Hi Phil,

Sorry for the delay in answering. (more below...)

Phil (list) wrote:
> Juan,
>
> On Apr 8, 2010, at 7:57 AM, Juan Vuletich wrote:
>
>> Hi Phil,
>>
>> Phil (list) wrote:
>>> Juan,
>>>
>>> I've finally made some time to attempt to migrate from Cuis 2.0->2.3 
>>> (yeah, I missed a couple of releases :-) and have run into some 
>>> issues.  The main one that jumped out at me is when I filed out my 
>>> changesets from the 2.0 image and then back in to 2.3: in many 
>>> places (strangely, not all), underscore assignment is being used 
>>> when *all* of my code in 2.0 used := (and when I view the code 
>>> before installing the changeset, it indicates that := was used on 
>>> the fileout)... so this is either a regression (I didn't have this 
>>> problem loading into 2.0) or a feature.  If it's a feature, can it 
>>> be disabled? #allowUnderscoreAssignment is true in both versions and 
>>> is the only pref I saw that seemed possibly related but since there 
>>> was no difference in the setting, I didn't expect any difference in 
>>> behavior.
>>
>> I apologize. Just turn off the 
>> #syntaxHighlightingAsYouTypeLeftArrowAssignment preference. It should 
>> be off by default, and will be so in next releases. BTW, next release 
>> of Cuis will include "configurable underscore meaning" as Andreas did 
>> recently for trunk, and you can always do 'StrikeFont useUnderscore', 
>> meaning that Cuis will fully support the use of _ as part of 
>> selectors or identifiers.
>
> Thanks, that took care of the problem and good to know re: future 
> releases.
>
>>> The other things I've run into so far are problems with what appears 
>>> to be an incomplete changeset being generated by 2.0 (specifically 
>>> with a class that I had renamed) and a hard crash problem (i.e. the 
>>> image literally just quits/crashes with no error) related to 
>>> OpenGL/FFI that I wasn't having in 2.0.  These two are more FYI at 
>>> this stage (and if either of these problems sounds familiar, by all 
>>> means please let me know) as I still have some investigating to do 
>>> to see if there is something on my end that is the cause of these 
>>> problems or if it's something I can figure out a fix for and provide 
>>> to you.
>>
>> This was already answered by Andreas. Thanks Andreas!
>
> 1/2 of it was... still having a problem with the incomplete changeset 
> but I'm able to work around it until I figure out what the issue is.  
> Not a big deal, just something I ran into (possibly a changeset 
> limitation, I just don't know yet.)
>
>>
>>> Now that I've finally gotten just about all of my stuff migrated to 
>>> Cuis, I'm going to use this migration as an opportunity to clean my 
>>> code up a little (OK, a lot :-) so that hopefully I won't fall so 
>>> far behind future releases and can provide more timely feedback 
>>> going forward.
>>
>> Great!
>>
>>> One additional item I would like to get your thoughts on is whether 
>>> or not you think that maintaining compliance with the ANSI Smalltalk 
>>> spec (or some other standard) where possible (i.e. it's a capability 
>>> that is included in Cuis) is a worthwhile goal?  This seems like it 
>>> might be helpful in trying to remain at least minimally compatible 
>>> with packages not specifically developed for Cuis.
>>>
>>> Thanks,
>>> Phil
>>
>> I'm not a big fan of ANSI Smalltalk, but I agree that some 
>> compatibility with Squeak and Pharo (and perhaps other Smalltalks) is 
>> a good thing. What I really like is Grease, as it can be tested for 
>> compliance. If anybody wants to work on Grease for Cuis, I'll be 
>> happy to help and to consider that work an "officially supported 
>> optional package" ((c) Andreas), meaning that I'd run all the test 
>> before any release, and integrate or write any needed fixes, to 
>> ensure it works ok. Aside from that, feel free to raise any 
>> compatibility issues that bite you. We might integrate the fix in 
>> Cuis, or in an "officially supported optional package". The fact is 
>> that I already have some stuff for starting such packages.
>>
>> Does this sound ok for you?
>>
>
> That works for me... I don't have any personal preference and was just 
> throwing out ANSI as that was one of the options I was aware of.  I'll 
> take a look into Grease since that seems to be an option that seems to 
> be working for far larger efforts than mine.  I'm still sorting 
> through my changes but in case anyone is interested in some of the 
> things that work: right now I'm successfully using FFI, OpenGL 
> (positional arguments worked as well but I got rid of them), 
> 3DTransform, Smallapack, Curl, Ometa2 and XML-Parser/XPath with only 
> minor changes needed and no show-stopping issues so far.  Aside from a 
> dozen or so missing methods and assumptions re: 'SmalltalkImage 
> current' that needed to be fixed to load the code, things have been 
> working just as reliably as they do in Squeak and Pharo.    Granted, 
> most of the external code I'm using doesn't have complex dependencies 
> on other packages, but the things I've needed are working and it's 
> been a very pleasant experience so far.

All this is great to know. Thank you.

>
>> Cheers,
>> Juan Vuletich
>>
>
> Thanks,
> Phil 


Cheers,
Juan Vuletich