1. baffling allocate error
- Posted by Jerry_Story Sep 19, 2010
- 1270 views
I'm hung up on an error that baffles me.
dmak.exw:5
0074>:: Errors resolving the following references:
./eugtk_stuff/ListView-NutrientsNonREQ.e (5): allocate
./eugtk_stuff/ListView-NutrientsREQ.e (5): allocate
./eugtk_stuff/ListView-Recipes.e (5): allocate
./eugtk_stuff/ListView-Foods.e (5): allocate
./eugtk_stuff/ListView-Diet.e (5): allocate
object iter = allocate(32)
^
All those *.e files are copies of ListView.e from EuGTK.
The dmak.exw:5 line number makes no sense.
PROGRAM_VERSION = "September 18, 2010"
Completely harmless. Clearly this line number is phony.
It looks like Euphoria doesn't know what 'allocate' is, but that doesn't make sense because test33.ex, which uses ListView.e, works.
How can I get a clue about the 'allocate' error?
2. Re: baffling allocate error
- Posted by ne1uno Sep 19, 2010
- 1188 views
It looks like Euphoria doesn't know what 'allocate' is, but that doesn't make sense because test33.ex, which uses ListView.e, works.
on a quick look test33 has, include machine.e should be include std/machine.e you may also need the include std/machine in any file that uses allocate.
3. Re: baffling allocate error
- Posted by jimcbrown (admin) Sep 19, 2010
- 1233 views
I'm hung up on an error that baffles me.
dmak.exw:5
The dmak.exw:5 line number makes no sense.
PROGRAM_VERSION = "September 18, 2010"
Completely harmless. Clearly this line number is phony.
Agreed, it is not a line number but the number of errors that follow.
0074>:: Errors resolving the following references: ./eugtk_stuff/ListView-NutrientsNonREQ.e (5): allocate ./eugtk_stuff/ListView-NutrientsREQ.e (5): allocate ./eugtk_stuff/ListView-Recipes.e (5): allocate ./eugtk_stuff/ListView-Foods.e (5): allocate ./eugtk_stuff/ListView-Diet.e (5): allocate
object iter = allocate(32) ^ }}} All those *.e files are copies of ListView.e from EuGTK.
It looks like Euphoria doesn't know what 'allocate' is, but that doesn't make sense because test33.ex, which uses ListView.e, works.
How can I get a clue about the 'allocate' error?
Looking at http://oe.cowgar.com/forum/112421.wc#112421 it looks like allocate(32) is on line 6 of the various ListView.e's not line 5. I'm not sure how that happened.
Anyways, this is easily solved by adding this line right before the allocate(32) one:
include std/machine.e
4. Re: baffling allocate error
- Posted by irv Sep 19, 2010
- 1133 views
Would it be better if I made the GtkEngine.e include std/machine.e as publicly available?
public include std/dll.e include std/machine.e -- change above line to public include std/machine.e
?
5. Re: baffling allocate error
- Posted by Jerry_Story Sep 19, 2010
- 1153 views
Would it be better if I made the GtkEngine.e include std/machine.e as publicly available?
public include std/dll.e include std/machine.e -- change above line to public include std/machine.e
?
That solves the problem. Thanks.
6. Re: baffling allocate error
- Posted by mattlewis (admin) Sep 19, 2010
- 1187 views
Would it be better if I made the GtkEngine.e include std/machine.e as publicly available?
public include std/dll.e include std/machine.e -- change above line to public include std/machine.e
?
This issue gets a bit philosophical, and I think many people will disagree. Personally, I would only use public includes in your library if the file were part of your library, and expected to be used by end users.
I'm not very familiar with using your GTK library, but a quick glance at some of the demos doesn't appear to require a lot use of low level memory routines like allocate. In this case, it looks like we're talking about extending the library itself, rather than normal usage.
The std/machine.e interface isn't something that's really provided by your library. I'm also a fan of being explicit about what includes any particular file uses, which makes large programs a lot less confusing.
Matt
7. Re: baffling allocate error
- Posted by irv Sep 19, 2010
- 1147 views
- Last edited Sep 20, 2010
OK, problem solved, when I updated the ListView file, it now takes care of allocating. However, I have kept public include std/dll.e, because of the number of call_back(routine_id()) calls, used heavily in end-user code.
Now, speaking of which,it is awkward that routine_id can't look forward.
? twoplus(2) ? routine_id("twoplus") function twoplus(integer x) return x+2 end function
the first call finds the twoplus function and prints 4 the second, can't, and returns -1
This lack of forward looking on the part of routine_id causes a lot of trouble, since it means juggling a lot of code around, and putting routines in places where you'd rather not have them.
