[squeak-dev] [Ann] [Cuis] Cuis 2.3 released
Juan Vuletich
juan at jvuletich.org
Wed Apr 14 16:47:48 UTC 2010
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
More information about the Squeak-dev
mailing list
|