[Pharo-dev] Smalltalk in a C World

kilon alios kilon.alios at gmail.com
Mon Dec 9 14:48:30 EST 2013


very interesting I wonder whether is pharo related or how easily can be
ported to Pharo.

The funny thing about nativeboost is that because it has its own inline
assembler it is possible to use nativeboost to debug the machine code
generated by nativeboost or to be more precise AsmJit. Of course thats a
manual way of doing this and less ideal than using a dedicated debugging
tool but its definitely an interesting concept. I am also wondering and
imagining things about Shared memory concept , where 2 apps can shared the
same memory addresses and so share data and wonder how nativeboost could
help there since it offer complete access to memory. But of course that are
low level concept I am not familiar at all, but I would not mind messing
with them at least once. It could even eliminate the need to embed pharo
inside a C app.

Definetly loads of ideas to explore here if one is willing to invest the
time.


On Mon, Dec 9, 2013 at 5:40 PM, <btc at openinworld.com> wrote:

>  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 <askoh at askoh.com> 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.
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131209/414db464/attachment-0002.html>


More information about the Pharo-dev mailing list