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

Mariano Martinez Peck marianopeck at gmail.com
Wed May 25 15:45:44 UTC 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110525/64e59ffe/attachment.htm


More information about the Vm-dev mailing list