- Moose-dev - INF Mailman

by Tudor Girba

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

14 years, 6 months

2
2
0 0

Re: [Pharo-project] [squeak-dev] Re: Graph library in Smalltalk - Need for advices

by Stéphane Ducasse

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

14 years, 6 months

2
1
0 0

Merlin help request

by Johan Fabry

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

14 years, 6 months

3
4
0 0

Problems with the Java parsing of inFusion(?)

by Alberto Bacchelli

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

14 years, 6 months

3
2
0 0

Glamour on Seaside - Steps

by Andre Hora

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

14 years, 6 months

4
4
0 0

Database Building

by Zhe-Xi Lim

Hi, I would like to ask the experts out there: Can Moose/Pharo/Squeak help to build a database which contains some indexes on texts? I might need Moose to analyze the raw texts first before indexing them. Can someone show me the light if this project or method workable? Thanks. Regards, Zhe-Xi -- View this message in context: http://forum.world.st/Database-Building-tp3092712p3092712.html Sent from the Moose mailing list archive at Nabble.com.

14 years, 6 months

2
1
0 0

Re: [Pharo-project] [Hudson] 1.2 build

by Marcus Denker

On Dec 16, 2010, at 5:26 PM, Tudor Girba wrote: > Great news! > > I already updated the Moose build to be based on the current 1.2: > http://hudson.moosetechnology.org/job/moose-latest-dev-on-pharo-1.2/lastSuc… > > > Maybe one suggestion: it would be good to name the image as pharo-1.2-dev, rather than just dev1.2. Ok, I will do that. In addition, it would be nice if the zip would contain inside some version number or date or something. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

14 years, 6 months

1
0
0 0

Re: [Pharo-project] [Hudson] 1.2 build

by Tudor Girba

Great news! I already updated the Moose build to be based on the current 1.2: http://hudson.moosetechnology.org/job/moose-latest-dev-on-pharo-1.2/lastSuc… Maybe one suggestion: it would be good to name the image as pharo-1.2-dev, rather than just dev1.2. Cheers, Doru On 16 Dec 2010, at 12:11, Marcus Denker wrote: > Hi, > > - the pharo 1.2 (and 1.1) full builds are now triggered by a successful build of the core images (failing tests are ok, failing builds do not trigger) > - One-Click of full is now build automatically: > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/20/artifact/PharoOne… > - just image and sources are available at this link https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastSuccessfulBuild/… > - tests are now run on 1.2 full. 24 are failing, of which 12 are from core: > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastCompletedBuild/t… > > > Next step: > > - re-use the core images in the full image builds, do not update again. (saves 5 minutes build time) > > Later: > - build all VMs from source automatically > - run tests on MacOS and Windows in addition to linux (to validate the VM and to check that image side is working on all plattforms) > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

14 years, 6 months

1
0
0 0

Exporter SVG and TikZ are under Construction

by Alexandre Bergel

Hi! Just a word to say that Eduardo is a student at the DCC working on exporting Mondrian views in SVG and TikZ (library for latex). As a goal, I would like to have classblueprint and system complexity exportable. Do you have a visualization you want to see exported? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 6 months

4
6
0 0

Glamour action list without the dropdown?

by Johan Fabry

Hi Doru, all, in AM I have a Glamour pane that is an actionList where I do 5 populate:on:entitled:with: so that the pane has 5 buttons. Now what happens is that the pane also has a dropdown menu, with the same actions as the buttons. This is a bit silly (see screenshot). Is there a way to have the actionList not have this popup menu? Thanks in advance! -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

14 years, 6 months

2
4
0 0

Re: Typo in load script on moosetechnology.org

by Tudor Girba

Thanks, Andy. It's fixed now. Cheers, Doru On 15 Dec 2010, at 12:49, Andy Kellens wrote: > Hello, > > On the page http://www.moosetechnology.org/tools/famix2importer the Gopher script to load the Famix 2 importer is: > Gofer new > squeaksource: 'Famix2Importer'; > package: 'Famix2Impoter'; > load. > > But it should be: > Gofer new > squeaksource: 'Famix2Importer'; > package: 'Famix2Importer'; > load. > > Kind regards, > > Andy -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

14 years, 6 months

1
0
0 0

allModelNamespaces vs allNamespaces

by Johan Fabry

Hi all, a question: I have some Java models imported from intooitus generated .mse files. allNamespaces has a lot of garbage in there (java.* _anonymous _unknown_package_). I found that allModelNamespaces filters those out, but also filters out some of the namespaces that are defined in the model that I imported. I guess this is a bug, right? How does allModelNamespaces work and what is the rationale? -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

14 years, 6 months

2
2
0 0

Tests in Merlin

by Alexandre Bergel

Hi! As a result of the Software Quality lecture we are running at the DCC, Vanessa has written tests for Merlin. They are currently stored under the package Merlin in the Squeaksource repository CC68S Can her tests be merged with Merlin? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 6 months

4
4
0 0

debugging java implementation of Fame ...

by anquetil.nicolas＠gmail.com

Hi all, I need some help with the Java implementation of Fame. I am trying to implement separate parsing in VerveineJ so that one can deal with larger project by parsing them piece by piece. This implies loading in verveine the MSE already created to be able to add new entities to it. And The import method of Repository does not work for big MSE files (that were generated by the export method of Repository BTW) :-( It crashes with a StackOverflow: Exception in thread "main" java.lang.StackOverflowError at java.util.HashMap.put(HashMap.java:389) at java.util.HashMap.putAll(HashMap.java:541) at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:192) at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:191) at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:191) at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:191) at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:191) at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:191) at ch.akuhn.fame.fm3.MetaDescription.allAttributes(MetaDescription.java:139) at ch.akuhn.fame.Repository.add(Repository.java:121) at ch.akuhn.fame.Repository.add(Repository.java:131) at ch.akuhn.fame.Repository.add(Repository.java:131) + zillions of this same line, Repository.add calling itself recursively at line 131 I looked a bit into it and think that the problem may come from line 131 into the Repository.add() method :-) public void add(Object element) { assert element != null; if (elements.add(element)) { MetaDescription meta = metamodel.getDescription(element.getClass()); assert meta != null : element.getClass(); for (PropertyDescription property : meta.allAttributes()) { <--- line 121 if (!property.isPrimitive()) { boolean isRoot = property.getType().isRoot(); for (Object value : property.readAll(element)) { assert value != null : property.getFullname(); if (!(isRoot && (value instanceof String || value instanceof Boolean || value instanceof Number))) { try { this.add(value); <--- line 131 } catch (ClassNotMetadescribedException e) { throw new ElementInPropertyNotMetadescribed(property); } } } } } } } My suspicion is that this recursive call is actually walking through the entire graph of FamixEntities because every entity is related to some other entity ... 1- Anybody want to comment on this suspicion? 2- Any idea how to correct it? nicolas -- Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod

14 years, 6 months

2
3
0 0

InvokedClasses question

by Zhe-Xi Lim

What does the following line mean? InvokedClasses in Smalltalk::Array (59) Thanks. Zhe-Xi Lim -- View this message in context: http://forum.world.st/InvokedClasses-question-tp3080486p3080486.html Sent from the Moose mailing list archive at Nabble.com.

14 years, 6 months

4
6
0 0

PetitParser: An Island Grammar parser

by Alberto Bacchelli

Hi all, I am trying to implement a small "island parser" in PetitParser, but I have a problem. The following is the most self contained example I can think of, it is able to extract the word 'island' from any context. I have the class IslandSyntax, subclass of PPCompositeParser, with the following methods: === IslandSyntax>>start ^world end IslandSytntax>>world world := PPUnresolvedParser new. world def: (island , world) / island / (water,world) / water. ^world. IslandSyntax>>island ^'island' asParser IslandSyntax>>water ^((island not), #any asParser) ==> #second === Then, I have IslandParser a subclass of IslandSyntax: === IslandParser>>island ^super island ==> [:result | result inspect] === If I open a workspace and do: IslandParser new parse: 'blablablaislandblablabla'. The inspect on island is called only once, while if I do: IslandParser new parse: 'island'. the inspector is called twice, probably because in the "world" production I first put (island , world) and then (island). Is there a way to avoid this double calling? Am I doing anything wrong here? Thank you! Alberto

14 years, 6 months

3
2
0 0

Re: Issue 457 in moose-technology: + and - buttons in the easel

by moose-technology＠googlecode.com

Updates: Status: WontFix Comment #2 on issue 457 by tudor.girba: + and - buttons in the easel http://code.google.com/p/moose-technology/issues/detail?id=457 I mark this as a won't fix because it is dependent on the theme, not on mondrian.

14 years, 6 months

1
1
0 0

Re: Issue 471 in moose-technology: Configuration of Glamour should load Shout

by moose-technology＠googlecode.com

Updates: Cc: tudor.girba Comment #1 on issue 471 by jannik.laval: Configuration of Glamour should load Shout http://code.google.com/p/moose-technology/issues/detail?id=471 It is done, Can we close this issue ?

14 years, 6 months

1
1
0 0

Re: PetitParser - some questions

by Lukas Renggli

I redirect this to the moose list, please as there or in the pharo list in the future. > One thing I've noticed is the error messages (PPFailure). I like that > it tells you what is wrong and where. What I don't like is how it > decides to tell you that. This can be customized. > For instance, take your PetitSQL package. If you do: > PPSqlGrammer new parse: 'select * form table' > it will tell you that 'UPDATE' is expected at 0. I'd much rather it > determine what the best match was and tell you it failed there. If > you change the #command from that class to read: > command > ^ createCommand / deleteCommand / insertCommand / updateCommand / selectCommand > and then run the above, it will instead tell you that 'FROM' expected > at 9, which is what I would really like it to do. The choice always reports the last error. Earlier version of PetitParser used to report the error that consumed most input, but I changed it because this was less predictable and less efficient than the current implementation. You can create your own choice parser and return the deepest failure if you think the old behavior is better. > Is this possible out of the box? If not, can you give me some > guidance on how I could make it work this way? What I typically do is to insert failures at particular choices in the grammar, for example: PPSqlGrammer>>command ^ createCommand / deleteCommand / insertCommand / selectCommand / updateCommand / (PPFailingParser message: 'Command expected') Lukas -- Lukas Renggli www.lukas-renggli.ch

14 years, 6 months

1
0
0 0

Re: Moose and Codecity question

by Tudor Girba

Hi Sebastian, I am not aware of anyone that actually did that. However, there would be two possibilities if you want to use Moose for your VASmalltalk code: 1. Migrate the Smalltalk importer, FAMIX and the Fame (from Pharo) or Meta (from VW) to VASmalltalk. This will enable you to export an MSE file and load it on the other side 2. Get your code loaded (it does not have to work, just to load) into Pharo or VW This will enable you to use the importer from those platforms Regarding CodeCity, you should know that it works on the VW version only (which is Moose 3.2). The current Moose version is 4.2 and is available only in Pharo. Cheers, Tudor On 8 Dec 2010, at 20:02, Sebastian Heidbrink wrote: > Hello Tudor, > > there's one little question I have. I wasn't able find instructions or hint on this on the web. > > Do you know a solution or somebody how might know, how to handle VASmalltalk codeing with Moose and CodeCity? > On ESUG in Amsterdam somebody mentioned that there is a way to import VASmalltalk, but there are some "adapters" needed, or need some tweaking? > I'm not really sure anymore. > > I would be very grateful if you could provide me with some hints. > > Cheers! > Sebastian -- www.tudorgirba.com "Being happy is a matter of choice."

14 years, 7 months

1
0
0 0

FAMIXClass

by Andre Hora

Hello, Is there some method on Moose that checks if a FAMIXClass of a Smalltalk model is a class or a metaclass? Cheers, -- André Hora

14 years, 7 months

2
1
0 0

Fwd: Please Fwd LDTA call for paper

by Tudor Girba

FYI Cheers, Doru Begin forwarded message: > > LDTA 2011 Call for Papers and Tool Challenge Submissions > > 11th International Workshop on > Language Descriptions, Tools, and Applications > > www.ldta.info > > Saarbrucken, Germany > March 26 & 27, 2011 > an ETAPS workshop > > LDTA is an application and tool-oriented workshop focused on > grammarware - software based on grammars in some form. Grammarware > applications are typically language processing applications and > traditional examples include parsers, program analyzers, optimizers > and translators. A primary focus of LDTA is grammarware that is > generated from high-level grammar-centric specifications and thus > submissions on parser generation, attribute grammar systems, > term/graph rewriting systems, and other grammar-related > meta-programming tools, techniques, and formalisms are encouraged. > > LDTA is also a forum in which theory is put to the test, in many cases > on real-world software engineering challenges. Thus, LDTA also > solicits papers on the application of grammarware to areas including, > but not limited to, the following: > - program analysis, transformation, generation, and verification, > - implementation of Domain-Specific Languages, > - reverse engineering and re-engineering, > - refactoring and other source-to-source transformations, > - language definition and language prototyping, and > - debugging, profiling, IDE support, and testing. > > This year LDTA will also be putting theory, as well as techniques and > tools, to the test in a new way - in the LDTA Tool Challenge. Tool > developers are invited to participate in the Challenge by developing > solutions to a range of language processing tasks over a simple but > evolving set of imperative programming languages. Tool challenge > participants will present highlights of their solution during a > special session of the workshop and contribute to a joint paper on the > Tool Challenge and proposed solutions to be co-authored by all > participants after the workshop. > > Note that LDTA is a well-established workshop similar to other > conferences on (programming) language engineering topics such as SLE > and GPCE, but is solely focused on grammarware. > > Paper Submission > ---------------- > LDTA solicits papers in the following categories. > > - research papers: original research results within the scope of LDTA > with a clear motivation, description, analysis, and evaluation. > > - short research papers: new innovative ideas that have not been > completely fleshed out. As a workshop, LDTA strongly encourages > these types of submissions. > > - experience report papers: description of the use of a grammarware > tool or technique to solve a non-trivial applied problem with an > emphasis on the advantages and disadvantages of the chosen approach > to the problem. > > - tool demo papers: discussion of a tool or technique that explains > the contributions of the tool and what specifically will be > demonstrated. These papers should describe tools and applications > that do not fit neatly into the specific problems in the Tool > Challenge. > > Each submission must clearly state in which of these categories it > falls and not be published or submitted elsewhere. Papers are to use > the standard LaTeX article style and the authblk style for > affiliations; a sample of which is provided at www.ldta.info. > Research and experience papers are limited to 15 pages, tool > demonstration papers are limited to 10 pages, and short papers are > limited to 6 pages. The final version of the accepted papers will, > pending approval, be published in the ACM Digital Library and will > also be made available during the workshop. > > Please submit your abstract and paper using EasyChair at > http://www.easychair.org/conferences/?conf=ldta2011. > > The authors of each submission are required to give a presentation at > LDTA 2011 and tool demonstration paper presentations are intended to > include a significant live, interactive demonstration. > > The authors of the best papers will be invited to write a journal > version of their paper which will be separately reviewed and, assuming > acceptance, be published in journal form. As in past years this will > be done in a special issue of the journal Science of Computer > Programming (Elsevier Science). > > Invited Speaker > --------------- > Rinus Plasmeijer, Radboud University Nijmegen, The Netherlands > > Important Dates > --------------- > Abstract submission: Dec. 15, 2010 > Full paper submission: Dec. 22, 2010 > Author notification: Feb. 01, 2011 > Camera-ready papers due: TBD > LDTA Workshop: March 26-27, 2011 > > LDTA Tool Challenge > ------------------- > > The aim of the LDTA Tool Challenge is to foster a better > understanding, among tool developers and tool users, of relative > strengths and weaknesses of different language processing tool > techniques as well as different implementations and realizations of > those techniques. Tool developers are invited to participate in the > Tool Challenge and demonstrate their solution to the problems during a > special session of LDTA 2011. > > The problems in the LDTA Tool Challenge Problem Set can be viewed as > points in a two dimensional space: one dimension specifying language > processing tasks and the second dimension specifying the set of > languages to which these tasks are to be applied. Along the task > dimension are several traditional language processing tasks such as > parsing, pretty printing, semantic analysis, optimization, and code > generation. The language dimension is comprised of a simple, but > evolving, suite of imperative programming languages. These two > dimensions form a problem space in which various techniques and > implementations will find problems in which they excel and others in > which they find some challenges; no single technique or tool is > expected to be optimal for all problems. Thus, this is a challenge > and not a competition; no winner is declared. The full description of > the problem set can be found in the LDTA Tool Challenge Problem Set > document on the LDTA web page at ( http://www.ldta.info ). > > The Tool Challenge is open to developers of all kinds of grammarware > tools and techniques. To participate, tool developers must submit the > following by March 5, 2011. Names of participants and the name of > their tool or technique. Presentation title and abstract. The short > abstract should specify on what aspects of the problem set the tool > was applied, where it excelled and where no solution was offered > and/or the solution was considered less than optimal. We expect these > to be only a few paragraphs in length. > > This information is used for scheduling purposes only and is not used > for evaluation; as all tool developers interested in participating are > welcome and will be given an opportunity to present their solution at > the workshop. Submission of this information indicates a commitment > to attend LDTA and to participate in the workshop. This information > will be listed in the program. > > Authors of submissions that appear to be outside of the scope of LDTA > will be contacted to discuss the relevance of their work to the > workshop. Of course tool developers who question whether their work > falls with the scope of LDTA are encouraged to contact the PC chairs > early on for clarification. > > After the workshop a joint paper will be written by participants and > submitted to a journal, most likely Science of Computer Programming. > It is separate from the proceedings of the workshop and any special > journal issue for the workshop. > > Program Committee > ----------------- > Emilie Balland, INRIA, France > Anya Helene Bagge, University of Bergen, Norway, > Paulo Borba, Federal University of Pernambuco, Brazil > John Boyland, University of Wisconsin, USA > Claus Brabrand, IT University of Copenhagen, Denmark, (co-chair), brabrand(a)itu.dk > Jim Cordy, Queen's University, Canada > Kyung-Goo Doh, Hanyang University, Ansan, South Korea > Giorgios Robert Economopoulos, University of Southampton, UK > Laurie Hendren, McGill University, Canada > Nigel Horspool, University of Victoria, Canada > Roberto Ierusalimschy, PontifÃ cia Universidade CatÃ³lica do Rio de Janeiro, Brazil > Johan Jeuring, Utrecht University, The Netherlands > Shane Markstrum, Bucknell University, USA > Sukyoung Ryu, Korea Advanced Institute of Science and Technology, Korea > Joao Saraiva, Universidade do Minho, Portugal > Sylvain Schmitz, Ecole Normale Superieure de Cachan, France > Sibylle Schupp, Hamburg University of Technology, Germany > Eli Tilevich, Virginia Tech, USA > Eric Van Wyk, University of Minnesota, USA (co-chair), evw(a)cs.umn.edu > Eelco Visser, Delft University of Technology, The Netherlands > > > Organizing Committee > -------------------- > Emilie Balland, INRIA, France > Giorgios Robert Economopoulos, University of Southampton, UK -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

14 years, 7 months

1
0
0 0

Mondrian Health Report under Cog

by Alexandre Bergel

Hi! Between 2 and 4 times faster than in a non-jitted vm. No big surprise. Report produced on 2010-12-07T12:10:45-03:00 System version Pharo-1.1.1-- of 12 September 2010 update 11414 Benchmark ManyNode (simple rendering of nodes) : 100 nodes => 2 ms 200 nodes => 4 ms 300 nodes => 4 ms 400 nodes => 8 ms 500 nodes => 10 ms 600 nodes => 11 ms 700 nodes => 12 ms 800 nodes => 12 ms 900 nodes => 17 ms 1000 nodes => 16 ms 1600 nodes => 29 ms 3200 nodes => 53 ms 6400 nodes => 105 ms Benchmark ManyEdges (simple rendering of edges) : 10 edges => 0 ms 20 edges => 2 ms 30 edges => 6 ms 40 edges => 10 ms 50 edges => 15 ms 60 edges => 16 ms 70 edges => 211 ms 80 edges => 35 ms 90 edges => 39 ms 100 edges => 51 ms 200 edges => 217 ms 300 edges => 976 ms Benchmark ManyInnerNodes : 5 nodes => 45 ms 10 nodes => 614 ms 15 nodes => 2948 ms Benchmark Displaying ManyInnerNodes : 5 nodes => 78 ms 10 nodes => 623 ms 15 nodes => 6569 ms Benchmark Displaying ManyInnerNodesAndEdges : 1 nodes => 4 ms 2 nodes => 124 ms 3 nodes => 2520 ms 4 nodes => 29783 ms Benchmark Displaying elementAt : 100 nodes => 2 ms 500 nodes => 4 ms 1000 nodes => 2 ms 1500 nodes => 4 ms 2000 nodes => 4 ms 2500 nodes => 6 ms Benchmark many small nodes : 2000 nodes => 1346 ms Benchmark edges bounds : 500 nodes => 71 ms Benchmark subnodes lookup : 20000 nodes => 2376 ms -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 7 months

1
0
0 0

ConfigurationOfMoose

by Alexandre Bergel

Hi! Doru fixed the mess with the configuration. I do not know what went wrong with my tries. Configuration must be simpler to manage in the future. There is a lot of redundancies. For example: - ConfigurationOfMoose loads Shout, Mondrian, and DSM - Mondrian loads Shout - DSM loads Moose This all should get simpler. Doru, what are the list of actions we need to do? How can we be sure that the problem we had does not appear again? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 7 months

4
6
0 0

Re: question about petitparser

by Lukas Renggli

Best is to send PetitParser questions to the Moose or Pharo list. To make your parser fail you have to enforce that it consumes until the end of the stream with #end: identifier := (#letter asParser , #letter asParser star) flatten end. identifier parse: 'ffff:gggg' Also note that you can replace p , p star with p plus Lukas On 6 December 2010 10:08, Alain Plantec <alain.plantec(a)univ-brest.fr> wrote: > Hi Lukas, > > identifier := (#letter asParser , #letter asParser star) flatten. > identifier parse: 'ffff:gggg' > > returns 'ffff'. > shouldn't it raise an error because of the $: ? > > Maybe you prefer me to ask this kind of question somewhere else. > just let me know > > Cheers > Alain > > -- Lukas Renggli www.lukas-renggli.ch

14 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev