Hi!
Apparently Rubric does not take into account the font size. How can I increase the font size in a playground?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
[Apologies for duplicate reception of this CFP]
Reminder: IEEE SOFTWARE - 1ST SPECIAL ISSUE ON RELEASE ENGINEERING
Submission Deadline: 1 August 2014
Publication: March/April 2015
More Information: http://releng.polymtl.ca/RELENG2014/html/SI.html
Software used to be released in shrink-wrapped form, but the advent of agile
methodologies and the web has overhauled the landscape. For example, a project
like Mozilla Firefox releases every 6 weeks, generating updates for dozens of
existing versions on 5 desktop, 2 mobile and 3 mobile desktop platforms, each of
which for more than 80 locales. In other words, deployment of modern
applications requires coordinating the release of applications on multiple
mobile platforms, web platforms with centralized backend services, and native
desktop clients. Furthermore, concepts like continuous delivery of software are
no longer curiosities, but essential to retain a competitive edge.
Release engineering deals with all activities in between regular development and
actual usage of a software product by the end user, i.e., integration, build,
test execution, packaging and delivery of software. Although research on this
topic goes back for decades, the increasing heterogeneity and variability of
software products along with the recent trend to reduce the release cycle to
days or even hours starts to question some of the common beliefs and practices
of the field.
The IEEE Software Special Issue on Release Engineering solicits experience
reports and papers on tools, methods, practices and techniques to streamline
release engineering. We especially welcome submissions targeting recent
challenges like continuous delivery and heterogeneous platform support, but the
Special Issue is open to any of the following topics:
* best practices for code movement (branching/integration)
* continuous integration and testing
* build and configuration of software
* build system maintenance
* testing and reporting infrastructures
* package and dependency management
* legal signoff and bill-of-materials
* delivery and deployment of software
* code signing and certificate management
* continuous delivery, deployment, installation and software update
* cloud provisioning and management
* cloud service release management
* interaction with app stores
* mobile app release management
* principles and automated techniques for release planning
* release engineering for product line systems
* devops and interaction with developers, end users, etc.
* devops practices and tools
* large-scale build and test farms
* multi-platform build and test
* feedback on continuous delivery and deployment
The goals for this Special Issue are three-fold:
* making researchers aware of the challenges and research opportunities, and
practitioners aware of research in release engineering
* sharing experiences with practical approaches, tools, methods and techniques for
release engineering
* building connections between different communities involved in release engineering.
In an effort to engage with practitioners, one of the co-organizers of the
Special Issue is a release engineer at Mozilla and one half of the reviewers
will consist of release engineers, so we guarantee that each paper or abstract
submission receives at least one review from a practitioner.
Full submissions for the Special Issue must not exceed 5,400 words including
figures and tables, which count for 200 words each. Submissions in excess of
these limits may be rejected without refereeing. The articles we deem within the
theme and scope will be peer-reviewed and are subject to editing for magazine
style, clarity, organization, and space. We reserve the right to edit the title
of all submissions. Be sure to include the name of the theme or Special Issue
you are submitting for.
We also solicit short “practice” papers from practitioners that contain
experience reports. These papers do not need to make a research contribution,
but should instead present the experiences of a practitioner or practitioners by
describing things such as current release processes used, challenges faced,
solutions attempted, and/or results obtained. Practice papers should not exceed
3,500 words.
Articles should have a practical orientation and be written in a style
accessible to practitioners. Overly complex, purely research-oriented or
theoretical treatments are not appropriate. Articles should be novel. IEEE
Software does not republish material published previously in other venues,
including other periodicals and formal conference/workshop proceedings, whether
previous publication was in print or in electronic form.
For more information about the focus, please contact the Guest Editors:
* Bram Adams (http://mcis.polymtl.ca/bram.html), Polytechnique Montréal, Canada
* Stephany Bellomo (http://www.sei.cmu.edu/about/people/profile.cfm?id=bellomo_15351), SEI, USA
* Christian Bird (http://research.microsoft.com/en-us/people/cbird/), Microsoft Research, USA
* Foutse Khomh (http://www.khomh.net/), Polytechnique Montréal, Canada
* Kim Moir (http://relengofthenerds.blogspot.com/), Mozilla, Canada
For general author guidelines: http://www.computer.org/software/author.htm
For submission details: software(a)computer.org
Hola,
I found a bug in Roassal: if an edge is labeled, and that edge is removed from the view at some point (using removeEdge:) then the label does not go away. This is quite annoying, given that my latest project adds and removes a lot of edges in the visualization on a frequent basis. :-(
I verified this bug in the latest build. Code to reproduce is below.
“From RTRoassalExample>>exampleArrowedAndLabelledLine. Last line is new”
| v e1 e2 l |
v := RTView new.
e1 := (RTEllipse new size: 20) elementOn: 'hello'.
e2 := (RTEllipse new size: 20) elementOn: 'world'.
e1 @ RTDraggable.
e2 @ RTDraggable.
l := RTEdge from: e1 to: e2.
l + (RTLine new color: Color red).
l + (RTSimpleArrowHead new color: Color red).
e2 translateBy: 60 @ 80.
v addAll: { e1 . e2 . l }.
e1 @ RTLabelled.
e2 @ RTLabelled.
"Note that the RTLabelled interaction has to be set after having added the element in the view"
l @ (RTLabelled new text: 'lining up!').
v open.
v canvas.
v removeEdge: l “THIS IS THE NEW LINE"
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile
Hi!
We get this in a fresh moose image, on OSX:
This is really a pity.
This problem is so important, that we may directly output a roassal visualization in a separate window, bypassing Athens and directly using Cairo on SDL.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
Is there any way to perform multiple selection of elements in roassal? i.e., my idea would be to drag a sort of "selection rectangle” and select those elements whose bounds lie underneath the selection.
Cheers and thanks in advance,
Roberto
Is there a stable ConfigurationOfGlamour for Pharo 3?
I loaded the last ConfigurationOfGlamour from Smalltalkhub and it defines
only stable versions up to #'pharo2.x'.
Is there a version i can securely use on Pharo 3 and it is just not defined
in the ConfigurationOfGlamour #stable: method?
--
View this message in context: http://forum.world.st/Is-there-a-stable-ConfigurationOfGlamour-for-Pharo-3-…
Sent from the Moose mailing list archive at Nabble.com.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 1078 by v.blonde...(a)gmail.com: Syntax error do not raise when
debugging
http://code.google.com/p/moose-technology/issues/detail?id=1078
Describe the problem: what do you get? what do you expect?
When I change a method in the GTDebugger with a syntax error, the save
action is allowed (the orange corner vanishes but the code is not saved...)
and the debugger goes to the top of the stack, but no error message is
risen.
I expect to have a message or at least not the ability to save
How to reproduce the problem: step by step if necessary
Execute: Object sorted
You should have a DNU.
Remove receiver: self in the Object>>doesNotUnderstand: method, now the
method contains a syntax error (; followed of .)
Save
Additional information: platform, context which may impact the problem
W7 - Moose latest
Please fill in the labels with the following information:
* Type-Defect
* Component-GTDebugger
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
>Just to avoid going in the tool issue again. Could you reproduce this problem on a plain Pharo3 + Roassal image?
>Then we can announce the image on the Pharo mailing list and see if we can get help.
In a 30851, with the 355 vm (Mavericks), opened a workspace,
Gofer new smalltalkhubUser: 'ObjectProfile'
project: 'Roassal2';
package: 'ConfigurationOfRoassal2';
load.
(Smalltalk at: #ConfigurationOfRoassal2) load
loaded an old version of Roassal2
If I open RoassalExamples in the world menu, I get a red window.
Opening the settings, unselecting and reselecting FreeType
doesn't help.
Setting the standard font to Helvetica Neue and using that as default font for
everything makes Roassal2 work.
Stephan
Hi!
I’ve seen quite some discussion about the GTDebugger. I’ve just downloaded the last moose, and I am heavily facing that problem. The debugger cannot be used :-(
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Normally solved with the latest slice:
SLICE-Issue-13422-Image-crashes-because-an-open-Nautilus-browser-hangs-onto-many-objects-while-code-is-being-loaded-ThierryGoubier.3.
Bug was: Wrong selection update loop while cleaning the listManager on update.
I also added a real delete for the removed morphs during update.
I won't integrate yet, I'd like to explore things about the selection while updating mechanism, and the Moose image is hard to use on my netbook.
Can you test if this solves all the problems you could see with trees and lists? I checked that it solved the debugger and the test case issues.
Thierry
________________________________________
De : moose-dev-bounces(a)iam.unibe.ch [moose-dev-bounces(a)iam.unibe.ch] de la part de GOUBIER Thierry
Envoyé : jeudi 3 juillet 2014 17:26
À : Moose-related development
Objet : [Moose-dev] Re: Playground and Shortcuts
Ok. I'll look into that later today, have to pick up the kids.
So far, so good. Update is correct, selected element is removed but is
kept as expanded (because of the select, I guess), but then it seems to
be reintroduced in the tree.
Working out of the test case Stephan pointed out.
Thierry
Le 03/07/2014 16:58, Tudor Girba a écrit :
> 30851 already contains the problematic issue.
>
> Doru
>
>
>
> On Thu, Jul 3, 2014 at 4:50 PM, Goubier Thierry <thierry.goubier(a)cea.fr
> <mailto:thierry.goubier@cea.fr>> wrote:
>
> Ok.
>
> Where is the configurationOfGlamour? The current Moose5.0 beta image
> in the pharo launcher is on 30851.
>
> Thierry
>
> Le 03/07/2014 16:45, Tudor Girba a écrit :
>
> Or that Glamour uses an internal API that it should not :)
>
> Doru
>
>
> On Thu, Jul 3, 2014 at 4:41 PM, Stephan Eggermont
> <stephane(a)xs4all.nl <mailto:stephane@xs4all.nl>
> <mailto:stephane@xs4all.nl <mailto:stephane@xs4all.nl>>> wrote:
>
> I can confirm it is the 13422 fix that is broken/incomplete
>
> Stephan
> _________________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
> <mailto:Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>__>
> https://www.iam.unibe.ch/__mailman/listinfo/moose-dev
> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
>
>
>
>
> --
> www.tudorgirba.com <http://www.tudorgirba.com>
> <http://www.tudorgirba.com>
>
>
> "Every thing has its own flow"
>
>
> _________________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
> https://www.iam.unibe.ch/__mailman/listinfo/moose-dev
> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
>
>
> --
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92
> <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95
> _________________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
> https://www.iam.unibe.ch/__mailman/listinfo/moose-dev
> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
>
>
>
>
> --
> www.tudorgirba.com <http://www.tudorgirba.com>
>
> "Every thing has its own flow"
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Solved!
a problem with lastClickedMorph in the listManager (lastClickedMorph is
not allways the last clicked morph, but this is another matter ;))
Can you pound on the .5 slice for 13422 ?
Thierry
Le 04/07/2014 09:45, Goubier Thierry a écrit :
>
>
> Le 04/07/2014 08:00, Tudor Girba a écrit :
>> Thanks. It seems to work the same as the one before from the point of
>> view of Glamour.
>>
>> However, I noticed a strange difference in the debugger. Try this:
>> - Do "1/0"
>> - In the debugger, select the first entry from the top of the stack
>> - Then press down once => it works fine
>> - Then press down again => it goes up!
>> (this behavior is reproducible with the version 3 of your slice as well)
>
> The bug is a bit more complex. Upon opening the debugger, the first down
> keypress doesn't do anything, the second one goes one step down (and the
> third one goes one step up :)).
>
> Thierry
>
>> I do not know what causes it. Andrei, could you take a look? I do not
>> have time to look at it too deeply right now.
>>
>> Cheers,
>> Doru
>>
>>
>>
>>
>> On Fri, Jul 4, 2014 at 7:25 AM, GOUBIER Thierry <thierry.goubier(a)cea.fr
>> <mailto:thierry.goubier@cea.fr>> wrote:
>>
>> Hi Doru,
>>
>> can you test the new slice for 13422 (.4) ? I made a small semantic
>> change to the way the model update the selection after a list
>> update. I haven't seen anything wrong after loading it in Moose
>> (including with the debugger).
>>
>> Thierry
>>
>> ------------------------------------------------------------------------
>> *De :* moose-dev-bounces(a)iam.unibe.ch
>> <mailto:moose-dev-bounces@iam.unibe.ch>
>> [moose-dev-bounces(a)iam.unibe.ch
>> <mailto:moose-dev-bounces@iam.unibe.ch>] de la part de Tudor Girba
>> [tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>]
>> *Envoyé :* jeudi 3 juillet 2014 22:34
>>
>> *À :* Moose-related development
>> *Objet :* [Moose-dev] Re: Playground and Shortcuts
>>
>> Hi,
>>
>> Indeed, it looks good!
>>
>> Doru
>>
>>
>> On Thu, Jul 3, 2014 at 10:24 PM, Tudor Girba <tudor(a)tudorgirba.com
>> <mailto:tudor@tudorgirba.com>> wrote:
>>
>> I am testing right away.
>>
>> Doru
>>
>>
>> On Thu, Jul 3, 2014 at 10:20 PM, GOUBIER Thierry
>> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>> wrote:
>>
>> Normally solved with the latest slice:
>>
>> SLICE-Issue-13422-Image-crashes-because-an-open-Nautilus-browser-hangs-onto-many-objects-while-code-is-being-loaded-ThierryGoubier.3.
>>
>>
>> Bug was: Wrong selection update loop while cleaning the
>> listManager on update.
>> I also added a real delete for the removed morphs during
>> update.
>>
>> I won't integrate yet, I'd like to explore things about the
>> selection while updating mechanism, and the Moose image is
>> hard to use on my netbook.
>>
>> Can you test if this solves all the problems you could see
>> with trees and lists? I checked that it solved the debugger
>> and the test case issues.
>>
>> Thierry
>> ________________________________________
>> De : moose-dev-bounces(a)iam.unibe.ch
>> <mailto:moose-dev-bounces@iam.unibe.ch>
>> [moose-dev-bounces(a)iam.unibe.ch
>> <mailto:moose-dev-bounces@iam.unibe.ch>] de la part de
>> GOUBIER Thierry
>> Envoyé : jeudi 3 juillet 2014 17:26
>> À : Moose-related development
>> Objet : [Moose-dev] Re: Playground and Shortcuts
>>
>> Ok. I'll look into that later today, have to pick up the
>> kids.
>>
>> So far, so good. Update is correct, selected element is
>> removed but is
>> kept as expanded (because of the select, I guess), but then
>> it seems to
>> be reintroduced in the tree.
>>
>> Working out of the test case Stephan pointed out.
>>
>> Thierry
>>
>> Le 03/07/2014 16:58, Tudor Girba a écrit :
>> > 30851 already contains the problematic issue.
>> >
>> > Doru
>> >
>> >
>> >
>> > On Thu, Jul 3, 2014 at 4:50 PM, Goubier Thierry
>> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>
>> > <mailto:thierry.goubier@cea.fr
>> <mailto:thierry.goubier@cea.fr>>> wrote:
>> >
>> > Ok.
>> >
>> > Where is the configurationOfGlamour? The current
>> Moose5.0 beta image
>> > in the pharo launcher is on 30851.
>> >
>> > Thierry
>> >
>> > Le 03/07/2014 16:45, Tudor Girba a écrit :
>> >
>> > Or that Glamour uses an internal API that it
>> should not :)
>> >
>> > Doru
>> >
>> >
>> > On Thu, Jul 3, 2014 at 4:41 PM, Stephan Eggermont
>> > <stephane(a)xs4all.nl <mailto:stephane@xs4all.nl>
>> <mailto:stephane@xs4all.nl <mailto:stephane@xs4all.nl>>
>> > <mailto:stephane@xs4all.nl
>> <mailto:stephane@xs4all.nl> <mailto:stephane@xs4all.nl
>> <mailto:stephane@xs4all.nl>>>> wrote:
>> >
>> > I can confirm it is the 13422 fix that is
>> broken/incomplete
>> >
>> > Stephan
>> >
>> _________________________________________________
>> > Moose-dev mailing list
>> > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> <mailto:Moose-dev@iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>>
>> > <mailto:Moose-dev@iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>
>> <mailto:Moose-dev@iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>>__>
>> > https://www.iam.unibe.ch/__mailman/listinfo/moose-dev
>> >
>> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
>> >
>> >
>> >
>> >
>> > --
>> > www.tudorgirba.com <http://www.tudorgirba.com>
>> <http://www.tudorgirba.com>
>> > <http://www.tudorgirba.com>
>> >
>> >
>> > "Every thing has its own flow"
>> >
>> >
>> > _________________________________________________
>> > Moose-dev mailing list
>> > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> <mailto:Moose-dev@iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>>
>> > https://www.iam.unibe.ch/__mailman/listinfo/moose-dev
>> >
>> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
>> >
>> >
>> > --
>> > Thierry Goubier
>> > CEA list
>> > Laboratoire des Fondations des Systèmes Temps Réel
>> Embarqués
>> > 91191 Gif sur Yvette Cedex
>> > France
>> > Phone/Fax: +33 (0) 1 69 08 32 92
>> <tel:%2B33%20%280%29%201%2069%2008%2032%2092>
>> > <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95
>> > _________________________________________________
>> > Moose-dev mailing list
>> > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> <mailto:Moose-dev@iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>>
>> > https://www.iam.unibe.ch/__mailman/listinfo/moose-dev
>> > <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
>> >
>> >
>> >
>> >
>> > --
>> > www.tudorgirba.com <http://www.tudorgirba.com>
>> <http://www.tudorgirba.com>
>> >
>> > "Every thing has its own flow"
>> >
>> >
>> > _______________________________________________
>> > Moose-dev mailing list
>> > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>> >
>>
>> --
>> Thierry Goubier
>> CEA list
>> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
>> 91191 Gif sur Yvette Cedex
>> France
>> Phone/Fax: +33 (0) 1 69 08 32 92
>> <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>
>>
>> --
>> www.tudorgirba.com <http://www.tudorgirba.com>
>>
>> "Every thing has its own flow"
>>
>>
>>
>>
>> --
>> www.tudorgirba.com <http://www.tudorgirba.com>
>>
>> "Every thing has its own flow"
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>
>>
>> --
>> www.tudorgirba.com <http://www.tudorgirba.com>
>>
>> "Every thing has its own flow"
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
And once we start looking to details:
- The blue rectangle indicating the focus is on the stack list, and its surrounding tab
have an incorrect size, the right side is cut off.
One example of a workaround:
MessageListBrowser>>updateTree
| prevSelected |
prevSelected := self selectedItem.
self updateList.
prevSelected ifNotNil: [self selectItems: (Array with: prevSelected)]
...
Thierry
Le 04/07/2014 09:15, Goubier Thierry a écrit :
> I'll keep looking.
>
> I have issues with the way selection works between the model and the
> MorphTreeMorph, and I had a bunch of work-around code in my apps, as I
> suspect most users of MorphTreeMorph have (Glamour, Nautilus, etc...).
>
> I try to go step by step and get test cases. That helps. Trying to debug
> with a possibly not working debugger in Moose is not convenient :)
>
> Thierry
>
> Le 04/07/2014 08:43, Tudor Girba a écrit :
>> I forgot to mention that funny enough, clicking on any element in the
>> stack list works just fine. Strange :)
>>
>> Cheers,
>> Doru
>>
>>
>> On Fri, Jul 4, 2014 at 8:00 AM, Tudor Girba <tudor(a)tudorgirba.com
>> <mailto:tudor@tudorgirba.com>> wrote:
>>
>> Thanks. It seems to work the same as the one before from the point
>> of view of Glamour.
>>
>> However, I noticed a strange difference in the debugger. Try this:
>> - Do "1/0"
>> - In the debugger, select the first entry from the top of the stack
>> - Then press down once => it works fine
>> - Then press down again => it goes up!
>> (this behavior is reproducible with the version 3 of your slice as
>> well)
>>
>> I do not know what causes it. Andrei, could you take a look? I do
>> not have time to look at it too deeply right now.
>>
>> Cheers,
>> Doru
>>
>>
>>
>>
>> On Fri, Jul 4, 2014 at 7:25 AM, GOUBIER Thierry
>> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>> wrote:
>>
>> Hi Doru,
>>
>> can you test the new slice for 13422 (.4) ? I made a small
>> semantic change to the way the model update the selection after
>> a list update. I haven't seen anything wrong after loading it in
>> Moose (including with the debugger).
>>
>> Thierry
>>
>> ------------------------------------------------------------------------
>> *De :* moose-dev-bounces(a)iam.unibe.ch
>> <mailto:moose-dev-bounces@iam.unibe.ch>
>> [moose-dev-bounces(a)iam.unibe.ch
>> <mailto:moose-dev-bounces@iam.unibe.ch>] de la part de Tudor
>> Girba [tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>]
>> *Envoyé :* jeudi 3 juillet 2014 22:34
>>
>> *À :* Moose-related development
>> *Objet :* [Moose-dev] Re: Playground and Shortcuts
>>
>> Hi,
>>
>> Indeed, it looks good!
>>
>> Doru
>>
>>
>> On Thu, Jul 3, 2014 at 10:24 PM, Tudor Girba
>> <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
>>
>> I am testing right away.
>>
>> Doru
>>
>>
>> On Thu, Jul 3, 2014 at 10:20 PM, GOUBIER Thierry
>> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>>
>> wrote:
>>
>> Normally solved with the latest slice:
>>
>> SLICE-Issue-13422-Image-crashes-because-an-open-Nautilus-browser-hangs-onto-many-objects-while-code-is-being-loaded-ThierryGoubier.3.
>>
>>
>> Bug was: Wrong selection update loop while cleaning the
>> listManager on update.
>> I also added a real delete for the removed morphs during
>> update.
>>
>> I won't integrate yet, I'd like to explore things about
>> the selection while updating mechanism, and the Moose
>> image is hard to use on my netbook.
>>
>> Can you test if this solves all the problems you could
>> see with trees and lists? I checked that it solved the
>> debugger and the test case issues.
>>
>> Thierry
>> ________________________________________
>> De : moose-dev-bounces(a)iam.unibe.ch
>> <mailto:moose-dev-bounces@iam.unibe.ch>
>> [moose-dev-bounces(a)iam.unibe.ch
>> <mailto:moose-dev-bounces@iam.unibe.ch>] de la part de
>> GOUBIER Thierry
>> Envoyé : jeudi 3 juillet 2014 17:26
>> À : Moose-related development
>> Objet : [Moose-dev] Re: Playground and Shortcuts
>>
>> Ok. I'll look into that later today, have to pick up the
>> kids.
>>
>> So far, so good. Update is correct, selected element is
>> removed but is
>> kept as expanded (because of the select, I guess), but
>> then it seems to
>> be reintroduced in the tree.
>>
>> Working out of the test case Stephan pointed out.
>>
>> Thierry
>>
>> Le 03/07/2014 16:58, Tudor Girba a écrit :
>> > 30851 already contains the problematic issue.
>> >
>> > Doru
>> >
>> >
>> >
>> > On Thu, Jul 3, 2014 at 4:50 PM, Goubier Thierry
>> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>
>> > <mailto:thierry.goubier@cea.fr
>> <mailto:thierry.goubier@cea.fr>>> wrote:
>> >
>> > Ok.
>> >
>> > Where is the configurationOfGlamour? The current
>> Moose5.0 beta image
>> > in the pharo launcher is on 30851.
>> >
>> > Thierry
>> >
>> > Le 03/07/2014 16:45, Tudor Girba a écrit :
>> >
>> > Or that Glamour uses an internal API that it
>> should not :)
>> >
>> > Doru
>> >
>> >
>> > On Thu, Jul 3, 2014 at 4:41 PM, Stephan
>> Eggermont
>> > <stephane(a)xs4all.nl
>> <mailto:stephane@xs4all.nl> <mailto:stephane@xs4all.nl
>> <mailto:stephane@xs4all.nl>>
>> > <mailto:stephane@xs4all.nl
>> <mailto:stephane@xs4all.nl> <mailto:stephane@xs4all.nl
>> <mailto:stephane@xs4all.nl>>>> wrote:
>> >
>> > I can confirm it is the 13422 fix that
>> is broken/incomplete
>> >
>> > Stephan
>> >
>> _________________________________________________
>> > Moose-dev mailing list
>> > Moose-dev(a)iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>
>> <mailto:Moose-dev@iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>>
>> > <mailto:Moose-dev@iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>
>> <mailto:Moose-dev@iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>>__>
>> > https://www.iam.unibe.ch/__mailman/listinfo/moose-dev
>> >
>> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
>> >
>> >
>> >
>> >
>> > --
>> > www.tudorgirba.com <http://www.tudorgirba.com>
>> <http://www.tudorgirba.com>
>> > <http://www.tudorgirba.com>
>> >
>> >
>> > "Every thing has its own flow"
>> >
>> >
>> >
>> _________________________________________________
>> > Moose-dev mailing list
>> > Moose-dev(a)iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>
>> <mailto:Moose-dev@iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>>
>> > https://www.iam.unibe.ch/__mailman/listinfo/moose-dev
>> >
>> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
>> >
>> >
>> > --
>> > Thierry Goubier
>> > CEA list
>> > Laboratoire des Fondations des Systèmes Temps
>> Réel Embarqués
>> > 91191 Gif sur Yvette Cedex
>> > France
>> > Phone/Fax: +33 (0) 1 69 08 32 92
>> <tel:%2B33%20%280%29%201%2069%2008%2032%2092>
>> > <tel:%2B33%20%280%29%201%2069%2008%2032%2092> /
>> 83 95
>> > _________________________________________________
>> > Moose-dev mailing list
>> > Moose-dev(a)iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>
>> <mailto:Moose-dev@iam.unibe.ch
>> <mailto:Moose-dev@iam.unibe.ch>>
>> > https://www.iam.unibe.ch/__mailman/listinfo/moose-dev
>> >
>> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
>> >
>> >
>> >
>> >
>> > --
>> > www.tudorgirba.com <http://www.tudorgirba.com>
>> <http://www.tudorgirba.com>
>> >
>> > "Every thing has its own flow"
>> >
>> >
>> > _______________________________________________
>> > Moose-dev mailing list
>> > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>> >
>>
>> --
>> Thierry Goubier
>> CEA list
>> Laboratoire des Fondations des Systèmes Temps Réel
>> Embarqués
>> 91191 Gif sur Yvette Cedex
>> France
>> Phone/Fax: +33 (0) 1 69 08 32 92
>> <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>
>>
>> --
>> www.tudorgirba.com <http://www.tudorgirba.com>
>>
>> "Every thing has its own flow"
>>
>>
>>
>>
>> --
>> www.tudorgirba.com <http://www.tudorgirba.com>
>>
>> "Every thing has its own flow"
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>
>>
>> --
>> www.tudorgirba.com <http://www.tudorgirba.com>
>>
>> "Every thing has its own flow"
>>
>>
>>
>>
>> --
>> www.tudorgirba.com <http://www.tudorgirba.com>
>>
>> "Every thing has its own flow"
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Hi,
I'm not sure it is but I think I have found a bug where elements share the
same instance of a shape.
Here an example:
view := RTView new.
els := (RTBox new size: 20) elementsOn: (1 to: 10).
view addAll: els.
els do: [ :e |
e on: TRMouseClick do: [ :event |
e shape color: Color random. e update. els atRandom update. view
signalUpdate ]
].
RTHorizontalLineLayout on: els.
view open
It should only change the color of one element but it doesn't.
So I don't know if it is wanted or not.
--
Cheers,
Leo Perard
University of Lille 1
Hi all,
the usual shortcuts with Linux (Alt+d for example) are not working with the
Playground.
I have to use the Ctrl+ shortcut to use it. I replace the playground by the
workspace and it works with it so I guess the bug is in the playground.
But not all of the shortcuts are not working, for example Alt+o is working.
The list of those that do not work:
Alt+a
Alt+i
Alt+d
Alt+c
Alt+x
Alt+v
maybe others but I didn't check them all.
I'm on ubuntu 13.10 64bits.
--
Cheers,
Leo Perard
University of Lille 1