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

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

by Jan Vrany

> Maybe it should only lock the threads that were _not_ started by the > âtest threadâ? Iâm not even sure that is possible, > just suggesting things. > Have a look at Niall Ross' XProc Patterns. They do the same by - AFAIK - intercepting process creation and checking whether the creating process is one of the "tests threads".Â HTH, Jan > > On Jan 12, 2016, at 11:11 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > > wrote: > > > > The coverage seems to be implemented by 'locking' the current > > execution thread exclusively, which would mean no other threads can > > run, at all. So code depending on multi threading, like > > client/server code, like HTTP, cannot work. Yes that seems to be a > > limitation, but an understandable one. > > > > I am trying to help but I don't known anything about the coverage > > tool, so maybe I should shut up ;-) > > > > > On 12 Jan 2016, at 11:05, Skip Lentz <skip.lentz(a)inria.fr> wrote: > > > > > > You mean as in it can check the coverage effected by the code > > > running in the other thread? > > > Or is this not what you mean? > > > > > > Well I mean, at least it can show the coverage done by what was > > > run in the same thread.. > > > And it will at least not hang or fail. > > > > > > > On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe <sven@stfx. > > > > eu> wrote: > > > > > > > > I never used that, but it seems coverage can only deal with > > > > single threaded code, which sounds logical. No ? > > > > > > > > > On 12 Jan 2016, at 10:53, Skip Lentz <skip.lentz(a)inria.fr> > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > When I want to run the coverage of for example Zincâs Client > > > > > and Server tests, > > > > > it will either hang (in the case of Zincâs test cases) or > > > > > fail because the coverage > > > > > uses BlockClosure>>valueUnpreemptively for running the tests. > > > > > The relevant method is TestRunner>>collectCoverageFor:. > > > > > > > > > > So when a test is run, it is not able to be preempted by > > > > > another process, like for > > > > > example a local server which is needed to run the actual test > > > > > in Zincâs case. > > > > > > > > > > When I use BlockClosure>>valueUninterruptably it works. Can > > > > > someone tell me > > > > > if it is wrong to use that instead? Is valueUnpreemptively > > > > > necessary in this case, > > > > > and if so, why? > > > > > > > > > > To reproduce: Load fresh image, select Zinc's ZnClientTests > > > > > and ZnServerTests, > > > > > click on âRun Coverageâ -> hanging image. > > > > > > > > > > Thanks, > > > > > > > > > > Skip > > > > > > > > > > > > > > > > > > > > >

Jan. 12, 2016

Re: [Pharo-dev] Pharo50 spur works on CentOS?

by Sven Van Caekenberghe

Ah yes, that is better, thanks! > On 12 Jan 2016, at 11:54, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Agree. > I open a bug: https://pharo.fogbugz.com/f/cases/17378/Improve-command-line-handler-docume… that improve the doc. > I propose: > Usage: [--no-preferences|--preference-file=<FILE>][--help|--list|--copyright|--version|--no-quit|<subcommand> <subcommand args>] > --help print this help message > --list list a description of all active command line handlers > --copyright print the copyrights > --version print the version for the image and the vm > --no-quit keep the image running without activating any other command line handler > <subcommand> a valid subcommand in --list > <subcommand> --help show subcommand help > > Vincent > >> -----Message d'origine----- >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Sven Van Caekenberghe >> EnvoyÃ© : mardi 12 janvier 2016 11:48 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS? >> >> No, I don't think so, it has a function. >> >> Some people like to configure Pharo images so that they have a running >> server inside them. In that case, starting your app is a simple as starting the >> image, but you would probably need the --no-quit to prevent it from exiting >> immediately. >> >> (I personally don't like and never use that approach, but I know some people >> like it). >> >> The confusing aspect is that the same option is used in two places and the >> first one annihilates the second. But that is documented: >> >> prometheus:pharo5 sven$ ./pharo Pharo.image --help >> Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] [-- >> help] [--copyright] [--version] [--list] [ --no-quit ] >> --help print this help message >> --copyright print the copyrights >> --version print the version for the image and the vm >> --list list a description of all active command line handlers >> --no-quit keep the image running without activating any other >> command line handler >> <subcommand> a valid subcommand in --list >> >> Documentation: >> A BasicCommandLineHandler handles default command line arguments and >> options. >> >> It clearly says "without activating any other command line handler". So using >> --no-quit BEFORE the subcommand annihilates the subcommand (AFAIU). >> >>> On 12 Jan 2016, at 11:28, Blondeau Vincent >> <vincent.blondeau(a)worldline.com> wrote: >>> >>> So --no-quit should be removed from the default line handler? >>> >>> Vincent >>> >>>> -----Message d'origine----- >>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part >>>> de Esteban Lorenzano EnvoyÃ© : mardi 12 janvier 2016 11:18 Ã : Pharo >>>> Development List Objet : Re: [Pharo-dev] Pharo50 spur works on >>>> CentOS? >>>> >>>> But you cannot use it as a general command. >>>> If you use a subcommand (most likely) then you do not have it unless >>>> the subcommand defines it. >>>> >>>> Esteban >>>> >>>>> On 12 Jan 2016, at 11:12, Blondeau Vincent >>>> <vincent.blondeau(a)worldline.com> wrote: >>>>> >>>>> >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la >>>>>> part de Sven Van Caekenberghe EnvoyÃ© : mardi 12 janvier 2016 10:57 Ã >> : >>>>>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works >>>>>> on CentOS? >>>>>> >>>>>> >>>>>>>> On 12 Jan 2016, at 10:50, Esteban Lorenzano >> <estebanlm(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe <sven(a)stfx.eu> >>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 12 Jan 2016, at 10:28, Blondeau Vincent >>>>>> <vincent.blondeau(a)worldline.com> wrote: >>>>>>>>> >>>>>>>>> Indeed, it works. Thanks! >>>>>>>>> >>>>>>>>> But the command line usage is not clear : >>>>>>>>> ./pharo Pharo.image >>>>>>>>> Usage: [--no-preferences|--preference- >> file=<FILE>][<subcommand>] >>>>>>>>> [--help] [--copyright] [--version] [--list] [ --no-quit ] >>>>>>>>> >>>>>>>>> Maybe, it can be : >>>>>>>>> Usage: [--no-preferences|--preference- >> file=<FILE>][<subcommand>] >>>>>>>>> [--help] [--copyright] [--version] [--list] [ --no-quit ] >>>>>>>>> [<subcommand args>] >>>>>>>>> >>>>>>>>> Moreover, an option can usually be placed anywhere on the >>>>>>>>> command >>>>>> line, shouldn't it? Or at least it should raise an error? >>>>>>>> >>>>>>>> Yes it is a bit confusion (but you could try to read/understand >>>>>>>> the Pharo code, it is not very difficult ;-) >>>>>>>> >>>>>>>> But the idea is that the sub-command controls its own options >>>>>>>> (like passing linker options via the compiler to the linker - git >>>>>>>> also has global and per sub command options, no ?) >>>>>>>> >>>>>>>> --no-quit probably also works for the default command ... (I >>>>>>>> haven't >>>>>> looked), so at that point, the option is consumed already. >>>>>>> >>>>>>> No, it doesn't :) >>>>>> >>>>>> prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version] >>>>>> 5.0 >>>>>> #50510 >>>>>> prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C >>>>>> >>>>>> The last command 'hangs' (i.e. the image keeps running, just as >>>> advertised). >>>>>> So the default (Pharo, subclass of BasicCommandHandler) interpreted >>>>>> the -- no-quit and acted upon it. No ? >>>>> >>>>> Yes! See: BasicCommandLineHandler>>handleArgument: >>>>>> >>>>>>>> >>>>>>>>> Vincent >>> >>> >>> >>> 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.

Jan. 12, 2016

Re: [Pharo-dev] Pharo50 spur works on CentOS?

by Blondeau Vincent

Agree. I open a bug: https://pharo.fogbugz.com/f/cases/17378/Improve-command-line-handler-docume… that improve the doc. I propose: Usage: [--no-preferences|--preference-file=<FILE>][--help|--list|--copyright|--version|--no-quit|<subcommand> <subcommand args>] --help print this help message --list list a description of all active command line handlers --copyright print the copyrights --version print the version for the image and the vm --no-quit keep the image running without activating any other command line handler <subcommand> a valid subcommand in --list <subcommand> --help show subcommand help Vincent > -----Message d'origine----- > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de > Sven Van Caekenberghe > EnvoyÃ© : mardi 12 janvier 2016 11:48 > Ã : Pharo Development List > Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS? > > No, I don't think so, it has a function. > > Some people like to configure Pharo images so that they have a running > server inside them. In that case, starting your app is a simple as starting the > image, but you would probably need the --no-quit to prevent it from exiting > immediately. > > (I personally don't like and never use that approach, but I know some people > like it). > > The confusing aspect is that the same option is used in two places and the > first one annihilates the second. But that is documented: > > prometheus:pharo5 sven$ ./pharo Pharo.image --help > Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] [-- > help] [--copyright] [--version] [--list] [ --no-quit ] > --help print this help message > --copyright print the copyrights > --version print the version for the image and the vm > --list list a description of all active command line handlers > --no-quit keep the image running without activating any other > command line handler > <subcommand> a valid subcommand in --list > > Documentation: > A BasicCommandLineHandler handles default command line arguments and > options. > > It clearly says "without activating any other command line handler". So using > --no-quit BEFORE the subcommand annihilates the subcommand (AFAIU). > > > On 12 Jan 2016, at 11:28, Blondeau Vincent > <vincent.blondeau(a)worldline.com> wrote: > > > > So --no-quit should be removed from the default line handler? > > > > Vincent > > > >> -----Message d'origine----- > >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part > >> de Esteban Lorenzano EnvoyÃ© : mardi 12 janvier 2016 11:18 Ã : Pharo > >> Development List Objet : Re: [Pharo-dev] Pharo50 spur works on > >> CentOS? > >> > >> But you cannot use it as a general command. > >> If you use a subcommand (most likely) then you do not have it unless > >> the subcommand defines it. > >> > >> Esteban > >> > >>> On 12 Jan 2016, at 11:12, Blondeau Vincent > >> <vincent.blondeau(a)worldline.com> wrote: > >>> > >>> > >>> > >>>> -----Message d'origine----- > >>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la > >>>> part de Sven Van Caekenberghe EnvoyÃ© : mardi 12 janvier 2016 10:57 Ã > : > >>>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works > >>>> on CentOS? > >>>> > >>>> > >>>>>> On 12 Jan 2016, at 10:50, Esteban Lorenzano > <estebanlm(a)gmail.com> > >>>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe <sven(a)stfx.eu> > >> wrote: > >>>>>> > >>>>>> > >>>>>>> On 12 Jan 2016, at 10:28, Blondeau Vincent > >>>> <vincent.blondeau(a)worldline.com> wrote: > >>>>>>> > >>>>>>> Indeed, it works. Thanks! > >>>>>>> > >>>>>>> But the command line usage is not clear : > >>>>>>> ./pharo Pharo.image > >>>>>>> Usage: [--no-preferences|--preference- > file=<FILE>][<subcommand>] > >>>>>>> [--help] [--copyright] [--version] [--list] [ --no-quit ] > >>>>>>> > >>>>>>> Maybe, it can be : > >>>>>>> Usage: [--no-preferences|--preference- > file=<FILE>][<subcommand>] > >>>>>>> [--help] [--copyright] [--version] [--list] [ --no-quit ] > >>>>>>> [<subcommand args>] > >>>>>>> > >>>>>>> Moreover, an option can usually be placed anywhere on the > >>>>>>> command > >>>> line, shouldn't it? Or at least it should raise an error? > >>>>>> > >>>>>> Yes it is a bit confusion (but you could try to read/understand > >>>>>> the Pharo code, it is not very difficult ;-) > >>>>>> > >>>>>> But the idea is that the sub-command controls its own options > >>>>>> (like passing linker options via the compiler to the linker - git > >>>>>> also has global and per sub command options, no ?) > >>>>>> > >>>>>> --no-quit probably also works for the default command ... (I > >>>>>> haven't > >>>> looked), so at that point, the option is consumed already. > >>>>> > >>>>> No, it doesn't :) > >>>> > >>>> prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version] > >>>> 5.0 > >>>> #50510 > >>>> prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C > >>>> > >>>> The last command 'hangs' (i.e. the image keeps running, just as > >> advertised). > >>>> So the default (Pharo, subclass of BasicCommandHandler) interpreted > >>>> the -- no-quit and acted upon it. No ? > >>> > >>> Yes! See: BasicCommandLineHandler>>handleArgument: > >>>> > >>>>>> > >>>>>>> Vincent > > > > > > > > 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.

Jan. 12, 2016

Re: [Pharo-dev] Pharo50 spur works on CentOS?

by Sven Van Caekenberghe

No, I don't think so, it has a function. Some people like to configure Pharo images so that they have a running server inside them. In that case, starting your app is a simple as starting the image, but you would probably need the --no-quit to prevent it from exiting immediately. (I personally don't like and never use that approach, but I know some people like it). The confusing aspect is that the same option is used in two places and the first one annihilates the second. But that is documented: prometheus:pharo5 sven$ ./pharo Pharo.image --help Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] [--help] [--copyright] [--version] [--list] [ --no-quit ] --help print this help message --copyright print the copyrights --version print the version for the image and the vm --list list a description of all active command line handlers --no-quit keep the image running without activating any other command line handler <subcommand> a valid subcommand in --list Documentation: A BasicCommandLineHandler handles default command line arguments and options. It clearly says "without activating any other command line handler". So using --no-quit BEFORE the subcommand annihilates the subcommand (AFAIU). > On 12 Jan 2016, at 11:28, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > So --no-quit should be removed from the default line handler? > > Vincent > >> -----Message d'origine----- >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Esteban Lorenzano >> EnvoyÃ© : mardi 12 janvier 2016 11:18 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS? >> >> But you cannot use it as a general command. >> If you use a subcommand (most likely) then you do not have it unless the >> subcommand defines it. >> >> Esteban >> >>> On 12 Jan 2016, at 11:12, Blondeau Vincent >> <vincent.blondeau(a)worldline.com> wrote: >>> >>> >>> >>>> -----Message d'origine----- >>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part >>>> de Sven Van Caekenberghe EnvoyÃ© : mardi 12 janvier 2016 10:57 Ã : >>>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on >>>> CentOS? >>>> >>>> >>>>>> On 12 Jan 2016, at 10:50, Esteban Lorenzano <estebanlm(a)gmail.com> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >>>>>> >>>>>> >>>>>>> On 12 Jan 2016, at 10:28, Blondeau Vincent >>>> <vincent.blondeau(a)worldline.com> wrote: >>>>>>> >>>>>>> Indeed, it works. Thanks! >>>>>>> >>>>>>> But the command line usage is not clear : >>>>>>> ./pharo Pharo.image >>>>>>> Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] >>>>>>> [--help] [--copyright] [--version] [--list] [ --no-quit ] >>>>>>> >>>>>>> Maybe, it can be : >>>>>>> Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] >>>>>>> [--help] [--copyright] [--version] [--list] [ --no-quit ] >>>>>>> [<subcommand args>] >>>>>>> >>>>>>> Moreover, an option can usually be placed anywhere on the command >>>> line, shouldn't it? Or at least it should raise an error? >>>>>> >>>>>> Yes it is a bit confusion (but you could try to read/understand the >>>>>> Pharo code, it is not very difficult ;-) >>>>>> >>>>>> But the idea is that the sub-command controls its own options (like >>>>>> passing linker options via the compiler to the linker - git also >>>>>> has global and per sub command options, no ?) >>>>>> >>>>>> --no-quit probably also works for the default command ... (I >>>>>> haven't >>>> looked), so at that point, the option is consumed already. >>>>> >>>>> No, it doesn't :) >>>> >>>> prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version] >>>> 5.0 >>>> #50510 >>>> prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C >>>> >>>> The last command 'hangs' (i.e. the image keeps running, just as >> advertised). >>>> So the default (Pharo, subclass of BasicCommandHandler) interpreted >>>> the -- no-quit and acted upon it. No ? >>> >>> Yes! See: BasicCommandLineHandler>>handleArgument: >>>> >>>>>> >>>>>>> Vincent > > > > 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.

Jan. 12, 2016

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

by Skip Lentz

Haha, donât worry. You donât have to shut up, in fact I thank you for replying. I donât know exactly how it has been implemented, I had a look see and it seems to be like this: It seems to collect all methods that will be checked for coverage, and then instantiate a wrapper around each one, and replace the method with the wrapper in the method dictionary of the class (and restore it afterwards, obviously). Maybe it should only lock the threads that were _not_ started by the âtest threadâ? Iâm not even sure that is possible, just suggesting things. > On Jan 12, 2016, at 11:11 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > The coverage seems to be implemented by 'locking' the current execution thread exclusively, which would mean no other threads can run, at all. So code depending on multi threading, like client/server code, like HTTP, cannot work. Yes that seems to be a limitation, but an understandable one. > > I am trying to help but I don't known anything about the coverage tool, so maybe I should shut up ;-) > >> On 12 Jan 2016, at 11:05, Skip Lentz <skip.lentz(a)inria.fr> wrote: >> >> You mean as in it can check the coverage effected by the code running in the other thread? >> Or is this not what you mean? >> >> Well I mean, at least it can show the coverage done by what was run in the same thread.. >> And it will at least not hang or fail. >> >>> On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> I never used that, but it seems coverage can only deal with single threaded code, which sounds logical. No ? >>> >>>> On 12 Jan 2016, at 10:53, Skip Lentz <skip.lentz(a)inria.fr> wrote: >>>> >>>> Hi, >>>> >>>> When I want to run the coverage of for example Zincâs Client and Server tests, >>>> it will either hang (in the case of Zincâs test cases) or fail because the coverage >>>> uses BlockClosure>>valueUnpreemptively for running the tests. >>>> The relevant method is TestRunner>>collectCoverageFor:. >>>> >>>> So when a test is run, it is not able to be preempted by another process, like for >>>> example a local server which is needed to run the actual test in Zincâs case. >>>> >>>> When I use BlockClosure>>valueUninterruptably it works. Can someone tell me >>>> if it is wrong to use that instead? Is valueUnpreemptively necessary in this case, >>>> and if so, why? >>>> >>>> To reproduce: Load fresh image, select Zinc's ZnClientTests and ZnServerTests, >>>> click on âRun Coverageâ -> hanging image. >>>> >>>> Thanks, >>>> >>>> Skip >>> >>> >> >> > >

Jan. 12, 2016

Re: [Pharo-dev] Pharo50 spur works on CentOS?

by Blondeau Vincent

So --no-quit should be removed from the default line handler? Vincent > -----Message d'origine----- > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de > Esteban Lorenzano > EnvoyÃ© : mardi 12 janvier 2016 11:18 > Ã : Pharo Development List > Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS? > > But you cannot use it as a general command. > If you use a subcommand (most likely) then you do not have it unless the > subcommand defines it. > > Esteban > > > On 12 Jan 2016, at 11:12, Blondeau Vincent > <vincent.blondeau(a)worldline.com> wrote: > > > > > > > >> -----Message d'origine----- > >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part > >> de Sven Van Caekenberghe EnvoyÃ© : mardi 12 janvier 2016 10:57 Ã : > >> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works on > >> CentOS? > >> > >> > >>>> On 12 Jan 2016, at 10:50, Esteban Lorenzano <estebanlm(a)gmail.com> > >>> wrote: > >>> > >>> > >>> > >>>> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>> > >>>> > >>>>> On 12 Jan 2016, at 10:28, Blondeau Vincent > >> <vincent.blondeau(a)worldline.com> wrote: > >>>>> > >>>>> Indeed, it works. Thanks! > >>>>> > >>>>> But the command line usage is not clear : > >>>>> ./pharo Pharo.image > >>>>> Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] > >>>>> [--help] [--copyright] [--version] [--list] [ --no-quit ] > >>>>> > >>>>> Maybe, it can be : > >>>>> Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] > >>>>> [--help] [--copyright] [--version] [--list] [ --no-quit ] > >>>>> [<subcommand args>] > >>>>> > >>>>> Moreover, an option can usually be placed anywhere on the command > >> line, shouldn't it? Or at least it should raise an error? > >>>> > >>>> Yes it is a bit confusion (but you could try to read/understand the > >>>> Pharo code, it is not very difficult ;-) > >>>> > >>>> But the idea is that the sub-command controls its own options (like > >>>> passing linker options via the compiler to the linker - git also > >>>> has global and per sub command options, no ?) > >>>> > >>>> --no-quit probably also works for the default command ... (I > >>>> haven't > >> looked), so at that point, the option is consumed already. > >>> > >>> No, it doesn't :) > >> > >> prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version] > >> 5.0 > >> #50510 > >> prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C > >> > >> The last command 'hangs' (i.e. the image keeps running, just as > advertised). > >> So the default (Pharo, subclass of BasicCommandHandler) interpreted > >> the -- no-quit and acted upon it. No ? > > > > Yes! See: BasicCommandLineHandler>>handleArgument: > >> > >>>> > >>>>> Vincent 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.

Jan. 12, 2016

Re: [Pharo-dev] Pharo50 spur works on CentOS?

by Esteban Lorenzano

But you cannot use it as a general command. If you use a subcommand (most likely) then you do not have it unless the subcommand defines it. Esteban > On 12 Jan 2016, at 11:12, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > > >> -----Message d'origine----- >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Sven Van Caekenberghe >> EnvoyÃ© : mardi 12 janvier 2016 10:57 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS? >> >> >>>> On 12 Jan 2016, at 10:50, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>> >>> >>>> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> >>>>> On 12 Jan 2016, at 10:28, Blondeau Vincent >> <vincent.blondeau(a)worldline.com> wrote: >>>>> >>>>> Indeed, it works. Thanks! >>>>> >>>>> But the command line usage is not clear : >>>>> ./pharo Pharo.image >>>>> Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] >>>>> [--help] [--copyright] [--version] [--list] [ --no-quit ] >>>>> >>>>> Maybe, it can be : >>>>> Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] >>>>> [--help] [--copyright] [--version] [--list] [ --no-quit ] >>>>> [<subcommand args>] >>>>> >>>>> Moreover, an option can usually be placed anywhere on the command >> line, shouldn't it? Or at least it should raise an error? >>>> >>>> Yes it is a bit confusion (but you could try to read/understand the >>>> Pharo code, it is not very difficult ;-) >>>> >>>> But the idea is that the sub-command controls its own options (like >>>> passing linker options via the compiler to the linker - git also has >>>> global and per sub command options, no ?) >>>> >>>> --no-quit probably also works for the default command ... (I haven't >> looked), so at that point, the option is consumed already. >>> >>> No, it doesn't :) >> >> prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version] 5.0 >> #50510 >> prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C >> >> The last command 'hangs' (i.e. the image keeps running, just as advertised). >> So the default (Pharo, subclass of BasicCommandHandler) interpreted the -- >> no-quit and acted upon it. No ? > > Yes! See: BasicCommandLineHandler>>handleArgument: >> >>>> >>>>> Vincent >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la >>>>>> part de Esteban Lorenzano EnvoyÃ© : lundi 11 janvier 2016 19:21 Ã : >>>>>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works >>>>>> on CentOS? >>>>>> >>>>>> >>>>>>> On 11 Jan 2016, at 19:06, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >>>>>>> >>>>>>> Is it not ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: >> 8080' >>>>>>> >>>>>>> ? >>>>>>> >>>>>>> I.e. the --no-quit AFTER the eval. >>>>>> >>>>>> yes, is like that :) >>>>>> >>>>>>> >>>>>>> http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/#runningarealclou >>>>>>> dser >>>>>>> ver >>>>>>> >>>>>>>> On 11 Jan 2016, at 18:46, Blondeau Vincent >>>>>> <vincent.blondeau(a)worldline.com> wrote: >>>>>>>> >>>>>>>> The .sources are in the vm folder. >>>>>>>> >>>>>>>> And, it is working, but without the âno-quit option and this kind of >> code : >>>>>>>> [ZnServer startOn: 8080] fork. (Delay forSeconds: 20) wait >>>>>>>> >>>>>>>> The âno-quit option seems to have a bad influenceâ¦ >>>>>>>> >>>>>>>> Can you tell me which packages you installed? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Vincent >>>>>>>> >>>>>>>> >>>>>>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la >>>>>>>> part de Mariano Martinez Peck EnvoyÃ© : lundi 11 janvier 2016 18:27 Ã >> : >>>>>>>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works >>>>>>>> on CentOS? >>>>>>>> >>>>>>>> It does work for me in CentOS. >>>>>>>> Are you sure .sources file is in the correct place? >>>>>>>> >>>>>>>> On Mon, Jan 11, 2016 at 1:55 PM, Blondeau Vincent >>>>>> <vincent.blondeau(a)worldline.com> wrote: >>>>>>>> Thanks for your answer. >>>>>>>> >>>>>>>> However, it seems that the server does not start with: >>>>>>>> ./pharo -vm-display-null -vm-sound-null Pharo.image --no-quit >>>>>>>> eval >>>>>> "ZnServer startOn: 8080." >>>>>>>> Nothing in the terminal and no open port in "netstat -an" >>>>>>>> >>>>>>>> While, this command is writing something in the terminal: >>>>>>>> ./pharo -vm-display-null -vm-sound-null Pharo.image eval >>>>>>>> "ZnServer >>>>>> startOn: 8080." >>>>>>>> a ZnManagingMultiThreadedServer(running 8080) >>>>>>>> >>>>>>>> Vincent >>>>>>>> >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la >>>>>>>>> part de Sven Van Caekenberghe EnvoyÃ© : lundi 11 janvier 2016 17:03 >> Ã : >>>>>>>>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur >>>>>>>>> works on CentOS? >>>>>>>>> >>>>>>>>> >>>>>>>>>>> On 11 Jan 2016, at 16:51, Blondeau Vincent >>>>>>>>>> <vincent.blondeau(a)worldline.com> wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I just wanted to run a latest Pharo image on a CentOS server to >>>>>>>>>> run a Zinc >>>>>>>>> server. >>>>>>>>>> So I did: >>>>>>>>>> curl get.pharo.org/50+vm | bash >>>>>>>>>> >>>>>>>>>> ./pharo Pharo.image eval â1+1â evals to 2 >>>>>>>>>> >>>>>>>>>> But, >>>>>>>>>> ./pharo Pharo.image --no-quit eval "ZnServer startOn: 8080." >>>>>>>>>> returns: >>>>>>>>>> ioLoadModule(/root/Pharo/pharo-vm/libFT2Plugin.so): >>>>>>>>>> libfreetype.so.6: cannot open shared object file: No such file >>>>>>>>>> or directory >>>>>>>>>> >>>>>>>>>> So the server is not launchedâ¦ >>>>>>>>>> >>>>>>>>>> What are the libs that should be installed on the machine? >>>>>>>>>> Should I take >>>>>>>>> another VM? >>>>>>>>>> >>>>>>>>>> BTW, why a headless image needs a freetype lib? >>>>>>>>> >>>>>>>>> Yeah, that should not be the case: >>>>>>>>> >>>>>>>>> http://forum.world.st/Confused-about-libFT2Plugin-tt4842354.html >>>>>>>>> >>>>>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Mariano >>>>>>>> http://marianopeck.wordpress.com >>>>>>>> >>>>>>>> >>>>>>>> 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. > > > > 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.

Jan. 12, 2016

Re: [Pharo-dev] Pharo50 spur works on CentOS?

by Blondeau Vincent

> -----Message d'origine----- > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de > Sven Van Caekenberghe > EnvoyÃ© : mardi 12 janvier 2016 10:57 > Ã : Pharo Development List > Objet : Re: [Pharo-dev] Pharo50 spur works on CentOS? > > > > On 12 Jan 2016, at 10:50, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > > > > >> On 12 Jan 2016, at 10:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> > >>> On 12 Jan 2016, at 10:28, Blondeau Vincent > <vincent.blondeau(a)worldline.com> wrote: > >>> > >>> Indeed, it works. Thanks! > >>> > >>> But the command line usage is not clear : > >>> ./pharo Pharo.image > >>> Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] > >>> [--help] [--copyright] [--version] [--list] [ --no-quit ] > >>> > >>> Maybe, it can be : > >>> Usage: [--no-preferences|--preference-file=<FILE>][<subcommand>] > >>> [--help] [--copyright] [--version] [--list] [ --no-quit ] > >>> [<subcommand args>] > >>> > >>> Moreover, an option can usually be placed anywhere on the command > line, shouldn't it? Or at least it should raise an error? > >> > >> Yes it is a bit confusion (but you could try to read/understand the > >> Pharo code, it is not very difficult ;-) > >> > >> But the idea is that the sub-command controls its own options (like > >> passing linker options via the compiler to the linker - git also has > >> global and per sub command options, no ?) > >> > >> --no-quit probably also works for the default command ... (I haven't > looked), so at that point, the option is consumed already. > > > > No, it doesn't :) > > prometheus:pharo5 sven$ ./pharo Pharo.image printVersion [version] 5.0 > #50510 > prometheus:pharo5 sven$ ./pharo Pharo.image --no-quit ^C > > The last command 'hangs' (i.e. the image keeps running, just as advertised). > So the default (Pharo, subclass of BasicCommandHandler) interpreted the -- > no-quit and acted upon it. No ? Yes! See: BasicCommandLineHandler>>handleArgument: > > >> > >>> Vincent > >>> > >>>> -----Message d'origine----- > >>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la > >>>> part de Esteban Lorenzano EnvoyÃ© : lundi 11 janvier 2016 19:21 Ã : > >>>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works > >>>> on CentOS? > >>>> > >>>> > >>>>> On 11 Jan 2016, at 19:06, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>> > >>>>> Is it not ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: > 8080' > >>>>> > >>>>> ? > >>>>> > >>>>> I.e. the --no-quit AFTER the eval. > >>>> > >>>> yes, is like that :) > >>>> > >>>>> > >>>>> http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/#runningarealclou > >>>>> dser > >>>>> ver > >>>>> > >>>>>> On 11 Jan 2016, at 18:46, Blondeau Vincent > >>>> <vincent.blondeau(a)worldline.com> wrote: > >>>>>> > >>>>>> The .sources are in the vm folder. > >>>>>> > >>>>>> And, it is working, but without the âno-quit option and this kind of > code : > >>>>>> [ZnServer startOn: 8080] fork. (Delay forSeconds: 20) wait > >>>>>> > >>>>>> The âno-quit option seems to have a bad influenceâ¦ > >>>>>> > >>>>>> Can you tell me which packages you installed? > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> Vincent > >>>>>> > >>>>>> > >>>>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la > >>>>>> part de Mariano Martinez Peck EnvoyÃ© : lundi 11 janvier 2016 18:27 Ã > : > >>>>>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur works > >>>>>> on CentOS? > >>>>>> > >>>>>> It does work for me in CentOS. > >>>>>> Are you sure .sources file is in the correct place? > >>>>>> > >>>>>> On Mon, Jan 11, 2016 at 1:55 PM, Blondeau Vincent > >>>> <vincent.blondeau(a)worldline.com> wrote: > >>>>>> Thanks for your answer. > >>>>>> > >>>>>> However, it seems that the server does not start with: > >>>>>> ./pharo -vm-display-null -vm-sound-null Pharo.image --no-quit > >>>>>> eval > >>>> "ZnServer startOn: 8080." > >>>>>> Nothing in the terminal and no open port in "netstat -an" > >>>>>> > >>>>>> While, this command is writing something in the terminal: > >>>>>> ./pharo -vm-display-null -vm-sound-null Pharo.image eval > >>>>>> "ZnServer > >>>> startOn: 8080." > >>>>>> a ZnManagingMultiThreadedServer(running 8080) > >>>>>> > >>>>>> Vincent > >>>>>> > >>>>>>> -----Message d'origine----- > >>>>>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la > >>>>>>> part de Sven Van Caekenberghe EnvoyÃ© : lundi 11 janvier 2016 17:03 > Ã : > >>>>>>> Pharo Development List Objet : Re: [Pharo-dev] Pharo50 spur > >>>>>>> works on CentOS? > >>>>>>> > >>>>>>> > >>>>>>>>> On 11 Jan 2016, at 16:51, Blondeau Vincent > >>>>>>>> <vincent.blondeau(a)worldline.com> wrote: > >>>>>>>> > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> I just wanted to run a latest Pharo image on a CentOS server to > >>>>>>>> run a Zinc > >>>>>>> server. > >>>>>>>> So I did: > >>>>>>>> curl get.pharo.org/50+vm | bash > >>>>>>>> > >>>>>>>> ./pharo Pharo.image eval â1+1â evals to 2 > >>>>>>>> > >>>>>>>> But, > >>>>>>>> ./pharo Pharo.image --no-quit eval "ZnServer startOn: 8080." > >>>>>>>> returns: > >>>>>>>> ioLoadModule(/root/Pharo/pharo-vm/libFT2Plugin.so): > >>>>>>>> libfreetype.so.6: cannot open shared object file: No such file > >>>>>>>> or directory > >>>>>>>> > >>>>>>>> So the server is not launchedâ¦ > >>>>>>>> > >>>>>>>> What are the libs that should be installed on the machine? > >>>>>>>> Should I take > >>>>>>> another VM? > >>>>>>>> > >>>>>>>> BTW, why a headless image needs a freetype lib? > >>>>>>> > >>>>>>> Yeah, that should not be the case: > >>>>>>> > >>>>>>> http://forum.world.st/Confused-about-libFT2Plugin-tt4842354.html > >>>>>>> > >>>>>>>> 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. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Mariano > >>>>>> http://marianopeck.wordpress.com > >>>>>> > >>>>>> > >>>>>> 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. > >> > >> > > > 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.

Jan. 12, 2016

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

by Sven Van Caekenberghe

The coverage seems to be implemented by 'locking' the current execution thread exclusively, which would mean no other threads can run, at all. So code depending on multi threading, like client/server code, like HTTP, cannot work. Yes that seems to be a limitation, but an understandable one. I am trying to help but I don't known anything about the coverage tool, so maybe I should shut up ;-) > On 12 Jan 2016, at 11:05, Skip Lentz <skip.lentz(a)inria.fr> wrote: > > You mean as in it can check the coverage effected by the code running in the other thread? > Or is this not what you mean? > > Well I mean, at least it can show the coverage done by what was run in the same thread.. > And it will at least not hang or fail. > >> On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I never used that, but it seems coverage can only deal with single threaded code, which sounds logical. No ? >> >>> On 12 Jan 2016, at 10:53, Skip Lentz <skip.lentz(a)inria.fr> wrote: >>> >>> Hi, >>> >>> When I want to run the coverage of for example Zincâs Client and Server tests, >>> it will either hang (in the case of Zincâs test cases) or fail because the coverage >>> uses BlockClosure>>valueUnpreemptively for running the tests. >>> The relevant method is TestRunner>>collectCoverageFor:. >>> >>> So when a test is run, it is not able to be preempted by another process, like for >>> example a local server which is needed to run the actual test in Zincâs case. >>> >>> When I use BlockClosure>>valueUninterruptably it works. Can someone tell me >>> if it is wrong to use that instead? Is valueUnpreemptively necessary in this case, >>> and if so, why? >>> >>> To reproduce: Load fresh image, select Zinc's ZnClientTests and ZnServerTests, >>> click on âRun Coverageâ -> hanging image. >>> >>> Thanks, >>> >>> Skip >> >> > >

Jan. 12, 2016

Re: [Pharo-dev] Test Runner: "Run Coverage" fails or hangs when multithreading is used in test.

by Skip Lentz

"can NOT check"*, in the first sentence. > On Jan 12, 2016, at 11:05 AM, Skip Lentz <skip.lentz(a)inria.fr> wrote: > > You mean as in it can check the coverage effected by the code running in the other thread? > Or is this not what you mean? > > Well I mean, at least it can show the coverage done by what was run in the same thread.. > And it will at least not hang or fail. > >> On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I never used that, but it seems coverage can only deal with single threaded code, which sounds logical. No ? >> >>> On 12 Jan 2016, at 10:53, Skip Lentz <skip.lentz(a)inria.fr> wrote: >>> >>> Hi, >>> >>> When I want to run the coverage of for example Zincâs Client and Server tests, >>> it will either hang (in the case of Zincâs test cases) or fail because the coverage >>> uses BlockClosure>>valueUnpreemptively for running the tests. >>> The relevant method is TestRunner>>collectCoverageFor:. >>> >>> So when a test is run, it is not able to be preempted by another process, like for >>> example a local server which is needed to run the actual test in Zincâs case. >>> >>> When I use BlockClosure>>valueUninterruptably it works. Can someone tell me >>> if it is wrong to use that instead? Is valueUnpreemptively necessary in this case, >>> and if so, why? >>> >>> To reproduce: Load fresh image, select Zinc's ZnClientTests and ZnServerTests, >>> click on âRun Coverageâ -> hanging image. >>> >>> Thanks, >>> >>> Skip >> >> >

Jan. 12, 2016