- Pharo-dev - lists.pharo.org

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

by Goubier Thierry

Le 27/06/2013 09:10, StÃ©phane Ducasse a Ã©crit : >> >> 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. > > I do not know. It's tempting because it seems to solve long running irritations I had with Smalltalk development (from many years ago); the need to keep the same image (saving and saving again) to maintain the development context, and being at the mercy of memory leaks, lack of stability, updates trashing my development image, etc :( With that kind of git support, I can change my workflow to: save frequently my packages, rm the image, package-cache and all the junk, and rebuilt everything from get.pharo.org and the git repos... Thanks to the pharo command line improvements as well :) Thierry -- 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] Versions Browser over gitfiletree://

by Goubier Thierry

Hi Dale, should I merge this work into the last pull request (#85) I made? I've corrected a few bugs and solved some performance issues, in addition to adding the API for querying and loading parts of a package. It's currently on a separate branch. Thierry Le 27/06/2013 01:26, Dale K. Henrichs a Ã©crit : > 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 > > -- 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] Versions Browser over gitfiletree://

by StÃ©phane Ducasse

> > 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. I do not know. Stef

June 27, 2013

Re: [Pharo-dev] Slide share

by StÃ©phane Ducasse

Ok so they try to influence the user by giving wrong information. I will continue to upload the slides then. Stef On Jun 27, 2013, at 8:58 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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] 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