On 5/5/2011 4:25 PM, Igor Stasenko wrote:
On 5 May 2011 21:39, Jimmie Houchin<[email protected]> wrote:
On 5/5/2011 12:21 PM, Igor Stasenko wrote:
On 5 May 2011 18:57, Jimmie Houchin<[email protected]> wrote:
[Big Snip]
Well said.
Except that i'm not sharing your view that its hard to interface with
foreign libraries.
Its not hard at all. Of course to connect two different worlds, you
need to have knowledge
in both of them. But this requirement not a bit different when you
take any other pair of languages and try to
connect them.
Thanks,
I have no knowledge of either the knowledge or the challenges involved in
using external libraries in Pharo or Squeak. I have no knowledge of
FFI/Alien or using C/C++/C# or compilers.
However, this is my experience in Python.
Navigate to the directory containing the script makepy.py or if it is a part
of your Python's sys.path, execute the script. It generates a Python module
which is on
It pops up a dialogue which prompts you to select the library you wish to
interface.
Then to use in a script simply
import Dispatch
self.mylib = Dispatch("MyLibrary")
This will expose all the functionality of the library.
All provided by the python win32 extensions. It was very successful for my
needs. I do not know what limitations it may or may not have.
Very easy for non-expert programmers. I would love this level of ability to
interface outside libraries in Squeak. But I have no idea the effort
required to automate the generation of a class or classes which interface
the external library.
In my particular instance this is obviously for a Windows library. I don't
know if Python has anything comparable for Linux or OSX.
In this particular instance, Python was enabling for me, for which I am
grateful. Otherwise I might be stuck writing my app in VisualBasic. But
despite my gratefulness, I spend as little time in Python as possible.
Despite Python not requiring a compiler, I really hate going to an editor
and writing code. Then to an interpreter to run code. Hit my stacktrace. Go
back to the editor. Reload the module in the interpreter and run again, and
if that doesn't succeed due to the reload not really reloading the new code,
open in a new interpreter. Ugh!!! Where's my Smalltalk. Give my live object
system. :)
Haha.. i have strong suspicion that here you are talking about quite
specific set of libraries,
which using OLE/COM interfaces. Indeed, one could implement an
automatic "import/connect" tool
for it, because a library itself contain enough information reflecting
it interface(s).
You can check Dolphin smalltalk which works only on windows and has
integrated solution for that for years:
In same way like you described, you just pick the library, click "ok"
and its done& ready for use.
But that would be too easy if you could do same with any other library
in your system.
So, if you feel adventurous, try to check what Python can do with
libraries like Kernel32.dll
or User32.dll. I am sure it can do as little as Smalltalk in this
regard, but you are free to check it yourself :)
As I said, I am totally unaware of the limitations of the system, but
that it did what I need, and would have liked to do that from
Pharo/Squeak. I know Dolphin has/had certain capabilities. But I don't
prefer to use non-open source software if at all possible for
development. I also am very preferential towards cross-platform
software. Dolphin fails on all accounts. I would choose my Python/Pharo
blend over Dolphin any day. I know it introduces some pain, but I am
willing to accept the pain. I like tools that allow me to use them where
ever I am and whatever I am doing.
However, that said, when I look at the facilities Python offers for such
capabilities it on appearances looks quite impressive.
http://docs.python.org/library/ctypes.html
"""
ctypes is a foreign function library for Python. It provides C
compatible data types, and allows calling functions in DLLs or shared
libraries. It can be used to wrap these libraries in pure Python.
15.18.1.1. Loading dynamic link libraries
ctypes exports the /cdll/, and on Windows /windll/ and /oledll/ objects,
for loading dynamic link libraries.
You load libraries by accessing them as attributes of these objects.
/cdll/ loads libraries which export functions using the standard cdecl
calling convention, while /windll/ libraries call functions using the
stdcall calling convention. /oledll/ also uses the stdcall calling
convention, and assumes the functions return a Windows HRESULT error
code. The error code is used to automatically raise a WindowsError
exception when the function call fails.
Here are some examples for Windows. Note that msvcrt is the MS standard
C library containing most standard C functions, and uses the cdecl
calling convention:
from ctypes import *
print windll.kernel32 # doctest: +WINDOWS
<WinDLL 'kernel32', handle ... at ...>
print cdll.msvcrt # doctest: +WINDOWS
<CDLL 'msvcrt', handle ... at ...>
libc = cdll.msvcrt # doctest: +WINDOWS
"""
It has examples for windows and linux.
I didn't read it all as I am unqualified to assess its capabilities or
limitations, nor do I presently need it as the win32 extensions do
easily and well what I presently need to do.
Hopefully it can inform us as to what is expected and doable in
alternative languages which are dynamic like Smalltalk.
Jimmie
