1. EuGTK - GtkDrawingArea
- Posted by Jerry_Story Oct 10, 2010
- 1343 views
/usr/share/euphoria/include/std/sequence.e:1375 in function vslice() A machine-level exception occurred during execution of this statement
... called from ./eugtk_stuff/GtkEngine.e:188 in function lookup_object_class_from_handle()
... called from ./eugtk_stuff/GtkEngine.e:484 in procedure set()
... called from ./dmak_actions.e:22 in procedure setFoodColors()
This is line 22.
set(drwColorBand1,"modify bg",0,"white")
drwColorBand1 is a GtkDrawingArea.
drwColorBand1 = create(GtkDrawingArea)
This time I'm showing everything with
show_all(Win)
What is wrong with line 22?
2. Re: EuGTK - GtkDrawingArea
- Posted by DerekParnell (admin) Oct 10, 2010
- 1327 views
What is wrong with line 22?
Just guessing, but if vslice() was passed an atom as the source it would crash with a type error. Or if one of the rows in the source to vslice() was actually an atom it would crash also.
3. Re: EuGTK - GtkDrawingArea
- Posted by irv Oct 10, 2010
- 1317 views
? drwColorBand1 set(drwColorBand1,"modify bg",0,"white")
The first thing to do when something goes wrong is to inspect the object handle to see if it's valid.
The first line above should print some large integer, like 151824384. Zero means the object doesn't exist or hasn't been "realized" yet.
I don't suspect that is the problem here, but it's always good (easy too) to check that first.
------------------------------------------------------------- export function lookup_object_class_from_handle(atom handle) ------------------------------------------------------------- ? object_register -- (1) object list = vslice(object_register,1)
The problem seems to be here, so I would add line (1) to your GtkEngine.e file, and see what the object_register looks like.
{ {168724008,35}, {170355912,29}, {170355608,29}, {170355456,29},...
You should get something like the above, a sequence of {handle,id}. Apparently, somewhere along the line, you're getting a bogus atom thrown in there. I can't think how that can happen, because that particular error hasn't ever occurred for me.
Do the above, and post the offending part of the list.
4. Re: EuGTK - GtkDrawingArea
- Posted by irv Oct 10, 2010
- 1335 views
------------------------------------------------------------- export function lookup_object_class_from_handle(atom handle) ------------------------------------------------------------- ifdef LOOK then ? object_register end ifdef object list = vslice(object_register,1) integer x = find(handle,list) if x then ifdef LOOK then printf(1,"LOOKUP OBJ CLASS FROM HANDLE: class: %d handle:%d\n",{x,handle}) end ifdef return object_register[x][CLASS] else return -1 end if end function
Heck, let's do this the easy way - just replace the routine with the code above, and run your program with -d LOOK as a parameter.
5. Re: EuGTK - GtkDrawingArea
- Posted by Jerry_Story Oct 10, 2010
- 1320 views
------------------------------------------------------------- export function lookup_object_class_from_handle(atom handle) ------------------------------------------------------------- ifdef LOOK then ? object_register end ifdef object list = vslice(object_register,1) integer x = find(handle,list) if x then ifdef LOOK then printf(1,"LOOKUP OBJ CLASS FROM HANDLE: class: %d handle:%d\n",{x,handle}) end ifdef return object_register[x][CLASS] else return -1 end if end function
Heck, let's do this the easy way - just replace the routine with the code above, and run your program with -d LOOK as a parameter.
jstory@jstory-desktop:/media/usb1_/projects/eugtk-projects/dmak-gtk$ eui dmak.exw -d LOOK
/usr/share/euphoria/include/std/sequence.e:1375 in function vslice()
A machine-level exception occurred during execution of this statement
... called from ./eugtk_stuff/GtkEngine.e:188 in function lookup_object_class_from_handle()
... called from ./eugtk_stuff/GtkEngine.e:484 in procedure set()
... called from ./dmak_actions.e:22 in procedure setFoodColors()
6. Re: EuGTK - GtkDrawingArea
- Posted by DerekParnell (admin) Oct 10, 2010
- 1299 views
The -d LOOK is an option for eui and not dmak, so use this as the command line ...
jstory@jstory-desktop:/media/usb1_/projects/eugtk-projects/dmak-gtk$ eui -d LOOK dmak.exw
7. Re: EuGTK - GtkDrawingArea
- Posted by Jerry_Story Oct 10, 2010
- 1297 views
Made a mistake. Forgot to copy the changed GtkEngine.e to the project directory.
jstory@jstory-desktop:/media/usb1_/projects/eugtk-projects/dmak-gtk$ eui dmak.exw -d LOOK /usr/share/euphoria/include/std/sequence.e:1375 in function vslice()
A machine-level exception occurred during execution of this statement
... called from ./eugtk_stuff/GtkEngine.e:207 in function lookup_object_class_from_handle()
... called from ./eugtk_stuff/GtkEngine.e:504 in procedure set()
... called from ./dmak_actions.e:22 in procedure setFoodColors()
Line 207 is
object list = vslice(object_register,1)
8. Re: EuGTK - GtkDrawingArea
- Posted by irv Oct 10, 2010
- 1306 views
Line 207 is
object list = vslice(object_register,1)
Well, the 3 lines just before that one should have printed the register. Even if you have only one control declared, like a main window, you'll get something.
If you got nothing, then you must be running your code while object_register is empty = {}.
Which means you're calling your set color routine before any control whatsoever has been created, OR some routine is setting object_register = 0 or {}. Do a grep for object_register, and you'll see there's only one line where the register can be affected, and that line always appends a tuple. Even a 3-line program with one window will trigger a lookup when you set() some property:
include GtkEngine.e constant win = create(GtkWindow) set(win,"modify bg",0,"red")
{ {160861224,35}, {162875392,184} } LOOKUP OBJ CLASS FROM HANDLE: class: 2 handle:162875392
9. Re: EuGTK - GtkDrawingArea
- Posted by Jerry_Story Oct 11, 2010
- 1312 views
The plot thickens.
Sometimes instead of getting an error on line 22, I get an error on line 717.
/usr/share/euphoria/include/std/sequence.e:1375 in function vslice()
A machine-level exception occurred during execution of this statement
... called from ./eugtk_stuff/GtkEngine.e:207 in function lookup_object_class_from_handle()
... called from ./eugtk_stuff/GtkEngine.e:593 in function get()
... called from ./dmak_actions.e:717 in procedure Sort_dlNutrients()
if (gtk:get(MenuNSI,"active") = TRUE) then
This Line 717.
MenuNSI = create(GtkCheckMenuItem,"new_with_label=>Sort normally."),
MenuNSI is a GtkCheckMenuItem.
Apart from line 1375 and line 207, I have no idea what the similarity is.
? drwColorBand1 ? MenuNSI
Both of these produce a large number.
10. Re: EuGTK - GtkDrawingArea
- Posted by DerekParnell (admin) Oct 11, 2010
- 1291 views
The plot thickens.
Sometimes instead of getting an error on line 22, I get an error on line 717.
I suspect it related to a recently discovered bug in v4. The problem is that some top-level variables and constants are not being initialized before the first routine is run. It can be worked around by changing the order of the include files, especially try placing std/memory.e and std/machine.e before std/error.e
We are working on a permanent fix.
11. Re: EuGTK - GtkDrawingArea
- Posted by mattlewis (admin) Oct 11, 2010
- 1286 views
I suspect it related to a recently discovered bug in v4. The problem is that some top-level variables and constants are not being initialized before the first routine is run. It can be worked around by changing the order of the include files, especially try placing std/memory.e and std/machine.e before std/error.e
We are working on a permanent fix.
This is fixed in the current trunk as of svn:3491.
Matt
12. Re: EuGTK - GtkDrawingArea
- Posted by DerekParnell (admin) Oct 11, 2010
- 1305 views
This is fixed in the current trunk as of svn:3491.
Are you saying that svn3491 is the permanent fix? If so, it ain't fixed things! I'm getting the same errors in safe.e, and maybe some other places too.
13. Re: EuGTK - GtkDrawingArea
- Posted by mattlewis (admin) Oct 11, 2010
- 1286 views
This is fixed in the current trunk as of svn:3491.
Are you saying that svn3491 is the permanent fix? If so, it ain't fixed things! I'm getting the same errors in safe.e, and maybe some other places too.
I'm getting an error in t_safe.e (interpreted) and t_literals.e (translating), but I didn't think it was related to that issue.
Matt
14. Re: EuGTK - GtkDrawingArea
- Posted by DerekParnell (admin) Oct 11, 2010
- 1292 views
This is fixed in the current trunk as of svn:3491.
Are you saying that svn3491 is the permanent fix? If so, it ain't fixed things! I'm getting the same errors in safe.e, and maybe some other places too.
I'm getting an error in t_safe.e (interpreted) and t_literals.e (translating), but I didn't think it was related to that issue.
Matt
Yes they are. I got around the safe.e by moving the include files around, but really that is not the best way. A coder should not have to arrange the include files in a particular order just to avoid crashing the application.
15. Re: EuGTK - GtkDrawingArea
- Posted by mattlewis (admin) Oct 11, 2010
- 1243 views
I'm getting an error in t_safe.e (interpreted) and t_literals.e (translating), but I didn't think it was related to that issue.
Yes they are. I got around the safe.e by moving the include files around, but really that is not the best way. A coder should not have to arrange the include files in a particular order just to avoid crashing the application.
Well, yes and no. I agree that the user of a library shouldn't have to rearrange include order, but in this case, there's not really another alternative. It's simply a case of when certain code executes. One statement must be either before or after another. And if statement B must follow statement A, but does not, you'll get an error, like we had here.
Here was the basic issue:
-- file_a.e include file_b.e export constant foo = call_some_function() -- ....code... -- file_b.e include file_a.e ? foo
In this case, if your code includes file_b.e first, it should work, because foo should be initialized before we try to print it. However, if you include file_a.e first, before foo can be initialized, file_b.e is included, and it attempts to use foo.
To fix this:
-- file_a.e export constant foo = call_some_function() include file_b.e -- ....code... -- file_b.e include file_a.e ? foo
...and now, foo is definitely initialized prior to being used in file_b.e, regardless of how those files were included into a program. So I think that as a general practice, top level initializations should be done as soon as possible, and with minimum includes preceding them in the file.
Matt