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

Re: [Pharo-project] [update 1.4] #14356

by Nicolas Cellier

And still, one thing that is no obvious with split interdependency, is that the tests testing the two sides are inter-dependent. How do we express this interdependency? If we don't that let us free to modify one single side and break the contract. Nicolas Le 25 fÃ©vrier 2012 15:37, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > Ah yes, that was me, since one feature of the Compiler is to insert > notifications into source text editor, this has to be tested. > - does the Compiler insert the right notification ? > - does it insert the notification at the right place ? > > As soon as TextMorph and SmalltalkEditor provide a hook for > evaluating/compiling source, and a callback for notifications they > become inter-dependent. And we'd better write a test documenting the > interdependency. > > Of course, we can replace the TextEditor with a mock up, like the one > in CompilerTest and split the interdependency in two parts. > And then assert on the notifier side that: > - the compiler emit notifications with 1-based insertion point indices > (1 means insert before first character) > (Though I don't like the hardcoded positions in CompilerTest, it's not > readble, but could be changed). > > Right now, the notified side of interdependency is missing, I see no > test asserting that: > - SmalltalkEditor notify:at:in: insert notifications with 1-based indices > > If I change TextEditor insertion points to be 0-based, this will get > unnoticed... > > And this decomposition being less immediate than my simple tests, we > forgot one feature which is to evaluate a sub-selection. > This feature makes the interdependency much more complex > - is notifier aware of sub-selection location ? If yes, does it > provide a location related to beginning of sub-selection of beginning > of text ? > - same for the notified side... > > I'm sure that decomposing the dependency explicitly with tests would > help reducing the complexity... > That was one of my questions: > - what if we change usage of ReadWriteStream on:from:to: in selectionAsStream? > > Since I wrote tests in Squeak and simply ported to Pharo, and since I > missed CompilerTest (which is in Test-Compiler not in CompilerTests, > why the hell having two packages?), we could push refactoring further. > I made a class for testing a pair (Compiler notifying a > SmalltalkEditor), and a subclass for testing another pair (Compiler > notifying nil), but I think Pharo has very new capabilities, like > working with console like I/O, so this is another variant to test, and > maybe in this case splitting interdependency in two is not an > over-engineered feature anymore ;) > > Nicolas > > Le 25 fÃ©vrier 2012 14:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> a Ã©crit : >> Great, The basic Pharo Kernel Jobs can be build again! Leaving aside >> the fact that number of failing tests significantly increased because >> someone made compiler tests dependent on TextMorph (setUpForErrorsIn:) >> :-) >> >> -- Pavel >> >> On Sat, Feb 25, 2012 at 8:43 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> 14356 >>> ----- >>> >>> Issue 5376: Â Â AbstractTool fix removeMethods method >>> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5376 >>> >>> Issue 5371: Â Â XTableForUnicodeFont is not used anywhere (and an internal class) >>> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5371 >>> >>> Issue 5372: Â Â Remove old Mac font reading in StrikeFont >>> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5372 >>> >>> Issue 5370: Â Â AppRegistry class >> #default: dependent on Morphic >>> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5370 >>> >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >>

Feb. 25, 2012

Re: [Pharo-project] [update 1.4] #14356

by Nicolas Cellier

Ah yes, that was me, since one feature of the Compiler is to insert notifications into source text editor, this has to be tested. - does the Compiler insert the right notification ? - does it insert the notification at the right place ? As soon as TextMorph and SmalltalkEditor provide a hook for evaluating/compiling source, and a callback for notifications they become inter-dependent. And we'd better write a test documenting the interdependency. Of course, we can replace the TextEditor with a mock up, like the one in CompilerTest and split the interdependency in two parts. And then assert on the notifier side that: - the compiler emit notifications with 1-based insertion point indices (1 means insert before first character) (Though I don't like the hardcoded positions in CompilerTest, it's not readble, but could be changed). Right now, the notified side of interdependency is missing, I see no test asserting that: - SmalltalkEditor notify:at:in: insert notifications with 1-based indices If I change TextEditor insertion points to be 0-based, this will get unnoticed... And this decomposition being less immediate than my simple tests, we forgot one feature which is to evaluate a sub-selection. This feature makes the interdependency much more complex - is notifier aware of sub-selection location ? If yes, does it provide a location related to beginning of sub-selection of beginning of text ? - same for the notified side... I'm sure that decomposing the dependency explicitly with tests would help reducing the complexity... That was one of my questions: - what if we change usage of ReadWriteStream on:from:to: in selectionAsStream? Since I wrote tests in Squeak and simply ported to Pharo, and since I missed CompilerTest (which is in Test-Compiler not in CompilerTests, why the hell having two packages?), we could push refactoring further. I made a class for testing a pair (Compiler notifying a SmalltalkEditor), and a subclass for testing another pair (Compiler notifying nil), but I think Pharo has very new capabilities, like working with console like I/O, so this is another variant to test, and maybe in this case splitting interdependency in two is not an over-engineered feature anymore ;) Nicolas Le 25 fÃ©vrier 2012 14:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> a Ã©crit : > Great, The basic Pharo Kernel Jobs can be build again! Leaving aside > the fact that number of failing tests significantly increased because > someone made compiler tests dependent on TextMorph (setUpForErrorsIn:) > :-) > > -- Pavel > > On Sat, Feb 25, 2012 at 8:43 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> 14356 >> ----- >> >> Issue 5376: Â Â AbstractTool fix removeMethods method >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5376 >> >> Issue 5371: Â Â XTableForUnicodeFont is not used anywhere (and an internal class) >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5371 >> >> Issue 5372: Â Â Remove old Mac font reading in StrikeFont >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5372 >> >> Issue 5370: Â Â AppRegistry class >> #default: dependent on Morphic >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5370 >> >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >

Feb. 25, 2012

[Pharo-project] So I broke 8k req/s today

by Philippe Marschall

Hi I heighten everybody's mood I'll post some positive news. After some optimizations in both Seaside and AJP I managed to break 8000 requests / sec with a single Pharo 1.3 image. Thanks to SystemProfiler I knew where to look. This is with a single request handler that just returns a two byte response. It doesn't involve any rendering, sessions, continuations or whatsoever but it kicks on the full Seaside request handling machinery with a request context and everything. I'm using WASmallRequestHandler from the Seaside-Benchmark package. WASmallRequestHandler >> #handleFiltered: aRequestContext aRequestContext respond: [ :response | response binary; contentType: WAMimeType textHtml; nextPutAll: 'OK' asByteArray ] Apache 2.2.21 mpm_worker mod_proxy_ajp CPU Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz SmalltalkImage current vmVersion 'Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.138]' Attached you'll find the output of ApacheBench. Cheers Philippe

Feb. 25, 2012

Re: [Pharo-project] [update 1.4] #14356

by Pavel Krivanek

Great, The basic Pharo Kernel Jobs can be build again! Leaving aside the fact that number of failing tests significantly increased because someone made compiler tests dependent on TextMorph (setUpForErrorsIn:) :-) -- Pavel On Sat, Feb 25, 2012 at 8:43 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 14356 > ----- > > Issue 5376: Â Â AbstractTool fix removeMethods method > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5376 > > Issue 5371: Â Â XTableForUnicodeFont is not used anywhere (and an internal class) > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5371 > > Issue 5372: Â Â Remove old Mac font reading in StrikeFont > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5372 > > Issue 5370: Â Â AppRegistry class >> #default: dependent on Morphic > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5370 > > > > -- > Marcus Denker -- http://marcusdenker.de > >

Feb. 25, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by H. Hirzel

On 1/18/12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Dennis, your screenshots are awesome, hope remains for a direct > manipulation framework such as Morphic to beet lesser and boring > standard UI WIDGETS frameworks. > > And by the way, Morphic isnt ours..it comes from a groundbreaking > object-focused environment called SELF. > Fernando Thank you for the reminder and the screen shot of a self screen. A recent implementation of Morphic using only HTML 5 canvas and JavaScript by Jens MÃ¶nig is here http://chirp.scratchr.org/dl/experimental/JsMorphic/morphic.html and the documentation is here http://chirp.scratchr.org/dl/experimental/JsMorphic/morphic.txt (21 - Feb - 2012) The code (MIT license) is very readable http://chirp.scratchr.org/dl/experimental/JsMorphic/morphic.js Morphic was developed in connection with the programming language 'Self'. The Wikipedia article http://en.wikipedia.org/wiki/Self_(programming_language) says that self is an _extreme_ dialect of Smalltalk. "Self was designed mostly by David Ungar and Randall Smith in 1986 while working at Xerox PARC. Their objective was to push forward the state of the art in object-oriented programming language research, once Smalltalk-80 was released by the labs and began to be taken seriously by the industry." --Hannes

Feb. 25, 2012

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3

by Schwab,Wilhelm K

Sig, This is helpful, as you have told me what is killing my images. Then you say to load then you say to load the latest config. Happy to comply, but how do I do that? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Saturday, February 25, 2012 12:39 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 On 25 February 2012 06:52, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 February 2012 06:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> Sorry about the empty reply. Migrate is fair game, and the image was healthy enough to file out the base (attached). Please look over how I install FFI to see if there are any mistakes. You might need to stub out a basic subclass (e.g. MigrateSig or anything else you want to call it) with a few methods (#me, #homeGrownClasses, etc.) to make it happy. Content of them can be simple to start. The "private stuff" has yet to enter the picture so shouldn't matter to us. >> >> THANKS!!! >> > Good. I will take a look. > >> Bill Ok, things for starting: Gofer new url:self mirror, 'MetacelloRepository'; package: 'ConfigurationOfAlien'; load. (Smalltalk globals classNamed: 'ConfigurationOfAlien') perform:#loadLatestVersion. Never ever use #loadLatestVersion, always use concrete version numbers, if you want to have stability. In our case, #loadLatestVersion is not quite latest, you can check it by yourself: ConfigurationOfAlien project updateProject. ConfigurationOfAlien project latestVersion "inspect it" 0.1 [ConfigurationOfAlien] so it actually loads not the latest available version, but the most old one. Because it is the only version with #release blessing. And i can tell you without even proceeding further, that it won't work in 1.3 neither in 1.4, because it is too old and not takes into account certain changes made in pharo. For instance: package: 'Alien-Prereqs' is no longer needed, as i told here: http://forum.world.st/Alien-Prerequisites-is-now-not-required-td3258432.html but its even worse, this version of config will be loading Alien-Prereqs-mha.3 which having even more overrides, and will definitely put image to its knees because compiler will be broken. So, try to load latest config first, if it would not help we will continue. P.S. to all people involved in using Alien.. some love needed to update configs for pharo 1.3 and 1.4 to finally get rid of 'Alien-Prereqs' package loading. -- Best regards, Igor Stasenko.

Feb. 25, 2012

[Pharo-project] [update 1.4] #14356

by Marcus Denker

14356 ----- Issue 5376: AbstractTool fix removeMethods method http://code.google.com/p/pharo/issues/detail?id=5376 Issue 5371: XTableForUnicodeFont is not used anywhere (and an internal class) http://code.google.com/p/pharo/issues/detail?id=5371 Issue 5372: Remove old Mac font reading in StrikeFont http://code.google.com/p/pharo/issues/detail?id=5372 Issue 5370: AppRegistry class >> #default: dependent on Morphic http://code.google.com/p/pharo/issues/detail?id=5370 -- Marcus Denker -- http://marcusdenker.de

Feb. 25, 2012

Re: [Pharo-project] DrGeo on ARM Android

by Hilaire Fernandes

Yes, it will be nice to have one chapter one the Pharo collaboractive book. Hilaire Le 24/02/2012 08:11, Olivier Auverlot a Ã©crit : > Hi Hilaire, > > It's very cool ! > > I will probably working on a projet for an android tablet in the next > weeks. That's could be cool to do it with Pharo. > > Could you share your experience about this subjet ? It will be nice to > have a documentation about the problematic of the adaptation and the > deploiment of an application made with Pharo on a Android tablet. > > What are the problems ? How to package the application to distribute ? > What are the limitations ? > > I think many users will be interested to read you because mobility is > become a critical subject. > > Best regards > Olivier ;-) > > www.auverlot.fr > >> Dimitry and I are working on the DrGeo port to the Android ARM Operating >> System. >> DrGeo on Pharo with Stack VM proves to be smooth and neat to use. >> http://www.drgeo.eu/screenshot-video >> >> Thanks >> > > > -- Dr. Geo -- http://www.drgeo.eu

Feb. 25, 2012

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3

by Igor Stasenko

On 25 February 2012 06:52, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 February 2012 06:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> Sorry about the empty reply. Â Migrate is fair game, and the image was healthy enough to file out the base (attached). Â Please look over how I install FFI to see if there are any mistakes. Â You might need to stub out a basic subclass (e.g. MigrateSig or anything else you want to call it) with a few methods (#me, #homeGrownClasses, etc.) to make it happy. Â Content of them can be simple to start. Â The "private stuff" has yet to enter the picture so shouldn't matter to us. >> >> THANKS!!! >> > Good. I will take a look. > >> Bill Ok, things for starting: Gofer new url:self mirror, 'MetacelloRepository'; package: 'ConfigurationOfAlien'; load. (Smalltalk globals classNamed: 'ConfigurationOfAlien') perform:#loadLatestVersion. Never ever use #loadLatestVersion, always use concrete version numbers, if you want to have stability. In our case, #loadLatestVersion is not quite latest, you can check it by yourself: ConfigurationOfAlien project updateProject. ConfigurationOfAlien project latestVersion "inspect it" 0.1 [ConfigurationOfAlien] so it actually loads not the latest available version, but the most old one. Because it is the only version with #release blessing. And i can tell you without even proceeding further, that it won't work in 1.3 neither in 1.4, because it is too old and not takes into account certain changes made in pharo. For instance: package: 'Alien-Prereqs' is no longer needed, as i told here: http://forum.world.st/Alien-Prerequisites-is-now-not-required-td3258432.html but its even worse, this version of config will be loading Alien-Prereqs-mha.3 which having even more overrides, and will definitely put image to its knees because compiler will be broken. So, try to load latest config first, if it would not help we will continue. P.S. to all people involved in using Alien.. some love needed to update configs for pharo 1.3 and 1.4 to finally get rid of 'Alien-Prereqs' package loading. -- Best regards, Igor Stasenko.

Feb. 25, 2012

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3

by Igor Stasenko

On 25 February 2012 06:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Sorry about the empty reply. Â Migrate is fair game, and the image was healthy enough to file out the base (attached). Â Please look over how I install FFI to see if there are any mistakes. Â You might need to stub out a basic subclass (e.g. MigrateSig or anything else you want to call it) with a few methods (#me, #homeGrownClasses, etc.) to make it happy. Â Content of them can be simple to start. Â The "private stuff" has yet to enter the picture so shouldn't matter to us. > > THANKS!!! > Good. I will take a look. > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] > Sent: Friday, February 24, 2012 10:30 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 > > On 25 February 2012 03:39, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> *I* can't set that up, but I know someone who can. Â It won't be a soft sell though, but it is kind offer on your part and I will investigate. Â Right now, the private project is Migrate, and you can HAVE that; I just need to scratch my head about how to make it work for you, after which you can tell me how naive I'm being :) >> > I have own reasons to help. So if you think you still need it, feel > free to contact me. > >> For now, I appear to have found the culprit: loading Alien is frying the image. >> > > Quite possible. FFI is delicate thing. > >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Friday, February 24, 2012 6:58 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3 >> >> One more thing: if it about private project, just tell me where to put >> my signature under NDA. >> If that would help to make Pharo more stable as well as help your >> project to keep going on, we're both in mutual benefit without risks >> for you. >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Feb. 25, 2012