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

Re: [Pharo-project] [MethodTrailer] #getSourceCodeBySelector: and #getSourceCodeByIdentifier: are not implemented

by Igor Stasenko

For #getSourceCodeByIdentifier: the idea was to introduce a source manager, which could manage source code by using some arbitrary IDs. Then you can store source code in database or on web.. depending how source manager is implemented. And for getSourceCodeBySelector: i did a trick to actually answer the source modified by comment (if method is originally comes from trait) so for example when method belongs to trait, then you will see something like: "This method implemented in TMyTrait" fooo ^ self then you will think twice before modifying such methods, because if you do that, you will replace it in class where you doing, but maybe you should do it in trait. But this change were not integrated. On 12 May 2011 16:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > I vote for removing any dead code. Less code, less bugs. Less code, easier to understand. > > On May 12, 2011, at 3:45 PM, Mariano Martinez Peck wrote: > >> If we see CompiledMethodTrailer >> sourceCode >> Â Â "Answer the source code of compiled method. >> Â Â Note: it does not attempts to read from source files using sourcePointer, >> Â Â nor reconstruct the source code using temp names" >> >> Â Â (kind == #EmbeddedSourceQCompress or: [ kind == #EmbeddedSourceZip ]) ifTrue: [ >> Â Â Â Â ^ data ]. >> >> Â Â kind == #SourceBySelector ifTrue: [ >> Â Â Â Â ^ method methodClass getSourceCodeBySelector: method selector ]. >> >> Â Â kind == #SourceByStringIdentifier ifTrue: [ >> Â Â Â Â ^ method methodClass getSourceCodeByIdentifier: data ]. >> >> Â Â ^ nil >> >> >> But neither #getSourceCodeBySelector: nor #getSourceCodeByIdentifier: Â are implemented. In fact, it is easy to modify their test and make them red. Change #testSourceBySelectorEncoding or #testSourceByIdentifierEncoding and add a send to #sourceCode. Example: >> >> testSourceBySelectorEncoding >> >> Â Â | trailer | >> >> Â Â trailer := CompiledMethodTrailer new. >> >> Â Â trailer setSourceBySelector. >> >> Â Â self assert: (trailer kind == #SourceBySelector ). >> Â Â self assert: (trailer size = 1). >> Â Â trailer sourceCode. >> >> >> >> So...I don't know why they are not implemented, but if this was work "unfinished", we should at least make that clear and not to appear that it is supported but at the end it is not. So, if that's the case, I suggest to put nice comments explaining that and in addition implement: >> >> Behavior >> getSourceCodeBySelector: >> ^ self notYetImplemented >> >> >> Behavior >> getSourceCodeByIdentifier: >> ^ self notYetImplemented >> >> >> What do you think ? >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Best regards, Igor Stasenko AKA sig.

May 12, 2011

Re: [Pharo-project] SSL/HTTPS -SecureSocketStream/SSLSessionforPharo/Squeak and otherSmalltalk implementations

by Sven Van Caekenberghe

On 12 May 2011, at 17:58, Rob Withers wrote: > Sure. I cannot recall if I offered a stream interface or not. > I could add one and we could treat this and the SqueakSSL stream as provider impl to a wrapper stream. The code that I am working on has a good [Secure]SocketStream implementation, it depends on a Socket like object, and on an SSLSession, which currently is the plugin. I imagine that it could also be your code. > I'll comment more as I dig into it. I think I will fork a PharoSSL project, since I know of at least one change in there. If I understood correctly, you need all of Cryptography, right ? So would it not make more sense to (if necessary), start or add a Cryptography-Pharo ? I mean, your code is much more than SSL. Sven

May 12, 2011

Re: [Pharo-project] [squeak-dev] [ANN] VB-Regex patch available

by Miguel CobÃ¡

Lukas Renggli maintained the VB-Regex on Pharo. He tried IIRC to get Vassily to accept some patches but it appears that he didn't get any response from him. Lukas will be interested in these patches for sure. Regards El jue, 12-05-2011 a las 16:28 +0200, Nicolas Cellier escribiÃ³: > Reinout Heek recently published a patch in cincom store for some Regex > pending bugs after a recent mail on vwnc list. > I ported this 3-methods patch on Squeak based on latest > http://www.squeaksource.com/Regex.htm > I have no commit right, so I posted two copies: > > http://source.squeak.org/inbox/VB-Regex-nice.18.mcz > http://www.squeaksource.com/PharoInbox/VB-Regex-nice.18.mcz > > Note that core Pharo version of Regex is some versions ahead and the > patch requires further porting. > > Nicolas > > > ------------------------------------------------------------------------- > Port fixes from Reinout Heek from VW.Regex11 > > Regex11(1.3.1-soops1) - introduces fix > Regex11(1.3.3) - merge above with 1.3.2 > > Blessing comment: > > Fixed RxmBranch to do greedy matching instead of first match passes. > This entailed adding a collection copy to #currentState, so I > expect this to slow down Regex11 a bit (not measured yet). > > This fixes a bug found a Soops: > '.*(ABCD|BC)' asRegex matches: 'fooABCD' > and Mantis bug 5391: > '15' matchesRegex: '[1-9]|1[0-9]' > > See http://bugs.squeak.org/view.php?id=5391 > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

May 12, 2011

Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

by Miguel CobÃ¡

El jue, 12-05-2011 a las 16:53 +0200, Sven Van Caekenberghe escribiÃ³: > Rob, > > On 12 May 2011, at 16:38, Rob Withers wrote: > > > It is a complete implementation with the bare minimum of supported algorithms, based on the spec. It is 100% in Smalltalk. It worked last time I tested in, several years ago. I will be able to tell you more this weekend. Others have been adding fixes/small features since, but not a lot - the base is pretty solid. I painstakingly followed the RFC for SSL - I think I read it over 20 times! The only issue would be algorithm support. I never benchmarked it, but seeing the difference in performance between Smlltalk crypto code like 3DES and plugin code, there is a SIGNIFICANT improvement (10x?). I do not know the state of Profiling under Pharo. If someone could help set me up, then I will profile it this weekend. I imagine both performance and certification were the reasons for SqueakSSL. > > > > There is also an SSH implementation I wrote that does dynamic window resizing on net latency. > > It would be *very cool* if that code base could be ported to Pharo. > It is really quite impressive that you did all this from the spec. > > I think that it would be possible to adjust my plan a bit, so that eventually, my code would use either the native plugin or your Smalltalk implementation. Then, we can compare features, functionality, bugs, etc.. > > Does that sound like a good idea ? But the performance is an issue. And I think that there was a discussion several years ago that lead to choice a plugin instead of the all-smalltalk code (independently of the queality of the smalltalk code). Also a point was made about the maintainability of the smalltalk code with respect to a library of the underlying OS, with respect to CERT issues and 0-day exploits. given the few resources in the community for simpler (relative to crypto) projects like *completion, RB and so, I think is a wise decision to use the proved, tested and maintained OS libraries through a plugin part of the standard VM. Of course, the smalltalk implementation can be used as a fallback for platforms where a plugin isn't available. Cheers > > Sven > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

May 12, 2011

Re: [Pharo-project] SSL/HTTPS -SecureSocketStream/SSLSessionforPharo/Squeak and otherSmalltalk implementations

by Rob Withers

Sure. I cannot recall if I offered a stream interface or not. I could add one and we could treat this and the SqueakSSL stream as provider impl to a wrapper stream. I'll comment more as I dig into it. I think I will fork a PharoSSL project, since I know of at least one change in there. Rob -----Original Message----- From: Sven Van Caekenberghe Sent: Thursday, May 12, 2011 10:53 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] SSL/HTTPS -SecureSocketStream/SSLSessionforPharo/Squeak and otherSmalltalk implementations Rob, On 12 May 2011, at 16:38, Rob Withers wrote: > It is a complete implementation with the bare minimum of supported > algorithms, based on the spec. It is 100% in Smalltalk. It worked last > time I tested in, several years ago. I will be able to tell you more this > weekend. Others have been adding fixes/small features since, but not a > lot - the base is pretty solid. I painstakingly followed the RFC for > SSL - I think I read it over 20 times! The only issue would be algorithm > support. I never benchmarked it, but seeing the difference in performance > between Smlltalk crypto code like 3DES and plugin code, there is a > SIGNIFICANT improvement (10x?). I do not know the state of Profiling > under Pharo. If someone could help set me up, then I will profile it this > weekend. I imagine both performance and certification were the reasons > for SqueakSSL. > > There is also an SSH implementation I wrote that does dynamic window > resizing on net latency. It would be *very cool* if that code base could be ported to Pharo. It is really quite impressive that you did all this from the spec. I think that it would be possible to adjust my plan a bit, so that eventually, my code would use either the native plugin or your Smalltalk implementation. Then, we can compare features, functionality, bugs, etc.. Does that sound like a good idea ? Sven

May 12, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Igor Stasenko

On 12 May 2011 16:02, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 10.05.2011 16:22, Igor Stasenko wrote: >> >> On 10 May 2011 13:33, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> Â wrote: >>> >>> On 10.05.2011 12:44, Igor Stasenko wrote: >>>> >>>> On 10 May 2011 11:27, Mariano Martinez Peck<marianopeck(a)gmail.com> >>>> Â wrote: >>>>> >>>>> On Tue, May 10, 2011 at 10:59 AM, Igor Stasenko<siguctua(a)gmail.com> >>>>> Â wrote: >>>>>> >>>>>> On 10 May 2011 09:48, Mariano Martinez Peck<marianopeck(a)gmail.com> >>>>>> Â wrote: >>>>>>> >>>>>>> On Tue, May 10, 2011 at 9:41 AM, Marcus >>>>>>> Denker<marcus.denker(a)inria.fr> >>>>>>> wrote: >>>>>>>> >>>>>>>> On May 10, 2011, at 9:32 AM, Mariano Martinez Peck wrote: >>>>>>>> >>>>>>>>> what is even worst, is that even after removing those correct CM, >>>>>>>>> and >>>>>>>>> doing a GC etc...they still don't disappear. >>>>>>>>> >>>>>>>> There is >>>>>>>> >>>>>>>> Â Â Â Â ScriptLoader new cleanUpMethods >>>>>>>> >>>>>>>> This is called from #cleanUpForRelease and normally should make sure >>>>>>>> there >>>>>>>> are no old methods. >>>>>>>> >>>>>>> hehehehe if I do: ScriptLoader new cleanUpForRelease, then inspect >>>>>>> ((CompiledMethod allInstances select: Â [:each | each trailer kind = >>>>>>> #VarLengthSourcePointer] ) ) >>>>>>> >>>>>>> they are not GC'ed and if then I click on the first element in the >>>>>>> inspector.... VM CRASH!!! Â with both, InterpreterVM and CogVM. >>>>>>> >>>>>>> :( >>>>>>> >>>>>> okay. it seems i found the offender. Its a CompiledMethod >>>>>> class>>cleanUp. >>>>>> It changing a source pointer of all non-installed methods to 0. >>>>> >>>>> Good catch!!! Â :) Â Anyway, why CompiledMethod class>>cleanUp would >>>>> like >>>>> to >>>>> destroy source pointers??? >>>>> If I understood correctly (please correct me), all compiled methods >>>>> will >>>>> loose the pointer to sources and hence they will be decompiled after >>>>> when >>>>> they are ask their source! >>>> >>>> Yes, if you wipe the sourcePointer, there is no way how you can get a >>>> source code of method. >>> >>> I believe the "not getting the source code" was on purpose. >>> It's done f.ex. as part of condenseChanges, as the source pointers would >>> have been invalid anyways. >>> The intent I believe is that you should get decompiled source if you >>> inspect >>> old(but still referenced) CompiledMethods, instead of a bogus display of >>> some random part of the new changes file, and remove error handling in >>> source lookup where pointer could potentially be beyond end of file. >>> >>> This of course worked much faster before trailers, when setSourcePointer: >>> actually modified the instance inline, rather than become'ing a copy, >>> nowadays I agree with Igor that it'd probably be more conceptually clean >>> to >>> the empty MethodTrailer in destroySourcePointer :) >>> >>> Just remember to make sure such instances decompile as expected to uphold >>> why the zapping was done in the first place. >>> If we're lucky, Â it won't crash the VM either ;) >>> >> Actually , in #destroySourcePointer setting sourcePointer = 0 is pretty >> useless. >> Since now, we can embed source code in trailer, we can replace a >> senders of it with #dropSourcePointer. >> Then you don't have to decompile the method, even if its no longer >> installed and cannot be located in .sources or .changes files anymore. > > You are forgetting, the send to #destroySourcePointer happens as a manual > step AFTER sources have been truncated. > So, trying to move it's source to a trailer from the changefile will be a > rather bad idea, as the source at its old pointer is either garbage, or > simply out of bounds of the change file already. There is #destroySourcePointer and #dropSourcePointer. First just destroys it, and don't attempts to retrieve the source code , because as you mentioned it may be not valid anymore. While #dropSourcePointer replacing a source pointer with embedded source code, and of course you should do it before condensing .changes or .sources, when source pointers are still pointing to correct place(s). CompiledMethod>>cleanUp using #destroySourcePointer, so there should be no problem with that. >> >> We could even do this at the method installation time: >> Â - if a newly installed method replacing an old one, >> we tell old one to drop its source pointer immediately. >> >> Then, by definition, you cannot have non-installed methods with wrong >> source pointer, and all those methods will still be able to show you >> an original source code. >> >> Sounds like an idea? > > This would be the alternative, yes. > Not sure if it's worth it, as the source will still be valid as long as > change file isn't messed with. > It seems like that with this change i opened a can of worms. There are some tricky logic somewhere ,which uninstalls methods from classes and then adds them back. So, i added #dropSourcePointer at uninstalling .. then compilation becomes too slow (because embedding source code using #becomeForward: ). Then i changed #dropSourcePointer to actually erase the trailer without using #become .. but then some methods lost their source. > Decompiled code for old methods which were moved as part of a truncation, > where the new versions have the exact same, and correct source doesn't sound > like the end of the world to me. The method itself did not actually change. > > Cheers, > Henry > -- Best regards, Igor Stasenko AKA sig.

May 12, 2011

Re: [Pharo-project] [Moose-dev] Re: Highlight problem with glamour

by Henrik Sperre Johansen

On 12.05.2011 16:42, Tudor Girba wrote: > Hi Henrik, > > On 12 May 2011, at 16:30, Henrik Sperre Johansen wrote: > >> On 12.05.2011 16:10, Tudor Girba wrote: >>> Thanks, Fabrizio. >>> >>> I noticed a similar problem with highlighting Java code, but I thought it was related to the grammar. >>> >>> I CC-ed the Pharo mailing list. >>> >>> Anyone knows why it would be a problem to highlight text with more than 4096 characters in a TextMorph? >>> >>> Cheers, >>> Doru >> Doru, I have NO idea what Morph GLMTabulator uses to display text, nor any desire of spending time trying to (maybe even succesfully) load Glamour. >> When posting snippets like that to the Core dev list, at least, PLEASE, either include a doit to load the components needed to reproduce the provided case, or reduce it to something which can be reproduced in core. >> >> | string | >> string := ''.1 to: 1000 do: [:i | string := string, 'jjjjj j j j j j jjj j']. >> ((string asText addAttribute: TextColor red), ('jjjjj j j j j j jjj j' asText)) asMorph openInWorld >> >> Works just fine, for example. > The question had nothing to do with Glamour, but I am sorry if the form of the mail made you waste your time. No problem, it was my decision to waste it. Was meant more as a general comment to inquieries like this, and why they often go unanswered. And in a way, I guess it did help a little bit, in the sense of clearing TextMorph of involvement :) Good to see it had already been solved! Cheers, Henry

May 12, 2011

Re: [Pharo-project] Helvetia... in Squeak

by Lukas Renggli

On 12 May 2011 17:47, Tudor Girba <tudor.girba(a)gmail.com> wrote: > I thought that Helvetia also works in Pharo 1.2.1. At least I saw that Bifrost is using it. Am I wrong? No, this is just RB and the AST-Compiler (RB to Pharo Compiler Bridge). Lukas -- Lukas Renggli www.lukas-renggli.ch

May 12, 2011

Re: [Pharo-project] [ANN] VB-Regex patch available

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=4203 Stef On May 12, 2011, at 4:28 PM, Nicolas Cellier wrote: > Reinout Heek recently published a patch in cincom store for some Regex > pending bugs after a recent mail on vwnc list. > I ported this 3-methods patch on Squeak based on latest > http://www.squeaksource.com/Regex.htm > I have no commit right, so I posted two copies: > > http://source.squeak.org/inbox/VB-Regex-nice.18.mcz > http://www.squeaksource.com/PharoInbox/VB-Regex-nice.18.mcz > > Note that core Pharo version of Regex is some versions ahead and the > patch requires further porting. > > Nicolas > > > ------------------------------------------------------------------------- > Port fixes from Reinout Heek from VW.Regex11 > > Regex11(1.3.1-soops1) - introduces fix > Regex11(1.3.3) - merge above with 1.3.2 > > Blessing comment: > > Fixed RxmBranch to do greedy matching instead of first match passes. > This entailed adding a collection copy to #currentState, so I > expect this to slow down Regex11 a bit (not measured yet). > > This fixes a bug found a Soops: > '.*(ABCD|BC)' asRegex matches: 'fooABCD' > and Mantis bug 5391: > '15' matchesRegex: '[1-9]|1[0-9]' > > See http://bugs.squeak.org/view.php?id=5391 >

May 12, 2011

Re: [Pharo-project] [ANN] VB-Regex patch available

by StÃ©phane Ducasse

Thanks nicolas I will integrate it now. > Reinout Heek recently published a patch in cincom store for some Regex > pending bugs after a recent mail on vwnc list. > I ported this 3-methods patch on Squeak based on latest > http://www.squeaksource.com/Regex.htm > I have no commit right, so I posted two copies: > > http://source.squeak.org/inbox/VB-Regex-nice.18.mcz > http://www.squeaksource.com/PharoInbox/VB-Regex-nice.18.mcz > > Note that core Pharo version of Regex is some versions ahead and the > patch requires further porting. What do you mean by further porting > > Nicolas > > > ------------------------------------------------------------------------- > Port fixes from Reinout Heek from VW.Regex11 > > Regex11(1.3.1-soops1) - introduces fix > Regex11(1.3.3) - merge above with 1.3.2 > > Blessing comment: > > Fixed RxmBranch to do greedy matching instead of first match passes. > This entailed adding a collection copy to #currentState, so I > expect this to slow down Regex11 a bit (not measured yet). > > This fixes a bug found a Soops: > '.*(ABCD|BC)' asRegex matches: 'fooABCD' > and Mantis bug 5391: > '15' matchesRegex: '[1-9]|1[0-9]' > > See http://bugs.squeak.org/view.php?id=5391 >

May 12, 2011