Moose-dev May 2009

moose-dev@list.inf.unibe.ch

15 participants
43 discussions

Re: FCA and Moose
by Alexandre Bergel 20 May '09

20 May '09

Ok, it makes sense. I just loaded the last version of ConAn, but some error popped up. What is the status ? Where you happy about the implementation? I can port SCG-Algorithm to Pharo, this shouldn't be a problem since I am experienced in this kind of porting. I suggest to use the Moose mailing list for FCA related discussion. Cheers, Alexandre On 19 May 2009, at 05:13, Gabriela Arevalo wrote: > Hi Alex, > > In fact, this is because when I finished my phd, my prototype was > almost broken due to the continuous changes in moose. > So I decided that the next version of ConAn would be Moose > independent to avoid to suffer with Moose evolution and also to be > able to work with any domain (not necessary related to Moose). The > implementation you have seen is something I started last year > recovering my code from my prototype in Store in Bern. > I know the advantages of FAMIXEntity, but it was a nightmare to > repair ConAn in the times that Moose changes a lot. > > Anyway, and considering that moose seems to be stable, I think that > we can make it a subclass of that class. I should think about it. > > cheers, > > gabi > > PS: When are you moving to Chile? >> Hi Gabriela, >> >> I was wondering why your implementation of FCA isn't implemented as >> an extension of FAMIX. Even if FCA has little to do with Structural >> entities in OO languages, FAMIXEntity could be inherited. For >> example, why FormalConcept is not a subclass of it? >> >> Cheers, >> Alexandre > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

7 9

MSEPragmaProcessor in Pharo-dev 309
by Laval Jannik 19 May '09

19 May '09

Hi all, When I want to open a MooseBrowser, a warning appears: 'Old implementation removed since it was not license clean.' This is because in MSEPragmaProcessor>>processClass:, there is "aClass methodDictionary do: [ ---something---]" methodDictionary is a MethodDictionary. And in this class the method do: is deprecated in the last version of pharo. How can I replace it ? The old method is: --- do: aBlock tally = 0 ifTrue: [^ self]. 1 to: self basicSize do: [:i | (self basicAt: i) == nil ifFalse: [aBlock value: (array at: i)]] --- Thanks --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

4 3

Loading Pharo into Moose
by Simon Denier 19 May '09

19 May '09

Dear list With the latest Moose update, it is now possible to load Pharo into Moose in less than a minute. However, after loading Moose, you need to run PackageOrganizerCache buildSystemCache (it takes less than 2 minutes to run). Not sure if I really want to store this cache in MC for the moment -- Simon

2 3

[phamoose] reviewing famix
by Tudor Girba 19 May '09

19 May '09

Hi, I am reviewing the FAMIX implementation in Pharo. It looks pretty nice, but here are a couple of issues: - FAMIX-Extensions harbors right now mostly implementation details (like accept:). I would move them to FAMIX-Implementation - FAMIXSourceAnchor should be extended to deal with various source anchor implementations. - We need extensions to support Exceptions and Annotations If it is Ok with everyone I will go on and tackle these issues. Cheers, Doru -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

4 3

sqMondrian and keyboard problem
by Laval Jannik 19 May '09

19 May '09

Hi all, I have loaded the last version of MondrianLoader in an image 279 and another 304. In both, when mondrian is loaded, I can not use my keyboard in the workspace. Has anyone the same problem ? --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

4 5

Test
by Francois Stephany 19 May '09

19 May '09

Please ignore this message.

1 0

[sqmoose] loading scripts
by Tudor Girba 17 May '09

17 May '09

Hi, I went over some of the loading scripts and I noticed that there were a number of duplicated scripts which led to inconsistencies. So, I now changed them as follows. Every loader has a load method that should load all the prerequisites. For example, we have: - MooseLoader>>load - GlamourLoader>>load - MondrianLoader>>load When loading a prerequisite project that is within the realm of Moose (e.g., Glamour, Mondrian), instead of hardcoding the script we delegate to the appropriate loader. For example: MooseLoader>>loadMondrian Installer ss project: 'Mondrian'; install: 'MondrianLoader'. (Smalltalk at: #MondrianLoader) load. Like this all loading scripts are in exactly one place. The next step would be to go towards something like the Seasiders have with their Package map in which we declaratively build a Moose landscape with all dependent packages. That would be nice both for loading and for creating a dependency visualization. Cheers, Doru -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

3 2

moose cook
by Tudor Girba 17 May '09

17 May '09

Hi, We have both a MooseCook and a Moose-Cook. Moose-Cook is the real one, but MooseCook seems to be very light and basically just have helper methods. Is it Ok to move the existing functionality in other packages and remove this one, or are there other use cases? Cheers, Doru -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

3 3

Dependencies in the Smalltalk Importer
by Mircea Lungu 17 May '09

17 May '09

Hi guys, Today I imported a smalltalk project in Moose/Softwarenaut. I have more than 3500 invocations with multiple candidates in the candidates list. I decided that I will ignore those dependencies. I would rather see fewer dependencies but be sure that the ones I see are for real (some kind of the lower-bounds of inter-package dependencies). The problem is that after removing the ambiguous invocations, I still have spurious invocations. Two examples: - In the project, there is a class which defines the #includes: method. In the resulting model, I have 64 invocations to this class's #include. However, if you look at the code, you see that the overwhelming majority of them are actually invocking List>>includes:. In fact, the model sais that several classes from the VisualWorks Base are depending on my code because they call includes:. - The same situation with the #with. I have it defined in one class, and all the invocations are attributed to the class although almost all are actually invoking the WATagBrush>>with: from Seaside. I am thinking that I should ignore the dependencies that have as target methods that I will define in a blacklist. I would put in there methods which are frequently used like: for: with: contains: etc... I guess I can remove a lot of noise this way. Then i could probably allow the user to further filter methods from the UI of S*naut. However, the user would have to know the system in order to be able to filter out these invocations. And the point of S*naut was that the user did not know the system... :) Does anybody have a better approach to making sure that the dependencies in the model are for real? Cheers, Mircea.

4 8

[phamoose] systemwindow announcer
by Tudor Girba 15 May '09

15 May '09

Hi Alex, In the lastest Mondrian, we have the error of the missing announcement for resize in system window. Is there a possibility to get the patch loaded from Monticello? Cheers, Doru -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev May 2009