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

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

by Igor Stasenko

On 24 October 2013 14:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > And to save on parenthesis, you could also write > > Compiler evaluate: 'http://my.url.with.script.st' asZnUrl > retrieveContents. > > CodeImporter evaluateString: 'http://my.url.with.script.st' asUrl > retrieveContents. > > this is why i love smalltalk: that you can express highly complex stuff (there's a lot of stuff happens under the hood) by single line expression. Comparing to most examples of C frameworks, where you had to manually allocate buffers, initialize some data structures, and pass several options and flags here and there, which at the end does what you need, but floods your mind with hundreds of tiny irrelevant details.. > With #asUrl and #asZnUrl soon to be 100% the same thing. > > On 24 Oct 2013, at 14:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > you mean: > > > > CodeImporter evaluateString: (ZnEasy get: 'my-url') contents. > > > > :) > > > > On Oct 23, 2013, at 11:17 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> > >> 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. > > > > > -- Best regards, Igor Stasenko.

Oct. 24, 2013

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

by Nicolas Cellier

Note that Squeak is running the display twice with StrikeFont when subPixelRenderColorFonts is enabled, which is far from optimal. See BitBlt>>displayString:from:to:at:strikeFont:kern: and BitBlt>>installStrikeFont:foregroundColor:backgroundColor: 2013/10/24 phil(a)highoctane.be <phil(a)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] Startup Preferences: An Alternative

by Sven Van Caekenberghe

And to save on parenthesis, you could also write Compiler evaluate: 'http://my.url.with.script.st' asZnUrl retrieveContents. CodeImporter evaluateString: 'http://my.url.with.script.st' asUrl retrieveContents. With #asUrl and #asZnUrl soon to be 100% the same thing. On 24 Oct 2013, at 14:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > you mean: > > CodeImporter evaluateString: (ZnEasy get: 'my-url') contents. > > :) > > On Oct 23, 2013, at 11:17 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> 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] Startup Preferences: An Alternative

by Esteban Lorenzano

you mean: CodeImporter evaluateString: (ZnEasy get: 'my-url') contents. :) On Oct 23, 2013, at 11:17 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > 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] Issue #11876 (Do not allow shouldnt:raise: Error) and Seaside dev. on Pharo 3.0

by Sven Van Caekenberghe

On 24 Oct 2013, at 13:55, Torsten Bergmann <astares(a)gmx.de> wrote: > From the comments I think we can agree that it is a better to have a lint rule > instead of breaking things the way it was introduced by the original issue #11876. > > I therefore opened an issue > https://pharo.fogbugz.com/f/cases/11989/shouldnt-raise-Error-from-issue-118… > and uploaded a slice > > SLICE-Issue-11989-shouldntraise-Error-from-issue-11876-is-too-offensive-TorstenBergmann.1 > > to Pharo30Inbox on STHub (http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main) that > removed #validateShouldntException: > > I used a fresh 3.0 image (Pharo3.0 Latest update: #30519) > > Please test so it can be integrated and we can continue to focus on more interesting stuff. With respect to Seaside (and its cross-platform-ness), this is probably a good decision, for now. But it is fundamentally unfair to call this an arbitrary unimportant change meant to annoy people. On the contrary ! I even think that there are too many methods in TAssertable and the #shouldnt: checks are very confusing and are candidates for removal, IMHO. Too much unnecessary code is not good in the long run. Have you ever written a #shouldnt: test ? I have never done so ! I took a Seaside image and looked at the senders of #shouldnt: and friends. There are that many from Seaside and I havenât seen any good example that could not be written otherwise. My 2c. Sven > Thanks > Torsten > > >

Oct. 24, 2013

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

by Torsten Bergmann

Oct. 24, 2013

Re: [Pharo-dev] VM for Athens Graphics

by Igor Stasenko

On 24 October 2013 08:24, Norbert Hartl <norbert(a)hartl.name> wrote: > > > 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. > > The sense is that i'm not changing NativeBoost each time i using it, so i am not "changing the runtime". It is pure fallacy to consider code as something else than just simple data. Sure thing, if i mutate the codebase by loading external code from random source later (and this is what we regularly do with our images) then the contract is broken. But not in case when all my code and i'm not changing it in any way. The fact it using code generation doesn't means it will turn into something else if i don't want to. > 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?). > > -- 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 Norbert Hartl

Am 24.10.2013 um 10:47 schrieb Philippe Marschall <philippe.marschall(a)netcetera.ch>: > On 24.10.13 08:05, Marcus Denker 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 are willing to change the code where there is a clear benefit. For example it's hard to argue that the new filesystem is an improvement over FileDirectory. We have a partically working Spec based UI for the servers. We would happily change the walkback to a new context API should it fix the bugs in the existing one. However this isn't the case with this change. To sole and only purpose of this change is to break code. This is what annoys me. > Personally I think the new filesystem is way better than the old one. Maybe not for seaside that has rather basic usage of it. This change I would consider game changer for pharo that need to happen from time to time. But with arbitrary changes we need to be very careful. There needs to be change because we cannot evolve without. But there is a border where changes are just for the sake of it (hard to justify). And that would turn pharo into _one of those_ open source projects where the only thing that is stable is the number of bugs. Norbert

Oct. 24, 2013

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

by Norbert Hartl

Am 24.10.2013 um 08:05 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > 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 Norbert

Oct. 24, 2013

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

by Philippe Marschall

On 24.10.13 08:05, Marcus Denker 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 are willing to change the code where there is a clear benefit. For example it's hard to argue that the new filesystem is an improvement over FileDirectory. We have a partically working Spec based UI for the servers. We would happily change the walkback to a new context API should it fix the bugs in the existing one. However this isn't the case with this change. To sole and only purpose of this change is to break code. This is what annoys me. Cheers Philippe

Oct. 24, 2013