OpenEuphoria

1. 'trace(1)' doesnt work under Eu 2.5 Source?

• Posted by Al Getz <Xaxo at aol.com> Dec 22, 2004
• 720 views

Hi there,

I have created a simple program with a loop that simply prints
the numbers 1 to 20, but before that i have (exw file) the lines:

with trace
trace(1)

Now when i open with v2.4 the interp goes to the line right after
the line 'trace(1)'.  When i open with v2.5 PD same thing.

The problem is, when i open from a dos box with the command line:

exw_25 eu.ex Test01.exw

The program prints out the numbers 1 to 20 but never traces.

Is there something different about the 'Source Eu Interp' ?

I also noticed that with a larger program with lots of routine id's
i get an 'Invalid routine id' error, but with the full v2.4 and PD v2.5
the program runs just fine.


Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"

3. Re: 'trace(1)' doesnt work under Eu 2.5 Source?

• Posted by Al Getz <Xaxo at aol.com> Dec 22, 2004
• 640 views

Matt Lewis wrote:
> 
> Al Getz wrote:
> > 
> > Now when i open with v2.4 the interp goes to the line right after
> > the line 'trace(1)'.  When i open with v2.5 PD same thing.
> 
> <snip>
> 
> > Is there something different about the 'Source Eu Interp' ?
> 
> Rob didn't implement trace (other than trace(3)) into the pd source.
> If you take a look at my modified interpreter (in the user contributions), 
> you'll see that I've got an interactive debugger (for Win32 and Linux) 
> using wxEuphoria.  The framework is there so that you could write your 
> own, however.  I think it's more usable than the standard Eu trace screen.
> 
> > I also noticed that with a larger program with lots of routine id's
> > i get an 'Invalid routine id' error, but with the full v2.4 and PD v2.5
> > the program runs just fine.
> 
> I think you mean callbacks.  Rob implemented the source with a limited 
> number of callbacks.  I've added a callback mechanism that can dynamically
> allocate new callbacks using a few lines of asm, so the number of callbacks
> are now unlimited.
> 
> Matt Lewis
> 

Hi matt,

No, it's a routine id error im getting.

You'll have to be more specific about your program ie what's the 
name that appears in the archive list so i can look it up?
So you're saying that the debugger can be modified to provide
other output screens/windows/var lists, etc. during interactive
trace ?

Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"

5. Re: 'trace(1)' doesnt work under Eu 2.5 Source?

• Posted by Al Getz <Xaxo at aol.com> Dec 23, 2004
• 659 views

Matt Lewis wrote:
> 
> Al Getz wrote:
> > 
> > No, it's a routine id error im getting.
> 
> How many routine_id's are you using?  I just tried a dummy program with
> 10,000 routine_id's, and it worked.  What is the exact error you're getting?
> 
> > You'll have to be more specific about your program ie what's the 
> > name that appears in the archive list so i can look it up?
> > So you're saying that the debugger can be modified to provide
> > other output screens/windows/var lists, etc. during interactive
> > trace ?
> > 
> 
> Object Oriented Euphoria:
> <a
> href="http://www.rapideuphoria.com/ooeu-1.2.2.zip">http://www.rapideuphoria.com/ooeu-1.2.2.zip</a>
> 
> I'm saying that you can do whatever you want with it.  It currently allows
> you to do everything that RDS' trace does, plus more, like examining any
> part of any file (as long as it has 'with trace', otherwise the line is
> tossed out), and setting and removing breakpoints anywhere, dynamically.
> 
> Matt Lewis
> 

Hey there Matt,

The exact error message is "invalid routine id".
The file being run is "Demo_08_Basic.exw" that comes with the
WinClass library.
The error seems to occur due to a call to
-> function Wm_GETMINMAXINFO(atom ID, atom hWnd, atom uMsg, atom wParam, atom
lParam)
which is on line 647 in the file 'MessageMap.ew'...here's the routine:

function Wm_GETMINMAXINFO(atom ID, atom hWnd, atom uMsg, atom wParam, atom
lParam)
return
  call_func(Track:Events[ID][onGetMinMaxInfo],{ID,hWnd,uMsg,wParam,lParam})
end function
WMsg[#024]=routine_id("Wm_GETMINMAXINFO")

Now when i change it to print out the routing id like so:

function Wm_GETMINMAXINFO(atom ID, atom hWnd, atom uMsg, atom wParam, atom
lParam)
  ?Track:Events[ID][onGetMinMaxInfo]
return
  call_func(Track:Events[ID][onGetMinMaxInfo],{ID,hWnd,uMsg,wParam,lParam})
end function
WMsg[#024]=routine_id("Wm_GETMINMAXINFO")

it prints a numerical zero (0) which of course indicates it's trying
to call_func routine id 0, the first routine id.
This is very interesting that it says '0' is invalid, because that's
the first routine id picked by the interp (right ?) and yet the
program was able to call the function which is only accessable through
a call to a higher routine id number -->routine_id("Wm_GETMINMAXINFO")<--

There's no problem when run from v2.4 (full version) or v2.5 PD non-source
version.  The problem only occurs when using the Source code
in the Source directory of the PD download for v2.5 by calling from
the command line:
exw_25 eu.ex Demo_08_Basic.exw

(exw_25 is of course Igor's idea of renaming the v2.5 interp so that
either interp could be run).

I've copied all of the new include files to the directory and
even tried renaming by Euphoria25 directory to Euphoria and still
the same error, which doesnt occur with the actual

I've also tried running exw_25 directly from the command line:

exw_25 testonly.exw

and that worked too (testonly.exw=Demo_08_Basic.exw, renamed)


The above stated problem is completely repeatable, in that it
occurs every single time.

BTW, I also have an Eu environment var set to tell Euphoria that the
WinClass library is under the directory "Euphoria\Include\WinClass"
but i think if all the files are put in the same directory as the
source exw file it runs just as well.



Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"

7. Re: 'trace(1)' doesnt work under Eu 2.5 Source?

• Posted by Robert Craig <rds at RapidEuphoria.com> Dec 23, 2004
• 646 views

Derek Parnell wrote:
> I noticed that there is an inconsistancy between ex.exe and eu.ex.
> 
> ex.exe has routine ids starting from 0.
> eu.ex  has routine ids starting from 1.
> 
> Both return -1 for a bad routine_id() call though.
> 
> So a value of 0 is invalid for eu.ex and its derivatives.

I noticed that too. I'm going to change eu.ex to use 0 as the
starting point for routine id's, so it will be the same as ex.exe etc.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

9. Re: 'trace(1)' doesnt work under Eu 2.5 Source?

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Dec 23, 2004
• 652 views

Al Getz wrote:
> 
> Matt Lewis wrote:
> > 
> > Al Getz wrote:
> > > 
> > > No, it's a routine id error im getting.
> > 
> > How many routine_id's are you using?  I just tried a dummy program with
> > 10,000 routine_id's, and it worked.  What is the exact error you're getting?
> > 
> > > You'll have to be more specific about your program ie what's the 
> > > name that appears in the archive list so i can look it up?
> > > So you're saying that the debugger can be modified to provide
> > > other output screens/windows/var lists, etc. during interactive
> > > trace ?
> > > 
> > 
> > Object Oriented Euphoria:
> > <a
> > href="http://www.rapideuphoria.com/ooeu-1.2.2.zip">http://www.rapideuphoria.com/ooeu-1.2.2.zip</a>
> > 
> > I'm saying that you can do whatever you want with it.  It currently allows
> > you to do everything that RDS' trace does, plus more, like examining any
> > part of any file (as long as it has 'with trace', otherwise the line is
> > tossed out), and setting and removing breakpoints anywhere, dynamically.
> > 
> > Matt Lewis
> > 
> 
> Hey there Matt,
> 
> The exact error message is "invalid routine id".
> The file being run is "Demo_08_Basic.exw" that comes with the
> WinClass library.

Just dl'd winclass1004.zip from the User Contributions, and it doesn't 
seem to have this file, and it doesn't seem to be listed in FileList.txt.

How is the routine_id that's supposed to be stored in
Track:Events[ID][onGetMinMaxInfo] gotten, because it sounds like that's 
where the error is.

> The error seems to occur due to a call to
> -> function Wm_GETMINMAXINFO(atom ID, atom hWnd, atom uMsg, atom wParam, atom
> lParam)
> which is on line 647 in the file 'MessageMap.ew'...here's the routine:

This is line 614 in my copy of MessageMap.ew.

Matt Lewis

11. Re: 'trace(1)' doesnt work under Eu 2.5 Source?

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Dec 23, 2004
• 674 views

Al Getz wrote:
> 
> Hi Matt,
> 
> Im very sorry, i was working with version 1005 which hasnt been
> uploaded yet.  The version on the RDS site, version 1004, has
> another file named "Demo_01-Basic.exw" which will trigger the
> exact same error with a slightly different line number (615).
> 
> In any case, i think Derek has identified the problem with the
> Source code and Rob has acknowledged it and has committed to
> updating it to work with routine id's starting at a numerical zero (0)
> rather than how it works now (starting at 1, unlike the official interp's).

Wrong.  You didn't read what I wrote.  I asked where the routine_id was
coming from.  The answer is that it never gets set.  You make an assumption,
that DefRID will always be 0, and use 0, I think, to initialize your event 
handling.  This is bad, and not just because eu.ex doesn't start at 0 
(which, of course, it should, since that's how the real thing does it).   
Your code will also break if the user happens to use routine_id
before DefRID gets set.  In your initialization, you should be using 
DefRID, *not* 0.

> If you'd like to verify this please do.  As mentioned, Demo-01 will
> trigger the same exact error (although wow, the Source takes really
> really long to parse the files! geeze!).

How long does it take you?  Running Demo_01-Basic.exw doesn't seem to
take a noticeably longer time with eu.ex or exwc straight up (of course,
this is on a 2.4GHz, 750MB system).

Matt Lewis

13. Re: 'trace(1)' doesnt work under Eu 2.5 Source?

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Dec 23, 2004
• 643 views

Al Getz wrote:
> 
> Hi again Matt,
> 
> 
> Track:Events[ID][onGetMinMaxInfo] is set to the default routine id at program
> startup.  This is always zero.  In every demo provided there is a note that
> the include statement:
> 
> include GlobalVars.ew
> 
> must be the first statement in the program after normal Eu includes.
> This guarantees that zero (0) is assigned to DefRID so that when
> the system issues a windows message that is not handled by the user
> it's routed to the "DefWindowProc()" allowing the system to provide
> default handling.

OK, I hadn't noticed this.  But even so, if I have, say:

procedure foo()
  ...
end procedure
global constant FOO_ID = routine_id("foo")

include GlobalVars.ew

Or, if I include database.e, a standard Euphoria include file that uses
routine_id at the top level, your code breaks.

> Also, what i was saying before about this is that since a routine
> id which must have been much higher than zero HAD to have been called
> in order to get to that particular function call (and hence the error).
> This of course means that RID=0 had to have been declared SOMEWHERE,
> even if it wasnt the correct function call.  If that zero^th function
> had failed, no routine id would have been issued right?  It's also
> very unlikely that ALL the functions that needed routine id's failed...
> that's the only way there could be no zero^th routine id in existance.

Erm, no.  That was my point.  There was never a routine_id of 0 created.
You're just assuming that DefRID = 0.

> Also, you'll note that the program runs just fine under the standard
> PD v2.5, so why wouldnt you want to blame the 'Source' code?

Yes, except that it's not really the source's fault here.  There's 
nothing in the documentation stating that the first routine_id will 
always be 0.  It just says that if the call to routine_id fails, then
the result will be -1.

You've made an assumption that would normally be safe, especially since 
Rob makes it a point to see that all incarnations of Euphoria act the 
same (interpreted, bound, translated, etc).  However, it's something 
that's really easily broken, and also really easily fixed.  By not 
assuming away the value of DefRID, you'd also be automatically self 
documenting what you're doing when you set up a new ID.

The source code just exposed a weak spot in your design, where DefRID 
*isn't* the first routine_id created.

> Did i understand your comments this time?

Mostly. :)

Matt Lewis