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

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

by GermÃ¡n Arduino

2010/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Thanks for your steady building approach > > +111111111111111 This is the attitude, Thanks Dale!

Feb. 24, 2010

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by Dale Henrichs

Doru, That is a good idea. It might also make sense from a Pharo perspective to have a global fallback defined. I am expecting that the mechanisms that we come up with will be useful for individual projects as well as Pharo overall, so building in flexibility at load time (instead of embedded in the configuration) is a good idea. To summarize my takeaway on this issue: - A pharo backup or secondary repository is a good solution to ensure that configurations and packages are "guaranteed" to survive over long periods of time regardless of the state of the primary project repositories - The secondary repository will be maintained by running a scraper script that scans the Metacello configurations that are critical to Pharo. - The script will copy the packages referenced by the configurations into the secondary repository. The configurations will also be copied into the repository. - Whether or not the configuration copies are modified to reference the secondary repository directly or not is still undefined. - This issue will be managed as a separate collection of packages to keep the core of Metacello clean. - The initial short term goal will be to provide a mechanism to do a "one-shot" checkpoint of configurations and packages (no configuration modification) so that a Pharo 1.0 repository of all of the important build artifacts can be archived in the event that the longer term goals aren't met in time. This initial short term goal will be based upon code already in use at GemStone to perform a similar function. - The second phase will be to work out the details of using the repository in real life conditions ... and at this point there are a number of possibilities under consideration. - More details when we get this far:) If I've missed something important, I'm sure you'll let me know:) Dale ----- "Tudor Girba" <tudor.girba(a)gmail.com> wrote: | Hi Dale, | | I believe the original problem is that you do not know upfront about | | where the actual files will be. In this case, perhaps the easiest | solution is to provide some scripting facility to provide a repository | | mapping that should could be modified at loading time, and not be | stored in the actual configuration. | | Suppose you have something like this: | | ConfigurationOfXXX>>baselineX: spec | <version: 'X-baseline'> | spec package: 'SomePackage' with: [ spec repository: 'SOME_URL' ]. | ... | | ConfigurationOfXXX>>versionX: spec | <version: 'X' imports: #('X-baseline')> | spec package: 'SomePackage' with: 'SomePackage.tg.1'. | ... | | | Maybe a solution would be that when loading you could say: | | (ConfigurationOfXXX project version: 'X') | withRepositoryMapping: 'SOME_URL' -> 'SOME_NEW_URL'; | withRepositoryMapping: '...' -> '...'; | load | | What do you think? | | In this way, the original configuration specifies everything, and the | | URL works either as the actual URL or as an alias that can be mapped | | to something else later on when you know the actual URL. Actually, | this can already be accomplished at engine level. I believe a simple | | scripting like above would just make it practical. What do you think? | | Cheers, | Doru | | | On 23 Feb 2010, at 21:18, Dale Henrichs wrote: | | > | > ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | > | > | > Perhaps Gofer can be provided with a secondary repository | location | > | in the case when the primary repository fails. | > | | > | Yes, it can. You just specify multiple repositories and it will | use | > | them all. If you tell Gofer to #disableRepositoryErrors then it | will | > | silently ignore repositories that are not available. | > | > Lukas, | > | > The only thing that worries about including such repository all of | | > the time, is the cost of building the cache of repository when | > resolving repositories ... the secondary repository would get pretty | | > large over time and most of the time (only in the case of errors) | > would it need to be scanned. | > | > I suppose Metacello could handle load errors in the code that calls | | > Gofer and do a retry using the secondary repository...the secondary | | > repository _could_ be specified as part of the configuration, so | > this probably isn't a bad idea... | > | > Thanks, | > | > Dale | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | -- | www.tudorgirba.com | | "Every thing has its own flow."

Feb. 24, 2010

Re: [Pharo-project] hex

by Nicolas Cellier

2010/2/24 <csrabak(a)bol.com.br>: > Stef, > > Squeak prints in lowercase and reads *correctly* only in uppercase. . . > > -- > Cesar Rabak > I think recent trunk version read both correctly. Did you try recently? Nicolas > > Em 24/02/2010 04:05, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > >> The main reason for not using lowercase in squeak was Dan extension of >> number with radix plus exponent. >> 16r8e7 -> 16r8 * (16 raisedTo: 7) >> and the Float variations... >> >> If you decided to abandon this notation, then go with either upper or lower. >> But a bit of consistency could help... > > I'm confused what is the situation now in squeak? > Because it seems that hex in squeak now prints and read lowercase? > So did > Â 16r8e7 and float > so will someone fix squeak to be consistent. > I'm a bit confused by the decision process in squeak (even if I should not worried too much). > > 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

Feb. 24, 2010

Re: [Pharo-project] hex

by csrabak＠bol.com.br

Stef, Squeak prints in lowercase and reads *correctly* only in uppercase. . . -- Cesar Rabak Em 24/02/2010 04:05, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > The main reason for not using lowercase in squeak was Dan extension of > number with radix plus exponent. > 16r8e7 -> 16r8 * (16 raisedTo: 7) > and the Float variations... > > If you decided to abandon this notation, then go with either upper or lower. > But a bit of consistency could help... I'm confused what is the situation now in squeak? Because it seems that hex in squeak now prints and read lowercase? So did 16r8e7 and float so will someone fix squeak to be consistent. I'm a bit confused by the decision process in squeak (even if I should not worried too much). Stef _______________________________________________ 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] HelpSystem & Class comments

by Torsten Bergmann

Andreas wrote: >What I'm looking for is a mechanism by which the documentation can >remain in the image even when HelpSystem is absent Why? Do you have test cases subclasses in the image when SUnit is absent? No. I think you want to have support or UI stuff removed/separated (like the viewer) - but a basic model should remain. The costs for the basic help system model support is minimal. Similar to SUnit. If you have the core model (TestCase) you are able to load/process tests done in subclasses. But with a separated UI you have the freedom for an exchangable TestRunner. Same should apply here. >What I'm looking for is a mechanism by which the documentation can >remain in the image even when HelpSystem is absent. So when HelpSystem >is loaded it needs to discover available books. Is there some tag/marker >mechanism by which one can flag those pre-existing books? > >(*hand waiving*) Maybe we should return to a pragma based solution. I originally had something like this. Just load "HelpSystem-Core-tbn.4" and have a look at class HelpHowTo methods. They have a "help" pragram. The pragma processing mechanism is in HelpBuilder>>createBookFrom: Danny removed this to introduce a HelpContent class (to support different content) - which I merged into HelpPage later. >That's why I was saying, why not derive >help books from class comments? How? Would you create a class for each page and use their class comment for the contents? >the only thing I'm asking for is just a tiny bit of additional structure >in a class comment so that one can have sections etc. As I said - maybe we should reactivate some Scamper code and use a markup language. The Parser from "Network-HTML" package on SqS.com/Scamper seems to work. Although it still uses _ instead of :=. We "just" have to rebuld a clean viewer. >We could start with simple Wiki syntax which can be used in >class comments and other simple places. If people feel unsatisfied or >need more or want to use HelpSystem for other purposes, extend it as >desired. We already discussed this and decided to first start with plain text and later add different content types (markup, active bookmorphs, ...) after getting the tool integration and other capabilities done. (I already pointed to the original discussion on pharo-dev) Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

Feb. 24, 2010

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

by Adrian Lienhard

Javier, Yes, I can build a linux VM (on OSX) from a Pharo image. I always build B3DAcceleratorPlugin as an internal plugin. Cheers, Adrian On Feb 24, 2010, at 09:30 , Mariano Martinez Peck wrote: > 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] withAllSubclasses -> Set or OrderedCollection

by Nicolas Cellier

Ah, I just found this starting point: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/143063.… 2010/2/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > The impact is: > - breaking some tools (easy to fix with asSet) I can't tell you > which... I saw an update recently related to this change. > - speeding up some other tools (unecessary asSet is unecessary cost) > - increasing Kernel consistency (selectors, instVarNames, > classVarNames don't return a Set). > > The speed-up gained by eliminating all these useless Set is visible in the IDE. > > Nicolas > > 2010/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Since this is obvious that in a tree you do not get twice the same node >> I was wondering why in the first place a set was returned. >> So apparently I'm not the only to not know and I was then curious about the >> impact of the changes. >> I was more interested in the impact of the changes that its justification :) >> >> http://code.google.com/p/pharo/issues/detail?id=2071 >> >> Stef >> >> On Feb 24, 2010, at 9:33 AM, Nicolas Cellier wrote: >> >>> 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 >>>> >>> >>> _______________________________________________ >>> 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] withAllSubclasses -> Set or OrderedCollection

by Nicolas Cellier

The impact is: - breaking some tools (easy to fix with asSet) I can't tell you which... I saw an update recently related to this change. - speeding up some other tools (unecessary asSet is unecessary cost) - increasing Kernel consistency (selectors, instVarNames, classVarNames don't return a Set). The speed-up gained by eliminating all these useless Set is visible in the IDE. Nicolas 2010/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Since this is obvious that in a tree you do not get twice the same node > I was wondering why in the first place a set was returned. > So apparently I'm not the only to not know and I was then curious about the > impact of the changes. > I was more interested in the impact of the changes that its justification :) > > http://code.google.com/p/pharo/issues/detail?id=2071 > > Stef > > On Feb 24, 2010, at 9:33 AM, Nicolas Cellier wrote: > >> 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 >>> >> >> _______________________________________________ >> 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] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by StÃ©phane Ducasse

Ok so we could fix that easily I imagine Stef On Feb 24, 2010, at 12:59 PM, Lukas Renggli wrote: >> Do you have an estimate of the code that you would break? > > It breaks the methods given above. > > 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

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

> Do you have an estimate of the code that you would break? It breaks the methods given above. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 24, 2010