- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 10bbe9: 30516

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 10bbe99db39f5f25348dc1c9b74dd9755f1da1fc https://github.com/pharo-project/pharo-core/commit/10bbe99db39f5f25348dc1c9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-22 (Tue, 22 Oct 2013) Changed paths: M OpalCompiler-Core.package/extension/TBehavior/instance/compileAllFrom_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script171.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30516.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Traits.package/TBehavior.class/instance/accessing method dictionary/localSelectors.st A Traits.package/TBehavior.class/instance/accessing method dictionary/localSelectorsDo_.st Log Message: ----------- 30516 11694 Trait methods wrong after recompiling the image https://pharo.fogbugz.com/f/cases/11694 http://files.pharo.org/image/30/30516.zip

Oct. 23, 2013

Re: [Pharo-dev] [update 3.0] #30516

by Marcus Denker

On Oct 23, 2013, at 8:22 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Marcus, > > The update mails from 30511 - 30515 seem to be missing, or is it just me ? > Is there another place to see the same information ? > Yes, the commit mail from Git. Normally I don't send this mail anymore. > > On 23 Oct 2013, at 08:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> 30516 >> ----- >> >> 11694 Trait methods wrong after recompiling the image >> https://pharo.fogbugz.com/f/cases/11694 >> >> Diff information: >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-MarcusDenker.584.diff >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… >> > >

Oct. 23, 2013

Re: [Pharo-dev] [update 3.0] #30516

by Sven Van Caekenberghe

Marcus, The update mails from 30511 - 30515 seem to be missing, or is it just me ? Is there another place to see the same information ? Sven On 23 Oct 2013, at 08:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30516 > ----- > > 11694 Trait methods wrong after recompiling the image > https://pharo.fogbugz.com/f/cases/11694 > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-MarcusDenker.584.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… >

Oct. 23, 2013

[update 3.0] #30516

by Marcus Denker

30516 ----- 11694 Trait methods wrong after recompiling the image https://pharo.fogbugz.com/f/cases/11694 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-MarcusDenker.584.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke…

Oct. 23, 2013

Re: [Pharo-dev] VM for Athens Graphics

by J.F. Rick

On Tue, Oct 22, 2013 at 7:37 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > The latest Pharo vms for all 3 major platforms support Athens with Cairo > as backend. > It is our starting point, one day we might choose to have different > backend(s), like opengl etc. > Excellent. I'm mainly using Linux. > For the ipad , best would be to implement a quartz backend for athens. > As a temporary solution we could try to compile cairo library for it, but > i am not expert in iOS > to say if it can be done without much fuss. > Also, since iOS is famous for banning any applications which using > generated code, > that means it should be done by writing a VM plugin and then adopting new > primitives to > work with Athens API. > While I would love to use such a thing on iOS, I'm afraid that VM making is beyond me. That said, if somebody does it, I do have a few multi-touch tools, such as a keyboard, that I'd be willing to port to it. Increasingly, touch based machines are going to replace mouse based machines as the dominant paradigm. If we can create a great development environment for touch, we'd have a good chance to really invent the future. Graphic processor accelerated graphics are part of that. A rewrite of the events infrastructure, both to simply the current mess and to add touch support, is part of that. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Oct. 23, 2013

Re: [Pharo-dev] i wish i could live in a world...

by David T. Lewis

On Wed, Oct 23, 2013 at 03:00:54AM +0200, Igor Stasenko wrote: > where morphs has position relative to their owner morph. > and laying out morphs or composing them into complex layout easy > and event handling is easy .. > and things are properly documented > :) > I'm not sure where this project stands, but Juan is working with coordinate systems for a morphic replacement. For clarity of code and documentation, his work is second to none. I think that if the two of you ever did some collaborative development, the results might be scary good :-) http://www.jvuletich.org/Morphic3/Morphic3-200911.html Dave

Oct. 23, 2013

i wish i could live in a world...

by Igor Stasenko

where morphs has position relative to their owner morph. and laying out morphs or composing them into complex layout easy and event handling is easy .. and things are properly documented :) -- Best regards, Igor Stasenko.

Oct. 23, 2013

Re: [Pharo-dev] Error-eating troll

by Igor Stasenko

ok. problem solved.. it is because my override triggers flushing full bounds to nil.. :) On 23 October 2013 01:10, Igor Stasenko <siguctua(a)gmail.com> wrote: > oh wait, apparently i am wrong.. > now i even more confused, why my morph fails to compute bounds at the > beginning :) > > > On 23 October 2013 01:07, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> I got quite confused, why i got error in strange place, >> the culprit is this one: >> >> >> computeFullBounds >> [ self doLayoutIn: self layoutBounds ] >> on: Error >> do: [ :ex | >> "This should do it unless you don't screw up the bounds" >> fullBounds := bounds. >> ex pass ] >> >> used by this: >> >> fullBounds >> "Return the bounding box of the receiver and all its children. >> Recompute the layout if necessary." >> >> fullBounds ifNotNil: [ ^ fullBounds ]. "Errors at this point can >> be critical so make sure we catch 'em all right" >> self computeFullBounds. "This should do it unless you don't screw >> up the bounds" >> ^ fullBounds >> >> So, if error happens, it leaves fullBounds==nil and as result, >> any code which follows, tries to do something with that nil.. >> Sure thing it is much more fun figuring out why your morph is broken >> and where, when such nasty code hides errors. >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Oct. 22, 2013

Re: [Pharo-dev] Error-eating troll

by Igor Stasenko

oh wait, apparently i am wrong.. now i even more confused, why my morph fails to compute bounds at the beginning :) On 23 October 2013 01:07, Igor Stasenko <siguctua(a)gmail.com> wrote: > I got quite confused, why i got error in strange place, > the culprit is this one: > > > computeFullBounds > [ self doLayoutIn: self layoutBounds ] > on: Error > do: [ :ex | > "This should do it unless you don't screw up the bounds" > fullBounds := bounds. > ex pass ] > > used by this: > > fullBounds > "Return the bounding box of the receiver and all its children. > Recompute the layout if necessary." > > fullBounds ifNotNil: [ ^ fullBounds ]. "Errors at this point can be > critical so make sure we catch 'em all right" > self computeFullBounds. "This should do it unless you don't screw > up the bounds" > ^ fullBounds > > So, if error happens, it leaves fullBounds==nil and as result, > any code which follows, tries to do something with that nil.. > Sure thing it is much more fun figuring out why your morph is broken > and where, when such nasty code hides errors. > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Oct. 22, 2013

Error-eating troll

by Igor Stasenko

I got quite confused, why i got error in strange place, the culprit is this one: computeFullBounds [ self doLayoutIn: self layoutBounds ] on: Error do: [ :ex | "This should do it unless you don't screw up the bounds" fullBounds := bounds. ex pass ] used by this: fullBounds "Return the bounding box of the receiver and all its children. Recompute the layout if necessary." fullBounds ifNotNil: [ ^ fullBounds ]. "Errors at this point can be critical so make sure we catch 'em all right" self computeFullBounds. "This should do it unless you don't screw up the bounds" ^ fullBounds So, if error happens, it leaves fullBounds==nil and as result, any code which follows, tries to do something with that nil.. Sure thing it is much more fun figuring out why your morph is broken and where, when such nasty code hides errors. -- Best regards, Igor Stasenko.

Oct. 22, 2013