18 Mar
2018
18 Mar
'18
12:02 p.m.
I summed up a list of actions:
Think in terms of layers.
I am not sure I see the similarity between GTExample and Announcements. Can you explain?
use of announcement.
We invested in the memory leaks as well. But, I think it would be a pity to say that the
investment in GT had only costs and no benefits :).
This is not what I’m saying but we should take care because you know like me that legacy
after a while smashes you.
We are planning this. (even if people will cry and complain that we are touching graal
code).
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
We are now talking about things that happened 9 years
ago :). In VW, every object is announcer. As Glamour came in Pharo from VW, it was the
simpler move strategy.
Indeed, GLMAnnouncer should not exist, but the logic of GLMAnnouncer is quite specific
(suspending announcements) to Glamour and we did not find a nice way to make it properly
reusable, and that is why it did not get into Announcer. We had a long discussion about
this with Igor, and at the time he was guarding Announcements, so nothing was integrated.
Announcement improvement.
ok we should have this discussion in the Pharo list.
The postCopy and other code could move up.
>> Of course generic infrastructures have a cost.
Now, before considering the cost of generic solutions, we should also compare it with the
cost of maintaining 1000s of concrete use cases (such as inspector extensions). As you
know, finding the right abstraction is difficult. For example, Traits underwent several
implementations over 15 years, and now we have another one. You have a similar issue with
Spec. For me, this is actually great. All of these served a purpose at the time, but the
important part is that they were shipped even if they were not perfect.
I think that this is important to have a simplification phase after a complex one.
I do not understand this part. Beacon was moved under
the Pharo umbrella, but its integration was postponed multiple times due to various other
external reasons in Pharo that were not under my control. Now, Beacon also came with
documentation, and its implementation is smaller and has less concepts than SystemLogger
(the main engine has 303 lines of code). I would be very happy to push it, but I do not
know what else to do right now :(.
Beacon use.
I will read the code. And ask other people to do the same.
And after we take a decision.
So at the end
I want to say that I may prefer that Pharo does not have hyperfancy features that only two
people master
and that we (the guy spending time on cleaning) can manage our system.
I have a different opinion. Bloc/Brick/GT are tested and documented like this, so
we need to have that around.
We will have to check this because even for Pharo we want to avoid to have the
Glamour/Annoucement hell around
when you will consider that another project is more important. I guess
that you are referring to the issue "GT-Examples-Roassal2 should not be packaged in
GT-Examples #1180”. I think there is a confusion, so I added a comment for that:
https://github.com/moosetechnology/Moose/issues/1180#issuecomment-373904295
<https://github.com/moosetechnology/Moose/issues/1180#issuecomment-373904295>
Yes but not only.
You see when we introduced Glamour in Pharo. You remember I was against it and you said
that
it was only 35 classes and that I could maintain Morphic that was far more complex.
Net result. ***We*** were fighting multiple time with memory leaks. The design is overly
complex. What we
introduce in Pharo should be maintainable by the majority.
- method comments (look at Glamour not a single method comment!!!!!!!!!)
- decent class comments and not just plain shit “this class is abstract”
- tests and not with a super funky system that only one guy understand
- less use of Pragmas
- You see if
I use Statespecs and
you use GTExample and
denis use his testing framework because it is
cooler
then
when we improve SUnit (which we will do) then fewer components benefit from it
we have to pay attention to Statespecs, GTExample,….. instead of ONE framework.
I do agree that one framework is important. Now, SUnit is around since decades and did
not really change much so I do not think it would be such a bad thing to revisit its
usage. GTExample is not only SUnit replacement, but also a
way to document and communicate. I would be very happy to have a conversation about it.
When I wanted to talk about examples a couple of years ago, there was not much interest
for it. So, we went on to do our homework and now have significant case studies that drove
significant projects, and now we can have that conversation with more concrete facts
around us.
You know what I mean and it depends.
I think that
Pharo will get a lot more picky about its components. So We are talking about Pharo 8.0
so you can be prepared. But do not come to tell me that we did not tell it.
Good. We will still continue producing components that are free and available and people
will be able to pick them if they want. The cool thing with Pharo getting more modular is
that now the cost of people trying things out is smaller so this should raise more
interesting debates, which I think is a healthy thing.
I really think that Pharo 8.0 will be about
massive cleaning up.
So as a community we will have to have a real discussion about Pharo 80
because we will raise the bar and I will push all my voice for that because we cannot
continue
like that.
I think that we should set some basic rules such as the tools we want for Pharo
development and the quality rules.
I agree.
Doru
Stef
--
www.tudorgirba.com <http://www.tudorgirba.com/>
www.feenk.com <http://www.feenk.com/>
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
Cheers,
Doru
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev> On Mar 17, 2018, at 6:39 PM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
I would like also to see what is the vision for the future of Moose.
Because we will put some effort on the table but not blindly and I would like to avoid to
throw away months of work.
I would like to know what is the status of Glamour development because iceberg shows that
Glamour is buggy.
We also have memory leaks in Pharo because of GT tools and this is super annoying.
I think that there are too many announcers to my personal taste
stef
> On 17 Mar 2018, at 18:26, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote:
>
>>
>> On 17 Mar 2018, at 17:42, Tudor Girba <tudor(a)tudorgirba.com> wrote:
>>
>> Excellent!
>>
>> Andrei and I allocated next Tuesday to look into migrating the code to GitHub.
Can we sync on Discord for this?
>
> Yes it would be nice.
>
> Now tuesday we will have a meeting with Guille and others because for Pharo we can
make sure that
> we can get exactly the same system to reproduce bugs and not end upi with situation
like two weeks ago where we could not get Pharo
> opening. So may be the pattern for Pharo can be applied to Moose.
>
> For the new moose I do not want to have one year open session. I’m fed up to have no
possibility to go back in the past.
> So we should find a solution and a real one. I’m not in the mood to lose my energy on
something that
> is unmanageable and just a “fuite en avant”.
> So may be automatic release every two weeks is a solution. It should not be difficult
to git.
>
> I also would like that subprojects are managed nicely and modularly. For example I do
not understand why we have Roassal-VW in Moose.
> I want to make sure that we can get moose without GTExample also.
>
> We should have a pattern for subcomponents and projects.
> PetitParser
> SmaCC
> Roassal
> XML
> …
> Here we see already that there are difference. SmaCC easy it is external.
>
> I will start to migrate (I cleaned RoelTyper).
>
> Stef
>
>
>>> On Mar 17, 2018, at 9:58 AM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
>>>
>>> Hi guys
>>>
>>> We started to have a look at the bug entries of Moose on github.
>>> We will start to migrate Moose to github. We will have to think how to manage
this.
>>> Projects
>>> Subprojects
>>> Baseline migration
>>>
>>> I would like to enforce the following:
>>>
>>> - the feature todos should not be managed in the bug tracker. Trello is good
for this.
>>> - Now todo related to current situation: such as remove empty class, split
package should at least the entry should be tagged with todo.
>>> - close any bug entry that does not have a description how to reproduce it.
>>>
>>> Stef
>>>
>>> --------------------------------------------
>>> Stéphane Ducasse
>>> http://stephane.ducasse.free.fr
>>> http://www.synectique.eu / http://www.pharo.org
>>> 03 59 35 87 52
>>> Assistant: Julie Jonas
>>> FAX 03 59 57 78 50
>>> TEL 03 59 35 86 16
>>> S. Ducasse - Inria
>>> 40, avenue Halley,
>>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>>> Villeneuve d'Ascq 59650
>>> France
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)list.inf.unibe.ch
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "To lead is not to demand things, it is to make them happen."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --------------------------------------------
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Beauty is where we see it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev