- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About BitBlt current -> BitBlt (Fuel)

by Max Leske

Thanks Mariano, Iâll look at that. On 29.10.2013, at 15:39, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Max, we use a primitive from BitBtl to perform writing of word-like instances (Bitmaps etc). It makes writing word objects way faster. > Check the method #copyWordObjectToBuffer: aWordObject and its senders. > > Cheers, > > > > On Tue, Oct 29, 2013 at 6:55 AM, Max Leske <maxleske(a)gmail.com> wrote: > Stef, what exactly is the influence on Fuel? I looked at the changes of your slice and couldnât find anythingâ¦ > > Max > > > On 25.10.2013, at 16:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > Hi > > > > I just pushed a change cleaning some strange usage. > > BitBlt was sometimes invoked via BitBlt current (which just returned the BitBlt class). > > Apparently in Squeak they removed it too. > > > > Now it touches Fuel so Fuel guys can you merge on your side too? > > > > https://pharo.fogbugz.com/f/cases/12009/BitBlt-current-BitBlt > > > > Stef > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Oct. 29, 2013

Re: [Pharo-dev] Tests with multiple processes

by David T. Lewis

> > 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. > I modeled the problem in terms of communication sessions, with message objects that can be sent and received on a session. By ÂtransactionÂ (poor choice of terms here) I mean an object with an evaluate method that uses a session to send a message object and receive a response message object, and that answers an object that encapsulates the result of that completed transaction (including errors if any). Early in the project I implemented a kind of ÂsessionÂ that handled asynchronous send and receive, keeping track of thread synchronization and matching response objects to request objects. I expected this to be necessary for interaction with old MS-DOS and OS/2 based applications that had been written in that manner, and that were entirely asynchronous and interrupt driven by design. I practice, I have never actually needed to use this asynchronous type of processing, because the simple synchronous session has always been proved sufficient even when interacting with systems that appeared to be (and were designed to be) completely asynchronous and event driven.

Oct. 29, 2013

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

by roberto.minelli＠usi.ch

On Oct 29, 2013, at 3:41 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > On Tue, Oct 29, 2013 at 11:37 AM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: > Hi Mariano, > > On Oct 29, 2013, at 1:35 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > 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. > > 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.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 > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Oct. 29, 2013

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

by Marcus Denker

On 29 Oct 2013, at 14:02, Martin Dias <tinchodias(a)gmail.com> wrote: > And even the class Slot could be compact (it's not right now) > Yes, that is easy to do and costs nothing. Protocol should be compact, too. I will do that. Marcus > > On Tue, Oct 29, 2013 at 1:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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] inria ci problem - content encoding error when clicking 'new job' in JobTemplate page

by Camillo Bruni

I just tried and I get a normal page to create a new job. I am using Chrome under OSX. On 2013-10-28, at 17:53, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Hi - > > > After logging in, when I visit this page: > > https://ci.inria.fr/pharo-contribution/view/all/newJob > > I get a 'content encoding error' and nothing is displayed in the browser. > > > Is there another way to create a job? > > > Thanks > > Paul >

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 11:37 AM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Hi Mariano, > > On Oct 29, 2013, at 1:35 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > 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. > > Nope, trust me it serialized the whole class. > > So that is a bug. Do you have a reproducible test case? > > 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.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 > > > -- Mariano http://marianopeck.wordpress.com

Oct. 29, 2013

Re: [Pharo-dev] Tests with multiple processes

by Igor Stasenko

On 29 October 2013 02:08, David T. Lewis <lewis(a)mail.msen.com> wrote: > 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. > > $0.02 > > Dave > Example from my life: real-time voice over IP project. >From very starting, it was designed as a bidirectional connection between two peers. Even though, that outgoing/incoming traffic was handled separately, the model was still there and treated as 'single conversation channel'. Later we wanted to introduce many-peer conversation and found that the above bi-directional model simply does not fits.. everything falls apart. Simple example: you have 3 peers A, B , C. So, you can represent is in this way: A<->B , A<->C , B<->C, or this: A -> (B,C) B -> (A, C) C -> (A,B) The bidirectional model implies that you have symmetry in number of outgoing and incoming channels (hence <->).. and if you send data over one of them, only single node will receive it. Logically, that leads to sending same data to two different channels. So, at very beginning you nailing down how the traffic is going to flow. With unidirectional model, as illustrated when you sending data over one channel, it will be delivered to all participants, and you don't have to do it yourself - the transport layer handles it for you. The thing is, that the way how data gets to receivers is heavily depends on network topology: imagine that two peers, B, C belong to same subnet, and latency between them is miniscule comparing to latency between A and one of them. The logical choice then should be to route the signal from A to either B or C and then broadcast from middle point to the listener which is left. Not possible with bidirectional model, because A insists on having direct socket connection with both B and C. Same goes for proxies: imagine that node A is connected via proxy.. and not directly to nodes B and C.. that means that to deliver its voice traffic to both of them it should just send a single packet to proxy, and then proxy will broadcast it to listeners. Not going to happen with bidirectional model, A will still send two very same packets to same proxy.. but with different destination address. Or even, it could be, that receiving traffic from A to C goes faster via B, while sending traffic from C to A is faster to do directly.. So try to fit that into bidirectional model of communication and see where it goes. Yes, i agree it is easier to put everything into sequential bidirectional model which makes everything so simple. If it fits. But if its not, you should not even try to fit it.. My point is, that IP is inherently asynchronous and unidirectional. -- Best regards, Igor Stasenko.

Oct. 29, 2013

Re: [Pharo-dev] About BitBlt current -> BitBlt (Fuel)

by Mariano Martinez Peck

Max, we use a primitive from BitBtl to perform writing of word-like instances (Bitmaps etc). It makes writing word objects way faster. Check the method #copyWordObjectToBuffer: aWordObject and its senders. Cheers, On Tue, Oct 29, 2013 at 6:55 AM, Max Leske <maxleske(a)gmail.com> wrote: > Stef, what exactly is the influence on Fuel? I looked at the changes of > your slice and couldnât find anythingâ¦ > > Max > > > On 25.10.2013, at 16:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Hi > > > > I just pushed a change cleaning some strange usage. > > BitBlt was sometimes invoked via BitBlt current (which just returned the > BitBlt class). > > Apparently in Squeak they removed it too. > > > > Now it touches Fuel so Fuel guys can you merge on your side too? > > > > https://pharo.fogbugz.com/f/cases/12009/BitBlt-current-BitBlt > > > > Stef > > > -- Mariano http://marianopeck.wordpress.com

Oct. 29, 2013

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

by roberto.minelli＠usi.ch

Hi Mariano, On Oct 29, 2013, at 1:35 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > 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. 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.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] inria ci problem - content encoding error when clicking 'new job' in JobTemplate page

by Paul DeBruicker

Is this error happening because my user is neither an Admin nor a Slave Admin and therefore I cannot create jobs? Thanks Paul Paul DeBruicker wrote > Hi - > > > After logging in, when I visit this page: > > https://ci.inria.fr/pharo-contribution/view/all/newJob > > I get a 'content encoding error' and nothing is displayed in the browser. > > > Is there another way to create a job? > > > Thanks > > Paul -- View this message in context: http://forum.world.st/inria-ci-problem-content-encoding-error-when-clicking… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 29, 2013