February 2016 - Pharo-dev - lists.pharo.org

Ubuntu with Spur

by Torsten Bergmann

Is Spur already in the PPA for last stable Ubuntu or how do I install latest spur quickly using commandline? Should I use zeroconf from get.pharo.org. Does it run on latest dev version of Ubuntu? Thanks T.

Feb. 5, 2016

Easy way to change "move between words" to alt key in OSX?

by Mariano Martinez Peck

Hi guys, It happens to me that I got so used to work in Pharo and "move between words" with ctrl key, that then, whenever I use any other program of OSX, I get crazy because in many programs ctrl+arrow is for going start/end of file. Same for command. It seems to me that using alt + arrow for moving between words is the most common in OSX. So....is there a way to set this via preferences or something? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Feb. 5, 2016

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Le 05/02/2016 14:55, Christophe Demarey a Ã©crit : > > Le 5 fÃ©vr. 2016 Ã 14:33, Thierry Goubier a Ã©crit : > >> Le 05/02/2016 11:33, Christophe Demarey a Ã©crit : >>> Hi Thierry, >>> >>> Just some thoughts I wanted to share: >>> >>> Le 3 fÃ©vr. 2016 Ã 10:18, Thierry Goubier a Ã©crit : >>> >>>> I went through all the different possible file formats, >>>> class-based, package-based, method-based, log metadata and the >>>> like, and I concluded that: >>>> >>>> - the method based format is as good as any other. Even better >>>> since it has a spec (cypress). >>> >>> I see cons that a class (or package) format would not have. One >>> file per method approach leads to generate plenty of small files. >>> In general, file systems do not like that: - it may consumes a >>> lot of space. I remember I had a Java/maven project with a lot of >>> small files and I got to fill the inodes tables on my unix >>> system. - you generate long pathes. Long pathes are not >>> user-friendly and some OS have restrictions on path length. >> >> The method based structure of filetree is very close to how code is >> navigated in Smalltalk browsers: one method at a time, with a >> package/class/protocol hierarchical layering on top. The one file >> per class / one file per package is a reference to the base unit of >> C / C++. > > I fully agree with that. As we have a lot (small) methods, we will > have a lot of small files and some file-system does not like that. I > remember huge slow-down be cause of that. It is good to keep that in > mind. The problem is linked with writing too many files. Because of a possible uncertainty about the on-disk state, FileTree erase the complete package directory then rewrites everything, letting the vcs decide what has really changed. This is doubly slow, because it hits the filesystem and the vcs. I said to Dale I'd see into a diff based writer; it should improve things a lot. >> And no OS in general use has path restrictions that matter. Ok, the >> windows vm has issues, but this is a vm bug, not a filesystem >> issue. > > Windows command-line has (had) this limitation. Good to know. >>> By adopting a file per method approach, you also increase the >>> distance to get a common script format for Smalltalk. Here I mean >>> a file where you could define classes, methods, and run >>> arbitrary portions of Smalltalk code. >> >> This format is called fileout, and already exist. > > I mean something like a python script: > http://archive.stsci.edu/vo/python_examples.html Not entirely keen in going that way. I prefer declarative formats for storing packages. And I still think that the fileout format is that (a sequence of scripts to execute, separated by !!). >> All you describe is also available in the FileTree/Cypress format >> and is technically better specified. >> >>>> - method based format allow for method-history queries on the >>>> git/vcs history (as well as class based / package based >>>> queries). - the tree structure on github or bitbucket is quite >>>> convenient (and browsable) to the point one could edit a >>>> package directly in it (I do when I need to do a quick fix). >>> >>> but is a pain to navigate: too much click to effectively browse >>> a method content. >> >> You must hate Nautilus, then, since this is Nautilus approach as >> well. Just count the number of clicks you do in a Nautilus, and the >> number in github. > > but we have spotter! (I just miss the exact search to not click and > scroll too much) Then you want spotter on the web :) >> If we remove the instance sub-directory and write instance-side >> methods just below the class name in filetree, then you'll get the >> exact same number of clicks to reach a method than in Nautilus. > > it would be a good idea Why not. >> Fun fact: if you do that with the Mac finder in NexT mode over a >> filetree repository (miller columns), you'll see that it almost >> looks like a Nautilus top panes. >> >>> I do not know what would be the best format but I think we need >>> to take care to do not generate too much files / folders. File >>> system and VCS will appreciate also. >> >> I'd say, overall, what we need to remember is that we produce a >> lot less lines of code than other languages, and that we shouldn't >> over-optimize. >> >> I'll probably look into optimising FileTree-like writing in the >> future; I wasn't that good into planning for it and it shows in >> specific cases. > > It is actually the problem: we generate a lot of small files. I do > not have numbers but I think it would be good to stress a bit a file > system to see where we hit the barrier and compare with the pharo > code base. From the git side, I'm not aware of a limitation regarding > small files. I'm sure the numbers are already available. And, as I said above, you may be measuring FileTree implementation limitations and nothing related to filesystem issues (or git issues). Thierry

Feb. 5, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50567 Home: https://github.com/pharo-project/pharo-core

Feb. 5, 2016

[pharo-project/pharo-core] 219d90: 50567

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 219d902c7d979074a155881cc28de2d71d1e39a3 https://github.com/pharo-project/pharo-core/commit/219d902c7d979074a155881c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-05 (Fri, 05 Feb 2016) Changed paths: M Collections-Strings.package/String.class/class/initialization/initialize.st A Collections-Tests.package/StringTest.class/instance/test-comparing/testComparingCaseInsensitiveLatin1.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50566.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50567.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50566.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50567.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot-Tests.package/SlotErrorsTest.class/instance/tests/testDangerousClassesConditions.st R System-Support.package/SystemDictionary.class/instance/memory space/growMemoryByAtLeast_.st Log Message: ----------- 50567 17526 growMemoryByAtLeast: duplicated https://pharo.fogbugz.com/f/cases/17526 17530 fix testDangerousClassesConditions https://pharo.fogbugz.com/f/cases/17530 17242 String>>compare:caseSensitive seems to be failing for extended charset comparisons https://pharo.fogbugz.com/f/cases/17242 http://files.pharo.org/image/50/50567.zip

Feb. 5, 2016

Re: [Pharo-dev] Contributing to Pharo

by Christophe Demarey

Le 5 fÃ©vr. 2016 Ã 14:33, Thierry Goubier a Ã©crit : > Le 05/02/2016 11:33, Christophe Demarey a Ã©crit : >> Hi Thierry, >> >> Just some thoughts I wanted to share: >> >> Le 3 fÃ©vr. 2016 Ã 10:18, Thierry Goubier a Ã©crit : >> >>> I went through all the different possible file formats, >>> class-based, package-based, method-based, log metadata and the >>> like, and I concluded that: >>> >>> - the method based format is as good as any other. Even better >>> since it has a spec (cypress). >> >> I see cons that a class (or package) format would not have. One file >> per method approach leads to generate plenty of small files. In >> general, file systems do not like that: - it may consumes a lot of >> space. I remember I had a Java/maven project with a lot of small >> files and I got to fill the inodes tables on my unix system. - you >> generate long pathes. Long pathes are not user-friendly and some OS >> have restrictions on path length. > > The method based structure of filetree is very close to how code is navigated in Smalltalk browsers: one method at a time, with a package/class/protocol hierarchical layering on top. The one file per class / one file per package is a reference to the base unit of C / C++. I fully agree with that. As we have a lot (small) methods, we will have a lot of small files and some file-system does not like that. I remember huge slow-down be cause of that. It is good to keep that in mind. > And no OS in general use has path restrictions that matter. Ok, the windows vm has issues, but this is a vm bug, not a filesystem issue. Windows command-line has (had) this limitation. > >> By adopting a file per method approach, you also increase the >> distance to get a common script format for Smalltalk. Here I mean a >> file where you could define classes, methods, and run arbitrary >> portions of Smalltalk code. > > This format is called fileout, and already exist. I mean something like a python script: http://archive.stsci.edu/vo/python_examples.html > All you describe is also available in the FileTree/Cypress format and is technically better specified. > >>> - method based format allow for method-history queries on the >>> git/vcs history (as well as class based / package based queries). - >>> the tree structure on github or bitbucket is quite convenient (and >>> browsable) to the point one could edit a package directly in it (I >>> do when I need to do a quick fix). >> >> but is a pain to navigate: too much click to effectively browse a >> method content. > > You must hate Nautilus, then, since this is Nautilus approach as well. Just count the number of clicks you do in a Nautilus, and the number in github. but we have spotter! (I just miss the exact search to not click and scroll too much) > If we remove the instance sub-directory and write instance-side methods just below the class name in filetree, then you'll get the exact same number of clicks to reach a method than in Nautilus. it would be a good idea > Fun fact: if you do that with the Mac finder in NexT mode over a filetree repository (miller columns), you'll see that it almost looks like a Nautilus top panes. > >> I do not know what would be the best format but I think we need to >> take care to do not generate too much files / folders. File system >> and VCS will appreciate also. > > I'd say, overall, what we need to remember is that we produce a lot less lines of code than other languages, and that we shouldn't over-optimize. > > I'll probably look into optimising FileTree-like writing in the future; I wasn't that good into planning for it and it shows in specific cases. It is actually the problem: we generate a lot of small files. I do not have numbers but I think it would be good to stress a bit a file system to see where we hit the barrier and compare with the pharo code base. From the git side, I'm not aware of a limitation regarding small files.

Feb. 5, 2016

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Le 05/02/2016 11:33, Christophe Demarey a Ã©crit : > Hi Thierry, > > Just some thoughts I wanted to share: > > Le 3 fÃ©vr. 2016 Ã 10:18, Thierry Goubier a Ã©crit : > >> I went through all the different possible file formats, >> class-based, package-based, method-based, log metadata and the >> like, and I concluded that: >> >> - the method based format is as good as any other. Even better >> since it has a spec (cypress). > > I see cons that a class (or package) format would not have. One file > per method approach leads to generate plenty of small files. In > general, file systems do not like that: - it may consumes a lot of > space. I remember I had a Java/maven project with a lot of small > files and I got to fill the inodes tables on my unix system. - you > generate long pathes. Long pathes are not user-friendly and some OS > have restrictions on path length. The method based structure of filetree is very close to how code is navigated in Smalltalk browsers: one method at a time, with a package/class/protocol hierarchical layering on top. The one file per class / one file per package is a reference to the base unit of C / C++. And no OS in general use has path restrictions that matter. Ok, the windows vm has issues, but this is a vm bug, not a filesystem issue. > By adopting a file per method approach, you also increase the > distance to get a common script format for Smalltalk. Here I mean a > file where you could define classes, methods, and run arbitrary > portions of Smalltalk code. This format is called fileout, and already exist. All you describe is also available in the FileTree/Cypress format and is technically better specified. >> - method based format allow for method-history queries on the >> git/vcs history (as well as class based / package based queries). - >> the tree structure on github or bitbucket is quite convenient (and >> browsable) to the point one could edit a package directly in it (I >> do when I need to do a quick fix). > > but is a pain to navigate: too much click to effectively browse a > method content. You must hate Nautilus, then, since this is Nautilus approach as well. Just count the number of clicks you do in a Nautilus, and the number in github. If we remove the instance sub-directory and write instance-side methods just below the class name in filetree, then you'll get the exact same number of clicks to reach a method than in Nautilus. Fun fact: if you do that with the Mac finder in NexT mode over a filetree repository (miller columns), you'll see that it almost looks like a Nautilus top panes. > I do not know what would be the best format but I think we need to > take care to do not generate too much files / folders. File system > and VCS will appreciate also. I'd say, overall, what we need to remember is that we produce a lot less lines of code than other languages, and that we shouldn't over-optimize. I'll probably look into optimising FileTree-like writing in the future; I wasn't that good into planning for it and it shows in specific cases. Thierry

Feb. 5, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Henrik Sperre Johansen

On Thu, Feb 4, 2016 at 2:59 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 04 Feb 2016, at 14:02, Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > >> > >> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> > >>> On 04 Feb 2016, at 11:55, Guille Polito <guillermopolito(a)gmail.com> > wrote: > >>> > >>> Good news, so far, installing NeoUUID and replacing UUID class >> new > by: > >>> > >>> UUID class >> new > >>> ^NeoUUIDGenerator new next > >>> > >>> seems to work. At it looks that I can trust again my commits. > >>> > >>> Thanks Sven :) > >> > >> OK. > >> > >> Now, the idea is that one instance of the generator is kept around, > this is way more efficient, but also more correct, as the random generator > should not be created anew each time. > >> > >>> Now I do not know how this should be solved, nor if this is > reproducible in a machine other than mine... > >> > >> I seriously doubt the plugin is better (more random, more unique) then > anything that we can do in Pharo itself. I like Pharo code way better, > because we all see what it does. > >> > >> Anyone else with an opinion ? > > > > More random for certain, at least much faster than we could do in Pharo, > is certainly possible with a plugin. > > More unique... well, depends on whether you can trust the source RNG > (seeded from data with enough entropy, period much greater than 2^128, etc). > > > > A single next:into:startingAt: primitive filling random data (obtained > using platform primitives and/or RDRAND/RDSEED) into a buffer would be much > nicer/more flexible than the current UUID primitive though. (the linked > UUID library is basically just a thin wrapper around the platform > primitives, plus setting variant/version bits in the returned UUID bytes) > > > > As a stopgap, one could instead use another, more general primitive (but > with a less flexible api than next:into:startingAt:) in an otherwise > unrelated plugin (but that is built internal to all Cog VM's, at least): > > rand: aBuffer > > <primitive: 'primitiveGatherEntropy' module: 'CroquetPlugin'> > > ^self primitiveFail > > > > (which, iirc, resolves to the same platform primitives as UUID lib) > > > > Also, the meaning of different UUID versions are well defined in the > RFC, marking NeoUUID's as being a version 4 UUID seems somewhat ... > disingenuous. > > Yes, but to 99.99% of developers, a UUID is something special/magic where > some effort was made to generate something as unique as possible. > > If we insist on it being just 128 random bits, then why all the fuss ? Why > do we even need so called standards ? In my mind, you just answered that :) The standard provides 4 well-defined ways to implement something where it's guaranteed that some effort has been made to generate something as unique as possible. Why do we need a plugin, an implementation even ? It makes no sense. Just > read 16 bytes from /dev/[u]random, or the equivalent use of a RNG and be > done with it. > > But if you tell developers that their database IDs are just plain random > numbers, they will probably feels less good about them. > > But... that's *exactly* what you tell them by marking UUID's as being of type 4. > To me UUID is a specific concept: << The intent of UUIDs is to enable > distributed systems to uniquely identify information without significant > central coordination. In this context the word unique should be taken to > mean "practically unique" rather than "guaranteed unique". >> > > Not including any 'node' information (identifying process, image, VM, > machine, network endpoint), nor 'counter' does not feel right. > And I agree Neo-UUID fits that bill nicely, the values it returns *are* practically unique. The two things I disagreed with was: 1) The statement that it is possible to implement purely in Smalltalk UUID's as random as those returned by the plugin (Which, as you say, is basically reading 16 bytes from /dev/random), at least as performant, without consulting an external trusted randomness source. 2) Misrepresenting the way the UUID was generated (a combination of node identifier + timestamp + random value, similar to type 3, but with differently sized/ordered fields) by marking it as being of type 4, which is defined to be UUID consisting of random bytes. IOW, I think it should be marked as type 0 instead of 4, so for the 1 person in each country who might be found to assume something about the implementation based on the type field, won't later feel he's been duped when checking the generator. Cheers, Henry

Feb. 5, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by Blondeau Vincent

If you remove any line, it stops crashingâ¦ I really donât know what is going onâ¦ Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Henrik Nergaard EnvoyÃ© : vendredi 5 fÃ©vrier 2016 14:03 Ã : Pharo Development List Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5) Removing #(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp: visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral: visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable: visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray: visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp: visitTempVector: visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar: visitSend: )) And it stops crashing. - BTW, there is not crash.dmp, does it works with spur? https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-f… Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Blondeau Vincent Sent: Friday, February 5, 2016 1:54 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org<mailto:pharo-dev@lists.pharo.org>> Subject: Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5) Very strange bug indeed that happens on windows machines that crashes the VM. I succeeded to reduce the problem to an evaluation of a collectionâ¦ Can someone have the same issue under Windows or Mac? To reproduce : Copy paste the contents of the attached file in the playground and print it or do it It works on pre-spur vm. BTW, there is not crash.dmp, does it works with spur? Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Marcus Denker EnvoyÃ© : vendredi 5 fÃ©vrier 2016 13:01 Ã : Pharo Development List Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5) On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker(a)inria.fr<mailto:marcus.denker@inria.fr>> wrote: I will try do integrate it nowâ¦ No, it still fails. https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… The last test it executed seems to be this: running suite: Refactoring-Tests-Environment starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ... Very strange... Marcus ________________________________ 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.

Feb. 5, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by Max Leske

> I can confirm that it doesnât crash on OS X but does in a Windows 7 VM. I should add: both with latest VM and image (spur) > >> On 05 Feb 2016, at 13:53, Blondeau Vincent <vincent.blondeau(a)worldline.com <mailto:vincent.blondeau@worldline.com>> wrote: >> >> Very strange bug indeed that happens on windows machines that crashes the VM. I succeeded to reduce the problem to an evaluation of a collectionâ¦ >> Can someone have the same issue under Windows or Mac? >> >> To reproduce : Copy paste the contents of the attached file in the playground and print it or do it >> It works on pre-spur vm. >> >> BTW, there is not crash.dmp, does it works with spur? >> Vincent >> >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org>] De la part de Marcus Denker >> EnvoyÃ© : vendredi 5 fÃ©vrier 2016 13:01 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5) >> >> >> On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> I will try do integrate it nowâ¦ >> >> >> >> No, it still fails. >> >> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… <https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe…> >> >> The last test it executed seems to be this: >> running suite: Refactoring-Tests-Environment >> starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ... >> Very strange... >> Marcus >> >> >> >> 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. >> <toEval.txt> >

Feb. 5, 2016