Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Using RPackage 3.3
by Stéphane Ducasse 19 Aug '11

19 Aug '11

Hi guys I will start a new development phase for RPackage and I would love to know if the version 3.3 when loaded in Moose is working. I would like to know if we can use this one as stable so that I can work on 3.4 (as dev branch) tx Stef

4 10

Fuel - FL export/import option
by Martin Dias 19 Aug '11

19 Aug '11

Hi! We have released a new version of Fuel-core. According to my benchmarks with Moose models, there is an improvement of 15-20% in export time. However, import time and file size is almost the same than in current version. There is a drawback if we adopt new version in Moose: saved files would become obsolete since the new format is incompatible. So maybe it is better to do not adopt the new version and keep the current one until we reach a better improvement. What do you think? Does anyone use the FL export/import option? Does it work fine? Bests, Martin

3 5

moosejee fails to build
by Tudor Girba 19 Aug '11

19 Aug '11

Hi Fabrizio, MooseJEE fails to build now due to some apparent problem in the configuration: 'Name not found: Moose-JEE-Tests-Importers-JSP' http://ci.moosetechnology.org/job/moosejee-latest-dev/139/console Cheers, Doru -- www.tudorgirba.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

2 2

latest filesystem is unloadable
by Tudor Girba 16 Aug '11

16 Aug '11

Hi, The bleeding edge version of Filesystem is unloadable in Pharo 1.3 (see the attached debug log). To test it, try: Gofer new squeaksource: 'fs'; package: 'ConfigurationOfFilesystem'; load. (Smalltalk at: #ConfigurationOfFilesystem) loadBleedingEdge Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

2 4

FAMOOSr @ ESUG'11
by Alexandre Bergel 12 Aug '11

12 Aug '11

Dear Fellow, We will organize Famoosr at esug this year. The event will be half a day, either on Sunday or on Tuesday morning. If you are using Moose and plan to attend esug, then submit your 10-lines description. -==-=-=-=-==-=-=-=-==-=-=-=-==-=-=-= FAMOOSr'11 Goal: Make people aware of what is happening on Moose. The event is demo oriented. You will have 5 minutes of demonstration. How to participate: you need to send a 10-lines description before Monday 15 August, to Jannik Laval <jannik.laval(a)inria.fr> and Alexandre Bergel <alexandre.bergel(a)me.com> What the event will look like: it will be heavily demo and discussion oriented. Participants are required to be concise and short on their presentation. -==-=-=-=-==-=-=-=-==-=-=-=-==-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 11

MooseChef scoping should not exclude self loops
by Nicolas Anquetil 12 Aug '11

12 Aug '11

I want to reimplement software engineering metrics using moose chef instead of moose cook. for example to compute cohesion I would do (among other things): self queryAllOutgoingDependencies atClassScope withinMyPackage i.e. : 1- from a package (self) 2- get all its "outgoingdependencies" (outgoing does not mean going outside the package, this includes dependencies within th package) 3- put that at class level (because we are interested in dependencies between classes within or outside the package) 4- and filter those that are inside self I want the result to be all dependencies from classes within package self going to classes within package self . but (from the moose chef documentation): "The scope operators exclude self loops by default (this was also the default in Moose Cook). That is, the query result will not contain the receiver scope itself: you will not get something like PackageX -> PackageX in the result (the reason for this is that in general algorithms do not like graphs with self loops)." So: - should we change that default? - should I change my query? I believe if there is a method to exclude self loops (withoutSelfLoop), it should not be done automatically in some case let those who want it do it themselves. What say you? nicolas

3 13

EyeSee: setup font size & color fill in diagram
by Simon Denier 11 Aug '11

11 Aug '11

I'm trying to customize some charts in EyeSee. First, can I change the font size of labels in a chart? I tried #defaultFontSize: without success. Second, can I change the fill color of my bars? In particular, I would like to pass a custom block as a parameter, as in Mondrian #fillColor: I found script helpers like #setColoredFill or #coloredFill: but again, no success. -- Simon Denier

2 1

Re: [Pharo-project] omit support in PetitParser
by Lukas Renggli 11 Aug '11

11 Aug '11

Hi Camillo, > I quickly hacked (with a lot of tests) support for omit in PetitParser. > This should simplify some parsing efforts as an additional filtering step could be avoided. > > parser := ($" asParser omit, $" asParser negate star flatten, $" asParser omit) > parser parse: '"asdfsd"' "yields directly #('asdfsd') " > > vs > > parser := ($" asParser, $" asParser negate star flatten, $" asParser) > parser parse: '"asdfsd"' > > which yields #($" 'asdfsd' $") I don't really see use of #omit. The element is still in a collection and you need to extract it from there. What is the benefit other than it is now at index 1 instead of 2? Also the implementation has some problems: 1. #omit makes it really hard to compose grammars, because parsers suddenly get very asymmetric and start to affect each others behavior depending on how you compose them. 2. For the same reason grammar transformation becomes impossible, one of the design goals of PetitParser. 3. #omit makes a typical grammar (the smalltalk one) roughly 15% slower without even using the new feature. 4. There are various methods (#-, #match..., #copy..., ...) that need to be fixed when you add state to a parser. 5. There is no need for eager (#initialize) as well as lazy initialization (kills the possibility for a quick invocation). 6. Please do not remove PPParser class>>new and do not change how initialization works, otherwise you break GemStone, VisualWorks, and GNU Smalltalk. The Seaside wiki has some nice documentation of how to correctly initialize objects (basically following the pattern of Objective-C). I think, problems 1, 3 (!), 4, 5 and to some extent also 2 could be solved if the implementation was a bit more object-oriented. That is, if you added a PPOmitParser that would dispatch from #parseOn: to some other parsing method #parseOmittedOn: you wouldn't need all those #ifTrue:ifFalse:. > I pushed my solution to the petitparser repos. I didn't add full support for flatten. Did you see #map: and #permutation:? Both allow you do the same in a less invasive way: parser := ($" asParser , $" asParser negate star flatten, $" asParser). parser map: [ :begin :inner :end | inner ] or parser := ($" asParser , $" asParser negate star flatten, $" asParser). parser permutation: #(2) Additionally, did you see the experimental binding/capturing functionality in PetitBeta? This kind of provides something much more general and (I believe) much more powerful without the above drawbacks. Bind-Capture allows you to bind certain parse results anywhere down the tree to names and directly access them later on in a capture block. It also deals with unpacking and reshuffling collections automatically, check the tests for that. Your example would look like: parser := ($" asParser , ($" asParser negate star flatten bind: #inner) , $" asParser). parser capture: [ :inner | inner ] Cheers, Lukas -- Lukas Renggli www.lukas-renggli.ch

4 5

Re: Issue 464 in moose-technology: Actions that open new browsers should go through Renderer
by moose-technology＠googlecode.com 11 Aug '11

11 Aug '11

Updates: Labels: -Milestone-4.2 Comment #1 on issue 464 by tudor.gi...(a)gmail.com: Actions that open new browsers should go through Renderer http://code.google.com/p/moose-technology/issues/detail?id=464 (No comment was entered for this change.)

1 2

[Glamour] open new browser action
by Cyrille Delaunay 11 Aug '11

11 Aug '11

Hello , I started to work on a 'actAndOpen' mechanism. The idea would be to allow glamour to encapsulate the action of opening a new glamour browser (the use case i have in mind for now is to open a GLMWizard). The model store those sepecific actions (like actions , selectionActions and now openBrowserActions and selectionOpenBrowserActions) , then each renderer now how to deal with them. What I did for now is to provide a similar interface than for other actions: aBrowser actAndOpen: [ ... ] entitled: '..'. The requirement is that the block return a browser. For now selectionActAndOpen: works fine Does this looks correct ? Am I taking the good direction ?

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev