Moose-dev

moose-dev@list.inf.unibe.ch

6630 discussions

by Sean P. DeNigris

Would it make sense to move the contents presentation from FileReference to AbstractFileReference? I ask because I often use FileLocators, for which the presentation is not currently available. Thanks! Sean ----- Cheers, Sean -- View this message in context: http://forum.world.st/File-Presentation-Move-Up-tp4871359.html Sent from the Moose mailing list archive at Nabble.com.

8 years, 11 months

Moose 6.0 Roassal crashing

by Sebastian Heidbrink

Hi! I already filed a bug on this but I am wondering if somebody here on the list might have a temporary workaround. I just downloaded the most current Moose-6.0 image and I also use the most recent SpurVM. On Windows 7 and 8 the PharoVM crashes once one moves the mouse pointer of a Roassal view containing e.g. a graph. Is there a particular built I could load to make this work until a fix might be published? Thanks Sebastian

8 years, 11 months

[Roassal2] RTResizable leaves callbacks with each selection

by Jan Blizničenko

Hello again This time I bring a problem without offering solution because I haven't managed to look deep enough into it yet. RTResizable leaves callbacks for handles on the selected element even afrer deselection (calling RTResizable>>#removeHandles). It means that following screnario happens: - I click on element -> handles are created and their callbacks are created - I click anywhere else -> handles are removed but their callbacks are not removed - I click on that element again -> handles are created again but new callbacks are created ...etc... So with each select, new callbacks are created and are added to previous ones. Those callbacks are created in RTResizable>>#showHandles - RTResizable>>#attachHandle:toCorner: - RTConstraint>>#stick. I did not notice any performance (or other) issues caused by this in Roassal resizableExample, but it causes performance problem in few (but important) cases in our DynaCASE (I am not sure why only there). Jan -- View this message in context: http://forum.world.st/Roassal2-RTResizable-leaves-callbacks-with-each-selec… Sent from the Moose mailing list archive at Nabble.com.

8 years, 11 months

Fwd: GSOC 2016

by Serge Stinckwich

---------- Forwarded message ---------- From: Serge Stinckwich <serge.stinckwich(a)gmail.com> Date: Thu, Feb 11, 2016 at 2:02 PM Subject: GSOC 2016 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Dear pharoers, this year Pharo consortium (and community) is going to take part in the Google Summer of Code event[1] as a standalone organization. This is an opportunity to promote Pharo, get some job done and have students paid. Currently we are at the most important stage as we are preparing the organization application, and hoping that we will be accepted and granted decent amount of project slots. Everyone can help with application by submitting ideas for student projects. I reuse the list of the last year : https://github.com/pharo-project/pharo-project-proposals/blob/master/Topics… It is in STON format, and result is being generated at: http://gsoc.pharo.org/ Please add (or update) your ideas following the format of existing projects and open a pull request with them (you will need a github account). Preferably submit ideas with possible mentors, but if none are available at the moment ideas without mentors are also welcome. The template to submit projects is : PharoTopic new title: 'The name of your project; contact: 'email address'; supervisors: 'Supervisors names'; keywords: 'keywords separated by spaces; context: 'a description of the context of the project'; goal: 'description of the goal'; level: 'Beginner or Intermediate or Advanced'; yourself. We will need a lot of projects/idea before February 19th 2016, the deadline for applying to GSOC 2016. Do not hesitate to ask me questions. If you don't know how to edit the list, please send your project description following the template to me. [1] https://summerofcode.withgoogle.com/ Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

8 years, 11 months

an example of debugging with moldable tools

by Tudor Girba

Hi, One thing we noticed over the past year since we introduced GT in Pharo is that people still tend to use these tools in a similar way classic tools were used. We think there is a more potential in these tools. To change this, we would like to collect stories of how using these tools enabled a workflow that was otherwise not possible. To get this started, we will start to document more consistently some of the sessions, and we would like to get input from your as well. The idea is to create a catalog of tutorials that people can follow and get inspired from. Let me start. I recently had to debug a small problem, and I ended up having an experience that I found beautiful: http://www.humane-assessment.com/blog/debugging-duplicated-behavior-with-gt… What do you think? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

8 years, 11 months

How to search in play-cache?

by Alexandre Bergel

Hi! There is something I do not understand with the play-cache. I have a file titled: 2016-01-21T16-47-20-368238-03-00.ph with the following content: -=-=-= -=-=-= -=-=-= -=-=-= Gofer it smalltalkhubUser: 'abergel' project: 'ObjectEvolutionBlueprint'; package: 'ObjectEvolutionBlueprint'; load. Gofer it smalltalkhubUser: 'rschulz' project: 'EvolutionMonitor'; package: 'EvolutionMonitor'; load. Gofer it smalltalkhubUser: 'rschulz' project: 'ObjectEvolutionExamples'; package: 'ObjectEvolutionExamples'; load. -=-=-= -=-=-= -=-=-= -=-=-= Entering “ObjectEvol” in spotter does not show the entry in the play-cache. How to search into play cache then? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

8 years, 11 months

new stable FASTCore

by Usman Bhatti

I created a new #stable for FASTCore. Let me know if that breaks anything. Name: ConfigurationOfFASTCore-usmanbhatti.8 Author: usmanbhatti Time: 25 January 2016, 3:36:18.412281 pm UUID: 5c183c5f-f566-45b1-bb4a-777927f41728 Ancestors: ConfigurationOfFASTCore-VincentBlondeau.7

8 years, 11 months

Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Vincent BLONDEAU

Hi, I made the benchmarks with the files you provided. I have more or less the same magnitude: Version 504: 0:00:01:09.021 Version 1175: 0:00:02:37.507 However, by launching it in the time profiler (MooseModel new importFromMSEStream: (StandardFileStream readOnlyFileNamed: 'd:/ArgoUML-0-34.mse')), it takes 504: 1 min 55 1175: 4 min 25 Well there is a delta... After investigation, the standard process has almost the same duration (120 secs for prespur and 140 secs for spur). But, there is a large difference in GC time: 504: not spur **Memory** old +144,822,000 bytes young -8,293,660 bytes used +136,528,340 bytes free -104,186,788 bytes **GCs** full 1 totalling 965ms (1.0% uptime), avg 965.0ms incr 3264 totalling 42,279ms (33.0% uptime), avg 13.0ms tenures 2,497 (avg 1 GCs/tenure) root table 0 overflows 1175: spur **Memory** old +0 bytes young +340,048 bytes used +340,048 bytes free -340,048 bytes **GCs** full 7 totalling 145,003ms (66.0% uptime), avg 20715.0ms incr 3288 totalling 30,912ms (14.0% uptime), avg 9.0ms tenures 7,146,505 (avg 0 GCs/tenure) root table 0 overflows Total GC time 504: 43 secs 1175: 176 secs See the performance reports attached. I let VM people take care of the issue ;) Cheers, Vincent -----Original Message----- From: moose-dev-bounces(a)list.inf.unibe.ch [mailto:moose-dev-bounces@list.inf.unibe.ch] On Behalf Of Tudor Girba Sent: dimanche 24 janvier 2016 09:08 To: Moose-related development Subject: [Moose-dev] Re: mse loading looks slower :( Hi, I am talking about the difference between Moose 6 images: - October 7: https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip - yesterday: https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip Multiple things did change, but not in Moose. In the end, I would like to understand where the slowness comes. Maybe it comes from Spur itself, but maybe it comes from somewhere else. Cheers, Doru > On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Doru...just to be sure it is not a Pharo (image change), when you said before and after Spur, do you mean a Pharo 5.0 exactly (just before Spur) and a Pharo JUST after it? Otherwise, the slowness may come from the difference between the 2 Pharos you are running. > > Cheers, > > On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am doing some performance testing of Moose with the Spur VM on Mac. > > I tried to load an MSE file with ArgoUML 0.34 and on my machine it loads twice as slow with Spur than before: > - PreSpur: 0:00:01:07.272 > - Spur: 0:00:02:10.508 > > Here is the reference file: > https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip > > And here is the script: > [ > MooseModel new > importFromMSEStream: (StandardFileStream readOnlyFileNamed: > (FileSystem workingDirectory / 'src' / 'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName). > ] timeToRun > > Do you get the same? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing the problem in a way > that makes the solution obvious." > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > -- > Mariano > http://marianopeck.wordpress.com > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?" _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

8 years, 11 months

Moose image font is sharp

by Blondeau Vincent

Hi, I just opened a new Moose image and the font is sharper than a Pharo image... Is it wanted? [cid:image001.png@01D1577F.87DDFAF0] Updating the font doesn't resolve the problem. PS: I am using Windows7. 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, 11 months

Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Eliot Miranda

Hi Stephan, On Sun, Jan 24, 2016 at 1:04 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 24-01-16 21:20, Eliot Miranda wrote: > >> Hi Vincent, >> >> I'll take a look early this week. There's clearly a bug; the Spur >> GC is /not/ collecting those dictionaries :-( (thanks Stephan!). >> > > I'm afraid the dictionaries are part of the model and should not be > garbage collected. They do make things slow though, so we need a better > model. Garbage collection cycle takes a few seconds now on my 4 GHz 4790K > 32GB. So Vincent's awful sats are no longer showing up? He reported a 140 second GC pause. What are you seeing? (.i.e. can you post the full stats?) If this has disappeared then I suspect my Slang bug, which I fixed yesterday. But I will investigate. > Stephan > _,,,^..^,,,_ best, Eliot

8 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev