Fwd: [Pharo-users] [ ANN ] Pharo Days 2016
by Tudor Girba
> 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."
1 week, 6 days
[Glamour] default selection in ListPresentation
by Cyrille Delaunay
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
5 years, 6 months
A quick analyzis of the usage of instance variables in Moose
by Guillaume Larcheveque
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*
6 years, 6 months
Design Challenge: metrics missing value...
by stepharong
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
6 years, 8 months
Using Moose outside of source assessment context?
by Udo Schneider
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
6 years, 8 months
MooseAbstractGroup>>allModelMethods // isStub
by Nicolas Anquetil
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
6 years, 9 months
removing the mooseName caching mechanism
by Tudor Girba
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.com
www.feenk.com
"What we can governs what we wish."
6 years, 9 months
About parentPackage
by Blondeau Vincent
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.!!!"
6 years, 9 months
Famix entities packaging
by Blondeau Vincent
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.!!!"
6 years, 9 months
