Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Stéphane Ducasse

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

13 years, 8 months

Fuel - FL export/import option

by Martin Dias

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

13 years, 8 months

moosejee fails to build

by Tudor Girba

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

13 years, 8 months

latest filesystem is unloadable

by Tudor Girba

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

13 years, 8 months

FAMOOSr @ ESUG'11

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

13 years, 9 months

MooseChef scoping should not exclude self loops

by Nicolas Anquetil

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

13 years, 9 months

EyeSee: setup font size & color fill in diagram

by Simon Denier

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

13 years, 9 months

Re: [Pharo-project] omit support in PetitParser

by Lukas Renggli

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

13 years, 9 months

Re: Issue 464 in moose-technology: Actions that open new browsers should go through Renderer

by moose-technology＠googlecode.com

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

13 years, 9 months

[Glamour] open new browser action

by Cyrille Delaunay

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 ?

13 years, 9 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