- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Unwind error during termination

by btc＠openinworld.com

Oct. 24, 2013

Re: [Pharo-dev] Startup Preferences: An Alternative

by Igor Stasenko

On 23 October 2013 20:21, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > This is really cool, is that in the image already ? > What about plain HTTP repos ? > > indeed, what could be simpler than: Compiler evaluate: (ZnEasy get: 'http://my.url.with.script.st') and you can, of course place it on github, if you need version control, like: https://raw.github.com/pharo-project/pharo-vm/master/codegen-scripts/LoadVM… > On 23 Oct 2013, at 20:04, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > philippeback wrote > >> Would be great to have a logout, in order to give images to other people > >> without leaving credentials around. > > > > Done, added to world menu under the individual repo login options > > > > The way the logins work is that a file named .mcconfig is expected in the > > general preferences folder with the format: > > > > [squeaksource] > > user := 'me'. > > password := 'pwd'. > > [squeaksource3] > > user := 'me'. > > password = 'pwd'. > > [smalltalkhub] > > user := 'me'. > > password := 'pwd'. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Startup-Preferences-An-Alternative-tp4713968p4716686.… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > -- Best regards, Igor Stasenko.

Oct. 24, 2013

Re: [Pharo-dev] VM for Athens Graphics

by Igor Stasenko

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. >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. 23, 2013

Re: [Pharo-dev] VM for Athens Graphics

by StÃ©phane Ducasse

> > > 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. > 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? stef

Oct. 23, 2013

Re: [Pharo-dev] VM for Athens Graphics

by StÃ©phane Ducasse

>> > > Igor it also means that we should find a way to get nativeboost wroking on iPad (probably by generating a "DLL" from NB). > > aha.. and digitally sign it before you can use it.. and then ask nicely Apple to approve it :) Yes :)

Oct. 23, 2013