1. wxEuphoria 3.1.0 alpha1 - Project Leviathan

We're back!!!

I've been trying to get this project off the ground for three years and I finally have something that builds and runs and is easily extensible. If you're wondering where I've been or why other things haven't gotten much of my attention (like iup4eu) then well, this is it. I had enough downtime over the holiday season to power through the tough parts to lay out the groud work and work out the kinks of building a new wxEuphoria library from scratch.

What is Project Leviathan?

This project is an all new library written from the ground up to supercede the previous version at SourceForge.net. Such an effort is not without its challenges of course. For one thing, this library is completely incompatible with the original, but the new design makes developing with and for wxEuphoria easier than ever before. We also plan to keep this version up to date with wxWidgets as new releases are made available upstream.

What's up with that project name?

This is inspired by the wxPython's Project Phoenix. The name is synonymous with a thing that is very large or powerful and the word evokes the sense of overwhelming effort and danger involved with the attempt tackle a project of this scale.

Why not update and extend the old library?

Matthew Lewis, the original author of wxEuphoria, did a great job on that library and we owe him a great deal of credit for his efforts. The very core of this new library is still based on his code. However, as time has moved on, the old library fell further behind the release of wxWidgets, which made it difficult to bring into the modern age. We used this as an opportunity to bring the whole thing up to date with modern tools.

What can I do with this so far?

Not much right now. Head over to the releases page to download the complete library. You can create a frame, a panel, and a button, and connect the "on click" handler to the button. Please make sure the installers work on your system and that the provided demo (C:\Euphoria\demo\wx\demo.ex) runs correctly.

Do I have to compile anything?

Nope! That's the beauty of it. Everything is baked right in! Just run the installer and away you go!

How can I help out?

The two best things you can do right now are, 1) test the releases as they're made available and 2) provide feedback or suggestions on the state and direction of the library. We've got a long way to go and your feedback will be crucial to the future of the library. Please create an issue for bug reports and feature suggestions. Keep general discussion to this forum.

Can I use this with Euphoria 3.1.x or 4.0.x?

No. This is not supported. Please do not try to do this. Bad things will happen.

Edit: Swapped order of thread title. I think it's better to lead with "wxEuphoria" for clarity.

-Greg

new topic     » topic index » view message » categorize

2. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

Wow! Sounds great!

I'll download and start some testing.

Who's "we?" grin

new topic     » goto parent     » topic index » view message » categorize

3. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

Test on VM win10

Demo works!

Nice Work!

_tom

new topic     » goto parent     » topic index » view message » categorize

4. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

euphoric said...

Wow! Sounds great!

I'll download and start some testing.

Who's "we?" grin

I like to think this is a project of multiple people. Fake it 'til ya make it, amiright?

_tom said...

Test on VM win10

Demo works!

Nice Work!

_tom

Excellent! We're off to a good start!

-Greg

new topic     » goto parent     » topic index » view message » categorize

5. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

ghaberek said...

Can I use this with Euphoria 3.1.x or 4.0.x?

No. This is not supported. Please do not try to do this. Bad things will happen.

Ditto Phix sad

Just 3 days ago, however, ChrisB enlightened me with the somewhat stunning revelation that euwingui works just fine on Phix by using (a copy of) the standard OpenEuphoria definitions of E_ATOM and E_SEQUENCE, despite the fact that Phix has absolutely no comprehension whatsoever of either, all through the magic of euconvertinc.e/euconvert.dll - it does mean that all parameters and return values are shunted through strings/value(), but it definitely works.

There would doubtlessly be other issues, but I hope it is worth considering a similar mechanism (extended if/as needed with E_INTEGER and E_OBJECT) for this project.

Pete

For reference, this thread covers the original inception of euconvert: http://openeuphoria.org/forum/113569.wc

It has also occurred to me that while this may slow things down, it may also solve some allocate/free issues that you have not yet discovered.

new topic     » goto parent     » topic index » view message » categorize

6. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

petelomax said...

There would doubtlessly be other issues, but I hope it is worth considering a similar mechanism (extended if/as needed with E_INTEGER and E_OBJECT) for this project.

It has also occurred to me that while this may slow things down, it may also solve some allocate/free issues that you have not yet discovered.

Thanks for the feedback Pete. I had considered writing the wrapper libraries as "pure" implementation using only const char*, int, double, etc. or even trying to appropriate wxC for Euphoria. Ultimately, I returned to Matt's original method* of "speaking" natively with Euphoria objects to and from the C++ library.

I need to mind my P's and Q's with proper dereferencing and once I get Linux builds working I'll have valgrind on my side to help curb memory issues. Do you know of any outstanding memory issues with the original wxEuphoria? Did it work with Phix? Can we make this work?

* Those who remember the earliest days of wxEuphoria may know that Matt's original method was to unmangle and calls directly into the wxWidgets class methods.

-Greg

new topic     » goto parent     » topic index » view message » categorize

7. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

ghaberek said...

Do you know of any outstanding memory issues with the original wxEuphoria?

No (as per that thread I mentioned I expect there will be times when wxdll:free() must be invoked instead of free(), and that sort of thing)

[EDIT] Actually, with the new or old, if you have sequence s = wxdll:somefunc(), then some time later the refcount of s drops to zero, I predict it will invoke the wrong free().

ghaberek said...

Did it (the original wxEuphoria) work with Phix?

No

ghaberek said...

Can we make this work?

Not if the abstraction bleeds internal (4.1-specific) implementation details. (see that thread for why I am saying that)

Pete

new topic     » goto parent     » topic index » view message » categorize

8. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

petelomax said...

No (as per that thread I mentioned I expect there will be times when wxdll:free() must be invoked instead of free(), and that sort of thing)

[EDIT] Actually, with the new or old, if you have sequence s = wxdll:somefunc(), then some time later the refcount of s drops to zero, I predict it will invoke the wrong free().

I've read through that thread a few times now, and I've poured over the source code for Phix, especially pHeap.e and pcfunc.e.

But what I'm still trying to understand is how there is a "wrong" free() and a "right" free(). Don't the process and its loaded libraries share a common heap?

So if I call HeapAlloc() in the library and then later call HeapFree() in the interpreter, that would still be the "right" free(), correct?

Side note: For those who aren't aware, on Windows the functions HeapAlloc(), et al. are aliased as malloc(), etc. using macros:

#ifdef WXEUMSW 
#define malloc(n) HeapAlloc((void *)default_heap, 0, n) 
#define free(p) HeapFree((void *)default_heap, 0, p) 
#define realloc(p, n) HeapReAlloc((void *)default_heap, 0, p, n) 
#endif 

petelomax said...
ghaberek said...

Did it (the original wxEuphoria) work with Phix?

No

From what I see, there's no support in Phix for Euphoria-built shared libraries, which is what wxEuphoria is pretending to be. Please correct me if I'm wrong there.

petelomax said...
ghaberek said...

Can we make this work?

Not if the abstraction bleeds internal (4.1-specific) implementation details. (see that thread for why I am saying that)

It seems to me that there are a few options to make wxEuphoria work with Phix:

  • Get Phix to "speak Euphoria" to a shared library. Given that its internal representation of objects is altogether different, I doubt that's likely to occur.
  • Get wxEuphoria to "speak plain C" with just const char*, int, double, etc. This requires more effort in the Euphoria binding code.

-Greg

new topic     » goto parent     » topic index » view message » categorize

9. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

ghaberek said...

I'm still trying to understand is how there is a "wrong" free() and a "right" free().

I tried to write an answer to that, and struggled. cry But I think I finally got there.

ghaberek said...

Don't the process and its loaded libraries share a common heap?

Erm, usually, but there is also HeapCreate to consider... You could probably mandate the use of a common heap, though, so let's just say yep.

ghaberek said...

So if I call HeapAlloc() in the library and then later call HeapFree() in the interpreter, that would still be the "right" free(), correct?

Yes, that would always be fine (HeapAlloc and HeapFree are guaranteed to be dynamically linked, since they only exist in kernel32.dll).
I was thinking of the sort of problems that pHeap.e (statically linked) introduces.
On re-examining be_alloc.c I now see that any potential issues with the (Windows-only) cache are rendered pretty insignificant by CACHE_LIMIT.
I had based most of my arguments on a runaway bleed of dll alloc->exe cache or exe alloc->dll cache, but I think these days anyone can live with 4000 (small) allocs they might never get back.
OTOH, were malloc (ie clib, glibc or whatever) statically linked, I simply cannot imagine how they have side-stepped the flaws I've put in pHeap.e, but I rather suspect they have, otherwise the internet would be chock-full of disgruntled programmers moaning about it. Oh wait - there are actually quite a few, eg http://stackoverflow.com/questions/35072500 (first comment on the question, and third paragraph of the first answer) and strangely I have completely failed to prove my point on Windows, yet half-proved it on Linux. Anyway, definitely the sort of thing I meant by a "wrong" free() and a "right" free().

Maybe I should just man up and put pHeap.e in a dll/so, which ceases to be an issue for any app that needs wx.dll, wx.so, iup.dll, libiup.so, or similar anyway.
I might even be capable of using a statically linked pHeap if no dll/so exists (moan about that when opening the above), and perhaps incorporate any needed multi-threading locks into the dynamic one.
Not that any of that, by itself, manages to address any of the fundamental compatibility issues here though, you understand.

ghaberek said...

From what I see, there's no support in Phix for Euphoria-built shared libraries

Yes, almost exactly the same problem that euconvert fixed: Eu3.1 could not support Eu4.0 dlls and Eu4.0 could not support Eu3.1 dlls.

Quite independently of and quite some time before all this, I have unilaterally decreed that any Phix-built dlls should be callable from C etc, not just Phix.

ghaberek said...

It seems to me that there are a few options to make wxEuphoria work with Phix:

  • Get wxEuphoria to "speak plain C" with just const char*, int, double, etc. This requires more effort in the Euphoria binding code.

I know there are overheads, and it is a Phix (and Eu<=4.0) problem, but that would help.

Regards,
Pete

PS: Apart from the obvious three years of effort you do not want to throw away (I get that, I really do), I'd be interested to hear of any other reasons why you are pushing ahead with this mammoth task instead of cutting your losses and going with the pretty much done and dusted IUP.

new topic     » goto parent     » topic index » view message » categorize

10. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

petelomax said...

OTOH, were malloc (ie clib, glibc or whatever) statically linked, I simply cannot imagine how they have side-stepped the flaws I've put in pHeap.e, but I rather suspect they have, otherwise the internet would be chock-full of disgruntled programmers moaning about it. Oh wait - there are actually quite a few, eg http://stackoverflow.com/questions/35072500 (first comment on the question, and third paragraph of the first answer) and strangely I have completely failed to prove my point on Windows, yet half-proved it on Linux. Anyway, definitely the sort of thing I meant by a "wrong" free() and a "right" free().

Thanks for the explanation. After reading everything and musing over the code for Euphoria and Phix again, I think understand now.

petelomax said...

Quite independently of and quite some time before all this, I have unilaterally decreed that any Phix-built dlls should be callable from C etc, not just Phix.

I find that commendable. I appreciate that about Go but not much else (I still can't compel myself to use Go).

petelomax said...

I know there are overheads, and it is a Phix (and Eu<=4.0) problem, but that would help.

I'm not that far in. I can at least give it a go to see how feasible it would be. I was also thinking that the initialization function for the library could accept the callback addresses for the internal memory functions and then performs all of its memory activities that way. What are your thoughts on this?

petelomax said...

PS: Apart from the obvious three years of effort you do not want to throw away (I get that, I really do), I'd be interested to hear of any other reasons why you are pushing ahead with this mammoth task instead of cutting your losses and going with the pretty much done and dusted IUP.

IUP has its uses but I find it lacking in too many ways. It put a lot of work into trying to use IUP with Euphoria and just kept on feeling like I was coming up short. I think the library really hits a brick wall when fails to have a proper ListView implementation. In the end, I just really like Euphoria and I really like wxWidgets and I really want them to get along. Consider it a passion project.

-Greg

new topic     » goto parent     » topic index » view message » categorize

11. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

ghaberek said...

I'm not that far in. I can at least give it a go to see how feasible it would be.

Excellent.

ghaberek said...

I was also thinking that the initialization function for the library could accept the callback addresses for the internal memory functions and then performs all of its memory activities that way. What are your thoughts on this?

Hmm. That puts me on the spot. It sounds reasonable and I might dare say there should be no real difference between exposing internals and providing externals. However I am slightly concerned it might feel a bit awkward, or worse introduce some low level fiddleiness, especially for any Phix/OpenEuphoria code that you want to compile into a dll/so. My gut feeling says that if it can be done without either, that would be my choice, but I might be missing something.

ghaberek said...

I think the library really hits a brick wall when fails to have a proper ListView implementation.

I appreciate the other points you made, but just in case, demo\pGUI\listview.exw does the detailed-list-with-sortable-columns thing I need, but there is indeed nothing similar to a thumbnail view.

Pete

new topic     » goto parent     » topic index » view message » categorize

12. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

petelomax said...
ghaberek said...

I think the library really hits a brick wall when fails to have a proper ListView implementation.

I appreciate the other points you made, but just in case, demo\pGUI\listview.exw does the detailed-list-with-sortable-columns thing I need, but there is indeed nothing similar to a thumbnail view.

I looked at that but it's actually a good example of what's turned me off from IUP.

This code just looks ugly to me. And it's not your fault, IUP forces this syntax on you.

I just can't make their ALL CAPS ATTRIBUTE SYNTAX sit comfortably in my head.

procedure main() 
    IupOpen() 
 
    IupSetHandle(LB, IupLoadImage("lightbulb.png")) 
 
    matrix = IupMatrix() 
    IupSetInt(matrix, "NUMCOL", length(titles)) 
    IupSetInt(matrix, "NUMCOL_VISIBLE", length(titles)) 
    IupSetInt(matrix, "NUMLIN", MAX) 
    IupSetInt(matrix, "NUMLIN_VISIBLE", 15) 
--  IupSetInt(matrix, "WIDTHDEF", 40) -- (now completely overidden anyway) 
    for i=1 to length(twidth) do 
        IupSetIntId(matrix, "RASTERWIDTH", i, twidth[i]) 
        IupSetAttributeId(matrix, "ALIGNMENT", i, talign[i]) 
    end for 
    --IMPORTANT: HEIGHT0 tells IupMatrix that we are gonna have column titles at line 0 
    IupSetInt(matrix, "HEIGHT0", 10); 
--  IupSetInt(matrix, "WIDTH0", NULL);  -- (no help) 
    IupSetAttribute(matrix, "RESIZEMATRIX", "YES"); 
    IupSetAttribute(matrix, "MARKMODE", "LIN"); 
    IupSetAttribute(matrix, "MARKAREA", "CONTINUOUS"); 
--DEV does not seem to work... 
--  IupSetAttribute(matrix, "MULTIPLE", "YES"); -- (or is that "MARKMULTIPLE"? the default is NO anyway) 
 
--  IupSetAttribute(matrix, "READONLY", "YES"); -- with VALUE_CB set, non-setting of VALUE_EDIT_CB (also) makes it read-only 
    IupSetAttribute(matrix, "HIDEFOCUS", "YES"); 
    IupSetAttribute(matrix, "FRAMECOLOR", "220 220 220"); 
--  IupSetAttribute(matrix, "FRAMEVERTCOLOR*:1", "255 255 255") 
    IupSetAttribute(matrix, "BORDER", "NO"); 
    IupSetAttribute(matrix, "CURSOR", "ARROW"); 
    IupSetAttribute(matrix, "TYPE*:1", "IMAGE"); 
 
    IupSetCallback(matrix, "VALUE_CB",      Icallback("value_cb")) 
    IupSetCallback(matrix, "ENTERITEM_CB",  Icallback("enteritem_cb")); 
    IupSetCallback(matrix, "CLICK_CB",      Icallback("click_cb")); 
 
    statusbar = IupLabel(buildDummyData()); 
    IupSetAttribute(statusbar, "EXPAND", "HORIZONTAL"); 
    IupSetAttribute(statusbar, "PADDING", "10x5"); 
 
    Ihandle vbox = IupVbox({matrix, 
                            statusbar}); 
 
    Ihandle dlg = IupDialog(vbox) 
    IupSetAttribute(dlg, "TITLE", "IupMatrix in Callback Mode"); 
    IupSetCallback(dlg, "RESIZE_CB", Icallback("resize_cb")); 
    IupSetCallback(dlg, "K_ANY", Icallback("key_cb")); 
    IupShow(dlg) 
 
    IupMainLoop() 
    IupClose() 
end procedure 

-Greg

new topic     » goto parent     » topic index » view message » categorize

13. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

ghaberek said...

I just can't make their ALL CAPS ATTRIBUTE SYNTAX sit comfortably in my head.

That could be fixed, with the caveat that attributes would become case insensitive, such that "title" and "TITLE" and "Title" refer to the same thing.

new topic     » goto parent     » topic index » view message » categorize

14. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1

petelomax said...
ghaberek said...

I was also thinking that the initialization function for the library could accept the callback addresses for the internal memory functions and then performs all of its memory activities that way. What are your thoughts on this?

Hmm. That puts me on the spot. It sounds reasonable and I might dare say there should be no real difference between exposing internals and providing externals. However I am slightly concerned it might feel a bit awkward, or worse introduce some low level fiddleiness, especially for any Phix/OpenEuphoria code that you want to compile into a dll/so. My gut feeling says that if it can be done without either, that would be my choice, but I might be missing something.

After pouring through the Euphoria and Phix source code for memory allocation, I think the best method to approach first is the one I described here. It requires the fewest changes to my existing code (not that there's much to change) and still allows wxEuphoria to accept and return Euphoria objects, which really streamlines the code. It's much easier to hand-assemble Euphoria objects in C that it is to allocate memory and build structures by hand in Euphoria. I will try this and report back.

Edit: this seems to be working well enough so far. Even works when translated. pleased

-Greg

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu