- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 657
by HernÃ¡n Morales Durand March 25, 2009

March 25, 2009

http://code.google.com/p/pharo/issues/detail?id=657

2 3

[Pharo-project] Another MIME-related problem
by Igor Stasenko March 25, 2009

March 25, 2009

Image is pharo-dev #10259 Try following: (Installer monticello http: 'http://scribo.aidaweb.si/repository') install: 'Scribo-np.172'. it says that 'unknown' mime type is invalid. I don't sure if it problem on a server side - Aida, or its because of changes to MIME.. Are 'unknown' mime type string is valid mime type? -- Best regards, Igor Stasenko AKA sig.

2 2

Re: [Pharo-project] Newbie Questions
by Keith Hodges March 25, 2009

March 25, 2009

Cross posted because I think others may find this discussion useful: Chris Muller wrote: > Hi Keith, I think the work you did on Level-Playing Field and MC 1.5 > has always sounded fantastic. > >> implemented it. Magma users use a variety of images and Magma needs you >> to have MCConfigurations working. Thats what LevelPlayingField in LPF >> gives you. >> > > So if it makes MC Configurations "work" why do *I* need to use it and > not just those wanting to load Magma via MC Configurations? > > You dont, but I kind of assume that you are a user too. >> Also the issue of extensions to classes that don't exist in older images >> is solved via the orphanage. MC1.5 doesnt complain like MC1 does. >> > > This is again something that happens for those *loading* Magma, so is > there a reason it is needed by the person doing the deployment? And, > if so, and I do, will others who want to load it require MC 1.5 and/or > LPF? > > The reason I have not moved on it after all this time, and I'm almost > ashamed to say it, it has never bubbled up into the realm of > critical-need that exceeded other priorities. Is LPF and MC 1.5 "drop > in and go?", completely compatible with existing mc packages? > > Thanks.. > Chris > It should be more so. The original MC1 made no effort to make anything compatible with anything else. It uses a simple binary storeOn: so save its binary data. This means that if you add an instance variable to any class in MC1's model, your packages are incompatible with past MC1's This is what happened, the MC in 3.9 added support for traits, and so packages saved, with that MC are incompatible with previous MC's. MC1.5 knows about this, and if a model class is realised with have extra data items, that it does not have inst vars for, it pops them into a properties dictionary. Also, MC1.5 makes an effort to only save the minimum amounts of instVars, so if your class does not have any Traits it saves, only the non-trait oriented inst-vars, and in doing so in theory the packages it generates should be compatible with even the older non 3.9 MC's. The original MC1 was very naive about handling errors. It would simply retry anything that raised an error. There were a number of situations that it did not handle well, such as renaming or re-ordering of inst vars. MC1.5 takes a much more considered approach. It attempts to actually make the class definition compatible with both the before and after situations, when loading methods. Obviously this is not always possible. In theory MC1.5 should handle more of the difficult cases, than MC1.0 did. However that doesn't stop people blaming MC1.5 if a package doesnt load, and they may find that the old MC1.0 can handle it using its old brute force approach. Finally MC1.6 with atomic loading is really cool, its over 3 times faster, which for something the size of Magma is a big deal. (However last time I tried it there was a minor bug) thanks for asking the relevant questions. Keith

1 0

[Pharo-project] New Pharo-dev AND web based on 10259
by Torsten Bergmann March 25, 2009

March 25, 2009

Damien Cassou wrote: ><serge.stinckwich at gmail.com> wrote: >> ScriptLoader loadSuperOB. does not work in this image. > >It does not surprise me because this script is not maintained. Try to >execute only the parts that make sense: OB*, AST, Shout, eCompletion >and the refactorings tools are already installed. Yes - it gives a #DNU for #longDescriptions after loading into the newest pharo image (#10259) But you can easily implement OBCodeTabPanel#longDescriptions like this: longDescriptions ^#() That should work for now... Bye Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

2 1

[Pharo-project] Font update at image startup as preference
by Torsten Bergmann March 25, 2009

March 25, 2009

fixed - see issue 689 (this time as a changeset for easier integration due to the massive unicode changes in the pharo inbox). -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

1 0

[Pharo-project] Using seaside.builder.st right from your image
by Torsten Bergmann March 25, 2009

March 25, 2009

Thanks to Lukas there is a new feature in the builder.seaside.st allowing you to directly load a builder configuration within the image itself. (see conversation below). Using the three URL parameters (distribution, packages and download) you can now write: (HTTPSocket httpGet: 'http://builder.seaside.st/?distribution=Seaside%202.9.0-alpha3&packages=all…') fileIn to load Seaside29alpha3 package right from the (pharo) image. Tip: If you need a different configuration, use builder.seaside.st and have a look at the comment in the generated load script. At the beginning you will find the specific URL with all your packages. That should make loading Seaside even easier and help to automate loading/integration tests. Keep on talking small Torsten -------- Original-Nachricht -------- Datum: Tue, 24 Mar 2009 17:08:46 +0100 Von: Lukas Renggli <YYY(a)ZZZ.com> An: Torsten Bergmann <YYY(a)ZZZ.de> Betreff: Re: Seaside Builder Installer script I've added two new features: - The parameter 'download' directly downloads the chosen definition. The value of the parameter is the label on the download link in the UI, including whitespace. Example: ?download=Load%20Script - The parameter 'package' also allows the value 'all' to automatically select all available packages. The latest deployment is based on Seaside 2.9a3 and noticeably faster (mainly because of the new JQuery libraries). Lukas On Tue, Mar 24, 2009 at 4:26 PM, Torsten Bergmann <YYY(a)ZZZ.de> wrote: > Very helpful, thanks! > > Bye > Torsten > > -------- Original-Nachricht -------- >> Datum: Tue, 24 Mar 2009 15:20:33 +0100 >> Von: Lukas Renggli <YYY(a)ZZZ.com> >> An: Torsten Bergmann <YYY(a)ZZZ.de> >> Betreff: Re: Seaside Builder Installer script > >> > But is it also possible to get the script using this parameter >> > convention? If so this would be helpful to directly >> > load a specific configuration right from the image: >> > >> > Â something in the like of: >> > >> > (HTTPDocument getURL: >> "http://builder.seaside.st/?distribution=allmyselectedSS29Packages?script=lo…) fileIn >> >> Yes, that would be easy to add. >> >> I need to do a new deployment on based on Seaside 2.9a3 anyway (it is >> still running on Seaside 2.9a2). I will add that ASAP. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch > > -- > Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal geschÃ¼tzt? > Jetzt absichern: https://homebanking.gmx.net/?mc=mail@footer.hb > -- Lukas Renggli http://www.lukas-renggli.ch -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

1 0

[Pharo-project] Seaside Builder Installer script
by Torsten Bergmann March 24, 2009

March 24, 2009

Hi Lukas, open builder.seaside.st and download an "Installer Script" from the advanced page. This is broken since Installer DNU #http: The generated pattern is (Installer http: 'someurl') install: 'somepackeg' but should be (Installer monticello http: 'someurl') install: 'somepackeg' This will work at least in latest Pharo. Maybe the builder could be extended to have a "Pharo" and a "Squeak" script option. Now the installer is always loaded from pbwiki at the beginning of the script. If in Pharo it would be better to use "ScriptLoader new installingInstaller" which downloads the Installer using Monicello and Squeaksource and allows to still have "Installer" as an MC package. Thx Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

2 1

[Pharo-project] New Pharo-dev AND web based on 10259
by Damien Cassou March 24, 2009

March 24, 2009

Here are pharo-dev and pharo-web based on latest 10259 before Closure: http://code.google.com/p/pharo/wiki/Downloads?tm=2 -- Damien Cassou http://damiencassou.seasidehosting.st

3 3

[Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)
by Michael van der Gulik March 24, 2009

March 24, 2009

On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <antony.blakey(a)gmail.com>wrote: > > On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote: > > > > > Smalltalk, the language rather than the implementation, already has > > fantastic support for concurrency. Smalltalkers just don't know how > > to use it. We don't need to rethink the model, we just need to learn > > to use what we have. > > Mutexes and semaphores are hardly 'fantastic'. The state of the art in > support for concurrency is way beyond what Smalltalk provides - > locking is both primitive and generally not scalable. > > Semaphores _are_ fantastic!! Lock-free algorithms are even cooler. The language lends itself to building up higher abstractions. Take for example Collection and all its subclasses; they're screaming out to have parallelised versions made: c := ConcurrentOrderedCollection new. c do: [ :each | ...this part gets executed in parallel...]. The caveat here is that you need to be careful about side-effects. This is just one example. I have some more rudimentary ideas at: http://gulik.pbwiki.com/Parallel+processing. Oh, and sorry to the Pharo guys for keeping this going. Let us know if you don't want threads like this on your list. Gulik. -- http://gulik.pbwiki.com/

6 6

[Pharo-project] tooltips for inspector 'mystery' buttons
by Dale Henrichs March 24, 2009

March 24, 2009

With 10259, there are tool tips for the 'mystery' buttons in the inspectors... If you have added a custom inspector method, you need to add #tooltip: to your pragama like the following for Object>>basicInspectorNodes: <inspector: #'1' priority: 600 toolTip: 'Basic elements'> Dale

2 1