- Projects

Re: XRM 66: Add parameterized formulas.
by Akim Demaille 12 Jun '06

12 Jun '06

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > EvalAnd: > + |[ d & e ]| -> |[ e ]| > + where <not(real-eq)>(d, "0") > + EvalAnd: > + |[ d & e ]| -> |[ false ]| > + where <real-eq>(d, "0") > + EvalAnd: > + |[ e & d ]| -> |[ e ]| > + where <not(real-eq)>(d, "0") > + EvalAnd: > + |[ e & d ]| -> |[ false ]| > + where <real-eq>(d, "0") > + EvalAnd: >> [ true & true ]| -> |[ true ]| There is no better way to do it? I think you should traverse & and | operands trying to evaluate them to Booleans, and then there would remain only the bool cases.

1 0

Re: XRM 64: Use --verbose instead of --statistics.
by Akim Demaille 12 Jun '06

12 Jun '06

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > https://svn.lrde.epita.fr/svn/xrm/trunk > Index: ChangeLog > from SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> > Use --verbose instead of --statistics. > This cancels the note of the previous commit. I have not seen the removal of --statistics support.

1 0

Re: XRM 59: Add (buggy) support for PCTL/CSL formulas.
by Akim Demaille 12 Jun '06

12 Jun '06

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > +pkgdata_DATA_built = \ The usual way to say "built" is nodist_pkgdata_DATA

1 0

Re: XRM 59: Add (buggy) support for PCTL/CSL formulas.
by Akim Demaille 12 Jun '06

12 Jun '06

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > Index: src/tools/parse-pctl.str > --- src/tools/parse-pctl.str (revision 58) > +++ src/tools/parse-pctl.str (working copy) > @@ -1,23 +1,23 @@ > // Code mostly from parse-java by Martin Bravenboer <martin(a)cs.uu.nl> > -module parse-prism > +module parse-pctl There is obviously a great deal of code duplication between your prism and pctrl. Can't you do something about it?

1 0

Re: XRM 59: Add (buggy) support for PCTL/CSL formulas.
by Akim Demaille 12 Jun '06

12 Jun '06

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > + ** We use two parse tables for performances. One of them > + (PCTL.tbl) has a ** single start symbol (ModulesFile) and the > + other (PCTL-StartSymbols) has > ** several other start symbols. We're doing this because start > symbol ** selection happens *after* parsing in sglr. So first > all the alternatives ** are parsed, and then the selected start > symbol is chosen. Wow!

1 0

Re: XRM 58: Add ConstantDef in concrete syntax.
by Akim Demaille 12 Jun '06

12 Jun '06

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > Index: src/syn/prism/StrategoPRISM.sdf > --- src/syn/prism/StrategoPRISM.sdf (revision 57) > +++ src/syn/prism/StrategoPRISM.sdf (working copy) > @@ -15,6 +15,7 @@ > "|[" Expression "]|" -> StrategoTerm {prefer,cons("ToTerm")} > "|[" Declaration "]|" -> StrategoTerm {prefer,cons("ToTerm")} > "|[" Command "]|" -> StrategoTerm {prefer,cons("ToTerm")} > + "|[" ConstantDef "]|" -> StrategoTerm {prefer,cons("ToTerm")} > context-free syntax Can you teach me the different between this file, and the change XRM 56: Index: src/syn/prism/PRISM-MetaCongruences.sdf --- src/syn/prism/PRISM-MetaCongruences.sdf (revision 55) +++ src/syn/prism/PRISM-MetaCongruences.sdf (working copy) @@ -7,3 +7,4 @@ "|[" Expression "]|" -> StrategoStrategy {prefer,cons("ToStrategy")} "|[" Declaration "]|" -> StrategoStrategy {prefer,cons("ToStrategy")} "|[" Command "]|" -> StrategoStrategy {prefer,cons("ToStrategy")} + "|[" ConstantDef "]|" -> StrategoStrategy {prefer,cons("ToStrategy")} ? I can see there is "ToStrategy" ot1h and ToTerm otoh, but what are the respective roles? And isn't this a sign you'd like to generate the two files from a common sources?

1 0

Re: XRM 57: Fix boxing of meta-if at Expression level.
by Akim Demaille 12 Jun '06

12 Jun '06

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > Fix boxing of meta-if at Expression level. > The new test fails because of an ambiguity. This ambiguity is a bit > tricky and (IMHO) must be resolved at the grammar level. > Basically we have: > test1 ? test1-true : test2 ? test2-true : test2-false > The ambiguity is: > (test1 ? test1-true : test2) ? test2-true : test2-false > -or- > test1 ? test1-true : (test2 ? test2-true : test2-false) > The second choice seems more natural and that's how it works in C. > Obviously we can't keep this ambiguity in the grammar. You might want to read the third problem in this exam.

1 0

Re: XRM 55: Add documentation draft for XRM.
by Akim Demaille 12 Jun '06

12 Jun '06

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > doc/user-guide.txt | 392 +++++++++++++++++++++++++++++++++++++++ This is nice (and seldom done!).

1 0

Re: XRM 53: Add meta-if at Expression level.
by Akim Demaille 12 Jun '06

12 Jun '06

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > https://svn.lrde.epita.fr/svn/xrm/trunk > Index: ChangeLog > from SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> > Add meta-if at Expression level. > So basically, it is now possible to have a meta-if statement everywhere > we can find an Expression. /!\ NOTE: meta-if statements at Expression > level are restricted to one single expressions in the then-part and > else-part. eg: > if some-condition then > exp1 > exp2 > end > is *invalid* at Expression level because neither the base language > nor the extended language provide real statements/sequences of > expressions. > Other improvements: PRISM-If statements (cond ? then-part : else-part) > are now evaluated by prism-desugar when possible. It is also possible > to reduce the condition of a meta-if statement down to a simple > Int(_) or Double(_). If that Int(_) or Double(_) is zero, the > condition will evaluate as False() otherwise True() [like in C]. > NOTE: for Double(_) all tests are performed with a precision of 10^-7 > in other words if 0.000000001 then ... else /*executed*/ end will be > false. This is nice!

1 0

Vcs cassé sur brasilia
by Roland Levillain 12 Jun '06

12 Jun '06

Vcs est malade chez moi [1]: brasilia ~/src/oln % svn status /usr/lib/ruby/gems/1.8/gems/core_ex-0.5.6.2/lib/core_ex/lazy_loading.rb:120:in `result': uninitialized constant Commands::Runners::Runner::Datas (NameError) from /usr/lib/ruby/gems/1.8/gems/core_ex-0.5.6.2/lib/core_ex/lazy_loading.rb:71:in `load' from /usr/lib/ruby/gems/1.8/gems/core_ex-0.5.6.2/lib/core_ex/lazy_loading.rb:133:in `load' from /usr/lib/ruby/gems/1.8/gems/core_ex-0.5.6.2/lib/core_ex/lazy_loading.rb:149:in `const_missing' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.2.5/lib/active_support/binding_of_caller.rb:80:in `of_caller' from /usr/lib/ruby/gems/1.8/gems/core_ex-0.5.6.2/lib/core_ex/lazy_loading.rb:147:in `const_missing' from /usr/lib/ruby/gems/1.8/gems/ruby_ex-0.4.6.2/lib/commands/runners/runner.rb:42:in `initialize' from /usr/lib/ruby/gems/1.8/gems/ruby_ex-0.4.6.2/lib/concrete.rb:18:in `new' from /usr/lib/ruby/gems/1.8/gems/ruby_ex-0.4.6.2/lib/uri/generic_ex.rb:37 ... 29 levels... from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.4/bin/../lib/vcs/app.rb:17 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.4/bin/vcs-svn:7 from /usr/bin/vcs-svn:18 brasilia ~/src/oln % which svn svn: aliased to vcs-svn brasilia ~/src/oln % gem list *** LOCAL GEMS *** activesupport (1.3.1, 1.2.5, 1.1.1, 1.0.4) Support and utility classes used by the Rails framework. core_ex (0.5.6.2, 0.5.5.0, 0.4.0, 0.3.1, 0.1.3) CoreEx is a proposal for a standard library extension. highline (1.2.0, 1.0.1) HighLine is a high-level command-line IO library. ruby_ex (0.4.6.2, 0.4.5.0, 0.3.0, 0.2.0, 0.1.2) RubyEx contains general purpose Ruby extensions. rubygems-update (0.8.11) RubyGems Update GEM sources (0.0.1) This package provides download sources for remote gem installation ttk (0.2.1) TTK is an extensible framework for dynamic testing. vcs (0.5.2.4, 0.4.1, 0.4.0, 0.3.0, 0.2.148, 0.1) A wrapper over Version Control Systems C'est peut-être une mise à jour de Ruby (dans Debian unstable) qui a cassé Vcs. C'est grave docteur ? Notes: [1] Encore une satanée allergie printanière, sans doute ! :)

2 2