February 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by Igor Stasenko

On 24 February 2010 10:15, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/2/24 Lukas Renggli <renggli(a)gmail.com>: >>> Huh? I am always assumed that binary selectors parsed in greedy >>> manner, which means that if parser found the start of >>> binary selector, it scans forward for following characters which can >>> be part of selector, without exceptions, like '-' char.. >> >> I checked in the ANSI standard. Igor is right: >> >> == ANSI: 3.5.6 Numbers ====== >> >> Â binaryCharacter ::= '!' | '%' | '&'' | '*' | '+' | ','' | '/' | '<' >> | '=' | '>' | '?' | '@' | '\' | '~' | '|' | '-' >> Â binarySelector ::= binaryCharacter+ >> >> Binary selectors are method selectors that appear similar to >> mathematical operators. A binary selector may be any length greater >> than or equal to one. If a negative <number literal> follows a binary >> selector there must intervening white space." >> >> ========================= >> >> I somehow remembered the grammar differently and that the $- was only >> allowed in the first position. This doesn't seem to be the case though >> (any longer) :-/ >> >> I am not against changing the grammar to conform to ANSI and VW. I >> think that would actually be a good move, even if it is probably not >> really relevant in practice. I am however strongly against asking the >> user to disambiguate an expression. The compiler should compile what >> the user types, not guess what else he could have ment to say. >> >> Lukas >> > > Then the question is how you compile 1@-2 and how you provide backward > compatibility. > As i said, i was always assumed that our parser works as ANSI says.. So, personally, i don't care about those who not followed it :) But yes, compatibility is now an issue :( Darn, why introducing a non-uniformity in syntax in a such way? When i hearing "hey, smalltalk expressions don't follow the 'usual' operators order of priority", i was always said - we don't need a non-uniform rules which complicating the syntax! But now , what a shame.. we actually having those! :) > Nicolas > >> -- >> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 24, 2010

Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by Nicolas Cellier

2010/2/24 Lukas Renggli <renggli(a)gmail.com>: >> Huh? I am always assumed that binary selectors parsed in greedy >> manner, which means that if parser found the start of >> binary selector, it scans forward for following characters which can >> be part of selector, without exceptions, like '-' char.. > > I checked in the ANSI standard. Igor is right: > > == ANSI: 3.5.6 Numbers ====== > > Â binaryCharacter ::= '!' | '%' | '&'' | '*' | '+' | ','' | '/' | '<' > | '=' | '>' | '?' | '@' | '\' | '~' | '|' | '-' > Â binarySelector ::= binaryCharacter+ > > Binary selectors are method selectors that appear similar to > mathematical operators. A binary selector may be any length greater > than or equal to one. If a negative <number literal> follows a binary > selector there must intervening white space." > > ========================= > > I somehow remembered the grammar differently and that the $- was only > allowed in the first position. This doesn't seem to be the case though > (any longer) :-/ > > I am not against changing the grammar to conform to ANSI and VW. I > think that would actually be a good move, even if it is probably not > really relevant in practice. I am however strongly against asking the > user to disambiguate an expression. The compiler should compile what > the user types, not guess what else he could have ment to say. > > Lukas > Then the question is how you compile 1@-2 and how you provide backward compatibility. Nicolas > -- > 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 >

Feb. 24, 2010

Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by Nicolas Cellier

2010/2/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/2/24 Igor Stasenko <siguctua(a)gmail.com>: >> On 24 February 2010 09:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> After the lengthly discussion about the fact that Smalltalk implementation is a balkan region >>> (cf "what Pharo/squeak do not parse 16rFF) >>> >>>> Authorize - at any position in binary selectors (like VW 7.7) >>>> See http://bugs.squeak.org/view.php?id=3616 >>>> Address the problem of compiling 1@-2 with following strategy: >>>> >>>> If compiler is non interactive, then compile with backward compatibility 1 @ (-2). >>>> If compiler is interactive, propose a menu to disambiguate and insert a proper space. >>>> 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 >>>> 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 >>>> >>>> Warning: Squeak did understand (1@- Â 2) as (1 @ (-2)).... >>>> I didn't do anything to support this vicious Squeakism, and by now the semantics are change. >>> >>> >>> I was wondering what do we do with that kind of changes. >>> Â Â Â Â Is it useful? >>> Â Â Â Â what is the end user case? >>> Â Â Â Â what are the binary operators that we could invent with -~- -| -@ >>> Â Â Â Â nicolas do you have a case in mind? >>> Â Â Â Â what VW people use it for? >>> >>> Now do we want this in pharo? >>> What is the cost? >>> Impact / broken code? >>> >> >> Huh? I am always assumed that binary selectors parsed in greedy >> manner, which means that if parser found the start of >> binary selector, it scans forward for following characters which can >> be part of selector, without exceptions, like '-' char.. >> > > This is precisely the reason I want to change this Behaviour for long. > It was an arbitrary, un-necessary limitation. Like Igor, I prefer uniformity. > The fact that VW did it influenced my decision to act. > >> so, >> 1--2 Â should ALWAYS mean: Â MessageSend receiver: 1 selector: #'--' argument: 2 >> >> and if you want an unary minus, you should put the white space or braces: >> 1 -- -2 >> 1 -- (-2) >> > > And this is precisely how things work now in trunk. > Beside, I forbid (- Â Â 2) which was authorized more accidentally than > intentionnally IMO. > > Nicolas > Oups, wrote to fast ! 1--2 now compiles 1 - (-2) for obvious backward compatibility reasons (1@-2) in batch mode (you import or recompile code). But it request disambiguation in interactive mode. If I would adopt Igor strategy that I like better, then I would break code. I want smooth transition. Nicolas >> >>>> >>> >>> Stef >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2010

Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by StÃ©phane Ducasse

thanks for the answer. Now since this is not top priority for me, if somebody check and produce a slice for pharo it will happen else it will be postponed. Note that for me the API of the compiler sucks and I would prefer to use cycle for fixing it. Stef On Feb 24, 2010, at 9:09 AM, Nicolas Cellier wrote: > 2010/2/24 Igor Stasenko <siguctua(a)gmail.com>: >> On 24 February 2010 09:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> After the lengthly discussion about the fact that Smalltalk implementation is a balkan region >>> (cf "what Pharo/squeak do not parse 16rFF) >>> >>>> Authorize - at any position in binary selectors (like VW 7.7) >>>> See http://bugs.squeak.org/view.php?id=3616 >>>> Address the problem of compiling 1@-2 with following strategy: >>>> >>>> If compiler is non interactive, then compile with backward compatibility 1 @ (-2). >>>> If compiler is interactive, propose a menu to disambiguate and insert a proper space. >>>> 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 >>>> 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 >>>> >>>> Warning: Squeak did understand (1@- 2) as (1 @ (-2)).... >>>> I didn't do anything to support this vicious Squeakism, and by now the semantics are change. >>> >>> >>> I was wondering what do we do with that kind of changes. >>> Is it useful? >>> what is the end user case? >>> what are the binary operators that we could invent with -~- -| -@ >>> nicolas do you have a case in mind? >>> what VW people use it for? >>> >>> Now do we want this in pharo? >>> What is the cost? >>> Impact / broken code? >>> >> >> Huh? I am always assumed that binary selectors parsed in greedy >> manner, which means that if parser found the start of >> binary selector, it scans forward for following characters which can >> be part of selector, without exceptions, like '-' char.. >> > > This is precisely the reason I want to change this Behaviour for long. > It was an arbitrary, un-necessary limitation. Like Igor, I prefer uniformity. > The fact that VW did it influenced my decision to act. > >> so, >> 1--2 should ALWAYS mean: MessageSend receiver: 1 selector: #'--' argument: 2 >> >> and if you want an unary minus, you should put the white space or braces: >> 1 -- -2 >> 1 -- (-2) >> > > And this is precisely how things work now in trunk. > Beside, I forbid (- 2) which was authorized more accidentally than > intentionnally IMO. > > Nicolas > >> >>>> >>> >>> Stef >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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

Feb. 24, 2010

Re: [Pharo-project] Why a package management system

by StÃ©phane Ducasse

> > > Just for the record. I truly look forward to the day when a better package management system comes along. > > If Metacello spurs some folks with "obviously better ideas" to produce a Package Management system that we can all use, then it will have been worth the effort:) > > Until the better mousetrap appears, I will continue to slog along on Metacello. this is the only strategy. build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn and may be swicth build use learn build use learn build use learn build use learn Thanks for your steady building approach

Feb. 24, 2010

Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by Nicolas Cellier

2010/2/24 Igor Stasenko <siguctua(a)gmail.com>: > On 24 February 2010 09:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> After the lengthly discussion about the fact that Smalltalk implementation is a balkan region >> (cf "what Pharo/squeak do not parse 16rFF) >> >>> Authorize - at any position in binary selectors (like VW 7.7) >>> See http://bugs.squeak.org/view.php?id=3616 >>> Address the problem of compiling 1@-2 with following strategy: >>> >>> If compiler is non interactive, then compile with backward compatibility 1 @ (-2). >>> If compiler is interactive, propose a menu to disambiguate and insert a proper space. >>> 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 >>> 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 >>> >>> Warning: Squeak did understand (1@- Â 2) as (1 @ (-2)).... >>> I didn't do anything to support this vicious Squeakism, and by now the semantics are change. >> >> >> I was wondering what do we do with that kind of changes. >> Â Â Â Â Is it useful? >> Â Â Â Â what is the end user case? >> Â Â Â Â what are the binary operators that we could invent with -~- -| -@ >> Â Â Â Â nicolas do you have a case in mind? >> Â Â Â Â what VW people use it for? >> >> Now do we want this in pharo? >> What is the cost? >> Impact / broken code? >> > > Huh? I am always assumed that binary selectors parsed in greedy > manner, which means that if parser found the start of > binary selector, it scans forward for following characters which can > be part of selector, without exceptions, like '-' char.. > This is precisely the reason I want to change this Behaviour for long. It was an arbitrary, un-necessary limitation. Like Igor, I prefer uniformity. The fact that VW did it influenced my decision to act. > so, > 1--2 Â should ALWAYS mean: Â MessageSend receiver: 1 selector: #'--' argument: 2 > > and if you want an unary minus, you should put the white space or braces: > 1 -- -2 > 1 -- (-2) > And this is precisely how things work now in trunk. Beside, I forbid (- 2) which was authorized more accidentally than intentionnally IMO. Nicolas > >>> >> >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 24, 2010

Re: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)

by StÃ©phane Ducasse

looks like a good master or PhD :) Interesting but need more cycle to think and play with it. Stef On Feb 24, 2010, at 8:36 AM, Igor Stasenko wrote: > Few more words. > > Deltas/packages. > > All we need for Delta is to identify the starting point (an image > state, from where you started changing it). In contrast to > DeltaStreams model, where it tries to capture both an 'old' and 'new' > state, so it can be reverted, we don't need it anymore, > since we can directly see what was the image state before we applied > the changes to it. Having all of the history preserved and tracked is > very powerful thing! > So, Delta only needs to reference to starting point (URI or some ID, > which identifies it, and in case of need can be easily found on the > web). > > What is cool about it? > Suppose, initially, all images started from some release (say Pharo > 1.0), so all users sharing the same sources/image state. > Now what happens when you start forking or making changes? > Users creating a deltas and storing them in the database , and their > images now knowing that they are derived from Pharo 1.0 point but also > has some changes stored in separate branch or 'fork'. > > Now, what happens if user wants to load the changes made by another > user: system can easily find the common ancestral point (since all > deltas knowing its own ancestral point). > And there is two use cases: > a) you doing a full synchronization with some remote source. This is > useful, when all of us want to use the very same image. This is > primarily a good thing for team-based development or Releases(R). > b) you doing a partial synchronization (or merge) with remote source. > In this case you creating own fork, which derived from , say Pharo 1.0 > + some changes from user Foo, Bar, Baz etc and getting own, unique > version of image. > > So no matter in what way you hacking/mixing the changes, you never > lost track of the system history, which means that for any two images > which derived from some common ancestral point we could could always > automatically generate a diff between them. It means that no matter > how far you went in your hacking - others could always load or > cherry-pick your code! > > Packages? Since model, i describing, operating at lower granularity > level (individual changes to methods/classes/doits), which means that > any package can be represented as a set of those > methods/classes/doits, there should be no problem > integrating/interacting at a package level. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 24, 2010

Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by Lukas Renggli

> Huh? I am always assumed that binary selectors parsed in greedy > manner, which means that if parser found the start of > binary selector, it scans forward for following characters which can > be part of selector, without exceptions, like '-' char.. I checked in the ANSI standard. Igor is right: == ANSI: 3.5.6 Numbers ====== binaryCharacter ::= '!' | '%' | '&'' | '*' | '+' | ','' | '/' | '<' | '=' | '>' | '?' | '@' | '\' | '~' | '|' | '-' binarySelector ::= binaryCharacter+ Binary selectors are method selectors that appear similar to mathematical operators. A binary selector may be any length greater than or equal to one. If a negative <number literal> follows a binary selector there must intervening white space." ========================= I somehow remembered the grammar differently and that the $- was only allowed in the first position. This doesn't seem to be the case though (any longer) :-/ I am not against changing the grammar to conform to ANSI and VW. I think that would actually be a good move, even if it is probably not really relevant in practice. I am however strongly against asking the user to disambiguate an expression. The compiler should compile what the user types, not guess what else he could have ment to say. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 24, 2010

Re: [Pharo-project] Why a package management system

by Janko MivÅ¡ek

On 24. 02. 2010 02:55, Dale Henrichs wrote: > If Metacello spurs some folks with "obviously better ideas" to produce a Package Management system that we > can all use, then it will have been worth the effort:) > Until the better mousetrap appears, I will continue to slog along on Metacello. That's a good plan, Dale. Metacello has a momentum right now and with continuing it has a chance to become a de-facto tool on top of Monticello for PMS. I just hope that the momentum will continue to some decent GUI tools as well :) Best regards Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Feb. 24, 2010

Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by Igor Stasenko

On 24 February 2010 09:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > After the lengthly discussion about the fact that Smalltalk implementation is a balkan region > (cf "what Pharo/squeak do not parse 16rFF) > >> Authorize - at any position in binary selectors (like VW 7.7) >> See http://bugs.squeak.org/view.php?id=3616 >> Address the problem of compiling 1@-2 with following strategy: >> >> If compiler is non interactive, then compile with backward compatibility 1 @ (-2). >> If compiler is interactive, propose a menu to disambiguate and insert a proper space. >> 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 >> 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 >> >> Warning: Squeak did understand (1@- Â 2) as (1 @ (-2)).... >> I didn't do anything to support this vicious Squeakism, and by now the semantics are change. > > > I was wondering what do we do with that kind of changes. > Â Â Â Â Is it useful? > Â Â Â Â what is the end user case? > Â Â Â Â what are the binary operators that we could invent with -~- -| -@ > Â Â Â Â nicolas do you have a case in mind? > Â Â Â Â what VW people use it for? > > Now do we want this in pharo? > What is the cost? > Impact / broken code? > Huh? I am always assumed that binary selectors parsed in greedy manner, which means that if parser found the start of binary selector, it scans forward for following characters which can be part of selector, without exceptions, like '-' char.. so, 1--2 should ALWAYS mean: MessageSend receiver: 1 selector: #'--' argument: 2 and if you want an unary minus, you should put the white space or braces: 1 -- -2 1 -- (-2) >> > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 24, 2010