- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: [Pharo-fuel] Two nice things I did in 2 hours with Fuel

by Igor Stasenko

I'm not impressed! :) (well done). Your posts are good that they can easily serve as a guide howto install-setup-and use stuff. Next experiment for you: mix Fuel with Magma (we should get some napalm) :) On 17 August 2011 00:14, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Well. I don't have a lot of time right now...but between writing things down > for myself or making a post there is not that difference. So...here is a > post about the Riak integration with Fuel: > > http://marianopeck.wordpress.com/2011/08/16/when-fuel-meets-riak-nosql-data… > > On Tue, Aug 16, 2011 at 9:37 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> This clearly opens the door to really amazing experiment. >> Stef >> >> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >> Date: August 16, 2011 8:58:03 PM GMT+02:00 >> To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >> Subject: [Pharo-fuel] Two nice things I did in 2 hours with Fuel >> Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >> >> 1) serialize a living debugger, materialize it in another image and >> continue debugging. >> 2) use Fuel to serialize a graph to a bytearray and then store and >> retrieve that from the Riak NoSQL database :) >> >> coooool! >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko AKA sig.

Aug. 17, 2011

[Pharo-project] new Cog VMs available

by Eliot Miranda

in http://www.mirandabanda.org/files/Cog/VM/VM.r2487/. Fix bugs described in the "[Pharo-project] Troubles with #flushCache and #run:with:in:" thread http://lists.gforge.inria.fr/pipermail/pharo-project/ 2011-July/050858.html. The PIC machinery wrongly treated invoke-as-method sends as MNUs. Closely related, finally fully implement PIC MNU cacheing where, by calling a special abort, a PIC is able to record that a gven selector is an MNU for a particular class. Speeds up a simple MNU benchmark by 33% (with more performance the deeper the receiver's cass hierarchy is). On Mac fix mis-editing of Info.plist to insert revision info so that VM .app once again starts on 10.5.x. -- best, Eliot

Aug. 17, 2011

[Pharo-project] Jenkis notification when Squeaksource is down [WAS] Re: [Pharo-fuel] Build failed in Jenkins: Fuel #112

by Mariano Martinez Peck

Marcus, is there a way to catch the errors when SqueakSource is down so that to avoid "false alarms" ? Thanks! On Wed, Aug 17, 2011 at 12:38 AM, <marcus.denker(a)inria.fr> wrote: > See <http://ci.lille.inria.fr/pharo/job/Fuel/112/> > > ------------------------------------------ > [...truncated 798 lines...] > (t4 value: t1) > ifTrue: [t3 value: t1]] in CommandLine > class(AbstractUserInput class)>>dispatch: > [:t2 | t1 value: t2 value] in Dictionary>>valuesDo: > [:t2 | t2 > ifNotNil: [t1 value: t2]] in Dictionary>>associationsDo: > Array(SequenceableCollection)>>do: > Dictionary>>associationsDo: > Dictionary>>valuesDo: > Dictionary>>do: > CommandLine class(AbstractUserInput class)>>dispatch: > [self dispatch: singleton] in CommandLine class>>dispatch > BlockClosure>>cull: > [:t2 | t2 cull: t1] in SmalltalkImage>>executeDeferredStartupActions: > OrderedCollection>>do: > SmalltalkImage>>executeDeferredStartupActions: > SmalltalkImage>>snapshot:andQuit: > WorldState class>>saveAndQuit > [| t3 | > (t3 := selector numArgs) = 0 > ifTrue: [target perform: selector] > ifFalse: [t3 = arguments size > ifTrue: [target perform: selector > withArguments: arguments] > ifFalse: [target > perform: selector > withArguments: (arguments > copyWith: t1)]]. > self changed] in > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > BlockClosure>>ensure: > CursorWithMask(Cursor)>>showWhile: > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: > MouseButtonEvent>>sentTo: > ToggleMenuItemMorph(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > ToggleMenuItemMorph(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > MenuMorph(Morph)>>processEvent:using: > MenuMorph(Morph)>>processEvent: > MenuMorph>>handleFocusEvent: > [ActiveHand := self. > ActiveEvent := t1. > t5 := t2 > handleFocusEvent: (t1 > transformedBy: (t2 > transformedFrom: self))] in HandMorph>>sendFocusEvent:to:clear: > [t1 value] in PasteUpMorph>>becomeActiveDuring: > BlockClosure>>on:do: > PasteUpMorph>>becomeActiveDuring: > HandMorph>>sendFocusEvent:to:clear: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendMouseEvent: > HandMorph>>handleEvent: > HandMorph>>processEvents > [:t2 | > ActiveHand := t2. > t2 processEvents. > ActiveHand := nil] in WorldState>>doOneCycleNowFor: > Array(SequenceableCollection)>>do: > WorldState>>handsDo: > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > PasteUpMorph>>doOneCycle > [[World doOneCycle. > Processor yield. > false] whileFalse. > nil] in Project class>>spawnNewProcess > [self value. > Processor terminateActive] in BlockClosure>>newProcess > ------------------------------------------------------------ > > Processes and their stacks: > Process: a Process in nil > stack: > > Array(SequenceableCollection)>>do: > [:logger | > logger nextPutAll: 'Processes and their stacks: '; > cr. > Process allInstances > do: [:each | > | ctx | > logger nextPutAll: 'Process: '; > print: each; > cr; > nextPutAll: ' stack:'; > cr; > cr. > ctx := each isActiveProcess > ifTrue: [thisContext sender] > ifFalse: [each > suspendedContext]. > ctx > ifNotNil: [(ctx stackOfSize: 20) > do: [:s | logger print: s; > cr]]. > logger nextPutAll: '------------------------------'; > cr; > cr]] in [Smalltalk logError: aString > inContext: aContext. > Smalltalk > logDuring: [:logger | > logger nextPutAll: 'Processes and their stacks: '; > cr. > Process allInstances > do: [:each | > | ctx | > logger nextPutAll: 'Process: '; > print: each; > cr; > nextPutAll: ' stack:'; > cr; > cr. > ctx := each isActiveProcess > ifTrue: > [thisContext sender] > ifFalse: > [each suspendedContext]. > ctx > ifNotNil: [(ctx stackOfSize: > 20) > do: [:s | > logger print: s; > > cr]]. > logger nextPutAll: > '------------------------------'; > cr; > cr]]] in > NonInteractiveUIManager>>quitFrom:withMessage: > [logStream := self openLog. > aMonadicBlock value: logStream] in SmalltalkImage>>logDuring: > BlockClosure>>ensure: > SmalltalkImage>>logDuring: > [Smalltalk logError: aString inContext: aContext. > Smalltalk > logDuring: [:logger | > logger nextPutAll: 'Processes and their stacks: '; > cr. > Process allInstances > do: [:each | > | ctx | > logger nextPutAll: 'Process: '; > print: each; > cr; > nextPutAll: ' stack:'; > cr; > cr. > ctx := each isActiveProcess > ifTrue: > [thisContext sender] > ifFalse: > [each suspendedContext]. > ctx > ifNotNil: [(ctx stackOfSize: > 20) > do: [:s | > logger print: s; > > cr]]. > logger nextPutAll: > '------------------------------'; > cr; > cr]]] in > NonInteractiveUIManager>>quitFrom:withMessage: > BlockClosure>>ensure: > NonInteractiveUIManager>>quitFrom:withMessage: > NonInteractiveUIManager>>unhandledErrorDefaultAction: > UnhandledError>>defaultAction > UndefinedObject>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > UnhandledError(Exception)>>signal > UnhandledError class>>signalForException: > GoferRepositoryError(Error)>>defaultAction > ------------------------------ > > Process: a Process in [self value. > Processor terminateActive] in BlockClosure>>newProcess > stack: > > [self value. > Processor terminateActive] in BlockClosure>>newProcess > ------------------------------ > > Process: a Process in [self value. > Processor terminateActive] in BlockClosure>>newProcess > stack: > > [self value. > Processor terminateActive] in BlockClosure>>newProcess > ------------------------------ > > Process: a Process in [self value. > Processor terminateActive] in BlockClosure>>newProcess > stack: > > [self value. > Processor terminateActive] in BlockClosure>>newProcess > ------------------------------ > > Process: a Process in [self value. > Processor terminateActive] in BlockClosure>>newProcess > stack: > > [self value. > Processor terminateActive] in BlockClosure>>newProcess > ------------------------------ > > Process: a Process in Delay class>>handleTimerEvent > stack: > > Delay class>>handleTimerEvent > Delay class>>runTimerEventLoop > [self runTimerEventLoop] in Delay class>>startTimerEventLoop > [self value. > Processor terminateActive] in BlockClosure>>newProcess > ------------------------------ > > Process: a Process in SmalltalkImage>>lowSpaceWatcher > stack: > > SmalltalkImage>>lowSpaceWatcher > [self lowSpaceWatcher] in SmalltalkImage>>installLowSpaceWatcher > [self value. > Processor terminateActive] in BlockClosure>>newProcess > ------------------------------ > > Process: a Process in ProcessorScheduler class>>idleProcess > stack: > > ProcessorScheduler class>>idleProcess > [self idleProcess] in ProcessorScheduler class>>startUp > [self value. > Processor terminateActive] in BlockClosure>>newProcess > ------------------------------ > > Process: a Process in [delaySemaphore wait] in Delay>>wait > stack: > > [delaySemaphore wait] in Delay>>wait > BlockClosure>>ifCurtailed: > Delay>>wait > InputEventPollingFetcher>>waitForInput > InputEventPollingFetcher(InputEventFetcher)>>eventLoop > [self eventLoop] in > InputEventPollingFetcher(InputEventFetcher)>>installEventLoop > [self value. > Processor terminateActive] in BlockClosure>>newProcess > ------------------------------ > > Process: a Process in WeakArray class>>finalizationProcess > stack: > > WeakArray class>>finalizationProcess > [self finalizationProcess] in WeakArray class>>restartFinalizationProcess > [self value. > Processor terminateActive] in BlockClosure>>newProcess > ------------------------------ > > Enregistrement des r?sultats des tests > Archiving artifacts > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > -- Mariano http://marianopeck.wordpress.com

Aug. 16, 2011

Re: [Pharo-project] Fwd: [Pharo-fuel] Two nice things I did in 2 hours with Fuel

by GermÃ¡n Arduino

Thanks by share! and yes, very interesting experiments! 2011/8/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Well. I don't have a lot of time right now...but between writing things down > for myself or making a post there is not that difference. So...here is a > post about the Riak integration with Fuel: > > http://marianopeck.wordpress.com/2011/08/16/when-fuel-meets-riak-nosql-data… > > On Tue, Aug 16, 2011 at 9:37 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> This clearly opens the door to really amazing experiment. >> Stef >> >> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >> Date: August 16, 2011 8:58:03 PM GMT+02:00 >> To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >> Subject: [Pharo-fuel] Two nice things I did in 2 hours with Fuel >> Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >> >> 1) serialize a living debugger, materialize it in another image and >> continue debugging. >> 2) use Fuel to serialize a graph to a bytearray and then store and >> retrieve that from the Riak NoSQL database :) >> >> coooool! >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Aug. 16, 2011

Re: [Pharo-project] squeaksource is down

by GermÃ¡n Arduino

2011/8/16 Torsten Bergmann <astares(a)gmx.de>: > ... again > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > yep...... :(

Aug. 16, 2011

Re: [Pharo-project] Fwd: [Pharo-fuel] Two nice things I did in 2 hours with Fuel

by Mariano Martinez Peck

Well. I don't have a lot of time right now...but between writing things down for myself or making a post there is not that difference. So...here is a post about the Riak integration with Fuel: http://marianopeck.wordpress.com/2011/08/16/when-fuel-meets-riak-nosql-data… On Tue, Aug 16, 2011 at 9:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > This clearly opens the door to really amazing experiment. > > Stef > > *From: *Mariano Martinez Peck <marianopeck(a)gmail.com> > *Date: *August 16, 2011 8:58:03 PM GMT+02:00 > *To: *The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > *Subject: **[Pharo-fuel] Two nice things I did in 2 hours with Fuel* > *Reply-To: *The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > > 1) serialize a living debugger, materialize it in another image and > continue debugging. > 2) use Fuel to serialize a graph to a bytearray and then store and retrieve > that from the Riak NoSQL database :) > > coooool! > > -- > Mariano > http://marianopeck.wordpress.com > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > -- Mariano http://marianopeck.wordpress.com

Aug. 16, 2011

Re: [Pharo-project] seaside #stable on pharo.13?

by Dale Henrichs

Doru, The 'Base' group defines the minimal set of packages for Seaside (it does not include OB)... The only thing that you need in addition to 'Base' is to decide which of the Adaptors you want to use and you can have a perfectly functioning Seaside. If you are suggesting that the 'default' to not include the OB tools, that's fine with me, but in past discussions the decision was reached to include OB tools in the 'default' group. The rationale has always been (i believe) that the naive users need to have the Seaside control panel (which is based on OB) in order to easily start and stop Seaside ... The sophisticated and knowledgeable users can start with the 'Base' group and add exactly the packages that they are interested in ... Perhaps we need to have one more group that loads everything but the OB tools and leave the default group alone? If you are sophisticated enough to know you don't want OB, then you can load that group... Dale ----- Original Message ----- | From: "Philippe Marschall" <kustos(a)gmx.net> | To: pharo-project(a)lists.gforge.inria.fr | Cc: seaside(a)lists.squeakfoundation.org | Sent: Tuesday, August 16, 2011 12:34:29 PM | Subject: Re: [Pharo-project] seaside #stable on pharo.13? | | On 16.08.2011 12:23, Marcus Denker wrote: | > | > On Aug 16, 2011, at 12:18 PM, Tudor Girba wrote: | > | >> Hi, | >> | >> The ConfiguraitonOfSeaside does not define any #stable version for | >> Pharo 1.3. | >> | >> Is it intentional or is it simply because the configuration is not | >> up to date? | > | > | > The configuration is not up to date... would be nice to fix it. And | > it would be good | > to have a version that loads a minimal seaside (no OB, which I | > think this does). | | That should actually work. You just need to define what you mean with | minimal (probably Seaside-Component and Seaside-Canvas and probably | Seaside-Flow as well). | | As long as you stay away from Seaside-Tools-OmniBrowser it shouldn't | load OB. | | Cheers | Philippe | | | |

Aug. 16, 2011

[Pharo-project] squeaksource is down

by Torsten Bergmann

... again -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Aug. 16, 2011

Re: [Pharo-project] [Seaside] seaside #stable on pharo.13?

by Dale Henrichs

Aug. 16, 2011

Re: [Pharo-project] Building vs. Stone carving (was: some explanations about what we are doing :)

by StÃ©phane Ducasse

I agree with what igor said. Now give us or join to build one of these items - a fast way to load package (fuel but there is still some work) - a spec for managing packages (metacello) - a set of tests (we have some but we need more) - a bootstrap (with have a mini image so this could be ok). and we will build and not carve and we will maintain a full set of packages. So we are getting there but this is not good to not test/use all day long what we release. So this will be like that for a moment but our goal is what I mention above: rebuilding from scratch all the pieces all the time and fast and we will get there. Stef On Aug 16, 2011, at 8:21 PM, Torsten Bergmann wrote: > Stef/Mariano wrote: >>> So now we are including several packages in the image so that we do not have two images. >>> >>> I am not against this, but I think it is a must to provide a #shrinkToPharoCore and a hudson associated to that. >> >> yes good idea > > Interesting (nearly silent) switch in the way we build Pharo(core). > > > With one "Core" and several distro packages like "pharo-dev", "seaside" > we once switched to the model anyone is used to in other technology sectors: > building a house or a machine by stacking up/assembling small pieces. > So we had a "start with a base/core and load what you need" model > similar to Linux kernel and distros. So you could pick up what you need. > > I thought this is the right model - since we can cleanly load > and keep images small while checking if something is running > after loading with CI/Hudson. > > But now we extract the kernel/core from the (bloated?) distro. > > For whatever reason I often see this tradition of "Stone carving" in > Smalltalk. One has a large image and strips it down for deployment > (throw out what you do not need). Often you get problems in unloading/ > clean loading again. Classes are referenced across the image without > checking the load order, ... > > > Mmmmhhh ... who shares the same feeling that this is not a good idea! > When there is a #shrinkToPharoCore then there is a pharo core image > anyway - so we always have two images. And we have to test it and > check if packages load cleanly anyway (using CI). > > Can you at least ellaborate what led to this step? Is PharoKernel > the new Pharo Core? Will we test reloading after shrinking? ... > > Thx > T. > > > > > > > > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

Aug. 16, 2011