Hi, Just tried to install the stable version of OSProcess using the configuration browser on a 3.0. I noticed it is still on http://www.squeaksource.com/OSProcess. Does it mean it is dead? if yes, what is the alternative? Thanx Noury
Hi Noury, no, OSProcess on Squeaksource is not dead and is integrating all the changes needed for all the platforms it is running on. And as you can see, I very recently updated the configuration to make sure it was pointing to the very latest version. Regards, Thierry Le 09/10/2014 22:30, Noury Bouraqadi a écrit :
Hi,
Just tried to install the stable version of OSProcess using the configuration browser on a 3.0. I noticed it is still on http://www.squeaksource.com/OSProcess. Does it mean it is dead? if yes, what is the alternative?
Thanx Noury
Thierry, Thanks for doing those configuration updates, I hit "send" before I saw your reply. Dave
Hi Noury,
no, OSProcess on Squeaksource is not dead and is integrating all the changes needed for all the platforms it is running on.
And as you can see, I very recently updated the configuration to make sure it was pointing to the very latest version.
Regards,
Thierry
Le 09/10/2014 22:30, Noury Bouraqadi a écrit :
Hi,
Just tried to install the stable version of OSProcess using the configuration browser on a 3.0. I noticed it is still on http://www.squeaksource.com/OSProcess. Does it mean it is dead? if yes, what is the alternative?
Thanx Noury
Hi Dave, thanks to you. I updated OSProcess to 4.5.11 and CommandShell to 4.6.8; are those the latest? I did it last Sunday. Thierry Le 09/10/2014 22:42, David T. Lewis a écrit :
Thierry,
Thanks for doing those configuration updates, I hit "send" before I saw your reply.
Dave
Hi Noury,
no, OSProcess on Squeaksource is not dead and is integrating all the changes needed for all the platforms it is running on.
And as you can see, I very recently updated the configuration to make sure it was pointing to the very latest version.
Regards,
Thierry
Le 09/10/2014 22:30, Noury Bouraqadi a écrit :
Hi,
Just tried to install the stable version of OSProcess using the configuration browser on a 3.0. I noticed it is still on http://www.squeaksource.com/OSProcess. Does it mean it is dead? if yes, what is the alternative?
Thanx Noury
Darn, I think we must have both done our updates on the same day. The last update I did was this (time stamp is GMT -4 hours) : CommandShell-dtl.76 Dave Lewis, 5 October 2014 5:29:32 pm CommandShell 4.6.9 Improve pipe closing for PipeableOSProcess class>>command: and related methods to support use as stand alone command processor. An expression such as the following will now close all open handles when command processing is complete: "(PipeableOSProcess command: '/bin/echo this is a test') output" If you could update the configuration to pick this up, that would be great. I think it will be helpful for people who want to easily execute commands directly from the image. I think the two sub-packages that you would update are CommandShell-Base-dtl.38 and CommandShell-Piping-dtl.16 Thanks, Dave
Hi Dave,
thanks to you. I updated OSProcess to 4.5.11 and CommandShell to 4.6.8; are those the latest? I did it last Sunday.
Thierry
Le 09/10/2014 22:42, David T. Lewis a écrit :
Thierry,
Thanks for doing those configuration updates, I hit "send" before I saw your reply.
Dave
Hi Noury,
no, OSProcess on Squeaksource is not dead and is integrating all the changes needed for all the platforms it is running on.
And as you can see, I very recently updated the configuration to make sure it was pointing to the very latest version.
Regards,
Thierry
Le 09/10/2014 22:30, Noury Bouraqadi a écrit :
Hi,
Just tried to install the stable version of OSProcess using the configuration browser on a 3.0. I noticed it is still on http://www.squeaksource.com/OSProcess. Does it mean it is dead? if yes, what is the alternative?
Thanx Noury
Le 9 oct. 2014 23:15, "David T. Lewis" <lewis@mail.msen.com> a écrit :
Darn, I think we must have both done our updates on the same day. The last update I did was this (time stamp is GMT -4 hours) :
CommandShell-dtl.76 Dave Lewis, 5 October 2014 5:29:32 pm CommandShell 4.6.9
Improve pipe closing for PipeableOSProcess class>>command: and related methods to support use as stand alone command processor. An expression such as the following will now close all open handles when command processing is complete:
"(PipeableOSProcess command: '/bin/echo this is a test') output"
No more need for the closePipes thing then? Also, I see that there is apparently no AioPlugin support in Pharo 3.0. Or so say the tests of OSProcess. What is the state of affairs there? Phil
If you could update the configuration to pick this up, that would be great. I think it will be helpful for people who want to easily execute commands directly from the image.
I think the two sub-packages that you would update are CommandShell-Base-dtl.38 and CommandShell-Piping-dtl.16
Thanks, Dave
Hi Dave,
thanks to you. I updated OSProcess to 4.5.11 and CommandShell to 4.6.8; are those the latest? I did it last Sunday.
Thierry
Le 09/10/2014 22:42, David T. Lewis a écrit :
Thierry,
Thanks for doing those configuration updates, I hit "send" before I saw your reply.
Dave
Hi Noury,
no, OSProcess on Squeaksource is not dead and is integrating all the changes needed for all the platforms it is running on.
And as you can see, I very recently updated the configuration to make sure it was pointing to the very latest version.
Regards,
Thierry
Le 09/10/2014 22:30, Noury Bouraqadi a écrit :
Hi,
Just tried to install the stable version of OSProcess using the configuration browser on a 3.0. I noticed it is still on http://www.squeaksource.com/OSProcess. Does it mean it is dead? if yes, what is the alternative?
Thanx Noury
On Fri, Oct 10, 2014 at 08:00:29AM +0200, phil@highoctane.be wrote:
Le 9 oct. 2014 23:15, "David T. Lewis" <lewis@mail.msen.com> a ??crit :
Darn, I think we must have both done our updates on the same day. The last update I did was this (time stamp is GMT -4 hours) :
CommandShell-dtl.76 Dave Lewis, 5 October 2014 5:29:32 pm CommandShell 4.6.9
Improve pipe closing for PipeableOSProcess class>>command: and related methods to support use as stand alone command processor. An expression such as the following will now close all open handles when command processing is complete:
"(PipeableOSProcess command: '/bin/echo this is a test') output"
No more need for the closePipes thing then?
Right. But please do test it in your applications to be sure, I really only did simple testing and I am sure there may still chances for problems in this area.
Also, I see that there is apparently no AioPlugin support in Pharo 3.0. Or so say the tests of OSProcess.
What is the state of affairs there?
Ask someone to include AioPlugin in the VM builds. Dave
2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis@mail.msen.com>:
Right. But please do test it in your applications to be sure, I really only did simple testing and I am sure there may still chances for problems in this area.
Hi Dave, Would it has a chance of slowing down things a lot? There is apparently something going very very slow compared to OSProcess 4.5.11 when used from GitFileTree. So slow that I killed the image building script before it was over. Reverting GitFileTree to 4.5.11 solved it. The absence of the AioPlugin warning may also be problematic, since it appears on stdout or stderr when Pharo is used on the command line. Thierry
Also, I see that there is apparently no AioPlugin support in Pharo 3.0.
Or
so say the tests of OSProcess.
What is the state of affairs there?
Ask someone to include AioPlugin in the VM builds.
Dave
Yes, the AioPlugin warning is annoying. The lack of it also, for a number of use cases I am currently on. Phil On Fri, Oct 10, 2014 at 5:04 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis@mail.msen.com>:
Right. But please do test it in your applications to be sure, I really only did simple testing and I am sure there may still chances for problems in this area.
Hi Dave,
Would it has a chance of slowing down things a lot?
There is apparently something going very very slow compared to OSProcess 4.5.11 when used from GitFileTree. So slow that I killed the image building script before it was over. Reverting GitFileTree to 4.5.11 solved it.
The absence of the AioPlugin warning may also be problematic, since it appears on stdout or stderr when Pharo is used on the command line.
Thierry
Also, I see that there is apparently no AioPlugin support in Pharo 3.0.
Or
so say the tests of OSProcess.
What is the state of affairs there?
Ask someone to include AioPlugin in the VM builds.
Dave
2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis@mail.msen.com>:
Right. But please do test it in your applications to be sure, I really only did simple testing and I am sure there may still chances for problems in this area.
Hi Dave,
Would it has a chance of slowing down things a lot?
There is apparently something going very very slow compared to OSProcess 4.5.11 when used from GitFileTree. So slow that I killed the image building script before it was over. Reverting GitFileTree to 4.5.11 solved it.
I don't this so, but I am not certain. The update for PipeableOSProcess affects only the methods in PipeableOSProcess class>>command: and closely related methods. If GitFileTree is using that idiom, then it is certainly possible that I have introduced a bug that does not show up in my unit tests.
The absence of the AioPlugin warning may also be problematic, since it appears on stdout or stderr when Pharo is used on the command line.
Yes I should get rid that annoyance. Thanks, Dave
Thierry
Also, I see that there is apparently no AioPlugin support in Pharo
3.0. Or
so say the tests of OSProcess.
What is the state of affairs there?
Ask someone to include AioPlugin in the VM builds.
Dave
Le 10/10/2014 17:52, David T. Lewis a écrit :
2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis@mail.msen.com>:
Right. But please do test it in your applications to be sure, I really only did simple testing and I am sure there may still chances for problems in this area.
Hi Dave,
Would it has a chance of slowing down things a lot?
There is apparently something going very very slow compared to OSProcess 4.5.11 when used from GitFileTree. So slow that I killed the image building script before it was over. Reverting GitFileTree to 4.5.11 solved it.
I don't this so, but I am not certain. The update for PipeableOSProcess affects only the methods in PipeableOSProcess class>>command: and closely related methods. If GitFileTree is using that idiom, then it is certainly possible that I have introduced a bug that does not show up in my unit tests.
Typical code in GitFileTree is this: [ c := PipeableOSProcess command: ''. output := c output. ... ] ensure: [c closePipes] Maybe it's triggering something. Thierry
Le 10/10/2014 17:52, David T. Lewis a écrit :
2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis@mail.msen.com>:
Right. But please do test it in your applications to be sure, I really only did simple testing and I am sure there may still chances for problems in this area.
Hi Dave,
Would it has a chance of slowing down things a lot?
There is apparently something going very very slow compared to OSProcess 4.5.11 when used from GitFileTree. So slow that I killed the image building script before it was over. Reverting GitFileTree to 4.5.11 solved it.
I don't this so, but I am not certain. The update for PipeableOSProcess affects only the methods in PipeableOSProcess class>>command: and closely related methods. If GitFileTree is using that idiom, then it is certainly possible that I have introduced a bug that does not show up in my unit tests.
Typical code in GitFileTree is this:
[ c := PipeableOSProcess command: ''. output := c output. ... ] ensure: [c closePipes]
Maybe it's triggering something.
Thierry
Hmmm... I wonder if the #closePipes is causing a problem now. I don't know if I ever tested to see if sending closePipes works after the pipes are already closed, and my recent change closes the pipes after #output is evaluated. I'll check it when I get home. Thanks, Dave
On Fri, Oct 10, 2014 at 01:32:27PM -0400, David T. Lewis wrote:
Le 10/10/2014 17:52, David T. Lewis a ?crit :
2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis@mail.msen.com>:
Right. But please do test it in your applications to be sure, I really only did simple testing and I am sure there may still chances for problems in this area.
Hi Dave,
Would it has a chance of slowing down things a lot?
There is apparently something going very very slow compared to OSProcess 4.5.11 when used from GitFileTree. So slow that I killed the image building script before it was over. Reverting GitFileTree to 4.5.11 solved it.
I don't this so, but I am not certain. The update for PipeableOSProcess affects only the methods in PipeableOSProcess class>>command: and closely related methods. If GitFileTree is using that idiom, then it is certainly possible that I have introduced a bug that does not show up in my unit tests.
Typical code in GitFileTree is this:
[ c := PipeableOSProcess command: ''. output := c output. ... ] ensure: [c closePipes]
Maybe it's triggering something.
Thierry
Hmmm... I wonder if the #closePipes is causing a problem now. I don't know if I ever tested to see if sending closePipes works after the pipes are already closed, and my recent change closes the pipes after #output is evaluated. I'll check it when I get home.
I tried this in both Squeak trunk and Pharo 3.0: (1 to: 100) collect: [:e | | c output | [c := PipeableOSProcess command: 'ls -lt'. output := c output. ] ensure: [c closePipes]. output ]. I get the expected results, and no open file handles left over. The #closePipes is no longer needed, so this can now be simplified as follows, which also leaves no open file handles: (1 to: 100) collect: [:e | (PipeableOSProcess command: 'ls -lt') output]. I am not sure what the issue is when used with GitFileTree, but it does not look like the change to PipeableOSProcess class>> command: is directly involved. But ... I'm probably missing something. If you are fairly sure the that problem is related to the the PipeableOSProcess change, then the only other thing I can think of right now is that there may be some other places in GitFileTree where PipeableOSProcess is being used in a different way, and maybe I caused a problem there due the the change in the #command: methods. But this a a complete guess, I really do not know. Dave
Hi Dave, took me a while to do some testing. It seems there is an issue, but I couldn't find out where. First, the data: Loading a package from a local gitfiletree repository (get from the command a zipped git archive containing the package) : 4.5.11, 4.6.8: 2132 msec. 4.5.12, 4.6.9: 50847 msec. I tried to rewrite the main command, remove the closePipes, etc... No change in the runtime, so your right. Profiling doesn't help much: execution time is mostly idle time (but with a significant increase on PipeableOSProcess commands: goes from invisible to 2700 ms. A user break in the middle shows it delay waiting on output of the external process). Only hint I could see is that it seems to be linked with the size of the output of the command. Thierry Le 11/10/2014 15:34, David T. Lewis a écrit :
On Fri, Oct 10, 2014 at 01:32:27PM -0400, David T. Lewis wrote:
Le 10/10/2014 17:52, David T. Lewis a ?crit :
2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis@mail.msen.com>:
Right. But please do test it in your applications to be sure, I really only did simple testing and I am sure there may still chances for problems in this area.
Hi Dave,
Would it has a chance of slowing down things a lot?
There is apparently something going very very slow compared to OSProcess 4.5.11 when used from GitFileTree. So slow that I killed the image building script before it was over. Reverting GitFileTree to 4.5.11 solved it.
I don't this so, but I am not certain. The update for PipeableOSProcess affects only the methods in PipeableOSProcess class>>command: and closely related methods. If GitFileTree is using that idiom, then it is certainly possible that I have introduced a bug that does not show up in my unit tests.
Typical code in GitFileTree is this:
[ c := PipeableOSProcess command: ''. output := c output. ... ] ensure: [c closePipes]
Maybe it's triggering something.
Thierry
Hmmm... I wonder if the #closePipes is causing a problem now. I don't know if I ever tested to see if sending closePipes works after the pipes are already closed, and my recent change closes the pipes after #output is evaluated. I'll check it when I get home.
I tried this in both Squeak trunk and Pharo 3.0:
(1 to: 100) collect: [:e | | c output | [c := PipeableOSProcess command: 'ls -lt'. output := c output. ] ensure: [c closePipes]. output ].
I get the expected results, and no open file handles left over.
The #closePipes is no longer needed, so this can now be simplified as follows, which also leaves no open file handles:
(1 to: 100) collect: [:e | (PipeableOSProcess command: 'ls -lt') output].
I am not sure what the issue is when used with GitFileTree, but it does not look like the change to PipeableOSProcess class>> command: is directly involved. But ... I'm probably missing something.
If you are fairly sure the that problem is related to the the PipeableOSProcess change, then the only other thing I can think of right now is that there may be some other places in GitFileTree where PipeableOSProcess is being used in a different way, and maybe I caused a problem there due the the change in the #command: methods. But this a a complete guess, I really do not know.
Dave
On Tue, Oct 14, 2014 at 07:19:10AM +0200, Thierry Goubier wrote:
Hi Dave,
took me a while to do some testing. It seems there is an issue, but I couldn't find out where. First, the data:
Loading a package from a local gitfiletree repository (get from the command a zipped git archive containing the package) :
4.5.11, 4.6.8: 2132 msec. 4.5.12, 4.6.9: 50847 msec.
I tried to rewrite the main command, remove the closePipes, etc... No change in the runtime, so your right.
Profiling doesn't help much: execution time is mostly idle time (but with a significant increase on PipeableOSProcess commands: goes from invisible to 2700 ms. A user break in the middle shows it delay waiting on output of the external process).
Only hint I could see is that it seems to be linked with the size of the output of the command.
Thierry, Aha! I am quite sure that you have located the problem. There must be something preventing the OS process from running to completion with a larger amount of output data. It definitely sounds like a bug in my latest update to Pipeable OSProcess. Thank you very much for finding this. I will get it fixed as quickly as I can. Dave
Le 11/10/2014 15:34, David T. Lewis a ?crit :
On Fri, Oct 10, 2014 at 01:32:27PM -0400, David T. Lewis wrote:
Le 10/10/2014 17:52, David T. Lewis a ?crit :
2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis@mail.msen.com>:
Right. But please do test it in your applications to be sure, I really only did simple testing and I am sure there may still chances for problems in this area.
Hi Dave,
Would it has a chance of slowing down things a lot?
There is apparently something going very very slow compared to OSProcess 4.5.11 when used from GitFileTree. So slow that I killed the image building script before it was over. Reverting GitFileTree to 4.5.11 solved it.
I don't this so, but I am not certain. The update for PipeableOSProcess affects only the methods in PipeableOSProcess class>>command: and closely related methods. If GitFileTree is using that idiom, then it is certainly possible that I have introduced a bug that does not show up in my unit tests.
Typical code in GitFileTree is this:
[ c := PipeableOSProcess command: ''. output := c output. ... ] ensure: [c closePipes]
Maybe it's triggering something.
Thierry
Hmmm... I wonder if the #closePipes is causing a problem now. I don't know if I ever tested to see if sending closePipes works after the pipes are already closed, and my recent change closes the pipes after #output is evaluated. I'll check it when I get home.
I tried this in both Squeak trunk and Pharo 3.0:
(1 to: 100) collect: [:e | | c output | [c := PipeableOSProcess command: 'ls -lt'. output := c output. ] ensure: [c closePipes]. output ].
I get the expected results, and no open file handles left over.
The #closePipes is no longer needed, so this can now be simplified as follows, which also leaves no open file handles:
(1 to: 100) collect: [:e | (PipeableOSProcess command: 'ls -lt') output].
I am not sure what the issue is when used with GitFileTree, but it does not look like the change to PipeableOSProcess class>> command: is directly involved. But ... I'm probably missing something.
If you are fairly sure the that problem is related to the the PipeableOSProcess change, then the only other thing I can think of right now is that there may be some other places in GitFileTree where PipeableOSProcess is being used in a different way, and maybe I caused a problem there due the the change in the #command: methods. But this a a complete guess, I really do not know.
Dave
Le 14/10/2014 14:15, David T. Lewis a écrit :
On Tue, Oct 14, 2014 at 07:19:10AM +0200, Thierry Goubier wrote:
Hi Dave,
took me a while to do some testing. It seems there is an issue, but I couldn't find out where. First, the data:
Loading a package from a local gitfiletree repository (get from the command a zipped git archive containing the package) :
4.5.11, 4.6.8: 2132 msec. 4.5.12, 4.6.9: 50847 msec.
I tried to rewrite the main command, remove the closePipes, etc... No change in the runtime, so your right.
Profiling doesn't help much: execution time is mostly idle time (but with a significant increase on PipeableOSProcess commands: goes from invisible to 2700 ms. A user break in the middle shows it delay waiting on output of the external process).
Only hint I could see is that it seems to be linked with the size of the output of the command.
Thierry,
Aha! I am quite sure that you have located the problem. There must be something preventing the OS process from running to completion with a larger amount of output data. It definitely sounds like a bug in my latest update to Pipeable OSProcess.
The strange thing is that it runs to completion (i.e. I got no errors; if any data was missing or corrupted on output, my load would fail); but a lot slower than it should be.
Thank you very much for finding this. I will get it fixed as quickly as I can.
Thanks. I'm unable to help you much, I'm afraid :( Thierry
On Tue, Oct 14, 2014 at 09:35:44PM +0200, Thierry Goubier wrote:
Le 14/10/2014 14:15, David T. Lewis a ?crit :
On Tue, Oct 14, 2014 at 07:19:10AM +0200, Thierry Goubier wrote:
Hi Dave,
took me a while to do some testing. It seems there is an issue, but I couldn't find out where. First, the data:
Loading a package from a local gitfiletree repository (get from the command a zipped git archive containing the package) :
4.5.11, 4.6.8: 2132 msec. 4.5.12, 4.6.9: 50847 msec.
I tried to rewrite the main command, remove the closePipes, etc... No change in the runtime, so your right.
Profiling doesn't help much: execution time is mostly idle time (but with a significant increase on PipeableOSProcess commands: goes from invisible to 2700 ms. A user break in the middle shows it delay waiting on output of the external process).
Only hint I could see is that it seems to be linked with the size of the output of the command.
Thierry,
Aha! I am quite sure that you have located the problem. There must be something preventing the OS process from running to completion with a larger amount of output data. It definitely sounds like a bug in my latest update to Pipeable OSProcess.
The strange thing is that it runs to completion (i.e. I got no errors; if any data was missing or corrupted on output, my load would fail); but a lot slower than it should be.
Thank you very much for finding this. I will get it fixed as quickly as I can.
Thanks. I'm unable to help you much, I'm afraid :(
Thierry, I do not yet have a solution to this, but I have been able to confirm that the performance difference that you see is primarily associated with the AioPlugin not being present in your VM. When I changed PipeableOSProcess to handle pipe handle closing properly, I used a buffered output stream that is driven by aio events. When data is available to be read from the external OS process, an aio notification pulls the available data into the buffered stream, and when no more data is available, the pipe (file) handles are closed. If the plugin is not present in the VM, I provided a polling mechanism to read data from the external OS process. Apparently this is very inefficient, and I am sure it could be greatly improved. That is the cause of the extremely slow performance that you are seeing. So in summary: The enhancement to PipeableOSProcess relies on an aio event driven reader, and if the AIO plugin is missing, the fallback code relies on polling, and is horribly inefficient. More to follow, and thank you again for identifying the problem. If you can convice your VM vendor to include AioPlugin in your VM, that would be helpful also ;-) Dave
Le 16/10/2014 01:30, David T. Lewis a écrit :
So in summary: The enhancement to PipeableOSProcess relies on an aio event driven reader, and if the AIO plugin is missing, the fallback code relies on polling, and is horribly inefficient.
More to follow, and thank you again for identifying the problem.
Thanks!
If you can convice your VM vendor to include AioPlugin in your VM, that would be helpful also ;-)
Well, now that 4.5.12/4.6.9 is the official OSProcess stable, people are starting to notice that the AioPlugin may be usefull :P Thierry
Le 16 oct. 2014 23:04, "Thierry Goubier" <thierry.goubier@gmail.com> a écrit :
Le 16/10/2014 01:30, David T. Lewis a écrit :
So in summary: The enhancement to PipeableOSProcess relies on an aio event driven reader, and if the AIO plugin is missing, the fallback code relies on polling, and is horribly inefficient.
More to follow, and thank you again for identifying the problem.
Thanks!
If you can convice your VM vendor to include AioPlugin in your VM, that would be helpful also ;-)
Well, now that 4.5.12/4.6.9 is the official OSProcess stable, people are
starting to notice that the AioPlugin may be usefull :P For example, CommandShell! I'll have a shot on building a vm with that plugin. Phil
Thierry
Ok, I'll update the configurations. Thanks, Thierry 2014-10-09 23:15 GMT+02:00 David T. Lewis <lewis@mail.msen.com>:
Darn, I think we must have both done our updates on the same day. The last update I did was this (time stamp is GMT -4 hours) :
CommandShell-dtl.76 Dave Lewis, 5 October 2014 5:29:32 pm CommandShell 4.6.9
Improve pipe closing for PipeableOSProcess class>>command: and related methods to support use as stand alone command processor. An expression such as the following will now close all open handles when command processing is complete:
"(PipeableOSProcess command: '/bin/echo this is a test') output"
If you could update the configuration to pick this up, that would be great. I think it will be helpful for people who want to easily execute commands directly from the image.
I think the two sub-packages that you would update are CommandShell-Base-dtl.38 and CommandShell-Piping-dtl.16
Thanks, Dave
Hi Dave,
thanks to you. I updated OSProcess to 4.5.11 and CommandShell to 4.6.8; are those the latest? I did it last Sunday.
Thierry
Le 09/10/2014 22:42, David T. Lewis a écrit :
Thierry,
Thanks for doing those configuration updates, I hit "send" before I saw your reply.
Dave
Hi Noury,
no, OSProcess on Squeaksource is not dead and is integrating all the changes needed for all the platforms it is running on.
And as you can see, I very recently updated the configuration to make sure it was pointing to the very latest version.
Regards,
Thierry
Le 09/10/2014 22:30, Noury Bouraqadi a écrit :
Hi,
Just tried to install the stable version of OSProcess using the configuration browser on a 3.0. I noticed it is still on http://www.squeaksource.com/OSProcess. Does it mean it is dead? if yes, what is the alternative?
Thanx Noury
Hi,
Just tried to install the stable version of OSProcess using the configuration browser on a 3.0. I noticed it is still on http://www.squeaksource.com/OSProcess. Does it mean it is dead? if yes, what is the alternative?
Hi Noury, OSProcess is alive and well. Let me know if you have any problems with it. The Metacello configurations might be due for an update for Pharo, as there is at least one recent update that would be of interest to users of PipeableOSProcess (in www.squeaksource.com/CommandShell). Dave
participants (4)
-
David T. Lewis -
Noury Bouraqadi -
phil＠highoctane.be -
Thierry Goubier