[Vm-dev] NativeBoost installation woes with Mac OS X

[Nicolas Cellier]

2011/10/2 Igor Stasenko <siguctua at gmail.com>:
>
> On 2 October 2011 19:35, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>> 2011/10/1 Igor Stasenko <siguctua at gmail.com>:
>>>
>>> On 1 October 2011 02:24, Henrik Sperre Johansen
>>> <henrik.s.johansen at veloxit.no> wrote:
>>>>
>>>> On 30.09.2011 18:20, Igor Stasenko wrote:
>>>>>
>>>>> On 30 September 2011 18:11, David T. Lewis<lewis at mail.msen.com>  wrote:
>>>>>>
>>>>>> On Fri, Sep 30, 2011 at 04:36:43PM +0200, Igor Stasenko wrote:
>>>>>>>
>>>>>>> On 30 September 2011 11:42, Lawson English<lenglish5 at cox.net>  wrote:
>>>>>>>>
>>>>>>>> Hi. On an Intel Mac running Mac OS X 10.6.8, I followed the
>>>>>>>> instructions to
>>>>>>>> install a NativeBoost VM found here:
>>>>>>>> http://code.google.com/p/nativeboost/wiki/Installation. I downloaded
>>>>>>>> the
>>>>>>>> latest Mac NBCog VM, ??and ran into an error after evaluating
>>>>>>>> NBInstaller
>>>>>>>> install.
>>>>>>>>
>>>>>>>> I'm using the 4.3alpha-11636.image file. The 4.2 image gives a
>>>>>>>> different set
>>>>>>>> of errors but also wont install:
>>>>>>>>
>>>>>>>> The progress bar window says: Compiling
>>>>>>>> NativeBoost-Core-IgorStasenko.36
>>>>>>>>
>>>>>>>>
>>>>>>>> The window title is "Syntax error" with a split text field. The top
>>>>>>>> field
>>>>>>>> contains:
>>>>>>>> nbExternalStructure Fields parsing spec parseFields:byte
>>>>>>>>
>>>>>>>>
>>>>>>>> The bottom field has a red error message embedded in this line:
>>>>>>>>
>>>>>>>> ?? ?? ?? ??stream peek == #Invalid literal character ->; ifTrue: [
>>>>>>>> stream next
>>>>>>>> ].
>>>>>>>> ?? ??].
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Help?
>>>>>>>>
>>>>>>> I didn't tested an installation in squeak 4.2 images.
>>>>>>> It looks like there is a change in parser which don't likes the
>>>>>>> following syntax:
>>>>>>>
>>>>>>> #( a; b ; c)
>>>>>>>
>>>>>>>
>>>>>>> imo, this is correct syntax. a ';' should be converted to #; symbol.
>>>>>>>
>>>>>> Squeak 3.6:
>>>>>> #( a; b ; c) ==>  #(#a #; #b #; #c)
>>>>>>
>>>>>> Squeak 3.8:
>>>>>> #( a; b ; c) ==>  #(#a #; #b #; #c)
>>>>>>
>>>>>> Squeak trunk:
>>>>>> #( a; b ; c) ==>  #(#a #';' #b #';' #c)
>>>>>>
>>>>>> PharoCore-1.3-13173:
>>>>>> #( a; b ; c) ==>  #(#a #';' #b #';' #c)
>>>>>>
>>>>>> Dave
>>>>>>
>>>>> ok, then problem is in something else.
>>>>> Lawson, could you please paste the full method source with problematic
>>>>> code?
>>>>>
>>>>
>>>> #; inspect -> Syntax error though...
>>>>
>>>> ps.
>>>> stream peek == #;
>>>>
>>>> sure it's not a typo and should be
>>>> stream peek == $;  ?
>>>>
>>> yes its not a typo. Since it is a stream from given array:
>>>
>>> #( a ; b ; c ; ) readStream
>>>
>>> stream peek at some moment could answer #; symbol.
>>>
>>> perhaps i should write it like #';' ?
>>> but why it considered invalid?
>>>
>>
>> Ah, all these behaviours were removed from Squeak
>> #; -> #';'
>> #1 -> 1
>> #$1 -> $1
>> The rationale was:
>> 1) These were not defined in st80, nor in any formal Smalltalk syntax.
>> # was only for literal symbols or literal arrays.
>> 2) #';' 1 and $1 already are literals, so we don't need any other
>> syntax or additional decoration.
>> 3) This is not portable, no other dialect would accept it.
>> 4) And there were plenty of oddities with doubled # or spaces inserted
>> in between...
>>
>> Now, Igor you seem to suggest that these extensions would be logical
>> given how the inside of literal array is interpreted, is that it?
>>
>
> No, i'm not suggesting that. :)
>
> But as you noted, i agree that if array literals treating ';' inside
> as a #; literal, then it would be more consistent to allow #; syntax
> as well.
>

I see. Some kind of least surprise principle...
But adding this syntax would immediately displace the problem one
character further...
...and I'm not very sure how universal would the interpretation of
multi non character symbols be:
#(+/|!?&%,;;<>_.:=--^:*)
->
 #(#+/ #| #!?&%, #';' #';' #<> #'_' #'.' #':=' #-- #'^' #':' #*)

The delimitation seems arbitrary and hard to explain...
how | is distinguished from other binary selectors...
how := is handled specially ...
To me, it's better to leave those behaviour as unspecified and reserve
the right to perform additional cleanup later


> Anyways, it is easy to change the method to be correct even for more
> strict syntax rules.
>

Sure

>
> --
> Best regards,
> Igor Stasenko.
>