Moose-dev January 2011

moose-dev@list.inf.unibe.ch

23 participants
129 discussions

by Ross Boylan

Some people suggested trying moose for analysis of SAS programs, and I'm trying to figure out where to start with the meta-modeling. SAS is not object oriented, though parts of it could be imagined to be. The main SAS code contains blocks of statements that begin with DATA or PROC; each block could probably be thought of as a function--to be precise, the application of a function. If I want to make some new models, where do I start? FM3? FAMIX? elsewhere? The 4.0 release announcement says FM3 and FAMIX3 are both implemented in Fame, so maybe start with Fame? I've read some documentation, but I can't tell. My inspiration for the project is understanding how some SAS datasets were produced. I have a system that creates numerous datasets, which feed into later datasets, etc. This is split at least across a couple of program files and it's really too complicated to keep in the brain. If I get ambitious it would also be useful to trace where particular variables came from, in the sense of both datasets and individual expressions. The only thing resembling a SAS parser I've run into (except for SAS, which is closed source) is a Perl module, and it looked relatively primitive. I've been using PetitParser, and at the point I started thinking about what it would parse results into. Thanks for any pointers. Ross Boylan

13 years, 6 months

Petit SQL Parser

by Fabrizio Perin

Hi all, i did implement an SQL parser using Petit Parser. I toke the grammar specification from SQLite http://www.sqlite.org/lang.html . The grammar implemented is not complete, for now i did implement "just" the create table statement, it means that you should be able to parse at least a script for create the database. The code is in squeaksource http://www.squeaksource.com/@09zbthA-fDDfyUNQ/_OIex3aA . To download it you can evaluate this: Gofer new squeaksource: 'PetitSQLParser'; package: 'ConfigurationOfPetitSQLParser'; load. (Smalltalk at: #ConfigurationOfPetitSQLParser) perform: #loadDefault in the repository there are several packages: the core contains the parser for the grammar. In the package parser there is a parser that instantiate some draft objects representing relational elements. In the next future i will start to implement also other statements. If you start to use it and you have some problem please let me know. Cheers, Fabrizio

13 years, 7 months

Issue 494 in moose-technology: Dynamic presentation should be a browser

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.3 New issue 494 by tudor.gi...(a)gmail.com: Dynamic presentation should be a browser http://code.google.com/p/moose-technology/issues/detail?id=494 The problem is that when in a presentation we ask for entity, we get the value of the entity of the pane around the dynamic presentation, instead of the transformed value.

13 years, 8 months

Issue 510 in moose-technology: Introduce Port>>transientValue:

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Glamour New issue 510 by tudor.gi...(a)gmail.com: Introduce Port>>transientValue: http://code.google.com/p/moose-technology/issues/detail?id=510 We should be able to set the value of a port only temporarily. This would be useful for triggering other transmissions. For example, to implement a search like behavior we could use the code from below. The problem is that if you press the search icon once, then change the selection manually, and then press the button again, the selection will not change because the #focusOne port did not change the value. |browser | browser := GLMTabulator new. browser act: [:b | (b pane port: #focusOne) value: 3 ] icon: MooseIcons mooseSearch entitled: 'Search'. browser column: #one; column: #two. browser transmit to: #one; andShow: [ :a | a tree display: [:x | 1 to: x]]. browser transmit to: #two; from: #one; andShow: [ :a | a tree display: [:x | 1 to: x*2]]. browser transmit to: #one port: #selection; fromOutsidePort: #focusOne. browser openOn: 3

13 years, 8 months

Re: Issue 448 in moose-technology: MOEaselTextEditor contains many methods that are never called

by moose-technology＠googlecode.com

Comment #1 on issue 448 by tudor.gi...(a)gmail.com: MOEaselTextEditor contains many methods that are never called http://code.google.com/p/moose-technology/issues/detail?id=448 Is this still a problem? And what is /branches/?

13 years, 8 months

Re: Issue 460 in moose-technology: scaleBy: should be in shapes, and not in MONode

by moose-technology＠googlecode.com

Updates: Labels: Component-Mondrian Comment #1 on issue 460 by jannik.l...(a)gmail.com: scaleBy: should be in shapes, and not in MONode http://code.google.com/p/moose-technology/issues/detail?id=460 (No comment was entered for this change.)

13 years, 8 months

Problem worth working on

by Alexandre Bergel

Hi! Since some of you are working on remodularizing code, maybe the following may inspire you. In Mondrian, the tests are badly structured. I actually wrote a large part of them as a way for me to understand the initial version of Mondrian, back in 2007-2008. Most of the tests are contained in the class MOViewRendererTest. They actually contain a lot of duplicated scenario (not really code): I open a canvas, put some nodes and edges, run the layout... I would like to cut this class into smaller unit tests. Fixture will have to be found for each new unit tests. How to structure them? Along the class hierarchy? Along the features of Mondrian? Along the features commonly used in Mondrian scripts (which is how they are roughly structured)? I can remodularize my tests and come up with a satisfactory design in a couple of hours. But maybe someone worked on a tool that would help me on this. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

13 years, 8 months

Mondrian bug or my fault?

by Fabrizio Perin

Hi, i got a strange behaviour from Mondrian trying to build a shape for data base tables. Basically defining a shape which contains a rectangle with a title and a children shape it happen that the rectangle containing the title have the same size of the children shape. Is it a bug or is a problem of my code? Below the code that i use, copy and paste in MOShapeSelector the tableShape method and than in a normal mondrian easel window you should be able to reproduce the same behaviour with the snippet below. By using this shape definition: tableShape | builder | builder := MOFormsBuilder new. builder column; fill; pref; grow. builder row; fill; pref; grow; row; fill; pref; grow. builder x: 1 y: 1 add: (MORectangleShape new text: [:table | table name]; fontSize: 10). builder x: 1 y: 2 add: MORectangleShape new. builder x: 1 y: 2 add: MOChildrenShape new. ^view shape: builder shape and using this visualization script: view shape tableShape. view node: (FAMIXNamedEntity new name: 'test') forIt: [ view shape rectangle. view nodes: (1 to: 20). view verticalLineLayout. ]. I got the result in the attachment. Thanks, Fabrizio

13 years, 8 months

Issue 498 in moose-technology: the sizes of the rectangles into built shape are the same

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 498 by fabrizio...(a)gmail.com: the sizes of the rectangles into built shape are the same http://code.google.com/p/moose-technology/issues/detail?id=498 Defining a shape which contains a rectangle with a title and a children shape it happen that the rectangle containing the title have the same size of the children shape while i would expect that the rectangle size was coherent with its content. By executing the following code in Mondrian you will see the problem | builder | builder := MOFormsBuilder new. builder column; fill; pref; grow. builder row; fill; row; fill; pref; grow. builder x: 1 y: 1 add: (MORectangleShape new text: [:table | table name]; fontSize: 10). builder x: 1 y: 2 add: MORectangleShape new. builder x: 1 y: 2 add: MOChildrenShape new. view shape: builder shape. view node: 'hello' forIt: [ view nodes: (1 to: 5). view verticalLineLayout ]

13 years, 8 months

Re: Issue 480 in moose-technology: VerveineJ: file-anchor contains absolute path

by moose-technology＠googlecode.com

Updates: Labels: -Component-Verveine Component-VerveineJ Comment #1 on issue 480 by tudor.gi...(a)gmail.com: VerveineJ: file-anchor contains absolute path http://code.google.com/p/moose-technology/issues/detail?id=480 (No comment was entered for this change.)

13 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev January 2011