January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] pharogenesis

by Max Leske

I'm not quite sure I can follow you. Do you want to import the full repository into the image? Or would you want SystemDictionary to hold simply the version of every method that was active *before* the current version? The first case is a no go I think. The packed repository is 101 MB big and there are still 11000 object files in addition to the pack and index file. The second case would definitely speed up the look up process but on the other hand it doesn't solve the problem that you need another mechanism in the background (like a DB) to hold further versions. Was that even close to what you wanted? Max On 17.01.2011, at 10:25, Norbert Hartl wrote: > > On 16.01.2011, at 21:46, StÃ©phane Ducasse wrote: > >> I would love to have all these versions in a database and that we can query them :) >> > I thought the same. But then I didn't think about database. Wouldn't that be possible if the environment SystemDictionary is in full use? Would it be possible to import a version into a SystemDictionary that reflects one version and that is accesible through the class via class history?. Or is this a rather stupid idea? > > Norbert > >> On Jan 16, 2011, at 12:26 PM, Max Leske wrote: >> >>> Hi Geert >>> >>> Pharogenesis is my bachelors thesis and I'm still not finished writing it. I'll let you know when I'm finished. >>> >>> In short: I'm hosting a git repository on github that contains the information from the changes and sources files starting at Squeak version 1 up to Squeak 4.0 and Pharo 1.0. The idea is to have a single point of entry to that information so that one could for instance find out about every change to a method back to its creation. >>> >>> To accomplish this I built an implementation of git called GitFS that uses Filesystem (it's based on GitForSqueak by Tony Garnock-Jones). You can find everything on Squeaksource: http://squeaksource.com/@gUSXOmZmeac-jt63/3ejuPFSA >>> In that repo is also the code I use to generate the repository. >>> >>> Feel free to use the code and the repo but keep in mind that I'm still working on it. >>> >>> Max >>> >>> >>> >>> On 16.01.2011, at 11:38, Geert Claes wrote: >>> >>>> >>>> Hi Max, Can you tell us a little bit about pharogenesis? >>>> -- >>>> View this message in context: http://forum.world.st/pharogenesis-tp3219872p3219893.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>> >>> >> >> > >

Jan. 17, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Schwab,Wilhelm K

Two comments: (1) there needs to be a way to unregister interest; (2) the registrations need to be weak so that (1) is largely optional. If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Monday, January 17, 2011 1:18 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Unsubscribing for Announcements I really like Announcements! It's so much easier to update complex GUIs when you can pass state :) I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe). I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete. SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete. But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted? Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 17, 2011

Re: [Pharo-project] Issue 3542 in pharo: Add SmalltalkImage>>#gcBiasToGrow: and friends to core

by pharo＠googlecode.com

Comment #8 on issue 3542 by philippe...(a)gmail.com: Add SmalltalkImage>>#gcBiasToGrow: and friends to core http://code.google.com/p/pharo/issues/detail?id=3542 I created a Seaside issue for this: http://code.google.com/p/seaside/issues/detail?id=634 Does anybody know whether these settings are also valid for Cog?

Jan. 17, 2011

[Pharo-project] Xtreams-Xtras: hashing and HMAC

by mkobetic＠gmail.com

I started playing with FFI and got the hashing streams working. They require OpenSSL's libcrypto, which should be available on any reasonably recent Unix and OSX. The VW version also has interface to native Windows bcrypt.dll (available on Vista and later) but I haven't done that part yet. Anyway the hashing streams seem to work and performance isn't bad either. Hashing 100MB of ones [ (([ 1 ] reading limiting: 100000000) hashing: 'md5') -= 0; close; digest ] timeToRun takes little over 5 seconds on not particularly fast machine. The above expression runs about 2.5 times faster on VW on the same machine, but that's probably due to the time spent in the block based terminal. Profile on VW says that only about 15% of the time is spent in the hashing layer. Hashing the 21M pharo image is pretty much instant: ((FileDirectory default / 'pharo.image') reading hashing: 'md5') -= 0; close; digest The code is in Xtreams-Xtras and Xtreams-XtrasTests (note that you'll have to load FFI!). I tested it on Pharo 1.2 beta with both cog vm and standard vm. There are few test failures with file terminals that don't seem to like to be closed twice. Should be an easy fix. Enjoy, Martin P.S.: If any resident FFI experts find the time and interest to look over my C bindings and find something wrong, please let me know. In particular I have't quite figured out how to work with struct fields that contain arrays (e.g. 'unsigned char [128]'). I figured out that I can declare the actual size of the field as a third parameter in the #fields declaration, but the accessors generated for the field are not right. I suspect they need to be some form of ExternalData but I don't quite grok how that should be created (see e.g. HMAC_CTX>>key). Also it seems that there isn't a type definition for 'int' so I'm replacing all references to that with 'long'. Is that how it's done?

Jan. 17, 2011

Re: [Pharo-project] Issue 3542 in pharo: Add SmalltalkImage>>#gcBiasToGrow: and friends to core

by pharo＠googlecode.com

Updates: Status: Fixed Comment #7 on issue 3542 by stephane...(a)gmail.com: Add SmalltalkImage>>#gcBiasToGrow: and friends to core http://code.google.com/p/pharo/issues/detail?id=3542 (No comment was entered for this change.)

Jan. 17, 2011

Re: [Pharo-project] Pharo issues on Google

by Gary Chambers

Good hint, clearing my Chrome caches fixed it! Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, January 17, 2011 1:05 PM Subject: Re: [Pharo-project] Pharo issues on Google Me too I had to restart safari. Stef On Jan 17, 2011, at 12:20 PM, Gary Chambers wrote: > IFor that url I get: > > > Google Error > > Server Error > > The server encountered an error and could not complete your request. > If the problem persists, please report your problem and mention this error > message and the query that caused it. > > > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" > <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, January 15, 2011 8:02 AM > Subject: Re: [Pharo-project] Pharo issues on Google > > >> what do you mean >> not sending notification? >> not sending mails? >> >> I get the list >> http://code.google.com/p/pharo/issues/list >> >> Stef >> On Jan 14, 2011, at 6:15 PM, Gary Chambers wrote: >> >>> Is the Pharo issues google site not working? >>> >>> Regards, Gary >> > >

Jan. 17, 2011

Re: [Pharo-project] [squeak-dev] more Info in aboutSqueak

by Alexander LazareviÄ

2011/1/13 Enrico Spinielli <enrico.spinielli(a)googlemail.com> > H Alex, > great idea! > > As a side thought, couldn't it be a dialog with cut&past-able text? > I thought about that too, but now used a small ToolBuilder window instead. In the SystemReporter you can chose what system information should be gathered. So you could have a compact overview of the image and the VM or a full length/all details report. Add the repository SystemReporter to Monitcello. MCHttpRepository location: 'http://www.squeaksource.com/SystemReporter' user: '' password: '' Load the package SystemReporter and do SystemReporter open in a workspace. This very simple and needs to be polished further. License is MIT and everybody is invited to add code. It's easy to extend the reporter and it is explained in the class comment. This works with Squeak Trunk and Pharo 1.1.1 (needs to get rid of the deprecation warning) Alex

Jan. 17, 2011

Re: [Pharo-project] Issue 3542 in pharo: Add SmalltalkImage>>#gcBiasToGrow: and friends to core

by pharo＠googlecode.com

Comment #6 on issue 3542 by Torsten....(a)astares.de: Add SmalltalkImage>>#gcBiasToGrow: and friends to core http://code.google.com/p/pharo/issues/detail?id=3542 Opened a seaside issue here http://code.google.com/p/seaside/issues/detail?id=633

Jan. 17, 2011

Re: [Pharo-project] Issue 3542 in pharo: Add SmalltalkImage>>#gcBiasToGrow: and friends to core

by pharo＠googlecode.com

Comment #5 on issue 3542 by Torsten....(a)astares.de: Add SmalltalkImage>>#gcBiasToGrow: and friends to core http://code.google.com/p/pharo/issues/detail?id=3542 Here is the cs to remove initializeMemorySettingsProfileSeaside from core. Attachments: RemoveSeasideMemorySettings.1.cs 170 bytes

Jan. 17, 2011

Re: [Pharo-project] Was not able to update with #12304

by StÃ©phane Ducasse

Thanks torsten. Stef On Jan 17, 2011, at 1:21 PM, Torsten Bergmann wrote: > Looks like a Cog issue, I was able to reproduce it: > > When I download "PharoCore-1.2.zip" from > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/126/ > > (which is a Pharo 1.2 Core #12303 image) and I directly start the image > with the latest Win32 Cog VM from Eliot then I'm not able > to go through update #12304 via the update mechanism > as I already wrote in [1]. I get this error: > > => ClassBuilder(Object)>>doesNotUnderstand: #reshapeClass:toSuper: > > When I use the standard VM I'm able to update correctly > to the latest version pharo core 1.2 #12307 > > Maybe Eliot is able to reproduce and fix it. Until then I switch > to standard VM. > > Thx > Torsten > > > [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/039747.ht… > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

Jan. 17, 2011