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

Re: [Pharo-dev] OSProcess bug ?

by Levente Uzonyi

Another possibility is that the program is writing to stderr instead of stdout. Levente On Wed, 25 Feb 2015, David T. Lewis wrote: > Hi Jannik, > > One other thing I just thought of: Check and see if your rostopic program > is actually writing to standard output, as opposed to writing directly to > /dev/tty. From a terminal window, I think you could do this: > > $ rostopic > out.txt > > If you run this get output written to the out.txt file, that is good. If > you run it and see output to your terminal window, it would mean that the > rostopic program was writing directly to /dev/tty (so there would never be > any output to read with a PipeableOSProcess). > > I would not worry about the missing AioPlugin. Your code should still work > without the plugin. > > Dave > > >> Hi Dave, >> >> 2015-02-25 1:13 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: >> >>> On Tue, Feb 24, 2015 at 08:33:41PM +0100, jannik laval wrote: >>>> Hi pharoers, >>>> >>>> I am playing with OSProcess. >>>> I am using an example, and I am annoyed with a strange bug: >>>> >>>> Here is the code I want to execute, and does not work: >>>> ==== >>>> |thread process output| >>>> myCmd := 'rostopic bw /turtle1/pose'. >>>> thread := [process := (PipeableOSProcess command: myCmd) ] fork. >>>> 3 second wait. >>>> output := process upToEnd. >>>> output inspect. >>>> thread terminate. >>>> === >>> >>> Hi Jannik, >>> >>> I am not familiar with the rostopic command, but it is common for some >>> Unix programs to flush their output when the stdout is connected to >>> /dev/tty (a terminal), but not necessarily if connected to a pipe or >>> to a file. So it may be that the running rostopic program is producing >>> output, but that the output has not yet been flushed to the pipe >>> connected >>> to your PipeableOSProcess. >>> >> >> Thank you for your explanation. >> So, what I can do is to send a sigint to terminate the process and receive >> the info. >> But sending "process processProxy sigint." does nothing. >> >> By the way I have a warning on the AIOPlugin... Probably I should >> reinstall >> my VM. >> >> I also try "process flush", but it does not do anything. >> >> >> >>> >>> Your #upToEnd call will read the available data from the OS pipe, but it >>> will not read data that was "written" by the rotopic program, but not >>> yet flushed out to the OSPipe. So I am guessing that this may be why the >>> data seems to be missing. >>> >>> I notice also that you are putting your PipeableOSProcess into a >>> separate >>> Smalltalk process using #fork. This is probably not necessary, so try >>> getting rid of the #fork and the later thread terminate. It will not fix >>> the problem for you, but it will simplify the code. >>> >> >> >> Ok, it is simpler like that. You are right, it does not help :) >> >> Thank you for your help. >> >> >>> >>> Dave >>> >>> >>>> >>>> 'rostopic bw /turtle1/pose' is a command that is a loop displaying the >>>> current bandwidth of a ROS process. In a terminal, it works fine. With >>>> OSProcess the output value is empty. >>>> >>>> My source code is correct: if I replace myCmd by : >>>> myCmd := 'ping localhost'. >>>> >>>> It is a loop too, and it returns a correct string. >>>> >>>> I have clearly no idea of where I have to search... Any help or >>> discussion >>>> about that would be great :) >>>> >>>> Thank you, >>>> >>>> Oups, some infos: >>>> I am using Ubuntu 14.04 >>>> Pharo3.0 with Moose 5.0, latest update: #30863 >>>> The script I use (rostopic) is a python script (does it impact ?) >>>> >>>> >>>> -- >>>> >>>> ~~Jannik Laval~~ >>>> ??cole des Mines de Douai >>>> Enseignant-chercheur >>>> http://www.jannik-laval.eu >>>> http://www.phratch.com >>>> http://www.approchealpes.info >>>> http://car.mines-douai.fr/ >>> >>> >> >> >> -- >> >> ~~Jannik Laval~~ >> Ã?cole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> http://www.phratch.com >> http://www.approchealpes.info >> http://car.mines-douai.fr/ >> > > > >

Feb. 25, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 7f3731: 40510

by Sven Van Caekenberghe

Great! > On 25 Feb 2015, at 16:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> >> Log Message: >> ----------- >> 40510 >> - Scriptloader test >> >> http://files.pharo.org/image/40/40510.zip >> >> > > We changed Scriptloader to rely on the fact that we have itâs history in the > reporsitory. This makes a lot of data not needed. (and another problem is > that the scripts are not valid in the current system, e.g. when we rename a Class). > > This removes around 160.000 lines of code, make the image smaller by 20% and > removes some load from SmalltalkHub as the Scriptloader40 package started to be > near 1MB in size. > > In addition, this brings us a tiny step closer to the ideal that âthe build server artefact should > be the release, unchangedâ. > > All this with loosing *nothing*, as the data is save and secure in the history of the package. > > > Marcus

Feb. 25, 2015

[Pharo4] Slots: ExampleSlotWithDefaultValue

by Marcus Denker

Hi, Todays small improvement: ExampleSlotWithDefaultValue now allows to set the default in the definition (it was before just hard coding a value). e.g. Object subclass: #GG slots: { #gg => ExampleSlotWithDefaultValue default: 5 } classVariables: { } category: âPlayGround' When inspecting GG new â> the slot is initialised to 5. https://pharo.fogbugz.com/f/cases/14991/ExampleSlotWithDefaultValue-allow-d… - Slot: storeOn: calls printOn: - PropertyBaseSlot: use mangeled name: #_propertyBaseSlot - ExampleSlotWithDefaultValue: set default in definition Marcus

Feb. 25, 2015

Re: [Pharo-dev] OSProcess bug ?

by David T. Lewis

Hi Jannik, One other thing I just thought of: Check and see if your rostopic program is actually writing to standard output, as opposed to writing directly to /dev/tty. From a terminal window, I think you could do this: $ rostopic > out.txt If you run this get output written to the out.txt file, that is good. If you run it and see output to your terminal window, it would mean that the rostopic program was writing directly to /dev/tty (so there would never be any output to read with a PipeableOSProcess). I would not worry about the missing AioPlugin. Your code should still work without the plugin. Dave > Hi Dave, > > 2015-02-25 1:13 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: > >> On Tue, Feb 24, 2015 at 08:33:41PM +0100, jannik laval wrote: >> > Hi pharoers, >> > >> > I am playing with OSProcess. >> > I am using an example, and I am annoyed with a strange bug: >> > >> > Here is the code I want to execute, and does not work: >> > ==== >> > |thread process output| >> > myCmd := 'rostopic bw /turtle1/pose'. >> > thread := [process := (PipeableOSProcess command: myCmd) ] fork. >> > 3 second wait. >> > output := process upToEnd. >> > output inspect. >> > thread terminate. >> > === >> >> Hi Jannik, >> >> I am not familiar with the rostopic command, but it is common for some >> Unix programs to flush their output when the stdout is connected to >> /dev/tty (a terminal), but not necessarily if connected to a pipe or >> to a file. So it may be that the running rostopic program is producing >> output, but that the output has not yet been flushed to the pipe >> connected >> to your PipeableOSProcess. >> > > Thank you for your explanation. > So, what I can do is to send a sigint to terminate the process and receive > the info. > But sending "process processProxy sigint." does nothing. > > By the way I have a warning on the AIOPlugin... Probably I should > reinstall > my VM. > > I also try "process flush", but it does not do anything. > > > >> >> Your #upToEnd call will read the available data from the OS pipe, but it >> will not read data that was "written" by the rotopic program, but not >> yet flushed out to the OSPipe. So I am guessing that this may be why the >> data seems to be missing. >> >> I notice also that you are putting your PipeableOSProcess into a >> separate >> Smalltalk process using #fork. This is probably not necessary, so try >> getting rid of the #fork and the later thread terminate. It will not fix >> the problem for you, but it will simplify the code. >> > > > Ok, it is simpler like that. You are right, it does not help :) > > Thank you for your help. > > >> >> Dave >> >> >> > >> > 'rostopic bw /turtle1/pose' is a command that is a loop displaying the >> > current bandwidth of a ROS process. In a terminal, it works fine. With >> > OSProcess the output value is empty. >> > >> > My source code is correct: if I replace myCmd by : >> > myCmd := 'ping localhost'. >> > >> > It is a loop too, and it returns a correct string. >> > >> > I have clearly no idea of where I have to search... Any help or >> discussion >> > about that would be great :) >> > >> > Thank you, >> > >> > Oups, some infos: >> > I am using Ubuntu 14.04 >> > Pharo3.0 with Moose 5.0, latest update: #30863 >> > The script I use (rostopic) is a python script (does it impact ?) >> > >> > >> > -- >> > >> > ~~Jannik Laval~~ >> > ??cole des Mines de Douai >> > Enseignant-chercheur >> > http://www.jannik-laval.eu >> > http://www.phratch.com >> > http://www.approchealpes.info >> > http://car.mines-douai.fr/ >> >> > > > -- > > ~~Jannik Laval~~ > ÃÂcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info > http://car.mines-douai.fr/ >

Feb. 25, 2015

Re: [Pharo-dev] zipped and unzipped methods for ByteArray

by Juraj Kubelka

> 25. 2. 2015 v 12:28, Sven Van Caekenberghe <sven(a)stfx.eu>: > > This seems related to adding 'easy of use' methods to String. > > There are many different compression schemes (zip, bzip, bzip2, gzip, ...), are we going to add them all ? > > How much do we want to couple different parts of the system ? I prefer to couple the compression schemes with String and ByteArray. Methods like #zipped, #unzipped are not that simple and it is not well apparent how to use that compression scheme. Cheers, Juraj > >> On 25 Feb 2015, at 16:23, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >> >> Can I add ByteArray>>#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example. >> >> Do you agree? >> Thanks, >> Juraj > >

Feb. 25, 2015

Re: [Pharo-dev] Error in MonitorDelay>>#signalLock:afterMSecs:inMonitor:queue:

by Juraj Kubelka

Both issues should be covered by SLICE-Issue-14990-MonitorDelaysignalLockafterMSecsinMonitorqueue-should-return-MonitorDelay-object-JurajKubelka.2 Thank you for the review! Juraj > 25. 2. 2015 v 12:32, Juraj Kubelka <juraj.kubelka(a)gmail.com>: > > Hi, > > it is already done: https://pharo.fogbugz.com/f/cases/14990/MonitorDelay-signalLock-afterMSecs-… <https://pharo.fogbugz.com/f/cases/14990/MonitorDelay-signalLock-afterMSecs-…> > > I will check this one too: Delay class>>timeoutSemaphore:afterMSecs: > > Cheers, > Juraj > >> 25. 2. 2015 v 12:29, Ben Coman <btc(a)openInWorld.com <mailto:btc@openInWorld.com>>: >> >> >>> 24. 2. 2015 v 16:36, Juraj Kubelka <juraj.kubelka(a)gmail.com <mailto:juraj.kubelka@gmail.com>>: >>> >>> Hi! >>> >>> I have a problem in the recent Pharo 4 image: the method MonitorDelay>>#signalLock:afterMSecs:inMonitor:queue: returns a boolean instead of MonitorDelay object. >>> And in the method Monitor>>#exitAndWaitInQueue:maxMilliseconds: it raises message not understood on #unschedule. >>> >>> Pharo #40505. >>> >>> -=-=- >>> | monitor | >>> monitor := Monitor new. >>> monitor critical: [ monitor waitWhile: [ true ] maxMilliseconds: 200 ]. >>> -=-=- >>> >>> Is it known error? Someone is changing Monitor or related code? >>> Thanks, >>> Juraj >>> >> 2015-02-24 20:45 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com <mailto:juraj.kubelka@gmail.com>>: >> Well, basically it is enough to add #yourself in to the class method: >> >> signalLock: aSemaphore afterMSecs: anInteger inMonitor: aMonitor queue: anOrderedCollection >> anInteger < 0 ifTrue: [self error: 'delay times cannot be negative']. >> ^ (self new setDelay: anInteger forSemaphore: aSemaphore monitor: aMonitor queue: anOrderedCollection) schedule; yourself >> >> But I am wondering if it is the only one affected method. >> If someone agree with this solution, I can create test case and slice. >> >> Cheers, >> Juraj >> >> >> On Wed, Feb 25, 2015 at 4:45 AM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> >> >> >> Yes, this has changed (see multiple issues on fogbugz). >> Ben Coman uses the return value in WorldState>>#interCyclePause: >> for tesing if the delay has been scheduled. >> >> I think there is a good chance that Monitor is the only class that expects the >> Delay as the return value. >> So, yes, please create a fix with your proposed solution. >> - or wait for Ben to comment on this :) >> >> nicolai >> >> Juraj, >> >> Your solution looks fine. Please go ahead to create a Fogbugz issue and submit a slice. It would be cool if your test covers the usage of that method and not "just" that it returns a particular class, since there seems no existing test for that method. I haven't had a lot to do with Monitors so it would be good to see a use case. If you notify me when you <Resolve> the issue I'll be happy to review. btw, can you cover both methods? >> >> Actually, looking through senders of #schedule, Delay class>>timeoutSemaphore:afterMSecs: suffers the same. Juraj could you cover this also? >> >> cheers -ben >

Feb. 25, 2015

Re: [Pharo-dev] Error in MonitorDelay>>#signalLock:afterMSecs:inMonitor:queue:

by Juraj Kubelka

Hi, it is already done: https://pharo.fogbugz.com/f/cases/14990/MonitorDelay-signalLock-afterMSecs-… I will check this one too: Delay class>>timeoutSemaphore:afterMSecs: Cheers, Juraj > 25. 2. 2015 v 12:29, Ben Coman <btc(a)openInWorld.com>: > > >> 24. 2. 2015 v 16:36, Juraj Kubelka <juraj.kubelka(a)gmail.com <mailto:juraj.kubelka@gmail.com>>: >> >> Hi! >> >> I have a problem in the recent Pharo 4 image: the method MonitorDelay>>#signalLock:afterMSecs:inMonitor:queue: returns a boolean instead of MonitorDelay object. >> And in the method Monitor>>#exitAndWaitInQueue:maxMilliseconds: it raises message not understood on #unschedule. >> >> Pharo #40505. >> >> -=-=- >> | monitor | >> monitor := Monitor new. >> monitor critical: [ monitor waitWhile: [ true ] maxMilliseconds: 200 ]. >> -=-=- >> >> Is it known error? Someone is changing Monitor or related code? >> Thanks, >> Juraj >> > 2015-02-24 20:45 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com <mailto:juraj.kubelka@gmail.com>>: > Well, basically it is enough to add #yourself in to the class method: > > signalLock: aSemaphore afterMSecs: anInteger inMonitor: aMonitor queue: anOrderedCollection > anInteger < 0 ifTrue: [self error: 'delay times cannot be negative']. > ^ (self new setDelay: anInteger forSemaphore: aSemaphore monitor: aMonitor queue: anOrderedCollection) schedule; yourself > > But I am wondering if it is the only one affected method. > If someone agree with this solution, I can create test case and slice. > > Cheers, > Juraj > > > On Wed, Feb 25, 2015 at 4:45 AM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: > > > > > Yes, this has changed (see multiple issues on fogbugz). > Ben Coman uses the return value in WorldState>>#interCyclePause: > for tesing if the delay has been scheduled. > > I think there is a good chance that Monitor is the only class that expects the > Delay as the return value. > So, yes, please create a fix with your proposed solution. > - or wait for Ben to comment on this :) > > nicolai > > Juraj, > > Your solution looks fine. Please go ahead to create a Fogbugz issue and submit a slice. It would be cool if your test covers the usage of that method and not "just" that it returns a particular class, since there seems no existing test for that method. I haven't had a lot to do with Monitors so it would be good to see a use case. If you notify me when you <Resolve> the issue I'll be happy to review. btw, can you cover both methods? > > Actually, looking through senders of #schedule, Delay class>>timeoutSemaphore:afterMSecs: suffers the same. Juraj could you cover this also? > > cheers -ben

Feb. 25, 2015

Re: [Pharo-dev] Error in MonitorDelay>>#signalLock:afterMSecs:inMonitor:queue:

by Ben Coman

> 24. 2. 2015 v 16:36, Juraj Kubelka <juraj.kubelka(a)gmail.com>: >> >> Hi! >> >> I have a problem in the recent Pharo 4 image: the method >> MonitorDelay>>#signalLock:afterMSecs:inMonitor:queue: returns a boolean >> instead of MonitorDelay object. >> And in the method Monitor>>#exitAndWaitInQueue:maxMilliseconds: it raises >> message not understood on #unschedule. >> >> Pharo #40505. >> >> -=-=- >> | monitor | >> monitor := Monitor new. >> monitor critical: [ monitor waitWhile: [ true ] maxMilliseconds: 200 ]. >> -=-=- >> >> Is it known error? Someone is changing Monitor or related code? >> Thanks, >> Juraj >> >> 2015-02-24 20:45 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: >> >>> Well, basically it is enough to add #yourself in to the class method: >>> >>> signalLock: aSemaphore afterMSecs: anInteger inMonitor: aMonitor queue: >>> anOrderedCollection >>> anInteger < 0 ifTrue: [self error: 'delay times cannot be negative']. >>> ^ (self new setDelay: anInteger forSemaphore: aSemaphore monitor: >>> aMonitor queue: anOrderedCollection) schedule; *yourself* >>> >>> But I am wondering if it is the only one affected method. >>> If someone agree with this solution, I can create test case and slice. >>> >>> Cheers, >>> Juraj >>> >> > On Wed, Feb 25, 2015 at 4:45 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > Yes, this has changed (see multiple issues on fogbugz). > Ben Coman uses the return value in WorldState>>#interCyclePause: > for tesing if the delay has been scheduled. > > I think there is a good chance that Monitor is the only class that expects > the > Delay as the return value. > So, yes, please create a fix with your proposed solution. > - or wait for Ben to comment on this :) > > nicolai > Juraj, Your solution looks fine. Please go ahead to create a Fogbugz issue and submit a slice. It would be cool if your test covers the usage of that method and not "just" that it returns a particular class, since there seems no existing test for that method. I haven't had a lot to do with Monitors so it would be good to see a use case. If you notify me when you <Resolve> the issue I'll be happy to review. btw, can you cover both methods? Actually, looking through senders of #schedule, Delay class>>timeoutSemaphore:afterMSecs: suffers the same. Juraj could you cover this also? cheers -ben

Feb. 25, 2015

Re: [Pharo-dev] zipped and unzipped methods for ByteArray

by Sven Van Caekenberghe

This seems related to adding 'easy of use' methods to String. There are many different compression schemes (zip, bzip, bzip2, gzip, ...), are we going to add them all ? How much do we want to couple different parts of the system ? > On 25 Feb 2015, at 16:23, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > > Can I add ByteArray>>#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example. > > Do you agree? > Thanks, > Juraj

Feb. 25, 2015

zipped and unzipped methods for ByteArray

by Juraj Kubelka

Can I add ByteArray>>#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example. Do you agree? Thanks, Juraj

Feb. 25, 2015