- Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20012

by Marcus Denker

20012 ----- Issue 5686: Add some primitive testing methods to CompiledMethod http://code.google.com/p/pharo/issues/detail?id=5686 Issue 5692: extract startup and shutdown from snapshot:andQuit: http://code.google.com/p/pharo/issues/detail?id=5692 Issue 5688: remove #isClosureCompiled http://code.google.com/p/pharo/issues/detail?id=5688 Issue 5682: metacelloPlatformAttributes should be updated. http://code.google.com/p/pharo/issues/detail?id=5682 Issue 5674: remove more deprecated method http://code.google.com/p/pharo/issues/detail?id=5674 Issue 5639: [EventModel] Remove more direct usage of Sensor http://code.google.com/p/pharo/issues/detail?id=5639 in pre-amble: ScriptLoader new addHomeRepositoryToAllPackages. ScriptLoader showIntegrationMenu. -- Marcus Denker -- http://marcusdenker.de

April 26, 2012

[Pharo-project] System browser in Pharo 1.4

by Olivier Auverlot

Hi, This is probably a stupid question. Why in Pharo 1.4, the system browser does not display classes hierarchically in the column instances / class. Each class is displayed at the same level. It's not easy to read. How to get the same behavior as in previous versions of Pharo ? Best regards Olivier

April 26, 2012

Re: [Pharo-project] ENH: Setting to enable two-way halo cycling

by Sean P. DeNigris

StÃ©phane Ducasse wrote > > Thanks Sean. I will have a look. > Okay great. It'd be nice to have this settled and not see it come up on the list anymore :) And the code is minimal... Sean -- View this message in context: http://forum.world.st/ENH-Setting-to-enable-two-way-halo-cycling-tp4585241p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 26, 2012

Re: [Pharo-project] [ANN] ImageWriter, the SystemTracer's son

by Guillermo Polito

On Thu, Apr 26, 2012 at 2:12 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > > On Thu, Apr 26, 2012 at 1:52 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > >> Great news! >> >> I tried it on fresh 1.4 and I got: >> SmalltalkImage(Object)>>doesNotUnderstand: #shutDownImage: >> HzImageWriter>>writeImage: >> > > Oups, bad packaging :). Will fix that asap. > Now it is fixed :). Tested it in a clean 2.0 image and worked :). > > >> >> Do you plan to create a loader too? To be able to load objects from >> different image file. >> > > Hmm it's kind of the inverse operation :P. Don't think it's an important > path for the project, but I can do it after for the lulz :). > > >> >> -- Pavel >> >> >> On Thu, Apr 26, 2012 at 1:00 PM, Guillermo Polito >> <guillermopolito(a)gmail.com> wrote: >> > First public push of the first step of the hazelnut GSoC project :) >> > >> > In a nutshell >> > >> > For those who didn't know SystemTracer (the father): >> > It is a tool that traces a graph of objects and writes an image from it. >> > >> > ImageWriter is a refactored, renamed and repackaged version of >> SystemTracer2 >> > with the following changes: >> > - The image format can be provided as a parameter. >> > - You have to provide an SmalltalkImage object as root to write the >> image >> > (so in the future we can write bootstrap with this). >> > - The object format was reified in objects. So the code is easier to >> > understand + change, and people can learn how are our objects in memory >> > easily :D. >> > >> > Right now, only 32 bit image format is supported. >> > >> > Structure >> > >> > - ImageWriter-Core has the image formats and the image writer in itself >> > - ImageWriter-ObjectFormats contains objects that represent the memory >> > layout of the objects and it's headers. >> > - ImageWriter-Tests has some tests. >> > >> > Tests done >> > >> > - Only tested in Pharo-1.4 >> > - There are specific tests written for the size and headers of the >> objects >> > - Also, I've written a Pharo-1.4 image and then run the tests in the >> copied >> > image. Only one failure compared to the original :) >> > >> > Known Bugs :) >> > >> > - WeakRegistryTest>>#testFinalizationWithOnFork is failing, and when I >> run >> > it manually it works :/. In the image I use to write, it does not >> happen, >> > only in the clone. >> > - When opening the new image, the window is too small. It is not >> > respecting the original image size. Don't know yet what is the problem. >> > >> > How To Download >> > >> > Gofer it >> > squeaksource3: 'ImageWriter'; >> > package: 'ImageWriter-Core'; >> > package: 'ImageWriter-ObjectFormats'; >> > package: 'ImageWriter-Tests'; >> > load >> > >> > How to Use it >> > >> > HzImageWriter new >> > format: HzCogImageFormat new; "or HzInterpreterImageFormat new" >> > imageFileName: 'someFile.image'; >> > onInitializeDo: [ "Some initialization?" ]; "this is optional, >> > probably the same as an startup script, probably nonsense" >> > writeImage: Smalltalk "Yes, we provide the our lovely global >> Smalltak, >> > but any SmalltalkImage instance could be" >> > >> > Next steps on this direction >> > >> > - support to write an isolated image different from the host one (I'll >> know >> > what I need later, hehe) >> > - class comments! >> > - metacello configuration >> > - better api :) >> > >> > Links >> > >> > http://ss3.gemstone.com/ss/ImageWriter.html >> > >> > >> > Cheers, >> > Guille >> >> >

April 26, 2012

[Pharo-project] Just a small question (Pharo 1.4 and Pier 3)

by Friedrich Dominicus

Can anyone tell me if this combination is working. If I try to load Pier3 I get nice crash.... Thanks in advance Friedrich

April 26, 2012

Re: [Pharo-project] Confused about #isDirectory

by Camillo Bruni

we changed that not so long ago :) but it will do the same.... the problem will be that the VM primitive might not follow symlinks (that would explain the first line) no clue though why it should return false for '/private/var'... On 2012-04-26, at 13:58, Sven Van Caekenberghe wrote: > Hi Alexis, > > On 26 Apr 2012, at 13:49, Alexis Parseghian wrote: > >> On Thu, Apr 26, 2012 at 12:47 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >>> '/tmp' asReference isDirectory. false >>> '/private/tmp' asReference isDirectory. false >>> >>> '/Users/sven' asReference isDirectory. true >>> '/Users/sven/Desktop' asReference isDirectory. true >>> >>> on Pharo 1.4 Mac OS X Cog VM. >> >> For what it's worth, working as expected on Linux (using either >> deprecated asReference or asFileReference) : >> >> /tmp true >> /home/alexisp true >> /nosuchpath false >> >> Pharo 1.4-14438 >> 'CoInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: >> 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Jan 26 2012, >> StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.139 uuid: >> 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Jan 26 2012, >> https://git.gitorious.org/cogvm/blessed.git Commit: >> e49a136ea9fe909dd5ba3cdeffac8f61cce27c9f Date: Thu Jan 26 17:38:06 >> 2012 +0100 By: Camillo Bruni <camillobruni(a)gmail.com>' > > I was afraid of that ;-) > > I don't have #asFileReference in my Pharo 1.4 image and #asReference is not deprecated, is that new ? > > Sven

April 26, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by H. Hirzel

On 4/24/12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > That's a good point. I regularly see that Stef and others harvest > enhancements and fixes from Squeak and CUIS. Surely, the other way > around is also true. > > We simply have to live with the fact that many forks exist, and each > of them is maintained by a small set of people who put a lot of energy > into their own system. Yes. > And sometimes they will collaborate, and sometimes not. And this is possible because all is under the MIT license. > The community behind Pharo, shouldnt be required to always be aware of > external enhancements. And vice-versa for the remaining forks. Yes. --Hannes > Fernando > > On Tue, Apr 24, 2012 at 12:38 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >>>> Now I do not see the points related to spoon and cuis. I do not >>>> understand what is the point. >>>> If people wants to collaborate with us this is ok now we do not count on >>>> that for our future. >>>> >>>> You do not have to reply. Just think about what you want to build and >>>> your future. Everybody >>>> make choices and is free. >>> >>> I see the point behind Cuis/Spoon discussion in a wish to avoid >>> duplication efforts in Smalltalk community. A wish to hear from you a >>> word, something like: "yes we will look in Cuis to see if we can reuse >>> some ideas or even code". To express just a will to look at achievements >>> of others would help here. I think this is what many of us wants to hear. >> >> Did you notice that we ***already*** harvested some of the CUIS items? >> Now it does not make sense to stay compatible for the sake of it. >> Look CUIS changes the class definition meta data and this is ok. Now >> nobody went to say >> to Juan that he should not â¦ blablbalbalba >> >> Stef >> >>> Best regards >>> Janko >>> >>> >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> >> > >

April 26, 2012

Re: [Pharo-project] [ANN] ImageWriter, the SystemTracer's son

by Juan Vuletich (mail lists)

Quoting Guillermo Polito <guillermopolito(a)gmail.com>: > On Thu, Apr 26, 2012 at 1:52 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > Great news! > > > > I tried it on fresh 1.4 and I got: > > SmalltalkImage(Object)>>doesNotUnderstand: #shutDownImage: > > HzImageWriter>>writeImage: > > > Oups, bad packaging :). Will fix that asap. > > > > Do you plan to create a loader too? To be able to load objects from > > different image file. > > > Hmm it's kind of the inverse operation :P. Don't think it's an important path for the project, but I can do it after for the lulz :). This could allow extracting objects from broken images (that are unable to start)? That would be great! BTW, this is a great project. Thank you! Cheers, Juan Vuletich > > -- Pavel > > > > On Thu, Apr 26, 2012 at 1:00 PM, Guillermo Polito > > <guillermopolito(a)gmail.com> wrote: > > > First public push of the first step of the hazelnut GSoC project :) > > > > > > In a nutshell > > > > > > For those who didn't know SystemTracer (the father): > > > It is a tool that traces a graph of objects and writes an image from it. > > > > > > ImageWriter is a refactored, renamed and repackaged version of SystemTracer2 > > > with the following changes: > > > - The image format can be provided as a parameter. > > > - You have to provide an SmalltalkImage object as root to write the image > > > (so in the future we can write bootstrap with this). > > > - The object format was reified in objects. So the code is easier to > > > understand + change, and people can learn how are our objects in memory > > > easily :D. > > > > > > Right now, only 32 bit image format is supported. > > > > > > Structure > > > > > > - ImageWriter-Core has the image formats and the image writer in itself > > > - ImageWriter-ObjectFormats contains objects that represent the memory > > > layout of the objects and it's headers. > > > - ImageWriter-Tests has some tests. > > > > > > Tests done > > > > > > - Only tested in Pharo-1.4 > > > - There are specific tests written for the size and headers of the objects > > > - Also, I've written a Pharo-1.4 image and then run the tests in the copied > > > image. Only one failure compared to the original :) > > > > > > Known Bugs :) > > > > > > - WeakRegistryTest>>#testFinalizationWithOnFork is failing, and when I run > > > it manually it works :/. In the image I use to write, it does not happen, > > > only in the clone. > > > - When opening the new image, the window is too small. It is not > > > respecting the original image size. Don't know yet what is the problem. > > > > > > How To Download > > > > > > Gofer it > > > squeaksource3: 'ImageWriter'; > > > package: 'ImageWriter-Core'; > > > package: 'ImageWriter-ObjectFormats'; > > > package: 'ImageWriter-Tests'; > > > load > > > > > > How to Use it > > > > > > HzImageWriter new > > > format: HzCogImageFormat new; "or HzInterpreterImageFormat new" > > > imageFileName: 'someFile.image'; > > > onInitializeDo: [ "Some initialization?" ]; "this is optional, > > > probably the same as an startup script, probably nonsense" > > > writeImage: Smalltalk "Yes, we provide the our lovely global Smalltak, > > > but any SmalltalkImage instance could be" > > > > > > Next steps on this direction > > > > > > - support to write an isolated image different from the host one (I'll know > > > what I need later, hehe) > > > - class comments! > > > - metacello configuration > > > - better api :) > > > > > > Links > > > > > > http://ss3.gemstone.com/ss/ImageWriter.html > > > > > > > > > Cheers, > > > Guille Cheers, Juan Vuletich

April 26, 2012

Re: [Pharo-project] Nautilus for Pharo 2.0?

by Marcus Denker

On Apr 26, 2012, at 2:41 PM, Noury Bouraqadi wrote: > Strange. I can't find it :-( > Nautilus points to Nautilus 1.4. > And I can't figure out the link. https://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/ Nautilus is included. -- Marcus Denker -- http://marcusdenker.de

April 26, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by Norbert Hartl

Am 26.04.2012 um 14:05 schrieb Edgar De Cleene: > > > > El 4/26/12 5:19 AM, "Pavel Krivanek" <pavel.krivanek(a)gmail.com> escribiÃ³: > >> Hi Chris, >> >> the planed changes in Pharo are not autotelic but in most cases they >> are replacements of current buggy and unmaintainable subsytems. >> We also use automatic or semiautomatic tools for shrinking and >> modularization of the image. For example uMorphic is generated moslty >> automatically with subsequent hand-made cleanup. The original Squeak >> KernelImage was generated in the similar way. But we use the results >> of this tools only as the supporting experimental sources of >> information. >> The goals of Cuis, Spoon and Pharo are very very similar. Everyone >> wants to have the "small, clean, understandable Smalltalk system". But >> Pharo development is more evolutional and modularity is more valuable >> than small size. >> In Smalltalk it is easy to dive into the system and create something >> like Cuis, Spoon or KernelImage. But this projects were created by a >> single person and the degree of adoption of this forks is low. You may >> for example to take the current PharoKernel and withing few days to >> create a perfect small and clean kernel. It is cool intelectual >> adventure but to make it generally used stuff is another story. >> >> -- Pavel > > > Again i ask to fellows on all forks adopt the great work of years from > Pavel. > We should not waste valuable time and instead take PharoKernel and build our > beloved pet on top of it. > That happens anyway for pharo. How could miss it? Norbert

April 26, 2012