Moose-dev March 2017

moose-dev@list.inf.unibe.ch

20 participants
26 discussions

Fwd: [Pharo-users] [ ANN ] Pharo Days 2016
by Tudor Girba 08 Mar '24

08 Mar '24

> Begin forwarded message: > > From: Sven Van Caekenberghe <sven(a)stfx.eu> > Subject: [Pharo-users] [ ANN ] Pharo Days 2016 > Date: December 9, 2015 at 9:52:09 AM EST > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>, Pharo Development List <pharo-dev(a)lists.pharo.org>, Pharo Business <pharo-business(a)lists.pharo.org> > Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > Dear fellow Pharoers, > > Mark your calendars: on Thursday March 31 & Friday April 1 we are organising the Pharo Days 2016. This year we moved the location to Namur, Belgium, just a bit south of Brussels, at the very beautiful location of the ‘Cercle de Wallonie’ overlooking the river Meuse. > > We’ll update the following page moving forward. > > https://medium.com/concerning-pharo/pharo-days-2016-c52fe4d7caf > > You can ask questions on any of the Pharo mailing lists or you can email the Pharo Board. > > Let's make this another success, together ! We hope to see as many of you as possible. > > -- www.tudorgirba.com "We are all great at making mistakes."

4 3

[Glamour] default selection in ListPresentation
by Cyrille Delaunay 24 Mar '18

24 Mar '18

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

3 4

[ann] gtspotter: a moldable interface for spotting objects
by Tudor Girba 23 Sep '17

23 Sep '17

Hi, Alex Syrel, Andrei Chis and I are happy to announce a new addition to the Glamorous Toolkit: GTSpotter, a novel interface for spotting objects. GTSpotter has two goals: - Provide a uniform yet moldable interface that can work on any object, and - Handle searching through arbitrary levels of object nesting. We think this will have a significant impact on the development workflow in Pharo. Here is a couple of screenshots: [image: Inline image 2] [image: Inline image 1] [image: Inline image 3] A trailer is available here: https://www.youtube.com/watch?v=PhSmjR3NOlU A detailed description is available here: http://www.humane-assessment.com/blog/introducing-gtspotter It works already in Pharo 3.0 and can be played with by following the instructions from: http://gt.moosetechnology.org Please let us know what you think. Enjoy, The Glamorous Team

6 21

Deprecation of #children in Moose-Core and FAMIX-Core
by Blondeau Vincent 31 Mar '17

31 Mar '17

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.!!!"

1 0

Big models, memory and persistence
by Cyrille Delaunay 30 Mar '17

30 Mar '17

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

5 9

Re: [Pharo-users] Smacc debugger
by Tudor Girba 29 Mar '17

29 Mar '17

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."

1 0

Analyzing python application
by Alexandre Bergel 29 Mar '17

29 Mar '17

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

1 0

Fwd: GSoC 2017: Tips on Reviewing Student Proposals
by Serge Stinckwich 23 Mar '17

23 Mar '17

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/

1 0

a lot of new tests with errors
by Pavel Krivanek 23 Mar '17

23 Mar '17

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

1 1

Question
by Markus Böhm 22 Mar '17

22 Mar '17

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

3 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev March 2017