- Moose-dev - INF Mailman

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

8 years, 3 months

5
9
0 0

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

8 years, 3 months

1
0
0 0

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

8 years, 3 months

1
0
0 0

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/

8 years, 3 months

1
0
0 0

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

8 years, 3 months

1
1
0 0

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

8 years, 3 months

3
7
0 0

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

8 years, 3 months

4
7
0 0

Remote publish (but to a hard drive)?

by Cris Fuhrman

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

8 years, 3 months

4
7
0 0

Improved Grapher way of stacking data

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

8 years, 3 months

1
0
0 0

A quick analyzis of the usage of instance variables in Moose

by Guillaume Larcheveque

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*

8 years, 3 months

6
7
0 0

Roassal IdentityGroup regression?

by Peter Uhnak

Hi, apparently there used to be RTIdentityGroup (and Collection>>asIdentityGroup) in Rossal, but I can't find any mention of it http://forum.world.st/AST-visualization-with-Roassal-td4840243.html did it vanish on its own (bug) or was that a deliberate choice (feature)? Peter

8 years, 3 months

2
2
0 0

Re: [Pharo-dev] Re: Segmentation fault on Moose 6.1 Build

by Tudor Girba

Thanks. I have switched the Moose job back to using the latest image. Let’s see how it works. Cheers, Doru > On Mar 3, 2017, at 9:19 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Esteban created a working fix for this issue. > > Cheers, > -- Pavel > > 2017-03-03 3:16 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > To confirm specific reproducibility, using... > http://files.pharo.org/image/60/60421.zip > > I did... > $ cd opensmalltalk-vm > $ git checkout d54edc56 > $ git log > commit d54edc5638c9f90c80f214e59e19240f8ead87f8 > Author: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: Thu Mar 2 09:53:05 2017 -0800 > CogVM source as per VMMaker.oscog-eem.2143 > Fix regression in Sista sources due to receiverTags work. > > $ cd build.linux32x86/pharo.cog.spur/build.debug > $ cd products/debug/phcogspurlinuxht > $ pharo ~/temp/Case19785/Pharo-60421.image > > World > Playground, evaluate... > surf := AthensCairoSurface extent: Display extent. > Display getCanvas drawImage: surf asForm at: 0@0 > > 70% ==> image seg fault > 30% ==> PrimitiveFailed: primitive #primSignal:andReturnAs:fromContext: > > but doing > Smalltalk snapshot: true andQuit: true. > surf := AthensCairoSurface extent: Display extent. > Display getCanvas drawImage: surf asForm at: 0@0. > > 100% ==> PrimitiveFailed: primitive #primSignal:andReturnAs:fromContext: > > > Evaluate the following in Playground for 100% segfault from command line. > > EllipseMorph compile: 'step > |surf| > [ surf := AthensCairoSurface extent: Display extent. > Display getCanvas drawImage: surf asForm at: 0@0. > ] on: Error do: [ ]. > self position: self position + (50@0). "To observe survival of seg fault" '. > Smalltalk snapshot: true andQuit: true. > EllipseMorph new openInWorld. > > > btw, I'm on 32-bit Debian 8 Jessie > $ uname -a > Linux dom0 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 GNU/Linux > > cheers -ben > > > On Fri, Mar 3, 2017 at 12:08 AM, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Hi Eliot, > > > > > > > > Thanks to take care of this issue! > > > > > > > > Pavel opened a bug issue here: > > https://pharo.fogbugz.com/f/cases/19785/Athens-crashes-the-VM . You need the > > latest Pharo image and VM and it crashes under Linux (32-bit) and OSX (El > > Captain, 32-bit VM). And I personally tried with Windows7 and the bug > > happens too. > > > > > > > > To reproduce: Morph new testAthensRender > > > > > > > > An extract of the opened issue: > > > > > > > > Edited by Pavel Krivanek 02/03/2017 (Today) 16:10 > > > > An empty surface crashes it too: > > surf := AthensCairoSurface extent: Display extent. > > Display getCanvas drawImage: surf asForm at: 0@0 > > > > > > > > The problem is in the method AthensCairoSurface>>#asForm where the previous > > slice started to add 1 to surface heigth > > > > > > > > Well, I tried to revert AthensCairoSurface>>#asForm which fixes this > > particular case but Roassal still crashes on copyBits > > > > > > > > Cheers, > > > > Vincent > > > > > > > > De : Moose-dev [mailto:moose-dev-bounces@list.inf.unibe.ch] De la part de > > Eliot Miranda > > Envoyé : jeudi 2 mars 2017 17:03 > > À : Pharo Development List > > Cc : Moose-related development; Squeak Virtual Machine Development > > Discussion > > Objet : [Moose-dev] Re: [Pharo-dev] Segmentation fault on Moose 6.1 Build > > > > Hi Vincent, > > > > first, apologies for the inconvenience, second, thanks! I badly need > > reproducible failure cases to get the remaining bugs out of the compactor > > and you have just provided me with one. Can you send me the information I > > need to reproduce the build? What platforms does it fall on? > > > > On Thu, Mar 2, 2017 at 2:23 AM, Blondeau Vincent > > <vincent.blondeau(a)worldline.com> wrote: > > > > Hi, > > > > The latest builds of the Moose6.1 image are failing due to a segmentation > > fault. > > > > Here is the link to the last build: > > https://ci.inria.fr/moose/job/moose-6.1/550/console > > > > How can we fix this? > -- www.tudorgirba.com www.feenk.com "Beauty is where we see it."

8 years, 3 months

5
5
0 0

How to know when a playground was executed and storing the result?

by Offray Vladimir Luna Cárdenas

Hi, For the Grafoscopio notebook I would like to store the results of playground executions. That would imply to know when a playground was executed and which was the result[1]. We have been talking about that in the Pharo users mailing list and Ben and Phill are bringing some light on that, but I would like to invite Moose community to participate also. I have been looking at some inspector and playground blog posts, but the ones I have found are about creating custom views of objects you would like to extend, instead of capturing the output. [1] http://forum.world.st/How-to-capture-the-execution-of-a-playground-tt493627… There is any way to do that? Offray

8 years, 3 months

1
0
0 0

Google Summer of Code 2017: Call for mentors for Pharo Consortium

by Serge Stinckwich

Heartiest Congratulations ! Pharo Consortium has been selected as a mentor organisation for Google Summer of Code 2017. Google Summer of Code is a global program focused on introducing students to open source software development. Students work on a 3 month programming project with an open source organisation during their break from university. Read more at https://summerofcode.withgoogle.com/ How the program works ? Organizations: Open source projects apply to be mentor organizations. Once accepted, organizations discuss possible ideas with students and then decide on the proposals they wish to mentor for the summer. They provide mentors to help guide each student through the program. Mentors: Existing contributors with the organizations can choose to mentor a student project. Mentors and students work together to determine appropriate milestones and requirements for the summer. Mentor interaction is a vital part of the program. A mentor may propose or endorse a project and each project has to be about Pharo or its ecosystem (e.g., a library). Projects will be mentored by one or more mentors and executed by one student. Students: Students contact the mentor organizations they want to work with and write up a project proposal for the summer. If accepted, students spend a month integrating with their organizations prior to the start of coding. Students then have three months to code, meeting the deadlines agreed upon with their mentors. Student coding period: May 30 - Aug 29 (Entire timeline can be viewed at: https://summerofcode.withgoogle.com/how-it-works/#timeline). Student stipend: https://developers.google.com/open-source/gsoc/help/student-stipends We are currently at the phase of identifying mentors and projects. The next phases will be about students selecting projects, and the community selecting the projects with their associated mentors and students which will be sponsored by the GSOC program. How to register ? Simply by replying to this email and joining the Slack channel... to have more discussion about what project the mentor will take up, what she/he wants at the end of the coding period and then we can invite them to the GSoC org dashboard). Hence, we invite regular & enthusiastic Pharo contributors to be a mentor with Pharo Consortium for GSoC 2017: 1. Kindly respond on this thread if you'd like to be a mentor, or wish to propose a project. An existing list of projects is already available here: http://gsoc.pharo.org/ and we already have a handful of projects and mentors chosen. Feel free to collaborate with existing mentors as well. 2. Join dedicated channels, #gsoc-students for general interactions with students & #gsoc-planning channel only for GSOC admins and mentors on Pharo slack. In order to get an invitation for pharoproject.slack.com visit the URL here: http://slackinvites.pharo.org/ 3. Please open relevant issues and make a roadmap of the projects being mentored by you so that students can start contributing to them already. If you want to mentor a project and there is no open-source repository at the moment, please built one ASAP. 4. If you know any students that might be interested to work on Pharo during the summer and be a part of GSoC as well, please ask him/her to start contributing to the Pharo projects, discuss their proposal, follow instructions that shall be posted soon in this mailing thread and submit their application by April 3, 2017. We don't know the number of slots attributed by Google to Pharo org, but the more students proposal we will receive, the more slots will be attributed to us. We remind you about the mentor responsibilities: ... to your Org Admins - Communicate availability and interaction expectations - Inform when mentoring capacity will be reduced, as early as possible (e.g., family, health, vacation) - Inform when there is an issue with a student - Lacking communication, activity, visibility (MIA), or progress - Participant Agreement violations (e.g., plagiarism, harassment, fraud) - Bad fit or stepping down - Formally evaluate student participation. - Communicate with admin and student before failing ... to your Students - Help and/or teach the student - how to be a part of your community - communicate more effectively and in the open - work with your org’s preferred communication channel (IRC, Slack, etc) - use your org’s version control system - ask good questions and get answers to their questions - provide convincing technical argument and constructive discussion - be independently motivated and productive - solve difficult technical problems - Keep track of their progress, keep student informed as to their status - Communicate on a regular basis, once a week or better (for GSoC) - Give constructive feedback, be patient, and be respectful - Respond to questions within 24 hours (occasionally under 36 hours is ok) - Establish realistic work objectives and timeline expectations - Re-evaluate scope with student when significantly ahead of or behind expectations - Work with devs and community to facilitate acceptance of student work Read more about responsibilities here: https://developers.google.com/open-source/gsoc/help/responsibilities Looking forward to a great guided summer by the talented mentors of our organisation. Warm Regards Pharo Organisation Admins (Alexandre Bergel, Jigyasa Grover, Serge Stinckwich & Yuriy Tymchuk)

8 years, 3 months

1
1
0 0

roassal2 job

by Tudor Girba

Hi, Something seems to be wrong with the Roassal2 job: it does not end. Could someone take a look? https://ci.inria.fr/moose/job/roassal2/ Cheers, Doru -- 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."

8 years, 4 months

2
1
0 0

[Moose-dev] Student of Stéphane Ducasse: Roassal project

by said yebbah

Hello, We‘re a group of 3 students from a course with Stéphane Ducasse in university of Lille 1, and we’re beginners in Pharo and for the next 2 weeks we have to work on an open source project. we choose Roassal project. So we would like to know what's the prupose of ideas that we've to do ? In fact, in the moments we're at the point of discovering Roassal. Thanks,

8 years, 4 months

4
3
0 0

Re: Student of Stéphane Ducasse: Roassal project

by Serge Stinckwich

This is better to answer on the mailing-list. Regards, On Fri, Mar 3, 2017 at 3:30 PM, said yebbah <said.yebbah(a)hotmail.com> wrote: > Bonjour, > > > First we thank you in advance for your reply, it seems an interesting > suggestion project, we'll try to start doing the same thing with Roassel > but for the moment we're beginners and we have only 2 weeks, we wish that > you help us for the next time. > > > this's list email of other memebers group: > > hamid.lafredi(a)etudiant.univ-lille1.fr > > martin.bigand(a)etudiant.univ-lille1.fr > > > > > > > On Fri, Mar 3, 2017 at 2:34 PM, said yebbah <said.yebbah(a)hotmail.com> > wrote: > > Hello, > > Bonjour, > > > We‘re a group of 3 students from a course with Stéphane Ducasse in > > university of Lille 1, > > and we’re beginners in Pharo and for the next 2 weeks we have to work on > an > > open source project. > > we choose Roassal project. So we would like to know what's the prupose of > > ideas that we've to do ? > > In fact, in the moments we're at the point of discovering Roassal. > > Welcome in the community ! > > I have one idea for a small project for students. > I give this link to my students for a lecture at Paris 6 University, > is it possible to do the same with Roassal: > https://github.com/SergeStinckwich/ARE-UPMC/blob/ > master/ARE-DYNAMIC/fiche3.ipynb > and if not how you fix that ? > > Thank you. > > -- > Serge Stinckwich > UCN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > Serge Stinckwich - Home | #DNU <http://www.doesnotunderstand.org/> > www.doesnotunderstand.org > Welcome to #DNU! #DNU is the home page of Serge Stinckwich, full-time > computer scientist and part-time Smalltalk evangelist. Important We are > currently conducting a ... > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > Moose-dev Info Page - unibe.ch > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > www.list.inf.unibe.ch > To see the collection of prior postings to the list, visit the Moose-dev > Archives. Using Moose-dev: To post a message to all the list members, send > ... > > > -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

8 years, 4 months

1
0
0 0

Different versions of Moose 6.0

by Serge Stinckwich

Dear all, apparently Moose 6.0 version available on the website: http://www.moosetechnology.com/ is not the same version used on SmalltalkCI. 1st one is : Pharo5.0 Latest update: #50761 and the other one: Pharo5.0 Latest update: #50770 Is it possible to have same version on both sides ? :-) Because we have some code that only fails on the CI and this source of confusion. Regards, -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

8 years, 4 months

1
0
0 0

Re: [Pharo-dev] Growing large images: the case of Moose models

by Blondeau Vincent

Thanks Eliot for the implementation of the new compactor! Just to add a piece of information: the mse imported have a size of 40Mb. Cheers, Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Clément Bera Envoyé : vendredi 3 mars 2017 11:56 À : Discusses Development of Pharo Objet : [Pharo-dev] Growing large images: the case of Moose models Hello everyone, This morning I investigated with Vincent Blondeau a problem reported by the Moose community a while ago: loading Moose model is slower in Spur (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this problem was present for anyone growing images to a significant size. To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb image, growing the image to 450Mb. Loading such a model takes 2 minutes in Spur and 1m30s in pre-Spur VMs. Using the stable Pharo VM, the analysis results were the following: - total time spent to load the Model: 2 minutes - time spent in full GC: 1 minute (4 fullGCs) - time spent in scavenges[1]: 15 seconds On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% in scavenges, 37.5% executing code. We then used the latest VM that features the new compactor (VM from beginning of March 2017 and over). The full GC execution time went down from 1 minute to 2 seconds. In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time spent in scavenges decreased from 15 seconds to 5 seconds. Overall, loading the model is now taking ~50 seconds instead of 2 minutes. To increase Eden size, one needs to run a script similar to: | currentEdenSize desiredEdenSize | currentEdenSize := Smalltalk vm parameterAt: 44. desiredEdenSize := currentEdenSize * 4. Smalltalk vm parameterAt: 45 put: desiredEdenSize. And then restart the image. I hope this report can be useful for some of you. I will try to make a blog post out of it, detailing other GC settings one can change from the image to improve performance. Best, Clement [1] A scavenge is basically the garbage collection of only young objects [2] Eden is basically the space where objects are initially allocated. [3] All numbers in the report are order of magnitudes and not precise numbers !!!************************************************************************************* "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.!!!"

8 years, 4 months

2
1
0 0

Segmentation fault on Moose 6.1 Build

by Blondeau Vincent

Hi, The latest builds of the Moose6.1 image are failing due to a segmentation fault. Here is the link to the last build: https://ci.inria.fr/moose/job/moose-6.1/550/console How can we fix this? 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.!!!"

8 years, 4 months

4
6
0 0

Re: [Pharo-dev] Re: Segmentation fault on Moose 6.1 Build

by Tudor Girba

Hmm, it looks like something changed and the build is now yellow. Does anyone have the time to check this mysterious behavior? Cheers, Doru > On Mar 2, 2017, at 1:24 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > I will try to make some easier way to reproduce it and open an issue > > -- Pavel > > 2017-03-02 11:58 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hm, I haven't check the time of the failing build... Yes, it will be related... > > 2017-03-02 11:51 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Except for tiny changes in Athens in 60419 :) > > Doru > > > > On Mar 2, 2017, at 11:33 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > On image side nothing relevant happened in 60418 where it started to fail. > > > > -- Pavel > > > > 2017-03-02 11:31 GMT+01:00 Blondeau Vincent <vincent.blondeau(a)worldline.com>: > > I heard that the gc compactor have changed. > > > > Cheers, > > Vincent > > > > > -----Message d'origine----- > > > De : Moose-dev [mailto:moose-dev-bounces@list.inf.unibe.ch] De la part de > > > Tudor Girba > > > Envoyé : jeudi 2 mars 2017 11:29 > > > À : Pharo Development List > > > Cc : Moose-related development > > > Objet : [Moose-dev] Re: [Pharo-dev] Segmentation fault on Moose 6.1 Build > > > > > > Hi, > > > > > > Was there a change related to the stable VM? > > > > > > Cheers, > > > Doru > > > > > > > > > > On Mar 2, 2017, at 11:23 AM, Blondeau Vincent > > > <vincent.blondeau(a)worldline.com> wrote: > > > > > > > > Hi, > > > > > > > > The latest builds of the Moose6.1 image are failing due to a segmentation > > > fault. > > > > Here is the link to the last build: > > > > https://ci.inria.fr/moose/job/moose-6.1/550/console > > > > > > > > How can we fix this? > > > > > > > > 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.!!!" > > > > <dump.txt> > > > > > > -- > > > www.tudorgirba.com > > > www.feenk.com > > > > > > “Live like you mean it." > > > > > > _______________________________________________ > > > Moose-dev mailing list > > > Moose-dev(a)list.inf.unibe.ch > > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > !!!************************************************************************************* > > "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.!!!" > > > > -- > www.tudorgirba.com > www.feenk.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > > > -- www.tudorgirba.com www.feenk.com "Beauty is where we see it."

8 years, 4 months

3
5
0 0

Google Summer of Code 2017: Call for students for Pharo Consortium

by Serge Stinckwich

*** Please forward this message to students that might be interested *** Heartiest Congratulations ! Pharo Consortium has been selected as a mentor organisation for Google Summer of Code 2017. Google Summer of Code is a global program focused on introducing students to open source software development. Students work on a 3 month programming project with an open source organisation during their break from university. Read more at https://summerofcode.withgoogle.com/ Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback (think IDE and OS rolled into one). Everything in Pharo is an object. The entire syntax of Pharo fits on a postcard coding can be done directly in the debugger. Pharo has super cool tools that empower you and make you super efficient. Pharo's goal is to deliver a clean, innovative, free and open-source immersive environment. By providing a stable and small core system, excellent developing tools, and maintained releases, Pharo is an attractive platform to build and deploy mission critical applications. Pharo fosters a healthy ecosystem of both private and commercial contributors who advance and maintain the core system and its external packages. More information about Pharo is available here: http://www.pharo.org/ We invite all the prospective eligible students to code their summer away with Pharo Consortium. Student Responsibilities ...to your Mentor - Submit quality work - Regularly communicate work completed, what you intend to do next, and blockers - Ask for help when something is preventing you from achieving a goal - Give indication that you are alive and working daily (GSoC) - Re-evaluate work scope when significantly ahead of expectations (GSoC) - Communicate with your mentor AND the broader community - Inform when work capacity will be reduced, as early as possible (e.g., family, health, other work) (GSoC) - Listen and respond to feedback ...to the Org Admin Let them know when there are - Interaction issues with any mentor or community member - Significant disagreements involving your work or changes to your work plan Read more about responsibilities here: https://developers.google.com/open-source/gsoc/help/responsibilities Hence, we invite enthusiastic student developers contributors to work with Pharo Consortium for GSoC 2017. 1. A first list of projects are available here : http://gsoc.pharo.org/ but more can be found by interacting with mentors from the Pharo community. 2. Join dedicated channels, #gsoc-students for general interactions with students on Pharo slack. In order to get an invitation for pharoproject.slack.com visit the URL here: http://slackinvites.pharo.org/ Discuss with mentors about the complexity and skills required for the different projects. 3. Please help fix bugs, open relevant issues, suggest changes, additional features, help build a roadmap, and interact with mentors on mailing list and/or slack to get a better insight into projects. Better the contributions, Better are the chances of selection. Before applying: * Knowledge about OOP * Basic idea about Pharo & Smalltalk syntax and ongoing projects * Past experience with Pharo & Smalltalk * Interaction with organisation You can start with the Pharo MOOC : http://files.pharo.org/mooc/ Guidelines for Proposal: * Introduction: Clearly defined problem. Current state of things. Issues you wish to solve and why. Conclude with solution. * Project goals: Format it like a list. Propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned. It is better to promise less and deliver more than to promise a lot and then fall short. * Implementation: Longer and more detailed. Provide technical details, show that you understand the technology and illustrate key technical elements of your proposed solution. * Timeline: Make it weekly. Set goals for each week. Be upfront about other commitments, including exams, classes, travel, internships, jobs, etc. * Benefits to Community: Make your case a benefit to the organization. * Related Work: Research and write how the project fits into the target organization. Explain related works, similarities & differences. * About me: Provide full contact information, email addresses, websites, IRC nick, postal address and telephone. Write a few sentences about yourself, previous experiences and why you think you’re the best for this job. Submit your proposal early. Keep it short. Include necessary information. Get it reviewed in the mailing list or Slack channel before submitting it. The deadline for submitting your proposal is March 20th to April 3rd on https://summerofcode.withgoogle.com/ Looking forward to great talent joining our organisation this summer. Warm Regards Pharo Organisation Admins (Alexandre Bergel, Jigyasa Grover, Serge Stinckwich & Yuriy Tymchuk)

8 years, 4 months

1
0
0 0

Roassal examples browser - too many items

by Ben Coman

Just some quick feedback... in the "Moose Suite 6.0 (beta)" image from PharoLauncher I opened World > Roassal > Roasasal Examples Nice interface, but for the category "Grapher - Overall" I find there are too many items, such that even the text labels are too small to read. It might be better to split this out to a few more categories. cheers -ben

8 years, 4 months

3
2
0 0

ElasticBoxZoom

by Ben Coman

I loaded Roassal into Pharo 60411 and tried #exampleElasticBoxZoom. I select a major portion of the graph, but it zooms down onto one of the tiny axis tick-marks. Is there an issue tracker that is a better place to report this? cheers -ben P.S. I was trying to run Moose 6.0 (beta) from Pharo Launcher on top of a recent VM Feb 22 2017. It was locking up and crashing and I wasn't sure how the versions aligned, so switching to loading Roassal from catalog into 60411 has been running fine.

8 years, 4 months

2
2
0 0

GTInspector duplicates overriden extensions

by Peter Uhnak

Hi, when I override a method with a GTInspector (because I need to change it), then inspector contains the extension twice. It seems Inspector scans the whole hierarchy of the inspected object for methods, but doesn't deduplicate them. Peter

8 years, 4 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev