Hi Mr Alexandre,
How can i visualize your exemple in Glamour. which method can i call?
Actually, i use the default builder in Glamour with roassal (
ROMondrianViewBuilder,
i think!).
Thanks!
2014-06-09 4:06 GMT+07:00 <moose-dev-request(a)iam.unibe.ch>:
> Send Moose-dev mailing list submissions to
> moose-dev(a)iam.unibe.ch
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> or, via email, send a message with subject or body 'help' to
> moose-dev-request(a)iam.unibe.ch
>
> You can reach the person managing the list at
> moose-dev-owner(a)iam.unibe.ch
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Moose-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Roassal2: sending @ RTLabelled to an empty edges group
> bug (Alexandre Bergel)
> 2. Re: RTView>>cleanAll: does not remove labels (Alexandre Bergel)
> 3. Re: length of edges in roassal (Alexandre Bergel)
> 4. Re: Loading large XML files in MOOSE (Serge Stinckwich)
> 5. Jenkins build became unstable: moose-5.0 #1593
> (admin(a)moosetechnology.org)
> 6. Re: Roassal2: sending @ RTLabelled to an empty edges group
> bug (Johan Fabry)
> 7. Re: Loading large XML files in MOOSE (Alexandre Bergel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 08 Jun 2014 16:02:08 -0400
> From: Alexandre Bergel <alexandre.bergel(a)me.com>
> Subject: [Moose-dev] Re: Roassal2: sending @ RTLabelled to an empty
> edges group bug
> To: Moose-related development <moose-dev(a)iam.unibe.ch>
> Message-ID: <EE750C18-4B56-4A1F-8A91-D1EB8377B5D2(a)me.com>
> Content-Type: text/plain; charset=windows-1252
>
> I am not sure to understand this.
>
> The following does not produce an error: RTGroup new @ RTLabelled
>
> Alexandre
>
>
> On Jun 8, 2014, at 3:00 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote:
>
> > I hit send to fast, sorry.
> >
> > The origin of the bug is Array>>@ interactionClassOrObject line 2: obj
> := interactionClassOrObject elementToBeAdded. The interactionClassOrObject
> is a RTLabelled class, and it DNU?s that message.
> >
> >
> > On Jun 8, 2014, at 2:49 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote:
> >
> >> Hi all,
> >>
> >> at some point I was sending @RTlabelled to a group of edges that
> happened to be empty, and up came the debugger :-(
> >>
> >>
> >> ---> Save our in-boxes! http://emailcharter.org <---
> >>
> >> Johan Fabry - http://pleiad.cl/~jfabry
> >> PLEIAD lab - Computer Science Department (DCC) - University of Chile
> >>
> >>
> >> _______________________________________________
> >> Moose-dev mailing list
> >> Moose-dev(a)iam.unibe.ch
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>
> >
> >
> >
> > ---> Save our in-boxes! http://emailcharter.org <---
> >
> > Johan Fabry - http://pleiad.cl/~jfabry
> > PLEIAD lab - Computer Science Department (DCC) - University of Chile
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)iam.unibe.ch
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 08 Jun 2014 16:19:53 -0400
> From: Alexandre Bergel <alexandre.bergel(a)me.com>
> Subject: [Moose-dev] Re: RTView>>cleanAll: does not remove labels
> To: Moose-related development <moose-dev(a)iam.unibe.ch>
> Message-ID: <04B5400A-15E9-45A1-B88C-F8907FFCB826(a)me.com>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> Well spotted!
> Fixed in version 0.272 of Roassal
>
> Alexandre
>
>
> On Jun 8, 2014, at 2:15 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote:
>
> > Hi all,
> >
> > another small bug in Roassal2: sending cleanAll to a view does not
> remove the labels attached to nodes in that view.
> >
> >
> > ---> Save our in-boxes! http://emailcharter.org <---
> >
> > Johan Fabry - http://pleiad.cl/~jfabry
> > PLEIAD lab - Computer Science Department (DCC) - University of Chile
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)iam.unibe.ch
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 08 Jun 2014 16:26:20 -0400
> From: Alexandre Bergel <alexandre.bergel(a)me.com>
> Subject: [Moose-dev] Re: length of edges in roassal
> To: Moose-related development <moose-dev(a)iam.unibe.ch>
> Message-ID: <CD07EFD1-41E3-4E83-B4E6-9B9F8B7CEC79(a)me.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi Fabrice,
>
> I am not sure what you actually need. Why do you find the edges too short?
> Currently we cannot set the length of edges. This will come soon, but
> right now we cannot.
>
> If you want to minimize crossing, then there are two solutions:
> - use a sugyama layout: RTSugiyamaLayout
> - use the force based Layout. Execute in a workspace:
> RTRoassalExample new exampleForceBasedLayoutAnimated
>
> Let us know how it goes...
>
> Cheers,
> Alexandre
>
>
>
> On Jun 7, 2014, at 5:18 PM, Fabrice Atrevi <atrevifabrice(a)gmail.com>
> wrote:
>
> > Hi!
> > I'm using roassal in glamour for painting. I want to know how i can give
> a length for edge. Like in the screenshot, the default length is too small.
> And if possible, i want boxes and arcs do not intersect.
> >
> > Thanks,
> >
> > --
> > ATREVI D. Fabrice
> > Master en Informatique A l'Institut de la Francophonie pour
> l'Informatique (IFI/Hano?)
> > <relation_seir.PNG>_______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)iam.unibe.ch
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 8 Jun 2014 22:35:46 +0200
> From: Serge Stinckwich <serge.stinckwich(a)gmail.com>
> Subject: [Moose-dev] Re: Loading large XML files in MOOSE
> To: Moose-related development <moose-dev(a)iam.unibe.ch>
> Message-ID:
> <CAOysuxUk5nOt9U_=PHXobF=
> df9ExjGcVGBZjE9-XCbsuzQw8dw(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Thank you Doru for the help.
>
> First case: 74Mb XML file. I'm able to load the string in memory but
> the XML parser crash the image before the end.
> Second case: 10Mb XML file. I'm able to load the string in memory,
> parse the XML file. When I start to process the XML file in order to
> create an object structure, the panel "Space is too low" appear.
>
> I would like to give a try with the XMLPullParser. I guess this is
> working correctly, because I find it with the Configuration Browser.
>
>
> On Sat, Jun 7, 2014 at 10:56 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> > Hi,
> >
> > Ok, I looked a bit, and here is a way to get it to work. It is not at all
> > ideal given that it loads the entire string before parsing it, but it
> surely
> > will work with an xml of your size:
> >
> > contents := fileReference readStreamDo: [ :stream | stream contents ].
> > svnlog := (XMLDOMParser on: contents )
> > documentReadLimit: contents size;
> > parseDocument.
> >
> > Cheers,
> > Doru
> >
> >
> >
> > On Fri, Jun 6, 2014 at 12:50 PM, Tudor Girba <tudor(a)tudorgirba.com>
> wrote:
> >>
> >> I encountered a similar situation before, but there is a way to go
> beyond
> >> that limit.
> >>
> >> I do not have the code at my disposal right now, but look at the
> >> XMLDOMParser constructor, and at some point you will see a hardcoded
> limit
> >> value. You should be able to pass another one in.
> >>
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >> On Fri, Jun 6, 2014 at 11:22 AM, Serge Stinckwich
> >> <serge.stinckwich(a)gmail.com> wrote:
> >>>
> >>> Dear all,
> >>>
> >>> I want to process large XML file (typically event logs with more than
> >>> 80Mb data) and I'm not able to do that at the moment with the XML DOM
> >>> parser (it says I reach the read limit after 3094 XML lines) and I
> >>> guess I will have problem to manage such a large file in memory after
> >>> that.
> >>>
> >>> Should I switch to an event-driven XML parser in order to avoid
> >>> loading all the XML file in memory ? Do we have such a parser for
> >>> Pharo ?
> >>>
> >>> --
> >>> Serge Stinckwich
> >>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> >>> Every DSL ends up being Smalltalk
> >>> http://www.doesnotunderstand.org/
> >>> _______________________________________________
> >>> Moose-dev mailing list
> >>> Moose-dev(a)iam.unibe.ch
> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>
> >>
> >>
> >>
> >> --
> >> www.tudorgirba.com
> >>
> >> "Every thing has its own flow"
> >
> >
> >
> >
> > --
> > www.tudorgirba.com
> >
> > "Every thing has its own flow"
> >
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)iam.unibe.ch
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
>
>
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 8 Jun 2014 22:41:04 +0200 (CEST)
> From: admin(a)moosetechnology.org
> Subject: [Moose-dev] Jenkins build became unstable: moose-5.0 #1593
> To: moose-dev(a)iam.unibe.ch
> Message-ID:
> <
> 704547223.139.1402260064428.JavaMail.jenk_moose(a)ci-jenkins3.inria.fr>
> Content-Type: text/plain; charset=UTF-8
>
> See <https://ci.inria.fr/moose/job/moose-5.0/1593/>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 8 Jun 2014 17:03:22 -0400
> From: Johan Fabry <jfabry(a)dcc.uchile.cl>
> Subject: [Moose-dev] Re: Roassal2: sending @ RTLabelled to an empty
> edges group bug
> To: moose-dev related tools <moose-dev(a)iam.unibe.ch>
> Message-ID: <EE3A1133-EF75-4DBF-924E-65844A997CEC(a)dcc.uchile.cl>
> Content-Type: text/plain; charset=windows-1252
>
>
> I think it?s best that I show you when you are back ? it?s so deep in my
> code that I cannot easily reproduce it in a simple example :-(
>
> On Jun 8, 2014, at 4:02 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
> wrote:
>
> > I am not sure to understand this.
> >
> > The following does not produce an error: RTGroup new @ RTLabelled
> >
> > Alexandre
> >
> >
> > On Jun 8, 2014, at 3:00 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote:
> >
> >> I hit send to fast, sorry.
> >>
> >> The origin of the bug is Array>>@ interactionClassOrObject line 2: obj
> := interactionClassOrObject elementToBeAdded. The interactionClassOrObject
> is a RTLabelled class, and it DNU?s that message.
> >>
> >>
> >> On Jun 8, 2014, at 2:49 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote:
> >>
> >>> Hi all,
> >>>
> >>> at some point I was sending @RTlabelled to a group of edges that
> happened to be empty, and up came the debugger :-(
> >>>
> >>>
> >>> ---> Save our in-boxes! http://emailcharter.org <---
> >>>
> >>> Johan Fabry - http://pleiad.cl/~jfabry
> >>> PLEIAD lab - Computer Science Department (DCC) - University of
> Chile
> >>>
> >>>
> >>> _______________________________________________
> >>> Moose-dev mailing list
> >>> Moose-dev(a)iam.unibe.ch
> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>>
> >>
> >>
> >>
> >> ---> Save our in-boxes! http://emailcharter.org <---
> >>
> >> Johan Fabry - http://pleiad.cl/~jfabry
> >> PLEIAD lab - Computer Science Department (DCC) - University of Chile
> >>
> >>
> >> _______________________________________________
> >> Moose-dev mailing list
> >> Moose-dev(a)iam.unibe.ch
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)iam.unibe.ch
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry - http://pleiad.cl/~jfabry
> PLEIAD lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 08 Jun 2014 17:05:54 -0400
> From: Alexandre Bergel <alexandre.bergel(a)me.com>
> Subject: [Moose-dev] Re: Loading large XML files in MOOSE
> To: Moose-related development <moose-dev(a)iam.unibe.ch>
> Message-ID: <7A240162-C07C-4883-9005-834221F8973D(a)me.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Serge, you are using a mac don?t you? Have you tried to augment the memory
> of the image?
>
> Open using a text editor the Info.plist file, contained in the VM folder.
> By checking on the internet, 1880000000 is apparently the biggest value
> possible.
> http://forum.world.st/OSX-squeak-crash-maximal-size-of-image-td2952312.html
>
>
>
>
> Cheers,
> Alexandre
>
>
> On Jun 8, 2014, at 4:35 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com>
> wrote:
>
> > Thank you Doru for the help.
> >
> > First case: 74Mb XML file. I'm able to load the string in memory but
> > the XML parser crash the image before the end.
> > Second case: 10Mb XML file. I'm able to load the string in memory,
> > parse the XML file. When I start to process the XML file in order to
> > create an object structure, the panel "Space is too low" appear.
> >
> > I would like to give a try with the XMLPullParser. I guess this is
> > working correctly, because I find it with the Configuration Browser.
> >
> >
> > On Sat, Jun 7, 2014 at 10:56 PM, Tudor Girba <tudor(a)tudorgirba.com>
> wrote:
> >> Hi,
> >>
> >> Ok, I looked a bit, and here is a way to get it to work. It is not at
> all
> >> ideal given that it loads the entire string before parsing it, but it
> surely
> >> will work with an xml of your size:
> >>
> >> contents := fileReference readStreamDo: [ :stream | stream contents ].
> >> svnlog := (XMLDOMParser on: contents )
> >> documentReadLimit: contents size;
> >> parseDocument.
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >>
> >> On Fri, Jun 6, 2014 at 12:50 PM, Tudor Girba <tudor(a)tudorgirba.com>
> wrote:
> >>>
> >>> I encountered a similar situation before, but there is a way to go
> beyond
> >>> that limit.
> >>>
> >>> I do not have the code at my disposal right now, but look at the
> >>> XMLDOMParser constructor, and at some point you will see a hardcoded
> limit
> >>> value. You should be able to pass another one in.
> >>>
> >>>
> >>> Cheers,
> >>> Doru
> >>>
> >>>
> >>> On Fri, Jun 6, 2014 at 11:22 AM, Serge Stinckwich
> >>> <serge.stinckwich(a)gmail.com> wrote:
> >>>>
> >>>> Dear all,
> >>>>
> >>>> I want to process large XML file (typically event logs with more than
> >>>> 80Mb data) and I'm not able to do that at the moment with the XML DOM
> >>>> parser (it says I reach the read limit after 3094 XML lines) and I
> >>>> guess I will have problem to manage such a large file in memory after
> >>>> that.
> >>>>
> >>>> Should I switch to an event-driven XML parser in order to avoid
> >>>> loading all the XML file in memory ? Do we have such a parser for
> >>>> Pharo ?
> >>>>
> >>>> --
> >>>> Serge Stinckwich
> >>>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> >>>> Every DSL ends up being Smalltalk
> >>>> http://www.doesnotunderstand.org/
> >>>> _______________________________________________
> >>>> Moose-dev mailing list
> >>>> Moose-dev(a)iam.unibe.ch
> >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> www.tudorgirba.com
> >>>
> >>> "Every thing has its own flow"
> >>
> >>
> >>
> >>
> >> --
> >> www.tudorgirba.com
> >>
> >> "Every thing has its own flow"
> >>
> >> _______________________________________________
> >> Moose-dev mailing list
> >> Moose-dev(a)iam.unibe.ch
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>
> >
> >
> >
> > --
> > Serge Stinckwich
> > UCBN & UMI UMMISCO 209 (IRD/UPMC)
> > Every DSL ends up being Smalltalk
> > http://www.doesnotunderstand.org/
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)iam.unibe.ch
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
Orthogonally to the process open dev / release, we have the notion of
two different uses of Configurations.
I call them the Projects vs the Dependencies style.
Let us look at these two uses. I will take an example that is not in
Moose but we can see the exact
same problems in Moose.
There is a parallel with XMLSupport (a group loading XMLparser, writer,
SIXX, Pastell....
and XMLParser, XMLWriter
XMLSupport is a "Project" configuration: it is a convenient way to
group and load (in particular it expresses
dependencies to clients of XML) so the relation is not I load Sixx
because I dependent on it.
More I load it because I want to optionally offer it.
XMLParser is a "Dependencies" configuration: to parse XML we need
OrderedPreservingDictionary, Bitmap...
if we do not load them we cannot get XMLParser working.
Why this difference is important: When you want to build a tool using
the XMLParser you do not want to get SIXX. pastell
when you do not need it.
Based on this analysis we see that
PetitParser project, MooseIDE project are Projects
while
PetitParser (the package), MooseCore (the package) are dependencies
configuration.
Now the problem is that we do not have a simple way to express the
dependencies at the level of a package.
Because when coding the XMLParser package you would write that it
depends on SIXX.
Christophe is working on a prototype to get package dependencies
expressed at the package level
and he will present that at ESUG but this is not ready to use.
Now we could (but this is a lot of work) add a
configuration"Dependencies" to any package. These dependencies would be
really simple. We already have that for Traverser, Merlin, RoelTyper and
many others.
This way we could have
- Project configurations
- Dependencies configurations
Now I would like to see is do we do it? Would be good to have different
names to identify these configurations clearly.
Or at least have a description that clearly say it.
Stef
Hi alex
Why Roassal depends on FuelMetalevel?
- having the stable as a baseline is not nice because clients will cry
big times.
- there is no correct version and it would be good to use versionner to
manage it
and to release some versions from time to time. Now that roassal2 is out
it is importnt that people
can build on versions if they want.
Typically Synectiquers should really pay attention to this "detail"
- unique version is pure junk and looks like from a tutorial so I can
clean it.
- versionDevelopment: introduce a dependencies to FuelMetalevel.
I do not have access to it but I can clean it fast. Else I will fork it.
Stef
Hi
today we brainstormed and I will send a sequence of emails to discuss
what we decided
and started to do.
One of our goal is to check if we can use versionner to manage all the
configurations.
It looks possible.
The first things we started to do is
- make sure that all the configurations of external libraries are
correctly defined.
In particular we made sure that a version does not depend on a
stable one but on a version specific.
- We think that Moose should not depend on baseline of external
tools, because we need real reproduceability.
- We started to produce configurations with versionner that do not
depend on stable but on exact versions.
- I will continue to see if we can use Versionner because it would
simplify the release.
Stef
Hi
I really think that
- everybody should use versionner :) because now that I use it it
is really nice.
- we should use baseline for development during development
- we should use stable or versionned for external packages such as XML.
- with versionner we can release at the end of every week or two in
probably some clicks.
(I can ask christophe for some improvements).
So can we agree on that because we can make sure that we have the
advantges that now
and have at the end of every week a versionned released?
Stef
Hi Christophe,
> Hi Diego,
>
> Le 30 juin 2014 à 09:23, Diego Lont a écrit :
>
>> I am very happy that versioner is being built. We need more and better software configuration tools, and versioner will make our life easier. That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my fears are unfounded.
>
> You're right, Versionner enforces a single workflow. We tried to do a simple tool that can fit most people and very easy to use. Versionner is far from perfect but allows to easily manage project dependencies and release for a "classical" workflow. There are also some known limitations (e.g., no support of platform-specific sections).
> Versionner does not aim that ALL people use a single workfow but tries to provide guidelines. If one needs another workflow, it is possible by using Metacello directly. If needed, we can also add features to Versionner. It may be done from feedbacks.
> To summarize, it is not "One Ring to rule them all" but rather one tool to fit more needs and make configuration management easy.
That is exactly my point. But Stef currently tries to enforce this workflow of working to Moose. And since this workflow will not work well for Moose (because of the demands on the process), I object to this.
>> Within the Pharo community we have at least 3 different workflows:
>> A. For Pharo core, we have a pharo inbox, where suggested fixes for reported bugs are put. These fixes are reviewed and, if accepted, integrated into Pharo. This ensures that the changes in Pharo hold (most of the time) to quite some quality standards.
> It is the same workflow that GitHub favors: you fork the code, do your changes and provide a pull request that will be accepted or not. It works quite well.
>> B. For the “cross-platform” projects (Grease, Seaside, Magritte, etc.) all suggested fixes are put in the main repository on smalltalkhub. The fixes are, after review and tests, released by putting them in a “released” version of the configuration. Since not all fixes should be in all versions, and sometimes only concern a certain platform, the process for Pharo core would not work: releasing fixes are more complex because of the cross-platform issues.
> I don't see your point here. What is really different except that you don't have an inbox (some kind of dedicated branch)? Instead, you publish in the same repository, creating new branches.
>> C. For the “moose” projects all suggested fixes are put in the main repository and are accepted by default. Since most projects evolve very fast, quality assurance is done afterwards, by submitting bug fixes.
> Here, there is no review, ok.
Your response shows that I have not made my point well. I wanted to point out that we need different workflows because of the different demands. A workflow is more than only a tool, but starts with people building something and ends with people using something. And you point out that versioner has one workflow implemented, and therefor will not be applicable to all projects.
A. For pharo core all projects are included in pharo. The number of external influences (VM, plugins) is very limited. It works here to have no configuration at all, since there is only 1 release-branch: the current one. And since the file server creates a version of each build, we can always go back to a specific build. Quality is very important to pharo as a lot of users depend on a good working pharo.
B. For the “cross-platform” projects this workflow is not sufficient, because there are much more external influences. So here we use the configurations to manage the releases. And the complexity of the configuration of Seaside shows this is a very complex thing to do. This complexity is not from Metacello. Metacello allows us to do a decent job here for the supported platforms. For the unsupported platforms there is some additional manual work involved, with all risks to this. The complexity here stems from the Software Configuration challenges Seaside faces. A simple inbox won’t do the job for us. Quality here is also very important as a lot of users depend on a good working Seaside. Also there are more demands on reproducibility, as there are quite some systems depending on Seaside that should function 24/7.
C. For the “moose” projects, we have a few advantages above the cross-platform projects, and a few disadvantages:
+ Moose only needs to work for pharo. So we can cut out a lot of platform specific junk. Some projects are suited for multiple platforms, but not for the amount of platform Seaside should work on.
+ There are far less projects depending on Moose. Most of them are integrated, so tests will automatically be fired. And the projects that do depend on Moose usually do not have run 24/7.
- Moose depends on more projects then Seaside. To create an exact version is therefor much harder.
- A large part of the Moose bugs comes from the change rate of the projects Moose depends on. Pharo has a very drastic strategy to improve its architecture. This causes quite some maintenance work.
So that there is no review is not the point. The point is that because of these different demands we need to accept a lower quality standard for moose. This lower quality standard is maybe undesirable, but is not easily improved. Having no review is a consequence of this, not the cause. If we want to improve this quality standard, better SCM tools will not suffice. On the other hand, this lower quality standard has so far worked for Moose, as there are less people who depend on Moose.
Regards,
Diego
Hi
stable and development points to the same.
Then I do not see why GraphET requires RoassalPdfExporter2 and Neo.
Again this configuration looks to me like a way to load everything.
I think that I will really try another way to manage Moose because I
start to
think that it goes nowhere. This is like the XMLSupport that loaded the
clients like SIXX of XML.
I did XMLParser and XMLWriter and this is much much nicer, smaller, less
complex.
Stef
I am afraid this mail is going to be too long, but I feel it needs to be written. I will start with the conclusion, so you can skip the mail if you feel it does not interest you. Please keep the discussion on the Moose list, as there the discussion was started.
I am very happy that versioner is being built. We need more and better software configuration tools, and versioner will make our life easier. That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my fears are unfounded.
Software configuration management (SCM) is in my opinion an undervalued topic within the software world. One cannot find very many good books on them, and I am afraid this lack of knowledge shows in the way people go around with their SCM. So I would like to write down some observations of the SCM processes in Pharo that I believe we should keep in mind.
The main target of SCM is to keep the impact of changes as minimal as possible. Good SCM allows all people working on a certain project, to make their changes, without causing trouble for other project members and people using this project. Open source projects are (in SCM terms) rather complex, as they involve a lot of people, including some people we do not know.
1. One of the best things of Metacello is that it does not require you to follow a certain workflow. It is very flexible and supports a large range of possible workflows. Within the Pharo community we have at least 3 different workflows:
A. For Pharo core, we have a pharo inbox, where suggested fixes for reported bugs are put. These fixes are reviewed and, if accepted, integrated into Pharo. This ensures that the changes in Pharo hold (most of the time) to quite some quality standards.
B. For the “cross-platform” projects (Grease, Seaside, Magritte, etc.) all suggested fixes are put in the main repository on smalltalkhub. The fixes are, after review and tests, released by putting them in a “released” version of the configuration. Since not all fixes should be in all versions, and sometimes only concern a certain platform, the process for Pharo core would not work: releasing fixes are more complex because of the cross-platform issues.
C. For the “moose” projects all suggested fixes are put in the main repository and are accepted by default. Since most projects evolve very fast, quality assurance is done afterwards, by submitting bug fixes.
I can say a lot about why I believe these workflows are appropriate for their different projects, but the point I am trying to make here, is that these workflows have come to existence because of the different demands on them. And to stress my point about the flexibility (thank you Dale):
When there was a problem with the workflow in the cross platform projects, I could find a solution (using releases) that Metacello supported.
2. Unfortunately Metacello does not have a good UI. And for large configurations like Seaside, it is a lot of work to keep them maintained. I dream of a tool that acts as a UI for Metacello: this tool is flexible as Metacello, while making the simple things real easy (hitting a button and done). Does versioner aim to do this?
3. I always get very nervous when someone says: They do it like this, and that works very well for them. So we should do that too. I do not believe that is always a good idea. The conclusion should be a question: Can we use that too? And now I cannot find the mail about the java SCM practice, but I do not think we can apply it to all our processes ...
4. Modularity is very important. Also for performing good SCM. And yes, we lack sufficient modularity in Moose. It should be better. I.e. because of the lack of modularity, it is sometimes hard to distinguish between where the change needs to be put in. So there is no clear group to point out who should accept the changes. So this is also an SCM problem.
Cleaning up the configuration will help here very much. Thank you Steff for the good work here. And maybe you also have a point that the people working on Moose should have more focus on keeping things modular, because it makes the system better maintainable in a lot of ways.
5. Forking things will only make SCM worse, as it adds a complexity. So I very much hope we can come to an agreement how the process works, without resorting to drastic measures.
Regards,
Diego
Hi,
At this moment, GT primarily means:
- Playground
- Inspector
- Debugger
(Metaceller was never a subject to debate, so I will not address it here)
The Coder will likely follow but first in a different format than one
expects. Namely, it will appear first as a code editor inside the inspector.
GT is neither a whim, nor is it experimental. GT is a long term project.
For example, the inspector was incubated for more than 4 years, and it is
time to work with it and evolve it based on real-life experience. It is
true that sometimes it is still moving but that is because it is alive :).
Yet, the functionality is there, and if there are issues they should be
treated as such: report them and they will be fixed.
Now, the main reason why GT is not optional for the main Moose distribution
is that, as I explained one year ago at the MooseDay, Moose will provide
the IDE. First, we need a new IDE in Pharo and I think we have cool set of
concepts and the Moose engines are perfect for it. Second, when analyzing
data from XML structures, plain files, DB, or even Pharo objects, the
Inspector is cornerstone. And so is the Playground. As for the Debugger, I
will remind you that it comes with working dedicated debuggers for
PetitParser, Glamour, and Announcements. These alone make it worth the
effort when developing Moose-based solutions.
Not to mention that we are building something that is ridiculously small
for the power it harnesses. We should not stop this because we find a
couple of bugs along the way.
For all these reasons, GT is here to stay.
Cheers,
Doru
p.s. Btw, the development of GT is not reserved to a closed circle. We
would like to invite anyone interested in participating in the development
of GT.
p.p.s. Of course, because this system is properly engineered, it can be
safely replaced by the default tools:
EyeInspector registerToolsOn: Smalltalk tools.
SpecDebugger registerToolsOn: Smalltalk tools.
Workspace registerToolsOn: Smalltalk tools.
--
www.tudorgirba.com
"Every thing has its own flow"
