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

Re: [Pharo-project] recompiling class

by Marcus Denker

On Jun 11, 2012, at 7:17 AM, S Krish wrote: > "decompile to an Intermediate Representation" > > This will be nice to have backported if possible to 1.4. > IR: you can do it. Whole compiler: no way, as it changes APIs and honestly, life is too short. Marcus -- Marcus Denker -- http://marcusdenker.de

June 11, 2012

Re: [Pharo-project] recompiling class

by Marcus Denker

On Jun 9, 2012, at 8:16 PM, Eliot Miranda wrote: > > For the backend of Opal, I did some crude benchmark for Martin this week: > Decompiling to IR and re-generating of all methods in Morph that access iVars takes 0.8 seconds... > > and how long does recompiling all Morph methods take? > on the same machine: 6.5 seconds. But of course that can be cut down by selecting for ivar access (to around half). More statistics: Bytecode to IR for the whole image: 4.5 seconds. BC->IR-BC: 12.7 seconds. (no install) Opal image (~57000 CompiledMethods) Not installing the methods yet... and of course nothing is profiled and optimized yet. > Marcus, I'm eager to port your code to Squeak. Would that be OK? > Yes! The first version will be (I think) portable. But future versions might use Pharo features. Compatibility is not the main goal. The whole point about improving the system is to then use the improvements. Else what's the point in improving anything? Marcus -- Marcus Denker -- http://marcusdenker.de

June 11, 2012

Re: [Pharo-project] zip bug [IMPORTANT] probably related to the recent Zip changes

by Ben Coman

Sean P. DeNigris wrote: > Sean P. DeNigris wrote > >> Where did you click on it? I need steps to reproduce... >> >> > > Okay, I tried to merge it and got the error when the package was being > read... > > I did some experiments... > * create a zip at Mac command line -> new Pharo code correctly parses > date/times > * unzip Balloon-CamilloBruni.85.mcz at Mac command line -> Mac reports > date/time as 1/23/2010... I'm assuming this is wrong because pre-fix, Pharo > reported 29 September 2011 > > So, I think the code is correct, but transitioning is a problem... let me > see write up a fallback defaulting to the old date format for invalid > dates... > > -- > View this message in context: http://forum.world.st/zip-bug-IMPORTANT-probably-related-to-the-recent-Zip-… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > What do you get if you unzip it outside Pharo? from the operating system?

June 11, 2012

Re: [Pharo-project] recompiling class

by S Krish

"decompile to an Intermediate Representation" This will be nice to have backported if possible to 1.4. On Sat, Jun 9, 2012 at 5:40 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jun 9, 2012, at 8:26 AM, S Krish wrote: > > > > > > > Can we do this in Pharo: > > > > "in Java, the computation of numeric o ffsets for instance elds in > memory is done by > > the run-time system. This permits updating a class with new instance > elds or methods without > > aff ecting existing code. In other words, it is possible to run an > existing bytecode fi le for a subclass > > after updating and recompiling the class, but without recompiling the > subclass." > > Hello, > > In Smalltalk, not only *new* instances get the changed > class layout, but *all* existing ones are migrated. > > There is always just one version of a class in the system, all instances > are of that version. > > Thus, if you add a instvar in a superclass, the iVar offsets of the > subclasses have to be > fixed. Right now this is done by recompiling the all subclasses, but you > could be much > more intelligent: filter for those methods that actually reference ivars > and then don't recompile > but just change the offset. > > This "just" is more difficult than it seems: changing an offset can mean > that the bytecode > needed is larger (2 instead of 1), and that then means jump offsets need > to be changed. > Which in turn can mean that the larger jump needs more bytecode, too.. > > So in practice, the best is to decompile to an Intermediate Representation > that is at the > level of bytecode, yet abtracts away jumps and the decision of which > bytecode exactly it used. > > For the backend of Opal, I did some crude benchmark for Martin this week: > Decompiling to IR and re-generating of all methods in Morph that access > iVars takes 0.8 seconds... > > We will add the IR backend to 2.0 soon and the new ClassBuilder will use > it. > > But in general, it would be nice to late-bind the offsets and just use > names in the representation > that a method is saved in. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > >

June 11, 2012

[Pharo-project] [CTI-KH] News

by Santiago Bragagnolo

Hi all! Here are the week news from TypeInference project :) Enjoy the week! . http://concretetypeinference.blogspot.com.ar/2012/06/news-cti.html Whats new in ConcreteTypeInference http://concretetypeinference.blogspot.com.ar/2012/06/news-kh.html Whats new in KwisatzHaderach http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… Little explanation of type in our context. http://concretetypeinference.blogspot.com.ar/2012/06/kwisatz-haderach-about… Graph building 'concepts exposition

June 11, 2012

Re: [Pharo-project] FilePlugin changed it's behavior?

by Sean P. DeNigris

Guillermo Polito wrote > > Has this behavior changed lately? > There's something weird and scary going on with FilePlugin... * Issue 6050: ensureDirectory looks strange http://code.google.com/p/pharo/issues/detail?id=6050 * http://forum.world.st/FilePlugin-bug-td4634074.html Anyone else notice anything? - S -- View this message in context: http://forum.world.st/FilePlugin-changed-it-s-behavior-tp4633565p4634255.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 11, 2012

Re: [Pharo-project] zip bug [IMPORTANT] probably related to the recent Zip changes

by Sean P. DeNigris

Okay, here is an issue: Issue 6054: Error when reading zip files with Squeak date/time format http://code.google.com/p/pharo/issues/detail?id=6054 with a fix attached and a comment pointing back here: > Attached are two cs files that have a temporary fix enabling us to load > mcz and other zip files, even if they have the old, incorrect date format. > They should be refactored and there is a larger question to discuss [1], > but they work under manual testing. > > The new behavior when reading zip file timestamps is: > * parse as a DOS timestamp > * if an error is encountered, fall back and treat it like a Squeak (i.e. > incorrect) DOS timestamp. This may return an incorrect result, but will > not cause an error > > The changes were tested by hand on Balloon-CamilloBruni.85.mcz, which > Steph was having a problem with because there was 13 as a month index, > which blew up [1] > The larger issue I was thinking about is: should we extend this fallback to all DOS timestamp parsing, but now that I think about it: * I imagine there's not much of that going on besides zipping, lol * I think it'd be better to signal an InvalidDosTimestamp, describing the change, and pointing users to how to convert their data, instead of silently trying to convert What do you think? Cheers, Sean -- View this message in context: http://forum.world.st/zip-bug-IMPORTANT-probably-related-to-the-recent-Zip-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 11, 2012

Re: [Pharo-project] zip bug [IMPORTANT] probably related to the recent Zip changes

by Sean P. DeNigris

Sean P. DeNigris wrote > > let me see write up a fallback defaulting to the old date format for > invalid dates... > Damn!! I'm screwed because the bug we found yesterday in #ensureDirectory (in the VM I think) makes all my tests fail, so I'm refactoring blind!! -- View this message in context: http://forum.world.st/zip-bug-IMPORTANT-probably-related-to-the-recent-Zip-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 11, 2012

Re: [Pharo-project] zip bug [IMPORTANT] probably related to the recent Zip changes

by Sean P. DeNigris

Sean P. DeNigris wrote > > Where did you click on it? I need steps to reproduce... > Okay, I tried to merge it and got the error when the package was being read... I did some experiments... * create a zip at Mac command line -> new Pharo code correctly parses date/times * unzip Balloon-CamilloBruni.85.mcz at Mac command line -> Mac reports date/time as 1/23/2010... I'm assuming this is wrong because pre-fix, Pharo reported 29 September 2011 So, I think the code is correct, but transitioning is a problem... let me see write up a fallback defaulting to the old date format for invalid dates... -- View this message in context: http://forum.world.st/zip-bug-IMPORTANT-probably-related-to-the-recent-Zip-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 11, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Yanni Chiu

On 10/06/12 6:16 PM, Cam S wrote: > Unfortunately, Fuel does not work in this Pier based image, so I still > have the situation where different images allow me to do different > combinations, but not one that allows me to operate my application > completely. (Maybe if i put my head in the sand the problems will go > away... ?) I've never had a problem with Fuel in a Pier image. What problem are you having? (It helps if you are specific in your post; otherwise, people have to ask.) What Pier one-click image did you use (link please)? Was it Magritte2 or Magritte3? How did you load Fuel? Did you use ConfigurationOf? Did you specify #stable or #bleedingEdge?

June 11, 2012