I have a C app that I'd like to port to Squeak. I had this crazy idea that I wanted to incrementally replace parts of it bit by bit with Smalltalk, and was entertained by how that seemed roughly impossible. The first thought that crossed my mind was to try to bolt some sort of C-based RPC onto it, and use that as a way to get it to talk to Squeak. Then I thought about FFI, but what I'm reading about that talks specifically about libraries.
Here's what I'm wondering:
Would it be insanely painful to make parts of the app into libraries that could get called via FFI? Would it just make more sense to do a scratch implementation? Has anyone ever done something like this before?
It's a crazy idea:)
On 17/08/10 01:34, Casey Ransberger wrote:
I have a C app that I'd like to port to Squeak. I had this crazy idea that I wanted to incrementally replace parts of it bit by bit with Smalltalk, and was entertained by how that seemed roughly impossible. The first thought that crossed my mind was to try to bolt some sort of C-based RPC onto it, and use that as a way to get it to talk to Squeak. Then I thought about FFI, but what I'm reading about that talks specifically about libraries.
Here's what I'm wondering:
Would it be insanely painful to make parts of the app into libraries that could get called via FFI? Would it just make more sense to do a scratch implementation? Has anyone ever done something like this before?
It's a crazy idea:)
It's difficult to comment without some details of your app. How big/complicated is it? Does it have a UI? Does it call other libs? Does it use threading or do a lot of IO? Is speed a factor? What platform?
If the app is not so big, is already well structured and has no special requirements then you could split it into libs as a first step and then later migrate C-code to Smalltalk in manageable chunks. Alternatively jump in with both feet and re-implement as much as possible in Squeak :-)
-D
On 17 August 2010 03:34, Casey Ransberger casey.obrien.r@gmail.com wrote:
I have a C app that I'd like to port to Squeak. I had this crazy idea that I wanted to incrementally replace parts of it bit by bit with Smalltalk, and was entertained by how that seemed roughly impossible. The first thought that crossed my mind was to try to bolt some sort of C-based RPC onto it, and use that as a way to get it to talk to Squeak. Then I thought about FFI, but what I'm reading about that talks specifically about libraries. Here's what I'm wondering:
Would it be insanely painful to make parts of the app into libraries that could get called via FFI? Would it just make more sense to do a scratch implementation? Has anyone ever done something like this before? It's a crazy idea:)
Not really crazy. I had same goal In 2006 (i think) , first i implemented own smalltalk interpreter, then using SWIG compiler i implemented Ogre 3D library bindings, which generates glue C++ code, reflecting C++ object into smalltalk. I was able to allocate new objects, call constructor/destructor, access fields, static and virtual functions. But then i dropped it, and switched to Squeak, since its having much more mature VM, comparing to my baby interpreter :)
-- Casey Ransberger
Just, :)
Wow.
On Aug 17, 2010, at 1:29 AM, Igor Stasenko siguctua@gmail.com wrote:
On 17 August 2010 03:34, Casey Ransberger casey.obrien.r@gmail.com wrote:
I have a C app that I'd like to port to Squeak. I had this crazy idea that I wanted to incrementally replace parts of it bit by bit with Smalltalk, and was entertained by how that seemed roughly impossible. The first thought that crossed my mind was to try to bolt some sort of C-based RPC onto it, and use that as a way to get it to talk to Squeak. Then I thought about FFI, but what I'm reading about that talks specifically about libraries. Here's what I'm wondering:
Would it be insanely painful to make parts of the app into libraries that could get called via FFI? Would it just make more sense to do a scratch implementation? Has anyone ever done something like this before? It's a crazy idea:)
Not really crazy. I had same goal In 2006 (i think) , first i implemented own smalltalk interpreter, then using SWIG compiler i implemented Ogre 3D library bindings, which generates glue C++ code, reflecting C++ object into smalltalk. I was able to allocate new objects, call constructor/destructor, access fields, static and virtual functions. But then i dropped it, and switched to Squeak, since its having much more mature VM, comparing to my baby interpreter :)
-- Casey Ransberger
-- Best regards, Igor Stasenko AKA sig.
Hello,
I do something similar now. We have ugly app with C++ server part and IExplorer JS and flash ui part. C++ part run iexplorer through com and interract with it by some binding trick.
First we replace ui with pharo morphic app and create binding with socket connections. Pharo sends socket commands to C++ tcp server and receive events from C++ to smalltalk socket server. Its were really easy done because I don't deal with ffi issues like callbacks and there is no need to build C++ dll .
Now we replace step-by-step separated C++ modules with smalltalk. Sometimes we kill it.
2010/8/17 Casey Ransberger casey.obrien.r@gmail.com
I have a C app that I'd like to port to Squeak. I had this crazy idea that I wanted to incrementally replace parts of it bit by bit with Smalltalk, and was entertained by how that seemed roughly impossible. The first thought that crossed my mind was to try to bolt some sort of C-based RPC onto it, and use that as a way to get it to talk to Squeak. Then I thought about FFI, but what I'm reading about that talks specifically about libraries.
Here's what I'm wondering:
Would it be insanely painful to make parts of the app into libraries that could get called via FFI? Would it just make more sense to do a scratch implementation? Has anyone ever done something like this before?
It's a crazy idea:)
Casey Ransberger
squeak-dev@lists.squeakfoundation.org
-
Casey Ransberger -
Denis Kudriashov -
Derek O'Connell -
Igor Stasenko