From 0800nacho at gmail.com  Sun Nov  1 20:45:06 2015
From: 0800nacho at gmail.com (nacho)
Date: Sun, 1 Nov 2015 18:45:06 -0800 (PST)
Subject: [Cuis] serialization in Cuis
Message-ID: <1446432306774-4858922.post@n4.nabble.com>

Hi Folks,
I'm trying to add support for serializing instances of a class. 
I'm looking at System-Object Storage
And in particular to the class SmartRefStream which seems to add that
functionality. However, the class has no comments and no examples.
Is there some example which uses this class? a short demo? an example?
Thanks in advance!!
best
Nacho





-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/serialization-in-Cuis-tp4858922.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Sun Nov  1 22:52:24 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sun, 1 Nov 2015 20:52:24 -0800
Subject: [Cuis] ColorEditor updated
In-Reply-To: <56357262.9599.2DA3199@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<56357262.9599.2DA3199@dnorton.mindspring.com>
Message-ID: <20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>

On Sat, 31 Oct 2015 22:01:06 -0400
"Dan Norton" <dnorton at mindspring.com> wrote:

> On 29 Oct 2015 at 16:56, KenD wrote:
..
> > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > updates.  You can file it in and check senders.
..
> I've done that and I see that messages to SystemChangeNotifier are not required in order to  use the method.
> 
> Also, the dependency mechanism itself uses #when:send:to:.
> 
> Any object can use  #when:send:to: because it is an Object instance method. 
> 
> So, should this be named a different mechanism or is it just a different use of the 
> dependency mechanism?
> 
> If it's a different mechanism, is "Signals" the right name? This by Marcel Taeumel:
> 	
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#Featu
> reComparison

Hi Dan.

I took a look at the Signals implementation some time ago and my recollection is that I found the implementation to be complex and less useful than I had hoped.

For my limited uses, I prefer #when:send:to:

Simplicity wins.  In the longer term I hope somebody gets a chance to rewrite the older #changed: code to use the #when:send:to: mechanism so that we can remove #changed: .

I agree that having two update mechanisms is one too many.  Adding a third dependency update, Signals, would be going in the wrong direction IMHO.

$0.02
-KenD



From dnorton at mindspring.com  Mon Nov  2 14:58:26 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 02 Nov 2015 15:58:26 -0500
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<56357262.9599.2DA3199@dnorton.mindspring.com>,
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
Message-ID: <5637CE72.9136.1176A2C@dnorton.mindspring.com>

Hi Ken,

Comments in line.

On 1 Nov 2015 at 20:52, KenD wrote:

> On Sat, 31 Oct 2015 22:01:06 -0400
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> > On 29 Oct 2015 at 16:56, KenD wrote:
> ..
> > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > > updates.  You can file it in and check senders.
> ..
> > I've done that and I see that messages to SystemChangeNotifier are
> not required in order to  use the method.
> > 
> > Also, the dependency mechanism itself uses #when:send:to:.
> > 
> > Any object can use  #when:send:to: because it is an Object
> instance method. 
> > 
> > So, should this be named a different mechanism or is it just a
> different use of the 
> > dependency mechanism?
> > 
> > If it's a different mechanism, is "Signals" the right name? This
> by Marcel Taeumel:
> > 	
> >
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjec
> ts/wiki/signals#Featu
> > reComparison
> 
> Hi Dan.
> 
> I took a look at the Signals implementation some time ago and my
> recollection is that I found the implementation to be complex and
> less useful than I had hoped.
> 
> For my limited uses, I prefer #when:send:to:
> 
> Simplicity wins.

+1

  In the longer term I hope somebody gets a chance
> to rewrite the older #changed: code to use the #when:send:to:
> mechanism so that we can remove #changed: .
> 
> I agree that having two update mechanisms is one too many.  Adding a
> third dependency update, Signals, would be going in the wrong
> direction IMHO.
>

That's fine. I was casting about for some name besides " #when:send:to: mechanism" for 
use in a brief essay on PluggableListMorph Principles of Operation when I came across 
Signals. I already wrote a paragraph on Dependency Mechanism.

So, the simple principle here is to just use #when:send:to: and forget about or maybe 
deprecate #changed: and #update:? The advantage IIUC is #when:send:to:
	can be sent by any object, 
	the receiver can be any object, 
	the to: parameter can be any object, and 
	the send: parameter doesn't necessarily have to exist because WeakMessageSend 
is used! 

What a deal :).

However, I see a problem common to dependency and #when:send:to: which is the 
identification and explanation of the various symbols which are communicated as the 
parameters for send: or changed: . When you're trying to design a model or view similar to 
something already in existence, the tools are not much help with that.

I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>

Would appreciate any thoughts.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151102/3d081884/attachment-0002.html>

From Ken.Dickey at Whidbey.com  Mon Nov  2 17:27:16 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Mon, 2 Nov 2015 15:27:16 -0800
Subject: [Cuis] ColorEditor updated
In-Reply-To: <5637CE72.9136.1176A2C@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<56357262.9599.2DA3199@dnorton.mindspring.com>
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
Message-ID: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>

On Mon, 02 Nov 2015 15:58:26 -0500
"Dan Norton" <dnorton at mindspring.com> wrote:

>.. I was casting about for some name besides " #when:send:to: mechanism" for 
> use in a brief essay on PluggableListMorph Principles of Operation when I came across 
> Signals. I already wrote a paragraph on Dependency Mechanism.

I would talk about #when:send:to: as implementing the Observer Pattern.

> So, the simple principle here is to just use #when:send:to: and forget about or maybe 
> deprecate #changed: and #update:? 

Yes.  Let us work to eliminate #changed: !

> However, I see a problem common to dependency and #when:send:to: which is the 
> identification and explanation of the various symbols which are communicated as the 
> parameters for send: or changed: . When you're trying to design a model or view similar to 
> something already in existence, the tools are not much help with that.
> 
> I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>

We should certainly add clarifying comments!

Your Comment Browser is a big help here.  Once people start using it more, comments will appear.

I suggest sending Juan a code update with an added "Open Comment Browser" Help menu item which autoloads the same way as TerseGuide.


However, class comments are not usually where design patterns show up.  8^|

In the case of #when:send:to: I suggest a slightly larger discussion around building paned windows which update dependent panes.

What constitutes good style?  What code patterns help?

Think "Useful Code Patterns" to augment "Useful Expressions".

You can do your own example, but looking at the ColorEditor:

ColorEditor>>buildMorphicWindow
	"Create a useful ColorEditor window"
	
	self layoutMorph beRow; " A row of columns"
		 separation: 6;
		 addMorph: self buildColorPaneColumn;
		 addMorph: self buildSliderColumn;
		 addMorph: self buildRadioButtonColumn;
		 color: self backgroundColor.
		
	self model when: #colorChanged send: #refreshColor to: self.
	
	^ self

So trying for good style (hey, I need to improve here too!) one uses: 

[Class]>buildMorphicWindow
    [Add (construct each pane).. to layout]
    [Add self or panes as observers]
  ^ self

Suggest
  Smalltalk browseAllImplementorsOf: #buildMorphicWindow
to see specific usage examples.

Of course, we will suffer some embarrassment as our real code is less than ideal. 8^(

But this is a great motivator to making our code better!  ;^)


$0.02
-KenD



From hannes.hirzel at gmail.com  Mon Nov  2 19:39:44 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 3 Nov 2015 02:39:44 +0100
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<56357262.9599.2DA3199@dnorton.mindspring.com>
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
Message-ID: <CAGQxfVjUVgu4_JDOEYJR1Kf4Kv+YADxMDb9bPd7=-rO8U_dZxg@mail.gmail.com>

On 11/3/15, KenD <Ken.Dickey at whidbey.com> wrote:
> On Mon, 02 Nov 2015 15:58:26 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
>
>>.. I was casting about for some name besides " #when:send:to: mechanism"
>> for
>> use in a brief essay on PluggableListMorph Principles of Operation when I
>> came across
>> Signals. I already wrote a paragraph on Dependency Mechanism.
>
> I would talk about #when:send:to: as implementing the Observer Pattern.
>
>> So, the simple principle here is to just use #when:send:to: and forget
>> about or maybe
>> deprecate #changed: and #update:?
>
> Yes.  Let us work to eliminate #changed: !
>
>> However, I see a problem common to dependency and #when:send:to: which is
>> the
>> identification and explanation of the various symbols which are
>> communicated as the
>> parameters for send: or changed: . When you're trying to design a model or
>> view similar to
>> something already in existence, the tools are not much help with that.
>>
>> I'm thinking maybe: document in comments? <rant>Nah. We don't do
>> comments.</rant>
>
> We should certainly add clarifying comments!
>
> Your Comment Browser is a big help here.  Once people start using it more,
> comments will appear.
>
> I suggest sending Juan a code update with an added "Open Comment Browser"
> Help menu item which autoloads the same way as TerseGuide.
+1
>
> However, class comments are not usually where design patterns show up.  8^|
>
> In the case of #when:send:to: I suggest a slightly larger discussion around
> building paned windows which update dependent panes.
>
> What constitutes good style?  What code patterns help?
>
> Think "Useful Code Patterns" to augment "Useful Expressions".
+1
> You can do your own example, but looking at the ColorEditor:
>
> ColorEditor>>buildMorphicWindow
> 	"Create a useful ColorEditor window"
> 	
> 	self layoutMorph beRow; " A row of columns"
> 		 separation: 6;
> 		 addMorph: self buildColorPaneColumn;
> 		 addMorph: self buildSliderColumn;
> 		 addMorph: self buildRadioButtonColumn;
> 		 color: self backgroundColor.
> 		
> 	self model when: #colorChanged send: #refreshColor to: self.
> 	
> 	^ self
>
> So trying for good style (hey, I need to improve here too!) one uses:
>
> [Class]>buildMorphicWindow
>     [Add (construct each pane).. to layout]
>     [Add self or panes as observers]
>   ^ self
>
> Suggest
>   Smalltalk browseAllImplementorsOf: #buildMorphicWindow
> to see specific usage examples.
>
> Of course, we will suffer some embarrassment as our real code is less than
> ideal. 8^(
>
> But this is a great motivator to making our code better!  ;^)
>
>
> $0.02
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From brasspen at gmail.com  Tue Nov  3 07:47:59 2015
From: brasspen at gmail.com (Chris Cunnington)
Date: Tue, 3 Nov 2015 08:47:59 -0500
Subject: [Cuis] [ANN] OopluCon 2016, San Francisco, April
Message-ID: <5638BB0F.5030700@gmail.com>

OopluCon 2016
A Day for the Smalltalk Programming Language and its Friends

Sunday 10 April 2016
8am - 4pm

The Box SF
1069 Howard Street (between 6th and 7th)
three blocks from Moscone Center, SoMa
San Francisco, USA
http://www.theboxsf.com/

The event is free
A request for presentations will be announced in a future month
A presentation called An Introduction To Smalltalk will promoted to the 
Ruby, Python and Objective C communities
The latest details will be available at http://www.ooplu.com




From dnorton at mindspring.com  Tue Nov  3 12:11:50 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 03 Nov 2015 13:11:50 -0500
Subject: [Cuis] Terse Guide to Cuis
Message-ID: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>

Hi Juan,

The guide has been updated as follows:

	revised iterations topic
	revised transcript topic
	replaced file streams with file operations topic featuring FileMan

Please include this in the next build. The repo is:

	https://github.com/dhnorton/Cuis-Smalltalk-terse

 - Dan



From dnorton at mindspring.com  Tue Nov  3 13:58:46 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 03 Nov 2015 14:58:46 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <563911F6.21646.11C43C8@dnorton.mindspring.com>

Hi Juan,

As recommended by Ken and Hannes, the attached methods add the capability to bring up 
the class comment browser from the help menu.

Sorry, but I still don't know how to prepend the thumbnail to the menu item :)

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TheWorldMenu-openCommentGuide.zip
Type: application/zip
Size: 1298 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151103/b51fa789/attachment-0002.zip>

From 0800nacho at gmail.com  Tue Nov  3 17:13:35 2015
From: 0800nacho at gmail.com (nacho)
Date: Tue, 3 Nov 2015 15:13:35 -0800 (PST)
Subject: [Cuis] Terse Guide to Cuis
In-Reply-To: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
References: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
Message-ID: <1446592415409-4859122.post@n4.nabble.com>

Thanks Dan,
This guide is very helpful.
Are you planning to add some help in all the ways to manipulate colours?
Best regards
Nacho





-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Re-Terse-Guide-to-Cuis-tp4859099p4859122.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From 0800nacho at gmail.com  Wed Nov  4 05:00:53 2015
From: 0800nacho at gmail.com (nacho)
Date: Wed, 4 Nov 2015 03:00:53 -0800 (PST)
Subject: [Cuis] Terse Guide to Cuis
In-Reply-To: <1446592415409-4859122.post@n4.nabble.com>
References: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
	<1446592415409-4859122.post@n4.nabble.com>
Message-ID: <1446634853959-4859148.post@n4.nabble.com>

Dan,
Thanks for your prompt response.
I already had all of Mr. Dickey's marvellous and mysterious Cuis stuff
cloned into my computer :p
Very useful too.
Best
nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Re-Terse-Guide-to-Cuis-tp4859099p4859148.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Wed Nov  4 09:11:16 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Wed, 4 Nov 2015 07:11:16 -0800
Subject: [Cuis] Terse Guide to Cuis
In-Reply-To: <1446634853959-4859148.post@n4.nabble.com>
References: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
	<1446592415409-4859122.post@n4.nabble.com>
	<1446634853959-4859148.post@n4.nabble.com>
Message-ID: <20151104071116.8650ae2d569537a692f895ec@Whidbey.com>

On Wed, 4 Nov 2015 03:00:53 -0800 (PST)
nacho <0800nacho at gmail.com> wrote:

> I already had all of Mr. Dickey's marvellous and mysterious Cuis stuff
> cloned into my computer :p

Note that I have been working through my projects, eliminating FileDirectory in favor of FileMan.

Users should to do a "git pull" on most of these for 2568.

As usual, bugs to /dev/null, er, I mean to me  ;^)
-KenD



From dnorton at mindspring.com  Wed Nov  4 17:46:20 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 04 Nov 2015 18:46:20 -0500
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>,
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
Message-ID: <563A98CC.20508.1B798BE@dnorton.mindspring.com>

Ran across this comment for ActiveModel and thought it was interesting, historically.

Part of update 5005u16-Events.cs:

"Change Set:		Events
Date:			11 February 2002
Author:			Rob Withers et al.

Published to 3.3a as 4756Events.cs

The NuBlue events code. Finally..."

The new event model, originally from VisualSmalltalk.
This includes #when:send:to: and friends, in Object (generic implementation) and 
ActiveModel (optimized implementation).
It renders the old change/update mechanism in Object and Model as obsolete, although still 
used.

 - Dan

On 2 Nov 2015 at 15:27, KenD wrote:

> On Mon, 02 Nov 2015 15:58:26 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> >.. I was casting about for some name besides " #when:send:to:
> mechanism" for 
> > use in a brief essay on PluggableListMorph Principles of Operation
> when I came across 
> > Signals. I already wrote a paragraph on Dependency Mechanism.
> 
> I would talk about #when:send:to: as implementing the Observer
> Pattern.
> 
> > So, the simple principle here is to just use #when:send:to: and
> forget about or maybe 
> > deprecate #changed: and #update:? 
> 
> Yes.  Let us work to eliminate #changed: !
> 
> > However, I see a problem common to dependency and #when:send:to:
> which is the 
> > identification and explanation of the various symbols which are
> communicated as the 
> > parameters for send: or changed: . When you're trying to design a
> model or view similar to 
> > something already in existence, the tools are not much help with
> that.
> > 
> > I'm thinking maybe: document in comments? <rant>Nah. We don't do
> comments.</rant>
> 
> We should certainly add clarifying comments!
> 
> Your Comment Browser is a big help here.  Once people start using it
> more, comments will appear.
> 
> I suggest sending Juan a code update with an added "Open Comment
> Browser" Help menu item which autoloads the same way as
> TerseGuide.
> 
> 
> However, class comments are not usually where design patterns show
> up.  8^|
> 
> In the case of #when:send:to: I suggest a slightly larger discussion
> around building paned windows which update dependent panes.
> 
> What constitutes good style?  What code patterns help?
> 
> Think "Useful Code Patterns" to augment "Useful Expressions".
> 
> You can do your own example, but looking at the ColorEditor:
> 
> ColorEditor>>buildMorphicWindow
> 	"Create a useful ColorEditor window"
> 	
> 	self layoutMorph beRow; " A row of columns"
> 		 separation: 6;
> 		 addMorph: self buildColorPaneColumn;
> 		 addMorph: self buildSliderColumn;
> 		 addMorph: self buildRadioButtonColumn;
> 		 color: self backgroundColor.
> 		
> 	self model when: #colorChanged send: #refreshColor to: self.
> 	
> 	^ self
> 
> So trying for good style (hey, I need to improve here too!) one
> uses: 
> 
> [Class]>buildMorphicWindow
>     [Add (construct each pane).. to layout]
>     [Add self or panes as observers]
>   ^ self
> 
> Suggest
>   Smalltalk browseAllImplementorsOf: #buildMorphicWindow
> to see specific usage examples.
> 
> Of course, we will suffer some embarrassment as our real code is
> less than ideal. 8^(
> 
> But this is a great motivator to making our code better!  ;^)
> 
> 
> $0.02
> -KenD





From dnorton at mindspring.com  Thu Nov  5 12:23:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 05 Nov 2015 13:23:07 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <563B9E8B.18686.D41F27@dnorton.mindspring.com>

The latest enables list selection by key. Not fancy like PluggableListMorph, just single key 
selection.

	https://github.com/dhnorton/Cuis-Smalltalk-comments

Somehoo I have introduced a yip in the scroller but maybe it is usable for the time being.

 - Dan



From hari.balaraman at icloud.com  Thu Nov  5 13:53:44 2015
From: hari.balaraman at icloud.com (Hari Balaraman)
Date: Thu, 05 Nov 2015 14:53:44 -0500
Subject: [Cuis] FAST conference
In-Reply-To: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
Message-ID: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>

If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
Best regards,
Hari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151105/32d3218d/attachment-0002.html>

From dnorton at mindspring.com  Thu Nov  5 15:25:17 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 5 Nov 2015 13:25:17 -0800 (PST)
Subject: [Cuis] Class Comment Browser
In-Reply-To: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
References: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
Message-ID: <1446758717845-4859424.post@n4.nabble.com>

:( OK, I fixed it. :)

 - Dan



--
View this message in context: http://forum.world.st/Class-Comment-Browser-tp4859411p4859424.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From juan at jvuletich.org  Fri Nov  6 12:04:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:04:53 -0300
Subject: [Cuis] ColorEditor updated
In-Reply-To: <5637CE72.9136.1176A2C@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<56357262.9599.2DA3199@dnorton.mindspring.com>,
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
Message-ID: <563CEBC5.40409@jvuletich.org>

(inline)

On 11/2/2015 5:58 PM, Dan Norton wrote:
> Hi Ken,
>
> Comments in line.
>
> On 1 Nov 2015 at 20:52, KenD wrote:
>
> > On Sat, 31 Oct 2015 22:01:06 -0400
> > "Dan Norton" <dnorton at mindspring.com> wrote:
> >
> > > On 29 Oct 2015 at 16:56, KenD wrote:
> > ..
> > > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > > > updates.  You can file it in and check senders.
> > ..
> > > I've done that and I see that messages to SystemChangeNotifier are
> > not required in order to  use the method.
> > >
> > > Also, the dependency mechanism itself uses #when:send:to:.
> > >
> > > Any object can use  #when:send:to: because it is an Object
> > instance method.
> > >
> > > So, should this be named a different mechanism or is it just a
> > different use of the
> > > dependency mechanism?
> > >
> > > If it's a different mechanism, is "Signals" the right name? This
> > by Marcel Taeumel:
> > >
> > >
> > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjec
> > ts/wiki/signals#Featu
> > > reComparison
> >
> > Hi Dan.
> >
> > I took a look at the Signals implementation some time ago and my
> > recollection is that I found the implementation to be complex and
> > less useful than I had hoped.
> >
> > For my limited uses, I prefer #when:send:to:
> >
> > Simplicity wins.
>
> +1
>
>   In the longer term I hope somebody gets a chance
> > to rewrite the older #changed: code to use the #when:send:to:
> > mechanism so that we can remove #changed: .
> >
> > I agree that having two update mechanisms is one too many.  Adding a
> > third dependency update, Signals, would be going in the wrong
> > direction IMHO.
> >
>
> That's fine. I was casting about for some name besides " 
> #when:send:to: mechanism" for
> use in a brief essay on PluggableListMorph Principles of Operation 
> when I came across
> Signals. I already wrote a paragraph on Dependency Mechanism.
>
> So, the simple principle here is to just use #when:send:to: and forget 
> about or maybe deprecate #changed: and #update:? The advantage IIUC is 
> #when:send:to:
>            can be sent by any object,
>            the receiver can be any object,
>            the to: parameter can be any object, and
>            the send: parameter doesn't necessarily have to exist 
> because WeakMessageSend is used!
>
> What a deal :).
>
> However, I see a problem common to dependency and #when:send:to: which 
> is the identification and explanation of the various symbols which are 
> communicated as the parameters forsend: or changed: . When you're 
> trying to design a model or view similar to something already in 
> existence, the tools are not much help with that.
>

Well, doing senders on any symbol (method selectors, but also event 
names) shows all references to it. I don't think it is that bad, but, do 
you have ideas for improvements on this?

> I'm thinking maybe: document in comments? <rant>Nah. We don't do 
> comments.</rant>

Let me disagree. Cuis includes 204019 characters in class comments. That 
would be like 2000 to 4000 lines, right? For a system with less than 
100kLOC. Top 10 classes with extensive class comments are: BitBlt 
SmartRefStream Float ClosureScanner Color ContentPack Monitor 
AndreasSystemProfiler EventSensor ReferenceStream. Just check them. 
Several of these are rather recent, some were written specifically for 
Cuis.

We also have  27058 bytes of comments at the top of methods. Some 
methods with great comments are #vmParameterAt: #entriesIn: 
#eliotsClosureMeasurements2On: #getCurrentWorkingDirectory 
#whatIsAPrimitive #asUtf8: #howToModifyPrimitives #applySimpleGamma:to: 
#linearTosRGBGamma: #localMicrosecondClock #findBinaryIndex:do:ifNone: 
#findBinary:do:ifNone: #spyAllOn: , etc.

There is a lot to be learnt about the system from reading comments. And 
we want to improve.

(BTW, querying the system to find this out took me less time than 
writing this email)

> Would appreciate any thoughts.
>
>  - Dan
>

I think that both comments and tools are useful and should be enhanced.

Cheers,
Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/8f076245/attachment-0002.html>

From juan at jvuletich.org  Fri Nov  6 12:13:13 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:13:13 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <1446432306774-4858922.post@n4.nabble.com>
References: <1446432306774-4858922.post@n4.nabble.com>
Message-ID: <563CEDB9.2090200@jvuletich.org>

Hi Nacho,

On 11/1/2015 11:45 PM, nacho wrote:
> Hi Folks,
> I'm trying to add support for serializing instances of a class.
> I'm looking at System-Object Storage
> And in particular to the class SmartRefStream which seems to add that
> functionality. However, the class has no comments and no examples.
> Is there some example which uses this class? a short demo? an example?
> Thanks in advance!!
> best
> Nacho
>

Are we browsing the same system? SmartRefStream class comment is 6016 
characters here. Superclass ReferenceStream has a class comments of 2875 
characters. DataStream and ReferenceStream have class methods that start 
with 'example'. Looking for references to these classes also brings 
useful examples of usage.

In any case, the usual way to serialize classes is fileOut. Why doesn't 
this work for you? What problem are you trying to solve?

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Nov  6 12:28:23 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:28:23 -0300
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<56357262.9599.2DA3199@dnorton.mindspring.com>	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
Message-ID: <563CF147.306@jvuletich.org>

Hi Ken,

On 11/2/2015 8:27 PM, KenD wrote:
> ...
>
> However, class comments are not usually where design patterns show up.  8^|
>
> In the case of #when:send:to: I suggest a slightly larger discussion around building paned windows which update dependent panes.
>
> What constitutes good style?  What code patterns help?
>
> Think "Useful Code Patterns" to augment "Useful Expressions".

In 2009 I wrote 
http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgramming.txt 
and 
http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.txt . 
I've had the idea of making all the GUI code in Cuis follow this style. 
But time is always short...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Nov  6 12:29:02 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:29:02 -0300
Subject: [Cuis] [ANN] OopluCon 2016, San Francisco, April
In-Reply-To: <5638BB0F.5030700@gmail.com>
References: <5638BB0F.5030700@gmail.com>
Message-ID: <563CF16E.3040707@jvuletich.org>

:)

On 11/3/2015 10:47 AM, Chris Cunnington wrote:
> OopluCon 2016
> A Day for the Smalltalk Programming Language and its Friends
>
> Sunday 10 April 2016
> 8am - 4pm
>
> The Box SF
> 1069 Howard Street (between 6th and 7th)
> three blocks from Moscone Center, SoMa
> San Francisco, USA
> http://www.theboxsf.com/
>
> The event is free
> A request for presentations will be announced in a future month
> A presentation called An Introduction To Smalltalk will promoted to 
> the Ruby, Python and Objective C communities
> The latest details will be available at http://www.ooplu.com
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Fri Nov  6 12:32:14 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:32:14 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
Message-ID: <563CF22E.4080804@jvuletich.org>

Hi Hari,

I'll be there. Let's meet then.

Anybody else?

Cheers,
Juan Vuletich

On 11/5/2015 4:53 PM, Hari Balaraman wrote:
> If any of you are attending the FAST conference in Buenos Aires in a 
> week or so, I look forward to meeting you face to face.
> Best regards,
> Hari
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/3c065b90/attachment-0002.html>

From 0800nacho at gmail.com  Fri Nov  6 12:40:14 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Fri, 6 Nov 2015 15:40:14 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <563CF22E.4080804@jvuletich.org>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
Message-ID: <etPan.563cf40e.77bd141b.a58@Unix.local>

Yes I will be there too.
Juan, are you giving the talk on friday?
cheers


--?
Ignacio Sniechowski
Prosavic SRL
Sent with Airmail

On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org) wrote:

Hi Hari,

I'll be there. Let's meet then.

Anybody else?

Cheers,
Juan Vuletich

On 11/5/2015 4:53 PM, Hari Balaraman wrote:
If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
Best regards,
Hari


_______________________________________________
Cuis mailing list
Cuis at jvuletich.org
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________  
Cuis mailing list  
Cuis at jvuletich.org  
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/0cb1d1b7/attachment-0002.html>

From 0800nacho at gmail.com  Fri Nov  6 12:42:53 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Fri, 6 Nov 2015 15:42:53 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <563CEDB9.2090200@jvuletich.org>
References: <1446432306774-4858922.post@n4.nabble.com>
	<563CEDB9.2090200@jvuletich.org>
Message-ID: <etPan.563cf4ad.177918bd.a58@Unix.local>

Hi Juan,
Thanks for your response.
I?m not trying to serialize classes but instances of them.
Suppose theres a class called Memo with an ivar ?content?
Then I want to be able add to the instances the posibility of storing their data.
fileOut is great for classes I use it a lot!
But I want a way to preserve data outside the image, so it can be loaded when a new image is used.
thanks!
Nacho


--?
Ignacio Sniechowski
Prosavic SRL
Sent with Airmail

On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org) wrote:

Hi Nacho,  

On 11/1/2015 11:45 PM, nacho wrote:  
> Hi Folks,  
> I'm trying to add support for serializing instances of a class.  
> I'm looking at System-Object Storage  
> And in particular to the class SmartRefStream which seems to add that  
> functionality. However, the class has no comments and no examples.  
> Is there some example which uses this class? a short demo? an example?  
> Thanks in advance!!  
> best  
> Nacho  
>  

Are we browsing the same system? SmartRefStream class comment is 6016  
characters here. Superclass ReferenceStream has a class comments of 2875  
characters. DataStream and ReferenceStream have class methods that start  
with 'example'. Looking for references to these classes also brings  
useful examples of usage.  

In any case, the usual way to serialize classes is fileOut. Why doesn't  
this work for you? What problem are you trying to solve?  

Cheers,  
Juan Vuletich  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/d2e149d2/attachment-0002.html>

From juan at jvuletich.org  Fri Nov  6 12:43:57 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:43:57 -0300
Subject: [Cuis] Class Comment Browser
In-Reply-To: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
References: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
Message-ID: <563CF4ED.6090306@jvuletich.org>

On 11/5/2015 3:23 PM, Dan Norton wrote:
> The latest enables list selection by key. Not fancy like PluggableListMorph, just single key
> selection.
>
> 	https://github.com/dhnorton/Cuis-Smalltalk-comments
>
> Somehoo I have introduced a yip in the scroller but maybe it is usable for the time being.
>
>   - Dan

Hi Dan,

Just integrated your recent contributions. Thank you!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Nov  6 12:45:15 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:45:15 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <etPan.563cf40e.77bd141b.a58@Unix.local>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
Message-ID: <563CF53B.5000107@jvuletich.org>

Yes, on Friday. Meet you there!

Cheers,
Juan Vuletich

On 11/6/2015 3:40 PM, Ignacio Sniechowski wrote:
> Yes I will be there too.
> Juan, are you giving the talk on friday?
> cheers
>
>
> -- 
> Ignacio Sniechowski
> Prosavic SRL
> Sent with Airmail
>
> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org 
> <mailto:juan at jvuletich.org>) wrote:
>
>> Hi Hari,
>>
>> I'll be there. Let's meet then.
>>
>> Anybody else?
>>
>> Cheers,
>> Juan Vuletich
>>
>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>> If any of you are attending the FAST conference in Buenos Aires in a 
>>> week or so, I look forward to meeting you face to face.
>>> Best regards,
>>> Hari
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/36a59629/attachment-0002.html>

From juan at jvuletich.org  Fri Nov  6 12:48:20 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:48:20 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <etPan.563cf4ad.177918bd.a58@Unix.local>
References: <1446432306774-4858922.post@n4.nabble.com>
	<563CEDB9.2090200@jvuletich.org>
	<etPan.563cf4ad.177918bd.a58@Unix.local>
Message-ID: <563CF5F4.1070808@jvuletich.org>

Hi Nacho,

Oh, yes, I misread. Ok. ReferenceStream and SmartRefStream are your 
choices. Take a look at the class comments, play with the examples. Ask 
questions.

Cheers,
Juan Vuletich


On 11/6/2015 3:42 PM, Ignacio Sniechowski wrote:
> Hi Juan,
> Thanks for your response.
> I?m not trying to serialize classes but instances of them.
> Suppose theres a class called Memo with an ivar ?content?
> Then I want to be able add to the instances the posibility of storing 
> their data.
> fileOut is great for classes I use it a lot!
> But I want a way to preserve data outside the image, so it can be 
> loaded when a new image is used.
> thanks!
> Nacho
>
>
> -- 
> Ignacio Sniechowski
> Prosavic SRL
> Sent with Airmail
>
> On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org 
> <mailto:juan at jvuletich.org>) wrote:
>
>> Hi Nacho,
>>
>> On 11/1/2015 11:45 PM, nacho wrote:
>> > Hi Folks,
>> > I'm trying to add support for serializing instances of a class.
>> > I'm looking at System-Object Storage
>> > And in particular to the class SmartRefStream which seems to add that
>> > functionality. However, the class has no comments and no examples.
>> > Is there some example which uses this class? a short demo? an example?
>> > Thanks in advance!!
>> > best
>> > Nacho
>> >
>>
>> Are we browsing the same system? SmartRefStream class comment is 6016
>> characters here. Superclass ReferenceStream has a class comments of 2875
>> characters. DataStream and ReferenceStream have class methods that start
>> with 'example'. Looking for references to these classes also brings
>> useful examples of usage.
>>
>> In any case, the usual way to serialize classes is fileOut. Why doesn't
>> this work for you? What problem are you trying to solve?
>>
>> Cheers,
>> Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/cda299f0/attachment-0002.html>

From dnorton at mindspring.com  Fri Nov  6 15:21:21 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 06 Nov 2015 16:21:21 -0500
Subject: [Cuis] Unknown File Dialogue
Message-ID: <563D19D1.11201.12C21F7@dnorton.mindspring.com>

Hello,

In FmFileEntry>>fileContents, a dialogue is presented if there is an attempt to read a file 
which does not exist. This gives the opportunity to choose another name or cancel.

A "Cancel" response produces MNU: #contents

To avoid the MNU and answer nil, I suggest the attached change be made to #fileContents.

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FmFileEntry-fileContents.zip
Type: application/zip
Size: 456 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/46db3fe0/attachment-0002.zip>

From edgardec2005 at gmail.com  Sat Nov  7 05:31:06 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sat, 07 Nov 2015 08:31:06 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <563CF5F4.1070808@jvuletich.org>
Message-ID: <D263674C.16FF1%edgardec2005@gmail.com>

As Juan said, ReferenceStream is your friend
Here I attach a old cs
If you wish , Foo saveOnFileNamed: 'Foo'create a Foo.obj file in your
working directory.
Later you could use readAndInspect: 'Path to your file'
When you have DrgaAndDrop as my forked CuiSantafesino you could exchange
working objects between Squeak,Cuis and Pharo.
And if you said Pharo do not have ReferenceStream , well I made how to for
Pharo 2.0 so is possible.
With this technique I export and import objects big enough for have complete
swiki into a Squeak derivate image, about 14 mb of data
Cheers

Edgar
@morplenauta




On 11/6/15, 3:48 PM, "Juan Vuletich" <juan at jvuletich.org> wrote:

>  Hi Nacho,
>  
>  Oh, yes, I misread. Ok. ReferenceStream and SmartRefStream are your choices.
> Take a look at the class comments, play with the examples. Ask questions.
>  
>  Cheers,
>  Juan Vuletich
>  
>  
>  On 11/6/2015 3:42 PM, Ignacio Sniechowski wrote:
>>   
>> Hi Juan,
>>  
>> Thanks for your response.
>>  
>> I?m not trying to serialize classes but instances of them.
>>  
>> Suppose theres a class called Memo with an ivar ?content?
>>  
>> Then I want to be able add to the instances the posibility of storing their
>> data.
>>  
>> fileOut is great for classes I use it a lot!
>>  
>> But I want a way to preserve data outside the image, so it can be loaded when
>> a new image is used.
>>  
>> thanks!
>>  
>> Nacho
>>  
>> 
>>  
>>  
>>  
>>  
>> --?
>>  Ignacio Sniechowski
>>  
>> Prosavic SRL
>>  Sent with Airmail
>>  
>>  
>>  
>> 
>> On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org) wrote:
>>  
>>>  
>>>  
>>> Hi Nacho, 
>>>  
>>>  On 11/1/2015 11:45 PM, nacho wrote:
>>>>  > Hi Folks, 
>>>>  > I'm trying to add support for serializing instances of a class.
>>>>  > I'm looking at System-Object Storage
>>>>  > And in particular to the class SmartRefStream which seems to add that
>>>>  > functionality. However, the class has no comments and no examples.
>>>>  > Is there some example which uses this class? a short demo? an example?
>>>>  > Thanks in advance!!
>>>>  > best 
>>>>  > Nacho 
>>>>  > 
>>>  
>>>  Are we browsing the same system? SmartRefStream class comment is 6016
>>>  characters here. Superclass ReferenceStream has a class comments of 2875
>>>  characters. DataStream and ReferenceStream have class methods that start
>>>  with 'example'. Looking for references to these classes also brings
>>>  useful examples of usage.
>>>  
>>>  In any case, the usual way to serialize classes is fileOut. Why doesn't
>>>  this work for you? What problem are you trying to solve?
>>>  
>>>  Cheers, 
>>>  Juan Vuletich 
>>>  
>>>  
>>>  
>>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151107/b0b7510f/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ObjectEnhEd.2.cs
Type: application/octet-stream
Size: 15734 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151107/b0b7510f/attachment-0002.obj>

From hannes.hirzel at gmail.com  Sat Nov  7 08:49:21 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 7 Nov 2015 15:49:21 +0100
Subject: [Cuis] serialization in Cuis
In-Reply-To: <D263674C.16FF1%edgardec2005@gmail.com>
References: <563CF5F4.1070808@jvuletich.org>
	<D263674C.16FF1%edgardec2005@gmail.com>
Message-ID: <CAGQxfVh391ZLuY4TDE3tLw+i=ZF4vNEMn3_ZL-29Sj-fTmv0GQ@mail.gmail.com>

Hello Nacho

Is it possible that your Cuis system does not show the class comments
for some reason?

Juan referred you to the class comment of ReferenceStream and the
subclass SmartreferenceStream.

The comment of class ReferenceStream below. It gives an example how to
store objects.

Regards
Hannes


---------------------------------
Comment of class ReferenceStream in Cuis 4.2-2563


This is a way of serializing a tree of objects into disk file. A
ReferenceStream can store
one or more objects in a persistent form, including sharing and cycles.

Here is the way to use DataStream and ReferenceStream:
	rr _ ReferenceStream fileNamed: 'test.obj'.
	rr nextPut: <your object>.
	rr close.

To get it back:
	rr _ ReferenceStream fileNamed: 'test.obj'.
	<your object> _ rr next.
	rr close.

ReferenceStreams can now write "weak" references. nextPutWeak:
writes a "weak" reference to an object, which refers to that object
*if* it also gets written to the stream by a normal nextPut:.

A ReferenceStream should be treated as a read-stream *or* as a
write-stream, *not* as a read/write-stream. The reference-remembering
mechanism would probably do bad things if you tried to read and write
from the same ReferenceStream.

[TBD] Should we override "close" to do (self forgetReferences)?

Instance variables
 references -- an IdentityDictionary mapping objects already written
	to their byteStream positions. If asked to write any object a
	second time, we just write a reference to its stream position.
	This handles shared objects and reference cycles between objects.
	To implement "weak references" (for Aliases), the references
	dictionary also maps objects not (yet?) written to a Collection
	of byteStream positions with hopeful weak-references to it. If
	asked to definitely write one of these objects, we'll fixup those
	weak references.
 objects -- an IdentityDictionary mapping relative byte stream positions to
	objects already read in. If asked to follow a reference, we
	return the object already read.
	This handles shared objects and reference cycles between objects.
 currentReference -- the current reference position. Positon relative to the
	start of object data in this file.  (Allows user to cut and paste smalltalk
	code from the front of the file without effecting the reference values.)
	This variable is used to help install each new object in "objects" as soon
	as it's created, **before** we start reading its contents, in
	case any of its content objects reference it.
 fwdRefEnds -- A weak reference can be a forward reference, which
	requires advance-reading the referrent. When we later come to the
	object, we must get its value from "objects" and not re-read it so
	refs to it don't become refs to copies. fwdRefEnds remembers the
	ending byte stream position of advance-read objects.
 skipping -- true if <what?>

If the object is referenced before it is done being created, it might
get created twice.  Just store the object the moment it is created in
the 'objects' dictionary.  If at the end, comeFullyUpOnReload returns
a different object, some refs will have the temporary object (this is
an unlikely case).  At the moment, no implementor of
comeFullyUpOnReload returns a different object except DiskProxy, and
that is OK.


On 11/7/15, Edgar J. De Cleene <edgardec2005 at gmail.com> wrote:
> As Juan said, ReferenceStream is your friend
> Here I attach a old cs
> If you wish , Foo saveOnFileNamed: 'Foo'create a Foo.obj file in your
> working directory.
> Later you could use readAndInspect: 'Path to your file'
> When you have DrgaAndDrop as my forked CuiSantafesino you could exchange
> working objects between Squeak,Cuis and Pharo.
> And if you said Pharo do not have ReferenceStream , well I made how to for
> Pharo 2.0 so is possible.
> With this technique I export and import objects big enough for have
> complete
> swiki into a Squeak derivate image, about 14 mb of data
> Cheers
>
> Edgar
> @morplenauta
>
>
>
>
> On 11/6/15, 3:48 PM, "Juan Vuletich" <juan at jvuletich.org> wrote:
>
>>  Hi Nacho,
>>
>>  Oh, yes, I misread. Ok. ReferenceStream and SmartRefStream are your
>> choices.
>> Take a look at the class comments, play with the examples. Ask questions.
>>
>>  Cheers,
>>  Juan Vuletich
>>
>>
>>  On 11/6/2015 3:42 PM, Ignacio Sniechowski wrote:
>>>
>>> Hi Juan,
>>>
>>> Thanks for your response.
>>>
>>> I?m not trying to serialize classes but instances of them.
>>>
>>> Suppose theres a class called Memo with an ivar ?content?
>>>
>>> Then I want to be able add to the instances the posibility of storing
>>> their
>>> data.
>>>
>>> fileOut is great for classes I use it a lot!
>>>
>>> But I want a way to preserve data outside the image, so it can be loaded
>>> when
>>> a new image is used.
>>>
>>> thanks!
>>>
>>> Nacho
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>  Ignacio Sniechowski
>>>
>>> Prosavic SRL
>>>  Sent with Airmail
>>>
>>>
>>>
>>>
>>> On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org)
>>> wrote:
>>>
>>>>
>>>>
>>>> Hi Nacho,
>>>>
>>>>  On 11/1/2015 11:45 PM, nacho wrote:
>>>>>  > Hi Folks,
>>>>>  > I'm trying to add support for serializing instances of a class.
>>>>>  > I'm looking at System-Object Storage
>>>>>  > And in particular to the class SmartRefStream which seems to add
>>>>> that
>>>>>  > functionality. However, the class has no comments and no examples.
>>>>>  > Is there some example which uses this class? a short demo? an
>>>>> example?
>>>>>  > Thanks in advance!!
>>>>>  > best
>>>>>  > Nacho
>>>>>  >
>>>>
>>>>  Are we browsing the same system? SmartRefStream class comment is 6016
>>>>  characters here. Superclass ReferenceStream has a class comments of
>>>> 2875
>>>>  characters. DataStream and ReferenceStream have class methods that
>>>> start
>>>>  with 'example'. Looking for references to these classes also brings
>>>>  useful examples of usage.
>>>>
>>>>  In any case, the usual way to serialize classes is fileOut. Why
>>>> doesn't
>>>>  this work for you? What problem are you trying to solve?
>>>>
>>>>  Cheers,
>>>>  Juan Vuletich
>>>>
>>>>
>>>>
>>>
>
>



From dnorton at mindspring.com  Sat Nov  7 20:12:43 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 07 Nov 2015 21:12:43 -0500
Subject: [Cuis] BouncingAtomsMorph
Message-ID: <563EAF9B.28589.26788EA@dnorton.mindspring.com>

Hi Juan,

Thanks for fixing it so that #doOneCycleNow is no longer needed during initialization. 
The code reads much better.

Next time you build, please update from my repo:

	https://github.com/dhnorton/Cuis-Smalltalk-atoms

I made the following changes:

	- added #open method in case someone wants to bring it up from the browser 
or a workspace (old way no longer works).
	- HeaterCoolerAtoms no longer affect each other when they collide.
	- appearance tweaks to HeaterCoolerAtoms.
	- improved the initial movement and distribution of atoms.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151107/005040c8/attachment-0002.html>

From euanmee at gmail.com  Sun Nov  8 10:18:57 2015
From: euanmee at gmail.com (Euan Mee)
Date: Sun, 8 Nov 2015 16:18:57 +0000
Subject: [Cuis] Current state of activity
Message-ID: <CALsRT0m1o_aask7bPD6_RHq7dePHFJUBULKHKeqbW7+MavBgWg@mail.gmail.com>

Hi, I'm a newcomer to Cuis.

The main web-site was last updated in July 2013

How active is CUIS atm.?

Is it fair to characterise CUIS as a minimalist image for running on
top of the current latest Squeak VMs  e.g. Cog with Spur (and with the
Scorch and Sista upgrades once they are out?)

I'm looking to build Smalltalk apps to control, manage, set up and
distribute multi-platform mobile web-apps.

So what I'm looking for is a Smalltalk development environment and
development management environment
an http server and an https server
a multi-platform (Windows, Linux, MacOS) desktop GUI environment and
desktop GUI apps
a web framework

My ideal is a central desktop GUI app that can run from a Raspberry Pi
which is also running a webserver which hands out JS apps securely to
mobile devices.

I'm happy to with development work, or help backport necessary items
from Squeak/Pharo

Cheers,
     EuanM



From juan at jvuletich.org  Mon Nov  9 06:42:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 09 Nov 2015 09:42:43 -0300
Subject: [Cuis] Current state of activity
In-Reply-To: <CALsRT0m1o_aask7bPD6_RHq7dePHFJUBULKHKeqbW7+MavBgWg@mail.gmail.com>
References: <CALsRT0m1o_aask7bPD6_RHq7dePHFJUBULKHKeqbW7+MavBgWg@mail.gmail.com>
Message-ID: <564094C3.3070001@jvuletich.org>

Hi Euan,

On 11/8/2015 1:18 PM, Euan Mee wrote:
> Hi, I'm a newcomer to Cuis.

Welcome!

> The main web-site was last updated in July 2013
>
> How active is CUIS atm.?

Quite. See 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors 
. Mail lista rchives are at 
http://forum.world.st/Cuis-Smalltalk-f4632260.html .

> Is it fair to characterise CUIS as a minimalist image for running on
> top of the current latest Squeak VMs  e.g. Cog with Spur (and with the
> Scorch and Sista upgrades once they are out?)

Yes. In any case, see 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/GettingStarted-UsingGitAndCommandline.md 
and sibling files .

> I'm looking to build Smalltalk apps to control, manage, set up and
> distribute multi-platform mobile web-apps.
>
> So what I'm looking for is a Smalltalk development environment and
> development management environment
> an http server and an https server
> a multi-platform (Windows, Linux, MacOS) desktop GUI environment and
> desktop GUI apps
> a web framework
>
> My ideal is a central desktop GUI app that can run from a Raspberry Pi
> which is also running a webserver which hands out JS apps securely to
> mobile devices.

Interesting! Please keep us posted.

> I'm happy to with development work, or help backport necessary items
> from Squeak/Pharo
>

Great. As you progress, you'll find out about stuff you need to develop 
or port to Cuis. Contributions to the base image, or optional packages 
are all welcome (please remember that to be added to the main GitHub 
Cuis repo, all code needs to be MIT). Besides, here on the mail list, 
you can discuss any issues, ask for opinions or advice, or for existing 
code, etc.

> Cheers,
>       EuanM

Cheers,
Juan Vuletich



From 0800nacho at gmail.com  Mon Nov  9 18:53:16 2015
From: 0800nacho at gmail.com (nacho)
Date: Mon, 9 Nov 2015 16:53:16 -0800 (PST)
Subject: [Cuis] Symbols that start with and uppercase letter
Message-ID: <1447116796630-4860091.post@n4.nabble.com>

Hi Folks,
I'm trying to generate a collection from all instances of Symbol that begin
with a capital letter.
I know how to do this for one case:

| aSymbolArray aSymbol |

aSymbolArray _ Symbol allInstances.
aSymbol _ (aSymbolArray at: 1).
(aSymbol at: 1) isUppercase.

But I want to use something like collect:
| aSymbolArray |

aSymbolArray _ Symbol allInstances.
aSymbolArray collect: [ :a | | aSymbol | aSymbol _ aSymbolArray at: a.
(aSymbol at: 1) isUppercase].

But I'm lost.
Any help?
Thanks in advance!
best
Nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Symbols-that-start-with-and-uppercase-letter-tp4860091.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Mon Nov  9 21:12:26 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Mon, 9 Nov 2015 19:12:26 -0800
Subject: [Cuis] Symbols that start with and uppercase letter
In-Reply-To: <1447116796630-4860091.post@n4.nabble.com>
References: <1447116796630-4860091.post@n4.nabble.com>
Message-ID: <20151109191226.d42159dd728b6a0d5a7d1548@Whidbey.com>

On Mon, 9 Nov 2015 16:53:16 -0800 (PST)
nacho <0800nacho at gmail.com> wrote:

> Hi Folks,
> I'm trying to generate a collection from all instances of Symbol that begin
> with a capital letter.

Symbol allInstances select: [ :s | (s size > 0) and: [(s asString at: 1) isUppercase ]].

Cheers, 
-KenD



From euanmee at gmail.com  Wed Nov 11 08:13:57 2015
From: euanmee at gmail.com (Euan Mee)
Date: Wed, 11 Nov 2015 14:13:57 +0000
Subject: [Cuis] Simple Morphic
Message-ID: <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w@mail.gmail.com>

What is the current state of development of Simple Morph?

Is there any documentation on how to use it, or is it allInTheCode ?



From Ken.Dickey at Whidbey.com  Wed Nov 11 10:13:58 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Wed, 11 Nov 2015 08:13:58 -0800
Subject: [Cuis] Simple Morphic
In-Reply-To: <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w@mail.gmail.com>
References: <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w@mail.gmail.com>
Message-ID: <20151111081358.4a0291315670cadcdcead39f@Whidbey.com>

On Wed, 11 Nov 2015 14:13:57 +0000
Euan Mee <euanmee at gmail.com> wrote:

> What is the current state of development of Simple Morph?

I am not sure what you mean by Simple Morph.

Cuis has been taking steps toward Morphic3:

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md

The MorphExtension class was removed.  (We have Morph Properties).

Morphs have float rather than integer location coordinates.

Morph location is relative to their owner, not the screen.

These are relatively small changes to get used to.

More radical are some of the other simplifications in the system.

The best example here is probably Layout.

LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.

The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.

See LayoutMorph class examples.

If you git clone the Morphic-Misc1 package and load it you can get Layout editors:

Open a shell and cd to the directory containing Cuis-Smalltalk-Dev

  git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git

Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:

  Feature require:  'Morphic-Misc1'.

Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.  

Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.

If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.

> Is there any documentation on how to use it, or is it allInTheCode ?

See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.

-- 
-KenD



From euanmee at gmail.com  Wed Nov 11 13:02:54 2015
From: euanmee at gmail.com (Euan Mee)
Date: Wed, 11 Nov 2015 19:02:54 +0000
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
Message-ID: <CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>

Thanks for the pointer to Morphic3 and its documentation.  I'll try to
contribute more naive-user questions :-)

What is the state of development of Morphic3?
  - complete stable codebase?
  - stable codebase for substantial parts, with fuurther extensions in
development?
  - central aspects still under development?
  - a design concept, coding yet to begin?

e.g. The documentation starts off with "Morphic3 *will have* scalable
graphics".  This might mean that Morphic3 works now, but does not yet
have scalable graphics.  Or it might just mean Morphic3 does not (yet)
work.

Generally, whenever I'm looking at a new platform, system, or package,
I am initially looking for answers of the type
   "Can I use it now?
        No /
        Yes /
        Yes to an extent, but..."

I'm very happy to write up aspects of the system/package as
fully-formed documentation, especially documentation for naive-users.
Please let me know if there specific places where this help is
already-known to be particularly needed.

I look forward (in the long run?) to trying Cuis and Morphic3 on Raspberry Pi.

On 11 November 2015 at 18:00,  <cuis-request at jvuletich.org> wrote:
> Send Cuis mailing list submissions to
>         cuis at jvuletich.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> or, via email, send a message with subject or body 'help' to
>         cuis-request at jvuletich.org
>
> You can reach the person managing the list at
>         cuis-owner at jvuletich.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cuis digest..."
>
>
> Today's Topics:
>
>    1. Simple Morphic (Euan Mee)
>    2. Re: Simple Morphic (KenD)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 11 Nov 2015 14:13:57 +0000
> From: Euan Mee <euanmee at gmail.com>
> To: cuis at jvuletich.org
> Subject: [Cuis] Simple Morphic
> Message-ID:
>         <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> What is the current state of development of Simple Morph?
>
> Is there any documentation on how to use it, or is it allInTheCode ?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 11 Nov 2015 08:13:58 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: Euan Mee <euanmee at gmail.com>
> Subject: Re: [Cuis] Simple Morphic
> Message-ID: <20151111081358.4a0291315670cadcdcead39f at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Wed, 11 Nov 2015 14:13:57 +0000
> Euan Mee <euanmee at gmail.com> wrote:
>
>> What is the current state of development of Simple Morph?
>
> I am not sure what you mean by Simple Morph.
>
> Cuis has been taking steps toward Morphic3:
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>
> The MorphExtension class was removed.  (We have Morph Properties).
>
> Morphs have float rather than integer location coordinates.
>
> Morph location is relative to their owner, not the screen.
>
> These are relatively small changes to get used to.
>
> More radical are some of the other simplifications in the system.
>
> The best example here is probably Layout.
>
> LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.
>
> The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.
>
> See LayoutMorph class examples.
>
> If you git clone the Morphic-Misc1 package and load it you can get Layout editors:
>
> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>
>   git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>
> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:
>
>   Feature require:  'Morphic-Misc1'.
>
> Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>
> Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.
>
> If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.
>
>> Is there any documentation on how to use it, or is it allInTheCode ?
>
> See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.
>
> --
> -KenD
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 41, Issue 14
> ************************************



From euanmee at gmail.com  Wed Nov 11 13:41:24 2015
From: euanmee at gmail.com (Euan Mee)
Date: Wed, 11 Nov 2015 19:41:24 +0000
Subject: [Cuis] Simple Morphic
Message-ID: <CALsRT0=_8W2iHB4amNP_V95H0S_HhbtPYh8yjG_tcXgeQs2c8g@mail.gmail.com>

Thanks for the pointer to Morphic3 and its documentation.  I'll try to
contribute more naive-user questions :-)

What is the state of development of Morphic3?
  - complete stable codebase?
  - stable codebase for substantial parts, with fuurther extensions in
development?
  - central aspects still under development?
  - a design concept, coding yet to begin?

e.g. The documentation starts off with "Morphic3 *will have* scalable
graphics".  This might mean that Morphic3 works now, but does not yet
have scalable graphics.  Or it might just mean Morphic3 does not (yet)
work.

Generally, whenever I'm looking at a new platform, system, or package,
I am initially looking for answers of the type
   "Can I use it now?
        No /
        Yes /
        Yes to an extent, but..."

I'm very happy to write up aspects of the system/package as
fully-formed documentation, especially documentation for naive-users.
Please let me know if there specific places where this help is
already-known to be particularly needed.

I look forward (in the long run?) to trying Cuis and Morphic3 on Raspberry Pi.

In the meantime, I'm catching up on what's written at:
https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1
and
https://github.com/KenDickey/Cuis-Smalltalk-ColorEditor


On 11 November 2015 at 16:13, KenD <Ken.Dickey at whidbey.com> wrote:
> On Wed, 11 Nov 2015 14:13:57 +0000
> Euan Mee <euanmee at gmail.com> wrote:
>
>> What is the current state of development of Simple Morph?
>
> I am not sure what you mean by Simple Morph.
>
> Cuis has been taking steps toward Morphic3:
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>
> The MorphExtension class was removed.  (We have Morph Properties).
>
> Morphs have float rather than integer location coordinates.
>
> Morph location is relative to their owner, not the screen.
>
> These are relatively small changes to get used to.
>
> More radical are some of the other simplifications in the system.
>
> The best example here is probably Layout.
>
> LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.
>
> The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.
>
> See LayoutMorph class examples.
>
> If you git clone the Morphic-Misc1 package and load it you can get Layout editors:
>
> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>
>   git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>
> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:
>
>   Feature require:  'Morphic-Misc1'.
>
> Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>
> Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.
>
> If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.
>
>> Is there any documentation on how to use it, or is it allInTheCode ?
>
> See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.
>
> --
> -KenD



From Ken.Dickey at Whidbey.com  Wed Nov 11 17:56:37 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Wed, 11 Nov 2015 15:56:37 -0800
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
Message-ID: <20151111155637.a6fc5a89ab8ca768aa93510a@Whidbey.com>

On Wed, 11 Nov 2015 19:02:54 +0000
Euan Mee <euanmee at gmail.com> wrote:

> What is the state of development of Morphic3?

Juan is working on an optimized MorphicCanvas to replace BitBltCanvas.

There is some old, unoptimized sample code in Cuis-Smalltalk-Dev/Experimental which is not for the faint of heart.

Cuis currently uses BitBltCanvas, so the graphics do not yet scale.

Most of the other code works fine.  The location changes to Morph were a big step.

Juan has been slimming down the Cuis image so that it should be possible to rapidly grow when scalable.  Slim down .. grow .. scale  ;^)

Note the small number of classes in the base image:
"2236 eToys 5.0"
"2511 Squeak 4.4"
"2175 Squeak 4.5"
"2244 Squeak 5.0"
"3226 Pharo 2.0"
"4020 Pharo 3.0"
"4924 Pharo 4.0"
  vvv
" 504 Cuis 4.2 (rev 2568)"
  ^^^

Juan, anything to add/correct here?

-- 
-KenD



From pbpublist at gmail.com  Wed Nov 11 20:05:36 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 11 Nov 2015 21:05:36 -0500
Subject: [Cuis] Simple Morphic
In-Reply-To: <CALsRT0=_8W2iHB4amNP_V95H0S_HhbtPYh8yjG_tcXgeQs2c8g@mail.gmail.com>
References: <CALsRT0=_8W2iHB4amNP_V95H0S_HhbtPYh8yjG_tcXgeQs2c8g@mail.gmail.com>
Message-ID: <1447293936.10654.37.camel@gmail.com>

Hi Euan,

On Wed, 2015-11-11 at 19:41 +0000, Euan Mee wrote:
> I am initially looking for answers of the type
> ???"Can I use it now?
> ????????No /
> ????????Yes /
> ????????Yes to an extent, but..."
> 

The short answer is no. ?It's still at an experimental / work in
progress stage. ?As Ken mentioned, you can take a look at a snapshot of
the code but it's not in a state where you can enable it and have
things even mostly work or be productive with it as your GUI. ?There's
still much work to be done: functionality to be added, bugs to be
fixed, performance to be tuned etc.

Thanks,
Phil



From dnorton at mindspring.com  Thu Nov 12 18:46:26 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 12 Nov 2015 19:46:26 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <564532E2.5884.24794CB@dnorton.mindspring.com>

Hi Juan,

On 3 Nov 2015 at 14:58, Dan Norton wrote:

> Hi Juan,
> 
> As recommended by Ken and Hannes, the attached methods add the
> capability to bring up 
> the class comment browser from the help menu.
> 
> Sorry, but I still don't know how to prepend the thumbnail to the
> menu item :)
> 

Found how to do it! The attached change to Theme>>basicIcons makes the Help icon 
appear for Class Comment Browser. Please include in the next build.

Thanks,
 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Theme-basicIcons.zip
Type: application/zip
Size: 1289 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151112/435f9b9a/attachment-0002.zip>

From dnorton at mindspring.com  Fri Nov 13 11:58:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 13 Nov 2015 12:58:22 -0500
Subject: [Cuis] #when:send:to:
Message-ID: <564624BE.15549.F1568C@dnorton.mindspring.com>

Hello Everyone,

The following repo contains before and after examples of replacing the Dependency 
Mechanism with the Observer Pattern:

	https://github.com/dhnorton/Cuis-Smalltalk-light

Please take a look at this and tell me what needs to change. I'm trying to supply an example 
of the Observer Pattern so that others might use #when:send:to: with less difficulty than I 
experienced. There may be better examples but I picked one from the Blue Book.

It seems that #when:send:to: is necessary but not sufficient as a replacement for the 
Dependency Mechanism. In this example, it replaced #addDependent:, not #changed or 
#update and I am still not comfortable with how to choose the parameters. This may be an 
example of the difficulty in explaining the obvious, I'm not sure :-)

The #changed method was replaced with #triggerEvent: with a symbol argument which is 
referred to in one of the arguments of #when:send:to: and that's the only constraint AFAICT.

The #update: method was retained, as a convenience; it also needs to agree with one of the 
arguments of #when:send:to: and could have been different.

Please tell me if any of this is wrong. Thanks.

 - Dan 



From Ken.Dickey at Whidbey.com  Fri Nov 13 20:33:24 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Fri, 13 Nov 2015 18:33:24 -0800
Subject: [Cuis] #when:send:to:
In-Reply-To: <564624BE.15549.F1568C@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>
Message-ID: <20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>

On Fri, 13 Nov 2015 12:58:22 -0500
"Dan Norton" <dnorton at mindspring.com> wrote:

> Hello Everyone,
> 
> The following repo contains before and after examples of replacing the Dependency 
> Mechanism with the Observer Pattern:
> 
> 	https://github.com/dhnorton/Cuis-Smalltalk-light
> 
> Please take a look at this and tell me what needs to change.

Dan,

Good start.

I would suggest a deeper example.

Lights could be a model with a presenter (LightPanel) which shows the lights.  E.g. open a layout morph with a row of elipses (circles) which are red/green (or whatever) for off/on.

Clicking on a light changes the model (Lights subclass ActiveModel), which signals 
  triggerEvent: #colorChange with: aColor.

You can look in Morphic-Misc1 at RadioButtonMorph to see how to handle clicks.

Workspace code could also turn off/on or just toggle lights in the model, with the LightPanel presenter updating appropriately.

One can then add a bit of wackyness, like using different colors than red/green and the presenter will show the proper color..

$0.02.
-KenD 



From euanmee at gmail.com  Fri Nov 13 23:02:53 2015
From: euanmee at gmail.com (EuanM)
Date: Sat, 14 Nov 2015 05:02:53 +0000
Subject: [Cuis] New Introductory Tutorial
Message-ID: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>

I've created Yet Another Smalltalk First
Steps tutorial.

This is intended as one of a series.

It is designed to be cross-platform across

    Squeak 5
    Pharo 4
    Seaside 3.1
    Cuis
    Dolphin 6

If you have experience running any of these systems on Windows, Linux
or MacOS, please check to see if I have the instructions correct for
your chosen pairing of Smalltalk and OS platform.

(As you'll see when you look, I do not have detailed instructions for
aspects of MacOS).

The document is at:
http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html

(It's intended to move to a different blog after this review process).

I feel the need to do this as cross-Smalltalks tutorial because of
findings and 4 charts  I've placed at:
http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/mindshare-of-smalltalk-in-development.html

Essentially, Smalltalk mindshare and use is incredibly tiny, compared
to other languages in the same space.  (We all know this, but seeing
it represented graphically has a more visceral effect, IMO)

Aggregating interest in all the Smalltalks still does not bring more
than a tiny proportion of the interest in, and use of, Ruby.

In turn, Ruby is (quite understandably) small in comparison to JavaScript.

Comparing interest in any specific Smalltalk is, predictably, smaller
than the aggregate interest in Smalltalk.

Our community seems determined to split itself into smaller and
smaller sub-communities.  I think we do ourselves a disservice this
way.

My initial contribution will be to try to provide some explicitly
pan-Smalltalk beginners' tutorials, like this one.

Cheers, and happy Smalltalking,
     EuanM



From euanmee at gmail.com  Fri Nov 13 23:12:31 2015
From: euanmee at gmail.com (EuanM)
Date: Sat, 14 Nov 2015 05:12:31 +0000
Subject: [Cuis] One-Click Installer for Cuis
Message-ID: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>

I've just recently put-together a cross-platform Installation Tutorial
for beginners to Smalltalk.

I was keen to include Cuis in the exercise.

One thing that becomes clear in the comparison is that Cuis is a good
beginner's environment from the point of view of size and complexity
and their bearing in learnability.

It is however, the worst Smalltalk (of the 4 in the tutorial) to get
downloaded and installed.

This seems a pity.

Would anyone be willing to help me put together a One-Click Install
package, similar to Squeak's and Pharo's?

(My plan is to do the grunt-work, if other people are willing to
indulge my noob questions while I do it)

Is there a particular place that it could be hosted, once ready?

Would anyone disagree with a 6-monthly update cycle for the One-Click installer?

(Frequent enough to send a signal to interested beginners that the
project is alive and kicking.  Infrequent enough that there is not
much work to be done)

Cheers,
   Euan



From hari.balaraman at icloud.com  Sat Nov 14 08:37:34 2015
From: hari.balaraman at icloud.com (Hari Balaraman)
Date: Sat, 14 Nov 2015 11:37:34 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <563CF53B.5000107@jvuletich.org>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
Message-ID: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>

Hi Juan,

It was very nice to sit down and chat with you on the sidelines of the conference. Thank you for taking the time to look at my stuttering project and offer advice (on the history of projects, strangely, some others I talked to didn?t recognise the names Mark Guzdial and Bijan Parsia.) Although I missed first two days because of careless travel planning, I?m hoping FAST will put videos of the presentations on the website so I can catch up. 

The two people at Toronto Smalltalk Users Group I mentioned are Bob Nemec and Dave Mason, a professor at Ryerson University. My knowledge of the use of SmallTalk in the CS curriculum there is second or third-hand and so may not be current. I haven?t actually met them as the one Monday evening I was able to make it to TSUG, I was late and both of them had left by then. :)

Thanks for the tip on visiting the bookshops on Avenida Corrientes in this amazing city. I passed it on the way home and realised I haven?t gone down this street in my wanderings. If you are going to be in the city before Tuesday afternoon, and are free and bored, do let me know.

Best regards,

Hari
>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org <mailto:juan at jvuletich.org>) wrote:
>> 
>>> Hi Hari,
>>> 
>>> I'll be there. Let's meet then.
>>> 
>>> Anybody else?
>>> 
>>> Cheers,
>>> Juan Vuletich
>>> 
>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>> 
>>>> If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
>>>> Best regards,
>>>> Hari
>>>> 
>>>> _______________________________________________
>>>> Cuis mailing list
>>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>>> 
>>> _______________________________________________ 
>>> Cuis mailing list 
>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org> 
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151114/17eb3e43/attachment-0002.html>

From 0800nacho at gmail.com  Sat Nov 14 09:45:12 2015
From: 0800nacho at gmail.com (nacho)
Date: Sat, 14 Nov 2015 07:45:12 -0800 (PST)
Subject: [Cuis] FAST conference
In-Reply-To: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
References: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
Message-ID: <1447515912161-4861043.post@n4.nabble.com>

I agree with Hari,
It was very nice to meet you Juan.
Thanks for your work and advice.
Best
Nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/FAST-conference-tp4859418p4861043.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Sat Nov 14 10:09:22 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sat, 14 Nov 2015 08:09:22 -0800
Subject: [Cuis] New Introductory Tutorial
In-Reply-To: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
References: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
Message-ID: <20151114080922.9fc084ad463f841976311bb7@Whidbey.com>

On Sat, 14 Nov 2015 05:02:53 +0000
EuanM <euanmee at gmail.com> wrote:

> I've created Yet Another Smalltalk First
> Steps tutorial.
...
> If you have experience running any of these systems on Windows, Linux
> or MacOS, please check to see if I have the instructions correct for
> your chosen pairing of Smalltalk and OS platform.

On Linux, Cuis works fine from the command line once the proper SqueakVM is installed.

E.g. in the Cuis-Smalltalk-Dev directory
   squeak  Cuis4.2-2571.image

> The document is at:
> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html

The different Squeak VMs are transition points and might need some explanation.

The stack-interpreter VM is a traditional bytecode interpreter.

Cog does just-in-time (JIT) compilation to native code for faster execution.

Spur is a new memory model which simplifies object layouts and is common between 32 and 64 bit memory architectures.  Because of object format/layout changes Spur images must be run on a Spur VMs and non-Spur images on a non-Spur VM.  You have to match the VM to the object format.

As far as I am aware, there is no Spur image for Cuis yet.  We need to write a tool to read a current image and write it out in Spur format.  Spur code is still evolving rapidly, so writing the  image translation has not been a priority for us.  Now that Squeak 5.0 is out (the 4.x series used the old format, 5.0 uses Spur) things are probably stable enough that we can get to this.

-- 

One side note is that none of the Cog (JIT) VMs run on ARM Chromebooks under Chrome OS.  I don't run Intel, but suspect the JIT is broken there as well.  This apparently has to do with the tightening up of code security policies in the Chromium OS.  As JIT means writing data, then executing this as code, there is an obvious security hole to be addressed.

It appears that there are are/should be rubrics/rules which allow JIT.  The V8 JavaScript VM does JIT on ChromeOS.  But it takes time to dig through the megabytes of code and docs to get at the details.  This is in progress, but there is not much resource (people time) to devote to it.

FYI,
-KenD



From edgardec2005 at gmail.com  Sat Nov 14 15:29:34 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Sat, 14 Nov 2015 18:29:34 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
Message-ID: <BF8DA200-D5CF-424C-8168-F5568D5C2253@gmail.com>

Also i say very, very thanks for all your talks, time to listening my crazy ideas and tu calidez como ser humano
Too bad also  i going without plan .
We should schedule some hangouts when yo have the time.
Wish know Nacho and Hari , look for me on Facebook and start  Cuis Friendship
Again thanks Juan.




> On Nov 14, 2015, at 11:37 AM, Hari Balaraman <hari.balaraman at icloud.com> wrote:
> 
> Hi Juan,
> 
> It was very nice to sit down and chat with you on the sidelines of the conference. Thank you for taking the time to look at my stuttering project and offer advice (on the history of projects, strangely, some others I talked to didn?t recognise the names Mark Guzdial and Bijan Parsia.) Although I missed first two days because of careless travel planning, I?m hoping FAST will put videos of the presentations on the website so I can catch up. 
> 
> The two people at Toronto Smalltalk Users Group I mentioned are Bob Nemec and Dave Mason, a professor at Ryerson University. My knowledge of the use of SmallTalk in the CS curriculum there is second or third-hand and so may not be current. I haven?t actually met them as the one Monday evening I was able to make it to TSUG, I was late and both of them had left by then. :)
> 
> Thanks for the tip on visiting the bookshops on Avenida Corrientes in this amazing city. I passed it on the way home and realised I haven?t gone down this street in my wanderings. If you are going to be in the city before Tuesday afternoon, and are free and bored, do let me know.
> 
> Best regards,
> 
> Hari
>>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org <mailto:juan at jvuletich.org>) wrote:
>>> 
>>>> Hi Hari,
>>>> 
>>>> I'll be there. Let's meet then.
>>>> 
>>>> Anybody else?
>>>> 
>>>> Cheers,
>>>> Juan Vuletich
>>>> 
>>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>>> 
>>>>> If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
>>>>> Best regards,
>>>>> Hari
>>>>> 
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>>>> 
>>>> _______________________________________________ 
>>>> Cuis mailing list 
>>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org> 
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> 
>> 
>> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151114/e42bf08f/attachment-0002.html>

From dnorton at mindspring.com  Sun Nov 15 12:47:00 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 15 Nov 2015 13:47:00 -0500
Subject: [Cuis] #when:send:to:
In-Reply-To: <20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>
Message-ID: <5648D324.31295.859AEA@dnorton.mindspring.com>

On 13 Nov 2015 at 18:33, KenD wrote:

> On Fri, 13 Nov 2015 12:58:22 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> > Hello Everyone,
> > 
> > The following repo contains before and after examples of replacing
> the Dependency 
> > Mechanism with the Observer Pattern:
> > 
> > 	https://github.com/dhnorton/Cuis-Smalltalk-light
> > 
> > Please take a look at this and tell me what needs to change.
> 
> Dan,
> 
> Good start.
> 
> I would suggest a deeper example.
> 

Hmm, I made it stark simple in order to focus on the basics. However, a couple of 
possibilities could be: a 3-bulb traffic light with a change button (incremental add-on), or a 
drag race tree (elaborate).

 - Dan

> Lights could be a model with a presenter (LightPanel) which shows
> the lights.  E.g. open a layout morph with a row of elipses
> (circles) which are red/green (or whatever) for off/on.
> 
> Clicking on a light changes the model (Lights subclass ActiveModel),
> which signals 
>   triggerEvent: #colorChange with: aColor.
> 
> You can look in Morphic-Misc1 at RadioButtonMorph to see how to
> handle clicks.
> 
> Workspace code could also turn off/on or just toggle lights in the
> model, with the LightPanel presenter updating appropriately.
> 
> One can then add a bit of wackyness, like using different colors
> than red/green and the presenter will show the proper color..
> 
> $0.02.
> -KenD 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From Ken.Dickey at Whidbey.com  Sun Nov 15 14:35:54 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sun, 15 Nov 2015 12:35:54 -0800
Subject: [Cuis] #when:send:to:
In-Reply-To: <5648D324.31295.859AEA@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>
	<20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>
	<5648D324.31295.859AEA@dnorton.mindspring.com>
Message-ID: <20151115123554.1a6ce6591f522779d96f2aa6@Whidbey.com>

On Sun, 15 Nov 2015 13:47:00 -0500
"Dan Norton" <dnorton at mindspring.com> wrote:


> Hmm, I made it stark simple in order to focus on the basics. 

If a "light" does not have a visual representation, I would call it a "switch".

$0.02 
-KenD



From dnorton at mindspring.com  Sun Nov 15 21:20:16 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 15 Nov 2015 22:20:16 -0500
Subject: [Cuis] #when:send:to:
In-Reply-To: <20151115123554.1a6ce6591f522779d96f2aa6@Whidbey.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<5648D324.31295.859AEA@dnorton.mindspring.com>,
	<20151115123554.1a6ce6591f522779d96f2aa6@Whidbey.com>
Message-ID: <56494B70.22263.25B83DB@dnorton.mindspring.com>

On 15 Nov 2015 at 12:35, KenD wrote:

> On Sun, 15 Nov 2015 13:47:00 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> 
> > Hmm, I made it stark simple in order to focus on the basics. 
> 
> If a "light" does not have a visual representation, I would call it
> a "switch".
> 

Good point. I see the light of that; however, stark though it be, at least it lets you see state in 
the Transcript. The Blue Book used Light and TrafficLight then left you to use inspectors I 
presume. They didn't say :)

 - Dan



From juan at jvuletich.org  Mon Nov 16 12:53:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 15:53:49 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
Message-ID: <564A263D.9000808@jvuletich.org>

Hi Hari,

On 11/14/2015 11:37 AM, Hari Balaraman wrote:
> Hi Juan,
>
> It was very nice to sit down and chat with you on the sidelines of the 
> conference. Thank you for taking the time to look at my stuttering 
> project and offer advice (on the history of projects, strangely, some 
> others I talked to didn?t recognise the names Mark Guzdial and Bijan 
> Parsia.) Although I missed first two days because of careless travel 
> planning, I?m hoping FAST will put videos of the presentations on the 
> website so I can catch up.

It was my pleasure!

> The two people at Toronto Smalltalk Users Group I mentioned are Bob 
> Nemec and Dave Mason, a professor at Ryerson University. My knowledge 
> of the use of SmallTalk in the CS curriculum there is second or 
> third-hand and so may not be current. I haven?t actually met them as 
> the one Monday evening I was able to make it to TSUG, I was late and 
> both of them had left by then. :)

Nice to know, thanks.

> Thanks for the tip on visiting the bookshops on Avenida Corrientes in 
> this amazing city. I passed it on the way home and realised I haven?t 
> gone down this street in my wanderings. If you are going to be in the 
> city before Tuesday afternoon, and are free and bored, do let me know.

Well, during the weekend I tried to spend some time with family. Also on 
Saturday we spent time with other fellow Smalltalkers, including the 
organizers, and their families. So, I only read this today. If you are 
still around on Tuesday evening, we can drink some beer, coffee, 
whatever, after office. If you leave on Tuesday afternoon, maybe we can 
have lunch tomorrow Tuesday. The rest of the day I'm at work, as you 
would expect... :)

Cheers,
Juan Vuletich

> Best regards,
>
> Hari
>>>
>>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org 
>>> <mailto:juan at jvuletich.org>) wrote:
>>>
>>>> Hi Hari,
>>>>
>>>> I'll be there. Let's meet then.
>>>>
>>>> Anybody else?
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>>> If any of you are attending the FAST conference in Buenos Aires in 
>>>>> a week or so, I look forward to meeting you face to face.
>>>>> Best regards,
>>>>> Hari
>>>>>
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>
>>>> _______________________________________________
>>>> Cuis mailing list
>>>> Cuis at jvuletich.org
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/1347cb49/attachment-0002.html>

From juan at jvuletich.org  Mon Nov 16 14:04:37 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 17:04:37 -0300
Subject: [Cuis] BouncingAtomsMorph
In-Reply-To: <563EAF9B.28589.26788EA@dnorton.mindspring.com>
References: <563EAF9B.28589.26788EA@dnorton.mindspring.com>
Message-ID: <564A36D5.5010109@jvuletich.org>

On 11/7/2015 11:12 PM, Dan Norton wrote:
> Hi Juan,
>
> Thanks for fixing it so that #doOneCycleNow is no longer needed during 
> initialization. The code reads much better.
>
>
> Next time you build, please update from my repo:
>
>            https://github.com/dhnorton/Cuis-Smalltalk-atoms
>
> I made the following changes:
>
>            - added #open method in case someone wants to bring it up 
> from the browser or a workspace (old way no longer works).
>            - HeaterCoolerAtoms no longer affect each other when they 
> collide.
>            - appearance tweaks to HeaterCoolerAtoms.
>            - improved the initial movement and distribution of atoms.
>
>  - Dan
>

I'll do a commit during this week, and this will be included. Thank you!

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/b5b4538a/attachment-0002.html>

From juan at jvuletich.org  Mon Nov 16 14:25:50 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 17:25:50 -0300
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
Message-ID: <564A3BCE.9090409@jvuletich.org>

Hi Euan,

On 11/11/2015 4:02 PM, Euan Mee wrote:
> Thanks for the pointer to Morphic3 and its documentation.  I'll try to
> contribute more naive-user questions :-)
>
> What is the state of development of Morphic3?
>    - complete stable codebase?
>    - stable codebase for substantial parts, with fuurther extensions in
> development?
>    - central aspects still under development?
>    - a design concept, coding yet to begin?

I think "central aspects still under development" is a fair way to say it.
If you want to take a look, it is in the 'Experimental' folder. Feel 
free to ask questions.

> e.g. The documentation starts off with "Morphic3 *will have* scalable
> graphics".  This might mean that Morphic3 works now, but does not yet
> have scalable graphics.  Or it might just mean Morphic3 does not (yet)
> work.
>

Well, we have been evolving Morphic in Cuis, towards the direction shown 
by some experiments I did in 2009, for quite some time. This is 
currently using BitBltCanvas to draw, that can not do proper scalable 
graphics. The Morphic3Canvas in 'Experimental' can do this.

> Generally, whenever I'm looking at a new platform, system, or package,
> I am initially looking for answers of the type
>     "Can I use it now?
>          No /
>          Yes /
>          Yes to an extent, but..."
>
> I'm very happy to write up aspects of the system/package as
> fully-formed documentation, especially documentation for naive-users.
> Please let me know if there specific places where this help is
> already-known to be particularly needed.

Morphic 3 is ready to be studied by really interested ones. Not at all 
ready for a naive- user. On the question of where this help is needed, 
I'm not the best to answer. Maybe others in the community answer this, 
or, just use the system for some project, and you'll quickly find the 
places where a new user (you!) could use better documentation.

> I look forward (in the long run?) to trying Cuis and Morphic3 on Raspberry Pi.
>

Well, Morphic 3 might be more expensive than BitBltCanvas, and I don't 
know if it will run reasonably well on a Pi....

Cheers,
Juan Vuletich

> On 11 November 2015 at 18:00,<cuis-request at jvuletich.org>  wrote:
>> Send Cuis mailing list submissions to
>>          cuis at jvuletich.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>          http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> or, via email, send a message with subject or body 'help' to
>>          cuis-request at jvuletich.org
>>
>> You can reach the person managing the list at
>>          cuis-owner at jvuletich.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Cuis digest..."
>>
>>
>> Today's Topics:
>>
>>     1. Simple Morphic (Euan Mee)
>>     2. Re: Simple Morphic (KenD)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 11 Nov 2015 14:13:57 +0000
>> From: Euan Mee<euanmee at gmail.com>
>> To: cuis at jvuletich.org
>> Subject: [Cuis] Simple Morphic
>> Message-ID:
>>          <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> What is the current state of development of Simple Morph?
>>
>> Is there any documentation on how to use it, or is it allInTheCode ?
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 11 Nov 2015 08:13:58 -0800
>> From: KenD<Ken.Dickey at Whidbey.com>
>> To: Discussion of Cuis Smalltalk<cuis at jvuletich.org>
>> Cc: Euan Mee<euanmee at gmail.com>
>> Subject: Re: [Cuis] Simple Morphic
>> Message-ID:<20151111081358.4a0291315670cadcdcead39f at Whidbey.com>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> On Wed, 11 Nov 2015 14:13:57 +0000
>> Euan Mee<euanmee at gmail.com>  wrote:
>>
>>> What is the current state of development of Simple Morph?
>> I am not sure what you mean by Simple Morph.
>>
>> Cuis has been taking steps toward Morphic3:
>>
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>>
>> The MorphExtension class was removed.  (We have Morph Properties).
>>
>> Morphs have float rather than integer location coordinates.
>>
>> Morph location is relative to their owner, not the screen.
>>
>> These are relatively small changes to get used to.
>>
>> More radical are some of the other simplifications in the system.
>>
>> The best example here is probably Layout.
>>
>> LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.
>>
>> The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.
>>
>> See LayoutMorph class examples.
>>
>> If you git clone the Morphic-Misc1 package and load it you can get Layout editors:
>>
>> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>>
>>    git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>>
>> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:
>>
>>    Feature require:  'Morphic-Misc1'.
>>
>> Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>>
>> Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.
>>
>> If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.
>>
>>> Is there any documentation on how to use it, or is it allInTheCode ?
>> See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.
>>
>> --
>> -KenD
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>> ------------------------------
>>
>> End of Cuis Digest, Vol 41, Issue 14
>> ************************************
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Mon Nov 16 14:27:35 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 17:27:35 -0300
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <20151111155637.a6fc5a89ab8ca768aa93510a@Whidbey.com>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
	<20151111155637.a6fc5a89ab8ca768aa93510a@Whidbey.com>
Message-ID: <564A3C37.8050404@jvuletich.org>

On 11/11/2015 8:56 PM, KenD wrote:
> On Wed, 11 Nov 2015 19:02:54 +0000
> Euan Mee<euanmee at gmail.com>  wrote:
>
>> What is the state of development of Morphic3?
> Juan is working on an optimized MorphicCanvas to replace BitBltCanvas.
>
> There is some old, unoptimized sample code in Cuis-Smalltalk-Dev/Experimental which is not for the faint of heart.
>
> Cuis currently uses BitBltCanvas, so the graphics do not yet scale.
>
> Most of the other code works fine.  The location changes to Morph were a big step.
>
> Juan has been slimming down the Cuis image so that it should be possible to rapidly grow when scalable.  Slim down .. grow .. scale  ;^)
>
> Note the small number of classes in the base image:
> "2236 eToys 5.0"
> "2511 Squeak 4.4"
> "2175 Squeak 4.5"
> "2244 Squeak 5.0"
> "3226 Pharo 2.0"
> "4020 Pharo 3.0"
> "4924 Pharo 4.0"
>    vvv
> " 504 Cuis 4.2 (rev 2568)"
>    ^^^
>
> Juan, anything to add/correct here?

No :) All you say is right. Just that besides scaling, also rotation is 
missing in BitBltCanvas.

Cheers,
Juan Vuletich



From dnorton at mindspring.com  Mon Nov 16 16:30:49 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 16 Nov 2015 17:30:49 -0500
Subject: [Cuis] Patterns
In-Reply-To: <563CF147.306@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>,
	<563CF147.306@jvuletich.org>
Message-ID: <564A5919.15040.19C7009@dnorton.mindspring.com>

On 6 Nov 2015 at 15:28, Juan Vuletich wrote Re: [Cuis] ColorEditor updated:

> Hi Ken,
> 
> On 11/2/2015 8:27 PM, KenD wrote:
> > ...
> >
> > However, class comments are not usually where design patterns show
> up.  8^|
> >
> > In the case of #when:send:to: I suggest a slightly larger
> discussion around building paned windows which update dependent
> panes.
> >
> > What constitutes good style?  What code patterns help?
> >
> > Think "Useful Code Patterns" to augment "Useful Expressions".
> 
> In 2009 I wrote 
> http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgram
> ming.txt 
> and 
> http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.tx
> t . 
> I've had the idea of making all the GUI code in Cuis follow this
> style. 
> But time is always short...
> 

As one who benefits greatly from studying other people's code ;-) I favor copy and paste over 
reading prose. The most useful "Useful Code Patterns" would be something in a code 
window like "Useful Expressions" IMO. But where UE is code line oriented, it needs to be 
class and method orented.  It would be heavily commented as to what is on a line, or in a 
method, and why, because this is a big problem with Smalltalk in many cases. Once pasted, 
the comments would be customized or removed.

I started a package with a model and a view, trying to be minimalist about getting them to 
simply put up a window without bringing up the debugger. There are lots of comments. 
Please take a look and give me yours.

	https://github.com/dhnorton/Cuis-Smalltalk-patterns

It tries to be the most efficient, direct, and simple pattern for opening a view on a model in 
Cuis. It's deliberately not glitzy. Glitz is added by the user. Next, I plan to incorporate 
#when:send:to: fundamentals.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/4a178960/attachment-0002.html>

From luchiano at gmail.com  Mon Nov 16 16:46:58 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Mon, 16 Nov 2015 22:46:58 +0000
Subject: [Cuis] Patterns
In-Reply-To: <564A5919.15040.19C7009@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
Message-ID: <CAL5GDyqTYQd0TYrbS969W=WbGK_PCKQHmytud+PhG96aQs85QQ@mail.gmail.com>

Excelent, this exampe has exactly what I wanted yesterday. Models should
implement #open for instance creation. Also, all the different ways we are
currently using to open windows should be cleaned up and unified... but
I'll be happy with #open in every model at least (and always returning the
window).

Also Smalltalk|save, saveAs, quit.

I don't use menues much, I rather doIt ;)
Luciano

On Mon, Nov 16, 2015 at 10:30 PM, Dan Norton <dnorton at mindspring.com> wrote:

> On 6 Nov 2015 at 15:28, Juan Vuletich wrote Re: [Cuis] ColorEditor updated:
>
> > Hi Ken,
> >
> > On 11/2/2015 8:27 PM, KenD wrote:
> > > ...
> > >
> > > However, class comments are not usually where design patterns show
> > up.  8^|
> > >
> > > In the case of #when:send:to: I suggest a slightly larger
> > discussion around building paned windows which update dependent
> > panes.
> > >
> > > What constitutes good style?  What code patterns help?
> > >
> > > Think "Useful Code Patterns" to augment "Useful Expressions".
> >
> > In 2009 I wrote
> > http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgram
> > ming.txt
> > and
> > http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.tx
> > t .
> > I've had the idea of making all the GUI code in Cuis follow this
> > style.
> > But time is always short...
> >
>
> As one who benefits greatly from studying other people's code ;-) I favor
> copy and paste over reading prose. The most useful "Useful Code Patterns"
> would be something in a code window like "Useful Expressions" IMO. But
> where UE is code line oriented, it needs to be class and method orented.
> It would be heavily commented as to what is on a line, or in a method, and
> why, because this is a big problem with Smalltalk in many cases. Once
> pasted, the comments would be customized or removed.
>
> I started a package with a model and a view, trying to be minimalist about
> getting them to simply put up a window without bringing up the debugger.
> There are lots of comments. Please take a look and give me yours.
>
>            https://github.com/dhnorton/Cuis-Smalltalk-patterns
>
> It tries to be the most efficient, direct, and simple pattern for opening
> a view on a model in Cuis. It's deliberately not glitzy. Glitz is added by
> the user. Next, I plan to incorporate #when:send:to: fundamentals.
>
>  - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/d69918db/attachment-0002.html>

From juan at jvuletich.org  Mon Nov 16 18:11:51 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:11:51 -0300
Subject: [Cuis] #when:send:to:
In-Reply-To: <564624BE.15549.F1568C@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>
Message-ID: <564A70C7.4040005@jvuletich.org>

Hi Dan,

On 13/11/2015 02:58 p.m., Dan Norton wrote:
> Hello Everyone,
>
> The following repo contains before and after examples of replacing the Dependency
> Mechanism with the Observer Pattern:
>
> 	https://github.com/dhnorton/Cuis-Smalltalk-light
>
> Please take a look at this and tell me what needs to change. I'm trying to supply an example
> of the Observer Pattern so that others might use #when:send:to: with less difficulty than I
> experienced. There may be better examples but I picked one from the Blue Book.
>
> It seems that #when:send:to: is necessary but not sufficient as a replacement for the
> Dependency Mechanism. In this example, it replaced #addDependent:, not #changed or
> #update and I am still not comfortable with how to choose the parameters. This may be an
> example of the difficulty in explaining the obvious, I'm not sure :-)
>
> The #changed method was replaced with #triggerEvent: with a symbol argument which is
> referred to in one of the arguments of #when:send:to: and that's the only constraint AFAICT.
>
> The #update: method was retained, as a convenience; it also needs to agree with one of the
> arguments of #when:send:to: and could have been different.
>
> Please tell me if any of this is wrong. Thanks.
>
>   - Dan

I think the idea of #when:send:to: is to use event names and actions 
that make sense to your model (and not #changed and #update:). For 
instance, in Example2>>#lights:, I would change the line:

         eachLight when: #changed send: #update: to: dependentLight 
with: self

to read:

         eachLight when: #turnedOn send: #turnOff to: dependentLight

And, in #turnOn, make it do:

         self triggerEvent: #turnedOn


Doesn't this read better?

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Nov 16 18:42:22 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:42:22 -0300
Subject: [Cuis] New Introductory Tutorial
In-Reply-To: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
References: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
Message-ID: <564A77EE.6060802@jvuletich.org>

Hi EuanM,

This is a great initiative. Thanks for including Cuis in the bunch!

Cheers,
Juan Vuletich

On 14/11/2015 02:02 a.m., EuanM wrote:
> I've created Yet Another Smalltalk First
> Steps tutorial.
>
> This is intended as one of a series.
>
> It is designed to be cross-platform across
>
>      Squeak 5
>      Pharo 4
>      Seaside 3.1
>      Cuis
>      Dolphin 6
>
> If you have experience running any of these systems on Windows, Linux
> or MacOS, please check to see if I have the instructions correct for
> your chosen pairing of Smalltalk and OS platform.
>
> (As you'll see when you look, I do not have detailed instructions for
> aspects of MacOS).
>
> The document is at:
> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html
>
> (It's intended to move to a different blog after this review process).
>
> I feel the need to do this as cross-Smalltalks tutorial because of
> findings and 4 charts  I've placed at:
> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/mindshare-of-smalltalk-in-development.html
>
> Essentially, Smalltalk mindshare and use is incredibly tiny, compared
> to other languages in the same space.  (We all know this, but seeing
> it represented graphically has a more visceral effect, IMO)
>
> Aggregating interest in all the Smalltalks still does not bring more
> than a tiny proportion of the interest in, and use of, Ruby.
>
> In turn, Ruby is (quite understandably) small in comparison to JavaScript.
>
> Comparing interest in any specific Smalltalk is, predictably, smaller
> than the aggregate interest in Smalltalk.
>
> Our community seems determined to split itself into smaller and
> smaller sub-communities.  I think we do ourselves a disservice this
> way.
>
> My initial contribution will be to try to provide some explicitly
> pan-Smalltalk beginners' tutorials, like this one.
>
> Cheers, and happy Smalltalking,
>       EuanM
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Mon Nov 16 18:47:33 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:47:33 -0300
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
Message-ID: <564A7925.4060103@jvuletich.org>

On 14/11/2015 02:12 a.m., EuanM wrote:
> I've just recently put-together a cross-platform Installation Tutorial
> for beginners to Smalltalk.
>
> I was keen to include Cuis in the exercise.
>

Again, thank you for this.

> One thing that becomes clear in the comparison is that Cuis is a good
> beginner's environment from the point of view of size and complexity
> and their bearing in learnability.
>
> It is however, the worst Smalltalk (of the 4 in the tutorial) to get
> downloaded and installed.
>
> This seems a pity.

Please take a look at 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Documentation 
. There are three 'Getting Started' guides, for different OSes and user 
style / preferences. They were tried (as described) in Linux, MacOsX and 
Windows.

> Would anyone be willing to help me put together a One-Click Install
> package, similar to Squeak's and Pharo's?
>
> (My plan is to do the grunt-work, if other people are willing to
> indulge my noob questions while I do it)

I believe that if you take the One-Click for Squeak or Pharo, and 
replace the image with a Cuis image, it should work.

> Is there a particular place that it could be hosted, once ready?
>
> Would anyone disagree with a 6-monthly update cycle for the One-Click installer?
>
> (Frequent enough to send a signal to interested beginners that the
> project is alive and kicking.  Infrequent enough that there is not
> much work to be done)

Yep, this sounds great. The natural place is 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev isn't it?


> Cheers,
>     Euan

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Nov 16 18:51:30 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:51:30 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <1447515912161-4861043.post@n4.nabble.com>
References: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>	<563CF22E.4080804@jvuletich.org>	<etPan.563cf40e.77bd141b.a58@Unix.local>	<563CF53B.5000107@jvuletich.org>	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
	<1447515912161-4861043.post@n4.nabble.com>
Message-ID: <564A7A12.2070908@jvuletich.org>

Thank you! It was a pleasure to meet you all at the conference.

Cheers,
Juan Vuletich

On 14/11/2015 12:45 p.m., nacho wrote:
> I agree with Hari,
> It was very nice to meet you Juan.
> Thanks for your work and advice.
> Best
> Nacho
>
>
>
>
> -----
> Nacho
> Smalltalker apprentice.
> Buenos Aires, Argentina.



From juan at jvuletich.org  Mon Nov 16 18:53:33 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:53:33 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <BF8DA200-D5CF-424C-8168-F5568D5C2253@gmail.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>	<563CF22E.4080804@jvuletich.org>	<etPan.563cf40e.77bd141b.a58@Unix.local>	<563CF53B.5000107@jvuletich.org>	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
	<BF8DA200-D5CF-424C-8168-F5568D5C2253@gmail.com>
Message-ID: <564A7A8D.5000101@jvuletich.org>

Thank you too, Edgar. I know you made quite an effort to be there!

I don't think not having a plan is too bad. The important thing is to 
enjoy the experience!

And sure, we can talk any time.

Cheers,
Juan Vuletich

On 14/11/2015 06:29 p.m., Edgar De Cleene wrote:
> Also i say very, very thanks for all your talks, time to listening my 
> crazy ideas and tu calidez como ser humano
> Too bad also  i going without plan .
> We should schedule some hangouts when yo have the time.
> Wish know Nacho and Hari , look for me on Facebook and start  Cuis 
> Friendship
> Again thanks Juan.
>
>
>
>
>> On Nov 14, 2015, at 11:37 AM, Hari Balaraman 
>> <hari.balaraman at icloud.com <mailto:hari.balaraman at icloud.com>> wrote:
>>
>> Hi Juan,
>>
>> It was very nice to sit down and chat with you on the sidelines of 
>> the conference. Thank you for taking the time to look at my 
>> stuttering project and offer advice (on the history of projects, 
>> strangely, some others I talked to didn?t recognise the names Mark 
>> Guzdial and Bijan Parsia.) Although I missed first two days because 
>> of careless travel planning, I?m hoping FAST will put videos of the 
>> presentations on the website so I can catch up.
>>
>> The two people at Toronto Smalltalk Users Group I mentioned are Bob 
>> Nemec and Dave Mason, a professor at Ryerson University. My knowledge 
>> of the use of SmallTalk in the CS curriculum there is second or 
>> third-hand and so may not be current. I haven?t actually met them as 
>> the one Monday evening I was able to make it to TSUG, I was late and 
>> both of them had left by then. :)
>>
>> Thanks for the tip on visiting the bookshops on Avenida Corrientes in 
>> this amazing city. I passed it on the way home and realised I haven?t 
>> gone down this street in my wanderings. If you are going to be in the 
>> city before Tuesday afternoon, and are free and bored, do let me know.
>>
>> Best regards,
>>
>> Hari
>>>>
>>>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich 
>>>> (juan at jvuletich.org <mailto:juan at jvuletich.org>) wrote:
>>>>
>>>>> Hi Hari,
>>>>>
>>>>> I'll be there. Let's meet then.
>>>>>
>>>>> Anybody else?
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>>>> If any of you are attending the FAST conference in Buenos Aires 
>>>>>> in a week or so, I look forward to meeting you face to face.
>>>>>> Best regards,
>>>>>> Hari
>>>>>>
>>>>>> _______________________________________________
>>>>>> Cuis mailing list
>>>>>> Cuis at jvuletich.org
>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/4eea6045/attachment-0002.html>

From juan at jvuletich.org  Mon Nov 16 19:06:25 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 22:06:25 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564A5919.15040.19C7009@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>,
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
Message-ID: <564A7D91.6080102@jvuletich.org>

Hi Dan,

On 16/11/2015 07:30 p.m., Dan Norton wrote:
>
> As one who benefits greatly from studying other people's code ;-) I 
> favor copy and paste over reading prose. The most useful "Useful Code 
> Patterns" would be something in a code window like "Useful 
> Expressions" IMO. But where UE is code line oriented, it needs to be 
> class and method orented.  It would be heavily commented as to what is 
> on a line, or in a method, and why, because this is a big problem with 
> Smalltalk in many cases. Once pasted, the comments would be customized 
> or removed.

Ok, it is a good idea.

> I started a package with a model and a view, trying to be minimalist 
> about getting them to simply put up a window without bringing up the 
> debugger. There are lots of comments. Please take a look and give me 
> yours.
>
>            https://github.com/dhnorton/Cuis-Smalltalk-patterns
>
> It tries to be the most efficient, direct, and simple pattern for 
> opening a view on a model in Cuis. It's deliberately not glitzy. Glitz 
> is added by the user. Next, I plan to incorporate #when:send:to: 
> fundamentals.
>
>  - Dan

Well, I don't like the #open method in the model. The idea of View / 
Model separation is that views know about models, but models don't know 
about views. A Model should exist independently of being used from 
Morphic, MVC, Seaside, or any other UI framework. It could live, for 
example, in a Gemstone database with no UI at all. Or ir could travel to 
and from other systems, like VA Smalltalk, where the UI framework is 
completely different from Cuis'.

I think it is better for the View to start it all.

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/87361800/attachment-0002.html>

From garduino at gmail.com  Mon Nov 16 19:47:43 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Mon, 16 Nov 2015 22:47:43 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564A7D91.6080102@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
Message-ID: <CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>

2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org>:

>
> Well, I don't like the #open method in the model. The idea of View / Model
> separation is that views know about models, but models don't know about
> views. A Model should exist independently of being used from Morphic, MVC,
> Seaside, or any other UI framework. It could live, for example, in a
> Gemstone database with no UI at all. Or ir could travel to and from other
> systems, like VA Smalltalk, where the UI framework is completely different
> from Cuis'.
>
>
Interesting, really I never heard of the use of  #open at the model or I do
not remember it at all, but I think similar to Juan.



> I think it is better for the View to start it all.
>
>
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/f563d169/attachment-0002.html>

From dnorton at mindspring.com  Mon Nov 16 19:50:30 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 16 Nov 2015 20:50:30 -0500
Subject: [Cuis] #when:send:to:
In-Reply-To: <564A70C7.4040005@jvuletich.org>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<564A70C7.4040005@jvuletich.org>
Message-ID: <564A87E6.28858.2533F1E@dnorton.mindspring.com>

On 16 Nov 2015 at 21:11, Juan Vuletich wrote:

> Hi Dan,
> 
> On 13/11/2015 02:58 p.m., Dan Norton wrote:
> > Hello Everyone,
> >
> > The following repo contains before and after examples of replacing
> the Dependency
> > Mechanism with the Observer Pattern:
> >
> > 	https://github.com/dhnorton/Cuis-Smalltalk-light
> >
> > Please take a look at this and tell me what needs to change. I'm
> trying to supply an example
> > of the Observer Pattern so that others might use #when:send:to:
> with less difficulty than I
> > experienced. There may be better examples but I picked one from
> the Blue Book.
> >
> > It seems that #when:send:to: is necessary but not sufficient as a
> replacement for the
> > Dependency Mechanism. In this example, it replaced #addDependent:,
> not #changed or
> > #update and I am still not comfortable with how to choose the
> parameters. This may be an
> > example of the difficulty in explaining the obvious, I'm not sure
> :-)
> >
> > The #changed method was replaced with #triggerEvent: with a symbol
> argument which is
> > referred to in one of the arguments of #when:send:to: and that's
> the only constraint AFAICT.
> >
> > The #update: method was retained, as a convenience; it also needs
> to agree with one of the
> > arguments of #when:send:to: and could have been different.
> >
> > Please tell me if any of this is wrong. Thanks.
> >
> >   - Dan
> 
> I think the idea of #when:send:to: is to use event names and actions
> that make sense to your model (and not #changed and #update:). For
> instance, in Example2>>#lights:, I would change the line:
> 
>          eachLight when: #changed send: #update: to: dependentLight
> with: self
> 
> to read:
> 
>          eachLight when: #turnedOn send: #turnOff to:
> dependentLight
> 
> And, in #turnOn, make it do:
> 
>          self triggerEvent: #turnedOn
> 
> 
> Doesn't this read better?
> 

+2
...because yes, it reads better, but there's more:

	#when:send:to: replaces #when:send:to:with:

	in Light2, #update: goes away, with a little factoring

The #triggerEvent: arg is changed to #turnedOn. This is elegant.

 - Dan



From juan at jvuletich.org  Mon Nov 16 19:52:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 22:52:01 -0300
Subject: [Cuis] #when:send:to:
In-Reply-To: <564A87E6.28858.2533F1E@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<564A70C7.4040005@jvuletich.org>
	<564A87E6.28858.2533F1E@dnorton.mindspring.com>
Message-ID: <564A8841.7070708@jvuletich.org>

On 16/11/2015 10:50 p.m., Dan Norton wrote:
> On 16 Nov 2015 at 21:11, Juan Vuletich wrote:
>
>> Hi Dan,
>>
>> On 13/11/2015 02:58 p.m., Dan Norton wrote:
>>> Hello Everyone,
>>>
>>> The following repo contains before and after examples of replacing
>> the Dependency
>>> Mechanism with the Observer Pattern:
>>>
>>> 	https://github.com/dhnorton/Cuis-Smalltalk-light
>>>
>>> Please take a look at this and tell me what needs to change. I'm
>> trying to supply an example
>>> of the Observer Pattern so that others might use #when:send:to:
>> with less difficulty than I
>>> experienced. There may be better examples but I picked one from
>> the Blue Book.
>>> It seems that #when:send:to: is necessary but not sufficient as a
>> replacement for the
>>> Dependency Mechanism. In this example, it replaced #addDependent:,
>> not #changed or
>>> #update and I am still not comfortable with how to choose the
>> parameters. This may be an
>>> example of the difficulty in explaining the obvious, I'm not sure
>> :-)
>>> The #changed method was replaced with #triggerEvent: with a symbol
>> argument which is
>>> referred to in one of the arguments of #when:send:to: and that's
>> the only constraint AFAICT.
>>> The #update: method was retained, as a convenience; it also needs
>> to agree with one of the
>>> arguments of #when:send:to: and could have been different.
>>>
>>> Please tell me if any of this is wrong. Thanks.
>>>
>>>    - Dan
>> I think the idea of #when:send:to: is to use event names and actions
>> that make sense to your model (and not #changed and #update:). For
>> instance, in Example2>>#lights:, I would change the line:
>>
>>           eachLight when: #changed send: #update: to: dependentLight
>> with: self
>>
>> to read:
>>
>>           eachLight when: #turnedOn send: #turnOff to:
>> dependentLight
>>
>> And, in #turnOn, make it do:
>>
>>           self triggerEvent: #turnedOn
>>
>>
>> Doesn't this read better?
>>
> +2
> ...because yes, it reads better, but there's more:
>
> 	#when:send:to: replaces #when:send:to:with:
>
> 	in Light2, #update: goes away, with a little factoring
>
> The #triggerEvent: arg is changed to #turnedOn. This is elegant.
>
>   - Dan
>

Yes! And this way, 'senders' and 'implementors' take you right to the spot.

Cheers,
Juan Vuletich

> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From thierry.goubier at gmail.com  Mon Nov 16 22:42:37 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 05:42:37 +0100
Subject: [Cuis] Patterns
In-Reply-To: <CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
Message-ID: <564AB03D.1040405@gmail.com>

Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
>
>
> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
> <mailto:juan at jvuletich.org>>:
>
>     __
>
>     Well, I don't like the #open method in the model. The idea of View /
>     Model separation is that views know about models, but models don't
>     know about views. A Model should exist independently of being used
>     from Morphic, MVC, Seaside, or any other UI framework. It could
>     live, for example, in a Gemstone database with no UI at all. Or ir
>     could travel to and from other systems, like VA Smalltalk, where the
>     UI framework is completely different from Cuis'.
>
>
> Interesting, really I never heard of the use of  #open at the model or I
> do not remember it at all, but I think similar to Juan.

Hum, #open has to go somewhere, so...

Either it goes into a sort of Application Model, which regroup the 
duties associated with the application (the view + model + whatever is 
necessary in environment X), or it goes into an Application View which 
then has model concerns in it (it knows how to start or connect to the 
model, it knows what the model is composed of to connect subviews to 
model elements, etc...).

>     I think it is better for the View to start it all.
>
>
> +1

I prefer to model an Application concept in the target desktop 
environment if I want to model highly portable stuff.

That application concern can be folded into a dedicated view if that is 
the preferred convention in the target environment.

Regards,

Thierry

>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From thierry.goubier at gmail.com  Mon Nov 16 22:44:52 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 05:44:52 +0100
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <564A3BCE.9090409@jvuletich.org>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
	<564A3BCE.9090409@jvuletich.org>
Message-ID: <564AB0C4.7000906@gmail.com>

Hi Juan, Euan,

thanks for the update on Morphic3. I'll have a look one of these days, 
when I'll have something interesting to show running on Cuis.

Regards,

Thierry

Le 16/11/2015 21:25, Juan Vuletich a ?crit :
> Hi Euan,
>
> On 11/11/2015 4:02 PM, Euan Mee wrote:
>> Thanks for the pointer to Morphic3 and its documentation.  I'll try to
>> contribute more naive-user questions :-)
>>
>> What is the state of development of Morphic3?
>>    - complete stable codebase?
>>    - stable codebase for substantial parts, with fuurther extensions in
>> development?
>>    - central aspects still under development?
>>    - a design concept, coding yet to begin?
>
> I think "central aspects still under development" is a fair way to say it.
> If you want to take a look, it is in the 'Experimental' folder. Feel
> free to ask questions.
>
>> e.g. The documentation starts off with "Morphic3 *will have* scalable
>> graphics".  This might mean that Morphic3 works now, but does not yet
>> have scalable graphics.  Or it might just mean Morphic3 does not (yet)
>> work.
>>
>
> Well, we have been evolving Morphic in Cuis, towards the direction shown
> by some experiments I did in 2009, for quite some time. This is
> currently using BitBltCanvas to draw, that can not do proper scalable
> graphics. The Morphic3Canvas in 'Experimental' can do this.
>
>> Generally, whenever I'm looking at a new platform, system, or package,
>> I am initially looking for answers of the type
>>     "Can I use it now?
>>          No /
>>          Yes /
>>          Yes to an extent, but..."
>>
>> I'm very happy to write up aspects of the system/package as
>> fully-formed documentation, especially documentation for naive-users.
>> Please let me know if there specific places where this help is
>> already-known to be particularly needed.
>
> Morphic 3 is ready to be studied by really interested ones. Not at all
> ready for a naive- user. On the question of where this help is needed,
> I'm not the best to answer. Maybe others in the community answer this,
> or, just use the system for some project, and you'll quickly find the
> places where a new user (you!) could use better documentation.
>
>> I look forward (in the long run?) to trying Cuis and Morphic3 on
>> Raspberry Pi.
>>
>
> Well, Morphic 3 might be more expensive than BitBltCanvas, and I don't
> know if it will run reasonably well on a Pi....
>
> Cheers,
> Juan Vuletich
>
>> On 11 November 2015 at 18:00,<cuis-request at jvuletich.org>  wrote:
>>> Send Cuis mailing list submissions to
>>>          cuis at jvuletich.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>          http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>> or, via email, send a message with subject or body 'help' to
>>>          cuis-request at jvuletich.org
>>>
>>> You can reach the person managing the list at
>>>          cuis-owner at jvuletich.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Cuis digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>     1. Simple Morphic (Euan Mee)
>>>     2. Re: Simple Morphic (KenD)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Wed, 11 Nov 2015 14:13:57 +0000
>>> From: Euan Mee<euanmee at gmail.com>
>>> To: cuis at jvuletich.org
>>> Subject: [Cuis] Simple Morphic
>>> Message-ID:
>>>
>>> <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w at mail.gmail.com>
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> What is the current state of development of Simple Morph?
>>>
>>> Is there any documentation on how to use it, or is it allInTheCode ?
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Wed, 11 Nov 2015 08:13:58 -0800
>>> From: KenD<Ken.Dickey at Whidbey.com>
>>> To: Discussion of Cuis Smalltalk<cuis at jvuletich.org>
>>> Cc: Euan Mee<euanmee at gmail.com>
>>> Subject: Re: [Cuis] Simple Morphic
>>> Message-ID:<20151111081358.4a0291315670cadcdcead39f at Whidbey.com>
>>> Content-Type: text/plain; charset=US-ASCII
>>>
>>> On Wed, 11 Nov 2015 14:13:57 +0000
>>> Euan Mee<euanmee at gmail.com>  wrote:
>>>
>>>> What is the current state of development of Simple Morph?
>>> I am not sure what you mean by Simple Morph.
>>>
>>> Cuis has been taking steps toward Morphic3:
>>>
>>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>>>
>>>
>>> The MorphExtension class was removed.  (We have Morph Properties).
>>>
>>> Morphs have float rather than integer location coordinates.
>>>
>>> Morph location is relative to their owner, not the screen.
>>>
>>> These are relatively small changes to get used to.
>>>
>>> More radical are some of the other simplifications in the system.
>>>
>>> The best example here is probably Layout.
>>>
>>> LayoutMorphs do just that for their submorphs.  A LayoutSpec is
>>> attached to individual Morphs to tell their container how they want
>>> to be layed out.  See the class comments.
>>>
>>> The code in LayoutMorph is much smaller (see
>>> LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding
>>> layout code in Squeak or Pharo.
>>>
>>> See LayoutMorph class examples.
>>>
>>> If you git clone the Morphic-Misc1 package and load it you can get
>>> Layout editors:
>>>
>>> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>>>
>>>    git clone
>>> https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>>>
>>> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to
>>> require the package:
>>>
>>>    Feature require:  'Morphic-Misc1'.
>>>
>>> Then use the LayoutMorph class examples, select (sub) morphs, open a
>>> LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>>>
>>> Note that these editors are "one-shot" and will close after setting
>>> or cancelling, so click on the "push pin" in the upper right corner
>>> to keep them open.
>>>
>>> If you have several editors open, you can use the "Show Halo" button
>>> to see which Morph an editor is adjusting.
>>>
>>>> Is there any documentation on how to use it, or is it allInTheCode ?
>>> See the above URL and continue to ask questions.  We need to make the
>>> documentation better over time and questions are very helpful here.
>>>
>>> --
>>> -KenD
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>>
>>> ------------------------------
>>>
>>> End of Cuis Digest, Vol 41, Issue 14
>>> ************************************
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From luchiano at gmail.com  Tue Nov 17 01:13:52 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Tue, 17 Nov 2015 07:13:52 +0000
Subject: [Cuis] dynamic window manager
Message-ID: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>

I've been using dwm.suckless.org for 10 years and I just had to have it in
Cuis. So, that's what I've been doing the last two days, and I had to do
some minor changes to the core in order to allow this level of
customization. In case there's some other tiling maniac like me who wants
to give it a try... although it's still a little rough, I'll be improving
it as I go by using it everyday :) Not sure it will work out-of-the-box
yet, I've done some changes that are not included in the package (like some
preferences and monospaced font)

https://github.com/len/Cuis-Smalltalk-DWM

Cheers,
Luciano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/57cf707d/attachment-0002.html>

From 0800nacho at gmail.com  Tue Nov 17 03:46:54 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Tue, 17 Nov 2015 06:46:54 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
Message-ID: <CAMCzT-arkx7dkmw1vNWGCXBTvTO4DbJ9eVFsqqDM-5fC0W9MpA@mail.gmail.com>

Great to hear you use suckless.
Do you use dwm or another WM?
For the past 2 years I been using i3, I'm very happy with it.
abrazo
Nacho


*Lic. Ignacio Sniechowski, MBA*
*Prosavic SRL*

*Tel: (011) 4542-6714*


















On Tue, Nov 17, 2015 at 4:13 AM, Luciano Notarfrancesco <luchiano at gmail.com>
wrote:

> I've been using dwm.suckless.org for 10 years and I just had to have it
> in Cuis. So, that's what I've been doing the last two days, and I had to do
> some minor changes to the core in order to allow this level of
> customization. In case there's some other tiling maniac like me who wants
> to give it a try... although it's still a little rough, I'll be improving
> it as I go by using it everyday :) Not sure it will work out-of-the-box
> yet, I've done some changes that are not included in the package (like some
> preferences and monospaced font)
>
> https://github.com/len/Cuis-Smalltalk-DWM
>
> Cheers,
> Luciano
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/e12d67bb/attachment-0002.html>

From juan at jvuletich.org  Tue Nov 17 08:00:21 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 17 Nov 2015 11:00:21 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564AB03D.1040405@gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>	<563CF147.306@jvuletich.org>	<564A5919.15040.19C7009@dnorton.mindspring.com>	<564A7D91.6080102@jvuletich.org>	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com>
Message-ID: <564B32F5.9050102@jvuletich.org>

Hi Thierry,


On 11/17/2015 1:42 AM, Thierry Goubier wrote:
> Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
>>
>>
>> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
>> <mailto:juan at jvuletich.org>>:
>>
>>     __
>>
>>     Well, I don't like the #open method in the model. The idea of View /
>>     Model separation is that views know about models, but models don't
>>     know about views. A Model should exist independently of being used
>>     from Morphic, MVC, Seaside, or any other UI framework. It could
>>     live, for example, in a Gemstone database with no UI at all. Or ir
>>     could travel to and from other systems, like VA Smalltalk, where the
>>     UI framework is completely different from Cuis'.
>>
>>
>> Interesting, really I never heard of the use of  #open at the model or I
>> do not remember it at all, but I think similar to Juan.
>
> Hum, #open has to go somewhere, so...
>
> Either it goes into a sort of Application Model, which regroup the 
> duties associated with the application (the view + model + whatever is 
> necessary in environment X), or it goes into an Application View which 
> then has model concerns in it (it knows how to start or connect to the 
> model, it knows what the model is composed of to connect subviews to 
> model elements, etc...).
>

The idea of view / model separation is pretty well explained in "Inside 
Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.

I agree that an Application object or such might make sense when you are 
building an application, especially if you need to deal with en external 
environment. But here we were talking about whether the Model classes 
should know about Morphs or not.

>>     I think it is better for the View to start it all.
>>
>>
>> +1
>
> I prefer to model an Application concept in the target desktop 
> environment if I want to model highly portable stuff.
>
> That application concern can be folded into a dedicated view if that 
> is the preferred convention in the target environment.
>
> Regards,
>
> Thierry

I wonder how would this result in practice. Do you have some examples to 
share?

Cheers,
Juan Vuletich



From thierry.goubier at gmail.com  Tue Nov 17 08:32:16 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 15:32:16 +0100
Subject: [Cuis] Fwd:  Patterns
In-Reply-To: <CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
Message-ID: <CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>

2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:

> Hi Thierry,
>
>
> On 11/17/2015 1:42 AM, Thierry Goubier wrote:
>
>> Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
>>
>>>
>>>
>>> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
>>> <mailto:juan at jvuletich.org>>:
>>>
>>>     __
>>>
>>>     Well, I don't like the #open method in the model. The idea of View /
>>>     Model separation is that views know about models, but models don't
>>>     know about views. A Model should exist independently of being used
>>>     from Morphic, MVC, Seaside, or any other UI framework. It could
>>>     live, for example, in a Gemstone database with no UI at all. Or ir
>>>     could travel to and from other systems, like VA Smalltalk, where the
>>>     UI framework is completely different from Cuis'.
>>>
>>>
>>> Interesting, really I never heard of the use of  #open at the model or I
>>> do not remember it at all, but I think similar to Juan.
>>>
>>
>> Hum, #open has to go somewhere, so...
>>
>> Either it goes into a sort of Application Model, which regroup the duties
>> associated with the application (the view + model + whatever is necessary
>> in environment X), or it goes into an Application View which then has model
>> concerns in it (it knows how to start or connect to the model, it knows
>> what the model is composed of to connect subviews to model elements,
>> etc...).
>>
>>
> The idea of view / model separation is pretty well explained in "Inside
> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>

Sadly, that view / model separation encounters pragmatic issues  when
dealing with things more complex than standard widgets, such as your
typical domain drawing editor. This is the fundamental reason for me to
consider that Morphic departed from that model, and that the pinacle of
that M / V separation is the M2VC of VisualWorks.

Newer models in the literature around those years such as PAC proposed
better abstractions, but they were never implemented.

Now, it's interesting to see you advocate that model on top of Morphic.


> I agree that an Application object or such might make sense when you are
> building an application, especially if you need to deal with en external
> environment. But here we were talking about whether the Model classes
> should know about Morphs or not.


In theory, no.

In practice, if you want a well tuned gui, I consider that yes, they need
to be aware of them.

So the most elegant way I've used is the two models: a pure, abstract
model, totally view independent. And a pragmatic, closer to the view /
aware of the view, application model as an mediator.


>
>
>     I think it is better for the View to start it all.
>>>
>>>
>>> +1
>>>
>>
>> I prefer to model an Application concept in the target desktop
>> environment if I want to model highly portable stuff.
>>
>> That application concern can be folded into a dedicated view if that is
>> the preferred convention in the target environment.
>>
>> Regards,
>>
>> Thierry
>>
>
> I wonder how would this result in practice. Do you have some examples to
> share?
>

I have a complex example, a system browser, would that fit?

Regards,

Thierry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/57a1be52/attachment-0002.html>

From juan at jvuletich.org  Tue Nov 17 09:16:07 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 17 Nov 2015 12:16:07 -0300
Subject: [Cuis] Fwd:  Patterns
In-Reply-To: <CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>	<563CF147.306@jvuletich.org>	<564A5919.15040.19C7009@dnorton.mindspring.com>	<564A7D91.6080102@jvuletich.org>	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>	<564AB03D.1040405@gmail.com>
	<564B32F5.9050102@jvuletich.org>	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
Message-ID: <564B44B7.2070809@jvuletich.org>

Hi Thierry,

On 11/17/2015 11:32 AM, Thierry Goubier wrote:
>
> 2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>>:
>
>     ...
>
>     The idea of view / model separation is pretty well explained in
>     "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>
>
> Sadly, that view / model separation encounters pragmatic issues  when 
> dealing with things more complex than standard widgets, such as your 
> typical domain drawing editor.

This is the first time I hear this. Can you elaborate or provide 
references? I worked on several mid-size to large projects that did 
strict view / model separation, and I never saw "pragmatic issues" (that 
couldn't be solved by a good design).

> This is the fundamental reason for me to consider that Morphic 
> departed from that model, and that the pinacle of that M / V 
> separation is the M2VC of VisualWorks.

PluggableMorphs attempted to follow this model (and give model 
compatibility between Morphic and MVC). Etoys (if I remember correctly) 
do the same, only that calling the model a "Player" and the view a 
"Costume". Later, people forgot about view / model separation, and 
Squeak became legacy software, in part because of that.

> Newer models in the literature around those years such as PAC proposed 
> better abstractions, but they were never implemented.
> Now, it's interesting to see you advocate that model on top of Morphic.
>
>
>     I agree that an Application object or such might make sense when
>     you are building an application, especially if you need to deal
>     with en external environment. But here we were talking about
>     whether the Model classes should know about Morphs or not.
>
>
> In theory, no.
>
> In practice, if you want a well tuned gui, I consider that yes, they 
> need to be aware of them.

Please elaborate, or provide references.

> So the most elegant way I've used is the two models: a pure, abstract 
> model, totally view independent. And a pragmatic, closer to the view / 
> aware of the view, application model as an mediator.
>
>
>
>                 I think it is better for the View to start it all.
>
>
>             +1
>
>
>         I prefer to model an Application concept in the target desktop
>         environment if I want to model highly portable stuff.
>
>         That application concern can be folded into a dedicated view
>         if that is the preferred convention in the target environment.
>
>         Regards,
>
>         Thierry
>
>
>     I wonder how would this result in practice. Do you have some
>     examples to share?
>
>
> I have a complex example, a system browser, would that fit?

Sure.

> Regards,
>
> Thierry
>

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/38ab5247/attachment-0002.html>

From garduino at gmail.com  Tue Nov 17 09:57:05 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Tue, 17 Nov 2015 12:57:05 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
Message-ID: <CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>

Awesome!!

Saludos / Regards,
Germ?n Arduino
@garduino


2015-11-17 4:13 GMT-03:00 Luciano Notarfrancesco <luchiano at gmail.com>:

> I've been using dwm.suckless.org for 10 years and I just had to have it
> in Cuis. So, that's what I've been doing the last two days, and I had to do
> some minor changes to the core in order to allow this level of
> customization. In case there's some other tiling maniac like me who wants
> to give it a try... although it's still a little rough, I'll be improving
> it as I go by using it everyday :) Not sure it will work out-of-the-box
> yet, I've done some changes that are not included in the package (like some
> preferences and monospaced font)
>
> https://github.com/len/Cuis-Smalltalk-DWM
>
> Cheers,
> Luciano
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/b2136b82/attachment-0002.html>

From luchiano at gmail.com  Tue Nov 17 10:35:40 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Tue, 17 Nov 2015 16:35:40 +0000
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAMCzT-arkx7dkmw1vNWGCXBTvTO4DbJ9eVFsqqDM-5fC0W9MpA@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
	<CAMCzT-arkx7dkmw1vNWGCXBTvTO4DbJ9eVFsqqDM-5fC0W9MpA@mail.gmail.com>
Message-ID: <CAL5GDyrGy=1rQctf4oBE_XLPF_yK_32yXGmsborH_4J5H7dqcA@mail.gmail.com>

Yeah, I use dwm, I tried several tiling window managers and I ended up with
my customized version of dwm. I use it "nested", I have a minimalist host
that barely can run dwm and the command-line virtualbox, and then many
small virtual machines that run a slightly different version of dwm for
different tasks, color-coded, etc... like a form of compartmentalization...
haha

I'm not sure this tiling and text-oriented thing is useful for coding
Smalltalk... I'll see... I always enjoyed experimenting with alternatives
to the classic overlapping-windows and menus and icons paradigm.

Cheers,
Luciano

On Tue, Nov 17, 2015 at 9:46 AM, Ignacio Sniechowski <0800nacho at gmail.com>
wrote:

> Great to hear you use suckless.
> Do you use dwm or another WM?
> For the past 2 years I been using i3, I'm very happy with it.
> abrazo
> Nacho
>
>
> *Lic. Ignacio Sniechowski, MBA*
> *Prosavic SRL*
>
> *Tel: (011) 4542-6714*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Nov 17, 2015 at 4:13 AM, Luciano Notarfrancesco <
> luchiano at gmail.com> wrote:
>
>> I've been using dwm.suckless.org for 10 years and I just had to have it
>> in Cuis. So, that's what I've been doing the last two days, and I had to do
>> some minor changes to the core in order to allow this level of
>> customization. In case there's some other tiling maniac like me who wants
>> to give it a try... although it's still a little rough, I'll be improving
>> it as I go by using it everyday :) Not sure it will work out-of-the-box
>> yet, I've done some changes that are not included in the package (like some
>> preferences and monospaced font)
>>
>> https://github.com/len/Cuis-Smalltalk-DWM
>>
>> Cheers,
>> Luciano
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/536c1256/attachment-0002.html>

From thierry.goubier at gmail.com  Tue Nov 17 10:51:47 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 17:51:47 +0100
Subject: [Cuis] Fwd:  Fwd: Patterns
In-Reply-To: <CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
	<564B44B7.2070809@jvuletich.org>
	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
Message-ID: <CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>

Hi Juan,

2015-11-17 16:16 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:

> Hi Thierry,
>
> On 11/17/2015 11:32 AM, Thierry Goubier wrote:
>
>
> 2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:
>
>> ...
>>
>> The idea of view / model separation is pretty well explained in "Inside
>> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>>
>
> Sadly, that view / model separation encounters pragmatic issues  when
> dealing with things more complex than standard widgets, such as your
> typical domain drawing editor.
>
>
> This is the first time I hear this. Can you elaborate or provide
> references? I worked on several mid-size to large projects that did strict
> view / model separation, and I never saw "pragmatic issues" (that couldn't
> be solved by a good design).
>

I would give HotDraw, and some of the original design pattern work on
editors, especially the parts derived from the InterViews toolkit.

Now, I used to be pretty up to date on the literature and some of the
criticism of the MVC model (especially the division between V and C) but my
memory of that time is all fuzzy.

> This is the fundamental reason for me to consider that Morphic departed
> from that model, and that the pinacle of that M / V separation is the M2VC
> of VisualWorks.
>
>
> PluggableMorphs attempted to follow this model (and give model
> compatibility between Morphic and MVC). Etoys (if I remember correctly) do
> the same, only that calling the model a "Player" and the view a "Costume".
> Later, people forgot about view / model separation, and Squeak became
> legacy software, in part because of that.
>

Maybe. I'm not sure of that particular factor. I have the feeling that
there is no clear and honest analysis on the state of GUI toolkits in that
universe, for present and future ones.


> Newer models in the literature around those years such as PAC proposed
> better abstractions, but they were never implemented.
> Now, it's interesting to see you advocate that model on top of Morphic.
>
>
>> I agree that an Application object or such might make sense when you are
>> building an application, especially if you need to deal with en external
>> environment. But here we were talking about whether the Model classes
>> should know about Morphs or not.
>
>
> In theory, no.
>
> In practice, if you want a well tuned gui, I consider that yes, they need
> to be aware of them.
>
>
> Please elaborate, or provide references.
>

What would you think of a drag and drop feedback which is dependent of the
type of the model elements?


>
>
> So the most elegant way I've used is the two models: a pure, abstract
> model, totally view independent. And a pragmatic, closer to the view /
> aware of the view, application model as an mediator.
>
>
>>
>>
>>     I think it is better for the View to start it all.
>>>>
>>>>
>>>> +1
>>>>
>>>
>>> I prefer to model an Application concept in the target desktop
>>> environment if I want to model highly portable stuff.
>>>
>>> That application concern can be folded into a dedicated view if that is
>>> the preferred convention in the target environment.
>>>
>>> Regards,
>>>
>>> Thierry
>>>
>>
>> I wonder how would this result in practice. Do you have some examples to
>> share?
>>
>
> I have a complex example, a system browser, would that fit?
>
>
> Sure.
>

Well, a short estimate on that particular application is that, linked with
the pluggable morphs, 10 to 20% of the code in the application model is:
- widget creation, setup, layout
- dynamic morph addition / removal when activating certain functions on the
model
- workarounds the pluggable morphs api to:
  - dynamically refresh parts of the inside of widgets
  - disconnect then reconnect links between widgets so that the
model-triggered update of one does not change the state of the other one
(i.e. protect the model from unwanted view triggered updates when the model
is changing part of its contents).

This application model uses mainly two widgets.

I do have a long term plan to port that to Cuis, and I expect I will have
to write that very same code somewhere (maybe more, maybe less).

Regards,

Thierry


>
> Regards,
>
> Thierry
>
>
> Cheers,
> Juan Vuletich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/fbfd618b/attachment-0002.html>

From luchiano at gmail.com  Tue Nov 17 11:14:29 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Tue, 17 Nov 2015 17:14:29 +0000
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
	<CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>
Message-ID: <CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>

On Tue, Nov 17, 2015 at 3:57 PM, Germ?n Arduino <garduino at gmail.com> wrote:

> Awesome!!
>

Haha, awesome is another window manager, it was also a fork of dwm, I used
it for a while ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/b007e699/attachment-0002.html>

From juan at jvuletich.org  Tue Nov 17 11:36:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 17 Nov 2015 14:36:34 -0300
Subject: [Cuis] Fwd:  Fwd: Patterns
In-Reply-To: <CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>	<563CF147.306@jvuletich.org>	<564A5919.15040.19C7009@dnorton.mindspring.com>	<564A7D91.6080102@jvuletich.org>	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>	<564AB03D.1040405@gmail.com>
	<564B32F5.9050102@jvuletich.org>	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>	<564B44B7.2070809@jvuletich.org>	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
	<CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
Message-ID: <564B65A2.3050604@jvuletich.org>

Hi Thierry,

On 11/17/2015 1:51 PM, Thierry Goubier wrote:
> Hi Juan,
>
> 2015-11-17 16:16 GMT+01:00 Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>>:
>
>     Hi Thierry,
>
>     On 11/17/2015 11:32 AM, Thierry Goubier wrote:
>>
>>     2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org
>>     <mailto:juan at jvuletich.org>>:
>>
>>         ...
>>
>>         The idea of view / model separation is pretty well explained
>>         in "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>>
>>
>>     Sadly, that view / model separation encounters pragmatic issues
>>      when dealing with things more complex than standard widgets,
>>     such as your typical domain drawing editor.
>
>     This is the first time I hear this. Can you elaborate or provide
>     references? I worked on several mid-size to large projects that
>     did strict view / model separation, and I never saw "pragmatic
>     issues" (that couldn't be solved by a good design).
>
>
> I would give HotDraw, and some of the original design pattern work on 
> editors, especially the parts derived from the InterViews toolkit.

Uh, it is not easy to find stuff about that, so I can't really comment.

> Now, I used to be pretty up to date on the literature and some of the 
> criticism of the MVC model (especially the division between V and C) 
> but my memory of that time is all fuzzy.

Well, in my opinion View / Model separation is a great property of the 
design of an application. Controller is more of a requirement of the 
ST-80 MVC framework. In principle, I see no problem in merging 
Controller into View. But, in Cuis, it can be argued that the Editor 
hierarchy is essentially a hierarchy of Controllers, and that's ok if 
the decomposition of responsibilities makes sense.

In View / Model separation there are two restrictions that need to be 
honored:
- The Model doesn't know about the possible Views. This means, for 
instance, that it could provide all its services, and exercise all its 
functionality, even if the GUI framework is completely absent. Model 
code should never fail because of this. This is great for moving models 
from and two different runtimes (client, server, gemstone, various 
dialects, etc) and also for writing tests.
- Model behavior should not leak into Views. This means that if the 
views are removed (maybe to be replaced by some others, in the same or 
in another framework), Model should not lose state nor behavior. Model 
must be complete by itself.
So, the idea is essentially to protect the integrity and consistency of 
Models.

>>     This is the fundamental reason for me to consider that Morphic
>>     departed from that model, and that the pinacle of that M / V
>>     separation is the M2VC of VisualWorks.
>
>     PluggableMorphs attempted to follow this model (and give model
>     compatibility between Morphic and MVC). Etoys (if I remember
>     correctly) do the same, only that calling the model a "Player" and
>     the view a "Costume". Later, people forgot about view / model
>     separation, and Squeak became legacy software, in part because of
>     that.
>
>
> Maybe. I'm not sure of that particular factor. I have the feeling that 
> there is no clear and honest analysis on the state of GUI toolkits in 
> that universe, for present and future ones.
>
>>     Newer models in the literature around those years such as PAC
>>     proposed better abstractions, but they were never implemented.
>>     Now, it's interesting to see you advocate that model on top of
>>     Morphic.
>>
>>
>>         I agree that an Application object or such might make sense
>>         when you are building an application, especially if you need
>>         to deal with en external environment. But here we were
>>         talking about whether the Model classes should know about
>>         Morphs or not.
>>
>>
>>     In theory, no.
>>
>>     In practice, if you want a well tuned gui, I consider that yes,
>>     they need to be aware of them.
>
>     Please elaborate, or provide references.
>
>
> What would you think of a drag and drop feedback which is dependent of 
> the type of the model elements?

Well, lets assume a Model with 2 collections of elements. To make it 
sound a bit more concrete, lets call them Orders and Assets. And lets 
assume that the UI has some place(s) from where the user can drag many 
kinds of objects, like Orders, Assets, between others. Now, the user 
drags an Asset and wants to drop it into the Orders list. Given that the 
widget for the Orders list supports dropping, lets assume that its 
'dropActionSelector' is #addOrder:. This #addOrder: model method would 
be called with an Asset. So, #addOrder: could answer false, to let 
sender know that the addition was rejected (because it was not an 
Order!). It makes sense to have the method in ListWidget that calls 
'dropSelector' check for the result, and if it is false, let the user 
know that the drop was rejected, for instance, by keeping the dragged 
object in the hand.

>
>
>>     So the most elegant way I've used is the two models: a pure,
>>     abstract model, totally view independent. And a pragmatic, closer
>>     to the view / aware of the view, application model as an mediator.
>>
>>
>>
>>                     I think it is better for the View to start it all.
>>
>>
>>                 +1
>>
>>
>>             I prefer to model an Application concept in the target
>>             desktop environment if I want to model highly portable stuff.
>>
>>             That application concern can be folded into a dedicated
>>             view if that is the preferred convention in the target
>>             environment.
>>
>>             Regards,
>>
>>             Thierry
>>
>>
>>         I wonder how would this result in practice. Do you have some
>>         examples to share?
>>
>>
>>     I have a complex example, a system browser, would that fit?
>
>     Sure.
>
>
> Well, a short estimate on that particular application is that, linked 
> with the pluggable morphs, 10 to 20% of the code in the application 
> model is:
> - widget creation, setup, layout
> - dynamic morph addition / removal when activating certain functions 
> on the model
> - workarounds the pluggable morphs api to:
>   - dynamically refresh parts of the inside of widgets
>   - disconnect then reconnect links between widgets so that the 
> model-triggered update of one does not change the state of the other 
> one (i.e. protect the model from unwanted view triggered updates when 
> the model is changing part of its contents).

"View model" is a bit a misleading name. I'd say all this belongs in the 
Views world.

Besides, the method called to update Views after Model changes should 
not modify the Model. In this way, there would be no extra Model events 
triggered, and spurious updates would not occur. This might require 
enhancing the Views framework, if not mature enough.

>
> This application model uses mainly two widgets.
>
> I do have a long term plan to port that to Cuis, and I expect I will 
> have to write that very same code somewhere (maybe more, maybe less).
>
> Regards,
>
> Thierry

Hopefully, it will be less :)

Cheers,
Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/b3f58cf1/attachment-0002.html>

From garduino at gmail.com  Tue Nov 17 11:44:12 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Tue, 17 Nov 2015 14:44:12 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
	<CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>
	<CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>
Message-ID: <CAEt3aLwUUCU8Qiqt_GphY1-8CpSxpbFSL75zXoAmTPY_hJjG_g@mail.gmail.com>

2015-11-17 14:14 GMT-03:00 Luciano Notarfrancesco <luchiano at gmail.com>:

> On Tue, Nov 17, 2015 at 3:57 PM, Germ?n Arduino <garduino at gmail.com>
> wrote:
>
>> Awesome!!
>>
>
> Haha, awesome is another window manager, it was also a fork of dwm, I used
> it for a while ;)
>
>
Related with this talk, I remember old times helping with LinEx (a Linux
made by the Extremadura government in Spain where my friend Diego GD was
working using Squeak in education) lot of fun playing with Squeak itself as
the Window Manager in charge of such Linux. Very very fun times!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/88c107c3/attachment-0002.html>

From thierry.goubier at gmail.com  Tue Nov 17 12:59:12 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 19:59:12 +0100
Subject: [Cuis] Fwd: Fwd: Patterns
In-Reply-To: <564B65A2.3050604@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
	<564B44B7.2070809@jvuletich.org>
	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
	<CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
	<564B65A2.3050604@jvuletich.org>
Message-ID: <564B7900.2030004@gmail.com>

Hi Juan,

Le 17/11/2015 18:36, Juan Vuletich a ?crit :
> Hi Thierry,
>
>>
>>
>> I would give HotDraw, and some of the original design pattern work on
>> editors, especially the parts derived from the InterViews toolkit.
>
> Uh, it is not easy to find stuff about that, so I can't really comment.

InterViews was kept alive as the ivtools for long, very long after 
InterViews lost to Motif as the X Window toolkit. Fresco, InterViews 
successor, was also very interesting.

HotDraw is old as well. But I did some cool stuff with it (a hypermedia 
system, in 1993).

>> Now, I used to be pretty up to date on the literature and some of the
>> criticism of the MVC model (especially the division between V and C)
>> but my memory of that time is all fuzzy.
>
> Well, in my opinion View / Model separation is a great property of the
> design of an application. Controller is more of a requirement of the
> ST-80 MVC framework. In principle, I see no problem in merging
> Controller into View. But, in Cuis, it can be argued that the Editor
> hierarchy is essentially a hierarchy of Controllers, and that's ok if
> the decomposition of responsibilities makes sense.
>
> In View / Model separation there are two restrictions that need to be
> honored:
> - The Model doesn't know about the possible Views. This means, for
> instance, that it could provide all its services, and exercise all its
> functionality, even if the GUI framework is completely absent. Model
> code should never fail because of this. This is great for moving models
> from and two different runtimes (client, server, gemstone, various
> dialects, etc) and also for writing tests.
> - Model behavior should not leak into Views. This means that if the
> views are removed (maybe to be replaced by some others, in the same or
> in another framework), Model should not lose state nor behavior. Model
> must be complete by itself.
> So, the idea is essentially to protect the integrity and consistency of
> Models.

I do agree with that objective, but, in practice, what I find as a 
result is that an additional layer (model mediation or the M2 of MMVC) 
helps immensely by:

- regrouping certain model features which are introduced to satisfy view 
requirements...

   - For example a pure model can just have a copy or save to file 
operation, but a view would like to have a feedback on the length of the 
operation. In non gui mode, having the model expose that sort of 
information is a needless waste of code and resources. This would better 
be carried by a layer on top (which is still a model IMHO, since it 
maintain a certain level of decoupling with a view).

- Expose explicitely certain adaptations which are made for a specific 
toolkit (they are in that model).

- Allow for user-features oriented models to appear on top of the pure, 
abstract model

   - In a browser, one can imagine scoped models of the code as a 
user-oriented feature that a disconnected mode doesn't need to integrate.

Nothing really grandiose or earth-shattering, mind you. Just convenient.

>> What would you think of a drag and drop feedback which is dependent of
>> the type of the model elements?
>
> Well, lets assume a Model with 2 collections of elements. To make it
> sound a bit more concrete, lets call them Orders and Assets. And lets
> assume that the UI has some place(s) from where the user can drag many
> kinds of objects, like Orders, Assets, between others. Now, the user
> drags an Asset and wants to drop it into the Orders list. Given that the
> widget for the Orders list supports dropping, lets assume that its
> 'dropActionSelector' is #addOrder:. This #addOrder: model method would
> be called with an Asset. So, #addOrder: could answer false, to let
> sender know that the addition was rejected (because it was not an
> Order!). It makes sense to have the method in ListWidget that calls
> 'dropSelector' check for the result, and if it is false, let the user
> know that the drop was rejected, for instance, by keeping the dragged
> object in the hand.

Hum, I was more thinking of what I am dealing with at the moment, which 
is a drop in the Orders list is a drop on a specific order item, which 
has to tell:

- during the drag, if a drop would be honored
- after the drop, if it is accepted or rejected
- and, if accepted, that specific order item changes state and is shown 
as such (and may also change the number of order items, etc...)

I found, when doing that, to have an intermediate model on top of my 
Asset/Order object to mediate with the drag and drop API very usefull 
(that is, what is displayed and dragged are Views on AssetModels which 
are themselves observers of Assets).


>
>>
>>
>>>     So the most elegant way I've used is the two models: a pure,
>>>     abstract model, totally view independent. And a pragmatic, closer
>>>     to the view / aware of the view, application model as an mediator.
>>>
>>>
>>>
>>>                     I think it is better for the View to start it all.
>>>
>>>
>>>                 +1
>>>
>>>
>>>             I prefer to model an Application concept in the target
>>>             desktop environment if I want to model highly portable stuff.
>>>
>>>             That application concern can be folded into a dedicated
>>>             view if that is the preferred convention in the target
>>>             environment.
>>>
>>>             Regards,
>>>
>>>             Thierry
>>>
>>>
>>>         I wonder how would this result in practice. Do you have some
>>>         examples to share?
>>>
>>>
>>>     I have a complex example, a system browser, would that fit?
>>
>>     Sure.
>>
>>
>> Well, a short estimate on that particular application is that, linked
>> with the pluggable morphs, 10 to 20% of the code in the application
>> model is:
>> - widget creation, setup, layout
>> - dynamic morph addition / removal when activating certain functions
>> on the model
>> - workarounds the pluggable morphs api to:
>>   - dynamically refresh parts of the inside of widgets
>>   - disconnect then reconnect links between widgets so that the
>> model-triggered update of one does not change the state of the other
>> one (i.e. protect the model from unwanted view triggered updates when
>> the model is changing part of its contents).
>
> "View model" is a bit a misleading name. I'd say all this belongs in the
> Views world.

As I said, it may be moved into the View world, in the sense that it 
holds view-related concerns. But, at the same time, it has Model like 
decoupling from the Views.

> Besides, the method called to update Views after Model changes should
> not modify the Model. In this way, there would be no extra Model events
> triggered, and spurious updates would not occur. This might require
> enhancing the Views framework, if not mature enough.

I'll let you have a try at that :)

>>
>> This application model uses mainly two widgets.
>>
>> I do have a long term plan to port that to Cuis, and I expect I will
>> have to write that very same code somewhere (maybe more, maybe less).
>>
>> Regards,
>>
>> Thierry
>
> Hopefully, it will be less :)

I'm certainly looking forward to it.

Regards,

Thierry



From dnorton at mindspring.com  Tue Nov 17 21:01:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 17 Nov 2015 22:01:56 -0500
Subject: [Cuis] Patterns
In-Reply-To: <564B32F5.9050102@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<564AB03D.1040405@gmail.com>, <564B32F5.9050102@jvuletich.org>
Message-ID: <564BEA24.27869.2592A08@dnorton.mindspring.com>

The repo now contains two pairs of classes: coupled and decoupled. As it stands, the 
coupled example comes up the same, whether from the World->New morph... menu or from 
a Browser or Workspace.

The decoupled example does not do this and I don't know what to have in the pattern to 
avoid the following pitfalls:

follow the BrowserWindow class #openBrowser and get MNU: owner
follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs

 - Dan

On 17 Nov 2015 at 11:00, Juan Vuletich wrote:

> Hi Thierry,
> 
> 
> On 11/17/2015 1:42 AM, Thierry Goubier wrote:
> > Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
> >>
> >>
> >> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
> >> <mailto:juan at jvuletich.org>>:
> >>
> >>     __
> >>
> >>     Well, I don't like the #open method in the model. The idea of
> View /
> >>     Model separation is that views know about models, but models
> don't
> >>     know about views. A Model should exist independently of being
> used
> >>     from Morphic, MVC, Seaside, or any other UI framework. It
> could
> >>     live, for example, in a Gemstone database with no UI at all.
> Or ir
> >>     could travel to and from other systems, like VA Smalltalk,
> where the
> >>     UI framework is completely different from Cuis'.
> >>
> >>
> >> Interesting, really I never heard of the use of  #open at the
> model or I
> >> do not remember it at all, but I think similar to Juan.
> >
> > Hum, #open has to go somewhere, so...
> >
> > Either it goes into a sort of Application Model, which regroup the
> > duties associated with the application (the view + model +
> whatever is 
> > necessary in environment X), or it goes into an Application View
> which 
> > then has model concerns in it (it knows how to start or connect to
> the 
> > model, it knows what the model is composed of to connect subviews
> to 
> > model elements, etc...).
> >
> 
> The idea of view / model separation is pretty well explained in
> "Inside 
> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
> 
> I agree that an Application object or such might make sense when you
> are 
> building an application, especially if you need to deal with en
> external 
> environment. But here we were talking about whether the Model
> classes 
> should know about Morphs or not.
> 
> >>     I think it is better for the View to start it all.
> >>
> >>
> >> +1
> >
> > I prefer to model an Application concept in the target desktop 
> > environment if I want to model highly portable stuff.
> >
> > That application concern can be folded into a dedicated view if
> that 
> > is the preferred convention in the target environment.
> >
> > Regards,
> >
> > Thierry
> 
> I wonder how would this result in practice. Do you have some
> examples to 
> share?
> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From hannes.hirzel at gmail.com  Wed Nov 18 01:02:05 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Wed, 18 Nov 2015 08:02:05 +0100
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <564A7925.4060103@jvuletich.org>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
	<564A7925.4060103@jvuletich.org>
Message-ID: <CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>

On 11/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 14/11/2015 02:12 a.m., EuanM wrote:
>> I've just recently put-together a cross-platform Installation Tutorial
>> for beginners to Smalltalk.
>>
>> I was keen to include Cuis in the exercise.
>>
>
> Again, thank you for this.
>
>> One thing that becomes clear in the comparison is that Cuis is a good
>> beginner's environment from the point of view of size and complexity
>> and their bearing in learnability.
>>
>> It is however, the worst Smalltalk (of the 4 in the tutorial) to get
>> downloaded and installed.
>>
>> This seems a pity.
>
> Please take a look at
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Documentation
>
> . There are three 'Getting Started' guides, for different OSes and user
> style / preferences. They were tried (as described) in Linux, MacOsX and
> Windows.
>
>> Would anyone be willing to help me put together a One-Click Install
>> package, similar to Squeak's and Pharo's?
>>
>> (My plan is to do the grunt-work, if other people are willing to
>> indulge my noob questions while I do it)
>
> I believe that if you take the One-Click for Squeak or Pharo, and
> replace the image with a Cuis image, it should work.

It is worthwhile to have a look as well at the Squeak all-in-one package.

I have done it in the past in an adhoc way about by taking
http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.

There is quite some discussion about how this was constructed on the
Squeak list and people are willing to answer questions.

--Hannes

>> Is there a particular place that it could be hosted, once ready?
>>
>> Would anyone disagree with a 6-monthly update cycle for the One-Click
>> installer?
>>
>> (Frequent enough to send a signal to interested beginners that the
>> project is alive and kicking.  Infrequent enough that there is not
>> much work to be done)
>
> Yep, this sounds great. The natural place is
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev isn't it?
>
>
>> Cheers,
>>     Euan
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Wed Nov 18 07:00:23 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Wed, 18 Nov 2015 14:00:23 +0100
Subject: [Cuis] New Introductory Tutorial
In-Reply-To: <564A77EE.6060802@jvuletich.org>
References: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
	<564A77EE.6060802@jvuletich.org>
Message-ID: <CAGQxfVjCC2J7hBUEMhpYAg95Ti6=assjW-cKs6sG034CVXCv4Q@mail.gmail.com>

Hi Euan

Worthwhile to refer to in your tutorial is as well the web version of
the ProfStef Smalltalk tutorial implemented in Amber Smalltalk

http://amber-smalltalk.github.io/trysmalltalk/

(https://github.com/amber-smalltalk/trysmalltalk)

It explains the syntax, control constructs and some basic classes. It
was first implemented in Pharo and then ported.

--Hannes

On 11/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi EuanM,
>
> This is a great initiative. Thanks for including Cuis in the bunch!
>
> Cheers,
> Juan Vuletich
>
> On 14/11/2015 02:02 a.m., EuanM wrote:
>> I've created Yet Another Smalltalk First
>> Steps tutorial.
>>
>> This is intended as one of a series.
>>
>> It is designed to be cross-platform across
>>
>>      Squeak 5
>>      Pharo 4
>>      Seaside 3.1
>>      Cuis
>>      Dolphin 6
>>
>> If you have experience running any of these systems on Windows, Linux
>> or MacOS, please check to see if I have the instructions correct for
>> your chosen pairing of Smalltalk and OS platform.
>>
>> (As you'll see when you look, I do not have detailed instructions for
>> aspects of MacOS).
>>
>> The document is at:
>> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html
>>
>> (It's intended to move to a different blog after this review process).
>>
>> I feel the need to do this as cross-Smalltalks tutorial because of
>> findings and 4 charts  I've placed at:
>> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/mindshare-of-smalltalk-in-development.html
>>
>> Essentially, Smalltalk mindshare and use is incredibly tiny, compared
>> to other languages in the same space.  (We all know this, but seeing
>> it represented graphically has a more visceral effect, IMO)
>>
>> Aggregating interest in all the Smalltalks still does not bring more
>> than a tiny proportion of the interest in, and use of, Ruby.
>>
>> In turn, Ruby is (quite understandably) small in comparison to
>> JavaScript.
>>
>> Comparing interest in any specific Smalltalk is, predictably, smaller
>> than the aggregate interest in Smalltalk.
>>
>> Our community seems determined to split itself into smaller and
>> smaller sub-communities.  I think we do ourselves a disservice this
>> way.
>>
>> My initial contribution will be to try to provide some explicitly
>> pan-Smalltalk beginners' tutorials, like this one.
>>
>> Cheers, and happy Smalltalking,
>>       EuanM
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Wed Nov 18 07:39:54 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 18 Nov 2015 10:39:54 -0300
Subject: [Cuis] Fwd: Fwd: Patterns
In-Reply-To: <564B7900.2030004@gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
	<564B44B7.2070809@jvuletich.org>
	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
	<CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
	<564B65A2.3050604@jvuletich.org> <564B7900.2030004@gmail.com>
Message-ID: <564C7FAA.90900@jvuletich.org>

Hi Thierry,

(inline and abridged)
On 11/17/2015 3:59 PM, Thierry Goubier wrote:
> Hi Juan,
>
> Le 17/11/2015 18:36, Juan Vuletich a ?crit :
>> Hi Thierry,
>>
> ...
>>> Now, I used to be pretty up to date on the literature and some of the
>>> criticism of the MVC model (especially the division between V and C)
>>> but my memory of that time is all fuzzy.
>>
>> Well, in my opinion View / Model separation is a great property of the
>> design of an application. Controller is more of a requirement of the
>> ST-80 MVC framework. In principle, I see no problem in merging
>> Controller into View. But, in Cuis, it can be argued that the Editor
>> hierarchy is essentially a hierarchy of Controllers, and that's ok if
>> the decomposition of responsibilities makes sense.
>>
>> In View / Model separation there are two restrictions that need to be
>> honored:
>> - The Model doesn't know about the possible Views. This means, for
>> instance, that it could provide all its services, and exercise all its
>> functionality, even if the GUI framework is completely absent. Model
>> code should never fail because of this. This is great for moving models
>> from and two different runtimes (client, server, gemstone, various
>> dialects, etc) and also for writing tests.
>> - Model behavior should not leak into Views. This means that if the
>> views are removed (maybe to be replaced by some others, in the same or
>> in another framework), Model should not lose state nor behavior. Model
>> must be complete by itself.
>> So, the idea is essentially to protect the integrity and consistency of
>> Models.
>
> I do agree with that objective, but, in practice, what I find as a 
> result is that an additional layer (model mediation or the M2 of MMVC) 
> helps immensely by:
>
> - regrouping certain model features which are introduced to satisfy 
> view requirements...
>
>   - For example a pure model can just have a copy or save to file 
> operation, but a view would like to have a feedback on the length of 
> the operation. In non gui mode, having the model expose that sort of 
> information is a needless waste of code and resources. This would 
> better be carried by a layer on top (which is still a model IMHO, 
> since it maintain a certain level of decoupling with a view).
>
> - Expose explicitely certain adaptations which are made for a specific 
> toolkit (they are in that model).
>
> - Allow for user-features oriented models to appear on top of the 
> pure, abstract model
>
>   - In a browser, one can imagine scoped models of the code as a 
> user-oriented feature that a disconnected mode doesn't need to integrate.
>
> Nothing really grandiose or earth-shattering, mind you. Just convenient.

I agree. Many times it is really useful to add another layer. At Caesar 
we called those "Model Extensions".

In many cases, it is possible to do this in a way that is agnostic of 
the actual GUI framework, meaning that it can be used for several GUI 
styles. If this is the case, then it is OK to bundle this with the real 
Model, as it doesn't leak GUI framework specifics.

It is also very desirable not to compromise the consistency of the real 
Model, i.e. not leaking Model specifics. Then, it is also possible to 
bundle this with the Views. (This is what we usually did at Caesar).

If none of this conditions are met, i.e., this "ModelExtension" includes 
Model responsibilities AND detailed GUI framework knowledge, then I'd 
say some refactoring is in order. So, this doesn't go against strict 
View / Model separation.

>>> What would you think of a drag and drop feedback which is dependent of
>>> the type of the model elements?
>>
>> Well, lets assume a Model with 2 collections of elements. To make it
>> sound a bit more concrete, lets call them Orders and Assets. And lets
>> assume that the UI has some place(s) from where the user can drag many
>> kinds of objects, like Orders, Assets, between others. Now, the user
>> drags an Asset and wants to drop it into the Orders list. Given that the
>> widget for the Orders list supports dropping, lets assume that its
>> 'dropActionSelector' is #addOrder:. This #addOrder: model method would
>> be called with an Asset. So, #addOrder: could answer false, to let
>> sender know that the addition was rejected (because it was not an
>> Order!). It makes sense to have the method in ListWidget that calls
>> 'dropSelector' check for the result, and if it is false, let the user
>> know that the drop was rejected, for instance, by keeping the dragged
>> object in the hand.
>
> Hum, I was more thinking of what I am dealing with at the moment, 
> which is a drop in the Orders list is a drop on a specific order item, 
> which has to tell:
>
> - during the drag, if a drop would be honored
> - after the drop, if it is accepted or rejected
> - and, if accepted, that specific order item changes state and is 
> shown as such (and may also change the number of order items, etc...)
>
> I found, when doing that, to have an intermediate model on top of my 
> Asset/Order object to mediate with the drag and drop API very usefull 
> (that is, what is displayed and dragged are Views on AssetModels which 
> are themselves observers of Assets).

This is OK as long as it doesn't leak Model responsibilities, then it 
can just be a Model Extension that goes with the GUI.

>
>>
>>>
>>>
>>>>     So the most elegant way I've used is the two models: a pure,
>>>>     abstract model, totally view independent. And a pragmatic, closer
>>>>     to the view / aware of the view, application model as an mediator.
>>>>
>>>>
>>>>
>>>>                     I think it is better for the View to start it all.
>>>>
>>>>
>>>>                 +1
>>>>
>>>>
>>>>             I prefer to model an Application concept in the target
>>>>             desktop environment if I want to model highly portable 
>>>> stuff.
>>>>
>>>>             That application concern can be folded into a dedicated
>>>>             view if that is the preferred convention in the target
>>>>             environment.
>>>>
>>>>             Regards,
>>>>
>>>>             Thierry
>>>>
>>>>
>>>>         I wonder how would this result in practice. Do you have some
>>>>         examples to share?
>>>>
>>>>
>>>>     I have a complex example, a system browser, would that fit?
>>>
>>>     Sure.
>>>
>>>
>>> Well, a short estimate on that particular application is that, linked
>>> with the pluggable morphs, 10 to 20% of the code in the application
>>> model is:
>>> - widget creation, setup, layout
>>> - dynamic morph addition / removal when activating certain functions
>>> on the model
>>> - workarounds the pluggable morphs api to:
>>>   - dynamically refresh parts of the inside of widgets
>>>   - disconnect then reconnect links between widgets so that the
>>> model-triggered update of one does not change the state of the other
>>> one (i.e. protect the model from unwanted view triggered updates when
>>> the model is changing part of its contents).
>>
>> "View model" is a bit a misleading name. I'd say all this belongs in the
>> Views world.
>
> As I said, it may be moved into the View world, in the sense that it 
> holds view-related concerns. But, at the same time, it has Model like 
> decoupling from the Views.

Yep (as I said above).

>
>> Besides, the method called to update Views after Model changes should
>> not modify the Model. In this way, there would be no extra Model events
>> triggered, and spurious updates would not occur. This might require
>> enhancing the Views framework, if not mature enough.
>
> I'll let you have a try at that :)

Of course. In my experience, these kinds of problems always made the 
framework evolve. Yes, it is important to be able to fix and enhance the 
frameworks you use!

>
>>>
>>> This application model uses mainly two widgets.
>>>
>>> I do have a long term plan to port that to Cuis, and I expect I will
>>> have to write that very same code somewhere (maybe more, maybe less).
>>>
>>> Regards,
>>>
>>> Thierry
>>
>> Hopefully, it will be less :)
>
> I'm certainly looking forward to it.
>
> Regards,
>
> Thierry
>

Thanks for the discussion Thierry. I think we essentially agree on the 
important parts here.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Nov 18 07:42:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 18 Nov 2015 10:42:09 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAEt3aLwUUCU8Qiqt_GphY1-8CpSxpbFSL75zXoAmTPY_hJjG_g@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>	<CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>	<CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>
	<CAEt3aLwUUCU8Qiqt_GphY1-8CpSxpbFSL75zXoAmTPY_hJjG_g@mail.gmail.com>
Message-ID: <564C8031.1040508@jvuletich.org>

On 11/17/2015 2:44 PM, Germ?n Arduino wrote:
>
> 2015-11-17 14:14 GMT-03:00 Luciano Notarfrancesco <luchiano at gmail.com 
> <mailto:luchiano at gmail.com>>:
>
>     On Tue, Nov 17, 2015 at 3:57 PM, Germ?n Arduino
>     <garduino at gmail.com <mailto:garduino at gmail.com>> wrote:
>
>         Awesome!!
>
>
>     Haha, awesome is another window manager, it was also a fork of
>     dwm, I used it for a while ;)
>
>
> Related with this talk, I remember old times helping with LinEx (a 
> Linux made by the Extremadura government in Spain where my friend 
> Diego GD was working using Squeak in education) lot of fun playing 
> with Squeak itself as the Window Manager in charge of such Linux. Very 
> very fun times!
>

Oh! I knew about LinEx, although I never used it. And didn't know about 
using Squeak as the Window Manager! That was also for non-Squeak 
windows, like a Bash terminal?

Thanks,
Juan Vuletih
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151118/200e56f2/attachment-0002.html>

From juan at jvuletich.org  Wed Nov 18 08:00:41 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 18 Nov 2015 11:00:41 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564BEA24.27869.2592A08@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<564AB03D.1040405@gmail.com>, <564B32F5.9050102@jvuletich.org>
	<564BEA24.27869.2592A08@dnorton.mindspring.com>
Message-ID: <564C8489.2000601@jvuletich.org>

Hi Dan,

On 11/18/2015 12:01 AM, Dan Norton wrote:
> The repo now contains two pairs of classes: coupled and decoupled. As it stands, the
> coupled example comes up the same, whether from the World->New morph... menu or from
> a Browser or Workspace.
>
> The decoupled example does not do this and I don't know what to have in the pattern to
> avoid the following pitfalls:
>
> follow the BrowserWindow class #openBrowser and get MNU: owner
> follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs
>
>   - Dan

This is much nicer, thanks! To make the BrowserWindow style work, all 
you have to do is to have #open answer the new instance (instead of the 
class). WRT the ColorEditorPanel style, maybe Ken can comment, or a 
little debugging is in order :)

Cheers,
Juan Vuletich



From Ken.Dickey at Whidbey.com  Thu Nov 19 16:06:17 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 14:06:17 -0800
Subject: [Cuis] Patterns
In-Reply-To: <564C8489.2000601@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<564BEA24.27869.2592A08@dnorton.mindspring.com>
	<564C8489.2000601@jvuletich.org>
Message-ID: <20151119140617.2b8f709d321e79c421f5e7a8@Whidbey.com>

Greetings all!

I have been without power for a few days.  Overhead power lines through forest with 70 mph "wind events" each winter is a guarantee of on-island jobs and the lineman's union is very adverse to underground phone lines.  I must say that this does add interest to the "island living" experience!  8^)

Boy, did I miss a lot of eMail conversations!


On Wed, 18 Nov 2015 11:00:41 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> > follow the BrowserWindow class #openBrowser and get MNU: owner
> > follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs
> >
> >   - Dan

> This is much nicer, thanks! To make the BrowserWindow style work, all 
> you have to do is to have #open answer the new instance (instead of the 
> class). WRT the ColorEditorPanel style, maybe Ken can comment, or a 
> little debugging is in order :)

Actually, I was looking at color backgrounds which would not clash badly with color display and sliders.  Suggestions welcomed.  I still be learning too!

Glad to be back online,
-KenD



From Ken.Dickey at Whidbey.com  Thu Nov 19 16:36:28 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 14:36:28 -0800
Subject: [Cuis] ChromeOS vs Cog VM
Message-ID: <20151119143628.303636338485b6c420e023a7@Whidbey.com>

By the way, I got a chance to work with Tim Rowledge at the Nanaimo Camp Smalltalk.

I'm sure Tim would have rather showed me around the Raspberry Pi VM work, but I have been unable to get any Cog VMs to work on either of my ARM Chromebooks.

CogVM works fine on the ATM RasPi system.

It turns out that Chromebooks are very serious about protecting maximally against code hijacking.  They don't allow arbitrary code to be written into memory and executed.

This is very good for safety in an uncertain world, but is also the definition of Just-In-Time code generation.

I expected that Google's V8 JavaScript, which JITs, would show how to do this sanely under ChromeOS so that we could Cog it, but the code base for V8 shows that they only run the bytecodes -- no JIT -- on Chromebooks.


There is hope for the future, but some changes will be required:
See 

"Exploiting and Protecting Dynamic Code Generation"

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjguP_RxJ3JAhXQT4gKHS2VAUYQFggeMAA&url=http%3A%2F%2Fwenke.gtisc.gatech.edu%2Fpapers%2Fsdcg.pdf&usg=AFQjCNF52_QFDuMcP05WvfeHNi2wUK-yHg&sig2=8SzTcWKA7VBubmzdzJmIiA


Google's "Safe Self-Modifying Code" patent: (Patent! Ack!! 8^{)

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwilmsKlxZ3JAhVRKYgKHfXgDOMQFgg5MAM&url=http%3A%2F%2Fwww.google.com%2Fpatents%2FUS8850574&usg=AFQjCNHTAbYqbvqy80Edcww1YDsgUvoKMQ&sig2=FK01uFZEn778RNmRm7iz4A


Also "Certified Self-Modifying Code"

http://flint.cs.yale.edu/flint/publications/smctr.pdf

More hoops, sigh.

FYI,
-KenD



From Ken.Dickey at Whidbey.com  Thu Nov 19 16:38:31 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 14:38:31 -0800
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
Message-ID: <20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>

On Thu, 19 Nov 2015 14:36:28 -0800
KenD <Ken.Dickey at Whidbey.com> wrote:

> CogVM works fine on the ATM RasPi system.

Sorry.  That is the _ARM_ Raspberry Pi system.

Sausage fingers, sigh.
-KenD



From 0800nacho at gmail.com  Thu Nov 19 17:02:53 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Thu, 19 Nov 2015 20:02:53 -0300
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>
Message-ID: <CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w@mail.gmail.com>

In my x86 chromebook I had to chroot through crouton and run Cuis from
there.
It seems that porting the VM to NaCL is indeed a daunting job....
Perhaps once web assembly is there, things turn a little easier, I don't
know.
cheers!


*Lic. Ignacio Sniechowski, MBA*
*Prosavic SRL*

*Tel: (011) 4542-6714*


















On Thu, Nov 19, 2015 at 7:38 PM, KenD <Ken.Dickey at whidbey.com> wrote:

> On Thu, 19 Nov 2015 14:36:28 -0800
> KenD <Ken.Dickey at Whidbey.com> wrote:
>
> > CogVM works fine on the ATM RasPi system.
>
> Sorry.  That is the _ARM_ Raspberry Pi system.
>
> Sausage fingers, sigh.
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151119/53227dca/attachment-0002.html>

From Ken.Dickey at Whidbey.com  Thu Nov 19 18:27:32 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 16:27:32 -0800
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w@mail.gmail.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>
	<CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w@mail.gmail.com>
Message-ID: <20151119162732.d1620999640219efc0ace630@Whidbey.com>

On Thu, 19 Nov 2015 20:02:53 -0300
Ignacio Sniechowski <0800nacho at gmail.com> wrote:

> In my x86 chromebook I had to chroot through crouton and run Cuis from
> there.

That is what I am doing, using the stack-vm for ARM.


> It seems that porting the VM to NaCL is indeed a daunting job....

So it would appear..


Cheers, 
-KenD



From euanmee at gmail.com  Fri Nov 20 20:10:23 2015
From: euanmee at gmail.com (EuanM)
Date: Sat, 21 Nov 2015 02:10:23 +0000
Subject: [Cuis] ChromeOS vs Cog VM
Message-ID: <CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>

We can run Smalltalk on our ARM ChromeBooks!?!?

Where's the nearest How-to?


On 20 November 2015 at 18:00,  <cuis-request at jvuletich.org> wrote:
> Send Cuis mailing list submissions to
>         cuis at jvuletich.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> or, via email, send a message with subject or body 'help' to
>         cuis-request at jvuletich.org
>
> You can reach the person managing the list at
>         cuis-owner at jvuletich.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cuis digest..."
>
>
> Today's Topics:
>
>    1. Re: Patterns (KenD)
>    2. ChromeOS vs Cog VM (KenD)
>    3. Re: ChromeOS vs Cog VM (KenD)
>    4. Re: ChromeOS vs Cog VM (Ignacio Sniechowski)
>    5. Re: ChromeOS vs Cog VM (KenD)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Nov 2015 14:06:17 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Subject: Re: [Cuis] Patterns
> Message-ID: <20151119140617.2b8f709d321e79c421f5e7a8 at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> Greetings all!
>
> I have been without power for a few days.  Overhead power lines through forest with 70 mph "wind events" each winter is a guarantee of on-island jobs and the lineman's union is very adverse to underground phone lines.  I must say that this does add interest to the "island living" experience!  8^)
>
> Boy, did I miss a lot of eMail conversations!
>
>
> On Wed, 18 Nov 2015 11:00:41 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
>
>> > follow the BrowserWindow class #openBrowser and get MNU: owner
>> > follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs
>> >
>> >   - Dan
>
>> This is much nicer, thanks! To make the BrowserWindow style work, all
>> you have to do is to have #open answer the new instance (instead of the
>> class). WRT the ColorEditorPanel style, maybe Ken can comment, or a
>> little debugging is in order :)
>
> Actually, I was looking at color backgrounds which would not clash badly with color display and sliders.  Suggestions welcomed.  I still be learning too!
>
> Glad to be back online,
> -KenD
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 Nov 2015 14:36:28 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: tim Rowledge <tim at rowledge.org>
> Subject: [Cuis] ChromeOS vs Cog VM
> Message-ID: <20151119143628.303636338485b6c420e023a7 at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> By the way, I got a chance to work with Tim Rowledge at the Nanaimo Camp Smalltalk.
>
> I'm sure Tim would have rather showed me around the Raspberry Pi VM work, but I have been unable to get any Cog VMs to work on either of my ARM Chromebooks.
>
> CogVM works fine on the ATM RasPi system.
>
> It turns out that Chromebooks are very serious about protecting maximally against code hijacking.  They don't allow arbitrary code to be written into memory and executed.
>
> This is very good for safety in an uncertain world, but is also the definition of Just-In-Time code generation.
>
> I expected that Google's V8 JavaScript, which JITs, would show how to do this sanely under ChromeOS so that we could Cog it, but the code base for V8 shows that they only run the bytecodes -- no JIT -- on Chromebooks.
>
>
> There is hope for the future, but some changes will be required:
> See
>
> "Exploiting and Protecting Dynamic Code Generation"
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjguP_RxJ3JAhXQT4gKHS2VAUYQFggeMAA&url=http%3A%2F%2Fwenke.gtisc.gatech.edu%2Fpapers%2Fsdcg.pdf&usg=AFQjCNF52_QFDuMcP05WvfeHNi2wUK-yHg&sig2=8SzTcWKA7VBubmzdzJmIiA
>
>
> Google's "Safe Self-Modifying Code" patent: (Patent! Ack!! 8^{)
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwilmsKlxZ3JAhVRKYgKHfXgDOMQFgg5MAM&url=http%3A%2F%2Fwww.google.com%2Fpatents%2FUS8850574&usg=AFQjCNHTAbYqbvqy80Edcww1YDsgUvoKMQ&sig2=FK01uFZEn778RNmRm7iz4A
>
>
> Also "Certified Self-Modifying Code"
>
> http://flint.cs.yale.edu/flint/publications/smctr.pdf
>
> More hoops, sigh.
>
> FYI,
> -KenD
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 19 Nov 2015 14:38:31 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: tim Rowledge <tim at rowledge.org>
> Subject: Re: [Cuis] ChromeOS vs Cog VM
> Message-ID: <20151119143831.7d441ccd80e851e278a5d16d at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 19 Nov 2015 14:36:28 -0800
> KenD <Ken.Dickey at Whidbey.com> wrote:
>
>> CogVM works fine on the ATM RasPi system.
>
> Sorry.  That is the _ARM_ Raspberry Pi system.
>
> Sausage fingers, sigh.
> -KenD
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 19 Nov 2015 20:02:53 -0300
> From: Ignacio Sniechowski <0800nacho at gmail.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: tim Rowledge <tim at rowledge.org>
> Subject: Re: [Cuis] ChromeOS vs Cog VM
> Message-ID:
>         <CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> In my x86 chromebook I had to chroot through crouton and run Cuis from
> there.
> It seems that porting the VM to NaCL is indeed a daunting job....
> Perhaps once web assembly is there, things turn a little easier, I don't
> know.
> cheers!
>
>
> *Lic. Ignacio Sniechowski, MBA*
> *Prosavic SRL*
>
> *Tel: (011) 4542-6714*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Nov 19, 2015 at 7:38 PM, KenD <Ken.Dickey at whidbey.com> wrote:
>
>> On Thu, 19 Nov 2015 14:36:28 -0800
>> KenD <Ken.Dickey at Whidbey.com> wrote:
>>
>> > CogVM works fine on the ATM RasPi system.
>>
>> Sorry.  That is the _ARM_ Raspberry Pi system.
>>
>> Sausage fingers, sigh.
>> -KenD
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151119/53227dca/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 19 Nov 2015 16:27:32 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: cuis at jvuletich.org
> Subject: Re: [Cuis] ChromeOS vs Cog VM
> Message-ID: <20151119162732.d1620999640219efc0ace630 at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 19 Nov 2015 20:02:53 -0300
> Ignacio Sniechowski <0800nacho at gmail.com> wrote:
>
>> In my x86 chromebook I had to chroot through crouton and run Cuis from
>> there.
>
> That is what I am doing, using the stack-vm for ARM.
>
>
>> It seems that porting the VM to NaCL is indeed a daunting job....
>
> So it would appear..
>
>
> Cheers,
> -KenD
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 41, Issue 29
> ************************************



From 0800nacho at gmail.com  Sat Nov 21 06:53:02 2015
From: 0800nacho at gmail.com (nacho)
Date: Sat, 21 Nov 2015 04:53:02 -0800 (PST)
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>
Message-ID: <1448110382723-4862380.post@n4.nabble.com>

Yes Euan,
However bear in mind two things:
1) You have to put your Chromebook into developer mode. See here on how to
do it and what it means.
http://www.howtogeek.com/210817/how-to-enable-developer-mode-on-your-chromebook/

2) You have to install Crouton. Crouton chroots your ChromeOS with the Linux
equivalente (usually an Ubuntu, but other flavours my be chosen). See here
on how to install it, and all the options you have.
https://github.com/dnschneid/crouton

3) Install the Crouton extension, really helps.

4) Install an ARM based VM (check in Eliot Miranda place)
http://www.mirandabanda.org/files/Cog/VM/ and for a classic VM in
http://www.squeakvm.org/unix/

And that should do it.
Cheers
Nacho 



-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/ChromeOS-vs-Cog-VM-tp4862115p4862380.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Sat Nov 21 10:47:08 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sat, 21 Nov 2015 08:47:08 -0800
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <1448110382723-4862380.post@n4.nabble.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>
	<1448110382723-4862380.post@n4.nabble.com>
Message-ID: <20151121084708.d29f22f6470bb56c300f7e48@Whidbey.com>

On Sat, 21 Nov 2015 04:53:02 -0800 (PST)
nacho <0800nacho at gmail.com> wrote:

> 4) Install an ARM based VM (check in Eliot Miranda place)
> http://www.mirandabanda.org/files/Cog/VM/ and for a classic VM in
> http://www.squeakvm.org/unix/

Nacho,

Great instructions.  I do almost all my work on an ARM Chromebook these days.

FYI I am using stklinuxhtARM-15.24.3386.tgz

Few of the Cog builds do stklinuxhtARM.

Cheers,
-KenD



From Ken.Dickey at whidbey.com  Fri Nov 20 23:47:36 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sat, 21 Nov 2015 13:47:36 +0800
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
	<564A7925.4060103@jvuletich.org>
	<CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>
Message-ID: <20151121134736.8c5073e5fbb43076d2defbf7@whidbey.com>

On Wed, 18 Nov 2015 08:02:05 +0100
"H. Hirzel" <hannes.hirzel at gmail.com> wrote:

> It is worthwhile to have a look as well at the Squeak all-in-one package.
> 
> I have done it in the past in an adhoc way about by taking
> http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.

Note that Squeak 5.0 uses the new Spur memory format which is incompatable with the older (4.x and Cuis) image format. 

Cheers,
-KenD



From euanmee at gmail.com  Sun Nov 22 17:05:26 2015
From: euanmee at gmail.com (EuanM)
Date: Sun, 22 Nov 2015 23:05:26 +0000
Subject: [Cuis] One-Click Installer for Cuis
Message-ID: <CALsRT0nu5CeinNX_8jjP=RvrJKkmMu18kNwEN-fLSq4KCALi4A@mail.gmail.com>

That's a useful thing to know!

Is there a sense of when Cuis will be able to use the Spur VM?  Squeak
5.0 is *much* faster on ARM than Squeak 4.6 (thanks to Tim Rowledge
and co).

And my own usecase for Cuis is the Raspberry Pi.  (and of course, now
also development on my Chromebook)

Cheers,
    EuanM

On 22 November 2015 at 18:00,  <cuis-request at jvuletich.org> wrote:
> Date: Sat, 21 Nov 2015 13:47:36 +0800
> From: "Ken.Dickey" <Ken.Dickey at whidbey.com>
>
> On Wed, 18 Nov 2015 08:02:05 +0100
> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>
>> It is worthwhile to have a look as well at the Squeak all-in-one package.
>>
>> I have done it in the past in an adhoc way about by taking
>> http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.
>
> Note that Squeak 5.0 uses the new Spur memory format which is incompatable with the older (4.x and Cuis) image format.
>
> Cheers,
> -KenD
>



From juan at jvuletich.org  Mon Nov 23 06:59:47 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 23 Nov 2015 09:59:47 -0300
Subject: [Cuis] New updates
Message-ID: <56530DC3.3040609@jvuletich.org>

Hi all,

I recently included some new updates:

- Fixes to Exceptions by Andr?s Valloud and Martin McClure.
- Assessments framework for testing and validation by Andr?s Valloud.
- Many fixes and enhancements to Layouts, Window drawing, keyboard 
shortcuts, etc. by Luciano Notarfrancesco

Thank you very much Folks! Andr?s, Luciano, please comment a bit on what 
you did, especially subtle but important behavior such as Exceptions and 
new stuff like Assessments, and the new Theme and Window Manager.

Cheers,
Juan Vuletich



From 0800nacho at gmail.com  Mon Nov 23 08:37:07 2015
From: 0800nacho at gmail.com (nacho)
Date: Mon, 23 Nov 2015 06:37:07 -0800 (PST)
Subject: [Cuis] Basic & probably stupid question.
Message-ID: <1448289427985-4862695.post@n4.nabble.com>

Hi Folks,
I'm trying an example from Inside Smalltalk vol.1

When I try to print:

| anArray |
anArray _ Array new.
anArray at: 1 put: 'hello'; at: 2 put: 'nacho'; at: 3 put: 'pepito'.

I receive:
subscript is out of bounds: 1
Where as according to the book I should receive the 3th element.

The same happens when I try to print:
| anArray |
anArray _ Array new.
anArray at: 1 put: 'hello'; at: 2 put: 'nacho'; at: 3 put: 'pepito';
yourself.

which according to the book should return anArray.

is the at:put: selector different in Cuis?
Thanks in advance
Nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Basic-probably-stupid-question-tp4862695.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From 0800nacho at gmail.com  Mon Nov 23 08:44:27 2015
From: 0800nacho at gmail.com (nacho)
Date: Mon, 23 Nov 2015 06:44:27 -0800 (PST)
Subject: [Cuis] Basic & probably stupid question.
In-Reply-To: <1448289427985-4862695.post@n4.nabble.com>
References: <1448289427985-4862695.post@n4.nabble.com>
Message-ID: <1448289867935-4862701.post@n4.nabble.com>

I figured it out.
It was indeed a stupid question.
Arrays are fixed so I should do:
anArray _ Array new: 3.

cheers




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Basic-probably-stupid-question-tp4862695p4862701.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From luchiano at gmail.com  Mon Nov 23 09:35:06 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Mon, 23 Nov 2015 15:35:06 +0000
Subject: [Cuis] New updates
In-Reply-To: <56530DC3.3040609@jvuletich.org>
References: <56530DC3.3040609@jvuletich.org>
Message-ID: <CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>

Hi all,
About my recent changes, some of them are 1) extensions to Theme to be able
to customize some more aspects of how the windows and widgets look, or 2)
fixes for small bugs that I found on the way, like misalignments of a few
pixels between parts of a widget or a window. The motivation behind this
was just to be able to implement a very minimalist look (borders of just 1
pixel, no decorations, no icons, no anything that I dont need and takes up
screen real estate), and a sort of tiling dynamic window manager very much
like http://dwm.suckless.org (https://github.com/len/Cuis-Smalltalk-DWM).

In order to implement this "window manager" as an external package with
minimal changes to the core system, I decided to: 1) make the current Theme
receive messages #windowOpen: #windowClosed: every time SystemWindows are
open or closed, in order to give it a chance to implement window-management
behaviour or delegate it to a proper window manager; 2) move the
window-management keyboard shortcuts (like alt-w to close) to Theme, so it
is all in one place, easy to change, and easy to make a Theme that
delegates keyboard events to a proper window manager.

Again I did it like this in order to minimize changes to the core system.
At the moment window management is in part implemented in SystemWindow, and
also in HandMorph and Morph. I had to make some small modifications in
order to get the desired behavior when using DWM, and keep the original
behavior in the base system. Maybe in the long run we would want to have a
WindowManager class that do this, handle keyboard events for the
window-management shortcuts and receives #windowOpen: and #windowClosed:,
etc. But I would like to think better about this before adding new concepts
and complexity to the core.

Cheers,
Luciano


On Mon, Nov 23, 2015 at 12:59 PM, Juan Vuletich <juan at jvuletich.org> wrote:

> Hi all,
>
> I recently included some new updates:
>
> - Fixes to Exceptions by Andr?s Valloud and Martin McClure.
> - Assessments framework for testing and validation by Andr?s Valloud.
> - Many fixes and enhancements to Layouts, Window drawing, keyboard
> shortcuts, etc. by Luciano Notarfrancesco
>
> Thank you very much Folks! Andr?s, Luciano, please comment a bit on what
> you did, especially subtle but important behavior such as Exceptions and
> new stuff like Assessments, and the new Theme and Window Manager.
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151123/42175fe6/attachment-0002.html>

From hannes.hirzel at gmail.com  Tue Nov 24 08:56:19 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 24 Nov 2015 15:56:19 +0100
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <20151121134736.8c5073e5fbb43076d2defbf7@whidbey.com>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
	<564A7925.4060103@jvuletich.org>
	<CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>
	<20151121134736.8c5073e5fbb43076d2defbf7@whidbey.com>
Message-ID: <CAGQxfVh++xk8YNESwEgwGM-2OXOx2O_fckMtWJDS5v-EQSN6oA@mail.gmail.com>

On 11/21/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Wed, 18 Nov 2015 08:02:05 +0100
> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>
>> It is worthwhile to have a look as well at the Squeak all-in-one package.
>>
>> I have done it in the past in an adhoc way about by taking
>> http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.
>
> Note that Squeak 5.0 uses the new Spur memory format which is incompatable
> with the older (4.x and Cuis) image format.

Thanks, Ken for the correction. I based the ad-hoc Cuis all-in-one on
http://ftp.squeak.org/4.6/Squeak-4.6-All-in-One.zip

--Hannes

>
> Cheers,
> -KenD
>



From Ken.Dickey at Whidbey.com  Tue Nov 24 18:08:31 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Tue, 24 Nov 2015 16:08:31 -0800
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <CALsRT0nu5CeinNX_8jjP=RvrJKkmMu18kNwEN-fLSq4KCALi4A@mail.gmail.com>
References: <CALsRT0nu5CeinNX_8jjP=RvrJKkmMu18kNwEN-fLSq4KCALi4A@mail.gmail.com>
Message-ID: <20151124160831.2314ed8c9a831809c0321069@Whidbey.com>

On Sun, 22 Nov 2015 23:05:26 +0000
EuanM <euanmee at gmail.com> wrote:

> Is there a sense of when Cuis will be able to use the Spur VM?  

You pushed me over the edge.  I am now/currently working on this.

> > Note that Squeak 5.0 uses the new Spur memory format which is incompatable with the older (4.x and Cuis) image format.

FYI, stkspurlinuxhtARM-15.24.3386.tgz can run Squeak 5.0 images on an ARM Chromebook under Crouton/Ubuntu.

Cheers,
-KenD



From luchiano at gmail.com  Thu Nov 26 00:53:52 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Thu, 26 Nov 2015 06:53:52 +0000
Subject: [Cuis] image segments
Message-ID: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>

I don't see image segments in Cuis... I don't even know if they still exist
in Squeak... Anyone is still using it?

It would be cool to have it at least as a package. If I remember correctly
it was very simple, like two primitives to load and save, but I think it
depended on something like mark and sweep or some particular kind of
garbage collector and it might not work in new VMs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151126/8333877d/attachment-0002.html>

From hannes.hirzel at gmail.com  Thu Nov 26 01:36:49 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 07:36:49 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
Message-ID: <CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>

Squeak 5.0 still has ImageSegments (class comment below). Saving and
loading of  projects currently is blocked in Squeak because of an
unfinished name space (environments implementation).

http://wiki.squeak.org/squeak/6218

And there is Fuel
http://rmod.inria.fr/web/software/Fuel

----------

ImageSegment

I represent a segment of Squeak address space.  I am created from an
array of root objects.  After storing, my segment contains a binary
encoding of every object accessible from my roots but not otherwise
accessible from anywhere else in the system.  My segment contains
outward pointers that are indices into my table of outPointers.
On load my segment is converted back into objects and becommed
into an Array of the loaded objects, so they can be enumerated.

	The main use of ImageSegments is to store Projects.  A dummy
version of SmartRefStream traverses the Project.  Everything it finds
is classified as either an object that is owned by the project (only
pointed to inside the project), or an object outside the project that
is pointed to from inside the project.  The objects that are
completely owned by the project are compressed into pure binary form
in an ImageSegment.  The outside objects are put in the 'outPointers'
array.  The entire ImageSegment (binary part plus outPointers) is
encoded in a SmartRefStream, and saved on the disk.  (aProject
exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
writeForExportWithSources:inDirectory:changeSet:).

	Note that every object inside the project is put into the
segment's arrayOfRoots.  This is because a dummy SmartRefStream to
scan the project, in order to make intelligent decisions about what
belongs in the project.
	See Project's class comment for what messages are sent to
objects as they are unpacked in a new image.

---- Older Details ------

	The primary kind of image segment is an Export Segment.  It
can be saved on a server and read into a completely different Squeak
image.
Old way to create one:
(ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz class))
		writeForExport: 'myFile.extSeg'.
Old way to create one for a project:
	(Project named: 'Play With Me - 3') exportSegment.
To read it into another image:  Select 'myFile.extSeg' in a FileList,
Menu 'load as project'.  It will install its classes automatically.
If you need to see the roots array, it is temporarily stored in
(SmartRefStream scannedObject).

Most of 'states' of an ImageSegment are not used to export a project,
and have been abandoned.

	When a segment is written out onto a file, it goes in a
folder called <image name>_segs.  If your image is called
"Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
image whenever your move, copy, or rename it.
	Whenever a Class is in arrayOfRoots, its class (aClass class)
must also be in the arrayOfRoots.
	There are two kinds of image segments.  Normal image segments
are a piece of a specific Squeak image, and can only be read back
into that image.  The image holds the array of outPointers that are
necessary to turn the bits in the file into objects.
	To put out a normal segment that holds a Project (not the
current project), execute (Project named: 'xxx') storeSegment.


arrayOfRoots	The objects that head the tree we will trace.
segment			The WordArray of raw bits of all objects in the tree.
outPointers		Oops of all objects outside the segment
pointed to from inside.
state			(see below)
segmentName	Its basic name.  Often the name of a Project.
fileName		The local name of the file.  'Foo-23.seg'
userRootCnt		number of roots submitted by caller.  Extras
are added in preparation for saving.

state that an ImageSegment may exist in...

#activeCopy			(has been copied, with the intent to
become active)
arrayOfRoots, segment, and outPointers have been created by
copyFromRoots:.  The tree of objects has been encoded in the segment,
but those objects are still present in the Squeak system.

#active				(segment is actively holding objects)
The segment is now the only holder of tree of objects.  Each of the
original roots has been transmuted into an ImageSegmentRootStub that
refers back to this image segment.  The original objects in the
segment will all be garbageCollected.

#onFile
The segment has been written out to a file and replaced by a file
pointer.  Only ImageSegmentRootStubs and the array of outPointers
remains in the image.  To get this far:
(ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
		writeToFile: 'myFile.seg'.

#inactive
The segment has been brought back into memory and turned back into
objects.  rootsArray is set, but the segment is invalid.

#onFileWithSymbols
The segment has been written out to a file, along with the text of
all the symbols in the outPointers array, and replaced by a file
pointer.  This reduces the size of the outPointers array, and also
allows the system to reclaim any symbols that are not referred to
from elsewhere in the image.  The specific format used is that of a
literal array as follows:
	#(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' # symbol5).
In this case, the original outPointers array was 8 long, but the
compacted table of outPointers retains only two entries.  These get
inserted in place of the #'s in the array of symbols after it is read
back in.  Symbols with embedded spaces or other strange characters
are written as strings, and converted back to symbols when read back
in.  The symbol # is never written out.
	NOTE: All IdentitySets or dictionaries must be rehashed when
being read back from this format.  The symbols are effectively
internal.  (No, not if read back into same image.  If a different
image, then use #imported.  -tk)

#imported
The segment is on an external file or just read in from one.  The
segment and outPointers are meant to be read into a foreign image.
In this form, the image segment can be read from a URL, and
installed.  A copy of the original array of root objects is
constructed, with former outPointers bound to existing objects in the
host system.
	(Any Class inside the segment MUST be in the arrayOfRoots.
This is so its association can be inserted into Smalltalk.  The
class's metaclass must be in roots also.  Methods that are in
outPointers because blocks point at them, were found and added to the
roots.
	All IdentitySets and dictionaries are rehashed when being
read back from exported segments.)


To discover why only some of the objects in a project are being
written out, try this (***Destructive Test***).  This breaks lots of
backpointers in the target project, and puts up an array of
suspicious objects, a list of the classes of the outPointers, and a
debugger.
"Close any transcripts in the target project"
World currentHand objectToPaste ifNotNil: [
	self inform: 'Hand is holding a Morph in its paste buffer:\' withCRs,
		World currentHand objectToPaste printString].
PV := Project named: 'xxxx'.
(IS := ImageSegment new) findRogueRootsImSeg:
	(Array with: PV world presenter with: PV world).
IS findOwnersOutPtrs.	"Optionally: write a file with owner chains"
"Quit and DO NOT save"

When an export image segment is brought into an image, it is like an
image starting up.  Certain startUp messages need to be run.  These
are byte and word reversals for nonPointer data that comes from a
machine of the opposite endianness.  #startUpProc passes over all
objects in the segment, and:
	The first time an instance of class X is encountered, (msg _
X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
case, it means that instances of X do not need special work.  X is
included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
store it in the dictionary, startUps (aClass -> aMessage).
	When a later instance of X is encountered, if X is in
noStartUpNeeded, do nothing.  If X is in startUps, send the message
to the instance.  Typically this is a message like #swapShortObjects.
	Every class that implements #startUp, should see if it needs
a parallel implementation of #startUpFrom:.

On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> I don't see image segments in Cuis... I don't even know if they still exist
> in Squeak... Anyone is still using it?
>
> It would be cool to have it at least as a package. If I remember correctly
> it was very simple, like two primitives to load and save, but I think it
> depended on something like mark and sweep or some particular kind of
> garbage collector and it might not work in new VMs.
>



From hannes.hirzel at gmail.com  Thu Nov 26 02:02:11 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 08:02:11 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
Message-ID: <CAGQxfVg0Oy-b5b-fZJwL39Zb_SnKhqiiti4mcK6wonNrrSMUPA@mail.gmail.com>

P.S. For a working version of Project save/load in Squeak go back to
version 4.4 or maybe 4.3

http://squeak.org/downloads/

On 11/26/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Squeak 5.0 still has ImageSegments (class comment below). Saving and
> loading of  projects currently is blocked in Squeak because of an
> unfinished name space (environments implementation).
>
> http://wiki.squeak.org/squeak/6218
>
> And there is Fuel
> http://rmod.inria.fr/web/software/Fuel
>
> ----------
>
> ImageSegment
>
> I represent a segment of Squeak address space.  I am created from an
> array of root objects.  After storing, my segment contains a binary
> encoding of every object accessible from my roots but not otherwise
> accessible from anywhere else in the system.  My segment contains
> outward pointers that are indices into my table of outPointers.
> On load my segment is converted back into objects and becommed
> into an Array of the loaded objects, so they can be enumerated.
>
> 	The main use of ImageSegments is to store Projects.  A dummy
> version of SmartRefStream traverses the Project.  Everything it finds
> is classified as either an object that is owned by the project (only
> pointed to inside the project), or an object outside the project that
> is pointed to from inside the project.  The objects that are
> completely owned by the project are compressed into pure binary form
> in an ImageSegment.  The outside objects are put in the 'outPointers'
> array.  The entire ImageSegment (binary part plus outPointers) is
> encoded in a SmartRefStream, and saved on the disk.  (aProject
> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
> writeForExportWithSources:inDirectory:changeSet:).
>
> 	Note that every object inside the project is put into the
> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
> scan the project, in order to make intelligent decisions about what
> belongs in the project.
> 	See Project's class comment for what messages are sent to
> objects as they are unpacked in a new image.
>
> ---- Older Details ------
>
> 	The primary kind of image segment is an Export Segment.  It
> can be saved on a server and read into a completely different Squeak
> image.
> Old way to create one:
> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
> class))
> 		writeForExport: 'myFile.extSeg'.
> Old way to create one for a project:
> 	(Project named: 'Play With Me - 3') exportSegment.
> To read it into another image:  Select 'myFile.extSeg' in a FileList,
> Menu 'load as project'.  It will install its classes automatically.
> If you need to see the roots array, it is temporarily stored in
> (SmartRefStream scannedObject).
>
> Most of 'states' of an ImageSegment are not used to export a project,
> and have been abandoned.
>
> 	When a segment is written out onto a file, it goes in a
> folder called <image name>_segs.  If your image is called
> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
> image whenever your move, copy, or rename it.
> 	Whenever a Class is in arrayOfRoots, its class (aClass class)
> must also be in the arrayOfRoots.
> 	There are two kinds of image segments.  Normal image segments
> are a piece of a specific Squeak image, and can only be read back
> into that image.  The image holds the array of outPointers that are
> necessary to turn the bits in the file into objects.
> 	To put out a normal segment that holds a Project (not the
> current project), execute (Project named: 'xxx') storeSegment.
>
>
> arrayOfRoots	The objects that head the tree we will trace.
> segment			The WordArray of raw bits of all objects in the tree.
> outPointers		Oops of all objects outside the segment
> pointed to from inside.
> state			(see below)
> segmentName	Its basic name.  Often the name of a Project.
> fileName		The local name of the file.  'Foo-23.seg'
> userRootCnt		number of roots submitted by caller.  Extras
> are added in preparation for saving.
>
> state that an ImageSegment may exist in...
>
> #activeCopy			(has been copied, with the intent to
> become active)
> arrayOfRoots, segment, and outPointers have been created by
> copyFromRoots:.  The tree of objects has been encoded in the segment,
> but those objects are still present in the Squeak system.
>
> #active				(segment is actively holding objects)
> The segment is now the only holder of tree of objects.  Each of the
> original roots has been transmuted into an ImageSegmentRootStub that
> refers back to this image segment.  The original objects in the
> segment will all be garbageCollected.
>
> #onFile
> The segment has been written out to a file and replaced by a file
> pointer.  Only ImageSegmentRootStubs and the array of outPointers
> remains in the image.  To get this far:
> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
> 		writeToFile: 'myFile.seg'.
>
> #inactive
> The segment has been brought back into memory and turned back into
> objects.  rootsArray is set, but the segment is invalid.
>
> #onFileWithSymbols
> The segment has been written out to a file, along with the text of
> all the symbols in the outPointers array, and replaced by a file
> pointer.  This reduces the size of the outPointers array, and also
> allows the system to reclaim any symbols that are not referred to
> from elsewhere in the image.  The specific format used is that of a
> literal array as follows:
> 	#(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' # symbol5).
> In this case, the original outPointers array was 8 long, but the
> compacted table of outPointers retains only two entries.  These get
> inserted in place of the #'s in the array of symbols after it is read
> back in.  Symbols with embedded spaces or other strange characters
> are written as strings, and converted back to symbols when read back
> in.  The symbol # is never written out.
> 	NOTE: All IdentitySets or dictionaries must be rehashed when
> being read back from this format.  The symbols are effectively
> internal.  (No, not if read back into same image.  If a different
> image, then use #imported.  -tk)
>
> #imported
> The segment is on an external file or just read in from one.  The
> segment and outPointers are meant to be read into a foreign image.
> In this form, the image segment can be read from a URL, and
> installed.  A copy of the original array of root objects is
> constructed, with former outPointers bound to existing objects in the
> host system.
> 	(Any Class inside the segment MUST be in the arrayOfRoots.
> This is so its association can be inserted into Smalltalk.  The
> class's metaclass must be in roots also.  Methods that are in
> outPointers because blocks point at them, were found and added to the
> roots.
> 	All IdentitySets and dictionaries are rehashed when being
> read back from exported segments.)
>
>
> To discover why only some of the objects in a project are being
> written out, try this (***Destructive Test***).  This breaks lots of
> backpointers in the target project, and puts up an array of
> suspicious objects, a list of the classes of the outPointers, and a
> debugger.
> "Close any transcripts in the target project"
> World currentHand objectToPaste ifNotNil: [
> 	self inform: 'Hand is holding a Morph in its paste buffer:\' withCRs,
> 		World currentHand objectToPaste printString].
> PV := Project named: 'xxxx'.
> (IS := ImageSegment new) findRogueRootsImSeg:
> 	(Array with: PV world presenter with: PV world).
> IS findOwnersOutPtrs.	"Optionally: write a file with owner chains"
> "Quit and DO NOT save"
>
> When an export image segment is brought into an image, it is like an
> image starting up.  Certain startUp messages need to be run.  These
> are byte and word reversals for nonPointer data that comes from a
> machine of the opposite endianness.  #startUpProc passes over all
> objects in the segment, and:
> 	The first time an instance of class X is encountered, (msg _
> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
> case, it means that instances of X do not need special work.  X is
> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
> store it in the dictionary, startUps (aClass -> aMessage).
> 	When a later instance of X is encountered, if X is in
> noStartUpNeeded, do nothing.  If X is in startUps, send the message
> to the instance.  Typically this is a message like #swapShortObjects.
> 	Every class that implements #startUp, should see if it needs
> a parallel implementation of #startUpFrom:.
>
> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>> I don't see image segments in Cuis... I don't even know if they still
>> exist
>> in Squeak... Anyone is still using it?
>>
>> It would be cool to have it at least as a package. If I remember
>> correctly
>> it was very simple, like two primitives to load and save, but I think it
>> depended on something like mark and sweep or some particular kind of
>> garbage collector and it might not work in new VMs.
>>
>



From luchiano at gmail.com  Thu Nov 26 08:10:21 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Thu, 26 Nov 2015 14:10:21 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
Message-ID: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>

Cool, maybe it's possible to make it into a package, I'll take a look.

I've never used it to store Projects, tho..  I used before to store things
that must be loaded very fast on demand and can be forgotten once there are
no more references to them.. like image fragments that compose a map of the
world, and small sound fragments that are used to synthesize speech
(diphones). Yesterday I just wanted to know how big are my objects, and I
wanted to make some experiments to see how the bit-size of my objects grow
as the problems I'm modeling grow by some other measure (degree of
polynomials, size of matrices are the most basic) and to know how much
memory are my algorithms actually using at every step... image segments are
ideal for this, you can use them to know exactly how much memory would be
freed if a reference to a given object were forgotten.


On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> Squeak 5.0 still has ImageSegments (class comment below). Saving and
> loading of  projects currently is blocked in Squeak because of an
> unfinished name space (environments implementation).
>
> http://wiki.squeak.org/squeak/6218
>
> And there is Fuel
> http://rmod.inria.fr/web/software/Fuel
>
> ----------
>
> ImageSegment
>
> I represent a segment of Squeak address space.  I am created from an
> array of root objects.  After storing, my segment contains a binary
> encoding of every object accessible from my roots but not otherwise
> accessible from anywhere else in the system.  My segment contains
> outward pointers that are indices into my table of outPointers.
> On load my segment is converted back into objects and becommed
> into an Array of the loaded objects, so they can be enumerated.
>
>         The main use of ImageSegments is to store Projects.  A dummy
> version of SmartRefStream traverses the Project.  Everything it finds
> is classified as either an object that is owned by the project (only
> pointed to inside the project), or an object outside the project that
> is pointed to from inside the project.  The objects that are
> completely owned by the project are compressed into pure binary form
> in an ImageSegment.  The outside objects are put in the 'outPointers'
> array.  The entire ImageSegment (binary part plus outPointers) is
> encoded in a SmartRefStream, and saved on the disk.  (aProject
> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
> writeForExportWithSources:inDirectory:changeSet:).
>
>         Note that every object inside the project is put into the
> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
> scan the project, in order to make intelligent decisions about what
> belongs in the project.
>         See Project's class comment for what messages are sent to
> objects as they are unpacked in a new image.
>
> ---- Older Details ------
>
>         The primary kind of image segment is an Export Segment.  It
> can be saved on a server and read into a completely different Squeak
> image.
> Old way to create one:
> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
> class))
>                 writeForExport: 'myFile.extSeg'.
> Old way to create one for a project:
>         (Project named: 'Play With Me - 3') exportSegment.
> To read it into another image:  Select 'myFile.extSeg' in a FileList,
> Menu 'load as project'.  It will install its classes automatically.
> If you need to see the roots array, it is temporarily stored in
> (SmartRefStream scannedObject).
>
> Most of 'states' of an ImageSegment are not used to export a project,
> and have been abandoned.
>
>         When a segment is written out onto a file, it goes in a
> folder called <image name>_segs.  If your image is called
> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
> image whenever your move, copy, or rename it.
>         Whenever a Class is in arrayOfRoots, its class (aClass class)
> must also be in the arrayOfRoots.
>         There are two kinds of image segments.  Normal image segments
> are a piece of a specific Squeak image, and can only be read back
> into that image.  The image holds the array of outPointers that are
> necessary to turn the bits in the file into objects.
>         To put out a normal segment that holds a Project (not the
> current project), execute (Project named: 'xxx') storeSegment.
>
>
> arrayOfRoots    The objects that head the tree we will trace.
> segment                 The WordArray of raw bits of all objects in the
> tree.
> outPointers             Oops of all objects outside the segment
> pointed to from inside.
> state                   (see below)
> segmentName     Its basic name.  Often the name of a Project.
> fileName                The local name of the file.  'Foo-23.seg'
> userRootCnt             number of roots submitted by caller.  Extras
> are added in preparation for saving.
>
> state that an ImageSegment may exist in...
>
> #activeCopy                     (has been copied, with the intent to
> become active)
> arrayOfRoots, segment, and outPointers have been created by
> copyFromRoots:.  The tree of objects has been encoded in the segment,
> but those objects are still present in the Squeak system.
>
> #active                         (segment is actively holding objects)
> The segment is now the only holder of tree of objects.  Each of the
> original roots has been transmuted into an ImageSegmentRootStub that
> refers back to this image segment.  The original objects in the
> segment will all be garbageCollected.
>
> #onFile
> The segment has been written out to a file and replaced by a file
> pointer.  Only ImageSegmentRootStubs and the array of outPointers
> remains in the image.  To get this far:
> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>                 writeToFile: 'myFile.seg'.
>
> #inactive
> The segment has been brought back into memory and turned back into
> objects.  rootsArray is set, but the segment is invalid.
>
> #onFileWithSymbols
> The segment has been written out to a file, along with the text of
> all the symbols in the outPointers array, and replaced by a file
> pointer.  This reduces the size of the outPointers array, and also
> allows the system to reclaim any symbols that are not referred to
> from elsewhere in the image.  The specific format used is that of a
> literal array as follows:
>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' # symbol5).
> In this case, the original outPointers array was 8 long, but the
> compacted table of outPointers retains only two entries.  These get
> inserted in place of the #'s in the array of symbols after it is read
> back in.  Symbols with embedded spaces or other strange characters
> are written as strings, and converted back to symbols when read back
> in.  The symbol # is never written out.
>         NOTE: All IdentitySets or dictionaries must be rehashed when
> being read back from this format.  The symbols are effectively
> internal.  (No, not if read back into same image.  If a different
> image, then use #imported.  -tk)
>
> #imported
> The segment is on an external file or just read in from one.  The
> segment and outPointers are meant to be read into a foreign image.
> In this form, the image segment can be read from a URL, and
> installed.  A copy of the original array of root objects is
> constructed, with former outPointers bound to existing objects in the
> host system.
>         (Any Class inside the segment MUST be in the arrayOfRoots.
> This is so its association can be inserted into Smalltalk.  The
> class's metaclass must be in roots also.  Methods that are in
> outPointers because blocks point at them, were found and added to the
> roots.
>         All IdentitySets and dictionaries are rehashed when being
> read back from exported segments.)
>
>
> To discover why only some of the objects in a project are being
> written out, try this (***Destructive Test***).  This breaks lots of
> backpointers in the target project, and puts up an array of
> suspicious objects, a list of the classes of the outPointers, and a
> debugger.
> "Close any transcripts in the target project"
> World currentHand objectToPaste ifNotNil: [
>         self inform: 'Hand is holding a Morph in its paste buffer:\'
> withCRs,
>                 World currentHand objectToPaste printString].
> PV := Project named: 'xxxx'.
> (IS := ImageSegment new) findRogueRootsImSeg:
>         (Array with: PV world presenter with: PV world).
> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
> "Quit and DO NOT save"
>
> When an export image segment is brought into an image, it is like an
> image starting up.  Certain startUp messages need to be run.  These
> are byte and word reversals for nonPointer data that comes from a
> machine of the opposite endianness.  #startUpProc passes over all
> objects in the segment, and:
>         The first time an instance of class X is encountered, (msg _
> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
> case, it means that instances of X do not need special work.  X is
> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
> store it in the dictionary, startUps (aClass -> aMessage).
>         When a later instance of X is encountered, if X is in
> noStartUpNeeded, do nothing.  If X is in startUps, send the message
> to the instance.  Typically this is a message like #swapShortObjects.
>         Every class that implements #startUp, should see if it needs
> a parallel implementation of #startUpFrom:.
>
> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> > I don't see image segments in Cuis... I don't even know if they still
> exist
> > in Squeak... Anyone is still using it?
> >
> > It would be cool to have it at least as a package. If I remember
> correctly
> > it was very simple, like two primitives to load and save, but I think it
> > depended on something like mark and sweep or some particular kind of
> > garbage collector and it might not work in new VMs.
> >
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151126/f896ab80/attachment-0002.html>

From hannes.hirzel at gmail.com  Thu Nov 26 09:16:29 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 16:16:29 +0100
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
Message-ID: <CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>

That's interesting,

see also http://wiki.squeak.org/squeak/2316 with a reference to an
article evaluation ImageSegments at the end.



On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> Cool, maybe it's possible to make it into a package, I'll take a look.
>
> I've never used it to store Projects, tho..  I used before to store things
> that must be loaded very fast on demand and can be forgotten once there are
> no more references to them.. like image fragments that compose a map of the
> world, and small sound fragments that are used to synthesize speech
> (diphones). Yesterday I just wanted to know how big are my objects, and I
> wanted to make some experiments to see how the bit-size of my objects grow
> as the problems I'm modeling grow by some other measure (degree of
> polynomials, size of matrices are the most basic) and to know how much
> memory are my algorithms actually using at every step... image segments are
> ideal for this, you can use them to know exactly how much memory would be
> freed if a reference to a given object were forgotten.
>
>
> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>
>> Squeak 5.0 still has ImageSegments (class comment below). Saving and
>> loading of  projects currently is blocked in Squeak because of an
>> unfinished name space (environments implementation).
>>
>> http://wiki.squeak.org/squeak/6218
>>
>> And there is Fuel
>> http://rmod.inria.fr/web/software/Fuel
>>
>> ----------
>>
>> ImageSegment
>>
>> I represent a segment of Squeak address space.  I am created from an
>> array of root objects.  After storing, my segment contains a binary
>> encoding of every object accessible from my roots but not otherwise
>> accessible from anywhere else in the system.  My segment contains
>> outward pointers that are indices into my table of outPointers.
>> On load my segment is converted back into objects and becommed
>> into an Array of the loaded objects, so they can be enumerated.
>>
>>         The main use of ImageSegments is to store Projects.  A dummy
>> version of SmartRefStream traverses the Project.  Everything it finds
>> is classified as either an object that is owned by the project (only
>> pointed to inside the project), or an object outside the project that
>> is pointed to from inside the project.  The objects that are
>> completely owned by the project are compressed into pure binary form
>> in an ImageSegment.  The outside objects are put in the 'outPointers'
>> array.  The entire ImageSegment (binary part plus outPointers) is
>> encoded in a SmartRefStream, and saved on the disk.  (aProject
>> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
>> writeForExportWithSources:inDirectory:changeSet:).
>>
>>         Note that every object inside the project is put into the
>> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
>> scan the project, in order to make intelligent decisions about what
>> belongs in the project.
>>         See Project's class comment for what messages are sent to
>> objects as they are unpacked in a new image.
>>
>> ---- Older Details ------
>>
>>         The primary kind of image segment is an Export Segment.  It
>> can be saved on a server and read into a completely different Squeak
>> image.
>> Old way to create one:
>> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
>> class))
>>                 writeForExport: 'myFile.extSeg'.
>> Old way to create one for a project:
>>         (Project named: 'Play With Me - 3') exportSegment.
>> To read it into another image:  Select 'myFile.extSeg' in a FileList,
>> Menu 'load as project'.  It will install its classes automatically.
>> If you need to see the roots array, it is temporarily stored in
>> (SmartRefStream scannedObject).
>>
>> Most of 'states' of an ImageSegment are not used to export a project,
>> and have been abandoned.
>>
>>         When a segment is written out onto a file, it goes in a
>> folder called <image name>_segs.  If your image is called
>> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
>> image whenever your move, copy, or rename it.
>>         Whenever a Class is in arrayOfRoots, its class (aClass class)
>> must also be in the arrayOfRoots.
>>         There are two kinds of image segments.  Normal image segments
>> are a piece of a specific Squeak image, and can only be read back
>> into that image.  The image holds the array of outPointers that are
>> necessary to turn the bits in the file into objects.
>>         To put out a normal segment that holds a Project (not the
>> current project), execute (Project named: 'xxx') storeSegment.
>>
>>
>> arrayOfRoots    The objects that head the tree we will trace.
>> segment                 The WordArray of raw bits of all objects in the
>> tree.
>> outPointers             Oops of all objects outside the segment
>> pointed to from inside.
>> state                   (see below)
>> segmentName     Its basic name.  Often the name of a Project.
>> fileName                The local name of the file.  'Foo-23.seg'
>> userRootCnt             number of roots submitted by caller.  Extras
>> are added in preparation for saving.
>>
>> state that an ImageSegment may exist in...
>>
>> #activeCopy                     (has been copied, with the intent to
>> become active)
>> arrayOfRoots, segment, and outPointers have been created by
>> copyFromRoots:.  The tree of objects has been encoded in the segment,
>> but those objects are still present in the Squeak system.
>>
>> #active                         (segment is actively holding objects)
>> The segment is now the only holder of tree of objects.  Each of the
>> original roots has been transmuted into an ImageSegmentRootStub that
>> refers back to this image segment.  The original objects in the
>> segment will all be garbageCollected.
>>
>> #onFile
>> The segment has been written out to a file and replaced by a file
>> pointer.  Only ImageSegmentRootStubs and the array of outPointers
>> remains in the image.  To get this far:
>> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>>                 writeToFile: 'myFile.seg'.
>>
>> #inactive
>> The segment has been brought back into memory and turned back into
>> objects.  rootsArray is set, but the segment is invalid.
>>
>> #onFileWithSymbols
>> The segment has been written out to a file, along with the text of
>> all the symbols in the outPointers array, and replaced by a file
>> pointer.  This reduces the size of the outPointers array, and also
>> allows the system to reclaim any symbols that are not referred to
>> from elsewhere in the image.  The specific format used is that of a
>> literal array as follows:
>>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
>> symbol5).
>> In this case, the original outPointers array was 8 long, but the
>> compacted table of outPointers retains only two entries.  These get
>> inserted in place of the #'s in the array of symbols after it is read
>> back in.  Symbols with embedded spaces or other strange characters
>> are written as strings, and converted back to symbols when read back
>> in.  The symbol # is never written out.
>>         NOTE: All IdentitySets or dictionaries must be rehashed when
>> being read back from this format.  The symbols are effectively
>> internal.  (No, not if read back into same image.  If a different
>> image, then use #imported.  -tk)
>>
>> #imported
>> The segment is on an external file or just read in from one.  The
>> segment and outPointers are meant to be read into a foreign image.
>> In this form, the image segment can be read from a URL, and
>> installed.  A copy of the original array of root objects is
>> constructed, with former outPointers bound to existing objects in the
>> host system.
>>         (Any Class inside the segment MUST be in the arrayOfRoots.
>> This is so its association can be inserted into Smalltalk.  The
>> class's metaclass must be in roots also.  Methods that are in
>> outPointers because blocks point at them, were found and added to the
>> roots.
>>         All IdentitySets and dictionaries are rehashed when being
>> read back from exported segments.)
>>
>>
>> To discover why only some of the objects in a project are being
>> written out, try this (***Destructive Test***).  This breaks lots of
>> backpointers in the target project, and puts up an array of
>> suspicious objects, a list of the classes of the outPointers, and a
>> debugger.
>> "Close any transcripts in the target project"
>> World currentHand objectToPaste ifNotNil: [
>>         self inform: 'Hand is holding a Morph in its paste buffer:\'
>> withCRs,
>>                 World currentHand objectToPaste printString].
>> PV := Project named: 'xxxx'.
>> (IS := ImageSegment new) findRogueRootsImSeg:
>>         (Array with: PV world presenter with: PV world).
>> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
>> "Quit and DO NOT save"
>>
>> When an export image segment is brought into an image, it is like an
>> image starting up.  Certain startUp messages need to be run.  These
>> are byte and word reversals for nonPointer data that comes from a
>> machine of the opposite endianness.  #startUpProc passes over all
>> objects in the segment, and:
>>         The first time an instance of class X is encountered, (msg _
>> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
>> case, it means that instances of X do not need special work.  X is
>> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
>> store it in the dictionary, startUps (aClass -> aMessage).
>>         When a later instance of X is encountered, if X is in
>> noStartUpNeeded, do nothing.  If X is in startUps, send the message
>> to the instance.  Typically this is a message like #swapShortObjects.
>>         Every class that implements #startUp, should see if it needs
>> a parallel implementation of #startUpFrom:.
>>
>> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>> > I don't see image segments in Cuis... I don't even know if they still
>> exist
>> > in Squeak... Anyone is still using it?
>> >
>> > It would be cool to have it at least as a package. If I remember
>> correctly
>> > it was very simple, like two primitives to load and save, but I think
>> > it
>> > depended on something like mark and sweep or some particular kind of
>> > garbage collector and it might not work in new VMs.
>> >
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>



From hannes.hirzel at gmail.com  Thu Nov 26 09:23:30 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 16:23:30 +0100
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
	<CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>
Message-ID: <CAGQxfVh3QvPc1=uzOTGQA3GYX5gca2gpJJMezf_NZqbFf1mOnw@mail.gmail.com>

And this seems to cover what you want to do

How to use an ImageSegment to determine memory usage
http://wiki.squeak.org/squeak/1260



On 11/26/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> That's interesting,
>
> see also http://wiki.squeak.org/squeak/2316 with a reference to an
> article evaluation ImageSegments at the end.
>
>
>
> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>> Cool, maybe it's possible to make it into a package, I'll take a look.
>>
>> I've never used it to store Projects, tho..  I used before to store
>> things
>> that must be loaded very fast on demand and can be forgotten once there
>> are
>> no more references to them.. like image fragments that compose a map of
>> the
>> world, and small sound fragments that are used to synthesize speech
>> (diphones). Yesterday I just wanted to know how big are my objects, and I
>> wanted to make some experiments to see how the bit-size of my objects
>> grow
>> as the problems I'm modeling grow by some other measure (degree of
>> polynomials, size of matrices are the most basic) and to know how much
>> memory are my algorithms actually using at every step... image segments
>> are
>> ideal for this, you can use them to know exactly how much memory would be
>> freed if a reference to a given object were forgotten.
>>
>>
>> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com>
>> wrote:
>>
>>> Squeak 5.0 still has ImageSegments (class comment below). Saving and
>>> loading of  projects currently is blocked in Squeak because of an
>>> unfinished name space (environments implementation).
>>>
>>> http://wiki.squeak.org/squeak/6218
>>>
>>> And there is Fuel
>>> http://rmod.inria.fr/web/software/Fuel
>>>
>>> ----------
>>>
>>> ImageSegment
>>>
>>> I represent a segment of Squeak address space.  I am created from an
>>> array of root objects.  After storing, my segment contains a binary
>>> encoding of every object accessible from my roots but not otherwise
>>> accessible from anywhere else in the system.  My segment contains
>>> outward pointers that are indices into my table of outPointers.
>>> On load my segment is converted back into objects and becommed
>>> into an Array of the loaded objects, so they can be enumerated.
>>>
>>>         The main use of ImageSegments is to store Projects.  A dummy
>>> version of SmartRefStream traverses the Project.  Everything it finds
>>> is classified as either an object that is owned by the project (only
>>> pointed to inside the project), or an object outside the project that
>>> is pointed to from inside the project.  The objects that are
>>> completely owned by the project are compressed into pure binary form
>>> in an ImageSegment.  The outside objects are put in the 'outPointers'
>>> array.  The entire ImageSegment (binary part plus outPointers) is
>>> encoded in a SmartRefStream, and saved on the disk.  (aProject
>>> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
>>> writeForExportWithSources:inDirectory:changeSet:).
>>>
>>>         Note that every object inside the project is put into the
>>> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
>>> scan the project, in order to make intelligent decisions about what
>>> belongs in the project.
>>>         See Project's class comment for what messages are sent to
>>> objects as they are unpacked in a new image.
>>>
>>> ---- Older Details ------
>>>
>>>         The primary kind of image segment is an Export Segment.  It
>>> can be saved on a server and read into a completely different Squeak
>>> image.
>>> Old way to create one:
>>> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
>>> class))
>>>                 writeForExport: 'myFile.extSeg'.
>>> Old way to create one for a project:
>>>         (Project named: 'Play With Me - 3') exportSegment.
>>> To read it into another image:  Select 'myFile.extSeg' in a FileList,
>>> Menu 'load as project'.  It will install its classes automatically.
>>> If you need to see the roots array, it is temporarily stored in
>>> (SmartRefStream scannedObject).
>>>
>>> Most of 'states' of an ImageSegment are not used to export a project,
>>> and have been abandoned.
>>>
>>>         When a segment is written out onto a file, it goes in a
>>> folder called <image name>_segs.  If your image is called
>>> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
>>> image whenever your move, copy, or rename it.
>>>         Whenever a Class is in arrayOfRoots, its class (aClass class)
>>> must also be in the arrayOfRoots.
>>>         There are two kinds of image segments.  Normal image segments
>>> are a piece of a specific Squeak image, and can only be read back
>>> into that image.  The image holds the array of outPointers that are
>>> necessary to turn the bits in the file into objects.
>>>         To put out a normal segment that holds a Project (not the
>>> current project), execute (Project named: 'xxx') storeSegment.
>>>
>>>
>>> arrayOfRoots    The objects that head the tree we will trace.
>>> segment                 The WordArray of raw bits of all objects in the
>>> tree.
>>> outPointers             Oops of all objects outside the segment
>>> pointed to from inside.
>>> state                   (see below)
>>> segmentName     Its basic name.  Often the name of a Project.
>>> fileName                The local name of the file.  'Foo-23.seg'
>>> userRootCnt             number of roots submitted by caller.  Extras
>>> are added in preparation for saving.
>>>
>>> state that an ImageSegment may exist in...
>>>
>>> #activeCopy                     (has been copied, with the intent to
>>> become active)
>>> arrayOfRoots, segment, and outPointers have been created by
>>> copyFromRoots:.  The tree of objects has been encoded in the segment,
>>> but those objects are still present in the Squeak system.
>>>
>>> #active                         (segment is actively holding objects)
>>> The segment is now the only holder of tree of objects.  Each of the
>>> original roots has been transmuted into an ImageSegmentRootStub that
>>> refers back to this image segment.  The original objects in the
>>> segment will all be garbageCollected.
>>>
>>> #onFile
>>> The segment has been written out to a file and replaced by a file
>>> pointer.  Only ImageSegmentRootStubs and the array of outPointers
>>> remains in the image.  To get this far:
>>> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>>>                 writeToFile: 'myFile.seg'.
>>>
>>> #inactive
>>> The segment has been brought back into memory and turned back into
>>> objects.  rootsArray is set, but the segment is invalid.
>>>
>>> #onFileWithSymbols
>>> The segment has been written out to a file, along with the text of
>>> all the symbols in the outPointers array, and replaced by a file
>>> pointer.  This reduces the size of the outPointers array, and also
>>> allows the system to reclaim any symbols that are not referred to
>>> from elsewhere in the image.  The specific format used is that of a
>>> literal array as follows:
>>>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
>>> symbol5).
>>> In this case, the original outPointers array was 8 long, but the
>>> compacted table of outPointers retains only two entries.  These get
>>> inserted in place of the #'s in the array of symbols after it is read
>>> back in.  Symbols with embedded spaces or other strange characters
>>> are written as strings, and converted back to symbols when read back
>>> in.  The symbol # is never written out.
>>>         NOTE: All IdentitySets or dictionaries must be rehashed when
>>> being read back from this format.  The symbols are effectively
>>> internal.  (No, not if read back into same image.  If a different
>>> image, then use #imported.  -tk)
>>>
>>> #imported
>>> The segment is on an external file or just read in from one.  The
>>> segment and outPointers are meant to be read into a foreign image.
>>> In this form, the image segment can be read from a URL, and
>>> installed.  A copy of the original array of root objects is
>>> constructed, with former outPointers bound to existing objects in the
>>> host system.
>>>         (Any Class inside the segment MUST be in the arrayOfRoots.
>>> This is so its association can be inserted into Smalltalk.  The
>>> class's metaclass must be in roots also.  Methods that are in
>>> outPointers because blocks point at them, were found and added to the
>>> roots.
>>>         All IdentitySets and dictionaries are rehashed when being
>>> read back from exported segments.)
>>>
>>>
>>> To discover why only some of the objects in a project are being
>>> written out, try this (***Destructive Test***).  This breaks lots of
>>> backpointers in the target project, and puts up an array of
>>> suspicious objects, a list of the classes of the outPointers, and a
>>> debugger.
>>> "Close any transcripts in the target project"
>>> World currentHand objectToPaste ifNotNil: [
>>>         self inform: 'Hand is holding a Morph in its paste buffer:\'
>>> withCRs,
>>>                 World currentHand objectToPaste printString].
>>> PV := Project named: 'xxxx'.
>>> (IS := ImageSegment new) findRogueRootsImSeg:
>>>         (Array with: PV world presenter with: PV world).
>>> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
>>> "Quit and DO NOT save"
>>>
>>> When an export image segment is brought into an image, it is like an
>>> image starting up.  Certain startUp messages need to be run.  These
>>> are byte and word reversals for nonPointer data that comes from a
>>> machine of the opposite endianness.  #startUpProc passes over all
>>> objects in the segment, and:
>>>         The first time an instance of class X is encountered, (msg _
>>> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
>>> case, it means that instances of X do not need special work.  X is
>>> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
>>> store it in the dictionary, startUps (aClass -> aMessage).
>>>         When a later instance of X is encountered, if X is in
>>> noStartUpNeeded, do nothing.  If X is in startUps, send the message
>>> to the instance.  Typically this is a message like #swapShortObjects.
>>>         Every class that implements #startUp, should see if it needs
>>> a parallel implementation of #startUpFrom:.
>>>
>>> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>>> > I don't see image segments in Cuis... I don't even know if they still
>>> exist
>>> > in Squeak... Anyone is still using it?
>>> >
>>> > It would be cool to have it at least as a package. If I remember
>>> correctly
>>> > it was very simple, like two primitives to load and save, but I think
>>> > it
>>> > depended on something like mark and sweep or some particular kind of
>>> > garbage collector and it might not work in new VMs.
>>> >
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>
>



From luchiano at gmail.com  Thu Nov 26 09:31:24 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Thu, 26 Nov 2015 15:31:24 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVh3QvPc1=uzOTGQA3GYX5gca2gpJJMezf_NZqbFf1mOnw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
	<CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>
	<CAGQxfVh3QvPc1=uzOTGQA3GYX5gca2gpJJMezf_NZqbFf1mOnw@mail.gmail.com>
Message-ID: <CAL5GDyrDJy377VS=eFRfAUkvLzVaUex9na_6HJMWM17EgxP2mQ@mail.gmail.com>

Oh, yes, that's exactly what I wanted, awesome! Thanks!

On Thu, Nov 26, 2015 at 3:23 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> And this seems to cover what you want to do
>
> How to use an ImageSegment to determine memory usage
> http://wiki.squeak.org/squeak/1260
>
>
>
> On 11/26/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > That's interesting,
> >
> > see also http://wiki.squeak.org/squeak/2316 with a reference to an
> > article evaluation ImageSegments at the end.
> >
> >
> >
> > On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> >> Cool, maybe it's possible to make it into a package, I'll take a look.
> >>
> >> I've never used it to store Projects, tho..  I used before to store
> >> things
> >> that must be loaded very fast on demand and can be forgotten once there
> >> are
> >> no more references to them.. like image fragments that compose a map of
> >> the
> >> world, and small sound fragments that are used to synthesize speech
> >> (diphones). Yesterday I just wanted to know how big are my objects, and
> I
> >> wanted to make some experiments to see how the bit-size of my objects
> >> grow
> >> as the problems I'm modeling grow by some other measure (degree of
> >> polynomials, size of matrices are the most basic) and to know how much
> >> memory are my algorithms actually using at every step... image segments
> >> are
> >> ideal for this, you can use them to know exactly how much memory would
> be
> >> freed if a reference to a given object were forgotten.
> >>
> >>
> >> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com>
> >> wrote:
> >>
> >>> Squeak 5.0 still has ImageSegments (class comment below). Saving and
> >>> loading of  projects currently is blocked in Squeak because of an
> >>> unfinished name space (environments implementation).
> >>>
> >>> http://wiki.squeak.org/squeak/6218
> >>>
> >>> And there is Fuel
> >>> http://rmod.inria.fr/web/software/Fuel
> >>>
> >>> ----------
> >>>
> >>> ImageSegment
> >>>
> >>> I represent a segment of Squeak address space.  I am created from an
> >>> array of root objects.  After storing, my segment contains a binary
> >>> encoding of every object accessible from my roots but not otherwise
> >>> accessible from anywhere else in the system.  My segment contains
> >>> outward pointers that are indices into my table of outPointers.
> >>> On load my segment is converted back into objects and becommed
> >>> into an Array of the loaded objects, so they can be enumerated.
> >>>
> >>>         The main use of ImageSegments is to store Projects.  A dummy
> >>> version of SmartRefStream traverses the Project.  Everything it finds
> >>> is classified as either an object that is owned by the project (only
> >>> pointed to inside the project), or an object outside the project that
> >>> is pointed to from inside the project.  The objects that are
> >>> completely owned by the project are compressed into pure binary form
> >>> in an ImageSegment.  The outside objects are put in the 'outPointers'
> >>> array.  The entire ImageSegment (binary part plus outPointers) is
> >>> encoded in a SmartRefStream, and saved on the disk.  (aProject
> >>> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
> >>> writeForExportWithSources:inDirectory:changeSet:).
> >>>
> >>>         Note that every object inside the project is put into the
> >>> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
> >>> scan the project, in order to make intelligent decisions about what
> >>> belongs in the project.
> >>>         See Project's class comment for what messages are sent to
> >>> objects as they are unpacked in a new image.
> >>>
> >>> ---- Older Details ------
> >>>
> >>>         The primary kind of image segment is an Export Segment.  It
> >>> can be saved on a server and read into a completely different Squeak
> >>> image.
> >>> Old way to create one:
> >>> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
> >>> class))
> >>>                 writeForExport: 'myFile.extSeg'.
> >>> Old way to create one for a project:
> >>>         (Project named: 'Play With Me - 3') exportSegment.
> >>> To read it into another image:  Select 'myFile.extSeg' in a FileList,
> >>> Menu 'load as project'.  It will install its classes automatically.
> >>> If you need to see the roots array, it is temporarily stored in
> >>> (SmartRefStream scannedObject).
> >>>
> >>> Most of 'states' of an ImageSegment are not used to export a project,
> >>> and have been abandoned.
> >>>
> >>>         When a segment is written out onto a file, it goes in a
> >>> folder called <image name>_segs.  If your image is called
> >>> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
> >>> image whenever your move, copy, or rename it.
> >>>         Whenever a Class is in arrayOfRoots, its class (aClass class)
> >>> must also be in the arrayOfRoots.
> >>>         There are two kinds of image segments.  Normal image segments
> >>> are a piece of a specific Squeak image, and can only be read back
> >>> into that image.  The image holds the array of outPointers that are
> >>> necessary to turn the bits in the file into objects.
> >>>         To put out a normal segment that holds a Project (not the
> >>> current project), execute (Project named: 'xxx') storeSegment.
> >>>
> >>>
> >>> arrayOfRoots    The objects that head the tree we will trace.
> >>> segment                 The WordArray of raw bits of all objects in the
> >>> tree.
> >>> outPointers             Oops of all objects outside the segment
> >>> pointed to from inside.
> >>> state                   (see below)
> >>> segmentName     Its basic name.  Often the name of a Project.
> >>> fileName                The local name of the file.  'Foo-23.seg'
> >>> userRootCnt             number of roots submitted by caller.  Extras
> >>> are added in preparation for saving.
> >>>
> >>> state that an ImageSegment may exist in...
> >>>
> >>> #activeCopy                     (has been copied, with the intent to
> >>> become active)
> >>> arrayOfRoots, segment, and outPointers have been created by
> >>> copyFromRoots:.  The tree of objects has been encoded in the segment,
> >>> but those objects are still present in the Squeak system.
> >>>
> >>> #active                         (segment is actively holding objects)
> >>> The segment is now the only holder of tree of objects.  Each of the
> >>> original roots has been transmuted into an ImageSegmentRootStub that
> >>> refers back to this image segment.  The original objects in the
> >>> segment will all be garbageCollected.
> >>>
> >>> #onFile
> >>> The segment has been written out to a file and replaced by a file
> >>> pointer.  Only ImageSegmentRootStubs and the array of outPointers
> >>> remains in the image.  To get this far:
> >>> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
> >>>                 writeToFile: 'myFile.seg'.
> >>>
> >>> #inactive
> >>> The segment has been brought back into memory and turned back into
> >>> objects.  rootsArray is set, but the segment is invalid.
> >>>
> >>> #onFileWithSymbols
> >>> The segment has been written out to a file, along with the text of
> >>> all the symbols in the outPointers array, and replaced by a file
> >>> pointer.  This reduces the size of the outPointers array, and also
> >>> allows the system to reclaim any symbols that are not referred to
> >>> from elsewhere in the image.  The specific format used is that of a
> >>> literal array as follows:
> >>>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
> >>> symbol5).
> >>> In this case, the original outPointers array was 8 long, but the
> >>> compacted table of outPointers retains only two entries.  These get
> >>> inserted in place of the #'s in the array of symbols after it is read
> >>> back in.  Symbols with embedded spaces or other strange characters
> >>> are written as strings, and converted back to symbols when read back
> >>> in.  The symbol # is never written out.
> >>>         NOTE: All IdentitySets or dictionaries must be rehashed when
> >>> being read back from this format.  The symbols are effectively
> >>> internal.  (No, not if read back into same image.  If a different
> >>> image, then use #imported.  -tk)
> >>>
> >>> #imported
> >>> The segment is on an external file or just read in from one.  The
> >>> segment and outPointers are meant to be read into a foreign image.
> >>> In this form, the image segment can be read from a URL, and
> >>> installed.  A copy of the original array of root objects is
> >>> constructed, with former outPointers bound to existing objects in the
> >>> host system.
> >>>         (Any Class inside the segment MUST be in the arrayOfRoots.
> >>> This is so its association can be inserted into Smalltalk.  The
> >>> class's metaclass must be in roots also.  Methods that are in
> >>> outPointers because blocks point at them, were found and added to the
> >>> roots.
> >>>         All IdentitySets and dictionaries are rehashed when being
> >>> read back from exported segments.)
> >>>
> >>>
> >>> To discover why only some of the objects in a project are being
> >>> written out, try this (***Destructive Test***).  This breaks lots of
> >>> backpointers in the target project, and puts up an array of
> >>> suspicious objects, a list of the classes of the outPointers, and a
> >>> debugger.
> >>> "Close any transcripts in the target project"
> >>> World currentHand objectToPaste ifNotNil: [
> >>>         self inform: 'Hand is holding a Morph in its paste buffer:\'
> >>> withCRs,
> >>>                 World currentHand objectToPaste printString].
> >>> PV := Project named: 'xxxx'.
> >>> (IS := ImageSegment new) findRogueRootsImSeg:
> >>>         (Array with: PV world presenter with: PV world).
> >>> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
> >>> "Quit and DO NOT save"
> >>>
> >>> When an export image segment is brought into an image, it is like an
> >>> image starting up.  Certain startUp messages need to be run.  These
> >>> are byte and word reversals for nonPointer data that comes from a
> >>> machine of the opposite endianness.  #startUpProc passes over all
> >>> objects in the segment, and:
> >>>         The first time an instance of class X is encountered, (msg _
> >>> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
> >>> case, it means that instances of X do not need special work.  X is
> >>> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
> >>> store it in the dictionary, startUps (aClass -> aMessage).
> >>>         When a later instance of X is encountered, if X is in
> >>> noStartUpNeeded, do nothing.  If X is in startUps, send the message
> >>> to the instance.  Typically this is a message like #swapShortObjects.
> >>>         Every class that implements #startUp, should see if it needs
> >>> a parallel implementation of #startUpFrom:.
> >>>
> >>> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> >>> > I don't see image segments in Cuis... I don't even know if they still
> >>> exist
> >>> > in Squeak... Anyone is still using it?
> >>> >
> >>> > It would be cool to have it at least as a package. If I remember
> >>> correctly
> >>> > it was very simple, like two primitives to load and save, but I think
> >>> > it
> >>> > depended on something like mark and sweep or some particular kind of
> >>> > garbage collector and it might not work in new VMs.
> >>> >
> >>>
> >>> _______________________________________________
> >>> Cuis mailing list
> >>> Cuis at jvuletich.org
> >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>>
> >>
> >
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151126/36cbae51/attachment-0002.html>

From Ken.Dickey at Whidbey.com  Thu Nov 26 10:43:56 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 26 Nov 2015 08:43:56 -0800
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
Message-ID: <20151126084356.9c4d2d0cd3817291d42a099e@Whidbey.com>

On Thu, 26 Nov 2015 14:10:21 +0000
Luciano Notarfrancesco <luchiano at gmail.com> wrote:

> Cool, maybe it's possible to make it into a package, I'll take a look.

Note that image segments are stored in a binary format that is dependent on the VM.

In other words an image segment saved in 4.x (pre-Spur) will not be loadable in 5.x (Spur).

I have not looked, but one might do better to port Fuel.

$0.02,
-KenD



From edgardec2005 at gmail.com  Thu Nov 26 11:27:58 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Thu, 26 Nov 2015 14:27:58 -0300
Subject: [Cuis] image segments
In-Reply-To: <20151126084356.9c4d2d0cd3817291d42a099e@Whidbey.com>
Message-ID: <D27CC76E.172AA%edgardec2005@gmail.com>




On 11/26/15, 1:43 PM, "KenD" <Ken.Dickey at Whidbey.com> wrote:

> I have not looked, but one might do better to port Fuel.

+1 A good look of Fuel 





From euanmee at gmail.com  Thu Nov 26 19:46:59 2015
From: euanmee at gmail.com (EuanM)
Date: Fri, 27 Nov 2015 01:46:59 +0000
Subject: [Cuis] Cuis Logo
Message-ID: <CALsRT0neHMUA5WagyEDVuatfCm6=7Ky0KnMKTSxd7_CTHDqGXg@mail.gmail.com>

I'm preparing a slideshow on what's good and cool in the Smalltalk world(s) atm.

I want to include Cuis.

I'm not aware of any official or semi-official logo.

I'm not even sure of the derivation or meaning of "Cuis".

Could someone point me to a logo, if there is one?

Could someone tell me more about why the project is called "Cuis"?
(And if there is nothing atm, I'll produce a logo that ties in to
that)

Cheers,
    Euan



From edgardec2005 at gmail.com  Fri Nov 27 04:26:15 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Fri, 27 Nov 2015 07:26:15 -0300
Subject: [Cuis] Cuis Logo
In-Reply-To: <CALsRT0neHMUA5WagyEDVuatfCm6=7Ky0KnMKTSxd7_CTHDqGXg@mail.gmail.com>
Message-ID: <D27DB617.172C3%edgardec2005@gmail.com>




On 11/26/15, 10:46 PM, "EuanM" <euanmee at gmail.com> wrote:

> I'm preparing a slideshow on what's good and cool in the Smalltalk world(s)
> atm.
> 
> I want to include Cuis.
> 
> I'm not aware of any official or semi-official logo.
> 
> I'm not even sure of the derivation or meaning of "Cuis".
> 
> Could someone point me to a logo, if there is one?
> 
> Could someone tell me more about why the project is called "Cuis"?
> (And if there is nothing atm, I'll produce a logo that ties in to
> that)
> 
> Cheers,
>     Euan
https://en.wikipedia.org/wiki/Southern_mountain_cavy (Microcavia australis)
Cuis

So is a rodent living in Argentina.
Very common, you do not need to far of mayor cities to found it to side of
roads 

Maybe a styli shed photo ?

Edgar





From avalloud at smalltalk.comcastbiz.net  Fri Nov 27 09:21:45 2015
From: avalloud at smalltalk.comcastbiz.net (Andres Valloud)
Date: Fri, 27 Nov 2015 07:21:45 -0800
Subject: [Cuis] New updates
In-Reply-To: <CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>
References: <56530DC3.3040609@jvuletich.org>
	<CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>
Message-ID: <56587509.2020202@smalltalk.comcastbiz.net>

Hello,

The fixes to exceptions are about solving subtle misbehaviors with the 
messages #pass, #outer, and #resignalAs:.  Generally speaking, the main 
issue was that the correct handler block wouldn't be found.  Thus, for 
example, sending the message #pass would fail to find a default handler. 
  I found these types of issues while porting Assessments (more on 
Assessments below), because it uses #pass to track exceptions, and 
#resignalAs: to remap other exceptions into exceptions Assessments 
understands.  Correct nested execution of #pass required a stack of 
handler contexts, thus now exceptions keep an ordered collection of 
handler contexts rather than just the topmost handler.  Surely this is 
not the only way this can be done.

Assessments is a testing framework specifically designed with 
collaboration in mind.  I had been making SUnit extensions since 2001, 
and eventually I realized sharing such extensions and improvements with 
other SUnit users would be fundamentally obstructed.  SUnit's design is 
such that one has to change the framework itself in order to extend its 
behavior.  Thus, what I change in my image does not necessarily have to 
work in someone else's image, and vice versa.  As a result, most SUnit 
users end up implementing extensions such as file logging or more 
extensive result reporting, and those extensions are incompatible with 
each other.

Instead, Assessments is built around the principle that the testing 
framework's behavior and extensibility should rely on object composition 
rather than subclassing.  In addition, a few critical objects are now 
reified explicitly.  Chief among them is the Assessment (the "test 
suite"), with its evaluation context (no parallel).  The key is that the 
evaluation context of an assessment can change how tests are executed, 
how results are collected, and so on.  Since this is done by object 
composition, it's trivial to e.g. set up an assessment to report results 
to multiple files and to the GUI without changing Assessments itself. 
As a result, extensions can be shared without the threat of immediate 
incompatibility.

But what about pre-existing SUnit tests?  Well surely a new testing 
framework built around collaboration wouldn't immediately obsolete the 
enormous body of SUnit tests out there, or force a migration because NIH 
or something like that.  And that's exactly what Assessments 
accomplishes.  Since there is an evaluation context object, an 
assessment ("test suite") can specify which execution policy goes for 
which check ("test").  Assessments uses this flexibility to execute 
SUnit tests in situ, as if SUnit itself was running them.  Unlike other 
solutions deployed to solve this problem, Assessments does not require 
modifications to existing code.  Loading Assessments is effectively 
invisible to existing SUnit code.

The end result is that the Assessments checklist evaluator (the "test 
runner") displays both SUnit tests and native Assessments tests, and one 
assessment object can execute both types together.

In addiiton, Assessments provides a clean, native implementation of 
SUnit Validation (also known as "Extreme Validation"), as well as SUnit 
Benchmarks.  Both of these are implemented in terms of Assessments 
checklists.  Briefly, validation involves using tests to verify e.g. 
business objects at run time.  A typical application of validation would 
be data entry verification.  The Benchmarks is another application of 
tests, where each test measures the time needed to execute some code. 
In addition, Benchmarks can enforce that some code runs within a certain 
amount of time.  An interesting detail is that the required time is 
specified in "message send" units, rather than time.  Thus, the 
benchmarks do not become obsolete or inappropriate depending on the 
speed of the machine where the measurements are taken.

For more information, the Assessments package contains more detailed 
comments as well as links to additional detail.  I originally presented 
Assessments at ESUG 2008, the video of the talk is online here (and 
other places):

https://vimeo.com/1945494

There are also some notes on validation here:

http://csl.ensm-douai.fr/Esug2007Media/uploads/1/Extreme.pdf

There is also a paper by Leandro Caniglia titled "Extreme Validation", 
which unfortunately I couldn't immediately find in Google.  But I image 
I can get a copy and put it online somewhere.

Andres.

On 11/23/15 7:35 , Luciano Notarfrancesco wrote:
> Hi all,
> About my recent changes, some of them are 1) extensions to Theme to be
> able to customize some more aspects of how the windows and widgets look,
> or 2) fixes for small bugs that I found on the way, like misalignments
> of a few pixels between parts of a widget or a window. The motivation
> behind this was just to be able to implement a very minimalist look
> (borders of just 1 pixel, no decorations, no icons, no anything that I
> dont need and takes up screen real estate), and a sort of tiling dynamic
> window manager very much like http://dwm.suckless.org
> (https://github.com/len/Cuis-Smalltalk-DWM).
>
> In order to implement this "window manager" as an external package with
> minimal changes to the core system, I decided to: 1) make the current
> Theme receive messages #windowOpen: #windowClosed: every time
> SystemWindows are open or closed, in order to give it a chance to
> implement window-management behaviour or delegate it to a proper window
> manager; 2) move the window-management keyboard shortcuts (like alt-w to
> close) to Theme, so it is all in one place, easy to change, and easy to
> make a Theme that delegates keyboard events to a proper window manager.
>
> Again I did it like this in order to minimize changes to the core
> system. At the moment window management is in part implemented in
> SystemWindow, and also in HandMorph and Morph. I had to make some small
> modifications in order to get the desired behavior when using DWM, and
> keep the original behavior in the base system. Maybe in the long run we
> would want to have a WindowManager class that do this, handle keyboard
> events for the window-management shortcuts and receives #windowOpen: and
> #windowClosed:, etc. But I would like to think better about this before
> adding new concepts and complexity to the core.
>
> Cheers,
> Luciano
>
>
> On Mon, Nov 23, 2015 at 12:59 PM, Juan Vuletich <juan at jvuletich.org
> <mailto:juan at jvuletich.org>> wrote:
>
>     Hi all,
>
>     I recently included some new updates:
>
>     - Fixes to Exceptions by Andr?s Valloud and Martin McClure.
>     - Assessments framework for testing and validation by Andr?s Valloud.
>     - Many fixes and enhancements to Layouts, Window drawing, keyboard
>     shortcuts, etc. by Luciano Notarfrancesco
>
>     Thank you very much Folks! Andr?s, Luciano, please comment a bit on
>     what you did, especially subtle but important behavior such as
>     Exceptions and new stuff like Assessments, and the new Theme and
>     Window Manager.
>
>     Cheers,
>     Juan Vuletich
>
>     _______________________________________________
>     Cuis mailing list
>     Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Fri Nov 27 13:50:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 27 Nov 2015 14:50:07 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <5658B3EF.24941.1584D0D@dnorton.mindspring.com>

Hi Juan,

Please include the latest when you build next time:

	https://github.com/dhnorton/Cuis-Smalltalk-comments

Changes:
	less redundancy in the list
	pick up trailing acronyms
	revised class comments

Thanks,
 - Dan



From euanmee at gmail.com  Fri Nov 27 14:19:05 2015
From: euanmee at gmail.com (EuanM)
Date: Fri, 27 Nov 2015 20:19:05 +0000
Subject: [Cuis] Cuis Logo
Message-ID: <CALsRT0k8oL4K0mqWuBTKi0+3cBqZ=cJZcQFZm4d1KSYkDhxj_A@mail.gmail.com>

My 0.0.3 release of a proposed interim Cuis logo is now online, on the
home page at:
http://smalltalk.uk.to/

My plan is to add it to the constellation of Smalltalk logos on the
slideshow I'm writing, until Juan and the community have a better
option.

Cheers,
    Euan


> On Fri, 27 Nov 2015 07:26:15 -0300, "Edgar J. De Cleene" wrote:

> On 11/26/15, 10:46 PM, "EuanM" <euanmee at gmail.com> wrote:
>
>> I'm preparing a slideshow on what's good and cool in the Smalltalk world(s)
>> atm.
>>
>> I want to include Cuis.
>>
>> I'm not aware of any official or semi-official logo.
>>
>> I'm not even sure of the derivation or meaning of "Cuis".
>>
>> Could someone point me to a logo, if there is one?
>>
>> Could someone tell me more about why the project is called "Cuis"?
>> (And if there is nothing atm, I'll produce a logo that ties in to
>> that)
>>
>> Cheers,
>>     Euan
> https://en.wikipedia.org/wiki/Southern_mountain_cavy (Microcavia australis)
> Cuis
>
> So is a rodent living in Argentina.
> Very common, you do not need to far of mayor cities to found it to side of
> roads
>
> Maybe a styli shed photo ?
>
> Edgar



From juan at jvuletich.org  Sat Nov 28 14:20:17 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:20:17 -0300
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
Message-ID: <565A0C81.9080702@jvuletich.org>

At some point in the development of Cuis I removed both Projects and 
ImageSegments. It shouldn't be hard to add them back, as an optional 
package.

WRT Fuel, it would be a great addition. If (as I believe) it already 
works on Squeak, besides Pharo, then it shouldn't be too hard to port to 
Cuis.

Cheers,
Juan Vuletich

On 26/11/2015 11:10 a.m., Luciano Notarfrancesco wrote:
> Cool, maybe it's possible to make it into a package, I'll take a look.
>
> I've never used it to store Projects, tho..  I used before to store 
> things that must be loaded very fast on demand and can be forgotten 
> once there are no more references to them.. like image fragments that 
> compose a map of the world, and small sound fragments that are used to 
> synthesize speech (diphones). Yesterday I just wanted to know how big 
> are my objects, and I wanted to make some experiments to see how the 
> bit-size of my objects grow as the problems I'm modeling grow by some 
> other measure (degree of polynomials, size of matrices are the most 
> basic) and to know how much memory are my algorithms actually using at 
> every step... image segments are ideal for this, you can use them to 
> know exactly how much memory would be freed if a reference to a given 
> object were forgotten.
>
>
> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com 
> <mailto:hannes.hirzel at gmail.com>> wrote:
>
>     Squeak 5.0 still has ImageSegments (class comment below). Saving and
>     loading of  projects currently is blocked in Squeak because of an
>     unfinished name space (environments implementation).
>
>     http://wiki.squeak.org/squeak/6218
>
>     And there is Fuel
>     http://rmod.inria.fr/web/software/Fuel
>
>     ----------
>
>     ImageSegment
>
>     I represent a segment of Squeak address space.  I am created from an
>     array of root objects.  After storing, my segment contains a binary
>     encoding of every object accessible from my roots but not otherwise
>     accessible from anywhere else in the system.  My segment contains
>     outward pointers that are indices into my table of outPointers.
>     On load my segment is converted back into objects and becommed
>     into an Array of the loaded objects, so they can be enumerated.
>
>             The main use of ImageSegments is to store Projects.  A dummy
>     version of SmartRefStream traverses the Project.  Everything it finds
>     is classified as either an object that is owned by the project (only
>     pointed to inside the project), or an object outside the project that
>     is pointed to from inside the project.  The objects that are
>     completely owned by the project are compressed into pure binary form
>     in an ImageSegment.  The outside objects are put in the 'outPointers'
>     array.  The entire ImageSegment (binary part plus outPointers) is
>     encoded in a SmartRefStream, and saved on the disk.  (aProject
>     exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
>     writeForExportWithSources:inDirectory:changeSet:).
>
>             Note that every object inside the project is put into the
>     segment's arrayOfRoots.  This is because a dummy SmartRefStream to
>     scan the project, in order to make intelligent decisions about what
>     belongs in the project.
>             See Project's class comment for what messages are sent to
>     objects as they are unpacked in a new image.
>
>     ---- Older Details ------
>
>             The primary kind of image segment is an Export Segment.  It
>     can be saved on a server and read into a completely different Squeak
>     image.
>     Old way to create one:
>     (ImageSegment new copyFromRootsForExport: (Array with: Baz with:
>     Baz class))
>                     writeForExport: 'myFile.extSeg'.
>     Old way to create one for a project:
>             (Project named: 'Play With Me - 3') exportSegment.
>     To read it into another image:  Select 'myFile.extSeg' in a FileList,
>     Menu 'load as project'.  It will install its classes automatically.
>     If you need to see the roots array, it is temporarily stored in
>     (SmartRefStream scannedObject).
>
>     Most of 'states' of an ImageSegment are not used to export a project,
>     and have been abandoned.
>
>             When a segment is written out onto a file, it goes in a
>     folder called <image name>_segs.  If your image is called
>     "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
>     image whenever your move, copy, or rename it.
>             Whenever a Class is in arrayOfRoots, its class (aClass class)
>     must also be in the arrayOfRoots.
>             There are two kinds of image segments.  Normal image segments
>     are a piece of a specific Squeak image, and can only be read back
>     into that image.  The image holds the array of outPointers that are
>     necessary to turn the bits in the file into objects.
>             To put out a normal segment that holds a Project (not the
>     current project), execute (Project named: 'xxx') storeSegment.
>
>
>     arrayOfRoots    The objects that head the tree we will trace.
>     segment                 The WordArray of raw bits of all objects
>     in the tree.
>     outPointers             Oops of all objects outside the segment
>     pointed to from inside.
>     state                   (see below)
>     segmentName     Its basic name.  Often the name of a Project.
>     fileName                The local name of the file.  'Foo-23.seg'
>     userRootCnt             number of roots submitted by caller.  Extras
>     are added in preparation for saving.
>
>     state that an ImageSegment may exist in...
>
>     #activeCopy                     (has been copied, with the intent to
>     become active)
>     arrayOfRoots, segment, and outPointers have been created by
>     copyFromRoots:.  The tree of objects has been encoded in the segment,
>     but those objects are still present in the Squeak system.
>
>     #active                         (segment is actively holding objects)
>     The segment is now the only holder of tree of objects.  Each of the
>     original roots has been transmuted into an ImageSegmentRootStub that
>     refers back to this image segment.  The original objects in the
>     segment will all be garbageCollected.
>
>     #onFile
>     The segment has been written out to a file and replaced by a file
>     pointer.  Only ImageSegmentRootStubs and the array of outPointers
>     remains in the image.  To get this far:
>     (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>                     writeToFile: 'myFile.seg'.
>
>     #inactive
>     The segment has been brought back into memory and turned back into
>     objects.  rootsArray is set, but the segment is invalid.
>
>     #onFileWithSymbols
>     The segment has been written out to a file, along with the text of
>     all the symbols in the outPointers array, and replaced by a file
>     pointer.  This reduces the size of the outPointers array, and also
>     allows the system to reclaim any symbols that are not referred to
>     from elsewhere in the image.  The specific format used is that of a
>     literal array as follows:
>             #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
>     symbol5).
>     In this case, the original outPointers array was 8 long, but the
>     compacted table of outPointers retains only two entries.  These get
>     inserted in place of the #'s in the array of symbols after it is read
>     back in.  Symbols with embedded spaces or other strange characters
>     are written as strings, and converted back to symbols when read back
>     in.  The symbol # is never written out.
>             NOTE: All IdentitySets or dictionaries must be rehashed when
>     being read back from this format.  The symbols are effectively
>     internal.  (No, not if read back into same image.  If a different
>     image, then use #imported.  -tk)
>
>     #imported
>     The segment is on an external file or just read in from one.  The
>     segment and outPointers are meant to be read into a foreign image.
>     In this form, the image segment can be read from a URL, and
>     installed.  A copy of the original array of root objects is
>     constructed, with former outPointers bound to existing objects in the
>     host system.
>             (Any Class inside the segment MUST be in the arrayOfRoots.
>     This is so its association can be inserted into Smalltalk.  The
>     class's metaclass must be in roots also.  Methods that are in
>     outPointers because blocks point at them, were found and added to the
>     roots.
>             All IdentitySets and dictionaries are rehashed when being
>     read back from exported segments.)
>
>
>     To discover why only some of the objects in a project are being
>     written out, try this (***Destructive Test***).  This breaks lots of
>     backpointers in the target project, and puts up an array of
>     suspicious objects, a list of the classes of the outPointers, and a
>     debugger.
>     "Close any transcripts in the target project"
>     World currentHand objectToPaste ifNotNil: [
>             self inform: 'Hand is holding a Morph in its paste
>     buffer:\' withCRs,
>                     World currentHand objectToPaste printString].
>     PV := Project named: 'xxxx'.
>     (IS := ImageSegment new) findRogueRootsImSeg:
>             (Array with: PV world presenter with: PV world).
>     IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
>     "Quit and DO NOT save"
>
>     When an export image segment is brought into an image, it is like an
>     image starting up.  Certain startUp messages need to be run.  These
>     are byte and word reversals for nonPointer data that comes from a
>     machine of the opposite endianness.  #startUpProc passes over all
>     objects in the segment, and:
>             The first time an instance of class X is encountered, (msg _
>     X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
>     case, it means that instances of X do not need special work.  X is
>     included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
>     store it in the dictionary, startUps (aClass -> aMessage).
>             When a later instance of X is encountered, if X is in
>     noStartUpNeeded, do nothing.  If X is in startUps, send the message
>     to the instance.  Typically this is a message like #swapShortObjects.
>             Every class that implements #startUp, should see if it needs
>     a parallel implementation of #startUpFrom:.
>
>     On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com
>     <mailto:luchiano at gmail.com>> wrote:
>     > I don't see image segments in Cuis... I don't even know if they
>     still exist
>     > in Squeak... Anyone is still using it?
>     >
>     > It would be cool to have it at least as a package. If I remember
>     correctly
>     > it was very simple, like two primitives to load and save, but I
>     think it
>     > depended on something like mark and sweep or some particular kind of
>     > garbage collector and it might not work in new VMs.
>     >
>
>     _______________________________________________
>     Cuis mailing list
>     Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151128/5e6e6890/attachment-0002.html>

From juan at jvuletich.org  Sat Nov 28 14:25:56 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:25:56 -0300
Subject: [Cuis] Cuis Logo
In-Reply-To: <CALsRT0k8oL4K0mqWuBTKi0+3cBqZ=cJZcQFZm4d1KSYkDhxj_A@mail.gmail.com>
References: <CALsRT0k8oL4K0mqWuBTKi0+3cBqZ=cJZcQFZm4d1KSYkDhxj_A@mail.gmail.com>
Message-ID: <565A0DD4.4000006@jvuletich.org>

Hi EuanM,

On 27/11/2015 05:19 p.m., EuanM wrote:
> My 0.0.3 release of a proposed interim Cuis logo is now online, on the
> home page at:
> http://smalltalk.uk.to/

When I first looked at it, I thought "what's this bear like face looking 
to the upper right? I'll need to find a polite way to say 'no'!".
Two seconds later mi brain did the click and saw the little mouse 
looking towards the left.
The same happened to my 12 y.o and my wife (without me saying a word).

I love it!

Thanks,
Juan Vuletich

> My plan is to add it to the constellation of Smalltalk logos on the
> slideshow I'm writing, until Juan and the community have a better
> option.
>
> Cheers,
>      Euan
>
>
>> On Fri, 27 Nov 2015 07:26:15 -0300, "Edgar J. De Cleene" wrote:
>> On 11/26/15, 10:46 PM, "EuanM"<euanmee at gmail.com>  wrote:
>>
>>> I'm preparing a slideshow on what's good and cool in the Smalltalk world(s)
>>> atm.
>>>
>>> I want to include Cuis.
>>>
>>> I'm not aware of any official or semi-official logo.
>>>
>>> I'm not even sure of the derivation or meaning of "Cuis".
>>>
>>> Could someone point me to a logo, if there is one?
>>>
>>> Could someone tell me more about why the project is called "Cuis"?
>>> (And if there is nothing atm, I'll produce a logo that ties in to
>>> that)
>>>
>>> Cheers,
>>>      Euan
>> https://en.wikipedia.org/wiki/Southern_mountain_cavy (Microcavia australis)
>> Cuis
>>
>> So is a rodent living in Argentina.
>> Very common, you do not need to far of mayor cities to found it to side of
>> roads
>>
>> Maybe a styli shed photo ?
>>
>> Edgar
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Sat Nov 28 14:26:54 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:26:54 -0300
Subject: [Cuis] Class Comment Browser
In-Reply-To: <5658B3EF.24941.1584D0D@dnorton.mindspring.com>
References: <5658B3EF.24941.1584D0D@dnorton.mindspring.com>
Message-ID: <565A0E0E.7070405@jvuletich.org>

Will do.

Thanks,
Juan Vuletich

On 27/11/2015 04:50 p.m., Dan Norton wrote:
> Hi Juan,
>
> Please include the latest when you build next time:
>
> 	https://github.com/dhnorton/Cuis-Smalltalk-comments
>
> Changes:
> 	less redundancy in the list
> 	pick up trailing acronyms
> 	revised class comments
>
> Thanks,
>   - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Sat Nov 28 14:28:18 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:28:18 -0300
Subject: [Cuis] New updates
In-Reply-To: <56587509.2020202@smalltalk.comcastbiz.net>
References: <56530DC3.3040609@jvuletich.org>	<CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>
	<56587509.2020202@smalltalk.comcastbiz.net>
Message-ID: <565A0E62.8080707@jvuletich.org>

Thanks, Folks!!!

Cheers,
Juan Vuletich

On 27/11/2015 12:21 p.m., Andres Valloud wrote:
> Hello,
>
> The fixes to exceptions are about solving subtle misbehaviors with the 
> messages #pass, #outer, and #resignalAs:.  Generally speaking, the 
> main issue was that the correct handler block wouldn't be found.  
> Thus, for example, sending the message #pass would fail to find a 
> default handler.  I found these types of issues while porting 
> Assessments (more on Assessments below), because it uses #pass to 
> track exceptions, and #resignalAs: to remap other exceptions into 
> exceptions Assessments understands.  Correct nested execution of #pass 
> required a stack of handler contexts, thus now exceptions keep an 
> ordered collection of handler contexts rather than just the topmost 
> handler.  Surely this is not the only way this can be done.
>
> Assessments is a testing framework specifically designed with 
> collaboration in mind.  I had been making SUnit extensions since 2001, 
> and eventually I realized sharing such extensions and improvements 
> with other SUnit users would be fundamentally obstructed.  SUnit's 
> design is such that one has to change the framework itself in order to 
> extend its behavior.  Thus, what I change in my image does not 
> necessarily have to work in someone else's image, and vice versa.  As 
> a result, most SUnit users end up implementing extensions such as file 
> logging or more extensive result reporting, and those extensions are 
> incompatible with each other.
>
> Instead, Assessments is built around the principle that the testing 
> framework's behavior and extensibility should rely on object 
> composition rather than subclassing.  In addition, a few critical 
> objects are now reified explicitly.  Chief among them is the 
> Assessment (the "test suite"), with its evaluation context (no 
> parallel).  The key is that the evaluation context of an assessment 
> can change how tests are executed, how results are collected, and so 
> on.  Since this is done by object composition, it's trivial to e.g. 
> set up an assessment to report results to multiple files and to the 
> GUI without changing Assessments itself. As a result, extensions can 
> be shared without the threat of immediate incompatibility.
>
> But what about pre-existing SUnit tests?  Well surely a new testing 
> framework built around collaboration wouldn't immediately obsolete the 
> enormous body of SUnit tests out there, or force a migration because 
> NIH or something like that.  And that's exactly what Assessments 
> accomplishes.  Since there is an evaluation context object, an 
> assessment ("test suite") can specify which execution policy goes for 
> which check ("test").  Assessments uses this flexibility to execute 
> SUnit tests in situ, as if SUnit itself was running them.  Unlike 
> other solutions deployed to solve this problem, Assessments does not 
> require modifications to existing code.  Loading Assessments is 
> effectively invisible to existing SUnit code.
>
> The end result is that the Assessments checklist evaluator (the "test 
> runner") displays both SUnit tests and native Assessments tests, and 
> one assessment object can execute both types together.
>
> In addiiton, Assessments provides a clean, native implementation of 
> SUnit Validation (also known as "Extreme Validation"), as well as 
> SUnit Benchmarks.  Both of these are implemented in terms of 
> Assessments checklists.  Briefly, validation involves using tests to 
> verify e.g. business objects at run time.  A typical application of 
> validation would be data entry verification.  The Benchmarks is 
> another application of tests, where each test measures the time needed 
> to execute some code. In addition, Benchmarks can enforce that some 
> code runs within a certain amount of time.  An interesting detail is 
> that the required time is specified in "message send" units, rather 
> than time.  Thus, the benchmarks do not become obsolete or 
> inappropriate depending on the speed of the machine where the 
> measurements are taken.
>
> For more information, the Assessments package contains more detailed 
> comments as well as links to additional detail.  I originally 
> presented Assessments at ESUG 2008, the video of the talk is online 
> here (and other places):
>
> https://vimeo.com/1945494
>
> There are also some notes on validation here:
>
> http://csl.ensm-douai.fr/Esug2007Media/uploads/1/Extreme.pdf
>
> There is also a paper by Leandro Caniglia titled "Extreme Validation", 
> which unfortunately I couldn't immediately find in Google.  But I 
> image I can get a copy and put it online somewhere.
>
> Andres.
>
> On 11/23/15 7:35 , Luciano Notarfrancesco wrote:
>> Hi all,
>> About my recent changes, some of them are 1) extensions to Theme to be
>> able to customize some more aspects of how the windows and widgets look,
>> or 2) fixes for small bugs that I found on the way, like misalignments
>> of a few pixels between parts of a widget or a window. The motivation
>> behind this was just to be able to implement a very minimalist look
>> (borders of just 1 pixel, no decorations, no icons, no anything that I
>> dont need and takes up screen real estate), and a sort of tiling dynamic
>> window manager very much like http://dwm.suckless.org
>> (https://github.com/len/Cuis-Smalltalk-DWM).
>>
>> In order to implement this "window manager" as an external package with
>> minimal changes to the core system, I decided to: 1) make the current
>> Theme receive messages #windowOpen: #windowClosed: every time
>> SystemWindows are open or closed, in order to give it a chance to
>> implement window-management behaviour or delegate it to a proper window
>> manager; 2) move the window-management keyboard shortcuts (like alt-w to
>> close) to Theme, so it is all in one place, easy to change, and easy to
>> make a Theme that delegates keyboard events to a proper window manager.
>>
>> Again I did it like this in order to minimize changes to the core
>> system. At the moment window management is in part implemented in
>> SystemWindow, and also in HandMorph and Morph. I had to make some small
>> modifications in order to get the desired behavior when using DWM, and
>> keep the original behavior in the base system. Maybe in the long run we
>> would want to have a WindowManager class that do this, handle keyboard
>> events for the window-management shortcuts and receives #windowOpen: and
>> #windowClosed:, etc. But I would like to think better about this before
>> adding new concepts and complexity to the core.
>>
>> Cheers,
>> Luciano
>>
>>
>> On Mon, Nov 23, 2015 at 12:59 PM, Juan Vuletich <juan at jvuletich.org
>> <mailto:juan at jvuletich.org>> wrote:
>>
>>     Hi all,
>>
>>     I recently included some new updates:
>>
>>     - Fixes to Exceptions by Andr?s Valloud and Martin McClure.
>>     - Assessments framework for testing and validation by Andr?s 
>> Valloud.
>>     - Many fixes and enhancements to Layouts, Window drawing, keyboard
>>     shortcuts, etc. by Luciano Notarfrancesco
>>
>>     Thank you very much Folks! Andr?s, Luciano, please comment a bit on
>>     what you did, especially subtle but important behavior such as
>>     Exceptions and new stuff like Assessments, and the new Theme and
>>     Window Manager.
>>
>>     Cheers,
>>     Juan Vuletich
>>
>>     _______________________________________________
>>     Cuis mailing list
>>     Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From 0800nacho at gmail.com  Sun Nov  1 20:45:06 2015
From: 0800nacho at gmail.com (nacho)
Date: Sun, 1 Nov 2015 18:45:06 -0800 (PST)
Subject: [Cuis] serialization in Cuis
Message-ID: <1446432306774-4858922.post@n4.nabble.com>

Hi Folks,
I'm trying to add support for serializing instances of a class. 
I'm looking at System-Object Storage
And in particular to the class SmartRefStream which seems to add that
functionality. However, the class has no comments and no examples.
Is there some example which uses this class? a short demo? an example?
Thanks in advance!!
best
Nacho





-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/serialization-in-Cuis-tp4858922.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Sun Nov  1 22:52:24 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sun, 1 Nov 2015 20:52:24 -0800
Subject: [Cuis] ColorEditor updated
In-Reply-To: <56357262.9599.2DA3199@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<56357262.9599.2DA3199@dnorton.mindspring.com>
Message-ID: <20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>

On Sat, 31 Oct 2015 22:01:06 -0400
"Dan Norton" <dnorton at mindspring.com> wrote:

> On 29 Oct 2015 at 16:56, KenD wrote:
..
> > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > updates.  You can file it in and check senders.
..
> I've done that and I see that messages to SystemChangeNotifier are not required in order to  use the method.
> 
> Also, the dependency mechanism itself uses #when:send:to:.
> 
> Any object can use  #when:send:to: because it is an Object instance method. 
> 
> So, should this be named a different mechanism or is it just a different use of the 
> dependency mechanism?
> 
> If it's a different mechanism, is "Signals" the right name? This by Marcel Taeumel:
> 	
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#Featu
> reComparison

Hi Dan.

I took a look at the Signals implementation some time ago and my recollection is that I found the implementation to be complex and less useful than I had hoped.

For my limited uses, I prefer #when:send:to:

Simplicity wins.  In the longer term I hope somebody gets a chance to rewrite the older #changed: code to use the #when:send:to: mechanism so that we can remove #changed: .

I agree that having two update mechanisms is one too many.  Adding a third dependency update, Signals, would be going in the wrong direction IMHO.

$0.02
-KenD



From dnorton at mindspring.com  Mon Nov  2 14:58:26 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 02 Nov 2015 15:58:26 -0500
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<56357262.9599.2DA3199@dnorton.mindspring.com>,
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
Message-ID: <5637CE72.9136.1176A2C@dnorton.mindspring.com>

Hi Ken,

Comments in line.

On 1 Nov 2015 at 20:52, KenD wrote:

> On Sat, 31 Oct 2015 22:01:06 -0400
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> > On 29 Oct 2015 at 16:56, KenD wrote:
> ..
> > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > > updates.  You can file it in and check senders.
> ..
> > I've done that and I see that messages to SystemChangeNotifier are
> not required in order to  use the method.
> > 
> > Also, the dependency mechanism itself uses #when:send:to:.
> > 
> > Any object can use  #when:send:to: because it is an Object
> instance method. 
> > 
> > So, should this be named a different mechanism or is it just a
> different use of the 
> > dependency mechanism?
> > 
> > If it's a different mechanism, is "Signals" the right name? This
> by Marcel Taeumel:
> > 	
> >
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjec
> ts/wiki/signals#Featu
> > reComparison
> 
> Hi Dan.
> 
> I took a look at the Signals implementation some time ago and my
> recollection is that I found the implementation to be complex and
> less useful than I had hoped.
> 
> For my limited uses, I prefer #when:send:to:
> 
> Simplicity wins.

+1

  In the longer term I hope somebody gets a chance
> to rewrite the older #changed: code to use the #when:send:to:
> mechanism so that we can remove #changed: .
> 
> I agree that having two update mechanisms is one too many.  Adding a
> third dependency update, Signals, would be going in the wrong
> direction IMHO.
>

That's fine. I was casting about for some name besides " #when:send:to: mechanism" for 
use in a brief essay on PluggableListMorph Principles of Operation when I came across 
Signals. I already wrote a paragraph on Dependency Mechanism.

So, the simple principle here is to just use #when:send:to: and forget about or maybe 
deprecate #changed: and #update:? The advantage IIUC is #when:send:to:
	can be sent by any object, 
	the receiver can be any object, 
	the to: parameter can be any object, and 
	the send: parameter doesn't necessarily have to exist because WeakMessageSend 
is used! 

What a deal :).

However, I see a problem common to dependency and #when:send:to: which is the 
identification and explanation of the various symbols which are communicated as the 
parameters for send: or changed: . When you're trying to design a model or view similar to 
something already in existence, the tools are not much help with that.

I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>

Would appreciate any thoughts.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151102/3d081884/attachment-0003.html>

From Ken.Dickey at Whidbey.com  Mon Nov  2 17:27:16 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Mon, 2 Nov 2015 15:27:16 -0800
Subject: [Cuis] ColorEditor updated
In-Reply-To: <5637CE72.9136.1176A2C@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<56357262.9599.2DA3199@dnorton.mindspring.com>
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
Message-ID: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>

On Mon, 02 Nov 2015 15:58:26 -0500
"Dan Norton" <dnorton at mindspring.com> wrote:

>.. I was casting about for some name besides " #when:send:to: mechanism" for 
> use in a brief essay on PluggableListMorph Principles of Operation when I came across 
> Signals. I already wrote a paragraph on Dependency Mechanism.

I would talk about #when:send:to: as implementing the Observer Pattern.

> So, the simple principle here is to just use #when:send:to: and forget about or maybe 
> deprecate #changed: and #update:? 

Yes.  Let us work to eliminate #changed: !

> However, I see a problem common to dependency and #when:send:to: which is the 
> identification and explanation of the various symbols which are communicated as the 
> parameters for send: or changed: . When you're trying to design a model or view similar to 
> something already in existence, the tools are not much help with that.
> 
> I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>

We should certainly add clarifying comments!

Your Comment Browser is a big help here.  Once people start using it more, comments will appear.

I suggest sending Juan a code update with an added "Open Comment Browser" Help menu item which autoloads the same way as TerseGuide.


However, class comments are not usually where design patterns show up.  8^|

In the case of #when:send:to: I suggest a slightly larger discussion around building paned windows which update dependent panes.

What constitutes good style?  What code patterns help?

Think "Useful Code Patterns" to augment "Useful Expressions".

You can do your own example, but looking at the ColorEditor:

ColorEditor>>buildMorphicWindow
	"Create a useful ColorEditor window"
	
	self layoutMorph beRow; " A row of columns"
		 separation: 6;
		 addMorph: self buildColorPaneColumn;
		 addMorph: self buildSliderColumn;
		 addMorph: self buildRadioButtonColumn;
		 color: self backgroundColor.
		
	self model when: #colorChanged send: #refreshColor to: self.
	
	^ self

So trying for good style (hey, I need to improve here too!) one uses: 

[Class]>buildMorphicWindow
    [Add (construct each pane).. to layout]
    [Add self or panes as observers]
  ^ self

Suggest
  Smalltalk browseAllImplementorsOf: #buildMorphicWindow
to see specific usage examples.

Of course, we will suffer some embarrassment as our real code is less than ideal. 8^(

But this is a great motivator to making our code better!  ;^)


$0.02
-KenD



From hannes.hirzel at gmail.com  Mon Nov  2 19:39:44 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 3 Nov 2015 02:39:44 +0100
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<56357262.9599.2DA3199@dnorton.mindspring.com>
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
Message-ID: <CAGQxfVjUVgu4_JDOEYJR1Kf4Kv+YADxMDb9bPd7=-rO8U_dZxg@mail.gmail.com>

On 11/3/15, KenD <Ken.Dickey at whidbey.com> wrote:
> On Mon, 02 Nov 2015 15:58:26 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
>
>>.. I was casting about for some name besides " #when:send:to: mechanism"
>> for
>> use in a brief essay on PluggableListMorph Principles of Operation when I
>> came across
>> Signals. I already wrote a paragraph on Dependency Mechanism.
>
> I would talk about #when:send:to: as implementing the Observer Pattern.
>
>> So, the simple principle here is to just use #when:send:to: and forget
>> about or maybe
>> deprecate #changed: and #update:?
>
> Yes.  Let us work to eliminate #changed: !
>
>> However, I see a problem common to dependency and #when:send:to: which is
>> the
>> identification and explanation of the various symbols which are
>> communicated as the
>> parameters for send: or changed: . When you're trying to design a model or
>> view similar to
>> something already in existence, the tools are not much help with that.
>>
>> I'm thinking maybe: document in comments? <rant>Nah. We don't do
>> comments.</rant>
>
> We should certainly add clarifying comments!
>
> Your Comment Browser is a big help here.  Once people start using it more,
> comments will appear.
>
> I suggest sending Juan a code update with an added "Open Comment Browser"
> Help menu item which autoloads the same way as TerseGuide.
+1
>
> However, class comments are not usually where design patterns show up.  8^|
>
> In the case of #when:send:to: I suggest a slightly larger discussion around
> building paned windows which update dependent panes.
>
> What constitutes good style?  What code patterns help?
>
> Think "Useful Code Patterns" to augment "Useful Expressions".
+1
> You can do your own example, but looking at the ColorEditor:
>
> ColorEditor>>buildMorphicWindow
> 	"Create a useful ColorEditor window"
> 	
> 	self layoutMorph beRow; " A row of columns"
> 		 separation: 6;
> 		 addMorph: self buildColorPaneColumn;
> 		 addMorph: self buildSliderColumn;
> 		 addMorph: self buildRadioButtonColumn;
> 		 color: self backgroundColor.
> 		
> 	self model when: #colorChanged send: #refreshColor to: self.
> 	
> 	^ self
>
> So trying for good style (hey, I need to improve here too!) one uses:
>
> [Class]>buildMorphicWindow
>     [Add (construct each pane).. to layout]
>     [Add self or panes as observers]
>   ^ self
>
> Suggest
>   Smalltalk browseAllImplementorsOf: #buildMorphicWindow
> to see specific usage examples.
>
> Of course, we will suffer some embarrassment as our real code is less than
> ideal. 8^(
>
> But this is a great motivator to making our code better!  ;^)
>
>
> $0.02
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From brasspen at gmail.com  Tue Nov  3 07:47:59 2015
From: brasspen at gmail.com (Chris Cunnington)
Date: Tue, 3 Nov 2015 08:47:59 -0500
Subject: [Cuis] [ANN] OopluCon 2016, San Francisco, April
Message-ID: <5638BB0F.5030700@gmail.com>

OopluCon 2016
A Day for the Smalltalk Programming Language and its Friends

Sunday 10 April 2016
8am - 4pm

The Box SF
1069 Howard Street (between 6th and 7th)
three blocks from Moscone Center, SoMa
San Francisco, USA
http://www.theboxsf.com/

The event is free
A request for presentations will be announced in a future month
A presentation called An Introduction To Smalltalk will promoted to the 
Ruby, Python and Objective C communities
The latest details will be available at http://www.ooplu.com




From dnorton at mindspring.com  Tue Nov  3 12:11:50 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 03 Nov 2015 13:11:50 -0500
Subject: [Cuis] Terse Guide to Cuis
Message-ID: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>

Hi Juan,

The guide has been updated as follows:

	revised iterations topic
	revised transcript topic
	replaced file streams with file operations topic featuring FileMan

Please include this in the next build. The repo is:

	https://github.com/dhnorton/Cuis-Smalltalk-terse

 - Dan



From dnorton at mindspring.com  Tue Nov  3 13:58:46 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 03 Nov 2015 14:58:46 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <563911F6.21646.11C43C8@dnorton.mindspring.com>

Hi Juan,

As recommended by Ken and Hannes, the attached methods add the capability to bring up 
the class comment browser from the help menu.

Sorry, but I still don't know how to prepend the thumbnail to the menu item :)

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TheWorldMenu-openCommentGuide.zip
Type: application/zip
Size: 1298 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151103/b51fa789/attachment-0003.zip>

From 0800nacho at gmail.com  Tue Nov  3 17:13:35 2015
From: 0800nacho at gmail.com (nacho)
Date: Tue, 3 Nov 2015 15:13:35 -0800 (PST)
Subject: [Cuis] Terse Guide to Cuis
In-Reply-To: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
References: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
Message-ID: <1446592415409-4859122.post@n4.nabble.com>

Thanks Dan,
This guide is very helpful.
Are you planning to add some help in all the ways to manipulate colours?
Best regards
Nacho





-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Re-Terse-Guide-to-Cuis-tp4859099p4859122.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From 0800nacho at gmail.com  Wed Nov  4 05:00:53 2015
From: 0800nacho at gmail.com (nacho)
Date: Wed, 4 Nov 2015 03:00:53 -0800 (PST)
Subject: [Cuis] Terse Guide to Cuis
In-Reply-To: <1446592415409-4859122.post@n4.nabble.com>
References: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
	<1446592415409-4859122.post@n4.nabble.com>
Message-ID: <1446634853959-4859148.post@n4.nabble.com>

Dan,
Thanks for your prompt response.
I already had all of Mr. Dickey's marvellous and mysterious Cuis stuff
cloned into my computer :p
Very useful too.
Best
nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Re-Terse-Guide-to-Cuis-tp4859099p4859148.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Wed Nov  4 09:11:16 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Wed, 4 Nov 2015 07:11:16 -0800
Subject: [Cuis] Terse Guide to Cuis
In-Reply-To: <1446634853959-4859148.post@n4.nabble.com>
References: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
	<1446592415409-4859122.post@n4.nabble.com>
	<1446634853959-4859148.post@n4.nabble.com>
Message-ID: <20151104071116.8650ae2d569537a692f895ec@Whidbey.com>

On Wed, 4 Nov 2015 03:00:53 -0800 (PST)
nacho <0800nacho at gmail.com> wrote:

> I already had all of Mr. Dickey's marvellous and mysterious Cuis stuff
> cloned into my computer :p

Note that I have been working through my projects, eliminating FileDirectory in favor of FileMan.

Users should to do a "git pull" on most of these for 2568.

As usual, bugs to /dev/null, er, I mean to me  ;^)
-KenD



From dnorton at mindspring.com  Wed Nov  4 17:46:20 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 04 Nov 2015 18:46:20 -0500
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>,
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
Message-ID: <563A98CC.20508.1B798BE@dnorton.mindspring.com>

Ran across this comment for ActiveModel and thought it was interesting, historically.

Part of update 5005u16-Events.cs:

"Change Set:		Events
Date:			11 February 2002
Author:			Rob Withers et al.

Published to 3.3a as 4756Events.cs

The NuBlue events code. Finally..."

The new event model, originally from VisualSmalltalk.
This includes #when:send:to: and friends, in Object (generic implementation) and 
ActiveModel (optimized implementation).
It renders the old change/update mechanism in Object and Model as obsolete, although still 
used.

 - Dan

On 2 Nov 2015 at 15:27, KenD wrote:

> On Mon, 02 Nov 2015 15:58:26 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> >.. I was casting about for some name besides " #when:send:to:
> mechanism" for 
> > use in a brief essay on PluggableListMorph Principles of Operation
> when I came across 
> > Signals. I already wrote a paragraph on Dependency Mechanism.
> 
> I would talk about #when:send:to: as implementing the Observer
> Pattern.
> 
> > So, the simple principle here is to just use #when:send:to: and
> forget about or maybe 
> > deprecate #changed: and #update:? 
> 
> Yes.  Let us work to eliminate #changed: !
> 
> > However, I see a problem common to dependency and #when:send:to:
> which is the 
> > identification and explanation of the various symbols which are
> communicated as the 
> > parameters for send: or changed: . When you're trying to design a
> model or view similar to 
> > something already in existence, the tools are not much help with
> that.
> > 
> > I'm thinking maybe: document in comments? <rant>Nah. We don't do
> comments.</rant>
> 
> We should certainly add clarifying comments!
> 
> Your Comment Browser is a big help here.  Once people start using it
> more, comments will appear.
> 
> I suggest sending Juan a code update with an added "Open Comment
> Browser" Help menu item which autoloads the same way as
> TerseGuide.
> 
> 
> However, class comments are not usually where design patterns show
> up.  8^|
> 
> In the case of #when:send:to: I suggest a slightly larger discussion
> around building paned windows which update dependent panes.
> 
> What constitutes good style?  What code patterns help?
> 
> Think "Useful Code Patterns" to augment "Useful Expressions".
> 
> You can do your own example, but looking at the ColorEditor:
> 
> ColorEditor>>buildMorphicWindow
> 	"Create a useful ColorEditor window"
> 	
> 	self layoutMorph beRow; " A row of columns"
> 		 separation: 6;
> 		 addMorph: self buildColorPaneColumn;
> 		 addMorph: self buildSliderColumn;
> 		 addMorph: self buildRadioButtonColumn;
> 		 color: self backgroundColor.
> 		
> 	self model when: #colorChanged send: #refreshColor to: self.
> 	
> 	^ self
> 
> So trying for good style (hey, I need to improve here too!) one
> uses: 
> 
> [Class]>buildMorphicWindow
>     [Add (construct each pane).. to layout]
>     [Add self or panes as observers]
>   ^ self
> 
> Suggest
>   Smalltalk browseAllImplementorsOf: #buildMorphicWindow
> to see specific usage examples.
> 
> Of course, we will suffer some embarrassment as our real code is
> less than ideal. 8^(
> 
> But this is a great motivator to making our code better!  ;^)
> 
> 
> $0.02
> -KenD





From dnorton at mindspring.com  Thu Nov  5 12:23:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 05 Nov 2015 13:23:07 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <563B9E8B.18686.D41F27@dnorton.mindspring.com>

The latest enables list selection by key. Not fancy like PluggableListMorph, just single key 
selection.

	https://github.com/dhnorton/Cuis-Smalltalk-comments

Somehoo I have introduced a yip in the scroller but maybe it is usable for the time being.

 - Dan



From hari.balaraman at icloud.com  Thu Nov  5 13:53:44 2015
From: hari.balaraman at icloud.com (Hari Balaraman)
Date: Thu, 05 Nov 2015 14:53:44 -0500
Subject: [Cuis] FAST conference
In-Reply-To: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
Message-ID: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>

If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
Best regards,
Hari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151105/32d3218d/attachment-0003.html>

From dnorton at mindspring.com  Thu Nov  5 15:25:17 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 5 Nov 2015 13:25:17 -0800 (PST)
Subject: [Cuis] Class Comment Browser
In-Reply-To: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
References: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
Message-ID: <1446758717845-4859424.post@n4.nabble.com>

:( OK, I fixed it. :)

 - Dan



--
View this message in context: http://forum.world.st/Class-Comment-Browser-tp4859411p4859424.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From juan at jvuletich.org  Fri Nov  6 12:04:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:04:53 -0300
Subject: [Cuis] ColorEditor updated
In-Reply-To: <5637CE72.9136.1176A2C@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<56357262.9599.2DA3199@dnorton.mindspring.com>,
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
Message-ID: <563CEBC5.40409@jvuletich.org>

(inline)

On 11/2/2015 5:58 PM, Dan Norton wrote:
> Hi Ken,
>
> Comments in line.
>
> On 1 Nov 2015 at 20:52, KenD wrote:
>
> > On Sat, 31 Oct 2015 22:01:06 -0400
> > "Dan Norton" <dnorton at mindspring.com> wrote:
> >
> > > On 29 Oct 2015 at 16:56, KenD wrote:
> > ..
> > > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > > > updates.  You can file it in and check senders.
> > ..
> > > I've done that and I see that messages to SystemChangeNotifier are
> > not required in order to  use the method.
> > >
> > > Also, the dependency mechanism itself uses #when:send:to:.
> > >
> > > Any object can use  #when:send:to: because it is an Object
> > instance method.
> > >
> > > So, should this be named a different mechanism or is it just a
> > different use of the
> > > dependency mechanism?
> > >
> > > If it's a different mechanism, is "Signals" the right name? This
> > by Marcel Taeumel:
> > >
> > >
> > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjec
> > ts/wiki/signals#Featu
> > > reComparison
> >
> > Hi Dan.
> >
> > I took a look at the Signals implementation some time ago and my
> > recollection is that I found the implementation to be complex and
> > less useful than I had hoped.
> >
> > For my limited uses, I prefer #when:send:to:
> >
> > Simplicity wins.
>
> +1
>
>   In the longer term I hope somebody gets a chance
> > to rewrite the older #changed: code to use the #when:send:to:
> > mechanism so that we can remove #changed: .
> >
> > I agree that having two update mechanisms is one too many.  Adding a
> > third dependency update, Signals, would be going in the wrong
> > direction IMHO.
> >
>
> That's fine. I was casting about for some name besides " 
> #when:send:to: mechanism" for
> use in a brief essay on PluggableListMorph Principles of Operation 
> when I came across
> Signals. I already wrote a paragraph on Dependency Mechanism.
>
> So, the simple principle here is to just use #when:send:to: and forget 
> about or maybe deprecate #changed: and #update:? The advantage IIUC is 
> #when:send:to:
>            can be sent by any object,
>            the receiver can be any object,
>            the to: parameter can be any object, and
>            the send: parameter doesn't necessarily have to exist 
> because WeakMessageSend is used!
>
> What a deal :).
>
> However, I see a problem common to dependency and #when:send:to: which 
> is the identification and explanation of the various symbols which are 
> communicated as the parameters forsend: or changed: . When you're 
> trying to design a model or view similar to something already in 
> existence, the tools are not much help with that.
>

Well, doing senders on any symbol (method selectors, but also event 
names) shows all references to it. I don't think it is that bad, but, do 
you have ideas for improvements on this?

> I'm thinking maybe: document in comments? <rant>Nah. We don't do 
> comments.</rant>

Let me disagree. Cuis includes 204019 characters in class comments. That 
would be like 2000 to 4000 lines, right? For a system with less than 
100kLOC. Top 10 classes with extensive class comments are: BitBlt 
SmartRefStream Float ClosureScanner Color ContentPack Monitor 
AndreasSystemProfiler EventSensor ReferenceStream. Just check them. 
Several of these are rather recent, some were written specifically for 
Cuis.

We also have  27058 bytes of comments at the top of methods. Some 
methods with great comments are #vmParameterAt: #entriesIn: 
#eliotsClosureMeasurements2On: #getCurrentWorkingDirectory 
#whatIsAPrimitive #asUtf8: #howToModifyPrimitives #applySimpleGamma:to: 
#linearTosRGBGamma: #localMicrosecondClock #findBinaryIndex:do:ifNone: 
#findBinary:do:ifNone: #spyAllOn: , etc.

There is a lot to be learnt about the system from reading comments. And 
we want to improve.

(BTW, querying the system to find this out took me less time than 
writing this email)

> Would appreciate any thoughts.
>
>  - Dan
>

I think that both comments and tools are useful and should be enhanced.

Cheers,
Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/8f076245/attachment-0003.html>

From juan at jvuletich.org  Fri Nov  6 12:13:13 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:13:13 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <1446432306774-4858922.post@n4.nabble.com>
References: <1446432306774-4858922.post@n4.nabble.com>
Message-ID: <563CEDB9.2090200@jvuletich.org>

Hi Nacho,

On 11/1/2015 11:45 PM, nacho wrote:
> Hi Folks,
> I'm trying to add support for serializing instances of a class.
> I'm looking at System-Object Storage
> And in particular to the class SmartRefStream which seems to add that
> functionality. However, the class has no comments and no examples.
> Is there some example which uses this class? a short demo? an example?
> Thanks in advance!!
> best
> Nacho
>

Are we browsing the same system? SmartRefStream class comment is 6016 
characters here. Superclass ReferenceStream has a class comments of 2875 
characters. DataStream and ReferenceStream have class methods that start 
with 'example'. Looking for references to these classes also brings 
useful examples of usage.

In any case, the usual way to serialize classes is fileOut. Why doesn't 
this work for you? What problem are you trying to solve?

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Nov  6 12:28:23 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:28:23 -0300
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<56357262.9599.2DA3199@dnorton.mindspring.com>	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
Message-ID: <563CF147.306@jvuletich.org>

Hi Ken,

On 11/2/2015 8:27 PM, KenD wrote:
> ...
>
> However, class comments are not usually where design patterns show up.  8^|
>
> In the case of #when:send:to: I suggest a slightly larger discussion around building paned windows which update dependent panes.
>
> What constitutes good style?  What code patterns help?
>
> Think "Useful Code Patterns" to augment "Useful Expressions".

In 2009 I wrote 
http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgramming.txt 
and 
http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.txt . 
I've had the idea of making all the GUI code in Cuis follow this style. 
But time is always short...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Nov  6 12:29:02 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:29:02 -0300
Subject: [Cuis] [ANN] OopluCon 2016, San Francisco, April
In-Reply-To: <5638BB0F.5030700@gmail.com>
References: <5638BB0F.5030700@gmail.com>
Message-ID: <563CF16E.3040707@jvuletich.org>

:)

On 11/3/2015 10:47 AM, Chris Cunnington wrote:
> OopluCon 2016
> A Day for the Smalltalk Programming Language and its Friends
>
> Sunday 10 April 2016
> 8am - 4pm
>
> The Box SF
> 1069 Howard Street (between 6th and 7th)
> three blocks from Moscone Center, SoMa
> San Francisco, USA
> http://www.theboxsf.com/
>
> The event is free
> A request for presentations will be announced in a future month
> A presentation called An Introduction To Smalltalk will promoted to 
> the Ruby, Python and Objective C communities
> The latest details will be available at http://www.ooplu.com
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Fri Nov  6 12:32:14 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:32:14 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
Message-ID: <563CF22E.4080804@jvuletich.org>

Hi Hari,

I'll be there. Let's meet then.

Anybody else?

Cheers,
Juan Vuletich

On 11/5/2015 4:53 PM, Hari Balaraman wrote:
> If any of you are attending the FAST conference in Buenos Aires in a 
> week or so, I look forward to meeting you face to face.
> Best regards,
> Hari
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/3c065b90/attachment-0003.html>

From 0800nacho at gmail.com  Fri Nov  6 12:40:14 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Fri, 6 Nov 2015 15:40:14 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <563CF22E.4080804@jvuletich.org>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
Message-ID: <etPan.563cf40e.77bd141b.a58@Unix.local>

Yes I will be there too.
Juan, are you giving the talk on friday?
cheers


--?
Ignacio Sniechowski
Prosavic SRL
Sent with Airmail

On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org) wrote:

Hi Hari,

I'll be there. Let's meet then.

Anybody else?

Cheers,
Juan Vuletich

On 11/5/2015 4:53 PM, Hari Balaraman wrote:
If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
Best regards,
Hari


_______________________________________________
Cuis mailing list
Cuis at jvuletich.org
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________  
Cuis mailing list  
Cuis at jvuletich.org  
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/0cb1d1b7/attachment-0003.html>

From 0800nacho at gmail.com  Fri Nov  6 12:42:53 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Fri, 6 Nov 2015 15:42:53 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <563CEDB9.2090200@jvuletich.org>
References: <1446432306774-4858922.post@n4.nabble.com>
	<563CEDB9.2090200@jvuletich.org>
Message-ID: <etPan.563cf4ad.177918bd.a58@Unix.local>

Hi Juan,
Thanks for your response.
I?m not trying to serialize classes but instances of them.
Suppose theres a class called Memo with an ivar ?content?
Then I want to be able add to the instances the posibility of storing their data.
fileOut is great for classes I use it a lot!
But I want a way to preserve data outside the image, so it can be loaded when a new image is used.
thanks!
Nacho


--?
Ignacio Sniechowski
Prosavic SRL
Sent with Airmail

On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org) wrote:

Hi Nacho,  

On 11/1/2015 11:45 PM, nacho wrote:  
> Hi Folks,  
> I'm trying to add support for serializing instances of a class.  
> I'm looking at System-Object Storage  
> And in particular to the class SmartRefStream which seems to add that  
> functionality. However, the class has no comments and no examples.  
> Is there some example which uses this class? a short demo? an example?  
> Thanks in advance!!  
> best  
> Nacho  
>  

Are we browsing the same system? SmartRefStream class comment is 6016  
characters here. Superclass ReferenceStream has a class comments of 2875  
characters. DataStream and ReferenceStream have class methods that start  
with 'example'. Looking for references to these classes also brings  
useful examples of usage.  

In any case, the usual way to serialize classes is fileOut. Why doesn't  
this work for you? What problem are you trying to solve?  

Cheers,  
Juan Vuletich  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/d2e149d2/attachment-0003.html>

From juan at jvuletich.org  Fri Nov  6 12:43:57 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:43:57 -0300
Subject: [Cuis] Class Comment Browser
In-Reply-To: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
References: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
Message-ID: <563CF4ED.6090306@jvuletich.org>

On 11/5/2015 3:23 PM, Dan Norton wrote:
> The latest enables list selection by key. Not fancy like PluggableListMorph, just single key
> selection.
>
> 	https://github.com/dhnorton/Cuis-Smalltalk-comments
>
> Somehoo I have introduced a yip in the scroller but maybe it is usable for the time being.
>
>   - Dan

Hi Dan,

Just integrated your recent contributions. Thank you!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Nov  6 12:45:15 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:45:15 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <etPan.563cf40e.77bd141b.a58@Unix.local>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
Message-ID: <563CF53B.5000107@jvuletich.org>

Yes, on Friday. Meet you there!

Cheers,
Juan Vuletich

On 11/6/2015 3:40 PM, Ignacio Sniechowski wrote:
> Yes I will be there too.
> Juan, are you giving the talk on friday?
> cheers
>
>
> -- 
> Ignacio Sniechowski
> Prosavic SRL
> Sent with Airmail
>
> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org 
> <mailto:juan at jvuletich.org>) wrote:
>
>> Hi Hari,
>>
>> I'll be there. Let's meet then.
>>
>> Anybody else?
>>
>> Cheers,
>> Juan Vuletich
>>
>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>> If any of you are attending the FAST conference in Buenos Aires in a 
>>> week or so, I look forward to meeting you face to face.
>>> Best regards,
>>> Hari
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/36a59629/attachment-0003.html>

From juan at jvuletich.org  Fri Nov  6 12:48:20 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:48:20 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <etPan.563cf4ad.177918bd.a58@Unix.local>
References: <1446432306774-4858922.post@n4.nabble.com>
	<563CEDB9.2090200@jvuletich.org>
	<etPan.563cf4ad.177918bd.a58@Unix.local>
Message-ID: <563CF5F4.1070808@jvuletich.org>

Hi Nacho,

Oh, yes, I misread. Ok. ReferenceStream and SmartRefStream are your 
choices. Take a look at the class comments, play with the examples. Ask 
questions.

Cheers,
Juan Vuletich


On 11/6/2015 3:42 PM, Ignacio Sniechowski wrote:
> Hi Juan,
> Thanks for your response.
> I?m not trying to serialize classes but instances of them.
> Suppose theres a class called Memo with an ivar ?content?
> Then I want to be able add to the instances the posibility of storing 
> their data.
> fileOut is great for classes I use it a lot!
> But I want a way to preserve data outside the image, so it can be 
> loaded when a new image is used.
> thanks!
> Nacho
>
>
> -- 
> Ignacio Sniechowski
> Prosavic SRL
> Sent with Airmail
>
> On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org 
> <mailto:juan at jvuletich.org>) wrote:
>
>> Hi Nacho,
>>
>> On 11/1/2015 11:45 PM, nacho wrote:
>> > Hi Folks,
>> > I'm trying to add support for serializing instances of a class.
>> > I'm looking at System-Object Storage
>> > And in particular to the class SmartRefStream which seems to add that
>> > functionality. However, the class has no comments and no examples.
>> > Is there some example which uses this class? a short demo? an example?
>> > Thanks in advance!!
>> > best
>> > Nacho
>> >
>>
>> Are we browsing the same system? SmartRefStream class comment is 6016
>> characters here. Superclass ReferenceStream has a class comments of 2875
>> characters. DataStream and ReferenceStream have class methods that start
>> with 'example'. Looking for references to these classes also brings
>> useful examples of usage.
>>
>> In any case, the usual way to serialize classes is fileOut. Why doesn't
>> this work for you? What problem are you trying to solve?
>>
>> Cheers,
>> Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/cda299f0/attachment-0003.html>

From dnorton at mindspring.com  Fri Nov  6 15:21:21 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 06 Nov 2015 16:21:21 -0500
Subject: [Cuis] Unknown File Dialogue
Message-ID: <563D19D1.11201.12C21F7@dnorton.mindspring.com>

Hello,

In FmFileEntry>>fileContents, a dialogue is presented if there is an attempt to read a file 
which does not exist. This gives the opportunity to choose another name or cancel.

A "Cancel" response produces MNU: #contents

To avoid the MNU and answer nil, I suggest the attached change be made to #fileContents.

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FmFileEntry-fileContents.zip
Type: application/zip
Size: 456 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/46db3fe0/attachment-0003.zip>

From edgardec2005 at gmail.com  Sat Nov  7 05:31:06 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sat, 07 Nov 2015 08:31:06 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <563CF5F4.1070808@jvuletich.org>
Message-ID: <D263674C.16FF1%edgardec2005@gmail.com>

As Juan said, ReferenceStream is your friend
Here I attach a old cs
If you wish , Foo saveOnFileNamed: 'Foo'create a Foo.obj file in your
working directory.
Later you could use readAndInspect: 'Path to your file'
When you have DrgaAndDrop as my forked CuiSantafesino you could exchange
working objects between Squeak,Cuis and Pharo.
And if you said Pharo do not have ReferenceStream , well I made how to for
Pharo 2.0 so is possible.
With this technique I export and import objects big enough for have complete
swiki into a Squeak derivate image, about 14 mb of data
Cheers

Edgar
@morplenauta




On 11/6/15, 3:48 PM, "Juan Vuletich" <juan at jvuletich.org> wrote:

>  Hi Nacho,
>  
>  Oh, yes, I misread. Ok. ReferenceStream and SmartRefStream are your choices.
> Take a look at the class comments, play with the examples. Ask questions.
>  
>  Cheers,
>  Juan Vuletich
>  
>  
>  On 11/6/2015 3:42 PM, Ignacio Sniechowski wrote:
>>   
>> Hi Juan,
>>  
>> Thanks for your response.
>>  
>> I?m not trying to serialize classes but instances of them.
>>  
>> Suppose theres a class called Memo with an ivar ?content?
>>  
>> Then I want to be able add to the instances the posibility of storing their
>> data.
>>  
>> fileOut is great for classes I use it a lot!
>>  
>> But I want a way to preserve data outside the image, so it can be loaded when
>> a new image is used.
>>  
>> thanks!
>>  
>> Nacho
>>  
>> 
>>  
>>  
>>  
>>  
>> --?
>>  Ignacio Sniechowski
>>  
>> Prosavic SRL
>>  Sent with Airmail
>>  
>>  
>>  
>> 
>> On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org) wrote:
>>  
>>>  
>>>  
>>> Hi Nacho, 
>>>  
>>>  On 11/1/2015 11:45 PM, nacho wrote:
>>>>  > Hi Folks, 
>>>>  > I'm trying to add support for serializing instances of a class.
>>>>  > I'm looking at System-Object Storage
>>>>  > And in particular to the class SmartRefStream which seems to add that
>>>>  > functionality. However, the class has no comments and no examples.
>>>>  > Is there some example which uses this class? a short demo? an example?
>>>>  > Thanks in advance!!
>>>>  > best 
>>>>  > Nacho 
>>>>  > 
>>>  
>>>  Are we browsing the same system? SmartRefStream class comment is 6016
>>>  characters here. Superclass ReferenceStream has a class comments of 2875
>>>  characters. DataStream and ReferenceStream have class methods that start
>>>  with 'example'. Looking for references to these classes also brings
>>>  useful examples of usage.
>>>  
>>>  In any case, the usual way to serialize classes is fileOut. Why doesn't
>>>  this work for you? What problem are you trying to solve?
>>>  
>>>  Cheers, 
>>>  Juan Vuletich 
>>>  
>>>  
>>>  
>>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151107/b0b7510f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ObjectEnhEd.2.cs
Type: application/octet-stream
Size: 15734 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151107/b0b7510f/attachment-0003.obj>

From hannes.hirzel at gmail.com  Sat Nov  7 08:49:21 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 7 Nov 2015 15:49:21 +0100
Subject: [Cuis] serialization in Cuis
In-Reply-To: <D263674C.16FF1%edgardec2005@gmail.com>
References: <563CF5F4.1070808@jvuletich.org>
	<D263674C.16FF1%edgardec2005@gmail.com>
Message-ID: <CAGQxfVh391ZLuY4TDE3tLw+i=ZF4vNEMn3_ZL-29Sj-fTmv0GQ@mail.gmail.com>

Hello Nacho

Is it possible that your Cuis system does not show the class comments
for some reason?

Juan referred you to the class comment of ReferenceStream and the
subclass SmartreferenceStream.

The comment of class ReferenceStream below. It gives an example how to
store objects.

Regards
Hannes


---------------------------------
Comment of class ReferenceStream in Cuis 4.2-2563


This is a way of serializing a tree of objects into disk file. A
ReferenceStream can store
one or more objects in a persistent form, including sharing and cycles.

Here is the way to use DataStream and ReferenceStream:
	rr _ ReferenceStream fileNamed: 'test.obj'.
	rr nextPut: <your object>.
	rr close.

To get it back:
	rr _ ReferenceStream fileNamed: 'test.obj'.
	<your object> _ rr next.
	rr close.

ReferenceStreams can now write "weak" references. nextPutWeak:
writes a "weak" reference to an object, which refers to that object
*if* it also gets written to the stream by a normal nextPut:.

A ReferenceStream should be treated as a read-stream *or* as a
write-stream, *not* as a read/write-stream. The reference-remembering
mechanism would probably do bad things if you tried to read and write
from the same ReferenceStream.

[TBD] Should we override "close" to do (self forgetReferences)?

Instance variables
 references -- an IdentityDictionary mapping objects already written
	to their byteStream positions. If asked to write any object a
	second time, we just write a reference to its stream position.
	This handles shared objects and reference cycles between objects.
	To implement "weak references" (for Aliases), the references
	dictionary also maps objects not (yet?) written to a Collection
	of byteStream positions with hopeful weak-references to it. If
	asked to definitely write one of these objects, we'll fixup those
	weak references.
 objects -- an IdentityDictionary mapping relative byte stream positions to
	objects already read in. If asked to follow a reference, we
	return the object already read.
	This handles shared objects and reference cycles between objects.
 currentReference -- the current reference position. Positon relative to the
	start of object data in this file.  (Allows user to cut and paste smalltalk
	code from the front of the file without effecting the reference values.)
	This variable is used to help install each new object in "objects" as soon
	as it's created, **before** we start reading its contents, in
	case any of its content objects reference it.
 fwdRefEnds -- A weak reference can be a forward reference, which
	requires advance-reading the referrent. When we later come to the
	object, we must get its value from "objects" and not re-read it so
	refs to it don't become refs to copies. fwdRefEnds remembers the
	ending byte stream position of advance-read objects.
 skipping -- true if <what?>

If the object is referenced before it is done being created, it might
get created twice.  Just store the object the moment it is created in
the 'objects' dictionary.  If at the end, comeFullyUpOnReload returns
a different object, some refs will have the temporary object (this is
an unlikely case).  At the moment, no implementor of
comeFullyUpOnReload returns a different object except DiskProxy, and
that is OK.


On 11/7/15, Edgar J. De Cleene <edgardec2005 at gmail.com> wrote:
> As Juan said, ReferenceStream is your friend
> Here I attach a old cs
> If you wish , Foo saveOnFileNamed: 'Foo'create a Foo.obj file in your
> working directory.
> Later you could use readAndInspect: 'Path to your file'
> When you have DrgaAndDrop as my forked CuiSantafesino you could exchange
> working objects between Squeak,Cuis and Pharo.
> And if you said Pharo do not have ReferenceStream , well I made how to for
> Pharo 2.0 so is possible.
> With this technique I export and import objects big enough for have
> complete
> swiki into a Squeak derivate image, about 14 mb of data
> Cheers
>
> Edgar
> @morplenauta
>
>
>
>
> On 11/6/15, 3:48 PM, "Juan Vuletich" <juan at jvuletich.org> wrote:
>
>>  Hi Nacho,
>>
>>  Oh, yes, I misread. Ok. ReferenceStream and SmartRefStream are your
>> choices.
>> Take a look at the class comments, play with the examples. Ask questions.
>>
>>  Cheers,
>>  Juan Vuletich
>>
>>
>>  On 11/6/2015 3:42 PM, Ignacio Sniechowski wrote:
>>>
>>> Hi Juan,
>>>
>>> Thanks for your response.
>>>
>>> I?m not trying to serialize classes but instances of them.
>>>
>>> Suppose theres a class called Memo with an ivar ?content?
>>>
>>> Then I want to be able add to the instances the posibility of storing
>>> their
>>> data.
>>>
>>> fileOut is great for classes I use it a lot!
>>>
>>> But I want a way to preserve data outside the image, so it can be loaded
>>> when
>>> a new image is used.
>>>
>>> thanks!
>>>
>>> Nacho
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>  Ignacio Sniechowski
>>>
>>> Prosavic SRL
>>>  Sent with Airmail
>>>
>>>
>>>
>>>
>>> On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org)
>>> wrote:
>>>
>>>>
>>>>
>>>> Hi Nacho,
>>>>
>>>>  On 11/1/2015 11:45 PM, nacho wrote:
>>>>>  > Hi Folks,
>>>>>  > I'm trying to add support for serializing instances of a class.
>>>>>  > I'm looking at System-Object Storage
>>>>>  > And in particular to the class SmartRefStream which seems to add
>>>>> that
>>>>>  > functionality. However, the class has no comments and no examples.
>>>>>  > Is there some example which uses this class? a short demo? an
>>>>> example?
>>>>>  > Thanks in advance!!
>>>>>  > best
>>>>>  > Nacho
>>>>>  >
>>>>
>>>>  Are we browsing the same system? SmartRefStream class comment is 6016
>>>>  characters here. Superclass ReferenceStream has a class comments of
>>>> 2875
>>>>  characters. DataStream and ReferenceStream have class methods that
>>>> start
>>>>  with 'example'. Looking for references to these classes also brings
>>>>  useful examples of usage.
>>>>
>>>>  In any case, the usual way to serialize classes is fileOut. Why
>>>> doesn't
>>>>  this work for you? What problem are you trying to solve?
>>>>
>>>>  Cheers,
>>>>  Juan Vuletich
>>>>
>>>>
>>>>
>>>
>
>



From dnorton at mindspring.com  Sat Nov  7 20:12:43 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 07 Nov 2015 21:12:43 -0500
Subject: [Cuis] BouncingAtomsMorph
Message-ID: <563EAF9B.28589.26788EA@dnorton.mindspring.com>

Hi Juan,

Thanks for fixing it so that #doOneCycleNow is no longer needed during initialization. 
The code reads much better.

Next time you build, please update from my repo:

	https://github.com/dhnorton/Cuis-Smalltalk-atoms

I made the following changes:

	- added #open method in case someone wants to bring it up from the browser 
or a workspace (old way no longer works).
	- HeaterCoolerAtoms no longer affect each other when they collide.
	- appearance tweaks to HeaterCoolerAtoms.
	- improved the initial movement and distribution of atoms.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151107/005040c8/attachment-0003.html>

From euanmee at gmail.com  Sun Nov  8 10:18:57 2015
From: euanmee at gmail.com (Euan Mee)
Date: Sun, 8 Nov 2015 16:18:57 +0000
Subject: [Cuis] Current state of activity
Message-ID: <CALsRT0m1o_aask7bPD6_RHq7dePHFJUBULKHKeqbW7+MavBgWg@mail.gmail.com>

Hi, I'm a newcomer to Cuis.

The main web-site was last updated in July 2013

How active is CUIS atm.?

Is it fair to characterise CUIS as a minimalist image for running on
top of the current latest Squeak VMs  e.g. Cog with Spur (and with the
Scorch and Sista upgrades once they are out?)

I'm looking to build Smalltalk apps to control, manage, set up and
distribute multi-platform mobile web-apps.

So what I'm looking for is a Smalltalk development environment and
development management environment
an http server and an https server
a multi-platform (Windows, Linux, MacOS) desktop GUI environment and
desktop GUI apps
a web framework

My ideal is a central desktop GUI app that can run from a Raspberry Pi
which is also running a webserver which hands out JS apps securely to
mobile devices.

I'm happy to with development work, or help backport necessary items
from Squeak/Pharo

Cheers,
     EuanM



From juan at jvuletich.org  Mon Nov  9 06:42:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 09 Nov 2015 09:42:43 -0300
Subject: [Cuis] Current state of activity
In-Reply-To: <CALsRT0m1o_aask7bPD6_RHq7dePHFJUBULKHKeqbW7+MavBgWg@mail.gmail.com>
References: <CALsRT0m1o_aask7bPD6_RHq7dePHFJUBULKHKeqbW7+MavBgWg@mail.gmail.com>
Message-ID: <564094C3.3070001@jvuletich.org>

Hi Euan,

On 11/8/2015 1:18 PM, Euan Mee wrote:
> Hi, I'm a newcomer to Cuis.

Welcome!

> The main web-site was last updated in July 2013
>
> How active is CUIS atm.?

Quite. See 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors 
. Mail lista rchives are at 
http://forum.world.st/Cuis-Smalltalk-f4632260.html .

> Is it fair to characterise CUIS as a minimalist image for running on
> top of the current latest Squeak VMs  e.g. Cog with Spur (and with the
> Scorch and Sista upgrades once they are out?)

Yes. In any case, see 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/GettingStarted-UsingGitAndCommandline.md 
and sibling files .

> I'm looking to build Smalltalk apps to control, manage, set up and
> distribute multi-platform mobile web-apps.
>
> So what I'm looking for is a Smalltalk development environment and
> development management environment
> an http server and an https server
> a multi-platform (Windows, Linux, MacOS) desktop GUI environment and
> desktop GUI apps
> a web framework
>
> My ideal is a central desktop GUI app that can run from a Raspberry Pi
> which is also running a webserver which hands out JS apps securely to
> mobile devices.

Interesting! Please keep us posted.

> I'm happy to with development work, or help backport necessary items
> from Squeak/Pharo
>

Great. As you progress, you'll find out about stuff you need to develop 
or port to Cuis. Contributions to the base image, or optional packages 
are all welcome (please remember that to be added to the main GitHub 
Cuis repo, all code needs to be MIT). Besides, here on the mail list, 
you can discuss any issues, ask for opinions or advice, or for existing 
code, etc.

> Cheers,
>       EuanM

Cheers,
Juan Vuletich



From 0800nacho at gmail.com  Mon Nov  9 18:53:16 2015
From: 0800nacho at gmail.com (nacho)
Date: Mon, 9 Nov 2015 16:53:16 -0800 (PST)
Subject: [Cuis] Symbols that start with and uppercase letter
Message-ID: <1447116796630-4860091.post@n4.nabble.com>

Hi Folks,
I'm trying to generate a collection from all instances of Symbol that begin
with a capital letter.
I know how to do this for one case:

| aSymbolArray aSymbol |

aSymbolArray _ Symbol allInstances.
aSymbol _ (aSymbolArray at: 1).
(aSymbol at: 1) isUppercase.

But I want to use something like collect:
| aSymbolArray |

aSymbolArray _ Symbol allInstances.
aSymbolArray collect: [ :a | | aSymbol | aSymbol _ aSymbolArray at: a.
(aSymbol at: 1) isUppercase].

But I'm lost.
Any help?
Thanks in advance!
best
Nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Symbols-that-start-with-and-uppercase-letter-tp4860091.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Mon Nov  9 21:12:26 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Mon, 9 Nov 2015 19:12:26 -0800
Subject: [Cuis] Symbols that start with and uppercase letter
In-Reply-To: <1447116796630-4860091.post@n4.nabble.com>
References: <1447116796630-4860091.post@n4.nabble.com>
Message-ID: <20151109191226.d42159dd728b6a0d5a7d1548@Whidbey.com>

On Mon, 9 Nov 2015 16:53:16 -0800 (PST)
nacho <0800nacho at gmail.com> wrote:

> Hi Folks,
> I'm trying to generate a collection from all instances of Symbol that begin
> with a capital letter.

Symbol allInstances select: [ :s | (s size > 0) and: [(s asString at: 1) isUppercase ]].

Cheers, 
-KenD



From euanmee at gmail.com  Wed Nov 11 08:13:57 2015
From: euanmee at gmail.com (Euan Mee)
Date: Wed, 11 Nov 2015 14:13:57 +0000
Subject: [Cuis] Simple Morphic
Message-ID: <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w@mail.gmail.com>

What is the current state of development of Simple Morph?

Is there any documentation on how to use it, or is it allInTheCode ?



From Ken.Dickey at Whidbey.com  Wed Nov 11 10:13:58 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Wed, 11 Nov 2015 08:13:58 -0800
Subject: [Cuis] Simple Morphic
In-Reply-To: <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w@mail.gmail.com>
References: <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w@mail.gmail.com>
Message-ID: <20151111081358.4a0291315670cadcdcead39f@Whidbey.com>

On Wed, 11 Nov 2015 14:13:57 +0000
Euan Mee <euanmee at gmail.com> wrote:

> What is the current state of development of Simple Morph?

I am not sure what you mean by Simple Morph.

Cuis has been taking steps toward Morphic3:

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md

The MorphExtension class was removed.  (We have Morph Properties).

Morphs have float rather than integer location coordinates.

Morph location is relative to their owner, not the screen.

These are relatively small changes to get used to.

More radical are some of the other simplifications in the system.

The best example here is probably Layout.

LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.

The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.

See LayoutMorph class examples.

If you git clone the Morphic-Misc1 package and load it you can get Layout editors:

Open a shell and cd to the directory containing Cuis-Smalltalk-Dev

  git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git

Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:

  Feature require:  'Morphic-Misc1'.

Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.  

Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.

If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.

> Is there any documentation on how to use it, or is it allInTheCode ?

See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.

-- 
-KenD



From euanmee at gmail.com  Wed Nov 11 13:02:54 2015
From: euanmee at gmail.com (Euan Mee)
Date: Wed, 11 Nov 2015 19:02:54 +0000
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
Message-ID: <CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>

Thanks for the pointer to Morphic3 and its documentation.  I'll try to
contribute more naive-user questions :-)

What is the state of development of Morphic3?
  - complete stable codebase?
  - stable codebase for substantial parts, with fuurther extensions in
development?
  - central aspects still under development?
  - a design concept, coding yet to begin?

e.g. The documentation starts off with "Morphic3 *will have* scalable
graphics".  This might mean that Morphic3 works now, but does not yet
have scalable graphics.  Or it might just mean Morphic3 does not (yet)
work.

Generally, whenever I'm looking at a new platform, system, or package,
I am initially looking for answers of the type
   "Can I use it now?
        No /
        Yes /
        Yes to an extent, but..."

I'm very happy to write up aspects of the system/package as
fully-formed documentation, especially documentation for naive-users.
Please let me know if there specific places where this help is
already-known to be particularly needed.

I look forward (in the long run?) to trying Cuis and Morphic3 on Raspberry Pi.

On 11 November 2015 at 18:00,  <cuis-request at jvuletich.org> wrote:
> Send Cuis mailing list submissions to
>         cuis at jvuletich.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> or, via email, send a message with subject or body 'help' to
>         cuis-request at jvuletich.org
>
> You can reach the person managing the list at
>         cuis-owner at jvuletich.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cuis digest..."
>
>
> Today's Topics:
>
>    1. Simple Morphic (Euan Mee)
>    2. Re: Simple Morphic (KenD)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 11 Nov 2015 14:13:57 +0000
> From: Euan Mee <euanmee at gmail.com>
> To: cuis at jvuletich.org
> Subject: [Cuis] Simple Morphic
> Message-ID:
>         <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> What is the current state of development of Simple Morph?
>
> Is there any documentation on how to use it, or is it allInTheCode ?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 11 Nov 2015 08:13:58 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: Euan Mee <euanmee at gmail.com>
> Subject: Re: [Cuis] Simple Morphic
> Message-ID: <20151111081358.4a0291315670cadcdcead39f at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Wed, 11 Nov 2015 14:13:57 +0000
> Euan Mee <euanmee at gmail.com> wrote:
>
>> What is the current state of development of Simple Morph?
>
> I am not sure what you mean by Simple Morph.
>
> Cuis has been taking steps toward Morphic3:
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>
> The MorphExtension class was removed.  (We have Morph Properties).
>
> Morphs have float rather than integer location coordinates.
>
> Morph location is relative to their owner, not the screen.
>
> These are relatively small changes to get used to.
>
> More radical are some of the other simplifications in the system.
>
> The best example here is probably Layout.
>
> LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.
>
> The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.
>
> See LayoutMorph class examples.
>
> If you git clone the Morphic-Misc1 package and load it you can get Layout editors:
>
> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>
>   git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>
> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:
>
>   Feature require:  'Morphic-Misc1'.
>
> Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>
> Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.
>
> If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.
>
>> Is there any documentation on how to use it, or is it allInTheCode ?
>
> See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.
>
> --
> -KenD
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 41, Issue 14
> ************************************



From euanmee at gmail.com  Wed Nov 11 13:41:24 2015
From: euanmee at gmail.com (Euan Mee)
Date: Wed, 11 Nov 2015 19:41:24 +0000
Subject: [Cuis] Simple Morphic
Message-ID: <CALsRT0=_8W2iHB4amNP_V95H0S_HhbtPYh8yjG_tcXgeQs2c8g@mail.gmail.com>

Thanks for the pointer to Morphic3 and its documentation.  I'll try to
contribute more naive-user questions :-)

What is the state of development of Morphic3?
  - complete stable codebase?
  - stable codebase for substantial parts, with fuurther extensions in
development?
  - central aspects still under development?
  - a design concept, coding yet to begin?

e.g. The documentation starts off with "Morphic3 *will have* scalable
graphics".  This might mean that Morphic3 works now, but does not yet
have scalable graphics.  Or it might just mean Morphic3 does not (yet)
work.

Generally, whenever I'm looking at a new platform, system, or package,
I am initially looking for answers of the type
   "Can I use it now?
        No /
        Yes /
        Yes to an extent, but..."

I'm very happy to write up aspects of the system/package as
fully-formed documentation, especially documentation for naive-users.
Please let me know if there specific places where this help is
already-known to be particularly needed.

I look forward (in the long run?) to trying Cuis and Morphic3 on Raspberry Pi.

In the meantime, I'm catching up on what's written at:
https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1
and
https://github.com/KenDickey/Cuis-Smalltalk-ColorEditor


On 11 November 2015 at 16:13, KenD <Ken.Dickey at whidbey.com> wrote:
> On Wed, 11 Nov 2015 14:13:57 +0000
> Euan Mee <euanmee at gmail.com> wrote:
>
>> What is the current state of development of Simple Morph?
>
> I am not sure what you mean by Simple Morph.
>
> Cuis has been taking steps toward Morphic3:
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>
> The MorphExtension class was removed.  (We have Morph Properties).
>
> Morphs have float rather than integer location coordinates.
>
> Morph location is relative to their owner, not the screen.
>
> These are relatively small changes to get used to.
>
> More radical are some of the other simplifications in the system.
>
> The best example here is probably Layout.
>
> LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.
>
> The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.
>
> See LayoutMorph class examples.
>
> If you git clone the Morphic-Misc1 package and load it you can get Layout editors:
>
> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>
>   git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>
> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:
>
>   Feature require:  'Morphic-Misc1'.
>
> Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>
> Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.
>
> If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.
>
>> Is there any documentation on how to use it, or is it allInTheCode ?
>
> See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.
>
> --
> -KenD



From Ken.Dickey at Whidbey.com  Wed Nov 11 17:56:37 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Wed, 11 Nov 2015 15:56:37 -0800
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
Message-ID: <20151111155637.a6fc5a89ab8ca768aa93510a@Whidbey.com>

On Wed, 11 Nov 2015 19:02:54 +0000
Euan Mee <euanmee at gmail.com> wrote:

> What is the state of development of Morphic3?

Juan is working on an optimized MorphicCanvas to replace BitBltCanvas.

There is some old, unoptimized sample code in Cuis-Smalltalk-Dev/Experimental which is not for the faint of heart.

Cuis currently uses BitBltCanvas, so the graphics do not yet scale.

Most of the other code works fine.  The location changes to Morph were a big step.

Juan has been slimming down the Cuis image so that it should be possible to rapidly grow when scalable.  Slim down .. grow .. scale  ;^)

Note the small number of classes in the base image:
"2236 eToys 5.0"
"2511 Squeak 4.4"
"2175 Squeak 4.5"
"2244 Squeak 5.0"
"3226 Pharo 2.0"
"4020 Pharo 3.0"
"4924 Pharo 4.0"
  vvv
" 504 Cuis 4.2 (rev 2568)"
  ^^^

Juan, anything to add/correct here?

-- 
-KenD



From pbpublist at gmail.com  Wed Nov 11 20:05:36 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 11 Nov 2015 21:05:36 -0500
Subject: [Cuis] Simple Morphic
In-Reply-To: <CALsRT0=_8W2iHB4amNP_V95H0S_HhbtPYh8yjG_tcXgeQs2c8g@mail.gmail.com>
References: <CALsRT0=_8W2iHB4amNP_V95H0S_HhbtPYh8yjG_tcXgeQs2c8g@mail.gmail.com>
Message-ID: <1447293936.10654.37.camel@gmail.com>

Hi Euan,

On Wed, 2015-11-11 at 19:41 +0000, Euan Mee wrote:
> I am initially looking for answers of the type
> ???"Can I use it now?
> ????????No /
> ????????Yes /
> ????????Yes to an extent, but..."
> 

The short answer is no. ?It's still at an experimental / work in
progress stage. ?As Ken mentioned, you can take a look at a snapshot of
the code but it's not in a state where you can enable it and have
things even mostly work or be productive with it as your GUI. ?There's
still much work to be done: functionality to be added, bugs to be
fixed, performance to be tuned etc.

Thanks,
Phil



From dnorton at mindspring.com  Thu Nov 12 18:46:26 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 12 Nov 2015 19:46:26 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <564532E2.5884.24794CB@dnorton.mindspring.com>

Hi Juan,

On 3 Nov 2015 at 14:58, Dan Norton wrote:

> Hi Juan,
> 
> As recommended by Ken and Hannes, the attached methods add the
> capability to bring up 
> the class comment browser from the help menu.
> 
> Sorry, but I still don't know how to prepend the thumbnail to the
> menu item :)
> 

Found how to do it! The attached change to Theme>>basicIcons makes the Help icon 
appear for Class Comment Browser. Please include in the next build.

Thanks,
 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Theme-basicIcons.zip
Type: application/zip
Size: 1289 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151112/435f9b9a/attachment-0003.zip>

From dnorton at mindspring.com  Fri Nov 13 11:58:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 13 Nov 2015 12:58:22 -0500
Subject: [Cuis] #when:send:to:
Message-ID: <564624BE.15549.F1568C@dnorton.mindspring.com>

Hello Everyone,

The following repo contains before and after examples of replacing the Dependency 
Mechanism with the Observer Pattern:

	https://github.com/dhnorton/Cuis-Smalltalk-light

Please take a look at this and tell me what needs to change. I'm trying to supply an example 
of the Observer Pattern so that others might use #when:send:to: with less difficulty than I 
experienced. There may be better examples but I picked one from the Blue Book.

It seems that #when:send:to: is necessary but not sufficient as a replacement for the 
Dependency Mechanism. In this example, it replaced #addDependent:, not #changed or 
#update and I am still not comfortable with how to choose the parameters. This may be an 
example of the difficulty in explaining the obvious, I'm not sure :-)

The #changed method was replaced with #triggerEvent: with a symbol argument which is 
referred to in one of the arguments of #when:send:to: and that's the only constraint AFAICT.

The #update: method was retained, as a convenience; it also needs to agree with one of the 
arguments of #when:send:to: and could have been different.

Please tell me if any of this is wrong. Thanks.

 - Dan 



From Ken.Dickey at Whidbey.com  Fri Nov 13 20:33:24 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Fri, 13 Nov 2015 18:33:24 -0800
Subject: [Cuis] #when:send:to:
In-Reply-To: <564624BE.15549.F1568C@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>
Message-ID: <20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>

On Fri, 13 Nov 2015 12:58:22 -0500
"Dan Norton" <dnorton at mindspring.com> wrote:

> Hello Everyone,
> 
> The following repo contains before and after examples of replacing the Dependency 
> Mechanism with the Observer Pattern:
> 
> 	https://github.com/dhnorton/Cuis-Smalltalk-light
> 
> Please take a look at this and tell me what needs to change.

Dan,

Good start.

I would suggest a deeper example.

Lights could be a model with a presenter (LightPanel) which shows the lights.  E.g. open a layout morph with a row of elipses (circles) which are red/green (or whatever) for off/on.

Clicking on a light changes the model (Lights subclass ActiveModel), which signals 
  triggerEvent: #colorChange with: aColor.

You can look in Morphic-Misc1 at RadioButtonMorph to see how to handle clicks.

Workspace code could also turn off/on or just toggle lights in the model, with the LightPanel presenter updating appropriately.

One can then add a bit of wackyness, like using different colors than red/green and the presenter will show the proper color..

$0.02.
-KenD 



From euanmee at gmail.com  Fri Nov 13 23:02:53 2015
From: euanmee at gmail.com (EuanM)
Date: Sat, 14 Nov 2015 05:02:53 +0000
Subject: [Cuis] New Introductory Tutorial
Message-ID: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>

I've created Yet Another Smalltalk First
Steps tutorial.

This is intended as one of a series.

It is designed to be cross-platform across

    Squeak 5
    Pharo 4
    Seaside 3.1
    Cuis
    Dolphin 6

If you have experience running any of these systems on Windows, Linux
or MacOS, please check to see if I have the instructions correct for
your chosen pairing of Smalltalk and OS platform.

(As you'll see when you look, I do not have detailed instructions for
aspects of MacOS).

The document is at:
http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html

(It's intended to move to a different blog after this review process).

I feel the need to do this as cross-Smalltalks tutorial because of
findings and 4 charts  I've placed at:
http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/mindshare-of-smalltalk-in-development.html

Essentially, Smalltalk mindshare and use is incredibly tiny, compared
to other languages in the same space.  (We all know this, but seeing
it represented graphically has a more visceral effect, IMO)

Aggregating interest in all the Smalltalks still does not bring more
than a tiny proportion of the interest in, and use of, Ruby.

In turn, Ruby is (quite understandably) small in comparison to JavaScript.

Comparing interest in any specific Smalltalk is, predictably, smaller
than the aggregate interest in Smalltalk.

Our community seems determined to split itself into smaller and
smaller sub-communities.  I think we do ourselves a disservice this
way.

My initial contribution will be to try to provide some explicitly
pan-Smalltalk beginners' tutorials, like this one.

Cheers, and happy Smalltalking,
     EuanM



From euanmee at gmail.com  Fri Nov 13 23:12:31 2015
From: euanmee at gmail.com (EuanM)
Date: Sat, 14 Nov 2015 05:12:31 +0000
Subject: [Cuis] One-Click Installer for Cuis
Message-ID: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>

I've just recently put-together a cross-platform Installation Tutorial
for beginners to Smalltalk.

I was keen to include Cuis in the exercise.

One thing that becomes clear in the comparison is that Cuis is a good
beginner's environment from the point of view of size and complexity
and their bearing in learnability.

It is however, the worst Smalltalk (of the 4 in the tutorial) to get
downloaded and installed.

This seems a pity.

Would anyone be willing to help me put together a One-Click Install
package, similar to Squeak's and Pharo's?

(My plan is to do the grunt-work, if other people are willing to
indulge my noob questions while I do it)

Is there a particular place that it could be hosted, once ready?

Would anyone disagree with a 6-monthly update cycle for the One-Click installer?

(Frequent enough to send a signal to interested beginners that the
project is alive and kicking.  Infrequent enough that there is not
much work to be done)

Cheers,
   Euan



From hari.balaraman at icloud.com  Sat Nov 14 08:37:34 2015
From: hari.balaraman at icloud.com (Hari Balaraman)
Date: Sat, 14 Nov 2015 11:37:34 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <563CF53B.5000107@jvuletich.org>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
Message-ID: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>

Hi Juan,

It was very nice to sit down and chat with you on the sidelines of the conference. Thank you for taking the time to look at my stuttering project and offer advice (on the history of projects, strangely, some others I talked to didn?t recognise the names Mark Guzdial and Bijan Parsia.) Although I missed first two days because of careless travel planning, I?m hoping FAST will put videos of the presentations on the website so I can catch up. 

The two people at Toronto Smalltalk Users Group I mentioned are Bob Nemec and Dave Mason, a professor at Ryerson University. My knowledge of the use of SmallTalk in the CS curriculum there is second or third-hand and so may not be current. I haven?t actually met them as the one Monday evening I was able to make it to TSUG, I was late and both of them had left by then. :)

Thanks for the tip on visiting the bookshops on Avenida Corrientes in this amazing city. I passed it on the way home and realised I haven?t gone down this street in my wanderings. If you are going to be in the city before Tuesday afternoon, and are free and bored, do let me know.

Best regards,

Hari
>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org <mailto:juan at jvuletich.org>) wrote:
>> 
>>> Hi Hari,
>>> 
>>> I'll be there. Let's meet then.
>>> 
>>> Anybody else?
>>> 
>>> Cheers,
>>> Juan Vuletich
>>> 
>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>> 
>>>> If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
>>>> Best regards,
>>>> Hari
>>>> 
>>>> _______________________________________________
>>>> Cuis mailing list
>>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>>> 
>>> _______________________________________________ 
>>> Cuis mailing list 
>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org> 
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151114/17eb3e43/attachment-0003.html>

From 0800nacho at gmail.com  Sat Nov 14 09:45:12 2015
From: 0800nacho at gmail.com (nacho)
Date: Sat, 14 Nov 2015 07:45:12 -0800 (PST)
Subject: [Cuis] FAST conference
In-Reply-To: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
References: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
Message-ID: <1447515912161-4861043.post@n4.nabble.com>

I agree with Hari,
It was very nice to meet you Juan.
Thanks for your work and advice.
Best
Nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/FAST-conference-tp4859418p4861043.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Sat Nov 14 10:09:22 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sat, 14 Nov 2015 08:09:22 -0800
Subject: [Cuis] New Introductory Tutorial
In-Reply-To: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
References: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
Message-ID: <20151114080922.9fc084ad463f841976311bb7@Whidbey.com>

On Sat, 14 Nov 2015 05:02:53 +0000
EuanM <euanmee at gmail.com> wrote:

> I've created Yet Another Smalltalk First
> Steps tutorial.
...
> If you have experience running any of these systems on Windows, Linux
> or MacOS, please check to see if I have the instructions correct for
> your chosen pairing of Smalltalk and OS platform.

On Linux, Cuis works fine from the command line once the proper SqueakVM is installed.

E.g. in the Cuis-Smalltalk-Dev directory
   squeak  Cuis4.2-2571.image

> The document is at:
> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html

The different Squeak VMs are transition points and might need some explanation.

The stack-interpreter VM is a traditional bytecode interpreter.

Cog does just-in-time (JIT) compilation to native code for faster execution.

Spur is a new memory model which simplifies object layouts and is common between 32 and 64 bit memory architectures.  Because of object format/layout changes Spur images must be run on a Spur VMs and non-Spur images on a non-Spur VM.  You have to match the VM to the object format.

As far as I am aware, there is no Spur image for Cuis yet.  We need to write a tool to read a current image and write it out in Spur format.  Spur code is still evolving rapidly, so writing the  image translation has not been a priority for us.  Now that Squeak 5.0 is out (the 4.x series used the old format, 5.0 uses Spur) things are probably stable enough that we can get to this.

-- 

One side note is that none of the Cog (JIT) VMs run on ARM Chromebooks under Chrome OS.  I don't run Intel, but suspect the JIT is broken there as well.  This apparently has to do with the tightening up of code security policies in the Chromium OS.  As JIT means writing data, then executing this as code, there is an obvious security hole to be addressed.

It appears that there are are/should be rubrics/rules which allow JIT.  The V8 JavaScript VM does JIT on ChromeOS.  But it takes time to dig through the megabytes of code and docs to get at the details.  This is in progress, but there is not much resource (people time) to devote to it.

FYI,
-KenD



From edgardec2005 at gmail.com  Sat Nov 14 15:29:34 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Sat, 14 Nov 2015 18:29:34 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
Message-ID: <BF8DA200-D5CF-424C-8168-F5568D5C2253@gmail.com>

Also i say very, very thanks for all your talks, time to listening my crazy ideas and tu calidez como ser humano
Too bad also  i going without plan .
We should schedule some hangouts when yo have the time.
Wish know Nacho and Hari , look for me on Facebook and start  Cuis Friendship
Again thanks Juan.




> On Nov 14, 2015, at 11:37 AM, Hari Balaraman <hari.balaraman at icloud.com> wrote:
> 
> Hi Juan,
> 
> It was very nice to sit down and chat with you on the sidelines of the conference. Thank you for taking the time to look at my stuttering project and offer advice (on the history of projects, strangely, some others I talked to didn?t recognise the names Mark Guzdial and Bijan Parsia.) Although I missed first two days because of careless travel planning, I?m hoping FAST will put videos of the presentations on the website so I can catch up. 
> 
> The two people at Toronto Smalltalk Users Group I mentioned are Bob Nemec and Dave Mason, a professor at Ryerson University. My knowledge of the use of SmallTalk in the CS curriculum there is second or third-hand and so may not be current. I haven?t actually met them as the one Monday evening I was able to make it to TSUG, I was late and both of them had left by then. :)
> 
> Thanks for the tip on visiting the bookshops on Avenida Corrientes in this amazing city. I passed it on the way home and realised I haven?t gone down this street in my wanderings. If you are going to be in the city before Tuesday afternoon, and are free and bored, do let me know.
> 
> Best regards,
> 
> Hari
>>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org <mailto:juan at jvuletich.org>) wrote:
>>> 
>>>> Hi Hari,
>>>> 
>>>> I'll be there. Let's meet then.
>>>> 
>>>> Anybody else?
>>>> 
>>>> Cheers,
>>>> Juan Vuletich
>>>> 
>>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>>> 
>>>>> If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
>>>>> Best regards,
>>>>> Hari
>>>>> 
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>>>> 
>>>> _______________________________________________ 
>>>> Cuis mailing list 
>>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org> 
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> 
>> 
>> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151114/e42bf08f/attachment-0003.html>

From dnorton at mindspring.com  Sun Nov 15 12:47:00 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 15 Nov 2015 13:47:00 -0500
Subject: [Cuis] #when:send:to:
In-Reply-To: <20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>
Message-ID: <5648D324.31295.859AEA@dnorton.mindspring.com>

On 13 Nov 2015 at 18:33, KenD wrote:

> On Fri, 13 Nov 2015 12:58:22 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> > Hello Everyone,
> > 
> > The following repo contains before and after examples of replacing
> the Dependency 
> > Mechanism with the Observer Pattern:
> > 
> > 	https://github.com/dhnorton/Cuis-Smalltalk-light
> > 
> > Please take a look at this and tell me what needs to change.
> 
> Dan,
> 
> Good start.
> 
> I would suggest a deeper example.
> 

Hmm, I made it stark simple in order to focus on the basics. However, a couple of 
possibilities could be: a 3-bulb traffic light with a change button (incremental add-on), or a 
drag race tree (elaborate).

 - Dan

> Lights could be a model with a presenter (LightPanel) which shows
> the lights.  E.g. open a layout morph with a row of elipses
> (circles) which are red/green (or whatever) for off/on.
> 
> Clicking on a light changes the model (Lights subclass ActiveModel),
> which signals 
>   triggerEvent: #colorChange with: aColor.
> 
> You can look in Morphic-Misc1 at RadioButtonMorph to see how to
> handle clicks.
> 
> Workspace code could also turn off/on or just toggle lights in the
> model, with the LightPanel presenter updating appropriately.
> 
> One can then add a bit of wackyness, like using different colors
> than red/green and the presenter will show the proper color..
> 
> $0.02.
> -KenD 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From Ken.Dickey at Whidbey.com  Sun Nov 15 14:35:54 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sun, 15 Nov 2015 12:35:54 -0800
Subject: [Cuis] #when:send:to:
In-Reply-To: <5648D324.31295.859AEA@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>
	<20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>
	<5648D324.31295.859AEA@dnorton.mindspring.com>
Message-ID: <20151115123554.1a6ce6591f522779d96f2aa6@Whidbey.com>

On Sun, 15 Nov 2015 13:47:00 -0500
"Dan Norton" <dnorton at mindspring.com> wrote:


> Hmm, I made it stark simple in order to focus on the basics. 

If a "light" does not have a visual representation, I would call it a "switch".

$0.02 
-KenD



From dnorton at mindspring.com  Sun Nov 15 21:20:16 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 15 Nov 2015 22:20:16 -0500
Subject: [Cuis] #when:send:to:
In-Reply-To: <20151115123554.1a6ce6591f522779d96f2aa6@Whidbey.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<5648D324.31295.859AEA@dnorton.mindspring.com>,
	<20151115123554.1a6ce6591f522779d96f2aa6@Whidbey.com>
Message-ID: <56494B70.22263.25B83DB@dnorton.mindspring.com>

On 15 Nov 2015 at 12:35, KenD wrote:

> On Sun, 15 Nov 2015 13:47:00 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> 
> > Hmm, I made it stark simple in order to focus on the basics. 
> 
> If a "light" does not have a visual representation, I would call it
> a "switch".
> 

Good point. I see the light of that; however, stark though it be, at least it lets you see state in 
the Transcript. The Blue Book used Light and TrafficLight then left you to use inspectors I 
presume. They didn't say :)

 - Dan



From juan at jvuletich.org  Mon Nov 16 12:53:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 15:53:49 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
Message-ID: <564A263D.9000808@jvuletich.org>

Hi Hari,

On 11/14/2015 11:37 AM, Hari Balaraman wrote:
> Hi Juan,
>
> It was very nice to sit down and chat with you on the sidelines of the 
> conference. Thank you for taking the time to look at my stuttering 
> project and offer advice (on the history of projects, strangely, some 
> others I talked to didn?t recognise the names Mark Guzdial and Bijan 
> Parsia.) Although I missed first two days because of careless travel 
> planning, I?m hoping FAST will put videos of the presentations on the 
> website so I can catch up.

It was my pleasure!

> The two people at Toronto Smalltalk Users Group I mentioned are Bob 
> Nemec and Dave Mason, a professor at Ryerson University. My knowledge 
> of the use of SmallTalk in the CS curriculum there is second or 
> third-hand and so may not be current. I haven?t actually met them as 
> the one Monday evening I was able to make it to TSUG, I was late and 
> both of them had left by then. :)

Nice to know, thanks.

> Thanks for the tip on visiting the bookshops on Avenida Corrientes in 
> this amazing city. I passed it on the way home and realised I haven?t 
> gone down this street in my wanderings. If you are going to be in the 
> city before Tuesday afternoon, and are free and bored, do let me know.

Well, during the weekend I tried to spend some time with family. Also on 
Saturday we spent time with other fellow Smalltalkers, including the 
organizers, and their families. So, I only read this today. If you are 
still around on Tuesday evening, we can drink some beer, coffee, 
whatever, after office. If you leave on Tuesday afternoon, maybe we can 
have lunch tomorrow Tuesday. The rest of the day I'm at work, as you 
would expect... :)

Cheers,
Juan Vuletich

> Best regards,
>
> Hari
>>>
>>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org 
>>> <mailto:juan at jvuletich.org>) wrote:
>>>
>>>> Hi Hari,
>>>>
>>>> I'll be there. Let's meet then.
>>>>
>>>> Anybody else?
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>>> If any of you are attending the FAST conference in Buenos Aires in 
>>>>> a week or so, I look forward to meeting you face to face.
>>>>> Best regards,
>>>>> Hari
>>>>>
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>
>>>> _______________________________________________
>>>> Cuis mailing list
>>>> Cuis at jvuletich.org
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/1347cb49/attachment-0003.html>

From juan at jvuletich.org  Mon Nov 16 14:04:37 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 17:04:37 -0300
Subject: [Cuis] BouncingAtomsMorph
In-Reply-To: <563EAF9B.28589.26788EA@dnorton.mindspring.com>
References: <563EAF9B.28589.26788EA@dnorton.mindspring.com>
Message-ID: <564A36D5.5010109@jvuletich.org>

On 11/7/2015 11:12 PM, Dan Norton wrote:
> Hi Juan,
>
> Thanks for fixing it so that #doOneCycleNow is no longer needed during 
> initialization. The code reads much better.
>
>
> Next time you build, please update from my repo:
>
>            https://github.com/dhnorton/Cuis-Smalltalk-atoms
>
> I made the following changes:
>
>            - added #open method in case someone wants to bring it up 
> from the browser or a workspace (old way no longer works).
>            - HeaterCoolerAtoms no longer affect each other when they 
> collide.
>            - appearance tweaks to HeaterCoolerAtoms.
>            - improved the initial movement and distribution of atoms.
>
>  - Dan
>

I'll do a commit during this week, and this will be included. Thank you!

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/b5b4538a/attachment-0003.html>

From juan at jvuletich.org  Mon Nov 16 14:25:50 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 17:25:50 -0300
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
Message-ID: <564A3BCE.9090409@jvuletich.org>

Hi Euan,

On 11/11/2015 4:02 PM, Euan Mee wrote:
> Thanks for the pointer to Morphic3 and its documentation.  I'll try to
> contribute more naive-user questions :-)
>
> What is the state of development of Morphic3?
>    - complete stable codebase?
>    - stable codebase for substantial parts, with fuurther extensions in
> development?
>    - central aspects still under development?
>    - a design concept, coding yet to begin?

I think "central aspects still under development" is a fair way to say it.
If you want to take a look, it is in the 'Experimental' folder. Feel 
free to ask questions.

> e.g. The documentation starts off with "Morphic3 *will have* scalable
> graphics".  This might mean that Morphic3 works now, but does not yet
> have scalable graphics.  Or it might just mean Morphic3 does not (yet)
> work.
>

Well, we have been evolving Morphic in Cuis, towards the direction shown 
by some experiments I did in 2009, for quite some time. This is 
currently using BitBltCanvas to draw, that can not do proper scalable 
graphics. The Morphic3Canvas in 'Experimental' can do this.

> Generally, whenever I'm looking at a new platform, system, or package,
> I am initially looking for answers of the type
>     "Can I use it now?
>          No /
>          Yes /
>          Yes to an extent, but..."
>
> I'm very happy to write up aspects of the system/package as
> fully-formed documentation, especially documentation for naive-users.
> Please let me know if there specific places where this help is
> already-known to be particularly needed.

Morphic 3 is ready to be studied by really interested ones. Not at all 
ready for a naive- user. On the question of where this help is needed, 
I'm not the best to answer. Maybe others in the community answer this, 
or, just use the system for some project, and you'll quickly find the 
places where a new user (you!) could use better documentation.

> I look forward (in the long run?) to trying Cuis and Morphic3 on Raspberry Pi.
>

Well, Morphic 3 might be more expensive than BitBltCanvas, and I don't 
know if it will run reasonably well on a Pi....

Cheers,
Juan Vuletich

> On 11 November 2015 at 18:00,<cuis-request at jvuletich.org>  wrote:
>> Send Cuis mailing list submissions to
>>          cuis at jvuletich.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>          http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> or, via email, send a message with subject or body 'help' to
>>          cuis-request at jvuletich.org
>>
>> You can reach the person managing the list at
>>          cuis-owner at jvuletich.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Cuis digest..."
>>
>>
>> Today's Topics:
>>
>>     1. Simple Morphic (Euan Mee)
>>     2. Re: Simple Morphic (KenD)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 11 Nov 2015 14:13:57 +0000
>> From: Euan Mee<euanmee at gmail.com>
>> To: cuis at jvuletich.org
>> Subject: [Cuis] Simple Morphic
>> Message-ID:
>>          <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> What is the current state of development of Simple Morph?
>>
>> Is there any documentation on how to use it, or is it allInTheCode ?
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 11 Nov 2015 08:13:58 -0800
>> From: KenD<Ken.Dickey at Whidbey.com>
>> To: Discussion of Cuis Smalltalk<cuis at jvuletich.org>
>> Cc: Euan Mee<euanmee at gmail.com>
>> Subject: Re: [Cuis] Simple Morphic
>> Message-ID:<20151111081358.4a0291315670cadcdcead39f at Whidbey.com>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> On Wed, 11 Nov 2015 14:13:57 +0000
>> Euan Mee<euanmee at gmail.com>  wrote:
>>
>>> What is the current state of development of Simple Morph?
>> I am not sure what you mean by Simple Morph.
>>
>> Cuis has been taking steps toward Morphic3:
>>
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>>
>> The MorphExtension class was removed.  (We have Morph Properties).
>>
>> Morphs have float rather than integer location coordinates.
>>
>> Morph location is relative to their owner, not the screen.
>>
>> These are relatively small changes to get used to.
>>
>> More radical are some of the other simplifications in the system.
>>
>> The best example here is probably Layout.
>>
>> LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.
>>
>> The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.
>>
>> See LayoutMorph class examples.
>>
>> If you git clone the Morphic-Misc1 package and load it you can get Layout editors:
>>
>> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>>
>>    git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>>
>> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:
>>
>>    Feature require:  'Morphic-Misc1'.
>>
>> Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>>
>> Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.
>>
>> If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.
>>
>>> Is there any documentation on how to use it, or is it allInTheCode ?
>> See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.
>>
>> --
>> -KenD
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>> ------------------------------
>>
>> End of Cuis Digest, Vol 41, Issue 14
>> ************************************
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Mon Nov 16 14:27:35 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 17:27:35 -0300
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <20151111155637.a6fc5a89ab8ca768aa93510a@Whidbey.com>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
	<20151111155637.a6fc5a89ab8ca768aa93510a@Whidbey.com>
Message-ID: <564A3C37.8050404@jvuletich.org>

On 11/11/2015 8:56 PM, KenD wrote:
> On Wed, 11 Nov 2015 19:02:54 +0000
> Euan Mee<euanmee at gmail.com>  wrote:
>
>> What is the state of development of Morphic3?
> Juan is working on an optimized MorphicCanvas to replace BitBltCanvas.
>
> There is some old, unoptimized sample code in Cuis-Smalltalk-Dev/Experimental which is not for the faint of heart.
>
> Cuis currently uses BitBltCanvas, so the graphics do not yet scale.
>
> Most of the other code works fine.  The location changes to Morph were a big step.
>
> Juan has been slimming down the Cuis image so that it should be possible to rapidly grow when scalable.  Slim down .. grow .. scale  ;^)
>
> Note the small number of classes in the base image:
> "2236 eToys 5.0"
> "2511 Squeak 4.4"
> "2175 Squeak 4.5"
> "2244 Squeak 5.0"
> "3226 Pharo 2.0"
> "4020 Pharo 3.0"
> "4924 Pharo 4.0"
>    vvv
> " 504 Cuis 4.2 (rev 2568)"
>    ^^^
>
> Juan, anything to add/correct here?

No :) All you say is right. Just that besides scaling, also rotation is 
missing in BitBltCanvas.

Cheers,
Juan Vuletich



From dnorton at mindspring.com  Mon Nov 16 16:30:49 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 16 Nov 2015 17:30:49 -0500
Subject: [Cuis] Patterns
In-Reply-To: <563CF147.306@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>,
	<563CF147.306@jvuletich.org>
Message-ID: <564A5919.15040.19C7009@dnorton.mindspring.com>

On 6 Nov 2015 at 15:28, Juan Vuletich wrote Re: [Cuis] ColorEditor updated:

> Hi Ken,
> 
> On 11/2/2015 8:27 PM, KenD wrote:
> > ...
> >
> > However, class comments are not usually where design patterns show
> up.  8^|
> >
> > In the case of #when:send:to: I suggest a slightly larger
> discussion around building paned windows which update dependent
> panes.
> >
> > What constitutes good style?  What code patterns help?
> >
> > Think "Useful Code Patterns" to augment "Useful Expressions".
> 
> In 2009 I wrote 
> http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgram
> ming.txt 
> and 
> http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.tx
> t . 
> I've had the idea of making all the GUI code in Cuis follow this
> style. 
> But time is always short...
> 

As one who benefits greatly from studying other people's code ;-) I favor copy and paste over 
reading prose. The most useful "Useful Code Patterns" would be something in a code 
window like "Useful Expressions" IMO. But where UE is code line oriented, it needs to be 
class and method orented.  It would be heavily commented as to what is on a line, or in a 
method, and why, because this is a big problem with Smalltalk in many cases. Once pasted, 
the comments would be customized or removed.

I started a package with a model and a view, trying to be minimalist about getting them to 
simply put up a window without bringing up the debugger. There are lots of comments. 
Please take a look and give me yours.

	https://github.com/dhnorton/Cuis-Smalltalk-patterns

It tries to be the most efficient, direct, and simple pattern for opening a view on a model in 
Cuis. It's deliberately not glitzy. Glitz is added by the user. Next, I plan to incorporate 
#when:send:to: fundamentals.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/4a178960/attachment-0003.html>

From luchiano at gmail.com  Mon Nov 16 16:46:58 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Mon, 16 Nov 2015 22:46:58 +0000
Subject: [Cuis] Patterns
In-Reply-To: <564A5919.15040.19C7009@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
Message-ID: <CAL5GDyqTYQd0TYrbS969W=WbGK_PCKQHmytud+PhG96aQs85QQ@mail.gmail.com>

Excelent, this exampe has exactly what I wanted yesterday. Models should
implement #open for instance creation. Also, all the different ways we are
currently using to open windows should be cleaned up and unified... but
I'll be happy with #open in every model at least (and always returning the
window).

Also Smalltalk|save, saveAs, quit.

I don't use menues much, I rather doIt ;)
Luciano

On Mon, Nov 16, 2015 at 10:30 PM, Dan Norton <dnorton at mindspring.com> wrote:

> On 6 Nov 2015 at 15:28, Juan Vuletich wrote Re: [Cuis] ColorEditor updated:
>
> > Hi Ken,
> >
> > On 11/2/2015 8:27 PM, KenD wrote:
> > > ...
> > >
> > > However, class comments are not usually where design patterns show
> > up.  8^|
> > >
> > > In the case of #when:send:to: I suggest a slightly larger
> > discussion around building paned windows which update dependent
> > panes.
> > >
> > > What constitutes good style?  What code patterns help?
> > >
> > > Think "Useful Code Patterns" to augment "Useful Expressions".
> >
> > In 2009 I wrote
> > http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgram
> > ming.txt
> > and
> > http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.tx
> > t .
> > I've had the idea of making all the GUI code in Cuis follow this
> > style.
> > But time is always short...
> >
>
> As one who benefits greatly from studying other people's code ;-) I favor
> copy and paste over reading prose. The most useful "Useful Code Patterns"
> would be something in a code window like "Useful Expressions" IMO. But
> where UE is code line oriented, it needs to be class and method orented.
> It would be heavily commented as to what is on a line, or in a method, and
> why, because this is a big problem with Smalltalk in many cases. Once
> pasted, the comments would be customized or removed.
>
> I started a package with a model and a view, trying to be minimalist about
> getting them to simply put up a window without bringing up the debugger.
> There are lots of comments. Please take a look and give me yours.
>
>            https://github.com/dhnorton/Cuis-Smalltalk-patterns
>
> It tries to be the most efficient, direct, and simple pattern for opening
> a view on a model in Cuis. It's deliberately not glitzy. Glitz is added by
> the user. Next, I plan to incorporate #when:send:to: fundamentals.
>
>  - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/d69918db/attachment-0003.html>

From juan at jvuletich.org  Mon Nov 16 18:11:51 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:11:51 -0300
Subject: [Cuis] #when:send:to:
In-Reply-To: <564624BE.15549.F1568C@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>
Message-ID: <564A70C7.4040005@jvuletich.org>

Hi Dan,

On 13/11/2015 02:58 p.m., Dan Norton wrote:
> Hello Everyone,
>
> The following repo contains before and after examples of replacing the Dependency
> Mechanism with the Observer Pattern:
>
> 	https://github.com/dhnorton/Cuis-Smalltalk-light
>
> Please take a look at this and tell me what needs to change. I'm trying to supply an example
> of the Observer Pattern so that others might use #when:send:to: with less difficulty than I
> experienced. There may be better examples but I picked one from the Blue Book.
>
> It seems that #when:send:to: is necessary but not sufficient as a replacement for the
> Dependency Mechanism. In this example, it replaced #addDependent:, not #changed or
> #update and I am still not comfortable with how to choose the parameters. This may be an
> example of the difficulty in explaining the obvious, I'm not sure :-)
>
> The #changed method was replaced with #triggerEvent: with a symbol argument which is
> referred to in one of the arguments of #when:send:to: and that's the only constraint AFAICT.
>
> The #update: method was retained, as a convenience; it also needs to agree with one of the
> arguments of #when:send:to: and could have been different.
>
> Please tell me if any of this is wrong. Thanks.
>
>   - Dan

I think the idea of #when:send:to: is to use event names and actions 
that make sense to your model (and not #changed and #update:). For 
instance, in Example2>>#lights:, I would change the line:

         eachLight when: #changed send: #update: to: dependentLight 
with: self

to read:

         eachLight when: #turnedOn send: #turnOff to: dependentLight

And, in #turnOn, make it do:

         self triggerEvent: #turnedOn


Doesn't this read better?

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Nov 16 18:42:22 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:42:22 -0300
Subject: [Cuis] New Introductory Tutorial
In-Reply-To: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
References: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
Message-ID: <564A77EE.6060802@jvuletich.org>

Hi EuanM,

This is a great initiative. Thanks for including Cuis in the bunch!

Cheers,
Juan Vuletich

On 14/11/2015 02:02 a.m., EuanM wrote:
> I've created Yet Another Smalltalk First
> Steps tutorial.
>
> This is intended as one of a series.
>
> It is designed to be cross-platform across
>
>      Squeak 5
>      Pharo 4
>      Seaside 3.1
>      Cuis
>      Dolphin 6
>
> If you have experience running any of these systems on Windows, Linux
> or MacOS, please check to see if I have the instructions correct for
> your chosen pairing of Smalltalk and OS platform.
>
> (As you'll see when you look, I do not have detailed instructions for
> aspects of MacOS).
>
> The document is at:
> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html
>
> (It's intended to move to a different blog after this review process).
>
> I feel the need to do this as cross-Smalltalks tutorial because of
> findings and 4 charts  I've placed at:
> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/mindshare-of-smalltalk-in-development.html
>
> Essentially, Smalltalk mindshare and use is incredibly tiny, compared
> to other languages in the same space.  (We all know this, but seeing
> it represented graphically has a more visceral effect, IMO)
>
> Aggregating interest in all the Smalltalks still does not bring more
> than a tiny proportion of the interest in, and use of, Ruby.
>
> In turn, Ruby is (quite understandably) small in comparison to JavaScript.
>
> Comparing interest in any specific Smalltalk is, predictably, smaller
> than the aggregate interest in Smalltalk.
>
> Our community seems determined to split itself into smaller and
> smaller sub-communities.  I think we do ourselves a disservice this
> way.
>
> My initial contribution will be to try to provide some explicitly
> pan-Smalltalk beginners' tutorials, like this one.
>
> Cheers, and happy Smalltalking,
>       EuanM
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Mon Nov 16 18:47:33 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:47:33 -0300
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
Message-ID: <564A7925.4060103@jvuletich.org>

On 14/11/2015 02:12 a.m., EuanM wrote:
> I've just recently put-together a cross-platform Installation Tutorial
> for beginners to Smalltalk.
>
> I was keen to include Cuis in the exercise.
>

Again, thank you for this.

> One thing that becomes clear in the comparison is that Cuis is a good
> beginner's environment from the point of view of size and complexity
> and their bearing in learnability.
>
> It is however, the worst Smalltalk (of the 4 in the tutorial) to get
> downloaded and installed.
>
> This seems a pity.

Please take a look at 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Documentation 
. There are three 'Getting Started' guides, for different OSes and user 
style / preferences. They were tried (as described) in Linux, MacOsX and 
Windows.

> Would anyone be willing to help me put together a One-Click Install
> package, similar to Squeak's and Pharo's?
>
> (My plan is to do the grunt-work, if other people are willing to
> indulge my noob questions while I do it)

I believe that if you take the One-Click for Squeak or Pharo, and 
replace the image with a Cuis image, it should work.

> Is there a particular place that it could be hosted, once ready?
>
> Would anyone disagree with a 6-monthly update cycle for the One-Click installer?
>
> (Frequent enough to send a signal to interested beginners that the
> project is alive and kicking.  Infrequent enough that there is not
> much work to be done)

Yep, this sounds great. The natural place is 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev isn't it?


> Cheers,
>     Euan

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Nov 16 18:51:30 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:51:30 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <1447515912161-4861043.post@n4.nabble.com>
References: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>	<563CF22E.4080804@jvuletich.org>	<etPan.563cf40e.77bd141b.a58@Unix.local>	<563CF53B.5000107@jvuletich.org>	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
	<1447515912161-4861043.post@n4.nabble.com>
Message-ID: <564A7A12.2070908@jvuletich.org>

Thank you! It was a pleasure to meet you all at the conference.

Cheers,
Juan Vuletich

On 14/11/2015 12:45 p.m., nacho wrote:
> I agree with Hari,
> It was very nice to meet you Juan.
> Thanks for your work and advice.
> Best
> Nacho
>
>
>
>
> -----
> Nacho
> Smalltalker apprentice.
> Buenos Aires, Argentina.



From juan at jvuletich.org  Mon Nov 16 18:53:33 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:53:33 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <BF8DA200-D5CF-424C-8168-F5568D5C2253@gmail.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>	<563CF22E.4080804@jvuletich.org>	<etPan.563cf40e.77bd141b.a58@Unix.local>	<563CF53B.5000107@jvuletich.org>	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
	<BF8DA200-D5CF-424C-8168-F5568D5C2253@gmail.com>
Message-ID: <564A7A8D.5000101@jvuletich.org>

Thank you too, Edgar. I know you made quite an effort to be there!

I don't think not having a plan is too bad. The important thing is to 
enjoy the experience!

And sure, we can talk any time.

Cheers,
Juan Vuletich

On 14/11/2015 06:29 p.m., Edgar De Cleene wrote:
> Also i say very, very thanks for all your talks, time to listening my 
> crazy ideas and tu calidez como ser humano
> Too bad also  i going without plan .
> We should schedule some hangouts when yo have the time.
> Wish know Nacho and Hari , look for me on Facebook and start  Cuis 
> Friendship
> Again thanks Juan.
>
>
>
>
>> On Nov 14, 2015, at 11:37 AM, Hari Balaraman 
>> <hari.balaraman at icloud.com <mailto:hari.balaraman at icloud.com>> wrote:
>>
>> Hi Juan,
>>
>> It was very nice to sit down and chat with you on the sidelines of 
>> the conference. Thank you for taking the time to look at my 
>> stuttering project and offer advice (on the history of projects, 
>> strangely, some others I talked to didn?t recognise the names Mark 
>> Guzdial and Bijan Parsia.) Although I missed first two days because 
>> of careless travel planning, I?m hoping FAST will put videos of the 
>> presentations on the website so I can catch up.
>>
>> The two people at Toronto Smalltalk Users Group I mentioned are Bob 
>> Nemec and Dave Mason, a professor at Ryerson University. My knowledge 
>> of the use of SmallTalk in the CS curriculum there is second or 
>> third-hand and so may not be current. I haven?t actually met them as 
>> the one Monday evening I was able to make it to TSUG, I was late and 
>> both of them had left by then. :)
>>
>> Thanks for the tip on visiting the bookshops on Avenida Corrientes in 
>> this amazing city. I passed it on the way home and realised I haven?t 
>> gone down this street in my wanderings. If you are going to be in the 
>> city before Tuesday afternoon, and are free and bored, do let me know.
>>
>> Best regards,
>>
>> Hari
>>>>
>>>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich 
>>>> (juan at jvuletich.org <mailto:juan at jvuletich.org>) wrote:
>>>>
>>>>> Hi Hari,
>>>>>
>>>>> I'll be there. Let's meet then.
>>>>>
>>>>> Anybody else?
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>>>> If any of you are attending the FAST conference in Buenos Aires 
>>>>>> in a week or so, I look forward to meeting you face to face.
>>>>>> Best regards,
>>>>>> Hari
>>>>>>
>>>>>> _______________________________________________
>>>>>> Cuis mailing list
>>>>>> Cuis at jvuletich.org
>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/4eea6045/attachment-0003.html>

From juan at jvuletich.org  Mon Nov 16 19:06:25 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 22:06:25 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564A5919.15040.19C7009@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>,
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
Message-ID: <564A7D91.6080102@jvuletich.org>

Hi Dan,

On 16/11/2015 07:30 p.m., Dan Norton wrote:
>
> As one who benefits greatly from studying other people's code ;-) I 
> favor copy and paste over reading prose. The most useful "Useful Code 
> Patterns" would be something in a code window like "Useful 
> Expressions" IMO. But where UE is code line oriented, it needs to be 
> class and method orented.  It would be heavily commented as to what is 
> on a line, or in a method, and why, because this is a big problem with 
> Smalltalk in many cases. Once pasted, the comments would be customized 
> or removed.

Ok, it is a good idea.

> I started a package with a model and a view, trying to be minimalist 
> about getting them to simply put up a window without bringing up the 
> debugger. There are lots of comments. Please take a look and give me 
> yours.
>
>            https://github.com/dhnorton/Cuis-Smalltalk-patterns
>
> It tries to be the most efficient, direct, and simple pattern for 
> opening a view on a model in Cuis. It's deliberately not glitzy. Glitz 
> is added by the user. Next, I plan to incorporate #when:send:to: 
> fundamentals.
>
>  - Dan

Well, I don't like the #open method in the model. The idea of View / 
Model separation is that views know about models, but models don't know 
about views. A Model should exist independently of being used from 
Morphic, MVC, Seaside, or any other UI framework. It could live, for 
example, in a Gemstone database with no UI at all. Or ir could travel to 
and from other systems, like VA Smalltalk, where the UI framework is 
completely different from Cuis'.

I think it is better for the View to start it all.

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/87361800/attachment-0003.html>

From garduino at gmail.com  Mon Nov 16 19:47:43 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Mon, 16 Nov 2015 22:47:43 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564A7D91.6080102@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
Message-ID: <CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>

2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org>:

>
> Well, I don't like the #open method in the model. The idea of View / Model
> separation is that views know about models, but models don't know about
> views. A Model should exist independently of being used from Morphic, MVC,
> Seaside, or any other UI framework. It could live, for example, in a
> Gemstone database with no UI at all. Or ir could travel to and from other
> systems, like VA Smalltalk, where the UI framework is completely different
> from Cuis'.
>
>
Interesting, really I never heard of the use of  #open at the model or I do
not remember it at all, but I think similar to Juan.



> I think it is better for the View to start it all.
>
>
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/f563d169/attachment-0003.html>

From dnorton at mindspring.com  Mon Nov 16 19:50:30 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 16 Nov 2015 20:50:30 -0500
Subject: [Cuis] #when:send:to:
In-Reply-To: <564A70C7.4040005@jvuletich.org>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<564A70C7.4040005@jvuletich.org>
Message-ID: <564A87E6.28858.2533F1E@dnorton.mindspring.com>

On 16 Nov 2015 at 21:11, Juan Vuletich wrote:

> Hi Dan,
> 
> On 13/11/2015 02:58 p.m., Dan Norton wrote:
> > Hello Everyone,
> >
> > The following repo contains before and after examples of replacing
> the Dependency
> > Mechanism with the Observer Pattern:
> >
> > 	https://github.com/dhnorton/Cuis-Smalltalk-light
> >
> > Please take a look at this and tell me what needs to change. I'm
> trying to supply an example
> > of the Observer Pattern so that others might use #when:send:to:
> with less difficulty than I
> > experienced. There may be better examples but I picked one from
> the Blue Book.
> >
> > It seems that #when:send:to: is necessary but not sufficient as a
> replacement for the
> > Dependency Mechanism. In this example, it replaced #addDependent:,
> not #changed or
> > #update and I am still not comfortable with how to choose the
> parameters. This may be an
> > example of the difficulty in explaining the obvious, I'm not sure
> :-)
> >
> > The #changed method was replaced with #triggerEvent: with a symbol
> argument which is
> > referred to in one of the arguments of #when:send:to: and that's
> the only constraint AFAICT.
> >
> > The #update: method was retained, as a convenience; it also needs
> to agree with one of the
> > arguments of #when:send:to: and could have been different.
> >
> > Please tell me if any of this is wrong. Thanks.
> >
> >   - Dan
> 
> I think the idea of #when:send:to: is to use event names and actions
> that make sense to your model (and not #changed and #update:). For
> instance, in Example2>>#lights:, I would change the line:
> 
>          eachLight when: #changed send: #update: to: dependentLight
> with: self
> 
> to read:
> 
>          eachLight when: #turnedOn send: #turnOff to:
> dependentLight
> 
> And, in #turnOn, make it do:
> 
>          self triggerEvent: #turnedOn
> 
> 
> Doesn't this read better?
> 

+2
...because yes, it reads better, but there's more:

	#when:send:to: replaces #when:send:to:with:

	in Light2, #update: goes away, with a little factoring

The #triggerEvent: arg is changed to #turnedOn. This is elegant.

 - Dan



From juan at jvuletich.org  Mon Nov 16 19:52:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 22:52:01 -0300
Subject: [Cuis] #when:send:to:
In-Reply-To: <564A87E6.28858.2533F1E@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<564A70C7.4040005@jvuletich.org>
	<564A87E6.28858.2533F1E@dnorton.mindspring.com>
Message-ID: <564A8841.7070708@jvuletich.org>

On 16/11/2015 10:50 p.m., Dan Norton wrote:
> On 16 Nov 2015 at 21:11, Juan Vuletich wrote:
>
>> Hi Dan,
>>
>> On 13/11/2015 02:58 p.m., Dan Norton wrote:
>>> Hello Everyone,
>>>
>>> The following repo contains before and after examples of replacing
>> the Dependency
>>> Mechanism with the Observer Pattern:
>>>
>>> 	https://github.com/dhnorton/Cuis-Smalltalk-light
>>>
>>> Please take a look at this and tell me what needs to change. I'm
>> trying to supply an example
>>> of the Observer Pattern so that others might use #when:send:to:
>> with less difficulty than I
>>> experienced. There may be better examples but I picked one from
>> the Blue Book.
>>> It seems that #when:send:to: is necessary but not sufficient as a
>> replacement for the
>>> Dependency Mechanism. In this example, it replaced #addDependent:,
>> not #changed or
>>> #update and I am still not comfortable with how to choose the
>> parameters. This may be an
>>> example of the difficulty in explaining the obvious, I'm not sure
>> :-)
>>> The #changed method was replaced with #triggerEvent: with a symbol
>> argument which is
>>> referred to in one of the arguments of #when:send:to: and that's
>> the only constraint AFAICT.
>>> The #update: method was retained, as a convenience; it also needs
>> to agree with one of the
>>> arguments of #when:send:to: and could have been different.
>>>
>>> Please tell me if any of this is wrong. Thanks.
>>>
>>>    - Dan
>> I think the idea of #when:send:to: is to use event names and actions
>> that make sense to your model (and not #changed and #update:). For
>> instance, in Example2>>#lights:, I would change the line:
>>
>>           eachLight when: #changed send: #update: to: dependentLight
>> with: self
>>
>> to read:
>>
>>           eachLight when: #turnedOn send: #turnOff to:
>> dependentLight
>>
>> And, in #turnOn, make it do:
>>
>>           self triggerEvent: #turnedOn
>>
>>
>> Doesn't this read better?
>>
> +2
> ...because yes, it reads better, but there's more:
>
> 	#when:send:to: replaces #when:send:to:with:
>
> 	in Light2, #update: goes away, with a little factoring
>
> The #triggerEvent: arg is changed to #turnedOn. This is elegant.
>
>   - Dan
>

Yes! And this way, 'senders' and 'implementors' take you right to the spot.

Cheers,
Juan Vuletich

> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From thierry.goubier at gmail.com  Mon Nov 16 22:42:37 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 05:42:37 +0100
Subject: [Cuis] Patterns
In-Reply-To: <CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
Message-ID: <564AB03D.1040405@gmail.com>

Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
>
>
> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
> <mailto:juan at jvuletich.org>>:
>
>     __
>
>     Well, I don't like the #open method in the model. The idea of View /
>     Model separation is that views know about models, but models don't
>     know about views. A Model should exist independently of being used
>     from Morphic, MVC, Seaside, or any other UI framework. It could
>     live, for example, in a Gemstone database with no UI at all. Or ir
>     could travel to and from other systems, like VA Smalltalk, where the
>     UI framework is completely different from Cuis'.
>
>
> Interesting, really I never heard of the use of  #open at the model or I
> do not remember it at all, but I think similar to Juan.

Hum, #open has to go somewhere, so...

Either it goes into a sort of Application Model, which regroup the 
duties associated with the application (the view + model + whatever is 
necessary in environment X), or it goes into an Application View which 
then has model concerns in it (it knows how to start or connect to the 
model, it knows what the model is composed of to connect subviews to 
model elements, etc...).

>     I think it is better for the View to start it all.
>
>
> +1

I prefer to model an Application concept in the target desktop 
environment if I want to model highly portable stuff.

That application concern can be folded into a dedicated view if that is 
the preferred convention in the target environment.

Regards,

Thierry

>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From thierry.goubier at gmail.com  Mon Nov 16 22:44:52 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 05:44:52 +0100
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <564A3BCE.9090409@jvuletich.org>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
	<564A3BCE.9090409@jvuletich.org>
Message-ID: <564AB0C4.7000906@gmail.com>

Hi Juan, Euan,

thanks for the update on Morphic3. I'll have a look one of these days, 
when I'll have something interesting to show running on Cuis.

Regards,

Thierry

Le 16/11/2015 21:25, Juan Vuletich a ?crit :
> Hi Euan,
>
> On 11/11/2015 4:02 PM, Euan Mee wrote:
>> Thanks for the pointer to Morphic3 and its documentation.  I'll try to
>> contribute more naive-user questions :-)
>>
>> What is the state of development of Morphic3?
>>    - complete stable codebase?
>>    - stable codebase for substantial parts, with fuurther extensions in
>> development?
>>    - central aspects still under development?
>>    - a design concept, coding yet to begin?
>
> I think "central aspects still under development" is a fair way to say it.
> If you want to take a look, it is in the 'Experimental' folder. Feel
> free to ask questions.
>
>> e.g. The documentation starts off with "Morphic3 *will have* scalable
>> graphics".  This might mean that Morphic3 works now, but does not yet
>> have scalable graphics.  Or it might just mean Morphic3 does not (yet)
>> work.
>>
>
> Well, we have been evolving Morphic in Cuis, towards the direction shown
> by some experiments I did in 2009, for quite some time. This is
> currently using BitBltCanvas to draw, that can not do proper scalable
> graphics. The Morphic3Canvas in 'Experimental' can do this.
>
>> Generally, whenever I'm looking at a new platform, system, or package,
>> I am initially looking for answers of the type
>>     "Can I use it now?
>>          No /
>>          Yes /
>>          Yes to an extent, but..."
>>
>> I'm very happy to write up aspects of the system/package as
>> fully-formed documentation, especially documentation for naive-users.
>> Please let me know if there specific places where this help is
>> already-known to be particularly needed.
>
> Morphic 3 is ready to be studied by really interested ones. Not at all
> ready for a naive- user. On the question of where this help is needed,
> I'm not the best to answer. Maybe others in the community answer this,
> or, just use the system for some project, and you'll quickly find the
> places where a new user (you!) could use better documentation.
>
>> I look forward (in the long run?) to trying Cuis and Morphic3 on
>> Raspberry Pi.
>>
>
> Well, Morphic 3 might be more expensive than BitBltCanvas, and I don't
> know if it will run reasonably well on a Pi....
>
> Cheers,
> Juan Vuletich
>
>> On 11 November 2015 at 18:00,<cuis-request at jvuletich.org>  wrote:
>>> Send Cuis mailing list submissions to
>>>          cuis at jvuletich.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>          http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>> or, via email, send a message with subject or body 'help' to
>>>          cuis-request at jvuletich.org
>>>
>>> You can reach the person managing the list at
>>>          cuis-owner at jvuletich.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Cuis digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>     1. Simple Morphic (Euan Mee)
>>>     2. Re: Simple Morphic (KenD)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Wed, 11 Nov 2015 14:13:57 +0000
>>> From: Euan Mee<euanmee at gmail.com>
>>> To: cuis at jvuletich.org
>>> Subject: [Cuis] Simple Morphic
>>> Message-ID:
>>>
>>> <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w at mail.gmail.com>
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> What is the current state of development of Simple Morph?
>>>
>>> Is there any documentation on how to use it, or is it allInTheCode ?
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Wed, 11 Nov 2015 08:13:58 -0800
>>> From: KenD<Ken.Dickey at Whidbey.com>
>>> To: Discussion of Cuis Smalltalk<cuis at jvuletich.org>
>>> Cc: Euan Mee<euanmee at gmail.com>
>>> Subject: Re: [Cuis] Simple Morphic
>>> Message-ID:<20151111081358.4a0291315670cadcdcead39f at Whidbey.com>
>>> Content-Type: text/plain; charset=US-ASCII
>>>
>>> On Wed, 11 Nov 2015 14:13:57 +0000
>>> Euan Mee<euanmee at gmail.com>  wrote:
>>>
>>>> What is the current state of development of Simple Morph?
>>> I am not sure what you mean by Simple Morph.
>>>
>>> Cuis has been taking steps toward Morphic3:
>>>
>>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>>>
>>>
>>> The MorphExtension class was removed.  (We have Morph Properties).
>>>
>>> Morphs have float rather than integer location coordinates.
>>>
>>> Morph location is relative to their owner, not the screen.
>>>
>>> These are relatively small changes to get used to.
>>>
>>> More radical are some of the other simplifications in the system.
>>>
>>> The best example here is probably Layout.
>>>
>>> LayoutMorphs do just that for their submorphs.  A LayoutSpec is
>>> attached to individual Morphs to tell their container how they want
>>> to be layed out.  See the class comments.
>>>
>>> The code in LayoutMorph is much smaller (see
>>> LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding
>>> layout code in Squeak or Pharo.
>>>
>>> See LayoutMorph class examples.
>>>
>>> If you git clone the Morphic-Misc1 package and load it you can get
>>> Layout editors:
>>>
>>> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>>>
>>>    git clone
>>> https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>>>
>>> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to
>>> require the package:
>>>
>>>    Feature require:  'Morphic-Misc1'.
>>>
>>> Then use the LayoutMorph class examples, select (sub) morphs, open a
>>> LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>>>
>>> Note that these editors are "one-shot" and will close after setting
>>> or cancelling, so click on the "push pin" in the upper right corner
>>> to keep them open.
>>>
>>> If you have several editors open, you can use the "Show Halo" button
>>> to see which Morph an editor is adjusting.
>>>
>>>> Is there any documentation on how to use it, or is it allInTheCode ?
>>> See the above URL and continue to ask questions.  We need to make the
>>> documentation better over time and questions are very helpful here.
>>>
>>> --
>>> -KenD
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>>
>>> ------------------------------
>>>
>>> End of Cuis Digest, Vol 41, Issue 14
>>> ************************************
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From luchiano at gmail.com  Tue Nov 17 01:13:52 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Tue, 17 Nov 2015 07:13:52 +0000
Subject: [Cuis] dynamic window manager
Message-ID: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>

I've been using dwm.suckless.org for 10 years and I just had to have it in
Cuis. So, that's what I've been doing the last two days, and I had to do
some minor changes to the core in order to allow this level of
customization. In case there's some other tiling maniac like me who wants
to give it a try... although it's still a little rough, I'll be improving
it as I go by using it everyday :) Not sure it will work out-of-the-box
yet, I've done some changes that are not included in the package (like some
preferences and monospaced font)

https://github.com/len/Cuis-Smalltalk-DWM

Cheers,
Luciano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/57cf707d/attachment-0003.html>

From 0800nacho at gmail.com  Tue Nov 17 03:46:54 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Tue, 17 Nov 2015 06:46:54 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
Message-ID: <CAMCzT-arkx7dkmw1vNWGCXBTvTO4DbJ9eVFsqqDM-5fC0W9MpA@mail.gmail.com>

Great to hear you use suckless.
Do you use dwm or another WM?
For the past 2 years I been using i3, I'm very happy with it.
abrazo
Nacho


*Lic. Ignacio Sniechowski, MBA*
*Prosavic SRL*

*Tel: (011) 4542-6714*


















On Tue, Nov 17, 2015 at 4:13 AM, Luciano Notarfrancesco <luchiano at gmail.com>
wrote:

> I've been using dwm.suckless.org for 10 years and I just had to have it
> in Cuis. So, that's what I've been doing the last two days, and I had to do
> some minor changes to the core in order to allow this level of
> customization. In case there's some other tiling maniac like me who wants
> to give it a try... although it's still a little rough, I'll be improving
> it as I go by using it everyday :) Not sure it will work out-of-the-box
> yet, I've done some changes that are not included in the package (like some
> preferences and monospaced font)
>
> https://github.com/len/Cuis-Smalltalk-DWM
>
> Cheers,
> Luciano
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/e12d67bb/attachment-0003.html>

From juan at jvuletich.org  Tue Nov 17 08:00:21 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 17 Nov 2015 11:00:21 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564AB03D.1040405@gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>	<563CF147.306@jvuletich.org>	<564A5919.15040.19C7009@dnorton.mindspring.com>	<564A7D91.6080102@jvuletich.org>	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com>
Message-ID: <564B32F5.9050102@jvuletich.org>

Hi Thierry,


On 11/17/2015 1:42 AM, Thierry Goubier wrote:
> Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
>>
>>
>> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
>> <mailto:juan at jvuletich.org>>:
>>
>>     __
>>
>>     Well, I don't like the #open method in the model. The idea of View /
>>     Model separation is that views know about models, but models don't
>>     know about views. A Model should exist independently of being used
>>     from Morphic, MVC, Seaside, or any other UI framework. It could
>>     live, for example, in a Gemstone database with no UI at all. Or ir
>>     could travel to and from other systems, like VA Smalltalk, where the
>>     UI framework is completely different from Cuis'.
>>
>>
>> Interesting, really I never heard of the use of  #open at the model or I
>> do not remember it at all, but I think similar to Juan.
>
> Hum, #open has to go somewhere, so...
>
> Either it goes into a sort of Application Model, which regroup the 
> duties associated with the application (the view + model + whatever is 
> necessary in environment X), or it goes into an Application View which 
> then has model concerns in it (it knows how to start or connect to the 
> model, it knows what the model is composed of to connect subviews to 
> model elements, etc...).
>

The idea of view / model separation is pretty well explained in "Inside 
Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.

I agree that an Application object or such might make sense when you are 
building an application, especially if you need to deal with en external 
environment. But here we were talking about whether the Model classes 
should know about Morphs or not.

>>     I think it is better for the View to start it all.
>>
>>
>> +1
>
> I prefer to model an Application concept in the target desktop 
> environment if I want to model highly portable stuff.
>
> That application concern can be folded into a dedicated view if that 
> is the preferred convention in the target environment.
>
> Regards,
>
> Thierry

I wonder how would this result in practice. Do you have some examples to 
share?

Cheers,
Juan Vuletich



From thierry.goubier at gmail.com  Tue Nov 17 08:32:16 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 15:32:16 +0100
Subject: [Cuis] Fwd:  Patterns
In-Reply-To: <CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
Message-ID: <CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>

2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:

> Hi Thierry,
>
>
> On 11/17/2015 1:42 AM, Thierry Goubier wrote:
>
>> Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
>>
>>>
>>>
>>> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
>>> <mailto:juan at jvuletich.org>>:
>>>
>>>     __
>>>
>>>     Well, I don't like the #open method in the model. The idea of View /
>>>     Model separation is that views know about models, but models don't
>>>     know about views. A Model should exist independently of being used
>>>     from Morphic, MVC, Seaside, or any other UI framework. It could
>>>     live, for example, in a Gemstone database with no UI at all. Or ir
>>>     could travel to and from other systems, like VA Smalltalk, where the
>>>     UI framework is completely different from Cuis'.
>>>
>>>
>>> Interesting, really I never heard of the use of  #open at the model or I
>>> do not remember it at all, but I think similar to Juan.
>>>
>>
>> Hum, #open has to go somewhere, so...
>>
>> Either it goes into a sort of Application Model, which regroup the duties
>> associated with the application (the view + model + whatever is necessary
>> in environment X), or it goes into an Application View which then has model
>> concerns in it (it knows how to start or connect to the model, it knows
>> what the model is composed of to connect subviews to model elements,
>> etc...).
>>
>>
> The idea of view / model separation is pretty well explained in "Inside
> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>

Sadly, that view / model separation encounters pragmatic issues  when
dealing with things more complex than standard widgets, such as your
typical domain drawing editor. This is the fundamental reason for me to
consider that Morphic departed from that model, and that the pinacle of
that M / V separation is the M2VC of VisualWorks.

Newer models in the literature around those years such as PAC proposed
better abstractions, but they were never implemented.

Now, it's interesting to see you advocate that model on top of Morphic.


> I agree that an Application object or such might make sense when you are
> building an application, especially if you need to deal with en external
> environment. But here we were talking about whether the Model classes
> should know about Morphs or not.


In theory, no.

In practice, if you want a well tuned gui, I consider that yes, they need
to be aware of them.

So the most elegant way I've used is the two models: a pure, abstract
model, totally view independent. And a pragmatic, closer to the view /
aware of the view, application model as an mediator.


>
>
>     I think it is better for the View to start it all.
>>>
>>>
>>> +1
>>>
>>
>> I prefer to model an Application concept in the target desktop
>> environment if I want to model highly portable stuff.
>>
>> That application concern can be folded into a dedicated view if that is
>> the preferred convention in the target environment.
>>
>> Regards,
>>
>> Thierry
>>
>
> I wonder how would this result in practice. Do you have some examples to
> share?
>

I have a complex example, a system browser, would that fit?

Regards,

Thierry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/57a1be52/attachment-0003.html>

From juan at jvuletich.org  Tue Nov 17 09:16:07 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 17 Nov 2015 12:16:07 -0300
Subject: [Cuis] Fwd:  Patterns
In-Reply-To: <CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>	<563CF147.306@jvuletich.org>	<564A5919.15040.19C7009@dnorton.mindspring.com>	<564A7D91.6080102@jvuletich.org>	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>	<564AB03D.1040405@gmail.com>
	<564B32F5.9050102@jvuletich.org>	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
Message-ID: <564B44B7.2070809@jvuletich.org>

Hi Thierry,

On 11/17/2015 11:32 AM, Thierry Goubier wrote:
>
> 2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>>:
>
>     ...
>
>     The idea of view / model separation is pretty well explained in
>     "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>
>
> Sadly, that view / model separation encounters pragmatic issues  when 
> dealing with things more complex than standard widgets, such as your 
> typical domain drawing editor.

This is the first time I hear this. Can you elaborate or provide 
references? I worked on several mid-size to large projects that did 
strict view / model separation, and I never saw "pragmatic issues" (that 
couldn't be solved by a good design).

> This is the fundamental reason for me to consider that Morphic 
> departed from that model, and that the pinacle of that M / V 
> separation is the M2VC of VisualWorks.

PluggableMorphs attempted to follow this model (and give model 
compatibility between Morphic and MVC). Etoys (if I remember correctly) 
do the same, only that calling the model a "Player" and the view a 
"Costume". Later, people forgot about view / model separation, and 
Squeak became legacy software, in part because of that.

> Newer models in the literature around those years such as PAC proposed 
> better abstractions, but they were never implemented.
> Now, it's interesting to see you advocate that model on top of Morphic.
>
>
>     I agree that an Application object or such might make sense when
>     you are building an application, especially if you need to deal
>     with en external environment. But here we were talking about
>     whether the Model classes should know about Morphs or not.
>
>
> In theory, no.
>
> In practice, if you want a well tuned gui, I consider that yes, they 
> need to be aware of them.

Please elaborate, or provide references.

> So the most elegant way I've used is the two models: a pure, abstract 
> model, totally view independent. And a pragmatic, closer to the view / 
> aware of the view, application model as an mediator.
>
>
>
>                 I think it is better for the View to start it all.
>
>
>             +1
>
>
>         I prefer to model an Application concept in the target desktop
>         environment if I want to model highly portable stuff.
>
>         That application concern can be folded into a dedicated view
>         if that is the preferred convention in the target environment.
>
>         Regards,
>
>         Thierry
>
>
>     I wonder how would this result in practice. Do you have some
>     examples to share?
>
>
> I have a complex example, a system browser, would that fit?

Sure.

> Regards,
>
> Thierry
>

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/38ab5247/attachment-0003.html>

From garduino at gmail.com  Tue Nov 17 09:57:05 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Tue, 17 Nov 2015 12:57:05 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
Message-ID: <CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>

Awesome!!

Saludos / Regards,
Germ?n Arduino
@garduino


2015-11-17 4:13 GMT-03:00 Luciano Notarfrancesco <luchiano at gmail.com>:

> I've been using dwm.suckless.org for 10 years and I just had to have it
> in Cuis. So, that's what I've been doing the last two days, and I had to do
> some minor changes to the core in order to allow this level of
> customization. In case there's some other tiling maniac like me who wants
> to give it a try... although it's still a little rough, I'll be improving
> it as I go by using it everyday :) Not sure it will work out-of-the-box
> yet, I've done some changes that are not included in the package (like some
> preferences and monospaced font)
>
> https://github.com/len/Cuis-Smalltalk-DWM
>
> Cheers,
> Luciano
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/b2136b82/attachment-0003.html>

From luchiano at gmail.com  Tue Nov 17 10:35:40 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Tue, 17 Nov 2015 16:35:40 +0000
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAMCzT-arkx7dkmw1vNWGCXBTvTO4DbJ9eVFsqqDM-5fC0W9MpA@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
	<CAMCzT-arkx7dkmw1vNWGCXBTvTO4DbJ9eVFsqqDM-5fC0W9MpA@mail.gmail.com>
Message-ID: <CAL5GDyrGy=1rQctf4oBE_XLPF_yK_32yXGmsborH_4J5H7dqcA@mail.gmail.com>

Yeah, I use dwm, I tried several tiling window managers and I ended up with
my customized version of dwm. I use it "nested", I have a minimalist host
that barely can run dwm and the command-line virtualbox, and then many
small virtual machines that run a slightly different version of dwm for
different tasks, color-coded, etc... like a form of compartmentalization...
haha

I'm not sure this tiling and text-oriented thing is useful for coding
Smalltalk... I'll see... I always enjoyed experimenting with alternatives
to the classic overlapping-windows and menus and icons paradigm.

Cheers,
Luciano

On Tue, Nov 17, 2015 at 9:46 AM, Ignacio Sniechowski <0800nacho at gmail.com>
wrote:

> Great to hear you use suckless.
> Do you use dwm or another WM?
> For the past 2 years I been using i3, I'm very happy with it.
> abrazo
> Nacho
>
>
> *Lic. Ignacio Sniechowski, MBA*
> *Prosavic SRL*
>
> *Tel: (011) 4542-6714*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Nov 17, 2015 at 4:13 AM, Luciano Notarfrancesco <
> luchiano at gmail.com> wrote:
>
>> I've been using dwm.suckless.org for 10 years and I just had to have it
>> in Cuis. So, that's what I've been doing the last two days, and I had to do
>> some minor changes to the core in order to allow this level of
>> customization. In case there's some other tiling maniac like me who wants
>> to give it a try... although it's still a little rough, I'll be improving
>> it as I go by using it everyday :) Not sure it will work out-of-the-box
>> yet, I've done some changes that are not included in the package (like some
>> preferences and monospaced font)
>>
>> https://github.com/len/Cuis-Smalltalk-DWM
>>
>> Cheers,
>> Luciano
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/536c1256/attachment-0003.html>

From thierry.goubier at gmail.com  Tue Nov 17 10:51:47 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 17:51:47 +0100
Subject: [Cuis] Fwd:  Fwd: Patterns
In-Reply-To: <CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
	<564B44B7.2070809@jvuletich.org>
	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
Message-ID: <CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>

Hi Juan,

2015-11-17 16:16 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:

> Hi Thierry,
>
> On 11/17/2015 11:32 AM, Thierry Goubier wrote:
>
>
> 2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:
>
>> ...
>>
>> The idea of view / model separation is pretty well explained in "Inside
>> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>>
>
> Sadly, that view / model separation encounters pragmatic issues  when
> dealing with things more complex than standard widgets, such as your
> typical domain drawing editor.
>
>
> This is the first time I hear this. Can you elaborate or provide
> references? I worked on several mid-size to large projects that did strict
> view / model separation, and I never saw "pragmatic issues" (that couldn't
> be solved by a good design).
>

I would give HotDraw, and some of the original design pattern work on
editors, especially the parts derived from the InterViews toolkit.

Now, I used to be pretty up to date on the literature and some of the
criticism of the MVC model (especially the division between V and C) but my
memory of that time is all fuzzy.

> This is the fundamental reason for me to consider that Morphic departed
> from that model, and that the pinacle of that M / V separation is the M2VC
> of VisualWorks.
>
>
> PluggableMorphs attempted to follow this model (and give model
> compatibility between Morphic and MVC). Etoys (if I remember correctly) do
> the same, only that calling the model a "Player" and the view a "Costume".
> Later, people forgot about view / model separation, and Squeak became
> legacy software, in part because of that.
>

Maybe. I'm not sure of that particular factor. I have the feeling that
there is no clear and honest analysis on the state of GUI toolkits in that
universe, for present and future ones.


> Newer models in the literature around those years such as PAC proposed
> better abstractions, but they were never implemented.
> Now, it's interesting to see you advocate that model on top of Morphic.
>
>
>> I agree that an Application object or such might make sense when you are
>> building an application, especially if you need to deal with en external
>> environment. But here we were talking about whether the Model classes
>> should know about Morphs or not.
>
>
> In theory, no.
>
> In practice, if you want a well tuned gui, I consider that yes, they need
> to be aware of them.
>
>
> Please elaborate, or provide references.
>

What would you think of a drag and drop feedback which is dependent of the
type of the model elements?


>
>
> So the most elegant way I've used is the two models: a pure, abstract
> model, totally view independent. And a pragmatic, closer to the view /
> aware of the view, application model as an mediator.
>
>
>>
>>
>>     I think it is better for the View to start it all.
>>>>
>>>>
>>>> +1
>>>>
>>>
>>> I prefer to model an Application concept in the target desktop
>>> environment if I want to model highly portable stuff.
>>>
>>> That application concern can be folded into a dedicated view if that is
>>> the preferred convention in the target environment.
>>>
>>> Regards,
>>>
>>> Thierry
>>>
>>
>> I wonder how would this result in practice. Do you have some examples to
>> share?
>>
>
> I have a complex example, a system browser, would that fit?
>
>
> Sure.
>

Well, a short estimate on that particular application is that, linked with
the pluggable morphs, 10 to 20% of the code in the application model is:
- widget creation, setup, layout
- dynamic morph addition / removal when activating certain functions on the
model
- workarounds the pluggable morphs api to:
  - dynamically refresh parts of the inside of widgets
  - disconnect then reconnect links between widgets so that the
model-triggered update of one does not change the state of the other one
(i.e. protect the model from unwanted view triggered updates when the model
is changing part of its contents).

This application model uses mainly two widgets.

I do have a long term plan to port that to Cuis, and I expect I will have
to write that very same code somewhere (maybe more, maybe less).

Regards,

Thierry


>
> Regards,
>
> Thierry
>
>
> Cheers,
> Juan Vuletich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/fbfd618b/attachment-0003.html>

From luchiano at gmail.com  Tue Nov 17 11:14:29 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Tue, 17 Nov 2015 17:14:29 +0000
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
	<CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>
Message-ID: <CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>

On Tue, Nov 17, 2015 at 3:57 PM, Germ?n Arduino <garduino at gmail.com> wrote:

> Awesome!!
>

Haha, awesome is another window manager, it was also a fork of dwm, I used
it for a while ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/b007e699/attachment-0003.html>

From juan at jvuletich.org  Tue Nov 17 11:36:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 17 Nov 2015 14:36:34 -0300
Subject: [Cuis] Fwd:  Fwd: Patterns
In-Reply-To: <CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>	<563CF147.306@jvuletich.org>	<564A5919.15040.19C7009@dnorton.mindspring.com>	<564A7D91.6080102@jvuletich.org>	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>	<564AB03D.1040405@gmail.com>
	<564B32F5.9050102@jvuletich.org>	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>	<564B44B7.2070809@jvuletich.org>	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
	<CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
Message-ID: <564B65A2.3050604@jvuletich.org>

Hi Thierry,

On 11/17/2015 1:51 PM, Thierry Goubier wrote:
> Hi Juan,
>
> 2015-11-17 16:16 GMT+01:00 Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>>:
>
>     Hi Thierry,
>
>     On 11/17/2015 11:32 AM, Thierry Goubier wrote:
>>
>>     2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org
>>     <mailto:juan at jvuletich.org>>:
>>
>>         ...
>>
>>         The idea of view / model separation is pretty well explained
>>         in "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>>
>>
>>     Sadly, that view / model separation encounters pragmatic issues
>>      when dealing with things more complex than standard widgets,
>>     such as your typical domain drawing editor.
>
>     This is the first time I hear this. Can you elaborate or provide
>     references? I worked on several mid-size to large projects that
>     did strict view / model separation, and I never saw "pragmatic
>     issues" (that couldn't be solved by a good design).
>
>
> I would give HotDraw, and some of the original design pattern work on 
> editors, especially the parts derived from the InterViews toolkit.

Uh, it is not easy to find stuff about that, so I can't really comment.

> Now, I used to be pretty up to date on the literature and some of the 
> criticism of the MVC model (especially the division between V and C) 
> but my memory of that time is all fuzzy.

Well, in my opinion View / Model separation is a great property of the 
design of an application. Controller is more of a requirement of the 
ST-80 MVC framework. In principle, I see no problem in merging 
Controller into View. But, in Cuis, it can be argued that the Editor 
hierarchy is essentially a hierarchy of Controllers, and that's ok if 
the decomposition of responsibilities makes sense.

In View / Model separation there are two restrictions that need to be 
honored:
- The Model doesn't know about the possible Views. This means, for 
instance, that it could provide all its services, and exercise all its 
functionality, even if the GUI framework is completely absent. Model 
code should never fail because of this. This is great for moving models 
from and two different runtimes (client, server, gemstone, various 
dialects, etc) and also for writing tests.
- Model behavior should not leak into Views. This means that if the 
views are removed (maybe to be replaced by some others, in the same or 
in another framework), Model should not lose state nor behavior. Model 
must be complete by itself.
So, the idea is essentially to protect the integrity and consistency of 
Models.

>>     This is the fundamental reason for me to consider that Morphic
>>     departed from that model, and that the pinacle of that M / V
>>     separation is the M2VC of VisualWorks.
>
>     PluggableMorphs attempted to follow this model (and give model
>     compatibility between Morphic and MVC). Etoys (if I remember
>     correctly) do the same, only that calling the model a "Player" and
>     the view a "Costume". Later, people forgot about view / model
>     separation, and Squeak became legacy software, in part because of
>     that.
>
>
> Maybe. I'm not sure of that particular factor. I have the feeling that 
> there is no clear and honest analysis on the state of GUI toolkits in 
> that universe, for present and future ones.
>
>>     Newer models in the literature around those years such as PAC
>>     proposed better abstractions, but they were never implemented.
>>     Now, it's interesting to see you advocate that model on top of
>>     Morphic.
>>
>>
>>         I agree that an Application object or such might make sense
>>         when you are building an application, especially if you need
>>         to deal with en external environment. But here we were
>>         talking about whether the Model classes should know about
>>         Morphs or not.
>>
>>
>>     In theory, no.
>>
>>     In practice, if you want a well tuned gui, I consider that yes,
>>     they need to be aware of them.
>
>     Please elaborate, or provide references.
>
>
> What would you think of a drag and drop feedback which is dependent of 
> the type of the model elements?

Well, lets assume a Model with 2 collections of elements. To make it 
sound a bit more concrete, lets call them Orders and Assets. And lets 
assume that the UI has some place(s) from where the user can drag many 
kinds of objects, like Orders, Assets, between others. Now, the user 
drags an Asset and wants to drop it into the Orders list. Given that the 
widget for the Orders list supports dropping, lets assume that its 
'dropActionSelector' is #addOrder:. This #addOrder: model method would 
be called with an Asset. So, #addOrder: could answer false, to let 
sender know that the addition was rejected (because it was not an 
Order!). It makes sense to have the method in ListWidget that calls 
'dropSelector' check for the result, and if it is false, let the user 
know that the drop was rejected, for instance, by keeping the dragged 
object in the hand.

>
>
>>     So the most elegant way I've used is the two models: a pure,
>>     abstract model, totally view independent. And a pragmatic, closer
>>     to the view / aware of the view, application model as an mediator.
>>
>>
>>
>>                     I think it is better for the View to start it all.
>>
>>
>>                 +1
>>
>>
>>             I prefer to model an Application concept in the target
>>             desktop environment if I want to model highly portable stuff.
>>
>>             That application concern can be folded into a dedicated
>>             view if that is the preferred convention in the target
>>             environment.
>>
>>             Regards,
>>
>>             Thierry
>>
>>
>>         I wonder how would this result in practice. Do you have some
>>         examples to share?
>>
>>
>>     I have a complex example, a system browser, would that fit?
>
>     Sure.
>
>
> Well, a short estimate on that particular application is that, linked 
> with the pluggable morphs, 10 to 20% of the code in the application 
> model is:
> - widget creation, setup, layout
> - dynamic morph addition / removal when activating certain functions 
> on the model
> - workarounds the pluggable morphs api to:
>   - dynamically refresh parts of the inside of widgets
>   - disconnect then reconnect links between widgets so that the 
> model-triggered update of one does not change the state of the other 
> one (i.e. protect the model from unwanted view triggered updates when 
> the model is changing part of its contents).

"View model" is a bit a misleading name. I'd say all this belongs in the 
Views world.

Besides, the method called to update Views after Model changes should 
not modify the Model. In this way, there would be no extra Model events 
triggered, and spurious updates would not occur. This might require 
enhancing the Views framework, if not mature enough.

>
> This application model uses mainly two widgets.
>
> I do have a long term plan to port that to Cuis, and I expect I will 
> have to write that very same code somewhere (maybe more, maybe less).
>
> Regards,
>
> Thierry

Hopefully, it will be less :)

Cheers,
Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/b3f58cf1/attachment-0003.html>

From garduino at gmail.com  Tue Nov 17 11:44:12 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Tue, 17 Nov 2015 14:44:12 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
	<CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>
	<CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>
Message-ID: <CAEt3aLwUUCU8Qiqt_GphY1-8CpSxpbFSL75zXoAmTPY_hJjG_g@mail.gmail.com>

2015-11-17 14:14 GMT-03:00 Luciano Notarfrancesco <luchiano at gmail.com>:

> On Tue, Nov 17, 2015 at 3:57 PM, Germ?n Arduino <garduino at gmail.com>
> wrote:
>
>> Awesome!!
>>
>
> Haha, awesome is another window manager, it was also a fork of dwm, I used
> it for a while ;)
>
>
Related with this talk, I remember old times helping with LinEx (a Linux
made by the Extremadura government in Spain where my friend Diego GD was
working using Squeak in education) lot of fun playing with Squeak itself as
the Window Manager in charge of such Linux. Very very fun times!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/88c107c3/attachment-0003.html>

From thierry.goubier at gmail.com  Tue Nov 17 12:59:12 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 19:59:12 +0100
Subject: [Cuis] Fwd: Fwd: Patterns
In-Reply-To: <564B65A2.3050604@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
	<564B44B7.2070809@jvuletich.org>
	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
	<CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
	<564B65A2.3050604@jvuletich.org>
Message-ID: <564B7900.2030004@gmail.com>

Hi Juan,

Le 17/11/2015 18:36, Juan Vuletich a ?crit :
> Hi Thierry,
>
>>
>>
>> I would give HotDraw, and some of the original design pattern work on
>> editors, especially the parts derived from the InterViews toolkit.
>
> Uh, it is not easy to find stuff about that, so I can't really comment.

InterViews was kept alive as the ivtools for long, very long after 
InterViews lost to Motif as the X Window toolkit. Fresco, InterViews 
successor, was also very interesting.

HotDraw is old as well. But I did some cool stuff with it (a hypermedia 
system, in 1993).

>> Now, I used to be pretty up to date on the literature and some of the
>> criticism of the MVC model (especially the division between V and C)
>> but my memory of that time is all fuzzy.
>
> Well, in my opinion View / Model separation is a great property of the
> design of an application. Controller is more of a requirement of the
> ST-80 MVC framework. In principle, I see no problem in merging
> Controller into View. But, in Cuis, it can be argued that the Editor
> hierarchy is essentially a hierarchy of Controllers, and that's ok if
> the decomposition of responsibilities makes sense.
>
> In View / Model separation there are two restrictions that need to be
> honored:
> - The Model doesn't know about the possible Views. This means, for
> instance, that it could provide all its services, and exercise all its
> functionality, even if the GUI framework is completely absent. Model
> code should never fail because of this. This is great for moving models
> from and two different runtimes (client, server, gemstone, various
> dialects, etc) and also for writing tests.
> - Model behavior should not leak into Views. This means that if the
> views are removed (maybe to be replaced by some others, in the same or
> in another framework), Model should not lose state nor behavior. Model
> must be complete by itself.
> So, the idea is essentially to protect the integrity and consistency of
> Models.

I do agree with that objective, but, in practice, what I find as a 
result is that an additional layer (model mediation or the M2 of MMVC) 
helps immensely by:

- regrouping certain model features which are introduced to satisfy view 
requirements...

   - For example a pure model can just have a copy or save to file 
operation, but a view would like to have a feedback on the length of the 
operation. In non gui mode, having the model expose that sort of 
information is a needless waste of code and resources. This would better 
be carried by a layer on top (which is still a model IMHO, since it 
maintain a certain level of decoupling with a view).

- Expose explicitely certain adaptations which are made for a specific 
toolkit (they are in that model).

- Allow for user-features oriented models to appear on top of the pure, 
abstract model

   - In a browser, one can imagine scoped models of the code as a 
user-oriented feature that a disconnected mode doesn't need to integrate.

Nothing really grandiose or earth-shattering, mind you. Just convenient.

>> What would you think of a drag and drop feedback which is dependent of
>> the type of the model elements?
>
> Well, lets assume a Model with 2 collections of elements. To make it
> sound a bit more concrete, lets call them Orders and Assets. And lets
> assume that the UI has some place(s) from where the user can drag many
> kinds of objects, like Orders, Assets, between others. Now, the user
> drags an Asset and wants to drop it into the Orders list. Given that the
> widget for the Orders list supports dropping, lets assume that its
> 'dropActionSelector' is #addOrder:. This #addOrder: model method would
> be called with an Asset. So, #addOrder: could answer false, to let
> sender know that the addition was rejected (because it was not an
> Order!). It makes sense to have the method in ListWidget that calls
> 'dropSelector' check for the result, and if it is false, let the user
> know that the drop was rejected, for instance, by keeping the dragged
> object in the hand.

Hum, I was more thinking of what I am dealing with at the moment, which 
is a drop in the Orders list is a drop on a specific order item, which 
has to tell:

- during the drag, if a drop would be honored
- after the drop, if it is accepted or rejected
- and, if accepted, that specific order item changes state and is shown 
as such (and may also change the number of order items, etc...)

I found, when doing that, to have an intermediate model on top of my 
Asset/Order object to mediate with the drag and drop API very usefull 
(that is, what is displayed and dragged are Views on AssetModels which 
are themselves observers of Assets).


>
>>
>>
>>>     So the most elegant way I've used is the two models: a pure,
>>>     abstract model, totally view independent. And a pragmatic, closer
>>>     to the view / aware of the view, application model as an mediator.
>>>
>>>
>>>
>>>                     I think it is better for the View to start it all.
>>>
>>>
>>>                 +1
>>>
>>>
>>>             I prefer to model an Application concept in the target
>>>             desktop environment if I want to model highly portable stuff.
>>>
>>>             That application concern can be folded into a dedicated
>>>             view if that is the preferred convention in the target
>>>             environment.
>>>
>>>             Regards,
>>>
>>>             Thierry
>>>
>>>
>>>         I wonder how would this result in practice. Do you have some
>>>         examples to share?
>>>
>>>
>>>     I have a complex example, a system browser, would that fit?
>>
>>     Sure.
>>
>>
>> Well, a short estimate on that particular application is that, linked
>> with the pluggable morphs, 10 to 20% of the code in the application
>> model is:
>> - widget creation, setup, layout
>> - dynamic morph addition / removal when activating certain functions
>> on the model
>> - workarounds the pluggable morphs api to:
>>   - dynamically refresh parts of the inside of widgets
>>   - disconnect then reconnect links between widgets so that the
>> model-triggered update of one does not change the state of the other
>> one (i.e. protect the model from unwanted view triggered updates when
>> the model is changing part of its contents).
>
> "View model" is a bit a misleading name. I'd say all this belongs in the
> Views world.

As I said, it may be moved into the View world, in the sense that it 
holds view-related concerns. But, at the same time, it has Model like 
decoupling from the Views.

> Besides, the method called to update Views after Model changes should
> not modify the Model. In this way, there would be no extra Model events
> triggered, and spurious updates would not occur. This might require
> enhancing the Views framework, if not mature enough.

I'll let you have a try at that :)

>>
>> This application model uses mainly two widgets.
>>
>> I do have a long term plan to port that to Cuis, and I expect I will
>> have to write that very same code somewhere (maybe more, maybe less).
>>
>> Regards,
>>
>> Thierry
>
> Hopefully, it will be less :)

I'm certainly looking forward to it.

Regards,

Thierry



From dnorton at mindspring.com  Tue Nov 17 21:01:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 17 Nov 2015 22:01:56 -0500
Subject: [Cuis] Patterns
In-Reply-To: <564B32F5.9050102@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<564AB03D.1040405@gmail.com>, <564B32F5.9050102@jvuletich.org>
Message-ID: <564BEA24.27869.2592A08@dnorton.mindspring.com>

The repo now contains two pairs of classes: coupled and decoupled. As it stands, the 
coupled example comes up the same, whether from the World->New morph... menu or from 
a Browser or Workspace.

The decoupled example does not do this and I don't know what to have in the pattern to 
avoid the following pitfalls:

follow the BrowserWindow class #openBrowser and get MNU: owner
follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs

 - Dan

On 17 Nov 2015 at 11:00, Juan Vuletich wrote:

> Hi Thierry,
> 
> 
> On 11/17/2015 1:42 AM, Thierry Goubier wrote:
> > Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
> >>
> >>
> >> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
> >> <mailto:juan at jvuletich.org>>:
> >>
> >>     __
> >>
> >>     Well, I don't like the #open method in the model. The idea of
> View /
> >>     Model separation is that views know about models, but models
> don't
> >>     know about views. A Model should exist independently of being
> used
> >>     from Morphic, MVC, Seaside, or any other UI framework. It
> could
> >>     live, for example, in a Gemstone database with no UI at all.
> Or ir
> >>     could travel to and from other systems, like VA Smalltalk,
> where the
> >>     UI framework is completely different from Cuis'.
> >>
> >>
> >> Interesting, really I never heard of the use of  #open at the
> model or I
> >> do not remember it at all, but I think similar to Juan.
> >
> > Hum, #open has to go somewhere, so...
> >
> > Either it goes into a sort of Application Model, which regroup the
> > duties associated with the application (the view + model +
> whatever is 
> > necessary in environment X), or it goes into an Application View
> which 
> > then has model concerns in it (it knows how to start or connect to
> the 
> > model, it knows what the model is composed of to connect subviews
> to 
> > model elements, etc...).
> >
> 
> The idea of view / model separation is pretty well explained in
> "Inside 
> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
> 
> I agree that an Application object or such might make sense when you
> are 
> building an application, especially if you need to deal with en
> external 
> environment. But here we were talking about whether the Model
> classes 
> should know about Morphs or not.
> 
> >>     I think it is better for the View to start it all.
> >>
> >>
> >> +1
> >
> > I prefer to model an Application concept in the target desktop 
> > environment if I want to model highly portable stuff.
> >
> > That application concern can be folded into a dedicated view if
> that 
> > is the preferred convention in the target environment.
> >
> > Regards,
> >
> > Thierry
> 
> I wonder how would this result in practice. Do you have some
> examples to 
> share?
> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From hannes.hirzel at gmail.com  Wed Nov 18 01:02:05 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Wed, 18 Nov 2015 08:02:05 +0100
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <564A7925.4060103@jvuletich.org>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
	<564A7925.4060103@jvuletich.org>
Message-ID: <CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>

On 11/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 14/11/2015 02:12 a.m., EuanM wrote:
>> I've just recently put-together a cross-platform Installation Tutorial
>> for beginners to Smalltalk.
>>
>> I was keen to include Cuis in the exercise.
>>
>
> Again, thank you for this.
>
>> One thing that becomes clear in the comparison is that Cuis is a good
>> beginner's environment from the point of view of size and complexity
>> and their bearing in learnability.
>>
>> It is however, the worst Smalltalk (of the 4 in the tutorial) to get
>> downloaded and installed.
>>
>> This seems a pity.
>
> Please take a look at
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Documentation
>
> . There are three 'Getting Started' guides, for different OSes and user
> style / preferences. They were tried (as described) in Linux, MacOsX and
> Windows.
>
>> Would anyone be willing to help me put together a One-Click Install
>> package, similar to Squeak's and Pharo's?
>>
>> (My plan is to do the grunt-work, if other people are willing to
>> indulge my noob questions while I do it)
>
> I believe that if you take the One-Click for Squeak or Pharo, and
> replace the image with a Cuis image, it should work.

It is worthwhile to have a look as well at the Squeak all-in-one package.

I have done it in the past in an adhoc way about by taking
http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.

There is quite some discussion about how this was constructed on the
Squeak list and people are willing to answer questions.

--Hannes

>> Is there a particular place that it could be hosted, once ready?
>>
>> Would anyone disagree with a 6-monthly update cycle for the One-Click
>> installer?
>>
>> (Frequent enough to send a signal to interested beginners that the
>> project is alive and kicking.  Infrequent enough that there is not
>> much work to be done)
>
> Yep, this sounds great. The natural place is
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev isn't it?
>
>
>> Cheers,
>>     Euan
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Wed Nov 18 07:00:23 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Wed, 18 Nov 2015 14:00:23 +0100
Subject: [Cuis] New Introductory Tutorial
In-Reply-To: <564A77EE.6060802@jvuletich.org>
References: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
	<564A77EE.6060802@jvuletich.org>
Message-ID: <CAGQxfVjCC2J7hBUEMhpYAg95Ti6=assjW-cKs6sG034CVXCv4Q@mail.gmail.com>

Hi Euan

Worthwhile to refer to in your tutorial is as well the web version of
the ProfStef Smalltalk tutorial implemented in Amber Smalltalk

http://amber-smalltalk.github.io/trysmalltalk/

(https://github.com/amber-smalltalk/trysmalltalk)

It explains the syntax, control constructs and some basic classes. It
was first implemented in Pharo and then ported.

--Hannes

On 11/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi EuanM,
>
> This is a great initiative. Thanks for including Cuis in the bunch!
>
> Cheers,
> Juan Vuletich
>
> On 14/11/2015 02:02 a.m., EuanM wrote:
>> I've created Yet Another Smalltalk First
>> Steps tutorial.
>>
>> This is intended as one of a series.
>>
>> It is designed to be cross-platform across
>>
>>      Squeak 5
>>      Pharo 4
>>      Seaside 3.1
>>      Cuis
>>      Dolphin 6
>>
>> If you have experience running any of these systems on Windows, Linux
>> or MacOS, please check to see if I have the instructions correct for
>> your chosen pairing of Smalltalk and OS platform.
>>
>> (As you'll see when you look, I do not have detailed instructions for
>> aspects of MacOS).
>>
>> The document is at:
>> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html
>>
>> (It's intended to move to a different blog after this review process).
>>
>> I feel the need to do this as cross-Smalltalks tutorial because of
>> findings and 4 charts  I've placed at:
>> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/mindshare-of-smalltalk-in-development.html
>>
>> Essentially, Smalltalk mindshare and use is incredibly tiny, compared
>> to other languages in the same space.  (We all know this, but seeing
>> it represented graphically has a more visceral effect, IMO)
>>
>> Aggregating interest in all the Smalltalks still does not bring more
>> than a tiny proportion of the interest in, and use of, Ruby.
>>
>> In turn, Ruby is (quite understandably) small in comparison to
>> JavaScript.
>>
>> Comparing interest in any specific Smalltalk is, predictably, smaller
>> than the aggregate interest in Smalltalk.
>>
>> Our community seems determined to split itself into smaller and
>> smaller sub-communities.  I think we do ourselves a disservice this
>> way.
>>
>> My initial contribution will be to try to provide some explicitly
>> pan-Smalltalk beginners' tutorials, like this one.
>>
>> Cheers, and happy Smalltalking,
>>       EuanM
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Wed Nov 18 07:39:54 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 18 Nov 2015 10:39:54 -0300
Subject: [Cuis] Fwd: Fwd: Patterns
In-Reply-To: <564B7900.2030004@gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
	<564B44B7.2070809@jvuletich.org>
	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
	<CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
	<564B65A2.3050604@jvuletich.org> <564B7900.2030004@gmail.com>
Message-ID: <564C7FAA.90900@jvuletich.org>

Hi Thierry,

(inline and abridged)
On 11/17/2015 3:59 PM, Thierry Goubier wrote:
> Hi Juan,
>
> Le 17/11/2015 18:36, Juan Vuletich a ?crit :
>> Hi Thierry,
>>
> ...
>>> Now, I used to be pretty up to date on the literature and some of the
>>> criticism of the MVC model (especially the division between V and C)
>>> but my memory of that time is all fuzzy.
>>
>> Well, in my opinion View / Model separation is a great property of the
>> design of an application. Controller is more of a requirement of the
>> ST-80 MVC framework. In principle, I see no problem in merging
>> Controller into View. But, in Cuis, it can be argued that the Editor
>> hierarchy is essentially a hierarchy of Controllers, and that's ok if
>> the decomposition of responsibilities makes sense.
>>
>> In View / Model separation there are two restrictions that need to be
>> honored:
>> - The Model doesn't know about the possible Views. This means, for
>> instance, that it could provide all its services, and exercise all its
>> functionality, even if the GUI framework is completely absent. Model
>> code should never fail because of this. This is great for moving models
>> from and two different runtimes (client, server, gemstone, various
>> dialects, etc) and also for writing tests.
>> - Model behavior should not leak into Views. This means that if the
>> views are removed (maybe to be replaced by some others, in the same or
>> in another framework), Model should not lose state nor behavior. Model
>> must be complete by itself.
>> So, the idea is essentially to protect the integrity and consistency of
>> Models.
>
> I do agree with that objective, but, in practice, what I find as a 
> result is that an additional layer (model mediation or the M2 of MMVC) 
> helps immensely by:
>
> - regrouping certain model features which are introduced to satisfy 
> view requirements...
>
>   - For example a pure model can just have a copy or save to file 
> operation, but a view would like to have a feedback on the length of 
> the operation. In non gui mode, having the model expose that sort of 
> information is a needless waste of code and resources. This would 
> better be carried by a layer on top (which is still a model IMHO, 
> since it maintain a certain level of decoupling with a view).
>
> - Expose explicitely certain adaptations which are made for a specific 
> toolkit (they are in that model).
>
> - Allow for user-features oriented models to appear on top of the 
> pure, abstract model
>
>   - In a browser, one can imagine scoped models of the code as a 
> user-oriented feature that a disconnected mode doesn't need to integrate.
>
> Nothing really grandiose or earth-shattering, mind you. Just convenient.

I agree. Many times it is really useful to add another layer. At Caesar 
we called those "Model Extensions".

In many cases, it is possible to do this in a way that is agnostic of 
the actual GUI framework, meaning that it can be used for several GUI 
styles. If this is the case, then it is OK to bundle this with the real 
Model, as it doesn't leak GUI framework specifics.

It is also very desirable not to compromise the consistency of the real 
Model, i.e. not leaking Model specifics. Then, it is also possible to 
bundle this with the Views. (This is what we usually did at Caesar).

If none of this conditions are met, i.e., this "ModelExtension" includes 
Model responsibilities AND detailed GUI framework knowledge, then I'd 
say some refactoring is in order. So, this doesn't go against strict 
View / Model separation.

>>> What would you think of a drag and drop feedback which is dependent of
>>> the type of the model elements?
>>
>> Well, lets assume a Model with 2 collections of elements. To make it
>> sound a bit more concrete, lets call them Orders and Assets. And lets
>> assume that the UI has some place(s) from where the user can drag many
>> kinds of objects, like Orders, Assets, between others. Now, the user
>> drags an Asset and wants to drop it into the Orders list. Given that the
>> widget for the Orders list supports dropping, lets assume that its
>> 'dropActionSelector' is #addOrder:. This #addOrder: model method would
>> be called with an Asset. So, #addOrder: could answer false, to let
>> sender know that the addition was rejected (because it was not an
>> Order!). It makes sense to have the method in ListWidget that calls
>> 'dropSelector' check for the result, and if it is false, let the user
>> know that the drop was rejected, for instance, by keeping the dragged
>> object in the hand.
>
> Hum, I was more thinking of what I am dealing with at the moment, 
> which is a drop in the Orders list is a drop on a specific order item, 
> which has to tell:
>
> - during the drag, if a drop would be honored
> - after the drop, if it is accepted or rejected
> - and, if accepted, that specific order item changes state and is 
> shown as such (and may also change the number of order items, etc...)
>
> I found, when doing that, to have an intermediate model on top of my 
> Asset/Order object to mediate with the drag and drop API very usefull 
> (that is, what is displayed and dragged are Views on AssetModels which 
> are themselves observers of Assets).

This is OK as long as it doesn't leak Model responsibilities, then it 
can just be a Model Extension that goes with the GUI.

>
>>
>>>
>>>
>>>>     So the most elegant way I've used is the two models: a pure,
>>>>     abstract model, totally view independent. And a pragmatic, closer
>>>>     to the view / aware of the view, application model as an mediator.
>>>>
>>>>
>>>>
>>>>                     I think it is better for the View to start it all.
>>>>
>>>>
>>>>                 +1
>>>>
>>>>
>>>>             I prefer to model an Application concept in the target
>>>>             desktop environment if I want to model highly portable 
>>>> stuff.
>>>>
>>>>             That application concern can be folded into a dedicated
>>>>             view if that is the preferred convention in the target
>>>>             environment.
>>>>
>>>>             Regards,
>>>>
>>>>             Thierry
>>>>
>>>>
>>>>         I wonder how would this result in practice. Do you have some
>>>>         examples to share?
>>>>
>>>>
>>>>     I have a complex example, a system browser, would that fit?
>>>
>>>     Sure.
>>>
>>>
>>> Well, a short estimate on that particular application is that, linked
>>> with the pluggable morphs, 10 to 20% of the code in the application
>>> model is:
>>> - widget creation, setup, layout
>>> - dynamic morph addition / removal when activating certain functions
>>> on the model
>>> - workarounds the pluggable morphs api to:
>>>   - dynamically refresh parts of the inside of widgets
>>>   - disconnect then reconnect links between widgets so that the
>>> model-triggered update of one does not change the state of the other
>>> one (i.e. protect the model from unwanted view triggered updates when
>>> the model is changing part of its contents).
>>
>> "View model" is a bit a misleading name. I'd say all this belongs in the
>> Views world.
>
> As I said, it may be moved into the View world, in the sense that it 
> holds view-related concerns. But, at the same time, it has Model like 
> decoupling from the Views.

Yep (as I said above).

>
>> Besides, the method called to update Views after Model changes should
>> not modify the Model. In this way, there would be no extra Model events
>> triggered, and spurious updates would not occur. This might require
>> enhancing the Views framework, if not mature enough.
>
> I'll let you have a try at that :)

Of course. In my experience, these kinds of problems always made the 
framework evolve. Yes, it is important to be able to fix and enhance the 
frameworks you use!

>
>>>
>>> This application model uses mainly two widgets.
>>>
>>> I do have a long term plan to port that to Cuis, and I expect I will
>>> have to write that very same code somewhere (maybe more, maybe less).
>>>
>>> Regards,
>>>
>>> Thierry
>>
>> Hopefully, it will be less :)
>
> I'm certainly looking forward to it.
>
> Regards,
>
> Thierry
>

Thanks for the discussion Thierry. I think we essentially agree on the 
important parts here.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Nov 18 07:42:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 18 Nov 2015 10:42:09 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAEt3aLwUUCU8Qiqt_GphY1-8CpSxpbFSL75zXoAmTPY_hJjG_g@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>	<CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>	<CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>
	<CAEt3aLwUUCU8Qiqt_GphY1-8CpSxpbFSL75zXoAmTPY_hJjG_g@mail.gmail.com>
Message-ID: <564C8031.1040508@jvuletich.org>

On 11/17/2015 2:44 PM, Germ?n Arduino wrote:
>
> 2015-11-17 14:14 GMT-03:00 Luciano Notarfrancesco <luchiano at gmail.com 
> <mailto:luchiano at gmail.com>>:
>
>     On Tue, Nov 17, 2015 at 3:57 PM, Germ?n Arduino
>     <garduino at gmail.com <mailto:garduino at gmail.com>> wrote:
>
>         Awesome!!
>
>
>     Haha, awesome is another window manager, it was also a fork of
>     dwm, I used it for a while ;)
>
>
> Related with this talk, I remember old times helping with LinEx (a 
> Linux made by the Extremadura government in Spain where my friend 
> Diego GD was working using Squeak in education) lot of fun playing 
> with Squeak itself as the Window Manager in charge of such Linux. Very 
> very fun times!
>

Oh! I knew about LinEx, although I never used it. And didn't know about 
using Squeak as the Window Manager! That was also for non-Squeak 
windows, like a Bash terminal?

Thanks,
Juan Vuletih
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151118/200e56f2/attachment-0003.html>

From juan at jvuletich.org  Wed Nov 18 08:00:41 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 18 Nov 2015 11:00:41 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564BEA24.27869.2592A08@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<564AB03D.1040405@gmail.com>, <564B32F5.9050102@jvuletich.org>
	<564BEA24.27869.2592A08@dnorton.mindspring.com>
Message-ID: <564C8489.2000601@jvuletich.org>

Hi Dan,

On 11/18/2015 12:01 AM, Dan Norton wrote:
> The repo now contains two pairs of classes: coupled and decoupled. As it stands, the
> coupled example comes up the same, whether from the World->New morph... menu or from
> a Browser or Workspace.
>
> The decoupled example does not do this and I don't know what to have in the pattern to
> avoid the following pitfalls:
>
> follow the BrowserWindow class #openBrowser and get MNU: owner
> follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs
>
>   - Dan

This is much nicer, thanks! To make the BrowserWindow style work, all 
you have to do is to have #open answer the new instance (instead of the 
class). WRT the ColorEditorPanel style, maybe Ken can comment, or a 
little debugging is in order :)

Cheers,
Juan Vuletich



From Ken.Dickey at Whidbey.com  Thu Nov 19 16:06:17 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 14:06:17 -0800
Subject: [Cuis] Patterns
In-Reply-To: <564C8489.2000601@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<564BEA24.27869.2592A08@dnorton.mindspring.com>
	<564C8489.2000601@jvuletich.org>
Message-ID: <20151119140617.2b8f709d321e79c421f5e7a8@Whidbey.com>

Greetings all!

I have been without power for a few days.  Overhead power lines through forest with 70 mph "wind events" each winter is a guarantee of on-island jobs and the lineman's union is very adverse to underground phone lines.  I must say that this does add interest to the "island living" experience!  8^)

Boy, did I miss a lot of eMail conversations!


On Wed, 18 Nov 2015 11:00:41 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> > follow the BrowserWindow class #openBrowser and get MNU: owner
> > follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs
> >
> >   - Dan

> This is much nicer, thanks! To make the BrowserWindow style work, all 
> you have to do is to have #open answer the new instance (instead of the 
> class). WRT the ColorEditorPanel style, maybe Ken can comment, or a 
> little debugging is in order :)

Actually, I was looking at color backgrounds which would not clash badly with color display and sliders.  Suggestions welcomed.  I still be learning too!

Glad to be back online,
-KenD



From Ken.Dickey at Whidbey.com  Thu Nov 19 16:36:28 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 14:36:28 -0800
Subject: [Cuis] ChromeOS vs Cog VM
Message-ID: <20151119143628.303636338485b6c420e023a7@Whidbey.com>

By the way, I got a chance to work with Tim Rowledge at the Nanaimo Camp Smalltalk.

I'm sure Tim would have rather showed me around the Raspberry Pi VM work, but I have been unable to get any Cog VMs to work on either of my ARM Chromebooks.

CogVM works fine on the ATM RasPi system.

It turns out that Chromebooks are very serious about protecting maximally against code hijacking.  They don't allow arbitrary code to be written into memory and executed.

This is very good for safety in an uncertain world, but is also the definition of Just-In-Time code generation.

I expected that Google's V8 JavaScript, which JITs, would show how to do this sanely under ChromeOS so that we could Cog it, but the code base for V8 shows that they only run the bytecodes -- no JIT -- on Chromebooks.


There is hope for the future, but some changes will be required:
See 

"Exploiting and Protecting Dynamic Code Generation"

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjguP_RxJ3JAhXQT4gKHS2VAUYQFggeMAA&url=http%3A%2F%2Fwenke.gtisc.gatech.edu%2Fpapers%2Fsdcg.pdf&usg=AFQjCNF52_QFDuMcP05WvfeHNi2wUK-yHg&sig2=8SzTcWKA7VBubmzdzJmIiA


Google's "Safe Self-Modifying Code" patent: (Patent! Ack!! 8^{)

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwilmsKlxZ3JAhVRKYgKHfXgDOMQFgg5MAM&url=http%3A%2F%2Fwww.google.com%2Fpatents%2FUS8850574&usg=AFQjCNHTAbYqbvqy80Edcww1YDsgUvoKMQ&sig2=FK01uFZEn778RNmRm7iz4A


Also "Certified Self-Modifying Code"

http://flint.cs.yale.edu/flint/publications/smctr.pdf

More hoops, sigh.

FYI,
-KenD



From Ken.Dickey at Whidbey.com  Thu Nov 19 16:38:31 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 14:38:31 -0800
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
Message-ID: <20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>

On Thu, 19 Nov 2015 14:36:28 -0800
KenD <Ken.Dickey at Whidbey.com> wrote:

> CogVM works fine on the ATM RasPi system.

Sorry.  That is the _ARM_ Raspberry Pi system.

Sausage fingers, sigh.
-KenD



From 0800nacho at gmail.com  Thu Nov 19 17:02:53 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Thu, 19 Nov 2015 20:02:53 -0300
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>
Message-ID: <CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w@mail.gmail.com>

In my x86 chromebook I had to chroot through crouton and run Cuis from
there.
It seems that porting the VM to NaCL is indeed a daunting job....
Perhaps once web assembly is there, things turn a little easier, I don't
know.
cheers!


*Lic. Ignacio Sniechowski, MBA*
*Prosavic SRL*

*Tel: (011) 4542-6714*


















On Thu, Nov 19, 2015 at 7:38 PM, KenD <Ken.Dickey at whidbey.com> wrote:

> On Thu, 19 Nov 2015 14:36:28 -0800
> KenD <Ken.Dickey at Whidbey.com> wrote:
>
> > CogVM works fine on the ATM RasPi system.
>
> Sorry.  That is the _ARM_ Raspberry Pi system.
>
> Sausage fingers, sigh.
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151119/53227dca/attachment-0003.html>

From Ken.Dickey at Whidbey.com  Thu Nov 19 18:27:32 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 16:27:32 -0800
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w@mail.gmail.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>
	<CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w@mail.gmail.com>
Message-ID: <20151119162732.d1620999640219efc0ace630@Whidbey.com>

On Thu, 19 Nov 2015 20:02:53 -0300
Ignacio Sniechowski <0800nacho at gmail.com> wrote:

> In my x86 chromebook I had to chroot through crouton and run Cuis from
> there.

That is what I am doing, using the stack-vm for ARM.


> It seems that porting the VM to NaCL is indeed a daunting job....

So it would appear..


Cheers, 
-KenD



From euanmee at gmail.com  Fri Nov 20 20:10:23 2015
From: euanmee at gmail.com (EuanM)
Date: Sat, 21 Nov 2015 02:10:23 +0000
Subject: [Cuis] ChromeOS vs Cog VM
Message-ID: <CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>

We can run Smalltalk on our ARM ChromeBooks!?!?

Where's the nearest How-to?


On 20 November 2015 at 18:00,  <cuis-request at jvuletich.org> wrote:
> Send Cuis mailing list submissions to
>         cuis at jvuletich.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> or, via email, send a message with subject or body 'help' to
>         cuis-request at jvuletich.org
>
> You can reach the person managing the list at
>         cuis-owner at jvuletich.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cuis digest..."
>
>
> Today's Topics:
>
>    1. Re: Patterns (KenD)
>    2. ChromeOS vs Cog VM (KenD)
>    3. Re: ChromeOS vs Cog VM (KenD)
>    4. Re: ChromeOS vs Cog VM (Ignacio Sniechowski)
>    5. Re: ChromeOS vs Cog VM (KenD)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Nov 2015 14:06:17 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Subject: Re: [Cuis] Patterns
> Message-ID: <20151119140617.2b8f709d321e79c421f5e7a8 at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> Greetings all!
>
> I have been without power for a few days.  Overhead power lines through forest with 70 mph "wind events" each winter is a guarantee of on-island jobs and the lineman's union is very adverse to underground phone lines.  I must say that this does add interest to the "island living" experience!  8^)
>
> Boy, did I miss a lot of eMail conversations!
>
>
> On Wed, 18 Nov 2015 11:00:41 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
>
>> > follow the BrowserWindow class #openBrowser and get MNU: owner
>> > follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs
>> >
>> >   - Dan
>
>> This is much nicer, thanks! To make the BrowserWindow style work, all
>> you have to do is to have #open answer the new instance (instead of the
>> class). WRT the ColorEditorPanel style, maybe Ken can comment, or a
>> little debugging is in order :)
>
> Actually, I was looking at color backgrounds which would not clash badly with color display and sliders.  Suggestions welcomed.  I still be learning too!
>
> Glad to be back online,
> -KenD
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 Nov 2015 14:36:28 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: tim Rowledge <tim at rowledge.org>
> Subject: [Cuis] ChromeOS vs Cog VM
> Message-ID: <20151119143628.303636338485b6c420e023a7 at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> By the way, I got a chance to work with Tim Rowledge at the Nanaimo Camp Smalltalk.
>
> I'm sure Tim would have rather showed me around the Raspberry Pi VM work, but I have been unable to get any Cog VMs to work on either of my ARM Chromebooks.
>
> CogVM works fine on the ATM RasPi system.
>
> It turns out that Chromebooks are very serious about protecting maximally against code hijacking.  They don't allow arbitrary code to be written into memory and executed.
>
> This is very good for safety in an uncertain world, but is also the definition of Just-In-Time code generation.
>
> I expected that Google's V8 JavaScript, which JITs, would show how to do this sanely under ChromeOS so that we could Cog it, but the code base for V8 shows that they only run the bytecodes -- no JIT -- on Chromebooks.
>
>
> There is hope for the future, but some changes will be required:
> See
>
> "Exploiting and Protecting Dynamic Code Generation"
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjguP_RxJ3JAhXQT4gKHS2VAUYQFggeMAA&url=http%3A%2F%2Fwenke.gtisc.gatech.edu%2Fpapers%2Fsdcg.pdf&usg=AFQjCNF52_QFDuMcP05WvfeHNi2wUK-yHg&sig2=8SzTcWKA7VBubmzdzJmIiA
>
>
> Google's "Safe Self-Modifying Code" patent: (Patent! Ack!! 8^{)
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwilmsKlxZ3JAhVRKYgKHfXgDOMQFgg5MAM&url=http%3A%2F%2Fwww.google.com%2Fpatents%2FUS8850574&usg=AFQjCNHTAbYqbvqy80Edcww1YDsgUvoKMQ&sig2=FK01uFZEn778RNmRm7iz4A
>
>
> Also "Certified Self-Modifying Code"
>
> http://flint.cs.yale.edu/flint/publications/smctr.pdf
>
> More hoops, sigh.
>
> FYI,
> -KenD
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 19 Nov 2015 14:38:31 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: tim Rowledge <tim at rowledge.org>
> Subject: Re: [Cuis] ChromeOS vs Cog VM
> Message-ID: <20151119143831.7d441ccd80e851e278a5d16d at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 19 Nov 2015 14:36:28 -0800
> KenD <Ken.Dickey at Whidbey.com> wrote:
>
>> CogVM works fine on the ATM RasPi system.
>
> Sorry.  That is the _ARM_ Raspberry Pi system.
>
> Sausage fingers, sigh.
> -KenD
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 19 Nov 2015 20:02:53 -0300
> From: Ignacio Sniechowski <0800nacho at gmail.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: tim Rowledge <tim at rowledge.org>
> Subject: Re: [Cuis] ChromeOS vs Cog VM
> Message-ID:
>         <CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> In my x86 chromebook I had to chroot through crouton and run Cuis from
> there.
> It seems that porting the VM to NaCL is indeed a daunting job....
> Perhaps once web assembly is there, things turn a little easier, I don't
> know.
> cheers!
>
>
> *Lic. Ignacio Sniechowski, MBA*
> *Prosavic SRL*
>
> *Tel: (011) 4542-6714*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Nov 19, 2015 at 7:38 PM, KenD <Ken.Dickey at whidbey.com> wrote:
>
>> On Thu, 19 Nov 2015 14:36:28 -0800
>> KenD <Ken.Dickey at Whidbey.com> wrote:
>>
>> > CogVM works fine on the ATM RasPi system.
>>
>> Sorry.  That is the _ARM_ Raspberry Pi system.
>>
>> Sausage fingers, sigh.
>> -KenD
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151119/53227dca/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 19 Nov 2015 16:27:32 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: cuis at jvuletich.org
> Subject: Re: [Cuis] ChromeOS vs Cog VM
> Message-ID: <20151119162732.d1620999640219efc0ace630 at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 19 Nov 2015 20:02:53 -0300
> Ignacio Sniechowski <0800nacho at gmail.com> wrote:
>
>> In my x86 chromebook I had to chroot through crouton and run Cuis from
>> there.
>
> That is what I am doing, using the stack-vm for ARM.
>
>
>> It seems that porting the VM to NaCL is indeed a daunting job....
>
> So it would appear..
>
>
> Cheers,
> -KenD
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 41, Issue 29
> ************************************



From 0800nacho at gmail.com  Sat Nov 21 06:53:02 2015
From: 0800nacho at gmail.com (nacho)
Date: Sat, 21 Nov 2015 04:53:02 -0800 (PST)
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>
Message-ID: <1448110382723-4862380.post@n4.nabble.com>

Yes Euan,
However bear in mind two things:
1) You have to put your Chromebook into developer mode. See here on how to
do it and what it means.
http://www.howtogeek.com/210817/how-to-enable-developer-mode-on-your-chromebook/

2) You have to install Crouton. Crouton chroots your ChromeOS with the Linux
equivalente (usually an Ubuntu, but other flavours my be chosen). See here
on how to install it, and all the options you have.
https://github.com/dnschneid/crouton

3) Install the Crouton extension, really helps.

4) Install an ARM based VM (check in Eliot Miranda place)
http://www.mirandabanda.org/files/Cog/VM/ and for a classic VM in
http://www.squeakvm.org/unix/

And that should do it.
Cheers
Nacho 



-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/ChromeOS-vs-Cog-VM-tp4862115p4862380.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Sat Nov 21 10:47:08 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sat, 21 Nov 2015 08:47:08 -0800
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <1448110382723-4862380.post@n4.nabble.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>
	<1448110382723-4862380.post@n4.nabble.com>
Message-ID: <20151121084708.d29f22f6470bb56c300f7e48@Whidbey.com>

On Sat, 21 Nov 2015 04:53:02 -0800 (PST)
nacho <0800nacho at gmail.com> wrote:

> 4) Install an ARM based VM (check in Eliot Miranda place)
> http://www.mirandabanda.org/files/Cog/VM/ and for a classic VM in
> http://www.squeakvm.org/unix/

Nacho,

Great instructions.  I do almost all my work on an ARM Chromebook these days.

FYI I am using stklinuxhtARM-15.24.3386.tgz

Few of the Cog builds do stklinuxhtARM.

Cheers,
-KenD



From Ken.Dickey at whidbey.com  Fri Nov 20 23:47:36 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sat, 21 Nov 2015 13:47:36 +0800
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
	<564A7925.4060103@jvuletich.org>
	<CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>
Message-ID: <20151121134736.8c5073e5fbb43076d2defbf7@whidbey.com>

On Wed, 18 Nov 2015 08:02:05 +0100
"H. Hirzel" <hannes.hirzel at gmail.com> wrote:

> It is worthwhile to have a look as well at the Squeak all-in-one package.
> 
> I have done it in the past in an adhoc way about by taking
> http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.

Note that Squeak 5.0 uses the new Spur memory format which is incompatable with the older (4.x and Cuis) image format. 

Cheers,
-KenD



From euanmee at gmail.com  Sun Nov 22 17:05:26 2015
From: euanmee at gmail.com (EuanM)
Date: Sun, 22 Nov 2015 23:05:26 +0000
Subject: [Cuis] One-Click Installer for Cuis
Message-ID: <CALsRT0nu5CeinNX_8jjP=RvrJKkmMu18kNwEN-fLSq4KCALi4A@mail.gmail.com>

That's a useful thing to know!

Is there a sense of when Cuis will be able to use the Spur VM?  Squeak
5.0 is *much* faster on ARM than Squeak 4.6 (thanks to Tim Rowledge
and co).

And my own usecase for Cuis is the Raspberry Pi.  (and of course, now
also development on my Chromebook)

Cheers,
    EuanM

On 22 November 2015 at 18:00,  <cuis-request at jvuletich.org> wrote:
> Date: Sat, 21 Nov 2015 13:47:36 +0800
> From: "Ken.Dickey" <Ken.Dickey at whidbey.com>
>
> On Wed, 18 Nov 2015 08:02:05 +0100
> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>
>> It is worthwhile to have a look as well at the Squeak all-in-one package.
>>
>> I have done it in the past in an adhoc way about by taking
>> http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.
>
> Note that Squeak 5.0 uses the new Spur memory format which is incompatable with the older (4.x and Cuis) image format.
>
> Cheers,
> -KenD
>



From juan at jvuletich.org  Mon Nov 23 06:59:47 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 23 Nov 2015 09:59:47 -0300
Subject: [Cuis] New updates
Message-ID: <56530DC3.3040609@jvuletich.org>

Hi all,

I recently included some new updates:

- Fixes to Exceptions by Andr?s Valloud and Martin McClure.
- Assessments framework for testing and validation by Andr?s Valloud.
- Many fixes and enhancements to Layouts, Window drawing, keyboard 
shortcuts, etc. by Luciano Notarfrancesco

Thank you very much Folks! Andr?s, Luciano, please comment a bit on what 
you did, especially subtle but important behavior such as Exceptions and 
new stuff like Assessments, and the new Theme and Window Manager.

Cheers,
Juan Vuletich



From 0800nacho at gmail.com  Mon Nov 23 08:37:07 2015
From: 0800nacho at gmail.com (nacho)
Date: Mon, 23 Nov 2015 06:37:07 -0800 (PST)
Subject: [Cuis] Basic & probably stupid question.
Message-ID: <1448289427985-4862695.post@n4.nabble.com>

Hi Folks,
I'm trying an example from Inside Smalltalk vol.1

When I try to print:

| anArray |
anArray _ Array new.
anArray at: 1 put: 'hello'; at: 2 put: 'nacho'; at: 3 put: 'pepito'.

I receive:
subscript is out of bounds: 1
Where as according to the book I should receive the 3th element.

The same happens when I try to print:
| anArray |
anArray _ Array new.
anArray at: 1 put: 'hello'; at: 2 put: 'nacho'; at: 3 put: 'pepito';
yourself.

which according to the book should return anArray.

is the at:put: selector different in Cuis?
Thanks in advance
Nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Basic-probably-stupid-question-tp4862695.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From 0800nacho at gmail.com  Mon Nov 23 08:44:27 2015
From: 0800nacho at gmail.com (nacho)
Date: Mon, 23 Nov 2015 06:44:27 -0800 (PST)
Subject: [Cuis] Basic & probably stupid question.
In-Reply-To: <1448289427985-4862695.post@n4.nabble.com>
References: <1448289427985-4862695.post@n4.nabble.com>
Message-ID: <1448289867935-4862701.post@n4.nabble.com>

I figured it out.
It was indeed a stupid question.
Arrays are fixed so I should do:
anArray _ Array new: 3.

cheers




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Basic-probably-stupid-question-tp4862695p4862701.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From luchiano at gmail.com  Mon Nov 23 09:35:06 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Mon, 23 Nov 2015 15:35:06 +0000
Subject: [Cuis] New updates
In-Reply-To: <56530DC3.3040609@jvuletich.org>
References: <56530DC3.3040609@jvuletich.org>
Message-ID: <CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>

Hi all,
About my recent changes, some of them are 1) extensions to Theme to be able
to customize some more aspects of how the windows and widgets look, or 2)
fixes for small bugs that I found on the way, like misalignments of a few
pixels between parts of a widget or a window. The motivation behind this
was just to be able to implement a very minimalist look (borders of just 1
pixel, no decorations, no icons, no anything that I dont need and takes up
screen real estate), and a sort of tiling dynamic window manager very much
like http://dwm.suckless.org (https://github.com/len/Cuis-Smalltalk-DWM).

In order to implement this "window manager" as an external package with
minimal changes to the core system, I decided to: 1) make the current Theme
receive messages #windowOpen: #windowClosed: every time SystemWindows are
open or closed, in order to give it a chance to implement window-management
behaviour or delegate it to a proper window manager; 2) move the
window-management keyboard shortcuts (like alt-w to close) to Theme, so it
is all in one place, easy to change, and easy to make a Theme that
delegates keyboard events to a proper window manager.

Again I did it like this in order to minimize changes to the core system.
At the moment window management is in part implemented in SystemWindow, and
also in HandMorph and Morph. I had to make some small modifications in
order to get the desired behavior when using DWM, and keep the original
behavior in the base system. Maybe in the long run we would want to have a
WindowManager class that do this, handle keyboard events for the
window-management shortcuts and receives #windowOpen: and #windowClosed:,
etc. But I would like to think better about this before adding new concepts
and complexity to the core.

Cheers,
Luciano


On Mon, Nov 23, 2015 at 12:59 PM, Juan Vuletich <juan at jvuletich.org> wrote:

> Hi all,
>
> I recently included some new updates:
>
> - Fixes to Exceptions by Andr?s Valloud and Martin McClure.
> - Assessments framework for testing and validation by Andr?s Valloud.
> - Many fixes and enhancements to Layouts, Window drawing, keyboard
> shortcuts, etc. by Luciano Notarfrancesco
>
> Thank you very much Folks! Andr?s, Luciano, please comment a bit on what
> you did, especially subtle but important behavior such as Exceptions and
> new stuff like Assessments, and the new Theme and Window Manager.
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151123/42175fe6/attachment-0003.html>

From hannes.hirzel at gmail.com  Tue Nov 24 08:56:19 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 24 Nov 2015 15:56:19 +0100
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <20151121134736.8c5073e5fbb43076d2defbf7@whidbey.com>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
	<564A7925.4060103@jvuletich.org>
	<CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>
	<20151121134736.8c5073e5fbb43076d2defbf7@whidbey.com>
Message-ID: <CAGQxfVh++xk8YNESwEgwGM-2OXOx2O_fckMtWJDS5v-EQSN6oA@mail.gmail.com>

On 11/21/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Wed, 18 Nov 2015 08:02:05 +0100
> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>
>> It is worthwhile to have a look as well at the Squeak all-in-one package.
>>
>> I have done it in the past in an adhoc way about by taking
>> http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.
>
> Note that Squeak 5.0 uses the new Spur memory format which is incompatable
> with the older (4.x and Cuis) image format.

Thanks, Ken for the correction. I based the ad-hoc Cuis all-in-one on
http://ftp.squeak.org/4.6/Squeak-4.6-All-in-One.zip

--Hannes

>
> Cheers,
> -KenD
>



From Ken.Dickey at Whidbey.com  Tue Nov 24 18:08:31 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Tue, 24 Nov 2015 16:08:31 -0800
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <CALsRT0nu5CeinNX_8jjP=RvrJKkmMu18kNwEN-fLSq4KCALi4A@mail.gmail.com>
References: <CALsRT0nu5CeinNX_8jjP=RvrJKkmMu18kNwEN-fLSq4KCALi4A@mail.gmail.com>
Message-ID: <20151124160831.2314ed8c9a831809c0321069@Whidbey.com>

On Sun, 22 Nov 2015 23:05:26 +0000
EuanM <euanmee at gmail.com> wrote:

> Is there a sense of when Cuis will be able to use the Spur VM?  

You pushed me over the edge.  I am now/currently working on this.

> > Note that Squeak 5.0 uses the new Spur memory format which is incompatable with the older (4.x and Cuis) image format.

FYI, stkspurlinuxhtARM-15.24.3386.tgz can run Squeak 5.0 images on an ARM Chromebook under Crouton/Ubuntu.

Cheers,
-KenD



From luchiano at gmail.com  Thu Nov 26 00:53:52 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Thu, 26 Nov 2015 06:53:52 +0000
Subject: [Cuis] image segments
Message-ID: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>

I don't see image segments in Cuis... I don't even know if they still exist
in Squeak... Anyone is still using it?

It would be cool to have it at least as a package. If I remember correctly
it was very simple, like two primitives to load and save, but I think it
depended on something like mark and sweep or some particular kind of
garbage collector and it might not work in new VMs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151126/8333877d/attachment-0003.html>

From hannes.hirzel at gmail.com  Thu Nov 26 01:36:49 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 07:36:49 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
Message-ID: <CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>

Squeak 5.0 still has ImageSegments (class comment below). Saving and
loading of  projects currently is blocked in Squeak because of an
unfinished name space (environments implementation).

http://wiki.squeak.org/squeak/6218

And there is Fuel
http://rmod.inria.fr/web/software/Fuel

----------

ImageSegment

I represent a segment of Squeak address space.  I am created from an
array of root objects.  After storing, my segment contains a binary
encoding of every object accessible from my roots but not otherwise
accessible from anywhere else in the system.  My segment contains
outward pointers that are indices into my table of outPointers.
On load my segment is converted back into objects and becommed
into an Array of the loaded objects, so they can be enumerated.

	The main use of ImageSegments is to store Projects.  A dummy
version of SmartRefStream traverses the Project.  Everything it finds
is classified as either an object that is owned by the project (only
pointed to inside the project), or an object outside the project that
is pointed to from inside the project.  The objects that are
completely owned by the project are compressed into pure binary form
in an ImageSegment.  The outside objects are put in the 'outPointers'
array.  The entire ImageSegment (binary part plus outPointers) is
encoded in a SmartRefStream, and saved on the disk.  (aProject
exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
writeForExportWithSources:inDirectory:changeSet:).

	Note that every object inside the project is put into the
segment's arrayOfRoots.  This is because a dummy SmartRefStream to
scan the project, in order to make intelligent decisions about what
belongs in the project.
	See Project's class comment for what messages are sent to
objects as they are unpacked in a new image.

---- Older Details ------

	The primary kind of image segment is an Export Segment.  It
can be saved on a server and read into a completely different Squeak
image.
Old way to create one:
(ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz class))
		writeForExport: 'myFile.extSeg'.
Old way to create one for a project:
	(Project named: 'Play With Me - 3') exportSegment.
To read it into another image:  Select 'myFile.extSeg' in a FileList,
Menu 'load as project'.  It will install its classes automatically.
If you need to see the roots array, it is temporarily stored in
(SmartRefStream scannedObject).

Most of 'states' of an ImageSegment are not used to export a project,
and have been abandoned.

	When a segment is written out onto a file, it goes in a
folder called <image name>_segs.  If your image is called
"Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
image whenever your move, copy, or rename it.
	Whenever a Class is in arrayOfRoots, its class (aClass class)
must also be in the arrayOfRoots.
	There are two kinds of image segments.  Normal image segments
are a piece of a specific Squeak image, and can only be read back
into that image.  The image holds the array of outPointers that are
necessary to turn the bits in the file into objects.
	To put out a normal segment that holds a Project (not the
current project), execute (Project named: 'xxx') storeSegment.


arrayOfRoots	The objects that head the tree we will trace.
segment			The WordArray of raw bits of all objects in the tree.
outPointers		Oops of all objects outside the segment
pointed to from inside.
state			(see below)
segmentName	Its basic name.  Often the name of a Project.
fileName		The local name of the file.  'Foo-23.seg'
userRootCnt		number of roots submitted by caller.  Extras
are added in preparation for saving.

state that an ImageSegment may exist in...

#activeCopy			(has been copied, with the intent to
become active)
arrayOfRoots, segment, and outPointers have been created by
copyFromRoots:.  The tree of objects has been encoded in the segment,
but those objects are still present in the Squeak system.

#active				(segment is actively holding objects)
The segment is now the only holder of tree of objects.  Each of the
original roots has been transmuted into an ImageSegmentRootStub that
refers back to this image segment.  The original objects in the
segment will all be garbageCollected.

#onFile
The segment has been written out to a file and replaced by a file
pointer.  Only ImageSegmentRootStubs and the array of outPointers
remains in the image.  To get this far:
(ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
		writeToFile: 'myFile.seg'.

#inactive
The segment has been brought back into memory and turned back into
objects.  rootsArray is set, but the segment is invalid.

#onFileWithSymbols
The segment has been written out to a file, along with the text of
all the symbols in the outPointers array, and replaced by a file
pointer.  This reduces the size of the outPointers array, and also
allows the system to reclaim any symbols that are not referred to
from elsewhere in the image.  The specific format used is that of a
literal array as follows:
	#(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' # symbol5).
In this case, the original outPointers array was 8 long, but the
compacted table of outPointers retains only two entries.  These get
inserted in place of the #'s in the array of symbols after it is read
back in.  Symbols with embedded spaces or other strange characters
are written as strings, and converted back to symbols when read back
in.  The symbol # is never written out.
	NOTE: All IdentitySets or dictionaries must be rehashed when
being read back from this format.  The symbols are effectively
internal.  (No, not if read back into same image.  If a different
image, then use #imported.  -tk)

#imported
The segment is on an external file or just read in from one.  The
segment and outPointers are meant to be read into a foreign image.
In this form, the image segment can be read from a URL, and
installed.  A copy of the original array of root objects is
constructed, with former outPointers bound to existing objects in the
host system.
	(Any Class inside the segment MUST be in the arrayOfRoots.
This is so its association can be inserted into Smalltalk.  The
class's metaclass must be in roots also.  Methods that are in
outPointers because blocks point at them, were found and added to the
roots.
	All IdentitySets and dictionaries are rehashed when being
read back from exported segments.)


To discover why only some of the objects in a project are being
written out, try this (***Destructive Test***).  This breaks lots of
backpointers in the target project, and puts up an array of
suspicious objects, a list of the classes of the outPointers, and a
debugger.
"Close any transcripts in the target project"
World currentHand objectToPaste ifNotNil: [
	self inform: 'Hand is holding a Morph in its paste buffer:\' withCRs,
		World currentHand objectToPaste printString].
PV := Project named: 'xxxx'.
(IS := ImageSegment new) findRogueRootsImSeg:
	(Array with: PV world presenter with: PV world).
IS findOwnersOutPtrs.	"Optionally: write a file with owner chains"
"Quit and DO NOT save"

When an export image segment is brought into an image, it is like an
image starting up.  Certain startUp messages need to be run.  These
are byte and word reversals for nonPointer data that comes from a
machine of the opposite endianness.  #startUpProc passes over all
objects in the segment, and:
	The first time an instance of class X is encountered, (msg _
X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
case, it means that instances of X do not need special work.  X is
included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
store it in the dictionary, startUps (aClass -> aMessage).
	When a later instance of X is encountered, if X is in
noStartUpNeeded, do nothing.  If X is in startUps, send the message
to the instance.  Typically this is a message like #swapShortObjects.
	Every class that implements #startUp, should see if it needs
a parallel implementation of #startUpFrom:.

On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> I don't see image segments in Cuis... I don't even know if they still exist
> in Squeak... Anyone is still using it?
>
> It would be cool to have it at least as a package. If I remember correctly
> it was very simple, like two primitives to load and save, but I think it
> depended on something like mark and sweep or some particular kind of
> garbage collector and it might not work in new VMs.
>



From hannes.hirzel at gmail.com  Thu Nov 26 02:02:11 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 08:02:11 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
Message-ID: <CAGQxfVg0Oy-b5b-fZJwL39Zb_SnKhqiiti4mcK6wonNrrSMUPA@mail.gmail.com>

P.S. For a working version of Project save/load in Squeak go back to
version 4.4 or maybe 4.3

http://squeak.org/downloads/

On 11/26/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Squeak 5.0 still has ImageSegments (class comment below). Saving and
> loading of  projects currently is blocked in Squeak because of an
> unfinished name space (environments implementation).
>
> http://wiki.squeak.org/squeak/6218
>
> And there is Fuel
> http://rmod.inria.fr/web/software/Fuel
>
> ----------
>
> ImageSegment
>
> I represent a segment of Squeak address space.  I am created from an
> array of root objects.  After storing, my segment contains a binary
> encoding of every object accessible from my roots but not otherwise
> accessible from anywhere else in the system.  My segment contains
> outward pointers that are indices into my table of outPointers.
> On load my segment is converted back into objects and becommed
> into an Array of the loaded objects, so they can be enumerated.
>
> 	The main use of ImageSegments is to store Projects.  A dummy
> version of SmartRefStream traverses the Project.  Everything it finds
> is classified as either an object that is owned by the project (only
> pointed to inside the project), or an object outside the project that
> is pointed to from inside the project.  The objects that are
> completely owned by the project are compressed into pure binary form
> in an ImageSegment.  The outside objects are put in the 'outPointers'
> array.  The entire ImageSegment (binary part plus outPointers) is
> encoded in a SmartRefStream, and saved on the disk.  (aProject
> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
> writeForExportWithSources:inDirectory:changeSet:).
>
> 	Note that every object inside the project is put into the
> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
> scan the project, in order to make intelligent decisions about what
> belongs in the project.
> 	See Project's class comment for what messages are sent to
> objects as they are unpacked in a new image.
>
> ---- Older Details ------
>
> 	The primary kind of image segment is an Export Segment.  It
> can be saved on a server and read into a completely different Squeak
> image.
> Old way to create one:
> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
> class))
> 		writeForExport: 'myFile.extSeg'.
> Old way to create one for a project:
> 	(Project named: 'Play With Me - 3') exportSegment.
> To read it into another image:  Select 'myFile.extSeg' in a FileList,
> Menu 'load as project'.  It will install its classes automatically.
> If you need to see the roots array, it is temporarily stored in
> (SmartRefStream scannedObject).
>
> Most of 'states' of an ImageSegment are not used to export a project,
> and have been abandoned.
>
> 	When a segment is written out onto a file, it goes in a
> folder called <image name>_segs.  If your image is called
> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
> image whenever your move, copy, or rename it.
> 	Whenever a Class is in arrayOfRoots, its class (aClass class)
> must also be in the arrayOfRoots.
> 	There are two kinds of image segments.  Normal image segments
> are a piece of a specific Squeak image, and can only be read back
> into that image.  The image holds the array of outPointers that are
> necessary to turn the bits in the file into objects.
> 	To put out a normal segment that holds a Project (not the
> current project), execute (Project named: 'xxx') storeSegment.
>
>
> arrayOfRoots	The objects that head the tree we will trace.
> segment			The WordArray of raw bits of all objects in the tree.
> outPointers		Oops of all objects outside the segment
> pointed to from inside.
> state			(see below)
> segmentName	Its basic name.  Often the name of a Project.
> fileName		The local name of the file.  'Foo-23.seg'
> userRootCnt		number of roots submitted by caller.  Extras
> are added in preparation for saving.
>
> state that an ImageSegment may exist in...
>
> #activeCopy			(has been copied, with the intent to
> become active)
> arrayOfRoots, segment, and outPointers have been created by
> copyFromRoots:.  The tree of objects has been encoded in the segment,
> but those objects are still present in the Squeak system.
>
> #active				(segment is actively holding objects)
> The segment is now the only holder of tree of objects.  Each of the
> original roots has been transmuted into an ImageSegmentRootStub that
> refers back to this image segment.  The original objects in the
> segment will all be garbageCollected.
>
> #onFile
> The segment has been written out to a file and replaced by a file
> pointer.  Only ImageSegmentRootStubs and the array of outPointers
> remains in the image.  To get this far:
> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
> 		writeToFile: 'myFile.seg'.
>
> #inactive
> The segment has been brought back into memory and turned back into
> objects.  rootsArray is set, but the segment is invalid.
>
> #onFileWithSymbols
> The segment has been written out to a file, along with the text of
> all the symbols in the outPointers array, and replaced by a file
> pointer.  This reduces the size of the outPointers array, and also
> allows the system to reclaim any symbols that are not referred to
> from elsewhere in the image.  The specific format used is that of a
> literal array as follows:
> 	#(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' # symbol5).
> In this case, the original outPointers array was 8 long, but the
> compacted table of outPointers retains only two entries.  These get
> inserted in place of the #'s in the array of symbols after it is read
> back in.  Symbols with embedded spaces or other strange characters
> are written as strings, and converted back to symbols when read back
> in.  The symbol # is never written out.
> 	NOTE: All IdentitySets or dictionaries must be rehashed when
> being read back from this format.  The symbols are effectively
> internal.  (No, not if read back into same image.  If a different
> image, then use #imported.  -tk)
>
> #imported
> The segment is on an external file or just read in from one.  The
> segment and outPointers are meant to be read into a foreign image.
> In this form, the image segment can be read from a URL, and
> installed.  A copy of the original array of root objects is
> constructed, with former outPointers bound to existing objects in the
> host system.
> 	(Any Class inside the segment MUST be in the arrayOfRoots.
> This is so its association can be inserted into Smalltalk.  The
> class's metaclass must be in roots also.  Methods that are in
> outPointers because blocks point at them, were found and added to the
> roots.
> 	All IdentitySets and dictionaries are rehashed when being
> read back from exported segments.)
>
>
> To discover why only some of the objects in a project are being
> written out, try this (***Destructive Test***).  This breaks lots of
> backpointers in the target project, and puts up an array of
> suspicious objects, a list of the classes of the outPointers, and a
> debugger.
> "Close any transcripts in the target project"
> World currentHand objectToPaste ifNotNil: [
> 	self inform: 'Hand is holding a Morph in its paste buffer:\' withCRs,
> 		World currentHand objectToPaste printString].
> PV := Project named: 'xxxx'.
> (IS := ImageSegment new) findRogueRootsImSeg:
> 	(Array with: PV world presenter with: PV world).
> IS findOwnersOutPtrs.	"Optionally: write a file with owner chains"
> "Quit and DO NOT save"
>
> When an export image segment is brought into an image, it is like an
> image starting up.  Certain startUp messages need to be run.  These
> are byte and word reversals for nonPointer data that comes from a
> machine of the opposite endianness.  #startUpProc passes over all
> objects in the segment, and:
> 	The first time an instance of class X is encountered, (msg _
> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
> case, it means that instances of X do not need special work.  X is
> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
> store it in the dictionary, startUps (aClass -> aMessage).
> 	When a later instance of X is encountered, if X is in
> noStartUpNeeded, do nothing.  If X is in startUps, send the message
> to the instance.  Typically this is a message like #swapShortObjects.
> 	Every class that implements #startUp, should see if it needs
> a parallel implementation of #startUpFrom:.
>
> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>> I don't see image segments in Cuis... I don't even know if they still
>> exist
>> in Squeak... Anyone is still using it?
>>
>> It would be cool to have it at least as a package. If I remember
>> correctly
>> it was very simple, like two primitives to load and save, but I think it
>> depended on something like mark and sweep or some particular kind of
>> garbage collector and it might not work in new VMs.
>>
>



From luchiano at gmail.com  Thu Nov 26 08:10:21 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Thu, 26 Nov 2015 14:10:21 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
Message-ID: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>

Cool, maybe it's possible to make it into a package, I'll take a look.

I've never used it to store Projects, tho..  I used before to store things
that must be loaded very fast on demand and can be forgotten once there are
no more references to them.. like image fragments that compose a map of the
world, and small sound fragments that are used to synthesize speech
(diphones). Yesterday I just wanted to know how big are my objects, and I
wanted to make some experiments to see how the bit-size of my objects grow
as the problems I'm modeling grow by some other measure (degree of
polynomials, size of matrices are the most basic) and to know how much
memory are my algorithms actually using at every step... image segments are
ideal for this, you can use them to know exactly how much memory would be
freed if a reference to a given object were forgotten.


On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> Squeak 5.0 still has ImageSegments (class comment below). Saving and
> loading of  projects currently is blocked in Squeak because of an
> unfinished name space (environments implementation).
>
> http://wiki.squeak.org/squeak/6218
>
> And there is Fuel
> http://rmod.inria.fr/web/software/Fuel
>
> ----------
>
> ImageSegment
>
> I represent a segment of Squeak address space.  I am created from an
> array of root objects.  After storing, my segment contains a binary
> encoding of every object accessible from my roots but not otherwise
> accessible from anywhere else in the system.  My segment contains
> outward pointers that are indices into my table of outPointers.
> On load my segment is converted back into objects and becommed
> into an Array of the loaded objects, so they can be enumerated.
>
>         The main use of ImageSegments is to store Projects.  A dummy
> version of SmartRefStream traverses the Project.  Everything it finds
> is classified as either an object that is owned by the project (only
> pointed to inside the project), or an object outside the project that
> is pointed to from inside the project.  The objects that are
> completely owned by the project are compressed into pure binary form
> in an ImageSegment.  The outside objects are put in the 'outPointers'
> array.  The entire ImageSegment (binary part plus outPointers) is
> encoded in a SmartRefStream, and saved on the disk.  (aProject
> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
> writeForExportWithSources:inDirectory:changeSet:).
>
>         Note that every object inside the project is put into the
> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
> scan the project, in order to make intelligent decisions about what
> belongs in the project.
>         See Project's class comment for what messages are sent to
> objects as they are unpacked in a new image.
>
> ---- Older Details ------
>
>         The primary kind of image segment is an Export Segment.  It
> can be saved on a server and read into a completely different Squeak
> image.
> Old way to create one:
> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
> class))
>                 writeForExport: 'myFile.extSeg'.
> Old way to create one for a project:
>         (Project named: 'Play With Me - 3') exportSegment.
> To read it into another image:  Select 'myFile.extSeg' in a FileList,
> Menu 'load as project'.  It will install its classes automatically.
> If you need to see the roots array, it is temporarily stored in
> (SmartRefStream scannedObject).
>
> Most of 'states' of an ImageSegment are not used to export a project,
> and have been abandoned.
>
>         When a segment is written out onto a file, it goes in a
> folder called <image name>_segs.  If your image is called
> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
> image whenever your move, copy, or rename it.
>         Whenever a Class is in arrayOfRoots, its class (aClass class)
> must also be in the arrayOfRoots.
>         There are two kinds of image segments.  Normal image segments
> are a piece of a specific Squeak image, and can only be read back
> into that image.  The image holds the array of outPointers that are
> necessary to turn the bits in the file into objects.
>         To put out a normal segment that holds a Project (not the
> current project), execute (Project named: 'xxx') storeSegment.
>
>
> arrayOfRoots    The objects that head the tree we will trace.
> segment                 The WordArray of raw bits of all objects in the
> tree.
> outPointers             Oops of all objects outside the segment
> pointed to from inside.
> state                   (see below)
> segmentName     Its basic name.  Often the name of a Project.
> fileName                The local name of the file.  'Foo-23.seg'
> userRootCnt             number of roots submitted by caller.  Extras
> are added in preparation for saving.
>
> state that an ImageSegment may exist in...
>
> #activeCopy                     (has been copied, with the intent to
> become active)
> arrayOfRoots, segment, and outPointers have been created by
> copyFromRoots:.  The tree of objects has been encoded in the segment,
> but those objects are still present in the Squeak system.
>
> #active                         (segment is actively holding objects)
> The segment is now the only holder of tree of objects.  Each of the
> original roots has been transmuted into an ImageSegmentRootStub that
> refers back to this image segment.  The original objects in the
> segment will all be garbageCollected.
>
> #onFile
> The segment has been written out to a file and replaced by a file
> pointer.  Only ImageSegmentRootStubs and the array of outPointers
> remains in the image.  To get this far:
> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>                 writeToFile: 'myFile.seg'.
>
> #inactive
> The segment has been brought back into memory and turned back into
> objects.  rootsArray is set, but the segment is invalid.
>
> #onFileWithSymbols
> The segment has been written out to a file, along with the text of
> all the symbols in the outPointers array, and replaced by a file
> pointer.  This reduces the size of the outPointers array, and also
> allows the system to reclaim any symbols that are not referred to
> from elsewhere in the image.  The specific format used is that of a
> literal array as follows:
>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' # symbol5).
> In this case, the original outPointers array was 8 long, but the
> compacted table of outPointers retains only two entries.  These get
> inserted in place of the #'s in the array of symbols after it is read
> back in.  Symbols with embedded spaces or other strange characters
> are written as strings, and converted back to symbols when read back
> in.  The symbol # is never written out.
>         NOTE: All IdentitySets or dictionaries must be rehashed when
> being read back from this format.  The symbols are effectively
> internal.  (No, not if read back into same image.  If a different
> image, then use #imported.  -tk)
>
> #imported
> The segment is on an external file or just read in from one.  The
> segment and outPointers are meant to be read into a foreign image.
> In this form, the image segment can be read from a URL, and
> installed.  A copy of the original array of root objects is
> constructed, with former outPointers bound to existing objects in the
> host system.
>         (Any Class inside the segment MUST be in the arrayOfRoots.
> This is so its association can be inserted into Smalltalk.  The
> class's metaclass must be in roots also.  Methods that are in
> outPointers because blocks point at them, were found and added to the
> roots.
>         All IdentitySets and dictionaries are rehashed when being
> read back from exported segments.)
>
>
> To discover why only some of the objects in a project are being
> written out, try this (***Destructive Test***).  This breaks lots of
> backpointers in the target project, and puts up an array of
> suspicious objects, a list of the classes of the outPointers, and a
> debugger.
> "Close any transcripts in the target project"
> World currentHand objectToPaste ifNotNil: [
>         self inform: 'Hand is holding a Morph in its paste buffer:\'
> withCRs,
>                 World currentHand objectToPaste printString].
> PV := Project named: 'xxxx'.
> (IS := ImageSegment new) findRogueRootsImSeg:
>         (Array with: PV world presenter with: PV world).
> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
> "Quit and DO NOT save"
>
> When an export image segment is brought into an image, it is like an
> image starting up.  Certain startUp messages need to be run.  These
> are byte and word reversals for nonPointer data that comes from a
> machine of the opposite endianness.  #startUpProc passes over all
> objects in the segment, and:
>         The first time an instance of class X is encountered, (msg _
> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
> case, it means that instances of X do not need special work.  X is
> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
> store it in the dictionary, startUps (aClass -> aMessage).
>         When a later instance of X is encountered, if X is in
> noStartUpNeeded, do nothing.  If X is in startUps, send the message
> to the instance.  Typically this is a message like #swapShortObjects.
>         Every class that implements #startUp, should see if it needs
> a parallel implementation of #startUpFrom:.
>
> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> > I don't see image segments in Cuis... I don't even know if they still
> exist
> > in Squeak... Anyone is still using it?
> >
> > It would be cool to have it at least as a package. If I remember
> correctly
> > it was very simple, like two primitives to load and save, but I think it
> > depended on something like mark and sweep or some particular kind of
> > garbage collector and it might not work in new VMs.
> >
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151126/f896ab80/attachment-0003.html>

From hannes.hirzel at gmail.com  Thu Nov 26 09:16:29 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 16:16:29 +0100
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
Message-ID: <CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>

That's interesting,

see also http://wiki.squeak.org/squeak/2316 with a reference to an
article evaluation ImageSegments at the end.



On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> Cool, maybe it's possible to make it into a package, I'll take a look.
>
> I've never used it to store Projects, tho..  I used before to store things
> that must be loaded very fast on demand and can be forgotten once there are
> no more references to them.. like image fragments that compose a map of the
> world, and small sound fragments that are used to synthesize speech
> (diphones). Yesterday I just wanted to know how big are my objects, and I
> wanted to make some experiments to see how the bit-size of my objects grow
> as the problems I'm modeling grow by some other measure (degree of
> polynomials, size of matrices are the most basic) and to know how much
> memory are my algorithms actually using at every step... image segments are
> ideal for this, you can use them to know exactly how much memory would be
> freed if a reference to a given object were forgotten.
>
>
> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>
>> Squeak 5.0 still has ImageSegments (class comment below). Saving and
>> loading of  projects currently is blocked in Squeak because of an
>> unfinished name space (environments implementation).
>>
>> http://wiki.squeak.org/squeak/6218
>>
>> And there is Fuel
>> http://rmod.inria.fr/web/software/Fuel
>>
>> ----------
>>
>> ImageSegment
>>
>> I represent a segment of Squeak address space.  I am created from an
>> array of root objects.  After storing, my segment contains a binary
>> encoding of every object accessible from my roots but not otherwise
>> accessible from anywhere else in the system.  My segment contains
>> outward pointers that are indices into my table of outPointers.
>> On load my segment is converted back into objects and becommed
>> into an Array of the loaded objects, so they can be enumerated.
>>
>>         The main use of ImageSegments is to store Projects.  A dummy
>> version of SmartRefStream traverses the Project.  Everything it finds
>> is classified as either an object that is owned by the project (only
>> pointed to inside the project), or an object outside the project that
>> is pointed to from inside the project.  The objects that are
>> completely owned by the project are compressed into pure binary form
>> in an ImageSegment.  The outside objects are put in the 'outPointers'
>> array.  The entire ImageSegment (binary part plus outPointers) is
>> encoded in a SmartRefStream, and saved on the disk.  (aProject
>> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
>> writeForExportWithSources:inDirectory:changeSet:).
>>
>>         Note that every object inside the project is put into the
>> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
>> scan the project, in order to make intelligent decisions about what
>> belongs in the project.
>>         See Project's class comment for what messages are sent to
>> objects as they are unpacked in a new image.
>>
>> ---- Older Details ------
>>
>>         The primary kind of image segment is an Export Segment.  It
>> can be saved on a server and read into a completely different Squeak
>> image.
>> Old way to create one:
>> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
>> class))
>>                 writeForExport: 'myFile.extSeg'.
>> Old way to create one for a project:
>>         (Project named: 'Play With Me - 3') exportSegment.
>> To read it into another image:  Select 'myFile.extSeg' in a FileList,
>> Menu 'load as project'.  It will install its classes automatically.
>> If you need to see the roots array, it is temporarily stored in
>> (SmartRefStream scannedObject).
>>
>> Most of 'states' of an ImageSegment are not used to export a project,
>> and have been abandoned.
>>
>>         When a segment is written out onto a file, it goes in a
>> folder called <image name>_segs.  If your image is called
>> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
>> image whenever your move, copy, or rename it.
>>         Whenever a Class is in arrayOfRoots, its class (aClass class)
>> must also be in the arrayOfRoots.
>>         There are two kinds of image segments.  Normal image segments
>> are a piece of a specific Squeak image, and can only be read back
>> into that image.  The image holds the array of outPointers that are
>> necessary to turn the bits in the file into objects.
>>         To put out a normal segment that holds a Project (not the
>> current project), execute (Project named: 'xxx') storeSegment.
>>
>>
>> arrayOfRoots    The objects that head the tree we will trace.
>> segment                 The WordArray of raw bits of all objects in the
>> tree.
>> outPointers             Oops of all objects outside the segment
>> pointed to from inside.
>> state                   (see below)
>> segmentName     Its basic name.  Often the name of a Project.
>> fileName                The local name of the file.  'Foo-23.seg'
>> userRootCnt             number of roots submitted by caller.  Extras
>> are added in preparation for saving.
>>
>> state that an ImageSegment may exist in...
>>
>> #activeCopy                     (has been copied, with the intent to
>> become active)
>> arrayOfRoots, segment, and outPointers have been created by
>> copyFromRoots:.  The tree of objects has been encoded in the segment,
>> but those objects are still present in the Squeak system.
>>
>> #active                         (segment is actively holding objects)
>> The segment is now the only holder of tree of objects.  Each of the
>> original roots has been transmuted into an ImageSegmentRootStub that
>> refers back to this image segment.  The original objects in the
>> segment will all be garbageCollected.
>>
>> #onFile
>> The segment has been written out to a file and replaced by a file
>> pointer.  Only ImageSegmentRootStubs and the array of outPointers
>> remains in the image.  To get this far:
>> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>>                 writeToFile: 'myFile.seg'.
>>
>> #inactive
>> The segment has been brought back into memory and turned back into
>> objects.  rootsArray is set, but the segment is invalid.
>>
>> #onFileWithSymbols
>> The segment has been written out to a file, along with the text of
>> all the symbols in the outPointers array, and replaced by a file
>> pointer.  This reduces the size of the outPointers array, and also
>> allows the system to reclaim any symbols that are not referred to
>> from elsewhere in the image.  The specific format used is that of a
>> literal array as follows:
>>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
>> symbol5).
>> In this case, the original outPointers array was 8 long, but the
>> compacted table of outPointers retains only two entries.  These get
>> inserted in place of the #'s in the array of symbols after it is read
>> back in.  Symbols with embedded spaces or other strange characters
>> are written as strings, and converted back to symbols when read back
>> in.  The symbol # is never written out.
>>         NOTE: All IdentitySets or dictionaries must be rehashed when
>> being read back from this format.  The symbols are effectively
>> internal.  (No, not if read back into same image.  If a different
>> image, then use #imported.  -tk)
>>
>> #imported
>> The segment is on an external file or just read in from one.  The
>> segment and outPointers are meant to be read into a foreign image.
>> In this form, the image segment can be read from a URL, and
>> installed.  A copy of the original array of root objects is
>> constructed, with former outPointers bound to existing objects in the
>> host system.
>>         (Any Class inside the segment MUST be in the arrayOfRoots.
>> This is so its association can be inserted into Smalltalk.  The
>> class's metaclass must be in roots also.  Methods that are in
>> outPointers because blocks point at them, were found and added to the
>> roots.
>>         All IdentitySets and dictionaries are rehashed when being
>> read back from exported segments.)
>>
>>
>> To discover why only some of the objects in a project are being
>> written out, try this (***Destructive Test***).  This breaks lots of
>> backpointers in the target project, and puts up an array of
>> suspicious objects, a list of the classes of the outPointers, and a
>> debugger.
>> "Close any transcripts in the target project"
>> World currentHand objectToPaste ifNotNil: [
>>         self inform: 'Hand is holding a Morph in its paste buffer:\'
>> withCRs,
>>                 World currentHand objectToPaste printString].
>> PV := Project named: 'xxxx'.
>> (IS := ImageSegment new) findRogueRootsImSeg:
>>         (Array with: PV world presenter with: PV world).
>> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
>> "Quit and DO NOT save"
>>
>> When an export image segment is brought into an image, it is like an
>> image starting up.  Certain startUp messages need to be run.  These
>> are byte and word reversals for nonPointer data that comes from a
>> machine of the opposite endianness.  #startUpProc passes over all
>> objects in the segment, and:
>>         The first time an instance of class X is encountered, (msg _
>> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
>> case, it means that instances of X do not need special work.  X is
>> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
>> store it in the dictionary, startUps (aClass -> aMessage).
>>         When a later instance of X is encountered, if X is in
>> noStartUpNeeded, do nothing.  If X is in startUps, send the message
>> to the instance.  Typically this is a message like #swapShortObjects.
>>         Every class that implements #startUp, should see if it needs
>> a parallel implementation of #startUpFrom:.
>>
>> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>> > I don't see image segments in Cuis... I don't even know if they still
>> exist
>> > in Squeak... Anyone is still using it?
>> >
>> > It would be cool to have it at least as a package. If I remember
>> correctly
>> > it was very simple, like two primitives to load and save, but I think
>> > it
>> > depended on something like mark and sweep or some particular kind of
>> > garbage collector and it might not work in new VMs.
>> >
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>



From hannes.hirzel at gmail.com  Thu Nov 26 09:23:30 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 16:23:30 +0100
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
	<CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>
Message-ID: <CAGQxfVh3QvPc1=uzOTGQA3GYX5gca2gpJJMezf_NZqbFf1mOnw@mail.gmail.com>

And this seems to cover what you want to do

How to use an ImageSegment to determine memory usage
http://wiki.squeak.org/squeak/1260



On 11/26/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> That's interesting,
>
> see also http://wiki.squeak.org/squeak/2316 with a reference to an
> article evaluation ImageSegments at the end.
>
>
>
> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>> Cool, maybe it's possible to make it into a package, I'll take a look.
>>
>> I've never used it to store Projects, tho..  I used before to store
>> things
>> that must be loaded very fast on demand and can be forgotten once there
>> are
>> no more references to them.. like image fragments that compose a map of
>> the
>> world, and small sound fragments that are used to synthesize speech
>> (diphones). Yesterday I just wanted to know how big are my objects, and I
>> wanted to make some experiments to see how the bit-size of my objects
>> grow
>> as the problems I'm modeling grow by some other measure (degree of
>> polynomials, size of matrices are the most basic) and to know how much
>> memory are my algorithms actually using at every step... image segments
>> are
>> ideal for this, you can use them to know exactly how much memory would be
>> freed if a reference to a given object were forgotten.
>>
>>
>> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com>
>> wrote:
>>
>>> Squeak 5.0 still has ImageSegments (class comment below). Saving and
>>> loading of  projects currently is blocked in Squeak because of an
>>> unfinished name space (environments implementation).
>>>
>>> http://wiki.squeak.org/squeak/6218
>>>
>>> And there is Fuel
>>> http://rmod.inria.fr/web/software/Fuel
>>>
>>> ----------
>>>
>>> ImageSegment
>>>
>>> I represent a segment of Squeak address space.  I am created from an
>>> array of root objects.  After storing, my segment contains a binary
>>> encoding of every object accessible from my roots but not otherwise
>>> accessible from anywhere else in the system.  My segment contains
>>> outward pointers that are indices into my table of outPointers.
>>> On load my segment is converted back into objects and becommed
>>> into an Array of the loaded objects, so they can be enumerated.
>>>
>>>         The main use of ImageSegments is to store Projects.  A dummy
>>> version of SmartRefStream traverses the Project.  Everything it finds
>>> is classified as either an object that is owned by the project (only
>>> pointed to inside the project), or an object outside the project that
>>> is pointed to from inside the project.  The objects that are
>>> completely owned by the project are compressed into pure binary form
>>> in an ImageSegment.  The outside objects are put in the 'outPointers'
>>> array.  The entire ImageSegment (binary part plus outPointers) is
>>> encoded in a SmartRefStream, and saved on the disk.  (aProject
>>> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
>>> writeForExportWithSources:inDirectory:changeSet:).
>>>
>>>         Note that every object inside the project is put into the
>>> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
>>> scan the project, in order to make intelligent decisions about what
>>> belongs in the project.
>>>         See Project's class comment for what messages are sent to
>>> objects as they are unpacked in a new image.
>>>
>>> ---- Older Details ------
>>>
>>>         The primary kind of image segment is an Export Segment.  It
>>> can be saved on a server and read into a completely different Squeak
>>> image.
>>> Old way to create one:
>>> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
>>> class))
>>>                 writeForExport: 'myFile.extSeg'.
>>> Old way to create one for a project:
>>>         (Project named: 'Play With Me - 3') exportSegment.
>>> To read it into another image:  Select 'myFile.extSeg' in a FileList,
>>> Menu 'load as project'.  It will install its classes automatically.
>>> If you need to see the roots array, it is temporarily stored in
>>> (SmartRefStream scannedObject).
>>>
>>> Most of 'states' of an ImageSegment are not used to export a project,
>>> and have been abandoned.
>>>
>>>         When a segment is written out onto a file, it goes in a
>>> folder called <image name>_segs.  If your image is called
>>> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
>>> image whenever your move, copy, or rename it.
>>>         Whenever a Class is in arrayOfRoots, its class (aClass class)
>>> must also be in the arrayOfRoots.
>>>         There are two kinds of image segments.  Normal image segments
>>> are a piece of a specific Squeak image, and can only be read back
>>> into that image.  The image holds the array of outPointers that are
>>> necessary to turn the bits in the file into objects.
>>>         To put out a normal segment that holds a Project (not the
>>> current project), execute (Project named: 'xxx') storeSegment.
>>>
>>>
>>> arrayOfRoots    The objects that head the tree we will trace.
>>> segment                 The WordArray of raw bits of all objects in the
>>> tree.
>>> outPointers             Oops of all objects outside the segment
>>> pointed to from inside.
>>> state                   (see below)
>>> segmentName     Its basic name.  Often the name of a Project.
>>> fileName                The local name of the file.  'Foo-23.seg'
>>> userRootCnt             number of roots submitted by caller.  Extras
>>> are added in preparation for saving.
>>>
>>> state that an ImageSegment may exist in...
>>>
>>> #activeCopy                     (has been copied, with the intent to
>>> become active)
>>> arrayOfRoots, segment, and outPointers have been created by
>>> copyFromRoots:.  The tree of objects has been encoded in the segment,
>>> but those objects are still present in the Squeak system.
>>>
>>> #active                         (segment is actively holding objects)
>>> The segment is now the only holder of tree of objects.  Each of the
>>> original roots has been transmuted into an ImageSegmentRootStub that
>>> refers back to this image segment.  The original objects in the
>>> segment will all be garbageCollected.
>>>
>>> #onFile
>>> The segment has been written out to a file and replaced by a file
>>> pointer.  Only ImageSegmentRootStubs and the array of outPointers
>>> remains in the image.  To get this far:
>>> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>>>                 writeToFile: 'myFile.seg'.
>>>
>>> #inactive
>>> The segment has been brought back into memory and turned back into
>>> objects.  rootsArray is set, but the segment is invalid.
>>>
>>> #onFileWithSymbols
>>> The segment has been written out to a file, along with the text of
>>> all the symbols in the outPointers array, and replaced by a file
>>> pointer.  This reduces the size of the outPointers array, and also
>>> allows the system to reclaim any symbols that are not referred to
>>> from elsewhere in the image.  The specific format used is that of a
>>> literal array as follows:
>>>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
>>> symbol5).
>>> In this case, the original outPointers array was 8 long, but the
>>> compacted table of outPointers retains only two entries.  These get
>>> inserted in place of the #'s in the array of symbols after it is read
>>> back in.  Symbols with embedded spaces or other strange characters
>>> are written as strings, and converted back to symbols when read back
>>> in.  The symbol # is never written out.
>>>         NOTE: All IdentitySets or dictionaries must be rehashed when
>>> being read back from this format.  The symbols are effectively
>>> internal.  (No, not if read back into same image.  If a different
>>> image, then use #imported.  -tk)
>>>
>>> #imported
>>> The segment is on an external file or just read in from one.  The
>>> segment and outPointers are meant to be read into a foreign image.
>>> In this form, the image segment can be read from a URL, and
>>> installed.  A copy of the original array of root objects is
>>> constructed, with former outPointers bound to existing objects in the
>>> host system.
>>>         (Any Class inside the segment MUST be in the arrayOfRoots.
>>> This is so its association can be inserted into Smalltalk.  The
>>> class's metaclass must be in roots also.  Methods that are in
>>> outPointers because blocks point at them, were found and added to the
>>> roots.
>>>         All IdentitySets and dictionaries are rehashed when being
>>> read back from exported segments.)
>>>
>>>
>>> To discover why only some of the objects in a project are being
>>> written out, try this (***Destructive Test***).  This breaks lots of
>>> backpointers in the target project, and puts up an array of
>>> suspicious objects, a list of the classes of the outPointers, and a
>>> debugger.
>>> "Close any transcripts in the target project"
>>> World currentHand objectToPaste ifNotNil: [
>>>         self inform: 'Hand is holding a Morph in its paste buffer:\'
>>> withCRs,
>>>                 World currentHand objectToPaste printString].
>>> PV := Project named: 'xxxx'.
>>> (IS := ImageSegment new) findRogueRootsImSeg:
>>>         (Array with: PV world presenter with: PV world).
>>> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
>>> "Quit and DO NOT save"
>>>
>>> When an export image segment is brought into an image, it is like an
>>> image starting up.  Certain startUp messages need to be run.  These
>>> are byte and word reversals for nonPointer data that comes from a
>>> machine of the opposite endianness.  #startUpProc passes over all
>>> objects in the segment, and:
>>>         The first time an instance of class X is encountered, (msg _
>>> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
>>> case, it means that instances of X do not need special work.  X is
>>> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
>>> store it in the dictionary, startUps (aClass -> aMessage).
>>>         When a later instance of X is encountered, if X is in
>>> noStartUpNeeded, do nothing.  If X is in startUps, send the message
>>> to the instance.  Typically this is a message like #swapShortObjects.
>>>         Every class that implements #startUp, should see if it needs
>>> a parallel implementation of #startUpFrom:.
>>>
>>> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>>> > I don't see image segments in Cuis... I don't even know if they still
>>> exist
>>> > in Squeak... Anyone is still using it?
>>> >
>>> > It would be cool to have it at least as a package. If I remember
>>> correctly
>>> > it was very simple, like two primitives to load and save, but I think
>>> > it
>>> > depended on something like mark and sweep or some particular kind of
>>> > garbage collector and it might not work in new VMs.
>>> >
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>
>



From luchiano at gmail.com  Thu Nov 26 09:31:24 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Thu, 26 Nov 2015 15:31:24 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVh3QvPc1=uzOTGQA3GYX5gca2gpJJMezf_NZqbFf1mOnw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
	<CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>
	<CAGQxfVh3QvPc1=uzOTGQA3GYX5gca2gpJJMezf_NZqbFf1mOnw@mail.gmail.com>
Message-ID: <CAL5GDyrDJy377VS=eFRfAUkvLzVaUex9na_6HJMWM17EgxP2mQ@mail.gmail.com>

Oh, yes, that's exactly what I wanted, awesome! Thanks!

On Thu, Nov 26, 2015 at 3:23 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> And this seems to cover what you want to do
>
> How to use an ImageSegment to determine memory usage
> http://wiki.squeak.org/squeak/1260
>
>
>
> On 11/26/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > That's interesting,
> >
> > see also http://wiki.squeak.org/squeak/2316 with a reference to an
> > article evaluation ImageSegments at the end.
> >
> >
> >
> > On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> >> Cool, maybe it's possible to make it into a package, I'll take a look.
> >>
> >> I've never used it to store Projects, tho..  I used before to store
> >> things
> >> that must be loaded very fast on demand and can be forgotten once there
> >> are
> >> no more references to them.. like image fragments that compose a map of
> >> the
> >> world, and small sound fragments that are used to synthesize speech
> >> (diphones). Yesterday I just wanted to know how big are my objects, and
> I
> >> wanted to make some experiments to see how the bit-size of my objects
> >> grow
> >> as the problems I'm modeling grow by some other measure (degree of
> >> polynomials, size of matrices are the most basic) and to know how much
> >> memory are my algorithms actually using at every step... image segments
> >> are
> >> ideal for this, you can use them to know exactly how much memory would
> be
> >> freed if a reference to a given object were forgotten.
> >>
> >>
> >> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com>
> >> wrote:
> >>
> >>> Squeak 5.0 still has ImageSegments (class comment below). Saving and
> >>> loading of  projects currently is blocked in Squeak because of an
> >>> unfinished name space (environments implementation).
> >>>
> >>> http://wiki.squeak.org/squeak/6218
> >>>
> >>> And there is Fuel
> >>> http://rmod.inria.fr/web/software/Fuel
> >>>
> >>> ----------
> >>>
> >>> ImageSegment
> >>>
> >>> I represent a segment of Squeak address space.  I am created from an
> >>> array of root objects.  After storing, my segment contains a binary
> >>> encoding of every object accessible from my roots but not otherwise
> >>> accessible from anywhere else in the system.  My segment contains
> >>> outward pointers that are indices into my table of outPointers.
> >>> On load my segment is converted back into objects and becommed
> >>> into an Array of the loaded objects, so they can be enumerated.
> >>>
> >>>         The main use of ImageSegments is to store Projects.  A dummy
> >>> version of SmartRefStream traverses the Project.  Everything it finds
> >>> is classified as either an object that is owned by the project (only
> >>> pointed to inside the project), or an object outside the project that
> >>> is pointed to from inside the project.  The objects that are
> >>> completely owned by the project are compressed into pure binary form
> >>> in an ImageSegment.  The outside objects are put in the 'outPointers'
> >>> array.  The entire ImageSegment (binary part plus outPointers) is
> >>> encoded in a SmartRefStream, and saved on the disk.  (aProject
> >>> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
> >>> writeForExportWithSources:inDirectory:changeSet:).
> >>>
> >>>         Note that every object inside the project is put into the
> >>> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
> >>> scan the project, in order to make intelligent decisions about what
> >>> belongs in the project.
> >>>         See Project's class comment for what messages are sent to
> >>> objects as they are unpacked in a new image.
> >>>
> >>> ---- Older Details ------
> >>>
> >>>         The primary kind of image segment is an Export Segment.  It
> >>> can be saved on a server and read into a completely different Squeak
> >>> image.
> >>> Old way to create one:
> >>> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
> >>> class))
> >>>                 writeForExport: 'myFile.extSeg'.
> >>> Old way to create one for a project:
> >>>         (Project named: 'Play With Me - 3') exportSegment.
> >>> To read it into another image:  Select 'myFile.extSeg' in a FileList,
> >>> Menu 'load as project'.  It will install its classes automatically.
> >>> If you need to see the roots array, it is temporarily stored in
> >>> (SmartRefStream scannedObject).
> >>>
> >>> Most of 'states' of an ImageSegment are not used to export a project,
> >>> and have been abandoned.
> >>>
> >>>         When a segment is written out onto a file, it goes in a
> >>> folder called <image name>_segs.  If your image is called
> >>> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
> >>> image whenever your move, copy, or rename it.
> >>>         Whenever a Class is in arrayOfRoots, its class (aClass class)
> >>> must also be in the arrayOfRoots.
> >>>         There are two kinds of image segments.  Normal image segments
> >>> are a piece of a specific Squeak image, and can only be read back
> >>> into that image.  The image holds the array of outPointers that are
> >>> necessary to turn the bits in the file into objects.
> >>>         To put out a normal segment that holds a Project (not the
> >>> current project), execute (Project named: 'xxx') storeSegment.
> >>>
> >>>
> >>> arrayOfRoots    The objects that head the tree we will trace.
> >>> segment                 The WordArray of raw bits of all objects in the
> >>> tree.
> >>> outPointers             Oops of all objects outside the segment
> >>> pointed to from inside.
> >>> state                   (see below)
> >>> segmentName     Its basic name.  Often the name of a Project.
> >>> fileName                The local name of the file.  'Foo-23.seg'
> >>> userRootCnt             number of roots submitted by caller.  Extras
> >>> are added in preparation for saving.
> >>>
> >>> state that an ImageSegment may exist in...
> >>>
> >>> #activeCopy                     (has been copied, with the intent to
> >>> become active)
> >>> arrayOfRoots, segment, and outPointers have been created by
> >>> copyFromRoots:.  The tree of objects has been encoded in the segment,
> >>> but those objects are still present in the Squeak system.
> >>>
> >>> #active                         (segment is actively holding objects)
> >>> The segment is now the only holder of tree of objects.  Each of the
> >>> original roots has been transmuted into an ImageSegmentRootStub that
> >>> refers back to this image segment.  The original objects in the
> >>> segment will all be garbageCollected.
> >>>
> >>> #onFile
> >>> The segment has been written out to a file and replaced by a file
> >>> pointer.  Only ImageSegmentRootStubs and the array of outPointers
> >>> remains in the image.  To get this far:
> >>> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
> >>>                 writeToFile: 'myFile.seg'.
> >>>
> >>> #inactive
> >>> The segment has been brought back into memory and turned back into
> >>> objects.  rootsArray is set, but the segment is invalid.
> >>>
> >>> #onFileWithSymbols
> >>> The segment has been written out to a file, along with the text of
> >>> all the symbols in the outPointers array, and replaced by a file
> >>> pointer.  This reduces the size of the outPointers array, and also
> >>> allows the system to reclaim any symbols that are not referred to
> >>> from elsewhere in the image.  The specific format used is that of a
> >>> literal array as follows:
> >>>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
> >>> symbol5).
> >>> In this case, the original outPointers array was 8 long, but the
> >>> compacted table of outPointers retains only two entries.  These get
> >>> inserted in place of the #'s in the array of symbols after it is read
> >>> back in.  Symbols with embedded spaces or other strange characters
> >>> are written as strings, and converted back to symbols when read back
> >>> in.  The symbol # is never written out.
> >>>         NOTE: All IdentitySets or dictionaries must be rehashed when
> >>> being read back from this format.  The symbols are effectively
> >>> internal.  (No, not if read back into same image.  If a different
> >>> image, then use #imported.  -tk)
> >>>
> >>> #imported
> >>> The segment is on an external file or just read in from one.  The
> >>> segment and outPointers are meant to be read into a foreign image.
> >>> In this form, the image segment can be read from a URL, and
> >>> installed.  A copy of the original array of root objects is
> >>> constructed, with former outPointers bound to existing objects in the
> >>> host system.
> >>>         (Any Class inside the segment MUST be in the arrayOfRoots.
> >>> This is so its association can be inserted into Smalltalk.  The
> >>> class's metaclass must be in roots also.  Methods that are in
> >>> outPointers because blocks point at them, were found and added to the
> >>> roots.
> >>>         All IdentitySets and dictionaries are rehashed when being
> >>> read back from exported segments.)
> >>>
> >>>
> >>> To discover why only some of the objects in a project are being
> >>> written out, try this (***Destructive Test***).  This breaks lots of
> >>> backpointers in the target project, and puts up an array of
> >>> suspicious objects, a list of the classes of the outPointers, and a
> >>> debugger.
> >>> "Close any transcripts in the target project"
> >>> World currentHand objectToPaste ifNotNil: [
> >>>         self inform: 'Hand is holding a Morph in its paste buffer:\'
> >>> withCRs,
> >>>                 World currentHand objectToPaste printString].
> >>> PV := Project named: 'xxxx'.
> >>> (IS := ImageSegment new) findRogueRootsImSeg:
> >>>         (Array with: PV world presenter with: PV world).
> >>> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
> >>> "Quit and DO NOT save"
> >>>
> >>> When an export image segment is brought into an image, it is like an
> >>> image starting up.  Certain startUp messages need to be run.  These
> >>> are byte and word reversals for nonPointer data that comes from a
> >>> machine of the opposite endianness.  #startUpProc passes over all
> >>> objects in the segment, and:
> >>>         The first time an instance of class X is encountered, (msg _
> >>> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
> >>> case, it means that instances of X do not need special work.  X is
> >>> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
> >>> store it in the dictionary, startUps (aClass -> aMessage).
> >>>         When a later instance of X is encountered, if X is in
> >>> noStartUpNeeded, do nothing.  If X is in startUps, send the message
> >>> to the instance.  Typically this is a message like #swapShortObjects.
> >>>         Every class that implements #startUp, should see if it needs
> >>> a parallel implementation of #startUpFrom:.
> >>>
> >>> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> >>> > I don't see image segments in Cuis... I don't even know if they still
> >>> exist
> >>> > in Squeak... Anyone is still using it?
> >>> >
> >>> > It would be cool to have it at least as a package. If I remember
> >>> correctly
> >>> > it was very simple, like two primitives to load and save, but I think
> >>> > it
> >>> > depended on something like mark and sweep or some particular kind of
> >>> > garbage collector and it might not work in new VMs.
> >>> >
> >>>
> >>> _______________________________________________
> >>> Cuis mailing list
> >>> Cuis at jvuletich.org
> >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>>
> >>
> >
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151126/36cbae51/attachment-0003.html>

From Ken.Dickey at Whidbey.com  Thu Nov 26 10:43:56 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 26 Nov 2015 08:43:56 -0800
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
Message-ID: <20151126084356.9c4d2d0cd3817291d42a099e@Whidbey.com>

On Thu, 26 Nov 2015 14:10:21 +0000
Luciano Notarfrancesco <luchiano at gmail.com> wrote:

> Cool, maybe it's possible to make it into a package, I'll take a look.

Note that image segments are stored in a binary format that is dependent on the VM.

In other words an image segment saved in 4.x (pre-Spur) will not be loadable in 5.x (Spur).

I have not looked, but one might do better to port Fuel.

$0.02,
-KenD



From edgardec2005 at gmail.com  Thu Nov 26 11:27:58 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Thu, 26 Nov 2015 14:27:58 -0300
Subject: [Cuis] image segments
In-Reply-To: <20151126084356.9c4d2d0cd3817291d42a099e@Whidbey.com>
Message-ID: <D27CC76E.172AA%edgardec2005@gmail.com>




On 11/26/15, 1:43 PM, "KenD" <Ken.Dickey at Whidbey.com> wrote:

> I have not looked, but one might do better to port Fuel.

+1 A good look of Fuel 





From euanmee at gmail.com  Thu Nov 26 19:46:59 2015
From: euanmee at gmail.com (EuanM)
Date: Fri, 27 Nov 2015 01:46:59 +0000
Subject: [Cuis] Cuis Logo
Message-ID: <CALsRT0neHMUA5WagyEDVuatfCm6=7Ky0KnMKTSxd7_CTHDqGXg@mail.gmail.com>

I'm preparing a slideshow on what's good and cool in the Smalltalk world(s) atm.

I want to include Cuis.

I'm not aware of any official or semi-official logo.

I'm not even sure of the derivation or meaning of "Cuis".

Could someone point me to a logo, if there is one?

Could someone tell me more about why the project is called "Cuis"?
(And if there is nothing atm, I'll produce a logo that ties in to
that)

Cheers,
    Euan



From edgardec2005 at gmail.com  Fri Nov 27 04:26:15 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Fri, 27 Nov 2015 07:26:15 -0300
Subject: [Cuis] Cuis Logo
In-Reply-To: <CALsRT0neHMUA5WagyEDVuatfCm6=7Ky0KnMKTSxd7_CTHDqGXg@mail.gmail.com>
Message-ID: <D27DB617.172C3%edgardec2005@gmail.com>




On 11/26/15, 10:46 PM, "EuanM" <euanmee at gmail.com> wrote:

> I'm preparing a slideshow on what's good and cool in the Smalltalk world(s)
> atm.
> 
> I want to include Cuis.
> 
> I'm not aware of any official or semi-official logo.
> 
> I'm not even sure of the derivation or meaning of "Cuis".
> 
> Could someone point me to a logo, if there is one?
> 
> Could someone tell me more about why the project is called "Cuis"?
> (And if there is nothing atm, I'll produce a logo that ties in to
> that)
> 
> Cheers,
>     Euan
https://en.wikipedia.org/wiki/Southern_mountain_cavy (Microcavia australis)
Cuis

So is a rodent living in Argentina.
Very common, you do not need to far of mayor cities to found it to side of
roads 

Maybe a styli shed photo ?

Edgar





From avalloud at smalltalk.comcastbiz.net  Fri Nov 27 09:21:45 2015
From: avalloud at smalltalk.comcastbiz.net (Andres Valloud)
Date: Fri, 27 Nov 2015 07:21:45 -0800
Subject: [Cuis] New updates
In-Reply-To: <CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>
References: <56530DC3.3040609@jvuletich.org>
	<CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>
Message-ID: <56587509.2020202@smalltalk.comcastbiz.net>

Hello,

The fixes to exceptions are about solving subtle misbehaviors with the 
messages #pass, #outer, and #resignalAs:.  Generally speaking, the main 
issue was that the correct handler block wouldn't be found.  Thus, for 
example, sending the message #pass would fail to find a default handler. 
  I found these types of issues while porting Assessments (more on 
Assessments below), because it uses #pass to track exceptions, and 
#resignalAs: to remap other exceptions into exceptions Assessments 
understands.  Correct nested execution of #pass required a stack of 
handler contexts, thus now exceptions keep an ordered collection of 
handler contexts rather than just the topmost handler.  Surely this is 
not the only way this can be done.

Assessments is a testing framework specifically designed with 
collaboration in mind.  I had been making SUnit extensions since 2001, 
and eventually I realized sharing such extensions and improvements with 
other SUnit users would be fundamentally obstructed.  SUnit's design is 
such that one has to change the framework itself in order to extend its 
behavior.  Thus, what I change in my image does not necessarily have to 
work in someone else's image, and vice versa.  As a result, most SUnit 
users end up implementing extensions such as file logging or more 
extensive result reporting, and those extensions are incompatible with 
each other.

Instead, Assessments is built around the principle that the testing 
framework's behavior and extensibility should rely on object composition 
rather than subclassing.  In addition, a few critical objects are now 
reified explicitly.  Chief among them is the Assessment (the "test 
suite"), with its evaluation context (no parallel).  The key is that the 
evaluation context of an assessment can change how tests are executed, 
how results are collected, and so on.  Since this is done by object 
composition, it's trivial to e.g. set up an assessment to report results 
to multiple files and to the GUI without changing Assessments itself. 
As a result, extensions can be shared without the threat of immediate 
incompatibility.

But what about pre-existing SUnit tests?  Well surely a new testing 
framework built around collaboration wouldn't immediately obsolete the 
enormous body of SUnit tests out there, or force a migration because NIH 
or something like that.  And that's exactly what Assessments 
accomplishes.  Since there is an evaluation context object, an 
assessment ("test suite") can specify which execution policy goes for 
which check ("test").  Assessments uses this flexibility to execute 
SUnit tests in situ, as if SUnit itself was running them.  Unlike other 
solutions deployed to solve this problem, Assessments does not require 
modifications to existing code.  Loading Assessments is effectively 
invisible to existing SUnit code.

The end result is that the Assessments checklist evaluator (the "test 
runner") displays both SUnit tests and native Assessments tests, and one 
assessment object can execute both types together.

In addiiton, Assessments provides a clean, native implementation of 
SUnit Validation (also known as "Extreme Validation"), as well as SUnit 
Benchmarks.  Both of these are implemented in terms of Assessments 
checklists.  Briefly, validation involves using tests to verify e.g. 
business objects at run time.  A typical application of validation would 
be data entry verification.  The Benchmarks is another application of 
tests, where each test measures the time needed to execute some code. 
In addition, Benchmarks can enforce that some code runs within a certain 
amount of time.  An interesting detail is that the required time is 
specified in "message send" units, rather than time.  Thus, the 
benchmarks do not become obsolete or inappropriate depending on the 
speed of the machine where the measurements are taken.

For more information, the Assessments package contains more detailed 
comments as well as links to additional detail.  I originally presented 
Assessments at ESUG 2008, the video of the talk is online here (and 
other places):

https://vimeo.com/1945494

There are also some notes on validation here:

http://csl.ensm-douai.fr/Esug2007Media/uploads/1/Extreme.pdf

There is also a paper by Leandro Caniglia titled "Extreme Validation", 
which unfortunately I couldn't immediately find in Google.  But I image 
I can get a copy and put it online somewhere.

Andres.

On 11/23/15 7:35 , Luciano Notarfrancesco wrote:
> Hi all,
> About my recent changes, some of them are 1) extensions to Theme to be
> able to customize some more aspects of how the windows and widgets look,
> or 2) fixes for small bugs that I found on the way, like misalignments
> of a few pixels between parts of a widget or a window. The motivation
> behind this was just to be able to implement a very minimalist look
> (borders of just 1 pixel, no decorations, no icons, no anything that I
> dont need and takes up screen real estate), and a sort of tiling dynamic
> window manager very much like http://dwm.suckless.org
> (https://github.com/len/Cuis-Smalltalk-DWM).
>
> In order to implement this "window manager" as an external package with
> minimal changes to the core system, I decided to: 1) make the current
> Theme receive messages #windowOpen: #windowClosed: every time
> SystemWindows are open or closed, in order to give it a chance to
> implement window-management behaviour or delegate it to a proper window
> manager; 2) move the window-management keyboard shortcuts (like alt-w to
> close) to Theme, so it is all in one place, easy to change, and easy to
> make a Theme that delegates keyboard events to a proper window manager.
>
> Again I did it like this in order to minimize changes to the core
> system. At the moment window management is in part implemented in
> SystemWindow, and also in HandMorph and Morph. I had to make some small
> modifications in order to get the desired behavior when using DWM, and
> keep the original behavior in the base system. Maybe in the long run we
> would want to have a WindowManager class that do this, handle keyboard
> events for the window-management shortcuts and receives #windowOpen: and
> #windowClosed:, etc. But I would like to think better about this before
> adding new concepts and complexity to the core.
>
> Cheers,
> Luciano
>
>
> On Mon, Nov 23, 2015 at 12:59 PM, Juan Vuletich <juan at jvuletich.org
> <mailto:juan at jvuletich.org>> wrote:
>
>     Hi all,
>
>     I recently included some new updates:
>
>     - Fixes to Exceptions by Andr?s Valloud and Martin McClure.
>     - Assessments framework for testing and validation by Andr?s Valloud.
>     - Many fixes and enhancements to Layouts, Window drawing, keyboard
>     shortcuts, etc. by Luciano Notarfrancesco
>
>     Thank you very much Folks! Andr?s, Luciano, please comment a bit on
>     what you did, especially subtle but important behavior such as
>     Exceptions and new stuff like Assessments, and the new Theme and
>     Window Manager.
>
>     Cheers,
>     Juan Vuletich
>
>     _______________________________________________
>     Cuis mailing list
>     Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Fri Nov 27 13:50:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 27 Nov 2015 14:50:07 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <5658B3EF.24941.1584D0D@dnorton.mindspring.com>

Hi Juan,

Please include the latest when you build next time:

	https://github.com/dhnorton/Cuis-Smalltalk-comments

Changes:
	less redundancy in the list
	pick up trailing acronyms
	revised class comments

Thanks,
 - Dan



From euanmee at gmail.com  Fri Nov 27 14:19:05 2015
From: euanmee at gmail.com (EuanM)
Date: Fri, 27 Nov 2015 20:19:05 +0000
Subject: [Cuis] Cuis Logo
Message-ID: <CALsRT0k8oL4K0mqWuBTKi0+3cBqZ=cJZcQFZm4d1KSYkDhxj_A@mail.gmail.com>

My 0.0.3 release of a proposed interim Cuis logo is now online, on the
home page at:
http://smalltalk.uk.to/

My plan is to add it to the constellation of Smalltalk logos on the
slideshow I'm writing, until Juan and the community have a better
option.

Cheers,
    Euan


> On Fri, 27 Nov 2015 07:26:15 -0300, "Edgar J. De Cleene" wrote:

> On 11/26/15, 10:46 PM, "EuanM" <euanmee at gmail.com> wrote:
>
>> I'm preparing a slideshow on what's good and cool in the Smalltalk world(s)
>> atm.
>>
>> I want to include Cuis.
>>
>> I'm not aware of any official or semi-official logo.
>>
>> I'm not even sure of the derivation or meaning of "Cuis".
>>
>> Could someone point me to a logo, if there is one?
>>
>> Could someone tell me more about why the project is called "Cuis"?
>> (And if there is nothing atm, I'll produce a logo that ties in to
>> that)
>>
>> Cheers,
>>     Euan
> https://en.wikipedia.org/wiki/Southern_mountain_cavy (Microcavia australis)
> Cuis
>
> So is a rodent living in Argentina.
> Very common, you do not need to far of mayor cities to found it to side of
> roads
>
> Maybe a styli shed photo ?
>
> Edgar



From juan at jvuletich.org  Sat Nov 28 14:20:17 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:20:17 -0300
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
Message-ID: <565A0C81.9080702@jvuletich.org>

At some point in the development of Cuis I removed both Projects and 
ImageSegments. It shouldn't be hard to add them back, as an optional 
package.

WRT Fuel, it would be a great addition. If (as I believe) it already 
works on Squeak, besides Pharo, then it shouldn't be too hard to port to 
Cuis.

Cheers,
Juan Vuletich

On 26/11/2015 11:10 a.m., Luciano Notarfrancesco wrote:
> Cool, maybe it's possible to make it into a package, I'll take a look.
>
> I've never used it to store Projects, tho..  I used before to store 
> things that must be loaded very fast on demand and can be forgotten 
> once there are no more references to them.. like image fragments that 
> compose a map of the world, and small sound fragments that are used to 
> synthesize speech (diphones). Yesterday I just wanted to know how big 
> are my objects, and I wanted to make some experiments to see how the 
> bit-size of my objects grow as the problems I'm modeling grow by some 
> other measure (degree of polynomials, size of matrices are the most 
> basic) and to know how much memory are my algorithms actually using at 
> every step... image segments are ideal for this, you can use them to 
> know exactly how much memory would be freed if a reference to a given 
> object were forgotten.
>
>
> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com 
> <mailto:hannes.hirzel at gmail.com>> wrote:
>
>     Squeak 5.0 still has ImageSegments (class comment below). Saving and
>     loading of  projects currently is blocked in Squeak because of an
>     unfinished name space (environments implementation).
>
>     http://wiki.squeak.org/squeak/6218
>
>     And there is Fuel
>     http://rmod.inria.fr/web/software/Fuel
>
>     ----------
>
>     ImageSegment
>
>     I represent a segment of Squeak address space.  I am created from an
>     array of root objects.  After storing, my segment contains a binary
>     encoding of every object accessible from my roots but not otherwise
>     accessible from anywhere else in the system.  My segment contains
>     outward pointers that are indices into my table of outPointers.
>     On load my segment is converted back into objects and becommed
>     into an Array of the loaded objects, so they can be enumerated.
>
>             The main use of ImageSegments is to store Projects.  A dummy
>     version of SmartRefStream traverses the Project.  Everything it finds
>     is classified as either an object that is owned by the project (only
>     pointed to inside the project), or an object outside the project that
>     is pointed to from inside the project.  The objects that are
>     completely owned by the project are compressed into pure binary form
>     in an ImageSegment.  The outside objects are put in the 'outPointers'
>     array.  The entire ImageSegment (binary part plus outPointers) is
>     encoded in a SmartRefStream, and saved on the disk.  (aProject
>     exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
>     writeForExportWithSources:inDirectory:changeSet:).
>
>             Note that every object inside the project is put into the
>     segment's arrayOfRoots.  This is because a dummy SmartRefStream to
>     scan the project, in order to make intelligent decisions about what
>     belongs in the project.
>             See Project's class comment for what messages are sent to
>     objects as they are unpacked in a new image.
>
>     ---- Older Details ------
>
>             The primary kind of image segment is an Export Segment.  It
>     can be saved on a server and read into a completely different Squeak
>     image.
>     Old way to create one:
>     (ImageSegment new copyFromRootsForExport: (Array with: Baz with:
>     Baz class))
>                     writeForExport: 'myFile.extSeg'.
>     Old way to create one for a project:
>             (Project named: 'Play With Me - 3') exportSegment.
>     To read it into another image:  Select 'myFile.extSeg' in a FileList,
>     Menu 'load as project'.  It will install its classes automatically.
>     If you need to see the roots array, it is temporarily stored in
>     (SmartRefStream scannedObject).
>
>     Most of 'states' of an ImageSegment are not used to export a project,
>     and have been abandoned.
>
>             When a segment is written out onto a file, it goes in a
>     folder called <image name>_segs.  If your image is called
>     "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
>     image whenever your move, copy, or rename it.
>             Whenever a Class is in arrayOfRoots, its class (aClass class)
>     must also be in the arrayOfRoots.
>             There are two kinds of image segments.  Normal image segments
>     are a piece of a specific Squeak image, and can only be read back
>     into that image.  The image holds the array of outPointers that are
>     necessary to turn the bits in the file into objects.
>             To put out a normal segment that holds a Project (not the
>     current project), execute (Project named: 'xxx') storeSegment.
>
>
>     arrayOfRoots    The objects that head the tree we will trace.
>     segment                 The WordArray of raw bits of all objects
>     in the tree.
>     outPointers             Oops of all objects outside the segment
>     pointed to from inside.
>     state                   (see below)
>     segmentName     Its basic name.  Often the name of a Project.
>     fileName                The local name of the file.  'Foo-23.seg'
>     userRootCnt             number of roots submitted by caller.  Extras
>     are added in preparation for saving.
>
>     state that an ImageSegment may exist in...
>
>     #activeCopy                     (has been copied, with the intent to
>     become active)
>     arrayOfRoots, segment, and outPointers have been created by
>     copyFromRoots:.  The tree of objects has been encoded in the segment,
>     but those objects are still present in the Squeak system.
>
>     #active                         (segment is actively holding objects)
>     The segment is now the only holder of tree of objects.  Each of the
>     original roots has been transmuted into an ImageSegmentRootStub that
>     refers back to this image segment.  The original objects in the
>     segment will all be garbageCollected.
>
>     #onFile
>     The segment has been written out to a file and replaced by a file
>     pointer.  Only ImageSegmentRootStubs and the array of outPointers
>     remains in the image.  To get this far:
>     (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>                     writeToFile: 'myFile.seg'.
>
>     #inactive
>     The segment has been brought back into memory and turned back into
>     objects.  rootsArray is set, but the segment is invalid.
>
>     #onFileWithSymbols
>     The segment has been written out to a file, along with the text of
>     all the symbols in the outPointers array, and replaced by a file
>     pointer.  This reduces the size of the outPointers array, and also
>     allows the system to reclaim any symbols that are not referred to
>     from elsewhere in the image.  The specific format used is that of a
>     literal array as follows:
>             #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
>     symbol5).
>     In this case, the original outPointers array was 8 long, but the
>     compacted table of outPointers retains only two entries.  These get
>     inserted in place of the #'s in the array of symbols after it is read
>     back in.  Symbols with embedded spaces or other strange characters
>     are written as strings, and converted back to symbols when read back
>     in.  The symbol # is never written out.
>             NOTE: All IdentitySets or dictionaries must be rehashed when
>     being read back from this format.  The symbols are effectively
>     internal.  (No, not if read back into same image.  If a different
>     image, then use #imported.  -tk)
>
>     #imported
>     The segment is on an external file or just read in from one.  The
>     segment and outPointers are meant to be read into a foreign image.
>     In this form, the image segment can be read from a URL, and
>     installed.  A copy of the original array of root objects is
>     constructed, with former outPointers bound to existing objects in the
>     host system.
>             (Any Class inside the segment MUST be in the arrayOfRoots.
>     This is so its association can be inserted into Smalltalk.  The
>     class's metaclass must be in roots also.  Methods that are in
>     outPointers because blocks point at them, were found and added to the
>     roots.
>             All IdentitySets and dictionaries are rehashed when being
>     read back from exported segments.)
>
>
>     To discover why only some of the objects in a project are being
>     written out, try this (***Destructive Test***).  This breaks lots of
>     backpointers in the target project, and puts up an array of
>     suspicious objects, a list of the classes of the outPointers, and a
>     debugger.
>     "Close any transcripts in the target project"
>     World currentHand objectToPaste ifNotNil: [
>             self inform: 'Hand is holding a Morph in its paste
>     buffer:\' withCRs,
>                     World currentHand objectToPaste printString].
>     PV := Project named: 'xxxx'.
>     (IS := ImageSegment new) findRogueRootsImSeg:
>             (Array with: PV world presenter with: PV world).
>     IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
>     "Quit and DO NOT save"
>
>     When an export image segment is brought into an image, it is like an
>     image starting up.  Certain startUp messages need to be run.  These
>     are byte and word reversals for nonPointer data that comes from a
>     machine of the opposite endianness.  #startUpProc passes over all
>     objects in the segment, and:
>             The first time an instance of class X is encountered, (msg _
>     X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
>     case, it means that instances of X do not need special work.  X is
>     included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
>     store it in the dictionary, startUps (aClass -> aMessage).
>             When a later instance of X is encountered, if X is in
>     noStartUpNeeded, do nothing.  If X is in startUps, send the message
>     to the instance.  Typically this is a message like #swapShortObjects.
>             Every class that implements #startUp, should see if it needs
>     a parallel implementation of #startUpFrom:.
>
>     On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com
>     <mailto:luchiano at gmail.com>> wrote:
>     > I don't see image segments in Cuis... I don't even know if they
>     still exist
>     > in Squeak... Anyone is still using it?
>     >
>     > It would be cool to have it at least as a package. If I remember
>     correctly
>     > it was very simple, like two primitives to load and save, but I
>     think it
>     > depended on something like mark and sweep or some particular kind of
>     > garbage collector and it might not work in new VMs.
>     >
>
>     _______________________________________________
>     Cuis mailing list
>     Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151128/5e6e6890/attachment-0003.html>

From juan at jvuletich.org  Sat Nov 28 14:25:56 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:25:56 -0300
Subject: [Cuis] Cuis Logo
In-Reply-To: <CALsRT0k8oL4K0mqWuBTKi0+3cBqZ=cJZcQFZm4d1KSYkDhxj_A@mail.gmail.com>
References: <CALsRT0k8oL4K0mqWuBTKi0+3cBqZ=cJZcQFZm4d1KSYkDhxj_A@mail.gmail.com>
Message-ID: <565A0DD4.4000006@jvuletich.org>

Hi EuanM,

On 27/11/2015 05:19 p.m., EuanM wrote:
> My 0.0.3 release of a proposed interim Cuis logo is now online, on the
> home page at:
> http://smalltalk.uk.to/

When I first looked at it, I thought "what's this bear like face looking 
to the upper right? I'll need to find a polite way to say 'no'!".
Two seconds later mi brain did the click and saw the little mouse 
looking towards the left.
The same happened to my 12 y.o and my wife (without me saying a word).

I love it!

Thanks,
Juan Vuletich

> My plan is to add it to the constellation of Smalltalk logos on the
> slideshow I'm writing, until Juan and the community have a better
> option.
>
> Cheers,
>      Euan
>
>
>> On Fri, 27 Nov 2015 07:26:15 -0300, "Edgar J. De Cleene" wrote:
>> On 11/26/15, 10:46 PM, "EuanM"<euanmee at gmail.com>  wrote:
>>
>>> I'm preparing a slideshow on what's good and cool in the Smalltalk world(s)
>>> atm.
>>>
>>> I want to include Cuis.
>>>
>>> I'm not aware of any official or semi-official logo.
>>>
>>> I'm not even sure of the derivation or meaning of "Cuis".
>>>
>>> Could someone point me to a logo, if there is one?
>>>
>>> Could someone tell me more about why the project is called "Cuis"?
>>> (And if there is nothing atm, I'll produce a logo that ties in to
>>> that)
>>>
>>> Cheers,
>>>      Euan
>> https://en.wikipedia.org/wiki/Southern_mountain_cavy (Microcavia australis)
>> Cuis
>>
>> So is a rodent living in Argentina.
>> Very common, you do not need to far of mayor cities to found it to side of
>> roads
>>
>> Maybe a styli shed photo ?
>>
>> Edgar
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Sat Nov 28 14:26:54 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:26:54 -0300
Subject: [Cuis] Class Comment Browser
In-Reply-To: <5658B3EF.24941.1584D0D@dnorton.mindspring.com>
References: <5658B3EF.24941.1584D0D@dnorton.mindspring.com>
Message-ID: <565A0E0E.7070405@jvuletich.org>

Will do.

Thanks,
Juan Vuletich

On 27/11/2015 04:50 p.m., Dan Norton wrote:
> Hi Juan,
>
> Please include the latest when you build next time:
>
> 	https://github.com/dhnorton/Cuis-Smalltalk-comments
>
> Changes:
> 	less redundancy in the list
> 	pick up trailing acronyms
> 	revised class comments
>
> Thanks,
>   - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Sat Nov 28 14:28:18 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:28:18 -0300
Subject: [Cuis] New updates
In-Reply-To: <56587509.2020202@smalltalk.comcastbiz.net>
References: <56530DC3.3040609@jvuletich.org>	<CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>
	<56587509.2020202@smalltalk.comcastbiz.net>
Message-ID: <565A0E62.8080707@jvuletich.org>

Thanks, Folks!!!

Cheers,
Juan Vuletich

On 27/11/2015 12:21 p.m., Andres Valloud wrote:
> Hello,
>
> The fixes to exceptions are about solving subtle misbehaviors with the 
> messages #pass, #outer, and #resignalAs:.  Generally speaking, the 
> main issue was that the correct handler block wouldn't be found.  
> Thus, for example, sending the message #pass would fail to find a 
> default handler.  I found these types of issues while porting 
> Assessments (more on Assessments below), because it uses #pass to 
> track exceptions, and #resignalAs: to remap other exceptions into 
> exceptions Assessments understands.  Correct nested execution of #pass 
> required a stack of handler contexts, thus now exceptions keep an 
> ordered collection of handler contexts rather than just the topmost 
> handler.  Surely this is not the only way this can be done.
>
> Assessments is a testing framework specifically designed with 
> collaboration in mind.  I had been making SUnit extensions since 2001, 
> and eventually I realized sharing such extensions and improvements 
> with other SUnit users would be fundamentally obstructed.  SUnit's 
> design is such that one has to change the framework itself in order to 
> extend its behavior.  Thus, what I change in my image does not 
> necessarily have to work in someone else's image, and vice versa.  As 
> a result, most SUnit users end up implementing extensions such as file 
> logging or more extensive result reporting, and those extensions are 
> incompatible with each other.
>
> Instead, Assessments is built around the principle that the testing 
> framework's behavior and extensibility should rely on object 
> composition rather than subclassing.  In addition, a few critical 
> objects are now reified explicitly.  Chief among them is the 
> Assessment (the "test suite"), with its evaluation context (no 
> parallel).  The key is that the evaluation context of an assessment 
> can change how tests are executed, how results are collected, and so 
> on.  Since this is done by object composition, it's trivial to e.g. 
> set up an assessment to report results to multiple files and to the 
> GUI without changing Assessments itself. As a result, extensions can 
> be shared without the threat of immediate incompatibility.
>
> But what about pre-existing SUnit tests?  Well surely a new testing 
> framework built around collaboration wouldn't immediately obsolete the 
> enormous body of SUnit tests out there, or force a migration because 
> NIH or something like that.  And that's exactly what Assessments 
> accomplishes.  Since there is an evaluation context object, an 
> assessment ("test suite") can specify which execution policy goes for 
> which check ("test").  Assessments uses this flexibility to execute 
> SUnit tests in situ, as if SUnit itself was running them.  Unlike 
> other solutions deployed to solve this problem, Assessments does not 
> require modifications to existing code.  Loading Assessments is 
> effectively invisible to existing SUnit code.
>
> The end result is that the Assessments checklist evaluator (the "test 
> runner") displays both SUnit tests and native Assessments tests, and 
> one assessment object can execute both types together.
>
> In addiiton, Assessments provides a clean, native implementation of 
> SUnit Validation (also known as "Extreme Validation"), as well as 
> SUnit Benchmarks.  Both of these are implemented in terms of 
> Assessments checklists.  Briefly, validation involves using tests to 
> verify e.g. business objects at run time.  A typical application of 
> validation would be data entry verification.  The Benchmarks is 
> another application of tests, where each test measures the time needed 
> to execute some code. In addition, Benchmarks can enforce that some 
> code runs within a certain amount of time.  An interesting detail is 
> that the required time is specified in "message send" units, rather 
> than time.  Thus, the benchmarks do not become obsolete or 
> inappropriate depending on the speed of the machine where the 
> measurements are taken.
>
> For more information, the Assessments package contains more detailed 
> comments as well as links to additional detail.  I originally 
> presented Assessments at ESUG 2008, the video of the talk is online 
> here (and other places):
>
> https://vimeo.com/1945494
>
> There are also some notes on validation here:
>
> http://csl.ensm-douai.fr/Esug2007Media/uploads/1/Extreme.pdf
>
> There is also a paper by Leandro Caniglia titled "Extreme Validation", 
> which unfortunately I couldn't immediately find in Google.  But I 
> image I can get a copy and put it online somewhere.
>
> Andres.
>
> On 11/23/15 7:35 , Luciano Notarfrancesco wrote:
>> Hi all,
>> About my recent changes, some of them are 1) extensions to Theme to be
>> able to customize some more aspects of how the windows and widgets look,
>> or 2) fixes for small bugs that I found on the way, like misalignments
>> of a few pixels between parts of a widget or a window. The motivation
>> behind this was just to be able to implement a very minimalist look
>> (borders of just 1 pixel, no decorations, no icons, no anything that I
>> dont need and takes up screen real estate), and a sort of tiling dynamic
>> window manager very much like http://dwm.suckless.org
>> (https://github.com/len/Cuis-Smalltalk-DWM).
>>
>> In order to implement this "window manager" as an external package with
>> minimal changes to the core system, I decided to: 1) make the current
>> Theme receive messages #windowOpen: #windowClosed: every time
>> SystemWindows are open or closed, in order to give it a chance to
>> implement window-management behaviour or delegate it to a proper window
>> manager; 2) move the window-management keyboard shortcuts (like alt-w to
>> close) to Theme, so it is all in one place, easy to change, and easy to
>> make a Theme that delegates keyboard events to a proper window manager.
>>
>> Again I did it like this in order to minimize changes to the core
>> system. At the moment window management is in part implemented in
>> SystemWindow, and also in HandMorph and Morph. I had to make some small
>> modifications in order to get the desired behavior when using DWM, and
>> keep the original behavior in the base system. Maybe in the long run we
>> would want to have a WindowManager class that do this, handle keyboard
>> events for the window-management shortcuts and receives #windowOpen: and
>> #windowClosed:, etc. But I would like to think better about this before
>> adding new concepts and complexity to the core.
>>
>> Cheers,
>> Luciano
>>
>>
>> On Mon, Nov 23, 2015 at 12:59 PM, Juan Vuletich <juan at jvuletich.org
>> <mailto:juan at jvuletich.org>> wrote:
>>
>>     Hi all,
>>
>>     I recently included some new updates:
>>
>>     - Fixes to Exceptions by Andr?s Valloud and Martin McClure.
>>     - Assessments framework for testing and validation by Andr?s 
>> Valloud.
>>     - Many fixes and enhancements to Layouts, Window drawing, keyboard
>>     shortcuts, etc. by Luciano Notarfrancesco
>>
>>     Thank you very much Folks! Andr?s, Luciano, please comment a bit on
>>     what you did, especially subtle but important behavior such as
>>     Exceptions and new stuff like Assessments, and the new Theme and
>>     Window Manager.
>>
>>     Cheers,
>>     Juan Vuletich
>>
>>     _______________________________________________
>>     Cuis mailing list
>>     Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From 0800nacho at gmail.com  Sun Nov  1 20:45:06 2015
From: 0800nacho at gmail.com (nacho)
Date: Sun, 1 Nov 2015 18:45:06 -0800 (PST)
Subject: [Cuis] serialization in Cuis
Message-ID: <1446432306774-4858922.post@n4.nabble.com>

Hi Folks,
I'm trying to add support for serializing instances of a class. 
I'm looking at System-Object Storage
And in particular to the class SmartRefStream which seems to add that
functionality. However, the class has no comments and no examples.
Is there some example which uses this class? a short demo? an example?
Thanks in advance!!
best
Nacho





-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/serialization-in-Cuis-tp4858922.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Sun Nov  1 22:52:24 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sun, 1 Nov 2015 20:52:24 -0800
Subject: [Cuis] ColorEditor updated
In-Reply-To: <56357262.9599.2DA3199@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<56357262.9599.2DA3199@dnorton.mindspring.com>
Message-ID: <20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>

On Sat, 31 Oct 2015 22:01:06 -0400
"Dan Norton" <dnorton at mindspring.com> wrote:

> On 29 Oct 2015 at 16:56, KenD wrote:
..
> > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > updates.  You can file it in and check senders.
..
> I've done that and I see that messages to SystemChangeNotifier are not required in order to  use the method.
> 
> Also, the dependency mechanism itself uses #when:send:to:.
> 
> Any object can use  #when:send:to: because it is an Object instance method. 
> 
> So, should this be named a different mechanism or is it just a different use of the 
> dependency mechanism?
> 
> If it's a different mechanism, is "Signals" the right name? This by Marcel Taeumel:
> 	
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#Featu
> reComparison

Hi Dan.

I took a look at the Signals implementation some time ago and my recollection is that I found the implementation to be complex and less useful than I had hoped.

For my limited uses, I prefer #when:send:to:

Simplicity wins.  In the longer term I hope somebody gets a chance to rewrite the older #changed: code to use the #when:send:to: mechanism so that we can remove #changed: .

I agree that having two update mechanisms is one too many.  Adding a third dependency update, Signals, would be going in the wrong direction IMHO.

$0.02
-KenD



From dnorton at mindspring.com  Mon Nov  2 14:58:26 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 02 Nov 2015 15:58:26 -0500
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<56357262.9599.2DA3199@dnorton.mindspring.com>,
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
Message-ID: <5637CE72.9136.1176A2C@dnorton.mindspring.com>

Hi Ken,

Comments in line.

On 1 Nov 2015 at 20:52, KenD wrote:

> On Sat, 31 Oct 2015 22:01:06 -0400
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> > On 29 Oct 2015 at 16:56, KenD wrote:
> ..
> > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > > updates.  You can file it in and check senders.
> ..
> > I've done that and I see that messages to SystemChangeNotifier are
> not required in order to  use the method.
> > 
> > Also, the dependency mechanism itself uses #when:send:to:.
> > 
> > Any object can use  #when:send:to: because it is an Object
> instance method. 
> > 
> > So, should this be named a different mechanism or is it just a
> different use of the 
> > dependency mechanism?
> > 
> > If it's a different mechanism, is "Signals" the right name? This
> by Marcel Taeumel:
> > 	
> >
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjec
> ts/wiki/signals#Featu
> > reComparison
> 
> Hi Dan.
> 
> I took a look at the Signals implementation some time ago and my
> recollection is that I found the implementation to be complex and
> less useful than I had hoped.
> 
> For my limited uses, I prefer #when:send:to:
> 
> Simplicity wins.

+1

  In the longer term I hope somebody gets a chance
> to rewrite the older #changed: code to use the #when:send:to:
> mechanism so that we can remove #changed: .
> 
> I agree that having two update mechanisms is one too many.  Adding a
> third dependency update, Signals, would be going in the wrong
> direction IMHO.
>

That's fine. I was casting about for some name besides " #when:send:to: mechanism" for 
use in a brief essay on PluggableListMorph Principles of Operation when I came across 
Signals. I already wrote a paragraph on Dependency Mechanism.

So, the simple principle here is to just use #when:send:to: and forget about or maybe 
deprecate #changed: and #update:? The advantage IIUC is #when:send:to:
	can be sent by any object, 
	the receiver can be any object, 
	the to: parameter can be any object, and 
	the send: parameter doesn't necessarily have to exist because WeakMessageSend 
is used! 

What a deal :).

However, I see a problem common to dependency and #when:send:to: which is the 
identification and explanation of the various symbols which are communicated as the 
parameters for send: or changed: . When you're trying to design a model or view similar to 
something already in existence, the tools are not much help with that.

I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>

Would appreciate any thoughts.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151102/3d081884/attachment-0004.html>

From Ken.Dickey at Whidbey.com  Mon Nov  2 17:27:16 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Mon, 2 Nov 2015 15:27:16 -0800
Subject: [Cuis] ColorEditor updated
In-Reply-To: <5637CE72.9136.1176A2C@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<56357262.9599.2DA3199@dnorton.mindspring.com>
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
Message-ID: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>

On Mon, 02 Nov 2015 15:58:26 -0500
"Dan Norton" <dnorton at mindspring.com> wrote:

>.. I was casting about for some name besides " #when:send:to: mechanism" for 
> use in a brief essay on PluggableListMorph Principles of Operation when I came across 
> Signals. I already wrote a paragraph on Dependency Mechanism.

I would talk about #when:send:to: as implementing the Observer Pattern.

> So, the simple principle here is to just use #when:send:to: and forget about or maybe 
> deprecate #changed: and #update:? 

Yes.  Let us work to eliminate #changed: !

> However, I see a problem common to dependency and #when:send:to: which is the 
> identification and explanation of the various symbols which are communicated as the 
> parameters for send: or changed: . When you're trying to design a model or view similar to 
> something already in existence, the tools are not much help with that.
> 
> I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>

We should certainly add clarifying comments!

Your Comment Browser is a big help here.  Once people start using it more, comments will appear.

I suggest sending Juan a code update with an added "Open Comment Browser" Help menu item which autoloads the same way as TerseGuide.


However, class comments are not usually where design patterns show up.  8^|

In the case of #when:send:to: I suggest a slightly larger discussion around building paned windows which update dependent panes.

What constitutes good style?  What code patterns help?

Think "Useful Code Patterns" to augment "Useful Expressions".

You can do your own example, but looking at the ColorEditor:

ColorEditor>>buildMorphicWindow
	"Create a useful ColorEditor window"
	
	self layoutMorph beRow; " A row of columns"
		 separation: 6;
		 addMorph: self buildColorPaneColumn;
		 addMorph: self buildSliderColumn;
		 addMorph: self buildRadioButtonColumn;
		 color: self backgroundColor.
		
	self model when: #colorChanged send: #refreshColor to: self.
	
	^ self

So trying for good style (hey, I need to improve here too!) one uses: 

[Class]>buildMorphicWindow
    [Add (construct each pane).. to layout]
    [Add self or panes as observers]
  ^ self

Suggest
  Smalltalk browseAllImplementorsOf: #buildMorphicWindow
to see specific usage examples.

Of course, we will suffer some embarrassment as our real code is less than ideal. 8^(

But this is a great motivator to making our code better!  ;^)


$0.02
-KenD



From hannes.hirzel at gmail.com  Mon Nov  2 19:39:44 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 3 Nov 2015 02:39:44 +0100
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<56357262.9599.2DA3199@dnorton.mindspring.com>
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
Message-ID: <CAGQxfVjUVgu4_JDOEYJR1Kf4Kv+YADxMDb9bPd7=-rO8U_dZxg@mail.gmail.com>

On 11/3/15, KenD <Ken.Dickey at whidbey.com> wrote:
> On Mon, 02 Nov 2015 15:58:26 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
>
>>.. I was casting about for some name besides " #when:send:to: mechanism"
>> for
>> use in a brief essay on PluggableListMorph Principles of Operation when I
>> came across
>> Signals. I already wrote a paragraph on Dependency Mechanism.
>
> I would talk about #when:send:to: as implementing the Observer Pattern.
>
>> So, the simple principle here is to just use #when:send:to: and forget
>> about or maybe
>> deprecate #changed: and #update:?
>
> Yes.  Let us work to eliminate #changed: !
>
>> However, I see a problem common to dependency and #when:send:to: which is
>> the
>> identification and explanation of the various symbols which are
>> communicated as the
>> parameters for send: or changed: . When you're trying to design a model or
>> view similar to
>> something already in existence, the tools are not much help with that.
>>
>> I'm thinking maybe: document in comments? <rant>Nah. We don't do
>> comments.</rant>
>
> We should certainly add clarifying comments!
>
> Your Comment Browser is a big help here.  Once people start using it more,
> comments will appear.
>
> I suggest sending Juan a code update with an added "Open Comment Browser"
> Help menu item which autoloads the same way as TerseGuide.
+1
>
> However, class comments are not usually where design patterns show up.  8^|
>
> In the case of #when:send:to: I suggest a slightly larger discussion around
> building paned windows which update dependent panes.
>
> What constitutes good style?  What code patterns help?
>
> Think "Useful Code Patterns" to augment "Useful Expressions".
+1
> You can do your own example, but looking at the ColorEditor:
>
> ColorEditor>>buildMorphicWindow
> 	"Create a useful ColorEditor window"
> 	
> 	self layoutMorph beRow; " A row of columns"
> 		 separation: 6;
> 		 addMorph: self buildColorPaneColumn;
> 		 addMorph: self buildSliderColumn;
> 		 addMorph: self buildRadioButtonColumn;
> 		 color: self backgroundColor.
> 		
> 	self model when: #colorChanged send: #refreshColor to: self.
> 	
> 	^ self
>
> So trying for good style (hey, I need to improve here too!) one uses:
>
> [Class]>buildMorphicWindow
>     [Add (construct each pane).. to layout]
>     [Add self or panes as observers]
>   ^ self
>
> Suggest
>   Smalltalk browseAllImplementorsOf: #buildMorphicWindow
> to see specific usage examples.
>
> Of course, we will suffer some embarrassment as our real code is less than
> ideal. 8^(
>
> But this is a great motivator to making our code better!  ;^)
>
>
> $0.02
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From brasspen at gmail.com  Tue Nov  3 07:47:59 2015
From: brasspen at gmail.com (Chris Cunnington)
Date: Tue, 3 Nov 2015 08:47:59 -0500
Subject: [Cuis] [ANN] OopluCon 2016, San Francisco, April
Message-ID: <5638BB0F.5030700@gmail.com>

OopluCon 2016
A Day for the Smalltalk Programming Language and its Friends

Sunday 10 April 2016
8am - 4pm

The Box SF
1069 Howard Street (between 6th and 7th)
three blocks from Moscone Center, SoMa
San Francisco, USA
http://www.theboxsf.com/

The event is free
A request for presentations will be announced in a future month
A presentation called An Introduction To Smalltalk will promoted to the 
Ruby, Python and Objective C communities
The latest details will be available at http://www.ooplu.com




From dnorton at mindspring.com  Tue Nov  3 12:11:50 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 03 Nov 2015 13:11:50 -0500
Subject: [Cuis] Terse Guide to Cuis
Message-ID: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>

Hi Juan,

The guide has been updated as follows:

	revised iterations topic
	revised transcript topic
	replaced file streams with file operations topic featuring FileMan

Please include this in the next build. The repo is:

	https://github.com/dhnorton/Cuis-Smalltalk-terse

 - Dan



From dnorton at mindspring.com  Tue Nov  3 13:58:46 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 03 Nov 2015 14:58:46 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <563911F6.21646.11C43C8@dnorton.mindspring.com>

Hi Juan,

As recommended by Ken and Hannes, the attached methods add the capability to bring up 
the class comment browser from the help menu.

Sorry, but I still don't know how to prepend the thumbnail to the menu item :)

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TheWorldMenu-openCommentGuide.zip
Type: application/zip
Size: 1298 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151103/b51fa789/attachment-0004.zip>

From 0800nacho at gmail.com  Tue Nov  3 17:13:35 2015
From: 0800nacho at gmail.com (nacho)
Date: Tue, 3 Nov 2015 15:13:35 -0800 (PST)
Subject: [Cuis] Terse Guide to Cuis
In-Reply-To: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
References: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
Message-ID: <1446592415409-4859122.post@n4.nabble.com>

Thanks Dan,
This guide is very helpful.
Are you planning to add some help in all the ways to manipulate colours?
Best regards
Nacho





-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Re-Terse-Guide-to-Cuis-tp4859099p4859122.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From 0800nacho at gmail.com  Wed Nov  4 05:00:53 2015
From: 0800nacho at gmail.com (nacho)
Date: Wed, 4 Nov 2015 03:00:53 -0800 (PST)
Subject: [Cuis] Terse Guide to Cuis
In-Reply-To: <1446592415409-4859122.post@n4.nabble.com>
References: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
	<1446592415409-4859122.post@n4.nabble.com>
Message-ID: <1446634853959-4859148.post@n4.nabble.com>

Dan,
Thanks for your prompt response.
I already had all of Mr. Dickey's marvellous and mysterious Cuis stuff
cloned into my computer :p
Very useful too.
Best
nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Re-Terse-Guide-to-Cuis-tp4859099p4859148.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Wed Nov  4 09:11:16 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Wed, 4 Nov 2015 07:11:16 -0800
Subject: [Cuis] Terse Guide to Cuis
In-Reply-To: <1446634853959-4859148.post@n4.nabble.com>
References: <5638F8E6.4570.BA5DEB@dnorton.mindspring.com>
	<1446592415409-4859122.post@n4.nabble.com>
	<1446634853959-4859148.post@n4.nabble.com>
Message-ID: <20151104071116.8650ae2d569537a692f895ec@Whidbey.com>

On Wed, 4 Nov 2015 03:00:53 -0800 (PST)
nacho <0800nacho at gmail.com> wrote:

> I already had all of Mr. Dickey's marvellous and mysterious Cuis stuff
> cloned into my computer :p

Note that I have been working through my projects, eliminating FileDirectory in favor of FileMan.

Users should to do a "git pull" on most of these for 2568.

As usual, bugs to /dev/null, er, I mean to me  ;^)
-KenD



From dnorton at mindspring.com  Wed Nov  4 17:46:20 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 04 Nov 2015 18:46:20 -0500
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>,
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
Message-ID: <563A98CC.20508.1B798BE@dnorton.mindspring.com>

Ran across this comment for ActiveModel and thought it was interesting, historically.

Part of update 5005u16-Events.cs:

"Change Set:		Events
Date:			11 February 2002
Author:			Rob Withers et al.

Published to 3.3a as 4756Events.cs

The NuBlue events code. Finally..."

The new event model, originally from VisualSmalltalk.
This includes #when:send:to: and friends, in Object (generic implementation) and 
ActiveModel (optimized implementation).
It renders the old change/update mechanism in Object and Model as obsolete, although still 
used.

 - Dan

On 2 Nov 2015 at 15:27, KenD wrote:

> On Mon, 02 Nov 2015 15:58:26 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> >.. I was casting about for some name besides " #when:send:to:
> mechanism" for 
> > use in a brief essay on PluggableListMorph Principles of Operation
> when I came across 
> > Signals. I already wrote a paragraph on Dependency Mechanism.
> 
> I would talk about #when:send:to: as implementing the Observer
> Pattern.
> 
> > So, the simple principle here is to just use #when:send:to: and
> forget about or maybe 
> > deprecate #changed: and #update:? 
> 
> Yes.  Let us work to eliminate #changed: !
> 
> > However, I see a problem common to dependency and #when:send:to:
> which is the 
> > identification and explanation of the various symbols which are
> communicated as the 
> > parameters for send: or changed: . When you're trying to design a
> model or view similar to 
> > something already in existence, the tools are not much help with
> that.
> > 
> > I'm thinking maybe: document in comments? <rant>Nah. We don't do
> comments.</rant>
> 
> We should certainly add clarifying comments!
> 
> Your Comment Browser is a big help here.  Once people start using it
> more, comments will appear.
> 
> I suggest sending Juan a code update with an added "Open Comment
> Browser" Help menu item which autoloads the same way as
> TerseGuide.
> 
> 
> However, class comments are not usually where design patterns show
> up.  8^|
> 
> In the case of #when:send:to: I suggest a slightly larger discussion
> around building paned windows which update dependent panes.
> 
> What constitutes good style?  What code patterns help?
> 
> Think "Useful Code Patterns" to augment "Useful Expressions".
> 
> You can do your own example, but looking at the ColorEditor:
> 
> ColorEditor>>buildMorphicWindow
> 	"Create a useful ColorEditor window"
> 	
> 	self layoutMorph beRow; " A row of columns"
> 		 separation: 6;
> 		 addMorph: self buildColorPaneColumn;
> 		 addMorph: self buildSliderColumn;
> 		 addMorph: self buildRadioButtonColumn;
> 		 color: self backgroundColor.
> 		
> 	self model when: #colorChanged send: #refreshColor to: self.
> 	
> 	^ self
> 
> So trying for good style (hey, I need to improve here too!) one
> uses: 
> 
> [Class]>buildMorphicWindow
>     [Add (construct each pane).. to layout]
>     [Add self or panes as observers]
>   ^ self
> 
> Suggest
>   Smalltalk browseAllImplementorsOf: #buildMorphicWindow
> to see specific usage examples.
> 
> Of course, we will suffer some embarrassment as our real code is
> less than ideal. 8^(
> 
> But this is a great motivator to making our code better!  ;^)
> 
> 
> $0.02
> -KenD





From dnorton at mindspring.com  Thu Nov  5 12:23:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 05 Nov 2015 13:23:07 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <563B9E8B.18686.D41F27@dnorton.mindspring.com>

The latest enables list selection by key. Not fancy like PluggableListMorph, just single key 
selection.

	https://github.com/dhnorton/Cuis-Smalltalk-comments

Somehoo I have introduced a yip in the scroller but maybe it is usable for the time being.

 - Dan



From hari.balaraman at icloud.com  Thu Nov  5 13:53:44 2015
From: hari.balaraman at icloud.com (Hari Balaraman)
Date: Thu, 05 Nov 2015 14:53:44 -0500
Subject: [Cuis] FAST conference
In-Reply-To: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
Message-ID: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>

If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
Best regards,
Hari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151105/32d3218d/attachment-0004.html>

From dnorton at mindspring.com  Thu Nov  5 15:25:17 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 5 Nov 2015 13:25:17 -0800 (PST)
Subject: [Cuis] Class Comment Browser
In-Reply-To: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
References: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
Message-ID: <1446758717845-4859424.post@n4.nabble.com>

:( OK, I fixed it. :)

 - Dan



--
View this message in context: http://forum.world.st/Class-Comment-Browser-tp4859411p4859424.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From juan at jvuletich.org  Fri Nov  6 12:04:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:04:53 -0300
Subject: [Cuis] ColorEditor updated
In-Reply-To: <5637CE72.9136.1176A2C@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<56357262.9599.2DA3199@dnorton.mindspring.com>,
	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>
	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
Message-ID: <563CEBC5.40409@jvuletich.org>

(inline)

On 11/2/2015 5:58 PM, Dan Norton wrote:
> Hi Ken,
>
> Comments in line.
>
> On 1 Nov 2015 at 20:52, KenD wrote:
>
> > On Sat, 31 Oct 2015 22:01:06 -0400
> > "Dan Norton" <dnorton at mindspring.com> wrote:
> >
> > > On 29 Oct 2015 at 16:56, KenD wrote:
> > ..
> > > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > > > updates.  You can file it in and check senders.
> > ..
> > > I've done that and I see that messages to SystemChangeNotifier are
> > not required in order to  use the method.
> > >
> > > Also, the dependency mechanism itself uses #when:send:to:.
> > >
> > > Any object can use  #when:send:to: because it is an Object
> > instance method.
> > >
> > > So, should this be named a different mechanism or is it just a
> > different use of the
> > > dependency mechanism?
> > >
> > > If it's a different mechanism, is "Signals" the right name? This
> > by Marcel Taeumel:
> > >
> > >
> > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjec
> > ts/wiki/signals#Featu
> > > reComparison
> >
> > Hi Dan.
> >
> > I took a look at the Signals implementation some time ago and my
> > recollection is that I found the implementation to be complex and
> > less useful than I had hoped.
> >
> > For my limited uses, I prefer #when:send:to:
> >
> > Simplicity wins.
>
> +1
>
>   In the longer term I hope somebody gets a chance
> > to rewrite the older #changed: code to use the #when:send:to:
> > mechanism so that we can remove #changed: .
> >
> > I agree that having two update mechanisms is one too many.  Adding a
> > third dependency update, Signals, would be going in the wrong
> > direction IMHO.
> >
>
> That's fine. I was casting about for some name besides " 
> #when:send:to: mechanism" for
> use in a brief essay on PluggableListMorph Principles of Operation 
> when I came across
> Signals. I already wrote a paragraph on Dependency Mechanism.
>
> So, the simple principle here is to just use #when:send:to: and forget 
> about or maybe deprecate #changed: and #update:? The advantage IIUC is 
> #when:send:to:
>            can be sent by any object,
>            the receiver can be any object,
>            the to: parameter can be any object, and
>            the send: parameter doesn't necessarily have to exist 
> because WeakMessageSend is used!
>
> What a deal :).
>
> However, I see a problem common to dependency and #when:send:to: which 
> is the identification and explanation of the various symbols which are 
> communicated as the parameters forsend: or changed: . When you're 
> trying to design a model or view similar to something already in 
> existence, the tools are not much help with that.
>

Well, doing senders on any symbol (method selectors, but also event 
names) shows all references to it. I don't think it is that bad, but, do 
you have ideas for improvements on this?

> I'm thinking maybe: document in comments? <rant>Nah. We don't do 
> comments.</rant>

Let me disagree. Cuis includes 204019 characters in class comments. That 
would be like 2000 to 4000 lines, right? For a system with less than 
100kLOC. Top 10 classes with extensive class comments are: BitBlt 
SmartRefStream Float ClosureScanner Color ContentPack Monitor 
AndreasSystemProfiler EventSensor ReferenceStream. Just check them. 
Several of these are rather recent, some were written specifically for 
Cuis.

We also have  27058 bytes of comments at the top of methods. Some 
methods with great comments are #vmParameterAt: #entriesIn: 
#eliotsClosureMeasurements2On: #getCurrentWorkingDirectory 
#whatIsAPrimitive #asUtf8: #howToModifyPrimitives #applySimpleGamma:to: 
#linearTosRGBGamma: #localMicrosecondClock #findBinaryIndex:do:ifNone: 
#findBinary:do:ifNone: #spyAllOn: , etc.

There is a lot to be learnt about the system from reading comments. And 
we want to improve.

(BTW, querying the system to find this out took me less time than 
writing this email)

> Would appreciate any thoughts.
>
>  - Dan
>

I think that both comments and tools are useful and should be enhanced.

Cheers,
Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/8f076245/attachment-0004.html>

From juan at jvuletich.org  Fri Nov  6 12:13:13 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:13:13 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <1446432306774-4858922.post@n4.nabble.com>
References: <1446432306774-4858922.post@n4.nabble.com>
Message-ID: <563CEDB9.2090200@jvuletich.org>

Hi Nacho,

On 11/1/2015 11:45 PM, nacho wrote:
> Hi Folks,
> I'm trying to add support for serializing instances of a class.
> I'm looking at System-Object Storage
> And in particular to the class SmartRefStream which seems to add that
> functionality. However, the class has no comments and no examples.
> Is there some example which uses this class? a short demo? an example?
> Thanks in advance!!
> best
> Nacho
>

Are we browsing the same system? SmartRefStream class comment is 6016 
characters here. Superclass ReferenceStream has a class comments of 2875 
characters. DataStream and ReferenceStream have class methods that start 
with 'example'. Looking for references to these classes also brings 
useful examples of usage.

In any case, the usual way to serialize classes is fileOut. Why doesn't 
this work for you? What problem are you trying to solve?

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Nov  6 12:28:23 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:28:23 -0300
Subject: [Cuis] ColorEditor updated
In-Reply-To: <20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<56357262.9599.2DA3199@dnorton.mindspring.com>	<20151101205224.c1f4f60bb2b111b858a909b4@Whidbey.com>	<5637CE72.9136.1176A2C@dnorton.mindspring.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
Message-ID: <563CF147.306@jvuletich.org>

Hi Ken,

On 11/2/2015 8:27 PM, KenD wrote:
> ...
>
> However, class comments are not usually where design patterns show up.  8^|
>
> In the case of #when:send:to: I suggest a slightly larger discussion around building paned windows which update dependent panes.
>
> What constitutes good style?  What code patterns help?
>
> Think "Useful Code Patterns" to augment "Useful Expressions".

In 2009 I wrote 
http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgramming.txt 
and 
http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.txt . 
I've had the idea of making all the GUI code in Cuis follow this style. 
But time is always short...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Nov  6 12:29:02 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:29:02 -0300
Subject: [Cuis] [ANN] OopluCon 2016, San Francisco, April
In-Reply-To: <5638BB0F.5030700@gmail.com>
References: <5638BB0F.5030700@gmail.com>
Message-ID: <563CF16E.3040707@jvuletich.org>

:)

On 11/3/2015 10:47 AM, Chris Cunnington wrote:
> OopluCon 2016
> A Day for the Smalltalk Programming Language and its Friends
>
> Sunday 10 April 2016
> 8am - 4pm
>
> The Box SF
> 1069 Howard Street (between 6th and 7th)
> three blocks from Moscone Center, SoMa
> San Francisco, USA
> http://www.theboxsf.com/
>
> The event is free
> A request for presentations will be announced in a future month
> A presentation called An Introduction To Smalltalk will promoted to 
> the Ruby, Python and Objective C communities
> The latest details will be available at http://www.ooplu.com
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Fri Nov  6 12:32:14 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:32:14 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
Message-ID: <563CF22E.4080804@jvuletich.org>

Hi Hari,

I'll be there. Let's meet then.

Anybody else?

Cheers,
Juan Vuletich

On 11/5/2015 4:53 PM, Hari Balaraman wrote:
> If any of you are attending the FAST conference in Buenos Aires in a 
> week or so, I look forward to meeting you face to face.
> Best regards,
> Hari
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/3c065b90/attachment-0004.html>

From 0800nacho at gmail.com  Fri Nov  6 12:40:14 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Fri, 6 Nov 2015 15:40:14 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <563CF22E.4080804@jvuletich.org>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
Message-ID: <etPan.563cf40e.77bd141b.a58@Unix.local>

Yes I will be there too.
Juan, are you giving the talk on friday?
cheers


--?
Ignacio Sniechowski
Prosavic SRL
Sent with Airmail

On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org) wrote:

Hi Hari,

I'll be there. Let's meet then.

Anybody else?

Cheers,
Juan Vuletich

On 11/5/2015 4:53 PM, Hari Balaraman wrote:
If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
Best regards,
Hari


_______________________________________________
Cuis mailing list
Cuis at jvuletich.org
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________  
Cuis mailing list  
Cuis at jvuletich.org  
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/0cb1d1b7/attachment-0004.html>

From 0800nacho at gmail.com  Fri Nov  6 12:42:53 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Fri, 6 Nov 2015 15:42:53 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <563CEDB9.2090200@jvuletich.org>
References: <1446432306774-4858922.post@n4.nabble.com>
	<563CEDB9.2090200@jvuletich.org>
Message-ID: <etPan.563cf4ad.177918bd.a58@Unix.local>

Hi Juan,
Thanks for your response.
I?m not trying to serialize classes but instances of them.
Suppose theres a class called Memo with an ivar ?content?
Then I want to be able add to the instances the posibility of storing their data.
fileOut is great for classes I use it a lot!
But I want a way to preserve data outside the image, so it can be loaded when a new image is used.
thanks!
Nacho


--?
Ignacio Sniechowski
Prosavic SRL
Sent with Airmail

On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org) wrote:

Hi Nacho,  

On 11/1/2015 11:45 PM, nacho wrote:  
> Hi Folks,  
> I'm trying to add support for serializing instances of a class.  
> I'm looking at System-Object Storage  
> And in particular to the class SmartRefStream which seems to add that  
> functionality. However, the class has no comments and no examples.  
> Is there some example which uses this class? a short demo? an example?  
> Thanks in advance!!  
> best  
> Nacho  
>  

Are we browsing the same system? SmartRefStream class comment is 6016  
characters here. Superclass ReferenceStream has a class comments of 2875  
characters. DataStream and ReferenceStream have class methods that start  
with 'example'. Looking for references to these classes also brings  
useful examples of usage.  

In any case, the usual way to serialize classes is fileOut. Why doesn't  
this work for you? What problem are you trying to solve?  

Cheers,  
Juan Vuletich  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/d2e149d2/attachment-0004.html>

From juan at jvuletich.org  Fri Nov  6 12:43:57 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:43:57 -0300
Subject: [Cuis] Class Comment Browser
In-Reply-To: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
References: <563B9E8B.18686.D41F27@dnorton.mindspring.com>
Message-ID: <563CF4ED.6090306@jvuletich.org>

On 11/5/2015 3:23 PM, Dan Norton wrote:
> The latest enables list selection by key. Not fancy like PluggableListMorph, just single key
> selection.
>
> 	https://github.com/dhnorton/Cuis-Smalltalk-comments
>
> Somehoo I have introduced a yip in the scroller but maybe it is usable for the time being.
>
>   - Dan

Hi Dan,

Just integrated your recent contributions. Thank you!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Nov  6 12:45:15 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:45:15 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <etPan.563cf40e.77bd141b.a58@Unix.local>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
Message-ID: <563CF53B.5000107@jvuletich.org>

Yes, on Friday. Meet you there!

Cheers,
Juan Vuletich

On 11/6/2015 3:40 PM, Ignacio Sniechowski wrote:
> Yes I will be there too.
> Juan, are you giving the talk on friday?
> cheers
>
>
> -- 
> Ignacio Sniechowski
> Prosavic SRL
> Sent with Airmail
>
> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org 
> <mailto:juan at jvuletich.org>) wrote:
>
>> Hi Hari,
>>
>> I'll be there. Let's meet then.
>>
>> Anybody else?
>>
>> Cheers,
>> Juan Vuletich
>>
>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>> If any of you are attending the FAST conference in Buenos Aires in a 
>>> week or so, I look forward to meeting you face to face.
>>> Best regards,
>>> Hari
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/36a59629/attachment-0004.html>

From juan at jvuletich.org  Fri Nov  6 12:48:20 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 06 Nov 2015 15:48:20 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <etPan.563cf4ad.177918bd.a58@Unix.local>
References: <1446432306774-4858922.post@n4.nabble.com>
	<563CEDB9.2090200@jvuletich.org>
	<etPan.563cf4ad.177918bd.a58@Unix.local>
Message-ID: <563CF5F4.1070808@jvuletich.org>

Hi Nacho,

Oh, yes, I misread. Ok. ReferenceStream and SmartRefStream are your 
choices. Take a look at the class comments, play with the examples. Ask 
questions.

Cheers,
Juan Vuletich


On 11/6/2015 3:42 PM, Ignacio Sniechowski wrote:
> Hi Juan,
> Thanks for your response.
> I?m not trying to serialize classes but instances of them.
> Suppose theres a class called Memo with an ivar ?content?
> Then I want to be able add to the instances the posibility of storing 
> their data.
> fileOut is great for classes I use it a lot!
> But I want a way to preserve data outside the image, so it can be 
> loaded when a new image is used.
> thanks!
> Nacho
>
>
> -- 
> Ignacio Sniechowski
> Prosavic SRL
> Sent with Airmail
>
> On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org 
> <mailto:juan at jvuletich.org>) wrote:
>
>> Hi Nacho,
>>
>> On 11/1/2015 11:45 PM, nacho wrote:
>> > Hi Folks,
>> > I'm trying to add support for serializing instances of a class.
>> > I'm looking at System-Object Storage
>> > And in particular to the class SmartRefStream which seems to add that
>> > functionality. However, the class has no comments and no examples.
>> > Is there some example which uses this class? a short demo? an example?
>> > Thanks in advance!!
>> > best
>> > Nacho
>> >
>>
>> Are we browsing the same system? SmartRefStream class comment is 6016
>> characters here. Superclass ReferenceStream has a class comments of 2875
>> characters. DataStream and ReferenceStream have class methods that start
>> with 'example'. Looking for references to these classes also brings
>> useful examples of usage.
>>
>> In any case, the usual way to serialize classes is fileOut. Why doesn't
>> this work for you? What problem are you trying to solve?
>>
>> Cheers,
>> Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/cda299f0/attachment-0004.html>

From dnorton at mindspring.com  Fri Nov  6 15:21:21 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 06 Nov 2015 16:21:21 -0500
Subject: [Cuis] Unknown File Dialogue
Message-ID: <563D19D1.11201.12C21F7@dnorton.mindspring.com>

Hello,

In FmFileEntry>>fileContents, a dialogue is presented if there is an attempt to read a file 
which does not exist. This gives the opportunity to choose another name or cancel.

A "Cancel" response produces MNU: #contents

To avoid the MNU and answer nil, I suggest the attached change be made to #fileContents.

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FmFileEntry-fileContents.zip
Type: application/zip
Size: 456 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/46db3fe0/attachment-0004.zip>

From edgardec2005 at gmail.com  Sat Nov  7 05:31:06 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sat, 07 Nov 2015 08:31:06 -0300
Subject: [Cuis] serialization in Cuis
In-Reply-To: <563CF5F4.1070808@jvuletich.org>
Message-ID: <D263674C.16FF1%edgardec2005@gmail.com>

As Juan said, ReferenceStream is your friend
Here I attach a old cs
If you wish , Foo saveOnFileNamed: 'Foo'create a Foo.obj file in your
working directory.
Later you could use readAndInspect: 'Path to your file'
When you have DrgaAndDrop as my forked CuiSantafesino you could exchange
working objects between Squeak,Cuis and Pharo.
And if you said Pharo do not have ReferenceStream , well I made how to for
Pharo 2.0 so is possible.
With this technique I export and import objects big enough for have complete
swiki into a Squeak derivate image, about 14 mb of data
Cheers

Edgar
@morplenauta




On 11/6/15, 3:48 PM, "Juan Vuletich" <juan at jvuletich.org> wrote:

>  Hi Nacho,
>  
>  Oh, yes, I misread. Ok. ReferenceStream and SmartRefStream are your choices.
> Take a look at the class comments, play with the examples. Ask questions.
>  
>  Cheers,
>  Juan Vuletich
>  
>  
>  On 11/6/2015 3:42 PM, Ignacio Sniechowski wrote:
>>   
>> Hi Juan,
>>  
>> Thanks for your response.
>>  
>> I?m not trying to serialize classes but instances of them.
>>  
>> Suppose theres a class called Memo with an ivar ?content?
>>  
>> Then I want to be able add to the instances the posibility of storing their
>> data.
>>  
>> fileOut is great for classes I use it a lot!
>>  
>> But I want a way to preserve data outside the image, so it can be loaded when
>> a new image is used.
>>  
>> thanks!
>>  
>> Nacho
>>  
>> 
>>  
>>  
>>  
>>  
>> --?
>>  Ignacio Sniechowski
>>  
>> Prosavic SRL
>>  Sent with Airmail
>>  
>>  
>>  
>> 
>> On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org) wrote:
>>  
>>>  
>>>  
>>> Hi Nacho, 
>>>  
>>>  On 11/1/2015 11:45 PM, nacho wrote:
>>>>  > Hi Folks, 
>>>>  > I'm trying to add support for serializing instances of a class.
>>>>  > I'm looking at System-Object Storage
>>>>  > And in particular to the class SmartRefStream which seems to add that
>>>>  > functionality. However, the class has no comments and no examples.
>>>>  > Is there some example which uses this class? a short demo? an example?
>>>>  > Thanks in advance!!
>>>>  > best 
>>>>  > Nacho 
>>>>  > 
>>>  
>>>  Are we browsing the same system? SmartRefStream class comment is 6016
>>>  characters here. Superclass ReferenceStream has a class comments of 2875
>>>  characters. DataStream and ReferenceStream have class methods that start
>>>  with 'example'. Looking for references to these classes also brings
>>>  useful examples of usage.
>>>  
>>>  In any case, the usual way to serialize classes is fileOut. Why doesn't
>>>  this work for you? What problem are you trying to solve?
>>>  
>>>  Cheers, 
>>>  Juan Vuletich 
>>>  
>>>  
>>>  
>>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151107/b0b7510f/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ObjectEnhEd.2.cs
Type: application/octet-stream
Size: 15734 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151107/b0b7510f/attachment-0004.obj>

From hannes.hirzel at gmail.com  Sat Nov  7 08:49:21 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 7 Nov 2015 15:49:21 +0100
Subject: [Cuis] serialization in Cuis
In-Reply-To: <D263674C.16FF1%edgardec2005@gmail.com>
References: <563CF5F4.1070808@jvuletich.org>
	<D263674C.16FF1%edgardec2005@gmail.com>
Message-ID: <CAGQxfVh391ZLuY4TDE3tLw+i=ZF4vNEMn3_ZL-29Sj-fTmv0GQ@mail.gmail.com>

Hello Nacho

Is it possible that your Cuis system does not show the class comments
for some reason?

Juan referred you to the class comment of ReferenceStream and the
subclass SmartreferenceStream.

The comment of class ReferenceStream below. It gives an example how to
store objects.

Regards
Hannes


---------------------------------
Comment of class ReferenceStream in Cuis 4.2-2563


This is a way of serializing a tree of objects into disk file. A
ReferenceStream can store
one or more objects in a persistent form, including sharing and cycles.

Here is the way to use DataStream and ReferenceStream:
	rr _ ReferenceStream fileNamed: 'test.obj'.
	rr nextPut: <your object>.
	rr close.

To get it back:
	rr _ ReferenceStream fileNamed: 'test.obj'.
	<your object> _ rr next.
	rr close.

ReferenceStreams can now write "weak" references. nextPutWeak:
writes a "weak" reference to an object, which refers to that object
*if* it also gets written to the stream by a normal nextPut:.

A ReferenceStream should be treated as a read-stream *or* as a
write-stream, *not* as a read/write-stream. The reference-remembering
mechanism would probably do bad things if you tried to read and write
from the same ReferenceStream.

[TBD] Should we override "close" to do (self forgetReferences)?

Instance variables
 references -- an IdentityDictionary mapping objects already written
	to their byteStream positions. If asked to write any object a
	second time, we just write a reference to its stream position.
	This handles shared objects and reference cycles between objects.
	To implement "weak references" (for Aliases), the references
	dictionary also maps objects not (yet?) written to a Collection
	of byteStream positions with hopeful weak-references to it. If
	asked to definitely write one of these objects, we'll fixup those
	weak references.
 objects -- an IdentityDictionary mapping relative byte stream positions to
	objects already read in. If asked to follow a reference, we
	return the object already read.
	This handles shared objects and reference cycles between objects.
 currentReference -- the current reference position. Positon relative to the
	start of object data in this file.  (Allows user to cut and paste smalltalk
	code from the front of the file without effecting the reference values.)
	This variable is used to help install each new object in "objects" as soon
	as it's created, **before** we start reading its contents, in
	case any of its content objects reference it.
 fwdRefEnds -- A weak reference can be a forward reference, which
	requires advance-reading the referrent. When we later come to the
	object, we must get its value from "objects" and not re-read it so
	refs to it don't become refs to copies. fwdRefEnds remembers the
	ending byte stream position of advance-read objects.
 skipping -- true if <what?>

If the object is referenced before it is done being created, it might
get created twice.  Just store the object the moment it is created in
the 'objects' dictionary.  If at the end, comeFullyUpOnReload returns
a different object, some refs will have the temporary object (this is
an unlikely case).  At the moment, no implementor of
comeFullyUpOnReload returns a different object except DiskProxy, and
that is OK.


On 11/7/15, Edgar J. De Cleene <edgardec2005 at gmail.com> wrote:
> As Juan said, ReferenceStream is your friend
> Here I attach a old cs
> If you wish , Foo saveOnFileNamed: 'Foo'create a Foo.obj file in your
> working directory.
> Later you could use readAndInspect: 'Path to your file'
> When you have DrgaAndDrop as my forked CuiSantafesino you could exchange
> working objects between Squeak,Cuis and Pharo.
> And if you said Pharo do not have ReferenceStream , well I made how to for
> Pharo 2.0 so is possible.
> With this technique I export and import objects big enough for have
> complete
> swiki into a Squeak derivate image, about 14 mb of data
> Cheers
>
> Edgar
> @morplenauta
>
>
>
>
> On 11/6/15, 3:48 PM, "Juan Vuletich" <juan at jvuletich.org> wrote:
>
>>  Hi Nacho,
>>
>>  Oh, yes, I misread. Ok. ReferenceStream and SmartRefStream are your
>> choices.
>> Take a look at the class comments, play with the examples. Ask questions.
>>
>>  Cheers,
>>  Juan Vuletich
>>
>>
>>  On 11/6/2015 3:42 PM, Ignacio Sniechowski wrote:
>>>
>>> Hi Juan,
>>>
>>> Thanks for your response.
>>>
>>> I?m not trying to serialize classes but instances of them.
>>>
>>> Suppose theres a class called Memo with an ivar ?content?
>>>
>>> Then I want to be able add to the instances the posibility of storing
>>> their
>>> data.
>>>
>>> fileOut is great for classes I use it a lot!
>>>
>>> But I want a way to preserve data outside the image, so it can be loaded
>>> when
>>> a new image is used.
>>>
>>> thanks!
>>>
>>> Nacho
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>  Ignacio Sniechowski
>>>
>>> Prosavic SRL
>>>  Sent with Airmail
>>>
>>>
>>>
>>>
>>> On November 6, 2015 at 3:13:25 PM, Juan Vuletich (juan at jvuletich.org)
>>> wrote:
>>>
>>>>
>>>>
>>>> Hi Nacho,
>>>>
>>>>  On 11/1/2015 11:45 PM, nacho wrote:
>>>>>  > Hi Folks,
>>>>>  > I'm trying to add support for serializing instances of a class.
>>>>>  > I'm looking at System-Object Storage
>>>>>  > And in particular to the class SmartRefStream which seems to add
>>>>> that
>>>>>  > functionality. However, the class has no comments and no examples.
>>>>>  > Is there some example which uses this class? a short demo? an
>>>>> example?
>>>>>  > Thanks in advance!!
>>>>>  > best
>>>>>  > Nacho
>>>>>  >
>>>>
>>>>  Are we browsing the same system? SmartRefStream class comment is 6016
>>>>  characters here. Superclass ReferenceStream has a class comments of
>>>> 2875
>>>>  characters. DataStream and ReferenceStream have class methods that
>>>> start
>>>>  with 'example'. Looking for references to these classes also brings
>>>>  useful examples of usage.
>>>>
>>>>  In any case, the usual way to serialize classes is fileOut. Why
>>>> doesn't
>>>>  this work for you? What problem are you trying to solve?
>>>>
>>>>  Cheers,
>>>>  Juan Vuletich
>>>>
>>>>
>>>>
>>>
>
>



From dnorton at mindspring.com  Sat Nov  7 20:12:43 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 07 Nov 2015 21:12:43 -0500
Subject: [Cuis] BouncingAtomsMorph
Message-ID: <563EAF9B.28589.26788EA@dnorton.mindspring.com>

Hi Juan,

Thanks for fixing it so that #doOneCycleNow is no longer needed during initialization. 
The code reads much better.

Next time you build, please update from my repo:

	https://github.com/dhnorton/Cuis-Smalltalk-atoms

I made the following changes:

	- added #open method in case someone wants to bring it up from the browser 
or a workspace (old way no longer works).
	- HeaterCoolerAtoms no longer affect each other when they collide.
	- appearance tweaks to HeaterCoolerAtoms.
	- improved the initial movement and distribution of atoms.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151107/005040c8/attachment-0004.html>

From euanmee at gmail.com  Sun Nov  8 10:18:57 2015
From: euanmee at gmail.com (Euan Mee)
Date: Sun, 8 Nov 2015 16:18:57 +0000
Subject: [Cuis] Current state of activity
Message-ID: <CALsRT0m1o_aask7bPD6_RHq7dePHFJUBULKHKeqbW7+MavBgWg@mail.gmail.com>

Hi, I'm a newcomer to Cuis.

The main web-site was last updated in July 2013

How active is CUIS atm.?

Is it fair to characterise CUIS as a minimalist image for running on
top of the current latest Squeak VMs  e.g. Cog with Spur (and with the
Scorch and Sista upgrades once they are out?)

I'm looking to build Smalltalk apps to control, manage, set up and
distribute multi-platform mobile web-apps.

So what I'm looking for is a Smalltalk development environment and
development management environment
an http server and an https server
a multi-platform (Windows, Linux, MacOS) desktop GUI environment and
desktop GUI apps
a web framework

My ideal is a central desktop GUI app that can run from a Raspberry Pi
which is also running a webserver which hands out JS apps securely to
mobile devices.

I'm happy to with development work, or help backport necessary items
from Squeak/Pharo

Cheers,
     EuanM



From juan at jvuletich.org  Mon Nov  9 06:42:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 09 Nov 2015 09:42:43 -0300
Subject: [Cuis] Current state of activity
In-Reply-To: <CALsRT0m1o_aask7bPD6_RHq7dePHFJUBULKHKeqbW7+MavBgWg@mail.gmail.com>
References: <CALsRT0m1o_aask7bPD6_RHq7dePHFJUBULKHKeqbW7+MavBgWg@mail.gmail.com>
Message-ID: <564094C3.3070001@jvuletich.org>

Hi Euan,

On 11/8/2015 1:18 PM, Euan Mee wrote:
> Hi, I'm a newcomer to Cuis.

Welcome!

> The main web-site was last updated in July 2013
>
> How active is CUIS atm.?

Quite. See 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors 
. Mail lista rchives are at 
http://forum.world.st/Cuis-Smalltalk-f4632260.html .

> Is it fair to characterise CUIS as a minimalist image for running on
> top of the current latest Squeak VMs  e.g. Cog with Spur (and with the
> Scorch and Sista upgrades once they are out?)

Yes. In any case, see 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/GettingStarted-UsingGitAndCommandline.md 
and sibling files .

> I'm looking to build Smalltalk apps to control, manage, set up and
> distribute multi-platform mobile web-apps.
>
> So what I'm looking for is a Smalltalk development environment and
> development management environment
> an http server and an https server
> a multi-platform (Windows, Linux, MacOS) desktop GUI environment and
> desktop GUI apps
> a web framework
>
> My ideal is a central desktop GUI app that can run from a Raspberry Pi
> which is also running a webserver which hands out JS apps securely to
> mobile devices.

Interesting! Please keep us posted.

> I'm happy to with development work, or help backport necessary items
> from Squeak/Pharo
>

Great. As you progress, you'll find out about stuff you need to develop 
or port to Cuis. Contributions to the base image, or optional packages 
are all welcome (please remember that to be added to the main GitHub 
Cuis repo, all code needs to be MIT). Besides, here on the mail list, 
you can discuss any issues, ask for opinions or advice, or for existing 
code, etc.

> Cheers,
>       EuanM

Cheers,
Juan Vuletich



From 0800nacho at gmail.com  Mon Nov  9 18:53:16 2015
From: 0800nacho at gmail.com (nacho)
Date: Mon, 9 Nov 2015 16:53:16 -0800 (PST)
Subject: [Cuis] Symbols that start with and uppercase letter
Message-ID: <1447116796630-4860091.post@n4.nabble.com>

Hi Folks,
I'm trying to generate a collection from all instances of Symbol that begin
with a capital letter.
I know how to do this for one case:

| aSymbolArray aSymbol |

aSymbolArray _ Symbol allInstances.
aSymbol _ (aSymbolArray at: 1).
(aSymbol at: 1) isUppercase.

But I want to use something like collect:
| aSymbolArray |

aSymbolArray _ Symbol allInstances.
aSymbolArray collect: [ :a | | aSymbol | aSymbol _ aSymbolArray at: a.
(aSymbol at: 1) isUppercase].

But I'm lost.
Any help?
Thanks in advance!
best
Nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Symbols-that-start-with-and-uppercase-letter-tp4860091.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Mon Nov  9 21:12:26 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Mon, 9 Nov 2015 19:12:26 -0800
Subject: [Cuis] Symbols that start with and uppercase letter
In-Reply-To: <1447116796630-4860091.post@n4.nabble.com>
References: <1447116796630-4860091.post@n4.nabble.com>
Message-ID: <20151109191226.d42159dd728b6a0d5a7d1548@Whidbey.com>

On Mon, 9 Nov 2015 16:53:16 -0800 (PST)
nacho <0800nacho at gmail.com> wrote:

> Hi Folks,
> I'm trying to generate a collection from all instances of Symbol that begin
> with a capital letter.

Symbol allInstances select: [ :s | (s size > 0) and: [(s asString at: 1) isUppercase ]].

Cheers, 
-KenD



From euanmee at gmail.com  Wed Nov 11 08:13:57 2015
From: euanmee at gmail.com (Euan Mee)
Date: Wed, 11 Nov 2015 14:13:57 +0000
Subject: [Cuis] Simple Morphic
Message-ID: <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w@mail.gmail.com>

What is the current state of development of Simple Morph?

Is there any documentation on how to use it, or is it allInTheCode ?



From Ken.Dickey at Whidbey.com  Wed Nov 11 10:13:58 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Wed, 11 Nov 2015 08:13:58 -0800
Subject: [Cuis] Simple Morphic
In-Reply-To: <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w@mail.gmail.com>
References: <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w@mail.gmail.com>
Message-ID: <20151111081358.4a0291315670cadcdcead39f@Whidbey.com>

On Wed, 11 Nov 2015 14:13:57 +0000
Euan Mee <euanmee at gmail.com> wrote:

> What is the current state of development of Simple Morph?

I am not sure what you mean by Simple Morph.

Cuis has been taking steps toward Morphic3:

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md

The MorphExtension class was removed.  (We have Morph Properties).

Morphs have float rather than integer location coordinates.

Morph location is relative to their owner, not the screen.

These are relatively small changes to get used to.

More radical are some of the other simplifications in the system.

The best example here is probably Layout.

LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.

The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.

See LayoutMorph class examples.

If you git clone the Morphic-Misc1 package and load it you can get Layout editors:

Open a shell and cd to the directory containing Cuis-Smalltalk-Dev

  git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git

Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:

  Feature require:  'Morphic-Misc1'.

Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.  

Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.

If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.

> Is there any documentation on how to use it, or is it allInTheCode ?

See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.

-- 
-KenD



From euanmee at gmail.com  Wed Nov 11 13:02:54 2015
From: euanmee at gmail.com (Euan Mee)
Date: Wed, 11 Nov 2015 19:02:54 +0000
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
Message-ID: <CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>

Thanks for the pointer to Morphic3 and its documentation.  I'll try to
contribute more naive-user questions :-)

What is the state of development of Morphic3?
  - complete stable codebase?
  - stable codebase for substantial parts, with fuurther extensions in
development?
  - central aspects still under development?
  - a design concept, coding yet to begin?

e.g. The documentation starts off with "Morphic3 *will have* scalable
graphics".  This might mean that Morphic3 works now, but does not yet
have scalable graphics.  Or it might just mean Morphic3 does not (yet)
work.

Generally, whenever I'm looking at a new platform, system, or package,
I am initially looking for answers of the type
   "Can I use it now?
        No /
        Yes /
        Yes to an extent, but..."

I'm very happy to write up aspects of the system/package as
fully-formed documentation, especially documentation for naive-users.
Please let me know if there specific places where this help is
already-known to be particularly needed.

I look forward (in the long run?) to trying Cuis and Morphic3 on Raspberry Pi.

On 11 November 2015 at 18:00,  <cuis-request at jvuletich.org> wrote:
> Send Cuis mailing list submissions to
>         cuis at jvuletich.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> or, via email, send a message with subject or body 'help' to
>         cuis-request at jvuletich.org
>
> You can reach the person managing the list at
>         cuis-owner at jvuletich.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cuis digest..."
>
>
> Today's Topics:
>
>    1. Simple Morphic (Euan Mee)
>    2. Re: Simple Morphic (KenD)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 11 Nov 2015 14:13:57 +0000
> From: Euan Mee <euanmee at gmail.com>
> To: cuis at jvuletich.org
> Subject: [Cuis] Simple Morphic
> Message-ID:
>         <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> What is the current state of development of Simple Morph?
>
> Is there any documentation on how to use it, or is it allInTheCode ?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 11 Nov 2015 08:13:58 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: Euan Mee <euanmee at gmail.com>
> Subject: Re: [Cuis] Simple Morphic
> Message-ID: <20151111081358.4a0291315670cadcdcead39f at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Wed, 11 Nov 2015 14:13:57 +0000
> Euan Mee <euanmee at gmail.com> wrote:
>
>> What is the current state of development of Simple Morph?
>
> I am not sure what you mean by Simple Morph.
>
> Cuis has been taking steps toward Morphic3:
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>
> The MorphExtension class was removed.  (We have Morph Properties).
>
> Morphs have float rather than integer location coordinates.
>
> Morph location is relative to their owner, not the screen.
>
> These are relatively small changes to get used to.
>
> More radical are some of the other simplifications in the system.
>
> The best example here is probably Layout.
>
> LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.
>
> The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.
>
> See LayoutMorph class examples.
>
> If you git clone the Morphic-Misc1 package and load it you can get Layout editors:
>
> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>
>   git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>
> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:
>
>   Feature require:  'Morphic-Misc1'.
>
> Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>
> Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.
>
> If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.
>
>> Is there any documentation on how to use it, or is it allInTheCode ?
>
> See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.
>
> --
> -KenD
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 41, Issue 14
> ************************************



From euanmee at gmail.com  Wed Nov 11 13:41:24 2015
From: euanmee at gmail.com (Euan Mee)
Date: Wed, 11 Nov 2015 19:41:24 +0000
Subject: [Cuis] Simple Morphic
Message-ID: <CALsRT0=_8W2iHB4amNP_V95H0S_HhbtPYh8yjG_tcXgeQs2c8g@mail.gmail.com>

Thanks for the pointer to Morphic3 and its documentation.  I'll try to
contribute more naive-user questions :-)

What is the state of development of Morphic3?
  - complete stable codebase?
  - stable codebase for substantial parts, with fuurther extensions in
development?
  - central aspects still under development?
  - a design concept, coding yet to begin?

e.g. The documentation starts off with "Morphic3 *will have* scalable
graphics".  This might mean that Morphic3 works now, but does not yet
have scalable graphics.  Or it might just mean Morphic3 does not (yet)
work.

Generally, whenever I'm looking at a new platform, system, or package,
I am initially looking for answers of the type
   "Can I use it now?
        No /
        Yes /
        Yes to an extent, but..."

I'm very happy to write up aspects of the system/package as
fully-formed documentation, especially documentation for naive-users.
Please let me know if there specific places where this help is
already-known to be particularly needed.

I look forward (in the long run?) to trying Cuis and Morphic3 on Raspberry Pi.

In the meantime, I'm catching up on what's written at:
https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1
and
https://github.com/KenDickey/Cuis-Smalltalk-ColorEditor


On 11 November 2015 at 16:13, KenD <Ken.Dickey at whidbey.com> wrote:
> On Wed, 11 Nov 2015 14:13:57 +0000
> Euan Mee <euanmee at gmail.com> wrote:
>
>> What is the current state of development of Simple Morph?
>
> I am not sure what you mean by Simple Morph.
>
> Cuis has been taking steps toward Morphic3:
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>
> The MorphExtension class was removed.  (We have Morph Properties).
>
> Morphs have float rather than integer location coordinates.
>
> Morph location is relative to their owner, not the screen.
>
> These are relatively small changes to get used to.
>
> More radical are some of the other simplifications in the system.
>
> The best example here is probably Layout.
>
> LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.
>
> The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.
>
> See LayoutMorph class examples.
>
> If you git clone the Morphic-Misc1 package and load it you can get Layout editors:
>
> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>
>   git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>
> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:
>
>   Feature require:  'Morphic-Misc1'.
>
> Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>
> Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.
>
> If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.
>
>> Is there any documentation on how to use it, or is it allInTheCode ?
>
> See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.
>
> --
> -KenD



From Ken.Dickey at Whidbey.com  Wed Nov 11 17:56:37 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Wed, 11 Nov 2015 15:56:37 -0800
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
Message-ID: <20151111155637.a6fc5a89ab8ca768aa93510a@Whidbey.com>

On Wed, 11 Nov 2015 19:02:54 +0000
Euan Mee <euanmee at gmail.com> wrote:

> What is the state of development of Morphic3?

Juan is working on an optimized MorphicCanvas to replace BitBltCanvas.

There is some old, unoptimized sample code in Cuis-Smalltalk-Dev/Experimental which is not for the faint of heart.

Cuis currently uses BitBltCanvas, so the graphics do not yet scale.

Most of the other code works fine.  The location changes to Morph were a big step.

Juan has been slimming down the Cuis image so that it should be possible to rapidly grow when scalable.  Slim down .. grow .. scale  ;^)

Note the small number of classes in the base image:
"2236 eToys 5.0"
"2511 Squeak 4.4"
"2175 Squeak 4.5"
"2244 Squeak 5.0"
"3226 Pharo 2.0"
"4020 Pharo 3.0"
"4924 Pharo 4.0"
  vvv
" 504 Cuis 4.2 (rev 2568)"
  ^^^

Juan, anything to add/correct here?

-- 
-KenD



From pbpublist at gmail.com  Wed Nov 11 20:05:36 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 11 Nov 2015 21:05:36 -0500
Subject: [Cuis] Simple Morphic
In-Reply-To: <CALsRT0=_8W2iHB4amNP_V95H0S_HhbtPYh8yjG_tcXgeQs2c8g@mail.gmail.com>
References: <CALsRT0=_8W2iHB4amNP_V95H0S_HhbtPYh8yjG_tcXgeQs2c8g@mail.gmail.com>
Message-ID: <1447293936.10654.37.camel@gmail.com>

Hi Euan,

On Wed, 2015-11-11 at 19:41 +0000, Euan Mee wrote:
> I am initially looking for answers of the type
> ???"Can I use it now?
> ????????No /
> ????????Yes /
> ????????Yes to an extent, but..."
> 

The short answer is no. ?It's still at an experimental / work in
progress stage. ?As Ken mentioned, you can take a look at a snapshot of
the code but it's not in a state where you can enable it and have
things even mostly work or be productive with it as your GUI. ?There's
still much work to be done: functionality to be added, bugs to be
fixed, performance to be tuned etc.

Thanks,
Phil



From dnorton at mindspring.com  Thu Nov 12 18:46:26 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 12 Nov 2015 19:46:26 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <564532E2.5884.24794CB@dnorton.mindspring.com>

Hi Juan,

On 3 Nov 2015 at 14:58, Dan Norton wrote:

> Hi Juan,
> 
> As recommended by Ken and Hannes, the attached methods add the
> capability to bring up 
> the class comment browser from the help menu.
> 
> Sorry, but I still don't know how to prepend the thumbnail to the
> menu item :)
> 

Found how to do it! The attached change to Theme>>basicIcons makes the Help icon 
appear for Class Comment Browser. Please include in the next build.

Thanks,
 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Theme-basicIcons.zip
Type: application/zip
Size: 1289 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151112/435f9b9a/attachment-0004.zip>

From dnorton at mindspring.com  Fri Nov 13 11:58:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 13 Nov 2015 12:58:22 -0500
Subject: [Cuis] #when:send:to:
Message-ID: <564624BE.15549.F1568C@dnorton.mindspring.com>

Hello Everyone,

The following repo contains before and after examples of replacing the Dependency 
Mechanism with the Observer Pattern:

	https://github.com/dhnorton/Cuis-Smalltalk-light

Please take a look at this and tell me what needs to change. I'm trying to supply an example 
of the Observer Pattern so that others might use #when:send:to: with less difficulty than I 
experienced. There may be better examples but I picked one from the Blue Book.

It seems that #when:send:to: is necessary but not sufficient as a replacement for the 
Dependency Mechanism. In this example, it replaced #addDependent:, not #changed or 
#update and I am still not comfortable with how to choose the parameters. This may be an 
example of the difficulty in explaining the obvious, I'm not sure :-)

The #changed method was replaced with #triggerEvent: with a symbol argument which is 
referred to in one of the arguments of #when:send:to: and that's the only constraint AFAICT.

The #update: method was retained, as a convenience; it also needs to agree with one of the 
arguments of #when:send:to: and could have been different.

Please tell me if any of this is wrong. Thanks.

 - Dan 



From Ken.Dickey at Whidbey.com  Fri Nov 13 20:33:24 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Fri, 13 Nov 2015 18:33:24 -0800
Subject: [Cuis] #when:send:to:
In-Reply-To: <564624BE.15549.F1568C@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>
Message-ID: <20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>

On Fri, 13 Nov 2015 12:58:22 -0500
"Dan Norton" <dnorton at mindspring.com> wrote:

> Hello Everyone,
> 
> The following repo contains before and after examples of replacing the Dependency 
> Mechanism with the Observer Pattern:
> 
> 	https://github.com/dhnorton/Cuis-Smalltalk-light
> 
> Please take a look at this and tell me what needs to change.

Dan,

Good start.

I would suggest a deeper example.

Lights could be a model with a presenter (LightPanel) which shows the lights.  E.g. open a layout morph with a row of elipses (circles) which are red/green (or whatever) for off/on.

Clicking on a light changes the model (Lights subclass ActiveModel), which signals 
  triggerEvent: #colorChange with: aColor.

You can look in Morphic-Misc1 at RadioButtonMorph to see how to handle clicks.

Workspace code could also turn off/on or just toggle lights in the model, with the LightPanel presenter updating appropriately.

One can then add a bit of wackyness, like using different colors than red/green and the presenter will show the proper color..

$0.02.
-KenD 



From euanmee at gmail.com  Fri Nov 13 23:02:53 2015
From: euanmee at gmail.com (EuanM)
Date: Sat, 14 Nov 2015 05:02:53 +0000
Subject: [Cuis] New Introductory Tutorial
Message-ID: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>

I've created Yet Another Smalltalk First
Steps tutorial.

This is intended as one of a series.

It is designed to be cross-platform across

    Squeak 5
    Pharo 4
    Seaside 3.1
    Cuis
    Dolphin 6

If you have experience running any of these systems on Windows, Linux
or MacOS, please check to see if I have the instructions correct for
your chosen pairing of Smalltalk and OS platform.

(As you'll see when you look, I do not have detailed instructions for
aspects of MacOS).

The document is at:
http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html

(It's intended to move to a different blog after this review process).

I feel the need to do this as cross-Smalltalks tutorial because of
findings and 4 charts  I've placed at:
http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/mindshare-of-smalltalk-in-development.html

Essentially, Smalltalk mindshare and use is incredibly tiny, compared
to other languages in the same space.  (We all know this, but seeing
it represented graphically has a more visceral effect, IMO)

Aggregating interest in all the Smalltalks still does not bring more
than a tiny proportion of the interest in, and use of, Ruby.

In turn, Ruby is (quite understandably) small in comparison to JavaScript.

Comparing interest in any specific Smalltalk is, predictably, smaller
than the aggregate interest in Smalltalk.

Our community seems determined to split itself into smaller and
smaller sub-communities.  I think we do ourselves a disservice this
way.

My initial contribution will be to try to provide some explicitly
pan-Smalltalk beginners' tutorials, like this one.

Cheers, and happy Smalltalking,
     EuanM



From euanmee at gmail.com  Fri Nov 13 23:12:31 2015
From: euanmee at gmail.com (EuanM)
Date: Sat, 14 Nov 2015 05:12:31 +0000
Subject: [Cuis] One-Click Installer for Cuis
Message-ID: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>

I've just recently put-together a cross-platform Installation Tutorial
for beginners to Smalltalk.

I was keen to include Cuis in the exercise.

One thing that becomes clear in the comparison is that Cuis is a good
beginner's environment from the point of view of size and complexity
and their bearing in learnability.

It is however, the worst Smalltalk (of the 4 in the tutorial) to get
downloaded and installed.

This seems a pity.

Would anyone be willing to help me put together a One-Click Install
package, similar to Squeak's and Pharo's?

(My plan is to do the grunt-work, if other people are willing to
indulge my noob questions while I do it)

Is there a particular place that it could be hosted, once ready?

Would anyone disagree with a 6-monthly update cycle for the One-Click installer?

(Frequent enough to send a signal to interested beginners that the
project is alive and kicking.  Infrequent enough that there is not
much work to be done)

Cheers,
   Euan



From hari.balaraman at icloud.com  Sat Nov 14 08:37:34 2015
From: hari.balaraman at icloud.com (Hari Balaraman)
Date: Sat, 14 Nov 2015 11:37:34 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <563CF53B.5000107@jvuletich.org>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
Message-ID: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>

Hi Juan,

It was very nice to sit down and chat with you on the sidelines of the conference. Thank you for taking the time to look at my stuttering project and offer advice (on the history of projects, strangely, some others I talked to didn?t recognise the names Mark Guzdial and Bijan Parsia.) Although I missed first two days because of careless travel planning, I?m hoping FAST will put videos of the presentations on the website so I can catch up. 

The two people at Toronto Smalltalk Users Group I mentioned are Bob Nemec and Dave Mason, a professor at Ryerson University. My knowledge of the use of SmallTalk in the CS curriculum there is second or third-hand and so may not be current. I haven?t actually met them as the one Monday evening I was able to make it to TSUG, I was late and both of them had left by then. :)

Thanks for the tip on visiting the bookshops on Avenida Corrientes in this amazing city. I passed it on the way home and realised I haven?t gone down this street in my wanderings. If you are going to be in the city before Tuesday afternoon, and are free and bored, do let me know.

Best regards,

Hari
>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org <mailto:juan at jvuletich.org>) wrote:
>> 
>>> Hi Hari,
>>> 
>>> I'll be there. Let's meet then.
>>> 
>>> Anybody else?
>>> 
>>> Cheers,
>>> Juan Vuletich
>>> 
>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>> 
>>>> If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
>>>> Best regards,
>>>> Hari
>>>> 
>>>> _______________________________________________
>>>> Cuis mailing list
>>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>>> 
>>> _______________________________________________ 
>>> Cuis mailing list 
>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org> 
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151114/17eb3e43/attachment-0004.html>

From 0800nacho at gmail.com  Sat Nov 14 09:45:12 2015
From: 0800nacho at gmail.com (nacho)
Date: Sat, 14 Nov 2015 07:45:12 -0800 (PST)
Subject: [Cuis] FAST conference
In-Reply-To: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
References: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
Message-ID: <1447515912161-4861043.post@n4.nabble.com>

I agree with Hari,
It was very nice to meet you Juan.
Thanks for your work and advice.
Best
Nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/FAST-conference-tp4859418p4861043.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Sat Nov 14 10:09:22 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sat, 14 Nov 2015 08:09:22 -0800
Subject: [Cuis] New Introductory Tutorial
In-Reply-To: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
References: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
Message-ID: <20151114080922.9fc084ad463f841976311bb7@Whidbey.com>

On Sat, 14 Nov 2015 05:02:53 +0000
EuanM <euanmee at gmail.com> wrote:

> I've created Yet Another Smalltalk First
> Steps tutorial.
...
> If you have experience running any of these systems on Windows, Linux
> or MacOS, please check to see if I have the instructions correct for
> your chosen pairing of Smalltalk and OS platform.

On Linux, Cuis works fine from the command line once the proper SqueakVM is installed.

E.g. in the Cuis-Smalltalk-Dev directory
   squeak  Cuis4.2-2571.image

> The document is at:
> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html

The different Squeak VMs are transition points and might need some explanation.

The stack-interpreter VM is a traditional bytecode interpreter.

Cog does just-in-time (JIT) compilation to native code for faster execution.

Spur is a new memory model which simplifies object layouts and is common between 32 and 64 bit memory architectures.  Because of object format/layout changes Spur images must be run on a Spur VMs and non-Spur images on a non-Spur VM.  You have to match the VM to the object format.

As far as I am aware, there is no Spur image for Cuis yet.  We need to write a tool to read a current image and write it out in Spur format.  Spur code is still evolving rapidly, so writing the  image translation has not been a priority for us.  Now that Squeak 5.0 is out (the 4.x series used the old format, 5.0 uses Spur) things are probably stable enough that we can get to this.

-- 

One side note is that none of the Cog (JIT) VMs run on ARM Chromebooks under Chrome OS.  I don't run Intel, but suspect the JIT is broken there as well.  This apparently has to do with the tightening up of code security policies in the Chromium OS.  As JIT means writing data, then executing this as code, there is an obvious security hole to be addressed.

It appears that there are are/should be rubrics/rules which allow JIT.  The V8 JavaScript VM does JIT on ChromeOS.  But it takes time to dig through the megabytes of code and docs to get at the details.  This is in progress, but there is not much resource (people time) to devote to it.

FYI,
-KenD



From edgardec2005 at gmail.com  Sat Nov 14 15:29:34 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Sat, 14 Nov 2015 18:29:34 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
Message-ID: <BF8DA200-D5CF-424C-8168-F5568D5C2253@gmail.com>

Also i say very, very thanks for all your talks, time to listening my crazy ideas and tu calidez como ser humano
Too bad also  i going without plan .
We should schedule some hangouts when yo have the time.
Wish know Nacho and Hari , look for me on Facebook and start  Cuis Friendship
Again thanks Juan.




> On Nov 14, 2015, at 11:37 AM, Hari Balaraman <hari.balaraman at icloud.com> wrote:
> 
> Hi Juan,
> 
> It was very nice to sit down and chat with you on the sidelines of the conference. Thank you for taking the time to look at my stuttering project and offer advice (on the history of projects, strangely, some others I talked to didn?t recognise the names Mark Guzdial and Bijan Parsia.) Although I missed first two days because of careless travel planning, I?m hoping FAST will put videos of the presentations on the website so I can catch up. 
> 
> The two people at Toronto Smalltalk Users Group I mentioned are Bob Nemec and Dave Mason, a professor at Ryerson University. My knowledge of the use of SmallTalk in the CS curriculum there is second or third-hand and so may not be current. I haven?t actually met them as the one Monday evening I was able to make it to TSUG, I was late and both of them had left by then. :)
> 
> Thanks for the tip on visiting the bookshops on Avenida Corrientes in this amazing city. I passed it on the way home and realised I haven?t gone down this street in my wanderings. If you are going to be in the city before Tuesday afternoon, and are free and bored, do let me know.
> 
> Best regards,
> 
> Hari
>>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org <mailto:juan at jvuletich.org>) wrote:
>>> 
>>>> Hi Hari,
>>>> 
>>>> I'll be there. Let's meet then.
>>>> 
>>>> Anybody else?
>>>> 
>>>> Cheers,
>>>> Juan Vuletich
>>>> 
>>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>>> 
>>>>> If any of you are attending the FAST conference in Buenos Aires in a week or so, I look forward to meeting you face to face.
>>>>> Best regards,
>>>>> Hari
>>>>> 
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>>>> 
>>>> _______________________________________________ 
>>>> Cuis mailing list 
>>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org> 
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org <http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> 
>> 
>> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151114/e42bf08f/attachment-0004.html>

From dnorton at mindspring.com  Sun Nov 15 12:47:00 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 15 Nov 2015 13:47:00 -0500
Subject: [Cuis] #when:send:to:
In-Reply-To: <20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>
Message-ID: <5648D324.31295.859AEA@dnorton.mindspring.com>

On 13 Nov 2015 at 18:33, KenD wrote:

> On Fri, 13 Nov 2015 12:58:22 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> > Hello Everyone,
> > 
> > The following repo contains before and after examples of replacing
> the Dependency 
> > Mechanism with the Observer Pattern:
> > 
> > 	https://github.com/dhnorton/Cuis-Smalltalk-light
> > 
> > Please take a look at this and tell me what needs to change.
> 
> Dan,
> 
> Good start.
> 
> I would suggest a deeper example.
> 

Hmm, I made it stark simple in order to focus on the basics. However, a couple of 
possibilities could be: a 3-bulb traffic light with a change button (incremental add-on), or a 
drag race tree (elaborate).

 - Dan

> Lights could be a model with a presenter (LightPanel) which shows
> the lights.  E.g. open a layout morph with a row of elipses
> (circles) which are red/green (or whatever) for off/on.
> 
> Clicking on a light changes the model (Lights subclass ActiveModel),
> which signals 
>   triggerEvent: #colorChange with: aColor.
> 
> You can look in Morphic-Misc1 at RadioButtonMorph to see how to
> handle clicks.
> 
> Workspace code could also turn off/on or just toggle lights in the
> model, with the LightPanel presenter updating appropriately.
> 
> One can then add a bit of wackyness, like using different colors
> than red/green and the presenter will show the proper color..
> 
> $0.02.
> -KenD 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From Ken.Dickey at Whidbey.com  Sun Nov 15 14:35:54 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sun, 15 Nov 2015 12:35:54 -0800
Subject: [Cuis] #when:send:to:
In-Reply-To: <5648D324.31295.859AEA@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>
	<20151113183324.351451e421e5e1703ab7d56d@Whidbey.com>
	<5648D324.31295.859AEA@dnorton.mindspring.com>
Message-ID: <20151115123554.1a6ce6591f522779d96f2aa6@Whidbey.com>

On Sun, 15 Nov 2015 13:47:00 -0500
"Dan Norton" <dnorton at mindspring.com> wrote:


> Hmm, I made it stark simple in order to focus on the basics. 

If a "light" does not have a visual representation, I would call it a "switch".

$0.02 
-KenD



From dnorton at mindspring.com  Sun Nov 15 21:20:16 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 15 Nov 2015 22:20:16 -0500
Subject: [Cuis] #when:send:to:
In-Reply-To: <20151115123554.1a6ce6591f522779d96f2aa6@Whidbey.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<5648D324.31295.859AEA@dnorton.mindspring.com>,
	<20151115123554.1a6ce6591f522779d96f2aa6@Whidbey.com>
Message-ID: <56494B70.22263.25B83DB@dnorton.mindspring.com>

On 15 Nov 2015 at 12:35, KenD wrote:

> On Sun, 15 Nov 2015 13:47:00 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> 
> > Hmm, I made it stark simple in order to focus on the basics. 
> 
> If a "light" does not have a visual representation, I would call it
> a "switch".
> 

Good point. I see the light of that; however, stark though it be, at least it lets you see state in 
the Transcript. The Blue Book used Light and TrafficLight then left you to use inspectors I 
presume. They didn't say :)

 - Dan



From juan at jvuletich.org  Mon Nov 16 12:53:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 15:53:49 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>
	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>
	<563CF22E.4080804@jvuletich.org>
	<etPan.563cf40e.77bd141b.a58@Unix.local>
	<563CF53B.5000107@jvuletich.org>
	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
Message-ID: <564A263D.9000808@jvuletich.org>

Hi Hari,

On 11/14/2015 11:37 AM, Hari Balaraman wrote:
> Hi Juan,
>
> It was very nice to sit down and chat with you on the sidelines of the 
> conference. Thank you for taking the time to look at my stuttering 
> project and offer advice (on the history of projects, strangely, some 
> others I talked to didn?t recognise the names Mark Guzdial and Bijan 
> Parsia.) Although I missed first two days because of careless travel 
> planning, I?m hoping FAST will put videos of the presentations on the 
> website so I can catch up.

It was my pleasure!

> The two people at Toronto Smalltalk Users Group I mentioned are Bob 
> Nemec and Dave Mason, a professor at Ryerson University. My knowledge 
> of the use of SmallTalk in the CS curriculum there is second or 
> third-hand and so may not be current. I haven?t actually met them as 
> the one Monday evening I was able to make it to TSUG, I was late and 
> both of them had left by then. :)

Nice to know, thanks.

> Thanks for the tip on visiting the bookshops on Avenida Corrientes in 
> this amazing city. I passed it on the way home and realised I haven?t 
> gone down this street in my wanderings. If you are going to be in the 
> city before Tuesday afternoon, and are free and bored, do let me know.

Well, during the weekend I tried to spend some time with family. Also on 
Saturday we spent time with other fellow Smalltalkers, including the 
organizers, and their families. So, I only read this today. If you are 
still around on Tuesday evening, we can drink some beer, coffee, 
whatever, after office. If you leave on Tuesday afternoon, maybe we can 
have lunch tomorrow Tuesday. The rest of the day I'm at work, as you 
would expect... :)

Cheers,
Juan Vuletich

> Best regards,
>
> Hari
>>>
>>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich (juan at jvuletich.org 
>>> <mailto:juan at jvuletich.org>) wrote:
>>>
>>>> Hi Hari,
>>>>
>>>> I'll be there. Let's meet then.
>>>>
>>>> Anybody else?
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>>> If any of you are attending the FAST conference in Buenos Aires in 
>>>>> a week or so, I look forward to meeting you face to face.
>>>>> Best regards,
>>>>> Hari
>>>>>
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>
>>>> _______________________________________________
>>>> Cuis mailing list
>>>> Cuis at jvuletich.org
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/1347cb49/attachment-0004.html>

From juan at jvuletich.org  Mon Nov 16 14:04:37 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 17:04:37 -0300
Subject: [Cuis] BouncingAtomsMorph
In-Reply-To: <563EAF9B.28589.26788EA@dnorton.mindspring.com>
References: <563EAF9B.28589.26788EA@dnorton.mindspring.com>
Message-ID: <564A36D5.5010109@jvuletich.org>

On 11/7/2015 11:12 PM, Dan Norton wrote:
> Hi Juan,
>
> Thanks for fixing it so that #doOneCycleNow is no longer needed during 
> initialization. The code reads much better.
>
>
> Next time you build, please update from my repo:
>
>            https://github.com/dhnorton/Cuis-Smalltalk-atoms
>
> I made the following changes:
>
>            - added #open method in case someone wants to bring it up 
> from the browser or a workspace (old way no longer works).
>            - HeaterCoolerAtoms no longer affect each other when they 
> collide.
>            - appearance tweaks to HeaterCoolerAtoms.
>            - improved the initial movement and distribution of atoms.
>
>  - Dan
>

I'll do a commit during this week, and this will be included. Thank you!

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/b5b4538a/attachment-0004.html>

From juan at jvuletich.org  Mon Nov 16 14:25:50 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 17:25:50 -0300
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
Message-ID: <564A3BCE.9090409@jvuletich.org>

Hi Euan,

On 11/11/2015 4:02 PM, Euan Mee wrote:
> Thanks for the pointer to Morphic3 and its documentation.  I'll try to
> contribute more naive-user questions :-)
>
> What is the state of development of Morphic3?
>    - complete stable codebase?
>    - stable codebase for substantial parts, with fuurther extensions in
> development?
>    - central aspects still under development?
>    - a design concept, coding yet to begin?

I think "central aspects still under development" is a fair way to say it.
If you want to take a look, it is in the 'Experimental' folder. Feel 
free to ask questions.

> e.g. The documentation starts off with "Morphic3 *will have* scalable
> graphics".  This might mean that Morphic3 works now, but does not yet
> have scalable graphics.  Or it might just mean Morphic3 does not (yet)
> work.
>

Well, we have been evolving Morphic in Cuis, towards the direction shown 
by some experiments I did in 2009, for quite some time. This is 
currently using BitBltCanvas to draw, that can not do proper scalable 
graphics. The Morphic3Canvas in 'Experimental' can do this.

> Generally, whenever I'm looking at a new platform, system, or package,
> I am initially looking for answers of the type
>     "Can I use it now?
>          No /
>          Yes /
>          Yes to an extent, but..."
>
> I'm very happy to write up aspects of the system/package as
> fully-formed documentation, especially documentation for naive-users.
> Please let me know if there specific places where this help is
> already-known to be particularly needed.

Morphic 3 is ready to be studied by really interested ones. Not at all 
ready for a naive- user. On the question of where this help is needed, 
I'm not the best to answer. Maybe others in the community answer this, 
or, just use the system for some project, and you'll quickly find the 
places where a new user (you!) could use better documentation.

> I look forward (in the long run?) to trying Cuis and Morphic3 on Raspberry Pi.
>

Well, Morphic 3 might be more expensive than BitBltCanvas, and I don't 
know if it will run reasonably well on a Pi....

Cheers,
Juan Vuletich

> On 11 November 2015 at 18:00,<cuis-request at jvuletich.org>  wrote:
>> Send Cuis mailing list submissions to
>>          cuis at jvuletich.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>          http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> or, via email, send a message with subject or body 'help' to
>>          cuis-request at jvuletich.org
>>
>> You can reach the person managing the list at
>>          cuis-owner at jvuletich.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Cuis digest..."
>>
>>
>> Today's Topics:
>>
>>     1. Simple Morphic (Euan Mee)
>>     2. Re: Simple Morphic (KenD)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 11 Nov 2015 14:13:57 +0000
>> From: Euan Mee<euanmee at gmail.com>
>> To: cuis at jvuletich.org
>> Subject: [Cuis] Simple Morphic
>> Message-ID:
>>          <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> What is the current state of development of Simple Morph?
>>
>> Is there any documentation on how to use it, or is it allInTheCode ?
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 11 Nov 2015 08:13:58 -0800
>> From: KenD<Ken.Dickey at Whidbey.com>
>> To: Discussion of Cuis Smalltalk<cuis at jvuletich.org>
>> Cc: Euan Mee<euanmee at gmail.com>
>> Subject: Re: [Cuis] Simple Morphic
>> Message-ID:<20151111081358.4a0291315670cadcdcead39f at Whidbey.com>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> On Wed, 11 Nov 2015 14:13:57 +0000
>> Euan Mee<euanmee at gmail.com>  wrote:
>>
>>> What is the current state of development of Simple Morph?
>> I am not sure what you mean by Simple Morph.
>>
>> Cuis has been taking steps toward Morphic3:
>>
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>>
>> The MorphExtension class was removed.  (We have Morph Properties).
>>
>> Morphs have float rather than integer location coordinates.
>>
>> Morph location is relative to their owner, not the screen.
>>
>> These are relatively small changes to get used to.
>>
>> More radical are some of the other simplifications in the system.
>>
>> The best example here is probably Layout.
>>
>> LayoutMorphs do just that for their submorphs.  A LayoutSpec is attached to individual Morphs to tell their container how they want to be layed out.  See the class comments.
>>
>> The code in LayoutMorph is much smaller (see LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding layout code in Squeak or Pharo.
>>
>> See LayoutMorph class examples.
>>
>> If you git clone the Morphic-Misc1 package and load it you can get Layout editors:
>>
>> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>>
>>    git clone https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>>
>> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to require the package:
>>
>>    Feature require:  'Morphic-Misc1'.
>>
>> Then use the LayoutMorph class examples, select (sub) morphs, open a LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>>
>> Note that these editors are "one-shot" and will close after setting or cancelling, so click on the "push pin" in the upper right corner to keep them open.
>>
>> If you have several editors open, you can use the "Show Halo" button to see which Morph an editor is adjusting.
>>
>>> Is there any documentation on how to use it, or is it allInTheCode ?
>> See the above URL and continue to ask questions.  We need to make the documentation better over time and questions are very helpful here.
>>
>> --
>> -KenD
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>> ------------------------------
>>
>> End of Cuis Digest, Vol 41, Issue 14
>> ************************************
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Mon Nov 16 14:27:35 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 17:27:35 -0300
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <20151111155637.a6fc5a89ab8ca768aa93510a@Whidbey.com>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
	<20151111155637.a6fc5a89ab8ca768aa93510a@Whidbey.com>
Message-ID: <564A3C37.8050404@jvuletich.org>

On 11/11/2015 8:56 PM, KenD wrote:
> On Wed, 11 Nov 2015 19:02:54 +0000
> Euan Mee<euanmee at gmail.com>  wrote:
>
>> What is the state of development of Morphic3?
> Juan is working on an optimized MorphicCanvas to replace BitBltCanvas.
>
> There is some old, unoptimized sample code in Cuis-Smalltalk-Dev/Experimental which is not for the faint of heart.
>
> Cuis currently uses BitBltCanvas, so the graphics do not yet scale.
>
> Most of the other code works fine.  The location changes to Morph were a big step.
>
> Juan has been slimming down the Cuis image so that it should be possible to rapidly grow when scalable.  Slim down .. grow .. scale  ;^)
>
> Note the small number of classes in the base image:
> "2236 eToys 5.0"
> "2511 Squeak 4.4"
> "2175 Squeak 4.5"
> "2244 Squeak 5.0"
> "3226 Pharo 2.0"
> "4020 Pharo 3.0"
> "4924 Pharo 4.0"
>    vvv
> " 504 Cuis 4.2 (rev 2568)"
>    ^^^
>
> Juan, anything to add/correct here?

No :) All you say is right. Just that besides scaling, also rotation is 
missing in BitBltCanvas.

Cheers,
Juan Vuletich



From dnorton at mindspring.com  Mon Nov 16 16:30:49 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 16 Nov 2015 17:30:49 -0500
Subject: [Cuis] Patterns
In-Reply-To: <563CF147.306@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>,
	<563CF147.306@jvuletich.org>
Message-ID: <564A5919.15040.19C7009@dnorton.mindspring.com>

On 6 Nov 2015 at 15:28, Juan Vuletich wrote Re: [Cuis] ColorEditor updated:

> Hi Ken,
> 
> On 11/2/2015 8:27 PM, KenD wrote:
> > ...
> >
> > However, class comments are not usually where design patterns show
> up.  8^|
> >
> > In the case of #when:send:to: I suggest a slightly larger
> discussion around building paned windows which update dependent
> panes.
> >
> > What constitutes good style?  What code patterns help?
> >
> > Think "Useful Code Patterns" to augment "Useful Expressions".
> 
> In 2009 I wrote 
> http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgram
> ming.txt 
> and 
> http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.tx
> t . 
> I've had the idea of making all the GUI code in Cuis follow this
> style. 
> But time is always short...
> 

As one who benefits greatly from studying other people's code ;-) I favor copy and paste over 
reading prose. The most useful "Useful Code Patterns" would be something in a code 
window like "Useful Expressions" IMO. But where UE is code line oriented, it needs to be 
class and method orented.  It would be heavily commented as to what is on a line, or in a 
method, and why, because this is a big problem with Smalltalk in many cases. Once pasted, 
the comments would be customized or removed.

I started a package with a model and a view, trying to be minimalist about getting them to 
simply put up a window without bringing up the debugger. There are lots of comments. 
Please take a look and give me yours.

	https://github.com/dhnorton/Cuis-Smalltalk-patterns

It tries to be the most efficient, direct, and simple pattern for opening a view on a model in 
Cuis. It's deliberately not glitzy. Glitz is added by the user. Next, I plan to incorporate 
#when:send:to: fundamentals.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/4a178960/attachment-0004.html>

From luchiano at gmail.com  Mon Nov 16 16:46:58 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Mon, 16 Nov 2015 22:46:58 +0000
Subject: [Cuis] Patterns
In-Reply-To: <564A5919.15040.19C7009@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
Message-ID: <CAL5GDyqTYQd0TYrbS969W=WbGK_PCKQHmytud+PhG96aQs85QQ@mail.gmail.com>

Excelent, this exampe has exactly what I wanted yesterday. Models should
implement #open for instance creation. Also, all the different ways we are
currently using to open windows should be cleaned up and unified... but
I'll be happy with #open in every model at least (and always returning the
window).

Also Smalltalk|save, saveAs, quit.

I don't use menues much, I rather doIt ;)
Luciano

On Mon, Nov 16, 2015 at 10:30 PM, Dan Norton <dnorton at mindspring.com> wrote:

> On 6 Nov 2015 at 15:28, Juan Vuletich wrote Re: [Cuis] ColorEditor updated:
>
> > Hi Ken,
> >
> > On 11/2/2015 8:27 PM, KenD wrote:
> > > ...
> > >
> > > However, class comments are not usually where design patterns show
> > up.  8^|
> > >
> > > In the case of #when:send:to: I suggest a slightly larger
> > discussion around building paned windows which update dependent
> > panes.
> > >
> > > What constitutes good style?  What code patterns help?
> > >
> > > Think "Useful Code Patterns" to augment "Useful Expressions".
> >
> > In 2009 I wrote
> > http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgram
> > ming.txt
> > and
> > http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.tx
> > t .
> > I've had the idea of making all the GUI code in Cuis follow this
> > style.
> > But time is always short...
> >
>
> As one who benefits greatly from studying other people's code ;-) I favor
> copy and paste over reading prose. The most useful "Useful Code Patterns"
> would be something in a code window like "Useful Expressions" IMO. But
> where UE is code line oriented, it needs to be class and method orented.
> It would be heavily commented as to what is on a line, or in a method, and
> why, because this is a big problem with Smalltalk in many cases. Once
> pasted, the comments would be customized or removed.
>
> I started a package with a model and a view, trying to be minimalist about
> getting them to simply put up a window without bringing up the debugger.
> There are lots of comments. Please take a look and give me yours.
>
>            https://github.com/dhnorton/Cuis-Smalltalk-patterns
>
> It tries to be the most efficient, direct, and simple pattern for opening
> a view on a model in Cuis. It's deliberately not glitzy. Glitz is added by
> the user. Next, I plan to incorporate #when:send:to: fundamentals.
>
>  - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/d69918db/attachment-0004.html>

From juan at jvuletich.org  Mon Nov 16 18:11:51 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:11:51 -0300
Subject: [Cuis] #when:send:to:
In-Reply-To: <564624BE.15549.F1568C@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>
Message-ID: <564A70C7.4040005@jvuletich.org>

Hi Dan,

On 13/11/2015 02:58 p.m., Dan Norton wrote:
> Hello Everyone,
>
> The following repo contains before and after examples of replacing the Dependency
> Mechanism with the Observer Pattern:
>
> 	https://github.com/dhnorton/Cuis-Smalltalk-light
>
> Please take a look at this and tell me what needs to change. I'm trying to supply an example
> of the Observer Pattern so that others might use #when:send:to: with less difficulty than I
> experienced. There may be better examples but I picked one from the Blue Book.
>
> It seems that #when:send:to: is necessary but not sufficient as a replacement for the
> Dependency Mechanism. In this example, it replaced #addDependent:, not #changed or
> #update and I am still not comfortable with how to choose the parameters. This may be an
> example of the difficulty in explaining the obvious, I'm not sure :-)
>
> The #changed method was replaced with #triggerEvent: with a symbol argument which is
> referred to in one of the arguments of #when:send:to: and that's the only constraint AFAICT.
>
> The #update: method was retained, as a convenience; it also needs to agree with one of the
> arguments of #when:send:to: and could have been different.
>
> Please tell me if any of this is wrong. Thanks.
>
>   - Dan

I think the idea of #when:send:to: is to use event names and actions 
that make sense to your model (and not #changed and #update:). For 
instance, in Example2>>#lights:, I would change the line:

         eachLight when: #changed send: #update: to: dependentLight 
with: self

to read:

         eachLight when: #turnedOn send: #turnOff to: dependentLight

And, in #turnOn, make it do:

         self triggerEvent: #turnedOn


Doesn't this read better?

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Nov 16 18:42:22 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:42:22 -0300
Subject: [Cuis] New Introductory Tutorial
In-Reply-To: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
References: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
Message-ID: <564A77EE.6060802@jvuletich.org>

Hi EuanM,

This is a great initiative. Thanks for including Cuis in the bunch!

Cheers,
Juan Vuletich

On 14/11/2015 02:02 a.m., EuanM wrote:
> I've created Yet Another Smalltalk First
> Steps tutorial.
>
> This is intended as one of a series.
>
> It is designed to be cross-platform across
>
>      Squeak 5
>      Pharo 4
>      Seaside 3.1
>      Cuis
>      Dolphin 6
>
> If you have experience running any of these systems on Windows, Linux
> or MacOS, please check to see if I have the instructions correct for
> your chosen pairing of Smalltalk and OS platform.
>
> (As you'll see when you look, I do not have detailed instructions for
> aspects of MacOS).
>
> The document is at:
> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html
>
> (It's intended to move to a different blog after this review process).
>
> I feel the need to do this as cross-Smalltalks tutorial because of
> findings and 4 charts  I've placed at:
> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/mindshare-of-smalltalk-in-development.html
>
> Essentially, Smalltalk mindshare and use is incredibly tiny, compared
> to other languages in the same space.  (We all know this, but seeing
> it represented graphically has a more visceral effect, IMO)
>
> Aggregating interest in all the Smalltalks still does not bring more
> than a tiny proportion of the interest in, and use of, Ruby.
>
> In turn, Ruby is (quite understandably) small in comparison to JavaScript.
>
> Comparing interest in any specific Smalltalk is, predictably, smaller
> than the aggregate interest in Smalltalk.
>
> Our community seems determined to split itself into smaller and
> smaller sub-communities.  I think we do ourselves a disservice this
> way.
>
> My initial contribution will be to try to provide some explicitly
> pan-Smalltalk beginners' tutorials, like this one.
>
> Cheers, and happy Smalltalking,
>       EuanM
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Mon Nov 16 18:47:33 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:47:33 -0300
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
Message-ID: <564A7925.4060103@jvuletich.org>

On 14/11/2015 02:12 a.m., EuanM wrote:
> I've just recently put-together a cross-platform Installation Tutorial
> for beginners to Smalltalk.
>
> I was keen to include Cuis in the exercise.
>

Again, thank you for this.

> One thing that becomes clear in the comparison is that Cuis is a good
> beginner's environment from the point of view of size and complexity
> and their bearing in learnability.
>
> It is however, the worst Smalltalk (of the 4 in the tutorial) to get
> downloaded and installed.
>
> This seems a pity.

Please take a look at 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Documentation 
. There are three 'Getting Started' guides, for different OSes and user 
style / preferences. They were tried (as described) in Linux, MacOsX and 
Windows.

> Would anyone be willing to help me put together a One-Click Install
> package, similar to Squeak's and Pharo's?
>
> (My plan is to do the grunt-work, if other people are willing to
> indulge my noob questions while I do it)

I believe that if you take the One-Click for Squeak or Pharo, and 
replace the image with a Cuis image, it should work.

> Is there a particular place that it could be hosted, once ready?
>
> Would anyone disagree with a 6-monthly update cycle for the One-Click installer?
>
> (Frequent enough to send a signal to interested beginners that the
> project is alive and kicking.  Infrequent enough that there is not
> much work to be done)

Yep, this sounds great. The natural place is 
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev isn't it?


> Cheers,
>     Euan

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Nov 16 18:51:30 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:51:30 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <1447515912161-4861043.post@n4.nabble.com>
References: <E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>	<563CF22E.4080804@jvuletich.org>	<etPan.563cf40e.77bd141b.a58@Unix.local>	<563CF53B.5000107@jvuletich.org>	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
	<1447515912161-4861043.post@n4.nabble.com>
Message-ID: <564A7A12.2070908@jvuletich.org>

Thank you! It was a pleasure to meet you all at the conference.

Cheers,
Juan Vuletich

On 14/11/2015 12:45 p.m., nacho wrote:
> I agree with Hari,
> It was very nice to meet you Juan.
> Thanks for your work and advice.
> Best
> Nacho
>
>
>
>
> -----
> Nacho
> Smalltalker apprentice.
> Buenos Aires, Argentina.



From juan at jvuletich.org  Mon Nov 16 18:53:33 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 21:53:33 -0300
Subject: [Cuis] FAST conference
In-Reply-To: <BF8DA200-D5CF-424C-8168-F5568D5C2253@gmail.com>
References: <486B2342-019F-452F-BC41-D9DFAFC20CB5@gmail.com>	<E35C2556-17DF-47B8-9BF0-4D3BC6E51E3C@icloud.com>	<563CF22E.4080804@jvuletich.org>	<etPan.563cf40e.77bd141b.a58@Unix.local>	<563CF53B.5000107@jvuletich.org>	<617A374B-7F22-4686-A262-E41D212D263F@icloud.com>
	<BF8DA200-D5CF-424C-8168-F5568D5C2253@gmail.com>
Message-ID: <564A7A8D.5000101@jvuletich.org>

Thank you too, Edgar. I know you made quite an effort to be there!

I don't think not having a plan is too bad. The important thing is to 
enjoy the experience!

And sure, we can talk any time.

Cheers,
Juan Vuletich

On 14/11/2015 06:29 p.m., Edgar De Cleene wrote:
> Also i say very, very thanks for all your talks, time to listening my 
> crazy ideas and tu calidez como ser humano
> Too bad also  i going without plan .
> We should schedule some hangouts when yo have the time.
> Wish know Nacho and Hari , look for me on Facebook and start  Cuis 
> Friendship
> Again thanks Juan.
>
>
>
>
>> On Nov 14, 2015, at 11:37 AM, Hari Balaraman 
>> <hari.balaraman at icloud.com <mailto:hari.balaraman at icloud.com>> wrote:
>>
>> Hi Juan,
>>
>> It was very nice to sit down and chat with you on the sidelines of 
>> the conference. Thank you for taking the time to look at my 
>> stuttering project and offer advice (on the history of projects, 
>> strangely, some others I talked to didn?t recognise the names Mark 
>> Guzdial and Bijan Parsia.) Although I missed first two days because 
>> of careless travel planning, I?m hoping FAST will put videos of the 
>> presentations on the website so I can catch up.
>>
>> The two people at Toronto Smalltalk Users Group I mentioned are Bob 
>> Nemec and Dave Mason, a professor at Ryerson University. My knowledge 
>> of the use of SmallTalk in the CS curriculum there is second or 
>> third-hand and so may not be current. I haven?t actually met them as 
>> the one Monday evening I was able to make it to TSUG, I was late and 
>> both of them had left by then. :)
>>
>> Thanks for the tip on visiting the bookshops on Avenida Corrientes in 
>> this amazing city. I passed it on the way home and realised I haven?t 
>> gone down this street in my wanderings. If you are going to be in the 
>> city before Tuesday afternoon, and are free and bored, do let me know.
>>
>> Best regards,
>>
>> Hari
>>>>
>>>> On November 6, 2015 at 3:32:33 PM, Juan Vuletich 
>>>> (juan at jvuletich.org <mailto:juan at jvuletich.org>) wrote:
>>>>
>>>>> Hi Hari,
>>>>>
>>>>> I'll be there. Let's meet then.
>>>>>
>>>>> Anybody else?
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>>> On 11/5/2015 4:53 PM, Hari Balaraman wrote:
>>>>>> If any of you are attending the FAST conference in Buenos Aires 
>>>>>> in a week or so, I look forward to meeting you face to face.
>>>>>> Best regards,
>>>>>> Hari
>>>>>>
>>>>>> _______________________________________________
>>>>>> Cuis mailing list
>>>>>> Cuis at jvuletich.org
>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/4eea6045/attachment-0004.html>

From juan at jvuletich.org  Mon Nov 16 19:06:25 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 22:06:25 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564A5919.15040.19C7009@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>,
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
Message-ID: <564A7D91.6080102@jvuletich.org>

Hi Dan,

On 16/11/2015 07:30 p.m., Dan Norton wrote:
>
> As one who benefits greatly from studying other people's code ;-) I 
> favor copy and paste over reading prose. The most useful "Useful Code 
> Patterns" would be something in a code window like "Useful 
> Expressions" IMO. But where UE is code line oriented, it needs to be 
> class and method orented.  It would be heavily commented as to what is 
> on a line, or in a method, and why, because this is a big problem with 
> Smalltalk in many cases. Once pasted, the comments would be customized 
> or removed.

Ok, it is a good idea.

> I started a package with a model and a view, trying to be minimalist 
> about getting them to simply put up a window without bringing up the 
> debugger. There are lots of comments. Please take a look and give me 
> yours.
>
>            https://github.com/dhnorton/Cuis-Smalltalk-patterns
>
> It tries to be the most efficient, direct, and simple pattern for 
> opening a view on a model in Cuis. It's deliberately not glitzy. Glitz 
> is added by the user. Next, I plan to incorporate #when:send:to: 
> fundamentals.
>
>  - Dan

Well, I don't like the #open method in the model. The idea of View / 
Model separation is that views know about models, but models don't know 
about views. A Model should exist independently of being used from 
Morphic, MVC, Seaside, or any other UI framework. It could live, for 
example, in a Gemstone database with no UI at all. Or ir could travel to 
and from other systems, like VA Smalltalk, where the UI framework is 
completely different from Cuis'.

I think it is better for the View to start it all.

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/87361800/attachment-0004.html>

From garduino at gmail.com  Mon Nov 16 19:47:43 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Mon, 16 Nov 2015 22:47:43 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564A7D91.6080102@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
Message-ID: <CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>

2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org>:

>
> Well, I don't like the #open method in the model. The idea of View / Model
> separation is that views know about models, but models don't know about
> views. A Model should exist independently of being used from Morphic, MVC,
> Seaside, or any other UI framework. It could live, for example, in a
> Gemstone database with no UI at all. Or ir could travel to and from other
> systems, like VA Smalltalk, where the UI framework is completely different
> from Cuis'.
>
>
Interesting, really I never heard of the use of  #open at the model or I do
not remember it at all, but I think similar to Juan.



> I think it is better for the View to start it all.
>
>
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151116/f563d169/attachment-0004.html>

From dnorton at mindspring.com  Mon Nov 16 19:50:30 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 16 Nov 2015 20:50:30 -0500
Subject: [Cuis] #when:send:to:
In-Reply-To: <564A70C7.4040005@jvuletich.org>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<564A70C7.4040005@jvuletich.org>
Message-ID: <564A87E6.28858.2533F1E@dnorton.mindspring.com>

On 16 Nov 2015 at 21:11, Juan Vuletich wrote:

> Hi Dan,
> 
> On 13/11/2015 02:58 p.m., Dan Norton wrote:
> > Hello Everyone,
> >
> > The following repo contains before and after examples of replacing
> the Dependency
> > Mechanism with the Observer Pattern:
> >
> > 	https://github.com/dhnorton/Cuis-Smalltalk-light
> >
> > Please take a look at this and tell me what needs to change. I'm
> trying to supply an example
> > of the Observer Pattern so that others might use #when:send:to:
> with less difficulty than I
> > experienced. There may be better examples but I picked one from
> the Blue Book.
> >
> > It seems that #when:send:to: is necessary but not sufficient as a
> replacement for the
> > Dependency Mechanism. In this example, it replaced #addDependent:,
> not #changed or
> > #update and I am still not comfortable with how to choose the
> parameters. This may be an
> > example of the difficulty in explaining the obvious, I'm not sure
> :-)
> >
> > The #changed method was replaced with #triggerEvent: with a symbol
> argument which is
> > referred to in one of the arguments of #when:send:to: and that's
> the only constraint AFAICT.
> >
> > The #update: method was retained, as a convenience; it also needs
> to agree with one of the
> > arguments of #when:send:to: and could have been different.
> >
> > Please tell me if any of this is wrong. Thanks.
> >
> >   - Dan
> 
> I think the idea of #when:send:to: is to use event names and actions
> that make sense to your model (and not #changed and #update:). For
> instance, in Example2>>#lights:, I would change the line:
> 
>          eachLight when: #changed send: #update: to: dependentLight
> with: self
> 
> to read:
> 
>          eachLight when: #turnedOn send: #turnOff to:
> dependentLight
> 
> And, in #turnOn, make it do:
> 
>          self triggerEvent: #turnedOn
> 
> 
> Doesn't this read better?
> 

+2
...because yes, it reads better, but there's more:

	#when:send:to: replaces #when:send:to:with:

	in Light2, #update: goes away, with a little factoring

The #triggerEvent: arg is changed to #turnedOn. This is elegant.

 - Dan



From juan at jvuletich.org  Mon Nov 16 19:52:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 16 Nov 2015 22:52:01 -0300
Subject: [Cuis] #when:send:to:
In-Reply-To: <564A87E6.28858.2533F1E@dnorton.mindspring.com>
References: <564624BE.15549.F1568C@dnorton.mindspring.com>,
	<564A70C7.4040005@jvuletich.org>
	<564A87E6.28858.2533F1E@dnorton.mindspring.com>
Message-ID: <564A8841.7070708@jvuletich.org>

On 16/11/2015 10:50 p.m., Dan Norton wrote:
> On 16 Nov 2015 at 21:11, Juan Vuletich wrote:
>
>> Hi Dan,
>>
>> On 13/11/2015 02:58 p.m., Dan Norton wrote:
>>> Hello Everyone,
>>>
>>> The following repo contains before and after examples of replacing
>> the Dependency
>>> Mechanism with the Observer Pattern:
>>>
>>> 	https://github.com/dhnorton/Cuis-Smalltalk-light
>>>
>>> Please take a look at this and tell me what needs to change. I'm
>> trying to supply an example
>>> of the Observer Pattern so that others might use #when:send:to:
>> with less difficulty than I
>>> experienced. There may be better examples but I picked one from
>> the Blue Book.
>>> It seems that #when:send:to: is necessary but not sufficient as a
>> replacement for the
>>> Dependency Mechanism. In this example, it replaced #addDependent:,
>> not #changed or
>>> #update and I am still not comfortable with how to choose the
>> parameters. This may be an
>>> example of the difficulty in explaining the obvious, I'm not sure
>> :-)
>>> The #changed method was replaced with #triggerEvent: with a symbol
>> argument which is
>>> referred to in one of the arguments of #when:send:to: and that's
>> the only constraint AFAICT.
>>> The #update: method was retained, as a convenience; it also needs
>> to agree with one of the
>>> arguments of #when:send:to: and could have been different.
>>>
>>> Please tell me if any of this is wrong. Thanks.
>>>
>>>    - Dan
>> I think the idea of #when:send:to: is to use event names and actions
>> that make sense to your model (and not #changed and #update:). For
>> instance, in Example2>>#lights:, I would change the line:
>>
>>           eachLight when: #changed send: #update: to: dependentLight
>> with: self
>>
>> to read:
>>
>>           eachLight when: #turnedOn send: #turnOff to:
>> dependentLight
>>
>> And, in #turnOn, make it do:
>>
>>           self triggerEvent: #turnedOn
>>
>>
>> Doesn't this read better?
>>
> +2
> ...because yes, it reads better, but there's more:
>
> 	#when:send:to: replaces #when:send:to:with:
>
> 	in Light2, #update: goes away, with a little factoring
>
> The #triggerEvent: arg is changed to #turnedOn. This is elegant.
>
>   - Dan
>

Yes! And this way, 'senders' and 'implementors' take you right to the spot.

Cheers,
Juan Vuletich

> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From thierry.goubier at gmail.com  Mon Nov 16 22:42:37 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 05:42:37 +0100
Subject: [Cuis] Patterns
In-Reply-To: <CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
Message-ID: <564AB03D.1040405@gmail.com>

Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
>
>
> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
> <mailto:juan at jvuletich.org>>:
>
>     __
>
>     Well, I don't like the #open method in the model. The idea of View /
>     Model separation is that views know about models, but models don't
>     know about views. A Model should exist independently of being used
>     from Morphic, MVC, Seaside, or any other UI framework. It could
>     live, for example, in a Gemstone database with no UI at all. Or ir
>     could travel to and from other systems, like VA Smalltalk, where the
>     UI framework is completely different from Cuis'.
>
>
> Interesting, really I never heard of the use of  #open at the model or I
> do not remember it at all, but I think similar to Juan.

Hum, #open has to go somewhere, so...

Either it goes into a sort of Application Model, which regroup the 
duties associated with the application (the view + model + whatever is 
necessary in environment X), or it goes into an Application View which 
then has model concerns in it (it knows how to start or connect to the 
model, it knows what the model is composed of to connect subviews to 
model elements, etc...).

>     I think it is better for the View to start it all.
>
>
> +1

I prefer to model an Application concept in the target desktop 
environment if I want to model highly portable stuff.

That application concern can be folded into a dedicated view if that is 
the preferred convention in the target environment.

Regards,

Thierry

>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From thierry.goubier at gmail.com  Mon Nov 16 22:44:52 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 05:44:52 +0100
Subject: [Cuis] Cuis Digest, Vol 41, Issue 14
In-Reply-To: <564A3BCE.9090409@jvuletich.org>
References: <mailman.1.1447264804.96259.cuis_jvuletich.org@jvuletich.org>
	<CALsRT0mMy_1Rq2vOAUkojHyOyM4SoGuuAXQvegaLp1kj9p7x_g@mail.gmail.com>
	<564A3BCE.9090409@jvuletich.org>
Message-ID: <564AB0C4.7000906@gmail.com>

Hi Juan, Euan,

thanks for the update on Morphic3. I'll have a look one of these days, 
when I'll have something interesting to show running on Cuis.

Regards,

Thierry

Le 16/11/2015 21:25, Juan Vuletich a ?crit :
> Hi Euan,
>
> On 11/11/2015 4:02 PM, Euan Mee wrote:
>> Thanks for the pointer to Morphic3 and its documentation.  I'll try to
>> contribute more naive-user questions :-)
>>
>> What is the state of development of Morphic3?
>>    - complete stable codebase?
>>    - stable codebase for substantial parts, with fuurther extensions in
>> development?
>>    - central aspects still under development?
>>    - a design concept, coding yet to begin?
>
> I think "central aspects still under development" is a fair way to say it.
> If you want to take a look, it is in the 'Experimental' folder. Feel
> free to ask questions.
>
>> e.g. The documentation starts off with "Morphic3 *will have* scalable
>> graphics".  This might mean that Morphic3 works now, but does not yet
>> have scalable graphics.  Or it might just mean Morphic3 does not (yet)
>> work.
>>
>
> Well, we have been evolving Morphic in Cuis, towards the direction shown
> by some experiments I did in 2009, for quite some time. This is
> currently using BitBltCanvas to draw, that can not do proper scalable
> graphics. The Morphic3Canvas in 'Experimental' can do this.
>
>> Generally, whenever I'm looking at a new platform, system, or package,
>> I am initially looking for answers of the type
>>     "Can I use it now?
>>          No /
>>          Yes /
>>          Yes to an extent, but..."
>>
>> I'm very happy to write up aspects of the system/package as
>> fully-formed documentation, especially documentation for naive-users.
>> Please let me know if there specific places where this help is
>> already-known to be particularly needed.
>
> Morphic 3 is ready to be studied by really interested ones. Not at all
> ready for a naive- user. On the question of where this help is needed,
> I'm not the best to answer. Maybe others in the community answer this,
> or, just use the system for some project, and you'll quickly find the
> places where a new user (you!) could use better documentation.
>
>> I look forward (in the long run?) to trying Cuis and Morphic3 on
>> Raspberry Pi.
>>
>
> Well, Morphic 3 might be more expensive than BitBltCanvas, and I don't
> know if it will run reasonably well on a Pi....
>
> Cheers,
> Juan Vuletich
>
>> On 11 November 2015 at 18:00,<cuis-request at jvuletich.org>  wrote:
>>> Send Cuis mailing list submissions to
>>>          cuis at jvuletich.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>          http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>> or, via email, send a message with subject or body 'help' to
>>>          cuis-request at jvuletich.org
>>>
>>> You can reach the person managing the list at
>>>          cuis-owner at jvuletich.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Cuis digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>     1. Simple Morphic (Euan Mee)
>>>     2. Re: Simple Morphic (KenD)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Wed, 11 Nov 2015 14:13:57 +0000
>>> From: Euan Mee<euanmee at gmail.com>
>>> To: cuis at jvuletich.org
>>> Subject: [Cuis] Simple Morphic
>>> Message-ID:
>>>
>>> <CALsRT0mTDvBNGgezDNq5-Uzx+K2QqBs7tierkCB2uORrLeB60w at mail.gmail.com>
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> What is the current state of development of Simple Morph?
>>>
>>> Is there any documentation on how to use it, or is it allInTheCode ?
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Wed, 11 Nov 2015 08:13:58 -0800
>>> From: KenD<Ken.Dickey at Whidbey.com>
>>> To: Discussion of Cuis Smalltalk<cuis at jvuletich.org>
>>> Cc: Euan Mee<euanmee at gmail.com>
>>> Subject: Re: [Cuis] Simple Morphic
>>> Message-ID:<20151111081358.4a0291315670cadcdcead39f at Whidbey.com>
>>> Content-Type: text/plain; charset=US-ASCII
>>>
>>> On Wed, 11 Nov 2015 14:13:57 +0000
>>> Euan Mee<euanmee at gmail.com>  wrote:
>>>
>>>> What is the current state of development of Simple Morph?
>>> I am not sure what you mean by Simple Morph.
>>>
>>> Cuis has been taking steps toward Morphic3:
>>>
>>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/NotesOnMorphic.md
>>>
>>>
>>> The MorphExtension class was removed.  (We have Morph Properties).
>>>
>>> Morphs have float rather than integer location coordinates.
>>>
>>> Morph location is relative to their owner, not the screen.
>>>
>>> These are relatively small changes to get used to.
>>>
>>> More radical are some of the other simplifications in the system.
>>>
>>> The best example here is probably Layout.
>>>
>>> LayoutMorphs do just that for their submorphs.  A LayoutSpec is
>>> attached to individual Morphs to tell their container how they want
>>> to be layed out.  See the class comments.
>>>
>>> The code in LayoutMorph is much smaller (see
>>> LayoutMorph>>layoutSubmorphsHorizontallyIn:) than corresponding
>>> layout code in Squeak or Pharo.
>>>
>>> See LayoutMorph class examples.
>>>
>>> If you git clone the Morphic-Misc1 package and load it you can get
>>> Layout editors:
>>>
>>> Open a shell and cd to the directory containing Cuis-Smalltalk-Dev
>>>
>>>    git clone
>>> https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1.git
>>>
>>> Go to Cuis-Smalltalk-Dev, open an image and use a Workspace to
>>> require the package:
>>>
>>>    Feature require:  'Morphic-Misc1'.
>>>
>>> Then use the LayoutMorph class examples, select (sub) morphs, open a
>>> LayoutMorph Editor (or a LayoutSpec Editor) and play with the settings.
>>>
>>> Note that these editors are "one-shot" and will close after setting
>>> or cancelling, so click on the "push pin" in the upper right corner
>>> to keep them open.
>>>
>>> If you have several editors open, you can use the "Show Halo" button
>>> to see which Morph an editor is adjusting.
>>>
>>>> Is there any documentation on how to use it, or is it allInTheCode ?
>>> See the above URL and continue to ask questions.  We need to make the
>>> documentation better over time and questions are very helpful here.
>>>
>>> --
>>> -KenD
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>>
>>> ------------------------------
>>>
>>> End of Cuis Digest, Vol 41, Issue 14
>>> ************************************
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From luchiano at gmail.com  Tue Nov 17 01:13:52 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Tue, 17 Nov 2015 07:13:52 +0000
Subject: [Cuis] dynamic window manager
Message-ID: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>

I've been using dwm.suckless.org for 10 years and I just had to have it in
Cuis. So, that's what I've been doing the last two days, and I had to do
some minor changes to the core in order to allow this level of
customization. In case there's some other tiling maniac like me who wants
to give it a try... although it's still a little rough, I'll be improving
it as I go by using it everyday :) Not sure it will work out-of-the-box
yet, I've done some changes that are not included in the package (like some
preferences and monospaced font)

https://github.com/len/Cuis-Smalltalk-DWM

Cheers,
Luciano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/57cf707d/attachment-0004.html>

From 0800nacho at gmail.com  Tue Nov 17 03:46:54 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Tue, 17 Nov 2015 06:46:54 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
Message-ID: <CAMCzT-arkx7dkmw1vNWGCXBTvTO4DbJ9eVFsqqDM-5fC0W9MpA@mail.gmail.com>

Great to hear you use suckless.
Do you use dwm or another WM?
For the past 2 years I been using i3, I'm very happy with it.
abrazo
Nacho


*Lic. Ignacio Sniechowski, MBA*
*Prosavic SRL*

*Tel: (011) 4542-6714*


















On Tue, Nov 17, 2015 at 4:13 AM, Luciano Notarfrancesco <luchiano at gmail.com>
wrote:

> I've been using dwm.suckless.org for 10 years and I just had to have it
> in Cuis. So, that's what I've been doing the last two days, and I had to do
> some minor changes to the core in order to allow this level of
> customization. In case there's some other tiling maniac like me who wants
> to give it a try... although it's still a little rough, I'll be improving
> it as I go by using it everyday :) Not sure it will work out-of-the-box
> yet, I've done some changes that are not included in the package (like some
> preferences and monospaced font)
>
> https://github.com/len/Cuis-Smalltalk-DWM
>
> Cheers,
> Luciano
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/e12d67bb/attachment-0004.html>

From juan at jvuletich.org  Tue Nov 17 08:00:21 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 17 Nov 2015 11:00:21 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564AB03D.1040405@gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>	<563CF147.306@jvuletich.org>	<564A5919.15040.19C7009@dnorton.mindspring.com>	<564A7D91.6080102@jvuletich.org>	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com>
Message-ID: <564B32F5.9050102@jvuletich.org>

Hi Thierry,


On 11/17/2015 1:42 AM, Thierry Goubier wrote:
> Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
>>
>>
>> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
>> <mailto:juan at jvuletich.org>>:
>>
>>     __
>>
>>     Well, I don't like the #open method in the model. The idea of View /
>>     Model separation is that views know about models, but models don't
>>     know about views. A Model should exist independently of being used
>>     from Morphic, MVC, Seaside, or any other UI framework. It could
>>     live, for example, in a Gemstone database with no UI at all. Or ir
>>     could travel to and from other systems, like VA Smalltalk, where the
>>     UI framework is completely different from Cuis'.
>>
>>
>> Interesting, really I never heard of the use of  #open at the model or I
>> do not remember it at all, but I think similar to Juan.
>
> Hum, #open has to go somewhere, so...
>
> Either it goes into a sort of Application Model, which regroup the 
> duties associated with the application (the view + model + whatever is 
> necessary in environment X), or it goes into an Application View which 
> then has model concerns in it (it knows how to start or connect to the 
> model, it knows what the model is composed of to connect subviews to 
> model elements, etc...).
>

The idea of view / model separation is pretty well explained in "Inside 
Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.

I agree that an Application object or such might make sense when you are 
building an application, especially if you need to deal with en external 
environment. But here we were talking about whether the Model classes 
should know about Morphs or not.

>>     I think it is better for the View to start it all.
>>
>>
>> +1
>
> I prefer to model an Application concept in the target desktop 
> environment if I want to model highly portable stuff.
>
> That application concern can be folded into a dedicated view if that 
> is the preferred convention in the target environment.
>
> Regards,
>
> Thierry

I wonder how would this result in practice. Do you have some examples to 
share?

Cheers,
Juan Vuletich



From thierry.goubier at gmail.com  Tue Nov 17 08:32:16 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 15:32:16 +0100
Subject: [Cuis] Fwd:  Patterns
In-Reply-To: <CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
Message-ID: <CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>

2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:

> Hi Thierry,
>
>
> On 11/17/2015 1:42 AM, Thierry Goubier wrote:
>
>> Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
>>
>>>
>>>
>>> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
>>> <mailto:juan at jvuletich.org>>:
>>>
>>>     __
>>>
>>>     Well, I don't like the #open method in the model. The idea of View /
>>>     Model separation is that views know about models, but models don't
>>>     know about views. A Model should exist independently of being used
>>>     from Morphic, MVC, Seaside, or any other UI framework. It could
>>>     live, for example, in a Gemstone database with no UI at all. Or ir
>>>     could travel to and from other systems, like VA Smalltalk, where the
>>>     UI framework is completely different from Cuis'.
>>>
>>>
>>> Interesting, really I never heard of the use of  #open at the model or I
>>> do not remember it at all, but I think similar to Juan.
>>>
>>
>> Hum, #open has to go somewhere, so...
>>
>> Either it goes into a sort of Application Model, which regroup the duties
>> associated with the application (the view + model + whatever is necessary
>> in environment X), or it goes into an Application View which then has model
>> concerns in it (it knows how to start or connect to the model, it knows
>> what the model is composed of to connect subviews to model elements,
>> etc...).
>>
>>
> The idea of view / model separation is pretty well explained in "Inside
> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>

Sadly, that view / model separation encounters pragmatic issues  when
dealing with things more complex than standard widgets, such as your
typical domain drawing editor. This is the fundamental reason for me to
consider that Morphic departed from that model, and that the pinacle of
that M / V separation is the M2VC of VisualWorks.

Newer models in the literature around those years such as PAC proposed
better abstractions, but they were never implemented.

Now, it's interesting to see you advocate that model on top of Morphic.


> I agree that an Application object or such might make sense when you are
> building an application, especially if you need to deal with en external
> environment. But here we were talking about whether the Model classes
> should know about Morphs or not.


In theory, no.

In practice, if you want a well tuned gui, I consider that yes, they need
to be aware of them.

So the most elegant way I've used is the two models: a pure, abstract
model, totally view independent. And a pragmatic, closer to the view /
aware of the view, application model as an mediator.


>
>
>     I think it is better for the View to start it all.
>>>
>>>
>>> +1
>>>
>>
>> I prefer to model an Application concept in the target desktop
>> environment if I want to model highly portable stuff.
>>
>> That application concern can be folded into a dedicated view if that is
>> the preferred convention in the target environment.
>>
>> Regards,
>>
>> Thierry
>>
>
> I wonder how would this result in practice. Do you have some examples to
> share?
>

I have a complex example, a system browser, would that fit?

Regards,

Thierry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/57a1be52/attachment-0004.html>

From juan at jvuletich.org  Tue Nov 17 09:16:07 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 17 Nov 2015 12:16:07 -0300
Subject: [Cuis] Fwd:  Patterns
In-Reply-To: <CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>	<563CF147.306@jvuletich.org>	<564A5919.15040.19C7009@dnorton.mindspring.com>	<564A7D91.6080102@jvuletich.org>	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>	<564AB03D.1040405@gmail.com>
	<564B32F5.9050102@jvuletich.org>	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
Message-ID: <564B44B7.2070809@jvuletich.org>

Hi Thierry,

On 11/17/2015 11:32 AM, Thierry Goubier wrote:
>
> 2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>>:
>
>     ...
>
>     The idea of view / model separation is pretty well explained in
>     "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>
>
> Sadly, that view / model separation encounters pragmatic issues  when 
> dealing with things more complex than standard widgets, such as your 
> typical domain drawing editor.

This is the first time I hear this. Can you elaborate or provide 
references? I worked on several mid-size to large projects that did 
strict view / model separation, and I never saw "pragmatic issues" (that 
couldn't be solved by a good design).

> This is the fundamental reason for me to consider that Morphic 
> departed from that model, and that the pinacle of that M / V 
> separation is the M2VC of VisualWorks.

PluggableMorphs attempted to follow this model (and give model 
compatibility between Morphic and MVC). Etoys (if I remember correctly) 
do the same, only that calling the model a "Player" and the view a 
"Costume". Later, people forgot about view / model separation, and 
Squeak became legacy software, in part because of that.

> Newer models in the literature around those years such as PAC proposed 
> better abstractions, but they were never implemented.
> Now, it's interesting to see you advocate that model on top of Morphic.
>
>
>     I agree that an Application object or such might make sense when
>     you are building an application, especially if you need to deal
>     with en external environment. But here we were talking about
>     whether the Model classes should know about Morphs or not.
>
>
> In theory, no.
>
> In practice, if you want a well tuned gui, I consider that yes, they 
> need to be aware of them.

Please elaborate, or provide references.

> So the most elegant way I've used is the two models: a pure, abstract 
> model, totally view independent. And a pragmatic, closer to the view / 
> aware of the view, application model as an mediator.
>
>
>
>                 I think it is better for the View to start it all.
>
>
>             +1
>
>
>         I prefer to model an Application concept in the target desktop
>         environment if I want to model highly portable stuff.
>
>         That application concern can be folded into a dedicated view
>         if that is the preferred convention in the target environment.
>
>         Regards,
>
>         Thierry
>
>
>     I wonder how would this result in practice. Do you have some
>     examples to share?
>
>
> I have a complex example, a system browser, would that fit?

Sure.

> Regards,
>
> Thierry
>

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/38ab5247/attachment-0004.html>

From garduino at gmail.com  Tue Nov 17 09:57:05 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Tue, 17 Nov 2015 12:57:05 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
Message-ID: <CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>

Awesome!!

Saludos / Regards,
Germ?n Arduino
@garduino


2015-11-17 4:13 GMT-03:00 Luciano Notarfrancesco <luchiano at gmail.com>:

> I've been using dwm.suckless.org for 10 years and I just had to have it
> in Cuis. So, that's what I've been doing the last two days, and I had to do
> some minor changes to the core in order to allow this level of
> customization. In case there's some other tiling maniac like me who wants
> to give it a try... although it's still a little rough, I'll be improving
> it as I go by using it everyday :) Not sure it will work out-of-the-box
> yet, I've done some changes that are not included in the package (like some
> preferences and monospaced font)
>
> https://github.com/len/Cuis-Smalltalk-DWM
>
> Cheers,
> Luciano
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/b2136b82/attachment-0004.html>

From luchiano at gmail.com  Tue Nov 17 10:35:40 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Tue, 17 Nov 2015 16:35:40 +0000
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAMCzT-arkx7dkmw1vNWGCXBTvTO4DbJ9eVFsqqDM-5fC0W9MpA@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
	<CAMCzT-arkx7dkmw1vNWGCXBTvTO4DbJ9eVFsqqDM-5fC0W9MpA@mail.gmail.com>
Message-ID: <CAL5GDyrGy=1rQctf4oBE_XLPF_yK_32yXGmsborH_4J5H7dqcA@mail.gmail.com>

Yeah, I use dwm, I tried several tiling window managers and I ended up with
my customized version of dwm. I use it "nested", I have a minimalist host
that barely can run dwm and the command-line virtualbox, and then many
small virtual machines that run a slightly different version of dwm for
different tasks, color-coded, etc... like a form of compartmentalization...
haha

I'm not sure this tiling and text-oriented thing is useful for coding
Smalltalk... I'll see... I always enjoyed experimenting with alternatives
to the classic overlapping-windows and menus and icons paradigm.

Cheers,
Luciano

On Tue, Nov 17, 2015 at 9:46 AM, Ignacio Sniechowski <0800nacho at gmail.com>
wrote:

> Great to hear you use suckless.
> Do you use dwm or another WM?
> For the past 2 years I been using i3, I'm very happy with it.
> abrazo
> Nacho
>
>
> *Lic. Ignacio Sniechowski, MBA*
> *Prosavic SRL*
>
> *Tel: (011) 4542-6714*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Nov 17, 2015 at 4:13 AM, Luciano Notarfrancesco <
> luchiano at gmail.com> wrote:
>
>> I've been using dwm.suckless.org for 10 years and I just had to have it
>> in Cuis. So, that's what I've been doing the last two days, and I had to do
>> some minor changes to the core in order to allow this level of
>> customization. In case there's some other tiling maniac like me who wants
>> to give it a try... although it's still a little rough, I'll be improving
>> it as I go by using it everyday :) Not sure it will work out-of-the-box
>> yet, I've done some changes that are not included in the package (like some
>> preferences and monospaced font)
>>
>> https://github.com/len/Cuis-Smalltalk-DWM
>>
>> Cheers,
>> Luciano
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/536c1256/attachment-0004.html>

From thierry.goubier at gmail.com  Tue Nov 17 10:51:47 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 17:51:47 +0100
Subject: [Cuis] Fwd:  Fwd: Patterns
In-Reply-To: <CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
	<564B44B7.2070809@jvuletich.org>
	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
Message-ID: <CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>

Hi Juan,

2015-11-17 16:16 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:

> Hi Thierry,
>
> On 11/17/2015 11:32 AM, Thierry Goubier wrote:
>
>
> 2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org>:
>
>> ...
>>
>> The idea of view / model separation is pretty well explained in "Inside
>> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>>
>
> Sadly, that view / model separation encounters pragmatic issues  when
> dealing with things more complex than standard widgets, such as your
> typical domain drawing editor.
>
>
> This is the first time I hear this. Can you elaborate or provide
> references? I worked on several mid-size to large projects that did strict
> view / model separation, and I never saw "pragmatic issues" (that couldn't
> be solved by a good design).
>

I would give HotDraw, and some of the original design pattern work on
editors, especially the parts derived from the InterViews toolkit.

Now, I used to be pretty up to date on the literature and some of the
criticism of the MVC model (especially the division between V and C) but my
memory of that time is all fuzzy.

> This is the fundamental reason for me to consider that Morphic departed
> from that model, and that the pinacle of that M / V separation is the M2VC
> of VisualWorks.
>
>
> PluggableMorphs attempted to follow this model (and give model
> compatibility between Morphic and MVC). Etoys (if I remember correctly) do
> the same, only that calling the model a "Player" and the view a "Costume".
> Later, people forgot about view / model separation, and Squeak became
> legacy software, in part because of that.
>

Maybe. I'm not sure of that particular factor. I have the feeling that
there is no clear and honest analysis on the state of GUI toolkits in that
universe, for present and future ones.


> Newer models in the literature around those years such as PAC proposed
> better abstractions, but they were never implemented.
> Now, it's interesting to see you advocate that model on top of Morphic.
>
>
>> I agree that an Application object or such might make sense when you are
>> building an application, especially if you need to deal with en external
>> environment. But here we were talking about whether the Model classes
>> should know about Morphs or not.
>
>
> In theory, no.
>
> In practice, if you want a well tuned gui, I consider that yes, they need
> to be aware of them.
>
>
> Please elaborate, or provide references.
>

What would you think of a drag and drop feedback which is dependent of the
type of the model elements?


>
>
> So the most elegant way I've used is the two models: a pure, abstract
> model, totally view independent. And a pragmatic, closer to the view /
> aware of the view, application model as an mediator.
>
>
>>
>>
>>     I think it is better for the View to start it all.
>>>>
>>>>
>>>> +1
>>>>
>>>
>>> I prefer to model an Application concept in the target desktop
>>> environment if I want to model highly portable stuff.
>>>
>>> That application concern can be folded into a dedicated view if that is
>>> the preferred convention in the target environment.
>>>
>>> Regards,
>>>
>>> Thierry
>>>
>>
>> I wonder how would this result in practice. Do you have some examples to
>> share?
>>
>
> I have a complex example, a system browser, would that fit?
>
>
> Sure.
>

Well, a short estimate on that particular application is that, linked with
the pluggable morphs, 10 to 20% of the code in the application model is:
- widget creation, setup, layout
- dynamic morph addition / removal when activating certain functions on the
model
- workarounds the pluggable morphs api to:
  - dynamically refresh parts of the inside of widgets
  - disconnect then reconnect links between widgets so that the
model-triggered update of one does not change the state of the other one
(i.e. protect the model from unwanted view triggered updates when the model
is changing part of its contents).

This application model uses mainly two widgets.

I do have a long term plan to port that to Cuis, and I expect I will have
to write that very same code somewhere (maybe more, maybe less).

Regards,

Thierry


>
> Regards,
>
> Thierry
>
>
> Cheers,
> Juan Vuletich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/fbfd618b/attachment-0004.html>

From luchiano at gmail.com  Tue Nov 17 11:14:29 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Tue, 17 Nov 2015 17:14:29 +0000
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
	<CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>
Message-ID: <CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>

On Tue, Nov 17, 2015 at 3:57 PM, Germ?n Arduino <garduino at gmail.com> wrote:

> Awesome!!
>

Haha, awesome is another window manager, it was also a fork of dwm, I used
it for a while ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/b007e699/attachment-0004.html>

From juan at jvuletich.org  Tue Nov 17 11:36:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 17 Nov 2015 14:36:34 -0300
Subject: [Cuis] Fwd:  Fwd: Patterns
In-Reply-To: <CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>	<563CF147.306@jvuletich.org>	<564A5919.15040.19C7009@dnorton.mindspring.com>	<564A7D91.6080102@jvuletich.org>	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>	<564AB03D.1040405@gmail.com>
	<564B32F5.9050102@jvuletich.org>	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>	<564B44B7.2070809@jvuletich.org>	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
	<CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
Message-ID: <564B65A2.3050604@jvuletich.org>

Hi Thierry,

On 11/17/2015 1:51 PM, Thierry Goubier wrote:
> Hi Juan,
>
> 2015-11-17 16:16 GMT+01:00 Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>>:
>
>     Hi Thierry,
>
>     On 11/17/2015 11:32 AM, Thierry Goubier wrote:
>>
>>     2015-11-17 15:00 GMT+01:00 Juan Vuletich <juan at jvuletich.org
>>     <mailto:juan at jvuletich.org>>:
>>
>>         ...
>>
>>         The idea of view / model separation is pretty well explained
>>         in "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
>>
>>
>>     Sadly, that view / model separation encounters pragmatic issues
>>      when dealing with things more complex than standard widgets,
>>     such as your typical domain drawing editor.
>
>     This is the first time I hear this. Can you elaborate or provide
>     references? I worked on several mid-size to large projects that
>     did strict view / model separation, and I never saw "pragmatic
>     issues" (that couldn't be solved by a good design).
>
>
> I would give HotDraw, and some of the original design pattern work on 
> editors, especially the parts derived from the InterViews toolkit.

Uh, it is not easy to find stuff about that, so I can't really comment.

> Now, I used to be pretty up to date on the literature and some of the 
> criticism of the MVC model (especially the division between V and C) 
> but my memory of that time is all fuzzy.

Well, in my opinion View / Model separation is a great property of the 
design of an application. Controller is more of a requirement of the 
ST-80 MVC framework. In principle, I see no problem in merging 
Controller into View. But, in Cuis, it can be argued that the Editor 
hierarchy is essentially a hierarchy of Controllers, and that's ok if 
the decomposition of responsibilities makes sense.

In View / Model separation there are two restrictions that need to be 
honored:
- The Model doesn't know about the possible Views. This means, for 
instance, that it could provide all its services, and exercise all its 
functionality, even if the GUI framework is completely absent. Model 
code should never fail because of this. This is great for moving models 
from and two different runtimes (client, server, gemstone, various 
dialects, etc) and also for writing tests.
- Model behavior should not leak into Views. This means that if the 
views are removed (maybe to be replaced by some others, in the same or 
in another framework), Model should not lose state nor behavior. Model 
must be complete by itself.
So, the idea is essentially to protect the integrity and consistency of 
Models.

>>     This is the fundamental reason for me to consider that Morphic
>>     departed from that model, and that the pinacle of that M / V
>>     separation is the M2VC of VisualWorks.
>
>     PluggableMorphs attempted to follow this model (and give model
>     compatibility between Morphic and MVC). Etoys (if I remember
>     correctly) do the same, only that calling the model a "Player" and
>     the view a "Costume". Later, people forgot about view / model
>     separation, and Squeak became legacy software, in part because of
>     that.
>
>
> Maybe. I'm not sure of that particular factor. I have the feeling that 
> there is no clear and honest analysis on the state of GUI toolkits in 
> that universe, for present and future ones.
>
>>     Newer models in the literature around those years such as PAC
>>     proposed better abstractions, but they were never implemented.
>>     Now, it's interesting to see you advocate that model on top of
>>     Morphic.
>>
>>
>>         I agree that an Application object or such might make sense
>>         when you are building an application, especially if you need
>>         to deal with en external environment. But here we were
>>         talking about whether the Model classes should know about
>>         Morphs or not.
>>
>>
>>     In theory, no.
>>
>>     In practice, if you want a well tuned gui, I consider that yes,
>>     they need to be aware of them.
>
>     Please elaborate, or provide references.
>
>
> What would you think of a drag and drop feedback which is dependent of 
> the type of the model elements?

Well, lets assume a Model with 2 collections of elements. To make it 
sound a bit more concrete, lets call them Orders and Assets. And lets 
assume that the UI has some place(s) from where the user can drag many 
kinds of objects, like Orders, Assets, between others. Now, the user 
drags an Asset and wants to drop it into the Orders list. Given that the 
widget for the Orders list supports dropping, lets assume that its 
'dropActionSelector' is #addOrder:. This #addOrder: model method would 
be called with an Asset. So, #addOrder: could answer false, to let 
sender know that the addition was rejected (because it was not an 
Order!). It makes sense to have the method in ListWidget that calls 
'dropSelector' check for the result, and if it is false, let the user 
know that the drop was rejected, for instance, by keeping the dragged 
object in the hand.

>
>
>>     So the most elegant way I've used is the two models: a pure,
>>     abstract model, totally view independent. And a pragmatic, closer
>>     to the view / aware of the view, application model as an mediator.
>>
>>
>>
>>                     I think it is better for the View to start it all.
>>
>>
>>                 +1
>>
>>
>>             I prefer to model an Application concept in the target
>>             desktop environment if I want to model highly portable stuff.
>>
>>             That application concern can be folded into a dedicated
>>             view if that is the preferred convention in the target
>>             environment.
>>
>>             Regards,
>>
>>             Thierry
>>
>>
>>         I wonder how would this result in practice. Do you have some
>>         examples to share?
>>
>>
>>     I have a complex example, a system browser, would that fit?
>
>     Sure.
>
>
> Well, a short estimate on that particular application is that, linked 
> with the pluggable morphs, 10 to 20% of the code in the application 
> model is:
> - widget creation, setup, layout
> - dynamic morph addition / removal when activating certain functions 
> on the model
> - workarounds the pluggable morphs api to:
>   - dynamically refresh parts of the inside of widgets
>   - disconnect then reconnect links between widgets so that the 
> model-triggered update of one does not change the state of the other 
> one (i.e. protect the model from unwanted view triggered updates when 
> the model is changing part of its contents).

"View model" is a bit a misleading name. I'd say all this belongs in the 
Views world.

Besides, the method called to update Views after Model changes should 
not modify the Model. In this way, there would be no extra Model events 
triggered, and spurious updates would not occur. This might require 
enhancing the Views framework, if not mature enough.

>
> This application model uses mainly two widgets.
>
> I do have a long term plan to port that to Cuis, and I expect I will 
> have to write that very same code somewhere (maybe more, maybe less).
>
> Regards,
>
> Thierry

Hopefully, it will be less :)

Cheers,
Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/b3f58cf1/attachment-0004.html>

From garduino at gmail.com  Tue Nov 17 11:44:12 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Tue, 17 Nov 2015 14:44:12 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>
	<CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>
	<CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>
Message-ID: <CAEt3aLwUUCU8Qiqt_GphY1-8CpSxpbFSL75zXoAmTPY_hJjG_g@mail.gmail.com>

2015-11-17 14:14 GMT-03:00 Luciano Notarfrancesco <luchiano at gmail.com>:

> On Tue, Nov 17, 2015 at 3:57 PM, Germ?n Arduino <garduino at gmail.com>
> wrote:
>
>> Awesome!!
>>
>
> Haha, awesome is another window manager, it was also a fork of dwm, I used
> it for a while ;)
>
>
Related with this talk, I remember old times helping with LinEx (a Linux
made by the Extremadura government in Spain where my friend Diego GD was
working using Squeak in education) lot of fun playing with Squeak itself as
the Window Manager in charge of such Linux. Very very fun times!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151117/88c107c3/attachment-0004.html>

From thierry.goubier at gmail.com  Tue Nov 17 12:59:12 2015
From: thierry.goubier at gmail.com (Thierry Goubier)
Date: Tue, 17 Nov 2015 19:59:12 +0100
Subject: [Cuis] Fwd: Fwd: Patterns
In-Reply-To: <564B65A2.3050604@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
	<564B44B7.2070809@jvuletich.org>
	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
	<CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
	<564B65A2.3050604@jvuletich.org>
Message-ID: <564B7900.2030004@gmail.com>

Hi Juan,

Le 17/11/2015 18:36, Juan Vuletich a ?crit :
> Hi Thierry,
>
>>
>>
>> I would give HotDraw, and some of the original design pattern work on
>> editors, especially the parts derived from the InterViews toolkit.
>
> Uh, it is not easy to find stuff about that, so I can't really comment.

InterViews was kept alive as the ivtools for long, very long after 
InterViews lost to Motif as the X Window toolkit. Fresco, InterViews 
successor, was also very interesting.

HotDraw is old as well. But I did some cool stuff with it (a hypermedia 
system, in 1993).

>> Now, I used to be pretty up to date on the literature and some of the
>> criticism of the MVC model (especially the division between V and C)
>> but my memory of that time is all fuzzy.
>
> Well, in my opinion View / Model separation is a great property of the
> design of an application. Controller is more of a requirement of the
> ST-80 MVC framework. In principle, I see no problem in merging
> Controller into View. But, in Cuis, it can be argued that the Editor
> hierarchy is essentially a hierarchy of Controllers, and that's ok if
> the decomposition of responsibilities makes sense.
>
> In View / Model separation there are two restrictions that need to be
> honored:
> - The Model doesn't know about the possible Views. This means, for
> instance, that it could provide all its services, and exercise all its
> functionality, even if the GUI framework is completely absent. Model
> code should never fail because of this. This is great for moving models
> from and two different runtimes (client, server, gemstone, various
> dialects, etc) and also for writing tests.
> - Model behavior should not leak into Views. This means that if the
> views are removed (maybe to be replaced by some others, in the same or
> in another framework), Model should not lose state nor behavior. Model
> must be complete by itself.
> So, the idea is essentially to protect the integrity and consistency of
> Models.

I do agree with that objective, but, in practice, what I find as a 
result is that an additional layer (model mediation or the M2 of MMVC) 
helps immensely by:

- regrouping certain model features which are introduced to satisfy view 
requirements...

   - For example a pure model can just have a copy or save to file 
operation, but a view would like to have a feedback on the length of the 
operation. In non gui mode, having the model expose that sort of 
information is a needless waste of code and resources. This would better 
be carried by a layer on top (which is still a model IMHO, since it 
maintain a certain level of decoupling with a view).

- Expose explicitely certain adaptations which are made for a specific 
toolkit (they are in that model).

- Allow for user-features oriented models to appear on top of the pure, 
abstract model

   - In a browser, one can imagine scoped models of the code as a 
user-oriented feature that a disconnected mode doesn't need to integrate.

Nothing really grandiose or earth-shattering, mind you. Just convenient.

>> What would you think of a drag and drop feedback which is dependent of
>> the type of the model elements?
>
> Well, lets assume a Model with 2 collections of elements. To make it
> sound a bit more concrete, lets call them Orders and Assets. And lets
> assume that the UI has some place(s) from where the user can drag many
> kinds of objects, like Orders, Assets, between others. Now, the user
> drags an Asset and wants to drop it into the Orders list. Given that the
> widget for the Orders list supports dropping, lets assume that its
> 'dropActionSelector' is #addOrder:. This #addOrder: model method would
> be called with an Asset. So, #addOrder: could answer false, to let
> sender know that the addition was rejected (because it was not an
> Order!). It makes sense to have the method in ListWidget that calls
> 'dropSelector' check for the result, and if it is false, let the user
> know that the drop was rejected, for instance, by keeping the dragged
> object in the hand.

Hum, I was more thinking of what I am dealing with at the moment, which 
is a drop in the Orders list is a drop on a specific order item, which 
has to tell:

- during the drag, if a drop would be honored
- after the drop, if it is accepted or rejected
- and, if accepted, that specific order item changes state and is shown 
as such (and may also change the number of order items, etc...)

I found, when doing that, to have an intermediate model on top of my 
Asset/Order object to mediate with the drag and drop API very usefull 
(that is, what is displayed and dragged are Views on AssetModels which 
are themselves observers of Assets).


>
>>
>>
>>>     So the most elegant way I've used is the two models: a pure,
>>>     abstract model, totally view independent. And a pragmatic, closer
>>>     to the view / aware of the view, application model as an mediator.
>>>
>>>
>>>
>>>                     I think it is better for the View to start it all.
>>>
>>>
>>>                 +1
>>>
>>>
>>>             I prefer to model an Application concept in the target
>>>             desktop environment if I want to model highly portable stuff.
>>>
>>>             That application concern can be folded into a dedicated
>>>             view if that is the preferred convention in the target
>>>             environment.
>>>
>>>             Regards,
>>>
>>>             Thierry
>>>
>>>
>>>         I wonder how would this result in practice. Do you have some
>>>         examples to share?
>>>
>>>
>>>     I have a complex example, a system browser, would that fit?
>>
>>     Sure.
>>
>>
>> Well, a short estimate on that particular application is that, linked
>> with the pluggable morphs, 10 to 20% of the code in the application
>> model is:
>> - widget creation, setup, layout
>> - dynamic morph addition / removal when activating certain functions
>> on the model
>> - workarounds the pluggable morphs api to:
>>   - dynamically refresh parts of the inside of widgets
>>   - disconnect then reconnect links between widgets so that the
>> model-triggered update of one does not change the state of the other
>> one (i.e. protect the model from unwanted view triggered updates when
>> the model is changing part of its contents).
>
> "View model" is a bit a misleading name. I'd say all this belongs in the
> Views world.

As I said, it may be moved into the View world, in the sense that it 
holds view-related concerns. But, at the same time, it has Model like 
decoupling from the Views.

> Besides, the method called to update Views after Model changes should
> not modify the Model. In this way, there would be no extra Model events
> triggered, and spurious updates would not occur. This might require
> enhancing the Views framework, if not mature enough.

I'll let you have a try at that :)

>>
>> This application model uses mainly two widgets.
>>
>> I do have a long term plan to port that to Cuis, and I expect I will
>> have to write that very same code somewhere (maybe more, maybe less).
>>
>> Regards,
>>
>> Thierry
>
> Hopefully, it will be less :)

I'm certainly looking forward to it.

Regards,

Thierry



From dnorton at mindspring.com  Tue Nov 17 21:01:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 17 Nov 2015 22:01:56 -0500
Subject: [Cuis] Patterns
In-Reply-To: <564B32F5.9050102@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<564AB03D.1040405@gmail.com>, <564B32F5.9050102@jvuletich.org>
Message-ID: <564BEA24.27869.2592A08@dnorton.mindspring.com>

The repo now contains two pairs of classes: coupled and decoupled. As it stands, the 
coupled example comes up the same, whether from the World->New morph... menu or from 
a Browser or Workspace.

The decoupled example does not do this and I don't know what to have in the pattern to 
avoid the following pitfalls:

follow the BrowserWindow class #openBrowser and get MNU: owner
follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs

 - Dan

On 17 Nov 2015 at 11:00, Juan Vuletich wrote:

> Hi Thierry,
> 
> 
> On 11/17/2015 1:42 AM, Thierry Goubier wrote:
> > Le 17/11/2015 02:47, Germ?n Arduino a ?crit :
> >>
> >>
> >> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
> >> <mailto:juan at jvuletich.org>>:
> >>
> >>     __
> >>
> >>     Well, I don't like the #open method in the model. The idea of
> View /
> >>     Model separation is that views know about models, but models
> don't
> >>     know about views. A Model should exist independently of being
> used
> >>     from Morphic, MVC, Seaside, or any other UI framework. It
> could
> >>     live, for example, in a Gemstone database with no UI at all.
> Or ir
> >>     could travel to and from other systems, like VA Smalltalk,
> where the
> >>     UI framework is completely different from Cuis'.
> >>
> >>
> >> Interesting, really I never heard of the use of  #open at the
> model or I
> >> do not remember it at all, but I think similar to Juan.
> >
> > Hum, #open has to go somewhere, so...
> >
> > Either it goes into a sort of Application Model, which regroup the
> > duties associated with the application (the view + model +
> whatever is 
> > necessary in environment X), or it goes into an Application View
> which 
> > then has model concerns in it (it knows how to start or connect to
> the 
> > model, it knows what the model is composed of to connect subviews
> to 
> > model elements, etc...).
> >
> 
> The idea of view / model separation is pretty well explained in
> "Inside 
> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
> 
> I agree that an Application object or such might make sense when you
> are 
> building an application, especially if you need to deal with en
> external 
> environment. But here we were talking about whether the Model
> classes 
> should know about Morphs or not.
> 
> >>     I think it is better for the View to start it all.
> >>
> >>
> >> +1
> >
> > I prefer to model an Application concept in the target desktop 
> > environment if I want to model highly portable stuff.
> >
> > That application concern can be folded into a dedicated view if
> that 
> > is the preferred convention in the target environment.
> >
> > Regards,
> >
> > Thierry
> 
> I wonder how would this result in practice. Do you have some
> examples to 
> share?
> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From hannes.hirzel at gmail.com  Wed Nov 18 01:02:05 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Wed, 18 Nov 2015 08:02:05 +0100
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <564A7925.4060103@jvuletich.org>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
	<564A7925.4060103@jvuletich.org>
Message-ID: <CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>

On 11/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 14/11/2015 02:12 a.m., EuanM wrote:
>> I've just recently put-together a cross-platform Installation Tutorial
>> for beginners to Smalltalk.
>>
>> I was keen to include Cuis in the exercise.
>>
>
> Again, thank you for this.
>
>> One thing that becomes clear in the comparison is that Cuis is a good
>> beginner's environment from the point of view of size and complexity
>> and their bearing in learnability.
>>
>> It is however, the worst Smalltalk (of the 4 in the tutorial) to get
>> downloaded and installed.
>>
>> This seems a pity.
>
> Please take a look at
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Documentation
>
> . There are three 'Getting Started' guides, for different OSes and user
> style / preferences. They were tried (as described) in Linux, MacOsX and
> Windows.
>
>> Would anyone be willing to help me put together a One-Click Install
>> package, similar to Squeak's and Pharo's?
>>
>> (My plan is to do the grunt-work, if other people are willing to
>> indulge my noob questions while I do it)
>
> I believe that if you take the One-Click for Squeak or Pharo, and
> replace the image with a Cuis image, it should work.

It is worthwhile to have a look as well at the Squeak all-in-one package.

I have done it in the past in an adhoc way about by taking
http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.

There is quite some discussion about how this was constructed on the
Squeak list and people are willing to answer questions.

--Hannes

>> Is there a particular place that it could be hosted, once ready?
>>
>> Would anyone disagree with a 6-monthly update cycle for the One-Click
>> installer?
>>
>> (Frequent enough to send a signal to interested beginners that the
>> project is alive and kicking.  Infrequent enough that there is not
>> much work to be done)
>
> Yep, this sounds great. The natural place is
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev isn't it?
>
>
>> Cheers,
>>     Euan
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Wed Nov 18 07:00:23 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Wed, 18 Nov 2015 14:00:23 +0100
Subject: [Cuis] New Introductory Tutorial
In-Reply-To: <564A77EE.6060802@jvuletich.org>
References: <CALsRT0n1zh_7SjfpY=c+qaDSrVKLdyUzD_OKcMTz+RNO0GyNCw@mail.gmail.com>
	<564A77EE.6060802@jvuletich.org>
Message-ID: <CAGQxfVjCC2J7hBUEMhpYAg95Ti6=assjW-cKs6sG034CVXCv4Q@mail.gmail.com>

Hi Euan

Worthwhile to refer to in your tutorial is as well the web version of
the ProfStef Smalltalk tutorial implemented in Amber Smalltalk

http://amber-smalltalk.github.io/trysmalltalk/

(https://github.com/amber-smalltalk/trysmalltalk)

It explains the syntax, control constructs and some basic classes. It
was first implemented in Pharo and then ported.

--Hannes

On 11/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi EuanM,
>
> This is a great initiative. Thanks for including Cuis in the bunch!
>
> Cheers,
> Juan Vuletich
>
> On 14/11/2015 02:02 a.m., EuanM wrote:
>> I've created Yet Another Smalltalk First
>> Steps tutorial.
>>
>> This is intended as one of a series.
>>
>> It is designed to be cross-platform across
>>
>>      Squeak 5
>>      Pharo 4
>>      Seaside 3.1
>>      Cuis
>>      Dolphin 6
>>
>> If you have experience running any of these systems on Windows, Linux
>> or MacOS, please check to see if I have the instructions correct for
>> your chosen pairing of Smalltalk and OS platform.
>>
>> (As you'll see when you look, I do not have detailed instructions for
>> aspects of MacOS).
>>
>> The document is at:
>> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/get-smalltalk-up-and-running.html
>>
>> (It's intended to move to a different blog after this review process).
>>
>> I feel the need to do this as cross-Smalltalks tutorial because of
>> findings and 4 charts  I've placed at:
>> http://smalltalkinsmallsteps.blogspot.co.uk/2015/11/mindshare-of-smalltalk-in-development.html
>>
>> Essentially, Smalltalk mindshare and use is incredibly tiny, compared
>> to other languages in the same space.  (We all know this, but seeing
>> it represented graphically has a more visceral effect, IMO)
>>
>> Aggregating interest in all the Smalltalks still does not bring more
>> than a tiny proportion of the interest in, and use of, Ruby.
>>
>> In turn, Ruby is (quite understandably) small in comparison to
>> JavaScript.
>>
>> Comparing interest in any specific Smalltalk is, predictably, smaller
>> than the aggregate interest in Smalltalk.
>>
>> Our community seems determined to split itself into smaller and
>> smaller sub-communities.  I think we do ourselves a disservice this
>> way.
>>
>> My initial contribution will be to try to provide some explicitly
>> pan-Smalltalk beginners' tutorials, like this one.
>>
>> Cheers, and happy Smalltalking,
>>       EuanM
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Wed Nov 18 07:39:54 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 18 Nov 2015 10:39:54 -0300
Subject: [Cuis] Fwd: Fwd: Patterns
In-Reply-To: <564B7900.2030004@gmail.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<20151102152716.dd9dfae195e0a5c726b5474e@Whidbey.com>
	<563CF147.306@jvuletich.org>
	<564A5919.15040.19C7009@dnorton.mindspring.com>
	<564A7D91.6080102@jvuletich.org>
	<CAEt3aLybY3VEC8TR=7KynxhAC8oSYHwbvtHVRQynxVg27+4pfQ@mail.gmail.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<CALS0RF214Ct1GSV6e9Z7nuFDYQxm9aqCg+oJEkNrgO_O7gtATw@mail.gmail.com>
	<CALS0RF3hR8NdaE+0YGy9mms=+Ec4K9ak78Jh0YVdDo9N5yuADQ@mail.gmail.com>
	<564B44B7.2070809@jvuletich.org>
	<CALS0RF0VQqsmb34a1o-G2GJ57gre9xspKfVKywT5j1+QBG5NJA@mail.gmail.com>
	<CALS0RF0CKWyxQKa4U=eO3LopwjyJDod=HQ0FsSH9_3h+xeYTjA@mail.gmail.com>
	<564B65A2.3050604@jvuletich.org> <564B7900.2030004@gmail.com>
Message-ID: <564C7FAA.90900@jvuletich.org>

Hi Thierry,

(inline and abridged)
On 11/17/2015 3:59 PM, Thierry Goubier wrote:
> Hi Juan,
>
> Le 17/11/2015 18:36, Juan Vuletich a ?crit :
>> Hi Thierry,
>>
> ...
>>> Now, I used to be pretty up to date on the literature and some of the
>>> criticism of the MVC model (especially the division between V and C)
>>> but my memory of that time is all fuzzy.
>>
>> Well, in my opinion View / Model separation is a great property of the
>> design of an application. Controller is more of a requirement of the
>> ST-80 MVC framework. In principle, I see no problem in merging
>> Controller into View. But, in Cuis, it can be argued that the Editor
>> hierarchy is essentially a hierarchy of Controllers, and that's ok if
>> the decomposition of responsibilities makes sense.
>>
>> In View / Model separation there are two restrictions that need to be
>> honored:
>> - The Model doesn't know about the possible Views. This means, for
>> instance, that it could provide all its services, and exercise all its
>> functionality, even if the GUI framework is completely absent. Model
>> code should never fail because of this. This is great for moving models
>> from and two different runtimes (client, server, gemstone, various
>> dialects, etc) and also for writing tests.
>> - Model behavior should not leak into Views. This means that if the
>> views are removed (maybe to be replaced by some others, in the same or
>> in another framework), Model should not lose state nor behavior. Model
>> must be complete by itself.
>> So, the idea is essentially to protect the integrity and consistency of
>> Models.
>
> I do agree with that objective, but, in practice, what I find as a 
> result is that an additional layer (model mediation or the M2 of MMVC) 
> helps immensely by:
>
> - regrouping certain model features which are introduced to satisfy 
> view requirements...
>
>   - For example a pure model can just have a copy or save to file 
> operation, but a view would like to have a feedback on the length of 
> the operation. In non gui mode, having the model expose that sort of 
> information is a needless waste of code and resources. This would 
> better be carried by a layer on top (which is still a model IMHO, 
> since it maintain a certain level of decoupling with a view).
>
> - Expose explicitely certain adaptations which are made for a specific 
> toolkit (they are in that model).
>
> - Allow for user-features oriented models to appear on top of the 
> pure, abstract model
>
>   - In a browser, one can imagine scoped models of the code as a 
> user-oriented feature that a disconnected mode doesn't need to integrate.
>
> Nothing really grandiose or earth-shattering, mind you. Just convenient.

I agree. Many times it is really useful to add another layer. At Caesar 
we called those "Model Extensions".

In many cases, it is possible to do this in a way that is agnostic of 
the actual GUI framework, meaning that it can be used for several GUI 
styles. If this is the case, then it is OK to bundle this with the real 
Model, as it doesn't leak GUI framework specifics.

It is also very desirable not to compromise the consistency of the real 
Model, i.e. not leaking Model specifics. Then, it is also possible to 
bundle this with the Views. (This is what we usually did at Caesar).

If none of this conditions are met, i.e., this "ModelExtension" includes 
Model responsibilities AND detailed GUI framework knowledge, then I'd 
say some refactoring is in order. So, this doesn't go against strict 
View / Model separation.

>>> What would you think of a drag and drop feedback which is dependent of
>>> the type of the model elements?
>>
>> Well, lets assume a Model with 2 collections of elements. To make it
>> sound a bit more concrete, lets call them Orders and Assets. And lets
>> assume that the UI has some place(s) from where the user can drag many
>> kinds of objects, like Orders, Assets, between others. Now, the user
>> drags an Asset and wants to drop it into the Orders list. Given that the
>> widget for the Orders list supports dropping, lets assume that its
>> 'dropActionSelector' is #addOrder:. This #addOrder: model method would
>> be called with an Asset. So, #addOrder: could answer false, to let
>> sender know that the addition was rejected (because it was not an
>> Order!). It makes sense to have the method in ListWidget that calls
>> 'dropSelector' check for the result, and if it is false, let the user
>> know that the drop was rejected, for instance, by keeping the dragged
>> object in the hand.
>
> Hum, I was more thinking of what I am dealing with at the moment, 
> which is a drop in the Orders list is a drop on a specific order item, 
> which has to tell:
>
> - during the drag, if a drop would be honored
> - after the drop, if it is accepted or rejected
> - and, if accepted, that specific order item changes state and is 
> shown as such (and may also change the number of order items, etc...)
>
> I found, when doing that, to have an intermediate model on top of my 
> Asset/Order object to mediate with the drag and drop API very usefull 
> (that is, what is displayed and dragged are Views on AssetModels which 
> are themselves observers of Assets).

This is OK as long as it doesn't leak Model responsibilities, then it 
can just be a Model Extension that goes with the GUI.

>
>>
>>>
>>>
>>>>     So the most elegant way I've used is the two models: a pure,
>>>>     abstract model, totally view independent. And a pragmatic, closer
>>>>     to the view / aware of the view, application model as an mediator.
>>>>
>>>>
>>>>
>>>>                     I think it is better for the View to start it all.
>>>>
>>>>
>>>>                 +1
>>>>
>>>>
>>>>             I prefer to model an Application concept in the target
>>>>             desktop environment if I want to model highly portable 
>>>> stuff.
>>>>
>>>>             That application concern can be folded into a dedicated
>>>>             view if that is the preferred convention in the target
>>>>             environment.
>>>>
>>>>             Regards,
>>>>
>>>>             Thierry
>>>>
>>>>
>>>>         I wonder how would this result in practice. Do you have some
>>>>         examples to share?
>>>>
>>>>
>>>>     I have a complex example, a system browser, would that fit?
>>>
>>>     Sure.
>>>
>>>
>>> Well, a short estimate on that particular application is that, linked
>>> with the pluggable morphs, 10 to 20% of the code in the application
>>> model is:
>>> - widget creation, setup, layout
>>> - dynamic morph addition / removal when activating certain functions
>>> on the model
>>> - workarounds the pluggable morphs api to:
>>>   - dynamically refresh parts of the inside of widgets
>>>   - disconnect then reconnect links between widgets so that the
>>> model-triggered update of one does not change the state of the other
>>> one (i.e. protect the model from unwanted view triggered updates when
>>> the model is changing part of its contents).
>>
>> "View model" is a bit a misleading name. I'd say all this belongs in the
>> Views world.
>
> As I said, it may be moved into the View world, in the sense that it 
> holds view-related concerns. But, at the same time, it has Model like 
> decoupling from the Views.

Yep (as I said above).

>
>> Besides, the method called to update Views after Model changes should
>> not modify the Model. In this way, there would be no extra Model events
>> triggered, and spurious updates would not occur. This might require
>> enhancing the Views framework, if not mature enough.
>
> I'll let you have a try at that :)

Of course. In my experience, these kinds of problems always made the 
framework evolve. Yes, it is important to be able to fix and enhance the 
frameworks you use!

>
>>>
>>> This application model uses mainly two widgets.
>>>
>>> I do have a long term plan to port that to Cuis, and I expect I will
>>> have to write that very same code somewhere (maybe more, maybe less).
>>>
>>> Regards,
>>>
>>> Thierry
>>
>> Hopefully, it will be less :)
>
> I'm certainly looking forward to it.
>
> Regards,
>
> Thierry
>

Thanks for the discussion Thierry. I think we essentially agree on the 
important parts here.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Nov 18 07:42:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 18 Nov 2015 10:42:09 -0300
Subject: [Cuis] dynamic window manager
In-Reply-To: <CAEt3aLwUUCU8Qiqt_GphY1-8CpSxpbFSL75zXoAmTPY_hJjG_g@mail.gmail.com>
References: <CAL5GDyq10udKroMmK=QV8P-ua8nTzVfXdZpDi0Q9i33hcujW6g@mail.gmail.com>	<CAEt3aLw7u3czHJ5QD2W9vPXEusm=gmh-sCwcFHZVR8yR70udoA@mail.gmail.com>	<CAL5GDyrzf5vhL5Q4yjYg-dsu6-SAAOYLdbXe7xwwgdLhXKxDEA@mail.gmail.com>
	<CAEt3aLwUUCU8Qiqt_GphY1-8CpSxpbFSL75zXoAmTPY_hJjG_g@mail.gmail.com>
Message-ID: <564C8031.1040508@jvuletich.org>

On 11/17/2015 2:44 PM, Germ?n Arduino wrote:
>
> 2015-11-17 14:14 GMT-03:00 Luciano Notarfrancesco <luchiano at gmail.com 
> <mailto:luchiano at gmail.com>>:
>
>     On Tue, Nov 17, 2015 at 3:57 PM, Germ?n Arduino
>     <garduino at gmail.com <mailto:garduino at gmail.com>> wrote:
>
>         Awesome!!
>
>
>     Haha, awesome is another window manager, it was also a fork of
>     dwm, I used it for a while ;)
>
>
> Related with this talk, I remember old times helping with LinEx (a 
> Linux made by the Extremadura government in Spain where my friend 
> Diego GD was working using Squeak in education) lot of fun playing 
> with Squeak itself as the Window Manager in charge of such Linux. Very 
> very fun times!
>

Oh! I knew about LinEx, although I never used it. And didn't know about 
using Squeak as the Window Manager! That was also for non-Squeak 
windows, like a Bash terminal?

Thanks,
Juan Vuletih
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151118/200e56f2/attachment-0004.html>

From juan at jvuletich.org  Wed Nov 18 08:00:41 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 18 Nov 2015 11:00:41 -0300
Subject: [Cuis] Patterns
In-Reply-To: <564BEA24.27869.2592A08@dnorton.mindspring.com>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>,
	<564AB03D.1040405@gmail.com>, <564B32F5.9050102@jvuletich.org>
	<564BEA24.27869.2592A08@dnorton.mindspring.com>
Message-ID: <564C8489.2000601@jvuletich.org>

Hi Dan,

On 11/18/2015 12:01 AM, Dan Norton wrote:
> The repo now contains two pairs of classes: coupled and decoupled. As it stands, the
> coupled example comes up the same, whether from the World->New morph... menu or from
> a Browser or Workspace.
>
> The decoupled example does not do this and I don't know what to have in the pattern to
> avoid the following pitfalls:
>
> follow the BrowserWindow class #openBrowser and get MNU: owner
> follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs
>
>   - Dan

This is much nicer, thanks! To make the BrowserWindow style work, all 
you have to do is to have #open answer the new instance (instead of the 
class). WRT the ColorEditorPanel style, maybe Ken can comment, or a 
little debugging is in order :)

Cheers,
Juan Vuletich



From Ken.Dickey at Whidbey.com  Thu Nov 19 16:06:17 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 14:06:17 -0800
Subject: [Cuis] Patterns
In-Reply-To: <564C8489.2000601@jvuletich.org>
References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com>
	<564AB03D.1040405@gmail.com> <564B32F5.9050102@jvuletich.org>
	<564BEA24.27869.2592A08@dnorton.mindspring.com>
	<564C8489.2000601@jvuletich.org>
Message-ID: <20151119140617.2b8f709d321e79c421f5e7a8@Whidbey.com>

Greetings all!

I have been without power for a few days.  Overhead power lines through forest with 70 mph "wind events" each winter is a guarantee of on-island jobs and the lineman's union is very adverse to underground phone lines.  I must say that this does add interest to the "island living" experience!  8^)

Boy, did I miss a lot of eMail conversations!


On Wed, 18 Nov 2015 11:00:41 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> > follow the BrowserWindow class #openBrowser and get MNU: owner
> > follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs
> >
> >   - Dan

> This is much nicer, thanks! To make the BrowserWindow style work, all 
> you have to do is to have #open answer the new instance (instead of the 
> class). WRT the ColorEditorPanel style, maybe Ken can comment, or a 
> little debugging is in order :)

Actually, I was looking at color backgrounds which would not clash badly with color display and sliders.  Suggestions welcomed.  I still be learning too!

Glad to be back online,
-KenD



From Ken.Dickey at Whidbey.com  Thu Nov 19 16:36:28 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 14:36:28 -0800
Subject: [Cuis] ChromeOS vs Cog VM
Message-ID: <20151119143628.303636338485b6c420e023a7@Whidbey.com>

By the way, I got a chance to work with Tim Rowledge at the Nanaimo Camp Smalltalk.

I'm sure Tim would have rather showed me around the Raspberry Pi VM work, but I have been unable to get any Cog VMs to work on either of my ARM Chromebooks.

CogVM works fine on the ATM RasPi system.

It turns out that Chromebooks are very serious about protecting maximally against code hijacking.  They don't allow arbitrary code to be written into memory and executed.

This is very good for safety in an uncertain world, but is also the definition of Just-In-Time code generation.

I expected that Google's V8 JavaScript, which JITs, would show how to do this sanely under ChromeOS so that we could Cog it, but the code base for V8 shows that they only run the bytecodes -- no JIT -- on Chromebooks.


There is hope for the future, but some changes will be required:
See 

"Exploiting and Protecting Dynamic Code Generation"

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjguP_RxJ3JAhXQT4gKHS2VAUYQFggeMAA&url=http%3A%2F%2Fwenke.gtisc.gatech.edu%2Fpapers%2Fsdcg.pdf&usg=AFQjCNF52_QFDuMcP05WvfeHNi2wUK-yHg&sig2=8SzTcWKA7VBubmzdzJmIiA


Google's "Safe Self-Modifying Code" patent: (Patent! Ack!! 8^{)

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwilmsKlxZ3JAhVRKYgKHfXgDOMQFgg5MAM&url=http%3A%2F%2Fwww.google.com%2Fpatents%2FUS8850574&usg=AFQjCNHTAbYqbvqy80Edcww1YDsgUvoKMQ&sig2=FK01uFZEn778RNmRm7iz4A


Also "Certified Self-Modifying Code"

http://flint.cs.yale.edu/flint/publications/smctr.pdf

More hoops, sigh.

FYI,
-KenD



From Ken.Dickey at Whidbey.com  Thu Nov 19 16:38:31 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 14:38:31 -0800
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
Message-ID: <20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>

On Thu, 19 Nov 2015 14:36:28 -0800
KenD <Ken.Dickey at Whidbey.com> wrote:

> CogVM works fine on the ATM RasPi system.

Sorry.  That is the _ARM_ Raspberry Pi system.

Sausage fingers, sigh.
-KenD



From 0800nacho at gmail.com  Thu Nov 19 17:02:53 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Thu, 19 Nov 2015 20:02:53 -0300
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>
Message-ID: <CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w@mail.gmail.com>

In my x86 chromebook I had to chroot through crouton and run Cuis from
there.
It seems that porting the VM to NaCL is indeed a daunting job....
Perhaps once web assembly is there, things turn a little easier, I don't
know.
cheers!


*Lic. Ignacio Sniechowski, MBA*
*Prosavic SRL*

*Tel: (011) 4542-6714*


















On Thu, Nov 19, 2015 at 7:38 PM, KenD <Ken.Dickey at whidbey.com> wrote:

> On Thu, 19 Nov 2015 14:36:28 -0800
> KenD <Ken.Dickey at Whidbey.com> wrote:
>
> > CogVM works fine on the ATM RasPi system.
>
> Sorry.  That is the _ARM_ Raspberry Pi system.
>
> Sausage fingers, sigh.
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151119/53227dca/attachment-0004.html>

From Ken.Dickey at Whidbey.com  Thu Nov 19 18:27:32 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 19 Nov 2015 16:27:32 -0800
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w@mail.gmail.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<20151119143831.7d441ccd80e851e278a5d16d@Whidbey.com>
	<CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w@mail.gmail.com>
Message-ID: <20151119162732.d1620999640219efc0ace630@Whidbey.com>

On Thu, 19 Nov 2015 20:02:53 -0300
Ignacio Sniechowski <0800nacho at gmail.com> wrote:

> In my x86 chromebook I had to chroot through crouton and run Cuis from
> there.

That is what I am doing, using the stack-vm for ARM.


> It seems that porting the VM to NaCL is indeed a daunting job....

So it would appear..


Cheers, 
-KenD



From euanmee at gmail.com  Fri Nov 20 20:10:23 2015
From: euanmee at gmail.com (EuanM)
Date: Sat, 21 Nov 2015 02:10:23 +0000
Subject: [Cuis] ChromeOS vs Cog VM
Message-ID: <CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>

We can run Smalltalk on our ARM ChromeBooks!?!?

Where's the nearest How-to?


On 20 November 2015 at 18:00,  <cuis-request at jvuletich.org> wrote:
> Send Cuis mailing list submissions to
>         cuis at jvuletich.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> or, via email, send a message with subject or body 'help' to
>         cuis-request at jvuletich.org
>
> You can reach the person managing the list at
>         cuis-owner at jvuletich.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cuis digest..."
>
>
> Today's Topics:
>
>    1. Re: Patterns (KenD)
>    2. ChromeOS vs Cog VM (KenD)
>    3. Re: ChromeOS vs Cog VM (KenD)
>    4. Re: ChromeOS vs Cog VM (Ignacio Sniechowski)
>    5. Re: ChromeOS vs Cog VM (KenD)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Nov 2015 14:06:17 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Subject: Re: [Cuis] Patterns
> Message-ID: <20151119140617.2b8f709d321e79c421f5e7a8 at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> Greetings all!
>
> I have been without power for a few days.  Overhead power lines through forest with 70 mph "wind events" each winter is a guarantee of on-island jobs and the lineman's union is very adverse to underground phone lines.  I must say that this does add interest to the "island living" experience!  8^)
>
> Boy, did I miss a lot of eMail conversations!
>
>
> On Wed, 18 Nov 2015 11:00:41 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
>
>> > follow the BrowserWindow class #openBrowser and get MNU: owner
>> > follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs
>> >
>> >   - Dan
>
>> This is much nicer, thanks! To make the BrowserWindow style work, all
>> you have to do is to have #open answer the new instance (instead of the
>> class). WRT the ColorEditorPanel style, maybe Ken can comment, or a
>> little debugging is in order :)
>
> Actually, I was looking at color backgrounds which would not clash badly with color display and sliders.  Suggestions welcomed.  I still be learning too!
>
> Glad to be back online,
> -KenD
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 Nov 2015 14:36:28 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: tim Rowledge <tim at rowledge.org>
> Subject: [Cuis] ChromeOS vs Cog VM
> Message-ID: <20151119143628.303636338485b6c420e023a7 at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> By the way, I got a chance to work with Tim Rowledge at the Nanaimo Camp Smalltalk.
>
> I'm sure Tim would have rather showed me around the Raspberry Pi VM work, but I have been unable to get any Cog VMs to work on either of my ARM Chromebooks.
>
> CogVM works fine on the ATM RasPi system.
>
> It turns out that Chromebooks are very serious about protecting maximally against code hijacking.  They don't allow arbitrary code to be written into memory and executed.
>
> This is very good for safety in an uncertain world, but is also the definition of Just-In-Time code generation.
>
> I expected that Google's V8 JavaScript, which JITs, would show how to do this sanely under ChromeOS so that we could Cog it, but the code base for V8 shows that they only run the bytecodes -- no JIT -- on Chromebooks.
>
>
> There is hope for the future, but some changes will be required:
> See
>
> "Exploiting and Protecting Dynamic Code Generation"
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjguP_RxJ3JAhXQT4gKHS2VAUYQFggeMAA&url=http%3A%2F%2Fwenke.gtisc.gatech.edu%2Fpapers%2Fsdcg.pdf&usg=AFQjCNF52_QFDuMcP05WvfeHNi2wUK-yHg&sig2=8SzTcWKA7VBubmzdzJmIiA
>
>
> Google's "Safe Self-Modifying Code" patent: (Patent! Ack!! 8^{)
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwilmsKlxZ3JAhVRKYgKHfXgDOMQFgg5MAM&url=http%3A%2F%2Fwww.google.com%2Fpatents%2FUS8850574&usg=AFQjCNHTAbYqbvqy80Edcww1YDsgUvoKMQ&sig2=FK01uFZEn778RNmRm7iz4A
>
>
> Also "Certified Self-Modifying Code"
>
> http://flint.cs.yale.edu/flint/publications/smctr.pdf
>
> More hoops, sigh.
>
> FYI,
> -KenD
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 19 Nov 2015 14:38:31 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: tim Rowledge <tim at rowledge.org>
> Subject: Re: [Cuis] ChromeOS vs Cog VM
> Message-ID: <20151119143831.7d441ccd80e851e278a5d16d at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 19 Nov 2015 14:36:28 -0800
> KenD <Ken.Dickey at Whidbey.com> wrote:
>
>> CogVM works fine on the ATM RasPi system.
>
> Sorry.  That is the _ARM_ Raspberry Pi system.
>
> Sausage fingers, sigh.
> -KenD
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 19 Nov 2015 20:02:53 -0300
> From: Ignacio Sniechowski <0800nacho at gmail.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: tim Rowledge <tim at rowledge.org>
> Subject: Re: [Cuis] ChromeOS vs Cog VM
> Message-ID:
>         <CAMCzT-bUaAG74XmJVrM+p1jOhS-zGhE3HS8mQu-fAsuvtOm39w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> In my x86 chromebook I had to chroot through crouton and run Cuis from
> there.
> It seems that porting the VM to NaCL is indeed a daunting job....
> Perhaps once web assembly is there, things turn a little easier, I don't
> know.
> cheers!
>
>
> *Lic. Ignacio Sniechowski, MBA*
> *Prosavic SRL*
>
> *Tel: (011) 4542-6714*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Nov 19, 2015 at 7:38 PM, KenD <Ken.Dickey at whidbey.com> wrote:
>
>> On Thu, 19 Nov 2015 14:36:28 -0800
>> KenD <Ken.Dickey at Whidbey.com> wrote:
>>
>> > CogVM works fine on the ATM RasPi system.
>>
>> Sorry.  That is the _ARM_ Raspberry Pi system.
>>
>> Sausage fingers, sigh.
>> -KenD
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151119/53227dca/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 19 Nov 2015 16:27:32 -0800
> From: KenD <Ken.Dickey at Whidbey.com>
> To: cuis at jvuletich.org
> Subject: Re: [Cuis] ChromeOS vs Cog VM
> Message-ID: <20151119162732.d1620999640219efc0ace630 at Whidbey.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 19 Nov 2015 20:02:53 -0300
> Ignacio Sniechowski <0800nacho at gmail.com> wrote:
>
>> In my x86 chromebook I had to chroot through crouton and run Cuis from
>> there.
>
> That is what I am doing, using the stack-vm for ARM.
>
>
>> It seems that porting the VM to NaCL is indeed a daunting job....
>
> So it would appear..
>
>
> Cheers,
> -KenD
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 41, Issue 29
> ************************************



From 0800nacho at gmail.com  Sat Nov 21 06:53:02 2015
From: 0800nacho at gmail.com (nacho)
Date: Sat, 21 Nov 2015 04:53:02 -0800 (PST)
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>
Message-ID: <1448110382723-4862380.post@n4.nabble.com>

Yes Euan,
However bear in mind two things:
1) You have to put your Chromebook into developer mode. See here on how to
do it and what it means.
http://www.howtogeek.com/210817/how-to-enable-developer-mode-on-your-chromebook/

2) You have to install Crouton. Crouton chroots your ChromeOS with the Linux
equivalente (usually an Ubuntu, but other flavours my be chosen). See here
on how to install it, and all the options you have.
https://github.com/dnschneid/crouton

3) Install the Crouton extension, really helps.

4) Install an ARM based VM (check in Eliot Miranda place)
http://www.mirandabanda.org/files/Cog/VM/ and for a classic VM in
http://www.squeakvm.org/unix/

And that should do it.
Cheers
Nacho 



-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/ChromeOS-vs-Cog-VM-tp4862115p4862380.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From Ken.Dickey at Whidbey.com  Sat Nov 21 10:47:08 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Sat, 21 Nov 2015 08:47:08 -0800
Subject: [Cuis] ChromeOS vs Cog VM
In-Reply-To: <1448110382723-4862380.post@n4.nabble.com>
References: <20151119143628.303636338485b6c420e023a7@Whidbey.com>
	<CALsRT0m9cWpNUD2gep_A+9xcKmfWbDOYdHkxoCVtp1MQYw2fig@mail.gmail.com>
	<1448110382723-4862380.post@n4.nabble.com>
Message-ID: <20151121084708.d29f22f6470bb56c300f7e48@Whidbey.com>

On Sat, 21 Nov 2015 04:53:02 -0800 (PST)
nacho <0800nacho at gmail.com> wrote:

> 4) Install an ARM based VM (check in Eliot Miranda place)
> http://www.mirandabanda.org/files/Cog/VM/ and for a classic VM in
> http://www.squeakvm.org/unix/

Nacho,

Great instructions.  I do almost all my work on an ARM Chromebook these days.

FYI I am using stklinuxhtARM-15.24.3386.tgz

Few of the Cog builds do stklinuxhtARM.

Cheers,
-KenD



From Ken.Dickey at whidbey.com  Fri Nov 20 23:47:36 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sat, 21 Nov 2015 13:47:36 +0800
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
	<564A7925.4060103@jvuletich.org>
	<CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>
Message-ID: <20151121134736.8c5073e5fbb43076d2defbf7@whidbey.com>

On Wed, 18 Nov 2015 08:02:05 +0100
"H. Hirzel" <hannes.hirzel at gmail.com> wrote:

> It is worthwhile to have a look as well at the Squeak all-in-one package.
> 
> I have done it in the past in an adhoc way about by taking
> http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.

Note that Squeak 5.0 uses the new Spur memory format which is incompatable with the older (4.x and Cuis) image format. 

Cheers,
-KenD



From euanmee at gmail.com  Sun Nov 22 17:05:26 2015
From: euanmee at gmail.com (EuanM)
Date: Sun, 22 Nov 2015 23:05:26 +0000
Subject: [Cuis] One-Click Installer for Cuis
Message-ID: <CALsRT0nu5CeinNX_8jjP=RvrJKkmMu18kNwEN-fLSq4KCALi4A@mail.gmail.com>

That's a useful thing to know!

Is there a sense of when Cuis will be able to use the Spur VM?  Squeak
5.0 is *much* faster on ARM than Squeak 4.6 (thanks to Tim Rowledge
and co).

And my own usecase for Cuis is the Raspberry Pi.  (and of course, now
also development on my Chromebook)

Cheers,
    EuanM

On 22 November 2015 at 18:00,  <cuis-request at jvuletich.org> wrote:
> Date: Sat, 21 Nov 2015 13:47:36 +0800
> From: "Ken.Dickey" <Ken.Dickey at whidbey.com>
>
> On Wed, 18 Nov 2015 08:02:05 +0100
> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>
>> It is worthwhile to have a look as well at the Squeak all-in-one package.
>>
>> I have done it in the past in an adhoc way about by taking
>> http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.
>
> Note that Squeak 5.0 uses the new Spur memory format which is incompatable with the older (4.x and Cuis) image format.
>
> Cheers,
> -KenD
>



From juan at jvuletich.org  Mon Nov 23 06:59:47 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 23 Nov 2015 09:59:47 -0300
Subject: [Cuis] New updates
Message-ID: <56530DC3.3040609@jvuletich.org>

Hi all,

I recently included some new updates:

- Fixes to Exceptions by Andr?s Valloud and Martin McClure.
- Assessments framework for testing and validation by Andr?s Valloud.
- Many fixes and enhancements to Layouts, Window drawing, keyboard 
shortcuts, etc. by Luciano Notarfrancesco

Thank you very much Folks! Andr?s, Luciano, please comment a bit on what 
you did, especially subtle but important behavior such as Exceptions and 
new stuff like Assessments, and the new Theme and Window Manager.

Cheers,
Juan Vuletich



From 0800nacho at gmail.com  Mon Nov 23 08:37:07 2015
From: 0800nacho at gmail.com (nacho)
Date: Mon, 23 Nov 2015 06:37:07 -0800 (PST)
Subject: [Cuis] Basic & probably stupid question.
Message-ID: <1448289427985-4862695.post@n4.nabble.com>

Hi Folks,
I'm trying an example from Inside Smalltalk vol.1

When I try to print:

| anArray |
anArray _ Array new.
anArray at: 1 put: 'hello'; at: 2 put: 'nacho'; at: 3 put: 'pepito'.

I receive:
subscript is out of bounds: 1
Where as according to the book I should receive the 3th element.

The same happens when I try to print:
| anArray |
anArray _ Array new.
anArray at: 1 put: 'hello'; at: 2 put: 'nacho'; at: 3 put: 'pepito';
yourself.

which according to the book should return anArray.

is the at:put: selector different in Cuis?
Thanks in advance
Nacho




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Basic-probably-stupid-question-tp4862695.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From 0800nacho at gmail.com  Mon Nov 23 08:44:27 2015
From: 0800nacho at gmail.com (nacho)
Date: Mon, 23 Nov 2015 06:44:27 -0800 (PST)
Subject: [Cuis] Basic & probably stupid question.
In-Reply-To: <1448289427985-4862695.post@n4.nabble.com>
References: <1448289427985-4862695.post@n4.nabble.com>
Message-ID: <1448289867935-4862701.post@n4.nabble.com>

I figured it out.
It was indeed a stupid question.
Arrays are fixed so I should do:
anArray _ Array new: 3.

cheers




-----
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: http://forum.world.st/Basic-probably-stupid-question-tp4862695p4862701.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From luchiano at gmail.com  Mon Nov 23 09:35:06 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Mon, 23 Nov 2015 15:35:06 +0000
Subject: [Cuis] New updates
In-Reply-To: <56530DC3.3040609@jvuletich.org>
References: <56530DC3.3040609@jvuletich.org>
Message-ID: <CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>

Hi all,
About my recent changes, some of them are 1) extensions to Theme to be able
to customize some more aspects of how the windows and widgets look, or 2)
fixes for small bugs that I found on the way, like misalignments of a few
pixels between parts of a widget or a window. The motivation behind this
was just to be able to implement a very minimalist look (borders of just 1
pixel, no decorations, no icons, no anything that I dont need and takes up
screen real estate), and a sort of tiling dynamic window manager very much
like http://dwm.suckless.org (https://github.com/len/Cuis-Smalltalk-DWM).

In order to implement this "window manager" as an external package with
minimal changes to the core system, I decided to: 1) make the current Theme
receive messages #windowOpen: #windowClosed: every time SystemWindows are
open or closed, in order to give it a chance to implement window-management
behaviour or delegate it to a proper window manager; 2) move the
window-management keyboard shortcuts (like alt-w to close) to Theme, so it
is all in one place, easy to change, and easy to make a Theme that
delegates keyboard events to a proper window manager.

Again I did it like this in order to minimize changes to the core system.
At the moment window management is in part implemented in SystemWindow, and
also in HandMorph and Morph. I had to make some small modifications in
order to get the desired behavior when using DWM, and keep the original
behavior in the base system. Maybe in the long run we would want to have a
WindowManager class that do this, handle keyboard events for the
window-management shortcuts and receives #windowOpen: and #windowClosed:,
etc. But I would like to think better about this before adding new concepts
and complexity to the core.

Cheers,
Luciano


On Mon, Nov 23, 2015 at 12:59 PM, Juan Vuletich <juan at jvuletich.org> wrote:

> Hi all,
>
> I recently included some new updates:
>
> - Fixes to Exceptions by Andr?s Valloud and Martin McClure.
> - Assessments framework for testing and validation by Andr?s Valloud.
> - Many fixes and enhancements to Layouts, Window drawing, keyboard
> shortcuts, etc. by Luciano Notarfrancesco
>
> Thank you very much Folks! Andr?s, Luciano, please comment a bit on what
> you did, especially subtle but important behavior such as Exceptions and
> new stuff like Assessments, and the new Theme and Window Manager.
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151123/42175fe6/attachment-0004.html>

From hannes.hirzel at gmail.com  Tue Nov 24 08:56:19 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 24 Nov 2015 15:56:19 +0100
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <20151121134736.8c5073e5fbb43076d2defbf7@whidbey.com>
References: <CALsRT0n5sE+pwwz-xWuyH7x96AsDJKYhC4mzE5PRbLrnR6i5pA@mail.gmail.com>
	<564A7925.4060103@jvuletich.org>
	<CAGQxfViFYNLJ3rw0ywOymZ4CMasq0rLKc_4M1KnT2HTFe8eE8A@mail.gmail.com>
	<20151121134736.8c5073e5fbb43076d2defbf7@whidbey.com>
Message-ID: <CAGQxfVh++xk8YNESwEgwGM-2OXOx2O_fckMtWJDS5v-EQSN6oA@mail.gmail.com>

On 11/21/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Wed, 18 Nov 2015 08:02:05 +0100
> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>
>> It is worthwhile to have a look as well at the Squeak all-in-one package.
>>
>> I have done it in the past in an adhoc way about by taking
>> http://ftp.squeak.org/5.0/Squeak-5.0-All-in-One.zip.
>
> Note that Squeak 5.0 uses the new Spur memory format which is incompatable
> with the older (4.x and Cuis) image format.

Thanks, Ken for the correction. I based the ad-hoc Cuis all-in-one on
http://ftp.squeak.org/4.6/Squeak-4.6-All-in-One.zip

--Hannes

>
> Cheers,
> -KenD
>



From Ken.Dickey at Whidbey.com  Tue Nov 24 18:08:31 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Tue, 24 Nov 2015 16:08:31 -0800
Subject: [Cuis] One-Click Installer for Cuis
In-Reply-To: <CALsRT0nu5CeinNX_8jjP=RvrJKkmMu18kNwEN-fLSq4KCALi4A@mail.gmail.com>
References: <CALsRT0nu5CeinNX_8jjP=RvrJKkmMu18kNwEN-fLSq4KCALi4A@mail.gmail.com>
Message-ID: <20151124160831.2314ed8c9a831809c0321069@Whidbey.com>

On Sun, 22 Nov 2015 23:05:26 +0000
EuanM <euanmee at gmail.com> wrote:

> Is there a sense of when Cuis will be able to use the Spur VM?  

You pushed me over the edge.  I am now/currently working on this.

> > Note that Squeak 5.0 uses the new Spur memory format which is incompatable with the older (4.x and Cuis) image format.

FYI, stkspurlinuxhtARM-15.24.3386.tgz can run Squeak 5.0 images on an ARM Chromebook under Crouton/Ubuntu.

Cheers,
-KenD



From luchiano at gmail.com  Thu Nov 26 00:53:52 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Thu, 26 Nov 2015 06:53:52 +0000
Subject: [Cuis] image segments
Message-ID: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>

I don't see image segments in Cuis... I don't even know if they still exist
in Squeak... Anyone is still using it?

It would be cool to have it at least as a package. If I remember correctly
it was very simple, like two primitives to load and save, but I think it
depended on something like mark and sweep or some particular kind of
garbage collector and it might not work in new VMs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151126/8333877d/attachment-0004.html>

From hannes.hirzel at gmail.com  Thu Nov 26 01:36:49 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 07:36:49 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
Message-ID: <CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>

Squeak 5.0 still has ImageSegments (class comment below). Saving and
loading of  projects currently is blocked in Squeak because of an
unfinished name space (environments implementation).

http://wiki.squeak.org/squeak/6218

And there is Fuel
http://rmod.inria.fr/web/software/Fuel

----------

ImageSegment

I represent a segment of Squeak address space.  I am created from an
array of root objects.  After storing, my segment contains a binary
encoding of every object accessible from my roots but not otherwise
accessible from anywhere else in the system.  My segment contains
outward pointers that are indices into my table of outPointers.
On load my segment is converted back into objects and becommed
into an Array of the loaded objects, so they can be enumerated.

	The main use of ImageSegments is to store Projects.  A dummy
version of SmartRefStream traverses the Project.  Everything it finds
is classified as either an object that is owned by the project (only
pointed to inside the project), or an object outside the project that
is pointed to from inside the project.  The objects that are
completely owned by the project are compressed into pure binary form
in an ImageSegment.  The outside objects are put in the 'outPointers'
array.  The entire ImageSegment (binary part plus outPointers) is
encoded in a SmartRefStream, and saved on the disk.  (aProject
exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
writeForExportWithSources:inDirectory:changeSet:).

	Note that every object inside the project is put into the
segment's arrayOfRoots.  This is because a dummy SmartRefStream to
scan the project, in order to make intelligent decisions about what
belongs in the project.
	See Project's class comment for what messages are sent to
objects as they are unpacked in a new image.

---- Older Details ------

	The primary kind of image segment is an Export Segment.  It
can be saved on a server and read into a completely different Squeak
image.
Old way to create one:
(ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz class))
		writeForExport: 'myFile.extSeg'.
Old way to create one for a project:
	(Project named: 'Play With Me - 3') exportSegment.
To read it into another image:  Select 'myFile.extSeg' in a FileList,
Menu 'load as project'.  It will install its classes automatically.
If you need to see the roots array, it is temporarily stored in
(SmartRefStream scannedObject).

Most of 'states' of an ImageSegment are not used to export a project,
and have been abandoned.

	When a segment is written out onto a file, it goes in a
folder called <image name>_segs.  If your image is called
"Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
image whenever your move, copy, or rename it.
	Whenever a Class is in arrayOfRoots, its class (aClass class)
must also be in the arrayOfRoots.
	There are two kinds of image segments.  Normal image segments
are a piece of a specific Squeak image, and can only be read back
into that image.  The image holds the array of outPointers that are
necessary to turn the bits in the file into objects.
	To put out a normal segment that holds a Project (not the
current project), execute (Project named: 'xxx') storeSegment.


arrayOfRoots	The objects that head the tree we will trace.
segment			The WordArray of raw bits of all objects in the tree.
outPointers		Oops of all objects outside the segment
pointed to from inside.
state			(see below)
segmentName	Its basic name.  Often the name of a Project.
fileName		The local name of the file.  'Foo-23.seg'
userRootCnt		number of roots submitted by caller.  Extras
are added in preparation for saving.

state that an ImageSegment may exist in...

#activeCopy			(has been copied, with the intent to
become active)
arrayOfRoots, segment, and outPointers have been created by
copyFromRoots:.  The tree of objects has been encoded in the segment,
but those objects are still present in the Squeak system.

#active				(segment is actively holding objects)
The segment is now the only holder of tree of objects.  Each of the
original roots has been transmuted into an ImageSegmentRootStub that
refers back to this image segment.  The original objects in the
segment will all be garbageCollected.

#onFile
The segment has been written out to a file and replaced by a file
pointer.  Only ImageSegmentRootStubs and the array of outPointers
remains in the image.  To get this far:
(ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
		writeToFile: 'myFile.seg'.

#inactive
The segment has been brought back into memory and turned back into
objects.  rootsArray is set, but the segment is invalid.

#onFileWithSymbols
The segment has been written out to a file, along with the text of
all the symbols in the outPointers array, and replaced by a file
pointer.  This reduces the size of the outPointers array, and also
allows the system to reclaim any symbols that are not referred to
from elsewhere in the image.  The specific format used is that of a
literal array as follows:
	#(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' # symbol5).
In this case, the original outPointers array was 8 long, but the
compacted table of outPointers retains only two entries.  These get
inserted in place of the #'s in the array of symbols after it is read
back in.  Symbols with embedded spaces or other strange characters
are written as strings, and converted back to symbols when read back
in.  The symbol # is never written out.
	NOTE: All IdentitySets or dictionaries must be rehashed when
being read back from this format.  The symbols are effectively
internal.  (No, not if read back into same image.  If a different
image, then use #imported.  -tk)

#imported
The segment is on an external file or just read in from one.  The
segment and outPointers are meant to be read into a foreign image.
In this form, the image segment can be read from a URL, and
installed.  A copy of the original array of root objects is
constructed, with former outPointers bound to existing objects in the
host system.
	(Any Class inside the segment MUST be in the arrayOfRoots.
This is so its association can be inserted into Smalltalk.  The
class's metaclass must be in roots also.  Methods that are in
outPointers because blocks point at them, were found and added to the
roots.
	All IdentitySets and dictionaries are rehashed when being
read back from exported segments.)


To discover why only some of the objects in a project are being
written out, try this (***Destructive Test***).  This breaks lots of
backpointers in the target project, and puts up an array of
suspicious objects, a list of the classes of the outPointers, and a
debugger.
"Close any transcripts in the target project"
World currentHand objectToPaste ifNotNil: [
	self inform: 'Hand is holding a Morph in its paste buffer:\' withCRs,
		World currentHand objectToPaste printString].
PV := Project named: 'xxxx'.
(IS := ImageSegment new) findRogueRootsImSeg:
	(Array with: PV world presenter with: PV world).
IS findOwnersOutPtrs.	"Optionally: write a file with owner chains"
"Quit and DO NOT save"

When an export image segment is brought into an image, it is like an
image starting up.  Certain startUp messages need to be run.  These
are byte and word reversals for nonPointer data that comes from a
machine of the opposite endianness.  #startUpProc passes over all
objects in the segment, and:
	The first time an instance of class X is encountered, (msg _
X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
case, it means that instances of X do not need special work.  X is
included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
store it in the dictionary, startUps (aClass -> aMessage).
	When a later instance of X is encountered, if X is in
noStartUpNeeded, do nothing.  If X is in startUps, send the message
to the instance.  Typically this is a message like #swapShortObjects.
	Every class that implements #startUp, should see if it needs
a parallel implementation of #startUpFrom:.

On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> I don't see image segments in Cuis... I don't even know if they still exist
> in Squeak... Anyone is still using it?
>
> It would be cool to have it at least as a package. If I remember correctly
> it was very simple, like two primitives to load and save, but I think it
> depended on something like mark and sweep or some particular kind of
> garbage collector and it might not work in new VMs.
>



From hannes.hirzel at gmail.com  Thu Nov 26 02:02:11 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 08:02:11 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
Message-ID: <CAGQxfVg0Oy-b5b-fZJwL39Zb_SnKhqiiti4mcK6wonNrrSMUPA@mail.gmail.com>

P.S. For a working version of Project save/load in Squeak go back to
version 4.4 or maybe 4.3

http://squeak.org/downloads/

On 11/26/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Squeak 5.0 still has ImageSegments (class comment below). Saving and
> loading of  projects currently is blocked in Squeak because of an
> unfinished name space (environments implementation).
>
> http://wiki.squeak.org/squeak/6218
>
> And there is Fuel
> http://rmod.inria.fr/web/software/Fuel
>
> ----------
>
> ImageSegment
>
> I represent a segment of Squeak address space.  I am created from an
> array of root objects.  After storing, my segment contains a binary
> encoding of every object accessible from my roots but not otherwise
> accessible from anywhere else in the system.  My segment contains
> outward pointers that are indices into my table of outPointers.
> On load my segment is converted back into objects and becommed
> into an Array of the loaded objects, so they can be enumerated.
>
> 	The main use of ImageSegments is to store Projects.  A dummy
> version of SmartRefStream traverses the Project.  Everything it finds
> is classified as either an object that is owned by the project (only
> pointed to inside the project), or an object outside the project that
> is pointed to from inside the project.  The objects that are
> completely owned by the project are compressed into pure binary form
> in an ImageSegment.  The outside objects are put in the 'outPointers'
> array.  The entire ImageSegment (binary part plus outPointers) is
> encoded in a SmartRefStream, and saved on the disk.  (aProject
> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
> writeForExportWithSources:inDirectory:changeSet:).
>
> 	Note that every object inside the project is put into the
> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
> scan the project, in order to make intelligent decisions about what
> belongs in the project.
> 	See Project's class comment for what messages are sent to
> objects as they are unpacked in a new image.
>
> ---- Older Details ------
>
> 	The primary kind of image segment is an Export Segment.  It
> can be saved on a server and read into a completely different Squeak
> image.
> Old way to create one:
> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
> class))
> 		writeForExport: 'myFile.extSeg'.
> Old way to create one for a project:
> 	(Project named: 'Play With Me - 3') exportSegment.
> To read it into another image:  Select 'myFile.extSeg' in a FileList,
> Menu 'load as project'.  It will install its classes automatically.
> If you need to see the roots array, it is temporarily stored in
> (SmartRefStream scannedObject).
>
> Most of 'states' of an ImageSegment are not used to export a project,
> and have been abandoned.
>
> 	When a segment is written out onto a file, it goes in a
> folder called <image name>_segs.  If your image is called
> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
> image whenever your move, copy, or rename it.
> 	Whenever a Class is in arrayOfRoots, its class (aClass class)
> must also be in the arrayOfRoots.
> 	There are two kinds of image segments.  Normal image segments
> are a piece of a specific Squeak image, and can only be read back
> into that image.  The image holds the array of outPointers that are
> necessary to turn the bits in the file into objects.
> 	To put out a normal segment that holds a Project (not the
> current project), execute (Project named: 'xxx') storeSegment.
>
>
> arrayOfRoots	The objects that head the tree we will trace.
> segment			The WordArray of raw bits of all objects in the tree.
> outPointers		Oops of all objects outside the segment
> pointed to from inside.
> state			(see below)
> segmentName	Its basic name.  Often the name of a Project.
> fileName		The local name of the file.  'Foo-23.seg'
> userRootCnt		number of roots submitted by caller.  Extras
> are added in preparation for saving.
>
> state that an ImageSegment may exist in...
>
> #activeCopy			(has been copied, with the intent to
> become active)
> arrayOfRoots, segment, and outPointers have been created by
> copyFromRoots:.  The tree of objects has been encoded in the segment,
> but those objects are still present in the Squeak system.
>
> #active				(segment is actively holding objects)
> The segment is now the only holder of tree of objects.  Each of the
> original roots has been transmuted into an ImageSegmentRootStub that
> refers back to this image segment.  The original objects in the
> segment will all be garbageCollected.
>
> #onFile
> The segment has been written out to a file and replaced by a file
> pointer.  Only ImageSegmentRootStubs and the array of outPointers
> remains in the image.  To get this far:
> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
> 		writeToFile: 'myFile.seg'.
>
> #inactive
> The segment has been brought back into memory and turned back into
> objects.  rootsArray is set, but the segment is invalid.
>
> #onFileWithSymbols
> The segment has been written out to a file, along with the text of
> all the symbols in the outPointers array, and replaced by a file
> pointer.  This reduces the size of the outPointers array, and also
> allows the system to reclaim any symbols that are not referred to
> from elsewhere in the image.  The specific format used is that of a
> literal array as follows:
> 	#(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' # symbol5).
> In this case, the original outPointers array was 8 long, but the
> compacted table of outPointers retains only two entries.  These get
> inserted in place of the #'s in the array of symbols after it is read
> back in.  Symbols with embedded spaces or other strange characters
> are written as strings, and converted back to symbols when read back
> in.  The symbol # is never written out.
> 	NOTE: All IdentitySets or dictionaries must be rehashed when
> being read back from this format.  The symbols are effectively
> internal.  (No, not if read back into same image.  If a different
> image, then use #imported.  -tk)
>
> #imported
> The segment is on an external file or just read in from one.  The
> segment and outPointers are meant to be read into a foreign image.
> In this form, the image segment can be read from a URL, and
> installed.  A copy of the original array of root objects is
> constructed, with former outPointers bound to existing objects in the
> host system.
> 	(Any Class inside the segment MUST be in the arrayOfRoots.
> This is so its association can be inserted into Smalltalk.  The
> class's metaclass must be in roots also.  Methods that are in
> outPointers because blocks point at them, were found and added to the
> roots.
> 	All IdentitySets and dictionaries are rehashed when being
> read back from exported segments.)
>
>
> To discover why only some of the objects in a project are being
> written out, try this (***Destructive Test***).  This breaks lots of
> backpointers in the target project, and puts up an array of
> suspicious objects, a list of the classes of the outPointers, and a
> debugger.
> "Close any transcripts in the target project"
> World currentHand objectToPaste ifNotNil: [
> 	self inform: 'Hand is holding a Morph in its paste buffer:\' withCRs,
> 		World currentHand objectToPaste printString].
> PV := Project named: 'xxxx'.
> (IS := ImageSegment new) findRogueRootsImSeg:
> 	(Array with: PV world presenter with: PV world).
> IS findOwnersOutPtrs.	"Optionally: write a file with owner chains"
> "Quit and DO NOT save"
>
> When an export image segment is brought into an image, it is like an
> image starting up.  Certain startUp messages need to be run.  These
> are byte and word reversals for nonPointer data that comes from a
> machine of the opposite endianness.  #startUpProc passes over all
> objects in the segment, and:
> 	The first time an instance of class X is encountered, (msg _
> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
> case, it means that instances of X do not need special work.  X is
> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
> store it in the dictionary, startUps (aClass -> aMessage).
> 	When a later instance of X is encountered, if X is in
> noStartUpNeeded, do nothing.  If X is in startUps, send the message
> to the instance.  Typically this is a message like #swapShortObjects.
> 	Every class that implements #startUp, should see if it needs
> a parallel implementation of #startUpFrom:.
>
> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>> I don't see image segments in Cuis... I don't even know if they still
>> exist
>> in Squeak... Anyone is still using it?
>>
>> It would be cool to have it at least as a package. If I remember
>> correctly
>> it was very simple, like two primitives to load and save, but I think it
>> depended on something like mark and sweep or some particular kind of
>> garbage collector and it might not work in new VMs.
>>
>



From luchiano at gmail.com  Thu Nov 26 08:10:21 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Thu, 26 Nov 2015 14:10:21 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
Message-ID: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>

Cool, maybe it's possible to make it into a package, I'll take a look.

I've never used it to store Projects, tho..  I used before to store things
that must be loaded very fast on demand and can be forgotten once there are
no more references to them.. like image fragments that compose a map of the
world, and small sound fragments that are used to synthesize speech
(diphones). Yesterday I just wanted to know how big are my objects, and I
wanted to make some experiments to see how the bit-size of my objects grow
as the problems I'm modeling grow by some other measure (degree of
polynomials, size of matrices are the most basic) and to know how much
memory are my algorithms actually using at every step... image segments are
ideal for this, you can use them to know exactly how much memory would be
freed if a reference to a given object were forgotten.


On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> Squeak 5.0 still has ImageSegments (class comment below). Saving and
> loading of  projects currently is blocked in Squeak because of an
> unfinished name space (environments implementation).
>
> http://wiki.squeak.org/squeak/6218
>
> And there is Fuel
> http://rmod.inria.fr/web/software/Fuel
>
> ----------
>
> ImageSegment
>
> I represent a segment of Squeak address space.  I am created from an
> array of root objects.  After storing, my segment contains a binary
> encoding of every object accessible from my roots but not otherwise
> accessible from anywhere else in the system.  My segment contains
> outward pointers that are indices into my table of outPointers.
> On load my segment is converted back into objects and becommed
> into an Array of the loaded objects, so they can be enumerated.
>
>         The main use of ImageSegments is to store Projects.  A dummy
> version of SmartRefStream traverses the Project.  Everything it finds
> is classified as either an object that is owned by the project (only
> pointed to inside the project), or an object outside the project that
> is pointed to from inside the project.  The objects that are
> completely owned by the project are compressed into pure binary form
> in an ImageSegment.  The outside objects are put in the 'outPointers'
> array.  The entire ImageSegment (binary part plus outPointers) is
> encoded in a SmartRefStream, and saved on the disk.  (aProject
> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
> writeForExportWithSources:inDirectory:changeSet:).
>
>         Note that every object inside the project is put into the
> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
> scan the project, in order to make intelligent decisions about what
> belongs in the project.
>         See Project's class comment for what messages are sent to
> objects as they are unpacked in a new image.
>
> ---- Older Details ------
>
>         The primary kind of image segment is an Export Segment.  It
> can be saved on a server and read into a completely different Squeak
> image.
> Old way to create one:
> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
> class))
>                 writeForExport: 'myFile.extSeg'.
> Old way to create one for a project:
>         (Project named: 'Play With Me - 3') exportSegment.
> To read it into another image:  Select 'myFile.extSeg' in a FileList,
> Menu 'load as project'.  It will install its classes automatically.
> If you need to see the roots array, it is temporarily stored in
> (SmartRefStream scannedObject).
>
> Most of 'states' of an ImageSegment are not used to export a project,
> and have been abandoned.
>
>         When a segment is written out onto a file, it goes in a
> folder called <image name>_segs.  If your image is called
> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
> image whenever your move, copy, or rename it.
>         Whenever a Class is in arrayOfRoots, its class (aClass class)
> must also be in the arrayOfRoots.
>         There are two kinds of image segments.  Normal image segments
> are a piece of a specific Squeak image, and can only be read back
> into that image.  The image holds the array of outPointers that are
> necessary to turn the bits in the file into objects.
>         To put out a normal segment that holds a Project (not the
> current project), execute (Project named: 'xxx') storeSegment.
>
>
> arrayOfRoots    The objects that head the tree we will trace.
> segment                 The WordArray of raw bits of all objects in the
> tree.
> outPointers             Oops of all objects outside the segment
> pointed to from inside.
> state                   (see below)
> segmentName     Its basic name.  Often the name of a Project.
> fileName                The local name of the file.  'Foo-23.seg'
> userRootCnt             number of roots submitted by caller.  Extras
> are added in preparation for saving.
>
> state that an ImageSegment may exist in...
>
> #activeCopy                     (has been copied, with the intent to
> become active)
> arrayOfRoots, segment, and outPointers have been created by
> copyFromRoots:.  The tree of objects has been encoded in the segment,
> but those objects are still present in the Squeak system.
>
> #active                         (segment is actively holding objects)
> The segment is now the only holder of tree of objects.  Each of the
> original roots has been transmuted into an ImageSegmentRootStub that
> refers back to this image segment.  The original objects in the
> segment will all be garbageCollected.
>
> #onFile
> The segment has been written out to a file and replaced by a file
> pointer.  Only ImageSegmentRootStubs and the array of outPointers
> remains in the image.  To get this far:
> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>                 writeToFile: 'myFile.seg'.
>
> #inactive
> The segment has been brought back into memory and turned back into
> objects.  rootsArray is set, but the segment is invalid.
>
> #onFileWithSymbols
> The segment has been written out to a file, along with the text of
> all the symbols in the outPointers array, and replaced by a file
> pointer.  This reduces the size of the outPointers array, and also
> allows the system to reclaim any symbols that are not referred to
> from elsewhere in the image.  The specific format used is that of a
> literal array as follows:
>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' # symbol5).
> In this case, the original outPointers array was 8 long, but the
> compacted table of outPointers retains only two entries.  These get
> inserted in place of the #'s in the array of symbols after it is read
> back in.  Symbols with embedded spaces or other strange characters
> are written as strings, and converted back to symbols when read back
> in.  The symbol # is never written out.
>         NOTE: All IdentitySets or dictionaries must be rehashed when
> being read back from this format.  The symbols are effectively
> internal.  (No, not if read back into same image.  If a different
> image, then use #imported.  -tk)
>
> #imported
> The segment is on an external file or just read in from one.  The
> segment and outPointers are meant to be read into a foreign image.
> In this form, the image segment can be read from a URL, and
> installed.  A copy of the original array of root objects is
> constructed, with former outPointers bound to existing objects in the
> host system.
>         (Any Class inside the segment MUST be in the arrayOfRoots.
> This is so its association can be inserted into Smalltalk.  The
> class's metaclass must be in roots also.  Methods that are in
> outPointers because blocks point at them, were found and added to the
> roots.
>         All IdentitySets and dictionaries are rehashed when being
> read back from exported segments.)
>
>
> To discover why only some of the objects in a project are being
> written out, try this (***Destructive Test***).  This breaks lots of
> backpointers in the target project, and puts up an array of
> suspicious objects, a list of the classes of the outPointers, and a
> debugger.
> "Close any transcripts in the target project"
> World currentHand objectToPaste ifNotNil: [
>         self inform: 'Hand is holding a Morph in its paste buffer:\'
> withCRs,
>                 World currentHand objectToPaste printString].
> PV := Project named: 'xxxx'.
> (IS := ImageSegment new) findRogueRootsImSeg:
>         (Array with: PV world presenter with: PV world).
> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
> "Quit and DO NOT save"
>
> When an export image segment is brought into an image, it is like an
> image starting up.  Certain startUp messages need to be run.  These
> are byte and word reversals for nonPointer data that comes from a
> machine of the opposite endianness.  #startUpProc passes over all
> objects in the segment, and:
>         The first time an instance of class X is encountered, (msg _
> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
> case, it means that instances of X do not need special work.  X is
> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
> store it in the dictionary, startUps (aClass -> aMessage).
>         When a later instance of X is encountered, if X is in
> noStartUpNeeded, do nothing.  If X is in startUps, send the message
> to the instance.  Typically this is a message like #swapShortObjects.
>         Every class that implements #startUp, should see if it needs
> a parallel implementation of #startUpFrom:.
>
> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> > I don't see image segments in Cuis... I don't even know if they still
> exist
> > in Squeak... Anyone is still using it?
> >
> > It would be cool to have it at least as a package. If I remember
> correctly
> > it was very simple, like two primitives to load and save, but I think it
> > depended on something like mark and sweep or some particular kind of
> > garbage collector and it might not work in new VMs.
> >
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151126/f896ab80/attachment-0004.html>

From hannes.hirzel at gmail.com  Thu Nov 26 09:16:29 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 16:16:29 +0100
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
Message-ID: <CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>

That's interesting,

see also http://wiki.squeak.org/squeak/2316 with a reference to an
article evaluation ImageSegments at the end.



On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> Cool, maybe it's possible to make it into a package, I'll take a look.
>
> I've never used it to store Projects, tho..  I used before to store things
> that must be loaded very fast on demand and can be forgotten once there are
> no more references to them.. like image fragments that compose a map of the
> world, and small sound fragments that are used to synthesize speech
> (diphones). Yesterday I just wanted to know how big are my objects, and I
> wanted to make some experiments to see how the bit-size of my objects grow
> as the problems I'm modeling grow by some other measure (degree of
> polynomials, size of matrices are the most basic) and to know how much
> memory are my algorithms actually using at every step... image segments are
> ideal for this, you can use them to know exactly how much memory would be
> freed if a reference to a given object were forgotten.
>
>
> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>
>> Squeak 5.0 still has ImageSegments (class comment below). Saving and
>> loading of  projects currently is blocked in Squeak because of an
>> unfinished name space (environments implementation).
>>
>> http://wiki.squeak.org/squeak/6218
>>
>> And there is Fuel
>> http://rmod.inria.fr/web/software/Fuel
>>
>> ----------
>>
>> ImageSegment
>>
>> I represent a segment of Squeak address space.  I am created from an
>> array of root objects.  After storing, my segment contains a binary
>> encoding of every object accessible from my roots but not otherwise
>> accessible from anywhere else in the system.  My segment contains
>> outward pointers that are indices into my table of outPointers.
>> On load my segment is converted back into objects and becommed
>> into an Array of the loaded objects, so they can be enumerated.
>>
>>         The main use of ImageSegments is to store Projects.  A dummy
>> version of SmartRefStream traverses the Project.  Everything it finds
>> is classified as either an object that is owned by the project (only
>> pointed to inside the project), or an object outside the project that
>> is pointed to from inside the project.  The objects that are
>> completely owned by the project are compressed into pure binary form
>> in an ImageSegment.  The outside objects are put in the 'outPointers'
>> array.  The entire ImageSegment (binary part plus outPointers) is
>> encoded in a SmartRefStream, and saved on the disk.  (aProject
>> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
>> writeForExportWithSources:inDirectory:changeSet:).
>>
>>         Note that every object inside the project is put into the
>> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
>> scan the project, in order to make intelligent decisions about what
>> belongs in the project.
>>         See Project's class comment for what messages are sent to
>> objects as they are unpacked in a new image.
>>
>> ---- Older Details ------
>>
>>         The primary kind of image segment is an Export Segment.  It
>> can be saved on a server and read into a completely different Squeak
>> image.
>> Old way to create one:
>> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
>> class))
>>                 writeForExport: 'myFile.extSeg'.
>> Old way to create one for a project:
>>         (Project named: 'Play With Me - 3') exportSegment.
>> To read it into another image:  Select 'myFile.extSeg' in a FileList,
>> Menu 'load as project'.  It will install its classes automatically.
>> If you need to see the roots array, it is temporarily stored in
>> (SmartRefStream scannedObject).
>>
>> Most of 'states' of an ImageSegment are not used to export a project,
>> and have been abandoned.
>>
>>         When a segment is written out onto a file, it goes in a
>> folder called <image name>_segs.  If your image is called
>> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
>> image whenever your move, copy, or rename it.
>>         Whenever a Class is in arrayOfRoots, its class (aClass class)
>> must also be in the arrayOfRoots.
>>         There are two kinds of image segments.  Normal image segments
>> are a piece of a specific Squeak image, and can only be read back
>> into that image.  The image holds the array of outPointers that are
>> necessary to turn the bits in the file into objects.
>>         To put out a normal segment that holds a Project (not the
>> current project), execute (Project named: 'xxx') storeSegment.
>>
>>
>> arrayOfRoots    The objects that head the tree we will trace.
>> segment                 The WordArray of raw bits of all objects in the
>> tree.
>> outPointers             Oops of all objects outside the segment
>> pointed to from inside.
>> state                   (see below)
>> segmentName     Its basic name.  Often the name of a Project.
>> fileName                The local name of the file.  'Foo-23.seg'
>> userRootCnt             number of roots submitted by caller.  Extras
>> are added in preparation for saving.
>>
>> state that an ImageSegment may exist in...
>>
>> #activeCopy                     (has been copied, with the intent to
>> become active)
>> arrayOfRoots, segment, and outPointers have been created by
>> copyFromRoots:.  The tree of objects has been encoded in the segment,
>> but those objects are still present in the Squeak system.
>>
>> #active                         (segment is actively holding objects)
>> The segment is now the only holder of tree of objects.  Each of the
>> original roots has been transmuted into an ImageSegmentRootStub that
>> refers back to this image segment.  The original objects in the
>> segment will all be garbageCollected.
>>
>> #onFile
>> The segment has been written out to a file and replaced by a file
>> pointer.  Only ImageSegmentRootStubs and the array of outPointers
>> remains in the image.  To get this far:
>> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>>                 writeToFile: 'myFile.seg'.
>>
>> #inactive
>> The segment has been brought back into memory and turned back into
>> objects.  rootsArray is set, but the segment is invalid.
>>
>> #onFileWithSymbols
>> The segment has been written out to a file, along with the text of
>> all the symbols in the outPointers array, and replaced by a file
>> pointer.  This reduces the size of the outPointers array, and also
>> allows the system to reclaim any symbols that are not referred to
>> from elsewhere in the image.  The specific format used is that of a
>> literal array as follows:
>>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
>> symbol5).
>> In this case, the original outPointers array was 8 long, but the
>> compacted table of outPointers retains only two entries.  These get
>> inserted in place of the #'s in the array of symbols after it is read
>> back in.  Symbols with embedded spaces or other strange characters
>> are written as strings, and converted back to symbols when read back
>> in.  The symbol # is never written out.
>>         NOTE: All IdentitySets or dictionaries must be rehashed when
>> being read back from this format.  The symbols are effectively
>> internal.  (No, not if read back into same image.  If a different
>> image, then use #imported.  -tk)
>>
>> #imported
>> The segment is on an external file or just read in from one.  The
>> segment and outPointers are meant to be read into a foreign image.
>> In this form, the image segment can be read from a URL, and
>> installed.  A copy of the original array of root objects is
>> constructed, with former outPointers bound to existing objects in the
>> host system.
>>         (Any Class inside the segment MUST be in the arrayOfRoots.
>> This is so its association can be inserted into Smalltalk.  The
>> class's metaclass must be in roots also.  Methods that are in
>> outPointers because blocks point at them, were found and added to the
>> roots.
>>         All IdentitySets and dictionaries are rehashed when being
>> read back from exported segments.)
>>
>>
>> To discover why only some of the objects in a project are being
>> written out, try this (***Destructive Test***).  This breaks lots of
>> backpointers in the target project, and puts up an array of
>> suspicious objects, a list of the classes of the outPointers, and a
>> debugger.
>> "Close any transcripts in the target project"
>> World currentHand objectToPaste ifNotNil: [
>>         self inform: 'Hand is holding a Morph in its paste buffer:\'
>> withCRs,
>>                 World currentHand objectToPaste printString].
>> PV := Project named: 'xxxx'.
>> (IS := ImageSegment new) findRogueRootsImSeg:
>>         (Array with: PV world presenter with: PV world).
>> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
>> "Quit and DO NOT save"
>>
>> When an export image segment is brought into an image, it is like an
>> image starting up.  Certain startUp messages need to be run.  These
>> are byte and word reversals for nonPointer data that comes from a
>> machine of the opposite endianness.  #startUpProc passes over all
>> objects in the segment, and:
>>         The first time an instance of class X is encountered, (msg _
>> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
>> case, it means that instances of X do not need special work.  X is
>> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
>> store it in the dictionary, startUps (aClass -> aMessage).
>>         When a later instance of X is encountered, if X is in
>> noStartUpNeeded, do nothing.  If X is in startUps, send the message
>> to the instance.  Typically this is a message like #swapShortObjects.
>>         Every class that implements #startUp, should see if it needs
>> a parallel implementation of #startUpFrom:.
>>
>> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>> > I don't see image segments in Cuis... I don't even know if they still
>> exist
>> > in Squeak... Anyone is still using it?
>> >
>> > It would be cool to have it at least as a package. If I remember
>> correctly
>> > it was very simple, like two primitives to load and save, but I think
>> > it
>> > depended on something like mark and sweep or some particular kind of
>> > garbage collector and it might not work in new VMs.
>> >
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>



From hannes.hirzel at gmail.com  Thu Nov 26 09:23:30 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 26 Nov 2015 16:23:30 +0100
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
	<CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>
Message-ID: <CAGQxfVh3QvPc1=uzOTGQA3GYX5gca2gpJJMezf_NZqbFf1mOnw@mail.gmail.com>

And this seems to cover what you want to do

How to use an ImageSegment to determine memory usage
http://wiki.squeak.org/squeak/1260



On 11/26/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> That's interesting,
>
> see also http://wiki.squeak.org/squeak/2316 with a reference to an
> article evaluation ImageSegments at the end.
>
>
>
> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>> Cool, maybe it's possible to make it into a package, I'll take a look.
>>
>> I've never used it to store Projects, tho..  I used before to store
>> things
>> that must be loaded very fast on demand and can be forgotten once there
>> are
>> no more references to them.. like image fragments that compose a map of
>> the
>> world, and small sound fragments that are used to synthesize speech
>> (diphones). Yesterday I just wanted to know how big are my objects, and I
>> wanted to make some experiments to see how the bit-size of my objects
>> grow
>> as the problems I'm modeling grow by some other measure (degree of
>> polynomials, size of matrices are the most basic) and to know how much
>> memory are my algorithms actually using at every step... image segments
>> are
>> ideal for this, you can use them to know exactly how much memory would be
>> freed if a reference to a given object were forgotten.
>>
>>
>> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com>
>> wrote:
>>
>>> Squeak 5.0 still has ImageSegments (class comment below). Saving and
>>> loading of  projects currently is blocked in Squeak because of an
>>> unfinished name space (environments implementation).
>>>
>>> http://wiki.squeak.org/squeak/6218
>>>
>>> And there is Fuel
>>> http://rmod.inria.fr/web/software/Fuel
>>>
>>> ----------
>>>
>>> ImageSegment
>>>
>>> I represent a segment of Squeak address space.  I am created from an
>>> array of root objects.  After storing, my segment contains a binary
>>> encoding of every object accessible from my roots but not otherwise
>>> accessible from anywhere else in the system.  My segment contains
>>> outward pointers that are indices into my table of outPointers.
>>> On load my segment is converted back into objects and becommed
>>> into an Array of the loaded objects, so they can be enumerated.
>>>
>>>         The main use of ImageSegments is to store Projects.  A dummy
>>> version of SmartRefStream traverses the Project.  Everything it finds
>>> is classified as either an object that is owned by the project (only
>>> pointed to inside the project), or an object outside the project that
>>> is pointed to from inside the project.  The objects that are
>>> completely owned by the project are compressed into pure binary form
>>> in an ImageSegment.  The outside objects are put in the 'outPointers'
>>> array.  The entire ImageSegment (binary part plus outPointers) is
>>> encoded in a SmartRefStream, and saved on the disk.  (aProject
>>> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
>>> writeForExportWithSources:inDirectory:changeSet:).
>>>
>>>         Note that every object inside the project is put into the
>>> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
>>> scan the project, in order to make intelligent decisions about what
>>> belongs in the project.
>>>         See Project's class comment for what messages are sent to
>>> objects as they are unpacked in a new image.
>>>
>>> ---- Older Details ------
>>>
>>>         The primary kind of image segment is an Export Segment.  It
>>> can be saved on a server and read into a completely different Squeak
>>> image.
>>> Old way to create one:
>>> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
>>> class))
>>>                 writeForExport: 'myFile.extSeg'.
>>> Old way to create one for a project:
>>>         (Project named: 'Play With Me - 3') exportSegment.
>>> To read it into another image:  Select 'myFile.extSeg' in a FileList,
>>> Menu 'load as project'.  It will install its classes automatically.
>>> If you need to see the roots array, it is temporarily stored in
>>> (SmartRefStream scannedObject).
>>>
>>> Most of 'states' of an ImageSegment are not used to export a project,
>>> and have been abandoned.
>>>
>>>         When a segment is written out onto a file, it goes in a
>>> folder called <image name>_segs.  If your image is called
>>> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
>>> image whenever your move, copy, or rename it.
>>>         Whenever a Class is in arrayOfRoots, its class (aClass class)
>>> must also be in the arrayOfRoots.
>>>         There are two kinds of image segments.  Normal image segments
>>> are a piece of a specific Squeak image, and can only be read back
>>> into that image.  The image holds the array of outPointers that are
>>> necessary to turn the bits in the file into objects.
>>>         To put out a normal segment that holds a Project (not the
>>> current project), execute (Project named: 'xxx') storeSegment.
>>>
>>>
>>> arrayOfRoots    The objects that head the tree we will trace.
>>> segment                 The WordArray of raw bits of all objects in the
>>> tree.
>>> outPointers             Oops of all objects outside the segment
>>> pointed to from inside.
>>> state                   (see below)
>>> segmentName     Its basic name.  Often the name of a Project.
>>> fileName                The local name of the file.  'Foo-23.seg'
>>> userRootCnt             number of roots submitted by caller.  Extras
>>> are added in preparation for saving.
>>>
>>> state that an ImageSegment may exist in...
>>>
>>> #activeCopy                     (has been copied, with the intent to
>>> become active)
>>> arrayOfRoots, segment, and outPointers have been created by
>>> copyFromRoots:.  The tree of objects has been encoded in the segment,
>>> but those objects are still present in the Squeak system.
>>>
>>> #active                         (segment is actively holding objects)
>>> The segment is now the only holder of tree of objects.  Each of the
>>> original roots has been transmuted into an ImageSegmentRootStub that
>>> refers back to this image segment.  The original objects in the
>>> segment will all be garbageCollected.
>>>
>>> #onFile
>>> The segment has been written out to a file and replaced by a file
>>> pointer.  Only ImageSegmentRootStubs and the array of outPointers
>>> remains in the image.  To get this far:
>>> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>>>                 writeToFile: 'myFile.seg'.
>>>
>>> #inactive
>>> The segment has been brought back into memory and turned back into
>>> objects.  rootsArray is set, but the segment is invalid.
>>>
>>> #onFileWithSymbols
>>> The segment has been written out to a file, along with the text of
>>> all the symbols in the outPointers array, and replaced by a file
>>> pointer.  This reduces the size of the outPointers array, and also
>>> allows the system to reclaim any symbols that are not referred to
>>> from elsewhere in the image.  The specific format used is that of a
>>> literal array as follows:
>>>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
>>> symbol5).
>>> In this case, the original outPointers array was 8 long, but the
>>> compacted table of outPointers retains only two entries.  These get
>>> inserted in place of the #'s in the array of symbols after it is read
>>> back in.  Symbols with embedded spaces or other strange characters
>>> are written as strings, and converted back to symbols when read back
>>> in.  The symbol # is never written out.
>>>         NOTE: All IdentitySets or dictionaries must be rehashed when
>>> being read back from this format.  The symbols are effectively
>>> internal.  (No, not if read back into same image.  If a different
>>> image, then use #imported.  -tk)
>>>
>>> #imported
>>> The segment is on an external file or just read in from one.  The
>>> segment and outPointers are meant to be read into a foreign image.
>>> In this form, the image segment can be read from a URL, and
>>> installed.  A copy of the original array of root objects is
>>> constructed, with former outPointers bound to existing objects in the
>>> host system.
>>>         (Any Class inside the segment MUST be in the arrayOfRoots.
>>> This is so its association can be inserted into Smalltalk.  The
>>> class's metaclass must be in roots also.  Methods that are in
>>> outPointers because blocks point at them, were found and added to the
>>> roots.
>>>         All IdentitySets and dictionaries are rehashed when being
>>> read back from exported segments.)
>>>
>>>
>>> To discover why only some of the objects in a project are being
>>> written out, try this (***Destructive Test***).  This breaks lots of
>>> backpointers in the target project, and puts up an array of
>>> suspicious objects, a list of the classes of the outPointers, and a
>>> debugger.
>>> "Close any transcripts in the target project"
>>> World currentHand objectToPaste ifNotNil: [
>>>         self inform: 'Hand is holding a Morph in its paste buffer:\'
>>> withCRs,
>>>                 World currentHand objectToPaste printString].
>>> PV := Project named: 'xxxx'.
>>> (IS := ImageSegment new) findRogueRootsImSeg:
>>>         (Array with: PV world presenter with: PV world).
>>> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
>>> "Quit and DO NOT save"
>>>
>>> When an export image segment is brought into an image, it is like an
>>> image starting up.  Certain startUp messages need to be run.  These
>>> are byte and word reversals for nonPointer data that comes from a
>>> machine of the opposite endianness.  #startUpProc passes over all
>>> objects in the segment, and:
>>>         The first time an instance of class X is encountered, (msg _
>>> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
>>> case, it means that instances of X do not need special work.  X is
>>> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
>>> store it in the dictionary, startUps (aClass -> aMessage).
>>>         When a later instance of X is encountered, if X is in
>>> noStartUpNeeded, do nothing.  If X is in startUps, send the message
>>> to the instance.  Typically this is a message like #swapShortObjects.
>>>         Every class that implements #startUp, should see if it needs
>>> a parallel implementation of #startUpFrom:.
>>>
>>> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
>>> > I don't see image segments in Cuis... I don't even know if they still
>>> exist
>>> > in Squeak... Anyone is still using it?
>>> >
>>> > It would be cool to have it at least as a package. If I remember
>>> correctly
>>> > it was very simple, like two primitives to load and save, but I think
>>> > it
>>> > depended on something like mark and sweep or some particular kind of
>>> > garbage collector and it might not work in new VMs.
>>> >
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>
>



From luchiano at gmail.com  Thu Nov 26 09:31:24 2015
From: luchiano at gmail.com (Luciano Notarfrancesco)
Date: Thu, 26 Nov 2015 15:31:24 +0000
Subject: [Cuis] image segments
In-Reply-To: <CAGQxfVh3QvPc1=uzOTGQA3GYX5gca2gpJJMezf_NZqbFf1mOnw@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
	<CAGQxfVjbfsNdrCRi27dhi2PJO_38Dp+9jmNejjp3jdiXW6evDA@mail.gmail.com>
	<CAGQxfVh3QvPc1=uzOTGQA3GYX5gca2gpJJMezf_NZqbFf1mOnw@mail.gmail.com>
Message-ID: <CAL5GDyrDJy377VS=eFRfAUkvLzVaUex9na_6HJMWM17EgxP2mQ@mail.gmail.com>

Oh, yes, that's exactly what I wanted, awesome! Thanks!

On Thu, Nov 26, 2015 at 3:23 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> And this seems to cover what you want to do
>
> How to use an ImageSegment to determine memory usage
> http://wiki.squeak.org/squeak/1260
>
>
>
> On 11/26/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > That's interesting,
> >
> > see also http://wiki.squeak.org/squeak/2316 with a reference to an
> > article evaluation ImageSegments at the end.
> >
> >
> >
> > On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> >> Cool, maybe it's possible to make it into a package, I'll take a look.
> >>
> >> I've never used it to store Projects, tho..  I used before to store
> >> things
> >> that must be loaded very fast on demand and can be forgotten once there
> >> are
> >> no more references to them.. like image fragments that compose a map of
> >> the
> >> world, and small sound fragments that are used to synthesize speech
> >> (diphones). Yesterday I just wanted to know how big are my objects, and
> I
> >> wanted to make some experiments to see how the bit-size of my objects
> >> grow
> >> as the problems I'm modeling grow by some other measure (degree of
> >> polynomials, size of matrices are the most basic) and to know how much
> >> memory are my algorithms actually using at every step... image segments
> >> are
> >> ideal for this, you can use them to know exactly how much memory would
> be
> >> freed if a reference to a given object were forgotten.
> >>
> >>
> >> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com>
> >> wrote:
> >>
> >>> Squeak 5.0 still has ImageSegments (class comment below). Saving and
> >>> loading of  projects currently is blocked in Squeak because of an
> >>> unfinished name space (environments implementation).
> >>>
> >>> http://wiki.squeak.org/squeak/6218
> >>>
> >>> And there is Fuel
> >>> http://rmod.inria.fr/web/software/Fuel
> >>>
> >>> ----------
> >>>
> >>> ImageSegment
> >>>
> >>> I represent a segment of Squeak address space.  I am created from an
> >>> array of root objects.  After storing, my segment contains a binary
> >>> encoding of every object accessible from my roots but not otherwise
> >>> accessible from anywhere else in the system.  My segment contains
> >>> outward pointers that are indices into my table of outPointers.
> >>> On load my segment is converted back into objects and becommed
> >>> into an Array of the loaded objects, so they can be enumerated.
> >>>
> >>>         The main use of ImageSegments is to store Projects.  A dummy
> >>> version of SmartRefStream traverses the Project.  Everything it finds
> >>> is classified as either an object that is owned by the project (only
> >>> pointed to inside the project), or an object outside the project that
> >>> is pointed to from inside the project.  The objects that are
> >>> completely owned by the project are compressed into pure binary form
> >>> in an ImageSegment.  The outside objects are put in the 'outPointers'
> >>> array.  The entire ImageSegment (binary part plus outPointers) is
> >>> encoded in a SmartRefStream, and saved on the disk.  (aProject
> >>> exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
> >>> writeForExportWithSources:inDirectory:changeSet:).
> >>>
> >>>         Note that every object inside the project is put into the
> >>> segment's arrayOfRoots.  This is because a dummy SmartRefStream to
> >>> scan the project, in order to make intelligent decisions about what
> >>> belongs in the project.
> >>>         See Project's class comment for what messages are sent to
> >>> objects as they are unpacked in a new image.
> >>>
> >>> ---- Older Details ------
> >>>
> >>>         The primary kind of image segment is an Export Segment.  It
> >>> can be saved on a server and read into a completely different Squeak
> >>> image.
> >>> Old way to create one:
> >>> (ImageSegment new copyFromRootsForExport: (Array with: Baz with: Baz
> >>> class))
> >>>                 writeForExport: 'myFile.extSeg'.
> >>> Old way to create one for a project:
> >>>         (Project named: 'Play With Me - 3') exportSegment.
> >>> To read it into another image:  Select 'myFile.extSeg' in a FileList,
> >>> Menu 'load as project'.  It will install its classes automatically.
> >>> If you need to see the roots array, it is temporarily stored in
> >>> (SmartRefStream scannedObject).
> >>>
> >>> Most of 'states' of an ImageSegment are not used to export a project,
> >>> and have been abandoned.
> >>>
> >>>         When a segment is written out onto a file, it goes in a
> >>> folder called <image name>_segs.  If your image is called
> >>> "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
> >>> image whenever your move, copy, or rename it.
> >>>         Whenever a Class is in arrayOfRoots, its class (aClass class)
> >>> must also be in the arrayOfRoots.
> >>>         There are two kinds of image segments.  Normal image segments
> >>> are a piece of a specific Squeak image, and can only be read back
> >>> into that image.  The image holds the array of outPointers that are
> >>> necessary to turn the bits in the file into objects.
> >>>         To put out a normal segment that holds a Project (not the
> >>> current project), execute (Project named: 'xxx') storeSegment.
> >>>
> >>>
> >>> arrayOfRoots    The objects that head the tree we will trace.
> >>> segment                 The WordArray of raw bits of all objects in the
> >>> tree.
> >>> outPointers             Oops of all objects outside the segment
> >>> pointed to from inside.
> >>> state                   (see below)
> >>> segmentName     Its basic name.  Often the name of a Project.
> >>> fileName                The local name of the file.  'Foo-23.seg'
> >>> userRootCnt             number of roots submitted by caller.  Extras
> >>> are added in preparation for saving.
> >>>
> >>> state that an ImageSegment may exist in...
> >>>
> >>> #activeCopy                     (has been copied, with the intent to
> >>> become active)
> >>> arrayOfRoots, segment, and outPointers have been created by
> >>> copyFromRoots:.  The tree of objects has been encoded in the segment,
> >>> but those objects are still present in the Squeak system.
> >>>
> >>> #active                         (segment is actively holding objects)
> >>> The segment is now the only holder of tree of objects.  Each of the
> >>> original roots has been transmuted into an ImageSegmentRootStub that
> >>> refers back to this image segment.  The original objects in the
> >>> segment will all be garbageCollected.
> >>>
> >>> #onFile
> >>> The segment has been written out to a file and replaced by a file
> >>> pointer.  Only ImageSegmentRootStubs and the array of outPointers
> >>> remains in the image.  To get this far:
> >>> (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
> >>>                 writeToFile: 'myFile.seg'.
> >>>
> >>> #inactive
> >>> The segment has been brought back into memory and turned back into
> >>> objects.  rootsArray is set, but the segment is invalid.
> >>>
> >>> #onFileWithSymbols
> >>> The segment has been written out to a file, along with the text of
> >>> all the symbols in the outPointers array, and replaced by a file
> >>> pointer.  This reduces the size of the outPointers array, and also
> >>> allows the system to reclaim any symbols that are not referred to
> >>> from elsewhere in the image.  The specific format used is that of a
> >>> literal array as follows:
> >>>         #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
> >>> symbol5).
> >>> In this case, the original outPointers array was 8 long, but the
> >>> compacted table of outPointers retains only two entries.  These get
> >>> inserted in place of the #'s in the array of symbols after it is read
> >>> back in.  Symbols with embedded spaces or other strange characters
> >>> are written as strings, and converted back to symbols when read back
> >>> in.  The symbol # is never written out.
> >>>         NOTE: All IdentitySets or dictionaries must be rehashed when
> >>> being read back from this format.  The symbols are effectively
> >>> internal.  (No, not if read back into same image.  If a different
> >>> image, then use #imported.  -tk)
> >>>
> >>> #imported
> >>> The segment is on an external file or just read in from one.  The
> >>> segment and outPointers are meant to be read into a foreign image.
> >>> In this form, the image segment can be read from a URL, and
> >>> installed.  A copy of the original array of root objects is
> >>> constructed, with former outPointers bound to existing objects in the
> >>> host system.
> >>>         (Any Class inside the segment MUST be in the arrayOfRoots.
> >>> This is so its association can be inserted into Smalltalk.  The
> >>> class's metaclass must be in roots also.  Methods that are in
> >>> outPointers because blocks point at them, were found and added to the
> >>> roots.
> >>>         All IdentitySets and dictionaries are rehashed when being
> >>> read back from exported segments.)
> >>>
> >>>
> >>> To discover why only some of the objects in a project are being
> >>> written out, try this (***Destructive Test***).  This breaks lots of
> >>> backpointers in the target project, and puts up an array of
> >>> suspicious objects, a list of the classes of the outPointers, and a
> >>> debugger.
> >>> "Close any transcripts in the target project"
> >>> World currentHand objectToPaste ifNotNil: [
> >>>         self inform: 'Hand is holding a Morph in its paste buffer:\'
> >>> withCRs,
> >>>                 World currentHand objectToPaste printString].
> >>> PV := Project named: 'xxxx'.
> >>> (IS := ImageSegment new) findRogueRootsImSeg:
> >>>         (Array with: PV world presenter with: PV world).
> >>> IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
> >>> "Quit and DO NOT save"
> >>>
> >>> When an export image segment is brought into an image, it is like an
> >>> image starting up.  Certain startUp messages need to be run.  These
> >>> are byte and word reversals for nonPointer data that comes from a
> >>> machine of the opposite endianness.  #startUpProc passes over all
> >>> objects in the segment, and:
> >>>         The first time an instance of class X is encountered, (msg _
> >>> X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
> >>> case, it means that instances of X do not need special work.  X is
> >>> included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
> >>> store it in the dictionary, startUps (aClass -> aMessage).
> >>>         When a later instance of X is encountered, if X is in
> >>> noStartUpNeeded, do nothing.  If X is in startUps, send the message
> >>> to the instance.  Typically this is a message like #swapShortObjects.
> >>>         Every class that implements #startUp, should see if it needs
> >>> a parallel implementation of #startUpFrom:.
> >>>
> >>> On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com> wrote:
> >>> > I don't see image segments in Cuis... I don't even know if they still
> >>> exist
> >>> > in Squeak... Anyone is still using it?
> >>> >
> >>> > It would be cool to have it at least as a package. If I remember
> >>> correctly
> >>> > it was very simple, like two primitives to load and save, but I think
> >>> > it
> >>> > depended on something like mark and sweep or some particular kind of
> >>> > garbage collector and it might not work in new VMs.
> >>> >
> >>>
> >>> _______________________________________________
> >>> Cuis mailing list
> >>> Cuis at jvuletich.org
> >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>>
> >>
> >
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151126/36cbae51/attachment-0004.html>

From Ken.Dickey at Whidbey.com  Thu Nov 26 10:43:56 2015
From: Ken.Dickey at Whidbey.com (KenD)
Date: Thu, 26 Nov 2015 08:43:56 -0800
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>
	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
Message-ID: <20151126084356.9c4d2d0cd3817291d42a099e@Whidbey.com>

On Thu, 26 Nov 2015 14:10:21 +0000
Luciano Notarfrancesco <luchiano at gmail.com> wrote:

> Cool, maybe it's possible to make it into a package, I'll take a look.

Note that image segments are stored in a binary format that is dependent on the VM.

In other words an image segment saved in 4.x (pre-Spur) will not be loadable in 5.x (Spur).

I have not looked, but one might do better to port Fuel.

$0.02,
-KenD



From edgardec2005 at gmail.com  Thu Nov 26 11:27:58 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Thu, 26 Nov 2015 14:27:58 -0300
Subject: [Cuis] image segments
In-Reply-To: <20151126084356.9c4d2d0cd3817291d42a099e@Whidbey.com>
Message-ID: <D27CC76E.172AA%edgardec2005@gmail.com>




On 11/26/15, 1:43 PM, "KenD" <Ken.Dickey at Whidbey.com> wrote:

> I have not looked, but one might do better to port Fuel.

+1 A good look of Fuel 





From euanmee at gmail.com  Thu Nov 26 19:46:59 2015
From: euanmee at gmail.com (EuanM)
Date: Fri, 27 Nov 2015 01:46:59 +0000
Subject: [Cuis] Cuis Logo
Message-ID: <CALsRT0neHMUA5WagyEDVuatfCm6=7Ky0KnMKTSxd7_CTHDqGXg@mail.gmail.com>

I'm preparing a slideshow on what's good and cool in the Smalltalk world(s) atm.

I want to include Cuis.

I'm not aware of any official or semi-official logo.

I'm not even sure of the derivation or meaning of "Cuis".

Could someone point me to a logo, if there is one?

Could someone tell me more about why the project is called "Cuis"?
(And if there is nothing atm, I'll produce a logo that ties in to
that)

Cheers,
    Euan



From edgardec2005 at gmail.com  Fri Nov 27 04:26:15 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Fri, 27 Nov 2015 07:26:15 -0300
Subject: [Cuis] Cuis Logo
In-Reply-To: <CALsRT0neHMUA5WagyEDVuatfCm6=7Ky0KnMKTSxd7_CTHDqGXg@mail.gmail.com>
Message-ID: <D27DB617.172C3%edgardec2005@gmail.com>




On 11/26/15, 10:46 PM, "EuanM" <euanmee at gmail.com> wrote:

> I'm preparing a slideshow on what's good and cool in the Smalltalk world(s)
> atm.
> 
> I want to include Cuis.
> 
> I'm not aware of any official or semi-official logo.
> 
> I'm not even sure of the derivation or meaning of "Cuis".
> 
> Could someone point me to a logo, if there is one?
> 
> Could someone tell me more about why the project is called "Cuis"?
> (And if there is nothing atm, I'll produce a logo that ties in to
> that)
> 
> Cheers,
>     Euan
https://en.wikipedia.org/wiki/Southern_mountain_cavy (Microcavia australis)
Cuis

So is a rodent living in Argentina.
Very common, you do not need to far of mayor cities to found it to side of
roads 

Maybe a styli shed photo ?

Edgar





From avalloud at smalltalk.comcastbiz.net  Fri Nov 27 09:21:45 2015
From: avalloud at smalltalk.comcastbiz.net (Andres Valloud)
Date: Fri, 27 Nov 2015 07:21:45 -0800
Subject: [Cuis] New updates
In-Reply-To: <CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>
References: <56530DC3.3040609@jvuletich.org>
	<CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>
Message-ID: <56587509.2020202@smalltalk.comcastbiz.net>

Hello,

The fixes to exceptions are about solving subtle misbehaviors with the 
messages #pass, #outer, and #resignalAs:.  Generally speaking, the main 
issue was that the correct handler block wouldn't be found.  Thus, for 
example, sending the message #pass would fail to find a default handler. 
  I found these types of issues while porting Assessments (more on 
Assessments below), because it uses #pass to track exceptions, and 
#resignalAs: to remap other exceptions into exceptions Assessments 
understands.  Correct nested execution of #pass required a stack of 
handler contexts, thus now exceptions keep an ordered collection of 
handler contexts rather than just the topmost handler.  Surely this is 
not the only way this can be done.

Assessments is a testing framework specifically designed with 
collaboration in mind.  I had been making SUnit extensions since 2001, 
and eventually I realized sharing such extensions and improvements with 
other SUnit users would be fundamentally obstructed.  SUnit's design is 
such that one has to change the framework itself in order to extend its 
behavior.  Thus, what I change in my image does not necessarily have to 
work in someone else's image, and vice versa.  As a result, most SUnit 
users end up implementing extensions such as file logging or more 
extensive result reporting, and those extensions are incompatible with 
each other.

Instead, Assessments is built around the principle that the testing 
framework's behavior and extensibility should rely on object composition 
rather than subclassing.  In addition, a few critical objects are now 
reified explicitly.  Chief among them is the Assessment (the "test 
suite"), with its evaluation context (no parallel).  The key is that the 
evaluation context of an assessment can change how tests are executed, 
how results are collected, and so on.  Since this is done by object 
composition, it's trivial to e.g. set up an assessment to report results 
to multiple files and to the GUI without changing Assessments itself. 
As a result, extensions can be shared without the threat of immediate 
incompatibility.

But what about pre-existing SUnit tests?  Well surely a new testing 
framework built around collaboration wouldn't immediately obsolete the 
enormous body of SUnit tests out there, or force a migration because NIH 
or something like that.  And that's exactly what Assessments 
accomplishes.  Since there is an evaluation context object, an 
assessment ("test suite") can specify which execution policy goes for 
which check ("test").  Assessments uses this flexibility to execute 
SUnit tests in situ, as if SUnit itself was running them.  Unlike other 
solutions deployed to solve this problem, Assessments does not require 
modifications to existing code.  Loading Assessments is effectively 
invisible to existing SUnit code.

The end result is that the Assessments checklist evaluator (the "test 
runner") displays both SUnit tests and native Assessments tests, and one 
assessment object can execute both types together.

In addiiton, Assessments provides a clean, native implementation of 
SUnit Validation (also known as "Extreme Validation"), as well as SUnit 
Benchmarks.  Both of these are implemented in terms of Assessments 
checklists.  Briefly, validation involves using tests to verify e.g. 
business objects at run time.  A typical application of validation would 
be data entry verification.  The Benchmarks is another application of 
tests, where each test measures the time needed to execute some code. 
In addition, Benchmarks can enforce that some code runs within a certain 
amount of time.  An interesting detail is that the required time is 
specified in "message send" units, rather than time.  Thus, the 
benchmarks do not become obsolete or inappropriate depending on the 
speed of the machine where the measurements are taken.

For more information, the Assessments package contains more detailed 
comments as well as links to additional detail.  I originally presented 
Assessments at ESUG 2008, the video of the talk is online here (and 
other places):

https://vimeo.com/1945494

There are also some notes on validation here:

http://csl.ensm-douai.fr/Esug2007Media/uploads/1/Extreme.pdf

There is also a paper by Leandro Caniglia titled "Extreme Validation", 
which unfortunately I couldn't immediately find in Google.  But I image 
I can get a copy and put it online somewhere.

Andres.

On 11/23/15 7:35 , Luciano Notarfrancesco wrote:
> Hi all,
> About my recent changes, some of them are 1) extensions to Theme to be
> able to customize some more aspects of how the windows and widgets look,
> or 2) fixes for small bugs that I found on the way, like misalignments
> of a few pixels between parts of a widget or a window. The motivation
> behind this was just to be able to implement a very minimalist look
> (borders of just 1 pixel, no decorations, no icons, no anything that I
> dont need and takes up screen real estate), and a sort of tiling dynamic
> window manager very much like http://dwm.suckless.org
> (https://github.com/len/Cuis-Smalltalk-DWM).
>
> In order to implement this "window manager" as an external package with
> minimal changes to the core system, I decided to: 1) make the current
> Theme receive messages #windowOpen: #windowClosed: every time
> SystemWindows are open or closed, in order to give it a chance to
> implement window-management behaviour or delegate it to a proper window
> manager; 2) move the window-management keyboard shortcuts (like alt-w to
> close) to Theme, so it is all in one place, easy to change, and easy to
> make a Theme that delegates keyboard events to a proper window manager.
>
> Again I did it like this in order to minimize changes to the core
> system. At the moment window management is in part implemented in
> SystemWindow, and also in HandMorph and Morph. I had to make some small
> modifications in order to get the desired behavior when using DWM, and
> keep the original behavior in the base system. Maybe in the long run we
> would want to have a WindowManager class that do this, handle keyboard
> events for the window-management shortcuts and receives #windowOpen: and
> #windowClosed:, etc. But I would like to think better about this before
> adding new concepts and complexity to the core.
>
> Cheers,
> Luciano
>
>
> On Mon, Nov 23, 2015 at 12:59 PM, Juan Vuletich <juan at jvuletich.org
> <mailto:juan at jvuletich.org>> wrote:
>
>     Hi all,
>
>     I recently included some new updates:
>
>     - Fixes to Exceptions by Andr?s Valloud and Martin McClure.
>     - Assessments framework for testing and validation by Andr?s Valloud.
>     - Many fixes and enhancements to Layouts, Window drawing, keyboard
>     shortcuts, etc. by Luciano Notarfrancesco
>
>     Thank you very much Folks! Andr?s, Luciano, please comment a bit on
>     what you did, especially subtle but important behavior such as
>     Exceptions and new stuff like Assessments, and the new Theme and
>     Window Manager.
>
>     Cheers,
>     Juan Vuletich
>
>     _______________________________________________
>     Cuis mailing list
>     Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Fri Nov 27 13:50:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 27 Nov 2015 14:50:07 -0500
Subject: [Cuis] Class Comment Browser
Message-ID: <5658B3EF.24941.1584D0D@dnorton.mindspring.com>

Hi Juan,

Please include the latest when you build next time:

	https://github.com/dhnorton/Cuis-Smalltalk-comments

Changes:
	less redundancy in the list
	pick up trailing acronyms
	revised class comments

Thanks,
 - Dan



From euanmee at gmail.com  Fri Nov 27 14:19:05 2015
From: euanmee at gmail.com (EuanM)
Date: Fri, 27 Nov 2015 20:19:05 +0000
Subject: [Cuis] Cuis Logo
Message-ID: <CALsRT0k8oL4K0mqWuBTKi0+3cBqZ=cJZcQFZm4d1KSYkDhxj_A@mail.gmail.com>

My 0.0.3 release of a proposed interim Cuis logo is now online, on the
home page at:
http://smalltalk.uk.to/

My plan is to add it to the constellation of Smalltalk logos on the
slideshow I'm writing, until Juan and the community have a better
option.

Cheers,
    Euan


> On Fri, 27 Nov 2015 07:26:15 -0300, "Edgar J. De Cleene" wrote:

> On 11/26/15, 10:46 PM, "EuanM" <euanmee at gmail.com> wrote:
>
>> I'm preparing a slideshow on what's good and cool in the Smalltalk world(s)
>> atm.
>>
>> I want to include Cuis.
>>
>> I'm not aware of any official or semi-official logo.
>>
>> I'm not even sure of the derivation or meaning of "Cuis".
>>
>> Could someone point me to a logo, if there is one?
>>
>> Could someone tell me more about why the project is called "Cuis"?
>> (And if there is nothing atm, I'll produce a logo that ties in to
>> that)
>>
>> Cheers,
>>     Euan
> https://en.wikipedia.org/wiki/Southern_mountain_cavy (Microcavia australis)
> Cuis
>
> So is a rodent living in Argentina.
> Very common, you do not need to far of mayor cities to found it to side of
> roads
>
> Maybe a styli shed photo ?
>
> Edgar



From juan at jvuletich.org  Sat Nov 28 14:20:17 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:20:17 -0300
Subject: [Cuis] image segments
In-Reply-To: <CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
References: <CAL5GDyrVqDVS-+-82byXNmw5qJ-k9K+_tfHw8NmU=t0e+1pngw@mail.gmail.com>	<CAGQxfVi50Lh+jH39YHdA7LbaYTjyYKGqDHDGvkiHC5TBJsUZuw@mail.gmail.com>
	<CAL5GDyq-nx0mbzrO=Lr_cBjyzrN0igk7K0SCHkPxe8ug47mumg@mail.gmail.com>
Message-ID: <565A0C81.9080702@jvuletich.org>

At some point in the development of Cuis I removed both Projects and 
ImageSegments. It shouldn't be hard to add them back, as an optional 
package.

WRT Fuel, it would be a great addition. If (as I believe) it already 
works on Squeak, besides Pharo, then it shouldn't be too hard to port to 
Cuis.

Cheers,
Juan Vuletich

On 26/11/2015 11:10 a.m., Luciano Notarfrancesco wrote:
> Cool, maybe it's possible to make it into a package, I'll take a look.
>
> I've never used it to store Projects, tho..  I used before to store 
> things that must be loaded very fast on demand and can be forgotten 
> once there are no more references to them.. like image fragments that 
> compose a map of the world, and small sound fragments that are used to 
> synthesize speech (diphones). Yesterday I just wanted to know how big 
> are my objects, and I wanted to make some experiments to see how the 
> bit-size of my objects grow as the problems I'm modeling grow by some 
> other measure (degree of polynomials, size of matrices are the most 
> basic) and to know how much memory are my algorithms actually using at 
> every step... image segments are ideal for this, you can use them to 
> know exactly how much memory would be freed if a reference to a given 
> object were forgotten.
>
>
> On Thu, Nov 26, 2015 at 7:36 AM, H. Hirzel <hannes.hirzel at gmail.com 
> <mailto:hannes.hirzel at gmail.com>> wrote:
>
>     Squeak 5.0 still has ImageSegments (class comment below). Saving and
>     loading of  projects currently is blocked in Squeak because of an
>     unfinished name space (environments implementation).
>
>     http://wiki.squeak.org/squeak/6218
>
>     And there is Fuel
>     http://rmod.inria.fr/web/software/Fuel
>
>     ----------
>
>     ImageSegment
>
>     I represent a segment of Squeak address space.  I am created from an
>     array of root objects.  After storing, my segment contains a binary
>     encoding of every object accessible from my roots but not otherwise
>     accessible from anywhere else in the system.  My segment contains
>     outward pointers that are indices into my table of outPointers.
>     On load my segment is converted back into objects and becommed
>     into an Array of the loaded objects, so they can be enumerated.
>
>             The main use of ImageSegments is to store Projects.  A dummy
>     version of SmartRefStream traverses the Project.  Everything it finds
>     is classified as either an object that is owned by the project (only
>     pointed to inside the project), or an object outside the project that
>     is pointed to from inside the project.  The objects that are
>     completely owned by the project are compressed into pure binary form
>     in an ImageSegment.  The outside objects are put in the 'outPointers'
>     array.  The entire ImageSegment (binary part plus outPointers) is
>     encoded in a SmartRefStream, and saved on the disk.  (aProject
>     exportSegmentWithChangeSet:fileName:directory:) calls (anImageSegment
>     writeForExportWithSources:inDirectory:changeSet:).
>
>             Note that every object inside the project is put into the
>     segment's arrayOfRoots.  This is because a dummy SmartRefStream to
>     scan the project, in order to make intelligent decisions about what
>     belongs in the project.
>             See Project's class comment for what messages are sent to
>     objects as they are unpacked in a new image.
>
>     ---- Older Details ------
>
>             The primary kind of image segment is an Export Segment.  It
>     can be saved on a server and read into a completely different Squeak
>     image.
>     Old way to create one:
>     (ImageSegment new copyFromRootsForExport: (Array with: Baz with:
>     Baz class))
>                     writeForExport: 'myFile.extSeg'.
>     Old way to create one for a project:
>             (Project named: 'Play With Me - 3') exportSegment.
>     To read it into another image:  Select 'myFile.extSeg' in a FileList,
>     Menu 'load as project'.  It will install its classes automatically.
>     If you need to see the roots array, it is temporarily stored in
>     (SmartRefStream scannedObject).
>
>     Most of 'states' of an ImageSegment are not used to export a project,
>     and have been abandoned.
>
>             When a segment is written out onto a file, it goes in a
>     folder called <image name>_segs.  If your image is called
>     "Squeak2.6.image", the folder "Squeak2.6_segs" must accompany the
>     image whenever your move, copy, or rename it.
>             Whenever a Class is in arrayOfRoots, its class (aClass class)
>     must also be in the arrayOfRoots.
>             There are two kinds of image segments.  Normal image segments
>     are a piece of a specific Squeak image, and can only be read back
>     into that image.  The image holds the array of outPointers that are
>     necessary to turn the bits in the file into objects.
>             To put out a normal segment that holds a Project (not the
>     current project), execute (Project named: 'xxx') storeSegment.
>
>
>     arrayOfRoots    The objects that head the tree we will trace.
>     segment                 The WordArray of raw bits of all objects
>     in the tree.
>     outPointers             Oops of all objects outside the segment
>     pointed to from inside.
>     state                   (see below)
>     segmentName     Its basic name.  Often the name of a Project.
>     fileName                The local name of the file.  'Foo-23.seg'
>     userRootCnt             number of roots submitted by caller.  Extras
>     are added in preparation for saving.
>
>     state that an ImageSegment may exist in...
>
>     #activeCopy                     (has been copied, with the intent to
>     become active)
>     arrayOfRoots, segment, and outPointers have been created by
>     copyFromRoots:.  The tree of objects has been encoded in the segment,
>     but those objects are still present in the Squeak system.
>
>     #active                         (segment is actively holding objects)
>     The segment is now the only holder of tree of objects.  Each of the
>     original roots has been transmuted into an ImageSegmentRootStub that
>     refers back to this image segment.  The original objects in the
>     segment will all be garbageCollected.
>
>     #onFile
>     The segment has been written out to a file and replaced by a file
>     pointer.  Only ImageSegmentRootStubs and the array of outPointers
>     remains in the image.  To get this far:
>     (ImageSegment new copyFromRoots: (Array with: Baz with: Baz class))
>                     writeToFile: 'myFile.seg'.
>
>     #inactive
>     The segment has been brought back into memory and turned back into
>     objects.  rootsArray is set, but the segment is invalid.
>
>     #onFileWithSymbols
>     The segment has been written out to a file, along with the text of
>     all the symbols in the outPointers array, and replaced by a file
>     pointer.  This reduces the size of the outPointers array, and also
>     allows the system to reclaim any symbols that are not referred to
>     from elsewhere in the image.  The specific format used is that of a
>     literal array as follows:
>             #(symbol1 symbol2 # symbol3 symbol4 'symbolWithSpaces' #
>     symbol5).
>     In this case, the original outPointers array was 8 long, but the
>     compacted table of outPointers retains only two entries.  These get
>     inserted in place of the #'s in the array of symbols after it is read
>     back in.  Symbols with embedded spaces or other strange characters
>     are written as strings, and converted back to symbols when read back
>     in.  The symbol # is never written out.
>             NOTE: All IdentitySets or dictionaries must be rehashed when
>     being read back from this format.  The symbols are effectively
>     internal.  (No, not if read back into same image.  If a different
>     image, then use #imported.  -tk)
>
>     #imported
>     The segment is on an external file or just read in from one.  The
>     segment and outPointers are meant to be read into a foreign image.
>     In this form, the image segment can be read from a URL, and
>     installed.  A copy of the original array of root objects is
>     constructed, with former outPointers bound to existing objects in the
>     host system.
>             (Any Class inside the segment MUST be in the arrayOfRoots.
>     This is so its association can be inserted into Smalltalk.  The
>     class's metaclass must be in roots also.  Methods that are in
>     outPointers because blocks point at them, were found and added to the
>     roots.
>             All IdentitySets and dictionaries are rehashed when being
>     read back from exported segments.)
>
>
>     To discover why only some of the objects in a project are being
>     written out, try this (***Destructive Test***).  This breaks lots of
>     backpointers in the target project, and puts up an array of
>     suspicious objects, a list of the classes of the outPointers, and a
>     debugger.
>     "Close any transcripts in the target project"
>     World currentHand objectToPaste ifNotNil: [
>             self inform: 'Hand is holding a Morph in its paste
>     buffer:\' withCRs,
>                     World currentHand objectToPaste printString].
>     PV := Project named: 'xxxx'.
>     (IS := ImageSegment new) findRogueRootsImSeg:
>             (Array with: PV world presenter with: PV world).
>     IS findOwnersOutPtrs.   "Optionally: write a file with owner chains"
>     "Quit and DO NOT save"
>
>     When an export image segment is brought into an image, it is like an
>     image starting up.  Certain startUp messages need to be run.  These
>     are byte and word reversals for nonPointer data that comes from a
>     machine of the opposite endianness.  #startUpProc passes over all
>     objects in the segment, and:
>             The first time an instance of class X is encountered, (msg _
>     X startUpFrom: anImageSegment) is sent.  If msg is nil, the usual
>     case, it means that instances of X do not need special work.  X is
>     included in the IdentitySet, noStartUpNeeded.  If msg is not nil,
>     store it in the dictionary, startUps (aClass -> aMessage).
>             When a later instance of X is encountered, if X is in
>     noStartUpNeeded, do nothing.  If X is in startUps, send the message
>     to the instance.  Typically this is a message like #swapShortObjects.
>             Every class that implements #startUp, should see if it needs
>     a parallel implementation of #startUpFrom:.
>
>     On 11/26/15, Luciano Notarfrancesco <luchiano at gmail.com
>     <mailto:luchiano at gmail.com>> wrote:
>     > I don't see image segments in Cuis... I don't even know if they
>     still exist
>     > in Squeak... Anyone is still using it?
>     >
>     > It would be cool to have it at least as a package. If I remember
>     correctly
>     > it was very simple, like two primitives to load and save, but I
>     think it
>     > depended on something like mark and sweep or some particular kind of
>     > garbage collector and it might not work in new VMs.
>     >
>
>     _______________________________________________
>     Cuis mailing list
>     Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151128/5e6e6890/attachment-0004.html>

From juan at jvuletich.org  Sat Nov 28 14:25:56 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:25:56 -0300
Subject: [Cuis] Cuis Logo
In-Reply-To: <CALsRT0k8oL4K0mqWuBTKi0+3cBqZ=cJZcQFZm4d1KSYkDhxj_A@mail.gmail.com>
References: <CALsRT0k8oL4K0mqWuBTKi0+3cBqZ=cJZcQFZm4d1KSYkDhxj_A@mail.gmail.com>
Message-ID: <565A0DD4.4000006@jvuletich.org>

Hi EuanM,

On 27/11/2015 05:19 p.m., EuanM wrote:
> My 0.0.3 release of a proposed interim Cuis logo is now online, on the
> home page at:
> http://smalltalk.uk.to/

When I first looked at it, I thought "what's this bear like face looking 
to the upper right? I'll need to find a polite way to say 'no'!".
Two seconds later mi brain did the click and saw the little mouse 
looking towards the left.
The same happened to my 12 y.o and my wife (without me saying a word).

I love it!

Thanks,
Juan Vuletich

> My plan is to add it to the constellation of Smalltalk logos on the
> slideshow I'm writing, until Juan and the community have a better
> option.
>
> Cheers,
>      Euan
>
>
>> On Fri, 27 Nov 2015 07:26:15 -0300, "Edgar J. De Cleene" wrote:
>> On 11/26/15, 10:46 PM, "EuanM"<euanmee at gmail.com>  wrote:
>>
>>> I'm preparing a slideshow on what's good and cool in the Smalltalk world(s)
>>> atm.
>>>
>>> I want to include Cuis.
>>>
>>> I'm not aware of any official or semi-official logo.
>>>
>>> I'm not even sure of the derivation or meaning of "Cuis".
>>>
>>> Could someone point me to a logo, if there is one?
>>>
>>> Could someone tell me more about why the project is called "Cuis"?
>>> (And if there is nothing atm, I'll produce a logo that ties in to
>>> that)
>>>
>>> Cheers,
>>>      Euan
>> https://en.wikipedia.org/wiki/Southern_mountain_cavy (Microcavia australis)
>> Cuis
>>
>> So is a rodent living in Argentina.
>> Very common, you do not need to far of mayor cities to found it to side of
>> roads
>>
>> Maybe a styli shed photo ?
>>
>> Edgar
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Sat Nov 28 14:26:54 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:26:54 -0300
Subject: [Cuis] Class Comment Browser
In-Reply-To: <5658B3EF.24941.1584D0D@dnorton.mindspring.com>
References: <5658B3EF.24941.1584D0D@dnorton.mindspring.com>
Message-ID: <565A0E0E.7070405@jvuletich.org>

Will do.

Thanks,
Juan Vuletich

On 27/11/2015 04:50 p.m., Dan Norton wrote:
> Hi Juan,
>
> Please include the latest when you build next time:
>
> 	https://github.com/dhnorton/Cuis-Smalltalk-comments
>
> Changes:
> 	less redundancy in the list
> 	pick up trailing acronyms
> 	revised class comments
>
> Thanks,
>   - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Sat Nov 28 14:28:18 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 28 Nov 2015 17:28:18 -0300
Subject: [Cuis] New updates
In-Reply-To: <56587509.2020202@smalltalk.comcastbiz.net>
References: <56530DC3.3040609@jvuletich.org>	<CAL5GDypb3ViiHvCpWV-V-A6w5r1+R192HjWfaPX4pn6c1KLDAA@mail.gmail.com>
	<56587509.2020202@smalltalk.comcastbiz.net>
Message-ID: <565A0E62.8080707@jvuletich.org>

Thanks, Folks!!!

Cheers,
Juan Vuletich

On 27/11/2015 12:21 p.m., Andres Valloud wrote:
> Hello,
>
> The fixes to exceptions are about solving subtle misbehaviors with the 
> messages #pass, #outer, and #resignalAs:.  Generally speaking, the 
> main issue was that the correct handler block wouldn't be found.  
> Thus, for example, sending the message #pass would fail to find a 
> default handler.  I found these types of issues while porting 
> Assessments (more on Assessments below), because it uses #pass to 
> track exceptions, and #resignalAs: to remap other exceptions into 
> exceptions Assessments understands.  Correct nested execution of #pass 
> required a stack of handler contexts, thus now exceptions keep an 
> ordered collection of handler contexts rather than just the topmost 
> handler.  Surely this is not the only way this can be done.
>
> Assessments is a testing framework specifically designed with 
> collaboration in mind.  I had been making SUnit extensions since 2001, 
> and eventually I realized sharing such extensions and improvements 
> with other SUnit users would be fundamentally obstructed.  SUnit's 
> design is such that one has to change the framework itself in order to 
> extend its behavior.  Thus, what I change in my image does not 
> necessarily have to work in someone else's image, and vice versa.  As 
> a result, most SUnit users end up implementing extensions such as file 
> logging or more extensive result reporting, and those extensions are 
> incompatible with each other.
>
> Instead, Assessments is built around the principle that the testing 
> framework's behavior and extensibility should rely on object 
> composition rather than subclassing.  In addition, a few critical 
> objects are now reified explicitly.  Chief among them is the 
> Assessment (the "test suite"), with its evaluation context (no 
> parallel).  The key is that the evaluation context of an assessment 
> can change how tests are executed, how results are collected, and so 
> on.  Since this is done by object composition, it's trivial to e.g. 
> set up an assessment to report results to multiple files and to the 
> GUI without changing Assessments itself. As a result, extensions can 
> be shared without the threat of immediate incompatibility.
>
> But what about pre-existing SUnit tests?  Well surely a new testing 
> framework built around collaboration wouldn't immediately obsolete the 
> enormous body of SUnit tests out there, or force a migration because 
> NIH or something like that.  And that's exactly what Assessments 
> accomplishes.  Since there is an evaluation context object, an 
> assessment ("test suite") can specify which execution policy goes for 
> which check ("test").  Assessments uses this flexibility to execute 
> SUnit tests in situ, as if SUnit itself was running them.  Unlike 
> other solutions deployed to solve this problem, Assessments does not 
> require modifications to existing code.  Loading Assessments is 
> effectively invisible to existing SUnit code.
>
> The end result is that the Assessments checklist evaluator (the "test 
> runner") displays both SUnit tests and native Assessments tests, and 
> one assessment object can execute both types together.
>
> In addiiton, Assessments provides a clean, native implementation of 
> SUnit Validation (also known as "Extreme Validation"), as well as 
> SUnit Benchmarks.  Both of these are implemented in terms of 
> Assessments checklists.  Briefly, validation involves using tests to 
> verify e.g. business objects at run time.  A typical application of 
> validation would be data entry verification.  The Benchmarks is 
> another application of tests, where each test measures the time needed 
> to execute some code. In addition, Benchmarks can enforce that some 
> code runs within a certain amount of time.  An interesting detail is 
> that the required time is specified in "message send" units, rather 
> than time.  Thus, the benchmarks do not become obsolete or 
> inappropriate depending on the speed of the machine where the 
> measurements are taken.
>
> For more information, the Assessments package contains more detailed 
> comments as well as links to additional detail.  I originally 
> presented Assessments at ESUG 2008, the video of the talk is online 
> here (and other places):
>
> https://vimeo.com/1945494
>
> There are also some notes on validation here:
>
> http://csl.ensm-douai.fr/Esug2007Media/uploads/1/Extreme.pdf
>
> There is also a paper by Leandro Caniglia titled "Extreme Validation", 
> which unfortunately I couldn't immediately find in Google.  But I 
> image I can get a copy and put it online somewhere.
>
> Andres.
>
> On 11/23/15 7:35 , Luciano Notarfrancesco wrote:
>> Hi all,
>> About my recent changes, some of them are 1) extensions to Theme to be
>> able to customize some more aspects of how the windows and widgets look,
>> or 2) fixes for small bugs that I found on the way, like misalignments
>> of a few pixels between parts of a widget or a window. The motivation
>> behind this was just to be able to implement a very minimalist look
>> (borders of just 1 pixel, no decorations, no icons, no anything that I
>> dont need and takes up screen real estate), and a sort of tiling dynamic
>> window manager very much like http://dwm.suckless.org
>> (https://github.com/len/Cuis-Smalltalk-DWM).
>>
>> In order to implement this "window manager" as an external package with
>> minimal changes to the core system, I decided to: 1) make the current
>> Theme receive messages #windowOpen: #windowClosed: every time
>> SystemWindows are open or closed, in order to give it a chance to
>> implement window-management behaviour or delegate it to a proper window
>> manager; 2) move the window-management keyboard shortcuts (like alt-w to
>> close) to Theme, so it is all in one place, easy to change, and easy to
>> make a Theme that delegates keyboard events to a proper window manager.
>>
>> Again I did it like this in order to minimize changes to the core
>> system. At the moment window management is in part implemented in
>> SystemWindow, and also in HandMorph and Morph. I had to make some small
>> modifications in order to get the desired behavior when using DWM, and
>> keep the original behavior in the base system. Maybe in the long run we
>> would want to have a WindowManager class that do this, handle keyboard
>> events for the window-management shortcuts and receives #windowOpen: and
>> #windowClosed:, etc. But I would like to think better about this before
>> adding new concepts and complexity to the core.
>>
>> Cheers,
>> Luciano
>>
>>
>> On Mon, Nov 23, 2015 at 12:59 PM, Juan Vuletich <juan at jvuletich.org
>> <mailto:juan at jvuletich.org>> wrote:
>>
>>     Hi all,
>>
>>     I recently included some new updates:
>>
>>     - Fixes to Exceptions by Andr?s Valloud and Martin McClure.
>>     - Assessments framework for testing and validation by Andr?s 
>> Valloud.
>>     - Many fixes and enhancements to Layouts, Window drawing, keyboard
>>     shortcuts, etc. by Luciano Notarfrancesco
>>
>>     Thank you very much Folks! Andr?s, Luciano, please comment a bit on
>>     what you did, especially subtle but important behavior such as
>>     Exceptions and new stuff like Assessments, and the new Theme and
>>     Window Manager.
>>
>>     Cheers,
>>     Juan Vuletich
>>
>>     _______________________________________________
>>     Cuis mailing list
>>     Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>