- Pharo-dev - lists.pharo.org

[Pharo-project] New step in Pharo modularity
by Mariano Martinez Peck April 5, 2010

April 5, 2010

Stef, please correct me if I wrote something incorrect :) Hi folks. It is since a couple of months that we have been discussing with Stef about the current Pharo architecture and the different kind of images we have. What we want to achieve, is to have a really small kernel and provide Metacello configurations so that people can easily load the rest of the stuff. Similar to what we are already doing with PharoCore and PharoDev. However, this still have limitations: 1) There are packages that should NOT be part of the core, but they are not also dev tools. For example, ObjectTracer, ObjectViewer, Morph examples, Sound, ImageSegment (?) etc. So...where do we put them ? 2) Most of the Pharo external packages that are loaded in a Dev image, are maintained by their own developers, not necessary "Pharo developers". So, we want to define "something" that Pharo developers should maintain, but that are not part of the core, neither a dev tool. For example, suppose that we want to remove some messages, classes or whatever, when we look senders or references, we should do it now not only in the core, but also in this new image. This is because now Pharo developers, will take care also about this. We don't have yet a clear name for this image. Do you have? We created a new repository called PharoNonCorePackages in squeaksource, and there we put all the packages that are part of this new concept. In addition, we created a Metacello configuration for that. With this, Pharo developers will be able to easily load that configuration in a PharoCore image. The name of such package is ConfigurationOfPharoCore, but I am not sure I like the name. Do you have a better one ? Of course, the Dev image will also have this configuration as reference, it means, the dev image will also have this stuff. We think this will let us have a smaller kernel, but still maintaining non core stuff in separate packages and easily loadable. It will also lower the "fear" when making a package external. The last thought was how we can integrate Metacello to manage updates in the system update. This is still green, but would be cool to a future. The idea is to migrate the ScriptLoader stuff, and instead, releasing metacello versions. Then, the system update should be just to load the last metacello version. So...what do you think ? Cheers

3 3

[Pharo-project] 11308 cleanup
by Pavel Krivanek April 5, 2010

April 5, 2010

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

2 1

[Pharo-project] Issue 2274: OBMClassQuery error key not found
by Stan Shepherd April 5, 2010

April 5, 2010

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.

4 4

[Pharo-project] about UIFeedback
by stephane ducasse April 5, 2010

April 5, 2010

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.

1 0

[Pharo-project] Fwd: [Fwd: binary removals of unbuildable packages in lucid]
by Serge Stinckwich April 5, 2010

April 5, 2010

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/

1 0

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...
by James Ladd April 4, 2010

April 4, 2010

> I do not know how related is it to your work, but I made some > experiment to translate Smalltalk into Java (http://www.squeaksource.com/Smalltalk2Java.html > ). > > Cheers, > Alexandre Its related and I will look into how I can use it. Of course, this is one those things I wish I knew about a while ago :) Rgs, James. _________________________________________________________________ Browse profiles for FREE! Meet local singles online. http://clk.atdmt.com/NMN/go/150855801/direct/01/

1 0

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...
by James Ladd April 4, 2010

April 4, 2010

Hi Pharo-ites, > Would it be sufficient to choose those classes that are also outlined in the ANSI standard? >>oh no. :) >>This is why you should study squeakOnJava, and other Smalltalk implementations. >>Take the squeak mini 2.2 image or littleSmalltalk (which run on java already and you will see what you need). I will look at the implementations you have suggested. Rgs, James. _________________________________________________________________ New, Used, Demo, Dealer or Private? Find it at CarPoint.com.au http://clk.atdmt.com/NMN/go/206222968/direct/01/

1 0

[Pharo-project] [ANN] Pharo-1.0-10517-rc4dev10.04.1 - Win32 Installer
by Torsten Bergmann April 4, 2010

April 4, 2010

The Win32 Installer for RC4 is available at [1]. As soon as beta testing is over we can change the link on the download page. Bye T. [1] https://gforge.inria.fr/frs/download.php/26783/setup_pharo1.0-10517-rc4dev1… -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

1 0

April 4, 2010

11306 ----- - Issue 2220: CombinedChar>>#add: - Issue 2273: RectangleExtent comment - Issue 2241: Character class>> euro 11307 ----- - Issue 2267: do:displayingProgress: enh - removing extra feedback from update utilities 11308 ----- - Issue 2258: Too many deprecation warnings. Thanks hernan stef and mariano (eating chocolates)

1 0

[Pharo-project] Dynamic content in inspector??
by Schwab,Wilhelm K April 4, 2010

April 4, 2010

Hello all, With the understanding that I am doing non-trivial FFI work and could have completely fried my image already, I'm wondering if this is a common Squeak/Pharo newbie kind of amazement: I create and inspect a new instance of something that has a #printOn: method, and the contents of the inspector's workspace change with time. I have seen inspectors update to track objects in the past, but this behavior is unwanted. I thought of finalization, but that appears not to be happening (nor should it be with the object inspected). I will keep looking, but plausible explanations will be appreciated. Bill

4 8