Questions of understanding

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions of understanding

FDominicus
Dear Pharoisten,
I have a couple of questions about my understanding about Pharo, the VM
and COG.

the COG VM is the "normal virtual machine as I understand"
At least my Pharo give me:
'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.35]'

It is my understanding that the Cog sources do not contain the actual
SerialPlugin stuff from SergeStinckwicj-
At least I can not find anything like OpenPortByname or writeToNamed
port or the like.

So I fetched the Squeak sources and the Cog sources and indeed they are
different.
The Cog version defines:
#ifdef SQUEAK_BUILTIN_PLUGIN

void* SerialPlugin_exports[][3] = {
        {"SerialPlugin", "getModuleName", (void*)getModuleName},
        {"SerialPlugin", "initialiseModule", (void*)initialiseModule},
        {"SerialPlugin", "primitiveSerialPortClose", (void*)primitiveSerialPortClose},
        {"SerialPlugin", "primitiveSerialPortOpen", (void*)primitiveSerialPortOpen},
        {"SerialPlugin", "primitiveSerialPortRead", (void*)primitiveSerialPortRead},
        {"SerialPlugin", "primitiveSerialPortWrite", (void*)primitiveSerialPortWrite},
        {"SerialPlugin", "setInterpreter", (void*)setInterpreter},
        {"SerialPlugin", "shutdownModule", (void*)shutdownModule},
        {NULL, NULL, NULL}
};

#endif /* ifdef SQ_BUILTIN_PLUGIN */


Whereas the Squeal-vm version contains e.g:
#ifdef SQUEAK_BUILTIN_PLUGIN

void* SerialPlugin_exports[][3] = {
        {"SerialPlugin", "primitiveSerialPortWrite", (void*)primitiveSerialPortWrite},
        {"SerialPlugin", "primitiveSerialPortClose", (void*)primitiveSerialPortClose},
        {"SerialPlugin", "primitiveSerialPortOpenByName", (void*)primitiveSerialPortOpenByName},
        {"SerialPlugin", "primitiveSerialPortWriteByName", (void*)primitiveSerialPortWriteByName},
        {"SerialPlugin", "primitiveSerialPortReadByName", (void*)primitiveSerialPortReadByName},
        {"SerialPlugin", "shutdownModule", (void*)shutdownModule},
        {"SerialPlugin", "primitiveSerialPortOpen", (void*)primitiveSerialPortOpen},
        {"SerialPlugin", "initialiseModule", (void*)initialiseModule},
        {"SerialPlugin", "setInterpreter", (void*)setInterpreter},
        {"SerialPlugin", "getModuleName", (void*)getModuleName},
        {"SerialPlugin", "primitiveSerialPortCloseByName", (void*)primitiveSerialPortCloseByName},
        {"SerialPlugin", "primitiveSerialPortRead", (void*)primitiveSerialPortRead},
        {NULL, NULL, NULL}
};

#endif

So now it seems the Cog version is for building an internal plugin. (I
may be mistaken of course)

but the code for primitiveSerialPortOpen looks like this:
EXPORT(sqInt)
primitiveSerialPortOpen(void)
{
        sqInt baudRate;
        sqInt dataBits;
        sqInt inFlowControl;
        sqInt outFlowControl;
        sqInt parityType;
        sqInt portNum;
        sqInt stopBitsType;
        sqInt xOffChar;
        sqInt xOnChar;

        portNum = interpreterProxy->stackIntegerValue(8);
        baudRate = interpreterProxy->stackIntegerValue(7);
        stopBitsType = interpreterProxy->stackIntegerValue(6);
        parityType = interpreterProxy->stackIntegerValue(5);
        dataBits = interpreterProxy->stackIntegerValue(4);
        inFlowControl = interpreterProxy->stackIntegerValue(3);
        outFlowControl = interpreterProxy->stackIntegerValue(2);
        xOnChar = interpreterProxy->stackIntegerValue(1);
        xOffChar = interpreterProxy->stackIntegerValue(0);
        if (interpreterProxy->failed()) {


whereas the Squeak sources looks like this:

int serialPortOpen(int portNum, int dataRate, int stopBitsType, int parityType, int dataBits,
                   int inFlowCtrl, int outFlowCtrl, int xOnChar, int xOffChar)
{
  char serialPortName[PORT_NAME_SIZE];
  make_portname_from_portnum(serialPortName, portNum);
     
  return serialPortOpenByName(serialPortName, dataRate, stopBitsType, parityType, dataBits,
                              inFlowCtrl, outFlowCtrl, xOnChar, xOffChar);
}


So I assume one has to make the changes as in the cog examples to make
this plugin workable in Cog. Is that a correct impression.

Well then it comes to the questions of how to properly write a plugin
for the COG  vm. Are there any tutorials about it, or is the best I can
hope for the sources for Cog itself?

My understanding is that stackIntegerValue, picks out a parameter from
a Cogs primitive. Is that a correct impression?

It seems that at least the following things have to be exported from a
plugin:
getModuleName
setInterpreter
and maybe
initializeModule
shutdownModule

The latter are probably for cleaning up....

But maybe I'm on the complete wrong track. Because at the beginning I
can read:
/* Automatically generated by
        SmartSyntaxPluginCodeGenerator VMMaker-oscog.40 uuid: 637db40c-33c6-4263-816e-1b8cc19e3c99
   from
        SerialPlugin VMMaker-oscog.40 uuid: 637db40c-33c6-4263-816e-1b8cc19e3c99
 */

So is this code not written in C but maybe somewhere else?

As you can see I'm more than less clueless.

So what is the "supposed" way to migrat that kind of code?


Regards
Friedrich

--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Reply | Threaded
Open this post in threaded view
|

Re: Questions of understanding

FDominicus
Ok I spend my time today on building a new virtual machine. And my
assumptions in my last mail were  wrong. The code is not hand-written
but is generated. Now I  understand that. But now I see that while
building the virtual machine the stuff probabably is taken form the
PharoV10.sources file  from which it seems SerialPlugin.c is build.

Now in PharoV10.sources there is are not the patches to use ports by
Name as needed in Linux. So now my question is. After I've build a new
virtual machine how can I  modify one of the plugins to update  them.

So the sources file contains things like openPort but not
openPortByName. So what do I have to do to get into the patches such
that the new SerialPlugin.c can be generated?

Ah yes I used the pages at
http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-using-git-and-cmakevmmaker/

for learning that....

Regards
Friedrich

Reply | Threaded
Open this post in threaded view
|

Re: Questions of understanding

Marcus Denker-4
In reply to this post by FDominicus

On May 24, 2011, at 5:37 PM, Friedrich Dominicus wrote:

> Ok I spend my time today on building a new virtual machine. And my
> assumptions in my last mail were  wrong. The code is not hand-written
> but is generated. Now I  understand that. But now I see that while
> building the virtual machine the stuff probabably is taken form the
> PharoV10.sources file  from which it seems SerialPlugin.c is build.
>

PharoV10.sources should not contain any VM Related sources... the VMMaker package
has the source for the VM.

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


Reply | Threaded
Open this post in threaded view
|

Re: Questions of understanding

Mariano Martinez Peck
In reply to this post by FDominicus


On Tue, May 24, 2011 at 5:37 PM, Friedrich Dominicus <[hidden email]> wrote:
Ok I spend my time today on building a new virtual machine. And my
assumptions in my last mail were  wrong. The code is not hand-written
but is generated. Now I  understand that. But now I see that while
building the virtual machine the stuff probabably is taken form the
PharoV10.sources file  from which it seems SerialPlugin.c is build.


Sorry, I didn't read the email until now, the subject was not very good ;)
 
Now in PharoV10.sources there is are not the patches to use ports by
Name as needed in Linux. So now my question is. After I've build a new
virtual machine how can I  modify one of the plugins to update  them.


For the plugins, there are two parts: the VMMaker part (usually a plugin is a subclass of InterpreterPlugin) and the C part.
Some plugins are directly included in the VMMaker package/repostitory and some others are in different places (usually when they are not "core" plugins).

The VMMaker part of SerialPlugin, is in VMMaker package, so if you followed my instructions, when you downloaded VMMAker, you should have downloaded the class SerialPlugin which is in the 'VMMaker-Plugins' category.

Now, if you need to modify something to the "platform code", hand written C code, then such plugins can be found in Git or in the SVN.
In git, they are in https://gitorious.org/cogvm/

For your case it should be:

https://gitorious.org/cogvm/blessed/blobs/master/platforms/unix/plugins/SerialPlugin/sqUnixSerial.c

 
So the sources file contains things like openPort but not
openPortByName. So what do I have to do to get into the patches such
that the new SerialPlugin.c can be generated?

Ah yes I used the pages at
http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-using-git-and-cmakevmmaker/

for learning that....

Regards
Friedrich




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Questions of understanding

FDominicus
> https://gitorious.org/cogvm/blessed/blobs/master/platforms/unix/plugins/
> SerialPlugin/sqUnixSerial.c
>
>  
>
>     So the sources file contains things like openPort but not
>     openPortByName. So what do I have to do to get into the patches such
>     that the new SerialPlugin.c can be generated?
>
>     Ah yes I used the pages at
>     http://marianopeck.wordpress.com/2011/04/10/
>     building-the-vm-from-scratch-using-git-and-cmakevmmaker/
>
>
>
> now you can read: http://marianopeck.wordpress.com/2011/04/05/
> first-stop-vms-scm-and-related-stuff
>
> :)
>  
>
>     for learning that....
Thanks  I'll  have another  look.

Regards
Friedrich

Reply | Threaded
Open this post in threaded view
|

Re: Questions of understanding

FDominicus
In reply to this post by Mariano Martinez Peck
Mariano Martinez Peck <[hidden email]> writes:

> https://gitorious.org/cogvm/blessed/blobs/master/platforms/unix/plugins/
> SerialPlugin/sqUnixSerial.c
This code contains the old implementaton of the Serial Plugin not the
extensions of things like openPortByName. The Serail Plugin I'm talking
about has the following implementation on the Smalltalk Size



--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

SerialPort.st (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Questions of understanding

Mariano Martinez Peck
I have no idea. Maybe someone in the VM mailing list can help you.

Cheers

2011/5/25 Friedrich Dominicus <[hidden email]>
Mariano Martinez Peck <[hidden email]> writes:

> https://gitorious.org/cogvm/blessed/blobs/master/platforms/unix/plugins/
> SerialPlugin/sqUnixSerial.c
This code contains the old implementaton of the Serial Plugin not the
extensions of things like openPortByName. The Serail Plugin I'm talking
about has the following implementation on the Smalltalk Size



--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Questions of understanding

FDominicus
Mariano Martinez Peck <[hidden email]> writes:

> I have no idea. Maybe someone in the VM mailing list can help you.
>
Ok I  finally got the serialPort access under Cog VM and Linux
I concede it is currently a hackerish solution a combination out of
Squeak sources and Cog sources with a good mixture of Cog

So whomever may be "reponsible" can get in touch with me and I'll try to
work out a stable implementation on Linux.

But I think there are a few problems with Pharo 1.3 and Cog. AFAIKT one
needs AbstractLauncher. I shamlessly stole it from Squeak. If I do
not have it and start my generated CogVM I just get an open window with
some black rectangle  in the upper left.
This problem was  mentioned at:

http://code.google.com/p/pharo/issues/detail?id=4002

Now what did I have to do?
I downloaded the sources from squeak-vm and Cog and there are at least
two different C files and probably a header files with the prototyps:
The two files are
sqUnixSerial.c which is in  platforms/unix/plugins/SerialPlugin
SerialPlugin in src/plugins/SerialPlugin

It seems the first is the handwritten C-code

The first is needed to "offer" the functionality and the later is
probabl seems t be the interface to Squeak. I guess this is generated
code from some Slang code which looks like this:

parityType dataBits: dataBits inFlowControlType: inFlowControl outFlowControlType: outFlowControl xOnByte: xOnChar xOffByte: xOffChar

        | cString |
        self primitive: 'primitiveSerialPortOpenByName'
                parameters: #(ByteArray SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger ).
        self var: #cString type: 'char *'.
        cString := self allocateTerminatedString: deviceName.
        self cCode: 'serialPortOpenByName(
                        cString, baudRate, stopBitsType, parityType, dataBits,
                        inFlowControl, outFlowControl, xOnChar, xOffChar)'

which then write out the proper C code for that plugin.

You see I'm still ignorant on how this is all supposed to work.

Nevertheless copying the files at the proper places in the src and
platform tree. This codes get's compiled into the VirtualMachine.

And I can use this "machine" for accessing the serial interfaces, (it
even works for '/dev/ttyUSBx' devices. For me this is a great thing
because I'm forced to access some periperal devices via serial lines.

I need some extra hack in the generated file (I know this is "dirty" a
missing #define was introduced. I bet there is a better place for that
but in genrated code. But well it's  just an intermediate step.

If someone here may be interested just drop me a mail and with some help
we'll be able to modify the Cog sources cleanly to use this modified
Plugin for intefacing to serial lines in Linux.

I'm also quite aware that the Smalltalk side of the code could need a
little attention: It looks like:



nextPutAll: aStringOrByteArray
        "Send the given bytes out this serial port. The port must be
        open. "
        ^ port isString
                ifTrue: [self
                primWritePortByName: port
                from: aStringOrByteArray
                startingAt: 1
                count: aStringOrByteArray size]
                ifFalse: [self
                primWritePort: port
                from: aStringOrByteArray
                startingAt: 1
                count: aStringOrByteArray size]

Which is kind of "unproper" IMHO....

Regards
Friedrich




--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Reply | Threaded
Open this post in threaded view
|

Re: Questions of understanding

Mariano Martinez Peck


But I think there are a few problems with Pharo 1.3 and Cog. AFAIKT one
needs AbstractLauncher. I shamlessly stole it from Squeak. If I do
not have it and start my generated CogVM I just get an open window with
some black rectangle  in the upper left.
This problem was  mentioned at:

http://code.google.com/p/pharo/issues/detail?id=4002



yes. Cog doesn't load in Pharo 1.3 anymore. We will fix it.

 
Now what did I have to do?
I downloaded the sources from squeak-vm and Cog and there are at least
two different C files and probably a header files with the prototyps:
The two files are
sqUnixSerial.c which is in  platforms/unix/plugins/SerialPlugin
SerialPlugin in src/plugins/SerialPlugin

It seems the first is the handwritten C-code

yes, everything under /platform is the hand written part and known as "platform code"
 

The first is needed to "offer" the functionality and the later is
probabl seems t be the interface to Squeak. I guess this is generated
code from some Slang code

yes, and that's what is known as "VM sources", the auto generated C code from SLANG that is usually placed in /src
 
which looks like this:

parityType dataBits: dataBits inFlowControlType: inFlowControl outFlowControlType: outFlowControl xOnByte: xOnChar xOffByte: xOffChar

       | cString |
       self primitive: 'primitiveSerialPortOpenByName'
               parameters: #(ByteArray SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger ).
       self var: #cString type: 'char *'.
       cString := self allocateTerminatedString: deviceName.
       self cCode: 'serialPortOpenByName(
                       cString, baudRate, stopBitsType, parityType, dataBits,
                       inFlowControl, outFlowControl, xOnChar, xOffChar)'

which then write out the proper C code for that plugin.



yep

 
You see I'm still ignorant on how this is all supposed to work.


so do  I :)
 
Nevertheless copying the files at the proper places in the src and
platform tree. This codes get's compiled into the VirtualMachine.

And I can use this "machine" for accessing the serial interfaces, (it
even works for '/dev/ttyUSBx' devices. For me this is a great thing
because I'm forced to access some periperal devices via serial lines.

I need some extra hack in the generated file (I know this is "dirty" a
missing #define was introduced. I bet there is a better place for that
but in genrated code. But well it's  just an intermediate step.

If someone here may be interested just drop me a mail and with some help
we'll be able to modify the Cog sources cleanly to use this modified
Plugin for intefacing to serial lines in Linux.


Eliot should be interested.
But you didn't comment your changes. Maybe you can push them in git ?
 

I'm also quite aware that the Smalltalk side of the code could need a
little attention: It looks like:



nextPutAll: aStringOrByteArray
       "Send the given bytes out this serial port. The port must be
       open. "
       ^ port isString
               ifTrue: [self
               primWritePortByName: port
               from: aStringOrByteArray
               startingAt: 1
               count: aStringOrByteArray size]
               ifFalse: [self
               primWritePort: port
               from: aStringOrByteArray
               startingAt: 1
               count: aStringOrByteArray size]



for this you can open a pharo issue


--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Questions of understanding

Igor Stasenko
In reply to this post by FDominicus
On 25 May 2011 17:30, Friedrich Dominicus <[hidden email]> wrote:

> Mariano Martinez Peck <[hidden email]> writes:
>
>> I have no idea. Maybe someone in the VM mailing list can help you.
>>
> Ok I  finally got the serialPort access under Cog VM and Linux
> I concede it is currently a hackerish solution a combination out of
> Squeak sources and Cog sources with a good mixture of Cog
>
> So whomever may be "reponsible" can get in touch with me and I'll try to
> work out a stable implementation on Linux.
>
> But I think there are a few problems with Pharo 1.3 and Cog. AFAIKT one
> needs AbstractLauncher. I shamlessly stole it from Squeak. If I do
> not have it and start my generated CogVM I just get an open window with
> some black rectangle  in the upper left.
> This problem was  mentioned at:
>
> http://code.google.com/p/pharo/issues/detail?id=4002
>
> Now what did I have to do?
> I downloaded the sources from squeak-vm and Cog and there are at least
> two different C files and probably a header files with the prototyps:
> The two files are
> sqUnixSerial.c which is in  platforms/unix/plugins/SerialPlugin
> SerialPlugin in src/plugins/SerialPlugin
>
> It seems the first is the handwritten C-code
>
> The first is needed to "offer" the functionality and the later is
> probabl seems t be the interface to Squeak. I guess this is generated
> code from some Slang code which looks like this:
>
> parityType dataBits: dataBits inFlowControlType: inFlowControl outFlowControlType: outFlowControl xOnByte: xOnChar xOffByte: xOffChar
>
>        | cString |
>        self primitive: 'primitiveSerialPortOpenByName'
>                parameters: #(ByteArray SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger ).
>        self var: #cString type: 'char *'.
>        cString := self allocateTerminatedString: deviceName.
>        self cCode: 'serialPortOpenByName(
>                        cString, baudRate, stopBitsType, parityType, dataBits,
>                        inFlowControl, outFlowControl, xOnChar, xOffChar)'
>
> which then write out the proper C code for that plugin.
>
> You see I'm still ignorant on how this is all supposed to work.
>
> Nevertheless copying the files at the proper places in the src and
> platform tree. This codes get's compiled into the VirtualMachine.
>
> And I can use this "machine" for accessing the serial interfaces, (it
> even works for '/dev/ttyUSBx' devices. For me this is a great thing
> because I'm forced to access some periperal devices via serial lines.
>
> I need some extra hack in the generated file (I know this is "dirty" a
> missing #define was introduced. I bet there is a better place for that
> but in genrated code. But well it's  just an intermediate step.
>
> If someone here may be interested just drop me a mail and with some help
> we'll be able to modify the Cog sources cleanly to use this modified
> Plugin for intefacing to serial lines in Linux.
>

In order to answer this question we have to see what you did.
And for that, it would be good if you register on gitorious.org
and then clone VM sources into your own branch and then push your changes there.
Then we can analyze it and integrate into a main branch.

> I'm also quite aware that the Smalltalk side of the code could need a
> little attention: It looks like:
>
>
> nextPutAll: aStringOrByteArray
>        "Send the given bytes out this serial port. The port must be
>        open. "
>        ^ port isString
>                ifTrue: [self
>                primWritePortByName: port
>                from: aStringOrByteArray
>                startingAt: 1
>                count: aStringOrByteArray size]
>                ifFalse: [self
>                primWritePort: port
>                from: aStringOrByteArray
>                startingAt: 1
>                count: aStringOrByteArray size]
>
> Which is kind of "unproper" IMHO....
>

Please, create an issue on Cog issue tracker and
place a changeset for language side changes there.
You can also use that issue entry to describe your changes and point
to the VM-side source code
which you are changed.
http://code.google.com/p/cog/issues/list
Otherwise there is a risk, that your changes and comments will be
buried under tons of other mails
and will be lost.

P.S. it is great that you were able to fix plugin & build VM with little help.
If you have questions, do not hesitate to ask. We need people who are
not afraid to get their hands dirty and to fix something in VM :)


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Re: Questions of understanding

David T. Lewis
In reply to this post by Mariano Martinez Peck
For the SerialPlugin, there are two enhancements that will be found
in VMMaker and Squeak that should be added to Cog and to Pharo:

1) The named serial port updates are documented at
      <http://bugs.squeak.org/view.php?id=7266>

2) A separate bug fix for SerialPlugin on Unix is at
      <http://bugs.squeak.org/view.php?id=7610>

The VMMaker updates are in class SerialPlugin. These can probably
be copied directly from VMMaker trunk to the oscog branch using an
MC browser.

The platforms source changes can probably be copied directly from
Subversion trunk to the branches/cog tree, although I have not looked
at them to verify this (the platforms cog branch has changes in various
places, so some merging might be required). Note that the platforms
changes must be supported for all platforms, not just unix.

I think that the image changes have already been copied from Squeak
to Pharo. If not, just copy class SerialPort.

Dave

On Wed, May 25, 2011 at 10:41:33AM +0200, Mariano Martinez Peck wrote:

>  
> I have no idea. Maybe someone in the VM mailing list can help you.
>
> Cheers
>
> 2011/5/25 Friedrich Dominicus <[hidden email]>
>
> > Mariano Martinez Peck <[hidden email]> writes:
> >
> > > https://gitorious.org/cogvm/blessed/blobs/master/platforms/unix/plugins/
> > > SerialPlugin/sqUnixSerial.c
> > This code contains the old implementaton of the Serial Plugin not the
> > extensions of things like openPortByName. The Serail Plugin I'm talking
> > about has the following implementation on the Smalltalk Size
> >
> >
> >
> > --
> > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
> > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
> >
> >
>
>
> --
> Mariano
> http://marianopeck.wordpress.com


Reply | Threaded
Open this post in threaded view
|

Re: Questions of understanding

David T. Lewis
In reply to this post by Igor Stasenko
On Wed, May 25, 2011 at 05:46:00PM +0200, Igor Stasenko wrote:
>
> P.S. it is great that you were able to fix plugin & build VM with little help.
> If you have questions, do not hesitate to ask. We need people who are
> not afraid to get their hands dirty and to fix something in VM :)

Yes!

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Re: Questions of understanding

FDominicus
In reply to this post by David T. Lewis
"David T. Lewis" <[hidden email]> writes:

>  
> For the SerialPlugin, there are two enhancements that will be found
> in VMMaker and Squeak that should be added to Cog and to Pharo:
>
> 1) The named serial port updates are documented at
>       <http://bugs.squeak.org/view.php?id=7266>
>
> 2) A separate bug fix for SerialPlugin on Unix is at
>       <http://bugs.squeak.org/view.php?id=7610>
>
> The VMMaker updates are in class SerialPlugin. These can probably
> be copied directly from VMMaker trunk to the oscog branch using an
> MC browser.
Stupid question, should I look after it?

Regards
Friedrich

--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus