On 12-08-19 9:42 PM, Igor Stasenko wrote:
> On 20 August 2012 00:53, Chris Cunnington <smalltalktelevision at gmail.com> wrote:
>> On 12-08-19 6:26 PM, Igor Stasenko wrote:
>>> On 17 August 2012 22:21, Yanni Chiu <yanni at rogers.com> wrote:
>>>> On 17/08/12 2:46 PM, Lawson English wrote:
>>>>>
>>>>> Which is a huge downside to the current implementation of NativeBoost,
>>>>> although, in theory, you could create a version that would compile to C
>>>>> via slang rather than using Igor's x86 assembler syntax.
>>>>
>>>> But it's called *Native*Boost. Are you suggesting non-native boost?
>>>> Wouldn't
>>>> that be Cog/JIT?
>>>>
>>> Right. It is native. You can talk directly to metal. No layers on
>>> top.. you are the in total control.
>>> This is the main motivation behind a project.
>>> You can build abstractions on top of it, of course. And of course you
>>> can make it portable across
>>> as many platforms as you need.. It may be hard but it is doable.
>>> But conceptually one thing are not gonna change: you have direct
>>> access to machine code,
>>> which means no compiler standing in your way, which generating
>>> suboptimal code :)
>>> And for some cases it is simply impossible to implement things in C
>>> without heavy sacrifices in speed..
>>> consider arithmetic overflow - in CPU's you have a flag which indicates
>>> that..
>>> but in C there is no way how you can access it.. so you cannot just write:
>>>
>>> int a, b;
>>> if ( (result = a +b) > maxInt )
>>> {
>>>    .. switch to big integer arithmetic ..
>>> }
>>>
>>> and i guess you can find many other cases where direct machine code is
>>> more preferable than produced by compiler(s).
>>>
>>>
>> In the last few posts you just wrote as many words arguing for NativeBoost
>> as David did explaining how to get started writing a plugin. Except when he
>> was done a person could actually start to write a plugin. If you and Lawson
>> spent as much time providing examples for NativeBoost as you do extolling
>> its virtues, I could actually try it for myself.
>>
> Chris, its unfair.
Thank you. Thank you very much. :)
> First, David only gave instructions how to set things up,
> but not how to actually start writing a plugin.. if he would do that,
> his post will be extended to dozens of pages :)
Yea, but it's a start. I mean he's got to start talking about 
subclassing from InterpreterPlugin? He covers a lot of ground for a 
beginning.
> And second, if i remember, you were present at my presentation i
> giving about NB,
> so i really surprised to hear that from you.
Hmmmm... this one http://osrcon.ca/AboutFFI.pdf ?

Yea, OK, you have a point. But in my defense DeepIntoSmalltalk was ... 
let's just say there was a lot of material.
> But you right, i am not good at writing docs, because i am way too
> lazy, and there's always more important things to do (well you know
> ;). But i am working on fixing that. :)
I seem to recall Lawson makes movies.
>
> And for getting starting with NB you can just follow installation
> instructions from here:
> http://code.google.com/p/nativeboost/wiki/Installation
>
> and if you need some examples of use, just recently i found this project:
> http://www.squeaksource.com/ICU
That looks interesting.
> which interesting in respect that it using two different FFI implementations,
> so you can load both and browse code and compare the way how things done.
> I am not sure in what state this project are, but since you don't need
> to actually "run" things, you can just
> browse the code to see how it done.
>
But "I would like to know more" about NativeBoost. (As long as I don't 
have to work too hard to know it. :p)

http://www.youtube.com/watch?feature=endscreen&v=l_5UZfwX0ss&NR=1

(That's an inside joke to people who were at DeepIntoSmalltalk. Igor's 
slides showed him to be a big fan of Starship Troopers and Firefly.)
>> Chris