October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] scriptloader>>loadComanche

by StÃ©phane Ducasse

ScriptLoader should not be used for loading external packages :) We are sorry about that. Else junk simply accumulate because they are not maintained. We clearly need a universe like tools so that people can publish and maintain their add-ons. Damien I would really like to see Universes coming back. Do we have any chance getting it back? Stef > Hi there, > > Scriptloader has lost its #loadComanche method, which means that > #loadSeaside30 does not work anymore. > > What happened? ;-) > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 20, 2009

Re: [Pharo-project] [update] #10487

by StÃ©phane Ducasse

yeap! 100% in sync. On Oct 19, 2009, at 9:57 PM, Lukas Renggli wrote: >> I think that there are different scenarios (dev my app vs changing >> the >> system) >> and I can tell you that they are change like cleaning image segment >> for which I would >> love to have tests because I would be more confortable with fixing >> it. > > Yeah definitely, I completely agree. The tests are very valuable and > should be run regularly. It is just for me as a normal user/developer > (of Seaside) is not really interested in running the collection tests > all the time. I am more interested in what tests pass (to chose the > right image, to know the limitations) than in the tests themselves. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 20, 2009

Re: [Pharo-project] '' asNumber -> 'Reading a number failed'

by Nicolas Cellier

2009/10/20 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, Oct 19, 2009 at 10:33 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Yes, I understand the paradigm, nil is nothing is zero, empty is >> nothing is zero... >> But frankly, do you think '' forms a valid Number ? In every context ? >> So yes, this is expected, and can break compatibility, but sometimes >> this is necessary. >> >> If you want to keep this behaviour, you have to use an explicit rule like: >> asNumberOrZero >> Â ^Number readFrom: self ifFail: [^0] >> > > Thanks Nicolas. Now, the question is, do you think we can create this method > in String as part of Pharo core?Â or I should add it to my application? > > cheers > > mariano > Depends if the pattern was used by many packages or not... It would be stupid to create 10x the same extension to work around a pharo change. Would it be a temporary helper subject to deprecation, or a definitive feature ? I can't tell, and i don't decide, i only suggest. Nicolas >> >> Hope this helps... >> >> Nicolas >> >> 2009/10/20 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > Hi folks:Â In older images, like 10418, '' asNumberÂ gave me a 0 (zero). >> > But >> > now, I get a 'Reading a number failed'. >> > >> > Is this expected? >> > >> > Perhaps it is due to the fix to this bug: >> > >> > >> > http://code.google.com/p/pharo/issues/detail?can=1&q=1258&colspec=ID%20Type… >> > >> > any toughs? >> > >> > best >> > >> > Mariano >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 20, 2009

Re: [Pharo-project] About TestCase >> assert:

by Nicolas Cellier

Hehe, yes, once I implemented a matlab like generalized access: m(1) = 3.14; % single element m(1:5) = [2 3 9 7 1]; % a contiguous subspace m([1 2 5]) = -m([1 2 5]); % an arbitrary subspace m(:) = m(end:-1:1); % a whole subspace (colon = column matrix) m( m>2 ) = m( m> 2 ) - 2; % a mask of booleans m( m<0 ) = 0; % variant: fill a subspace with an element m( m>5 ) = []; % a remove operation To keep it extensible and avoid static type checks, i ended up with triple dispatching... Not the code I'm the most proud of. I must admit a static-type compiler can handle such situations better... Maybe some declarative rules rather than procedural would also help... Nicolas 2009/10/20 Dale Henrichs <dale.henrichs(a)gemstone.com>: > Nicolas, many very good points. > > Just to add food for thought... double dispatching is a technique that has the benefit of avoiding isXXXX messages completely allowing for maximum flexibility and if the message isn't understood, immediate feedback that the programmer has done something wrong (which can be fixed by implementing the appropriate dispatch method) ... better than an assertion failures perhaps... > > Of course, double dispatching is not without it's drawbacks. I prefer double dispatching to implementing isXXX messages, but then I'd like to eliminate Booleans, too:) > > Dale > ----- "Nicolas Cellier" <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > | 2009/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > | > > | >> I think Smalltalk quality is based on a completly different plane > | > > | > | First, my reference about quality is not Squeak, I rather mean st-80 > | from ParcPlace :) > | At least it used to have > | - more generous class and method comments > | - less bugs and obscure code (certainly because less code too !) > | - a certain homogeneity (less programmers ?) > | > | So were is the Smalltalk quality ? > | - the ability to test code as soon as written > | - the ability to write small and simple code, > | - the ability to write readable code, > | - the ability to extend code > | Are these essential properties in the quality standards used in static > | typing ? > | > | > You mean not checkable documentation, absence of documentation, > | > lack of static typing to document (because what would be good is to > | > have a pluggable type system) > | > > | > | I agree, lack of type can be seen as a weakness for documenting APIs. > | As a workaround, we use funny parameter names (anArrayOfStrings). > | Or we add a method comment (hem... at least we should). > | I agree, all these comments will become false when code is changed, > | and the quality will decrease... > | As false as an outdated assertion... but silent... Maybe it's worse ? > | Browsing senders, or inspecting the signature of message sent to, or > | inserting a halt is sometimes our solutions... > | I agree, this is not ideal. > | > | So yes, assertions as a public declaration of API could be good for > | documenting. > | And a good description of assertion failure can also provide > | informative feedback to the user (more than a Debugger ?) > | > | What I do not like is defensive assertions as a potential barrier to > | extendability, because they correspond to a static view of code, a > | snapshot of current state. > | Smalltalk state does and will change. The image is living, and class > | structure not written on stone. > | Rapidly changing code is definitely not accepted as a quality > | standard... > | > | In a rapidly changing image, assertions could be a supplementary drag > | against change... > | Suppose I have a method accepting a String parameter P: p. > | Â Â [p isString] assertWithDescription: 'method xxx only accept a > | String as parameter P'. > | Now maybe the method would have worked with a Text. I have been too > | restrictive: > | Â Â [p isCharacters] assertWithDescription: 'method xxx only accept > | characters'. > | Now someone introduce WideString, and my code only work with > | ByteString. > | Â Â [p isCharacters and: [p asString isByteString]] > | assertWithDescription: 'method xxx only accept byte characters'. > | Yes, but the method does not work with empty String, I add: > | Â Â [p notEmpty] assertWithDescription: 'method xxx only accept non > | empty strings'. > | Nor does it with some control characters: > | Â Â self assertPHasValidCharacters: p. > | Fortunately someone then correct the WideString case, now I can > | retract isByteString. > | Unfortunately, p will be stored in an inst. var. with many public > | interfaces... > | Each time, I have to change all the false assertions in all senders > | of > | the core method that are in the public API... > | And maybe some of these public APIs are driven by other public APIs > | (you meet this in Smalltalk, didn't you?) > | To avoid this I create a specific method > | assertPIsValid: p > | Â Â | sender | > | Â Â sender := thisContext sender homeContext selector. > | Â Â [p isCharacters] assertWithDescription: 'method ' , sender , ' > | only accept characters'. > | Â Â [p asString isByteString] assertWithDescription: 'method ' , > | sender , ' only accept byte characters'. > | Â Â [p notEmpty] assertWithDescription: 'method ' , sender , ' only > | accept non empty strings'. > | Â Â self assertPHasValidCharacters: p from: sender. > | > | But now, I can't see the assumption from within public API. I have to > | browse implementors of assertPIsValid:, so I loose the immediate > | documentation... > | > | And one day, a brilliant programmer decide a ReadStream on characters > | would also be a good parameter P, with a minor change in the core > | method... > | Arghh, I don't want to advance the stream yet and do all my static > | checks... > | > | In order to maximize extendability, can't we use extensible > | assertions > | like sending a message? > | If we end up with > | Â Â [p isAGoodParameterPForMyMessage] assert. > | then I don't buy it ;) > | > | Maybe you have some better ideas about optional types as a > | specification... > | Semi-automatic RoelTyper like helper tools? > | > | Nicolas > | > | > _______________________________________________ > | > Pharo-project mailing list > | > Pharo-project(a)lists.gforge.inria.fr > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | > > | > | _______________________________________________ > | Pharo-project mailing list > | Pharo-project(a)lists.gforge.inria.fr > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 20, 2009

Re: [Pharo-project] '' asNumber -> 'Reading a number failed'

by Mariano Martinez Peck

On Mon, Oct 19, 2009 at 10:33 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Yes, I understand the paradigm, nil is nothing is zero, empty is > nothing is zero... > But frankly, do you think '' forms a valid Number ? In every context ? > So yes, this is expected, and can break compatibility, but sometimes > this is necessary. > > If you want to keep this behaviour, you have to use an explicit rule like: > asNumberOrZero > ^Number readFrom: self ifFail: [^0] > > Thanks Nicolas. Now, the question is, do you think we can create this method in String as part of Pharo core? or I should add it to my application? cheers mariano > Hope this helps... > > Nicolas > > 2009/10/20 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi folks: In older images, like 10418, '' asNumber gave me a 0 (zero). > But > > now, I get a 'Reading a number failed'. > > > > Is this expected? > > > > Perhaps it is due to the fix to this bug: > > > > > http://code.google.com/p/pharo/issues/detail?can=1&q=1258&colspec=ID%20Type… > > > > any toughs? > > > > best > > > > Mariano > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 20, 2009

Re: [Pharo-project] About TestCase >> assert:

by Dale Henrichs

Nicolas, many very good points. Just to add food for thought... double dispatching is a technique that has the benefit of avoiding isXXXX messages completely allowing for maximum flexibility and if the message isn't understood, immediate feedback that the programmer has done something wrong (which can be fixed by implementing the appropriate dispatch method) ... better than an assertion failures perhaps... Of course, double dispatching is not without it's drawbacks. I prefer double dispatching to implementing isXXX messages, but then I'd like to eliminate Booleans, too:) Dale ----- "Nicolas Cellier" <nicolas.cellier.aka.nice(a)gmail.com> wrote: | 2009/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: | > | >> I think Smalltalk quality is based on a completly different plane | > | | First, my reference about quality is not Squeak, I rather mean st-80 | from ParcPlace :) | At least it used to have | - more generous class and method comments | - less bugs and obscure code (certainly because less code too !) | - a certain homogeneity (less programmers ?) | | So were is the Smalltalk quality ? | - the ability to test code as soon as written | - the ability to write small and simple code, | - the ability to write readable code, | - the ability to extend code | Are these essential properties in the quality standards used in static | typing ? | | > You mean not checkable documentation, absence of documentation, | > lack of static typing to document (because what would be good is to | > have a pluggable type system) | > | | I agree, lack of type can be seen as a weakness for documenting APIs. | As a workaround, we use funny parameter names (anArrayOfStrings). | Or we add a method comment (hem... at least we should). | I agree, all these comments will become false when code is changed, | and the quality will decrease... | As false as an outdated assertion... but silent... Maybe it's worse ? | Browsing senders, or inspecting the signature of message sent to, or | inserting a halt is sometimes our solutions... | I agree, this is not ideal. | | So yes, assertions as a public declaration of API could be good for | documenting. | And a good description of assertion failure can also provide | informative feedback to the user (more than a Debugger ?) | | What I do not like is defensive assertions as a potential barrier to | extendability, because they correspond to a static view of code, a | snapshot of current state. | Smalltalk state does and will change. The image is living, and class | structure not written on stone. | Rapidly changing code is definitely not accepted as a quality | standard... | | In a rapidly changing image, assertions could be a supplementary drag | against change... | Suppose I have a method accepting a String parameter P: p. | [p isString] assertWithDescription: 'method xxx only accept a | String as parameter P'. | Now maybe the method would have worked with a Text. I have been too | restrictive: | [p isCharacters] assertWithDescription: 'method xxx only accept | characters'. | Now someone introduce WideString, and my code only work with | ByteString. | [p isCharacters and: [p asString isByteString]] | assertWithDescription: 'method xxx only accept byte characters'. | Yes, but the method does not work with empty String, I add: | [p notEmpty] assertWithDescription: 'method xxx only accept non | empty strings'. | Nor does it with some control characters: | self assertPHasValidCharacters: p. | Fortunately someone then correct the WideString case, now I can | retract isByteString. | Unfortunately, p will be stored in an inst. var. with many public | interfaces... | Each time, I have to change all the false assertions in all senders | of | the core method that are in the public API... | And maybe some of these public APIs are driven by other public APIs | (you meet this in Smalltalk, didn't you?) | To avoid this I create a specific method | assertPIsValid: p | | sender | | sender := thisContext sender homeContext selector. | [p isCharacters] assertWithDescription: 'method ' , sender , ' | only accept characters'. | [p asString isByteString] assertWithDescription: 'method ' , | sender , ' only accept byte characters'. | [p notEmpty] assertWithDescription: 'method ' , sender , ' only | accept non empty strings'. | self assertPHasValidCharacters: p from: sender. | | But now, I can't see the assumption from within public API. I have to | browse implementors of assertPIsValid:, so I loose the immediate | documentation... | | And one day, a brilliant programmer decide a ReadStream on characters | would also be a good parameter P, with a minor change in the core | method... | Arghh, I don't want to advance the stream yet and do all my static | checks... | | In order to maximize extendability, can't we use extensible | assertions | like sending a message? | If we end up with | [p isAGoodParameterPForMyMessage] assert. | then I don't buy it ;) | | Maybe you have some better ideas about optional types as a | specification... | Semi-automatic RoelTyper like helper tools? | | Nicolas | | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 20, 2009

Re: [Pharo-project] #1339 - ODBC crashes vm

by Mariano Martinez Peck

On Mon, Oct 19, 2009 at 2:34 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Hello all, > > I decided to try the simplest of all possible tests to reproduce my ODBC > crash: start with a fresh beta image, load FFI and ODBC, and then try to > connect to a non-existent data source. It indeed crashes the Linux VM, and > the Windows VM hangs badly. > > Sorry about this next part: I marked it for 1.0. > > Bill: I could reproduce it in both OS. I saw there is some problem when the debugger stack is stored to disk. Could you please evaluate Preferences disable: #logDebuggerStackToFile And try again with valid DSN, user and password. Any difference? In my case the segmentation fault is in ODBCConnection >> sqlAllocConnect: cheers mariano > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 20, 2009

Re: [Pharo-project] '' asNumber -> 'Reading a number failed'

by Nicolas Cellier

Yes, I understand the paradigm, nil is nothing is zero, empty is nothing is zero... But frankly, do you think '' forms a valid Number ? In every context ? So yes, this is expected, and can break compatibility, but sometimes this is necessary. If you want to keep this behaviour, you have to use an explicit rule like: asNumberOrZero ^Number readFrom: self ifFail: [^0] Hope this helps... Nicolas 2009/10/20 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi folks:Â In older images, like 10418, '' asNumberÂ gave me a 0 (zero). But > now, I get a 'Reading a number failed'. > > Is this expected? > > Perhaps it is due to the fix to this bug: > > http://code.google.com/p/pharo/issues/detail?can=1&q=1258&colspec=ID%20Type… > > any toughs? > > best > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 20, 2009

Re: [Pharo-project] About TestCase >> assert:

by Nicolas Cellier

2009/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> I think Smalltalk quality is based on a completly different plane > First, my reference about quality is not Squeak, I rather mean st-80 from ParcPlace :) At least it used to have - more generous class and method comments - less bugs and obscure code (certainly because less code too !) - a certain homogeneity (less programmers ?) So were is the Smalltalk quality ? - the ability to test code as soon as written - the ability to write small and simple code, - the ability to write readable code, - the ability to extend code Are these essential properties in the quality standards used in static typing ? > You mean not checkable documentation, absence of documentation, > lack of static typing to document (because what would be good is to > have a pluggable type system) > I agree, lack of type can be seen as a weakness for documenting APIs. As a workaround, we use funny parameter names (anArrayOfStrings). Or we add a method comment (hem... at least we should). I agree, all these comments will become false when code is changed, and the quality will decrease... As false as an outdated assertion... but silent... Maybe it's worse ? Browsing senders, or inspecting the signature of message sent to, or inserting a halt is sometimes our solutions... I agree, this is not ideal. So yes, assertions as a public declaration of API could be good for documenting. And a good description of assertion failure can also provide informative feedback to the user (more than a Debugger ?) What I do not like is defensive assertions as a potential barrier to extendability, because they correspond to a static view of code, a snapshot of current state. Smalltalk state does and will change. The image is living, and class structure not written on stone. Rapidly changing code is definitely not accepted as a quality standard... In a rapidly changing image, assertions could be a supplementary drag against change... Suppose I have a method accepting a String parameter P: p. [p isString] assertWithDescription: 'method xxx only accept a String as parameter P'. Now maybe the method would have worked with a Text. I have been too restrictive: [p isCharacters] assertWithDescription: 'method xxx only accept characters'. Now someone introduce WideString, and my code only work with ByteString. [p isCharacters and: [p asString isByteString]] assertWithDescription: 'method xxx only accept byte characters'. Yes, but the method does not work with empty String, I add: [p notEmpty] assertWithDescription: 'method xxx only accept non empty strings'. Nor does it with some control characters: self assertPHasValidCharacters: p. Fortunately someone then correct the WideString case, now I can retract isByteString. Unfortunately, p will be stored in an inst. var. with many public interfaces... Each time, I have to change all the false assertions in all senders of the core method that are in the public API... And maybe some of these public APIs are driven by other public APIs (you meet this in Smalltalk, didn't you?) To avoid this I create a specific method assertPIsValid: p | sender | sender := thisContext sender homeContext selector. [p isCharacters] assertWithDescription: 'method ' , sender , ' only accept characters'. [p asString isByteString] assertWithDescription: 'method ' , sender , ' only accept byte characters'. [p notEmpty] assertWithDescription: 'method ' , sender , ' only accept non empty strings'. self assertPHasValidCharacters: p from: sender. But now, I can't see the assumption from within public API. I have to browse implementors of assertPIsValid:, so I loose the immediate documentation... And one day, a brilliant programmer decide a ReadStream on characters would also be a good parameter P, with a minor change in the core method... Arghh, I don't want to advance the stream yet and do all my static checks... In order to maximize extendability, can't we use extensible assertions like sending a message? If we end up with [p isAGoodParameterPForMyMessage] assert. then I don't buy it ;) Maybe you have some better ideas about optional types as a specification... Semi-automatic RoelTyper like helper tools? Nicolas > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 20, 2009

[Pharo-project] '' asNumber -> 'Reading a number failed'

by Mariano Martinez Peck

Hi folks: In older images, like 10418, '' asNumber gave me a 0 (zero). But now, I get a 'Reading a number failed'. Is this expected? Perhaps it is due to the fix to this bug: http://code.google.com/p/pharo/issues/detail?can=1&q=1258&colspec=ID%20Type… any toughs? best Mariano

Oct. 20, 2009