OpenEuphoria

2. Re: Phix+EuGTK

• Posted by _tom (admin) Sep 11, 2019
• 3322 views

EuGtk for Phix uses the Euphoria std/lib a lot. It also seems to use unique Euphoria syntax. Looks like translating euGtk to Phix will take a lot of work.

Console programs will work on Euphoria and Phix.

IUP gui will work on Euphoria and Phix. The wrappers are different but IUP remains the same. (My frustration with IUP is that 32bit Linux is no longer supported.)

JAPI I think will work on Euphoria and Phix. (You need to install Java for this.) The JAPI interface is a bit old looking.

Tcl/tk can be used on Euphoria and Phix. (The tk gui is satisfactory, and it works on 32 bit Linux)

_tom

4. Re: Phix+EuGTK

• Posted by irv Sep 12, 2019
• 3245 views
• Last edited Sep 15, 2019

No. I have tried to convert EuGtk to work with Phix, and got a basic window and button to work, but as noted above, it would be a major job. Different libs, etc.

If I recall correctly, there were some things not yet implemented in phix which were "show stoppers". Those would require writing significant amounts of code to implement and test.

6. Re: Phix+EuGTK

• Posted by irv Dec 05, 2020
• 2653 views

It's been a while, I can't remember what the problem was. However, I would like to see EuGTK work with phix, so I'll give it another try.

8. Re: Phix+EuGTK

• Posted by petelomax Dec 13, 2020
• 2509 views

Works for me, on windows and linux (only tested 64 bit on the latter, 32 and 64 on windows).

I believe there's a thing with the linux kernel... see https://openeuphoria.org/forum/m/134873.wc
On the machine I tested it on, uname -r yields 3.5.0-54-generic, if that helps any.

10. Re: Phix+EuGTK

• Posted by petelomax Dec 14, 2020
• 2470 views
• Last edited Dec 15, 2020

Right. I've now got the same crash (proc not func) on Ubuntu 20.04.1 LTS with a uname -r of 5.4.0-58-generic
building edb...

Some small progress, I think it's this (sort of) thing, from builtins\VM\pcfunc.e, line 308:

        [PE64] 
            mov rcx,rsp -- put 2 copies of rsp onto the stack... 
            push rsp 
            push rcx 
            or rsp,8    -- [rsp] is now 1st or 2nd copy: 
                        -- if on entry rsp was xxx8: both copies remain on the stack 
                        -- if on entry rsp was xxx0: or rsp,8 effectively pops one of them (+8) 
                        -- obviously rsp is now xxx8, whatever alignment we started with 
 
            mov rax,[lib] 
--          mov r15,h4 
            sub rsp,8*5                         -- minimum 4 param shadow space, and align 
            mov rdx,[name] 
            call :%pLoadMint -- (rax:=(int64)rax; rdx preserved) 
            shl rdx,2                           -- lpProcName 
            mov rcx,rax                         -- hModule 
            call "kernel32.dll","GetProcAddress" 
            lea rdi,[addr] 
--          add rsp,8*5 
--          pop rsp 
            mov rsp,[rsp+8*5]   -- equivalent to the add/pop 
            call :%pStoreMint 
        [ELF64] 
            mov rax,[lib] 
            mov rsi,[name] 
            call :%pLoadMint -- (rax:=(int64)rax) 
            shl rsi,2                           -- symbol 
            mov rdi,rax                         -- handle 
            call "libdl.so.2", "dlsym" 
            lea rdi,[addr] 
            call :%pStoreMint 
        [] 

The windows code is aligning the stack, but the Linux code isn't...
There's a movaps instruction which is expecting the stack to be aligned,
and I guess some kernels were built with whatever-compiler-flag it is
that causes it to emit movups instructions instead. And I originally ported
Phix to Linux on such a machine.

Anyway, it's fixed! The above needs to become

        [64] 
            mov rcx,rsp -- put 2 copies of rsp onto the stack... 
            push rsp 
            push rcx 
            or rsp,8    -- [rsp] is now 1st or 2nd copy: 
                        -- if on entry rsp was xxx8: both copies remain on the stack 
                        -- if on entry rsp was xxx0: or rsp,8 effectively pops one of them (+8) 
                        -- obviously rsp is now xxx8, whatever alignment we started with 
 
            mov rax,[lib] 
--          mov r15,h4 
            sub rsp,8*5                         -- minimum 4 param shadow space, and align 
        [PE64] 
            mov rdx,[name] 
            call :%pLoadMint -- (rax:=(int64)rax; rdx preserved) 
            shl rdx,2                           -- lpProcName 
            mov rcx,rax                         -- hModule 
            call "kernel32.dll","GetProcAddress" 
        [ELF64] 
            mov rsi,[name] 
            call :%pLoadMint -- (rax:=(int64)rax) 
            shl rsi,2                           -- symbol 
            mov rdi,rax                         -- handle 
            call "libdl.so.2", "dlsym" 
        [64] 
            lea rdi,[addr] 
--          add rsp,8*5 
--          pop rsp 
            mov rsp,[rsp+8*5]   -- equivalent to the add/pop 
            call :%pStoreMint 
        [] 

and further down, also in builtins\VM\pcfunc.e, line 1115, replace

        if platform()=WINDOWS then 
            if la<5 then 
                args &= repeat(0,5-la) 
                argdefs &= repeat(#01000004,5-la) 
            elsif remainder(la,2)!=1 then 
                args &= 0 
                argdefs &= #01000004    -- (C_INT) 
            end if 
        else -- LINUX 
            if la<6 then 
                args &= repeat(0,6-la) 
                argdefs &= repeat(#01000004,6-la) 
            end if 
        end if 
        #ilASM{ 
            [PE64] 

with

        if platform()=WINDOWS then 
            if la<5 then 
                args &= repeat(0,5-la) 
                argdefs &= repeat(#01000004,5-la) 
                la = 5 
            end if 
        else -- LINUX 
--          if la<6 then 
            if la<7 then 
                args &= repeat(0,7-la) 
                argdefs &= repeat(#01000004,7-la) 
                la = 7 
            end if 
        end if 
        if remainder(la,2)!=1 then 
            args &= 0 
            argdefs &= #01000004    -- (C_INT) 
        end if 
        #ilASM{ 
--14/12/20 
--          [PE64] 
            [64] 

Obviously, a quick './p -c p' and you should be good.

I'll have a quick trawl for other places that need the same treatment.

12. Re: Phix+EuGTK

• Posted by petelomax Dec 15, 2020
• 2427 views

OOPS - those mods seemed fine on linux, but they've spannered me windows tests...

OK, that's better now - I've updated post #11, make sure you've got the replacement with [PE32]/pStoreFlt in it.

14. Re: Phix+EuGTK

• Posted by irv Dec 15, 2020
• 2397 views

Next question: how to create new instances?

constant LIB = open_dll("libgtk-3.so.0") 
constant  
 P = C_PTR, 
 I = C_INT 
  
integer init_rid = define_c_func(LIB,"gtk_init_check",{P,P},P)  
if init_rid < 1 or c_func(init_rid,{0,0})=0 then  
  crash("Failed to initialize GTK library!")  
end if  
 
class Window  
  public atom handle = c_func(define_c_func(LIB,"gtk_window_new",{I},P),{0}) 
  procedure show() 
    c_proc(define_c_proc(LIB,"gtk_widget_show",{P}),{handle}) 
  end procedure 
end class 
 
procedure main()  
c_proc(define_c_proc(LIB,"gtk_main",{}))  
end procedure  
 
Window w1 = new()  
Window w2 = new() 
 
? w1 ? w1.handle 
? w2 ? w2.handle -- same as w1 
 
w1.show()  
w2.show() -- already shown 
 
main() 

{"struct","Window",2,1} 
30917232 
{"struct","Window",2,2} 
30917232 

Both windows have the same "handle". How can I change my code so each call to new() will call the "gtk_window_new" function again to get a new unique handle?

16. Re: Phix+EuGTK

• Posted by irv Dec 15, 2020
• 2391 views

This works to open multiple instances of a class (handles returned by GTK are unique)

constant LIB = open_dll("libgtk-3.so.0") 
constant  
 P = C_PTR, 
 I = C_INT 
 
integer init_rid = define_c_func(LIB,"gtk_init_check",{P,P},P)  
if init_rid < 1 or c_func(init_rid,{0,0})=0 then  
  crash("Failed to initialize GTK library!")  
end if  
 
class Widget 
  public atom handle 
  public integer sigid  
 
  procedure show() 
    c_proc(define_c_proc(LIB,"gtk_widget_show",{P}),{this.handle}) 
  end procedure   
 
  procedure connect(object sig, object fn, object data=0, object closure=0, integer flags=0) 
    integer rid 
    sig = allocate_string(sig) 
    if string(fn) then 
      rid = routine_id(fn)  
      if rid > 0 then 
        fn = call_back(rid) 
        if fn < 1 then  
          crash("Invalid callback for -> %s",{fn}) 
        end if 
      else 
        crash("Can't locate function -> %s",{fn}) 
      end if 
    end if 
    if string(data) then data = allocate_string(data) end if 
    sigid = c_func(define_c_func(LIB,"g_signal_connect_data",{P,P,P,P,P,I},I), 
            {this.handle,sig,fn,data,closure,flags}) 
  end procedure 
 
end class 
 
class Window extends Widget 
  function Window() 
    this.handle = c_func(define_c_func(LIB,"gtk_window_new",{I},P),{0}) 
    return this 
  end function 
 
  procedure title(sequence t) 
    c_proc(define_c_proc(LIB,"gtk_window_set_title",{P,P}),{handle,t}) 
  end procedure 
 
  procedure size(integer w, integer h) 
    c_proc(define_c_proc(LIB,"gtk_window_set_default_size",{P,I,I}),{handle,w,h}) 
  end procedure 
   
end class 
 
function Quit() 
  c_proc(define_c_proc(LIB,"gtk_main_quit",{})) 
return 0 
end function 
 
procedure main()  
c_proc(define_c_proc(LIB,"gtk_main",{}))  
end procedure  
 
-------------------------------------------------------------------- 
 
Window w1 = new()  ? w1.handle 
Window w2 = new()  ? w2.handle 
w1.title("I'm Number One!") 
w2.title("but I'm on top") 
w1.size(500,300) 
w1.connect("destroy","Quit") 
w1.show() w2.show() 
main() 

Window handles:

10781296 
10781968 

18. Re: Phix+EuGTK

• Posted by irv Dec 15, 2020
• 2379 views

Great, thanks.

I'm finding Phix classes really make a difference. I've implemented some of the most used widgets and gotten GTK to display a nice window with a label, image, and a couple of buttons. Looks good, and the coding is much easier.

Of course, there are about 300 more to go.

20. Re: Phix+EuGTK

• Posted by petelomax Dec 16, 2020
• 2334 views

No. There is a table of fields in builtins\structs.e, but it's private, you'd need to faff about with struct_dx() and field_dx() to decipher it, and the delete_routine()'d reference you're after has been given over to your application, and trying to replicate a "fake copy" would no doubt end in tears.

Here's what I'd do:

class window nullable 
    integer handle  
    function get_handle() return handle end function  
end class  
 
integer hdict = new_dict("handle lookup") 
 
function new_window(integer handle) 
    window w = new({handle}) 
    setd(w.get_handle(),w,hdict) 
    return w 
end function 
 
function get_by_handle(integer handle) 
    return getd(handle,hdict) 
end function 
 
function destroy_window(window w) 
    deld(w.get_handle(),hdict) 
    delete(w) 
    return null 
end function 
 
window w = new_window(17) 
 
?w 
?get_by_handle(17) 
 
w = destroy_window(w) 

PS Here's a bugfix to builtins/structs.e, line 536, in case you need it:

--16/12/20: [struct(0)/class(0) and similar should return false, not crash] 
--      elsif s=NULL then 
        elsif s=NULL and rid!=0 then 

22. Re: Phix+EuGTK

• Posted by irv Dec 16, 2020
• 2321 views

Super!

Phix is full of tricks.

And faster than a politician pocketing a bribe

24. Re: Phix+EuGTK

• Posted by petelomax Dec 17, 2020
• 2291 views

Does not really surprise me. With just a quick scan, I spotted this on line 1554 of builtins\VM\pcfunc.e:

                            fstp dword[rsp] 

I'm pretty sure that should be qword. Let me know it if helps.

Ugh. Ignore that. The one on line 1450 is correct, so that's not it.

26. Re: Phix+EuGTK

• Posted by petelomax Dec 17, 2020
• 2257 views

double hello(double x) 

LOL.

Anyway, erm, it will be worth checking what happens when you pass an integer from Phix into a C_DOUBLE.

And then I'd check {1.1,2.2,3.3,4.4,5.5,6.6,7.7,8.8,9.9,10.10} are all present and correct.
Forked into: External functions returning C_DOUBLE are called twice (bug?)

28. Re: Phix+EuGTK

• Posted by irv Jan 27, 2021
• 1853 views

Constructing GTK classes works fine, using the syntax below. What I need to find out is what the deconstructor does i.e. ~Window()

• When or how is it called?
• Do I have to connect every widget's "destroy" signal to call the deconstructor for that class of widget?
• What does it do besides remove the Window instance from the dictionary?

class Window extends Widget   
 
  function Window()   
    this.handle = 17  
    setd(this.handle,this,hdict)  
    return this   
  end function 
   
  procedure ~Window()   
    deld(this.handle,hdict)  
  end procedure   
 
end class  

30. Re: Phix+EuGTK

• Posted by irv Jan 28, 2021
• 1792 views
• Last edited Jan 29, 2021

Ok, this is strange. I had to devise a test to see what is going on. I created a simple window with a label and a button. Click the button, and a dialog pops up. Here's what happens:

"---------- BEFORE ------------"  
hdict before: {24327152,26215072,26239360,26284368,26325424} 
1 24327152 -> {"struct","Label",11,1} 
2 26215072 -> {"struct","Window",7,1} 
3 26239360 -> {"struct","Button",15,1} 
4 26284368 -> {"struct","ButtonBox",12,1} 
5 26325424 -> {"struct","Box",9,1} 
"----------- DIALOG CREATED ------------" 
hdict before: {24327152,26215072,26239360,26284368,26325424} 
hdict now:    {24327152,24328400,24328800,26215072,26239360,26284368,26325424,26325776,28222240} 
1 24327152 -> {"struct","Label",11,1} 
2 24328400 -> {"struct","Label",11,2} 
3 24328800 -> {"struct","Expander",18,1} 
4 26215072 -> {"struct","Window",7,1} 
5 26239360 -> {"struct","Button",15,1} 
6 26284368 -> {"struct","ButtonBox",12,1} 
7 26325424 -> {"struct","Box",9,1} 
8 26325776 -> {"struct","Box",9,2} 
9 28222240 -> {"struct","MessageDialog",17,1} 
"********** DIALOG CLOSED **************" 
Deleting Label 24328400 {"struct","Label",11,2} 
Deleting Box 26325776 {"struct","Box",9,2} 
Deleting Expander 24328800 {"struct","Expander",18,1} 
Deleting Message Dialog 28222240 {"struct","MessageDialog",17,1} 
"========== AFTER =============" 
hdict at start: {24327152,26215072,26239360,26284368,26325424} 
hdict now:      {24327152,26215072,26239360,26284368,26325424} 
1 24327152 -> {"struct","Label",11,1} 
2 26215072 -> {"struct","Window",7,1} 
3 26239360 -> {"struct","Button",15,1} 
4 26284368 -> {"struct","ButtonBox",12,1} 
5 26325424 -> {"struct","Box",9,1} 

So far, so good, the Before and After match, just as it should be. Now for another run, and a different outcome:

"---------- BEFORE ------------" 
hdict before: {23229424,25060000,25395632,25436496,25477504} 
1 23229424 -> {"struct","Label",11,1} 
2 25060000 -> {"struct","Window",7,1} 
3 25395632 -> {"struct","Box",9,1} 
4 25436496 -> {"struct","ButtonBox",12,1} 
5 25477504 -> {"struct","Button",15,1} 
"----------- DIALOG CREATED ------------" 
hdict before: {23229424,25060000,25395632,25436496,25477504} 
hdict now:    {23229424,23230672,23231072,25060000,25395632,25395984,25436496,25477504,27124512} 
1 23229424 -> {"struct","Label",11,1} 
2 23230672 -> {"struct","Label",11,2} 
3 23231072 -> {"struct","Expander",18,1} 
4 25060000 -> {"struct","Window",7,1} 
5 25395632 -> {"struct","Box",9,1} 
6 25395984 -> {"struct","Box",9,2} 
7 25436496 -> {"struct","ButtonBox",12,1} 
8 25477504 -> {"struct","Button",15,1} 
9 27124512 -> {"struct","MessageDialog",17,1} 
"********** DIALOG CLOSED **************" 
Deleting Label 23230672 {"struct","Label",11,2} 
Deleting Box 25395984 {"struct","Box",9,2} 
Deleting Expander 23231072 {"struct","Expander",18,1} 
Deleting Message Dialog 27124512 {"struct","MessageDialog",17,1} 
"========== AFTER =============" 
hdict at start: {23229424,25060000,25395632,25436496,25477504} 
hdict now:      {23229424,25060000,25395632,25436496,25477504} 
1 23229424 -> {"struct","Label",11,1} 
2 25060000 -> {"struct","Label",11,2} -- NOTE: this is the "handle" previously assigned to the main window. 
3 25395632 -> {"struct","Box",9,1} 
4 25436496 -> {"struct","ButtonBox",12,1} 
5 25477504 -> {"struct","Button",15,1} 
?? where's my window gone ?? 

With no change to my program, every run comes out different, with something not deleted that should have been, and something deleted that should not have been. Sometimes it works properly. Sometimes isn't good enough. What to do?

The delete routine for each of the widgets is similar to this one:

procedure ~Label() --(replacing Label here and below with the appropriate class name) 
 printf(1,"Deleting Label %d ",this.handle) ? this   
 deld(this.handle,hdict) 
 this.destroy() 
end procedure 

32. Re: Phix+EuGTK

• Posted by petelomax Jan 28, 2021
• 1768 views

Oops, yesterday I said "when the reference count drops to zero, or when delete(instance) is explicitly invoked" - but I forgot that hdict will stop the refcount ever naturally dropping to zero, so you probably will need explicit delete(instance) calls all hooked up.

34. Re: Phix+EuGTK

• Posted by petelomax Jan 29, 2021
• 1771 views

I am. The good news is I've just reproduced it - and the problem is in either dict.e or structs.e

Update: The problem is somewhere in dict.e

Update: pretty sure this is it, in dict.e routine deleteNode, line 228:

        trees[tid][root+KEY] = key 
--bugfix 29/1/21: 
        trees[tid][root+DATA] = trees[tid][temp+DATA] 

It was copying the key but not the data. I will have to run quite a few more tests, but so far that looks good.

Update: test\t67dicts.exw added: detects it properly if I comment out that fix, no other problems found.

Many thanks for finding a very nasty bug in a critical component!

36. Re: Phix+EuGTK

• Posted by petelomax Jan 29, 2021
• 1719 views
• Last edited Jan 30, 2021

Yes, it's probably better as well as easier and faster to just test it first:

--if Box(bx) then       -- best, if/when you can 
--if struct(bx) then    -- or Widget or whatever (see note below) 
if is_struct(bx,0) then -- (equivalent to struct) 
--if is_struct(bx,Box) then -- same as Box() 
--if is_struct(bx,routine_id("Box")) then -- ditto 
    ?bx.handle 
end if 

However, I think you know this, there will (probably) come a day when it succeeds, because {"struct","Box",5,2} or close enough has been re-created for something else, and you or someone else will sorely wish it hadn't.
Actually, though, there is something I could and should do to improve upon that: implement a new builtin (and use it in is_struct(), and therefore in both struct() and Box() too) [DONE, ready for next release]

bool bRes = still_has_delete_routine(object x) 

I'd still recommend doing everything you can to nullify all delete()'d instance refs/vars, tho.

Update: Added still_has_delete_routine(), used it, and fixed the glitch in using struct() ready for the next release.
I also cleaned up the original comments and added a couple extra options for testing.

Should you hit that struct() bug, the fix is in pmain.e, DoSubScripts() line 6495:

--31/1/21: 
--      integer stype = symtab[N][S_ltype] 
        integer stype = symtab[N][S_vtype]