- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Are there still halos in Pharo 3.0?

by Esteban Lorenzano

yes. alt+shift works for me (in osx) On Oct 28, 2013, at 9:11 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I tried various key combinations with mouse click but no one worked... > > in Morph>>handleMouseDown: > it seems like this block never fires: > anEvent blueButtonChanged ifTrue:[^self blueButtonDown: anEvent]. > > Is it still possible to have these halos?

Oct. 29, 2013

Are there still halos in Pharo 3.0?

by Nicolas Cellier

I tried various key combinations with mouse click but no one worked... in Morph>>handleMouseDown: it seems like this block never fires: anEvent blueButtonChanged ifTrue:[^self blueButtonDown: anEvent]. Is it still possible to have these halos?

Oct. 29, 2013

Re: [Pharo-dev] Tests with multiple processes

by Sebastian Sastre

you can do stuff like that, just not sync (which when it's about networks is a good idea) sounds like you should design things javascript style. I mean, like if "everything" is a callback reacting to something.. yourAPIClient sendCommand: aCommand do: aBlockHandlingResponse my 2 cents On Oct 28, 2013, at 8:50 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Iâm working on project that deals with server to server communication. For the test suite it is necessary to simulate the two ends of the communication within one test. The problem is that in a single threaded environment you make a send call SC from server A to B but the response of B will happen before SC returned. That makes every state change the happens in A after SC bogus from a call flow perspective. > > There are two approaches that have their own problems. > > 1) Until now Iâm reordering parts of the call stack to simulate the return of a call before the actual call is sent. But now I have nested sends that make my simple approach not working anymore. I could elaborate my approach by using something like delimited continuations to make a less brittle approach to stack call reordering in order to cope with the problem. That would need some work and the stack in the debugger will look a little bit odd/confusing. > > 2.) The product will later have a dispatcher process that dispatches each send operation in its own process. That would solve one problem: the timing of when actions happen. But Iâm not sure if it will be easy to orchestrate actions in a way that I would call controlled in order to have reliable tests. > > Are there any approaches to simulate coroutines in a single thread environment or approaches to deal with multiple processes within one process? > > It is hard to explain and I hope my description of the problem is understandable > > thanks in advance, > > Norbert

Oct. 29, 2013

Re: [Pharo-dev] Tests with multiple processes

by Norbert Hartl

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

Oct. 28, 2013

Tests with multiple processes

by Norbert Hartl

Iâm working on project that deals with server to server communication. For the test suite it is necessary to simulate the two ends of the communication within one test. The problem is that in a single threaded environment you make a send call SC from server A to B but the response of B will happen before SC returned. That makes every state change the happens in A after SC bogus from a call flow perspective. There are two approaches that have their own problems. 1) Until now Iâm reordering parts of the call stack to simulate the return of a call before the actual call is sent. But now I have nested sends that make my simple approach not working anymore. I could elaborate my approach by using something like delimited continuations to make a less brittle approach to stack call reordering in order to cope with the problem. That would need some work and the stack in the debugger will look a little bit odd/confusing. 2.) The product will later have a dispatcher process that dispatches each send operation in its own process. That would solve one problem: the timing of when actions happen. But Iâm not sure if it will be easy to orchestrate actions in a way that I would call controlled in order to have reliable tests. Are there any approaches to simulate coroutines in a single thread environment or approaches to deal with multiple processes within one process? It is hard to explain and I hope my description of the problem is understandable thanks in advance, Norbert

Oct. 28, 2013

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

by Mariano Martinez Peck

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

Oct. 28, 2013

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

by Max Leske

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? > > > > > > >

Oct. 28, 2013

Re: [Pharo-dev] SmalltalkHub red

by Nicolas Petton

Yes, we need to look at this issue. I'll do that when I'll be back from Argentina in a week or so. Nico Manfred KrÃ¶hnert writes: > Hi everyone, > > are there any news on this issue? > I tried to load SmalltalkHub into a new Pharo 2.0 image yesterday and was > hit by this. > > Best, > Manfred > > > > > On Wed, Oct 9, 2013 at 9:33 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Yes, running the Grease/Seaside tests works fine. But, you will only see >> the "packages" problems when you do something with packages. So you will >> have to trigger RPackage tests to notice the issue. >> >> After all, you spotted the issue by running the Pharo regression tests >> after loading Moose/Grease/Seaside. >> >> Doru >> >> >> On Wed, Oct 9, 2013 at 9:28 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: >> >>> so is seaside: https://ci.inria.fr/pharo-contribution/job/Seaside/ >>> >>> On 2013-10-09, at 17:48, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>> > On Wed, Oct 9, 2013 at 4:47 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> wrote: >>> >> Do you know who is working with grease? It doesn't sound too hard to >>> solve this. >>> > >>> > >>> > and Grease seems to be ok: >>> https://ci.inria.fr/pharo-contribution/job/Grease/ >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> -- Nicolas Petton http://nicolas-petton.fr

Oct. 28, 2013

Re: [Pharo-dev] About SqNumberParser

by Chris Cunningham

I just used the parsing of a number like this: -1.2e+3 just a scant 15 minutes ago, so I appreciate the support. -cbc On Mon, Oct 28, 2013 at 11:46 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Concerning FORTRAN, I think it was removed for a long time, it was just an > example of how the NumberParser could be used. > Concerning the ExtendedNumberParser, I find it useful to have it, because > it can parse inputs like: > +1.4 > -1.2e+3 > .005 > 127.e6 > A lot of languages/applications around the world would accept these as > valid Number. > Smalltalk syntax is much stricter... > > OK, it's just a DSL, and it could as well be implemented by other means... > Whether such DSL implementation belongs to NumberParser hierarchy or not, > is a choice that was guided by 2 things > - NumberParser provides an implementation that will correctly round the > number to nearest Float (or ScaledDecimal eventually) > I've seen too many Smalltalk implementations departing from universal > standards with this respect (IOW, wrong) > - NumerParser tries to be efficient (as far as Smalltalk can be), > especially in the cases with many digits > The first point is mandatory. > The second is just an optimization. > > Now that you have more insight about rationale which guided those > decisions, it's up to you :) > > Cheers > > Nicolas > > > > 2013/10/28 Marcus Denker <marcus.denker(a)inria.fr> > >> >> On 28 Oct 2013, at 17:55, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> >> On 28 Oct 2013, at 17:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> So what we decide to do with this? >> >> I can work on that case, but I have 2 questions: >> >> - do we care to provide parsing of numbers in other notations as Pharo >> one? >> >> >> Thatâs a good question.. I completely misunderstood the code there >> because that sounds a bit >> strange that a language supports other languages syntax, but not âinsideâ >> the language but somehow as a toolâ¦ >> >> I fear that even if someone needs Fotran number parsing, the last place >> to look would be the Pharo base kernel >> classesâ¦ >> >> >> There are 2 extremes here. If you want to parse a fortran number, you >> probably also want to parse other fortran parts, and so you have some >> dedicated parser. >> But if you want to just parse some general number and itâs +2, then you >> canât easily do that. >> >> >> - what is the number syntax that we want to support? >> >> Yes, we we need to document it. Right now it is âsome extended Squeak >> formatâ which is just defined by the implementation. >> >> >> I can levee the implementation that is used now (a sq one). Or use >> extended. But it should be really nice to think about what we want to have >> instead of what we can use. >> >> >> If we have to decide, we should take the simple path. The fact that I am >> completely confused about this is not a good sign (maybe more related to my >> intelligenceâ¦ :-) >> >> Marcus >> >> >

Oct. 28, 2013

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

by Martin Dias

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? > > > > > > >

Oct. 28, 2013