Hi!
I've heard some time ago there has been an attempt to have models obtained from C# program. What is the status?
cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
sounds good!
STef
On Nov 12, 2010, at 11:01 PM, Tudor Girba wrote:
> Until someone raises an objection :), I created a baseline42 that does not include RB, and official build based on 1.1 is using this one for now.
>
> Cheers,
> Doru
>
>
> On 12 Nov 2010, at 18:43, Tudor Girba wrote:
>
>> Hi,
>>
>> As I said, the problem appears because right now the default configuration of Moose loads the latest RB code, which no longer works with the OB that is loaded in 1.1.
>>
>> The solution I propose goes like this: we release a 4.2 based on Pharo 1.1, and then we move the development to Pharo 1.2.
>>
>> Any objections?
>>
>> Cheers,
>> Doru
>>
>>
>> On 12 Nov 2010, at 16:38, Lukas Renggli wrote:
>>
>>> "Interactive*Change" were all merged with their superclass "*Change".
>>> Just change the refernces to their superclass and everything should
>>> continue to work.
>>>
>>> Lukas
>>>
>>> On Friday, November 12, 2010, Fabrizio Perin <perin(a)iam.unibe.ch> wrote:
>>>> Thanks Doru. Yep definitely the cause is some modification of RB. What it is not clear is if it is a bug or Moose just load an unstable version (since they are still migrating the system).
>>>>
>>>> Cheers,
>>>>
>>>> Fabrizio
>>>>
>>>>
>>>> On 12 Nov 2010, at 16:02, Tudor Girba wrote:
>>>>
>>>>> Hmm, I can reproduce it. I am not sure where it comes from. The cause that come to mind is the recent changes in RB that is moving to Pharo 1.2. We are now loading RB to make sure that it loads in the Core, and this means that when RB changes, it affects the default of Moose.
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> On 12 Nov 2010, at 13:03, Fabrizio Perin wrote:
>>>>>
>>>>>> Hi,
>>>>>> I started to develop a new tool but i cannot create a new class. When i try save a modified class template i got an error. Apparently the class "Refactoring-Core-Changes>>>InteractiveAddClassChange" has been removed since the build 433 of the Moose.
>>>>>>
>>>>>> Can anyone reproduce the error?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Fabrizio
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "From an abstract enough point of view, any two things are similar."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Next time you see your life passing by, say 'hi' and get to know her."
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Being happy is a matter of choice."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
if it make senses.....
Stef
Begin forwarded message:
> From: Kim Mens <Kim.Mens(a)uclouvain.be>
> Date: November 12, 2010 10:51:21 PM GMT+01:00
> To: all INGI / INFO <all-ingi(a)listes.uclouvain.be>, moves-announce(a)soft.vub.ac.be, researchers VARIBRU <varibru-team(a)googlegroups.com>, Benevol2008 <benevol2008(a)win.tue.nl>, evol(a)lists.inf.unisi.ch
> Subject: [Evol] Call for Systems of the 4th Science of Computer Programming special issue on Experimental Software and Toolkits
>
> =============================================
> Call for Systems:
> Science of Computer Programming
>
> Fourth special issue on
> Experimental Software and Toolkits (EST)
>
> Deadline for submissions: January 17th, 2011
> In cooperation with WASDeTT 2010
>
> http://www.win.tue.nl/~mvdbrand/SCP-EST/
> =============================================
>
> The idea in a nutshell: Reproducibility and Accessibility
>
> The journal 'Science of Computer Programming' of Elsevier Science has
> a long history of publishing high-quality articles on programming and
> software. The idea of this special issue on Experimental Software and
> Toolkits (EST) is to allow academic software developers to publish
> the software system they developed together with a (short) paper. We
> hope this will help the software community to find a wider audience
> for their work. Moreover, by enhancing the accessibility and the
> reproducibility of results, we hope to help to encourage a wider
> application and adoption of experimental software.
>
> The first call for systems resulted in the special issue published as
> Volume 69, Numbers 1-3 of Science of Computer Programming. The second
> issue was published as special issue as Volume 72, Numbers 1-2 of
> Science of Computer Programming. The third issue was in cooperation
> with WASDeTT2008 and was published as third special issue as Volume
> 75, Number 4 of Science of Computer Programming. Given the success
> of these special issues, a fourth special issue is planned, the
> deadline for submitting systems is the 17th of January, 2011.
>
> Aim and scope
>
> Academic software development may involve the development of huge
> software systems in order to perform all kinds of experiments. This
> can be compared with huge experiments in physics or chemistry. The
> focus of researchers developing such experimental software systems is
> mainly on software development. The software developer has some idea,
> algorithmic or functional, and in order to prove his or her idea
> software is adapted or newly developed. Some of these systems are
> distributed to different researchers and may become very popular in
> the community. The software development of these systems is almost
> always in conflict with papers that are to be written. Specially if
> the users community grows and the requests for enhancements and
> improvements increases. The application areas of these software
> systems are rather diverse, from language prototyping environments,
> theorem provers, visualisation tools, renovation tools, programming
> environments, etc.
>
> This EST initiative is focussed on the creation of a forum where
> beside the paper the software system itself is published. Two obvious
> questions arise here:
>
> * What is the difference between this initiative and the open source
> facilities like SourceForge? The most important and challenging
> difference is that the software is reviewed. A number of
> independent referees will review both the system and the system
> description paper and will give a verdict.
> * What is the difference with tool demonstrations at conferences and
> workshops. The difference is that at conferences tool
> demonstrations are accepted based on the tool demonstration only,
> the referee has no opportunity to install and use the system or
> have a look at the code.
>
> We want to invite authors to submit software systems together with a
> paper. We want to go one step further than the tool demonstrations
> at the various conferences. The software systems is reviewed on
> various aspects:
> * ease of installation,
> * quality of (user) documentation,
> * ease of usage, and
> * applicability and relevance to the intended domain.
>
> Referees will also be invited to have a look at the actual code of
> the system. The major improvement over the conference and workshop
> tool demonstration is that a broader audience is able to use the
> system, the software system will be published by Elsevier as well.
>
>
> Guidelines for authors
>
> In order to submit a software system the author has to produce a tool
> description paper, we expect the size and quality of a research paper
> but the topic is on the tool, its usability, installation, and
> optionally a few words on tool building issues. The size of the tool
> description paper is at least 12 pages. The main goal of the paper is
> to introduce the tool, the application domain of the tool and to give
> a comparison with relevant related tools and systems. Moreover,
> relevant theory should concisely be addressed.
>
> The requirements of the software system itself:
> * Installation documentation.
> * The source files and an installation script or procedure, it is
> possible to provide the binaries as well, but the original source
> files are required for code inspection.
> * A number of example applications.
> * User documentation.
>
>
> Instructions
>
> The submission deadline is January 17th, 2011. Authors are requested
> to submit their system and corresponding paper electronically to EES
> (see http://ees.elsevier.com/scico) in PDF format by selecting 'SI:
> WASDETT EST 2010'. We encourage the use of the Elsevier style file
> for LaTeX (see http://www.elsevier.com/locate/latex).
>
>
> Copyright
>
> The copyright of the articles is held, except where noted, by
> Elsevier Science. Copyright as well as other proprietary rights in
> the source code are held by the authors. By submitting the code along
> with the article, the authors have agreed to permit the readers of
> Science of Computer Programming the right to use the algorithms for
> personal and professional research use, but not for any further
> redistribution, further sub-licensing, or commercial use. All rights
> are otherwise reserved. Authors are thus free to distribute the
> published version of the source code via other media as well as to
> develop and distribute new versions of the source code.
>
>
> Guest editors
>
> Prof. Mark G.J. van den Brand
> Faculty of Mathematics and Computer Science
> Eindhoven University of Technology (TU/e)
> Den Dolech 2
> NL-5612 AZ Eindhoven, Netherlands
> URL: http://www.win.tue.nl/~mvdbrand
>
> Prof. Kim Mens
> Université catholique de Louvain (UCL)
> Louvain School of Engineering (EPL)
> Institute for Information and Communication Technologies, Electronics
> and Applied Mathematics (ICTEAM)
> Department of Computing Science and Engineering
> Place Sainte Barbe, 2
> B-1348 Louvain-la-Neuve, Belgium
> URL: http://www.info.ucl.ac.be/~km
>
> Dr. Holger Kienle
> School of Innovation, Design and Engineering
> Mälardalen University
> Box 883
> 721 23 Västerås
> Sweden
> URL: http://holgerkienle.wikispaces.com/
>
> ============================================================
> To contribute to SEWORLD, send your submission to
> mailto:seworld@sigsoft.org
>
> http://www.sigsoft.org/seworld provides more
> information on SEWORLD as well as a complete archive of
> messages posted to the list.
> ============================================================
> _______________________________________________
> Evol mailing list
> Evol(a)lists.inf.unisi.ch
> http://lists.inf.unisi.ch/mailman/listinfo/evol
Hi,
I started to develop a new tool but i cannot create a new class. When i try save a modified class template i got an error. Apparently the class "Refactoring-Core-Changes>>>InteractiveAddClassChange" has been removed since the build 433 of the Moose.
Can anyone reproduce the error?
Cheers,
Fabrizio
I've been playing with PetitParser and I keep running into what seems like a
common case. I want to skip everything up to the first match of my second
parser.
For example, if I don't care about anything in a string that comes before
'dd', I write:
parser2 := 'dd' asParser negate plus, 'dd' asParser ==> [ :nodes | nodes
second ].
parser2 parse: 'kslkxjclkxjcdd'. "Returns 'dd'"
This gets the job done, but seems awkward. What's the most elegant way?
I thought maybe "'dd' asParser not plus, 'dd' asParser."
But the image just hangs.
Thanks.
Sean
--
View this message in context: http://forum.world.st/PetitParser-skip-everything-up-to-X-tp3038824p3038824…
Sent from the Moose mailing list archive at Nabble.com.
I'm flopping around trying to flatten an array. I can't seem to get it...
input := '...
Optical Drive Type: CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-R, DVD-R DL,
DVD-RW, DVD+R, DVD+R DL, DVD+RW
Optical Media Type:...'
lineBreak := #cr asParser / #lf asParser.
driveTypeHeader := 'Optical Drive Type: ' asParser skipUntil.
driveType := (', ' asParser / lineBreak) negate plus flatten.
additionalDriveType := ', ' asParser, driveType ==> [ :nodes | nodes second
].
driveTypeList := (driveType, additionalDriveType star).
parser := driveTypeHeader, driveTypeList, lineBreak ==> [ :nodes | nodes
second ].
parser parse: input.
Returns: "#('CD-ROM' #('CD-R' 'CD-RW' 'DVD-ROM' 'DVD-R' 'DVD-R DL' 'DVD-RW'
'DVD+R' 'DVD+R DL' 'DVD+RW'))"
Makes sense so far, but if I change the above to:
...
driveTypeList := (driveType, additionalDriveType star) flatten.
...
Returns: "'CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-R, DVD-R DL, DVD-RW, DVD+R,
DVD+R DL, DVD+RW'"
Instead of combining the arrays, it made one big string!?
How do I do this?
Thanks.
Sean
--
View this message in context: http://forum.world.st/PetitParser-problem-flattening-a-collection-tp3038980…
Sent from the Moose mailing list archive at Nabble.com.
On 11 nov. 2010, at 23:25, Tudor Girba wrote:
> Hi,
>
> It looks like the Fame tests decide to fail from time to time. I could not figure out what the problem is right now, but if you want to reproduce the problem, take the latest Moose and run the tests multiple times. Different tests crash in what appears to be a random order.
>
> I could use some help on this one :)
Would it be possible to hack SUnit so that the test suite is kept in case of failures? Then we could assess which test sequence fails the tests.
--
Simon
Hi,
It looks like the Fame tests decide to fail from time to time. I could not figure out what the problem is right now, but if you want to reproduce the problem, take the latest Moose and run the tests multiple times. Different tests crash in what appears to be a random order.
I could use some help on this one :)
Cheers,
Doru
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
I make changes to load Moose on pharo 1.2
here is the script:
=====
Gofer new
squeaksource: 'rb';
package: 'AST-Core';
package: 'Refactoring-Core';
package: 'Refactoring-Changes';
package: 'Refactoring-Critics';
package: 'Refactoring-Environment';
package: 'Refactoring-Spelling';
load.
(ConfigurationOfShout project version: '1.2') load.
Gofer new
squeaksource: 'Moose';
package: 'ConfigurationOfMoose';
load.
(Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault.
=====
It loads, with some deprecation due to FileSystem. I have not the right to change that.
But moose loads :)
---
Jannik Laval