On 20 August 2012 20:42, Chris Cunnington <smalltalktelevision at gmail.com> wrote:
> On 12-08-20 1:52 PM, Igor Stasenko wrote:
>>
>> On 20 August 2012 04:10, Chris Cunnington <smalltalktelevision at gmail.com>
>> wrote:
>>>
>>> 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)
>>
>> Just today i spent couple of hours to make the NB-Help package work
>> out of the box.
>> You can find the NativeBoost-Help package in NativeBoost repository..
>> i wrote some stuff there but it is not that much..(and some stuff is
>> already outdated.. things moving fast) however i will keep pumping
>> into it. :)
>>
>> All you need to do is to load this package , and then open the system
>> help browser (from world menu) and look for
>> NativeBoost bookmark.
>
> Thanks. This stuff looks great. I'll watch for updates to the Help package.
> The Help Browser is a nice way to learn things, as it's bite sized, right
> there in the image, etc. I've got a NativeBoost.app on my desktop now and
> will poke around with it. I do see there is some stuff at the
> http://code.gogoel.com/p/nativeboost location. The Help Browser is a more
> fun place for it to be, I think.
>
Yeah, we spent some effort to make markdown syntax & styler working, so now
NB Help if one of those who using that..
i like the links to classes/methods, which ia clickable, so it is not
a dry text but actually
can point to real places in code which people can see 1 click away :)


> Chris
>
> http://www.youtube.com/watch?v=aFj8eFZx-TA&feature=related
>
>>
>>> 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
>>>
>>>
>>>
>>
>>
>
>



-- 
Best regards,
Igor Stasenko.