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

Re: [Pharo-dev] Rationale for RGClassDefinition>>definition?

by stepharo

016-01-21 9:07 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > > I do not know now I would have love that veronica believed in tests. > the difference is the following > > > a RG cna either > - wrap and point to a living entity > - acts a dead one (representing a class on a disk) > > > Yes, I was about to add a check for isActive/isPassive for > RGClassDefinition, but this isAcitve/isPassive is only > defined for Ringmethods not for Ring class (or behavior) definitions. I think that we should add it to classes too. In fact we should consider ring as a first try and it is in our plan to revisit it but too busy.

Jan. 21, 2016

Re: [Pharo-dev] Bad layoutFrame>>#hash

by stepharo

It is neat :) Le 21/1/16 11:18, Henrik Nergaard a Ã©crit : > What about something like this? > > > ^self species hash hashComposer > add: leftFraction; > add: leftOffset; > add: topFraction; > add: topOffset; > add: rightOffset; > add: bottomFraction; > add: bottomOffset > > HashComposer>>#add: anObject > > ^hash := (hash + anObject hash) hashMultiply > > > Best regards, > Henrik > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont > Sent: Wednesday, January 13, 2016 8:34 PM > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Bad layoutFrame>>#hash > > On 13-01-16 18:38, David Allouche wrote: >> Why did you use a single expression instead of using a temporary variable? I find it harder to understand. > I did find it very slightly easier to understand. It is not a strong opinion however. > > The ideomatic smalltalk would be > > ^#(leftFraction leftOffset topFraction topOffset rightFraction rightOffset bottomFraction bottomOffset) > inject: self species hash into: [:hashValue :selector | > (hashValue + self perform: selector) hashMultiply ] > > but that would be slower. > > I would be tempted to add a binary message > > Integer>>+** aNumber > ^(aNumber +self hash) hashMultiply > > (I'd prefer +#*, but that doesn't parse) > > hash > ^self species hash +** > leftFraction +** leftOffset +** > topFraction +** topOffset +** > rightFraction +** rightOffset +** > bottomFraction +** bottomOffset > > > > Stephan > > > >

Jan. 21, 2016

Re: [Pharo-dev] ESUG '16?

by stepharo

I will take place at Prague and the dates are about to be announced because there were some bugs in the hotel quotes! Le 21/1/16 14:42, Alexandre Bergel a Ã©crit : > Hi! > > Anyone know when ESUGâ16 will take place? > > Alexandre

Jan. 21, 2016

Re: [Pharo-dev] [ANN] GitHub API Bindings: new version

by stepharo

Excellent Job Skip!!! Great Documentation. Stef Le 21/1/16 11:30, Skip Lentz a Ã©crit : > Hi everyone, > > I am announcing a new version for the API bindings to GitHub in Pharo. > For documentation and information on how to load it, see the new > project homepage: > > https://balletie.github.io/GitHub/ (generated with Pillar. Plug for > Damien and Cyril) > > For a list of changes in this release, follow this link: > https://github.com/Balletie/GitHub/releases/tag/v0.5 > > To load absolutely everything, including the tests and the tool, evaluate: > > Metacello new > baseline: 'GitHub'; > repository: 'github://Balletie/GitHub:master' > <github://Balletie/GitHub:master%27>; > load: #(tests tool) > > If you have loaded the tool, it can be opened via the world > menu, under âToolsâ. > > Feedback welcome :)

Jan. 21, 2016

Re: [Pharo-dev] [ANN] Pharo bootstrap

by stepharo

reducing also the number of classes in the kernel could help. But first it should work and then we start to optimize Now this is true that 10 h is insane :) Le 20/1/16 09:08, Christophe Demarey a Ã©crit : > Hi Pavel, > > Le 19 janv. 2016 Ã 19:53, Pavel Krivanek a Ã©crit : > >> Hi, >> >> amazing! Do you have any idea how to speed up it? The bootstrap >> process is now running on my machine about one and half hour and it >> is still far from finish. > > The process is indeed far too long (takes around 10 hours) on the CI > server. > Reasons are: > - we use a stack interpreter VM > - we modified it and is a bit slower than a classical stack VM > - we use AST interpretation to build the bootstrap and it is very > slow. Guille already did some speed improvements by avoiding to > interpret loops by example. > > I did not yet spend time on this point because I first wanted to have > something working. > Definitely, this problem will be tackled when we will put in > production the bootstrap. > > Cheers, > Christophe > > >> Cheers, >> -- Pavel >> >> 2016-01-19 15:29 GMT+01:00 Christophe Demarey >> <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>>: >> >> Hi all, >> >> In case you do not know, we work on bootstrapping Pharo, i.e. >> create a Pharo image from sources, not based on a previous image >> (well, we use a pharo image to produce it but no code / state >> from it). >> >> This process will allow to define a minimal Pharo kernel >> (currently 52 packages but we could have it far smaller) and to >> modularize the whole image (currently packages have too much >> dependencies on packages already loaded into the image). >> The bootstrap process also allows to write down the recipe to >> initialize a new image from scratch (some code is missing in the >> image or is wrong). In addition, I think we will clean a lot of >> historical objects that are not used anymore. >> >> With the amazing work done by Guillermo Polito during his Phd >> (around Espell, Oz): >> https://guillep.github.io/files/publications/Poli15Thesis.pdf, >> *we succeeded to get a first prototype of a bootstraped Pharo 5 >> image (from 5.392)*. >> This prototype is able to run an eval command line handler and to >> log output / errors. Not all classes are yet initialized and you >> cannot yet save / restart this image but it is a big step forward. >> It is a 4 mb image (could be half the size without unicode data). >> You can download it at: >> http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/pharo-bootstrap/pharo-… >> <http://chercheurs.lille.inria.fr/%7Edemarey/pmwiki/pub/pharo-bootstrap/phar…>. >> >> Next steps are to have a bootstrapped image fully working, then >> to load packages on top of it (like network, sunit) to produce a >> minimal image. >> Then, we need to implement an Oz VM on top of Spur. >> After that, we need to work on a reliable way to build the >> bootstrap (not too sensitive to changes in the image). >> >> Christophe. >> >> ------- >> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ >> ../pharo bootstrap.image --no-default-preferences eval "1 + 1" >> 2 >> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ >> ../pharo bootstrap.image --no-default-preferences eval "'a' , 'b'" >> 'ab' >> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ >> ../pharo bootstrap.image --no-default-preferences eval "1 / 0" >> ZeroDivide >> SmallInteger>>/ >> UndefinedObject>>DoIt >> OpalCompiler>>evaluate >> OpalCompiler(AbstractCompiler)>>evaluate: >> SmalltalkImage>>evaluate: >> >> EvaluateCommandLineHandler>>no (source is Undeclared) >> no source in EvaluateCommandLineHandler>>evaluate: in Block: no >> source >> BlockClosure>>on:do: >> EvaluateCommandLineHandler>>evaluate: >> EvaluateCommandLineHandler>>evaluateArguments >> EvaluateCommandLineHandler>>activate >> EvaluateCommandLineHandler class(CommandLineHandler >> class)>>activateWith: >> >> BasicCommandLineHandler>>no (source is Undeclared) >> no source in >> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >> in Block: no source >> BlockClosure>>on:do: >> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand >> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: >> >> BasicCommandLineHandler>>no (source is Undeclared) >> no source in >> PharoCommandLineHandler(BasicCommandLineHandler)>>activate in >> Block: no source >> BlockClosure>>on:do: >> PharoCommandLineHandler(BasicCommandLineHandler)>>activate >> PharoCommandLineHandler>>activate >> PharoCommandLineHandler class(CommandLineHandler >> class)>>activateWith: >> >> PharoCommandLineHandler class>>no (source is Undeclared) >> no source in PharoCommandLineHandler class>>activateWith: in >> Block: no source >> NonInteractiveUIManager(UIManager)>>defer: >> PharoCommandLineHandler class>>activateWith: >> no source in BasicCommandLineHandler>>activateSubCommand: in >> Block: no source >> BlockClosure>>on:do: >> BasicCommandLineHandler>>activateSubCommand: >> BasicCommandLineHandler>>handleSubcommand >> BasicCommandLineHandler>>handleArgument: >> no source in BasicCommandLineHandler>>activate in Block: no source >> >> SmallInteger>>no (source is Undeclared) >> >> UndefinedObject>>no (source is Undeclared) >> >> AbstractCompiler>>no (source is Undeclared) >> >> SmalltalkImage>>no (source is Undeclared) >> >> BlockClosure>>no (source is Undeclared) >> >> EvaluateCommandLineHandler>>no (source is Undeclared) >> >> EvaluateCommandLineHandler>>no (source is Undeclared) >> >> CommandLineHandler class>>no (source is Undeclared) >> >> BasicCommandLineHandler>>no (source is Undeclared) >> >> BasicCommandLineHandler>>no (source is Undeclared) >> >> PharoCommandLineHandler>>no (source is Undeclared) >> >> UIManager>>no (source is Undeclared) >> >> UndefinedObject>>no (source is Undeclared) >> >> CommandLineUIManager>>no (source is Undeclared) >> >> SmalltalkImage>>no (source is Undeclared) >> >> DelayMicrosecondScheduler>>no (source is Undeclared) >> >> BlockClosure>>no (source is Undeclared) >> >> SmalltalkImage>>no (source is Undeclared) >> >> WeakArray class>>no (source is Undeclared) >> >> >> ps: source cannot be displayed because there is no formatter >> available in the bootstrap >> >> >

Jan. 21, 2016

Re: [Pharo-dev] [ANN] Pharo bootstrap

by stepharo

> This is a much more complex and challenging subject that you might think. > > There has been a lot of work done on this for many years, many approaches have been tried. > > I am pretty sure that the people behind the Pharo Bootstrap project are aware of the existing literature. oh yes and even of things that were not written in papers. :)

Jan. 21, 2016

Re: [Pharo-dev] [squeak-dev] Smalltalk website tricks

by stepharo

Please guys use the Pharo-user mailing-list. Le 21/1/16 19:39, Dimitris Chloupis a Ã©crit : > Does not render well on my iPad and has problems with multi touch, > looks cool though :) > On Thu, 21 Jan 2016 at 19:19, Craig Latta <craig(a)netjam.org > <mailto:craig@netjam.org>> wrote: > > > Hi-- > > I wrote a new website for Black Page Digital, my consultancy in > Amsterdam and San Francisco. It includes SqueakJS running in a 3D CSS > viewport, kinda cute. Please check it out, pass it on, and let me know > what you think! > > > http://thiscontext.com/2016/01/21/new-website-for-black-page-digital > > > thanks, > > -C > > -- > Craig Latta > Black Page Digital > postbus 10784 > 1001ET Amsterdam, Netherlands > craig(a)blackpagedigital.com <mailto:craig@blackpagedigital.com> > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > >

Jan. 21, 2016

Re: [Pharo-dev] [squeak-dev] re: Smalltalk website tricks

by Dimitris Chloupis

It first told me close other tabs for it to load a database which was weird I double clicked and then the interface turned 3D sidewise and i could not bring straight , also it shadow created a mouse pointer that was offset to my touch event. Touching was bringing a world menu and there was also a workspace mixed with the images On Thu, 21 Jan 2016 at 21:31, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > It first told me close other tabs for it to load a database which was weird > > I double clicked and then the interface turned 3D sidewise and i could not > bring straight , also it shadow created a mouse pointer that was offset to > my touch event. Touching was bringing a world menu and there was also a > workspace mixed with the images > On Thu, 21 Jan 2016 at 20:45, Craig Latta <craig(a)netjam.org> wrote: > >> >> > Does not render well on my iPad and has problems with multi touch. >> >> Hm, it should be ignoring multi-touch gestures. What happens? And >> what rendering problems does it have? I haven't done any >> browser-specific optimizations yet. >> >> >> thanks! >> >> -C >> >> -- >> Craig Latta >> netjam.org >> +31 6 2757 7177 (SMS ok) >> + 1 415 287 3547 (no SMS) >> >> >>

Jan. 21, 2016

Re: [Pharo-dev] [squeak-dev] re: Smalltalk website tricks

by Dimitris Chloupis

It first told me close other tabs for it to load a database which was weird I double clicked and then the interface turned 3D sidewise and i could not bring straight , also it shadow created a mouse pointer that was offset to my touch event. Touching was bringing a world menu and there was also a workspace mixed with the images On Thu, 21 Jan 2016 at 20:45, Craig Latta <craig(a)netjam.org> wrote: > > > Does not render well on my iPad and has problems with multi touch. > > Hm, it should be ignoring multi-touch gestures. What happens? And > what rendering problems does it have? I haven't done any > browser-specific optimizations yet. > > > thanks! > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > >

Jan. 21, 2016

Re: [Pharo-dev] Pharo bootstrap

by Craig Latta

Hi Guille-- > The point is that âcleaning the imageâ is not reproducible. A cleanup > script may work with todayâs image but may not work with tomorrowâs. I consider this sort of cleaning something that gets done once per preexisting Smalltalk implementation (Pharo, VisualWorks, etc.). After it's done, I would build every release artifact up from the identified essentials (minimal object memory). You need a good module system for that, and I think one based on live remote messaging instead of source code stored in files would be best (easiest to build and use, and most accurate). With the knowledge of those essentials, I would create new Smalltalk implementations from a system tracer informed by them. Cleaning isn't something I would expect to do routinely as an app developer. It's primarily a research activity. > [Cleaning] does not scale when it starts to become circular. For > example, you want to refactor a part of morphic => but you are use > morphic while the refactor is performed. We do that all the time, but > at the cost of splitting and staging changes that require to be > atomic, which adds more complexity to the process. Of course, this is another argument for using remote tools. > ...I wrote a prototype of Espell that manipulated an image loaded in > the simulator. The result is that you had a high-level API provided > by mirrors to manipulate an image without requiring a VM change. I think that's definitely something you want to be able to do, since there are some changes that can only be made when time is stopped for the target image. And the simulator is simply the most pleasant tool for it. The implementation of this that I did was especially useful for making complimentary documentation, like the directed-graph movies at [1]. True, the simulator is slow, and making movie frames with it is glacial. :) We should never be afraid to change the virtual machine, though, in the absence of any other constraint. :) > A distributed object memory forces you to include in every peer that > may receive code a distribution layer (at least sockets, class > builder, compiler or serializer + dependencies). And we wanted to go > further. We wanted to be able to easily manipulate an image that does > not have those features. Right, I use the simulator stuff when I care about leaving those things out (e.g. [2]). But all of the systems I actually want to deploy do have those things, to the point that I do consider them to be as fundamental as anything else. And they don't include the class builder or compiler; the remote messaging protocol I wrote gets by with just sockets, a few collection classes, and the reflection primitives that the virtual machine needs anyway. There is never a need to compile source code. > The main point was to use the same infrastructure to build an image > in an explicit manner (the bootstrap) as well as in an implicit > on-demand manner (tornado). And I believe that the bootstrap is a > more transparent process where we can control what happens. It seems to me that push imprinting, where methods are transferred from one system to another as a side-effect of running them, is just as transparent and controllable, and gives you tools that you want anyway for other purposes. thanks, -C [1] http://netjam.org/context/viz [2] http://netjam.org/context/smallest -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Jan. 21, 2016