Re: FCA and Moose
by Alexandre Bergel
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
14 years, 4 months
MSEPragmaProcessor in Pharo-dev 309
by Laval Jannik
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
---
14 years, 4 months
Loading Pharo into Moose
by Simon Denier
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
14 years, 4 months
[phamoose] reviewing famix
by Tudor Girba
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."
14 years, 4 months
Test
by Francois Stephany
Please ignore this message.
14 years, 4 months
[sqmoose] loading scripts
by Tudor Girba
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."
14 years, 4 months
moose cook
by Tudor Girba
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."
14 years, 4 months
Dependencies in the Smalltalk Importer
by Mircea Lungu
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.
14 years, 4 months
[phamoose] systemwindow announcer
by Tudor Girba
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."
14 years, 4 months
