- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Getting Pharo 1.2 on Hudson green/blue again

by StÃ©phane Ducasse

Thanks marcus. I will integrate some fixes after fixing some stuff with kids. Stef On Mar 29, 2011, at 8:31 PM, Marcus Denker wrote: > > On Mar 29, 2011, at 9:33 AM, Torsten Bergmann wrote: > >> Hi Markus, >> >> I think I've found out what the problem with the >> hudson build for Pharo 1.2 is: >> >> - the Pharo-1.2.st Skript used to build it includes this line: >> >> ((Smalltalk at: #ConfigurationOfPharo) project lastVersion) >> >> which now returns 1.3. instead of 1.2 since the config was extended. >> >> Guess who did it: ConfigurationOfPharo-MarcusDenker.148 >> on 22 March 2011, the day when the hudson build broke >> >> So change the line in Pharo-1.2.st to: >> >> ((Smalltalk at: #ConfigurationOfPharo) project version: '1.2-beta2') perform: #silently: with: true; perform: #load. >> >> and the build works. At least it does manually when I try it here. >> > Oh... > I fixed the build script. Hudson building now. > > >> If that works you either send me a beer or you take the time to >> exchange the VM to the customized ones I've sent you so we can >> move 1.2 out of the door and concentrate on 1.3... >> > I will do a release of 1.2.1 and then fix the one-click. > > Marcus > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

March 29, 2011

Re: [Pharo-project] who is using softSqueak and standard Squeak

by Helene Bilbo

"StÃ©phane Ducasseâ wrote: > > I would really like to remove the standard squeak because it is terrible. > I set it up since some updates and > I cannot work with it anymore. > No, it is not terrible. It is very beautiful, and much more useful and innovative than for example fake-windows or fake-macos themes. People like me who came to Pharo after you forked from Squeak have no idea of your quarrels with the Squeak-Community (i only read it afterwards in the mailing-lists) and have therefore no problem with using the best from every implementation (the beautiful theme from squeak and the random refactorings from pharo ;) And while i would have no problem with loading the theme by hand â if i would remove themes it would not be the squeak theme.. Have a look at: http://www.engadget.com/2011/01/17/princeton-study-shows-that-easy-fonts-ma… Princeton study shows that easy fonts make things harder to remember: "Fortune favors the bold (and the Italicized)" -- View this message in context: http://forum.world.st/who-is-using-softSqueak-and-standard-Squeak-tp3407241… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 29, 2011

Re: [Pharo-project] Getting Pharo 1.2 on Hudson green/blue again

by Marcus Denker

On Mar 29, 2011, at 9:33 AM, Torsten Bergmann wrote: > Hi Markus, > > I think I've found out what the problem with the > hudson build for Pharo 1.2 is: > > - the Pharo-1.2.st Skript used to build it includes this line: > > ((Smalltalk at: #ConfigurationOfPharo) project lastVersion) > > which now returns 1.3. instead of 1.2 since the config was extended. > > Guess who did it: ConfigurationOfPharo-MarcusDenker.148 > on 22 March 2011, the day when the hudson build broke > > So change the line in Pharo-1.2.st to: > > ((Smalltalk at: #ConfigurationOfPharo) project version: '1.2-beta2') perform: #silently: with: true; perform: #load. > > and the build works. At least it does manually when I try it here. > Oh... I fixed the build script. Hudson building now. > If that works you either send me a beer or you take the time to > exchange the VM to the customized ones I've sent you so we can > move 1.2 out of the door and concentrate on 1.3... > I will do a release of 1.2.1 and then fix the one-click. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 29, 2011

Re: [Pharo-project] Issue 3736 in pharo: new Transcript from CUIS

by pharo＠googlecode.com

Comment #4 on issue 3736 by stephane...(a)gmail.com: new Transcript from CUIS http://code.google.com/p/pharo/issues/detail?id=3736 Thanks a lot this is really nice!

March 29, 2011

Re: [Pharo-project] Can we get 1.2 on the pharo web site?

by Adrian Lienhard

Sure! I can help with updating the website. Is the list of changes [1] still work in progress or should I add as is? It would be nice to have it structured (I can do this) and a bit more detailed if possible. The site for the 1.1 release had a quite verbose summary [2]. Do we have the Pharo 1.2 and Pharo one click images ready already? Cheers, Adrian [1] http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo [2] http://www.pharo-project.org/pharo-download/release-1-1 On Mar 29, 2011, at 19:28 , StÃ©phane Ducasse wrote: > HI guys > > Would it be possible that we have Pharo 1.2 on the web site? > Marcus I can focus on 1.3. current fixes. > Stef >

March 29, 2011

Re: [Pharo-project] Thanks for Pharo

by StÃ©phane Ducasse

Thanks a lot scott and welcome. - sign the license :) - report bug - report successful stories :) - tell us what are also your needs. For us this is important that people can make money and create cool products/ideas with Pharo. Then we are currently reading: http://caml.inria.fr/consortium/index.en.html to get an example for a possible Pharo consortium. Our idea is to make sure that single people or really small entreprise can contribute. Stef > I just wanted to say thanks to everyone for all of the hard work that has been done for Pharo. Pharo 1.2 has come a long way and has been very enjoyable to use. > > Recently I had been given the opportunity to develop an application for a potential customer. I chose to use Pharo and Seaside and have been very happy with how well using Pharo 1.2 has been, with Cog even. > > I am very new to Smalltalk but I have been looking to help in any way (financially, documentation, etc.) that I can in order to help the progress of an open source Smalltalk, Pharo specifically. I am so new to Smalltalk that I feel I would be more of a hinderance than anything so I have not quite figured out how I could best help though I do hope to contribute in some way soon. > > > Thanks again! > Scott Gibson > >

March 29, 2011

[Pharo-project] Can we get 1.2 on the pharo web site?

by StÃ©phane Ducasse

HI guys Would it be possible that we have Pharo 1.2 on the web site? Marcus I can focus on 1.3. current fixes. Stef

March 29, 2011

Re: [Pharo-project] Opal decompiler: I've been a big good ... I've been a bit bad ...

by StÃ©phane Ducasse

On Mar 29, 2011, at 12:24 AM, Toon Verwaest wrote: > To keep you up to date... I've already implemented bytecode rewriting that inserts an error. > > Basically when you have something like > > instVarAt: 1 > > where 1 is now removed, this gets translated to: > > pushConstant: (RemovedField new name: #old name) > send: invalidRead > pop > pushConstant: nil > > and at:put: to > > pushConstant: (RemovedField new originalSlot: oldSlotObject) > send: invalidWrite > pop > > Then these messages will at runtime give you an error. Also since my MethodFieldUpdater sees these methods as it is rewriting it, it can collect them (doesn't do it yet though.. but that's 2 minutes of work) and present them to the user. > > Since we insert these magic constant object recompile time, the decompiler can find them again when recompiling for the next class update. When it finds them, it has all the meta-data it needs to figure out what slot access it was. Now that the method is being recompiled it can find out if there's a new slot that matches the old name; and put the corresponding field-access back into the method. > At the moment the compiler already finds the slot accesses but doesn't yet rewrite the IR back to a field-access. But that's semi-easy too. The IR just doesn't provide an API yet for finding objects around a certain IR node and removing them ... so I got bored :) > > So in short, we have all the infrastructure to provide good runtime errors, to collect methods at compiletime; and to reintroduce slots after they were previously removed and reattach the accesses properly. And it's all done outside of the decompiler using our classbuilder + classmodification + field modification + method & instance modification maps. > > And so yes, I also want to have proper meta-info everywhere; proper objects everywhere; so that we can build proper tooling to solve it. The new classbuilder is fully built around this idea. It builds up modification maps exactly so that it can find conflicts early, and present them to the developer for fixing; BEFORE applying the modification to the classes. > > Once this fully works I can post an image somewhere that can give you a sneak preview. At the moment it's still a bit intertwined with Helvetia for the slot-related experiment; but that we'll extract after the paper is written so that we can submit a clean model to Pharo, ... if Pharo cares ;) oh yes it does... we all want that :). First class slots is a dream. > > cheers, > Toon > > On 03/28/2011 09:20 PM, StÃ©phane Ducasse wrote: >>>> >>>> (Unless, of course you simply raise an error during (re)compilation >>>> when given ivar removed from class). >>> That's the plan yes. Niko is working on that part now. I guess for now we might keep it on Eliot's proposal of just transforming to an undefined field access; but we'll see. >>> One of the ideas is of course to collect the methods that get affected by a change and report back to the user; just like with all other types of errors that can occur during class modification. We have a pretty cool model already so it's becoming increasingly easy to install such hooks. I hate self error: 'your class is invalid because of something somewhere', and we'll get that all fixed! >> I would love to have real object that contains compilation error (instead of Transcript show:) so that we can build tool to fix them :) >> >>>> If you create a copy of method, copy the method's trailer. >>>> >>>> >>>> trailer := oldMethod trailer. >>>> >>>> newMethod := CompiledMethod newBytes: ... trailerBytes: ***trailer*** >>>> nArgs: ... nTemps: .. nStack: ... nLits: ... primitive: ... >>> It seems that the opal compiler has a compiledMethodWith: trailer. Useful ;) >>> I just had to set the methodClass: and selector: myself. Fair enough. >>> >>> @Eliot thanks for the hints. I'll take it into account to make the recompilation complete. If Niko doesn't finish it this evening I'll probably do it tomorrow... I'm in the need of a small break :) >>> >>> Ignoring the fact that it doesn't support removing instance variables yet, it would very well already. Pretty cool to see methods updated on bytecode level without slow recompilation. Aaah... rewriting the classbuilder is starting to pay off :) And then on to stateful traits. >>> >>> Just for credits: I'm working together with Camillo Bruni and Niko Schwarz on this. >>> >>> cheers, >>> Toon >>> >> > >

March 29, 2011

[Pharo-project] Issue 3909 in pharo: ObjectStringConverter refactored

by pharo＠googlecode.com

Status: FixProposed Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3909 by stephane...(a)gmail.com: ObjectStringConverter refactored http://code.google.com/p/pharo/issues/detail?id=3909 I've refactored the ObjectStringConverter support to be more flexible and provide feedback in the UI (via corner triangle). Also, should be no more MNU's in, for example, ColorSelectorDialogWindow when numeric fields are made empty! Note that any fields in use need to be recreated. A save of the image (or otherwise) is required to reinitialize the EditorFindReplaceDialogWindow singleton. Attachments: TextFieldRegex.3.cs 7.9 KB

March 29, 2011

Re: [Pharo-project] PharoCasts with experts

by StÃ©phane Ducasse

Igor I would love to have a way to connect to a bar code reader or webcam. Stef On Mar 29, 2011, at 6:57 PM, Igor Stasenko wrote: > On 29 March 2011 18:35, laurent laffont <laurent.laffont(a)gmail.com> wrote: >> On Tue, Mar 29, 2011 at 6:30 PM, Gary Chambers <gazzaguru2(a)btinternet.com> >> wrote: >>> >>> I expect it will be tricky to synchronise our schedules... >> >> Could you start by telling me when it's easy for you ? > > I am available :) > I just need some guidance from a guy from needs some specific functionality, > and i can implement that. > Because for me it is not really a problem to write binding to > anything.. the problem is to find real users for it :) > >> Laurent. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: laurent laffont >>> To: An open mailing list to discuss any topics related to an >>> open-sourceSmalltalk >>> Sent: Monday, March 28, 2011 8:03 AM >>> Subject: [Pharo-project] PharoCasts with experts >>> Hi, >>> Actually I'm training remotely a developer on Pharo using Skype and >>> TeamViewer. This guy records all sessions for its own purpose and I like the >>> idea. >>> For PharoCasts I would like to record 30mn to 1 hour sessions (as I know >>> you don't have time) with an expert who shows us real code, explaining a >>> framework / programming style / pattern while programming some examples (in >>> the spirit of PharoCasts, and may be >>> http://forum.world.st/Screencast-proposition-Watch-someone-read-code-td3244… >>> ). >>> Right now I'm thinking about: >>> - Mariano on DBXTalk >>> - Gary on Polymorph >>> - Igor on VM debugging or FFI / NativeBoost (for example interfacing >>> with http://id3lib.sourceforge.net/ or other lib) >>> - Lukas on Magritte or PetitParser >>> - Dale on Metacello >>> - Nicolas on Iliad >>> - Janko on Aida/Web >>> and all that I forgot ..... I'm sure plenty of people would like their >>> open-source project to be more known. This may be an opportunity. >>> >>> How to do this: contact me if you wish to do that so we can choose an hour >>> that match our respective calendars and agree on tools used (skype, google >>> video chat, vnc, teamviewer, ....) - I will care about video stuff. Just >>> talk and code :) >>> >>> Anyone ? >>> >>> Laurent Laffont - @lolgzs >>> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >>> Blog: http://magaloma.blogspot.com/ >>> Developer group: http://cara74.seasidehosting.st >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

March 29, 2011