Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Glamour and Rubric
by Usman Bhatti 17 Jun '15

17 Jun '15

Hi, ConfigurationOfGlamourCore>>version315: references Rubric version 1.2.14. But I could not find this version in ConfigurationOfRubric and hence I got an error while loading ConfigurationOfGlamourCore. Did I miss something? usman

3 4

About MOOSE 5.1 in the CI
by Serge Stinckwich 16 Jun '15

16 Jun '15

Hi all, I'm using usually the last MOOSE 5.1 image available in the CI throught Pharo Launcher. Recent MOOSE 5.1 have problems. For example 3 CMD-G in a Playground return a DNU, because String>>findAnySubStr: delimiters startingAt: start has been renamed in Pharo 5.0 into findAnySubStrinhg: delimiters startingAt: start I guess I should not use these images anymore, but why they are build on the CI ? The MOOSE 5.1 image should be labelled as stable in Pharo Launcher also. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

3 3

CfP: VISSOFT'15 - NIER / Tools Demo
by Alexandre Bergel 15 Jun '15

15 Jun '15

Hi! I think this may be of some interest. Deadline June 29. --------------------------------------- VISSOFT 2015 - Call for Papers: New Ideas or Emerging Results and Tool Demos 3rd IEEE Working Conference on Software Visualization (VISSOFT) September 27-28, 2015, Bremen, Germany Paper submission date: June 29, 2015 Notification: July 31, 2015 http://vissoft.info Software visualization is a broad research area encompassing concepts, methods, tools, and techniques that assist in a range of software engineering and software development activities. Covered aspects include the development and evaluation of approaches for visually analyzing software and software systems, including their structure, execution behavior, and evolution. The VISSOFT IEEE Working Conference on Software Visualization continues the history of the ACM SOFTVIS Symposium on Software Visualization and the IEEE VISSOFT International Workshop on Visualizing Software for Understanding and Analysis. The conference focuses on visualization techniques that target aspects of software maintenance and evolution, program comprehension, reverse engineering, and reengineering, i.e., how visualization helps professionals to understand, analyze, test and evolve software. We aim to gather tool developers, experts, users, and researchers from software engineering, information visualization, computer graphics, and human-computer interaction to discuss theoretical foundations, algorithms, techniques, tools, and applications related to software visualization. Topics of interest include, but are not limited to: * Innovative visualization and visual analytics techniques for software engineering data, such as, - source code - static and dynamic dependencies - software evolution and repositories - software documentation - web services - protocol, log, and performance data - parallel techniques - database schemes - software security and privacy issues - workflow and business processes * Visualization to support program comprehension, software testing, and debugging * Interaction techniques and algorithms for software visualization * Visualization-based techniques in computer science and software engineering education * Integration of software visualization tools and development environments * Empirical evaluation of software visualization * Industrial experience on using software visualization VISSOFT features a New Ideas or Emerging Results (NIER) track and a Tool Demo track related to the list of topics suggested above. Papers are solicited that present original, unpublished research results and will be rigorously reviewed by an international program committee. The NIER contributions (New Ideas and Emerging Results) describe work-in-progress and preliminary exciting results. Authors should include open questions and even provocative hypotheses to get early feedback on their research ideas or even support through new research collaborations. Tool contributions describe the design or actual utilization of software visualization tools, with a focus on relevant tool construction aspects or the use of the tool for gaining new insights. Authors should be prepared to demonstrate their tool at the conference. The submission may also contain a link to a screencast (video). All accepted submissions will appear in the conference proceedings and the IEEE Digital Library. -== How to Submit ==- Both types of papers have to be maximum 5 pages long (including bibliography and annexes). Paper submission date: June 29, 2015 (previously: June 15, 2015) Notification: July 31, 2015 Submissions must be submitted online via the VISSOFT 2015 EasyChair conference management system at https://easychair.org/conferences/?conf=vissoft2015 Please adhere to the formatting instruction published on the ICSME website: http://www.icsme.uni-bremen.de/formatting.php -== Organizing Committee ==- General Chair: Jürgen Doellner, Hasso-Plattner-Institut, Germany Program Co-Chairs: Fabian Beck, University of Stuttgart, Germany Alexandre Bergel, University of Chile, Chile NIER/Tool Co-Chairs: Craig Anslow, Middlesex University, UK Johan Fabry, University of Chile, Chile NIER/Tool Program Committee: Bilal Alsallakh TU Vienna, Austria Jennifer Baldwin Swinburne University,Australia Ivan Beschastnikh University of British Columbia, Canada Usman Bhatti INRIA Lille / Synectique, France Michael Burch University of Stuttgart, Germany Andrei Chis Bern University, Switzerland Neville Churcher University of Canterbury, New Zealand Marcus Denker INRIA Lille, France Coen De Roover Vrije Universiteit Brussel, Belgium Jens Dietrich Massey University, New Zealand Bogdan Dit Boise State University, US Matthias Frisch Magdeburg University, Germany Maria-Elena Froese University of Victoria, Canada Michael Homer Victoria University of Wellington, New Zealand James A. Jones University of California, Irvine, US Adrian Kuhn AirBNB, US Jannik Laval Ecole Des Mines de Douai, France Paul Leger Universidad Catolica Del Norte, Chile Andrea Mocci University of Lugano, Switzerland Tim Molderez Vrije Universiteit Brussel, Belgium Chris Parnin NC State University, US Michael Perscheid HPI-Universtat Potsdam, Germany David Roethlisberger Universidad Diego Portales, Chile Christian Tominski Unviversity of Rostock, Germany ---------------------------------------

1 0

inspector lag on pharo 5.1
by Nicolas Anquetil 13 Jun '15

13 Jun '15

In Moose 5.1 (fresh from ci) I have an average sized model (ArgouML, < 260K entities) in the playground,: model := MooseModel root allModels first. <cmd-I> takes 10 seconds to open the GT-Inspector smaller models (14K entities) created form smalltalk or MSE (java) are instantaneous. nicolas

4 7

Visualization: How to get numbers inside epicycles
by offray＠riseup.net 13 Jun '15

13 Jun '15

Hi, With some friends, we're playing with the idea of using epicycles [1] for a visualization. So far, so good and we have some beta code script at [2]. We would like to put a pair of numbers inside the epicycle. So the question is: How can we add a horizontal line wich divides the epicycle in the middle and how can we put a number on each part? [1] http://en.wikipedia.org/wiki/Deferent_and_epicycle [2] http://ws.stfx.eu/2S8R9YAGSJHO Thanks, Offray

3 13

Re: [Pharo-dev] Pratt Parsers for PetitParser
by Jan Kurš 12 Jun '15

12 Jun '15

Hi, Did you tried to inspect the PPFailure in the Moose? There is a tab with a tree structure giving you a pretty good overview, what is going wrong... Or as an alternative, one can call: myParser enableDebug parse:myInput Otherwise, PetitParser really needs some nice error reporting system. I would have integrated one, but I am not aware of any suitable solution :( Cheers, Jan On Fri, Jun 12, 2015 at 8:07 AM Francisco Garau <francisco.garau(a)gmail.com> wrote: > > Hi Camile > > On 11 Jun 2015, at 10:47, Camille <camille.teruel(a)gmail.com> wrote: > > > On 11 Jun 2015, at 09:30, Jan Kurš <kurs(a)iam.unibe.ch> wrote: > > That sounds really cool and useful extension. > > Thank you Jan! > > Regarding the furthest failure, the core of the problem is the distinction > between an error and a failure. Error reports on a problem in the input, > while failure is information for choice parser combinator. In general, the > furthest failure is a better approximation of an error than the last > failure, so we use it. > > I am not sure what exactly is the problem in case of PrattParser. I guess > the last failure gives better results for a user? > > Yes, with furthest failure I get errors from tokenization instead of my > errors. > For exemple with the calculator grammar I gave in my first mail when I > parse ‘1+’ the furthestFailure is ‘$- expected at 2’ whereas I return > ‘expression expected at 2’ because there's a whole expression missing. Same > thing with ‘(1+2’ that returns ‘digit expected at 4’ instead of ‘$) > expected at 4’. > > But furthest failure gives wrong messages in other cases to. > Consider this sequence parser: > > keyword := #letter asParser plus , $: asParser. > keyword parse: ‘foo' > > This returns 'letter expected at 3’, but no matter how many letters I add > to the end I’ll still get ‘letter expected’. > I want to get what is really missing: '$: expected at 3’. > > > Any of those error messages wouldn't be too bad if the failing production > rule were also mentioned. Something like "keyword rule failed with xx > expected at 3" > > But yeah, that would require annotating the production rules which can > pollute the clarity of the grammar definition... > > > Maybe returning the “latest furthest failure” instead of the “first > furthest failure” could solves the problem here (i.e. replacing > with >= > in PPContext>>#noteFailure:)? > > One has to consider a pratt parser included in the normal parser, e. g. > Expressions parsed by pratt in a Java Grammar. Depending where an error > occurs, different strategy for choosing the proper failure is necessary :-/ > > Indeed, my hack (redefining #parseWithContext:) works only when the Pratt > parser is the top parser, but a soon as I compose it I’m screwed because > only parseOn: is sent to the Pratt parser. > That’s why I wonder if letting the parser decide what to return wouldn’t > solve the problem: by default the furthest failure but special parsers can > still decide. > > Regarding tokenization, there is a message token, that returns > PPTokenParser, which transforms a parsed input into the PPToken object. > Perhaps this might be helpful? > > The Pratt tokens are special: a token points back to the parser that > generated it (its “kind”). > PPTokenKind subclasses PPFlatteningParser and generates instances of > PPPrattToken. > A PPTokenKind stores the precedence, the action to be executed when a > token of this kind is met at the start of an expression (for terminals and > prefixes) and the action to be executed when a token is met in the middle > of an expression (for postfixes and infixes). > > Cheers, > Camille > > Cheers Jan > > On Wed, Jun 10, 2015, 20:52 Richard Sargent < > richard.sargent(a)gemtalksystems.com> wrote: > >> camille teruel wrote >> >> On 10 Jun 2015, at 19:11, Chris Cunningham < >> >> > cunningham.cb@ >> >> > > wrote: >> >> >> >> Inteteresting.... >> >> >> >> On Wed, Jun 10, 2015 at 9:36 AM, Camille < >> >> > camille.teruel@ >> >> > <mailto: >> >> > camille.teruel@ >> >> > >> wrote: >> >> Hello Pharoers and Moosers, >> >> >> >> I did a Pratt parser extension for PetitParser. >> >> >> >> >> > <snip> >> > >> >> @PP Devs: >> >> I had trouble with the PPContext furthestFailure that is taken into >> >> account instead of the failures I return, so I had to redefine >> >> #parseWithContext: to return the failures I want. The results given by >> >> furthestFailure were not very meaningful in my case (the same is true >> for >> >> PPExpressionParser btw). >> >> But I guess it was introduced because it gives good results in other >> >> cases. >> >> So would it be possible to change this behavior to let the parser >> decide >> >> if it returns the furthestFailure or the original failure? >> >> >> >> The intent behind the furthestFailure is that it give the failure that >> >> gets the furthest into the source stream. It is most useful when there >> >> are embedded choice operators in the parser - the original/pre furthest >> >> behaviour would return the last failure, which depending on the >> incoming >> >> stream and the order of the choice options could be significantly not >> >> useful. >> >> >> >> I ran into this when working with the sql parser, which started off >> with >> >> the outer choice of (by memory): >> >> ^ selectStatement / insertStatement / updateStatement / >> >> deleteStatement >> >> If I was trying to part a select statement that had an error at the >> very >> >> end of the statement, the parser would return an error talking about >> how >> >> the incoming stream failed in deleteStatement. Not useful. >> >> >> >> I would be saddened if this further failure was not available. >> > >> > Yes in that case returning the furthest failure gives better results. >> > However, this don’t give meaningful messages in all cases. >> > For exemple with the calculator I gave in my previous message, if I >> parse >> > ‘1+’ I want to get ‘expression expected at: 2’ but instead it returns >> ‘$- >> > expected at 2'. >> > I’m not proposing to remove this feature but to let parsers decide to >> use >> > it or not. >> > Something like (changes in bold): >> > >> > PPParser>>parseWithContext: context >> > | result | >> > context initializeFor: self. >> > result := self parseOn: context. >> > >> > "Return the furthest failure, it gives better results than the >> last >> > failure" >> > (result isPetitFailure and: [ self wantsFurthestFailure and: [ >> context >> > furthestFailure notNil ] ]) >> > ifTrue: [ ^ context furthestFailure ]. >> > ^ result >> >> This screams at me. Why not just delegate to the context and use a context >> that returns the preferred failure? e.g. end with: >> ^context preferredResultFor: result. >> >> >> > >> > PPParser>>wantsFurthestFailure >> > ^ true >> > >> > Like this, one can return the failures he wants. >> > >> > PPPrattParser>>wantsFurthestFailure >> > ^ false >> > >> > >> > Camille >> > >> >> >> >> -cbc >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

2 1

PetitMarkdown
by Jan Kurš 12 Jun '15

12 Jun '15

Hi All! I have implemented a PetitMarkdown grammar for PetitParser according to the CommonMark 0.19 specification (http://spec.commonmark.org/0.19/). The current implementation can be loaded like this: Gofer new url: 'http://smalltalkhub.com/mc/JanKurs/PetitParser/main'; package: 'PetitMarkdown'; load. The result of the parsing is AST, so I guess there is a possibility to write a CommonMark -> Pilar AST transformation. I wrote the AST->HTML visitor only. CommonMark uses two pass strategy. The block elements are recognized in the first phase and the inline elements in the second phase. My implementation handles the first phase without any problems, there are some issues with the priorities of inline elements and emphasis (I don't understand, why more than 50% of the whole specification covers this). There are in total 550 example, the current implementation handles 420 of them so far. I guess for the most users it handles more than enough,... If anyone is interested in using it/fixing it/improving performance, I am more than willing to help you. Some of the rules are pretty crazy, so I guess it will take some time before we find best solutions. Cheers, Jan

1 0

Re: [Pharo-dev] Pratt Parsers for PetitParser
by Jan Kurš 11 Jun '15

11 Jun '15

That sounds really cool and useful extension. Regarding the furthest failure, the core of the problem is the distinction between an error and a failure. Error reports on a problem in the input, while failure is information for choice parser combinator. In general, the furthest failure is a better approximation of an error than the last failure, so we use it. I am not sure what exactly is the problem in case of PrattParser. I guess the last failure gives better results for a user? One has to consider a pratt parser included in the normal parser, e. g. Expressions parsed by pratt in a Java Grammar. Depending where an error occurs, different strategy for choosing the proper failure is necessary :-/ Regarding tokenization, there is a message token, that returns PPTokenParser, which transforms a parsed input into the PPToken object. Perhaps this might be helpful? Cheers Jan On Wed, Jun 10, 2015, 20:52 Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > camille teruel wrote > >> On 10 Jun 2015, at 19:11, Chris Cunningham < > > > cunningham.cb@ > > > > wrote: > >> > >> Inteteresting.... > >> > >> On Wed, Jun 10, 2015 at 9:36 AM, Camille < > > > camille.teruel@ > > > <mailto: > > > camille.teruel@ > > > >> wrote: > >> Hello Pharoers and Moosers, > >> > >> I did a Pratt parser extension for PetitParser. > >> > >> > > <snip> > > > >> @PP Devs: > >> I had trouble with the PPContext furthestFailure that is taken into > >> account instead of the failures I return, so I had to redefine > >> #parseWithContext: to return the failures I want. The results given by > >> furthestFailure were not very meaningful in my case (the same is true > for > >> PPExpressionParser btw). > >> But I guess it was introduced because it gives good results in other > >> cases. > >> So would it be possible to change this behavior to let the parser decide > >> if it returns the furthestFailure or the original failure? > >> > >> The intent behind the furthestFailure is that it give the failure that > >> gets the furthest into the source stream. It is most useful when there > >> are embedded choice operators in the parser - the original/pre furthest > >> behaviour would return the last failure, which depending on the incoming > >> stream and the order of the choice options could be significantly not > >> useful. > >> > >> I ran into this when working with the sql parser, which started off with > >> the outer choice of (by memory): > >> ^ selectStatement / insertStatement / updateStatement / > >> deleteStatement > >> If I was trying to part a select statement that had an error at the very > >> end of the statement, the parser would return an error talking about how > >> the incoming stream failed in deleteStatement. Not useful. > >> > >> I would be saddened if this further failure was not available. > > > > Yes in that case returning the furthest failure gives better results. > > However, this don’t give meaningful messages in all cases. > > For exemple with the calculator I gave in my previous message, if I parse > > ‘1+’ I want to get ‘expression expected at: 2’ but instead it returns ‘$- > > expected at 2'. > > I’m not proposing to remove this feature but to let parsers decide to use > > it or not. > > Something like (changes in bold): > > > > PPParser>>parseWithContext: context > > | result | > > context initializeFor: self. > > result := self parseOn: context. > > > > "Return the furthest failure, it gives better results than the last > > failure" > > (result isPetitFailure and: [ self wantsFurthestFailure and: [ > context > > furthestFailure notNil ] ]) > > ifTrue: [ ^ context furthestFailure ]. > > ^ result > > This screams at me. Why not just delegate to the context and use a context > that returns the preferred failure? e.g. end with: > ^context preferredResultFor: result. > > > > > > PPParser>>wantsFurthestFailure > > ^ true > > > > Like this, one can return the failures he wants. > > > > PPPrattParser>>wantsFurthestFailure > > ^ false > > > > > > Camille > > > >> > >> -cbc > > > > > > -- > View this message in context: > http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

2 1

Pratt Parsers for PetitParser
by Camille 10 Jun '15

10 Jun '15

Hello Pharoers and Moosers, I did a Pratt parser extension for PetitParser. A Pratt parser (a.k.a top-down operator precedence parser) handles left-recursion and operator precedence. It handles grouping, prefix, postfix, infix (right- or left-associative) and "multifix” operators (e.g. "if ... then ... else ...", "... ? ... : ...", Smalltalk keyword messages). Normally Pratt Parsing needs a tokenization phase but here tokenization is done on the fly with other PP parsers. Apart from tokenization, no backtracking is needed so parsing is quite fast (approximatively 2 times faster than PPExpressionParser). Here is an exemple of a calculator: parser := PPPrattParser new. "Numbers" parser terminal: #digit asParser plus do: [ :token | token inputValue asNumber ]. parser skip: #space asParser plus. "Parentheses" parser groupLeft: $( asParser right: $) asParser. "Addition, substraction, multiplication, division: all left infix, * and / have higher precedence than + and -" parser leftInfix: $+ asParser precedence: 1 do: [ :left :op :right | left + right ]. parser leftInfix: $- asParser precedence: 1 do: [ :left :op :right | left - right ]. parser leftInfix: $* asParser precedence: 2 do: [ :left :op :right | left * right ]. parser leftInfix: $/ asParser precedence: 2 do: [ :left :op :right | left / right ]. "Power: right infix with higher precedence than multiplication and division" parser rightInfix: $^ asParser precedence: 3 do: [ :left :op :right | left raisedTo: right ]. "Unary minus: prefix with highest precedence" parser prefix: $- asParser precedence: 4 do: [ :op :right | right negated ]. parser parse: '2*3 + 4^(1/2)*3' ----> 12 To try it: Gofer it smalltalkhubUser: 'CamilleTeruel' project: 'PetitPratt'; package: 'PetitPratt'; load Note that it is in beta stage so it might still change drastically. @PP Devs: I had trouble with the PPContext furthestFailure that is taken into account instead of the failures I return, so I had to redefine #parseWithContext: to return the failures I want. The results given by furthestFailure were not very meaningful in my case (the same is true for PPExpressionParser btw). But I guess it was introduced because it gives good results in other cases. So would it be possible to change this behavior to let the parser decide if it returns the furthestFailure or the original failure? Cheers, Camille

1 0

Feedbacks from Moose Course
by Anne Etien 10 Jun '15

10 Jun '15

Hi, Last week, we made (Guillaume Larchevêque and my self) 6 hours about Moose. Guillaume was using Moose 5.0 and me the latest stable 5.1 version. The purpose was, after an introduction to Moose to be able to analyse a real project with a reasonable size (35 to 420 FAMIXClasses) in order to evaluate its quality. We met some issues: - MSE file generated by VerveineJ could not be used in Version 5.0 (FileAnchor issue) - From the MoosePanel, right clicking on a FAMIXClassesGroup to build the UML diagram: - sometimes, the panel is completely white (since no error, or exception are raised, it is difficult to know why) - when the UML class diagram appears, it is no zoomable and there is no way to export it. We had to hack the visualization to inspect the view in order to get access to the zooms and the exports. - sometimes, I reorganized the figure before exportation, but in that cases, the resulting figure didn’t contain the whole diagram. - When querying a collection of FAMIXEntity, it would be great to get an answer even if the result is empty. Where can I put some new issues? Have we migrated from google code? Am I the only one teaching Moose? Having these issues? Cheers, Anne

5 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev