- Pharo-dev - lists.pharo.org

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

[Pharo-project] New transcript questions and notes (take 2)

by DougEdmunds

[Yesterday I posted this on Nabble, and deleted it, because it wasn't processing (apparently the mail server was down). That's a mistake. Now it's in the mailing list archive, but the Nabble entry http://forum.world.st/New-transcript-questions-and-notes-tp3516546p3516546.… is gone, which means it may not garner a reply.] So, with apologies, I repeat: Using Pharo1.3a Latest update: #13193 Are there any plans to give the new transcript window a mouseable menu? If not, buttons for select all and copy would be nice. -- Nothing seems to be happening when clicking 'log to file'. What is the name of the file? Where is it? -- When checking/unchecking/checking 'log to file' will the second checking add to the end of an existing file, or will it start a new one, or wipe out old one and start it over? -- This code does not work right with the new transcript: 1 to: 30 do: [: x | Transcript cr; show: x. (Delay forSeconds: 0.2) wait.]. a) Try it in 1.2 (old transcript) to see how it should work. Old transcript, there's a delay between each line printed. 1.3 (new transcript) there's a total delay first, then all the lines are immediately printed. b) If the length of the entries to the transcript exceeds the size of the window, the lines do not automatically scroll up to be able to see them. Instead, they are added outside of the visible window area. IMO, this must be changed so that whatever gets added to the end of the transcript is immediately visible. c) If cursor is at the bottom (with a vertical scroll bar visible), as soon as a new line is added, the transcript pops back to the beginning again, requiring scrolling to see new entries. This makes any kind of continual stream to the transcript impossible to view. Position the Transcript at the end of the output, then run the 1 to: 30 do: code line again -- it will pop you to the top, not the end. -- Will the vertical size of the header area (Clear, etc) be reduced? It is taller than needed. -- View this message in context: http://forum.world.st/New-transcript-questions-and-notes-take-2-tp3517942p3… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 12, 2011

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

by Tudor Girba

I thought that Helvetia also works in Pharo 1.2.1. At least I saw that Bifrost is using it. Am I wrong? Cheers, Doru On 12 May 2011, at 17:43, Lukas Renggli wrote: >>> The builds are not running anymore. Helvetia is based on Pharo 1.1.1. >>> I don't have the time to maintain the codebase. >> >> That's a pity, it was/is quite impressive (I read your paper, have your PhD on my reading list). >> >> But I understand. > > It is a lot of work. It took me more than 1 year (about 1 month of > full time) to move Helvetia forward from Pharo 0.9 to 1.1. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

May 12, 2011

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

by Lukas Renggli

>> The builds are not running anymore. Helvetia is based on Pharo 1.1.1. >> I don't have the time to maintain the codebase. > > That's a pity, it was/is quite impressive (I read your paper, have your PhD on my reading list). > > But I understand. It is a lot of work. It took me more than 1 year (about 1 month of full time) to move Helvetia forward from Pharo 0.9 to 1.1. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 12, 2011

Re: [Pharo-project] [update 1.2] #12352

by Tudor Girba

Hi, On 12 May 2011, at 17:19, Damien Cassou wrote: > On Thu, May 12, 2011 at 8:49 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Issue 4157: TextColor is ignored in large TextEditors > > IIRC, this was made on purpose to avoid waiting hours for syntax > highlighting to color big regions. I see the intent but I think this is done at the wrong level, because like this we have no way to highlight something even if we would be willing to wait. Cheers, Doru > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

May 12, 2011

Re: [Pharo-project] [squeak-dev] [NativeBoost] Need your ideas, what platform-neutral assembler syntax you would like to have

by Igor Stasenko

On 12 May 2011 17:22, Gerardo Richarte <gera(a)corest.com> wrote: > On 05/10/2011 08:34 PM, Igor Stasenko wrote: >> Things i don't like: register naming. >> In cog you should use following register names: >> Â Â Â FPReg := -1. >> Â Â Â SPReg := -2. >> Â Â Â ReceiverResultReg := GPRegMax := -3. >> Â Â Â TempReg := -4. >> Â Â Â ClassReg := -5. >> Â Â Â SendNumArgsReg := -6. >> Â Â Â Arg0Reg := -7. >> Â Â Â Arg1Reg := GPRegMin := -8. >> Â Â Â DPFPReg0 := -9. >> >> They are mapping 1:1 to real registers on your machine. > > "Our" names are pretty similar to those, and I don't really see they are > 1:1 mapping to architecture (though at some point you will have that > mapping). The 1:1 mapping is not on names, but latter on implementation, > and I think that has to do with exactly what Cog wants: a fast > implementation. > In Cog TempReg maps to EAX. and rest of register names mapped directly to assembler ones. I don't see how register names could affect an implementation. It depends where and how you using them. I agree that when you generating code which closely related to VM internals, then it makes sense to use special names like SendNumArgsReg. But if you wanna use spare register to hold something else than NumArgs.. then using such name is not helping. In that cases, i would prefer to use neutral names, like GPReg0 ... GPRegX .. which stands for General Purpose Register. Because the role of certain register may be different depending on where you using it. > FP is frame pointer, and it's the generic name for what in intel is BP > (in gdb you can do either $rbp or $fp) > SP is a generic name for the stack pointer (in gdb you can use $sp or $rsp) > ReceiverResult has to do with the use, nothing to do with processor > etc. > > not sure what DPFPReg0 stands for. > I guess its a "Double Precision Floating Point Register number 0" :) > I think the names are good for a VM implementation. Though maybe not for > a generic assembler. I think the that might be the difference between > Cog's and NativeBoost's needs > Yes. This is why i asking.. Because i want it to be generic. > Â Â gera > -- Best regards, Igor Stasenko AKA sig.

May 12, 2011