On 27 May 2012 23:32, Tudor Girba wrote:
> "To utilize feedback, you first have to acquire it."
:)
--
Best regards,
Igor Stasenko.
Hi,
Thanks, Igor. Indeed, something is strange. And indeed, you were obviously
right about not building the morph inside the addDeferredUIMessage block. It's
published now.
I built a test to show the behavior. It does not rely on a Glamour mechanism,
but it does use the GLMWatcherWindow. Perha
On 27 May 2012 21:23, Mariano Martinez Peck wrote:
>
>
>
>> Fuel works out of the box in Pharo from 1.1 up to 2.0 (checked at
>> #20094). Please check our documentation [2] for complete installation
>> and use guides
>
>
>
> Martin told me something by private email that I think is worth to mentio
On Sun, May 27, 2012 at 12:58 PM, p...@highoctane.be wrote:
> Yes, very interesting, motivating, and results producing!
>
> Thanks a ton for making it a reality.
>
> Two blog posts of mine just in case you are interested:
>
> http://philippeback.be/2012/05/first-day-of-pharoconf-in-lille/
> http:/
On 27 May 2012 21:04, Mariano Martinez Peck wrote:
>
>> >> >> So questions:
>> >> >> Is ProtoObject should implement #class?
>> >> >> Can we move #class method from Object to ProtoObject?
>> >> >>
>> >> >
>> >> > upsgood catch! indeed, we should move it to ProtoObject.
>> >> >
>> >> mm.. why?
thanks Sven.
I have nearly finish to read the zinc chapter. Great contents. I would like to
create diagram and others for the book version but no time right now.
Stef
On May 27, 2012, at 7:34 PM, Sven Van Caekenberghe wrote:
> Hi,
>
>
> Now that I have recovered from the intensive Pharo Confer
Fuel works out of the box in Pharo from 1.1 up to 2.0 (checked at
> #20094). Please check our documentation [2] for complete installation
> and use guides
Martin told me something by private email that I think is worth to mention.
Not sure if you read it carefully, but Fuel is working from Pharo
> >> >> So questions:
> >> >> Is ProtoObject should implement #class?
> >> >> Can we move #class method from Object to ProtoObject?
> >> >>
> >> >
> >> > upsgood catch! indeed, we should move it to ProtoObject.
> >> >
> >> mm.. why?
> >
> >
> > Because ALL objects do have a class. Right? if you
On 27 May 2012 19:16, Stéphane Ducasse wrote:
>>>
>>>
hi, i just discovered that Halt signals the exception as unhandled one..
which, in own turn makes announcers who using on:fork: to _fork_ the
process,
so when debugger opens you don't see who sent the announcement sinc
Hi,
Now that I have recovered from the intensive Pharo Conference, I found the time
to publish the Zinc and Zodiac documentation.
The two main websites have been updated:
http://zn.stfx.eu
http://zdc.stfx.eu
My slides are here
http://zn.stfx.eu/zn/zn-talk-pharo-confer
>>
>>
>>> hi, i just discovered that Halt signals the exception as unhandled one..
>>>
>>> which, in own turn makes announcers who using on:fork: to _fork_ the
>>> process,
>>> so when debugger opens you don't see who sent the announcement since
>>> the bottom stack frame is #on:fork:
>>
>> Ex
Ok I got it and we agree :)
>> hi, i just discovered that Halt signals the exception as unhandled one..
>>
>> which, in own turn makes announcers who using on:fork: to _fork_ the process,
>> so when debugger opens you don't see who sent the announcement since
>> the bottom stack frame is #on:fork
On 27 May 2012 18:18, Stéphane Ducasse wrote:
>
>
>> hi, i just discovered that Halt signals the exception as unhandled one..
>>
>> which, in own turn makes announcers who using on:fork: to _fork_ the process,
>> so when debugger opens you don't see who sent the announcement since
>> the bottom st
On 27 May 2012 14:46, Mariano Martinez Peck wrote:
>
>
> On Sun, May 27, 2012 at 2:31 PM, Igor Stasenko wrote:
>>
>> On 27 May 2012 11:40, Mariano Martinez Peck wrote:
>> >
>> >
>> > On Sun, May 27, 2012 at 11:02 AM, Denis Kudriashov
>> >
>> > wrote:
>> >>
>> >> I found problem.
>> >>
>> >> Pro
> +1
>
> And thanks to all involved in the conf. I hope that some years in the future
> I can say "I was present in the first PharoConf!" :)
well the second :)
The first was organized at Annecy by laurent laffont and herve Verjus. But it
was less international :)
i think there is some mistake in event wiring..
i cannot tell much, because i don't understand the glamour models..
but what i found strange is that i get large pause before i got halt in
actOnMatchingPresentationsChanged:
it looks like the same event goes twice (or there two kinds of events)
an
> hi, i just discovered that Halt signals the exception as unhandled one..
>
> which, in own turn makes announcers who using on:fork: to _fork_ the process,
> so when debugger opens you don't see who sent the announcement since
> the bottom stack frame is #on:fork:
Excellent this would also exp
On Sun, May 27, 2012 at 6:01 PM, Igor Stasenko wrote:
> On 27 May 2012 12:58, p...@highoctane.be wrote:
> > Yes, very interesting, motivating, and results producing!
> >
> > Thanks a ton for making it a reality.
> >
> > Two blog posts of mine just in case you are interested:
> >
> > http://phili
> More than that, since CompiledMethod redefines #=, it is strange that
> it's not redefines #hash as well,
> because it is one of requirements to make sure they are always in sync.
>
>
indeed!
>
> > Two conclusions:
> >
> > The solution is to define CompiledMethod>hash such that it does not
> ac
excellent!
I love milestones (metacello) just for that.
On May 27, 2012, at 5:25 PM, Denis Kudriashov wrote:
> Ok.
>
> Now I just fix SMock by adding #class method.
> And I publish new ConfigurationOfMocketry to
> squeaksource/MetacelloRepository.
> All tests green
>
On 27 May 2012 12:58, p...@highoctane.be wrote:
> Yes, very interesting, motivating, and results producing!
>
> Thanks a ton for making it a reality.
>
> Two blog posts of mine just in case you are interested:
>
> http://philippeback.be/2012/05/first-day-of-pharoconf-in-lille/
> http://philippebac
hi, i just discovered that Halt signals the exception as unhandled one..
which, in own turn makes announcers who using on:fork: to _fork_ the process,
so when debugger opens you don't see who sent the announcement since
the bottom stack frame is #on:fork:
Now if you change
Halt>>defaultAction
Ok.
Now I just fix SMock by adding #class method.
And I publish new ConfigurationOfMocketry to
squeaksource/MetacelloRepository.
All tests green
>>
>>>
>>>
>>> I can hardly see what else can replace a tree/graph-like data
>>> organization.
>>>
>>
>> Something entirely unexpected that no one saw coming, no doubt :)
>>
>> e.g. what does the "current working directory" mean in a system with
>> orthogonal persistence?
>>
> probably nothi
On 27 May 2012 15:04, Douglas Brebner wrote:
> On 26/05/2012 23:08, Igor Stasenko wrote:
>>
>>
>> I can hardly see what else can replace a tree/graph-like data
>> organization.
>>
>
> Something entirely unexpected that no one saw coming, no doubt :)
>
> e.g. what does the "current working director
On Sun, May 27, 2012 at 3:06 PM, Douglas Brebner <
squeakli...@fang.demon.co.uk> wrote:
> On 27/05/2012 13:46, Mariano Martinez Peck wrote:
>
>>
>> Because ALL objects do have a class. Right?
>>
>
> Wasn't one of the reasons for ProtoObject to enable building non-class
> (e.g. prototype) object sy
On 27/05/2012 13:46, Mariano Martinez Peck wrote:
Because ALL objects do have a class. Right?
Wasn't one of the reasons for ProtoObject to enable building non-class
(e.g. prototype) object systems?
On 26/05/2012 23:08, Igor Stasenko wrote:
I can hardly see what else can replace a tree/graph-like data organization.
Something entirely unexpected that no one saw coming, no doubt :)
e.g. what does the "current working directory" mean in a system with
orthogonal persistence?
On Sun, May 27, 2012 at 2:31 PM, Igor Stasenko wrote:
> On 27 May 2012 11:40, Mariano Martinez Peck wrote:
> >
> >
> > On Sun, May 27, 2012 at 11:02 AM, Denis Kudriashov >
> > wrote:
> >>
> >> I found problem.
> >>
> >> Proxy classes in SMock and Mocketry are subclasses of ProtoObject which
> >
On 27 May 2012 11:40, Mariano Martinez Peck wrote:
>
>
> On Sun, May 27, 2012 at 11:02 AM, Denis Kudriashov
> wrote:
>>
>> I found problem.
>>
>> Proxy classes in SMock and Mocketry are subclasses of ProtoObject which
>> not implements #class.
>> But proxy classes use "self class" in some methods
Yes, it was really nice. Thanks for such a good atmosphere!
I regret I was unable to be there on Friday.
Of course, I hope to see you all at ESUG in Gent! ;-)
Johan (sent from my mobile)
On 27 May 2012, at 12:58, "p...@highoctane.be" wrote:
> Yes, very interesting, motivating, and results p
http://openendedgroup.com/field/OverviewBanners2.html
--
Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the
(almost) complete and compleate beginner).
https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all
Yes, very interesting, motivating, and results producing!
Thanks a ton for making it a reality.
Two blog posts of mine just in case you are interested:
http://philippeback.be/2012/05/first-day-of-pharoconf-in-lille/
http://philippeback.be/2012/05/second-day-at-pharoconf-in-lille/
Thanks again!
Yes,
was fun to see a lot of you. And I could add some new faces to my inventory.
Great!
Norbert
Am 27.05.2012 um 00:12 schrieb Tudor Girba:
> Hi,
>
> I had a good time at PharoConf.
>
> Thanks for organizing it.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
>
> "Beauty is where we se
On 27 May 2012 11:02, Denis Kudriashov wrote:
>
> I add #class implementation from Object to ProtoObject and all SMock and
> Mocketry tests become green.
>
Yes, that fixes any problems I can think of with it.
Otherwise #class ends up in #doesNotUnderstand which is special for proxy
objects...
On Sun, May 27, 2012 at 11:02 AM, Denis Kudriashov wrote:
> I found problem.
>
> Proxy classes in SMock and Mocketry are subclasses of ProtoObject which
> not implements #class.
> But proxy classes use "self class" in some methods (like #printOn:
> implementation).
>
> I add #class implementation
yes! thanks!!!
Cheers
Alain
Le 27/05/12 00:12, Tudor Girba a écrit :
Hi,
I had a good time at PharoConf.
Thanks for organizing it.
Cheers,
Doru
--
www.tudorgirba.com
"Beauty is where we see it."
I found problem.
Proxy classes in SMock and Mocketry are subclasses of ProtoObject which not
implements #class.
But proxy classes use "self class" in some methods (like #printOn:
implementation).
I add #class implementation from Object to ProtoObject and all SMock and
Mocketry tests become green.
Yes, thanks to organizers and every participants for all of this positive
energy!
#Luc
2012/5/27 Sven Van Caekenberghe
> +1
>
> On 27 May 2012, at 00:12, Tudor Girba wrote:
>
> > Hi,
> >
> > I had a good time at PharoConf.
> >
> > Thanks for organizing it.
> >
> > Cheers,
> > Doru
> >
> >
> >
> > no, the other way around, now #class is NOT bytecoded, and therefore is
> > managed as a normal message send.
> >
> > That is much better. Thanks! I like progress even if it breaks old code.
>
> :)
> But we always try to minimize else we would go much faster and btw class
> should not break
Hello
2012/5/26 Milan Mimica
> On 26 May 2012 20:53, Stéphane Ducasse wrote:
>
>> >
>> > What has changed in implementation "class" message in between Pharo 1.3
>> and 1.4? Is it compiled inline now or something like that?
>> >
>> > no, the other way around, now #class is NOT bytecoded, and the
+1
On 27 May 2012, at 00:12, Tudor Girba wrote:
> Hi,
>
> I had a good time at PharoConf.
>
> Thanks for organizing it.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
>
> "Beauty is where we see it."
I liked it a lot as well: interesting content, interesting people, motivational.
Thx,
42 matches
Mail list logo
