April 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] CollabActive book :)

by Serge Stinckwich

Great idea ! But what will be the relationship between this book and "Pharo by Example" ? Not the same material ? Regards, On Sat, Apr 3, 2010 at 6:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi Pharoers > > We put in place (big big thanks doru, anton, lukas and gemstone for that) a pier book > Â Â Â Â http://book.pharo-project.org/ > > The idea is that we can collect/edit.... information about pharo on this collaborative book. > Now we would like that **you**/**us** control the quality of the contents. Â The book will be open: > **you**= anybody from the pharo community can be editor (you should ask probably doru because I have to > really make sure that I do not mess it up) but not everybody can change text, everybody will be able to add notes > following the http://book.seaside.st principle. > As an editor you can register to the rss stream and includes the comments. > > Now the idea is that after a while the ready to get publish parts may be used for Pharo by example 2 since we > can generate automatically latex from the web. > > Now I would love to have chapter on > Â Â Â Â - how to compile my vm on Mac OSX > Â Â Â Â - how to compile my vm on linux > Â Â Â Â - how to compile my vm on Windows > Â Â Â Â - Understanding Announcement > Â Â Â Â - Settings > Â Â Â Â - Building UI with Polymorph.... > Â Â Â Â - Help > Â Â Â Â - ... > > So if you want to be an editor you are more than welcome! > Just ask > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 5, 2010

Re: [Pharo-project] CollabActive book :)

by Tudor Girba

Hi, You can subscribe to the Diffs RSS here: http://book.pharo-project.org/book/?view=PBDiffRssView I also added it in the header. Cheers, Doru On 4 Apr 2010, at 21:17, StÃ©phane Ducasse wrote: > Hi doru > > I looked for the rss feed but I could not find. May be I missed the > obvious? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "When people care, great things can happen."

April 5, 2010

[Pharo-project] about UIFeedback

by stephane ducasse

Hi I have the impression that it would be good that we have a way to specify that either a UI feedback should be standalone or that it can be standalone if not invoked when another ui feedback tasks place (in such a case it can be part of the previous line. I was trying to reduce the stack of progressbar we have during the update Utilities creates one for number of CS. (I removed it in 11306 as an experiment) NewChangeSetfromStream create the empty one Then MC Then HTTP protocol So what would be nice is a way to control that without having to know the context is which a feedback is sent. Does any of you have an idea: because I'm not satisfied with the removal in the Utilities for CS Right now ProgressNotification signal: '' extra: val makes sure that the feedback is made as show below with defaultMorphicAction ProgressInitiationException>>defaultMorphicAction | result progress | progress := SystemProgressMorph label: progressTitle min: minVal max: maxVal. [[result := workBlock value: progress] on: ProgressNotification do: [:ex| ex extraParam isString ifTrue: [SystemProgressMorph uniqueInstance labelAt: progress put: ex extraParam]. ex resume]] ensure: [SystemProgressMorph close: progress]. self resume: result We can use sendNotificaton to change that ProgressInitiationException>>sendNotificationsTo: aNewBlock self resume: ( workBlock value: [ :barVal | aNewBlock value: minVal value: maxVal value: barVal]) But 'Loading....' displayProgressAt: Sensor cursorPoint from: 0 to: self size during: [:bar | ..... Create a ProgressInitiationException... displayProgressAt: aPoint from: minVal to: maxVal during: workBlock "Display this string as a caption over a progress bar while workBlock is evaluated. EXAMPLE (Select next 6 lines and Do It) 'Now here''s some Real Progress' displayProgressAt: Sensor cursorPoint from: 0 to: 10 during: [:bar | 1 to: 10 do: [:x | bar value: x. (Delay forMilliseconds: 500) wait]]. HOW IT WORKS (Try this in any other language :-) Since your code (the last 2 lines in the above example) is in a block, this method gets control to display its heading before, and clean up the screen after, its execution. The key, though, is that the block is supplied with an argument, named 'bar' in the example, which will update the bar image every it is sent the message value: x, where x is in the from:to: range." ^ProgressInitiationException display: self at: aPoint from: minVal to: maxVal during: workBlock So is it me or the design above (which I like) is not smart enough so that we do not have to consider to change a display:....during into a ProgressNotification signal: '' extra: val to be sure that we do not stack progress bar.

April 5, 2010

[Pharo-project] A small idea how to get closer to hardware with small efforts :)

by Igor Stasenko

Hello again, it is about running a native code , stored in compiled methods. All we need is: a) allow code execution for object memory. On most platforms this is trivial - just pass additional flags to virtual memory allocation functions. b) add a single primitive 'call a native code' c) use a special compiled method trailer, which will store the native code inside itself Then we could place any native code inside a compiled method and use a single primitive to run this code. This is quite simple thing, given that both pharo and squeak adopted method trailers, so a primitive, before running the code, needs few checks: - a method's trailer format is valid (we could reserve a terminal byte value for that) - a native code, placed inside a method trailer is targeted for same platform as currently running on if not, then primitive will simply fail, and interpreter will run the method's bytecode, which , depending on a situation, can check if it can recompile the code (if platform doesn't match) or use a workaround. The only limitation of such approach, that native code, placed in compiled method should be relocate-agnostic, i.e. never use absolute jumps, only relative ones and so on. Also, we could force, that code using a specific calling convention, so it will be easy to fetch values from stack and other useful stuff from interpreter/object memory (like passing an interpreterProxy pointer). This could be a good answer in generating a trampoline code for FFI/Alien on the fly. What you think? -- Best regards, Igor Stasenko AKA sig.

April 5, 2010

[Pharo-project] 11308 cleanup

by Pavel Krivanek

Hi, two classes are not removed properly. This code removes obsolete classes: DataStream initialize. "clean obsolete KedamaFloatArray". Class removeSubclass: (SystemNavigation default obsoleteClasses detect: [:class | class name = 'AnObsoleteObjectTracer']) class. -- Pavel

April 5, 2010

Re: [Pharo-project] Sugar Theme

by Hilaire Fernandes

David T. Lewis a Ã©crit : > On Sat, Apr 03, 2010 at 11:13:25AM +0200, Michael Rueger wrote: >> On 4/3/2010 11:09 AM, St?phane Ducasse wrote: >> >>> did you check on the etoy image? I imgaine that they have their own >>> repository? Sye >> AFAIK they don't use Monticello... > > MCHttpRepository > location: 'http://source.squeak.org/etoys' > user: '' > password: '' Thanks for the reminder. Yeah, Karl is doing great. Damn, I should have remember about this effort of the Etoys folks to modualarize Etoys as I am this group as well. Hilaire

April 5, 2010

[Pharo-project] Fwd: [Fwd: binary removals of unbuildable packages in lucid]

by Serge Stinckwich

Hi all, i follow-up a message concerning the possible removal of Squeak vm from the next Ubuntu version (Lucid) because there is some build problems. If someone could look at these building problems. Best regards, ------------ Dear developers, At UDS in Dallas, it was proposed that we run a round of removals of those binary packages in universe and multiverse from sources that fail to build in lucid, so that we would enter the LTS release clean and no users would wind up installing binary packages that it would be impossible for us to provide security support for. Â https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-supportable… After some discussion on ubuntu-devel[1], this has now been done. Â Attached is the list of packages that were candidates for removal. Â Some of these may already have been fixed by uploads correcting the build failures, but if you see a package here that you care about having available in Lucid, I recommend that you check on it and take care of any remaining build failures. Â The archive admins will happily help any of these packages back through the NEW queue that manage to get building again. And if you don't get the package building again before release but a fix comes along post-release, these packages are also candidates for the SRU process[2]. Cheers, -- Steve Langasek Â Â Â Â Â Â Â Â Â Give me a lever long enough and a Free OS Debian Developer Â Â Â Â Â Â Â Â Â to set it on, and I can move the world. Ubuntu Developer Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.debian.org/ slangasek(a)ubuntu.com Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â vorlon(a)debian.org [1] https://lists.ubuntu.com/archives/ubuntu-devel/2010-March/030509.html [2] https://wiki.ubuntu.com/StableReleaseUpdates#When -- ubuntu-devel-announce mailing list ubuntu-devel-announce(a)lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 5, 2010

Re: [Pharo-project] Problem loading Exupery on PharoCore 1.0

by Javier PimÃ¡s

maybe you could try separating with spaces the elements of the array, I think I had a similar problem once, don't know if it is the case: #( (block 1 (mov (literalVariableAddress 10) t1) ) ) Regards, Javier. On Sun, Apr 4, 2010 at 9:49 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Maybe a non-visible character? > > Cheers, > Alexandre > > > On 4 Apr 2010, at 04:32, laurent laffont wrote: > > I do: >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfMondrian'; >> load.. >> >> ConfigurationOfMondrian project latestVersion load. >> >> Then >> >> Gofer new >> squeaksource: 'Exupery'; >> package: 'Exupery'; >> load. >> >> ==> Syntax Error >> >> testLiteralVariableAddress >> source := MedMethod >> createIntermediate: >> #((block 1 >> (mov(literalVariableAddress 10) t1) )Nothing more expected ->) >> for: machine. >> mockEmitter expectEmission: >> #( (block1 >> (mov #(#emitFetchAddress 1 >> #(#simplifiedLiteralAddress 10)) t1)) >> (block2) ). >> >> self simplifyFullyMocked. >> >> self verify. >> mockEmitter verify. >> >> >> Laurent Laffont >> >> >> On Sun, Apr 4, 2010 at 10:26 AM, laurent laffont < >> laurent.laffont(a)gmail.com> wrote: >> OK Thanks. I will try. Would be cool to have a ConfigurationOfExupery :). >> >> Laurent Laffont >> >> >> On Sun, Apr 4, 2010 at 10:19 AM, Tudor Girba <tudor.girba(a)gmail.com> >> wrote: >> Hi Laurent, >> >> Something is wrong. MOAbstractLayout and MOGraphVizLayout come from >> Mondrian. Were these by mistake somehow added as dependencies to Exupery? >> Doru >> >> >> >> On 4 Apr 2010, at 10:06, laurent laffont wrote: >> >> Hi, >> >> I want to try to build Exupery VM. On PharoCore 1.0 I do: >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfVMMaker'; >> load. >> >> (ConfigurationOfVMMaker project version: '1.2') load. >> >> Then >> >> Gofer new >> squeaksource: 'Exupery'; >> package: 'Exupery'; >> load. >> >> I have this error: >> >> This package depends on the following classes: >> MOAbstractLayout >> You must resolve these dependencies before you will be able to load these >> definitions: >> MOGraphVizLayout >> MOGraphVizLayout>>doExecute: >> MOGraphVizLayout>>findTopLeftCorner: >> >> >> I suppose I need GraphViz package >> >> Gofer new >> squeaksource: 'GraphViz'; >> package: 'GraphViz'; >> load. >> >> But when I load it I have a Syntax Error: >> >> runWithSystemFramework: string >> <> expected ->apicall: short 'system' (char*) module: >> 'System.framework'> >> >> ^ self externalCallFailed >> >> Laurent Laffont >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "It's not how it is, it is how we see it." >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier PimÃ¡s Ciudad de Buenos Aires

April 5, 2010

Re: [Pharo-project] Sugar Theme

by David T. Lewis

On Sat, Apr 03, 2010 at 11:13:25AM +0200, Michael Rueger wrote: > On 4/3/2010 11:09 AM, St?phane Ducasse wrote: > > >did you check on the etoy image? I imgaine that they have their own > >repository? Sye > > AFAIK they don't use Monticello... MCHttpRepository location: 'http://source.squeak.org/etoys' user: '' password: ''

April 5, 2010

Re: [Pharo-project] Issue 2274: OBMClassQuery error key not found

by Lukas Renggli

I can reproduce the problem, but I do not see any attachement. Or did you commit your change somewhere? Lukas On 4 April 2010 21:49, Stan Shepherd <stan.shepherd414(a)gmail.com> wrote: > > VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: > #10074] > Image: Pharo-1.0-10517-rc4 [Latest update: #10517] > > > in Omnibrowser, search for MCIni . This tries to browse the class MCIni, > rather than MCInitializeTest, throwing error. > > walkback and fix attached to issue. > -- > View this message in context: http://n4.nabble.com/Issue-2274-OBMClassQuery-error-key-not-found-tp1751098… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

April 4, 2010