wxlua-users Mailing List for wxLua

I note that in:

C:\Dev\wxLua-2.8.0.0\modules\wxlua\include\wxldefs.h

the version number is not updated...

#define WXLUA_MAJOR_VERSION      2
#define WXLUA_MINOR_VERSION      6
#define WXLUA_RELEASE_VERSION    3
#define WXLUA_SUBRELEASE_VERSION 0
#define WXLUA_VERSION_STRING    wxT("wxLua 2.6.3")

Regards,

e

-- 
Doug Currie
Londonderry, NH, USA

In the midst of building 2.8.0.0 with wxstedit-1.2.4 with mingw and
msys on WinXP using configure...

When making wxstedit-1.2.4 I ran into the old problem of
wxstedit-1.2.4\samples\stedit\wxstedit.rc  having paths such as
"../../art/pencil.ico" that I must modify to "../art/pencil.ico" to
make the build proceed.

Also, in setup.h if I use:

#define STE_USE_LANG_VB          0 // 8

I get:

./bk-deps g++ -c -o stedit_lib_stelangs.o  -I../include -I/contrib/include -I/usr/local/lib/wx/include/msw-unicode-release-static-2.8 -I/usr/local/include/wx-2.8 -D__WXMSW__ -mthreads  -g0 -O2 .././src/stelangs.cpp
.././src/stelangs.cpp:4475: error: `STE_WordList1_STE_LANG_VB' was not declared in this scope
make: *** [stedit_lib_stelangs.o] Error 1

Also, the Makefile built by configure doesn't have any include path
for windres for wx, so I had to add:

--include-dir /usr/local/include/wx-2.8

at the end of the WINDRES line in the wxstedit_wxstedit_rc.o target

Regards,

e

-- 
Doug Currie
Londonderry, NH, USA

Patches item #1622013, was opened at 2006-12-25 10:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=745326&aid=1622013&group_id=140042

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andre Arpin (andrearpin)
Assigned to: Nobody/Anonymous (nobody)
Summary: editor

Initial Comment:
These changes are to make the editor easier to use to improve it. This should make the editor friendlier. 

Fix a numbers of minor problems.
Added comment toggling
Added sort
Added a more complete find/replace
Added some folding

There is a number of issues that still have to addressed.

Andre

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=745326&aid=1622013&group_id=140042

On 12/24/06, J=E9r=F4me VUARAND <jer...@gm...> wrote:
> 2006/12/24, John Labenski <jla...@gm...>:
> > On 12/24/06, J=E9r=F4me VUARAND <jer...@gm...> wrote:
> > > 2006/12/24, John Labenski <jla...@gm...>:
> > > > What you're suggesting is not normal, it's better to have the syste=
m's
> > > > native mainloop control program flow rather than implementing your =
own
> > > > which will most likely be far less efficient. In any case you shoul=
d
> > > > be able to do it using wxApp::Pending and wxApp::Dispatch.
> > >
> > > wxApp::Pending+wxApp::Dispatch seems to be exactly what I need.
> >
> > You may still want to consider using wxEVT_IDLE though since I think
> > that's what is typically suggested on the C++ wxusers mailing list for
> > doing pseudo-threading like this.
>
> I've tried Pending+Dispatch but that don't seems to work.
> wx.wxGetApp():Pending() never returns true.
>
> The code is :
> wx =3D require("wx")
> dofile(...)
> local use_custom_loop =3D true
> if use_custom_loop then
>     while true do
          while wx.wxGetApp():Pending() do
>             wx.wxGetApp():Dispatch()
>         end

           wx.wxMilliSleep(10) -- adjust as necessary
           wx.wxGetApp():ProcessIdle()

>     end
> else
>     wx.wxGetApp():MainLoop()
> end
>
> The command line is :
> lua bootstrap.lua minimal.wx.lua
>
> Everything works ok if I set my use_custom_loop to false. I'll have a
> look at the internals of MainLoop to see what may be missing. And I
> still need to try the idle event model, though I don't think that will
> match my timing requirement.

I can't test the changes above right now, but take a look at
wxPython's samples/mainloop/mainloop.py program and it's wxApp's
MainLoop function. Hopefully the only problem is that you need to
completely flush the events with the "while wx.wxGetApp():Pending()"
loop and give the event handler a little kick with
wx.wxGetApp():ProcessIdle() every once in a while.

see here and the posts before and after it.
http://lists.wxwidgets.org/archive/wxPython-users/msg07355.html

Regards,
    John Labenski

MjAwNi8xMi8yNCwgSm9obiBMYWJlbnNraSA8amxhYmVuc2tpQGdtYWlsLmNvbT46Cj4gT24gMTIv
MjQvMDYsIErDqXLDtG1lIFZVQVJBTkQgPGplcm9tZS52dWFyYW5kQGdtYWlsLmNvbT4gd3JvdGU6
Cj4gPiAyMDA2LzEyLzI0LCBKb2huIExhYmVuc2tpIDxqbGFiZW5za2lAZ21haWwuY29tPjoKPiA+
ID4gV2hhdCB5b3UncmUgc3VnZ2VzdGluZyBpcyBub3Qgbm9ybWFsLCBpdCdzIGJldHRlciB0byBo
YXZlIHRoZSBzeXN0ZW0ncwo+ID4gPiBuYXRpdmUgbWFpbmxvb3AgY29udHJvbCBwcm9ncmFtIGZs
b3cgcmF0aGVyIHRoYW4gaW1wbGVtZW50aW5nIHlvdXIgb3duCj4gPiA+IHdoaWNoIHdpbGwgbW9z
dCBsaWtlbHkgYmUgZmFyIGxlc3MgZWZmaWNpZW50LiBJbiBhbnkgY2FzZSB5b3Ugc2hvdWxkCj4g
PiA+IGJlIGFibGUgdG8gZG8gaXQgdXNpbmcgd3hBcHA6OlBlbmRpbmcgYW5kIHd4QXBwOjpEaXNw
YXRjaC4KPiA+Cj4gPiB3eEFwcDo6UGVuZGluZyt3eEFwcDo6RGlzcGF0Y2ggc2VlbXMgdG8gYmUg
ZXhhY3RseSB3aGF0IEkgbmVlZC4KPgo+IFlvdSBtYXkgc3RpbGwgd2FudCB0byBjb25zaWRlciB1
c2luZyB3eEVWVF9JRExFIHRob3VnaCBzaW5jZSBJIHRoaW5rCj4gdGhhdCdzIHdoYXQgaXMgdHlw
aWNhbGx5IHN1Z2dlc3RlZCBvbiB0aGUgQysrIHd4dXNlcnMgbWFpbGluZyBsaXN0IGZvcgo+IGRv
aW5nIHBzZXVkby10aHJlYWRpbmcgbGlrZSB0aGlzLgoKSSd2ZSB0cmllZCBQZW5kaW5nK0Rpc3Bh
dGNoIGJ1dCB0aGF0IGRvbid0IHNlZW1zIHRvIHdvcmsuCnd4Lnd4R2V0QXBwKCk6UGVuZGluZygp
IG5ldmVyIHJldHVybnMgdHJ1ZS4KClRoZSBjb2RlIGlzIDoKd3ggPSByZXF1aXJlKCJ3eCIpCmRv
ZmlsZSguLi4pCmxvY2FsIHVzZV9jdXN0b21fbG9vcCA9IHRydWUKaWYgdXNlX2N1c3RvbV9sb29w
IHRoZW4KICAgIHdoaWxlIHRydWUgZG8KICAgICAgICBpZiB3eC53eEdldEFwcCgpOlBlbmRpbmco
KSB0aGVuCiAgICAgICAgICAgIHd4Lnd4R2V0QXBwKCk6RGlzcGF0Y2goKQogICAgICAgIGVuZAog
ICAgZW5kCmVsc2UKICAgIHd4Lnd4R2V0QXBwKCk6TWFpbkxvb3AoKQplbmQKClRoZSBjb21tYW5k
IGxpbmUgaXMgOgpsdWEgYm9vdHN0cmFwLmx1YSBtaW5pbWFsLnd4Lmx1YQoKRXZlcnl0aGluZyB3
b3JrcyBvayBpZiBJIHNldCBteSB1c2VfY3VzdG9tX2xvb3AgdG8gZmFsc2UuIEknbGwgaGF2ZSBh
Cmxvb2sgYXQgdGhlIGludGVybmFscyBvZiBNYWluTG9vcCB0byBzZWUgd2hhdCBtYXkgYmUgbWlz
c2luZy4gQW5kIEkKc3RpbGwgbmVlZCB0byB0cnkgdGhlIGlkbGUgZXZlbnQgbW9kZWwsIHRob3Vn
aCBJIGRvbid0IHRoaW5rIHRoYXQgd2lsbAptYXRjaCBteSB0aW1pbmcgcmVxdWlyZW1lbnQuCg==

On 12/24/06, J=E9r=F4me VUARAND <jer...@gm...> wrote:
> 2006/12/24, John Labenski <jla...@gm...>:
> > What you're suggesting is not normal, it's better to have the system's
> > native mainloop control program flow rather than implementing your own
> > which will most likely be far less efficient. In any case you should
> > be able to do it using wxApp::Pending and wxApp::Dispatch.
>
> wxApp::Pending+wxApp::Dispatch seems to be exactly what I need.
>
> I don't know what your definition of normal is, but my question seems
> perfectly normal to me. What I want to achieve is to have several Lua
> frameworks working together in a single thread (because Lua is not
> thread safe). Each of my frameworks need to be updated several times a
> second, but I can't give application main loop control to any of
> these, so I need to make them cooperate.

Sounds good, I was just using "normal" in the sense that having lua
run the mainloop is a little like having the tail wag the dog. It
sounds like you're doing something a little more advanced though, good
luck.

You may still want to consider using wxEVT_IDLE though since I think
that's what is typically suggested on the C++ wxusers mailing list for
doing pseudo-threading like this.

Regards,
    John Labenski

2006/12/24, John Labenski <jla...@gm...>:
> What you're suggesting is not normal, it's better to have the system's
> native mainloop control program flow rather than implementing your own
> which will most likely be far less efficient. In any case you should
> be able to do it using wxApp::Pending and wxApp::Dispatch.

wxApp::Pending+wxApp::Dispatch seems to be exactly what I need.

I don't know what your definition of normal is, but my question seems
perfectly normal to me. What I want to achieve is to have several Lua
frameworks working together in a single thread (because Lua is not
thread safe). Each of my frameworks need to be updated several times a
second, but I can't give application main loop control to any of
these, so I need to make them cooperate.

Example :

void F1::MainLoop()
{
    bool quit;
    Message message;
    while (message = F1::GetMessage_Blocking())
    {
        F1::ProcessMessage(message);
    }
}

void F2::MainLoop()
{
    bool quit;
    do
    {
        F2::Render();
        quit = F2::ProcessInput();
    } while (!quit);
}

void F3::MainLoop()
{
    bool quit;
    do
    {
        F3::Update();
        if (F3::LastError())
            quit = true;
    } while (!quit);
}

void InterleavedMainLoop()
{
    bool quit = false;
    Message message;
    while (true)
    {
        // Update framework F1
        while (F1::IsMessagePresent())
        {
            message = F1::GetMessage_NonBlocking();
            if (message)
                F1::ProcessMessage();
            else
                quit = true;
        }
        if (quit) break;

        // Update framework F2
        F2::Render();
        quit = F2::ProcessInput();
        if (quit) break;

        // Update framework F3
        F3::Update();
        if (F3::LastError())
            quit = true;
        if (quit) break;

        // Main application control refresh rate
        usleep(10000);
    }
}

Replace F1 with wxLua, F2 with my OpenGL renderer and F3 with john
doe's network framework if that makes things clearer. The basic idea
is that an extension module should not take control of the
application. There are a lot of multi-threaded solution to this kind
of problem, but in some context a full thread control is a big
requirement for an extension module.

On 12/24/06, J=E9r=F4me VUARAND <jer...@gm...> wrote:
> 2006/12/24, Hakki Dogusan <dog...@tr...>:
> > Most of the samples designed for wxLua.exe.
> >
> > You may write a simple bootstrap file, ie:
> >
> >
> > wx =3D require("wx")
> > dofile("wxluasudoku.wx.lua")
> > wx.wxGetApp():MainLoop()
>
> Is there an equivalent of wx.wxGetApp():MainLoop() that is not
> blocking ? It would process all pending messages, and then give back
> control to application. I would then call it from my own frame-based
> main loop.

You have to do all initialization or whatever you need to do before
running the GUI main loop which is always blocking since thats what
the underlying framework does. You can use the wxEVT_IDLE events to do
things continuously by calling event.RequestMore(true), but note that
continuously doing this will use 100% of your processor.

What you're suggesting is not normal, it's better to have the system's
native mainloop control program flow rather than implementing your own
which will most likely be far less efficient. In any case you should
be able to do it using wxApp::Pending and wxApp::Dispatch.

Hope this helps,
    John Labenski