On 5/5/2011 4:25 PM, Igor Stasenko wrote:
On 5 May 2011 21:39, Jimmie Houchin<jlhouchin@gmail.com> wrote:
On 5/5/2011 12:21 PM, Igor Stasenko wrote:
On 5 May 2011 18:57, Jimmie Houchin<jlhouchin@gmail.com> 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