On Sat, Feb 1, 2014 at 3:25 PM, Pharo4Stef wrote:
> Andreas
>
> did you realise that pools are just static cached version of (simple
> value) returning messages?
>
But they are not. They are combinations of a getter and a setter; pools
are pools of *variables*, not *constants*. So one variabl
On Sat, Feb 1, 2014 at 6:00 AM, Johan Fabry wrote:
>
> On Feb 1, 2014, at 9:32 AM, Sebastian Sastre
> wrote:
>
>
> > It's a half-ass non-solution
> >
> > Do you really love cleaning that up?
>
>
> This half-assed non-solution is the same solution as for Traits,
> essentially. Do you have the
On Feb 1, 2014, at 9:33 PM, Pharo4Stef wrote:
>>
>> So if we cannot break tradition then Traits should never have been
>> introduced?
We can. Innovation has a lot to do with that.
But you have ways to introduce your innovation that will make all the
difference.
iPhone broke all the traditi
Why state 'responded' - would it not be better if the monkey checked the slice,
even though no unit tests will hit the change, it shows at least that nothing
obvious broke.
On 02 Feb 2014, at 09:12, Pharo4Stef wrote:
> I added https://pharo.fogbugz.com/default.asp?12769
> Fix included.
> took
Le 31/01/2014 13:21, Esteban Lorenzano a écrit :
> Said so… I still does not understand why this particular change couldn’t wait
> for pharo 4. But well… now is there, so it needs to work fine.
As long as you don't learn to reject, you will face this situation over
and over. Believe me.
Hilaire
I added https://pharo.fogbugz.com/default.asp?12769
Fix included.
took me less than 10 min including downloading the latest version of Pharo and
scanning complete sources.
Stef
On Feb 1, 2014, at 8:59 PM, Pharo4Stef wrote:
>>> If your students have problems to grasp the concept of pool dictionaries
>>> then how do they deal with mathematics and computer science?
>>
>> Given enough time, no problem. But time in class and outside is limited
>> enough as it is.
>
> N
yes johan you are right again :)
Stef
>> OK, back to topic and to summarize: we now all fully understood that the
>> original message
>> including pools is still there, will not break code loading or other things
>> and that the
>> change is on the Nautilus level.
>
> Yes, thanks for unde
>>
>> There are some kinds of students who are going to find Smalltalk difficult,
>> yes. I do not see how removing pooldictionaries from the class creation
>> template will affect them. If they ask about them, you can say that they are
>> there and point them to the new class creation message
>>
>> If your students have problems to grasp the concept of pool dictionaries
>> then how do they deal with mathematics and computer science?
>
> Given enough time, no problem. But time in class and outside is limited
> enough as it is.
No johan even if I multiply by two the amount of time y
> Hi Stef,
>
>> Now people hear me well: you are ready to hear well. Lower the music
>
> Beside the fact that I like listening to loud music I really lowered it ;)
> But even with silence in the room your response told me nothing new regarding
> the topic discussed.
Then read it again :)
Be
>
> So if we cannot break tradition then Traits should never have been introduced?
indeed :)
without this breaks Java8 would not have them.
And why on earth new invokes initialize this was not like that when I learned
Smalltalk!
Sorry I could not resist.
Stef
Sorry sebastian but you are wrong :) and start to be ready for changes in the
future too or stay with Pharo 2.0
Look at the Pharo Motto.
Stef
On 01 Feb 2014, at 13:32, Sebastian Sastre wrote:
>
>>> How many lectures did you give? It is annoying to have to explain something
>>> that usually p
Andreas
did you realise that pools are just static cached version of (simple value)
returning messages?
>> How many lectures did you give? It is annoying to have to explain something
>> that usually people do not need to know.
> I don’t give any lectures to students but I often try to „teach“
[Pharo-dev] poolDictionaries removal breaks my projects
Please note that the change IS at the Nautilus level. The default class
description is the same as before! Your class porting example is unharmed by
this change.
On Feb 1, 2014, at 7:16 AM, GOUBIER Thierry wrote:
> Shortening the
Just to clarify... 5 emails saying “it’s okay” plus no active complains is a
whole different thing than making usability tests with 5 users.
I wish so much I could say that Nautilus rocks, seriously
It’s a pity because the community is putting so much effort on it
On Feb 1, 2014, at 2:41 PM, J
On Feb 1, 2014, at 12:55 PM, Andreas Wacknitz wrote:
>> There are some kinds of students who are going to find Smalltalk difficult,
>> yes. I do not see how removing pooldictionaries from the class creation
>> template will affect them. If they ask about them, you can say that they are
>> the
On Feb 1, 2014, at 12:39 PM, "Torsten Bergmann" wrote:
> OK, back to topic and to summarize: we now all fully understood that the
> original message
> including pools is still there, will not break code loading or other things
> and that the
> change is on the Nautilus level.
Yes, thanks f
Am 01.02.2014 um 15:00 schrieb Johan Fabry :
>
> On Feb 1, 2014, at 9:32 AM, Sebastian Sastre
> wrote:
>
>>> I don’t give any lectures to students but I often try to „teach“ Smalltalk
>>> to some of my colleagues and friends. And with that I have hard times.
>>> Typically „experienced“ softw
Hi Stef,
> Now people hear me well: you are ready to hear well. Lower the music
Beside the fact that I like listening to loud music I really lowered it ;)
But even with silence in the room your response told me nothing new regarding
the topic discussed.
It is not a discussion about "who has t
On Feb 1, 2014, at 12:09 PM, Johan Fabry wrote:
> Yes, something like this would be great. If it's a consolation: this kind of
> problem is present throughout the programming language research community.
> There's a great paper by Hanenberg on that. It's called "Faith, hope, and
> love: an es
On Feb 1, 2014, at 10:58 AM, Sebastian Sastre
wrote:
>
> On Feb 1, 2014, at 11:37 AM, Johan Fabry wrote:
>
>> For what it's worth: this was asked on the users list (some months ago).
>> There were about 5 replies and they were positive. I do not recall having
>> any negative replies.
>>
>
On Feb 1, 2014, at 9:32 AM, Sebastian Sastre
wrote:
>> I don’t give any lectures to students but I often try to „teach“ Smalltalk
>> to some of my colleagues and friends. And with that I have hard times.
>> Typically „experienced“ software developers think about themselves as being
>> experts
On Feb 1, 2014, at 11:37 AM, Johan Fabry wrote:
> For what it's worth: this was asked on the users list (some months ago).
> There were about 5 replies and they were positive. I do not recall having any
> negative replies.
>
> I think that asking much more than that is hard, given the nature
Please note that the change IS at the Nautilus level. The default class
description is the same as before! Your class porting example is unharmed by
this change.
On Feb 1, 2014, at 7:16 AM, GOUBIER Thierry wrote:
> Shortening the default class description is also painfull when you port code,
+1 on this point of view
On Feb 1, 2014, at 7:09 AM, Pharo4Stef wrote:
> @ Igor
>
> I guess that I know pretty well poolDictionaries I do not need an
> explanation. I even found bugs in the previous lookup and now
> we have recompilation bugs when changing pools.
>
> Now how many times gave
On Jan 31, 2014, at 4:50 PM, Pharo4Stef wrote:
>> I don’t see how this change make Smalltalk (the language) simpler. For me
>> this change looks more like an obfuscation than a simplification.
>
> How many lectures did you give? It is annoying to have to explain something
> that usually peopl
For what it's worth: this was asked on the users list (some months ago). There
were about 5 replies and they were positive. I do not recall having any
negative replies.
I think that asking much more than that is hard, given the nature of mailing
lists and the comity being busy with many other
On Feb 1, 2014, at 8:09 AM, Pharo4Stef wrote:
>
> WE WILL change the class definition in Pharo 4 because we want slots.
> So be prepared.
If by slots you mean this:
http://forum.world.st/Slot-class-builder-Anonymous-class-modification-td4724351.html
It sounds good.
It seems to make possibl
>> How many lectures did you give? It is annoying to have to explain something
>> that usually people do not need to know.
> I don’t give any lectures to students but I often try to „teach“ Smalltalk to
> some of my colleagues and friends. And with that I have hard times.
> Typically „experience
Am 31.01.2014 um 20:50 schrieb Pharo4Stef :
>
>
>>> Hi Torsten,
>>>
>>> I think it is a design decision / tradeoff, and therefore there is no
>>> fundamentally "right way" to do it. For me, it is the same case as the
>>> uses: message for Traits. It's not in the template by default because i
Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Pharo4Stef
[pharo4s...@free.fr]
Date d'envoi : vendredi 31 janvier 2014 20:50
À : Pharo Development List
Objet : Re: [Pharo-dev] poolDictionaries removal breaks my projects
>> Hi Torsten,
>>
>> I think it is a design
@ Igor
I guess that I know pretty well poolDictionaries I do not need an explanation.
I even found bugs in the previous lookup and now
we have recompilation bugs when changing pools.
Now how many times gave one lectures to newcomers?
Why do we have new calling initialize? Because after first le
>> Hi Torsten,
>>
>> I think it is a design decision / tradeoff, and therefore there is no
>> fundamentally "right way" to do it. For me, it is the same case as the uses:
>> message for Traits. It's not in the template by default because it is used
>> very infrequently. So for language simpli
Guys, can you explain me, why you hating pools so much?
Because you cannot find good use of them, or because you don't know how to
properly use them? Or because you don't understand what is it?
Pool dictionary is just a namespace, which you can share among different
parts of your code (on a per-cl
On 31 January 2014 18:03, Andreas Wacknitz wrote:
>
> Am 31.01.2014 um 14:40 schrieb Johan Fabry :
>
> > Hi Torsten,
> >
> > I think it is a design decision / tradeoff, and therefore there is no
> fundamentally "right way" to do it. For me, it is the same case as the
> uses: message for Traits. I
On Jan 31, 2014, at 2:19 PM, Pharo4Stef wrote:
> I love the changes of Johan. I would love to have a more compact class
> definition :)
> Now the question by henrik is really puzzling me.
But is not working, isn’t it? I mean for the people.
I don’t want to be critical here, only to analyse t
On Jan 31, 2014, at 2:03 PM, Andreas Wacknitz wrote:
>
> Am 31.01.2014 um 14:40 schrieb Johan Fabry :
>
>> Hi Torsten,
>>
>> I think it is a design decision / tradeoff, and therefore there is no
>> fundamentally "right way" to do it. For me, it is the same case as the uses:
>> message for T
I would like to get to the bottom of this, to be doubly sure there is no
remaining problem. Can you send me privately the steps to reproduce so I can
have a go at it using the unfixed version?
On Jan 31, 2014, at 2:04 PM, Esteban Lorenzano wrote:
> No, because my pools were not there and my t
Chris Cunningham wrote
> maybe a specific browser to include...
A real UI instead of editing a string in a workspace would make these
problems go away. Show a little form there, with a button or menu to
show/add pool dictionaries/Traits/whatever
-
Cheers,
Sean
--
View this message in contex
No, because my pools were not there and my tests were failing. But no matters,
it works now :)
> On 31 Jan 2014, at 17:45, Johan Fabry wrote:
>
>
> What probably happened is that Monticello loading with pooldictionaries was
> still working, but Nautilus was not showing them. This is the only
Am 31.01.2014 um 14:40 schrieb Johan Fabry :
> Hi Torsten,
>
> I think it is a design decision / tradeoff, and therefore there is no
> fundamentally "right way" to do it. For me, it is the same case as the uses:
> message for Traits. It's not in the template by default because it is used
> ve
What probably happened is that Monticello loading with pooldictionaries was
still working, but Nautilus was not showing them. This is the only thing that
changed, and the fix addresses the showing part. So you should not worry.
On Jan 31, 2014, at 1:26 PM, Esteban Lorenzano wrote:
> I don’t k
I don’t know what happened. All that I know is that it was not working and now
with the last fix it is, so I’m happy for now.
worried? yes. But not too much :)
On 31 Jan 2014, at 14:59, Henrik Johansen wrote:
>
> On 30 Jan 2014, at 6:14 , Esteban Lorenzano wrote:
>
>> So… that.
>>
>> Is s
Torsten
I love the changes of Johan. I would love to have a more compact class
definition :)
Now the question by henrik is really puzzling me.
Stef
> Hi Johan,
>
> Still I really do not understand what particular problem that is solved by
> changing
> the template from
>
> MySuperclass sub
On Thu, Jan 30, 2014 at 11:42 PM, Torsten Bergmann wrote:
> Please make it a setting - so one can see the creation message with
> poolDictionaries in Nautilus
> as before in the browser and is able to fill out the template.
>
> When using NB one requires them.
>
> Well, since it seems that the di
On 30 Jan 2014, at 6:14 , Esteban Lorenzano wrote:
> So… that.
>
> Is super cool to remove poolDictionaries from the default class template.
> What is not cool *at all* is the fact that now my low level projects, who
> uses them intensively, does not work anymore.
> The reason? the classes
Hi Torsten,
I think it is a design decision / tradeoff, and therefore there is no
fundamentally "right way" to do it. For me, it is the same case as the uses:
message for Traits. It's not in the template by default because it is used very
infrequently. So for language simplicity it should not b
Hi Johan,
Still I really do not understand what particular problem that is solved by
changing
the template from
MySuperclass subclass: #Foo
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Bar-Core'
to
MySuperclass subclass: #Foo
just to be clear: I’m not agains this change, I think is a good one.
I just was (and I still am) pissed with the fact that we do not fully
understand the signification of “frozen” version, and sometimes I feel like
nobody notices the HUGE effort that means to close a version in a reliable and
s
I don't see why there needs to be a configuration for that. You can still add
them, just put pooldictionaries: 'foo bar' on the next-to-last line as it was
before, et voilá … you have them in your class.
This is the same behavior as traits and the uses: message. There is not
configuration opt
Torsten wrote
>Please make it a setting - so one can see the creation message with
>poolDictionaries in Nautilus
>as before in the browser and is able to fill out the template.
Please don’t. Settings as a replacement for design are evil
Stephan
Please make it a setting - so one can see the creation message with
poolDictionaries in Nautilus
as before in the browser and is able to fill out the template.
When using NB one requires them.
Thx
T.
The behavior that Stef explains is indeed what was intended: when they are used
show them, when not, not. This is just like Traits.
The implementation was broken in this respect though. Sorry for that. I have
submitted a fix. https://pharo.fogbugz.com/f/cases/12752
Note that the original way i
In fact I do not understand why the solution can just display Pool when there
are and none when not.
I think that this is what johan wanted to do. I’m curious to see why this is
not the case.
Because it looks obvious that current users should not get impacted.
I like the idea to remove pool entry
On Thu, Jan 30, 2014 at 10:58 AM, Esteban Lorenzano wrote:
>
> On 30 Jan 2014, at 19:43, Torsten Bergmann wrote:
>
> > I checked: it was introduced in update no. 30711 with #issue 12163
> > including the following statements:
> >
> >> "Who uses poolDictionaries? I suspect extremely few of us."
>
On 30 Jan 2014, at 20:03, Eliot Miranda wrote:
>
>
>
> On Thu, Jan 30, 2014 at 10:58 AM, Esteban Lorenzano
> wrote:
>
> On 30 Jan 2014, at 19:43, Torsten Bergmann wrote:
>
> > I checked: it was introduced in update no. 30711 with #issue 12163
> > including the following statements:
> >
>
On 30 Jan 2014, at 19:43, Torsten Bergmann wrote:
> I checked: it was introduced in update no. 30711 with #issue 12163
> including the following statements:
>
>> "Who uses poolDictionaries? I suspect extremely few of us."
>> ...
>> "It would be a bit cleaner. I know us old timers don't even see
I checked: it was introduced in update no. 30711 with #issue 12163
including the following statements:
>"Who uses poolDictionaries? I suspect extremely few of us."
>...
>"It would be a bit cleaner. I know us old timers don't even see the
>poolDictionaries: line anymore, but >I dislike having to
and is even worst: classes from system that uses pools do not show them.
take a look at AJx86Assembler
it should be like that:
AJAssembler subclass: #AJx86Assembler
instanceVariableNames: 'instructions last labels stackManager level
is64'
classVariableNames: ''
poolDicti
Woha that sounds kind of wild
Easy on radical changes guys, change have costs
On Jan 30, 2014, at 3:14 PM, Esteban Lorenzano wrote:
> So… that.
>
> Is super cool to remove poolDictionaries from the default class template.
> What is not cool *at all* is the fact that now my low level proje
So… that.
Is super cool to remove poolDictionaries from the default class template.
What is not cool *at all* is the fact that now my low level projects, who uses
them intensively, does not work anymore.
The reason? the classes are created without poolDictionaries.
So, please… whoever pushed
62 matches
Mail list logo
