Hi,
Over the past week I worked on strengthening the new Jenkins infrastructure:
- created multiple jobs for Moose subprojects like Fame, Glamour or PetitParser. We should continue to create such jobs for all projects.
- Made the jobs to react on commits to the respective repositories, and to trigger the full Moose build. Like this we both ensure that every individual project is loadable as standalone, and we ensure that the integration tests are run after every commit.
- created shortcuts:
ci.moosetechnology.org -> https://ci.inria.fr/moose/ci.moosetechnology.org//moose-latest-dev.zip -> https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/arti…
Cheers,
Doru
--
www.tudorgirba.com
"To utilize feedback, you first have to acquire it."
Hi,
Would it make sense to test PPCompositeParser subclasses to not end with returnSelf for productions?
Each time I start building a new parser I manage to forget a few ^'s
I could either add some code to PPCompositeParserTest>parserInstance
to check methods having same-named instance variables, or do the same to
the PPCompositeParser itself
Stephan
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 920 by norbert.hartl: Petit parser UI shows only production rules
that have an instance variable in the selected class
http://code.google.com/p/moose-technology/issues/detail?id=920
In the petit parser UI if I select a class I can see all production rules
of that class. If I have a derived parser class that does not implement
every of the production rules I get only those which are defined in the
derived class.
It would be good if the pane of the production rules list could show
productions from every class in the hierarchie above the petit parser ones.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
---------- Forwarded message ----------
From: Oscar Nierstrasz <oscar(a)iam.unibe.ch>
Date: Tue, Mar 19, 2013 at 2:27 PM
Subject: [Evol] Call for PhD candidates in the Software Composition Group,
U Bern
To: evol(a)lists.inf.unisi.ch
Applications are invited for PhD candidates at the Software Composition
Group, University of Bern, Switzerland.
The Software Composition Group carries out research in software analysis
and programming language design and implementation, with a view to enabling
software evolution. The SCG is led by Prof. Oscar Nierstrasz and is part
of the Institute of Computer Science and Applied Mathematics (IAM) at the
University of Berne.
Details about current and ongoing research can be found here:
http://scg.unibe.ch/research/
The candidate must have a MSc in Computer Science (equivalent to a Swiss
MSc), should demonstrate strong programming skills, and have research
interests in several of the following areas:
- software evolution
- program understanding
- software modeling
- model-driven engineering
- reverse engineering
- domain specific languages
- dynamic analysis
- integrated development environments
- programming language design
- virtual machine technology
To apply, please send an email including your CV, with references, to Prof.
Oscar Nierstrasz (oscar(a)iam.unibe.ch), by April 15, 2013.
Oscar Nierstrasz
---
Prof. Dr. O. Nierstrasz -- oscar(a)iam.unibe.ch
Software Composition Group -- http://scg.unibe.ch/oscar
University of Bern -- Tel/Fax +41 31 631.4618/3355
_______________________________________________
Evol mailing list
Evol(a)lists.inf.unisi.ch
http://lists.inf.unisi.ch/mailman/listinfo/evol
--
www.tudorgirba.com
"Every thing has its own flow"
Hi.
In Pharo 2.0 PetitSmalltalk tests are failing.
Firs of all there are real problems with parsing as some test fail because
parser finishes to parse before the end of the stream. Right now I don't
know what's causing the problem and how to solve it.
Then there is a ton of deprecation warnings as PPToken>>#value became
deprecated and it's recommended to use #inputValue. It's now hard to fix
that, but there are two problems.
1) At places where #value message is sent, not only PPToken is used as a
receiver, but sometimes RBToken is used instead. And RBToken does not
understand the #inputValue message. This can be hacked by adding a
protocol-extension that will return "self value" then, but it's not very
nice.
2) Some #value messages are sent from methods in AST-Core package, and I
don't know how we should deal with that.
Any ideas for solutions?
Uko
--
View this message in context: http://moose-dev.97923.n3.nabble.com/Failing-PetitSmalltalk-tests-tp4026442…
Sent from the moose-dev mailing list archive at Nabble.com.
Hi,
I put together a little description of how we built the Moose job on Jenkins using the CommandLine infrastructure. Perhaps it is useful for other people as well:
http://www.tudorgirba.com/blog/moose-4-8-on-jenkins
Cheers,
Doru
--
www.tudorgirba.com
"Be rather willing to give than demanding to get."