- Moose-dev - INF Mailman

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

9 years, 5 months

2
1
0 0

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

by Tudor Girba

What should we use instead? Array? nil when it’s empty? How about introducing some sort of a NilDictionary? Would anyone like to experiment? Cheers, Doru > On Jan 24, 2016, at 8:49 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > I think the use of SmallDictionaries for storing Famix state is not such a good idea. After loading the model: > > bag := Bag new . > SmallDictionary allInstances do: [ :each | bag add: each size ]. > bag sortedCounts > > "{530387->0. 19253->3. 18292->1. 20->2. 2->4. 2->11. 1->12}" > > bag := Bag new . > SmallDictionary allInstances do: [ :each | bag add: (each keys) ]. > bag sortedCounts > > an Array(530387->#() 19253->#(#cyclomaticComplexity #numberOfStatements #mooseName) 9311->#(#binding) 8707->#(#mooseName) 426->#(#comments) 20->#(#comments #ir) 13->#(#ir) 4->#(#comments #binding) 3->#(#binding #semanticWarning) 2->#('charset') 1->#(1 2 3 4 5 6 7 8 9 10 11 12) 1->#(14 15 16 17 18 19 20 21 22 23 24) 1->#(9 10 11 12 13 14 15 16) 1->an Array('-source-' #'`@method:' RBPatternVariableNode(`@args) '-pragmas-') 1->#(1 2 3 4 5 6 7 8 9 10 11) 1->{MooseModel} 1->{FAMIXAnnotationType. FAMIXClass. FAMIXNamespace. FAMIXMethod} 1->#(1 2)) > >

9 years, 5 months

2
1
0 0

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

by Stephan Eggermont

On 24-01-16 15:34, Vincent BLONDEAU wrote: > Yes, and we have to do several passes to construct the model with references > (so we store a mapping table). > Maybe a collection or two are GCed. Probably a bit more. Before loading, there were 172 instances of SmallDictionary. After loading, 558293, of which 30194 contain something. Stephan

9 years, 5 months

1
0
0 0

mse loading looks slower :(

by Tudor Girba

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

9 years, 5 months

2
2
0 0

Specific Domain Visualizations: a glimpse of medicine public data released by governments

by Offray Vladimir Luna Cárdenas

Hi, As I told you before, I have been using Pharo/Moose/Roassal to approach certain problems by agile prototyping and visualization. It has been a really empowering community and technology and even a newbie can feel more eloquent talking to/with computers, so thanks as always. Here is the blog post with more details: http://mutabit.com/offray/blog/en/entry/sdv-infomed And here the tweet if you're in that network and want to reshare: https://twitter.com/offrayLC/status/689854446541611008 Hopefully I have been clear in the blog, but any advice to my almost self taught English, or proof reading or improvements are welcomed. I also hope putting proper credits to all the people involved in this visualization. And hopefully soon (at some point in February) I will be sharing some advances in the interactive notebook front also. Cheers, Offray

9 years, 5 months

3
4
0 0

roassal2 seems to work well now

by Tudor Girba

Hi, With the latest development, Roassal2 seems to work well. For example, the rendering of the logical view of Glamour browsers was broken, and now it works well. This is great news. Is this just my impression? Do we know if there are still open issues with the FFI in this area? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

9 years, 5 months

7
23
0 0

Telescope

by Axel Lefaux

Bonjours, J'ai voulu installer Telescope sur Pharo 4.0. Hors lors de sa configuration, j'ai eu un Warning à propos de ce package qui dépend d'autre packages : This package depends on the following classes: RTObject RTView RTClusterLayout RTAbstractNormalizer RTShape J'ai donc téléchargé une image de Moose 5.1. L'installation réussie, j'ai essayé de suivre "Tutorial end-user" et lors du premier exemple, le message n'était pas compris, le receveur du "new" est "null". Cordialement, Axel Lefaux.

9 years, 5 months

3
3
0 0

[ann] spotter processors as settings

by Tudor Girba

Hi, We now have a new little feature in Spotter. Take a look: Basically, you will get a setting for each processor defined in the image. This happens dynamically. If you disable the setting, the processor will not be available anymore. Please give this a try and let us know what you think. We would also like a code review related to the way we deal with dynamic settings. Right now, the magic is done in GTSpotterExtensionSettings (this is real magic - read the class comment), but the current solution relies on a doesNotUnderstand: to maintain the list of disabled processors. I would more prefer it if we could create a DynamicSettingDeclaration that would be able to pass arguments to one central selector. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

9 years, 5 months

2
4
0 0

Script of the day: Charting several data sets

by Alexandre Bergel

Hi! Just in case you did not know, we have a MultipleData to chart using bars several data sets. For example: -=-=-=-=-=-=-=-=-= b := RTGrapher new. d := RTMultipleData new. d barShape color: Color blue. 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 barChartWithBarCenteredTitle: #first." d barChartWithBarTitle: #first rotation: -30. b add: d. b -=-=-=-=-=-=-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 5 months

1
0
0 0

Problem with Rubric?

by Alexandre Bergel

Hi! I regularly see very obvious problems with Rubric. I have just downloaded the latest Moose image and typing in a Playground and get an exception in: RubTextComposer>>recomposeFrom: start to: stop delta: delta Am I the only one? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 5 months

3
3
0 0

loading ozone in moose

by Usman Bhatti

I'm try to load Ozone in moose 5.1 but I got the following error: This package depends on the following classes: MalCyclesCoverageAndSort DSMMatrix DSMCellTest DSMCell NumberColoredDSM You must resolve these dependencies before you will be able to load these definitions: weightedSize testWeightedSize doLayerGraphModified .... Does anyone know what happened to the classes that are not found in the newer version because it loaded correctly in Moose 5.0 (Pharo 3.0)? Are these renamed or is there a package not loaded in the latest moose? tx!

9 years, 5 months

2
2
0 0

Sugiyama layout is now working...

by Alexandre Bergel

Hi! I have found and fixed a bug in the Sugiyama layout. Example of usage: b := RTMondrian new. b shape box color: Color red. b nodes: (1 to: 100). b edges connectFrom: [ :v | v // 2 ]. b layout sugiyama. b normalizer normalizeSize: #yourself; alphaColor: 0.4. b Here is a screenshot in Hapao: :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 5 months

2
1
0 0

spotter: top search for senders and references

by Tudor Girba

Hi, With the latest GT integration, we also integrated the search for senders and references from the first step. Here is a detailed explanation about it, including what we still want to do, how it’s done, and how to discover what else is around: http://www.humane-assessment.com/blog/spotting-senders-references-with-gtsp… Please let us know what you think. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

9 years, 5 months

1
0
0 0

a new version of gtdebugger

by Tudor Girba

Hi, A new version of GTDebugger was just integrated. Several issues were addressed. Some more notable things are: - the stack shows columns for class, method, other info - there are new keybindings in place that do not collide with the text editor - the accept/cancel buttons are in the contextual menu at least for Pharo 5 - the variables pane received a label There are still some things todos left like: - the columns in the stack should be resizable - thisContext, stackTop - perhaps make the key bindings controllable through settings We kindly invite everyone to test it and provide feedback. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

9 years, 5 months

1
0
0 0

Re: [Pharo-users] [ann] gtdebugger in pharo 5.0

by Nicolai Hess

2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: > the GTDebugger. As this is a significant change that might affect your > workflow, here is some background information to help you deal with the > change. > > First, you should know that the change is not irreversible and it is > easily possible to disabled the new debugger through a setting. However, > please do take the time to provide us feedback if something does not work > out for you. We want to know what can be improved and we try to react as > fast as we can. > > A practical change comes from the fact that the variables are manipulated > through a GTInspector, which makes it cheaper to maintain in the longer run. > Accept and Cancel buttons shouldn't be there or should not act on if the codepane hasn't changed. (every press on "accept" writes a new method version, although the contents didn't changed - tested on Latest update: #50524 ) Most (all?) other tools don't have Accept/Cancel buttons. - I really miss the "List Methods using 'varname'/List Methods storing into 'varname' - is "stackTop" now gone ? I thought you wanted to add it to the stack ? - thisContext is gone as well ? - the Bytecode/GT button is badly placed, it looks like the "downarrow" window menu icon is a dropdown menu with label "Bytecode" (since when do we put buttons in the title pane? - the evaluator pane is shown as "dirty", as it does not make a difference if we accept the text in this pane, there shouldn't be a dirty indicator. - you can not use the inspector pane to change inst var values - there is no way to refresh the inspector pane I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs but features. nicolai

9 years, 5 months

4
6
0 0

1 failing test (MooseQuery)

by Tudor Girba

Hi, So, the VM was updated and the become: issues are solved. There is now only 1 failing test: https://ci.inria.fr/moose/job/moose-6.0/1077/testReport/junit/Moose.Tests.F… The problem is that MooseOutgoingCompositeQueryResult doesNotUnderstand #atScope: I suspect it has to do with the new addition of the Moose Query implementation. Could someone look at the new Moose Query? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

9 years, 5 months

1
1
0 0

PetitParser Browser

by Anne Etien

Hi, Does anyone knows why when using PetitParser Browser, the debugger tab presents a tree composed of only one or maximum two elements (even if it enters more rules)? Any help will be useful because debugging petitParser code is really hard. Thanks. Anne

9 years, 5 months

2
2
0 0

Moebio framework

by Offray Vladimir Luna Cárdenas

Hi, I just want to share some recently released framework for data visualization and interaction that could serve as inspiration: http://moebiolabs.github.io/moebio_framework/ I'm thinking, which of the visualizations that are shown in the reel could *not* be done with Roassal and what is needed for that. Just for reference, a friend and I found a visualization that was not on Roassal a couple of months ago (see [1]) and it was a pleasure to create something that provides some support for visualizations that look alike (see [2][3][4]). [1] http://www.theguardian.com/world/interactive/2012/may/08/gay-rights-united-… [2] https://offray.withknown.com/2016/matrix-sunburst-visualization-example-for… [3] https://offray.withknown.com/2016/matrix-sunburst-visualization-example-for… [4] https://offray.withknown.com/2016/matrix-sunburst-visualization-example-for… Of course the best way to know if Roassal supports something like Moebio Framework is to approach some problem which produce a similar output. Cheers, Offray

9 years, 5 months

2
1
0 0

Re: [Pharo-users] [ann] gtdebugger in pharo 5.0

by Nicolai Hess

Accept and Cancel buttons shouldn't be there or should not act on if the codepane hasn't changed. (every press on "accept" writes a new method version, although the contents didn't changed - tested on Latest update: #50524 ) 2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: > the GTDebugger. As this is a significant change that might affect your > workflow, here is some background information to help you deal with the > change. > > First, you should know that the change is not irreversible and it is > easily possible to disabled the new debugger through a setting. However, > please do take the time to provide us feedback if something does not work > out for you. We want to know what can be improved and we try to react as > fast as we can. > > A practical change comes from the fact that the variables are manipulated > through a GTInspector, which makes it cheaper to maintain in the longer run. > > > While the first thing that will capture the attention is the default > generic interface, the real power comes from the moldable nature of the > debugger. Like all other GT tools, GTDebugger is also moldable by design. > This means that we can construct custom debuggers for specific libraries at > small costs (often measured in a couple of hundred lines of code). > > > > Here is an introductory overview blog post that also includes some links > for further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Beauty is where we see it." > > > > >

9 years, 5 months

1
0
0 0

[Survey] Forking Operating System Proces in Pharo

by Mariano Martinez Peck

Dear all, As I mentioned in the thread "Pharo Consortium Sponsored Development Effort" [1] I built a survey about Forking Operating System Processes in Pharo. The idea of the survey is simple: I want to understand what people needs the most, which features would be useful, which ones would not, what is missing, what is wrong, etc etc etc. As always, since we have limited resources, we should optimize them as much as possible. I count with you so that we can make a roadmap together on this project. Please, feel free to forward this survey anywhere where there could be an interest. https://www.surveymonkey.com/r/DHR22TL Best regards, [1] http://forum.world.st/ANN-Pharo-Consortium-Sponsored-Development-Effort-td4… -- Mariano http://marianopeck.wordpress.com

9 years, 5 months

2
2
0 0

happy lessons from recent talks

by Tudor Girba

Hi, I just wanted to share with you a bit of a different perspective on what we do around here. Over the past half a year I gave several talks to some 1k technical people at industrial events like ArchConf, NDC Oslo and several others. The tour will continue this year at OOP, ArchConf and a couple of other places. These are places where people talk about mainstream techniques & technologies (like Java, JS, C#). For example, ArchConf is a premier software architecture conference in the US. During these sessions, people get to experience Moose and Pharo through live demos. I use these demos as examples of how humane assessment (building your own analysis tools) can boost engineering decisions making in practice. I consistently receive the feedback that the live programming possibilities from Pharo/Moose are impressive. But, more recently, there is something else worthy of being noted. If in previous years, nobody heard about what we do, this year I started to get consistently a couple of persons in the room that have heard something about Pharo/Moose before the presentation. This is huge. While a couple might not sound like much, you should remember that information (especially in this technical space) has the capability of spreading exponentially. What we have done over the past years starts to show results. We have to keep it up. Happy New Year! 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."

9 years, 5 months

3
2
0 0

gtdebugger - icons with text and a couple of others

by Tudor Girba

Hi, Andrei and I took your feedback into account, and now we have this in the last version: - actions have text (this is a feature introduced in Glamour now) - the order of the code actions is better (accept is next to cancel) On top of that, there are a couple of extra features that we did not talk about until now: - whenever there is another kind of debugger available, a new button appears on the top right. When the Bytecode Debugger is loaded, you can always switch to it. Or, when you get in a situation in which the SUnit is available, you can switch to it. - the selection from the inspector is preserved when you move back and forth in the stack. - the panes in the inspector can be closed - stack highlighting is not on by default (it never was actually) - if you “Inspect and Go”, you inspect in place instead of the inspector at the bottom (no extra window) There are probably still glitches, but we think they are fixable. We still would like to add a couple of more features if there is time: - having a table in the stack to show class / method / package - having multiple inspectors in tabs when you inspect in place to not remove the original inspector Please let us know what you think. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

9 years, 5 months

2
1
0 0

4 tests failing

by Tudor Girba

Hi, It looks like in the Spur image, the ghost instances of GTInspector are gone. So, now we have only 4 tests failing, and they all seem to be related to a possible problem with become:. I am not yet sure what the solution is, but I raised this issue on the Pharo mailing list. Cheers, Doru -- www.tudorgirba.com www.feenk.com "It's not what we do that matters most, it's how we do it."

9 years, 5 months

5
5
0 0

gtdebugger in pharo 5.0

by Tudor Girba

Hi, We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). For example, the core configuration includes also the SUnit and the bytecode debugger. These are around 150 lines of code. Here is how the bytecode debugger looks like: You can find more information in an introductory overview blog post that also includes some links for further reading: http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ Please let us know what you think. Cheers, Doru -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

9 years, 5 months

6
14
0 0

Re: [Pharo-dev] [ann] gtdebugger in pharo 5.0

by Torsten Bergmann

Hi, with a moldable debugger we should (in the future) be able to support debugging also different/other programming languages/DSLs in Pharo :) - although usually one does necessary have such a use case. So I guess GTInspector or other will be adopted to own needs more than GTDebugger. However: The only objection so far is that I dislike the order/size of the panes. The placement of the panes in GTDebugger (as for instance found in Moose) requires often to use the scrollbars of the pane showing the stack because of the text length. In GTDebugger the stack is at the top left, the source at the top right with a common splitter beneath the two panes: therefore the height (depth) of the stack pane is always the height of the code pane. When you have a long method to debug on the right much space is wasted for a deep stack on the left although you might only be interested in a few top frames. Contrary when you have are interested in a deep/full stack and you increase the height of the stack pane on the left you directly increase the height of the code pane and for short methods you waste a lot of space in the source pane as well. This is much better solved with the positioning in the traditinal Debugger: - Stack - Source - other So in my opinion We should preserve: - TOP: the stack at the top (using the full width of the window, so only vertical scrolling has to be done to "roll" on the stack, no need for horizontal scrolling as the area is wide enough) - MIDDLE: the source code pane in the middle (also using the full width of the window and there fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) - BOTTON: one or more panel for inspection at the bottom It would be OK for me if others like the new layout better - but at least there should be an option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) Also the debugger window in Moose wastes a lot of space/has unused space within the windows client are itself. For instance the splitters are very thick which might be an issue of the moose theme. Thanks T. Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr Von: "Tudor Girba" <tudor(a)tudorgirba.com> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 Hi, We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). Here is an introductory overview blog post that also includes some links for further reading: http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ Please let us know what you think. Cheers, Doru -- www.tudorgirba.com[http://www.tudorgirba.com] www.feenk.com[http://www.feenk.com] "Beauty is where we see it."

9 years, 5 months

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev