1. wxEuphoria 3.1.0 alpha1 - Project Leviathan
- Posted by ghaberek (admin) Jan 14, 2017
- 1904 views
- Last edited Jan 20, 2017
We're back!!!
What is Project Leviathan?
What's up with that project name?
Why not update and extend the old library?
What can I do with this so far?
Do I have to compile anything?
How can I help out?
Can I use this with Euphoria 3.1.x or 4.0.x?
Edit: Swapped order of thread title. I think it's better to lead with "wxEuphoria" for clarity.
-Greg
2. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by euphoric (admin) Jan 14, 2017
- 1833 views
Wow! Sounds great!
I'll download and start some testing.
Who's "we?"
3. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by _tom (admin) Jan 14, 2017
- 1842 views
Test on VM win10
Demo works!
Nice Work!
_tom
4. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by ghaberek (admin) Jan 14, 2017
- 1834 views
Wow! Sounds great!
I'll download and start some testing.
Who's "we?"
I like to think this is a project of multiple people. Fake it 'til ya make it, amiright?
Test on VM win10
Demo works!
Nice Work!
_tom
Excellent! We're off to a good start!
-Greg
5. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by petelomax Jan 14, 2017
- 1847 views
Can I use this with Euphoria 3.1.x or 4.0.x?
Ditto Phix
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.
6. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by ghaberek (admin) Jan 14, 2017
- 1870 views
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
7. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by petelomax Jan 15, 2017
- 1773 views
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().
Did it (the original wxEuphoria) work with Phix?
No
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
8. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by ghaberek (admin) Jan 16, 2017
- 1752 views
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
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.
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
9. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by petelomax Jan 16, 2017
- 1785 views
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. But I think I finally got there.
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.
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.
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.
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.
10. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by ghaberek (admin) Jan 16, 2017
- 1740 views
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.
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).
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?
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
11. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by petelomax Jan 17, 2017
- 1703 views
I'm not that far in. I can at least give it a go to see how feasible it would be.
Excellent.
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.
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
12. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by ghaberek (admin) Jan 17, 2017
- 1736 views
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
13. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by petelomax Jan 18, 2017
- 1662 views
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.
14. Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by ghaberek (admin) Jan 19, 2017
- 1663 views
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.
-Greg