Projects

projects@lrde.epita.fr

1049 discussions

by Akim Demaille

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > DesugarUnaryOps: > - Plus(Int(i)) -> Int(i) > + Plus(Int(i){a*}) -> Int(i){a*} If you don't write this, you loose the annotations?

18 years, 7 months

Re: XRM 48: Use libstratego-gpp for direct pretty printing.

by Akim Demaille

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > Use libstratego-gpp for direct pretty printing. > This is a brand new way of pretty-printing. It relies on a very > recent version of libstratego-gpp and thus requires a very recent > installation of Stratego/XT 0.17M1. > Instead of calling prism-to-abox and Abox-2-text (which implies > creating several temporary files under /tmp) pp-{prism,xrm} do the > pretty-printing themselves and then use libstratego-gpp to transform > the boxed AST into text. This is much more efficient. The point is only speed?

18 years, 7 months

test

by SIGOURE Benoit

test -- SIGOURE Benoit aka Tsuna _____ /EPITA\ Promo 2008, LRDE

18 years, 7 months

Re: XRM 46: Major changes: new way of handling arrays.

by Akim Demaille

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > Major changes: new way of handling arrays. > The whole way of handling arrays in XRM has been changed. The former > way of doing it was somewhat simplistic and quickly reached its > limit. We used to have: x[1][2] represented as ArrayAccess(x, [1, 2]), > we now have: ArrayAccess(ArrayAccess(x, [1]), [2]) which means that > the expression is parenthesized as (x[1])[2]. Pretty much like in > Java/C/C++... So far it did not make sense to have this approach > since one cannot access the intermediate dimensions anyway (eg: if x > is a 2D array, say: x[3][3], it doesn't make sense, in XRM, to access > x[2] for instance). > We are moving to an approach which is more Java/C-like because we > want to be able to write things such as: x[1..3,5,7..9][1,3,5][2..6] > which is suddenly more complex than what we used to support before. > This revision provides several new features among this new way of > writing array accesses: > It is now possible to declare an array using ranges, eg: > x[1..3,7][2..4] will declare a 2D array defined only for certain > ranges (it's somewhat like sparse arrays) > It will soon be possible to write equality tests such as: > x[1..3][2,3]=0 to check whether x[1][2]=0 & x[1][3]=0 & x[2][2]=0 > etc. > Other new operators added in the grammar (but not yet implemented): > x[1..3][2,3]?=0 is there at least one of the elements > that's equal to 0? x[1..3][2,3]?!=0 same but at least one not equal. > Array declarations have been optimized since the declarations are now > directly generated instead of creating a meta-for loop that will be > later unrolled to generate them. This also introduces a problem (see > the TODO). Nice and well documented: congrats!

18 years, 7 months

Re: XRM 43: Fix the XRM rand builtin for negative numbers.

by Akim Demaille

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > +We would like to make "=" and "!=" non-associative. Actually it's > +worse than that since we would like to disallow expressions such > +as 1=2=3 at all, whether they are parenthesized or not. How about choosing the simplest path: a simple type-checking pass?

18 years, 7 months

Re: XRM 38: Add support for ranges in constant propagation.

by Akim Demaille

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > /!\ This commit has all the debugging messages left in the source of > prism-desugar because it seems to trigger a bug in the Stratego > compiler. Therefore we'll be able to use this revision to investigate > the bug. Roughly, what happens is that a strategy such as: > a;b;c;...; (X <+ Y <+ Z ...) > is inlined and transformed (in C) as something like: > ((a;b;c;...;X) <+ (a;b;c;...;Y) <+ (a;b;c;...;Z) <+ ...) > which is totally wrong if a;b;c;... has side effects (such as > defining dynamic rules) Wow... So, do you confirm? How much time did this bug cost you?

18 years, 7 months

Re: XRM 37: Add formulas in constant propagation.

by Akim Demaille

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > Index: tests/xrm/static-const-arrays-desugar.xpm > --- tests/xrm/static-const-arrays-desugar.xpm (revision 0) > +++ tests/xrm/static-const-arrays-desugar.xpm (revision 0) > @@ -0,0 +1,26 @@ > +const int N = 3; > +const int array[N] = 42; > + > +module test > + x[N] : [0..N] init array[N]; > + > + [] x[array[N]]=0 -> (x[array[N]]'=1); > +endmodule > + > +// The above code will generate the following code once > +// collect-static-const-decl and array-decl-desugar have runned. > +// The problem is that the loop "hides" static const variables which > +// are not caught by collect-static-const-decl. > + > +// const int N = 3; > +// > +// for __meta_i_0 from 0 to 2 step 1 do > +// const int array[__meta_i_0] = 42; > +// end > +// > +// module test > +// for __meta_i_2 from 0 to 2 step 1 do > +// x[__meta_i_2] : [0..N] init array[N]; > +// end > +// [] x[array[N]]=0 -> (x[array[N]]'=1); > +// endmodule Nice! Rather than using comments, you should check in the genuine expected output, and compare your output to it. You may want to add option to your binary to check intermediate desugaring.

18 years, 7 months

Re: XRM 31: Add array declarations (sugar).

by Akim Demaille

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > Add array declarations (sugar). > It is now possible to declare arrays such as: b[4][3] : bool; > Multi-dimensional arrays are correctly handled. This is really nice. I would like to emphasize, though, that, unless you plan to make "b[4]" actually mean something here, the user would rather write b[4, 3]. Again, that's only sugar. > + /** > + ** Patch the list of dimensions with the meta-var used in the meta for loop. > + ** Basically this strategy generates a new meta-var used as the iterator > + ** in the meta-for loop and updates the dimensions of the declared array. > + ** The dimension updated is the first one matching Int(_) A minor nit: Please don't forget the ending period for sentences. That's a frequent mistake. > +// FIXME: Try to figure out why concrete syntax fails to work here You bet! > xrm-to-prism = > /* remove XRM sugar, normalize some nodes */ > - topdown(try(xrm-to-prism-desugar)) > + innermost(xrm-to-prism-desugar) What made you change this? > Index: tests/xrm/globals.xpm > --- tests/xrm/globals.xpm (revision 0) > +++ tests/xrm/globals.xpm (revision 0) > @@ -0,0 +1,3 @@ > +for i from 0 to 4 do > + global x[i] : bool; > +end I don't really understand how works your test suite. Shouldn't you be also checking in the expected output?

18 years, 7 months

Re: XRM 42: Extend meta for loops + fix the XRM rand builtin.

by Akim Demaille

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > + DesugarUnaryOps: > + Minus(Int(i)) -> Int(j) where <mulS>(i, "-1") => j > + > + DesugarUnaryOps: > + Minus(Double(i)) -> Double(j) where <mulS>(i, "-1") => j Funny, I would have use 0 - i.

18 years, 7 months

Re: XRM 41: Add the rand() builtin.

by Akim Demaille

>>> "SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes: > + %% ExpressionFunc ::= > + %% (* older builtin functions for backwards compat. *) > + %% "rand" "(" Expression {"," Expression} ")" > + %% (* builtin functions calls using the "func" notation *) > + %% | "func" "(" "rand" "," Expression {"," Expression} ")" What do you mean by "older"? Why did you choose to also include the "func" feature? Why did you choose the name of the functions to be defined in the grammar?

18 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Projects