- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] runSimulated behaviour

by StÃ©phane Ducasse

tx! On May 23, 2010, at 11:24 PM, Eliot Miranda wrote: > Hi Michael, Michael, Dennis, Hi All, > > I think this is a simple bug in ContextPart >> #tryNamedPrimitiveIn:for:withArgs:, which neglects to flush the method cache for the method and/or selector used to simulate execution of a named primitive. With the relevant flushCacher calls added I no longer see any of the simulation failures recently experienced (someMethod getSourceFromFile, TimeStamp now). Please test the attached and let me know how you get on. > > The problem is caused by using the same method to invoke differet primitives in quick succession where, because the method cache is not flushed, the wrong primitive (a previous primitive) is left in the cache and invoked instead of the desired primitive. In Cog I added a primitive to directly evaluate a named primitive so the problem does not occur. Adding the two lines marked >> below fixes the problem. The line "theMethod flushCache" is probably more than we need, but does not harm. > > HTH > Eliot > > > !ContextPart methodsFor: 'private' stamp: 'eem 5/23/2010 14:13'! > tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments > "Hack. Attempt to execute the named primitive from the given compiled method" > | selector theMethod spec | > arguments size > 8 ifTrue:[^PrimitiveFailToken]. > selector := #( > tryNamedPrimitive > tryNamedPrimitive: > tryNamedPrimitive:with: > tryNamedPrimitive:with:with: > tryNamedPrimitive:with:with:with: > tryNamedPrimitive:with:with:with:with: > tryNamedPrimitive:with:with:with:with:with: > tryNamedPrimitive:with:with:with:with:with:with: > tryNamedPrimitive:with:with:with:with:with:with:with:) at: arguments size+1. > theMethod := aReceiver class lookupSelector: selector. > theMethod == nil ifTrue:[^PrimitiveFailToken]. > spec := theMethod literalAt: 1. > spec replaceFrom: 1 to: spec size with: (aCompiledMethod literalAt: 1) startingAt: 1. > >> theMethod flushCache. > >> selector flushCache. > ^aReceiver perform: selector withArguments: arguments! ! > > On Thu, May 20, 2010 at 2:55 AM, Michael Haupt <mhaupt(a)gmail.com> wrote: > Dear all, > > we're observing some strange behaviour in simulated bytecode execution > in Squeak (4.1, on Macs). > > Printing this: > ContextPart runSimulated: [ TimeStamp now ] > will work once and then reproducibly fail with code simulation errors. > > This works well (also reproducibly): > ContextPart trace: [ TimeStamp now ] > > Going to more detail, we figured out that simulation reproducibly > works if things are written to the Transcript every now and then. > Printing this: > n:=0. thisContext runSimulated: [ TimeStamp now ] contextAtEachStep: [ > :c | n\\100=0 ifTrue: [ Transcript show: $. ] ] > works. > > We've tried to just insert some artificial delays (<someValue> > milliSeconds asDelay wait) in the block, but that will not > reproducibly work; it also leads to code simulation errors. So it > can't be just the time it takes to write to Transcript. Or so we > believe. > > Does anybody know the reason for this strange behaviour, or where in > the simulation logic to look? > > Best, > > Michael > > > <ContextPart-tryNamedPrimitiveInforwithArgs.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] Metacello and SourceTalk ...

by StÃ©phane Ducasse

thanks for the update. Stef On May 24, 2010, at 2:42 AM, Julian Fitzell wrote: > The fact that MC2 is still a moving target. Or at least it would be if it was moving. :) More to the point, the early releases had some problems that prompted further redesign and I'd recommend against creating large amounts of date in those versions that will need to be brought forward. In other words, I don't think it's ready for prime time in its current state. > > Julian > > On Mon, May 17, 2010 at 1:34 PM, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > > What would be the biggest challenges moving to MC2 and a MC2 Repository like > SourceTalk? > > > Mariano Martinez Peck wrote: > > > > Hi Geert. I agree it would awesome to have Monticello 2 and SourcTalk for > > Pharo 1.2. I have not idea the status. I tested once (you can see > > squeakdbx there) but I have a lot of problems. And the project seems > > "dead". I mean, I don't think someone is working on it. That said, it > > would be great someone to work on it and maybe start to using it by Pharo > > 1.2 > > > -- > View this message in context: http://forum.world.st/Metacello-and-SourceTalk-tp2219294p2219517.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] Rendering fonts on OpenGL

by StÃ©phane Ducasse

On May 23, 2010, at 11:04 PM, Igor Stasenko wrote: > 2010/5/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: >> Hi, may I ask how you are rendering these fonts? You parse the glyphs and >> then render lines with opengl or use freetype to render to a texture without >> antialiasing or both? > > Squeak has already a TT font reader, so i just taking the data from there > and piping to GPU. > What you see here is freely scalable vector/curve rendering done > completely on GPU. > >> If you asked me, I'd say I like the method but for >> fonts they look a bit blury, I'd say too much for the smaller ones. > > I think this is best what you can achieve without hinting / subpixel AA. > >> Also, what are you working on? >> > I once did a GLCanvas, > and now i want to reiterate and improve it using new callout mechanism > (NativeBoost), > and full coverage of OpenGL API, with all extensions available at your disposal. Igor it would be good it we could have NativeBoostRomeCanvas if you see what I mean :) > >> Regards, >> Javier. >> >> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] [BUG] VM crash during debbuging some code by Through button with Transcript>>show: in deepest inner methods

by StÃ©phane Ducasse

thanks a lot denis. Can you create one or two bug entries in the bug tracking tool and attach your code there? Stef On May 23, 2010, at 4:18 PM, Denis Kudriashov wrote: > I found more bad cases with code simulation. And I think any manipulations with context (errors signals, simaphore, ...) not work in simulation mode. Transcript printing failed because of simaphore accessing (for thread safety) > > I create CodeSimulationTests (see attachement) with some tests which not work and which crash VM. > > Maybe this tests not correct. But I hope it helps to indicate and solve issues > > 2010/5/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Thanks! > > Stef > > On May 23, 2010, at 11:13 AM, Denis Kudriashov wrote: > > > And If you replace Transcript code with > > > > self halt. > > > > You will see that debugging with through button does not work. Code simulation failure raised (but without VM crash) > > > > 2010/5/23 Denis Kudriashov <dionisiydk(a)gmail.com> > > I has Pharo1.0 one click, Windows 7. > > I attach class ClassWithTranscriptPrinting. > > see class side method #debug > > > > > > > > > > > > 2010/5/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > > Hi denis > > > > can you report clearly your bug > > - image > > - vm > > - os > > - scenario > > > > I could not compile > > Transcript>>show:'something' > > > > so I do not know how you did it. > > > > > > > > On May 23, 2010, at 10:11 AM, Denis Kudriashov wrote: > > > > > Hello > > > > > > Just insert > > > Transcript>>show:'something' > > > at any method begin. > > > > > > Now debug sender of your method by debugger Through button. > > > > > > If no Transcript opened VM will crash! > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <CodeSimulationTests.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] About the Pharo Issue tracker

by StÃ©phane Ducasse

when you close or tag as won't fixes put on on the cc line or send an email to the mailing-list. Stef On May 24, 2010, at 7:04 AM, Carla F. Griggio wrote: > Welcome, Guille :) It was very cool to have you in the Sprint :) > > I notice that if I try to post a new issue, I can't categorize it. Who is able to categorize issues? > > Carla. > > 2010/5/23 Guillermo Polito <guillermopolito(a)gmail.com> > Hi! > > First I may introduce myself. My name is Guillermo Polito and I'm from Argentina. I've been using Pharo for several months with some colleagues that are already here to teach OOP in the UTN university, and i've been suscribed to this mailing list for some time. But it's my first mail here :P. > > I participated yesterday in the Pharo Sprint in Argentina and there I had my first look at the issue tracker. And well, it seemed to me to be a little messy. There are lots of issues that aren't properly explained, some of them are duplicated, and they are not well organized. > It would be nice to use the labels googlecode provides to give them some categorization, so we can browse them in a more intelligent way. Maybe we can split the issues in "modules" (like Collection issues, Compiler Issues, Closures Issues, Networking Issues...) or something like that. That will help in avoiding duplications and looking for issues to solve (because I can look for issues in the modules I know the most). > > At the moment I will stay looking for issues i can fix or commenting the ones that lacks information :). > > Regards, > Guille > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] About the Pharo Issue tracker

by StÃ©phane Ducasse

On May 23, 2010, at 8:33 PM, Guillermo Polito wrote: > Hi! > > First I may introduce myself. My name is Guillermo Polito and I'm from Argentina. I've been using Pharo for several months with some colleagues that are already here to teach OOP in the UTN university, and i've been suscribed to this mailing list for some time. But it's my first mail here :P. Welcome > > I participated yesterday in the Pharo Sprint in Argentina and there I had my first look at the issue tracker. Thanks for your time. I will go over the produced fixes today using Torch :) > And well, it seemed to me to be a little messy. There are lots of issues that aren't properly explained, some of them are duplicated, and they are not well organized. And you would not imagine if we would not spend a lot of time on it.... This is like a garden. > It would be nice to use the labels googlecode provides to give them some categorization, so we can browse them in a more intelligent way. Maybe we can split the issues in "modules" (like Collection issues, Compiler Issues, Closures Issues, Networking Issues...) or something like that. That will help in avoiding duplications and looking for issues to solve (because I can look for issues in the modules I know the most). > > At the moment I will stay looking for issues i can fix or commenting the ones that lacks information :). Excellent Tagging the entries with semantics is a good idea. > > Regards, > Guille > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] CompiledMethodTrailer with a different CompiledMethod class

by StÃ©phane Ducasse

and send us the fix for inclusion :) On May 24, 2010, at 10:54 AM, Igor Stasenko wrote: > On 24 May 2010 10:31, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >> Hello >> >> Just to make a little note. I'm adapting the lightweight classes >> package to work with CompilerMethodTrailer. In this method >> >> CompiledMethodTrailer>>createMethod: numberOfBytesForAllButTrailer >> header: headerWord >> | meth | >> encodedData ifNil: [ self encode ]. >> meth := CompiledMethod newMethod: numberOfBytesForAllButTrailer + >> size header: headerWord. >> ... >> >> I need to answer a different kind of CompiledMethod, it would be nice >> if my own CompiledMethod class could be specified in some way to make >> the CompiledMethodTrailer more flexible. > > Yes, you could add a class parameter, so method will take 3 > > createMethod: numberOfBytesForAllButTrailer header: headerWord class: > aMethodClass > >> Cheers, >> >> HernÃ¡n >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] Bug? ParagraphEditor do-its are not following the expected method lookup

by StÃ©phane Ducasse

cool! Stef On May 24, 2010, at 8:04 AM, Carla F. Griggio wrote: > Well, just to let you know, I've submitted a fix to PharoInbox: > > Name: SLICE-superBugInParagraphEditor-carlaGriggio.1 > Author: carlaGriggio > Time: 24 May 2010, 2:33:50 am > UUID: 94ff9a49-b4ba-488b-9470-777e0f1885a7 > Ancestors: SLICE-superBugInParagraphEditor-carlaGriggio.1 > Dependencies: Compiler-carlaGriggio.212, CompilerTests-carlaGriggio.42, Kernel-carlaGriggio.665, ParagraphEditor-Test-carlaGriggio.1 > > But I can't change the status of the issue to fixed :P > > On Wed, May 19, 2010 at 4:51 PM, Carla F. Griggio <carla.griggio(a)gmail.com> wrote: > Not the cs, I have an st. It's in the first email of this thread. I also attached a cs with a possible fix. > > > > On Wed, May 19, 2010 at 4:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes this is an important bug > do you have the cs of your little example? > > Stef > > On May 19, 2010, at 9:17 PM, Carla F. Griggio wrote: > > > Just reproducing it would be helpful :O a friend of mine already > > tested the code I attatched and saw the same problem. > > > > If you recall having a class with a method sending a message to super, > > and a sublclass inheriting that method, you can try to reproduce it > > there too debugging that message on an instance of the subclass. > > > > It's not easy to explain with words, that's why I made a little > > package of code to illustrate the situation. > > > > The thing is that when printing the evaluation of a selected bunch of > > code inside a debugger window (paragraphEditor?), if the code you're > > evaluating is a message to super, and the class of the object you're > > debugging is inheriting the method you're debugging, the printed > > result will be wrong. In other words, the method lookup fails. > > > > This doesn't happen with normal excution of code (thank God!). > > > > I think this is an important bug, seeing those wrong results when > > debugging can be very confusing. I spent hours feeling stupid last > > Monday while debugging because I trusted those wrong results and > > couldn't see where I was doing something wrong :P > > > > Cheers! > > Carla > > > > On Wednesday, May 19, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Hi Carla. I would like to help you, but I have no idea. I could reproduce it. > >> > >> Maybe Lukas, Igor, Eliot etc can help you. I have no idea. > >> > >> Cheers > >> > >> Mariano > >> > >> 2010/5/18 Carla F. Griggio <carla.griggio(a)gmail.com> > >> Hi everybody! > >> Well, maybe you are already aware of this... maybe not. I tried to find an issue about this and unless I didn't think of the right keywords, it's not there. > >> > >> > >> > >> I was debugging a template method and sudenly I found myself spending ours trying to find out why I got different results when printing the result of a message sent to super and when steping into that message and printing the (same) result there. > >> > >> > >> > >> Imagine this simple situation (I attatch the complete code and some tests so you can reproduce this): > >> AverageTotalization inherits from Totalization.WeightedAverageTotalization inherits from AverageTotalization. > >> > >> > >> > >> Totalization>>total > >> > >> ^self summatory > >> > >> > >> > >> > >> > >> AverageTotalization>>total > >> > >> ^(super total) / self denominator > >> > >> > >> > >> > >> > >> AverageTotalization>> denominator > >> > >> ^values size > >> > >> > >> > >> > >> WeightedAverageTotalization>> denominator > >> > >> "Weights is a dictionary" > >> > >> ^self weights values sum > >> > >> > >> > >> > >> If I debug aWeightedAverateTotalization total and try to print super total in the debugger ParagraphEditor, I'll get this result: > >> > >> > >> > >> (self summatory / self denominator) > >> > >> > >> instead of just: > >> self summatory > >> This only happens when I print or inspect or other do-its in the debugger window. The method lookup works OK when just _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by Serge Stinckwich

When i switch to demo mode, method selector in System Browser are no more bold in the bottom pane. 2010/5/21 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi Pharaoers. I am pleased to announce the first Pharo 1.1 beta based on > PharoCore-1.1-11367-Beta. It is the first time we build a Pharo 1.1 dev > image with PharoCore 1.1 so the image may be not 100% stable. However, we > think it is good to release it so that people can start to test it, load > their own packages, adapt them, etc. We would like to receive feedback about > it. It (yet) has failing and error tests. > > The main changes with Pharo 1.0 is that of course, it is based on a > PharoCore 1.1 with all that it means. We started to write down some of the > actions done in PharoCore 1.1. The list so far can be found here: > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotOne > Of course, for the stable releae of Pharo 1.1 we will do a clear list in the > website as we did for 1.0. > > Regarding the included packages in 1.1 we added ScriptManager (a tool to > manage and persist workspaces), ProfStefBrowser, ArchiveViewer, > MethodWrappers and ObjectMetaTools (which includes things like > ProtocolCatcher, ObjectTracer, ObjectViewer, etc). > > Another difference is the font. In Pharo 1.0 we used TrueType fonts by > default. In Pharo 1.1 we use StrikeFonts (no need of TrueType plugin, > netiher to have the fonts). However, of course, you can disable StrikeFonts > and put TrueType like in 1.0. > > That's all. We would really appreciate you use it, test it, report issues, > provide fixes, etc. It is important also that you start to use your own > packages/applications. There have been several changes in 1.1 that may > require change in your code. > > Ahh if you want to create the image yourself, check as usually the > installScript.st file to see how to do it. Actually, you can just take a > PharoCore-1.1-11367-Beta image and evaluate (the same procedure as 1.0): > > Gofer new > Â Â Â squeaksource: 'MetacelloRepository'; > Â Â Â package: 'ConfigurationOfPharo'; > Â Â Â load. > > ((Smalltalk at: #ConfigurationOfPharo) project version: '1.1-beta1.10517') > load. > > Here is the link to the image: > > https://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05… > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 24, 2010

Re: [Pharo-project] CompiledMethodTrailer with a different CompiledMethod class

by Igor Stasenko

On 24 May 2010 10:31, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hello > > Just to make a little note. I'm adapting the lightweight classes > package to work with CompilerMethodTrailer. In this method > > CompiledMethodTrailer>>createMethod: numberOfBytesForAllButTrailer > header: headerWord > Â Â Â Â | meth | > Â Â Â Â encodedData ifNil: [ self encode ]. > Â Â Â Â meth := CompiledMethod newMethod: numberOfBytesForAllButTrailer + > size header: headerWord. > Â Â Â Â ... > > I need to answer a different kind of CompiledMethod, it would be nice > if my own CompiledMethod class could be specified in some way to make > the CompiledMethodTrailer more flexible. Yes, you could add a class parameter, so method will take 3 createMethod: numberOfBytesForAllButTrailer header: headerWord class: aMethodClass > Cheers, > > HernÃ¡n > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig.

May 24, 2010