[Glamour] default selection in ListPresentation
by Cyrille Delaunay
Hello,
Is there a way to set a default selection to a list presentation? so that
when I open the browser, the morphic list has already a value selected.
I tried that:
|tmpBrowser|
tmpBrowser := GLMTabulator new.
tmpBrowser row: #list.
tmpBrowser transmit to: #list; andShow: [:a |
a list
display: [:input | input];
selection: #a;
yourself
].
tmpBrowser openOn: #( b c d v a d f r).
but the list still open with nothing selected
5 years, 2 months
Deprecation of #children in Moose-Core and FAMIX-Core
by Blondeau Vincent
Hi,
With Cyril, we discovered that MooseEntity >> children behavior is not as expected. It collects all the items defined in the meta meta model: not only the children but the parents too...
childrenEntities should be used instead and consequently TMetaLevelDependency should be defined on MooseEntity.
Moreover, #children is also defined on the subclasses of FAMIXScopingEntity as a "Polymorphic accessor to children of this scope in a hierarchical structure (package->subpackages, scope->subscopes)".
Cyril and I suggest to deprecate these 3 methods (in FAMIXScopingEntity, FAMIXNamespace, FAMIXPackage) to "childrenOfMyKind", and to change in FAMIXPackage, isKindOf: in allWithSubTypeOf:.
Cyril will do the changes next week.
Cheers,
Vincent
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
6 years, 2 months
Big models, memory and persistence
by Cyrille Delaunay
Hello Moose !
With the current memory limit of Pharo,
and the size of the generated moose models being potentially huge,
maybe some of you already though about (or even experimented) persistence
solutions with query mechanisms that would instantiate famix objects only
“on demand”,
in order to only have part of a model in memory when working on a specific
area.
If so, I would be really interested to hear about (or play with) it :)
At first look, I see that there is a MooseGroupStorage class.
This kind of object answers to some usual collection messages (add, remove,
select, detect, .. ).
I guess that when we perform queries over a moose model,
when we add or remove entity objects,
we end up using this protocol.
So, if I wanted to implement a database persistence solution for moose,
my first feeling would be to implement a specific kind of
“MooseGroupStorage”,
and to plug there a communication layer with a database.
Does it make sense ?
I have not played with moose since a long time
(but I am back to play with it a lot more :))
and my vision on things may be naive.
So do not hesitate to tell me if what I am saying sounds crazy,
and to push me back on the right path !
Does anyone already thought about solutions to deal with memory limits when
generating big moose models ?
--
Cyrille Delaunay
6 years, 2 months
Re: [Pharo-users] Smacc debugger
by Tudor Girba
Hi,
It is actually the economic reasoning that prevailed here.
John was willing to invest effort to both work with and benefit from the Moose/GT environment. The consequence was that he built the GT extensions for SmaCC while Andrei and I offered a bit of support. In this process, we also got updates and fixes to several grammars that are now shipped with Moose.
Furthermore, as John is the primary author of SmaCC it only makes sense that he gets to control what he maintains.
As for the repository, I asked him kindly to keep it in SmalltalkHub at the beginning to make the integration with Moose cheaper and easier. Now, that the GitHub solution grows we can certainly consider moving it together with the rest of Moose.
As for the need to have a fork of SmaCC, I think there is little need for that and John was always responsive to requests.
Cheers,
Doru
> On Mar 29, 2017, at 6:21 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
>
> So I browsed the mailing-list and I foind the mail of thierry saying that there is no difference.
> I will try to tools in moose then.
>
>
> On Wed, Mar 29, 2017 at 6:07 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
> Ok I should say that I do not understand the differences and why there are two versions of Smacc.
> So I will stop maintaining the tutorial because now may be I should revert what I wrote.
> I was too stupid to do it in fact I should focus on my stuff and nothing else.
> This saddens me a lot.
> We are a small community and we split ourselves into little chunks.
> I do not get why there is no notion of economy and sharing in our culture.
>
> Stef
>
>
>
> On Wed, Mar 29, 2017 at 2:30 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> Hi,
>
> > On Mar 28, 2017, at 11:50 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
> >
> > OK
> > I loaded Smacc from github as mentioned by thierry.
> >
> > Metacello new
> > baseline: 'SmaCC';
> > repository: 'github://ThierryGoubier/SmaCC';
> > load
> >
> > Are there two configurationOfSmacc?
> > May be we should only have one no?
> >
> > I have the impression that even thierry and jason working heavily with Smacc do not know that.
> > And we should not force them to use Moose. At least we do not have to win
> > anything with it.
>
> I did not mean to force anyone to use Moose. I just said it is already loaded there, in case you use it.
>
> Moose relies on the ConfigurationOfSmaCC maintained by John. Thierry has another repository that he created before John moved his work to Pharo. But, now that he does work with Pharo Moose relies on his version.
>
> Cheers,
> Doru
>
> >
> > Stef
> >
> > On Mon, Mar 27, 2017 at 6:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> > They come with the ConfigurationOfSmaCC which is already in the Moose image.
> >
> > Doru
> >
> >
> > > On Mar 27, 2017, at 4:52 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
> > >
> > > Hi
> > >
> > > where can I load the Smacc gt extension and debugger extensions?
> > >
> > > Stef
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Speaking louder won't make the point worthier."
> >
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "There are no old things, there are only old ways of looking at them."
>
>
>
>
>
>
>
--
www.tudorgirba.com
www.feenk.com
"We cannot reach the flow of things unless we let go."
6 years, 2 months
Analyzing python application
by Alexandre Bergel
Hi!
Just to share what we have recently done.
We have designed a very simple python analyzer, available as a Roassal plugin (available from the world menu).
As an example, the following code produces:
-=-=-=-=-=-=-=-=-=-=-=-=
root := '/Users/alexandrebergel/Desktop/astropy' asFileReference.
p := PyProcessor new.
p processRootFolder: root.
p resolveDependencies.
b := RTMondrian new.
b shape circle.
b shape box
height: #numberOfLinesOfCode;
width: [ :c | c numberOfMethods * 10 ].
b nodes: p classes.
b edges connectFrom: #superclass.
b layout tree;
ifNotConnectedThen: RTFlowLayout new.
b normalizer
distinctColorUsing: #file.
^ b
-=-=-=-=-=-=-=-=-=-=-=-=
Cheers,
Alexandre
6 years, 2 months
Fwd: GSoC 2017: Tips on Reviewing Student Proposals
by Serge Stinckwich
Dear all,
this is a short update for the Google Summer of Code 2017.
The students have to submit your proposals on the Google website before
April 3rd.
See details below.
I dunno exactly who are the students/mentors who are submitting a proposal
for Pharo.
Can the mentors (or students) send me in private an email about the name of
the students/mentors + a title of your project ?
Thank you very much.
Regards,
---------- Forwarded message ----------
From: Google Summer of Code <summerofcode-noreply(a)google.com>
Date: Mon, Mar 20, 2017 at 7:26 PM
Subject: GSoC 2017: Tips on Reviewing Student Proposals
To: sergestinckwich(a)gmail.com
[image: Google Summer of Code]
Hi Serge Stinckwich,
Thank you for registering to be a GSoC 2017 mentor or organization
administrator!
We have many new mentors and organizations this year so we wanted to go
through some important details to help you understand the process for the
next couple of months.
Please take the time to reach out to your organization administrator about
what is expected of you this year as a mentor. We also encourage you to
read the entire Google Summer of Code mentor manual
<http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/> and the
Roles and Responsibilities doc if you haven't done so already. Both the
manual and Roles and Responsibilities doc were written by GSoC veteran Org
Admins, Mentors, former students and Google Program Admins. They have
helpful information about the program and how to participate successfully
at each step in GSoC.
*New GSoC Orgs*: the section about participating in your first GSoC has
some great tips.
To see all emails sent to mentors and org admins visit this page
<https://developers.google.com/open-source/gsoc/2017/mentor-oa-announcements>
that will continue to be updated throughout the program.
Student Proposals
As of today, students are able to submit their proposals via the website.
Each student may submit up to 5 proposals to the program. They can submit
multiple proposals to the same organization for different projects if they
wish.
Historically, the students with the best proposals reach out to the orgs
early to receive feedback before submitting their final proposal. To
encourage more students to seek feedback on their proposals we made draft
proposals part of the official proposal workflow. Be sure to refresh your
dashboard periodically so that you can see when new drafts are ready to
review. You will not receive an email. We are encouraging the use of Google
Docs for proposals as this will allow you to comment directly on the
proposal (if the student sets their sharing settings correctly).
Over the next couple of weeks you will be interacting with dozens and in
some cases hundreds of students interested in working with your project. We
know many of you may become overwhelmed and some students can be impatient,
so you may want to have an auto-responder or some sort of canned response
to let students know you are looking at their proposals but it could take X
days to receive a response.
Students *must* submit their final proposal as a PDF through the website.
It will be visible to you after the deadline for student applications
(April 3 16:00 UTC). You should make your decisions on which students to
accept based on the contents of the final PDF proposal and your
interactions with the student.
Students can delete their proposals and you will not receive an email of
the deletion. If a proposal disappears from your list, it is likely because
they deleted it.
Working with Students
All student projects must have at least 1 mentor assigned to the project.
We strongly encourage assigning a second mentor as a backup mentor or
co-mentor. A mentor should not be the primary mentor for more than one or
two students. Mentoring can be a lot of work and we don’t want anyone to
burn out and become frustrated with the program.
Important GSoC 2017 Dates and Deadlines
*March 20 - April 3 16:00 UTC*: Mentors and Org Admins review student draft
proposals and give students feedback on their proposals.
*April 3 - 16:* Review all submitted student proposals with your org and
consider how many you want to select and how many you can handle. Decide on
the minimum/maximum number of student slots to request.
*April 17, 16:00 UTC*: Deadline to submit slot requests (OAs enter requests)
*April 19, 16:00 UTC*: Slot allocations are announced by Google
*April 19 - 24 16:00 UTC* : Select the proposals to become student
projects. At least 1 mentor must be assigned to each project before it can
be selected. (OAs enter selections)
*April 24 - May 4:* Google Program Admins will do another review of student
eligibility
*May 4*: Accepted GSoC students/projects are announced
*May 4 - 29*: Community Bonding Period
*May 30*: Coding begins
*June 26-30*: First evaluation period - mentors evaluate students, students
evaluate mentors
*July 24 - 28*: Second evaluation period - mentors evaluate students,
students evaluate mentors
*August 21- 29*: Students wrap up their projects and submit final
evaluation of their mentor
*August 29 - September 5*: Mentors submit final evaluations of students
*September 6*: Students passing GSoC 2017 are announced
Mentors Mailing List
If you want to be included on the GSoC mentors mailing list be sure to opt
in on your User Profile page. We will add anyone who has opted in to the
list every few days for the next month. And then every couple of weeks
throughout the program. You can always opt out once you have been added by
unsubscribing using the link on any of the emails.
Contact Us
Please use the gsoc-support(a)google.com email address for questions so that
anyone on our team can answer your question for you.
We look forward to working with all of you over these next 6 months! Thanks
again for being a mentor for GSoC 2017!
Google Open Source Programs Office
This email was sent to serge.stinckwich(a)gmail.com.
You are receiving this email because of your participation in Google Summer
of Code 2017.
https://summerofcode.withgoogle.com
To leave the program and stop receiving all emails, you can go to your
profile <https://summerofcode.withgoogle.com/dashboard/profile/> and
request deletion of your program profile.
For any questions, please contact gsoc-support(a)google.com. Replies to this
message go to an unmonitored mailbox.
© 2017 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA
--
Serge Stinckwich
UCN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
6 years, 2 months
a lot of new tests with errors
by Pavel Krivanek
In the latest build we have 243 new tests failing with an error (Instance
of FAMIXPharoAnchor did not understand #privateQuery:with:)
new versions in the image are:
'ACD-Model' : 'ACD-Model-PavelKrivanek.47',
Merlin' : 'Merlin-PavelKrivanek.159',
'RoelTyper' : 'RoelTyper-PavelKrivanek.88',
'Famix-Core' : 'Famix-Core-AnneEtien.312'
'Famix-Extensions' : 'Famix-Extensions-VincentBlondeau.302',
-- Pavel
6 years, 2 months
Question
by Markus Böhm
Agile Vis ebook is superb, copied following snippet, know hopefully what
it's doing, but want to make sure I understand how it works (in terms of
"plain" Pharo):
1) @ RTPopup: Class name is enough, but it is initiated under the hood?
2) RTMetricNormalizer new ...: There is no need to keep reference to
created object? Why? because messages sent to object (like normalizeSize)
have a "sideeffect" on es?
3) RTMetricNormalizer connects to model via #yourself? Is every symbol or
code block. that is sent to RTMetricNormalizer as argument, executed when
finally "sent" to es?
BR Mike
v := RTView new. es := (RTEllipse new color: Color blue) elementsOn: #(4 5 1
2 3 5). v addAll: es. es @ RTPopup. RTMetricNormalizer new elements: es;
alphaColor; normalizeSize: #yourself min: 20 max: 50; normalizeColor:
#yourself. RTHorizontalLineLayout new alignCenter; on: es. es @ RTLabeled. v
6 years, 2 months
Roassal tests make moose6.1 build crashing
by Blondeau Vincent
Hi,
The last changes on Roassal2 seems to make the actual job stopping in the middle of the tests: https://ci.inria.fr/moose/job/roassal2/.
And make the moose6.1 failing too...
Can someone fix this problem?
Else, I'll skip the Roassal tests to make the job green again (and integrate the latest changes).
Thanks in advance !
Cheers,
Vincent
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
6 years, 2 months
