- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 657

by Rob Rothwell

Worked great but the Ok button is gone now! Rob 2009/3/25 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > http://code.google.com/p/pharo/issues/detail?id=657 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 25, 2009

[Pharo-project] Issue 657

by HernÃ¡n Morales Durand

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

March 25, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?

by Michael van der Gulik

On 3/26/09, Markus Fritsche <fritsche.markus(a)gmx.net> wrote: > Igor Stasenko <siguctua(a)gmail.com> wrote: > >> | array sum1 sum2 | >> sum1 := 0. sum2 := 0. >> array := Array new: 10. >> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] >> fork. >> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] >> fork. >> 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ]. > > Something I came across leately: Threads are evil - > http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf They're not evil, just mischievous. I find it a fairly unimpressive article that recites what any decent programmer already knows about parallel programming. "This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash." heh. True. Gulik. -- http://gulik.pbwiki.com/

March 25, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?

by Markus Fritsche

Igor Stasenko <siguctua(a)gmail.com> wrote: > | array sum1 sum2 | > sum1 := 0. sum2 := 0. > array := Array new: 10. > [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. > [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. > 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ]. Something I came across leately: Threads are evil - http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

March 25, 2009

Re: [Pharo-project] Another MIME-related problem

by Igor Stasenko

2009/3/25 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: >> 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? > > AFAIK it is not a legal mime type, so it is a server side problem. It > should return a default mime type like application/octet-stream. > > Having said that, I've changed the code so it converts 'unkown' into > 'application/octet-stream'. Available in the inbox as > NONO! If MIME standard says its illegal - let it be illegal. I think this is fair to force devs to follow standards. What i can guess, that maybe there is no need to throw an error: i.e. if content-type is malformed, it can simply do: ^self main: mimeString sub: '' parameters: '' in #fromMIMEString: method. because i think nothing bad will happen later - if content type is unknown , then all applications who care about it will anyways be forced to use them as a simple octet stream. Monticello doesn't care about proper MIME type, and it can continue running without any problems (this is what i actually did - returned (self main: mimeString sub: '' parameters: '') using debugger to install the needed package despite the error with MIME). > Network-MIME-michael_rueger.8 > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 25, 2009

Re: [Pharo-project] Unicode merge

by Damien Cassou

On Wed, Mar 25, 2009 at 2:58 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > SLICE-UnicodeRwrite1-michael_rueger.1 (unchanged) > SLICE-UnicodeRewrite2-5.mcm (updated) Loading went fine but only '?' appear in the workspace when entering accented characters. Your one-click image worked fine. I launched the image with: squeak -encoding UTF-8 Pharo0.1Core-10259.image but only *after* having loaded your slices. I'm on Ubuntu Linux 8.10. -- Damien Cassou http://damiencassou.seasidehosting.st

March 25, 2009

Re: [Pharo-project] Another MIME-related problem

by Michael Rueger

Igor Stasenko wrote: > 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? AFAIK it is not a legal mime type, so it is a server side problem. It should return a default mime type like application/octet-stream. Having said that, I've changed the code so it converts 'unkown' into 'application/octet-stream'. Available in the inbox as Network-MIME-michael_rueger.8 Michael

March 25, 2009

Re: [Pharo-project] Unicode merge

by Michael Rueger

StÃ©phane Ducasse wrote: > Loaded without problems great :-) > shortcut error. debug? Please try again with these updated SLICEs SLICE-UnicodeRwrite1-michael_rueger.1 (unchanged) SLICE-UnicodeRewrite2-5.mcm (updated) Michael

March 25, 2009

Re: [Pharo-project] Newbie Questions

by Keith Hodges

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

March 25, 2009

Re: [Pharo-project] New Pharo-dev AND web based on 10259

by David RÃ¶thlisberger

Hi Torsten, > 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... yes, I did this change in my image in all OB packages, but forgot to commit it to OB-Mondrian-Diagrams, sorry. It's committed now. David

March 25, 2009