Menu
▾
▴
gobo-eiffel-develop
|
From: Eric B. <er...@go...> - 2009-05-02 09:28:46
|
Hi Colin, On January 18, 2007, in commit svn#5840, you changed the implementation and contracts of feature `unescaped_utf8' in UT_URL_ENCODING. However, after this change of contracts, it looks like you didn't update its callers. For example feature `decoded_utf8' in class UT_URI_STRING, and hence its callers, still rely on the fact that the result of `unescaped_utf8' is supposed to be non-void. Can you have a look at that? This is a bug which is blocking the conversion of Gobo to void-safe mode. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2009-05-02 16:25:24
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> Hi Colin, On January 18, 2007, in commit svn#5840, you
Eric> changed the implementation and contracts of feature
Eric> `unescaped_utf8' in UT_URL_ENCODING. However, after this
Eric> change of contracts, it looks like you didn't update its
Eric> callers. For example feature `decoded_utf8' in class
Eric> UT_URI_STRING, and hence its callers, still rely on the fact
Eric> that the result of `unescaped_utf8' is supposed to be
Eric> non-void.
Eric> Can you have a look at that? This is a bug which is blocking
Eric> the conversion of Gobo to void-safe mode.
I'll take a look early next week.
--
Colin Adams
Preston Lancashire
|
|
From: Colin A. <col...@go...> - 2009-05-03 09:14:52
|
The contract for the routine is correct (the preconditions do not exclude a string which includes escapes represnting a non-valid UTF-8 byte sequence, such as Latin-1 bytes, or just pure garbage). There is a test that unescape_string returns no byte greater than 255 - I think this is redundant (but it would need a postcondition on unescape_string to make it secure), but this is not relevant to the issue in hand. So the clients need changing to accept the possibility of a Void result. I'll look into this on Wednesday (or possibly Tuesday if I have more time than expected). 2009/5/2 Colin Paul Adams <co...@co...>: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> Hi Colin, On January 18, 2007, in commit svn#5840, you > Eric> changed the implementation and contracts of feature > Eric> `unescaped_utf8' in UT_URL_ENCODING. However, after this > Eric> change of contracts, it looks like you didn't update its > Eric> callers. For example feature `decoded_utf8' in class > Eric> UT_URI_STRING, and hence its callers, still rely on the fact > Eric> that the result of `unescaped_utf8' is supposed to be > Eric> non-void. > > Eric> Can you have a look at that? This is a bug which is blocking > Eric> the conversion of Gobo to void-safe mode. > > I'll take a look early next week. > -- > Colin Adams > Preston Lancashire > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > _______________________________________________ > gobo-eiffel-develop mailing list > gob...@li... > https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop > |
|
From: Colin A. <col...@go...> - 2009-05-06 07:27:31
|
There is a complication in that UT_FILE_URI_ROUTINES is buggy. In particular, the routine uri_to_pathname has too liberal a contract. I've discussed this extensively with Franck. One possible solution is to strengthen the precondition so that the argument wither contains no colon characters, or it contains exactly one, and then the argument starts with "file:" (this would be in accordance with the class-level documentation). With such a precondition, it would then be possible to leave the postcondition unchanged - that is, a non-Void Result. In such cases we could simply return "create Result.make" for an invalid URI. Since this is equivalent to the URI "file:///" (the rot of the file system), this isn't attractive. The more attractive (to me) alternative is to weaken the postcondition, so that the return only returns non-Void if a good file URI is passed to it. So http://www.some.host/my/path/to/file will return Void (currently it returns the same pathname as file:///my/path/to/file, which is a clear bug). Then if decoding a percent-encoded URI fails (returns Void), we simply return a Void pathname. This means that this routine will always return Void for URIs which include percent-encodings which are intended to be in Latin-1. Well, that has never been supported by this class, so it should be added to the class-level documentation. Note that the inverse routine, pathname_to_uri, always produces UTF-8 encoded URIs (when encoding is necessary). 2009/5/3 Colin Adams <col...@go...>: > The contract for the routine is correct (the preconditions do not > exclude a string which includes escapes representing a non-valid UTF-8 > byte sequence, > such as Latin-1 bytes, or just pure garbage). > > There is a test that unescape_string returns no byte greater than 255 > - I think this is redundant (but it would need a postcondition on > unescape_string to make it secure), > but this is not relevant to the issue in hand. > > So the clients need changing to accept the possibility of a Void > result. I'll look into this on Wednesday (or possibly Tuesday if I > have more time than expected). > > 2009/5/2 Colin Paul Adams <co...@co...>: >>>>>>> "Eric" == Eric Bezault <er...@go...> writes: >> >> Eric> Hi Colin, On January 18, 2007, in commit svn#5840, you >> Eric> changed the implementation and contracts of feature >> Eric> `unescaped_utf8' in UT_URL_ENCODING. However, after this >> Eric> change of contracts, it looks like you didn't update its >> Eric> callers. For example feature `decoded_utf8' in class >> Eric> UT_URI_STRING, and hence its callers, still rely on the fact >> Eric> that the result of `unescaped_utf8' is supposed to be >> Eric> non-void. >> >> Eric> Can you have a look at that? This is a bug which is blocking >> Eric> the conversion of Gobo to void-safe mode. >> >> I'll take a look early next week. >> -- >> Colin Adams >> Preston Lancashire >> >> ------------------------------------------------------------------------------ >> Register Now & Save for Velocity, the Web Performance & Operations >> Conference from O'Reilly Media. Velocity features a full day of >> expert-led, hands-on workshops and two days of sessions from industry >> leaders in dedicated Performance & Operations tracks. Use code vel09scf >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf >> _______________________________________________ >> gobo-eiffel-develop mailing list >> gob...@li... >> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop >> > |
|
From: Colin A. <col...@go...> - 2009-05-06 09:21:28
|
Looking at the latest code in SVN, I see that ?STRING is used on return type of unescape_utf8, but unescape_string has plain STRING (not !STRING). Is this the policy to follow? Doesn't it mean that the library will only be Void-safe if types are considered attached by default? 2009/5/6 Colin Adams <col...@go...>: > There is a complication in that UT_FILE_URI_ROUTINES is buggy. In > particular, the routine uri_to_pathname has too liberal a contract. > I've discussed this extensively with Franck. > > One possible solution is to strengthen the precondition so that the > argument wither contains no colon characters, or it contains exactly > one, and then the argument starts with "file:" (this would be in > accordance with the class-level documentation). > > With such a precondition, it would then be possible to leave the > postcondition unchanged - that is, a non-Void Result. In such cases we > could simply return "create Result.make" for an invalid URI. Since > this is equivalent to the URI "file:///" (the rot of the file system), > this isn't attractive. > > The more attractive (to me) alternative is to weaken the > postcondition, so that the return only returns non-Void if a good file > URI is passed to it. So http://www.some.host/my/path/to/file will > return Void (currently it returns the same pathname as > file:///my/path/to/file, which is a clear bug). Then if decoding a > percent-encoded URI fails (returns Void), we simply return a Void > pathname. > > This means that this routine will always return Void for URIs which > include percent-encodings which are intended to be in Latin-1. Well, > that has never been supported by this class, so it should be added to > the class-level documentation. Note that the inverse routine, > pathname_to_uri, always produces UTF-8 encoded URIs (when encoding is > necessary). > > 2009/5/3 Colin Adams <col...@go...>: >> The contract for the routine is correct (the preconditions do not >> exclude a string which includes escapes representing a non-valid UTF-8 >> byte sequence, >> such as Latin-1 bytes, or just pure garbage). >> >> There is a test that unescape_string returns no byte greater than 255 >> - I think this is redundant (but it would need a postcondition on >> unescape_string to make it secure), >> but this is not relevant to the issue in hand. >> >> So the clients need changing to accept the possibility of a Void >> result. I'll look into this on Wednesday (or possibly Tuesday if I >> have more time than expected). >> >> 2009/5/2 Colin Paul Adams <co...@co...>: >>>>>>>> "Eric" == Eric Bezault <er...@go...> writes: >>> >>> Eric> Hi Colin, On January 18, 2007, in commit svn#5840, you >>> Eric> changed the implementation and contracts of feature >>> Eric> `unescaped_utf8' in UT_URL_ENCODING. However, after this >>> Eric> change of contracts, it looks like you didn't update its >>> Eric> callers. For example feature `decoded_utf8' in class >>> Eric> UT_URI_STRING, and hence its callers, still rely on the fact >>> Eric> that the result of `unescaped_utf8' is supposed to be >>> Eric> non-void. >>> >>> Eric> Can you have a look at that? This is a bug which is blocking >>> Eric> the conversion of Gobo to void-safe mode. >>> >>> I'll take a look early next week. >>> -- >>> Colin Adams >>> Preston Lancashire >>> >>> ------------------------------------------------------------------------------ >>> Register Now & Save for Velocity, the Web Performance & Operations >>> Conference from O'Reilly Media. Velocity features a full day of >>> expert-led, hands-on workshops and two days of sessions from industry >>> leaders in dedicated Performance & Operations tracks. Use code vel09scf >>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf >>> _______________________________________________ >>> gobo-eiffel-develop mailing list >>> gob...@li... >>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop >>> >> > |
|
From: Eric B. <er...@go...> - 2009-05-06 10:26:34
|
Colin Adams wrote: > Looking at the latest code in SVN, I see that ?STRING is used on > return type of unescape_utf8, but unescape_string has plain STRING > (not !STRING). > > Is this the policy to follow? Doesn't it mean that the library will > only be Void-safe if types are considered attached by default? I guess so. Note that when there is a plain STRING, the postcondition Result /= Void should be retained for the time being. That way the code is still correct in non void-safe mode. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin A. <col...@go...> - 2009-05-06 09:38:44
|
One client was the test case. I've added a check statement so that it should pass Void-safety. Geant test_debug_ge and geant test_debug_ise both pass, but I presume these are NOT running in Void-safe mode. Is there a way to check that what I have done is sufficient? 2009/5/2 Eric Bezault <er...@go...>: > Hi Colin, > > On January 18, 2007, in commit svn#5840, you changed the implementation > and contracts of feature `unescaped_utf8' in UT_URL_ENCODING. However, > after this change of contracts, it looks like you didn't update its > callers. For example feature `decoded_utf8' in class UT_URI_STRING, > and hence its callers, still rely on the fact that the result of > `unescaped_utf8' is supposed to be non-void. > > Can you have a look at that? This is a bug which is blocking the > conversion of Gobo to void-safe mode. > > -- > Eric Bezault > mailto:er...@go... > http://www.gobosoft.com > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > _______________________________________________ > gobo-eiffel-develop mailing list > gob...@li... > https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop > |
|
From: Eric B. <er...@go...> - 2009-05-06 10:30:22
|
Colin Adams wrote: > One client was the test case. I've added a check statement so that it > should pass Void-safety. > > Geant test_debug_ge and geant test_debug_ise both pass, but I presume > these are NOT running in Void-safe mode. Is there a way to check that > what I have done is sufficient? Jocelyn might give a better answer here, but my feeling is that the classes are not fully void-safe yet. What is done is incremental modifications towards void-safety. So running in void-safe mode would still trigger a lot of errors I guess. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Jocelyn <li...@dj...> - 2009-05-06 19:07:54
|
Indeed, The current gobo's trunk is not Void safe. At ISE we converted (almost) all Gobo's libraries, and made this version available at http://github.com/jocelyn/void-safe-gobo-eiffel/tree/master (almost because currently the ools, tests, and some XSLT related classes are not converted). Since Eric doesn't have that much time to integrate the result of the conversion, I send him small patches from time to time, so that the official gobo's lib is converted slowly. The integration sometime requires implementation or interface change to avoid having dirty code, and there are still points such as DS_TRAVERSABLE.internal_cursor which should be detachable for invariant's purpose, which slow down (or even block the progression). If you see at the code hosted at github (See previous link), you might noticed the xml cluster has a lot of changes (mostly check var /= Void end) to make it Void safe. This is mainly due to the fact some of those classes use different attribute according to other (boolean status report) attribute. So we end up with many "detachable" attribute, and whenever the code use them, it needs to check if this is attached or not. Anyway, the conversion goes slowly, but surely. I doubt the official gobo will integrate all the changes for 6.4, but we never knows ... Eric might have more time, and maybe someone can review the changes from the xml cluster, and eventually redesign some part to make it more void-safety friendly. So my short answer to your question 1) the official gobo's libraries get converted+integrated incrementally 2) however, the fully converted gobo's lib are available at http://github.com/jocelyn/void-safe-gobo-eiffel/tree/master Hope this helps, -- Jocelyn Eric Bezault wrote: > Colin Adams wrote: > >> One client was the test case. I've added a check statement so that it >> should pass Void-safety. >> >> Geant test_debug_ge and geant test_debug_ise both pass, but I presume >> these are NOT running in Void-safe mode. Is there a way to check that >> what I have done is sufficient? >> > > Jocelyn might give a better answer here, but my feeling is that > the classes are not fully void-safe yet. What is done is incremental > modifications towards void-safety. So running in void-safe mode > would still trigger a lot of errors I guess. > > |
|
From: Colin A. <col...@go...> - 2009-05-06 14:28:20
|
OK. On that basis I was prepared to check in my changes. But one of the tests has failed - for geant, so I guess this cannot be something I have changed, as it will not be using the URI stuff. Anyway, the failing test is GEANT_FUNCTIONAL_ECHO_TEST.test_built_in_var. The failing assertion is test_builtin_var_2 (diff between files 'out.txt' and 'out2.txt' at line 1) I cannot find a file named out2.txt or out.txt. 2009/5/6 Eric Bezault <er...@go...>: > Colin Adams wrote: >> >> One client was the test case. I've added a check statement so that it >> should pass Void-safety. >> >> Geant test_debug_ge and geant test_debug_ise both pass, but I presume >> these are NOT running in Void-safe mode. Is there a way to check that >> what I have done is sufficient? > > Jocelyn might give a better answer here, but my feeling is that > the classes are not fully void-safe yet. What is done is incremental > modifications towards void-safety. So running in void-safe mode > would still trigger a lot of errors I guess. > > -- > Eric Bezault > mailto:er...@go... > http://www.gobosoft.com > |
|
From: Colin A. <col...@go...> - 2009-05-06 17:22:55
|
Also DT_TEST_STOPWATCH.test_start_stop fails with elapsed_time_positive1 when run with: geant test_ge This is on 64-bit Linux, for what that's worth. Again, I can't see any connection with my changes to the URI classes. Shall I check-in anyway? 2009/5/6 Colin Adams <col...@go...>: > OK. > > On that basis I was prepared to check in my changes. > > But one of the tests has failed - for geant, so I guess this cannot be > something I have changed, as it will not be using the URI stuff. > > Anyway, the failing test is GEANT_FUNCTIONAL_ECHO_TEST.test_built_in_var. > The failing assertion is test_builtin_var_2 (diff between files > 'out.txt' and 'out2.txt' at line 1) > > I cannot find a file named out2.txt or out.txt. > > 2009/5/6 Eric Bezault <er...@go...>: >> Colin Adams wrote: >>> >>> One client was the test case. I've added a check statement so that it >>> should pass Void-safety. >>> >>> Geant test_debug_ge and geant test_debug_ise both pass, but I presume >>> these are NOT running in Void-safe mode. Is there a way to check that >>> what I have done is sufficient? >> >> Jocelyn might give a better answer here, but my feeling is that >> the classes are not fully void-safe yet. What is done is incremental >> modifications towards void-safety. So running in void-safe mode >> would still trigger a lot of errors I guess. >> >> -- >> Eric Bezault >> mailto:er...@go... >> http://www.gobosoft.com >> > |
|
From: Eric B. <er...@go...> - 2009-05-06 17:23:53
|
Colin Adams wrote: > Also DT_TEST_STOPWATCH.test_start_stop fails with > elapsed_time_positive1 when run with: > > geant test_ge > > This is on 64-bit Linux, for what that's worth. > > Again, I can't see any connection with my changes to the URI classes. > Shall I check-in anyway? Yes. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin A. <col...@go...> - 2009-05-06 17:43:12
|
Done. 2009/5/6 Eric Bezault <er...@go...>: > Colin Adams wrote: >> >> Also DT_TEST_STOPWATCH.test_start_stop fails with >> elapsed_time_positive1 when run with: >> >> geant test_ge >> >> This is on 64-bit Linux, for what that's worth. >> >> Again, I can't see any connection with my changes to the URI classes. >> Shall I check-in anyway? > > Yes. > > -- > Eric Bezault > mailto:er...@go... > http://www.gobosoft.com > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X