[Ann] [Cuis] Cuis 2.3 released

> Hi Folks,
>
> Cuis 2.2 is out, as usual, at www.jvuletich.org/Cuis/Index.html. From the
> release notes:
>
> Main new in Cuis 2.3
>
>   * Fixes for internalized sources
>   * Decompiler fixes by nice
>   * Various code cosmetics fixes
>   * Enhancements to prettyPrint by cmm
>   * A fix to WeakRegistry by ul
>   * Added BitBltTests to allow knowing if the VM is updated
>   * A serious simplification of Morphic geometry, removing DisplayTransform
>   * InteractiveErrorCorrection fixes by cao and jmv
>   * Lots of minor fixes
>
> A big news, at least for me, is that I added a "Donate" button. So, you have
> a new way to help me keep developing Cuis.
>
> Cheers,
> Juan Vuletich
>
>

> Hi Folks,
>
> Cuis 2.2 is out, as usual, at www.jvuletich.org/Cuis/Index.html.  
> From the release notes:
>
> Main new in Cuis 2.3
>
>   * Fixes for internalized sources
>   * Decompiler fixes by nice
>   * Various code cosmetics fixes
>   * Enhancements to prettyPrint by cmm
>   * A fix to WeakRegistry by ul
>   * Added BitBltTests to allow knowing if the VM is updated
>   * A serious simplification of Morphic geometry, removing  
> DisplayTransform
>   * InteractiveErrorCorrection fixes by cao and jmv
>   * Lots of minor fixes
>
> A big news, at least for me, is that I added a "Donate" button. So,  
> you have a new way to help me keep developing Cuis.
>
> Cheers,
> Juan Vuletich
>

> On Mar 22, 2010, at 2:48 PM, Juan Vuletich wrote:
>
>> Hi Folks,
>>
>> Cuis 2.2 is out, as usual, at www.jvuletich.org/Cuis/Index.html. From
>> the release notes:
>>
>> Main new in Cuis 2.3
>>
>>   * Fixes for internalized sources
>>   * Decompiler fixes by nice
>>   * Various code cosmetics fixes
>>   * Enhancements to prettyPrint by cmm
>>   * A fix to WeakRegistry by ul
>>   * Added BitBltTests to allow knowing if the VM is updated
>>   * A serious simplification of Morphic geometry, removing
>> DisplayTransform
>>   * InteractiveErrorCorrection fixes by cao and jmv
>>   * Lots of minor fixes
>>
>> A big news, at least for me, is that I added a "Donate" button. So,
>> you have a new way to help me keep developing Cuis.
>>
>> Cheers,
>> Juan Vuletich
>>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.791 / Virus Database: 271.1.1/2765 - Release Date: 03/23/10 04:33:00
>
>  

> Hi Folks,
>
> Cuis 2.2 is out, as usual, at www.jvuletich.org/Cuis/Index.html.  
> From the release notes:
>
> Main new in Cuis 2.3
>
>   * Fixes for internalized sources
>   * Decompiler fixes by nice
>   * Various code cosmetics fixes
>   * Enhancements to prettyPrint by cmm
>   * A fix to WeakRegistry by ul
>   * Added BitBltTests to allow knowing if the VM is updated
>   * A serious simplification of Morphic geometry, removing  
> DisplayTransform
>   * InteractiveErrorCorrection fixes by cao and jmv
>   * Lots of minor fixes
>
> A big news, at least for me, is that I added a "Donate" button. So,  
> you have a new way to help me keep developing Cuis.
>
> Cheers,
> Juan Vuletich
>

> 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.
>
> 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
>
> On Mar 22, 2010, at 2:48 PM, Juan Vuletich wrote:
>
>> Hi Folks,
>>
>> Cuis 2.2 is out, as usual, at www.jvuletich.org/Cuis/Index.html. From
>> the release notes:
>>
>> Main new in Cuis 2.3
>>
>> * Fixes for internalized sources
>> * Decompiler fixes by nice
>> * Various code cosmetics fixes
>> * Enhancements to prettyPrint by cmm
>> * A fix to WeakRegistry by ul
>> * Added BitBltTests to allow knowing if the VM is updated
>> * A serious simplification of Morphic geometry, removing DisplayTransform
>> * InteractiveErrorCorrection fixes by cao and jmv
>> * Lots of minor fixes
>>
>> A big news, at least for me, is that I added a "Donate" button. So,
>> you have a new way to help me keep developing Cuis.
>>
>> Cheers,
>> Juan Vuletich
>>
>
>
>

> On 4/7/2010 6:04 PM, Phil (list) wrote:
>> 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.
>
> Make sure you run "Smalltalk recreateSpecialObjectsArray" to ensure  
> the FFI classes get registered properly.
>

> 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.

> 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.

> On 4/7/2010 6:04 PM, Phil (list) wrote:
>> 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.
>
> Make sure you run "Smalltalk recreateSpecialObjectsArray" to ensure
> the FFI classes get registered properly.
>
> Cheers,
>   - Andreas

>> 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.

> 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.

>> 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!

>
>> 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?
>

> 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.