June 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Goubier Thierry

Le 27/06/2013 08:48, StÃ©phane Ducasse a Ã©crit : > > >> Or ... A first step towards Pharo without a changeset. > > > without Monticello file back-end no? No, in fact it's very much dependent on Monticello filetree back end. This backend has the granularity which allow a use of git querying / fetching facilities to the level associated with changesets. I could implement a use of a gitfiletree:// repo as a complete replacement of a live changeset + monticello repository in one, if needed. Still wondering if this is the way to go. Thierry > Stef >> >> Thierry<Capture du 2013-06-26 23:14:08.png> > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2013

Re: [Pharo-dev] Slide share

by Marcus Denker

On Jun 26, 2013, at 9:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > http://www.slideshare.net/pharoproject/ > > Do you know if there are limits on the number of presentations that we can upload, because > I see (get public on this presentation => go pro). > So I wonder if I want to invest in slideshare. I think it is not limited for number of uploads. Just size of the file that is limited (to 100MB). More here: http://www.slideshare.net/business/premium/plans Marcus

June 27, 2013

Re: [Pharo-dev] Slide share

by Hilaire Fernandes

Le 26/06/2013 21:13, StÃ©phane Ducasse a Ã©crit : > Can you tell me if you can see the 2013 pharo conference? I can see 7 conferences and among them the 2013 pharo conference. Hilaire -- Dr. Geo http://drgeo.eu

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by StÃ©phane Ducasse

> Or ... A first step towards Pharo without a changeset. without Monticello file back-end no? Stef > > Thierry<Capture du 2013-06-26 23:14:08.png>

June 27, 2013

Re: [Pharo-dev] Boolean

by Marcus Denker

On Jun 27, 2013, at 8:16 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > In Pharo 3 we will support conditional optimized messages ( #ifTrue:, #ifFalse:, #ifTrue:ifFalse: and #ifFalse:ifTrue: ) sent on non boolean receiver. However, this feature will be slow, so one should not use it too much (as #become:, #isKindOf:, ...). Basically Opal compiles on the fly without optimizing it the conditional messageNode as a DoIt, run it, and jump in the context to the pc corresponding to the next ast node. We don't generate extra bytecode as you suggested, because it will grow the size of the image a lot and slow down the system with extra conditions. > It's actually not a lot of code. We need to debug/fix it for all the cases, though, this might add some more complexity: mustBeBooleanInMagic: context "Permits to redefine methods inlined by compiler. Take the ast node corresponding to the mustBeBoolean error, compile it on the fly with Opal and executes it as a DoIt. Then resume the execution of the context." | proceedValue sendNode selector expression arguments methodNode method offset position | context skipBackBeforeJump. sendNode := context sourceNode sourceNodeForPC: context pc. position := sendNode irInstruction bytecodeOffset. offset := sendNode irInstruction nextBytecodeOffsetAfterJump - position. expression := sendNode copy asSequenceNode transformLastToReturn. selector := #ExecuteUnOptimzedIn:. arguments := {(RBVariableNode named:'ThisContext')}. methodNode := RBMethodNode selector: selector arguments: arguments body: expression. context tempNames do: [:tempName | methodNode :=methodNode rewriteTempNamedWrite: tempName forContext: context. methodNode :=methodNode rewriteTempNamedRead: tempName forContext: context. ]. methodNode compilationContext: sendNode methodNode compilationContext. methodNode compilationContext class: UndefinedObject; compilerOptions: #(+ optIlineNone). method := methodNode generateWithSource. context jump: offset. proceedValue := self withArgs: {context} executeMethod: method. ^proceedValue

June 27, 2013

Re: [Pharo-dev] Boolean

by ClÃ©ment Bera

2013/6/27 Levente Uzonyi <leves(a)elte.hu> > On Wed, 26 Jun 2013, Guillermo Polito wrote: > > >> On Wed, Jun 26, 2013 at 11:20 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Wed, 26 Jun 2013, ClÃ©ment Bera wrote: >> >> Actually this code: >> True basicNew ifTrue: [ "some code" ] >> works fine on the latest Pharo 3 because of Opal :) >> >> >> So the Opal compiler lacks important optimizations. :) >> >> Actually Opal generates almost the same bytecode as the old compiler. As a proof, Benchmarks run at the same speed when compiled with one or the other compiler. So no lack of optimizations. Moreover Pharo and Squeak cannot be compiled without optimizing control flow structure or the compilation fails by image crash. This is due for example to the implementation of BlockClosure>>whileTrue: . > >> Not at all. In fact, the the code is optimized and falls back to the >> normal lookup in case of exceptional #mustBeBoolean, so the existing code >> keeps running the same speed ;) >> > > So it generates a bunch of extra bytecodes for every #ifTrue:, #ifFalse:, > #ifTrue:ifFalse: and #ifFalse:ifTrue: messages, in order to make this thing > work? Or is there a trick to avoid the duplicaiton of the code in the > blocks? > > I understood the problem. In Pharo 3 we will support conditional optimized messages ( #ifTrue:, #ifFalse:, #ifTrue:ifFalse: and #ifFalse:ifTrue: ) sent on non boolean receiver. However, this feature will be slow, so one should not use it too much (as #become:, #isKindOf:, ...). Basically Opal compiles on the fly without optimizing it the conditional messageNode as a DoIt, run it, and jump in the context to the pc corresponding to the next ast node. We don't generate extra bytecode as you suggested, because it will grow the size of the image a lot and slow down the system with extra conditions. Right now the feature is still under development and very buggy (it is just a prototype). It is activated only when Opal is set as default compiler, which is wrong, and there is a bug report. This bug report will be fixed during the sprint on Friday. So actually I didn't look carefully enough but: True basicNew ifTrue: [ "some code" ] works fine because it sends it to a NonBooleanReceiver but Pharo 3 supports #ifTrue: sent on a NonBooleanReceiver. However, what you can do in Pharo 3 / Opal if you know explicitly that you will send the optimized message to a NonBooleanReceiver, to avoid slowness due to on the fly do it compilation, you can specify it to the compiler in the class: MyClass class>>#compiler ^ super compiler options: #(- optInlineIf) or in the method : MyClass>>#foo <compilerOptions: #(- optInlineIf)> ^ #myNonBooleanObject ifTrue: [ 1 ] ifFalse: [ 0 ] There are different options like this one. I wrote them down here to remember (section compilerOptions): http://clementbera.wordpress.com/2013/05/28/modular-compilation-with-opal/ But it is not very nicely written, I've just write it to remember .. Compiler options as this one are not for daily use, there are here to enable some stuff like boolean proxies. > Levente > > > >> >> >> Levente >> >> >> But nice trick for the old compiler :) >> >> >> 2013/6/26 Nicolas Cellier <nicolas.cellier.aka.nice@** >> gmail.com <nicolas.cellier.aka.nice(a)gmail.com>> >> Because you don't know the tricks... This one should be >> just fine >> >> True basicNew ifTrue: [ "some code" ] yourself >> >> >> 2013/6/26 ClÃ©ment Bera <bera.clement(a)gmail.com> >> True basicNew ifTrue: [ "some code" ] >> >> hehe raises NonBooleanReceiver :) >> >> >> 2013/6/26 Camillo Bruni <camillobruni(a)gmail.com> >> why not, let's "forbid" them with an error message! >> >> => maybe you can and error to #become: on nil / true / >> false as well? >> >> On 2013-06-26, at 14:20, Torsten Bergmann < >> astares(a)gmx.de> wrote: >> >> > Boolean new -> error >> > Boolean basicNew -> is possible >> > >> > should we care? >> > >> >> >> >> >> -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

June 27, 2013

Re: [Pharo-dev] Boolean

by Levente Uzonyi

On Wed, 26 Jun 2013, Guillermo Polito wrote: > > On Wed, Jun 26, 2013 at 11:20 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 26 Jun 2013, ClÃ©ment Bera wrote: > > Actually this code:Â > True basicNew ifTrue: [ "some code" ] > works fine on the latest Pharo 3 because of Opal :) > > > So the Opal compiler lacks important optimizations. :) > > > Not at all. In fact, the the code is optimized and falls back to the normal lookup in case of exceptional #mustBeBoolean, so the existing code keeps running the same speed ;) So it generates a bunch of extra bytecodes for every #ifTrue:, #ifFalse:, #ifTrue:ifFalse: and #ifFalse:ifTrue: messages, in order to make this thing work? Or is there a trick to avoid the duplicaiton of the code in the blocks? Levente > Â > > > Levente > > > But nice trick for the old compiler :) > > > 2013/6/26 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Â Â Â Because you don't know the tricks... This one should be just fine > > Â Â Â True basicNew ifTrue: [ "some code" ] yourself > > > 2013/6/26 ClÃ©ment Bera <bera.clement(a)gmail.com> > Â Â Â True basicNew ifTrue: [ "some code" ] > > hehe raises NonBooleanReceiver :) > > > 2013/6/26 Camillo Bruni <camillobruni(a)gmail.com> > Â Â Â why not, let's "forbid" them with an error message! > > Â Â Â => maybe you can and error to #become: on nil / true / false as well? > > Â Â Â On 2013-06-26, at 14:20, Torsten Bergmann <astares(a)gmx.de> wrote: > > Â Â Â > Boolean new Â Â Â Â -> error > Â Â Â > Boolean basicNew Â -> is possible > Â Â Â > > Â Â Â > should we care? > Â Â Â > > > > > > > -- > ClÃ©ment BÃ©raMate Virtual Machine Engineer > BÃ¢timent B 40, avenue Halley 59650Â Villeneuve d'Ascq > > > > >

June 26, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Dale K. Henrichs

Cool! I plan to integrate your work soon and I expect to merge your work on the Pharo3.0 branch as well... Dale ----- Original Message ----- | From: "GOUBIER Thierry" <thierry.goubier(a)cea.fr> | To: "Pharo Development List â[pharo-dev@lists.pharo.org]â" <pharo-dev(a)lists.pharo.org> | Sent: Wednesday, June 26, 2013 2:28:55 PM | Subject: [Pharo-dev] Versions Browser over gitfiletree:// | | Or ... A first step towards Pharo without a changeset. | | Thierry

June 26, 2013

Re: [Pharo-dev] Metacello doubt

by Dale K. Henrichs

----- Original Message ----- | From: "Guido Chari" <charig(a)gmail.com> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Wednesday, June 26, 2013 2:49:09 PM | Subject: Re: [Pharo-dev] Metacello doubt | I understood. Thanks for the answer Dale. The drawback in this case | is to specify a particular dependency to AsmJit in my configuration. | Also, perhaps is the right way since i realized i have a particular | dependency on it. | But this discussion makes me thing a little and so i have a new | question. | Form what I (mis) undestand from Metacello, when asking for a | bleedingEdge version it loads only the baseline that specifies | packages and then last version of every package specified there. | As in the projects referenced on the baseline there is no need for | specifying a version, and that's the case of nativeBoost | configuration, wouldn't it be interesting to have some behavior (i | mean i new method for loading like loadDeepSymbolic:) that not only | load the symbolicVersion of the package asked, but also propagate | that symbolicVersion (bleedingEdge in this case) to all the | dependencies that don't specify a concrete version? | Guido. Guido, With the Metacello Scripting API[1] I've taken a slightly different tack, but I think that it gets you to the same place. I am a big fan of deterministic loads, but I know that from a practical point of view developers need to have a certain amount of control over exactly what gets loaded into their DEVELOPMENT environments and they need to be able to exert this control without having to resort to editing configurations to match their specific requirements. I have accomplished this by arranging for a Notification to be signalled whenever a project is referenced during a load. The developer can use one or more of the onUpgrade:, onDowngrade: and onConflict: clauses in their load scripts to exert fine control over what happens on a project by project basis ... For your specific use case, I would think that you would want to use the `lock` command[2] and specify that you want to `lock` the projects (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if I've got test cases for symbolic versions, but if you are seriously interested in taking the Scripting API for a spin, I'd be willing to write some additional tests using the #bleedingEdge symbolic version (if not already covered) and validate this use case... I am entering a phase where I will be doing some work on getting FileTree and Metacello up to snuff for Pharo3.0 so this would be a good time for me to add some test cases in anticipation of having some interested users ... I haven't released the Scripting API, because I need to have real users with real use cases take the API for a spin and validate the API. The Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I think the Scripting API is (or will be) available in Pharo3.0. I'm looking forward to getting feedback as to how the API stands up to real use ... So let me know if you are interested in being another Scripting API guinea pig:) Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse…

June 26, 2013

Re: [Pharo-dev] Better Interruption in 2.0

by Stephan Eggermont

Using Henry's processToInterrupt "Look for best candidate to interrupt: - any scheduled non-finalization process of lower priority - the weak-finalization process, if scheduled - the UI process Never interrupt the idle process, since killing it is fatal" | fallback | fallback := UIManager default uiProcess. Processor scanSchedule: [:p | "suspendedContext sender == nil usually means that process is only scheduled but had no chance to run" ((p ~~ Processor backgroundProcess) and: [ p suspendedContext sender notNil]) ifTrue: [ p ~~ WeakArray runningFinalizationProcess ifTrue: [^p] ifFalse: [fallback := p]] ] startingAt: Processor activePriority. ^fallback in todays Moose 4.8 (on Pharo 20608) on the april 10 VM allows for better interruption, up to the point where the system runs out of memory without a lowspace warning after I assume trying to collect garbage for 20 minutes or so. Stephan

June 26, 2013