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

Re: [Pharo-project] ConfigurationOfAlien

by Fernando olivero

Alain, thanks for pointing this out. I've tried with the latest dev images, and it works there. In the core images it doesn't. as you found out. Anybody have a clue why? I dont have time to track down why at the moment, but will do in the future. Fernando On Jan 14, 2010, at 9:19 AM, Alain Plantec wrote: > Hi all, > > From a freshly updated 11151->11156 > after > > (ConfigurationOfAlien project version:'1.0') load. > > I've > Array DNU createMethod:header: > and can't open debugger anymore. > > see screenshot. > > Maybe ConfigurationOfAlien/Alien is(are) only for 1.0 ? > Sorry if I missed something. > > Cheers > Alain > > Fernando olivero a Ã©crit : >> Hi, just added ConfigurationOfAlien to the MetacelloRepository. >> >> >> To load Alien using Metacello configurations evaluate >> >> Gofer new >> url: 'http://www.squeaksource.com/MetacelloRepository' ; >> package: 'ConfigurationOfAlien'; >> load. >> (ConfigurationOfAlien project version:'1.0') load. >> >> >> ( John please update the ALIEN squeaksource page with the previous text ) >> >> >> Note: >> Using the available MAC VM i the pharo page, you should be able to run the test correctly. >> ( the alien plugin 'IA32ABI 7 May 2009 (e)', is compiled inside that vm, there's no need for the external one) >> >> >> Metacello question: >> >> If i want load Alien Examples, the package Alien-MacOSExamples, but don't want to add them to the above configuration , should i create a new #versionXXX method ? >> >> Or provide a class side method like for example >> >> ConfigurationOfAlien>>loadWithMaxOsExamples >> (ConfigurationOfAlien project version:'1.0') load:#('Alien-MacOsExamples') >> >> >> Saludos, >> Fernando >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > <Capture.png><ATT00001..txt>

Jan. 14, 2010

Re: [Pharo-project] [Vm-dev] SystemTracer64 progress

by Laval Jannik

Hi Dave, Thank you for your feedback :), Now, in the PharoCore64, some tests crash or loops. I will see that :) Cheers, Jannik On Jan 12, 2010, at 13:29 , David T. Lewis wrote: > > On Tue, Jan 12, 2010 at 08:31:11AM +0100, Laval Jannik wrote: >> >> On Jan 12, 2010, at 04:55 , David T. Lewis wrote: >> >>> Over the weekend I made some progress in getting SystemTracer updated >>> to do 64-bit image tracing. Previously SystemTracer64 did not work on >>> little-endian machines (Mantis 5240). This is corrected now, and the >>> code is on SqueakSource in project "SystemTracing". >>> >>> I can now trace a Squeak 3.10.2 image to 64-bit format on my Linux >>> AMD box (little endian), producing a runnable 64-bit image. For >>> an up to date Squeak trunk image, I can trace a 64 image that >>> loads and runs (display opens and things start working), but that >>> has problems with resuming its background processes (low space >>> watcher etc). Possibly it's related to the block closure changes, >>> although I believe there was an earlier report of a Pharo image >>> with block closures being successfully traced to 64 bit format. >>> >> >> Hi David, >> >> I cannot write my changes. >> So you can have them in attachment. >> >> In these .cs, there is a merge with your version .15. >> And it works with Pharo. > > Jannik, > > Thank you for sending this. I will compare and merge as soon as I > have some more free time. > > Also, your PharoCore64-1.1-11152-UNSTABLE image works fine on my > Linux box. > > Dave >

Jan. 14, 2010

[Pharo-project] Comments on Metacello and ConfigurationOfExternalWebBrowser

by Torsten Bergmann

>Two little remarks of the conf: you are using for FFI '1.0-baseline', not a >version, this means that it will ALWAYS bring the latest version (maybe >unstable). That's why I always try to put a particular version that I know >is stable. Thought about that again and looked at other examples. Now the baseline of ExternalWebbrowser depends on a baseline of FFI. And the version itself uses the version. See ConfiguratonOfExternalWebBrowser-tbn-5.mcz This is similar to what Dale did in the seaside 3.0 config with grease and follows the rules from #lesson11Blessing: "Since the latest #baseline version should reflect the most up-to-date project structure, ... should load the absolute bleeding edge of the project." >Come on!!! That's not an excuse ;) Have access now - typos in the tutorial are fixed. Included in 1.0-beta.20 of metacello conf. Just run "ConfigurationOfMetacello loadLatestPackages" Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Jan. 14, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by StÃ©phane Ducasse

Elliot it would be realllllllly cool to have this in the squeak-vm what should be done to get it? Stef On Jan 13, 2010, at 7:41 PM, Eliot Miranda wrote: > A *much* better way to implement this is to support immutability in the VM (I know, I know, but all the code is available in the Newspeak VM), mark objects one wants to mark as dirty as immutable, catch the NoModificationError exception, and proceed after having made the object mutable and marked it dirty. No creating hidden classes, no trying to get change class to work for compact classes, etc. Just a simple VM-implemented write barrier that can also be used for a host of other things (object-database mapping, debugging, immutable literals etc). > > On Wed, Jan 13, 2010 at 9:55 AM, Chris Muller <asqueaker(a)gmail.com> wrote: > A great description of what WriteBarrier does and how it works can be > found in the WriteBarrier class-comment, itself. > > In a nutshell, when an object is added to a WriteBarrier, a subclass > is dynamically compiled for it, but not added to the Smalltalk > dictionary. The name of the class is the same as its superclass but > with a '*' appended to it. > > After creating the subclass, WriteBarrier looks at all "definitions" > of each instance variable, and adds methods to override the methods in > its superclass. The generated override checks the pre-state of the > instVar, calls super, then compares the post-state of the instVar to > the pre-state. > > If it changed, it signals so that the application (Magma) can mark it dirty. > > So, it allows Magma to operate with a smaller readSet, which speeds up > the part of the commit process relating to detection of changed > objects for building the CommitPackage which is shipped off to the > server.. > > - Chris > > 2010/1/13 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: > > El miÃ©, 13-01-2010 a las 18:08 +0200, Igor Stasenko escribiÃ³: > >> Can someone clarify, why WriteBarrier depends on compiler (new > >> compiler or old compiler - not really important). > >> I just wonder what compiler functionality its depends on. > > > > WriteBarrier uses the class BytecodeGenerator that is part of the > > package NewCompiler (that is currently on rewrite for the closure > > images). Why it need it and how it use it, I really don't know. I have > > only a vague idea of what WriteBarrier does, and as Mariano said, I use > > Magma but never used or activated the WriteBarrier functionality of it. > > > > Cheers > >> > >> 2010/1/13 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> > > >> > > >> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > >> >> > >> >> 2010/1/12 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> > Magma depends on NewCompiler ??? > >> >> > >> >> No, WriteBarrier depends on NewCompiler. > >> >> > >> >> Magma can, at the explicit option of the user, turn on the > >> >> WriteBarrier option if the WriteBarrier package is present. > >> >> WriteBarrier used to be self-contained, later it became dependent on > >> >> NewCompiler. > >> >> > >> >> Unless the WriteBarrier option is switched on by the user, its > >> >> presence or absence in the image (as well as NewCompiler) has no > >> >> effect on Magma. > >> >> > >> > > >> > Thanks for the clarification Chris. It was strange for me that as I used > >> > Magma a couple of times and I never installed WriteBarrier neither > >> > NewCompiler. > >> > > >> > Cheers > >> > > >> > Mariano > >> > > >> > > >> >> > >> >> - Chris > >> >> > >> >> _______________________________________________ > >> >> Pharo-project mailing list > >> >> Pharo-project(a)lists.gforge.inria.fr > >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 14, 2010

Re: [Pharo-project] ConfigurationOfAlien

by Alain Plantec

Hi all, From a freshly updated 11151->11156 after (ConfigurationOfAlien project version:'1.0') load. I've Array DNU createMethod:header: and can't open debugger anymore. see screenshot. Maybe ConfigurationOfAlien/Alien is(are) only for 1.0 ? Sorry if I missed something. Cheers Alain Fernando olivero a Ã©crit : > Hi, just added ConfigurationOfAlien to the MetacelloRepository. > > > To load Alien using Metacello configurations evaluate > > Gofer new > url: 'http://www.squeaksource.com/MetacelloRepository' ; > package: 'ConfigurationOfAlien'; > load. > (ConfigurationOfAlien project version:'1.0') load. > > > ( John please update the ALIEN squeaksource page with the previous text ) > > > Note: > Using the available MAC VM i the pharo page, you should be able to run the test correctly. > ( the alien plugin 'IA32ABI 7 May 2009 (e)', is compiled inside that vm, there's no need for the external one) > > > Metacello question: > > If i want load Alien Examples, the package Alien-MacOSExamples, but don't want to add them to the above configuration , should i create a new #versionXXX method ? > > Or provide a class side method like for example > > ConfigurationOfAlien>>loadWithMaxOsExamples > (ConfigurationOfAlien project version:'1.0') load:#('Alien-MacOsExamples') > > > Saludos, > Fernando > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Jan. 14, 2010

[Pharo-project] Metacello configuration of Magma

by Miguel Enrique CobÃ¡ Martinez

I have published the Metacello configuration of Magma in the MetacelloRepository of squeaksource.com. Take a PharoCore 10506 and evaluate in a workspace: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMagma'; load. Then load the default group that loads the Magma Client: ((Smalltalk at: #ConfigurationOfMagma) project version: '1.0r43') load this is equivalent to: ((Smalltalk at: #ConfigurationOfMagma) project version: '1.0r43') load: 'Client'. To load the Magma Server evaluate: ((Smalltalk at: #ConfigurationOfMagma) project version: '1.0r43') load: 'Server'. And to load the Magma Tester evaluate: ((Smalltalk at: #ConfigurationOfMagma) project version: '1.0r43') load: 'Tester'. This last one will load also OSProcess that is used by the Magma Tester to do the stress testing of Magma. Notes: - WriteBarrier is a package loaded by Magma. This requires NewCompiler as dependency but as NewCompiler is being rewritten currently, isn't loaded as a dependency. - Magma makes use of ProjectHistory that doesn't exist anymore in Pharo. Magma will fix this by conditionally testing for ProjectHistory by means of Smalltalk at: #ProjectHistory. - This is the first configuration for Magma and will be modified in response to the feedback you give me. - Currently the blessing is #development. Maybe this should be marked as #stable in order to load with: ((Smalltalk at: #ConfigurationOfMagma) project latestVersion) load. This way it will install the latest non-development version available in MetacelloRepository without having to specify a version number. - This configuration executes a preLoadDoIt with the following code: Smalltalk at: #EventSensor put: InputEventSensor because EventSensor was removed from Pharo, but Magma add some methods to EventSensor class. I *really* need feedback about the risks of doing this. Any feedback is welcome. Enjoy! -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 14, 2010

[Pharo-project] regex gurus anyone? Method category refactoring?

by Stan Shepherd

Hi, I'm looking at getting the window building tools to provide some information to a theme, so it can provide meaningful themeing (in the first instance window color) . So I have a list of the senders of #labelled:, that currently are sending virginal SystemWindows with no models. I'd like to do a regex on the scoped list, of the form (SystemWindow labelled: 'later') model: self. becomes (SystemWindow labelled: 'later' justSetModel: self) model: self. So the theme can see the model at the time it's asked to provide the color. ie (SystemWindow labelled: foo ) model: bar. becomes (SystemWindow labelled: foo justSetModel: bar) model: bar. Any takers on a regex for that? Also, how do you add all the methods changed to category *MyWindow-Changes in one go? Bear in mind no package browser in the dev or one click images. Thanks, ...Stan -- View this message in context: http://n2.nabble.com/regex-gurus-anyone-Method-category-refactoring-tp43901… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 14, 2010

Re: [Pharo-project] [ANN] Metacello configuration of OSProcess

by David T. Lewis

On Wed, Jan 13, 2010 at 04:01:32PM -0600, Miguel Enrique Cob? Martinez wrote: > El mi??, 13-01-2010 a las 15:52 -0600, Miguel Enrique Cob?? Martinez > escribi??: > > I ran the tests in PharoCore 10506 and got 4 failures: > > AioEventHandlerTestCase>>#testSocketExceptionEvent > AioEventHandlerTestCase>>#testSocketReadableEvent > AioEventHandlerTestCase>>#testSocketReadableEventWithMaskNotSet > AioEventHandlerTestCase>>#testSuspendAioForSocketReadableEvent > > All of them caused by > > ByteArray(Object)>>doesNotUnderstand: #port: > > in: > > Socket>>connectTo:port: This is caused by changes to NetNameResolver in Pharo versus Squeak. If you set the UseOldNetwork variable to false in NetNameResolver, the tests will pass. The issue is that the following expression does not work with the new network code: Socket newTCP connectTo: (NetNameResolver addressFromString: '127.0.0.1') port: 8086 I'm not sure if this is a bug or a feature. Dave

Jan. 14, 2010

Re: [Pharo-project] EventSensor vs EventInputSensor

by Schwab,Wilhelm K

Stef, Polling for events is baaaaad. However, is the new mechanism tainted by poor support for weak collections? If so, it might be better to poll until we get the latter right and can get away from #release as a requirement. Unregistering interest in events should always be possible; it should not be required. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique CobÃ¡ Martinez Sent: Wednesday, January 13, 2010 6:38 PM To: Pharo-project(a)lists.gforge.inria.fr Cc: ma.chris.m(a)gmail.com Subject: Re: [Pharo-project] EventSensor vs EventInputSensor El miÃ©, 13-01-2010 a las 22:27 +0100, StÃ©phane Ducasse escribiÃ³: > I do not know > what I know is that we should support the new event architecture and > deprecate the polling one > > Well, I'm doing it as a preload doit in the metacello configuration. The problem is that goes unnoticed by the user. And maybe later could give surprises. Can someone giver their opinion about this? By having it in PharoCore is visible in the change log of Pharo. But what could someday be wrong with having it in Pharo? -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 14, 2010

Re: [Pharo-project] EventSensor vs EventInputSensor

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 13-01-2010 a las 22:27 +0100, StÃ©phane Ducasse escribiÃ³: > I do not know > what I know is that we should support the new event architecture and deprecate the polling one > > Well, I'm doing it as a preload doit in the metacello configuration. The problem is that goes unnoticed by the user. And maybe later could give surprises. Can someone giver their opinion about this? By having it in PharoCore is visible in the change log of Pharo. But what could someday be wrong with having it in Pharo? -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 14, 2010