Moose-dev April 2017

moose-dev@list.inf.unibe.ch

23 participants
21 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

CFP - IWST 2017 - International Workshop on Smalltalk Technologies
by jannik.laval＠gmail.com 12 Jun '17

12 Jun '17

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

2 2

moose & the dark theme
by Tudor Girba 08 May '17

08 May '17

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

8 28

RTCalendarBuilder
by Markus Böhm 02 May '17

02 May '17

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

3 6

slow CI
by Pavel Krivanek 24 Apr '17

24 Apr '17

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

1 0

GSOC Mentors - We need you.
by Serge Stinckwich 22 Apr '17

22 Apr '17

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/

1 0

DeepTraverser in very old version
by Pavel Krivanek 22 Apr '17

22 Apr '17

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

3 4

Removing elements from GroupStorage
by Cyrille Delaunay 19 Apr '17

19 Apr '17

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev April 2017