[Pharo-project] One click feature list request/question
Hello all, Please feel free to say "that's going in the wrong direction," but it might be nice to have FFI, or at least the plugins, lurking in the one-click file structure. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
On 15.10.2008, at 22:53, Bill Schwab wrote:
Hello all,
Please feel free to say "that's going in the wrong direction," but it might be nice to have FFI, or at least the plugins, lurking in the one-click file structure.
I always thought that not having FFI in the Squeak image was a strange decision... It seemed to be very important to Andreas back then, so we did it. And it was the wrong thing to do, IMHO. But then, the new FFI of Eliot seems to be far, far better then the old one. It would be nice to have that instead. E.g, it supports callbacks nicely and is much faster. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
But then, the new FFI of Eliot seems to be far, far better then the old one. It would be nice to have that instead. E.g, it supports callbacks nicely and is much faster.
Go Eliot, go! It is crucial that Smalltalk gets better bindings with the outside world. It should be easy (as with Python or Ruby) to integrate some external C library. I hope the new FFI doesn't need to hack the Smalltalk language and compiler. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Talking about interoperability. I did some experiment a while ago about making Squeak talk to Java using sockets. Java classes are accessible within Squeak, and reflection is used to invoke methods. People interested in this could ask for further info. Cheers, Alexandre On 16 Oct 2008, at 09:55, Lukas Renggli wrote:
But then, the new FFI of Eliot seems to be far, far better then the old one. It would be nice to have that instead. E.g, it supports callbacks nicely and is much faster.
Go Eliot, go! It is crucial that Smalltalk gets better bindings with the outside world. It should be easy (as with Python or Ruby) to integrate some external C library.
I hope the new FFI doesn't need to hack the Smalltalk language and compiler.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I did some work to integrate LLVM and Clang with VW. I'm moving this to Squeak. For the platforms supported by LLVM this allows inline C/ ObjC/C++ (although C++ is early days yet), dynamically compiled and loaded, and highly optimized platform-independent SSA-based native code generation. As a side effect it can provide an optimized FFI based on jitted stubs/trampolines. I did this (trivially) for callout in VW, but didn't bother about callbacks. You can also use Clang to parse platform headers (and code), which you can obviously include in inline C, and also produce a parse tree with various degrees of semantic analysis, which you can then reflect on. Clang goes to extraordinary lengths to maintain source correspondence, which is an added bonus in interactive environment such as Smalltalk. Eliot's aware of that work. AFAIK he decided against using LLVM for Cog because Qwak wanted something that didn't increase the VM footprint, although he probably had some other reasons as well. PICs were an issue he raised, but that can be dealt with - in fact, by using runtime type recording at the call sites, plus some techniques used in multi-method dispatch for CLOS, you can optimize for both sides of a double dispatch, which would given at the very least highly optimized numeric operations. LLVM also does cool link time optimization and inlining, and I've got this (largely unformed) idea that the type-based specialisation could possibly trickle back along a call chain, resulting in block-aggregation that would expose more opportunity for optimization by delimiting regions of known type information. It might be however that such regions never practically get above a certain size. I'd like to investigate using LLVM to make plugins that are dynamically compiled and loaded (i.e. not via VMMaker). A further thought is that the VM could be regenerated, compiled and switched whilst running. This leads obviously to a *very* basic cross-platform headless VM that regenerates itself upon loading, optimized for the platform it's running on. Of course you'd cache this. Benefits of LLVM/Clang over roll-your-own native code generation are a) the significant optimization systems; b) cross-platform code generation; and c) dynamic C-family integration. And finally, LLVM/Clang are two of the most beautifully, cleanly architected and written pieces of C++ code I've ever seen. No, I'm not a contributor :) Anyone else interested in this? On 16/10/2008, at 6:33 PM, Alexandre Bergel wrote:
Talking about interoperability. I did some experiment a while ago about making Squeak talk to Java using sockets. Java classes are accessible within Squeak, and reflection is used to invoke methods. People interested in this could ask for further info.
Cheers, Alexandre
On 16 Oct 2008, at 09:55, Lukas Renggli wrote:
But then, the new FFI of Eliot seems to be far, far better then the old one. It would be nice to have that instead. E.g, it supports callbacks nicely and is much faster.
Go Eliot, go! It is crucial that Smalltalk gets better bindings with the outside world. It should be easy (as with Python or Ruby) to integrate some external C library.
I hope the new FFI doesn't need to hack the Smalltalk language and compiler.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 When I hear somebody sigh, 'Life is hard,' I am always tempted to ask, 'Compared to what?' -- Sydney Harris
Yes this is important! Stef On Oct 16, 2008, at 9:55 AM, Lukas Renggli wrote:
But then, the new FFI of Eliot seems to be far, far better then the old one. It would be nice to have that instead. E.g, it supports callbacks nicely and is much faster.
Go Eliot, go! It is crucial that Smalltalk gets better bindings with the outside world. It should be easy (as with Python or Ruby) to integrate some external C library.
I hope the new FFI doesn't need to hack the Smalltalk language and compiler.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 16.10.2008, at 10:40, Antony Blakey wrote:
Anyone else interested in this?
Sounds cool! Of course, the question always is what means "interested in this", in the light of no funding and limited spare time? Marcus
I did some work to integrate LLVM and Clang with VW. I'm moving this to Squeak. For the platforms supported by LLVM this allows inline C/ ObjC/C++ (although C++ is early days yet), dynamically compiled and loaded, and highly optimized platform-independent SSA-based native code generation. As a side effect it can provide an optimized FFI based on jitted stubs/trampolines. I did this (trivially) for callout in VW, but didn't bother about callbacks. You can also use Clang to parse platform headers (and code), which you can obviously include in inline C, and also produce a parse tree with various degrees of semantic analysis, which you can then reflect on. Clang goes to extraordinary lengths to maintain source correspondence, which is an added bonus in interactive environment such as Smalltalk.
Eliot's aware of that work. AFAIK he decided against using LLVM for Cog because Qwak wanted something that didn't increase the VM footprint, although he probably had some other reasons as well. PICs were an issue he raised, but that can be dealt with - in fact, by using runtime type recording at the call sites, plus some techniques used in multi-method dispatch for CLOS, you can optimize for both sides of a double dispatch, which would given at the very least highly optimized numeric operations. LLVM also does cool link time optimization and inlining, and I've got this (largely unformed) idea that the type-based specialisation could possibly trickle back along a call chain, resulting in block-aggregation that would expose more opportunity for optimization by delimiting regions of known type information. It might be however that such regions never practically get above a certain size.
I'd like to investigate using LLVM to make plugins that are dynamically compiled and loaded (i.e. not via VMMaker). A further thought is that the VM could be regenerated, compiled and switched whilst running. This leads obviously to a *very* basic cross- platform headless VM that regenerates itself upon loading, optimized for the platform it's running on. Of course you'd cache this.
Benefits of LLVM/Clang over roll-your-own native code generation are a) the significant optimization systems; b) cross-platform code generation; and c) dynamic C-family integration.
And finally, LLVM/Clang are two of the most beautifully, cleanly architected and written pieces of C++ code I've ever seen. No, I'm not a contributor :)
On 16/10/2008, at 6:33 PM, Alexandre Bergel wrote:
Talking about interoperability. I did some experiment a while ago about making Squeak talk to Java using sockets. Java classes are accessible within Squeak, and reflection is used to invoke methods. People interested in this could ask for further info.
Cheers, Alexandre
On 16 Oct 2008, at 09:55, Lukas Renggli wrote:
But then, the new FFI of Eliot seems to be far, far better then the old one. It would be nice to have that instead. E.g, it supports callbacks nicely and is much faster.
Go Eliot, go! It is crucial that Smalltalk gets better bindings with the outside world. It should be easy (as with Python or Ruby) to integrate some external C library.
I hope the new FFI doesn't need to hack the Smalltalk language and compiler.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
When I hear somebody sigh, 'Life is hard,' I am always tempted to ask, 'Compared to what?' -- Sydney Harris
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
On 17/10/2008, at 6:08 PM, Marcus Denker wrote:
Of course, the question always is what means "interested in this", in the light of no funding and limited spare time?
I'm not au fait with the detailed history of Squeak, but I know that you've been at the pointy end of the thankless and shitty task of harvesting for release, so I mean no disrespect, and acknowledge that it is a problem. However ... I had no external funding and limited time and yet I managed to make LLVM/Clang work in VW, as well as many other things. I've found that ST can be phenomenally productive for these kind of things, especially when you a) you don't try to solve every problem, esp. in every 'market' that uses Squeak; and b) you leverage existing codebases such as LLVM/Clang/WebKit/GIT etc. <rant> IMO Smalltalk's fatal flaw is it's lack of modularity and good system construction. Pharo is one kind of process, but IMO a more fundamental rethink of system construction mechanisms is required, at all granularities. IMO the #1 priority should be dealing with this problem which has burdened Smalltalk since it's inception. It's particularly problematic in Squeak because it tries to address so many uses, there's so much stuff added to Squeak, and often then abandoned, and no one seems to do any serious documentation of any architecture or implementation, apart from a few Traits papers and one OB paper. </rant> I've found it more productive to completely replace components rather than attempt to untangle the mess that it is e.g. a typical GUI component. I've developed a very productive way of doing that involving class cloning, hierarchy collapsing and brutal simplification. I think 90% of the entanglement problem is in Morphic, so being brutal there, which can be accomplished by focussing on keeping OB working and letting just about every other GUI tool rot, is a productive strategy. I'm greatly enhancing OB, and by relying on it's abstraction from the GUI (and using OB-Tools) Squeak can be kept usable whilst pruning with a chainsaw. I can do this because I'm not trying to produce a system that is backwards compatible in any sense, primarily because I've implemented a solution to the system construction/modularity problem, so I'm trying to reboot to a from-source modular bootstrap. Thus, my mileage will vary compared to people with other constraints. So I suppose by 'interested' I mean 'interested in LLVM/Clang in the context of a far more brutal reboot than Pharo'. I guess skepticism is warranted, and I failed to garner interest in the VW community in spite of providing proof-of-concept demonstrations for my proposals, so I admit I'm fishing (although not, I hope, trolling) :) Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 He who would make his own liberty secure, must guard even his enemy from repression. -- Thomas Paine
Antony Blakey schrieb:
I can do this because I'm not trying to produce a system that is backwards compatible in any sense, primarily because I've implemented a solution to the system construction/modularity problem, so I'm trying to reboot to a from-source modular bootstrap. Thus, my mileage will vary compared to people with other constraints.
One "quicker-written-than-thought" posting: GNU Smalltalk implements from-source bootstrapping (the image gets constructed from a source kernel if not available). GNU Smalltalk can do this (I don't know the deep internals) since the compiler is implemented i C/ native. Squeak itself was "bootstrapped" once or twice (depending on the point of view, SystemTracer did transform the image into something different). Pharo, as I understand (CMIIW) was bootstrapped by reimplement, delete previous version, distribute. Naiad (is, will be) bootstrapped by keeping a minimal ObjectMemory-Invocation image connected by a Compiler-having image. So... as long there's no SLang-convertable compiler, squeak and siblings won't be able to be a "from-scratch-implementation" built from the sources, right? And there will be always a big graph of objects that are "created, saved, non-recreatable"? Hm, 'scuse me, I'm wearing my troll-mask today ;-)
participants (7)
-
Alexandre Bergel -
Antony Blakey -
Bill Schwab -
Lukas Renggli -
Marcus Denker -
Markus Fritsche -
Stéphane Ducasse