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 := GLMTabulator new.
tmpBrowser row: #list.
tmpBrowser transmit to: #list; andShow: [:a |
display: [:input | input];
tmpBrowser openOn: #( b c d v a d f r).
but the list still open with nothing selected
Alex Syrel, Andrei Chis and I are happy to announce a new addition to the
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
Here is a couple of screenshots:
[image: Inline image 2] [image: Inline image 1] [image: Inline image 3]
A trailer is available here:
A detailed description is available here:
It works already in Pharo 3.0 and can be played with by following the
Please let us know what you think.
The Glamorous Team
CFP - IWST 2017 - International Workshop on Smalltalk Technologies
[Please accept our apologies if you receive multiple copies of this call]
[Please send to interested colleagues / mailing-lists]
CALL FOR PAPERS
IWST 2017 International Workshop on Smalltalk Technologies
Maribor, Slovenia; Between September 4th to 8th, 2017
Goals and scopes
The goals of the workshop is to create a forum around advances or experience
in Smalltalk and to trigger discussions and exchanges of ideas. The topics
of your paper can be on all aspect of Smalltalk, theoretical as well as
practical. Participants are invited to submit research articles or
industrial papers. This year we want to open two different tracks: one
research track and one industrial track with less scientific constraints.
We expect papers of three kinds:
Short position papers describing emerging ideas
Long research papers with deeper description of experiments and of research
Industrial papers with presentation of real and innovative Smalltalk
applications; this kind of paper should enlighten why Smalltalk is really
appropriate for your application.
We will not enforce any length restriction.
Submission deadline: June 16th, 2017
Notification deadline: July 21th, 2017
Workshop : between September 4th and 8th, 2017
All accepted papers will be published in ACM DL (To be confirmed)
We welcome contributions on all aspects, theoretical as well as practical,
of Smalltalk related topics such as:
-Implementation, new dialects or languages implemented in Smalltalk,
-Interaction with other languages,
-Meta-programming and Meta-modeling,
Best Paper Award
To encourage the submission of high-quality papers, the IWST organizing
committee is very proud to announce a Best Paper Award for this edition of
We thank the Lam Research Corporation for its financial contribution which
makes it possible for prizes for the three best papers: 1000 USD for first
place, 600 USD for second place and 400 USD for third place.
The ranking will be decided by the program committee during the review
process. The awards will be given during the ESUG conference social event.
The Best Paper Award will take place only with a minimum of six submissions.
Notice also that to be illegible, a paper must be presented at the workshop
by one of the author and that the presenting author must be registered at
the ESUG conference.
Both submissions and final papers must be prepared using the ACM SIGPLAN 10
point format. Templates for Word and LaTeX are available at
http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also
contains links to useful informations on how to write effective submissions.
All submissions must be sent via easychair:
Anne Etien (Université de Lille 1, France)
Jannik Laval (Université Lyon 2 Lumière, France)
Responsable Pédagogique Licence Coordonnateur de Projet en Système
<http://iut.univ-lyon2.fr/> IUT Lumière, <http://www.univ-lyon2.fr/>
Université Lumière Lyon 2
<http://disp-lab.fr/> laboratoire DISP
+33 4 78 77 43 06
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
As you could see, in Pharo we turned the Dark Theme on by default.
The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons:
- they were conceived on a white canvas
- the colors are hardcoded
Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo.
What do you think?
"Not knowing how to do something is not an argument for how it cannot be done."
May I ask:
Roassal and Pharo are really fantastic. I’m trying to get a grip on it and
use it. What makes me think:
In the introduction of the superb “Agile Visualization” book it is stated,
that the Roassal OO approach allows for visualizations that are “easily
extensible”. I guess compared to hand-crafted, imperative visualizations.
Let’s take an example: RTCalendarBuilder
I noticed that present visualization of week days start with Sunday as
first day of week. E.g. in Europe/Germany weeks start on Monday (according
ISO8601). We are visually so used to it, that other schemes make us think
How could I modify this?
P.S.: Especially in calendrical visualizations there will be many (local)
variations. So maybe it’s a good example to understand how to easily extend
Roassal in above and similar topics as an interested user.
we are currently reviewing all the students proposals. Please join the
#gsoc-planning on Discord for giving your insights about the students.
The deadline for the final selection will be Monday 24th 6pm CEST.
As a reminder, we have 5 slots given by Google this year.
UCN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
in the latest Moose build the DeepTraverser package is in very old version
(DeepTraverser-StefanReichhart.10) but the recent one in
It looks like someone started to want stable version of the DeepTraverser
configuration instead of the development one. Does anyone know something
We recently had to work around the method
And found its intention somehow not clear.
We understand that entities are stored into 3 different type of collection:
When we remove an element from the group storage, we want to remove the
element from each of the 3 collections.
A tricky case is for byName dictionary:
in some cases, an element may not have been registered to the byName
dictionary because it does not have a unique moose name (see methods #
The current implementation of #remove:ifAbsent: does not really consider
this specific case.
As soon as an element is not found in the byName dictionary, the exception
block is executed.
More generally, we could have expected a distinction between
- inconsistent absence of an element in one of the collection. This would
raise an error.
- consistent absence of an element in all the collection. This would
execute the exception block.
With this consideration, the method could be something like:
*remove: anElement ifAbsent: exceptionBlock *
| key group |
elements remove: anElement ifAbsent: [ ^exceptionBlock value ].
key := anElement class.
group := byType
ifAbsent: [ OrderedCollection new ].
ifAbsent: [ *self error: 'Internal storage inconsistency'* ].
anElement *hasUniqueMooseNameInModel* ifTrue:
[ "In theory, objects are registered under their mooseName,
however some objects are still registered by their name
if #resetMooseName was not used when needed"
key :=anElement mooseName asSymbol.
byName at: key ifAbsent: [ self resetMooseNameFor: anElement ].
ifAbsent: [ *self error: 'Internal storage inconsistency'* ] ].
What do you think ?
I find the MSE export time far too long in Pharo. I dug up a little in
the export algo and found two problems. The first one is easy to
improve. The second one less.
First problem: FMRepository>>elements.
This method transform an IdentitySet to an Array with the #asArray
method. This takes ~40% of the export time in a small model (5Mo of Java
This #elements method is called by the method #includes: of FMRepository
and FMMetaRepository. I propose to change those #includes: methods to
use the variable `elements` instead of the getter. It should not change
anything since the result of an #includes: on an Array and an
IdentitySet should be the same.
Second problem: the progress bar
Usually a progress bar is used via an iteration on a collection and it
update the bar each 200ms. During the export it is not done that way and
the bar is managed "manually" because we do not have one iteration. I
think it is done far more time than each 200ms and at the end ~15-20% of
the export time is spent in the progress bar update. This is far too much.
For now, I don't know how to improve this part without changing the
actual behavior of the export. If I have time I'll try to improve this
part of the export too.
Have a good day.
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France