Re: [Pharo-project] Trying to build alien plugin in linux
Torsten and JB: it would be cool to create a new metacello configuration version with this new version of VMMaker, puting the fix about the baseHeaderSize and integrating JB fixes to VMMaker. Cheers Mariano On Tue, Feb 23, 2010 at 7:55 AM, Fernando olivero wrote: > > On Feb 23, 2010, at 4:19 AM, John M McIntosh wrote: > > > > > On 2010-02-22, at 6:48 PM, Javier Pimás wrote: > > > >> > > > >> Lastly, as I said when I loaded Alien Core the first time, I got this > error while loading it: > >> > >> Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". > >> > >> What should I do about that? ignore it? > > > > Well it seems to be related to > > > > ((Smalltalk includesKey: #ObjectMemory) > >and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien > ifAbsent: []) ~~ (index - 1)]) ifTrue: > > [self error: 'index probably wrong']. > > > > Usually people don't have ObjectMemory loaded in their image, and I"m not > sure what it is check for. > > Why don't you try it in a regular Pharo image versus your VMMaker image. > > Great work Jorge! Nice to know you won the battle against VMMaker! > > The ensure in special objects array error, has to do with some missing > classes as John pointed out. > > The smalltalk special objects array has hardcoded indexes for some relevant > classes ( Globals) in the system. > In the alien configuration i've just ensured that the size should be 53, > before loading Alien, because the Alien code installs itself in that array > at positions 54 and 55. > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Mariano and me are writing a chapter about metacello. We can put a draft on the web. Stef On Feb 22, 2010, at 8:32 AM, Fernando olivero wrote: > I think this scenario of usage is really great! Good work Torsten. > > Would be a shame that this example got lost in the emails list. > For starting from scratch and getting to know metacello is perfect. > > Could the Metacello group add it to the web page? Or a link in the Pharo > website, in a tutorials section? > > Fernando > > On Feb 22, 2010, at 1:12 AM, Torsten Bergmann wrote: > >> FYI, see >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/144820.html >> >> >> -- >> Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - >> jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo website homepage
thanks laurent! Stef On Feb 22, 2010, at 6:37 PM, laurent laffont wrote: > Hi, > > Discussing with Stephane I was thinking that pharo website homepage could be > far less verbose in order to attract, guide newcomers better. IMHO it's a > very important point for Pharo 1.0. > I like the Rails homepage http://rubyonrails.org/, especially the Get Excited > / Started / Better / Involved. > > What do you think ? > > Laurent Laffont > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Help system now for Squeak and Pharo
Cool Danny what we could do is to define a pragma that we could use to tag public tests that are published in the help. Let us know and we can give a try to see. Stef On Feb 22, 2010, at 7:50 PM, Danny Chan wrote: > Hi! > > I like the idea. On the weekend I hacked a bit of code to generate help pages > from the class and methods comments. I have just added another bit of code > that sorts the documentation for all methods so that methods with a > pragma appear in a special section. See the "Help on Help" pages in the > browser. > > And I just learned that you can load this with > (ConfigurationOfHelpSystem project version: '1.0-baseline') load. > > Danny > > Am Sonntag, 21. Februar 2010 23:39:16 schrieb Stéphane Ducasse: >> Torsten / Danny >> >> I was discussing with laurent and I like his idea. >> We could tag >> test with >> >> >> and the tests would be used for the Help. We could design test that are >> more for understanding than identifying bugs and we would have a win-win >> situation: documentation and always in sync. >> >> doing the same for class comments would be nice. >> Often in a package you have one or two important classes. >> >> This would be a good incentive to get cool comments. >> >> On Feb 19, 2010, at 5:00 PM, Torsten Bergmann wrote: >>> Since we share tools and code - we may in the future also >>> share (in-image) documentation for tools. What is new: >>> >>> - Refactored and updated the code >>> - Help System is now usable in Pharo and Squeak too >>> - Metacello config is updated for both >>> - there is an initial help for the Pharo project and the Squeak project >>>(depending on from where you load it) >>> - the help for the help system is displayed as last book >>> - I merged HelpContents into a new HelpPage - so we have books and >>> pages (we may later add other forms than text in subclasses like >>> HTMLHelpPage, ...) >>> >>> The help browser includs a book on how to provide/implement an own >>> custom help. Future version may include specific colored icons for >>> squeak and better UI depending on the UI system (Polymorph in Squeak) >>> as well as authoring tools. >>> >>> Thanks to Metacello one is able to manage the differences. To load: >>> >>> Squeak >>> == >>> >>> Installer ss project: 'MetacelloRepository'; >>> install: 'ConfigurationOfHelpSystem'. >>> >>>((Smalltalk at: #ConfigurationOfHelpSystem) project version: '1.0') >>> load >>> >>> >>> Pharo >>> = >>> >>>Gofer new >>> squeaksource: 'MetacelloRepository'; >>> package: 'ConfigurationOfHelpSystem'; >>> load. >>> >>>((Smalltalk at: #ConfigurationOfHelpSystem) project version: '1.0') >>> load >>> >>> >>> Bye >>> T. >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Browse classes with shortcut in merge
Will happen in the next update :) On Feb 22, 2010, at 7:19 PM, Gary Chambers wrote: > Certainly possible. Needs an update for Polymorph as well as the Diff tools. > Will only be available when the "changes tree" has keyboard focus, also... > > Will do cmd+n for senders, cmd+m for implementors and cmd+v for versions > while at it. > Also, I'll update the menu items to indicate shortcuts. > > Regards, Gary > - Original Message - > From: Mariano Martinez Peck > To: Pharo Development > Cc: Gary Chambers > Sent: Friday, February 19, 2010 2:57 PM > Subject: Browse classes with shortcut in merge > > Hi Gary: It would be cool to be able to browse a class (when selected) using > the shortcut (cmd + b). Right now you only can browse it using right button > -> Browse class > > Cheers > > Mariano > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Hi! Stéphane Ducasse wrote: > On Feb 22, 2010, at 10:27 AM, Göran Krampe wrote: > >> Stéphane Ducasse wrote: >>> So you are educating them >>> Frankly I stopped trying long time ago. >> Hey Stef, no need to be so sarcastic you know - several of us are in >> fact in BOTH communities. IMHO we all need to remember that. > > Do you think that I do not know it? [SNIP of lots of things you did in Squeak, no argument about that] > and in general **each** time this was a fight so I can say that I'm fed up > arguing. I am fully aware of the history here, as you know, but I still ask all involved (on BOTH sides) to try to remember that our two communities overlap substantially. And personally I think your characterization of the Squeak community is a tad black & white. ;) I also know you quite well Steph, after all these years, so I hardly even react when you use harsh words :) - still, lots of other people are new in our communities. I think it would be much more ... "becoming" (and fruitful) if we all could stop "trash talking" each other - especially those of us who play a "larger role". Just my 2 cents, would be interesting to hear views of other Pharaos on this subject. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web package documentation
I really like the idea! Continue pushing. Stef On Feb 22, 2010, at 9:23 PM, laurent laffont wrote: > Hi, > > I've worked on SimpleWebDoc http://magaloma.seasidehosting.st > (code here, http://www.squeaksource.com/SimpleWebDoc.html, proof-of-concept) > > Now it builds a package documentation overview by taking the first sentence > of each class comment (if it has comment). For example: > http://magaloma.seasidehosting.st/Traits > > So we can quickly see (I think) the composition of a package. > > Maybe we can have a similar thing with the new HelpSystem. > > Laurent Laffont > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Monticello repos when adding packages
Thanks we will intergate that http://code.google.com/p/pharo/issues/detail?id=2045 Stef On Feb 22, 2010, at 11:43 PM, Eliot Miranda wrote: > or add the attached which add a 'add to package...' to a selected package > > > > On Mon, Feb 22, 2010 at 4:17 AM, Gary Chambers > wrote: > Create your package, deselect any package. > Pick your existing repository spec. > Choose "add to package..." from the repo popup menu. > > Regards, Gary > > - Original Message - > From: "Germán Arduino" > To: > Sent: Monday, February 22, 2010 12:00 PM > Subject: Re: [Pharo-project] Monticello repos when adding packages > > > 2010/2/21 Torsten Bergmann : > > Hi, > > > > in Monticello: > > > > - when you open the browser you see a list of known > > repositories > > - when I select "+Package" and enter the name > > of a new package the right pane only shows > > the package-cache as valid repo and I have > > to add the repository using "+Repository" > > again - even when it is already known to the system > > > > Yes, is an annoying "feature". I don't know if exist another way, > but indeed, is not a good behaviour. > > > > Confusing, isnt it? Or is there an easier way? > > > > Thx > > T. > > > > Cheers. > Germán. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
2010/2/22 Torsten Bergmann > FYI, see > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/144820.html > > > Incredible. Your answer are always very valuable. Little comment. You said: "He creates a class "ConfigurationOfMyDatabaseDriver" since he learned that Metacello uses a simple class with methods to describe the load order and version of the packages that fit together." Maybe I am wrong, but I think that you SHOULDN'T be aware of the order. I mean, you should be able to write all the spec package: in ANY order and that should still work perfectly. The order is not defined by the order of the spec package: but using the required. Of course, maybe there are exceptions, but most of the time, the order should be determined by the dependencies (requires:) and not by the natural order of the invocations to spec package: Thanks again for this wonderful answer. I will incorporate most of that in the Metacello chapter. Can I ? Cheers Mariano -- > Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - > jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
You are probably right. I should not read squeak-dev anymore I spent my time trying to show that there is NO contradiction between innovation/fun and good and clean system. But I'm not fun enough or smart enough. Stef (a etoy haters that was so stupid that he translated the book of etoy in french, an idiot that wrote most of the squeak books available right now, one of the four amigos that created the squeak foundation, a guy that did this stupid squeak 3.9 - you know stef this guy without any vision that just wants a "commercial smalltalk" puck! No innovation just plain engineering ) On Feb 23, 2010, at 10:30 AM, Göran Krampe wrote: > Hi! > > Stéphane Ducasse wrote: >> On Feb 22, 2010, at 10:27 AM, Göran Krampe wrote: >> >>> Stéphane Ducasse wrote: So you are educating them Frankly I stopped trying long time ago. >>> Hey Stef, no need to be so sarcastic you know - several of us are in >>> fact in BOTH communities. IMHO we all need to remember that. >> >> Do you think that I do not know it? > [SNIP of lots of things you did in Squeak, no argument about that] > >> and in general **each** time this was a fight so I can say that I'm fed up >> arguing. > > I am fully aware of the history here, as you know, but I still ask all > involved (on BOTH sides) to try to remember that our two communities > overlap substantially. And personally I think your characterization of > the Squeak community is a tad black & white. ;) > > I also know you quite well Steph, after all these years, so I hardly > even react when you use harsh words :) - still, lots of other people are > new in our communities. > > I think it would be much more ... "becoming" (and fruitful) if we all > could stop "trash talking" each other - especially those of us who play > a "larger role". > > Just my 2 cents, would be interesting to hear views of other Pharaos on > this subject. > > regards, Göran > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] how to remove World?
I think that maybe it is a good idea to use the DummyUIManager and the MorphicUIManager from Pavel MinimalImage. We can put those classes in a repository called PharoMinimal or something similar. Then, you will be able to load both classes, run your image headless and before, evaluate something to set those classes as the current. Just an idea... On Tue, Feb 23, 2010 at 10:18 AM, Stéphane Ducasse < stephane.duca...@inria.fr> wrote: > this is a really good experiment > please continue > and let us know the results. > Stef > On Feb 22, 2010, at 8:21 PM, Esteban Lorenzano wrote: > > > I tried by starting pharo with a script: > > > > Project uiProcess suspend. > > Smalltalk > > snapshot: true > > andQuit: true. > > > > ...and the processing stop working after the #suspend (no > > snapshot:andQuit: happens :( ) > > > > On 2010-02-22 13:43:05 -0300, Lukas Renggli > > said: > > > >>> Is that also necessary for a headless Pharo/Squeak? > >> > >> No, it is not necessary. It saves a few CPU cycles because the event > >> polling stops, the #step methods on the visible morphs are not called > >> anymore, and the display is not updated any longer. > >> > >> Programmatically you can still do everything (headless or > >> non-headless). For example you can open morphs and move them around, > >> you just won't see a change on the screen. Code that have some > >> interaction with the GUI thread (like the debugger) might deadlock (or > >> hang) the system. > >> > >> Lukas > > > > > > > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Trying to build alien plugin in linux
Havent followed this thread and currently lacking some time. The VMMaker config is changeable, so go ahead. Take care that it also works in latest Squeak trunk. Since most VM maintainers use Squeak to build the VM this is essential to follow their progress. Would also be a great move if Alien would be available on Windows - this would open the door to interfacing with Win technologies like COM or .NET (and therefore wake more commercial interest in Pharo). Having Alien on major OS platforms would also allow to use Smalltalk<-> Java bridging technologies like JavaConnect/JNIPort, Bye T. Original-Nachricht > Datum: Tue, 23 Feb 2010 10:08:55 +0100 > Von: Mariano Martinez Peck > An: Pharo-project@lists.gforge.inria.fr > CC: Arnaud Jean-Baptiste , Torsten Bergmann > > Betreff: Re: [Pharo-project] Trying to build alien plugin in linux > Torsten and JB: it would be cool to create a new metacello configuration > version with this new version of VMMaker, puting the fix about the > baseHeaderSize and integrating JB fixes to VMMaker. > > Cheers > > Mariano > > On Tue, Feb 23, 2010 at 7:55 AM, Fernando olivero > wrote: > > > > > On Feb 23, 2010, at 4:19 AM, John M McIntosh wrote: > > > > > > > > On 2010-02-22, at 6:48 PM, Javier Pimás wrote: > > > > > >> > > > > > >> Lastly, as I said when I loaded Alien Core the first time, I got this > > error while loading it: > > >> > > >> Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". > > >> > > >> What should I do about that? ignore it? > > > > > > Well it seems to be related to > > > > > > ((Smalltalk includesKey: #ObjectMemory) > > >and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien > > ifAbsent: []) ~~ (index - 1)]) ifTrue: > > > [self error: 'index probably wrong']. > > > > > > Usually people don't have ObjectMemory loaded in their image, and I"m > not > > sure what it is check for. > > > Why don't you try it in a regular Pharo image versus your VMMaker > image. > > > > Great work Jorge! Nice to know you won the battle against VMMaker! > > > > The ensure in special objects array error, has to do with some missing > > classes as John pointed out. > > > > The smalltalk special objects array has hardcoded indexes for some > relevant > > classes ( Globals) in the system. > > In the alien configuration i've just ensured that the size should be 53, > > before loading Alien, because the Alien code installs itself in that > array > > at positions 54 and 55. > > > > > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Why a package management system
>So you are educating them >Frankly I stopped trying long time ago. No, I just tell them what I think is necessary to move forward. Other may be more educated here, it is just sharing MHO so others can to form an own opinion. >I think it would be much more ... "becoming" (and fruitful) if we all >could stop "trash talking" each other - especially those of us who play >a "larger role". +1 Meanwhile the Pharo community has grown with new members and many people dont care about old discussions. Let's use our energy to move forward and (if possible) share as much knowledge and code as long as parts of our communities overlap. I therefore would really like to see a common exchange mechanism used on both sides. I'm sure I'm not able to convince one or the other to use package systems like Metacello but at least I hope to make them think about the need of a more modular system. Bye T. "I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Why a package management system
>Maybe I am wrong, but I think that you SHOULDN'T be aware of the order. I >mean, you should be able to write all the spec package No, you are right. Usually in a PMS you just tell the dependencies and the load order is defined by the system based on that description. But I tried to be as close to the "Installer" script example as possible, so it was intended to use both interchangable in this context (although there is the noted difference). >Thanks again for this wonderful answer. I will incorporate most of that in >the Metacello chapter. Can I ? No problem. AFAIK posting to the lists are now MIT ;) Bye T. -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
On Feb 22, 2010, at 10:27 AM, Göran Krampe wrote: > Stéphane Ducasse wrote: >> So you are educating them >> Frankly I stopped trying long time ago. > > Hey Stef, no need to be so sarcastic you know - several of us are in > fact in BOTH communities. IMHO we all need to remember that. Do you think that I do not know it? Let me tell you something: - I pushed refactoring browser (without result - the only result once was a private like why do you say that refactoring is important) - SUnit (you remember that I even wrote a chapter to explain it you remember that I said that I will stop harvesting fixes if we have to put tests outside the image? I'm sur you do!) - cleaning (do you remember Kernel cleaning project?) - Better smaller images - we were the first ones to use MC for managing complex app like squeak (and some guys complained that this was stupid) and in general **each** time this was a fight so I can say that I'm fed up arguing. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] how to remove World?
this is a really good experiment please continue and let us know the results. Stef On Feb 22, 2010, at 8:21 PM, Esteban Lorenzano wrote: > I tried by starting pharo with a script: > > Project uiProcess suspend. > Smalltalk > snapshot: true > andQuit: true. > > ...and the processing stop working after the #suspend (no > snapshot:andQuit: happens :( ) > > On 2010-02-22 13:43:05 -0300, Lukas Renggli > said: > >>> Is that also necessary for a headless Pharo/Squeak? >> >> No, it is not necessary. It saves a few CPU cycles because the event >> polling stops, the #step methods on the visible morphs are not called >> anymore, and the display is not updated any longer. >> >> Programmatically you can still do everything (headless or >> non-headless). For example you can open morphs and move them around, >> you just won't see a change on the screen. Code that have some >> interaction with the GUI thread (like the debugger) might deadlock (or >> hang) the system. >> >> Lukas > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
On Tue, Feb 23, 2010 at 11:27 AM, Torsten Bergmann wrote: > >Maybe I am wrong, but I think that you SHOULDN'T be aware of the order. I > >mean, you should be able to write all the spec package > > No, you are right. Usually in a PMS you just tell the dependencies and the > load order is defined by the system based on that description. But I tried > to be as > close to the "Installer" script example as possible, so it was intended to > use both interchangable in this context (although there is the noted > difference). > Ahh okok. Prefect, we agree :) > > >Thanks again for this wonderful answer. I will incorporate most of that in > >the Metacello chapter. Can I ? > > No problem. AFAIK posting to the lists are now MIT ;) > > hahahhahahah thanks! > Bye > T. > > > > > -- > NEU: Mit GMX DSL über 1000,- ¿ sparen! > http://portal.gmx.net/de/go/dsl02 > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Help system now for Squeak and Pharo
On Mon, Feb 22, 2010 at 7:50 PM, Danny Chan wrote: > Hi! > > I like the idea. On the weekend I hacked a bit of code to generate help > pages > from the class and methods comments. I have just added another bit of code > that sorts the documentation for all methods so that methods with a > pragma appear in a special section. See the "Help on Help" pages in the > browser. > > And I just learned that you can load this with > (ConfigurationOfHelpSystem project version: '1.0-baseline') load. > > You should read about Metacello :) You can start by reading Torsten post...that will follow to the metacello links too http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/144820.html > Danny > > Am Sonntag, 21. Februar 2010 23:39:16 schrieb Stéphane Ducasse: > > Torsten / Danny > > > > I was discussing with laurent and I like his idea. > > We could tag > > test with > > > > > > and the tests would be used for the Help. We could design test that are > > more for understanding than identifying bugs and we would have a win-win > > situation: documentation and always in sync. > > > > doing the same for class comments would be nice. > > Often in a package you have one or two important classes. > > > > This would be a good incentive to get cool comments. > > > > On Feb 19, 2010, at 5:00 PM, Torsten Bergmann wrote: > > > Since we share tools and code - we may in the future also > > > share (in-image) documentation for tools. What is new: > > > > > > - Refactored and updated the code > > > - Help System is now usable in Pharo and Squeak too > > > - Metacello config is updated for both > > > - there is an initial help for the Pharo project and the Squeak > project > > > (depending on from where you load it) > > > - the help for the help system is displayed as last book > > > - I merged HelpContents into a new HelpPage - so we have books and > > > pages (we may later add other forms than text in subclasses like > > > HTMLHelpPage, ...) > > > > > > The help browser includs a book on how to provide/implement an own > > > custom help. Future version may include specific colored icons for > > > squeak and better UI depending on the UI system (Polymorph in Squeak) > > > as well as authoring tools. > > > > > > Thanks to Metacello one is able to manage the differences. To load: > > > > > > Squeak > > > == > > > > > > Installer ss project: 'MetacelloRepository'; > > >install: 'ConfigurationOfHelpSystem'. > > > > > > ((Smalltalk at: #ConfigurationOfHelpSystem) project version: '1.0') > > > load > > > > > > > > > Pharo > > > = > > > > > > Gofer new > > >squeaksource: 'MetacelloRepository'; > > >package: 'ConfigurationOfHelpSystem'; > > >load. > > > > > > ((Smalltalk at: #ConfigurationOfHelpSystem) project version: '1.0') > > > load > > > > > > > > > Bye > > > T. > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
2010/2/23 Torsten Bergmann > >So you are educating them > >Frankly I stopped trying long time ago. > > No, I just tell them what I think is necessary to move forward. > Other may be more educated here, it is just sharing MHO so others > can to form an own opinion. > > Your mail is excellent and show very well the advantages of work with Metacello. When I read the first article about Metacello don't figured out is power until I invested some time to learn it and developed some "ConfigurationOf..." and currently I think is an invaluable tool that help to put Pharo/Squeak at the "next level" :) > Let's use our energy to move forward and (if possible) share as much > knowledge and code as long as parts of our communities overlap. > > I therefore would really like to see a common exchange mechanism used > on both sides. > > I'm sure I'm not able to convince one or the other to use package > systems like Metacello but at least I hope to make them think about > the need of a more modular system. > > Package systems are needed to professional development and I think that Metacello is a very good tool. I'm happily using it. Germán. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Monticello repos when adding packages
Thanks Gary. I was not aware of this option. Germán. 2010/2/22 Gary Chambers > Create your package, deselect any package. > Pick your existing repository spec. > Choose "add to package..." from the repo popup menu. > > Regards, Gary > > - Original Message - > From: "Germán Arduino" > To: > Sent: Monday, February 22, 2010 12:00 PM > Subject: Re: [Pharo-project] Monticello repos when adding packages > > > 2010/2/21 Torsten Bergmann : > > Hi, > > > > in Monticello: > > > > - when you open the browser you see a list of known > > repositories > > - when I select "+Package" and enter the name > > of a new package the right pane only shows > > the package-cache as valid repo and I have > > to add the repository using "+Repository" > > again - even when it is already known to the system > > > > Yes, is an annoying "feature". I don't know if exist another way, > but indeed, is not a good behaviour. > > > > Confusing, isnt it? Or is there an easier way? > > > > Thx > > T. > > > > Cheers. > Germán. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- = Germán S. Arduino Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com = ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Monticello repos when adding packages
Thanks Eliot. 2010/2/22 Eliot Miranda > or add the attached which add a 'add to package...' to a selected package > > > > On Mon, Feb 22, 2010 at 4:17 AM, Gary Chambers > wrote: > >> Create your package, deselect any package. >> Pick your existing repository spec. >> Choose "add to package..." from the repo popup menu. >> >> Regards, Gary >> >> - Original Message - >> From: "Germán Arduino" >> To: >> Sent: Monday, February 22, 2010 12:00 PM >> Subject: Re: [Pharo-project] Monticello repos when adding packages >> >> >> 2010/2/21 Torsten Bergmann : >> > Hi, >> > >> > in Monticello: >> > >> > - when you open the browser you see a list of known >> > repositories >> > - when I select "+Package" and enter the name >> > of a new package the right pane only shows >> > the package-cache as valid repo and I have >> > to add the repository using "+Repository" >> > again - even when it is already known to the system >> > >> >> Yes, is an annoying "feature". I don't know if exist another way, >> but indeed, is not a good behaviour. >> >> >> > Confusing, isnt it? Or is there an easier way? >> > >> > Thx >> > T. >> > >> >> Cheers. >> Germán. >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Hi! Stéphane Ducasse wrote: > You are probably right. I should not read squeak-dev anymore I spent my time > trying to show > that there is NO contradiction between innovation/fun and good and clean > system. > But I'm not fun enough or smart enough. > > Stef (a etoy haters that was so stupid that he translated the book of etoy in > french, > an idiot that wrote most of the squeak books available right now, one of the > four amigos that created the squeak foundation, > a guy that did this stupid squeak 3.9 - you know stef this guy without any > vision that just wants a > "commercial smalltalk" puck! No innovation just plain engineering ) First you write "You are probably right" and then you write the above, you just can't stop can you? :) regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Hi! Torsten Bergmann wrote: >> So you are educating them >> Frankly I stopped trying long time ago. > > No, I just tell them what I think is necessary to move forward. > Other may be more educated here, it is just sharing MHO so others > can to form an own opinion. Right, discussion is good. And believe me - the squeak-dev community is NOT oblivious to the needs of a package system. I mean, come on, Monticello, SqueakMap, Universes etc etc - it all was around before Pharo was born. What I have seen so far in Metacello is indeed nothing new - the senarios and discussions about dependencies etc go lng way back. BUT... that *doesn't* mean I am passing any judgment on Metacello - IMHO all efforts are good per definition! :) I haven't formed an opinion myself. >> I think it would be much more ... "becoming" (and fruitful) if we all >> could stop "trash talking" each other - especially those of us who play >> a "larger role". > > +1 Thank you. > Meanwhile the Pharo community has grown with new members and many people > dont care about old discussions. > > Let's use our energy to move forward and (if possible) share as much > knowledge and code as long as parts of our communities overlap. Yes, exactly. > I therefore would really like to see a common exchange mechanism used > on both sides. > > I'm sure I'm not able to convince one or the other to use package > systems like Metacello but at least I hope to make them think about > the need of a more modular system. Ehm, "a more modular system" has been on the table since... hell, way back to Squeak 3.3! And yeah, even earlier of course - you can probably track it back to PARC if you try hard. :) :) Anyway, "common exchange mechanism" - I am working on Deltastreams which I even presented at Brest, though unfortunately colliding with the Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY this problem (fork interchange), and it was born in 2007: http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.html I and Igor are the ones working on it - and after Brest we have had very little time to move it forward. I still think it is a very important piece of the puzzle though. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
Hi all I would like that we have a discussion about how do we put in place an infrastructure to make sure that we can get metacello configuration working in 3/5 years from now. I think that there are two scenarios: MyProject == in my project I used metacello and I publish a config and if it breaks in the future this is my responsibility PublishedMyProjectIn = When I publish my project (for now I copy the configuration file from my repository to the one of metacello) in the metacelloPharo1.0 project, we could automatically pulled up all the necessary files and copy them in the 1.0 repository. This way we can shield and make sure that a project can be loaded. I would like to have MetacelloMetaRepository1.0 MetacelloMetaRepository1.1 MetacelloMetaRepository1.2 ... what do you think? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Goran another meta remark :) may be some people said in squeak-dev that we were not these bad guys after all and that we did some great stuff after all even if this was bitcounting and cleaning the dust bean and were kind of somehow right but I do not remember having seen people saying sometimes when we are implicitly mentioned in bad press. But this is life :) Stef Let me repeat myself again: I would love to see smalltalk/pharo used to do advanced UI, multitouch software, advanced multimedia applications, and any kind of advanced on the edge experimental attempt to change the world. I would love to convince my colleague http://insitu.lri.fr/metisse/ that smalltalk is as good as Python and C++ for that. For use there was never any opposition between good software engineering practices and innovation. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Pharo by Example is back on Lulu
Hi Folks, After much pain, PBE is back on Lulu: http://www.lulu.com/content/paperback-book/pharo-by-example/7522128 The problem seems to have been caused by embedded PDF figures, which messed up the fonts on several pages. By turning all th efigures into embedded PNGs, the problem finally went away. Cheers, - on ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Browse classes with shortcut in merge
In the latest Widgets/DiffTools on SqueakSource now. Regards, Gary - Original Message - From: "Stéphane Ducasse" To: Sent: Tuesday, February 23, 2010 9:16 AM Subject: Re: [Pharo-project] Browse classes with shortcut in merge > Will happen in the next update :) > > On Feb 22, 2010, at 7:19 PM, Gary Chambers wrote: > >> Certainly possible. Needs an update for Polymorph as well as the Diff >> tools. >> Will only be available when the "changes tree" has keyboard focus, >> also... >> >> Will do cmd+n for senders, cmd+m for implementors and cmd+v for versions >> while at it. >> Also, I'll update the menu items to indicate shortcuts. >> >> Regards, Gary >> - Original Message - >> From: Mariano Martinez Peck >> To: Pharo Development >> Cc: Gary Chambers >> Sent: Friday, February 19, 2010 2:57 PM >> Subject: Browse classes with shortcut in merge >> >> Hi Gary: It would be cool to be able to browse a class (when selected) >> using the shortcut (cmd + b). Right now you only can browse it using >> right button -> Browse class >> >> Cheers >> >> Mariano >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribió: I was thinking about this problem yesterday in the light of the packages moved by Lukas. We have a problem with the packages referenced by a ConfigurationOfXXX. The can disappear anytime. The repository can disappear anytime. So I thought that we need a dedicated hosting server where: - We have all the ConfigurationOfXXX (in the MetacelloRepository repo, just as now) - We copy there *all* the packages that conform a giver ConfigurationOfXXX>>versionXX: from the original repo to this dedicated repo. - There is *no way* to delete anything. This is a *write only, read always, delete never* repository. So maybe we need a modified squeaksource image there that disables delete/rename/move packages. Or maybe the metasource from Torsten (is that the name of the new app designed for Metacello) can add this requirement. Besides, the app can scan all the ConfigurationOfXXX and check for what ones are affected by a deletion of a package before permiting delete of the package. This way we can delete packages but also see what that will affect and correctly promptly. The point is, we need an independent, mostly never breaking metacello repository. Other idea will be to use google or github versioned repositories and from them build the published repo, so that when a package is deleted by accident or by mistake, it can be restored quickly. But I like more the previous version. What do you think? -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
Miguel Enrique Cobá Martinez wrote: > El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribió: > I was thinking about this problem yesterday in the light of the packages > moved by Lukas. > We have a problem with the packages referenced by a ConfigurationOfXXX. > The can disappear anytime. The repository can disappear anytime. > > So I thought that we need a dedicated hosting server where: > > - We have all the ConfigurationOfXXX (in the MetacelloRepository repo, > just as now) > - We copy there *all* the packages that conform a giver > ConfigurationOfXXX>>versionXX: from the original repo to this dedicated > repo. > - There is *no way* to delete anything. This is a *write only, read > always, delete never* repository. Sidenote: SqueakMap actually caches all URLs used for versions and if the original URL fails an SHA check it falls back on the cached file on the SqueakMap server. In that way it was meant to handle original URLs going stale or disappearing. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
>make sure that we can get metacello configuration working in 3/5 years from >now. We should also think about - mirroring. Currently in Metacello you give the repo hard coded in the baseline. Maybe it would be better to have an alias there and define the repo elsewhere (for instance in #versionXXX method). - offline work where on is working offline, behind a closed proxy. There are also companies that want to have an internal server. They do not want to rely on a public server even when it is 24*7. Did I already ask if we have the infrastructure/resources to run an own server (PharoSource, ...)? Bye T. c -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo by Example is back on Lulu
Glad to hear this! Good job! Alexandre On 23 Feb 2010, at 09:46, Oscar Nierstrasz wrote: > > Hi Folks, > > After much pain, PBE is back on Lulu: > > http://www.lulu.com/content/paperback-book/pharo-by-example/7522128 > > The problem seems to have been caused by embedded PDF figures, which > messed up the fonts on several pages. By turning all th efigures > into embedded PNGs, the problem finally went away. > > Cheers, > - on > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
El mar, 23-02-2010 a las 14:12 +0100, Göran Krampe escribió: > > Sidenote: SqueakMap actually caches all URLs used for versions and if > the original URL fails an SHA check it falls back on the cached file on > the SqueakMap server. > > In that way it was meant to handle original URLs going stale or > disappearing. > Does that mean that everything pushed to squeakmap can never be deleted? If that isn't true, then the problem is just pushed one step further. > regards, Göran > Thanks -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Hi Göran: Sorry by my intromision here, but want to say somethings :) 2010/2/23 Göran Krampe > Hi! > > Torsten Bergmann wrote: > >> So you are educating them > >> Frankly I stopped trying long time ago. > > > > No, I just tell them what I think is necessary to move forward. > > Other may be more educated here, it is just sharing MHO so others > > can to form an own opinion. > > Right, discussion is good. And believe me - the squeak-dev community is > NOT oblivious to the needs of a package system. I mean, come on, > Monticello, SqueakMap, Universes etc etc - it all was around before > Pharo was born. > > What I have seen so far in Metacello is indeed nothing new - the > senarios and discussions about dependencies etc go lng way back. > I'm on Squeak from old 3.2 times. And yes, a lot of discussions about packages, etc, but only discussions on most of cases. I think Metacello solves the dependencies questions very well and the other tools not (with exception of Universes probably, but abandoned now). Also Metacello provides all the features explained on the excellent mail of Torsten, assuring that the configurations will work with the time not breaking stuffs. The solution of using Metacello+Monticello is, imho, very simple, easy and productive and is here, available to us. :) > I therefore would really like to see a common exchange mechanism used > > on both sides. > > > > I'm sure I'm not able to convince one or the other to use package > > systems like Metacello but at least I hope to make them think about > > the need of a more modular system. > > Ehm, "a more modular system" has been on the table since... hell, way > back to Squeak 3.3! And yeah, even earlier of course - you can probably > track it back to PARC if you try hard. :) :) > hehe, I remember the 3.3 modules breaking almost all the things coming from 3.2. > > Anyway, "common exchange mechanism" - I am working on Deltastreams which > I even presented at Brest, though unfortunately colliding with the > Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY > this problem (fork interchange), and it was born in 2007: > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.html > > I and Igor are the ones working on it - and after Brest we have had very > little time to move it forward. I still think it is a very important > piece of the puzzle though. > > But Deltastreams are ready to use on production systems? Cheers. Germán. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Den 23.02.2010 13:00, skrev Göran Krampe: > Hi! > > Torsten Bergmann wrote: > >>> So you are educating them >>> Frankly I stopped trying long time ago. >>> >> No, I just tell them what I think is necessary to move forward. >> Other may be more educated here, it is just sharing MHO so others >> can to form an own opinion. >> > Right, discussion is good. And believe me - the squeak-dev community is > NOT oblivious to the needs of a package system. I mean, come on, > Monticello, SqueakMap, Universes etc etc - it all was around before > Pharo was born. > > What I have seen so far in Metacello is indeed nothing new - the > senarios and discussions about dependencies etc go lng way back. > > BUT... that *doesn't* mean I am passing any judgment on Metacello - IMHO > all efforts are good per definition! :) I haven't formed an opinion myself. > > No system is going to perfectly fulfill everyones perception of what would be "The Best Way"(tm), but as long as the need for functionality provided by a system is real, actually deciding on one, IS important. >From what I've seen in archive discussion, that seems to have been the biggest showstopper for noticeable progress in the Squeak community. Paradoxically, existing systems which clearly contain lousy code, are left in (or replacements objected to) on the basis of backwards-compatability... IMHO, this is the biggest difference between Squeak and Pharo I've seen. Sure, you can now unload Etoys from Squeak, your image will still contain code like ImageSegment>>findRogueRootsAllMorphs: though. Sure, you can new add Preferences with pragmas now, you still have a class with a Dictionary accessed and stored into by the entire system, and 1223 accessors for things local to specific packages though. Metacello is nothing new for sure, but contrary to other systems, it seems to have reached wide acceptance in Pharo. Understandably, many here feel it'd be nice if the "classic" Squeak-community decided to use it as well. Personally, I doubt it will happen (for any PMS really, as evidenced by Sake/Packages, as well as all the other previous attempts), yet I appreciate Torsten's and others effort to at least correct the plain-out misconceptions some people seem to have about deficiencies of Metacello. Pretty sure noone would argue Monticello is a perfect system either, achieving critical mass was though. >> Meanwhile the Pharo community has grown with new members and many people >> dont care about old discussions. >> >> Let's use our energy to move forward and (if possible) share as much >> knowledge and code as long as parts of our communities overlap. >> > Yes, exactly. > +1. > Anyway, "common exchange mechanism" - I am working on Deltastreams which > I even presented at Brest, though unfortunately colliding with the > Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY > this problem (fork interchange), and it was born in 2007: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.html > > I and Igor are the ones working on it - and after Brest we have had very > little time to move it forward. I still think it is a very important > piece of the puzzle though. > > regards, Göran I've been meaning to make system-change notifications for Pharo so the recording-part could work there too, but I never seem to get around to it :( Part of the problem is of course my own personal "The Best Way"(tm), which f.ex. would include Announcements. Since I'd like the ability to have Weak subscriptions, I'd first have to deoptimize the Announcement-package Levente made a bit to make it "prettier", make it a strict superset of what if found in Core already, fix WeakRegistry so each resource registered for an object actually gets finalized, which again means... etc... Oh, and hope it'd end up good enough that it'd warrant inclusion:) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
> IMHO, this is the biggest difference between Squeak and Pharo I've seen. > Sure, you can now unload Etoys from Squeak, your image will still > contain code like ImageSegment>>findRogueRootsAllMorphs: though. > Of courseand an infinitive number of Smalltalk at: #XXX ifPresent: ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Hi! Germán Arduino wrote: > Hi Göran: > > Sorry by my intromision here, but want to say somethings :) > > 2010/2/23 Göran Krampe mailto:go...@krampe.se>> [SNIP] > What I have seen so far in Metacello is indeed nothing new - the > senarios and discussions about dependencies etc go lng way back. > > > I'm on Squeak from old 3.2 times. And yes, a lot of discussions about > packages, > etc, but only discussions on most of cases. I think Metacello solves the > dependencies > questions very well and the other tools not (with exception of Universes > probably, but > abandoned now). Also Metacello provides all the features explained on > the excellent > mail of Torsten, assuring that the configurations will work with the > time not breaking > stuffs. > > The solution of using Metacello+Monticello is, imho, very simple, easy > and productive > and is here, available to us. :) I never claimed otherwise! I am just saying that there is nothing new - and frankly, though I admit not having read carefully, I didn't find the example so... impressive. Perhaps I need to read it again. Again though - I am not saying anything negative about Metacello. [SNIP] > Anyway, "common exchange mechanism" - I am working on Deltastreams which > I even presented at Brest, though unfortunately colliding with the > Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY > this problem (fork interchange), and it was born in 2007: > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.html > > I and Igor are the ones working on it - and after Brest we have had very > little time to move it forward. I still think it is a very important > piece of the puzzle though. > > But Deltastreams are ready to use on production systems? Nope, not yet, although very close. But since the topic came up I wanted to mention it. But AFAIK there is no other tool/project aimed at that use case. Again, I may be wrong :) regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
Hi, I am very interested in the whole configuration management, metacello, monticello, public/private repository, project, library/package, object, project, environment, release, version stuff ... some clarity around is badly needed. My first contact with the whole Squeak/Pharo packages and versioning was very confusing with SqueakSource, SqueakMap, Sake/Packages, Package Universe, Monticello. Why not look at other distributed version control systems like Darcs, Bazaar, GIT ... and see what could work for smalltalk? -- View this message in context: http://n4.nabble.com/Metacello-How-to-make-sure-that-we-will-be-able-to-load-in-3-years-from-now-tp1565830p1566000.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
and with that I did not mean to "use" those other DVCS but maybe take ideas from them :) -- View this message in context: http://n4.nabble.com/Metacello-How-to-make-sure-that-we-will-be-able-to-load-in-3-years-from-now-tp1565830p1566007.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo by Example is back on Lulu
Thank you Oscar for the great job ! On Tue, Feb 23, 2010 at 1:46 PM, Oscar Nierstrasz wrote: > > Hi Folks, > > After much pain, PBE is back on Lulu: > > http://www.lulu.com/content/paperback-book/pharo-by-example/7522128 > > The problem seems to have been caused by embedded PDF figures, which messed > up the fonts on several pages. By turning all th efigures into embedded > PNGs, the problem finally went away. > > Cheers, > - on > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11229
11229 - Issue 2035: use Behavior>>#methods and Behavior>>#selectors Issue 2043: clean codeloader a little This does a #releaseCleanup afterwards. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
> and with that I did not mean to "use" those other DVCS but maybe take ideas > from them :) This is not a problem any DVCS tackles. Rather take ideas of package management systems like aptitude, rpm, portage, fink, ... As you see in all such system, they ship the code (binary or source) together with the package definition. None of these mechanisms refer to the VCS where the code is developed, but they include all the dependencies they need. I was thinking more along of something of a SAR file that would include the Metacello configuration and all the referenced mcz files in one file. Dragging and dropping that file onto the image (or using some GUI) would bootstrap Metacello, execute the Metacello definition, and if necessary download and pull in other SAR files from a well known place. That's how Linux works quite successful for over a decade. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Diff tools
If you can describe exactly what you wish I'm sure it can be done ;-) ... Remember, conflicts are conflicts and *should* be checked on a one-by-one basis when merging. Regards, Gary - Original Message - From: "Stéphane Ducasse" To: Sent: Thursday, February 11, 2010 7:57 AM Subject: Re: [Pharo-project] Diff tools > gary > do we have resolved all conflict by taking the incoming? > and the inverse because in the old diff tools we could and this is handy. > > On Feb 9, 2010, at 4:24 PM, GARY CHAMBERS wrote: > >> New version on SqueakSource Polymorph-Tools-Diff-gvc.20. >> >> Descriptions added and small bug fix for merge tool (selecting next >> conflict now ignores "resolved" conflicts). >> >> Merge and select incoming for each conflict to load.. >> >> Regards, Gary >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Source code management - my vision. (Was: Re: Why a package management system)
Since Goran mentioned DeltaStreams, i'd like to share one of my ideas, which came into my mind, when i complete coding the method trailers. I made a method trailers open for future extensions. A first step would be to introduce an abstract 'source management' layer, which will be responsible for delivering a method's and classes sources from some abstract data source. The next step is actually implement such data sources. So, the idea is to abandon hardwiring with .sources and .changes files. What new opportunities it gives to us? Suppose that instead of storing sources into file, you putting them directly to database , such as CouchDB (yes! :). Now if you imagine that anyone could access to this database on some public location, this means that we automagically made a source code exchange hub, and could do a very cool things with it. Suppose that ALL source code is put into a single database. Now different users creating own accounts and makind own 'forks' from original. What we getting is a number of update streams (methods, doits etc etc), which lying in those databases, and if one user wants to load/merge code from one of the sources he simply points to it and it get loaded into his image. We could organize things very closely to what github currently is: everyone could create any number of new projects, or forks of existing ones. Freely exchange the code, do a cherry picking etc etc. And what is most important, that with such organization you can track any methods, classes in the image and their evolutionary history back to its origin. As well as, you can query database, how an when a concrete method/class get deleted (everything is recorded, not just current state). Also, it would allow us to manipulate the code at the lowest level of granularity (individual methods/classes/doits, same as DS does), not at a package level. There are a lot of synergy with DeltaStreams - it could serve as an 'offline' format, in same way as git storing the files locally, but can reconnect with remote storage (which can be a public database). One of the things, which could be made is to allow stashing/popping code from stash. Suppose two projects started from a single starting point (Squeak 3.9). Now suppose that by clicking a single button you could get either trunk image, or Pharo 1.0 image. But that's not all! With DeltaStreams, you could then click once more, and revert things back from , say Pharo 1.0 to trunk or vice versa :) Of course it would be stupid to do things at such large scale, but if we put some common 'root' stuff into database, then we could very easily track all changes & compare them. This would make cherry picking and code exchange much more easier. This could get us on the next level of code management and system organization and organization of community efforts. 2010/2/23 Göran Krampe : > Hi! > > Germán Arduino wrote: >> Hi Göran: >> >> Sorry by my intromision here, but want to say somethings :) >> >> 2010/2/23 Göran Krampe mailto:go...@krampe.se>> > [SNIP] >> What I have seen so far in Metacello is indeed nothing new - the >> senarios and discussions about dependencies etc go lng way back. >> >> >> I'm on Squeak from old 3.2 times. And yes, a lot of discussions about >> packages, >> etc, but only discussions on most of cases. I think Metacello solves the >> dependencies >> questions very well and the other tools not (with exception of Universes >> probably, but >> abandoned now). Also Metacello provides all the features explained on >> the excellent >> mail of Torsten, assuring that the configurations will work with the >> time not breaking >> stuffs. >> >> The solution of using Metacello+Monticello is, imho, very simple, easy >> and productive >> and is here, available to us. :) > > I never claimed otherwise! I am just saying that there is nothing new - > and frankly, though I admit not having read carefully, I didn't find the > example so... impressive. Perhaps I need to read it again. > > Again though - I am not saying anything negative about Metacello. > > [SNIP] >> Anyway, "common exchange mechanism" - I am working on Deltastreams which >> I even presented at Brest, though unfortunately colliding with the >> Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY >> this problem (fork interchange), and it was born in 2007: >> >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.html >> >> I and Igor are the ones working on it - and after Brest we have had very >> little time to move it forward. I still think it is a very important >> piece of the puzzle though. >> >> But Deltastreams are ready to use on production systems? > > Nope, not yet, although very close. But since the topic came up I wanted > to mention it. But AFAIK there is no other tool/project aimed at that > use case. Again, I may be wrong :) > > regards, Göran > > > ___ > Pharo-project ma
Re: [Pharo-project] Pharo won't make a VM in linux
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 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 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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)
Some kind of graph-based GUI would certainly help in this scenario to visualise the dependencies/changes... just a thought. Regards, Gary - Original Message - From: "Igor Stasenko" To: Sent: Tuesday, February 23, 2010 4:02 PM Subject: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system) > Since Goran mentioned DeltaStreams, i'd like to share one of my ideas, > which came into my mind, when i complete coding the method trailers. > > I made a method trailers open for future extensions. > A first step would be to introduce an abstract 'source management' > layer, which will be responsible for delivering > a method's and classes sources from some abstract data source. The > next step is actually implement such data sources. > > So, the idea is to abandon hardwiring with .sources and .changes files. > What new opportunities it gives to us? > Suppose that instead of storing sources into file, you putting them > directly to database , such as CouchDB (yes! :). > > Now if you imagine that anyone could access to this database on some > public location, this means that we automagically made a source code > exchange hub, and could do a very cool things with it. > > Suppose that ALL source code is put into a single database. Now > different users creating own accounts and makind own 'forks' from > original. What we getting is a number of update streams (methods, > doits etc etc), which lying in those databases, > and if one user wants to load/merge code from one of the sources he > simply points to it and it get loaded into his image. > We could organize things very closely to what github currently is: > everyone could create any number of new projects, or forks of existing > ones. Freely exchange the code, do a cherry picking etc etc. > And what is most important, that with such organization you can track > any methods, classes in the image and their evolutionary history back > to its origin. As well as, you can query database, how an when a > concrete method/class get deleted (everything is recorded, not just > current state). > > Also, it would allow us to manipulate the code at the lowest level of > granularity (individual methods/classes/doits, same as DS does), not > at a package level. > There are a lot of synergy with DeltaStreams - it could serve as an > 'offline' format, in same way as git storing the files locally, but > can reconnect with remote storage (which can be a public database). > One of the things, which could be made is to allow stashing/popping > code from stash. Suppose two projects started from a single starting > point (Squeak 3.9). Now suppose that by clicking a single button you > could get either trunk image, or Pharo 1.0 image. > But that's not all! With DeltaStreams, you could then click once more, > and revert things back from , say Pharo 1.0 to trunk or vice versa :) > Of course it would be stupid to do things at such large scale, but if > we put some common 'root' stuff into database, then we could very > easily track all changes & compare them. This would make cherry > picking and code exchange much more easier. > > This could get us on the next level of code management and system > organization and organization of community efforts. > > > > 2010/2/23 Göran Krampe : >> Hi! >> >> Germán Arduino wrote: >>> Hi Göran: >>> >>> Sorry by my intromision here, but want to say somethings :) >>> >>> 2010/2/23 Göran Krampe mailto:go...@krampe.se>> >> [SNIP] >>> What I have seen so far in Metacello is indeed nothing new - the >>> senarios and discussions about dependencies etc go lng way back. >>> >>> >>> I'm on Squeak from old 3.2 times. And yes, a lot of discussions about >>> packages, >>> etc, but only discussions on most of cases. I think Metacello solves the >>> dependencies >>> questions very well and the other tools not (with exception of Universes >>> probably, but >>> abandoned now). Also Metacello provides all the features explained on >>> the excellent >>> mail of Torsten, assuring that the configurations will work with the >>> time not breaking >>> stuffs. >>> >>> The solution of using Metacello+Monticello is, imho, very simple, easy >>> and productive >>> and is here, available to us. :) >> >> I never claimed otherwise! I am just saying that there is nothing new - >> and frankly, though I admit not having read carefully, I didn't find the >> example so... impressive. Perhaps I need to read it again. >> >> Again though - I am not saying anything negative about Metacello. >> >> [SNIP] >>> Anyway, "common exchange mechanism" - I am working on Deltastreams which >>> I even presented at Brest, though unfortunately colliding with the >>> Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY >>> this problem (fork interchange), and it was born in 2007: >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.html >>> >>> I and Igor are the ones working on it - and after Brest we have had
[Pharo-project] [ANN 1.1] pre-built Core#11229
http://gforge.inria.fr/frs/download.php/26457/PharoCore-1.1-11229-UNSTABLE.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
> > > Metacello is nothing new for sure, but contrary to other systems, it > seems to have reached wide acceptance in Pharo. > IMHO that's a key point. We don't need to have the best package management system, we need to have only ONE. Major Linux distributions are great for that. Ruby too (though there has been a lot of problems when github came in, you had to choose which fork of the gem you wanted to use, everybody fork. gemcutter has resolved this). When there will be needs to switch to another package management system, trash the old, only use the new one. So we can keep one way to load packages. Metacello is great :) Laurent Laffont. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] how to remove World?
Yes this is a good idea. May be the DummyUIManager should be by default in the system. Can you open a ticket? Stef > I think that maybe it is a good idea to use the DummyUIManager and the > MorphicUIManager from Pavel MinimalImage. > > We can put those classes in a repository called PharoMinimal or something > similar. Then, you will be able to load both classes, run your image headless > and before, evaluate something to set those classes as the current. > > Just an idea... > > On Tue, Feb 23, 2010 at 10:18 AM, Stéphane Ducasse > wrote: > this is a really good experiment > please continue > and let us know the results. > Stef > On Feb 22, 2010, at 8:21 PM, Esteban Lorenzano wrote: > > > I tried by starting pharo with a script: > > > > Project uiProcess suspend. > > Smalltalk > > snapshot: true > > andQuit: true. > > > > ...and the processing stop working after the #suspend (no > > snapshot:andQuit: happens :( ) > > > > On 2010-02-22 13:43:05 -0300, Lukas Renggli > > said: > > > >>> Is that also necessary for a headless Pharo/Squeak? > >> > >> No, it is not necessary. It saves a few CPU cycles because the event > >> polling stops, the #step methods on the visible morphs are not called > >> anymore, and the display is not updated any longer. > >> > >> Programmatically you can still do everything (headless or > >> non-headless). For example you can open morphs and move them around, > >> you just won't see a change on the screen. Code that have some > >> interaction with the GUI thread (like the debugger) might deadlock (or > >> hang) the system. > >> > >> Lukas > > > > > > > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Trying to build alien plugin in linux
I hope that we will get an engineer paid by inria but this will not be before september 2010. we should get some news in a couple of weeks. Stef On Feb 23, 2010, at 10:51 AM, Torsten Bergmann wrote: > Havent followed this thread and currently lacking some time. > The VMMaker config is changeable, so go ahead. > > Take care that it also works in latest Squeak trunk. > Since most VM maintainers use Squeak to build the VM this is > essential to follow their progress. > > Would also be a great move if Alien would be available on Windows - > this would open the door to interfacing with Win technologies like > COM or .NET (and therefore wake more commercial interest in Pharo). > Having Alien on major OS platforms would also allow to use Smalltalk<-> > Java bridging technologies like JavaConnect/JNIPort, > > Bye > T. > > Original-Nachricht >> Datum: Tue, 23 Feb 2010 10:08:55 +0100 >> Von: Mariano Martinez Peck >> An: Pharo-project@lists.gforge.inria.fr >> CC: Arnaud Jean-Baptiste , Torsten Bergmann >> >> Betreff: Re: [Pharo-project] Trying to build alien plugin in linux > >> Torsten and JB: it would be cool to create a new metacello configuration >> version with this new version of VMMaker, puting the fix about the >> baseHeaderSize and integrating JB fixes to VMMaker. >> >> Cheers >> >> Mariano >> >> On Tue, Feb 23, 2010 at 7:55 AM, Fernando olivero >> wrote: >> >>> >>> On Feb 23, 2010, at 4:19 AM, John M McIntosh wrote: >>> On 2010-02-22, at 6:48 PM, Javier Pimás wrote: > > Lastly, as I said when I loaded Alien Core the first time, I got this >>> error while loading it: > > Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". > > What should I do about that? ignore it? Well it seems to be related to ((Smalltalk includesKey: #ObjectMemory) and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien >>> ifAbsent: []) ~~ (index - 1)]) ifTrue: [self error: 'index probably wrong']. Usually people don't have ObjectMemory loaded in their image, and I"m >> not >>> sure what it is check for. Why don't you try it in a regular Pharo image versus your VMMaker >> image. >>> >>> Great work Jorge! Nice to know you won the battle against VMMaker! >>> >>> The ensure in special objects array error, has to do with some missing >>> classes as John pointed out. >>> >>> The smalltalk special objects array has hardcoded indexes for some >> relevant >>> classes ( Globals) in the system. >>> In the alien configuration i've just ensured that the size should be 53, >>> before loading Alien, because the Alien code installs itself in that >> array >>> at positions 54 and 55. >>> >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > > -- > NEU: Mit GMX DSL über 1000,- ¿ sparen! > http://portal.gmx.net/de/go/dsl02 > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo by Example is back on Lulu
We need to get some cool reviews now. :) Stef On Feb 23, 2010, at 1:46 PM, Oscar Nierstrasz wrote: > > Hi Folks, > > After much pain, PBE is back on Lulu: > > http://www.lulu.com/content/paperback-book/pharo-by-example/7522128 > > The problem seems to have been caused by embedded PDF figures, which messed > up the fonts on several pages. By turning all th efigures into embedded > PNGs, the problem finally went away. > > Cheers, > - on > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
neat! > >> El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribió: >> I was thinking about this problem yesterday in the light of the packages >> moved by Lukas. >> We have a problem with the packages referenced by a ConfigurationOfXXX. >> The can disappear anytime. The repository can disappear anytime. >> >> So I thought that we need a dedicated hosting server where: >> >> - We have all the ConfigurationOfXXX (in the MetacelloRepository repo, >> just as now) >> - We copy there *all* the packages that conform a giver >> ConfigurationOfXXX>>versionXX: from the original repo to this dedicated >> repo. >> - There is *no way* to delete anything. This is a *write only, read >> always, delete never* repository. > > Sidenote: SqueakMap actually caches all URLs used for versions and if > the original URL fails an SHA check it falls back on the cached file on > the SqueakMap server. > > In that way it was meant to handle original URLs going stale or > disappearing. > > regards, Göran > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
On Feb 23, 2010, at 2:25 PM, Torsten Bergmann wrote: >> make sure that we can get metacello configuration working in 3/5 years from >> now. > > We should also think about > > - mirroring. Currently in Metacello you give the repo hard coded in the > baseline. >Maybe it would be better to have an alias there and define the repo >elsewhere (for instance in #versionXXX method). > - offline work where on is working offline, behind a closed proxy. There are > also >companies that want to have an internal server. They do not want to rely >on a public server even when it is 24*7. > > Did I already ask if we have the infrastructure/resources to run an own > server (PharoSource, ...)? I requested inria to get a server with the correct webdav configuration but so far they were busy... > > Bye > T. > > c > -- > NEU: Mit GMX DSL über 1000,- ¿ sparen! > http://portal.gmx.net/de/go/dsl02 > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Diff tools
Gary sometimes I know (since for example I already checked all the conflicts but the system crashes for another reason) that I want to take all the incoming versions or the working copy ones. Right now I have to go over the list each time (even if I know what I'm doing). in the old merge there was such buttons. Stef On Feb 23, 2010, at 4:40 PM, Gary Chambers wrote: > If you can describe exactly what you wish I'm sure it can be done ;-) ... > Remember, conflicts are conflicts and *should* be checked on a one-by-one > basis when merging. > > Regards, Gary > > - Original Message - > From: "Stéphane Ducasse" > To: > Sent: Thursday, February 11, 2010 7:57 AM > Subject: Re: [Pharo-project] Diff tools > > >> gary >> do we have resolved all conflict by taking the incoming? >> and the inverse because in the old diff tools we could and this is handy. >> >> On Feb 9, 2010, at 4:24 PM, GARY CHAMBERS wrote: >> >>> New version on SqueakSource Polymorph-Tools-Diff-gvc.20. >>> >>> Descriptions added and small bug fix for merge tool (selecting next >>> conflict now ignores "resolved" conflicts). >>> >>> Merge and select incoming for each conflict to load.. >>> >>> Regards, Gary >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
> > > "I've learned that people will forget what you said, people will forget what > you did, but people will never forget how you made them feel." Exactly this is exactly my experience. :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
> > When I read the first article about Metacello don't figured out is power > until I invested some > time to learn it and developed some "ConfigurationOf..." and currently I > think is an > invaluable tool that help to put Pharo/Squeak at the "next level" :) Thanks. I'm really happy that dale started to push that (even if keith was doing the same with Sake) because since the first day we worked with MC and used MC to manage 3.9 we were aware that we need such mechanism. Expressing package dependency is key to system deployment scale. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
On Feb 23, 2010, at 12:49 PM, Göran Krampe wrote: > Hi! > > Stéphane Ducasse wrote: >> You are probably right. I should not read squeak-dev anymore I spent my time >> trying to show >> that there is NO contradiction between innovation/fun and good and clean >> system. >> But I'm not fun enough or smart enough. >> >> Stef (a etoy haters that was so stupid that he translated the book of etoy >> in french, >> an idiot that wrote most of the squeak books available right now, one of the >> four amigos that created the squeak foundation, >> a guy that did this stupid squeak 3.9 - you know stef this guy without any >> vision that just wants a >> "commercial smalltalk" puck! No innovation just plain engineering ) > > First you write "You are probably right" and then you write the above, > you just can't stop can you? :) Is it insulting for you when I say that I felt insulted and immensely sad? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
>> >> But Deltastreams are ready to use on production systems? > > Nope, not yet, although very close. But since the topic came up I wanted > to mention it. But AFAIK there is no other tool/project aimed at that > use case. Again, I may be wrong : BTW I like deltastream and your presentation at esug was convincing now this is important to try it for real before commiting. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
+ 1 let us work on the infrastructure. > Metacello is nothing new for sure, but contrary to other systems, it > seems to have reached wide acceptance in Pharo. > > IMHO that's a key point. We don't need to have the best package management > system, we need to have only ONE. Major Linux distributions are great for > that. Ruby too (though there has been a lot of problems when github came in, > you had to choose which fork of the gem you wanted to use, everybody > fork. gemcutter has resolved this). > > When there will be needs to switch to another package management system, > trash the old, only use the new one. So we can keep one way to load packages. > > Metacello is great :) > > Laurent Laffont. > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
> I've been meaning to make system-change notifications for Pharo so the > recording-part could work there too, but I never seem to get around to it :( > Part of the problem is of course my own personal "The Best Way"(tm), > which f.ex. would include Announcements. > Since I'd like the ability to have Weak subscriptions, I'd first have to > deoptimize the Announcement-package Levente made a bit to make it > "prettier", can you explain a bit more the technical aspect? > make it a strict superset of what if found in Core already, > fix WeakRegistry so each resource registered for an object actually gets > finalized, which again means... etc... Oh, and hope it'd end up good > enough that it'd warrant inclusion:) I would love to see a bit more enhancement on Announcement. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Diff tools
I'll give it a go (keyboard shortcuts included) in the next DiffTools version... I guess you won't want a warning dialog the "What you are choosing means that any conflicts will be unchecked"... ;-) So, "use incoming for all incoming conficts" and "use current for all conflicts"? Regards, Gary - Original Message - From: "Stéphane Ducasse" To: Sent: Tuesday, February 23, 2010 5:47 PM Subject: Re: [Pharo-project] Diff tools Gary sometimes I know (since for example I already checked all the conflicts but the system crashes for another reason) that I want to take all the incoming versions or the working copy ones. Right now I have to go over the list each time (even if I know what I'm doing). in the old merge there was such buttons. Stef On Feb 23, 2010, at 4:40 PM, Gary Chambers wrote: > If you can describe exactly what you wish I'm sure it can be done ;-) ... > Remember, conflicts are conflicts and *should* be checked on a one-by-one > basis when merging. > > Regards, Gary > > - Original Message - > From: "Stéphane Ducasse" > To: > Sent: Thursday, February 11, 2010 7:57 AM > Subject: Re: [Pharo-project] Diff tools > > >> gary >> do we have resolved all conflict by taking the incoming? >> and the inverse because in the old diff tools we could and this is handy. >> >> On Feb 9, 2010, at 4:24 PM, GARY CHAMBERS wrote: >> >>> New version on SqueakSource Polymorph-Tools-Diff-gvc.20. >>> >>> Descriptions added and small bug fix for merge tool (selecting next >>> conflict now ignores "resolved" conflicts). >>> >>> Merge and select incoming for each conflict to load.. >>> >>> Regards, Gary >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
A final point. Yes I was in a bad mood. When I replied to torsten. But mainly a bad mood against myself and my stupid idealistic idea that I could spend good energy fixing the world I like. Now I decided to spend it in Pharo. Stef On Feb 23, 2010, at 12:49 PM, Göran Krampe wrote: > Hi! > > Stéphane Ducasse wrote: >> You are probably right. I should not read squeak-dev anymore I spent my time >> trying to show >> that there is NO contradiction between innovation/fun and good and clean >> system. >> But I'm not fun enough or smart enough. >> >> Stef (a etoy haters that was so stupid that he translated the book of etoy >> in french, >> an idiot that wrote most of the squeak books available right now, one of the >> four amigos that created the squeak foundation, >> a guy that did this stupid squeak 3.9 - you know stef this guy without any >> vision that just wants a >> "commercial smalltalk" puck! No innovation just plain engineering ) > > First you write "You are probably right" and then you write the above, > you just can't stop can you? :) > > regards, Göran > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
If that was fixing the "World" (you know what I mean) then I understand :-) Regards, Gary - Original Message - From: "Stéphane Ducasse" To: Sent: Tuesday, February 23, 2010 6:04 PM Subject: Re: [Pharo-project] Why a package management system A final point. Yes I was in a bad mood. When I replied to torsten. But mainly a bad mood against myself and my stupid idealistic idea that I could spend good energy fixing the world I like. Now I decided to spend it in Pharo. Stef On Feb 23, 2010, at 12:49 PM, Göran Krampe wrote: > Hi! > > Stéphane Ducasse wrote: >> You are probably right. I should not read squeak-dev anymore I spent my >> time trying to show >> that there is NO contradiction between innovation/fun and good and clean >> system. >> But I'm not fun enough or smart enough. >> >> Stef (a etoy haters that was so stupid that he translated the book of >> etoy in french, >> an idiot that wrote most of the squeak books available right now, one of >> the four amigos that created the squeak foundation, >> a guy that did this stupid squeak 3.9 - you know stef this guy without >> any vision that just wants a >> "commercial smalltalk" puck! No innovation just plain engineering ) > > First you write "You are probably right" and then you write the above, > you just can't stop can you? :) > > regards, Göran > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] GemStone/S
Having investigated the virtual appliance (GLASS) http://seaside.gemstone.com/ for a potential upcoming project... It is in shocking state with regard to maintenance duties... We will be trying a native install with Pharo, of course. The question is whether anyone is interested in collaborating with producing some decent GUI tools for doing general administration tasks (backups, recovery, archival etc.)? A lot of scope for taking the pain out of maintaining such an environment... Regards, Gary ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Hi! Stéphane Ducasse wrote: > On Feb 23, 2010, at 12:49 PM, Göran Krampe wrote: > >> Hi! >> >> Stéphane Ducasse wrote: >>> You are probably right. I should not read squeak-dev anymore I spent my >>> time trying to show >>> that there is NO contradiction between innovation/fun and good and clean >>> system. >>> But I'm not fun enough or smart enough. >>> >>> Stef (a etoy haters that was so stupid that he translated the book of etoy >>> in french, >>> an idiot that wrote most of the squeak books available right now, one of >>> the four amigos that created the squeak foundation, >>> a guy that did this stupid squeak 3.9 - you know stef this guy without any >>> vision that just wants a >>> "commercial smalltalk" puck! No innovation just plain engineering ) >> First you write "You are probably right" and then you write the above, >> you just can't stop can you? :) > > Is it insulting for you when I say that I felt insulted and immensely sad? No, of course not, but... IMHO we have come to a point where some of us really want to work on sharing and cooperating between the two *overlapping* communities - and in that light these never ending "shots" are really not helping. And I am really trying to express this in my best humble and most respectful way, you know that. I love all the energy and work you personally pour into the Smalltalk community, you know that. I still wish you could... consider the fact I originally wrote: We overlap. And I really think the hostility is getting boring. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
I like the notion of a secondary repository for packages. It is absolutely necessary to protect us from a catastrophic failure with any one of the SqueakSource repositories. Perhaps Gofer can be provided with a secondary repository location in the case when the primary repository fails. With this kind of approach, the metacello configurations can continue to reference the primary development repository, in this way we might just be able to have our cake and eat it too:) The Pharo secondary repository would protect users from repository volatility and package volatility ... Once a version is published in Pharo you can count of being able to load that version over time. This secondary repository could be maintained by periodically scanning the Pharo configurations and copying the referenced packages from the primary repository to a known secondary repository (this repository could just be done with Apache file access since a fancy UI for the secondary repository isn't essential). Having code and processes in place means that individuals can reuse the code and process to maintain their own secondary repository for their own production environment. I have code that does most of what is needed, as I use this process at GemStone for archiving the configurations and mcz packages in our company source code control system. Dale - "Göran Krampe" wrote: | Miguel Enrique Cobá Martinez wrote: | > El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribió: | > I was thinking about this problem yesterday in the light of the | packages | > moved by Lukas. | > We have a problem with the packages referenced by a | ConfigurationOfXXX. | > The can disappear anytime. The repository can disappear anytime. | > | > So I thought that we need a dedicated hosting server where: | > | > - We have all the ConfigurationOfXXX (in the MetacelloRepository | repo, | > just as now) | > - We copy there *all* the packages that conform a giver | > ConfigurationOfXXX>>versionXX: from the original repo to this | dedicated | > repo. | > - There is *no way* to delete anything. This is a *write only, read | > always, delete never* repository. | | Sidenote: SqueakMap actually caches all URLs used for versions and if | the original URL fails an SHA check it falls back on the cached file | on | the SqueakMap server. | | In that way it was meant to handle original URLs going stale or | disappearing. | | regards, Göran | | | ___ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
> 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 -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GemStone/S
Hi Gary, > Having investigated the virtual appliance (GLASS) > http://seaside.gemstone.com/ > for a potential upcoming project... > It is in shocking state with regard to maintenance duties... > > We will be trying a native install with Pharo, of course. Cool! > The question is whether anyone is interested in collaborating with > producing some decent GUI tools for doing general administration > tasks (backups, recovery, archival etc.)? This is not directly related, but I had to raise my voice. I am interesting in enhancing the UI of Mondrian. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Yes and you are right. I was thinking too much about bad energy. :) Stef > Hi! > > Stéphane Ducasse wrote: >> On Feb 23, 2010, at 12:49 PM, Göran Krampe wrote: >> >>> Hi! >>> >>> Stéphane Ducasse wrote: You are probably right. I should not read squeak-dev anymore I spent my time trying to show that there is NO contradiction between innovation/fun and good and clean system. But I'm not fun enough or smart enough. Stef (a etoy haters that was so stupid that he translated the book of etoy in french, an idiot that wrote most of the squeak books available right now, one of the four amigos that created the squeak foundation, a guy that did this stupid squeak 3.9 - you know stef this guy without any vision that just wants a "commercial smalltalk" puck! No innovation just plain engineering ) >>> First you write "You are probably right" and then you write the above, >>> you just can't stop can you? :) >> >> Is it insulting for you when I say that I felt insulted and immensely sad? > > No, of course not, but... IMHO we have come to a point where some of us > really want to work on sharing and cooperating between the two > *overlapping* communities - and in that light these never ending "shots" > are really not helping. > > And I am really trying to express this in my best humble and most > respectful way, you know that. I love all the energy and work you > personally pour into the Smalltalk community, you know that. > > I still wish you could... consider the fact I originally wrote: We > overlap. And I really think the hostility is getting boring. > > regards, Göran > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Diff tools
On Feb 23, 2010, at 7:04 PM, Gary Chambers wrote: > I'll give it a go (keyboard shortcuts included) in the next DiffTools > version... > I guess you won't want a warning dialog the "What you are choosing means > that any conflicts will be unchecked"... ;-) :) > So, "use incoming for all incoming conficts" and "use current for all > conflicts"? Yeap! ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GemStone/S
Gary, > The question is whether anyone is interested in collaborating with producing > some decent GUI tools for doing general administration tasks (backups, > recovery, archival etc.)? Its not GUI tools but its quite decent. Subjectively speaking of course: http://github.com/ottobehrens/gemstone-scripts I am much more comfortable with command line management of my production environments :-) -- Danie Roux *shuffle* Adore Unix - http://danieroux.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Trying to build alien plugin in linux
On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh < john...@smalltalkconsulting.com> wrote: > > On 2010-02-22, at 6:48 PM, Javier Pimás wrote: > > Nice It's compiling now. Now, I loaded tests, and here are the > results: > > 37 run, 17 passed, 0 failures, 20 errors. > > TestCallingSequenceChar10Long2 > TestCallingSequenceChar2LongLong2 > TestCallingSequenceChar8Long2 > TestCallingSequenceChar9Long2 > TestCallingSequenceCharLongLong2 > TestCallingSequenceChars > TestCallingSequenceDoubles14 > TestCallingSequenceDoubles2 > TestCallingSequenceFloats13 > TestCallingSequenceFloats14 > TestCallingSequenceFloats2 > TestCallingSequenceFloats2WithInteger > TestCallingSequenceFloats2WithInteger2 > TestCallingSequenceFloats7 > TestCallingSequenceInt > TestCallingSequenceInt8 > TestCallingSequenceIntWithFloatArgs > TestCallingSequenceLongLong2 > TestCallingSequenceShort > TestCallingSequenceString > > > Oh look SUnits, great stuff (*cough* well I wrote most of them). > > Cool, this is really really useful (although I sometimes find wrting tests boring ;) ). > > > It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why > should it try to load itself, if it's compiled as an internal plugin? I > compiled it as external too but didn't work either. > > > Well it compiled, but that doesn't mean it works. In fact the error means > the plugin code is never loaded, or is callable. > Now one thing to consider is that the plugin load fails, because it can't > find it. (external usage). > Or because (internal and external plugin) the VM Version and the plugin > version don't match. > > Look for your definition of > #define VM_PROXY_MINOR 8 > > It should be 8 or higher for compiling BOTH the VM and the Plugin. > Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is mass > confusion about which header is being used? > > If for example your VM say it's a VM_PROXY_MINOR of 7, then it won't work > with a plugin compiled with VM_PROXY_MINOR = 8. > It silently fails... Well actually it gives the primLoadLibrary failure, > but good luck in guessing why... > Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't have I? It wouldn't compile if I didn't and its sets it to 8. Is it defined in any other place? > > > Other question, can classic FFI and Alien live nicely together (I mean have > x plugin use classic FFI while y uses Alien)? > > > yes. > > One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't have > both in, right? > > > One is a subclass of the other. I use the IA32ABIPluginAttic one. > Ok, what is the difference between them? a performance issue? everything works the same I choose one or the other? > > > Syntax highligthing is broken for Alien primitive methods like these: > > > > Lastly, as I said when I loaded Alien Core the first time, I got this error > while loading it: > > Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". > > What should I do about that? ignore it? > > > Well it seems to be related to > > ((Smalltalk includesKey: #ObjectMemory) > and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: > []) ~~ (index - 1)]) ifTrue: > [self error: 'index probably wrong']. > > Usually people don't have ObjectMemory loaded in their image, and I"m not > sure what it is check for. > Why don't you try it in a regular Pharo image versus your VMMaker image. > > In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When I load VMMaker it's downloaded from monticello, but obviously, #ClassAlien isn't defined inside (Smalltalk at: #ObjectMemory) classPool Interestingly, after load alien, #ClassAlien gets added as a key, but all values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like this: (Smalltalk at: #ObjectMemory) classPool inspect: - size : 119 [#AllButHashBits] : nil [#AllButMarkBit] : nil [#AllButMarkBitAndTypeMask] : nil [#AllButRootBit] : nil [#AllButTypeMask] : nil ... [#ClassAlien] : nil ... Any ideas? -- Javier Pimás Ciudad de Buenos Aires ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
Stéphane Ducasse wrote: > Yes and you are right. I was thinking too much about bad energy. > :) > > Stef Cool. :) regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Trying to build alien plugin in linux
On Tue, Feb 23, 2010 at 3:55 AM, Fernando olivero wrote: > > On Feb 23, 2010, at 4:19 AM, John M McIntosh wrote: > > > > > On 2010-02-22, at 6:48 PM, Javier Pimás wrote: > > > >> > > > >> Lastly, as I said when I loaded Alien Core the first time, I got this > error while loading it: > >> > >> Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". > >> > >> What should I do about that? ignore it? > > > > Well it seems to be related to > > > > ((Smalltalk includesKey: #ObjectMemory) > >and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien > ifAbsent: []) ~~ (index - 1)]) ifTrue: > > [self error: 'index probably wrong']. > > > > Usually people don't have ObjectMemory loaded in their image, and I"m not > sure what it is check for. > > Why don't you try it in a regular Pharo image versus your VMMaker image. > > Great work Jorge! Nice to know you won the battle against VMMaker! > > Haha, it's Javier but you were very close, keep trying :P > The ensure in special objects array error, has to do with some missing > classes as John pointed out. > > The smalltalk special objects array has hardcoded indexes for some relevant > classes ( Globals) in the system. > In the alien configuration i've just ensured that the size should be 53, > before loading Alien, because the Alien code installs itself in that array > at positions 54 and 55. > > Before loading my image has 50 items, last one being #run:with:in:. After loading alien I've got 55. The new ones are: [51] : nil [52] : nil [53] : Alien [54] : #invokeCallback:stack:registers:jmpbuf: [55] : UnsafeAlien Other strange stuff is that while inspecting (Smalltalk at: #Interpreter) classPool I found that [#PrimErrBadArgument] : nil [#PrimErrBadIndex] : nil [#PrimErrBadNumArgs] : nil [#PrimErrBadReceiver] : nil [#PrimErrGenericFailure] : nil [#PrimErrInappropriate] : nil [#PrimErrNoCMemory] : nil [#PrimErrNoMemory] : nil [#PrimErrNoModification] : nil [#PrimErrNotFound] : nil [#PrimErrTableIndex] : nil [#PrimErrUnsupported] : nil [#PrimNoErr] : nil Which means that initializePrimitiveErrorCodes hasn't been called, which explains why special object #52 is nil. Analysing it a bit more I discover that initializePrimitiveErrorCodes has no senders, is that right? Regards, Javier. > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier Pimás Ciudad de Buenos Aires ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
- "Lukas Renggli" 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11230
11230 - - Issue 2048: delete class ChangeListForProjects - Issue 2041: remove #isSketchMorph - Issue 1519: remove #asKnownNameMenu - Issue 2031: Should add empty TheWorldMenu class - Issue 2046: Remove Network-in-Browser support (not used) - Issue 2028: remove Morph methods (#adaptedToWorld: and some more) - Issue 2033: remove Modell>>addItem: - Issue 2051: Clean users of Utilities - Issue 2052: PluggableDialogWindow should Inherit from ModelDependentDialogWindow - Issue 1950: Polymorph usage are broken - Clean some undeclared variables Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] nice tool I discovered recently
Hi guys if you want to follow the changes that are done during an update you can open the Tools > Code recovering > recent submission There is a slight bug with the scrolling list but this tool is useful. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Shout
Hi guys I would like to know which version of shout we are using and relying on. Apparently one version was integrated on squeak and I would like to make sure that the one we use continue to get improved. One of these days we will have to think about the status of important packages that are external to pharo: shout, XMLSupport Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)
Doru did some experiement with Mondrian I believe. Cheers, Alexandre On 23 Feb 2010, at 13:25, Gary Chambers wrote: > Some kind of graph-based GUI would certainly help in this scenario to > visualise the dependencies/changes... just a thought. > > Regards, Gary > > - Original Message - > From: "Igor Stasenko" > To: > Sent: Tuesday, February 23, 2010 4:02 PM > Subject: [Pharo-project] Source code management - my vision. (Was: > Re: Why > apackage management system) > > >> Since Goran mentioned DeltaStreams, i'd like to share one of my >> ideas, >> which came into my mind, when i complete coding the method trailers. >> >> I made a method trailers open for future extensions. >> A first step would be to introduce an abstract 'source management' >> layer, which will be responsible for delivering >> a method's and classes sources from some abstract data source. The >> next step is actually implement such data sources. >> >> So, the idea is to abandon hardwiring with .sources and .changes >> files. >> What new opportunities it gives to us? >> Suppose that instead of storing sources into file, you putting them >> directly to database , such as CouchDB (yes! :). >> >> Now if you imagine that anyone could access to this database on some >> public location, this means that we automagically made a source code >> exchange hub, and could do a very cool things with it. >> >> Suppose that ALL source code is put into a single database. Now >> different users creating own accounts and makind own 'forks' from >> original. What we getting is a number of update streams (methods, >> doits etc etc), which lying in those databases, >> and if one user wants to load/merge code from one of the sources he >> simply points to it and it get loaded into his image. >> We could organize things very closely to what github currently is: >> everyone could create any number of new projects, or forks of >> existing >> ones. Freely exchange the code, do a cherry picking etc etc. >> And what is most important, that with such organization you can track >> any methods, classes in the image and their evolutionary history back >> to its origin. As well as, you can query database, how an when a >> concrete method/class get deleted (everything is recorded, not just >> current state). >> >> Also, it would allow us to manipulate the code at the lowest level of >> granularity (individual methods/classes/doits, same as DS does), not >> at a package level. >> There are a lot of synergy with DeltaStreams - it could serve as an >> 'offline' format, in same way as git storing the files locally, but >> can reconnect with remote storage (which can be a public database). >> One of the things, which could be made is to allow stashing/popping >> code from stash. Suppose two projects started from a single starting >> point (Squeak 3.9). Now suppose that by clicking a single button you >> could get either trunk image, or Pharo 1.0 image. >> But that's not all! With DeltaStreams, you could then click once >> more, >> and revert things back from , say Pharo 1.0 to trunk or vice versa :) >> Of course it would be stupid to do things at such large scale, but if >> we put some common 'root' stuff into database, then we could very >> easily track all changes & compare them. This would make cherry >> picking and code exchange much more easier. >> >> This could get us on the next level of code management and system >> organization and organization of community efforts. >> >> >> >> 2010/2/23 Göran Krampe : >>> Hi! >>> >>> Germán Arduino wrote: Hi Göran: Sorry by my intromision here, but want to say somethings :) 2010/2/23 Göran Krampe mailto:go...@krampe.se>> >>> [SNIP] What I have seen so far in Metacello is indeed nothing new - the senarios and discussions about dependencies etc go lng way back. I'm on Squeak from old 3.2 times. And yes, a lot of discussions about packages, etc, but only discussions on most of cases. I think Metacello solves the dependencies questions very well and the other tools not (with exception of Universes probably, but abandoned now). Also Metacello provides all the features explained on the excellent mail of Torsten, assuring that the configurations will work with the time not breaking stuffs. The solution of using Metacello+Monticello is, imho, very simple, easy and productive and is here, available to us. :) >>> >>> I never claimed otherwise! I am just saying that there is nothing >>> new - >>> and frankly, though I admit not having read carefully, I didn't >>> find the >>> example so... impressive. Perhaps I need to read it again. >>> >>> Again though - I am not saying anything negative about Metacello. >>> >>> [SNIP] Anyway, "common exchange mechanism" - I am working on Deltastreams which I even presented at Brest, though unfortun
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
What if use redudancy features of Internet itself? As you know the Internet was designed to withstand a nuclear attack, with a lot of redudant features, which we can explore to harden the Smalltalk infracture as well. In the similar ways as guyss like Google do. You know, they have always a single entry, http://www.google.com, but actually they direct your search to 1000s and milions of their servers behind. A mini version of Google can be use for Squeak or PharoSource as well. As I can see the Monticello repositories are basically the stateless WebDAV enabled Apache web servers. So having a mirror is a first thing to do. To still have a single entry point like http://www.squeaksource.com), we can exploit the redundancy feature of DNS: round robin entries. That is, you enter two entries in DNS zone, with the same name but different IP addresses, say: squeaksource.com www IN A87.54.32.108 www IN A212.18.45.87 This way in the case of failure of one server, the another one will responds. If both are working, DNS will return one of them in roun robin fashion. This will work for WebDAV part of the story, but we still need to tackle of the statefull web application of SqueakSource... hmm, a bit more thinking is needed therefore... Best regards Janko On 23. 02. 2010 19:48, Dale Henrichs wrote: > I like the notion of a secondary repository for packages. It is absolutely > necessary to protect us from a catastrophic failure with any one of the > SqueakSource repositories. > > Perhaps Gofer can be provided with a secondary repository location in the > case when the primary repository fails. > > With this kind of approach, the metacello configurations can continue to > reference the primary development repository, in this way we might just be > able to have our cake and eat it too:) The Pharo secondary repository would > protect users from repository volatility and package volatility ... Once a > version is published in Pharo you can count of being able to load that > version over time. > > This secondary repository could be maintained by periodically scanning the > Pharo configurations and copying the referenced packages from the primary > repository to a known secondary repository (this repository could just be > done with Apache file access since a fancy UI for the secondary repository > isn't essential). > > Having code and processes in place means that individuals can reuse the code > and process to maintain their own secondary repository for their own > production environment. > > I have code that does most of what is needed, as I use this process at > GemStone for archiving the configurations and mcz packages in our company > source code control system. > > Dale > - "Göran Krampe" wrote: > > | Miguel Enrique Cobá Martinez wrote: > | > El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribió: > | > I was thinking about this problem yesterday in the light of the > | packages > | > moved by Lukas. > | > We have a problem with the packages referenced by a > | ConfigurationOfXXX. > | > The can disappear anytime. The repository can disappear anytime. > | > > | > So I thought that we need a dedicated hosting server where: > | > > | > - We have all the ConfigurationOfXXX (in the MetacelloRepository > | repo, > | > just as now) > | > - We copy there *all* the packages that conform a giver > | > ConfigurationOfXXX>>versionXX: from the original repo to this > | dedicated > | > repo. > | > - There is *no way* to delete anything. This is a *write only, read > | > always, delete never* repository. > | > | Sidenote: SqueakMap actually caches all URLs used for versions and if > | the original URL fails an SHA check it falls back on the cached file > | on > | the SqueakMap server. > | > | In that way it was meant to handle original URLs going stale or > | disappearing. > | > | regards, Göran > | > | > | ___ > | Pharo-project mailing list > | Pharo-project@lists.gforge.inria.fr > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] hex
in pharo #[122 43 213 7] hex = '7A2BD507' in squeak #[122 43 213 7] hex = '7a2bd507' do you think that it makes a difference? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] hex
On Tue, Feb 23, 2010 at 1:25 PM, stephane ducasse wrote: > in pharo > > #[122 43 213 7] hex = '7A2BD507' > > in squeak > > #[122 43 213 7] hex = '7a2bd507' > > do you think that it makes a difference? > Much of the "rest of the world" (e.g. gdb, md5sum) uses lower case. Personally I find lower-case much easier to read because I find the lower-case letters visually more different from the digits than the upper case letters. For these two reasons I prefer lower-case. I haven't always been this way. I used to prefer upper case because I think the upper case letters look neater, having the same height as the digits. But now I prefer legibility over neatness. 2¢ Eliot > > Stef > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] hex
Ok thanks. " The UUID spec (RFC 4122) allows both upper and lower case hex digits, so I don't see a reason not to. " Bert On Feb 23, 2010, at 10:43 PM, Eliot Miranda wrote: > > > On Tue, Feb 23, 2010 at 1:25 PM, stephane ducasse > wrote: > in pharo > > #[122 43 213 7] hex = '7A2BD507' > > in squeak > > #[122 43 213 7] hex = '7a2bd507' > > do you think that it makes a difference? > > > Much of the "rest of the world" (e.g. gdb, md5sum) uses lower case. > Personally I find lower-case much easier to read because I find the > lower-case letters visually more different from the digits than the upper > case letters. For these two reasons I prefer lower-case. I haven't always > been this way. I used to prefer upper case because I think the upper case > letters look neater, having the same height as the digits. But now I prefer > legibility over neatness. > > 2¢ > > Eliot > > Stef > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] withAllSubclasses -> Set or OrderedCollection
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] withAllSubclasses -> Set or OrderedCollection
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 : > 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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] hex
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... Nicolas 2010/2/23 Stéphane Ducasse : > Ok thanks. > > " > The UUID spec (RFC 4122) allows both upper and lower case hex digits, so I > don't see a reason not to. > > " > Bert > > > On Feb 23, 2010, at 10:43 PM, Eliot Miranda wrote: > >> >> >> On Tue, Feb 23, 2010 at 1:25 PM, stephane ducasse >> wrote: >> in pharo >> >> #[122 43 213 7] hex = '7A2BD507' >> >> in squeak >> >> #[122 43 213 7] hex = '7a2bd507' >> >> do you think that it makes a difference? >> >> >> Much of the "rest of the world" (e.g. gdb, md5sum) uses lower case. >> Personally I find lower-case much easier to read because I find the >> lower-case letters visually more different from the digits than the upper >> case letters. For these two reasons I prefer lower-case. I haven't always >> been this way. I used to prefer upper case because I think the upper case >> letters look neater, having the same height as the digits. But now I prefer >> legibility over neatness. >> >> 2¢ >> >> Eliot >> >> Stef >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why a package management system
- "Torsten Bergmann" wrote: | I'm sure I'm not able to convince one or the other to use package | systems like Metacello but at least I hope to make them think about | the need of a more modular system. Torsten, 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. Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] Magma 1.0 release 44
Hi Ramiro, something happened between Pharo1.0-10502-rc1dev09.12.2. and 10508 related to Networking. Please see: http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/021912.html I am not sure what happened. Perhaps someone on the Pharo team would elaborate? - Chris On Tue, Feb 23, 2010 at 6:54 PM, Ramiro Diaz Trepat wrote: > Hi Chris, > Once again, thanks for your work. > One question though, is this version running fine on the latest Pharo 1.0 ? > I haven't been able to start a server successfuly, I get a primitive has > failed. > It doesn't run on Pharo 1.1 or Squeak trunk but you didn't mention those :) > I loaded it in a fresh Pharo 1.0 image using: > ScriptLoader new installer. > Installer ss project: 'Magma'; > install: '1.0r44 (server)'. > > Cheers > > r > > On Wed, Feb 17, 2010 at 8:46 PM, Chris Muller wrote: >> >> I am pleased to announce the immediate availability of Magma 1.0 >> release "44" for both Squeak, 3.9, 3.10 and Pharo. Although I am >> looking into alternatives for future releases, for now I am still >> distributing Magma in my traditional ways: >> >> - On SqueakMap - three one-click installable packages. >> >> - In the "1.0r44" Monticello Configuration in the "Magma" project of >> squeaksource, there are three one-click installable configurations >> (client, server, tester). >> >> - The "r44Final" Monticello Configuration in the "MagmaTester" >> project of squeaksource is the one-click installable MagmaTester >> package. >> >> As has always been the case, ONLY ONE of the three packages needs to >> be installed, the full and proper configuration is loaded with >> one-click. >> >> Compared to r43, this is mostly a maintenance release without any >> major new functionality, but with improved robustness in the HA and >> luxury querying as well as several other fixes. Here are the specific >> improvements over 43: >> >> - Made several HA fixes and improvements, many identified by Bart >> Gaquie by testing with more than a two-server Magma Node. Many thanks >> Bart. >> - Updated MaQueryExecutor>>#fractionComplete to answer an unreduced >> Fraction instead of a reduced one. This convey's more information; >> since the denominator represents the total number of elements in the >> final result. Thanks again to Bart Gauqie. >> - Upgraded MagmaCollectionReader>>#release to allow give a >> well-behaved application much freer access to the "luxury" query >> features of MagmaCollections. It is essential for applications >> employing luxury query features of Magma for ad-hoc querying, to >> #release the Reader returned from the query so that resources on the >> server can be freed. >> - Now properly truncating the applied.images file, so it doesn't >> grow >> and grow.. >> - Now, when a repository is opened locally, if it's location has >> never been set (new repository) or was a different *local* location, >> then update it to the new aMagmaLocalLocation. If it was formerly a >> network-hosted server, do not update since we could be here simply >> just for re-opening that repository. So, to go from a remote >> repository to a local one, you have to manually update the node's >> primaryLocation. >> - Server no longer allows any clients to log in with the system >> name, >> since it is sometimes checked for special-purpose server housekeeping. >> - Updated MagmaSession's standard printing method, again! >> - Added MagmaCollectionReader>>#sortBy:makeDistinct:descending: and >> #sortBy:makeDistinct:descending:. >> - Made MaRepositoryDisconnectRequest asynchronous, it now returns >> considerably faster! >> - Fix for a recent MagmaCollection optimization. >> - Removed hard-reference to OSProcess. >> - Patch for #removeListener to avoid DependentsArray problem. >> - Fixed a ReadStrategy regression. >> ___ >> Magma mailing list >> ma...@lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/magma > > > ___ > Magma mailing list > ma...@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)
On 23 February 2010 18:25, Gary Chambers wrote: > Some kind of graph-based GUI would certainly help in this scenario to > visualise the dependencies/changes... just a thought. > Sure. But this is a little far perspective. ;) At first, we should replace the source code management in image to be able to connect with any facility for storing the sources (be it in file or database or network). The main point that tools & system utils should not know where these sources stored or coming from. Then, we could move on the next stage - design a database/source code managers to fit specific purposes. The one which i described above is only one of the possible ways, actually. > Regards, Gary > > - Original Message - > From: "Igor Stasenko" > To: > Sent: Tuesday, February 23, 2010 4:02 PM > Subject: [Pharo-project] Source code management - my vision. (Was: Re: Why > apackage management system) > > >> Since Goran mentioned DeltaStreams, i'd like to share one of my ideas, >> which came into my mind, when i complete coding the method trailers. >> >> I made a method trailers open for future extensions. >> A first step would be to introduce an abstract 'source management' >> layer, which will be responsible for delivering >> a method's and classes sources from some abstract data source. The >> next step is actually implement such data sources. >> >> So, the idea is to abandon hardwiring with .sources and .changes files. >> What new opportunities it gives to us? >> Suppose that instead of storing sources into file, you putting them >> directly to database , such as CouchDB (yes! :). >> >> Now if you imagine that anyone could access to this database on some >> public location, this means that we automagically made a source code >> exchange hub, and could do a very cool things with it. >> >> Suppose that ALL source code is put into a single database. Now >> different users creating own accounts and makind own 'forks' from >> original. What we getting is a number of update streams (methods, >> doits etc etc), which lying in those databases, >> and if one user wants to load/merge code from one of the sources he >> simply points to it and it get loaded into his image. >> We could organize things very closely to what github currently is: >> everyone could create any number of new projects, or forks of existing >> ones. Freely exchange the code, do a cherry picking etc etc. >> And what is most important, that with such organization you can track >> any methods, classes in the image and their evolutionary history back >> to its origin. As well as, you can query database, how an when a >> concrete method/class get deleted (everything is recorded, not just >> current state). >> >> Also, it would allow us to manipulate the code at the lowest level of >> granularity (individual methods/classes/doits, same as DS does), not >> at a package level. >> There are a lot of synergy with DeltaStreams - it could serve as an >> 'offline' format, in same way as git storing the files locally, but >> can reconnect with remote storage (which can be a public database). >> One of the things, which could be made is to allow stashing/popping >> code from stash. Suppose two projects started from a single starting >> point (Squeak 3.9). Now suppose that by clicking a single button you >> could get either trunk image, or Pharo 1.0 image. >> But that's not all! With DeltaStreams, you could then click once more, >> and revert things back from , say Pharo 1.0 to trunk or vice versa :) >> Of course it would be stupid to do things at such large scale, but if >> we put some common 'root' stuff into database, then we could very >> easily track all changes & compare them. This would make cherry >> picking and code exchange much more easier. >> >> This could get us on the next level of code management and system >> organization and organization of community efforts. >> >> >> >> 2010/2/23 Göran Krampe : >>> Hi! >>> >>> Germán Arduino wrote: Hi Göran: Sorry by my intromision here, but want to say somethings :) 2010/2/23 Göran Krampe mailto:go...@krampe.se>> >>> [SNIP] What I have seen so far in Metacello is indeed nothing new - the senarios and discussions about dependencies etc go lng way back. I'm on Squeak from old 3.2 times. And yes, a lot of discussions about packages, etc, but only discussions on most of cases. I think Metacello solves the dependencies questions very well and the other tools not (with exception of Universes probably, but abandoned now). Also Metacello provides all the features explained on the excellent mail of Torsten, assuring that the configurations will work with the time not breaking stuffs. The solution of using Metacello+Monticello is, imho, very simple, easy and productive and is here, available to us. :) >>> >>> I never claimed otherwise! I am just saying that there is nothing new - >>> and frankly, t
Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
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 spec package: 'SomePackage' with: [ spec repository: 'SOME_URL' ]. ... ConfigurationOfXXX>>versionX: spec 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" 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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Every thing has its own flow." ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] withAllSubclasses -> Set or OrderedCollection
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 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 : >> 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@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] hex
> 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] Magma 1.0 release 44
Thanks we will have a look. Note that Installer is not available from ScriptLoader (ScriptLoader is not a public class and nobody should use it) Either use gofer which is the default loader or install installer manually. Stef On Feb 24, 2010, at 5:38 AM, Chris Muller wrote: > Hi Ramiro, something happened between Pharo1.0-10502-rc1dev09.12.2. > and 10508 related to Networking. Please see: > > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/021912.html > > I am not sure what happened. Perhaps someone on the Pharo team would > elaborate? > > - Chris > > > On Tue, Feb 23, 2010 at 6:54 PM, Ramiro Diaz Trepat > wrote: >> Hi Chris, >> Once again, thanks for your work. >> One question though, is this version running fine on the latest Pharo 1.0 ? >> I haven't been able to start a server successfuly, I get a primitive has >> failed. >> It doesn't run on Pharo 1.1 or Squeak trunk but you didn't mention those :) >> I loaded it in a fresh Pharo 1.0 image using: >> ScriptLoader new installer. >> Installer ss project: 'Magma'; >> install: '1.0r44 (server)'. >> >> Cheers >> >> r >> >> On Wed, Feb 17, 2010 at 8:46 PM, Chris Muller wrote: >>> >>> I am pleased to announce the immediate availability of Magma 1.0 >>> release "44" for both Squeak, 3.9, 3.10 and Pharo. Although I am >>> looking into alternatives for future releases, for now I am still >>> distributing Magma in my traditional ways: >>> >>> - On SqueakMap - three one-click installable packages. >>> >>> - In the "1.0r44" Monticello Configuration in the "Magma" project of >>> squeaksource, there are three one-click installable configurations >>> (client, server, tester). >>> >>> - The "r44Final" Monticello Configuration in the "MagmaTester" >>> project of squeaksource is the one-click installable MagmaTester >>> package. >>> >>> As has always been the case, ONLY ONE of the three packages needs to >>> be installed, the full and proper configuration is loaded with >>> one-click. >>> >>> Compared to r43, this is mostly a maintenance release without any >>> major new functionality, but with improved robustness in the HA and >>> luxury querying as well as several other fixes. Here are the specific >>> improvements over 43: >>> >>>- Made several HA fixes and improvements, many identified by Bart >>> Gaquie by testing with more than a two-server Magma Node. Many thanks >>> Bart. >>>- Updated MaQueryExecutor>>#fractionComplete to answer an unreduced >>> Fraction instead of a reduced one. This convey's more information; >>> since the denominator represents the total number of elements in the >>> final result. Thanks again to Bart Gauqie. >>>- Upgraded MagmaCollectionReader>>#release to allow give a >>> well-behaved application much freer access to the "luxury" query >>> features of MagmaCollections. It is essential for applications >>> employing luxury query features of Magma for ad-hoc querying, to >>> #release the Reader returned from the query so that resources on the >>> server can be freed. >>>- Now properly truncating the applied.images file, so it doesn't >>> grow >>> and grow.. >>>- Now, when a repository is opened locally, if it's location has >>> never been set (new repository) or was a different *local* location, >>> then update it to the new aMagmaLocalLocation. If it was formerly a >>> network-hosted server, do not update since we could be here simply >>> just for re-opening that repository. So, to go from a remote >>> repository to a local one, you have to manually update the node's >>> primaryLocation. >>>- Server no longer allows any clients to log in with the system >>> name, >>> since it is sometimes checked for special-purpose server housekeeping. >>>- Updated MagmaSession's standard printing method, again! >>>- Added MagmaCollectionReader>>#sortBy:makeDistinct:descending: and >>> #sortBy:makeDistinct:descending:. >>>- Made MaRepositoryDisconnectRequest asynchronous, it now returns >>> considerably faster! >>>- Fix for a recent MagmaCollection optimization. >>>- Removed hard-reference to OSProcess. >>>- Patch for #removeListener to avoid DependentsArray problem. >>>- Fixed a ReadStrategy regression. >>> ___ >>> Magma mailing list >>> ma...@lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/mailman/listinfo/magma >> >> >> ___ >> Magma mailing list >> ma...@lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/magma >> >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/li
Re: [Pharo-project] 16rff broke 16r8e7
http://code.google.com/p/pharo/issues/detail?id=2068 On Feb 14, 2010, at 9:22 PM, Nicolas Cellier wrote: > As you may know, with 16rff change, we cannot anymore use a radix > notation combined with an exponent notation. > At least for base > 14, the exponent letter is taken as an ordinary digit. > The options are: > > 1) revert the change > > 2) abandon combined radix+exponent notation > all the code for printing Float with different radix, and also for > scanning can be removed > Or I can provide a subclass of SqNumberParser for backward compatibility. > > 3) find a new syntax for radix+exponent > > For example, 16r7f_e6 16r7f^6 16r7f#6 > None of these is ambiguous with existing code. > > Or maybe use an uppercase R for uppercase only digits... > > 4) use q exponent to at least enable base 16 > This is hackish and not universal, but I guess hardly anybody ever > used a base > 16. > > - > > What would squeak/pharo folks choose ? > > - > Personnally, I'm OK with 1) and 2). > But 2) deserves a bit more discussion > After all this is a change of Squeak syntax. > I find Dan's notation educative and fun, especially for writing tests. > But it is a non portable Squeakish thing, rarely used, and it does not > really has much value for industrial usage, > On the other hand, is it really necessary to parse 16rff ? > > I dislike 3) because I find my own propositions bad. > Also, if we remove Squeak-specific syntax for compatibility reasons, > why the hell adding a new uncompatible syntax? > Previous usage of e notation was far better because just extending an > existing syntax, not creating a new one. > Maybe you'll have other ideas... > > Nicolas > > - > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] hex
Nicolas and others I was thinking also about the implication of the 16rFF changes on 16r8e7 http://code.google.com/p/pharo/issues/detail?id=2068 I would really like to take the time to think and discuss it as a community to see what we want to do. What is the current situation in squeak? Stef On Feb 23, 2010, at 11:16 PM, Nicolas Cellier wrote: > 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... Yes ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
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? > Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
On 24 February 2010 09:25, Stéphane Ducasse 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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
