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

[Igor Stasenko]

On 25 May 2011 17:30, Friedrich Dominicus <frido at q-software-solutions.de> wrote:
> Mariano Martinez Peck <marianopeck at gmail.com> 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.