Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Issue 927 in moose-technology: Rename the importers with Squeak in their names

by moose-technology＠googlecode.com

Status: New Owner: tu...(a)tudorgirba.com Labels: Type-Enhancement Priority-Medium Milestone-4.8 New issue 927 by tu...(a)tudorgirba.com: Rename the importers with Squeak in their names http://code.google.com/p/moose-technology/issues/detail?id=927 Just what the title says -- 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

12 years

Roassal new algorithms

by mathieubmddehouck＠mailoo.org

Hi There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order. But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points : - The radial one choose its control points within the same radius as its source and its target. I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too. Regards Mathieu

12 years

comments for java enum values

by Vaidotas Didžbalis

Hello, Thank you for Moose tool. It seems that comments for java enum values are not imported in 4.8 dev image. regards, Vaidotas

12 years

#stable and Metacello (was Re: ConfigurationOfGlamourSeaside)

by Chris Cunningham

Interesting. Does Metacello allow us to associate #stable with a version of a platform (for instance, #stable for Moose 4.7)? Because #stable isn't always stable, as you have pointed out. On Wed, Apr 17, 2013 at 8:34 AM, Diego Lont <diego.lont(a)delware.nl> wrote: > Problem found, thanks to Doru. It was loading the stable version of > Glamour. That is apparently not stable in 4.8. It should load the > development version. I changed this, and now I can continue working once I > load GlamourSeaside. Running the tests failed 44 out of 66: When I browse > through them I saw two problems: it needed a HTTPRequest, that no longer > exists (problem in Seaside Tests), and I did not start the Parasol server. > So no surprises here yet. Maybe someone else can test if GlamourSeaside > loads good? > > Cheers, > Diego > > P.S. I now loaded my configuration using GTMetaceller. > > Thanks for doing this. > > I am not sure what you mean by becoming unstable. ConfigurationOfGlamour > #development is already loaded in the image. It should not cause any > further problems. > > What might happen is that ConfigurationOfGlamour loads Magritte which > loads Grease, and this might have an impact on Seaside. Maybe we are not > loading the proper versions. Could it be it? > > Cheers, > Doru > > > > > On Wed, Apr 17, 2013 at 4:01 PM, Diego Lont <diego.lont(a)delware.nl> wrote: > >> Hi all, >> >> Done some more testing and cleaned to configuration to follow standards. >> >> I have an additional note. Currently when I load the development version >> of ConfigurationOfGlamour into moose 4.8, my moose becomes unstable. I am >> not sure what is wrong here, but this makes it hard to test well. So I >> guess I am stuck untill Glamour is stable again in 4.8. >> >> Serge and Doru, >> >> Please let me know if some more work is needed on the >> ConfigurationOfGlamourSeaside. It should be fine now. >> >> Cheers, >> Diego >> >> > Hi all, >> > >> > I am not fully done testing, but so far looking good, so here I share >> how far I am: >> >> Version 0.4 is tested in Moose 4.8. I loaded it in Pharo 2.0 and got >> an error while loading Seaside Tests. Only the tests depend on this >> project, so this should be ok. Maybe the tests even run, when you proceed >> on the warning. >> >> Important note: the configuration of Seaside30 comes from Seaside30 >> repository instead of the MetacelloRepository on squeak source. So you need >> to load this configuration manually before loading GlamourSeaside. >> > >> > After manually loading configuration of GlamourSeaside and Seaside30 >> the following should load this project: >> > >> > (ConfigurationOfGlamourSeaside project version: '0.4') load: 'Examples' >> > After that you should of course start the server by: >> > ZnZincServerAdaptor startOn: 8080 >> > >> > Cheers >> > >> > >> > _______________________________________________ >> > 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 >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > _______________________________________________ > 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 > >

12 years

Version 1.39 of Versionner

by Alexandre Bergel

Hi All, I have produced a new version of Versionner (how odd is that ? :-) What is new: - you can load a project from SmalltalkHub (cf screenshot) - some bugs have been fixed (e.g., browsing a version) - including some other fixes, from Norbert for example Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years

Metacello issue?

by Alexandre Bergel

Hi Dale, I am facing some problem with Metacello that really drive me crazy. Recently we have introduced a dependency to Athens in the baseline 0.6. This triggers some error that I do not understand. For example: Error: Error composing version '1.220': MessageNotUnderstood: SmallInteger>>add: { versionCompositionError } [ #validateProject: ] Error: Error composing version '1.239': MessageNotUnderstood: SmallInteger>>add: { versionCompositionError } [ #validateProject: ] Warning: Symbolic version #development refers to a version'0.6-baseline' whose blessing #baseline is not #development { notDevelopmentVersion } [ #validateVersionSpecForSymbolicVersion:symbolicVersion: ] I am thinking about removing the dependency of Athens because all the tooling we have to development is broken. Do you have any idea what is going on? You can reproduce the problem by doiting the following in a 2.0: -=-=-=-=-=-=-=-=-=-=-=-= Gofer new url: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal/main' ; package: 'ConfigurationOfRoassal'; load. (MetacelloToolBox validateConfiguration: (Smalltalk at: #ConfigurationOfRoassal)) explore -=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years

Build failed in Jenkins: moose-latest-dev-4.8 #288

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/288/> ------------------------------------------ Started by upstream project "roassal" build number 116 originally caused by: [URLTrigger] A change within the response URL invocation (log) [URLTrigger] A change within the response URL invocation (log) [URLTrigger] A change within the response URL invocation (log) Building remotely on moose-slave in workspace <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> Deleting project workspace... done [moose-latest-dev-4.8] $ /bin/sh -xe /tmp/hudson6898755218833735760.sh + bash + wget --quiet -O - http://get.pharo.org/20+vmLatest Downloading the latest 20 Image: http://files.pharo.org/image/20/latest.zip [image.X8lMJ/image.zip] End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of image.X8lMJ/image.zip or image.X8lMJ/image.zip.zip, and cannot find image.X8lMJ/image.zip.ZIP, period. Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results

12 years

Options for Visualization

by Damir Majer

Hi, I´m searching for Options to visualize diagrams, for example an class-diagram. Is there an graphViz-Implementation in Pharo or better other Options to display Diagrams? (here is the graphViz-Dot-Example: graph ethane { Car -- tire1 [type=s]; Car -- tire2 [type=s]; Car -- tire3 [type=s]; Car -- tire4 [type=s]; } Thanks for routing me in the right direction! Cheers, Damir ----- -- Damir Majer ... be agile: www.majcon.de -- View this message in context: http://forum.world.st/Options-for-Visualization-tp4682144.html Sent from the Moose mailing list archive at Nabble.com.

12 years

Re: [Seaside-dev] ConfigurationOfSeaside30

by Dale Henrichs

Johan, I think that OneClick was put where it was because it is in the #squeakPlatform block, not the #common block ... there is no OneClick for GemStone ... IIRC, the original OneClick group was created because I noticed that the OneClick images were built with different contents than the 'default' group, so I created the separate group .. Dale ----- Original Message ----- | From: "Johan Brichau" <johan(a)inceptive.be> | To: "Seaside - developer list" <seaside-dev(a)lists.squeakfoundation.org> | Cc: "Moose-related development" <moose-dev(a)iam.unibe.ch> | Sent: Tuesday, April 16, 2013 1:24:30 AM | Subject: Re: [Seaside-dev] ConfigurationOfSeaside30 | | I adapted that group, which was indeed forgotten (why was it written at the | bottom and the other groups at the top?) | | I'm testing... | | On 16 Apr 2013, at 09:56, Diego Lont <diego.lont(a)delware.nl> wrote: | | > Hi all, Hi Johan, | > | > I tried loading the seaside30 version 3.0.8 into moose 4.8 by using: | > (ConfigurationOfSeaside30 project version: '3.0.8') load: 'OneClick'. | > This resulted in a failure, since there was still some dependency on OB, | > and this could not be resolved, since OB is removed in Pharo 2.0 for the | > time being. | > | > I fixed this by moving 'Seaside-Tools-OmniBrowser' in group 'OneClick' from | > squeakcommon to squeak + pharo 1.x. And since this package is too big for | > the list, anyone who wants it can mail me. | > | > On squeaksource I am called del, so if someone could add me here, I will | > commit this version to the Seaside30 repository. | > | > Cheers, | > Diego_______________________________________________ | > seaside-dev mailing list | > seaside-dev(a)lists.squeakfoundation.org | > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | | _______________________________________________ | seaside-dev mailing list | seaside-dev(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |

12 years

ideas for a new Famix

by Nicolas Anquetil

Hi guys, Food for thoughts. It's a long one, but it is literally the result of years of thinking and discussing Famix in our group. This is still work in progress so that those who might want to participate have a chance to do it before everything is already decided. You can call it a vision for the next Famix (and Fame incidentally) Although the goal of Famix is to be able to model systems in any language, the reality of it is that it focuses very much on OO, and more precisely on ST and Java. And even with only these two languages, it is already difficult. Famix is the union of ST + Java which means unneeded complexity when you deal with only one of the two. Same happen when considering something outside the current scope. For example something as a C function calling another C function is currently represented as an invocation, which means it has a receiver (the object on which a message is sent, useless in C) and also a collection of candidates (whereas in C function names must be unique). When working with different languages, mostly not OO, it started to annoy me, and I wanted to see how we could redesign a new Famix so that: - we have a bare core metamodel that is really language independent - something that is easily extensible so that one does not have to redefine basic stuff (what is a variable, a class, a method) - no "hidden" associations as the declaredType of a FamixStructuralEntity - it is completely model driven, which means we can regenerate all the code in Smalltalk, Java and other languages from the metamodel. Having Fame (and thus Famix) in Java helped a lot when I did VerveineJ. I can imagine having a C implementation of Fame could be nice to reuse old parsers based on Bison+Flex :-) I had two other requirements steming from the way I see metamodels: primarily as conceptual representations of some domain. They should be as clear as possible about what is meant by the concepts and their relationships, and also it should be as close as possible from the human conception of the domain. This implies: - I want it to be typed. C and Java have types to guard the developer from making mistakes, I want types to clarify the meaning of the concepts, like defining an ontology - I want it to have multiple inheritance, with as little restrictions as possible (typical multiple inheritance problems in programming languages) to try to be closer from the abstract conception of the domain. In short, we are looking for the Graal, nothing new here :-) Now the question is how far we can push it and how close can we get? Discussing we had the idea of a GenericEntity, probably equivalent to the current FamixSourcedEntity. We could have generic FunctionEntity, VariableEntity, ClassEntity inheriting from GenericEntity; MethodEntity inheriting from FunctionEntity. And all these only stating consensual things like a class defines methods, a function defines variables. Independent of that (meant to be used through multiple inheritance) we would have the idea that there are ContainerEntity, BehavioredEntity, TypedEntity, maybe even NamedEntity. So that FunctionEntity (which is a GenericEntity) would also be a BehavioredEntity + a NamedEntity. Invocation would occur between two BehavioredEntity And we could create new entities by combining all these things. For example, a JavaMethodEntity would inherit from MethodEntity + TypedEntity + ContainerEntity (may define classes) A PascalProgram could be a GenericEntity+ContainerEntity (contains functions)+BehavioredEntity All this would be declarative in the new Famix and translated in some way by Fame into different languages (lets concentrate on Pharo and Java for now). In a first step, behaviour to be reused (like navigation between a ContainerEntity and its members) could be stored directly in the metamodel for each target language and then copied appropriately when generating actual code. In a second step I also dream of using FAST (AST metamodeling, see http://youtu.be/dRr3WHOD3x4) to model the behaviour abstractly and then generate the code from that. I believe this would introduce only two real changes to Moose: First Fame would have to allow for multiple inheritance, second MooseChef would have to be re-designed to allow for new queries (at least ContainerEntity, BehavioredEntity). And of course, we would need to using it concretely to see whether it really helps considering new languages So this is about it. If you have any idea or comment on this, we will be glad to here from you. If you want to participate, we will be even gladder because we are not that many and it is a lot of work. nicolas -- Nicolas Anquetil -- RMod research team (Inria)

12 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev