- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] readFrom: vs readFromString:

by David T. Lewis

On Sun, Oct 30, 2011 at 05:07:48PM +0100, Nicolas Cellier wrote: > There is a huge mess in #readFrom: implementation. > Some classes will signal trailing characters as a bug, some other > won't and will simply leave the stream positioned after the valid > part. > I propose to change this behaviour uniformly: > - readFrom: aStream will never fail on trailing chars (hey, it's a > stream, it's up to sender to interpret the tail) > - readFromString: aString will always forbid trailing char (it's not a > stream, so this garbage is most probably an error and cannot be > ignored silently) > > What do you think ? This sounds right to me. I suspect that it might be difficult to do this without breaking some external packages, but it does seem like the right thing to do. Dave

Oct. 30, 2011

[Pharo-project] Explorer shortcut opens an inspector

by Sean P. DeNigris

With Keymapping loaded via TWM, Cmd+shift+i brings up an inspector instead of an explorer (happens in both workspace and OB source pane), while doIt "anObject explore" does the right thing. Any ideas? Where do I look to see what KM is doing? Sean -- View this message in context: http://forum.world.st/Explorer-shortcut-opens-an-inspector-tp3953977p395397… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 30, 2011

Re: [Pharo-project] Still more problems with underscore

by Schwab,Wilhelm K

Mariano, As much as I don't like to adopt the position, all too common in other forums, that "you can't do that because I think it's ugly," I am forced to agree with Lucas. It's not that I care whether or not *you* have underscore assignments at your disposal, but having both really would be a broken mess. Is it simply that you want to type _ and get :=? YEARS ago, I offered a near optimal solution to the problem. Never did I hear anyone say they wanted _ in their sources; they wanted to see a back-arrow, and they especially didn't want type the extra character. So, the fix is obvious: an *optional* editor feature that hijacks a key (probably _), inserts :=, and when the option is set, deleting = takes with it any preceding :. Then one has "underscore assignment" with the reduced typing and the compiler and sources are never burdened with the ambiguities that can arise, and the hijacking of _ is optional for those who do not want it. If you want to simultaneously load code with and w/o underscore assignment, I agree with Lucas that you really need to fix the legacy code, maybe in a separate image(??) and then load the fixed code. Am I missing something? I'm trying to be helpful and honest at the same time. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Lukas Renggli [renggli(a)gmail.com] Sent: Sunday, October 30, 2011 2:16 PM To: Pharo-project(a)lists.gforge.inria.fr Cc: Benjamin Van Ryseghem Subject: Re: [Pharo-project] Still more problems with underscore > Hi guys. I still have problems with underscore in Pharo 1.3. I want to use > underscore in both ways: in selectors and as assigment. Who would tell the system what you mean? > If I do: Scanner allowUnderscoreAsAssignment: true. > then it works in selectrs but not in assigment. > > If I do String allowUnderscore. > then it works for assigment but stops working for selector. This is the point of the design. Maybe the prefix "allow" is not quite revealing enough, because you cannot have both. You load the old code with the setting set to true. You fix your broken assignments and you switch to false to use underscores. Squeak has decided to go another way and allow both cases kind of simultaneous. What a broken mess! Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 30, 2011

Re: [Pharo-project] [squeak-dev] readFrom: vs readFromString:

by Nicolas Cellier

2011/10/30 Sven Van Caekenberghe <sven(a)beta9.be>: > Nicolas, > > On 30 Oct 2011, at 17:07, Nicolas Cellier wrote: > >> There is a huge mess in #readFrom: implementation. >> Some classes will signal trailing characters as a bug, some other >> won't and will simply leave the stream positioned after the valid >> part. >> I propose to change this behaviour uniformly: >> - readFrom: aStream will never fail on trailing chars (hey, it's a >> stream, it's up to sender to interpret the tail) >> - readFromString: aString will always forbid trailing char (it's not a >> stream, so this garbage is most probably an error and cannot be >> ignored silently) >> >> What do you think ? > > Will that not break the idiom (lazy implementation) > > readFromString: string > Â Â Â Â ^ self readFrom: string readStream > > ? That's it, I would change for something like readFromString: aString | aStream newInstance | aStream := aString readString. newInstance := self readFrom: aStream. aStream atEnd ifFalse: [FormatError raise]. ^newInstance > > BTW, what I miss in Smalltalk is a way to read from some position to another without all the terrible copying, either from a stream or from a string. > There is ReadStream class>>on:from:to: but I recommend testing and testing again, because Stream implementation is ... not crystal clear. > Consider parsing something like this '2011-10-30T17:17:47+01:00', the fields are fixed and pretty simple, but I can't think of an efficient way to do it, can you ? > Don't know... Some pattern matching, maybe with a simple regexp. PEG might be simple too. Qualifying as "efficient" however raise the bar a bit high ;) Nicolas > Sven > > >

Oct. 30, 2011

Re: [Pharo-project] readFrom: vs readFromString:

by Schwab,Wilhelm K

There is certainly room for both approaches, and reading from a stream is the more logical time to stop at the end of valid input. There are times when I know the stream should be at its end, and I test for that in those cases. Dolphin contains some *ToText classes that do some very useful things (supporting both direction via #leftToRight: and #rightToLeft:), especially DateToText and TimeToText, which have a #format aspect. It's not really the same problem, but worth keeping in mind as we tackle this. The short version, +1. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Sunday, October 30, 2011 12:07 PM To: The general-purpose Squeak developers list; Pharo Development Subject: [Pharo-project] readFrom: vs readFromString: There is a huge mess in #readFrom: implementation. Some classes will signal trailing characters as a bug, some other won't and will simply leave the stream positioned after the valid part. I propose to change this behaviour uniformly: - readFrom: aStream will never fail on trailing chars (hey, it's a stream, it's up to sender to interpret the tail) - readFromString: aString will always forbid trailing char (it's not a stream, so this garbage is most probably an error and cannot be ignored silently) What do you think ? Nicolas

Oct. 30, 2011

Re: [Pharo-project] [ANN 1.3] One-Click #13315

by StÃ©phane Ducasse

Yes we will :) On Oct 30, 2011, at 4:04 PM, Marcus Denker wrote: > > On Oct 30, 2011, at 4:00 PM, Mariano Martinez Peck wrote: > >> Hi. There was some crash related to network changes... but I don't remember that much. Maybe Sven can help you. >> Attach here the dump file and the PharoDebug.log no problem. > > That should have been fixed in 13315... > > Now what would be nice is to run automatically all tests on the last VM on all three architectures. > Will we ever reach that goal? > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

Oct. 30, 2011

Re: [Pharo-project] Still more problems with underscore

by Lukas Renggli

> I don't agree that having both at the same time is a mess. In fact, I need > exactly that: > > 1) Sometimes I load code which uses _ as assigment > 2) Sometimes I load packages which use _ as selector (like Glorp). > > So now I cannot have both. It means that if I load Glorp, I cannot load code > that needs _ as assigment. > If I load code that needs _ as assigment, I cannot load Glorp. > > THAT means a "broken mess" for me. Why? You can change the setting before you load each individual package. It only affects code that is newly parsed, existing code continues to work the way it was compiled. This should encourage you to clean up the underscore assignment mess. There is really no reason to keep an underscore assignment. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 30, 2011

Re: [Pharo-project] Still more problems with underscore

by Alain Plantec

Le 30/10/2011 19:22, Mariano Martinez Peck a Ã©crit : > > 1) Sometimes I load code which uses _ as assigment > 2) Sometimes I load packages which use _ as selector (like Glorp). > > So now I cannot have both. It means that if I load Glorp, I cannot > load code that needs _ as assigment. > If I load code that needs _ as assigment, I cannot load Glorp. maybe I'm wrong but can't you load them as follow: 1: allow _ as assignment 2: then load the code that have _ as assignment 3: vorbid _ as assignment 4: then load Glorp Alain > > THAT means a "broken mess" for me. > > Thanks anyway. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch <http://www.lukas-renggli.ch> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 30, 2011

Re: [Pharo-project] Still more problems with underscore

by Mariano Martinez Peck

> > > > If I do String allowUnderscore. > > then it works for assigment but stops working for selector. > > This is the point of the design. Maybe the prefix "allow" is not quite > revealing enough, because you cannot have both. > > You load the old code with the setting set to true. You fix your > broken assignments and you switch to false to use underscores. > > Squeak has decided to go another way and allow both cases kind of > simultaneous. What a broken mess! > > I don't agree that having both at the same time is a mess. In fact, I need exactly that: 1) Sometimes I load code which uses _ as assigment 2) Sometimes I load packages which use _ as selector (like Glorp). So now I cannot have both. It means that if I load Glorp, I cannot load code that needs _ as assigment. If I load code that needs _ as assigment, I cannot load Glorp. THAT means a "broken mess" for me. Thanks anyway. > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Mariano http://marianopeck.wordpress.com

Oct. 30, 2011

Re: [Pharo-project] Still more problems with underscore

by Lukas Renggli

> Hi guys. I still have problems with underscore in Pharo 1.3. I want to use > underscore in both ways: in selectors and as assigment. Who would tell the system what you mean? > If I do: Scanner allowUnderscoreAsAssignment: true. > then it works in selectrs but not in assigment. > > If I do String allowUnderscore. > then it works for assigment but stops working for selector. This is the point of the design. Maybe the prefix "allow" is not quite revealing enough, because you cannot have both. You load the old code with the setting set to true. You fix your broken assignments and you switch to false to use underscores. Squeak has decided to go another way and allow both cases kind of simultaneous. What a broken mess! Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 30, 2011