[Newbies] communication with serial port

Ken G. Brown kbrown at mac.com
Fri Nov 3 18:43:13 UTC 2006

>Date: Thu, 2 Nov 2006 22:13:44 -0500
>From: Benjamin Schroeder <benschroeder at acm.org>
>Subject: Re: [Newbies] communication with serial port
>Hi Ned, everyone,
>Please post any questions, thoughts, problems, etc.
>Benjamin Schroeder

In rooting around my squeak-dev archives I found this message from John McIntosh that mentions extended serial support. And on his www site <http://homepage.mac.com/WebObjects/FileSharing.woa/66/wo/4XP0BYBpP9D4dDvW.1/> there is a SerialExtendedUnixPlugin.bundle.zip.
I do not know anything more about it.


At 3:32 AM -0700 7/30/06, squeak-dev-request at lists.squeakfoundation.org wrote:
>Date: Sat, 29 Jul 2006 23:26:19 -0700
>From: John M McIntosh <johnmci at smalltalkconsulting.com>
>Subject: Re: Suggestions for C++ or DLL code
>To: Ron at USMedRec.com, The general-purpose Squeak developers list
>	<squeak-dev at lists.squeakfoundation.org>
>Cc: 'Cryptography Team Development List'
>	<cryptography at lists.squeakfoundation.org>
>	<9303CC02-F919-4F8F-BCD9-0E5311078498 at smalltalkconsulting.com>
>Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes;
>	format=flowed
>Well I've done all three, or is that four?
>a) FFI class via platform specific instances interfacing to generic 
>classes that a squeak user interacts with.
>b) FFI class/subclasses that are modified on the fly depending on 
>platform to get module name correct and or provide overrides by 
>platform, lots of this in Croquet.
>c) wrapper classes that use plugin code that lightly wraps api, 
>support work all done in Smalltalk, I did this for the extended 
>serial support.
>d) Generic classes that wrap plugin code that interfaces to platform 
>specific code, lots of this in the VM
>Generally getting folks to setup a development system, get VMMaker, 
>understand plugins, build and test something is only done by a 
>minority of squeakers.
>In using FFI, mapping the parms/return values to the correct 
>Smalltalk external objects will at some point drive you crazy, it 
>does all work, but sometimes late at night you
>wonder. For the most part we do this in Sophie, any one can do FFI, 
>but debugging is hard.
>Using lightly wrap APIs, that provides a bit clearer, in my opinion, 
>parameter specifications that then invoke the api. You usually can 
>use the development system source debugger to halt and debug at the 
>api inteface. It's a bit easy for folks to assemble features since 
>they can code the steps in smalltalk and interface to the apis, new 
>apis require someone to mangle plugin code and compile plugins. 
>Technically it's very similar to FFI, but avoids FFI.
>Using fully abstracted plugin with platform specific code, well 
>that's hard, and few folks want to participate. You can of course 
>write all the code via plugin code, I believe I do this for the mac 
>menu bar plugin since it's platform specific, there is no platform C 
>code, everything is done in squeak slang then compiled into the VM as 
>the mac menu bar plugin (used in Sophie btw).
>On 29-Jul-06, at 9:15 PM, Ron Teitelbaum wrote:
>> Hello all,
>> Iím currently working on a TLS / SSL implementation and on windows 
>> I am planning to support the Certificate Store that is built in.  
> > This requires me to use the CryptoAPI dlls.  The code is complex 
> > and it uses a number of header files and many steps.  I built some C
> > ++ code that does what Iím looking for so now I would like to 
>> incorporate this into Squeak.
>> Iíd assumed that FFI was like DDL/C connect in VW but thatís not 
>> what Iím seeing.  So my question is: What is the best way to get 
>> this working?  Should I hack away at FFI and support the api 
>> directly, and is that even possible?  Should I create DLLís to call 
>> and use them with FFI, or should I compile some sort of plugins?  
>> My preference would be to call the api directly without having to 
>> create dllís, duplicating my C++ code in Smalltalk if possible.
> >
>> Some direction and comparisons of different options would be very 
> > helpful.
>> Thank you for your help!
>> Ron Teitelbaum
>John M. McIntosh <johnmci at smalltalkconsulting.com>
>Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com

More information about the Beginners mailing list