Hi!
As you know, the moose team is full of passionated and happy people willing to analyze software.
We have great platforms to carry out analysis that are robust enough to compete with state-of-the-Art software analysis platforms out there.
It would be great to have software to feed our wonderful tools. There are 123 873 packages on Smalltalkhub (!). Can we have easily access to them? I mean, a big big big .zip file would be fantastic with all the public software.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
For the past few months I've been distracted by working on Issues for
Pharo 3.0 Beta. Now that it is almost released, its time for me to
return to packaging my masters project for release (it was good to have
the break after handing everything in). I wrote my project on top of
Moose 4.7-Development and I have modification against some of the
packages. Some of these are not worth merging into the current HEAD
since I'll be migrating to GraphET and Roassal2. However it would be
good to have them somewhere I can reference them for a Configuration of
a working system before I do that migration. It would be useful for them
to be in their main repositories rather than trying to work out
something else.
Can I get access to upload to the EyeSee, Glamour, Magritte and Roassal
repositories?
Here is a summary of what I would upload, compared to Moose47 and latest
versions:
* EyeSee had extension Dictionary class >> keys:values: that hardcoded a
reference to 'Dictionary' preventing use by subclasses that I had. So I
change that reference to 'self'.
Latest EyeSee-Core-VincentBlondeau.110
Moose47 EyeSee-Core-AndreHora.100
LEKtrek01 EyeSee-Core-BenComan.101
* I added two features to Magritte:
* MADropDownListMorph
* MASeparatorMorph
Latest Magritte-Morph-SeanDeNigris.86
Moose47 Magritte-Morph-NickAger.63
LEKtrek01 Magritte-Morph-BenComan.66
* I introduced #newView: to Glamour-Roassal so that #painting: could
receive a raw ROView rather than only ROMondrianBuilder. I believe
similar functionality ended up being integrated into the mainline later
on, but there are too many other changes for me to catch up for the 0.1
release.
Latest Glamour-Morphic-Renderer-AndreiChis.239
Moose47 Glamour-Morphic-Renderer -TudorGirba.183
LEKtrek01 Glamour-Morphic-Renderer -BenComan.181
Latest Glamour-Roassal-Presentations-TudorGirba.20
Moose47 Glamour-Roassal-Presentations-TudorGirba.8
LEKtrek01 Glamour-Roassal-Presentations-BenComan.10
Latest Glamour-Tests-Roassal-TudorGirba.6
Moose47 Glamour-Tests-Roassal-TudorGirba.4
LEKtrek01 Glamour-Tests-Roassal-BenComan.5
* I ended up a long way behind with Roassal. I added several features
that I think some made their way into the mainline, but I just didn't
keep up:
* adjust popup position
* added selections
* drag multiple items at a time
* work with ROView in Glamour
* keypress modifiers shift/control/alt
Latest Roassal-AlexandreBergel.757
Moose47 Roassal-AlexandreBergel.476
LEKtrek01 Roassal-BenComan.396
Latest RoassalMorphic-AlexandreBergel.170
Moose47 RoassalMorphic-VanessaPena.111
LEKtrek01 RoassalMorphic-BenComan.81
cheers -ben
Hi everyone,
we all have seen how cool CodeCity can the visualisation be on example of Pharo3 changes. But my question is: can we make platform to be somehow wider than the “wall” inside of it? Because in my case colour of a platform may not be the same as all the nodes on the wall and it’s hard to understand if it’s the platform that is red or the nodes at the bottom of the wall.
I’ve tried to do "wallLayout outerGap: 5 asCCPoint”, and it gives the desired result, but then walls also start to float above platforms.
I’d be thankful for any suggestion.
Uko
You might want to take a look at DeprecationFinder (on smalltalkhub).
You could make a data structure representing all missing dependencies for a package, so you can create independent models for all versions of packages. If you can reason about multiple versions of packages you calculate which versions can (not) work together based on class/method signatures.
To do this over something as large as Moose, you currently need to create deltas or at least a structure more memory efficient than Famix, otherwise you'll run out of memory. I'm looking forward to a 64 bit image+vm
Stephan
Hi guys.
I’ve encountered an error that occurs when we are displaying for example dict in GTInspector. There is very nice functionality which sorts items according to one column
column: 'Key'
evaluated: [:each | GTObjectPrinter new asTruncatedTextFrom: each key ]
sortedBy: [:x :y | x > y ];
but not all objects know how to respond to #>.
Any ideas how to solve this in a mic way?
Uko
Hi all,
I have two questions :
how to load Moose in Pharo 1.0?
then how can I make in a programmatic way a MooseModel with packages that I chose in Pharo 1.0?
cheers,
------------------------------------
Hayatou
Ok, with some more configuration massage, some parts of it actually work.
The dependency on Magritte-Seaside was missing.
It still depends on Mondrian...
Stephan
Dory wrote:
>Pretty cool. Did you by any chance run it locally to see if it actually works?
Nah, no need if the tests run ;)
The tests don't tell you:
- need to load Zinc-Seaside
- need to load JQueryUI
Then you get to see something. WATableTag>border: is still missing,
I don't know where to get that.
Stephna
