Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

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

Roassal tests make moose6.1 build crashing
by Blondeau Vincent 22 Mar '17

22 Mar '17

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

4 7

Remote publish (but to a hard drive)?
by Cris Fuhrman 16 Mar '17

16 Mar '17

Hello all, I recently discovered Remote Publish for Playgrounds in Pharo. I'm wondering if there's a way to do the same thing, but to a specified file on my hard drive? As it stands, much of my Roassal experiments are in the Playground and I have been saving images (!) since I could not find a "Save as..." for the text file in the Playground. With big Moose models, saving images is overkill. The (non-lazy) alternative is to select all text in the Playground and copy/paste it into a Notepad++ file. Cheers, C. Fuhrman

4 7

Improved Grapher way of stacking data
by Alexandre Bergel 16 Mar '17

16 Mar '17

Hi! Just to share an improvement of Grapher, which is part of Roassal. The code: | b d classes | classes := (Collection withAllSubclasses reverseSortedAs: #numberOfMethods) first: 10. b := RTGrapher new. d := RTVerticalMultipleData new. d points: classes. d addMetric: #numberOfLinesOfCode. d addMetric: #numberOfMethods. d barChartWithBarTitle: #name rotation: -30. b add: d. b Produces: And this code: | b d classes | classes := (Collection withAllSubclasses reverseSortedAs: #numberOfMethods) first: 10. b := RTGrapher new. d := RTHorizontalMultipleData new. d points: classes. d addMetric: #numberOfLinesOfCode. d addMetric: #numberOfMethods. d barChartWithBarTitle: #name rotation: -30. b add: d. b Produces: Naturally, you can add several metrics: Consider: | b d classes | b := RTGrapher new. d := RTHorizontalMultipleData new. d points: #( #('hello' 1 2 1) #('world' 2 4 2) #('bonjour' 3 5 4) #('Gutten Morgen' -1 4 -5)). d addMetric: #second. d addMetric: #third. d addMetric: #fourth. d barChartWithBarTitle: #first rotation: -30. b add: d. b And: | b d classes | b := RTGrapher new. d := RTVerticalMultipleData new. d points: #( #('hello' 1 2 1) #('world' 2 4 2) #('bonjour' 3 5 4) ). d addMetric: #second. d addMetric: #third. d addMetric: #fourth. d barChartWithBarTitle: #first rotation: -30. b add: d. b -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

A quick analyzis of the usage of instance variables in Moose
by Guillaume Larcheveque 14 Mar '17

14 Mar '17

Hi Moose users, as you may know, at Synectique we experiment lots of issues about memory usage. That's why i had a look at the number of unused instance variables in one of our system loaded with a big model from one of our main customer. Total instance variables: 26.852.653 Used instance variables: 17.393.938 Empty collections: 5.023.508 Recoverable instance variables: 14.482.223 The recoverable instance variables are those with nil or an empty collection (or MultiValueLink) As you can see, we can save a lot of memory :-) Here is my (dirty) code to get that: countUsedInstanceVariableInForSubInstances: aClass | usedInstNbr instNbr emptyCollNbr | usedInstNbr := 0. instNbr := 0. emptyCollNbr := 0. aClass allSubInstancesDo: [ :anEntity | instNbr := instNbr + anEntity class allInstVarNames size. anEntity class allInstVarNames doWithIndex: [ :e :i | (anEntity instVarAt: i) ifNotNil: [ :content | ([ content isEmpty. emptyCollNbr := emptyCollNbr + 1. false ] on: MessageNotUnderstood do: [ false ]) ifFalse: [ usedInstNbr := usedInstNbr + 1 ] ] ] ]. ^ {('Used instance variables' -> usedInstNbr). ('empty collections' -> emptyCollNbr). ('Recoverable instance variables' -> (instNbr - (usedInstNbr - emptyCollNbr))). ('Total instance variables' -> instNbr)} -- *Guillaume Larcheveque*

6 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev