Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

dead link on the hudson server
by Alexandre Bergel 23 Dec '10

23 Dec '10

On http://hudson.moosetechnology.org/job/mondrian-latest-dev-on-pharo-1.2/ there is the link http://www.pharo-project.org/pharo-download/unstable , which does not exist apparently. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Error exporting big models
by Martin Dias 23 Dec '10

23 Dec '10

Hi I'm trying to do some benchmarks using MSE import and export, and for that I am using MooseScripts to create test models. But many of them (I think the bigger ones) I get an error. I am attaching an screenshot, maybe is useful. For reproduce it in a new Moose 4.1 "one-click", I do: MooseScripts createModelForMorphic. And then, in a MoosePanel I click on Export to MSE, and after some seconds I get the error. Should I report a bug in the issue tracker? Does somebody know the cause of the error? Thanks in advance, Martin

2 2

Name Cloud Analysis in Moose
by Zhe-Xi Lim 23 Dec '10

23 Dec '10

Hi, I am new to Moose. What kind of analysis does the Utilities->Name Cloud offer to the user? It seems like sometimes the spellings of results of Name Cloud are weird (i.e. nonam, talkin, etc.) Thanks. Regards, Zhe-Xi -- View this message in context: http://forum.world.st/Name-Cloud-Analysis-in-Moose-tp3087373p3087373.html Sent from the Moose mailing list archive at Nabble.com.

5 9

PetitParser for Squeak 4.1
by Zhe-Xi Lim 23 Dec '10

23 Dec '10

Hi, How can I load PetitParser into Squeak 4.1 image? I had tried out the methods suggested by Lukas in his website but it turned out that Squeak find undefined object: Gofer. Can show me the steps in loading the PetitParser? Thanks. Regards, Zhe-Xi -- View this message in context: http://forum.world.st/PetitParser-for-Squeak-4-1-tp3161639p3161639.html Sent from the Moose mailing list archive at Nabble.com.

3 5

Dependencies with MalTarjanNode, MalGraphNode and friends
by Alexandre Bergel 22 Dec '10

22 Dec '10

Hi! I am still struggling to make Moose work on a Pharo 1.1.1. When you execute: ((Smalltalk at: #ConfigurationOfMoose) project version: '4.2') load You end up with an error: -=-=-=-=-=-=-=-=-=-=-=-= Warning: This package depends on the following classes: MalTarjanNode MalGraphNode MOCycleTable MalCyclesCoverage You must resolve these dependencies before you will be able to load these definitions: DSMCycleTable DSMCycleTable>>cellShape DSMCycleTable>>cellShapeFor:borderColor:view:at: DSMCycleTable>>dsm DSMCycleTable>>dsm: DSMCycleTable>>edgeCellShapeBorder:fill: DSMCycleTable>>edgeCellShapeColor: DSMCycleTable>>renderOn: DSMCyclesCoverage DSMCyclesCoverage>>nodeClass DSMCyclesCoverage>>run DSMCyclesCoverage>>sort DSMTarjanNode DSMTarjanNode>>initialize DSMTarjanNode>>previousNodes DSMTarjanNode>>previousNodesInCycles DSMTarjanNode>>to: FAMIXGraphNode FAMIXGraphNode>>from: FAMIXGraphNode>>initialize FAMIXGraphNode>>isLeaf FAMIXGraphNode>>isRoot FAMIXGraphNode>>nextNodes FAMIXGraphNode>>nextNodes: FAMIXGraphNode>>previousNodes FAMIXGraphNode>>previousNodes: -=-=-=-=-=-=-=-=-=-=-=-= I put some spec requires: #('Mondrian for Moose' 'MooseAlgos for Moose') ]; a bit everywhere. What package defines the class DSMTarjanNode, DSMCyclesCoverage, DSMCycleTable? I looked into Moose-DistributionMap but apparently they are defined somewhere else. We are almost done. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

5 6

Re: Request to Join Project Verveine J
by Tudor Girba 22 Dec '10

22 Dec '10

Hi Nicolas, Thanks for getting me access to the project. I will try to look into it in the following year. next is a derived property. You should only save the previous pointer. The context of next/previous is the context of the scope in which the association is defined. Thus, for example, for invocations, the scope is the sender method. For inheritance, the scope is the class. Cheers, Doru On 20 Dec 2010, at 18:38, Nicolas Anquetil wrote: > > > ----- Mail transféré ----- >> De: "Nicolas Anquetil" <nicolas.anquetil(a)inria.fr> >> À: noreply(a)gforge.inria.fr >> Envoyé: Lundi 20 Décembre 2010 18:28:49 >> Objet: Re: Request to Join Project Verveine J >> Done, >> >> By the way, I looked at the next/previous Association >> Moose impoter does not support it yet. >> It is stated in the comments, and the next: method is not implemented. >> Any special reason for this? >> >> Also, what's the semantics? It's inside a method / inside a class ? >> >> >> nicolas >> >> ----- Mail original ----- >>> De: noreply(a)gforge.inria.fr >>> À: "nicolas anquetil" <nicolas.anquetil(a)inria.fr> >>> Envoyé: Lundi 20 Décembre 2010 18:16:16 >>> Objet: Request to Join Project Verveine J >>> Tudor Girba has requested to join your project. >>> You can approve this request here: >>> https://gforge.inria.fr/project/admin/?group_id=2934 >>> >>> Comments by the user: >>> Would it be possible to give me access to the sources? >>> >>> Cheers, >>> Doru -- www.tudorgirba.com "Being happy is a matter of choice."

2 2

Re: [Pharo-project] [squeak-dev] Re: Graph library in Smalltalk - Need for advices
by Stéphane Ducasse 22 Dec '10

22 Dec '10

this is a nice analysis. Now I think that if different lib are needed for people then starting to build some of them is important. I know that Jannik also implemented and optimize tarjan and other graph algorithms for moose so cedric it would be probably a good start to check that and probably to make the moose graph algo lib a separate entity. We (the moose people) also need a good graph lib. Stef > 1. Scalability > 2. Data structures > 3. Algorithms > 4. Performance > 5. Visualization > > I think you need to at least consider all the above when creating a library. > In fact, you probably should break it up as many libraries do into several > components: > > 1. Common, useful data structures (Vertex, Edge, Adjacency List, Adjaceny > Matrix, etc.) that are optimized for your language - hopefully smalltalk > > 2. Computations / Measurements > > 3. Algorithms - layout, common graph problems, etc. > > 4. Persistence - database or otherwise, likely several supporting libs > specific to the persistence mechanism or implementing some kind of pattern > to be agnostic. The data structures should at least be designed in such a > way that they are persistence friendly to put in something like Gemstone, > Magma, Image, etc. See for example InfiniteGraph which has a Java interface > built on Objectivity. > > 5. Visualization - desktop, web, and static output. > > The problem here is that creating a graph library is a huge undertaking. It > might not sound like it, but they can grow to epic proportions. From my > comments, you can see that it is really not the fault of any particular lib, > but rather the subject matter. You could spend a lifetime packing in > features. The real key is just to create a series of libs that work well > together and not constantly reinvent the wheel with node classes in each > library. > > A secondary problem is doing graph analysis and even drawing graphs can take > a lot of horse power. Parallelism is a tough issue with graph libraries and > there's a multitude of approaches from pure threads to map/reduce to random > walking and stream processing. This is further compounded by persistence > where you need to start doing things like graph healing, partitioning, and > sharding to scale to massive levels and maintain performance. > > I just want to mention to others that graphs are hugely useful in general to > solve a variety of problems from recommendations to meta programming. It's > not just pretty pictures and experiments with molecules. There's a lot of > potential in Smalltalk to do something since generally I feel Smalltalkers > aren't bound by or afraid of new approaches to old problems. Graph databases > in many cases could replace relational DBs for example and let your app do > all kinds of stuff you might never have thought of otherwise. > > I could go on and on, but I'll stop myself here. Comments or thoughts? > > > > > > > Stéphane Ducasse wrote: >> >>> >>> I've started looking at the exemples YossiDM gave to me and in particular >>> Lemon which was according to him his best experience. I found the model >>> quite clear and covering all what I expect for a generic graph lib >>> (directed, undirected, mapping concept, iterators, and algorithms of >>> course). Moreover and contrary to Boost, it's still developed in 2010. >>> >>> To be more precise, here's what I expect for a generic graph lib in >>> smalltalk (note all in Lemon except visualization): >>> >>> - data structure: directed graphs, undirected graphs, possible loop and >>> parallel edged, ..., trees (?) >>> - mapping: easily map objects, informations on nodes and/or edges (here, >>> don't know if I'd like subclassing nodes/eges instead...) >>> - iterators: efficient way to iterate over nodes and edges >>> - algorithms: basic algorithms implementation (bfs, dfs, ..., shortest >>> paths, ...), and plug-ability for specific ones... >>> - visualization: having an interactive graph visualization web/SVG and >>> eventually morphic (... graphviz, mondrian, .......) >>> >>> then, I could use this for my research work... >>> - I need "belief" nodes with associated conditional beliefs tables >>> - I need to implement algorithms to propagate an information change >>> (change of a node state) in any nodes... >>> ****mainly, I'd like to get junction trees from a graph [1] which are >>> rely useful for several domains in machine learning field *** >>> >>> Actually, I don't know if I really need a graph lib as a simple >>> implementation directed to bayesian should be enough but it's the second >>> time I need graphs (last time was for planification) and I think that >>> would be great to have a nice and clean basic implementation. >>> >>> Couldn't we start developing something similar to Lemon (regarding "API", >>> enitites, etc...) that would work for small scale project project in >>> smalltalk ? >> >> It would be excellent. >> Because now that you have a full time permanent position you can invest a >> bit and in 2 years you can get something really sexy.... >> This is what we are doing all the time around pharo. >> >>> Yossi, what were the limitations you found with Lemon ? >>> >>> Cheers, >>> >>> Cédrick >>> >> >> >> >> > > -- > View this message in context: http://forum.world.st/Graph-library-in-Smalltalk-Need-for-advices-tp3092747… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

2 1

Merlin help request
by Johan Fabry 21 Dec '10

21 Dec '10

Hi all, I am looking at Merlin to build an import wizard for AspectMaps (current solution works but could be improved). Merlin looks cool but I have trouble understanding how everything works, and what is possible, from the examples. Please forgive me if the question below is an obvious thing / FAQ. The setup is as follows: From a first pane I get a filename, I need to parse that file to extract a list of N items. In the second pane I want the list of N items, each as a checkbox, ie N checkboxes. Then the next panes are 'generated' for each selected checkbox. These panes repeat the item, ask for a filename and a selection from radio button. Then a pane that is optional, depending on the radio button state of all the previous panes (+ internal state of the app). At the end an 'you have successfully imported blah' pane would be cool but is not required (I can use a dialog box for that). Now I have the first pane up and running, but the second panes and beyond I have no idea on how to do this. I dont find in the examples how to dynamically build a group of radio buttons, nor to dynamically build agroup of panes / select which is the next pane to show. Can anybody help me out here? Thanks in advance! -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

3 4

Problems with the Java parsing of inFusion(?)
by Alberto Bacchelli 20 Dec '10

20 Dec '10

Hi, I am using my PetitJava parser to extract some facts from Java code. Currently, I limit myself to extract the location of classes (so that I can see the source code), their name, and information about the package in which they reside. By parsing a system with both PetitJava and inFusion (using VisualWorks 7.7.1 and MSE 2.1), I found that some classes are not present in the model generated by inFusion. I attach here the name of the classes found by PetitJava and by inFusion (using the command allModelClasses on the MooseModel). (Here I do not consider interfaces). The analyzed source code can be found here: www.inf.usi.ch/phd/bacchelli/research/2002-05-10-argoUML_0.10.tar.bz2 For example, you can consider the files (and classes): Project.java GoalsDialog.java SuperclassGen.java ... I also tried to find them by querying the main MooseModel (e.g. model detect: [:e | e name = #Project]), but these classes are not in the model. Am I doing something wrong? Cheers, Alberto

3 2

Glamour on Seaside - Steps
by Andre Hora 18 Dec '10

18 Dec '10

Hi Tudor, As we talked today, I would like to know the steps to get Glamour running on Seaside. Thank you! Regards, -- Andre Hora

4 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