> Begin forwarded message:
>
> From: Sven Van Caekenberghe <sven(a)stfx.eu>
> Subject: [Pharo-users] [ ANN ] Pharo Days 2016
> Date: December 9, 2015 at 9:52:09 AM EST
> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>, Pharo Development List <pharo-dev(a)lists.pharo.org>, Pharo Business <pharo-business(a)lists.pharo.org>
> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
>
> Dear fellow Pharoers,
>
> Mark your calendars: on Thursday March 31 & Friday April 1 we are organising the Pharo Days 2016. This year we moved the location to Namur, Belgium, just a bit south of Brussels, at the very beautiful location of the ‘Cercle de Wallonie’ overlooking the river Meuse.
>
> We’ll update the following page moving forward.
>
> https://medium.com/concerning-pharo/pharo-days-2016-c52fe4d7caf
>
> You can ask questions on any of the Pharo mailing lists or you can email the Pharo Board.
>
> Let's make this another success, together ! We hope to see as many of you as possible.
>
>
--
www.tudorgirba.com
"We are all great at making mistakes."
Hello,
Is there a way to set a default selection to a list presentation? so that
when I open the browser, the morphic list has already a value selected.
I tried that:
|tmpBrowser|
tmpBrowser := GLMTabulator new.
tmpBrowser row: #list.
tmpBrowser transmit to: #list; andShow: [:a |
a list
display: [:input | input];
selection: #a;
yourself
].
tmpBrowser openOn: #( b c d v a d f r).
but the list still open with nothing selected
Hi,
Alex Syrel, Andrei Chis and I are happy to announce a new addition to the
Glamorous Toolkit:
GTSpotter, a novel interface for spotting objects.
GTSpotter has two goals:
- Provide a uniform yet moldable interface that can work on any object, and
- Handle searching through arbitrary levels of object nesting.
We think this will have a significant impact on the development workflow in
Pharo.
Here is a couple of screenshots:
[image: Inline image 2] [image: Inline image 1] [image: Inline image 3]
A trailer is available here:
https://www.youtube.com/watch?v=PhSmjR3NOlU
A detailed description is available here:
http://www.humane-assessment.com/blog/introducing-gtspotter
It works already in Pharo 3.0 and can be played with by following the
instructions from:
http://gt.moosetechnology.org
Please let us know what you think.
Enjoy,
The Glamorous Team
Hi,
With Cyril, we discovered that MooseEntity >> children behavior is not as expected. It collects all the items defined in the meta meta model: not only the children but the parents too...
childrenEntities should be used instead and consequently TMetaLevelDependency should be defined on MooseEntity.
Moreover, #children is also defined on the subclasses of FAMIXScopingEntity as a "Polymorphic accessor to children of this scope in a hierarchical structure (package->subpackages, scope->subscopes)".
Cyril and I suggest to deprecate these 3 methods (in FAMIXScopingEntity, FAMIXNamespace, FAMIXPackage) to "childrenOfMyKind", and to change in FAMIXPackage, isKindOf: in allWithSubTypeOf:.
Cyril will do the changes next week.
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.!!!"
Hello Moose !
With the current memory limit of Pharo,
and the size of the generated moose models being potentially huge,
maybe some of you already though about (or even experimented) persistence
solutions with query mechanisms that would instantiate famix objects only
“on demand”,
in order to only have part of a model in memory when working on a specific
area.
If so, I would be really interested to hear about (or play with) it :)
At first look, I see that there is a MooseGroupStorage class.
This kind of object answers to some usual collection messages (add, remove,
select, detect, .. ).
I guess that when we perform queries over a moose model,
when we add or remove entity objects,
we end up using this protocol.
So, if I wanted to implement a database persistence solution for moose,
my first feeling would be to implement a specific kind of
“MooseGroupStorage”,
and to plug there a communication layer with a database.
Does it make sense ?
I have not played with moose since a long time
(but I am back to play with it a lot more :))
and my vision on things may be naive.
So do not hesitate to tell me if what I am saying sounds crazy,
and to push me back on the right path !
Does anyone already thought about solutions to deal with memory limits when
generating big moose models ?
--
Cyrille Delaunay
Hi,
It is actually the economic reasoning that prevailed here.
John was willing to invest effort to both work with and benefit from the Moose/GT environment. The consequence was that he built the GT extensions for SmaCC while Andrei and I offered a bit of support. In this process, we also got updates and fixes to several grammars that are now shipped with Moose.
Furthermore, as John is the primary author of SmaCC it only makes sense that he gets to control what he maintains.
As for the repository, I asked him kindly to keep it in SmalltalkHub at the beginning to make the integration with Moose cheaper and easier. Now, that the GitHub solution grows we can certainly consider moving it together with the rest of Moose.
As for the need to have a fork of SmaCC, I think there is little need for that and John was always responsive to requests.
Cheers,
Doru
> On Mar 29, 2017, at 6:21 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
>
> So I browsed the mailing-list and I foind the mail of thierry saying that there is no difference.
> I will try to tools in moose then.
>
>
> On Wed, Mar 29, 2017 at 6:07 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
> Ok I should say that I do not understand the differences and why there are two versions of Smacc.
> So I will stop maintaining the tutorial because now may be I should revert what I wrote.
> I was too stupid to do it in fact I should focus on my stuff and nothing else.
> This saddens me a lot.
> We are a small community and we split ourselves into little chunks.
> I do not get why there is no notion of economy and sharing in our culture.
>
> Stef
>
>
>
> On Wed, Mar 29, 2017 at 2:30 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> Hi,
>
> > On Mar 28, 2017, at 11:50 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
> >
> > OK
> > I loaded Smacc from github as mentioned by thierry.
> >
> > Metacello new
> > baseline: 'SmaCC';
> > repository: 'github://ThierryGoubier/SmaCC';
> > load
> >
> > Are there two configurationOfSmacc?
> > May be we should only have one no?
> >
> > I have the impression that even thierry and jason working heavily with Smacc do not know that.
> > And we should not force them to use Moose. At least we do not have to win
> > anything with it.
>
> I did not mean to force anyone to use Moose. I just said it is already loaded there, in case you use it.
>
> Moose relies on the ConfigurationOfSmaCC maintained by John. Thierry has another repository that he created before John moved his work to Pharo. But, now that he does work with Pharo Moose relies on his version.
>
> Cheers,
> Doru
>
> >
> > Stef
> >
> > On Mon, Mar 27, 2017 at 6:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> > They come with the ConfigurationOfSmaCC which is already in the Moose image.
> >
> > Doru
> >
> >
> > > On Mar 27, 2017, at 4:52 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
> > >
> > > Hi
> > >
> > > where can I load the Smacc gt extension and debugger extensions?
> > >
> > > Stef
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Speaking louder won't make the point worthier."
> >
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "There are no old things, there are only old ways of looking at them."
>
>
>
>
>
>
>
--
www.tudorgirba.comwww.feenk.com
"We cannot reach the flow of things unless we let go."
Hi!
Just to share what we have recently done.
We have designed a very simple python analyzer, available as a Roassal plugin (available from the world menu).
As an example, the following code produces:
-=-=-=-=-=-=-=-=-=-=-=-=
root := '/Users/alexandrebergel/Desktop/astropy' asFileReference.
p := PyProcessor new.
p processRootFolder: root.
p resolveDependencies.
b := RTMondrian new.
b shape circle.
b shape box
height: #numberOfLinesOfCode;
width: [ :c | c numberOfMethods * 10 ].
b nodes: p classes.
b edges connectFrom: #superclass.
b layout tree;
ifNotConnectedThen: RTFlowLayout new.
b normalizer
distinctColorUsing: #file.
^ b
-=-=-=-=-=-=-=-=-=-=-=-=
Cheers,
Alexandre
In the latest build we have 243 new tests failing with an error (Instance
of FAMIXPharoAnchor did not understand #privateQuery:with:)
new versions in the image are:
'ACD-Model' : 'ACD-Model-PavelKrivanek.47',
Merlin' : 'Merlin-PavelKrivanek.159',
'RoelTyper' : 'RoelTyper-PavelKrivanek.88',
'Famix-Core' : 'Famix-Core-AnneEtien.312'
'Famix-Extensions' : 'Famix-Extensions-VincentBlondeau.302',
-- Pavel
Agile Vis ebook is superb, copied following snippet, know hopefully what
it's doing, but want to make sure I understand how it works (in terms of
"plain" Pharo):
1) @ RTPopup: Class name is enough, but it is initiated under the hood?
2) RTMetricNormalizer new ...: There is no need to keep reference to
created object? Why? because messages sent to object (like normalizeSize)
have a "sideeffect" on es?
3) RTMetricNormalizer connects to model via #yourself? Is every symbol or
code block. that is sent to RTMetricNormalizer as argument, executed when
finally "sent" to es?
BR Mike
v := RTView new. es := (RTEllipse new color: Color blue) elementsOn: #(4 5 1
2 3 5). v addAll: es. es @ RTPopup. RTMetricNormalizer new elements: es;
alphaColor; normalizeSize: #yourself min: 20 max: 50; normalizeColor:
#yourself. RTHorizontalLineLayout new alignCenter; on: es. es @ RTLabeled. v
