18 Mar
2018
18 Mar
'18
12:01 p.m.
Hi,
I mean that until 6.1, Pharo was managed by integrating in the image. From 7.0, Pharo is
managed by loading code, and the process is much more similar to what happens in Moose.
This means that now we can reuse the learnings and infrastructure in both of these
projects.
ahh. Now I think that we will face problems in Pharo :)
:)))))))
I meant the requirements are the same. Pharo should certainly not learn from Moose how to
distribute code, but hopefully we can learn together :).
Doru
The problem is when you have multiple repositories, and a deeper nesting level. Indeed,
we do not have version methods, but we still have to change the string inside the baseline
to point to specific version of a dependency.
Ok.
I did not discard the argument. But that was the best solution I could find, and others
did not produce a better one.
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.
Sure.
I am not sure I see the similarity between GTExample and Announcements. Can you explain?
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 :).
--------------------------------------------
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
"We can create beautiful models in a vacuum.
But, to get them effective we have to deal with the inconvenience of reality."
On Mar 18, 2018, at 11:55 AM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
Yes, please.
Yes. So, let’s start with one next Tuesday.
May be we could add you to the discussion we have via discord. We should also present what we will do around
Spec2 but first we should have a prototype because it will
clean a lot of mess and works with Morphic and Bloc.
Yes.
In the
meantime, here is some input:
It would be great to align the development of Moose with that of Pharo. We were waiting
for this for a long time, and now that Pharo is built similar to how other projects are
built, we can finally do it. So, this is really great!
You will tell me what you mean because this is not clear.
I do not see for now the difference. And I
also do not want to have 1 year releases. In fact, that is why for our work we actually
use the latest version. The only reason why we did not have faster releases was that there
was no reliable way to do it, except the manual way. Right now, we still do not have such
a way for Git either, and this is not a problem unique to Moose. It would be great work on
some solution for this problem to benefit all Pharo projects.
With git I thought that you can reload a version and dependent components held in the
same repository based on a hash.
We do not need to handle the versions as with MC but I think that this only works for
components stored in the same repo.
This is why we should really think about what is Moose.
I will ask the experts around. For
Glamour and existing GT, we can deal with bugs at most, but we will not invest in further
development. The memory leaks problem seems to have reappeared. This shows that we do not
have the right tools for understanding it, and I would be happy to work with someone that
wants to invest in this, especially when it comes to Announcements.
Discuss with esteban. Because we should do something. Ok this is good to know. Because Moose++ should
not rely on Glamour then and it means that RMOD will not invest there. I suspected it
so good to know.
We think that except GTTool, Pharo should not depend on Glamour so that we can unload it.
So we will check and redo all the tools
that are not GT to not use Glamour.
Ok.
Now there are two problems that I would like to
see changed in the future
- no comment at all in methods. This is the last time that I accept components in Pharo
in that state
Same apply for Spec and other BTW
- Subclasses when superclass could have been improved. For example GLMAnnouncer methods
should not be there
but most of them should have been put the superclass. This is not the way to grow a
strong infrastructure.
- Having all the classes subclasses of Announcer looks like a bad design strategy.
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.
On the UI
front, our complete energy is on Bloc, and the goal is both to produce the IDE for Pharo
and to provide the browsing infrastructure for Moose. Over the past year, the main UI we
used when working with Moose was the Moose Playground and GTInspector and it works really
well. This shows that the investment in Bloc can pay off easily for Moose as well.
I have large concerns about the engineering behind GT widgets and Glamour and overall
super complex design of GT in general.
I can understand that you want generic solution but generic solutions have a cost.
Now I sincerly hope that the new version will be less complex because Pharo needs
simplicity and often
you discarded this argument but this argument is real and it can kill us. We cannot for
example spent days looking for memory leaks. Now you see something that is symptomatic to me:
let us look at Beacon / SystemLogger.
I do not care about SystemLogger. Now I worked on it (and the design could be better).
Then you came with Beacon which basically killed SystemLogger.
Then nothing. We still have this fucking Transcript everywhere and not object transcript.
There were not a single effort to build the next step. While I was planning to do it with
SystemLogger.
You killed my energy and all the effort around. And you produce Beacon and two people are
using it.
So I will check with the guys here what they think about Beacon and may be do a pass on
SystemLogger or another iteration.
Now for me the main problem (and there is a pattern with Glamour here) is that
I do not know how to maintain Beacon while I know how to maintain SystemLogger (it is
limited and simple and not
super generic and super powerful but I can maintain it). The same happens with Glamour.
Probably the same happens with Spotter.
If esteban cannot fix easily Glamour (Iceberg suffered A LOT of bugs in Glamour like the
refresh to index in list) then there is an ENGINEERING problem.
Now we can discard this argument. The point is still there.
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 :(.
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.
Also,
beside the UI, the new GT also comes with visual components, like Mondrian and Diagrammer,
and with the basic support for documentation with Documenter.
I am not sure I understand what not loading GTExample mean.
The point is that we should take care of modularity and I would like to avoid to be also
forced to pay attention for others.
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
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.
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
www.feenk.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Cheers,
Doru
> 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
--------------------------------------------
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