Moose-dev January 2017

moose-dev@list.inf.unibe.ch

21 participants
22 discussions

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

08 Mar '24

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

4 3

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

24 Mar '18

Hello, Is there a way to set a default selection to a list presentation? so that when I open the browser, the morphic list has already a value selected. I tried that: |tmpBrowser| tmpBrowser := GLMTabulator new. tmpBrowser row: #list. tmpBrowser transmit to: #list; andShow: [:a | a list display: [:input | input]; selection: #a; yourself ]. tmpBrowser openOn: #( b c d v a d f r). but the list still open with nothing selected

3 4

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

23 Sep '17

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

6 21

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

Mondrian edge styling
by Wm Annis 03 Feb '17

03 Feb '17

As part of a larger project I'm trying to recreate some functionality that can be seen here: http://clics.lingpy.org/browse.php?gloss=carry+%28bear%29&view=community At this point I can slurp the data out of a database and get a graph with Mondrian. What I cannot figure out is how I might change the styling on the edges to represent weights. All I have found so far is RTEdgeBuilder>>#label:, which is better than nothing, but is sort of a mess visually in complex graphs. Changing edge width would be tidier. I'm still working my brain around how Smalltalk does things, so my apologies in advance if I'm missing something obvious. -- wm -- View this message in context: http://forum.world.st/Mondrian-edge-styling-tp4932317.html Sent from the Moose mailing list archive at Nabble.com.

3 4

Memory leaks
by Alexandre Bergel 31 Jan '17

31 Jan '17

Hi! It looks like that we are currently suffering memory leaks. In march 2015 it was said in the mailing list: -=-=-=-=-=-=-=-= I also tried this: 1. Create a dummy class: Object subclass: #AAA instanceVariableNames: 'x' classVariableNames: '' category: 'AAA'. 2. Open a Playground and do it and go on this: a := #AAA asClass new. 3. In the second pane go on "self" 4. Close the Playground 5. Execute: 3 timesRepeat: [ Smalltalk garbageCollect ]. 6. Check: #AAA asClass allInstances. 7. Repeat if necessary, and after a while, the result after step 6 is not empty. -=-=-=-=-=-=-=-= The problem is still present. Looking at the pointers There was an object reference crawler no? I remember someone worked on this? I tried sending #pointersTo but I without much success on identifying the cause of this leak. Any idea? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 4

failing tests on Moose 6.0
by Usman Bhatti 30 Jan '17

30 Jan '17

Hi, There are a few failing tests on Moose 6.0. https://ci.inria.fr/moose/job/moose-6.0/2418/testReport/ I would like to know if these tests represent some important functionality that might cause bugs in the image. Principally, the tests are related to Spotter and GT-examples. I think we might be missing a #stable version to load these packages correctly in Moose 6.0. I am going to use Moose 6.0 for a training so I would like to avoid bugs during my presentation. regards. Usman

1 0

[Jdt2Famix] Parsing of innerclasses creates unamed methods
by Blondeau Vincent 25 Jan '17

25 Jan '17

Hi, By generating some models with the Jdt2Famix java parser, I rose an issue with the anonymous classes. It appears that some methods and classes generated have no name (i.e. getName() = ""). For instance, this code: public static void method(String name) { Comparator<String> comparator = new Comparator<String>() { @Override public int compare(String string1, String string2) { return string1.toString().compareTo(string2.toString()); } }; } should model a stub constructor: Comparator. But, there is no such method and only an empty method belonging to the container class is created. Consequently, it is harder to find them in the model ... I opened an issue https://github.com/girba/jdt2famix/issues/34 and added some tests that you can found in the PR: https://github.com/girba/jdt2famix/pull/33 Can someone take a look at this problem? 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.!!!"

1 0

BUG - MooseModel resetMeta
by Anne Etien 23 Jan '17

23 Jan '17

Hi, I am developing a tool based on Fame pragma. Considering the following methods: FAMIXSQLExpression >>referencedRequests <MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued> <MSEComment: 'List of requests referenced by the expression.'> ^ referencedRequests FAMIXRequest >>usedInExpression <MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests> <MSEComment: 'Expression in which the request is used.'> ^ usedInExpression (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true. However, I don’t have always the same behavior after each resetMeta. (1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ]. always halts, at some unpredictable iteration (usually less than 10) Does someone has any idea what is the problem and how to solve it? By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/ <https://ci.inria.fr/moose/job/MooseSQL/> Thanks in advance for your help. Anne

6 9

edges attach point issues with tree layout
by Tudor Girba 15 Jan '17

15 Jan '17

Hi, I have a tree layout scene and I am trying to add on top other edges that do not affect the layout and that should have a centered attach point. However, the edges are still being drawn from bottom to top, like the rest of the edges from the tree layout. I think this is a bug. What do you think? Here is the example: view := RTMondrian new. view shape label. view nodes: (1 to: 10). edges := view edges connectFrom: [ :x | x//2 ]. view layout tree userDefinedEdges: edges. view shape arrowedLine color: Color red; centeredAttachPoint. view edges source: {3->2 . 9->7} connectFrom: #key to: #value. view http://ws.stfx.eu/QX0KW6F3QYC0 Cheers, Doru -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev January 2017