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

Re: [Pharo-project] [COTDC] 37 - MCPatcher

by laurent laffont

PharoCore 1.3 from https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%20Core%201.3/ On Tue, Mar 29, 2011 at 6:02 AM, HwaJong Oh <daliot.oh(a)gmail.com> wrote: > what version of image are we doing COTDC? > i'm using 1.2. > > -- > View this message in context: > http://forum.world.st/COTDC-37-MCPatcher-tp3410269p3413687.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

March 29, 2011

Re: [Pharo-project] [COTDC] 37 - MCPatcher

by HwaJong Oh

what version of image are we doing COTDC? i'm using 1.2. -- View this message in context: http://forum.world.st/COTDC-37-MCPatcher-tp3410269p3413687.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 29, 2011

[Pharo-project] Issue 3901 in pharo: warning when updating from server

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3901 by vonbecm...(a)gmail.com: warning when updating from server http://code.google.com/p/pharo/issues/detail?id=3901 Pharo image: Pharo1.3a#13115 Virtual machine used: Squeak4.1 of 17 April 2010 [latest update: #9957] Platform Name: unix Class browser used (if applicable): Browser Steps to reproduce: - take unstable pharo core - World/System/Software Update actual results: see files attached. if you proceed then it continues to update from server and finish as expected. my concern is that it does not update automatically, it's interactive. is that ok? Attachments: PharoDebug.log 41.9 KB PharoScreenshot.1.png 96.4 KB

March 29, 2011

Re: [Pharo-project] [Seaside] rack/wsgi/ring for smalltalk

by Sean Allen

>> >> WAServerAdaptor isn't really much like ring, rack et al. > > Yes and no. It has the same responsibility in the "Seaside stack" but > is "object oriented" and not "string/byte array oriented" and more > high level. > >> But it does put the thought into my mind that it would be interesting >> down the road to >> try and take the Seaside infrastructure and work something like rack into it. > > > Well the "problem" is that "traditional" servers (Comanche, Swazoo, > OpenTalk) used to "object oriented" and fully featured web servers. > Since building something like that takes a lot of work more recent > servers (FastCGI, SCGI, AJP) are "string/byte array oriented". The > later ones are obviously easier to adapt to a ring/rack/wsgi style > interface. a bit of background from me could help here. i'm going to end up having redline smalltalk using either netty or jetty be the final target for my own personal use of this when i'm done so the 'string/byte oriented' is going to be important to me. i'm playing around with how restful resources using stored blocks would look and the final end result i would build on top of it is going to be a combination of some stuff i wrote earlier this year in smalltalk using pharo ( ported to redline ) and a later part that i had a much easier time expressing using clojure. thus the jvm is a big + for me, but in general as i'm one of the redline guys, it is probably going to be my primary platform sometime in the future ( although i still love pharo and gemstone which i've used for a few years now and plan to keep contributing to in whatever fashion i can. )

March 29, 2011

Re: [Pharo-project] Issue 2190 in pharo: at:put: return the argument

by pharo＠googlecode.com

Comment #6 on issue 2190 by nicolas....(a)gmail.com: at:put: return the argument http://code.google.com/p/pharo/issues/detail?id=2190 Note that bitAt:put: is ANSI, and that it won't modify the receiver but return a copy. We cannot change it, no way. I would say let's do it for #at:put: then discuss about the other ones in another issue if you want. I advocate consistency because of least surprising effect... The first time this was really usefull to me was for translating this DSL: d := a[i] := b[j] := c := 3; into: d := a at: i put: (b at: j put: (c := 3)). This also provides a Rationale for original st-80 design. Of course, you then have to explain #yourself to noobs with such implementation, but that's not that difficult to explain, and i find it worth.

March 28, 2011

[Pharo-project] Thanks for Pharo

by Scott Gibson

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 28, 2011

Re: [Pharo-project] Issue 3845 in pharo: Polymorph extension shortSummary is not programmed the object way

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3845 by nicolas....(a)gmail.com: Polymorph extension shortSummary is not programmed the object way http://code.google.com/p/pharo/issues/detail?id=3845 Name: SLICE-Issue-3845-Polymorph-Diff-Tool-shortSummary-fails-for-postscript-nice.1 Dependencies: Polymorph-Tools-Diff-nice.49 Implement #shortSummary in subclasses rather than using ifTrue:ifFalse: chains Reminder: these chains fail in case mcz includes a Postscript... While at it, also sort the changes in a patch morph class-name-wise (though this should be a different Issue, but everyone shall know how lazy I can be at this time of the night) Note that the implementation is different from PSMCMergeMorph>>#model: But MC+Polymorph together makes such a big number of classes that I won't try to be any clever and won't spend any time guessing a way to factor this code out.

March 28, 2011

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

by Toon Verwaest

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 ;) 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 28, 2011

[Pharo-project] Issue 3900 in pharo: FileDirectory>>withAllSubdirectoriesCollect:

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3900 by j...(a)rogerthedog.com: FileDirectory>>withAllSubdirectoriesCollect: http://code.google.com/p/pharo/issues/detail?id=3900 Pharo image: Pharo 1.1.1 (and checked in Pharo-core 1.2) Pharo core version: Pharo-1.1.1 #11414 Virtual machine used: <ex: pharo-vm-0.15.2f-linux> Class browser used (if applicable): SystemBrowser default Steps to reproduce: The withAllSubdirectoriesCollect: method returns an OrderedCollection of OrderedCollections of entries. That is, one OrderedCollection per subdirectory. To change it to return a single OrderedCollection of all entries from all subdirectories change the following line: From: result add: (aBlock value: dir). To: result addAll: (aBlock value: dir).

March 28, 2011

Re: [Pharo-project] String asUppercase/asLowercase

by Nicolas Cellier

OK good news, I just put a SLICE in inbox. Nicolas 2011/3/28 Denis Kudriashov <dionisiydk(a)gmail.com>: > yes. this fix is work (Unicode>>toLowercase:/toUppercase: works good for > russian strings) > > 2011/3/29 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> >> >> http://code.google.com/p/pharo/issues/detail?id=2703 >> Try squeak multilingual experimentations, I'm interested to ear if it >> would work for you >> (I'm unfortunately latin and need testing feedback from non latin users). >> >> Nicolas >> >> 2011/3/28 Denis Kudriashov <dionisiydk(a)gmail.com>: >> > Hello. >> > >> > asUppercase/asLowercase not work for non english strings (russian >> > strings). >> > >> > Is it bug? >> > How it can be implemeted? >> > >> > >

March 28, 2011