[Pharo-project] Popularity of Smalltalk in Software Industry
jlhouchin at gmail.com
Fri May 6 01:03:41 CEST 2011
On 5/5/2011 4:25 PM, Igor Stasenko wrote:
> On 5 May 2011 21:39, Jimmie Houchin<jlhouchin at gmail.com> wrote:
>> On 5/5/2011 12:21 PM, Igor Stasenko wrote:
>>> On 5 May 2011 18:57, Jimmie Houchin<jlhouchin at 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.
>> 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
>> 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.
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.
22.214.171.124. 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
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-project