October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] Slides of my Lecture this morning..

by Sven Van Caekenberghe

On 29 Oct 2013, at 13:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 29 Oct 2013, at 13:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Thanks for sharing, Marcus, I really appreciate this. >> >> It is cool to know that we have already slots under the hood, and that much more application are on their way. >> > > Slot allInstances size > > ==> 7128 > > :-) > > Marcus And nobody ever noticed !

Oct. 29, 2013

Re: [Pharo-dev] [Pharo-users] Slides of my Lecture this morning..

by Marcus Denker

On 29 Oct 2013, at 13:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Thanks for sharing, Marcus, I really appreciate this. > > It is cool to know that we have already slots under the hood, and that much more application are on their way. > Slot allInstances size ==> 7128 :-) Marcus

Oct. 29, 2013

Re: [Pharo-dev] [Pharo-users] Slides of my Lecture this morning..

by Sven Van Caekenberghe

Thanks for sharing, Marcus, I really appreciate this. It is cool to know that we have already slots under the hood, and that much more application are on their way. Sven On 29 Oct 2013, at 13:02, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > I am just visiting Jordi Delgado in Barcelona and I gave a lecture in his course this morning. > âAdvanced Reflection in Pharoâ, this is meant to be a lecture after an introduction to standard > Smalltalk reflection. > > SlideShare > http://www.slideshare.net/MarcusDenker/lecture-27685035 > > PDF > http://marcusdenker.de/talks/13BarcelonaLecture/ > > > Marcus

Oct. 29, 2013

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

by Mariano Martinez Peck

On Tue, Oct 29, 2013 at 6:53 AM, roberto.minelli(a)usi.ch < roberto.minelli(a)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. Then at materialization it should search that class name in the SmalltalkDictionary and get that. 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. Cheers, > Thanks a lot for the support, > Roby > > On Oct 29, 2013, at 8:03 AM, roberto.minelli(a)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 < > marianopeck(a)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 <maxleske(a)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 <tinchodias(a)gmail.com> wrote: > >> > >>> > >>> > >>> > >>> On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli(a)usi.ch < > roberto.minelli(a)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 <tinchodias(a)gmail.com> wrote: > >>> > >>>> > >>>> > >>>> > >>>> On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli(a)usi.ch < > roberto.minelli(a)usi.ch> wrote: > >>>> Thanks, > >>>> > >>>> On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias(a)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

Oct. 29, 2013

Re: [Pharo-dev] Unwind error during termination

by ClÃ©ment Bera

(Igor speaking with Clement) Another, tangent. I feel extremely wrong with given piece of code (however it works): [ ^ 2 ] ensure: [ ^ 5 ] my point, that you cannot return from same context twice, and what happens here is really weird. Or even more weird: [ ^ 2 ] ifCurtailed: [ ^ 5 ] or imagine more abstract case: someBlock ifCurtailed: [ ^ 5 ] The someBlock can belong to other context (like the caller context), and if evaluating it leads to non-local return, it must continue execution from the sender context of its home context. But alas, our ifCurtailed block thinks otherwise and intercepts that.. and does own non-local return to possibly alredy unwinded portion of stack.. I feel there's something extremely wrong with that :) We changed the #resume:through: method to catch that: unwindBlock ifCurtailed: [ self error: 'cannot resume execution due to curtailing' ] instead of: unwindBlock value i am, however don't really know what is the least surprising behavior for such situation. 2013/10/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > If I remember correctly andreas wrote the tests. > I always like them. > > Stef > > > The author of the test is Andreas Raab, but I'm not sure who found it > (excavating mailing list is hard work) > > > 2013/10/25 Igor Stasenko <siguctua(a)gmail.com> > >> >> >> >> On 25 October 2013 00:26, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> Hard to debug this kind of code :( >>> This is reproducible on Squeak wiht on:do:, so on:fork: bizareness >>> apart, this is another flaw in exception handling, along with wrong handler >>> for nested exception (testHandlerFromAction below), unless it's an avatar. >>> >>> Still, I do not see how you get the errorSubscriptBound:... >>> In Squeak that would mean that you sent #handleSignal: to a not >>> isHandlerContext ContextPart... >>> I never saw this, but if Eliot says so... >>> >>> >>> >>> ExceptionTests>>testHandlerFromAction >>> "A test ensuring that nested exceptions work as expected." >>> >>> | result | >>> result := [ >>> [ >>> [self error: 'trigger error'] on: ZeroDivide do: [ :ex | >>> 'inner' ] >>> ] on: Error do: [ :ex | 3 / 0 ] >>> ] on: ZeroDivide do: [ :ex | 'outer' ]. >>> self assert: 'outer' equals: result description: 'Incorrect handler'. >>> >>> good find :) >> >> https://pharo.fogbugz.com/f/cases/11996/Wrong-exception-handler-problem >> >> >>> >>> >>> 2013/10/24 Igor Stasenko <siguctua(a)gmail.com> >>> >>>> >>>> ok, it seems i found how to reproduce the situation with following: >>>> >>>> [ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ] >>>> >>>> you will get halt, and if you close the debugger , it will throw unwind >>>> error. >>>> (while instead it should throw DNU) >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > >

Oct. 29, 2013

Slides of my Lecture this morning..

by Marcus Denker

Hi, I am just visiting Jordi Delgado in Barcelona and I gave a lecture in his course this morning. âAdvanced Reflection in Pharoâ, this is meant to be a lecture after an introduction to standard Smalltalk reflection. SlideShare http://www.slideshare.net/MarcusDenker/lecture-27685035 PDF http://marcusdenker.de/talks/13BarcelonaLecture/ Marcus

Oct. 29, 2013

Re: [Pharo-dev] Tests with multiple processes

by Norbert Hartl

Am 29.10.2013 um 02:08 schrieb David T. Lewis <lewis(a)mail.msen.com>: > I have some experience with this, not related to Smalltalk but maybe > still relevant. I have worked with systems that were designed around > networked message passing, implemented on platforms like MS-DOS with time > slicing kernels, Series I, OS/2, etc. These systems were designed to operate > with asynchronous message passing protocols. The asynchronous designs were > intended to support primitive OS environments, including MS-DOS with > software interrupts for multitasking. > > These are production-critical manufacturing applications, and in the course > of modernizing them I have reimplemented the network protocols in Java and > moved them to new computing platforms. Along the way I have found that the > asynchronous designs could always be replaced by bidirectional send-receive > transactions running in the context of a thread or process. Even the systems > that appeared to be most complex have turned out to work perfectly well > when modeled as synchronous send-receive transactions on a bidirectional > communication channel. The software is much simpler to understand and debug > when structured in this manner. > > My conclusion is that designing around asynchronous, loosely coupled > channels sounds like a good idea, but in practice it leads to unnecessary > complexity, and to systems that are difficult to debug and support. > I agree. That was the reason for me to look out for a simpler approach. At least for testing. Can you elaborate on the âbidirectional send-receive transactionâ. Iâm not sure I understand what happens there. I explained my case a bit more in my response to Igor. thanks, Norbert > $0.02 > > Dave > > > On Tue, Oct 29, 2013 at 01:19:17AM +0100, Igor Stasenko wrote: >> Maybe i'm off track, but here my thoughts: >> >> - one big misconception (and most problems which arising from it), that >> people tend to use a bidirectional communication models instead of >> unidirectional. >> In bidirectional you tend to think as if you using same channel for sending >> and receiving data. >> The truth is, that it is two unidirectional channels, wired in the way so >> they look like single bidirectional channel. >> >> And what it means, that coupling sending and receiving activities in a >> single thread is wrong: >> - you should not wait for data only if you sent something >> - you should not expect that activity from other end is possible only >> after you _send_ something. >> >> If you treat connection as two unidirectional, loosely coupled channels, >> instead of single bidirectional one, >> you will find that in such setup you don't have many problems. >> >> You should definitely go for (2), e.g. you should decouple a >> transport/communication layer >> from your program/logic flow: if some process wants to send data and block >> until some response to >> that message arrived, you should do so. >> You can simply put that process on semaphore, and adding it to the list of >> 'awaiting answer' >> processes in your scheduler which runs in separate process to handle >> incoming data. >> Then you can have different strategies, what to do if >> a) data seems taking too long to arrive (signal timeout) >> b) connection lost >> c) etc.. >> >> ohh.. with smalltalk it is so easy to operate with those things (the fact >> the VM is green-threaded doesn't >> changes much). >> >> >> >> On 28 October 2013 23:52, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> >>> Am 28.10.2013 um 23:50 schrieb Norbert Hartl <norbert(a)hartl.name>: >>> >>> Are there any approaches to simulate coroutines in a single thread >>> environment or approaches to deal with multiple processes within one >>> process? >>> >>> >>> That should have been >>> >>> Are there any approaches to simulate coroutines in a single thread >>> environment or approaches to deal with multiple processes within one test? >>> >>> Norbert >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >

Oct. 29, 2013

Re: [Pharo-dev] Tests with multiple processes

by Norbert Hartl

Igor, it seems I did a terrible job explaining it. Comments inline! Am 29.10.2013 um 01:19 schrieb Igor Stasenko <siguctua(a)gmail.com>: > Maybe i'm off track, but here my thoughts: > > - one big misconception (and most problems which arising from it), that people tend to use a bidirectional communication models instead of unidirectional. > In bidirectional you tend to think as if you using same channel for sending and receiving data. > The truth is, that it is two unidirectional channels, wired in the way so they look like single bidirectional channel. > > And what it means, that coupling sending and receiving activities in a single thread is wrong: > - you should not wait for data only if you sent something > - you should not expect that activity from other end is possible only after you _send_ something. > > If you treat connection as two unidirectional, loosely coupled channels, instead of single bidirectional one, > you will find that in such setup you don't have many problems. I donât know what gave you the impression it could be that way but it isnât. There is a component called NetworkService that Iâm using to do sends and where Iâm registering for incoming messages. I was not talking about the architecture of the application but about ways how to test those setups. For this I have a TestNetworkService that has an instVar otherService. On connection time the NetworkServices set themself via a setter in the other service and a send is done like send: someData otherService doReceive: someData This is the place where I change the execution model for the tests. What would be normally something asynchronous is now synchronous with the mentioned side effect that a send with response will look like A send1 B receive1 B send2 A receive2 A return from receive2 B return from send2 B return from receive1 A return from send1 I really like the tests to be single threaded. It makes debugging a lot easier. So I was evaluating a few possibilities. As long as all of the calls in the above chain are tail calls it should be the same of the calls are nested or not. But that would be a restriction and Iâm not sure yet if it is a good one or not. The next approach I do at the moment is that e.g. a send call goes roughly like this p := [ a block for preparing send data ] s := [ a block that sends the data ] s value: p value What I do is to rearrange flow. At the moment where s would be evaluated it is instead made the sender of p and the sender of s will be the former sender of p. So everything that happens in p will return before s is executed. For my execution model this mimicks parallel behaviour. But now the receive/sends are nested and my simple model doesnât work. I could improve it but it seems like I need to tweak a tweak of a workaround that probably wasnât the right choice in the first place. What my experience showed me is that often it is a good way to remove a hack instead of hacking a hack. So Iâm thinking about if this is the point to let go :) > You should definitely go for (2), e.g. you should decouple a transport/communication layer > from your program/logic flow: if some process wants to send data and block until some response to > that message arrived, you should do so. > You can simply put that process on semaphore, and adding it to the list of 'awaiting answer' > processes in your scheduler which runs in separate process to handle incoming data. > Then you can have different strategies, what to do if > a) data seems taking too long to arrive (signal timeout) > b) connection lost > c) etc.. > > ohh.. with smalltalk it is so easy to operate with those things (the fact the VM is green-threaded doesn't > changes much). > As I said the layers are separate. So one idea was to keep it in multiple processes and use semaphores for orchestration. I need to think about that because I donât have an immediate idea how this should be done. I mean the dispatcher/scheduler does the orchestration of the processes but I would need to make use of this inside a test. Need to think about that. Norbert > > > On 28 October 2013 23:52, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 28.10.2013 um 23:50 schrieb Norbert Hartl <norbert(a)hartl.name>: > >> Are there any approaches to simulate coroutines in a single thread environment or approaches to deal with multiple processes within one process? > > That should have been > > Are there any approaches to simulate coroutines in a single thread environment or approaches to deal with multiple processes within one test? > > Norbert > > > > -- > Best regards, > Igor Stasenko.

Oct. 29, 2013

Re: [Pharo-dev] [pharo-project/pharo-core] a20ada: 30532

by Marcus Denker

On 29 Oct 2013, at 11:37, GitHub <noreply(a)github.com> wrote: > Branch: refs/heads/3.0 > Home: https://github.com/pharo-project/pharo-core > Commit: a20adab058f13ca9dff1c6cc5ee92be5b5fc3c9d > https://github.com/pharo-project/pharo-core/commit/a20adab058f13ca9dff1c6cc… The link above goes to page with diffs (can be easily missed). Marcus

Oct. 29, 2013

Re: [Pharo-dev] Hungry Pharo

by Nicolas Cellier

The conclusion is: more work is required on both sides, VM and image. 2013/10/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > A greater than, say, 1% base CPU load from an otherwise idle application > would indicate that it's doing some busy waiting somewhere... in my > Activity Monitor, I don't see too many processes doing that, so just using > an ObjC framework doesn't seem to be the guilty part. By the way, very old > versions of VisualWorks used to be bad in that way, but not any more; so > there is something that can be done about it. > > if I'm correct there are some busy waiting process in the VM instead of an > event based + semaphore architecture. > We already removed some of the polling behavior at the image level but > there are probably more and there was a discussion in the > VM mailing list. Now I do not know the conclusion. > > > A large virtual memory working set wouldn't help either for power > efficiency, though with today's RAM sizes it's probably less important. > > > >

Oct. 29, 2013