[Pharo-dev] [Reflectivity] What are the #arguments?

2015-09-25 Thread roberto.mine...@usi.ch
Dear Marcus,

I am wondering where to ‘discover’ all the possible values for the #arguments: 
to pass to the MetaLink.

Cheers,
R



Re: [Pharo-dev] [Reflectivity] What are the #arguments?

2015-09-25 Thread roberto.mine...@usi.ch
Thank you very much, Marcus!

Concerning the table..we can do a method that lists the #availableReifications 
or something like that ;)

For example, if I am interested in all the available reifications for an 
RBMethodNode I can do:
RFReification subclasses select: [ :e | e nodes includesAny: RBMethodNode 
withAllSuperclasses ].

Cheers,
Roby


> On 25 Sep 2015, at 09:51, Marcus Denker <marcus.den...@inria.fr> wrote:
> 
> Hello,
> 
> every one of these “reifications” are defined as a subclass of
> RFReification
> 
> There is one subclass for every symbol (e.g. for #arguments, there is 
> RFArgumentsReification).
> The class side method #key defines the exact symbol, while #nodes returns the 
> AST node classes
> where this reification is available.
> 
> I will make a full table soon that lists everything.
> 
>   Marcus
> 
>> On 25 Sep 2015, at 09:36, roberto.mine...@usi.ch wrote:
>> 
>> Dear Marcus,
>> 
>> I am wondering where to ‘discover’ all the possible values for the 
>> #arguments: to pass to the MetaLink.
>> 
>> Cheers,
>> R
>> 
> 



Re: [Pharo-dev] [Reflectivity] Slides ESUG talk

2015-09-24 Thread roberto.mine...@usi.ch
Lovely Marcus, thank you.

> On 24 Sep 2015, at 09:59, Marcus Denker <marcus.den...@inria.fr> wrote:
> 
>> 
>> On 22 Sep 2015, at 17:23, roberto.mine...@usi.ch wrote:
>> 
>> Hi Marcus,
>> 
>> I am finally playing with Reflectivity. In the first place, thanks a lot for 
>> this contribution!
>> 
>> I am wondering what is the ‘correct’ way to ‘remove’ a MetaLink. Is it 
>> enough to call #uninstall on the MetaLink or should I also recompile the 
>> class/method where the link is installed?
>> 
>> I spotted a problem with the control #after. If you try to pass #arguments 
>> to the meta, an error is returned. To reproduce: 
>> http://ws.stfx.eu/ONC4K9KQRTNQ
>> 
>> Is this behavior somewhat desired, or is a bug?
>> 
> Hello, I fixed it:
> 
>   
> https://pharo.fogbugz.com/f/cases/16629/fix-after-on-method-with-arguments
> 
> You example is now working, I added it as this test:
> 
> testReifyMethodArgsAfter
>   | methodNode link instance|
>   methodNode := (ReflectivityExamples>>#exampleWithArg:) ast.
>   link := MetaLink new 
>   metaObject: self; 
>   selector: #tagExec:;
>   control: #after;
>   arguments: #(arguments).
>   methodNode link: link.
>   self assert: methodNode hasMetalink.
>   self assert: (ReflectivityExamples>>#exampleWithArg:) class = 
> ReflectiveMethod.
>   self assert: (tag isNil).
>   instance := ReflectivityExamples new .
>   self assert: ((instance exampleWithArg: 3) = 5).
>   self assert: (tag = #(3)).
>   link uninstall. 
> 
> 
> I will integrate this fix and then write more tests (e.g. I think there are 
> still problems with an #after on a method that defines temps,
> but it will be easy to fix).
> 
>   Marcus



Re: [Pharo-dev] [Reflectivity] Slides ESUG talk

2015-09-22 Thread roberto.mine...@usi.ch
Hi Marcus,

I am finally playing with Reflectivity. In the first place, thanks a lot for 
this contribution!

I am wondering what is the ‘correct’ way to ‘remove’ a MetaLink. Is it enough 
to call #uninstall on the MetaLink or should I also recompile the class/method 
where the link is installed?

I spotted a problem with the control #after. If you try to pass #arguments to 
the meta, an error is returned. To reproduce: http://ws.stfx.eu/ONC4K9KQRTNQ

Is this behavior somewhat desired, or is a bug?

Dictionary>>errorKeyNotFound:
[ self errorKeyNotFound: key ] in Dictionary>>at: in Block: [ self 
errorKeyNotFound: key ]
Dictionary>>at:ifAbsent:
Dictionary>>at:
IRPushClosureCopy>>indexForVarNamed:
IRTranslatorV2>>visitPushTemp:
IRPushTemp>>accept:
IRTranslatorV2(IRVisitor)>>visitNode:
IRTranslatorV2>>visitInstruction:
[ :instr | self visitInstruction: instr ] in 
IRTranslatorV2(IRVisitor)>>visitSequence: in Block: [ :instr | self 
visitInstruction: instr ]
OrderedCollection>>do:
IRSequence>>do:
IRTranslatorV2(IRVisitor)>>visitSequence:
IRTranslatorV2>>visitSequence:
IRSequence>>accept:
IRTranslatorV2(IRVisitor)>>visitNode:
[ :each | self visitNode: each ] in IRTranslatorV2(IRVisitor)>>visitNodes: in 
Block: [ :each | self visitNode: each ]
SortedCollection(OrderedCollection)>>do:
IRTranslatorV2(IRVisitor)>>visitNodes:
IRTranslatorV2>>visitSequences:
IRTranslatorV2>>visitMethod:
IRMethod>>accept:
IRTranslatorV2(IRVisitor)>>visitNode:
IRMethod>>generate:
IRMethod>>compiledMethodWith:
RBMethodNode>>generate:
ReflectiveMethod>>recompileAST
ReflectiveMethod>>compileAndInstallCompiledMethod
ReflectiveMethod>>run:with:in:
UndefinedObject>>DoIt

Cheers,
Roberto

> On 04 Sep 2015, at 14:16, Marcus Denker <marcus.den...@inria.fr> wrote:
> 
> Hi Roberto,
> 
> Very good! I am now working on #after for methods+sequence. *And* 
> primitives... this should all be committed early next week.
> 
> After that, I need to actually use it to find remaining problems, so this is 
> very good that you will start now.
> 
>Marcus
> 
> On Thu, Sep 3, 2015 at 2:50 PM, roberto.mine...@usi.ch 
> <roberto.mine...@usi.ch> wrote:
> Very good talk Marcus.
> 
> In the next weeks I will finally have some time to try Reflectivity out!
> 
> Thanks a lot for all your effort!
> 
> Cheers,
> Roberto
> 
> > On 31 Jul 2015, at 13:23, Marcus Denker <marcus.den...@inria.fr> wrote:
> >
> >
> >> On 15 Jul 2015, at 10:15, Marcus Denker <marcus.den...@inria.fr> wrote:
> >>
> >> Hi,
> >>
> >> the slides for my ESUG talk are online:
> >>
> >>  http://www.slideshare.net/MarcusDenker/reflection-in-pharo5
> >>
> >>
> >
> > Video is online, too:
> >
> >   https://www.youtube.com/watch?v=Ik539CtjtTI
> >
> >
> >
> >   Marcus
> >
> 
> 
> 
> 
> -- 
> --
> Marcus Denker  --  den...@acm.org
> http://www.marcusdenker.de



[Pharo-dev] Pharo 5 and method extensions

2015-09-18 Thread roberto.mine...@usi.ch
Dear all,

I just moved to Pharo 5 for development and discovered that it does not 
correctly show method extensions.

I opened a case
https://pharo.fogbugz.com/f/cases/16601/Pharo-5-does-not-show-method-extensions

Cheers,
R




Re: [Pharo-dev] Configuration Madness

2015-09-18 Thread roberto.mine...@usi.ch
Thanks a lot Dale, this works indeed.

P.s. Sorry for the delay in the answer but my mailbox went crazy!

R


> On 16 Sep 2015, at 17:43, Dale Henrichs <dale.henri...@gemtalksystems.com> 
> wrote:
> 
> 
> 
> On 9/16/15 8:07 AM, Max Leske wrote:
>>> On 16 Sep 2015, at 16:39, roberto.mine...@usi.ch wrote:
>>> 
>>> Dear all,
>>> 
>>> I have a question about the ConfigurationOf my project, and I really hope 
>>> you can help.
>>> 
>>> In my project I have a package called ‘DevFlow-Extensions’ that is a 
>>> “placeholder” for code that is dependent on the Pharo version.
>>> 
>>> On the ConfigurationOf, according to the Pharo version I do something like
>>> 
>>> spec for: #'pharo3.x'
>>> do: [
>>> 
>>> spec blessing: #baseline.
>>> spec repository: 
>>> 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'.
>>> 
>>> spec package: 'DevFlow-Extensions' with: 
>>> 'DevFlow-Extensions30'.
>>> ].
>>> 
>>> spec for: #'pharo4.x'
>>> do: [
>>> 
>>> spec blessing: #baseline.
>>> spec repository: 
>>> 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'.
>>> 
>>> spec package: 'DevFlow-Extensions' with: 
>>> 'DevFlow-Extensions40'.
>>> ].
>>> 
>>> In this way, in Pharo 3.0 I’d load DevFlow-Extensions30 and in Pharo 4.0 
>>> I’d load DevFlow-Extensions40. Super cool.
>>> I am using a single package (‘DevFlow-Extensions’) to specify of groups, 
>>> for example:
>>> 
>>> spec group: 'User' with: #(
>>> 'DevFlow-Meta'
>>> ...
>>> 'DevFlow-Announcement'
>>> 'DevFlow-Extensions').
>>> 
>>> Now the problem is that for Pharo 5 I have to load both 
>>> 'DevFlow-Extensions40’ and 'DevFlow-Extensions50’.
>>> I read the chapter on Metacello, but didn’t find a solution. I tried some 
>>> combinations of #includes: and #requires: but with no luck.
>>> 
>>> Any help is appreciated, thank you very much!
>>> 
>>> Roberto
>> Shouldn’t this work?
>> 
>> spec package: 'DevFlow-Extensions' with: #('DevFlow-Extensions40’ 
>> ‘DevFlow-Extensions50).
>> 
>> 
>> 
> Good idea, but it's not quite correct, I think this will work:
> 
> spec for: #'pharo5.x'
>  do: [
>spec package: 'DevFlow-Extensions40' .
>spec package: 'DevFlow-Extensions50' .
>spec group: 'DevFlow-Extensions' with: #('DevFlow-Extensions40’ 
> ‘DevFlow-Extensions50) ].
> 
> 
> Dale
> 



[Pharo-dev] Configuration Madness

2015-09-16 Thread roberto.mine...@usi.ch
Dear all,

I have a question about the ConfigurationOf my project, and I really hope you 
can help.

In my project I have a package called ‘DevFlow-Extensions’ that is a 
“placeholder” for code that is dependent on the Pharo version.

On the ConfigurationOf, according to the Pharo version I do something like

spec for: #'pharo3.x'
do: [ 

spec blessing: #baseline.
spec repository: 
'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'.

spec package: 'DevFlow-Extensions' with: 
'DevFlow-Extensions30'.
].

spec for: #'pharo4.x'
do: [ 

spec blessing: #baseline.
spec repository: 
'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'.

spec package: 'DevFlow-Extensions' with: 
'DevFlow-Extensions40'.
].

In this way, in Pharo 3.0 I’d load DevFlow-Extensions30 and in Pharo 4.0 I’d 
load DevFlow-Extensions40. Super cool.
I am using a single package (‘DevFlow-Extensions’) to specify of groups, for 
example:

spec group: 'User' with: #(
'DevFlow-Meta' 
...
'DevFlow-Announcement'
'DevFlow-Extensions'). 

Now the problem is that for Pharo 5 I have to load both 'DevFlow-Extensions40’ 
and 'DevFlow-Extensions50’. 
I read the chapter on Metacello, but didn’t find a solution. I tried some 
combinations of #includes: and #requires: but with no luck.

Any help is appreciated, thank you very much!

Roberto

Re: [Pharo-dev] [Reflectivity] Slides ESUG talk

2015-09-03 Thread roberto.mine...@usi.ch
Very good talk Marcus. 

In the next weeks I will finally have some time to try Reflectivity out!

Thanks a lot for all your effort!

Cheers,
Roberto

> On 31 Jul 2015, at 13:23, Marcus Denker  wrote:
> 
> 
>> On 15 Jul 2015, at 10:15, Marcus Denker  wrote:
>> 
>> Hi,
>> 
>> the slides for my ESUG talk are online:
>> 
>>  http://www.slideshare.net/MarcusDenker/reflection-in-pharo5
>> 
>> 
> 
> Video is online, too:
> 
>   https://www.youtube.com/watch?v=Ik539CtjtTI
> 
> 
> 
>   Marcus
> 




Re: [Pharo-dev] About compileSilently

2015-07-29 Thread roberto.mine...@usi.ch
Yeah, I also removed #prepareDebuggerExample from my image...

It is the third time in the last two weeks that this happens to me and I have 
to spend lot of time to recover the changes from one image to the other.

Cheers,
R

 On 29 Jul 2015, at 11:16, Marcus Denker marcus.den...@inria.fr wrote:
 
 Not known, but the whole #prepareDebuggerExample method is very strange. We 
 should remove it.
 
 On 29 Jul 2015, at 16:05, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I don’t know if this is related, but recently happens something super 
 strange to my images.
 
 From time to time, in one of my commits the author is suddenly changed to 
 ‘AutoGenTutorial’ and, if I don’t spot this, from now on the Pharo image 
 stops recording my changes.
 
 This is very frustrating.. is this a known issue?
 
 Thanks a lot,
 RM
 
 
 On 30 May 2015, at 06:01, Nicolai Hess nicolaih...@web.de wrote:
 
 
 
 2015-05-28 21:14 GMT+02:00 Thierry Goubier thierry.goub...@gmail.com:
 Le 28/05/2015 20:40, Nicolai Hess a écrit :
 
 
 2015-05-28 16:55 GMT+02:00 Thierry Goubier thierry.goub...@gmail.com
 mailto:thierry.goub...@gmail.com:
 
 
 
   2015-05-28 16:49 GMT+02:00 Nicolai Hess nicolaih...@web.de
   mailto:nicolaih...@web.de:
 
   How silent should compileSilently be?
 
   no trace in the system :
   15314 https://pharo.fogbugz.com/default.asp?15314
   compileSilently and method history / changes file
 
   not half silenlty
   13023 https://pharo.fogbugz.com/default.asp?13023
   Test Cases should not do things half silently
 
   not SystemAnnouncer-silent
   10560 https://pharo.fogbugz.com/default.asp?10560
   SystemAnnouncer and compileSilently
 
 
   ?
 
   What do you think, what granularity of silent do we need.
   I see at least three different use cases:
 
   - just an ordinary compile
 
 
   ? Silent means that: Core infrastructure is not updated properly
   (i.e. RPackage) and tools (Browsers) can end desynchronised with the
   methods.
 
   - compile for tests
 
 
   Probably the one... But I wonder if this is a good idea anyway. I'd
   believe most tests using silently are using it wrongly and shouldn't
   be using it in the first place.
 
   - compile autogenerated methods.
 
 
   This one may not be silent. If the auto-generated method will be
   visible (saved in a package, can be browsed, etc...) then it
   shouldn't be silent.
 
 
 
 What about compiled method for which the source did not change?
 
 Hum. I see what you mean.
 
 I do silent compilation when I install tracing probes inside methods, to 
 make sure they don't appear as changed in browsers... But I don't create 
 new methods. I guess this will be the same with the MetaLinks Marcus is 
 preparing.
 
 But, yes, as I said: methods or changes that are not visible then you can 
 make them silent.
 
 But in a different case, such as compiling a SmaCC parser, you want that 
 code to be visible.
 
 
 For NativeBoost generated methods, I may want to have that code visible too.
 I just don't want the code to be marked as changed after a recompilation.
 
 For example, a subclass of NativeBoosts NBExternalStructure or 
 NBExternalArray must be recompiled when used in a new session, or when the 
 structure
 changed.
 
 The compiler installs the generated accessor methods and you may want to 
 see that code - just to make sure the structure change was applied.
 But you really don't want this code in a changeset, because whenever you 
 use this code in another image or in a new session it
 will be recompiled  anyway.
 
 
 
 I am interested on this for issue 15315, everytime you open spotter,
 you'll get a new
 
 method: PharoSyntaxTutorial divideTwoByZero; AutoGenTutorial 5/28/2015
 20:34
 
 in you changes file.
 
 This one makes for some annoying noise in the changes. But as I say below, 
 maybe it doesn't matter.
 
 Another case are autogenerated methods from NativeBoost.
 For example, open a fresh image and execute code that triggers
 NativeBoost to install native functions for this session.
 (EllipseMorph new openInSceneView)
 
 And now look at your list of recent changes.
 I get about 30 entries for athens/cairo methods.
 
 One of the thing to consider is what you use the changes for. If it is to 
 recover from crashes, then what you just need to make sure is that 
 replaying all since the last save is ok... even if you have multiple times 
 the same method source saved in it.
 
 Yes, you are right. It does not hurt to have this in the changes file. (But 
 it does not have any use to be there).
 
 
 True changes management is happening in the packages these days, and most 
 code written in the changes shouldn't be recorded there imho (oh, well, 
 apart for the source pointer, of course).
 
 And other uses it could have (recording all do its, for example) is 
 reimplemented / duplicated elsewhere in the system anyway.
 
 Thierry
 
 
 



Re: [Pharo-dev] About compileSilently

2015-07-29 Thread roberto.mine...@usi.ch
Hi,

I don’t know if this is related, but recently happens something super strange 
to my images.

From time to time, in one of my commits the author is suddenly changed to 
‘AutoGenTutorial’ and, if I don’t spot this, from now on the Pharo image stops 
recording my changes.

This is very frustrating.. is this a known issue?

Thanks a lot,
RM


 On 30 May 2015, at 06:01, Nicolai Hess nicolaih...@web.de wrote:
 
 
 
 2015-05-28 21:14 GMT+02:00 Thierry Goubier thierry.goub...@gmail.com:
 Le 28/05/2015 20:40, Nicolai Hess a écrit :
 
 
 2015-05-28 16:55 GMT+02:00 Thierry Goubier thierry.goub...@gmail.com
 mailto:thierry.goub...@gmail.com:
 
 
 
 2015-05-28 16:49 GMT+02:00 Nicolai Hess nicolaih...@web.de
 mailto:nicolaih...@web.de:
 
 How silent should compileSilently be?
 
 no trace in the system :
 15314 https://pharo.fogbugz.com/default.asp?15314
 compileSilently and method history / changes file
 
 not half silenlty
 13023 https://pharo.fogbugz.com/default.asp?13023
 Test Cases should not do things half silently
 
 not SystemAnnouncer-silent
 10560 https://pharo.fogbugz.com/default.asp?10560
 SystemAnnouncer and compileSilently
 
 
 ?
 
 What do you think, what granularity of silent do we need.
 I see at least three different use cases:
 
 - just an ordinary compile
 
 
 ? Silent means that: Core infrastructure is not updated properly
 (i.e. RPackage) and tools (Browsers) can end desynchronised with the
 methods.
 
 - compile for tests
 
 
 Probably the one... But I wonder if this is a good idea anyway. I'd
 believe most tests using silently are using it wrongly and shouldn't
 be using it in the first place.
 
 - compile autogenerated methods.
 
 
 This one may not be silent. If the auto-generated method will be
 visible (saved in a package, can be browsed, etc...) then it
 shouldn't be silent.
 
 
 
 What about compiled method for which the source did not change?
 
 Hum. I see what you mean.
 
 I do silent compilation when I install tracing probes inside methods, to make 
 sure they don't appear as changed in browsers... But I don't create new 
 methods. I guess this will be the same with the MetaLinks Marcus is preparing.
 
 But, yes, as I said: methods or changes that are not visible then you can 
 make them silent.
 
 But in a different case, such as compiling a SmaCC parser, you want that code 
 to be visible.
 
 
 For NativeBoost generated methods, I may want to have that code visible too.
 I just don't want the code to be marked as changed after a recompilation.
 
 For example, a subclass of NativeBoosts NBExternalStructure or 
 NBExternalArray must be recompiled when used in a new session, or when the 
 structure
 changed.
 
 The compiler installs the generated accessor methods and you may want to see 
 that code - just to make sure the structure change was applied.
 But you really don't want this code in a changeset, because whenever you use 
 this code in another image or in a new session it
 will be recompiled  anyway.
 
  
 
 I am interested on this for issue 15315, everytime you open spotter,
 you'll get a new
 
 method: PharoSyntaxTutorial divideTwoByZero; AutoGenTutorial 5/28/2015
 20:34
 
 in you changes file.
 
 This one makes for some annoying noise in the changes. But as I say below, 
 maybe it doesn't matter.
 
 Another case are autogenerated methods from NativeBoost.
 For example, open a fresh image and execute code that triggers
 NativeBoost to install native functions for this session.
 (EllipseMorph new openInSceneView)
 
 And now look at your list of recent changes.
 I get about 30 entries for athens/cairo methods.
 
 One of the thing to consider is what you use the changes for. If it is to 
 recover from crashes, then what you just need to make sure is that replaying 
 all since the last save is ok... even if you have multiple times the same 
 method source saved in it.
 
 Yes, you are right. It does not hurt to have this in the changes file. (But 
 it does not have any use to be there).
  
 
 True changes management is happening in the packages these days, and most 
 code written in the changes shouldn't be recorded there imho (oh, well, apart 
 for the source pointer, of course).
 
 And other uses it could have (recording all do its, for example) is 
 reimplemented / duplicated elsewhere in the system anyway.
 
 Thierry



[Pharo-dev] [Reflectivity] HowTo

2015-06-03 Thread roberto.mine...@usi.ch
Dear Marcus,

I am following your progresses on Reflectivity and I’d like to start with a 
big: THANK YOU!

Having said that, I am wondering whether this is a good point in which I can 
try (as an alpha tester :) to use it.

What I need to achieve is something similar to a method wrapper, i.e., some 
code that gets executed before or after a particular method call.

Is something doable at this point? Could you _please_ provide me pointers where 
to look to understand the Reflectivity framework?

Cheers and thanks in advance,
Roberto

Re: [Pharo-dev] [Reflectivity] Progress for Breakpoints

2015-05-26 Thread roberto.mine...@usi.ch
Thanks a lot Marcus. Your work is really appreciated!

 On 26 May 2015, at 08:46, Marcus Denker marcus.den...@inria.fr wrote:
 Yes, I am aware that these mails are not understandable… I think they are 
 more a trick 
 for myself to do something tiny every day that moves the project forward.
 
 And it works: soon it will be in a state that it can be used for lots of 
 interesting things.
 
 Demos I want to do
   - statement level code coverage using MetaLinks
   - Implementing a CLOS style MOP for ivar/global/message send
   - Implement MethodWrappers using meta links 

Can’t wait for this one! (  - Implement MethodWrappers using meta links ) 
and many other applications. Keep us up to date!


   - Plugin for nautilus to warn when looking at a method that is 
 currently executed
   (some red button that get red on call and slowly fades)
   - Implement the test coverage in the test runner using meta links on 
 methods
   - Extend Breakpoints to general “watch” points.
   - Logging: provide a framework so that we can easily add logging 
 reflectively
 
 Marcus



Re: [Pharo-dev] Collecting user data

2015-04-29 Thread roberto.mine...@usi.ch
+1 I couldn’t agree more with Andrei. 

I believe that we should have a common infrastructure, at least, to define 
which level of details tools are
allowed to collect/send for research purposes. I envision a setting’s panel in 
which the user has a list of
tools collecting data with their own settings and the user can freely select 
which tools are allowed to 
collect her data.

I had another idea, a “research image”. Let me explain, people are struggling 
to install tools that are not 
part of the standard image. On the other hand, having your research tool part 
of the standard image, is not 
easy for a number of reasons. So what about having a  “research image” that 
allows researcher to install and
distribute their own tools? Brave developers, for their free time project, 
could use this image instead of the
standard distribution, benefit from the innovative (but in early stage) tools 
and contribute to the data
collection mechanisms?

Cheers,
Roberto


 On 28 Apr 2015, at 14:35, Tommaso Dal Sasso tommaso.dalsa...@gmail.com 
 wrote:
 
 +1 for me.
 
 Having a centralized way of managing data submission would simplify
 things a lot for people collecting data, but also for users who could
 check in one place all the kind of data they send.
 
 Tommaso
 
 On 28/04/15 14:31, Andrei Chis wrote:
 Yes, some level of unification would be nice, especially for the part
 about users agreeing to send usage data and persisting that setting.
 Also at least two general levels of details about what data is being
 send that tools should follow would help (full anonymous vs. include
 class names/method names ?).
 Last but not least, a single entry point for sending that data over the
 network would help.
 
 How data is collected/stored will differ from tool to tool, but agreeing
 on the previous aspects would make it much easier to collect data.
 
 Cheers,
 Andrei
 
 On Tue, Apr 28, 2015 at 1:18 PM, Marcus Denker marcus.den...@inria.fr
 mailto:marcus.den...@inria.fr wrote:
 
 
 On 28 Apr 2015, at 11:42, Yuriy Tymchuk yuriy.tymc...@me.com
mailto:yuriy.tymc...@me.com wrote:
 
 Hi guys,
 
 from time to time we have to collect a usage data in order to
improve our tools. For example I’d like to collect data in future
about how do you treat code critics: do they occur, do you outfox
them, do you mark them as false positives? If we had answers to
these questions, we could really make good and helpful critics.
 
 For now I know that there are 3 projects which collect data:
 - GTSpotter
 - Shoreline
 - DFlow (not in image by default).
 
 Should I make 4th data collection for QualityAssistant? Or maybe
we can do some unification?
 
 
I would love unification!
 
It’s not only good for the researchers, but even for the user: I do
not want to decide 5 times to give data to research,
but I want to decide it once…
 
Marcus



[Pharo-dev] ZnClient send big data + progress

2014-06-06 Thread roberto.mine...@usi.ch
Hi guys,

I have a problem with Zinc, I need to send a huge amount of data (bytes) that 
translates to ~50Mb.

When I do something like:

ZnEasy 
post: 'http://localhost:15432' 
data: (ZnEntity bytes: aHugeByteArray.]

I encounter a ‘ConnectionTimedOut: Data send timed out.’, I attach the stack 
trace:

ZdcSocketStream(ZdcSimpleSocketStream)flushBytes:startingAt:count:
ZdcSocketStreamnext:putAll:startingAt:
ZnBivalentWriteStreamnext:putAll:startingAt:
ZnUtils classnextPutAll:on:
ZnByteArrayEntitywriteOn:
ZnEntityWriterwriteEntity:
ZnRequest(ZnMessage)writeOn:
ZnRequestwriteOn:
ZnClientexecuteRequestResponse
ZnClientgetConnectionAndExecute in Block: [ self executeRequestResponse ]
BlockClosureensure:
ZnClientgetConnectionAndExecute
ZnClientexecuteWithRedirectsRemaining:
ZnClientexecuteWithRetriesRemaining: in Block: [ self 
executeWithRedirectsRemaining: self maxNumb...etc...
BlockClosureon:do:
ZnClientexecuteWithRetriesRemaining:
ZnClientexecuteWithTimeout in Block: [ self executeWithRetriesRemaining: self 
numberOfR...etc...
BlockClosureon:do:
ZnClientexecuteWithTimeout in Block: [ ...
ZnClientwithTimeoutDo: in Block: [ ^ block value ]
ZnConnectionTimeout(DynamicVariable)value:during: in Block: [ ...
BlockClosureensure:
ZnConnectionTimeout(DynamicVariable)value:during:
ZnConnectionTimeout class(DynamicVariable class)value:during:
ZnClientwithTimeoutDo:
ZnClientexecuteWithTimeout
ZnClientexecute in Block: [ result := self executeWithTimeout ]
ZnClientwithProgressDo: in Block: [ ^ block value ]
ZnSignalProgress(DynamicVariable)value:during: in Block: [ ...
BlockClosureensure:

I tried to:
- Augment the client timeout to a huge value (10 mins) but it has no effect: 
The data send still goes into timeout, after 10-15 sec
- I replaced the ZnEntity with a ZnMultiPartFormDataEntity, still no luck

I am wondering what else can I do.

Moreover, I discovered there is a #signalProgress: message to signal process. 
The following examples do not work, any hint?


Example 1, from the book @ http://zn.stfx.eu/zn/zinc-http-components-paper.html:

UIManager default informUserDuring: [ :bar |
  [ ^ ZnClient new
signalProgress: true;
get: 'http://zn.stfx.eu/echo?delay=2' ]
on: HTTPProgress 
do: [ :progress | bar value: progress printString. progress resume ] ]


Example 2, from ZnClientTests#testProgress works, but not when issuing a POST 
request
[ :bar |
bar title: 'Downloading Sources...'.
[
ZnClient new 
url: 
'http://files.pharo.org/sources/PharoV30.sources'; 
signalProgress: true;   
downloadTo: FileLocator temp ]
on: HTTPProgress 
do: [ :progress |
progress isEmpty ifFalse: [ bar current: 
progress percentage ]. 
progress resume ] ] asJob run.
…works but only when using #downloadTo: if you do a #post:contents: or a #get: 
as in the example with #get: 'http://zn.stfx.eu/echo?delay=10' no process is 
shown. Any hint?

Thanks in advance,
Roberto




Re: [Pharo-dev] ZnClient send big data + progress

2014-06-06 Thread roberto.mine...@usi.ch
Hi Sven,

Thanks a lot for the answer, it’s two days I am struggling on it!
Let me know if you discover how to fix the ZdcSocketStream to behave in a good 
way ;)

Cheers,
R

On Jun 6, 2014, at 1:14 PM, Sven Van Caekenberghe s...@stfx.eu wrote:

 Hi Roberto,
 
 Let's see. First we start an HTTP server in Pharo 3:
 
 (ZnServer defaultOn: 1701)
  onRequestRespond: [ :request | 
request inspect. 
ZnResponse ok: (ZnEntity text: 'OK') ];
  maximumEntitySize: 100*1024*1024;
  logToTranscript ;
  start.
 
 The handler code will always reply 'OK', but also inspect the incoming 
 request. I raise the maximum entity size to 100Mb.
 
 Here is a simple request:
 
 ZnClient new
  url: 'http://localhost:1701';
  entity: (ZnEntity with: (0 to: 255) asByteArray);
  post.
 
 Next is a bigger one (10Mb):
 
 ZnClient new
  url: 'http://localhost:1701';
  entity: (ZnEntity with: (ByteArray new: 10*1024*1023 withAll: 123));
  post.
 
 Finally the big one (50Mb):
   
 ZnClient new
  url: 'http://localhost:1701';
  timeout: 900;
  entity: (ZnEntity with: (ByteArray new: 50*1024*1023 withAll: 123));
  post.
 
 That fails indeed, and I don't know why (yet). The weird thing is, it fails 
 with only 6Mb written, always at the same position, while the 10Mb upload did 
 work OK. Raising the timeout does indeed not make a difference. Data is 
 written using 16Kb chunks, with progress notifications (see ZnUtils 
 class#nextPutAll:on:). 
 
 Luckily, there is a workaround, using the classic SocketStream somehow fixes 
 the issue:
 
  ZnNetworkingUtils default socketStreamClass: SocketStream.
 
 Now, for the progress indication, Zinc certainly does it correctly, but 
 somehow the UI does not always follow. You can verify this by writing to the 
 Transcript:
 
 [ :bar |
  bar title: 'Uploading...'.
  [
ZnClient new 
  signalProgress: true;
  url: 'http://localhost:1701';
  entity: (ZnEntity with: (ByteArray new: 10*1024*1023 withAll: 123));
  post ]
on: HTTPProgress 
do: [ :progress |
  progress isEmpty ifFalse: [ bar current: progress percentage ]. 
  Transcript crShow: progress.
  progress resume ] ] asJob run.
 
 Experiment with adding/commenting out the #crShow: you will see that it 
 works, sometimes.
 
 HTH,
 
 Sven
 
 On 06 Jun 2014, at 10:47, roberto.mine...@usi.ch wrote:
 
 Hi guys,
 
 I have a problem with Zinc, I need to send a huge amount of data (bytes) 
 that translates to ~50Mb.
 
 When I do something like:
 
 ZnEasy 
  post: 'http://localhost:15432' 
  data: (ZnEntity bytes: aHugeByteArray.]
 
 I encounter a ‘ConnectionTimedOut: Data send timed out.’, I attach the stack 
 trace:
 
 ZdcSocketStream(ZdcSimpleSocketStream)flushBytes:startingAt:count:
 ZdcSocketStreamnext:putAll:startingAt:
 ZnBivalentWriteStreamnext:putAll:startingAt:
 ZnUtils classnextPutAll:on:
 ZnByteArrayEntitywriteOn:
 ZnEntityWriterwriteEntity:
 ZnRequest(ZnMessage)writeOn:
 ZnRequestwriteOn:
 ZnClientexecuteRequestResponse
 ZnClientgetConnectionAndExecute in Block: [ self executeRequestResponse ]
 BlockClosureensure:
 ZnClientgetConnectionAndExecute
 ZnClientexecuteWithRedirectsRemaining:
 ZnClientexecuteWithRetriesRemaining: in Block: [ self 
 executeWithRedirectsRemaining: self maxNumb...etc...
 BlockClosureon:do:
 ZnClientexecuteWithRetriesRemaining:
 ZnClientexecuteWithTimeout in Block: [ self executeWithRetriesRemaining: 
 self numberOfR...etc...
 BlockClosureon:do:
 ZnClientexecuteWithTimeout in Block: [ ...
 ZnClientwithTimeoutDo: in Block: [ ^ block value ]
 ZnConnectionTimeout(DynamicVariable)value:during: in Block: [ ...
 BlockClosureensure:
 ZnConnectionTimeout(DynamicVariable)value:during:
 ZnConnectionTimeout class(DynamicVariable class)value:during:
 ZnClientwithTimeoutDo:
 ZnClientexecuteWithTimeout
 ZnClientexecute in Block: [ result := self executeWithTimeout ]
 ZnClientwithProgressDo: in Block: [ ^ block value ]
 ZnSignalProgress(DynamicVariable)value:during: in Block: [ ...
 BlockClosureensure:
 
 I tried to:
 - Augment the client timeout to a huge value (10 mins) but it has no effect: 
 The data send still goes into timeout, after 10-15 sec
 - I replaced the ZnEntity with a ZnMultiPartFormDataEntity, still no luck
 
 I am wondering what else can I do.
 
 Moreover, I discovered there is a #signalProgress: message to signal 
 process. The following examples do not work, any hint?
 
 
 Example 1, from the book @ 
 http://zn.stfx.eu/zn/zinc-http-components-paper.html:
 
 UIManager default informUserDuring: [ :bar |
 [ ^ ZnClient new
   signalProgress: true;
   get: 'http://zn.stfx.eu/echo?delay=2' ]
   on: HTTPProgress 
   do: [ :progress | bar value: progress printString. progress resume ] ]
 
 
 Example 2, from ZnClientTests#testProgress works, but not when issuing a 
 POST request
 [ :bar

[Pharo-dev] [Fuel] Serialize and materialize to GZip

2014-04-30 Thread roberto.mine...@usi.ch
Hi,

Following the Fuel test FLUserGuidesTest#testGZip I discovered that I can 
serialize and materialize to and from GZip archives. Cool!

I tried with some small test object and it worked like a charm. When I tried 
with a large object…

Serialization
- It does not work, the image instantly crashes

Materialization
- Since I was not able to serialize the large object on GZip, I serialized 
normally than compressed the resulting fuel file using GZipWriteStream 
class#compressFile:
- When I materialize from the GZip archive, it takes forever and does not 
succeed after more than 1 minute. Note that the same non-Gzipped file takes a 
couple of seconds to be materialized.

How can I handle this?

Thanks in advance,
Roby


[Pharo-dev] Milliseconds in DateAndTime or TimeStamp

2014-04-22 Thread roberto.mine...@usi.ch
Hi,

I am wondering if there is the possibility to get milliseconds in a TimeStamp.

I need to record fine-grained events and second-granularity is not enough.

Cheers,
Roberto


Re: [Pharo-dev] Milliseconds in DateAndTime or TimeStamp

2014-04-22 Thread roberto.mine...@usi.ch
TimeStamp now rounds the timestamp, so #asNanoSeconds returns the seconds * 
10e9.

Doing “DateAndTime now” solves my issue, but this is a total non-sense.

Cheers,
R

On Apr 22, 2014, at 4:54 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote:

 Well, it has #asNanoSeconds, how finer can you go?
 
 Uko
 
 On 22 Apr 2014, at 17:13, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I am wondering if there is the possibility to get milliseconds in a 
 TimeStamp.
 
 I need to record fine-grained events and second-granularity is not enough.
 
 Cheers,
 Roberto
 
 




Re: [Pharo-dev] Milliseconds in DateAndTime or TimeStamp

2014-04-22 Thread roberto.mine...@usi.ch
If done right, TimeStamp would have not caused any confusion. 
Now that I discovered that a TimeStamp is a DateAndTime with rounded seconds 
(read: non-sense) I agree with you.

On Apr 22, 2014, at 6:42 PM, Sven Van Caekenberghe s...@stfx.eu wrote:

 TimeStamp is deprecated, because it creates too much confusion, you better 
 use DateAndTime.
 
 On 22 Apr 2014, at 17:11, roberto.mine...@usi.ch wrote:
 
 TimeStamp now rounds the timestamp, so #asNanoSeconds returns the seconds 
 * 10e9.
 
 Doing “DateAndTime now” solves my issue, but this is a total non-sense.
 
 Cheers,
 R
 
 On Apr 22, 2014, at 4:54 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote:
 
 Well, it has #asNanoSeconds, how finer can you go?
 
 Uko
 
 On 22 Apr 2014, at 17:13, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I am wondering if there is the possibility to get milliseconds in a 
 TimeStamp.
 
 I need to record fine-grained events and second-granularity is not enough.
 
 Cheers,
 Roberto
 
 
 
 
 
 




Re: [Pharo-dev] MongoGB GridFS driver for Pharo

2014-04-11 Thread roberto.mine...@usi.ch

On Apr 10, 2014, at 1:18 PM, Norbert Hartl norb...@hartl.name wrote:

 
 Am 10.04.2014 um 11:17 schrieb Esteban Lorenzano esteba...@gmail.com:
 
 Hi,
 
 Voyage did not implement GridFS out of the box. 
 But It can be extended to use it, it does not looks as a real complicated 
 API.
 
 Agreed. But I ask myself what is the use of GridFS in voyage. I would guess 
 that in most use cases the access to GridFS needs to be offloaded of the 
 image.

What about storing and retrieving documents that exceed the Mongo document size 
limit? :)

Cheers,
R

 
 Norbert
 
 Esteban
 
 On 10 Apr 2014, at 11:07, roberto.mine...@usi.ch wrote:
 
 Hi guys,
 
 I need to store objects (i.e., mongo documents) which exceeds the 
 BSON-document size of 16MB.
 
 I run into the “official” mongoDB solution, which is to use GridFS.
 
 Does anyone know if there is any possibility to use GridFS within Pharo? 
 For example with Voyage… or any other suggestion is highly appreciated!
 
 Cheers,
 Roberto
 
 
 
 




[Pharo-dev] MongoGB GridFS driver for Pharo

2014-04-10 Thread roberto.mine...@usi.ch
Hi guys,

I need to store objects (i.e., mongo documents) which exceeds the BSON-document 
size of 16MB.

I run into the “official” mongoDB solution, which is to use GridFS.

Does anyone know if there is any possibility to use GridFS within Pharo? For 
example with Voyage… or any other suggestion is highly appreciated!

Cheers,
Roberto


Re: [Pharo-dev] MongoGB GridFS driver for Pharo

2014-04-10 Thread roberto.mine...@usi.ch
Ok, thanks Esteban.

Do you plan to integrate it in Voyage or should we look into it?
Any starting point? Never done something similar.

Cheers,
R

On Apr 10, 2014, at 11:17 AM, Esteban Lorenzano esteba...@gmail.com wrote:

 Hi,
 
 Voyage did not implement GridFS out of the box. 
 But It can be extended to use it, it does not looks as a real complicated API.
 
 Esteban
 
 On 10 Apr 2014, at 11:07, roberto.mine...@usi.ch wrote:
 
 Hi guys,
 
 I need to store objects (i.e., mongo documents) which exceeds the 
 BSON-document size of 16MB.
 
 I run into the “official” mongoDB solution, which is to use GridFS.
 
 Does anyone know if there is any possibility to use GridFS within Pharo? For 
 example with Voyage… or any other suggestion is highly appreciated!
 
 Cheers,
 Roberto
 
 




[Pharo-dev] Spec double title or nil title

2014-03-14 Thread roberto.mine...@usi.ch
Hi Guys,

I noticed a weird behavior of Spec MenuModel, it has either a double title or a 
#nil title.

Please see 
https://pharo.fogbugz.com/f/cases/13075/Spec-double-title-or-nil-title

Cheers,
R


Re: [Pharo-dev] Is there some shared memory space?

2014-03-08 Thread roberto.mine...@usi.ch
Anyone on this? It is very frustrating for me.

Cheers,
Roby

On Mar 7, 2014, at 1:05 PM, roberto.mine...@usi.ch wrote:

 
 On Mar 7, 2014, at 12:24 PM, Max Leske maxle...@gmail.com wrote:
 
 
 On 07.03.2014, at 11:55, roberto.mine...@usi.ch wrote:
 
 Hi guys,
 
 I am experiencing a very strange problem that makes me think there is some 
 shared memory problem with Pharo.
 
 Here are the steps that lead to the problem:
 - I have an image, I do something (i.e., materializing objects with Fuel)
 - I encounter a problem and a debugger pops up with a “self error: 
 something
 - I close the debugger
 - I close the image
 
 Do you save the image? If so, are you saving references to the already 
 materialized objects?
 
 Of course, I did not save the image. Otherwise I’d have understood the 
 behavior.
 
 
 - I reopen the image
 - I fix the bug (i.e., commenting the self error)
 - I re-run the same thing as in the first step
 - An OutOfMemory error appears.
 
 Any clue?
 
 Thanks,
 Roberto




Re: [Pharo-dev] [Fuel] Unexpected stream version 19

2014-03-07 Thread roberto.mine...@usi.ch
Hi Max,

Thanks for the answer in the first place. Besides the “unexpected stream”, I am 
also experiencing some weird behavior about memory consumption.

I have a folder with 70 fuel files, ranging from few kb to 40MB. Each file 
represents a development session with some of my objects inside. 
I have a method that scans that directory, with sub-directories, and 
materializes all the objects in the image.

Until last month, this worked like a charm but now, every time I launch it I 
got an OutOfMemory problem with the VM.

Do you have any idea how this is possible? I tried to increase heap size, pass 
the —memory option to the VM, force garbage collection but the problem 
persists. I also tried to load the old Fuel (1.9.1), the version I was using to 
export. Still no luck.

Thanks in advance for any help,
Roberto
 
I am experiencing something really wired
On Mar 6, 2014, at 5:33 PM, Max Leske maxle...@gmail.com wrote:

 We’ve been discussing that and are evaluating different approaches to solving 
 this problem. We are pretty sure (but can’t guarantee) that there are no 
 format differences between 1.9 and 1.9.3. So feel free to remove the error 
 and continue. It will probably work (just expect that it might not).
 
 Cheers,
 Max
 
 On 06.03.2014, at 17:23, Sven Van Caekenberghe s...@stfx.eu wrote:
 
 Well, https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3 was just 
 integrated. Why Fuel is so picky about minor versions, and if that matters, 
 I don't know.
 
 On 06 Mar 2014, at 17:14, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I just run into an error while materializing an object with Fuel. 
 Unexpected stream version 19 should be 193.
 
 Do you have any idea why? I noticed that the fuel #stable version is now 
 1.9.3 instead of 1.9.1 which was the version I used for export. When I 
 loaded Fuel 1.9.1 despite getting some errors, I managed to import my 
 objects.
 
 Do you guys have an idea why?
 
 Thanks in advance, here is the stack trace.
 
 Roby
 
 FLMaterializerverifyVersionFrom:
 FLMaterializermaterializeFrom:
 FLMaterializer classmaterializationFromFileNamed: in Block: [ 
 :aFileStream | self newDefault materializeFrom: ...etc...
 StandardFileStream class(FileStream class)detectFile:do: in Block: [ 
 anotherBlock value: file ]
 BlockClosureensure:
 StandardFileStream class(FileStream class)detectFile:do:
 StandardFileStream class(FileStream class)oldFileNamed:do:
 FLMaterializer classmaterializationFromFileNamed:
 FLMaterializer classmaterializeFromFileNamed:
 DFPharoMenu classimportSessionFromFuelPath:
 DFPharoMenu classimportAllSessionsFromFolder in Block: [ :bar | ...
 BlockClosurecull:
 Jobrun in Block: [ result := block cull: self ]
 BlockClosureon:do:
 Jobrun in Block: [ ...
 BlockClosureensure:
 Jobrun
 MorphicUIManager(UIManager)displayProgress:from:to:during:
 ByteString(String)displayProgressAt:from:to:during:
 DFPharoMenu classimportAllSessionsFromFolder
 DFPharoMenu classmenuCommandOn: in Block: [ self 
 importAllSessionsFromFolder ]
 BlockClosurecull:
 ToggleMenuItemMorph(MenuItemMorph)invokeWithEvent: in Block: [ ...
 BlockClosureensure:
 CursorWithMask(Cursor)showWhile:
 ToggleMenuItemMorph(MenuItemMorph)invokeWithEvent:
 ToggleMenuItemMorph(MenuItemMorph)mouseUp:
 ToggleMenuItemMorph(MenuItemMorph)handleMouseUp:
 MouseButtonEventsentTo:
 ToggleMenuItemMorph(Morph)handleEvent:
 
 
 
 
 
 
 
 




[Pharo-dev] Is there some shared memory space?

2014-03-07 Thread roberto.mine...@usi.ch
Hi guys,

I am experiencing a very strange problem that makes me think there is some 
shared memory problem with Pharo.

Here are the steps that lead to the problem:
- I have an image, I do something (i.e., materializing objects with Fuel)
- I encounter a problem and a debugger pops up with a “self error: something
- I close the debugger
- I close the image
- I reopen the image
- I fix the bug (i.e., commenting the self error)
- I re-run the same thing as in the first step
- An OutOfMemory error appears.

Any clue?

Thanks,
Roberto


Re: [Pharo-dev] Is there some shared memory space?

2014-03-07 Thread roberto.mine...@usi.ch

On Mar 7, 2014, at 12:24 PM, Max Leske maxle...@gmail.com wrote:

 
 On 07.03.2014, at 11:55, roberto.mine...@usi.ch wrote:
 
 Hi guys,
 
 I am experiencing a very strange problem that makes me think there is some 
 shared memory problem with Pharo.
 
 Here are the steps that lead to the problem:
 - I have an image, I do something (i.e., materializing objects with Fuel)
 - I encounter a problem and a debugger pops up with a “self error: something
 - I close the debugger
 - I close the image
 
 Do you save the image? If so, are you saving references to the already 
 materialized objects?

Of course, I did not save the image. Otherwise I’d have understood the behavior.

 
 - I reopen the image
 - I fix the bug (i.e., commenting the self error)
 - I re-run the same thing as in the first step
 - An OutOfMemory error appears.
 
 Any clue?
 
 Thanks,
 Roberto
 
 




[Pharo-dev] [Fuel] Unexpected stream version 19

2014-03-06 Thread roberto.mine...@usi.ch
Hi,

I just run into an error while materializing an object with Fuel. Unexpected 
stream version 19 should be 193.

Do you have any idea why? I noticed that the fuel #stable version is now 1.9.3 
instead of 1.9.1 which was the version I used for export. When I loaded Fuel 
1.9.1 despite getting some errors, I managed to import my objects.

Do you guys have an idea why?

Thanks in advance, here is the stack trace.

Roby

FLMaterializerverifyVersionFrom:
FLMaterializermaterializeFrom:
FLMaterializer classmaterializationFromFileNamed: in Block: [ :aFileStream | 
self newDefault materializeFrom: ...etc...
StandardFileStream class(FileStream class)detectFile:do: in Block: [ 
anotherBlock value: file ]
BlockClosureensure:
StandardFileStream class(FileStream class)detectFile:do:
StandardFileStream class(FileStream class)oldFileNamed:do:
FLMaterializer classmaterializationFromFileNamed:
FLMaterializer classmaterializeFromFileNamed:
DFPharoMenu classimportSessionFromFuelPath:
DFPharoMenu classimportAllSessionsFromFolder in Block: [ :bar | ...
BlockClosurecull:
Jobrun in Block: [ result := block cull: self ]
BlockClosureon:do:
Jobrun in Block: [ ...
BlockClosureensure:
Jobrun
MorphicUIManager(UIManager)displayProgress:from:to:during:
ByteString(String)displayProgressAt:from:to:during:
DFPharoMenu classimportAllSessionsFromFolder
DFPharoMenu classmenuCommandOn: in Block: [ self importAllSessionsFromFolder ]
BlockClosurecull:
ToggleMenuItemMorph(MenuItemMorph)invokeWithEvent: in Block: [ ...
BlockClosureensure:
CursorWithMask(Cursor)showWhile:
ToggleMenuItemMorph(MenuItemMorph)invokeWithEvent:
ToggleMenuItemMorph(MenuItemMorph)mouseUp:
ToggleMenuItemMorph(MenuItemMorph)handleMouseUp:
MouseButtonEventsentTo:
ToggleMenuItemMorph(Morph)handleEvent:






Re: [Pharo-dev] Spec #subMenu is broken

2014-03-05 Thread roberto.mine...@usi.ch
Perfect. Please ping us when it is integrated ;)

On Mar 5, 2014, at 9:15 AM, Benjamin benjamin.vanryseghem.ph...@gmail.com 
wrote:

 On 05 Mar 2014, at 08:41, Pharo4Stef pharo4s...@free.fr wrote:
 where? because I wanted to integrate it and I could not find the slice in 
 the inbox.
 
 PharoInbox, slice number 13040
 
 It’s weird you do no find it :S
 
 
 did you fix also the menu title rendering (when putting a title it was not 
 used and rendered)
 because I was hacking a solution in the “MenuAdapter” but I do not remember 
 where I put the code.
 
 I do not remember such an issue :(
 
 I will dig the code and publish it, if it is not fixed.
 
 Cool, tell me :)
 
 Ben




[Pharo-dev] Spec #subMenu is broken

2014-03-04 Thread roberto.mine...@usi.ch
Hi,

It seems that Spec’s #subMenu functionality is broken. 

I opened an entry here: 
https://pharo.fogbugz.com/f/cases/13039/Spec-s-subMenu-is-broken

Cheers,
RM


Re: [Pharo-dev] Spec #subMenu is broken

2014-03-04 Thread roberto.mine...@usi.ch
Cool Ben!

P.s. Should I wait until the fix will be integrated in Pharo?

Cheers,
R

On Mar 4, 2014, at 5:13 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com 
wrote:

 Thanks for the report :)
 
 Fixed in commit df6e44a :)
 
 Ben
 
 On 04 Mar 2014, at 16:57, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 It seems that Spec’s #subMenu functionality is broken. 
 
 I opened an entry here: 
 https://pharo.fogbugz.com/f/cases/13039/Spec-s-subMenu-is-broken
 
 Cheers,
 RM
 




Re: [Pharo-dev] [ANN]: EventRecorderMorph Port to 3.0

2014-01-13 Thread roberto.mine...@usi.ch
I am working on a similar thing (without the replaying feature).
I am interested in profiling (i.e., recording) some morphic events.

I will look into this existing recorder, thanks for sharing.

Cheers,
R

On Jan 13, 2014, at 9:03 AM, Goubier Thierry thierry.goub...@cea.fr wrote:

 Cool! This is really interesting to have.
 
 Executable screencasts... I'll do that next time for teaching with Pharo :)
 
 Thierry
 
 Le 13/01/2014 04:14, Sean P. DeNigris a écrit :
 If you don't know EventRecorderMorph and HandMorphForReplay (which I didn't
 and started to re-implement), they are super cool.
 
 1. DoIt: EventRecorderMorph new openInWorld
 2. Click record in the GUI
 3. Perform some UI actions
 4. Click play in the GUI
 
 Your keyboard and mouse actions will be replayed in the World! I know
 right?! Amazing. This could be really cool for live documentation and
 executable screencasts :)
 
 It's just a straight port now, but I'd like to decouple the recorder and
 replay hand so that any event source can be used.
 
 http://smalltalkhub.com/#!/~PharoExtras/EventRecorder
 
 Initial commit: port EventRecorderMorph and HandMorphForReplay (originally
 in MorphicExtras-AdditionalSupport) to Pharo 3.0
 
 
 
 -
 Cheers,
 Sean
 --
 View this message in context: 
 http://forum.world.st/ANN-EventRecorderMorph-Port-to-3-0-tp4736258.html
 Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
 
 
 
 -- 
 Thierry Goubier
 CEA list
 Laboratoire des Fondations des Systèmes Temps Réel Embarqués
 91191 Gif sur Yvette Cedex
 France
 Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
 




[Pharo-dev] Detect when Pharo loses focus

2014-01-13 Thread roberto.mine...@usi.ch
Hi guys,

I am trying to detect when a user switches her focus from Pharo to another app.

In short I’d like to know when the user switches (i.e., atl+tab) from the Pharo 
application to another application, losing focus from the development.

I looked into Morphic and I was able to tell when the mouse goes outside the 
Pharo window.
Unfortunately this technique does not work when the user uses alt+tab to switch 
to another app, since the last mouse event is not outside the Pharo window.

Any suggestion where to look?

Thanks in advance,
R


Re: [Pharo-dev] Detect when Pharo loses focus

2014-01-13 Thread roberto.mine...@usi.ch
I wasn’t able to find something like that.

There is MorphLostFocus, bit is not triggered by World. And not triggered when 
Pharo loose focus.

Cheers,
R

On Jan 13, 2014, at 12:00 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com 
wrote:

 Did World trigger a keyboard focus lost announcement?
 
 Ben
 
 On 13 Jan 2014, at 06:49, roberto.mine...@usi.ch wrote:
 
 Hi guys,
 
 I am trying to detect when a user switches her focus from Pharo to another 
 app.
 
 In short I’d like to know when the user switches (i.e., atl+tab) from the 
 Pharo application to another application, losing focus from the development.
 
 I looked into Morphic and I was able to tell when the mouse goes outside the 
 Pharo window.
 Unfortunately this technique does not work when the user uses alt+tab to 
 switch to another app, since the last mouse event is not outside the Pharo 
 window.
 
 Any suggestion where to look?
 
 Thanks in advance,
 R
 




[Pharo-dev] #runOnce: of StartupAction not working

2014-01-08 Thread roberto.mine...@usi.ch
Hi,

I am playing with StartupAction’s. I discovered that the #runOnce: message is 
apparently not working.

Try to put this (https://dl.dropboxusercontent.com/u/6281855/pincopallino.st) 
StartupAction into ~/Library/Preferences/pharo and open an image.

The first time the name is set as expected. Then, change the ‘PincoPallino' 
name in the pincopallino.st file to another name, save and open another time 
your image.

I think it should change the name again, since #runOnce: is set to false. But 
it does not.

Looking around seems that the StartupLoader handles the preferences in a 
Dictionary whose keys are names (BAD) and if there is a preference with the 
same name of an already executed one it does not re-execute even though 
#runOnce: false.

I also put an entry in the tracker: 
https://pharo.fogbugz.com/f/cases/12594/runOnce-of-StartupAction-not-working

Cheers,
R


Re: [Pharo-dev] PharoLauncher as the default Pharo download on pharo.org?

2013-12-20 Thread roberto.mine...@usi.ch
I like the launcher, I’ll use it for sure by myself even though it will not be 
part of the standard Pharo distro.

Cheers,
R

On Dec 20, 2013, at 10:44 AM, Damien Cassou damien.cas...@gmail.com wrote:

 Hi guys,
 
 what do you think about setting the PharoLauncher as the default
 download for mac os x users?
 
 If you never tried the launcher, please try it now:
 
 Mac OS X: 
 https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Mac-Package/lastSuccessfulBuild/artifact/pharo-ci/Pharo%203.0.0.dmg
 Ubuntu : https://launchpad.net/~pharo/+archive/stable
 Others: http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher
 
 -- 
 Damien Cassou
 http://damiencassou.seasidehosting.st
 
 Success is the ability to go from one failure to another without
 losing enthusiasm.
 Winston Churchill
 




Re: [Pharo-dev] gtinspector deconstructed

2013-12-19 Thread roberto.mine...@usi.ch
Hi Doru,

I have never used it till 2 days ago when I was playing with Andrei to do 
something.

The only thing I can say is that it “feels” strange at the beginning… I am not 
used to this horizontal navigation… I am more used to spawning a lot of small 
inspectors that I can also use to compare things, i.e., one inspector close to 
the other.

Apart from that, Andrei told me it takes time but then you get used to it and 
you love it. Let’s see.

Cheers,
R

On Dec 19, 2013, at 7:50 AM, Tudor Girba tu...@tudorgirba.com wrote:

 Hi,
 
 I took a bit of time to describe how the GTInspector works, what makes it 
 different, and to provide hints for several usage scenarios.
 http://www.humane-assessment.com/blog/the-moldable-gtinspector-deconstructed
 
 It's a long post, I know :), but please take a look. As you might know, this 
 is the default inspector in the Moose image, but it can also be loaded in a 
 fresh Pharo image.
 
 I am particularly interested in the following:
 - if you never used it, and tried it now, what don't you like?
 - if you used it, was there anything that you did not know?
 - and of course, what do you like about it?
 
 Cheers,
 Doru
 
 -- 
 www.tudorgirba.com
 
 Every thing has its own flow




[Pharo-dev] SmalltalkHub is down

2013-11-08 Thread roberto.mine...@usi.ch
:’(


Re: [Pharo-dev] SmalltalkHub is down

2013-11-08 Thread roberto.mine...@usi.ch
Apparently is back up again ;)

On Nov 8, 2013, at 10:11 AM, roberto.mine...@usi.ch wrote:

 :’(




[Pharo-dev] Menu enabled not refreshing

2013-11-08 Thread roberto.mine...@usi.ch
Hi,

I think I spotted a bug. When registering a menu item I think the message 
PragmaMenuAndShortcutRegistration#enabled: passing a block is not working 
correctly.

It seems that the enabled state is somewhat cached, i.e., if the block value 
passes from true to false due to a certain condition in the model, the enabled 
state is not changed.

Are you aware of this? Am I missing something (i.e., force the refresh or 
something).

Thanks in advance,
Roby


[Pharo-dev] [Edu] 3-day project with high school students

2013-11-06 Thread roberto.mine...@usi.ch
Hi,

I would like to hear an opinion from you. I need to organize a 3-day project 
with high-school students. In short they will come to our University and I am 
the responsible to guide them to do “something” to introduce them to 
programming.

The assumption is that they have zero background about programming. In this 
mailing list I’ve read a couple of previous discussions about how to start to 
use Pharo and ST for educational purposes, but I’d love to collect additional 
opinions.

Visual programming is one of the thing that came to my mind. I though about 
Phratch. Michele suggested me to look also at Etoys (squeakland.org) and I will 
start to look at thesee two tools in the next days.

Any opinion, proposal, tool, article, suggestion, hint on the topic is really 
welcome.

Thanks in advance,
Roberto




Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

2013-10-29 Thread roberto.mine...@usi.ch
I’ll look at the doc… However if some of you is online in Skype we can have a 
chat…

Cheers and thanks for help,
Roby

On Oct 28, 2013, at 11:45 PM, Mariano Martinez Peck marianop...@gmail.com 
wrote:

 Indeed, I think I agree with Max. You can also use the substitute feature and 
 replace the instVars you don't want with nil or something...See the doc link 
 Martin sent.  
 
 
 On Mon, Oct 28, 2013 at 7:00 PM, Max Leske maxle...@gmail.com wrote:
 In my opinion the #fuelAccept: for the meta description object should be 
 overridden and there the behaviour for problematic references should be 
 defined.
 
 Roberto, what references does your meta object hold on to?
 
 Max
 
 
 On 28.10.2013, at 22:16, Martin Dias tinchod...@gmail.com wrote:
 
 
 
 
 On Mon, Oct 28, 2013 at 5:13 PM, roberto.mine...@usi.ch 
 roberto.mine...@usi.ch wrote:
 The idea is that I have an object (a session) which has meta data (time, 
 duration, author) and some other object inside.
 
 I want that Fuel serializes just that object and not pointes to other 
 object, globals and what not.
 
 This causes me a lot of troubles, moreover it makes the fuel file bigger 
 than the optimum…
 
 Still there is something that I don't understand in your problem. If you 
 just prune the graph, what your objects represent (conceptually) can be 
 lost. Did you pick one of your problematic session objects are explored it 
 until find how the unwanted block closures are referenced? I mean, fuel 
 doesn't invent the unwanted closures magically, you are saying to fuel to 
 serialize the graph with the unwanted objects already there. 
  
 
 Cheers,
 R
 
 
 On Oct 28, 2013, at 4:57 PM, Martin Dias tinchod...@gmail.com wrote:
 
 
 
 
  On Mon, Oct 28, 2013 at 4:47 PM, roberto.mine...@usi.ch 
  roberto.mine...@usi.ch wrote:
  Thanks,
 
  On Oct 28, 2013, at 4:36 PM, Martin Dias tinchod...@gmail.com wrote:
 
   Currently there is no such option.
 
  Maybe it is something which is needed, what do you think?
 
  The idea is that, if you serialize:
 
  a - b - c
 
  fuel actually would encode:
 
  a - b - nil
 
 
  that?
 
 
 
 
 
 
 
 
 
 -- 
 Mariano
 http://marianopeck.wordpress.com




Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

2013-10-29 Thread roberto.mine...@usi.ch
Guys,

Fuel it’s perfect, it was–of course–my fault.

When I considered everything and I moved away from Ring definition which caused 
me lot of troubles I forgot to consider MethodContext objects, which in turn 
points to CompiledMethod which point to classes. Thus Fuel serialize all this 
crap (including classes) and in the materialization phase I got clearly a 
FLClassNotFound.

Thanks a lot for the support,
Roby

On Oct 29, 2013, at 8:03 AM, roberto.mine...@usi.ch wrote:

 I’ll look at the doc… However if some of you is online in Skype we can have a 
 chat…
 
 Cheers and thanks for help,
 Roby
 
 On Oct 28, 2013, at 11:45 PM, Mariano Martinez Peck marianop...@gmail.com 
 wrote:
 
 Indeed, I think I agree with Max. You can also use the substitute feature 
 and replace the instVars you don't want with nil or something...See the doc 
 link Martin sent.  
 
 
 On Mon, Oct 28, 2013 at 7:00 PM, Max Leske maxle...@gmail.com wrote:
 In my opinion the #fuelAccept: for the meta description object should be 
 overridden and there the behaviour for problematic references should be 
 defined.
 
 Roberto, what references does your meta object hold on to?
 
 Max
 
 
 On 28.10.2013, at 22:16, Martin Dias tinchod...@gmail.com wrote:
 
 
 
 
 On Mon, Oct 28, 2013 at 5:13 PM, roberto.mine...@usi.ch 
 roberto.mine...@usi.ch wrote:
 The idea is that I have an object (a session) which has meta data (time, 
 duration, author) and some other object inside.
 
 I want that Fuel serializes just that object and not pointes to other 
 object, globals and what not.
 
 This causes me a lot of troubles, moreover it makes the fuel file bigger 
 than the optimum…
 
 Still there is something that I don't understand in your problem. If you 
 just prune the graph, what your objects represent (conceptually) can be 
 lost. Did you pick one of your problematic session objects are explored 
 it until find how the unwanted block closures are referenced? I mean, fuel 
 doesn't invent the unwanted closures magically, you are saying to fuel to 
 serialize the graph with the unwanted objects already there. 
 
 
 Cheers,
 R
 
 
 On Oct 28, 2013, at 4:57 PM, Martin Dias tinchod...@gmail.com wrote:
 
 
 
 
 On Mon, Oct 28, 2013 at 4:47 PM, roberto.mine...@usi.ch 
 roberto.mine...@usi.ch wrote:
 Thanks,
 
 On Oct 28, 2013, at 4:36 PM, Martin Dias tinchod...@gmail.com wrote:
 
 Currently there is no such option.
 
 Maybe it is something which is needed, what do you think?
 
 The idea is that, if you serialize:
 
 a - b - c
 
 fuel actually would encode:
 
 a - b - nil
 
 
 that?
 
 
 
 
 
 
 
 
 
 -- 
 Mariano
 http://marianopeck.wordpress.com
 
 




Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

2013-10-29 Thread roberto.mine...@usi.ch
Hi Mariano,

On Oct 29, 2013, at 1:35 PM, Mariano Martinez Peck marianop...@gmail.com 
wrote:

 On Tue, Oct 29, 2013 at 6:53 AM, roberto.mine...@usi.ch 
 roberto.mine...@usi.ch wrote:
 Guys,
 
 Fuel it’s perfect, it was–of course–my fault.
 
 When I considered everything and I moved away from Ring definition which 
 caused me lot of troubles I forgot to consider MethodContext objects, which 
 in turn points to CompiledMethod which point to classes. Thus Fuel serialize 
 all this crap (including classes) and in the materialization phase I got 
 clearly a FLClassNotFound.
 
 
 
 Even in this case, Fuel should have not serialized classes. Instead, if a 
 class was found in the graph, Fuel should have serialized a mock object 
 that just contains the class name and a few other things, but not the whole 
 class.

Nope, trust me it serialized the whole class.

 Then at materialization it should search that class name in the 
 SmalltalkDictionary and get that.

There is no such class at materialization.

 So...it could still happen that the class name you stored during 
 serialization is NOT present in materialization. But Fuel should not have 
 serialized the class itself but rather this mock object. 

Again, I removed the MethodContext and use a description for them, and 
everything work as expected.

Cheers,
R


 
 Cheers, 
  
 Thanks a lot for the support,
 Roby
 
 On Oct 29, 2013, at 8:03 AM, roberto.mine...@usi.ch wrote:
 
  I’ll look at the doc… However if some of you is online in Skype we can have 
  a chat…
 
  Cheers and thanks for help,
  Roby
 
  On Oct 28, 2013, at 11:45 PM, Mariano Martinez Peck marianop...@gmail.com 
  wrote:
 
  Indeed, I think I agree with Max. You can also use the substitute feature 
  and replace the instVars you don't want with nil or something...See the 
  doc link Martin sent.
 
 
  On Mon, Oct 28, 2013 at 7:00 PM, Max Leske maxle...@gmail.com wrote:
  In my opinion the #fuelAccept: for the meta description object should be 
  overridden and there the behaviour for problematic references should be 
  defined.
 
  Roberto, what references does your meta object hold on to?
 
  Max
 
 
  On 28.10.2013, at 22:16, Martin Dias tinchod...@gmail.com wrote:
 
 
 
 
  On Mon, Oct 28, 2013 at 5:13 PM, roberto.mine...@usi.ch 
  roberto.mine...@usi.ch wrote:
  The idea is that I have an object (a session) which has meta data (time, 
  duration, author) and some other object inside.
 
  I want that Fuel serializes just that object and not pointes to other 
  object, globals and what not.
 
  This causes me a lot of troubles, moreover it makes the fuel file bigger 
  than the optimum…
 
  Still there is something that I don't understand in your problem. If you 
  just prune the graph, what your objects represent (conceptually) can be 
  lost. Did you pick one of your problematic session objects are explored 
  it until find how the unwanted block closures are referenced? I mean, 
  fuel doesn't invent the unwanted closures magically, you are saying to 
  fuel to serialize the graph with the unwanted objects already there.
 
 
  Cheers,
  R
 
 
  On Oct 28, 2013, at 4:57 PM, Martin Dias tinchod...@gmail.com wrote:
 
 
 
 
  On Mon, Oct 28, 2013 at 4:47 PM, roberto.mine...@usi.ch 
  roberto.mine...@usi.ch wrote:
  Thanks,
 
  On Oct 28, 2013, at 4:36 PM, Martin Dias tinchod...@gmail.com wrote:
 
  Currently there is no such option.
 
  Maybe it is something which is needed, what do you think?
 
  The idea is that, if you serialize:
 
  a - b - c
 
  fuel actually would encode:
 
  a - b - nil
 
 
  that?
 
 
 
 
 
 
 
 
 
  --
  Mariano
  http://marianopeck.wordpress.com
 
 
 
 
 
 
 
 -- 
 Mariano
 http://marianopeck.wordpress.com




Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

2013-10-29 Thread roberto.mine...@usi.ch

On Oct 29, 2013, at 3:41 PM, Mariano Martinez Peck marianop...@gmail.com 
wrote:

 On Tue, Oct 29, 2013 at 11:37 AM, roberto.mine...@usi.ch 
 roberto.mine...@usi.ch wrote:
 Hi Mariano,
 
 On Oct 29, 2013, at 1:35 PM, Mariano Martinez Peck marianop...@gmail.com 
 wrote:
 
  On Tue, Oct 29, 2013 at 6:53 AM, roberto.mine...@usi.ch 
  roberto.mine...@usi.ch wrote:
  Guys,
 
  Fuel it’s perfect, it was–of course–my fault.
 
  When I considered everything and I moved away from Ring definition which 
  caused me lot of troubles I forgot to consider MethodContext objects, which 
  in turn points to CompiledMethod which point to classes. Thus Fuel 
  serialize all this crap (including classes) and in the materialization 
  phase I got clearly a FLClassNotFound.
 
 
 
  Even in this case, Fuel should have not serialized classes. Instead, if a 
  class was found in the graph, Fuel should have serialized a mock object 
  that just contains the class name and a few other things, but not the whole 
  class.
 
 Nope, trust me it serialized the whole class.
 
 
 So that is a bug. Do you have a reproducible test case? 

I’ll try to isolate the problem and provide a TC tomorrow

  
  Then at materialization it should search that class name in the 
  SmalltalkDictionary and get that.
 
 There is no such class at materialization.
 
  So...it could still happen that the class name you stored during 
  serialization is NOT present in materialization. But Fuel should not have 
  serialized the class itself but rather this mock object.
 
 Again, I removed the MethodContext and use a description for them, and 
 everything work as expected.
 
 Cheers,
 R
 
 
 
  Cheers,
 
  Thanks a lot for the support,
  Roby
 
  On Oct 29, 2013, at 8:03 AM, roberto.mine...@usi.ch wrote:
 
   I’ll look at the doc… However if some of you is online in Skype we can 
   have a chat…
  
   Cheers and thanks for help,
   Roby
  
   On Oct 28, 2013, at 11:45 PM, Mariano Martinez Peck 
   marianop...@gmail.com wrote:
  
   Indeed, I think I agree with Max. You can also use the substitute 
   feature and replace the instVars you don't want with nil or 
   something...See the doc link Martin sent.
  
  
   On Mon, Oct 28, 2013 at 7:00 PM, Max Leske maxle...@gmail.com wrote:
   In my opinion the #fuelAccept: for the meta description object should be 
   overridden and there the behaviour for problematic references should be 
   defined.
  
   Roberto, what references does your meta object hold on to?
  
   Max
  
  
   On 28.10.2013, at 22:16, Martin Dias tinchod...@gmail.com wrote:
  
  
  
  
   On Mon, Oct 28, 2013 at 5:13 PM, roberto.mine...@usi.ch 
   roberto.mine...@usi.ch wrote:
   The idea is that I have an object (a session) which has meta data 
   (time, duration, author) and some other object inside.
  
   I want that Fuel serializes just that object and not pointes to other 
   object, globals and what not.
  
   This causes me a lot of troubles, moreover it makes the fuel file 
   bigger than the optimum…
  
   Still there is something that I don't understand in your problem. If 
   you just prune the graph, what your objects represent (conceptually) 
   can be lost. Did you pick one of your problematic session objects are 
   explored it until find how the unwanted block closures are referenced? 
   I mean, fuel doesn't invent the unwanted closures magically, you are 
   saying to fuel to serialize the graph with the unwanted objects already 
   there.
  
  
   Cheers,
   R
  
  
   On Oct 28, 2013, at 4:57 PM, Martin Dias tinchod...@gmail.com wrote:
  
  
  
  
   On Mon, Oct 28, 2013 at 4:47 PM, roberto.mine...@usi.ch 
   roberto.mine...@usi.ch wrote:
   Thanks,
  
   On Oct 28, 2013, at 4:36 PM, Martin Dias tinchod...@gmail.com wrote:
  
   Currently there is no such option.
  
   Maybe it is something which is needed, what do you think?
  
   The idea is that, if you serialize:
  
   a - b - c
  
   fuel actually would encode:
  
   a - b - nil
  
  
   that?
  
  
  
  
  
  
  
  
  
   --
   Mariano
   http://marianopeck.wordpress.com
  
  
 
 
 
 
 
  --
  Mariano
  http://marianopeck.wordpress.com
 
 
 
 
 
 -- 
 Mariano
 http://marianopeck.wordpress.com




[Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

2013-10-28 Thread roberto.mine...@usi.ch
Hi,

I’m struggling with Fuel and I probably discovered my problem.

When trying to serialize an object (that represents a development session, 
i.e., contains some meta-data (title, author, etc.) and some objects 
representing actions of the developer) I often encounter problem with some 
BlockClosure’s which are somewhat corrupt and Fuel crashes and cannot serialize 
them. We already discussed this issue in this mailing list a while ago with Max.

I do not ask directly Fuel to serialize some BlockClosures, so my intuition is 
that Fuel serializes all the references to the objects I am trying to 
serialize. Am I right? Is there any way to tell Fuel not to do so?

Cheers and thanks for the help,
Roberto


Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

2013-10-28 Thread roberto.mine...@usi.ch
Hi Martin,

Thanks for the answer, I have another question. Is there any way to tell Fuel 
to serialize only the object with its instance variables and that’s it?

I don’t want Fuel to traverse any reference, just the object with its fields.

Thanks,
Roberto

On Oct 28, 2013, at 4:00 PM, Martin Dias tinchod...@gmail.com wrote:

 I don't remember the previous discussion. When you tell fuel to serialize an 
 object, it traverses the references of that object *to* other objects. By 
 default, it uses some criteria to prune the traversal. For example, when the 
 traversed object is a class, then it encodes the name of that class. Similar 
 for a method. 
 
 So I think in some way your object is referencing that problematic block 
 closure. 
 
 Maybe it can give you a clue if you put a halt in FLAnalysistrace: 
 
 Maybe a self haltIf: anObject isClosure
 
 HTH,
 Martín
 
 
 On Mon, Oct 28, 2013 at 8:16 AM, roberto.mine...@usi.ch 
 roberto.mine...@usi.ch wrote:
 Hi,
 
 I’m struggling with Fuel and I probably discovered my problem.
 
 When trying to serialize an object (that represents a development session, 
 i.e., contains some meta-data (title, author, etc.) and some objects 
 representing actions of the developer) I often encounter problem with some 
 BlockClosure’s which are somewhat corrupt and Fuel crashes and cannot 
 serialize them. We already discussed this issue in this mailing list a while 
 ago with Max.
 
 I do not ask directly Fuel to serialize some BlockClosures, so my intuition 
 is that Fuel serializes all the references to the objects I am trying to 
 serialize. Am I right? Is there any way to tell Fuel not to do so?
 
 Cheers and thanks for the help,
 Roberto
 




Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

2013-10-28 Thread roberto.mine...@usi.ch
Thanks,

On Oct 28, 2013, at 4:36 PM, Martin Dias tinchod...@gmail.com wrote:

 Currently there is no such option.

Maybe it is something which is needed, what do you think?

 You might want to customize how your development session objects are 
 encoded. Like in DateAndTime... you can look at these methods:
  
 #fuelAccept:
 #serializeOn:
 #materializeFrom: (at class-side)
 
 
 Or you can tell fuel to ignore some instance variables, if you override 
 #fuelIgnoredInstanceVariableNames at class-side.
 
 Both alternatives are covered in the documentation 
 
 http://rmod.lille.inria.fr/web/pier/software/Fuel
 
 (which is sadly down in this moment, but will be up again soon)
 
 Martín
 
 
 On Mon, Oct 28, 2013 at 4:10 PM, roberto.mine...@usi.ch 
 roberto.mine...@usi.ch wrote:
 Hi Martin,
 
 Thanks for the answer, I have another question. Is there any way to tell Fuel 
 to serialize only the object with its instance variables and that’s it?
 
 I don’t want Fuel to traverse any reference, just the object with its fields.
 
 Thanks,
 Roberto
 
 On Oct 28, 2013, at 4:00 PM, Martin Dias tinchod...@gmail.com wrote:
 
  I don't remember the previous discussion. When you tell fuel to serialize 
  an object, it traverses the references of that object *to* other objects. 
  By default, it uses some criteria to prune the traversal. For example, when 
  the traversed object is a class, then it encodes the name of that class. 
  Similar for a method.
 
  So I think in some way your object is referencing that problematic block 
  closure.
 
  Maybe it can give you a clue if you put a halt in FLAnalysistrace:
 
  Maybe a self haltIf: anObject isClosure
 
  HTH,
  Martín
 
 
  On Mon, Oct 28, 2013 at 8:16 AM, roberto.mine...@usi.ch 
  roberto.mine...@usi.ch wrote:
  Hi,
 
  I’m struggling with Fuel and I probably discovered my problem.
 
  When trying to serialize an object (that represents a development session, 
  i.e., contains some meta-data (title, author, etc.) and some objects 
  representing actions of the developer) I often encounter problem with some 
  BlockClosure’s which are somewhat corrupt and Fuel crashes and cannot 
  serialize them. We already discussed this issue in this mailing list a 
  while ago with Max.
 
  I do not ask directly Fuel to serialize some BlockClosures, so my intuition 
  is that Fuel serializes all the references to the objects I am trying to 
  serialize. Am I right? Is there any way to tell Fuel not to do so?
 
  Cheers and thanks for the help,
  Roberto
 
 
 
 




Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

2013-10-28 Thread roberto.mine...@usi.ch
The idea is that I have an object (a session) which has meta data (time, 
duration, author) and some other object inside.

I want that Fuel serializes just that object and not pointes to other object, 
globals and what not.

This causes me a lot of troubles, moreover it makes the fuel file bigger than 
the optimum…

Cheers,
R


On Oct 28, 2013, at 4:57 PM, Martin Dias tinchod...@gmail.com wrote:

 
 
 
 On Mon, Oct 28, 2013 at 4:47 PM, roberto.mine...@usi.ch 
 roberto.mine...@usi.ch wrote:
 Thanks,
 
 On Oct 28, 2013, at 4:36 PM, Martin Dias tinchod...@gmail.com wrote:
 
  Currently there is no such option.
 
 Maybe it is something which is needed, what do you think?
 
 The idea is that, if you serialize:
 
 a - b - c
 
 fuel actually would encode:
 
 a - b - nil
 
 
 that?
 
 




Re: [Pharo-dev] How to delete an obsolete class ?

2013-10-14 Thread roberto.mine...@usi.ch
Thank you Pavel,

Just run into the same situation and your 'Smalltalk fixObsoleteReferences' 
worked like a charm ;)

Cheers,
Roberto

On Oct 10, 2013, at 11:11 AM, Pavel Krivanek pavel.kriva...@gmail.com wrote:

 Hi Olivier,
 
 firstly try Smalltalk fixObsoleteReferences. Then try this:
 
 Smalltalk tools pointerExplorer openOn: SystemNavigation default
 obsoleteClasses first.
 
 Look at every reference that is not related to the explorer itself and
 try to find why it is not garbage-collected.
 
 Cheers,
 -- Pavel
 
 2013/10/10 Olivier Auverlot olivier.auver...@gmail.com:
 Hi Pavel,
 
 Thanks for your response.
 
 I tryed this morning and in fact, the obsolete class has not instances.
 
 SystemNavigation default obsoleteClasses {AnObsoletePVENodeStatus}
 
 SystemNavigation default obsoleteClasses collect: #allSubInstances. an 
 Array(an OrderedCollection())
 
 have you an idea how to remove this class ?
 
 Best regards
 Olivier ;-)
 
 Le 9 oct. 2013 à 10:46, Pavel Krivanek a écrit :
 
 You need to check if it still does have some instances and kill them.
 Then find and remove all references to the class.
 
 SystemNavigation default obsoleteClasses.
 
 SystemNavigation default obsoleteClasses collect: #allSubInstances.
 
 SystemNavigation default obsoleteClasses first allSubInstances first 
 pointersTo.
 
 etc...
 
 Good hunt
 -- Pavel
 
 2013/10/9 Olivier Auverlot olivier.auver...@gmail.com:
 Hi,
 
 In my project, my code has a strange behavior when I'm reading all 
 subclasses of an another class.
 
 The following code must visit all the subclasses of PVEStatus but I get a 
 bad result.
 
   PVEStatus allSubclasses
   do: [ :statusDatatype |
   (aRawStatus at: 'type') = statusDatatype type
   ifTrue: [ ^ statusDatatype getStatus: 
 aRawStatus callback: self ] ]
 
 The answer contains #AnObsoletePVENodeStatus and this class doesn't exist. 
 She doesn't appear in the class browser. I suppose that it's a rest of 
 refactoring. How can I delete this obsolete class ?
 
 Best regards
 Olivier ;-)
 
 
 
 
 
 
 




Re: [Pharo-dev] Please contributors fill up this form...

2013-10-14 Thread roberto.mine...@usi.ch
Here's mine:

PharoContributor new
name: 'Roberto Minelli';
email: 'roberto.min...@usi.ch';
website: 'http://www.inf.usi.ch/phd/minelli';
description: 'PhD Student at REVEAL @ Faculty of Informatics (University of 
Lugano)';
yourself.

On Oct 9, 2013, at 1:34 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote:

 Hi guys
 
 I would like to get 
   contributors.pharo.org a bit more representative of Pharo.
 
 We should have Previous contributors and enhance the current list.
 Can you please reply to this mail
 
   PharoContributor new
   name: 'Esteban Lorenzano';
   id: 'estebanlm';
   email: 'esteba...@gmail.com';
   website: 'http://smallworks.eu';
   description: 'Pharo core team. Contributor of several projects, 
 including Kernel, DBXTalk, Voyage, Mars, etc. Also I work on the VM.';
   image: 
 'http://www.gravatar.com/avatar/193af464509ae8fbcc04abad70b72fc0?s=120';
   yourself
 
 
 Stef




Re: [Pharo-dev] [ann] system attraction view

2013-10-03 Thread roberto.mine...@usi.ch
Cool! It really catches the eye, Doru!

On Oct 3, 2013, at 11:37 PM, Alexandre Bergel alexandre.ber...@me.com wrote:

 I think this is the nicest looking visualization made so far with Roassal.
 Consider it for the next Roassal contest next year. 
 
 Amazing job! Truly beautiful.
 
 Alexandre
 
 
 On Oct 3, 2013, at 6:34 PM, Tudor Girba tu...@tudorgirba.com wrote:
 
 Hi,
 
 I built a new visualization that has two goals:
 
 1. show how the architecture of a system is fluid rather than rigid.
 2. look good and serve as advertisement device for Moose, Roassal and Pharo.
 
 A description of mainly point 1. can be found here:
 http://www.humane-assessment.com/blog/system-attraction/
 
 I already used it as a splash screen for a couple of presentations, and it 
 catches the eye.
 
 The code can be found in Moose, in a separate tiny FAMIXSystemAttraction 
 class. You can invoke it on any class group (note: it can take a long time 
 to render for large groups).
 
 Cheers,
 Doru
 
 -- 
 www.tudorgirba.com
 
 Every thing has its own flow
 
 -- 
 _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
 Alexandre Bergel  http://www.bergel.eu
 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
 
 
 
 




Re: [Pharo-dev] Dynamically adding nodes to Roassal

2013-09-30 Thread roberto.mine...@usi.ch
Anyone can help here?

On Sep 20, 2013, at 5:32 PM, roberto.mine...@usi.ch wrote:

 Hi, 
 
 It's me again..
 
 I managed to have something *almost* working, but the behavior of the 
 ROTreeMapLayout is not clear to me.
 
 Using the ROMondrianViewBuilder I can specify the size of the Tree map, but 
 then I am not able to dynamically add nodes. Well, at least I did not manage 
 to do that. So I moved to pure Roassal, as suggested by Alejandro.
 
 Here's how my actual code looks like: http://ws.stfx.eu/CFM522Z9X3ES
 
 I am a beginner with Roassal, so I spend some time to figure out how to draw 
 the tree map in this way. I did not really quite understand why I have to add 
 the ROBox new size: 200 to the ROElement, but I'll figure it out.
 
 The thing is when I try to add the new node. Following, again, Alejandro's 
 advice I am writing something like:
 
 I add a new node, re-layout the view, and signalUpdate
 rawView add: ((ROElement on: 10) + (ROBox new size: 200)).
 (ROTreeMapLayout withWeightBlock: [ :e | e model ]) applyOn: rawView elements.
 rawView signalUpdate .
 
 The result is quite strange, the view is indeed updated but I cannot 
 understand why all sizes are messed up.
 
 My questions, in short are: How can I fix the overall size of the tree map? 
 Am I doing everything correct till now?
 
 Thanks again for your help,
 Roby
 
 On Sep 20, 2013, at 11:24 AM, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I was playing around with Roassal (in particular, a tree map) and I have a 
 question: Is there a way to dynamically adding nodes? I mean, once the view 
 is generated to update the #nodes by adding a new node (and associations as 
 well, i.e., edges) and have the visualization re-
 
 Thanks in advance.
 
 Roby
 
 




[Pharo-dev] Dynamically adding nodes to Roassal

2013-09-20 Thread roberto.mine...@usi.ch
Hi,

I was playing around with Roassal (in particular, a tree map) and I have a 
question: Is there a way to dynamically adding nodes? I mean, once the view is 
generated to update the #nodes by adding a new node (and associations as well, 
i.e., edges) and have the visualization re-

Thanks in advance.

Roby


Re: [Pharo-dev] Dynamically adding nodes to Roassal

2013-09-20 Thread roberto.mine...@usi.ch
*and have the visualization re-layouted?

On Sep 20, 2013, at 11:24 AM, roberto.mine...@usi.ch roberto.mine...@usi.ch
 wrote:

 Hi,
 
 I was playing around with Roassal (in particular, a tree map) and I have a 
 question: Is there a way to dynamically adding nodes? I mean, once the view 
 is generated to update the #nodes by adding a new node (and associations as 
 well, i.e., edges) and have the visualization re-
 
 Thanks in advance.
 
 Roby




Re: [Pharo-dev] Dynamically adding nodes to Roassal

2013-09-20 Thread roberto.mine...@usi.ch
Thanks Alejandro, I will try what you propose!

What do you mean by
 Another thing bothering me is that you mentioned the method #nodes, thats 
 from the ROMondrianViewBuilder, which I think is not that friendly with 
 dynamic stuff.

How would you construct a view without using the ROMondrianViewBuilder? I am 
used to start as in the Roassal Easel like
rawView := ROView new.
view := ROMondrianViewBuilder view: rawView

And then adding nodes to the view, calling view nodes: myNodes

Cheers,
R



On Sep 20, 2013, at 1:49 PM, Alejandro Infante alejandroinfant...@gmail.com
 wrote:

 In Roassal calling the method #signalUpdate to the view should show those new 
 nodes. If you want to re-layout the nodes you should apply a new layout to 
 the nodes before the #signalUpdate.
 
 Another pretty interesting feature is the method ROContainercallback: 
 aCallback. The idea is that every time an element is added inside the 
 container the callback is called. 
 Now how you can use this:
 
 element callback: (ROContainerCallbackLayout new layout: (ROGridLayout new 
 gapSize: 2)). 
 
 Remember that you must send signalUpdate to the view if you want to see the 
 changes.
 
 Another thing bothering me is that you mentioned the method #nodes, thats 
 from the ROMondrianViewBuilder, which I think is not that friendly with 
 dynamic stuff.
 It is a little bit ugly but you can always get the ROView from 
 ROMondrianViewBuilder sending the message #view and over that do all kind of 
 Roassal magic stuff, like adding the callback with the TreeLayout the the 
 ROView itself. Also for adding new nodes you should add them directly to the 
 ROView, or at least I haven't found the way to do that without having to add 
 all the nodes again to the Builder.
 
 Hope that help you.
 
 
 2013/9/20 roberto.mine...@usi.ch roberto.mine...@usi.ch
 *and have the visualization re-layouted?
 
 On Sep 20, 2013, at 11:24 AM, roberto.mine...@usi.ch 
 roberto.mine...@usi.ch
  wrote:
 
  Hi,
 
  I was playing around with Roassal (in particular, a tree map) and I have a 
  question: Is there a way to dynamically adding nodes? I mean, once the view 
  is generated to update the #nodes by adding a new node (and associations as 
  well, i.e., edges) and have the visualization re-
 
  Thanks in advance.
 
  Roby
 
 
 




Re: [Pharo-dev] Dynamically adding nodes to Roassal

2013-09-20 Thread roberto.mine...@usi.ch
Thanks Alejandro,

Yes I went through the examples and I understood the difference between the 
examples using the builder (which are easier) and with pure Roassal, which 
are..let's say.. less user friendly..

I am trying, in pure Roassal, to do a tree map and add another node to the 
ROView then calling signalUpdate. No luck 'till now..

Cheers,
R

On Sep 20, 2013, at 3:01 PM, Alejandro Infante alejandroinfant...@gmail.com
 wrote:

 Well,
 If you started with the Easel then you must have seen the examples. Well at 
 first you see two boxes with examples inside (one on the top and the other 
 below (If you dont see the second one just drag the view). 
 
 The first one has a label at the top-left corner that says ROMondrianExample, 
 and this were done using the ROMondrianViewBuilder API, and you can see that 
 you interact mainly with the view variable.
 The second box is called ROExample and then you interact mainly with the 
 rawView variable which is pure Roassal.
 
 The difference between them is that the ROMondrianViewBuilder is a nice and 
 friendly API, but doing really complex stuff it's not possible. So we go one 
 level below to pure Roassal.
 
 Here you have the Collection class hierarchy in Roassal:
 |rawView|
   rawView := ROView new.
   Collection withAllSubclasses do: [ :c | 
   | el |
   el := ROBorder elementOn: c.
   el @ ROPopup.
   rawView add: el ].
 
   Draw edges
   rawView addAll: (ROEdge 
   buildEdgesFromElements: rawView elements 
   from:  [ :cls | cls superclass ]  
   to: #yourself 
   using: ROLine new).
   
   ROTreeLayout on: rawView elementsNotEdge edges: rawView elementsAsEdge.
   rawView open.
 
 I recommend you to see the ROExamples and if there is something that you 
 don't know just ask to the mailing list.
 You may like to see the ROExamplesinteractionsaddingOnClick example.
 
 
 2013/9/20 roberto.mine...@usi.ch roberto.mine...@usi.ch
 Thanks Alejandro, I will try what you propose!
 
 What do you mean by
  Another thing bothering me is that you mentioned the method #nodes, thats 
  from the ROMondrianViewBuilder, which I think is not that friendly with 
  dynamic stuff.
 
 How would you construct a view without using the ROMondrianViewBuilder? I am 
 used to start as in the Roassal Easel like
 rawView := ROView new.
 view := ROMondrianViewBuilder view: rawView
 
 And then adding nodes to the view, calling view nodes: myNodes
 
 Cheers,
 R
 
 
 
 On Sep 20, 2013, at 1:49 PM, Alejandro Infante alejandroinfant...@gmail.com
  wrote:
 
  In Roassal calling the method #signalUpdate to the view should show those 
  new nodes. If you want to re-layout the nodes you should apply a new layout 
  to the nodes before the #signalUpdate.
 
  Another pretty interesting feature is the method ROContainercallback: 
  aCallback. The idea is that every time an element is added inside the 
  container the callback is called.
  Now how you can use this:
 
  element callback: (ROContainerCallbackLayout new layout: (ROGridLayout new 
  gapSize: 2)).
 
  Remember that you must send signalUpdate to the view if you want to see the 
  changes.
 
  Another thing bothering me is that you mentioned the method #nodes, thats 
  from the ROMondrianViewBuilder, which I think is not that friendly with 
  dynamic stuff.
  It is a little bit ugly but you can always get the ROView from 
  ROMondrianViewBuilder sending the message #view and over that do all kind 
  of Roassal magic stuff, like adding the callback with the TreeLayout the 
  the ROView itself. Also for adding new nodes you should add them directly 
  to the ROView, or at least I haven't found the way to do that without 
  having to add all the nodes again to the Builder.
 
  Hope that help you.
 
 
  2013/9/20 roberto.mine...@usi.ch roberto.mine...@usi.ch
  *and have the visualization re-layouted?
 
  On Sep 20, 2013, at 11:24 AM, roberto.mine...@usi.ch 
  roberto.mine...@usi.ch
   wrote:
 
   Hi,
  
   I was playing around with Roassal (in particular, a tree map) and I have 
   a question: Is there a way to dynamically adding nodes? I mean, once the 
   view is generated to update the #nodes by adding a new node (and 
   associations as well, i.e., edges) and have the visualization re-
  
   Thanks in advance.
  
   Roby
 
 
 
 
 
 




Re: [Pharo-dev] Dynamically adding nodes to Roassal

2013-09-20 Thread roberto.mine...@usi.ch
I started yesterday to read the chapter. I bought the book at ESUG. :D


On Sep 20, 2013, at 3:13 PM, Alejandro Infante alejandroinfant...@gmail.com
 wrote:

 Also I forgot to tell you that the new book Deep into Pharo has a chapter 
 for Roassal and another for Mondrian.
 
 Maybe that's the best place to start from, the link of the book is 
 http://rmod.lille.inria.fr/pbe2/.
 
 
 2013/9/20 roberto.mine...@usi.ch roberto.mine...@usi.ch
 Thanks Alejandro,
 
 Yes I went through the examples and I understood the difference between the 
 examples using the builder (which are easier) and with pure Roassal, which 
 are..let's say.. less user friendly..
 
 I am trying, in pure Roassal, to do a tree map and add another node to the 
 ROView then calling signalUpdate. No luck 'till now..
 
 Cheers,
 R
 
 On Sep 20, 2013, at 3:01 PM, Alejandro Infante alejandroinfant...@gmail.com
  wrote:
 
  Well,
  If you started with the Easel then you must have seen the examples. Well at 
  first you see two boxes with examples inside (one on the top and the other 
  below (If you dont see the second one just drag the view).
 
  The first one has a label at the top-left corner that says 
  ROMondrianExample, and this were done using the ROMondrianViewBuilder API, 
  and you can see that you interact mainly with the view variable.
  The second box is called ROExample and then you interact mainly with the 
  rawView variable which is pure Roassal.
 
  The difference between them is that the ROMondrianViewBuilder is a nice and 
  friendly API, but doing really complex stuff it's not possible. So we go 
  one level below to pure Roassal.
 
  Here you have the Collection class hierarchy in Roassal:
  |rawView|
rawView := ROView new.
Collection withAllSubclasses do: [ :c |
| el |
el := ROBorder elementOn: c.
el @ ROPopup.
rawView add: el ].
 
Draw edges
rawView addAll: (ROEdge
buildEdgesFromElements: rawView elements
from:  [ :cls | cls superclass ]
to: #yourself
using: ROLine new).
 
ROTreeLayout on: rawView elementsNotEdge edges: rawView 
  elementsAsEdge.
rawView open.
 
  I recommend you to see the ROExamples and if there is something that you 
  don't know just ask to the mailing list.
  You may like to see the ROExamplesinteractionsaddingOnClick example.
 
 
  2013/9/20 roberto.mine...@usi.ch roberto.mine...@usi.ch
  Thanks Alejandro, I will try what you propose!
 
  What do you mean by
   Another thing bothering me is that you mentioned the method #nodes, thats 
   from the ROMondrianViewBuilder, which I think is not that friendly with 
   dynamic stuff.
 
  How would you construct a view without using the ROMondrianViewBuilder? I 
  am used to start as in the Roassal Easel like
  rawView := ROView new.
  view := ROMondrianViewBuilder view: rawView
 
  And then adding nodes to the view, calling view nodes: myNodes
 
  Cheers,
  R
 
 
 
  On Sep 20, 2013, at 1:49 PM, Alejandro Infante 
  alejandroinfant...@gmail.com
   wrote:
 
   In Roassal calling the method #signalUpdate to the view should show those 
   new nodes. If you want to re-layout the nodes you should apply a new 
   layout to the nodes before the #signalUpdate.
  
   Another pretty interesting feature is the method ROContainercallback: 
   aCallback. The idea is that every time an element is added inside the 
   container the callback is called.
   Now how you can use this:
  
   element callback: (ROContainerCallbackLayout new layout: (ROGridLayout 
   new gapSize: 2)).
  
   Remember that you must send signalUpdate to the view if you want to see 
   the changes.
  
   Another thing bothering me is that you mentioned the method #nodes, thats 
   from the ROMondrianViewBuilder, which I think is not that friendly with 
   dynamic stuff.
   It is a little bit ugly but you can always get the ROView from 
   ROMondrianViewBuilder sending the message #view and over that do all kind 
   of Roassal magic stuff, like adding the callback with the TreeLayout the 
   the ROView itself. Also for adding new nodes you should add them directly 
   to the ROView, or at least I haven't found the way to do that without 
   having to add all the nodes again to the Builder.
  
   Hope that help you.
  
  
   2013/9/20 roberto.mine...@usi.ch roberto.mine...@usi.ch
   *and have the visualization re-layouted?
  
   On Sep 20, 2013, at 11:24 AM, roberto.mine...@usi.ch 
   roberto.mine...@usi.ch
wrote:
  
Hi,
   
I was playing around with Roassal (in particular, a tree map) and I 
have a question: Is there a way to dynamically adding nodes? I mean, 
once the view is generated to update the #nodes by adding a new node 
(and associations as well, i.e., edges) and have the visualization re-
   
Thanks in advance

Re: [Pharo-dev] Dynamically adding nodes to Roassal

2013-09-20 Thread roberto.mine...@usi.ch
Thanks for the reference!

On Sep 20, 2013, at 3:02 PM, b...@openinworld.com wrote:

 Have a look at [1], section 5.6.2 LEKCimDynamicTreeLayout
 Note however that my project was based entirely on using raw ROView, rather 
 than ROMondrianViewBuilder.
 
 [1] 
 http://files.openinworld.com/LEKtrek/BenjaminTerrenceCOMAN-LEKtrek-2013-08-21.pdf




Re: [Pharo-dev] Dynamically adding nodes to Roassal

2013-09-20 Thread roberto.mine...@usi.ch
Hi, 

It's me again..

I managed to have something *almost* working, but the behavior of the 
ROTreeMapLayout is not clear to me.

Using the ROMondrianViewBuilder I can specify the size of the Tree map, but 
then I am not able to dynamically add nodes. Well, at least I did not manage to 
do that. So I moved to pure Roassal, as suggested by Alejandro.

Here's how my actual code looks like: http://ws.stfx.eu/CFM522Z9X3ES

I am a beginner with Roassal, so I spend some time to figure out how to draw 
the tree map in this way. I did not really quite understand why I have to add 
the ROBox new size: 200 to the ROElement, but I'll figure it out.

The thing is when I try to add the new node. Following, again, Alejandro's 
advice I am writing something like:

I add a new node, re-layout the view, and signalUpdate
rawView add: ((ROElement on: 10) + (ROBox new size: 200)).
(ROTreeMapLayout withWeightBlock: [ :e | e model ]) applyOn: rawView elements.
rawView signalUpdate .

The result is quite strange, the view is indeed updated but I cannot understand 
why all sizes are messed up.

My questions, in short are: How can I fix the overall size of the tree map? Am 
I doing everything correct till now?

Thanks again for your help,
Roby

On Sep 20, 2013, at 11:24 AM, roberto.mine...@usi.ch wrote:

 Hi,
 
 I was playing around with Roassal (in particular, a tree map) and I have a 
 question: Is there a way to dynamically adding nodes? I mean, once the view 
 is generated to update the #nodes by adding a new node (and associations as 
 well, i.e., edges) and have the visualization re-
 
 Thanks in advance.
 
 Roby




Re: [Pharo-dev] Create a Moose model a posteriori

2013-09-16 Thread roberto.mine...@usi.ch
Hi Guillermo,

On Sep 16, 2013, at 9:44 AM, Guillermo Polito guillermopol...@gmail.com wrote:

 Hey!
 
 On Mon, Sep 16, 2013 at 9:19 AM, roberto.mine...@usi.ch 
 roberto.mine...@usi.ch wrote:
 Hi,
 
 I was at ESUG last week and I discussed about this issue with some people, 
 and in the end Stef told me drop a mail in the mailing list, I am interested 
 to understand what all the other people think about it. So, here I am.
 
 I have my project in which I am modeling development sessions. Each session 
 object has a number of meta-data (e.g., start, end time, etc.) and a 
 collection of events. Each event object owns some meta-data and some 
 references to classes that were touched by a given event (i.e., now I am 
 using the Ring definition of the classes, since I plan to serialize and 
 deserialize them and I cannot serialize the real class object, it would be 
 too heavy, isn't it?).
 
 Serializing a class is not a big deal ;). With fuel you can even serialize 
 execution contexts, blocks and stuff. But (but but), I can tell your decision 
 is still good because during development you can end up removing a class, and 
 when that happens the system makes it obsolete and remove all its data.

Exactly the problem I run into.

 So if you were pointing to the real class, you would have problems to access 
 the class data afterwards. And since you use ring, you're ok ;).
 
 Cheers,
 Guille
  
 
 Now the question: I would like to create a Moose model of a development 
 session to be able to import the sessions in the Moose panel and play around 
 with the excellent Moose tool-suite. How should I proceed? Do you think it's 
 better to annotate and add pragmas to the existing classes or to create a 
 minimal parallel hierarchy of my model (i.e., MooseSession for MySession) and 
 have something like MySession#asMooseDef which returns an object of kind 
 MooseSession?

Any suggestion on this, Guillermo?

 
 Thanks in advance,
 Roberto
 




[Pharo-dev] Removing a package from Smalltalkhub

2013-05-21 Thread roberto.mine...@usi.ch
Hi,

I was wondering if and how can I delete a package from Smalltalkhub.

Thanks in avance,
R



Re: [Pharo-dev] Removing a package from Smalltalkhub

2013-05-21 Thread roberto.mine...@usi.ch
Awesome, thanks ;)

On May 21, 2013, at 3:21 PM, Nicolas Petton petton.nico...@gmail.com
 wrote:

 Hey!
 
 It will be there soon, Damien implemented the feature, I need to review it 
 before updating smalltalkhub :)
 
 Nico
 
 
 On May 21, 2013, at 2:52 PM, Roberto Minelli roberto.mine...@bluewin.ch 
 wrote:
 
 Hi,
 
 I was wondering if and how can I delete a package from Smalltalkhub.
 
 Thanks in avance,
 R
 
 
 --
 Nicolas Petton
 http://www.nicolas-petton.fr
 
 




[Pharo-dev] [Fuel] [FuelMetaLevel] Help

2013-05-21 Thread roberto.mine...@usi.ch
Hi,

I am using Fuel to serialize/deserialize some objects. As part as the objects I 
need to serialize there are some classes, class definitions (i.e., Ring) and 
some CompiledMethod.
It's not always the case that I serialize and materialize in the same image, 
thus sometimes I experience FLClassNotFound and FLMerthodChanged exceptions.

I discovered FuelMetaLevel, as far as I can understand, it can solve many 
problems. 
Now my questions are (1) am I correct that it can help? and (2) from which 
repository should I load FuelMetaLevel?

As far as I understood not Fuel is developed as part of Pharo so it's 
pre-installed in every fresh image. I tried to get FuelMetaLevel from ss3 (both 
Pharo20 and PharoInbox) but when I run 
FLSerializer newFull serialize: 'whatever' toFileNamed: 'whatever.fuel'

I got a MNU on 
FLFullGlobalMapper#initializeWithInternalBehaviors:internalMethods:globalSymbols:
  since the class FLGlobalAssociationCluster is not part of my image.

I'm attaching the stack trace of the error I'm getting.

Thanks in advance,
RM

 UndefinedObject(Object)doesNotUnderstand: #newAnalyzing
 FLFullGlobalMapperinitializeWithInternalBehaviors:internalMethods:globalSymbols:
 FLFullGlobalMapper 
 classnewWithInternalBehaviors:internalMethods:globalSymbols:
 FLAnalyzerfullGlobalMappers
 FLAnalyzeruseFullMappers in Block: [self fullGlobalMappers]
 FLAnalyzerglobalMappers
 FLAnalyzermappers
 FLAnalyzerfirstInMapperChain
 FLAnalyzersetDefaultAnalysis in Block: [:anObject | (FLAnalysis...
 FLAnalyzeranalysisFor:
 FLSerializationanalysisStep
 FLSerializationrun
 FLSerializersetDefaultSerialization in Block: [:anObject :anEncoder | 
 (FLSerialization...
 FLSerializerserialize:on: in Block: [:anEncoder | ...
 FLEncoder classon:globalEnvironment:do: in Block: [aBlock value: anEncoder]
 BlockClosureensure:
 FLEncoder classon:globalEnvironment:do:
 FLSerializerserialize:on:
 FLSerializerserialize:toFileNamed: in Block: [:aFileStream | ...
 StandardFileStream class(FileStream class)detectFile:do: in Block: 
 [anotherBlock value: file]
 BlockClosureensure:
 StandardFileStream class(FileStream class)detectFile:do:
 StandardFileStream class(FileStream class)forceNewFileNamed:do:
 FLSerializerserialize:toFileNamed:
 UndefinedObjectDoIt
 Compilerevaluate:in:to:notifying:ifFail:logged:
 SmalltalkEditorevaluateSelectionAndDo: in Block: [rcvr class evaluatorClass 
 new...
 BlockClosureon:do:
 SmalltalkEditorevaluateSelectionAndDo:
 SmalltalkEditorevaluateSelection
 



Re: [Pharo-dev] [Fuel] [FuelMetaLevel] Help

2013-05-21 Thread roberto.mine...@usi.ch
Thanks! I was not aware of a Fuel-dev mailing list.

Thanks,
R

On May 21, 2013, at 4:05 PM, Max Leske maxle...@gmail.com
 wrote:

 Forwarding to Fuel dev
 
 
 On 21.05.2013, at 16:00, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I am using Fuel to serialize/deserialize some objects. As part as the 
 objects I need to serialize there are some classes, class definitions (i.e., 
 Ring) and some CompiledMethod.
 It's not always the case that I serialize and materialize in the same image, 
 thus sometimes I experience FLClassNotFound and FLMerthodChanged exceptions.
 
 I discovered FuelMetaLevel, as far as I can understand, it can solve many 
 problems. 
 Now my questions are (1) am I correct that it can help? and (2) from which 
 repository should I load FuelMetaLevel?
 
 As far as I understood not Fuel is developed as part of Pharo so it's 
 pre-installed in every fresh image. I tried to get FuelMetaLevel from ss3 
 (both Pharo20 and PharoInbox) but when I run 
  FLSerializer newFull serialize: 'whatever' toFileNamed: 'whatever.fuel'
 
 I got a MNU on 
 FLFullGlobalMapper#initializeWithInternalBehaviors:internalMethods:globalSymbols:
   since the class FLGlobalAssociationCluster is not part of my image.
 
 I'm attaching the stack trace of the error I'm getting.
 
 Thanks in advance,
 RM
 
 UndefinedObject(Object)doesNotUnderstand: #newAnalyzing
 FLFullGlobalMapperinitializeWithInternalBehaviors:internalMethods:globalSymbols:
 FLFullGlobalMapper 
 classnewWithInternalBehaviors:internalMethods:globalSymbols:
 FLAnalyzerfullGlobalMappers
 FLAnalyzeruseFullMappers in Block: [self fullGlobalMappers]
 FLAnalyzerglobalMappers
 FLAnalyzermappers
 FLAnalyzerfirstInMapperChain
 FLAnalyzersetDefaultAnalysis in Block: [:anObject | (FLAnalysis...
 FLAnalyzeranalysisFor:
 FLSerializationanalysisStep
 FLSerializationrun
 FLSerializersetDefaultSerialization in Block: [:anObject :anEncoder | 
 (FLSerialization...
 FLSerializerserialize:on: in Block: [:anEncoder | ...
 FLEncoder classon:globalEnvironment:do: in Block: [aBlock value: 
 anEncoder]
 BlockClosureensure:
 FLEncoder classon:globalEnvironment:do:
 FLSerializerserialize:on:
 FLSerializerserialize:toFileNamed: in Block: [:aFileStream | ...
 StandardFileStream class(FileStream class)detectFile:do: in Block: 
 [anotherBlock value: file]
 BlockClosureensure:
 StandardFileStream class(FileStream class)detectFile:do:
 StandardFileStream class(FileStream class)forceNewFileNamed:do:
 FLSerializerserialize:toFileNamed:
 UndefinedObjectDoIt
 Compilerevaluate:in:to:notifying:ifFail:logged:
 SmalltalkEditorevaluateSelectionAndDo: in Block: [rcvr class 
 evaluatorClass new...
 BlockClosureon:do:
 SmalltalkEditorevaluateSelectionAndDo:
 SmalltalkEditorevaluateSelection
 
 
 
 




Re: [Pharo-dev] Removing a package from Smalltalkhub

2013-05-21 Thread roberto.mine...@usi.ch
Awesome, you guys are fast!

A nice to have would also be a rename package and rename project without having 
to create a new project and/or a new package since in this way you will loose 
the history..

Cheers,
R

On May 21, 2013, at 5:53 PM, Esteban Lorenzano esteba...@gmail.com wrote:

 you cannot, once you commited, your package belong to the universe :)
 
 nah, it is a known missing feature (and really needed), there is a fix coming 
 I think next week. 
 
 Esteban
 
 On May 21, 2013, at 2:53 PM, roberto.mine...@usi.ch wrote:
 
 Hi,
 
 I was wondering if and how can I delete a package from Smalltalkhub.
 
 Thanks in avance,
 R