List view
- Due by February 29, 2020•62/63 issues closed
Currently we use Maven for Continuous Integration and OSGi (Eclipse Bundles) during development. The problem with this setup is that we need to keep track of dependencies and versions across two different technologies (Maven = pom.xml, OSGi = MANIFEST.MF). This makes adding new dependencies, updating versions or releasing harder then necessary. Next to this, keeping everything described as OSGi Eclipse Bundles makes it harder to run Rascal outside of Eclipse. Because of this we would like to move to a setup in which Maven is in the lead. This changed setup should be done with a minimum impact on day-to-day development routines.
Due by October 15, 2015•4/4 issues closedA compiler for the Rascal language. There are several phases: 1. Feature complete 2. All tests can be compiled. 3. All tests pass. 4. Connection with the Eclipse eco-system. Status update (April 30, 2014): 1. The type checker handles all features 2. The compiler/code generator supports most features (visit on strings is most notably missing) 3. All compiler tests and Rascal tests compile. 4. All compiler tests pass. Most Rascal tests pass (still 20 to go). 5. Many libraries compile. In progress (April 30, 2014): 1. Resolving the remaining issues for all the above steps. 2. Compile all the existing Rascal files, in particular parser generator, type checker and compiler. Not yet started (April 30, 2014): 1. Implement RascalConsole for compiled code. 2. Connect compiled code to the Eclipse eco-system.
Due by September 1, 2014•188/188 issues closed- No due date•1/1 issues closed
- No due date•2/2 issues closed
Allow Rascal to run in a safe sandbox on a server.
No due date•1/1 issues closedUnits of measurement can catch inconsistent use of numbers in expression. Explore how to incorporate them in Rascal.
No due date•3/3 issues closedThe more we are using relations (= set of tuples) the more it becomes clear that we are missing certain data types, in particular ordered relations (= list of tuples). The idea is to add support for 1. ordered relations = list of tuples: ___lrel___ 2. unordered relations = set of tuples : ___srel___ 3. unordered relations with duplicates = nag of tuples: ___brel___ 4. bags The current ___rel___ can be become a super type of all these new ___rel___ types.
Due by February 28, 2013•3/3 issues closedThe Result is powerful and efficient but hard to understand. Replace it by methods that are distributed over the AST hierarchy.
Due by January 31, 2013•1/1 issues closedCurrently, concrete syntax patterns are implemented by first extending the rascal grammar with user-defined syntax rules and then parsing the Rascal file with the extended grammar. We want to move to a simpler architecture that uses a fixed Rascal parser that recognizes concrete syntax patterns with a fixed parser. In a second phase, they are parsed with their own grammar. The expected benefits are: 1. Faster parse time of Rascal code. 2. Less ambiguities. 3. Simplifies typechecking
Due by January 31, 2013•4/4 issues closedThere are shortcomings in the functionality of import and extend. These have to be reconsidered and the implementation has to be adapted.
No due date•1/1 issues closedWe need string formatting facilities to print numbers in the desired format, place aligned string in fields of certain width, and so on. A possible design is to add a format description to each interpolation in a string, e.g. 1. "There remained \<n - 1\> little niggers". (as usual, no formatting) 2. "There remained \<n - 1 : 3r\> little niggers". (right-aligned in a field of 3 wide) 2. "There remained \<n - 1 : 3.2r\> little niggers". (right-aligned as decimal in given format)
Due by December 31, 2013•1/1 issues closedSee description in issues
No due date•7/7 issues closedWe can add ```public``` and ```private``` visibility modifiers to all declarations. When omitted, the default i now ```private```. This is a nuisance (in particular for new users). The idea is to switch the default: when a modifier is omitted from a declaration it will default to ```public```.
Due by December 31, 2012•1/1 issues closedIn this milestone we will have put the type checker between the parser and the AST builder. * The AST builder will create AST nodes which are name and type specific, such that * name resolution does not have to occur at run-time anymore and * dynamic dispatch is resolved up to types (where pattern matching begins we can not do dispatch statically of course)
Due by February 28, 2013•2/2 issues closed- No due date•2/2 issues closed
Since we've build the tutor multiple times, we now know what we want :) This milestone collects issues related to improvements of the tutor.
No due date•1/1 issues closed