1. EuGTK - GtkDrawingArea

/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?

new topic     » topic index » view message » categorize

2. Re: EuGTK - GtkDrawingArea

Jerry_Story said...

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.

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

3. Re: EuGTK - GtkDrawingArea

? 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.

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

4. Re: EuGTK - GtkDrawingArea

------------------------------------------------------------- 
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.

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

5. Re: EuGTK - GtkDrawingArea

irv said...
------------------------------------------------------------- 
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()

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

6. Re: EuGTK - GtkDrawingArea

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 

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

7. Re: EuGTK - GtkDrawingArea

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)

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

8. Re: EuGTK - GtkDrawingArea

Jerry_Story said...

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 
new topic     » goto parent     » topic index » view message » categorize

9. Re: EuGTK - GtkDrawingArea

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.

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

10. Re: EuGTK - GtkDrawingArea

Jerry_Story said...

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.

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

11. Re: EuGTK - GtkDrawingArea

DerekParnell said...

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

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

12. Re: EuGTK - GtkDrawingArea

mattlewis said...

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.

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

13. Re: EuGTK - GtkDrawingArea

DerekParnell said...
mattlewis said...

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

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

14. Re: EuGTK - GtkDrawingArea

mattlewis said...
DerekParnell said...
mattlewis said...

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.

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

15. Re: EuGTK - GtkDrawingArea

DerekParnell said...
mattlewis said...

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

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

Search



Quick Links

User menu

Not signed in.

Misc Menu