[Glamour] default selection in ListPresentation
by Cyrille Delaunay
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
5 years, 2 months
CFP - IWST 2017 - International Workshop on Smalltalk Technologies
by jannik.laval＠gmail.com
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
http://www.esug.org/wiki/pier/Conferences/2017/International-Workshop-IWST_1
7
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
results.
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.
--------------------
Important Dates
--------------------
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)
-------------------
Topics
-------------------
We welcome contributions on all aspects, theoretical as well as practical,
of Smalltalk related topics such as:
-Aspect-oriented programming,
-Design patterns,
-Experience reports,
-Frameworks,
-Implementation, new dialects or languages implemented in Smalltalk,
-Interaction with other languages,
-Meta-programming and Meta-modeling,
-Tools
-------------------
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
IWST.
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.
-------------------
Publication
-------------------
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.
-------------------
Submission
-------------------
All submissions must be sent via easychair:
https://easychair.org/conferences/?conf=iwst2017
-------------------
Program chairs
-------------------
Anne Etien (Université de Lille 1, France)
Jannik Laval (Université Lyon 2 Lumière, France)
--
~~Jannik Laval~~
Enseignant-chercheur
Responsable Pédagogique Licence Coordonnateur de Projet en Système
d'Information
<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
<http://www.jannik-laval.eu/> http://www.jannik-laval.eu
<http://www.phratch.com/> http://www.phratch.com
<http://www.approchealpes.info/> http://www.approchealpes.info
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
5 years, 11 months
moose & the dark theme
by Tudor Girba
Hi,
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?
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
6 years
RTCalendarBuilder
by Markus Böhm
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
(not intuitive).
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.
BR Mike
6 years, 1 month
slow CI
by Pavel Krivanek
Hi,
we have currently troubles with the slow CI, probably related to the Inria
network issues. The last Moose job took 42 min (I had to extend the time
limit)
-- Pavel
6 years, 1 month
GSOC Mentors - We need you.
by Serge Stinckwich
Dear mentors,
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.
Regards,
--
Serge Stinckwich
UCN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
6 years, 1 month
DeepTraverser in very old version
by Pavel Krivanek
Hi,
in the latest Moose build the DeepTraverser package is in very old version
(DeepTraverser-StefanReichhart.10) but the recent one in
-StefanReichhart.39.
It looks like someone started to want stable version of the DeepTraverser
configuration instead of the development one. Does anyone know something
about that?
Cheers,
-- Pavel
6 years, 1 month
Removing elements from GroupStorage
by Cyrille Delaunay
Hello Moose-dev,
We recently had to work around the method
MooseGroupRuntimeStorage>>remove:ifAbsent:
And found its intention somehow not clear.
We understand that entities are stored into 3 different type of collection:
- elements
- byType
- byName
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 #
*updateCacheFor: *#*hasUniqueMooseNameInModel*)
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
at: key
ifAbsent: [ OrderedCollection new ].
group
remove: anElement
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 ].
byName
removeKey: key
ifAbsent: [ *self error: 'Internal storage inconsistency'* ] ].
^anElement
What do you think ?
--
Cyrille Delaunay
6 years, 1 month
Improvement of the MSE export time
by Cyril Ferlicot D.
Hi everyone!
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
sources).
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.
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
6 years, 1 month
