October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Some very rough benchmarks on text rendering

by phil＠highoctane.be

Very cool indeed. The days of fearing to click on large methods due to looong rendering times are numbered (e.g. Seaside FileLibrary uploaded files... like jQuery or images). PluggableTextMorph does a hell of a lot of twisted things, I guess we'll get much improved understandability as well with the Tx things. Kepp up the good work, it is much appreciated! Phil On Thu, Oct 24, 2013 at 8:41 AM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > Awesome ! > > I'd love to have that in the image and use it for my everyday dev. > Great work Igor please finish it so we can use it :) > > > 2013/10/24 Igor Stasenko <siguctua(a)gmail.com> > >> As a followup on discussion about improving/benching text stuff. >> Just out of curiosity, wanted to compare how sloooow athens with cairo >> comparing to good old bitblt in terms of displaying text. >> >> See for yourselves. >> Sure comparison is very rough (text are different >> - in athens i using freetype font, in workspace is raster font) >> but at least both windows displaying same amount of text. >> (that i think what is relevant to us, humans ;) ) >> And, of course, to make things more precise need to write more code to >> make sure >> it renders exact contents of the text morph fully without any clipping, >> in both cases). >> And frankly, i am not in a mood of making/coding precise benchmark now. :) >> >> Why i posting this, is mainly because i am quite surprised by numbers. >> i expected opposite proportion.. >> >> And i still almost didn't optimized things. >> >> [image: Inline images 2][image: Inline images 1] >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Oct. 24, 2013

Re: [Pharo-dev] Issue #11876 (Do not allow shouldnt:raise: Error) and Seaside dev. on Pharo 3.0

by Johan Brichau

On 24 Oct 2013, at 08:05, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 23 Oct 2013, at 23:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >>> Hi, >>> >>> just as info: looks like already fixed Pharo issue #11876 makes problem for Seaside in 3.0: >>> >>> http://lists.squeakfoundation.org/pipermail/seaside-dev/2013-October/005509… >>> http://lists.squeakfoundation.org/pipermail/seaside-dev/2013-October/005540… >> >> >> It would be a bit sad that Seaside does not work in Pharo3.0 >> I imagine that Philippe is tired. >> >> I would revert the change and add a rule that check that the argument of shouldnt:raise: should not be an Error >> > > yes, people are not willing to change code all the timeâ¦ we should do things like that in rules first and only later > hard errors. + 1

Oct. 24, 2013

Re: [Pharo-dev] Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

by Sven Van Caekenberghe

While I agree that we shouldnât unnecessary make life more difficult for external frameworks/libraries when that can be avoided, we do have to reserve the right to be able to make changes that break things. Like with #includesSubstring: the actual intention of the change is valid and sound, but the process could have been smoother. Issue 11876 does have a point and it does simplify the system, IMHO. On 24 Oct 2013, at 08:17, Philippe Marschall <philippe.marschall(a)netcetera.ch> wrote: > On 22.10.13 00:08, Camillo Bruni wrote: >> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 >> it looks unsuspicous until the moment you try understand such a failing assertion. > > This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way. > > This only adds code who's sole purpose is to break people's existing code. > > If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule. > > Cheers > Philippe > >

Oct. 24, 2013

Re: [Pharo-dev] Unwind error during termination

by ClÃ©ment Bera

Ok I have the error too. Strangely enough, the error is triggered because the third BlockClosure>>#on:do: context has 2 temporaries instead of 3. Igor / Esteban do you have a clue ? Why a context would have less temporaries than expected ? Problem from context creation out of the stack ? I will try to find some time to look at this problem. Though it is not an easy one it will take some time to be fixed. 2013/10/24 <btc(a)openinworld.com> > ** > ClÃ©ment Bera wrote: > > Hello, > > I'm interested. > > Please send me the image in private mail not to overload the mailing list > with large attachment. > Alternatively, give me a place where I can download it. > > > http://files.openinworld.com/Pharo/PharoLauncher-Unwind-Error.zip > > The steps to reproduce are: open the image, execute 1halt, close debugger ? > > > There are three debuggers already open. Just close them. The third > close generates the error. > A confounding factor may be your running this on a different VM. This is > mine... > > http://files.openinworld.com/Pharo/PharoLauncher-Unwind-Error-VM.zip > > Win32 built on Mar 13 2013 18:49:42 Compiler: 4.6.2 > VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: > 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> <estebanlm(a)gmail.com> Jenkins > build #14535 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > The error still occurs if I try the image on the latest VM, but then again > the effect may already be in effect. > > btw, Its not directly causing me pain since I can continue in the image, > but still thanks for checking it out for general improvements. > > cheers -ben > > Best, > > > > 2013/10/22 <btc(a)openinworld.com> <btc(a)openinworld.com> > > ** > For a while now, every now and then when closing a debugger I have been > getting an "Unwind error during termination" > > > > I happened to have saved the image moments before it just occurred again. > From opening that save error can be reliably triggered in three clicks. > I can provide this image if anyone is interested in it. > > cheers -ben > > > > >

Oct. 24, 2013

Re: [Pharo-dev] Some very rough benchmarks on text rendering

by ClÃ©ment Bera

Awesome ! I'd love to have that in the image and use it for my everyday dev. Great work Igor please finish it so we can use it :) 2013/10/24 Igor Stasenko <siguctua(a)gmail.com> > As a followup on discussion about improving/benching text stuff. > Just out of curiosity, wanted to compare how sloooow athens with cairo > comparing to good old bitblt in terms of displaying text. > > See for yourselves. > Sure comparison is very rough (text are different > - in athens i using freetype font, in workspace is raster font) > but at least both windows displaying same amount of text. > (that i think what is relevant to us, humans ;) ) > And, of course, to make things more precise need to write more code to > make sure > it renders exact contents of the text morph fully without any clipping, in > both cases). > And frankly, i am not in a mood of making/coding precise benchmark now. :) > > Why i posting this, is mainly because i am quite surprised by numbers. > i expected opposite proportion.. > > And i still almost didn't optimized things. > > [image: Inline images 2][image: Inline images 1] > > -- > Best regards, > Igor Stasenko. >

Oct. 24, 2013

Re: [Pharo-dev] VM for Athens Graphics

by Norbert Hartl

> Am 23.10.2013 um 23:28 schrieb Igor Stasenko <siguctua(a)gmail.com>: > > > > >> On 23 October 2013 23:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> Well implementing ARM-FFI is largely orthogonal to Athens. >>> Yes, i am happily using it for Cairo and it lets me customize /rethink things as they go >>> without need to touch VM. Which means much faster development process and feedback etc. >>> But since Athens API is settled down more or less, now it is quite possible to implement a plugin >>> for different backend, knowing that it won't require huge changes later. >> >> Ok I was not aware you were thinking about that. So this is good to have this path in my radar. > Yes, this is actually what we discussed recently with Esteban about possible alternatives and > low-hanging fruits :) > >>> Concerning ARM: >>> - Damien Pollet works on ARM assembler for ASMJit. >>> as soon as it working, we can try doing something with it. >>> >>> But in addition, what i would like to do is to move more towards platform-neutral FFI implementation, >>> using low-level assembler DSL which is platform neutral. There's a work started on it >>> as part of Mate project, but it is yet far from finished. >> >> I would love that. >> Now I guess that I'm correct to say that even with it the fact that it would generate assembly on the fly >> would make it a no go for iPad and friends. >> >> I thought that esteban and you thought about generating the "assembly once for all for Ipda and putting it in file" >> so that we do not have the "assembly generation" problem? > that's a big question, whether such idea fits into apple technicians/politicans heads or not. > Do you think we have enough time/resources to waste on implementing such mechanism > only to discover later that Apple says 'over my dead body'? > The point is that generating code, saving it to file, and then loading that file as DLL, > is largely a hack. > You either allowed to run your own generated code or not.. because from security perspective, > the fact that you first stored it into file and then load it back doesn't changes a tiny bit. You store the code in a file in order to rip off the code generation part from your image. That would make it comply to apples policies. Same goes for the compiler. You are also not allowed to download a library and use it in your program. I think the plot is that apps get examined before they are allowed to be in the appstore. Changing the runtime would break this certification of the binary and apple would loose control because everybody would add a clean binary to the examination process and then they would load everything else when the user opens the app for the first time. So there is some sense in this. It is just a different way of thinking that we find annoying. Norbert > From design perspective, it is crutch, which don't really buys anything (why on earth, anyone would want to deal with files > and OS, if he could just run code which already in memory?). >

Oct. 24, 2013

Re: [Pharo-dev] Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

by Philippe Marschall

On 22.10.13 00:08, Camillo Bruni wrote: > see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 > it looks unsuspicous until the moment you try understand such a failing assertion. This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way. This only adds code who's sole purpose is to break people's existing code. If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule. Cheers Philippe

Oct. 24, 2013

Re: [Pharo-dev] Issue #11876 (Do not allow shouldnt:raise: Error) and Seaside dev. on Pharo 3.0

by Marcus Denker

On 23 Oct 2013, at 23:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi, >> >> just as info: looks like already fixed Pharo issue #11876 makes problem for Seaside in 3.0: >> >> http://lists.squeakfoundation.org/pipermail/seaside-dev/2013-October/005509… >> http://lists.squeakfoundation.org/pipermail/seaside-dev/2013-October/005540… > > > It would be a bit sad that Seaside does not work in Pharo3.0 > I imagine that Philippe is tired. > > I would revert the change and add a rule that check that the argument of shouldnt:raise: should not be an Error > yes, people are not willing to change code all the timeâ¦ we should do things like that in rules first and only later hard errors. Marcus

Oct. 24, 2013

Re: [Pharo-dev] How is this possible?

by Marcus Denker

On 24 Oct 2013, at 07:12, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> I will >> -> commit an update where the code moves the temps to the method >> -> then fix the compiler next week > > Are there issues for these? I want to track the status because the TWM port > to 3.0 is on hold until it's fixed... > > I did the workaround literally within hoursâ¦ so this is closed already. I donât remember if I put an issue for the second, but there is a TODO on my list "In Bug Tracker: bug temps in ifTrue:â which is the next on the listâ¦ I did not dare to fix it with the Opal RegressionTester crashing the VM, which I fixed yesterday. Marcus

Oct. 24, 2013

Some very rough benchmarks on text rendering

by Igor Stasenko

As a followup on discussion about improving/benching text stuff. Just out of curiosity, wanted to compare how sloooow athens with cairo comparing to good old bitblt in terms of displaying text. See for yourselves. Sure comparison is very rough (text are different - in athens i using freetype font, in workspace is raster font) but at least both windows displaying same amount of text. (that i think what is relevant to us, humans ;) ) And, of course, to make things more precise need to write more code to make sure it renders exact contents of the text morph fully without any clipping, in both cases). And frankly, i am not in a mood of making/coding precise benchmark now. :) Why i posting this, is mainly because i am quite surprised by numbers. i expected opposite proportion.. And i still almost didn't optimized things. [image: Inline images 2][image: Inline images 1] -- Best regards, Igor Stasenko.

Oct. 24, 2013