1. Yay for me, found an interpreter bug!
so, now all I have to do is write a quite large work-around for it.
Running the 2.4 Interpreter :
namespacebugtest.e :
atom mynumber
mynumber = 10
global procedure changemynumber(atom number)
mynumber = number
end procedure
global procedure devide(atom number)
?(number/mynumber)
end procedure
include get.e
include namespacebugtest.e as TEST1
include namespacebugtest.e as TEST2
object foobar
TEST1:changemynumber(5)
TEST2:changemynumber(0)
puts(1,"If it prints 1, then the interpreter works, if it crashes, then
it's broken.\n")
TEST1:devide(5)
foobar = wait_key()
I guess I'll have to do what I was really hoping not to do, to create a
_2 copy of the include file. Problem with that is, the real file is like
500 lines of buggy code which needs fixing on a daily basis :(
2. Re: Yay for me, found an interpreter bug!
----- Original Message -----
From: "Urzumph" <Urzumph at HotPOP.com>
To: "Mailing List" <EUforum at topica.com>
Subject: Yay for me, found an interpreter bug!
>
>
> so, now all I have to do is write a quite large work-around for it.
>
> Running the 2.4 Interpreter :
>
> namespacebugtest.e :
>
> atom mynumber
> mynumber = 10
>
> global procedure changemynumber(atom number)
> mynumber = number
> end procedure
>
> global procedure devide(atom number)
> ?(number/mynumber)
> end procedure
>
> include get.e
> include namespacebugtest.e as TEST1
> include namespacebugtest.e as TEST2
> object foobar
>
> TEST1:changemynumber(5)
> TEST2:changemynumber(0)
> puts(1,"If it prints 1, then the interpreter works, if it crashes, then
> it's broken.\n")
> TEST1:devide(5)
>
> foobar = wait_key()
>
> I guess I'll have to do what I was really hoping not to do, to create a
> _2 copy of the include file. Problem with that is, the real file is like
> 500 lines of buggy code which needs fixing on a daily basis :(
>
This is not a bug. This behaviour is documented. What you end up with is that
TEST1 and TEST2 are aliases for the same global routines. Whenever you include a
file more than once, the second and subsequent includes are NOT actually
included, but the namespace qualifier just becomes an alias.
--
Derek
3. Re: Yay for me, found an interpreter bug!
On Sun, 02 Nov 2003 10:17:55 +1000, Urzumph <Urzumph at HotPOP.com>
wrote:
<snip>
As already said, it is doing what it should.
This will do what you want, or is there something much more difficult
about your 500-line program this approach cannot be used on?
Pete
namespacebugtest.e :
sequence mynumber
mynumber = {10,10}
global procedure changemynumber(integer instance, atom number)
mynumber[instance] = number
end procedure
global procedure devide(integer instance, atom number)
?(number/mynumber[instance])
end procedure
include get.e
include namespacebugtest.e
object foobar
changemynumber(1,5)
changemynumber(2,0)
puts(1,"If it prints 1, then it works, if it crashes, then it's
broken.\n")
devide(1,5)
foobar = wait_key()
Pete
4. Re: Yay for me, found an interpreter bug!
----- Original Message -----
From: "Al Getz" <Xaxo at aol.com>
To: <EUforum at topica.com>
Subject: RE: Yay for me, found an interpreter bug!
>
> Hi Pete,
>
> Really, saying it's doing what it 'should' be doing is like
> saying 'routine_id' is doing what it should be doing too.
> We already know it might be documented etc.
>
> Yes, you can say it's doing what it 'should' be doing, but
> you cant say it's doing what it 'could' be doing.
> It 'could' be including as a new file under a new file prefix,
> AND what it's doing now 
>
However, you can get it to work as you'd like to , namely including the file
twice. All you have to do is place a copy of the include file in two different
folders and include it thus ...
include one\namespacebugtest.e as TEST1
include two\namespacebugtest.e as TEST2
and this will work just fine then. That is, you will have two instances of the
local variables defined in the include file.
A kludge, but it works.
--
Derek
5. Re: Yay for me, found an interpreter bug!
On Sunday 02 November 2003 12:22 pm, you wrote:
>
>
> Sorry for all who have tested this, I didn't test it before posting.
> I meant slash instead of backslash.
>
> So:
>
> include namespacebugtest.e as TEST1
> include ./namespacebugtest.e as TEST2
> include ././namespacebugtest.e as TEST3
> include ./././namespacebugtest.e as TEST4
>
> It works on both eu 2.3 and eu 2.4.
Unfortunately, this doesn't work on Linux. Neither does copying the file into
a separate directory. Nor does putting quotes around the include names help
any. The only thing that works is changing the filename or extension.
This, to me, is a significant bug. There is no reason files test1.e and
/anotherdir/test1.e should be treated as the same file. Perhaps they are
completely different. Perhaps they are two completely different libraries
written by two different people, but I want to utilize both in my program.
Preferably without further confusing the issue by changing the names of other
peoples' work.
-- test1.e (and test1.x) contains:
global atom x
x = 0
-- end of test1.e
-- here's the main program;
include test1.e as one
include ./test1.e as two
include ./anotherdir/test1.e as three
include ./anotherdir/test1.x as four
one:x = 1
two:x = 2
three:x = 3
four:x = 4
? one:x
? two:x
? three:x
? four:x
-- Results:
3
3
3
4
So much for 'namespacing'.
Irv
6. Re: Yay for me, found an interpreter bug!
When Euphoria includes a file, it checks to see
if a file with the same name has already been included.
It only looks at the file *name*, not the full path.
Maybe I should document this better.
If you have:
include graphics.e
and later, perhaps in a different file you have:
include c:\euphoria\include\graphics.e
it will ignore the second include. Of course the two
files might be quite different. It doesn't look at
their contents. You could argue that a file should
be assumed to be different if it's in a different
directory. Euphoria doesn't work that way. There are pros
and cons to either approach. I don't think this
issue comes up very often.
On DOS/Windows it assumes that the file name is
the part that comes after the last backslash.
On Linux/FreeBSD it looks for the forward slash.
There is a small bug on DOS/Windows,
since on DOS/Windows you can also usually get away
with using forward slashes in file names.
To be consistent I should probably look for
both slashes on DOS/Windows.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: Yay for me, found an interpreter bug!
On Monday 03 November 2003 07:12 pm, Aku wrote:
> How about using links in Linux? I haven't tried it (no linux installed
> here), but maybe something like this can work:
Aku, you are a genius!
-- my include file, test.e, contains:
-- global atom x
-- x = 0
system("ln test.e test.one",0) -- create links 'on the fly'
system("ln test.e test.two",0)
include test.one as one
include test.two as two
? one:x
? two:x
one:x = 1
two:x = 2
? one:x
? two:x
Results:
0
0
1
2
And this works without error, even if the links exist already. Even error
reporting works properly.
I changed test.e to make x a sequence, i..e:
global sequence x
x = "HELLO"
and here's the output from ex.err:
test.exu:17
type_check failure, x is 1
Global & Local Variables
test.one:
x = 1
test.two:
x = {72'H',69'E',76'L',76'L',79'O'}
Regards,
Irv
8. Re: Yay for me, found an interpreter bug!
On Tuesday 04 November 2003 10:19 am, I wrote:
> On Monday 03 November 2003 07:12 pm, Aku wrote:
> > How about using links in Linux? I haven't tried it (no linux installed
> > here), but maybe something like this can work:
>
> Aku, you are a genius!
A followup, to which Rob should pay attention:
I am writing a little Personal Info Manager in Euphoria / GTK.
It uses a notebook with (at present) two pages, page 1 contains a
daily schedule (a list control), page 2 contains another list control with
contacts (name, addr, phone...). There will probably be more pages and
lists later.
The individual include files to manage a list with its associated pop-up
menus, edit boxes, etc. each required more than 165 lines of code.
If there are eventually 5 lists, that means 800-1000 lines of code
in 5 different files to wade thru when fixing bugs, or adding
features.
Using Aku's idea, I created a single 'generic' include to manage all the
lists, 190 lines. So I've already saved a good bit of coding, and when I
add more lists, I will get them basically for free - there will still be only
a singe, generic file to edit and test. Each 'instance' of the included code
maintains its own set of variables (for example, the currently selected row),
each edit window looks different with different text and entry fields, and
each accesses its own table in the database, even though they all use a
single, common procedure for each of those tasks. All of this is extremely
useful.
Please note the operative word: *useful*
Regards,
Irv
9. Re: Yay for me, found an interpreter bug!
On Tue, 4 Nov 2003 16:52:32 -0500, Irv Mullins <irvm at ellijay.com>
wrote:
>A followup, to which Rob should pay attention:
Irv, can you explain to me the difficulties of changing (I'm guessing
here), eg getRow() to getRow(instance), and getTable() to
GetTable(instance)?
As I started with my last reply to Al, I'm not *anti* anything, just
engaging in discussion.
Do you have any thoughts on extra difficulties this might cause when
debugging, for instance? Equally, any thoughts on "getting lost" when
debugging because you're looking at the wrong "copy of" the
source/variables? How would you really know?
Thanks,
Pete
10. Re: Yay for me, found an interpreter bug!
eww, this means that I shouldn't have any libs that are named the same as
you have done.
hence, I shouldn't have a folder named, oh, unkmar. and in that folder have
a file named.
I don't know, file.e because if I use my file.e then I can't use yours.
(hiss) - How awful of you. so now you are telling us to have some cryptic
filenames.
I can have unkfile.e but shouldn't have file.e
I can see now that, when I finally manage to get the time to peel myself out
of Euphoria,
that I won't likely look back in quite so much a positive light. :(
Lucius L. Hilley III - Unkmar
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: <EUforum at topica.com>
Sent: Monday, November 03, 2003 06:59 PM
Subject: Re: Yay for me, found an interpreter bug!
>
>
> When Euphoria includes a file, it checks to see
> if a file with the same name has already been included.
> It only looks at the file *name*, not the full path.
> Maybe I should document this better.
>
> If you have:
>
> include graphics.e
>
> and later, perhaps in a different file you have:
>
> include c:\euphoria\include\graphics.e
>
> it will ignore the second include. Of course the two
> files might be quite different. It doesn't look at
> their contents. You could argue that a file should
> be assumed to be different if it's in a different
> directory. Euphoria doesn't work that way. There are pros
> and cons to either approach. I don't think this
> issue comes up very often.
>
> On DOS/Windows it assumes that the file name is
> the part that comes after the last backslash.
> On Linux/FreeBSD it looks for the forward slash.
>
> There is a small bug on DOS/Windows,
> since on DOS/Windows you can also usually get away
> with using forward slashes in file names.
>
> To be consistent I should probably look for
> both slashes on DOS/Windows.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
11. Re: Yay for me, found an interpreter bug!
On Tuesday 04 November 2003 06:52 pm, Pete wrote:
> Irv, can you explain to me the difficulties of changing (I'm guessing
> here), eg getRow() to getRow(instance), and getTable() to
> GetTable(instance)?
If I understand your idea correctly, yes.
I want to write an include which can manage, for example, three database
tables, displayed in three different list formats, with three different pop-up
menus, and edited with three different edit windows.
Using instance variables, I would need to write the include so that it would
have an array of tables {"CONTACTS","SCHEDULES","TODO"}
an array of pointers to the proper list controls (different tables need their
own lists with different list headers) an array of integers to hold the
currently-selected row of each list, an array of entry fields, so that the
contents of the correct fields would be transferred into the database at the
conclusion of an edit, an array of titles for those entry fields, so they
would appear with meaningful labels, an array of buttons and the functions
that they call, etc.
Every time I added a new table and list, I would have to expand all those
arrays. Plus, there would need to be a lot of if ... then coding to choose
the correct buttons, correct labels, correct entry fields to use, depending
upon the "instance" being called.
Then there's the problem of duplicate controls. For example, almost all
windows will have an "OK" button. But the same "OK" button can't be used
in more than one window, so I would have to declare separate "OK" buttons,
one for each instance *at the time I write the include*.
Compare the method that Aku suggested:
I can write the one include, just as if it was intended to manage only one
table and its associated controls. No array mess. Then, by including it
multiple times, I get multiple, independent instances of everything. And
those instances are accessible using standard namespacing, i.e.
contacts:list, schedule:current_selection, contacts:okbutton, etc.
> As I started with my last reply to Al, I'm not *anti* anything, just
> engaging in discussion.
>
> Do you have any thoughts on extra difficulties this might cause when
> debugging, for instance? Equally, any thoughts on "getting lost" when
> debugging because you're looking at the wrong "copy of" the
> source/variables? How would you really know?
I don't believe that would be a problem.
As I mentioned earlier, the ex.err message seems clear, it even shows the
(mulltiple) instances of the variable in question.
Irv
--
Windows 98 is *NOT* a virus - viruses are small and efficient.
