July 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] strange question

by Sven Van Caekenberghe

Hi Werner, On 29 Jul 2014, at 14:50, Werner Kassens <wkassens(a)libello.com> wrote: > Hi, > is there a way for a method, to look up the name of the method from where itself was called ? > werner That is what thisContext is for (one of the few special variables, like self and super). Use the Finder to search for all occurrences of thisContext in the Source code. I think your particular question is answered as follows: thisContext sender method HTH, Sven

July 29, 2014

Re: [Pharo-users] strange question

by FranÃ§ois Stephany

You might want to dig into thisContext. "thisContext sender" is probably what you need. On Tue, Jul 29, 2014 at 2:50 PM, Werner Kassens <wkassens(a)libello.com> wrote: > Hi, > is there a way for a method, to look up the name of the method from where > itself was called ? > werner > >

July 29, 2014

strange question

by Werner Kassens

Hi, is there a way for a method, to look up the name of the method from where itself was called ? werner

July 29, 2014

Re: [Pharo-users] Writing on stdout when redirecting the standard output

by FranÃ§ois Stephany

Yep, we haven't measured yet how slower it gets but we don't have a lot of traffic for this logger. It was annoying to have a delay when observing logs so we flush the stream all the time. We were also afraid of missing information in the case of a pharo crash (hopefully that doesnt happen too much ;)) On Tue, Jul 29, 2014 at 10:06 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 29 Jul 2014, at 09:49, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> > wrote: > > > Uh. We nailed it. > > Good ! > > > We implemented a custom Logger writing to stdout because the default one > doesn't flush the stream immediately after writing to it. > > Beware that flushing after every line is measurably slower. > > > One of our configuration was configuring a logger and another was > reconfiguring it. The stdout stream was probably closed in the process > somewhere. > > > > In conclusion, beware of your loggers ;) > > > > > > > > On Tue, Jul 29, 2014 at 8:32 AM, FranÃ§ois Stephany < > tulipe.moutarde(a)gmail.com> wrote: > > Yes, it works for me on OSX.l But it says "FileWriteError: File stdout > is closed" when doing exactly the same thing on the Arch Linux of one of > our programmer. > > > > We'll investigate and test on another Linux distro... > > > > > > On Mon, Jul 28, 2014 at 10:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > I think we need a better bug report, for me (Mac OS X) this works fine: > > > > $ ./pharo Pharo.image eval 'FileStream stdout nextPutAll: 42 factorial > asString; cr. #done' > out.txt > > > > $ cat out.txt > > 1405006117752879898543142606244511569936384000000000 > > #done > > > > So, what exactly is not working ? > > > > On 28 Jul 2014, at 21:30, stepharo <stepharo(a)free.fr> wrote: > > > > > Francois > > > > > > can you open a bug entry because this is not nice. > > > > > > Stef > > > > > > On 28/7/14 16:46, FranÃ§ois Stephany wrote: > > >> > > >> $ pharo Pharo-30852.image > /tmp/test.log > > >> > > >> Outputting somethind to stdout results in: > > >> "FileWriteError: File stdout is closed" > > >> > > >> * Arch Linux > > >> * Pharo 30852. > > >> > > >> $ pharo --version > > >> > > >> 3.9-7 #1 Thu May 15 18:29:30 CEST 2014 gcc 4.6.3 [Production ITHB VM] > > >> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > > >> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > > >> https://github.com/pharo-project/pharo-vm.git Commit: > ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 > > >> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 > 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux > > >> > > >> > > >> Did I miss something? > > >> > > > > > > > > > > > > > >

July 29, 2014

Re: [Pharo-users] Writing on stdout when redirecting the standard output

by Sven Van Caekenberghe

On 29 Jul 2014, at 09:49, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > Uh. We nailed it. Good ! > We implemented a custom Logger writing to stdout because the default one doesn't flush the stream immediately after writing to it. Beware that flushing after every line is measurably slower. > One of our configuration was configuring a logger and another was reconfiguring it. The stdout stream was probably closed in the process somewhere. > > In conclusion, beware of your loggers ;) > > > > On Tue, Jul 29, 2014 at 8:32 AM, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > Yes, it works for me on OSX.l But it says "FileWriteError: File stdout is closed" when doing exactly the same thing on the Arch Linux of one of our programmer. > > We'll investigate and test on another Linux distro... > > > On Mon, Jul 28, 2014 at 10:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I think we need a better bug report, for me (Mac OS X) this works fine: > > $ ./pharo Pharo.image eval 'FileStream stdout nextPutAll: 42 factorial asString; cr. #done' > out.txt > > $ cat out.txt > 1405006117752879898543142606244511569936384000000000 > #done > > So, what exactly is not working ? > > On 28 Jul 2014, at 21:30, stepharo <stepharo(a)free.fr> wrote: > > > Francois > > > > can you open a bug entry because this is not nice. > > > > Stef > > > > On 28/7/14 16:46, FranÃ§ois Stephany wrote: > >> > >> $ pharo Pharo-30852.image > /tmp/test.log > >> > >> Outputting somethind to stdout results in: > >> "FileWriteError: File stdout is closed" > >> > >> * Arch Linux > >> * Pharo 30852. > >> > >> $ pharo --version > >> > >> 3.9-7 #1 Thu May 15 18:29:30 CEST 2014 gcc 4.6.3 [Production ITHB VM] > >> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > >> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > >> https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 > >> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux > >> > >> > >> Did I miss something? > >> > > > > > >

July 29, 2014

Re: [Pharo-users] Writing on stdout when redirecting the standard output

by FranÃ§ois Stephany

Uh. We nailed it. We implemented a custom Logger writing to stdout because the default one doesn't flush the stream immediately after writing to it. One of our configuration was configuring a logger and another was reconfiguring it. The stdout stream was probably closed in the process somewhere. In conclusion, beware of your loggers ;) On Tue, Jul 29, 2014 at 8:32 AM, FranÃ§ois Stephany < tulipe.moutarde(a)gmail.com> wrote: > Yes, it works for me on OSX.l But it says "FileWriteError: File stdout is > closed" when doing exactly the same thing on the Arch Linux of one of our > programmer. > > We'll investigate and test on another Linux distro... > > > On Mon, Jul 28, 2014 at 10:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> I think we need a better bug report, for me (Mac OS X) this works fine: >> >> $ ./pharo Pharo.image eval 'FileStream stdout nextPutAll: 42 factorial >> asString; cr. #done' > out.txt >> >> $ cat out.txt >> 1405006117752879898543142606244511569936384000000000 >> #done >> >> So, what exactly is not working ? >> >> On 28 Jul 2014, at 21:30, stepharo <stepharo(a)free.fr> wrote: >> >> > Francois >> > >> > can you open a bug entry because this is not nice. >> > >> > Stef >> > >> > On 28/7/14 16:46, FranÃ§ois Stephany wrote: >> >> >> >> $ pharo Pharo-30852.image > /tmp/test.log >> >> >> >> Outputting somethind to stdout results in: >> >> "FileWriteError: File stdout is closed" >> >> >> >> * Arch Linux >> >> * Pharo 30852. >> >> >> >> $ pharo --version >> >> >> >> 3.9-7 #1 Thu May 15 18:29:30 CEST 2014 gcc 4.6.3 [Production ITHB VM] >> >> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 >> >> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 >> >> https://github.com/pharo-project/pharo-vm.git Commit: >> ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 >> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 >> >> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 >> 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux >> >> >> >> >> >> Did I miss something? >> >> >> > >> >> >> >

July 29, 2014

Re: [Pharo-users] Writing on stdout when redirecting the standard output

by FranÃ§ois Stephany

Yes, it works for me on OSX.l But it says "FileWriteError: File stdout is closed" when doing exactly the same thing on the Arch Linux of one of our programmer. We'll investigate and test on another Linux distro... On Mon, Jul 28, 2014 at 10:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I think we need a better bug report, for me (Mac OS X) this works fine: > > $ ./pharo Pharo.image eval 'FileStream stdout nextPutAll: 42 factorial > asString; cr. #done' > out.txt > > $ cat out.txt > 1405006117752879898543142606244511569936384000000000 > #done > > So, what exactly is not working ? > > On 28 Jul 2014, at 21:30, stepharo <stepharo(a)free.fr> wrote: > > > Francois > > > > can you open a bug entry because this is not nice. > > > > Stef > > > > On 28/7/14 16:46, FranÃ§ois Stephany wrote: > >> > >> $ pharo Pharo-30852.image > /tmp/test.log > >> > >> Outputting somethind to stdout results in: > >> "FileWriteError: File stdout is closed" > >> > >> * Arch Linux > >> * Pharo 30852. > >> > >> $ pharo --version > >> > >> 3.9-7 #1 Thu May 15 18:29:30 CEST 2014 gcc 4.6.3 [Production ITHB VM] > >> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > >> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > >> https://github.com/pharo-project/pharo-vm.git Commit: > ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 > >> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 > 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux > >> > >> > >> Did I miss something? > >> > > > > >

July 29, 2014

Re: [Pharo-users] Writing on stdout when redirecting the standard output

by Sven Van Caekenberghe

I think we need a better bug report, for me (Mac OS X) this works fine: $ ./pharo Pharo.image eval 'FileStream stdout nextPutAll: 42 factorial asString; cr. #done' > out.txt $ cat out.txt 1405006117752879898543142606244511569936384000000000 #done So, what exactly is not working ? On 28 Jul 2014, at 21:30, stepharo <stepharo(a)free.fr> wrote: > Francois > > can you open a bug entry because this is not nice. > > Stef > > On 28/7/14 16:46, FranÃ§ois Stephany wrote: >> >> $ pharo Pharo-30852.image > /tmp/test.log >> >> Outputting somethind to stdout results in: >> "FileWriteError: File stdout is closed" >> >> * Arch Linux >> * Pharo 30852. >> >> $ pharo --version >> >> 3.9-7 #1 Thu May 15 18:29:30 CEST 2014 gcc 4.6.3 [Production ITHB VM] >> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 >> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 >> https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 >> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux >> >> >> Did I miss something? >> >

July 28, 2014

Re: [Pharo-users] Writing on stdout when redirecting the standard output

by stepharo

Francois can you open a bug entry because this is not nice. Stef On 28/7/14 16:46, FranÃ§ois Stephany wrote: > > $ pharo Pharo-30852.image > /tmp/test.log > > Outputting somethind to stdout results in: > "FileWriteError: File stdout is closed" > > * Arch Linux > * Pharo 30852. > > $ pharo --version > > 3.9-7 #1 Thu May 15 18:29:30 CEST 2014 gcc 4.6.3 [Production ITHB VM] > NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > https://github.com/pharo-project/pharo-vm.git Commit: > ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 > +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> Jenkins build #14826 > Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 > 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux > > > Did I miss something? >

July 28, 2014

Re: [Pharo-users] Writing on stdout when redirecting the standard output

by Robert Shiplett

ex Google on "rlwrap" STDIN STDOUT redirection On 28 July 2014 14:01, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Mmh, I have been experiencing that too. > > Stdin and stdout aren't that well handled it seems. I write to the term > using VTerm fwiw. > > Phil > Le 28 juil. 2014 16:46, "FranÃ§ois Stephany" <tulipe.moutarde(a)gmail.com> a > Ã©crit : > >> >> $ pharo Pharo-30852.image > /tmp/test.log >> >> Outputting somethind to stdout results in: >> "FileWriteError: File stdout is closed" >> >> * Arch Linux >> * Pharo 30852. >> >> $ pharo --version >> >> 3.9-7 #1 Thu May 15 18:29:30 CEST 2014 gcc 4.6.3 [Production ITHB VM] >> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 >> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 >> https://github.com/pharo-project/pharo-vm.git Commit: >> ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 >> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 >> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 >> UTC 2012 i686 i686 i386 GNU/Linux >> >> >> Did I miss something? >> >>

July 28, 2014