February 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] aboutToStyle:

by StÃ©phane Ducasse

Hi guys as part of a controlled experience I'm going over all the changes in MC done in squeak since pharo creation and I saw that Squeak has MCSnapshotBrowser>>aboutToStyle: aStyler | classDefinition shouldStyle | classSelection ifNil: [ ^false ]. self switchIsComment ifTrue: [ ^false ]. methodSelection ifNotNil: [ classDefinition := items detect: [:ea | ea isClassDefinition and: [ ea className = classSelection ] ] ifNone: [ (Smalltalk at: classSelection ifAbsent: [ Object ]) asClassDefinition ]. shouldStyle := true ] ifNil: [ classDefinition := nil. shouldStyle := categorySelection ~= self extensionsCategory ]. aStyler environment: self; classOrMetaClass: (classDefinition ifNotNil: [ SHMCClassDefinition classDefinition: classDefinition items: items meta: switch = #class ]). ^shouldStyle while Pharo not. Could you tell me if this would not be a good idea to integrate it in Pharo :). Stef

Feb. 11, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by Yanni Chiu

On 10/02/12 3:45 PM, StÃ©phane Ducasse wrote: > this is a good idea. Hmmm. I think the .zip file approach is the "correct/better" approach to take to my metadata problem. This discussion did turn up a feature of Fuel that was not obvious to me before - namely, that you can read/write multiple materializations on a single stream.

Feb. 11, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by Ben Coman

Norbert Hartl wrote: > Am 10.02.2012 um 19:51 schrieb Igor Stasenko: > > >> On 10 February 2012 19:27, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> But if you choose this route let me strongly suggest you use the zip file >>> format. Its very useful with Monticello mcz's to be able to pick them apart >>> using unzip. >>> >>> >> yes but then it makes the whole thing completely orthogonal to Fuel. >> because in zip you can have one file to hold serialized stuff, in >> another your metadata and whatsoever.. >> i mean, you can organize your data packaging yourself, without forcing >> fuel to support anything related to metadata. >> >> and i think this is right direction. >> >> So. I think it is useless to try extending fuel with metadata. if >> people want to have metadata, they should make it by own, >> in the way they see fit. >> I think fuel should do one thing : serialize/materialize stuff. Lets >> not turn it into "i can do everything to please you" library. >> >> > +1 > > Fuel does what it does. Having a fuel with metadata is just a customized format. In the end it is all streams. You can open a file read the metadata and then hand over the stream to fuel. I don't see any need to tweak fuel for that. Changing it to be able to read multiple roots sounds great but has the potential for e.g. doubling objects and all sorts (if I understand it correct). > > Norbert > > > > Using a standard container is better resuse and design - but maybe you still want to specify exactly the format of a file ending in "*.fuel". Is it _always_ a zip file or do you look for the zipfile magic number and if that is not there revert to it being a single fuel stream. cheers, -ben

Feb. 11, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Ben Coman

Schwab,Wilhelm K wrote: > Stef, > > I have an idea for something that might be simple enough to make the point. It is confusing though, especially that once an image goes bad, it stays bad, even though (AFAIK, I don't save it after the damage is done). For certainty, you could monitor file timestamps or in the extreme compare md5 checksums on the image at various points. Perhaps the first thing after unzippping a new image add 'self halt' at the top of SmalltalkImage>>snapshot:andQuit: This might help hunt down anything that is forcing an image save without your consent. cheers, -ben

Feb. 11, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by Norbert Hartl

Am 10.02.2012 um 19:51 schrieb Igor Stasenko: > On 10 February 2012 19:27, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> But if you choose this route let me strongly suggest you use the zip file >> format. Its very useful with Monticello mcz's to be able to pick them apart >> using unzip. >> > > yes but then it makes the whole thing completely orthogonal to Fuel. > because in zip you can have one file to hold serialized stuff, in > another your metadata and whatsoever.. > i mean, you can organize your data packaging yourself, without forcing > fuel to support anything related to metadata. > > and i think this is right direction. > > So. I think it is useless to try extending fuel with metadata. if > people want to have metadata, they should make it by own, > in the way they see fit. > I think fuel should do one thing : serialize/materialize stuff. Lets > not turn it into "i can do everything to please you" library. > +1 Fuel does what it does. Having a fuel with metadata is just a customized format. In the end it is all streams. You can open a file read the metadata and then hand over the stream to fuel. I don't see any need to tweak fuel for that. Changing it to be able to read multiple roots sounds great but has the potential for e.g. doubling objects and all sorts (if I understand it correct). Norbert

Feb. 11, 2012

[Pharo-project] Fwd: [Vm-dev] Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Subject: Re: [Vm-dev] Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt > Date: February 9, 2012 6:05:48 PM GMT+01:00 > To: lenglish5(a)cox.net, Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > > > On Thu, Feb 9, 2012 at 8:32 AM, Lawson English <lenglish5(a)cox.net> wrote: > > On 2/8/12 5:41 PM, Eliot Miranda wrote: >> >> >> >> >> this is well written, relatively short, and extremely informative. >> >> http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enou… >> >> thanks to Bob Westergaard for pointing it out to me. >> -- > > Eliot, do you have plans to recreate the functionality of RPython to auto-generate JITs for other languages? > > No. This article confirmed David Simmons' conclusions as to the potential performance of tracing JITs, i.e. that they produce excellent performance for micro-benchmarks but overall perform poorly. Here are some key quotes: > > "It's clear that, in general, an RPython VM won't reach the performance of something like HotSpot, which has several advantages: the overall better performance of method-based JITs; the fact that it's hand-coded for one specific class of languages; and the sheer amount of effort put into it. But I'd certainly expect RPython VMs to get to comfortably within an order of magnitude performance levels as HotSpot. Time will tell, and as people write RPython VMs for languages like Java, we'll have better points of comparison." > > "Tracing JITs are relatively new and have some limitations, at least based on what we currently know. Mozilla, for example, removed their tracing JIT a few months back, because while it's sometimes blazingly fast, it's sometimes rather slow. This is due to a tracing JIT optimising a single code-path at a time: if a guard fails, execution falls back to the (very slow) tracing interpreter for the remainder of that bytecode (which could be quite long), and then back to the language interpreter for subsequent bytecodes. Code which tends to take the same path time after time benefits hugely from tracing; code which tends to branch unpredictably can take considerable time to derive noticeable benefits from the JIT." > > My own preferred direction remains to add adaptive optimization to Cog, after improving the object representation. > > L. > > > > > -- > best, > Eliot >

Feb. 10, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by StÃ©phane Ducasse

> > Great. Maybe we should include #nextMaterializedRootFrom: to fuel. And I would love a chapter for our book :) But after mariano finished his phd draft :)

Feb. 10, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by StÃ©phane Ducasse

this is a good idea. On Feb 10, 2012, at 12:25 AM, Yanni Chiu wrote: > I'd like to store some metadata in a Fuel serialized file. I'd like to be able to read that metadata, without de-serializing the file. So, if there were a fixed header at the start of the file, with some "unused" fields, that would be ideal. > >

Feb. 10, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by StÃ©phane Ducasse

marcus may be we should integrate the rollback suggested by igor :) Now I go to bed because a doctor touches my vertebra and I need to lay down :). On Feb 10, 2012, at 9:38 PM, Marcus Denker wrote: > > On Feb 10, 2012, at 9:36 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> I am trying to simplify it :) You use a Mac, right? I'm using Linux, and the vm differences might be at play?? >> > How can we know if we can not reproduce the problem? > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >

Feb. 10, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by StÃ©phane Ducasse

On Feb 10, 2012, at 9:36 PM, Schwab,Wilhelm K wrote: > Stef, > > I am trying to simplify it :) tx > You use a Mac, right? I'm using Linux, and the vm differences might be at play?? May be. > > Thanks for understanding my motivations. I'll keep at it. It might also be interesting for me to try to orchestrate an attempt on a Windows vm. I don't care for Windows, but I have long respected Andreas' work on it vm. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Friday, February 10, 2012 3:26 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 1.4 - better from Jenkins > > bill > > can you build a reproducable situation? > Because we use daily packages with 1.4 > > In fact in often only develop in 1.4 and did not experience this problem. but it does not mean that we do not have problems :) > > Stef > > > On Feb 9, 2012, at 9:15 PM, Schwab,Wilhelm K wrote: > >> One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work. >> >> Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image?? >> >> One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas? >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of blake [dsblakewatson(a)gmail.com] >> Sent: Thursday, February 09, 2012 2:58 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] 1.4 - better from Jenkins >> >> I just downloaded the latest CogWin and Pharo 1.4 image and I got >> "WARNING: Manufactured file handle detected!" at the bottom, and popup >> full of startup errors. >> >> But! >> >> It's all actually very friendly! I can look through the errors and try >> to figure out what caused them. It's way cleaner than the old style >> mega-DNU-stacks. >> >> Nice work! >> >> On Thu, Feb 9, 2012 at 11:06 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one >>> directory, made a shell script to run the image using Cog, and all I can say >>> is "wow." >>> >>> The usability problems I was having are gone. In particular, the context >>> menus work. I loaded Migrate and set preferences, with a really nice >>> appearance resulting. >>> >>> One question: why did ClassDescription>>package go away? That seems to be a >>> really useful message. >>> >>> I'll try to build an image using the SqueakSource mirror. No promises, but >>> 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the >>> Pharo page old, or did somebody just do a lot of work to make things better? >>> >>> Bill >>> >>> >> >> > > >

Feb. 10, 2012