Hi guys!
When looking for ammo :-) in "the GPL/LGPL duel" on the net I stumbled upon cURL and libcurl:
Could this be a good plugin candidate? It sounds super to me, has a good license (MIT, which I guess is ok with SqueakL, oooh, here we go again... ;-) and seems to be very easy to interface to, take a look at the C-api.
Anyway, fishing a bit before I try myself. There are so many other good slang-wielders out there but of course, now that VMMaker (thanks, Tim) is here I have no good excuse to stay out of the plugin business, right? :-)
regards, Göran
PS. Plugins for solid good libraries is IMHO a very simple way of making Squeak better. We don't HAVE to make everything ourselves, right? :-) Even if it is fun... DS
On Wed, 31 Oct 2001 goran.hultgren@bluefish.se wrote:
PS. Plugins for solid good libraries is IMHO a very simple way of making Squeak better. We don't HAVE to make everything ourselves, right? :-) Even if it is fun... DS
I agree. In fact, I think this is something we need to start doing to gain some more general acceptance. In having been involved in some capacity in the Squeak and Lisp community for a couple years now (not very long time, mind you), too often the answer the question of "how do I hook up xxx implementation with the yyy library?" is "Rewrite it in xxx." Seen it on this list, seen it on comp.lang.lisp.
I think it would make Squeak quite good if we kept a plug-in/FFI-class directory on the Swiki. A list of libraries Squeak hooks up with. Show that Smalltalk *can* play well with others.
/rant...
Regards, Aaron
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/ "civilization is a limitless multiplication of unnecessary necessities." :: mark twain
I think it would make Squeak quite good if we kept a plug-in/FFI-class directory on the Swiki. A list of libraries Squeak hooks up with. Show that Smalltalk *can* play well with others.
I think this is a great idea. It is really easy with FFI to interface Squeak with external libs (though there are some enhancements to FFI that would make things even easier). Of course the ideal solution is to rewrite the external lib in Squeak, then pluginize any key algorithms to achieve performance, but using an external lib is the next best thing.
Having a central place to keep track of external libs that people have wrapped in Squeak would be great.
- Stephen
"Stephen Pair" spair@advantive.com is widely believed to have written:
I think this is a great idea. It is really easy with FFI to interface Squeak with external libs
As a general rule it will usually perform better if you write a plugin to interface to the external library. You get the chance to make a nice clean interface for the Squeak side, you can handle structures effectively etc etc.
tim
I know...but I like the simplicity of FFI. If you have a pre-compiled library (DLL) in hand, you can call it directly with FFI without needing to translate and compile anything.
- Stephen
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Tim Rowledge Sent: Wednesday, October 31, 2001 11:40 AM To: squeak-dev@lists.squeakfoundation.org Subject: RE: External Libs (was Re: libcurl?!)
"Stephen Pair" spair@advantive.com is widely believed to have written:
I think this is a great idea. It is really easy with FFI
to interface
Squeak with external libs
As a general rule it will usually perform better if you write a plugin to interface to the external library. You get the chance to make a nice clean interface for the Squeak side, you can handle structures effectively etc etc.
tim
-- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful > random insult:- Full of
wisdumb.
Ditto here...
I had a simple class that used FFI to call some functions in an external library. For some reason, FFI no longer works for me on UNIX so I bought the "NuBlue" book and read the chapter on making plugins...and it made my head spin. I'm sure I just need to re-read the chapter and look at some working examples, but FFI is much simpler for 'quick and dirty' experimentation.
On Wed, Oct 31, 2001 at 02:41:42PM -0500, Stephen Pair wrote:
I know...but I like the simplicity of FFI. If you have a pre-compiled library (DLL) in hand, you can call it directly with FFI without needing to translate and compile anything.
- Stephen
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Tim Rowledge Sent: Wednesday, October 31, 2001 11:40 AM To: squeak-dev@lists.squeakfoundation.org Subject: RE: External Libs (was Re: libcurl?!)
"Stephen Pair" spair@advantive.com is widely believed to have written:
I think this is a great idea. It is really easy with FFI
to interface
Squeak with external libs
As a general rule it will usually perform better if you write a plugin to interface to the external library. You get the chance to make a nice clean interface for the Squeak side, you can handle structures effectively etc etc.
tim
-- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful > random insult:- Full of
wisdumb.
On Thu, 1 Nov 2001, Kevin Fisher wrote:
Ditto here...
I had a simple class that used FFI to call some functions in an external library. For some reason, FFI no longer works for me on UNIX
Actually, FFI works on Linux as it ever has. Just get SqueakFFIPrims.so from somewhere (Andreas' original release still works fine: http://isgwww.cs.uni-magdeburg.de/~raab/squeak/FFI), put it somewhere it can be found (cwd does nicely), and off you go - I just tried
X11Display coloredRectangles
Simply because it's "disabled" in the build process does not mean it wont work. And it *is* a heck of a security hole. It is so dangerous that we want everyone who wants to use it spend a little effort to get.
-- Bert
On Thu, Nov 01, 2001 at 03:45:52PM +0100, Bert Freudenberg wrote:
On Thu, 1 Nov 2001, Kevin Fisher wrote:
Ditto here...
I had a simple class that used FFI to call some functions in an external library. For some reason, FFI no longer works for me on UNIX
Actually, FFI works on Linux as it ever has. Just get SqueakFFIPrims.so from somewhere (Andreas' original release still works fine: http://isgwww.cs.uni-magdeburg.de/~raab/squeak/FFI), put it somewhere it can be found (cwd does nicely), and off you go - I just tried
Yes, I think it's a problem on my end. I've got the plugin, the external libffi et al...but ever since the 3.0 VM it just stopped working for me. I figured it was high time I learned about VM plugins anyways so I've not looked into it too deeply.
X11Display coloredRectangles
Simply because it's "disabled" in the build process does not mean it wont work. And it *is* a heck of a security hole. It is so dangerous that we want everyone who wants to use it spend a little effort to get.
-- Bert
I usually build my own VMs and yes, it -is- enabled...why it doesn't work on my end warrants a little investigation on my part I guess. I still need to figure out making plugins though. :) What I was doing with FFI (making calls to glib and libxmms) is something that better fits as a plugin.
(It worked fine for me with the old 2.9 VM sources, however. It really is handy for "quickly" prototyping a plugin.)
Kevin Fisher kgf@golden.net is widely believed to have written:
Ditto here...
I had a simple class that used FFI to call some functions in an external library. For some reason, FFI no longer works for me on UNIX
I'm not going to claim to be sure, since the autoconf stuff andmakefile making still mystifies me, but if you look in the sourcecode tree I'm faily sure you'll find that the unix ffi plugin is carefully excluded. If you can hack autoconf/make you should be able to change it. Tell me how....
so I bought the "NuBlue" book and read the chapter on making plugins...and it made my head spin. I'm sure I just need to re-read the chapter and look at some working examples, but FFI is much simpler for 'quick and dirty' experimentation.
Take a look at some of the subclasses of TestInterpreterPlugin that use AndyG's simpler slang style.
tim
On Thu, Nov 01, 2001 at 07:22:15AM -0800, Tim Rowledge wrote:
Kevin Fisher kgf@golden.net is widely believed to have written:
Ditto here...
I had a simple class that used FFI to call some functions in an external library. For some reason, FFI no longer works for me on UNIX
I'm not going to claim to be sure, since the autoconf stuff andmakefile making still mystifies me, but if you look in the sourcecode tree I'm faily sure you'll find that the unix ffi plugin is carefully excluded. If you can hack autoconf/make you should be able to change it. Tell me how....
Yes, I noticed that. :) I did enable it when I compiled and still no dice.. I must be doing something wrong.
One difference I noticed between 2.9a and the 3.0/3.1 VM is that the --enable-ffi=yes configure argument went away.
so I bought the "NuBlue" book and read the chapter on making plugins...and it made my head spin. I'm sure I just need to re-read the chapter and look at some working examples, but FFI is much simpler for 'quick and dirty' experimentation.
Take a look at some of the subclasses of TestInterpreterPlugin that use AndyG's simpler slang style.
tim
Thanks, I will. The FFI stuff I was doing was to "flesh out" a plugin anyway...now that I know what I want to do (and that it works), I want to plugin-ize it.
I'm totally new to Slang so I think I just need to get a grip on it. :)
-- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Sure it's user-friendly...if you know what you're doing.
On Thu, 1 Nov 2001, Kevin Fisher wrote:
Yes, I noticed that. :) I did enable it when I compiled and still no dice.. I must be doing something wrong.
One difference I noticed between 2.9a and the 3.0/3.1 VM is that the --enable-ffi=yes configure argument went away.
As I said before, you don't have to "enable" FFI. Just get the plugin. You don't even need libffi because it's statically linked into SqueakFFIPrims.so.
-- Bert
In case you don't believe me: This is a log of the X11 example:
tryLoading ./SqueakFFIPrims.so loaded: ./SqueakFFIPrims.so ioFindExternalFunctionIn(getModuleName, 135169408) ioFindExternalFunctionIn(getModuleName, 135169408): build/squeak: undefined symbol: getModuleName ioFindExternalFunctionIn(setInterpreter, 135169408) ioFindExternalFunctionIn(initialiseModule, 135169408) ioFindExternalFunctionIn(initialiseModule, 135169408): build/squeak: undefined symbol: initialiseModule ioFindExternalFunctionIn(primitiveCallout, 135169408) tryLoading ./X11.so not found tryLoading libX11.so loaded: libX11.so ioFindExternalFunctionIn(XOpenDisplay, 1073836808) ioFindExternalFunctionIn(XGetInputFocus, 1073836808) ioFindExternalFunctionIn(XQueryPointer, 1073836808) ioFindExternalFunctionIn(primitiveFFIIntegerAt, 135169408) ioFindExternalFunctionIn(XCreateGC, 1073836808) ioFindExternalFunctionIn(XSetForeground, 1073836808) ioFindExternalFunctionIn(XFillRectangle, 1073836808) ioFindExternalFunctionIn(XDrawRectangle, 1073836808) ioFindExternalFunctionIn(XSync, 1073836808) ioFindExternalFunctionIn(XFreeGC, 1073836808) ioFindExternalFunctionIn(XCloseDisplay, 1073836808)
On Fri, Nov 02, 2001 at 10:17:34AM +0100, Bert Freudenberg wrote:
On Thu, 1 Nov 2001, Kevin Fisher wrote:
Yes, I noticed that. :) I did enable it when I compiled and still no dice.. I must be doing something wrong.
One difference I noticed between 2.9a and the 3.0/3.1 VM is that the --enable-ffi=yes configure argument went away.
As I said before, you don't have to "enable" FFI. Just get the plugin. You don't even need libffi because it's statically linked into SqueakFFIPrims.so.
I realize that, I was only referring to self-built VM's. The 2.9a VM configure did have such an option if you were building from source. At one time I was trying to get FFI working on ARM, which is why I needed to rebuild it myself.
Out of curiosity, how did you produce that log below?
-- Bert
In case you don't believe me: This is a log of the X11 example:
tryLoading ./SqueakFFIPrims.so loaded: ./SqueakFFIPrims.so ioFindExternalFunctionIn(getModuleName, 135169408) ioFindExternalFunctionIn(getModuleName, 135169408): build/squeak: undefined symbol: getModuleName ioFindExternalFunctionIn(setInterpreter, 135169408) ioFindExternalFunctionIn(initialiseModule, 135169408) ioFindExternalFunctionIn(initialiseModule, 135169408): build/squeak: undefined symbol: initialiseModule ioFindExternalFunctionIn(primitiveCallout, 135169408) tryLoading ./X11.so not found tryLoading libX11.so loaded: libX11.so ioFindExternalFunctionIn(XOpenDisplay, 1073836808) ioFindExternalFunctionIn(XGetInputFocus, 1073836808) ioFindExternalFunctionIn(XQueryPointer, 1073836808) ioFindExternalFunctionIn(primitiveFFIIntegerAt, 135169408) ioFindExternalFunctionIn(XCreateGC, 1073836808) ioFindExternalFunctionIn(XSetForeground, 1073836808) ioFindExternalFunctionIn(XFillRectangle, 1073836808) ioFindExternalFunctionIn(XDrawRectangle, 1073836808) ioFindExternalFunctionIn(XSync, 1073836808) ioFindExternalFunctionIn(XFreeGC, 1073836808) ioFindExternalFunctionIn(XCloseDisplay, 1073836808)
On Fri, 2 Nov 2001, Kevin Fisher wrote:
On Fri, Nov 02, 2001 at 10:17:34AM +0100, Bert Freudenberg wrote:
On Thu, 1 Nov 2001, Kevin Fisher wrote:
Yes, I noticed that. :) I did enable it when I compiled and still no dice.. I must be doing something wrong.
One difference I noticed between 2.9a and the 3.0/3.1 VM is that the --enable-ffi=yes configure argument went away.
As I said before, you don't have to "enable" FFI. Just get the plugin. You don't even need libffi because it's statically linked into SqueakFFIPrims.so.
I realize that, I was only referring to self-built VM's. The 2.9a VM configure did have such an option if you were building from source. At one time I was trying to get FFI working on ARM, which is why I needed to rebuild it myself.
Out of curiosity, how did you produce that log below?
Oh, I just enabled the DPRINTF macro in sqUnixExternal.c (or whatever it's called). Helps figuring out that stuff.
-- Bert
In case you don't believe me: This is a log of the X11 example:
tryLoading ./SqueakFFIPrims.so loaded: ./SqueakFFIPrims.so ioFindExternalFunctionIn(getModuleName, 135169408) ioFindExternalFunctionIn(getModuleName, 135169408): build/squeak: undefined symbol: getModuleName ioFindExternalFunctionIn(setInterpreter, 135169408) ioFindExternalFunctionIn(initialiseModule, 135169408) ioFindExternalFunctionIn(initialiseModule, 135169408): build/squeak: undefined symbol: initialiseModule ioFindExternalFunctionIn(primitiveCallout, 135169408) tryLoading ./X11.so not found tryLoading libX11.so loaded: libX11.so ioFindExternalFunctionIn(XOpenDisplay, 1073836808) ioFindExternalFunctionIn(XGetInputFocus, 1073836808) ioFindExternalFunctionIn(XQueryPointer, 1073836808) ioFindExternalFunctionIn(primitiveFFIIntegerAt, 135169408) ioFindExternalFunctionIn(XCreateGC, 1073836808) ioFindExternalFunctionIn(XSetForeground, 1073836808) ioFindExternalFunctionIn(XFillRectangle, 1073836808) ioFindExternalFunctionIn(XDrawRectangle, 1073836808) ioFindExternalFunctionIn(XSync, 1073836808) ioFindExternalFunctionIn(XFreeGC, 1073836808) ioFindExternalFunctionIn(XCloseDisplay, 1073836808)
On Wednesday 31 October 2001 08:42 am, Stephen Pair wrote:
I think it would make Squeak quite good if we kept a plug-in/FFI-class directory on the Swiki. A list of libraries Squeak hooks up with. Show that Smalltalk *can* play well with others.
I think this is a great idea. It is really easy with FFI to interface Squeak with external libs (though there are some enhancements to FFI that would make things even easier). Of course the ideal solution is to rewrite the external lib in Squeak, then pluginize any key algorithms to achieve performance, but using an external lib is the next best thing.
Having a central place to keep track of external libs that people have wrapped in Squeak would be great.
But FFI was removed from the Squeak distribution by SqC who feel that it's a security hole and would be a problem for their network distribution of active content.
But FFI was removed from the Squeak distribution by SqC who feel that it's a security hole and would be a problem for their network distribution of active content.
What's your point? Just because its not in the SqC distribution doesn't mean it can't be used. Hopefully we'll have a more comprehensive approach to security in the future so that this won't be an issue. Until then, we could have several different distributions that have different objectives. For instance, SqC might produce bundles that are intended for use with active content from the web, where security would be a higher priority.
- Stephen
On Wednesday 31 October 2001 10:09 am, Stephen Pair wrote:
But FFI was removed from the Squeak distribution by SqC who feel that it's a security hole and would be a problem for their network distribution of active content.
What's your point? Just because its not in the SqC distribution doesn't mean it can't be used. Hopefully we'll have a more comprehensive approach to security in the future so that this won't be an issue. Until then, we could have several different distributions that have different objectives. For instance, SqC might produce bundles that are intended for use with active content from the web, where security would be a higher priority.
Just that I can't distribute something that uses FFI to the Squeak world and expect that they'll be able to run it (unless I also distribute the FFI plugin, but I seem to recall that this wasn't sufficient to make it work).
There are even a few Windows and Mac users who can't re-compile their own VM's!
Ned Konz wrote:
There are even a few Windows and Mac users who can't re-compile their own VM's!
It would be nice to have a place to organize VMs and plugins that people build, maybe on the Swiki? What kind of info would we need for each? Interpreter version (3.0, 3.1) Custom enhancements (if any) Builtin Plugins (with info on version and enhancements) External Plugins (bundled with download)
- Stephen
Ned Konz wrote:
There are even a few Windows and Mac users who can't re-compile their own VM's!
It would be nice to have a place to organize VMs and plugins that people build, maybe on the Swiki? What kind of info would we need for each? Interpreter version (3.0, 3.1) Custom enhancements (if any) Builtin Plugins (with info on version and enhancements) External Plugins (bundled with download)
- Stephen
Dare I suggest the VMMaker source tree on sourgeforge.net? Seems that would be the logical place for storage of C specific plugins, also the fact that many of the libraries some of the plugins need are also stored on sourceforge.
This also answers the question about FFI, although FFI support isn't in the base distribution that shouldn't stop someone from going to sourceforge and getting the latest plugin binary, these do exist, but the problem is that they are difficult to find right now.
John M McIntosh johnmci@smalltalkconsulting.com is widely believed to have written:
Dare I suggest the VMMaker source tree on sourgeforge.net? Seems that would be the logical place for storage of C specific plugins, also the fact that many of the libraries some of the plugins need are also stored on sourceforge.
It should be a good place for the source code, but I think the original request was for a place for _compiled_ stuff; in which case Bruce already administers such a place.
This also answers the question about FFI, although FFI support isn't in the base distribution that shouldn't stop someone from going to sourceforge and getting the latest plugin binary, these do exist, but the problem is that they are difficult to find right now.
The source code is already there _IF_ it was in the source trees I grabbed to make the VMMaker tree. I haven't done anything at all to change whether or not the FFI plugin is buildable; for example the unix stuff seems to be carefully excluded in the makefile.
tim
squeak-dev@lists.squeakfoundation.org