[Pharo-dev] [Reflectivity] What are the #arguments?
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?
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
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
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
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
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
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
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 Denkerwrote: > > >> 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
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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?
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
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?
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?
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
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
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
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
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
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
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
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
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?
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
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
:’(
Re: [Pharo-dev] SmalltalkHub is down
Apparently is back up again ;) On Nov 8, 2013, at 10:11 AM, roberto.mine...@usi.ch wrote: :’(
[Pharo-dev] Menu enabled not refreshing
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
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?
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?
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?
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?
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?
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?
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?
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?
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 ?
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...
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
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
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
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
*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
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
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
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
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
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
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
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
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
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
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
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