August 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Has someone ever built a "sort block generator"

by Esteban A. Maringolo

Y asked for the same thing a few days ago in http://forum.world.st/Multiple-sorting-helper-td4770613.html Something like: sorter := MultipleSortCriteria new add: #lastName; add: [:each | each personalInfo age ] ascending: false. aCollection asSortedCollection: sorter. you could add something like: sorter := MultipleSortCriteria new add: #lastName; add: #firstName ascending: false nullsFirst: true. aCollection asSortedCollection: sorter. Regards! Esteban A. Maringolo 2014-08-01 2:40 GMT-03:00 Damien Cassou <damien.cassou(a)gmail.com>: > On Thu, Jul 31, 2014 at 10:50 PM, stepharo <stepharo(a)free.fr> wrote: > > what are you doing? > > > I think Mariano would like something like this: > > persons sorted: #(lastname firstname birthdate) asSortBlock > > that would sort by lastname, and if lastnames are equal by firstnames > and if both lastnames and firstnames are equal by birthdate. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

Aug. 1, 2014

Re: [Pharo-dev] Strange behavior of blocks

by Henrik Johansen

On 01 Aug 2014, at 3:20 , Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Dear all, > > using Sci-Smalltalk, we found with Natalia that sometimes blocks have > strange behavior : > https://groups.google.com/forum/#!topic/scismalltalk/HmGpTkzLOdQ > > I was able to create a more simpler example using only Pharo. > If you try, the following expression, there is no problem: > > |state values | > values := (1 to: 10000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 10000) do:[:i | (values at:i) at:2]. > > and you do more iterations, an error appears (Instances of > SmallInteger are not indexable), > because from time to time, an array is replaced by an integer: > > |state values | > values := (1 to: 100000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > and if you move the state variable inside the block, it works again : > > | values | > values := (1 to: 100000) collect: [ : t| |state| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > Same problem in Pharo 3.0 or Pharo 4.0 > > Regards, Speaking of which, when trying to inspect the array, itâs incredibly slowâ¦ The main reason for this? BasicIndexedEyeElement >> hash ^super hash bitXor: index hash The super implementation? AbstractEyeElement >> hash ^host hash Guess what the host of an indexedEyeElement is? Thatâs right, the collectionâ¦ So every time it tries to find the cached icon of a line (which is, 10-20 times per refresh cycle depending on the view), it iterates through the 100000 element array to calculate its hashâ¦ Iâd recommend either removing the super call from BasicIndexedEyeElement, or tell the AbstractEyeElement to use the identityHash of its host instead. Bonus: It also invokes a #DNU hander every time, since DictionaryValueHolder >> at:ifAbsentPut: is implemented self at: key ifAbsent: []. instead of value at: key ifAbsent: []. Code quality progress. Yay. Cheers, Henry

Aug. 1, 2014

Re: [Pharo-dev] Floating point literals in debugger

by Sven Van Caekenberghe

Note that inspecting her expression does work, it is the debugging that fails (I am not sure why you would want to that). Pharo does answer whole numbers from scientific notation if it can (try 1e6 for example), I think that is cool (maintaining maximum precision). You can always do #asFloat if you want. So the calculation is correct 1 - 1e-6 or 1 - 1/1000000 which equals 999999/1000000 On 01 Aug 2014, at 15:40, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Yes, I see also the same problem. > > I didn't realize until now that : 1-1e-6 > is printed as a fraction (try print-it): > (999999/1000000) > > A little bit strange, no ? > > On Fri, Aug 1, 2014 at 3:05 PM, Natalia Tymchuk > <natalia.tymchuk(a)unikernel.net> wrote: >> Hello. >> When I have the following expression >> {1-1e-6. 1e-6. 0} >> in the code and then I debug it I get >> {(1 - '<an unprintable nonliteral value>'). >> '<an unprintable nonliteral value>'. >> 0}. >> >> Is it a known problem or should I report an issue on debug tracker? >> >> Best regards, >> Natalia >> > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

Aug. 1, 2014

Re: [Pharo-dev] Floating point literals in debugger

by Serge Stinckwich

Yes, I see also the same problem. I didn't realize until now that : 1-1e-6 is printed as a fraction (try print-it): (999999/1000000) A little bit strange, no ? On Fri, Aug 1, 2014 at 3:05 PM, Natalia Tymchuk <natalia.tymchuk(a)unikernel.net> wrote: > Hello. > When I have the following expression > {1-1e-6. 1e-6. 0} > in the code and then I debug it I get > {(1 - '<an unprintable nonliteral value>'). > '<an unprintable nonliteral value>'. > 0}. > > Is it a known problem or should I report an issue on debug tracker? > > Best regards, > Natalia > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 1, 2014

Strange behavior of blocks

by Serge Stinckwich

Dear all, using Sci-Smalltalk, we found with Natalia that sometimes blocks have strange behavior : https://groups.google.com/forum/#!topic/scismalltalk/HmGpTkzLOdQ I was able to create a more simpler example using only Pharo. If you try, the following expression, there is no problem: |state values | values := (1 to: 10000) collect: [ : t| state := { t. t+1. t+2.}]. (1 to: 10000) do:[:i | (values at:i) at:2]. and you do more iterations, an error appears (Instances of SmallInteger are not indexable), because from time to time, an array is replaced by an integer: |state values | values := (1 to: 100000) collect: [ : t| state := { t. t+1. t+2.}]. (1 to: 100000) do:[:i | (values at:i) at:2]. and if you move the state variable inside the block, it works again : | values | values := (1 to: 100000) collect: [ : t| |state| state := { t. t+1. t+2.}]. (1 to: 100000) do:[:i | (values at:i) at:2]. Same problem in Pharo 3.0 or Pharo 4.0 Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 1, 2014

Floating point literals in debugger

by Natalia Tymchuk

Hello. When I have the following expression {1-1e-6. 1e-6. 0} in the code and then I debug it I get {(1 - '<an unprintable nonliteral value>'). '<an unprintable nonliteral value>'. 0}. Is it a known problem or should I report an issue on debug tracker? Best regards, Natalia

Aug. 1, 2014

Re: [Pharo-dev] where the...

by stepharo

Don't get me started on that..... to many little glitches everywhere. Stef > Why you don't like it? > > Norbert > >> Am 01.08.2014 um 09:48 schrieb stepharo <stepharo(a)free.fr>: >> >> I can tell you that I do not like jenkins but we have it, it works and it is maintained. So I lobotomize myself when I use it and it looks ok :) >> >> Stef >> >>> On 1/8/14 01:36, Eliot Miranda wrote: >>> *&^% do I find build artifacts for https://ci.inria.fr/pharo/job/Pharo-4.0/lastSuccessfulBuild/? There's no pointer to an image/changes combo I can see. >>> -- >>> Aloha, >>> Eliot >> >

Aug. 1, 2014

Re: [Pharo-dev] [Moose-dev] Pharo image corruption and fatal VM error with Roassal

by stepharo

> > Someone working on this? igor but he got burned out on that. > What are the next steps to make the system fully athens based? we need - to update all the drawon: methods (arghhhhh) - get a texteditor working (so far it is working but no tab support) We can organize a skype meetings with people willing to help. Stef > > > Nicolai > > > >> This way we don't clutter Athens with such low level stuff, and >> we offer the user a high-level usable cairo binding, which can be >> also used outside athens. >> >> Cheers, >> Ciprian >> >> > >> > But it is a bit different for resources created through Athens >> core api. >> > How can the user (TRShape for example) know, that a path >> created by >> > an Athens surface referes to an external resource? >> > >> > The attached changeset implements a simple check for TRCanvas and >> > resets paths if the canvas changes. This solves the crash on >> > image start up.But it is not a good solution. >> > >> > >> > >> > >> > 2014-07-31 16:23 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com >> <mailto:siguctua@gmail.com>>: >> > >> >> The recipe is simple: isolate the code in your application in >> a way that if certain feature not available (line nativeboost), >> it won't put your image into endless exception throwing loop. >> >> >> > >> > That's another story. The projects I have seen, using athens, >> do this with an explicit use >> > on AthensCairoSurface. Is there already a way to instantiate an >> AthensSurface depending on the >> > available libraries? And AthensBalloon and AthensCairo don't >> differ only in rendering quality, so there >> > is no real fallback option. >> > >> > >> > >> > >> >> >> >> >> >> On 31 July 2014 16:09, Alexandre Bergel >> <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> >>> >> >>> Yes, and this is a mess. >> >>> Iâve spent quite some time in getting the session working >> with Roassal2 and it still does not work. I would appreciate help >> on this. >> >>> >> >>> Alexandre >> >>> >> >>> >> >>> On Jul 31, 2014, at 8:58 AM, Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>> wrote: >> >>> >> >>> > It looks like Trachel does not recreate athens external >> resources. >> >>> > There is an example in AthensSceneView, on how to check and >> reload >> >>> > an AthensSurface. >> >>> > >> >>> > >> >>> > 2014-07-31 12:51 GMT+02:00 Usman Bhatti >> <usman.bhatti(a)gmail.com <mailto:usman.bhatti@gmail.com>>: >> >>> > >> >>> > >> >>> > >> >>> > On Thu, Jul 31, 2014 at 11:17 AM, Blondeau Vincent >> <vincent.blondeau(a)worldline.com >> <mailto:vincent.blondeau@worldline.com>> wrote: >> >>> > Yes it is. But I will not do >> >>> > >> >>> > TRMorph allInstances do: #delete >> >>> > >> >>> > In command line every dayâ¦ >> >>> > >> >>> > >> >>> > It is only intended to recover your lost work in the image >> not for everyday use :). >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > Vincent >> >>> > >> >>> > >> >>> > >> >>> > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org >> <mailto:pharo-dev-bounces@lists.pharo.org>] De la part de Usman >> Bhatti >> >>> > EnvoyÃ© : jeudi 31 juillet 2014 10:59 >> >>> > Ã : Pharo Development List >> >>> > Cc : Moose-related development >> >>> > >> >>> > >> >>> > Objet : Re: [Pharo-dev] Pharo image corruption and fatal VM >> error with Roassal >> >>> > >> >>> > >> >>> > >> >>> > This may be related to this known issue reported a few days >> back. >> >>> > >> >>> > >> https://code.google.com/p/moose-technology/issues/detail?id=1084 >> >>> > >> >>> > >> >>> > >> >>> > And there is a possible solution to recover your image. >> >>> > >> >>> > >> >>> > >> >>> > usman >> >>> > >> >>> > >> >>> > >> >>> > On Thu, Jul 31, 2014 at 10:50 AM, Blondeau Vincent >> <vincent.blondeau(a)worldline.com >> <mailto:vincent.blondeau@worldline.com>> wrote: >> >>> > >> >>> > Hi, >> >>> > >> >>> > >> >>> > >> >>> > Yesterday, I was using GraphET (a part of Roassal) to do >> some charts and, today, when I wanted to reopen the image. >> >>> > >> >>> > And I got that : >> >>> > >> >>> > <image001.png> >> >>> > >> >>> > It is *very* unpleasantâ¦ >> >>> > >> >>> > >> >>> > >> >>> > To reproduce the bug: >> >>> > >> >>> > 1 - You can do either: >> >>> > >> >>> > | builder | >> >>> > >> >>> > builder := GET2Line data: (0 to: 100) . >> >>> > >> >>> > builder >> >>> > >> >>> > y: [ :x | x*x ]. >> >>> > >> >>> > >> >>> > >> >>> > builder open. >> >>> > >> >>> > Or >> >>> > >> >>> > WorldMenu -> Roassal examples -> choose an item -> click on >> a graph . A TRMorph should be opened. >> >>> > >> >>> > 2 - donât close the graph and save the pharo image. >> >>> > >> >>> > 3 â Close the pharo image >> >>> > >> >>> > 4 - Reopen it >> >>> > >> >>> > >> >>> > >> >>> > I am under W7 x64 with the latest moose image and the VM >> available on the pharo.org <http://pharo.org> website >> (http://files.pharo.org/platform/Pharo3.0-win.zip) from the 10 july. >> >>> > >> >>> > You will find the crash dump attached. >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > Thankfully, I managed to open the image with a latest VM >> (http://www.mirandabanda.org/files/Cog/VM/VM.r3056/cogwin-14.29.3056.zip) >> >>> > >> >>> > Thanks a lot Eliot ! :) >> >>> > >> >>> > >> >>> > >> >>> > And I got this: >> >>> > >> >>> > <image002.png> >> >>> > >> >>> > >> >>> > >> >>> > Thanks in advance >> >>> > >> >>> > >> >>> > >> >>> > Cheers, >> >>> > >> >>> > Vincent BLONDEAU >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > Ce message et les piÃ¨ces jointes sont confidentiels et >> rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut >> Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous >> recevez ce message par erreur, merci d'en avertir immÃ©diatement >> l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant >> Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne >> pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que >> les meilleurs efforts soient faits pour maintenir cette >> transmission exempte de tout virus, l'expÃ©diteur ne donne aucune >> garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre >> recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. >> >>> > >> >>> > This e-mail and the documents attached are confidential and >> intended solely for the addressee; it may also be privileged. If >> you receive this e-mail in error, please notify the sender >> immediately and destroy it. As its integrity cannot be secured on >> the Internet, the Worldline liability cannot be triggered for the >> message content. Although the sender endeavours to maintain a >> computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any >> damages resulting from any virus transmitted. >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > Ce message et les piÃ¨ces jointes sont confidentiels et >> rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut >> Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous >> recevez ce message par erreur, merci d'en avertir immÃ©diatement >> l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant >> Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne >> pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que >> les meilleurs efforts soient faits pour maintenir cette >> transmission exempte de tout virus, l'expÃ©diteur ne donne aucune >> garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre >> recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. >> >>> > >> >>> > This e-mail and the documents attached are confidential and >> intended solely for the addressee; it may also be privileged. If >> you receive this e-mail in error, please notify the sender >> immediately and destroy it. As its integrity cannot be secured on >> the Internet, the Worldline liability cannot be triggered for the >> message content. Although the sender endeavours to maintain a >> computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any >> damages resulting from any virus transmitted. >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Moose-dev mailing list >> >>> > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> >>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>> >> >>> -- >> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>> Alexandre Bergel http://www.bergel.eu >> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>> >> >>> >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> > >> > >> > >

Aug. 1, 2014

Re: [Pharo-dev] [Moose-dev] Pharo image corruption and fatal VM error with Roassal

by Nicolai Hess

2014-08-01 9:46 GMT+02:00 stepharo <stepharo(a)free.fr>: > > On 1/8/14 08:56, Ciprian Teodorov wrote: > > > On Jul 31, 2014 11:03 PM, "Nicolai Hess" <nicolaihess(a)web.de> wrote: > > > > Is is not that easy :) > > TRMorph already checks for a new session. > > TRCanvas not, but could be done the same way - maybe. It is difficult as > TRCanvas are shared by different objects. > > And it is more difficult for TRShape. > > > > I know Igors argument against a session management in Athens for > > recreating cairo resources on image start up. It is not the job of > Athens. > > Maybe session management should be implemented by the cairo binding (or an > abstraction on top of it, that is then used by athens). > > > It will when the system will be fully athens based. Now each client should > handle it his way. > Someone working on this? What are the next steps to make the system fully athens based? Nicolai > > > This way we don't clutter Athens with such low level stuff, and we offer > the user a high-level usable cairo binding, which can be also used outside > athens. > > Cheers, > Ciprian > > > > > But it is a bit different for resources created through Athens core api. > > How can the user (TRShape for example) know, that a path created by > > an Athens surface referes to an external resource? > > > > The attached changeset implements a simple check for TRCanvas and > > resets paths if the canvas changes. This solves the crash on > > image start up.But it is not a good solution. > > > > > > > > > > 2014-07-31 16:23 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > > > >> The recipe is simple: isolate the code in your application in a way > that if certain feature not available (line nativeboost), it won't put your > image into endless exception throwing loop. > >> > > > > That's another story. The projects I have seen, using athens, do this > with an explicit use > > on AthensCairoSurface. Is there already a way to instantiate an > AthensSurface depending on the > > available libraries? And AthensBalloon and AthensCairo don't differ only > in rendering quality, so there > > is no real fallback option. > > > > > > > > > >> > >> > >> On 31 July 2014 16:09, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >>> > >>> Yes, and this is a mess. > >>> Iâve spent quite some time in getting the session working with > Roassal2 and it still does not work. I would appreciate help on this. > >>> > >>> Alexandre > >>> > >>> > >>> On Jul 31, 2014, at 8:58 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >>> > >>> > It looks like Trachel does not recreate athens external resources. > >>> > There is an example in AthensSceneView, on how to check and reload > >>> > an AthensSurface. > >>> > > >>> > > >>> > 2014-07-31 12:51 GMT+02:00 Usman Bhatti <usman.bhatti(a)gmail.com>: > >>> > > >>> > > >>> > > >>> > On Thu, Jul 31, 2014 at 11:17 AM, Blondeau Vincent < > vincent.blondeau(a)worldline.com> wrote: > >>> > Yes it is. But I will not do > >>> > > >>> > TRMorph allInstances do: #delete > >>> > > >>> > In command line every dayâ¦ > >>> > > >>> > > >>> > It is only intended to recover your lost work in the image not for > everyday use :). > >>> > > >>> > > >>> > > >>> > > >>> > Vincent > >>> > > >>> > > >>> > > >>> > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la > part de Usman Bhatti > >>> > EnvoyÃ© : jeudi 31 juillet 2014 10:59 > >>> > Ã : Pharo Development List > >>> > Cc : Moose-related development > >>> > > >>> > > >>> > Objet : Re: [Pharo-dev] Pharo image corruption and fatal VM error > with Roassal > >>> > > >>> > > >>> > > >>> > This may be related to this known issue reported a few days back. > >>> > > >>> > https://code.google.com/p/moose-technology/issues/detail?id=1084 > >>> > > >>> > > >>> > > >>> > And there is a possible solution to recover your image. > >>> > > >>> > > >>> > > >>> > usman > >>> > > >>> > > >>> > > >>> > On Thu, Jul 31, 2014 at 10:50 AM, Blondeau Vincent < > vincent.blondeau(a)worldline.com> wrote: > >>> > > >>> > Hi, > >>> > > >>> > > >>> > > >>> > Yesterday, I was using GraphET (a part of Roassal) to do some charts > and, today, when I wanted to reopen the image. > >>> > > >>> > And I got that : > >>> > > >>> > <image001.png> > >>> > > >>> > It is *very* unpleasantâ¦ > >>> > > >>> > > >>> > > >>> > To reproduce the bug: > >>> > > >>> > 1 - You can do either: > >>> > > >>> > | builder | > >>> > > >>> > builder := GET2Line data: (0 to: > 100) . > >>> > > >>> > builder > >>> > > >>> > y: [ :x | x*x ]. > >>> > > >>> > > >>> > > >>> > builder open. > >>> > > >>> > Or > >>> > > >>> > WorldMenu -> Roassal examples -> choose an item -> click on a graph > . A TRMorph should be opened. > >>> > > >>> > 2 - donât close the graph and save the pharo image. > >>> > > >>> > 3 â Close the pharo image > >>> > > >>> > 4 - Reopen it > >>> > > >>> > > >>> > > >>> > I am under W7 x64 with the latest moose image and the VM available > on the pharo.org website (http://files.pharo.org/platform/Pharo3.0-win.zip) > from the 10 july. > >>> > > >>> > You will find the crash dump attached. > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > Thankfully, I managed to open the image with a latest VM ( > http://www.mirandabanda.org/files/Cog/VM/VM.r3056/cogwin-14.29.3056.zip) > >>> > > >>> > Thanks a lot Eliot ! :) > >>> > > >>> > > >>> > > >>> > And I got this: > >>> > > >>> > <image002.png> > >>> > > >>> > > >>> > > >>> > Thanks in advance > >>> > > >>> > > >>> > > >>> > Cheers, > >>> > > >>> > Vincent BLONDEAU > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã > l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par > le secret professionnel. Si vous recevez ce message par erreur, merci d'en > avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du > message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de > Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien > que les meilleurs efforts soient faits pour maintenir cette transmission > exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et > sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant > d'un virus transmis. > >>> > > >>> > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã > l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par > le secret professionnel. Si vous recevez ce message par erreur, merci d'en > avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du > message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de > Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien > que les meilleurs efforts soient faits pour maintenir cette transmission > exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et > sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant > d'un virus transmis. > >>> > > >>> > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > >>> > > >>> > > >>> > _______________________________________________ > >>> > Moose-dev mailing list > >>> > Moose-dev(a)iam.unibe.ch > >>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > > > > > > >

Aug. 1, 2014

Re: [Pharo-dev] where the...

by Ben Coman

Aug. 1, 2014