I want to have all the presentations which would usually appear for an object
in the inspector, but embedded in a pane of a Glamour browser. I'm looking
for something like this (naive and non-working):
browser transmit
from: #one;
to: #two;
andShow: [ :a :b | b gtInspectorPresentationsIn: a inContext: nil ].
Thanks!
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/GT-Inspector-Presentations-in-Glamour-Browser-tp49337…
Sent from the Moose mailing list archive at Nabble.com.
Hi,
Andrei and Alex did a great job at improving the performance and scalability of the inspector.
There are a couple of main improvements:
- Added FastTable support for the Raw presentation for all objects. This implied completing the support for the tree presentation binding to fast table.
- Moved the Items presentation for collections to FastTable.
- Improved the rendering of Glamour to no longer rely on the default Morph>>#adoptPaneColor. It turns out that using adoptPaneColor triggers a relayout of the morph, even if it is not visible. We extended PanelMorph in the context of Glamour with a less needy logic.
I will not tell you how fast it is. I would rather want you to play with it :).
The change is already in the Moose image. It is not yet in Pharo, but it will be soon. In the meantime you can be load it in Pharo 6 like this:
Gofer new
smalltalkhubUser: 'Moose' project: 'GToolkit';
package: 'ConfigurationOfGToolkitCore';
load.
(#ConfigurationOfGToolkitCore asClass project version: #stable) load
To play with it, try this with both the current version and the new one and the Spec Inspector if you want (just make sure you save the image beforehand):
collection := (1 to: 100000000) asArray.
[collection inspect] timeToRun.
collection := (1 to: 100000000).
[collection inspect] timeToRun.
(for these two ones notice that Items do not appear at all in the old implementation)
[World inspect] timeToRun.
There are still a couple of issues open, such as the sorting of the columns. We would need your help with testing this, and report possible missing issues.
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"Obvious things are difficult to teach."
Dear all,
thanks to the efforts of Jigyasa Grover, Yuriy Tymchuk and Alexandre
Bergel, , we were able to have a GSOC 2017 application for the Pharo
Consortium. This is only the first phase. If we are selected by
Google, they will give some slots for students.
We have a list of projects for GSOC here : http://gsoc.pharo.org/
If you have more ideas, please send them to me or send a PR on :
https://github.com/pharo-project/pharo-project-proposals/blob/master/Topics…
Try to describe your project idea with 10-15 lines maximum.
The ideas is not too much projects proposals but to find important
projects for the Pharo community (i.e that will have some impact for
the community) with the support of the appropriate mentors.
I would like to have maximum 2-3 projects for each mentors.
Thank you.
Cheers,
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
Hi,
I've made a small addition to Roassal, so now we can drop morphs onto Roassal canvas and then do something with it.
For example open a view:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
v := RTView new.
v @ (RTMorphDropInteraction new
if: [ :morph :event | morph isTransferable and: [ morph passenger isNotEmpty ] ]
do: [ :morph :event | |el|
el := (RTLabel new elementOn: morph passenger first).
el @ RTDraggable.
v add: el.
v signalUpdate.
]).
v open.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
And then drag Class or Method from Nautilus window and it should appear in the canvas.
The interaction can be added to any shape (not just view), and the first (in terms of elements placed on top of each other) shape/view that passes the #if: block will process it (just like a click event).
Is this useful in Roassal itself? Should I keep it for myself? (The implementation is a bit... hacky).
Peter
Hello,
In our Fame meta meta model, some information about the source and target selector for the associations were missing. It was hard to extend the model with new associations.
With the help of Anne, I added the pragma <source> representing the incoming link of the association and <target> representing the outgoing link of the association (see FAMIXAssociation >> #from , #to for usage).
In Fame, it is represented in FM3PropertyDescription by isTarget and isSource (false by default).
All the tests related to this change are now green in Jenkins and some additional tests should be added to cover this new functionality.
MooseQuery is now based on these features.
Cheers,
Vincent
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
Hi,
Recently, a new code was introduced in which RTLine>>initialize called withSelfLoop.
However, the method does not exist yet. I guess you forgot to commit it. In the meantime, I commented that line out.
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
As part of a larger project I'm trying to recreate some functionality
that can be seen here:
http://clics.lingpy.org/browse.php?gloss=carry+%28bear%29&view=community
At this point I can slurp the data out of a database and get a graph
with Mondrian. What I cannot figure out is how I might change the
styling on the edges to represent weights. All I have found so far
is RTEdgeBuilder>>#label:, which is better than nothing, but is sort
of a mess visually in complex graphs. Changing edge width would be
tidier.
I'm still working my brain around how Smalltalk does things, so my
apologies in advance if I'm missing something obvious.
--
wm
--
View this message in context: http://forum.world.st/Mondrian-edge-styling-tp4932317.html
Sent from the Moose mailing list archive at Nabble.com.
Hi!
It looks like that we are currently suffering memory leaks.
In march 2015 it was said in the mailing list:
-=-=-=-=-=-=-=-=
I also tried this:
1. Create a dummy class:
Object subclass: #AAA
instanceVariableNames: 'x'
classVariableNames: ''
category: 'AAA'.
2. Open a Playground and do it and go on this:
a := #AAA asClass new.
3. In the second pane go on "self"
4. Close the Playground
5. Execute:
3 timesRepeat: [ Smalltalk garbageCollect ].
6. Check:
#AAA asClass allInstances.
7. Repeat if necessary, and after a while, the result after step 6 is not empty.
-=-=-=-=-=-=-=-=
The problem is still present.
Looking at the pointers
There was an object reference crawler no? I remember someone worked on this? I tried sending #pointersTo but I without much success on identifying the cause of this leak.
Any idea?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
There are a few failing tests on Moose 6.0.
https://ci.inria.fr/moose/job/moose-6.0/2418/testReport/
I would like to know if these tests represent some important functionality
that might cause bugs in the image. Principally, the tests are related to
Spotter and GT-examples. I think we might be missing a #stable version to
load these packages correctly in Moose 6.0.
I am going to use Moose 6.0 for a training so I would like to avoid bugs
during my presentation.
regards.
Usman
