[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squeak-vm-dev
Subject:    Re: [Vm-dev] urgent info required on Slang's shift treatment...
From:       Andreas Raab <andreas.raab () gmx ! de>
Date:       2009-03-03 22:09:13
Message-ID: 49ADAA89.6030801 () gmx ! de
[Download RAW message or body]

 
Oops. This was *not* meant to go to the list. My sincerest apologies.

   - Andreas

Andreas Raab wrote:
> 
> Eliot Miranda wrote:
>> On Tue, Mar 3, 2009 at 1:20 PM, Andreas Raab <andreas.raab@gmx.de 
>> <mailto:andreas.raab@gmx.de>> wrote:
>>
>>
>>     Don't even think about it.
>>
>>
>> Too late.  I'm testing my workaround,  Give us a reason or two and I 
>> might recant :)
> 
> You are creating more instability and risk. We want to ship this thing 
> in a couple of weeks. Introducing subtle bugs like these are most 
> definitely not the path to stabilizing this VM.
> 
> Cheers,
>   - Andreas
> 
>>  
>>
>>     Cheers,
>>      - Andreas
>>
>>     Eliot Miranda wrote:
>>
>>         
>>         
>> ------------------------------------------------------------------------
>>
>>
>>         Hi All,
>>
>>            I'm being bitten by Slang's treatment of bitShift: & >>.  In
>>         both cases (generateBitShift:on:indent: &
>>         generateShiftRight:on:indent:) Slang generates an unsigned shift
>>         by explicitly casting the shifted expression to usqInt.  I can
>>         understand the benefit of having an unsigned shift.  But there
>>         are times when one really needs a signed shift.  Further, the
>>         Smalltalk versions of both bitShift: and >> are signed shifts.
>>
>>         Dare I change e.g. generateShiftRight:on:indent: to leave the
>>         expression alone and generate either a signed or an unsigned
>>         shift based on the variable's declaration?  Or must I live with
>>         a maddening cCode: '(signed)' inSmalltalk: [] carbuncle?
>>
>>         E.
>>
>>
> 
[prev in list] [next in list] [prev in thread] [next in thread]