> 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 Moose users,
as you may know, at Synectique we experiment lots of issues about memory
usage.
That's why i had a look at the number of unused instance variables in one
of our system loaded with a big model from one of our main customer.
Total instance variables: 26.852.653
Used instance variables: 17.393.938
Empty collections: 5.023.508
Recoverable instance variables: 14.482.223
The recoverable instance variables are those with nil or an empty
collection (or MultiValueLink)
As you can see, we can save a lot of memory :-)
Here is my (dirty) code to get that:
countUsedInstanceVariableInForSubInstances: aClass
| usedInstNbr instNbr emptyCollNbr |
usedInstNbr := 0.
instNbr := 0.
emptyCollNbr := 0.
aClass
allSubInstancesDo: [ :anEntity |
instNbr := instNbr + anEntity class allInstVarNames size.
anEntity class allInstVarNames
doWithIndex: [ :e :i |
(anEntity instVarAt: i)
ifNotNil: [ :content |
([
content isEmpty.
emptyCollNbr := emptyCollNbr + 1.
false ]
on: MessageNotUnderstood
do: [ false ])
ifFalse: [ usedInstNbr := usedInstNbr + 1 ] ] ] ].
^ {('Used instance variables' -> usedInstNbr).
('empty collections' -> emptyCollNbr).
('Recoverable instance variables' -> (instNbr - (usedInstNbr -
emptyCollNbr))).
('Total instance variables' -> instNbr)}
--
*Guillaume Larcheveque*
Hi dear great OO designers
Here is a little challenges for your brainy souls :)
In Moose when we compute metrics it may happen than a tool (often external
to pharo) does not compute a metrics
and when we request it in moose we check and often we return a not so good
-1.
I'm trying to brainstorm on a solution
- first may be the simplest way is to not invoke a metrics when it is not
computed. But it means that we should know it and that we should have a
registration mechanism. After all this is probably the best solution.
- Second we were thinking to use exception but when we have multiple
entities missing one metrics.... I have serious doubts.
- Second I was thinking about having the following behavior
testCollect
| uarray collected |
uarray := UniformOrderedCollection new.
uarray add: 10.
uarray add: 20.
uarray add: (MissingValue discarding).
collected := uarray collect: [ :each | each ].
self assert: collected size equals: 2.
testDo
| res uarray |
uarray := UniformOrderedCollection new.
uarray add: 10.
uarray add: 20.
uarray add: (MissingValue discarding).
uarray add: 40.
res := 0.
uarray do: [ :each | res := res + each ].
self assert: res equals: 70.
testCollectDefaulting
| uarray collected |
uarray := UniformOrderedCollection new.
uarray add: 10.
uarray add: 20.
uarray add: (MissingValue default: 33).
collected := uarray collect: [ :each | each ].
self assert: collected size equals: 3.
self assert: collected third equals: 33
I basically started to implement
do: aBlock
"Refer to the comment in Collection|do:."
1 to: self size do:
[:index | (self at: index) toDo: aBlock on: self]
collect: aBlock
"Evaluate aBlock with each of the receiver's elements as the argument.
Collect the resulting values into a collection like the receiver. Answer
the new collection."
| newCollection |
newCollection := self species new.
self
do: [ :each | each toCollect: aBlock on: newCollection ].
^ newCollection
and
DiscardingValue >> toCollect: aBlock on: aCollection
"discard computation"
^ self
Object >> toCollect: aBlock on: aCollection
^ aCollection add: (aBlock value: self)
So I imagine that you see the design and I wanted to get your point of
view.
--
Using Opera a kind of bad mail client but far better than thunderbird
All,
I’m dabbling with the idea of using Moose in a totally different questions. However I do have some questions about using it in my context. Would this ML be the right place to ask those questions?
CU,
Udo
any reason why:
MooseAbstractGroup>>allModelMethods
... self allMethods reject: [ :each | each parentTypeIsStub ]
why not:
... self allMethods reject: [ :each | each isStub ]
1- if a method is a stub, by definition we may not know what its class is
2- even if we know, if the parent class is a stub, then the method
itself should be a stub
so why this indirection?
nicolas
--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod
Hi,
A while ago we put in place a caching mechanism for mooseName. While this has an impact on performance, it makes it a pain to play with the model in any sort of dynamic fashion. It also makes debugging very difficult especially during the development of new importers.
Furthermore, it also has issues with assumptions about creating global caches at the model level which are not correct: FAMIXNamedEntities are not uniquely named in the whole model, they are uniquely named within their own type, and for that we already have a cache in the groups. For example, "model allClasses” will give us a group that will also have a cache by the mooseName of classes.
This is a heads up that I want to remove this feature. Of course, we can still discuss about it.
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"What we can governs what we wish."
Hello,
Still in the context of Moose re-architecting, we detected that parentSelector is defined at FAMIXNamedEntity level but is only used for Smalltalk model at FamixMethod and FamixClass.
As parentSelector is a container, it should not be defined at a too high level.
We suggest to move down this property to this both subclasses. Has someone something against it?
Thanks in advance,
Cheers,
Anne & Vincent
Vincent BLONDEAU
RMOD Team
Bât B - Bureau 306
Centre de recherche
Lille-Nord Europe
+33 (0)3 59 35 87 45
vincent.blondeau(a)inria.fr<mailto:vincent.blondeau@inria.fr>
[cid:image001.jpg@01D25B93.9BD2F6A0]
Software Architects
SDCO
ZI A, rue de la Pointe
59113 SECLIN
+33.(0)3.28.54.41.54
vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@worldline.com>
[cid:image003.gif@01D25B93.9BD2F6A0]
!!!*************************************************************************************
"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,
In the context of Moose re-architecting, FAMIXCore package should contain only FAMIXCore classes, i.e., only classes common to all languages.
We detected some misplaced classes:
- FAMIXTypeAlias should belong to the C package like FAMIXModule which is already in.
- FAMIXAnnotation*should belong to the Java package.
Do you think that these classes have to stay in the core package? Or can we move them?
BTW, we also added an opposite to the FAMIXException>> exceptionClass in FAMIXClass.
Cheers,
Anne & 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.!!!"
