I am developing a simple "CommandLineProcessor" facade for easily
transferring command-line arguments simply as block-arguments, so you can write smalltalk scripts in vi: CommandLineProcessor do: [ : arg1 : arg2 : arg3 | "args come in as Strings" ... ] and also for directing Notifications and Warnings messages to stdOut, and Errors to stdErr. It relies on OSProcess to write to stdOut and stdErr for this. However, ever since switching to Cog, writing to these streams does not seem to redirect out to Linux.. I don't know whether writing to these streams makes me Linux-dependent, but it really is nice to be able to write Linux scripts that employ Squeak in the back-end, but operate normally like other shell programs in the terminal window and with redirecting output, etc. - Chris |
Hi Chris,
I have code for this, but right now I need to crack some crabs, so I don't have time to verify this code in 4.1 :) Use at your own risk ;) The most important thing is the StandardFileStream>>stdioHandles primitive for accessing the streams. N.B. some work needs to be done on the win32 FilePlugin support code before this will work on Windows. On Sun, Sep 26, 2010 at 2:46 PM, Chris Muller <[hidden email]> wrote: I am developing a simple "CommandLineProcessor" facade for easily stdio.st (10K) Download Attachment |
On Sun, 26 Sep 2010, Eliot Miranda wrote:
> Hi Chris, > > I have code for this, but right now I need to crack some crabs, so I > don't have time to verify this code in 4.1 :) Use at your own risk ;) The > most important thing is the StandardFileStream>>stdioHandles primitive for > accessing the streams. N.B. some work needs to be done on the win32 > FilePlugin support code before this will work on Windows. All three streams seem to be working on Windows Vista with the latest CogVM. This seems to be a really cool feature, though I think CrLfFileStream should be deprecated, so MultiByteFileStream support would be better IMO. Levente > > > On Sun, Sep 26, 2010 at 2:46 PM, Chris Muller <[hidden email]> wrote: > >> I am developing a simple "CommandLineProcessor" facade for easily >> transferring command-line arguments simply as block-arguments, so you >> can write smalltalk scripts in vi: >> >> CommandLineProcessor do: [ : arg1 : arg2 : arg3 | "args come in as >> Strings" ... ] >> >> and also for directing Notifications and Warnings messages to stdOut, >> and Errors to stdErr. It relies on OSProcess to write to stdOut and >> stdErr for this. However, ever since switching to Cog, writing to >> these streams does not seem to redirect out to Linux.. >> >> I don't know whether writing to these streams makes me >> Linux-dependent, but it really is nice to be able to write Linux >> scripts that employ Squeak in the back-end, but operate normally like >> other shell programs in the terminal window and with redirecting >> output, etc. >> >> - Chris >> >> > |
Hi Levente,
On Sun, Sep 26, 2010 at 7:13 PM, Levente Uzonyi <[hidden email]> wrote:
The streams work if directed to files. But they will /not/ work if directed to input or output in a console window. I should have been clearer, sorry. The work needed is in platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c where if input and/or output is the console we need to use ReadConsole & WriteConsole in place of ReadFile & WriteFile.
cheers Eliot
|
In reply to this post by Levente Uzonyi-2
On Sun, Sep 26, 2010 at 7:13 PM, Levente Uzonyi <[hidden email]> wrote:
Forgive me. I was unaware of the subtleties when I wrote the code. The important thing is the remembering of the three streams so that multiple clients that e.g. write to stdout will end up writing to a singe stdout stream, not multiple independent streams on stdout. Feel free to fix my stream usage.
cheers Eliot
|
On 27.09.2010, at 07:20, Eliot Miranda wrote:
Since this comes up at least once every year it would really be awesome to finally get proper stdio support :) OSProcess is a fine choice for many situations, but not all. Getting this in the regular VM + image will be very helpful. - Bert - |
+1, yes _very_ helpful
Is it a lot of work to do so? --Hannes On 9/27/10, Bert Freudenberg <[hidden email]> wrote: > > On 27.09.2010, at 07:20, Eliot Miranda wrote: > >> >> >> On Sun, Sep 26, 2010 at 7:13 PM, Levente Uzonyi <[hidden email]> wrote: >> On Sun, 26 Sep 2010, Eliot Miranda wrote: >> >> Hi Chris, >> >> I have code for this, but right now I need to crack some crabs, so I >> don't have time to verify this code in 4.1 :) Use at your own risk ;) >> The >> most important thing is the StandardFileStream>>stdioHandles primitive for >> accessing the streams. N.B. some work needs to be done on the win32 >> FilePlugin support code before this will work on Windows. >> >> All three streams seem to be working on Windows Vista with the latest >> CogVM. >> This seems to be a really cool feature, though I think CrLfFileStream >> should be deprecated, so MultiByteFileStream support would be better IMO. >> >> Forgive me. I was unaware of the subtleties when I wrote the code. The >> important thing is the remembering of the three streams so that multiple >> clients that e.g. write to stdout will end up writing to a singe stdout >> stream, not multiple independent streams on stdout. Feel free to fix my >> stream usage. >> >> cheers >> Eliot > > Since this comes up at least once every year it would really be awesome to > finally get proper stdio support :) > > OSProcess is a fine choice for many situations, but not all. Getting this in > the regular VM + image will be very helpful. > > - Bert - > > > |
On 27.09.2010, at 12:23, Hannes Hirzel wrote:
> +1, yes _very_ helpful > > Is it a lot of work to do so? > > --Hannes Not really, but still some. More importantly, it requires coordinating all the platforms. The new primitive(s) must be added to VMMaker, which calls into the platform support code, which must be written (or at the very least be stubbed out) for each platform. This work typically falls to the few VM platform maintainers. We do not have a good process to share that burden. Contributors have to send patches to the vm-dev list. But since no one is expert in all platforms, patches typically are supplied for one platform only. It is expected of the platform maintainers to implement the equivalent on their platform. This means significant work for them, so it might not happen soon or at all. If patches were provided for all platforms and simply needed to be applied, the work would be much easier on the maintainers. However, we lack collaboration infrastructure to work on these patches. - Bert - > > On 9/27/10, Bert Freudenberg <[hidden email]> wrote: >> >> On 27.09.2010, at 07:20, Eliot Miranda wrote: >> >>> >>> >>> On Sun, Sep 26, 2010 at 7:13 PM, Levente Uzonyi <[hidden email]> wrote: >>> On Sun, 26 Sep 2010, Eliot Miranda wrote: >>> >>> Hi Chris, >>> >>> I have code for this, but right now I need to crack some crabs, so I >>> don't have time to verify this code in 4.1 :) Use at your own risk ;) >>> The >>> most important thing is the StandardFileStream>>stdioHandles primitive for >>> accessing the streams. N.B. some work needs to be done on the win32 >>> FilePlugin support code before this will work on Windows. >>> >>> All three streams seem to be working on Windows Vista with the latest >>> CogVM. >>> This seems to be a really cool feature, though I think CrLfFileStream >>> should be deprecated, so MultiByteFileStream support would be better IMO. >>> >>> Forgive me. I was unaware of the subtleties when I wrote the code. The >>> important thing is the remembering of the three streams so that multiple >>> clients that e.g. write to stdout will end up writing to a singe stdout >>> stream, not multiple independent streams on stdout. Feel free to fix my >>> stream usage. >>> >>> cheers >>> Eliot >> >> Since this comes up at least once every year it would really be awesome to >> finally get proper stdio support :) >> >> OSProcess is a fine choice for many situations, but not all. Getting this in >> the regular VM + image will be very helpful. >> >> - Bert - >> >> >> > |
In reply to this post by Eliot Miranda-2
On Sun, Sep 26, 2010 at 10:18 PM, Eliot Miranda <[hidden email]> wrote: Hi Levente, Hmmm. Turns out I was confused about this. One doesn't need ReadConsole & WriteConsole; ReadFile & WriteFile should do just fine. But the Cog code doesnt work in either an MS-DOS console window or a cygwin console window. If anyone's familiar with this area of Windows please feel free to take a look...
TIA Eliot
|
On 27 September 2010 21:09, Eliot Miranda <[hidden email]> wrote:
> > > On Sun, Sep 26, 2010 at 10:18 PM, Eliot Miranda <[hidden email]> > wrote: >> >> Hi Levente, >> >> On Sun, Sep 26, 2010 at 7:13 PM, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Sun, 26 Sep 2010, Eliot Miranda wrote: >>> >>>> Hi Chris, >>>> >>>> I have code for this, but right now I need to crack some crabs, so I >>>> don't have time to verify this code in 4.1 :) Use at your own risk ;) >>>> The >>>> most important thing is the StandardFileStream>>stdioHandles primitive >>>> for >>>> accessing the streams. N.B. some work needs to be done on the win32 >>>> FilePlugin support code before this will work on Windows. >>> >>> All three streams seem to be working on Windows Vista with the latest >>> CogVM. >>> This seems to be a really cool feature, though I think CrLfFileStream >>> should be deprecated, so MultiByteFileStream support would be better IMO. >> >> The streams work if directed to files. But they will /not/ work if >> directed to input or output in a console window. I should have been >> clearer, sorry. The work needed is in >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c where if input and/or >> output is the console we need to use ReadConsole & WriteConsole in place of >> ReadFile & WriteFile. > > Hmmm. Turns out I was confused about this. One doesn't need ReadConsole & > WriteConsole; ReadFile & WriteFile should do just fine. But the Cog code > doesnt work in either an MS-DOS console window or a cygwin console window. > If anyone's familiar with this area of Windows please feel free to take a > look... In Hydra, i simply changed main entry point from winMain() to main(), and then i were able to print to console using printf() etc. The side effect of it, that when you run VM from explorer, it opens a console window, so you end up with two windows - console and graphic. and obvious, when you running it from command-line its using a console from which you run it. I din't explored the way , how to make it to not open console but still have stdin/stdout working. > TIA > Eliot >> >> cheers >> Eliot >>> >>> >>> Levente >>> >>>> >>>> >>>> On Sun, Sep 26, 2010 at 2:46 PM, Chris Muller <[hidden email]> >>>> wrote: >>>> >>>>> I am developing a simple "CommandLineProcessor" facade for easily >>>>> transferring command-line arguments simply as block-arguments, so you >>>>> can write smalltalk scripts in vi: >>>>> >>>>> CommandLineProcessor do: [ : arg1 : arg2 : arg3 | "args come in as >>>>> Strings" ... ] >>>>> >>>>> and also for directing Notifications and Warnings messages to stdOut, >>>>> and Errors to stdErr. It relies on OSProcess to write to stdOut and >>>>> stdErr for this. However, ever since switching to Cog, writing to >>>>> these streams does not seem to redirect out to Linux.. >>>>> >>>>> I don't know whether writing to these streams makes me >>>>> Linux-dependent, but it really is nice to be able to write Linux >>>>> scripts that employ Squeak in the back-end, but operate normally like >>>>> other shell programs in the terminal window and with redirecting >>>>> output, etc. >>>>> >>>>> - Chris >>>>> >>>>> >>>> >>> >> > > > > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Bert Freudenberg
On 9/27/10, Bert Freudenberg <[hidden email]> wrote:
> On 27.09.2010, at 12:23, Hannes Hirzel wrote: > >> +1, yes _very_ helpful >> >> Is it a lot of work to do so? >> >> --Hannes > > Not really, but still some. More importantly, it requires coordinating all > the platforms. > > The new primitive(s) must be added to VMMaker, which calls into the platform > support code, which must be written (or at the very least be stubbed out) > for each platform. > > This work typically falls to the few VM platform maintainers. We do not have > a good process to share that burden. > > Contributors have to send patches to the vm-dev list. But since no one is > expert in all platforms, patches typically are supplied for one platform > only. It is expected of the platform maintainers to implement the equivalent > on their platform. This means significant work for them, so it might not > happen soon or at all. > > If patches were provided for all platforms and simply needed to be applied, > the work would be much easier on the maintainers. However, we lack > collaboration infrastructure to work on these patches. > > - Bert - > As Cog is still in test and evaluation phase and not yet widespread I think it is an opportunity to add this basic feature people expect. I agree with your analysis. We need collaboration infrastructure for future changes like this. But for the change at hand I hope that it is still possible to do it on a as-we-go-along basis ..... --Hannes |
In reply to this post by Eliot Miranda-2
Thanks for the code Eliot. Can you give me a hint about proper usage.
In the current trunk I tried CrLfFileStream newForStdio but I was not able to nextPutAll: a String onto that (rwmode was not set). I also found StandardFileStream class>>#standardIOStreamNamed:forWrite: but it has undeclared variable, "stdioFiles". Is that supposed to be a class-inst var defined at the StandardFileStream level? Senders did not help me understand what arguments I should pass... Sorry for my confusion.. - Chris On Mon, Sep 27, 2010 at 1:09 PM, Eliot Miranda <[hidden email]> wrote: > > > On Sun, Sep 26, 2010 at 10:18 PM, Eliot Miranda <[hidden email]> > wrote: >> >> Hi Levente, >> >> On Sun, Sep 26, 2010 at 7:13 PM, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Sun, 26 Sep 2010, Eliot Miranda wrote: >>> >>>> Hi Chris, >>>> >>>> I have code for this, but right now I need to crack some crabs, so I >>>> don't have time to verify this code in 4.1 :) Use at your own risk ;) >>>> The >>>> most important thing is the StandardFileStream>>stdioHandles primitive >>>> for >>>> accessing the streams. N.B. some work needs to be done on the win32 >>>> FilePlugin support code before this will work on Windows. >>> >>> All three streams seem to be working on Windows Vista with the latest >>> CogVM. >>> This seems to be a really cool feature, though I think CrLfFileStream >>> should be deprecated, so MultiByteFileStream support would be better IMO. >> >> The streams work if directed to files. But they will /not/ work if >> directed to input or output in a console window. I should have been >> clearer, sorry. The work needed is in >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c where if input and/or >> output is the console we need to use ReadConsole & WriteConsole in place of >> ReadFile & WriteFile. > > Hmmm. Turns out I was confused about this. One doesn't need ReadConsole & > WriteConsole; ReadFile & WriteFile should do just fine. But the Cog code > doesnt work in either an MS-DOS console window or a cygwin console window. > If anyone's familiar with this area of Windows please feel free to take a > look... > TIA > Eliot >> >> cheers >> Eliot >>> >>> >>> Levente >>> >>>> >>>> >>>> On Sun, Sep 26, 2010 at 2:46 PM, Chris Muller <[hidden email]> >>>> wrote: >>>> >>>>> I am developing a simple "CommandLineProcessor" facade for easily >>>>> transferring command-line arguments simply as block-arguments, so you >>>>> can write smalltalk scripts in vi: >>>>> >>>>> CommandLineProcessor do: [ : arg1 : arg2 : arg3 | "args come in as >>>>> Strings" ... ] >>>>> >>>>> and also for directing Notifications and Warnings messages to stdOut, >>>>> and Errors to stdErr. It relies on OSProcess to write to stdOut and >>>>> stdErr for this. However, ever since switching to Cog, writing to >>>>> these streams does not seem to redirect out to Linux.. >>>>> >>>>> I don't know whether writing to these streams makes me >>>>> Linux-dependent, but it really is nice to be able to write Linux >>>>> scripts that employ Squeak in the back-end, but operate normally like >>>>> other shell programs in the terminal window and with redirecting >>>>> output, etc. >>>>> >>>>> - Chris >>>>> >>>>> >>>> >>> >> > > > > > |
On Sun, 3 Oct 2010, Chris Muller wrote:
> Thanks for the code Eliot. Can you give me a hint about proper usage. > In the current trunk I tried > > CrLfFileStream newForStdio > > but I was not able to nextPutAll: a String onto that (rwmode was not set). > > I also found StandardFileStream > class>>#standardIOStreamNamed:forWrite: but it has undeclared > variable, "stdioFiles". Is that supposed to be a class-inst var > defined at the StandardFileStream level? Senders did not help me > understand what arguments I should pass... this: CrLfFileStream stdout nextPutAll: 'Hello World!'. Levente > > Sorry for my confusion.. > > - Chris > > > On Mon, Sep 27, 2010 at 1:09 PM, Eliot Miranda <[hidden email]> wrote: >> >> >> On Sun, Sep 26, 2010 at 10:18 PM, Eliot Miranda <[hidden email]> >> wrote: >>> >>> Hi Levente, >>> >>> On Sun, Sep 26, 2010 at 7:13 PM, Levente Uzonyi <[hidden email]> wrote: >>>> >>>> On Sun, 26 Sep 2010, Eliot Miranda wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> I have code for this, but right now I need to crack some crabs, so I >>>>> don't have time to verify this code in 4.1 :) Use at your own risk ;) >>>>> The >>>>> most important thing is the StandardFileStream>>stdioHandles primitive >>>>> for >>>>> accessing the streams. N.B. some work needs to be done on the win32 >>>>> FilePlugin support code before this will work on Windows. >>>> >>>> All three streams seem to be working on Windows Vista with the latest >>>> CogVM. >>>> This seems to be a really cool feature, though I think CrLfFileStream >>>> should be deprecated, so MultiByteFileStream support would be better IMO. >>> >>> The streams work if directed to files. But they will /not/ work if >>> directed to input or output in a console window. I should have been >>> clearer, sorry. The work needed is in >>> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c where if input and/or >>> output is the console we need to use ReadConsole & WriteConsole in place of >>> ReadFile & WriteFile. >> >> Hmmm. Turns out I was confused about this. One doesn't need ReadConsole & >> WriteConsole; ReadFile & WriteFile should do just fine. But the Cog code >> doesnt work in either an MS-DOS console window or a cygwin console window. >> If anyone's familiar with this area of Windows please feel free to take a >> look... >> TIA >> Eliot >>> >>> cheers >>> Eliot >>>> >>>> >>>> Levente >>>> >>>>> >>>>> >>>>> On Sun, Sep 26, 2010 at 2:46 PM, Chris Muller <[hidden email]> >>>>> wrote: >>>>> >>>>>> I am developing a simple "CommandLineProcessor" facade for easily >>>>>> transferring command-line arguments simply as block-arguments, so you >>>>>> can write smalltalk scripts in vi: >>>>>> >>>>>> CommandLineProcessor do: [ : arg1 : arg2 : arg3 | "args come in as >>>>>> Strings" ... ] >>>>>> >>>>>> and also for directing Notifications and Warnings messages to stdOut, >>>>>> and Errors to stdErr. It relies on OSProcess to write to stdOut and >>>>>> stdErr for this. However, ever since switching to Cog, writing to >>>>>> these streams does not seem to redirect out to Linux.. >>>>>> >>>>>> I don't know whether writing to these streams makes me >>>>>> Linux-dependent, but it really is nice to be able to write Linux >>>>>> scripts that employ Squeak in the back-end, but operate normally like >>>>>> other shell programs in the terminal window and with redirecting >>>>>> output, etc. >>>>>> >>>>>> - Chris >>>>>> >>>>>> >>>>> >>>> >>> >> >> >> >> >> > > |
Hi Both,
2010/10/3 Levente Uzonyi <[hidden email]>
Levente, as usual, is exactly right. use e.g. StandardFileStream stdout.
That's right. This is missing: StandardFileStream class instanceVariableNames: 'stdioFiles'
best Eliot
|
Thank you both, it worked in my Linux test! And Levente tested it in
Windows. Does that mean only Mac needs tested and clean up the stream-usage to be able to include this into 4.2? Bert, I was not clear if that what you meant in your reference to work needed by platform maintainers..? On Mon, Oct 4, 2010 at 10:26 PM, Eliot Miranda <[hidden email]> wrote: > Hi Both, > > 2010/10/3 Levente Uzonyi <[hidden email]> >> >> On Sun, 3 Oct 2010, Chris Muller wrote: >> >>> Thanks for the code Eliot. Can you give me a hint about proper usage. >>> In the current trunk I tried >>> >>> CrLfFileStream newForStdio > > Levente, as usual, is exactly right. use e.g. StandardFileStream stdout. > >>> >>> but I was not able to nextPutAll: a String onto that (rwmode was not >>> set). >>> >>> I also found StandardFileStream >>> class>>#standardIOStreamNamed:forWrite: but it has undeclared >>> variable, "stdioFiles". Is that supposed to be a class-inst var >>> defined at the StandardFileStream level? Senders did not help me >>> understand what arguments I should pass... >> >> That class instance variable is missing, but the code still works. Try >> this: >> >> CrLfFileStream stdout nextPutAll: 'Hello World!'. > > That's right. This is missing: > StandardFileStream class > instanceVariableNames: 'stdioFiles' > best > Eliot >> >> Levente >> >>> >>> Sorry for my confusion.. >>> >>> - Chris >>> >>> >>> On Mon, Sep 27, 2010 at 1:09 PM, Eliot Miranda <[hidden email]> >>> wrote: >>>> >>>> >>>> On Sun, Sep 26, 2010 at 10:18 PM, Eliot Miranda >>>> <[hidden email]> >>>> wrote: >>>>> >>>>> Hi Levente, >>>>> >>>>> On Sun, Sep 26, 2010 at 7:13 PM, Levente Uzonyi <[hidden email]> wrote: >>>>>> >>>>>> On Sun, 26 Sep 2010, Eliot Miranda wrote: >>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> I have code for this, but right now I need to crack some crabs, so >>>>>>> I >>>>>>> don't have time to verify this code in 4.1 :) Use at your own risk >>>>>>> ;) >>>>>>> The >>>>>>> most important thing is the StandardFileStream>>stdioHandles >>>>>>> primitive >>>>>>> for >>>>>>> accessing the streams. N.B. some work needs to be done on the win32 >>>>>>> FilePlugin support code before this will work on Windows. >>>>>> >>>>>> All three streams seem to be working on Windows Vista with the latest >>>>>> CogVM. >>>>>> This seems to be a really cool feature, though I think CrLfFileStream >>>>>> should be deprecated, so MultiByteFileStream support would be better >>>>>> IMO. >>>>> >>>>> The streams work if directed to files. But they will /not/ work if >>>>> directed to input or output in a console window. I should have been >>>>> clearer, sorry. The work needed is in >>>>> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c where if input >>>>> and/or >>>>> output is the console we need to use ReadConsole & WriteConsole in >>>>> place of >>>>> ReadFile & WriteFile. >>>> >>>> Hmmm. Turns out I was confused about this. One doesn't need >>>> ReadConsole & >>>> WriteConsole; ReadFile & WriteFile should do just fine. But the Cog >>>> code >>>> doesnt work in either an MS-DOS console window or a cygwin console >>>> window. >>>> If anyone's familiar with this area of Windows please feel free to take >>>> a >>>> look... >>>> TIA >>>> Eliot >>>>> >>>>> cheers >>>>> Eliot >>>>>> >>>>>> >>>>>> Levente >>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Sep 26, 2010 at 2:46 PM, Chris Muller <[hidden email]> >>>>>>> wrote: >>>>>>> >>>>>>>> I am developing a simple "CommandLineProcessor" facade for easily >>>>>>>> transferring command-line arguments simply as block-arguments, so >>>>>>>> you >>>>>>>> can write smalltalk scripts in vi: >>>>>>>> >>>>>>>> CommandLineProcessor do: [ : arg1 : arg2 : arg3 | "args come in as >>>>>>>> Strings" ... ] >>>>>>>> >>>>>>>> and also for directing Notifications and Warnings messages to >>>>>>>> stdOut, >>>>>>>> and Errors to stdErr. It relies on OSProcess to write to stdOut and >>>>>>>> stdErr for this. However, ever since switching to Cog, writing to >>>>>>>> these streams does not seem to redirect out to Linux.. >>>>>>>> >>>>>>>> I don't know whether writing to these streams makes me >>>>>>>> Linux-dependent, but it really is nice to be able to write Linux >>>>>>>> scripts that employ Squeak in the back-end, but operate normally >>>>>>>> like >>>>>>>> other shell programs in the terminal window and with redirecting >>>>>>>> output, etc. >>>>>>>> >>>>>>>> - Chris >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> > > > > > |
On Tue, Oct 5, 2010 at 12:23 PM, Chris Muller <[hidden email]> wrote: Thank you both, it worked in my Linux test! And Levente tested it in I wrote it on Mac and use it regularly on Mac. It works on Mac. Mac == unix at this level. But the VM support needs to get merged into the trunk before we an add it to 4.2.
|
Free forum by Nabble | Edit this page |