wxlua-users — wxLua list for users and developers

[Wxlua-users] ENABLING WAR: Celebrity Christians and the real Da vinci Code

[<in...@st...>]

Reply-To: cecarl

http://straitgateministry.net/
345-page ONE NATION UNDER ISRAEL Almost FREE (see end)
Published by Truths Press

ENABLING WAR: HOW A BIBLE PUBLISHER CORRUPTED CHRIST'S WORDS
Why Celebrity leaders accept a form of Judaism and call it "Christianity"
By Charles E. Carlson (Director of We Hold These Truths)

This study is not written to convince anyone of what Jesus said; it quotes a small but important part of the Christian New Testament of Jesus, explaining how these words have been reinterpreted to justify serial wars.  This analysis is important to persons of all beliefs, faiths, and races who are trying to understand why wars dominate our world, and why many of those who call themselves by Jesus Christ's name find themselves pitted in support of wars against other races. It is undeniable that our current wars are directed at Islamic populations.  We focus on one bible that is used every day as a war enabler. 

This is a re-written and abbreviated version of our more far reaching 2006 series, "The Sheep and the Goats" Parts 1 & 2, which are drawn from a study of book of Matthew, chapter 25.  Your author is responding to requests that we more clearly prove and document the essence of popular biblical distortion about Heaven and Hell in the book of Matthew. Chapters 24-25, which evangelical believe to contain Jesus' words, are intentionally distorted by these same persons, both in the text and footnotes to the text in most popular bible study versions.

Self professed CHRISTIAN-ZIONISTS at the pulpit of mega-churches are left with an untenable problem. It is impossible for them to tell the truth about what certain New Testament Bible passages say, or even to read them, without contradicting their own support for wars and for the constantly warring state of Israel. Evangelical teaching and preaching often directly contradict that which Jesus taught about love and peace, and more surprisingly, celebrity Christian statements often directly conflict with Jesus' statements about Heaven and Hell. 

Church economics may be a factor in scriptural compromise. Opposition to war is less popular than ignoring or accepting it.  Celebrity Christian leaders may feel financial pressure to warp the New Testament into a wide and easy path interpretation, which they say points, not to Heaven and Hell, but to a "second coming."  Simply stated, pastors have learned they can't fill 10,000 seat arenas by leaning too heavily on sin, repentance and judgment as Jesus portrayed it in this carefully worded chapter. It is just not good for mega-church business.

Nor do they want to refute what is public policy at the highest levels. Some pastors no doubt justify compromise to choose the wide path to build their own empires in contrast to what Christ called the narrow path or "Strait" gate. Our government's public policy includes war, which has also become many churches' policy.

Evangelical celebrities generally believe in politically activism, and every politician knows it pays to be "born again." Thus an unspoken, unholy alliance has been created between financially successful biblical teachers on one hand, and politically successful politicians and businessmen who thrive on serial wars, on the other. The cost has been untold lives in several unholy wars in the 20 years.   But where to the war-accepting pastors find their scriptural support for war? We will examine only once example in a corrupted version of the book of Matthew, in one corrupted bible the Scofield Reference Bible 1967 version.

Oh that my adversary would write a book

The famous Scofield Reference Bible, perhaps the most powerfully promoted Bible ever written, is the godfather of modern bible distortion, which is now emulating and even exceeding in radicalism by other popular study bibles including the NIV Study Bible and the MacArthur Study Bible.   

Matthew 25 contains one of the most directly written and clearly self-explained passages on Heaven and Hell, which was once taken at face value in most churches. But the explanation of Matthew 25 we find so simple and straight forward is now rejected in almost every evangelical (Christian Zionist) church. And the Oxford/Scofield re-write is increasingly influential in a growing number of mainline churches where are members attend dispensational bible studies, and while there hours before celebrity-Christian media.  Members of most Catholic or mainline protestant church are also deeply influenced by the “end times controversy.

Matthew, the first book in the New Testament, contains the most outrageous example of added words that directly contradicts Jesus words. A quote from the Scofield Reference Bible footnotes directly contradicts what Jesus Christ is quoted to have said, His simple words, taken from the King James Edition, describing the basis upon which Jesus told his followers He himself will someday judge every man from every tribe ("nation").  We start by reading Jesus' words in Matthew 25:31-35:

"When the Son of man shall come in his glory, and all the holy angels with him, then shall he sit upon the throne of his glory: 32 And before him shall be gathered all nations: and he shall separate them one from another, as a shepherd divided his sheep from the goats: 33 And he shall set the sheep on his right hand, but the goats on the left. 34 Then shall the King say unto them on his right hand, Come, ye blessed of my Father, inherit the kingdom prepared for you from the foundation of the world: 35 For I was an hungered, and ye gave me meat: I was thirsty, and ye gave me drink: I was a stranger, and ye took me in: (skip to40)---Verily I say unto you, Inasmuch as ye have done it unto one of the least of these my brethren, ye have done it unto me."

The next five versus describe Jesus' rejection of the "goats," those who have been less than kind to the least of "his brethren," judging them unfit for heaven by the same measure.  Jesus provides a standard for his eternal kingdom, simple measurement of faith, love and service, a simple set of rules for His acceptance. 

Now, we must beg your patience to wade through a long paragraph which is a footnote to this same passage in Matthew above, and which footnote directly conflicts with what Jesus taught. Be patient if at first reading you should be confused. From the Scofield (Oxford) Reference bible, 

Matthew 25:32: p-1036-37: 
"This judgment of individual Gentiles is to be distinguished from other judgments in Scripture, such as the judgment of Israel, and the judgment of the wicked after the millennium. The time of this judgment is "when the Son of man shall come in his glory," i.e. at the second coming of Christ after the tribulation. The subjects of this judgment are ...all Gentiles then living on earth. Three classes of individuals are mentioned: (1) sheep, saved Gentiles; (2) goats, unsaved Gentiles; and (3) brethren, the people of Israel. The scene is on earth;...The test of this judgment is the treatment by individual Gentiles of those whom Christ calls "my brethren," living in the preceding tribulation period when Israel is fearfully persecuted...The sheep are Gentiles saved on earth during the period between the rapture and Christ's second coming to the earth..." 

What is that all about? Maybe you need to pinch yourself and read it again. The brethren are "the people of Israel?" but Israel can only mean the state by that name in 1967 when this was written, and the State of Israel did not exist when Jesus lived!  

Oxford Press introduces radical racism into its interpolation of Jesus' words by limiting heaven to "Jews" and those non-Jews who are excessively kind to Jews. And the footnotes also claim it is not even Heaven Jesus it talking about. Instead it is an early kingdom that is yet to come...and it has (according to Oxford) nothing to do with the world the Disciples and Jesus lived in!  

In the Scofield/Oxford University Press’s bible interpretation,” the least of these my brethren" are stated to be "Jews" living in the state of Israel at some future age.  In fact, in this passage Scofield/Oxford ignores Heaven exchanges it for an "earthy kingdom" at a future time after an Armageddon event to take place after a "rapture" event followed by a "millennium" event.  This complex and aggressive re-interruption of Jesus' simple words is an insult to any reader's intelligence and a false witness to God himself.  

WHO ARE JESUS BRETHREN?
When Jesus spoke of "his brethren" He was in no way talking about the 1948 created State of Israel. Surely He was referring to his followers who he often pointedly called brothers. And based upon Jesus many consistent statements about loving ones' neighbor, associates, and even our enemies, it is more likely Jesus was thinking of any and all of suffering mankind when he used the term "the least of these my brethren." But we do not try to decide that for you, let the words speak your own discernment. Suffice to say, the New Testament does not read as Oxford Press portrays it. That makes it a giant intentional forgery. 

"Goats," in Jesus simple pastoral analogy, are those who look a lot like sheep but who act differently and have ignored the needs of their fellow men.

But to Scofield/Oxford University Press, the goats are made to be human symbols of Anti-Israel, anti-Semitism.  They are "gentiles" who fail to shelter Israelis at some future time in imagined history. In other words, Oxford Press wants us to believe Jesus was not even talking to his disciples or needy mankind at all, but that he was tossing cute futurist riddles over his followers' innocent heads.  Why would Jesus lecture his disciples about some future generation that his "brethren" would not even comprehend or live to see?  Jesus words were (this writer thinks) relevant to those who followed him and to the questions they asked.  If Jesus did not shoot strait with his own, how can Jesus words be believable to those who try to follow him now?

Jesus left no doubt about his subject. To make sure everyone knows He was talking about, Heaven and Hell, and nothing else, he provides two parables in first half of the same 25th Chapter that he labeled as explaining the kingdom of Heaven ("the kingdom of Heaven is like"). And nowhere in the chapter did Jesus say he was suddenly inclined to change the subject to a "second coming" scene. Had Jesus intended to give a future history lesson it is logical to think he would have said so.  After all, He is the son of God and knew how to dictate a literate paragraph!  But this did not deter Oxford from changing the subject!

Little lies between the lines
Another Forgery is found in Matthew 24 in the Oxford 1967 edition, page 1035, and is part of the sheep and goats forgery.  It is worth a minute or two to see what Jesus was talking about that Oxford Press considered important enough to forge right in front of the world of Bible readers.  Here they did not change the words but refuted that they mean what Jesus said.  In other words Oxford Press says Jesus is wrong.

Jesus was first asked a natural and simple question by an unnamed disciple in the 3rd verse; 
3)"Tell us, when shall these things be.. what shall be the sign of thy coming, and of the end of the world?" 

To Which Jesus Replied: 
34)"Verily (truly) I say unto you, this generation shall not pass, till all these things be fulfilled."

Jesus was answering his youthful and curious followers, telling them certain events would occur before their "generation" is gone, leaving no doubt that he means some of them might live to see much persecution and the temple destroyed, among less easily understood events. One event specifically asked about was Jesus’ predicted discussion of Herod's Temple, where today the Al Aqsa Mosque stands. It turns out the "in this generation" was absolutely right for the Roman as well as Jewish records show the Temple was completely destroyed about 35 years later in 70 AD under the Roman General Titus. 

Now read the Oxford footnote that actually refutes Jesus words:
1(24:34, page 1035) states: 

"The word 'generation' though commonly used in Scriptures of those living at one time, could not here mean those alive at the time of Christ..." 

Obviously, Oxford Press has a problem with Jesus words so it vetoed what Jesus said.  To do this they invented a new definition of "generation" that fit Oxford's idea of an earthly kingdom in Jerusalem in which the present day state of Israelis, chosen of God, and owning the entire Middle East. Oxford fixed the Bible by making a generation as long as they wish it to be, say 3000 years or more.  This of course would make Jesus a liar to his own followers, but Oxford Press, satisfying the interest of World Zionism, does not flinch at doing this.  

WHAT IS OXFORD'S UNIVERSITY PRESS' MOTIVE?
Oxford Press treats Jesus Christ like a public school drop out who cannot express himself or compose a paragraph without Oxford's help. We are supposed to believe that the Scofield bible (written and rewritten by Oxford University Press from 1921 on) is needed to interpret Jesus lack of expression.  It would have us think God is incapable of explaining his purpose on earth.  How insulting to God. Oxford Press and Pharisaic Christian leaders should tremble in fear before a Holy God. 

Jesus was clearly addressing his Disciples in the whole of Chapter 25, and he was telling them about Heaven and Hell and He explained the earthly path to each place. Traditional Christians (as well as Muslims as we understand them) believe Jesus was describing the "narrow path" to heaven. Jesus does not tell us so but we tend to assume this path is also meant for us to follow. 

Most dispensational pastors avoid discussing Matthew 25 as thought they wish it would disappear. To deal with it they have adopted what we call "Scofieldism" to convert this problem into an asset. Scofieldism make no sense as interpreted in the Oxford footnotes except to "dispensationalists" who have built cults around it.  Scofieldism is gushed from the pulpits of the celebrity Christian churches and go out on Christian airwaves to untold millions. As a result, followers of Christ as well as moral but confused Christian drop outs are confused by the simple words Jesus left for us. 

Jesus words are easy to understand, but difficult to follow toward the strait gate. Oxford Press's words are impossible to understand and as hard to remember, but the interpretations are duck soup to follow...they require almost nothing of those who profess to be "born again."

Those who promoted the Oxford University Press bible (Scofield Reference Bibles) invents a wide and easy path to heaven, where hell is only a factor for others, where sacrificial kindness must be shown only to "Jews," and not even now...but later, during a millennial kingdom. Mr. Scofield coined the terms “dispensations” from which we have "Dispensationalism.” It is quite ok to slaughter Arab children and wage the cruelest wars on their parents.  The false interpretation of Jesus words, teaching that Israelis must be loved more than others has made it quite acceptable in dispensational circles to ignore the continuous bombing and starving of  Arabs and Muslims because they are thought to be Israel's enemies.

The amazing paradox about Scofield-dispensationalism is that it is practiced by those celebrity "Christians" who claim they believe that 100% of the Bible is literally true.  Ted Haggard is one.
Barbara Walters interviewed Evangelical mega-church leader on ABC's 20/20, on December 19th, 2005. The subject was Heaven and Hell. Haggard defined "evangelicalism" as three principles that he said evangelicals believe: that Jesus Christ is the son of God; that the Bible is literally true throughout; and that to go to Heaven one must be "born again."  But Haggard teaches Scofieldism.

It should be no surprise if the Zionist leaning, non-Christian Oxford Press would lie to attain a political agenda to control American Christianity. This was its logical purpose in making, selling and promoting tens of millions of Scofield bibles into American Seminaries and church leaders. 

CONCLUSION 
Dispensationalism is Christian-Zionism, which is racism. It requires each follower to acknowledge the lordship of the State of Israel along side of Christ. Their view of salvation is a glittery wide and easy way that that requires loving "Jews" next to loving God, and more than we love others. We have shown this in Part 2, The Sheep and the Goats. 

The immense, indescribable distortion of Jesus Christ's words of which such clear examples are found in Matthew 25, defies imagination in its brazenness and the cruel intent of its Zionist framers. It is used every day in the USA to enable and instigate the brutality falsely called "war" in the Middle East. -

Evangelical celebrities, and all who knowingly go along with the forgery, have the blood of a several racist wars on their hands.  Jesus' true words require that We Hold These Truths confronts pastors and leaders in tens of thousands of churches, as Jesus confronted the chief priests and Pharisees of his day.  Project Strait Gate is our plan to do this. WE Hold These Truths website is there to help you make your own decision.  Perhaps it will be a life changing and lifesaving decision for you.

Other works by this author:
 http://straitgateministry.net (Click: Pharisee Watch/Listen Live)

The Cause of Our Conflicts
Interactive audio-video presentation (Christian-Zionism's roots)
 
Almost FREE, 345-page ONE NATION UNDER ISRAEL, by Andrew Hurley, the factual documentary in the words of past congressmen telling how AIPAC (American Israeli Public Affairs Committee) has controlled the American Congress for a generation.  Shipping cost only, only one please.  
 
Strait Gate Ministry
Pharisee Watch
PO Box 14491
Scottsdale, AZ 85267
http://straitgateministry.net/

in...@st...
FAX 480 699 1902


To be blocked from future mail, please respond with the word "Delete".
Please write in the Subject line only, (allow one week for change).

[Wxlua-users] wxLua CVS Snapshots

[Leandro M. B. <lmb...@gm...>]

SGksCgpZZXN0ZXJkYXkgSSB0cmllZCB0aGUgbGF0ZXN0IENWUyBzbmFwc2hvdCAoMjAwNi0wNS0y
MSksIGJ1dCBydW5uaW5nCidtYWtlJyByZXN1bHRlZCBpbiBhbiBlcnJvcjoKCm1ha2UKCihjZCAu
L21vZHVsZXMvICYmIC9iaW4vbWFrZSApCm1ha2VbMV06IEVudGVyaW5nIGRpcmVjdG9yeQpgL0Zp
bGVzL0NvbXBpbGUvU291cmNlcy93eEx1YV9TbmFwc2hvdF8yMDA2LTA1LTIwL3d4THVhL21vZHVs
ZXMnCk1ha2VmaWxlOjExODY6ICoqKiBtaXNzaW5nIHNlcGFyYXRvci4gIFN0b3AuCm1ha2VbMV06
IExlYXZpbmcgZGlyZWN0b3J5CmAvRmlsZXMvQ29tcGlsZS9Tb3VyY2VzL3d4THVhX1NuYXBzaG90
XzIwMDYtMDUtMjAvd3hMdWEvbW9kdWxlcycKbWFrZTogKioqIFttb2R1bGVzXSBFcnJvciAyCgpJ
IGZvdW5kIHRoYXQgdGhlIG1vc3QgcmVjZW50IHNuYXBzaG90IHRoYXQgY29tcGlsZXMgY2xlYW5s
eSBpcwoyMDA2LTA1LTE5LCBzbyBJIGNvbXBpbGVkIGFuZCBpbnN0YWxsZWQgaXQuIFVuZm9ydHVu
YXRlbGx5LCB1c2luZyB0aGlzCjIwMDYtMDUtMTkgc25hcHNob3QsIHRoZSBJRExFIGV2ZW50cyB0
aGF0IEkgd2FzIGhhbmRsaW5nIGluIGEgd2luZG93CmFyZSBubyBsb25nZXIgYmVpbmcgcmVjZWl2
ZWQgOi0oCgpJcyB0aGlzIGEga25vd24gYnVnPyBJcyB0aGVyZSBhIGZpeCBmb3IgaXQ/IElmIG5v
dCwgSSBjYW4gdHJ5IHRvCmNyZWF0ZSBhIHNpbXBsZSBleGFtcGxlIHRoYXQgc2hvd3MgdGhlIHBy
b2JsZW0sIHNvIHRoYXQgc29sdmluZyBpdApiZWNvbWVzIGVhc2llci4KClRoYW5rIHlvdSwKCkxN
Qgo=

Re: [Wxlua-users] Re: XRC can not load a panel

[Steve K. <ha...@ya...>]

did you hand-write the XRC ?
To me it looks like a wx problem; you could try to modify the 'xrc' 
sample to see if you can reproduce with wxWidgets directly.

the xrc is created using a rad tool (hatch), and looks no problem to me. I have read the code of wxLua binding as well no found no problem (actually just puch and pop things.
so I too highly suspect this is wxWidgets problem but since no one reported it so far in wxBugreport. I need to reporduced it using c++ to confirm

Update: yes it seems wxWidgets problem reproduced by c++ code. Actually in c++ I just need to load the frame and show it, it automatically show the panel child; so no one wants to load the panel anymore. but in wxLua it seems not.

<code>
      
 #include "wx/wx.h" #ifdef __BORLANDC__ #pragma hdrstop #endif #include "wx/xrc/xmlres.h" #include "wx/image.h" #include "wx/frame.h" #define ID_FRAME 10000 #ifndef wxCLOSE_BOX #define wxCLOSE_BOX 0x1000 #endif  class t: public wxFrame {         DECLARE_CLASS( t ) public:     t( );     t( wxWindow* parent, wxWindowID=wxID_ANY, const wxString& caption = _(""), const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = wxCAPTION|wxRESIZE_BORDER|wxSYSTEM_MENU|wxCLOSE_BOX );      bool Create( wxWindow* parent, wxWindowID=wxID_ANY, const wxString& caption = _(""), const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = wxCAPTION|wxRESIZE_BORDER|wxSYSTEM_MENU|wxCLOSE_BOX);     void CreateControls(); }; IMPLEMENT_CLASS( t, wxFrame ) t::t( ){} t::t( wxWindow* parent, wxWindowID id, const wxString& caption, const wxPoint& pos, const wxSize& size, long style ){      SetParent(parent); 
 wxXmlResource::Get()->LoadFrame(this, GetParent(), wxT("ID_FRAME"));  wxXmlResource::Get()->LoadPanel(this, wxT("ID_PANEL")); }  class TestXRCApp: public wxApp {         DECLARE_CLASS( TestXRCApp ) public:     TestXRCApp();     virtual bool OnInit();      virtual int OnExit(); }; DECLARE_APP(TestXRCApp) IMPLEMENT_APP( TestXRCApp ) IMPLEMENT_CLASS( TestXRCApp, wxApp ) TestXRCApp::TestXRCApp(){} bool TestXRCApp::OnInit() {         wxXmlResource::Get()->InitAllHandlers();     wxXmlResource::Get()->Load(_T("testXRC.xrc"));  #if wxUSE_XPM     wxImage::AddHandler(new wxXPMHandler); #endif #if wxUSE_LIBPNG     wxImage::AddHandler(new wxPNGHandler); #endif #if wxUSE_LIBJPEG     wxImage::AddHandler(new wxJPEGHandler); #endif #if wxUSE_GIF     wxImage::AddHandler(new wxGIFHandler); #endif     t* mainWindow = new t( NULL, ID_FRAME );     mainWindow->Show(true);     return true; } int TestXRCApp::OnExit(){ return wxApp::OnExit();} 
</code>

XRC file is

<?xml version="1.0" encoding="UTF-8"?>
<resource version="2.3.0.1" xmlns="http://www.wxwidgets.org/wxxrc">
    <object class="wxFrame" name="ID_FRAME" subclass="t">
        <style>wxCAPTION|wxRESIZE_BORDER|wxSYSTEM_MENU|wxCLOSE_BOX</style>
        <size>400,300</size>
        <title>t</title>
        <object class="wxPanel" name="ID_PANEL">
            <style>wxSUNKEN_BORDER|wxTAB_TRAVERSAL</style>
            <object class="wxButton" name="ID_BUTTON">
                <label>Button</label>
            </object>
        </object>
    </object>
</resource>


Assuming this is a wx bug, I suggest you to use a sizer inside the frame 
wrapping the panel; maybe this will workaround the bug.
Nope it doesn work.

One thing is, in C++ I do not need to load the panel at all, show the frame is fine (it show the panel as well as all control on the panel; But in wxLua I can not, let me re-check this.

Sorry about long email :-)

I have file a bug report in wxWidgets page.

Cheers,



S.KIEU
		
---------------------------------
Do you Yahoo!?
  Yahoo! Personals: It's free to check out our great singles!  

Re: [Wxlua-users] Re: XRC can not load a panel

[Steve K. <ha...@ya...>]

did you hand-write the XRC ?
To me it looks like a wx problem; you could try to modify the 'xrc' 
sample to see if you can reproduce with wxWidgets directly.

the xrc is created using a rad tool (hatch), and looks no problem to me. I have read the code of wxLua binding as well no found no problem (actually just puch and pop things.
so I too highly suspect this is wxWidgets problem but since no one reported it so far in wxBugreport. I need to reporduced it using c++ to confirm

Update: yes it seems wxWidgets problem reproduced by c++ code. Actually in c++ I just need to load the frame and show it, it automatically show the panel child; so no one wants to load the panel anymore. but in wxLua it seems not.

<code>
      
 #include "wx/wx.h" #ifdef __BORLANDC__ #pragma hdrstop #endif #include "wx/xrc/xmlres.h" #include "wx/image.h" #include "wx/frame.h" #define ID_FRAME 10000 #ifndef wxCLOSE_BOX #define wxCLOSE_BOX 0x1000 #endif  class t: public wxFrame {         DECLARE_CLASS( t ) public:     t( );     t( wxWindow* parent, wxWindowID=wxID_ANY, const wxString& caption = _(""), const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = wxCAPTION|wxRESIZE_BORDER|wxSYSTEM_MENU|wxCLOSE_BOX );      bool Create( wxWindow* parent, wxWindowID=wxID_ANY, const wxString& caption = _(""), const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = wxCAPTION|wxRESIZE_BORDER|wxSYSTEM_MENU|wxCLOSE_BOX);     void CreateControls(); }; IMPLEMENT_CLASS( t, wxFrame ) t::t( ){} t::t( wxWindow* parent, wxWindowID id, const wxString& caption, const wxPoint& pos, const wxSize& size, long style ){      SetParent(parent); 
 wxXmlResource::Get()->LoadFrame(this, GetParent(), wxT("ID_FRAME"));  wxXmlResource::Get()->LoadPanel(this, wxT("ID_PANEL")); }  class TestXRCApp: public wxApp {         DECLARE_CLASS( TestXRCApp ) public:     TestXRCApp();     virtual bool OnInit();      virtual int OnExit(); }; DECLARE_APP(TestXRCApp) IMPLEMENT_APP( TestXRCApp ) IMPLEMENT_CLASS( TestXRCApp, wxApp ) TestXRCApp::TestXRCApp(){} bool TestXRCApp::OnInit() {         wxXmlResource::Get()->InitAllHandlers();     wxXmlResource::Get()->Load(_T("testXRC.xrc"));  #if wxUSE_XPM     wxImage::AddHandler(new wxXPMHandler); #endif #if wxUSE_LIBPNG     wxImage::AddHandler(new wxPNGHandler); #endif #if wxUSE_LIBJPEG     wxImage::AddHandler(new wxJPEGHandler); #endif #if wxUSE_GIF     wxImage::AddHandler(new wxGIFHandler); #endif     t* mainWindow = new t( NULL, ID_FRAME );     mainWindow->Show(true);     return true; } int TestXRCApp::OnExit(){ return wxApp::OnExit();} 
</code>

XRC file is

<?xml version="1.0" encoding="UTF-8"?>
<resource version="2.3.0.1" xmlns="http://www.wxwidgets.org/wxxrc">
    <object class="wxFrame" name="ID_FRAME" subclass="t">
        <style>wxCAPTION|wxRESIZE_BORDER|wxSYSTEM_MENU|wxCLOSE_BOX</style>
        <size>400,300</size>
        <title>t</title>
        <object class="wxPanel" name="ID_PANEL">
            <style>wxSUNKEN_BORDER|wxTAB_TRAVERSAL</style>
            <object class="wxButton" name="ID_BUTTON">
                <label>Button</label>
            </object>
        </object>
    </object>
</resource>


Assuming this is a wx bug, I suggest you to use a sizer inside the frame 
wrapping the panel; maybe this will workaround the bug.
Nope it doesn work.

One thing is, in C++ I do not need to load the panel at all, show the frame is fine (it show the panel as well as all control on the panel; But in wxLua I can not, let me re-check this.

Sorry about long email :-)

DO you think I should file a bug report in wxWidgets page?

Cheers,



S.KIEU
		
---------------------------------
On Yahoo!7
  Socceroos Central: Latest news, schedule, blogs and videos.  

[Wxlua-users] Re: wxLua shared build status

[Francesco M. <f18...@ya...>]

Francesco Montorsi <f18m_cpp217828@...> writes:
> 1) the wx.dll which is created by MSVC, generates the following error 
> when used through luamodule.wx.lua sample:
> 
> "Cannot find a required procedure"
> 
> (the message is localized so I'm translating it)... maybe that's because 
> wx.dll is a dll which in reality does not contain any code apart from 
> wxLua\modules\luamodule\src\luamodule.cpp (it's just 34K IIRC) ?
> Nonetheless it should force lua to import all other DLLs from which it 
> depends (wxlua* and wx* ones)...
Ok, it was late and I was definitevely sleeping: adding right export/import
symbols for luamodule, MSVC's wx.dll works perfectly...

Francesco

[Wxlua-users] Re: XRC can not load a panel

[Francesco M. <f18...@ya...>]

Steve Kieu ha scritto:
> 
> Hi,
> 
> I am not quite sure that this is bug in wxLua or wxWidgets  or I am 
> doing something wrong. Maybe it is in wxWidgets (I think).
> 
> The problem is the XRC can not load a panel ; .
> 
> To illustrate, I have a very simple xrc  like this:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <resource version="2.3.0.1" xmlns="http://www.wxwidgets.org/wxxrc">
>     <object class="wxFrame" name="ID_FRAME" subclass="t">
>         <style>wxCAPTION|wxRESIZE_BORDER|wxSYSTEM_MENU|wxCLOSE_BOX</style>
>         <size>400,300</size>
>         <title>t</title>
>         <object class="wxPanel" name="ID_PANEL">
>             <style>wxSUNKEN_BORDER|wxTAB_TRAVERSAL</style>
>         </object>
>     </object>
> </resource>
> 
> suppose the xrc file name below is correct (the above one)
> lua script:
> 
> local frame=nil
> res = wx.wxXmlResourceGetDefault()
> res:InitAllHandlers()
> local xrcFilename = "./test.xrc"
> res:Load(xrcFilename)
> frame = wx.wxFrame(wx.wxNull, wx.wxID_ANY, "My Frame")
> 
> res:LoadFrame(frame, wx.wxNull, "ID_FRAME")
> local myPanel=wx.wxPanel(wx.wxNull, wx.wxID_ANY)
> res:LoadPanelCreate(myPanel, frame, "ID_PANEL" )
> 
> If you run this script wxlua report error:
> 
> XRC resource 'ID_PANEL' (class 'wxPanel') not found
> As you see in xrc file ID_PANEL is the panel, why not find it?
> 
> Viewing examples of wxwidgets and wxlua dealing with XRC, it seems that 
> everybody use dialog instead of frame + panel, so maybe no one got that 
> problem so far.
> 
> Any comment?
did you hand-write the XRC ?
To me it looks like a wx problem; you could try to modify the 'xrc' 
sample to see if you can reproduce with wxWidgets directly.

Assuming this is a wx bug, I suggest you to use a sizer inside the frame 
wrapping the panel; maybe this will workaround the bug.

HTH,
Francesco

[Wxlua-users] Re: Problems compiling wxLua on Windows

[Francesco M. <f18...@ya...>]

Edgar GloWacki ha scritto:
> * wxWidgets 2.6.3 Patch 2 compiled as multi DLL lib non-unicode
> 
> * wxLua 2.6.2.0 using DLL Debug Multilib
> 
> * WindowsXP
> 
> *.NET 2003 (VC++ 7.1)
> 
>  
> 
> Just downloaded wxLua and was trying to build it using wxLua.dsw project 
> from msw folder and I got allot of warnings and errors. Project 
> mod_lua_lib compiles cleanly but when it gets to mod_wxluadebug I get this:
> 
>  
> 
> \ wxLua\ modules\ wxluadebug\ src\ staktree.cpp(110) : warning C4273: 
> 'ms_classInfo' : inconsistent dll linkage
> 
> \ wxLua\ modules\ wxluadebug\ src\ staktree.cpp(110) : error C2491: 
> 'wxLuaStackDialog::ms_classInfo' : definition of dllimport static data 
> member not allowed
> 
> \ wxLua\ modules\ wxluadebug\ src\ staktree.cpp(110) : warning C4273: 
> 'wxLuaStackDialog::GetClassInfo' : inconsistent dll linkage
> 
> \ wxLua\ modules\ wxluadebug\ src\ staktree.cpp(112) : warning C4273: 
> 'sm_eventTable' : inconsistent dll linkage
> 
> …
> 
> And many more, which I will skip it for now, since it’s basically the 
> same. I hope I’m missing something very simple here.
wxlua 2.6.2.0 does not compile with that config.
Luckily, yesterday I've just worked on that and now it should compile 
fine; I suggest you to use the latest snapshot at

http://wxlua.sourceforge.net/download/

using command-line makefiles (sorry I haven't tested DSW/DSP yet after 
last changes) or to compile in static mode.

Thanks,
Francesco

[Wxlua-users] Re: Should wxLua be subscribed at LuaForge?

[Francesco M. <f18...@ya...>]

klaas.holwerda ha scritto:
> Francesco Montorsi wrote:
>> Hi,
>>   before I forget this - what about subscribing wxLua project at 
>> LuaForge and then disable all services and use as homepage wxlua.sf.net ?
> I think that is a good idea, it is only for subscribing right, not 
> really move all?
right - just to make wxLua more visible ;)

Francesco

[Wxlua-users] XRC can not load a panel

[Steve K. <ha...@ya...>]

Hi,

I am not quite sure that this is bug in wxLua or wxWidgets  or I am doing something wrong. Maybe it is in wxWidgets (I think).

The problem is the XRC can not load a panel ; .

To illustrate, I have a very simple xrc  like this:

<?xml version="1.0" encoding="UTF-8"?>
<resource version="2.3.0.1" xmlns="http://www.wxwidgets.org/wxxrc">
    <object class="wxFrame" name="ID_FRAME" subclass="t">
        <style>wxCAPTION|wxRESIZE_BORDER|wxSYSTEM_MENU|wxCLOSE_BOX</style>
        <size>400,300</size>
        <title>t</title>
        <object class="wxPanel" name="ID_PANEL">
            <style>wxSUNKEN_BORDER|wxTAB_TRAVERSAL</style>
        </object>
    </object>
</resource>

suppose the xrc file name below is correct (the above one)
lua script:

local frame=nil
res = wx.wxXmlResourceGetDefault()
res:InitAllHandlers()
local xrcFilename = "./test.xrc" 
res:Load(xrcFilename)
frame = wx.wxFrame(wx.wxNull, wx.wxID_ANY, "My Frame")

res:LoadFrame(frame, wx.wxNull, "ID_FRAME")
local myPanel=wx.wxPanel(wx.wxNull, wx.wxID_ANY)
res:LoadPanelCreate(myPanel, frame, "ID_PANEL" )

If you run this script wxlua report error:

XRC resource 'ID_PANEL' (class 'wxPanel') not found
As you see in xrc file ID_PANEL is the panel, why not find it?

Viewing examples of wxwidgets and wxlua dealing with XRC, it seems that everybody use dialog instead of frame + panel, so maybe no one got that problem so far. 

Any comment?
Cheers,





S.KIEU
		
---------------------------------
On Yahoo!7 
  360°:  Your own space to share what you want with who you want!

[Wxlua-users] Problems compiling wxLua on Windows

[Edgar G. <edg...@ya...>]

* wxWidgets 2.6.3 Patch 2 compiled as multi DLL lib non-unicode
  * wxLua 2.6.2.0 using DLL Debug Multilib
  * WindowsXP
  *.NET 2003 (VC++ 7.1)
     =20
   Just downloaded wxLua and was trying to build it using wxLua.dsw project=
 from msw folder and I got allot of warnings and errors. Project mod_lua_li=
b compiles cleanly but when it gets to mod_wxluadebug I get this:
   =20
   \  wxLua\  modules\  wxluadebug\  src\  staktree.cpp(110) : warning C427=
3: 'ms_classInfo' : inconsistent dll linkage
   \  wxLua\  modules\  wxluadebug\  src\  staktree.cpp(110) : error C2491:=
 'wxLuaStackDialog::ms_classInfo' : definition of dllimport static data mem=
ber not allowed
   \  wxLua\  modules\  wxluadebug\  src\  staktree.cpp(110) : warning C427=
3: 'wxLuaStackDialog::GetClassInfo' : inconsistent dll linkage
   \  wxLua\  modules\  wxluadebug\  src\  staktree.cpp(112) : warning C427=
3: 'sm_eventTable' : inconsistent dll linkage
  =E2=80=A6
  And many more, which I will skip it for now, since it=E2=80=99s basically=
 the same. I hope I=E2=80=99m missing something very simple here.
   =20
   -Edgar
  =20

Re: [Wxlua-users] Should wxLua be subscribed at LuaForge?

[klaas.holwerda <kho...@xs...>]

Francesco Montorsi wrote:
> Hi,
>   before I forget this - what about subscribing wxLua project at 
> LuaForge and then disable all services and use as homepage wxlua.sf.net ?
I think that is a good idea, it is only for subscribing right, not 
really move all?

Klaas

[Wxlua-users] wxLua shared build status

[Francesco M. <f18...@ya...>]

Hi,
   I did various changes and now using SHARED=1 option wxLua compiles 
smoothly as a dll also on windows.

Nonetheless, there are two problems:

1) the wx.dll which is created by MSVC, generates the following error 
when used through luamodule.wx.lua sample:

"Cannot find a required procedure"

(the message is localized so I'm translating it)... maybe that's because 
wx.dll is a dll which in reality does not contain any code apart from 
wxLua\modules\luamodule\src\luamodule.cpp (it's just 34K IIRC) ?
Nonetheless it should force lua to import all other DLLs from which it 
depends (wxlua* and wx* ones)...

Unfortunately I've upgraded to latest Mingw which gives an internal 
error when compiling wx_bind.cpp and borland is giving me strange errors 
about wxLUA_DECLARE_ENCAPSULATION so I can't verify if this happens also 
with other win32 compilers...


2) setting the #define wxLuaDebugServer to 1 in wxluasetup.h generates a 
dependency of wxbind module to the wxluasocket (and thus also to 
wxluadebug) module. Is this a good thing to do ?
Shouldn't we keep all wxLuaDebugServer stuff in the wxluasocket module?


Thanks,
Francesco

[Wxlua-users] Should wxLua be subscribed at LuaForge?

[Francesco M. <f18...@ya...>]

Hi,
   before I forget this - what about subscribing wxLua project at 
LuaForge and then disable all services and use as homepage wxlua.sf.net ?

This way wxLua would be more easily discovered by lua developers...

Francesco

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
>> > -> all DLLs/.so of wxLua/lib if they built wxLua as a shared library
>> > (SHARED=1)
>> > -> wx.so/.dll if they built wxLua as a static library (SHARED=0).
>> >    In fact, wx.so/.dll should be built regardless of the SHARED option
>> > value: when SHARED==1, it will just be a super-small file which tells
>> > the OS to load the other .so/.dll libraries; when SHARED==0, it will be
>> > a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.
>> >
>> > What do you think ?
as a reply to my own thought - it's wrong: luamodule should never be 
built when SHARED==0. In fact, as written at 
http://lua-users.org/wiki/BuildingModules, our wx.dll/.so would embed in 
that case a duplicated copy of lua core, which must be avoided.
Thus I'll set luamodule buildable only when SHARED==1


> Sounds good, would this account for the possibility of someone getting
> the wxWidgets2.6.3.rpm so they have their .so files and build wxLua
> (or someday we provide our own rpm that depends on the wxWidgets rpm)
> then we'd just want our .so libs to link to the rpm's libs. Or is this
> way too much to ask.
This is definitevely possible and is the whole sense of building shared 
libraries. On Unix it already works (I'm using wxLua shared libs against 
Ubuntu's shared build of wxGTK 2.6.1).


> >> Trying to get wx.dll working on Win32, too, I've found a lot of problems
>> in building the DLLs of wxLua.
>>
>> In particular, it looks like the different modules need somehow stuff
>> which is in other modules to link so that I ended up to compile first
>> all files and then link them all together in a single monolithic DLL
>> library.
> 
> It should be all top down from wxLuaSocket->wxLuaDebug->wxLua, no deps
> the other way around.
Well, looking at docs/install.html and to current Makefiles (which I'm 
sure they work on linux), the link order is:

wxlua, [wxbindstc, ] wxbind, wxluasocket, wxluadebug, lua

where library X depends from libraries listed on its right (e.g. 
wxluasocket depends on wxluadebug and lua).

maybe it would be more correct to write that:

    wxlua depends from:          lua
    wxbind depends from:         lua
    wxbindstc depends from:      wxbind, lua
    wxluadebug depends from:     wxlua, lua
    wxluasocket depends from:    wxluadebug, wxlua, lua

I realize that I've never asked such important question and that these 
relations should definitevely be cleared.... please correct the above 
schema.


> 
>> This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol
>> while for various reasons they should use different ones for the
>> different modules.
> 
> I had no idea. This is not a problem, we just need wxlsockdefs.h and
> wxldebugdefs.h or something like that for each.
I'll look about it and let you know. This will be also a good occasion 
to learn more about wxLua internals :))


>> Since, in my personal experience, building as DLL can be a BIG pain (you
>> have to be very careful about WXDLLIMPEXP symbols, inter-module
>> dependencies and in general in the entire build system), I propose to
>> make wxLua buildable as a set of modules when SHARED==0 and as a single
>> monolithic DLL library when SHARED==1.
>>
>> What do you think ?
> 
> I have never tried to build anything as a DLL except by accident. It's
> probably a shame that I separated out the wxluadebug and wxluasocket
> stuff from wxlua since it's so tiny compared to wxWidgets that the
> size savings of not having them is quite negligible and it's a hassle
> dealing with so many tiny parts.
that's partially true... OTOH they solve quite different tasks so that, 
at least logically, having them separate is a good thing...


> 
>> Also, what about moving "luamodule" dir to wxLua\modules ? Can I commit
>> that change ?
> 
> I see it more as an app? It's an end product of wxLua to be used by a
> user and it links to the other libs just like an app, even though it's
> a lib.
well, also other libs link to other libs when built as DLL :)
I think it would be confusing for the user to have all modules' output 
placed in wxLua\lib and apps' output partially in wxLua\bin and 
wxLua\lib....

An application is something the user can run... an executable; luamodule 
produces a library which is usable more or less like all other wxLua 
libraries (if we say that luamodule is like an app, why not say that 
also for e.g. wxbind? :))


> I thought it belonged in apps since you can't link to it unlike
> the other wxLua modules.
The link happens dinamically but is always a link...

> Sure, it's called module, but that's just
> lua's name for "require" libs.
> 
> I'm off for the next couple days, if you still think it's a good idea, 
> fine.
Ok, I'll try to fix the DLL build adding 
WXDLLIMPEXP_{WXBIND|WXBINDSTC|WXLUA|WXLUADEBUG|WXLUASOCKET} and then 
eventually commit them.

> 
> -------
> 
> I also had this in mind, the wxLuaFreeze and luamodule program may
> want to be compiled with smaller sets of the wxWidgets bindings. This
> is back to the old question of how to deal with different wxluasetup.h
> files, the wxLua app should always have everything. 
I thought this issue was solved using the WXLUASETUP_DIR and 
WXLUABINDLIB_DIR options; if someone wants a minimal version of wxLua 
without affecting the wxLua executable he needs to keep its wxluasetup.h 
in its own project folder instead of modifying 
wxLua\modules\wxbind\setup\wxluasetup.h...

>Also, the
> luamodule must have WXLUA_LUA_NEWTHREAD not #defined to use with a
> stock version of the lua executable and again the wxLua program
> *should* have it.
ok, I'll then add a new target to the makefiles, "lua", which builds the 
verbatim version of lua 5.1 and then make luamodule build against it.

I could then add also a "lua" <exe> target so that in the end, building 
wxLua one would get:

in bin\:
   wxlua-lua[.exe]  <-- the lua interpreter with WXLUA_LUA_NEWTHREAD
   lua5.1[.exe]     <-- the lua interpreter WITHOUT WXLUA_LUA_NEWTHREAD

in lib\:
   wxlua_gtk2d_lua-2.7[.so/.dll]  <-- lua core with WXLUA_LUA_NEWTHREAD
   lua5.1[.so/.dll]  <-- lua core WITHOUT WXLUA_LUA_NEWTHREAD

the names lua5.1[.exe] and lua5.1[.so/.dll] are intentionally the same 
of the LuaBinaries project since we should not fear to overwrite the 
system's installations of these things since they will be identic to the 
ones provided by the LuaBinaries project...


> Of course you (I) don't want to have to compile wxLua w/ everything,
> clean out the libs and rebuild, if you're a developer this can get
> really annoying. Maybe the wxLuaFreeze and luamodule should just
> compile the cpp files to their own private object files and be done
> with it. There's nothing worse than compiling something with wrong
> build options or #defines and when you get to end the linker complains
> about missing parts, you've got to completely restart and people might
> just get confused/annoyed and give up.
> 
> Additionally the wxLuaFreeze and luamodule might as well be linked to
> the object files directly since they really ought to be monolithic
> since they're distributable.
well, wxLuaFreeze is monolithic when compiled with SHARED==0.
luamodule OTOH *needs* to be non-monolithic (i.e. it needs not to have 
lua core code inside it - see beginning of this reply).

When compiled with SHARED==1, you get a wxLuaFreeze which depends from 
wxLua dlls but that's what the user expects I think...


> 
> -------
> 
> Finally, can we output the object files into unique dirs for each
> build setting. IIRC they're put in the same place for debug and
> release in MSVC and configure w/ gmake, but I could be wrong, I can't
> check right now.
yes, I'll do it.


> 
> Thanks for all your work Francesco, it'd be a pretty sorry state of
> affairs without you.
Thanks for your great work on wxLua, which unfortunately I haven't 
managed to integrate with my other projects yet :(

BTW, wxLuaSudoku sample is now so complete, nice and native-looking 
that we could really propose it as a stock game of Gnome ;)

Francesco

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

Josh Turpen ha scritto:
> 
> I see I'm not the only one having problems.  In order for other binary 
> modules to work with wxLua, wxLua needs to link against a seperate 
> Lua.DLL, a DLL which the modules also link against. 
I know - it's the same issue described at

http://lua-users.org/wiki/BuildingModules

(see "Do Not Link Modules to the Lua Core Libraries"), right ?



> In the current 
> binary release of wxLua the only way to make it work is to rebuild all 
> of the modules and have them link against wxLua.dll to get the lua symbols.
> 
> Please please please add/fix the SHARED options to the build system :)
Just for curiosity: how did you manage to rebuild all modules ?
Hacking the makefiles ?


> 
> 
> I have 3D rendering working inside a wxFrame using wxLua and IrrLua. 
> 
> http://irrlua.sourceforge.net/14.wxWindow.lua
very interesting project !
Maybe we should add a "projects using wxLua" section in wxLuaWebsite...


> 
>   Unfortunately it only works with wxLua 2.4 due to the linking issues 
> I've described above, which this SHARED option would solve.
> 
>   Linking against the LuaBinaries would be best of all.  If everybody 
> links against the same binaries, all of our modules will play together 
> without the need for a recompile somewhere.  Just download the .DLL/.so 
> and go.
I think it should be not very difficult to reach this compatibility: we 
just need to build luamodule against the verbatim version of lua.

Francesco

Re: [Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[John L. <jla...@gm...>]

On 5/19/06, Francesco Montorsi <f18...@ya...> wrote:
> > Ok, another thing which now comes to my mind: "luamodule" directory
> > should probably be moved too, in wxLua/modules. In fact, it does not
> > build any application at all, just a .so/.dll

See below, but the .so/.dll is a distributable usable product, like an app?

> > BTW: I'd organize the thing as:
> > -> wx.so/dll is always placed in wxLua/lib (even if, in Unix, you're
> > building from a different build folder, e.g. wxLua/mybuild)

Sure.

> > -> luamodule.wx.lua sample uses
> > package.cpath = ";;../lib/?.so;..\lib\?.dll"
> > before the call to require("wx")
> >
> > -> on Unix, wx.so is installed in  $prefix/lib/lua/5.1

Ok.

> > Now, developers using wxLua which want to ship an application entirely
> > written in wxLua, which uses the require("wx") notation, will just need
> > to ship:
> >
> > -> all DLLs/.so of wxLua/lib if they built wxLua as a shared library
> > (SHARED=1)
> > -> wx.so/.dll if they built wxLua as a static library (SHARED=0).
> >    In fact, wx.so/.dll should be built regardless of the SHARED option
> > value: when SHARED==1, it will just be a super-small file which tells
> > the OS to load the other .so/.dll libraries; when SHARED==0, it will be
> > a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.
> >
> > What do you think ?

Sounds good, would this account for the possibility of someone getting
the wxWidgets2.6.3.rpm so they have their .so files and build wxLua
(or someday we provide our own rpm that depends on the wxWidgets rpm)
then we'd just want our .so libs to link to the rpm's libs. Or is this
way too much to ask.

> Trying to get wx.dll working on Win32, too, I've found a lot of problems
> in building the DLLs of wxLua.
>
> In particular, it looks like the different modules need somehow stuff
> which is in other modules to link so that I ended up to compile first
> all files and then link them all together in a single monolithic DLL
> library.

It should be all top down from wxLuaSocket->wxLuaDebug->wxLua, no deps
the other way around.

> This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol
> while for various reasons they should use different ones for the
> different modules.

I had no idea. This is not a problem, we just need wxlsockdefs.h and
wxldebugdefs.h or something like that for each.

> Since, in my personal experience, building as DLL can be a BIG pain (you
> have to be very careful about WXDLLIMPEXP symbols, inter-module
> dependencies and in general in the entire build system), I propose to
> make wxLua buildable as a set of modules when SHARED==0 and as a single
> monolithic DLL library when SHARED==1.
>
> What do you think ?

I have never tried to build anything as a DLL except by accident. It's
probably a shame that I separated out the wxluadebug and wxluasocket
stuff from wxlua since it's so tiny compared to wxWidgets that the
size savings of not having them is quite negligible and it's a hassle
dealing with so many tiny parts.

> Also, what about moving "luamodule" dir to wxLua\modules ? Can I commit
> that change ?

I see it more as an app? It's an end product of wxLua to be used by a
user and it links to the other libs just like an app, even though it's
a lib. I thought it belonged in apps since you can't link to it unlike
the other wxLua modules. Sure, it's called module, but that's just
lua's name for "require" libs.

I'm off for the next couple days, if you still think it's a good idea, fine.

-------

I also had this in mind, the wxLuaFreeze and luamodule program may
want to be compiled with smaller sets of the wxWidgets bindings. This
is back to the old question of how to deal with different wxluasetup.h
files, the wxLua app should always have everything. Also, the
luamodule must have WXLUA_LUA_NEWTHREAD not #defined to use with a
stock version of the lua executable and again the wxLua program
*should* have it.

Of course you (I) don't want to have to compile wxLua w/ everything,
clean out the libs and rebuild, if you're a developer this can get
really annoying. Maybe the wxLuaFreeze and luamodule should just
compile the cpp files to their own private object files and be done
with it. There's nothing worse than compiling something with wrong
build options or #defines and when you get to end the linker complains
about missing parts, you've got to completely restart and people might
just get confused/annoyed and give up.

Additionally the wxLuaFreeze and luamodule might as well be linked to
the object files directly since they really ought to be monolithic
since they're distributable.

-------

Finally, can we output the object files into unique dirs for each
build setting. IIRC they're put in the same place for debug and
release in MSVC and configure w/ gmake, but I could be wrong, I can't
check right now.

Thanks for all your work Francesco, it'd be a pretty sorry state of
affairs without you.
    John Labenski

Re: [Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Josh T. <zen...@ya...>]

I see I'm not the only one having problems.  In order for other binary modules to work with wxLua, wxLua needs to link against a seperate Lua.DLL, a DLL which the modules also link against.  In the current binary release of wxLua the only way to make it work is to rebuild all of the modules and have them link against wxLua.dll to get the lua symbols.

Please please please add/fix the SHARED options to the build system :)


I have 3D rendering working inside a wxFrame using wxLua and IrrLua.  

http://irrlua.sourceforge.net/14.wxWindow.lua

  Unfortunately it only works with wxLua 2.4 due to the linking issues I've described above, which this SHARED option would solve.

  Linking against the LuaBinaries would be best of all.  If everybody links against the same binaries, all of our modules will play together without the need for a recompile somewhere.  Just download the .DLL/.so and go.

" Trying to get wx.dll working on Win32, too, I've found a lot of problems 
in building the DLLs of wxLua.

In particular, it looks like the different modules need somehow stuff 
which is in other modules to link so that I ended up to compile first 
all files and then link them all together in a single monolithic DLL 
library.

This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol while for various reasons they should use different ones for the 
different modules.

Since, in my personal experience, building as DLL can be a BIG pain (you 
have to be very careful about WXDLLIMPEXP symbols, inter-module 
dependencies and in general in the entire build system), I propose to 
make wxLua buildable as a set of modules when SHARED==0 and as a single 
monolithic DLL library when SHARED==1.

What do you think ? "





		
---------------------------------
Ring'em or ping'em. Make  PC-to-phone calls as low as 1¢/min with Yahoo! Messenger with Voice.

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

Francesco Montorsi ha scritto:
> John Labenski ha scritto:
>> On 5/17/06, Francesco Montorsi 
>> <f18...@ya...> wrote:
>>> Hi,
>>>     I'm experimenting with wx module and I've got a few proposals for 
>>> it:
>>>
>>> 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
>>> isn't it ? Shouldn't then go in wxLua/samples ?
>>> wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?
>>
>> Eh... I think these are pretty specialized. But, you're probably
>> right, once things work they should be moved. I just put them into the
>> dir where I generated the shared lib since I was having trouble with
>> the paths for require.
> Ok, another thing which now comes to my mind: "luamodule" directory 
> should probably be moved too, in wxLua/modules. In fact, it does not 
> build any application at all, just a .so/.dll
> 
> BTW: I'd organize the thing as:
> -> wx.so/dll is always placed in wxLua/lib (even if, in Unix, you're 
> building from a different build folder, e.g. wxLua/mybuild)
> 
> -> luamodule.wx.lua sample uses
> package.cpath = ";;../lib/?.so;..\lib\?.dll"
> before the call to require("wx")
> 
> -> on Unix, wx.so is installed in  $prefix/lib/lua/5.1
> 
> Now, developers using wxLua which want to ship an application entirely 
> written in wxLua, which uses the require("wx") notation, will just need 
> to ship:
> 
> -> all DLLs/.so of wxLua/lib if they built wxLua as a shared library 
> (SHARED=1)
> -> wx.so/.dll if they built wxLua as a static library (SHARED=0).
>    In fact, wx.so/.dll should be built regardless of the SHARED option 
> value: when SHARED==1, it will just be a super-small file which tells 
> the OS to load the other .so/.dll libraries; when SHARED==0, it will be 
> a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.
> 
> What do you think ?
Trying to get wx.dll working on Win32, too, I've found a lot of problems 
in building the DLLs of wxLua.

In particular, it looks like the different modules need somehow stuff 
which is in other modules to link so that I ended up to compile first 
all files and then link them all together in a single monolithic DLL 
library.

This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol 
while for various reasons they should use different ones for the 
different modules.

Since, in my personal experience, building as DLL can be a BIG pain (you 
have to be very careful about WXDLLIMPEXP symbols, inter-module 
dependencies and in general in the entire build system), I propose to 
make wxLua buildable as a set of modules when SHARED==0 and as a single 
monolithic DLL library when SHARED==1.

What do you think ?

Also, what about moving "luamodule" dir to wxLua\modules ? Can I commit 
that change ?

Thanks,
Francesco

Re: [Wxlua-users] Re: Function naming conventions (follow wxPython or our own way)

[John L. <jla...@gm...>]

T24gNS8xOS8wNiwgSGFra2kgRG9ndXNhbiA8ZG9ndXNhbmhAdHIubmV0PiB3cm90ZToKPiBGcmFu
Y2VzY28gTW9udG9yc2kgeWF6bf3+Ogo+ID4gSm9obiBMYWJlbnNraSBoYSBzY3JpdHRvOgo+ID4+
IEluIGdvaW5nIHRocm91Z2ggdGhlIHRoZSBpbnRlcmZhY2UgZmlsZXMgSSd2ZSBub3RpY2VkIHRo
YXQgdGhlcmUgYXJlIGEKPiA+PiBmZXcgbmFtaW5nIGluY29uc2lzdGVuY2llcyBmb3IgQysrIG92
ZXJsb2FkZWQgZnVuY3Rpb25zIGFuZAo+ID4+IGNvbnN0cnVjdG9ycy4gVHlwaWNhbGx5IHRoZXkg
aGF2ZSB0aGUgbmFtZXMgdGhhdCB3eFB5dGhvbiB1c2VzICh3aGVyZQo+ID4+IG5vdGVkIGluIHRo
ZSBkb2NzKSBhbmQgZm9yIHRoZSBtb3N0IHBhcnQgYXJlIGZpbmUsIGJ1dC4uLgo+ID4+Cj4gPj4g
U2luY2Ugd2UgY2FuIG92ZXJsb2FkZWQgZnVuY3Rpb24gaW4gd3hMdWEgZGlyZWN0bHkgKHVzdWFs
bHkpIHdlIGRvbid0Cj4gPj4gYWN0dWFsbHkgbmVlZCB0byBnaXZlIHRoZW0gdW5pcXVlIG5hbWVz
LCBob3dldmVyIHRoZXkgbmVlZCBzb21lIHNvcnQKPiA+PiBvZiBuYW1lIGZvciB0aGUgQyBmdW5j
dGlvbiBhbmQgbWlnaHQgYXMgd2VsbCBiZSBhY2Nlc3NpYmxlIGluIHd4THVhCj4gPj4gdXNpbmcg
dGhhdCBuYW1lIGFzIHdlbGwgYXMgdGhlIG92ZXJsb2FkZWQgd2F5Lgo+ID4gaG93ZXZlciBJJ20g
bm90IHN1cmUgdGhhdCBoYXZpbmcgdHdvIHBvc3NpYmxlIG5hbWVzIChlLmcuIEluc2VydEl0ZW0g
YW5kCj4gPiBJbnNlcnRJdGVtU3RyaW5nKSBmb3IgdGhlIHNhbWUgZnVuY3Rpb25zIChpbiBsdWEg
c2NyaXB0cykgaXMgYSBnb29kCj4gPiB0aGluZzogaXQgcHJvYmFibHkgbWVhbnMgdGhlcmUgd2ls
bCBiZSBzY3JpcHRzIHdpdGggYSBtZXNzeSBtaXggb2YgdGhlCj4gPiB0d28uLi4KClRoaXMgaXMg
dHJ1ZSwgaG9wZWZ1bGx5IHBlb3BsZSB3aWxsIGp1c3QgdXNlIHRoZSBvdmVybG9hZGVkIG1ldGhv
ZHMgYXMKc2hvd24gaW4gdGhlIHNhbXBsZXMgKHRvZG8pLiBUaGVyZSdzIHN0aWxsIHNvbWUgd29y
ayB0byBiZSBkb25lIHdpdGgKdGhlIG92ZXJsb2FkZWQgZnVuY3Rpb25zLCBsaWtlIHN0YXRpYyBm
dW5jdGlvbnMgZG9uJ3Qgd29yaywgYnV0IEkKZG9uJ3QgZm9yc2VlIGFueXRoaW5nIHRoYXQgc2hv
dWxkIG1ha2UgaXQgaW1wb3NzaWJsZS4KCj4gPj4gU3VnZ2VzdGVkIHJ1bGVzIGZvciByZW5hbWlu
ZzoKPiA+PiAxKSBNb3N0ICJjb21tb25seSB1c2VkIiBvciBkZWZhdWx0IGZ1bmN0aW9uIGdldHMg
YWN0dWFsIG5hbWUKPiA+PiAyKSBGdW5jdGlvbiBuYW1lcyB1c2UgdGhlIG9yaWdpbmFsIG5hbWUg
KyBbV2l0aF1bRGF0YSB0eXBlXQo+ID4+IGV4LiBBcHBlbmQoaW50IG4pLCBBcHBlbmQod3hTdHJp
bmcgcykgLT4gQXBwZW5kU3RyaW5nKHMpCj4gPj4gZXguIEFwcGVuZChpbnQgbiksIEFwcGVuZChp
bnQgbiwgU3R1ZmYgcykgLT4gQXBwZW5kV2l0aFN0dWZmKG4sIHMpCj4gPj4gMykgQ2xhc3MgY29u
c3RydWN0b3JzIHN0YXJ0IHdpdGggdGhlIENsYXNzTmFtZSArIEZyb21bRGF0YSB0eXBlXQo+ID4+
IERlZmF1bHQgY29uc3RydWN0b3JzIGFyZSBhbHdheXMgd3hDbGFzc05hbWVEZWZhdWx0KCkKPiA+
PiBDb3B5IGNvbnN0cnVjdG9ycyBhcmUgYWx3YXlzIHd4Q2xhc3NOYW1lQ29weShjb25zdCB3eENs
YXNzTmFtZSYgYykKPiA+Pgo+ID4+IE9idmlvdXNseSB0aGVyZSB3aWxsIGJlIGV4Y2VwdGlvbnMg
b3IgY2FzZXMgd2hlcmUgdGhlIG5hbWUgbWF5IHNvdW5kCj4gPj4gYXdrd2FyZCwgYnV0IHRoZSBu
dW1iZXIgb2YgdGhlc2Ugd2lsbCBiZSBzbWFsbC4KPiA+IEkgYWdyZWU6IGJldHRlciBmb2xsb3cg
YSB1bmlxdWUgcmF0aW9uYWwgcnVsZS4gVGhpcyB3aWxsIHJlZHVjZSB0aGUKPiA+IG51bWJlciBv
ZiB0aW1lcyB0aGUgdXNlciBpcyBmb3JjZWQgdG8gbG9vayBpbiB0aGUgbWFudWFsIHRvIGZpbmQg
dGhlCj4gPiByaWdodCBuYW1lIG9mIGEgZnVuY3Rpb24uCgpHb29kLCBJJ20gZ2xhZCB5b3UgYWdy
ZWUuIEFnYWluLCBmb3IgdGhlIG1vc3QgcGFydCB0aGV5IGZvbGxvdyB0aGUKYWJvdmUgInJ1bGVz
IiwgYnV0IHRoZXJlJ3Mgc29tZSBvZGRiYWxscy4KCj4gPj4gSG9wZWZ1bGx5IHlvdSBjYW4gc2Vl
IHRoYXQgdGhlIG5hbWluZyByaWdodCBub3cgY2FuIGJlIGZhaXJseQo+ID4+IGFyYml0cmFyeSwg
d2hlcmUgdGhlIGRlZmF1bHQgd3hJbWFnZSBjb25zdHJ1Y3RvciBtYWtlcyBhIGNvcHk/Cj4gPj4g
d3hFbXB0eUltYWdlPyB3eERlZmF1bHRJbWFnZT8gVGhlIGRlZmF1bHQgZm9yIHd4Qml0bWFwIHRh
a2VzIHRoZQo+ID4+IGJpdG1hcCBkYXRhIGl0c2VsZiwgYnV0IG9ubHkgZm9yIE1TVywgaG93IHVz
ZWZ1bCBpcyB0aGF0Pwo+ID4+Cj4gPj4gSSB3b3VsZCBsaWtlIHRvIG5vcm1hbGl6ZSBhbGwgb2Yg
dGhlc2UsIG9idmlvdXNseSBicmVha2luZwo+ID4+IGNvbXBhdGliaWxpdHksIGJ1dCBiZXR0ZXIg
c29vbmVyIHRoYW4gbGF0ZXIuIDopIFRoZXJlJ3MgcHJvYmFibHkgYWJvdXQKPiA+PiAyIGRvemVu
IG9mIHRoZW0gdG8gY2hhbmdlLgo+ID4gSSBhZ3JlZSB0aGF0IHRoaXMgc2hvdWxkIGJlIGRvbmUg
YXMgc29vbiBhcyBwb3NzaWJsZS4KCk5leHQgd2VlaywgSSdtIG9mZiBmb3IgdGhlIHdlZWtlbmQu
Cgo+IEkgd2FzIG5hbWluZyBteSBweXRob24gYmluZGluZ3MgKHdpdGggc3dpZykgbGlrZSB3eFB5
dGhvbi4gQnV0Cj4gZm9yIGx1YSBJJ20gbm90IGR1cGxpY2F0aW5nIGZ1bmN0aW9ucyBmb3IgZXZl
cnkgZGlmZmVyZW50IHBhcmFtczsKPiBJJ20gY2hlY2tpbmcgdGhlbSBpbiB3cmFwcGluZyBmdW5j
dGlvbnMuIEknbSB1c2luZyBsdW5hLiBTbyBhbGwKPiB3cmFwcGluZyBpcyBoYW5kIG1hZGUgOikK
Pgo+IEV4OiBpbiBDKysgOiBTZW5kKGludCksIFNlbmQod3hTdHJpbmcpLCBTZW5kKGludCwgaW50
KSwuLi4KPiBiZWNvbWVzIGluIEx1YTogU2VuZCguLi4pCj4KPiBCdXQgSSBkb24ndCBrbm93IGhv
dyBzb21ldGhpbmcgbGlrZSB0aGF0IGNhbiBiZSBnZW5lcmF0ZWQgYXV0b21hdGljYWxseS4KPiBE
b2VzIHRvTHVhIGhhbmRsZSBvdmVybG9hZGVkIGZ1bmN0aW9ucz8KCkR1bm5vLCB3eEx1YSB1c2Vz
IGl0J3Mgb3duIHdyYXBwaW5nIG1lY2hhbmlzbSBmb3IgYmV0dGVyIG9yIHdvcnNlLgpQcm9iYWJs
eSBmb3IgdGhlIGJldHRlciBzaW5jZSB3ZSBoYXZlIGNvbnRyb2wgb3ZlciBpdCBhbmQgdGhlcmUn
cyBhCmZldyB0aGluZyBpbiB3eFdpZGdldHMgdGhhdCB3ZSBoYXZlIHRvIGhhbmRsZSBzcGVjaWFs
bHksIGxpa2Ugd3hXaW5kb3cKZGVyaXZlZCBjbGFzc2VzLgoKaHR0cDovL3d4bHVhLnNvdXJjZWZv
cmdlLm5ldC9kb2NzL2JpbmRpbmcuaHRtbApodHRwOi8vd3hsdWEuc291cmNlZm9yZ2UubmV0L2Rv
Y3Mvd3hsdWFyZWYuaHRtbAoKUmVnYXJkcywKICAgIEpvaG4gTGFiZW5za2kK

Re: [Wxlua-users] Re: Function naming conventions (follow wxPython or our own way)

[Hakki D. <dog...@tr...>]

Hi,

Francesco Montorsi yazmış:
> John Labenski ha scritto:
>> In going through the the interface files I've noticed that there are a
>> few naming inconsistencies for C++ overloaded functions and
>> constructors. Typically they have the names that wxPython uses (where
>> noted in the docs) and for the most part are fine, but...
>>
>> Since we can overloaded function in wxLua directly (usually) we don't
>> actually need to give them unique names, however they need some sort
>> of name for the C function and might as well be accessible in wxLua
>> using that name as well as the overloaded way.
> however I'm not sure that having two possible names (e.g. InsertItem and 
> InsertItemString) for the same functions (in lua scripts) is a good 
> thing: it probably means there will be scripts with a messy mix of the 
> two...
> 
>> Suggested rules for renaming:
>> 1) Most "commonly used" or default function gets actual name
>> 2) Function names use the original name + [With][Data type]
>> ex. Append(int n), Append(wxString s) -> AppendString(s)
>> ex. Append(int n), Append(int n, Stuff s) -> AppendWithStuff(n, s)
>> 3) Class constructors start with the ClassName + From[Data type]
>> Default constructors are always wxClassNameDefault()
>> Copy constructors are always wxClassNameCopy(const wxClassName& c)
>>
>> Obviously there will be exceptions or cases where the name may sound
>> awkward, but the number of these will be small.
> I agree: better follow a unique rational rule. This will reduce the 
> number of times the user is forced to look in the manual to find the 
> right name of a function.
> 
> 
>> Hopefully you can see that the naming right now can be fairly
>> arbitrary, where the default wxImage constructor makes a copy?
>> wxEmptyImage? wxDefaultImage? The default for wxBitmap takes the
>> bitmap data itself, but only for MSW, how useful is that?
>>
>> I would like to normalize all of these, obviously breaking
>> compatibility, but better sooner than later. :) There's probably about
>> 2 dozen of them to change.
> I agree that this should be done as soon as possible.
> 
> Francesco
> 
> 

I was naming my python bindings (with swig) like wxPython. But
for lua I'm not duplicating functions for every different params;
I'm checking them in wrapping functions. I'm using luna. So all
wrapping is hand made :)

Ex: in C++ : Send(int), Send(wxString), Send(int, int),...
becomes in Lua: Send(...)


But I don't know how something like that can be generated automatically.
Does toLua handle overloaded functions?



--
Regards,
Hakki Dogusan

[Wxlua-users] Re: Function naming conventions (follow wxPython or our own way)

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
> In going through the the interface files I've noticed that there are a
> few naming inconsistencies for C++ overloaded functions and
> constructors. Typically they have the names that wxPython uses (where
> noted in the docs) and for the most part are fine, but...
> 
> Since we can overloaded function in wxLua directly (usually) we don't
> actually need to give them unique names, however they need some sort
> of name for the C function and might as well be accessible in wxLua
> using that name as well as the overloaded way.
however I'm not sure that having two possible names (e.g. InsertItem and 
InsertItemString) for the same functions (in lua scripts) is a good 
thing: it probably means there will be scripts with a messy mix of the 
two...

> Suggested rules for renaming:
> 1) Most "commonly used" or default function gets actual name
> 2) Function names use the original name + [With][Data type]
> ex. Append(int n), Append(wxString s) -> AppendString(s)
> ex. Append(int n), Append(int n, Stuff s) -> AppendWithStuff(n, s)
> 3) Class constructors start with the ClassName + From[Data type]
> Default constructors are always wxClassNameDefault()
> Copy constructors are always wxClassNameCopy(const wxClassName& c)
> 
> Obviously there will be exceptions or cases where the name may sound
> awkward, but the number of these will be small.
I agree: better follow a unique rational rule. This will reduce the 
number of times the user is forced to look in the manual to find the 
right name of a function.


> Hopefully you can see that the naming right now can be fairly
> arbitrary, where the default wxImage constructor makes a copy?
> wxEmptyImage? wxDefaultImage? The default for wxBitmap takes the
> bitmap data itself, but only for MSW, how useful is that?
> 
> I would like to normalize all of these, obviously breaking
> compatibility, but better sooner than later. :) There's probably about
> 2 dozen of them to change.
I agree that this should be done as soon as possible.

Francesco

[Wxlua-users] Re: SSH host key changed?

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
> On 5/18/06, Francesco Montorsi 
> <f18...@ya...> wrote:
>> Hi,
>>    today my SSH client says that the RSA key fingerprint for the CVS
>> server is
>>
>>     13:f1:65:c3:6c:b7:7e:a5:f0:f3:f5:19:f4:42:9c:4a
>>
>> I had to delete the "offending" line from my
>> /home/frm/.ssh/known_hosts... does anyone got the same message ?
>>
>> Or I've really been subject to a "man-in-the-middle attack" as SSH 
>> says ? ;)
> 
> The key changed for wxcode as well, so I guess SF changed machines and
> didn't copy the old key?
seems so... (that sounded a bit strange for me given how much SF cares 
about security - I couldn't even find a news on SF website about this 
change)

Francesco

Re: [Wxlua-users] SSH host key changed?

[John L. <jla...@gm...>]

On 5/18/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>    today my SSH client says that the RSA key fingerprint for the CVS
> server is
>
>     13:f1:65:c3:6c:b7:7e:a5:f0:f3:f5:19:f4:42:9c:4a
>
> I had to delete the "offending" line from my
> /home/frm/.ssh/known_hosts... does anyone got the same message ?
>
> Or I've really been subject to a "man-in-the-middle attack" as SSH says ? ;)

The key changed for wxcode as well, so I guess SF changed machines and
didn't copy the old key?

-John Labenski

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
> On 5/17/06, Francesco Montorsi 
> <f18...@ya...> wrote:
>> Hi,
>>     I'm experimenting with wx module and I've got a few proposals for it:
>>
>> 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
>> isn't it ? Shouldn't then go in wxLua/samples ?
>> wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?
> 
> Eh... I think these are pretty specialized. But, you're probably
> right, once things work they should be moved. I just put them into the
> dir where I generated the shared lib since I was having trouble with
> the paths for require.
Ok, another thing which now comes to my mind: "luamodule" directory 
should probably be moved too, in wxLua/modules. In fact, it does not 
build any application at all, just a .so/.dll

BTW: I'd organize the thing as:
-> wx.so/dll is always placed in wxLua/lib (even if, in Unix, you're 
building from a different build folder, e.g. wxLua/mybuild)

-> luamodule.wx.lua sample uses
package.cpath = ";;../lib/?.so;..\lib\?.dll"
before the call to require("wx")

-> on Unix, wx.so is installed in  $prefix/lib/lua/5.1

Now, developers using wxLua which want to ship an application entirely 
written in wxLua, which uses the require("wx") notation, will just need 
to ship:

-> all DLLs/.so of wxLua/lib if they built wxLua as a shared library 
(SHARED=1)
-> wx.so/.dll if they built wxLua as a static library (SHARED=0).
    In fact, wx.so/.dll should be built regardless of the SHARED option 
value: when SHARED==1, it will just be a super-small file which tells 
the OS to load the other .so/.dll libraries; when SHARED==0, it will be 
a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.

What do you think ?

Francesco

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

Ray Gilbert ha scritto:
> Being able to set LUA_PATH from within lua script is does not work with 5.1
> 
> I hacked code to look for LUA_PATH in our version of loadlib.c - but it only uses it for pname of "path" i.e. .lua files.
> 
> You could change loadlib.c code to
> 
>   /* Make 5.0 compatible to allow global LUA_PATH to be set from LUA */
>   if (strcmp(pname, "path") == 0 || strcmp(pname, "cpath") == 0) {
> 						^^^^^^^^^^^^^^^^^^^^^^^^^^^
>       lua_getfield(L, LUA_GLOBALSINDEX, LUA_PATH);
> 
> 
> so that it will pick up "cpath" libraries 
thanks for the tip but I'd prefer not to modify the loadlib.c code - 
specially because I've solved this problem with package.cpath ;)

BTW, why was this LUA_PATH change added ?
It would be great if we could use the verbatim lua 5.1 distribution in 
modules/lua...

Thanks!
Francesco