- Pharo-dev - lists.pharo.org

Re: [Pharo-project] withAllSubclasses -> Set or OrderedCollection

by Nicolas Cellier

2010/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > this was not really my question :) I know that a tree does not twice the same node > do you know when it changed in squeak or pharo and the reason? > > Stef I return the question: so why answer a Set ? For multiple inheritance experiments or for some tools conveniency ? Nicolas > > On Feb 23, 2010, at 11:02 PM, Nicolas Cellier wrote: > >> The single inheritance hierarchy is a Tree... >> I don't see any interest in answering a Set. >> Some tools might expect a Set... >> If so, they just have to use withAllSubclasses asSet. >> >> If my own tool expect a LinkedList, I ain't gonna change the Kernel >> library for my conveniency, or am I ? >> >> Nicolas >> >> 2010/2/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Nicolas I remember that we discussed this point or a related one a while ago >>> >>> Squeak >>> >>> Â Â Â Â Point withAllSubclasses >>> Â Â Â Â Â Â Â Â an OrderedCollection(Point) >>> >>> >>> Pharo >>> >>> Â Â Â Â Point withAllSubclasses >>> Â Â Â Â Â Â Â Â a Set(Point) >>> >>> Do you remember? >>> I forgot? >>> >>> Stef >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >

Feb. 24, 2010

Re: [Pharo-project] Pharo won't make a VM in linux

by Mariano Martinez Peck

Javier: I cannot help you, but I can advice you to ask this VM related questions not only in Pharo but also in the VM mailing list: vm-dev(a)lists.squeakfoundation.org as you will probably receive more help :) Cheers Mariano 2010/2/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > Made some tests to find out what is happening, and found the problem. I can > confirm that this happens both in squeak and pharo. The thing is that > B3DAccelerator doesn't work as internal plugin in unix. Making it external > worked fine. > > This lead me to some questions: > > - To make it work as internal the only thing needed is to add that -lGL to > the linking process. Does anybody know how to modify the cmake files to do > that? Maybe it's just a thing of adding a line to > unix/plugins/B3DAcceleratorPlugin/config.cmake or unix/vm/config.cmake?? > > - Does anybody build the VM in unix? using cmake? > > Regards, > Javier. > > > On Mon, Feb 22, 2010 at 1:07 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > >> I'm cross-posting to vm-dev because I get the same errors with Squeak >> 3.10.2.7179 image. I have >> >> GL_VERSION = 3.2.0 NVIDIA 190.53 >> >> After navigating trough the makefiles, I found I was right, it's not >> linking to opengl. The linking command was autogenerated and sitting in >> blddir/CMakeFiles/squeakvm.dir/link.txt. Adding -lGL to it solved that >> problem. Does anybody know what caused the missing "-lGL" and how to solve >> it? >> >> Now I can get back to trying to compile alien! >> >> Regards, >> Javier. >> >> >> >> But I don't think it's a version problem, these undefined functions are >> there since OpenGL 1. the >> >> On Sun, Feb 21, 2010 at 4:27 PM, Martin McClure <martin(a)hand2mouse.com>wrote: >> >>> Javier PimÃ¡s wrote: >>> > >>> > Linking C executable squeakvm >>> > >>> > >>> > B3DAcceleratorPlugin/libB3DAcceleratorPlugin.a(sqOpenGLRenderer.c.o): >>> In >>> > function >>> > `glRenderVertexBuffer': >>> > >>> > >>> /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:846: >>> > undefined reference to >>> > `glColorMaterial' >>> > >>> /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:847: >>> > undefined reference to >>> > `glGetError' >>> > >>> /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:848: >>> > undefined reference to >>> > `glEnable' >>> > >>> /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:849: >>> > undefined reference to `glGetError' >>> > >>> > ... >>> > >>> > >>> /home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:159: >>> > undefined reference to `glLightModelfv' >>> > >>> /home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:160: >>> > undefined reference to `glGetError' >>> > collect2: ld returned 1 exit status >>> > make[2]: *** [squeakvm] Error 1 >>> > make[1]: *** [CMakeFiles/squeakvm.dir/all] Error 2 >>> > make: *** [all] Error 2 >>> > >>> > >>> > Maybe it should be linking to opengl lib but it isn't, what do you >>> think? >>> >>> What version of OpenGL do you have installed on your machine? I haven't >>> looked at the details, but I believe that the interface changed quite a >>> lot between OpenGL 1.x and OpenGL 2.x, so if B3D is expecting 2.x and >>> you have 1.x, or the other way around, you might get problems like this. >>> >>> Regards, >>> >>> -Martin >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > 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 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