Smalltalk in a C World

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Smalltalk in a C World

askoh
Administrator
http://www.cl.cam.ac.uk/~dc552/papers/SmalltalkInACWorld.pdf

The paper talks about Smalltalk and Objective C coexisting equally in a software development environment. And by virtual of ObjC compatibility with C/C++, the whole C world is open to Smalltalk. Isn't this very exciting? Anyone else noticing this? Can Pragmatic Smalltalk be used to develop a CAD system using the OpenCascade and Visualization Toolkit (VTK) open source libraries?

Can this work help us enter the Apple ecosystem?

All the best,
Aik-Siong Koh
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

kilon.alios
Pharo can already communicate natively with objective C and all its libraries via Nativeboost. An example is Mars on Pharo.


Nativeboost of course can communicate with C and it even offers an inline Assembler so you can go down to bare metal having all the speed and performance you want.
Nativeboost cannot communicate with C++ currently , so it cant use C++ libraries like VTK , however there is a workaround.

It is possible to wrap a C++ to a C DLL (or the equivelant of other OS) , thus indirectly Nativeboost can use even C++ libraries. Here is how -> http://stackoverflow.com/questions/199418/using-c-library-in-c-code

Overall when dealing with C/C++ you have to deal with all sort of technically issues that you don't have in pharo. The problem also becomes even worse because C/C++ libraries usually are not made with simplicity in mind. In the case for example of CAD software with pharo this is of course doable but you will need to have a very deep understanding how 3d graphics works which is a highly technically area by itself. So as you can see there are loads of technically problems to overcome even before worrying about Pharo.

But none the less its doable.   


On Sat, Dec 7, 2013 at 5:24 AM, askoh <[hidden email]> wrote:
http://www.cl.cam.ac.uk/~dc552/papers/SmalltalkInACWorld.pdf

The paper talks about Smalltalk and Objective C coexisting equally in a
software development environment. And by virtual of ObjC compatibility with
C/C++, the whole C world is open to Smalltalk. Isn't this very exciting?
Anyone else noticing this? Can Pragmatic Smalltalk be used to develop a CAD
system using the OpenCascade and Visualization Toolkit (VTK) open source
libraries?

Can this work help us enter the Apple ecosystem?

All the best,
Aik-Siong Koh



--
View this message in context: http://forum.world.st/Smalltalk-in-a-C-World-tp4728217.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

askoh
Administrator
Good that NativeBoost can do what the paper says. How does one debug Pharo and NativeBoost working together? Can one step in Pharo, encounter NativeBoost code, the step in C and return to Pharo?

I would like to create addins for CAD programs (Windows for now). The CAD program starts and calls the addin to be part of the CAD program. User interactions within the CAD are passed to the addin which then drives the data or display in the CAD. The addin is a separate DLL or EXE but the user sees only the CAD with extra capabilities - not as distinct programs. Can Pharo make such an addin?

Thanks,
Aik-Siong Koh
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

kilon.alios
Sort answer is no , Pharo does not try to replace C/C++. CAD plugins are indeed dlls and you will need C/C++ for that. I only Know Free Pascal as another language to generate DLLs but even in that case its extra work. 

So if you look for the most direct solution then Pharo wont cut it and probably most other programming languages.

Theoretically of course its possible , but someone would need to implement this to make it easy to do and currently AFAIK none has. 

Bare in mind that DLLs are strictly a C/C++ invention and definitely not how highly dynamic languages like Pharo work so there is no direct need for Pharo to do such thing cause it would complicate the workflow. For instance you would not want to create a dll for pharo code when you can have an image and live object that offer far more flexibility of code that can modify itself even on runtime. People choose dynamic languages for the very reason that want to avoid such complications and limitations.

If you dont mind workarounds the then answer changes from "no" to "yes".

You could of course create a CAD plugin that triggers pharo and pass information to it through sockets , pipes or other ways of application communication. Its a workaround but it works and I have seen it used in 3d apps. For example in blender that support mainly python addons , I know of a python addon (city generator addon) that uses Java libraries. In this case you create a "bridge" between your CAD application and Pharo and you make the two work together. The good news is that if Pharo crashes , it wont crash your CAD app so that a good thing about this workaround. The bad news is that you would be responsible to expose the CAD functionality to Pharo meaning you will have to create a bridge between pharo and CAD. Of course you will need to expose only the functionality that your plugin uses to Pharo so its not as hard as it may sound. 

 
To paraphrase a favorite quote "good coders invent , great coders cheat " ;)

So yes there definetly many roads that lead to Rome. If you are determined to use Pharo nothing will stop you. 

About debugging nativeboost of course you can use the pharo debugger because nativeboost commands are fully pharo compliant , meaning they are like everything else, messages and objects. For the machine code generated by nativeboost you can use a C debugger like gdb that could let you disassemble the code to see whats wrong with it. Though usually you will just ask here and Igor that is the expert and creator of nativeboost will reply back. He is very helpful and never turns down a question ;) 



On Sun, Dec 8, 2013 at 8:20 PM, askoh <[hidden email]> wrote:
Good that NativeBoost can do what the paper says. How does one debug Pharo
and NativeBoost working together? Can one step in Pharo, encounter
NativeBoost code, the step in C and return to Pharo?

I would like to create addins for CAD programs (Windows for now). The CAD
program starts and calls the addin to be part of the CAD program. User
interactions within the CAD are passed to the addin which then drives the
data or display in the CAD. The addin is a separate DLL or EXE but the user
sees only the CAD with extra capabilities - not as distinct programs. Can
Pharo make such an addin?

Thanks,
Aik-Siong Koh



--
View this message in context: http://forum.world.st/Smalltalk-in-a-C-World-tp4728217p4728573.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Torsten Bergmann
In reply to this post by askoh
Usually plugins for CAD programs have to be running in-process.
Pharo is not (at least not without further work) running in a DLL
as by default it runs as an own OS process.

There once was a plugin for Netscape and one for IE running
Squeak VM as a in-process plugin in the browser - so its technically possible
but not out of the box.

If you want to use Smalltalk for extending CAD programs with
a DLL then you should give "Smalltalk/MT" from ObjectConnect a try
as it is able to build DLL's and OCX/ActiveX components and
already provides the native support (Graphics, Debugging, ...)

Have fun
Torsten

> Gesendet: Sonntag, 08. Dezember 2013 um 19:20 Uhr
> Von: askoh <[hidden email]>
> An: [hidden email]
> Betreff: Re: [Pharo-dev] Smalltalk in a C World
>
> Good that NativeBoost can do what the paper says. How does one debug Pharo
> and NativeBoost working together? Can one step in Pharo, encounter
> NativeBoost code, the step in C and return to Pharo?
>
> I would like to create addins for CAD programs (Windows for now). The CAD
> program starts and calls the addin to be part of the CAD program. User
> interactions within the CAD are passed to the addin which then drives the
> data or display in the CAD. The addin is a separate DLL or EXE but the user
> sees only the CAD with extra capabilities - not as distinct programs. Can
> Pharo make such an addin?
>
> Thanks,
> Aik-Siong Koh
>
>
>
> --
> View this message in context: http://forum.world.st/Smalltalk-in-a-C-World-tp4728217p4728573.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Esteban A. Maringolo
Is Smalltalk/MT still "alive"?
I remember them as the only Smalltalk dialect having in-process COM
servers, whilst Dolphin only had out of process.

I think they also had realtime and threading features no other
Smalltalk, at that time, had.

Regards,
Esteban A. Maringolo


2013/12/8 Torsten Bergmann <[hidden email]>:

> Usually plugins for CAD programs have to be running in-process.
> Pharo is not (at least not without further work) running in a DLL
> as by default it runs as an own OS process.
>
> There once was a plugin for Netscape and one for IE running
> Squeak VM as a in-process plugin in the browser - so its technically possible
> but not out of the box.
>
> If you want to use Smalltalk for extending CAD programs with
> a DLL then you should give "Smalltalk/MT" from ObjectConnect a try
> as it is able to build DLL's and OCX/ActiveX components and
> already provides the native support (Graphics, Debugging, ...)
>
> Have fun
> Torsten
>
>> Gesendet: Sonntag, 08. Dezember 2013 um 19:20 Uhr
>> Von: askoh <[hidden email]>
>> An: [hidden email]
>> Betreff: Re: [Pharo-dev] Smalltalk in a C World
>>
>> Good that NativeBoost can do what the paper says. How does one debug Pharo
>> and NativeBoost working together? Can one step in Pharo, encounter
>> NativeBoost code, the step in C and return to Pharo?
>>
>> I would like to create addins for CAD programs (Windows for now). The CAD
>> program starts and calls the addin to be part of the CAD program. User
>> interactions within the CAD are passed to the addin which then drives the
>> data or display in the CAD. The addin is a separate DLL or EXE but the user
>> sees only the CAD with extra capabilities - not as distinct programs. Can
>> Pharo make such an addin?
>>
>> Thanks,
>> Aik-Siong Koh
>>
>>
>>
>> --
>> View this message in context: http://forum.world.st/Smalltalk-in-a-C-World-tp4728217p4728573.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Torsten Bergmann
> Is Smalltalk/MT still "alive"?

Yes - still alive and kicking. But I'm sure you did not notice since there
are no "big" announcements or advertising for it.
ObjectConnect follows the "time is better invested into technology" strategy.
It is one of the most interesting Smalltalks ever implemented.

The newest ST/MT 6.3 version (now 64 bit) is from end of November 2013

Bye
T.


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Marcus Denker-4

On 08 Dec 2013, at 21:44, Torsten Bergmann <[hidden email]> wrote:

>> Is Smalltalk/MT still "alive"?
>
> Yes - still alive and kicking. But I'm sure you did not notice since there
> are no "big" announcements or advertising for it.

For me this is a nice way of saying “its dead”.

> ObjectConnect follows the "time is better invested into technology" strategy.
> It is one of the most interesting Smalltalks ever implemented.
>
> The newest ST/MT 6.3 version (now 64 bit) is from end of November 2013
>
and nobody thinks that this needs to be announced?

I really do not understand.

        Marcus


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Marcus Denker-4

On 08 Dec 2013, at 21:47, Marcus Denker <[hidden email]> wrote:

>
> On 08 Dec 2013, at 21:44, Torsten Bergmann <[hidden email]> wrote:
>
>>> Is Smalltalk/MT still "alive"?
>>
>> Yes - still alive and kicking. But I'm sure you did not notice since there
>> are no "big" announcements or advertising for it.
>
> For me this is a nice way of saying “its dead”.

I am sure I will not put a link to this at esug.org:
       
        http://www.objectconnect.com

Webrings? I mean seriously: What does this website communicate?
“We are irrelevant and old”.

        Marcus


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Stéphane Ducasse
In reply to this post by Torsten Bergmann

> Yes - still alive and kicking. But I'm sure you did not notice since there
> are no "big" announcements or advertising for it.
> ObjectConnect follows the "time is better invested into technology" strategy.
> It is one of the most interesting Smalltalks ever implemented.

http://www.objectconnect.com/stmt_overview.htm
I like the idea that you can get 50kb applications.
Now since this is a closed system and windows-centric.
But I like that it shows that Smalltalk does not have to be the image centric way.

>
> The newest ST/MT 6.3 version (now 64 bit) is from end of November 2013

Now it is not a community thing. :)
And the web site stop and 5.6 in 2009.

Last time I talk to tarrick he told me that he could control the "no gc in the next 250 frames on PS2"
but it was in 1998 :)


Stef
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Clément Béra
How can people even know Smalltalk MT still exist with their website and their communication ?

I looked at other Smalltalks a while ago, for Smalltalk MT I clicked on "what's new" on their website and I got that:

Images intégrées 1

Then I thought this Smalltalk was dead (nothing new in the past 4 years) and I didn't look any further.


2013/12/8 Stéphane Ducasse <[hidden email]>

> Yes - still alive and kicking. But I'm sure you did not notice since there
> are no "big" announcements or advertising for it.
> ObjectConnect follows the "time is better invested into technology" strategy.
> It is one of the most interesting Smalltalks ever implemented.

http://www.objectconnect.com/stmt_overview.htm
I like the idea that you can get 50kb applications.
Now since this is a closed system and windows-centric.
But I like that it shows that Smalltalk does not have to be the image centric way.

>
> The newest ST/MT 6.3 version (now 64 bit) is from end of November 2013

Now it is not a community thing. :)
And the web site stop and 5.6 in 2009.

Last time I talk to tarrick he told me that he could control the "no gc in the next 250 frames on PS2"
but it was in 1998 :)


Stef

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Stéphane Ducasse
You should think that they use their smalltalk for their projects.

Stef

On Dec 9, 2013, at 9:21 AM, Clément Bera <[hidden email]> wrote:

How can people even know Smalltalk MT still exist with their website and their communication ?

I looked at other Smalltalks a while ago, for Smalltalk MT I clicked on "what's new" on their website and I got that:

<Screen Shot 2013-12-09 at 9.18.11 AM.png>

Then I thought this Smalltalk was dead (nothing new in the past 4 years) and I didn't look any further.


2013/12/8 Stéphane Ducasse <[hidden email]>

> Yes - still alive and kicking. But I'm sure you did not notice since there
> are no "big" announcements or advertising for it.
> ObjectConnect follows the "time is better invested into technology" strategy.
> It is one of the most interesting Smalltalks ever implemented.

http://www.objectconnect.com/stmt_overview.htm
I like the idea that you can get 50kb applications.
Now since this is a closed system and windows-centric.
But I like that it shows that Smalltalk does not have to be the image centric way.

>
> The newest ST/MT 6.3 version (now 64 bit) is from end of November 2013

Now it is not a community thing. :)
And the web site stop and 5.6 in 2009.

Last time I talk to tarrick he told me that he could control the "no gc in the next 250 frames on PS2"
but it was in 1998 :)


Stef


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

kilon.alios
please note that generating dlls alone wont be enough , plugins are compiled against a runtime or specific libraries (a Plugin SDK) and Smalltalk MT would have to be able to do that in order to be a viable solution.   


On Mon, Dec 9, 2013 at 10:28 AM, Stéphane Ducasse <[hidden email]> wrote:
You should think that they use their smalltalk for their projects.

Stef

On Dec 9, 2013, at 9:21 AM, Clément Bera <[hidden email]> wrote:

How can people even know Smalltalk MT still exist with their website and their communication ?

I looked at other Smalltalks a while ago, for Smalltalk MT I clicked on "what's new" on their website and I got that:

<Screen Shot 2013-12-09 at 9.18.11 AM.png>

Then I thought this Smalltalk was dead (nothing new in the past 4 years) and I didn't look any further.


2013/12/8 Stéphane Ducasse <[hidden email]>

> Yes - still alive and kicking. But I'm sure you did not notice since there
> are no "big" announcements or advertising for it.
> ObjectConnect follows the "time is better invested into technology" strategy.
> It is one of the most interesting Smalltalks ever implemented.

http://www.objectconnect.com/stmt_overview.htm
I like the idea that you can get 50kb applications.
Now since this is a closed system and windows-centric.
But I like that it shows that Smalltalk does not have to be the image centric way.

>
> The newest ST/MT 6.3 version (now 64 bit) is from end of November 2013

Now it is not a community thing. :)
And the web site stop and 5.6 in 2009.

Last time I talk to tarrick he told me that he could control the "no gc in the next 250 frames on PS2"
but it was in 1998 :)


Stef



Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

philippeback
The main issue is that it is complicated to embed the VM in C code.
That's due to how the VM is done.

Compared to TCL, where you can easily embed the interpreter in a C program, this is a problem. http://wiki.tcl.tk/3474

Where you can embed the interpreter in a C program, you can do whatever integration you want.

Now, with NativeBoost, we can call C. The next challenge would be to be able to call Pharo from C by embedding the interpreter.

I am curious to  see what you guys think about this.

I would love to see things like mod_pharo (as there is mod_php, mod_perl, mod_tcl...) in Apache.





---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/
Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 



On Mon, Dec 9, 2013 at 9:48 AM, kilon alios <[hidden email]> wrote:
please note that generating dlls alone wont be enough , plugins are compiled against a runtime or specific libraries (a Plugin SDK) and Smalltalk MT would have to be able to do that in order to be a viable solution.   


On Mon, Dec 9, 2013 at 10:28 AM, Stéphane Ducasse <[hidden email]> wrote:
You should think that they use their smalltalk for their projects.

Stef

On Dec 9, 2013, at 9:21 AM, Clément Bera <[hidden email]> wrote:

How can people even know Smalltalk MT still exist with their website and their communication ?

I looked at other Smalltalks a while ago, for Smalltalk MT I clicked on "what's new" on their website and I got that:

<Screen Shot 2013-12-09 at 9.18.11 AM.png>

Then I thought this Smalltalk was dead (nothing new in the past 4 years) and I didn't look any further.


2013/12/8 Stéphane Ducasse <[hidden email]>

> Yes - still alive and kicking. But I'm sure you did not notice since there
> are no "big" announcements or advertising for it.
> ObjectConnect follows the "time is better invested into technology" strategy.
> It is one of the most interesting Smalltalks ever implemented.

http://www.objectconnect.com/stmt_overview.htm
I like the idea that you can get 50kb applications.
Now since this is a closed system and windows-centric.
But I like that it shows that Smalltalk does not have to be the image centric way.

>
> The newest ST/MT 6.3 version (now 64 bit) is from end of November 2013

Now it is not a community thing. :)
And the web site stop and 5.6 in 2009.

Last time I talk to tarrick he told me that he could control the "no gc in the next 250 frames on PS2"
but it was in 1998 :)


Stef




Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

FDominicus
In reply to this post by kilon.alios
kilon alios <[hidden email]> writes:

> Sort answer is no , Pharo does not try to replace C/C++. CAD plugins
> are indeed dlls and you will need C/C++ for that. I only Know Free
> Pascal as another language to generate DLLs but even in that case its
> extra work.
>
> So if you look for the most direct solution then Pharo wont cut it and
> probably most other programming languages.
>
> Theoretically of course its possible , but someone would need to
> implement this to make it easy to do and currently AFAIK none has.
>
> Bare in mind that DLLs are strictly a C/C++ invention and definitely
> not how highly dynamic languages like Pharo work so there is no direct
> need for Pharo to do such thing cause it would complicate the
> workflow.
I don't this is entirely true. AFAIKT Except Smalltalk can be used for
generateing DLLs. However they are "compiling" to C AFAIKT. I'm quite
sure that one can use ObjectArts Smalltalk also to generate niche Active
X and I bet also shared libraries.

Regards
Friedrich



Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Torsten Bergmann
In reply to this post by kilon.alios
Kilon wrote:
>dlls alone wont be enough , plugins are compiled against a runtime or specific libraries (a Plugin SDK) and Smalltalk MT
>would have to be able to do that in order to be a viable solution. 

You can be sure it can :)

Clement wrote:
>How can people even know Smalltalk MT still exist with their website and
>their communication ?

If you follow the hype and advertising you go to Java - if you search
for something more powerful you search for it and will find Smalltalk.

Same for ST/MT - if you need something more specific (like building DLLs, COM
components, access DirectX/OpenGL, ... and stay with Smalltalk you may
end up at their system.
 
I know several projects using MT, it is also used for games (like Aura - Fate of the Ages).

Note that also other Smalltalks are able to build DLLs like Dolphin, ST/X and SmallScript.

Bye
T.

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

kilon.alios
In reply to this post by FDominicus
this is why i said " Theoretically of course its possible , but someone would need to  implement this to make it easy to do and currently AFAIK none has.". 

Please note I was talking about Pharo.

Even if you take into account Slang , pharo is not compiling to C, it has actually a completely different ideology to C.  C/C++ does what it does because it favors raw performance, Pharo does what it does because its favors ease of use , simplicity and flexibility. So its definitely doable technically but the questions is "do you REALLY want to do this". The sort answer NO with the exceptions depending on the situation. Because you don't want to further complicate your life. 

On the issue of embedding I think its a good option to have but something I rather avoid. If you want to know why , then read this very well written article for python http://twistedmatrix.com/users/glyph/rant/extendit.html. To sum up extending is just better than embedding because it allow you to put focus on your language of choice and take full advantage of its merits. 

Blender the 3d app , written in C/C++ , embeds python for its addon architecture. Python makes the addons and also manages the GUI. I can tell you there are clear advantages to have blender as  python library instead of embedding python inside blender. It would offer a lot easier customization of blender. But since all developers  of Blender are C/C++ developers , embedding seemed like an "obvious" solution to them. Mostly because they saw python as a third class citizent in their app. But with blender addons popping up like mushrooms , python has played such a central role to Blender that now it compromises 12% of the 1 million lines of code , blender's code base. 12% might not seem much but once you figure out that python is generally 2-5 times less verbose than C/C++ it become a huge number.

Take also to account the world in general move towards dynamic languages mainly because they make life easier and more manageable. For me its far more important to improve Nativeboost and create high quality documentation  for it even before considering embedding pharo. 


On Mon, Dec 9, 2013 at 12:09 PM, Friedrich Dominicus <[hidden email]> wrote:
kilon alios <[hidden email]> writes:

> Sort answer is no , Pharo does not try to replace C/C++. CAD plugins
> are indeed dlls and you will need C/C++ for that. I only Know Free
> Pascal as another language to generate DLLs but even in that case its
> extra work.
>
> So if you look for the most direct solution then Pharo wont cut it and
> probably most other programming languages.
>
> Theoretically of course its possible , but someone would need to
> implement this to make it easy to do and currently AFAIK none has.
>
> Bare in mind that DLLs are strictly a C/C++ invention and definitely
> not how highly dynamic languages like Pharo work so there is no direct
> need for Pharo to do such thing cause it would complicate the
> workflow.
I don't this is entirely true. AFAIKT Except Smalltalk can be used for
generateing DLLs. However they are "compiling" to C AFAIKT. I'm quite
sure that one can use ObjectArts Smalltalk also to generate niche Active
X and I bet also shared libraries.

Regards
Friedrich




Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Marcus Denker-4
In reply to this post by Torsten Bergmann

On 09 Dec 2013, at 11:37, Torsten Bergmann <[hidden email]> wrote:

> Kilon wrote:
>> dlls alone wont be enough , plugins are compiled against a runtime or specific libraries (a Plugin SDK) and Smalltalk MT
>> would have to be able to do that in order to be a viable solution.
>
> You can be sure it can :)
>
> Clement wrote:
>> How can people even know Smalltalk MT still exist with their website and
>> their communication ?
>
> If you follow the hype and advertising you go to Java - if you search
> for something more powerful you search for it and will find Smalltalk.
>
You search and you find a website that convinces you that Smalltalk it indeed
dead.

        Marcus


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Esteban A. Maringolo
2013/12/9 Marcus Denker <[hidden email]>:
>> Clement wrote:
>>> How can people even know Smalltalk MT still exist with their website and
>>> their communication ?
>>
>> If you follow the hype and advertising you go to Java - if you search
>> for something more powerful you search for it and will find Smalltalk.

> You search and you find a website that convinces you that Smalltalk it indeed
> dead.

+1

I'd prefer ObjectConnect shutdown their website rather than having that.
And, at certain degree the same applies to my beloved ObjectArts and
its Dolphin masterpiece.

Regards,

ps: Java is no Hype. You might like the language or not, but it has
established throughout the last decade, and is the language/platform
that runs on almost all devices. Only C can beat that.

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk in a C World

Ben Coman
In reply to this post by kilon.alios
kilon alios wrote:
Sort answer is no , Pharo does not try to replace C/C++. CAD plugins are indeed dlls and you will need C/C++ for that. I only Know Free Pascal as another language to generate DLLs but even in that case its extra work. 

So if you look for the most direct solution then Pharo wont cut it and probably most other programming languages.

Theoretically of course its possible , but someone would need to implement this to make it easy to do and currently AFAIK none has. 

Bare in mind that DLLs are strictly a C/C++ invention and definitely not how highly dynamic languages like Pharo work so there is no direct need for Pharo to do such thing cause it would complicate the workflow. For instance you would not want to create a dll for pharo code when you can have an image and live object that offer far more flexibility of code that can modify itself even on runtime. People choose dynamic languages for the very reason that want to avoid such complications and limitations.

If you dont mind workarounds the then answer changes from "no" to "yes".

You could of course create a CAD plugin that triggers pharo and pass information to it through sockets , pipes or other ways of application communication. Its a workaround but it works and I have seen it used in 3d apps. For example in blender that support mainly python addons , I know of a python addon (city generator addon) that uses Java libraries. In this case you create a "bridge" between your CAD application and Pharo and you make the two work together. The good news is that if Pharo crashes , it wont crash your CAD app so that a good thing about this workaround. The bad news is that you would be responsible to expose the CAD functionality to Pharo meaning you will have to create a bridge between pharo and CAD. Of course you will need to expose only the functionality that your plugin uses to Pharo so its not as hard as it may sound. 

 
To paraphrase a favorite quote "good coders invent , great coders cheat " ;)

So yes there definetly many roads that lead to Rome. If you are determined to use Pharo nothing will stop you. 

About debugging nativeboost of course you can use the pharo debugger because nativeboost commands are fully pharo compliant , meaning they are like everything else, messages and objects. For the machine code generated by nativeboost you can use a C debugger like gdb that could let you disassemble the code to see whats wrong with it.
I guess that "Native Debugger" [1] project proposed for Google Summer of Code would have potential for seamless debugging through NativeBoost and C library.

[1] http://gsoc2013.esug.org/projects/native-code-debugger

cheers -ben

Though usually you will just ask here and Igor that is the expert and creator of nativeboost will reply back. He is very helpful and never turns down a question ;) 



On Sun, Dec 8, 2013 at 8:20 PM, askoh <[hidden email]> wrote:
Good that NativeBoost can do what the paper says. How does one debug Pharo
and NativeBoost working together? Can one step in Pharo, encounter
NativeBoost code, the step in C and return to Pharo?

I would like to create addins for CAD programs (Windows for now). The CAD
program starts and calls the addin to be part of the CAD program. User
interactions within the CAD are passed to the addin which then drives the
data or display in the CAD. The addin is a separate DLL or EXE but the user
sees only the CAD with extra capabilities - not as distinct programs. Can
Pharo make such an addin?

Thanks,
Aik-Siong Koh



--
View this message in context: http://forum.world.st/Smalltalk-in-a-C-World-tp4728217p4728573.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



12