Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Tudor Girba

Hi, The Moose build is red due to a strange error: ... Starting atomic load[31m==== Startup Error: SubclassResponsibility: UTF8InvalidText had the subclass responsibility to implement #defaultAction [0mUTF8InvalidText(Object)>>subclassResponsibility UTF8InvalidText(Exception)>>defaultAction UndefinedObject>>handleSignal: Context>>handleSignal: Context>>handleSignal: ... See here: https://ci.inria.fr/moose/job/moose-6.0/308/console Could anyone investigate this? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

9 years, 8 months

Slow World Menu opening

by Alexandre Bergel

Hi! When I open the world menu, the mouse cursor is intensively blinking, and opening the menu is _very slow_. This bugs has been around for a couple of weeks already. Am I the only one to see it? I have checked the cause, and apparently the problem disappear by removing the use of “Cursor read showWhile:”. The following method: -=-=-=-=-=-=-=-=-= ImageReadWriter>>formFromStream: aBinaryStream "Answer a ColorForm stored on the given stream. closes the stream" | reader readerClass form | readerClass := self readerClassFromStream: aBinaryStream. reader := readerClass new on: aBinaryStream. Cursor read showWhile: [ form := reader nextImage. reader close ]. ^ form -=-=-=-=-=-=-=-=-= May be rewritten as: -=-=-=-=-=-=-=-=-= ImageReadWriter>>formFromStream: aBinaryStream "Answer a ColorForm stored on the given stream. closes the stream" | reader readerClass form | readerClass := self readerClassFromStream: aBinaryStream. reader := readerClass new on: aBinaryStream. form := reader nextImage. reader close. ^ form -=-=-=-=-=-=-=-=-= However, changing the cursor has been around for quite a long time. It is strange that the slow menu is surfacing only now. Any idea why? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 8 months

CFP: BENEVOL 2015 December 3-4 in Lille

by Anne Etien

Dear all, We would like to cordially invite you to participate in BENEVOL 2015 in Lille, organised by the University of Lille 1 and Inria The BENEVOL software evolution research seminar aims to gather junior and senior researchers from Belgium, the Netherlands, and neighboring countries to meet and to discuss new ideas, important problems and obtained research results in the field of software evolution. Prospective speakers (junior or senior researchers or practitioners active in the field) are invited to submit an extended abstract (max. 2 A4 pages) of a talk. Based on these extended abstracts, the organization will construct an exciting program. The seminar particularly welcomes presentations of ongoing research or tools developed by PhD students. Senior researchers will provide the necessary feedback and lively discussions. As every year, we will have invited talks by key researchers in the field Attendance to BENEVOL 2015 is free (including lunch, coffee breaks, and dinner on the first day), but registration is required. The event will be hosted at Inria in Lille. Important dates: - Submission deadline: October 15th - Registration deadline: November 15th - Event: December 3rd and 4th Extended abstracts (2 to 4 A4 pages) should be submitted using EasyChair: https://easychair.org/conferences/?conf=benevol2015. Proceedings will be published as a Inria technical report. Participants can still submit their work to other scientific venues. Our kind sponsors enable free registration for the event: - CRIStAL http://cristal.univ-lille.fr/ - GDR-GPL http://gdr-gpl.cnrs.fr/ - Inria www.inria.fr/centre/lille - GT-GL http://www.cristal.univ-lille.fr/?rubrique26&id=5 Feel free to contact the organizers Nicolas Anquetil (nicolas.anquetil(a)univ-lille1.fr), Damien Cassou (damien.cassou(a)univ-lille1.fr) and Anne Etien (anne.etien(a)univ-lille1.fr). Please redistribute the attached flyer among your network of software evolution researchers in the Netherlands, Belgium and neighboring countries. Best regards, Nicolas, Damien and Anne

9 years, 8 months

New features on MooseQuery

by Anne Etien

Hi, Yesterday we developed two new features in MooseQuery: - the toScope: method to go down in the containment tree. It is the opposite of atScope: that goes up. Both methods work the same way: ((classA queryIncoming: FAMIXInvocation) atScope: FAMIXClass) toScope: FAMIXMethod. This query uses the new API and returns the methods of the classes containing the methods sources of the incoming FAMIXInvocation of classA. - the ability to query the MooseGroups. Thanks to this new feature, it is possible to query directly the model or any MooseGroup resulting from a selection or an operation (union, intersection, difference…) of several MooseGroups. A full documentation’s coming, but certainly not before the end of the summer. Cheers, Jean-Christophe and Anne

9 years, 8 months

Re: [Pharo-dev] Re: Object new foo

by Vincent BLONDEAU

Hi Eliot, Thanks for your help. The problem has been resolved! In fact a class was removed or renamed in Pharo, and the Moose debugger calls it just before the opening. So it created an infinite loop, because the class wasn’t understood by the system, so it opened another debugger, etc…. Do you think something can be made to not break the image and so to break this infinite loop? A solution may to open either another registered debugger, or the emergency debugger? I can create an image with the problem if needed. Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Eliot Miranda Envoyé : jeudi 20 août 2015 22:13 À : Pharo Development List Cc : Moose-related development; Squeak Virtual Machine Development Discussion Objet : Re: [Pharo-dev] [Moose-dev] Re: Object new foo Hi Vincent, does the image lock up when you execute Exception signal? The two functions you see looping are part of the implementation of primitives 195 & 196, findNextUnwindContextUpTo: (primitiveFindNextUnwindContext) & terminateTo: (primitiveTerminateTo). So if the image locks up the question is, is what is creating a circular structure of contexts, the VM or the image? I am willing to take a look at an image that contains the case. If you can create an image which enters the lop on start-up without my having to do anything I'm happy to take a look. On Wed, Aug 19, 2015 at 3:22 PM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net <mailto:vincent.blondeau@polytech-lille.net> > wrote: Hi, On last Moose image, I debugged the VM and executed “Exception signal”. I paused the VM and saw that 2 methods are looping together in gcc3x-cointerp.c: static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt primitive, sqInt senderContext, sqInt homeContext); static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, char *startFP, sqInt homeContext); The image is looping only when the debugger is launch on Error (not by launching it by the script below). Maybe someone on the Pharo mailing list knows what is happening? Thanks in advance, Cheers, Vincent De : moose-dev-bounces(a)iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> [mailto:moose-dev-bounces@iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> ] De la part de Andrei Chis Envoyé : mardi 18 août 2015 10:53 À : Moose-related development Objet : [Moose-dev] Re: Object new foo Hi Vincent, You example will also kill the Pharo debugger :) The issue is that you pass 'Processor activeProcess' which gets terminated when you close the debugger. When you open the debugger you need to make sure the process on which it is opened is suspended and can get terminated with no problem. A different way to redo the example would be: context := Context sender: nil receiver: {1 . 2 . 2} method: (OrderedCollection>>#add:) arguments: #(10). process := Process forContext: context priority: Processor userInterruptPriority. GTGenericStackDebugger openOn: (DebugSession process: process context: context). There is a basic test for opening the debugger in GTGenericStackDebuggerSmokeTest but more could help. Cheers, Andrei On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net <mailto:vincent.blondeau@polytech-lille.net> > wrote: Indeed. Maybe some tests has to be added.. But for now, it seems that the debugger is crashing the image… Not just by launching it: GTGenericStackDebugger openOn: (DebugSession process: Processor activeProcess context: (Context sender: nil receiver: {1 . 2 . 2} method: (OrderedCollection>>#add: ) arguments: #(10))) But when an exception is thrown, its seems that we fall into an infinite loop around the primitive 199. Maybe the context is not well set? Cheers, Vincent De : moose-dev-bounces(a)iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> [mailto:moose-dev-bounces@iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> ] De la part de Alexandre Bergel Envoyé : lundi 17 août 2015 13:26 À : Moose-related development Objet : [Moose-dev] Re: Object new foo This is weird that such bug can be introduced and no alarm is raised Alexandre Le 17 août 2015 à 08:03, Jan Kurš <kurs(a)iam.unibe.ch <mailto:kurs@iam.unibe.ch> > a écrit : Yep I had this problem (falled back to previous version), I suspected debugger being the reason. Cheers Jan On Sun, 16 Aug 2015 03:05 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com> > wrote: in Moose 6.0 simply freezes. Anyone else sees this? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ 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 _______________________________________________ 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 -- _,,,^..^,,,_ best, Eliot

9 years, 8 months

[Request]: Feedback for Issue #1130: Hook for Customized Presentation Constructors (e.g. Magritte)

by Sean P. DeNigris

>From https://github.com/moosetechnology/Moose/issues/1130 : Right now, by default, a presentation constructor must be an annotated method which takes a composite (and optional context) as arguments, and configures a presentation. For example: gtInspectorStepsIn: composite <gtInspectorPresentationOrder: 10> composite list title: 'Steps'; display: [ self children ] While this serves the basic purpose, I found myself continuously duplicating info which I had already described with Magritte, as in the description mirroring the above: descriptionChildren <magritteDescription> ^ MAToManyRelationDescription new accessor: #children; label: 'Steps'; "..." yourself So, playing around, I created the following general purpose hook to give more latitude in constructing presentations: gtInspectorPresentationsIn: composite inContext: aGTInspector "..." eachPragma selector numArgs = 0 ifTrue: [ | configurationProvider | configurationProvider := self perform: eachPragma selector. configurationProvider gtPresentation cull: composite cull: aGTInspector cull: self ]. "..." This enables you to get presentations almost for free by leaning on (in this case) Magritte. The Magritte description gets a slight upgrade: descriptionChildren <magritteDescription> <gtInspectorPresentationOrder: 10> ^ MAToManyRelationDescription new accessor: #children; label: 'Steps'; "..." gtPresentation: [ :a | a list ]; yourself #gtPresentation: sets default mappings, eliminating the original duplication: gtPresentation: aBlock | wrapper | wrapper := [ :composite :context :subject | | presentation | presentation := aBlock cull: composite cull: context. presentation hasTitle ifFalse: [ presentation title: self label ]. presentation hasTransformation ifFalse: [ presentation display: (self accessor read: subject) ] ]. self propertyAt: #gtPresentation put: wrapper ----- Cheers, Sean -- View this message in context: http://forum.world.st/Request-Feedback-for-Issue-1130-Hook-for-Customized-P… Sent from the Moose mailing list archive at Nabble.com.

9 years, 8 months

Updating Configurations for Pharo 4.0

by Sean P. DeNigris

Is the Moose version loadable in Pharo4.0 now fixed? That is, how would one back port a Moose feature into Pharo 4.0? The configurations already have new versions which seem to have integrated Pharo 5.0-only features, but none of these are in #pharo50 blocks. I'm asking because Camp Smalltalkers are wanting to see a demo of the GT Magritte extensions, but my projects are only loading in Pharo 4.0. Maybe I'll just do a quick jdemo project in Pharo 5.0, but a lesser problem still stands, which is that currently, I don't even know how to load my own projects with these extensions without manually declaring specific Moose package versions in my own configs, which is a hassle. Maybe I should make a ConfigurationOfGlamourMagritteForPharo40?! Any suggestions are welcome. Thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Updating-Configurations-for-Pharo-4-0-tp4845070.html Sent from the Moose mailing list archive at Nabble.com.

9 years, 8 months

SmaCC 2.0.5 released

by Thierry Goubier

Hi All, I have released SmaCC 2.0.5, aligned on the main SmaCC[1] with a small fix on the Java parser, a few additional parsers (Cucumber), the addition of the Javascript parser, and continuous improvements on the performance and source code coverage of SmaCC generated parsers (with many thanks to John Brant and Don Roberts). The project is available on github[2] [1] http://www.refactoryworkers.com/SmaCC.html [2] https://github.com/ThierryGoubier/SmaCC This release is targeted at Pharo4. All parsers should work on Pharo 5, but the GUI doesn't work. Most parsers come with full AST generation and a dedicated visitor for each, and support for native language refactoring. To retrieve a specific parser, please use Metacello with the following script: Metacello new baseline: 'SmaCC'; repository: 'github://ThierryGoubier/SmaCC:v2.0.5'; load: 'SmaCC-Javascript' (SmaCC-Python, SmaCC-Java, SmaCC-Cucumber, etc...) On Pharo4 only, to retrieve the full set (gui and tests), please use Metacello with the following expressions: Metacello new baseline: 'SmaCC'; repository: 'github://ThierryGoubier/SmaCC:v2.0.5'; load Regards, Thierry

9 years, 8 months

Object new foo

by Alexandre Bergel

in Moose 6.0 simply freezes. Anyone else sees this? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 8 months

Roassal callbacks as events

by Peter Uhnák

Hi, this is just an idea that's been bugging me for some time... what if callbacks could be attached just like regular events? e.g. aBox when: TRExtentChanged do: [ :event | (self parentFor: aBox) rebuild ] Is there benefit in having some events as events and some as callbacks? Isn't event more versatile? What do you think? I should probably check how this is done in Bloc... Peter

9 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev