- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Canvas transform bug when rendering text?

by Henrik Johansen

On Apr 7, 2010, at 1:45 49PM, David Harvey wrote: > Hi list, > > I'm writing a little charting morph, and while playing with rotating text for axis labels came across something which I've noted in Morphs text handling a couple of times. > > If I apply a transform in a drawing operation, rotated text _appears_ to be drawn twice, slightly offset, giving a scrappy bold look. It seems only to do this when drawing on a form canvas that's backed onto the display: if you pick and drag the morph, the text is rendered beautifully. > > The test morph attached isolates the problem. The transcript logging is an attempt to see what might be happening: looking at the output it appears that there are circumstances in which the during: block is invoked twice. > > Any thoughts? > > David http://n4.nabble.com/Problem-with-TransformationMorph-td1691811.html#a16918… Basically, transform doesn't work with depth 32. Workarounds are described in the thread. Cheers, Henry

April 7, 2010

Re: [Pharo-project] todo after 1.0 is released

by Mariano Martinez Peck

On Wed, Apr 7, 2010 at 1:07 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi Adrian > > Once 1.0 is released we should check that all the fixes that went in 1.0 > after the fork to 1.1 are integrated in 1.1. > The problem is how we can identify them ? I only remember http://code.google.com/p/pharo/issues/detail?id=1841 but it even is different in 1.1 Ahh maybe also the NetNameResolver problem ? > Would be nice also to remove the testsexpected to break so that we give > them a chance to be fixed in 1.1. > > Good idea. > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 7, 2010

Re: [Pharo-project] CollabActive book :)

by Michael Roberts

I'm afraid it doesn't work behind my coporate firewall. I will need to look in more detail. I think some redirects are perhaps being dropped. In IE 6 it doesn't work at all. Login command goes to a page that says command PULogin not found. I don't care for IE but I know the proxy is configured. In firefox with foxy proxy I can login but when I add a page, the page I get back is exactly the same as the one for the add. It's just my name eg test2 has been replaced by untitled. Any ideas? I will dig around. Cheers mike On Tuesday, April 6, 2010, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi Mike, > > I am not sure I understand what the problem is. > > Try this: > # go to a page: http://book.pharo-project.org/book/introduction > # invoke Add > # enter a name (e.g., "somepage") and select Book Portion > # press add > > This should create a new section in the introduction. Please let me know if it works for you. > > Cheers, > Doru > > On 6 Apr 2010, at 23:24, Michael Roberts wrote: > > > Hi, > > is there some brief documentation for how to use the book engine? I am > not a pier expert, i just get the basic ideas. Â I tried to add some > new pages/sections using the add command, but it kept on logging me > out to the front page. Â I could not work out whether these actions had > any side-effect or not. Â If there are no docs, perhaps someone > knowledgeable could just add a page, showing how to add a page... > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 7, 2010

Re: [Pharo-project] Fwd: [squeak-dev] OB performance (Re: Slime)

by Lukas Renggli

> Lukas, do you think this is worth? I can neither observe nor measure a performance improvement, but i've integrated it this morning as it makes sense not to recreate the buttons all the time. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 7, 2010

Re: [Pharo-project] Bug or new feature in RB?

by Lukas Renggli

> So, my question is, shouldn't only apply the refactor to the initialize > method of extended packages ONLY if that method is extended ? Because > otherwise I think it is a bit dangerous. > > What do you think ? > > I attach screenshot also. I see no screenshot, but I can reproduce the problem. The problem is that for some refactorings the refactoring engine needs too look beyond the defined scope to be able to do something useful (e.g. if a class is not contained in a scope but some methods, it still needs some object that represents the class to enumerate the methods). There are definitely issues when classes are not fully contained within a scope, but I don't think that this is critical. After all the changes are presented for review. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 7, 2010

[Pharo-project] Canvas transform bug when rendering text?

by David Harvey

Hi list, I'm writing a little charting morph, and while playing with rotating text for axis labels came across something which I've noted in Morphs text handling a couple of times. If I apply a transform in a drawing operation, rotated text _appears_ to be drawn twice, slightly offset, giving a scrappy bold look. It seems only to do this when drawing on a form canvas that's backed onto the display: if you pick and drag the morph, the text is rendered beautifully. The test morph attached isolates the problem. The transcript logging is an attempt to see what might be happening: looking at the output it appears that there are circumstances in which the during: block is invoked twice. Any thoughts? David ------------------ David Harvey www.teamsandtechnology.com www.cateams.com @david_harvey

April 7, 2010

[Pharo-project] Fwd: [squeak-dev] OB performance (Re: Slime)

by Mariano Martinez Peck

Thanks Andreas :) Lukas, do you think this is worth? ---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: Wed, Apr 7, 2010 at 5:25 AM Subject: [squeak-dev] OB performance (Re: Slime) To: The general-purpose Squeak developers list < squeak-dev(a)lists.squeakfoundation.org> On 4/3/2010 2:22 PM, Colin Putney wrote: > > On 2010-04-03, at 11:50 AM, Andreas Raab wrote: > > On 4/3/2010 11:27 AM, Levente Uzonyi wrote: >> >>> On Sat, 3 Apr 2010, Andreas Raab wrote: >>> >>>> Interesting. My encounters with OB mostly originate from Pharo where >>>> it's always been dog-slow so I was never interested in looked deeper. >>>> Any ideas how to install OB without that stuff? >>>> >>> >>> Try this: >>> >> >> Thanks. It's definitely better than I remembered. I'm still noticing a >> real delay in some areas though, for example when I click on a system >> category. One thing you can try to test this is to open a regular browser >> and OB and then just keep scrolling through the system categories with >> cursor up or cursor down. In the regular browser this entirely smooth; in OB >> it's "stuttering" and at least I notice the same delay when clicking on the >> list. >> > > Yeah, this one area where OB is certainly not as fast. That's because OB > sorts classes according to inheritance, rather than name. It's just more > work. I find the tradeoff worthwhile - it's not that slow, and the extra > information imparted by the sort order is useful - but reasonable people may > disagree. It wouldn't be hard to make this a preference. > Nope it's not that. A bit of profiling shows the particular problem is caused by some gross inefficiencies when updating. If you file in the attached tweaks, OB scrolls just as smoothly as the standard browser. I'm not sure if the tweaks have side effects though; you might want to verify that (in particular because of the comment in OBColumn>>switchFilter: which indicates some interference although I can't see how that could make a difference if the filter is identical). Cheers, - Andreas

April 7, 2010

[Pharo-project] todo after 1.0 is released

by StÃ©phane Ducasse

Hi Adrian Once 1.0 is released we should check that all the fixes that went in 1.0 after the fork to 1.1 are integrated in 1.1. Would be nice also to remove the testsexpected to break so that we give them a chance to be fixed in 1.1. Stef

April 7, 2010

Re: [Pharo-project] Redline Smalltalk

by Mariano Martinez Peck

> > >> Dan, Mariano for his PhD did some analysis about number of object used > during typical coding session and we got around 17 %. > >> So mariano would like to see how we can get something like LOOM to > dispose unused objects :) > > > > Are you aware of the work I did that enables class fault detection in > Squeak? > > Yes :) > MDFault that hijack the method category > > But now it is in a separate package: http://www.squeaksource.com/ClaseUseDiscovery > > If a class has a nil methodDictionary, it causes a fault (ie it sends > recoverFromMDFault to the class). That code then restores the MD in > addition to any anyalysis you want. I never cleaned it up for posterity, but > it enabled lots of interesting work... > > The problem is that we did some experiences (not too advance with mathieu) > and we got all the classes touched after a couple of seconds. > > > By nilling all but a few MDs, and then running some application, > you could > > tell exactly what classes were needed and which were not. > > See the method discoverActiveClasses. > > A special feature even recorded the call stack that caused each > class to be > > touched. > ok this one I was not aware. > I was ;) you can read how to enable that trance and see the results, in the class comment of CUDClassesUseDiscoverer And also in the tests. > > What I was doing was restructuring the entire system as a bunch of > > image segments that could be swapped out and brought in > > on demand -- a sort of user-programmable swapping memory. > > What mariano did so far is to > - read all the image segments code /c included > - find it dangerous > As we discussed recently: http://n4.nabble.com/The-Pharo-Linux-Vm-WAS-Squeak-VM-FT2Plugin-all-Pharo-1… ImageSegment primitives and the VERY core is working well. The problem is all what is/was implemented on top of that for Project and friends. > - clean the project and etoy related code (for me the simple fact > that you have all the special cases for projects > reveals that there is a deeper fundamental problem. I do not have > the answer but normally the "swapouter" should be generic > and may be provide hooks for specific cases but not do that in the > logic itself. > - define some primitive to use the extra bit to collect some measure > of object used. > - read / understand loom + the same in Java in OOPSLA 2008 > This paper is very related to what we are talking about: http://www.cs.utexas.edu/~mikebond/melt-oopsla-2008.pdf > > Another problem was the size of array which may be double or triple than > what you want to save mariano will be more precise than me. > > This, this was a minor problem. But if you want to use ImageSegment for REALLY big segmentes (Like DabbleDB) you may have a problem as ImageSegment allocates 2 or 3 times the size of the array....maybe adding a primitive to do that directly in disk (of course it will be slower) could be a good idea. Cheers Mariano > > > > > > > - Dan > > > >> > >>> James Ladd <james_ladd(a)hotmail.com> wrote... > >>>>> Hi Pharo-ites, > >>>>> > >>>>> I'm working on a port of Pharo to the Java Virtual Machine called > Redline Smalltalk. > >>>>> (read more here: http://jamesladdcode.com/?p=323) > >>>>> > >>>>> I'm wanting to port every single class over time, but initially > enough to get the > >>>>> compiler working and have a minimum runtime. > >>>>> > >>>>> Of the 1600+/- classes which are those necessary to make a small > workable compiler > >>>>> and runtime environment? > >>> > >>> Hi, James - > >>> > >>> Bert Freudenberg forwarded this along to me, as I'm not on a Pharo > mailing list. > >>> > >>> I think you know of my JSqueak project (a.k.a. Potato) -- a Squeak VM > written in Java. The image that I used with it, is the same that I always > use for this kind of experiment -- mini.image built in Squeak 2.2. > >>> > >>> The reason it is so cool is that it includes browser, editor, compiler, > inspector debugger, and files -- everything you need for self-support. Plus > it has the decompiler, and special temp-name hack, so you can actually > browse sources with temp names before any file system works. My favorite > thing about this image is that although it is only 600k, if you decompile > all its sources, it comprises over 850k of Smalltalk, so it's like a > compressed version of the sources with a full-function IDE thrown in for > free ;-). > >>> > >>> As I said, the image is about 600k, of which 240k is code -- 202 > classes (x2 if you count the metas) with 4590 methods. This should be a > good guide for you in choosing classes to start with. > >>> > >>> You can actually run this image live in JSqueak on the web if you have > Java installed and the planets are aligned correctly... > >>> http://Weather-dimensions.com/Dan/JSqueak.jnlp > >>> Another interesting statistic is that the Java .jar file is only 433k, > including not only the VM, but also the entire image! This is possible > because the image is so small that the pointers in it are mostly zeroes, so > it compresses nicely. I just checked that this runs, and was happy to see > that it putts along at 21 million bytecodes/sec on my laptop. > >>> > >>> I haven't looked recently, but I think you'll find Mini2.2.image or > something like it in the same place where all the historical releases of > Squeak are kept. Let me know if you can't find it. > >>> > >>> Have fun with your project! I hope this helps > >>> > >>> - Dan > >>> _______________________________________________ > >>> 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 >

April 7, 2010

Re: [Pharo-project] Redline Smalltalk

by Mariano Martinez Peck

> > Are you aware of the work I did that enables class fault detection in > Squeak? > > If a class has a nil methodDictionary, it causes a fault (ie it sends > recoverFromMDFault to the class). That code then restores the MD in > addition to any anyalysis you want. I never cleaned it up for posterity, but > it enabled lots of interesting work... > > By nilling all but a few MDs, and then running some application, you > could > tell exactly what classes were needed and which were not. > See the method discoverActiveClasses. > A special feature even recorded the call stack that caused each > class to be > touched. > What I was doing was restructuring the entire system as a bunch of > image segments that could be swapped out and brought in > on demand -- a sort of user-programmable swapping memory. > This all worked at one point. Swapping of projects was a bit > flakier > because of our weak discipline on pointer scope, but it > even worked in many cases. > > Where I was going with the whole "reorganizeEverything" project was that > the SystemDictionary would be partitioned into many separate dictionaries in > each project, and that namespaces would be the same as the project swapping > unit, and the whole thing would be simple and fast. It actually worked once > (;-) also. > > Loom was cool, but it could never come close to the speed of imageSegments. > I played around with swapping out the entire VM Support category with all > classes and methods, and it would swap in the entirety in less than 200 > milliseconds, and this was a decade ago. > > Sorry for the long digression, but maybe some of this thinking or even the > actual mechanism can be of use to your experiments. > > Hi Dan. First let me say that it is really cool to have you in the list :) Yes, I know about that MD faults and I did some experiments with it. As part of my work, I remove that from core and I put it in a separate package. I also rewrite some things a little. I invite you, if you want/have time to look at it. It is in http://www.squeaksource.com/ClaseUseDiscovery You can see the class comments of CUDClassesUseDiscoverer and also the CUDClassesUseDiscovererTest This tool is working perfect. I sent an email some weeks ago: http://n4.nabble.com/ANN-ClaseUseDiscovery-tool-td1296859.html#a1296861 Now, my conclusions were that it is a great tool but it has the problem that when ever you do a Smalltalk allClassesDo or similar, it brings all the classes back. I saw there was the *gentlly* so that you could do allClassesDoGently etc and the gently checks for isInMemory, where in ImageSegmentRootStub answers false. The problem is that you have to put those gently everywhere and once you forget about that....you are dead. The other problem is the gradunalirity. I mean, even when sending a simple message to a single object of a class, the whole class is loaded. Even with all that, it was great to see and have in mind a percentage of the used classes against different scenarios. Cheers Mariano > - Dan > > > > >> James Ladd <james_ladd(a)hotmail.com> wrote... > >>>> Hi Pharo-ites, > >>>> > >>>> I'm working on a port of Pharo to the Java Virtual Machine called > Redline Smalltalk. > >>>> (read more here: http://jamesladdcode.com/?p=323) > >>>> > >>>> I'm wanting to port every single class over time, but initially enough > to get the > >>>> compiler working and have a minimum runtime. > >>>> > >>>> Of the 1600+/- classes which are those necessary to make a small > workable compiler > >>>> and runtime environment? > >> > >> Hi, James - > >> > >> Bert Freudenberg forwarded this along to me, as I'm not on a Pharo > mailing list. > >> > >> I think you know of my JSqueak project (a.k.a. Potato) -- a Squeak VM > written in Java. The image that I used with it, is the same that I always > use for this kind of experiment -- mini.image built in Squeak 2.2. > >> > >> The reason it is so cool is that it includes browser, editor, compiler, > inspector debugger, and files -- everything you need for self-support. Plus > it has the decompiler, and special temp-name hack, so you can actually > browse sources with temp names before any file system works. My favorite > thing about this image is that although it is only 600k, if you decompile > all its sources, it comprises over 850k of Smalltalk, so it's like a > compressed version of the sources with a full-function IDE thrown in for > free ;-). > >> > >> As I said, the image is about 600k, of which 240k is code -- 202 classes > (x2 if you count the metas) with 4590 methods. This should be a good guide > for you in choosing classes to start with. > >> > >> You can actually run this image live in JSqueak on the web if you have > Java installed and the planets are aligned correctly... > >> http://Weather-dimensions.com/Dan/JSqueak.jnlp > >> Another interesting statistic is that the Java .jar file is only 433k, > including not only the VM, but also the entire image! This is possible > because the image is so small that the pointers in it are mostly zeroes, so > it compresses nicely. I just checked that this runs, and was happy to see > that it putts along at 21 million bytecodes/sec on my laptop. > > > > >> I haven't looked recently, but I think you'll find Mini2.2.image or > something like it in the same place where all the historical releases of > Squeak are kept. Let me know if you can't find it. > >> > >> Have fun with your project! I hope this helps > >> > >> - Dan > >> _______________________________________________ > >> 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 >

April 7, 2010