Moose-dev October 2012

moose-dev@list.inf.unibe.ch

25 participants
139 discussions

How to export multiple Pharo packages to VW

by Stephan Eggermont

The VW5PackageExporter allows the exporting of a package to the VW xml based fileout format. I've adapted the code to be less Seaside-specific, and am now able to export one package (Parasol-Core). If I try to export another package (Parasol-Tests), which depends on the earlier one, it fails to load. It can't resolve the dependency to a superclass defined in Parasol-Core. I've seen that Roassal puts all Pharo packages into one VW package. That would work, but is not very nice. A package in VW doesn't seem to register its dependencies in a fileout. Would creating a parcel help, or should I try something on basis of RPackage? Stephan

12 years, 2 months

FAMIX question

by wam

Hello everyone, How would you model a script (batch, shell or in the the case I am interested in, a JCL script) in FAMIX? Does it make sense to use FAMIXModule or should I create a new entity for this purpose? Thank you Camille Teruel

12 years, 2 months

Java Parser for Moose/Pharo

by Santiago Vidal

Hi, I looking for a Java parser to use with Moose. While the MSE file gives me most of the relevant information,I need to analyze the internals statements of a method. Anybody is aware of such a parser? Thanks in advance. Cheers, -- Santiago Vidal

12 years, 2 months

Issue 836 in moose-technology: Bug in GLMMorphicBrowserRenderer

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 836 by julioari...(a)gmail.com: Bug in GLMMorphicBrowserRenderer http://code.google.com/p/moose-technology/issues/detail?id=836 Hello, in the class GLMMorphicBrowserRenderer I had a out of bound problem the first time that a model was charged (click on model). I changed the code of the render method (when activeEntity message on aBrowser object is sent)as follow: aBrowser activeEntity: ((aBrowser panes at: (ann pageIndex max: aBrowser panes size)) port: #entity) value ]. It was ok for me. So, I suggest this change to the Moose Developers. Hugs, Julio Ariel Hurtado

12 years, 2 months

Issue 650 in moose-technology: Mondrian multiple selection uses a broken metaphor

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Mondrian Milestone-4.5 New issue 650 by tu...(a)tudorgirba.com: Mondrian multiple selection uses a broken metaphor http://code.google.com/p/moose-technology/issues/detail?id=650 The multiple selection mechanism is confusing because you have to release the mouse to start selecting. It should be disabled until it works properly.

12 years, 2 months

Jenkins build became unstable: moose-latest-dev #1162

by admin＠moosetechnology.org

See <http://hudson.moosetechnology.org/job/moose-latest-dev/1162/>

12 years, 2 months

Short update of Softwarenaut port to Pharo

by Dennis Schenk

Hi all, Here's a short status update on the port of Softwarenaut to Pharo for those interested. Here is a screenshot of Softwarenaut visualizing itself: http://cl.ly/image/073a0B0z3N15 We see all the classes as nodes, their size corresponds to their weights (which is LOC in this example). The Treemaps are constructed with the classes children, which are methods, their weight also based on LOC. The relationships are the propagated invocations from each class to the others. The nodes are manually laid out in the screenshot. One of the next steps will be to find some clever layouting mechanism for nodes of different sizes with relationships between them. Here is another screenshot of FAMIX http://cl.ly/image/1t3C2s0r3M3V Using the same parameters as the visualization used for the Softwarenaut screenshot but arranged in a circle layout. If anyone has any question don't hesitate to ask. Cheers, Dennis

12 years, 2 months

default pharo image for moose

by Nicolas Anquetil

What's the pharo image for moose ? I am having problems with things that work in Pharo, but cannot work in the moose image. Mainly these days I am stumbling upon issue with moose lacking | or byteOr: (which is actually the same thing) :-( nicolas

12 years, 2 months

MySQL slow query log analysis

by laurent laffont

Hello, I would like a mysql slow query log parser / analyzer that generates a graph with most time consuming requests. Someone already done it with Moose / Roassal ? Cheers, Laurent

12 years, 2 months

ROView>>allElementsDo:

by Ben Coman

Alexandre, Thanks for addition of the rubberband feature. Having considered the ROExample some more, I think it would provide a better show by highlighting the available target nodes, so (to keep the application code concise) I was thinking of rearranging the API as follows... --------------- rubberband := RORubberBand new targeting: [:sourceElement | sourceElement view allElementsSelect: [:targetElement | [targetElement model first asInteger = (sourceElement model first asInteger + 1)]]]; highlightTargets; onDrop: [:rawNewEdge | rawNewEdge + ROLine. rawNewEdge to removeAllEdgesTo. rawNewEdge to view add: rawNewEdge. ROTreeLayout on: rawView elements]. -------------- where I was adding ROView>>allElementsSelect: as... -------------- allElementsSelect: aBlock | newCollection | newCollection := OrderedCollection new. self allElementsDo: [:each | (aBlock value: each) ifTrue: [newCollection add: each]]. ^newCollection -------------- However I bumped into an issue where (unless you see a more elegant solution) I feel the right thing might be to rename #allElementsDo: to #allElementsAndEdgesDo (or #alllAbstractElementsDo:) and create two new methods #allEdgesDo: and #allElementsDo: The issue is that I was assuming I would be safe with the code "sourceElement model first" since I _know_ the model is a string, however I was surprised that this failed - due to #allElementsDo also processing edges which had no model. However trying to workaround this with the following also fails... -------------- allElementsSelect: [:targetElement | (targetElement isKindOf: ROElement) and: (targetElement model first asInteger = (sourceElement model first asInteger + 1)) ] -------------- since the right-side is not bypassed when the left-side evaluates to #true as per other languages (as well it clutters the application code) Hence it seems useful for the (targetElement isKindOf: ROElement) to be pushed upstream. However what would such a method be called? #allElementsDo: is already taken, unless as mentioned above #allElementsDo: is renamed to #allAbstactElementsDo: and new #allEdgesDo: and #allElementsDo: are created. Actually a new thought just occurs.... since Roassal has two major components ROEdge and ROElement, and I think it will be _very_ common to filter between them, having something like #allElementsKindOf:do: (as well as #allElementsKindOf:select:) might be useful, such that the application code would be... -------------- rubberband := RORubberBand new targeting: [:sourceElement | sourceElement view allElementsKindOf: ROElement select: [:targetElement | [targetElement model first asInteger = (sourceElement model first asInteger + 1)]]]; highlightTargets; onDrop: [:rawNewEdge | rawNewEdge + ROLine. rawNewEdge to removeAllEdgesTo. rawNewEdge to view add: rawNewEdge. ROTreeLayout on: rawView elements]. -------------- This could leave the rubberbanding mechanism flexible to later drop edges onto other edges - which might be randomly useful for something like the hyperedges discussed recently. Do you have any other ideas on achieving something similar to the last example? cheers -ben P.S. While it is elegant that ROAbstractElement has only one instance variable 'elements' containing both ROElements and ROEdges, it is a little unfortunate when considering the term 'elements' in general discussion and documentation that there is a semantic overlap between ROAbstactElement and ROElement that may at times be open to confusion.

12 years, 2 months

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev October 2012