[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.
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/0.2.1.2.18.104.22.168.22.214.171.124.1?user=johnmci&fpath=experimental&templatefn=FileSharing.html> 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;
>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
>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