1. Bug in new get()?
I'm not sure if it's my build process or what. I'm still unable to make
backendw.exe / backendu on Windows or Linux, but I seem to be making exw and exu
just fine and the library just fine.
On both Linux and Windows the linker gives me similar errors while building the
backend:
main-.o: In function `main':
main-.c:(.text+0x84c): undefined reference to `_6upper'
Another problem is that sanity.ex is failing testget() which stems from the
changes to get.e.
Never mind... testget() in sanity.ex is expecting get() to return a sequence of
length two, not four. That'll have to be fixed...
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
2. Re: Bug in new get()?
Jason Gade wrote:
> I'm not sure if it's my build process or what. I'm still unable to make
> backendw.exe
> / backendu on Windows or Linux, but I seem to be making exw and exu just fine
> and the library just fine.
>
> On both Linux and Windows the linker gives me similar errors while building
> the backend:
> main-.o: In function `main':
> main-.c:(.text+0x84c): undefined reference to `_6upper'
>
>
> Another problem is that sanity.ex is failing testget() which stems from the
> changes to get.e.
What changes to get.e? Release 3.1.1 should only be a bug fix release, no?
> Never mind... testget() in sanity.ex is expecting get() to return a sequence
> of length two, not four. That'll have to be fixed...
Regards,
Juergen
3. Re: Bug in new get()?
Jason Gade wrote:
>
> I'm not sure if it's my build process or what. I'm still unable to make
> backendw.exe
> / backendu on Windows or Linux, but I seem to be making exw and exu just fine
> and the library just fine.
>
> On both Linux and Windows the linker gives me similar errors while building
> the backend:
> main-.o: In function `main':
> main-.c:(.text+0x84c): undefined reference to `_6upper'
>
>
> Another problem is that sanity.ex is failing testget() which stems from the
> changes to get.e.
>
> Never mind... testget() in sanity.ex is expecting get() to return a sequence
> of length two, not four. That'll have to be fixed...
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
I cannot check the repository easily now because of https// issues - will do so
in 10 hours when I'm back home -, but I suspect some of your files are out of
sync:
* get.e was changed long ago, and sanity.ex a little later. There is a remote
possibility that I forgot to update the trunk; but you can grab the one at
http://oedoc.free.fr/value_get/sanity.ex , it will work.
* Since I fixed the Same_name() routine, the interpreter no longer uses upper(),
so I'm surprised that you get this compile error. I had some errors at various
points of course, but never this one. And OpenWatcom 1.6 under Windows outputs
exw.exe and ex.exe without an error for me. This is why I suspect you are (the
compiler is) mixing files from different sources somehow.
Perform an svn update of your working copy, clean all *.c/*.obj files and try
again: that may just do the job.
CChris
4. Re: Bug in new get()?
CChris wrote:
>
> Jason Gade wrote:
> >
> > I'm not sure if it's my build process or what. I'm still unable to make
> > backendw.exe
> > / backendu on Windows or Linux, but I seem to be making exw and exu just
> > fine
> > and the library just fine.
> >
> > On both Linux and Windows the linker gives me similar errors while building
> > the backend:
> > main-.o: In function `main':
> > main-.c:(.text+0x84c): undefined reference to `_6upper'
> >
> >
> > Another problem is that sanity.ex is failing testget() which stems from the
> > changes to get.e.
> >
> > Never mind... testget() in sanity.ex is expecting get() to return a sequence
> > of length two, not four. That'll have to be fixed...
> >
> > --
> > A complex system that works is invariably found to have evolved from a
> > simple
> > system that works.
> > --John Gall's 15th law of Systemantics.
> >
> > "Premature optimization is the root of all evil in programming."
> > --C.A.R. Hoare
> >
> > j.
>
> I cannot check the repository easily now because of https// issues - will do
> so in 10 hours when I'm back home -, but I suspect some of your files are out
> of sync:
> * get.e was changed long ago, and sanity.ex a little later. There is a remote
> possibility that
> I forgot to update the trunk; but you can grab the one at <a
> href="http://oedoc.free.fr/value_get/sanity.ex">http://oedoc.free.fr/value_get/sanity.ex</a>
> , it will work.
> * Since I fixed the Same_name() routine, the interpreter no longer uses
> upper(),
> so I'm surprised that you get this compile error. I had some errors at various
> points of course, but never this one. And OpenWatcom 1.6 under Windows outputs
> exw.exe and ex.exe without an error for me. This is why I suspect you are (the
> compiler is) mixing files from different sources somehow.
>
> Perform an svn update of your working copy, clean all *.c/*.obj files and try
> again: that may just do the job.
>
> CChris
Well, I've been doing an svn update before doing any other work whatsoever, and
I'm working with the trunk.
And yes I've been cleaning all of my *.o/*.obj/*.s/*.c files every time as well.
I find I have to do so manually, though. Not a big issue.
I noticed the copyright in get.e from the trunk is 2006 and 3.0 instead of 2007
and 3.1.
I can only build at home so that will be about another 9-10 hours or so from the
time of posting this message.
Juergen -- yeah, I'm working with the sourceforge stuff. Sorry! I haven't tried
the 3.1.1 release version yet.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
5. Re: Bug in new get()?
Jason Gade wrote:
<snip>
> Juergen -- yeah, I'm working with the sourceforge stuff. Sorry! I haven't
> tried
> the 3.1.1 release version yet.
Ooops. Since Rob recently had announced the Euphoria 3.1.1 Release
Candidate for Linux, I mixed it up. Sorry!
Regards,
Juergen
6. Re: Bug in new get()?
Christian: I just compared your copy of sanity.ex with sourceforge/trunk. I
didn't do a diff, but they seem to be the same.
In procedure testget(), the local sequence variable results needs to be changed
to reflect the extra two returned elements from your new get() routine.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
7. Re: Bug in new get()?
CChris wrote:
>
> Jason Gade wrote:
> >
> > I'm not sure if it's my build process or what. I'm still unable to make
> > backendw.exe
> > / backendu on Windows or Linux, but I seem to be making exw and exu just
> > fine
> > and the library just fine.
> >
> > On both Linux and Windows the linker gives me similar errors while building
> > the backend:
> > main-.o: In function `main':
> > main-.c:(.text+0x84c): undefined reference to `_6upper'
> * Since I fixed the Same_name() routine, the interpreter no longer uses
> upper(),
> so I'm surprised that you get this compile error. I had some errors at various
> points of course, but never this one. And OpenWatcom 1.6 under Windows outputs
> exw.exe and ex.exe without an error for me.
> CChris
Okay, I think you gave me a clue here. You changed the *.lnk files to remove
wildcard.o/wildcard.obj, right? You should really do a log comment when you
commit changes...
I'm not having a problem building exw or exu (I haven't tried ex yet -- I didn't
download the DOS bits to Open Watcom) I'm having the problem building
backendw/backendu. Searching quickly through the source finds that backend.ex
uses upper(), not Same_name().
I'll check this out later tonight.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
8. Re: Bug in new get()?
Jason Gade wrote:
>
> CChris wrote:
> >
> > Jason Gade wrote:
> > >
> > > I'm not sure if it's my build process or what. I'm still unable to make
> > > backendw.exe
> > > / backendu on Windows or Linux, but I seem to be making exw and exu just
> > > fine
> > > and the library just fine.
> > >
> > > On both Linux and Windows the linker gives me similar errors while
> > > building
> > > the backend:
> > > main-.o: In function `main':
> > > main-.c:(.text+0x84c): undefined reference to `_6upper'
> > * Since I fixed the Same_name() routine, the interpreter no longer uses
> > upper(),
> > so I'm surprised that you get this compile error. I had some errors at
> > various
> > points of course, but never this one. And OpenWatcom 1.6 under Windows
> > outputs
> > exw.exe and ex.exe without an error for me.
> > CChris
>
> Okay, I think you gave me a clue here. You changed the *.lnk files to remove
> wildcard.o/wildcard.obj, right? You should really do a log comment when you
> commit changes...
>
> I'm not having a problem building exw or exu (I haven't tried ex yet -- I
> didn't
> download the DOS bits to Open Watcom) I'm having the problem building
> backendw/backendu.
> Searching quickly through the source finds that backend.ex uses upper(), not
> Same_name().
>
> I'll check this out later tonight.
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
Thanks for the tip; I'll check this tonight.
Actually, I removed the references to wildcard.* _because_ they were causing
errors, since wildcard.c was no longer output by the front end compilation. So
it's quite interesting that this is causing errors on your end. Search EuForum
for "upper()" or "\"upper\"" in may or june 2007, poster being either CChris or
Rob.
CChris
9. Re: Bug in new get()?
CChris wrote:
>
> Thanks for the tip; I'll check this tonight.
> Actually, I removed the references to wildcard.* _because_ they were causing
> errors, since wildcard.c was no longer output by the front end compilation.
> So it's quite interesting that this is causing errors on your end. Search
> EuForum
> for "upper()" or "\"upper\"" in may or june 2007, poster being either CChris
> or Rob.
>
> CChris
Okay, hopefully we'll be done with this discussion here...
I also found upper() referred to in traninit.e which is used in the translator.
I don't know why it didn't crash...
Oh, and your email box seems to be full (the one listed for you above). Can you
email me an alternate address? Thanks.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
10. Re: Bug in new get()?
Jason Gade wrote:
>
> I'm not sure if it's my build process or what. I'm still unable to make
> backendw.exe
> / backendu on Windows or Linux, but I seem to be making exw and exu just fine
> and the library just fine.
>
> On both Linux and Windows the linker gives me similar errors while building
> the backend:
> main-.o: In function `main':
> main-.c:(.text+0x84c): undefined reference to `_6upper'
I think that some of CChris' changes (or maybe someone elses?) added wildcard.e
to the mix. The translated c files have to be maintained by hand whenever
the generated files change. My make files don't cover the backend, but I
know that I had to add wildcard.c to the makefiles for the translator.
Matt
11. Re: Bug in new get()?
Jason Gade wrote:
>
> CChris wrote:
> >
> > Thanks for the tip; I'll check this tonight.
> > Actually, I removed the references to wildcard.* _because_ they were causing
> > errors, since wildcard.c was no longer output by the front end compilation.
> > So it's quite interesting that this is causing errors on your end. Search
> > EuForum
> > for "upper()" or "\"upper\"" in may or june 2007, poster being either CChris
> > or Rob.
> >
> > CChris
>
> Okay, hopefully we'll be done with this discussion here...
>
> I also found upper() referred to in traninit.e which is used in the
> translator.
> I don't know why it didn't crash...
>
> Oh, and your email box seems to be full (the one listed for you above). Can
> you email me an alternate address? Thanks.
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
sanity.ex was last updated by me, at revision 142, while we are at 180 or so
currently, so you must have been using an old sanity.ex file, not the one in the
trunk.
I just committed a change to backend.ex where I inlined upper() as
and_bits(cl[1],#DF), so the problem you experienced with backendw/u should go
away.
Out of safety, I defined a local upper() in traninit.e as well.
CChris
12. Re: Bug in new get()?
CChris wrote:
> sanity.ex was last updated by me, at revision 142, while we are at 180 or so
> currently, so you must have been using an old sanity.ex file, not the one in
> the trunk.
Well I did a diff between the one in the trunk and the one you linked and they
were the same. I looked at the code and the one you linked has the exact same
problem -- the sequence "results" in procedure "testget()" is wrong for what
get() returns. Check lines 857-891 of sanity.ex.
>
> I just committed a change to backend.ex where I inlined upper() as
> and_bits(cl[1],#DF),
> so the problem you experienced with backendw/u should go away.
>
> Out of safety, I defined a local upper() in traninit.e as well.
>
> CChris
Cool, thanks!
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
13. Re: Bug in new get()?
Okay, I'm writing a stub to test your new get.e with regards to sanity.ex, so I
can fix sanity.ex.
And I'm looking at your docs. I don't quite understand them and I have a change
suggestion.
Your docs say:
get() returns a 4 element sequence, like value() does:
a status code (success/error/end of file),
the value just read (meaningful only when the status code is
GET_SUCCESS),
the number of characters read,
the number of leading whitespace characters.
I'm getting a bunch of 1s, -1s, or 0s for the last two elements. In fact I'm not
getting any other values.
Are these really useful return values? Maybe a different function to read those
last two numbers would be better (state kept in a file variable of course)?
Plus your comment at the top of Get2() doesn't seem to reflect reality: you say
that Get2() will return a 2-element sequence unless record_whitespace flag is
set. Get2() seems to return 4 elements regardless.
I would see more value in returning (in this order) "success or failure",
"sequence of interest", "sequence containing invalid characters until next valid
character (not read)" and "total characters read". And probably not even that, as
I would prefer to see it separated from get(). get()'s pointer, of course, would
point to the next valid character.
So the optimal situation in my opinion would be to leave get() returning a
two-element sequence as now, but add get_leading_whitespace_count(),
get_chars_read(), and get_last_invalid(). Obviously, those names suck, but the
point still stands.
Same for value().
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
14. Re: Bug in new get()?
Jason Gade wrote:
> Okay, I'm writing a stub to test your new get.e with regards to sanity.ex, so
> I can fix sanity.ex.
>
> And I'm looking at your docs. I don't quite understand them and I have a
> change
> suggestion.
>
> Your docs say:
> get() returns a 4 element sequence, like value() does:
> a status code (success/error/end of file),
> the value just read (meaningful only when the status code is
> GET_SUCCESS),
> the number of characters read,
> the number of leading whitespace characters.
>
> I'm getting a bunch of 1s, -1s, or 0s for the last two elements. In fact I'm
> not getting any other values.
>
> Are these really useful return values? Maybe a different function to read
> those
> last two numbers would be better (state kept in a file variable of course)?
>
> Plus your comment at the top of Get2() doesn't seem to reflect reality: you
> say that Get2() will return a 2-element sequence unless record_whitespace flag
> is set. Get2() seems to return 4 elements regardless.
>
> I would see more value in returning (in this order) "success or failure",
> "sequence
> of interest", "sequence containing invalid characters until next valid
> character
> (not read)" and "total characters read". And probably not even that, as I
> would
> prefer to see it separated from get(). get()'s pointer, of course, would point
> to the next valid character.
>
> So the optimal situation in my opinion would be to leave get() returning a
> two-element
> sequence as now, but add get_leading_whitespace_count(), get_chars_read(), and
> get_last_invalid(). Obviously, those names suck, but the point still stands.
>
> Same for value().
Just let get() alone.
Same for value().
Regards,
Juergen
15. Re: Bug in new get()?
Jason Gade wrote:
>
> Okay, I'm writing a stub to test your new get.e with regards to sanity.ex, so
> I can fix sanity.ex.
>
> And I'm looking at your docs. I don't quite understand them and I have a
> change
> suggestion.
>
> Your docs say:
> get() returns a 4 element sequence, like value() does:
> a status code (success/error/end of file),
> the value just read (meaningful only when the status code is
> GET_SUCCESS),
> the number of characters read,
> the number of leading whitespace characters.
>
> I'm getting a bunch of 1s, -1s, or 0s for the last two elements. In fact I'm
> not getting any other values.
>
Indeed get() had a problem which value() did not. A forgotten ! in a != test
DUH! Fixed yesterday night, will commit tonight.
> Are these really useful return values? Maybe a different function to read
> those
> last two numbers would be better (state kept in a file variable of course)?
>
I just contributed an eval library which uses it. It really simplifies some
sorts of murky coding.
> Plus your comment at the top of Get2() doesn't seem to reflect reality: you
> say that Get2() will return a 2-element sequence unless record_whitespace flag
> is set. Get2() seems to return 4 elements regardless.
The comment there was left untouched. Will change this. The docs say the right
thing though (didn't find that line 549-552 in the .htx file - which one?
>
> I would see more value in returning (in this order) "success or failure",
> "sequence
> of interest", "sequence containing invalid characters until next valid
> character
> (not read)" and "total characters read". And probably not even that, as I
> would
> prefer to see it separated from get(). get()'s pointer, of course, would point
> to the next valid character.
For the third item, you mean the exact string that was interpreted? Ok, but bear
in mind that only leading invalid stuff will be seen, only trailing comments
will. Looks good, but perhaps not consistent with the way the functions work.
>
> So the optimal situation in my opinion would be to leave get() returning a
> two-element
> sequence as now, but add get_leading_whitespace_count(), get_chars_read(), and
> get_last_invalid(). Obviously, those names suck, but the point still stands.
Do you really want to have one function for minimal things, one for this item
more, one for this item more and so on? I would vote against this sort of
evolution. Even with acceptably short names, because that's not the issue.
CChris
>
> Same for value().
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
16. Re: Bug in new get()?
I was in a hurry when writing the first reply, some precisions now.
Jason Gade wrote:
>
> Okay, I'm writing a stub to test your new get.e with regards to sanity.ex, so
> I can fix sanity.ex.
>
> And I'm looking at your docs. I don't quite understand them and I have a
> change
> suggestion.
>
> Your docs say:
> get() returns a 4 element sequence, like value() does:
> a status code (success/error/end of file),
> the value just read (meaningful only when the status code is
> GET_SUCCESS),
> the number of characters read,
> the number of leading whitespace characters.
>
> I'm getting a bunch of 1s, -1s, or 0s for the last two elements. In fact I'm
> not getting any other values.
>
The bunch of 0s in 3rd position is a bug, corrected. value() didn't have this
bug.
The bunch of -1s in the last position should be a bunch of 0s, hardly more
useful. This is because nearly all the test values start without any leading
whitespace. Otherwise, you'd get more useful output - I'll add some.
> Are these really useful return values? Maybe a different function to read
> those
> last two numbers would be better (state kept in a file variable of course)?
>
What do you mean by this "file variable"?
As I said in my previous post, I don't like the idea of having too many routine
names to do "almost similar but ..." things. C's stdlib went that way, there are
some good reasons to do this indeed, but the drawbacks are obvious.
> Plus your comment at the top of Get2() doesn't seem to reflect reality: you
> say that Get2() will return a 2-element sequence unless record_whitespace flag
> is set. Get2() seems to return 4 elements regardless.
>
Actually the comments of Get() and Get2() need to be swapped. Will do that.
Bear in mind they are local routines anyway. It is quite exceptional for local
routines to be commented in the standard files - perhaps a bad thing, not sure.
> I would see more value in returning (in this order) "success or failure",
> "sequence
> of interest", "sequence containing invalid characters until next valid
> character
> (not read)" and "total characters read". And probably not even that, as I
> would
> prefer to see it separated from get(). get()'s pointer, of course, would point
> to the next valid character.
>
> So the optimal situation in my opinion would be to leave get() returning a
> two-element
> sequence as now, but add get_leading_whitespace_count(), get_chars_read(), and
> get_last_invalid(). Obviously, those names suck, but the point still stands.
>
> Same for value().
>
Answered the previous two points in previous post.
Actually, I don't think that the symmetry between get() and value() is very
deep. With value(), you still can inspect the input string easily. With get(), it
is not as easy - you need to seek() back where you were, and then get_bytes() the
same amount you read so as to inspect the string that was just read and return to
file position. On some devices, this may be slow or impossible.
So, the idea of returning at some point the whole string, which will stop right
before the first invalid character anyway, may make sense for get(), but not as
much for value(). Conversely, while value_from() can be just as useful as
find_from() is (and easier to implement), get_from() would just be seek()
followed by get(), so it would hardly be useful.
CChris
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
17. Re: Bug in new get()?
CChris wrote:
>
> I was in a hurry when writing the first reply, some precisions now.
>
>
> Jason Gade wrote:
> >
> > Okay, I'm writing a stub to test your new get.e with regards to sanity.ex,
> > so
> > I can fix sanity.ex.
> >
> > And I'm looking at your docs. I don't quite understand them and I have a
> > change
> > suggestion.
> >
> > Your docs say:
> > get() returns a 4 element sequence, like value() does:
> > a status code (success/error/end of file),
> > the value just read (meaningful only when the status code is
> > GET_SUCCESS),
> > the number of characters read,
> > the number of leading whitespace characters.
> >
> > I'm getting a bunch of 1s, -1s, or 0s for the last two elements. In fact I'm
> > not getting any other values.
> >
>
> The bunch of 0s in 3rd position is a bug, corrected. value() didn't have this
> bug.
> The bunch of -1s in the last position should be a bunch of 0s, hardly more
> useful.
> This is because nearly all the test values start without any leading
> whitespace. Otherwise, you'd get more useful output - I'll add some.
Okay. I don't know if I'll get a chance to test tonight...
Actually I can probably just download get.e and sanity.ex and test them here at
work.
>
> > Are these really useful return values? Maybe a different function to read
> > those
> > last two numbers would be better (state kept in a file variable of course)?
> >
>
> What do you mean by this "file variable"?
"file variable" -- a variable defined at the top level of a file. It can hold
state but is not visible to routines outside of that file. Also known as a
"static variable".
> As I said in my previous post, I don't like the idea of having too many
> routine
> names to do "almost similar but ..." things. C's stdlib went that way, there
> are some good reasons to do this indeed, but the drawbacks are obvious.
>
Right. I remember discussing on the list whether value() and get() should read
and ignore comments like they do whitespace but I don't remember discussing the
extra return values. I might have missed the discussion.
I don't really have a problem with it -- it just seems lie extraneous
information to me. get() and value() should return a status and a value. Maybe
some other functions should return extended state information. But I don't really
care either way.
> > Plus your comment at the top of Get2() doesn't seem to reflect reality: you
> > say that Get2() will return a 2-element sequence unless record_whitespace
> > flag
> > is set. Get2() seems to return 4 elements regardless.
> >
>
> Actually the comments of Get() and Get2() need to be swapped. Will do that.
> Bear in mind they are local routines anyway. It is quite exceptional for local
> routines to be commented in the standard files - perhaps a bad thing, not
> sure.
No, comments are a good thing! As long as they accurately reflect the code.
So -- you mean to say that Get2() (and by extension get() since it returns
Get2()) will now always return a length 4 sequence?
>
> > I would see more value in returning (in this order) "success or failure",
> > "sequence
> > of interest", "sequence containing invalid characters until next valid
> > character
> > (not read)" and "total characters read". And probably not even that, as I
> > would
> > prefer to see it separated from get(). get()'s pointer, of course, would
> > point
> > to the next valid character.
> >
> > So the optimal situation in my opinion would be to leave get() returning a
> > two-element
> > sequence as now, but add get_leading_whitespace_count(), get_chars_read(),
> > and
> > get_last_invalid(). Obviously, those names suck, but the point still stands.
> >
> > Same for value().
> >
>
> Answered the previous two points in previous post.
>
> Actually, I don't think that the symmetry between get() and value() is very
> deep. With value(), you still can inspect the input string easily. With get(),
> it is not as easy - you need to seek() back where you were, and then
> get_bytes()
> the same amount you read so as to inspect the string that was just read and
> return to file position. On some devices, this may be slow or impossible.
> So, the idea of returning at some point the whole string, which will stop
> right
> before the first invalid character anyway, may make sense for get(), but not
> as much for value(). Conversely, while value_from() can be just as useful as
> find_from() is (and easier to implement), get_from() would just be seek()
> followed
> by get(), so it would hardly be useful.
>
> CChris
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
18. Re: Bug in new get()?
CChris wrote:
> (didn't find that line 549-552 in the .htx file - which one?
trunk/htx/lib_e_g.htx lines 549-552 say that get() will return a 2-element
sequence.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
19. Re: Bug in new get()?
Jason Gade wrote:
>
> CChris wrote:
> >
> > I was in a hurry when writing the first reply, some precisions now.
> >
> >
> > Jason Gade wrote:
> > >
> > > Okay, I'm writing a stub to test your new get.e with regards to sanity.ex,
> > > so
> > > I can fix sanity.ex.
> > >
> > > And I'm looking at your docs. I don't quite understand them and I have a
> > > change
> > > suggestion.
> > >
> > > Your docs say:
> > > get() returns a 4 element sequence, like value() does:
> > > a status code (success/error/end of file),
> > > the value just read (meaningful only when the status code is
> > > GET_SUCCESS),
> > > the number of characters read,
> > > the number of leading whitespace characters.
> > >
> > > I'm getting a bunch of 1s, -1s, or 0s for the last two elements. In fact
> > > I'm
> > > not getting any other values.
> > >
> >
> > The bunch of 0s in 3rd position is a bug, corrected. value() didn't have
> > this
> > bug.
> > The bunch of -1s in the last position should be a bunch of 0s, hardly more
> > useful.
> > This is because nearly all the test values start without any leading
> > whitespace. Otherwise, you'd get more useful output - I'll add some.
>
> Okay. I don't know if I'll get a chance to test tonight...
>
> Actually I can probably just download get.e and sanity.ex and test them here
> at work.
>
> >
> > > Are these really useful return values? Maybe a different function to read
> > > those
> > > last two numbers would be better (state kept in a file variable of
> > > course)?
> > >
> >
> > What do you mean by this "file variable"?
>
> "file variable" -- a variable defined at the top level of a file. It can hold
> state but is not visible to routines outside of that file. Also known as a
> "static
> variable".
>
Oh, I am so used to calling them "local variables". I thought it was something
else...
> > As I said in my previous post, I don't like the idea of having too many
> > routine
> > names to do "almost similar but ..." things. C's stdlib went that way, there
> > are some good reasons to do this indeed, but the drawbacks are obvious.
> >
>
> Right. I remember discussing on the list whether value() and get() should read
> and ignore comments like they do whitespace but I don't remember discussing
> the extra return values. I might have missed the discussion.
>
> I don't really have a problem with it -- it just seems lie extraneous
> information
> to me. get() and value() should return a status and a value. Maybe some other
> functions should return extended state information. But I don't really care
> either way.
>
Actually, there could be something to please the archconservative lobby. I
remembered that, initially, I had only extended value() because the whitespace
and length information are clearly of less use for get() than for value().
So a possibility could be to:
* leave get() and value() alone, alllowing embedded comments;
* add a value_from(sequnce s,integer start) which would return the 4 element
sequence and would allow to select where to start from. If the string holds
several Eu objects, it would be pretty useful, just like find_drom(). get()
wouldn't be extended.
What about that? The change will be very easy to implement.
Rob had explicitly stated he preferred to keep the symmetry between get() and
value(). Perhaps there is no need to have a symmetrixc get_from().
> > > Plus your comment at the top of Get2() doesn't seem to reflect reality:
> > > you
> > > say that Get2() will return a 2-element sequence unless record_whitespace
> > > flag
> > > is set. Get2() seems to return 4 elements regardless.
> > >
> >
> > Actually the comments of Get() and Get2() need to be swapped. Will do that.
> > Bear in mind they are local routines anyway. It is quite exceptional for
> > local
> > routines to be commented in the standard files - perhaps a bad thing, not
> > sure.
>
> No, comments are a good thing! As long as they accurately reflect the code.
>
So a side question is: shouldn't there be mmore comments in the standard files?
They are pretty sparse in this respect.
> So -- you mean to say that Get2() (and by extension get() since it returns
> Get2())
> will now always return a length 4 sequence?
>
Not really.
* Get(), the inner level routine, returns 2 element sequences. It was modified
only regarding the embedded comments; otherwise it is the original RDS code;
* Get2(), the outer level routine, was obtained by duplicating Get() and making
some extensive changes inside. It returns 4 element sequences;
* get() and value() return Get2(), so they also return a 4 element sequence.
If the modification I suggested above was preferred, then the pictture would
become as follows:
* Get() unchanged;
* Get2() unchanged;
* get() and value() return Get(), hence a 2 element sequence
* value_from() returns Get2(), hence a 4 element sequence.
> >
> > > I would see more value in returning (in this order) "success or failure",
> > > "sequence
> > > of interest", "sequence containing invalid characters until next valid
> > > character
> > > (not read)" and "total characters read". And probably not even that, as I
> > > would
> > > prefer to see it separated from get(). get()'s pointer, of course, would
> > > point
> > > to the next valid character.
> > >
> > > So the optimal situation in my opinion would be to leave get() returning a
> two-element</font></i>
> > > sequence as now, but add get_leading_whitespace_count(), get_chars_read(),
> > > and
> > > get_last_invalid(). Obviously, those names suck, but the point still
> > > stands.
> > >
> > > Same for value().
> > >
> >
> > Answered the previous two points in previous post.
> >
> > Actually, I don't think that the symmetry between get() and value() is very
> > deep. With value(), you still can inspect the input string easily. With
> > get(),
> > it is not as easy - you need to seek() back where you were, and then
> > get_bytes()
> > the same amount you read so as to inspect the string that was just read and
> > return to file position. On some devices, this may be slow or impossible.
> > So, the idea of returning at some point the whole string, which will stop
> > right
> > before the first invalid character anyway, may make sense for get(), but not
> > as much for value(). Conversely, while value_from() can be just as useful as
> > find_from() is (and easier to implement), get_from() would just be seek()
> > followed
> > by get(), so it would hardly be useful.
> >
> > CChris
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
CChris
20. Re: Bug in new get()?
Jason Gade wrote:
>
> CChris wrote:
>
> > (didn't find that line 549-552 in the .htx file - which one?
>
> trunk/htx/lib_e_g.htx lines 549-552 say that get() will return a 2-element
> sequence.
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
Ok; I'll wait to see if the value_from() option is preferred before updating
that. I really thought I had - oh well.
Some RL intensive days, I may perform the updates only tomorrow.
CChris
21. Re: Bug in new get()?
CChris wrote:
>
> Jason Gade wrote:
> >
> > CChris wrote:
> > > What do you mean by this "file variable"?
> >
> > "file variable" -- a variable defined at the top level of a file. It can
> > hold
> > state but is not visible to routines outside of that file. Also known as a
> > "static
> > variable".
> >
>
> Oh, I am so used to calling them "local variables". I thought it was something
> else...
Heh. Sorry. To me a local variable is one defined inside a function or a
procedure -- otherwise known as a "private" variable.
> Actually, there could be something to please the archconservative lobby. I
> remembered
> that, initially, I had only extended value() because the whitespace and length
> information are clearly of less use for get() than for value().
>
> So a possibility could be to:
> * leave get() and value() alone, alllowing embedded comments;
> * add a value_from(sequnce s,integer start) which would return the 4 element
> sequence and would allow to select where to start from. If the string holds
> several Eu objects, it would be pretty useful, just like find_drom(). get()
> wouldn't be extended.
>
> What about that? The change will be very easy to implement.
>
> Rob had explicitly stated he preferred to keep the symmetry between get() and
> value(). Perhaps there is no need to have a symmetrixc get_from().
Sounds okay to me -- again, I'm just trying to verify my build of
interpreter/translator/backend. If everything had worked then I wouldn't have
complained at all.
> > No, comments are a good thing! As long as they accurately reflect the code.
> >
>
> So a side question is: shouldn't there be mmore comments in the standard
> files?
> They are pretty sparse in this respect.
I think there are two theories on that -- some think that the code should
"comment itself". Personally I would at least prefer an "intent" comment -- "why
this routine was written" or "what this routine does" kind of thing.
A lot of the time I'll write the comment before I write any code.
> If the modification I suggested above was preferred, then the pictture would
> become as follows:
> * Get() unchanged;
> * Get2() unchanged;
> * get() and value() return Get(), hence a 2 element sequence
> * value_from() returns Get2(), hence a 4 element sequence.
I actually think that's a fine idea. What do others think?
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
22. Re: Bug in new get()?
Jason Gade wrote:
>
> CChris wrote:
> >
> > Jason Gade wrote:
> > >
> > > CChris wrote:
> > > > What do you mean by this "file variable"?
> > >
> > > "file variable" -- a variable defined at the top level of a file. It can
> > > hold
> > > state but is not visible to routines outside of that file. Also known as a
> > > "static
> > > variable".
> > >
> >
> > Oh, I am so used to calling them "local variables". I thought it was
> > something
> > else...
>
> Heh. Sorry. To me a local variable is one defined inside a function or a
> procedure
> -- otherwise known as a "private" variable.
>
> > Actually, there could be something to please the archconservative lobby. I
> > remembered
> > that, initially, I had only extended value() because the whitespace and
> > length
> > information are clearly of less use for get() than for value().
> >
> > So a possibility could be to:
> > * leave get() and value() alone, alllowing embedded comments;
> > * add a value_from(sequnce s,integer start) which would return the 4 element
> > sequence and would allow to select where to start from. If the string holds
> > several Eu objects, it would be pretty useful, just like find_drom(). get()
> > wouldn't be extended.
> >
> > What about that? The change will be very easy to implement.
> >
> > Rob had explicitly stated he preferred to keep the symmetry between get()
> > and
> > value(). Perhaps there is no need to have a symmetrixc get_from().
>
> Sounds okay to me -- again, I'm just trying to verify my build of
> interpreter/translator/backend.
> If everything had worked then I wouldn't have complained at all.
>
> > > No, comments are a good thing! As long as they accurately reflect the
> > > code.
> > >
> >
> > So a side question is: shouldn't there be mmore comments in the standard
> > files?
> > They are pretty sparse in this respect.
>
> I think there are two theories on that -- some think that the code should
> "comment
> itself". Personally I would at least prefer an "intent" comment -- "why this
> routine was written" or "what this routine does" kind of thing.
>
> A lot of the time I'll write the comment before I write any code.
>
> > If the modification I suggested above was preferred, then the pictture would
> > become as follows:
> > * Get() unchanged;
> > * Get2() unchanged;
> > * get() and value() return Get(), hence a 2 element sequence
> > * value_from() returns Get2(), hence a 4 element sequence.
>
> I actually think that's a fine idea. What do others think?
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
Thank you Jason and CChris,
Unwittingly you just explained to me what 'top level' and 'lower level' meant.
I never understood this although I see it discussed often.
So readding this forum is not a compleat waste of time even if you don't
understand what they are talking about.
Don Cole
