1. Bug in new get()?
- Posted by Jason Gade <jaygade at ?ahoo.c?m> Aug 16, 2007
- 586 views
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()?
- Posted by Juergen Luethje <j.lue at g?x.?e> Aug 16, 2007
- 558 views
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()?
- Posted by CChris <christian.cuvier at agricultur?.go?v.fr> Aug 16, 2007
- 539 views
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()?
- Posted by Jason Gade <jaygade at ya?oo?com> Aug 16, 2007
- 531 views
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()?
- Posted by Juergen Luethje <j.lue at ?mx.?e> Aug 16, 2007
- 551 views
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()?
- Posted by Jason Gade <jaygade at yaho?.c?m> Aug 16, 2007
- 538 views
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()?
- Posted by Jason Gade <jaygade at y?hoo?com> Aug 16, 2007
- 520 views
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()?
- Posted by CChris <christian.cuvier at agricul?ure.gouv?fr> Aug 16, 2007
- 542 views
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()?
- Posted by Jason Gade <jaygade at y?hoo.?om> Aug 16, 2007
- 539 views
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()?
- Posted by Matt Lewis <matthewwalkerlewis at g?a?l.com> Aug 16, 2007
- 543 views
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()?
- Posted by CChris <christian.cuvier at ag?icu?ture.gouv.fr> Aug 16, 2007
- 548 views
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()?
- Posted by Jason Gade <jaygade at ya?oo?com> Aug 16, 2007
- 545 views
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()?
- Posted by Jason Gade <jaygade at y?h?o.com> Aug 17, 2007
- 549 views
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()?
- Posted by Juergen Luethje <j.lue at g?x?de> Aug 17, 2007
- 557 views
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()?
- Posted by CChris <christian.cuvier at agriculture.g??v.fr> Aug 17, 2007
- 534 views
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()?
- Posted by CChris <christian.cuvier at ag?icu?ture.gouv.fr> Aug 17, 2007
- 535 views
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()?
- Posted by Jason Gade <jaygade at yah?o.?om> Aug 17, 2007
- 531 views
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()?
- Posted by Jason Gade <jaygade at yahoo?c?m> Aug 17, 2007
- 532 views
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()?
- Posted by CChris <christian.cuvier at agricu?ture.gou?.fr> Aug 17, 2007
- 531 views
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()?
- Posted by CChris <christian.cuvier at ag?icultu?e.gouv.fr> Aug 17, 2007
- 549 views
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()?
- Posted by Jason Gade <jaygade at y?hoo.com> Aug 17, 2007
- 539 views
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()?
- Posted by don cole <doncole at pac??ll.net> Aug 19, 2007
- 576 views
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