From nicolas.cellier.aka.nice at gmail.com  Wed Jul  1 07:52:56 2015
From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier)
Date: Wed, 1 Jul 2015 14:52:56 +0200
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
References: <1435576183.2309.69.camel@gmail.com>
	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>
	<55917102.4030901@jvuletich.org>
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
Message-ID: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>

2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:

> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>
> > Hi folks,
> >
> > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> > > On Mon, 29 Jun 2015 07:09:43 -0400
> > > "Phil (list)"<pbpublist at gmail.com>  wrote:
> > >> ..  Is it
> > >> worth having a class for this vs. raising the more general
> > Notification
> > >> and then checking for a #ReparseAfterSourceEditing signal, and if
> > it
> > >> isn't, re-raise Notification in its sole handler?
> > >> ..
> > >> This is a specific example of the more general question of where
> > to draw
> > >> the line on having single, or very limited, use classes and
> > methods vs.
> > >> adding a tiny bit of complexity in one or two methods to simplify
> > the
> > >> overall image or package in question.  Thoughts?
> > > I would say the overriding goal is clarity.
> > >
> > > It is important work to refactor code to have the same behavior
> > but be easier to understand.
> > >
> > > A Smalltalk style goal is to have small methods which do things
> > clearly.  This tends to lead to lots of small methods.
> > >
> > > Specializing classes for one or just a few methods may seem
> > wasteful, but computer resources are cheap.
> > >
> > > Look at class #PartsBinMorph.  Would you say the having the
> > additional class is wasteful?
> > >
> > > It is a tough balance.  Aesthetics and restraint require judgement
> > and we don't always get it right.  It takes time.
> > >
> > > I only have so many life hours left.  I feel my time is valuable.
> > I prefer to understand.
> > >
> > > Thank you so much for taking the time to make Cuis more
> > comprehensible.
> > >
> > > $0.02
> > > -KenD
> >
> > I fully support Ken. I don't think that a general answer is correct
> > in
> > all cases here. It is a matter of making code easy to understand.
> > But
> > also making it consistent and pretty.
> >
> > In general, I don't like making general classes know much about
> > details
> > of specific use cases. But there might be exceptions.
> >
> > If you feel like experimenting with this kind of stuff, send your
> > suggestions to the mail list so we can discuss.
> >
> > In the particular case of ReparseAfterSourceEditing, I agree that a
> > class that does nothing is a bit strange. But, what is the
> > alternative?
> > How would the sole exception handler know what to do with a general
> > Notification? I think the handler looks quite reasonable right now.
> > And
> > the pollution of the global space might be tolerable if the
> > alternative
> > is more convoluted code...
> >
>
> Making code easy to understand is very valuable. Simple things should be
> simple to
> accomplish, but achieving this in an API may not always be easy.
>
> This weekend I spent lots of "quality time" with the debugger, trying to
> figure out why I could
> not get a new window with a PluggableListMorph to work like another one
> which had exactly
> the behavior I wanted. The bug was that a method referred to by the
> #indexSetter: keyword
> needed to send the #selectedItem: message, which is not mentioned by
> keyword. Not sure
> what the answer is for that one but I'm working on notes to try to avoid
> that stupid mistake in
> the future. :)
>
> I'm just saying we should do anything we can to enhance clarity as well as
> simplify.
>
>  - Dan
>
>
Since you are using the right keywords, maybe it's time to view it again
Simple made easy
http://www.infoq.com/presentations/Simple-Made-Easy

_______________________________________________
> 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/20150701/06743c77/attachment-0002.html>

From peter at aba-instituut.nl  Wed Jul  1 15:10:31 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 1 Jul 2015 22:10:31 +0200
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>
	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>
	<55917102.4030901@jvuletich.org>
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
Message-ID: <CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>

Hi all,

I believe that a class can be justified simply because it gives you
an intention revealing name in the code, and room to put a
class comment (possibly an extensive one).

Especially with exceptions it can be difficult to understand
what exactly the exception is for, and a class comment can
be extremely helpful.

So, one thing that I am saying is that a class with NO behavior
but a well-chosen name, superclass and a clear class comment, can
be a very valuable part of a system.

Another thing I believe is that a class by itself is not very complex.
Complex in the sense of adding to the overall complexity of the system.

I have been interested in complexity and reducing it for a very long time
(since before I started with Smalltalk) and I have often thought about
the rules one would put into a tool that automatically measured the
complexity of a system of code.

One application of such a tool would be refactoring. Generally, after I
refactor, all my old tests should still run, but also, my overall complexity
should be lower.

At least, that was my thinking, and a tool that measures
complexity could help with that. In a sense it would be a more
sophisticated version of the "rule of three".

In any case, I never implemented such a tool, but did develop a set of
heuristics/rules that I let guide me to decide whether I should extract
methods, extract classes, etc. Part of these heuristics was that a class
by itself did not add that much.

I don't remember most of my rules although I probably still follow them
intuitively. Perhaps a class added more complexity than a method, but not
more than two methods, I don't really know.

I wonder what others do to decide how to factor code.

Cheers, Peter



On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>
>> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>>
>> > Hi folks,
>> >
>> > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>> > > On Mon, 29 Jun 2015 07:09:43 -0400
>> > > "Phil (list)"<pbpublist at gmail.com>  wrote:
>> > >> ..  Is it
>> > >> worth having a class for this vs. raising the more general
>> > Notification
>> > >> and then checking for a #ReparseAfterSourceEditing signal, and if
>> > it
>> > >> isn't, re-raise Notification in its sole handler?
>> > >> ..
>> > >> This is a specific example of the more general question of where
>> > to draw
>> > >> the line on having single, or very limited, use classes and
>> > methods vs.
>> > >> adding a tiny bit of complexity in one or two methods to simplify
>> > the
>> > >> overall image or package in question.  Thoughts?
>> > > I would say the overriding goal is clarity.
>> > >
>> > > It is important work to refactor code to have the same behavior
>> > but be easier to understand.
>> > >
>> > > A Smalltalk style goal is to have small methods which do things
>> > clearly.  This tends to lead to lots of small methods.
>> > >
>> > > Specializing classes for one or just a few methods may seem
>> > wasteful, but computer resources are cheap.
>> > >
>> > > Look at class #PartsBinMorph.  Would you say the having the
>> > additional class is wasteful?
>> > >
>> > > It is a tough balance.  Aesthetics and restraint require judgement
>> > and we don't always get it right.  It takes time.
>> > >
>> > > I only have so many life hours left.  I feel my time is valuable.
>> > I prefer to understand.
>> > >
>> > > Thank you so much for taking the time to make Cuis more
>> > comprehensible.
>> > >
>> > > $0.02
>> > > -KenD
>> >
>> > I fully support Ken. I don't think that a general answer is correct
>> > in
>> > all cases here. It is a matter of making code easy to understand.
>> > But
>> > also making it consistent and pretty.
>> >
>> > In general, I don't like making general classes know much about
>> > details
>> > of specific use cases. But there might be exceptions.
>> >
>> > If you feel like experimenting with this kind of stuff, send your
>> > suggestions to the mail list so we can discuss.
>> >
>> > In the particular case of ReparseAfterSourceEditing, I agree that a
>> > class that does nothing is a bit strange. But, what is the
>> > alternative?
>> > How would the sole exception handler know what to do with a general
>> > Notification? I think the handler looks quite reasonable right now.
>> > And
>> > the pollution of the global space might be tolerable if the
>> > alternative
>> > is more convoluted code...
>> >
>>
>> Making code easy to understand is very valuable. Simple things should be
>> simple to
>> accomplish, but achieving this in an API may not always be easy.
>>
>> This weekend I spent lots of "quality time" with the debugger, trying to
>> figure out why I could
>> not get a new window with a PluggableListMorph to work like another one
>> which had exactly
>> the behavior I wanted. The bug was that a method referred to by the
>> #indexSetter: keyword
>> needed to send the #selectedItem: message, which is not mentioned by
>> keyword. Not sure
>> what the answer is for that one but I'm working on notes to try to avoid
>> that stupid mistake in
>> the future. :)
>>
>> I'm just saying we should do anything we can to enhance clarity as well
>> as simplify.
>>
>>  - Dan
>>
>>
> Since you are using the right keywords, maybe it's time to view it again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy
>
> _______________________________________________
>> 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/20150701/09108f29/attachment-0002.html>

From peter at aba-instituut.nl  Wed Jul  1 15:20:11 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 1 Jul 2015 22:20:11 +0200
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1435627676.2309.133.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<54FEF396.1070509@jvuletich.org>
	<1426014697.2279.25.camel@gmail.com>
	<1435627676.2309.133.camel@gmail.com>
Message-ID: <CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>

Not sure if this is related but InspectorWindow does not cut
off the text in the title bar of the window eagerly enough.

Take an inspector whose title is too long for the window
and see how the text is cut off mid-character at the right
border of the window. Move the window around and it leaves
a trail, exactly where the character pixels touch the side.

BTW, the devoweling of inspector titles I strongly dislike.
If that could be taken out, great. Or perhaps someone has
real good use for that?

Thanks, Peter

On Tue, Jun 30, 2015 at 3:27 AM, Phil (list) <pbpublist at gmail.com> wrote:

> An old issue with some new info...
>
> On Tue, 2015-03-10 at 15:11 -0400, Phil (list) wrote:
> > On Tue, 2015-03-10 at 10:37 -0300, Juan Vuletich wrote:
> > > Hi Phil,
> > >
> > > (inline)
> > > On 3/9/2015 6:54 AM, Phil (list) wrote:
> > > > I've been testing some of my code after migrating to the local
> > > > coordinate system and am running into a few things:
> > > >
> > > > 1) Morph stepping appears to be non-functional (at least in terms of
> > > > running the code as-is from Cuis 4.0)
> > >
> > > You already found #stepAt: . In any case, the "message names" tool is
> > > your friend.
> > >
> >
> > As was FrameRateMorph.
> >
> > > > 2) Halos are behaving badly on occasion... drawing artifacts,
> problems
> > > > resizing, experiencing the odd image crash here and there.
> > >
> > > Please, steps to reproduce.
> > >
> >
> > Working on narrowing down.
>
> At least the drawing artifacts issue doesn't appear to be Halo specific.
> I've been seeing it on occasion with other kinds of Morphs.  Today it
> finally dawned on me what is going on: Morphs are drawing outside of
> their bounds.  I think I have a reproducible scenario: in the Workspace
> type ReparseAfterSourceEditing, select and right click->Smalltalk
> Options->Method Source with it.  On my computer, the default window size
> results in the title text being drawn well outside of the Morph so
> there's no mistaking what's going on.  Drag the window around and notice
> the artifacts.  I think Halos and other Morphs are doing the same thing
> though less obviously.
>
>
> _______________________________________________
> 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/20150701/77b298a2/attachment-0002.html>

From pbpublist at gmail.com  Wed Jul  1 15:30:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 16:30:01 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<54FEF396.1070509@jvuletich.org> <1426014697.2279.25.camel@gmail.com>
	<1435627676.2309.133.camel@gmail.com>
	<CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>
Message-ID: <1435782601.2309.170.camel@gmail.com>

On Wed, 2015-07-01 at 22:20 +0200, Peter van Rooijen wrote:
> Not sure if this is related but InspectorWindow does not cut
> off the text in the title bar of the window eagerly enough.
> 

That's exactly the issue I'm referring to (though it is larger in scope
than just title bars.)

> 
> Take an inspector whose title is too long for the window
> and see how the text is cut off mid-character at the right
> border of the window. Move the window around and it leaves
> a trail, exactly where the character pixels touch the side.
> 

Yup.

> 
> BTW, the devoweling of inspector titles I strongly dislike.
> If that could be taken out, great. Or perhaps someone has
> real good use for that?
> 

I'm not wild about it either but in many cases I think it is probably
better than just truncating the string.  I think that's one of those
things where a better approach would be nice but so far no one has come
up with one...

> 
> Thanks, Peter
> 
> On Tue, Jun 30, 2015 at 3:27 AM, Phil (list) <pbpublist at gmail.com>
> wrote:
>         An old issue with some new info...
>         
>         On Tue, 2015-03-10 at 15:11 -0400, Phil (list) wrote:
>         > On Tue, 2015-03-10 at 10:37 -0300, Juan Vuletich wrote:
>         > > Hi Phil,
>         > >
>         > > (inline)
>         > > On 3/9/2015 6:54 AM, Phil (list) wrote:
>         > > > I've been testing some of my code after migrating to the
>         local
>         > > > coordinate system and am running into a few things:
>         > > >
>         > > > 1) Morph stepping appears to be non-functional (at least
>         in terms of
>         > > > running the code as-is from Cuis 4.0)
>         > >
>         > > You already found #stepAt: . In any case, the "message
>         names" tool is
>         > > your friend.
>         > >
>         >
>         > As was FrameRateMorph.
>         >
>         > > > 2) Halos are behaving badly on occasion... drawing
>         artifacts, problems
>         > > > resizing, experiencing the odd image crash here and
>         there.
>         > >
>         > > Please, steps to reproduce.
>         > >
>         >
>         > Working on narrowing down.
>         
>         At least the drawing artifacts issue doesn't appear to be Halo
>         specific.
>         I've been seeing it on occasion with other kinds of Morphs.
>         Today it
>         finally dawned on me what is going on: Morphs are drawing
>         outside of
>         their bounds.  I think I have a reproducible scenario: in the
>         Workspace
>         type ReparseAfterSourceEditing, select and right
>         click->Smalltalk
>         Options->Method Source with it.  On my computer, the default
>         window size
>         results in the title text being drawn well outside of the
>         Morph so
>         there's no mistaking what's going on.  Drag the window around
>         and notice
>         the artifacts.  I think Halos and other Morphs are doing the
>         same thing
>         though less obviously.
>         
>         
>         _______________________________________________
>         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 Ken.Dickey at whidbey.com  Wed Jul  1 15:35:34 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Wed, 1 Jul 2015 13:35:34 -0700
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1435782601.2309.170.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<54FEF396.1070509@jvuletich.org>
	<1426014697.2279.25.camel@gmail.com>
	<1435627676.2309.133.camel@gmail.com>
	<CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>
	<1435782601.2309.170.camel@gmail.com>
Message-ID: <20150701133534.7bcc7623e97ea01308b48194@whidbey.com>

On Wed, 01 Jul 2015 16:30:01 -0400
"Phil (list)" <pbpublist at gmail.com> wrote:

> > BTW, the devoweling of inspector titles I strongly dislike.
> > If that could be taken out, great. Or perhaps someone has
> > real good use for that?
> 
> I'm not wild about it either but in many cases I think it is probably
> better than just truncating the string.  I think that's one of those
> things where a better approach would be nice but so far no one has come
> up with one...

I find it much more helpful than truncated strings.

FYI,
-KenD



From pbpublist at gmail.com  Wed Jul  1 15:54:22 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 16:54:22 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>
	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>
	<55917102.4030901@jvuletich.org>
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
Message-ID: <1435784062.2309.192.camel@gmail.com>

On Wed, 2015-07-01 at 22:10 +0200, Peter van Rooijen wrote:
> Hi all,
> 
> 
> I believe that a class can be justified simply because it gives you
> an intention revealing name in the code, and room to put a
> class comment (possibly an extensive one).
> 

I believe that's the thinking that results in most of the current
Exception subclasses.  I personally don't care for it, but will go with
the consensus which seems to be OK with it.

> 
> Especially with exceptions it can be difficult to understand
> what exactly the exception is for, and a class comment can
> be extremely helpful.
> 

But Exceptions have a #signal: value which could also easily convey that
information.  (that's not always true, but the point is there are other
ways to convey the information other than subclassing)  Also keep in
mind that many exceptions, such as the one I was pointing out, are never
even seen by the user: they are used as an alternate messaging channel
by the code.

> 
> So, one thing that I am saying is that a class with NO behavior
> but a well-chosen name, superclass and a clear class comment, can
> be a very valuable part of a system.
> 
> 
> Another thing I believe is that a class by itself is not very complex.
> Complex in the sense of adding to the overall complexity of the
> system.
> 

True, a single class by itself is not very complex.  Multiply that by
100x or more and the story changes.  To me, one of the more obvious
aspects of complexity is the aggregate # of classes/methods/lines of
code in a system.  In this particular case, I was wondering out loud if
this particular trade-off (i.e. creating a class to save 1-2 lines of
code) was worth it.  I find it interesting that exception handling is
one of the younger parts of Smalltalk and, to me at least, it really
stands out as being rather strangely implemented in terms of the class
hierarchy.

> 
> I have been interested in complexity and reducing it for a very long
> time
> (since before I started with Smalltalk) and I have often thought about
> the rules one would put into a tool that automatically measured the
> complexity of a system of code.
> 
> 
> One application of such a tool would be refactoring. Generally, after
> I
> refactor, all my old tests should still run, but also, my overall
> complexity
> should be lower.
> 
> 
> At least, that was my thinking, and a tool that measures
> complexity could help with that. In a sense it would be a more
> sophisticated version of the "rule of three".
> 
> 
> In any case, I never implemented such a tool, but did develop a set of
> heuristics/rules that I let guide me to decide whether I should
> extract
> methods, extract classes, etc. Part of these heuristics was that a
> class
> by itself did not add that much.
> 
> 
> I don't remember most of my rules although I probably still follow
> them
> intuitively. Perhaps a class added more complexity than a method, but
> not
> more than two methods, I don't really know.
> 
> 
> I wonder what others do to decide how to factor code.
> 

You might want to take a look at Moose http://www.moosetechnology.org/
It's a tool to help you analyze and understand a given body of code.
It's a bit fragile/brittle/incomplete, but right now it's about the best
I've found to date to try to analyze and quantify complexity.  Also, you
could take a look at the work VPRI is doing related to FoNC/STEPS as
minimizing complexity is core to what they are working on.

> 
> Cheers, Peter
> 
> 
> 
> 
> 
> On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>         
>         
>         2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>                 On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>                 
>                 > Hi folks,
>                 >
>                 > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>                 > > On Mon, 29 Jun 2015 07:09:43 -0400
>                 > > "Phil (list)"<pbpublist at gmail.com>  wrote:
>                 > >> ..  Is it
>                 > >> worth having a class for this vs. raising the
>                 more general
>                 > Notification
>                 > >> and then checking for a
>                 #ReparseAfterSourceEditing signal, and if
>                 > it
>                 > >> isn't, re-raise Notification in its sole handler?
>                 > >> ..
>                 > >> This is a specific example of the more general
>                 question of where
>                 > to draw
>                 > >> the line on having single, or very limited, use
>                 classes and
>                 > methods vs.
>                 > >> adding a tiny bit of complexity in one or two
>                 methods to simplify
>                 > the
>                 > >> overall image or package in question.  Thoughts?
>                 > > I would say the overriding goal is clarity.
>                 > >
>                 > > It is important work to refactor code to have the
>                 same behavior
>                 > but be easier to understand.
>                 > >
>                 > > A Smalltalk style goal is to have small methods
>                 which do things
>                 > clearly.  This tends to lead to lots of small
>                 methods.
>                 > >
>                 > > Specializing classes for one or just a few methods
>                 may seem
>                 > wasteful, but computer resources are cheap.
>                 > >
>                 > > Look at class #PartsBinMorph.  Would you say the
>                 having the
>                 > additional class is wasteful?
>                 > >
>                 > > It is a tough balance.  Aesthetics and restraint
>                 require judgement
>                 > and we don't always get it right.  It takes time.
>                 > >
>                 > > I only have so many life hours left.  I feel my
>                 time is valuable.
>                 > I prefer to understand.
>                 > >
>                 > > Thank you so much for taking the time to make Cuis
>                 more
>                 > comprehensible.
>                 > >
>                 > > $0.02
>                 > > -KenD
>                 >
>                 > I fully support Ken. I don't think that a general
>                 answer is correct
>                 > in
>                 > all cases here. It is a matter of making code easy
>                 to understand.
>                 > But
>                 > also making it consistent and pretty.
>                 >
>                 > In general, I don't like making general classes know
>                 much about
>                 > details
>                 > of specific use cases. But there might be
>                 exceptions.
>                 >
>                 > If you feel like experimenting with this kind of
>                 stuff, send your
>                 > suggestions to the mail list so we can discuss.
>                 >
>                 > In the particular case of ReparseAfterSourceEditing,
>                 I agree that a
>                 > class that does nothing is a bit strange. But, what
>                 is the
>                 > alternative?
>                 > How would the sole exception handler know what to do
>                 with a general
>                 > Notification? I think the handler looks quite
>                 reasonable right now.
>                 > And
>                 > the pollution of the global space might be tolerable
>                 if the
>                 > alternative
>                 > is more convoluted code...
>                 >
>                 
>                 
>                 Making code easy to understand is very valuable.
>                 Simple things should be simple to
>                 accomplish, but achieving this in an API may not
>                 always be easy.
>                 
>                 This weekend I spent lots of "quality time" with the
>                 debugger, trying to figure out why I could
>                 not get a new window with a PluggableListMorph to work
>                 like another one which had exactly
>                 the behavior I wanted. The bug was that a method
>                 referred to by the #indexSetter: keyword
>                 needed to send the #selectedItem: message, which is
>                 not mentioned by keyword. Not sure
>                 what the answer is for that one but I'm working on
>                 notes to try to avoid that stupid mistake in
>                 the future. :)
>                 
>                 I'm just saying we should do anything we can to
>                 enhance clarity as well as simplify.
>                 
>                  - Dan
>                 
>                 
>         
>         
>         Since you are using the right keywords, maybe it's time to
>         view it again
>         
>         Simple made easy
>         http://www.infoq.com/presentations/Simple-Made-Easy 
>         
>         
>                 _______________________________________________
>                 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Wed Jul  1 16:33:32 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 01 Jul 2015 17:33:32 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <20150701133534.7bcc7623e97ea01308b48194@whidbey.com>
References: <1425894846.2281.37.camel@gmail.com>,
	<1435782601.2309.170.camel@gmail.com>,
	<20150701133534.7bcc7623e97ea01308b48194@whidbey.com>
Message-ID: <55945CAC.22357.1785ED9@dnorton.mindspring.com>

On 1 Jul 2015 at 13:35, Ken.Dickey wrote:

> On Wed, 01 Jul 2015 16:30:01 -0400
> "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > > BTW, the devoweling of inspector titles I strongly dislike.
> > > If that could be taken out, great. Or perhaps someone has
> > > real good use for that?
> > 
> > I'm not wild about it either but in many cases I think it is
> probably
> > better than just truncating the string.  I think that's one of
> those
> > things where a better approach would be nice but so far no one has
> come
> > up with one...
> 
> I find it much more helpful than truncated strings.
> 
> FYI,
> -KenD
> 

+1

Best regards,
 - Dan



From juan at jvuletich.org  Wed Jul  1 19:29:42 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:29:42 -0300
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>	<55917102.4030901@jvuletich.org>	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
Message-ID: <559485F6.3030408@jvuletich.org>

On 7/1/2015 9:52 AM, Nicolas Cellier wrote:
> ...
>
> Since you are using the right keywords, maybe it's time to view it again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy

Thanks Nicolas. This is absolutely wonderful! Really inspiring.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  1 19:37:40 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:37:40 -0300
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>	<55917102.4030901@jvuletich.org>	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
Message-ID: <559487D4.30603@jvuletich.org>

On 7/1/2015 5:10 PM, Peter van Rooijen wrote:
> ...
>
> I don't remember most of my rules although I probably still follow them
> intuitively. Perhaps a class added more complexity than a method, but not
> more than two methods, I don't really know.
>
> I wonder what others do to decide how to factor code.
>
> Cheers, Peter


To me Smalltalk code is an expression of human knowledge. I refactor 
code when I understand better, to express that new understanding.

Writing code is like writing course material, or a technical book on 
some subject. Good code is like a good book. You read it and understand. 
That's the gold standard.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  1 19:43:08 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:43:08 -0300
Subject: [Cuis] Updates
Message-ID: <5594891C.6090104@jvuletich.org>

Hi Folks,

Today I did a commit. I fixed recently reported issues (halos, window 
labels, etc). I also added Dan Norton's port of BouncingAtoms to the 
packages folder (thanks Dan!).

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  1 19:51:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:51:34 -0300
Subject: [Cuis] Display units and UI widgets in Morphic 3
In-Reply-To: <1435714029.2309.155.camel@gmail.com>
References: <1435714029.2309.155.camel@gmail.com>
Message-ID: <55948B16.4060100@jvuletich.org>

Hi Phil,

On 6/30/2015 10:27 PM, Phil (list) wrote:
> Juan,
>
> I vaguely recall previously having a discussion somewhere about unit
> scaling / high dpi but can't seem to find the thread.  Anyways, this
> question is specific to Morphic 3: from a UI creation standpoint is
> Morphic 3 still going to use pixel-based units or will some other unit
> of measure be used? i.e. if you design a UI and have say a 32x32
> button, is that going to need to be scaled up (understanding that this
> will be trivial for Morphic 3 to do) for high-dpi displays?  Is this
> even a Morphic concern or will it be up to Cuis as an environment to
> have a preference for display scaling?

In Morphic 3 you can use any unit you want for your Morphs. It is 
perfectly reasonable to use pixels, at your preferred zoom level and 
DPI. You can also use domain specific units.

The user is able to scale the World or any particular Morph to suit his 
needs or taste, much like you do in Google Maps, in Satellite mode.

> Related to this is the question of how much do you anticipate
> higher-level UI code needing to be reworked for Morphic 3? One
> of the many projects I've been playing around with giving things a bit
> of a face-lift (i.e. a logging framework that can handle non-textual
> data, grid and multi-element list pluggable morphs, visualization
> widgets, etc... sort of along the lines of what is being done in Pharo
> with the playground stuff) and am just wondering how far I should go
> with this work before seeing what's involved in migrating to Morphic 3?

In principle, there is no code rework needed. The local coordinates, 
locations, etc. are the standard in Cuis since a few years ago.

The difference is that Morphic 3 will make some new things possible, and 
others will be simpler. It will also give the user a better control on 
how to use the UI.

> (I did take a quick peek at the Morphic 3 package but didn't find
> answers as it looks like you're still working out the lower level
> details)
>
> Thanks,
> Phil

Well, but that experimental code already can draw essentially any Cuis 
morphic World. It is just some lower level details what is missing to 
make it the main graphics engine for Cuis.

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Wed Jul  1 20:59:54 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 21:59:54 -0400
Subject: [Cuis] Updates
In-Reply-To: <5594891C.6090104@jvuletich.org>
References: <5594891C.6090104@jvuletich.org>
Message-ID: <1435802394.2309.194.camel@gmail.com>

On Wed, 2015-07-01 at 21:43 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> Today I did a commit. I fixed recently reported issues (halos, window 
> labels, etc). I also added Dan Norton's port of BouncingAtoms to the 
> packages folder (thanks Dan!).
> 

Looks good to me. (heh... now that Cuis isn't leaving behind artifacts
it exposed the issue that some of my morphs were too :-)

> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From pbpublist at gmail.com  Wed Jul  1 21:02:43 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 22:02:43 -0400
Subject: [Cuis] Display units and UI widgets in Morphic 3
In-Reply-To: <55948B16.4060100@jvuletich.org>
References: <1435714029.2309.155.camel@gmail.com>
	<55948B16.4060100@jvuletich.org>
Message-ID: <1435802563.2309.197.camel@gmail.com>

On Wed, 2015-07-01 at 21:51 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 6/30/2015 10:27 PM, Phil (list) wrote:
> > Juan,
> >
> > I vaguely recall previously having a discussion somewhere about unit
> > scaling / high dpi but can't seem to find the thread.  Anyways, this
> > question is specific to Morphic 3: from a UI creation standpoint is
> > Morphic 3 still going to use pixel-based units or will some other unit
> > of measure be used? i.e. if you design a UI and have say a 32x32
> > button, is that going to need to be scaled up (understanding that this
> > will be trivial for Morphic 3 to do) for high-dpi displays?  Is this
> > even a Morphic concern or will it be up to Cuis as an environment to
> > have a preference for display scaling?
> 
> In Morphic 3 you can use any unit you want for your Morphs. It is 
> perfectly reasonable to use pixels, at your preferred zoom level and 
> DPI. You can also use domain specific units.
> 
> The user is able to scale the World or any particular Morph to suit his 
> needs or taste, much like you do in Google Maps, in Satellite mode.
> 

Excellent... that's what I was hoping for.

> > Related to this is the question of how much do you anticipate
> > higher-level UI code needing to be reworked for Morphic 3? One
> > of the many projects I've been playing around with giving things a bit
> > of a face-lift (i.e. a logging framework that can handle non-textual
> > data, grid and multi-element list pluggable morphs, visualization
> > widgets, etc... sort of along the lines of what is being done in Pharo
> > with the playground stuff) and am just wondering how far I should go
> > with this work before seeing what's involved in migrating to Morphic 3?
> 
> In principle, there is no code rework needed. The local coordinates, 
> locations, etc. are the standard in Cuis since a few years ago.
> 
> The difference is that Morphic 3 will make some new things possible, and 
> others will be simpler. It will also give the user a better control on 
> how to use the UI.
> 

Better and better!

> > (I did take a quick peek at the Morphic 3 package but didn't find
> > answers as it looks like you're still working out the lower level
> > details)
> >
> > Thanks,
> > Phil
> 
> Well, but that experimental code already can draw essentially any Cuis 
> morphic World. It is just some lower level details what is missing to 
> make it the main graphics engine for Cuis.
> 

Hmm... then I need to take another look.  I probably wasn't loading
and/or initializing things correctly.

> Cheers,
> Juan Vuletich





From dnorton at mindspring.com  Thu Jul  2 20:15:27 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 02 Jul 2015 21:15:27 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>,
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>,
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
Message-ID: <5595E22F.2684.23EA964@dnorton.mindspring.com>

Hi,

I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The 
question is how to view it without disabling my antivirus plus surrendering a bunch of 
"required" info. BTW I'm running Win7, IE, and ESET.

Any other possibilities?

 - Dan

On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:

> 
> 
> 
> 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>     On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>     
>     > Hi folks,
>     >
>     > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>     > > On Mon, 29 Jun 2015 07:09:43 -0400
>     > > "Phil (list)"<pbpublist at gmail.com>? wrote:
>     > >> ..? Is it
>     > >> worth having a class for this vs. raising the more
> general
>     > Notification
>     > >> and then checking for a #ReparseAfterSourceEditing signal,
> and if
>     > it
>     > >> isn't, re-raise Notification in its sole handler?
>     > >> ..
>     > >> This is a specific example of the more general question of
> where
>     > to draw
>     > >> the line on having single, or very limited, use classes
> and
>     > methods vs.
>     > >> adding a tiny bit of complexity in one or two methods to
> simplify
>     > the
>     > >> overall image or package in question.? Thoughts?
>     > > I would say the overriding goal is clarity.
>     > >
>     > > It is important work to refactor code to have the same
> behavior
>     > but be easier to understand.
>     > >
>     > > A Smalltalk style goal is to have small methods which do
> things
>     > clearly.? This tends to lead to lots of small methods.
>     > >
>     > > Specializing classes for one or just a few methods may
> seem
>     > wasteful, but computer resources are cheap.
>     > >
>     > > Look at class #PartsBinMorph.? Would you say the having
> the
>     > additional class is wasteful?
>     > >
>     > > It is a tough balance.? Aesthetics and restraint require
> judgement
>     > and we don't always get it right.? It takes time.
>     > >
>     > > I only have so many life hours left.? I feel my time is
> valuable.
>     > I prefer to understand.
>     > >
>     > > Thank you so much for taking the time to make Cuis more
>     > comprehensible.
>     > >
>     > > $0.02
>     > > -KenD
>     >
>     > I fully support Ken. I don't think that a general answer is
> correct
>     > in
>     > all cases here. It is a matter of making code easy to
> understand.
>     > But
>     > also making it consistent and pretty.
>     >
>     > In general, I don't like making general classes know much
> about
>     > details
>     > of specific use cases. But there might be exceptions.
>     >
>     > If you feel like experimenting with this kind of stuff, send
> your
>     > suggestions to the mail list so we can discuss.
>     >
>     > In the particular case of ReparseAfterSourceEditing, I agree
> that a
>     > class that does nothing is a bit strange. But, what is the
>     > alternative?
>     > How would the sole exception handler know what to do with a
> general
>     > Notification? I think the handler looks quite reasonable right
> now.
>     > And
>     > the pollution of the global space might be tolerable if the
>     > alternative
>     > is more convoluted code...
>     >
> 
>     Making code easy to understand is very valuable. Simple things
> should be simple to
>     accomplish, but achieving this in an API may not always be
> easy.
>     
>     This weekend I spent lots of "quality time" with the debugger,
> trying to figure out why I could
>     not get a new window with a PluggableListMorph to work like
> another one which had exactly
>     the behavior I wanted. The bug was that a method referred to by
> the #indexSetter: keyword
>     needed to send the #selectedItem: message, which is not
> mentioned by keyword. Not sure
>     what the answer is for that one but I'm working on notes to try
> to avoid that stupid mistake in
>     the future. :)
>     
>     I'm just saying we should do anything we can to enhance clarity
> as well as simplify.
>     
>     ?- Dan
> 
> 
> Since you are using the right keywords, maybe it's time to view it
> again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy
> 
>     _______________________________________________
>     Cuis mailing list
>     Cuis at jvuletich.org
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> 





From juan at jvuletich.org  Thu Jul  2 20:55:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 2 Jul 2015 22:55:27 -0300
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <5595E22F.2684.23EA964@dnorton.mindspring.com>
References: <1435576183.2309.69.camel@gmail.com>,
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>,
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<5595E22F.2684.23EA964@dnorton.mindspring.com>
Message-ID: <03aa649484e81e74b85e0dcfd201bc9e.squirrel@gator3294.hostgator.com>

Hi Dan,

It plays without problems in Chrome on my Win7 PC. No need to supply any
info at all.

HTH,
Juan vuletich

On Thu, July 2, 2015 10:15 pm, Dan Norton wrote:
> Hi,
>
>
> I would like to view this, especially since it is recommended by Nicolas,
> Paul, and Juan. The
> question is how to view it without disabling my antivirus plus
> surrendering a bunch of "required" info. BTW I'm running Win7, IE, and
> ESET.
>
>
> Any other possibilities?
>
>
> - Dan
>
>
> On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:
>
>
>>
>>
>>
>> 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>>
>>
>>> Hi folks,
>>>
>>>
>>> On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>>>
>>>> On Mon, 29 Jun 2015 07:09:43 -0400
>>>> "Phil (list)"<pbpublist at gmail.com>? wrote:
>>>>
>>>>> ..? Is it
>>>>> worth having a class for this vs. raising the more
>> general
>>> Notification
>>>
>>>>> and then checking for a #ReparseAfterSourceEditing signal,
>> and if
>>> it
>>>>> isn't, re-raise Notification in its sole handler? ..
>>>>> This is a specific example of the more general question of
>>>>>
>> where
>>> to draw
>>>>> the line on having single, or very limited, use classes
>> and
>>> methods vs.
>>>>> adding a tiny bit of complexity in one or two methods to
>> simplify
>>> the
>>>>> overall image or package in question.? Thoughts?
>>>> I would say the overriding goal is clarity.
>>>>
>>>>
>>>> It is important work to refactor code to have the same
>>>>
>> behavior
>>> but be easier to understand.
>>>>
>>>> A Smalltalk style goal is to have small methods which do
>>>>
>> things
>>> clearly.? This tends to lead to lots of small methods.
>>>>
>>>> Specializing classes for one or just a few methods may
>>>>
>> seem
>>> wasteful, but computer resources are cheap.
>>>>
>>>> Look at class #PartsBinMorph.? Would you say the having
>>>>
>> the
>>> additional class is wasteful?
>>>>
>>>> It is a tough balance.? Aesthetics and restraint require
>>>>
>> judgement
>>> and we don't always get it right.? It takes time.
>>>>
>>>> I only have so many life hours left.? I feel my time is
>>>>
>> valuable.
>>> I prefer to understand.
>>>
>>>>
>>>> Thank you so much for taking the time to make Cuis more
>>>>
>>> comprehensible.
>>>>
>>>> $0.02
>>>> -KenD
>>>>
>>>
>>> I fully support Ken. I don't think that a general answer is
>>>
>> correct
>>> in all cases here. It is a matter of making code easy to
>> understand.
>>> But
>>> also making it consistent and pretty.
>>>
>>> In general, I don't like making general classes know much
>>>
>> about
>>> details of specific use cases. But there might be exceptions.
>>>
>>> If you feel like experimenting with this kind of stuff, send
>>>
>> your
>>> suggestions to the mail list so we can discuss.
>>>
>>> In the particular case of ReparseAfterSourceEditing, I agree
>>>
>> that a
>>> class that does nothing is a bit strange. But, what is the
>>> alternative? How would the sole exception handler know what to do with
>>> a
>> general
>>> Notification? I think the handler looks quite reasonable right
>>>
>> now.
>>> And
>>> the pollution of the global space might be tolerable if the alternative
>>>  is more convoluted code...
>>>
>>
>> Making code easy to understand is very valuable. Simple things
>> should be simple to accomplish, but achieving this in an API may not
>> always be easy.
>>
>> This weekend I spent lots of "quality time" with the debugger,
>> trying to figure out why I could not get a new window with a
>> PluggableListMorph to work like
>> another one which had exactly the behavior I wanted. The bug was that a
>> method referred to by the #indexSetter: keyword needed to send the
>> #selectedItem: message, which is not
>> mentioned by keyword. Not sure what the answer is for that one but I'm
>> working on notes to try to avoid that stupid mistake in the future. :)
>>
>> I'm just saying we should do anything we can to enhance clarity
>> as well as simplify.
>>
>> ?- Dan
>>
>>
>>
>> Since you are using the right keywords, maybe it's time to view it
>> again Simple made easy
>> http://www.infoq.com/presentations/Simple-Made-Easy
>>
>>
>> _______________________________________________
>> 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 pbpublist at gmail.com  Thu Jul  2 21:03:41 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 02 Jul 2015 22:03:41 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <5595E22F.2684.23EA964@dnorton.mindspring.com>
References: <1435576183.2309.69.camel@gmail.com>
	, <5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	, <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<5595E22F.2684.23EA964@dnorton.mindspring.com>
Message-ID: <1435889021.2309.200.camel@gmail.com>

You're probably trying one of the download links.  You can stream the
video as long as JavaScript is enabled.  If you can't temporarily do
this in IE, I'd highly recommend keeping Firefox+NoScript around as it
lets you temporarily enable JavaScript & cookies for this type of
scenario.

On Thu, 2015-07-02 at 21:15 -0400, Dan Norton wrote:
> Hi,
> 
> I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The 
> question is how to view it without disabling my antivirus plus surrendering a bunch of 
> "required" info. BTW I'm running Win7, IE, and ESET.
> 
> Any other possibilities?
> 
>  - Dan
> 
> On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:
> 
> > 
> > 
> > 
> > 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
> >     On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
> >     
> >     > Hi folks,
> >     >
> >     > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> >     > > On Mon, 29 Jun 2015 07:09:43 -0400
> >     > > "Phil (list)"<pbpublist at gmail.com>  wrote:
> >     > >> ..  Is it
> >     > >> worth having a class for this vs. raising the more
> > general
> >     > Notification
> >     > >> and then checking for a #ReparseAfterSourceEditing signal,
> > and if
> >     > it
> >     > >> isn't, re-raise Notification in its sole handler?
> >     > >> ..
> >     > >> This is a specific example of the more general question of
> > where
> >     > to draw
> >     > >> the line on having single, or very limited, use classes
> > and
> >     > methods vs.
> >     > >> adding a tiny bit of complexity in one or two methods to
> > simplify
> >     > the
> >     > >> overall image or package in question.  Thoughts?
> >     > > I would say the overriding goal is clarity.
> >     > >
> >     > > It is important work to refactor code to have the same
> > behavior
> >     > but be easier to understand.
> >     > >
> >     > > A Smalltalk style goal is to have small methods which do
> > things
> >     > clearly.  This tends to lead to lots of small methods.
> >     > >
> >     > > Specializing classes for one or just a few methods may
> > seem
> >     > wasteful, but computer resources are cheap.
> >     > >
> >     > > Look at class #PartsBinMorph.  Would you say the having
> > the
> >     > additional class is wasteful?
> >     > >
> >     > > It is a tough balance.  Aesthetics and restraint require
> > judgement
> >     > and we don't always get it right.  It takes time.
> >     > >
> >     > > I only have so many life hours left.  I feel my time is
> > valuable.
> >     > I prefer to understand.
> >     > >
> >     > > Thank you so much for taking the time to make Cuis more
> >     > comprehensible.
> >     > >
> >     > > $0.02
> >     > > -KenD
> >     >
> >     > I fully support Ken. I don't think that a general answer is
> > correct
> >     > in
> >     > all cases here. It is a matter of making code easy to
> > understand.
> >     > But
> >     > also making it consistent and pretty.
> >     >
> >     > In general, I don't like making general classes know much
> > about
> >     > details
> >     > of specific use cases. But there might be exceptions.
> >     >
> >     > If you feel like experimenting with this kind of stuff, send
> > your
> >     > suggestions to the mail list so we can discuss.
> >     >
> >     > In the particular case of ReparseAfterSourceEditing, I agree
> > that a
> >     > class that does nothing is a bit strange. But, what is the
> >     > alternative?
> >     > How would the sole exception handler know what to do with a
> > general
> >     > Notification? I think the handler looks quite reasonable right
> > now.
> >     > And
> >     > the pollution of the global space might be tolerable if the
> >     > alternative
> >     > is more convoluted code...
> >     >
> > 
> >     Making code easy to understand is very valuable. Simple things
> > should be simple to
> >     accomplish, but achieving this in an API may not always be
> > easy.
> >     
> >     This weekend I spent lots of "quality time" with the debugger,
> > trying to figure out why I could
> >     not get a new window with a PluggableListMorph to work like
> > another one which had exactly
> >     the behavior I wanted. The bug was that a method referred to by
> > the #indexSetter: keyword
> >     needed to send the #selectedItem: message, which is not
> > mentioned by keyword. Not sure
> >     what the answer is for that one but I'm working on notes to try
> > to avoid that stupid mistake in
> >     the future. :)
> >     
> >     I'm just saying we should do anything we can to enhance clarity
> > as well as simplify.
> >     
> >      - Dan
> > 
> > 
> > Since you are using the right keywords, maybe it's time to view it
> > again
> > Simple made easy
> > http://www.infoq.com/presentations/Simple-Made-Easy
> > 
> >     _______________________________________________
> >     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 pbpublist at gmail.com  Sat Jul  4 16:30:43 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 04 Jul 2015 17:30:43 -0400
Subject: [Cuis] Display units and UI widgets in Morphic 3
In-Reply-To: <1435802563.2309.197.camel@gmail.com>
References: <1435714029.2309.155.camel@gmail.com>
	<55948B16.4060100@jvuletich.org> <1435802563.2309.197.camel@gmail.com>
Message-ID: <1436045443.2309.205.camel@gmail.com>

On Wed, 2015-07-01 at 22:02 -0400, Phil (list) wrote:
> On Wed, 2015-07-01 at 21:51 -0300, Juan Vuletich wrote:
> >
> > > (I did take a quick peek at the Morphic 3 package but didn't find
> > > answers as it looks like you're still working out the lower level
> > > details)
> > >
> > > Thanks,
> > > Phil
> > 
> > Well, but that experimental code already can draw essentially any Cuis 
> > morphic World. It is just some lower level details what is missing to 
> > make it the main graphics engine for Cuis.
> > 
> 
> Hmm... then I need to take another look.  I probably wasn't loading
> and/or initializing things correctly.
> 

Ahh... I see my mistake (duh!):  I was trying to load Morphic 3 into the
latest image rather than using your experimental image.  One minor
issue: that image is expecting to find the example SVG files in
svgSamples but the directory is now called SVGSamples.  (Easily
addressed with a symlink so I could run the demo render.)  It looks
very, very nice!

> > Cheers,
> > Juan Vuletich
> 





From Ken.Dickey at whidbey.com  Sat Jul  4 03:04:24 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sat, 4 Jul 2015 16:04:24 +0800
Subject: [Cuis] Package wants to require minimum revision on base
Message-ID: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>

Juan,

The Installed Packages browser used to be able to require a minimum revision on the base release.

I use this feature as a backstop when features change in the base release.

Any chance in getting this ability back?

Thanks much,
-KenD



From hannes.hirzel at gmail.com  Sat Jul  4 18:45:41 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 4 Jul 2015 23:45:41 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
Message-ID: <CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>

Juan,

And this brings up the question that it would be good to have a
'release tag' from time to time.

So that releases show up here

    https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases

Currently there are 0 releases. This is very straightforward to do in github.

This will facilitate checking if external packages still run fine.
There are about 50 commits in
Cuis-Smalltalk-Dev in first two quaters of 2015.

I think I some minor releases (i.e. 2 ... 6 a year) would be fine.

Thanks for considering this

--Hannes

On 7/4/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> Juan,
>
> The Installed Packages browser used to be able to require a minimum revision
> on the base release.
>
> I use this feature as a backstop when features change in the base release.
>
> Any chance in getting this ability back?
>
> Thanks much,
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From pbpublist at gmail.com  Sat Jul  4 19:51:18 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 04 Jul 2015 20:51:18 -0400
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
Message-ID: <1436057478.2309.229.camel@gmail.com>

On Sat, 2015-07-04 at 23:45 +0000, H. Hirzel wrote:
> Juan,
> 
> And this brings up the question that it would be good to have a
> 'release tag' from time to time.
> 
> So that releases show up here
> 
>     https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases
> 
> Currently there are 0 releases. This is very straightforward to do in github.
> 
> This will facilitate checking if external packages still run fine.
> There are about 50 commits in
> Cuis-Smalltalk-Dev in first two quaters of 2015.
> 
> I think I some minor releases (i.e. 2 ... 6 a year) would be fine.
> 
> Thanks for considering this
> 

It seems like for most of my packages I'd need to tie to a minimum build
# (what Ken asked for, i.e. #2400) rather than a version # (4.2.7 or
whatever) right now.  How do you envision using a version # given that
people will pretty much grab whatever the current build is at the time
they download Cuis?

> --Hannes
> 
> On 7/4/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> > Juan,
> >
> > The Installed Packages browser used to be able to require a minimum revision
> > on the base release.
> >
> > I use this feature as a backstop when features change in the base release.
> >
> > Any chance in getting this ability back?
> >
> > Thanks much,
> > -KenD
> >
> > _______________________________________________
> > 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  Sun Jul  5 09:01:06 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 05 Jul 2015 11:01:06 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
Message-ID: <559938A2.3040204@jvuletich.org>

Hi Ken,

On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
> Juan,
>
> The Installed Packages browser used to be able to require a minimum revision on the base release.
>
> I use this feature as a backstop when features change in the base release.
>
> Any chance in getting this ability back?
>
> Thanks much,
> -KenD

When was it lost?  I can't remember doing anything related to this...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sun Jul  5 09:03:44 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 05 Jul 2015 11:03:44 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
Message-ID: <55993940.8090704@jvuletich.org>

Hi Hannes,

Sure, let's discuss this. What do other people maintaining external 
packages think? This is for you...

Cheers,
Juan Vuletich

On 04/07/2015 08:45 p.m., H. Hirzel wrote:
> Juan,
>
> And this brings up the question that it would be good to have a
> 'release tag' from time to time.
>
> So that releases show up here
>
>      https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases
>
> Currently there are 0 releases. This is very straightforward to do in github.
>
> This will facilitate checking if external packages still run fine.
> There are about 50 commits in
> Cuis-Smalltalk-Dev in first two quaters of 2015.
>
> I think I some minor releases (i.e. 2 ... 6 a year) would be fine.
>
> Thanks for considering this
>
> --Hannes
>
> On 7/4/15, Ken.Dickey<Ken.Dickey at whidbey.com>  wrote:
>> Juan,
>>
>> The Installed Packages browser used to be able to require a minimum revision
>> on the base release.
>>
>> I use this feature as a backstop when features change in the base release.
>>
>> Any chance in getting this ability back?
>>
>> Thanks much,
>> -KenD
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>




From Ken.Dickey at whidbey.com  Sat Jul  4 20:57:51 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sun, 5 Jul 2015 09:57:51 +0800
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <559938A2.3040204@jvuletich.org>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<559938A2.3040204@jvuletich.org>
Message-ID: <20150705095751.c84ded291d123bac31348c46@whidbey.com>

On Sun, 05 Jul 2015 11:01:06 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Ken,
> 
> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
> > Juan,
> >
> > The Installed Packages browser used to be able to require a minimum revision on the base release.
> >
> > I use this feature as a backstop when features change in the base release.
> >
> > Any chance in getting this ability back?
> >
> > Thanks much,
> > -KenD
> 
> When was it lost?  I can't remember doing anything related to this...

Not sure when.

If there is more than one package loaded, one can Add Requirement with one option being the base release.  If only one package is loaded, one gets the "Required package must already be loaded" popup, rather than an option to require Cuis-Base.

-- 
-KenD



From dnorton at mindspring.com  Sun Jul  5 18:35:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 05 Jul 2015 19:35:22 -0400
Subject: [Cuis] Minor Direction Padding
Message-ID: <5599BF3A.26485.1F11628@dnorton.mindspring.com>

Greetings,

Four LayoutSpec class methods use "minorDirectionPadding:" as a keyword. The parameter 
can be a number or one of: #top, #left, #center, #right, or #bottom. AFAICT when the 
parameter is a number, it refers to the padding which will be applied in the minor direction. 
When it is a symbol, it effectively specifies that morphs will be located as the symbol name 
implies.

Attached are four convenience methods whose keyword emphasizes the visible (morph) 
instead of the invisible (padding). The "morphPlacement:" parameter can be  #top, #left, 
#center, #right, or #bottom. The methods are:

LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
LayoutSpec class>>proportionalWidth:proportionalHeight:morphPlacement:

Are these worth having in the base system?

 - Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: LayoutSpec class-convenience.zip
Type: application/zip
Size: 1988 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150705/2ebc6107/attachment-0002.zip>

From pbpublist at gmail.com  Mon Jul  6 03:01:56 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 06 Jul 2015 04:01:56 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
Message-ID: <1436169716.2678.46.camel@gmail.com>

Hannes,

Sorry for the delay... it's taken me longer than expected to get back to
it.  I really don't have any simple examples of porting as my stuff is
fairly involved (i.e. drawing and keyboard handling as part of a larger
OpenGL project etc.)  However, I do have more specifics re: what needed
to be done.

On Tue, 2015-03-10 at 06:56 +0000, H. Hirzel wrote:
> Phil,
> 
> could you please provide an example code snippet (Morph class).
> 
> Version 4.0
> vs
> Version 4.2
> ?
> 
> On 3/10/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > Created https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/48 for
> > this.
> >
> > On 3/9/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> On Mon, 2015-03-09 at 05:54 -0400, Phil (list) wrote:
> >>> 1) Morph stepping appears to be non-functional (at least in terms of
> >>> running the code as-is from Cuis 4.0)
> >>
> >> Figured this one out... #step appears to be obsolete, use #stepAt:
> >> instead.  In some cases now need to override #wantsSteps to return true
> >> (the default implementation now always returns false.  This is an issue
> >> only for some of my animated morphs.)
> >>

Morphic (continuous) animation

previously:
#step

now:
#stepAt: (just rename #step to #stepAt: milliseconds)
#wantsSteps (^true)

Notes:
1) If this change isn't made, you may get what appears to be animation,
but it's just the morph redrawing after damage.
2) Be sure to call #truncate on bounds etc. if your code can't handle
floats.
3) I used to have several direct Morph subclasses, but it appears that
they now need to be RectangleLikeMorph subclasses to maintain similar
behavior.



Keyboard focus handling

previously:
#handlesKeyboard (^ true)
#keyboardFocusChange: (call any code needed to deal with getting/losing
focus such as drawing a focus indicator)
#handleKeystroke: (when morph has focus, will receive keystroke)

now:
This is my best guess... are there any examples of working Morphs that
deal with keyboard focus but do *not* have text morphs?
#handlesKeyboard (no change)
#handlesMouseOver: (^true to get #mouseEnter: & #mouseLeave:)
#mouseEnter: event
	event hand newKeyboardFocus: self
#mouseLeave: event
	event hand newKeyboardFocus: nil
#keyStroke: event (receives the keystroke when focused, some event
accessors no longer exist)

Thanks,
Phil




From pbpublist at gmail.com  Mon Jul  6 03:12:39 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 06 Jul 2015 04:12:39 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1436169716.2678.46.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
	<1436169716.2678.46.camel@gmail.com>
Message-ID: <1436170359.2678.52.camel@gmail.com>

On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote:
> Hannes,
> 
> Sorry for the delay... it's taken me longer than expected to get back to
> it.  I really don't have any simple examples of porting as my stuff is
> fairly involved (i.e. drawing and keyboard handling as part of a larger
> OpenGL project etc.)  However, I do have more specifics re: what needed
> to be done.
> 
<snip>
> 
> Keyboard focus handling
> 

One additional thing related to keyboard focus that should probably be
handled by Morphic: various mouse (mouse wheel) and trackpad (gesture)
events get sent as keyboard events and should probably be (at least
optionally?) intercepted from the event stream and sent as distinct
events such as #scroll: etc.  No idea how multi-finger touch screen
gestures are handled by the VM these days but that is yet something else
to think about...

> 
> Thanks,
> Phil





From juan at jvuletich.org  Mon Jul  6 08:33:23 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 06 Jul 2015 10:33:23 -0300
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <5599BF3A.26485.1F11628@dnorton.mindspring.com>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>
Message-ID: <559A83A3.5040406@jvuletich.org>

Hi Dan,

On 7/5/2015 8:35 PM, Dan Norton wrote:
> Greetings,
>
> Four LayoutSpec class methods use "minorDirectionPadding:" as a keyword. The parameter
> can be a number or one of: #top, #left, #center, #right, or #bottom. AFAICT when the
> parameter is a number, it refers to the padding which will be applied in the minor direction.
> When it is a symbol, it effectively specifies that morphs will be located as the symbol name
> implies.
>
> Attached are four convenience methods whose keyword emphasizes the visible (morph)
> instead of the invisible (padding). The "morphPlacement:" parameter can be  #top, #left,
> #center, #right, or #bottom. The methods are:
>
> LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
> LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
> LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
> LayoutSpec class>>proportionalWidth:proportionalHeight:morphPlacement:
>
> Are these worth having in the base system?
>
>   - Dan
>

I'd rather replace the keyword 'minorDirectionPadding:' by 
'minorDirectionPlacement:' to:
- Avoid ambiguity
- Avoid duplication

What do you all think?

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Mon Jul  6 10:00:36 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 6 Jul 2015 15:00:36 +0000
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1436170359.2678.52.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
	<1436169716.2678.46.camel@gmail.com>
	<1436170359.2678.52.camel@gmail.com>
Message-ID: <CAGQxfVgb34x3P9shmHgs9=MMu0uQbAFQdBNSm9VfUCaZvVCQgA@mail.gmail.com>

Phil,

thank you for answering three months later. That is fine, I'd like to
distill from our conversation some upgrade notes from Cuis Morphic 4.0
to Cuis Morphic 4.2.

I created an issue for this for the documentation of Cuis

   https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/65

Quite a number of issues are piled up there and I want to work on them
in batch mode in one go sometime in the upcoming months.

So if this thread goes to sleep for three more months I do not have
any problem with it ...

:-)


The documentation of course is related to the issue of having release
version numbers you can refer to.


Ideally we have release notes from time to time which list the changes
and test reports which packages work with which release.

--Hannes

On 7/6/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote:
>> Hannes,
>>
>> Sorry for the delay... it's taken me longer than expected to get back to
>> it.  I really don't have any simple examples of porting as my stuff is
>> fairly involved (i.e. drawing and keyboard handling as part of a larger
>> OpenGL project etc.)  However, I do have more specifics re: what needed
>> to be done.
>>
> <snip>
>>
>> Keyboard focus handling
>>
>
> One additional thing related to keyboard focus that should probably be
> handled by Morphic: various mouse (mouse wheel) and trackpad (gesture)
> events get sent as keyboard events and should probably be (at least
> optionally?) intercepted from the event stream and sent as distinct
> events such as #scroll: etc.  No idea how multi-finger touch screen
> gestures are handled by the VM these days but that is yet something else
> to think about...
>
>>
>> Thanks,
>> Phil
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Mon Jul  6 10:04:05 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 6 Jul 2015 15:04:05 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <55993940.8090704@jvuletich.org>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
	<55993940.8090704@jvuletich.org>
Message-ID: <CAGQxfVhAxbOCLaztuYifqRR-9rFgHThVF6C5pz5nw1OBXdOiTQ@mail.gmail.com>

On 7/5/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Hannes,
>
> Sure, let's discuss this. What do other people maintaining external
> packages think? This is for you...


Thank you. I think the issue is that the 50 or so commits in the first
six months of this year needed to be grouped into larger chunks,
called minor released.

I understand that in github a release is just a tab on a particular
commit, i.e. they may be still be added.

And the most straightforward thing is to continue numbering with where
you left off before moving to github.

It should be easy for people to check out a particular release of the past.

This in particular as many months might pass between work on Cuis for
a particular project.


>
> Cheers,
> Juan Vuletich
>
> On 04/07/2015 08:45 p.m., H. Hirzel wrote:
>> Juan,
>>
>> And this brings up the question that it would be good to have a
>> 'release tag' from time to time.
>>
>> So that releases show up here
>>
>>      https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases
>>
>> Currently there are 0 releases. This is very straightforward to do in
>> github.
>>
>> This will facilitate checking if external packages still run fine.
>> There are about 50 commits in
>> Cuis-Smalltalk-Dev in first two quaters of 2015.
>>
>> I think I some minor releases (i.e. 2 ... 6 a year) would be fine.
>>
>> Thanks for considering this
>>
>> --Hannes
>>
>> On 7/4/15, Ken.Dickey<Ken.Dickey at whidbey.com>  wrote:
>>> Juan,
>>>
>>> The Installed Packages browser used to be able to require a minimum
>>> revision
>>> on the base release.
>>>
>>> I use this feature as a backstop when features change in the base
>>> release.
>>>
>>> Any chance in getting this ability back?
>>>
>>> Thanks much,
>>> -KenD
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>
>



From dnorton at mindspring.com  Mon Jul  6 10:37:06 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 06 Jul 2015 11:37:06 -0400
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <559A83A3.5040406@jvuletich.org>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>,
	<559A83A3.5040406@jvuletich.org>
Message-ID: <559AA0A2.13962.3B4CD8@dnorton.mindspring.com>

On 6 Jul 2015 at 10:33, Juan Vuletich wrote:

> Hi Dan,
> 
> On 7/5/2015 8:35 PM, Dan Norton wrote:
> > Greetings,
> >
> > Four LayoutSpec class methods use "minorDirectionPadding:" as a
> keyword. The parameter
> > can be a number or one of: #top, #left, #center, #right, or
> #bottom. AFAICT when the
> > parameter is a number, it refers to the padding which will be
> applied in the minor direction.
> > When it is a symbol, it effectively specifies that morphs will be
> located as the symbol name
> > implies.
> >
> > Attached are four convenience methods whose keyword emphasizes the
> visible (morph)
> > instead of the invisible (padding). The "morphPlacement:"
> parameter can be  #top, #left,
> > #center, #right, or #bottom. The methods are:
> >
> > LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
> > LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
> > LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
> > LayoutSpec
> class>>proportionalWidth:proportionalHeight:morphPlacement:
> >
> > Are these worth having in the base system?
> >
> >   - Dan
> >
> 
> I'd rather replace the keyword 'minorDirectionPadding:' by 
> 'minorDirectionPlacement:' to:
> - Avoid ambiguity
> - Avoid duplication
> 
OK, as far as the duplication, but I don't see "morphPlacement:" in use. Where does the 
ambiguity occur?

 - Dan



From dnorton at mindspring.com  Mon Jul  6 10:49:46 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 06 Jul 2015 11:49:46 -0400
Subject: [Cuis] Cuis Archive
Message-ID: <559AA39A.19585.46E7C0@dnorton.mindspring.com>

Hi,

There is nothing in the archive for July. Anybody else experiencing this?

 - Dan



From dnorton at mindspring.com  Mon Jul  6 21:05:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 06 Jul 2015 22:05:22 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <1435889021.2309.200.camel@gmail.com>
References: <1435576183.2309.69.camel@gmail.com>,
	<5595E22F.2684.23EA964@dnorton.mindspring.com>,
	<1435889021.2309.200.camel@gmail.com>
Message-ID: <559B33E2.1296.27A7F1A@dnorton.mindspring.com>

On 2 Jul 2015 at 22:03, Phil (list) wrote:

> You're probably trying one of the download links.  You can stream
> the
> video as long as JavaScript is enabled.  If you can't temporarily
> do
> this in IE, I'd highly recommend keeping Firefox+NoScript around as
> it
> lets you temporarily enable JavaScript & cookies for this type of
> scenario.
> [...]

Thanks, Phil. That's better.

 - Dan




From pbpublist at gmail.com  Mon Jul  6 22:03:26 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 06 Jul 2015 23:03:26 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <CAGQxfVgb34x3P9shmHgs9=MMu0uQbAFQdBNSm9VfUCaZvVCQgA@mail.gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
	<1436169716.2678.46.camel@gmail.com>
	<1436170359.2678.52.camel@gmail.com>
	<CAGQxfVgb34x3P9shmHgs9=MMu0uQbAFQdBNSm9VfUCaZvVCQgA@mail.gmail.com>
Message-ID: <1436238206.2678.107.camel@gmail.com>

On Mon, 2015-07-06 at 15:00 +0000, H. Hirzel wrote:
> Phil,
> 
> thank you for answering three months later. That is fine, I'd like to
> distill from our conversation some upgrade notes from Cuis Morphic 4.0
> to Cuis Morphic 4.2.
> 

Apologies for taking so long... I figured better late than never.

> I created an issue for this for the documentation of Cuis
> 
>    https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/65
> 
> Quite a number of issues are piled up there and I want to work on them
> in batch mode in one go sometime in the upcoming months.
> 
> So if this thread goes to sleep for three more months I do not have
> any problem with it ...
> 
> :-)
> 

I'll try to stop being such a troublemaker... (promises, promises :-)

> 
> The documentation of course is related to the issue of having release
> version numbers you can refer to.
> 

Ah, now I understand why you're asking for version #'s/tags/something.

> 
> Ideally we have release notes from time to time which list the changes
> and test reports which packages work with which release.
> 

The reporting part sounds like Continuous Integration testing to me...

> --Hannes
> 
> On 7/6/15, Phil (list) <pbpublist at gmail.com> wrote:
> > On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote:
> >> Hannes,
> >>
> >> Sorry for the delay... it's taken me longer than expected to get back to
> >> it.  I really don't have any simple examples of porting as my stuff is
> >> fairly involved (i.e. drawing and keyboard handling as part of a larger
> >> OpenGL project etc.)  However, I do have more specifics re: what needed
> >> to be done.
> >>
> > <snip>
> >>
> >> Keyboard focus handling
> >>
> >
> > One additional thing related to keyboard focus that should probably be
> > handled by Morphic: various mouse (mouse wheel) and trackpad (gesture)
> > events get sent as keyboard events and should probably be (at least
> > optionally?) intercepted from the event stream and sent as distinct
> > events such as #scroll: etc.  No idea how multi-finger touch screen
> > gestures are handled by the VM these days but that is yet something else
> > to think about...
> >
> >>
> >> Thanks,
> >> Phil
> >
> >
> >
> > _______________________________________________
> > 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 pbpublist at gmail.com  Tue Jul  7 01:59:59 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 07 Jul 2015 02:59:59 -0400
Subject: [Cuis] MNU bug with halo in world
Message-ID: <1436252399.2678.117.camel@gmail.com>

Juan,

In an empty area in the world, middle click to bring up a halo for the
world PasteUpMorph.  Middle click again... MNU.

Thanks,
Phil




From hannes.hirzel at gmail.com  Tue Jul  7 06:22:43 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 7 Jul 2015 11:22:43 +0000
Subject: [Cuis] Status of continuous integration testing // release numbers
	to refer to?
Message-ID: <CAGQxfVie+JNw0R3rEXN4-WuUUWc8AS-Pa3k3u42A+A=fFvmibA@mail.gmail.com>

On 7/7/15, Phil (list) <pbpublist at gmail.com> wrote:
....
>
> The documentation of course is related to the issue of having release
> version numbers you can refer to.
>

Ah, now I understand why you're asking for version #'s/tags/something.
..

>> Ideally we have release notes from time to time which list the changes
>> and test reports which packages work with which release.
>>
>
> The reporting part sounds like Continuous Integration testing to me...
>

Hello Juan

You recently had a note to the ML that you are doing integration
testing before each of your releases which are announced on the
mailing list with an 'update' mail.

I understand that you are loading all packages in

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Packages

and run the tests there in addition to the tests built into Cuis core.

Is this so?

Do you produce a log file of the results which might be archived as
well in the repository?

Kind regards

Hannes



From hannes.hirzel at gmail.com  Tue Jul  7 07:06:48 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 7 Jul 2015 12:06:48 +0000
Subject: [Cuis] MNU bug with halo in world
In-Reply-To: <1436252399.2678.117.camel@gmail.com>
References: <1436252399.2678.117.camel@gmail.com>
Message-ID: <CAGQxfViw8_6ow6LGpAG8SkFfkYgh5_P2aZqzDeCNAKqfsLFk8A@mail.gmail.com>

Added to issues

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/66

--HH

On 7/7/15, Phil (list) <pbpublist at gmail.com> wrote:
> Juan,
>
> In an empty area in the world, middle click to bring up a halo for the
> world PasteUpMorph.  Middle click again... MNU.
>
> Thanks,
> Phil
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From Ken.Dickey at whidbey.com  Tue Jul  7 08:04:18 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 7 Jul 2015 06:04:18 -0700
Subject: [Cuis] MorphIt -- toward direct authoring with media
Message-ID: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>

Greetings all,

I have put some pre-Alpha proof-of-concept code in BabySteps

	https://github.com/KenDickey/Cuis-Smalltalk-BabySteps

The package is called MorphIt, the gist being drag-n-drop prototype style modification of Morphs with a general goal of multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..

As some of you may know, my style is to have a bunch of half baked ideas roiling around in my head which I tend to think through by writing code.  

Very early days yet, but anyone with time on their hands can see what works and what doesn't.  The README.md has some notes on directions.

Cheers, 
-KenD

================
When Michael Faraday first demonstrated electromagnetic induction, the Prime Minister asked, ?Of what use is this discovery, Mr. Faraday?? Faraday replied, ?Of what use is a baby, Mr. Prime Minister??



From dnorton at mindspring.com  Tue Jul  7 12:05:17 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 07 Jul 2015 13:05:17 -0400
Subject: [Cuis] Loop during StrikeFont install:
Message-ID: <559C06CD.15379.DC94F3@dnorton.mindspring.com>

To cause this loop:

In directory "Cuis-Smalltalk-Dev-master" have no "AAFonts" directory.
Do (cmd-d) StrikeFont install: 'Optima'
Get a loop instead of "File does not exist" exception.

 - Dan



From pbpublist at gmail.com  Tue Jul  7 16:57:40 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 07 Jul 2015 17:57:40 -0400
Subject: [Cuis] OpenGL questions
Message-ID: <1436306260.2678.148.camel@gmail.com>

Just wanted to see if anyone other than me is currently using my OpenGL
port at https://github.com/pbella/Cuis-Ports?  I ask because what is
currently there is from some old Squeak/Croquet code that only supported
OpenGL 1.x (1.3, I believe) and I'm getting ready to update it but will
need to break some things no matter how I decide to do it (i.e. related
to the next question)

Does anyone care about the 'full' OpenGL API anymore?  My general sense
is that unless one is a developer of CAD software or high-end video game
engines, the full/desktop API doesn't add much value esp. given how
limiting it is in terms of portability.  As recent releases of OpenGL
are supersets of OpenGL ES, I'm thinking of just supporting ES and that
way both desktop and mobile devices can be targeted with the same code
and have a much smaller API to deal with.  However, if anyone has a
burning need for a non-ES flavor, now would be the time to speak up.

Thanks,
Phil




From Ken.Dickey at whidbey.com  Tue Jul  7 02:52:26 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 7 Jul 2015 15:52:26 +0800
Subject: [Cuis] OpenGL questions
In-Reply-To: <1436306260.2678.148.camel@gmail.com>
References: <1436306260.2678.148.camel@gmail.com>
Message-ID: <20150707155226.9877626cbfa5f046b51073c8@whidbey.com>

On Tue, 07 Jul 2015 17:57:40 -0400
"Phil (list)" <pbpublist at gmail.com> wrote:

> Just wanted to see if anyone other than me is currently using my OpenGL
> port at https://github.com/pbella/Cuis-Ports? 

Not me (so far).

ES would be great!

-KenD



From juan at jvuletich.org  Wed Jul  8 09:33:04 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 08 Jul 2015 11:33:04 -0300
Subject: [Cuis] Status of continuous integration testing // release
 numbers to refer to?
In-Reply-To: <CAGQxfVie+JNw0R3rEXN4-WuUUWc8AS-Pa3k3u42A+A=fFvmibA@mail.gmail.com>
References: <CAGQxfVie+JNw0R3rEXN4-WuUUWc8AS-Pa3k3u42A+A=fFvmibA@mail.gmail.com>
Message-ID: <559D34A0.5080102@jvuletich.org>

Hi Hannes,

On 7/7/2015 8:22 AM, H. Hirzel wrote:
> Hello Juan
>
> You recently had a note to the ML that you are doing integration
> testing before each of your releases which are announced on the
> mailing list with an 'update' mail.

Yes, I do that before pushing to github, almost every time.

> I understand that you are loading all packages in
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Packages
>
> and run the tests there in addition to the tests built into Cuis core.
>
> Is this so?

Yes.

> Do you produce a log file of the results which might be archived as
> well in the repository?

Well, recently I did SUnit XML reports.pck.st, so it is not a big deal 
to do it. I'll try to remember. Please nag me if I forget about it.

> Kind regards
>
> Hannes

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  8 09:34:20 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 08 Jul 2015 11:34:20 -0300
Subject: [Cuis] MNU bug with halo in world
In-Reply-To: <1436252399.2678.117.camel@gmail.com>
References: <1436252399.2678.117.camel@gmail.com>
Message-ID: <559D34EC.4000608@jvuletich.org>

On 7/7/2015 3:59 AM, Phil (list) wrote:
> Juan,
>
> In an empty area in the world, middle click to bring up a halo for the
> world PasteUpMorph.  Middle click again... MNU.
>
> Thanks,
> Phil
>

Thanks for reporting! I have the fix, and it will be in the next commit 
I do.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  8 09:37:15 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 08 Jul 2015 11:37:15 -0300
Subject: [Cuis] OpenGL questions
In-Reply-To: <1436306260.2678.148.camel@gmail.com>
References: <1436306260.2678.148.camel@gmail.com>
Message-ID: <559D359B.9090607@jvuletich.org>

Hi Phil,

I'm not using it, but it is a very nice to have it. I'd say, stick to 
the subset that makes most sense for you. Very few people could need the 
full OpenGL api. ES sounds very reasonable to me.

Cheers,
Juan Vuletich

On 7/7/2015 6:57 PM, Phil (list) wrote:
> Just wanted to see if anyone other than me is currently using my OpenGL
> port at https://github.com/pbella/Cuis-Ports?  I ask because what is
> currently there is from some old Squeak/Croquet code that only supported
> OpenGL 1.x (1.3, I believe) and I'm getting ready to update it but will
> need to break some things no matter how I decide to do it (i.e. related
> to the next question)
>
> Does anyone care about the 'full' OpenGL API anymore?  My general sense
> is that unless one is a developer of CAD software or high-end video game
> engines, the full/desktop API doesn't add much value esp. given how
> limiting it is in terms of portability.  As recent releases of OpenGL
> are supersets of OpenGL ES, I'm thinking of just supporting ES and that
> way both desktop and mobile devices can be targeted with the same code
> and have a much smaller API to deal with.  However, if anyone has a
> burning need for a non-ES flavor, now would be the time to speak up.
>
> Thanks,
> Phil
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From dnorton at mindspring.com  Wed Jul  8 18:44:53 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 08 Jul 2015 19:44:53 -0400
Subject: [Cuis] #browseVersions Key not Found
Message-ID: <559DB5F5.25858.20175F4@dnorton.mindspring.com>

>From a browser, the versions button works as it should.

However, from a ProtocolBrowser, if the message is from a superclass a "key not found" 
error occurs. 

Versions of messages belonging to the class being "protocol browsed" are listed as they 
should be.

 - Dan



From dnorton at mindspring.com  Wed Jul  8 19:03:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 08 Jul 2015 20:03:07 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <559DBA3B.28326.21224C9@dnorton.mindspring.com>

For my PluggableListMorph, the model prepares list elements on a "String new writeStream." 
They are not static. I need for these list elements to be aligned in columns like a small 
spreadsheet. A fixed font would be handy - how can I install one?

Any other approaches to get columns in a list?

 - Dan



From pbpublist at gmail.com  Thu Jul  9 04:15:37 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 09 Jul 2015 05:15:37 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
Message-ID: <1436433337.2325.6.camel@gmail.com>

This is a minor nit but when I'm developing Morphs I often need to
instantiate them manually via something like 'MorphName new
openInWorld.'  When I do that, I almost always find its initial position
annoying and in some cases nearly non-functional since the Morph doesn't
have room for its halo icons.  Just wondering if this bothers anyone
else and if maybe insetting new morphs top left by default to something
like 50 @ 50 (something out of the way, but giving it a bit of margin
from the edge of the screen) might be better?




From hannes.hirzel at gmail.com  Thu Jul  9 05:43:42 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 9 Jul 2015 10:43:42 +0000
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
Message-ID: <CAGQxfVhNEnergmoFZJtyENR7nGLKSgWsPGR5z+o83pzV9TfS7A@mail.gmail.com>

+1

On 7/9/15, Phil (list) <pbpublist at gmail.com> wrote:
> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial position
> annoying and in some cases nearly non-functional since the Morph doesn't
> have room for its halo icons.  Just wondering if this bothers anyone
> else and if maybe insetting new morphs top left by default to something
> like 50 @ 50 (something out of the way, but giving it a bit of margin
> from the edge of the screen) might be better?
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Thu Jul  9 09:49:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 09 Jul 2015 10:49:07 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
Message-ID: <559E89E3.19425.2863A2@dnorton.mindspring.com>

On 9 Jul 2015 at 5:15, Phil (list) wrote:

> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial
> position
> annoying and in some cases nearly non-functional since the Morph
> doesn't
> have room for its halo icons.  Just wondering if this bothers
> anyone
> else and if maybe insetting new morphs top left by default to
> something
> like 50 @ 50 (something out of the way, but giving it a bit of
> margin
> from the edge of the screen) might be better?
> 

+1

Also, it's pretty dark up there and the black on blue MinimalStringMorph is hard to see, for 
example.

 - Dan



From sean at clipperadams.com  Thu Jul  9 09:43:55 2015
From: sean at clipperadams.com (Sean P. DeNigris)
Date: Thu, 9 Jul 2015 07:43:55 -0700 (PDT)
Subject: [Cuis] MorphIt -- toward direct authoring with media
In-Reply-To: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
References: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
Message-ID: <1436453035366-4836792.post@n4.nabble.com>

Ken.Dickey wrote
> drag-n-drop prototype style modification of Morphs with a general goal of
> multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..

Sounds fantastic!



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/MorphIt-toward-direct-authoring-with-media-tp4836232p4836792.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From casey.obrien.r at gmail.com  Thu Jul  9 21:05:20 2015
From: casey.obrien.r at gmail.com (Casey Ransberger)
Date: Thu, 9 Jul 2015 19:05:20 -0700
Subject: [Cuis] MorphIt -- toward direct authoring with media
In-Reply-To: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
References: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
Message-ID: <A420D093-D868-490D-AC79-3DDED1561178@gmail.com>

Hey Ken,

Woot! I was working on something that did this but got distracted by a shiny robot before it got close to working. 

I've wanted to see Self-style authoring in Cuis ever since I realized that I liked working with Cuis better than the other distributions. It was the one thing I really enjoyed in Squeak that we're really missing in Cuisland. 

If we can throw in some HyperCard and... what is that thing from Self? Little tool to zero in on a Morph and then inspect it? Anyway, that thing. Would be just amazingly awesome. 

--C

> On Jul 7, 2015, at 6:04 AM, "Ken.Dickey" <Ken.Dickey at whidbey.com> wrote:
> 
> Greetings all,
> 
> I have put some pre-Alpha proof-of-concept code in BabySteps
> 
>    https://github.com/KenDickey/Cuis-Smalltalk-BabySteps
> 
> The package is called MorphIt, the gist being drag-n-drop prototype style modification of Morphs with a general goal of multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..
> 
> As some of you may know, my style is to have a bunch of half baked ideas roiling around in my head which I tend to think through by writing code.  
> 
> Very early days yet, but anyone with time on their hands can see what works and what doesn't.  The README.md has some notes on directions.
> 
> Cheers, 
> -KenD
> 
> ================
> When Michael Faraday first demonstrated electromagnetic induction, the Prime Minister asked, ?Of what use is this discovery, Mr. Faraday?? Faraday replied, ?Of what use is a baby, Mr. Prime Minister??
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



From casey.obrien.r at gmail.com  Thu Jul  9 21:11:24 2015
From: casey.obrien.r at gmail.com (Casey Ransberger)
Date: Thu, 9 Jul 2015 19:11:24 -0700
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
Message-ID: <D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>

I want this too. What needs to be done is to make a StrikeFont, IIRC. I didn't get a round toit. If anyone has an extra round toit that I can borrow, I'd be very appreciative. 

Anyway I think if you look around at the class StrikeFont, you'll find a trailhead or rabbit hole that you can follow toward how to #doIt.

Someone correct me if I'm wrong.

--C

> On Jul 8, 2015, at 5:03 PM, "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> For my PluggableListMorph, the model prepares list elements on a "String new writeStream." 
> They are not static. I need for these list elements to be aligned in columns like a small 
> spreadsheet. A fixed font would be handy - how can I install one?
> 
> Any other approaches to get columns in a list?
> 
> - Dan
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



From dnorton at mindspring.com  Fri Jul 10 09:20:45 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 10 Jul 2015 10:20:45 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
Message-ID: <559FD4BD.26551.31649C@dnorton.mindspring.com>

On 9 Jul 2015 at 19:11, Casey Ransberger wrote:

> I want this too. What needs to be done is to make a StrikeFont,
> IIRC. I didn't get a round toit. If anyone has an extra round toit
> that I can borrow, I'd be very appreciative. 
> 
Thought I had one... must be around here somewhere... :(

> Anyway I think if you look around at the class StrikeFont, you'll
> find a trailhead or rabbit hole that you can follow toward how to
> #doIt.
> 
Browsing through strike fonts, I see no fixed widths. But, true type fonts have a few 
fixed-width examples. There seems to be no way to install a .ttf in Cuis currently.

Can we port TrueType-Support from Squeak?

Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits from AbstractFont?

Any hints or guidance would be most welcomed.

> Someone correct me if I'm wrong.
> 
> --C
> 
> > On Jul 8, 2015, at 5:03 PM, "Dan Norton" <dnorton at mindspring.com>
> wrote:
> > 
> > For my PluggableListMorph, the model prepares list elements on a
> "String new writeStream." 
> > They are not static. I need for these list elements to be aligned
> in columns like a small 
> > spreadsheet. A fixed font would be handy - how can I install
> one?
> > 
> > Any other approaches to get columns in a list?
> > 
> > - Dan
> > 
> > _______________________________________________
> > 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

 - Dan




From pbpublist at gmail.com  Fri Jul 10 12:29:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 10 Jul 2015 13:29:01 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559FD4BD.26551.31649C@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	, <D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
Message-ID: <1436549341.2325.3.camel@gmail.com>

On Fri, 2015-07-10 at 10:20 -0400, Dan Norton wrote:
> On 9 Jul 2015 at 19:11, Casey Ransberger wrote:
> 
> > I want this too. What needs to be done is to make a StrikeFont,
> > IIRC. I didn't get a round toit. If anyone has an extra round toit
> > that I can borrow, I'd be very appreciative. 
> > 
> Thought I had one... must be around here somewhere... :(
> 
> > Anyway I think if you look around at the class StrikeFont, you'll
> > find a trailhead or rabbit hole that you can follow toward how to
> > #doIt.
> > 
> Browsing through strike fonts, I see no fixed widths. But, true type fonts have a few 
> fixed-width examples. There seems to be no way to install a .ttf in Cuis currently.
> 
> Can we port TrueType-Support from Squeak?
> 
> Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits from AbstractFont?
> 
> Any hints or guidance would be most welcomed.

I'd like a fixed-width font as well but I suspect that this is one of
the areas it might be better to wait until Morphic 3 on (i.e. isn't the
existing font support based on bitmap fonts rather than vector?)

> 
> > Someone correct me if I'm wrong.
> > 
> > --C
> > 
> > > On Jul 8, 2015, at 5:03 PM, "Dan Norton" <dnorton at mindspring.com>
> > wrote:
> > > 
> > > For my PluggableListMorph, the model prepares list elements on a
> > "String new writeStream." 
> > > They are not static. I need for these list elements to be aligned
> > in columns like a small 
> > > spreadsheet. A fixed font would be handy - how can I install
> > one?
> > > 
> > > Any other approaches to get columns in a list?
> > > 
> > > - Dan
> > > 
> > > _______________________________________________
> > > 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
> 
>  - Dan
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Fri Jul 10 14:05:50 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 10 Jul 2015 15:05:50 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <1436549341.2325.3.camel@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<559FD4BD.26551.31649C@dnorton.mindspring.com>,
	<1436549341.2325.3.camel@gmail.com>
Message-ID: <55A0178E.16257.13666A4@dnorton.mindspring.com>

On 10 Jul 2015 at 13:29, Phil (list) wrote:

> On Fri, 2015-07-10 at 10:20 -0400, Dan Norton wrote:
> > On 9 Jul 2015 at 19:11, Casey Ransberger wrote:
> > 
> > > I want this too. What needs to be done is to make a
> StrikeFont,
> > > IIRC. I didn't get a round toit. If anyone has an extra round
> toit
> > > that I can borrow, I'd be very appreciative. 
> > > 
> > Thought I had one... must be around here somewhere... :(
> > 
> > > Anyway I think if you look around at the class StrikeFont,
> you'll
> > > find a trailhead or rabbit hole that you can follow toward how
> to
> > > #doIt.
> > > 
> > Browsing through strike fonts, I see no fixed widths. But, true
> type fonts have a few 
> > fixed-width examples. There seems to be no way to install a .ttf
> in Cuis currently.
> > 
> > Can we port TrueType-Support from Squeak?
> > 
> > Should there be a sibling of StrikeFont, say TrueTypeFont, which
> inherits from AbstractFont?
> > 
> > Any hints or guidance would be most welcomed.
> 
> I'd like a fixed-width font as well but I suspect that this is one
> of
> the areas it might be better to wait until Morphic 3 on (i.e. isn't
> the
> existing font support based on bitmap fonts rather than vector?)
>

Yes, the only font now is DejaVu and it's a bitmap font. I found some fixed bitmap fonts 
among the true types at:

http://www.lowing.org/fonts/

Adding a sublcass to AbstractFont to load one of these might be doable near-term until 
Morphic 3 comes along. Porting TrueType from Squeak has a lot of drag.

> > 
> > > Someone correct me if I'm wrong.
> > > 
> > > --C
> > > 
> > > > On Jul 8, 2015, at 5:03 PM, "Dan Norton"
> <dnorton at mindspring.com>
> > > wrote:
> > > > 
> > > > For my PluggableListMorph, the model prepares list elements on
> a
> > > "String new writeStream." 
> > > > They are not static. I need for these list elements to be
> aligned
> > > in columns like a small 
> > > > spreadsheet. A fixed font would be handy - how can I install
> > > one?
> > > > 
> > > > Any other approaches to get columns in a list?
> > > > 
> > > > - Dan
> > > > 
> > > > _______________________________________________
> > > > 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
> > 
> >  - Dan
> > 
> > 
> > _______________________________________________
> > 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 Ken.Dickey at whidbey.com  Fri Jul 10 03:51:44 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 10 Jul 2015 16:51:44 +0800
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A0178E.16257.13666A4@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
Message-ID: <20150710165144.ece0f54787132fed1278bdc4@whidbey.com>

On Fri, 10 Jul 2015 15:05:50 -0400
"Dan Norton" <dnorton at mindspring.com> wrote:

> Yes, the only font now is DejaVu and it's a bitmap font. I found some fixed bitmap fonts 
> among the true types at:
> 
> http://www.lowing.org/fonts/
> 
> Adding a sublcass to AbstractFont to load one of these might be doable near-term until 
> Morphic 3 comes along. Porting TrueType from Squeak has a lot of drag.

My Cuis-Smalltalk-Unicode package subclasses AbstractFont and provides fixed width characters.

See class #UniForms 

Unicode is kinda big, memory wise.  I suspect one should be able to take the ASCII subset of the Unicode glyphs and make a strike font -- or just do what I did for Unicode, but just use the ASCII subset.

FYI,
-KenD



From juan at jvuletich.org  Sat Jul 11 11:11:04 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:11:04 -0300
Subject: [Cuis] #browseVersions Key not Found
In-Reply-To: <559DB5F5.25858.20175F4@dnorton.mindspring.com>
References: <559DB5F5.25858.20175F4@dnorton.mindspring.com>
Message-ID: <55A14018.1050602@jvuletich.org>

On 7/8/2015 8:44 PM, Dan Norton wrote:
> > From a browser, the versions button works as it should.
>
> However, from a ProtocolBrowser, if the message is from a superclass a "key not found"
> error occurs.
>
> Versions of messages belonging to the class being "protocol browsed" are listed as they
> should be.
>
>   - Dan

Oh! Thanks for the report.

This turned out to be a little pandora box. Lots of broken code, unused 
/ incosistent ivars, and the like in ProtocolBrowser and 
TimeProfileBrowser. Setting all this straight is taking a little bit 
longer than expected. But I hope to do a commit with these tools working 
substantially better this weekend. I'm also removing quite a bit of code...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 11:40:28 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:40:28 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
Message-ID: <55A146FC.4020402@jvuletich.org>

Hi Folks,

It is not too hard to build new StrikeFonts. You need to build, by hand, 
files like the ones in here: 
https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zip 
and learn a bit about stuff like #installDejaVu2 . Maybe it was with 
this method and the files in this zip that built the existing instances 
of StrikeFont. Not sure.

I think DejaVu Sans Mono would be a great addition, and would look well 
to the existing DejaVu Sans.

In any case, don't be afraid, and play with the stuff. It is there so 
you can do it.

BTW, yesterday I learnt about https://github.com/tonsky/FiraCode . I 
think it is wonderful. We can't just adopt it, as we don't have 
ligatures. But maybe some time, Morphic 3 could be made to use it.

Cheers,
Juan vuletich

On 7/8/2015 9:03 PM, Dan Norton wrote:
> For my PluggableListMorph, the model prepares list elements on a "String new writeStream."
> They are not static. I need for these list elements to be aligned in columns like a small
> spreadsheet. A fixed font would be handy - how can I install one?
>
> Any other approaches to get columns in a list?
>
>   - Dan




From juan at jvuletich.org  Sat Jul 11 11:42:05 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:42:05 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559FD4BD.26551.31649C@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
Message-ID: <55A1475D.3030501@jvuletich.org>

On 7/10/2015 11:20 AM, Dan Norton wrote:
> ...
> Browsing through strike fonts, I see no fixed widths. But, true type fonts have a few
> fixed-width examples. There seems to be no way to install a .ttf in Cuis currently.
>
> Can we port TrueType-Support from Squeak?
>
> Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits from AbstractFont?
>
> Any hints or guidance would be most welcomed.
>

I'd say, stick to StrikeFonts, and learn to build new ones. I the other 
message I just sent, I included more details.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 11:46:17 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:46:17 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A0178E.16257.13666A4@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<559FD4BD.26551.31649C@dnorton.mindspring.com>,
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
Message-ID: <55A14859.2080409@jvuletich.org>

On 7/10/2015 4:05 PM, Dan Norton wrote:
> ...
> Yes, the only font now is DejaVu and it's a bitmap font. I found some fixed bitmap fonts
> among the true types at:
>
> http://www.lowing.org/fonts/
>
> Adding a sublcass to AbstractFont to load one of these might be doable near-term until
> Morphic 3 comes along. Porting TrueType from Squeak has a lot of drag.
>

ProFontWindows doesn't look bad. In any case, I built the Bitmap DejaVu 
fonts in Cuis (and Squeak and Pharo) by capturing the bits from the 
screen of a text editor, running the TTF. You can do the same with 
DejaVu Sans Mono or any other TTF / OTF / whatever.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 12:27:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 14:27:01 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
Message-ID: <55A151E5.5060409@jvuletich.org>

On 7/9/2015 6:15 AM, Phil (list) wrote:
> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial position
> annoying and in some cases nearly non-functional since the Morph doesn't
> have room for its halo icons.  Just wondering if this bothers anyone
> else and if maybe insetting new morphs top left by default to something
> like 50 @ 50 (something out of the way, but giving it a bit of margin
> from the edge of the screen) might be better?

Sure. Will be there in the next commit.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 12:29:39 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 14:29:39 -0300
Subject: [Cuis] MorphIt -- toward direct authoring with media
In-Reply-To: <A420D093-D868-490D-AC79-3DDED1561178@gmail.com>
References: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
	<A420D093-D868-490D-AC79-3DDED1561178@gmail.com>
Message-ID: <55A15283.8050104@jvuletich.org>

Hi Folks,

I agree with you. I think it will be great to make Cuis good at that! 
(While keeping the cleanness of the code and the design, of course).

Cheers,
Juan Vuletich

On 7/9/2015 11:05 PM, Casey Ransberger wrote:
> Hey Ken,
>
> Woot! I was working on something that did this but got distracted by a shiny robot before it got close to working.
>
> I've wanted to see Self-style authoring in Cuis ever since I realized that I liked working with Cuis better than the other distributions. It was the one thing I really enjoyed in Squeak that we're really missing in Cuisland.
>
> If we can throw in some HyperCard and... what is that thing from Self? Little tool to zero in on a Morph and then inspect it? Anyway, that thing. Would be just amazingly awesome.
>
> --C
>
>> On Jul 7, 2015, at 6:04 AM, "Ken.Dickey"<Ken.Dickey at whidbey.com>  wrote:
>>
>> Greetings all,
>>
>> I have put some pre-Alpha proof-of-concept code in BabySteps
>>
>>     https://github.com/KenDickey/Cuis-Smalltalk-BabySteps
>>
>> The package is called MorphIt, the gist being drag-n-drop prototype style modification of Morphs with a general goal of multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..
>>
>> As some of you may know, my style is to have a bunch of half baked ideas roiling around in my head which I tend to think through by writing code.
>>
>> Very early days yet, but anyone with time on their hands can see what works and what doesn't.  The README.md has some notes on directions.
>>
>> Cheers,
>> -KenD




From juan at jvuletich.org  Sat Jul 11 12:31:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 14:31:27 -0300
Subject: [Cuis] Loop during StrikeFont install:
In-Reply-To: <559C06CD.15379.DC94F3@dnorton.mindspring.com>
References: <559C06CD.15379.DC94F3@dnorton.mindspring.com>
Message-ID: <55A152EF.1030801@jvuletich.org>

Hi Dan,

It looks like you'll be playing a bit with building a good monospaced 
font, right? While you are at it, please send to the mail list any fixes 
you'll for sure be doing in this area...

Thanks,
Juan Vuletich

On 7/7/2015 2:05 PM, Dan Norton wrote:
> To cause this loop:
>
> In directory "Cuis-Smalltalk-Dev-master" have no "AAFonts" directory.
> Do (cmd-d) StrikeFont install: 'Optima'
> Get a loop instead of "File does not exist" exception.
>
>   - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From edgardec2005 at gmail.com  Sat Jul 11 15:24:20 2015
From: edgardec2005 at gmail.com (Edgar J De Cleene)
Date: Sat, 11 Jul 2015 17:24:20 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <55A146FC.4020402@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
Message-ID: <6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>

Quoting Casey

> If we can throw in some HyperCard and... 

A long time algo wish Squeak could read HyperCard stacks.
If Cuis could do this , bet we have thousands users.
Anyway whats the HyperCard status ?
 
Env?ado desde Edgar's iPad mini



> El 11/7/2015, a las 13:40, Juan Vuletich <juan at jvuletich.org> escribi?:
> 
> Hi Folks,
> 
> It is not too hard to build new StrikeFonts. You need to build, by hand, files like the ones in here: https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zip and learn a bit about stuff like #installDejaVu2 . Maybe it was with this method and the files in this zip that built the existing instances of StrikeFont. Not sure.
> 
> I think DejaVu Sans Mono would be a great addition, and would look well to the existing DejaVu Sans.
> 
> In any case, don't be afraid, and play with the stuff. It is there so you can do it.
> 
> BTW, yesterday I learnt about https://github.com/tonsky/FiraCode . I think it is wonderful. We can't just adopt it, as we don't have ligatures. But maybe some time, Morphic 3 could be made to use it.
> 
> Cheers,
> Juan vuletich
> 
>> On 7/8/2015 9:03 PM, Dan Norton wrote:
>> For my PluggableListMorph, the model prepares list elements on a "String new writeStream."
>> They are not static. I need for these list elements to be aligned in columns like a small
>> spreadsheet. A fixed font would be handy - how can I install one?
>> 
>> Any other approaches to get columns in a list?
>> 
>>  - 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/20150711/224e60c8/attachment-0002.html>

From edgardec2005 at gmail.com  Sun Jul 12 04:21:11 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sun, 12 Jul 2015 06:21:11 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
Message-ID: <D1C7B7D7.159F8%edgardec2005@gmail.com>




On 7/9/15, 6:15 AM, "Phil (list)" <pbpublist at gmail.com> wrote:

> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial position
> annoying and in some cases nearly non-functional since the Morph doesn't
> have room for its halo icons.  Just wondering if this bothers anyone
> else and if maybe insetting new morphs top left by default to something
> like 50 @ 50 (something out of the way, but giving it a bit of margin
> from the edge of the screen) might be better?


Morph new openInHand could be better?

Edgar





From pbpublist at gmail.com  Sun Jul 12 12:16:15 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 12 Jul 2015 13:16:15 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <D1C7B7D7.159F8%edgardec2005@gmail.com>
References: <D1C7B7D7.159F8%edgardec2005@gmail.com>
Message-ID: <1436721375.2314.3.camel@gmail.com>

Edgar,


On Sun, 2015-07-12 at 06:21 -0300, Edgar J. De Cleene wrote:
> 
> 
> On 7/9/15, 6:15 AM, "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > This is a minor nit but when I'm developing Morphs I often need to
> > instantiate them manually via something like 'MorphName new
> > openInWorld.'  When I do that, I almost always find its initial position
> > annoying and in some cases nearly non-functional since the Morph doesn't
> > have room for its halo icons.  Just wondering if this bothers anyone
> > else and if maybe insetting new morphs top left by default to something
> > like 50 @ 50 (something out of the way, but giving it a bit of margin
> > from the edge of the screen) might be better?
> 
> 
> Morph new openInHand could be better?
> 

I find that's not always an option in the early stages of working on a
Morph as there are often initialization dependencies that I haven't
worked out at that stage causing openInHand not to work.  Once I have
everything working, then I go back and figure out what needs to happen
to get it running with openInHand...


> Edgar
> 
> 
> 
Thanks,
Phil




From edgardec2005 at gmail.com  Sun Jul 12 13:21:03 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sun, 12 Jul 2015 15:21:03 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436721375.2314.3.camel@gmail.com>
Message-ID: <D1C8365F.15A07%edgardec2005@gmail.com>




On 7/12/15, 2:16 PM, "Phil (list)" <pbpublist at gmail.com> wrote:

> I find that's not always an option in the early stages of working on a
> Morph as there are often initialization dependencies that I haven't
> worked out at that stage causing openInHand not to work.  Once I have
> everything working, then I go back and figure out what needs to happen
> to get it running with openInHand...

Ok.
Could share yours code not working with openInHand ?

Edgar





From pbpublist at gmail.com  Sun Jul 12 15:23:37 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 12 Jul 2015 16:23:37 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <D1C8365F.15A07%edgardec2005@gmail.com>
References: <D1C8365F.15A07%edgardec2005@gmail.com>
Message-ID: <1436732617.2314.17.camel@gmail.com>

On Sun, 2015-07-12 at 15:21 -0300, Edgar J. De Cleene wrote:
> 
> 
> On 7/12/15, 2:16 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > I find that's not always an option in the early stages of working on a
> > Morph as there are often initialization dependencies that I haven't
> > worked out at that stage causing openInHand not to work.  Once I have
> > everything working, then I go back and figure out what needs to happen
> > to get it running with openInHand...
> 
> Ok.
> Could share yours code not working with openInHand ?
> 

I think a recent example was the Dan's BouncingAtomsMorph which could
not be invoked from the New Morph... menu until I submitted a fix.  It
was an easy fix and I run into this problem quite often in the early
stages of Morph development.  openInHand calls doOneCycleNow (or maybe
it's doOneCycle... I forget which) which results in the Morph needing to
draw earlier than with openInWorld.  This is a problem if the Morph
isn't fully initialized and ready to be drawn yet.  It's not a big deal,
just part of how I develop Morphs and why I use openInWorld until I get
things sorted out.  Also, when I'm developing a Morph I'm usually
invoking it from a workspace or code browser and don't want to be
dealing with it interactively yet since it usually isn't fully
functional anyway.

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





From edgardec2005 at gmail.com  Sun Jul 12 16:02:31 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sun, 12 Jul 2015 18:02:31 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436732617.2314.17.camel@gmail.com>
Message-ID: <D1C85C37.15A14%edgardec2005@gmail.com>




On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:

> I think a recent example was the Dan's BouncingAtomsMorph which could
> not be invoked from the New Morph... menu until I submitted a fix.  It
> was an easy fix and I run into this problem quite often in the early
> stages of Morph development.  openInHand calls doOneCycleNow (or maybe
> it's doOneCycle... I forget which) which results in the Morph needing to
> draw earlier than with openInWorld.  This is a problem if the Morph
> isn't fully initialized and ready to be drawn yet.  It's not a big deal,
> just part of how I develop Morphs and why I use openInWorld until I get
> things sorted out.  Also, when I'm developing a Morph I'm usually
> invoking it from a workspace or code browser and don't want to be
> dealing with it interactively yet since it usually isn't fully
> functional anyway.

Very instructive.
Thanks a lot.

Edgar





From dnorton at mindspring.com  Sun Jul 12 21:20:55 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 12 Jul 2015 22:20:55 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <D1C85C37.15A14%edgardec2005@gmail.com>
References: <1436732617.2314.17.camel@gmail.com>,
	<D1C85C37.15A14%edgardec2005@gmail.com>
Message-ID: <55A32087.26820.2A728B2@dnorton.mindspring.com>

On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:

> 
> 
> 
> On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > I think a recent example was the Dan's BouncingAtomsMorph which
> could
> > not be invoked from the New Morph... menu until I submitted a fix.
> It
> > was an easy fix and I run into this problem quite often in the
> early
> > stages of Morph development.  openInHand calls doOneCycleNow (or
> maybe
> > it's doOneCycle... I forget which) which results in the Morph
> needing to
> > draw earlier than with openInWorld.  This is a problem if the
> Morph
> > isn't fully initialized and ready to be drawn yet.  It's not a big
> deal,
> > just part of how I develop Morphs and why I use openInWorld until
> I get
> > things sorted out.  Also, when I'm developing a Morph I'm
> usually
> > invoking it from a workspace or code browser and don't want to
> be
> > dealing with it interactively yet since it usually isn't fully
> > functional anyway.
> 
> Very instructive.
> Thanks a lot.
> 
> Edgar
>

Yes, thank you Phil for the fix. I needed to learn that. I put the history of the change on:

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

The commit is "343a986"  "starts from new morph menu"

 - Dan




From pbpublist at gmail.com  Sun Jul 12 23:41:03 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 13 Jul 2015 00:41:03 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <55A32087.26820.2A728B2@dnorton.mindspring.com>
References: <1436732617.2314.17.camel@gmail.com>
	, <D1C85C37.15A14%edgardec2005@gmail.com>
	<55A32087.26820.2A728B2@dnorton.mindspring.com>
Message-ID: <1436762463.2314.19.camel@gmail.com>

On Sun, 2015-07-12 at 22:20 -0400, Dan Norton wrote:
> On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:
> 
> > 
> > 
> > 
> > On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
> > 
> > > I think a recent example was the Dan's BouncingAtomsMorph which
> > could
> > > not be invoked from the New Morph... menu until I submitted a fix.
> > It
> > > was an easy fix and I run into this problem quite often in the
> > early
> > > stages of Morph development.  openInHand calls doOneCycleNow (or
> > maybe
> > > it's doOneCycle... I forget which) which results in the Morph
> > needing to
> > > draw earlier than with openInWorld.  This is a problem if the
> > Morph
> > > isn't fully initialized and ready to be drawn yet.  It's not a big
> > deal,
> > > just part of how I develop Morphs and why I use openInWorld until
> > I get
> > > things sorted out.  Also, when I'm developing a Morph I'm
> > usually
> > > invoking it from a workspace or code browser and don't want to
> > be
> > > dealing with it interactively yet since it usually isn't fully
> > > functional anyway.
> > 
> > Very instructive.
> > Thanks a lot.
> > 
> > Edgar
> >
> 
> Yes, thank you Phil for the fix. I needed to learn that. I put the history of the change on:
> 

Glad to chip in... thank you for giving us a nice Morphic demo!

> https://github.com/dhnorton/Cuis-Smalltalk-atoms
> 
> The commit is "343a986"  "starts from new morph menu"
> 

There it is  (I was too tired/lazy to dig up the commit reference :-)

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





From hannes.hirzel at gmail.com  Mon Jul 13 00:39:23 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 13 Jul 2015 05:39:23 +0000
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436762463.2314.19.camel@gmail.com>
References: <1436732617.2314.17.camel@gmail.com>
	<D1C85C37.15A14%edgardec2005@gmail.com>
	<55A32087.26820.2A728B2@dnorton.mindspring.com>
	<1436762463.2314.19.camel@gmail.com>
Message-ID: <CAGQxfVjPO7Q+BS=N4HEcsKtb_4g4+RmVLvZeM_KDEWPe4+61Tg@mail.gmail.com>

You mean this one

https://github.com/dhnorton/Cuis-Smalltalk-atoms/commit/343a986a8f4bdfb4bee8eb05797e4d75b881ecbe

?

--Hannes

On 7/13/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Sun, 2015-07-12 at 22:20 -0400, Dan Norton wrote:
>> On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:
>>
>> >
>> >
>> >
>> > On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
>> >
>> > > I think a recent example was the Dan's BouncingAtomsMorph which
>> > could
>> > > not be invoked from the New Morph... menu until I submitted a fix.
>> > It
>> > > was an easy fix and I run into this problem quite often in the
>> > early
>> > > stages of Morph development.  openInHand calls doOneCycleNow (or
>> > maybe
>> > > it's doOneCycle... I forget which) which results in the Morph
>> > needing to
>> > > draw earlier than with openInWorld.  This is a problem if the
>> > Morph
>> > > isn't fully initialized and ready to be drawn yet.  It's not a big
>> > deal,
>> > > just part of how I develop Morphs and why I use openInWorld until
>> > I get
>> > > things sorted out.  Also, when I'm developing a Morph I'm
>> > usually
>> > > invoking it from a workspace or code browser and don't want to
>> > be
>> > > dealing with it interactively yet since it usually isn't fully
>> > > functional anyway.
>> >
>> > Very instructive.
>> > Thanks a lot.
>> >
>> > Edgar
>> >
>>
>> Yes, thank you Phil for the fix. I needed to learn that. I put the history
>> of the change on:
>>
>
> Glad to chip in... thank you for giving us a nice Morphic demo!
>
>> https://github.com/dhnorton/Cuis-Smalltalk-atoms
>>
>> The commit is "343a986"  "starts from new morph menu"
>>
>
> There it is  (I was too tired/lazy to dig up the commit reference :-)
>
>>  - Dan
>>
>>
>> _______________________________________________
>> 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 dnorton at mindspring.com  Mon Jul 13 09:23:44 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 13 Jul 2015 07:23:44 -0700 (PDT)
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <CAGQxfVjPO7Q+BS=N4HEcsKtb_4g4+RmVLvZeM_KDEWPe4+61Tg@mail.gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
	<D1C7B7D7.159F8%edgardec2005@gmail.com>
	<1436721375.2314.3.camel@gmail.com>
	<D1C8365F.15A07%edgardec2005@gmail.com>
	<1436732617.2314.17.camel@gmail.com>
	<D1C85C37.15A14%edgardec2005@gmail.com>
	<55A32087.26820.2A728B2@dnorton.mindspring.com>
	<1436762463.2314.19.camel@gmail.com>
	<CAGQxfVjPO7Q+BS=N4HEcsKtb_4g4+RmVLvZeM_KDEWPe4+61Tg@mail.gmail.com>
Message-ID: <1436797424888-4837347.post@n4.nabble.com>

Yes, it seems there are several ways to see the commit :-)

GitHub newbie here,

 - Dan



--
View this message in context: http://forum.world.st/Default-Morph-position-something-other-than-0-0-tp4836757p4837347.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From dnorton at mindspring.com  Wed Jul 15 10:54:49 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 15 Jul 2015 11:54:49 -0400
Subject: [Cuis] Array2D newSize:
Message-ID: <55A68249.17883.775BA8@dnorton.mindspring.com>

Maybe it's my dyslexia, but isn't this backward?

"Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
| nil nil |
| nil nil |
| nil nil |

IMO it should be:
| nil nil nil |
| nil nil nil |

For example, in Squeak, "MatrixTransform2x3 identity" produces: MatrixTransform2x3(
1.0	0.0	0.0
0.0	1.0	0.0
)

Please correct me if I'm wrong.

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

From dnorton at mindspring.com  Wed Jul 15 17:23:26 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 15 Jul 2015 15:23:26 -0700 (PDT)
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A68249.17883.775BA8@dnorton.mindspring.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
Message-ID: <1436999006167-4837720.post@n4.nabble.com>


Maybe it's my dyslexia, but isn't this backward?

"Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
| nil nil |
| nil nil |
| nil nil |

IMO it should be:
| nil nil nil |
| nil nil nil |

For example, in Squeak, "MatrixTransform2x3 identity" produces:
MatrixTransform2x3(
1.0	0.0	0.0
0.0	1.0	0.0
)

Please correct me if I'm wrong.

OK, you're wrong - as long as there is a subclass called Matrix in

LinearAlgebra.pck.st

Use Matrix instead of Array2d.

(whew)




--
View this message in context: http://forum.world.st/Array2D-newSize-tp4837696p4837720.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From pbpublist at gmail.com  Wed Jul 15 18:43:12 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 15 Jul 2015 19:43:12 -0400
Subject: [Cuis] Preventing pretty print from replacing := with _?
Message-ID: <1437003792.2401.2.camel@gmail.com>

Is there a setting that will disable this substitution?  I would
actually prefer it to go the other way: if it sees an _ assignment,
replace it with :=

Thanks,
Phil




From pbpublist at gmail.com  Wed Jul 15 19:49:57 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 15 Jul 2015 20:49:57 -0400
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1436999006167-4837720.post@n4.nabble.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
Message-ID: <1437007797.2401.12.camel@gmail.com>

On Wed, 2015-07-15 at 15:23 -0700, Dan Norton wrote:
> Maybe it's my dyslexia, but isn't this backward?
> 
> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
> | nil nil |
> | nil nil |
> | nil nil |
> 
> IMO it should be:
> | nil nil nil |
> | nil nil nil |
> 
> For example, in Squeak, "MatrixTransform2x3 identity" produces:
> MatrixTransform2x3(
> 1.0	0.0	0.0
> 0.0	1.0	0.0
> )
> 
> Please correct me if I'm wrong.
> 
> OK, you're wrong - as long as there is a subclass called Matrix in
> 
> LinearAlgebra.pck.st
> 
> Use Matrix instead of Array2d.
> 

Glad that solved your problem but, ouch... that class is uncomfortably
close in name and function to the 3DTransform package I'm using for
OpenGL.  Juan: would you be open to using an extended version of my
classes so that we don't run into namespace conflicts?

One advantage that the Matrix* and Vector* classes I'm using have is
that they are mapped to native types which makes for transparent and
easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
compute shaders and you have the fastest matrix math you've ever seen,
assuming you've got medium or larger sets of data)

> (whew)
> 
> 
> 
> 
> --
> View this message in context: http://forum.world.st/Array2D-newSize-tp4837696p4837720.html
> Sent from the Cuis Smalltalk mailing list archive at Nabble.com.
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Thu Jul 16 07:43:13 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 09:43:13 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
Message-ID: <55A7A6E1.8000909@jvuletich.org>

Hi Edgar,

Is there such a project? Any reference?

Thanks,
Juan Vuletich

On 7/11/2015 5:24 PM, Edgar J De Cleene wrote:
> Quoting Casey
>
>> If we can throw in some HyperCard and... 
>
> A long time algo wish Squeak could read HyperCard stacks.
> If Cuis could do this , bet we have thousands users.
> Anyway whats the HyperCard status ?
>

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

From hannes.hirzel at gmail.com  Thu Jul 16 08:00:03 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 13:00:03 +0000
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <55A7A6E1.8000909@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
Message-ID: <CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>

 I think there was something like that. Need to search in the Squeak
list. And check the porting effort. Might be doable with Cuis these
days.

--Hannes

On 7/16/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Edgar,
>
> Is there such a project? Any reference?
>
> Thanks,
> Juan Vuletich
>
> On 7/11/2015 5:24 PM, Edgar J De Cleene wrote:
>> Quoting Casey
>>
>>> If we can throw in some HyperCard and...
>>
>> A long time algo wish Squeak could read HyperCard stacks.
>> If Cuis could do this , bet we have thousands users.
>> Anyway whats the HyperCard status ?
>>
>
>



From juan at jvuletich.org  Thu Jul 16 08:01:12 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:01:12 -0300
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <1437003792.2401.2.camel@gmail.com>
References: <1437003792.2401.2.camel@gmail.com>
Message-ID: <55A7AB18.5020601@jvuletich.org>

On 7/15/2015 8:43 PM, Phil (list) wrote:
> Is there a setting that will disable this substitution?  I would
> actually prefer it to go the other way: if it sees an _ assignment,
> replace it with :=
>
> Thanks,
> Phil

Please check #syntaxHighlightingAsYouTypeAnsiAssignment and 
#syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.

Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough 
for you?

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Thu Jul 16 08:10:02 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 13:10:02 +0000
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <55A7AB18.5020601@jvuletich.org>
References: <1437003792.2401.2.camel@gmail.com>
	<55A7AB18.5020601@jvuletich.org>
Message-ID: <CAGQxfVhV09RLrLsEsBaRKXERznoP-p+Zdxj4dOF5CnjNFtgH4Q@mail.gmail.com>

I just added an issue for this

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/67

(for Documentation which I'd like to do later, there are more of
issues like this)

Please update the issue when the answer is known.

--Hannes

On 7/16/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/15/2015 8:43 PM, Phil (list) wrote:
>> Is there a setting that will disable this substitution?  I would
>> actually prefer it to go the other way: if it sees an _ assignment,
>> replace it with :=
>>
>> Thanks,
>> Phil
>
> Please check #syntaxHighlightingAsYouTypeAnsiAssignment and
> #syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.
>
> Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough
> for you?
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Thu Jul 16 08:14:17 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:14:17 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A68249.17883.775BA8@dnorton.mindspring.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
Message-ID: <55A7AE29.3010706@jvuletich.org>

Hi Dan,

On 7/15/2015 12:54 PM, Dan Norton wrote:
> Maybe it's my dyslexia, but isn't this backward?

It is not you. It is the unfortunate fact that 2 conventions exist for this

> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
> | nil nil |
> | nil nil |
> | nil nil |

Yes. 2 at 3 is a point with x=2 and y=3. x is usually regarded as the 
horizontal coordinate and y as the vertical coordinate. This is the 
universal convention for pixels in Displays and Forms and for 
mathematical points in the Cartesian plane.

> IMO it should be:
> | nil nil nil |
> | nil nil nil |

Yes. That's why Array2D class also has #height:width: and #width:height. 
Matrices are usually accessed with i, j; where i is the row and j the 
column. Array2D instances have #x:y: and #i:j: , and the order of the 
arguments is swapped. So you can pick the convention that bests suits 
what you are doing.

> For example, in Squeak, "MatrixTransform2x3 identity" produces: 
> MatrixTransform2x3(
> 1.0       0.0       0.0
> 0.0       1.0       0.0
> )

Yes. It uses the matrix convention.

> Please correct me if I'm wrong.
>
>  - Dan
>

  HTH.

In addition to all this Matrices have origin (1,1), while the 
mathematical plane and Forms have origin (0,0). But Matrices and Forms 
have the origin at the topLeft, while the mathematical plane has the 
origin at the bottomLeft (or at the center if you allow negative 
coordinates).

To make things even more complicated, when mapping the mathematical 
plane to a Form, you can map integer numbers in the plane to the center 
of the pixels (the convention that makes most sense to me) or to pixel 
corners (as Squeak / Cuis Rectangles do).

All unnecesary complications, but that we can't avoid.

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

From juan at jvuletich.org  Thu Jul 16 08:16:54 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:16:54 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1436999006167-4837720.post@n4.nabble.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
Message-ID: <55A7AEC6.9090908@jvuletich.org>

On 7/15/2015 7:23 PM, Dan Norton wrote:
> Maybe it's my dyslexia, but isn't this backward?
>
> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
> | nil nil |
> | nil nil |
> | nil nil |
>
> IMO it should be:
> | nil nil nil |
> | nil nil nil |
>
> For example, in Squeak, "MatrixTransform2x3 identity" produces:
> MatrixTransform2x3(
> 1.0	0.0	0.0
> 0.0	1.0	0.0
> )
>
> Please correct me if I'm wrong.
>
> OK, you're wrong - as long as there is a subclass called Matrix in
>
> LinearAlgebra.pck.st
>
> Use Matrix instead of Array2d.
>
> (whew)

No, you are not wrong.

But use Matrix, or maybe FloatMatrix if it makes sense for you.

Also keep in mind that Cuis has AffineTransformation, that is almost 
identical to Squeak's MatrixTransform2x3 (except for Squeak's doing some 
very arguable rounding to integer of results).

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 16 08:23:35 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:23:35 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1437007797.2401.12.camel@gmail.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>	<1436999006167-4837720.post@n4.nabble.com>
	<1437007797.2401.12.camel@gmail.com>
Message-ID: <55A7B057.4050803@jvuletich.org>

Hi Phil,

On 7/15/2015 9:49 PM, Phil (list) wrote:
> Glad that solved your problem but, ouch... that class is uncomfortably
> close in name and function to the 3DTransform package I'm using for
> OpenGL.  Juan: would you be open to using an extended version of my
> classes so that we don't run into namespace conflicts?

Indeed we need to do something with this. Check the "Math 3D" package. 
It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need 
double precision for satellite image processing at work.

There is a lot of overlap with yours, but you are using 32 bit Floats.

> One advantage that the Matrix* and Vector* classes I'm using have is
> that they are mapped to native types which makes for transparent and
> easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
> compute shaders and you have the fastest matrix math you've ever seen,
> assuming you've got medium or larger sets of data)

Yes. This is indeed great. We need to build a single, uniform package 
with this stuff, that handles both 32 and 64 bit Floats and can take 
advantage of GPUs.

BTW, have you used OpenCL from Cuis? I'll be needing to work with that 
in a few months.

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Thu Jul 16 08:28:07 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 13:28:07 +0000
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A7AEC6.9090908@jvuletich.org>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
	<55A7AEC6.9090908@jvuletich.org>
Message-ID: <CAGQxfVjFGwyjhX_tJkFx3F8WtBnbuDA1huqcQ=fJwG-M5+4bjQ@mail.gmail.com>

Created an issue for me to sometime later this year add to the documentation

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/68

--Hannes

On 7/16/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/15/2015 7:23 PM, Dan Norton wrote:
>> Maybe it's my dyslexia, but isn't this backward?
>>
>> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
>> | nil nil |
>> | nil nil |
>> | nil nil |
>>
>> IMO it should be:
>> | nil nil nil |
>> | nil nil nil |
>>
>> For example, in Squeak, "MatrixTransform2x3 identity" produces:
>> MatrixTransform2x3(
>> 1.0	0.0	0.0
>> 0.0	1.0	0.0
>> )
>>
>> Please correct me if I'm wrong.
>>
>> OK, you're wrong - as long as there is a subclass called Matrix in
>>
>> LinearAlgebra.pck.st
>>
>> Use Matrix instead of Array2d.
>>
>> (whew)
>
> No, you are not wrong.
>
> But use Matrix, or maybe FloatMatrix if it makes sense for you.
>
> Also keep in mind that Cuis has AffineTransformation, that is almost
> identical to Squeak's MatrixTransform2x3 (except for Squeak's doing some
> very arguable rounding to integer of results).
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Thu Jul 16 09:49:52 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 14:49:52 +0000
Subject: [Cuis] Time stamp of source code change of a method?
Message-ID: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>

Hello

I'd like to do a query finding out about the time stamp of  source
code changes of all methods in the Cuis image and then do a list with
the following four columns


ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName, DateOfChange

Help is appreciated.

Hannes



From hannes.hirzel at gmail.com  Thu Jul 16 09:51:58 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 14:51:58 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
Message-ID: <CAGQxfVgdYn2s2A2e54SYhh8se8tJfv1QwHOw7u6fVkTFrrt8jA@mail.gmail.com>

P.S. I'd like to do this on a Cuis image of January 1st and then on a
Cuis image 30th June 2015.

And then do a bar chart


Package
NumberOfMethodsChanged

On 7/16/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Hello
>
> I'd like to do a query finding out about the time stamp of  source
> code changes of all methods in the Cuis image and then do a list with
> the following four columns
>
>
> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName, DateOfChange
>
> Help is appreciated.
>
> Hannes
>



From pbpublist at gmail.com  Thu Jul 16 13:36:29 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 16 Jul 2015 14:36:29 -0400
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <55A7AB18.5020601@jvuletich.org>
References: <1437003792.2401.2.camel@gmail.com>
	<55A7AB18.5020601@jvuletich.org>
Message-ID: <1437071789.2255.28.camel@gmail.com>

Juan,

On Thu, 2015-07-16 at 10:01 -0300, Juan Vuletich wrote:
> On 7/15/2015 8:43 PM, Phil (list) wrote:
> > Is there a setting that will disable this substitution?  I would
> > actually prefer it to go the other way: if it sees an _ assignment,
> > replace it with :=
> >
> > Thanks,
> > Phil
> 
> Please check #syntaxHighlightingAsYouTypeAnsiAssignment and 
> #syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.
> 
> Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough 
> for you?
> 

I'm already setting #syntaxHighlightingAsYouTypeAnsiAssignment to true
and leaving #syntaxHighlightingAsYouTypeLeftArrowAssignment at false.
That seems to work for everything except pretty printing.  I also played
with #allowUnderscoreAssignments but that just determines whether or not
_ is valid and doesn't stop pretty print trying to use underscores
anyway (which is entertaining because then pp produces invalid code :-)

> Cheers,
> Juan Vuletich

Thanks,
Phil




From pbpublist at gmail.com  Thu Jul 16 15:13:48 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 16 Jul 2015 16:13:48 -0400
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A7B057.4050803@jvuletich.org>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
	<1437007797.2401.12.camel@gmail.com> <55A7B057.4050803@jvuletich.org>
Message-ID: <1437077628.2255.77.camel@gmail.com>

Juan,

On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 7/15/2015 9:49 PM, Phil (list) wrote:
> > Glad that solved your problem but, ouch... that class is uncomfortably
> > close in name and function to the 3DTransform package I'm using for
> > OpenGL.  Juan: would you be open to using an extended version of my
> > classes so that we don't run into namespace conflicts?
> 
> Indeed we need to do something with this. Check the "Math 3D" package. 
> It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need 
> double precision for satellite image processing at work.
> 

You space guys with your astronomically large numbers and being sooooo
concerned with precisely where things are.  Why can't you accept
'there-ish' like the rest of us? :-)

(disclaimer: the events depicted in Gravity should in no way cast
aspersions as to the inadequacies of 32-bit floats...)

Ahh... hadn't noticed the Math 3D stuff before.  For OpenGL, I've been
using a combination of the Collections-Arrayed, Collections-Balloon and
3DTransform (i.e. the 3DTransform package which provides the Vector* and
Matrix* classes, which came from Croquet, or whatever upstream source
they pulled from)

The Float64* class hierarchy in Math 3D appears to just be a parallel
64-bit hierarchy (with some slight naming convention differences) to the
32-bit Vector* and Matrix* classes from 3DTransform.  So what we'd
probably want to do there is merge them (i.e. keeping both the 64-bit
and 32-versions... when you need one or the other, you absolutely need
it) into a single package and make sure they have identical
functionality and consistent naming conventions (I have no preference on
which conventions we use other than that they be consistent.  Makes no
difference to me whether I'm using Vector2 or Float32Vector2 or whatever
else would make sense)  If we did that, this would just leave the
question of how the LinearAlgebra and Array2D classes fit into this (one
thing I don't currently have but would like is an arbitrary MxN 32-bit
float matrix class)...

At first glance, the naming convention mapping appears to be:

Float64Color4 -> VectorColor
Float64Matrix4x4 -> Matrix4x4
Float64Rotation -> Quaternion
Float64Vector2 -> Vector2
Float64Vector3 -> Vector3
Float64Vector4 -> Vector4

With the balances of the classes being unique to 3DTransform. (Just
curious: for Float64Vector* why don't you use a common base class
similar to Vector?)

> There is a lot of overlap with yours, but you are using 32 bit Floats.
> 

For now... at some point I'm sure I'll be needing 64-bit Floats as well.
Since both the VM and OpenGL are limited to 32-bits, that's been doing
the job for me. (my priority is currently performance over precision
since for me it's just an errant pixel, for you it might be a house or
your satellite heading for the ISS...)

> > One advantage that the Matrix* and Vector* classes I'm using have is
> > that they are mapped to native types which makes for transparent and
> > easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
> > compute shaders and you have the fastest matrix math you've ever seen,
> > assuming you've got medium or larger sets of data)
> 
> Yes. This is indeed great. We need to build a single, uniform package 
> with this stuff, that handles both 32 and 64 bit Floats and can take 
> advantage of GPUs.
> 
> BTW, have you used OpenCL from Cuis? I'll be needing to work with that 
> in a few months.
> 

Not yet, but pretty much all of the same issues I've run into with
OpenGL would apply for OpenCL (i.e. it's all FFI as far as the VM is
concerned unless you're going to create a plugin, but even then you
still have the same issues) so I think we should be able to get to a
unified vector/matrix structure that works for both of us.  In both
cases the key is to minimize the amount of work done to marshal native
data in and out (slow/expensive conversions have a dramatic and
detrimental cost for small data sets / short computations) while keeping
the data as easy to work with as possible in both the Smalltalk and FFI
(whether OpenGL/OpenCL/CUDA/Metal/Vulcan/etc.) environments.

Something to keep in the back of your mind: OMeta.  One of the many
reasons I get so geeked out about it is that an OpenGL shader is just
another language that can be targeted via source-to-source translation
(i.e. dynamically generated GPU code written in something similar to
Slang or another DSL from Cuis).  OpenCL shouldn't be terribly
different...

> Cheers,
> Juan Vuletich

Thanks,
Phil




From dnorton at mindspring.com  Thu Jul 16 20:43:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 16 Jul 2015 21:43:22 -0400
Subject: [Cuis] Block Arguments
Message-ID: <55A85DBA.15429.29625A6@dnorton.mindspring.com>

Hi Juan,

On windows, when the attached class method is added to StrikeFont and cmd-d is done on 
the comment, it produces:

'Error: This block accepts 0 arguments, but was called with 1 argument.'

AFAIKT it is not passing any arguments and the files do exist. Maybe a bug?

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150716/ea2323c1/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StrikeFont class-createTrueTypebolditalicboldItalic.zip
Type: application/zip
Size: 624 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150716/ea2323c1/attachment-0002.zip>

From pbpublist at gmail.com  Thu Jul 16 21:11:45 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 16 Jul 2015 22:11:45 -0400
Subject: [Cuis] Block Arguments
In-Reply-To: <55A85DBA.15429.29625A6@dnorton.mindspring.com>
References: <55A85DBA.15429.29625A6@dnorton.mindspring.com>
Message-ID: <1437099105.2255.92.camel@gmail.com>

On Thu, 2015-07-16 at 21:43 -0400, Dan Norton wrote:
> Hi Juan,
> 
> 
> On windows, when the attached class method is added to StrikeFont and
> cmd-d is done on the comment, it produces:
> 
> 
> 'Error: This block accepts 0 arguments, but was called with 1
> argument.'
> 
> 
> AFAIKT it is not passing any arguments and the files do exist. Maybe a
> bug?
> 
But it is passing an argument to your ifExistsDo: block (the filestream)
and your block doesn't accept any.  If you don't care about the
filestream, change your blocks to [:filestream| {baseName. ' OK'} print]
etc. and ignore the parameter.

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





From juan at jvuletich.org  Fri Jul 17 08:03:16 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:03:16 -0300
Subject: [Cuis] DIRECT version number
In-Reply-To: <CAGQxfVg4pDR8sL9ezpcvtH3DFQuG7Si=wiG=mh+daW0seUTO8g@mail.gmail.com>
References: <CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA@mail.gmail.com>	<55A7A607.7050304@jvuletich.org>	<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A@mail.gmail.com>	<55A7B5DA.1020103@jvuletich.org>	<CAGQxfVg7ZLtdkz211LwJPe6uFxSUBMvgeJhafD+ZSxixSMo6tA@mail.gmail.com>
	<CAGQxfVg4pDR8sL9ezpcvtH3DFQuG7Si=wiG=mh+daW0seUTO8g@mail.gmail.com>
Message-ID: <55A8FD14.8060502@jvuletich.org>

(cc the mail list)

Yes, we could do it. I kinda stopped doing "releases" because with a 
constantly updating GitHub repo, each commit can be considered a "release".

So, the question is,
What is a release? How is it different from a GitHub commit?
What is the value of a release?

Maybe it is just about following a tradition (from the time of diskettes 
and CD Rom). Or maybe it is about crating echos in other places (tweets, 
blogs, etc)...

What do others think?

Cheers,
Juan Vuletich

On 7/16/2015 4:36 PM, H. Hirzel wrote:
> What I mean is this
>
> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
>
> New in Cuis 4.2 (released July 25, 2013)
>
>      Packages now have dependencies
>
>      Package loading greatly enhanced
>
>      Moved non-essential stuff to optional packages. Cuis is now below
> 500 classes and 100kLOC. Reduction was about 25%
>
>      Many bugfixes, and minor enhancements and cleanup
>
>
> NO RELEASE SINCE since July 2013!
>
>
> I suggest to do a release 4.3 soon and among other things have a
> clean-up  and documentation phase and then go for a 4.4 release after
> three months.
> I am willing to contribute to this.
>
> --HH
>
> On 7/16/15, H. Hirzel<hannes.hirzel at gmail.com>  wrote:
>> Thank you for the answer. Your conclusion nicely summarizes my concerns,
>>
>> I will think about it.
>>
>> As for no 1) parts of the system that are affected:
>>
>> Going for a list of all methods, taking the time stamp of last change
>> and do a graph of number of affected methods in each subsystem would
>> be helpful.
>>
>> That shows the impact of changes and allows to choose a proper commit
>> where I want to go for.
>>
>> That could be a built-in report.
>>
>> No 2) Level of risk involved
>> is more difficult to do automaticallyz
>>
>> --HH
>>
>>
>>
>>
>> On 7/16/15, Juan Vuletich<juan at jvuletich.org>  wrote:
>>> Hi Hannes,
>>>
>>> On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>>> Thank you Juan, for answering.
>>>>
>>>> At the moment I feel uncomfortable using Cuis because it is currently
>>>> a quite fast moving target. I perceive quite a number of API changes
>>>> though this might be wrong. But I do not know because there are no
>>>> release notes which summarize it.
>>> Yes, that's true. Besides, we don't have a specification of what is an
>>> API and what is not. So, almost any change can be considered an API
>>> change.
>>>
>>> I don't want you to feel uncomfortable. Let's work this out.
>>>
>>>>    And I do not now in which state my stuff and the general Cuis stuff
>>>> ist.
>>>>
>>>> I need a new 'base line', i.e. a release number to which I can refer
>>>> to when upgrading my code.
>>> Well, but we do have that. It is the update number. It is part of any
>>> Cuis image I've ever committed to the repo.
>>>
>>> The problem, I think, is not identifying well defined Cuis releases. The
>>> problem is knowing how updates could affect your code.
>>>
>>>> Of course the other option  is to just follow the most recent update
>>>> all the time. That would  call for some kind of continuous integration
>>>> testing 'Cuis style' which I not have either.
>>>>
>>>> E.g. if you could do a writeup how you do test Cuis before each new
>>>> commit (there are over 50 this year) and which scripts you use I could
>>>> apply the same thing for my packages.
>>>>
>>>> It has to be something which can be done quickly. Semi-Automatic is
>>>> fine. A check list with
>>>>
>>>> - do this
>>>> - then execute that script
>>>> - Open .. this and that
>>>> - And finally run a report on  ...
>>>>
>>>> would be fine.
>>> I don't have that either. I run the tests from time to time (I'll start
>>> doing it before any commit, and add the xml report to the rep). But this
>>> is not the most important reason why Cuis is solid. Cuis is very
>>> reliable because:
>>> - I'm not too bad as a coder.
>>> - I do my own code revisions at least one day after each change.
>>> - I use Cuis every day, and spot most problems in the updates, before
>>> commtting them to the repo.
>>> - I really, really care about code quality.
>>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>>> is a big responsibility, given how important I think Smalltalk-80 is.
>>>
>>> So, I suggest running your tests when updating your image, or migrating
>>> your code to an updated image.
>>>
>>> In any case, I think this doesn't answer your concerns. What you need is
>>> some way to know which updates could affect you, to review them in
>>> detail, and understanding their effect on your code. A list of the
>>> affected classes and/or methods for each update makes no sense. Cuis can
>>> already show you that very easily. Perhaps each update should include:
>>>
>>> 1) parts of the system that are affected:
>>> - Kernel
>>> - Compiler
>>> - Tools
>>> - Morphic
>>> - etc
>>>
>>> 2) Level of risk involved
>>> - very unlikely to break code that depends on this part of the system
>>> - could perhaps break code that depends on this part of the system
>>> - will most likely break code that depends on this part of the system
>>>
>>> Or something like that.
>>>
>>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>>> free to answer there if you agree.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>> However doing a release tag in github is really not a big deal if you
>>>> actually take the plunge.
>>>>
>>>> You are not alone in not using this option.
>>>>
>>>> It took me two years to realize that I can learn to do it and actually
>>>> do a release in 5 minutes.....
>>>>
>>>> So I suggest do a release just continuing where you left off last time.
>>>>
>>>> Then people will start to realise there is something to test against.
>>>> And new update requests will come and you can do another one.
>>>>
>>>> So the release which I am asking for is not a big deal. Just a tag on a
>>>> commit.
>>>>
>>>> I'd like to explore the direct authoring tools offered by Ken Dickey.
>>>>
>>>> With the aim of producing a very simple Hypercard / Powerpoint like
>>>> authoring environment.
>>>>
>>>> And do more with OMeta.
>>>>
>>>> Happy continued Cuis curating .....
>>>> And thank you very much indeed for your great work maintaining this
>>>> environment.
>>>>
>>>>
>>>> Hannes
>>>>
>>>>
>>>>
>>>> On 7/16/15, Juan Vuletich<juan at jvuletich.org>   wrote:
>>>>> On 7/12/2015 6:27 PM, H. Hirzel wrote:
>>>>>> Hi Juan
>>>>>>
>>>>>> Regarding a Cuis version number. I suggest that you just continue with
>>>>>> a new version number where you left off last time.
>>>>>>
>>>>>> It is just about having a version number to have a new baseline to
>>>>>> refer to. This is helpful for testing and documentation.
>>>>>>
>>>>>> I do not think it is a big issue.
>>>>>>
>>>>>> API changes require a new version number.
>>>>>>
>>>>>> Kind regards
>>>>>> Hannes
>>>>> Hi Hannes,
>>>>>
>>>>> Sometimes I don't pay enough attention to stuff like this, so feel free
>>>>> to request action from me when you feel appropriate :)
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>




From juan at jvuletich.org  Fri Jul 17 08:39:47 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:39:47 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
Message-ID: <55A905A3.1060100@jvuletich.org>

Additional stuff about versioning, and how to keep your code working as 
Cuis changes.

Please share your ideas and thoughts about this.

We all want to ease development and maintenance of all sorts of projects 
while allowing a moderate rate of change to Cuis itself...

Cheers,
Juan Vuletich

-------- Original Message --------
From: 	- Thu Jul 16 10:47:08 2015
X-Mozilla-Status: 	0001
X-Mozilla-Status2: 	00800000
X-Mozilla-Keys: 	
Message-ID: 	<55A7B5DA.1020103 at jvuletich.org>
Date: 	Thu, 16 Jul 2015 10:47:06 -0300
From: 	Juan Vuletich <juan at jvuletich.org>
User-Agent: 	Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; 
rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 	1.0
To: 	H. Hirzel <hannes.hirzel at gmail.com>
Subject: 	Re: DIRECT version number
References: 
<CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA at mail.gmail.com> 
<55A7A607.7050304 at jvuletich.org> 
<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
In-Reply-To: 
<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
Content-Type: 	text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 	7bit



Hi Hannes,

On 7/16/2015 9:57 AM, H. Hirzel wrote:
>  Thank you Juan, for answering.
>
>  At the moment I feel uncomfortable using Cuis because it is currently
>  a quite fast moving target. I perceive quite a number of API changes
>  though this might be wrong. But I do not know because there are no
>  release notes which summarize it.

Yes, that's true. Besides, we don't have a specification of what is an
API and what is not. So, almost any change can be considered an API change.

I don't want you to feel uncomfortable. Let's work this out.

>    And I do not now in which state my stuff and the general Cuis stuff ist.
>
>  I need a new 'base line', i.e. a release number to which I can refer
>  to when upgrading my code.

Well, but we do have that. It is the update number. It is part of any
Cuis image I've ever committed to the repo.

The problem, I think, is not identifying well defined Cuis releases. The
problem is knowing how updates could affect your code.

>  Of course the other option  is to just follow the most recent update
>  all the time. That would  call for some kind of continuous integration
>  testing 'Cuis style' which I not have either.
>
>  E.g. if you could do a writeup how you do test Cuis before each new
>  commit (there are over 50 this year) and which scripts you use I could
>  apply the same thing for my packages.
>
>  It has to be something which can be done quickly. Semi-Automatic is
>  fine. A check list with
>
>  - do this
>  - then execute that script
>  - Open .. this and that
>  - And finally run a report on  ...
>
>  would be fine.

I don't have that either. I run the tests from time to time (I'll start
doing it before any commit, and add the xml report to the rep). But this
is not the most important reason why Cuis is solid. Cuis is very
reliable because:
- I'm not too bad as a coder.
- I do my own code revisions at least one day after each change.
- I use Cuis every day, and spot most problems in the updates, before
commtting them to the repo.
- I really, really care about code quality.
- I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
is a big responsibility, given how important I think Smalltalk-80 is.

So, I suggest running your tests when updating your image, or migrating
your code to an updated image.

In any case, I think this doesn't answer your concerns. What you need is
some way to know which updates could affect you, to review them in
detail, and understanding their effect on your code. A list of the
affected classes and/or methods for each update makes no sense. Cuis can
already show you that very easily. Perhaps each update should include:

1) parts of the system that are affected:
- Kernel
- Compiler
- Tools
- Morphic
- etc

2) Level of risk involved
- very unlikely to break code that depends on this part of the system
- could perhaps break code that depends on this part of the system
- will most likely break code that depends on this part of the system

Or something like that.

BTW, this is a very relevant topic for discussing on the mail list. Feel
free to answer there if you agree.

Cheers,
Juan Vuletich


>  However doing a release tag in github is really not a big deal if you
>  actually take the plunge.
>
>  You are not alone in not using this option.
>
>  It took me two years to realize that I can learn to do it and actually
>  do a release in 5 minutes.....
>
>  So I suggest do a release just continuing where you left off last time.
>
>  Then people will start to realise there is something to test against.
>  And new update requests will come and you can do another one.
>
>  So the release which I am asking for is not a big deal. Just a tag on a commit.
>
>  I'd like to explore the direct authoring tools offered by Ken Dickey.
>
>  With the aim of producing a very simple Hypercard / Powerpoint like
>  authoring environment.
>
>  And do more with OMeta.
>
>  Happy continued Cuis curating .....
>  And thank you very much indeed for your great work maintaining this environment.
>
>
>  Hannes
>
>
>
>  On 7/16/15, Juan Vuletich<juan at jvuletich.org>   wrote:
>>  On 7/12/2015 6:27 PM, H. Hirzel wrote:
>>>  Hi Juan
>>>
>>>  Regarding a Cuis version number. I suggest that you just continue with
>>>  a new version number where you left off last time.
>>>
>>>  It is just about having a version number to have a new baseline to
>>>  refer to. This is helpful for testing and documentation.
>>>
>>>  I do not think it is a big issue.
>>>
>>>  API changes require a new version number.
>>>
>>>  Kind regards
>>>  Hannes
>>  Hi Hannes,
>>
>>  Sometimes I don't pay enough attention to stuff like this, so feel free
>>  to request action from me when you feel appropriate :)
>>
>>  Cheers,
>>  Juan Vuletich
>>

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

From Ken.Dickey at whidbey.com  Fri Jul 17 08:40:55 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 17 Jul 2015 06:40:55 -0700
Subject: [Cuis] DIRECT version number
In-Reply-To: <55A8FD14.8060502@jvuletich.org>
References: <CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA@mail.gmail.com>
	<55A7A607.7050304@jvuletich.org>
	<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A@mail.gmail.com>
	<55A7B5DA.1020103@jvuletich.org>
	<CAGQxfVg7ZLtdkz211LwJPe6uFxSUBMvgeJhafD+ZSxixSMo6tA@mail.gmail.com>
	<CAGQxfVg4pDR8sL9ezpcvtH3DFQuG7Si=wiG=mh+daW0seUTO8g@mail.gmail.com>
	<55A8FD14.8060502@jvuletich.org>
Message-ID: <20150717064055.f8bc194236afd071b8afff51@whidbey.com>

On Fri, 17 Jul 2015 10:03:16 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> So, the question is,
> What is a release? How is it different from a GitHub commit?
> What is the value of a release?

IMHO, a Release is a stable point, expected to be robust and with some level of support, which one can develop against without concern for the ground changing under one's feet.

This is important in commercial projects and things one likes to demo and share around.

In particular, I would expect a Release for Cuis to have major associated packages also maintained at that particular release level.  It would be good to package the core release and associated packages matching that release together.

At this point, I test most of my packages with many (not all) Cuis Commits so that I can find/fix breakage as it happens.  I expect to do this.  I want Cuis to change for the better, radically, but I am not keeping a set of packages pegged to a historical Release.

I am willing to do maintain versions my packages for a particular Cuis release, e.g. for stable demos.  However, I would prefer Releases to be a long intervals (say a year) or after some radical change has been introduced and stabilized.

So far, this has not been a problem, but as usage increases ...

$0.02
-KenD



From juan at jvuletich.org  Fri Jul 17 08:48:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:48:09 -0300
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
Message-ID: <55A90799.7080302@jvuletich.org>

On 7/16/2015 11:49 AM, H. Hirzel wrote:
> Hello
>
> I'd like to do a query finding out about the time stamp of  source
> code changes of all methods in the Cuis image and then do a list with
> the following four columns
>
>
> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName, DateOfChange
>
> Help is appreciated.
>
> Hannes

Check #timeStampFor:class:reverseOrdinal: and in general 
#annotationForSelector:ofClass:

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Jul 17 08:51:38 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:51:38 -0300
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <1437071789.2255.28.camel@gmail.com>
References: <1437003792.2401.2.camel@gmail.com>	
	<55A7AB18.5020601@jvuletich.org>
	<1437071789.2255.28.camel@gmail.com>
Message-ID: <55A9086A.9060600@jvuletich.org>

On 7/16/2015 3:36 PM, Phil (list) wrote:
> Juan,
>
> On Thu, 2015-07-16 at 10:01 -0300, Juan Vuletich wrote:
>> On 7/15/2015 8:43 PM, Phil (list) wrote:
>>> Is there a setting that will disable this substitution?  I would
>>> actually prefer it to go the other way: if it sees an _ assignment,
>>> replace it with :=
>>>
>>> Thanks,
>>> Phil
>> Please check #syntaxHighlightingAsYouTypeAnsiAssignment and
>> #syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.
>>
>> Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough
>> for you?
>>
> I'm already setting #syntaxHighlightingAsYouTypeAnsiAssignment to true
> and leaving #syntaxHighlightingAsYouTypeLeftArrowAssignment at false.
> That seems to work for everything except pretty printing.

But, are you using Shout on the code pane? Can you list simple steps to 
reproduce on a fresh Cuis image?

>    I also played
> with #allowUnderscoreAssignments but that just determines whether or not
> _ is valid and doesn't stop pretty print trying to use underscores
> anyway (which is entertaining because then pp produces invalid code :-)

Yep. We could indeed fix that. Ok. I'll include it in the next commit.

Cheers,
Juan Vuletich

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




From juan at jvuletich.org  Fri Jul 17 09:15:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 11:15:53 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1437077628.2255.77.camel@gmail.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>	
	<1436999006167-4837720.post@n4.nabble.com>	
	<1437007797.2401.12.camel@gmail.com>
	<55A7B057.4050803@jvuletich.org>
	<1437077628.2255.77.camel@gmail.com>
Message-ID: <55A90E19.3060005@jvuletich.org>

Hi Phil,

On 7/16/2015 5:13 PM, Phil (list) wrote:
> Juan,
>
> On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
>> Hi Phil,
>>
>> On 7/15/2015 9:49 PM, Phil (list) wrote:
>>> Glad that solved your problem but, ouch... that class is uncomfortably
>>> close in name and function to the 3DTransform package I'm using for
>>> OpenGL.  Juan: would you be open to using an extended version of my
>>> classes so that we don't run into namespace conflicts?
>> Indeed we need to do something with this. Check the "Math 3D" package.
>> It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need
>> double precision for satellite image processing at work.
>>
> You space guys with your astronomically large numbers and being sooooo
> concerned with precisely where things are.  Why can't you accept
> 'there-ish' like the rest of us? :-)

:) I would... But if you want Google Earth level of precision, you do 
need them...

> (disclaimer: the events depicted in Gravity should in no way cast
> aspersions as to the inadequacies of 32-bit floats...)
>
> Ahh... hadn't noticed the Math 3D stuff before.  For OpenGL, I've been
> using a combination of the Collections-Arrayed, Collections-Balloon and
> 3DTransform (i.e. the 3DTransform package which provides the Vector* and
> Matrix* classes, which came from Croquet, or whatever upstream source
> they pulled from)

Croquet was done by Andreas, who previously wrote all the Baloon 3d 
stuff (including "Balloon3D-Math" , that is the base of the Math 3D 
package I did )

> The Float64* class hierarchy in Math 3D appears to just be a parallel
> 64-bit hierarchy (with some slight naming convention differences) to the
> 32-bit Vector* and Matrix* classes from 3DTransform.  So what we'd
> probably want to do there is merge them (i.e. keeping both the 64-bit
> and 32-versions... when you need one or the other, you absolutely need
> it) into a single package and make sure they have identical
> functionality and consistent naming conventions (I have no preference on
> which conventions we use other than that they be consistent.  Makes no
> difference to me whether I'm using Vector2 or Float32Vector2 or whatever
> else would make sense)  If we did that, this would just leave the
> question of how the LinearAlgebra and Array2D classes fit into this (one
> thing I don't currently have but would like is an arbitrary MxN 32-bit
> float matrix class)...
>
> At first glance, the naming convention mapping appears to be:
>
> Float64Color4 ->  VectorColor
> Float64Matrix4x4 ->  Matrix4x4
> Float64Rotation ->  Quaternion
> Float64Vector2 ->  Vector2
> Float64Vector3 ->  Vector3
> Float64Vector4 ->  Vector4
>
> With the balances of the classes being unique to 3DTransform. (Just
> curious: for Float64Vector* why don't you use a common base class
> similar to Vector?)

This comes from "Balloon3D-Math".  I'm sure Andreas did it that way to 
be able to write very efficient slang code for the Ballon3D VM plugin.

WRT to naming conventions, we just need to agree on one. I have no 
preference.

>> There is a lot of overlap with yours, but you are using 32 bit Floats.
>>
> For now... at some point I'm sure I'll be needing 64-bit Floats as well.
> Since both the VM and OpenGL are limited to 32-bits, that's been doing
> the job for me. (my priority is currently performance over precision
> since for me it's just an errant pixel, for you it might be a house or
> your satellite heading for the ISS...)

That's totally ok. Just a remark: the VM is not limited to 32 bits. 
Floats are 64 bits and are handled by the VM. What is limited to 32 bits 
is FloatArrayPlugin. But it is entirely possible to add Float64 (a.k.a. 
double) primitives to it.

WRT the satellites... I'm not doing AOCS (Attitude and Orbital Control 
System), but the image processing pipeline. So, a numeric error would be 
like saying that a picture of L.A. is in Mexico, or such :)

>>> One advantage that the Matrix* and Vector* classes I'm using have is
>>> that they are mapped to native types which makes for transparent and
>>> easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
>>> compute shaders and you have the fastest matrix math you've ever seen,
>>> assuming you've got medium or larger sets of data)
>> Yes. This is indeed great. We need to build a single, uniform package
>> with this stuff, that handles both 32 and 64 bit Floats and can take
>> advantage of GPUs.
>>
>> BTW, have you used OpenCL from Cuis? I'll be needing to work with that
>> in a few months.
>>
> Not yet, but pretty much all of the same issues I've run into with
> OpenGL would apply for OpenCL (i.e. it's all FFI as far as the VM is
> concerned unless you're going to create a plugin, but even then you
> still have the same issues) so I think we should be able to get to a
> unified vector/matrix structure that works for both of us.  In both
> cases the key is to minimize the amount of work done to marshal native
> data in and out (slow/expensive conversions have a dramatic and
> detrimental cost for small data sets / short computations) while keeping
> the data as easy to work with as possible in both the Smalltalk and FFI
> (whether OpenGL/OpenCL/CUDA/Metal/Vulcan/etc.) environments.

Yes.

Something that I would like (and I don't know how to do it without 
Traits) is to share most of the source code between the 32 and 64 bits 
versions. We would need something like two parallel inheritance hierarchies:

GeneralFloatArray
--- FloatArray32
--- --- FloatVector32
--- --- FloatQuaternion32
--- FloatArray64
--- --- FloatVector64
--- --- FloatQuaternion64
for the inheritance of size specific code (#at: #at:put: primitives)

and something like
FloatVector
--- FloatQuaternion
--- --- FloatQuaternion32
--- --- FloatQuaternion64
to share quaternion specific code...

Any idea on this? If code sharing is not possible, at least some help to 
keep both consistent...

> Something to keep in the back of your mind: OMeta.  One of the many
> reasons I get so geeked out about it is that an OpenGL shader is just
> another language that can be targeted via source-to-source translation
> (i.e. dynamically generated GPU code written in something similar to
> Slang or another DSL from Cuis).  OpenCL shouldn't be terribly
> different...

Yes... Although as OpenCL is close to C, I was thinking on a variant of 
Slang... Especially after Bert did a translator Slang -> js

Cheers,
Juan Vuletich



From Ken.Dickey at whidbey.com  Fri Jul 17 09:21:52 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 17 Jul 2015 07:21:52 -0700
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55A905A3.1060100@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
Message-ID: <20150717072152.c4ed6c0e14a113c18966f2d8@whidbey.com>

On Fri, 17 Jul 2015 10:39:47 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> The problem, I think, is not identifying well defined Cuis releases. The
> problem is knowing how updates could affect your code.

This is a large search space.  It is easy for some minor change to have a cascaded interaction.

In thinking about this, I like to think of aerodynamic drag.  I want to be able to make rapid progress, so I like streamlined development processes.  I also want stability and robustness.

I think the inflection point where we go from laminar to turbulent air flow will change over time.

At this point in time, there are the fewest users and projects Cuis is likely to have.  I personally favor minimal drag and maximal progress at the expense of stability.  As stability becomes more important, added drag (heavier duty release process) is justified.

I once was talking with someone about garbage collection and they asked me how I could _prove_ that only "live" objects were left after each GC.  I told them it was a "proof by contradiction".

I.e. it's not a problem until it becomes a problem.

I did software development for a living for a couple of decades.  For me (a vote of 1) Release process is not yet a problem.  But, hey, I'm an old hacker guy.

What does everyone else think?

-- 
-KenD

PS: the random progress graphic is totally unrelated to this discussion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PropEdit-Screenshot.png
Type: image/png
Size: 324850 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150717/563d523a/attachment-0002.png>

From dnorton at mindspring.com  Fri Jul 17 09:57:34 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 17 Jul 2015 10:57:34 -0400
Subject: [Cuis] Block Arguments
In-Reply-To: <1437099105.2255.92.camel@gmail.com>
References: <55A85DBA.15429.29625A6@dnorton.mindspring.com>,
	<1437099105.2255.92.camel@gmail.com>
Message-ID: <55A917DE.23607.2C3F41@dnorton.mindspring.com>

On 16 Jul 2015 at 22:11, Phil (list) wrote:

> On Thu, 2015-07-16 at 21:43 -0400, Dan Norton wrote:
> > Hi Juan,
> > 
> > 
> > On windows, when the attached class method is added to StrikeFont
> and
> > cmd-d is done on the comment, it produces:
> > 
> > 
> > 'Error: This block accepts 0 arguments, but was called with 1
> > argument.'
> > 
> > 
> > AFAIKT it is not passing any arguments and the files do exist.
> Maybe a
> > bug?
> > 
> But it is passing an argument to your ifExistsDo: block (the
> filestream)
> and your block doesn't accept any.  If you don't care about the
> filestream, change your blocks to [:filestream| {baseName. ' OK'}
> print]
> etc. and ignore the parameter.
>

Ahh, now I see it. Interesting. Thanks, Phil.

 - Dan



From dnorton at mindspring.com  Fri Jul 17 10:03:27 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 17 Jul 2015 11:03:27 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150717072152.c4ed6c0e14a113c18966f2d8@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>,
	<20150717072152.c4ed6c0e14a113c18966f2d8@whidbey.com>
Message-ID: <55A9193F.13540.31A0C2@dnorton.mindspring.com>

On 17 Jul 2015 at 7:21, Ken.Dickey wrote:

> On Fri, 17 Jul 2015 10:39:47 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
> 
> > The problem, I think, is not identifying well defined Cuis
> releases. The
> > problem is knowing how updates could affect your code.
> 
> This is a large search space.  It is easy for some minor change to
> have a cascaded interaction.
> 
> In thinking about this, I like to think of aerodynamic drag.  I want
> to be able to make rapid progress, so I like streamlined development
> processes.  I also want stability and robustness.
> 
> I think the inflection point where we go from laminar to turbulent
> air flow will change over time.
> 
> At this point in time, there are the fewest users and projects Cuis
> is likely to have.  I personally favor minimal drag and maximal
> progress at the expense of stability.  As stability becomes more
> important, added drag (heavier duty release process) is justified.
> 
> I once was talking with someone about garbage collection and they
> asked me how I could _prove_ that only "live" objects were left
> after each GC.  I told them it was a "proof by contradiction".
> 
> I.e. it's not a problem until it becomes a problem.
> 
> I did software development for a living for a couple of decades. 
> For me (a vote of 1) Release process is not yet a problem.  But,
> hey, I'm an old hacker guy.
>

+1

 - Dan
 
> What does everyone else think?
> 
> -- 
> -KenD
> 
> PS: the random progress graphic is totally unrelated to this
> discussion.
> 





From pbpublist at gmail.com  Fri Jul 17 10:18:54 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 17 Jul 2015 11:18:54 -0400
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A90E19.3060005@jvuletich.org>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
	<1437007797.2401.12.camel@gmail.com> <55A7B057.4050803@jvuletich.org>
	<1437077628.2255.77.camel@gmail.com> <55A90E19.3060005@jvuletich.org>
Message-ID: <1437146334.2255.134.camel@gmail.com>

Juan,

On Fri, 2015-07-17 at 11:15 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 7/16/2015 5:13 PM, Phil (list) wrote:
> > Juan,
> >
> > On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
> >> Hi Phil,
> >>
> >> On 7/15/2015 9:49 PM, Phil (list) wrote:
> >>> Glad that solved your problem but, ouch... that class is uncomfortably
> >>> close in name and function to the 3DTransform package I'm using for
> >>> OpenGL.  Juan: would you be open to using an extended version of my
> >>> classes so that we don't run into namespace conflicts?
> >> Indeed we need to do something with this. Check the "Math 3D" package.
> >> It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need
> >> double precision for satellite image processing at work.
> >>
> > You space guys with your astronomically large numbers and being sooooo
> > concerned with precisely where things are.  Why can't you accept
> > 'there-ish' like the rest of us? :-)
> 
> :) I would... But if you want Google Earth level of precision, you do 
> need them...
> 

Just aim for Apple Maps level of precision and call it good enough :-)

> > (disclaimer: the events depicted in Gravity should in no way cast
> > aspersions as to the inadequacies of 32-bit floats...)
> >
> > Ahh... hadn't noticed the Math 3D stuff before.  For OpenGL, I've been
> > using a combination of the Collections-Arrayed, Collections-Balloon and
> > 3DTransform (i.e. the 3DTransform package which provides the Vector* and
> > Matrix* classes, which came from Croquet, or whatever upstream source
> > they pulled from)
> 
> Croquet was done by Andreas, who previously wrote all the Baloon 3d 
> stuff (including "Balloon3D-Math" , that is the base of the Math 3D 
> package I did )

Ah, I knew Andreas did most of the graphics stuff in Croquet but wasn't
sure about the math code (just spot-checking, I see 'das' listed as the
person who last touched most of the code back in 2005 with some by
Andreas both before and after)

> 
> > The Float64* class hierarchy in Math 3D appears to just be a parallel
> > 64-bit hierarchy (with some slight naming convention differences) to the
> > 32-bit Vector* and Matrix* classes from 3DTransform.  So what we'd
> > probably want to do there is merge them (i.e. keeping both the 64-bit
> > and 32-versions... when you need one or the other, you absolutely need
> > it) into a single package and make sure they have identical
> > functionality and consistent naming conventions (I have no preference on
> > which conventions we use other than that they be consistent.  Makes no
> > difference to me whether I'm using Vector2 or Float32Vector2 or whatever
> > else would make sense)  If we did that, this would just leave the
> > question of how the LinearAlgebra and Array2D classes fit into this (one
> > thing I don't currently have but would like is an arbitrary MxN 32-bit
> > float matrix class)...
> >
> > At first glance, the naming convention mapping appears to be:
> >
> > Float64Color4 ->  VectorColor
> > Float64Matrix4x4 ->  Matrix4x4
> > Float64Rotation ->  Quaternion
> > Float64Vector2 ->  Vector2
> > Float64Vector3 ->  Vector3
> > Float64Vector4 ->  Vector4
> >
> > With the balances of the classes being unique to 3DTransform. (Just
> > curious: for Float64Vector* why don't you use a common base class
> > similar to Vector?)
> 
> This comes from "Balloon3D-Math".  I'm sure Andreas did it that way to 
> be able to write very efficient slang code for the Ballon3D VM plugin.
> 
> WRT to naming conventions, we just need to agree on one. I have no 
> preference.
> 

I'm OK with changing my stuff to use Float32*.  Since both hierarchies
are dependent on their underlying native types, that would probably be
the most straightforward approach.  Would it make sense to you to use
FloatXXQuaternion? (Rotation seems a bit vague to me since, while
unlikely, there could potentially be other rotation solutions
implemented)

> >> There is a lot of overlap with yours, but you are using 32 bit Floats.
> >>
> > For now... at some point I'm sure I'll be needing 64-bit Floats as well.
> > Since both the VM and OpenGL are limited to 32-bits, that's been doing
> > the job for me. (my priority is currently performance over precision
> > since for me it's just an errant pixel, for you it might be a house or
> > your satellite heading for the ISS...)
> 
> That's totally ok. Just a remark: the VM is not limited to 32 bits. 
> Floats are 64 bits and are handled by the VM. What is limited to 32 bits 
> is FloatArrayPlugin. But it is entirely possible to add Float64 (a.k.a. 
> double) primitives to it.
> 

That's good to know.  I've been meaning to dig back into the VM source
as there are still some questions I have about how FFI is doing some of
what it is doing.  Just lack of time on my part vs other priorities...

> WRT the satellites... I'm not doing AOCS (Attitude and Orbital Control 
> System), but the image processing pipeline. So, a numeric error would be 
> like saying that a picture of L.A. is in Mexico, or such :)
> 

Awww... you've destroyed my Dr. Evil mental image of you at work ;-)

> >>> One advantage that the Matrix* and Vector* classes I'm using have is
> >>> that they are mapped to native types which makes for transparent and
> >>> easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
> >>> compute shaders and you have the fastest matrix math you've ever seen,
> >>> assuming you've got medium or larger sets of data)
> >> Yes. This is indeed great. We need to build a single, uniform package
> >> with this stuff, that handles both 32 and 64 bit Floats and can take
> >> advantage of GPUs.
> >>
> >> BTW, have you used OpenCL from Cuis? I'll be needing to work with that
> >> in a few months.
> >>
> > Not yet, but pretty much all of the same issues I've run into with
> > OpenGL would apply for OpenCL (i.e. it's all FFI as far as the VM is
> > concerned unless you're going to create a plugin, but even then you
> > still have the same issues) so I think we should be able to get to a
> > unified vector/matrix structure that works for both of us.  In both
> > cases the key is to minimize the amount of work done to marshal native
> > data in and out (slow/expensive conversions have a dramatic and
> > detrimental cost for small data sets / short computations) while keeping
> > the data as easy to work with as possible in both the Smalltalk and FFI
> > (whether OpenGL/OpenCL/CUDA/Metal/Vulcan/etc.) environments.
> 
> Yes.
> 
> Something that I would like (and I don't know how to do it without 
> Traits) is to share most of the source code between the 32 and 64 bits 
> versions. We would need something like two parallel inheritance hierarchies:
> 
> GeneralFloatArray
> --- FloatArray32
> --- --- FloatVector32
> --- --- FloatQuaternion32
> --- FloatArray64
> --- --- FloatVector64
> --- --- FloatQuaternion64
> for the inheritance of size specific code (#at: #at:put: primitives)
> 
> and something like
> FloatVector
> --- FloatQuaternion
> --- --- FloatQuaternion32
> --- --- FloatQuaternion64
> to share quaternion specific code...
> 
> Any idea on this? If code sharing is not possible, at least some help to 
> keep both consistent...
> 

That would be the ideal.  But like you, I can only think of ways that
are a bit messy:

1) Traits (dependency complexity)
2) OMeta (using it as a templating system to emit both variants,
dependency complexity)
3) Using class composition rather than inheritance (adds a bit of
complexity as you would need to call something like myMatrix #contents
to actually get at the data to pass to FFI)

Probably the simplest solution short term is just keep a parallel class
hierarchy in the same package and ensure that they stay in sync using
test cases.

> > Something to keep in the back of your mind: OMeta.  One of the many
> > reasons I get so geeked out about it is that an OpenGL shader is just
> > another language that can be targeted via source-to-source translation
> > (i.e. dynamically generated GPU code written in something similar to
> > Slang or another DSL from Cuis).  OpenCL shouldn't be terribly
> > different...
> 
> Yes... Although as OpenCL is close to C, I was thinking on a variant of 
> Slang... Especially after Bert did a translator Slang -> js
> 

However you go about it, just keep language abstraction in mind.  Just
as OpenGL continues to go through backwards-incompatible changes to
'fix' its abstraction layer issues, I suspect we're entering a similar
phase with OpenCL and CUDA.  We will likely end up with something
different such as Vulcan or Metal as the GPU compute standard a few
years from now.  Hopefully it won't take them as many iterations as it
has with OpenGL... (wishful thinking on my part, I fear)

> Cheers,
> Juan Vuletich

Thanks,
Phil




From edgardec2005 at gmail.com  Fri Jul 17 12:36:25 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Fri, 17 Jul 2015 14:36:25 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
Message-ID: <E772B770227A414C8E4912293F62ED5A@gmail.com>

Casey , you begin all this a long time ago.
Hope you could be healthy and join to the quest soon.


Now i away of my dungeons, but this week end I take a torch and try to found the relevant info.
To my short memory , no code or significant progress.
Not knowing if Apple could be persuaded HyperCard go open source or give technical info what could be useful to any wishing bring HyperCard to life again..

But glad Juan , Hannes show interest.

Edgar 

-- 
Edgar De Cleene
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Thursday, July 16, 2015 at 10:00 AM, H. Hirzel wrote:

> I think there was something like that. Need to search in the Squeak
> list. And check the porting effort. Might be doable with Cuis these
> days.
> 
> --Hannes
> 
> On 7/16/15, Juan Vuletich <juan at jvuletich.org (mailto:juan at jvuletich.org)> wrote:
> > Hi Edgar,
> > 
> > Is there such a project? Any reference?
> > 
> > Thanks,
> > Juan Vuletich
> > 
> > On 7/11/2015 5:24 PM, Edgar J De Cleene wrote:
> > > Quoting Casey
> > > 
> > > > If we can throw in some HyperCard and...
> > > 
> > > A long time algo wish Squeak could read HyperCard stacks.
> > > If Cuis could do this , bet we have thousands users.
> > > Anyway whats the HyperCard status ?
> > > 
> > 
> > 
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org (mailto: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/20150717/0f16a00a/attachment-0002.html>

From pbpublist at gmail.com  Fri Jul 17 13:45:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 17 Jul 2015 14:45:01 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55A905A3.1060100@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
Message-ID: <1437158701.2255.245.camel@gmail.com>

On Fri, 2015-07-17 at 10:39 -0300, Juan Vuletich wrote:
> Additional stuff about versioning, and how to keep your code working
> as Cuis changes.
> 
> Please share your ideas and thoughts about this.
> 
> We all want to ease development and maintenance of all sorts of
> projects while allowing a moderate rate of change to Cuis itself...
> 
> Cheers,
> Juan Vuletich
> 
> -------- Original Message -------- 
>                              From: 
> - Thu Jul 16 10:47:08 2015
>                  X-Mozilla-Status: 
> 0001
>                 X-Mozilla-Status2: 
> 00800000
>                    X-Mozilla-Keys: 
> 
> 
>                        Message-ID: 
> <55A7B5DA.1020103 at jvuletich.org>
>                              Date: 
> Thu, 16 Jul 2015 10:47:06 -0300
>                              From: 
> Juan Vuletich <juan at jvuletich.org>
>                        User-Agent: 
> Mozilla/5.0 (Windows; U; Windows NT
> 6.1; en-US; rv:1.9.2.28)
> Gecko/20120306 Thunderbird/3.1.20
>                      MIME-Version: 
> 1.0
>                                To: 
> H. Hirzel <hannes.hirzel at gmail.com>
>                           Subject: 
> Re: DIRECT version number
>                        References: 
> <CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA at mail.gmail.com> <55A7A607.7050304 at jvuletich.org> <CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
>                       In-Reply-To: 
> <CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
>                      Content-Type: 
> text/plain; charset=UTF-8;
> format=flowed
>         Content-Transfer-Encoding: 
> 7bit
> 
> 
> Hi Hannes,
> 
> On 7/16/2015 9:57 AM, H. Hirzel wrote:
> > Thank you Juan, for answering.
> >
> > At the moment I feel uncomfortable using Cuis because it is currently
> > a quite fast moving target. I perceive quite a number of API changes
> > though this might be wrong. But I do not know because there are no
> > release notes which summarize it.
> 

I totally feel Hannes' pain having gone through it a few times myself
over the years.  At the same time, I agree with Ken's point about not
getting too bogged down in process since we're in the best position
right now to break things for the better longer term.

> Yes, that's true. Besides, we don't have a specification of what is an 
> API and what is not. So, almost any change can be considered an API change.
> 

That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
issue, not specific to Cuis)  I believe it is largely fixable without
tons of documentation and tests: the use of private (categories or
method naming convention).  Bernhard pointed out an existing capability
a few months ago
http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
While I personally like the idea of private categories, one of these
approaches should really be seriously considered.

Other than a few specific examples (i.e. mostly the base data types
including the Collection and Number class hierarchies which are pretty
mature and don't change all that much anyway) I would guesstimate that
<20% (probably closer to 10%) of the methods, and and unknown % of
classes (a significantly larger fraction though), should even be
considered public.  If things were indicated as private that would
accomplish two things:

1) We could construct some simple tooling (some combination of up-front
warnings in the editor and/or a lint-type tester after the fact) that
would allow people to identify problematic calls within their code.
(i.e. just because it works now doesn't mean it always will if you keep
calling X, Y, Z...)

2) It would provide a way for people to know if something needs to be
discussed.  i.e. 'In class X method Y is private but I need that type of
functionality' so you would know that there's a need and could consider
either making it public, and therefore supported, or rethinking its
implementation if you'd like to offer a better public API solution.

> I don't want you to feel uncomfortable. Let's work this out.
> 
> >   And I do not now in which state my stuff and the general Cuis stuff ist.
> >
> > I need a new 'base line', i.e. a release number to which I can refer
> > to when upgrading my code.
> 
> Well, but we do have that. It is the update number. It is part of any 
> Cuis image I've ever committed to the repo.
> 
> The problem, I think, is not identifying well defined Cuis releases. The 
> problem is knowing how updates could affect your code.
> 

By narrowing the scope of what the public API is using private
designators, this dramatically reduces what you need to be concerned
with on this front.  It's part of the reason that Apple, Google, and
even Microsoft are so adamant about public APIs these days.  They dealt
with the pain of even major developers depending on private APIs for
decades. It's only been in the last 10 years or so that they've been
able to dig themselves out from under this issue.

This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
attitude of 'you have the source, play around, have fun!' has morphed
into 'everything is a public API!  there are no rules! isn't this
great?'  Well no, it's not great.  It makes life impossible for image
maintainers (Squeak has been in a coma for the last decade or so as the
result of trying to keep everyone happy... yet no one seems to be) and
miserable for those who are trying to keep code running on it (stuff
still breaks all the time.)

I personally believe the minimalism and simplicity that Cuis is based on
has the best long term prospects but we have to get out of this
'everything is public' mindset.  Sure, we have all the source: look at
it, learn from it, poke around, refactor it, submit fixes, etc.  But
there needs to be a manageable subset of it which is considered the
'public API' that people can depend on to write frameworks and apps on
top of that is relatively stable longer term.  Let's start defining what
that is and backfill changes to the public API (which will happen from
time to time as we don't want things to be completely static) with tests
and documentation so you can focus your efforts on where they matter
most and you get the most enjoyment from.

> > Of course the other option  is to just follow the most recent update
> > all the time. That would  call for some kind of continuous integration
> > testing 'Cuis style' which I not have either.
> >
> > E.g. if you could do a writeup how you do test Cuis before each new
> > commit (there are over 50 this year) and which scripts you use I could
> > apply the same thing for my packages.
> >
> > It has to be something which can be done quickly. Semi-Automatic is
> > fine. A check list with
> >
> > - do this
> > - then execute that script
> > - Open .. this and that
> > - And finally run a report on  ...
> >
> > would be fine.
> 
> I don't have that either. I run the tests from time to time (I'll start 
> doing it before any commit, and add the xml report to the rep). But this 
> is not the most important reason why Cuis is solid. Cuis is very 
> reliable because:

reliable != stable

> - I'm not too bad as a coder.
> - I do my own code revisions at least one day after each change.
> - I use Cuis every day, and spot most problems in the updates, before 
> commtting them to the repo.
> - I really, really care about code quality.
> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that 
> is a big responsibility, given how important I think Smalltalk-80 is.
> 

Agree to all this and more.  Cuis would not be where it is without your
continued effort and diligence. (i.e. setting aside that you obviously
created it, if you had just tossed it out into the world and let it go
at best it would have started looking something like Squeak or Pharo by
now.  It's a lot of effort over the long term to *keep* it small and
focused.  THANK YOU JUAN!)

> So, I suggest running your tests when updating your image, or migrating 
> your code to an updated image.
> 

+1 to tests as they do help quite a bit and are a very good practice.
Just be judicious in what/where you test (I personally don't subscribe
to the TDD approach where you spend your days mostly writing tests.
That's just admitting defeat in that you spend all day writing
executable documentation.)

> In any case, I think this doesn't answer your concerns. What you need is 
> some way to know which updates could affect you, to review them in 
> detail, and understanding their effect on your code. A list of the 
> affected classes and/or methods for each update makes no sense. Cuis can 
> already show you that very easily. Perhaps each update should include:
> 
> 1) parts of the system that are affected:
> - Kernel
> - Compiler
> - Tools
> - Morphic
> - etc
> 
> 2) Level of risk involved
> - very unlikely to break code that depends on this part of the system
> - could perhaps break code that depends on this part of the system
> - will most likely break code that depends on this part of the system
> 
> Or something like that.
> 
> BTW, this is a very relevant topic for discussing on the mail list. Feel 
> free to answer there if you agree.
> 

One final thought on this:  I suspect a major cause of people abandoning
Cuis (and Smalltalk in general), behind the 'it's too different from
what I'm used to'/'not mainstream' reaction, is the instability of its
APIs.

> Cheers,
> Juan Vuletich
> 
> 
> > However doing a release tag in github is really not a big deal if you
> > actually take the plunge.
> >
> > You are not alone in not using this option.
> >
> > It took me two years to realize that I can learn to do it and actually
> > do a release in 5 minutes.....
> >
> > So I suggest do a release just continuing where you left off last time.
> >
> > Then people will start to realise there is something to test against.
> > And new update requests will come and you can do another one.
> >
> > So the release which I am asking for is not a big deal. Just a tag on a commit.
> >
> > I'd like to explore the direct authoring tools offered by Ken Dickey.
> >
> > With the aim of producing a very simple Hypercard / Powerpoint like
> > authoring environment.
> >
> > And do more with OMeta.
> >
> > Happy continued Cuis curating .....
> > And thank you very much indeed for your great work maintaining this environment.
> >
> >
> > Hannes
> >
> >
> >
> > On 7/16/15, Juan Vuletich<juan at jvuletich.org>  wrote:
> >> On 7/12/2015 6:27 PM, H. Hirzel wrote:
> >>> Hi Juan
> >>>
> >>> Regarding a Cuis version number. I suggest that you just continue with
> >>> a new version number where you left off last time.
> >>>
> >>> It is just about having a version number to have a new baseline to
> >>> refer to. This is helpful for testing and documentation.
> >>>
> >>> I do not think it is a big issue.
> >>>
> >>> API changes require a new version number.
> >>>
> >>> Kind regards
> >>> Hannes
> >> Hi Hannes,
> >>
> >> Sometimes I don't pay enough attention to stuff like this, so feel free
> >> to request action from me when you feel appropriate :)
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From Ken.Dickey at whidbey.com  Fri Jul 17 14:11:02 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 17 Jul 2015 12:11:02 -0700
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <E772B770227A414C8E4912293F62ED5A@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
Message-ID: <20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>

HyperCard Factoids

- The reason that HyperCard failed to support color for many years was that the project leader was color blind and could not see using all those extra bits just to support color. [Someone at Apple told me this, I forget who.]

- The original Myst was developed & deployed using HyperCard. [I found this out from Robyn and Rand Miller when they visited Apple.]

FYI,
-KenD



From 0800nacho at gmail.com  Fri Jul 17 14:37:36 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Fri, 17 Jul 2015 16:37:36 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
	<20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
Message-ID: <CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>

This is a good resource for HyperCard and HyperTalk

http://hypercard.org

cheers
Nacho


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

*Tel: (011) 4542-6714*


















On Fri, Jul 17, 2015 at 4:11 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

> HyperCard Factoids
>
> - The reason that HyperCard failed to support color for many years was
> that the project leader was color blind and could not see using all those
> extra bits just to support color. [Someone at Apple told me this, I forget
> who.]
>
> - The original Myst was developed & deployed using HyperCard. [I found
> this out from Robyn and Rand Miller when they visited Apple.]
>
> FYI,
> -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/20150717/190ea4f7/attachment-0002.html>

From hannes.hirzel at gmail.com  Fri Jul 17 17:21:50 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Fri, 17 Jul 2015 22:21:50 +0000
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
	<20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
	<CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
Message-ID: <CAGQxfVh_0LZv+AzQMep1urFYpP36qqdeKmcG01x_-wQyUj3gFg@mail.gmail.com>

At the moment my interest is in creating a very small subset of Hypercard

Pictures on cards with a caption and buttons. Plus cards with bullet lists.

I postpone the direct manipulation aspect currently. I describe what
is on the cards with Smalltalk (you may call it a "DSL" for describing
stacks). And I have a reader for MarkDown and other similar types of
input.

These very days I focus on generating export formats (Just a sequence
of JPEGs to put on a tablet as is, LibreOffice Writer, LibreOffice
Impress, Large JPEG with many cards to create a poster, Microsoft
Word, Powerpoint, Markdown e.g. https://www.swipe.to/).  I work on
Pharo 4 at the moment and I aim at easy porting to Cuis.

More interaction will come later (drag and drop activities).


For a fairly recent Hypercard in Smalltalk / Squeak discussions see
the Squeak mailing list

Feb 24, 2013 at 10:54 AM
About HyperCard

A thread started by Edgar. I downloaded the sample image and could run
a stack like the Hypercard help stack in Squeak (screen shot
attached).


Below an extract of that thread.

-- Hannes


Feb 24, 2013 at 10:54 AM
About HyperCard

http://www.vpri.org/pdf/m2011001_dbjr_spec.pdf

DynaBook Junior Specification
by Ted Kaehler
14 Jan 2009. (Minor corrections 13 Dec 2010)
A specification for DynaBook Junior
shown in itself.
DBJr is a desktop publishing framework and
application builder that is modeled after Apple's HyperCard.

Abstract
DynaBook Junior is a desktop publishing
framework and application builder that is
modeled after Apple's HyperCard(tm). The
purpose of this specification is as a starting
point for the discovery of an extremely simple
way to describe and automatically generate
DynaBook Junior. The specification describes
stacks, pages, backgrounds, objects
embedded in pages, the front-to-back ordering
of objects, and page-specific objects. This
document is itself a DBJr stack that shows
examples of the features it describes.
Algorithms for showing a new page, adding
pages, adding backgrounds, and adding
objects to a page are given in pseudocode.


http://tinlizzie.org/lesserphic2/

download the example stack
http://tinlizzie.org/lesserphic2/aboutDBJr%205-Aug.morph
in addition, locate it with the file browser and then choose 'load as morph'

....
While the DynaBookJr (I always misread "DBJr" as "DataBase Jr") is
indeed a good modern replacement for HyperCard, isn't the normal
BookMorph already available in Squeak a reasonable approximation?

...
The Lesserphic version of DBJr is considered to be obsolete.  It uses
the "Etoys-style" uniclasses for pages but we later figured out a
simpler way of implementing it.
...


http://www.vpri.org/pdf/m2013003_ksapps.pdf


... research report 'Making
applications in KSWorld' and the equally interesting report of October
2012 'A Report on KScript and KSWorld'
http://www.vpri.org/html/writings.php

Chapter 6 of the the October report talks about  the hosting
environment which happens to be Squeak

<citation>
Hosting Environment: Squeak
As of this writing, the KSWorld is hosted on top of Squeak Smalltalk [10]. A
special Morphic widget called KSMorph is created under RectangleMorph.
</citation>


....

In the new document, Section
7.1 discusses the "Document Model" and Section 8.9 says it took about
200 lines to implement.




On 7/17/15, Ignacio Sniechowski <0800nacho at gmail.com> wrote:
> This is a good resource for HyperCard and HyperTalk
>
> http://hypercard.org
>
> cheers
> Nacho
>
>
> *Lic. Ignacio Sniechowski, MBA*
> *Prosavic SRL*
>
> *Tel: (011) 4542-6714*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jul 17, 2015 at 4:11 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
>
>> HyperCard Factoids
>>
>> - The reason that HyperCard failed to support color for many years was
>> that the project leader was color blind and could not see using all those
>> extra bits just to support color. [Someone at Apple told me this, I
>> forget
>> who.]
>>
>> - The original Myst was developed & deployed using HyperCard. [I found
>> this out from Robyn and Rand Miller when they visited Apple.]
>>
>> FYI,
>> -KenD
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StackInDynaBookJunior.gif
Type: image/gif
Size: 55598 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150717/e0b2194d/attachment-0002.gif>

From edgardec2005 at gmail.com  Sat Jul 18 05:55:16 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Sat, 18 Jul 2015 07:55:16 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
	<20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
	<CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
Message-ID: <40788499-8CB3-4134-97A2-FE1EFA13598F@gmail.com>


> On Jul 17, 2015, at 4:37 PM, Ignacio Sniechowski <0800nacho at gmail.com> wrote:
> 
> This is a good resource for HyperCard and HyperTalk
> 
> http://hypercard.org <http://hypercard.org/>

Ignacio beats me.

But I download Stacksmith and CinsImp
Seems https://github.com/uliwitness/Stacksmith <https://github.com/uliwitness/Stacksmith> and http://hammer-language.com/ <http://hammer-language.com/> should be the docs to read.

Excited !!!

Edgar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150718/2cf88a47/attachment-0002.html>

From dnorton at mindspring.com  Sat Jul 18 13:33:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 14:33:35 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <20150710165144.ece0f54787132fed1278bdc4@whidbey.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A0178E.16257.13666A4@dnorton.mindspring.com>,
	<20150710165144.ece0f54787132fed1278bdc4@whidbey.com>
Message-ID: <55AA9BFF.3085.11B851C@dnorton.mindspring.com>

On 10 Jul 2015 at 16:51, Ken.Dickey wrote:

> On Fri, 10 Jul 2015 15:05:50 -0400
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> > Yes, the only font now is DejaVu and it's a bitmap font. I found
> some fixed bitmap fonts 
> > among the true types at:
> > 
> > http://www.lowing.org/fonts/
> > 
> > Adding a sublcass to AbstractFont to load one of these might be
> doable near-term until 
> > Morphic 3 comes along. Porting TrueType from Squeak has a lot of
> drag.
> 
> My Cuis-Smalltalk-Unicode package subclasses AbstractFont and
> provides fixed width characters.
> 
> See class #UniForms 
> 
> Unicode is kinda big, memory wise.  I suspect one should be able to
> take the ASCII subset of the Unicode glyphs and make a strike font
> -- or just do what I did for Unicode, but just use the ASCII
> subset.
> 
> FYI,
> -KenD

That is awesome, Ken.

 - Dan



From dnorton at mindspring.com  Sat Jul 18 13:37:16 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 14:37:16 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A146FC.4020402@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A146FC.4020402@jvuletich.org>
Message-ID: <55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>

On 11 Jul 2015 at 13:40, Juan Vuletich wrote:

> Hi Folks,
> 
> It is not too hard to build new StrikeFonts. You need to build, by
> hand, 
> files like the ones in here: 
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> p 
> and learn a bit about stuff like #installDejaVu2 . Maybe it was with
> this method and the files in this zip that built the existing
> instances 
> of StrikeFont. Not sure.
> 

That's intrigueing but I can't reproduce it. Maybe the .bmp but where did you get the .txt?

 - Dan



From dnorton at mindspring.com  Sat Jul 18 13:56:46 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 14:56:46 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A14859.2080409@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A0178E.16257.13666A4@dnorton.mindspring.com>,
	<55A14859.2080409@jvuletich.org>
Message-ID: <55AAA16E.24887.130BE16@dnorton.mindspring.com>

On 11 Jul 2015 at 13:46, Juan Vuletich wrote:

> On 7/10/2015 4:05 PM, Dan Norton wrote:
> > ...
> > Yes, the only font now is DejaVu and it's a bitmap font. I found
> some fixed bitmap fonts
> > among the true types at:
> >
> > http://www.lowing.org/fonts/
> >
> > Adding a sublcass to AbstractFont to load one of these might be
> doable near-term until
> > Morphic 3 comes along. Porting TrueType from Squeak has a lot of
> drag.
> >
> 
> ProFontWindows doesn't look bad. In any case, I built the Bitmap
> DejaVu 
> fonts in Cuis (and Squeak and Pharo) by capturing the bits from the
> screen of a text editor, running the TTF. You can do the same with
> DejaVu Sans Mono or any other TTF / OTF / whatever.
>

Currently I am porting TrueType. By way of a progress report, drag has been reduced and by 
installing

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

and cmd-d "tt := TTFontReader parseFileNamed:'c:\windows\fonts\cour.ttf'" you have a true 
type instance "tt" which, when explored, bears a strong resemblance to the same thing if 
done on Squeak, according to my eyeballs.

Now to transform(?) convert(?) this font to something which can be added to AvailableFonts 
and used. WIBGI it could be used as is? There are several fixed-width fonts in the .ttf set.

 - Dan



From hannes.hirzel at gmail.com  Sat Jul 18 13:58:53 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 18 Jul 2015 18:58:53 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A1475D.3030501@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<55A1475D.3030501@jvuletich.org>
Message-ID: <CAGQxfVjJsjkj1BRj_KoKHH4AZsdSDfMFWZ764-L=5rBPqB1k0Q@mail.gmail.com>

On 7/11/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/10/2015 11:20 AM, Dan Norton wrote:
>> ...
>> Browsing through strike fonts, I see no fixed widths. But, true type fonts
>> have a few
>> fixed-width examples. There seems to be no way to install a .ttf in Cuis
>> currently.
>>
>> Can we port TrueType-Support from Squeak?
>>
>> Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits
>> from AbstractFont?
>>
>> Any hints or guidance would be most welcomed.
>>
>
> I'd say, stick to StrikeFonts, and learn to build new ones. I the other
> message I just sent, I included more details.

+1

or copy a strikefont from Squeak. The Squeak wiki has a lot of
material about Strikefont.



> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Sat Jul 18 14:04:18 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 12:04:18 -0700 (PDT)
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AAA16E.24887.130BE16@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
	<55A14859.2080409@jvuletich.org>
	<55AAA16E.24887.130BE16@dnorton.mindspring.com>
Message-ID: <1437246258310-4838103.post@n4.nabble.com>

Correction:

Currently I am porting TrueType. By way of a progress report, drag has been
reduced and by 
installing /the TrueType package from:/

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

etc.



--
View this message in context: http://forum.world.st/Fixed-Width-Font-tp4836695p4838103.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From hannes.hirzel at gmail.com  Sat Jul 18 14:10:52 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 18 Jul 2015 19:10:52 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <1437246258310-4838103.post@n4.nabble.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
	<55A14859.2080409@jvuletich.org>
	<55AAA16E.24887.130BE16@dnorton.mindspring.com>
	<1437246258310-4838103.post@n4.nabble.com>
Message-ID: <CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>

https://github.com/dhnorton/Cuis-Smalltalk-fonts/blob/master/Graphics-Text.pck.st#L2

says

    "Description A stripped-down package with changes only to
AbstractFont and StrikeFont."

I assume the code is from the current Squeak 4.6?

--HH

On 7/18/15, Dan Norton <dnorton at mindspring.com> wrote:
> Correction:
>
> Currently I am porting TrueType. By way of a progress report, drag has been
> reduced and by
> installing /the TrueType package from:/
>
> https://github.com/dhnorton/Cuis-Smalltalk-fonts
>
> etc.
>
>
>
> --
> View this message in context:
> http://forum.world.st/Fixed-Width-Font-tp4836695p4838103.html
> Sent from the Cuis Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Sat Jul 18 14:27:25 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 15:27:25 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<1437246258310-4838103.post@n4.nabble.com>,
	<CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
Message-ID: <55AAA89D.29698.14CCC69@dnorton.mindspring.com>

On 18 Jul 2015 at 19:10, H. Hirzel wrote:

> https://github.com/dhnorton/Cuis-Smalltalk-fonts/blob/master/Graphic
> s-Text.pck.st#L2
> 
> says
> 
>     "Description A stripped-down package with changes only to
> AbstractFont and StrikeFont."
> 
> I assume the code is from the current Squeak 4.6?
> 
> --HH
> 

No, Squeak 4.5.

 - Dan



From dnorton at mindspring.com  Sat Jul 18 14:41:19 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 15:41:19 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<1437246258310-4838103.post@n4.nabble.com>,
	<CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
Message-ID: <55AAABDF.5892.15986B3@dnorton.mindspring.com>

On 18 Jul 2015 at 19:10, H. Hirzel wrote:

> https://github.com/dhnorton/Cuis-Smalltalk-fonts/blob/master/Graphic
> s-Text.pck.st#L2
> 
> says
> 
>     "Description A stripped-down package with changes only to
> AbstractFont and StrikeFont."
> 
> I assume the code is from the current Squeak 4.6?
> 
> --HH
> 

Actually, the code is from Cuis, now that I take a closer look.

 - Dan



From Ken.Dickey at whidbey.com  Sat Jul 18 23:33:48 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sat, 18 Jul 2015 21:33:48 -0700
Subject: [Cuis] #printStringLimitedTo:
Message-ID: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>

I find it kind of odd that #printStringLimitedTo: takes the prefix of a too-long string and adds '...etc...', which itself is 9 characters.

I think a shorter addition would make more sense.  After all, the string is already too long, right?

I like '[..]' , which is only four characters. 

Would anyone else like to weigh in on this?  Other options?

-KenD



From pbpublist at gmail.com  Sun Jul 19 01:04:59 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 02:04:59 -0400
Subject: [Cuis] #printStringLimitedTo:
In-Reply-To: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>
References: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>
Message-ID: <1437285899.6934.1.camel@gmail.com>

On Sat, 2015-07-18 at 21:33 -0700, Ken.Dickey wrote:
> I find it kind of odd that #printStringLimitedTo: takes the prefix of a too-long string and adds '...etc...', which itself is 9 characters.
> 
> I think a shorter addition would make more sense.  After all, the string is already too long, right?
> 
> I like '[..]' , which is only four characters. 
> 
> Would anyone else like to weigh in on this?  Other options?

I agree that the current suffix is long-ish and like your [..] idea as
that's unlikely to appear in the majority of strings but would still
convey the information.

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





From juan at jvuletich.org  Sun Jul 19 08:31:14 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 19 Jul 2015 10:31:14 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A146FC.4020402@jvuletich.org>
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
Message-ID: <55ABA6A2.5090607@jvuletich.org>

On 7/18/2015 3:37 PM, Dan Norton wrote:
> On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>
>> Hi Folks,
>>
>> It is not too hard to build new StrikeFonts. You need to build, by
>> hand,
>> files like the ones in here:
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> p
>> and learn a bit about stuff like #installDejaVu2 . Maybe it was with
>> this method and the files in this zip that built the existing
>> instances
>> of StrikeFont. Not sure.
>>
> That's intrigueing but I can't reproduce it. Maybe the .bmp but where did you get the .txt?
>
>   - Dan

I wrote them with a text editor. Check #installDejaVu2 and really try to 
understand how StrikeFonts work and how they are built with this method. 
Maybe you'll become enlightened.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sun Jul 19 09:20:19 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 19 Jul 2015 11:20:19 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437158701.2255.245.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
Message-ID: <55ABB223.8010309@jvuletich.org>

Hi Folks,

(inline)

On 7/17/2015 3:45 PM, Phil (list) wrote:
> ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>> Thank you Juan, for answering.
>>>
>>> At the moment I feel uncomfortable using Cuis because it is currently
>>> a quite fast moving target. I perceive quite a number of API changes
>>> though this might be wrong. But I do not know because there are no
>>> release notes which summarize it.
> I totally feel Hannes' pain having gone through it a few times myself
> over the years.  At the same time, I agree with Ken's point about not
> getting too bogged down in process since we're in the best position
> right now to break things for the better longer term.
>
>> Yes, that's true. Besides, we don't have a specification of what is an
>> API and what is not. So, almost any change can be considered an API change.
> That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
> issue, not specific to Cuis)  I believe it is largely fixable without
> tons of documentation and tests: the use of private (categories or
> method naming convention).  Bernhard pointed out an existing capability
> a few months ago
> http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
> While I personally like the idea of private categories, one of these
> approaches should really be seriously considered.
>
> Other than a few specific examples (i.e. mostly the base data types
> including the Collection and Number class hierarchies which are pretty
> mature and don't change all that much anyway) I would guesstimate that
> <20% (probably closer to 10%) of the methods, and and unknown % of
> classes (a significantly larger fraction though), should even be
> considered public.  If things were indicated as private that would
> accomplish two things:
>
> 1) We could construct some simple tooling (some combination of up-front
> warnings in the editor and/or a lint-type tester after the fact) that
> would allow people to identify problematic calls within their code.
> (i.e. just because it works now doesn't mean it always will if you keep
> calling X, Y, Z...)
>
> 2) It would provide a way for people to know if something needs to be
> discussed.  i.e. 'In class X method Y is private but I need that type of
> functionality' so you would know that there's a need and could consider
> either making it public, and therefore supported, or rethinking its
> implementation if you'd like to offer a better public API solution.

Ok. Doing something along these lines would be great. But please note 
that it is a rather large amount of work. It is not something I'm able 
or willing to do it alone. If you (any of you all, not just Phil) wants 
to start defining the API for any part of the system or optional 
packages, please start doing it and send the changesets to the list. If 
we get this working, I'll start the tools you mention.

<slowly diverging into OT rant>

On the other hand (and please forgive me if this kills a bit of 
momentum), I don't really think we are changing APIs that much. And I 
don't think we'll be doing it any more in the future than we do today, 
at least in the base image. I hope to see most of the activity and 
incompatible changes to happen in optional packages, and affecting 
package dependencies... Mhhh, now that I write this I think that it 
doesn't really go against the idea of defining APIs. Maybe APIs in the 
base image will almost never change or be a problem, but packages should 
provide APIs too... Optional packages will (I hope!) always be 
improving, and new ones will appear all the time.

If all this work, the Cuis will be a lot less about my personal effort 
and coding style, and the packages maintained by each one of us will 
become the main characters in this story. And this will be a very good 
thing. The base image should be about providing a good base for doing 
the really interesting stuff on top...

Let me tell you a bit about how Cuis got started. Many years ago I did 
my thesis on audio/music processing. The I wanted to turn that into a 
novel and fun application for musicians (both pros and anyone willing to 
play with sound). I started to think about how a good GUI for that could 
be, giving the feeling of modifying sound by direct manipulation of it, 
as if it was clay, as if it was visual and not just auditory. Well, that 
was the start of my questioning of the whole GUI business and Morphic 3. 
And it became clear to me that Squeak had turned into something that was 
not the best possible environment to do all this. The idea of "fixing" 
Squeak, and thus make Cuis, was born. So, Cuis was not and end in 
itself, but a means for allowing experimentation, freedom to build 
applications in new styles, etc.

(The idea that Cuis is a truer Smalltalk-80 than Squeak or any other 
came later, as an observation on facts.)

So, when the moment comes when Cuis stabilizes a bit, and interest moves 
to packages and applications built by all us, Cuis will start to fulfill 
its original objective.

</slowly diverging into OT rant>

>> ...
>> The problem, I think, is not identifying well defined Cuis releases. The
>> problem is knowing how updates could affect your code
> By narrowing the scope of what the public API is using private
> designators, this dramatically reduces what you need to be concerned
> with on this front.  It's part of the reason that Apple, Google, and
> even Microsoft are so adamant about public APIs these days.  They dealt
> with the pain of even major developers depending on private APIs for
> decades. It's only been in the last 10 years or so that they've been
> able to dig themselves out from under this issue.
>
> This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
> attitude of 'you have the source, play around, have fun!' has morphed
> into 'everything is a public API!  there are no rules! isn't this
> great?'  Well no, it's not great.  It makes life impossible for image
> maintainers (Squeak has been in a coma for the last decade or so as the
> result of trying to keep everyone happy... yet no one seems to be) and
> miserable for those who are trying to keep code running on it (stuff
> still breaks all the time.)

Yes.

> I personally believe the minimalism and simplicity that Cuis is based on
> has the best long term prospects but we have to get out of this
> 'everything is public' mindset.  Sure, we have all the source: look at
> it, learn from it, poke around, refactor it, submit fixes, etc.  But
> there needs to be a manageable subset of it which is considered the
> 'public API' that people can depend on to write frameworks and apps on
> top of that is relatively stable longer term.  Let's start defining what
> that is and backfill changes to the public API (which will happen from
> time to time as we don't want things to be completely static) with tests
> and documentation so you can focus your efforts on where they matter
> most and you get the most enjoyment from.

I fully agree and support this.
Maybe an alternative to yet-another-convention-on-categories could be to 
mark public methods with a pragma, or make them send 'self publicAPI' or 
such... This could be better for the tools, also.

> ...
>> I don't have that either. I run the tests from time to time (I'll start
>> doing it before any commit, and add the xml report to the rep). But this
>> is not the most important reason why Cuis is solid. Cuis is very
>> reliable because:
> reliable != stable

;)

>> - I'm not too bad as a coder.
>> - I do my own code revisions at least one day after each change.
>> - I use Cuis every day, and spot most problems in the updates, before
>> commtting them to the repo.
>> - I really, really care about code quality.
>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>> is a big responsibility, given how important I think Smalltalk-80 is.
>>
> Agree to all this and more.  Cuis would not be where it is without your
> continued effort and diligence. (i.e. setting aside that you obviously
> created it, if you had just tossed it out into the world and let it go
> at best it would have started looking something like Squeak or Pharo by
> now.  It's a lot of effort over the long term to *keep* it small and
> focused.  THANK YOU JUAN!)

Thanks for your nice words, Phil. I really appreciate that you all 
accept this rather restrictive dev model for the base image, in contrast 
with a more open trunk style. Hopefully, as the base image becomes 
stable and almost irrelevant, this will be each time less of a problem.

>> So, I suggest running your tests when updating your image, or migrating
>> your code to an updated image.
> +1 to tests as they do help quite a bit and are a very good practice.
> Just be judicious in what/where you test (I personally don't subscribe
> to the TDD approach where you spend your days mostly writing tests.
> That's just admitting defeat in that you spend all day writing
> executable documentation.)

<OT>

I don't subscribe to "extreme" TDD either. To me design is a creative 
activity, both technical and artistic. It should be "driven" by 
creativity and intelligence, not by a process. Any xDD process is 
admitting defeat on design itself!

</OT>

>> In any case, I think this doesn't answer your concerns. What you need is
>> some way to know which updates could affect you, to review them in
>> detail, and understanding their effect on your code. A list of the
>> affected classes and/or methods for each update makes no sense. Cuis can
>> already show you that very easily. Perhaps each update should include:
>>
>> 1) parts of the system that are affected:
>> - Kernel
>> - Compiler
>> - Tools
>> - Morphic
>> - etc
>>
>> 2) Level of risk involved
>> - very unlikely to break code that depends on this part of the system
>> - could perhaps break code that depends on this part of the system
>> - will most likely break code that depends on this part of the system
>>
>> Or something like that.
>>
>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>> free to answer there if you agree.
> One final thought on this:  I suspect a major cause of people abandoning
> Cuis (and Smalltalk in general), behind the 'it's too different from
> what I'm used to'/'not mainstream' reaction, is the instability of its
> APIs.

Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) 
is a PITA too...

As a bottom line, let me repeat: This is too big for me to do it. 
Please, folks, start documenting the APIs you most care about.

Cheers,
Juan Vuletich



From peter at aba-instituut.nl  Sun Jul 19 11:02:20 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Sun, 19 Jul 2015 18:02:20 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55ABB223.8010309@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
Message-ID: <CAJBxtBY7YtLCJwVSOM3w58shed-YcnON=BL2WD2xM6EAMVbn2A@mail.gmail.com>

Hey all,

Just 2 cents from a Cuis noob:

1. Releases... since this stuff is not being sold for money and not being
distributed using off-line media, what use does a "release" have? I like
that stuff gets improved as often as possible. I believe that the things
that get improved the most often, have the best chance of becoming
something really good.

So, I am for adopting practices that increase the number of improvements.
Practices that decrease the number of deteriorations seem helpful as well.
See below if you wonder what my point is ;-).

2. Public vs private API. Stable APIs are nice, if you can get them. If you
have authors who develop a base, and other authors who (have to) develop ON
that base, you need stable APIs, or you will lose the authors dependent on
your base.

So, do we really have those different author groups? Somehow I doubt it. I
recently changed the scoping rules for shared variables (I think they're
done wrong in the base image). I could change what I wanted easily. So I
think I am not in some outsider author group. Instead I am happy that I
could change what I wanted without needing anyone's approval or cooperation.

Suppose we were making money from outside author groups who want us to keep
certain APIs stable. For the right price, I would be happy to provide that
for them. In the mean time, I can live with free. Free to change what I
want, free to use without paying, and others free to change what I am
building on (sometimes frustrating).

3. Maybe what will help everybody is something that prevents functionality
from being lost, especially *unintentionally*. This can include certain
APIs as well. So what if an author who values a certain API, could invest
some of his own time/money, to protect that API? What if he could write a
software component (let's say a class) that was able to detect whenever an
image did not provide the desired API? What if he could submit that class,
and everybody who cared about not breaking that API, could use that class
to see if perhaps they broke it?

4. I believe the idea could be generalized to include any feature of (the
code in) an image for which presence or absence (as may be the case) can be
determined by such a class. Bugs could be reified as classes, and the
presence or absence of the bug could be determined by that class. Feature
requests could be reified as classes, and whether or not the feature had
actually been implemented could be determined by that class.

5. The things I am proposing would basically be Feature Tests, and would be
rather different from Unit Tests (which apply to a unit and which you want
to all be green when you share your software with users of it). Feature
Tests would apply to a system (not a unit) and simply indicate which
features are and which features are not present in the system. Every
"release" could then come with a) the assertion that all the Unit Tests
passed b) a list of the Feature Tests that passed and those that did not.

6. I think it would be pretty cool if people sent in feature requests in
the form of Feature Tests, instead of messages to the mailing list (or the
request tracker). So that anybody who (wished to impress somebody and) had
some time on their hands, could then try to implement the functionality
that made the Feature Test pass.

Hope this helps somebody with something :)

Cheers, Peter

On Sun, Jul 19, 2015 at 4:20 PM, Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Folks,
>
> (inline)
>
> On 7/17/2015 3:45 PM, Phil (list) wrote:
>
>> ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>
>>> Thank you Juan, for answering.
>>>>
>>>> At the moment I feel uncomfortable using Cuis because it is currently
>>>> a quite fast moving target. I perceive quite a number of API changes
>>>> though this might be wrong. But I do not know because there are no
>>>> release notes which summarize it.
>>>>
>>> I totally feel Hannes' pain having gone through it a few times myself
>> over the years.  At the same time, I agree with Ken's point about not
>> getting too bogged down in process since we're in the best position
>> right now to break things for the better longer term.
>>
>>  Yes, that's true. Besides, we don't have a specification of what is an
>>> API and what is not. So, almost any change can be considered an API
>>> change.
>>>
>> That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
>> issue, not specific to Cuis)  I believe it is largely fixable without
>> tons of documentation and tests: the use of private (categories or
>> method naming convention).  Bernhard pointed out an existing capability
>> a few months ago
>> http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
>> While I personally like the idea of private categories, one of these
>> approaches should really be seriously considered.
>>
>> Other than a few specific examples (i.e. mostly the base data types
>> including the Collection and Number class hierarchies which are pretty
>> mature and don't change all that much anyway) I would guesstimate that
>> <20% (probably closer to 10%) of the methods, and and unknown % of
>> classes (a significantly larger fraction though), should even be
>> considered public.  If things were indicated as private that would
>> accomplish two things:
>>
>> 1) We could construct some simple tooling (some combination of up-front
>> warnings in the editor and/or a lint-type tester after the fact) that
>> would allow people to identify problematic calls within their code.
>> (i.e. just because it works now doesn't mean it always will if you keep
>> calling X, Y, Z...)
>>
>> 2) It would provide a way for people to know if something needs to be
>> discussed.  i.e. 'In class X method Y is private but I need that type of
>> functionality' so you would know that there's a need and could consider
>> either making it public, and therefore supported, or rethinking its
>> implementation if you'd like to offer a better public API solution.
>>
>
> Ok. Doing something along these lines would be great. But please note that
> it is a rather large amount of work. It is not something I'm able or
> willing to do it alone. If you (any of you all, not just Phil) wants to
> start defining the API for any part of the system or optional packages,
> please start doing it and send the changesets to the list. If we get this
> working, I'll start the tools you mention.
>
> <slowly diverging into OT rant>
>
> On the other hand (and please forgive me if this kills a bit of momentum),
> I don't really think we are changing APIs that much. And I don't think
> we'll be doing it any more in the future than we do today, at least in the
> base image. I hope to see most of the activity and incompatible changes to
> happen in optional packages, and affecting package dependencies... Mhhh,
> now that I write this I think that it doesn't really go against the idea of
> defining APIs. Maybe APIs in the base image will almost never change or be
> a problem, but packages should provide APIs too... Optional packages will
> (I hope!) always be improving, and new ones will appear all the time.
>
> If all this work, the Cuis will be a lot less about my personal effort and
> coding style, and the packages maintained by each one of us will become the
> main characters in this story. And this will be a very good thing. The base
> image should be about providing a good base for doing the really
> interesting stuff on top...
>
> Let me tell you a bit about how Cuis got started. Many years ago I did my
> thesis on audio/music processing. The I wanted to turn that into a novel
> and fun application for musicians (both pros and anyone willing to play
> with sound). I started to think about how a good GUI for that could be,
> giving the feeling of modifying sound by direct manipulation of it, as if
> it was clay, as if it was visual and not just auditory. Well, that was the
> start of my questioning of the whole GUI business and Morphic 3. And it
> became clear to me that Squeak had turned into something that was not the
> best possible environment to do all this. The idea of "fixing" Squeak, and
> thus make Cuis, was born. So, Cuis was not and end in itself, but a means
> for allowing experimentation, freedom to build applications in new styles,
> etc.
>
> (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other came
> later, as an observation on facts.)
>
> So, when the moment comes when Cuis stabilizes a bit, and interest moves
> to packages and applications built by all us, Cuis will start to fulfill
> its original objective.
>
> </slowly diverging into OT rant>
>
>  ...
>>> The problem, I think, is not identifying well defined Cuis releases. The
>>> problem is knowing how updates could affect your code
>>>
>> By narrowing the scope of what the public API is using private
>> designators, this dramatically reduces what you need to be concerned
>> with on this front.  It's part of the reason that Apple, Google, and
>> even Microsoft are so adamant about public APIs these days.  They dealt
>> with the pain of even major developers depending on private APIs for
>> decades. It's only been in the last 10 years or so that they've been
>> able to dig themselves out from under this issue.
>>
>> This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
>> attitude of 'you have the source, play around, have fun!' has morphed
>> into 'everything is a public API!  there are no rules! isn't this
>> great?'  Well no, it's not great.  It makes life impossible for image
>> maintainers (Squeak has been in a coma for the last decade or so as the
>> result of trying to keep everyone happy... yet no one seems to be) and
>> miserable for those who are trying to keep code running on it (stuff
>> still breaks all the time.)
>>
>
> Yes.
>
>  I personally believe the minimalism and simplicity that Cuis is based on
>> has the best long term prospects but we have to get out of this
>> 'everything is public' mindset.  Sure, we have all the source: look at
>> it, learn from it, poke around, refactor it, submit fixes, etc.  But
>> there needs to be a manageable subset of it which is considered the
>> 'public API' that people can depend on to write frameworks and apps on
>> top of that is relatively stable longer term.  Let's start defining what
>> that is and backfill changes to the public API (which will happen from
>> time to time as we don't want things to be completely static) with tests
>> and documentation so you can focus your efforts on where they matter
>> most and you get the most enjoyment from.
>>
>
> I fully agree and support this.
> Maybe an alternative to yet-another-convention-on-categories could be to
> mark public methods with a pragma, or make them send 'self publicAPI' or
> such... This could be better for the tools, also.
>
>  ...
>>
>>> I don't have that either. I run the tests from time to time (I'll start
>>> doing it before any commit, and add the xml report to the rep). But this
>>> is not the most important reason why Cuis is solid. Cuis is very
>>> reliable because:
>>>
>> reliable != stable
>>
>
> ;)
>
>  - I'm not too bad as a coder.
>>> - I do my own code revisions at least one day after each change.
>>> - I use Cuis every day, and spot most problems in the updates, before
>>> commtting them to the repo.
>>> - I really, really care about code quality.
>>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>>> is a big responsibility, given how important I think Smalltalk-80 is.
>>>
>>>  Agree to all this and more.  Cuis would not be where it is without your
>> continued effort and diligence. (i.e. setting aside that you obviously
>> created it, if you had just tossed it out into the world and let it go
>> at best it would have started looking something like Squeak or Pharo by
>> now.  It's a lot of effort over the long term to *keep* it small and
>> focused.  THANK YOU JUAN!)
>>
>
> Thanks for your nice words, Phil. I really appreciate that you all accept
> this rather restrictive dev model for the base image, in contrast with a
> more open trunk style. Hopefully, as the base image becomes stable and
> almost irrelevant, this will be each time less of a problem.
>
>  So, I suggest running your tests when updating your image, or migrating
>>> your code to an updated image.
>>>
>> +1 to tests as they do help quite a bit and are a very good practice.
>> Just be judicious in what/where you test (I personally don't subscribe
>> to the TDD approach where you spend your days mostly writing tests.
>> That's just admitting defeat in that you spend all day writing
>> executable documentation.)
>>
>
> <OT>
>
> I don't subscribe to "extreme" TDD either. To me design is a creative
> activity, both technical and artistic. It should be "driven" by creativity
> and intelligence, not by a process. Any xDD process is admitting defeat on
> design itself!
>
> </OT>
>
>  In any case, I think this doesn't answer your concerns. What you need is
>>> some way to know which updates could affect you, to review them in
>>> detail, and understanding their effect on your code. A list of the
>>> affected classes and/or methods for each update makes no sense. Cuis can
>>> already show you that very easily. Perhaps each update should include:
>>>
>>> 1) parts of the system that are affected:
>>> - Kernel
>>> - Compiler
>>> - Tools
>>> - Morphic
>>> - etc
>>>
>>> 2) Level of risk involved
>>> - very unlikely to break code that depends on this part of the system
>>> - could perhaps break code that depends on this part of the system
>>> - will most likely break code that depends on this part of the system
>>>
>>> Or something like that.
>>>
>>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>>> free to answer there if you agree.
>>>
>> One final thought on this:  I suspect a major cause of people abandoning
>> Cuis (and Smalltalk in general), behind the 'it's too different from
>> what I'm used to'/'not mainstream' reaction, is the instability of its
>> APIs.
>>
>
> Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) is
> a PITA too...
>
> As a bottom line, let me repeat: This is too big for me to do it. Please,
> folks, start documenting the APIs you most care about.
>
> 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/20150719/8e5a281b/attachment-0002.html>

From hannes.hirzel at gmail.com  Sun Jul 19 14:48:04 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 19:48:04 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <55A90799.7080302@jvuletich.org>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
Message-ID: <CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>

If I use this to find out which methods have a time stamp date
indicating a change after the 1st of January 2015 in a pristine Cuis
4.2-2243 (17 April 2015) image I find out that only the

#postCopy method was changed (probably added) in nearly all classes.

If I change the base line date to 1st of January 2014 I get

a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy #at:ifAbsent:)
as changed/updated methods (i.e. methods which have a time stamp in
this period).

Of course this assumes that a method gets a time stamp when changed.
Many methods have nil as a time stamp.


Could somebody from the list check this please?


|date coll baseLineDate dt  updatedMethods |

baseLineDate := Date year: 2014 month: 1 day: 1.
coll := OrderedCollection new.

Smalltalk allClasses do: [ :cls |
cls allSelectors do: [ :sel |
dt := VersionsBrowser timeStampFor:  sel class: Dictionary reverseOrdinal:  1.

dt notNil ifTrue: [
date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
]) or: [ch = $:]] .
(date = '') ifFalse:
	[date := Date fromString: date.
		(date > baseLineDate) ifTrue: [coll add: (Association key:
(Association key: cls value: sel) value: date)
]]].

]].

updatedMethods := Set new.
coll do: [ :elem | updatedMethods add: (elem key value)].
coll inspect.
updatedMethods inspect




On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/16/2015 11:49 AM, H. Hirzel wrote:
>> Hello
>>
>> I'd like to do a query finding out about the time stamp of  source
>> code changes of all methods in the Cuis image and then do a list with
>> the following four columns
>>
>>
>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
>> DateOfChange
>>
>> Help is appreciated.
>>
>> Hannes
>
> Check #timeStampFor:class:reverseOrdinal: and in general
> #annotationForSelector:ofClass:
>
> Cheers,
> Juan Vuletich
>



From Ken.Dickey at whidbey.com  Sun Jul 19 15:18:38 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sun, 19 Jul 2015 13:18:38 -0700
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55ABB223.8010309@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
Message-ID: <20150719131838.7d00ce57192818d00c38262c@whidbey.com>

On Sun, 19 Jul 2015 11:20:19 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> As a bottom line, let me repeat: This is too big for me to do it. 
> Please, folks, start documenting the APIs you most care about.

Let me repeat, "you don't have to do it".

I'd like to propose a simpler model based on the Smalltalk Way.

We take any stable revision, call it a version, give it a Baseline Version Number (could be just the development version number).  Each Baseline Release has a release document which describes major changes since the previous baseline.  This document is a light-weight description.

Each baseline release starts a new fork.  The only changes to the particular baseline release are bug fixes.

Nice users test their packages and likewise fork a Package Release which matches a Baseline Release.  This fork also only changes with bug fixes, and only in synch with its particular baseline.  Baseline packages Feature the baseline release.

So we forge ahead as usual, once in a while we say "enough has changed that we should re-baseline", do a new Baseline Release, test and release our Package Releases, then again move on forward.

Anyone can now pick any baseline release, require any associated packages, and ship/demo without fear.

Anyone with the time, energy, and interest can document baseline APIs to whatever level they feel comfortable.

Anyone can forge on ahead with the latest revision(s) with the usual "here be dragons, but also gold".

$0.02
-KenD



From hannes.hirzel at gmail.com  Sun Jul 19 15:21:09 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 20:21:09 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
Message-ID: <CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>

If I take a current image (18 Jul 2015, 4.2-2424)  I get the same result


a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy #at:ifAbsent:)

All the FileMan additions are not listed. Maybe because they keep
their original time stamp, not the time stamp of the addition to
Squeak.

And the recent change on #compilerClass does not show up.

--HH

On 7/19/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> If I use this to find out which methods have a time stamp date
> indicating a change after the 1st of January 2015 in a pristine Cuis
> 4.2-2243 (17 April 2015) image I find out that only the
>
> #postCopy method was changed (probably added) in nearly all classes.
>
> If I change the base line date to 1st of January 2014 I get
>
> a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
> #at:ifAbsent:)
> as changed/updated methods (i.e. methods which have a time stamp in
> this period).
>
> Of course this assumes that a method gets a time stamp when changed.
> Many methods have nil as a time stamp.
>
>
> Could somebody from the list check this please?
>
>
> |date coll baseLineDate dt  updatedMethods |
>
> baseLineDate := Date year: 2014 month: 1 day: 1.
> coll := OrderedCollection new.
>
> Smalltalk allClasses do: [ :cls |
> cls allSelectors do: [ :sel |
> dt := VersionsBrowser timeStampFor:  sel class: Dictionary reverseOrdinal:
> 1.
>
> dt notNil ifTrue: [
> date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
> ]) or: [ch = $:]] .
> (date = '') ifFalse:
> 	[date := Date fromString: date.
> 		(date > baseLineDate) ifTrue: [coll add: (Association key:
> (Association key: cls value: sel) value: date)
> ]]].
>
> ]].
>
> updatedMethods := Set new.
> coll do: [ :elem | updatedMethods add: (elem key value)].
> coll inspect.
> updatedMethods inspect
>
>
>
>
> On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
>> On 7/16/2015 11:49 AM, H. Hirzel wrote:
>>> Hello
>>>
>>> I'd like to do a query finding out about the time stamp of  source
>>> code changes of all methods in the Cuis image and then do a list with
>>> the following four columns
>>>
>>>
>>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
>>> DateOfChange
>>>
>>> Help is appreciated.
>>>
>>> Hannes
>>
>> Check #timeStampFor:class:reverseOrdinal: and in general
>> #annotationForSelector:ofClass:
>>
>> Cheers,
>> Juan Vuletich
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis compilerClass Screenshot from 2015-07-19 20:18:32.png
Type: image/png
Size: 33713 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150719/16f947f7/attachment-0002.png>

From hannes.hirzel at gmail.com  Sun Jul 19 15:50:18 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 20:50:18 +0000
Subject: [Cuis] API descriptions in form of an external package / Feature
	tests?
Message-ID: <CAGQxfViw4j2cvFUBf-0G_TE_e3cBi0=r8=d8YXacB4B4vv-zQw@mail.gmail.com>

Hello Peter

I think your proposal to check the presence of an API is very interesting.

You suggest to have API descriptions in form of classes in an external
package which test the presence of an API.

Contrariwise to unit tests they only look for the presence of a
classes with certain methods.

It is an external tool (i.e. not included in the core) to check the
presence or absence of an API.

These tools can focus on a certain part of the system which is of a
particular interest for an external package and be kept with that
package.

--Hannes


On 7/19/15, Peter van Rooijen <peter at aba-instituut.nl> wrote:
> Hey all,
>
> Just 2 cents from a Cuis noob:
>
...
>

A. Increase the number of improvements

> So, I am for adopting practices that increase the number of improvements.


B. Decrease the number of deterioations

> Practices that decrease the number of deteriorations seem helpful as well.
> See below if you wonder what my point is ;-).
>
...

> 3. Maybe what will help everybody is something that prevents functionality
> from being lost, especially *unintentionally*. This can include certain
> APIs as well. So what if an author who values a certain API, could invest
> some of his own time/money, to protect that API? What if he could write a
> software component (let's say a class) that was able to detect whenever an
> image did not provide the desired API? What if he could submit that class,
> and everybody who cared about not breaking that API, could use that class
> to see if perhaps they broke it?
>
> 4. I believe the idea could be generalized to include any feature of (the
> code in) an image for which presence or absence (as may be the case) can be
> determined by such a class. Bugs could be reified as classes, and the
> presence or absence of the bug could be determined by that class. Feature
> requests could be reified as classes, and whether or not the feature had
> actually been implemented could be determined by that class.
>
> 5. The things I am proposing would basically be Feature Tests, and would be
> rather different from Unit Tests (which apply to a unit and which you want
> to all be green when you share your software with users of it). Feature
> Tests would apply to a system (not a unit) and simply indicate which
> features are and which features are not present in the system. Every
> "release" could then come with a) the assertion that all the Unit Tests
> passed b) a list of the Feature Tests that passed and those that did not.
>
> 6. I think it would be pretty cool if people sent in feature requests in
> the form of Feature Tests, instead of messages to the mailing list (or the
> request tracker). So that anybody who (wished to impress somebody and) had
> some time on their hands, could then try to implement the functionality
> that made the Feature Test pass.



From hannes.hirzel at gmail.com  Sun Jul 19 15:53:27 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 20:53:27 +0000
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150719131838.7d00ce57192818d00c38262c@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
Message-ID: <CAGQxfVgj4-zOZazpQcB8hhy_cikBCMJqU0iTPNLZqNZMrC-23A@mail.gmail.com>

KenD

I like your proposal. And earlier you suggested to have one of these
base line versions per year.

--Hannes

On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Sun, 19 Jul 2015 11:20:19 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
>
>> As a bottom line, let me repeat: This is too big for me to do it.
>> Please, folks, start documenting the APIs you most care about.
>
> Let me repeat, "you don't have to do it".
>
> I'd like to propose a simpler model based on the Smalltalk Way.
>
> We take any stable revision, call it a version, give it a Baseline Version
> Number (could be just the development version number).  Each Baseline
> Release has a release document which describes major changes since the
> previous baseline.  This document is a light-weight description.
>
> Each baseline release starts a new fork.  The only changes to the particular
> baseline release are bug fixes.
>
> Nice users test their packages and likewise fork a Package Release which
> matches a Baseline Release.  This fork also only changes with bug fixes, and
> only in synch with its particular baseline.  Baseline packages Feature the
> baseline release.
>
> So we forge ahead as usual, once in a while we say "enough has changed that
> we should re-baseline", do a new Baseline Release, test and release our
> Package Releases, then again move on forward.
>
> Anyone can now pick any baseline release, require any associated packages,
> and ship/demo without fear.
>
> Anyone with the time, energy, and interest can document baseline APIs to
> whatever level they feel comfortable.
>
> Anyone can forge on ahead with the latest revision(s) with the usual "here
> be dragons, but also gold".
>
> $0.02
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Sun Jul 19 16:01:17 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 21:01:17 +0000
Subject: [Cuis] Scoping rules for shared variables ?
Message-ID: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>

On 7/19/15, Peter van Rooijen <peter at aba-instituut.nl> wrote:
....
 I
> recently changed the scoping rules for shared variables (I think they're
> done wrong in the base image). I could change what I wanted easily. So I
> think I am not in some outsider author group. Instead I am happy that I
> could change what I wanted without needing anyone's approval or
> cooperation.

A note:
This applies to any version / distribution of Smalltalk. But it means
that you have your own version of the core system.

Could you elaborate on the issue of the shared variables, maybe it is
something to include in the core Cuis image?

--Hannes



From pbpublist at gmail.com  Sun Jul 19 16:38:25 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 17:38:25 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55ABB223.8010309@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
Message-ID: <1437341905.6934.99.camel@gmail.com>

On Sun, 2015-07-19 at 11:20 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> (inline)
> 
> On 7/17/2015 3:45 PM, Phil (list) wrote:
> > ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
> >>> Thank you Juan, for answering.
> >>>
> >>> At the moment I feel uncomfortable using Cuis because it is currently
> >>> a quite fast moving target. I perceive quite a number of API changes
> >>> though this might be wrong. But I do not know because there are no
> >>> release notes which summarize it.
> > I totally feel Hannes' pain having gone through it a few times myself
> > over the years.  At the same time, I agree with Ken's point about not
> > getting too bogged down in process since we're in the best position
> > right now to break things for the better longer term.
> >
> >> Yes, that's true. Besides, we don't have a specification of what is an
> >> API and what is not. So, almost any change can be considered an API change.
> > That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
> > issue, not specific to Cuis)  I believe it is largely fixable without
> > tons of documentation and tests: the use of private (categories or
> > method naming convention).  Bernhard pointed out an existing capability
> > a few months ago
> > http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
> > While I personally like the idea of private categories, one of these
> > approaches should really be seriously considered.
> >
> > Other than a few specific examples (i.e. mostly the base data types
> > including the Collection and Number class hierarchies which are pretty
> > mature and don't change all that much anyway) I would guesstimate that
> > <20% (probably closer to 10%) of the methods, and and unknown % of
> > classes (a significantly larger fraction though), should even be
> > considered public.  If things were indicated as private that would
> > accomplish two things:
> >
> > 1) We could construct some simple tooling (some combination of up-front
> > warnings in the editor and/or a lint-type tester after the fact) that
> > would allow people to identify problematic calls within their code.
> > (i.e. just because it works now doesn't mean it always will if you keep
> > calling X, Y, Z...)
> >
> > 2) It would provide a way for people to know if something needs to be
> > discussed.  i.e. 'In class X method Y is private but I need that type of
> > functionality' so you would know that there's a need and could consider
> > either making it public, and therefore supported, or rethinking its
> > implementation if you'd like to offer a better public API solution.
> 
> Ok. Doing something along these lines would be great. But please note 
> that it is a rather large amount of work. It is not something I'm able 
> or willing to do it alone. If you (any of you all, not just Phil) wants 
> to start defining the API for any part of the system or optional 
> packages, please start doing it and send the changesets to the list. If 
> we get this working, I'll start the tools you mention.
> 

Agreed that this is a lot of work and I definitely wasn't expecting you
to do it (other than reviewing the work for approval/rejection.)  I'll
be happy to work on this with anyone else who is interested.

> <slowly diverging into OT rant>
> 
> On the other hand (and please forgive me if this kills a bit of 
> momentum), I don't really think we are changing APIs that much. And I 
> don't think we'll be doing it any more in the future than we do today, 
> at least in the base image. I hope to see most of the activity and 
> incompatible changes to happen in optional packages, and affecting 
> package dependencies... Mhhh, now that I write this I think that it 
> doesn't really go against the idea of defining APIs. Maybe APIs in the 
> base image will almost never change or be a problem, but packages should 
> provide APIs too... Optional packages will (I hope!) always be 
> improving, and new ones will appear all the time.
> 

You'd likely be very surprised.  I'd say there's usually at least a
couple changes a month that breaks something, somewhere in my code.  A
few recent examples that have been discussed on the list: removing clone
broke OpenGL a bit (easy fix thanks to the on-list discussion), removing
compilerClass killed OMeta, a while back you were considering removing
storeString which would again break OMeta. etc. (that's just a few
things off the top of my head from the last few months and note that all
were probably considered minor, inconsequential changes)  However the
issue snowballs quickly if one misses a few updates and some of the
breakage is related to changes that weren't discussed on the list or
otherwise documented.  I've been managing through this recently (the
last 6 months or so) by upgrading my image very quickly after you commit
changes but I doubt most people would be able / willing to have that
level of diligence.

A lot of this breakage is no one's 'fault', it's just how a lot of
Smalltalk code has been historically written.  Two examples of how this
happens:

1) For ports of existing code, you're subject to the whims of the
original author who often used techniques described in the next item to
write their code.  And of course, code coming from Squeak/Pharo means
that there were often 10 or more possible ways they could have
implemented parts of their solution.  So after porting a few different
packages, you have several different approaches to the same kinds of
problems.

2) For one's own code because there is currently no distinction between
public and private, you tend to go either with what you already know or
whatever the first thing you find poking around the image that appears
to make sense and work.  Even in Cuis, there are still usually multiple
ways to do most things, so you end up arbitrarily picking one or two
that you like.  As a result, you quickly end up with a potpourri of
calls that may or may not be the best way to do things.  Over time, you
start building new code on top of this code and quickly end up with a
house of cards that comes crashing down as the result of a subsequent
image update.  Again, this often results in each of us as authors
deciding on superficially different solutions to the same problems.

I'm not expecting you to not do things that might break my, or anyone
else's code, going forward.  Like Hannes, I'm just looking for ways to
help manage through the changes and breakage.  One of the key aspects of
this is to have an opinion and to say 'hey, here are the one or two ways
we should be doing this'.  There may be disagreement and discussion as
to what those one or two ways are, but at the end of the day we need to
settle these issues so that both your and our lives are manageable.
That's really the main thing that a public API is, IMO.  There may be
all sorts of internal helper methods and implementation details needed
to make it all work, but like the cells of a living organism, these
details should be hidden and their use discouraged.  Hey, didn't someone
say something along those lines once? :-)
 
> If all this work, the Cuis will be a lot less about my personal effort 
> and coding style, and the packages maintained by each one of us will 
> become the main characters in this story. And this will be a very good 
> thing. The base image should be about providing a good base for doing 
> the really interesting stuff on top...
> 

I both agree (that the packages become more important) and disagree
(that Cuis fades into the background).  I still view the core Cuis image
as the philosophical and stylistic backbone that all of my stuff is
based on.  It's a constant reminder to clean up and get rid of as much
cruft as possible in my code (especially for the packages that have yet
other packages dependent on them)  I freely admit that I am mostly
falling short in my execution on this front, but it would be easy to
lose sight of entirely if Cuis didn't stay the course.

> Let me tell you a bit about how Cuis got started. Many years ago I did 
> my thesis on audio/music processing. The I wanted to turn that into a 
> novel and fun application for musicians (both pros and anyone willing to 
> play with sound). I started to think about how a good GUI for that could 
> be, giving the feeling of modifying sound by direct manipulation of it, 
> as if it was clay, as if it was visual and not just auditory. Well, that 
> was the start of my questioning of the whole GUI business and Morphic 3. 
> And it became clear to me that Squeak had turned into something that was 
> not the best possible environment to do all this. The idea of "fixing" 
> Squeak, and thus make Cuis, was born. So, Cuis was not and end in 
> itself, but a means for allowing experimentation, freedom to build 
> applications in new styles, etc.
> 
> (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other 
> came later, as an observation on facts.)
> 
> So, when the moment comes when Cuis stabilizes a bit, and interest moves 
> to packages and applications built by all us, Cuis will start to fulfill 
> its original objective.
> 

It's already this is as far as I'm concerned.  I can't tell you much
time I burned just trying to extract OpenGL from Croquet so that I could
load it into Squeak, for example.  It was painful on both sides, and by
the time I was done I had to think for a bit to remind myself what my
original objective was... I have *never* had this issue with Cuis.

It is absolutely enabling me to play around with ideas and build things
that I couldn't have / wouldn't have bothered in Squeak.  The only issue
I'm having is that once I've built it, I want to keep it running :-)

> </slowly diverging into OT rant>

Not at all a rant as it reaffirms *why* you're doing what you're doing.
If you lost sight of that, that's when I'd start worrying about Cuis.

> 
> >> ...
> >> The problem, I think, is not identifying well defined Cuis releases. The
> >> problem is knowing how updates could affect your code
> > By narrowing the scope of what the public API is using private
> > designators, this dramatically reduces what you need to be concerned
> > with on this front.  It's part of the reason that Apple, Google, and
> > even Microsoft are so adamant about public APIs these days.  They dealt
> > with the pain of even major developers depending on private APIs for
> > decades. It's only been in the last 10 years or so that they've been
> > able to dig themselves out from under this issue.
> >
> > This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
> > attitude of 'you have the source, play around, have fun!' has morphed
> > into 'everything is a public API!  there are no rules! isn't this
> > great?'  Well no, it's not great.  It makes life impossible for image
> > maintainers (Squeak has been in a coma for the last decade or so as the
> > result of trying to keep everyone happy... yet no one seems to be) and
> > miserable for those who are trying to keep code running on it (stuff
> > still breaks all the time.)
> 
> Yes.
> 
> > I personally believe the minimalism and simplicity that Cuis is based on
> > has the best long term prospects but we have to get out of this
> > 'everything is public' mindset.  Sure, we have all the source: look at
> > it, learn from it, poke around, refactor it, submit fixes, etc.  But
> > there needs to be a manageable subset of it which is considered the
> > 'public API' that people can depend on to write frameworks and apps on
> > top of that is relatively stable longer term.  Let's start defining what
> > that is and backfill changes to the public API (which will happen from
> > time to time as we don't want things to be completely static) with tests
> > and documentation so you can focus your efforts on where they matter
> > most and you get the most enjoyment from.
> 
> I fully agree and support this.
> Maybe an alternative to yet-another-convention-on-categories could be to 
> mark public methods with a pragma, or make them send 'self publicAPI' or 
> such... This could be better for the tools, also.
> 

I like your idea better re: rather than having to go through and mark
the majority as private, just mark the minority as public.  I'm open to
either of your proposed approaches.  I just tossed out the two (method
categories and naming) I was aware of but agree that they would not do
much to ease developing tools to support/enforce.  Of the two ideas, am
I correct in believing that pragma would have the lowest runtime
overhead?  Are there any downsides you can think of to using pragma?

Speaking of enforcing, I am not proposing that we make this a
straight-jacket for anyone: it should be easy to opt-out the way things
like underscore assignment are (except for pp which I'm still trying to
get to an easily repro example with... :-) so that anyone who doesn't
care about this isn't forced into it.  On the other hand, for people who
do care, they should be able to leave it 'enabled', whatever that ends
up meaning, and get help from the tooling to help them minimize
potential future breakage.  The downside to opting out would be that
you, as the author opting out, have decided to take it entirely on
yourself to keep your code running across builds/releases.

> > ...
> >> I don't have that either. I run the tests from time to time (I'll start
> >> doing it before any commit, and add the xml report to the rep). But this
> >> is not the most important reason why Cuis is solid. Cuis is very
> >> reliable because:
> > reliable != stable
> 
> ;)
> 
> >> - I'm not too bad as a coder.
> >> - I do my own code revisions at least one day after each change.
> >> - I use Cuis every day, and spot most problems in the updates, before
> >> commtting them to the repo.
> >> - I really, really care about code quality.
> >> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
> >> is a big responsibility, given how important I think Smalltalk-80 is.
> >>
> > Agree to all this and more.  Cuis would not be where it is without your
> > continued effort and diligence. (i.e. setting aside that you obviously
> > created it, if you had just tossed it out into the world and let it go
> > at best it would have started looking something like Squeak or Pharo by
> > now.  It's a lot of effort over the long term to *keep* it small and
> > focused.  THANK YOU JUAN!)
> 
> Thanks for your nice words, Phil. I really appreciate that you all 
> accept this rather restrictive dev model for the base image, in contrast 
> with a more open trunk style. Hopefully, as the base image becomes 
> stable and almost irrelevant, this will be each time less of a problem.
> 
> >> So, I suggest running your tests when updating your image, or migrating
> >> your code to an updated image.
> > +1 to tests as they do help quite a bit and are a very good practice.
> > Just be judicious in what/where you test (I personally don't subscribe
> > to the TDD approach where you spend your days mostly writing tests.
> > That's just admitting defeat in that you spend all day writing
> > executable documentation.)
> 
> <OT>
> 
> I don't subscribe to "extreme" TDD either. To me design is a creative 
> activity, both technical and artistic. It should be "driven" by 
> creativity and intelligence, not by a process. Any xDD process is 
> admitting defeat on design itself!
> 

Heh... I like the way you put that.

> </OT>
> 
> >> In any case, I think this doesn't answer your concerns. What you need is
> >> some way to know which updates could affect you, to review them in
> >> detail, and understanding their effect on your code. A list of the
> >> affected classes and/or methods for each update makes no sense. Cuis can
> >> already show you that very easily. Perhaps each update should include:
> >>
> >> 1) parts of the system that are affected:
> >> - Kernel
> >> - Compiler
> >> - Tools
> >> - Morphic
> >> - etc
> >>
> >> 2) Level of risk involved
> >> - very unlikely to break code that depends on this part of the system
> >> - could perhaps break code that depends on this part of the system
> >> - will most likely break code that depends on this part of the system
> >>
> >> Or something like that.
> >>
> >> BTW, this is a very relevant topic for discussing on the mail list. Feel
> >> free to answer there if you agree.
> > One final thought on this:  I suspect a major cause of people abandoning
> > Cuis (and Smalltalk in general), behind the 'it's too different from
> > what I'm used to'/'not mainstream' reaction, is the instability of its
> > APIs.
> 
> Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) 
> is a PITA too...

True, neither extreme (changing nothing vs. changing everything) works
very well. <cough>Perl 6</cough> :-)
 
> 
> As a bottom line, let me repeat: This is too big for me to do it. 
> Please, folks, start documenting the APIs you most care about.
> 

Ready to go... we just need to agree on how to do it (pragma/method
call/method category/method name?)  Also, this is most definitely
related to the 'Canonical test cases?' thread from a few months ago as
these types of test cases / docs are part of the backfill I was
referring to.

As I've been writing this it occurs to me that there's probably a pretty
easy way to go about getting started on this: IIRC, there are ~1,500
distinct method names in the core image.  If I do a count of how many
times my code is calling any of those methods, that should pop out what,
for my code, is the low hanging fruit.  The long-tail of say 1-5 calls
for the lesser used methods are the tedious work that will take more
effort for me to sort through.  We could use my 'short list' to at least
provide a starting point and using these most frequently called methods
you could scan through the list and could say 'hey, why are you calling
X instead of Y?' or maybe you'd get some visibility in the sense of
'wow, I didn't think that was being used'.  Hmm... I've got some
analysis to do...

> Cheers,
> Juan Vuletich





From hannes.hirzel at gmail.com  Sun Jul 19 18:01:22 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 23:01:22 +0000
Subject: [Cuis] Baseline version?
Message-ID: <CAGQxfVg7XkxDx0GXRzbM-g-efzvVKeafy3H5DzNJdjkzTwxDUg@mail.gmail.com>

On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Sun, 19 Jul 2015 11:20:19 -0300
....
> I'd like to propose a simpler model based on the Smalltalk Way.
>
> We take any stable revision, call it a version, give it a Baseline Version
> Number (could be just the development version number).

I'd like to suggest to label just the current version as a "baseline".

It would not need a long description, just a few keywords regarding
major changes like the addition of the FileMan package with a
reference to the description of it.

The last one
http://www.jvuletich.org/Cuis/CuisReleaseNotes.html

had

New in Cuis 4.2 (released July 25, 2013)

    Packages now have dependencies

    Package loading greatly enhanced

    Moved non-essential stuff to optional packages. Cuis is now below
500 classes and 100kLOC. Reduction was about 25%

    Many bugfixes, and minor enhancements and cleanup


So this one would have

New in Cuis 4.3 (released July 25, 2015)

     Many bugfixes, and minor enhancements and cleanup

     Addition of FileMan

    .....................

    .......................


    .....................

    .......................



And then after testing various packages on it
another baseline at the end of the year with a release document.

New in Cuis 4.4 (released December 31, 2015)

     Many bugfixes, and minor enhancements and cleanup

    .....................

    .....................

    .......................


    .....................

    .......................

    .....................

    .......................


More text as we will be more aware of the changes.



> Each Baseline
> Release has a release document which describes major changes since the
> previous baseline.  This document is a light-weight description.
>
> Each baseline release starts a new fork.  The only changes to the particular
> baseline release are bug fixes.
>
> Nice users test their packages and likewise fork a Package Release which
> matches a Baseline Release.  This fork also only changes with bug fixes, and
> only in synch with its particular baseline.  Baseline packages Feature the
> baseline release.
>
> So we forge ahead as usual, once in a while we say "enough has changed that
> we should re-baseline", do a new Baseline Release, test and release our
> Package Releases, then again move on forward.
>
> Anyone can now pick any baseline release, require any associated packages,
> and ship/demo without fear.
>
> Anyone with the time, energy, and interest can document baseline APIs to
> whatever level they feel comfortable.
>
> Anyone can forge on ahead with the latest revision(s) with the usual "here
> be dragons, but also gold".
>
> $0.02
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Sun Jul 19 18:52:33 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 23:52:33 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1424720606.2231.10.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
Message-ID: <CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>

On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> On Mon, 23 Feb 2015 08:38:44 +0000
>> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>
>> > As Casey writes "The hard part is time and energy to do so."
>> >
>> > So what can be done with minimal effort and big impact?
>>
>> Looking around, I see that I could make some simple naming changes for
>> test cases.
>>
>> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>>   testExampleHighlevel -> testNaclHiglLevelAPI
>>   textExampleLowLevel -> testNaclLowLevelAPI
>>
>> We could use other words, but API is shorter than Usage, Example,
>> Interface.
>>
>> Having specific test names end in 'API' would clue me in.
>>
>> Adding 'Nacl' means I can use the existing message finder to search for
>> 'api' and note testNacl*API methods.  This lets me find API tests specific
>> to Nacl.
>>
>> And we can do this as I get the chance.
>>
>> Other suggestions?
>
> I started playing around with a couple of example test cases to see what
> I ran into and came up with a distinct class to store all of these per
> test category (i.e. under Test-Files a class ApiFile which could have a
> method testWriteTextFile)  The rationale was that it might make sense to
> keep these test cases separate from traditional test cases which are
> free to make calls that users of the class (i.e. who are calling the
> supported API) should not.

Phil,

where do you keep this class ApiFile?

regards

Hannes


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



From hannes.hirzel at gmail.com  Sun Jul 19 18:57:25 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 23:57:25 +0000
Subject: [Cuis] Where are SUnit tests and how do I get them?
Message-ID: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>

Hello

In the current image when I open the SUnit browser no tests appear.


I assume the SUnit tests now in

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st

?

Are all tests there?

An snippet how to load them in the 'Useful Expression Workspace' would be fine.

Regards
Hannes



From pbpublist at gmail.com  Sun Jul 19 19:39:31 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 20:39:31 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150719131838.7d00ce57192818d00c38262c@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
Message-ID: <1437352771.6934.219.camel@gmail.com>

On Sun, 2015-07-19 at 13:18 -0700, Ken.Dickey wrote:
> On Sun, 19 Jul 2015 11:20:19 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
> 
> > As a bottom line, let me repeat: This is too big for me to do it. 
> > Please, folks, start documenting the APIs you most care about.
> 
> Let me repeat, "you don't have to do it".
> 

I would agree that *Juan* doesn't need to do much of anything at this
stage, but not that it doesn't need to be done.  If and when it does get
done, if he disregards it, it will have been a futile exercise.  So I'd
appreciate it if we could come to an agreement as to whether or not I
should bother...

> I'd like to propose a simpler model based on the Smalltalk Way.
> 
> We take any stable revision, call it a version, give it a Baseline Version Number (could be just the development version number).  Each Baseline Release has a release document which describes major changes since the previous baseline.  This document is a light-weight description.
> 

While I agree that there should be periodic major releases, there are a
lot of things in motion between major releases that will either be
forgotten about or not considered major enough to call out in the major
version release notes.

The issue is what constitutes a major change?  If your code uses it it's
major, if mine uses it it's minor?  Coin toss?  Without a public API
what is considered major is either obvious (i.e. Morphic changes from
global to local coords or changing the File/Directory API so obviously
everything using them breaks) or arbitrary (sorry to hear that you
depended on that... but it wasn't major, now it's gone)  If the image
snapshot is considered the public API, then everything must be both
considered fair game to depend on and to change in the future which is
unmanageable.

Let's look at a few examples along the spectrum of what I'm talking
about:

1)  Things that hopefully we can all agree on as being obvious and
relatively stable.  We have a class called Morph.  Is it reasonable to
assume that that is going to be supported going forward?  How about the
#drawOn: method, is that going to be around for a while?  If Juan were
to randomly decide to change these, I'd expect there would be screaming
from anyone who has a significant amount of drawing code.

2) Multiple ways to do the same thing.  Morphs support stepping to do
animated drawing etc.  There are at least two different ways (one
seemingly obvious, one less so... both different from how things used to
work) currently to do stepping.  Should this be the case, or should we
just have one way we agree that everyone uses?  What is lost by giving
up the 2nd (and 3rd...) way(s)?  Currently, if Juan were to change *any*
of the approaches, it would probably break someones code.  Why not just
have one supported way for him to be concerned with?  (if you think this
doesn't happen, one of my pull requests in the last month was related to
this)

3) Questionable usage / edge cases.  Morph also has
#resumeAfterDrawError and #resumeAfterStepError.  Now taking a few
seconds to look at them (never used myself) they seem like Morphic
implementation details, but hey they're in the image and not even marked
private so I should feel free to make my code depend on them, right?
Conversely, Juan could look at them and decide 'no one would possibly
need these' and change/remove them at any time.

It seems to me that at least 1/2 of 2 and most use cases of 3 are
unnecessary issues waiting to, and eventually will, happen.  I
personally try to stick to depending on things that are in category 1 or
the obvious use case of 2.  But imagine my surprise when I discover as
the result of an update that something I was using was actually in
category 2 (less obvious, to me at least) or 3.  Sure, there's a lot of
gray area that isn't so clear cut, but shouldn't we at least try to
minimize the amount of breakage going forward when it can easily be
avoided or manage it via documentation/communication when it can't?

I'm not trying to restrict Juan in any way from making the changes he
thinks are important for Cuis.  His taste and direction have been
generally excellent and the reason I'm here!  If for example, he decides
that #drawOn: is no longer the way to do things or that even Morph
needed to go away, that's fine as long as what's going on gets
communicated.  However, a problem I think he faces right now is that he
doesn't know who's using / depending on what.

> Each baseline release starts a new fork.  The only changes to the particular baseline release are bug fixes.
> 
> Nice users test their packages and likewise fork a Package Release which matches a Baseline Release.  This fork also only changes with bug fixes, and only in synch with its particular baseline.  Baseline packages Feature the baseline release.
> 
> So we forge ahead as usual, once in a while we say "enough has changed that we should re-baseline", do a new Baseline Release, test and release our Package Releases, then again move on forward.
> 
> Anyone can now pick any baseline release, require any associated packages, and ship/demo without fear.
> 

What you are describing is an application development model, not a
platform development model.  It handles dependencies by ignoring them.
It really comes down to what is Cuis?  Is it:

1) a minimal Smalltalk that you play around with ideas / prototype
something in the short to intermediate term

2) a platform that you can take that idea you were playing around with,
and if it proves out, build something more substantial from for the
longer term

3) a completely experimental environment.  Anything can change at any
time.  Supporting 1 is doable but 2 is doubtful.

Right now, Cuis is great at 1 but seems like it should be able to handle
both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
all, but who knows, others may disagree.  If others look at it
differently, I'd love to know how you look at Cuis.

> Anyone with the time, energy, and interest can document baseline APIs to whatever level they feel comfortable.
> 
> Anyone can forge on ahead with the latest revision(s) with the usual "here be dragons, but also gold".
> 
> $0.02
> -KenD
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From pbpublist at gmail.com  Sun Jul 19 19:43:29 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 20:43:29 -0400
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
Message-ID: <1437353009.6934.223.camel@gmail.com>

Hi Hannes,

On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
> >> On Mon, 23 Feb 2015 08:38:44 +0000
> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
> >>
> >> > As Casey writes "The hard part is time and energy to do so."
> >> >
> >> > So what can be done with minimal effort and big impact?
> >>
> >> Looking around, I see that I could make some simple naming changes for
> >> test cases.
> >>
> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
> >>   testExampleHighlevel -> testNaclHiglLevelAPI
> >>   textExampleLowLevel -> testNaclLowLevelAPI
> >>
> >> We could use other words, but API is shorter than Usage, Example,
> >> Interface.
> >>
> >> Having specific test names end in 'API' would clue me in.
> >>
> >> Adding 'Nacl' means I can use the existing message finder to search for
> >> 'api' and note testNacl*API methods.  This lets me find API tests specific
> >> to Nacl.
> >>
> >> And we can do this as I get the chance.
> >>
> >> Other suggestions?
> >
> > I started playing around with a couple of example test cases to see what
> > I ran into and came up with a distinct class to store all of these per
> > test category (i.e. under Test-Files a class ApiFile which could have a
> > method testWriteTextFile)  The rationale was that it might make sense to
> > keep these test cases separate from traditional test cases which are
> > free to make calls that users of the class (i.e. who are calling the
> > supported API) should not.
> 
> Phil,
> 
> where do you keep this class ApiFile?
> 

It's in Packages/Tests.pck.st package. After loading it will be listed
in the Tests-Files category.

> regards
> 
> Hannes
> 

Thanks,
Phil




From pbpublist at gmail.com  Sun Jul 19 19:50:10 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 20:50:10 -0400
Subject: [Cuis] Where are SUnit tests and how do I get them?
In-Reply-To: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>
References: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>
Message-ID: <1437353410.6934.229.camel@gmail.com>

Hannes,

On Sun, 2015-07-19 at 23:57 +0000, H. Hirzel wrote:
> Hello
> 
> In the current image when I open the SUnit browser no tests appear.
> 
> 
> I assume the SUnit tests now in
> 
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st
> 
> ?
> 
> Are all tests there?
> 
> An snippet how to load them in the 'Useful Expression Workspace' would be fine.
> 

The main Cuis tests are in the Packages/Tests.pck.st file I mentioned in
my previous reply.  Additionally, many of the 3rd party packages also
have optional tests (usually <PackageName>Tests.pck.st or something
similar) which can be loaded.  They don't get loaded by default so you
need to open a file browser, navigate to them, and install the
package(s).

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





From pbpublist at gmail.com  Sun Jul 19 20:01:38 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 21:01:38 -0400
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
	<CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>
Message-ID: <1437354098.6934.240.camel@gmail.com>

On Sun, 2015-07-19 at 20:21 +0000, H. Hirzel wrote:
> If I take a current image (18 Jul 2015, 4.2-2424)  I get the same result
> 
> 
> a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy #at:ifAbsent:)
> 
> All the FileMan additions are not listed. Maybe because they keep
> their original time stamp, not the time stamp of the addition to
> Squeak.
> 

Right, the timestamp will reflect when they were last edited rather than
when they were loaded into the image.

> And the recent change on #compilerClass does not show up.
> 

Same situation: #compilerClass while only recently re-added to the
image, hasn't actually been changed since it was removed and added back
so it still shows an older timestamp.

It sounds like you're looking for more of an image diff to see what
classes/methods changed between timer period X and Y?  This isn't
something that currently exists in an easy to use form that I'm aware
of.
 
> --HH
> 
> On 7/19/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > If I use this to find out which methods have a time stamp date
> > indicating a change after the 1st of January 2015 in a pristine Cuis
> > 4.2-2243 (17 April 2015) image I find out that only the
> >
> > #postCopy method was changed (probably added) in nearly all classes.
> >
> > If I change the base line date to 1st of January 2014 I get
> >
> > a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
> > #at:ifAbsent:)
> > as changed/updated methods (i.e. methods which have a time stamp in
> > this period).
> >
> > Of course this assumes that a method gets a time stamp when changed.
> > Many methods have nil as a time stamp.
> >
> >
> > Could somebody from the list check this please?
> >
> >
> > |date coll baseLineDate dt  updatedMethods |
> >
> > baseLineDate := Date year: 2014 month: 1 day: 1.
> > coll := OrderedCollection new.
> >
> > Smalltalk allClasses do: [ :cls |
> > cls allSelectors do: [ :sel |
> > dt := VersionsBrowser timeStampFor:  sel class: Dictionary reverseOrdinal:
> > 1.
> >
> > dt notNil ifTrue: [
> > date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
> > ]) or: [ch = $:]] .
> > (date = '') ifFalse:
> > 	[date := Date fromString: date.
> > 		(date > baseLineDate) ifTrue: [coll add: (Association key:
> > (Association key: cls value: sel) value: date)
> > ]]].
> >
> > ]].
> >
> > updatedMethods := Set new.
> > coll do: [ :elem | updatedMethods add: (elem key value)].
> > coll inspect.
> > updatedMethods inspect
> >
> >
> >
> >
> > On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> >> On 7/16/2015 11:49 AM, H. Hirzel wrote:
> >>> Hello
> >>>
> >>> I'd like to do a query finding out about the time stamp of  source
> >>> code changes of all methods in the Cuis image and then do a list with
> >>> the following four columns
> >>>
> >>>
> >>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
> >>> DateOfChange
> >>>
> >>> Help is appreciated.
> >>>
> >>> Hannes
> >>
> >> Check #timeStampFor:class:reverseOrdinal: and in general
> >> #annotationForSelector:ofClass:
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
> >
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Sun Jul 19 20:13:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 19 Jul 2015 21:13:35 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55ABA6A2.5090607@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>,
	<55ABA6A2.5090607@jvuletich.org>
Message-ID: <55AC4B3F.19938.1F92268@dnorton.mindspring.com>

On 19 Jul 2015 at 10:31, Juan Vuletich wrote:

> On 7/18/2015 3:37 PM, Dan Norton wrote:
> > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
> >
> >> Hi Folks,
> >>
> >> It is not too hard to build new StrikeFonts. You need to build,
> by
> >> hand,
> >> files like the ones in here:
> >>
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> >> p
> >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
> with
> >> this method and the files in this zip that built the existing
> >> instances
> >> of StrikeFont. Not sure.
> >>
> > That's intrigueing but I can't reproduce it. Maybe the .bmp but
> where did you get the .txt?
> >
> >   - Dan
> 
> I wrote them with a text editor. Check #installDejaVu2 and really
> try to 
> understand how StrikeFonts work and how they are built with this
> method. 
> Maybe you'll become enlightened.
> 

A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name, and several scalars. 
StrikeFont class methods create fonts by processing file pairs assumed to be in the 
"AAFonts" subdirectory. For example:

DejaVu Sans Oblique 14.bmp
DejaVu Sans Oblique 14.txt

Is one such pair providing the italic (oblique) style for 14-point size. There is a pair for every 
font size and style: base, bold, italic, and bold italic. Therefore a font such as "DejaVu Sans" 
which is available in the size interval 5 to 24 requires 160 files. The file names are stylized 
and encoded in the StrikeFont class methods.

Glyphs come from the .bmp file. The .txt file is a string of numbers; the first three specify 
pointSize, ascent, and	descent. The rest of the numbers in the .txt file are used to form the 
xTable, which is the index into the glyphs for a character. The characterToGlyphMap is an 
array of 256 entries which map a character's ascii value to the xTable and thence to the 
glyphs.

The bold, italic, and bold italic styles are stashed as derivatives of the base and not 
selectable from the current menus.

StrikeFont is a subclass of AbstractFont, which has class variables AvailableFonts and 
DefaultFont.

If it can't find a file, StrikeFont will loop.

In regard to creating the .bmp and .txt files, you say, "I wrote them with a text editor." Please 
tell me which text editor you used. None of mine do that.

 - Dan

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

From pbpublist at gmail.com  Sun Jul 19 20:21:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 21:21:01 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBY7YtLCJwVSOM3w58shed-YcnON=BL2WD2xM6EAMVbn2A@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<CAJBxtBY7YtLCJwVSOM3w58shed-YcnON=BL2WD2xM6EAMVbn2A@mail.gmail.com>
Message-ID: <1437355261.6934.252.camel@gmail.com>

On Sun, 2015-07-19 at 18:02 +0200, Peter van Rooijen wrote:
> Hey all,
> 
> 
> Just 2 cents from a Cuis noob:
> 
> 
> 1. Releases... since this stuff is not being sold for money and not
> being distributed using off-line media, what use does a "release"
> have? I like that stuff gets improved as often as possible. I believe
> that the things that get improved the most often, have the best chance
> of becoming something really good.
> 

It's more a function of managing the dependent code bases than anything
else.  One's view of 'improved as often as possible' changes when said
improvements break things you are depending on without warning.

> 
> So, I am for adopting practices that increase the number of
> improvements. Practices that decrease the number of deteriorations
> seem helpful as well. See below if you wonder what my point is ;-).
> 
> 
> 2. Public vs private API. Stable APIs are nice, if you can get them.
> If you have authors who develop a base, and other authors who (have
> to) develop ON that base, you need stable APIs, or you will lose the
> authors dependent on your base.
> 

Yup.  See Hannes' original comments that started this thread.  I chimed
in because I've been bitten by this several times.  And I'm sure there
are others who don't participate in the lists.  At the same time, I
recognize that there are others like Ken who don't have an issue.  It's
just a discussion that needed to be had and a decision reached whether
or not something needs to be done, and if so what.

> 
> So, do we really have those different author groups? Somehow I doubt
> it. I recently changed the scoping rules for shared variables (I think
> they're done wrong in the base image). I could change what I wanted
> easily. So I think I am not in some outsider author group. Instead I
> am happy that I could change what I wanted without needing anyone's
> approval or cooperation.
> 

We absolutely do.  I fall into several categories: I occasionally submit
changes to 'core' Cuis, work on several add-on frameworks (OMeta and
OpenGL are currently my main focuses on that front), and have a
large-ish base of my own code that I'm developing and maintaining.

The issue isn't one of permission as much as it is of communicating to
those downstream what is considered stable/supported.  Feel free to
change anything you want, just don't be surprised if the next release
breaks your changes.  But what do you do when you're trying to write
something that either won't break in the next release or at least have
some indication before hand what you might run into...

> 
> Suppose we were making money from outside author groups who want us to
> keep certain APIs stable. For the right price, I would be happy to
> provide that for them. In the mean time, I can live with free. Free to
> change what I want, free to use without paying, and others free to
> change what I am building on (sometimes frustrating).
> 

That definitely makes sense when you're talking about things like LTS
(Long Term Support) versions etc.  Free and stable are not mutually
exclusive.

> 
> 3. Maybe what will help everybody is something that prevents
> functionality from being lost, especially *unintentionally*. This can
> include certain APIs as well. So what if an author who values a
> certain API, could invest some of his own time/money, to protect that
> API? What if he could write a software component (let's say a class)
> that was able to detect whenever an image did not provide the desired
> API? What if he could submit that class, and everybody who cared about
> not breaking that API, could use that class to see if perhaps they
> broke it?
> 
> 
> 4. I believe the idea could be generalized to include any feature of
> (the code in) an image for which presence or absence (as may be the
> case) can be determined by such a class. Bugs could be reified as
> classes, and the presence or absence of the bug could be determined by
> that class. Feature requests could be reified as classes, and whether
> or not the feature had actually been implemented could be determined
> by that class.
> 
> 
> 5. The things I am proposing would basically be Feature Tests, and
> would be rather different from Unit Tests (which apply to a unit and
> which you want to all be green when you share your software with users
> of it). Feature Tests would apply to a system (not a unit) and simply
> indicate which features are and which features are not present in the
> system. Every "release" could then come with a) the assertion that all
> the Unit Tests passed b) a list of the Feature Tests that passed and
> those that did not.
> 

I believe what you are proposing is similar to what I proposed a few
months ago in the 'Canonical test cases?' thread.
http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-February/001747.html

> 
> 6. I think it would be pretty cool if people sent in feature requests
> in the form of Feature Tests, instead of messages to the mailing list
> (or the request tracker). So that anybody who (wished to impress
> somebody and) had some time on their hands, could then try to
> implement the functionality that made the Feature Test pass.
> 
> 
> Hope this helps somebody with something :)
> 
> 
> Cheers, Peter
> 
> On Sun, Jul 19, 2015 at 4:20 PM, Juan Vuletich <juan at jvuletich.org>
> wrote:
>         Hi Folks,
>         
>         (inline)
>         
>         On 7/17/2015 3:45 PM, Phil (list) wrote:
>                 ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>                                 Thank you Juan, for answering.
>                                 
>                                 At the moment I feel uncomfortable
>                                 using Cuis because it is currently
>                                 a quite fast moving target. I perceive
>                                 quite a number of API changes
>                                 though this might be wrong. But I do
>                                 not know because there are no
>                                 release notes which summarize it.
>                 I totally feel Hannes' pain having gone through it a
>                 few times myself
>                 over the years.  At the same time, I agree with Ken's
>                 point about not
>                 getting too bogged down in process since we're in the
>                 best position
>                 right now to break things for the better longer term.
>                 
>                         Yes, that's true. Besides, we don't have a
>                         specification of what is an
>                         API and what is not. So, almost any change can
>                         be considered an API change.
>                 That's the problem!  Both for you and us (it's a
>                 general 'Smalltalk Way'
>                 issue, not specific to Cuis)  I believe it is largely
>                 fixable without
>                 tons of documentation and tests: the use of private
>                 (categories or
>                 method naming convention).  Bernhard pointed out an
>                 existing capability
>                 a few months ago
>                 http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
>                 While I personally like the idea of private
>                 categories, one of these
>                 approaches should really be seriously considered.
>                 
>                 Other than a few specific examples (i.e. mostly the
>                 base data types
>                 including the Collection and Number class hierarchies
>                 which are pretty
>                 mature and don't change all that much anyway) I would
>                 guesstimate that
>                 <20% (probably closer to 10%) of the methods, and and
>                 unknown % of
>                 classes (a significantly larger fraction though),
>                 should even be
>                 considered public.  If things were indicated as
>                 private that would
>                 accomplish two things:
>                 
>                 1) We could construct some simple tooling (some
>                 combination of up-front
>                 warnings in the editor and/or a lint-type tester after
>                 the fact) that
>                 would allow people to identify problematic calls
>                 within their code.
>                 (i.e. just because it works now doesn't mean it always
>                 will if you keep
>                 calling X, Y, Z...)
>                 
>                 2) It would provide a way for people to know if
>                 something needs to be
>                 discussed.  i.e. 'In class X method Y is private but I
>                 need that type of
>                 functionality' so you would know that there's a need
>                 and could consider
>                 either making it public, and therefore supported, or
>                 rethinking its
>                 implementation if you'd like to offer a better public
>                 API solution.
>         
>         Ok. Doing something along these lines would be great. But
>         please note that it is a rather large amount of work. It is
>         not something I'm able or willing to do it alone. If you (any
>         of you all, not just Phil) wants to start defining the API for
>         any part of the system or optional packages, please start
>         doing it and send the changesets to the list. If we get this
>         working, I'll start the tools you mention.
>         
>         <slowly diverging into OT rant>
>         
>         On the other hand (and please forgive me if this kills a bit
>         of momentum), I don't really think we are changing APIs that
>         much. And I don't think we'll be doing it any more in the
>         future than we do today, at least in the base image. I hope to
>         see most of the activity and incompatible changes to happen in
>         optional packages, and affecting package dependencies... Mhhh,
>         now that I write this I think that it doesn't really go
>         against the idea of defining APIs. Maybe APIs in the base
>         image will almost never change or be a problem, but packages
>         should provide APIs too... Optional packages will (I hope!)
>         always be improving, and new ones will appear all the time.
>         
>         If all this work, the Cuis will be a lot less about my
>         personal effort and coding style, and the packages maintained
>         by each one of us will become the main characters in this
>         story. And this will be a very good thing. The base image
>         should be about providing a good base for doing the really
>         interesting stuff on top...
>         
>         Let me tell you a bit about how Cuis got started. Many years
>         ago I did my thesis on audio/music processing. The I wanted to
>         turn that into a novel and fun application for musicians (both
>         pros and anyone willing to play with sound). I started to
>         think about how a good GUI for that could be, giving the
>         feeling of modifying sound by direct manipulation of it, as if
>         it was clay, as if it was visual and not just auditory. Well,
>         that was the start of my questioning of the whole GUI business
>         and Morphic 3. And it became clear to me that Squeak had
>         turned into something that was not the best possible
>         environment to do all this. The idea of "fixing" Squeak, and
>         thus make Cuis, was born. So, Cuis was not and end in itself,
>         but a means for allowing experimentation, freedom to build
>         applications in new styles, etc.
>         
>         (The idea that Cuis is a truer Smalltalk-80 than Squeak or any
>         other came later, as an observation on facts.)
>         
>         So, when the moment comes when Cuis stabilizes a bit, and
>         interest moves to packages and applications built by all us,
>         Cuis will start to fulfill its original objective.
>         
>         </slowly diverging into OT rant>
>         
>                         ...
>                         The problem, I think, is not identifying well
>                         defined Cuis releases. The
>                         problem is knowing how updates could affect
>                         your code
>                 By narrowing the scope of what the public API is using
>                 private
>                 designators, this dramatically reduces what you need
>                 to be concerned
>                 with on this front.  It's part of the reason that
>                 Apple, Google, and
>                 even Microsoft are so adamant about public APIs these
>                 days.  They dealt
>                 with the pain of even major developers depending on
>                 private APIs for
>                 decades. It's only been in the last 10 years or so
>                 that they've been
>                 able to dig themselves out from under this issue.
>                 
>                 This gets back to the 'Smalltalk Way' issue I
>                 referenced earlier.  The
>                 attitude of 'you have the source, play around, have
>                 fun!' has morphed
>                 into 'everything is a public API!  there are no rules!
>                 isn't this
>                 great?'  Well no, it's not great.  It makes life
>                 impossible for image
>                 maintainers (Squeak has been in a coma for the last
>                 decade or so as the
>                 result of trying to keep everyone happy... yet no one
>                 seems to be) and
>                 miserable for those who are trying to keep code
>                 running on it (stuff
>                 still breaks all the time.)
>         
>         Yes.
>         
>                 I personally believe the minimalism and simplicity
>                 that Cuis is based on
>                 has the best long term prospects but we have to get
>                 out of this
>                 'everything is public' mindset.  Sure, we have all the
>                 source: look at
>                 it, learn from it, poke around, refactor it, submit
>                 fixes, etc.  But
>                 there needs to be a manageable subset of it which is
>                 considered the
>                 'public API' that people can depend on to write
>                 frameworks and apps on
>                 top of that is relatively stable longer term.  Let's
>                 start defining what
>                 that is and backfill changes to the public API (which
>                 will happen from
>                 time to time as we don't want things to be completely
>                 static) with tests
>                 and documentation so you can focus your efforts on
>                 where they matter
>                 most and you get the most enjoyment from.
>         
>         I fully agree and support this.
>         Maybe an alternative to yet-another-convention-on-categories
>         could be to mark public methods with a pragma, or make them
>         send 'self publicAPI' or such... This could be better for the
>         tools, also.
>         
>                 ...
>                         I don't have that either. I run the tests from
>                         time to time (I'll start
>                         doing it before any commit, and add the xml
>                         report to the rep). But this
>                         is not the most important reason why Cuis is
>                         solid. Cuis is very
>                         reliable because:
>                 reliable != stable
>         
>         ;)
>         
>                         - I'm not too bad as a coder.
>                         - I do my own code revisions at least one day
>                         after each change.
>                         - I use Cuis every day, and spot most problems
>                         in the updates, before
>                         commtting them to the repo.
>                         - I really, really care about code quality.
>                         - I think Cuis keeps Smalltalk-80 and its
>                         ideals alive. And I think that
>                         is a big responsibility, given how important I
>                         think Smalltalk-80 is.
>                         
>                 Agree to all this and more.  Cuis would not be where
>                 it is without your
>                 continued effort and diligence. (i.e. setting aside
>                 that you obviously
>                 created it, if you had just tossed it out into the
>                 world and let it go
>                 at best it would have started looking something like
>                 Squeak or Pharo by
>                 now.  It's a lot of effort over the long term to
>                 *keep* it small and
>                 focused.  THANK YOU JUAN!)
>         
>         Thanks for your nice words, Phil. I really appreciate that you
>         all accept this rather restrictive dev model for the base
>         image, in contrast with a more open trunk style. Hopefully, as
>         the base image becomes stable and almost irrelevant, this will
>         be each time less of a problem.
>         
>                         So, I suggest running your tests when updating
>                         your image, or migrating
>                         your code to an updated image.
>                 +1 to tests as they do help quite a bit and are a very
>                 good practice.
>                 Just be judicious in what/where you test (I personally
>                 don't subscribe
>                 to the TDD approach where you spend your days mostly
>                 writing tests.
>                 That's just admitting defeat in that you spend all day
>                 writing
>                 executable documentation.)
>         
>         <OT>
>         
>         I don't subscribe to "extreme" TDD either. To me design is a
>         creative activity, both technical and artistic. It should be
>         "driven" by creativity and intelligence, not by a process. Any
>         xDD process is admitting defeat on design itself!
>         
>         </OT>
>         
>                         In any case, I think this doesn't answer your
>                         concerns. What you need is
>                         some way to know which updates could affect
>                         you, to review them in
>                         detail, and understanding their effect on your
>                         code. A list of the
>                         affected classes and/or methods for each
>                         update makes no sense. Cuis can
>                         already show you that very easily. Perhaps
>                         each update should include:
>                         
>                         1) parts of the system that are affected:
>                         - Kernel
>                         - Compiler
>                         - Tools
>                         - Morphic
>                         - etc
>                         
>                         2) Level of risk involved
>                         - very unlikely to break code that depends on
>                         this part of the system
>                         - could perhaps break code that depends on
>                         this part of the system
>                         - will most likely break code that depends on
>                         this part of the system
>                         
>                         Or something like that.
>                         
>                         BTW, this is a very relevant topic for
>                         discussing on the mail list. Feel
>                         free to answer there if you agree.
>                 One final thought on this:  I suspect a major cause of
>                 people abandoning
>                 Cuis (and Smalltalk in general), behind the 'it's too
>                 different from
>                 what I'm used to'/'not mainstream' reaction, is the
>                 instability of its
>                 APIs.
>         
>         Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0
>         problem) is a PITA too...
>         
>         As a bottom line, let me repeat: This is too big for me to do
>         it. Please, folks, start documenting the APIs you most care
>         about.
>         
>         Cheers,
>         Juan Vuletich
>         
>         _______________________________________________
>         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 kbrown at mac.com  Sun Jul 19 22:21:29 2015
From: kbrown at mac.com (Ken G. Brown)
Date: Sun, 19 Jul 2015 21:21:29 -0600
Subject: [Cuis]  Baseline version?
In-Reply-To: <mailman.94.1437354099.18328.cuis_jvuletich.org@jvuletich.org>
References: <mailman.94.1437354099.18328.cuis_jvuletich.org@jvuletich.org>
Message-ID: <4CA2DB35-1A26-46CE-B5D1-ACB50DC642B0@mac.com>

Craig Latta has a nice write up about his decent looking versioning system for Spoon: http://netjam.org/versions/

Ken G. Brown

> Date: Sun, 19 Jul 2015 23:01:22 +0000
> From: "H. Hirzel" <hannes.hirzel at gmail.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Subject: [Cuis] Baseline version?
> Message-ID:
>    <CAGQxfVg7XkxDx0GXRzbM-g-efzvVKeafy3H5DzNJdjkzTwxDUg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
>> On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
>> On Sun, 19 Jul 2015 11:20:19 -0300
> ....
>> I'd like to propose a simpler model based on the Smalltalk Way.
>> 
>> We take any stable revision, call it a version, give it a Baseline Version
>> Number (could be just the development version number).
> 
> I'd like to suggest to label just the current version as a "baseline".
> 
> It would not need a long description, just a few keywords regarding
> major changes like the addition of the FileMan package with a
> reference to the description of it.
> 
> The last one
> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
> 
> had
> 
> New in Cuis 4.2 (released July 25, 2013)
> 
>    Packages now have dependencies
> 
>    Package loading greatly enhanced
> 
>    Moved non-essential stuff to optional packages. Cuis is now below
> 500 classes and 100kLOC. Reduction was about 25%
> 
>    Many bugfixes, and minor enhancements and cleanup
> 
> 
> So this one would have
> 
> New in Cuis 4.3 (released July 25, 2015)
> 
>     Many bugfixes, and minor enhancements and cleanup
> 
>     Addition of FileMan
> 
>    .....................
> 
>    .......................
> 
> 
>    .....................
> 
>    .......................
> 
> 
> 
> And then after testing various packages on it
> another baseline at the end of the year with a release document.
> 
> New in Cuis 4.4 (released December 31, 2015)
> 
>     Many bugfixes, and minor enhancements and cleanup
> 
>    .....................
> 
>    .....................
> 
>    .......................
> 
> 
>    .....................
> 
>    .......................
> 
>    .....................
> 
>    .......................
> 
> 
> More text as we will be more aware of the changes.
> 
> 
> 
>> Each Baseline
>> Release has a release document which describes major changes since the
>> previous baseline.  This document is a light-weight description.
>> 
>> Each baseline release starts a new fork.  The only changes to the particular
>> baseline release are bug fixes.
>> 
>> Nice users test their packages and likewise fork a Package Release which
>> matches a Baseline Release.  This fork also only changes with bug fixes, and
>> only in synch with its particular baseline.  Baseline packages Feature the
>> baseline release.
>> 
>> So we forge ahead as usual, once in a while we say "enough has changed that
>> we should re-baseline", do a new Baseline Release, test and release our
>> Package Releases, then again move on forward.
>> 
>> Anyone can now pick any baseline release, require any associated packages,
>> and ship/demo without fear.
>> 
>> Anyone with the time, energy, and interest can document baseline APIs to
>> whatever level they feel comfortable.
>> 
>> Anyone can forge on ahead with the latest revision(s) with the usual "here
>> be dragons, but also gold".
>> 
>> $0.02
>> -KenD
>> 
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> 
> 



From hannes.hirzel at gmail.com  Mon Jul 20 02:35:38 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 07:35:38 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AC4B3F.19938.1F92268@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
	<55ABA6A2.5090607@jvuletich.org>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
Message-ID: <CAGQxfVhxnkq00Qi7OhuQo3Lbvqb03nRJi2sFxkQxHVet2439jw@mail.gmail.com>

On 7/20/15, Dan Norton <dnorton at mindspring.com> wrote:
> On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>
>> On 7/18/2015 3:37 PM, Dan Norton wrote:
>> > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>> >
>> >> Hi Folks,
>> >>
>> >> It is not too hard to build new StrikeFonts. You need to build,
>> by
>> >> hand,
>> >> files like the ones in here:
>> >>
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> >> p
>> >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
>> with
>> >> this method and the files in this zip that built the existing
>> >> instances
>> >> of StrikeFont. Not sure.
>> >>
>> > That's intrigueing but I can't reproduce it. Maybe the .bmp but
>> where did you get the .txt?
>> >
>> >   - Dan
>>
>> I wrote them with a text editor. Check #installDejaVu2 and really
>> try to
>> understand how StrikeFonts work and how they are built with this
>> method.
>> Maybe you'll become enlightened.
>>
>
> A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name, and
> several scalars.
> StrikeFont class methods create fonts by processing file pairs assumed to be
> in the
> "AAFonts" subdirectory. For example:
>
> DejaVu Sans Oblique 14.bmp
> DejaVu Sans Oblique 14.txt
>
> Is one such pair providing the italic (oblique) style for 14-point size.
> There is a pair for every
> font size and style: base, bold, italic, and bold italic. Therefore a font
> such as "DejaVu Sans"
> which is available in the size interval 5 to 24 requires 160 files. The file
> names are stylized
> and encoded in the StrikeFont class methods.
>
> Glyphs come from the .bmp file. The .txt file is a string of numbers; the
> first three specify
> pointSize, ascent, and	descent. The rest of the numbers in the .txt file are
> used to form the
> xTable, which is the index into the glyphs for a character. The
> characterToGlyphMap is an
> array of 256 entries which map a character's ascii value to the xTable and
> thence to the
> glyphs.
>
> The bold, italic, and bold italic styles are stashed as derivatives of the
> base and not
> selectable from the current menus.
>
> StrikeFont is a subclass of AbstractFont, which has class variables
> AvailableFonts and
> DefaultFont.
>
> If it can't find a file, StrikeFont will loop.
>
> In regard to creating the .bmp and .txt files, you say, "I wrote them with a
> text editor." Please
> tell me which text editor you used. None of mine do that.
>
>  - Dan

What I used in the past is the StrikeFont bitmap editor which is in
Squeak. In MVC if I remember well. So an early version of Squeak (e.g.
3.8.1 Oct 2006)  is helpful.

These versions are very accessible these days  http://squeak.org/downloads/

--Hannes



From hannes.hirzel at gmail.com  Mon Jul 20 03:06:33 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:06:33 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1437353009.6934.223.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
Message-ID: <CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> Hi Hannes,
>
> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>> >>
>> >> > As Casey writes "The hard part is time and energy to do so."
>> >> >
>> >> > So what can be done with minimal effort and big impact?
>> >>
>> >> Looking around, I see that I could make some simple naming changes for
>> >> test cases.
>> >>
>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>> >>
>> >> We could use other words, but API is shorter than Usage, Example,
>> >> Interface.
>> >>
>> >> Having specific test names end in 'API' would clue me in.
>> >>
>> >> Adding 'Nacl' means I can use the existing message finder to search
>> >> for
>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>> >> specific
>> >> to Nacl.
>> >>
>> >> And we can do this as I get the chance.
>> >>
>> >> Other suggestions?
>> >
>> > I started playing around with a couple of example test cases to see
>> > what
>> > I ran into and came up with a distinct class to store all of these per
>> > test category (i.e. under Test-Files a class ApiFile which could have a
>> > method testWriteTextFile)  The rationale was that it might make sense
>> > to
>> > keep these test cases separate from traditional test cases which are
>> > free to make calls that users of the class (i.e. who are calling the
>> > supported API) should not.
>>
>> Phil,
>>
>> where do you keep this class ApiFile?
>>
>
> It's in Packages/Tests.pck.st package. After loading it will be listed
> in the Tests-Files category.


I loaded the class ApiFile only and I get 3 tests passed and 1 failure
in Cuis 2.4-2424.

Can you confirm this, Phil?

>> regards
>>
>> Hannes
>>
>
> Thanks,
> Phil
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis4.2-2424-ApiFile Test Screenshot from 2015-07-20 07:56:23.png
Type: image/png
Size: 127147 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/7a96c85d/attachment-0002.png>

From hannes.hirzel at gmail.com  Mon Jul 20 03:16:02 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:16:02 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
Message-ID: <CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>

The file testResults.xml which Juan added has

<testcase classname="ApiFile" name="testImagePNG01WriteToFile"
status="passed"/>
<testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
status="passed"/>
<testcase classname="ApiFile" name="testText01WriteToFile" status="passed"/>
<testcase classname="ApiFile" name="testText02ReadFromFile" status="passed"/>

So there is an issue of test setup which was not fullfilled in my case....
Might be a Linux Mint issue (access rights)

On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> Hi Hannes,
>>
>> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>> >>
>>> >> > As Casey writes "The hard part is time and energy to do so."
>>> >> >
>>> >> > So what can be done with minimal effort and big impact?
>>> >>
>>> >> Looking around, I see that I could make some simple naming changes
>>> >> for
>>> >> test cases.
>>> >>
>>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>>> >>
>>> >> We could use other words, but API is shorter than Usage, Example,
>>> >> Interface.
>>> >>
>>> >> Having specific test names end in 'API' would clue me in.
>>> >>
>>> >> Adding 'Nacl' means I can use the existing message finder to search
>>> >> for
>>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>>> >> specific
>>> >> to Nacl.
>>> >>
>>> >> And we can do this as I get the chance.
>>> >>
>>> >> Other suggestions?
>>> >
>>> > I started playing around with a couple of example test cases to see
>>> > what
>>> > I ran into and came up with a distinct class to store all of these per
>>> > test category (i.e. under Test-Files a class ApiFile which could have
>>> > a
>>> > method testWriteTextFile)  The rationale was that it might make sense
>>> > to
>>> > keep these test cases separate from traditional test cases which are
>>> > free to make calls that users of the class (i.e. who are calling the
>>> > supported API) should not.
>>>
>>> Phil,
>>>
>>> where do you keep this class ApiFile?
>>>
>>
>> It's in Packages/Tests.pck.st package. After loading it will be listed
>> in the Tests-Files category.
>
>
> I loaded the class ApiFile only and I get 3 tests passed and 1 failure
> in Cuis 2.4-2424.
>
> Can you confirm this, Phil?
>
>>> regards
>>>
>>> Hannes
>>>
>>
>> Thanks,
>> Phil
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis4.2-2424_Testfiles_on_LinuxMint_Screenshot from 2015-07-20 08:13:48.png
Type: image/png
Size: 36391 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/7a092b24/attachment-0002.png>

From hannes.hirzel at gmail.com  Mon Jul 20 03:22:41 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:22:41 +0000
Subject: [Cuis] Where are SUnit tests and how do I get them?
In-Reply-To: <1437353410.6934.229.camel@gmail.com>
References: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>
	<1437353410.6934.229.camel@gmail.com>
Message-ID: <CAGQxfVgbdhZasgBHydZ6ykFuu+=O5D9rP4+MZN=Nn1Gitj92dA@mail.gmail.com>

I got the tests, the way you describe. I only loaded class ApiFile,
see other thread.

--Hannes

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> Hannes,
>
> On Sun, 2015-07-19 at 23:57 +0000, H. Hirzel wrote:
>> Hello
>>
>> In the current image when I open the SUnit browser no tests appear.
>>
>>
>> I assume the SUnit tests now in
>>
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st
>>
>> ?
>>
>> Are all tests there?
>>
>> An snippet how to load them in the 'Useful Expression Workspace' would be
>> fine.
>>
>
> The main Cuis tests are in the Packages/Tests.pck.st file I mentioned in
> my previous reply.  Additionally, many of the 3rd party packages also
> have optional tests (usually <PackageName>Tests.pck.st or something
> similar) which can be loaded.  They don't get loaded by default so you
> need to open a file browser, navigate to them, and install the
> package(s).
>
>> Regards
>> Hannes
>>
>> _______________________________________________
>> 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 hannes.hirzel at gmail.com  Mon Jul 20 03:30:38 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:30:38 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
Message-ID: <CAGQxfVg==3cZfayb1xZXiT5pA8mkas9xE12LNHNLwO8cRMEvUg@mail.gmail.com>

On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> The file testResults.xml which Juan added has
>
> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testText01WriteToFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testText02ReadFromFile"
> status="passed"/>
>
> So there is an issue of test setup which was not fullfilled in my case....
> Might be a Linux Mint issue (access rights)

The debugger indicated that I need Graphics-Files-Additional and in
fact the package header says this.

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st#L1

'From Cuis 4.2 of 25 July 2013 [latest update: #2424] on 18 July 2015
at 7:09:24.325834 pm'!
'Description Please enter a description for this package '!
!provides: 'Tests' 1 28!
!requires: 'Graphics-Files-Additional' 1 nil nil!
!requires: 'Compression' 1 nil nil!


> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>>> Hi Hannes,
>>>
>>> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>>>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>>>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>>>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>>>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>>> >>
>>>> >> > As Casey writes "The hard part is time and energy to do so."
>>>> >> >
>>>> >> > So what can be done with minimal effort and big impact?
>>>> >>
>>>> >> Looking around, I see that I could make some simple naming changes
>>>> >> for
>>>> >> test cases.
>>>> >>
>>>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>>>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>>>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>>>> >>
>>>> >> We could use other words, but API is shorter than Usage, Example,
>>>> >> Interface.
>>>> >>
>>>> >> Having specific test names end in 'API' would clue me in.
>>>> >>
>>>> >> Adding 'Nacl' means I can use the existing message finder to search
>>>> >> for
>>>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>>>> >> specific
>>>> >> to Nacl.
>>>> >>
>>>> >> And we can do this as I get the chance.
>>>> >>
>>>> >> Other suggestions?
>>>> >
>>>> > I started playing around with a couple of example test cases to see
>>>> > what
>>>> > I ran into and came up with a distinct class to store all of these
>>>> > per
>>>> > test category (i.e. under Test-Files a class ApiFile which could have
>>>> > a
>>>> > method testWriteTextFile)  The rationale was that it might make sense
>>>> > to
>>>> > keep these test cases separate from traditional test cases which are
>>>> > free to make calls that users of the class (i.e. who are calling the
>>>> > supported API) should not.
>>>>
>>>> Phil,
>>>>
>>>> where do you keep this class ApiFile?
>>>>
>>>
>>> It's in Packages/Tests.pck.st package. After loading it will be listed
>>> in the Tests-Files category.
>>
>>
>> I loaded the class ApiFile only and I get 3 tests passed and 1 failure
>> in Cuis 2.4-2424.
>>
>> Can you confirm this, Phil?
>>
>>>> regards
>>>>
>>>> Hannes
>>>>
>>>
>>> Thanks,
>>> Phil
>>>
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis-4.2-2424_ApiFile_SUnit_test_result_Screenshot from 2015-07-20 08:21:33.png
Type: image/png
Size: 20022 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/2ed77677/attachment-0002.png>

From pbpublist at gmail.com  Mon Jul 20 03:33:57 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 04:33:57 -0400
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
Message-ID: <1437381237.2286.13.camel@gmail.com>

On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
> The file testResults.xml which Juan added has
> 
> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testText01WriteToFile" status="passed"/>
> <testcase classname="ApiFile" name="testText02ReadFromFile" status="passed"/>
> 
> So there is an issue of test setup which was not fullfilled in my case....
> Might be a Linux Mint issue (access rights)
> 

I don't have the test in front of me right now but if I recall, the
setup code exists to create a temp directory in the same directory the
image was launched from to write the test files. (that was the best way
I could come up with to not introduce any platform-specific path
handling issues to the test)

If the setup code failed, then the test would have probably failed.  Did
you manually do anything or did it just work the 2nd time you ran it?
(if it re-ran successfully without you needing to do anything else, it
definitely sounds like a problem in the test setup.  If it were a rights
issue, it should have continued to fail.)

The good news is we're about to change all the file/directory handling
code so it needs to be updated anyway...

> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> Hi Hannes,
> >>
> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
> >>> >>
> >>> >> > As Casey writes "The hard part is time and energy to do so."
> >>> >> >
> >>> >> > So what can be done with minimal effort and big impact?
> >>> >>
> >>> >> Looking around, I see that I could make some simple naming changes
> >>> >> for
> >>> >> test cases.
> >>> >>
> >>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
> >>> >>
> >>> >> We could use other words, but API is shorter than Usage, Example,
> >>> >> Interface.
> >>> >>
> >>> >> Having specific test names end in 'API' would clue me in.
> >>> >>
> >>> >> Adding 'Nacl' means I can use the existing message finder to search
> >>> >> for
> >>> >> 'api' and note testNacl*API methods.  This lets me find API tests
> >>> >> specific
> >>> >> to Nacl.
> >>> >>
> >>> >> And we can do this as I get the chance.
> >>> >>
> >>> >> Other suggestions?
> >>> >
> >>> > I started playing around with a couple of example test cases to see
> >>> > what
> >>> > I ran into and came up with a distinct class to store all of these per
> >>> > test category (i.e. under Test-Files a class ApiFile which could have
> >>> > a
> >>> > method testWriteTextFile)  The rationale was that it might make sense
> >>> > to
> >>> > keep these test cases separate from traditional test cases which are
> >>> > free to make calls that users of the class (i.e. who are calling the
> >>> > supported API) should not.
> >>>
> >>> Phil,
> >>>
> >>> where do you keep this class ApiFile?
> >>>
> >>
> >> It's in Packages/Tests.pck.st package. After loading it will be listed
> >> in the Tests-Files category.
> >
> >
> > I loaded the class ApiFile only and I get 3 tests passed and 1 failure
> > in Cuis 2.4-2424.
> >
> > Can you confirm this, Phil?
> >
> >>> regards
> >>>
> >>> Hannes
> >>>
> >>
> >> Thanks,
> >> Phil
> >>
> >>
> >> _______________________________________________
> >> 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 hannes.hirzel at gmail.com  Mon Jul 20 03:45:53 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:45:53 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1437381237.2286.13.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
	<1437381237.2286.13.camel@gmail.com>
Message-ID: <CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>

The reason was

I only cherry picked the ApiFile class by manual loading.

After adding  Graphics-Files-Additional.pck.st manually it worked.

Another interesting test case is to write out a StrikeFont to the file
system in the proper
canonical export format (bmp and text) with a new name  and read it
back as a new font.

--Hannes

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
>> The file testResults.xml which Juan added has
>>
>> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
>> status="passed"/>
>> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
>> status="passed"/>
>> <testcase classname="ApiFile" name="testText01WriteToFile"
>> status="passed"/>
>> <testcase classname="ApiFile" name="testText02ReadFromFile"
>> status="passed"/>
>>
>> So there is an issue of test setup which was not fullfilled in my
>> case....
>> Might be a Linux Mint issue (access rights)
>>
>
> I don't have the test in front of me right now but if I recall, the
> setup code exists to create a temp directory in the same directory the
> image was launched from to write the test files. (that was the best way
> I could come up with to not introduce any platform-specific path
> handling issues to the test)
>
> If the setup code failed, then the test would have probably failed.  Did
> you manually do anything or did it just work the 2nd time you ran it?
> (if it re-ran successfully without you needing to do anything else, it
> definitely sounds like a problem in the test setup.  If it were a rights
> issue, it should have continued to fail.)
>
> The good news is we're about to change all the file/directory handling
> code so it needs to be updated anyway...
>
>> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >> Hi Hannes,
>> >>
>> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>> >>> >>
>> >>> >> > As Casey writes "The hard part is time and energy to do so."
>> >>> >> >
>> >>> >> > So what can be done with minimal effort and big impact?
>> >>> >>
>> >>> >> Looking around, I see that I could make some simple naming changes
>> >>> >> for
>> >>> >> test cases.
>> >>> >>
>> >>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>> >>> >>
>> >>> >> We could use other words, but API is shorter than Usage, Example,
>> >>> >> Interface.
>> >>> >>
>> >>> >> Having specific test names end in 'API' would clue me in.
>> >>> >>
>> >>> >> Adding 'Nacl' means I can use the existing message finder to
>> >>> >> search
>> >>> >> for
>> >>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>> >>> >> specific
>> >>> >> to Nacl.
>> >>> >>
>> >>> >> And we can do this as I get the chance.
>> >>> >>
>> >>> >> Other suggestions?
>> >>> >
>> >>> > I started playing around with a couple of example test cases to see
>> >>> > what
>> >>> > I ran into and came up with a distinct class to store all of these
>> >>> > per
>> >>> > test category (i.e. under Test-Files a class ApiFile which could
>> >>> > have
>> >>> > a
>> >>> > method testWriteTextFile)  The rationale was that it might make
>> >>> > sense
>> >>> > to
>> >>> > keep these test cases separate from traditional test cases which
>> >>> > are
>> >>> > free to make calls that users of the class (i.e. who are calling
>> >>> > the
>> >>> > supported API) should not.
>> >>>
>> >>> Phil,
>> >>>
>> >>> where do you keep this class ApiFile?
>> >>>
>> >>
>> >> It's in Packages/Tests.pck.st package. After loading it will be listed
>> >> in the Tests-Files category.
>> >
>> >
>> > I loaded the class ApiFile only and I get 3 tests passed and 1 failure
>> > in Cuis 2.4-2424.
>> >
>> > Can you confirm this, Phil?
>> >
>> >>> regards
>> >>>
>> >>> Hannes
>> >>>
>> >>
>> >> Thanks,
>> >> Phil
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From pbpublist at gmail.com  Mon Jul 20 04:43:58 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 05:43:58 -0400
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
	<1437381237.2286.13.camel@gmail.com>
	<CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>
Message-ID: <1437385438.2286.33.camel@gmail.com>

On Mon, 2015-07-20 at 08:45 +0000, H. Hirzel wrote:
> The reason was
> 
> I only cherry picked the ApiFile class by manual loading.
> 
> After adding  Graphics-Files-Additional.pck.st manually it worked.
> 

That would do it.  By adding 'manually' do you mean that you didn't have
the Graphics package downloaded at the time you loaded Tests?  That's
the only reason I can think of that the package manager wouldn't have
loaded Graphics for you automatically given the dependency.

> Another interesting test case is to write out a StrikeFont to the file
> system in the proper
> canonical export format (bmp and text) with a new name  and read it
> back as a new font.
> 

That's the sort of thing I was getting at with these tests: if there is
some useful bit of work that you need to be able to do (especially
something larger than a unit test and/or crossing package boundaries),
to create a test for it to help Juan understand the functionality we're
using.  This was one way I came up with to try to get to some sort of
agreed upon public API.  In retrospect, I probably put the cart before
the horse as doing all of these tests will take considerably longer than
initially flagging methods considered to be public.  But hopefully you
can see how doing both could complement each other.  To reiterate: this
work is on us to do up front, Juan would just review and commit.

> --Hannes
> 
> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> > On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
> >> The file testResults.xml which Juan added has
> >>
> >> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
> >> status="passed"/>
> >> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
> >> status="passed"/>
> >> <testcase classname="ApiFile" name="testText01WriteToFile"
> >> status="passed"/>
> >> <testcase classname="ApiFile" name="testText02ReadFromFile"
> >> status="passed"/>
> >>
> >> So there is an issue of test setup which was not fullfilled in my
> >> case....
> >> Might be a Linux Mint issue (access rights)
> >>
> >
> > I don't have the test in front of me right now but if I recall, the
> > setup code exists to create a temp directory in the same directory the
> > image was launched from to write the test files. (that was the best way
> > I could come up with to not introduce any platform-specific path
> > handling issues to the test)
> >
> > If the setup code failed, then the test would have probably failed.  Did
> > you manually do anything or did it just work the 2nd time you ran it?
> > (if it re-ran successfully without you needing to do anything else, it
> > definitely sounds like a problem in the test setup.  If it were a rights
> > issue, it should have continued to fail.)
> >
> > The good news is we're about to change all the file/directory handling
> > code so it needs to be updated anyway...
> >
> >> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> >> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> >> Hi Hannes,
> >> >>
> >> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
> >> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
> >> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
> >> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
> >> >>> >>
> >> >>> >> > As Casey writes "The hard part is time and energy to do so."
> >> >>> >> >
> >> >>> >> > So what can be done with minimal effort and big impact?
> >> >>> >>
> >> >>> >> Looking around, I see that I could make some simple naming changes
> >> >>> >> for
> >> >>> >> test cases.
> >> >>> >>
> >> >>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
> >> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
> >> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
> >> >>> >>
> >> >>> >> We could use other words, but API is shorter than Usage, Example,
> >> >>> >> Interface.
> >> >>> >>
> >> >>> >> Having specific test names end in 'API' would clue me in.
> >> >>> >>
> >> >>> >> Adding 'Nacl' means I can use the existing message finder to
> >> >>> >> search
> >> >>> >> for
> >> >>> >> 'api' and note testNacl*API methods.  This lets me find API tests
> >> >>> >> specific
> >> >>> >> to Nacl.
> >> >>> >>
> >> >>> >> And we can do this as I get the chance.
> >> >>> >>
> >> >>> >> Other suggestions?
> >> >>> >
> >> >>> > I started playing around with a couple of example test cases to see
> >> >>> > what
> >> >>> > I ran into and came up with a distinct class to store all of these
> >> >>> > per
> >> >>> > test category (i.e. under Test-Files a class ApiFile which could
> >> >>> > have
> >> >>> > a
> >> >>> > method testWriteTextFile)  The rationale was that it might make
> >> >>> > sense
> >> >>> > to
> >> >>> > keep these test cases separate from traditional test cases which
> >> >>> > are
> >> >>> > free to make calls that users of the class (i.e. who are calling
> >> >>> > the
> >> >>> > supported API) should not.
> >> >>>
> >> >>> Phil,
> >> >>>
> >> >>> where do you keep this class ApiFile?
> >> >>>
> >> >>
> >> >> It's in Packages/Tests.pck.st package. After loading it will be listed
> >> >> in the Tests-Files category.
> >> >
> >> >
> >> > I loaded the class ApiFile only and I get 3 tests passed and 1 failure
> >> > in Cuis 2.4-2424.
> >> >
> >> > Can you confirm this, Phil?
> >> >
> >> >>> regards
> >> >>>
> >> >>> Hannes
> >> >>>
> >> >>
> >> >> Thanks,
> >> >> Phil
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> 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
> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From hannes.hirzel at gmail.com  Mon Jul 20 07:31:22 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:31:22 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1437385438.2286.33.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
	<1437381237.2286.13.camel@gmail.com>
	<CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>
	<1437385438.2286.33.camel@gmail.com>
Message-ID: <CAGQxfViPQp2vBYh_To2nU05A5LVDF9VoAML1SMXbYH6Fm5KJzw@mail.gmail.com>

I think both is valuable and we need both

1. Doing larger tests like the 4 tests you did in ApiFile. They show
typical use cases.

2. flagging methods considered to be public. This can be done with a
test as well.
    Just a long list of checking with respondsTo: if a methods exist.



On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-07-20 at 08:45 +0000, H. Hirzel wrote:
>> The reason was
>>
>> I only cherry picked the ApiFile class by manual loading.
>>
>> After adding  Graphics-Files-Additional.pck.st manually it worked.
>>
>
> That would do it.  By adding 'manually' do you mean that you didn't have
> the Graphics package downloaded at the time you loaded Tests?  That's
> the only reason I can think of that the package manager wouldn't have
> loaded Graphics for you automatically given the dependency.
>
>> Another interesting test case is to write out a StrikeFont to the file
>> system in the proper
>> canonical export format (bmp and text) with a new name  and read it
>> back as a new font.
>>
>
> That's the sort of thing I was getting at with these tests: if there is
> some useful bit of work that you need to be able to do (especially
> something larger than a unit test and/or crossing package boundaries),
> to create a test for it to help Juan understand the functionality we're
> using.  This was one way I came up with to try to get to some sort of
> agreed upon public API.  In retrospect, I probably put the cart before
> the horse as doing all of these tests will take considerably longer than
> initially flagging methods considered to be public.  But hopefully you
> can see how doing both could complement each other.  To reiterate: this
> work is on us to do up front, Juan would just review and commit.
>
>> --Hannes
>>
>> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> > On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
>> >> The file testResults.xml which Juan added has
>> >>
>> >> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
>> >> status="passed"/>
>> >> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
>> >> status="passed"/>
>> >> <testcase classname="ApiFile" name="testText01WriteToFile"
>> >> status="passed"/>
>> >> <testcase classname="ApiFile" name="testText02ReadFromFile"
>> >> status="passed"/>
>> >>
>> >> So there is an issue of test setup which was not fullfilled in my
>> >> case....
>> >> Might be a Linux Mint issue (access rights)
>> >>
>> >
>> > I don't have the test in front of me right now but if I recall, the
>> > setup code exists to create a temp directory in the same directory the
>> > image was launched from to write the test files. (that was the best way
>> > I could come up with to not introduce any platform-specific path
>> > handling issues to the test)
>> >
>> > If the setup code failed, then the test would have probably failed.
>> > Did
>> > you manually do anything or did it just work the 2nd time you ran it?
>> > (if it re-ran successfully without you needing to do anything else, it
>> > definitely sounds like a problem in the test setup.  If it were a
>> > rights
>> > issue, it should have continued to fail.)
>> >
>> > The good news is we're about to change all the file/directory handling
>> > code so it needs to be updated anyway...
>> >
>> >> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> >> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >> >> Hi Hannes,
>> >> >>
>> >> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>> >> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> >> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>> >> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>> >> >>> >>
>> >> >>> >> > As Casey writes "The hard part is time and energy to do so."
>> >> >>> >> >
>> >> >>> >> > So what can be done with minimal effort and big impact?
>> >> >>> >>
>> >> >>> >> Looking around, I see that I could make some simple naming
>> >> >>> >> changes
>> >> >>> >> for
>> >> >>> >> test cases.
>> >> >>> >>
>> >> >>> >> E.g in package Crypto-Nacl there are test cases (class
>> >> >>> >> NaclTests)
>> >> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>> >> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>> >> >>> >>
>> >> >>> >> We could use other words, but API is shorter than Usage,
>> >> >>> >> Example,
>> >> >>> >> Interface.
>> >> >>> >>
>> >> >>> >> Having specific test names end in 'API' would clue me in.
>> >> >>> >>
>> >> >>> >> Adding 'Nacl' means I can use the existing message finder to
>> >> >>> >> search
>> >> >>> >> for
>> >> >>> >> 'api' and note testNacl*API methods.  This lets me find API
>> >> >>> >> tests
>> >> >>> >> specific
>> >> >>> >> to Nacl.
>> >> >>> >>
>> >> >>> >> And we can do this as I get the chance.
>> >> >>> >>
>> >> >>> >> Other suggestions?
>> >> >>> >
>> >> >>> > I started playing around with a couple of example test cases to
>> >> >>> > see
>> >> >>> > what
>> >> >>> > I ran into and came up with a distinct class to store all of
>> >> >>> > these
>> >> >>> > per
>> >> >>> > test category (i.e. under Test-Files a class ApiFile which could
>> >> >>> > have
>> >> >>> > a
>> >> >>> > method testWriteTextFile)  The rationale was that it might make
>> >> >>> > sense
>> >> >>> > to
>> >> >>> > keep these test cases separate from traditional test cases which
>> >> >>> > are
>> >> >>> > free to make calls that users of the class (i.e. who are calling
>> >> >>> > the
>> >> >>> > supported API) should not.
>> >> >>>
>> >> >>> Phil,
>> >> >>>
>> >> >>> where do you keep this class ApiFile?
>> >> >>>
>> >> >>
>> >> >> It's in Packages/Tests.pck.st package. After loading it will be
>> >> >> listed
>> >> >> in the Tests-Files category.
>> >> >
>> >> >
>> >> > I loaded the class ApiFile only and I get 3 tests passed and 1
>> >> > failure
>> >> > in Cuis 2.4-2424.
>> >> >
>> >> > Can you confirm this, Phil?
>> >> >
>> >> >>> regards
>> >> >>>
>> >> >>> Hannes
>> >> >>>
>> >> >>
>> >> >> Thanks,
>> >> >> Phil
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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
>> > 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 hannes.hirzel at gmail.com  Mon Jul 20 07:41:41 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:41:41 +0000
Subject: [Cuis] #printStringLimitedTo:
In-Reply-To: <1437285899.6934.1.camel@gmail.com>
References: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>
	<1437285899.6934.1.camel@gmail.com>
Message-ID: <CAGQxfVi0Sjj8YNfYBxDKwa4sqWHJnAbApWfgHOOHdUy72nZYPA@mail.gmail.com>

Ken you ask about other options

one would be to have a method


#printStringLimitedTo:suffix:

so that people can have their own suffix.

Might be better in a multilingual environment.

However  '...etc...' is pretty general.

No objection if it stays as is.

--HH

On 7/19/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Sat, 2015-07-18 at 21:33 -0700, Ken.Dickey wrote:
>> I find it kind of odd that #printStringLimitedTo: takes the prefix of a
>> too-long string and adds '...etc...', which itself is 9 characters.
>>
>> I think a shorter addition would make more sense.  After all, the string
>> is already too long, right?
>>
>> I like '[..]' , which is only four characters.
>>
>> Would anyone else like to weigh in on this?  Other options?
>
> I agree that the current suffix is long-ish and like your [..] idea as
> that's unlikely to appear in the majority of strings but would still
> convey the information.
>
>> -KenD
>>
>> _______________________________________________
>> 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 hannes.hirzel at gmail.com  Mon Jul 20 07:47:19 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:47:19 +0000
Subject: [Cuis] Baseline version?
In-Reply-To: <4CA2DB35-1A26-46CE-B5D1-ACB50DC642B0@mac.com>
References: <mailman.94.1437354099.18328.cuis_jvuletich.org@jvuletich.org>
	<4CA2DB35-1A26-46CE-B5D1-ACB50DC642B0@mac.com>
Message-ID: <CAGQxfVhUXD_P8Tz7vqGh_9U=8C+WcPJKvSqtizMH-yLNNTcKQg@mail.gmail.com>

 http://netjam.org/versions/ is pretty general.

I would be fine with a very simple scheme these days. Just two
releases per year.

--HH

On 7/20/15, Ken G. Brown <kbrown at mac.com> wrote:
> Craig Latta has a nice write up about his decent looking versioning system
> for Spoon: http://netjam.org/versions/
>
> Ken G. Brown
>
>> Date: Sun, 19 Jul 2015 23:01:22 +0000
>> From: "H. Hirzel" <hannes.hirzel at gmail.com>
>> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
>> Subject: [Cuis] Baseline version?
>> Message-ID:
>>    <CAGQxfVg7XkxDx0GXRzbM-g-efzvVKeafy3H5DzNJdjkzTwxDUg at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>>> On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
>>> On Sun, 19 Jul 2015 11:20:19 -0300
>> ....
>>> I'd like to propose a simpler model based on the Smalltalk Way.
>>>
>>> We take any stable revision, call it a version, give it a Baseline
>>> Version
>>> Number (could be just the development version number).
>>
>> I'd like to suggest to label just the current version as a "baseline".
>>
>> It would not need a long description, just a few keywords regarding
>> major changes like the addition of the FileMan package with a
>> reference to the description of it.
>>
>> The last one
>> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
>>
>> had
>>
>> New in Cuis 4.2 (released July 25, 2013)
>>
>>    Packages now have dependencies
>>
>>    Package loading greatly enhanced
>>
>>    Moved non-essential stuff to optional packages. Cuis is now below
>> 500 classes and 100kLOC. Reduction was about 25%
>>
>>    Many bugfixes, and minor enhancements and cleanup
>>
>>
>> So this one would have
>>
>> New in Cuis 4.3 (released July 25, 2015)
>>
>>     Many bugfixes, and minor enhancements and cleanup
>>
>>     Addition of FileMan
>>
>>    .....................
>>
>>    .......................
>>
>>
>>    .....................
>>
>>    .......................
>>
>>
>>
>> And then after testing various packages on it
>> another baseline at the end of the year with a release document.
>>
>> New in Cuis 4.4 (released December 31, 2015)
>>
>>     Many bugfixes, and minor enhancements and cleanup
>>
>>    .....................
>>
>>    .....................
>>
>>    .......................
>>
>>
>>    .....................
>>
>>    .......................
>>
>>    .....................
>>
>>    .......................
>>
>>
>> More text as we will be more aware of the changes.
>>
>>
>>
>>> Each Baseline
>>> Release has a release document which describes major changes since the
>>> previous baseline.  This document is a light-weight description.
>>>
>>> Each baseline release starts a new fork.  The only changes to the
>>> particular
>>> baseline release are bug fixes.
>>>
>>> Nice users test their packages and likewise fork a Package Release which
>>> matches a Baseline Release.  This fork also only changes with bug fixes,
>>> and
>>> only in synch with its particular baseline.  Baseline packages Feature
>>> the
>>> baseline release.
>>>
>>> So we forge ahead as usual, once in a while we say "enough has changed
>>> that
>>> we should re-baseline", do a new Baseline Release, test and release our
>>> Package Releases, then again move on forward.
>>>
>>> Anyone can now pick any baseline release, require any associated
>>> packages,
>>> and ship/demo without fear.
>>>
>>> Anyone with the time, energy, and interest can document baseline APIs to
>>> whatever level they feel comfortable.
>>>
>>> Anyone can forge on ahead with the latest revision(s) with the usual
>>> "here
>>> be dragons, but also gold".
>>>
>>> $0.02
>>> -KenD
>>>
>>> _______________________________________________
>>> 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 hannes.hirzel at gmail.com  Mon Jul 20 07:55:57 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:55:57 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <1437354098.6934.240.camel@gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
	<CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>
	<1437354098.6934.240.camel@gmail.com>
Message-ID: <CAGQxfVjzR=pG2i4+RakCiNZKJ6EMTJGkXu5sX2OAdiMCjS24GQ@mail.gmail.com>

Yes,

an image diff to see what classes/methods changed between timer period X and Y

is what I am looking for.

--Hannes

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Sun, 2015-07-19 at 20:21 +0000, H. Hirzel wrote:
>> If I take a current image (18 Jul 2015, 4.2-2424)  I get the same result
>>
>>
>> a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
>> #at:ifAbsent:)
>>
>> All the FileMan additions are not listed. Maybe because they keep
>> their original time stamp, not the time stamp of the addition to
>> Squeak.
>>
>
> Right, the timestamp will reflect when they were last edited rather than
> when they were loaded into the image.
>
>> And the recent change on #compilerClass does not show up.
>>
>
> Same situation: #compilerClass while only recently re-added to the
> image, hasn't actually been changed since it was removed and added back
> so it still shows an older timestamp.
>
> It sounds like you're looking for more of an image diff to see what
> classes/methods changed between timer period X and Y?  This isn't
> something that currently exists in an easy to use form that I'm aware
> of.
>
>> --HH
>>
>> On 7/19/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> > If I use this to find out which methods have a time stamp date
>> > indicating a change after the 1st of January 2015 in a pristine Cuis
>> > 4.2-2243 (17 April 2015) image I find out that only the
>> >
>> > #postCopy method was changed (probably added) in nearly all classes.
>> >
>> > If I change the base line date to 1st of January 2014 I get
>> >
>> > a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
>> > #at:ifAbsent:)
>> > as changed/updated methods (i.e. methods which have a time stamp in
>> > this period).
>> >
>> > Of course this assumes that a method gets a time stamp when changed.
>> > Many methods have nil as a time stamp.
>> >
>> >
>> > Could somebody from the list check this please?
>> >
>> >
>> > |date coll baseLineDate dt  updatedMethods |
>> >
>> > baseLineDate := Date year: 2014 month: 1 day: 1.
>> > coll := OrderedCollection new.
>> >
>> > Smalltalk allClasses do: [ :cls |
>> > cls allSelectors do: [ :sel |
>> > dt := VersionsBrowser timeStampFor:  sel class: Dictionary
>> > reverseOrdinal:
>> > 1.
>> >
>> > dt notNil ifTrue: [
>> > date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
>> > ]) or: [ch = $:]] .
>> > (date = '') ifFalse:
>> > 	[date := Date fromString: date.
>> > 		(date > baseLineDate) ifTrue: [coll add: (Association key:
>> > (Association key: cls value: sel) value: date)
>> > ]]].
>> >
>> > ]].
>> >
>> > updatedMethods := Set new.
>> > coll do: [ :elem | updatedMethods add: (elem key value)].
>> > coll inspect.
>> > updatedMethods inspect
>> >
>> >
>> >
>> >
>> > On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
>> >> On 7/16/2015 11:49 AM, H. Hirzel wrote:
>> >>> Hello
>> >>>
>> >>> I'd like to do a query finding out about the time stamp of  source
>> >>> code changes of all methods in the Cuis image and then do a list with
>> >>> the following four columns
>> >>>
>> >>>
>> >>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
>> >>> DateOfChange
>> >>>
>> >>> Help is appreciated.
>> >>>
>> >>> Hannes
>> >>
>> >> Check #timeStampFor:class:reverseOrdinal: and in general
>> >> #annotationForSelector:ofClass:
>> >>
>> >> Cheers,
>> >> Juan Vuletich
>> >>
>> >
>> _______________________________________________
>> 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 Ken.Dickey at whidbey.com  Mon Jul 20 08:55:45 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 20 Jul 2015 06:55:45 -0700
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437352771.6934.219.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
Message-ID: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>

On Sun, 19 Jul 2015 20:39:31 -0400
"Phil (list)" <pbpublist at gmail.com> wrote:

> The issue is what constitutes a major change?  If your code uses it it's
> major, if mine uses it it's minor?  Coin toss?  Without a public API
> what is considered major is either obvious (i.e. Morphic changes from
> global to local coords or changing the File/Directory API so obviously
> everything using them breaks) or arbitrary (sorry to hear that you
> depended on that... but it wasn't major, now it's gone)  If the image
> snapshot is considered the public API, then everything must be both
> considered fair game to depend on and to change in the future which is
> unmanageable.

I don't think this is the issue at all. 

The text editor comes up in every release with goals for Cuis.  Backward compatibility is a stated non-goal.

I am happy to baseline my packages a couple of times a year against a baseline core release and maintain such matched baseline package releases.

I trust Juan's leadership and judgment. His time is a scarce and valuable resource.  He is very responsive to the Cuis community, including requests for backward compatibility and additional support.  I do _not_ want to slow him down.

If you have specific requirements, a package with Feature/Unit-tests is a good way to express this.

> I'm not trying to restrict Juan in any way from making the changes he
> thinks are important for Cuis.  His taste and direction have been
> generally excellent and the reason I'm here!  If for example, he decides
> that #drawOn: is no longer the way to do things or that even Morph
> needed to go away, that's fine as long as what's going on gets
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.

Pardon me, but this sounds exactly like you are trying to restrict certain changes.

It seems that you are trying to "plan" and "rule set" rather than "discover quickly".

My experience is that quick discovery (like writing unit tests and running them very frequently) is the fastest development path.

My guess is that major packages which prove useful will either migrate into the core packages or will be tested against as part of a larger release process.  I just prefer that process to be as small and painless (low drag) as possible.

If some package is not in wide use, the author can test against releases as often as he/she feels it necessary.  We can deal with breakage as it arises rather than planning search strategies for avoiding breakage.  For me, this is much more efficient.

Having API test suites is a good way to communicate importance.


As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful.  I heard that the Arabic word for "miracle" literally translates to "breaking the habit".  Interesting thought.

In the limit, we may be "agreeing loudly" here.  Easy to sound strident in an email.  Not the intent.


What is the simplest thing that will work?
-KenD



From hannes.hirzel at gmail.com  Mon Jul 20 12:26:42 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 17:26:42 +0000
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
Message-ID: <CAGQxfVisvidGE440ZhSTcC=RHjcU2Ega4_uUwh_j-QpdosRFNw@mail.gmail.com>

On 7/20/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Sun, 19 Jul 2015 20:39:31 -0400
> "Phil (list)" <pbpublist at gmail.com> wrote:
>
>> The issue is what constitutes a major change?  If your code uses it it's
>> major, if mine uses it it's minor?  Coin toss?  Without a public API
>> what is considered major is either obvious (i.e. Morphic changes from
>> global to local coords or changing the File/Directory API so obviously
>> everything using them breaks) or arbitrary (sorry to hear that you
>> depended on that... but it wasn't major, now it's gone)  If the image
>> snapshot is considered the public API, then everything must be both
>> considered fair game to depend on and to change in the future which is
>> unmanageable.
>
> I don't think this is the issue at all.
>
> The text editor comes up in every release with goals for Cuis.  Backward
> compatibility is a stated non-goal.
>
> I am happy to baseline my packages a couple of times a year against a
> baseline core release and maintain such matched baseline package releases.

+1

> I trust Juan's leadership and judgment. His time is a scarce and valuable
> resource.  He is very responsive to the Cuis community, including requests
> for backward compatibility and additional support.  I do _not_ want to slow
> him down.


+1

> If you have specific requirements, a package with Feature/Unit-tests is a
> good way to express this.


+1

>> I'm not trying to restrict Juan in any way from making the changes he
>> thinks are important for Cuis.  His taste and direction have been
>> generally excellent and the reason I'm here!  If for example, he decides
>> that #drawOn: is no longer the way to do things or that even Morph
>> needed to go away, that's fine as long as what's going on gets
>> communicated.


+1

However, a problem I think he faces right now is that he
>> doesn't know who's using / depending on what.
>
> Pardon me, but this sounds exactly like you are trying to restrict certain
> changes.
>
> It seems that you are trying to "plan" and "rule set" rather than "discover
> quickly".
>
> My experience is that quick discovery (like writing unit tests and running
> them very frequently) is the fastest development path.
>
> My guess is that major packages which prove useful will either migrate into
> the core packages or will be tested against as part of a larger release
> process.  I just prefer that process to be as small and painless (low drag)
> as possible.
>
> If some package is not in wide use, the author can test against releases as
> often as he/she feels it necessary.  We can deal with breakage as it arises
> rather than planning search strategies for avoiding breakage.  For me, this
> is much more efficient.
>
> Having API test suites is a good way to communicate importance.

+1

>
> As an aside, I have found some breakage to be very enlightening and
> (sometimes painfully) helpful.  I heard that the Arabic word for "miracle"
> literally translates to "breaking the habit".  Interesting thought.
>
> In the limit, we may be "agreeing loudly" here.  Easy to sound strident in
> an email.  Not the intent.
>
>
> What is the simplest thing that will work?
> -KenD


Probably the easiest is that Juan goes on as he is used to and a
release manager or release team forks off a release / baseline from
time to time.

This allows for documenting an artifact which is no longer moving.
Selected updates might be applied to the release until the next release is due.

The documentation will got later on merged into the main branch as well.

Hannes



From peter at aba-instituut.nl  Mon Jul 20 16:32:46 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Mon, 20 Jul 2015 23:32:46 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
Message-ID: <CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>

On Mon, Jul 20, 2015 at 3:55 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

>
> If you have specific requirements, a package with Feature/Unit-tests is a
> good way to express this.
>

I was thinking: "What should a Feature Test be?". I tried to look up what
others have written, but found nothing useful (I probably did not look hard
enough). Now, I don't mind thinking of something new, so here goes:

1. Clearly (to me), it should not be a kind of Unit Test. When you run a
unit test, you assume that the unit under test is present in the system and
you are trying to ascertain if it does certain things you expect. For this,
unit tests have built-in facilities to detect execution errors and failed
expectations, If such problems happen, unit tests are able to continue the
testing process and report on the problems that occurred after the tests
are run (this is the step forward that SUnit - or TSTTestingFramework as it
ws known at the time - brought).

2. On the other hand, when you run a Feature Test, you may be testing one
or more units, and one or more (or all) of those might not even be present.
Therefore, a feature test should be able to run even if in the absence of
the unit(s) supposed to implement the feature. So then, perhaps what a
class FeatureTest should offer its subclasses, is a #run: aString method
that tries to compile aString and if it compiles, execute it and look for
any foreseen side effects and/or expression value.

a test method might then look like:

testApiReceiverIsPresentAndCanBeSetUp

self run: 'ApiReceiver version > ''1.1.4''' expectEvaluationResult: true
.
self run: 'ApiReceiver setUp'
.
self expectSideEffect: 'ExpectedApiReceiver isSetUp'

3. Then it should be able to report that everything went well, or that
there was a problem compiling (ideally with detailed info such as 'global
Xxx was expected but was not present in the system'. If compiling went
well, the execution should be protected and monitored similarly to unit
tests that are already able to catch exceptions during execution.

4. Perhaps something along these lines would be the simplest thing that
could possibly work?

Would it help anyone if they had the FeatureTest class that they could
subclass and as a result they could always, safely, test if some feature
was present and did what you needed/expected of it? And you could have a
Feature Test Runner that ran your feature test, made sure nothing crashed,
and reported the results in a useful fashion.

Just some thoughts, cheers, Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/9cfb5cc4/attachment-0002.html>

From d.a.tennant.2009 at gmail.com  Mon Jul 20 17:18:13 2015
From: d.a.tennant.2009 at gmail.com (David Tennant)
Date: Mon, 20 Jul 2015 16:18:13 -0600
Subject: [Cuis] Embedding morphs at specific points in a morph?
Message-ID: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>

Hi everyone.
I have been playing arrowed with cuis for a couple of years, but I am
extremely horrible at it. Every time I attempt to code a program I don't
get too far, but this time I want to actually make a program that works. So
I am trying to make a program that you can play mancala with. Mancala is an
abstract board game.
I decided that I should build the board first. the board should look
something like this
http://ecx.images-amazon.com/images/I/51PD0CemQkL._SY300_.jpg . I wanted
the circles and ovals to be separate classes so that I have more
flexibility later. I have 3 classes: Board, BigEllipse, and CircleEllipse.
In BigEllipse and CircleEllipse I just have initialization stuff, like size
and color. in Board I have the initialization stuff too, but I also have
what I thought would create the board, but It does not work. there are two
methods, one I called "addMyEllipse" and th other I called
"addScoreEllipse". these are the methods

addMyEllipse
|n|

    myEllipse:= CircleEllipse new.
        n:=1.
        (1to:12) do:[
            (n<7)
            ifTrue: [self addMorph: (myEllipse at: 35@(35+(60*n)))]
            ifFalse: [self addMorph: (myEllipse at: 110@(35+(60*n)))].
            n:= (n+1).
        ].
note: myEllipse is an instance variable.

addScoreEllipse
| n|

    scoreEllipse:= BigEllipse new.
    n:=1.
    (1to:2) do:[
        (n=1)
        ifTrue:[self addMorph:(scoreEllipse at: 72.5 at 35)]
        ifFalse:[self addMorph:(scoreEllipse at: 72.5 at 455)].
        n=(n+1).
    ].
note: scoreEllipse is an instance variable.

I don't actually know what is wrong. when I type in the workspace: Board
new openInWorld. I just get the background of the board, no ellipses. and
when I type in the workspace: test:= Board new openInWorld. test
addMyEllipse. I get an error that says, this block accepts 0 arguments, but
was called with 1 argument.

Thank you for your time
-- 
David Tennant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/1108b143/attachment-0002.html>

From juan at jvuletich.org  Mon Jul 20 17:33:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 19:33:27 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AC4B3F.19938.1F92268@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>,
	<55ABA6A2.5090607@jvuletich.org>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
Message-ID: <55AD7737.30003@jvuletich.org>

Hi Dan,

On 7/19/2015 10:13 PM, Dan Norton wrote:
> On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>
> > On 7/18/2015 3:37 PM, Dan Norton wrote:
> > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
> > >
> > >> Hi Folks,
> > >>
> > >> It is not too hard to build new StrikeFonts. You need to build,
> > by
> > >> hand,
> > >> files like the ones in here:
> > >>
> > https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> > >> p
> > >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
> > with
> > >> this method and the files in this zip that built the existing
> > >> instances
> > >> of StrikeFont. Not sure.
> > >>
> > > That's intrigueing but I can't reproduce it. Maybe the .bmp but
> > where did you get the .txt?
> > >
> > >   - Dan
> >
> > I wrote them with a text editor. Check #installDejaVu2 and really
> > try to
> > understand how StrikeFonts work and how they are built with this
> > method.
> > Maybe you'll become enlightened.
> >
>
> A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name, 
> and several scalars. StrikeFont class methods create fonts by 
> processing file pairs assumed to be in the "AAFonts" subdirectory. For 
> example:
>
> DejaVu Sans Oblique 14.bmp
> DejaVu Sans Oblique 14.txt
>
> Is one such pair providing the italic (oblique) style for 14-point 
> size. There is a pair for every font size and style: base, bold, 
> italic, and bold italic. Therefore a font such as "DejaVu Sans" which 
> is available in the size interval 5 to 24 requires 160 files. The file 
> names are stylized and encoded in the StrikeFont class methods.
>
> Glyphs come from the .bmp file. The .txt file is a string of numbers; 
> the first three specify pointSize, ascent, and descent. The rest of 
> the numbers in the .txt file are used to form the xTable, which is the 
> index into the glyphs for a character. The characterToGlyphMap is an 
> array of 256 entries which map a character's ascii value to the xTable 
> and thence to the glyphs.
>
> The bold, italic, and bold italic styles are stashed as derivatives of 
> the base and not selectable from the current menus.
>
> StrikeFont is a subclass of AbstractFont, which has class variables 
> AvailableFonts and DefaultFont.
>
> If it can't find a file, StrikeFont will loop.

Great! You got it all.

> In regard to creating the .bmp and .txt files, you say, " I wrote them 
> with a text editor." Please tell me which text editor you used. None 
> of mine do that.

The bmp files can be created with screen capture program, after entering 
suitable text in it. Maybe you need to stitch several pieces together, 
etc. WRT the txt files, well, the editor didn't do it for me. I wrote 
them. I _typed_ them. Maybe I used some (long lost) code to look for 
white columns separating glyphs, but I'm not really sure. 
#xTallyPixelValue:orNot: and friends are great for this kind of stuff.

In any case, it will be easier for you, as you want a monospaced font. 
Printing something like (32 to: 255) collect: [ :ascii | ascii-32 * 9 ] 
into the file might be enough.

You have all the pieces at hand. it just requires a bit of patience.

Cheers,
Juan Vuletich

>  - Dan
>

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

From hannes.hirzel at gmail.com  Mon Jul 20 18:33:31 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 23:33:31 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AD7737.30003@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
	<55ABA6A2.5090607@jvuletich.org>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
	<55AD7737.30003@jvuletich.org>
Message-ID: <CAGQxfViL7p7GieO3zwYRQpboqeMnfiiQdATeok1rZTeGmrCijw@mail.gmail.com>

https://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format

The Glyph Bitmap Distribution Format (BDF) by Adobe is a file format
for storing bitmap fonts. The content takes the form of a text file
intended to be human- and computer-readable. BDF is typically used in
Unix X Window environments.

Squeak contains a BDFFontReader

<class comment>
I am a conversion utility for reading X11 Bitmap Distribution Format
fonts.  My code is derived from the multilingual Squeak changeset
written by OHSHIMA Yoshiki (ohshima at is.titech.ac.jp), although all
support for fonts with more than 256 glyphs has been ripped out.  See
http://www.is.titech.ac.jp/~ohshima/squeak/squeak-multilingual-e.html
.

My class methods contain tools for fetching BDF source files from a
well-known archive site, batch conversion to Squeak's .sf2 format, and
installation of these fonts as TextStyles.  Also, the legal notices
for the standard 75dpi fonts I process this way are included as
"x11FontLegalNotices'.
</class comment>

The URL no longer works, but the Squeak wiki

http://wiki.squeak.org/squeak/696

has more on fonts.

I have loaded BDF fonts into Squeak in the past and I assume the
Squeak StrikeFonts and the Cuis StrikeFonts are still compatible.

--Hannes

On 7/20/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Dan,
>
> On 7/19/2015 10:13 PM, Dan Norton wrote:
>> On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>>
>> > On 7/18/2015 3:37 PM, Dan Norton wrote:
>> > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>> > >
>> > >> Hi Folks,
>> > >>
>> > >> It is not too hard to build new StrikeFonts. You need to build,
>> > by
>> > >> hand,
>> > >> files like the ones in here:
>> > >>
>> > https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> > >> p
>> > >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
>> > with
>> > >> this method and the files in this zip that built the existing
>> > >> instances
>> > >> of StrikeFont. Not sure.
>> > >>
>> > > That's intrigueing but I can't reproduce it. Maybe the .bmp but
>> > where did you get the .txt?
>> > >
>> > >   - Dan
>> >
>> > I wrote them with a text editor. Check #installDejaVu2 and really
>> > try to
>> > understand how StrikeFonts work and how they are built with this
>> > method.
>> > Maybe you'll become enlightened.
>> >
>>
>> A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name,
>> and several scalars. StrikeFont class methods create fonts by
>> processing file pairs assumed to be in the "AAFonts" subdirectory. For
>> example:
>>
>> DejaVu Sans Oblique 14.bmp
>> DejaVu Sans Oblique 14.txt
>>
>> Is one such pair providing the italic (oblique) style for 14-point
>> size. There is a pair for every font size and style: base, bold,
>> italic, and bold italic. Therefore a font such as "DejaVu Sans" which
>> is available in the size interval 5 to 24 requires 160 files. The file
>> names are stylized and encoded in the StrikeFont class methods.
>>
>> Glyphs come from the .bmp file. The .txt file is a string of numbers;
>> the first three specify pointSize, ascent, and descent. The rest of
>> the numbers in the .txt file are used to form the xTable, which is the
>> index into the glyphs for a character. The characterToGlyphMap is an
>> array of 256 entries which map a character's ascii value to the xTable
>> and thence to the glyphs.
>>
>> The bold, italic, and bold italic styles are stashed as derivatives of
>> the base and not selectable from the current menus.
>>
>> StrikeFont is a subclass of AbstractFont, which has class variables
>> AvailableFonts and DefaultFont.
>>
>> If it can't find a file, StrikeFont will loop.
>
> Great! You got it all.
>
>> In regard to creating the .bmp and .txt files, you say, " I wrote them
>> with a text editor." Please tell me which text editor you used. None
>> of mine do that.
>
> The bmp files can be created with screen capture program, after entering
> suitable text in it. Maybe you need to stitch several pieces together,
> etc. WRT the txt files, well, the editor didn't do it for me. I wrote
> them. I _typed_ them. Maybe I used some (long lost) code to look for
> white columns separating glyphs, but I'm not really sure.
> #xTallyPixelValue:orNot: and friends are great for this kind of stuff.
>
> In any case, it will be easier for you, as you want a monospaced font.
> Printing something like (32 to: 255) collect: [ :ascii | ascii-32 * 9 ]
> into the file might be enough.
>
> You have all the pieces at hand. it just requires a bit of patience.
>
> Cheers,
> Juan Vuletich
>
>>  - Dan
>>
>
>



From dnorton at mindspring.com  Mon Jul 20 18:55:38 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 19:55:38 -0400
Subject: [Cuis] Embedding morphs at specific points in a morph?
In-Reply-To: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
References: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
Message-ID: <55AD8A7A.26397.2436C64@dnorton.mindspring.com>

On 20 Jul 2015 at 16:18, David Tennant wrote:

> 
> Hi everyone.
> I have been playing arrowed with cuis for a couple of years, but I
> am extremely horrible at it. Every 
> time I attempt to code a program I don't get too far, but this time
> I want to actually make a 
> program that works. So I am trying to make a program that you can
> play mancala with. Mancala is 
> an abstract board game.
> I decided that I should build the board first. the board should look
> something like this 
> http://ecx.images-amazon.com/images/I/51PD0CemQkL._SY300_.jpg . I
> wanted the circles and 
> ovals to be separate classes so that I have more flexibility later.
> I have 3 classes: Board, 
> BigEllipse, and CircleEllipse. In BigEllipse and CircleEllipse I
> just have initialization stuff, like size 
> and color. in Board I have the initialization stuff too, but I also
> have what I thought would create 
> the board, but It does not work. there are two methods, one I called
> "addMyEllipse" and th other I 
> called "addScoreEllipse". these are the methods
> ?
> addMyEllipse
> |n|
> 
> ??? myEllipse:= CircleEllipse new.
> ??? ??? n:=1.
> ??? ??? (1to:12) do:[
> ??? ??? ??? (n<7)
> ??? ??? ??? ifTrue: [self addMorph: (myEllipse at:
> 35@(35+(60*n)))]
> ??? ??? ??? ifFalse: [self addMorph: (myEllipse at:
> 110@(35+(60*n)))].
> ??? ??? ??? n:= (n+1).
> ??? ??? ].
> note: myEllipse is an instance variable.
> 
> addScoreEllipse
> | n|
> 
> ??? scoreEllipse:= BigEllipse new.
> ??? n:=1.
> ??? (1to:2) do:[
> ??? ??? (n=1)
> ??? ??? ifTrue:[self addMorph:(scoreEllipse at: 72.5 at 35)]
> ??? ??? ifFalse:[self addMorph:(scoreEllipse at: 72.5 at 455)].
> ??? ??? n=(n+1).
> ??? ].
> note: scoreEllipse is an instance variable.
> 
> I don't actually know what is wrong. when I type in the workspace:
> Board new openInWorld. I just 
> get the background of the board, no ellipses. and when I type in the
> workspace: test:= Board new 
> openInWorld. test addMyEllipse. I get an error that says, this block
> accepts 0 arguments, but was 
> called with 1 argument.
> 
>
I had the same problem recently in some code that looked like this:

ifExistsDo: [{italicName. ' OK'} print]

The cure was to "expect" an argument, even tho it would not be used:

ifExistsDo: [:x | {italicName. ' OK'} print]

Thanks to Phil for staightening me out.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/6f694e3a/attachment-0002.html>

From dnorton at mindspring.com  Mon Jul 20 19:32:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 20:32:56 -0400
Subject: [Cuis] Terse Guide to Pen, Forms
Message-ID: <55AD9338.29402.26592D8@dnorton.mindspring.com>

Hello,

The Pen and Forms topics in Terse Guide no longer work. For example:

| x y |
x := Form dotOfSize: 20.	"Make a form containing a dot (as yet unseen)."
x displayAt: 500 at 200.		"Cause the form to appear at a point on the display."
Display restore.			"Erase what was displayed."

#displayAt: doesn't.

Similar problems with "Display fillWhite" in the Pen topic.

 - Dan



From juan at jvuletich.org  Mon Jul 20 20:07:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:07:01 -0300
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVjzR=pG2i4+RakCiNZKJ6EMTJGkXu5sX2OAdiMCjS24GQ@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>	<55A90799.7080302@jvuletich.org>	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>	<CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>	<1437354098.6934.240.camel@gmail.com>
	<CAGQxfVjzR=pG2i4+RakCiNZKJ6EMTJGkXu5sX2OAdiMCjS24GQ@mail.gmail.com>
Message-ID: <55AD9B35.5010805@jvuletich.org>

Hi Hannes,

On 7/20/2015 9:55 AM, H. Hirzel wrote:
> Yes,
>
> an image diff to see what classes/methods changed between timer period X and Y
>
> is what I am looking for.
>
> --Hannes

That is easy.

In the newer image, evaluate: SystemOrganization fileOutAllCategories.

Now start the older image. (you might need to file in the attach if you 
get a walkback) Open a File list. Click on the *AllCode.st file 
generated in the newer image. Click on [contents]. Select "No".

Right click on the change list. 'remove up-to-date versions'.

"Right click again. Select methods equivalent to current". "Remove 
selected items".

You can study them right there. Or you can "select all" "file out 
selections". Then select this file in the file list and click on [code] 
and use this view instead. In any of these ways, it is reasonable easy 
to see how much changed, and check each change if desired.

Or you can come up with your own new and creative ways to use the tools 
in the system :)

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2425-privateReadSelector-fix-JuanVuletich-2015Jul20-19h44m-jmv.1.cs.zip
Type: application/zip
Size: 662 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/0304b3af/attachment-0002.zip>

From juan at jvuletich.org  Mon Jul 20 20:21:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:21:34 -0300
Subject: [Cuis] Terse Guide to Pen, Forms
In-Reply-To: <55AD9338.29402.26592D8@dnorton.mindspring.com>
References: <55AD9338.29402.26592D8@dnorton.mindspring.com>
Message-ID: <55AD9E9E.7020407@jvuletich.org>

Hi Dan,

This is a bug I introduced when speeding up Transcript maybe a month 
ago. I'll fix it soon (max 2 days).

Thanks for reporting.

Cheers,
Juan Vuletich

On 7/20/2015 9:32 PM, Dan Norton wrote:
> Hello,
>
> The Pen and Forms topics in Terse Guide no longer work. For example:
>
> | x y |
> x := Form dotOfSize: 20.	"Make a form containing a dot (as yet unseen)."
> x displayAt: 500 at 200.		"Cause the form to appear at a point on the display."
> Display restore.			"Erase what was displayed."
>
> #displayAt: doesn't.
>
> Similar problems with "Display fillWhite" in the Pen topic.
>
>   - Dan
>




From juan at jvuletich.org  Mon Jul 20 20:28:44 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:28:44 -0300
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <559AA0A2.13962.3B4CD8@dnorton.mindspring.com>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>,
	<559A83A3.5040406@jvuletich.org>
	<559AA0A2.13962.3B4CD8@dnorton.mindspring.com>
Message-ID: <55ADA04C.8070100@jvuletich.org>

On 7/6/2015 12:37 PM, Dan Norton wrote:
> On 6 Jul 2015 at 10:33, Juan Vuletich wrote:
>
>> Hi Dan,
>>
>> On 7/5/2015 8:35 PM, Dan Norton wrote:
>>> Greetings,
>>>
>>> Four LayoutSpec class methods use "minorDirectionPadding:" as a
>> keyword. The parameter
>>> can be a number or one of: #top, #left, #center, #right, or
>> #bottom. AFAICT when the
>>> parameter is a number, it refers to the padding which will be
>> applied in the minor direction.
>>> When it is a symbol, it effectively specifies that morphs will be
>> located as the symbol name
>>> implies.
>>>
>>> Attached are four convenience methods whose keyword emphasizes the
>> visible (morph)
>>> instead of the invisible (padding). The "morphPlacement:"
>> parameter can be  #top, #left,
>>> #center, #right, or #bottom. The methods are:
>>>
>>> LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
>>> LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
>>> LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
>>> LayoutSpec
>> class>>proportionalWidth:proportionalHeight:morphPlacement:
>>> Are these worth having in the base system?
>>>
>>>    - Dan
>>>
>> I'd rather replace the keyword 'minorDirectionPadding:' by
>> 'minorDirectionPlacement:' to:
>> - Avoid ambiguity
>> - Avoid duplication
>>
> OK, as far as the duplication, but I don't see "morphPlacement:" in use. Where does the
> ambiguity occur?
>
>   - Dan

The ambiguity in 'morphPlacement' is that it suggest it is about x and y 
placement. It is only for the 'minor' direction: x if a column, y if a 
row. Major direction placement is dictated by the other arguments, and 
siblings, etc.

Does this make sense?

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Mon Jul 20 20:34:16 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 21:34:16 -0400
Subject: [Cuis] Embedding morphs at specific points in a morph?
In-Reply-To: <55AD8A7A.26397.2436C64@dnorton.mindspring.com>
References: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
	<55AD8A7A.26397.2436C64@dnorton.mindspring.com>
Message-ID: <1437442456.2300.57.camel@gmail.com>

Welcome David!

On Mon, 2015-07-20 at 19:55 -0400, Dan Norton wrote:
> On 20 Jul 2015 at 16:18, David Tennant wrote:
> 
> 
> > 
> > Hi everyone.
> > I have been playing arrowed with cuis for a couple of years, but I
> > am extremely horrible at it. Every 
> > time I attempt to code a program I don't get too far, but this time
> > I want to actually make a 
> > program that works. So I am trying to make a program that you can
> > play mancala with. Mancala is 
> > an abstract board game.
> > I decided that I should build the board first. the board should look
> > something like this 
> > http://ecx.images-amazon.com/images/I/51PD0CemQkL._SY300_.jpg . I
> > wanted the circles and 
> > ovals to be separate classes so that I have more flexibility later.
> > I have 3 classes: Board, 
> > BigEllipse, and CircleEllipse. In BigEllipse and CircleEllipse I
> > just have initialization stuff, like size 
> > and color. in Board I have the initialization stuff too, but I also
> > have what I thought would create 
> > the board, but It does not work. there are two methods, one I called
> > "addMyEllipse" and th other I 
> > called "addScoreEllipse". these are the methods
> >  
> > addMyEllipse
> > |n|
> > 
> >     myEllipse:= CircleEllipse new.
> >         n:=1.
> >         (1to:12) do:[
> >             (n<7)
> >             ifTrue: [self addMorph: (myEllipse at:
> > 35@(35+(60*n)))]
> >             ifFalse: [self addMorph: (myEllipse at:
> > 110@(35+(60*n)))].
> >             n:= (n+1).
> >         ].
> > note: myEllipse is an instance variable.
> > 
> > addScoreEllipse
> > | n|
> > 
> >     scoreEllipse:= BigEllipse new.
> >     n:=1.
> >     (1to:2) do:[
> >         (n=1)
> >         ifTrue:[self addMorph:(scoreEllipse at: 72.5 at 35)]
> >         ifFalse:[self addMorph:(scoreEllipse at: 72.5 at 455)].
> >         n=(n+1).
> >     ].
> > note: scoreEllipse is an instance variable.
> > 
> > I don't actually know what is wrong. when I type in the workspace:
> > Board new openInWorld. I just 
> > get the background of the board, no ellipses. and when I type in the
> > workspace: test:= Board new 
> > openInWorld. test addMyEllipse. I get an error that says, this block
> > accepts 0 arguments, but was 
> > called with 1 argument.
> > 
> >
> I had the same problem recently in some code that looked like this:
> 
> 
> ifExistsDo: [{italicName. ' OK'} print]
> 
> 
> The cure was to "expect" an argument, even tho it would not be used:
> 
> 
> ifExistsDo: [:x | {italicName. ' OK'} print]
> 
Dan has it exactly right. The (1 to: 12) do: is trying to pass your
block the current value which *is* your n so you should get rid of the
outer n declaration and change the block to accept the parameter like
this:

(1 to: 12) do: [:n| Transcript show: n asString]

Just replace the Transcript statement with your code and you should be
good to go...

> 
> Thanks to Phil for staightening me out.
> 

Glad I could help... while the debugger is always precise as to what is
wrong, it isn't always clear :-)
> 
>  - Dan
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Mon Jul 20 20:34:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:34:43 -0300
Subject: [Cuis] #printStringLimitedTo:
In-Reply-To: <CAGQxfVi0Sjj8YNfYBxDKwa4sqWHJnAbApWfgHOOHdUy72nZYPA@mail.gmail.com>
References: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>	<1437285899.6934.1.camel@gmail.com>
	<CAGQxfVi0Sjj8YNfYBxDKwa4sqWHJnAbApWfgHOOHdUy72nZYPA@mail.gmail.com>
Message-ID: <55ADA1B3.7060504@jvuletich.org>

Why not? I just did the .cs. If nobody objects, Ken' s suggestion will 
be in the next commit.

Cheers,
Juan Vuletich

On 7/20/2015 9:41 AM, H. Hirzel wrote:
> Ken you ask about other options
>
> one would be to have a method
>
>
> #printStringLimitedTo:suffix:
>
> so that people can have their own suffix.
>
> Might be better in a multilingual environment.
>
> However  '...etc...' is pretty general.
>
> No objection if it stays as is.
>
> --HH
>
> On 7/19/15, Phil (list)<pbpublist at gmail.com>  wrote:
>> On Sat, 2015-07-18 at 21:33 -0700, Ken.Dickey wrote:
>>> I find it kind of odd that #printStringLimitedTo: takes the prefix of a
>>> too-long string and adds '...etc...', which itself is 9 characters.
>>>
>>> I think a shorter addition would make more sense.  After all, the string
>>> is already too long, right?
>>>
>>> I like '[..]' , which is only four characters.
>>>
>>> Would anyone else like to weigh in on this?  Other options?
>> I agree that the current suffix is long-ish and like your [..] idea as
>> that's unlikely to appear in the majority of strings but would still
>> convey the information.
>>
>>> -KenD
>>>
>>> _______________________________________________
>>> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Mon Jul 20 20:36:10 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:36:10 -0300
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
Message-ID: <55ADA20A.2070105@jvuletich.org>

On 7/19/2015 6:01 PM, H. Hirzel wrote:
> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
> ....
>   I
>> recently changed the scoping rules for shared variables (I think they're
>> done wrong in the base image). I could change what I wanted easily. So I
>> think I am not in some outsider author group. Instead I am happy that I
>> could change what I wanted without needing anyone's approval or
>> cooperation.

Great!

> A note:
> This applies to any version / distribution of Smalltalk. But it means
> that you have your own version of the core system.
>
> Could you elaborate on the issue of the shared variables, maybe it is
> something to include in the core Cuis image?
>
> --Hannes

Agree. It would be nice to know.

Cheers,
Juan Vuletich



From Ken.Dickey at whidbey.com  Mon Jul 20 20:44:43 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 20 Jul 2015 18:44:43 -0700
Subject: [Cuis] Embedding morphs at specific points in a morph?
In-Reply-To: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
References: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
Message-ID: <20150720184443.e17db364fc884fd11ac09d87@whidbey.com>

On Mon, 20 Jul 2015 16:18:13 -0600
David Tennant <d.a.tennant.2009 at gmail.com> wrote:

> myEllipse:= CircleEllipse new.
>         n:=1.
>         (1to:12) do:[
>             (n<7)
>             ifTrue: [self addMorph: (myEllipse at: 35@(35+(60*n)))]
>             ifFalse: [self addMorph: (myEllipse at: 110@(35+(60*n)))].
>             n:= (n+1).
>         ].

I don't know what "CircleEllipse new" does (e.g. is the radius zero?), but I would note that you are adding the same morph at different positions.

I suspect each position would like its own morph.

-- 
-KenD



From dnorton at mindspring.com  Mon Jul 20 20:58:43 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 21:58:43 -0400
Subject: [Cuis] Terse Guide to Pen, Forms
In-Reply-To: <55AD9E9E.7020407@jvuletich.org>
References: <55AD9338.29402.26592D8@dnorton.mindspring.com>,
	<55AD9E9E.7020407@jvuletich.org>
Message-ID: <55ADA753.26544.2B41A22@dnorton.mindspring.com>

Great! The transcript speed is impressive, BTW.

 - Dan

On 20 Jul 2015 at 22:21, Juan Vuletich wrote:

> Hi Dan,
> 
> This is a bug I introduced when speeding up Transcript maybe a month
> ago. I'll fix it soon (max 2 days).
> 
> Thanks for reporting.
> 
> Cheers,
> Juan Vuletich
> 
> On 7/20/2015 9:32 PM, Dan Norton wrote:
> > Hello,
> >
> > The Pen and Forms topics in Terse Guide no longer work. For
> example:
> >
> > | x y |
> > x := Form dotOfSize: 20.	"Make a form containing a dot (as yet
> unseen)."
> > x displayAt: 500 at 200.		"Cause the form to appear at a point on the
> display."
> > Display restore.			"Erase what was displayed."
> >
> > #displayAt: doesn't.
> >
> > Similar problems with "Display fillWhite" in the Pen topic.
> >
> >   - Dan
> >
> 





From pbpublist at gmail.com  Mon Jul 20 20:58:55 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 21:58:55 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
Message-ID: <1437443935.2300.77.camel@gmail.com>

On Mon, 2015-07-20 at 06:55 -0700, Ken.Dickey wrote:
> On Sun, 19 Jul 2015 20:39:31 -0400
> "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > The issue is what constitutes a major change?  If your code uses it it's
> > major, if mine uses it it's minor?  Coin toss?  Without a public API
> > what is considered major is either obvious (i.e. Morphic changes from
> > global to local coords or changing the File/Directory API so obviously
> > everything using them breaks) or arbitrary (sorry to hear that you
> > depended on that... but it wasn't major, now it's gone)  If the image
> > snapshot is considered the public API, then everything must be both
> > considered fair game to depend on and to change in the future which is
> > unmanageable.
> 
> I don't think this is the issue at all. 
> 
> The text editor comes up in every release with goals for Cuis.  Backward compatibility is a stated non-goal.
> 

The first issue (text editor working in every release) is the difference
between reliability and stability, at least as I've been meaning in this
discussion.  Yes, it works in every release because it is part of what
is at least implicitly tested to a degree as part of nearly every build.
Cuis is very reliable in that within a given build things are generally
working better than they did in the previous build.

The backward compatibility non-goal seems like it should decrease as
Cuis matures. (not sure if this is a recent change or not, but it
actually does say that on the Cuis home page)  Once we hit a minimal
feature set, backwards incompatibility should largely go away as the
result of a combination of Cuis becoming the simplest thing that would
work and diminishing returns.  Perhaps we disagree on how close to that
point we are?  As Juan indicated, at some point the packages start to
play a larger role and at some point the same stability discussion
becomes an issue there as well.  (At least if the plan is to be able to
build larger and more complex things using Cuis in the future)

> I am happy to baseline my packages a couple of times a year against a baseline core release and maintain such matched baseline package releases.
> 

In theory what you're saying makes sense but in practice I didn't find
it worked.  I tried that back in the 2.x days and again in 4.x but found
the release notes just didn't have the detail to make this work for me.
I disliked the results enough that I'm currently trying to stay within a
build or two of Juan but that isn't realistic to expect most people to
do (I don't think so, at least) and if I ever fall behind in the current
model, I'm screwed...

> I trust Juan's leadership and judgment. His time is a scarce and valuable resource.  He is very responsive to the Cuis community, including requests for backward compatibility and additional support.  I do _not_ want to slow him down.
> 

I agree.  The question is how do we accomplish this.  My sense is that
we are starting to chew up more of his time peppering him with
questions / issues that he didn't anticipate resulting from recent
changes.  At the same time, for those who are not staying on the
bleeding edge, there is a level of frustration in that we're living in
an environment with very few constants and some of the changes have been
starting to hurt.

> If you have specific requirements, a package with Feature/Unit-tests is a good way to express this.
> 

I guess I see explicitly identified public methods and
feature/unit-tests as being complementary and helping lead to the same
place.

> > I'm not trying to restrict Juan in any way from making the changes he
> > thinks are important for Cuis.  His taste and direction have been
> > generally excellent and the reason I'm here!  If for example, he decides
> > that #drawOn: is no longer the way to do things or that even Morph
> > needed to go away, that's fine as long as what's going on gets
> > communicated.  However, a problem I think he faces right now is that he
> > doesn't know who's using / depending on what.
> 
> Pardon me, but this sounds exactly like you are trying to restrict certain changes.
> 

Poor choice of wording on my part, I probably should have said something
like 'prevent'.  Putting any sort of limits on when / how changes can be
made is a restriction.  But I'm not actually asking him to *not* make
the changes he thinks are necessary, but manage the when / how in some
cases.

> It seems that you are trying to "plan" and "rule set" rather than "discover quickly".
> 

I am asking him to plan a bit more *only* for a subset of things that we
agree need to be more stable than the rest.  I still believe that is <
20% of the unique method names.
  
> My experience is that quick discovery (like writing unit tests and running them very frequently) is the fastest development path.
> 
> My guess is that major packages which prove useful will either migrate into the core packages or will be tested against as part of a larger release process.  I just prefer that process to be as small and painless (low drag) as possible.
> 
> If some package is not in wide use, the author can test against releases as often as he/she feels it necessary.  We can deal with breakage as it arises rather than planning search strategies for avoiding breakage.  For me, this is much more efficient.

I don't think that most people will accept the compatibility through
continual testing/fixing over a long period of time... most will likely
give up after experiencing this for a while if they're attempting to use
Cuis as something more than a playground.

If the long term objective *isn't* for Cuis to be a platform, then an
acceptable answer would be 'you're using it wrong'.  Or Juan could
simply say 'yeah, ok... but I really don't want to do that...'

> 
> Having API test suites is a good way to communicate importance.
> 
> 
> As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful.  I heard that the Arabic word for "miracle" literally translates to "breaking the habit".  Interesting thought.
> 
> In the limit, we may be "agreeing loudly" here.  Easy to sound strident in an email.  Not the intent.
> 

I know you're generally pretty level headed and not looking to be
disagreeable.  I engaged in this discussion because it is an important
one to have and it felt like the right time to have it. A lot of what is
being proposed is a change from how things have historically been.  But
at the same time the pace of change has slowed down (ah, those whirlwind
1.x and 2.x days... :-) so it *seems* like trying to start to try to
stabilize things a bit has relatively little downside.  (Dunno... maybe
Juan is working on chucking the whole Magnitude hierarchy or something
major like that right now...)

> 
> What is the simplest thing that will work?
> -KenD





From dnorton at mindspring.com  Mon Jul 20 21:00:30 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 22:00:30 -0400
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <55ADA04C.8070100@jvuletich.org>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>,
	<559AA0A2.13962.3B4CD8@dnorton.mindspring.com>,
	<55ADA04C.8070100@jvuletich.org>
Message-ID: <55ADA7BE.20764.2B5BCE6@dnorton.mindspring.com>

On 20 Jul 2015 at 22:28, Juan Vuletich wrote:

> On 7/6/2015 12:37 PM, Dan Norton wrote:
> > On 6 Jul 2015 at 10:33, Juan Vuletich wrote:
> >
> >> Hi Dan,
> >>
> >> On 7/5/2015 8:35 PM, Dan Norton wrote:
> >>> Greetings,
> >>>
> >>> Four LayoutSpec class methods use "minorDirectionPadding:" as
> a
> >> keyword. The parameter
> >>> can be a number or one of: #top, #left, #center, #right, or
> >> #bottom. AFAICT when the
> >>> parameter is a number, it refers to the padding which will be
> >> applied in the minor direction.
> >>> When it is a symbol, it effectively specifies that morphs will
> be
> >> located as the symbol name
> >>> implies.
> >>>
> >>> Attached are four convenience methods whose keyword emphasizes
> the
> >> visible (morph)
> >>> instead of the invisible (padding). The "morphPlacement:"
> >> parameter can be  #top, #left,
> >>> #center, #right, or #bottom. The methods are:
> >>>
> >>> LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
> >>> LayoutSpec
> class>>fixedWidth:proportionalHeight:morphPlacement:
> >>> LayoutSpec
> class>>proportionalWidth:fixedHeight:morphPlacement:
> >>> LayoutSpec
> >> class>>proportionalWidth:proportionalHeight:morphPlacement:
> >>> Are these worth having in the base system?
> >>>
> >>>    - Dan
> >>>
> >> I'd rather replace the keyword 'minorDirectionPadding:' by
> >> 'minorDirectionPlacement:' to:
> >> - Avoid ambiguity
> >> - Avoid duplication
> >>
> > OK, as far as the duplication, but I don't see "morphPlacement:"
> in use. Where does the
> > ambiguity occur?
> >
> >   - Dan
> 
> The ambiguity in 'morphPlacement' is that it suggest it is about x
> and y 
> placement. It is only for the 'minor' direction: x if a column, y if
> a 
> row. Major direction placement is dictated by the other arguments,
> and 
> siblings, etc.
> 
> Does this make sense?
> 

+1

 - Dan



From hannes.hirzel at gmail.com  Tue Jul 21 02:12:34 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 21 Jul 2015 07:12:34 +0000
Subject: [Cuis] Terse Guide to Pen, Forms
In-Reply-To: <55ADA753.26544.2B41A22@dnorton.mindspring.com>
References: <55AD9338.29402.26592D8@dnorton.mindspring.com>
	<55AD9E9E.7020407@jvuletich.org>
	<55ADA753.26544.2B41A22@dnorton.mindspring.com>
Message-ID: <CAGQxfVhKjD-H3JKj7B8St6f0E-aYJrAMi0b87KHJjJHgcZBgSg@mail.gmail.com>

How would an additinonal test look like which covers this?

--Hannes



On 7/21/15, Dan Norton <dnorton at mindspring.com> wrote:
> Great! The transcript speed is impressive, BTW.
>
>  - Dan
>
> On 20 Jul 2015 at 22:21, Juan Vuletich wrote:
>
>> Hi Dan,
>>
>> This is a bug I introduced when speeding up Transcript maybe a month
>> ago. I'll fix it soon (max 2 days).
>>
>> Thanks for reporting.
>>
>> Cheers,
>> Juan Vuletich
>>
>> On 7/20/2015 9:32 PM, Dan Norton wrote:
>> > Hello,
>> >
>> > The Pen and Forms topics in Terse Guide no longer work. For
>> example:
>> >
>> > | x y |
>> > x := Form dotOfSize: 20.	"Make a form containing a dot (as yet
>> unseen)."
>> > x displayAt: 500 at 200.		"Cause the form to appear at a point on the
>> display."
>> > Display restore.			"Erase what was displayed."
>> >
>> > #displayAt: doesn't.
>> >
>> > Similar problems with "Display fillWhite" in the Pen topic.
>> >
>> >   - Dan
>> >
>>
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From peter at aba-instituut.nl  Tue Jul 21 14:13:15 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Tue, 21 Jul 2015 21:13:15 +0200
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <55ADA20A.2070105@jvuletich.org>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
	<55ADA20A.2070105@jvuletich.org>
Message-ID: <CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>

Hi Juan, Hannes,

since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW,
ST/X, VSE, IIRC) already do it as I want it to work
(Squeak does it "wrong" so perhaps it's not really a Smalltalk
implementation)

This is about the lookup logic when we see a name that is not a local name
(local to the block, method or object)

To resolve it (i.e., determine if it is a valid reference to a shared
variable), this is the order of searching for the name:

1 pool dictionaries declared in this class (from left to right I presume
but I don't care so I haven't paid attention)
2 classPool (i.e. the class variables defined in this class)
3 classPools in superclass chain
4 globals

The code in Squeak (and Cuis) does something recursive in the lookup logic
when it should not, which is probably based on an incorrect understanding
of the lookup rules. I have to admit that it is not easy to find how this
should be done, I have studied the Blue Book and ANSI-98 Smalltalk standard
(long long ago) and they were a bit fuzzy. But the logic all the other
dialects have also makes the most sense (to me) and works for some "clever"
stuff I do to make code 100% portable between dialects, so that's how I
like it to work.

Cheers, Peter

BTW Hannes, I'm not sure I would be able to change this in Dolphin, but in
the other dialects, probably. But like I said, there is no need, it is
Squeak (and Cuis) that's the odd one out.

On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org> wrote:

> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>
>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>> ....
>>   I
>>
>>> recently changed the scoping rules for shared variables (I think they're
>>> done wrong in the base image). I could change what I wanted easily. So I
>>> think I am not in some outsider author group. Instead I am happy that I
>>> could change what I wanted without needing anyone's approval or
>>> cooperation.
>>>
>>
> Great!
>
>  A note:
>> This applies to any version / distribution of Smalltalk. But it means
>> that you have your own version of the core system.
>>
>> Could you elaborate on the issue of the shared variables, maybe it is
>> something to include in the core Cuis image?
>>
>> --Hannes
>>
>
> Agree. It would be nice to know.
>
> 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/20150721/62be7266/attachment-0002.html>

From nicolas.cellier.aka.nice at gmail.com  Tue Jul 21 15:16:42 2015
From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier)
Date: Tue, 21 Jul 2015 22:16:42 +0200
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
	<55ADA20A.2070105@jvuletich.org>
	<CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>
Message-ID: <CAKnRiT68QBMbomVYVDyxpzfAM-g1rMBKZ+=RPp5nmdvb7DmqAA@mail.gmail.com>

2015-07-21 21:13 GMT+02:00 Peter van Rooijen <peter at aba-instituut.nl>:

> Hi Juan, Hannes,
>
> since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW,
> ST/X, VSE, IIRC) already do it as I want it to work
> (Squeak does it "wrong" so perhaps it's not really a Smalltalk
> implementation)
>
> This is about the lookup logic when we see a name that is not a local name
> (local to the block, method or object)
>
> To resolve it (i.e., determine if it is a valid reference to a shared
> variable), this is the order of searching for the name:
>
> 1 pool dictionaries declared in this class (from left to right I presume
> but I don't care so I haven't paid attention)
> 2 classPool (i.e. the class variables defined in this class)
> 3 classPools in superclass chain
> 4 globals
>
> The code in Squeak (and Cuis) does something recursive in the lookup logic
> when it should not, which is probably based on an incorrect understanding
> of the lookup rules. I have to admit that it is not easy to find how this
> should be done, I have studied the Blue Book and ANSI-98 Smalltalk standard
> (long long ago) and they were a bit fuzzy. But the logic all the other
> dialects have also makes the most sense (to me) and works for some "clever"
> stuff I do to make code 100% portable between dialects, so that's how I
> like it to work.
>
>
Ah, you probably mean that you would not want the superclass pool
dictionaries to be inherited, right?

Nicolas


> Cheers, Peter
>
> BTW Hannes, I'm not sure I would be able to change this in Dolphin, but in
> the other dialects, probably. But like I said, there is no need, it is
> Squeak (and Cuis) that's the odd one out.
>
> On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org> wrote:
>
>> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>>
>>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>>> ....
>>>   I
>>>
>>>> recently changed the scoping rules for shared variables (I think they're
>>>> done wrong in the base image). I could change what I wanted easily. So I
>>>> think I am not in some outsider author group. Instead I am happy that I
>>>> could change what I wanted without needing anyone's approval or
>>>> cooperation.
>>>>
>>>
>> Great!
>>
>>  A note:
>>> This applies to any version / distribution of Smalltalk. But it means
>>> that you have your own version of the core system.
>>>
>>> Could you elaborate on the issue of the shared variables, maybe it is
>>> something to include in the core Cuis image?
>>>
>>> --Hannes
>>>
>>
>> Agree. It would be nice to know.
>>
>> Cheers,
>> Juan Vuletich
>>
>> _______________________________________________
>> 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/20150721/c1c50cfa/attachment-0002.html>

From Ken.Dickey at whidbey.com  Tue Jul 21 17:33:00 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 21 Jul 2015 15:33:00 -0700
Subject: [Cuis] (Rescued) Re:  Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
Message-ID: <20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>

On Tue, 21 Jul 2015 07:59:47 -0700
Peter van Rooijen <peter at aba-instituut.nl> wrote:

>> I was thinking: "What should a Feature Test be?". 

I tend to think of a hierarchy of requirements.  Perhaps something like:

 Feature requireAll: #( <feature name>.. ).
 Classes requireAll: #( <class name>.. ). 
 Methods requireAll: #( <selector name>.. ).
 MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).         
 Tests requireAllPass: #( <unit test name> ).                 

The Feature class lets us require named (macro) Features with a version check.  I prefer that requirements at this level actually load the packages required and only report failure if that is not possible, although we could have a "preflight" verson which just checks without loading any featured packages.

API's are basically "protocols", which in the absence of symbolic execution means checking that classes and specific method selectors exist, or more specifically, method selectors are applicable to specific KindOf: classes.

Further, some Unit Tests may be required to pass to ensure compliance with some specification.

We should be able to automate at least some of this, including a first pass of generating the test sets, which could then be pruned by hand as required. 

$0.02,
-KenD



From peter at aba-instituut.nl  Wed Jul 22 05:41:47 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 22 Jul 2015 12:41:47 +0200
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <CAKnRiT68QBMbomVYVDyxpzfAM-g1rMBKZ+=RPp5nmdvb7DmqAA@mail.gmail.com>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
	<55ADA20A.2070105@jvuletich.org>
	<CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>
	<CAKnRiT68QBMbomVYVDyxpzfAM-g1rMBKZ+=RPp5nmdvb7DmqAA@mail.gmail.com>
Message-ID: <CAJBxtBb6ahfcNi7tAhJVZab5QfTG2cATrmyRBJjEEPwKc10fiA@mail.gmail.com>

Hi Nicolas,

On Tue, Jul 21, 2015 at 10:16 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:


> Ah, you probably mean that you would not want the superclass pool
> dictionaries to be inherited, right?
>

Indeed they should not be inherited. If the variables are relevant for the
whole hierarchy, the place to put them is in the classPool.

But there is a problem with the class variables by themselves too, although
I always forget what it is. If you really want to know I can look it up of
course.

Cheers, Peter





>
>
> Nicolas
>
>
>> Cheers, Peter
>>
>> BTW Hannes, I'm not sure I would be able to change this in Dolphin, but
>> in the other dialects, probably. But like I said, there is no need, it is
>> Squeak (and Cuis) that's the odd one out.
>>
>> On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org>
>> wrote:
>>
>>> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>>>
>>>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>>>> ....
>>>>   I
>>>>
>>>>> recently changed the scoping rules for shared variables (I think
>>>>> they're
>>>>> done wrong in the base image). I could change what I wanted easily. So
>>>>> I
>>>>> think I am not in some outsider author group. Instead I am happy that I
>>>>> could change what I wanted without needing anyone's approval or
>>>>> cooperation.
>>>>>
>>>>
>>> Great!
>>>
>>>  A note:
>>>> This applies to any version / distribution of Smalltalk. But it means
>>>> that you have your own version of the core system.
>>>>
>>>> Could you elaborate on the issue of the shared variables, maybe it is
>>>> something to include in the core Cuis image?
>>>>
>>>> --Hannes
>>>>
>>>
>>> Agree. It would be nice to know.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> _______________________________________________
>>> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>

On Tue, Jul 21, 2015 at 10:16 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 2015-07-21 21:13 GMT+02:00 Peter van Rooijen <peter at aba-instituut.nl>:
>
>> Hi Juan, Hannes,
>>
>> since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW,
>> ST/X, VSE, IIRC) already do it as I want it to work
>> (Squeak does it "wrong" so perhaps it's not really a Smalltalk
>> implementation)
>>
>> This is about the lookup logic when we see a name that is not a local
>> name (local to the block, method or object)
>>
>> To resolve it (i.e., determine if it is a valid reference to a shared
>> variable), this is the order of searching for the name:
>>
>> 1 pool dictionaries declared in this class (from left to right I presume
>> but I don't care so I haven't paid attention)
>> 2 classPool (i.e. the class variables defined in this class)
>> 3 classPools in superclass chain
>> 4 globals
>>
>> The code in Squeak (and Cuis) does something recursive in the lookup
>> logic when it should not, which is probably based on an incorrect
>> understanding of the lookup rules. I have to admit that it is not easy to
>> find how this should be done, I have studied the Blue Book and ANSI-98
>> Smalltalk standard (long long ago) and they were a bit fuzzy. But the logic
>> all the other dialects have also makes the most sense (to me) and works for
>> some "clever" stuff I do to make code 100% portable between dialects, so
>> that's how I like it to work.
>>
>>
> Ah, you probably mean that you would not want the superclass pool
> dictionaries to be inherited, right?
>
> Nicolas
>
>
>> Cheers, Peter
>>
>> BTW Hannes, I'm not sure I would be able to change this in Dolphin, but
>> in the other dialects, probably. But like I said, there is no need, it is
>> Squeak (and Cuis) that's the odd one out.
>>
>> On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org>
>> wrote:
>>
>>> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>>>
>>>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>>>> ....
>>>>   I
>>>>
>>>>> recently changed the scoping rules for shared variables (I think
>>>>> they're
>>>>> done wrong in the base image). I could change what I wanted easily. So
>>>>> I
>>>>> think I am not in some outsider author group. Instead I am happy that I
>>>>> could change what I wanted without needing anyone's approval or
>>>>> cooperation.
>>>>>
>>>>
>>> Great!
>>>
>>>  A note:
>>>> This applies to any version / distribution of Smalltalk. But it means
>>>> that you have your own version of the core system.
>>>>
>>>> Could you elaborate on the issue of the shared variables, maybe it is
>>>> something to include in the core Cuis image?
>>>>
>>>> --Hannes
>>>>
>>>
>>> Agree. It would be nice to know.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> _______________________________________________
>>> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150722/ab140f14/attachment-0002.html>

From peter at aba-instituut.nl  Wed Jul 22 05:57:44 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 22 Jul 2015 12:57:44 +0200
Subject: [Cuis] (Rescued) Re:  Fwd: Re: DIRECT version number
In-Reply-To: <20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
Message-ID: <CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>

Hi Ken,

On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

> On Tue, 21 Jul 2015 07:59:47 -0700
> Peter van Rooijen <peter at aba-instituut.nl> wrote:
>
> >> I was thinking: "What should a Feature Test be?".
>
> I tend to think of a hierarchy of requirements.  Perhaps something like:
>
>  Feature requireAll: #( <feature name>.. ).
>  Classes requireAll: #( <class name>.. ).
>  Methods requireAll: #( <selector name>.. ).
>  MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).
>  Tests requireAllPass: #( <unit test name> ).
>

Yeah, that's not at all what I'm thinking :). I'm thinking of something
that is automatically runnable, like a unit test. It tests something, like
a un test. But if the test does not pass, it is NOT a bug, unlike with a
unit test. It's just that we would like to know about it. Also, with nit
tests there is the assumption that the code that represents the test is
always compilable, with feature tests that cannot be assumed, so there
would need to be protection against that. Of course we want to be able to
load the feature tests in any condition, so putting it in the form of
source text and compiling that is a possibility. The fact that that makes
it slower than unit tests is not a problem, because unlike unit tests, we
don't have to run them continuously.


> The Feature class lets us require named (macro) Features with a version
> check.  I prefer that requirements at this level actually load the packages
> required and only report failure if that is not possible, although we could
> have a "preflight" verson which just checks without loading any featured
> packages.
>

I see. The thing I was thinking about merely reports about the state of a
system (of code), it does not try to configure that in any way.


>
> API's are basically "protocols", which in the absence of symbolic
> execution means checking that classes and specific method selectors exist,
> or more specifically, method selectors are applicable to specific KindOf:
> classes.
>

Well, in my mind some semantics could be expected (and tested for). For
instance I might be interested if there is a DateTime class in the image
and if it implements the ANSI DateAndTime protocol (not sure if there is
one named that). Or perhaps another class that does that. These tests can
test some actual semantics no problem.

Perhaps some of you remember that Camp Smalltalk started with Ralph
Johnson's desire to build an ANSI test suite. The way people went about it
(extension methods to SUnit? I don't really remember) was wrong and could
not possibly work (in my opinion anyway), but I could not convince a lot of
people and such a test suite was never written. But with Feature Tests I
think we could come a long way.

>
> Further, some Unit Tests may be required to pass to ensure compliance with
> some specification.
>

Well, except that the tests would not be unit tests in the strictest sense.
But semantics, not merely interface, can be tested for sure.

>
> We should be able to automate at least some of this


Automate the running of the feature tests? Of course.


> including a first pass of generating the test sets, which could then be
> pruned by hand as required.
>

That I don't see happening. You test what YOU think is important to be sure
of. No machine can decide/calculate that for you. Perhaps I'm
misunderstanding you.

Cheers, Peter


>
> $0.02,
> -KenD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150722/32a7fa87/attachment-0002.html>

From peter at aba-instituut.nl  Wed Jul 22 06:29:05 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 22 Jul 2015 13:29:05 +0200
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
Message-ID: <CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>

I'm thinking about some features (pun not intentional) of this Feature Test
framework:

1. It's reasonable to assume that many tests will depend on something else
working, but that cannot be counted on, and
we would not want to repeat testing for that and also would not run into it
failing all the time and that filling our feedback.

1a. So it would make sense to add a #precondition method to each Feature
Test class.

FeatureAnsiArray
    class
        precondition

        self run: 'Array' "i.e. the global Array must be present"

then only if the precondition for the class is satisfied, will the test
methods be executed. so if most of them start with

'Array new ?' then they would all fail anyway so we don't need to test them.

2. You would want to be able to assure that in a particular object you
would be able to access a particular variable.

so in the test method you would write:

FeatureTest1
    class
        test1

        self setContext: OrderdCollection new

        self run: 'elements' "determine if the inst var elements is present
in a new OrderedCollection"

        self run: 'elements == nil' expect: false

        self run: 'elements isOrderedCollection' expect: true

let's say the test runner would continue testing even if something failed,
e.g. the array is called array, not elements. then we already know that the
following expressions will fail

so we might instead write:

        self run: 'elements' ifFail: [^self]

 3. Instead of implicitly testing for a global using run: 'NameOfTheGlobal'
or for a class var using setContext: and then run'NameOfTheClassVar' there
could be convenience methods for

        self expectGlobal: 'NameOfTheGlobal' "argument may be given as a
Symbol as well"

        self expectClass: 'NameOfTheClass' "additionally verified that the
global holds a class"

        self expectSharedVariable: 'Foo' inClass: 'Bar'

this would make for nicer feedback since the expectation is made clearer

Okay just 2 more cents!

Cheers, Peter



On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen <peter at aba-instituut.nl>
wrote:

> Hi Ken,
>
> On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <Ken.Dickey at whidbey.com>
> wrote:
>
>> On Tue, 21 Jul 2015 07:59:47 -0700
>> Peter van Rooijen <peter at aba-instituut.nl> wrote:
>>
>> >> I was thinking: "What should a Feature Test be?".
>>
>> I tend to think of a hierarchy of requirements.  Perhaps something like:
>>
>>  Feature requireAll: #( <feature name>.. ).
>>  Classes requireAll: #( <class name>.. ).
>>  Methods requireAll: #( <selector name>.. ).
>>  MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).
>>  Tests requireAllPass: #( <unit test name> ).
>>
>
> Yeah, that's not at all what I'm thinking :). I'm thinking of something
> that is automatically runnable, like a unit test. It tests something, like
> a un test. But if the test does not pass, it is NOT a bug, unlike with a
> unit test. It's just that we would like to know about it. Also, with nit
> tests there is the assumption that the code that represents the test is
> always compilable, with feature tests that cannot be assumed, so there
> would need to be protection against that. Of course we want to be able to
> load the feature tests in any condition, so putting it in the form of
> source text and compiling that is a possibility. The fact that that makes
> it slower than unit tests is not a problem, because unlike unit tests, we
> don't have to run them continuously.
>
>
>> The Feature class lets us require named (macro) Features with a version
>> check.  I prefer that requirements at this level actually load the packages
>> required and only report failure if that is not possible, although we could
>> have a "preflight" verson which just checks without loading any featured
>> packages.
>>
>
> I see. The thing I was thinking about merely reports about the state of a
> system (of code), it does not try to configure that in any way.
>
>
>>
>> API's are basically "protocols", which in the absence of symbolic
>> execution means checking that classes and specific method selectors exist,
>> or more specifically, method selectors are applicable to specific KindOf:
>> classes.
>>
>
> Well, in my mind some semantics could be expected (and tested for). For
> instance I might be interested if there is a DateTime class in the image
> and if it implements the ANSI DateAndTime protocol (not sure if there is
> one named that). Or perhaps another class that does that. These tests can
> test some actual semantics no problem.
>
> Perhaps some of you remember that Camp Smalltalk started with Ralph
> Johnson's desire to build an ANSI test suite. The way people went about it
> (extension methods to SUnit? I don't really remember) was wrong and could
> not possibly work (in my opinion anyway), but I could not convince a lot of
> people and such a test suite was never written. But with Feature Tests I
> think we could come a long way.
>
>>
>> Further, some Unit Tests may be required to pass to ensure compliance
>> with some specification.
>>
>
> Well, except that the tests would not be unit tests in the strictest
> sense. But semantics, not merely interface, can be tested for sure.
>
>>
>> We should be able to automate at least some of this
>
>
> Automate the running of the feature tests? Of course.
>
>
>> including a first pass of generating the test sets, which could then be
>> pruned by hand as required.
>>
>
> That I don't see happening. You test what YOU think is important to be
> sure of. No machine can decide/calculate that for you. Perhaps I'm
> misunderstanding you.
>
> Cheers, Peter
>
>
>>
>> $0.02,
>> -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/20150722/5bba2659/attachment-0002.html>

From Ken.Dickey at whidbey.com  Wed Jul 22 08:58:12 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Wed, 22 Jul 2015 06:58:12 -0700
Subject: [Cuis] (Rescued) Re:  Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
Message-ID: <20150722065812.da4e892dbe35764801607ace@whidbey.com>

On Wed, 22 Jul 2015 12:57:44 +0200
Peter van Rooijen <peter at aba-instituut.nl> wrote:

> Hi Ken,
> 
> On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> 
> > On Tue, 21 Jul 2015 07:59:47 -0700
> > Peter van Rooijen <peter at aba-instituut.nl> wrote:
> >
> > >> I was thinking: "What should a Feature Test be?".
> >
> > I tend to think of a hierarchy of requirements.  Perhaps something like:
> >
> >  Feature requireAll: #( <feature name>.. ).
> >  Classes requireAll: #( <class name>.. ).
> >  Methods requireAll: #( <selector name>.. ).
> >  MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).
> >  Tests requireAllPass: #( <unit test name> ).
> >
> 
> Yeah, that's not at all what I'm thinking :). I'm thinking of something
> that is automatically runnable, like a unit test. It tests something, like
> a un test. But if the test does not pass, it is NOT a bug, unlike with a
> unit test. It's just that we would like to know about it. Also, with nit
> tests there is the assumption that the code that represents the test is
> always compilable, with feature tests that cannot be assumed, so there
> would need to be protection against that. ...

Remember the phrase "agreeing loudly"?

OK, so you want the "preflight option" for Feature check.

To not "fail a test" one has to test in sequence.

- Are the Features present (as in Feature require: #<whatever> )
- Are the classes present?
- Do the method selectors exist?
- Are the right protocols there (method selectors exist for specific classes; e.g. #isFoo: is a method on a class for some aClass isKindOf: <foo>).
- What code is expected to yield a specific result (actually run some code to check, like, well, a unit test).

Failure at any step/level means something is missing and the more specific tests at the next level don't get run. 

A whole hierarchy of tests can be bundled as one Feature Test.

How is this different than what you are proposing?

-- 
-KenD



From pbpublist at gmail.com  Wed Jul 22 14:19:16 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 22 Jul 2015 15:19:16 -0400
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
	<CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>
Message-ID: <1437592756.2326.32.camel@gmail.com>

On Wed, 2015-07-22 at 13:29 +0200, Peter van Rooijen wrote:
> I'm thinking about some features (pun not intentional) of this Feature
> Test framework:
> 
> 
> 1. It's reasonable to assume that many tests will depend on something
> else working, but that cannot be counted on, and
> we would not want to repeat testing for that and also would not run
> into it failing all the time and that filling our feedback.
> 

Why not?  I agree that these would be a different category of test in
that the dependencies would be more complex and often dependent on more
than one package, but why would their functioning be considered
optional?  If they fail, shouldn't they either be addressed right away
or explicitly deprecated?  If you make the tests easy to ignore/forget
about, they will be.  If the functionality they are testing can't be
counted on, it won't be used.

If your thinking is that these would be tests that are part of package X
but might rely on package Y which might not be loaded yet, why not
instead just make the tests part of package Z which depends on package X
and Y?  The whole idea is that these are not unit tests in that sense...
have them live where ever it is appropriate.

> 
> 1a. So it would make sense to add a #precondition method to each
> Feature Test class.
> 
> 
> FeatureAnsiArray
>     class
>         precondition
> 
>         
>         self run: 'Array' "i.e. the global Array must be present"
> 
> 
> then only if the precondition for the class is satisfied, will the
> test methods be executed. so if most of them start with
> 
> 
> 'Array new ?' then they would all fail anyway so we don't need to test
> them.
> 
> 
> 2. You would want to be able to assure that in a particular object you
> would be able to access a particular variable.
> 
> 
> so in the test method you would write:
> 
> 
> FeatureTest1
>     class
>         test1
>         
>         self setContext: OrderdCollection new
> 
> 
>         self run: 'elements' "determine if the inst var elements is
> present in a new OrderedCollection"
> 
> 
>         self run: 'elements == nil' expect: false
> 
> 
>         self run: 'elements isOrderedCollection' expect: true
> 
> 
> let's say the test runner would continue testing even if something
> failed, e.g. the array is called array, not elements. then we already
> know that the following expressions will fail
> 
> 
> so we might instead write:
> 
> 
>         self run: 'elements' ifFail: [^self]
> 
> 
> 
>  3. Instead of implicitly testing for a global using run:
> 'NameOfTheGlobal' or for a class var using setContext: and then
> run'NameOfTheClassVar' there could be convenience methods for
> 
> 
>         self expectGlobal: 'NameOfTheGlobal' "argument may be given as
> a Symbol as well"
> 
> 
>         self expectClass: 'NameOfTheClass' "additionally verified that
> the global holds a class"
> 
> 
>         self expectSharedVariable: 'Foo' inClass: 'Bar'
> 
> 
> this would make for nicer feedback since the expectation is made
> clearer

I went the other way when I did the ApiFile tests in that it didn't seem
terribly important to use most of the testing framework capabilities
(other than the overall pass/fail aspect to keep the initial PoC as
simple as possible)  So they are simply small snippets of code that
performed the desired task but didn't care where it failed (if it
failed):  the failure to successfully complete the task would be the
indicator that there was a problem and we would know that either
something being depended on had broken and needed to be fixed or that
the test needed to be updated/overhauled to represent the new way of
accomplishing the task.

My thinking was that as we started to build up a number of these, we
might start to see common breakage patterns and then we could decide
whether or not to handle that them more explicitly (whether using the
existing test framework capabilities, creating a new one, etc.)  Trying
to engineer it up front didn't seem like a great idea not knowing what
common failure states would look like yet.

> 
> 
> Okay just 2 more cents!
> 

Mine as well.  This is a worthwhile discussion/exercise IMO as we need
to get to a common understanding of what we are doing here.

> 
> Cheers, Peter
> 
> 
> 
> 
> 
> On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen
> <peter at aba-instituut.nl> wrote:
>         Hi Ken,
>         
>         On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey
>         <Ken.Dickey at whidbey.com> wrote:
>                 On Tue, 21 Jul 2015 07:59:47 -0700
>                 Peter van Rooijen <peter at aba-instituut.nl> wrote:
>                 
>                 >> I was thinking: "What should a Feature Test be?".
>                 
>                 I tend to think of a hierarchy of requirements.
>                 Perhaps something like:
>                 
>                  Feature requireAll: #( <feature name>.. ).
>                  Classes requireAll: #( <class name>.. ).
>                  Methods requireAll: #( <selector name>.. ).
>                  MethodsForKind class: <class name> requireAll:
>                 #( <selectorName>.. ).
>                  Tests requireAllPass: #( <unit test name> ).
>         
>         
>         Yeah, that's not at all what I'm thinking :). I'm thinking of
>         something that is automatically runnable, like a unit test. It
>         tests something, like a un test. But if the test does not
>         pass, it is NOT a bug, unlike with a unit test. It's just that
>         we would like to know about it. Also, with nit tests there is
>         the assumption that the code that represents the test is
>         always compilable, with feature tests that cannot be assumed,
>         so there would need to be protection against that. Of course
>         we want to be able to load the feature tests in any condition,
>         so putting it in the form of source text and compiling that is
>         a possibility. The fact that that makes it slower than unit
>         tests is not a problem, because unlike unit tests, we don't
>         have to run them continuously.
>          
>                 The Feature class lets us require named (macro)
>                 Features with a version check.  I prefer that
>                 requirements at this level actually load the packages
>                 required and only report failure if that is not
>                 possible, although we could have a "preflight" verson
>                 which just checks without loading any featured
>                 packages.
>         
>         
>         I see. The thing I was thinking about merely reports about the
>         state of a system (of code), it does not try to configure that
>         in any way.
>          
>                 
>                 API's are basically "protocols", which in the absence
>                 of symbolic execution means checking that classes and
>                 specific method selectors exist, or more specifically,
>                 method selectors are applicable to specific KindOf:
>                 classes.
>         
>         
>         Well, in my mind some semantics could be expected (and tested
>         for). For instance I might be interested if there is a
>         DateTime class in the image and if it implements the ANSI
>         DateAndTime protocol (not sure if there is one named that). Or
>         perhaps another class that does that. These tests can test
>         some actual semantics no problem.
>         
>         
>         Perhaps some of you remember that Camp Smalltalk started with
>         Ralph Johnson's desire to build an ANSI test suite. The way
>         people went about it (extension methods to SUnit? I don't
>         really remember) was wrong and could not possibly work (in my
>         opinion anyway), but I could not convince a lot of people and
>         such a test suite was never written. But with Feature Tests I
>         think we could come a long way.
>                 
>                 Further, some Unit Tests may be required to pass to
>                 ensure compliance with some specification.
>         
>         
>         Well, except that the tests would not be unit tests in the
>         strictest sense. But semantics, not merely interface, can be
>         tested for sure.
>                 
>                 We should be able to automate at least some of this
>         
>         
>         Automate the running of the feature tests? Of course.
>          
>                 including a first pass of generating the test sets,
>                 which could then be pruned by hand as required.
>         
>         
>         That I don't see happening. You test what YOU think is
>         important to be sure of. No machine can decide/calculate that
>         for you. Perhaps I'm misunderstanding you.
>         
>         
>         Cheers, Peter
>          
>                 
>                 $0.02,
>                 -KenD
>         
>         
>         
>         _______________________________________________
>         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  Thu Jul 23 08:11:37 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 10:11:37 -0300
Subject: [Cuis] Cuis Archive
In-Reply-To: <559AA39A.19585.46E7C0@dnorton.mindspring.com>
References: <559AA39A.19585.46E7C0@dnorton.mindspring.com>
Message-ID: <55B0E809.7010904@jvuletich.org>

Yes, unfortunately.

I hadn't much time for this before, but yesterday I spent over one hour 
chatting with the provider's (HostGator) support. I use them for 
cuis-smalltalk.org, jvuletich.org, personal email and the cuis mail 
list. The service is usually very reliable.

But now this happened. I swear I did not touch anything.

They opened a support ticket, and said they will fix it. I hope they do.

Apologies,
Juan Vuletich

On 7/6/2015 12:49 PM, Dan Norton wrote:
> Hi,
>
> There is nothing in the archive for July. Anybody else experiencing this?
>
>   - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Thu Jul 23 08:48:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 10:48:34 -0300
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT version
 number
Message-ID: <55B0F0B2.6090202@jvuletich.org>

Very small snip (while preparing an answer for the whole thread):

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.
> ...

Yes. Cuis is MIT, etc. You don't have any obligations, etc.

But, if you tell what are you using Cuis for, and how, that is very 
useful (and nice to know).
If you are maintaining a significant code base, if possible, tell about 
it. This will help us better support you.

It is nice to know to what extent something you do is useful for others. 
I think it is also a polite and reasonable way to say thanks to us, 
working for you.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 23 08:51:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 10:51:09 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437352771.6934.219.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
Message-ID: <55B0F14D.7010405@jvuletich.org>

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> It really comes down to what is Cuis?  Is it:
>
> 1) a minimal Smalltalk that you play around with ideas / prototype
> something in the short to intermediate term
>
> 2) a platform that you can take that idea you were playing around with,
> and if it proves out, build something more substantial from for the
> longer term
>
> 3) a completely experimental environment.  Anything can change at any
> time.  Supporting 1 is doable but 2 is doubtful.
>
> Right now, Cuis is great at 1 but seems like it should be able to handle
> both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
> all, but who knows, others may disagree.  If others look at it
> differently, I'd love to know how you look at Cuis.

I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that way.

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Thu Jul 23 09:09:24 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 23 Jul 2015 14:09:24 +0000
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55B0F14D.7010405@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<55B0F14D.7010405@jvuletich.org>
Message-ID: <CAGQxfVh5AMJnVr3i-Kc2jomzTFoug5r1u=KbJa1VX6b_jruT6A@mail.gmail.com>

1) and 2) sounds like there is a need for an Ubuntu type of approach.

Labelled releases at regular intervals -- could be semi-annually or
annually. Some of them receive important bux fixes thus constituting
Long Term Releases.

Or stable vs unstable branches in github.

In two days on the 25th of July it will be exactly 2 years after the
last release of 4.2.   :-)

A point to consider as well is that what Juan is doing constitutes a
trunk from which releases are forked from time to time by other
people. The ones who run Feature Tests ....

--Hannes

On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/19/2015 9:39 PM, Phil (list) wrote:
>> ...
>> It really comes down to what is Cuis?  Is it:
>>
>> 1) a minimal Smalltalk that you play around with ideas / prototype
>> something in the short to intermediate term
>>
>> 2) a platform that you can take that idea you were playing around with,
>> and if it proves out, build something more substantial from for the
>> longer term
>>
>> 3) a completely experimental environment.  Anything can change at any
>> time.  Supporting 1 is doable but 2 is doubtful.
>>
>> Right now, Cuis is great at 1 but seems like it should be able to handle
>> both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
>> all, but who knows, others may disagree.  If others look at it
>> differently, I'd love to know how you look at Cuis.
>
> I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that
> way.
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Thu Jul 23 09:15:15 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 11:15:15 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437443935.2300.77.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>	<1437352771.6934.219.camel@gmail.com>	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<1437443935.2300.77.camel@gmail.com>
Message-ID: <55B0F6F3.3030503@jvuletich.org>

Another specific comment:

On 7/20/2015 10:58 PM, Phil (list) wrote:
> I agree. The question is how do we accomplish this. My sense is that
> we are starting to chew up more of his time peppering him with
> questions / issues that he didn't anticipate resulting from recent
> changes.

This is a very good thing! I need to know the extent of the trouble I 
create when I change something.
This is no longer my private quest for the perfect Smalltalk-80. Your 
needs are really important now!
If some changes have issues I didn't anticipate, I need to know. This is 
another force (amongst a few others)
driving the evolution of Cuis.

> ...
> I don't think that most people will accept the compatibility through
> continual testing/fixing over a long period of time... most will likely
> give up after experiencing this for a while if they're attempting to use
> Cuis as something more than a playground.

I don't want that to happen.

> If the long term objective *isn't* for Cuis to be a platform, then an
> acceptable answer would be 'you're using it wrong'.  Or Juan could
> simply say 'yeah, ok... but I really don't want to do that...'

But now, after all these years, most of the worst, convoluted, horrible, 
apis and code inherited from Squeak have been cleaned. Right now, if I 
break something badly, and without any prior communication, it is most 
likely a mistake on my part. If I do such mistake, I'll be willing to 
fix it. I think this has happened a few times in this last couple of years.


>> ...
>> As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful.  I heard that the Arabic word for "miracle" literally translates to "breaking the habit".  Interesting thought.
>> ...

Hehehe. Yes.

> I know you're generally pretty level headed and not looking to be
> disagreeable.  I engaged in this discussion because it is an important
> one to have and it felt like the right time to have it. A lot of what is
> being proposed is a change from how things have historically been.  But
> at the same time the pace of change has slowed down (ah, those whirlwind
> 1.x and 2.x days... :-) so it *seems* like trying to start to try to
> stabilize things a bit has relatively little downside.  (Dunno... maybe
> Juan is working on chucking the whole Magnitude hierarchy or something
> major like that right now...)

:D

No, the only important API change we have planned is to move from 
FileDirectory to FileMan.

We'll be doing relatively risky stuff, but not with the objective of 
changing APIs, although that might be a consequence. Some things I'd 
like to work in the next months / years are:
- Spur. The Spur object format requires a few changes in the compiler 
and core classes
- 64 bit. Having 64 and 32 bit images might also break stuff (?)
- Bootstrap from sources
- Switch to Morphic 3

Maybe I'm forgetting about something... And at some point, if possible, 
I'd like to integrate (or support and use as optional packages) Ropes 
and Unicode from Ken, VMMaker, code generation, VM simulation. Morphic 
programming for app developers should be easier and more convenient... 
And we might come up with other cool stuff to be done, that could 
perhaps impact a bit on APIs used by others...

>> What is the simplest thing that will work?
>> -KenD
>

That is indeed the question we need to answer.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 23 09:25:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 11:25:49 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437341905.6934.99.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>	
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
Message-ID: <55B0F96D.4010706@jvuletich.org>

Hi Phil,

This is  very good and stong advocacy on documented public APIs. Thank you!

(a few comments inline)
On 7/19/2015 6:38 PM, Phil (list) wrote:
> On Sun, 2015-07-19 at 11:20 -0300, Juan Vuletich wrote:
>> Hi Folks,
>>
>> (inline)
>>
>> On 7/17/2015 3:45 PM, Phil (list) wrote:
>>> ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>>>> Thank you Juan, for answering.
>>>>>
>>>>> At the moment I feel uncomfortable using Cuis because it is currently
>>>>> a quite fast moving target. I perceive quite a number of API changes
>>>>> though this might be wrong. But I do not know because there are no
>>>>> release notes which summarize it.
>>> I totally feel Hannes' pain having gone through it a few times myself
>>> over the years.  At the same time, I agree with Ken's point about not
>>> getting too bogged down in process since we're in the best position
>>> right now to break things for the better longer term.
>>>
>>>> Yes, that's true. Besides, we don't have a specification of what is an
>>>> API and what is not. So, almost any change can be considered an API change.
>>> That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
>>> issue, not specific to Cuis)  I believe it is largely fixable without
>>> tons of documentation and tests: the use of private (categories or
>>> method naming convention).  Bernhard pointed out an existing capability
>>> a few months ago
>>> http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
>>> While I personally like the idea of private categories, one of these
>>> approaches should really be seriously considered.
>>>
>>> Other than a few specific examples (i.e. mostly the base data types
>>> including the Collection and Number class hierarchies which are pretty
>>> mature and don't change all that much anyway) I would guesstimate that
>>> <20% (probably closer to 10%) of the methods, and and unknown % of
>>> classes (a significantly larger fraction though), should even be
>>> considered public.  If things were indicated as private that would
>>> accomplish two things:
>>>
>>> 1) We could construct some simple tooling (some combination of up-front
>>> warnings in the editor and/or a lint-type tester after the fact) that
>>> would allow people to identify problematic calls within their code.
>>> (i.e. just because it works now doesn't mean it always will if you keep
>>> calling X, Y, Z...)
>>>
>>> 2) It would provide a way for people to know if something needs to be
>>> discussed.  i.e. 'In class X method Y is private but I need that type of
>>> functionality' so you would know that there's a need and could consider
>>> either making it public, and therefore supported, or rethinking its
>>> implementation if you'd like to offer a better public API solution.
>> Ok. Doing something along these lines would be great. But please note
>> that it is a rather large amount of work. It is not something I'm able
>> or willing to do it alone. If you (any of you all, not just Phil) wants
>> to start defining the API for any part of the system or optional
>> packages, please start doing it and send the changesets to the list. If
>> we get this working, I'll start the tools you mention.
>>
> Agreed that this is a lot of work and I definitely wasn't expecting you
> to do it (other than reviewing the work for approval/rejection.)  I'll
> be happy to work on this with anyone else who is interested.
>
>> <slowly diverging into OT rant>
>>
>> On the other hand (and please forgive me if this kills a bit of
>> momentum), I don't really think we are changing APIs that much. And I
>> don't think we'll be doing it any more in the future than we do today,
>> at least in the base image. I hope to see most of the activity and
>> incompatible changes to happen in optional packages, and affecting
>> package dependencies... Mhhh, now that I write this I think that it
>> doesn't really go against the idea of defining APIs. Maybe APIs in the
>> base image will almost never change or be a problem, but packages should
>> provide APIs too... Optional packages will (I hope!) always be
>> improving, and new ones will appear all the time.
>>
> You'd likely be very surprised.  I'd say there's usually at least a
> couple changes a month that breaks something, somewhere in my code.  A
> few recent examples that have been discussed on the list: removing clone
> broke OpenGL a bit (easy fix thanks to the on-list discussion), removing
> compilerClass killed OMeta, a while back you were considering removing
> storeString which would again break OMeta. etc. (that's just a few
> things off the top of my head from the last few months and note that all
> were probably considered minor, inconsequential changes)  However the
> issue snowballs quickly if one misses a few updates and some of the
> breakage is related to changes that weren't discussed on the list or
> otherwise documented.  I've been managing through this recently (the
> last 6 months or so) by upgrading my image very quickly after you commit
> changes but I doubt most people would be able / willing to have that
> level of diligence.
>
> A lot of this breakage is no one's 'fault', it's just how a lot of
> Smalltalk code has been historically written.  Two examples of how this
> happens:
>
> 1) For ports of existing code, you're subject to the whims of the
> original author who often used techniques described in the next item to
> write their code.  And of course, code coming from Squeak/Pharo means
> that there were often 10 or more possible ways they could have
> implemented parts of their solution.  So after porting a few different
> packages, you have several different approaches to the same kinds of
> problems.
>
> 2) For one's own code because there is currently no distinction between
> public and private, you tend to go either with what you already know or
> whatever the first thing you find poking around the image that appears
> to make sense and work.  Even in Cuis, there are still usually multiple
> ways to do most things, so you end up arbitrarily picking one or two
> that you like.  As a result, you quickly end up with a potpourri of
> calls that may or may not be the best way to do things.  Over time, you
> start building new code on top of this code and quickly end up with a
> house of cards that comes crashing down as the result of a subsequent
> image update.  Again, this often results in each of us as authors
> deciding on superficially different solutions to the same problems.
>
> I'm not expecting you to not do things that might break my, or anyone
> else's code, going forward.  Like Hannes, I'm just looking for ways to
> help manage through the changes and breakage.  One of the key aspects of
> this is to have an opinion and to say 'hey, here are the one or two ways
> we should be doing this'.  There may be disagreement and discussion as
> to what those one or two ways are, but at the end of the day we need to
> settle these issues so that both your and our lives are manageable.
> That's really the main thing that a public API is, IMO.  There may be
> all sorts of internal helper methods and implementation details needed
> to make it all work, but like the cells of a living organism, these
> details should be hidden and their use discouraged.  Hey, didn't someone
> say something along those lines once? :-)

Yes. :)

>> If all this work, the Cuis will be a lot less about my personal effort
>> and coding style, and the packages maintained by each one of us will
>> become the main characters in this story. And this will be a very good
>> thing. The base image should be about providing a good base for doing
>> the really interesting stuff on top...
>>
> I both agree (that the packages become more important) and disagree
> (that Cuis fades into the background).  I still view the core Cuis image
> as the philosophical and stylistic backbone that all of my stuff is
> based on.  It's a constant reminder to clean up and get rid of as much
> cruft as possible in my code (especially for the packages that have yet
> other packages dependent on them)  I freely admit that I am mostly
> falling short in my execution on this front, but it would be easy to
> lose sight of entirely if Cuis didn't stay the course.
>
>> Let me tell you a bit about how Cuis got started. Many years ago I did
>> my thesis on audio/music processing. The I wanted to turn that into a
>> novel and fun application for musicians (both pros and anyone willing to
>> play with sound). I started to think about how a good GUI for that could
>> be, giving the feeling of modifying sound by direct manipulation of it,
>> as if it was clay, as if it was visual and not just auditory. Well, that
>> was the start of my questioning of the whole GUI business and Morphic 3.
>> And it became clear to me that Squeak had turned into something that was
>> not the best possible environment to do all this. The idea of "fixing"
>> Squeak, and thus make Cuis, was born. So, Cuis was not and end in
>> itself, but a means for allowing experimentation, freedom to build
>> applications in new styles, etc.
>>
>> (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other
>> came later, as an observation on facts.)
>>
>> So, when the moment comes when Cuis stabilizes a bit, and interest moves
>> to packages and applications built by all us, Cuis will start to fulfill
>> its original objective.
>>
> It's already this is as far as I'm concerned.  I can't tell you much
> time I burned just trying to extract OpenGL from Croquet so that I could
> load it into Squeak, for example.  It was painful on both sides, and by
> the time I was done I had to think for a bit to remind myself what my
> original objective was... I have *never* had this issue with Cuis.
>
> It is absolutely enabling me to play around with ideas and build things
> that I couldn't have / wouldn't have bothered in Squeak.  The only issue
> I'm having is that once I've built it, I want to keep it running :-)
>
>> </slowly diverging into OT rant>
> Not at all a rant as it reaffirms *why* you're doing what you're doing.
> If you lost sight of that, that's when I'd start worrying about Cuis.
>
>>>> ...
>>>> The problem, I think, is not identifying well defined Cuis releases. The
>>>> problem is knowing how updates could affect your code
>>> By narrowing the scope of what the public API is using private
>>> designators, this dramatically reduces what you need to be concerned
>>> with on this front.  It's part of the reason that Apple, Google, and
>>> even Microsoft are so adamant about public APIs these days.  They dealt
>>> with the pain of even major developers depending on private APIs for
>>> decades. It's only been in the last 10 years or so that they've been
>>> able to dig themselves out from under this issue.
>>>
>>> This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
>>> attitude of 'you have the source, play around, have fun!' has morphed
>>> into 'everything is a public API!  there are no rules! isn't this
>>> great?'  Well no, it's not great.  It makes life impossible for image
>>> maintainers (Squeak has been in a coma for the last decade or so as the
>>> result of trying to keep everyone happy... yet no one seems to be) and
>>> miserable for those who are trying to keep code running on it (stuff
>>> still breaks all the time.)
>> Yes.
>>
>>> I personally believe the minimalism and simplicity that Cuis is based on
>>> has the best long term prospects but we have to get out of this
>>> 'everything is public' mindset.  Sure, we have all the source: look at
>>> it, learn from it, poke around, refactor it, submit fixes, etc.  But
>>> there needs to be a manageable subset of it which is considered the
>>> 'public API' that people can depend on to write frameworks and apps on
>>> top of that is relatively stable longer term.  Let's start defining what
>>> that is and backfill changes to the public API (which will happen from
>>> time to time as we don't want things to be completely static) with tests
>>> and documentation so you can focus your efforts on where they matter
>>> most and you get the most enjoyment from.
>> I fully agree and support this.
>> Maybe an alternative to yet-another-convention-on-categories could be to
>> mark public methods with a pragma, or make them send 'self publicAPI' or
>> such... This could be better for the tools, also.
>>
> I like your idea better re: rather than having to go through and mark
> the majority as private, just mark the minority as public.  I'm open to
> either of your proposed approaches.  I just tossed out the two (method
> categories and naming) I was aware of but agree that they would not do
> much to ease developing tools to support/enforce.  Of the two ideas, am
> I correct in believing that pragma would have the lowest runtime
> overhead?  Are there any downsides you can think of to using pragma?

No that I can think of. A bit of experimentation is in order.

> Speaking of enforcing, I am not proposing that we make this a
> straight-jacket for anyone: it should be easy to opt-out the way things
> like underscore assignment are (except for pp which I'm still trying to
> get to an easily repro example with... :-) so that anyone who doesn't
> care about this isn't forced into it.  On the other hand, for people who
> do care, they should be able to leave it 'enabled', whatever that ends
> up meaning, and get help from the tooling to help them minimize
> potential future breakage.  The downside to opting out would be that
> you, as the author opting out, have decided to take it entirely on
> yourself to keep your code running across builds/releases.

Sure.

>>> ...
>>>> I don't have that either. I run the tests from time to time (I'll start
>>>> doing it before any commit, and add the xml report to the rep). But this
>>>> is not the most important reason why Cuis is solid. Cuis is very
>>>> reliable because:
>>> reliable != stable
>> ;)
>>
>>>> - I'm not too bad as a coder.
>>>> - I do my own code revisions at least one day after each change.
>>>> - I use Cuis every day, and spot most problems in the updates, before
>>>> commtting them to the repo.
>>>> - I really, really care about code quality.
>>>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>>>> is a big responsibility, given how important I think Smalltalk-80 is.
>>>>
>>> Agree to all this and more.  Cuis would not be where it is without your
>>> continued effort and diligence. (i.e. setting aside that you obviously
>>> created it, if you had just tossed it out into the world and let it go
>>> at best it would have started looking something like Squeak or Pharo by
>>> now.  It's a lot of effort over the long term to *keep* it small and
>>> focused.  THANK YOU JUAN!)
>> Thanks for your nice words, Phil. I really appreciate that you all
>> accept this rather restrictive dev model for the base image, in contrast
>> with a more open trunk style. Hopefully, as the base image becomes
>> stable and almost irrelevant, this will be each time less of a problem.
>>
>>>> So, I suggest running your tests when updating your image, or migrating
>>>> your code to an updated image.
>>> +1 to tests as they do help quite a bit and are a very good practice.
>>> Just be judicious in what/where you test (I personally don't subscribe
>>> to the TDD approach where you spend your days mostly writing tests.
>>> That's just admitting defeat in that you spend all day writing
>>> executable documentation.)
>> <OT>
>>
>> I don't subscribe to "extreme" TDD either. To me design is a creative
>> activity, both technical and artistic. It should be "driven" by
>> creativity and intelligence, not by a process. Any xDD process is
>> admitting defeat on design itself!
>>
> Heh... I like the way you put that.
>
>> </OT>
>>
>>>> In any case, I think this doesn't answer your concerns. What you need is
>>>> some way to know which updates could affect you, to review them in
>>>> detail, and understanding their effect on your code. A list of the
>>>> affected classes and/or methods for each update makes no sense. Cuis can
>>>> already show you that very easily. Perhaps each update should include:
>>>>
>>>> 1) parts of the system that are affected:
>>>> - Kernel
>>>> - Compiler
>>>> - Tools
>>>> - Morphic
>>>> - etc
>>>>
>>>> 2) Level of risk involved
>>>> - very unlikely to break code that depends on this part of the system
>>>> - could perhaps break code that depends on this part of the system
>>>> - will most likely break code that depends on this part of the system
>>>>
>>>> Or something like that.
>>>>
>>>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>>>> free to answer there if you agree.
>>> One final thought on this:  I suspect a major cause of people abandoning
>>> Cuis (and Smalltalk in general), behind the 'it's too different from
>>> what I'm used to'/'not mainstream' reaction, is the instability of its
>>> APIs.
>> Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem)
>> is a PITA too...
> True, neither extreme (changing nothing vs. changing everything) works
> very well.<cough>Perl 6</cough>  :-)
>
>> As a bottom line, let me repeat: This is too big for me to do it.
>> Please, folks, start documenting the APIs you most care about.
>>
> Ready to go... we just need to agree on how to do it (pragma/method
> call/method category/method name?)  Also, this is most definitely
> related to the 'Canonical test cases?' thread from a few months ago as
> these types of test cases / docs are part of the backfill I was
> referring to.

I think pragmas are the best options. Also, "API existence tests" should 
ask for those APIs to be declared as public.

> As I've been writing this it occurs to me that there's probably a pretty
> easy way to go about getting started on this: IIRC, there are ~1,500
> distinct method names in the core image.  If I do a count of how many
> times my code is calling any of those methods, that should pop out what,
> for my code, is the low hanging fruit.  The long-tail of say 1-5 calls
> for the lesser used methods are the tedious work that will take more
> effort for me to sort through.  We could use my 'short list' to at least
> provide a starting point and using these most frequently called methods
> you could scan through the list and could say 'hey, why are you calling
> X instead of Y?' or maybe you'd get some visibility in the sense of
> 'wow, I didn't think that was being used'.  Hmm... I've got some
> analysis to do...

And some automated scripts to generate thos pragmas to write :)

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 23 09:59:38 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 11:59:38 -0300
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
	checking them and Releases)
Message-ID: <55B1015A.2080109@jvuletich.org>

Hi Folks,

I've just re-read the very rich threads related to this. Thank you all 
for thoughtful and valuable considerations and opinions. This mail 
attempts to make really small summary, to start taking action.

First, the easiest. Releases
-------------------------------------
Several of you see real value on doing a few named releases per year. 
Theres' no big downside, so, let's do it. I think this is a good time to 
do a release. So, I'll refrain to introduce any major changes, except 
important bugfixes. Please start testing / updating / fixing your 
packages and applications. When we are all happy, and we all agree that 
the whole ecosystem is in a healthy state, we'll call that a release.

We need a name for this release. The obvious choice is "Cuis4.3-nnnn". 
So, there might be a Cuis4.3-2456, and as that branch evolves, a 
Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha" 
updates of Cuis4.4. So, I guess #2459 would be (a potential risky 
change) for Cuis 4.4. What if later we need to apply some patch to the 
stable Cuis4.3? How would we name it?

After a bit of discussion, I can take action. Or you can volunteer for 
Release Manager or member of the Release Team for Cuis 4.3.

Next, Documented, Public APIs
-------------------------------------------

Use pragmas, like PubicAPI (some method we intend to support and keep in 
that hierarchy), or CalledFromOutside (some method our yet-to-be-written 
tool detects as called from another package). Write tools for analyzing 
them. Do not remove them without due discussion.

It should be possible to write tests for existence of APIs.

This area is new to us, and we'll learn as we go.

Anybody can take action here. Documenting APIs by hand, writing tools to 
try to autogenerate them, writing tests that check for existence of 
specific APIs, whatever you can come up with.

This sounds like a major strategic direction, and in a very early stage, 
so maybe we'd not include anything of this in the Cuis4.3 release, but 
make this the start of the Cuis4.4 effort.

Thoughts? Or feel free to start coding!

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Thu Jul 23 16:26:38 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 23 Jul 2015 17:26:38 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <CAGQxfVh5AMJnVr3i-Kc2jomzTFoug5r1u=KbJa1VX6b_jruT6A@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com> <55B0F14D.7010405@jvuletich.org>
	<CAGQxfVh5AMJnVr3i-Kc2jomzTFoug5r1u=KbJa1VX6b_jruT6A@mail.gmail.com>
Message-ID: <1437686798.2326.73.camel@gmail.com>

On Thu, 2015-07-23 at 14:09 +0000, H. Hirzel wrote:
> 1) and 2) sounds like there is a need for an Ubuntu type of approach.
> 
> Labelled releases at regular intervals -- could be semi-annually or
> annually. Some of them receive important bux fixes thus constituting
> Long Term Releases.
> 

LTS releases are a *lot* of work and add quite a bit of drag.
Back-porting can be as much work as forward-porting (sometimes more.)  I
was thinking we start off as streamlined as possible: when 4.3 is
released, it becomes the stable branch.  At some point 4.4 (or whatever
version # makes sense) is nearing release and there is some period of RC
status for it.  When 4.4 goes stable, 4.3 is retired an so on.  That way
we only have one stable release at a time to be concerned with.

Also on the subject of LTS, I think we want to be careful not to get
into a Debian mode of operation.  That results in extreme stability at
the price of glacially slow change.

> Or stable vs unstable branches in github.
> 
> In two days on the 25th of July it will be exactly 2 years after the
> last release of 4.2.   :-)
> 

It's safe to say 2 years is a bit long between stable releases while 3
months would probably be too short.  I like yearly, but every 6 months
works too.  Since there's probably going to be a period of something
along the lines of RC status (a week?  a month?  no idea...) you don't
want the releases too often or you're chewing up a lot of time preparing
and testing releases and people are complaining that releases are too
frequent.  But that's just me spit-balling... I'm fine with whatever
people prefer.

> A point to consider as well is that what Juan is doing constitutes a
> trunk from which releases are forked from time to time by other
> people. The ones who run Feature Tests ....
> 

How this gets implemented depends largely on Juan's preference.  I guess
the way I envisioned it is that most of the changes being made could go
directly to stable (i.e. they are *mostly* bug fixes and behind the
scenes improvements).  Unless I'm mistaken, no one is really complaining
that a change might temporarily break something as the fixes for those
is almost always quick to arrive and don't require changes on our end
(at least nothing that I can recall.)  This would be more about changes
that will break/alter the behavior of the public APIs (i.e. there's good
reason to expect code breakage), either that goes into a
development/alpha branch or could be managed similarly to how I
*believe* Juan is handling Morphic 3 (i.e. changesets/packages that
don't get applied to stable but rather batched up until they're ready
for release driven both by the development effort and release timing)

For example, the FileMan code is something that I would be fine having
introduced in the middle of a stable branch's lifecycle.  Just don't
'flip the switch' on it (i.e. breaking code compatibility from an API
standpoint) until the next major stable release when there is sufficient
notice and documentation for people to make the move.  For me, it's all
a question of 'will the change break my code?'  I rather like bug fixes,
new features, and workflow improvements enough that to the extent
possible these should be encouraged in stable.  Would that be too
aggressive for you?

> --Hannes
> 
> On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:
> > On 7/19/2015 9:39 PM, Phil (list) wrote:
> >> ...
> >> It really comes down to what is Cuis?  Is it:
> >>
> >> 1) a minimal Smalltalk that you play around with ideas / prototype
> >> something in the short to intermediate term
> >>
> >> 2) a platform that you can take that idea you were playing around with,
> >> and if it proves out, build something more substantial from for the
> >> longer term
> >>
> >> 3) a completely experimental environment.  Anything can change at any
> >> time.  Supporting 1 is doable but 2 is doubtful.
> >>
> >> Right now, Cuis is great at 1 but seems like it should be able to handle
> >> both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
> >> all, but who knows, others may disagree.  If others look at it
> >> differently, I'd love to know how you look at Cuis.
> >
> > I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that
> > way.
> >
> > Cheers,
> > Juan Vuletich
> >
> > _______________________________________________
> > 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 pbpublist at gmail.com  Thu Jul 23 17:09:02 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 23 Jul 2015 18:09:02 -0400
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
 checking them and Releases)
In-Reply-To: <55B1015A.2080109@jvuletich.org>
References: <55B1015A.2080109@jvuletich.org>
Message-ID: <1437689342.2326.88.camel@gmail.com>

On Thu, 2015-07-23 at 11:59 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> I've just re-read the very rich threads related to this. Thank you all 
> for thoughtful and valuable considerations and opinions. This mail 
> attempts to make really small summary, to start taking action.

My quick summary to your previous replies: I agree!  :-)

> 
> First, the easiest. Releases
> -------------------------------------
> Several of you see real value on doing a few named releases per year. 
> Theres' no big downside, so, let's do it. I think this is a good time to 
> do a release. So, I'll refrain to introduce any major changes, except 
> important bugfixes. Please start testing / updating / fixing your 
> packages and applications. When we are all happy, and we all agree that 
> the whole ecosystem is in a healthy state, we'll call that a release.
> 
> We need a name for this release. The obvious choice is "Cuis4.3-nnnn". 
> So, there might be a Cuis4.3-2456, and as that branch evolves, a 
> Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha" 
> updates of Cuis4.4. So, I guess #2459 would be (a potential risky 
> change) for Cuis 4.4. What if later we need to apply some patch to the 
> stable Cuis4.3? How would we name it?
> 

My .02 on how we might manage the different branches is in my latest
reply to Hannes.  If you're happy with the way you're managing Morphic
3, why not start with that approach?  Or you could use two git branches
and periodically merge fixes from stable into development while you're
working on it, then merge development back into stable for release... or
something like that.  I'll defer to what you think will work best for
your workflow here...

> After a bit of discussion, I can take action. Or you can volunteer for 
> Release Manager or member of the Release Team for Cuis 4.3.
> 

Consider me volunteered.  I'll be happy to help in whatever way I can...
how can I best do that?  

> Next, Documented, Public APIs
> -------------------------------------------
> 
> Use pragmas, like PubicAPI (some method we intend to support and keep in 
> that hierarchy), or CalledFromOutside (some method our yet-to-be-written 
> tool detects as called from another package). Write tools for analyzing 
> them. Do not remove them without due discussion.
> 
> It should be possible to write tests for existence of APIs.
> 
> This area is new to us, and we'll learn as we go.
> 

Yep.  Undiscovered Country and it will likely take a few iterations to
get to what makes sense.

> Anybody can take action here. Documenting APIs by hand, writing tools to 
> try to autogenerate them, writing tests that check for existence of 
> specific APIs, whatever you can come up with.
> 
> This sounds like a major strategic direction, and in a very early stage, 
> so maybe we'd not include anything of this in the Cuis4.3 release, but 
> make this the start of the Cuis4.4 effort.
> 

Agreed.  Besides, I don't think we'll have even version 1 of APIs ready
for 4.3. (because the stable API stuff will likely still be, umm...
unstable)

> Thoughts? Or feel free to start coding!
> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From Ken.Dickey at whidbey.com  Thu Jul 23 02:13:17 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Thu, 23 Jul 2015 15:13:17 +0800
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
 checking them and Releases)
In-Reply-To: <55B1015A.2080109@jvuletich.org>
References: <55B1015A.2080109@jvuletich.org>
Message-ID: <20150723151317.b0caaf647bf8aecf6ec1491b@whidbey.com>

On Thu, 23 Jul 2015 11:59:38 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> We need a name for this release. The obvious choice is "Cuis4.3-nnnn". 
> So, there might be a Cuis4.3-2456, and as that branch evolves, a 
> Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha" 
> updates of Cuis4.4. So, I guess #2459 would be (a potential risky 
> change) for Cuis 4.4. What if later we need to apply some patch to the 
> stable Cuis4.3? How would we name it?

How about a fork with the suffix "-stable" ?

E.g. "4.2-stable", "4.3-stable", ...  The revisions on these would be independent of the main development thread.  Only bugfixes and (rare) backports.

$0.02
-KenD



From Ken.Dickey at whidbey.com  Thu Jul 23 22:39:03 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Thu, 23 Jul 2015 20:39:03 -0700
Subject: [Cuis] Morph default position
Message-ID: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>

My panels lost their titles.

This was because the WindowTitleMorphs were created and added to the window without setting the morphPosition to 0 at 0, so they were at 50 at 50, way outside the viewport of the windows.

Not difficult to fix, but there is a tension between being required to set morphPosition when/before/during addMorph* method sends and only setting morphPosition when the default is not desired.

FYI,
-KenD



From pbpublist at gmail.com  Fri Jul 24 03:26:52 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 24 Jul 2015 04:26:52 -0400
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT
 version number
In-Reply-To: <55B0F0B2.6090202@jvuletich.org>
References: <55B0F0B2.6090202@jvuletich.org>
Message-ID: <1437726412.2326.290.camel@gmail.com>

Juan,

On Thu, 2015-07-23 at 10:48 -0300, Juan Vuletich wrote:
> Very small snip (while preparing an answer for the whole thread):
> 
> On 7/19/2015 9:39 PM, Phil (list) wrote:
> > ...
> > communicated.  However, a problem I think he faces right now is that he
> > doesn't know who's using / depending on what.
> > ...
> 
> Yes. Cuis is MIT, etc. You don't have any obligations, etc.
> 
> But, if you tell what are you using Cuis for, and how, that is very 
> useful (and nice to know).
> If you are maintaining a significant code base, if possible, tell about 
> it. This will help us better support you.
> 

(You wrote this first but I responded to it last... still couldn't get
it as short as I had hoped... :-)

Much of what I am currently doing in Cuis falls into the broad
categories of data processing, visualization/simulation and prototyping.

1) Data processing: Lots of importers and exporters.  The data I need is
all over the place both on my local filesystem/network as well as from
various Internet sources in just about every format you can imagine
whether it's munging some HTML if that's the only place I can find what
I need or processing some XML, SQLite, other text/binary data files (it
totally depends on the data source: whatever the source uses is what I'm
stuck with.  Additionally, I may need to emit a different format than I
took in.)  As a result, I've had to port a number of packages (some of
which I still maintain, others I've deprecated as things like FFI and
XML have become core Cuis packages) and write my own to support both
getting data into and back out of Cuis.  If all the task I'm doing
requires is data processing, this might be the end of the story: suck
the data in from whatever source/format, perform any needed processing,
and spit it back out to whatever destination/format.

2) Visualization/simulation: often I'm not just doing a simple data
conversion, so once the data is in Cuis I might need to do some analysis
to see what I'm dealing with, generate some charts/graphs, visualize
relationships within a data set or the results of a simulation, etc.
Sometimes it's tabular data, sometimes 2D image data, sometimes 3D,
sometimes temporal (tabular|2D|3D.) This is why I've got both Morphic
and OpenGL code lying around: for quick and easy 2D Morphic is hard to
beat, 3D and/or performance requirements push you to OpenGL.

3) Prototyping: most of the 'production' code I'm dealing with is in
other languages (Java for Android apps as an example). However, I find
non-dynamic languages unpleasant to prototype in.  So I find myself
quite often playing around with my ideas in Cuis even though the
implementation target might be a different language/environment.  This
is all over the place in terms of the 'what' (UI, networking, algorithm,
etc.)  Sometimes these prototypes often result in more code related to 1
and 2. Sometimes I decide that I could re-use whatever I was working on
in Cuis too, so I keep it.  Recently, I've started thinking a bit
differently about this one. (see 4)

1 and 2 almost always go together in some way.  3 is sometimes
standalone, but more and more it includes 1 and/or 2.  All together, I'd
estimate that the uses described above has resulted in about 100K LoC
across dozens of Cuis project files.  Lots of little things, depending
on lots of other little things.

An example of how this all fits together for me just using mostly core
Cuis packages for something you're probably quite familiar with:  I need
to do work on some SVG files.  No problem: XML parser can help there.
But they're out on a web site: easy, use Protocols-HTTP.  Parse the
file: now I depend on some of my framework code that depends on XML
parser since XML parser only deals with structure, not content.  Doh!
The SVG has embedded images: grab the compression and PNG support
(Graphics-File-Additional) packages.  Now the file is loaded and fully
parsed and you want to look at it: grab some Morphic code for that.
Need it to draw fast?  Use OpenGL + yet more framework code instead...
and OpenGL adds an FFI dependency.  So you've now got basic SVG support
with 8 packages and are ready to start doing the actual work which will
require additional packages.  This is both probably not impressive as it
might sound (it's only a subset of SVG, structured in a particular way)
and somewhat oversimplified (uses some custom extensions) but you get
the idea.  It's pretty clean and modular and things can pretty quickly
touch a couple dozen packages for a single task.  Most of my stuff is a
lot of this sort of thing. (i.e. a fair bit of work just to get the data
into a usable internal format. Once in, life gets easier until it's time
to export...)

Some future plans/projects:

4) As a result of spending more time with OMeta, I'm becoming convinced
that I can increase my usage beyond what I describe in 3: design and
build a prototype in Cuis and actually emit the code for the target
platform/environment.  With OMeta, code becomes just another data
source / target so why not? (minor detail of frameworks that I make
hand-wavy motions when reminded of... )  This is on my longer term wish
list and seems doable, it's just a lot of work to get there.  For things
like OpenGL/GPU compute it's looking to be a necessity.  For other
platform targets the payoff is less certain but this is interesting
enough that I don't care... I'll probably try to do it regardless of
whether or not it turns out to be a good idea :-)

5) For web apps, I've been finding Seaside quite nice to work with and
have been steadily increasing the things I'm using it for over the last
couple of years.  While this isn't yet Cuis related, it seems like there
are enough of us interested in something like this that at some point
we'll either figure out how to get Seaside ported or come up with
another solution.  At that point, Cuis will have permeated just about
every aspect of my development life :-)

> It is nice to know to what extent something you do is useful for others. 
> I think it is also a polite and reasonable way to say thanks to us, 
> working for you.
> 

Absolutely.  That's also part of the reason I publish the packages I've
needed to port.  Life would have been so much simpler if someone had
taken care of that part so I didn't have to.  So, I push them out in the
hopes that it might save someone the trouble of having to deal with it
just as all of your efforts and others who have contributed to Cuis have
made my life easier.

> Cheers,
> Juan Vuletich

Thanks,
Phil




From pbpublist at gmail.com  Fri Jul 24 05:23:46 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 24 Jul 2015 06:23:46 -0400
Subject: [Cuis] Morph default position
In-Reply-To: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
References: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
Message-ID: <1437733426.2326.295.camel@gmail.com>

On Thu, 2015-07-23 at 20:39 -0700, Ken.Dickey wrote:
> My panels lost their titles.
> 
> This was because the WindowTitleMorphs were created and added to the window without setting the morphPosition to 0 at 0, so they were at 50 at 50, way outside the viewport of the windows.
> 
> Not difficult to fix, but there is a tension between being required to set morphPosition when/before/during addMorph* method sends and only setting morphPosition when the default is not desired.
> 

Insetting Morphs seemed like such a harmless suggestion...

> FYI,
> -KenD
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Fri Jul 24 07:00:12 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 24 Jul 2015 09:00:12 -0300
Subject: [Cuis] Morph default position
In-Reply-To: <1437733426.2326.295.camel@gmail.com>
References: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
	<1437733426.2326.295.camel@gmail.com>
Message-ID: <55B228CC.6000102@jvuletich.org>

Hi Folks,

On 7/24/2015 7:23 AM, Phil (list) wrote:
> On Thu, 2015-07-23 at 20:39 -0700, Ken.Dickey wrote:
>> My panels lost their titles.
>>
>> This was because the WindowTitleMorphs were created and added to the window without setting the morphPosition to 0 at 0, so they were at 50 at 50, way outside the viewport of the windows.
>>
>> Not difficult to fix, but there is a tension between being required to set morphPosition when/before/during addMorph* method sends and only setting morphPosition when the default is not desired.
>>
> Insetting Morphs seemed like such a harmless suggestion...

Uh, apologies. I also thought it would harmless. I'll take back that 
change, and set an offset only when adding to World.

Regards,
Juan Vuletich



From hannes.hirzel at gmail.com  Fri Jul 24 08:56:04 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Fri, 24 Jul 2015 13:56:04 +0000
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
 checking them and Releases)
In-Reply-To: <55B1015A.2080109@jvuletich.org>
References: <55B1015A.2080109@jvuletich.org>
Message-ID: <CAGQxfVgvt5b8AqF+se1mKrkwptFSSYFq3hOdxivuf1x=DvN8RA@mail.gmail.com>

On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:

Thanks for this summary, I think it captures what we have discussed.

Two comments below

--Hannes

> Hi Folks,
>
> I've just re-read the very rich threads related to this. Thank you all
> for thoughtful and valuable considerations and opinions. This mail
> attempts to make really small summary, to start taking action.
>
> First, the easiest. Releases
> -------------------------------------
> Several of you see real value on doing a few named releases per year.
> Theres' no big downside, so, let's do it. I think this is a good time to
> do a release. So, I'll refrain to introduce any major changes, except
> important bugfixes. Please start testing / updating / fixing your
> packages and applications. When we are all happy, and we all agree that
> the whole ecosystem is in a healthy state, we'll call that a release.
>
> We need a name for this release. The obvious choice is "Cuis4.3-nnnn".
> So, there might be a Cuis4.3-2456, and as that branch evolves, a
> Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha"
> updates of Cuis4.4. So, I guess #2459 would be (a potential risky
> change) for Cuis 4.4. What if later we need to apply some patch to the
> stable Cuis4.3? How would we name it?
>
> After a bit of discussion, I can take action. Or you can volunteer for
> Release Manager or member of the Release Team for Cuis 4.3.

A suggestion: label the version of tomorrow as Cuis 4.3

and then have a period (4...8 weeks?) where only bug fixes are allowed
and then release a version Cuis 4.4


Cuis 4.3 would then be what KenD calls a 'baseline' to measure against
until we have 4.4

>
> Next, Documented, Public APIs
> -------------------------------------------
>
> Use pragmas, like PubicAPI (some method we intend to support and keep in
> that hierarchy), or CalledFromOutside (some method our yet-to-be-written
> tool detects as called from another package). Write tools for analyzing
> them. Do not remove them without due discussion.
>
> It should be possible to write tests for existence of APIs.
>
> This area is new to us, and we'll learn as we go.
>
> Anybody can take action here. Documenting APIs by hand, writing tools to
> try to autogenerate them, writing tests that check for existence of
> specific APIs, whatever you can come up with.
>
> This sounds like a major strategic direction, and in a very early stage,
> so maybe we'd not include anything of this in the Cuis4.3 release, but
> make this the start of the Cuis4.4 effort.
>
> Thoughts? Or feel free to start coding!

I think we should start coding with FeatureTests which check for the
presence of classes and methods.

As independent packages in various repositories, after some
evaluation/testing/checking they should go to the packages folder.

> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From Ken.Dickey at whidbey.com  Fri Jul 24 09:10:02 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 24 Jul 2015 07:10:02 -0700
Subject: [Cuis] Morph default position
In-Reply-To: <55B228CC.6000102@jvuletich.org>
References: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
	<1437733426.2326.295.camel@gmail.com>
	<55B228CC.6000102@jvuletich.org>
Message-ID: <20150724071002.1a76620f39adb183005b4715@whidbey.com>

On Fri, 24 Jul 2015 09:00:12 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Uh, apologies. I also thought it would harmless. I'll take back that 
> change, and set an offset only when adding to World.

Or just add 
 Morph>>defaultPosition
	^ 50 at 50

And let subclasses override when it makes a difference..

$0.02
-KenD



From dnorton at mindspring.com  Fri Jul 24 15:20:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 24 Jul 2015 16:20:35 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AD7737.30003@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>,
	<55AD7737.30003@jvuletich.org>
Message-ID: <55B29E13.29241.F06B25@dnorton.mindspring.com>

On 20 Jul 2015 at 19:33, Juan Vuletich wrote:

> 
> Hi Dan,
> 
> On 7/19/2015 10:13 PM, Dan Norton wrote:
>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
> 
>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>     > >
>     > >> Hi Folks,
>     > >>
>     > >> It is not too hard to build new StrikeFonts. You need to
> build,
>     > by
>     > >> hand,
>     > >> files like the ones in here:
>     > >>
>     >
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>     > >> p
>     > >> and learn a bit about stuff like #installDejaVu2 . Maybe it
> was
>     > with
>     > >> this method and the files in this zip that built the
> existing
>     > >> instances
>     > >> of StrikeFont. Not sure.
>     > >>
>     > > That's intrigueing but I can't reproduce it. Maybe the .bmp
> but
>     > where did you get the .txt?
>     > >
>     > >?? - Dan
>     >
>     > I wrote them with a text editor. Check #installDejaVu2 and
> really
>     > try to
>     > understand how StrikeFonts work and how they are built with
> this
>     > method.
>     > Maybe you'll become enlightened.
>     >
> 
>     A StrikeFont consists of a characterToGlyphMap, xTable, glyphs,
> name, and several 
>     scalars. StrikeFont class methods create fonts by processing
> file pairs assumed to be in the 
>     "AAFonts" subdirectory. For example:
> 
>     DejaVu Sans Oblique 14.bmp
>     DejaVu Sans Oblique 14.txt
> 
>     Is one such pair providing the italic (oblique) style for
> 14-point size. There is a pair for every 
>     font size and style: base, bold, italic, and bold italic.
> Therefore a font such as "DejaVu Sans" 
>     which is available in the size interval 5 to 24 requires 160
> files. The file names are stylized 
>     and encoded in the StrikeFont class methods.
> 
>     Glyphs come from the .bmp file. The .txt file is a string of
> numbers; the first three specify 
>     pointSize, ascent, and?descent. The rest of the numbers in the
> .txt file are used to form the 
>     xTable, which is the index into the glyphs for a character. The
> characterToGlyphMap is an 
>     array of 256 entries which map a character's ascii value to the
> xTable and thence to the 
>     glyphs.
> 
>     The bold, italic, and bold italic styles are stashed as
> derivatives of the base and not 
>     selectable from the current menus.
> 
>     StrikeFont is a subclass of AbstractFont, which has class
> variables AvailableFonts and 
>     DefaultFont.
> 
>     If it can't find a file, StrikeFont will loop.
> 
> Great! You got it all.
> 
>     In regard to creating the .bmp and .txt files, you say, " I
> wrote them with a text editor." 
>     Please tell me which text editor you used. None of mine do
> that.
> 
> The bmp files can be created with screen capture program, after
> entering suitable text in it. Maybe 
> you need to stitch several pieces together, etc. WRT the txt files,
> well, the editor didn't do it for 
> me. I wrote them. I _typed_ them. Maybe I used some (long lost) code
> to look for white columns 
> separating glyphs, but I'm not really sure. #xTallyPixelValue:orNot:
> and friends are great for this 
> kind of stuff.
> 
> In any case, it will be easier for you, as you want a monospaced
> font. Printing something like (32 
> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might be
> enough.
> 
> You have all the pieces at hand. it just requires a bit of
> patience.
> 

Encouraged by this, I have tried cobbling a fixed-width StrikeFont from Courier New which 
comes with Windows7. At this point, if some kind of fixed-width smudges would appear then 
it would be progress. Here's where I am:

The immediate problem is an error: 'Unsupported format. Try 
"Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter 
class>>formFromStream: examines the .bmp file.

Higher in the context, Form class>>fromBinaryStream: has firstByte = 66 which I mention 
because of the way the .bmp file was made. Here is the process I used, from the bottom up:

ImageMagick freeware	 produces the glyphs but with something stubbornly prepended. The 
command line is:
	convert -font \windows\fonts\cour.ttf -pointsize 12 label:@characters.txt 
courier12.bmp

Using NotePad, save characters.txt with encoding: UTF-8.

Paste the character string onto a NotePad

Copy the character string.

In a Cuis workspace print:
	str := String new writeStream.
	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
	str contents.

Code package and files allegedly for courier strike fonts are attached if you're 
interested.

 - Dan
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150724/bf929021/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CourierExample.zip
Type: application/zip
Size: 25150 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150724/bf929021/attachment-0002.zip>

From hannes.hirzel at gmail.com  Sat Jul 25 08:00:45 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 25 Jul 2015 13:00:45 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B29E13.29241.F06B25@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
	<55AD7737.30003@jvuletich.org>
	<55B29E13.29241.F06B25@dnorton.mindspring.com>
Message-ID: <CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>

I would try to save the *.bmp file as a *.gif file in Microsoft Paint
and then try to load it with

ImageReadWriter class>>formFromStream:

HTH

--HH

On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
>
>>
>> Hi Dan,
>>
>> On 7/19/2015 10:13 PM, Dan Norton wrote:
>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>>
>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>>     > >
>>     > >> Hi Folks,
>>     > >>
>>     > >> It is not too hard to build new StrikeFonts. You need to
>> build,
>>     > by
>>     > >> hand,
>>     > >> files like the ones in here:
>>     > >>
>>     >
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>>     > >> p
>>     > >> and learn a bit about stuff like #installDejaVu2 . Maybe it
>> was
>>     > with
>>     > >> this method and the files in this zip that built the
>> existing
>>     > >> instances
>>     > >> of StrikeFont. Not sure.
>>     > >>
>>     > > That's intrigueing but I can't reproduce it. Maybe the .bmp
>> but
>>     > where did you get the .txt?
>>     > >
>>     > >?? - Dan
>>     >
>>     > I wrote them with a text editor. Check #installDejaVu2 and
>> really
>>     > try to
>>     > understand how StrikeFonts work and how they are built with
>> this
>>     > method.
>>     > Maybe you'll become enlightened.
>>     >
>>
>>     A StrikeFont consists of a characterToGlyphMap, xTable, glyphs,
>> name, and several
>>     scalars. StrikeFont class methods create fonts by processing
>> file pairs assumed to be in the
>>     "AAFonts" subdirectory. For example:
>>
>>     DejaVu Sans Oblique 14.bmp
>>     DejaVu Sans Oblique 14.txt
>>
>>     Is one such pair providing the italic (oblique) style for
>> 14-point size. There is a pair for every
>>     font size and style: base, bold, italic, and bold italic.
>> Therefore a font such as "DejaVu Sans"
>>     which is available in the size interval 5 to 24 requires 160
>> files. The file names are stylized
>>     and encoded in the StrikeFont class methods.
>>
>>     Glyphs come from the .bmp file. The .txt file is a string of
>> numbers; the first three specify
>>     pointSize, ascent, and?descent. The rest of the numbers in the
>> .txt file are used to form the
>>     xTable, which is the index into the glyphs for a character. The
>> characterToGlyphMap is an
>>     array of 256 entries which map a character's ascii value to the
>> xTable and thence to the
>>     glyphs.
>>
>>     The bold, italic, and bold italic styles are stashed as
>> derivatives of the base and not
>>     selectable from the current menus.
>>
>>     StrikeFont is a subclass of AbstractFont, which has class
>> variables AvailableFonts and
>>     DefaultFont.
>>
>>     If it can't find a file, StrikeFont will loop.
>>
>> Great! You got it all.
>>
>>     In regard to creating the .bmp and .txt files, you say, " I
>> wrote them with a text editor."
>>     Please tell me which text editor you used. None of mine do
>> that.
>>
>> The bmp files can be created with screen capture program, after
>> entering suitable text in it. Maybe
>> you need to stitch several pieces together, etc. WRT the txt files,
>> well, the editor didn't do it for
>> me. I wrote them. I _typed_ them. Maybe I used some (long lost) code
>> to look for white columns
>> separating glyphs, but I'm not really sure. #xTallyPixelValue:orNot:
>> and friends are great for this
>> kind of stuff.
>>
>> In any case, it will be easier for you, as you want a monospaced
>> font. Printing something like (32
>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might be
>> enough.
>>
>> You have all the pieces at hand. it just requires a bit of
>> patience.
>>
>
> Encouraged by this, I have tried cobbling a fixed-width StrikeFont from
> Courier New which
> comes with Windows7. At this point, if some kind of fixed-width smudges
> would appear then
> it would be progress. Here's where I am:
>
> The immediate problem is an error: 'Unsupported format. Try
> "Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter
> class>>formFromStream: examines the .bmp file.
>
> Higher in the context, Form class>>fromBinaryStream: has firstByte = 66
> which I mention
> because of the way the .bmp file was made. Here is the process I used, from
> the bottom up:
>
> ImageMagick freeware	 produces the glyphs but with something stubbornly
> prepended. The
> command line is:
> 	convert -font \windows\fonts\cour.ttf -pointsize 12 label:@characters.txt
> courier12.bmp
>
> Using NotePad, save characters.txt with encoding: UTF-8.
>
> Paste the character string onto a NotePad
>
> Copy the character string.
>
> In a Cuis workspace print:
> 	str := String new writeStream.
> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
> 	str contents.
>
> Code package and files allegedly for courier strike fonts are attached if
> you're
> interested.
>
>  - Dan
>
>



From hannes.hirzel at gmail.com  Sat Jul 25 08:14:38 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 25 Jul 2015 13:14:38 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
	<55AD7737.30003@jvuletich.org>
	<55B29E13.29241.F06B25@dnorton.mindspring.com>
	<CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>
Message-ID: <CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>

I did the StrikeFont exercises in Squeak. So it could be that Squeak
has a BMP file reader which is no longer included in Cuis. A thing to
check....

--HH

On 7/25/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> I would try to save the *.bmp file as a *.gif file in Microsoft Paint
> and then try to load it with
>
> ImageReadWriter class>>formFromStream:
>
> HTH
>
> --HH
>
> On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
>> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
>>
>>>
>>> Hi Dan,
>>>
>>> On 7/19/2015 10:13 PM, Dan Norton wrote:
>>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>>>
>>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>>>     > >
>>>     > >> Hi Folks,
>>>     > >>
>>>     > >> It is not too hard to build new StrikeFonts. You need to
>>> build,
>>>     > by
>>>     > >> hand,
>>>     > >> files like the ones in here:
>>>     > >>
>>>     >
>>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>>>     > >> p
>>>     > >> and learn a bit about stuff like #installDejaVu2 . Maybe it
>>> was
>>>     > with
>>>     > >> this method and the files in this zip that built the
>>> existing
>>>     > >> instances
>>>     > >> of StrikeFont. Not sure.
>>>     > >>
>>>     > > That's intrigueing but I can't reproduce it. Maybe the .bmp
>>> but
>>>     > where did you get the .txt?
>>>     > >
>>>     > >?? - Dan
>>>     >
>>>     > I wrote them with a text editor. Check #installDejaVu2 and
>>> really
>>>     > try to
>>>     > understand how StrikeFonts work and how they are built with
>>> this
>>>     > method.
>>>     > Maybe you'll become enlightened.
>>>     >
>>>
>>>     A StrikeFont consists of a characterToGlyphMap, xTable, glyphs,
>>> name, and several
>>>     scalars. StrikeFont class methods create fonts by processing
>>> file pairs assumed to be in the
>>>     "AAFonts" subdirectory. For example:
>>>
>>>     DejaVu Sans Oblique 14.bmp
>>>     DejaVu Sans Oblique 14.txt
>>>
>>>     Is one such pair providing the italic (oblique) style for
>>> 14-point size. There is a pair for every
>>>     font size and style: base, bold, italic, and bold italic.
>>> Therefore a font such as "DejaVu Sans"
>>>     which is available in the size interval 5 to 24 requires 160
>>> files. The file names are stylized
>>>     and encoded in the StrikeFont class methods.
>>>
>>>     Glyphs come from the .bmp file. The .txt file is a string of
>>> numbers; the first three specify
>>>     pointSize, ascent, and?descent. The rest of the numbers in the
>>> .txt file are used to form the
>>>     xTable, which is the index into the glyphs for a character. The
>>> characterToGlyphMap is an
>>>     array of 256 entries which map a character's ascii value to the
>>> xTable and thence to the
>>>     glyphs.
>>>
>>>     The bold, italic, and bold italic styles are stashed as
>>> derivatives of the base and not
>>>     selectable from the current menus.
>>>
>>>     StrikeFont is a subclass of AbstractFont, which has class
>>> variables AvailableFonts and
>>>     DefaultFont.
>>>
>>>     If it can't find a file, StrikeFont will loop.
>>>
>>> Great! You got it all.
>>>
>>>     In regard to creating the .bmp and .txt files, you say, " I
>>> wrote them with a text editor."
>>>     Please tell me which text editor you used. None of mine do
>>> that.
>>>
>>> The bmp files can be created with screen capture program, after
>>> entering suitable text in it. Maybe
>>> you need to stitch several pieces together, etc. WRT the txt files,
>>> well, the editor didn't do it for
>>> me. I wrote them. I _typed_ them. Maybe I used some (long lost) code
>>> to look for white columns
>>> separating glyphs, but I'm not really sure. #xTallyPixelValue:orNot:
>>> and friends are great for this
>>> kind of stuff.
>>>
>>> In any case, it will be easier for you, as you want a monospaced
>>> font. Printing something like (32
>>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might be
>>> enough.
>>>
>>> You have all the pieces at hand. it just requires a bit of
>>> patience.
>>>
>>
>> Encouraged by this, I have tried cobbling a fixed-width StrikeFont from
>> Courier New which
>> comes with Windows7. At this point, if some kind of fixed-width smudges
>> would appear then
>> it would be progress. Here's where I am:
>>
>> The immediate problem is an error: 'Unsupported format. Try
>> "Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter
>> class>>formFromStream: examines the .bmp file.
>>
>> Higher in the context, Form class>>fromBinaryStream: has firstByte = 66
>> which I mention
>> because of the way the .bmp file was made. Here is the process I used,
>> from
>> the bottom up:
>>
>> ImageMagick freeware	 produces the glyphs but with something stubbornly
>> prepended. The
>> command line is:
>> 	convert -font \windows\fonts\cour.ttf -pointsize 12
>> label:@characters.txt
>> courier12.bmp
>>
>> Using NotePad, save characters.txt with encoding: UTF-8.
>>
>> Paste the character string onto a NotePad
>>
>> Copy the character string.
>>
>> In a Cuis workspace print:
>> 	str := String new writeStream.
>> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
>> 	str contents.
>>
>> Code package and files allegedly for courier strike fonts are attached if
>> you're
>> interested.
>>
>>  - Dan
>>
>>
>



From dnorton at mindspring.com  Sat Jul 25 10:40:19 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 25 Jul 2015 11:40:19 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>,
	<CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>
Message-ID: <55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>

Form class>>fromBinaryStream: has firstByte = 66, this is not an error but part of "BM" in the header of the .bmp file.

The "Unsupported format..." error is caused by Cuis wanting biSize = 40 and ImageMagick 
putting a different value.

Squeak has BitstreamVeraSansMono, a fixed-width font. Why couldn't  that be used to 
produce .bmp files instead of ImageMagick? The BM header would be compatible with Cuis 
AFAIKT and it might get us a fixed-width font on Cuis.

On 25 Jul 2015 at 13:14, H. Hirzel wrote:

> I did the StrikeFont exercises in Squeak. So it could be that
> Squeak
> has a BMP file reader which is no longer included in Cuis. A thing
> to
> check....
> 
> --HH
> 
> On 7/25/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > I would try to save the *.bmp file as a *.gif file in Microsoft
> Paint
> > and then try to load it with
> >
> > ImageReadWriter class>>formFromStream:
> >
> > HTH
> >
> > --HH
> >
> > On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
> >> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
> >>
> >>>
> >>> Hi Dan,
> >>>
> >>> On 7/19/2015 10:13 PM, Dan Norton wrote:
> >>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
> >>>
> >>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
> >>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
> >>>     > >
> >>>     > >> Hi Folks,
> >>>     > >>
> >>>     > >> It is not too hard to build new StrikeFonts. You need
> to
> >>> build,
> >>>     > by
> >>>     > >> hand,
> >>>     > >> files like the ones in here:
> >>>     > >>
> >>>     >
> >>>
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> >>>     > >> p
> >>>     > >> and learn a bit about stuff like #installDejaVu2 .
> Maybe it
> >>> was
> >>>     > with
> >>>     > >> this method and the files in this zip that built the
> >>> existing
> >>>     > >> instances
> >>>     > >> of StrikeFont. Not sure.
> >>>     > >>
> >>>     > > That's intrigueing but I can't reproduce it. Maybe the
> .bmp
> >>> but
> >>>     > where did you get the .txt?
> >>>     > >
> >>>     > >?? - Dan
> >>>     >
> >>>     > I wrote them with a text editor. Check #installDejaVu2
> and
> >>> really
> >>>     > try to
> >>>     > understand how StrikeFonts work and how they are built
> with
> >>> this
> >>>     > method.
> >>>     > Maybe you'll become enlightened.
> >>>     >
> >>>
> >>>     A StrikeFont consists of a characterToGlyphMap, xTable,
> glyphs,
> >>> name, and several
> >>>     scalars. StrikeFont class methods create fonts by
> processing
> >>> file pairs assumed to be in the
> >>>     "AAFonts" subdirectory. For example:
> >>>
> >>>     DejaVu Sans Oblique 14.bmp
> >>>     DejaVu Sans Oblique 14.txt
> >>>
> >>>     Is one such pair providing the italic (oblique) style for
> >>> 14-point size. There is a pair for every
> >>>     font size and style: base, bold, italic, and bold italic.
> >>> Therefore a font such as "DejaVu Sans"
> >>>     which is available in the size interval 5 to 24 requires
> 160
> >>> files. The file names are stylized
> >>>     and encoded in the StrikeFont class methods.
> >>>
> >>>     Glyphs come from the .bmp file. The .txt file is a string
> of
> >>> numbers; the first three specify
> >>>     pointSize, ascent, and?descent. The rest of the numbers in
> the
> >>> .txt file are used to form the
> >>>     xTable, which is the index into the glyphs for a character.
> The
> >>> characterToGlyphMap is an
> >>>     array of 256 entries which map a character's ascii value to
> the
> >>> xTable and thence to the
> >>>     glyphs.
> >>>
> >>>     The bold, italic, and bold italic styles are stashed as
> >>> derivatives of the base and not
> >>>     selectable from the current menus.
> >>>
> >>>     StrikeFont is a subclass of AbstractFont, which has class
> >>> variables AvailableFonts and
> >>>     DefaultFont.
> >>>
> >>>     If it can't find a file, StrikeFont will loop.
> >>>
> >>> Great! You got it all.
> >>>
> >>>     In regard to creating the .bmp and .txt files, you say, "
> I
> >>> wrote them with a text editor."
> >>>     Please tell me which text editor you used. None of mine do
> >>> that.
> >>>
> >>> The bmp files can be created with screen capture program,
> after
> >>> entering suitable text in it. Maybe
> >>> you need to stitch several pieces together, etc. WRT the txt
> files,
> >>> well, the editor didn't do it for
> >>> me. I wrote them. I _typed_ them. Maybe I used some (long lost)
> code
> >>> to look for white columns
> >>> separating glyphs, but I'm not really sure.
> #xTallyPixelValue:orNot:
> >>> and friends are great for this
> >>> kind of stuff.
> >>>
> >>> In any case, it will be easier for you, as you want a
> monospaced
> >>> font. Printing something like (32
> >>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might
> be
> >>> enough.
> >>>
> >>> You have all the pieces at hand. it just requires a bit of
> >>> patience.
> >>>
> >>
> >> Encouraged by this, I have tried cobbling a fixed-width
> StrikeFont from
> >> Courier New which
> >> comes with Windows7. At this point, if some kind of fixed-width
> smudges
> >> would appear then
> >> it would be progress. Here's where I am:
> >>
> >> The immediate problem is an error: 'Unsupported format. Try
> >> "Graphics-Files-Additional.pck.st".' which arises when
> ImageReadWriter
> >> class>>formFromStream: examines the .bmp file.
> >>
> >> Higher in the context, Form class>>fromBinaryStream: has
> firstByte = 66
> >> which I mention
> >> because of the way the .bmp file was made. Here is the process I
> used,
> >> from
> >> the bottom up:
> >>
> >> ImageMagick freeware	 produces the glyphs but with something
> stubbornly
> >> prepended. The
> >> command line is:
> >> 	convert -font \windows\fonts\cour.ttf -pointsize 12
> >> label:@characters.txt
> >> courier12.bmp
> >>
> >> Using NotePad, save characters.txt with encoding: UTF-8.
> >>
> >> Paste the character string onto a NotePad
> >>
> >> Copy the character string.
> >>
> >> In a Cuis workspace print:
> >> 	str := String new writeStream.
> >> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
> >> 	str contents.
> >>
> >> Code package and files allegedly for courier strike fonts are
> attached if
> >> you're
> >> interested.
> >>
> >>  - Dan
> >>
> >>
> >
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From hannes.hirzel at gmail.com  Sat Jul 25 13:57:43 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 25 Jul 2015 18:57:43 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>
	<CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>
	<55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>
Message-ID: <CAGQxfVggp67RO7k4q8Cgh4thyi4AQTWpvwVSapXMb=LTrR3eqQ@mail.gmail.com>

Then I would try to export the Squeak BitstreamVeraSansMono in
StrikeFont format and import into Cuis. That should work ...

On 7/25/15, Dan Norton <dnorton at mindspring.com> wrote:
> Form class>>fromBinaryStream: has firstByte = 66, this is not an error but
> part of "BM" in the header of the .bmp file.
>
> The "Unsupported format..." error is caused by Cuis wanting biSize = 40 and
> ImageMagick
> putting a different value.
>
> Squeak has BitstreamVeraSansMono, a fixed-width font. Why couldn't  that be
> used to
> produce .bmp files instead of ImageMagick? The BM header would be compatible
> with Cuis
> AFAIKT and it might get us a fixed-width font on Cuis.
>
> On 25 Jul 2015 at 13:14, H. Hirzel wrote:
>
>> I did the StrikeFont exercises in Squeak. So it could be that
>> Squeak
>> has a BMP file reader which is no longer included in Cuis. A thing
>> to
>> check....
>>
>> --HH
>>
>> On 7/25/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> > I would try to save the *.bmp file as a *.gif file in Microsoft
>> Paint
>> > and then try to load it with
>> >
>> > ImageReadWriter class>>formFromStream:
>> >
>> > HTH
>> >
>> > --HH
>> >
>> > On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
>> >> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
>> >>
>> >>>
>> >>> Hi Dan,
>> >>>
>> >>> On 7/19/2015 10:13 PM, Dan Norton wrote:
>> >>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>> >>>
>> >>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>> >>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>> >>>     > >
>> >>>     > >> Hi Folks,
>> >>>     > >>
>> >>>     > >> It is not too hard to build new StrikeFonts. You need
>> to
>> >>> build,
>> >>>     > by
>> >>>     > >> hand,
>> >>>     > >> files like the ones in here:
>> >>>     > >>
>> >>>     >
>> >>>
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> >>>     > >> p
>> >>>     > >> and learn a bit about stuff like #installDejaVu2 .
>> Maybe it
>> >>> was
>> >>>     > with
>> >>>     > >> this method and the files in this zip that built the
>> >>> existing
>> >>>     > >> instances
>> >>>     > >> of StrikeFont. Not sure.
>> >>>     > >>
>> >>>     > > That's intrigueing but I can't reproduce it. Maybe the
>> .bmp
>> >>> but
>> >>>     > where did you get the .txt?
>> >>>     > >
>> >>>     > >?? - Dan
>> >>>     >
>> >>>     > I wrote them with a text editor. Check #installDejaVu2
>> and
>> >>> really
>> >>>     > try to
>> >>>     > understand how StrikeFonts work and how they are built
>> with
>> >>> this
>> >>>     > method.
>> >>>     > Maybe you'll become enlightened.
>> >>>     >
>> >>>
>> >>>     A StrikeFont consists of a characterToGlyphMap, xTable,
>> glyphs,
>> >>> name, and several
>> >>>     scalars. StrikeFont class methods create fonts by
>> processing
>> >>> file pairs assumed to be in the
>> >>>     "AAFonts" subdirectory. For example:
>> >>>
>> >>>     DejaVu Sans Oblique 14.bmp
>> >>>     DejaVu Sans Oblique 14.txt
>> >>>
>> >>>     Is one such pair providing the italic (oblique) style for
>> >>> 14-point size. There is a pair for every
>> >>>     font size and style: base, bold, italic, and bold italic.
>> >>> Therefore a font such as "DejaVu Sans"
>> >>>     which is available in the size interval 5 to 24 requires
>> 160
>> >>> files. The file names are stylized
>> >>>     and encoded in the StrikeFont class methods.
>> >>>
>> >>>     Glyphs come from the .bmp file. The .txt file is a string
>> of
>> >>> numbers; the first three specify
>> >>>     pointSize, ascent, and?descent. The rest of the numbers in
>> the
>> >>> .txt file are used to form the
>> >>>     xTable, which is the index into the glyphs for a character.
>> The
>> >>> characterToGlyphMap is an
>> >>>     array of 256 entries which map a character's ascii value to
>> the
>> >>> xTable and thence to the
>> >>>     glyphs.
>> >>>
>> >>>     The bold, italic, and bold italic styles are stashed as
>> >>> derivatives of the base and not
>> >>>     selectable from the current menus.
>> >>>
>> >>>     StrikeFont is a subclass of AbstractFont, which has class
>> >>> variables AvailableFonts and
>> >>>     DefaultFont.
>> >>>
>> >>>     If it can't find a file, StrikeFont will loop.
>> >>>
>> >>> Great! You got it all.
>> >>>
>> >>>     In regard to creating the .bmp and .txt files, you say, "
>> I
>> >>> wrote them with a text editor."
>> >>>     Please tell me which text editor you used. None of mine do
>> >>> that.
>> >>>
>> >>> The bmp files can be created with screen capture program,
>> after
>> >>> entering suitable text in it. Maybe
>> >>> you need to stitch several pieces together, etc. WRT the txt
>> files,
>> >>> well, the editor didn't do it for
>> >>> me. I wrote them. I _typed_ them. Maybe I used some (long lost)
>> code
>> >>> to look for white columns
>> >>> separating glyphs, but I'm not really sure.
>> #xTallyPixelValue:orNot:
>> >>> and friends are great for this
>> >>> kind of stuff.
>> >>>
>> >>> In any case, it will be easier for you, as you want a
>> monospaced
>> >>> font. Printing something like (32
>> >>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might
>> be
>> >>> enough.
>> >>>
>> >>> You have all the pieces at hand. it just requires a bit of
>> >>> patience.
>> >>>
>> >>
>> >> Encouraged by this, I have tried cobbling a fixed-width
>> StrikeFont from
>> >> Courier New which
>> >> comes with Windows7. At this point, if some kind of fixed-width
>> smudges
>> >> would appear then
>> >> it would be progress. Here's where I am:
>> >>
>> >> The immediate problem is an error: 'Unsupported format. Try
>> >> "Graphics-Files-Additional.pck.st".' which arises when
>> ImageReadWriter
>> >> class>>formFromStream: examines the .bmp file.
>> >>
>> >> Higher in the context, Form class>>fromBinaryStream: has
>> firstByte = 66
>> >> which I mention
>> >> because of the way the .bmp file was made. Here is the process I
>> used,
>> >> from
>> >> the bottom up:
>> >>
>> >> ImageMagick freeware	 produces the glyphs but with something
>> stubbornly
>> >> prepended. The
>> >> command line is:
>> >> 	convert -font \windows\fonts\cour.ttf -pointsize 12
>> >> label:@characters.txt
>> >> courier12.bmp
>> >>
>> >> Using NotePad, save characters.txt with encoding: UTF-8.
>> >>
>> >> Paste the character string onto a NotePad
>> >>
>> >> Copy the character string.
>> >>
>> >> In a Cuis workspace print:
>> >> 	str := String new writeStream.
>> >> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
>> >> 	str contents.
>> >>
>> >> Code package and files allegedly for courier strike fonts are
>> attached if
>> >> you're
>> >> interested.
>> >>
>> >>  - Dan
>> >>
>> >>
>> >
>>
>> _______________________________________________
>> 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 dnorton at mindspring.com  Sat Jul 25 14:34:34 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 25 Jul 2015 15:34:34 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVggp67RO7k4q8Cgh4thyi4AQTWpvwVSapXMb=LTrR3eqQ@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>,
	<CAGQxfVggp67RO7k4q8Cgh4thyi4AQTWpvwVSapXMb=LTrR3eqQ@mail.gmail.com>
Message-ID: <55B3E4CA.22470.194F1C5@dnorton.mindspring.com>

On 25 Jul 2015 at 18:57, H. Hirzel wrote:

> Then I would try to export the Squeak BitstreamVeraSansMono in
> StrikeFont format and import into Cuis. That should work ...
>

Yes, but the problem is how to get BitstreamVeraSansMono into StrikeFont format.

In Squeak 4.6, the font of a character string in the transcript can be changed from the default 
to one of the BitstreamVeraSansMono sizes: #(9 12 15 24 36). Digging down through the 
Transcript submorphs I found aTextMorphForEditView. When this is sent 
"exportAsBMPNamed: 'sansmono12.bmp'" for example, the image in the Transcript is placed 
in the .bmp file.

This needs improvement. The good news is that the glyphs appear to be sized and shaped 
based on the font. The bad news is that the .bmp file contains a multi-line image, exactly as it 
appears in the transcript and the entire first line of this appears to result from the blank (ascii 
32). The next line looks pretty good until it reaches the edge of the pane where it stops. The 
following characters are on the next line, etc.

What's needed is a morph which will contain the entire character set 32 to 255 without 
wrapping and with the desired font. That morph can be sent the #exportAsBMPNamed: 
message and then maybe we can make a strikefont.

[ snip ]

 - Dan



From juan at jvuletich.org  Sat Jul 25 16:31:18 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 25 Jul 2015 18:31:18 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B29E13.29241.F06B25@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>,
	<55AD7737.30003@jvuletich.org>
	<55B29E13.29241.F06B25@dnorton.mindspring.com>
Message-ID: <55B40026.6010208@jvuletich.org>

Hi Dan,

The format saved by image writer is not (currently) supported in Cuis, 
Squeak, etc. Maybe there is a command line option to tell imageMagick to 
use a more standard bmp format. Or you can just save in png. I opened 
them in Windows Paint, clicked on 'save' and then Cuis was able to read 
them.

Your xTables in the txt files are indeed wrong. For Courier12, the width 
of the bmp file is around 1500 pixels. And in the xTable you have 
entries calling pixels around x=2600. Impossible. Take a look at the bmp 
you generated count the width used by each glyph. It is 7 pixels wide. 
Your xTable is multiples of 12...

After fixing this 2 issues, I run your stuff and indeed it starts to 
run. It looks like a bit more work is needed in the xTable, though.

Cheers,
Juan Vuletich

On 7/24/2015 5:20 PM, Dan Norton wrote:
>
> Encouraged by this, I have tried cobbling a fixed-width StrikeFont 
> from Courier New which comes with Windows7. At this point, if some 
> kind of fixed-width smudges would appear then it would be progress. 
> Here's where I am:
>
> The immediate problem is an error: 'Unsupported format. Try 
> "Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter 
> class>>formFromStream: examines the .bmp file.
>
> Higher in the context, Form class>>fromBinaryStream: has firstByte = 
> 66 which I mention because of the way the .bmp file was made. Here is 
> the process I used, from the bottom up:
>
> ImageMagick freeware produces the glyphs but with something stubbornly 
> prepended. The command line is:
>            convert -font \windows\fonts\cour.ttf -pointsize 12 
> label:@characters.txt courier12.bmp
>
> Using NotePad, save characters.txt with encoding: UTF-8.
>
> Paste the character string onto a NotePad
>
> Copy the character string.
>
> In a Cuis workspace print:
>            str := String new writeStream.
>            (32 to: 255) do: [ :n | str nextPut: n asCharacter]
>            str contents.
>
> Code package and files allegedly for courier strike fonts are attached 
> if you're interested.
>
>  - Dan

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

From juan at jvuletich.org  Sat Jul 25 17:36:58 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 25 Jul 2015 19:36:58 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <20150705095751.c84ded291d123bac31348c46@whidbey.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>	<559938A2.3040204@jvuletich.org>
	<20150705095751.c84ded291d123bac31348c46@whidbey.com>
Message-ID: <55B40F8A.1030706@jvuletich.org>

I fixed this a few days ago. Please check. If there's some problem there 
yet, please complain :)

Cheers,
Juan Vuletich

Ps. It is getting a bit hard to find enough time for all this. That's 
why I'm slow answering. Please never refrain from insisting if I don't 
answer.

On 7/4/2015 10:57 PM, Ken.Dickey wrote:
> On Sun, 05 Jul 2015 11:01:06 -0300
> Juan Vuletich<juan at jvuletich.org>  wrote:
>
>> Hi Ken,
>>
>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>> Juan,
>>>
>>> The Installed Packages browser used to be able to require a minimum revision on the base release.
>>>
>>> I use this feature as a backstop when features change in the base release.
>>>
>>> Any chance in getting this ability back?
>>>
>>> Thanks much,
>>> -KenD
>> When was it lost?  I can't remember doing anything related to this...
> Not sure when.
>
> If there is more than one package loaded, one can Add Requirement with one option being the base release.  If only one package is loaded, one gets the "Required package must already be loaded" popup, rather than an option to require Cuis-Base.
>




From dnorton at mindspring.com  Sat Jul 25 20:41:03 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 25 Jul 2015 21:41:03 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <55B43AAF.12784.2E478F5@dnorton.mindspring.com>

Attached is a StrikeFont of Courier New 12. It's hacked - not polished by any means. It was 
made by:

Making "characters.txt" by printing in a Cuis workspace, copying to Notepad, and saving with 
encoding: ANSI.

This was input to ImageMagick to make a .png file.

The .png file was opened in Paint, then saved as a .bmp file.

The body of the .txt file was generated by:
(32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 - needed to avoid index out of range"

The first three numbers in .txt were finagled to 12 15 5 (the last two anyway).

The font was installed by running:
StrikeFont installCourier.  "code in Courier.pck.st "

Text in the Text Editor pane was highlighted and the font changed to Courier 12 point. It 
looked much too small. Going back to Paint, the glyphs were selected and stretched 
vertically. The font was re-installed. The vertical distortion is probably obvious.

At least it's recognizable as Courier and it's fixed width. Files are attached.

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CourierExample2.zip
Type: application/zip
Size: 10523 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150725/30c1a018/attachment-0002.zip>

From dnorton at mindspring.com  Sun Jul 26 17:47:53 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 26 Jul 2015 15:47:53 -0700 (PDT)
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT
 version number
In-Reply-To: <55B0F0B2.6090202@jvuletich.org>
References: <55B0F0B2.6090202@jvuletich.org>
Message-ID: <1437950873600-4839529.post@n4.nabble.com>


Very small snip (while preparing an answer for the whole thread):

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.
> ...

Yes. Cuis is MIT, etc. You don't have any obligations, etc.

But, if you tell what are you using Cuis for, and how, that is very 
useful (and nice to know).
If you are maintaining a significant code base, if possible, tell about 
it. This will help us better support you.


How I want to use Cuis:

Multi-player games. Juan, are you going to put your Scrabble in a Cuis
package?

App delivery sans IDE, halos, menus

Apps with feedback; output becomes next input

Recognition biometrics

Financial analysis

Anything fun

 - Dan




--
View this message in context: http://forum.world.st/Please-tell-about-your-projects-Re-Fwd-Re-DIRECT-version-number-tp4838865p4839529.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From hannes.hirzel at gmail.com  Mon Jul 27 01:54:17 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 27 Jul 2015 06:54:17 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <55B40F8A.1030706@jvuletich.org>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<559938A2.3040204@jvuletich.org>
	<20150705095751.c84ded291d123bac31348c46@whidbey.com>
	<55B40F8A.1030706@jvuletich.org>
Message-ID: <CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>

On 7/25/15, Juan Vuletich <juan at jvuletich.org> wrote:
> I fixed this a few days ago. Please check. If there's some problem there
> yet, please complain :)
>
> Cheers,
> Juan Vuletich
>
> Ps. It is getting a bit hard to find enough time for all this. That's
> why I'm slow answering. Please never refrain from insisting if I don't
> answer.

Thank you for this fix. Has it been committed?
The last commit is 8 days ago.
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/e9568515b8db6c5e251e209edae60819d7ba4b63

--Hannes


> On 7/4/2015 10:57 PM, Ken.Dickey wrote:
>> On Sun, 05 Jul 2015 11:01:06 -0300
>> Juan Vuletich<juan at jvuletich.org>  wrote:
>>
>>> Hi Ken,
>>>
>>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>>> Juan,
>>>>
>>>> The Installed Packages browser used to be able to require a minimum
>>>> revision on the base release.
>>>>
>>>> I use this feature as a backstop when features change in the base
>>>> release.
>>>>
>>>> Any chance in getting this ability back?
>>>>
>>>> Thanks much,
>>>> -KenD
>>> When was it lost?  I can't remember doing anything related to this...
>> Not sure when.
>>
>> If there is more than one package loaded, one can Add Requirement with one
>> option being the base release.  If only one package is loaded, one gets
>> the "Required package must already be loaded" popup, rather than an option
>> to require Cuis-Base.
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Mon Jul 27 01:59:47 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 27 Jul 2015 06:59:47 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<559938A2.3040204@jvuletich.org>
	<20150705095751.c84ded291d123bac31348c46@whidbey.com>
	<55B40F8A.1030706@jvuletich.org>
	<CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>
Message-ID: <CAGQxfVgT9Crbu1V7TEQ_baYf+On=7aECUMf7MzB7S6Ri4tBw0Q@mail.gmail.com>

BTW you are NOT slow in answering. Take you time.

For confirming  that the feature is back indeed
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/70

On 7/27/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> On 7/25/15, Juan Vuletich <juan at jvuletich.org> wrote:
>> I fixed this a few days ago. Please check. If there's some problem there
>> yet, please complain :)
>>
>> Cheers,
>> Juan Vuletich
>>
>> Ps. It is getting a bit hard to find enough time for all this. That's
>> why I'm slow answering. Please never refrain from insisting if I don't
>> answer.
>
> Thank you for this fix. Has it been committed?
> The last commit is 8 days ago.
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/e9568515b8db6c5e251e209edae60819d7ba4b63
>
> --Hannes
>
>
>> On 7/4/2015 10:57 PM, Ken.Dickey wrote:
>>> On Sun, 05 Jul 2015 11:01:06 -0300
>>> Juan Vuletich<juan at jvuletich.org>  wrote:
>>>
>>>> Hi Ken,
>>>>
>>>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>>>> Juan,
>>>>>
>>>>> The Installed Packages browser used to be able to require a minimum
>>>>> revision on the base release.
>>>>>
>>>>> I use this feature as a backstop when features change in the base
>>>>> release.
>>>>>
>>>>> Any chance in getting this ability back?
>>>>>
>>>>> Thanks much,
>>>>> -KenD
>>>> When was it lost?  I can't remember doing anything related to this...
>>> Not sure when.
>>>
>>> If there is more than one package loaded, one can Add Requirement with
>>> one
>>> option being the base release.  If only one package is loaded, one gets
>>> the "Required package must already be loaded" popup, rather than an
>>> option
>>> to require Cuis-Base.
>>>
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>



From juan at jvuletich.org  Mon Jul 27 09:40:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 27 Jul 2015 11:40:34 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfVgT9Crbu1V7TEQ_baYf+On=7aECUMf7MzB7S6Ri4tBw0Q@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>	<559938A2.3040204@jvuletich.org>	<20150705095751.c84ded291d123bac31348c46@whidbey.com>	<55B40F8A.1030706@jvuletich.org>	<CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>
	<CAGQxfVgT9Crbu1V7TEQ_baYf+On=7aECUMf7MzB7S6Ri4tBw0Q@mail.gmail.com>
Message-ID: <55B642E2.6040203@jvuletich.org>

On 7/27/2015 3:59 AM, H. Hirzel wrote:
> BTW you are NOT slow in answering. Take you time.

:)

> For confirming  that the feature is back indeed
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/70

Ken confirmed that it is working ok. I closed the issue.

Thanks,
Juan Vuletich

> On 7/27/15, H. Hirzel<hannes.hirzel at gmail.com>  wrote:
>> On 7/25/15, Juan Vuletich<juan at jvuletich.org>  wrote:
>>> I fixed this a few days ago. Please check. If there's some problem there
>>> yet, please complain :)
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> Ps. It is getting a bit hard to find enough time for all this. That's
>>> why I'm slow answering. Please never refrain from insisting if I don't
>>> answer.
>> Thank you for this fix. Has it been committed?
>> The last commit is 8 days ago.
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/e9568515b8db6c5e251e209edae60819d7ba4b63
>>
>> --Hannes
>>
>>
>>> On 7/4/2015 10:57 PM, Ken.Dickey wrote:
>>>> On Sun, 05 Jul 2015 11:01:06 -0300
>>>> Juan Vuletich<juan at jvuletich.org>   wrote:
>>>>
>>>>> Hi Ken,
>>>>>
>>>>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>>>>> Juan,
>>>>>>
>>>>>> The Installed Packages browser used to be able to require a minimum
>>>>>> revision on the base release.
>>>>>>
>>>>>> I use this feature as a backstop when features change in the base
>>>>>> release.
>>>>>>
>>>>>> Any chance in getting this ability back?
>>>>>>
>>>>>> Thanks much,
>>>>>> -KenD
>>>>> When was it lost?  I can't remember doing anything related to this...
>>>> Not sure when.
>>>>
>>>> If there is more than one package loaded, one can Add Requirement with
>>>> one
>>>> option being the base release.  If only one package is loaded, one gets
>>>> the "Required package must already be loaded" popup, rather than an
>>>> option
>>>> to require Cuis-Base.
>>>>
>>>
>>> _______________________________________________
>>> 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  Mon Jul 27 09:58:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 27 Jul 2015 11:58:27 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6BMwgF9pffS7TWaPKTi8EkE2X-puM=e0NQNBn1gW5Z4Pw@mail.gmail.com>
References: <CAGQxfVhtR6zezHW4Nji0kHU3str2Zf4Dbfdn5VjphgAqwnuz-g@mail.gmail.com>
	<20140501080531.493624077a7c3f67688650f9@whidbey.com>
	<CAGQxfVgeyXkyu5Rqdn2T9T+iY5rYzEVy9w76N0=scZCR+-iy3w@mail.gmail.com>
	<CAEt3aLxfNLqDJ3LhBZFdwSO5VjcPDmQcStXWiTEts8YBsWLvxw@mail.gmail.com>
	<CA+=t-6DwrOQwVB3QeTWaL=rGG7=g5J-poDh5UR9tpMXFtnsPbg@mail.gmail.com>
	<CAGQxfVg4wzvPRBg-XRP3dFWw_EbV=in7ZCiK-TzYJzV+MP9y0A@mail.gmail.com>
	<CAGQxfVjyHyA1R1aEuaNcpiyFqOG+zSy8SzqqqeD7drG8kSzZPQ@mail.gmail.com>
	<555A8705.5080502@jvuletich.org>
	<CA+=t-6C7Bh+2YRfNwEdfUJDcn=cx=NNXTc-DuWfyJ5ZbbKYeHQ@mail.gmail.com>
	<5573BD8C.4010008@jvuletich.org>
	<CA+=t-6BMwgF9pffS7TWaPKTi8EkE2X-puM=e0NQNBn1gW5Z4Pw@mail.gmail.com>
Message-ID: <55B64713.8040806@jvuletich.org>

Hi Masashi,

Recently we found that in FileMan, if we do

'inexistentFile' asFileEntry readStream

we get an empty readStream.

I think it is better to throw the #fileDoesNotExistException , as 
FileDirectory did, and let the user handle the exception appropriately. 
But I would not want to break compatibility with FileMan, as the main 
purpose of FileMan is to give compatibility amongst dialects.

Are there good reasons to avoid the exception? Should we add another 
method, besides #readStream when we want a readStream strictly on 
existing file contents?

Thanks,
Juan Vuletich


On 6/14/2015 8:38 AM, Masashi UMEZAWA wrote:
> Hello Juan,
>
> Thank you for the patches and more tests! I'll adapt those updates for
> other FileMan ports.
>
> Best regards,
>
> 2015-06-07 12:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>> Hi Masashi,
>>
>> I was trying FileMan tests today and I saw they create some folders in my
>> drive. The names looked a bit strange, so I took a closer look and found a
>> couple of bugs. At least on Windows, #testRecursiveDelete instead of
>> creating
>>        subDir/aaa/bbb/ccc/ddd/eee/fff/ggg/test1
>> it created
>>         subDir/bbb/ccc/eee/ggg/test!
>>
>> So I wrote a few more tests on the issues I saw, and teaked the code to make
>> them pass. The result is attached, and I think is useful for all ports of
>> FileMan.
>>
>> Thanks,
>> Juan Vuletich
>>
>> On 5/26/2015 11:34 PM, Masashi UMEZAWA wrote:
>>> Hi all,
>>>
>>> I think it is nice if FileMan is on the core package repository.
>>>
>>> FileMan for Cuis (and Squeak) has minimum dependencies to the existing
>>> FileDirectory and DirectoryEntry. FileMan selectively uses a few
>>> methods of them.
>>>
>>> So we can gradually adopt FileMan interfaces and trim the
>>> FileDirectory and DirectoryEntry's non-intuitive methods.
>>>
>>> Another way of cleaning-up the file-related classes is to port
>>> FileSystems to Cuis.
>>> But since Cuis is a lightweight Smalltalk dialect, FileSystems might
>>> be an overkill.
>>>
>>> Best regards,
>>>
>>> 2015-05-19 9:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>>>> Hi Folks,
>>>>
>>>> I apologize for talking before taking even a quick look, but anyway, We'd
>>>> take a good look at this. And seriously consider replacing files stuff in
>>>> Cuis base. Or at least adopting it as a core package in our repo.
>>>>
>>>> Thoughts?
>>>>
>>>> Masashi-san: opinions?
>>>>
>>>> Thanks,
>>>> Juan Vuletich
>>>>
>>>>
>>>> On 5/17/2015 12:07 PM, H. Hirzel wrote:
>>>>> Below are the comments from the FileMan package.
>>>>>
>>>>> Question: How do you compare the FileMan package to the FileSystem
>>>>> package in Pharo?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L45
>>>>> I represent a single file entry (including directory).
>>>>> You can write data by #fileContents: , and read the data by
>>>>> #fileContents.
>>>>> ---
>>>>> mu 11/6/2006 20:21!
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L53
>>>>> I represent a single file directory.
>>>>> I implement various directory specific behaviors.
>>>>> You can write data by #at:put: , and read the data by #at:.
>>>>> ---
>>>>> mu 11/6/2006 20:21
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L63
>>>>> !FmFileIOAccessor commentStamp: '<historical>' prior: 0!
>>>>> I am an accessor to the low level file IO.
>>>>> You can extend/rewrite me if you port FileMan to other Smalltalk
>>>>> dialects.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L44
>>>>> !FmBackupDirectoryEntry commentStamp: 'mu 5/4/2007 23:26' prior: 0!
>>>>> This is a simple example for adding special behaviors to
>>>>> FmDirectoryEntry.
>>>>> I backup file contents automatically, while users are not conscious
>>>>> about
>>>>> that.
>>>>> Usage:
>>>>> dir := './withBackup' asDirectoryEntry: FmBackupDirectoryEntry.
>>>>> dir at: 'text' put: 'abc'.
>>>>> dir at: 'text' put: 'def'.
>>>>> (dir at: 'text') inspect. "def"
>>>>> (dir backupAt: 'text') inspect. "abc"
>>>>> ((dir / 'sub') at: 'text2' put: '123').
>>>>> ((dir / 'sub') at: 'text2' put: '456').
>>>>> ((dir / 'sub') at: 'text2') inspect. "456"
>>>>> ((dir / 'sub') backupAt: 'text2') inspect. "123"
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L63
>>>>> This is a simple example for adding special behaviors to
>>>>> FmDirectoryEntry.
>>>>> I put and get file contents as gzipped, while users are not conscious
>>>>> about that.
>>>>> Usage:
>>>>> | dir |
>>>>> dir := './gzipped2' asDirectoryEntry: FmGZipDirectoryEntry.
>>>>> dir binaryAt: 'bin' put: #(1 2 3 12 34 56) asByteArray.
>>>>> (dir binaryAt: 'bin') inspect.
>>>>> dir at: 'text' put: 'This will be gzipped'.
>>>>> (dir at: 'text') inspect.
>>>>> I would be useful for storing/loading big contents in a simple
>>>>> dictionary-like manner.
>>>>>
>>>>>
>>>>>
>>>>> On 5/17/15, H. Hirzel<hannes.hirzel at gmail.com>    wrote:
>>>>>> Hello Masashi-san
>>>>>>
>>>>>> I'd like to come back to your FileMan package
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>
>>>>>> and ask a question.
>>>>>>
>>>>>> Is this package a port from somewhere or did you write it from scratch?
>>>>>>
>>>>>> Some background information is appreciated.
>>>>>>
>>>>>> There is no description
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L2
>>>>>>
>>>>>> Thank you in advance
>>>>>>
>>>>>> Hannes Hirzel
>>>>>>
>>>>>>
>>>>>> On 5/2/14, Masashi UMEZAWA<ume at blueplane.jp>    wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Thank you for the kind words. I've just started Cuis on March, and I
>>>>>>> was impressed with its cleanness, simplicity, etc.
>>>>>>> So I did a introductory presentation at Tokyo Smalltalkers meeting. It
>>>>>>> was successful.
>>>>>>> Now I'm planning to port Folktale (telnet-base object shell), and SIXX
>>>>>>> to Cuis. My pace maybe slow, but please stay tuned. ;)
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> 2014-05-02 1:05 GMT+09:00 Germ?n Arduino<garduino at gmail.com>:
>>>>>>>> Wow, I was completely unaware of Masashi working in Cuis! Welcome
>>>>>>>> aboard!!
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-05-01 12:19 GMT-03:00 H. Hirzel<hannes.hirzel at gmail.com>:
>>>>>>>>
>>>>>>>>> Thank you for the link to  Masashi Umezawa's presentation.
>>>>>>>>>
>>>>>>>>> It is from 2014 and talks about
>>>>>>>>>
>>>>>>>>> - the number of classes compared to Squeak and Pharo
>>>>>>>>> - the size of Morphic -- Morph allSelectors size "=>    502"
>>>>>>>>> - something I do not fully get about instance variables
>>>>>>>>>         'bounds owner submorphs fullBounds color extension'
>>>>>>>>>         versus
>>>>>>>>>        'owner submorphs location layoutNeeded layoutSpec properties'
>>>>>>>>> - layoutSpec
>>>>>>>>> - PackageInfo
>>>>>>>>> - version control with git
>>>>>>>>> - Feature require: '<PackageName>'.
>>>>>>>>> - your Unicode package
>>>>>>>>> https://github.com/KenDickey/Cuis-Smalltalk-Unicode
>>>>>>>>> - https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-StyledTextEditor
>>>>>>>>> - How to query for other Cuis-Smalltalk repositories
>>>>>>>>>                 https://github.com/search?q=cuis-smalltalk
>>>>>>>>>
>>>>>>>>> All things which we will include Cuis documentation effort.
>>>>>>>>>
>>>>>>>>> --Hannes
>>>>>>>>>
>>>>>>>>> On 5/1/14, Ken Dickey<Ken.Dickey at whidbey.com>    wrote:
>>>>>>>>>> On Thu, 1 May 2014 07:28:54 +0000
>>>>>>>>>> "H. Hirzel"<hannes.hirzel at gmail.com>    wrote:
>>>>>>>>>>
>>>>>>>>>>> A noteworthy effort
>>>>>>>>>>>
>>>>>>>>>>>          https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>>>> Yes.  Masashi Umezawa is the man in Japan!
>>>>>>>>>>
>>>>>>>>>> He should introduce himself.
>>>>>>>>>>
>>>>>>>>>> He gave a talk about Cuis at the 63rd Smalltalkers' meeting in
>>>>>>>>>> Tokyo:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://www.smalltalk-users.jp/Home/gao-zhi/dai63kaismalltalkbenkyoukai/shiryou
>>>>>>>>>>
>>>>>>>>>> Masashi has ported several packages to CUis.
>>>>>>>>>>
>>>>>>>>>> Because of Unicode interest, I was made aware that recent font
>>>>>>>>>> tweaks
>>>>>>>>>> have
>>>>>>>>>> broken my Unicode package in the latest Cuis versions.
>>>>>>>>>>
>>>>>>>>>> Masashi-san, would you care to tell us about yourself and what
>>>>>>>>>> people
>>>>>>>>>> there
>>>>>>>>>> think about Cuis?
>>>>>>>>>>
>>>>>>>>>> -KenD
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>
>>>
>
>




From hannes.hirzel at gmail.com  Mon Jul 27 13:31:24 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 27 Jul 2015 18:31:24 +0000
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <55B64713.8040806@jvuletich.org>
References: <CAGQxfVhtR6zezHW4Nji0kHU3str2Zf4Dbfdn5VjphgAqwnuz-g@mail.gmail.com>
	<20140501080531.493624077a7c3f67688650f9@whidbey.com>
	<CAGQxfVgeyXkyu5Rqdn2T9T+iY5rYzEVy9w76N0=scZCR+-iy3w@mail.gmail.com>
	<CAEt3aLxfNLqDJ3LhBZFdwSO5VjcPDmQcStXWiTEts8YBsWLvxw@mail.gmail.com>
	<CA+=t-6DwrOQwVB3QeTWaL=rGG7=g5J-poDh5UR9tpMXFtnsPbg@mail.gmail.com>
	<CAGQxfVg4wzvPRBg-XRP3dFWw_EbV=in7ZCiK-TzYJzV+MP9y0A@mail.gmail.com>
	<CAGQxfVjyHyA1R1aEuaNcpiyFqOG+zSy8SzqqqeD7drG8kSzZPQ@mail.gmail.com>
	<555A8705.5080502@jvuletich.org>
	<CA+=t-6C7Bh+2YRfNwEdfUJDcn=cx=NNXTc-DuWfyJ5ZbbKYeHQ@mail.gmail.com>
	<5573BD8C.4010008@jvuletich.org>
	<CA+=t-6BMwgF9pffS7TWaPKTi8EkE2X-puM=e0NQNBn1gW5Z4Pw@mail.gmail.com>
	<55B64713.8040806@jvuletich.org>
Message-ID: <CAGQxfVijywhcd0rCTnqz53oD0xcKnFjt8rcQ27VWuwZqqDqdYA@mail.gmail.com>

I as well opened an issue for Cuis to get mentioned.

https://github.com/mumez/FileMan/issues/1

--Hannes

On 7/27/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Masashi,
>
> Recently we found that in FileMan, if we do
>
> 'inexistentFile' asFileEntry readStream
>
> we get an empty readStream.
>
> I think it is better to throw the #fileDoesNotExistException , as
> FileDirectory did, and let the user handle the exception appropriately.
> But I would not want to break compatibility with FileMan, as the main
> purpose of FileMan is to give compatibility amongst dialects.
>
> Are there good reasons to avoid the exception? Should we add another
> method, besides #readStream when we want a readStream strictly on
> existing file contents?
>
> Thanks,
> Juan Vuletich
>
>
> On 6/14/2015 8:38 AM, Masashi UMEZAWA wrote:
>> Hello Juan,
>>
>> Thank you for the patches and more tests! I'll adapt those updates for
>> other FileMan ports.
>>
>> Best regards,
>>
>> 2015-06-07 12:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>>> Hi Masashi,
>>>
>>> I was trying FileMan tests today and I saw they create some folders in
>>> my
>>> drive. The names looked a bit strange, so I took a closer look and found
>>> a
>>> couple of bugs. At least on Windows, #testRecursiveDelete instead of
>>> creating
>>>        subDir/aaa/bbb/ccc/ddd/eee/fff/ggg/test1
>>> it created
>>>         subDir/bbb/ccc/eee/ggg/test!
>>>
>>> So I wrote a few more tests on the issues I saw, and teaked the code to
>>> make
>>> them pass. The result is attached, and I think is useful for all ports
>>> of
>>> FileMan.
>>>
>>> Thanks,
>>> Juan Vuletich
>>>
>>> On 5/26/2015 11:34 PM, Masashi UMEZAWA wrote:
>>>> Hi all,
>>>>
>>>> I think it is nice if FileMan is on the core package repository.
>>>>
>>>> FileMan for Cuis (and Squeak) has minimum dependencies to the existing
>>>> FileDirectory and DirectoryEntry. FileMan selectively uses a few
>>>> methods of them.
>>>>
>>>> So we can gradually adopt FileMan interfaces and trim the
>>>> FileDirectory and DirectoryEntry's non-intuitive methods.
>>>>
>>>> Another way of cleaning-up the file-related classes is to port
>>>> FileSystems to Cuis.
>>>> But since Cuis is a lightweight Smalltalk dialect, FileSystems might
>>>> be an overkill.
>>>>
>>>> Best regards,
>>>>
>>>> 2015-05-19 9:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>>>>> Hi Folks,
>>>>>
>>>>> I apologize for talking before taking even a quick look, but anyway,
>>>>> We'd
>>>>> take a good look at this. And seriously consider replacing files stuff
>>>>> in
>>>>> Cuis base. Or at least adopting it as a core package in our repo.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Masashi-san: opinions?
>>>>>
>>>>> Thanks,
>>>>> Juan Vuletich
>>>>>
>>>>>
>>>>> On 5/17/2015 12:07 PM, H. Hirzel wrote:
>>>>>> Below are the comments from the FileMan package.
>>>>>>
>>>>>> Question: How do you compare the FileMan package to the FileSystem
>>>>>> package in Pharo?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L45
>>>>>> I represent a single file entry (including directory).
>>>>>> You can write data by #fileContents: , and read the data by
>>>>>> #fileContents.
>>>>>> ---
>>>>>> mu 11/6/2006 20:21!
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L53
>>>>>> I represent a single file directory.
>>>>>> I implement various directory specific behaviors.
>>>>>> You can write data by #at:put: , and read the data by #at:.
>>>>>> ---
>>>>>> mu 11/6/2006 20:21
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L63
>>>>>> !FmFileIOAccessor commentStamp: '<historical>' prior: 0!
>>>>>> I am an accessor to the low level file IO.
>>>>>> You can extend/rewrite me if you port FileMan to other Smalltalk
>>>>>> dialects.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L44
>>>>>> !FmBackupDirectoryEntry commentStamp: 'mu 5/4/2007 23:26' prior: 0!
>>>>>> This is a simple example for adding special behaviors to
>>>>>> FmDirectoryEntry.
>>>>>> I backup file contents automatically, while users are not conscious
>>>>>> about
>>>>>> that.
>>>>>> Usage:
>>>>>> dir := './withBackup' asDirectoryEntry: FmBackupDirectoryEntry.
>>>>>> dir at: 'text' put: 'abc'.
>>>>>> dir at: 'text' put: 'def'.
>>>>>> (dir at: 'text') inspect. "def"
>>>>>> (dir backupAt: 'text') inspect. "abc"
>>>>>> ((dir / 'sub') at: 'text2' put: '123').
>>>>>> ((dir / 'sub') at: 'text2' put: '456').
>>>>>> ((dir / 'sub') at: 'text2') inspect. "456"
>>>>>> ((dir / 'sub') backupAt: 'text2') inspect. "123"
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L63
>>>>>> This is a simple example for adding special behaviors to
>>>>>> FmDirectoryEntry.
>>>>>> I put and get file contents as gzipped, while users are not conscious
>>>>>> about that.
>>>>>> Usage:
>>>>>> | dir |
>>>>>> dir := './gzipped2' asDirectoryEntry: FmGZipDirectoryEntry.
>>>>>> dir binaryAt: 'bin' put: #(1 2 3 12 34 56) asByteArray.
>>>>>> (dir binaryAt: 'bin') inspect.
>>>>>> dir at: 'text' put: 'This will be gzipped'.
>>>>>> (dir at: 'text') inspect.
>>>>>> I would be useful for storing/loading big contents in a simple
>>>>>> dictionary-like manner.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/17/15, H. Hirzel<hannes.hirzel at gmail.com>    wrote:
>>>>>>> Hello Masashi-san
>>>>>>>
>>>>>>> I'd like to come back to your FileMan package
>>>>>>>
>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>
>>>>>>> and ask a question.
>>>>>>>
>>>>>>> Is this package a port from somewhere or did you write it from
>>>>>>> scratch?
>>>>>>>
>>>>>>> Some background information is appreciated.
>>>>>>>
>>>>>>> There is no description
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L2
>>>>>>>
>>>>>>> Thank you in advance
>>>>>>>
>>>>>>> Hannes Hirzel
>>>>>>>
>>>>>>>
>>>>>>> On 5/2/14, Masashi UMEZAWA<ume at blueplane.jp>    wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Thank you for the kind words. I've just started Cuis on March, and
>>>>>>>> I
>>>>>>>> was impressed with its cleanness, simplicity, etc.
>>>>>>>> So I did a introductory presentation at Tokyo Smalltalkers meeting.
>>>>>>>> It
>>>>>>>> was successful.
>>>>>>>> Now I'm planning to port Folktale (telnet-base object shell), and
>>>>>>>> SIXX
>>>>>>>> to Cuis. My pace maybe slow, but please stay tuned. ;)
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> 2014-05-02 1:05 GMT+09:00 Germ?n Arduino<garduino at gmail.com>:
>>>>>>>>> Wow, I was completely unaware of Masashi working in Cuis! Welcome
>>>>>>>>> aboard!!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2014-05-01 12:19 GMT-03:00 H. Hirzel<hannes.hirzel at gmail.com>:
>>>>>>>>>
>>>>>>>>>> Thank you for the link to  Masashi Umezawa's presentation.
>>>>>>>>>>
>>>>>>>>>> It is from 2014 and talks about
>>>>>>>>>>
>>>>>>>>>> - the number of classes compared to Squeak and Pharo
>>>>>>>>>> - the size of Morphic -- Morph allSelectors size "=>    502"
>>>>>>>>>> - something I do not fully get about instance variables
>>>>>>>>>>         'bounds owner submorphs fullBounds color extension'
>>>>>>>>>>         versus
>>>>>>>>>>        'owner submorphs location layoutNeeded layoutSpec
>>>>>>>>>> properties'
>>>>>>>>>> - layoutSpec
>>>>>>>>>> - PackageInfo
>>>>>>>>>> - version control with git
>>>>>>>>>> - Feature require: '<PackageName>'.
>>>>>>>>>> - your Unicode package
>>>>>>>>>> https://github.com/KenDickey/Cuis-Smalltalk-Unicode
>>>>>>>>>> -
>>>>>>>>>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-StyledTextEditor
>>>>>>>>>> - How to query for other Cuis-Smalltalk repositories
>>>>>>>>>>                 https://github.com/search?q=cuis-smalltalk
>>>>>>>>>>
>>>>>>>>>> All things which we will include Cuis documentation effort.
>>>>>>>>>>
>>>>>>>>>> --Hannes
>>>>>>>>>>
>>>>>>>>>> On 5/1/14, Ken Dickey<Ken.Dickey at whidbey.com>    wrote:
>>>>>>>>>>> On Thu, 1 May 2014 07:28:54 +0000
>>>>>>>>>>> "H. Hirzel"<hannes.hirzel at gmail.com>    wrote:
>>>>>>>>>>>
>>>>>>>>>>>> A noteworthy effort
>>>>>>>>>>>>
>>>>>>>>>>>>          https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>>>>> Yes.  Masashi Umezawa is the man in Japan!
>>>>>>>>>>>
>>>>>>>>>>> He should introduce himself.
>>>>>>>>>>>
>>>>>>>>>>> He gave a talk about Cuis at the 63rd Smalltalkers' meeting in
>>>>>>>>>>> Tokyo:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://www.smalltalk-users.jp/Home/gao-zhi/dai63kaismalltalkbenkyoukai/shiryou
>>>>>>>>>>>
>>>>>>>>>>> Masashi has ported several packages to CUis.
>>>>>>>>>>>
>>>>>>>>>>> Because of Unicode interest, I was made aware that recent font
>>>>>>>>>>> tweaks
>>>>>>>>>>> have
>>>>>>>>>>> broken my Unicode package in the latest Cuis versions.
>>>>>>>>>>>
>>>>>>>>>>> Masashi-san, would you care to tell us about yourself and what
>>>>>>>>>>> people
>>>>>>>>>>> there
>>>>>>>>>>> think about Cuis?
>>>>>>>>>>>
>>>>>>>>>>> -KenD
>>>>>> _______________________________________________
>>>>>> Cuis mailing list
>>>>>> Cuis at jvuletich.org
>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>
>>>>
>>
>>
>
>



From juan at jvuletich.org  Tue Jul 28 07:28:45 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 28 Jul 2015 09:28:45 -0300
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
Message-ID: <55B7757D.80006@jvuletich.org>

Hi Folks,

I just did a commit to the repo. It includes the updated ReferenceFinder 
and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).

Open an inspector on a window (using the halo). In the bottom pane 
evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer 
openExplorerOn: self'. Check the object trees to see what you have 
there. Read ClosureScanner class comment. You'll agree with me that this 
is truly great!

Also, several contributions by Ken (thanks Ken!), and a few fixes to 
Display updating, font creation, etc. by yours truly.

I also included an xml file with the test results.

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Tue Jul 28 16:41:42 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 28 Jul 2015 17:41:42 -0400
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <55B7757D.80006@jvuletich.org>
References: <55B7757D.80006@jvuletich.org>
Message-ID: <1438119702.2292.5.camel@gmail.com>

On Tue, 2015-07-28 at 09:28 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> I just did a commit to the repo. It includes the updated ReferenceFinder 
> and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).
> 
> Open an inspector on a window (using the halo). In the bottom pane 
> evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer 
> openExplorerOn: self'. Check the object trees to see what you have 
> there. Read ClosureScanner class comment. You'll agree with me that this 
> is truly great!
> 

Very cool stuff indeed!  Are there any notable changes between the old
and new ReferenceFinder or is it mostly just internals stuff?  Also,
should WeightTracer be added to the context menu (right click) of
Explorer and Inspector windows?

> Also, several contributions by Ken (thanks Ken!), and a few fixes to 
> Display updating, font creation, etc. by yours truly.
> 
> I also included an xml file with the test results.
> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Tue Jul 28 17:00:02 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 28 Jul 2015 18:00:02 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>

When the glyphs for the Cuis default font (DejaVu) or those for DejaVu Sans are filed out and 
then examined using Paint, it is obvious that they are of much higher quality than those 
produced by ImageMagick. The height is exactly right, as can be seen at ascii 129, 132, and 
133. They are the right size and crisp when displayed. This is the quality we should have for a 
fixed-width font. How were these .bmp files produced?

On 25 Jul 2015 at 21:41, Dan Norton wrote:

> Attached is a StrikeFont of Courier New 12. It's hacked - not
> polished by any means. It was 
> made by:
> 
> Making "characters.txt" by printing in a Cuis workspace, copying to
> Notepad, and saving with 
> encoding: ANSI.
> 
> This was input to ImageMagick to make a .png file.
> 
> The .png file was opened in Paint, then saved as a .bmp file.
> 
> The body of the .txt file was generated by:
> (32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 -
> needed to avoid index out of range"
> 
> The first three numbers in .txt were finagled to 12 15 5 (the last
> two anyway).
> 
> The font was installed by running:
> StrikeFont installCourier.  "code in Courier.pck.st "
> 
> Text in the Text Editor pane was highlighted and the font changed to
> Courier 12 point. It 
> looked much too small. Going back to Paint, the glyphs were selected
> and stretched 
> vertically. The font was re-installed. The vertical distortion is
> probably obvious.
> 
> At least it's recognizable as Courier and it's fixed width. Files
> are attached.
> 
>  - Dan
> 
> Attachments:
>   C:\Cuis\CourierExample2.zip





From hannes.hirzel at gmail.com  Wed Jul 29 03:44:36 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Wed, 29 Jul 2015 08:44:36 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
Message-ID: <CAGQxfVjs7DceHza3oyWAPRbJ7YDjoVR=HswXosR9yyJX4auM4w@mail.gmail.com>

Juan produced the fonts. There is some discussion about it in the
mailing list archive.

--HH

On 7/28/15, Dan Norton <dnorton at mindspring.com> wrote:
> When the glyphs for the Cuis default font (DejaVu) or those for DejaVu Sans
> are filed out and
> then examined using Paint, it is obvious that they are of much higher
> quality than those
> produced by ImageMagick. The height is exactly right, as can be seen at
> ascii 129, 132, and
> 133. They are the right size and crisp when displayed. This is the quality
> we should have for a
> fixed-width font. How were these .bmp files produced?
>
> On 25 Jul 2015 at 21:41, Dan Norton wrote:
>
>> Attached is a StrikeFont of Courier New 12. It's hacked - not
>> polished by any means. It was
>> made by:
>>
>> Making "characters.txt" by printing in a Cuis workspace, copying to
>> Notepad, and saving with
>> encoding: ANSI.
>>
>> This was input to ImageMagick to make a .png file.
>>
>> The .png file was opened in Paint, then saved as a .bmp file.
>>
>> The body of the .txt file was generated by:
>> (32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 -
>> needed to avoid index out of range"
>>
>> The first three numbers in .txt were finagled to 12 15 5 (the last
>> two anyway).
>>
>> The font was installed by running:
>> StrikeFont installCourier.  "code in Courier.pck.st "
>>
>> Text in the Text Editor pane was highlighted and the font changed to
>> Courier 12 point. It
>> looked much too small. Going back to Paint, the glyphs were selected
>> and stretched
>> vertically. The font was re-installed. The vertical distortion is
>> probably obvious.
>>
>> At least it's recognizable as Courier and it's fixed width. Files
>> are attached.
>>
>>  - Dan
>>
>> Attachments:
>>   C:\Cuis\CourierExample2.zip
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Wed Jul 29 09:49:14 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 29 Jul 2015 11:49:14 -0300
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <1438119702.2292.5.camel@gmail.com>
References: <55B7757D.80006@jvuletich.org> <1438119702.2292.5.camel@gmail.com>
Message-ID: <55B8E7EA.7060301@jvuletich.org>

On 7/28/2015 6:41 PM, Phil (list) wrote:
> On Tue, 2015-07-28 at 09:28 -0300, Juan Vuletich wrote:
>> Hi Folks,
>>
>> I just did a commit to the repo. It includes the updated ReferenceFinder
>> and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).
>>
>> Open an inspector on a window (using the halo). In the bottom pane
>> evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer
>> openExplorerOn: self'. Check the object trees to see what you have
>> there. Read ClosureScanner class comment. You'll agree with me that this
>> is truly great!
>>
> Very cool stuff indeed!  Are there any notable changes between the old
> and new ReferenceFinder or is it mostly just internals stuff?

I believe it is refactoring to make room for the new WeightTracer.

> Also,
> should WeightTracer be added to the context menu (right click) of
> Explorer and Inspector windows?

Yes! Care to send a cs?

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul 29 09:54:52 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 29 Jul 2015 11:54:52 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
Message-ID: <55B8E93C.7080009@jvuletich.org>

Hi Dan,

I looked for it in old stuff I haven't touched in several years, and 
found it. Glyph rendering is done by FreeType. 
https://www.dropbox.com/sh/9d5xi3x2lvtrtum/AABy17XMTRmciA44ysM-vuxza?dl=0

This original ran on the Mac I had by then, but with the VM I added, it 
seems to work ok on Windows. Anyway, there are no guarantees. I didn't 
try to import the files generated, and for sure you'd need to add glyphs 
for 128, 129, 130 and 131, to follow the Cuis convention.

BTW, I suggest using free fonts, that you can share without concern. 
DejaVu Sans is a good option. Inconsolata is just great. There are 
several more free code-oriented monospaced fonts out there.

Cheers,
Juan Vuletich

On 7/28/2015 7:00 PM, Dan Norton wrote:
> When the glyphs for the Cuis default font (DejaVu) or those for DejaVu Sans are filed out and
> then examined using Paint, it is obvious that they are of much higher quality than those
> produced by ImageMagick. The height is exactly right, as can be seen at ascii 129, 132, and
> 133. They are the right size and crisp when displayed. This is the quality we should have for a
> fixed-width font. How were these .bmp files produced?
>
> On 25 Jul 2015 at 21:41, Dan Norton wrote:
>
>> Attached is a StrikeFont of Courier New 12. It's hacked - not
>> polished by any means. It was
>> made by:
>>
>> Making "characters.txt" by printing in a Cuis workspace, copying to
>> Notepad, and saving with
>> encoding: ANSI.
>>
>> This was input to ImageMagick to make a .png file.
>>
>> The .png file was opened in Paint, then saved as a .bmp file.
>>
>> The body of the .txt file was generated by:
>> (32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 -
>> needed to avoid index out of range"
>>
>> The first three numbers in .txt were finagled to 12 15 5 (the last
>> two anyway).
>>
>> The font was installed by running:
>> StrikeFont installCourier.  "code in Courier.pck.st "
>>
>> Text in the Text Editor pane was highlighted and the font changed to
>> Courier 12 point. It
>> looked much too small. Going back to Paint, the glyphs were selected
>> and stretched
>> vertically. The font was re-installed. The vertical distortion is
>> probably obvious.
>>
>> At least it's recognizable as Courier and it's fixed width. Files
>> are attached.
>>
>>   - Dan
>>
>> Attachments:
>>    C:\Cuis\CourierExample2.zip
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From pbpublist at gmail.com  Wed Jul 29 12:11:37 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 29 Jul 2015 13:11:37 -0400
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <55B8E7EA.7060301@jvuletich.org>
References: <55B7757D.80006@jvuletich.org>
	<1438119702.2292.5.camel@gmail.com> <55B8E7EA.7060301@jvuletich.org>
Message-ID: <1438189897.2292.6.camel@gmail.com>

On Wed, 2015-07-29 at 11:49 -0300, Juan Vuletich wrote:
> On 7/28/2015 6:41 PM, Phil (list) wrote:
> > On Tue, 2015-07-28 at 09:28 -0300, Juan Vuletich wrote:
> >> Hi Folks,
> >>
> >> I just did a commit to the repo. It includes the updated ReferenceFinder
> >> and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).
> >>
> >> Open an inspector on a window (using the halo). In the bottom pane
> >> evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer
> >> openExplorerOn: self'. Check the object trees to see what you have
> >> there. Read ClosureScanner class comment. You'll agree with me that this
> >> is truly great!
> >>
> > Very cool stuff indeed!  Are there any notable changes between the old
> > and new ReferenceFinder or is it mostly just internals stuff?
> 
> I believe it is refactoring to make room for the new WeightTracer.
> 
> > Also,
> > should WeightTracer be added to the context menu (right click) of
> > Explorer and Inspector windows?
> 
> Yes! Care to send a cs?
> 

Done... pull request submitted

> Cheers,
> Juan Vuletich





From hannes.hirzel at gmail.com  Fri Jul 31 01:29:54 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Fri, 31 Jul 2015 06:29:54 +0000
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <1437592756.2326.32.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
	<CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>
	<1437592756.2326.32.camel@gmail.com>
Message-ID: <CAGQxfVhZfsbRw=Fiq0fy5_5MHU5bqEEnM2S1F5akOKUMmxXUJg@mail.gmail.com>

Could we do examples of such Feature Tests?

Class String is a good candidate to start with

Reasons
a) Is  used everywhere
b) Interface is non-trivial
        String selectors size 166   (in Cuis)
                                      338   (in Pharo)
                                      331   (in Squeak)
        --> there are issues when porting.

We might want to have a StringExtensions package

--Hannes

On 7/22/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Wed, 2015-07-22 at 13:29 +0200, Peter van Rooijen wrote:
>> I'm thinking about some features (pun not intentional) of this Feature
>> Test framework:
>>
>>
>> 1. It's reasonable to assume that many tests will depend on something
>> else working, but that cannot be counted on, and
>> we would not want to repeat testing for that and also would not run
>> into it failing all the time and that filling our feedback.
>>
>
> Why not?  I agree that these would be a different category of test in
> that the dependencies would be more complex and often dependent on more
> than one package, but why would their functioning be considered
> optional?  If they fail, shouldn't they either be addressed right away
> or explicitly deprecated?  If you make the tests easy to ignore/forget
> about, they will be.  If the functionality they are testing can't be
> counted on, it won't be used.
>
> If your thinking is that these would be tests that are part of package X
> but might rely on package Y which might not be loaded yet, why not
> instead just make the tests part of package Z which depends on package X
> and Y?  The whole idea is that these are not unit tests in that sense...
> have them live where ever it is appropriate.
>
>>
>> 1a. So it would make sense to add a #precondition method to each
>> Feature Test class.
>>
>>
>> FeatureAnsiArray
>>     class
>>         precondition
>>
>>
>>         self run: 'Array' "i.e. the global Array must be present"
>>
>>
>> then only if the precondition for the class is satisfied, will the
>> test methods be executed. so if most of them start with
>>
>>
>> 'Array new ?' then they would all fail anyway so we don't need to test
>> them.
>>
>>
>> 2. You would want to be able to assure that in a particular object you
>> would be able to access a particular variable.
>>
>>
>> so in the test method you would write:
>>
>>
>> FeatureTest1
>>     class
>>         test1
>>
>>         self setContext: OrderdCollection new
>>
>>
>>         self run: 'elements' "determine if the inst var elements is
>> present in a new OrderedCollection"
>>
>>
>>         self run: 'elements == nil' expect: false
>>
>>
>>         self run: 'elements isOrderedCollection' expect: true
>>
>>
>> let's say the test runner would continue testing even if something
>> failed, e.g. the array is called array, not elements. then we already
>> know that the following expressions will fail
>>
>>
>> so we might instead write:
>>
>>
>>         self run: 'elements' ifFail: [^self]
>>
>>
>>
>>  3. Instead of implicitly testing for a global using run:
>> 'NameOfTheGlobal' or for a class var using setContext: and then
>> run'NameOfTheClassVar' there could be convenience methods for
>>
>>
>>         self expectGlobal: 'NameOfTheGlobal' "argument may be given as
>> a Symbol as well"
>>
>>
>>         self expectClass: 'NameOfTheClass' "additionally verified that
>> the global holds a class"
>>
>>
>>         self expectSharedVariable: 'Foo' inClass: 'Bar'
>>
>>
>> this would make for nicer feedback since the expectation is made
>> clearer
>
> I went the other way when I did the ApiFile tests in that it didn't seem
> terribly important to use most of the testing framework capabilities
> (other than the overall pass/fail aspect to keep the initial PoC as
> simple as possible)  So they are simply small snippets of code that
> performed the desired task but didn't care where it failed (if it
> failed):  the failure to successfully complete the task would be the
> indicator that there was a problem and we would know that either
> something being depended on had broken and needed to be fixed or that
> the test needed to be updated/overhauled to represent the new way of
> accomplishing the task.
>
> My thinking was that as we started to build up a number of these, we
> might start to see common breakage patterns and then we could decide
> whether or not to handle that them more explicitly (whether using the
> existing test framework capabilities, creating a new one, etc.)  Trying
> to engineer it up front didn't seem like a great idea not knowing what
> common failure states would look like yet.
>
>>
>>
>> Okay just 2 more cents!
>>
>
> Mine as well.  This is a worthwhile discussion/exercise IMO as we need
> to get to a common understanding of what we are doing here.
>
>>
>> Cheers, Peter
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen
>> <peter at aba-instituut.nl> wrote:
>>         Hi Ken,
>>
>>         On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey
>>         <Ken.Dickey at whidbey.com> wrote:
>>                 On Tue, 21 Jul 2015 07:59:47 -0700
>>                 Peter van Rooijen <peter at aba-instituut.nl> wrote:
>>
>>                 >> I was thinking: "What should a Feature Test be?".
>>
>>                 I tend to think of a hierarchy of requirements.
>>                 Perhaps something like:
>>
>>                  Feature requireAll: #( <feature name>.. ).
>>                  Classes requireAll: #( <class name>.. ).
>>                  Methods requireAll: #( <selector name>.. ).
>>                  MethodsForKind class: <class name> requireAll:
>>                 #( <selectorName>.. ).
>>                  Tests requireAllPass: #( <unit test name> ).
>>
>>
>>         Yeah, that's not at all what I'm thinking :). I'm thinking of
>>         something that is automatically runnable, like a unit test. It
>>         tests something, like a un test. But if the test does not
>>         pass, it is NOT a bug, unlike with a unit test. It's just that
>>         we would like to know about it. Also, with nit tests there is
>>         the assumption that the code that represents the test is
>>         always compilable, with feature tests that cannot be assumed,
>>         so there would need to be protection against that. Of course
>>         we want to be able to load the feature tests in any condition,
>>         so putting it in the form of source text and compiling that is
>>         a possibility. The fact that that makes it slower than unit
>>         tests is not a problem, because unlike unit tests, we don't
>>         have to run them continuously.
>>
>>                 The Feature class lets us require named (macro)
>>                 Features with a version check.  I prefer that
>>                 requirements at this level actually load the packages
>>                 required and only report failure if that is not
>>                 possible, although we could have a "preflight" verson
>>                 which just checks without loading any featured
>>                 packages.
>>
>>
>>         I see. The thing I was thinking about merely reports about the
>>         state of a system (of code), it does not try to configure that
>>         in any way.
>>
>>
>>                 API's are basically "protocols", which in the absence
>>                 of symbolic execution means checking that classes and
>>                 specific method selectors exist, or more specifically,
>>                 method selectors are applicable to specific KindOf:
>>                 classes.
>>
>>
>>         Well, in my mind some semantics could be expected (and tested
>>         for). For instance I might be interested if there is a
>>         DateTime class in the image and if it implements the ANSI
>>         DateAndTime protocol (not sure if there is one named that). Or
>>         perhaps another class that does that. These tests can test
>>         some actual semantics no problem.
>>
>>
>>         Perhaps some of you remember that Camp Smalltalk started with
>>         Ralph Johnson's desire to build an ANSI test suite. The way
>>         people went about it (extension methods to SUnit? I don't
>>         really remember) was wrong and could not possibly work (in my
>>         opinion anyway), but I could not convince a lot of people and
>>         such a test suite was never written. But with Feature Tests I
>>         think we could come a long way.
>>
>>                 Further, some Unit Tests may be required to pass to
>>                 ensure compliance with some specification.
>>
>>
>>         Well, except that the tests would not be unit tests in the
>>         strictest sense. But semantics, not merely interface, can be
>>         tested for sure.
>>
>>                 We should be able to automate at least some of this
>>
>>
>>         Automate the running of the feature tests? Of course.
>>
>>                 including a first pass of generating the test sets,
>>                 which could then be pruned by hand as required.
>>
>>
>>         That I don't see happening. You test what YOU think is
>>         important to be sure of. No machine can decide/calculate that
>>         for you. Perhaps I'm misunderstanding you.
>>
>>
>>         Cheers, Peter
>>
>>
>>                 $0.02,
>>                 -KenD
>>
>>
>>
>>         _______________________________________________
>>         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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From nicolas.cellier.aka.nice at gmail.com  Wed Jul  1 07:52:56 2015
From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier)
Date: Wed, 1 Jul 2015 14:52:56 +0200
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
References: <1435576183.2309.69.camel@gmail.com>
	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>
	<55917102.4030901@jvuletich.org>
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
Message-ID: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>

2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:

> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>
> > Hi folks,
> >
> > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> > > On Mon, 29 Jun 2015 07:09:43 -0400
> > > "Phil (list)"<pbpublist at gmail.com>  wrote:
> > >> ..  Is it
> > >> worth having a class for this vs. raising the more general
> > Notification
> > >> and then checking for a #ReparseAfterSourceEditing signal, and if
> > it
> > >> isn't, re-raise Notification in its sole handler?
> > >> ..
> > >> This is a specific example of the more general question of where
> > to draw
> > >> the line on having single, or very limited, use classes and
> > methods vs.
> > >> adding a tiny bit of complexity in one or two methods to simplify
> > the
> > >> overall image or package in question.  Thoughts?
> > > I would say the overriding goal is clarity.
> > >
> > > It is important work to refactor code to have the same behavior
> > but be easier to understand.
> > >
> > > A Smalltalk style goal is to have small methods which do things
> > clearly.  This tends to lead to lots of small methods.
> > >
> > > Specializing classes for one or just a few methods may seem
> > wasteful, but computer resources are cheap.
> > >
> > > Look at class #PartsBinMorph.  Would you say the having the
> > additional class is wasteful?
> > >
> > > It is a tough balance.  Aesthetics and restraint require judgement
> > and we don't always get it right.  It takes time.
> > >
> > > I only have so many life hours left.  I feel my time is valuable.
> > I prefer to understand.
> > >
> > > Thank you so much for taking the time to make Cuis more
> > comprehensible.
> > >
> > > $0.02
> > > -KenD
> >
> > I fully support Ken. I don't think that a general answer is correct
> > in
> > all cases here. It is a matter of making code easy to understand.
> > But
> > also making it consistent and pretty.
> >
> > In general, I don't like making general classes know much about
> > details
> > of specific use cases. But there might be exceptions.
> >
> > If you feel like experimenting with this kind of stuff, send your
> > suggestions to the mail list so we can discuss.
> >
> > In the particular case of ReparseAfterSourceEditing, I agree that a
> > class that does nothing is a bit strange. But, what is the
> > alternative?
> > How would the sole exception handler know what to do with a general
> > Notification? I think the handler looks quite reasonable right now.
> > And
> > the pollution of the global space might be tolerable if the
> > alternative
> > is more convoluted code...
> >
>
> Making code easy to understand is very valuable. Simple things should be
> simple to
> accomplish, but achieving this in an API may not always be easy.
>
> This weekend I spent lots of "quality time" with the debugger, trying to
> figure out why I could
> not get a new window with a PluggableListMorph to work like another one
> which had exactly
> the behavior I wanted. The bug was that a method referred to by the
> #indexSetter: keyword
> needed to send the #selectedItem: message, which is not mentioned by
> keyword. Not sure
> what the answer is for that one but I'm working on notes to try to avoid
> that stupid mistake in
> the future. :)
>
> I'm just saying we should do anything we can to enhance clarity as well as
> simplify.
>
>  - Dan
>
>
Since you are using the right keywords, maybe it's time to view it again
Simple made easy
http://www.infoq.com/presentations/Simple-Made-Easy

_______________________________________________
> 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/20150701/06743c77/attachment-0003.html>

From peter at aba-instituut.nl  Wed Jul  1 15:10:31 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 1 Jul 2015 22:10:31 +0200
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>
	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>
	<55917102.4030901@jvuletich.org>
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
Message-ID: <CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>

Hi all,

I believe that a class can be justified simply because it gives you
an intention revealing name in the code, and room to put a
class comment (possibly an extensive one).

Especially with exceptions it can be difficult to understand
what exactly the exception is for, and a class comment can
be extremely helpful.

So, one thing that I am saying is that a class with NO behavior
but a well-chosen name, superclass and a clear class comment, can
be a very valuable part of a system.

Another thing I believe is that a class by itself is not very complex.
Complex in the sense of adding to the overall complexity of the system.

I have been interested in complexity and reducing it for a very long time
(since before I started with Smalltalk) and I have often thought about
the rules one would put into a tool that automatically measured the
complexity of a system of code.

One application of such a tool would be refactoring. Generally, after I
refactor, all my old tests should still run, but also, my overall complexity
should be lower.

At least, that was my thinking, and a tool that measures
complexity could help with that. In a sense it would be a more
sophisticated version of the "rule of three".

In any case, I never implemented such a tool, but did develop a set of
heuristics/rules that I let guide me to decide whether I should extract
methods, extract classes, etc. Part of these heuristics was that a class
by itself did not add that much.

I don't remember most of my rules although I probably still follow them
intuitively. Perhaps a class added more complexity than a method, but not
more than two methods, I don't really know.

I wonder what others do to decide how to factor code.

Cheers, Peter



On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>
>> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>>
>> > Hi folks,
>> >
>> > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>> > > On Mon, 29 Jun 2015 07:09:43 -0400
>> > > "Phil (list)"<pbpublist at gmail.com>  wrote:
>> > >> ..  Is it
>> > >> worth having a class for this vs. raising the more general
>> > Notification
>> > >> and then checking for a #ReparseAfterSourceEditing signal, and if
>> > it
>> > >> isn't, re-raise Notification in its sole handler?
>> > >> ..
>> > >> This is a specific example of the more general question of where
>> > to draw
>> > >> the line on having single, or very limited, use classes and
>> > methods vs.
>> > >> adding a tiny bit of complexity in one or two methods to simplify
>> > the
>> > >> overall image or package in question.  Thoughts?
>> > > I would say the overriding goal is clarity.
>> > >
>> > > It is important work to refactor code to have the same behavior
>> > but be easier to understand.
>> > >
>> > > A Smalltalk style goal is to have small methods which do things
>> > clearly.  This tends to lead to lots of small methods.
>> > >
>> > > Specializing classes for one or just a few methods may seem
>> > wasteful, but computer resources are cheap.
>> > >
>> > > Look at class #PartsBinMorph.  Would you say the having the
>> > additional class is wasteful?
>> > >
>> > > It is a tough balance.  Aesthetics and restraint require judgement
>> > and we don't always get it right.  It takes time.
>> > >
>> > > I only have so many life hours left.  I feel my time is valuable.
>> > I prefer to understand.
>> > >
>> > > Thank you so much for taking the time to make Cuis more
>> > comprehensible.
>> > >
>> > > $0.02
>> > > -KenD
>> >
>> > I fully support Ken. I don't think that a general answer is correct
>> > in
>> > all cases here. It is a matter of making code easy to understand.
>> > But
>> > also making it consistent and pretty.
>> >
>> > In general, I don't like making general classes know much about
>> > details
>> > of specific use cases. But there might be exceptions.
>> >
>> > If you feel like experimenting with this kind of stuff, send your
>> > suggestions to the mail list so we can discuss.
>> >
>> > In the particular case of ReparseAfterSourceEditing, I agree that a
>> > class that does nothing is a bit strange. But, what is the
>> > alternative?
>> > How would the sole exception handler know what to do with a general
>> > Notification? I think the handler looks quite reasonable right now.
>> > And
>> > the pollution of the global space might be tolerable if the
>> > alternative
>> > is more convoluted code...
>> >
>>
>> Making code easy to understand is very valuable. Simple things should be
>> simple to
>> accomplish, but achieving this in an API may not always be easy.
>>
>> This weekend I spent lots of "quality time" with the debugger, trying to
>> figure out why I could
>> not get a new window with a PluggableListMorph to work like another one
>> which had exactly
>> the behavior I wanted. The bug was that a method referred to by the
>> #indexSetter: keyword
>> needed to send the #selectedItem: message, which is not mentioned by
>> keyword. Not sure
>> what the answer is for that one but I'm working on notes to try to avoid
>> that stupid mistake in
>> the future. :)
>>
>> I'm just saying we should do anything we can to enhance clarity as well
>> as simplify.
>>
>>  - Dan
>>
>>
> Since you are using the right keywords, maybe it's time to view it again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy
>
> _______________________________________________
>> 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/20150701/09108f29/attachment-0003.html>

From peter at aba-instituut.nl  Wed Jul  1 15:20:11 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 1 Jul 2015 22:20:11 +0200
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1435627676.2309.133.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<54FEF396.1070509@jvuletich.org>
	<1426014697.2279.25.camel@gmail.com>
	<1435627676.2309.133.camel@gmail.com>
Message-ID: <CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>

Not sure if this is related but InspectorWindow does not cut
off the text in the title bar of the window eagerly enough.

Take an inspector whose title is too long for the window
and see how the text is cut off mid-character at the right
border of the window. Move the window around and it leaves
a trail, exactly where the character pixels touch the side.

BTW, the devoweling of inspector titles I strongly dislike.
If that could be taken out, great. Or perhaps someone has
real good use for that?

Thanks, Peter

On Tue, Jun 30, 2015 at 3:27 AM, Phil (list) <pbpublist at gmail.com> wrote:

> An old issue with some new info...
>
> On Tue, 2015-03-10 at 15:11 -0400, Phil (list) wrote:
> > On Tue, 2015-03-10 at 10:37 -0300, Juan Vuletich wrote:
> > > Hi Phil,
> > >
> > > (inline)
> > > On 3/9/2015 6:54 AM, Phil (list) wrote:
> > > > I've been testing some of my code after migrating to the local
> > > > coordinate system and am running into a few things:
> > > >
> > > > 1) Morph stepping appears to be non-functional (at least in terms of
> > > > running the code as-is from Cuis 4.0)
> > >
> > > You already found #stepAt: . In any case, the "message names" tool is
> > > your friend.
> > >
> >
> > As was FrameRateMorph.
> >
> > > > 2) Halos are behaving badly on occasion... drawing artifacts,
> problems
> > > > resizing, experiencing the odd image crash here and there.
> > >
> > > Please, steps to reproduce.
> > >
> >
> > Working on narrowing down.
>
> At least the drawing artifacts issue doesn't appear to be Halo specific.
> I've been seeing it on occasion with other kinds of Morphs.  Today it
> finally dawned on me what is going on: Morphs are drawing outside of
> their bounds.  I think I have a reproducible scenario: in the Workspace
> type ReparseAfterSourceEditing, select and right click->Smalltalk
> Options->Method Source with it.  On my computer, the default window size
> results in the title text being drawn well outside of the Morph so
> there's no mistaking what's going on.  Drag the window around and notice
> the artifacts.  I think Halos and other Morphs are doing the same thing
> though less obviously.
>
>
> _______________________________________________
> 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/20150701/77b298a2/attachment-0003.html>

From pbpublist at gmail.com  Wed Jul  1 15:30:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 16:30:01 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<54FEF396.1070509@jvuletich.org> <1426014697.2279.25.camel@gmail.com>
	<1435627676.2309.133.camel@gmail.com>
	<CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>
Message-ID: <1435782601.2309.170.camel@gmail.com>

On Wed, 2015-07-01 at 22:20 +0200, Peter van Rooijen wrote:
> Not sure if this is related but InspectorWindow does not cut
> off the text in the title bar of the window eagerly enough.
> 

That's exactly the issue I'm referring to (though it is larger in scope
than just title bars.)

> 
> Take an inspector whose title is too long for the window
> and see how the text is cut off mid-character at the right
> border of the window. Move the window around and it leaves
> a trail, exactly where the character pixels touch the side.
> 

Yup.

> 
> BTW, the devoweling of inspector titles I strongly dislike.
> If that could be taken out, great. Or perhaps someone has
> real good use for that?
> 

I'm not wild about it either but in many cases I think it is probably
better than just truncating the string.  I think that's one of those
things where a better approach would be nice but so far no one has come
up with one...

> 
> Thanks, Peter
> 
> On Tue, Jun 30, 2015 at 3:27 AM, Phil (list) <pbpublist at gmail.com>
> wrote:
>         An old issue with some new info...
>         
>         On Tue, 2015-03-10 at 15:11 -0400, Phil (list) wrote:
>         > On Tue, 2015-03-10 at 10:37 -0300, Juan Vuletich wrote:
>         > > Hi Phil,
>         > >
>         > > (inline)
>         > > On 3/9/2015 6:54 AM, Phil (list) wrote:
>         > > > I've been testing some of my code after migrating to the
>         local
>         > > > coordinate system and am running into a few things:
>         > > >
>         > > > 1) Morph stepping appears to be non-functional (at least
>         in terms of
>         > > > running the code as-is from Cuis 4.0)
>         > >
>         > > You already found #stepAt: . In any case, the "message
>         names" tool is
>         > > your friend.
>         > >
>         >
>         > As was FrameRateMorph.
>         >
>         > > > 2) Halos are behaving badly on occasion... drawing
>         artifacts, problems
>         > > > resizing, experiencing the odd image crash here and
>         there.
>         > >
>         > > Please, steps to reproduce.
>         > >
>         >
>         > Working on narrowing down.
>         
>         At least the drawing artifacts issue doesn't appear to be Halo
>         specific.
>         I've been seeing it on occasion with other kinds of Morphs.
>         Today it
>         finally dawned on me what is going on: Morphs are drawing
>         outside of
>         their bounds.  I think I have a reproducible scenario: in the
>         Workspace
>         type ReparseAfterSourceEditing, select and right
>         click->Smalltalk
>         Options->Method Source with it.  On my computer, the default
>         window size
>         results in the title text being drawn well outside of the
>         Morph so
>         there's no mistaking what's going on.  Drag the window around
>         and notice
>         the artifacts.  I think Halos and other Morphs are doing the
>         same thing
>         though less obviously.
>         
>         
>         _______________________________________________
>         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 Ken.Dickey at whidbey.com  Wed Jul  1 15:35:34 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Wed, 1 Jul 2015 13:35:34 -0700
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1435782601.2309.170.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<54FEF396.1070509@jvuletich.org>
	<1426014697.2279.25.camel@gmail.com>
	<1435627676.2309.133.camel@gmail.com>
	<CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>
	<1435782601.2309.170.camel@gmail.com>
Message-ID: <20150701133534.7bcc7623e97ea01308b48194@whidbey.com>

On Wed, 01 Jul 2015 16:30:01 -0400
"Phil (list)" <pbpublist at gmail.com> wrote:

> > BTW, the devoweling of inspector titles I strongly dislike.
> > If that could be taken out, great. Or perhaps someone has
> > real good use for that?
> 
> I'm not wild about it either but in many cases I think it is probably
> better than just truncating the string.  I think that's one of those
> things where a better approach would be nice but so far no one has come
> up with one...

I find it much more helpful than truncated strings.

FYI,
-KenD



From pbpublist at gmail.com  Wed Jul  1 15:54:22 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 16:54:22 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>
	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>
	<55917102.4030901@jvuletich.org>
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
Message-ID: <1435784062.2309.192.camel@gmail.com>

On Wed, 2015-07-01 at 22:10 +0200, Peter van Rooijen wrote:
> Hi all,
> 
> 
> I believe that a class can be justified simply because it gives you
> an intention revealing name in the code, and room to put a
> class comment (possibly an extensive one).
> 

I believe that's the thinking that results in most of the current
Exception subclasses.  I personally don't care for it, but will go with
the consensus which seems to be OK with it.

> 
> Especially with exceptions it can be difficult to understand
> what exactly the exception is for, and a class comment can
> be extremely helpful.
> 

But Exceptions have a #signal: value which could also easily convey that
information.  (that's not always true, but the point is there are other
ways to convey the information other than subclassing)  Also keep in
mind that many exceptions, such as the one I was pointing out, are never
even seen by the user: they are used as an alternate messaging channel
by the code.

> 
> So, one thing that I am saying is that a class with NO behavior
> but a well-chosen name, superclass and a clear class comment, can
> be a very valuable part of a system.
> 
> 
> Another thing I believe is that a class by itself is not very complex.
> Complex in the sense of adding to the overall complexity of the
> system.
> 

True, a single class by itself is not very complex.  Multiply that by
100x or more and the story changes.  To me, one of the more obvious
aspects of complexity is the aggregate # of classes/methods/lines of
code in a system.  In this particular case, I was wondering out loud if
this particular trade-off (i.e. creating a class to save 1-2 lines of
code) was worth it.  I find it interesting that exception handling is
one of the younger parts of Smalltalk and, to me at least, it really
stands out as being rather strangely implemented in terms of the class
hierarchy.

> 
> I have been interested in complexity and reducing it for a very long
> time
> (since before I started with Smalltalk) and I have often thought about
> the rules one would put into a tool that automatically measured the
> complexity of a system of code.
> 
> 
> One application of such a tool would be refactoring. Generally, after
> I
> refactor, all my old tests should still run, but also, my overall
> complexity
> should be lower.
> 
> 
> At least, that was my thinking, and a tool that measures
> complexity could help with that. In a sense it would be a more
> sophisticated version of the "rule of three".
> 
> 
> In any case, I never implemented such a tool, but did develop a set of
> heuristics/rules that I let guide me to decide whether I should
> extract
> methods, extract classes, etc. Part of these heuristics was that a
> class
> by itself did not add that much.
> 
> 
> I don't remember most of my rules although I probably still follow
> them
> intuitively. Perhaps a class added more complexity than a method, but
> not
> more than two methods, I don't really know.
> 
> 
> I wonder what others do to decide how to factor code.
> 

You might want to take a look at Moose http://www.moosetechnology.org/
It's a tool to help you analyze and understand a given body of code.
It's a bit fragile/brittle/incomplete, but right now it's about the best
I've found to date to try to analyze and quantify complexity.  Also, you
could take a look at the work VPRI is doing related to FoNC/STEPS as
minimizing complexity is core to what they are working on.

> 
> Cheers, Peter
> 
> 
> 
> 
> 
> On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>         
>         
>         2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>                 On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>                 
>                 > Hi folks,
>                 >
>                 > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>                 > > On Mon, 29 Jun 2015 07:09:43 -0400
>                 > > "Phil (list)"<pbpublist at gmail.com>  wrote:
>                 > >> ..  Is it
>                 > >> worth having a class for this vs. raising the
>                 more general
>                 > Notification
>                 > >> and then checking for a
>                 #ReparseAfterSourceEditing signal, and if
>                 > it
>                 > >> isn't, re-raise Notification in its sole handler?
>                 > >> ..
>                 > >> This is a specific example of the more general
>                 question of where
>                 > to draw
>                 > >> the line on having single, or very limited, use
>                 classes and
>                 > methods vs.
>                 > >> adding a tiny bit of complexity in one or two
>                 methods to simplify
>                 > the
>                 > >> overall image or package in question.  Thoughts?
>                 > > I would say the overriding goal is clarity.
>                 > >
>                 > > It is important work to refactor code to have the
>                 same behavior
>                 > but be easier to understand.
>                 > >
>                 > > A Smalltalk style goal is to have small methods
>                 which do things
>                 > clearly.  This tends to lead to lots of small
>                 methods.
>                 > >
>                 > > Specializing classes for one or just a few methods
>                 may seem
>                 > wasteful, but computer resources are cheap.
>                 > >
>                 > > Look at class #PartsBinMorph.  Would you say the
>                 having the
>                 > additional class is wasteful?
>                 > >
>                 > > It is a tough balance.  Aesthetics and restraint
>                 require judgement
>                 > and we don't always get it right.  It takes time.
>                 > >
>                 > > I only have so many life hours left.  I feel my
>                 time is valuable.
>                 > I prefer to understand.
>                 > >
>                 > > Thank you so much for taking the time to make Cuis
>                 more
>                 > comprehensible.
>                 > >
>                 > > $0.02
>                 > > -KenD
>                 >
>                 > I fully support Ken. I don't think that a general
>                 answer is correct
>                 > in
>                 > all cases here. It is a matter of making code easy
>                 to understand.
>                 > But
>                 > also making it consistent and pretty.
>                 >
>                 > In general, I don't like making general classes know
>                 much about
>                 > details
>                 > of specific use cases. But there might be
>                 exceptions.
>                 >
>                 > If you feel like experimenting with this kind of
>                 stuff, send your
>                 > suggestions to the mail list so we can discuss.
>                 >
>                 > In the particular case of ReparseAfterSourceEditing,
>                 I agree that a
>                 > class that does nothing is a bit strange. But, what
>                 is the
>                 > alternative?
>                 > How would the sole exception handler know what to do
>                 with a general
>                 > Notification? I think the handler looks quite
>                 reasonable right now.
>                 > And
>                 > the pollution of the global space might be tolerable
>                 if the
>                 > alternative
>                 > is more convoluted code...
>                 >
>                 
>                 
>                 Making code easy to understand is very valuable.
>                 Simple things should be simple to
>                 accomplish, but achieving this in an API may not
>                 always be easy.
>                 
>                 This weekend I spent lots of "quality time" with the
>                 debugger, trying to figure out why I could
>                 not get a new window with a PluggableListMorph to work
>                 like another one which had exactly
>                 the behavior I wanted. The bug was that a method
>                 referred to by the #indexSetter: keyword
>                 needed to send the #selectedItem: message, which is
>                 not mentioned by keyword. Not sure
>                 what the answer is for that one but I'm working on
>                 notes to try to avoid that stupid mistake in
>                 the future. :)
>                 
>                 I'm just saying we should do anything we can to
>                 enhance clarity as well as simplify.
>                 
>                  - Dan
>                 
>                 
>         
>         
>         Since you are using the right keywords, maybe it's time to
>         view it again
>         
>         Simple made easy
>         http://www.infoq.com/presentations/Simple-Made-Easy 
>         
>         
>                 _______________________________________________
>                 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Wed Jul  1 16:33:32 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 01 Jul 2015 17:33:32 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <20150701133534.7bcc7623e97ea01308b48194@whidbey.com>
References: <1425894846.2281.37.camel@gmail.com>,
	<1435782601.2309.170.camel@gmail.com>,
	<20150701133534.7bcc7623e97ea01308b48194@whidbey.com>
Message-ID: <55945CAC.22357.1785ED9@dnorton.mindspring.com>

On 1 Jul 2015 at 13:35, Ken.Dickey wrote:

> On Wed, 01 Jul 2015 16:30:01 -0400
> "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > > BTW, the devoweling of inspector titles I strongly dislike.
> > > If that could be taken out, great. Or perhaps someone has
> > > real good use for that?
> > 
> > I'm not wild about it either but in many cases I think it is
> probably
> > better than just truncating the string.  I think that's one of
> those
> > things where a better approach would be nice but so far no one has
> come
> > up with one...
> 
> I find it much more helpful than truncated strings.
> 
> FYI,
> -KenD
> 

+1

Best regards,
 - Dan



From juan at jvuletich.org  Wed Jul  1 19:29:42 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:29:42 -0300
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>	<55917102.4030901@jvuletich.org>	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
Message-ID: <559485F6.3030408@jvuletich.org>

On 7/1/2015 9:52 AM, Nicolas Cellier wrote:
> ...
>
> Since you are using the right keywords, maybe it's time to view it again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy

Thanks Nicolas. This is absolutely wonderful! Really inspiring.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  1 19:37:40 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:37:40 -0300
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>	<55917102.4030901@jvuletich.org>	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
Message-ID: <559487D4.30603@jvuletich.org>

On 7/1/2015 5:10 PM, Peter van Rooijen wrote:
> ...
>
> I don't remember most of my rules although I probably still follow them
> intuitively. Perhaps a class added more complexity than a method, but not
> more than two methods, I don't really know.
>
> I wonder what others do to decide how to factor code.
>
> Cheers, Peter


To me Smalltalk code is an expression of human knowledge. I refactor 
code when I understand better, to express that new understanding.

Writing code is like writing course material, or a technical book on 
some subject. Good code is like a good book. You read it and understand. 
That's the gold standard.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  1 19:43:08 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:43:08 -0300
Subject: [Cuis] Updates
Message-ID: <5594891C.6090104@jvuletich.org>

Hi Folks,

Today I did a commit. I fixed recently reported issues (halos, window 
labels, etc). I also added Dan Norton's port of BouncingAtoms to the 
packages folder (thanks Dan!).

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  1 19:51:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:51:34 -0300
Subject: [Cuis] Display units and UI widgets in Morphic 3
In-Reply-To: <1435714029.2309.155.camel@gmail.com>
References: <1435714029.2309.155.camel@gmail.com>
Message-ID: <55948B16.4060100@jvuletich.org>

Hi Phil,

On 6/30/2015 10:27 PM, Phil (list) wrote:
> Juan,
>
> I vaguely recall previously having a discussion somewhere about unit
> scaling / high dpi but can't seem to find the thread.  Anyways, this
> question is specific to Morphic 3: from a UI creation standpoint is
> Morphic 3 still going to use pixel-based units or will some other unit
> of measure be used? i.e. if you design a UI and have say a 32x32
> button, is that going to need to be scaled up (understanding that this
> will be trivial for Morphic 3 to do) for high-dpi displays?  Is this
> even a Morphic concern or will it be up to Cuis as an environment to
> have a preference for display scaling?

In Morphic 3 you can use any unit you want for your Morphs. It is 
perfectly reasonable to use pixels, at your preferred zoom level and 
DPI. You can also use domain specific units.

The user is able to scale the World or any particular Morph to suit his 
needs or taste, much like you do in Google Maps, in Satellite mode.

> Related to this is the question of how much do you anticipate
> higher-level UI code needing to be reworked for Morphic 3? One
> of the many projects I've been playing around with giving things a bit
> of a face-lift (i.e. a logging framework that can handle non-textual
> data, grid and multi-element list pluggable morphs, visualization
> widgets, etc... sort of along the lines of what is being done in Pharo
> with the playground stuff) and am just wondering how far I should go
> with this work before seeing what's involved in migrating to Morphic 3?

In principle, there is no code rework needed. The local coordinates, 
locations, etc. are the standard in Cuis since a few years ago.

The difference is that Morphic 3 will make some new things possible, and 
others will be simpler. It will also give the user a better control on 
how to use the UI.

> (I did take a quick peek at the Morphic 3 package but didn't find
> answers as it looks like you're still working out the lower level
> details)
>
> Thanks,
> Phil

Well, but that experimental code already can draw essentially any Cuis 
morphic World. It is just some lower level details what is missing to 
make it the main graphics engine for Cuis.

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Wed Jul  1 20:59:54 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 21:59:54 -0400
Subject: [Cuis] Updates
In-Reply-To: <5594891C.6090104@jvuletich.org>
References: <5594891C.6090104@jvuletich.org>
Message-ID: <1435802394.2309.194.camel@gmail.com>

On Wed, 2015-07-01 at 21:43 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> Today I did a commit. I fixed recently reported issues (halos, window 
> labels, etc). I also added Dan Norton's port of BouncingAtoms to the 
> packages folder (thanks Dan!).
> 

Looks good to me. (heh... now that Cuis isn't leaving behind artifacts
it exposed the issue that some of my morphs were too :-)

> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From pbpublist at gmail.com  Wed Jul  1 21:02:43 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 22:02:43 -0400
Subject: [Cuis] Display units and UI widgets in Morphic 3
In-Reply-To: <55948B16.4060100@jvuletich.org>
References: <1435714029.2309.155.camel@gmail.com>
	<55948B16.4060100@jvuletich.org>
Message-ID: <1435802563.2309.197.camel@gmail.com>

On Wed, 2015-07-01 at 21:51 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 6/30/2015 10:27 PM, Phil (list) wrote:
> > Juan,
> >
> > I vaguely recall previously having a discussion somewhere about unit
> > scaling / high dpi but can't seem to find the thread.  Anyways, this
> > question is specific to Morphic 3: from a UI creation standpoint is
> > Morphic 3 still going to use pixel-based units or will some other unit
> > of measure be used? i.e. if you design a UI and have say a 32x32
> > button, is that going to need to be scaled up (understanding that this
> > will be trivial for Morphic 3 to do) for high-dpi displays?  Is this
> > even a Morphic concern or will it be up to Cuis as an environment to
> > have a preference for display scaling?
> 
> In Morphic 3 you can use any unit you want for your Morphs. It is 
> perfectly reasonable to use pixels, at your preferred zoom level and 
> DPI. You can also use domain specific units.
> 
> The user is able to scale the World or any particular Morph to suit his 
> needs or taste, much like you do in Google Maps, in Satellite mode.
> 

Excellent... that's what I was hoping for.

> > Related to this is the question of how much do you anticipate
> > higher-level UI code needing to be reworked for Morphic 3? One
> > of the many projects I've been playing around with giving things a bit
> > of a face-lift (i.e. a logging framework that can handle non-textual
> > data, grid and multi-element list pluggable morphs, visualization
> > widgets, etc... sort of along the lines of what is being done in Pharo
> > with the playground stuff) and am just wondering how far I should go
> > with this work before seeing what's involved in migrating to Morphic 3?
> 
> In principle, there is no code rework needed. The local coordinates, 
> locations, etc. are the standard in Cuis since a few years ago.
> 
> The difference is that Morphic 3 will make some new things possible, and 
> others will be simpler. It will also give the user a better control on 
> how to use the UI.
> 

Better and better!

> > (I did take a quick peek at the Morphic 3 package but didn't find
> > answers as it looks like you're still working out the lower level
> > details)
> >
> > Thanks,
> > Phil
> 
> Well, but that experimental code already can draw essentially any Cuis 
> morphic World. It is just some lower level details what is missing to 
> make it the main graphics engine for Cuis.
> 

Hmm... then I need to take another look.  I probably wasn't loading
and/or initializing things correctly.

> Cheers,
> Juan Vuletich





From dnorton at mindspring.com  Thu Jul  2 20:15:27 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 02 Jul 2015 21:15:27 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>,
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>,
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
Message-ID: <5595E22F.2684.23EA964@dnorton.mindspring.com>

Hi,

I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The 
question is how to view it without disabling my antivirus plus surrendering a bunch of 
"required" info. BTW I'm running Win7, IE, and ESET.

Any other possibilities?

 - Dan

On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:

> 
> 
> 
> 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>     On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>     
>     > Hi folks,
>     >
>     > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>     > > On Mon, 29 Jun 2015 07:09:43 -0400
>     > > "Phil (list)"<pbpublist at gmail.com>? wrote:
>     > >> ..? Is it
>     > >> worth having a class for this vs. raising the more
> general
>     > Notification
>     > >> and then checking for a #ReparseAfterSourceEditing signal,
> and if
>     > it
>     > >> isn't, re-raise Notification in its sole handler?
>     > >> ..
>     > >> This is a specific example of the more general question of
> where
>     > to draw
>     > >> the line on having single, or very limited, use classes
> and
>     > methods vs.
>     > >> adding a tiny bit of complexity in one or two methods to
> simplify
>     > the
>     > >> overall image or package in question.? Thoughts?
>     > > I would say the overriding goal is clarity.
>     > >
>     > > It is important work to refactor code to have the same
> behavior
>     > but be easier to understand.
>     > >
>     > > A Smalltalk style goal is to have small methods which do
> things
>     > clearly.? This tends to lead to lots of small methods.
>     > >
>     > > Specializing classes for one or just a few methods may
> seem
>     > wasteful, but computer resources are cheap.
>     > >
>     > > Look at class #PartsBinMorph.? Would you say the having
> the
>     > additional class is wasteful?
>     > >
>     > > It is a tough balance.? Aesthetics and restraint require
> judgement
>     > and we don't always get it right.? It takes time.
>     > >
>     > > I only have so many life hours left.? I feel my time is
> valuable.
>     > I prefer to understand.
>     > >
>     > > Thank you so much for taking the time to make Cuis more
>     > comprehensible.
>     > >
>     > > $0.02
>     > > -KenD
>     >
>     > I fully support Ken. I don't think that a general answer is
> correct
>     > in
>     > all cases here. It is a matter of making code easy to
> understand.
>     > But
>     > also making it consistent and pretty.
>     >
>     > In general, I don't like making general classes know much
> about
>     > details
>     > of specific use cases. But there might be exceptions.
>     >
>     > If you feel like experimenting with this kind of stuff, send
> your
>     > suggestions to the mail list so we can discuss.
>     >
>     > In the particular case of ReparseAfterSourceEditing, I agree
> that a
>     > class that does nothing is a bit strange. But, what is the
>     > alternative?
>     > How would the sole exception handler know what to do with a
> general
>     > Notification? I think the handler looks quite reasonable right
> now.
>     > And
>     > the pollution of the global space might be tolerable if the
>     > alternative
>     > is more convoluted code...
>     >
> 
>     Making code easy to understand is very valuable. Simple things
> should be simple to
>     accomplish, but achieving this in an API may not always be
> easy.
>     
>     This weekend I spent lots of "quality time" with the debugger,
> trying to figure out why I could
>     not get a new window with a PluggableListMorph to work like
> another one which had exactly
>     the behavior I wanted. The bug was that a method referred to by
> the #indexSetter: keyword
>     needed to send the #selectedItem: message, which is not
> mentioned by keyword. Not sure
>     what the answer is for that one but I'm working on notes to try
> to avoid that stupid mistake in
>     the future. :)
>     
>     I'm just saying we should do anything we can to enhance clarity
> as well as simplify.
>     
>     ?- Dan
> 
> 
> Since you are using the right keywords, maybe it's time to view it
> again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy
> 
>     _______________________________________________
>     Cuis mailing list
>     Cuis at jvuletich.org
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> 





From juan at jvuletich.org  Thu Jul  2 20:55:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 2 Jul 2015 22:55:27 -0300
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <5595E22F.2684.23EA964@dnorton.mindspring.com>
References: <1435576183.2309.69.camel@gmail.com>,
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>,
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<5595E22F.2684.23EA964@dnorton.mindspring.com>
Message-ID: <03aa649484e81e74b85e0dcfd201bc9e.squirrel@gator3294.hostgator.com>

Hi Dan,

It plays without problems in Chrome on my Win7 PC. No need to supply any
info at all.

HTH,
Juan vuletich

On Thu, July 2, 2015 10:15 pm, Dan Norton wrote:
> Hi,
>
>
> I would like to view this, especially since it is recommended by Nicolas,
> Paul, and Juan. The
> question is how to view it without disabling my antivirus plus
> surrendering a bunch of "required" info. BTW I'm running Win7, IE, and
> ESET.
>
>
> Any other possibilities?
>
>
> - Dan
>
>
> On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:
>
>
>>
>>
>>
>> 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>>
>>
>>> Hi folks,
>>>
>>>
>>> On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>>>
>>>> On Mon, 29 Jun 2015 07:09:43 -0400
>>>> "Phil (list)"<pbpublist at gmail.com>? wrote:
>>>>
>>>>> ..? Is it
>>>>> worth having a class for this vs. raising the more
>> general
>>> Notification
>>>
>>>>> and then checking for a #ReparseAfterSourceEditing signal,
>> and if
>>> it
>>>>> isn't, re-raise Notification in its sole handler? ..
>>>>> This is a specific example of the more general question of
>>>>>
>> where
>>> to draw
>>>>> the line on having single, or very limited, use classes
>> and
>>> methods vs.
>>>>> adding a tiny bit of complexity in one or two methods to
>> simplify
>>> the
>>>>> overall image or package in question.? Thoughts?
>>>> I would say the overriding goal is clarity.
>>>>
>>>>
>>>> It is important work to refactor code to have the same
>>>>
>> behavior
>>> but be easier to understand.
>>>>
>>>> A Smalltalk style goal is to have small methods which do
>>>>
>> things
>>> clearly.? This tends to lead to lots of small methods.
>>>>
>>>> Specializing classes for one or just a few methods may
>>>>
>> seem
>>> wasteful, but computer resources are cheap.
>>>>
>>>> Look at class #PartsBinMorph.? Would you say the having
>>>>
>> the
>>> additional class is wasteful?
>>>>
>>>> It is a tough balance.? Aesthetics and restraint require
>>>>
>> judgement
>>> and we don't always get it right.? It takes time.
>>>>
>>>> I only have so many life hours left.? I feel my time is
>>>>
>> valuable.
>>> I prefer to understand.
>>>
>>>>
>>>> Thank you so much for taking the time to make Cuis more
>>>>
>>> comprehensible.
>>>>
>>>> $0.02
>>>> -KenD
>>>>
>>>
>>> I fully support Ken. I don't think that a general answer is
>>>
>> correct
>>> in all cases here. It is a matter of making code easy to
>> understand.
>>> But
>>> also making it consistent and pretty.
>>>
>>> In general, I don't like making general classes know much
>>>
>> about
>>> details of specific use cases. But there might be exceptions.
>>>
>>> If you feel like experimenting with this kind of stuff, send
>>>
>> your
>>> suggestions to the mail list so we can discuss.
>>>
>>> In the particular case of ReparseAfterSourceEditing, I agree
>>>
>> that a
>>> class that does nothing is a bit strange. But, what is the
>>> alternative? How would the sole exception handler know what to do with
>>> a
>> general
>>> Notification? I think the handler looks quite reasonable right
>>>
>> now.
>>> And
>>> the pollution of the global space might be tolerable if the alternative
>>>  is more convoluted code...
>>>
>>
>> Making code easy to understand is very valuable. Simple things
>> should be simple to accomplish, but achieving this in an API may not
>> always be easy.
>>
>> This weekend I spent lots of "quality time" with the debugger,
>> trying to figure out why I could not get a new window with a
>> PluggableListMorph to work like
>> another one which had exactly the behavior I wanted. The bug was that a
>> method referred to by the #indexSetter: keyword needed to send the
>> #selectedItem: message, which is not
>> mentioned by keyword. Not sure what the answer is for that one but I'm
>> working on notes to try to avoid that stupid mistake in the future. :)
>>
>> I'm just saying we should do anything we can to enhance clarity
>> as well as simplify.
>>
>> ?- Dan
>>
>>
>>
>> Since you are using the right keywords, maybe it's time to view it
>> again Simple made easy
>> http://www.infoq.com/presentations/Simple-Made-Easy
>>
>>
>> _______________________________________________
>> 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 pbpublist at gmail.com  Thu Jul  2 21:03:41 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 02 Jul 2015 22:03:41 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <5595E22F.2684.23EA964@dnorton.mindspring.com>
References: <1435576183.2309.69.camel@gmail.com>
	, <5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	, <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<5595E22F.2684.23EA964@dnorton.mindspring.com>
Message-ID: <1435889021.2309.200.camel@gmail.com>

You're probably trying one of the download links.  You can stream the
video as long as JavaScript is enabled.  If you can't temporarily do
this in IE, I'd highly recommend keeping Firefox+NoScript around as it
lets you temporarily enable JavaScript & cookies for this type of
scenario.

On Thu, 2015-07-02 at 21:15 -0400, Dan Norton wrote:
> Hi,
> 
> I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The 
> question is how to view it without disabling my antivirus plus surrendering a bunch of 
> "required" info. BTW I'm running Win7, IE, and ESET.
> 
> Any other possibilities?
> 
>  - Dan
> 
> On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:
> 
> > 
> > 
> > 
> > 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
> >     On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
> >     
> >     > Hi folks,
> >     >
> >     > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> >     > > On Mon, 29 Jun 2015 07:09:43 -0400
> >     > > "Phil (list)"<pbpublist at gmail.com>  wrote:
> >     > >> ..  Is it
> >     > >> worth having a class for this vs. raising the more
> > general
> >     > Notification
> >     > >> and then checking for a #ReparseAfterSourceEditing signal,
> > and if
> >     > it
> >     > >> isn't, re-raise Notification in its sole handler?
> >     > >> ..
> >     > >> This is a specific example of the more general question of
> > where
> >     > to draw
> >     > >> the line on having single, or very limited, use classes
> > and
> >     > methods vs.
> >     > >> adding a tiny bit of complexity in one or two methods to
> > simplify
> >     > the
> >     > >> overall image or package in question.  Thoughts?
> >     > > I would say the overriding goal is clarity.
> >     > >
> >     > > It is important work to refactor code to have the same
> > behavior
> >     > but be easier to understand.
> >     > >
> >     > > A Smalltalk style goal is to have small methods which do
> > things
> >     > clearly.  This tends to lead to lots of small methods.
> >     > >
> >     > > Specializing classes for one or just a few methods may
> > seem
> >     > wasteful, but computer resources are cheap.
> >     > >
> >     > > Look at class #PartsBinMorph.  Would you say the having
> > the
> >     > additional class is wasteful?
> >     > >
> >     > > It is a tough balance.  Aesthetics and restraint require
> > judgement
> >     > and we don't always get it right.  It takes time.
> >     > >
> >     > > I only have so many life hours left.  I feel my time is
> > valuable.
> >     > I prefer to understand.
> >     > >
> >     > > Thank you so much for taking the time to make Cuis more
> >     > comprehensible.
> >     > >
> >     > > $0.02
> >     > > -KenD
> >     >
> >     > I fully support Ken. I don't think that a general answer is
> > correct
> >     > in
> >     > all cases here. It is a matter of making code easy to
> > understand.
> >     > But
> >     > also making it consistent and pretty.
> >     >
> >     > In general, I don't like making general classes know much
> > about
> >     > details
> >     > of specific use cases. But there might be exceptions.
> >     >
> >     > If you feel like experimenting with this kind of stuff, send
> > your
> >     > suggestions to the mail list so we can discuss.
> >     >
> >     > In the particular case of ReparseAfterSourceEditing, I agree
> > that a
> >     > class that does nothing is a bit strange. But, what is the
> >     > alternative?
> >     > How would the sole exception handler know what to do with a
> > general
> >     > Notification? I think the handler looks quite reasonable right
> > now.
> >     > And
> >     > the pollution of the global space might be tolerable if the
> >     > alternative
> >     > is more convoluted code...
> >     >
> > 
> >     Making code easy to understand is very valuable. Simple things
> > should be simple to
> >     accomplish, but achieving this in an API may not always be
> > easy.
> >     
> >     This weekend I spent lots of "quality time" with the debugger,
> > trying to figure out why I could
> >     not get a new window with a PluggableListMorph to work like
> > another one which had exactly
> >     the behavior I wanted. The bug was that a method referred to by
> > the #indexSetter: keyword
> >     needed to send the #selectedItem: message, which is not
> > mentioned by keyword. Not sure
> >     what the answer is for that one but I'm working on notes to try
> > to avoid that stupid mistake in
> >     the future. :)
> >     
> >     I'm just saying we should do anything we can to enhance clarity
> > as well as simplify.
> >     
> >      - Dan
> > 
> > 
> > Since you are using the right keywords, maybe it's time to view it
> > again
> > Simple made easy
> > http://www.infoq.com/presentations/Simple-Made-Easy
> > 
> >     _______________________________________________
> >     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 pbpublist at gmail.com  Sat Jul  4 16:30:43 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 04 Jul 2015 17:30:43 -0400
Subject: [Cuis] Display units and UI widgets in Morphic 3
In-Reply-To: <1435802563.2309.197.camel@gmail.com>
References: <1435714029.2309.155.camel@gmail.com>
	<55948B16.4060100@jvuletich.org> <1435802563.2309.197.camel@gmail.com>
Message-ID: <1436045443.2309.205.camel@gmail.com>

On Wed, 2015-07-01 at 22:02 -0400, Phil (list) wrote:
> On Wed, 2015-07-01 at 21:51 -0300, Juan Vuletich wrote:
> >
> > > (I did take a quick peek at the Morphic 3 package but didn't find
> > > answers as it looks like you're still working out the lower level
> > > details)
> > >
> > > Thanks,
> > > Phil
> > 
> > Well, but that experimental code already can draw essentially any Cuis 
> > morphic World. It is just some lower level details what is missing to 
> > make it the main graphics engine for Cuis.
> > 
> 
> Hmm... then I need to take another look.  I probably wasn't loading
> and/or initializing things correctly.
> 

Ahh... I see my mistake (duh!):  I was trying to load Morphic 3 into the
latest image rather than using your experimental image.  One minor
issue: that image is expecting to find the example SVG files in
svgSamples but the directory is now called SVGSamples.  (Easily
addressed with a symlink so I could run the demo render.)  It looks
very, very nice!

> > Cheers,
> > Juan Vuletich
> 





From Ken.Dickey at whidbey.com  Sat Jul  4 03:04:24 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sat, 4 Jul 2015 16:04:24 +0800
Subject: [Cuis] Package wants to require minimum revision on base
Message-ID: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>

Juan,

The Installed Packages browser used to be able to require a minimum revision on the base release.

I use this feature as a backstop when features change in the base release.

Any chance in getting this ability back?

Thanks much,
-KenD



From hannes.hirzel at gmail.com  Sat Jul  4 18:45:41 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 4 Jul 2015 23:45:41 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
Message-ID: <CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>

Juan,

And this brings up the question that it would be good to have a
'release tag' from time to time.

So that releases show up here

    https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases

Currently there are 0 releases. This is very straightforward to do in github.

This will facilitate checking if external packages still run fine.
There are about 50 commits in
Cuis-Smalltalk-Dev in first two quaters of 2015.

I think I some minor releases (i.e. 2 ... 6 a year) would be fine.

Thanks for considering this

--Hannes

On 7/4/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> Juan,
>
> The Installed Packages browser used to be able to require a minimum revision
> on the base release.
>
> I use this feature as a backstop when features change in the base release.
>
> Any chance in getting this ability back?
>
> Thanks much,
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From pbpublist at gmail.com  Sat Jul  4 19:51:18 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 04 Jul 2015 20:51:18 -0400
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
Message-ID: <1436057478.2309.229.camel@gmail.com>

On Sat, 2015-07-04 at 23:45 +0000, H. Hirzel wrote:
> Juan,
> 
> And this brings up the question that it would be good to have a
> 'release tag' from time to time.
> 
> So that releases show up here
> 
>     https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases
> 
> Currently there are 0 releases. This is very straightforward to do in github.
> 
> This will facilitate checking if external packages still run fine.
> There are about 50 commits in
> Cuis-Smalltalk-Dev in first two quaters of 2015.
> 
> I think I some minor releases (i.e. 2 ... 6 a year) would be fine.
> 
> Thanks for considering this
> 

It seems like for most of my packages I'd need to tie to a minimum build
# (what Ken asked for, i.e. #2400) rather than a version # (4.2.7 or
whatever) right now.  How do you envision using a version # given that
people will pretty much grab whatever the current build is at the time
they download Cuis?

> --Hannes
> 
> On 7/4/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> > Juan,
> >
> > The Installed Packages browser used to be able to require a minimum revision
> > on the base release.
> >
> > I use this feature as a backstop when features change in the base release.
> >
> > Any chance in getting this ability back?
> >
> > Thanks much,
> > -KenD
> >
> > _______________________________________________
> > 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  Sun Jul  5 09:01:06 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 05 Jul 2015 11:01:06 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
Message-ID: <559938A2.3040204@jvuletich.org>

Hi Ken,

On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
> Juan,
>
> The Installed Packages browser used to be able to require a minimum revision on the base release.
>
> I use this feature as a backstop when features change in the base release.
>
> Any chance in getting this ability back?
>
> Thanks much,
> -KenD

When was it lost?  I can't remember doing anything related to this...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sun Jul  5 09:03:44 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 05 Jul 2015 11:03:44 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
Message-ID: <55993940.8090704@jvuletich.org>

Hi Hannes,

Sure, let's discuss this. What do other people maintaining external 
packages think? This is for you...

Cheers,
Juan Vuletich

On 04/07/2015 08:45 p.m., H. Hirzel wrote:
> Juan,
>
> And this brings up the question that it would be good to have a
> 'release tag' from time to time.
>
> So that releases show up here
>
>      https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases
>
> Currently there are 0 releases. This is very straightforward to do in github.
>
> This will facilitate checking if external packages still run fine.
> There are about 50 commits in
> Cuis-Smalltalk-Dev in first two quaters of 2015.
>
> I think I some minor releases (i.e. 2 ... 6 a year) would be fine.
>
> Thanks for considering this
>
> --Hannes
>
> On 7/4/15, Ken.Dickey<Ken.Dickey at whidbey.com>  wrote:
>> Juan,
>>
>> The Installed Packages browser used to be able to require a minimum revision
>> on the base release.
>>
>> I use this feature as a backstop when features change in the base release.
>>
>> Any chance in getting this ability back?
>>
>> Thanks much,
>> -KenD
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>




From Ken.Dickey at whidbey.com  Sat Jul  4 20:57:51 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sun, 5 Jul 2015 09:57:51 +0800
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <559938A2.3040204@jvuletich.org>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<559938A2.3040204@jvuletich.org>
Message-ID: <20150705095751.c84ded291d123bac31348c46@whidbey.com>

On Sun, 05 Jul 2015 11:01:06 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Ken,
> 
> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
> > Juan,
> >
> > The Installed Packages browser used to be able to require a minimum revision on the base release.
> >
> > I use this feature as a backstop when features change in the base release.
> >
> > Any chance in getting this ability back?
> >
> > Thanks much,
> > -KenD
> 
> When was it lost?  I can't remember doing anything related to this...

Not sure when.

If there is more than one package loaded, one can Add Requirement with one option being the base release.  If only one package is loaded, one gets the "Required package must already be loaded" popup, rather than an option to require Cuis-Base.

-- 
-KenD



From dnorton at mindspring.com  Sun Jul  5 18:35:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 05 Jul 2015 19:35:22 -0400
Subject: [Cuis] Minor Direction Padding
Message-ID: <5599BF3A.26485.1F11628@dnorton.mindspring.com>

Greetings,

Four LayoutSpec class methods use "minorDirectionPadding:" as a keyword. The parameter 
can be a number or one of: #top, #left, #center, #right, or #bottom. AFAICT when the 
parameter is a number, it refers to the padding which will be applied in the minor direction. 
When it is a symbol, it effectively specifies that morphs will be located as the symbol name 
implies.

Attached are four convenience methods whose keyword emphasizes the visible (morph) 
instead of the invisible (padding). The "morphPlacement:" parameter can be  #top, #left, 
#center, #right, or #bottom. The methods are:

LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
LayoutSpec class>>proportionalWidth:proportionalHeight:morphPlacement:

Are these worth having in the base system?

 - Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: LayoutSpec class-convenience.zip
Type: application/zip
Size: 1988 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150705/2ebc6107/attachment-0003.zip>

From pbpublist at gmail.com  Mon Jul  6 03:01:56 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 06 Jul 2015 04:01:56 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
Message-ID: <1436169716.2678.46.camel@gmail.com>

Hannes,

Sorry for the delay... it's taken me longer than expected to get back to
it.  I really don't have any simple examples of porting as my stuff is
fairly involved (i.e. drawing and keyboard handling as part of a larger
OpenGL project etc.)  However, I do have more specifics re: what needed
to be done.

On Tue, 2015-03-10 at 06:56 +0000, H. Hirzel wrote:
> Phil,
> 
> could you please provide an example code snippet (Morph class).
> 
> Version 4.0
> vs
> Version 4.2
> ?
> 
> On 3/10/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > Created https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/48 for
> > this.
> >
> > On 3/9/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> On Mon, 2015-03-09 at 05:54 -0400, Phil (list) wrote:
> >>> 1) Morph stepping appears to be non-functional (at least in terms of
> >>> running the code as-is from Cuis 4.0)
> >>
> >> Figured this one out... #step appears to be obsolete, use #stepAt:
> >> instead.  In some cases now need to override #wantsSteps to return true
> >> (the default implementation now always returns false.  This is an issue
> >> only for some of my animated morphs.)
> >>

Morphic (continuous) animation

previously:
#step

now:
#stepAt: (just rename #step to #stepAt: milliseconds)
#wantsSteps (^true)

Notes:
1) If this change isn't made, you may get what appears to be animation,
but it's just the morph redrawing after damage.
2) Be sure to call #truncate on bounds etc. if your code can't handle
floats.
3) I used to have several direct Morph subclasses, but it appears that
they now need to be RectangleLikeMorph subclasses to maintain similar
behavior.



Keyboard focus handling

previously:
#handlesKeyboard (^ true)
#keyboardFocusChange: (call any code needed to deal with getting/losing
focus such as drawing a focus indicator)
#handleKeystroke: (when morph has focus, will receive keystroke)

now:
This is my best guess... are there any examples of working Morphs that
deal with keyboard focus but do *not* have text morphs?
#handlesKeyboard (no change)
#handlesMouseOver: (^true to get #mouseEnter: & #mouseLeave:)
#mouseEnter: event
	event hand newKeyboardFocus: self
#mouseLeave: event
	event hand newKeyboardFocus: nil
#keyStroke: event (receives the keystroke when focused, some event
accessors no longer exist)

Thanks,
Phil




From pbpublist at gmail.com  Mon Jul  6 03:12:39 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 06 Jul 2015 04:12:39 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1436169716.2678.46.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
	<1436169716.2678.46.camel@gmail.com>
Message-ID: <1436170359.2678.52.camel@gmail.com>

On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote:
> Hannes,
> 
> Sorry for the delay... it's taken me longer than expected to get back to
> it.  I really don't have any simple examples of porting as my stuff is
> fairly involved (i.e. drawing and keyboard handling as part of a larger
> OpenGL project etc.)  However, I do have more specifics re: what needed
> to be done.
> 
<snip>
> 
> Keyboard focus handling
> 

One additional thing related to keyboard focus that should probably be
handled by Morphic: various mouse (mouse wheel) and trackpad (gesture)
events get sent as keyboard events and should probably be (at least
optionally?) intercepted from the event stream and sent as distinct
events such as #scroll: etc.  No idea how multi-finger touch screen
gestures are handled by the VM these days but that is yet something else
to think about...

> 
> Thanks,
> Phil





From juan at jvuletich.org  Mon Jul  6 08:33:23 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 06 Jul 2015 10:33:23 -0300
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <5599BF3A.26485.1F11628@dnorton.mindspring.com>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>
Message-ID: <559A83A3.5040406@jvuletich.org>

Hi Dan,

On 7/5/2015 8:35 PM, Dan Norton wrote:
> Greetings,
>
> Four LayoutSpec class methods use "minorDirectionPadding:" as a keyword. The parameter
> can be a number or one of: #top, #left, #center, #right, or #bottom. AFAICT when the
> parameter is a number, it refers to the padding which will be applied in the minor direction.
> When it is a symbol, it effectively specifies that morphs will be located as the symbol name
> implies.
>
> Attached are four convenience methods whose keyword emphasizes the visible (morph)
> instead of the invisible (padding). The "morphPlacement:" parameter can be  #top, #left,
> #center, #right, or #bottom. The methods are:
>
> LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
> LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
> LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
> LayoutSpec class>>proportionalWidth:proportionalHeight:morphPlacement:
>
> Are these worth having in the base system?
>
>   - Dan
>

I'd rather replace the keyword 'minorDirectionPadding:' by 
'minorDirectionPlacement:' to:
- Avoid ambiguity
- Avoid duplication

What do you all think?

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Mon Jul  6 10:00:36 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 6 Jul 2015 15:00:36 +0000
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1436170359.2678.52.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
	<1436169716.2678.46.camel@gmail.com>
	<1436170359.2678.52.camel@gmail.com>
Message-ID: <CAGQxfVgb34x3P9shmHgs9=MMu0uQbAFQdBNSm9VfUCaZvVCQgA@mail.gmail.com>

Phil,

thank you for answering three months later. That is fine, I'd like to
distill from our conversation some upgrade notes from Cuis Morphic 4.0
to Cuis Morphic 4.2.

I created an issue for this for the documentation of Cuis

   https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/65

Quite a number of issues are piled up there and I want to work on them
in batch mode in one go sometime in the upcoming months.

So if this thread goes to sleep for three more months I do not have
any problem with it ...

:-)


The documentation of course is related to the issue of having release
version numbers you can refer to.


Ideally we have release notes from time to time which list the changes
and test reports which packages work with which release.

--Hannes

On 7/6/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote:
>> Hannes,
>>
>> Sorry for the delay... it's taken me longer than expected to get back to
>> it.  I really don't have any simple examples of porting as my stuff is
>> fairly involved (i.e. drawing and keyboard handling as part of a larger
>> OpenGL project etc.)  However, I do have more specifics re: what needed
>> to be done.
>>
> <snip>
>>
>> Keyboard focus handling
>>
>
> One additional thing related to keyboard focus that should probably be
> handled by Morphic: various mouse (mouse wheel) and trackpad (gesture)
> events get sent as keyboard events and should probably be (at least
> optionally?) intercepted from the event stream and sent as distinct
> events such as #scroll: etc.  No idea how multi-finger touch screen
> gestures are handled by the VM these days but that is yet something else
> to think about...
>
>>
>> Thanks,
>> Phil
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Mon Jul  6 10:04:05 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 6 Jul 2015 15:04:05 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <55993940.8090704@jvuletich.org>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
	<55993940.8090704@jvuletich.org>
Message-ID: <CAGQxfVhAxbOCLaztuYifqRR-9rFgHThVF6C5pz5nw1OBXdOiTQ@mail.gmail.com>

On 7/5/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Hannes,
>
> Sure, let's discuss this. What do other people maintaining external
> packages think? This is for you...


Thank you. I think the issue is that the 50 or so commits in the first
six months of this year needed to be grouped into larger chunks,
called minor released.

I understand that in github a release is just a tab on a particular
commit, i.e. they may be still be added.

And the most straightforward thing is to continue numbering with where
you left off before moving to github.

It should be easy for people to check out a particular release of the past.

This in particular as many months might pass between work on Cuis for
a particular project.


>
> Cheers,
> Juan Vuletich
>
> On 04/07/2015 08:45 p.m., H. Hirzel wrote:
>> Juan,
>>
>> And this brings up the question that it would be good to have a
>> 'release tag' from time to time.
>>
>> So that releases show up here
>>
>>      https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases
>>
>> Currently there are 0 releases. This is very straightforward to do in
>> github.
>>
>> This will facilitate checking if external packages still run fine.
>> There are about 50 commits in
>> Cuis-Smalltalk-Dev in first two quaters of 2015.
>>
>> I think I some minor releases (i.e. 2 ... 6 a year) would be fine.
>>
>> Thanks for considering this
>>
>> --Hannes
>>
>> On 7/4/15, Ken.Dickey<Ken.Dickey at whidbey.com>  wrote:
>>> Juan,
>>>
>>> The Installed Packages browser used to be able to require a minimum
>>> revision
>>> on the base release.
>>>
>>> I use this feature as a backstop when features change in the base
>>> release.
>>>
>>> Any chance in getting this ability back?
>>>
>>> Thanks much,
>>> -KenD
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>
>



From dnorton at mindspring.com  Mon Jul  6 10:37:06 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 06 Jul 2015 11:37:06 -0400
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <559A83A3.5040406@jvuletich.org>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>,
	<559A83A3.5040406@jvuletich.org>
Message-ID: <559AA0A2.13962.3B4CD8@dnorton.mindspring.com>

On 6 Jul 2015 at 10:33, Juan Vuletich wrote:

> Hi Dan,
> 
> On 7/5/2015 8:35 PM, Dan Norton wrote:
> > Greetings,
> >
> > Four LayoutSpec class methods use "minorDirectionPadding:" as a
> keyword. The parameter
> > can be a number or one of: #top, #left, #center, #right, or
> #bottom. AFAICT when the
> > parameter is a number, it refers to the padding which will be
> applied in the minor direction.
> > When it is a symbol, it effectively specifies that morphs will be
> located as the symbol name
> > implies.
> >
> > Attached are four convenience methods whose keyword emphasizes the
> visible (morph)
> > instead of the invisible (padding). The "morphPlacement:"
> parameter can be  #top, #left,
> > #center, #right, or #bottom. The methods are:
> >
> > LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
> > LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
> > LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
> > LayoutSpec
> class>>proportionalWidth:proportionalHeight:morphPlacement:
> >
> > Are these worth having in the base system?
> >
> >   - Dan
> >
> 
> I'd rather replace the keyword 'minorDirectionPadding:' by 
> 'minorDirectionPlacement:' to:
> - Avoid ambiguity
> - Avoid duplication
> 
OK, as far as the duplication, but I don't see "morphPlacement:" in use. Where does the 
ambiguity occur?

 - Dan



From dnorton at mindspring.com  Mon Jul  6 10:49:46 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 06 Jul 2015 11:49:46 -0400
Subject: [Cuis] Cuis Archive
Message-ID: <559AA39A.19585.46E7C0@dnorton.mindspring.com>

Hi,

There is nothing in the archive for July. Anybody else experiencing this?

 - Dan



From dnorton at mindspring.com  Mon Jul  6 21:05:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 06 Jul 2015 22:05:22 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <1435889021.2309.200.camel@gmail.com>
References: <1435576183.2309.69.camel@gmail.com>,
	<5595E22F.2684.23EA964@dnorton.mindspring.com>,
	<1435889021.2309.200.camel@gmail.com>
Message-ID: <559B33E2.1296.27A7F1A@dnorton.mindspring.com>

On 2 Jul 2015 at 22:03, Phil (list) wrote:

> You're probably trying one of the download links.  You can stream
> the
> video as long as JavaScript is enabled.  If you can't temporarily
> do
> this in IE, I'd highly recommend keeping Firefox+NoScript around as
> it
> lets you temporarily enable JavaScript & cookies for this type of
> scenario.
> [...]

Thanks, Phil. That's better.

 - Dan




From pbpublist at gmail.com  Mon Jul  6 22:03:26 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 06 Jul 2015 23:03:26 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <CAGQxfVgb34x3P9shmHgs9=MMu0uQbAFQdBNSm9VfUCaZvVCQgA@mail.gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
	<1436169716.2678.46.camel@gmail.com>
	<1436170359.2678.52.camel@gmail.com>
	<CAGQxfVgb34x3P9shmHgs9=MMu0uQbAFQdBNSm9VfUCaZvVCQgA@mail.gmail.com>
Message-ID: <1436238206.2678.107.camel@gmail.com>

On Mon, 2015-07-06 at 15:00 +0000, H. Hirzel wrote:
> Phil,
> 
> thank you for answering three months later. That is fine, I'd like to
> distill from our conversation some upgrade notes from Cuis Morphic 4.0
> to Cuis Morphic 4.2.
> 

Apologies for taking so long... I figured better late than never.

> I created an issue for this for the documentation of Cuis
> 
>    https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/65
> 
> Quite a number of issues are piled up there and I want to work on them
> in batch mode in one go sometime in the upcoming months.
> 
> So if this thread goes to sleep for three more months I do not have
> any problem with it ...
> 
> :-)
> 

I'll try to stop being such a troublemaker... (promises, promises :-)

> 
> The documentation of course is related to the issue of having release
> version numbers you can refer to.
> 

Ah, now I understand why you're asking for version #'s/tags/something.

> 
> Ideally we have release notes from time to time which list the changes
> and test reports which packages work with which release.
> 

The reporting part sounds like Continuous Integration testing to me...

> --Hannes
> 
> On 7/6/15, Phil (list) <pbpublist at gmail.com> wrote:
> > On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote:
> >> Hannes,
> >>
> >> Sorry for the delay... it's taken me longer than expected to get back to
> >> it.  I really don't have any simple examples of porting as my stuff is
> >> fairly involved (i.e. drawing and keyboard handling as part of a larger
> >> OpenGL project etc.)  However, I do have more specifics re: what needed
> >> to be done.
> >>
> > <snip>
> >>
> >> Keyboard focus handling
> >>
> >
> > One additional thing related to keyboard focus that should probably be
> > handled by Morphic: various mouse (mouse wheel) and trackpad (gesture)
> > events get sent as keyboard events and should probably be (at least
> > optionally?) intercepted from the event stream and sent as distinct
> > events such as #scroll: etc.  No idea how multi-finger touch screen
> > gestures are handled by the VM these days but that is yet something else
> > to think about...
> >
> >>
> >> Thanks,
> >> Phil
> >
> >
> >
> > _______________________________________________
> > 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 pbpublist at gmail.com  Tue Jul  7 01:59:59 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 07 Jul 2015 02:59:59 -0400
Subject: [Cuis] MNU bug with halo in world
Message-ID: <1436252399.2678.117.camel@gmail.com>

Juan,

In an empty area in the world, middle click to bring up a halo for the
world PasteUpMorph.  Middle click again... MNU.

Thanks,
Phil




From hannes.hirzel at gmail.com  Tue Jul  7 06:22:43 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 7 Jul 2015 11:22:43 +0000
Subject: [Cuis] Status of continuous integration testing // release numbers
	to refer to?
Message-ID: <CAGQxfVie+JNw0R3rEXN4-WuUUWc8AS-Pa3k3u42A+A=fFvmibA@mail.gmail.com>

On 7/7/15, Phil (list) <pbpublist at gmail.com> wrote:
....
>
> The documentation of course is related to the issue of having release
> version numbers you can refer to.
>

Ah, now I understand why you're asking for version #'s/tags/something.
..

>> Ideally we have release notes from time to time which list the changes
>> and test reports which packages work with which release.
>>
>
> The reporting part sounds like Continuous Integration testing to me...
>

Hello Juan

You recently had a note to the ML that you are doing integration
testing before each of your releases which are announced on the
mailing list with an 'update' mail.

I understand that you are loading all packages in

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Packages

and run the tests there in addition to the tests built into Cuis core.

Is this so?

Do you produce a log file of the results which might be archived as
well in the repository?

Kind regards

Hannes



From hannes.hirzel at gmail.com  Tue Jul  7 07:06:48 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 7 Jul 2015 12:06:48 +0000
Subject: [Cuis] MNU bug with halo in world
In-Reply-To: <1436252399.2678.117.camel@gmail.com>
References: <1436252399.2678.117.camel@gmail.com>
Message-ID: <CAGQxfViw8_6ow6LGpAG8SkFfkYgh5_P2aZqzDeCNAKqfsLFk8A@mail.gmail.com>

Added to issues

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/66

--HH

On 7/7/15, Phil (list) <pbpublist at gmail.com> wrote:
> Juan,
>
> In an empty area in the world, middle click to bring up a halo for the
> world PasteUpMorph.  Middle click again... MNU.
>
> Thanks,
> Phil
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From Ken.Dickey at whidbey.com  Tue Jul  7 08:04:18 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 7 Jul 2015 06:04:18 -0700
Subject: [Cuis] MorphIt -- toward direct authoring with media
Message-ID: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>

Greetings all,

I have put some pre-Alpha proof-of-concept code in BabySteps

	https://github.com/KenDickey/Cuis-Smalltalk-BabySteps

The package is called MorphIt, the gist being drag-n-drop prototype style modification of Morphs with a general goal of multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..

As some of you may know, my style is to have a bunch of half baked ideas roiling around in my head which I tend to think through by writing code.  

Very early days yet, but anyone with time on their hands can see what works and what doesn't.  The README.md has some notes on directions.

Cheers, 
-KenD

================
When Michael Faraday first demonstrated electromagnetic induction, the Prime Minister asked, ?Of what use is this discovery, Mr. Faraday?? Faraday replied, ?Of what use is a baby, Mr. Prime Minister??



From dnorton at mindspring.com  Tue Jul  7 12:05:17 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 07 Jul 2015 13:05:17 -0400
Subject: [Cuis] Loop during StrikeFont install:
Message-ID: <559C06CD.15379.DC94F3@dnorton.mindspring.com>

To cause this loop:

In directory "Cuis-Smalltalk-Dev-master" have no "AAFonts" directory.
Do (cmd-d) StrikeFont install: 'Optima'
Get a loop instead of "File does not exist" exception.

 - Dan



From pbpublist at gmail.com  Tue Jul  7 16:57:40 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 07 Jul 2015 17:57:40 -0400
Subject: [Cuis] OpenGL questions
Message-ID: <1436306260.2678.148.camel@gmail.com>

Just wanted to see if anyone other than me is currently using my OpenGL
port at https://github.com/pbella/Cuis-Ports?  I ask because what is
currently there is from some old Squeak/Croquet code that only supported
OpenGL 1.x (1.3, I believe) and I'm getting ready to update it but will
need to break some things no matter how I decide to do it (i.e. related
to the next question)

Does anyone care about the 'full' OpenGL API anymore?  My general sense
is that unless one is a developer of CAD software or high-end video game
engines, the full/desktop API doesn't add much value esp. given how
limiting it is in terms of portability.  As recent releases of OpenGL
are supersets of OpenGL ES, I'm thinking of just supporting ES and that
way both desktop and mobile devices can be targeted with the same code
and have a much smaller API to deal with.  However, if anyone has a
burning need for a non-ES flavor, now would be the time to speak up.

Thanks,
Phil




From Ken.Dickey at whidbey.com  Tue Jul  7 02:52:26 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 7 Jul 2015 15:52:26 +0800
Subject: [Cuis] OpenGL questions
In-Reply-To: <1436306260.2678.148.camel@gmail.com>
References: <1436306260.2678.148.camel@gmail.com>
Message-ID: <20150707155226.9877626cbfa5f046b51073c8@whidbey.com>

On Tue, 07 Jul 2015 17:57:40 -0400
"Phil (list)" <pbpublist at gmail.com> wrote:

> Just wanted to see if anyone other than me is currently using my OpenGL
> port at https://github.com/pbella/Cuis-Ports? 

Not me (so far).

ES would be great!

-KenD



From juan at jvuletich.org  Wed Jul  8 09:33:04 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 08 Jul 2015 11:33:04 -0300
Subject: [Cuis] Status of continuous integration testing // release
 numbers to refer to?
In-Reply-To: <CAGQxfVie+JNw0R3rEXN4-WuUUWc8AS-Pa3k3u42A+A=fFvmibA@mail.gmail.com>
References: <CAGQxfVie+JNw0R3rEXN4-WuUUWc8AS-Pa3k3u42A+A=fFvmibA@mail.gmail.com>
Message-ID: <559D34A0.5080102@jvuletich.org>

Hi Hannes,

On 7/7/2015 8:22 AM, H. Hirzel wrote:
> Hello Juan
>
> You recently had a note to the ML that you are doing integration
> testing before each of your releases which are announced on the
> mailing list with an 'update' mail.

Yes, I do that before pushing to github, almost every time.

> I understand that you are loading all packages in
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Packages
>
> and run the tests there in addition to the tests built into Cuis core.
>
> Is this so?

Yes.

> Do you produce a log file of the results which might be archived as
> well in the repository?

Well, recently I did SUnit XML reports.pck.st, so it is not a big deal 
to do it. I'll try to remember. Please nag me if I forget about it.

> Kind regards
>
> Hannes

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  8 09:34:20 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 08 Jul 2015 11:34:20 -0300
Subject: [Cuis] MNU bug with halo in world
In-Reply-To: <1436252399.2678.117.camel@gmail.com>
References: <1436252399.2678.117.camel@gmail.com>
Message-ID: <559D34EC.4000608@jvuletich.org>

On 7/7/2015 3:59 AM, Phil (list) wrote:
> Juan,
>
> In an empty area in the world, middle click to bring up a halo for the
> world PasteUpMorph.  Middle click again... MNU.
>
> Thanks,
> Phil
>

Thanks for reporting! I have the fix, and it will be in the next commit 
I do.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  8 09:37:15 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 08 Jul 2015 11:37:15 -0300
Subject: [Cuis] OpenGL questions
In-Reply-To: <1436306260.2678.148.camel@gmail.com>
References: <1436306260.2678.148.camel@gmail.com>
Message-ID: <559D359B.9090607@jvuletich.org>

Hi Phil,

I'm not using it, but it is a very nice to have it. I'd say, stick to 
the subset that makes most sense for you. Very few people could need the 
full OpenGL api. ES sounds very reasonable to me.

Cheers,
Juan Vuletich

On 7/7/2015 6:57 PM, Phil (list) wrote:
> Just wanted to see if anyone other than me is currently using my OpenGL
> port at https://github.com/pbella/Cuis-Ports?  I ask because what is
> currently there is from some old Squeak/Croquet code that only supported
> OpenGL 1.x (1.3, I believe) and I'm getting ready to update it but will
> need to break some things no matter how I decide to do it (i.e. related
> to the next question)
>
> Does anyone care about the 'full' OpenGL API anymore?  My general sense
> is that unless one is a developer of CAD software or high-end video game
> engines, the full/desktop API doesn't add much value esp. given how
> limiting it is in terms of portability.  As recent releases of OpenGL
> are supersets of OpenGL ES, I'm thinking of just supporting ES and that
> way both desktop and mobile devices can be targeted with the same code
> and have a much smaller API to deal with.  However, if anyone has a
> burning need for a non-ES flavor, now would be the time to speak up.
>
> Thanks,
> Phil
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From dnorton at mindspring.com  Wed Jul  8 18:44:53 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 08 Jul 2015 19:44:53 -0400
Subject: [Cuis] #browseVersions Key not Found
Message-ID: <559DB5F5.25858.20175F4@dnorton.mindspring.com>

>From a browser, the versions button works as it should.

However, from a ProtocolBrowser, if the message is from a superclass a "key not found" 
error occurs. 

Versions of messages belonging to the class being "protocol browsed" are listed as they 
should be.

 - Dan



From dnorton at mindspring.com  Wed Jul  8 19:03:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 08 Jul 2015 20:03:07 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <559DBA3B.28326.21224C9@dnorton.mindspring.com>

For my PluggableListMorph, the model prepares list elements on a "String new writeStream." 
They are not static. I need for these list elements to be aligned in columns like a small 
spreadsheet. A fixed font would be handy - how can I install one?

Any other approaches to get columns in a list?

 - Dan



From pbpublist at gmail.com  Thu Jul  9 04:15:37 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 09 Jul 2015 05:15:37 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
Message-ID: <1436433337.2325.6.camel@gmail.com>

This is a minor nit but when I'm developing Morphs I often need to
instantiate them manually via something like 'MorphName new
openInWorld.'  When I do that, I almost always find its initial position
annoying and in some cases nearly non-functional since the Morph doesn't
have room for its halo icons.  Just wondering if this bothers anyone
else and if maybe insetting new morphs top left by default to something
like 50 @ 50 (something out of the way, but giving it a bit of margin
from the edge of the screen) might be better?




From hannes.hirzel at gmail.com  Thu Jul  9 05:43:42 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 9 Jul 2015 10:43:42 +0000
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
Message-ID: <CAGQxfVhNEnergmoFZJtyENR7nGLKSgWsPGR5z+o83pzV9TfS7A@mail.gmail.com>

+1

On 7/9/15, Phil (list) <pbpublist at gmail.com> wrote:
> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial position
> annoying and in some cases nearly non-functional since the Morph doesn't
> have room for its halo icons.  Just wondering if this bothers anyone
> else and if maybe insetting new morphs top left by default to something
> like 50 @ 50 (something out of the way, but giving it a bit of margin
> from the edge of the screen) might be better?
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Thu Jul  9 09:49:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 09 Jul 2015 10:49:07 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
Message-ID: <559E89E3.19425.2863A2@dnorton.mindspring.com>

On 9 Jul 2015 at 5:15, Phil (list) wrote:

> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial
> position
> annoying and in some cases nearly non-functional since the Morph
> doesn't
> have room for its halo icons.  Just wondering if this bothers
> anyone
> else and if maybe insetting new morphs top left by default to
> something
> like 50 @ 50 (something out of the way, but giving it a bit of
> margin
> from the edge of the screen) might be better?
> 

+1

Also, it's pretty dark up there and the black on blue MinimalStringMorph is hard to see, for 
example.

 - Dan



From sean at clipperadams.com  Thu Jul  9 09:43:55 2015
From: sean at clipperadams.com (Sean P. DeNigris)
Date: Thu, 9 Jul 2015 07:43:55 -0700 (PDT)
Subject: [Cuis] MorphIt -- toward direct authoring with media
In-Reply-To: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
References: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
Message-ID: <1436453035366-4836792.post@n4.nabble.com>

Ken.Dickey wrote
> drag-n-drop prototype style modification of Morphs with a general goal of
> multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..

Sounds fantastic!



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/MorphIt-toward-direct-authoring-with-media-tp4836232p4836792.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From casey.obrien.r at gmail.com  Thu Jul  9 21:05:20 2015
From: casey.obrien.r at gmail.com (Casey Ransberger)
Date: Thu, 9 Jul 2015 19:05:20 -0700
Subject: [Cuis] MorphIt -- toward direct authoring with media
In-Reply-To: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
References: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
Message-ID: <A420D093-D868-490D-AC79-3DDED1561178@gmail.com>

Hey Ken,

Woot! I was working on something that did this but got distracted by a shiny robot before it got close to working. 

I've wanted to see Self-style authoring in Cuis ever since I realized that I liked working with Cuis better than the other distributions. It was the one thing I really enjoyed in Squeak that we're really missing in Cuisland. 

If we can throw in some HyperCard and... what is that thing from Self? Little tool to zero in on a Morph and then inspect it? Anyway, that thing. Would be just amazingly awesome. 

--C

> On Jul 7, 2015, at 6:04 AM, "Ken.Dickey" <Ken.Dickey at whidbey.com> wrote:
> 
> Greetings all,
> 
> I have put some pre-Alpha proof-of-concept code in BabySteps
> 
>    https://github.com/KenDickey/Cuis-Smalltalk-BabySteps
> 
> The package is called MorphIt, the gist being drag-n-drop prototype style modification of Morphs with a general goal of multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..
> 
> As some of you may know, my style is to have a bunch of half baked ideas roiling around in my head which I tend to think through by writing code.  
> 
> Very early days yet, but anyone with time on their hands can see what works and what doesn't.  The README.md has some notes on directions.
> 
> Cheers, 
> -KenD
> 
> ================
> When Michael Faraday first demonstrated electromagnetic induction, the Prime Minister asked, ?Of what use is this discovery, Mr. Faraday?? Faraday replied, ?Of what use is a baby, Mr. Prime Minister??
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



From casey.obrien.r at gmail.com  Thu Jul  9 21:11:24 2015
From: casey.obrien.r at gmail.com (Casey Ransberger)
Date: Thu, 9 Jul 2015 19:11:24 -0700
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
Message-ID: <D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>

I want this too. What needs to be done is to make a StrikeFont, IIRC. I didn't get a round toit. If anyone has an extra round toit that I can borrow, I'd be very appreciative. 

Anyway I think if you look around at the class StrikeFont, you'll find a trailhead or rabbit hole that you can follow toward how to #doIt.

Someone correct me if I'm wrong.

--C

> On Jul 8, 2015, at 5:03 PM, "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> For my PluggableListMorph, the model prepares list elements on a "String new writeStream." 
> They are not static. I need for these list elements to be aligned in columns like a small 
> spreadsheet. A fixed font would be handy - how can I install one?
> 
> Any other approaches to get columns in a list?
> 
> - Dan
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



From dnorton at mindspring.com  Fri Jul 10 09:20:45 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 10 Jul 2015 10:20:45 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
Message-ID: <559FD4BD.26551.31649C@dnorton.mindspring.com>

On 9 Jul 2015 at 19:11, Casey Ransberger wrote:

> I want this too. What needs to be done is to make a StrikeFont,
> IIRC. I didn't get a round toit. If anyone has an extra round toit
> that I can borrow, I'd be very appreciative. 
> 
Thought I had one... must be around here somewhere... :(

> Anyway I think if you look around at the class StrikeFont, you'll
> find a trailhead or rabbit hole that you can follow toward how to
> #doIt.
> 
Browsing through strike fonts, I see no fixed widths. But, true type fonts have a few 
fixed-width examples. There seems to be no way to install a .ttf in Cuis currently.

Can we port TrueType-Support from Squeak?

Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits from AbstractFont?

Any hints or guidance would be most welcomed.

> Someone correct me if I'm wrong.
> 
> --C
> 
> > On Jul 8, 2015, at 5:03 PM, "Dan Norton" <dnorton at mindspring.com>
> wrote:
> > 
> > For my PluggableListMorph, the model prepares list elements on a
> "String new writeStream." 
> > They are not static. I need for these list elements to be aligned
> in columns like a small 
> > spreadsheet. A fixed font would be handy - how can I install
> one?
> > 
> > Any other approaches to get columns in a list?
> > 
> > - Dan
> > 
> > _______________________________________________
> > 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

 - Dan




From pbpublist at gmail.com  Fri Jul 10 12:29:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 10 Jul 2015 13:29:01 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559FD4BD.26551.31649C@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	, <D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
Message-ID: <1436549341.2325.3.camel@gmail.com>

On Fri, 2015-07-10 at 10:20 -0400, Dan Norton wrote:
> On 9 Jul 2015 at 19:11, Casey Ransberger wrote:
> 
> > I want this too. What needs to be done is to make a StrikeFont,
> > IIRC. I didn't get a round toit. If anyone has an extra round toit
> > that I can borrow, I'd be very appreciative. 
> > 
> Thought I had one... must be around here somewhere... :(
> 
> > Anyway I think if you look around at the class StrikeFont, you'll
> > find a trailhead or rabbit hole that you can follow toward how to
> > #doIt.
> > 
> Browsing through strike fonts, I see no fixed widths. But, true type fonts have a few 
> fixed-width examples. There seems to be no way to install a .ttf in Cuis currently.
> 
> Can we port TrueType-Support from Squeak?
> 
> Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits from AbstractFont?
> 
> Any hints or guidance would be most welcomed.

I'd like a fixed-width font as well but I suspect that this is one of
the areas it might be better to wait until Morphic 3 on (i.e. isn't the
existing font support based on bitmap fonts rather than vector?)

> 
> > Someone correct me if I'm wrong.
> > 
> > --C
> > 
> > > On Jul 8, 2015, at 5:03 PM, "Dan Norton" <dnorton at mindspring.com>
> > wrote:
> > > 
> > > For my PluggableListMorph, the model prepares list elements on a
> > "String new writeStream." 
> > > They are not static. I need for these list elements to be aligned
> > in columns like a small 
> > > spreadsheet. A fixed font would be handy - how can I install
> > one?
> > > 
> > > Any other approaches to get columns in a list?
> > > 
> > > - Dan
> > > 
> > > _______________________________________________
> > > 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
> 
>  - Dan
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Fri Jul 10 14:05:50 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 10 Jul 2015 15:05:50 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <1436549341.2325.3.camel@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<559FD4BD.26551.31649C@dnorton.mindspring.com>,
	<1436549341.2325.3.camel@gmail.com>
Message-ID: <55A0178E.16257.13666A4@dnorton.mindspring.com>

On 10 Jul 2015 at 13:29, Phil (list) wrote:

> On Fri, 2015-07-10 at 10:20 -0400, Dan Norton wrote:
> > On 9 Jul 2015 at 19:11, Casey Ransberger wrote:
> > 
> > > I want this too. What needs to be done is to make a
> StrikeFont,
> > > IIRC. I didn't get a round toit. If anyone has an extra round
> toit
> > > that I can borrow, I'd be very appreciative. 
> > > 
> > Thought I had one... must be around here somewhere... :(
> > 
> > > Anyway I think if you look around at the class StrikeFont,
> you'll
> > > find a trailhead or rabbit hole that you can follow toward how
> to
> > > #doIt.
> > > 
> > Browsing through strike fonts, I see no fixed widths. But, true
> type fonts have a few 
> > fixed-width examples. There seems to be no way to install a .ttf
> in Cuis currently.
> > 
> > Can we port TrueType-Support from Squeak?
> > 
> > Should there be a sibling of StrikeFont, say TrueTypeFont, which
> inherits from AbstractFont?
> > 
> > Any hints or guidance would be most welcomed.
> 
> I'd like a fixed-width font as well but I suspect that this is one
> of
> the areas it might be better to wait until Morphic 3 on (i.e. isn't
> the
> existing font support based on bitmap fonts rather than vector?)
>

Yes, the only font now is DejaVu and it's a bitmap font. I found some fixed bitmap fonts 
among the true types at:

http://www.lowing.org/fonts/

Adding a sublcass to AbstractFont to load one of these might be doable near-term until 
Morphic 3 comes along. Porting TrueType from Squeak has a lot of drag.

> > 
> > > Someone correct me if I'm wrong.
> > > 
> > > --C
> > > 
> > > > On Jul 8, 2015, at 5:03 PM, "Dan Norton"
> <dnorton at mindspring.com>
> > > wrote:
> > > > 
> > > > For my PluggableListMorph, the model prepares list elements on
> a
> > > "String new writeStream." 
> > > > They are not static. I need for these list elements to be
> aligned
> > > in columns like a small 
> > > > spreadsheet. A fixed font would be handy - how can I install
> > > one?
> > > > 
> > > > Any other approaches to get columns in a list?
> > > > 
> > > > - Dan
> > > > 
> > > > _______________________________________________
> > > > 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
> > 
> >  - Dan
> > 
> > 
> > _______________________________________________
> > 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 Ken.Dickey at whidbey.com  Fri Jul 10 03:51:44 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 10 Jul 2015 16:51:44 +0800
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A0178E.16257.13666A4@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
Message-ID: <20150710165144.ece0f54787132fed1278bdc4@whidbey.com>

On Fri, 10 Jul 2015 15:05:50 -0400
"Dan Norton" <dnorton at mindspring.com> wrote:

> Yes, the only font now is DejaVu and it's a bitmap font. I found some fixed bitmap fonts 
> among the true types at:
> 
> http://www.lowing.org/fonts/
> 
> Adding a sublcass to AbstractFont to load one of these might be doable near-term until 
> Morphic 3 comes along. Porting TrueType from Squeak has a lot of drag.

My Cuis-Smalltalk-Unicode package subclasses AbstractFont and provides fixed width characters.

See class #UniForms 

Unicode is kinda big, memory wise.  I suspect one should be able to take the ASCII subset of the Unicode glyphs and make a strike font -- or just do what I did for Unicode, but just use the ASCII subset.

FYI,
-KenD



From juan at jvuletich.org  Sat Jul 11 11:11:04 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:11:04 -0300
Subject: [Cuis] #browseVersions Key not Found
In-Reply-To: <559DB5F5.25858.20175F4@dnorton.mindspring.com>
References: <559DB5F5.25858.20175F4@dnorton.mindspring.com>
Message-ID: <55A14018.1050602@jvuletich.org>

On 7/8/2015 8:44 PM, Dan Norton wrote:
> > From a browser, the versions button works as it should.
>
> However, from a ProtocolBrowser, if the message is from a superclass a "key not found"
> error occurs.
>
> Versions of messages belonging to the class being "protocol browsed" are listed as they
> should be.
>
>   - Dan

Oh! Thanks for the report.

This turned out to be a little pandora box. Lots of broken code, unused 
/ incosistent ivars, and the like in ProtocolBrowser and 
TimeProfileBrowser. Setting all this straight is taking a little bit 
longer than expected. But I hope to do a commit with these tools working 
substantially better this weekend. I'm also removing quite a bit of code...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 11:40:28 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:40:28 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
Message-ID: <55A146FC.4020402@jvuletich.org>

Hi Folks,

It is not too hard to build new StrikeFonts. You need to build, by hand, 
files like the ones in here: 
https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zip 
and learn a bit about stuff like #installDejaVu2 . Maybe it was with 
this method and the files in this zip that built the existing instances 
of StrikeFont. Not sure.

I think DejaVu Sans Mono would be a great addition, and would look well 
to the existing DejaVu Sans.

In any case, don't be afraid, and play with the stuff. It is there so 
you can do it.

BTW, yesterday I learnt about https://github.com/tonsky/FiraCode . I 
think it is wonderful. We can't just adopt it, as we don't have 
ligatures. But maybe some time, Morphic 3 could be made to use it.

Cheers,
Juan vuletich

On 7/8/2015 9:03 PM, Dan Norton wrote:
> For my PluggableListMorph, the model prepares list elements on a "String new writeStream."
> They are not static. I need for these list elements to be aligned in columns like a small
> spreadsheet. A fixed font would be handy - how can I install one?
>
> Any other approaches to get columns in a list?
>
>   - Dan




From juan at jvuletich.org  Sat Jul 11 11:42:05 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:42:05 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559FD4BD.26551.31649C@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
Message-ID: <55A1475D.3030501@jvuletich.org>

On 7/10/2015 11:20 AM, Dan Norton wrote:
> ...
> Browsing through strike fonts, I see no fixed widths. But, true type fonts have a few
> fixed-width examples. There seems to be no way to install a .ttf in Cuis currently.
>
> Can we port TrueType-Support from Squeak?
>
> Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits from AbstractFont?
>
> Any hints or guidance would be most welcomed.
>

I'd say, stick to StrikeFonts, and learn to build new ones. I the other 
message I just sent, I included more details.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 11:46:17 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:46:17 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A0178E.16257.13666A4@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<559FD4BD.26551.31649C@dnorton.mindspring.com>,
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
Message-ID: <55A14859.2080409@jvuletich.org>

On 7/10/2015 4:05 PM, Dan Norton wrote:
> ...
> Yes, the only font now is DejaVu and it's a bitmap font. I found some fixed bitmap fonts
> among the true types at:
>
> http://www.lowing.org/fonts/
>
> Adding a sublcass to AbstractFont to load one of these might be doable near-term until
> Morphic 3 comes along. Porting TrueType from Squeak has a lot of drag.
>

ProFontWindows doesn't look bad. In any case, I built the Bitmap DejaVu 
fonts in Cuis (and Squeak and Pharo) by capturing the bits from the 
screen of a text editor, running the TTF. You can do the same with 
DejaVu Sans Mono or any other TTF / OTF / whatever.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 12:27:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 14:27:01 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
Message-ID: <55A151E5.5060409@jvuletich.org>

On 7/9/2015 6:15 AM, Phil (list) wrote:
> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial position
> annoying and in some cases nearly non-functional since the Morph doesn't
> have room for its halo icons.  Just wondering if this bothers anyone
> else and if maybe insetting new morphs top left by default to something
> like 50 @ 50 (something out of the way, but giving it a bit of margin
> from the edge of the screen) might be better?

Sure. Will be there in the next commit.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 12:29:39 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 14:29:39 -0300
Subject: [Cuis] MorphIt -- toward direct authoring with media
In-Reply-To: <A420D093-D868-490D-AC79-3DDED1561178@gmail.com>
References: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
	<A420D093-D868-490D-AC79-3DDED1561178@gmail.com>
Message-ID: <55A15283.8050104@jvuletich.org>

Hi Folks,

I agree with you. I think it will be great to make Cuis good at that! 
(While keeping the cleanness of the code and the design, of course).

Cheers,
Juan Vuletich

On 7/9/2015 11:05 PM, Casey Ransberger wrote:
> Hey Ken,
>
> Woot! I was working on something that did this but got distracted by a shiny robot before it got close to working.
>
> I've wanted to see Self-style authoring in Cuis ever since I realized that I liked working with Cuis better than the other distributions. It was the one thing I really enjoyed in Squeak that we're really missing in Cuisland.
>
> If we can throw in some HyperCard and... what is that thing from Self? Little tool to zero in on a Morph and then inspect it? Anyway, that thing. Would be just amazingly awesome.
>
> --C
>
>> On Jul 7, 2015, at 6:04 AM, "Ken.Dickey"<Ken.Dickey at whidbey.com>  wrote:
>>
>> Greetings all,
>>
>> I have put some pre-Alpha proof-of-concept code in BabySteps
>>
>>     https://github.com/KenDickey/Cuis-Smalltalk-BabySteps
>>
>> The package is called MorphIt, the gist being drag-n-drop prototype style modification of Morphs with a general goal of multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..
>>
>> As some of you may know, my style is to have a bunch of half baked ideas roiling around in my head which I tend to think through by writing code.
>>
>> Very early days yet, but anyone with time on their hands can see what works and what doesn't.  The README.md has some notes on directions.
>>
>> Cheers,
>> -KenD




From juan at jvuletich.org  Sat Jul 11 12:31:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 14:31:27 -0300
Subject: [Cuis] Loop during StrikeFont install:
In-Reply-To: <559C06CD.15379.DC94F3@dnorton.mindspring.com>
References: <559C06CD.15379.DC94F3@dnorton.mindspring.com>
Message-ID: <55A152EF.1030801@jvuletich.org>

Hi Dan,

It looks like you'll be playing a bit with building a good monospaced 
font, right? While you are at it, please send to the mail list any fixes 
you'll for sure be doing in this area...

Thanks,
Juan Vuletich

On 7/7/2015 2:05 PM, Dan Norton wrote:
> To cause this loop:
>
> In directory "Cuis-Smalltalk-Dev-master" have no "AAFonts" directory.
> Do (cmd-d) StrikeFont install: 'Optima'
> Get a loop instead of "File does not exist" exception.
>
>   - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From edgardec2005 at gmail.com  Sat Jul 11 15:24:20 2015
From: edgardec2005 at gmail.com (Edgar J De Cleene)
Date: Sat, 11 Jul 2015 17:24:20 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <55A146FC.4020402@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
Message-ID: <6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>

Quoting Casey

> If we can throw in some HyperCard and... 

A long time algo wish Squeak could read HyperCard stacks.
If Cuis could do this , bet we have thousands users.
Anyway whats the HyperCard status ?
 
Env?ado desde Edgar's iPad mini



> El 11/7/2015, a las 13:40, Juan Vuletich <juan at jvuletich.org> escribi?:
> 
> Hi Folks,
> 
> It is not too hard to build new StrikeFonts. You need to build, by hand, files like the ones in here: https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zip and learn a bit about stuff like #installDejaVu2 . Maybe it was with this method and the files in this zip that built the existing instances of StrikeFont. Not sure.
> 
> I think DejaVu Sans Mono would be a great addition, and would look well to the existing DejaVu Sans.
> 
> In any case, don't be afraid, and play with the stuff. It is there so you can do it.
> 
> BTW, yesterday I learnt about https://github.com/tonsky/FiraCode . I think it is wonderful. We can't just adopt it, as we don't have ligatures. But maybe some time, Morphic 3 could be made to use it.
> 
> Cheers,
> Juan vuletich
> 
>> On 7/8/2015 9:03 PM, Dan Norton wrote:
>> For my PluggableListMorph, the model prepares list elements on a "String new writeStream."
>> They are not static. I need for these list elements to be aligned in columns like a small
>> spreadsheet. A fixed font would be handy - how can I install one?
>> 
>> Any other approaches to get columns in a list?
>> 
>>  - 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/20150711/224e60c8/attachment-0003.html>

From edgardec2005 at gmail.com  Sun Jul 12 04:21:11 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sun, 12 Jul 2015 06:21:11 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
Message-ID: <D1C7B7D7.159F8%edgardec2005@gmail.com>




On 7/9/15, 6:15 AM, "Phil (list)" <pbpublist at gmail.com> wrote:

> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial position
> annoying and in some cases nearly non-functional since the Morph doesn't
> have room for its halo icons.  Just wondering if this bothers anyone
> else and if maybe insetting new morphs top left by default to something
> like 50 @ 50 (something out of the way, but giving it a bit of margin
> from the edge of the screen) might be better?


Morph new openInHand could be better?

Edgar





From pbpublist at gmail.com  Sun Jul 12 12:16:15 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 12 Jul 2015 13:16:15 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <D1C7B7D7.159F8%edgardec2005@gmail.com>
References: <D1C7B7D7.159F8%edgardec2005@gmail.com>
Message-ID: <1436721375.2314.3.camel@gmail.com>

Edgar,


On Sun, 2015-07-12 at 06:21 -0300, Edgar J. De Cleene wrote:
> 
> 
> On 7/9/15, 6:15 AM, "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > This is a minor nit but when I'm developing Morphs I often need to
> > instantiate them manually via something like 'MorphName new
> > openInWorld.'  When I do that, I almost always find its initial position
> > annoying and in some cases nearly non-functional since the Morph doesn't
> > have room for its halo icons.  Just wondering if this bothers anyone
> > else and if maybe insetting new morphs top left by default to something
> > like 50 @ 50 (something out of the way, but giving it a bit of margin
> > from the edge of the screen) might be better?
> 
> 
> Morph new openInHand could be better?
> 

I find that's not always an option in the early stages of working on a
Morph as there are often initialization dependencies that I haven't
worked out at that stage causing openInHand not to work.  Once I have
everything working, then I go back and figure out what needs to happen
to get it running with openInHand...


> Edgar
> 
> 
> 
Thanks,
Phil




From edgardec2005 at gmail.com  Sun Jul 12 13:21:03 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sun, 12 Jul 2015 15:21:03 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436721375.2314.3.camel@gmail.com>
Message-ID: <D1C8365F.15A07%edgardec2005@gmail.com>




On 7/12/15, 2:16 PM, "Phil (list)" <pbpublist at gmail.com> wrote:

> I find that's not always an option in the early stages of working on a
> Morph as there are often initialization dependencies that I haven't
> worked out at that stage causing openInHand not to work.  Once I have
> everything working, then I go back and figure out what needs to happen
> to get it running with openInHand...

Ok.
Could share yours code not working with openInHand ?

Edgar





From pbpublist at gmail.com  Sun Jul 12 15:23:37 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 12 Jul 2015 16:23:37 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <D1C8365F.15A07%edgardec2005@gmail.com>
References: <D1C8365F.15A07%edgardec2005@gmail.com>
Message-ID: <1436732617.2314.17.camel@gmail.com>

On Sun, 2015-07-12 at 15:21 -0300, Edgar J. De Cleene wrote:
> 
> 
> On 7/12/15, 2:16 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > I find that's not always an option in the early stages of working on a
> > Morph as there are often initialization dependencies that I haven't
> > worked out at that stage causing openInHand not to work.  Once I have
> > everything working, then I go back and figure out what needs to happen
> > to get it running with openInHand...
> 
> Ok.
> Could share yours code not working with openInHand ?
> 

I think a recent example was the Dan's BouncingAtomsMorph which could
not be invoked from the New Morph... menu until I submitted a fix.  It
was an easy fix and I run into this problem quite often in the early
stages of Morph development.  openInHand calls doOneCycleNow (or maybe
it's doOneCycle... I forget which) which results in the Morph needing to
draw earlier than with openInWorld.  This is a problem if the Morph
isn't fully initialized and ready to be drawn yet.  It's not a big deal,
just part of how I develop Morphs and why I use openInWorld until I get
things sorted out.  Also, when I'm developing a Morph I'm usually
invoking it from a workspace or code browser and don't want to be
dealing with it interactively yet since it usually isn't fully
functional anyway.

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





From edgardec2005 at gmail.com  Sun Jul 12 16:02:31 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sun, 12 Jul 2015 18:02:31 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436732617.2314.17.camel@gmail.com>
Message-ID: <D1C85C37.15A14%edgardec2005@gmail.com>




On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:

> I think a recent example was the Dan's BouncingAtomsMorph which could
> not be invoked from the New Morph... menu until I submitted a fix.  It
> was an easy fix and I run into this problem quite often in the early
> stages of Morph development.  openInHand calls doOneCycleNow (or maybe
> it's doOneCycle... I forget which) which results in the Morph needing to
> draw earlier than with openInWorld.  This is a problem if the Morph
> isn't fully initialized and ready to be drawn yet.  It's not a big deal,
> just part of how I develop Morphs and why I use openInWorld until I get
> things sorted out.  Also, when I'm developing a Morph I'm usually
> invoking it from a workspace or code browser and don't want to be
> dealing with it interactively yet since it usually isn't fully
> functional anyway.

Very instructive.
Thanks a lot.

Edgar





From dnorton at mindspring.com  Sun Jul 12 21:20:55 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 12 Jul 2015 22:20:55 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <D1C85C37.15A14%edgardec2005@gmail.com>
References: <1436732617.2314.17.camel@gmail.com>,
	<D1C85C37.15A14%edgardec2005@gmail.com>
Message-ID: <55A32087.26820.2A728B2@dnorton.mindspring.com>

On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:

> 
> 
> 
> On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > I think a recent example was the Dan's BouncingAtomsMorph which
> could
> > not be invoked from the New Morph... menu until I submitted a fix.
> It
> > was an easy fix and I run into this problem quite often in the
> early
> > stages of Morph development.  openInHand calls doOneCycleNow (or
> maybe
> > it's doOneCycle... I forget which) which results in the Morph
> needing to
> > draw earlier than with openInWorld.  This is a problem if the
> Morph
> > isn't fully initialized and ready to be drawn yet.  It's not a big
> deal,
> > just part of how I develop Morphs and why I use openInWorld until
> I get
> > things sorted out.  Also, when I'm developing a Morph I'm
> usually
> > invoking it from a workspace or code browser and don't want to
> be
> > dealing with it interactively yet since it usually isn't fully
> > functional anyway.
> 
> Very instructive.
> Thanks a lot.
> 
> Edgar
>

Yes, thank you Phil for the fix. I needed to learn that. I put the history of the change on:

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

The commit is "343a986"  "starts from new morph menu"

 - Dan




From pbpublist at gmail.com  Sun Jul 12 23:41:03 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 13 Jul 2015 00:41:03 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <55A32087.26820.2A728B2@dnorton.mindspring.com>
References: <1436732617.2314.17.camel@gmail.com>
	, <D1C85C37.15A14%edgardec2005@gmail.com>
	<55A32087.26820.2A728B2@dnorton.mindspring.com>
Message-ID: <1436762463.2314.19.camel@gmail.com>

On Sun, 2015-07-12 at 22:20 -0400, Dan Norton wrote:
> On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:
> 
> > 
> > 
> > 
> > On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
> > 
> > > I think a recent example was the Dan's BouncingAtomsMorph which
> > could
> > > not be invoked from the New Morph... menu until I submitted a fix.
> > It
> > > was an easy fix and I run into this problem quite often in the
> > early
> > > stages of Morph development.  openInHand calls doOneCycleNow (or
> > maybe
> > > it's doOneCycle... I forget which) which results in the Morph
> > needing to
> > > draw earlier than with openInWorld.  This is a problem if the
> > Morph
> > > isn't fully initialized and ready to be drawn yet.  It's not a big
> > deal,
> > > just part of how I develop Morphs and why I use openInWorld until
> > I get
> > > things sorted out.  Also, when I'm developing a Morph I'm
> > usually
> > > invoking it from a workspace or code browser and don't want to
> > be
> > > dealing with it interactively yet since it usually isn't fully
> > > functional anyway.
> > 
> > Very instructive.
> > Thanks a lot.
> > 
> > Edgar
> >
> 
> Yes, thank you Phil for the fix. I needed to learn that. I put the history of the change on:
> 

Glad to chip in... thank you for giving us a nice Morphic demo!

> https://github.com/dhnorton/Cuis-Smalltalk-atoms
> 
> The commit is "343a986"  "starts from new morph menu"
> 

There it is  (I was too tired/lazy to dig up the commit reference :-)

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





From hannes.hirzel at gmail.com  Mon Jul 13 00:39:23 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 13 Jul 2015 05:39:23 +0000
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436762463.2314.19.camel@gmail.com>
References: <1436732617.2314.17.camel@gmail.com>
	<D1C85C37.15A14%edgardec2005@gmail.com>
	<55A32087.26820.2A728B2@dnorton.mindspring.com>
	<1436762463.2314.19.camel@gmail.com>
Message-ID: <CAGQxfVjPO7Q+BS=N4HEcsKtb_4g4+RmVLvZeM_KDEWPe4+61Tg@mail.gmail.com>

You mean this one

https://github.com/dhnorton/Cuis-Smalltalk-atoms/commit/343a986a8f4bdfb4bee8eb05797e4d75b881ecbe

?

--Hannes

On 7/13/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Sun, 2015-07-12 at 22:20 -0400, Dan Norton wrote:
>> On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:
>>
>> >
>> >
>> >
>> > On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
>> >
>> > > I think a recent example was the Dan's BouncingAtomsMorph which
>> > could
>> > > not be invoked from the New Morph... menu until I submitted a fix.
>> > It
>> > > was an easy fix and I run into this problem quite often in the
>> > early
>> > > stages of Morph development.  openInHand calls doOneCycleNow (or
>> > maybe
>> > > it's doOneCycle... I forget which) which results in the Morph
>> > needing to
>> > > draw earlier than with openInWorld.  This is a problem if the
>> > Morph
>> > > isn't fully initialized and ready to be drawn yet.  It's not a big
>> > deal,
>> > > just part of how I develop Morphs and why I use openInWorld until
>> > I get
>> > > things sorted out.  Also, when I'm developing a Morph I'm
>> > usually
>> > > invoking it from a workspace or code browser and don't want to
>> > be
>> > > dealing with it interactively yet since it usually isn't fully
>> > > functional anyway.
>> >
>> > Very instructive.
>> > Thanks a lot.
>> >
>> > Edgar
>> >
>>
>> Yes, thank you Phil for the fix. I needed to learn that. I put the history
>> of the change on:
>>
>
> Glad to chip in... thank you for giving us a nice Morphic demo!
>
>> https://github.com/dhnorton/Cuis-Smalltalk-atoms
>>
>> The commit is "343a986"  "starts from new morph menu"
>>
>
> There it is  (I was too tired/lazy to dig up the commit reference :-)
>
>>  - Dan
>>
>>
>> _______________________________________________
>> 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 dnorton at mindspring.com  Mon Jul 13 09:23:44 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 13 Jul 2015 07:23:44 -0700 (PDT)
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <CAGQxfVjPO7Q+BS=N4HEcsKtb_4g4+RmVLvZeM_KDEWPe4+61Tg@mail.gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
	<D1C7B7D7.159F8%edgardec2005@gmail.com>
	<1436721375.2314.3.camel@gmail.com>
	<D1C8365F.15A07%edgardec2005@gmail.com>
	<1436732617.2314.17.camel@gmail.com>
	<D1C85C37.15A14%edgardec2005@gmail.com>
	<55A32087.26820.2A728B2@dnorton.mindspring.com>
	<1436762463.2314.19.camel@gmail.com>
	<CAGQxfVjPO7Q+BS=N4HEcsKtb_4g4+RmVLvZeM_KDEWPe4+61Tg@mail.gmail.com>
Message-ID: <1436797424888-4837347.post@n4.nabble.com>

Yes, it seems there are several ways to see the commit :-)

GitHub newbie here,

 - Dan



--
View this message in context: http://forum.world.st/Default-Morph-position-something-other-than-0-0-tp4836757p4837347.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From dnorton at mindspring.com  Wed Jul 15 10:54:49 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 15 Jul 2015 11:54:49 -0400
Subject: [Cuis] Array2D newSize:
Message-ID: <55A68249.17883.775BA8@dnorton.mindspring.com>

Maybe it's my dyslexia, but isn't this backward?

"Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
| nil nil |
| nil nil |
| nil nil |

IMO it should be:
| nil nil nil |
| nil nil nil |

For example, in Squeak, "MatrixTransform2x3 identity" produces: MatrixTransform2x3(
1.0	0.0	0.0
0.0	1.0	0.0
)

Please correct me if I'm wrong.

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

From dnorton at mindspring.com  Wed Jul 15 17:23:26 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 15 Jul 2015 15:23:26 -0700 (PDT)
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A68249.17883.775BA8@dnorton.mindspring.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
Message-ID: <1436999006167-4837720.post@n4.nabble.com>


Maybe it's my dyslexia, but isn't this backward?

"Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
| nil nil |
| nil nil |
| nil nil |

IMO it should be:
| nil nil nil |
| nil nil nil |

For example, in Squeak, "MatrixTransform2x3 identity" produces:
MatrixTransform2x3(
1.0	0.0	0.0
0.0	1.0	0.0
)

Please correct me if I'm wrong.

OK, you're wrong - as long as there is a subclass called Matrix in

LinearAlgebra.pck.st

Use Matrix instead of Array2d.

(whew)




--
View this message in context: http://forum.world.st/Array2D-newSize-tp4837696p4837720.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From pbpublist at gmail.com  Wed Jul 15 18:43:12 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 15 Jul 2015 19:43:12 -0400
Subject: [Cuis] Preventing pretty print from replacing := with _?
Message-ID: <1437003792.2401.2.camel@gmail.com>

Is there a setting that will disable this substitution?  I would
actually prefer it to go the other way: if it sees an _ assignment,
replace it with :=

Thanks,
Phil




From pbpublist at gmail.com  Wed Jul 15 19:49:57 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 15 Jul 2015 20:49:57 -0400
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1436999006167-4837720.post@n4.nabble.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
Message-ID: <1437007797.2401.12.camel@gmail.com>

On Wed, 2015-07-15 at 15:23 -0700, Dan Norton wrote:
> Maybe it's my dyslexia, but isn't this backward?
> 
> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
> | nil nil |
> | nil nil |
> | nil nil |
> 
> IMO it should be:
> | nil nil nil |
> | nil nil nil |
> 
> For example, in Squeak, "MatrixTransform2x3 identity" produces:
> MatrixTransform2x3(
> 1.0	0.0	0.0
> 0.0	1.0	0.0
> )
> 
> Please correct me if I'm wrong.
> 
> OK, you're wrong - as long as there is a subclass called Matrix in
> 
> LinearAlgebra.pck.st
> 
> Use Matrix instead of Array2d.
> 

Glad that solved your problem but, ouch... that class is uncomfortably
close in name and function to the 3DTransform package I'm using for
OpenGL.  Juan: would you be open to using an extended version of my
classes so that we don't run into namespace conflicts?

One advantage that the Matrix* and Vector* classes I'm using have is
that they are mapped to native types which makes for transparent and
easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
compute shaders and you have the fastest matrix math you've ever seen,
assuming you've got medium or larger sets of data)

> (whew)
> 
> 
> 
> 
> --
> View this message in context: http://forum.world.st/Array2D-newSize-tp4837696p4837720.html
> Sent from the Cuis Smalltalk mailing list archive at Nabble.com.
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Thu Jul 16 07:43:13 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 09:43:13 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
Message-ID: <55A7A6E1.8000909@jvuletich.org>

Hi Edgar,

Is there such a project? Any reference?

Thanks,
Juan Vuletich

On 7/11/2015 5:24 PM, Edgar J De Cleene wrote:
> Quoting Casey
>
>> If we can throw in some HyperCard and... 
>
> A long time algo wish Squeak could read HyperCard stacks.
> If Cuis could do this , bet we have thousands users.
> Anyway whats the HyperCard status ?
>

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

From hannes.hirzel at gmail.com  Thu Jul 16 08:00:03 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 13:00:03 +0000
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <55A7A6E1.8000909@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
Message-ID: <CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>

 I think there was something like that. Need to search in the Squeak
list. And check the porting effort. Might be doable with Cuis these
days.

--Hannes

On 7/16/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Edgar,
>
> Is there such a project? Any reference?
>
> Thanks,
> Juan Vuletich
>
> On 7/11/2015 5:24 PM, Edgar J De Cleene wrote:
>> Quoting Casey
>>
>>> If we can throw in some HyperCard and...
>>
>> A long time algo wish Squeak could read HyperCard stacks.
>> If Cuis could do this , bet we have thousands users.
>> Anyway whats the HyperCard status ?
>>
>
>



From juan at jvuletich.org  Thu Jul 16 08:01:12 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:01:12 -0300
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <1437003792.2401.2.camel@gmail.com>
References: <1437003792.2401.2.camel@gmail.com>
Message-ID: <55A7AB18.5020601@jvuletich.org>

On 7/15/2015 8:43 PM, Phil (list) wrote:
> Is there a setting that will disable this substitution?  I would
> actually prefer it to go the other way: if it sees an _ assignment,
> replace it with :=
>
> Thanks,
> Phil

Please check #syntaxHighlightingAsYouTypeAnsiAssignment and 
#syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.

Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough 
for you?

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Thu Jul 16 08:10:02 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 13:10:02 +0000
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <55A7AB18.5020601@jvuletich.org>
References: <1437003792.2401.2.camel@gmail.com>
	<55A7AB18.5020601@jvuletich.org>
Message-ID: <CAGQxfVhV09RLrLsEsBaRKXERznoP-p+Zdxj4dOF5CnjNFtgH4Q@mail.gmail.com>

I just added an issue for this

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/67

(for Documentation which I'd like to do later, there are more of
issues like this)

Please update the issue when the answer is known.

--Hannes

On 7/16/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/15/2015 8:43 PM, Phil (list) wrote:
>> Is there a setting that will disable this substitution?  I would
>> actually prefer it to go the other way: if it sees an _ assignment,
>> replace it with :=
>>
>> Thanks,
>> Phil
>
> Please check #syntaxHighlightingAsYouTypeAnsiAssignment and
> #syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.
>
> Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough
> for you?
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Thu Jul 16 08:14:17 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:14:17 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A68249.17883.775BA8@dnorton.mindspring.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
Message-ID: <55A7AE29.3010706@jvuletich.org>

Hi Dan,

On 7/15/2015 12:54 PM, Dan Norton wrote:
> Maybe it's my dyslexia, but isn't this backward?

It is not you. It is the unfortunate fact that 2 conventions exist for this

> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
> | nil nil |
> | nil nil |
> | nil nil |

Yes. 2 at 3 is a point with x=2 and y=3. x is usually regarded as the 
horizontal coordinate and y as the vertical coordinate. This is the 
universal convention for pixels in Displays and Forms and for 
mathematical points in the Cartesian plane.

> IMO it should be:
> | nil nil nil |
> | nil nil nil |

Yes. That's why Array2D class also has #height:width: and #width:height. 
Matrices are usually accessed with i, j; where i is the row and j the 
column. Array2D instances have #x:y: and #i:j: , and the order of the 
arguments is swapped. So you can pick the convention that bests suits 
what you are doing.

> For example, in Squeak, "MatrixTransform2x3 identity" produces: 
> MatrixTransform2x3(
> 1.0       0.0       0.0
> 0.0       1.0       0.0
> )

Yes. It uses the matrix convention.

> Please correct me if I'm wrong.
>
>  - Dan
>

  HTH.

In addition to all this Matrices have origin (1,1), while the 
mathematical plane and Forms have origin (0,0). But Matrices and Forms 
have the origin at the topLeft, while the mathematical plane has the 
origin at the bottomLeft (or at the center if you allow negative 
coordinates).

To make things even more complicated, when mapping the mathematical 
plane to a Form, you can map integer numbers in the plane to the center 
of the pixels (the convention that makes most sense to me) or to pixel 
corners (as Squeak / Cuis Rectangles do).

All unnecesary complications, but that we can't avoid.

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

From juan at jvuletich.org  Thu Jul 16 08:16:54 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:16:54 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1436999006167-4837720.post@n4.nabble.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
Message-ID: <55A7AEC6.9090908@jvuletich.org>

On 7/15/2015 7:23 PM, Dan Norton wrote:
> Maybe it's my dyslexia, but isn't this backward?
>
> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
> | nil nil |
> | nil nil |
> | nil nil |
>
> IMO it should be:
> | nil nil nil |
> | nil nil nil |
>
> For example, in Squeak, "MatrixTransform2x3 identity" produces:
> MatrixTransform2x3(
> 1.0	0.0	0.0
> 0.0	1.0	0.0
> )
>
> Please correct me if I'm wrong.
>
> OK, you're wrong - as long as there is a subclass called Matrix in
>
> LinearAlgebra.pck.st
>
> Use Matrix instead of Array2d.
>
> (whew)

No, you are not wrong.

But use Matrix, or maybe FloatMatrix if it makes sense for you.

Also keep in mind that Cuis has AffineTransformation, that is almost 
identical to Squeak's MatrixTransform2x3 (except for Squeak's doing some 
very arguable rounding to integer of results).

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 16 08:23:35 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:23:35 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1437007797.2401.12.camel@gmail.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>	<1436999006167-4837720.post@n4.nabble.com>
	<1437007797.2401.12.camel@gmail.com>
Message-ID: <55A7B057.4050803@jvuletich.org>

Hi Phil,

On 7/15/2015 9:49 PM, Phil (list) wrote:
> Glad that solved your problem but, ouch... that class is uncomfortably
> close in name and function to the 3DTransform package I'm using for
> OpenGL.  Juan: would you be open to using an extended version of my
> classes so that we don't run into namespace conflicts?

Indeed we need to do something with this. Check the "Math 3D" package. 
It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need 
double precision for satellite image processing at work.

There is a lot of overlap with yours, but you are using 32 bit Floats.

> One advantage that the Matrix* and Vector* classes I'm using have is
> that they are mapped to native types which makes for transparent and
> easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
> compute shaders and you have the fastest matrix math you've ever seen,
> assuming you've got medium or larger sets of data)

Yes. This is indeed great. We need to build a single, uniform package 
with this stuff, that handles both 32 and 64 bit Floats and can take 
advantage of GPUs.

BTW, have you used OpenCL from Cuis? I'll be needing to work with that 
in a few months.

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Thu Jul 16 08:28:07 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 13:28:07 +0000
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A7AEC6.9090908@jvuletich.org>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
	<55A7AEC6.9090908@jvuletich.org>
Message-ID: <CAGQxfVjFGwyjhX_tJkFx3F8WtBnbuDA1huqcQ=fJwG-M5+4bjQ@mail.gmail.com>

Created an issue for me to sometime later this year add to the documentation

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/68

--Hannes

On 7/16/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/15/2015 7:23 PM, Dan Norton wrote:
>> Maybe it's my dyslexia, but isn't this backward?
>>
>> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
>> | nil nil |
>> | nil nil |
>> | nil nil |
>>
>> IMO it should be:
>> | nil nil nil |
>> | nil nil nil |
>>
>> For example, in Squeak, "MatrixTransform2x3 identity" produces:
>> MatrixTransform2x3(
>> 1.0	0.0	0.0
>> 0.0	1.0	0.0
>> )
>>
>> Please correct me if I'm wrong.
>>
>> OK, you're wrong - as long as there is a subclass called Matrix in
>>
>> LinearAlgebra.pck.st
>>
>> Use Matrix instead of Array2d.
>>
>> (whew)
>
> No, you are not wrong.
>
> But use Matrix, or maybe FloatMatrix if it makes sense for you.
>
> Also keep in mind that Cuis has AffineTransformation, that is almost
> identical to Squeak's MatrixTransform2x3 (except for Squeak's doing some
> very arguable rounding to integer of results).
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Thu Jul 16 09:49:52 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 14:49:52 +0000
Subject: [Cuis] Time stamp of source code change of a method?
Message-ID: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>

Hello

I'd like to do a query finding out about the time stamp of  source
code changes of all methods in the Cuis image and then do a list with
the following four columns


ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName, DateOfChange

Help is appreciated.

Hannes



From hannes.hirzel at gmail.com  Thu Jul 16 09:51:58 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 14:51:58 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
Message-ID: <CAGQxfVgdYn2s2A2e54SYhh8se8tJfv1QwHOw7u6fVkTFrrt8jA@mail.gmail.com>

P.S. I'd like to do this on a Cuis image of January 1st and then on a
Cuis image 30th June 2015.

And then do a bar chart


Package
NumberOfMethodsChanged

On 7/16/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Hello
>
> I'd like to do a query finding out about the time stamp of  source
> code changes of all methods in the Cuis image and then do a list with
> the following four columns
>
>
> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName, DateOfChange
>
> Help is appreciated.
>
> Hannes
>



From pbpublist at gmail.com  Thu Jul 16 13:36:29 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 16 Jul 2015 14:36:29 -0400
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <55A7AB18.5020601@jvuletich.org>
References: <1437003792.2401.2.camel@gmail.com>
	<55A7AB18.5020601@jvuletich.org>
Message-ID: <1437071789.2255.28.camel@gmail.com>

Juan,

On Thu, 2015-07-16 at 10:01 -0300, Juan Vuletich wrote:
> On 7/15/2015 8:43 PM, Phil (list) wrote:
> > Is there a setting that will disable this substitution?  I would
> > actually prefer it to go the other way: if it sees an _ assignment,
> > replace it with :=
> >
> > Thanks,
> > Phil
> 
> Please check #syntaxHighlightingAsYouTypeAnsiAssignment and 
> #syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.
> 
> Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough 
> for you?
> 

I'm already setting #syntaxHighlightingAsYouTypeAnsiAssignment to true
and leaving #syntaxHighlightingAsYouTypeLeftArrowAssignment at false.
That seems to work for everything except pretty printing.  I also played
with #allowUnderscoreAssignments but that just determines whether or not
_ is valid and doesn't stop pretty print trying to use underscores
anyway (which is entertaining because then pp produces invalid code :-)

> Cheers,
> Juan Vuletich

Thanks,
Phil




From pbpublist at gmail.com  Thu Jul 16 15:13:48 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 16 Jul 2015 16:13:48 -0400
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A7B057.4050803@jvuletich.org>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
	<1437007797.2401.12.camel@gmail.com> <55A7B057.4050803@jvuletich.org>
Message-ID: <1437077628.2255.77.camel@gmail.com>

Juan,

On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 7/15/2015 9:49 PM, Phil (list) wrote:
> > Glad that solved your problem but, ouch... that class is uncomfortably
> > close in name and function to the 3DTransform package I'm using for
> > OpenGL.  Juan: would you be open to using an extended version of my
> > classes so that we don't run into namespace conflicts?
> 
> Indeed we need to do something with this. Check the "Math 3D" package. 
> It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need 
> double precision for satellite image processing at work.
> 

You space guys with your astronomically large numbers and being sooooo
concerned with precisely where things are.  Why can't you accept
'there-ish' like the rest of us? :-)

(disclaimer: the events depicted in Gravity should in no way cast
aspersions as to the inadequacies of 32-bit floats...)

Ahh... hadn't noticed the Math 3D stuff before.  For OpenGL, I've been
using a combination of the Collections-Arrayed, Collections-Balloon and
3DTransform (i.e. the 3DTransform package which provides the Vector* and
Matrix* classes, which came from Croquet, or whatever upstream source
they pulled from)

The Float64* class hierarchy in Math 3D appears to just be a parallel
64-bit hierarchy (with some slight naming convention differences) to the
32-bit Vector* and Matrix* classes from 3DTransform.  So what we'd
probably want to do there is merge them (i.e. keeping both the 64-bit
and 32-versions... when you need one or the other, you absolutely need
it) into a single package and make sure they have identical
functionality and consistent naming conventions (I have no preference on
which conventions we use other than that they be consistent.  Makes no
difference to me whether I'm using Vector2 or Float32Vector2 or whatever
else would make sense)  If we did that, this would just leave the
question of how the LinearAlgebra and Array2D classes fit into this (one
thing I don't currently have but would like is an arbitrary MxN 32-bit
float matrix class)...

At first glance, the naming convention mapping appears to be:

Float64Color4 -> VectorColor
Float64Matrix4x4 -> Matrix4x4
Float64Rotation -> Quaternion
Float64Vector2 -> Vector2
Float64Vector3 -> Vector3
Float64Vector4 -> Vector4

With the balances of the classes being unique to 3DTransform. (Just
curious: for Float64Vector* why don't you use a common base class
similar to Vector?)

> There is a lot of overlap with yours, but you are using 32 bit Floats.
> 

For now... at some point I'm sure I'll be needing 64-bit Floats as well.
Since both the VM and OpenGL are limited to 32-bits, that's been doing
the job for me. (my priority is currently performance over precision
since for me it's just an errant pixel, for you it might be a house or
your satellite heading for the ISS...)

> > One advantage that the Matrix* and Vector* classes I'm using have is
> > that they are mapped to native types which makes for transparent and
> > easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
> > compute shaders and you have the fastest matrix math you've ever seen,
> > assuming you've got medium or larger sets of data)
> 
> Yes. This is indeed great. We need to build a single, uniform package 
> with this stuff, that handles both 32 and 64 bit Floats and can take 
> advantage of GPUs.
> 
> BTW, have you used OpenCL from Cuis? I'll be needing to work with that 
> in a few months.
> 

Not yet, but pretty much all of the same issues I've run into with
OpenGL would apply for OpenCL (i.e. it's all FFI as far as the VM is
concerned unless you're going to create a plugin, but even then you
still have the same issues) so I think we should be able to get to a
unified vector/matrix structure that works for both of us.  In both
cases the key is to minimize the amount of work done to marshal native
data in and out (slow/expensive conversions have a dramatic and
detrimental cost for small data sets / short computations) while keeping
the data as easy to work with as possible in both the Smalltalk and FFI
(whether OpenGL/OpenCL/CUDA/Metal/Vulcan/etc.) environments.

Something to keep in the back of your mind: OMeta.  One of the many
reasons I get so geeked out about it is that an OpenGL shader is just
another language that can be targeted via source-to-source translation
(i.e. dynamically generated GPU code written in something similar to
Slang or another DSL from Cuis).  OpenCL shouldn't be terribly
different...

> Cheers,
> Juan Vuletich

Thanks,
Phil




From dnorton at mindspring.com  Thu Jul 16 20:43:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 16 Jul 2015 21:43:22 -0400
Subject: [Cuis] Block Arguments
Message-ID: <55A85DBA.15429.29625A6@dnorton.mindspring.com>

Hi Juan,

On windows, when the attached class method is added to StrikeFont and cmd-d is done on 
the comment, it produces:

'Error: This block accepts 0 arguments, but was called with 1 argument.'

AFAIKT it is not passing any arguments and the files do exist. Maybe a bug?

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150716/ea2323c1/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StrikeFont class-createTrueTypebolditalicboldItalic.zip
Type: application/zip
Size: 624 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150716/ea2323c1/attachment-0003.zip>

From pbpublist at gmail.com  Thu Jul 16 21:11:45 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 16 Jul 2015 22:11:45 -0400
Subject: [Cuis] Block Arguments
In-Reply-To: <55A85DBA.15429.29625A6@dnorton.mindspring.com>
References: <55A85DBA.15429.29625A6@dnorton.mindspring.com>
Message-ID: <1437099105.2255.92.camel@gmail.com>

On Thu, 2015-07-16 at 21:43 -0400, Dan Norton wrote:
> Hi Juan,
> 
> 
> On windows, when the attached class method is added to StrikeFont and
> cmd-d is done on the comment, it produces:
> 
> 
> 'Error: This block accepts 0 arguments, but was called with 1
> argument.'
> 
> 
> AFAIKT it is not passing any arguments and the files do exist. Maybe a
> bug?
> 
But it is passing an argument to your ifExistsDo: block (the filestream)
and your block doesn't accept any.  If you don't care about the
filestream, change your blocks to [:filestream| {baseName. ' OK'} print]
etc. and ignore the parameter.

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





From juan at jvuletich.org  Fri Jul 17 08:03:16 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:03:16 -0300
Subject: [Cuis] DIRECT version number
In-Reply-To: <CAGQxfVg4pDR8sL9ezpcvtH3DFQuG7Si=wiG=mh+daW0seUTO8g@mail.gmail.com>
References: <CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA@mail.gmail.com>	<55A7A607.7050304@jvuletich.org>	<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A@mail.gmail.com>	<55A7B5DA.1020103@jvuletich.org>	<CAGQxfVg7ZLtdkz211LwJPe6uFxSUBMvgeJhafD+ZSxixSMo6tA@mail.gmail.com>
	<CAGQxfVg4pDR8sL9ezpcvtH3DFQuG7Si=wiG=mh+daW0seUTO8g@mail.gmail.com>
Message-ID: <55A8FD14.8060502@jvuletich.org>

(cc the mail list)

Yes, we could do it. I kinda stopped doing "releases" because with a 
constantly updating GitHub repo, each commit can be considered a "release".

So, the question is,
What is a release? How is it different from a GitHub commit?
What is the value of a release?

Maybe it is just about following a tradition (from the time of diskettes 
and CD Rom). Or maybe it is about crating echos in other places (tweets, 
blogs, etc)...

What do others think?

Cheers,
Juan Vuletich

On 7/16/2015 4:36 PM, H. Hirzel wrote:
> What I mean is this
>
> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
>
> New in Cuis 4.2 (released July 25, 2013)
>
>      Packages now have dependencies
>
>      Package loading greatly enhanced
>
>      Moved non-essential stuff to optional packages. Cuis is now below
> 500 classes and 100kLOC. Reduction was about 25%
>
>      Many bugfixes, and minor enhancements and cleanup
>
>
> NO RELEASE SINCE since July 2013!
>
>
> I suggest to do a release 4.3 soon and among other things have a
> clean-up  and documentation phase and then go for a 4.4 release after
> three months.
> I am willing to contribute to this.
>
> --HH
>
> On 7/16/15, H. Hirzel<hannes.hirzel at gmail.com>  wrote:
>> Thank you for the answer. Your conclusion nicely summarizes my concerns,
>>
>> I will think about it.
>>
>> As for no 1) parts of the system that are affected:
>>
>> Going for a list of all methods, taking the time stamp of last change
>> and do a graph of number of affected methods in each subsystem would
>> be helpful.
>>
>> That shows the impact of changes and allows to choose a proper commit
>> where I want to go for.
>>
>> That could be a built-in report.
>>
>> No 2) Level of risk involved
>> is more difficult to do automaticallyz
>>
>> --HH
>>
>>
>>
>>
>> On 7/16/15, Juan Vuletich<juan at jvuletich.org>  wrote:
>>> Hi Hannes,
>>>
>>> On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>>> Thank you Juan, for answering.
>>>>
>>>> At the moment I feel uncomfortable using Cuis because it is currently
>>>> a quite fast moving target. I perceive quite a number of API changes
>>>> though this might be wrong. But I do not know because there are no
>>>> release notes which summarize it.
>>> Yes, that's true. Besides, we don't have a specification of what is an
>>> API and what is not. So, almost any change can be considered an API
>>> change.
>>>
>>> I don't want you to feel uncomfortable. Let's work this out.
>>>
>>>>    And I do not now in which state my stuff and the general Cuis stuff
>>>> ist.
>>>>
>>>> I need a new 'base line', i.e. a release number to which I can refer
>>>> to when upgrading my code.
>>> Well, but we do have that. It is the update number. It is part of any
>>> Cuis image I've ever committed to the repo.
>>>
>>> The problem, I think, is not identifying well defined Cuis releases. The
>>> problem is knowing how updates could affect your code.
>>>
>>>> Of course the other option  is to just follow the most recent update
>>>> all the time. That would  call for some kind of continuous integration
>>>> testing 'Cuis style' which I not have either.
>>>>
>>>> E.g. if you could do a writeup how you do test Cuis before each new
>>>> commit (there are over 50 this year) and which scripts you use I could
>>>> apply the same thing for my packages.
>>>>
>>>> It has to be something which can be done quickly. Semi-Automatic is
>>>> fine. A check list with
>>>>
>>>> - do this
>>>> - then execute that script
>>>> - Open .. this and that
>>>> - And finally run a report on  ...
>>>>
>>>> would be fine.
>>> I don't have that either. I run the tests from time to time (I'll start
>>> doing it before any commit, and add the xml report to the rep). But this
>>> is not the most important reason why Cuis is solid. Cuis is very
>>> reliable because:
>>> - I'm not too bad as a coder.
>>> - I do my own code revisions at least one day after each change.
>>> - I use Cuis every day, and spot most problems in the updates, before
>>> commtting them to the repo.
>>> - I really, really care about code quality.
>>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>>> is a big responsibility, given how important I think Smalltalk-80 is.
>>>
>>> So, I suggest running your tests when updating your image, or migrating
>>> your code to an updated image.
>>>
>>> In any case, I think this doesn't answer your concerns. What you need is
>>> some way to know which updates could affect you, to review them in
>>> detail, and understanding their effect on your code. A list of the
>>> affected classes and/or methods for each update makes no sense. Cuis can
>>> already show you that very easily. Perhaps each update should include:
>>>
>>> 1) parts of the system that are affected:
>>> - Kernel
>>> - Compiler
>>> - Tools
>>> - Morphic
>>> - etc
>>>
>>> 2) Level of risk involved
>>> - very unlikely to break code that depends on this part of the system
>>> - could perhaps break code that depends on this part of the system
>>> - will most likely break code that depends on this part of the system
>>>
>>> Or something like that.
>>>
>>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>>> free to answer there if you agree.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>> However doing a release tag in github is really not a big deal if you
>>>> actually take the plunge.
>>>>
>>>> You are not alone in not using this option.
>>>>
>>>> It took me two years to realize that I can learn to do it and actually
>>>> do a release in 5 minutes.....
>>>>
>>>> So I suggest do a release just continuing where you left off last time.
>>>>
>>>> Then people will start to realise there is something to test against.
>>>> And new update requests will come and you can do another one.
>>>>
>>>> So the release which I am asking for is not a big deal. Just a tag on a
>>>> commit.
>>>>
>>>> I'd like to explore the direct authoring tools offered by Ken Dickey.
>>>>
>>>> With the aim of producing a very simple Hypercard / Powerpoint like
>>>> authoring environment.
>>>>
>>>> And do more with OMeta.
>>>>
>>>> Happy continued Cuis curating .....
>>>> And thank you very much indeed for your great work maintaining this
>>>> environment.
>>>>
>>>>
>>>> Hannes
>>>>
>>>>
>>>>
>>>> On 7/16/15, Juan Vuletich<juan at jvuletich.org>   wrote:
>>>>> On 7/12/2015 6:27 PM, H. Hirzel wrote:
>>>>>> Hi Juan
>>>>>>
>>>>>> Regarding a Cuis version number. I suggest that you just continue with
>>>>>> a new version number where you left off last time.
>>>>>>
>>>>>> It is just about having a version number to have a new baseline to
>>>>>> refer to. This is helpful for testing and documentation.
>>>>>>
>>>>>> I do not think it is a big issue.
>>>>>>
>>>>>> API changes require a new version number.
>>>>>>
>>>>>> Kind regards
>>>>>> Hannes
>>>>> Hi Hannes,
>>>>>
>>>>> Sometimes I don't pay enough attention to stuff like this, so feel free
>>>>> to request action from me when you feel appropriate :)
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>




From juan at jvuletich.org  Fri Jul 17 08:39:47 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:39:47 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
Message-ID: <55A905A3.1060100@jvuletich.org>

Additional stuff about versioning, and how to keep your code working as 
Cuis changes.

Please share your ideas and thoughts about this.

We all want to ease development and maintenance of all sorts of projects 
while allowing a moderate rate of change to Cuis itself...

Cheers,
Juan Vuletich

-------- Original Message --------
From: 	- Thu Jul 16 10:47:08 2015
X-Mozilla-Status: 	0001
X-Mozilla-Status2: 	00800000
X-Mozilla-Keys: 	
Message-ID: 	<55A7B5DA.1020103 at jvuletich.org>
Date: 	Thu, 16 Jul 2015 10:47:06 -0300
From: 	Juan Vuletich <juan at jvuletich.org>
User-Agent: 	Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; 
rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 	1.0
To: 	H. Hirzel <hannes.hirzel at gmail.com>
Subject: 	Re: DIRECT version number
References: 
<CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA at mail.gmail.com> 
<55A7A607.7050304 at jvuletich.org> 
<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
In-Reply-To: 
<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
Content-Type: 	text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 	7bit



Hi Hannes,

On 7/16/2015 9:57 AM, H. Hirzel wrote:
>  Thank you Juan, for answering.
>
>  At the moment I feel uncomfortable using Cuis because it is currently
>  a quite fast moving target. I perceive quite a number of API changes
>  though this might be wrong. But I do not know because there are no
>  release notes which summarize it.

Yes, that's true. Besides, we don't have a specification of what is an
API and what is not. So, almost any change can be considered an API change.

I don't want you to feel uncomfortable. Let's work this out.

>    And I do not now in which state my stuff and the general Cuis stuff ist.
>
>  I need a new 'base line', i.e. a release number to which I can refer
>  to when upgrading my code.

Well, but we do have that. It is the update number. It is part of any
Cuis image I've ever committed to the repo.

The problem, I think, is not identifying well defined Cuis releases. The
problem is knowing how updates could affect your code.

>  Of course the other option  is to just follow the most recent update
>  all the time. That would  call for some kind of continuous integration
>  testing 'Cuis style' which I not have either.
>
>  E.g. if you could do a writeup how you do test Cuis before each new
>  commit (there are over 50 this year) and which scripts you use I could
>  apply the same thing for my packages.
>
>  It has to be something which can be done quickly. Semi-Automatic is
>  fine. A check list with
>
>  - do this
>  - then execute that script
>  - Open .. this and that
>  - And finally run a report on  ...
>
>  would be fine.

I don't have that either. I run the tests from time to time (I'll start
doing it before any commit, and add the xml report to the rep). But this
is not the most important reason why Cuis is solid. Cuis is very
reliable because:
- I'm not too bad as a coder.
- I do my own code revisions at least one day after each change.
- I use Cuis every day, and spot most problems in the updates, before
commtting them to the repo.
- I really, really care about code quality.
- I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
is a big responsibility, given how important I think Smalltalk-80 is.

So, I suggest running your tests when updating your image, or migrating
your code to an updated image.

In any case, I think this doesn't answer your concerns. What you need is
some way to know which updates could affect you, to review them in
detail, and understanding their effect on your code. A list of the
affected classes and/or methods for each update makes no sense. Cuis can
already show you that very easily. Perhaps each update should include:

1) parts of the system that are affected:
- Kernel
- Compiler
- Tools
- Morphic
- etc

2) Level of risk involved
- very unlikely to break code that depends on this part of the system
- could perhaps break code that depends on this part of the system
- will most likely break code that depends on this part of the system

Or something like that.

BTW, this is a very relevant topic for discussing on the mail list. Feel
free to answer there if you agree.

Cheers,
Juan Vuletich


>  However doing a release tag in github is really not a big deal if you
>  actually take the plunge.
>
>  You are not alone in not using this option.
>
>  It took me two years to realize that I can learn to do it and actually
>  do a release in 5 minutes.....
>
>  So I suggest do a release just continuing where you left off last time.
>
>  Then people will start to realise there is something to test against.
>  And new update requests will come and you can do another one.
>
>  So the release which I am asking for is not a big deal. Just a tag on a commit.
>
>  I'd like to explore the direct authoring tools offered by Ken Dickey.
>
>  With the aim of producing a very simple Hypercard / Powerpoint like
>  authoring environment.
>
>  And do more with OMeta.
>
>  Happy continued Cuis curating .....
>  And thank you very much indeed for your great work maintaining this environment.
>
>
>  Hannes
>
>
>
>  On 7/16/15, Juan Vuletich<juan at jvuletich.org>   wrote:
>>  On 7/12/2015 6:27 PM, H. Hirzel wrote:
>>>  Hi Juan
>>>
>>>  Regarding a Cuis version number. I suggest that you just continue with
>>>  a new version number where you left off last time.
>>>
>>>  It is just about having a version number to have a new baseline to
>>>  refer to. This is helpful for testing and documentation.
>>>
>>>  I do not think it is a big issue.
>>>
>>>  API changes require a new version number.
>>>
>>>  Kind regards
>>>  Hannes
>>  Hi Hannes,
>>
>>  Sometimes I don't pay enough attention to stuff like this, so feel free
>>  to request action from me when you feel appropriate :)
>>
>>  Cheers,
>>  Juan Vuletich
>>

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

From Ken.Dickey at whidbey.com  Fri Jul 17 08:40:55 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 17 Jul 2015 06:40:55 -0700
Subject: [Cuis] DIRECT version number
In-Reply-To: <55A8FD14.8060502@jvuletich.org>
References: <CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA@mail.gmail.com>
	<55A7A607.7050304@jvuletich.org>
	<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A@mail.gmail.com>
	<55A7B5DA.1020103@jvuletich.org>
	<CAGQxfVg7ZLtdkz211LwJPe6uFxSUBMvgeJhafD+ZSxixSMo6tA@mail.gmail.com>
	<CAGQxfVg4pDR8sL9ezpcvtH3DFQuG7Si=wiG=mh+daW0seUTO8g@mail.gmail.com>
	<55A8FD14.8060502@jvuletich.org>
Message-ID: <20150717064055.f8bc194236afd071b8afff51@whidbey.com>

On Fri, 17 Jul 2015 10:03:16 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> So, the question is,
> What is a release? How is it different from a GitHub commit?
> What is the value of a release?

IMHO, a Release is a stable point, expected to be robust and with some level of support, which one can develop against without concern for the ground changing under one's feet.

This is important in commercial projects and things one likes to demo and share around.

In particular, I would expect a Release for Cuis to have major associated packages also maintained at that particular release level.  It would be good to package the core release and associated packages matching that release together.

At this point, I test most of my packages with many (not all) Cuis Commits so that I can find/fix breakage as it happens.  I expect to do this.  I want Cuis to change for the better, radically, but I am not keeping a set of packages pegged to a historical Release.

I am willing to do maintain versions my packages for a particular Cuis release, e.g. for stable demos.  However, I would prefer Releases to be a long intervals (say a year) or after some radical change has been introduced and stabilized.

So far, this has not been a problem, but as usage increases ...

$0.02
-KenD



From juan at jvuletich.org  Fri Jul 17 08:48:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:48:09 -0300
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
Message-ID: <55A90799.7080302@jvuletich.org>

On 7/16/2015 11:49 AM, H. Hirzel wrote:
> Hello
>
> I'd like to do a query finding out about the time stamp of  source
> code changes of all methods in the Cuis image and then do a list with
> the following four columns
>
>
> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName, DateOfChange
>
> Help is appreciated.
>
> Hannes

Check #timeStampFor:class:reverseOrdinal: and in general 
#annotationForSelector:ofClass:

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Jul 17 08:51:38 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:51:38 -0300
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <1437071789.2255.28.camel@gmail.com>
References: <1437003792.2401.2.camel@gmail.com>	
	<55A7AB18.5020601@jvuletich.org>
	<1437071789.2255.28.camel@gmail.com>
Message-ID: <55A9086A.9060600@jvuletich.org>

On 7/16/2015 3:36 PM, Phil (list) wrote:
> Juan,
>
> On Thu, 2015-07-16 at 10:01 -0300, Juan Vuletich wrote:
>> On 7/15/2015 8:43 PM, Phil (list) wrote:
>>> Is there a setting that will disable this substitution?  I would
>>> actually prefer it to go the other way: if it sees an _ assignment,
>>> replace it with :=
>>>
>>> Thanks,
>>> Phil
>> Please check #syntaxHighlightingAsYouTypeAnsiAssignment and
>> #syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.
>>
>> Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough
>> for you?
>>
> I'm already setting #syntaxHighlightingAsYouTypeAnsiAssignment to true
> and leaving #syntaxHighlightingAsYouTypeLeftArrowAssignment at false.
> That seems to work for everything except pretty printing.

But, are you using Shout on the code pane? Can you list simple steps to 
reproduce on a fresh Cuis image?

>    I also played
> with #allowUnderscoreAssignments but that just determines whether or not
> _ is valid and doesn't stop pretty print trying to use underscores
> anyway (which is entertaining because then pp produces invalid code :-)

Yep. We could indeed fix that. Ok. I'll include it in the next commit.

Cheers,
Juan Vuletich

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




From juan at jvuletich.org  Fri Jul 17 09:15:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 11:15:53 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1437077628.2255.77.camel@gmail.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>	
	<1436999006167-4837720.post@n4.nabble.com>	
	<1437007797.2401.12.camel@gmail.com>
	<55A7B057.4050803@jvuletich.org>
	<1437077628.2255.77.camel@gmail.com>
Message-ID: <55A90E19.3060005@jvuletich.org>

Hi Phil,

On 7/16/2015 5:13 PM, Phil (list) wrote:
> Juan,
>
> On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
>> Hi Phil,
>>
>> On 7/15/2015 9:49 PM, Phil (list) wrote:
>>> Glad that solved your problem but, ouch... that class is uncomfortably
>>> close in name and function to the 3DTransform package I'm using for
>>> OpenGL.  Juan: would you be open to using an extended version of my
>>> classes so that we don't run into namespace conflicts?
>> Indeed we need to do something with this. Check the "Math 3D" package.
>> It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need
>> double precision for satellite image processing at work.
>>
> You space guys with your astronomically large numbers and being sooooo
> concerned with precisely where things are.  Why can't you accept
> 'there-ish' like the rest of us? :-)

:) I would... But if you want Google Earth level of precision, you do 
need them...

> (disclaimer: the events depicted in Gravity should in no way cast
> aspersions as to the inadequacies of 32-bit floats...)
>
> Ahh... hadn't noticed the Math 3D stuff before.  For OpenGL, I've been
> using a combination of the Collections-Arrayed, Collections-Balloon and
> 3DTransform (i.e. the 3DTransform package which provides the Vector* and
> Matrix* classes, which came from Croquet, or whatever upstream source
> they pulled from)

Croquet was done by Andreas, who previously wrote all the Baloon 3d 
stuff (including "Balloon3D-Math" , that is the base of the Math 3D 
package I did )

> The Float64* class hierarchy in Math 3D appears to just be a parallel
> 64-bit hierarchy (with some slight naming convention differences) to the
> 32-bit Vector* and Matrix* classes from 3DTransform.  So what we'd
> probably want to do there is merge them (i.e. keeping both the 64-bit
> and 32-versions... when you need one or the other, you absolutely need
> it) into a single package and make sure they have identical
> functionality and consistent naming conventions (I have no preference on
> which conventions we use other than that they be consistent.  Makes no
> difference to me whether I'm using Vector2 or Float32Vector2 or whatever
> else would make sense)  If we did that, this would just leave the
> question of how the LinearAlgebra and Array2D classes fit into this (one
> thing I don't currently have but would like is an arbitrary MxN 32-bit
> float matrix class)...
>
> At first glance, the naming convention mapping appears to be:
>
> Float64Color4 ->  VectorColor
> Float64Matrix4x4 ->  Matrix4x4
> Float64Rotation ->  Quaternion
> Float64Vector2 ->  Vector2
> Float64Vector3 ->  Vector3
> Float64Vector4 ->  Vector4
>
> With the balances of the classes being unique to 3DTransform. (Just
> curious: for Float64Vector* why don't you use a common base class
> similar to Vector?)

This comes from "Balloon3D-Math".  I'm sure Andreas did it that way to 
be able to write very efficient slang code for the Ballon3D VM plugin.

WRT to naming conventions, we just need to agree on one. I have no 
preference.

>> There is a lot of overlap with yours, but you are using 32 bit Floats.
>>
> For now... at some point I'm sure I'll be needing 64-bit Floats as well.
> Since both the VM and OpenGL are limited to 32-bits, that's been doing
> the job for me. (my priority is currently performance over precision
> since for me it's just an errant pixel, for you it might be a house or
> your satellite heading for the ISS...)

That's totally ok. Just a remark: the VM is not limited to 32 bits. 
Floats are 64 bits and are handled by the VM. What is limited to 32 bits 
is FloatArrayPlugin. But it is entirely possible to add Float64 (a.k.a. 
double) primitives to it.

WRT the satellites... I'm not doing AOCS (Attitude and Orbital Control 
System), but the image processing pipeline. So, a numeric error would be 
like saying that a picture of L.A. is in Mexico, or such :)

>>> One advantage that the Matrix* and Vector* classes I'm using have is
>>> that they are mapped to native types which makes for transparent and
>>> easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
>>> compute shaders and you have the fastest matrix math you've ever seen,
>>> assuming you've got medium or larger sets of data)
>> Yes. This is indeed great. We need to build a single, uniform package
>> with this stuff, that handles both 32 and 64 bit Floats and can take
>> advantage of GPUs.
>>
>> BTW, have you used OpenCL from Cuis? I'll be needing to work with that
>> in a few months.
>>
> Not yet, but pretty much all of the same issues I've run into with
> OpenGL would apply for OpenCL (i.e. it's all FFI as far as the VM is
> concerned unless you're going to create a plugin, but even then you
> still have the same issues) so I think we should be able to get to a
> unified vector/matrix structure that works for both of us.  In both
> cases the key is to minimize the amount of work done to marshal native
> data in and out (slow/expensive conversions have a dramatic and
> detrimental cost for small data sets / short computations) while keeping
> the data as easy to work with as possible in both the Smalltalk and FFI
> (whether OpenGL/OpenCL/CUDA/Metal/Vulcan/etc.) environments.

Yes.

Something that I would like (and I don't know how to do it without 
Traits) is to share most of the source code between the 32 and 64 bits 
versions. We would need something like two parallel inheritance hierarchies:

GeneralFloatArray
--- FloatArray32
--- --- FloatVector32
--- --- FloatQuaternion32
--- FloatArray64
--- --- FloatVector64
--- --- FloatQuaternion64
for the inheritance of size specific code (#at: #at:put: primitives)

and something like
FloatVector
--- FloatQuaternion
--- --- FloatQuaternion32
--- --- FloatQuaternion64
to share quaternion specific code...

Any idea on this? If code sharing is not possible, at least some help to 
keep both consistent...

> Something to keep in the back of your mind: OMeta.  One of the many
> reasons I get so geeked out about it is that an OpenGL shader is just
> another language that can be targeted via source-to-source translation
> (i.e. dynamically generated GPU code written in something similar to
> Slang or another DSL from Cuis).  OpenCL shouldn't be terribly
> different...

Yes... Although as OpenCL is close to C, I was thinking on a variant of 
Slang... Especially after Bert did a translator Slang -> js

Cheers,
Juan Vuletich



From Ken.Dickey at whidbey.com  Fri Jul 17 09:21:52 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 17 Jul 2015 07:21:52 -0700
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55A905A3.1060100@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
Message-ID: <20150717072152.c4ed6c0e14a113c18966f2d8@whidbey.com>

On Fri, 17 Jul 2015 10:39:47 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> The problem, I think, is not identifying well defined Cuis releases. The
> problem is knowing how updates could affect your code.

This is a large search space.  It is easy for some minor change to have a cascaded interaction.

In thinking about this, I like to think of aerodynamic drag.  I want to be able to make rapid progress, so I like streamlined development processes.  I also want stability and robustness.

I think the inflection point where we go from laminar to turbulent air flow will change over time.

At this point in time, there are the fewest users and projects Cuis is likely to have.  I personally favor minimal drag and maximal progress at the expense of stability.  As stability becomes more important, added drag (heavier duty release process) is justified.

I once was talking with someone about garbage collection and they asked me how I could _prove_ that only "live" objects were left after each GC.  I told them it was a "proof by contradiction".

I.e. it's not a problem until it becomes a problem.

I did software development for a living for a couple of decades.  For me (a vote of 1) Release process is not yet a problem.  But, hey, I'm an old hacker guy.

What does everyone else think?

-- 
-KenD

PS: the random progress graphic is totally unrelated to this discussion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PropEdit-Screenshot.png
Type: image/png
Size: 324850 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150717/563d523a/attachment-0003.png>

From dnorton at mindspring.com  Fri Jul 17 09:57:34 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 17 Jul 2015 10:57:34 -0400
Subject: [Cuis] Block Arguments
In-Reply-To: <1437099105.2255.92.camel@gmail.com>
References: <55A85DBA.15429.29625A6@dnorton.mindspring.com>,
	<1437099105.2255.92.camel@gmail.com>
Message-ID: <55A917DE.23607.2C3F41@dnorton.mindspring.com>

On 16 Jul 2015 at 22:11, Phil (list) wrote:

> On Thu, 2015-07-16 at 21:43 -0400, Dan Norton wrote:
> > Hi Juan,
> > 
> > 
> > On windows, when the attached class method is added to StrikeFont
> and
> > cmd-d is done on the comment, it produces:
> > 
> > 
> > 'Error: This block accepts 0 arguments, but was called with 1
> > argument.'
> > 
> > 
> > AFAIKT it is not passing any arguments and the files do exist.
> Maybe a
> > bug?
> > 
> But it is passing an argument to your ifExistsDo: block (the
> filestream)
> and your block doesn't accept any.  If you don't care about the
> filestream, change your blocks to [:filestream| {baseName. ' OK'}
> print]
> etc. and ignore the parameter.
>

Ahh, now I see it. Interesting. Thanks, Phil.

 - Dan



From dnorton at mindspring.com  Fri Jul 17 10:03:27 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 17 Jul 2015 11:03:27 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150717072152.c4ed6c0e14a113c18966f2d8@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>,
	<20150717072152.c4ed6c0e14a113c18966f2d8@whidbey.com>
Message-ID: <55A9193F.13540.31A0C2@dnorton.mindspring.com>

On 17 Jul 2015 at 7:21, Ken.Dickey wrote:

> On Fri, 17 Jul 2015 10:39:47 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
> 
> > The problem, I think, is not identifying well defined Cuis
> releases. The
> > problem is knowing how updates could affect your code.
> 
> This is a large search space.  It is easy for some minor change to
> have a cascaded interaction.
> 
> In thinking about this, I like to think of aerodynamic drag.  I want
> to be able to make rapid progress, so I like streamlined development
> processes.  I also want stability and robustness.
> 
> I think the inflection point where we go from laminar to turbulent
> air flow will change over time.
> 
> At this point in time, there are the fewest users and projects Cuis
> is likely to have.  I personally favor minimal drag and maximal
> progress at the expense of stability.  As stability becomes more
> important, added drag (heavier duty release process) is justified.
> 
> I once was talking with someone about garbage collection and they
> asked me how I could _prove_ that only "live" objects were left
> after each GC.  I told them it was a "proof by contradiction".
> 
> I.e. it's not a problem until it becomes a problem.
> 
> I did software development for a living for a couple of decades. 
> For me (a vote of 1) Release process is not yet a problem.  But,
> hey, I'm an old hacker guy.
>

+1

 - Dan
 
> What does everyone else think?
> 
> -- 
> -KenD
> 
> PS: the random progress graphic is totally unrelated to this
> discussion.
> 





From pbpublist at gmail.com  Fri Jul 17 10:18:54 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 17 Jul 2015 11:18:54 -0400
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A90E19.3060005@jvuletich.org>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
	<1437007797.2401.12.camel@gmail.com> <55A7B057.4050803@jvuletich.org>
	<1437077628.2255.77.camel@gmail.com> <55A90E19.3060005@jvuletich.org>
Message-ID: <1437146334.2255.134.camel@gmail.com>

Juan,

On Fri, 2015-07-17 at 11:15 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 7/16/2015 5:13 PM, Phil (list) wrote:
> > Juan,
> >
> > On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
> >> Hi Phil,
> >>
> >> On 7/15/2015 9:49 PM, Phil (list) wrote:
> >>> Glad that solved your problem but, ouch... that class is uncomfortably
> >>> close in name and function to the 3DTransform package I'm using for
> >>> OpenGL.  Juan: would you be open to using an extended version of my
> >>> classes so that we don't run into namespace conflicts?
> >> Indeed we need to do something with this. Check the "Math 3D" package.
> >> It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need
> >> double precision for satellite image processing at work.
> >>
> > You space guys with your astronomically large numbers and being sooooo
> > concerned with precisely where things are.  Why can't you accept
> > 'there-ish' like the rest of us? :-)
> 
> :) I would... But if you want Google Earth level of precision, you do 
> need them...
> 

Just aim for Apple Maps level of precision and call it good enough :-)

> > (disclaimer: the events depicted in Gravity should in no way cast
> > aspersions as to the inadequacies of 32-bit floats...)
> >
> > Ahh... hadn't noticed the Math 3D stuff before.  For OpenGL, I've been
> > using a combination of the Collections-Arrayed, Collections-Balloon and
> > 3DTransform (i.e. the 3DTransform package which provides the Vector* and
> > Matrix* classes, which came from Croquet, or whatever upstream source
> > they pulled from)
> 
> Croquet was done by Andreas, who previously wrote all the Baloon 3d 
> stuff (including "Balloon3D-Math" , that is the base of the Math 3D 
> package I did )

Ah, I knew Andreas did most of the graphics stuff in Croquet but wasn't
sure about the math code (just spot-checking, I see 'das' listed as the
person who last touched most of the code back in 2005 with some by
Andreas both before and after)

> 
> > The Float64* class hierarchy in Math 3D appears to just be a parallel
> > 64-bit hierarchy (with some slight naming convention differences) to the
> > 32-bit Vector* and Matrix* classes from 3DTransform.  So what we'd
> > probably want to do there is merge them (i.e. keeping both the 64-bit
> > and 32-versions... when you need one or the other, you absolutely need
> > it) into a single package and make sure they have identical
> > functionality and consistent naming conventions (I have no preference on
> > which conventions we use other than that they be consistent.  Makes no
> > difference to me whether I'm using Vector2 or Float32Vector2 or whatever
> > else would make sense)  If we did that, this would just leave the
> > question of how the LinearAlgebra and Array2D classes fit into this (one
> > thing I don't currently have but would like is an arbitrary MxN 32-bit
> > float matrix class)...
> >
> > At first glance, the naming convention mapping appears to be:
> >
> > Float64Color4 ->  VectorColor
> > Float64Matrix4x4 ->  Matrix4x4
> > Float64Rotation ->  Quaternion
> > Float64Vector2 ->  Vector2
> > Float64Vector3 ->  Vector3
> > Float64Vector4 ->  Vector4
> >
> > With the balances of the classes being unique to 3DTransform. (Just
> > curious: for Float64Vector* why don't you use a common base class
> > similar to Vector?)
> 
> This comes from "Balloon3D-Math".  I'm sure Andreas did it that way to 
> be able to write very efficient slang code for the Ballon3D VM plugin.
> 
> WRT to naming conventions, we just need to agree on one. I have no 
> preference.
> 

I'm OK with changing my stuff to use Float32*.  Since both hierarchies
are dependent on their underlying native types, that would probably be
the most straightforward approach.  Would it make sense to you to use
FloatXXQuaternion? (Rotation seems a bit vague to me since, while
unlikely, there could potentially be other rotation solutions
implemented)

> >> There is a lot of overlap with yours, but you are using 32 bit Floats.
> >>
> > For now... at some point I'm sure I'll be needing 64-bit Floats as well.
> > Since both the VM and OpenGL are limited to 32-bits, that's been doing
> > the job for me. (my priority is currently performance over precision
> > since for me it's just an errant pixel, for you it might be a house or
> > your satellite heading for the ISS...)
> 
> That's totally ok. Just a remark: the VM is not limited to 32 bits. 
> Floats are 64 bits and are handled by the VM. What is limited to 32 bits 
> is FloatArrayPlugin. But it is entirely possible to add Float64 (a.k.a. 
> double) primitives to it.
> 

That's good to know.  I've been meaning to dig back into the VM source
as there are still some questions I have about how FFI is doing some of
what it is doing.  Just lack of time on my part vs other priorities...

> WRT the satellites... I'm not doing AOCS (Attitude and Orbital Control 
> System), but the image processing pipeline. So, a numeric error would be 
> like saying that a picture of L.A. is in Mexico, or such :)
> 

Awww... you've destroyed my Dr. Evil mental image of you at work ;-)

> >>> One advantage that the Matrix* and Vector* classes I'm using have is
> >>> that they are mapped to native types which makes for transparent and
> >>> easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
> >>> compute shaders and you have the fastest matrix math you've ever seen,
> >>> assuming you've got medium or larger sets of data)
> >> Yes. This is indeed great. We need to build a single, uniform package
> >> with this stuff, that handles both 32 and 64 bit Floats and can take
> >> advantage of GPUs.
> >>
> >> BTW, have you used OpenCL from Cuis? I'll be needing to work with that
> >> in a few months.
> >>
> > Not yet, but pretty much all of the same issues I've run into with
> > OpenGL would apply for OpenCL (i.e. it's all FFI as far as the VM is
> > concerned unless you're going to create a plugin, but even then you
> > still have the same issues) so I think we should be able to get to a
> > unified vector/matrix structure that works for both of us.  In both
> > cases the key is to minimize the amount of work done to marshal native
> > data in and out (slow/expensive conversions have a dramatic and
> > detrimental cost for small data sets / short computations) while keeping
> > the data as easy to work with as possible in both the Smalltalk and FFI
> > (whether OpenGL/OpenCL/CUDA/Metal/Vulcan/etc.) environments.
> 
> Yes.
> 
> Something that I would like (and I don't know how to do it without 
> Traits) is to share most of the source code between the 32 and 64 bits 
> versions. We would need something like two parallel inheritance hierarchies:
> 
> GeneralFloatArray
> --- FloatArray32
> --- --- FloatVector32
> --- --- FloatQuaternion32
> --- FloatArray64
> --- --- FloatVector64
> --- --- FloatQuaternion64
> for the inheritance of size specific code (#at: #at:put: primitives)
> 
> and something like
> FloatVector
> --- FloatQuaternion
> --- --- FloatQuaternion32
> --- --- FloatQuaternion64
> to share quaternion specific code...
> 
> Any idea on this? If code sharing is not possible, at least some help to 
> keep both consistent...
> 

That would be the ideal.  But like you, I can only think of ways that
are a bit messy:

1) Traits (dependency complexity)
2) OMeta (using it as a templating system to emit both variants,
dependency complexity)
3) Using class composition rather than inheritance (adds a bit of
complexity as you would need to call something like myMatrix #contents
to actually get at the data to pass to FFI)

Probably the simplest solution short term is just keep a parallel class
hierarchy in the same package and ensure that they stay in sync using
test cases.

> > Something to keep in the back of your mind: OMeta.  One of the many
> > reasons I get so geeked out about it is that an OpenGL shader is just
> > another language that can be targeted via source-to-source translation
> > (i.e. dynamically generated GPU code written in something similar to
> > Slang or another DSL from Cuis).  OpenCL shouldn't be terribly
> > different...
> 
> Yes... Although as OpenCL is close to C, I was thinking on a variant of 
> Slang... Especially after Bert did a translator Slang -> js
> 

However you go about it, just keep language abstraction in mind.  Just
as OpenGL continues to go through backwards-incompatible changes to
'fix' its abstraction layer issues, I suspect we're entering a similar
phase with OpenCL and CUDA.  We will likely end up with something
different such as Vulcan or Metal as the GPU compute standard a few
years from now.  Hopefully it won't take them as many iterations as it
has with OpenGL... (wishful thinking on my part, I fear)

> Cheers,
> Juan Vuletich

Thanks,
Phil




From edgardec2005 at gmail.com  Fri Jul 17 12:36:25 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Fri, 17 Jul 2015 14:36:25 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
Message-ID: <E772B770227A414C8E4912293F62ED5A@gmail.com>

Casey , you begin all this a long time ago.
Hope you could be healthy and join to the quest soon.


Now i away of my dungeons, but this week end I take a torch and try to found the relevant info.
To my short memory , no code or significant progress.
Not knowing if Apple could be persuaded HyperCard go open source or give technical info what could be useful to any wishing bring HyperCard to life again..

But glad Juan , Hannes show interest.

Edgar 

-- 
Edgar De Cleene
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Thursday, July 16, 2015 at 10:00 AM, H. Hirzel wrote:

> I think there was something like that. Need to search in the Squeak
> list. And check the porting effort. Might be doable with Cuis these
> days.
> 
> --Hannes
> 
> On 7/16/15, Juan Vuletich <juan at jvuletich.org (mailto:juan at jvuletich.org)> wrote:
> > Hi Edgar,
> > 
> > Is there such a project? Any reference?
> > 
> > Thanks,
> > Juan Vuletich
> > 
> > On 7/11/2015 5:24 PM, Edgar J De Cleene wrote:
> > > Quoting Casey
> > > 
> > > > If we can throw in some HyperCard and...
> > > 
> > > A long time algo wish Squeak could read HyperCard stacks.
> > > If Cuis could do this , bet we have thousands users.
> > > Anyway whats the HyperCard status ?
> > > 
> > 
> > 
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org (mailto: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/20150717/0f16a00a/attachment-0003.html>

From pbpublist at gmail.com  Fri Jul 17 13:45:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 17 Jul 2015 14:45:01 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55A905A3.1060100@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
Message-ID: <1437158701.2255.245.camel@gmail.com>

On Fri, 2015-07-17 at 10:39 -0300, Juan Vuletich wrote:
> Additional stuff about versioning, and how to keep your code working
> as Cuis changes.
> 
> Please share your ideas and thoughts about this.
> 
> We all want to ease development and maintenance of all sorts of
> projects while allowing a moderate rate of change to Cuis itself...
> 
> Cheers,
> Juan Vuletich
> 
> -------- Original Message -------- 
>                              From: 
> - Thu Jul 16 10:47:08 2015
>                  X-Mozilla-Status: 
> 0001
>                 X-Mozilla-Status2: 
> 00800000
>                    X-Mozilla-Keys: 
> 
> 
>                        Message-ID: 
> <55A7B5DA.1020103 at jvuletich.org>
>                              Date: 
> Thu, 16 Jul 2015 10:47:06 -0300
>                              From: 
> Juan Vuletich <juan at jvuletich.org>
>                        User-Agent: 
> Mozilla/5.0 (Windows; U; Windows NT
> 6.1; en-US; rv:1.9.2.28)
> Gecko/20120306 Thunderbird/3.1.20
>                      MIME-Version: 
> 1.0
>                                To: 
> H. Hirzel <hannes.hirzel at gmail.com>
>                           Subject: 
> Re: DIRECT version number
>                        References: 
> <CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA at mail.gmail.com> <55A7A607.7050304 at jvuletich.org> <CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
>                       In-Reply-To: 
> <CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
>                      Content-Type: 
> text/plain; charset=UTF-8;
> format=flowed
>         Content-Transfer-Encoding: 
> 7bit
> 
> 
> Hi Hannes,
> 
> On 7/16/2015 9:57 AM, H. Hirzel wrote:
> > Thank you Juan, for answering.
> >
> > At the moment I feel uncomfortable using Cuis because it is currently
> > a quite fast moving target. I perceive quite a number of API changes
> > though this might be wrong. But I do not know because there are no
> > release notes which summarize it.
> 

I totally feel Hannes' pain having gone through it a few times myself
over the years.  At the same time, I agree with Ken's point about not
getting too bogged down in process since we're in the best position
right now to break things for the better longer term.

> Yes, that's true. Besides, we don't have a specification of what is an 
> API and what is not. So, almost any change can be considered an API change.
> 

That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
issue, not specific to Cuis)  I believe it is largely fixable without
tons of documentation and tests: the use of private (categories or
method naming convention).  Bernhard pointed out an existing capability
a few months ago
http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
While I personally like the idea of private categories, one of these
approaches should really be seriously considered.

Other than a few specific examples (i.e. mostly the base data types
including the Collection and Number class hierarchies which are pretty
mature and don't change all that much anyway) I would guesstimate that
<20% (probably closer to 10%) of the methods, and and unknown % of
classes (a significantly larger fraction though), should even be
considered public.  If things were indicated as private that would
accomplish two things:

1) We could construct some simple tooling (some combination of up-front
warnings in the editor and/or a lint-type tester after the fact) that
would allow people to identify problematic calls within their code.
(i.e. just because it works now doesn't mean it always will if you keep
calling X, Y, Z...)

2) It would provide a way for people to know if something needs to be
discussed.  i.e. 'In class X method Y is private but I need that type of
functionality' so you would know that there's a need and could consider
either making it public, and therefore supported, or rethinking its
implementation if you'd like to offer a better public API solution.

> I don't want you to feel uncomfortable. Let's work this out.
> 
> >   And I do not now in which state my stuff and the general Cuis stuff ist.
> >
> > I need a new 'base line', i.e. a release number to which I can refer
> > to when upgrading my code.
> 
> Well, but we do have that. It is the update number. It is part of any 
> Cuis image I've ever committed to the repo.
> 
> The problem, I think, is not identifying well defined Cuis releases. The 
> problem is knowing how updates could affect your code.
> 

By narrowing the scope of what the public API is using private
designators, this dramatically reduces what you need to be concerned
with on this front.  It's part of the reason that Apple, Google, and
even Microsoft are so adamant about public APIs these days.  They dealt
with the pain of even major developers depending on private APIs for
decades. It's only been in the last 10 years or so that they've been
able to dig themselves out from under this issue.

This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
attitude of 'you have the source, play around, have fun!' has morphed
into 'everything is a public API!  there are no rules! isn't this
great?'  Well no, it's not great.  It makes life impossible for image
maintainers (Squeak has been in a coma for the last decade or so as the
result of trying to keep everyone happy... yet no one seems to be) and
miserable for those who are trying to keep code running on it (stuff
still breaks all the time.)

I personally believe the minimalism and simplicity that Cuis is based on
has the best long term prospects but we have to get out of this
'everything is public' mindset.  Sure, we have all the source: look at
it, learn from it, poke around, refactor it, submit fixes, etc.  But
there needs to be a manageable subset of it which is considered the
'public API' that people can depend on to write frameworks and apps on
top of that is relatively stable longer term.  Let's start defining what
that is and backfill changes to the public API (which will happen from
time to time as we don't want things to be completely static) with tests
and documentation so you can focus your efforts on where they matter
most and you get the most enjoyment from.

> > Of course the other option  is to just follow the most recent update
> > all the time. That would  call for some kind of continuous integration
> > testing 'Cuis style' which I not have either.
> >
> > E.g. if you could do a writeup how you do test Cuis before each new
> > commit (there are over 50 this year) and which scripts you use I could
> > apply the same thing for my packages.
> >
> > It has to be something which can be done quickly. Semi-Automatic is
> > fine. A check list with
> >
> > - do this
> > - then execute that script
> > - Open .. this and that
> > - And finally run a report on  ...
> >
> > would be fine.
> 
> I don't have that either. I run the tests from time to time (I'll start 
> doing it before any commit, and add the xml report to the rep). But this 
> is not the most important reason why Cuis is solid. Cuis is very 
> reliable because:

reliable != stable

> - I'm not too bad as a coder.
> - I do my own code revisions at least one day after each change.
> - I use Cuis every day, and spot most problems in the updates, before 
> commtting them to the repo.
> - I really, really care about code quality.
> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that 
> is a big responsibility, given how important I think Smalltalk-80 is.
> 

Agree to all this and more.  Cuis would not be where it is without your
continued effort and diligence. (i.e. setting aside that you obviously
created it, if you had just tossed it out into the world and let it go
at best it would have started looking something like Squeak or Pharo by
now.  It's a lot of effort over the long term to *keep* it small and
focused.  THANK YOU JUAN!)

> So, I suggest running your tests when updating your image, or migrating 
> your code to an updated image.
> 

+1 to tests as they do help quite a bit and are a very good practice.
Just be judicious in what/where you test (I personally don't subscribe
to the TDD approach where you spend your days mostly writing tests.
That's just admitting defeat in that you spend all day writing
executable documentation.)

> In any case, I think this doesn't answer your concerns. What you need is 
> some way to know which updates could affect you, to review them in 
> detail, and understanding their effect on your code. A list of the 
> affected classes and/or methods for each update makes no sense. Cuis can 
> already show you that very easily. Perhaps each update should include:
> 
> 1) parts of the system that are affected:
> - Kernel
> - Compiler
> - Tools
> - Morphic
> - etc
> 
> 2) Level of risk involved
> - very unlikely to break code that depends on this part of the system
> - could perhaps break code that depends on this part of the system
> - will most likely break code that depends on this part of the system
> 
> Or something like that.
> 
> BTW, this is a very relevant topic for discussing on the mail list. Feel 
> free to answer there if you agree.
> 

One final thought on this:  I suspect a major cause of people abandoning
Cuis (and Smalltalk in general), behind the 'it's too different from
what I'm used to'/'not mainstream' reaction, is the instability of its
APIs.

> Cheers,
> Juan Vuletich
> 
> 
> > However doing a release tag in github is really not a big deal if you
> > actually take the plunge.
> >
> > You are not alone in not using this option.
> >
> > It took me two years to realize that I can learn to do it and actually
> > do a release in 5 minutes.....
> >
> > So I suggest do a release just continuing where you left off last time.
> >
> > Then people will start to realise there is something to test against.
> > And new update requests will come and you can do another one.
> >
> > So the release which I am asking for is not a big deal. Just a tag on a commit.
> >
> > I'd like to explore the direct authoring tools offered by Ken Dickey.
> >
> > With the aim of producing a very simple Hypercard / Powerpoint like
> > authoring environment.
> >
> > And do more with OMeta.
> >
> > Happy continued Cuis curating .....
> > And thank you very much indeed for your great work maintaining this environment.
> >
> >
> > Hannes
> >
> >
> >
> > On 7/16/15, Juan Vuletich<juan at jvuletich.org>  wrote:
> >> On 7/12/2015 6:27 PM, H. Hirzel wrote:
> >>> Hi Juan
> >>>
> >>> Regarding a Cuis version number. I suggest that you just continue with
> >>> a new version number where you left off last time.
> >>>
> >>> It is just about having a version number to have a new baseline to
> >>> refer to. This is helpful for testing and documentation.
> >>>
> >>> I do not think it is a big issue.
> >>>
> >>> API changes require a new version number.
> >>>
> >>> Kind regards
> >>> Hannes
> >> Hi Hannes,
> >>
> >> Sometimes I don't pay enough attention to stuff like this, so feel free
> >> to request action from me when you feel appropriate :)
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From Ken.Dickey at whidbey.com  Fri Jul 17 14:11:02 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 17 Jul 2015 12:11:02 -0700
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <E772B770227A414C8E4912293F62ED5A@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
Message-ID: <20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>

HyperCard Factoids

- The reason that HyperCard failed to support color for many years was that the project leader was color blind and could not see using all those extra bits just to support color. [Someone at Apple told me this, I forget who.]

- The original Myst was developed & deployed using HyperCard. [I found this out from Robyn and Rand Miller when they visited Apple.]

FYI,
-KenD



From 0800nacho at gmail.com  Fri Jul 17 14:37:36 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Fri, 17 Jul 2015 16:37:36 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
	<20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
Message-ID: <CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>

This is a good resource for HyperCard and HyperTalk

http://hypercard.org

cheers
Nacho


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

*Tel: (011) 4542-6714*


















On Fri, Jul 17, 2015 at 4:11 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

> HyperCard Factoids
>
> - The reason that HyperCard failed to support color for many years was
> that the project leader was color blind and could not see using all those
> extra bits just to support color. [Someone at Apple told me this, I forget
> who.]
>
> - The original Myst was developed & deployed using HyperCard. [I found
> this out from Robyn and Rand Miller when they visited Apple.]
>
> FYI,
> -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/20150717/190ea4f7/attachment-0003.html>

From hannes.hirzel at gmail.com  Fri Jul 17 17:21:50 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Fri, 17 Jul 2015 22:21:50 +0000
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
	<20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
	<CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
Message-ID: <CAGQxfVh_0LZv+AzQMep1urFYpP36qqdeKmcG01x_-wQyUj3gFg@mail.gmail.com>

At the moment my interest is in creating a very small subset of Hypercard

Pictures on cards with a caption and buttons. Plus cards with bullet lists.

I postpone the direct manipulation aspect currently. I describe what
is on the cards with Smalltalk (you may call it a "DSL" for describing
stacks). And I have a reader for MarkDown and other similar types of
input.

These very days I focus on generating export formats (Just a sequence
of JPEGs to put on a tablet as is, LibreOffice Writer, LibreOffice
Impress, Large JPEG with many cards to create a poster, Microsoft
Word, Powerpoint, Markdown e.g. https://www.swipe.to/).  I work on
Pharo 4 at the moment and I aim at easy porting to Cuis.

More interaction will come later (drag and drop activities).


For a fairly recent Hypercard in Smalltalk / Squeak discussions see
the Squeak mailing list

Feb 24, 2013 at 10:54 AM
About HyperCard

A thread started by Edgar. I downloaded the sample image and could run
a stack like the Hypercard help stack in Squeak (screen shot
attached).


Below an extract of that thread.

-- Hannes


Feb 24, 2013 at 10:54 AM
About HyperCard

http://www.vpri.org/pdf/m2011001_dbjr_spec.pdf

DynaBook Junior Specification
by Ted Kaehler
14 Jan 2009. (Minor corrections 13 Dec 2010)
A specification for DynaBook Junior
shown in itself.
DBJr is a desktop publishing framework and
application builder that is modeled after Apple's HyperCard.

Abstract
DynaBook Junior is a desktop publishing
framework and application builder that is
modeled after Apple's HyperCard(tm). The
purpose of this specification is as a starting
point for the discovery of an extremely simple
way to describe and automatically generate
DynaBook Junior. The specification describes
stacks, pages, backgrounds, objects
embedded in pages, the front-to-back ordering
of objects, and page-specific objects. This
document is itself a DBJr stack that shows
examples of the features it describes.
Algorithms for showing a new page, adding
pages, adding backgrounds, and adding
objects to a page are given in pseudocode.


http://tinlizzie.org/lesserphic2/

download the example stack
http://tinlizzie.org/lesserphic2/aboutDBJr%205-Aug.morph
in addition, locate it with the file browser and then choose 'load as morph'

....
While the DynaBookJr (I always misread "DBJr" as "DataBase Jr") is
indeed a good modern replacement for HyperCard, isn't the normal
BookMorph already available in Squeak a reasonable approximation?

...
The Lesserphic version of DBJr is considered to be obsolete.  It uses
the "Etoys-style" uniclasses for pages but we later figured out a
simpler way of implementing it.
...


http://www.vpri.org/pdf/m2013003_ksapps.pdf


... research report 'Making
applications in KSWorld' and the equally interesting report of October
2012 'A Report on KScript and KSWorld'
http://www.vpri.org/html/writings.php

Chapter 6 of the the October report talks about  the hosting
environment which happens to be Squeak

<citation>
Hosting Environment: Squeak
As of this writing, the KSWorld is hosted on top of Squeak Smalltalk [10]. A
special Morphic widget called KSMorph is created under RectangleMorph.
</citation>


....

In the new document, Section
7.1 discusses the "Document Model" and Section 8.9 says it took about
200 lines to implement.




On 7/17/15, Ignacio Sniechowski <0800nacho at gmail.com> wrote:
> This is a good resource for HyperCard and HyperTalk
>
> http://hypercard.org
>
> cheers
> Nacho
>
>
> *Lic. Ignacio Sniechowski, MBA*
> *Prosavic SRL*
>
> *Tel: (011) 4542-6714*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jul 17, 2015 at 4:11 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
>
>> HyperCard Factoids
>>
>> - The reason that HyperCard failed to support color for many years was
>> that the project leader was color blind and could not see using all those
>> extra bits just to support color. [Someone at Apple told me this, I
>> forget
>> who.]
>>
>> - The original Myst was developed & deployed using HyperCard. [I found
>> this out from Robyn and Rand Miller when they visited Apple.]
>>
>> FYI,
>> -KenD
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StackInDynaBookJunior.gif
Type: image/gif
Size: 55598 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150717/e0b2194d/attachment-0003.gif>

From edgardec2005 at gmail.com  Sat Jul 18 05:55:16 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Sat, 18 Jul 2015 07:55:16 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
	<20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
	<CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
Message-ID: <40788499-8CB3-4134-97A2-FE1EFA13598F@gmail.com>


> On Jul 17, 2015, at 4:37 PM, Ignacio Sniechowski <0800nacho at gmail.com> wrote:
> 
> This is a good resource for HyperCard and HyperTalk
> 
> http://hypercard.org <http://hypercard.org/>

Ignacio beats me.

But I download Stacksmith and CinsImp
Seems https://github.com/uliwitness/Stacksmith <https://github.com/uliwitness/Stacksmith> and http://hammer-language.com/ <http://hammer-language.com/> should be the docs to read.

Excited !!!

Edgar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150718/2cf88a47/attachment-0003.html>

From dnorton at mindspring.com  Sat Jul 18 13:33:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 14:33:35 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <20150710165144.ece0f54787132fed1278bdc4@whidbey.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A0178E.16257.13666A4@dnorton.mindspring.com>,
	<20150710165144.ece0f54787132fed1278bdc4@whidbey.com>
Message-ID: <55AA9BFF.3085.11B851C@dnorton.mindspring.com>

On 10 Jul 2015 at 16:51, Ken.Dickey wrote:

> On Fri, 10 Jul 2015 15:05:50 -0400
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> > Yes, the only font now is DejaVu and it's a bitmap font. I found
> some fixed bitmap fonts 
> > among the true types at:
> > 
> > http://www.lowing.org/fonts/
> > 
> > Adding a sublcass to AbstractFont to load one of these might be
> doable near-term until 
> > Morphic 3 comes along. Porting TrueType from Squeak has a lot of
> drag.
> 
> My Cuis-Smalltalk-Unicode package subclasses AbstractFont and
> provides fixed width characters.
> 
> See class #UniForms 
> 
> Unicode is kinda big, memory wise.  I suspect one should be able to
> take the ASCII subset of the Unicode glyphs and make a strike font
> -- or just do what I did for Unicode, but just use the ASCII
> subset.
> 
> FYI,
> -KenD

That is awesome, Ken.

 - Dan



From dnorton at mindspring.com  Sat Jul 18 13:37:16 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 14:37:16 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A146FC.4020402@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A146FC.4020402@jvuletich.org>
Message-ID: <55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>

On 11 Jul 2015 at 13:40, Juan Vuletich wrote:

> Hi Folks,
> 
> It is not too hard to build new StrikeFonts. You need to build, by
> hand, 
> files like the ones in here: 
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> p 
> and learn a bit about stuff like #installDejaVu2 . Maybe it was with
> this method and the files in this zip that built the existing
> instances 
> of StrikeFont. Not sure.
> 

That's intrigueing but I can't reproduce it. Maybe the .bmp but where did you get the .txt?

 - Dan



From dnorton at mindspring.com  Sat Jul 18 13:56:46 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 14:56:46 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A14859.2080409@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A0178E.16257.13666A4@dnorton.mindspring.com>,
	<55A14859.2080409@jvuletich.org>
Message-ID: <55AAA16E.24887.130BE16@dnorton.mindspring.com>

On 11 Jul 2015 at 13:46, Juan Vuletich wrote:

> On 7/10/2015 4:05 PM, Dan Norton wrote:
> > ...
> > Yes, the only font now is DejaVu and it's a bitmap font. I found
> some fixed bitmap fonts
> > among the true types at:
> >
> > http://www.lowing.org/fonts/
> >
> > Adding a sublcass to AbstractFont to load one of these might be
> doable near-term until
> > Morphic 3 comes along. Porting TrueType from Squeak has a lot of
> drag.
> >
> 
> ProFontWindows doesn't look bad. In any case, I built the Bitmap
> DejaVu 
> fonts in Cuis (and Squeak and Pharo) by capturing the bits from the
> screen of a text editor, running the TTF. You can do the same with
> DejaVu Sans Mono or any other TTF / OTF / whatever.
>

Currently I am porting TrueType. By way of a progress report, drag has been reduced and by 
installing

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

and cmd-d "tt := TTFontReader parseFileNamed:'c:\windows\fonts\cour.ttf'" you have a true 
type instance "tt" which, when explored, bears a strong resemblance to the same thing if 
done on Squeak, according to my eyeballs.

Now to transform(?) convert(?) this font to something which can be added to AvailableFonts 
and used. WIBGI it could be used as is? There are several fixed-width fonts in the .ttf set.

 - Dan



From hannes.hirzel at gmail.com  Sat Jul 18 13:58:53 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 18 Jul 2015 18:58:53 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A1475D.3030501@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<55A1475D.3030501@jvuletich.org>
Message-ID: <CAGQxfVjJsjkj1BRj_KoKHH4AZsdSDfMFWZ764-L=5rBPqB1k0Q@mail.gmail.com>

On 7/11/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/10/2015 11:20 AM, Dan Norton wrote:
>> ...
>> Browsing through strike fonts, I see no fixed widths. But, true type fonts
>> have a few
>> fixed-width examples. There seems to be no way to install a .ttf in Cuis
>> currently.
>>
>> Can we port TrueType-Support from Squeak?
>>
>> Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits
>> from AbstractFont?
>>
>> Any hints or guidance would be most welcomed.
>>
>
> I'd say, stick to StrikeFonts, and learn to build new ones. I the other
> message I just sent, I included more details.

+1

or copy a strikefont from Squeak. The Squeak wiki has a lot of
material about Strikefont.



> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Sat Jul 18 14:04:18 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 12:04:18 -0700 (PDT)
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AAA16E.24887.130BE16@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
	<55A14859.2080409@jvuletich.org>
	<55AAA16E.24887.130BE16@dnorton.mindspring.com>
Message-ID: <1437246258310-4838103.post@n4.nabble.com>

Correction:

Currently I am porting TrueType. By way of a progress report, drag has been
reduced and by 
installing /the TrueType package from:/

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

etc.



--
View this message in context: http://forum.world.st/Fixed-Width-Font-tp4836695p4838103.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From hannes.hirzel at gmail.com  Sat Jul 18 14:10:52 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 18 Jul 2015 19:10:52 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <1437246258310-4838103.post@n4.nabble.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
	<55A14859.2080409@jvuletich.org>
	<55AAA16E.24887.130BE16@dnorton.mindspring.com>
	<1437246258310-4838103.post@n4.nabble.com>
Message-ID: <CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>

https://github.com/dhnorton/Cuis-Smalltalk-fonts/blob/master/Graphics-Text.pck.st#L2

says

    "Description A stripped-down package with changes only to
AbstractFont and StrikeFont."

I assume the code is from the current Squeak 4.6?

--HH

On 7/18/15, Dan Norton <dnorton at mindspring.com> wrote:
> Correction:
>
> Currently I am porting TrueType. By way of a progress report, drag has been
> reduced and by
> installing /the TrueType package from:/
>
> https://github.com/dhnorton/Cuis-Smalltalk-fonts
>
> etc.
>
>
>
> --
> View this message in context:
> http://forum.world.st/Fixed-Width-Font-tp4836695p4838103.html
> Sent from the Cuis Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Sat Jul 18 14:27:25 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 15:27:25 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<1437246258310-4838103.post@n4.nabble.com>,
	<CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
Message-ID: <55AAA89D.29698.14CCC69@dnorton.mindspring.com>

On 18 Jul 2015 at 19:10, H. Hirzel wrote:

> https://github.com/dhnorton/Cuis-Smalltalk-fonts/blob/master/Graphic
> s-Text.pck.st#L2
> 
> says
> 
>     "Description A stripped-down package with changes only to
> AbstractFont and StrikeFont."
> 
> I assume the code is from the current Squeak 4.6?
> 
> --HH
> 

No, Squeak 4.5.

 - Dan



From dnorton at mindspring.com  Sat Jul 18 14:41:19 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 15:41:19 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<1437246258310-4838103.post@n4.nabble.com>,
	<CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
Message-ID: <55AAABDF.5892.15986B3@dnorton.mindspring.com>

On 18 Jul 2015 at 19:10, H. Hirzel wrote:

> https://github.com/dhnorton/Cuis-Smalltalk-fonts/blob/master/Graphic
> s-Text.pck.st#L2
> 
> says
> 
>     "Description A stripped-down package with changes only to
> AbstractFont and StrikeFont."
> 
> I assume the code is from the current Squeak 4.6?
> 
> --HH
> 

Actually, the code is from Cuis, now that I take a closer look.

 - Dan



From Ken.Dickey at whidbey.com  Sat Jul 18 23:33:48 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sat, 18 Jul 2015 21:33:48 -0700
Subject: [Cuis] #printStringLimitedTo:
Message-ID: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>

I find it kind of odd that #printStringLimitedTo: takes the prefix of a too-long string and adds '...etc...', which itself is 9 characters.

I think a shorter addition would make more sense.  After all, the string is already too long, right?

I like '[..]' , which is only four characters. 

Would anyone else like to weigh in on this?  Other options?

-KenD



From pbpublist at gmail.com  Sun Jul 19 01:04:59 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 02:04:59 -0400
Subject: [Cuis] #printStringLimitedTo:
In-Reply-To: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>
References: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>
Message-ID: <1437285899.6934.1.camel@gmail.com>

On Sat, 2015-07-18 at 21:33 -0700, Ken.Dickey wrote:
> I find it kind of odd that #printStringLimitedTo: takes the prefix of a too-long string and adds '...etc...', which itself is 9 characters.
> 
> I think a shorter addition would make more sense.  After all, the string is already too long, right?
> 
> I like '[..]' , which is only four characters. 
> 
> Would anyone else like to weigh in on this?  Other options?

I agree that the current suffix is long-ish and like your [..] idea as
that's unlikely to appear in the majority of strings but would still
convey the information.

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





From juan at jvuletich.org  Sun Jul 19 08:31:14 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 19 Jul 2015 10:31:14 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A146FC.4020402@jvuletich.org>
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
Message-ID: <55ABA6A2.5090607@jvuletich.org>

On 7/18/2015 3:37 PM, Dan Norton wrote:
> On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>
>> Hi Folks,
>>
>> It is not too hard to build new StrikeFonts. You need to build, by
>> hand,
>> files like the ones in here:
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> p
>> and learn a bit about stuff like #installDejaVu2 . Maybe it was with
>> this method and the files in this zip that built the existing
>> instances
>> of StrikeFont. Not sure.
>>
> That's intrigueing but I can't reproduce it. Maybe the .bmp but where did you get the .txt?
>
>   - Dan

I wrote them with a text editor. Check #installDejaVu2 and really try to 
understand how StrikeFonts work and how they are built with this method. 
Maybe you'll become enlightened.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sun Jul 19 09:20:19 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 19 Jul 2015 11:20:19 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437158701.2255.245.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
Message-ID: <55ABB223.8010309@jvuletich.org>

Hi Folks,

(inline)

On 7/17/2015 3:45 PM, Phil (list) wrote:
> ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>> Thank you Juan, for answering.
>>>
>>> At the moment I feel uncomfortable using Cuis because it is currently
>>> a quite fast moving target. I perceive quite a number of API changes
>>> though this might be wrong. But I do not know because there are no
>>> release notes which summarize it.
> I totally feel Hannes' pain having gone through it a few times myself
> over the years.  At the same time, I agree with Ken's point about not
> getting too bogged down in process since we're in the best position
> right now to break things for the better longer term.
>
>> Yes, that's true. Besides, we don't have a specification of what is an
>> API and what is not. So, almost any change can be considered an API change.
> That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
> issue, not specific to Cuis)  I believe it is largely fixable without
> tons of documentation and tests: the use of private (categories or
> method naming convention).  Bernhard pointed out an existing capability
> a few months ago
> http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
> While I personally like the idea of private categories, one of these
> approaches should really be seriously considered.
>
> Other than a few specific examples (i.e. mostly the base data types
> including the Collection and Number class hierarchies which are pretty
> mature and don't change all that much anyway) I would guesstimate that
> <20% (probably closer to 10%) of the methods, and and unknown % of
> classes (a significantly larger fraction though), should even be
> considered public.  If things were indicated as private that would
> accomplish two things:
>
> 1) We could construct some simple tooling (some combination of up-front
> warnings in the editor and/or a lint-type tester after the fact) that
> would allow people to identify problematic calls within their code.
> (i.e. just because it works now doesn't mean it always will if you keep
> calling X, Y, Z...)
>
> 2) It would provide a way for people to know if something needs to be
> discussed.  i.e. 'In class X method Y is private but I need that type of
> functionality' so you would know that there's a need and could consider
> either making it public, and therefore supported, or rethinking its
> implementation if you'd like to offer a better public API solution.

Ok. Doing something along these lines would be great. But please note 
that it is a rather large amount of work. It is not something I'm able 
or willing to do it alone. If you (any of you all, not just Phil) wants 
to start defining the API for any part of the system or optional 
packages, please start doing it and send the changesets to the list. If 
we get this working, I'll start the tools you mention.

<slowly diverging into OT rant>

On the other hand (and please forgive me if this kills a bit of 
momentum), I don't really think we are changing APIs that much. And I 
don't think we'll be doing it any more in the future than we do today, 
at least in the base image. I hope to see most of the activity and 
incompatible changes to happen in optional packages, and affecting 
package dependencies... Mhhh, now that I write this I think that it 
doesn't really go against the idea of defining APIs. Maybe APIs in the 
base image will almost never change or be a problem, but packages should 
provide APIs too... Optional packages will (I hope!) always be 
improving, and new ones will appear all the time.

If all this work, the Cuis will be a lot less about my personal effort 
and coding style, and the packages maintained by each one of us will 
become the main characters in this story. And this will be a very good 
thing. The base image should be about providing a good base for doing 
the really interesting stuff on top...

Let me tell you a bit about how Cuis got started. Many years ago I did 
my thesis on audio/music processing. The I wanted to turn that into a 
novel and fun application for musicians (both pros and anyone willing to 
play with sound). I started to think about how a good GUI for that could 
be, giving the feeling of modifying sound by direct manipulation of it, 
as if it was clay, as if it was visual and not just auditory. Well, that 
was the start of my questioning of the whole GUI business and Morphic 3. 
And it became clear to me that Squeak had turned into something that was 
not the best possible environment to do all this. The idea of "fixing" 
Squeak, and thus make Cuis, was born. So, Cuis was not and end in 
itself, but a means for allowing experimentation, freedom to build 
applications in new styles, etc.

(The idea that Cuis is a truer Smalltalk-80 than Squeak or any other 
came later, as an observation on facts.)

So, when the moment comes when Cuis stabilizes a bit, and interest moves 
to packages and applications built by all us, Cuis will start to fulfill 
its original objective.

</slowly diverging into OT rant>

>> ...
>> The problem, I think, is not identifying well defined Cuis releases. The
>> problem is knowing how updates could affect your code
> By narrowing the scope of what the public API is using private
> designators, this dramatically reduces what you need to be concerned
> with on this front.  It's part of the reason that Apple, Google, and
> even Microsoft are so adamant about public APIs these days.  They dealt
> with the pain of even major developers depending on private APIs for
> decades. It's only been in the last 10 years or so that they've been
> able to dig themselves out from under this issue.
>
> This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
> attitude of 'you have the source, play around, have fun!' has morphed
> into 'everything is a public API!  there are no rules! isn't this
> great?'  Well no, it's not great.  It makes life impossible for image
> maintainers (Squeak has been in a coma for the last decade or so as the
> result of trying to keep everyone happy... yet no one seems to be) and
> miserable for those who are trying to keep code running on it (stuff
> still breaks all the time.)

Yes.

> I personally believe the minimalism and simplicity that Cuis is based on
> has the best long term prospects but we have to get out of this
> 'everything is public' mindset.  Sure, we have all the source: look at
> it, learn from it, poke around, refactor it, submit fixes, etc.  But
> there needs to be a manageable subset of it which is considered the
> 'public API' that people can depend on to write frameworks and apps on
> top of that is relatively stable longer term.  Let's start defining what
> that is and backfill changes to the public API (which will happen from
> time to time as we don't want things to be completely static) with tests
> and documentation so you can focus your efforts on where they matter
> most and you get the most enjoyment from.

I fully agree and support this.
Maybe an alternative to yet-another-convention-on-categories could be to 
mark public methods with a pragma, or make them send 'self publicAPI' or 
such... This could be better for the tools, also.

> ...
>> I don't have that either. I run the tests from time to time (I'll start
>> doing it before any commit, and add the xml report to the rep). But this
>> is not the most important reason why Cuis is solid. Cuis is very
>> reliable because:
> reliable != stable

;)

>> - I'm not too bad as a coder.
>> - I do my own code revisions at least one day after each change.
>> - I use Cuis every day, and spot most problems in the updates, before
>> commtting them to the repo.
>> - I really, really care about code quality.
>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>> is a big responsibility, given how important I think Smalltalk-80 is.
>>
> Agree to all this and more.  Cuis would not be where it is without your
> continued effort and diligence. (i.e. setting aside that you obviously
> created it, if you had just tossed it out into the world and let it go
> at best it would have started looking something like Squeak or Pharo by
> now.  It's a lot of effort over the long term to *keep* it small and
> focused.  THANK YOU JUAN!)

Thanks for your nice words, Phil. I really appreciate that you all 
accept this rather restrictive dev model for the base image, in contrast 
with a more open trunk style. Hopefully, as the base image becomes 
stable and almost irrelevant, this will be each time less of a problem.

>> So, I suggest running your tests when updating your image, or migrating
>> your code to an updated image.
> +1 to tests as they do help quite a bit and are a very good practice.
> Just be judicious in what/where you test (I personally don't subscribe
> to the TDD approach where you spend your days mostly writing tests.
> That's just admitting defeat in that you spend all day writing
> executable documentation.)

<OT>

I don't subscribe to "extreme" TDD either. To me design is a creative 
activity, both technical and artistic. It should be "driven" by 
creativity and intelligence, not by a process. Any xDD process is 
admitting defeat on design itself!

</OT>

>> In any case, I think this doesn't answer your concerns. What you need is
>> some way to know which updates could affect you, to review them in
>> detail, and understanding their effect on your code. A list of the
>> affected classes and/or methods for each update makes no sense. Cuis can
>> already show you that very easily. Perhaps each update should include:
>>
>> 1) parts of the system that are affected:
>> - Kernel
>> - Compiler
>> - Tools
>> - Morphic
>> - etc
>>
>> 2) Level of risk involved
>> - very unlikely to break code that depends on this part of the system
>> - could perhaps break code that depends on this part of the system
>> - will most likely break code that depends on this part of the system
>>
>> Or something like that.
>>
>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>> free to answer there if you agree.
> One final thought on this:  I suspect a major cause of people abandoning
> Cuis (and Smalltalk in general), behind the 'it's too different from
> what I'm used to'/'not mainstream' reaction, is the instability of its
> APIs.

Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) 
is a PITA too...

As a bottom line, let me repeat: This is too big for me to do it. 
Please, folks, start documenting the APIs you most care about.

Cheers,
Juan Vuletich



From peter at aba-instituut.nl  Sun Jul 19 11:02:20 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Sun, 19 Jul 2015 18:02:20 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55ABB223.8010309@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
Message-ID: <CAJBxtBY7YtLCJwVSOM3w58shed-YcnON=BL2WD2xM6EAMVbn2A@mail.gmail.com>

Hey all,

Just 2 cents from a Cuis noob:

1. Releases... since this stuff is not being sold for money and not being
distributed using off-line media, what use does a "release" have? I like
that stuff gets improved as often as possible. I believe that the things
that get improved the most often, have the best chance of becoming
something really good.

So, I am for adopting practices that increase the number of improvements.
Practices that decrease the number of deteriorations seem helpful as well.
See below if you wonder what my point is ;-).

2. Public vs private API. Stable APIs are nice, if you can get them. If you
have authors who develop a base, and other authors who (have to) develop ON
that base, you need stable APIs, or you will lose the authors dependent on
your base.

So, do we really have those different author groups? Somehow I doubt it. I
recently changed the scoping rules for shared variables (I think they're
done wrong in the base image). I could change what I wanted easily. So I
think I am not in some outsider author group. Instead I am happy that I
could change what I wanted without needing anyone's approval or cooperation.

Suppose we were making money from outside author groups who want us to keep
certain APIs stable. For the right price, I would be happy to provide that
for them. In the mean time, I can live with free. Free to change what I
want, free to use without paying, and others free to change what I am
building on (sometimes frustrating).

3. Maybe what will help everybody is something that prevents functionality
from being lost, especially *unintentionally*. This can include certain
APIs as well. So what if an author who values a certain API, could invest
some of his own time/money, to protect that API? What if he could write a
software component (let's say a class) that was able to detect whenever an
image did not provide the desired API? What if he could submit that class,
and everybody who cared about not breaking that API, could use that class
to see if perhaps they broke it?

4. I believe the idea could be generalized to include any feature of (the
code in) an image for which presence or absence (as may be the case) can be
determined by such a class. Bugs could be reified as classes, and the
presence or absence of the bug could be determined by that class. Feature
requests could be reified as classes, and whether or not the feature had
actually been implemented could be determined by that class.

5. The things I am proposing would basically be Feature Tests, and would be
rather different from Unit Tests (which apply to a unit and which you want
to all be green when you share your software with users of it). Feature
Tests would apply to a system (not a unit) and simply indicate which
features are and which features are not present in the system. Every
"release" could then come with a) the assertion that all the Unit Tests
passed b) a list of the Feature Tests that passed and those that did not.

6. I think it would be pretty cool if people sent in feature requests in
the form of Feature Tests, instead of messages to the mailing list (or the
request tracker). So that anybody who (wished to impress somebody and) had
some time on their hands, could then try to implement the functionality
that made the Feature Test pass.

Hope this helps somebody with something :)

Cheers, Peter

On Sun, Jul 19, 2015 at 4:20 PM, Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Folks,
>
> (inline)
>
> On 7/17/2015 3:45 PM, Phil (list) wrote:
>
>> ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>
>>> Thank you Juan, for answering.
>>>>
>>>> At the moment I feel uncomfortable using Cuis because it is currently
>>>> a quite fast moving target. I perceive quite a number of API changes
>>>> though this might be wrong. But I do not know because there are no
>>>> release notes which summarize it.
>>>>
>>> I totally feel Hannes' pain having gone through it a few times myself
>> over the years.  At the same time, I agree with Ken's point about not
>> getting too bogged down in process since we're in the best position
>> right now to break things for the better longer term.
>>
>>  Yes, that's true. Besides, we don't have a specification of what is an
>>> API and what is not. So, almost any change can be considered an API
>>> change.
>>>
>> That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
>> issue, not specific to Cuis)  I believe it is largely fixable without
>> tons of documentation and tests: the use of private (categories or
>> method naming convention).  Bernhard pointed out an existing capability
>> a few months ago
>> http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
>> While I personally like the idea of private categories, one of these
>> approaches should really be seriously considered.
>>
>> Other than a few specific examples (i.e. mostly the base data types
>> including the Collection and Number class hierarchies which are pretty
>> mature and don't change all that much anyway) I would guesstimate that
>> <20% (probably closer to 10%) of the methods, and and unknown % of
>> classes (a significantly larger fraction though), should even be
>> considered public.  If things were indicated as private that would
>> accomplish two things:
>>
>> 1) We could construct some simple tooling (some combination of up-front
>> warnings in the editor and/or a lint-type tester after the fact) that
>> would allow people to identify problematic calls within their code.
>> (i.e. just because it works now doesn't mean it always will if you keep
>> calling X, Y, Z...)
>>
>> 2) It would provide a way for people to know if something needs to be
>> discussed.  i.e. 'In class X method Y is private but I need that type of
>> functionality' so you would know that there's a need and could consider
>> either making it public, and therefore supported, or rethinking its
>> implementation if you'd like to offer a better public API solution.
>>
>
> Ok. Doing something along these lines would be great. But please note that
> it is a rather large amount of work. It is not something I'm able or
> willing to do it alone. If you (any of you all, not just Phil) wants to
> start defining the API for any part of the system or optional packages,
> please start doing it and send the changesets to the list. If we get this
> working, I'll start the tools you mention.
>
> <slowly diverging into OT rant>
>
> On the other hand (and please forgive me if this kills a bit of momentum),
> I don't really think we are changing APIs that much. And I don't think
> we'll be doing it any more in the future than we do today, at least in the
> base image. I hope to see most of the activity and incompatible changes to
> happen in optional packages, and affecting package dependencies... Mhhh,
> now that I write this I think that it doesn't really go against the idea of
> defining APIs. Maybe APIs in the base image will almost never change or be
> a problem, but packages should provide APIs too... Optional packages will
> (I hope!) always be improving, and new ones will appear all the time.
>
> If all this work, the Cuis will be a lot less about my personal effort and
> coding style, and the packages maintained by each one of us will become the
> main characters in this story. And this will be a very good thing. The base
> image should be about providing a good base for doing the really
> interesting stuff on top...
>
> Let me tell you a bit about how Cuis got started. Many years ago I did my
> thesis on audio/music processing. The I wanted to turn that into a novel
> and fun application for musicians (both pros and anyone willing to play
> with sound). I started to think about how a good GUI for that could be,
> giving the feeling of modifying sound by direct manipulation of it, as if
> it was clay, as if it was visual and not just auditory. Well, that was the
> start of my questioning of the whole GUI business and Morphic 3. And it
> became clear to me that Squeak had turned into something that was not the
> best possible environment to do all this. The idea of "fixing" Squeak, and
> thus make Cuis, was born. So, Cuis was not and end in itself, but a means
> for allowing experimentation, freedom to build applications in new styles,
> etc.
>
> (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other came
> later, as an observation on facts.)
>
> So, when the moment comes when Cuis stabilizes a bit, and interest moves
> to packages and applications built by all us, Cuis will start to fulfill
> its original objective.
>
> </slowly diverging into OT rant>
>
>  ...
>>> The problem, I think, is not identifying well defined Cuis releases. The
>>> problem is knowing how updates could affect your code
>>>
>> By narrowing the scope of what the public API is using private
>> designators, this dramatically reduces what you need to be concerned
>> with on this front.  It's part of the reason that Apple, Google, and
>> even Microsoft are so adamant about public APIs these days.  They dealt
>> with the pain of even major developers depending on private APIs for
>> decades. It's only been in the last 10 years or so that they've been
>> able to dig themselves out from under this issue.
>>
>> This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
>> attitude of 'you have the source, play around, have fun!' has morphed
>> into 'everything is a public API!  there are no rules! isn't this
>> great?'  Well no, it's not great.  It makes life impossible for image
>> maintainers (Squeak has been in a coma for the last decade or so as the
>> result of trying to keep everyone happy... yet no one seems to be) and
>> miserable for those who are trying to keep code running on it (stuff
>> still breaks all the time.)
>>
>
> Yes.
>
>  I personally believe the minimalism and simplicity that Cuis is based on
>> has the best long term prospects but we have to get out of this
>> 'everything is public' mindset.  Sure, we have all the source: look at
>> it, learn from it, poke around, refactor it, submit fixes, etc.  But
>> there needs to be a manageable subset of it which is considered the
>> 'public API' that people can depend on to write frameworks and apps on
>> top of that is relatively stable longer term.  Let's start defining what
>> that is and backfill changes to the public API (which will happen from
>> time to time as we don't want things to be completely static) with tests
>> and documentation so you can focus your efforts on where they matter
>> most and you get the most enjoyment from.
>>
>
> I fully agree and support this.
> Maybe an alternative to yet-another-convention-on-categories could be to
> mark public methods with a pragma, or make them send 'self publicAPI' or
> such... This could be better for the tools, also.
>
>  ...
>>
>>> I don't have that either. I run the tests from time to time (I'll start
>>> doing it before any commit, and add the xml report to the rep). But this
>>> is not the most important reason why Cuis is solid. Cuis is very
>>> reliable because:
>>>
>> reliable != stable
>>
>
> ;)
>
>  - I'm not too bad as a coder.
>>> - I do my own code revisions at least one day after each change.
>>> - I use Cuis every day, and spot most problems in the updates, before
>>> commtting them to the repo.
>>> - I really, really care about code quality.
>>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>>> is a big responsibility, given how important I think Smalltalk-80 is.
>>>
>>>  Agree to all this and more.  Cuis would not be where it is without your
>> continued effort and diligence. (i.e. setting aside that you obviously
>> created it, if you had just tossed it out into the world and let it go
>> at best it would have started looking something like Squeak or Pharo by
>> now.  It's a lot of effort over the long term to *keep* it small and
>> focused.  THANK YOU JUAN!)
>>
>
> Thanks for your nice words, Phil. I really appreciate that you all accept
> this rather restrictive dev model for the base image, in contrast with a
> more open trunk style. Hopefully, as the base image becomes stable and
> almost irrelevant, this will be each time less of a problem.
>
>  So, I suggest running your tests when updating your image, or migrating
>>> your code to an updated image.
>>>
>> +1 to tests as they do help quite a bit and are a very good practice.
>> Just be judicious in what/where you test (I personally don't subscribe
>> to the TDD approach where you spend your days mostly writing tests.
>> That's just admitting defeat in that you spend all day writing
>> executable documentation.)
>>
>
> <OT>
>
> I don't subscribe to "extreme" TDD either. To me design is a creative
> activity, both technical and artistic. It should be "driven" by creativity
> and intelligence, not by a process. Any xDD process is admitting defeat on
> design itself!
>
> </OT>
>
>  In any case, I think this doesn't answer your concerns. What you need is
>>> some way to know which updates could affect you, to review them in
>>> detail, and understanding their effect on your code. A list of the
>>> affected classes and/or methods for each update makes no sense. Cuis can
>>> already show you that very easily. Perhaps each update should include:
>>>
>>> 1) parts of the system that are affected:
>>> - Kernel
>>> - Compiler
>>> - Tools
>>> - Morphic
>>> - etc
>>>
>>> 2) Level of risk involved
>>> - very unlikely to break code that depends on this part of the system
>>> - could perhaps break code that depends on this part of the system
>>> - will most likely break code that depends on this part of the system
>>>
>>> Or something like that.
>>>
>>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>>> free to answer there if you agree.
>>>
>> One final thought on this:  I suspect a major cause of people abandoning
>> Cuis (and Smalltalk in general), behind the 'it's too different from
>> what I'm used to'/'not mainstream' reaction, is the instability of its
>> APIs.
>>
>
> Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) is
> a PITA too...
>
> As a bottom line, let me repeat: This is too big for me to do it. Please,
> folks, start documenting the APIs you most care about.
>
> 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/20150719/8e5a281b/attachment-0003.html>

From hannes.hirzel at gmail.com  Sun Jul 19 14:48:04 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 19:48:04 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <55A90799.7080302@jvuletich.org>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
Message-ID: <CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>

If I use this to find out which methods have a time stamp date
indicating a change after the 1st of January 2015 in a pristine Cuis
4.2-2243 (17 April 2015) image I find out that only the

#postCopy method was changed (probably added) in nearly all classes.

If I change the base line date to 1st of January 2014 I get

a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy #at:ifAbsent:)
as changed/updated methods (i.e. methods which have a time stamp in
this period).

Of course this assumes that a method gets a time stamp when changed.
Many methods have nil as a time stamp.


Could somebody from the list check this please?


|date coll baseLineDate dt  updatedMethods |

baseLineDate := Date year: 2014 month: 1 day: 1.
coll := OrderedCollection new.

Smalltalk allClasses do: [ :cls |
cls allSelectors do: [ :sel |
dt := VersionsBrowser timeStampFor:  sel class: Dictionary reverseOrdinal:  1.

dt notNil ifTrue: [
date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
]) or: [ch = $:]] .
(date = '') ifFalse:
	[date := Date fromString: date.
		(date > baseLineDate) ifTrue: [coll add: (Association key:
(Association key: cls value: sel) value: date)
]]].

]].

updatedMethods := Set new.
coll do: [ :elem | updatedMethods add: (elem key value)].
coll inspect.
updatedMethods inspect




On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/16/2015 11:49 AM, H. Hirzel wrote:
>> Hello
>>
>> I'd like to do a query finding out about the time stamp of  source
>> code changes of all methods in the Cuis image and then do a list with
>> the following four columns
>>
>>
>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
>> DateOfChange
>>
>> Help is appreciated.
>>
>> Hannes
>
> Check #timeStampFor:class:reverseOrdinal: and in general
> #annotationForSelector:ofClass:
>
> Cheers,
> Juan Vuletich
>



From Ken.Dickey at whidbey.com  Sun Jul 19 15:18:38 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sun, 19 Jul 2015 13:18:38 -0700
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55ABB223.8010309@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
Message-ID: <20150719131838.7d00ce57192818d00c38262c@whidbey.com>

On Sun, 19 Jul 2015 11:20:19 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> As a bottom line, let me repeat: This is too big for me to do it. 
> Please, folks, start documenting the APIs you most care about.

Let me repeat, "you don't have to do it".

I'd like to propose a simpler model based on the Smalltalk Way.

We take any stable revision, call it a version, give it a Baseline Version Number (could be just the development version number).  Each Baseline Release has a release document which describes major changes since the previous baseline.  This document is a light-weight description.

Each baseline release starts a new fork.  The only changes to the particular baseline release are bug fixes.

Nice users test their packages and likewise fork a Package Release which matches a Baseline Release.  This fork also only changes with bug fixes, and only in synch with its particular baseline.  Baseline packages Feature the baseline release.

So we forge ahead as usual, once in a while we say "enough has changed that we should re-baseline", do a new Baseline Release, test and release our Package Releases, then again move on forward.

Anyone can now pick any baseline release, require any associated packages, and ship/demo without fear.

Anyone with the time, energy, and interest can document baseline APIs to whatever level they feel comfortable.

Anyone can forge on ahead with the latest revision(s) with the usual "here be dragons, but also gold".

$0.02
-KenD



From hannes.hirzel at gmail.com  Sun Jul 19 15:21:09 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 20:21:09 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
Message-ID: <CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>

If I take a current image (18 Jul 2015, 4.2-2424)  I get the same result


a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy #at:ifAbsent:)

All the FileMan additions are not listed. Maybe because they keep
their original time stamp, not the time stamp of the addition to
Squeak.

And the recent change on #compilerClass does not show up.

--HH

On 7/19/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> If I use this to find out which methods have a time stamp date
> indicating a change after the 1st of January 2015 in a pristine Cuis
> 4.2-2243 (17 April 2015) image I find out that only the
>
> #postCopy method was changed (probably added) in nearly all classes.
>
> If I change the base line date to 1st of January 2014 I get
>
> a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
> #at:ifAbsent:)
> as changed/updated methods (i.e. methods which have a time stamp in
> this period).
>
> Of course this assumes that a method gets a time stamp when changed.
> Many methods have nil as a time stamp.
>
>
> Could somebody from the list check this please?
>
>
> |date coll baseLineDate dt  updatedMethods |
>
> baseLineDate := Date year: 2014 month: 1 day: 1.
> coll := OrderedCollection new.
>
> Smalltalk allClasses do: [ :cls |
> cls allSelectors do: [ :sel |
> dt := VersionsBrowser timeStampFor:  sel class: Dictionary reverseOrdinal:
> 1.
>
> dt notNil ifTrue: [
> date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
> ]) or: [ch = $:]] .
> (date = '') ifFalse:
> 	[date := Date fromString: date.
> 		(date > baseLineDate) ifTrue: [coll add: (Association key:
> (Association key: cls value: sel) value: date)
> ]]].
>
> ]].
>
> updatedMethods := Set new.
> coll do: [ :elem | updatedMethods add: (elem key value)].
> coll inspect.
> updatedMethods inspect
>
>
>
>
> On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
>> On 7/16/2015 11:49 AM, H. Hirzel wrote:
>>> Hello
>>>
>>> I'd like to do a query finding out about the time stamp of  source
>>> code changes of all methods in the Cuis image and then do a list with
>>> the following four columns
>>>
>>>
>>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
>>> DateOfChange
>>>
>>> Help is appreciated.
>>>
>>> Hannes
>>
>> Check #timeStampFor:class:reverseOrdinal: and in general
>> #annotationForSelector:ofClass:
>>
>> Cheers,
>> Juan Vuletich
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis compilerClass Screenshot from 2015-07-19 20:18:32.png
Type: image/png
Size: 33713 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150719/16f947f7/attachment-0003.png>

From hannes.hirzel at gmail.com  Sun Jul 19 15:50:18 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 20:50:18 +0000
Subject: [Cuis] API descriptions in form of an external package / Feature
	tests?
Message-ID: <CAGQxfViw4j2cvFUBf-0G_TE_e3cBi0=r8=d8YXacB4B4vv-zQw@mail.gmail.com>

Hello Peter

I think your proposal to check the presence of an API is very interesting.

You suggest to have API descriptions in form of classes in an external
package which test the presence of an API.

Contrariwise to unit tests they only look for the presence of a
classes with certain methods.

It is an external tool (i.e. not included in the core) to check the
presence or absence of an API.

These tools can focus on a certain part of the system which is of a
particular interest for an external package and be kept with that
package.

--Hannes


On 7/19/15, Peter van Rooijen <peter at aba-instituut.nl> wrote:
> Hey all,
>
> Just 2 cents from a Cuis noob:
>
...
>

A. Increase the number of improvements

> So, I am for adopting practices that increase the number of improvements.


B. Decrease the number of deterioations

> Practices that decrease the number of deteriorations seem helpful as well.
> See below if you wonder what my point is ;-).
>
...

> 3. Maybe what will help everybody is something that prevents functionality
> from being lost, especially *unintentionally*. This can include certain
> APIs as well. So what if an author who values a certain API, could invest
> some of his own time/money, to protect that API? What if he could write a
> software component (let's say a class) that was able to detect whenever an
> image did not provide the desired API? What if he could submit that class,
> and everybody who cared about not breaking that API, could use that class
> to see if perhaps they broke it?
>
> 4. I believe the idea could be generalized to include any feature of (the
> code in) an image for which presence or absence (as may be the case) can be
> determined by such a class. Bugs could be reified as classes, and the
> presence or absence of the bug could be determined by that class. Feature
> requests could be reified as classes, and whether or not the feature had
> actually been implemented could be determined by that class.
>
> 5. The things I am proposing would basically be Feature Tests, and would be
> rather different from Unit Tests (which apply to a unit and which you want
> to all be green when you share your software with users of it). Feature
> Tests would apply to a system (not a unit) and simply indicate which
> features are and which features are not present in the system. Every
> "release" could then come with a) the assertion that all the Unit Tests
> passed b) a list of the Feature Tests that passed and those that did not.
>
> 6. I think it would be pretty cool if people sent in feature requests in
> the form of Feature Tests, instead of messages to the mailing list (or the
> request tracker). So that anybody who (wished to impress somebody and) had
> some time on their hands, could then try to implement the functionality
> that made the Feature Test pass.



From hannes.hirzel at gmail.com  Sun Jul 19 15:53:27 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 20:53:27 +0000
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150719131838.7d00ce57192818d00c38262c@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
Message-ID: <CAGQxfVgj4-zOZazpQcB8hhy_cikBCMJqU0iTPNLZqNZMrC-23A@mail.gmail.com>

KenD

I like your proposal. And earlier you suggested to have one of these
base line versions per year.

--Hannes

On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Sun, 19 Jul 2015 11:20:19 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
>
>> As a bottom line, let me repeat: This is too big for me to do it.
>> Please, folks, start documenting the APIs you most care about.
>
> Let me repeat, "you don't have to do it".
>
> I'd like to propose a simpler model based on the Smalltalk Way.
>
> We take any stable revision, call it a version, give it a Baseline Version
> Number (could be just the development version number).  Each Baseline
> Release has a release document which describes major changes since the
> previous baseline.  This document is a light-weight description.
>
> Each baseline release starts a new fork.  The only changes to the particular
> baseline release are bug fixes.
>
> Nice users test their packages and likewise fork a Package Release which
> matches a Baseline Release.  This fork also only changes with bug fixes, and
> only in synch with its particular baseline.  Baseline packages Feature the
> baseline release.
>
> So we forge ahead as usual, once in a while we say "enough has changed that
> we should re-baseline", do a new Baseline Release, test and release our
> Package Releases, then again move on forward.
>
> Anyone can now pick any baseline release, require any associated packages,
> and ship/demo without fear.
>
> Anyone with the time, energy, and interest can document baseline APIs to
> whatever level they feel comfortable.
>
> Anyone can forge on ahead with the latest revision(s) with the usual "here
> be dragons, but also gold".
>
> $0.02
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Sun Jul 19 16:01:17 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 21:01:17 +0000
Subject: [Cuis] Scoping rules for shared variables ?
Message-ID: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>

On 7/19/15, Peter van Rooijen <peter at aba-instituut.nl> wrote:
....
 I
> recently changed the scoping rules for shared variables (I think they're
> done wrong in the base image). I could change what I wanted easily. So I
> think I am not in some outsider author group. Instead I am happy that I
> could change what I wanted without needing anyone's approval or
> cooperation.

A note:
This applies to any version / distribution of Smalltalk. But it means
that you have your own version of the core system.

Could you elaborate on the issue of the shared variables, maybe it is
something to include in the core Cuis image?

--Hannes



From pbpublist at gmail.com  Sun Jul 19 16:38:25 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 17:38:25 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55ABB223.8010309@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
Message-ID: <1437341905.6934.99.camel@gmail.com>

On Sun, 2015-07-19 at 11:20 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> (inline)
> 
> On 7/17/2015 3:45 PM, Phil (list) wrote:
> > ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
> >>> Thank you Juan, for answering.
> >>>
> >>> At the moment I feel uncomfortable using Cuis because it is currently
> >>> a quite fast moving target. I perceive quite a number of API changes
> >>> though this might be wrong. But I do not know because there are no
> >>> release notes which summarize it.
> > I totally feel Hannes' pain having gone through it a few times myself
> > over the years.  At the same time, I agree with Ken's point about not
> > getting too bogged down in process since we're in the best position
> > right now to break things for the better longer term.
> >
> >> Yes, that's true. Besides, we don't have a specification of what is an
> >> API and what is not. So, almost any change can be considered an API change.
> > That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
> > issue, not specific to Cuis)  I believe it is largely fixable without
> > tons of documentation and tests: the use of private (categories or
> > method naming convention).  Bernhard pointed out an existing capability
> > a few months ago
> > http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
> > While I personally like the idea of private categories, one of these
> > approaches should really be seriously considered.
> >
> > Other than a few specific examples (i.e. mostly the base data types
> > including the Collection and Number class hierarchies which are pretty
> > mature and don't change all that much anyway) I would guesstimate that
> > <20% (probably closer to 10%) of the methods, and and unknown % of
> > classes (a significantly larger fraction though), should even be
> > considered public.  If things were indicated as private that would
> > accomplish two things:
> >
> > 1) We could construct some simple tooling (some combination of up-front
> > warnings in the editor and/or a lint-type tester after the fact) that
> > would allow people to identify problematic calls within their code.
> > (i.e. just because it works now doesn't mean it always will if you keep
> > calling X, Y, Z...)
> >
> > 2) It would provide a way for people to know if something needs to be
> > discussed.  i.e. 'In class X method Y is private but I need that type of
> > functionality' so you would know that there's a need and could consider
> > either making it public, and therefore supported, or rethinking its
> > implementation if you'd like to offer a better public API solution.
> 
> Ok. Doing something along these lines would be great. But please note 
> that it is a rather large amount of work. It is not something I'm able 
> or willing to do it alone. If you (any of you all, not just Phil) wants 
> to start defining the API for any part of the system or optional 
> packages, please start doing it and send the changesets to the list. If 
> we get this working, I'll start the tools you mention.
> 

Agreed that this is a lot of work and I definitely wasn't expecting you
to do it (other than reviewing the work for approval/rejection.)  I'll
be happy to work on this with anyone else who is interested.

> <slowly diverging into OT rant>
> 
> On the other hand (and please forgive me if this kills a bit of 
> momentum), I don't really think we are changing APIs that much. And I 
> don't think we'll be doing it any more in the future than we do today, 
> at least in the base image. I hope to see most of the activity and 
> incompatible changes to happen in optional packages, and affecting 
> package dependencies... Mhhh, now that I write this I think that it 
> doesn't really go against the idea of defining APIs. Maybe APIs in the 
> base image will almost never change or be a problem, but packages should 
> provide APIs too... Optional packages will (I hope!) always be 
> improving, and new ones will appear all the time.
> 

You'd likely be very surprised.  I'd say there's usually at least a
couple changes a month that breaks something, somewhere in my code.  A
few recent examples that have been discussed on the list: removing clone
broke OpenGL a bit (easy fix thanks to the on-list discussion), removing
compilerClass killed OMeta, a while back you were considering removing
storeString which would again break OMeta. etc. (that's just a few
things off the top of my head from the last few months and note that all
were probably considered minor, inconsequential changes)  However the
issue snowballs quickly if one misses a few updates and some of the
breakage is related to changes that weren't discussed on the list or
otherwise documented.  I've been managing through this recently (the
last 6 months or so) by upgrading my image very quickly after you commit
changes but I doubt most people would be able / willing to have that
level of diligence.

A lot of this breakage is no one's 'fault', it's just how a lot of
Smalltalk code has been historically written.  Two examples of how this
happens:

1) For ports of existing code, you're subject to the whims of the
original author who often used techniques described in the next item to
write their code.  And of course, code coming from Squeak/Pharo means
that there were often 10 or more possible ways they could have
implemented parts of their solution.  So after porting a few different
packages, you have several different approaches to the same kinds of
problems.

2) For one's own code because there is currently no distinction between
public and private, you tend to go either with what you already know or
whatever the first thing you find poking around the image that appears
to make sense and work.  Even in Cuis, there are still usually multiple
ways to do most things, so you end up arbitrarily picking one or two
that you like.  As a result, you quickly end up with a potpourri of
calls that may or may not be the best way to do things.  Over time, you
start building new code on top of this code and quickly end up with a
house of cards that comes crashing down as the result of a subsequent
image update.  Again, this often results in each of us as authors
deciding on superficially different solutions to the same problems.

I'm not expecting you to not do things that might break my, or anyone
else's code, going forward.  Like Hannes, I'm just looking for ways to
help manage through the changes and breakage.  One of the key aspects of
this is to have an opinion and to say 'hey, here are the one or two ways
we should be doing this'.  There may be disagreement and discussion as
to what those one or two ways are, but at the end of the day we need to
settle these issues so that both your and our lives are manageable.
That's really the main thing that a public API is, IMO.  There may be
all sorts of internal helper methods and implementation details needed
to make it all work, but like the cells of a living organism, these
details should be hidden and their use discouraged.  Hey, didn't someone
say something along those lines once? :-)
 
> If all this work, the Cuis will be a lot less about my personal effort 
> and coding style, and the packages maintained by each one of us will 
> become the main characters in this story. And this will be a very good 
> thing. The base image should be about providing a good base for doing 
> the really interesting stuff on top...
> 

I both agree (that the packages become more important) and disagree
(that Cuis fades into the background).  I still view the core Cuis image
as the philosophical and stylistic backbone that all of my stuff is
based on.  It's a constant reminder to clean up and get rid of as much
cruft as possible in my code (especially for the packages that have yet
other packages dependent on them)  I freely admit that I am mostly
falling short in my execution on this front, but it would be easy to
lose sight of entirely if Cuis didn't stay the course.

> Let me tell you a bit about how Cuis got started. Many years ago I did 
> my thesis on audio/music processing. The I wanted to turn that into a 
> novel and fun application for musicians (both pros and anyone willing to 
> play with sound). I started to think about how a good GUI for that could 
> be, giving the feeling of modifying sound by direct manipulation of it, 
> as if it was clay, as if it was visual and not just auditory. Well, that 
> was the start of my questioning of the whole GUI business and Morphic 3. 
> And it became clear to me that Squeak had turned into something that was 
> not the best possible environment to do all this. The idea of "fixing" 
> Squeak, and thus make Cuis, was born. So, Cuis was not and end in 
> itself, but a means for allowing experimentation, freedom to build 
> applications in new styles, etc.
> 
> (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other 
> came later, as an observation on facts.)
> 
> So, when the moment comes when Cuis stabilizes a bit, and interest moves 
> to packages and applications built by all us, Cuis will start to fulfill 
> its original objective.
> 

It's already this is as far as I'm concerned.  I can't tell you much
time I burned just trying to extract OpenGL from Croquet so that I could
load it into Squeak, for example.  It was painful on both sides, and by
the time I was done I had to think for a bit to remind myself what my
original objective was... I have *never* had this issue with Cuis.

It is absolutely enabling me to play around with ideas and build things
that I couldn't have / wouldn't have bothered in Squeak.  The only issue
I'm having is that once I've built it, I want to keep it running :-)

> </slowly diverging into OT rant>

Not at all a rant as it reaffirms *why* you're doing what you're doing.
If you lost sight of that, that's when I'd start worrying about Cuis.

> 
> >> ...
> >> The problem, I think, is not identifying well defined Cuis releases. The
> >> problem is knowing how updates could affect your code
> > By narrowing the scope of what the public API is using private
> > designators, this dramatically reduces what you need to be concerned
> > with on this front.  It's part of the reason that Apple, Google, and
> > even Microsoft are so adamant about public APIs these days.  They dealt
> > with the pain of even major developers depending on private APIs for
> > decades. It's only been in the last 10 years or so that they've been
> > able to dig themselves out from under this issue.
> >
> > This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
> > attitude of 'you have the source, play around, have fun!' has morphed
> > into 'everything is a public API!  there are no rules! isn't this
> > great?'  Well no, it's not great.  It makes life impossible for image
> > maintainers (Squeak has been in a coma for the last decade or so as the
> > result of trying to keep everyone happy... yet no one seems to be) and
> > miserable for those who are trying to keep code running on it (stuff
> > still breaks all the time.)
> 
> Yes.
> 
> > I personally believe the minimalism and simplicity that Cuis is based on
> > has the best long term prospects but we have to get out of this
> > 'everything is public' mindset.  Sure, we have all the source: look at
> > it, learn from it, poke around, refactor it, submit fixes, etc.  But
> > there needs to be a manageable subset of it which is considered the
> > 'public API' that people can depend on to write frameworks and apps on
> > top of that is relatively stable longer term.  Let's start defining what
> > that is and backfill changes to the public API (which will happen from
> > time to time as we don't want things to be completely static) with tests
> > and documentation so you can focus your efforts on where they matter
> > most and you get the most enjoyment from.
> 
> I fully agree and support this.
> Maybe an alternative to yet-another-convention-on-categories could be to 
> mark public methods with a pragma, or make them send 'self publicAPI' or 
> such... This could be better for the tools, also.
> 

I like your idea better re: rather than having to go through and mark
the majority as private, just mark the minority as public.  I'm open to
either of your proposed approaches.  I just tossed out the two (method
categories and naming) I was aware of but agree that they would not do
much to ease developing tools to support/enforce.  Of the two ideas, am
I correct in believing that pragma would have the lowest runtime
overhead?  Are there any downsides you can think of to using pragma?

Speaking of enforcing, I am not proposing that we make this a
straight-jacket for anyone: it should be easy to opt-out the way things
like underscore assignment are (except for pp which I'm still trying to
get to an easily repro example with... :-) so that anyone who doesn't
care about this isn't forced into it.  On the other hand, for people who
do care, they should be able to leave it 'enabled', whatever that ends
up meaning, and get help from the tooling to help them minimize
potential future breakage.  The downside to opting out would be that
you, as the author opting out, have decided to take it entirely on
yourself to keep your code running across builds/releases.

> > ...
> >> I don't have that either. I run the tests from time to time (I'll start
> >> doing it before any commit, and add the xml report to the rep). But this
> >> is not the most important reason why Cuis is solid. Cuis is very
> >> reliable because:
> > reliable != stable
> 
> ;)
> 
> >> - I'm not too bad as a coder.
> >> - I do my own code revisions at least one day after each change.
> >> - I use Cuis every day, and spot most problems in the updates, before
> >> commtting them to the repo.
> >> - I really, really care about code quality.
> >> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
> >> is a big responsibility, given how important I think Smalltalk-80 is.
> >>
> > Agree to all this and more.  Cuis would not be where it is without your
> > continued effort and diligence. (i.e. setting aside that you obviously
> > created it, if you had just tossed it out into the world and let it go
> > at best it would have started looking something like Squeak or Pharo by
> > now.  It's a lot of effort over the long term to *keep* it small and
> > focused.  THANK YOU JUAN!)
> 
> Thanks for your nice words, Phil. I really appreciate that you all 
> accept this rather restrictive dev model for the base image, in contrast 
> with a more open trunk style. Hopefully, as the base image becomes 
> stable and almost irrelevant, this will be each time less of a problem.
> 
> >> So, I suggest running your tests when updating your image, or migrating
> >> your code to an updated image.
> > +1 to tests as they do help quite a bit and are a very good practice.
> > Just be judicious in what/where you test (I personally don't subscribe
> > to the TDD approach where you spend your days mostly writing tests.
> > That's just admitting defeat in that you spend all day writing
> > executable documentation.)
> 
> <OT>
> 
> I don't subscribe to "extreme" TDD either. To me design is a creative 
> activity, both technical and artistic. It should be "driven" by 
> creativity and intelligence, not by a process. Any xDD process is 
> admitting defeat on design itself!
> 

Heh... I like the way you put that.

> </OT>
> 
> >> In any case, I think this doesn't answer your concerns. What you need is
> >> some way to know which updates could affect you, to review them in
> >> detail, and understanding their effect on your code. A list of the
> >> affected classes and/or methods for each update makes no sense. Cuis can
> >> already show you that very easily. Perhaps each update should include:
> >>
> >> 1) parts of the system that are affected:
> >> - Kernel
> >> - Compiler
> >> - Tools
> >> - Morphic
> >> - etc
> >>
> >> 2) Level of risk involved
> >> - very unlikely to break code that depends on this part of the system
> >> - could perhaps break code that depends on this part of the system
> >> - will most likely break code that depends on this part of the system
> >>
> >> Or something like that.
> >>
> >> BTW, this is a very relevant topic for discussing on the mail list. Feel
> >> free to answer there if you agree.
> > One final thought on this:  I suspect a major cause of people abandoning
> > Cuis (and Smalltalk in general), behind the 'it's too different from
> > what I'm used to'/'not mainstream' reaction, is the instability of its
> > APIs.
> 
> Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) 
> is a PITA too...

True, neither extreme (changing nothing vs. changing everything) works
very well. <cough>Perl 6</cough> :-)
 
> 
> As a bottom line, let me repeat: This is too big for me to do it. 
> Please, folks, start documenting the APIs you most care about.
> 

Ready to go... we just need to agree on how to do it (pragma/method
call/method category/method name?)  Also, this is most definitely
related to the 'Canonical test cases?' thread from a few months ago as
these types of test cases / docs are part of the backfill I was
referring to.

As I've been writing this it occurs to me that there's probably a pretty
easy way to go about getting started on this: IIRC, there are ~1,500
distinct method names in the core image.  If I do a count of how many
times my code is calling any of those methods, that should pop out what,
for my code, is the low hanging fruit.  The long-tail of say 1-5 calls
for the lesser used methods are the tedious work that will take more
effort for me to sort through.  We could use my 'short list' to at least
provide a starting point and using these most frequently called methods
you could scan through the list and could say 'hey, why are you calling
X instead of Y?' or maybe you'd get some visibility in the sense of
'wow, I didn't think that was being used'.  Hmm... I've got some
analysis to do...

> Cheers,
> Juan Vuletich





From hannes.hirzel at gmail.com  Sun Jul 19 18:01:22 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 23:01:22 +0000
Subject: [Cuis] Baseline version?
Message-ID: <CAGQxfVg7XkxDx0GXRzbM-g-efzvVKeafy3H5DzNJdjkzTwxDUg@mail.gmail.com>

On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Sun, 19 Jul 2015 11:20:19 -0300
....
> I'd like to propose a simpler model based on the Smalltalk Way.
>
> We take any stable revision, call it a version, give it a Baseline Version
> Number (could be just the development version number).

I'd like to suggest to label just the current version as a "baseline".

It would not need a long description, just a few keywords regarding
major changes like the addition of the FileMan package with a
reference to the description of it.

The last one
http://www.jvuletich.org/Cuis/CuisReleaseNotes.html

had

New in Cuis 4.2 (released July 25, 2013)

    Packages now have dependencies

    Package loading greatly enhanced

    Moved non-essential stuff to optional packages. Cuis is now below
500 classes and 100kLOC. Reduction was about 25%

    Many bugfixes, and minor enhancements and cleanup


So this one would have

New in Cuis 4.3 (released July 25, 2015)

     Many bugfixes, and minor enhancements and cleanup

     Addition of FileMan

    .....................

    .......................


    .....................

    .......................



And then after testing various packages on it
another baseline at the end of the year with a release document.

New in Cuis 4.4 (released December 31, 2015)

     Many bugfixes, and minor enhancements and cleanup

    .....................

    .....................

    .......................


    .....................

    .......................

    .....................

    .......................


More text as we will be more aware of the changes.



> Each Baseline
> Release has a release document which describes major changes since the
> previous baseline.  This document is a light-weight description.
>
> Each baseline release starts a new fork.  The only changes to the particular
> baseline release are bug fixes.
>
> Nice users test their packages and likewise fork a Package Release which
> matches a Baseline Release.  This fork also only changes with bug fixes, and
> only in synch with its particular baseline.  Baseline packages Feature the
> baseline release.
>
> So we forge ahead as usual, once in a while we say "enough has changed that
> we should re-baseline", do a new Baseline Release, test and release our
> Package Releases, then again move on forward.
>
> Anyone can now pick any baseline release, require any associated packages,
> and ship/demo without fear.
>
> Anyone with the time, energy, and interest can document baseline APIs to
> whatever level they feel comfortable.
>
> Anyone can forge on ahead with the latest revision(s) with the usual "here
> be dragons, but also gold".
>
> $0.02
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Sun Jul 19 18:52:33 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 23:52:33 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1424720606.2231.10.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
Message-ID: <CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>

On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> On Mon, 23 Feb 2015 08:38:44 +0000
>> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>
>> > As Casey writes "The hard part is time and energy to do so."
>> >
>> > So what can be done with minimal effort and big impact?
>>
>> Looking around, I see that I could make some simple naming changes for
>> test cases.
>>
>> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>>   testExampleHighlevel -> testNaclHiglLevelAPI
>>   textExampleLowLevel -> testNaclLowLevelAPI
>>
>> We could use other words, but API is shorter than Usage, Example,
>> Interface.
>>
>> Having specific test names end in 'API' would clue me in.
>>
>> Adding 'Nacl' means I can use the existing message finder to search for
>> 'api' and note testNacl*API methods.  This lets me find API tests specific
>> to Nacl.
>>
>> And we can do this as I get the chance.
>>
>> Other suggestions?
>
> I started playing around with a couple of example test cases to see what
> I ran into and came up with a distinct class to store all of these per
> test category (i.e. under Test-Files a class ApiFile which could have a
> method testWriteTextFile)  The rationale was that it might make sense to
> keep these test cases separate from traditional test cases which are
> free to make calls that users of the class (i.e. who are calling the
> supported API) should not.

Phil,

where do you keep this class ApiFile?

regards

Hannes


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



From hannes.hirzel at gmail.com  Sun Jul 19 18:57:25 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 23:57:25 +0000
Subject: [Cuis] Where are SUnit tests and how do I get them?
Message-ID: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>

Hello

In the current image when I open the SUnit browser no tests appear.


I assume the SUnit tests now in

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st

?

Are all tests there?

An snippet how to load them in the 'Useful Expression Workspace' would be fine.

Regards
Hannes



From pbpublist at gmail.com  Sun Jul 19 19:39:31 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 20:39:31 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150719131838.7d00ce57192818d00c38262c@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
Message-ID: <1437352771.6934.219.camel@gmail.com>

On Sun, 2015-07-19 at 13:18 -0700, Ken.Dickey wrote:
> On Sun, 19 Jul 2015 11:20:19 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
> 
> > As a bottom line, let me repeat: This is too big for me to do it. 
> > Please, folks, start documenting the APIs you most care about.
> 
> Let me repeat, "you don't have to do it".
> 

I would agree that *Juan* doesn't need to do much of anything at this
stage, but not that it doesn't need to be done.  If and when it does get
done, if he disregards it, it will have been a futile exercise.  So I'd
appreciate it if we could come to an agreement as to whether or not I
should bother...

> I'd like to propose a simpler model based on the Smalltalk Way.
> 
> We take any stable revision, call it a version, give it a Baseline Version Number (could be just the development version number).  Each Baseline Release has a release document which describes major changes since the previous baseline.  This document is a light-weight description.
> 

While I agree that there should be periodic major releases, there are a
lot of things in motion between major releases that will either be
forgotten about or not considered major enough to call out in the major
version release notes.

The issue is what constitutes a major change?  If your code uses it it's
major, if mine uses it it's minor?  Coin toss?  Without a public API
what is considered major is either obvious (i.e. Morphic changes from
global to local coords or changing the File/Directory API so obviously
everything using them breaks) or arbitrary (sorry to hear that you
depended on that... but it wasn't major, now it's gone)  If the image
snapshot is considered the public API, then everything must be both
considered fair game to depend on and to change in the future which is
unmanageable.

Let's look at a few examples along the spectrum of what I'm talking
about:

1)  Things that hopefully we can all agree on as being obvious and
relatively stable.  We have a class called Morph.  Is it reasonable to
assume that that is going to be supported going forward?  How about the
#drawOn: method, is that going to be around for a while?  If Juan were
to randomly decide to change these, I'd expect there would be screaming
from anyone who has a significant amount of drawing code.

2) Multiple ways to do the same thing.  Morphs support stepping to do
animated drawing etc.  There are at least two different ways (one
seemingly obvious, one less so... both different from how things used to
work) currently to do stepping.  Should this be the case, or should we
just have one way we agree that everyone uses?  What is lost by giving
up the 2nd (and 3rd...) way(s)?  Currently, if Juan were to change *any*
of the approaches, it would probably break someones code.  Why not just
have one supported way for him to be concerned with?  (if you think this
doesn't happen, one of my pull requests in the last month was related to
this)

3) Questionable usage / edge cases.  Morph also has
#resumeAfterDrawError and #resumeAfterStepError.  Now taking a few
seconds to look at them (never used myself) they seem like Morphic
implementation details, but hey they're in the image and not even marked
private so I should feel free to make my code depend on them, right?
Conversely, Juan could look at them and decide 'no one would possibly
need these' and change/remove them at any time.

It seems to me that at least 1/2 of 2 and most use cases of 3 are
unnecessary issues waiting to, and eventually will, happen.  I
personally try to stick to depending on things that are in category 1 or
the obvious use case of 2.  But imagine my surprise when I discover as
the result of an update that something I was using was actually in
category 2 (less obvious, to me at least) or 3.  Sure, there's a lot of
gray area that isn't so clear cut, but shouldn't we at least try to
minimize the amount of breakage going forward when it can easily be
avoided or manage it via documentation/communication when it can't?

I'm not trying to restrict Juan in any way from making the changes he
thinks are important for Cuis.  His taste and direction have been
generally excellent and the reason I'm here!  If for example, he decides
that #drawOn: is no longer the way to do things or that even Morph
needed to go away, that's fine as long as what's going on gets
communicated.  However, a problem I think he faces right now is that he
doesn't know who's using / depending on what.

> Each baseline release starts a new fork.  The only changes to the particular baseline release are bug fixes.
> 
> Nice users test their packages and likewise fork a Package Release which matches a Baseline Release.  This fork also only changes with bug fixes, and only in synch with its particular baseline.  Baseline packages Feature the baseline release.
> 
> So we forge ahead as usual, once in a while we say "enough has changed that we should re-baseline", do a new Baseline Release, test and release our Package Releases, then again move on forward.
> 
> Anyone can now pick any baseline release, require any associated packages, and ship/demo without fear.
> 

What you are describing is an application development model, not a
platform development model.  It handles dependencies by ignoring them.
It really comes down to what is Cuis?  Is it:

1) a minimal Smalltalk that you play around with ideas / prototype
something in the short to intermediate term

2) a platform that you can take that idea you were playing around with,
and if it proves out, build something more substantial from for the
longer term

3) a completely experimental environment.  Anything can change at any
time.  Supporting 1 is doable but 2 is doubtful.

Right now, Cuis is great at 1 but seems like it should be able to handle
both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
all, but who knows, others may disagree.  If others look at it
differently, I'd love to know how you look at Cuis.

> Anyone with the time, energy, and interest can document baseline APIs to whatever level they feel comfortable.
> 
> Anyone can forge on ahead with the latest revision(s) with the usual "here be dragons, but also gold".
> 
> $0.02
> -KenD
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From pbpublist at gmail.com  Sun Jul 19 19:43:29 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 20:43:29 -0400
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
Message-ID: <1437353009.6934.223.camel@gmail.com>

Hi Hannes,

On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
> >> On Mon, 23 Feb 2015 08:38:44 +0000
> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
> >>
> >> > As Casey writes "The hard part is time and energy to do so."
> >> >
> >> > So what can be done with minimal effort and big impact?
> >>
> >> Looking around, I see that I could make some simple naming changes for
> >> test cases.
> >>
> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
> >>   testExampleHighlevel -> testNaclHiglLevelAPI
> >>   textExampleLowLevel -> testNaclLowLevelAPI
> >>
> >> We could use other words, but API is shorter than Usage, Example,
> >> Interface.
> >>
> >> Having specific test names end in 'API' would clue me in.
> >>
> >> Adding 'Nacl' means I can use the existing message finder to search for
> >> 'api' and note testNacl*API methods.  This lets me find API tests specific
> >> to Nacl.
> >>
> >> And we can do this as I get the chance.
> >>
> >> Other suggestions?
> >
> > I started playing around with a couple of example test cases to see what
> > I ran into and came up with a distinct class to store all of these per
> > test category (i.e. under Test-Files a class ApiFile which could have a
> > method testWriteTextFile)  The rationale was that it might make sense to
> > keep these test cases separate from traditional test cases which are
> > free to make calls that users of the class (i.e. who are calling the
> > supported API) should not.
> 
> Phil,
> 
> where do you keep this class ApiFile?
> 

It's in Packages/Tests.pck.st package. After loading it will be listed
in the Tests-Files category.

> regards
> 
> Hannes
> 

Thanks,
Phil




From pbpublist at gmail.com  Sun Jul 19 19:50:10 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 20:50:10 -0400
Subject: [Cuis] Where are SUnit tests and how do I get them?
In-Reply-To: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>
References: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>
Message-ID: <1437353410.6934.229.camel@gmail.com>

Hannes,

On Sun, 2015-07-19 at 23:57 +0000, H. Hirzel wrote:
> Hello
> 
> In the current image when I open the SUnit browser no tests appear.
> 
> 
> I assume the SUnit tests now in
> 
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st
> 
> ?
> 
> Are all tests there?
> 
> An snippet how to load them in the 'Useful Expression Workspace' would be fine.
> 

The main Cuis tests are in the Packages/Tests.pck.st file I mentioned in
my previous reply.  Additionally, many of the 3rd party packages also
have optional tests (usually <PackageName>Tests.pck.st or something
similar) which can be loaded.  They don't get loaded by default so you
need to open a file browser, navigate to them, and install the
package(s).

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





From pbpublist at gmail.com  Sun Jul 19 20:01:38 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 21:01:38 -0400
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
	<CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>
Message-ID: <1437354098.6934.240.camel@gmail.com>

On Sun, 2015-07-19 at 20:21 +0000, H. Hirzel wrote:
> If I take a current image (18 Jul 2015, 4.2-2424)  I get the same result
> 
> 
> a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy #at:ifAbsent:)
> 
> All the FileMan additions are not listed. Maybe because they keep
> their original time stamp, not the time stamp of the addition to
> Squeak.
> 

Right, the timestamp will reflect when they were last edited rather than
when they were loaded into the image.

> And the recent change on #compilerClass does not show up.
> 

Same situation: #compilerClass while only recently re-added to the
image, hasn't actually been changed since it was removed and added back
so it still shows an older timestamp.

It sounds like you're looking for more of an image diff to see what
classes/methods changed between timer period X and Y?  This isn't
something that currently exists in an easy to use form that I'm aware
of.
 
> --HH
> 
> On 7/19/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > If I use this to find out which methods have a time stamp date
> > indicating a change after the 1st of January 2015 in a pristine Cuis
> > 4.2-2243 (17 April 2015) image I find out that only the
> >
> > #postCopy method was changed (probably added) in nearly all classes.
> >
> > If I change the base line date to 1st of January 2014 I get
> >
> > a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
> > #at:ifAbsent:)
> > as changed/updated methods (i.e. methods which have a time stamp in
> > this period).
> >
> > Of course this assumes that a method gets a time stamp when changed.
> > Many methods have nil as a time stamp.
> >
> >
> > Could somebody from the list check this please?
> >
> >
> > |date coll baseLineDate dt  updatedMethods |
> >
> > baseLineDate := Date year: 2014 month: 1 day: 1.
> > coll := OrderedCollection new.
> >
> > Smalltalk allClasses do: [ :cls |
> > cls allSelectors do: [ :sel |
> > dt := VersionsBrowser timeStampFor:  sel class: Dictionary reverseOrdinal:
> > 1.
> >
> > dt notNil ifTrue: [
> > date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
> > ]) or: [ch = $:]] .
> > (date = '') ifFalse:
> > 	[date := Date fromString: date.
> > 		(date > baseLineDate) ifTrue: [coll add: (Association key:
> > (Association key: cls value: sel) value: date)
> > ]]].
> >
> > ]].
> >
> > updatedMethods := Set new.
> > coll do: [ :elem | updatedMethods add: (elem key value)].
> > coll inspect.
> > updatedMethods inspect
> >
> >
> >
> >
> > On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> >> On 7/16/2015 11:49 AM, H. Hirzel wrote:
> >>> Hello
> >>>
> >>> I'd like to do a query finding out about the time stamp of  source
> >>> code changes of all methods in the Cuis image and then do a list with
> >>> the following four columns
> >>>
> >>>
> >>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
> >>> DateOfChange
> >>>
> >>> Help is appreciated.
> >>>
> >>> Hannes
> >>
> >> Check #timeStampFor:class:reverseOrdinal: and in general
> >> #annotationForSelector:ofClass:
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
> >
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Sun Jul 19 20:13:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 19 Jul 2015 21:13:35 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55ABA6A2.5090607@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>,
	<55ABA6A2.5090607@jvuletich.org>
Message-ID: <55AC4B3F.19938.1F92268@dnorton.mindspring.com>

On 19 Jul 2015 at 10:31, Juan Vuletich wrote:

> On 7/18/2015 3:37 PM, Dan Norton wrote:
> > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
> >
> >> Hi Folks,
> >>
> >> It is not too hard to build new StrikeFonts. You need to build,
> by
> >> hand,
> >> files like the ones in here:
> >>
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> >> p
> >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
> with
> >> this method and the files in this zip that built the existing
> >> instances
> >> of StrikeFont. Not sure.
> >>
> > That's intrigueing but I can't reproduce it. Maybe the .bmp but
> where did you get the .txt?
> >
> >   - Dan
> 
> I wrote them with a text editor. Check #installDejaVu2 and really
> try to 
> understand how StrikeFonts work and how they are built with this
> method. 
> Maybe you'll become enlightened.
> 

A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name, and several scalars. 
StrikeFont class methods create fonts by processing file pairs assumed to be in the 
"AAFonts" subdirectory. For example:

DejaVu Sans Oblique 14.bmp
DejaVu Sans Oblique 14.txt

Is one such pair providing the italic (oblique) style for 14-point size. There is a pair for every 
font size and style: base, bold, italic, and bold italic. Therefore a font such as "DejaVu Sans" 
which is available in the size interval 5 to 24 requires 160 files. The file names are stylized 
and encoded in the StrikeFont class methods.

Glyphs come from the .bmp file. The .txt file is a string of numbers; the first three specify 
pointSize, ascent, and	descent. The rest of the numbers in the .txt file are used to form the 
xTable, which is the index into the glyphs for a character. The characterToGlyphMap is an 
array of 256 entries which map a character's ascii value to the xTable and thence to the 
glyphs.

The bold, italic, and bold italic styles are stashed as derivatives of the base and not 
selectable from the current menus.

StrikeFont is a subclass of AbstractFont, which has class variables AvailableFonts and 
DefaultFont.

If it can't find a file, StrikeFont will loop.

In regard to creating the .bmp and .txt files, you say, "I wrote them with a text editor." Please 
tell me which text editor you used. None of mine do that.

 - Dan

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

From pbpublist at gmail.com  Sun Jul 19 20:21:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 21:21:01 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBY7YtLCJwVSOM3w58shed-YcnON=BL2WD2xM6EAMVbn2A@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<CAJBxtBY7YtLCJwVSOM3w58shed-YcnON=BL2WD2xM6EAMVbn2A@mail.gmail.com>
Message-ID: <1437355261.6934.252.camel@gmail.com>

On Sun, 2015-07-19 at 18:02 +0200, Peter van Rooijen wrote:
> Hey all,
> 
> 
> Just 2 cents from a Cuis noob:
> 
> 
> 1. Releases... since this stuff is not being sold for money and not
> being distributed using off-line media, what use does a "release"
> have? I like that stuff gets improved as often as possible. I believe
> that the things that get improved the most often, have the best chance
> of becoming something really good.
> 

It's more a function of managing the dependent code bases than anything
else.  One's view of 'improved as often as possible' changes when said
improvements break things you are depending on without warning.

> 
> So, I am for adopting practices that increase the number of
> improvements. Practices that decrease the number of deteriorations
> seem helpful as well. See below if you wonder what my point is ;-).
> 
> 
> 2. Public vs private API. Stable APIs are nice, if you can get them.
> If you have authors who develop a base, and other authors who (have
> to) develop ON that base, you need stable APIs, or you will lose the
> authors dependent on your base.
> 

Yup.  See Hannes' original comments that started this thread.  I chimed
in because I've been bitten by this several times.  And I'm sure there
are others who don't participate in the lists.  At the same time, I
recognize that there are others like Ken who don't have an issue.  It's
just a discussion that needed to be had and a decision reached whether
or not something needs to be done, and if so what.

> 
> So, do we really have those different author groups? Somehow I doubt
> it. I recently changed the scoping rules for shared variables (I think
> they're done wrong in the base image). I could change what I wanted
> easily. So I think I am not in some outsider author group. Instead I
> am happy that I could change what I wanted without needing anyone's
> approval or cooperation.
> 

We absolutely do.  I fall into several categories: I occasionally submit
changes to 'core' Cuis, work on several add-on frameworks (OMeta and
OpenGL are currently my main focuses on that front), and have a
large-ish base of my own code that I'm developing and maintaining.

The issue isn't one of permission as much as it is of communicating to
those downstream what is considered stable/supported.  Feel free to
change anything you want, just don't be surprised if the next release
breaks your changes.  But what do you do when you're trying to write
something that either won't break in the next release or at least have
some indication before hand what you might run into...

> 
> Suppose we were making money from outside author groups who want us to
> keep certain APIs stable. For the right price, I would be happy to
> provide that for them. In the mean time, I can live with free. Free to
> change what I want, free to use without paying, and others free to
> change what I am building on (sometimes frustrating).
> 

That definitely makes sense when you're talking about things like LTS
(Long Term Support) versions etc.  Free and stable are not mutually
exclusive.

> 
> 3. Maybe what will help everybody is something that prevents
> functionality from being lost, especially *unintentionally*. This can
> include certain APIs as well. So what if an author who values a
> certain API, could invest some of his own time/money, to protect that
> API? What if he could write a software component (let's say a class)
> that was able to detect whenever an image did not provide the desired
> API? What if he could submit that class, and everybody who cared about
> not breaking that API, could use that class to see if perhaps they
> broke it?
> 
> 
> 4. I believe the idea could be generalized to include any feature of
> (the code in) an image for which presence or absence (as may be the
> case) can be determined by such a class. Bugs could be reified as
> classes, and the presence or absence of the bug could be determined by
> that class. Feature requests could be reified as classes, and whether
> or not the feature had actually been implemented could be determined
> by that class.
> 
> 
> 5. The things I am proposing would basically be Feature Tests, and
> would be rather different from Unit Tests (which apply to a unit and
> which you want to all be green when you share your software with users
> of it). Feature Tests would apply to a system (not a unit) and simply
> indicate which features are and which features are not present in the
> system. Every "release" could then come with a) the assertion that all
> the Unit Tests passed b) a list of the Feature Tests that passed and
> those that did not.
> 

I believe what you are proposing is similar to what I proposed a few
months ago in the 'Canonical test cases?' thread.
http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-February/001747.html

> 
> 6. I think it would be pretty cool if people sent in feature requests
> in the form of Feature Tests, instead of messages to the mailing list
> (or the request tracker). So that anybody who (wished to impress
> somebody and) had some time on their hands, could then try to
> implement the functionality that made the Feature Test pass.
> 
> 
> Hope this helps somebody with something :)
> 
> 
> Cheers, Peter
> 
> On Sun, Jul 19, 2015 at 4:20 PM, Juan Vuletich <juan at jvuletich.org>
> wrote:
>         Hi Folks,
>         
>         (inline)
>         
>         On 7/17/2015 3:45 PM, Phil (list) wrote:
>                 ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>                                 Thank you Juan, for answering.
>                                 
>                                 At the moment I feel uncomfortable
>                                 using Cuis because it is currently
>                                 a quite fast moving target. I perceive
>                                 quite a number of API changes
>                                 though this might be wrong. But I do
>                                 not know because there are no
>                                 release notes which summarize it.
>                 I totally feel Hannes' pain having gone through it a
>                 few times myself
>                 over the years.  At the same time, I agree with Ken's
>                 point about not
>                 getting too bogged down in process since we're in the
>                 best position
>                 right now to break things for the better longer term.
>                 
>                         Yes, that's true. Besides, we don't have a
>                         specification of what is an
>                         API and what is not. So, almost any change can
>                         be considered an API change.
>                 That's the problem!  Both for you and us (it's a
>                 general 'Smalltalk Way'
>                 issue, not specific to Cuis)  I believe it is largely
>                 fixable without
>                 tons of documentation and tests: the use of private
>                 (categories or
>                 method naming convention).  Bernhard pointed out an
>                 existing capability
>                 a few months ago
>                 http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
>                 While I personally like the idea of private
>                 categories, one of these
>                 approaches should really be seriously considered.
>                 
>                 Other than a few specific examples (i.e. mostly the
>                 base data types
>                 including the Collection and Number class hierarchies
>                 which are pretty
>                 mature and don't change all that much anyway) I would
>                 guesstimate that
>                 <20% (probably closer to 10%) of the methods, and and
>                 unknown % of
>                 classes (a significantly larger fraction though),
>                 should even be
>                 considered public.  If things were indicated as
>                 private that would
>                 accomplish two things:
>                 
>                 1) We could construct some simple tooling (some
>                 combination of up-front
>                 warnings in the editor and/or a lint-type tester after
>                 the fact) that
>                 would allow people to identify problematic calls
>                 within their code.
>                 (i.e. just because it works now doesn't mean it always
>                 will if you keep
>                 calling X, Y, Z...)
>                 
>                 2) It would provide a way for people to know if
>                 something needs to be
>                 discussed.  i.e. 'In class X method Y is private but I
>                 need that type of
>                 functionality' so you would know that there's a need
>                 and could consider
>                 either making it public, and therefore supported, or
>                 rethinking its
>                 implementation if you'd like to offer a better public
>                 API solution.
>         
>         Ok. Doing something along these lines would be great. But
>         please note that it is a rather large amount of work. It is
>         not something I'm able or willing to do it alone. If you (any
>         of you all, not just Phil) wants to start defining the API for
>         any part of the system or optional packages, please start
>         doing it and send the changesets to the list. If we get this
>         working, I'll start the tools you mention.
>         
>         <slowly diverging into OT rant>
>         
>         On the other hand (and please forgive me if this kills a bit
>         of momentum), I don't really think we are changing APIs that
>         much. And I don't think we'll be doing it any more in the
>         future than we do today, at least in the base image. I hope to
>         see most of the activity and incompatible changes to happen in
>         optional packages, and affecting package dependencies... Mhhh,
>         now that I write this I think that it doesn't really go
>         against the idea of defining APIs. Maybe APIs in the base
>         image will almost never change or be a problem, but packages
>         should provide APIs too... Optional packages will (I hope!)
>         always be improving, and new ones will appear all the time.
>         
>         If all this work, the Cuis will be a lot less about my
>         personal effort and coding style, and the packages maintained
>         by each one of us will become the main characters in this
>         story. And this will be a very good thing. The base image
>         should be about providing a good base for doing the really
>         interesting stuff on top...
>         
>         Let me tell you a bit about how Cuis got started. Many years
>         ago I did my thesis on audio/music processing. The I wanted to
>         turn that into a novel and fun application for musicians (both
>         pros and anyone willing to play with sound). I started to
>         think about how a good GUI for that could be, giving the
>         feeling of modifying sound by direct manipulation of it, as if
>         it was clay, as if it was visual and not just auditory. Well,
>         that was the start of my questioning of the whole GUI business
>         and Morphic 3. And it became clear to me that Squeak had
>         turned into something that was not the best possible
>         environment to do all this. The idea of "fixing" Squeak, and
>         thus make Cuis, was born. So, Cuis was not and end in itself,
>         but a means for allowing experimentation, freedom to build
>         applications in new styles, etc.
>         
>         (The idea that Cuis is a truer Smalltalk-80 than Squeak or any
>         other came later, as an observation on facts.)
>         
>         So, when the moment comes when Cuis stabilizes a bit, and
>         interest moves to packages and applications built by all us,
>         Cuis will start to fulfill its original objective.
>         
>         </slowly diverging into OT rant>
>         
>                         ...
>                         The problem, I think, is not identifying well
>                         defined Cuis releases. The
>                         problem is knowing how updates could affect
>                         your code
>                 By narrowing the scope of what the public API is using
>                 private
>                 designators, this dramatically reduces what you need
>                 to be concerned
>                 with on this front.  It's part of the reason that
>                 Apple, Google, and
>                 even Microsoft are so adamant about public APIs these
>                 days.  They dealt
>                 with the pain of even major developers depending on
>                 private APIs for
>                 decades. It's only been in the last 10 years or so
>                 that they've been
>                 able to dig themselves out from under this issue.
>                 
>                 This gets back to the 'Smalltalk Way' issue I
>                 referenced earlier.  The
>                 attitude of 'you have the source, play around, have
>                 fun!' has morphed
>                 into 'everything is a public API!  there are no rules!
>                 isn't this
>                 great?'  Well no, it's not great.  It makes life
>                 impossible for image
>                 maintainers (Squeak has been in a coma for the last
>                 decade or so as the
>                 result of trying to keep everyone happy... yet no one
>                 seems to be) and
>                 miserable for those who are trying to keep code
>                 running on it (stuff
>                 still breaks all the time.)
>         
>         Yes.
>         
>                 I personally believe the minimalism and simplicity
>                 that Cuis is based on
>                 has the best long term prospects but we have to get
>                 out of this
>                 'everything is public' mindset.  Sure, we have all the
>                 source: look at
>                 it, learn from it, poke around, refactor it, submit
>                 fixes, etc.  But
>                 there needs to be a manageable subset of it which is
>                 considered the
>                 'public API' that people can depend on to write
>                 frameworks and apps on
>                 top of that is relatively stable longer term.  Let's
>                 start defining what
>                 that is and backfill changes to the public API (which
>                 will happen from
>                 time to time as we don't want things to be completely
>                 static) with tests
>                 and documentation so you can focus your efforts on
>                 where they matter
>                 most and you get the most enjoyment from.
>         
>         I fully agree and support this.
>         Maybe an alternative to yet-another-convention-on-categories
>         could be to mark public methods with a pragma, or make them
>         send 'self publicAPI' or such... This could be better for the
>         tools, also.
>         
>                 ...
>                         I don't have that either. I run the tests from
>                         time to time (I'll start
>                         doing it before any commit, and add the xml
>                         report to the rep). But this
>                         is not the most important reason why Cuis is
>                         solid. Cuis is very
>                         reliable because:
>                 reliable != stable
>         
>         ;)
>         
>                         - I'm not too bad as a coder.
>                         - I do my own code revisions at least one day
>                         after each change.
>                         - I use Cuis every day, and spot most problems
>                         in the updates, before
>                         commtting them to the repo.
>                         - I really, really care about code quality.
>                         - I think Cuis keeps Smalltalk-80 and its
>                         ideals alive. And I think that
>                         is a big responsibility, given how important I
>                         think Smalltalk-80 is.
>                         
>                 Agree to all this and more.  Cuis would not be where
>                 it is without your
>                 continued effort and diligence. (i.e. setting aside
>                 that you obviously
>                 created it, if you had just tossed it out into the
>                 world and let it go
>                 at best it would have started looking something like
>                 Squeak or Pharo by
>                 now.  It's a lot of effort over the long term to
>                 *keep* it small and
>                 focused.  THANK YOU JUAN!)
>         
>         Thanks for your nice words, Phil. I really appreciate that you
>         all accept this rather restrictive dev model for the base
>         image, in contrast with a more open trunk style. Hopefully, as
>         the base image becomes stable and almost irrelevant, this will
>         be each time less of a problem.
>         
>                         So, I suggest running your tests when updating
>                         your image, or migrating
>                         your code to an updated image.
>                 +1 to tests as they do help quite a bit and are a very
>                 good practice.
>                 Just be judicious in what/where you test (I personally
>                 don't subscribe
>                 to the TDD approach where you spend your days mostly
>                 writing tests.
>                 That's just admitting defeat in that you spend all day
>                 writing
>                 executable documentation.)
>         
>         <OT>
>         
>         I don't subscribe to "extreme" TDD either. To me design is a
>         creative activity, both technical and artistic. It should be
>         "driven" by creativity and intelligence, not by a process. Any
>         xDD process is admitting defeat on design itself!
>         
>         </OT>
>         
>                         In any case, I think this doesn't answer your
>                         concerns. What you need is
>                         some way to know which updates could affect
>                         you, to review them in
>                         detail, and understanding their effect on your
>                         code. A list of the
>                         affected classes and/or methods for each
>                         update makes no sense. Cuis can
>                         already show you that very easily. Perhaps
>                         each update should include:
>                         
>                         1) parts of the system that are affected:
>                         - Kernel
>                         - Compiler
>                         - Tools
>                         - Morphic
>                         - etc
>                         
>                         2) Level of risk involved
>                         - very unlikely to break code that depends on
>                         this part of the system
>                         - could perhaps break code that depends on
>                         this part of the system
>                         - will most likely break code that depends on
>                         this part of the system
>                         
>                         Or something like that.
>                         
>                         BTW, this is a very relevant topic for
>                         discussing on the mail list. Feel
>                         free to answer there if you agree.
>                 One final thought on this:  I suspect a major cause of
>                 people abandoning
>                 Cuis (and Smalltalk in general), behind the 'it's too
>                 different from
>                 what I'm used to'/'not mainstream' reaction, is the
>                 instability of its
>                 APIs.
>         
>         Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0
>         problem) is a PITA too...
>         
>         As a bottom line, let me repeat: This is too big for me to do
>         it. Please, folks, start documenting the APIs you most care
>         about.
>         
>         Cheers,
>         Juan Vuletich
>         
>         _______________________________________________
>         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 kbrown at mac.com  Sun Jul 19 22:21:29 2015
From: kbrown at mac.com (Ken G. Brown)
Date: Sun, 19 Jul 2015 21:21:29 -0600
Subject: [Cuis]  Baseline version?
In-Reply-To: <mailman.94.1437354099.18328.cuis_jvuletich.org@jvuletich.org>
References: <mailman.94.1437354099.18328.cuis_jvuletich.org@jvuletich.org>
Message-ID: <4CA2DB35-1A26-46CE-B5D1-ACB50DC642B0@mac.com>

Craig Latta has a nice write up about his decent looking versioning system for Spoon: http://netjam.org/versions/

Ken G. Brown

> Date: Sun, 19 Jul 2015 23:01:22 +0000
> From: "H. Hirzel" <hannes.hirzel at gmail.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Subject: [Cuis] Baseline version?
> Message-ID:
>    <CAGQxfVg7XkxDx0GXRzbM-g-efzvVKeafy3H5DzNJdjkzTwxDUg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
>> On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
>> On Sun, 19 Jul 2015 11:20:19 -0300
> ....
>> I'd like to propose a simpler model based on the Smalltalk Way.
>> 
>> We take any stable revision, call it a version, give it a Baseline Version
>> Number (could be just the development version number).
> 
> I'd like to suggest to label just the current version as a "baseline".
> 
> It would not need a long description, just a few keywords regarding
> major changes like the addition of the FileMan package with a
> reference to the description of it.
> 
> The last one
> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
> 
> had
> 
> New in Cuis 4.2 (released July 25, 2013)
> 
>    Packages now have dependencies
> 
>    Package loading greatly enhanced
> 
>    Moved non-essential stuff to optional packages. Cuis is now below
> 500 classes and 100kLOC. Reduction was about 25%
> 
>    Many bugfixes, and minor enhancements and cleanup
> 
> 
> So this one would have
> 
> New in Cuis 4.3 (released July 25, 2015)
> 
>     Many bugfixes, and minor enhancements and cleanup
> 
>     Addition of FileMan
> 
>    .....................
> 
>    .......................
> 
> 
>    .....................
> 
>    .......................
> 
> 
> 
> And then after testing various packages on it
> another baseline at the end of the year with a release document.
> 
> New in Cuis 4.4 (released December 31, 2015)
> 
>     Many bugfixes, and minor enhancements and cleanup
> 
>    .....................
> 
>    .....................
> 
>    .......................
> 
> 
>    .....................
> 
>    .......................
> 
>    .....................
> 
>    .......................
> 
> 
> More text as we will be more aware of the changes.
> 
> 
> 
>> Each Baseline
>> Release has a release document which describes major changes since the
>> previous baseline.  This document is a light-weight description.
>> 
>> Each baseline release starts a new fork.  The only changes to the particular
>> baseline release are bug fixes.
>> 
>> Nice users test their packages and likewise fork a Package Release which
>> matches a Baseline Release.  This fork also only changes with bug fixes, and
>> only in synch with its particular baseline.  Baseline packages Feature the
>> baseline release.
>> 
>> So we forge ahead as usual, once in a while we say "enough has changed that
>> we should re-baseline", do a new Baseline Release, test and release our
>> Package Releases, then again move on forward.
>> 
>> Anyone can now pick any baseline release, require any associated packages,
>> and ship/demo without fear.
>> 
>> Anyone with the time, energy, and interest can document baseline APIs to
>> whatever level they feel comfortable.
>> 
>> Anyone can forge on ahead with the latest revision(s) with the usual "here
>> be dragons, but also gold".
>> 
>> $0.02
>> -KenD
>> 
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> 
> 



From hannes.hirzel at gmail.com  Mon Jul 20 02:35:38 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 07:35:38 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AC4B3F.19938.1F92268@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
	<55ABA6A2.5090607@jvuletich.org>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
Message-ID: <CAGQxfVhxnkq00Qi7OhuQo3Lbvqb03nRJi2sFxkQxHVet2439jw@mail.gmail.com>

On 7/20/15, Dan Norton <dnorton at mindspring.com> wrote:
> On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>
>> On 7/18/2015 3:37 PM, Dan Norton wrote:
>> > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>> >
>> >> Hi Folks,
>> >>
>> >> It is not too hard to build new StrikeFonts. You need to build,
>> by
>> >> hand,
>> >> files like the ones in here:
>> >>
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> >> p
>> >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
>> with
>> >> this method and the files in this zip that built the existing
>> >> instances
>> >> of StrikeFont. Not sure.
>> >>
>> > That's intrigueing but I can't reproduce it. Maybe the .bmp but
>> where did you get the .txt?
>> >
>> >   - Dan
>>
>> I wrote them with a text editor. Check #installDejaVu2 and really
>> try to
>> understand how StrikeFonts work and how they are built with this
>> method.
>> Maybe you'll become enlightened.
>>
>
> A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name, and
> several scalars.
> StrikeFont class methods create fonts by processing file pairs assumed to be
> in the
> "AAFonts" subdirectory. For example:
>
> DejaVu Sans Oblique 14.bmp
> DejaVu Sans Oblique 14.txt
>
> Is one such pair providing the italic (oblique) style for 14-point size.
> There is a pair for every
> font size and style: base, bold, italic, and bold italic. Therefore a font
> such as "DejaVu Sans"
> which is available in the size interval 5 to 24 requires 160 files. The file
> names are stylized
> and encoded in the StrikeFont class methods.
>
> Glyphs come from the .bmp file. The .txt file is a string of numbers; the
> first three specify
> pointSize, ascent, and	descent. The rest of the numbers in the .txt file are
> used to form the
> xTable, which is the index into the glyphs for a character. The
> characterToGlyphMap is an
> array of 256 entries which map a character's ascii value to the xTable and
> thence to the
> glyphs.
>
> The bold, italic, and bold italic styles are stashed as derivatives of the
> base and not
> selectable from the current menus.
>
> StrikeFont is a subclass of AbstractFont, which has class variables
> AvailableFonts and
> DefaultFont.
>
> If it can't find a file, StrikeFont will loop.
>
> In regard to creating the .bmp and .txt files, you say, "I wrote them with a
> text editor." Please
> tell me which text editor you used. None of mine do that.
>
>  - Dan

What I used in the past is the StrikeFont bitmap editor which is in
Squeak. In MVC if I remember well. So an early version of Squeak (e.g.
3.8.1 Oct 2006)  is helpful.

These versions are very accessible these days  http://squeak.org/downloads/

--Hannes



From hannes.hirzel at gmail.com  Mon Jul 20 03:06:33 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:06:33 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1437353009.6934.223.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
Message-ID: <CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> Hi Hannes,
>
> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>> >>
>> >> > As Casey writes "The hard part is time and energy to do so."
>> >> >
>> >> > So what can be done with minimal effort and big impact?
>> >>
>> >> Looking around, I see that I could make some simple naming changes for
>> >> test cases.
>> >>
>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>> >>
>> >> We could use other words, but API is shorter than Usage, Example,
>> >> Interface.
>> >>
>> >> Having specific test names end in 'API' would clue me in.
>> >>
>> >> Adding 'Nacl' means I can use the existing message finder to search
>> >> for
>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>> >> specific
>> >> to Nacl.
>> >>
>> >> And we can do this as I get the chance.
>> >>
>> >> Other suggestions?
>> >
>> > I started playing around with a couple of example test cases to see
>> > what
>> > I ran into and came up with a distinct class to store all of these per
>> > test category (i.e. under Test-Files a class ApiFile which could have a
>> > method testWriteTextFile)  The rationale was that it might make sense
>> > to
>> > keep these test cases separate from traditional test cases which are
>> > free to make calls that users of the class (i.e. who are calling the
>> > supported API) should not.
>>
>> Phil,
>>
>> where do you keep this class ApiFile?
>>
>
> It's in Packages/Tests.pck.st package. After loading it will be listed
> in the Tests-Files category.


I loaded the class ApiFile only and I get 3 tests passed and 1 failure
in Cuis 2.4-2424.

Can you confirm this, Phil?

>> regards
>>
>> Hannes
>>
>
> Thanks,
> Phil
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis4.2-2424-ApiFile Test Screenshot from 2015-07-20 07:56:23.png
Type: image/png
Size: 127147 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/7a96c85d/attachment-0003.png>

From hannes.hirzel at gmail.com  Mon Jul 20 03:16:02 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:16:02 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
Message-ID: <CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>

The file testResults.xml which Juan added has

<testcase classname="ApiFile" name="testImagePNG01WriteToFile"
status="passed"/>
<testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
status="passed"/>
<testcase classname="ApiFile" name="testText01WriteToFile" status="passed"/>
<testcase classname="ApiFile" name="testText02ReadFromFile" status="passed"/>

So there is an issue of test setup which was not fullfilled in my case....
Might be a Linux Mint issue (access rights)

On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> Hi Hannes,
>>
>> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>> >>
>>> >> > As Casey writes "The hard part is time and energy to do so."
>>> >> >
>>> >> > So what can be done with minimal effort and big impact?
>>> >>
>>> >> Looking around, I see that I could make some simple naming changes
>>> >> for
>>> >> test cases.
>>> >>
>>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>>> >>
>>> >> We could use other words, but API is shorter than Usage, Example,
>>> >> Interface.
>>> >>
>>> >> Having specific test names end in 'API' would clue me in.
>>> >>
>>> >> Adding 'Nacl' means I can use the existing message finder to search
>>> >> for
>>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>>> >> specific
>>> >> to Nacl.
>>> >>
>>> >> And we can do this as I get the chance.
>>> >>
>>> >> Other suggestions?
>>> >
>>> > I started playing around with a couple of example test cases to see
>>> > what
>>> > I ran into and came up with a distinct class to store all of these per
>>> > test category (i.e. under Test-Files a class ApiFile which could have
>>> > a
>>> > method testWriteTextFile)  The rationale was that it might make sense
>>> > to
>>> > keep these test cases separate from traditional test cases which are
>>> > free to make calls that users of the class (i.e. who are calling the
>>> > supported API) should not.
>>>
>>> Phil,
>>>
>>> where do you keep this class ApiFile?
>>>
>>
>> It's in Packages/Tests.pck.st package. After loading it will be listed
>> in the Tests-Files category.
>
>
> I loaded the class ApiFile only and I get 3 tests passed and 1 failure
> in Cuis 2.4-2424.
>
> Can you confirm this, Phil?
>
>>> regards
>>>
>>> Hannes
>>>
>>
>> Thanks,
>> Phil
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis4.2-2424_Testfiles_on_LinuxMint_Screenshot from 2015-07-20 08:13:48.png
Type: image/png
Size: 36391 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/7a092b24/attachment-0003.png>

From hannes.hirzel at gmail.com  Mon Jul 20 03:22:41 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:22:41 +0000
Subject: [Cuis] Where are SUnit tests and how do I get them?
In-Reply-To: <1437353410.6934.229.camel@gmail.com>
References: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>
	<1437353410.6934.229.camel@gmail.com>
Message-ID: <CAGQxfVgbdhZasgBHydZ6ykFuu+=O5D9rP4+MZN=Nn1Gitj92dA@mail.gmail.com>

I got the tests, the way you describe. I only loaded class ApiFile,
see other thread.

--Hannes

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> Hannes,
>
> On Sun, 2015-07-19 at 23:57 +0000, H. Hirzel wrote:
>> Hello
>>
>> In the current image when I open the SUnit browser no tests appear.
>>
>>
>> I assume the SUnit tests now in
>>
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st
>>
>> ?
>>
>> Are all tests there?
>>
>> An snippet how to load them in the 'Useful Expression Workspace' would be
>> fine.
>>
>
> The main Cuis tests are in the Packages/Tests.pck.st file I mentioned in
> my previous reply.  Additionally, many of the 3rd party packages also
> have optional tests (usually <PackageName>Tests.pck.st or something
> similar) which can be loaded.  They don't get loaded by default so you
> need to open a file browser, navigate to them, and install the
> package(s).
>
>> Regards
>> Hannes
>>
>> _______________________________________________
>> 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 hannes.hirzel at gmail.com  Mon Jul 20 03:30:38 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:30:38 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
Message-ID: <CAGQxfVg==3cZfayb1xZXiT5pA8mkas9xE12LNHNLwO8cRMEvUg@mail.gmail.com>

On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> The file testResults.xml which Juan added has
>
> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testText01WriteToFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testText02ReadFromFile"
> status="passed"/>
>
> So there is an issue of test setup which was not fullfilled in my case....
> Might be a Linux Mint issue (access rights)

The debugger indicated that I need Graphics-Files-Additional and in
fact the package header says this.

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st#L1

'From Cuis 4.2 of 25 July 2013 [latest update: #2424] on 18 July 2015
at 7:09:24.325834 pm'!
'Description Please enter a description for this package '!
!provides: 'Tests' 1 28!
!requires: 'Graphics-Files-Additional' 1 nil nil!
!requires: 'Compression' 1 nil nil!


> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>>> Hi Hannes,
>>>
>>> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>>>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>>>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>>>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>>>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>>> >>
>>>> >> > As Casey writes "The hard part is time and energy to do so."
>>>> >> >
>>>> >> > So what can be done with minimal effort and big impact?
>>>> >>
>>>> >> Looking around, I see that I could make some simple naming changes
>>>> >> for
>>>> >> test cases.
>>>> >>
>>>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>>>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>>>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>>>> >>
>>>> >> We could use other words, but API is shorter than Usage, Example,
>>>> >> Interface.
>>>> >>
>>>> >> Having specific test names end in 'API' would clue me in.
>>>> >>
>>>> >> Adding 'Nacl' means I can use the existing message finder to search
>>>> >> for
>>>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>>>> >> specific
>>>> >> to Nacl.
>>>> >>
>>>> >> And we can do this as I get the chance.
>>>> >>
>>>> >> Other suggestions?
>>>> >
>>>> > I started playing around with a couple of example test cases to see
>>>> > what
>>>> > I ran into and came up with a distinct class to store all of these
>>>> > per
>>>> > test category (i.e. under Test-Files a class ApiFile which could have
>>>> > a
>>>> > method testWriteTextFile)  The rationale was that it might make sense
>>>> > to
>>>> > keep these test cases separate from traditional test cases which are
>>>> > free to make calls that users of the class (i.e. who are calling the
>>>> > supported API) should not.
>>>>
>>>> Phil,
>>>>
>>>> where do you keep this class ApiFile?
>>>>
>>>
>>> It's in Packages/Tests.pck.st package. After loading it will be listed
>>> in the Tests-Files category.
>>
>>
>> I loaded the class ApiFile only and I get 3 tests passed and 1 failure
>> in Cuis 2.4-2424.
>>
>> Can you confirm this, Phil?
>>
>>>> regards
>>>>
>>>> Hannes
>>>>
>>>
>>> Thanks,
>>> Phil
>>>
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis-4.2-2424_ApiFile_SUnit_test_result_Screenshot from 2015-07-20 08:21:33.png
Type: image/png
Size: 20022 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/2ed77677/attachment-0003.png>

From pbpublist at gmail.com  Mon Jul 20 03:33:57 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 04:33:57 -0400
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
Message-ID: <1437381237.2286.13.camel@gmail.com>

On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
> The file testResults.xml which Juan added has
> 
> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testText01WriteToFile" status="passed"/>
> <testcase classname="ApiFile" name="testText02ReadFromFile" status="passed"/>
> 
> So there is an issue of test setup which was not fullfilled in my case....
> Might be a Linux Mint issue (access rights)
> 

I don't have the test in front of me right now but if I recall, the
setup code exists to create a temp directory in the same directory the
image was launched from to write the test files. (that was the best way
I could come up with to not introduce any platform-specific path
handling issues to the test)

If the setup code failed, then the test would have probably failed.  Did
you manually do anything or did it just work the 2nd time you ran it?
(if it re-ran successfully without you needing to do anything else, it
definitely sounds like a problem in the test setup.  If it were a rights
issue, it should have continued to fail.)

The good news is we're about to change all the file/directory handling
code so it needs to be updated anyway...

> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> Hi Hannes,
> >>
> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
> >>> >>
> >>> >> > As Casey writes "The hard part is time and energy to do so."
> >>> >> >
> >>> >> > So what can be done with minimal effort and big impact?
> >>> >>
> >>> >> Looking around, I see that I could make some simple naming changes
> >>> >> for
> >>> >> test cases.
> >>> >>
> >>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
> >>> >>
> >>> >> We could use other words, but API is shorter than Usage, Example,
> >>> >> Interface.
> >>> >>
> >>> >> Having specific test names end in 'API' would clue me in.
> >>> >>
> >>> >> Adding 'Nacl' means I can use the existing message finder to search
> >>> >> for
> >>> >> 'api' and note testNacl*API methods.  This lets me find API tests
> >>> >> specific
> >>> >> to Nacl.
> >>> >>
> >>> >> And we can do this as I get the chance.
> >>> >>
> >>> >> Other suggestions?
> >>> >
> >>> > I started playing around with a couple of example test cases to see
> >>> > what
> >>> > I ran into and came up with a distinct class to store all of these per
> >>> > test category (i.e. under Test-Files a class ApiFile which could have
> >>> > a
> >>> > method testWriteTextFile)  The rationale was that it might make sense
> >>> > to
> >>> > keep these test cases separate from traditional test cases which are
> >>> > free to make calls that users of the class (i.e. who are calling the
> >>> > supported API) should not.
> >>>
> >>> Phil,
> >>>
> >>> where do you keep this class ApiFile?
> >>>
> >>
> >> It's in Packages/Tests.pck.st package. After loading it will be listed
> >> in the Tests-Files category.
> >
> >
> > I loaded the class ApiFile only and I get 3 tests passed and 1 failure
> > in Cuis 2.4-2424.
> >
> > Can you confirm this, Phil?
> >
> >>> regards
> >>>
> >>> Hannes
> >>>
> >>
> >> Thanks,
> >> Phil
> >>
> >>
> >> _______________________________________________
> >> 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 hannes.hirzel at gmail.com  Mon Jul 20 03:45:53 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:45:53 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1437381237.2286.13.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
	<1437381237.2286.13.camel@gmail.com>
Message-ID: <CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>

The reason was

I only cherry picked the ApiFile class by manual loading.

After adding  Graphics-Files-Additional.pck.st manually it worked.

Another interesting test case is to write out a StrikeFont to the file
system in the proper
canonical export format (bmp and text) with a new name  and read it
back as a new font.

--Hannes

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
>> The file testResults.xml which Juan added has
>>
>> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
>> status="passed"/>
>> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
>> status="passed"/>
>> <testcase classname="ApiFile" name="testText01WriteToFile"
>> status="passed"/>
>> <testcase classname="ApiFile" name="testText02ReadFromFile"
>> status="passed"/>
>>
>> So there is an issue of test setup which was not fullfilled in my
>> case....
>> Might be a Linux Mint issue (access rights)
>>
>
> I don't have the test in front of me right now but if I recall, the
> setup code exists to create a temp directory in the same directory the
> image was launched from to write the test files. (that was the best way
> I could come up with to not introduce any platform-specific path
> handling issues to the test)
>
> If the setup code failed, then the test would have probably failed.  Did
> you manually do anything or did it just work the 2nd time you ran it?
> (if it re-ran successfully without you needing to do anything else, it
> definitely sounds like a problem in the test setup.  If it were a rights
> issue, it should have continued to fail.)
>
> The good news is we're about to change all the file/directory handling
> code so it needs to be updated anyway...
>
>> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >> Hi Hannes,
>> >>
>> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>> >>> >>
>> >>> >> > As Casey writes "The hard part is time and energy to do so."
>> >>> >> >
>> >>> >> > So what can be done with minimal effort and big impact?
>> >>> >>
>> >>> >> Looking around, I see that I could make some simple naming changes
>> >>> >> for
>> >>> >> test cases.
>> >>> >>
>> >>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>> >>> >>
>> >>> >> We could use other words, but API is shorter than Usage, Example,
>> >>> >> Interface.
>> >>> >>
>> >>> >> Having specific test names end in 'API' would clue me in.
>> >>> >>
>> >>> >> Adding 'Nacl' means I can use the existing message finder to
>> >>> >> search
>> >>> >> for
>> >>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>> >>> >> specific
>> >>> >> to Nacl.
>> >>> >>
>> >>> >> And we can do this as I get the chance.
>> >>> >>
>> >>> >> Other suggestions?
>> >>> >
>> >>> > I started playing around with a couple of example test cases to see
>> >>> > what
>> >>> > I ran into and came up with a distinct class to store all of these
>> >>> > per
>> >>> > test category (i.e. under Test-Files a class ApiFile which could
>> >>> > have
>> >>> > a
>> >>> > method testWriteTextFile)  The rationale was that it might make
>> >>> > sense
>> >>> > to
>> >>> > keep these test cases separate from traditional test cases which
>> >>> > are
>> >>> > free to make calls that users of the class (i.e. who are calling
>> >>> > the
>> >>> > supported API) should not.
>> >>>
>> >>> Phil,
>> >>>
>> >>> where do you keep this class ApiFile?
>> >>>
>> >>
>> >> It's in Packages/Tests.pck.st package. After loading it will be listed
>> >> in the Tests-Files category.
>> >
>> >
>> > I loaded the class ApiFile only and I get 3 tests passed and 1 failure
>> > in Cuis 2.4-2424.
>> >
>> > Can you confirm this, Phil?
>> >
>> >>> regards
>> >>>
>> >>> Hannes
>> >>>
>> >>
>> >> Thanks,
>> >> Phil
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From pbpublist at gmail.com  Mon Jul 20 04:43:58 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 05:43:58 -0400
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
	<1437381237.2286.13.camel@gmail.com>
	<CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>
Message-ID: <1437385438.2286.33.camel@gmail.com>

On Mon, 2015-07-20 at 08:45 +0000, H. Hirzel wrote:
> The reason was
> 
> I only cherry picked the ApiFile class by manual loading.
> 
> After adding  Graphics-Files-Additional.pck.st manually it worked.
> 

That would do it.  By adding 'manually' do you mean that you didn't have
the Graphics package downloaded at the time you loaded Tests?  That's
the only reason I can think of that the package manager wouldn't have
loaded Graphics for you automatically given the dependency.

> Another interesting test case is to write out a StrikeFont to the file
> system in the proper
> canonical export format (bmp and text) with a new name  and read it
> back as a new font.
> 

That's the sort of thing I was getting at with these tests: if there is
some useful bit of work that you need to be able to do (especially
something larger than a unit test and/or crossing package boundaries),
to create a test for it to help Juan understand the functionality we're
using.  This was one way I came up with to try to get to some sort of
agreed upon public API.  In retrospect, I probably put the cart before
the horse as doing all of these tests will take considerably longer than
initially flagging methods considered to be public.  But hopefully you
can see how doing both could complement each other.  To reiterate: this
work is on us to do up front, Juan would just review and commit.

> --Hannes
> 
> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> > On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
> >> The file testResults.xml which Juan added has
> >>
> >> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
> >> status="passed"/>
> >> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
> >> status="passed"/>
> >> <testcase classname="ApiFile" name="testText01WriteToFile"
> >> status="passed"/>
> >> <testcase classname="ApiFile" name="testText02ReadFromFile"
> >> status="passed"/>
> >>
> >> So there is an issue of test setup which was not fullfilled in my
> >> case....
> >> Might be a Linux Mint issue (access rights)
> >>
> >
> > I don't have the test in front of me right now but if I recall, the
> > setup code exists to create a temp directory in the same directory the
> > image was launched from to write the test files. (that was the best way
> > I could come up with to not introduce any platform-specific path
> > handling issues to the test)
> >
> > If the setup code failed, then the test would have probably failed.  Did
> > you manually do anything or did it just work the 2nd time you ran it?
> > (if it re-ran successfully without you needing to do anything else, it
> > definitely sounds like a problem in the test setup.  If it were a rights
> > issue, it should have continued to fail.)
> >
> > The good news is we're about to change all the file/directory handling
> > code so it needs to be updated anyway...
> >
> >> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> >> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> >> Hi Hannes,
> >> >>
> >> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
> >> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
> >> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
> >> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
> >> >>> >>
> >> >>> >> > As Casey writes "The hard part is time and energy to do so."
> >> >>> >> >
> >> >>> >> > So what can be done with minimal effort and big impact?
> >> >>> >>
> >> >>> >> Looking around, I see that I could make some simple naming changes
> >> >>> >> for
> >> >>> >> test cases.
> >> >>> >>
> >> >>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
> >> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
> >> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
> >> >>> >>
> >> >>> >> We could use other words, but API is shorter than Usage, Example,
> >> >>> >> Interface.
> >> >>> >>
> >> >>> >> Having specific test names end in 'API' would clue me in.
> >> >>> >>
> >> >>> >> Adding 'Nacl' means I can use the existing message finder to
> >> >>> >> search
> >> >>> >> for
> >> >>> >> 'api' and note testNacl*API methods.  This lets me find API tests
> >> >>> >> specific
> >> >>> >> to Nacl.
> >> >>> >>
> >> >>> >> And we can do this as I get the chance.
> >> >>> >>
> >> >>> >> Other suggestions?
> >> >>> >
> >> >>> > I started playing around with a couple of example test cases to see
> >> >>> > what
> >> >>> > I ran into and came up with a distinct class to store all of these
> >> >>> > per
> >> >>> > test category (i.e. under Test-Files a class ApiFile which could
> >> >>> > have
> >> >>> > a
> >> >>> > method testWriteTextFile)  The rationale was that it might make
> >> >>> > sense
> >> >>> > to
> >> >>> > keep these test cases separate from traditional test cases which
> >> >>> > are
> >> >>> > free to make calls that users of the class (i.e. who are calling
> >> >>> > the
> >> >>> > supported API) should not.
> >> >>>
> >> >>> Phil,
> >> >>>
> >> >>> where do you keep this class ApiFile?
> >> >>>
> >> >>
> >> >> It's in Packages/Tests.pck.st package. After loading it will be listed
> >> >> in the Tests-Files category.
> >> >
> >> >
> >> > I loaded the class ApiFile only and I get 3 tests passed and 1 failure
> >> > in Cuis 2.4-2424.
> >> >
> >> > Can you confirm this, Phil?
> >> >
> >> >>> regards
> >> >>>
> >> >>> Hannes
> >> >>>
> >> >>
> >> >> Thanks,
> >> >> Phil
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> 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
> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From hannes.hirzel at gmail.com  Mon Jul 20 07:31:22 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:31:22 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1437385438.2286.33.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
	<1437381237.2286.13.camel@gmail.com>
	<CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>
	<1437385438.2286.33.camel@gmail.com>
Message-ID: <CAGQxfViPQp2vBYh_To2nU05A5LVDF9VoAML1SMXbYH6Fm5KJzw@mail.gmail.com>

I think both is valuable and we need both

1. Doing larger tests like the 4 tests you did in ApiFile. They show
typical use cases.

2. flagging methods considered to be public. This can be done with a
test as well.
    Just a long list of checking with respondsTo: if a methods exist.



On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-07-20 at 08:45 +0000, H. Hirzel wrote:
>> The reason was
>>
>> I only cherry picked the ApiFile class by manual loading.
>>
>> After adding  Graphics-Files-Additional.pck.st manually it worked.
>>
>
> That would do it.  By adding 'manually' do you mean that you didn't have
> the Graphics package downloaded at the time you loaded Tests?  That's
> the only reason I can think of that the package manager wouldn't have
> loaded Graphics for you automatically given the dependency.
>
>> Another interesting test case is to write out a StrikeFont to the file
>> system in the proper
>> canonical export format (bmp and text) with a new name  and read it
>> back as a new font.
>>
>
> That's the sort of thing I was getting at with these tests: if there is
> some useful bit of work that you need to be able to do (especially
> something larger than a unit test and/or crossing package boundaries),
> to create a test for it to help Juan understand the functionality we're
> using.  This was one way I came up with to try to get to some sort of
> agreed upon public API.  In retrospect, I probably put the cart before
> the horse as doing all of these tests will take considerably longer than
> initially flagging methods considered to be public.  But hopefully you
> can see how doing both could complement each other.  To reiterate: this
> work is on us to do up front, Juan would just review and commit.
>
>> --Hannes
>>
>> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> > On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
>> >> The file testResults.xml which Juan added has
>> >>
>> >> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
>> >> status="passed"/>
>> >> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
>> >> status="passed"/>
>> >> <testcase classname="ApiFile" name="testText01WriteToFile"
>> >> status="passed"/>
>> >> <testcase classname="ApiFile" name="testText02ReadFromFile"
>> >> status="passed"/>
>> >>
>> >> So there is an issue of test setup which was not fullfilled in my
>> >> case....
>> >> Might be a Linux Mint issue (access rights)
>> >>
>> >
>> > I don't have the test in front of me right now but if I recall, the
>> > setup code exists to create a temp directory in the same directory the
>> > image was launched from to write the test files. (that was the best way
>> > I could come up with to not introduce any platform-specific path
>> > handling issues to the test)
>> >
>> > If the setup code failed, then the test would have probably failed.
>> > Did
>> > you manually do anything or did it just work the 2nd time you ran it?
>> > (if it re-ran successfully without you needing to do anything else, it
>> > definitely sounds like a problem in the test setup.  If it were a
>> > rights
>> > issue, it should have continued to fail.)
>> >
>> > The good news is we're about to change all the file/directory handling
>> > code so it needs to be updated anyway...
>> >
>> >> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> >> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >> >> Hi Hannes,
>> >> >>
>> >> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>> >> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> >> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>> >> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>> >> >>> >>
>> >> >>> >> > As Casey writes "The hard part is time and energy to do so."
>> >> >>> >> >
>> >> >>> >> > So what can be done with minimal effort and big impact?
>> >> >>> >>
>> >> >>> >> Looking around, I see that I could make some simple naming
>> >> >>> >> changes
>> >> >>> >> for
>> >> >>> >> test cases.
>> >> >>> >>
>> >> >>> >> E.g in package Crypto-Nacl there are test cases (class
>> >> >>> >> NaclTests)
>> >> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>> >> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>> >> >>> >>
>> >> >>> >> We could use other words, but API is shorter than Usage,
>> >> >>> >> Example,
>> >> >>> >> Interface.
>> >> >>> >>
>> >> >>> >> Having specific test names end in 'API' would clue me in.
>> >> >>> >>
>> >> >>> >> Adding 'Nacl' means I can use the existing message finder to
>> >> >>> >> search
>> >> >>> >> for
>> >> >>> >> 'api' and note testNacl*API methods.  This lets me find API
>> >> >>> >> tests
>> >> >>> >> specific
>> >> >>> >> to Nacl.
>> >> >>> >>
>> >> >>> >> And we can do this as I get the chance.
>> >> >>> >>
>> >> >>> >> Other suggestions?
>> >> >>> >
>> >> >>> > I started playing around with a couple of example test cases to
>> >> >>> > see
>> >> >>> > what
>> >> >>> > I ran into and came up with a distinct class to store all of
>> >> >>> > these
>> >> >>> > per
>> >> >>> > test category (i.e. under Test-Files a class ApiFile which could
>> >> >>> > have
>> >> >>> > a
>> >> >>> > method testWriteTextFile)  The rationale was that it might make
>> >> >>> > sense
>> >> >>> > to
>> >> >>> > keep these test cases separate from traditional test cases which
>> >> >>> > are
>> >> >>> > free to make calls that users of the class (i.e. who are calling
>> >> >>> > the
>> >> >>> > supported API) should not.
>> >> >>>
>> >> >>> Phil,
>> >> >>>
>> >> >>> where do you keep this class ApiFile?
>> >> >>>
>> >> >>
>> >> >> It's in Packages/Tests.pck.st package. After loading it will be
>> >> >> listed
>> >> >> in the Tests-Files category.
>> >> >
>> >> >
>> >> > I loaded the class ApiFile only and I get 3 tests passed and 1
>> >> > failure
>> >> > in Cuis 2.4-2424.
>> >> >
>> >> > Can you confirm this, Phil?
>> >> >
>> >> >>> regards
>> >> >>>
>> >> >>> Hannes
>> >> >>>
>> >> >>
>> >> >> Thanks,
>> >> >> Phil
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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
>> > 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 hannes.hirzel at gmail.com  Mon Jul 20 07:41:41 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:41:41 +0000
Subject: [Cuis] #printStringLimitedTo:
In-Reply-To: <1437285899.6934.1.camel@gmail.com>
References: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>
	<1437285899.6934.1.camel@gmail.com>
Message-ID: <CAGQxfVi0Sjj8YNfYBxDKwa4sqWHJnAbApWfgHOOHdUy72nZYPA@mail.gmail.com>

Ken you ask about other options

one would be to have a method


#printStringLimitedTo:suffix:

so that people can have their own suffix.

Might be better in a multilingual environment.

However  '...etc...' is pretty general.

No objection if it stays as is.

--HH

On 7/19/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Sat, 2015-07-18 at 21:33 -0700, Ken.Dickey wrote:
>> I find it kind of odd that #printStringLimitedTo: takes the prefix of a
>> too-long string and adds '...etc...', which itself is 9 characters.
>>
>> I think a shorter addition would make more sense.  After all, the string
>> is already too long, right?
>>
>> I like '[..]' , which is only four characters.
>>
>> Would anyone else like to weigh in on this?  Other options?
>
> I agree that the current suffix is long-ish and like your [..] idea as
> that's unlikely to appear in the majority of strings but would still
> convey the information.
>
>> -KenD
>>
>> _______________________________________________
>> 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 hannes.hirzel at gmail.com  Mon Jul 20 07:47:19 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:47:19 +0000
Subject: [Cuis] Baseline version?
In-Reply-To: <4CA2DB35-1A26-46CE-B5D1-ACB50DC642B0@mac.com>
References: <mailman.94.1437354099.18328.cuis_jvuletich.org@jvuletich.org>
	<4CA2DB35-1A26-46CE-B5D1-ACB50DC642B0@mac.com>
Message-ID: <CAGQxfVhUXD_P8Tz7vqGh_9U=8C+WcPJKvSqtizMH-yLNNTcKQg@mail.gmail.com>

 http://netjam.org/versions/ is pretty general.

I would be fine with a very simple scheme these days. Just two
releases per year.

--HH

On 7/20/15, Ken G. Brown <kbrown at mac.com> wrote:
> Craig Latta has a nice write up about his decent looking versioning system
> for Spoon: http://netjam.org/versions/
>
> Ken G. Brown
>
>> Date: Sun, 19 Jul 2015 23:01:22 +0000
>> From: "H. Hirzel" <hannes.hirzel at gmail.com>
>> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
>> Subject: [Cuis] Baseline version?
>> Message-ID:
>>    <CAGQxfVg7XkxDx0GXRzbM-g-efzvVKeafy3H5DzNJdjkzTwxDUg at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>>> On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
>>> On Sun, 19 Jul 2015 11:20:19 -0300
>> ....
>>> I'd like to propose a simpler model based on the Smalltalk Way.
>>>
>>> We take any stable revision, call it a version, give it a Baseline
>>> Version
>>> Number (could be just the development version number).
>>
>> I'd like to suggest to label just the current version as a "baseline".
>>
>> It would not need a long description, just a few keywords regarding
>> major changes like the addition of the FileMan package with a
>> reference to the description of it.
>>
>> The last one
>> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
>>
>> had
>>
>> New in Cuis 4.2 (released July 25, 2013)
>>
>>    Packages now have dependencies
>>
>>    Package loading greatly enhanced
>>
>>    Moved non-essential stuff to optional packages. Cuis is now below
>> 500 classes and 100kLOC. Reduction was about 25%
>>
>>    Many bugfixes, and minor enhancements and cleanup
>>
>>
>> So this one would have
>>
>> New in Cuis 4.3 (released July 25, 2015)
>>
>>     Many bugfixes, and minor enhancements and cleanup
>>
>>     Addition of FileMan
>>
>>    .....................
>>
>>    .......................
>>
>>
>>    .....................
>>
>>    .......................
>>
>>
>>
>> And then after testing various packages on it
>> another baseline at the end of the year with a release document.
>>
>> New in Cuis 4.4 (released December 31, 2015)
>>
>>     Many bugfixes, and minor enhancements and cleanup
>>
>>    .....................
>>
>>    .....................
>>
>>    .......................
>>
>>
>>    .....................
>>
>>    .......................
>>
>>    .....................
>>
>>    .......................
>>
>>
>> More text as we will be more aware of the changes.
>>
>>
>>
>>> Each Baseline
>>> Release has a release document which describes major changes since the
>>> previous baseline.  This document is a light-weight description.
>>>
>>> Each baseline release starts a new fork.  The only changes to the
>>> particular
>>> baseline release are bug fixes.
>>>
>>> Nice users test their packages and likewise fork a Package Release which
>>> matches a Baseline Release.  This fork also only changes with bug fixes,
>>> and
>>> only in synch with its particular baseline.  Baseline packages Feature
>>> the
>>> baseline release.
>>>
>>> So we forge ahead as usual, once in a while we say "enough has changed
>>> that
>>> we should re-baseline", do a new Baseline Release, test and release our
>>> Package Releases, then again move on forward.
>>>
>>> Anyone can now pick any baseline release, require any associated
>>> packages,
>>> and ship/demo without fear.
>>>
>>> Anyone with the time, energy, and interest can document baseline APIs to
>>> whatever level they feel comfortable.
>>>
>>> Anyone can forge on ahead with the latest revision(s) with the usual
>>> "here
>>> be dragons, but also gold".
>>>
>>> $0.02
>>> -KenD
>>>
>>> _______________________________________________
>>> 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 hannes.hirzel at gmail.com  Mon Jul 20 07:55:57 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:55:57 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <1437354098.6934.240.camel@gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
	<CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>
	<1437354098.6934.240.camel@gmail.com>
Message-ID: <CAGQxfVjzR=pG2i4+RakCiNZKJ6EMTJGkXu5sX2OAdiMCjS24GQ@mail.gmail.com>

Yes,

an image diff to see what classes/methods changed between timer period X and Y

is what I am looking for.

--Hannes

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Sun, 2015-07-19 at 20:21 +0000, H. Hirzel wrote:
>> If I take a current image (18 Jul 2015, 4.2-2424)  I get the same result
>>
>>
>> a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
>> #at:ifAbsent:)
>>
>> All the FileMan additions are not listed. Maybe because they keep
>> their original time stamp, not the time stamp of the addition to
>> Squeak.
>>
>
> Right, the timestamp will reflect when they were last edited rather than
> when they were loaded into the image.
>
>> And the recent change on #compilerClass does not show up.
>>
>
> Same situation: #compilerClass while only recently re-added to the
> image, hasn't actually been changed since it was removed and added back
> so it still shows an older timestamp.
>
> It sounds like you're looking for more of an image diff to see what
> classes/methods changed between timer period X and Y?  This isn't
> something that currently exists in an easy to use form that I'm aware
> of.
>
>> --HH
>>
>> On 7/19/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> > If I use this to find out which methods have a time stamp date
>> > indicating a change after the 1st of January 2015 in a pristine Cuis
>> > 4.2-2243 (17 April 2015) image I find out that only the
>> >
>> > #postCopy method was changed (probably added) in nearly all classes.
>> >
>> > If I change the base line date to 1st of January 2014 I get
>> >
>> > a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
>> > #at:ifAbsent:)
>> > as changed/updated methods (i.e. methods which have a time stamp in
>> > this period).
>> >
>> > Of course this assumes that a method gets a time stamp when changed.
>> > Many methods have nil as a time stamp.
>> >
>> >
>> > Could somebody from the list check this please?
>> >
>> >
>> > |date coll baseLineDate dt  updatedMethods |
>> >
>> > baseLineDate := Date year: 2014 month: 1 day: 1.
>> > coll := OrderedCollection new.
>> >
>> > Smalltalk allClasses do: [ :cls |
>> > cls allSelectors do: [ :sel |
>> > dt := VersionsBrowser timeStampFor:  sel class: Dictionary
>> > reverseOrdinal:
>> > 1.
>> >
>> > dt notNil ifTrue: [
>> > date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
>> > ]) or: [ch = $:]] .
>> > (date = '') ifFalse:
>> > 	[date := Date fromString: date.
>> > 		(date > baseLineDate) ifTrue: [coll add: (Association key:
>> > (Association key: cls value: sel) value: date)
>> > ]]].
>> >
>> > ]].
>> >
>> > updatedMethods := Set new.
>> > coll do: [ :elem | updatedMethods add: (elem key value)].
>> > coll inspect.
>> > updatedMethods inspect
>> >
>> >
>> >
>> >
>> > On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
>> >> On 7/16/2015 11:49 AM, H. Hirzel wrote:
>> >>> Hello
>> >>>
>> >>> I'd like to do a query finding out about the time stamp of  source
>> >>> code changes of all methods in the Cuis image and then do a list with
>> >>> the following four columns
>> >>>
>> >>>
>> >>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
>> >>> DateOfChange
>> >>>
>> >>> Help is appreciated.
>> >>>
>> >>> Hannes
>> >>
>> >> Check #timeStampFor:class:reverseOrdinal: and in general
>> >> #annotationForSelector:ofClass:
>> >>
>> >> Cheers,
>> >> Juan Vuletich
>> >>
>> >
>> _______________________________________________
>> 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 Ken.Dickey at whidbey.com  Mon Jul 20 08:55:45 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 20 Jul 2015 06:55:45 -0700
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437352771.6934.219.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
Message-ID: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>

On Sun, 19 Jul 2015 20:39:31 -0400
"Phil (list)" <pbpublist at gmail.com> wrote:

> The issue is what constitutes a major change?  If your code uses it it's
> major, if mine uses it it's minor?  Coin toss?  Without a public API
> what is considered major is either obvious (i.e. Morphic changes from
> global to local coords or changing the File/Directory API so obviously
> everything using them breaks) or arbitrary (sorry to hear that you
> depended on that... but it wasn't major, now it's gone)  If the image
> snapshot is considered the public API, then everything must be both
> considered fair game to depend on and to change in the future which is
> unmanageable.

I don't think this is the issue at all. 

The text editor comes up in every release with goals for Cuis.  Backward compatibility is a stated non-goal.

I am happy to baseline my packages a couple of times a year against a baseline core release and maintain such matched baseline package releases.

I trust Juan's leadership and judgment. His time is a scarce and valuable resource.  He is very responsive to the Cuis community, including requests for backward compatibility and additional support.  I do _not_ want to slow him down.

If you have specific requirements, a package with Feature/Unit-tests is a good way to express this.

> I'm not trying to restrict Juan in any way from making the changes he
> thinks are important for Cuis.  His taste and direction have been
> generally excellent and the reason I'm here!  If for example, he decides
> that #drawOn: is no longer the way to do things or that even Morph
> needed to go away, that's fine as long as what's going on gets
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.

Pardon me, but this sounds exactly like you are trying to restrict certain changes.

It seems that you are trying to "plan" and "rule set" rather than "discover quickly".

My experience is that quick discovery (like writing unit tests and running them very frequently) is the fastest development path.

My guess is that major packages which prove useful will either migrate into the core packages or will be tested against as part of a larger release process.  I just prefer that process to be as small and painless (low drag) as possible.

If some package is not in wide use, the author can test against releases as often as he/she feels it necessary.  We can deal with breakage as it arises rather than planning search strategies for avoiding breakage.  For me, this is much more efficient.

Having API test suites is a good way to communicate importance.


As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful.  I heard that the Arabic word for "miracle" literally translates to "breaking the habit".  Interesting thought.

In the limit, we may be "agreeing loudly" here.  Easy to sound strident in an email.  Not the intent.


What is the simplest thing that will work?
-KenD



From hannes.hirzel at gmail.com  Mon Jul 20 12:26:42 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 17:26:42 +0000
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
Message-ID: <CAGQxfVisvidGE440ZhSTcC=RHjcU2Ega4_uUwh_j-QpdosRFNw@mail.gmail.com>

On 7/20/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Sun, 19 Jul 2015 20:39:31 -0400
> "Phil (list)" <pbpublist at gmail.com> wrote:
>
>> The issue is what constitutes a major change?  If your code uses it it's
>> major, if mine uses it it's minor?  Coin toss?  Without a public API
>> what is considered major is either obvious (i.e. Morphic changes from
>> global to local coords or changing the File/Directory API so obviously
>> everything using them breaks) or arbitrary (sorry to hear that you
>> depended on that... but it wasn't major, now it's gone)  If the image
>> snapshot is considered the public API, then everything must be both
>> considered fair game to depend on and to change in the future which is
>> unmanageable.
>
> I don't think this is the issue at all.
>
> The text editor comes up in every release with goals for Cuis.  Backward
> compatibility is a stated non-goal.
>
> I am happy to baseline my packages a couple of times a year against a
> baseline core release and maintain such matched baseline package releases.

+1

> I trust Juan's leadership and judgment. His time is a scarce and valuable
> resource.  He is very responsive to the Cuis community, including requests
> for backward compatibility and additional support.  I do _not_ want to slow
> him down.


+1

> If you have specific requirements, a package with Feature/Unit-tests is a
> good way to express this.


+1

>> I'm not trying to restrict Juan in any way from making the changes he
>> thinks are important for Cuis.  His taste and direction have been
>> generally excellent and the reason I'm here!  If for example, he decides
>> that #drawOn: is no longer the way to do things or that even Morph
>> needed to go away, that's fine as long as what's going on gets
>> communicated.


+1

However, a problem I think he faces right now is that he
>> doesn't know who's using / depending on what.
>
> Pardon me, but this sounds exactly like you are trying to restrict certain
> changes.
>
> It seems that you are trying to "plan" and "rule set" rather than "discover
> quickly".
>
> My experience is that quick discovery (like writing unit tests and running
> them very frequently) is the fastest development path.
>
> My guess is that major packages which prove useful will either migrate into
> the core packages or will be tested against as part of a larger release
> process.  I just prefer that process to be as small and painless (low drag)
> as possible.
>
> If some package is not in wide use, the author can test against releases as
> often as he/she feels it necessary.  We can deal with breakage as it arises
> rather than planning search strategies for avoiding breakage.  For me, this
> is much more efficient.
>
> Having API test suites is a good way to communicate importance.

+1

>
> As an aside, I have found some breakage to be very enlightening and
> (sometimes painfully) helpful.  I heard that the Arabic word for "miracle"
> literally translates to "breaking the habit".  Interesting thought.
>
> In the limit, we may be "agreeing loudly" here.  Easy to sound strident in
> an email.  Not the intent.
>
>
> What is the simplest thing that will work?
> -KenD


Probably the easiest is that Juan goes on as he is used to and a
release manager or release team forks off a release / baseline from
time to time.

This allows for documenting an artifact which is no longer moving.
Selected updates might be applied to the release until the next release is due.

The documentation will got later on merged into the main branch as well.

Hannes



From peter at aba-instituut.nl  Mon Jul 20 16:32:46 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Mon, 20 Jul 2015 23:32:46 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
Message-ID: <CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>

On Mon, Jul 20, 2015 at 3:55 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

>
> If you have specific requirements, a package with Feature/Unit-tests is a
> good way to express this.
>

I was thinking: "What should a Feature Test be?". I tried to look up what
others have written, but found nothing useful (I probably did not look hard
enough). Now, I don't mind thinking of something new, so here goes:

1. Clearly (to me), it should not be a kind of Unit Test. When you run a
unit test, you assume that the unit under test is present in the system and
you are trying to ascertain if it does certain things you expect. For this,
unit tests have built-in facilities to detect execution errors and failed
expectations, If such problems happen, unit tests are able to continue the
testing process and report on the problems that occurred after the tests
are run (this is the step forward that SUnit - or TSTTestingFramework as it
ws known at the time - brought).

2. On the other hand, when you run a Feature Test, you may be testing one
or more units, and one or more (or all) of those might not even be present.
Therefore, a feature test should be able to run even if in the absence of
the unit(s) supposed to implement the feature. So then, perhaps what a
class FeatureTest should offer its subclasses, is a #run: aString method
that tries to compile aString and if it compiles, execute it and look for
any foreseen side effects and/or expression value.

a test method might then look like:

testApiReceiverIsPresentAndCanBeSetUp

self run: 'ApiReceiver version > ''1.1.4''' expectEvaluationResult: true
.
self run: 'ApiReceiver setUp'
.
self expectSideEffect: 'ExpectedApiReceiver isSetUp'

3. Then it should be able to report that everything went well, or that
there was a problem compiling (ideally with detailed info such as 'global
Xxx was expected but was not present in the system'. If compiling went
well, the execution should be protected and monitored similarly to unit
tests that are already able to catch exceptions during execution.

4. Perhaps something along these lines would be the simplest thing that
could possibly work?

Would it help anyone if they had the FeatureTest class that they could
subclass and as a result they could always, safely, test if some feature
was present and did what you needed/expected of it? And you could have a
Feature Test Runner that ran your feature test, made sure nothing crashed,
and reported the results in a useful fashion.

Just some thoughts, cheers, Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/9cfb5cc4/attachment-0003.html>

From d.a.tennant.2009 at gmail.com  Mon Jul 20 17:18:13 2015
From: d.a.tennant.2009 at gmail.com (David Tennant)
Date: Mon, 20 Jul 2015 16:18:13 -0600
Subject: [Cuis] Embedding morphs at specific points in a morph?
Message-ID: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>

Hi everyone.
I have been playing arrowed with cuis for a couple of years, but I am
extremely horrible at it. Every time I attempt to code a program I don't
get too far, but this time I want to actually make a program that works. So
I am trying to make a program that you can play mancala with. Mancala is an
abstract board game.
I decided that I should build the board first. the board should look
something like this
http://ecx.images-amazon.com/images/I/51PD0CemQkL._SY300_.jpg . I wanted
the circles and ovals to be separate classes so that I have more
flexibility later. I have 3 classes: Board, BigEllipse, and CircleEllipse.
In BigEllipse and CircleEllipse I just have initialization stuff, like size
and color. in Board I have the initialization stuff too, but I also have
what I thought would create the board, but It does not work. there are two
methods, one I called "addMyEllipse" and th other I called
"addScoreEllipse". these are the methods

addMyEllipse
|n|

    myEllipse:= CircleEllipse new.
        n:=1.
        (1to:12) do:[
            (n<7)
            ifTrue: [self addMorph: (myEllipse at: 35@(35+(60*n)))]
            ifFalse: [self addMorph: (myEllipse at: 110@(35+(60*n)))].
            n:= (n+1).
        ].
note: myEllipse is an instance variable.

addScoreEllipse
| n|

    scoreEllipse:= BigEllipse new.
    n:=1.
    (1to:2) do:[
        (n=1)
        ifTrue:[self addMorph:(scoreEllipse at: 72.5 at 35)]
        ifFalse:[self addMorph:(scoreEllipse at: 72.5 at 455)].
        n=(n+1).
    ].
note: scoreEllipse is an instance variable.

I don't actually know what is wrong. when I type in the workspace: Board
new openInWorld. I just get the background of the board, no ellipses. and
when I type in the workspace: test:= Board new openInWorld. test
addMyEllipse. I get an error that says, this block accepts 0 arguments, but
was called with 1 argument.

Thank you for your time
-- 
David Tennant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/1108b143/attachment-0003.html>

From juan at jvuletich.org  Mon Jul 20 17:33:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 19:33:27 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AC4B3F.19938.1F92268@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>,
	<55ABA6A2.5090607@jvuletich.org>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
Message-ID: <55AD7737.30003@jvuletich.org>

Hi Dan,

On 7/19/2015 10:13 PM, Dan Norton wrote:
> On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>
> > On 7/18/2015 3:37 PM, Dan Norton wrote:
> > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
> > >
> > >> Hi Folks,
> > >>
> > >> It is not too hard to build new StrikeFonts. You need to build,
> > by
> > >> hand,
> > >> files like the ones in here:
> > >>
> > https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> > >> p
> > >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
> > with
> > >> this method and the files in this zip that built the existing
> > >> instances
> > >> of StrikeFont. Not sure.
> > >>
> > > That's intrigueing but I can't reproduce it. Maybe the .bmp but
> > where did you get the .txt?
> > >
> > >   - Dan
> >
> > I wrote them with a text editor. Check #installDejaVu2 and really
> > try to
> > understand how StrikeFonts work and how they are built with this
> > method.
> > Maybe you'll become enlightened.
> >
>
> A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name, 
> and several scalars. StrikeFont class methods create fonts by 
> processing file pairs assumed to be in the "AAFonts" subdirectory. For 
> example:
>
> DejaVu Sans Oblique 14.bmp
> DejaVu Sans Oblique 14.txt
>
> Is one such pair providing the italic (oblique) style for 14-point 
> size. There is a pair for every font size and style: base, bold, 
> italic, and bold italic. Therefore a font such as "DejaVu Sans" which 
> is available in the size interval 5 to 24 requires 160 files. The file 
> names are stylized and encoded in the StrikeFont class methods.
>
> Glyphs come from the .bmp file. The .txt file is a string of numbers; 
> the first three specify pointSize, ascent, and descent. The rest of 
> the numbers in the .txt file are used to form the xTable, which is the 
> index into the glyphs for a character. The characterToGlyphMap is an 
> array of 256 entries which map a character's ascii value to the xTable 
> and thence to the glyphs.
>
> The bold, italic, and bold italic styles are stashed as derivatives of 
> the base and not selectable from the current menus.
>
> StrikeFont is a subclass of AbstractFont, which has class variables 
> AvailableFonts and DefaultFont.
>
> If it can't find a file, StrikeFont will loop.

Great! You got it all.

> In regard to creating the .bmp and .txt files, you say, " I wrote them 
> with a text editor." Please tell me which text editor you used. None 
> of mine do that.

The bmp files can be created with screen capture program, after entering 
suitable text in it. Maybe you need to stitch several pieces together, 
etc. WRT the txt files, well, the editor didn't do it for me. I wrote 
them. I _typed_ them. Maybe I used some (long lost) code to look for 
white columns separating glyphs, but I'm not really sure. 
#xTallyPixelValue:orNot: and friends are great for this kind of stuff.

In any case, it will be easier for you, as you want a monospaced font. 
Printing something like (32 to: 255) collect: [ :ascii | ascii-32 * 9 ] 
into the file might be enough.

You have all the pieces at hand. it just requires a bit of patience.

Cheers,
Juan Vuletich

>  - Dan
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/8664adb8/attachment-0003.html>

From hannes.hirzel at gmail.com  Mon Jul 20 18:33:31 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 23:33:31 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AD7737.30003@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
	<55ABA6A2.5090607@jvuletich.org>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
	<55AD7737.30003@jvuletich.org>
Message-ID: <CAGQxfViL7p7GieO3zwYRQpboqeMnfiiQdATeok1rZTeGmrCijw@mail.gmail.com>

https://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format

The Glyph Bitmap Distribution Format (BDF) by Adobe is a file format
for storing bitmap fonts. The content takes the form of a text file
intended to be human- and computer-readable. BDF is typically used in
Unix X Window environments.

Squeak contains a BDFFontReader

<class comment>
I am a conversion utility for reading X11 Bitmap Distribution Format
fonts.  My code is derived from the multilingual Squeak changeset
written by OHSHIMA Yoshiki (ohshima at is.titech.ac.jp), although all
support for fonts with more than 256 glyphs has been ripped out.  See
http://www.is.titech.ac.jp/~ohshima/squeak/squeak-multilingual-e.html
.

My class methods contain tools for fetching BDF source files from a
well-known archive site, batch conversion to Squeak's .sf2 format, and
installation of these fonts as TextStyles.  Also, the legal notices
for the standard 75dpi fonts I process this way are included as
"x11FontLegalNotices'.
</class comment>

The URL no longer works, but the Squeak wiki

http://wiki.squeak.org/squeak/696

has more on fonts.

I have loaded BDF fonts into Squeak in the past and I assume the
Squeak StrikeFonts and the Cuis StrikeFonts are still compatible.

--Hannes

On 7/20/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Dan,
>
> On 7/19/2015 10:13 PM, Dan Norton wrote:
>> On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>>
>> > On 7/18/2015 3:37 PM, Dan Norton wrote:
>> > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>> > >
>> > >> Hi Folks,
>> > >>
>> > >> It is not too hard to build new StrikeFonts. You need to build,
>> > by
>> > >> hand,
>> > >> files like the ones in here:
>> > >>
>> > https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> > >> p
>> > >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
>> > with
>> > >> this method and the files in this zip that built the existing
>> > >> instances
>> > >> of StrikeFont. Not sure.
>> > >>
>> > > That's intrigueing but I can't reproduce it. Maybe the .bmp but
>> > where did you get the .txt?
>> > >
>> > >   - Dan
>> >
>> > I wrote them with a text editor. Check #installDejaVu2 and really
>> > try to
>> > understand how StrikeFonts work and how they are built with this
>> > method.
>> > Maybe you'll become enlightened.
>> >
>>
>> A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name,
>> and several scalars. StrikeFont class methods create fonts by
>> processing file pairs assumed to be in the "AAFonts" subdirectory. For
>> example:
>>
>> DejaVu Sans Oblique 14.bmp
>> DejaVu Sans Oblique 14.txt
>>
>> Is one such pair providing the italic (oblique) style for 14-point
>> size. There is a pair for every font size and style: base, bold,
>> italic, and bold italic. Therefore a font such as "DejaVu Sans" which
>> is available in the size interval 5 to 24 requires 160 files. The file
>> names are stylized and encoded in the StrikeFont class methods.
>>
>> Glyphs come from the .bmp file. The .txt file is a string of numbers;
>> the first three specify pointSize, ascent, and descent. The rest of
>> the numbers in the .txt file are used to form the xTable, which is the
>> index into the glyphs for a character. The characterToGlyphMap is an
>> array of 256 entries which map a character's ascii value to the xTable
>> and thence to the glyphs.
>>
>> The bold, italic, and bold italic styles are stashed as derivatives of
>> the base and not selectable from the current menus.
>>
>> StrikeFont is a subclass of AbstractFont, which has class variables
>> AvailableFonts and DefaultFont.
>>
>> If it can't find a file, StrikeFont will loop.
>
> Great! You got it all.
>
>> In regard to creating the .bmp and .txt files, you say, " I wrote them
>> with a text editor." Please tell me which text editor you used. None
>> of mine do that.
>
> The bmp files can be created with screen capture program, after entering
> suitable text in it. Maybe you need to stitch several pieces together,
> etc. WRT the txt files, well, the editor didn't do it for me. I wrote
> them. I _typed_ them. Maybe I used some (long lost) code to look for
> white columns separating glyphs, but I'm not really sure.
> #xTallyPixelValue:orNot: and friends are great for this kind of stuff.
>
> In any case, it will be easier for you, as you want a monospaced font.
> Printing something like (32 to: 255) collect: [ :ascii | ascii-32 * 9 ]
> into the file might be enough.
>
> You have all the pieces at hand. it just requires a bit of patience.
>
> Cheers,
> Juan Vuletich
>
>>  - Dan
>>
>
>



From dnorton at mindspring.com  Mon Jul 20 18:55:38 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 19:55:38 -0400
Subject: [Cuis] Embedding morphs at specific points in a morph?
In-Reply-To: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
References: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
Message-ID: <55AD8A7A.26397.2436C64@dnorton.mindspring.com>

On 20 Jul 2015 at 16:18, David Tennant wrote:

> 
> Hi everyone.
> I have been playing arrowed with cuis for a couple of years, but I
> am extremely horrible at it. Every 
> time I attempt to code a program I don't get too far, but this time
> I want to actually make a 
> program that works. So I am trying to make a program that you can
> play mancala with. Mancala is 
> an abstract board game.
> I decided that I should build the board first. the board should look
> something like this 
> http://ecx.images-amazon.com/images/I/51PD0CemQkL._SY300_.jpg . I
> wanted the circles and 
> ovals to be separate classes so that I have more flexibility later.
> I have 3 classes: Board, 
> BigEllipse, and CircleEllipse. In BigEllipse and CircleEllipse I
> just have initialization stuff, like size 
> and color. in Board I have the initialization stuff too, but I also
> have what I thought would create 
> the board, but It does not work. there are two methods, one I called
> "addMyEllipse" and th other I 
> called "addScoreEllipse". these are the methods
> ?
> addMyEllipse
> |n|
> 
> ??? myEllipse:= CircleEllipse new.
> ??? ??? n:=1.
> ??? ??? (1to:12) do:[
> ??? ??? ??? (n<7)
> ??? ??? ??? ifTrue: [self addMorph: (myEllipse at:
> 35@(35+(60*n)))]
> ??? ??? ??? ifFalse: [self addMorph: (myEllipse at:
> 110@(35+(60*n)))].
> ??? ??? ??? n:= (n+1).
> ??? ??? ].
> note: myEllipse is an instance variable.
> 
> addScoreEllipse
> | n|
> 
> ??? scoreEllipse:= BigEllipse new.
> ??? n:=1.
> ??? (1to:2) do:[
> ??? ??? (n=1)
> ??? ??? ifTrue:[self addMorph:(scoreEllipse at: 72.5 at 35)]
> ??? ??? ifFalse:[self addMorph:(scoreEllipse at: 72.5 at 455)].
> ??? ??? n=(n+1).
> ??? ].
> note: scoreEllipse is an instance variable.
> 
> I don't actually know what is wrong. when I type in the workspace:
> Board new openInWorld. I just 
> get the background of the board, no ellipses. and when I type in the
> workspace: test:= Board new 
> openInWorld. test addMyEllipse. I get an error that says, this block
> accepts 0 arguments, but was 
> called with 1 argument.
> 
>
I had the same problem recently in some code that looked like this:

ifExistsDo: [{italicName. ' OK'} print]

The cure was to "expect" an argument, even tho it would not be used:

ifExistsDo: [:x | {italicName. ' OK'} print]

Thanks to Phil for staightening me out.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/6f694e3a/attachment-0003.html>

From dnorton at mindspring.com  Mon Jul 20 19:32:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 20:32:56 -0400
Subject: [Cuis] Terse Guide to Pen, Forms
Message-ID: <55AD9338.29402.26592D8@dnorton.mindspring.com>

Hello,

The Pen and Forms topics in Terse Guide no longer work. For example:

| x y |
x := Form dotOfSize: 20.	"Make a form containing a dot (as yet unseen)."
x displayAt: 500 at 200.		"Cause the form to appear at a point on the display."
Display restore.			"Erase what was displayed."

#displayAt: doesn't.

Similar problems with "Display fillWhite" in the Pen topic.

 - Dan



From juan at jvuletich.org  Mon Jul 20 20:07:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:07:01 -0300
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVjzR=pG2i4+RakCiNZKJ6EMTJGkXu5sX2OAdiMCjS24GQ@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>	<55A90799.7080302@jvuletich.org>	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>	<CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>	<1437354098.6934.240.camel@gmail.com>
	<CAGQxfVjzR=pG2i4+RakCiNZKJ6EMTJGkXu5sX2OAdiMCjS24GQ@mail.gmail.com>
Message-ID: <55AD9B35.5010805@jvuletich.org>

Hi Hannes,

On 7/20/2015 9:55 AM, H. Hirzel wrote:
> Yes,
>
> an image diff to see what classes/methods changed between timer period X and Y
>
> is what I am looking for.
>
> --Hannes

That is easy.

In the newer image, evaluate: SystemOrganization fileOutAllCategories.

Now start the older image. (you might need to file in the attach if you 
get a walkback) Open a File list. Click on the *AllCode.st file 
generated in the newer image. Click on [contents]. Select "No".

Right click on the change list. 'remove up-to-date versions'.

"Right click again. Select methods equivalent to current". "Remove 
selected items".

You can study them right there. Or you can "select all" "file out 
selections". Then select this file in the file list and click on [code] 
and use this view instead. In any of these ways, it is reasonable easy 
to see how much changed, and check each change if desired.

Or you can come up with your own new and creative ways to use the tools 
in the system :)

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2425-privateReadSelector-fix-JuanVuletich-2015Jul20-19h44m-jmv.1.cs.zip
Type: application/zip
Size: 662 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/0304b3af/attachment-0003.zip>

From juan at jvuletich.org  Mon Jul 20 20:21:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:21:34 -0300
Subject: [Cuis] Terse Guide to Pen, Forms
In-Reply-To: <55AD9338.29402.26592D8@dnorton.mindspring.com>
References: <55AD9338.29402.26592D8@dnorton.mindspring.com>
Message-ID: <55AD9E9E.7020407@jvuletich.org>

Hi Dan,

This is a bug I introduced when speeding up Transcript maybe a month 
ago. I'll fix it soon (max 2 days).

Thanks for reporting.

Cheers,
Juan Vuletich

On 7/20/2015 9:32 PM, Dan Norton wrote:
> Hello,
>
> The Pen and Forms topics in Terse Guide no longer work. For example:
>
> | x y |
> x := Form dotOfSize: 20.	"Make a form containing a dot (as yet unseen)."
> x displayAt: 500 at 200.		"Cause the form to appear at a point on the display."
> Display restore.			"Erase what was displayed."
>
> #displayAt: doesn't.
>
> Similar problems with "Display fillWhite" in the Pen topic.
>
>   - Dan
>




From juan at jvuletich.org  Mon Jul 20 20:28:44 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:28:44 -0300
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <559AA0A2.13962.3B4CD8@dnorton.mindspring.com>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>,
	<559A83A3.5040406@jvuletich.org>
	<559AA0A2.13962.3B4CD8@dnorton.mindspring.com>
Message-ID: <55ADA04C.8070100@jvuletich.org>

On 7/6/2015 12:37 PM, Dan Norton wrote:
> On 6 Jul 2015 at 10:33, Juan Vuletich wrote:
>
>> Hi Dan,
>>
>> On 7/5/2015 8:35 PM, Dan Norton wrote:
>>> Greetings,
>>>
>>> Four LayoutSpec class methods use "minorDirectionPadding:" as a
>> keyword. The parameter
>>> can be a number or one of: #top, #left, #center, #right, or
>> #bottom. AFAICT when the
>>> parameter is a number, it refers to the padding which will be
>> applied in the minor direction.
>>> When it is a symbol, it effectively specifies that morphs will be
>> located as the symbol name
>>> implies.
>>>
>>> Attached are four convenience methods whose keyword emphasizes the
>> visible (morph)
>>> instead of the invisible (padding). The "morphPlacement:"
>> parameter can be  #top, #left,
>>> #center, #right, or #bottom. The methods are:
>>>
>>> LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
>>> LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
>>> LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
>>> LayoutSpec
>> class>>proportionalWidth:proportionalHeight:morphPlacement:
>>> Are these worth having in the base system?
>>>
>>>    - Dan
>>>
>> I'd rather replace the keyword 'minorDirectionPadding:' by
>> 'minorDirectionPlacement:' to:
>> - Avoid ambiguity
>> - Avoid duplication
>>
> OK, as far as the duplication, but I don't see "morphPlacement:" in use. Where does the
> ambiguity occur?
>
>   - Dan

The ambiguity in 'morphPlacement' is that it suggest it is about x and y 
placement. It is only for the 'minor' direction: x if a column, y if a 
row. Major direction placement is dictated by the other arguments, and 
siblings, etc.

Does this make sense?

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Mon Jul 20 20:34:16 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 21:34:16 -0400
Subject: [Cuis] Embedding morphs at specific points in a morph?
In-Reply-To: <55AD8A7A.26397.2436C64@dnorton.mindspring.com>
References: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
	<55AD8A7A.26397.2436C64@dnorton.mindspring.com>
Message-ID: <1437442456.2300.57.camel@gmail.com>

Welcome David!

On Mon, 2015-07-20 at 19:55 -0400, Dan Norton wrote:
> On 20 Jul 2015 at 16:18, David Tennant wrote:
> 
> 
> > 
> > Hi everyone.
> > I have been playing arrowed with cuis for a couple of years, but I
> > am extremely horrible at it. Every 
> > time I attempt to code a program I don't get too far, but this time
> > I want to actually make a 
> > program that works. So I am trying to make a program that you can
> > play mancala with. Mancala is 
> > an abstract board game.
> > I decided that I should build the board first. the board should look
> > something like this 
> > http://ecx.images-amazon.com/images/I/51PD0CemQkL._SY300_.jpg . I
> > wanted the circles and 
> > ovals to be separate classes so that I have more flexibility later.
> > I have 3 classes: Board, 
> > BigEllipse, and CircleEllipse. In BigEllipse and CircleEllipse I
> > just have initialization stuff, like size 
> > and color. in Board I have the initialization stuff too, but I also
> > have what I thought would create 
> > the board, but It does not work. there are two methods, one I called
> > "addMyEllipse" and th other I 
> > called "addScoreEllipse". these are the methods
> >  
> > addMyEllipse
> > |n|
> > 
> >     myEllipse:= CircleEllipse new.
> >         n:=1.
> >         (1to:12) do:[
> >             (n<7)
> >             ifTrue: [self addMorph: (myEllipse at:
> > 35@(35+(60*n)))]
> >             ifFalse: [self addMorph: (myEllipse at:
> > 110@(35+(60*n)))].
> >             n:= (n+1).
> >         ].
> > note: myEllipse is an instance variable.
> > 
> > addScoreEllipse
> > | n|
> > 
> >     scoreEllipse:= BigEllipse new.
> >     n:=1.
> >     (1to:2) do:[
> >         (n=1)
> >         ifTrue:[self addMorph:(scoreEllipse at: 72.5 at 35)]
> >         ifFalse:[self addMorph:(scoreEllipse at: 72.5 at 455)].
> >         n=(n+1).
> >     ].
> > note: scoreEllipse is an instance variable.
> > 
> > I don't actually know what is wrong. when I type in the workspace:
> > Board new openInWorld. I just 
> > get the background of the board, no ellipses. and when I type in the
> > workspace: test:= Board new 
> > openInWorld. test addMyEllipse. I get an error that says, this block
> > accepts 0 arguments, but was 
> > called with 1 argument.
> > 
> >
> I had the same problem recently in some code that looked like this:
> 
> 
> ifExistsDo: [{italicName. ' OK'} print]
> 
> 
> The cure was to "expect" an argument, even tho it would not be used:
> 
> 
> ifExistsDo: [:x | {italicName. ' OK'} print]
> 
Dan has it exactly right. The (1 to: 12) do: is trying to pass your
block the current value which *is* your n so you should get rid of the
outer n declaration and change the block to accept the parameter like
this:

(1 to: 12) do: [:n| Transcript show: n asString]

Just replace the Transcript statement with your code and you should be
good to go...

> 
> Thanks to Phil for staightening me out.
> 

Glad I could help... while the debugger is always precise as to what is
wrong, it isn't always clear :-)
> 
>  - Dan
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Mon Jul 20 20:34:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:34:43 -0300
Subject: [Cuis] #printStringLimitedTo:
In-Reply-To: <CAGQxfVi0Sjj8YNfYBxDKwa4sqWHJnAbApWfgHOOHdUy72nZYPA@mail.gmail.com>
References: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>	<1437285899.6934.1.camel@gmail.com>
	<CAGQxfVi0Sjj8YNfYBxDKwa4sqWHJnAbApWfgHOOHdUy72nZYPA@mail.gmail.com>
Message-ID: <55ADA1B3.7060504@jvuletich.org>

Why not? I just did the .cs. If nobody objects, Ken' s suggestion will 
be in the next commit.

Cheers,
Juan Vuletich

On 7/20/2015 9:41 AM, H. Hirzel wrote:
> Ken you ask about other options
>
> one would be to have a method
>
>
> #printStringLimitedTo:suffix:
>
> so that people can have their own suffix.
>
> Might be better in a multilingual environment.
>
> However  '...etc...' is pretty general.
>
> No objection if it stays as is.
>
> --HH
>
> On 7/19/15, Phil (list)<pbpublist at gmail.com>  wrote:
>> On Sat, 2015-07-18 at 21:33 -0700, Ken.Dickey wrote:
>>> I find it kind of odd that #printStringLimitedTo: takes the prefix of a
>>> too-long string and adds '...etc...', which itself is 9 characters.
>>>
>>> I think a shorter addition would make more sense.  After all, the string
>>> is already too long, right?
>>>
>>> I like '[..]' , which is only four characters.
>>>
>>> Would anyone else like to weigh in on this?  Other options?
>> I agree that the current suffix is long-ish and like your [..] idea as
>> that's unlikely to appear in the majority of strings but would still
>> convey the information.
>>
>>> -KenD
>>>
>>> _______________________________________________
>>> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Mon Jul 20 20:36:10 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:36:10 -0300
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
Message-ID: <55ADA20A.2070105@jvuletich.org>

On 7/19/2015 6:01 PM, H. Hirzel wrote:
> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
> ....
>   I
>> recently changed the scoping rules for shared variables (I think they're
>> done wrong in the base image). I could change what I wanted easily. So I
>> think I am not in some outsider author group. Instead I am happy that I
>> could change what I wanted without needing anyone's approval or
>> cooperation.

Great!

> A note:
> This applies to any version / distribution of Smalltalk. But it means
> that you have your own version of the core system.
>
> Could you elaborate on the issue of the shared variables, maybe it is
> something to include in the core Cuis image?
>
> --Hannes

Agree. It would be nice to know.

Cheers,
Juan Vuletich



From Ken.Dickey at whidbey.com  Mon Jul 20 20:44:43 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 20 Jul 2015 18:44:43 -0700
Subject: [Cuis] Embedding morphs at specific points in a morph?
In-Reply-To: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
References: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
Message-ID: <20150720184443.e17db364fc884fd11ac09d87@whidbey.com>

On Mon, 20 Jul 2015 16:18:13 -0600
David Tennant <d.a.tennant.2009 at gmail.com> wrote:

> myEllipse:= CircleEllipse new.
>         n:=1.
>         (1to:12) do:[
>             (n<7)
>             ifTrue: [self addMorph: (myEllipse at: 35@(35+(60*n)))]
>             ifFalse: [self addMorph: (myEllipse at: 110@(35+(60*n)))].
>             n:= (n+1).
>         ].

I don't know what "CircleEllipse new" does (e.g. is the radius zero?), but I would note that you are adding the same morph at different positions.

I suspect each position would like its own morph.

-- 
-KenD



From dnorton at mindspring.com  Mon Jul 20 20:58:43 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 21:58:43 -0400
Subject: [Cuis] Terse Guide to Pen, Forms
In-Reply-To: <55AD9E9E.7020407@jvuletich.org>
References: <55AD9338.29402.26592D8@dnorton.mindspring.com>,
	<55AD9E9E.7020407@jvuletich.org>
Message-ID: <55ADA753.26544.2B41A22@dnorton.mindspring.com>

Great! The transcript speed is impressive, BTW.

 - Dan

On 20 Jul 2015 at 22:21, Juan Vuletich wrote:

> Hi Dan,
> 
> This is a bug I introduced when speeding up Transcript maybe a month
> ago. I'll fix it soon (max 2 days).
> 
> Thanks for reporting.
> 
> Cheers,
> Juan Vuletich
> 
> On 7/20/2015 9:32 PM, Dan Norton wrote:
> > Hello,
> >
> > The Pen and Forms topics in Terse Guide no longer work. For
> example:
> >
> > | x y |
> > x := Form dotOfSize: 20.	"Make a form containing a dot (as yet
> unseen)."
> > x displayAt: 500 at 200.		"Cause the form to appear at a point on the
> display."
> > Display restore.			"Erase what was displayed."
> >
> > #displayAt: doesn't.
> >
> > Similar problems with "Display fillWhite" in the Pen topic.
> >
> >   - Dan
> >
> 





From pbpublist at gmail.com  Mon Jul 20 20:58:55 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 21:58:55 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
Message-ID: <1437443935.2300.77.camel@gmail.com>

On Mon, 2015-07-20 at 06:55 -0700, Ken.Dickey wrote:
> On Sun, 19 Jul 2015 20:39:31 -0400
> "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > The issue is what constitutes a major change?  If your code uses it it's
> > major, if mine uses it it's minor?  Coin toss?  Without a public API
> > what is considered major is either obvious (i.e. Morphic changes from
> > global to local coords or changing the File/Directory API so obviously
> > everything using them breaks) or arbitrary (sorry to hear that you
> > depended on that... but it wasn't major, now it's gone)  If the image
> > snapshot is considered the public API, then everything must be both
> > considered fair game to depend on and to change in the future which is
> > unmanageable.
> 
> I don't think this is the issue at all. 
> 
> The text editor comes up in every release with goals for Cuis.  Backward compatibility is a stated non-goal.
> 

The first issue (text editor working in every release) is the difference
between reliability and stability, at least as I've been meaning in this
discussion.  Yes, it works in every release because it is part of what
is at least implicitly tested to a degree as part of nearly every build.
Cuis is very reliable in that within a given build things are generally
working better than they did in the previous build.

The backward compatibility non-goal seems like it should decrease as
Cuis matures. (not sure if this is a recent change or not, but it
actually does say that on the Cuis home page)  Once we hit a minimal
feature set, backwards incompatibility should largely go away as the
result of a combination of Cuis becoming the simplest thing that would
work and diminishing returns.  Perhaps we disagree on how close to that
point we are?  As Juan indicated, at some point the packages start to
play a larger role and at some point the same stability discussion
becomes an issue there as well.  (At least if the plan is to be able to
build larger and more complex things using Cuis in the future)

> I am happy to baseline my packages a couple of times a year against a baseline core release and maintain such matched baseline package releases.
> 

In theory what you're saying makes sense but in practice I didn't find
it worked.  I tried that back in the 2.x days and again in 4.x but found
the release notes just didn't have the detail to make this work for me.
I disliked the results enough that I'm currently trying to stay within a
build or two of Juan but that isn't realistic to expect most people to
do (I don't think so, at least) and if I ever fall behind in the current
model, I'm screwed...

> I trust Juan's leadership and judgment. His time is a scarce and valuable resource.  He is very responsive to the Cuis community, including requests for backward compatibility and additional support.  I do _not_ want to slow him down.
> 

I agree.  The question is how do we accomplish this.  My sense is that
we are starting to chew up more of his time peppering him with
questions / issues that he didn't anticipate resulting from recent
changes.  At the same time, for those who are not staying on the
bleeding edge, there is a level of frustration in that we're living in
an environment with very few constants and some of the changes have been
starting to hurt.

> If you have specific requirements, a package with Feature/Unit-tests is a good way to express this.
> 

I guess I see explicitly identified public methods and
feature/unit-tests as being complementary and helping lead to the same
place.

> > I'm not trying to restrict Juan in any way from making the changes he
> > thinks are important for Cuis.  His taste and direction have been
> > generally excellent and the reason I'm here!  If for example, he decides
> > that #drawOn: is no longer the way to do things or that even Morph
> > needed to go away, that's fine as long as what's going on gets
> > communicated.  However, a problem I think he faces right now is that he
> > doesn't know who's using / depending on what.
> 
> Pardon me, but this sounds exactly like you are trying to restrict certain changes.
> 

Poor choice of wording on my part, I probably should have said something
like 'prevent'.  Putting any sort of limits on when / how changes can be
made is a restriction.  But I'm not actually asking him to *not* make
the changes he thinks are necessary, but manage the when / how in some
cases.

> It seems that you are trying to "plan" and "rule set" rather than "discover quickly".
> 

I am asking him to plan a bit more *only* for a subset of things that we
agree need to be more stable than the rest.  I still believe that is <
20% of the unique method names.
  
> My experience is that quick discovery (like writing unit tests and running them very frequently) is the fastest development path.
> 
> My guess is that major packages which prove useful will either migrate into the core packages or will be tested against as part of a larger release process.  I just prefer that process to be as small and painless (low drag) as possible.
> 
> If some package is not in wide use, the author can test against releases as often as he/she feels it necessary.  We can deal with breakage as it arises rather than planning search strategies for avoiding breakage.  For me, this is much more efficient.

I don't think that most people will accept the compatibility through
continual testing/fixing over a long period of time... most will likely
give up after experiencing this for a while if they're attempting to use
Cuis as something more than a playground.

If the long term objective *isn't* for Cuis to be a platform, then an
acceptable answer would be 'you're using it wrong'.  Or Juan could
simply say 'yeah, ok... but I really don't want to do that...'

> 
> Having API test suites is a good way to communicate importance.
> 
> 
> As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful.  I heard that the Arabic word for "miracle" literally translates to "breaking the habit".  Interesting thought.
> 
> In the limit, we may be "agreeing loudly" here.  Easy to sound strident in an email.  Not the intent.
> 

I know you're generally pretty level headed and not looking to be
disagreeable.  I engaged in this discussion because it is an important
one to have and it felt like the right time to have it. A lot of what is
being proposed is a change from how things have historically been.  But
at the same time the pace of change has slowed down (ah, those whirlwind
1.x and 2.x days... :-) so it *seems* like trying to start to try to
stabilize things a bit has relatively little downside.  (Dunno... maybe
Juan is working on chucking the whole Magnitude hierarchy or something
major like that right now...)

> 
> What is the simplest thing that will work?
> -KenD





From dnorton at mindspring.com  Mon Jul 20 21:00:30 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 22:00:30 -0400
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <55ADA04C.8070100@jvuletich.org>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>,
	<559AA0A2.13962.3B4CD8@dnorton.mindspring.com>,
	<55ADA04C.8070100@jvuletich.org>
Message-ID: <55ADA7BE.20764.2B5BCE6@dnorton.mindspring.com>

On 20 Jul 2015 at 22:28, Juan Vuletich wrote:

> On 7/6/2015 12:37 PM, Dan Norton wrote:
> > On 6 Jul 2015 at 10:33, Juan Vuletich wrote:
> >
> >> Hi Dan,
> >>
> >> On 7/5/2015 8:35 PM, Dan Norton wrote:
> >>> Greetings,
> >>>
> >>> Four LayoutSpec class methods use "minorDirectionPadding:" as
> a
> >> keyword. The parameter
> >>> can be a number or one of: #top, #left, #center, #right, or
> >> #bottom. AFAICT when the
> >>> parameter is a number, it refers to the padding which will be
> >> applied in the minor direction.
> >>> When it is a symbol, it effectively specifies that morphs will
> be
> >> located as the symbol name
> >>> implies.
> >>>
> >>> Attached are four convenience methods whose keyword emphasizes
> the
> >> visible (morph)
> >>> instead of the invisible (padding). The "morphPlacement:"
> >> parameter can be  #top, #left,
> >>> #center, #right, or #bottom. The methods are:
> >>>
> >>> LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
> >>> LayoutSpec
> class>>fixedWidth:proportionalHeight:morphPlacement:
> >>> LayoutSpec
> class>>proportionalWidth:fixedHeight:morphPlacement:
> >>> LayoutSpec
> >> class>>proportionalWidth:proportionalHeight:morphPlacement:
> >>> Are these worth having in the base system?
> >>>
> >>>    - Dan
> >>>
> >> I'd rather replace the keyword 'minorDirectionPadding:' by
> >> 'minorDirectionPlacement:' to:
> >> - Avoid ambiguity
> >> - Avoid duplication
> >>
> > OK, as far as the duplication, but I don't see "morphPlacement:"
> in use. Where does the
> > ambiguity occur?
> >
> >   - Dan
> 
> The ambiguity in 'morphPlacement' is that it suggest it is about x
> and y 
> placement. It is only for the 'minor' direction: x if a column, y if
> a 
> row. Major direction placement is dictated by the other arguments,
> and 
> siblings, etc.
> 
> Does this make sense?
> 

+1

 - Dan



From hannes.hirzel at gmail.com  Tue Jul 21 02:12:34 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 21 Jul 2015 07:12:34 +0000
Subject: [Cuis] Terse Guide to Pen, Forms
In-Reply-To: <55ADA753.26544.2B41A22@dnorton.mindspring.com>
References: <55AD9338.29402.26592D8@dnorton.mindspring.com>
	<55AD9E9E.7020407@jvuletich.org>
	<55ADA753.26544.2B41A22@dnorton.mindspring.com>
Message-ID: <CAGQxfVhKjD-H3JKj7B8St6f0E-aYJrAMi0b87KHJjJHgcZBgSg@mail.gmail.com>

How would an additinonal test look like which covers this?

--Hannes



On 7/21/15, Dan Norton <dnorton at mindspring.com> wrote:
> Great! The transcript speed is impressive, BTW.
>
>  - Dan
>
> On 20 Jul 2015 at 22:21, Juan Vuletich wrote:
>
>> Hi Dan,
>>
>> This is a bug I introduced when speeding up Transcript maybe a month
>> ago. I'll fix it soon (max 2 days).
>>
>> Thanks for reporting.
>>
>> Cheers,
>> Juan Vuletich
>>
>> On 7/20/2015 9:32 PM, Dan Norton wrote:
>> > Hello,
>> >
>> > The Pen and Forms topics in Terse Guide no longer work. For
>> example:
>> >
>> > | x y |
>> > x := Form dotOfSize: 20.	"Make a form containing a dot (as yet
>> unseen)."
>> > x displayAt: 500 at 200.		"Cause the form to appear at a point on the
>> display."
>> > Display restore.			"Erase what was displayed."
>> >
>> > #displayAt: doesn't.
>> >
>> > Similar problems with "Display fillWhite" in the Pen topic.
>> >
>> >   - Dan
>> >
>>
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From peter at aba-instituut.nl  Tue Jul 21 14:13:15 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Tue, 21 Jul 2015 21:13:15 +0200
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <55ADA20A.2070105@jvuletich.org>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
	<55ADA20A.2070105@jvuletich.org>
Message-ID: <CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>

Hi Juan, Hannes,

since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW,
ST/X, VSE, IIRC) already do it as I want it to work
(Squeak does it "wrong" so perhaps it's not really a Smalltalk
implementation)

This is about the lookup logic when we see a name that is not a local name
(local to the block, method or object)

To resolve it (i.e., determine if it is a valid reference to a shared
variable), this is the order of searching for the name:

1 pool dictionaries declared in this class (from left to right I presume
but I don't care so I haven't paid attention)
2 classPool (i.e. the class variables defined in this class)
3 classPools in superclass chain
4 globals

The code in Squeak (and Cuis) does something recursive in the lookup logic
when it should not, which is probably based on an incorrect understanding
of the lookup rules. I have to admit that it is not easy to find how this
should be done, I have studied the Blue Book and ANSI-98 Smalltalk standard
(long long ago) and they were a bit fuzzy. But the logic all the other
dialects have also makes the most sense (to me) and works for some "clever"
stuff I do to make code 100% portable between dialects, so that's how I
like it to work.

Cheers, Peter

BTW Hannes, I'm not sure I would be able to change this in Dolphin, but in
the other dialects, probably. But like I said, there is no need, it is
Squeak (and Cuis) that's the odd one out.

On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org> wrote:

> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>
>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>> ....
>>   I
>>
>>> recently changed the scoping rules for shared variables (I think they're
>>> done wrong in the base image). I could change what I wanted easily. So I
>>> think I am not in some outsider author group. Instead I am happy that I
>>> could change what I wanted without needing anyone's approval or
>>> cooperation.
>>>
>>
> Great!
>
>  A note:
>> This applies to any version / distribution of Smalltalk. But it means
>> that you have your own version of the core system.
>>
>> Could you elaborate on the issue of the shared variables, maybe it is
>> something to include in the core Cuis image?
>>
>> --Hannes
>>
>
> Agree. It would be nice to know.
>
> 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/20150721/62be7266/attachment-0003.html>

From nicolas.cellier.aka.nice at gmail.com  Tue Jul 21 15:16:42 2015
From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier)
Date: Tue, 21 Jul 2015 22:16:42 +0200
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
	<55ADA20A.2070105@jvuletich.org>
	<CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>
Message-ID: <CAKnRiT68QBMbomVYVDyxpzfAM-g1rMBKZ+=RPp5nmdvb7DmqAA@mail.gmail.com>

2015-07-21 21:13 GMT+02:00 Peter van Rooijen <peter at aba-instituut.nl>:

> Hi Juan, Hannes,
>
> since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW,
> ST/X, VSE, IIRC) already do it as I want it to work
> (Squeak does it "wrong" so perhaps it's not really a Smalltalk
> implementation)
>
> This is about the lookup logic when we see a name that is not a local name
> (local to the block, method or object)
>
> To resolve it (i.e., determine if it is a valid reference to a shared
> variable), this is the order of searching for the name:
>
> 1 pool dictionaries declared in this class (from left to right I presume
> but I don't care so I haven't paid attention)
> 2 classPool (i.e. the class variables defined in this class)
> 3 classPools in superclass chain
> 4 globals
>
> The code in Squeak (and Cuis) does something recursive in the lookup logic
> when it should not, which is probably based on an incorrect understanding
> of the lookup rules. I have to admit that it is not easy to find how this
> should be done, I have studied the Blue Book and ANSI-98 Smalltalk standard
> (long long ago) and they were a bit fuzzy. But the logic all the other
> dialects have also makes the most sense (to me) and works for some "clever"
> stuff I do to make code 100% portable between dialects, so that's how I
> like it to work.
>
>
Ah, you probably mean that you would not want the superclass pool
dictionaries to be inherited, right?

Nicolas


> Cheers, Peter
>
> BTW Hannes, I'm not sure I would be able to change this in Dolphin, but in
> the other dialects, probably. But like I said, there is no need, it is
> Squeak (and Cuis) that's the odd one out.
>
> On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org> wrote:
>
>> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>>
>>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>>> ....
>>>   I
>>>
>>>> recently changed the scoping rules for shared variables (I think they're
>>>> done wrong in the base image). I could change what I wanted easily. So I
>>>> think I am not in some outsider author group. Instead I am happy that I
>>>> could change what I wanted without needing anyone's approval or
>>>> cooperation.
>>>>
>>>
>> Great!
>>
>>  A note:
>>> This applies to any version / distribution of Smalltalk. But it means
>>> that you have your own version of the core system.
>>>
>>> Could you elaborate on the issue of the shared variables, maybe it is
>>> something to include in the core Cuis image?
>>>
>>> --Hannes
>>>
>>
>> Agree. It would be nice to know.
>>
>> Cheers,
>> Juan Vuletich
>>
>> _______________________________________________
>> 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/20150721/c1c50cfa/attachment-0003.html>

From Ken.Dickey at whidbey.com  Tue Jul 21 17:33:00 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 21 Jul 2015 15:33:00 -0700
Subject: [Cuis] (Rescued) Re:  Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
Message-ID: <20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>

On Tue, 21 Jul 2015 07:59:47 -0700
Peter van Rooijen <peter at aba-instituut.nl> wrote:

>> I was thinking: "What should a Feature Test be?". 

I tend to think of a hierarchy of requirements.  Perhaps something like:

 Feature requireAll: #( <feature name>.. ).
 Classes requireAll: #( <class name>.. ). 
 Methods requireAll: #( <selector name>.. ).
 MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).         
 Tests requireAllPass: #( <unit test name> ).                 

The Feature class lets us require named (macro) Features with a version check.  I prefer that requirements at this level actually load the packages required and only report failure if that is not possible, although we could have a "preflight" verson which just checks without loading any featured packages.

API's are basically "protocols", which in the absence of symbolic execution means checking that classes and specific method selectors exist, or more specifically, method selectors are applicable to specific KindOf: classes.

Further, some Unit Tests may be required to pass to ensure compliance with some specification.

We should be able to automate at least some of this, including a first pass of generating the test sets, which could then be pruned by hand as required. 

$0.02,
-KenD



From peter at aba-instituut.nl  Wed Jul 22 05:41:47 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 22 Jul 2015 12:41:47 +0200
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <CAKnRiT68QBMbomVYVDyxpzfAM-g1rMBKZ+=RPp5nmdvb7DmqAA@mail.gmail.com>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
	<55ADA20A.2070105@jvuletich.org>
	<CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>
	<CAKnRiT68QBMbomVYVDyxpzfAM-g1rMBKZ+=RPp5nmdvb7DmqAA@mail.gmail.com>
Message-ID: <CAJBxtBb6ahfcNi7tAhJVZab5QfTG2cATrmyRBJjEEPwKc10fiA@mail.gmail.com>

Hi Nicolas,

On Tue, Jul 21, 2015 at 10:16 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:


> Ah, you probably mean that you would not want the superclass pool
> dictionaries to be inherited, right?
>

Indeed they should not be inherited. If the variables are relevant for the
whole hierarchy, the place to put them is in the classPool.

But there is a problem with the class variables by themselves too, although
I always forget what it is. If you really want to know I can look it up of
course.

Cheers, Peter





>
>
> Nicolas
>
>
>> Cheers, Peter
>>
>> BTW Hannes, I'm not sure I would be able to change this in Dolphin, but
>> in the other dialects, probably. But like I said, there is no need, it is
>> Squeak (and Cuis) that's the odd one out.
>>
>> On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org>
>> wrote:
>>
>>> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>>>
>>>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>>>> ....
>>>>   I
>>>>
>>>>> recently changed the scoping rules for shared variables (I think
>>>>> they're
>>>>> done wrong in the base image). I could change what I wanted easily. So
>>>>> I
>>>>> think I am not in some outsider author group. Instead I am happy that I
>>>>> could change what I wanted without needing anyone's approval or
>>>>> cooperation.
>>>>>
>>>>
>>> Great!
>>>
>>>  A note:
>>>> This applies to any version / distribution of Smalltalk. But it means
>>>> that you have your own version of the core system.
>>>>
>>>> Could you elaborate on the issue of the shared variables, maybe it is
>>>> something to include in the core Cuis image?
>>>>
>>>> --Hannes
>>>>
>>>
>>> Agree. It would be nice to know.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> _______________________________________________
>>> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>

On Tue, Jul 21, 2015 at 10:16 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 2015-07-21 21:13 GMT+02:00 Peter van Rooijen <peter at aba-instituut.nl>:
>
>> Hi Juan, Hannes,
>>
>> since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW,
>> ST/X, VSE, IIRC) already do it as I want it to work
>> (Squeak does it "wrong" so perhaps it's not really a Smalltalk
>> implementation)
>>
>> This is about the lookup logic when we see a name that is not a local
>> name (local to the block, method or object)
>>
>> To resolve it (i.e., determine if it is a valid reference to a shared
>> variable), this is the order of searching for the name:
>>
>> 1 pool dictionaries declared in this class (from left to right I presume
>> but I don't care so I haven't paid attention)
>> 2 classPool (i.e. the class variables defined in this class)
>> 3 classPools in superclass chain
>> 4 globals
>>
>> The code in Squeak (and Cuis) does something recursive in the lookup
>> logic when it should not, which is probably based on an incorrect
>> understanding of the lookup rules. I have to admit that it is not easy to
>> find how this should be done, I have studied the Blue Book and ANSI-98
>> Smalltalk standard (long long ago) and they were a bit fuzzy. But the logic
>> all the other dialects have also makes the most sense (to me) and works for
>> some "clever" stuff I do to make code 100% portable between dialects, so
>> that's how I like it to work.
>>
>>
> Ah, you probably mean that you would not want the superclass pool
> dictionaries to be inherited, right?
>
> Nicolas
>
>
>> Cheers, Peter
>>
>> BTW Hannes, I'm not sure I would be able to change this in Dolphin, but
>> in the other dialects, probably. But like I said, there is no need, it is
>> Squeak (and Cuis) that's the odd one out.
>>
>> On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org>
>> wrote:
>>
>>> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>>>
>>>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>>>> ....
>>>>   I
>>>>
>>>>> recently changed the scoping rules for shared variables (I think
>>>>> they're
>>>>> done wrong in the base image). I could change what I wanted easily. So
>>>>> I
>>>>> think I am not in some outsider author group. Instead I am happy that I
>>>>> could change what I wanted without needing anyone's approval or
>>>>> cooperation.
>>>>>
>>>>
>>> Great!
>>>
>>>  A note:
>>>> This applies to any version / distribution of Smalltalk. But it means
>>>> that you have your own version of the core system.
>>>>
>>>> Could you elaborate on the issue of the shared variables, maybe it is
>>>> something to include in the core Cuis image?
>>>>
>>>> --Hannes
>>>>
>>>
>>> Agree. It would be nice to know.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> _______________________________________________
>>> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150722/ab140f14/attachment-0003.html>

From peter at aba-instituut.nl  Wed Jul 22 05:57:44 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 22 Jul 2015 12:57:44 +0200
Subject: [Cuis] (Rescued) Re:  Fwd: Re: DIRECT version number
In-Reply-To: <20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
Message-ID: <CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>

Hi Ken,

On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

> On Tue, 21 Jul 2015 07:59:47 -0700
> Peter van Rooijen <peter at aba-instituut.nl> wrote:
>
> >> I was thinking: "What should a Feature Test be?".
>
> I tend to think of a hierarchy of requirements.  Perhaps something like:
>
>  Feature requireAll: #( <feature name>.. ).
>  Classes requireAll: #( <class name>.. ).
>  Methods requireAll: #( <selector name>.. ).
>  MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).
>  Tests requireAllPass: #( <unit test name> ).
>

Yeah, that's not at all what I'm thinking :). I'm thinking of something
that is automatically runnable, like a unit test. It tests something, like
a un test. But if the test does not pass, it is NOT a bug, unlike with a
unit test. It's just that we would like to know about it. Also, with nit
tests there is the assumption that the code that represents the test is
always compilable, with feature tests that cannot be assumed, so there
would need to be protection against that. Of course we want to be able to
load the feature tests in any condition, so putting it in the form of
source text and compiling that is a possibility. The fact that that makes
it slower than unit tests is not a problem, because unlike unit tests, we
don't have to run them continuously.


> The Feature class lets us require named (macro) Features with a version
> check.  I prefer that requirements at this level actually load the packages
> required and only report failure if that is not possible, although we could
> have a "preflight" verson which just checks without loading any featured
> packages.
>

I see. The thing I was thinking about merely reports about the state of a
system (of code), it does not try to configure that in any way.


>
> API's are basically "protocols", which in the absence of symbolic
> execution means checking that classes and specific method selectors exist,
> or more specifically, method selectors are applicable to specific KindOf:
> classes.
>

Well, in my mind some semantics could be expected (and tested for). For
instance I might be interested if there is a DateTime class in the image
and if it implements the ANSI DateAndTime protocol (not sure if there is
one named that). Or perhaps another class that does that. These tests can
test some actual semantics no problem.

Perhaps some of you remember that Camp Smalltalk started with Ralph
Johnson's desire to build an ANSI test suite. The way people went about it
(extension methods to SUnit? I don't really remember) was wrong and could
not possibly work (in my opinion anyway), but I could not convince a lot of
people and such a test suite was never written. But with Feature Tests I
think we could come a long way.

>
> Further, some Unit Tests may be required to pass to ensure compliance with
> some specification.
>

Well, except that the tests would not be unit tests in the strictest sense.
But semantics, not merely interface, can be tested for sure.

>
> We should be able to automate at least some of this


Automate the running of the feature tests? Of course.


> including a first pass of generating the test sets, which could then be
> pruned by hand as required.
>

That I don't see happening. You test what YOU think is important to be sure
of. No machine can decide/calculate that for you. Perhaps I'm
misunderstanding you.

Cheers, Peter


>
> $0.02,
> -KenD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150722/32a7fa87/attachment-0003.html>

From peter at aba-instituut.nl  Wed Jul 22 06:29:05 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 22 Jul 2015 13:29:05 +0200
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
Message-ID: <CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>

I'm thinking about some features (pun not intentional) of this Feature Test
framework:

1. It's reasonable to assume that many tests will depend on something else
working, but that cannot be counted on, and
we would not want to repeat testing for that and also would not run into it
failing all the time and that filling our feedback.

1a. So it would make sense to add a #precondition method to each Feature
Test class.

FeatureAnsiArray
    class
        precondition

        self run: 'Array' "i.e. the global Array must be present"

then only if the precondition for the class is satisfied, will the test
methods be executed. so if most of them start with

'Array new ?' then they would all fail anyway so we don't need to test them.

2. You would want to be able to assure that in a particular object you
would be able to access a particular variable.

so in the test method you would write:

FeatureTest1
    class
        test1

        self setContext: OrderdCollection new

        self run: 'elements' "determine if the inst var elements is present
in a new OrderedCollection"

        self run: 'elements == nil' expect: false

        self run: 'elements isOrderedCollection' expect: true

let's say the test runner would continue testing even if something failed,
e.g. the array is called array, not elements. then we already know that the
following expressions will fail

so we might instead write:

        self run: 'elements' ifFail: [^self]

 3. Instead of implicitly testing for a global using run: 'NameOfTheGlobal'
or for a class var using setContext: and then run'NameOfTheClassVar' there
could be convenience methods for

        self expectGlobal: 'NameOfTheGlobal' "argument may be given as a
Symbol as well"

        self expectClass: 'NameOfTheClass' "additionally verified that the
global holds a class"

        self expectSharedVariable: 'Foo' inClass: 'Bar'

this would make for nicer feedback since the expectation is made clearer

Okay just 2 more cents!

Cheers, Peter



On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen <peter at aba-instituut.nl>
wrote:

> Hi Ken,
>
> On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <Ken.Dickey at whidbey.com>
> wrote:
>
>> On Tue, 21 Jul 2015 07:59:47 -0700
>> Peter van Rooijen <peter at aba-instituut.nl> wrote:
>>
>> >> I was thinking: "What should a Feature Test be?".
>>
>> I tend to think of a hierarchy of requirements.  Perhaps something like:
>>
>>  Feature requireAll: #( <feature name>.. ).
>>  Classes requireAll: #( <class name>.. ).
>>  Methods requireAll: #( <selector name>.. ).
>>  MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).
>>  Tests requireAllPass: #( <unit test name> ).
>>
>
> Yeah, that's not at all what I'm thinking :). I'm thinking of something
> that is automatically runnable, like a unit test. It tests something, like
> a un test. But if the test does not pass, it is NOT a bug, unlike with a
> unit test. It's just that we would like to know about it. Also, with nit
> tests there is the assumption that the code that represents the test is
> always compilable, with feature tests that cannot be assumed, so there
> would need to be protection against that. Of course we want to be able to
> load the feature tests in any condition, so putting it in the form of
> source text and compiling that is a possibility. The fact that that makes
> it slower than unit tests is not a problem, because unlike unit tests, we
> don't have to run them continuously.
>
>
>> The Feature class lets us require named (macro) Features with a version
>> check.  I prefer that requirements at this level actually load the packages
>> required and only report failure if that is not possible, although we could
>> have a "preflight" verson which just checks without loading any featured
>> packages.
>>
>
> I see. The thing I was thinking about merely reports about the state of a
> system (of code), it does not try to configure that in any way.
>
>
>>
>> API's are basically "protocols", which in the absence of symbolic
>> execution means checking that classes and specific method selectors exist,
>> or more specifically, method selectors are applicable to specific KindOf:
>> classes.
>>
>
> Well, in my mind some semantics could be expected (and tested for). For
> instance I might be interested if there is a DateTime class in the image
> and if it implements the ANSI DateAndTime protocol (not sure if there is
> one named that). Or perhaps another class that does that. These tests can
> test some actual semantics no problem.
>
> Perhaps some of you remember that Camp Smalltalk started with Ralph
> Johnson's desire to build an ANSI test suite. The way people went about it
> (extension methods to SUnit? I don't really remember) was wrong and could
> not possibly work (in my opinion anyway), but I could not convince a lot of
> people and such a test suite was never written. But with Feature Tests I
> think we could come a long way.
>
>>
>> Further, some Unit Tests may be required to pass to ensure compliance
>> with some specification.
>>
>
> Well, except that the tests would not be unit tests in the strictest
> sense. But semantics, not merely interface, can be tested for sure.
>
>>
>> We should be able to automate at least some of this
>
>
> Automate the running of the feature tests? Of course.
>
>
>> including a first pass of generating the test sets, which could then be
>> pruned by hand as required.
>>
>
> That I don't see happening. You test what YOU think is important to be
> sure of. No machine can decide/calculate that for you. Perhaps I'm
> misunderstanding you.
>
> Cheers, Peter
>
>
>>
>> $0.02,
>> -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/20150722/5bba2659/attachment-0003.html>

From Ken.Dickey at whidbey.com  Wed Jul 22 08:58:12 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Wed, 22 Jul 2015 06:58:12 -0700
Subject: [Cuis] (Rescued) Re:  Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
Message-ID: <20150722065812.da4e892dbe35764801607ace@whidbey.com>

On Wed, 22 Jul 2015 12:57:44 +0200
Peter van Rooijen <peter at aba-instituut.nl> wrote:

> Hi Ken,
> 
> On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> 
> > On Tue, 21 Jul 2015 07:59:47 -0700
> > Peter van Rooijen <peter at aba-instituut.nl> wrote:
> >
> > >> I was thinking: "What should a Feature Test be?".
> >
> > I tend to think of a hierarchy of requirements.  Perhaps something like:
> >
> >  Feature requireAll: #( <feature name>.. ).
> >  Classes requireAll: #( <class name>.. ).
> >  Methods requireAll: #( <selector name>.. ).
> >  MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).
> >  Tests requireAllPass: #( <unit test name> ).
> >
> 
> Yeah, that's not at all what I'm thinking :). I'm thinking of something
> that is automatically runnable, like a unit test. It tests something, like
> a un test. But if the test does not pass, it is NOT a bug, unlike with a
> unit test. It's just that we would like to know about it. Also, with nit
> tests there is the assumption that the code that represents the test is
> always compilable, with feature tests that cannot be assumed, so there
> would need to be protection against that. ...

Remember the phrase "agreeing loudly"?

OK, so you want the "preflight option" for Feature check.

To not "fail a test" one has to test in sequence.

- Are the Features present (as in Feature require: #<whatever> )
- Are the classes present?
- Do the method selectors exist?
- Are the right protocols there (method selectors exist for specific classes; e.g. #isFoo: is a method on a class for some aClass isKindOf: <foo>).
- What code is expected to yield a specific result (actually run some code to check, like, well, a unit test).

Failure at any step/level means something is missing and the more specific tests at the next level don't get run. 

A whole hierarchy of tests can be bundled as one Feature Test.

How is this different than what you are proposing?

-- 
-KenD



From pbpublist at gmail.com  Wed Jul 22 14:19:16 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 22 Jul 2015 15:19:16 -0400
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
	<CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>
Message-ID: <1437592756.2326.32.camel@gmail.com>

On Wed, 2015-07-22 at 13:29 +0200, Peter van Rooijen wrote:
> I'm thinking about some features (pun not intentional) of this Feature
> Test framework:
> 
> 
> 1. It's reasonable to assume that many tests will depend on something
> else working, but that cannot be counted on, and
> we would not want to repeat testing for that and also would not run
> into it failing all the time and that filling our feedback.
> 

Why not?  I agree that these would be a different category of test in
that the dependencies would be more complex and often dependent on more
than one package, but why would their functioning be considered
optional?  If they fail, shouldn't they either be addressed right away
or explicitly deprecated?  If you make the tests easy to ignore/forget
about, they will be.  If the functionality they are testing can't be
counted on, it won't be used.

If your thinking is that these would be tests that are part of package X
but might rely on package Y which might not be loaded yet, why not
instead just make the tests part of package Z which depends on package X
and Y?  The whole idea is that these are not unit tests in that sense...
have them live where ever it is appropriate.

> 
> 1a. So it would make sense to add a #precondition method to each
> Feature Test class.
> 
> 
> FeatureAnsiArray
>     class
>         precondition
> 
>         
>         self run: 'Array' "i.e. the global Array must be present"
> 
> 
> then only if the precondition for the class is satisfied, will the
> test methods be executed. so if most of them start with
> 
> 
> 'Array new ?' then they would all fail anyway so we don't need to test
> them.
> 
> 
> 2. You would want to be able to assure that in a particular object you
> would be able to access a particular variable.
> 
> 
> so in the test method you would write:
> 
> 
> FeatureTest1
>     class
>         test1
>         
>         self setContext: OrderdCollection new
> 
> 
>         self run: 'elements' "determine if the inst var elements is
> present in a new OrderedCollection"
> 
> 
>         self run: 'elements == nil' expect: false
> 
> 
>         self run: 'elements isOrderedCollection' expect: true
> 
> 
> let's say the test runner would continue testing even if something
> failed, e.g. the array is called array, not elements. then we already
> know that the following expressions will fail
> 
> 
> so we might instead write:
> 
> 
>         self run: 'elements' ifFail: [^self]
> 
> 
> 
>  3. Instead of implicitly testing for a global using run:
> 'NameOfTheGlobal' or for a class var using setContext: and then
> run'NameOfTheClassVar' there could be convenience methods for
> 
> 
>         self expectGlobal: 'NameOfTheGlobal' "argument may be given as
> a Symbol as well"
> 
> 
>         self expectClass: 'NameOfTheClass' "additionally verified that
> the global holds a class"
> 
> 
>         self expectSharedVariable: 'Foo' inClass: 'Bar'
> 
> 
> this would make for nicer feedback since the expectation is made
> clearer

I went the other way when I did the ApiFile tests in that it didn't seem
terribly important to use most of the testing framework capabilities
(other than the overall pass/fail aspect to keep the initial PoC as
simple as possible)  So they are simply small snippets of code that
performed the desired task but didn't care where it failed (if it
failed):  the failure to successfully complete the task would be the
indicator that there was a problem and we would know that either
something being depended on had broken and needed to be fixed or that
the test needed to be updated/overhauled to represent the new way of
accomplishing the task.

My thinking was that as we started to build up a number of these, we
might start to see common breakage patterns and then we could decide
whether or not to handle that them more explicitly (whether using the
existing test framework capabilities, creating a new one, etc.)  Trying
to engineer it up front didn't seem like a great idea not knowing what
common failure states would look like yet.

> 
> 
> Okay just 2 more cents!
> 

Mine as well.  This is a worthwhile discussion/exercise IMO as we need
to get to a common understanding of what we are doing here.

> 
> Cheers, Peter
> 
> 
> 
> 
> 
> On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen
> <peter at aba-instituut.nl> wrote:
>         Hi Ken,
>         
>         On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey
>         <Ken.Dickey at whidbey.com> wrote:
>                 On Tue, 21 Jul 2015 07:59:47 -0700
>                 Peter van Rooijen <peter at aba-instituut.nl> wrote:
>                 
>                 >> I was thinking: "What should a Feature Test be?".
>                 
>                 I tend to think of a hierarchy of requirements.
>                 Perhaps something like:
>                 
>                  Feature requireAll: #( <feature name>.. ).
>                  Classes requireAll: #( <class name>.. ).
>                  Methods requireAll: #( <selector name>.. ).
>                  MethodsForKind class: <class name> requireAll:
>                 #( <selectorName>.. ).
>                  Tests requireAllPass: #( <unit test name> ).
>         
>         
>         Yeah, that's not at all what I'm thinking :). I'm thinking of
>         something that is automatically runnable, like a unit test. It
>         tests something, like a un test. But if the test does not
>         pass, it is NOT a bug, unlike with a unit test. It's just that
>         we would like to know about it. Also, with nit tests there is
>         the assumption that the code that represents the test is
>         always compilable, with feature tests that cannot be assumed,
>         so there would need to be protection against that. Of course
>         we want to be able to load the feature tests in any condition,
>         so putting it in the form of source text and compiling that is
>         a possibility. The fact that that makes it slower than unit
>         tests is not a problem, because unlike unit tests, we don't
>         have to run them continuously.
>          
>                 The Feature class lets us require named (macro)
>                 Features with a version check.  I prefer that
>                 requirements at this level actually load the packages
>                 required and only report failure if that is not
>                 possible, although we could have a "preflight" verson
>                 which just checks without loading any featured
>                 packages.
>         
>         
>         I see. The thing I was thinking about merely reports about the
>         state of a system (of code), it does not try to configure that
>         in any way.
>          
>                 
>                 API's are basically "protocols", which in the absence
>                 of symbolic execution means checking that classes and
>                 specific method selectors exist, or more specifically,
>                 method selectors are applicable to specific KindOf:
>                 classes.
>         
>         
>         Well, in my mind some semantics could be expected (and tested
>         for). For instance I might be interested if there is a
>         DateTime class in the image and if it implements the ANSI
>         DateAndTime protocol (not sure if there is one named that). Or
>         perhaps another class that does that. These tests can test
>         some actual semantics no problem.
>         
>         
>         Perhaps some of you remember that Camp Smalltalk started with
>         Ralph Johnson's desire to build an ANSI test suite. The way
>         people went about it (extension methods to SUnit? I don't
>         really remember) was wrong and could not possibly work (in my
>         opinion anyway), but I could not convince a lot of people and
>         such a test suite was never written. But with Feature Tests I
>         think we could come a long way.
>                 
>                 Further, some Unit Tests may be required to pass to
>                 ensure compliance with some specification.
>         
>         
>         Well, except that the tests would not be unit tests in the
>         strictest sense. But semantics, not merely interface, can be
>         tested for sure.
>                 
>                 We should be able to automate at least some of this
>         
>         
>         Automate the running of the feature tests? Of course.
>          
>                 including a first pass of generating the test sets,
>                 which could then be pruned by hand as required.
>         
>         
>         That I don't see happening. You test what YOU think is
>         important to be sure of. No machine can decide/calculate that
>         for you. Perhaps I'm misunderstanding you.
>         
>         
>         Cheers, Peter
>          
>                 
>                 $0.02,
>                 -KenD
>         
>         
>         
>         _______________________________________________
>         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  Thu Jul 23 08:11:37 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 10:11:37 -0300
Subject: [Cuis] Cuis Archive
In-Reply-To: <559AA39A.19585.46E7C0@dnorton.mindspring.com>
References: <559AA39A.19585.46E7C0@dnorton.mindspring.com>
Message-ID: <55B0E809.7010904@jvuletich.org>

Yes, unfortunately.

I hadn't much time for this before, but yesterday I spent over one hour 
chatting with the provider's (HostGator) support. I use them for 
cuis-smalltalk.org, jvuletich.org, personal email and the cuis mail 
list. The service is usually very reliable.

But now this happened. I swear I did not touch anything.

They opened a support ticket, and said they will fix it. I hope they do.

Apologies,
Juan Vuletich

On 7/6/2015 12:49 PM, Dan Norton wrote:
> Hi,
>
> There is nothing in the archive for July. Anybody else experiencing this?
>
>   - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Thu Jul 23 08:48:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 10:48:34 -0300
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT version
 number
Message-ID: <55B0F0B2.6090202@jvuletich.org>

Very small snip (while preparing an answer for the whole thread):

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.
> ...

Yes. Cuis is MIT, etc. You don't have any obligations, etc.

But, if you tell what are you using Cuis for, and how, that is very 
useful (and nice to know).
If you are maintaining a significant code base, if possible, tell about 
it. This will help us better support you.

It is nice to know to what extent something you do is useful for others. 
I think it is also a polite and reasonable way to say thanks to us, 
working for you.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 23 08:51:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 10:51:09 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437352771.6934.219.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
Message-ID: <55B0F14D.7010405@jvuletich.org>

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> It really comes down to what is Cuis?  Is it:
>
> 1) a minimal Smalltalk that you play around with ideas / prototype
> something in the short to intermediate term
>
> 2) a platform that you can take that idea you were playing around with,
> and if it proves out, build something more substantial from for the
> longer term
>
> 3) a completely experimental environment.  Anything can change at any
> time.  Supporting 1 is doable but 2 is doubtful.
>
> Right now, Cuis is great at 1 but seems like it should be able to handle
> both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
> all, but who knows, others may disagree.  If others look at it
> differently, I'd love to know how you look at Cuis.

I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that way.

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Thu Jul 23 09:09:24 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 23 Jul 2015 14:09:24 +0000
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55B0F14D.7010405@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<55B0F14D.7010405@jvuletich.org>
Message-ID: <CAGQxfVh5AMJnVr3i-Kc2jomzTFoug5r1u=KbJa1VX6b_jruT6A@mail.gmail.com>

1) and 2) sounds like there is a need for an Ubuntu type of approach.

Labelled releases at regular intervals -- could be semi-annually or
annually. Some of them receive important bux fixes thus constituting
Long Term Releases.

Or stable vs unstable branches in github.

In two days on the 25th of July it will be exactly 2 years after the
last release of 4.2.   :-)

A point to consider as well is that what Juan is doing constitutes a
trunk from which releases are forked from time to time by other
people. The ones who run Feature Tests ....

--Hannes

On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/19/2015 9:39 PM, Phil (list) wrote:
>> ...
>> It really comes down to what is Cuis?  Is it:
>>
>> 1) a minimal Smalltalk that you play around with ideas / prototype
>> something in the short to intermediate term
>>
>> 2) a platform that you can take that idea you were playing around with,
>> and if it proves out, build something more substantial from for the
>> longer term
>>
>> 3) a completely experimental environment.  Anything can change at any
>> time.  Supporting 1 is doable but 2 is doubtful.
>>
>> Right now, Cuis is great at 1 but seems like it should be able to handle
>> both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
>> all, but who knows, others may disagree.  If others look at it
>> differently, I'd love to know how you look at Cuis.
>
> I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that
> way.
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Thu Jul 23 09:15:15 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 11:15:15 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437443935.2300.77.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>	<1437352771.6934.219.camel@gmail.com>	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<1437443935.2300.77.camel@gmail.com>
Message-ID: <55B0F6F3.3030503@jvuletich.org>

Another specific comment:

On 7/20/2015 10:58 PM, Phil (list) wrote:
> I agree. The question is how do we accomplish this. My sense is that
> we are starting to chew up more of his time peppering him with
> questions / issues that he didn't anticipate resulting from recent
> changes.

This is a very good thing! I need to know the extent of the trouble I 
create when I change something.
This is no longer my private quest for the perfect Smalltalk-80. Your 
needs are really important now!
If some changes have issues I didn't anticipate, I need to know. This is 
another force (amongst a few others)
driving the evolution of Cuis.

> ...
> I don't think that most people will accept the compatibility through
> continual testing/fixing over a long period of time... most will likely
> give up after experiencing this for a while if they're attempting to use
> Cuis as something more than a playground.

I don't want that to happen.

> If the long term objective *isn't* for Cuis to be a platform, then an
> acceptable answer would be 'you're using it wrong'.  Or Juan could
> simply say 'yeah, ok... but I really don't want to do that...'

But now, after all these years, most of the worst, convoluted, horrible, 
apis and code inherited from Squeak have been cleaned. Right now, if I 
break something badly, and without any prior communication, it is most 
likely a mistake on my part. If I do such mistake, I'll be willing to 
fix it. I think this has happened a few times in this last couple of years.


>> ...
>> As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful.  I heard that the Arabic word for "miracle" literally translates to "breaking the habit".  Interesting thought.
>> ...

Hehehe. Yes.

> I know you're generally pretty level headed and not looking to be
> disagreeable.  I engaged in this discussion because it is an important
> one to have and it felt like the right time to have it. A lot of what is
> being proposed is a change from how things have historically been.  But
> at the same time the pace of change has slowed down (ah, those whirlwind
> 1.x and 2.x days... :-) so it *seems* like trying to start to try to
> stabilize things a bit has relatively little downside.  (Dunno... maybe
> Juan is working on chucking the whole Magnitude hierarchy or something
> major like that right now...)

:D

No, the only important API change we have planned is to move from 
FileDirectory to FileMan.

We'll be doing relatively risky stuff, but not with the objective of 
changing APIs, although that might be a consequence. Some things I'd 
like to work in the next months / years are:
- Spur. The Spur object format requires a few changes in the compiler 
and core classes
- 64 bit. Having 64 and 32 bit images might also break stuff (?)
- Bootstrap from sources
- Switch to Morphic 3

Maybe I'm forgetting about something... And at some point, if possible, 
I'd like to integrate (or support and use as optional packages) Ropes 
and Unicode from Ken, VMMaker, code generation, VM simulation. Morphic 
programming for app developers should be easier and more convenient... 
And we might come up with other cool stuff to be done, that could 
perhaps impact a bit on APIs used by others...

>> What is the simplest thing that will work?
>> -KenD
>

That is indeed the question we need to answer.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 23 09:25:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 11:25:49 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437341905.6934.99.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>	
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
Message-ID: <55B0F96D.4010706@jvuletich.org>

Hi Phil,

This is  very good and stong advocacy on documented public APIs. Thank you!

(a few comments inline)
On 7/19/2015 6:38 PM, Phil (list) wrote:
> On Sun, 2015-07-19 at 11:20 -0300, Juan Vuletich wrote:
>> Hi Folks,
>>
>> (inline)
>>
>> On 7/17/2015 3:45 PM, Phil (list) wrote:
>>> ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>>>> Thank you Juan, for answering.
>>>>>
>>>>> At the moment I feel uncomfortable using Cuis because it is currently
>>>>> a quite fast moving target. I perceive quite a number of API changes
>>>>> though this might be wrong. But I do not know because there are no
>>>>> release notes which summarize it.
>>> I totally feel Hannes' pain having gone through it a few times myself
>>> over the years.  At the same time, I agree with Ken's point about not
>>> getting too bogged down in process since we're in the best position
>>> right now to break things for the better longer term.
>>>
>>>> Yes, that's true. Besides, we don't have a specification of what is an
>>>> API and what is not. So, almost any change can be considered an API change.
>>> That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
>>> issue, not specific to Cuis)  I believe it is largely fixable without
>>> tons of documentation and tests: the use of private (categories or
>>> method naming convention).  Bernhard pointed out an existing capability
>>> a few months ago
>>> http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
>>> While I personally like the idea of private categories, one of these
>>> approaches should really be seriously considered.
>>>
>>> Other than a few specific examples (i.e. mostly the base data types
>>> including the Collection and Number class hierarchies which are pretty
>>> mature and don't change all that much anyway) I would guesstimate that
>>> <20% (probably closer to 10%) of the methods, and and unknown % of
>>> classes (a significantly larger fraction though), should even be
>>> considered public.  If things were indicated as private that would
>>> accomplish two things:
>>>
>>> 1) We could construct some simple tooling (some combination of up-front
>>> warnings in the editor and/or a lint-type tester after the fact) that
>>> would allow people to identify problematic calls within their code.
>>> (i.e. just because it works now doesn't mean it always will if you keep
>>> calling X, Y, Z...)
>>>
>>> 2) It would provide a way for people to know if something needs to be
>>> discussed.  i.e. 'In class X method Y is private but I need that type of
>>> functionality' so you would know that there's a need and could consider
>>> either making it public, and therefore supported, or rethinking its
>>> implementation if you'd like to offer a better public API solution.
>> Ok. Doing something along these lines would be great. But please note
>> that it is a rather large amount of work. It is not something I'm able
>> or willing to do it alone. If you (any of you all, not just Phil) wants
>> to start defining the API for any part of the system or optional
>> packages, please start doing it and send the changesets to the list. If
>> we get this working, I'll start the tools you mention.
>>
> Agreed that this is a lot of work and I definitely wasn't expecting you
> to do it (other than reviewing the work for approval/rejection.)  I'll
> be happy to work on this with anyone else who is interested.
>
>> <slowly diverging into OT rant>
>>
>> On the other hand (and please forgive me if this kills a bit of
>> momentum), I don't really think we are changing APIs that much. And I
>> don't think we'll be doing it any more in the future than we do today,
>> at least in the base image. I hope to see most of the activity and
>> incompatible changes to happen in optional packages, and affecting
>> package dependencies... Mhhh, now that I write this I think that it
>> doesn't really go against the idea of defining APIs. Maybe APIs in the
>> base image will almost never change or be a problem, but packages should
>> provide APIs too... Optional packages will (I hope!) always be
>> improving, and new ones will appear all the time.
>>
> You'd likely be very surprised.  I'd say there's usually at least a
> couple changes a month that breaks something, somewhere in my code.  A
> few recent examples that have been discussed on the list: removing clone
> broke OpenGL a bit (easy fix thanks to the on-list discussion), removing
> compilerClass killed OMeta, a while back you were considering removing
> storeString which would again break OMeta. etc. (that's just a few
> things off the top of my head from the last few months and note that all
> were probably considered minor, inconsequential changes)  However the
> issue snowballs quickly if one misses a few updates and some of the
> breakage is related to changes that weren't discussed on the list or
> otherwise documented.  I've been managing through this recently (the
> last 6 months or so) by upgrading my image very quickly after you commit
> changes but I doubt most people would be able / willing to have that
> level of diligence.
>
> A lot of this breakage is no one's 'fault', it's just how a lot of
> Smalltalk code has been historically written.  Two examples of how this
> happens:
>
> 1) For ports of existing code, you're subject to the whims of the
> original author who often used techniques described in the next item to
> write their code.  And of course, code coming from Squeak/Pharo means
> that there were often 10 or more possible ways they could have
> implemented parts of their solution.  So after porting a few different
> packages, you have several different approaches to the same kinds of
> problems.
>
> 2) For one's own code because there is currently no distinction between
> public and private, you tend to go either with what you already know or
> whatever the first thing you find poking around the image that appears
> to make sense and work.  Even in Cuis, there are still usually multiple
> ways to do most things, so you end up arbitrarily picking one or two
> that you like.  As a result, you quickly end up with a potpourri of
> calls that may or may not be the best way to do things.  Over time, you
> start building new code on top of this code and quickly end up with a
> house of cards that comes crashing down as the result of a subsequent
> image update.  Again, this often results in each of us as authors
> deciding on superficially different solutions to the same problems.
>
> I'm not expecting you to not do things that might break my, or anyone
> else's code, going forward.  Like Hannes, I'm just looking for ways to
> help manage through the changes and breakage.  One of the key aspects of
> this is to have an opinion and to say 'hey, here are the one or two ways
> we should be doing this'.  There may be disagreement and discussion as
> to what those one or two ways are, but at the end of the day we need to
> settle these issues so that both your and our lives are manageable.
> That's really the main thing that a public API is, IMO.  There may be
> all sorts of internal helper methods and implementation details needed
> to make it all work, but like the cells of a living organism, these
> details should be hidden and their use discouraged.  Hey, didn't someone
> say something along those lines once? :-)

Yes. :)

>> If all this work, the Cuis will be a lot less about my personal effort
>> and coding style, and the packages maintained by each one of us will
>> become the main characters in this story. And this will be a very good
>> thing. The base image should be about providing a good base for doing
>> the really interesting stuff on top...
>>
> I both agree (that the packages become more important) and disagree
> (that Cuis fades into the background).  I still view the core Cuis image
> as the philosophical and stylistic backbone that all of my stuff is
> based on.  It's a constant reminder to clean up and get rid of as much
> cruft as possible in my code (especially for the packages that have yet
> other packages dependent on them)  I freely admit that I am mostly
> falling short in my execution on this front, but it would be easy to
> lose sight of entirely if Cuis didn't stay the course.
>
>> Let me tell you a bit about how Cuis got started. Many years ago I did
>> my thesis on audio/music processing. The I wanted to turn that into a
>> novel and fun application for musicians (both pros and anyone willing to
>> play with sound). I started to think about how a good GUI for that could
>> be, giving the feeling of modifying sound by direct manipulation of it,
>> as if it was clay, as if it was visual and not just auditory. Well, that
>> was the start of my questioning of the whole GUI business and Morphic 3.
>> And it became clear to me that Squeak had turned into something that was
>> not the best possible environment to do all this. The idea of "fixing"
>> Squeak, and thus make Cuis, was born. So, Cuis was not and end in
>> itself, but a means for allowing experimentation, freedom to build
>> applications in new styles, etc.
>>
>> (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other
>> came later, as an observation on facts.)
>>
>> So, when the moment comes when Cuis stabilizes a bit, and interest moves
>> to packages and applications built by all us, Cuis will start to fulfill
>> its original objective.
>>
> It's already this is as far as I'm concerned.  I can't tell you much
> time I burned just trying to extract OpenGL from Croquet so that I could
> load it into Squeak, for example.  It was painful on both sides, and by
> the time I was done I had to think for a bit to remind myself what my
> original objective was... I have *never* had this issue with Cuis.
>
> It is absolutely enabling me to play around with ideas and build things
> that I couldn't have / wouldn't have bothered in Squeak.  The only issue
> I'm having is that once I've built it, I want to keep it running :-)
>
>> </slowly diverging into OT rant>
> Not at all a rant as it reaffirms *why* you're doing what you're doing.
> If you lost sight of that, that's when I'd start worrying about Cuis.
>
>>>> ...
>>>> The problem, I think, is not identifying well defined Cuis releases. The
>>>> problem is knowing how updates could affect your code
>>> By narrowing the scope of what the public API is using private
>>> designators, this dramatically reduces what you need to be concerned
>>> with on this front.  It's part of the reason that Apple, Google, and
>>> even Microsoft are so adamant about public APIs these days.  They dealt
>>> with the pain of even major developers depending on private APIs for
>>> decades. It's only been in the last 10 years or so that they've been
>>> able to dig themselves out from under this issue.
>>>
>>> This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
>>> attitude of 'you have the source, play around, have fun!' has morphed
>>> into 'everything is a public API!  there are no rules! isn't this
>>> great?'  Well no, it's not great.  It makes life impossible for image
>>> maintainers (Squeak has been in a coma for the last decade or so as the
>>> result of trying to keep everyone happy... yet no one seems to be) and
>>> miserable for those who are trying to keep code running on it (stuff
>>> still breaks all the time.)
>> Yes.
>>
>>> I personally believe the minimalism and simplicity that Cuis is based on
>>> has the best long term prospects but we have to get out of this
>>> 'everything is public' mindset.  Sure, we have all the source: look at
>>> it, learn from it, poke around, refactor it, submit fixes, etc.  But
>>> there needs to be a manageable subset of it which is considered the
>>> 'public API' that people can depend on to write frameworks and apps on
>>> top of that is relatively stable longer term.  Let's start defining what
>>> that is and backfill changes to the public API (which will happen from
>>> time to time as we don't want things to be completely static) with tests
>>> and documentation so you can focus your efforts on where they matter
>>> most and you get the most enjoyment from.
>> I fully agree and support this.
>> Maybe an alternative to yet-another-convention-on-categories could be to
>> mark public methods with a pragma, or make them send 'self publicAPI' or
>> such... This could be better for the tools, also.
>>
> I like your idea better re: rather than having to go through and mark
> the majority as private, just mark the minority as public.  I'm open to
> either of your proposed approaches.  I just tossed out the two (method
> categories and naming) I was aware of but agree that they would not do
> much to ease developing tools to support/enforce.  Of the two ideas, am
> I correct in believing that pragma would have the lowest runtime
> overhead?  Are there any downsides you can think of to using pragma?

No that I can think of. A bit of experimentation is in order.

> Speaking of enforcing, I am not proposing that we make this a
> straight-jacket for anyone: it should be easy to opt-out the way things
> like underscore assignment are (except for pp which I'm still trying to
> get to an easily repro example with... :-) so that anyone who doesn't
> care about this isn't forced into it.  On the other hand, for people who
> do care, they should be able to leave it 'enabled', whatever that ends
> up meaning, and get help from the tooling to help them minimize
> potential future breakage.  The downside to opting out would be that
> you, as the author opting out, have decided to take it entirely on
> yourself to keep your code running across builds/releases.

Sure.

>>> ...
>>>> I don't have that either. I run the tests from time to time (I'll start
>>>> doing it before any commit, and add the xml report to the rep). But this
>>>> is not the most important reason why Cuis is solid. Cuis is very
>>>> reliable because:
>>> reliable != stable
>> ;)
>>
>>>> - I'm not too bad as a coder.
>>>> - I do my own code revisions at least one day after each change.
>>>> - I use Cuis every day, and spot most problems in the updates, before
>>>> commtting them to the repo.
>>>> - I really, really care about code quality.
>>>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>>>> is a big responsibility, given how important I think Smalltalk-80 is.
>>>>
>>> Agree to all this and more.  Cuis would not be where it is without your
>>> continued effort and diligence. (i.e. setting aside that you obviously
>>> created it, if you had just tossed it out into the world and let it go
>>> at best it would have started looking something like Squeak or Pharo by
>>> now.  It's a lot of effort over the long term to *keep* it small and
>>> focused.  THANK YOU JUAN!)
>> Thanks for your nice words, Phil. I really appreciate that you all
>> accept this rather restrictive dev model for the base image, in contrast
>> with a more open trunk style. Hopefully, as the base image becomes
>> stable and almost irrelevant, this will be each time less of a problem.
>>
>>>> So, I suggest running your tests when updating your image, or migrating
>>>> your code to an updated image.
>>> +1 to tests as they do help quite a bit and are a very good practice.
>>> Just be judicious in what/where you test (I personally don't subscribe
>>> to the TDD approach where you spend your days mostly writing tests.
>>> That's just admitting defeat in that you spend all day writing
>>> executable documentation.)
>> <OT>
>>
>> I don't subscribe to "extreme" TDD either. To me design is a creative
>> activity, both technical and artistic. It should be "driven" by
>> creativity and intelligence, not by a process. Any xDD process is
>> admitting defeat on design itself!
>>
> Heh... I like the way you put that.
>
>> </OT>
>>
>>>> In any case, I think this doesn't answer your concerns. What you need is
>>>> some way to know which updates could affect you, to review them in
>>>> detail, and understanding their effect on your code. A list of the
>>>> affected classes and/or methods for each update makes no sense. Cuis can
>>>> already show you that very easily. Perhaps each update should include:
>>>>
>>>> 1) parts of the system that are affected:
>>>> - Kernel
>>>> - Compiler
>>>> - Tools
>>>> - Morphic
>>>> - etc
>>>>
>>>> 2) Level of risk involved
>>>> - very unlikely to break code that depends on this part of the system
>>>> - could perhaps break code that depends on this part of the system
>>>> - will most likely break code that depends on this part of the system
>>>>
>>>> Or something like that.
>>>>
>>>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>>>> free to answer there if you agree.
>>> One final thought on this:  I suspect a major cause of people abandoning
>>> Cuis (and Smalltalk in general), behind the 'it's too different from
>>> what I'm used to'/'not mainstream' reaction, is the instability of its
>>> APIs.
>> Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem)
>> is a PITA too...
> True, neither extreme (changing nothing vs. changing everything) works
> very well.<cough>Perl 6</cough>  :-)
>
>> As a bottom line, let me repeat: This is too big for me to do it.
>> Please, folks, start documenting the APIs you most care about.
>>
> Ready to go... we just need to agree on how to do it (pragma/method
> call/method category/method name?)  Also, this is most definitely
> related to the 'Canonical test cases?' thread from a few months ago as
> these types of test cases / docs are part of the backfill I was
> referring to.

I think pragmas are the best options. Also, "API existence tests" should 
ask for those APIs to be declared as public.

> As I've been writing this it occurs to me that there's probably a pretty
> easy way to go about getting started on this: IIRC, there are ~1,500
> distinct method names in the core image.  If I do a count of how many
> times my code is calling any of those methods, that should pop out what,
> for my code, is the low hanging fruit.  The long-tail of say 1-5 calls
> for the lesser used methods are the tedious work that will take more
> effort for me to sort through.  We could use my 'short list' to at least
> provide a starting point and using these most frequently called methods
> you could scan through the list and could say 'hey, why are you calling
> X instead of Y?' or maybe you'd get some visibility in the sense of
> 'wow, I didn't think that was being used'.  Hmm... I've got some
> analysis to do...

And some automated scripts to generate thos pragmas to write :)

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 23 09:59:38 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 11:59:38 -0300
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
	checking them and Releases)
Message-ID: <55B1015A.2080109@jvuletich.org>

Hi Folks,

I've just re-read the very rich threads related to this. Thank you all 
for thoughtful and valuable considerations and opinions. This mail 
attempts to make really small summary, to start taking action.

First, the easiest. Releases
-------------------------------------
Several of you see real value on doing a few named releases per year. 
Theres' no big downside, so, let's do it. I think this is a good time to 
do a release. So, I'll refrain to introduce any major changes, except 
important bugfixes. Please start testing / updating / fixing your 
packages and applications. When we are all happy, and we all agree that 
the whole ecosystem is in a healthy state, we'll call that a release.

We need a name for this release. The obvious choice is "Cuis4.3-nnnn". 
So, there might be a Cuis4.3-2456, and as that branch evolves, a 
Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha" 
updates of Cuis4.4. So, I guess #2459 would be (a potential risky 
change) for Cuis 4.4. What if later we need to apply some patch to the 
stable Cuis4.3? How would we name it?

After a bit of discussion, I can take action. Or you can volunteer for 
Release Manager or member of the Release Team for Cuis 4.3.

Next, Documented, Public APIs
-------------------------------------------

Use pragmas, like PubicAPI (some method we intend to support and keep in 
that hierarchy), or CalledFromOutside (some method our yet-to-be-written 
tool detects as called from another package). Write tools for analyzing 
them. Do not remove them without due discussion.

It should be possible to write tests for existence of APIs.

This area is new to us, and we'll learn as we go.

Anybody can take action here. Documenting APIs by hand, writing tools to 
try to autogenerate them, writing tests that check for existence of 
specific APIs, whatever you can come up with.

This sounds like a major strategic direction, and in a very early stage, 
so maybe we'd not include anything of this in the Cuis4.3 release, but 
make this the start of the Cuis4.4 effort.

Thoughts? Or feel free to start coding!

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Thu Jul 23 16:26:38 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 23 Jul 2015 17:26:38 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <CAGQxfVh5AMJnVr3i-Kc2jomzTFoug5r1u=KbJa1VX6b_jruT6A@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com> <55B0F14D.7010405@jvuletich.org>
	<CAGQxfVh5AMJnVr3i-Kc2jomzTFoug5r1u=KbJa1VX6b_jruT6A@mail.gmail.com>
Message-ID: <1437686798.2326.73.camel@gmail.com>

On Thu, 2015-07-23 at 14:09 +0000, H. Hirzel wrote:
> 1) and 2) sounds like there is a need for an Ubuntu type of approach.
> 
> Labelled releases at regular intervals -- could be semi-annually or
> annually. Some of them receive important bux fixes thus constituting
> Long Term Releases.
> 

LTS releases are a *lot* of work and add quite a bit of drag.
Back-porting can be as much work as forward-porting (sometimes more.)  I
was thinking we start off as streamlined as possible: when 4.3 is
released, it becomes the stable branch.  At some point 4.4 (or whatever
version # makes sense) is nearing release and there is some period of RC
status for it.  When 4.4 goes stable, 4.3 is retired an so on.  That way
we only have one stable release at a time to be concerned with.

Also on the subject of LTS, I think we want to be careful not to get
into a Debian mode of operation.  That results in extreme stability at
the price of glacially slow change.

> Or stable vs unstable branches in github.
> 
> In two days on the 25th of July it will be exactly 2 years after the
> last release of 4.2.   :-)
> 

It's safe to say 2 years is a bit long between stable releases while 3
months would probably be too short.  I like yearly, but every 6 months
works too.  Since there's probably going to be a period of something
along the lines of RC status (a week?  a month?  no idea...) you don't
want the releases too often or you're chewing up a lot of time preparing
and testing releases and people are complaining that releases are too
frequent.  But that's just me spit-balling... I'm fine with whatever
people prefer.

> A point to consider as well is that what Juan is doing constitutes a
> trunk from which releases are forked from time to time by other
> people. The ones who run Feature Tests ....
> 

How this gets implemented depends largely on Juan's preference.  I guess
the way I envisioned it is that most of the changes being made could go
directly to stable (i.e. they are *mostly* bug fixes and behind the
scenes improvements).  Unless I'm mistaken, no one is really complaining
that a change might temporarily break something as the fixes for those
is almost always quick to arrive and don't require changes on our end
(at least nothing that I can recall.)  This would be more about changes
that will break/alter the behavior of the public APIs (i.e. there's good
reason to expect code breakage), either that goes into a
development/alpha branch or could be managed similarly to how I
*believe* Juan is handling Morphic 3 (i.e. changesets/packages that
don't get applied to stable but rather batched up until they're ready
for release driven both by the development effort and release timing)

For example, the FileMan code is something that I would be fine having
introduced in the middle of a stable branch's lifecycle.  Just don't
'flip the switch' on it (i.e. breaking code compatibility from an API
standpoint) until the next major stable release when there is sufficient
notice and documentation for people to make the move.  For me, it's all
a question of 'will the change break my code?'  I rather like bug fixes,
new features, and workflow improvements enough that to the extent
possible these should be encouraged in stable.  Would that be too
aggressive for you?

> --Hannes
> 
> On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:
> > On 7/19/2015 9:39 PM, Phil (list) wrote:
> >> ...
> >> It really comes down to what is Cuis?  Is it:
> >>
> >> 1) a minimal Smalltalk that you play around with ideas / prototype
> >> something in the short to intermediate term
> >>
> >> 2) a platform that you can take that idea you were playing around with,
> >> and if it proves out, build something more substantial from for the
> >> longer term
> >>
> >> 3) a completely experimental environment.  Anything can change at any
> >> time.  Supporting 1 is doable but 2 is doubtful.
> >>
> >> Right now, Cuis is great at 1 but seems like it should be able to handle
> >> both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
> >> all, but who knows, others may disagree.  If others look at it
> >> differently, I'd love to know how you look at Cuis.
> >
> > I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that
> > way.
> >
> > Cheers,
> > Juan Vuletich
> >
> > _______________________________________________
> > 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 pbpublist at gmail.com  Thu Jul 23 17:09:02 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 23 Jul 2015 18:09:02 -0400
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
 checking them and Releases)
In-Reply-To: <55B1015A.2080109@jvuletich.org>
References: <55B1015A.2080109@jvuletich.org>
Message-ID: <1437689342.2326.88.camel@gmail.com>

On Thu, 2015-07-23 at 11:59 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> I've just re-read the very rich threads related to this. Thank you all 
> for thoughtful and valuable considerations and opinions. This mail 
> attempts to make really small summary, to start taking action.

My quick summary to your previous replies: I agree!  :-)

> 
> First, the easiest. Releases
> -------------------------------------
> Several of you see real value on doing a few named releases per year. 
> Theres' no big downside, so, let's do it. I think this is a good time to 
> do a release. So, I'll refrain to introduce any major changes, except 
> important bugfixes. Please start testing / updating / fixing your 
> packages and applications. When we are all happy, and we all agree that 
> the whole ecosystem is in a healthy state, we'll call that a release.
> 
> We need a name for this release. The obvious choice is "Cuis4.3-nnnn". 
> So, there might be a Cuis4.3-2456, and as that branch evolves, a 
> Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha" 
> updates of Cuis4.4. So, I guess #2459 would be (a potential risky 
> change) for Cuis 4.4. What if later we need to apply some patch to the 
> stable Cuis4.3? How would we name it?
> 

My .02 on how we might manage the different branches is in my latest
reply to Hannes.  If you're happy with the way you're managing Morphic
3, why not start with that approach?  Or you could use two git branches
and periodically merge fixes from stable into development while you're
working on it, then merge development back into stable for release... or
something like that.  I'll defer to what you think will work best for
your workflow here...

> After a bit of discussion, I can take action. Or you can volunteer for 
> Release Manager or member of the Release Team for Cuis 4.3.
> 

Consider me volunteered.  I'll be happy to help in whatever way I can...
how can I best do that?  

> Next, Documented, Public APIs
> -------------------------------------------
> 
> Use pragmas, like PubicAPI (some method we intend to support and keep in 
> that hierarchy), or CalledFromOutside (some method our yet-to-be-written 
> tool detects as called from another package). Write tools for analyzing 
> them. Do not remove them without due discussion.
> 
> It should be possible to write tests for existence of APIs.
> 
> This area is new to us, and we'll learn as we go.
> 

Yep.  Undiscovered Country and it will likely take a few iterations to
get to what makes sense.

> Anybody can take action here. Documenting APIs by hand, writing tools to 
> try to autogenerate them, writing tests that check for existence of 
> specific APIs, whatever you can come up with.
> 
> This sounds like a major strategic direction, and in a very early stage, 
> so maybe we'd not include anything of this in the Cuis4.3 release, but 
> make this the start of the Cuis4.4 effort.
> 

Agreed.  Besides, I don't think we'll have even version 1 of APIs ready
for 4.3. (because the stable API stuff will likely still be, umm...
unstable)

> Thoughts? Or feel free to start coding!
> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From Ken.Dickey at whidbey.com  Thu Jul 23 02:13:17 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Thu, 23 Jul 2015 15:13:17 +0800
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
 checking them and Releases)
In-Reply-To: <55B1015A.2080109@jvuletich.org>
References: <55B1015A.2080109@jvuletich.org>
Message-ID: <20150723151317.b0caaf647bf8aecf6ec1491b@whidbey.com>

On Thu, 23 Jul 2015 11:59:38 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> We need a name for this release. The obvious choice is "Cuis4.3-nnnn". 
> So, there might be a Cuis4.3-2456, and as that branch evolves, a 
> Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha" 
> updates of Cuis4.4. So, I guess #2459 would be (a potential risky 
> change) for Cuis 4.4. What if later we need to apply some patch to the 
> stable Cuis4.3? How would we name it?

How about a fork with the suffix "-stable" ?

E.g. "4.2-stable", "4.3-stable", ...  The revisions on these would be independent of the main development thread.  Only bugfixes and (rare) backports.

$0.02
-KenD



From Ken.Dickey at whidbey.com  Thu Jul 23 22:39:03 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Thu, 23 Jul 2015 20:39:03 -0700
Subject: [Cuis] Morph default position
Message-ID: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>

My panels lost their titles.

This was because the WindowTitleMorphs were created and added to the window without setting the morphPosition to 0 at 0, so they were at 50 at 50, way outside the viewport of the windows.

Not difficult to fix, but there is a tension between being required to set morphPosition when/before/during addMorph* method sends and only setting morphPosition when the default is not desired.

FYI,
-KenD



From pbpublist at gmail.com  Fri Jul 24 03:26:52 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 24 Jul 2015 04:26:52 -0400
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT
 version number
In-Reply-To: <55B0F0B2.6090202@jvuletich.org>
References: <55B0F0B2.6090202@jvuletich.org>
Message-ID: <1437726412.2326.290.camel@gmail.com>

Juan,

On Thu, 2015-07-23 at 10:48 -0300, Juan Vuletich wrote:
> Very small snip (while preparing an answer for the whole thread):
> 
> On 7/19/2015 9:39 PM, Phil (list) wrote:
> > ...
> > communicated.  However, a problem I think he faces right now is that he
> > doesn't know who's using / depending on what.
> > ...
> 
> Yes. Cuis is MIT, etc. You don't have any obligations, etc.
> 
> But, if you tell what are you using Cuis for, and how, that is very 
> useful (and nice to know).
> If you are maintaining a significant code base, if possible, tell about 
> it. This will help us better support you.
> 

(You wrote this first but I responded to it last... still couldn't get
it as short as I had hoped... :-)

Much of what I am currently doing in Cuis falls into the broad
categories of data processing, visualization/simulation and prototyping.

1) Data processing: Lots of importers and exporters.  The data I need is
all over the place both on my local filesystem/network as well as from
various Internet sources in just about every format you can imagine
whether it's munging some HTML if that's the only place I can find what
I need or processing some XML, SQLite, other text/binary data files (it
totally depends on the data source: whatever the source uses is what I'm
stuck with.  Additionally, I may need to emit a different format than I
took in.)  As a result, I've had to port a number of packages (some of
which I still maintain, others I've deprecated as things like FFI and
XML have become core Cuis packages) and write my own to support both
getting data into and back out of Cuis.  If all the task I'm doing
requires is data processing, this might be the end of the story: suck
the data in from whatever source/format, perform any needed processing,
and spit it back out to whatever destination/format.

2) Visualization/simulation: often I'm not just doing a simple data
conversion, so once the data is in Cuis I might need to do some analysis
to see what I'm dealing with, generate some charts/graphs, visualize
relationships within a data set or the results of a simulation, etc.
Sometimes it's tabular data, sometimes 2D image data, sometimes 3D,
sometimes temporal (tabular|2D|3D.) This is why I've got both Morphic
and OpenGL code lying around: for quick and easy 2D Morphic is hard to
beat, 3D and/or performance requirements push you to OpenGL.

3) Prototyping: most of the 'production' code I'm dealing with is in
other languages (Java for Android apps as an example). However, I find
non-dynamic languages unpleasant to prototype in.  So I find myself
quite often playing around with my ideas in Cuis even though the
implementation target might be a different language/environment.  This
is all over the place in terms of the 'what' (UI, networking, algorithm,
etc.)  Sometimes these prototypes often result in more code related to 1
and 2. Sometimes I decide that I could re-use whatever I was working on
in Cuis too, so I keep it.  Recently, I've started thinking a bit
differently about this one. (see 4)

1 and 2 almost always go together in some way.  3 is sometimes
standalone, but more and more it includes 1 and/or 2.  All together, I'd
estimate that the uses described above has resulted in about 100K LoC
across dozens of Cuis project files.  Lots of little things, depending
on lots of other little things.

An example of how this all fits together for me just using mostly core
Cuis packages for something you're probably quite familiar with:  I need
to do work on some SVG files.  No problem: XML parser can help there.
But they're out on a web site: easy, use Protocols-HTTP.  Parse the
file: now I depend on some of my framework code that depends on XML
parser since XML parser only deals with structure, not content.  Doh!
The SVG has embedded images: grab the compression and PNG support
(Graphics-File-Additional) packages.  Now the file is loaded and fully
parsed and you want to look at it: grab some Morphic code for that.
Need it to draw fast?  Use OpenGL + yet more framework code instead...
and OpenGL adds an FFI dependency.  So you've now got basic SVG support
with 8 packages and are ready to start doing the actual work which will
require additional packages.  This is both probably not impressive as it
might sound (it's only a subset of SVG, structured in a particular way)
and somewhat oversimplified (uses some custom extensions) but you get
the idea.  It's pretty clean and modular and things can pretty quickly
touch a couple dozen packages for a single task.  Most of my stuff is a
lot of this sort of thing. (i.e. a fair bit of work just to get the data
into a usable internal format. Once in, life gets easier until it's time
to export...)

Some future plans/projects:

4) As a result of spending more time with OMeta, I'm becoming convinced
that I can increase my usage beyond what I describe in 3: design and
build a prototype in Cuis and actually emit the code for the target
platform/environment.  With OMeta, code becomes just another data
source / target so why not? (minor detail of frameworks that I make
hand-wavy motions when reminded of... )  This is on my longer term wish
list and seems doable, it's just a lot of work to get there.  For things
like OpenGL/GPU compute it's looking to be a necessity.  For other
platform targets the payoff is less certain but this is interesting
enough that I don't care... I'll probably try to do it regardless of
whether or not it turns out to be a good idea :-)

5) For web apps, I've been finding Seaside quite nice to work with and
have been steadily increasing the things I'm using it for over the last
couple of years.  While this isn't yet Cuis related, it seems like there
are enough of us interested in something like this that at some point
we'll either figure out how to get Seaside ported or come up with
another solution.  At that point, Cuis will have permeated just about
every aspect of my development life :-)

> It is nice to know to what extent something you do is useful for others. 
> I think it is also a polite and reasonable way to say thanks to us, 
> working for you.
> 

Absolutely.  That's also part of the reason I publish the packages I've
needed to port.  Life would have been so much simpler if someone had
taken care of that part so I didn't have to.  So, I push them out in the
hopes that it might save someone the trouble of having to deal with it
just as all of your efforts and others who have contributed to Cuis have
made my life easier.

> Cheers,
> Juan Vuletich

Thanks,
Phil




From pbpublist at gmail.com  Fri Jul 24 05:23:46 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 24 Jul 2015 06:23:46 -0400
Subject: [Cuis] Morph default position
In-Reply-To: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
References: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
Message-ID: <1437733426.2326.295.camel@gmail.com>

On Thu, 2015-07-23 at 20:39 -0700, Ken.Dickey wrote:
> My panels lost their titles.
> 
> This was because the WindowTitleMorphs were created and added to the window without setting the morphPosition to 0 at 0, so they were at 50 at 50, way outside the viewport of the windows.
> 
> Not difficult to fix, but there is a tension between being required to set morphPosition when/before/during addMorph* method sends and only setting morphPosition when the default is not desired.
> 

Insetting Morphs seemed like such a harmless suggestion...

> FYI,
> -KenD
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Fri Jul 24 07:00:12 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 24 Jul 2015 09:00:12 -0300
Subject: [Cuis] Morph default position
In-Reply-To: <1437733426.2326.295.camel@gmail.com>
References: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
	<1437733426.2326.295.camel@gmail.com>
Message-ID: <55B228CC.6000102@jvuletich.org>

Hi Folks,

On 7/24/2015 7:23 AM, Phil (list) wrote:
> On Thu, 2015-07-23 at 20:39 -0700, Ken.Dickey wrote:
>> My panels lost their titles.
>>
>> This was because the WindowTitleMorphs were created and added to the window without setting the morphPosition to 0 at 0, so they were at 50 at 50, way outside the viewport of the windows.
>>
>> Not difficult to fix, but there is a tension between being required to set morphPosition when/before/during addMorph* method sends and only setting morphPosition when the default is not desired.
>>
> Insetting Morphs seemed like such a harmless suggestion...

Uh, apologies. I also thought it would harmless. I'll take back that 
change, and set an offset only when adding to World.

Regards,
Juan Vuletich



From hannes.hirzel at gmail.com  Fri Jul 24 08:56:04 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Fri, 24 Jul 2015 13:56:04 +0000
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
 checking them and Releases)
In-Reply-To: <55B1015A.2080109@jvuletich.org>
References: <55B1015A.2080109@jvuletich.org>
Message-ID: <CAGQxfVgvt5b8AqF+se1mKrkwptFSSYFq3hOdxivuf1x=DvN8RA@mail.gmail.com>

On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:

Thanks for this summary, I think it captures what we have discussed.

Two comments below

--Hannes

> Hi Folks,
>
> I've just re-read the very rich threads related to this. Thank you all
> for thoughtful and valuable considerations and opinions. This mail
> attempts to make really small summary, to start taking action.
>
> First, the easiest. Releases
> -------------------------------------
> Several of you see real value on doing a few named releases per year.
> Theres' no big downside, so, let's do it. I think this is a good time to
> do a release. So, I'll refrain to introduce any major changes, except
> important bugfixes. Please start testing / updating / fixing your
> packages and applications. When we are all happy, and we all agree that
> the whole ecosystem is in a healthy state, we'll call that a release.
>
> We need a name for this release. The obvious choice is "Cuis4.3-nnnn".
> So, there might be a Cuis4.3-2456, and as that branch evolves, a
> Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha"
> updates of Cuis4.4. So, I guess #2459 would be (a potential risky
> change) for Cuis 4.4. What if later we need to apply some patch to the
> stable Cuis4.3? How would we name it?
>
> After a bit of discussion, I can take action. Or you can volunteer for
> Release Manager or member of the Release Team for Cuis 4.3.

A suggestion: label the version of tomorrow as Cuis 4.3

and then have a period (4...8 weeks?) where only bug fixes are allowed
and then release a version Cuis 4.4


Cuis 4.3 would then be what KenD calls a 'baseline' to measure against
until we have 4.4

>
> Next, Documented, Public APIs
> -------------------------------------------
>
> Use pragmas, like PubicAPI (some method we intend to support and keep in
> that hierarchy), or CalledFromOutside (some method our yet-to-be-written
> tool detects as called from another package). Write tools for analyzing
> them. Do not remove them without due discussion.
>
> It should be possible to write tests for existence of APIs.
>
> This area is new to us, and we'll learn as we go.
>
> Anybody can take action here. Documenting APIs by hand, writing tools to
> try to autogenerate them, writing tests that check for existence of
> specific APIs, whatever you can come up with.
>
> This sounds like a major strategic direction, and in a very early stage,
> so maybe we'd not include anything of this in the Cuis4.3 release, but
> make this the start of the Cuis4.4 effort.
>
> Thoughts? Or feel free to start coding!

I think we should start coding with FeatureTests which check for the
presence of classes and methods.

As independent packages in various repositories, after some
evaluation/testing/checking they should go to the packages folder.

> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From Ken.Dickey at whidbey.com  Fri Jul 24 09:10:02 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 24 Jul 2015 07:10:02 -0700
Subject: [Cuis] Morph default position
In-Reply-To: <55B228CC.6000102@jvuletich.org>
References: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
	<1437733426.2326.295.camel@gmail.com>
	<55B228CC.6000102@jvuletich.org>
Message-ID: <20150724071002.1a76620f39adb183005b4715@whidbey.com>

On Fri, 24 Jul 2015 09:00:12 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Uh, apologies. I also thought it would harmless. I'll take back that 
> change, and set an offset only when adding to World.

Or just add 
 Morph>>defaultPosition
	^ 50 at 50

And let subclasses override when it makes a difference..

$0.02
-KenD



From dnorton at mindspring.com  Fri Jul 24 15:20:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 24 Jul 2015 16:20:35 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AD7737.30003@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>,
	<55AD7737.30003@jvuletich.org>
Message-ID: <55B29E13.29241.F06B25@dnorton.mindspring.com>

On 20 Jul 2015 at 19:33, Juan Vuletich wrote:

> 
> Hi Dan,
> 
> On 7/19/2015 10:13 PM, Dan Norton wrote:
>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
> 
>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>     > >
>     > >> Hi Folks,
>     > >>
>     > >> It is not too hard to build new StrikeFonts. You need to
> build,
>     > by
>     > >> hand,
>     > >> files like the ones in here:
>     > >>
>     >
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>     > >> p
>     > >> and learn a bit about stuff like #installDejaVu2 . Maybe it
> was
>     > with
>     > >> this method and the files in this zip that built the
> existing
>     > >> instances
>     > >> of StrikeFont. Not sure.
>     > >>
>     > > That's intrigueing but I can't reproduce it. Maybe the .bmp
> but
>     > where did you get the .txt?
>     > >
>     > >?? - Dan
>     >
>     > I wrote them with a text editor. Check #installDejaVu2 and
> really
>     > try to
>     > understand how StrikeFonts work and how they are built with
> this
>     > method.
>     > Maybe you'll become enlightened.
>     >
> 
>     A StrikeFont consists of a characterToGlyphMap, xTable, glyphs,
> name, and several 
>     scalars. StrikeFont class methods create fonts by processing
> file pairs assumed to be in the 
>     "AAFonts" subdirectory. For example:
> 
>     DejaVu Sans Oblique 14.bmp
>     DejaVu Sans Oblique 14.txt
> 
>     Is one such pair providing the italic (oblique) style for
> 14-point size. There is a pair for every 
>     font size and style: base, bold, italic, and bold italic.
> Therefore a font such as "DejaVu Sans" 
>     which is available in the size interval 5 to 24 requires 160
> files. The file names are stylized 
>     and encoded in the StrikeFont class methods.
> 
>     Glyphs come from the .bmp file. The .txt file is a string of
> numbers; the first three specify 
>     pointSize, ascent, and?descent. The rest of the numbers in the
> .txt file are used to form the 
>     xTable, which is the index into the glyphs for a character. The
> characterToGlyphMap is an 
>     array of 256 entries which map a character's ascii value to the
> xTable and thence to the 
>     glyphs.
> 
>     The bold, italic, and bold italic styles are stashed as
> derivatives of the base and not 
>     selectable from the current menus.
> 
>     StrikeFont is a subclass of AbstractFont, which has class
> variables AvailableFonts and 
>     DefaultFont.
> 
>     If it can't find a file, StrikeFont will loop.
> 
> Great! You got it all.
> 
>     In regard to creating the .bmp and .txt files, you say, " I
> wrote them with a text editor." 
>     Please tell me which text editor you used. None of mine do
> that.
> 
> The bmp files can be created with screen capture program, after
> entering suitable text in it. Maybe 
> you need to stitch several pieces together, etc. WRT the txt files,
> well, the editor didn't do it for 
> me. I wrote them. I _typed_ them. Maybe I used some (long lost) code
> to look for white columns 
> separating glyphs, but I'm not really sure. #xTallyPixelValue:orNot:
> and friends are great for this 
> kind of stuff.
> 
> In any case, it will be easier for you, as you want a monospaced
> font. Printing something like (32 
> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might be
> enough.
> 
> You have all the pieces at hand. it just requires a bit of
> patience.
> 

Encouraged by this, I have tried cobbling a fixed-width StrikeFont from Courier New which 
comes with Windows7. At this point, if some kind of fixed-width smudges would appear then 
it would be progress. Here's where I am:

The immediate problem is an error: 'Unsupported format. Try 
"Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter 
class>>formFromStream: examines the .bmp file.

Higher in the context, Form class>>fromBinaryStream: has firstByte = 66 which I mention 
because of the way the .bmp file was made. Here is the process I used, from the bottom up:

ImageMagick freeware	 produces the glyphs but with something stubbornly prepended. The 
command line is:
	convert -font \windows\fonts\cour.ttf -pointsize 12 label:@characters.txt 
courier12.bmp

Using NotePad, save characters.txt with encoding: UTF-8.

Paste the character string onto a NotePad

Copy the character string.

In a Cuis workspace print:
	str := String new writeStream.
	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
	str contents.

Code package and files allegedly for courier strike fonts are attached if you're 
interested.

 - Dan
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150724/bf929021/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CourierExample.zip
Type: application/zip
Size: 25150 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150724/bf929021/attachment-0003.zip>

From hannes.hirzel at gmail.com  Sat Jul 25 08:00:45 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 25 Jul 2015 13:00:45 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B29E13.29241.F06B25@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
	<55AD7737.30003@jvuletich.org>
	<55B29E13.29241.F06B25@dnorton.mindspring.com>
Message-ID: <CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>

I would try to save the *.bmp file as a *.gif file in Microsoft Paint
and then try to load it with

ImageReadWriter class>>formFromStream:

HTH

--HH

On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
>
>>
>> Hi Dan,
>>
>> On 7/19/2015 10:13 PM, Dan Norton wrote:
>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>>
>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>>     > >
>>     > >> Hi Folks,
>>     > >>
>>     > >> It is not too hard to build new StrikeFonts. You need to
>> build,
>>     > by
>>     > >> hand,
>>     > >> files like the ones in here:
>>     > >>
>>     >
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>>     > >> p
>>     > >> and learn a bit about stuff like #installDejaVu2 . Maybe it
>> was
>>     > with
>>     > >> this method and the files in this zip that built the
>> existing
>>     > >> instances
>>     > >> of StrikeFont. Not sure.
>>     > >>
>>     > > That's intrigueing but I can't reproduce it. Maybe the .bmp
>> but
>>     > where did you get the .txt?
>>     > >
>>     > >?? - Dan
>>     >
>>     > I wrote them with a text editor. Check #installDejaVu2 and
>> really
>>     > try to
>>     > understand how StrikeFonts work and how they are built with
>> this
>>     > method.
>>     > Maybe you'll become enlightened.
>>     >
>>
>>     A StrikeFont consists of a characterToGlyphMap, xTable, glyphs,
>> name, and several
>>     scalars. StrikeFont class methods create fonts by processing
>> file pairs assumed to be in the
>>     "AAFonts" subdirectory. For example:
>>
>>     DejaVu Sans Oblique 14.bmp
>>     DejaVu Sans Oblique 14.txt
>>
>>     Is one such pair providing the italic (oblique) style for
>> 14-point size. There is a pair for every
>>     font size and style: base, bold, italic, and bold italic.
>> Therefore a font such as "DejaVu Sans"
>>     which is available in the size interval 5 to 24 requires 160
>> files. The file names are stylized
>>     and encoded in the StrikeFont class methods.
>>
>>     Glyphs come from the .bmp file. The .txt file is a string of
>> numbers; the first three specify
>>     pointSize, ascent, and?descent. The rest of the numbers in the
>> .txt file are used to form the
>>     xTable, which is the index into the glyphs for a character. The
>> characterToGlyphMap is an
>>     array of 256 entries which map a character's ascii value to the
>> xTable and thence to the
>>     glyphs.
>>
>>     The bold, italic, and bold italic styles are stashed as
>> derivatives of the base and not
>>     selectable from the current menus.
>>
>>     StrikeFont is a subclass of AbstractFont, which has class
>> variables AvailableFonts and
>>     DefaultFont.
>>
>>     If it can't find a file, StrikeFont will loop.
>>
>> Great! You got it all.
>>
>>     In regard to creating the .bmp and .txt files, you say, " I
>> wrote them with a text editor."
>>     Please tell me which text editor you used. None of mine do
>> that.
>>
>> The bmp files can be created with screen capture program, after
>> entering suitable text in it. Maybe
>> you need to stitch several pieces together, etc. WRT the txt files,
>> well, the editor didn't do it for
>> me. I wrote them. I _typed_ them. Maybe I used some (long lost) code
>> to look for white columns
>> separating glyphs, but I'm not really sure. #xTallyPixelValue:orNot:
>> and friends are great for this
>> kind of stuff.
>>
>> In any case, it will be easier for you, as you want a monospaced
>> font. Printing something like (32
>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might be
>> enough.
>>
>> You have all the pieces at hand. it just requires a bit of
>> patience.
>>
>
> Encouraged by this, I have tried cobbling a fixed-width StrikeFont from
> Courier New which
> comes with Windows7. At this point, if some kind of fixed-width smudges
> would appear then
> it would be progress. Here's where I am:
>
> The immediate problem is an error: 'Unsupported format. Try
> "Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter
> class>>formFromStream: examines the .bmp file.
>
> Higher in the context, Form class>>fromBinaryStream: has firstByte = 66
> which I mention
> because of the way the .bmp file was made. Here is the process I used, from
> the bottom up:
>
> ImageMagick freeware	 produces the glyphs but with something stubbornly
> prepended. The
> command line is:
> 	convert -font \windows\fonts\cour.ttf -pointsize 12 label:@characters.txt
> courier12.bmp
>
> Using NotePad, save characters.txt with encoding: UTF-8.
>
> Paste the character string onto a NotePad
>
> Copy the character string.
>
> In a Cuis workspace print:
> 	str := String new writeStream.
> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
> 	str contents.
>
> Code package and files allegedly for courier strike fonts are attached if
> you're
> interested.
>
>  - Dan
>
>



From hannes.hirzel at gmail.com  Sat Jul 25 08:14:38 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 25 Jul 2015 13:14:38 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
	<55AD7737.30003@jvuletich.org>
	<55B29E13.29241.F06B25@dnorton.mindspring.com>
	<CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>
Message-ID: <CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>

I did the StrikeFont exercises in Squeak. So it could be that Squeak
has a BMP file reader which is no longer included in Cuis. A thing to
check....

--HH

On 7/25/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> I would try to save the *.bmp file as a *.gif file in Microsoft Paint
> and then try to load it with
>
> ImageReadWriter class>>formFromStream:
>
> HTH
>
> --HH
>
> On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
>> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
>>
>>>
>>> Hi Dan,
>>>
>>> On 7/19/2015 10:13 PM, Dan Norton wrote:
>>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>>>
>>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>>>     > >
>>>     > >> Hi Folks,
>>>     > >>
>>>     > >> It is not too hard to build new StrikeFonts. You need to
>>> build,
>>>     > by
>>>     > >> hand,
>>>     > >> files like the ones in here:
>>>     > >>
>>>     >
>>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>>>     > >> p
>>>     > >> and learn a bit about stuff like #installDejaVu2 . Maybe it
>>> was
>>>     > with
>>>     > >> this method and the files in this zip that built the
>>> existing
>>>     > >> instances
>>>     > >> of StrikeFont. Not sure.
>>>     > >>
>>>     > > That's intrigueing but I can't reproduce it. Maybe the .bmp
>>> but
>>>     > where did you get the .txt?
>>>     > >
>>>     > >?? - Dan
>>>     >
>>>     > I wrote them with a text editor. Check #installDejaVu2 and
>>> really
>>>     > try to
>>>     > understand how StrikeFonts work and how they are built with
>>> this
>>>     > method.
>>>     > Maybe you'll become enlightened.
>>>     >
>>>
>>>     A StrikeFont consists of a characterToGlyphMap, xTable, glyphs,
>>> name, and several
>>>     scalars. StrikeFont class methods create fonts by processing
>>> file pairs assumed to be in the
>>>     "AAFonts" subdirectory. For example:
>>>
>>>     DejaVu Sans Oblique 14.bmp
>>>     DejaVu Sans Oblique 14.txt
>>>
>>>     Is one such pair providing the italic (oblique) style for
>>> 14-point size. There is a pair for every
>>>     font size and style: base, bold, italic, and bold italic.
>>> Therefore a font such as "DejaVu Sans"
>>>     which is available in the size interval 5 to 24 requires 160
>>> files. The file names are stylized
>>>     and encoded in the StrikeFont class methods.
>>>
>>>     Glyphs come from the .bmp file. The .txt file is a string of
>>> numbers; the first three specify
>>>     pointSize, ascent, and?descent. The rest of the numbers in the
>>> .txt file are used to form the
>>>     xTable, which is the index into the glyphs for a character. The
>>> characterToGlyphMap is an
>>>     array of 256 entries which map a character's ascii value to the
>>> xTable and thence to the
>>>     glyphs.
>>>
>>>     The bold, italic, and bold italic styles are stashed as
>>> derivatives of the base and not
>>>     selectable from the current menus.
>>>
>>>     StrikeFont is a subclass of AbstractFont, which has class
>>> variables AvailableFonts and
>>>     DefaultFont.
>>>
>>>     If it can't find a file, StrikeFont will loop.
>>>
>>> Great! You got it all.
>>>
>>>     In regard to creating the .bmp and .txt files, you say, " I
>>> wrote them with a text editor."
>>>     Please tell me which text editor you used. None of mine do
>>> that.
>>>
>>> The bmp files can be created with screen capture program, after
>>> entering suitable text in it. Maybe
>>> you need to stitch several pieces together, etc. WRT the txt files,
>>> well, the editor didn't do it for
>>> me. I wrote them. I _typed_ them. Maybe I used some (long lost) code
>>> to look for white columns
>>> separating glyphs, but I'm not really sure. #xTallyPixelValue:orNot:
>>> and friends are great for this
>>> kind of stuff.
>>>
>>> In any case, it will be easier for you, as you want a monospaced
>>> font. Printing something like (32
>>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might be
>>> enough.
>>>
>>> You have all the pieces at hand. it just requires a bit of
>>> patience.
>>>
>>
>> Encouraged by this, I have tried cobbling a fixed-width StrikeFont from
>> Courier New which
>> comes with Windows7. At this point, if some kind of fixed-width smudges
>> would appear then
>> it would be progress. Here's where I am:
>>
>> The immediate problem is an error: 'Unsupported format. Try
>> "Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter
>> class>>formFromStream: examines the .bmp file.
>>
>> Higher in the context, Form class>>fromBinaryStream: has firstByte = 66
>> which I mention
>> because of the way the .bmp file was made. Here is the process I used,
>> from
>> the bottom up:
>>
>> ImageMagick freeware	 produces the glyphs but with something stubbornly
>> prepended. The
>> command line is:
>> 	convert -font \windows\fonts\cour.ttf -pointsize 12
>> label:@characters.txt
>> courier12.bmp
>>
>> Using NotePad, save characters.txt with encoding: UTF-8.
>>
>> Paste the character string onto a NotePad
>>
>> Copy the character string.
>>
>> In a Cuis workspace print:
>> 	str := String new writeStream.
>> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
>> 	str contents.
>>
>> Code package and files allegedly for courier strike fonts are attached if
>> you're
>> interested.
>>
>>  - Dan
>>
>>
>



From dnorton at mindspring.com  Sat Jul 25 10:40:19 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 25 Jul 2015 11:40:19 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>,
	<CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>
Message-ID: <55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>

Form class>>fromBinaryStream: has firstByte = 66, this is not an error but part of "BM" in the header of the .bmp file.

The "Unsupported format..." error is caused by Cuis wanting biSize = 40 and ImageMagick 
putting a different value.

Squeak has BitstreamVeraSansMono, a fixed-width font. Why couldn't  that be used to 
produce .bmp files instead of ImageMagick? The BM header would be compatible with Cuis 
AFAIKT and it might get us a fixed-width font on Cuis.

On 25 Jul 2015 at 13:14, H. Hirzel wrote:

> I did the StrikeFont exercises in Squeak. So it could be that
> Squeak
> has a BMP file reader which is no longer included in Cuis. A thing
> to
> check....
> 
> --HH
> 
> On 7/25/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > I would try to save the *.bmp file as a *.gif file in Microsoft
> Paint
> > and then try to load it with
> >
> > ImageReadWriter class>>formFromStream:
> >
> > HTH
> >
> > --HH
> >
> > On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
> >> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
> >>
> >>>
> >>> Hi Dan,
> >>>
> >>> On 7/19/2015 10:13 PM, Dan Norton wrote:
> >>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
> >>>
> >>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
> >>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
> >>>     > >
> >>>     > >> Hi Folks,
> >>>     > >>
> >>>     > >> It is not too hard to build new StrikeFonts. You need
> to
> >>> build,
> >>>     > by
> >>>     > >> hand,
> >>>     > >> files like the ones in here:
> >>>     > >>
> >>>     >
> >>>
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> >>>     > >> p
> >>>     > >> and learn a bit about stuff like #installDejaVu2 .
> Maybe it
> >>> was
> >>>     > with
> >>>     > >> this method and the files in this zip that built the
> >>> existing
> >>>     > >> instances
> >>>     > >> of StrikeFont. Not sure.
> >>>     > >>
> >>>     > > That's intrigueing but I can't reproduce it. Maybe the
> .bmp
> >>> but
> >>>     > where did you get the .txt?
> >>>     > >
> >>>     > >?? - Dan
> >>>     >
> >>>     > I wrote them with a text editor. Check #installDejaVu2
> and
> >>> really
> >>>     > try to
> >>>     > understand how StrikeFonts work and how they are built
> with
> >>> this
> >>>     > method.
> >>>     > Maybe you'll become enlightened.
> >>>     >
> >>>
> >>>     A StrikeFont consists of a characterToGlyphMap, xTable,
> glyphs,
> >>> name, and several
> >>>     scalars. StrikeFont class methods create fonts by
> processing
> >>> file pairs assumed to be in the
> >>>     "AAFonts" subdirectory. For example:
> >>>
> >>>     DejaVu Sans Oblique 14.bmp
> >>>     DejaVu Sans Oblique 14.txt
> >>>
> >>>     Is one such pair providing the italic (oblique) style for
> >>> 14-point size. There is a pair for every
> >>>     font size and style: base, bold, italic, and bold italic.
> >>> Therefore a font such as "DejaVu Sans"
> >>>     which is available in the size interval 5 to 24 requires
> 160
> >>> files. The file names are stylized
> >>>     and encoded in the StrikeFont class methods.
> >>>
> >>>     Glyphs come from the .bmp file. The .txt file is a string
> of
> >>> numbers; the first three specify
> >>>     pointSize, ascent, and?descent. The rest of the numbers in
> the
> >>> .txt file are used to form the
> >>>     xTable, which is the index into the glyphs for a character.
> The
> >>> characterToGlyphMap is an
> >>>     array of 256 entries which map a character's ascii value to
> the
> >>> xTable and thence to the
> >>>     glyphs.
> >>>
> >>>     The bold, italic, and bold italic styles are stashed as
> >>> derivatives of the base and not
> >>>     selectable from the current menus.
> >>>
> >>>     StrikeFont is a subclass of AbstractFont, which has class
> >>> variables AvailableFonts and
> >>>     DefaultFont.
> >>>
> >>>     If it can't find a file, StrikeFont will loop.
> >>>
> >>> Great! You got it all.
> >>>
> >>>     In regard to creating the .bmp and .txt files, you say, "
> I
> >>> wrote them with a text editor."
> >>>     Please tell me which text editor you used. None of mine do
> >>> that.
> >>>
> >>> The bmp files can be created with screen capture program,
> after
> >>> entering suitable text in it. Maybe
> >>> you need to stitch several pieces together, etc. WRT the txt
> files,
> >>> well, the editor didn't do it for
> >>> me. I wrote them. I _typed_ them. Maybe I used some (long lost)
> code
> >>> to look for white columns
> >>> separating glyphs, but I'm not really sure.
> #xTallyPixelValue:orNot:
> >>> and friends are great for this
> >>> kind of stuff.
> >>>
> >>> In any case, it will be easier for you, as you want a
> monospaced
> >>> font. Printing something like (32
> >>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might
> be
> >>> enough.
> >>>
> >>> You have all the pieces at hand. it just requires a bit of
> >>> patience.
> >>>
> >>
> >> Encouraged by this, I have tried cobbling a fixed-width
> StrikeFont from
> >> Courier New which
> >> comes with Windows7. At this point, if some kind of fixed-width
> smudges
> >> would appear then
> >> it would be progress. Here's where I am:
> >>
> >> The immediate problem is an error: 'Unsupported format. Try
> >> "Graphics-Files-Additional.pck.st".' which arises when
> ImageReadWriter
> >> class>>formFromStream: examines the .bmp file.
> >>
> >> Higher in the context, Form class>>fromBinaryStream: has
> firstByte = 66
> >> which I mention
> >> because of the way the .bmp file was made. Here is the process I
> used,
> >> from
> >> the bottom up:
> >>
> >> ImageMagick freeware	 produces the glyphs but with something
> stubbornly
> >> prepended. The
> >> command line is:
> >> 	convert -font \windows\fonts\cour.ttf -pointsize 12
> >> label:@characters.txt
> >> courier12.bmp
> >>
> >> Using NotePad, save characters.txt with encoding: UTF-8.
> >>
> >> Paste the character string onto a NotePad
> >>
> >> Copy the character string.
> >>
> >> In a Cuis workspace print:
> >> 	str := String new writeStream.
> >> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
> >> 	str contents.
> >>
> >> Code package and files allegedly for courier strike fonts are
> attached if
> >> you're
> >> interested.
> >>
> >>  - Dan
> >>
> >>
> >
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From hannes.hirzel at gmail.com  Sat Jul 25 13:57:43 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 25 Jul 2015 18:57:43 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>
	<CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>
	<55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>
Message-ID: <CAGQxfVggp67RO7k4q8Cgh4thyi4AQTWpvwVSapXMb=LTrR3eqQ@mail.gmail.com>

Then I would try to export the Squeak BitstreamVeraSansMono in
StrikeFont format and import into Cuis. That should work ...

On 7/25/15, Dan Norton <dnorton at mindspring.com> wrote:
> Form class>>fromBinaryStream: has firstByte = 66, this is not an error but
> part of "BM" in the header of the .bmp file.
>
> The "Unsupported format..." error is caused by Cuis wanting biSize = 40 and
> ImageMagick
> putting a different value.
>
> Squeak has BitstreamVeraSansMono, a fixed-width font. Why couldn't  that be
> used to
> produce .bmp files instead of ImageMagick? The BM header would be compatible
> with Cuis
> AFAIKT and it might get us a fixed-width font on Cuis.
>
> On 25 Jul 2015 at 13:14, H. Hirzel wrote:
>
>> I did the StrikeFont exercises in Squeak. So it could be that
>> Squeak
>> has a BMP file reader which is no longer included in Cuis. A thing
>> to
>> check....
>>
>> --HH
>>
>> On 7/25/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> > I would try to save the *.bmp file as a *.gif file in Microsoft
>> Paint
>> > and then try to load it with
>> >
>> > ImageReadWriter class>>formFromStream:
>> >
>> > HTH
>> >
>> > --HH
>> >
>> > On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
>> >> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
>> >>
>> >>>
>> >>> Hi Dan,
>> >>>
>> >>> On 7/19/2015 10:13 PM, Dan Norton wrote:
>> >>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>> >>>
>> >>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>> >>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>> >>>     > >
>> >>>     > >> Hi Folks,
>> >>>     > >>
>> >>>     > >> It is not too hard to build new StrikeFonts. You need
>> to
>> >>> build,
>> >>>     > by
>> >>>     > >> hand,
>> >>>     > >> files like the ones in here:
>> >>>     > >>
>> >>>     >
>> >>>
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> >>>     > >> p
>> >>>     > >> and learn a bit about stuff like #installDejaVu2 .
>> Maybe it
>> >>> was
>> >>>     > with
>> >>>     > >> this method and the files in this zip that built the
>> >>> existing
>> >>>     > >> instances
>> >>>     > >> of StrikeFont. Not sure.
>> >>>     > >>
>> >>>     > > That's intrigueing but I can't reproduce it. Maybe the
>> .bmp
>> >>> but
>> >>>     > where did you get the .txt?
>> >>>     > >
>> >>>     > >?? - Dan
>> >>>     >
>> >>>     > I wrote them with a text editor. Check #installDejaVu2
>> and
>> >>> really
>> >>>     > try to
>> >>>     > understand how StrikeFonts work and how they are built
>> with
>> >>> this
>> >>>     > method.
>> >>>     > Maybe you'll become enlightened.
>> >>>     >
>> >>>
>> >>>     A StrikeFont consists of a characterToGlyphMap, xTable,
>> glyphs,
>> >>> name, and several
>> >>>     scalars. StrikeFont class methods create fonts by
>> processing
>> >>> file pairs assumed to be in the
>> >>>     "AAFonts" subdirectory. For example:
>> >>>
>> >>>     DejaVu Sans Oblique 14.bmp
>> >>>     DejaVu Sans Oblique 14.txt
>> >>>
>> >>>     Is one such pair providing the italic (oblique) style for
>> >>> 14-point size. There is a pair for every
>> >>>     font size and style: base, bold, italic, and bold italic.
>> >>> Therefore a font such as "DejaVu Sans"
>> >>>     which is available in the size interval 5 to 24 requires
>> 160
>> >>> files. The file names are stylized
>> >>>     and encoded in the StrikeFont class methods.
>> >>>
>> >>>     Glyphs come from the .bmp file. The .txt file is a string
>> of
>> >>> numbers; the first three specify
>> >>>     pointSize, ascent, and?descent. The rest of the numbers in
>> the
>> >>> .txt file are used to form the
>> >>>     xTable, which is the index into the glyphs for a character.
>> The
>> >>> characterToGlyphMap is an
>> >>>     array of 256 entries which map a character's ascii value to
>> the
>> >>> xTable and thence to the
>> >>>     glyphs.
>> >>>
>> >>>     The bold, italic, and bold italic styles are stashed as
>> >>> derivatives of the base and not
>> >>>     selectable from the current menus.
>> >>>
>> >>>     StrikeFont is a subclass of AbstractFont, which has class
>> >>> variables AvailableFonts and
>> >>>     DefaultFont.
>> >>>
>> >>>     If it can't find a file, StrikeFont will loop.
>> >>>
>> >>> Great! You got it all.
>> >>>
>> >>>     In regard to creating the .bmp and .txt files, you say, "
>> I
>> >>> wrote them with a text editor."
>> >>>     Please tell me which text editor you used. None of mine do
>> >>> that.
>> >>>
>> >>> The bmp files can be created with screen capture program,
>> after
>> >>> entering suitable text in it. Maybe
>> >>> you need to stitch several pieces together, etc. WRT the txt
>> files,
>> >>> well, the editor didn't do it for
>> >>> me. I wrote them. I _typed_ them. Maybe I used some (long lost)
>> code
>> >>> to look for white columns
>> >>> separating glyphs, but I'm not really sure.
>> #xTallyPixelValue:orNot:
>> >>> and friends are great for this
>> >>> kind of stuff.
>> >>>
>> >>> In any case, it will be easier for you, as you want a
>> monospaced
>> >>> font. Printing something like (32
>> >>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might
>> be
>> >>> enough.
>> >>>
>> >>> You have all the pieces at hand. it just requires a bit of
>> >>> patience.
>> >>>
>> >>
>> >> Encouraged by this, I have tried cobbling a fixed-width
>> StrikeFont from
>> >> Courier New which
>> >> comes with Windows7. At this point, if some kind of fixed-width
>> smudges
>> >> would appear then
>> >> it would be progress. Here's where I am:
>> >>
>> >> The immediate problem is an error: 'Unsupported format. Try
>> >> "Graphics-Files-Additional.pck.st".' which arises when
>> ImageReadWriter
>> >> class>>formFromStream: examines the .bmp file.
>> >>
>> >> Higher in the context, Form class>>fromBinaryStream: has
>> firstByte = 66
>> >> which I mention
>> >> because of the way the .bmp file was made. Here is the process I
>> used,
>> >> from
>> >> the bottom up:
>> >>
>> >> ImageMagick freeware	 produces the glyphs but with something
>> stubbornly
>> >> prepended. The
>> >> command line is:
>> >> 	convert -font \windows\fonts\cour.ttf -pointsize 12
>> >> label:@characters.txt
>> >> courier12.bmp
>> >>
>> >> Using NotePad, save characters.txt with encoding: UTF-8.
>> >>
>> >> Paste the character string onto a NotePad
>> >>
>> >> Copy the character string.
>> >>
>> >> In a Cuis workspace print:
>> >> 	str := String new writeStream.
>> >> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
>> >> 	str contents.
>> >>
>> >> Code package and files allegedly for courier strike fonts are
>> attached if
>> >> you're
>> >> interested.
>> >>
>> >>  - Dan
>> >>
>> >>
>> >
>>
>> _______________________________________________
>> 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 dnorton at mindspring.com  Sat Jul 25 14:34:34 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 25 Jul 2015 15:34:34 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVggp67RO7k4q8Cgh4thyi4AQTWpvwVSapXMb=LTrR3eqQ@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>,
	<CAGQxfVggp67RO7k4q8Cgh4thyi4AQTWpvwVSapXMb=LTrR3eqQ@mail.gmail.com>
Message-ID: <55B3E4CA.22470.194F1C5@dnorton.mindspring.com>

On 25 Jul 2015 at 18:57, H. Hirzel wrote:

> Then I would try to export the Squeak BitstreamVeraSansMono in
> StrikeFont format and import into Cuis. That should work ...
>

Yes, but the problem is how to get BitstreamVeraSansMono into StrikeFont format.

In Squeak 4.6, the font of a character string in the transcript can be changed from the default 
to one of the BitstreamVeraSansMono sizes: #(9 12 15 24 36). Digging down through the 
Transcript submorphs I found aTextMorphForEditView. When this is sent 
"exportAsBMPNamed: 'sansmono12.bmp'" for example, the image in the Transcript is placed 
in the .bmp file.

This needs improvement. The good news is that the glyphs appear to be sized and shaped 
based on the font. The bad news is that the .bmp file contains a multi-line image, exactly as it 
appears in the transcript and the entire first line of this appears to result from the blank (ascii 
32). The next line looks pretty good until it reaches the edge of the pane where it stops. The 
following characters are on the next line, etc.

What's needed is a morph which will contain the entire character set 32 to 255 without 
wrapping and with the desired font. That morph can be sent the #exportAsBMPNamed: 
message and then maybe we can make a strikefont.

[ snip ]

 - Dan



From juan at jvuletich.org  Sat Jul 25 16:31:18 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 25 Jul 2015 18:31:18 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B29E13.29241.F06B25@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>,
	<55AD7737.30003@jvuletich.org>
	<55B29E13.29241.F06B25@dnorton.mindspring.com>
Message-ID: <55B40026.6010208@jvuletich.org>

Hi Dan,

The format saved by image writer is not (currently) supported in Cuis, 
Squeak, etc. Maybe there is a command line option to tell imageMagick to 
use a more standard bmp format. Or you can just save in png. I opened 
them in Windows Paint, clicked on 'save' and then Cuis was able to read 
them.

Your xTables in the txt files are indeed wrong. For Courier12, the width 
of the bmp file is around 1500 pixels. And in the xTable you have 
entries calling pixels around x=2600. Impossible. Take a look at the bmp 
you generated count the width used by each glyph. It is 7 pixels wide. 
Your xTable is multiples of 12...

After fixing this 2 issues, I run your stuff and indeed it starts to 
run. It looks like a bit more work is needed in the xTable, though.

Cheers,
Juan Vuletich

On 7/24/2015 5:20 PM, Dan Norton wrote:
>
> Encouraged by this, I have tried cobbling a fixed-width StrikeFont 
> from Courier New which comes with Windows7. At this point, if some 
> kind of fixed-width smudges would appear then it would be progress. 
> Here's where I am:
>
> The immediate problem is an error: 'Unsupported format. Try 
> "Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter 
> class>>formFromStream: examines the .bmp file.
>
> Higher in the context, Form class>>fromBinaryStream: has firstByte = 
> 66 which I mention because of the way the .bmp file was made. Here is 
> the process I used, from the bottom up:
>
> ImageMagick freeware produces the glyphs but with something stubbornly 
> prepended. The command line is:
>            convert -font \windows\fonts\cour.ttf -pointsize 12 
> label:@characters.txt courier12.bmp
>
> Using NotePad, save characters.txt with encoding: UTF-8.
>
> Paste the character string onto a NotePad
>
> Copy the character string.
>
> In a Cuis workspace print:
>            str := String new writeStream.
>            (32 to: 255) do: [ :n | str nextPut: n asCharacter]
>            str contents.
>
> Code package and files allegedly for courier strike fonts are attached 
> if you're interested.
>
>  - Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150725/797d695b/attachment-0003.html>

From juan at jvuletich.org  Sat Jul 25 17:36:58 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 25 Jul 2015 19:36:58 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <20150705095751.c84ded291d123bac31348c46@whidbey.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>	<559938A2.3040204@jvuletich.org>
	<20150705095751.c84ded291d123bac31348c46@whidbey.com>
Message-ID: <55B40F8A.1030706@jvuletich.org>

I fixed this a few days ago. Please check. If there's some problem there 
yet, please complain :)

Cheers,
Juan Vuletich

Ps. It is getting a bit hard to find enough time for all this. That's 
why I'm slow answering. Please never refrain from insisting if I don't 
answer.

On 7/4/2015 10:57 PM, Ken.Dickey wrote:
> On Sun, 05 Jul 2015 11:01:06 -0300
> Juan Vuletich<juan at jvuletich.org>  wrote:
>
>> Hi Ken,
>>
>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>> Juan,
>>>
>>> The Installed Packages browser used to be able to require a minimum revision on the base release.
>>>
>>> I use this feature as a backstop when features change in the base release.
>>>
>>> Any chance in getting this ability back?
>>>
>>> Thanks much,
>>> -KenD
>> When was it lost?  I can't remember doing anything related to this...
> Not sure when.
>
> If there is more than one package loaded, one can Add Requirement with one option being the base release.  If only one package is loaded, one gets the "Required package must already be loaded" popup, rather than an option to require Cuis-Base.
>




From dnorton at mindspring.com  Sat Jul 25 20:41:03 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 25 Jul 2015 21:41:03 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <55B43AAF.12784.2E478F5@dnorton.mindspring.com>

Attached is a StrikeFont of Courier New 12. It's hacked - not polished by any means. It was 
made by:

Making "characters.txt" by printing in a Cuis workspace, copying to Notepad, and saving with 
encoding: ANSI.

This was input to ImageMagick to make a .png file.

The .png file was opened in Paint, then saved as a .bmp file.

The body of the .txt file was generated by:
(32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 - needed to avoid index out of range"

The first three numbers in .txt were finagled to 12 15 5 (the last two anyway).

The font was installed by running:
StrikeFont installCourier.  "code in Courier.pck.st "

Text in the Text Editor pane was highlighted and the font changed to Courier 12 point. It 
looked much too small. Going back to Paint, the glyphs were selected and stretched 
vertically. The font was re-installed. The vertical distortion is probably obvious.

At least it's recognizable as Courier and it's fixed width. Files are attached.

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CourierExample2.zip
Type: application/zip
Size: 10523 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150725/30c1a018/attachment-0003.zip>

From dnorton at mindspring.com  Sun Jul 26 17:47:53 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 26 Jul 2015 15:47:53 -0700 (PDT)
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT
 version number
In-Reply-To: <55B0F0B2.6090202@jvuletich.org>
References: <55B0F0B2.6090202@jvuletich.org>
Message-ID: <1437950873600-4839529.post@n4.nabble.com>


Very small snip (while preparing an answer for the whole thread):

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.
> ...

Yes. Cuis is MIT, etc. You don't have any obligations, etc.

But, if you tell what are you using Cuis for, and how, that is very 
useful (and nice to know).
If you are maintaining a significant code base, if possible, tell about 
it. This will help us better support you.


How I want to use Cuis:

Multi-player games. Juan, are you going to put your Scrabble in a Cuis
package?

App delivery sans IDE, halos, menus

Apps with feedback; output becomes next input

Recognition biometrics

Financial analysis

Anything fun

 - Dan




--
View this message in context: http://forum.world.st/Please-tell-about-your-projects-Re-Fwd-Re-DIRECT-version-number-tp4838865p4839529.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From hannes.hirzel at gmail.com  Mon Jul 27 01:54:17 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 27 Jul 2015 06:54:17 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <55B40F8A.1030706@jvuletich.org>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<559938A2.3040204@jvuletich.org>
	<20150705095751.c84ded291d123bac31348c46@whidbey.com>
	<55B40F8A.1030706@jvuletich.org>
Message-ID: <CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>

On 7/25/15, Juan Vuletich <juan at jvuletich.org> wrote:
> I fixed this a few days ago. Please check. If there's some problem there
> yet, please complain :)
>
> Cheers,
> Juan Vuletich
>
> Ps. It is getting a bit hard to find enough time for all this. That's
> why I'm slow answering. Please never refrain from insisting if I don't
> answer.

Thank you for this fix. Has it been committed?
The last commit is 8 days ago.
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/e9568515b8db6c5e251e209edae60819d7ba4b63

--Hannes


> On 7/4/2015 10:57 PM, Ken.Dickey wrote:
>> On Sun, 05 Jul 2015 11:01:06 -0300
>> Juan Vuletich<juan at jvuletich.org>  wrote:
>>
>>> Hi Ken,
>>>
>>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>>> Juan,
>>>>
>>>> The Installed Packages browser used to be able to require a minimum
>>>> revision on the base release.
>>>>
>>>> I use this feature as a backstop when features change in the base
>>>> release.
>>>>
>>>> Any chance in getting this ability back?
>>>>
>>>> Thanks much,
>>>> -KenD
>>> When was it lost?  I can't remember doing anything related to this...
>> Not sure when.
>>
>> If there is more than one package loaded, one can Add Requirement with one
>> option being the base release.  If only one package is loaded, one gets
>> the "Required package must already be loaded" popup, rather than an option
>> to require Cuis-Base.
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Mon Jul 27 01:59:47 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 27 Jul 2015 06:59:47 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<559938A2.3040204@jvuletich.org>
	<20150705095751.c84ded291d123bac31348c46@whidbey.com>
	<55B40F8A.1030706@jvuletich.org>
	<CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>
Message-ID: <CAGQxfVgT9Crbu1V7TEQ_baYf+On=7aECUMf7MzB7S6Ri4tBw0Q@mail.gmail.com>

BTW you are NOT slow in answering. Take you time.

For confirming  that the feature is back indeed
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/70

On 7/27/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> On 7/25/15, Juan Vuletich <juan at jvuletich.org> wrote:
>> I fixed this a few days ago. Please check. If there's some problem there
>> yet, please complain :)
>>
>> Cheers,
>> Juan Vuletich
>>
>> Ps. It is getting a bit hard to find enough time for all this. That's
>> why I'm slow answering. Please never refrain from insisting if I don't
>> answer.
>
> Thank you for this fix. Has it been committed?
> The last commit is 8 days ago.
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/e9568515b8db6c5e251e209edae60819d7ba4b63
>
> --Hannes
>
>
>> On 7/4/2015 10:57 PM, Ken.Dickey wrote:
>>> On Sun, 05 Jul 2015 11:01:06 -0300
>>> Juan Vuletich<juan at jvuletich.org>  wrote:
>>>
>>>> Hi Ken,
>>>>
>>>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>>>> Juan,
>>>>>
>>>>> The Installed Packages browser used to be able to require a minimum
>>>>> revision on the base release.
>>>>>
>>>>> I use this feature as a backstop when features change in the base
>>>>> release.
>>>>>
>>>>> Any chance in getting this ability back?
>>>>>
>>>>> Thanks much,
>>>>> -KenD
>>>> When was it lost?  I can't remember doing anything related to this...
>>> Not sure when.
>>>
>>> If there is more than one package loaded, one can Add Requirement with
>>> one
>>> option being the base release.  If only one package is loaded, one gets
>>> the "Required package must already be loaded" popup, rather than an
>>> option
>>> to require Cuis-Base.
>>>
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>



From juan at jvuletich.org  Mon Jul 27 09:40:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 27 Jul 2015 11:40:34 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfVgT9Crbu1V7TEQ_baYf+On=7aECUMf7MzB7S6Ri4tBw0Q@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>	<559938A2.3040204@jvuletich.org>	<20150705095751.c84ded291d123bac31348c46@whidbey.com>	<55B40F8A.1030706@jvuletich.org>	<CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>
	<CAGQxfVgT9Crbu1V7TEQ_baYf+On=7aECUMf7MzB7S6Ri4tBw0Q@mail.gmail.com>
Message-ID: <55B642E2.6040203@jvuletich.org>

On 7/27/2015 3:59 AM, H. Hirzel wrote:
> BTW you are NOT slow in answering. Take you time.

:)

> For confirming  that the feature is back indeed
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/70

Ken confirmed that it is working ok. I closed the issue.

Thanks,
Juan Vuletich

> On 7/27/15, H. Hirzel<hannes.hirzel at gmail.com>  wrote:
>> On 7/25/15, Juan Vuletich<juan at jvuletich.org>  wrote:
>>> I fixed this a few days ago. Please check. If there's some problem there
>>> yet, please complain :)
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> Ps. It is getting a bit hard to find enough time for all this. That's
>>> why I'm slow answering. Please never refrain from insisting if I don't
>>> answer.
>> Thank you for this fix. Has it been committed?
>> The last commit is 8 days ago.
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/e9568515b8db6c5e251e209edae60819d7ba4b63
>>
>> --Hannes
>>
>>
>>> On 7/4/2015 10:57 PM, Ken.Dickey wrote:
>>>> On Sun, 05 Jul 2015 11:01:06 -0300
>>>> Juan Vuletich<juan at jvuletich.org>   wrote:
>>>>
>>>>> Hi Ken,
>>>>>
>>>>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>>>>> Juan,
>>>>>>
>>>>>> The Installed Packages browser used to be able to require a minimum
>>>>>> revision on the base release.
>>>>>>
>>>>>> I use this feature as a backstop when features change in the base
>>>>>> release.
>>>>>>
>>>>>> Any chance in getting this ability back?
>>>>>>
>>>>>> Thanks much,
>>>>>> -KenD
>>>>> When was it lost?  I can't remember doing anything related to this...
>>>> Not sure when.
>>>>
>>>> If there is more than one package loaded, one can Add Requirement with
>>>> one
>>>> option being the base release.  If only one package is loaded, one gets
>>>> the "Required package must already be loaded" popup, rather than an
>>>> option
>>>> to require Cuis-Base.
>>>>
>>>
>>> _______________________________________________
>>> 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  Mon Jul 27 09:58:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 27 Jul 2015 11:58:27 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6BMwgF9pffS7TWaPKTi8EkE2X-puM=e0NQNBn1gW5Z4Pw@mail.gmail.com>
References: <CAGQxfVhtR6zezHW4Nji0kHU3str2Zf4Dbfdn5VjphgAqwnuz-g@mail.gmail.com>
	<20140501080531.493624077a7c3f67688650f9@whidbey.com>
	<CAGQxfVgeyXkyu5Rqdn2T9T+iY5rYzEVy9w76N0=scZCR+-iy3w@mail.gmail.com>
	<CAEt3aLxfNLqDJ3LhBZFdwSO5VjcPDmQcStXWiTEts8YBsWLvxw@mail.gmail.com>
	<CA+=t-6DwrOQwVB3QeTWaL=rGG7=g5J-poDh5UR9tpMXFtnsPbg@mail.gmail.com>
	<CAGQxfVg4wzvPRBg-XRP3dFWw_EbV=in7ZCiK-TzYJzV+MP9y0A@mail.gmail.com>
	<CAGQxfVjyHyA1R1aEuaNcpiyFqOG+zSy8SzqqqeD7drG8kSzZPQ@mail.gmail.com>
	<555A8705.5080502@jvuletich.org>
	<CA+=t-6C7Bh+2YRfNwEdfUJDcn=cx=NNXTc-DuWfyJ5ZbbKYeHQ@mail.gmail.com>
	<5573BD8C.4010008@jvuletich.org>
	<CA+=t-6BMwgF9pffS7TWaPKTi8EkE2X-puM=e0NQNBn1gW5Z4Pw@mail.gmail.com>
Message-ID: <55B64713.8040806@jvuletich.org>

Hi Masashi,

Recently we found that in FileMan, if we do

'inexistentFile' asFileEntry readStream

we get an empty readStream.

I think it is better to throw the #fileDoesNotExistException , as 
FileDirectory did, and let the user handle the exception appropriately. 
But I would not want to break compatibility with FileMan, as the main 
purpose of FileMan is to give compatibility amongst dialects.

Are there good reasons to avoid the exception? Should we add another 
method, besides #readStream when we want a readStream strictly on 
existing file contents?

Thanks,
Juan Vuletich


On 6/14/2015 8:38 AM, Masashi UMEZAWA wrote:
> Hello Juan,
>
> Thank you for the patches and more tests! I'll adapt those updates for
> other FileMan ports.
>
> Best regards,
>
> 2015-06-07 12:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>> Hi Masashi,
>>
>> I was trying FileMan tests today and I saw they create some folders in my
>> drive. The names looked a bit strange, so I took a closer look and found a
>> couple of bugs. At least on Windows, #testRecursiveDelete instead of
>> creating
>>        subDir/aaa/bbb/ccc/ddd/eee/fff/ggg/test1
>> it created
>>         subDir/bbb/ccc/eee/ggg/test!
>>
>> So I wrote a few more tests on the issues I saw, and teaked the code to make
>> them pass. The result is attached, and I think is useful for all ports of
>> FileMan.
>>
>> Thanks,
>> Juan Vuletich
>>
>> On 5/26/2015 11:34 PM, Masashi UMEZAWA wrote:
>>> Hi all,
>>>
>>> I think it is nice if FileMan is on the core package repository.
>>>
>>> FileMan for Cuis (and Squeak) has minimum dependencies to the existing
>>> FileDirectory and DirectoryEntry. FileMan selectively uses a few
>>> methods of them.
>>>
>>> So we can gradually adopt FileMan interfaces and trim the
>>> FileDirectory and DirectoryEntry's non-intuitive methods.
>>>
>>> Another way of cleaning-up the file-related classes is to port
>>> FileSystems to Cuis.
>>> But since Cuis is a lightweight Smalltalk dialect, FileSystems might
>>> be an overkill.
>>>
>>> Best regards,
>>>
>>> 2015-05-19 9:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>>>> Hi Folks,
>>>>
>>>> I apologize for talking before taking even a quick look, but anyway, We'd
>>>> take a good look at this. And seriously consider replacing files stuff in
>>>> Cuis base. Or at least adopting it as a core package in our repo.
>>>>
>>>> Thoughts?
>>>>
>>>> Masashi-san: opinions?
>>>>
>>>> Thanks,
>>>> Juan Vuletich
>>>>
>>>>
>>>> On 5/17/2015 12:07 PM, H. Hirzel wrote:
>>>>> Below are the comments from the FileMan package.
>>>>>
>>>>> Question: How do you compare the FileMan package to the FileSystem
>>>>> package in Pharo?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L45
>>>>> I represent a single file entry (including directory).
>>>>> You can write data by #fileContents: , and read the data by
>>>>> #fileContents.
>>>>> ---
>>>>> mu 11/6/2006 20:21!
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L53
>>>>> I represent a single file directory.
>>>>> I implement various directory specific behaviors.
>>>>> You can write data by #at:put: , and read the data by #at:.
>>>>> ---
>>>>> mu 11/6/2006 20:21
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L63
>>>>> !FmFileIOAccessor commentStamp: '<historical>' prior: 0!
>>>>> I am an accessor to the low level file IO.
>>>>> You can extend/rewrite me if you port FileMan to other Smalltalk
>>>>> dialects.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L44
>>>>> !FmBackupDirectoryEntry commentStamp: 'mu 5/4/2007 23:26' prior: 0!
>>>>> This is a simple example for adding special behaviors to
>>>>> FmDirectoryEntry.
>>>>> I backup file contents automatically, while users are not conscious
>>>>> about
>>>>> that.
>>>>> Usage:
>>>>> dir := './withBackup' asDirectoryEntry: FmBackupDirectoryEntry.
>>>>> dir at: 'text' put: 'abc'.
>>>>> dir at: 'text' put: 'def'.
>>>>> (dir at: 'text') inspect. "def"
>>>>> (dir backupAt: 'text') inspect. "abc"
>>>>> ((dir / 'sub') at: 'text2' put: '123').
>>>>> ((dir / 'sub') at: 'text2' put: '456').
>>>>> ((dir / 'sub') at: 'text2') inspect. "456"
>>>>> ((dir / 'sub') backupAt: 'text2') inspect. "123"
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L63
>>>>> This is a simple example for adding special behaviors to
>>>>> FmDirectoryEntry.
>>>>> I put and get file contents as gzipped, while users are not conscious
>>>>> about that.
>>>>> Usage:
>>>>> | dir |
>>>>> dir := './gzipped2' asDirectoryEntry: FmGZipDirectoryEntry.
>>>>> dir binaryAt: 'bin' put: #(1 2 3 12 34 56) asByteArray.
>>>>> (dir binaryAt: 'bin') inspect.
>>>>> dir at: 'text' put: 'This will be gzipped'.
>>>>> (dir at: 'text') inspect.
>>>>> I would be useful for storing/loading big contents in a simple
>>>>> dictionary-like manner.
>>>>>
>>>>>
>>>>>
>>>>> On 5/17/15, H. Hirzel<hannes.hirzel at gmail.com>    wrote:
>>>>>> Hello Masashi-san
>>>>>>
>>>>>> I'd like to come back to your FileMan package
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>
>>>>>> and ask a question.
>>>>>>
>>>>>> Is this package a port from somewhere or did you write it from scratch?
>>>>>>
>>>>>> Some background information is appreciated.
>>>>>>
>>>>>> There is no description
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L2
>>>>>>
>>>>>> Thank you in advance
>>>>>>
>>>>>> Hannes Hirzel
>>>>>>
>>>>>>
>>>>>> On 5/2/14, Masashi UMEZAWA<ume at blueplane.jp>    wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Thank you for the kind words. I've just started Cuis on March, and I
>>>>>>> was impressed with its cleanness, simplicity, etc.
>>>>>>> So I did a introductory presentation at Tokyo Smalltalkers meeting. It
>>>>>>> was successful.
>>>>>>> Now I'm planning to port Folktale (telnet-base object shell), and SIXX
>>>>>>> to Cuis. My pace maybe slow, but please stay tuned. ;)
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> 2014-05-02 1:05 GMT+09:00 Germ?n Arduino<garduino at gmail.com>:
>>>>>>>> Wow, I was completely unaware of Masashi working in Cuis! Welcome
>>>>>>>> aboard!!
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-05-01 12:19 GMT-03:00 H. Hirzel<hannes.hirzel at gmail.com>:
>>>>>>>>
>>>>>>>>> Thank you for the link to  Masashi Umezawa's presentation.
>>>>>>>>>
>>>>>>>>> It is from 2014 and talks about
>>>>>>>>>
>>>>>>>>> - the number of classes compared to Squeak and Pharo
>>>>>>>>> - the size of Morphic -- Morph allSelectors size "=>    502"
>>>>>>>>> - something I do not fully get about instance variables
>>>>>>>>>         'bounds owner submorphs fullBounds color extension'
>>>>>>>>>         versus
>>>>>>>>>        'owner submorphs location layoutNeeded layoutSpec properties'
>>>>>>>>> - layoutSpec
>>>>>>>>> - PackageInfo
>>>>>>>>> - version control with git
>>>>>>>>> - Feature require: '<PackageName>'.
>>>>>>>>> - your Unicode package
>>>>>>>>> https://github.com/KenDickey/Cuis-Smalltalk-Unicode
>>>>>>>>> - https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-StyledTextEditor
>>>>>>>>> - How to query for other Cuis-Smalltalk repositories
>>>>>>>>>                 https://github.com/search?q=cuis-smalltalk
>>>>>>>>>
>>>>>>>>> All things which we will include Cuis documentation effort.
>>>>>>>>>
>>>>>>>>> --Hannes
>>>>>>>>>
>>>>>>>>> On 5/1/14, Ken Dickey<Ken.Dickey at whidbey.com>    wrote:
>>>>>>>>>> On Thu, 1 May 2014 07:28:54 +0000
>>>>>>>>>> "H. Hirzel"<hannes.hirzel at gmail.com>    wrote:
>>>>>>>>>>
>>>>>>>>>>> A noteworthy effort
>>>>>>>>>>>
>>>>>>>>>>>          https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>>>> Yes.  Masashi Umezawa is the man in Japan!
>>>>>>>>>>
>>>>>>>>>> He should introduce himself.
>>>>>>>>>>
>>>>>>>>>> He gave a talk about Cuis at the 63rd Smalltalkers' meeting in
>>>>>>>>>> Tokyo:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://www.smalltalk-users.jp/Home/gao-zhi/dai63kaismalltalkbenkyoukai/shiryou
>>>>>>>>>>
>>>>>>>>>> Masashi has ported several packages to CUis.
>>>>>>>>>>
>>>>>>>>>> Because of Unicode interest, I was made aware that recent font
>>>>>>>>>> tweaks
>>>>>>>>>> have
>>>>>>>>>> broken my Unicode package in the latest Cuis versions.
>>>>>>>>>>
>>>>>>>>>> Masashi-san, would you care to tell us about yourself and what
>>>>>>>>>> people
>>>>>>>>>> there
>>>>>>>>>> think about Cuis?
>>>>>>>>>>
>>>>>>>>>> -KenD
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>
>>>
>
>




From hannes.hirzel at gmail.com  Mon Jul 27 13:31:24 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 27 Jul 2015 18:31:24 +0000
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <55B64713.8040806@jvuletich.org>
References: <CAGQxfVhtR6zezHW4Nji0kHU3str2Zf4Dbfdn5VjphgAqwnuz-g@mail.gmail.com>
	<20140501080531.493624077a7c3f67688650f9@whidbey.com>
	<CAGQxfVgeyXkyu5Rqdn2T9T+iY5rYzEVy9w76N0=scZCR+-iy3w@mail.gmail.com>
	<CAEt3aLxfNLqDJ3LhBZFdwSO5VjcPDmQcStXWiTEts8YBsWLvxw@mail.gmail.com>
	<CA+=t-6DwrOQwVB3QeTWaL=rGG7=g5J-poDh5UR9tpMXFtnsPbg@mail.gmail.com>
	<CAGQxfVg4wzvPRBg-XRP3dFWw_EbV=in7ZCiK-TzYJzV+MP9y0A@mail.gmail.com>
	<CAGQxfVjyHyA1R1aEuaNcpiyFqOG+zSy8SzqqqeD7drG8kSzZPQ@mail.gmail.com>
	<555A8705.5080502@jvuletich.org>
	<CA+=t-6C7Bh+2YRfNwEdfUJDcn=cx=NNXTc-DuWfyJ5ZbbKYeHQ@mail.gmail.com>
	<5573BD8C.4010008@jvuletich.org>
	<CA+=t-6BMwgF9pffS7TWaPKTi8EkE2X-puM=e0NQNBn1gW5Z4Pw@mail.gmail.com>
	<55B64713.8040806@jvuletich.org>
Message-ID: <CAGQxfVijywhcd0rCTnqz53oD0xcKnFjt8rcQ27VWuwZqqDqdYA@mail.gmail.com>

I as well opened an issue for Cuis to get mentioned.

https://github.com/mumez/FileMan/issues/1

--Hannes

On 7/27/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Masashi,
>
> Recently we found that in FileMan, if we do
>
> 'inexistentFile' asFileEntry readStream
>
> we get an empty readStream.
>
> I think it is better to throw the #fileDoesNotExistException , as
> FileDirectory did, and let the user handle the exception appropriately.
> But I would not want to break compatibility with FileMan, as the main
> purpose of FileMan is to give compatibility amongst dialects.
>
> Are there good reasons to avoid the exception? Should we add another
> method, besides #readStream when we want a readStream strictly on
> existing file contents?
>
> Thanks,
> Juan Vuletich
>
>
> On 6/14/2015 8:38 AM, Masashi UMEZAWA wrote:
>> Hello Juan,
>>
>> Thank you for the patches and more tests! I'll adapt those updates for
>> other FileMan ports.
>>
>> Best regards,
>>
>> 2015-06-07 12:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>>> Hi Masashi,
>>>
>>> I was trying FileMan tests today and I saw they create some folders in
>>> my
>>> drive. The names looked a bit strange, so I took a closer look and found
>>> a
>>> couple of bugs. At least on Windows, #testRecursiveDelete instead of
>>> creating
>>>        subDir/aaa/bbb/ccc/ddd/eee/fff/ggg/test1
>>> it created
>>>         subDir/bbb/ccc/eee/ggg/test!
>>>
>>> So I wrote a few more tests on the issues I saw, and teaked the code to
>>> make
>>> them pass. The result is attached, and I think is useful for all ports
>>> of
>>> FileMan.
>>>
>>> Thanks,
>>> Juan Vuletich
>>>
>>> On 5/26/2015 11:34 PM, Masashi UMEZAWA wrote:
>>>> Hi all,
>>>>
>>>> I think it is nice if FileMan is on the core package repository.
>>>>
>>>> FileMan for Cuis (and Squeak) has minimum dependencies to the existing
>>>> FileDirectory and DirectoryEntry. FileMan selectively uses a few
>>>> methods of them.
>>>>
>>>> So we can gradually adopt FileMan interfaces and trim the
>>>> FileDirectory and DirectoryEntry's non-intuitive methods.
>>>>
>>>> Another way of cleaning-up the file-related classes is to port
>>>> FileSystems to Cuis.
>>>> But since Cuis is a lightweight Smalltalk dialect, FileSystems might
>>>> be an overkill.
>>>>
>>>> Best regards,
>>>>
>>>> 2015-05-19 9:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>>>>> Hi Folks,
>>>>>
>>>>> I apologize for talking before taking even a quick look, but anyway,
>>>>> We'd
>>>>> take a good look at this. And seriously consider replacing files stuff
>>>>> in
>>>>> Cuis base. Or at least adopting it as a core package in our repo.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Masashi-san: opinions?
>>>>>
>>>>> Thanks,
>>>>> Juan Vuletich
>>>>>
>>>>>
>>>>> On 5/17/2015 12:07 PM, H. Hirzel wrote:
>>>>>> Below are the comments from the FileMan package.
>>>>>>
>>>>>> Question: How do you compare the FileMan package to the FileSystem
>>>>>> package in Pharo?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L45
>>>>>> I represent a single file entry (including directory).
>>>>>> You can write data by #fileContents: , and read the data by
>>>>>> #fileContents.
>>>>>> ---
>>>>>> mu 11/6/2006 20:21!
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L53
>>>>>> I represent a single file directory.
>>>>>> I implement various directory specific behaviors.
>>>>>> You can write data by #at:put: , and read the data by #at:.
>>>>>> ---
>>>>>> mu 11/6/2006 20:21
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L63
>>>>>> !FmFileIOAccessor commentStamp: '<historical>' prior: 0!
>>>>>> I am an accessor to the low level file IO.
>>>>>> You can extend/rewrite me if you port FileMan to other Smalltalk
>>>>>> dialects.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L44
>>>>>> !FmBackupDirectoryEntry commentStamp: 'mu 5/4/2007 23:26' prior: 0!
>>>>>> This is a simple example for adding special behaviors to
>>>>>> FmDirectoryEntry.
>>>>>> I backup file contents automatically, while users are not conscious
>>>>>> about
>>>>>> that.
>>>>>> Usage:
>>>>>> dir := './withBackup' asDirectoryEntry: FmBackupDirectoryEntry.
>>>>>> dir at: 'text' put: 'abc'.
>>>>>> dir at: 'text' put: 'def'.
>>>>>> (dir at: 'text') inspect. "def"
>>>>>> (dir backupAt: 'text') inspect. "abc"
>>>>>> ((dir / 'sub') at: 'text2' put: '123').
>>>>>> ((dir / 'sub') at: 'text2' put: '456').
>>>>>> ((dir / 'sub') at: 'text2') inspect. "456"
>>>>>> ((dir / 'sub') backupAt: 'text2') inspect. "123"
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L63
>>>>>> This is a simple example for adding special behaviors to
>>>>>> FmDirectoryEntry.
>>>>>> I put and get file contents as gzipped, while users are not conscious
>>>>>> about that.
>>>>>> Usage:
>>>>>> | dir |
>>>>>> dir := './gzipped2' asDirectoryEntry: FmGZipDirectoryEntry.
>>>>>> dir binaryAt: 'bin' put: #(1 2 3 12 34 56) asByteArray.
>>>>>> (dir binaryAt: 'bin') inspect.
>>>>>> dir at: 'text' put: 'This will be gzipped'.
>>>>>> (dir at: 'text') inspect.
>>>>>> I would be useful for storing/loading big contents in a simple
>>>>>> dictionary-like manner.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/17/15, H. Hirzel<hannes.hirzel at gmail.com>    wrote:
>>>>>>> Hello Masashi-san
>>>>>>>
>>>>>>> I'd like to come back to your FileMan package
>>>>>>>
>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>
>>>>>>> and ask a question.
>>>>>>>
>>>>>>> Is this package a port from somewhere or did you write it from
>>>>>>> scratch?
>>>>>>>
>>>>>>> Some background information is appreciated.
>>>>>>>
>>>>>>> There is no description
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L2
>>>>>>>
>>>>>>> Thank you in advance
>>>>>>>
>>>>>>> Hannes Hirzel
>>>>>>>
>>>>>>>
>>>>>>> On 5/2/14, Masashi UMEZAWA<ume at blueplane.jp>    wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Thank you for the kind words. I've just started Cuis on March, and
>>>>>>>> I
>>>>>>>> was impressed with its cleanness, simplicity, etc.
>>>>>>>> So I did a introductory presentation at Tokyo Smalltalkers meeting.
>>>>>>>> It
>>>>>>>> was successful.
>>>>>>>> Now I'm planning to port Folktale (telnet-base object shell), and
>>>>>>>> SIXX
>>>>>>>> to Cuis. My pace maybe slow, but please stay tuned. ;)
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> 2014-05-02 1:05 GMT+09:00 Germ?n Arduino<garduino at gmail.com>:
>>>>>>>>> Wow, I was completely unaware of Masashi working in Cuis! Welcome
>>>>>>>>> aboard!!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2014-05-01 12:19 GMT-03:00 H. Hirzel<hannes.hirzel at gmail.com>:
>>>>>>>>>
>>>>>>>>>> Thank you for the link to  Masashi Umezawa's presentation.
>>>>>>>>>>
>>>>>>>>>> It is from 2014 and talks about
>>>>>>>>>>
>>>>>>>>>> - the number of classes compared to Squeak and Pharo
>>>>>>>>>> - the size of Morphic -- Morph allSelectors size "=>    502"
>>>>>>>>>> - something I do not fully get about instance variables
>>>>>>>>>>         'bounds owner submorphs fullBounds color extension'
>>>>>>>>>>         versus
>>>>>>>>>>        'owner submorphs location layoutNeeded layoutSpec
>>>>>>>>>> properties'
>>>>>>>>>> - layoutSpec
>>>>>>>>>> - PackageInfo
>>>>>>>>>> - version control with git
>>>>>>>>>> - Feature require: '<PackageName>'.
>>>>>>>>>> - your Unicode package
>>>>>>>>>> https://github.com/KenDickey/Cuis-Smalltalk-Unicode
>>>>>>>>>> -
>>>>>>>>>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-StyledTextEditor
>>>>>>>>>> - How to query for other Cuis-Smalltalk repositories
>>>>>>>>>>                 https://github.com/search?q=cuis-smalltalk
>>>>>>>>>>
>>>>>>>>>> All things which we will include Cuis documentation effort.
>>>>>>>>>>
>>>>>>>>>> --Hannes
>>>>>>>>>>
>>>>>>>>>> On 5/1/14, Ken Dickey<Ken.Dickey at whidbey.com>    wrote:
>>>>>>>>>>> On Thu, 1 May 2014 07:28:54 +0000
>>>>>>>>>>> "H. Hirzel"<hannes.hirzel at gmail.com>    wrote:
>>>>>>>>>>>
>>>>>>>>>>>> A noteworthy effort
>>>>>>>>>>>>
>>>>>>>>>>>>          https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>>>>> Yes.  Masashi Umezawa is the man in Japan!
>>>>>>>>>>>
>>>>>>>>>>> He should introduce himself.
>>>>>>>>>>>
>>>>>>>>>>> He gave a talk about Cuis at the 63rd Smalltalkers' meeting in
>>>>>>>>>>> Tokyo:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://www.smalltalk-users.jp/Home/gao-zhi/dai63kaismalltalkbenkyoukai/shiryou
>>>>>>>>>>>
>>>>>>>>>>> Masashi has ported several packages to CUis.
>>>>>>>>>>>
>>>>>>>>>>> Because of Unicode interest, I was made aware that recent font
>>>>>>>>>>> tweaks
>>>>>>>>>>> have
>>>>>>>>>>> broken my Unicode package in the latest Cuis versions.
>>>>>>>>>>>
>>>>>>>>>>> Masashi-san, would you care to tell us about yourself and what
>>>>>>>>>>> people
>>>>>>>>>>> there
>>>>>>>>>>> think about Cuis?
>>>>>>>>>>>
>>>>>>>>>>> -KenD
>>>>>> _______________________________________________
>>>>>> Cuis mailing list
>>>>>> Cuis at jvuletich.org
>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>
>>>>
>>
>>
>
>



From juan at jvuletich.org  Tue Jul 28 07:28:45 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 28 Jul 2015 09:28:45 -0300
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
Message-ID: <55B7757D.80006@jvuletich.org>

Hi Folks,

I just did a commit to the repo. It includes the updated ReferenceFinder 
and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).

Open an inspector on a window (using the halo). In the bottom pane 
evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer 
openExplorerOn: self'. Check the object trees to see what you have 
there. Read ClosureScanner class comment. You'll agree with me that this 
is truly great!

Also, several contributions by Ken (thanks Ken!), and a few fixes to 
Display updating, font creation, etc. by yours truly.

I also included an xml file with the test results.

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Tue Jul 28 16:41:42 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 28 Jul 2015 17:41:42 -0400
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <55B7757D.80006@jvuletich.org>
References: <55B7757D.80006@jvuletich.org>
Message-ID: <1438119702.2292.5.camel@gmail.com>

On Tue, 2015-07-28 at 09:28 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> I just did a commit to the repo. It includes the updated ReferenceFinder 
> and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).
> 
> Open an inspector on a window (using the halo). In the bottom pane 
> evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer 
> openExplorerOn: self'. Check the object trees to see what you have 
> there. Read ClosureScanner class comment. You'll agree with me that this 
> is truly great!
> 

Very cool stuff indeed!  Are there any notable changes between the old
and new ReferenceFinder or is it mostly just internals stuff?  Also,
should WeightTracer be added to the context menu (right click) of
Explorer and Inspector windows?

> Also, several contributions by Ken (thanks Ken!), and a few fixes to 
> Display updating, font creation, etc. by yours truly.
> 
> I also included an xml file with the test results.
> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Tue Jul 28 17:00:02 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 28 Jul 2015 18:00:02 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>

When the glyphs for the Cuis default font (DejaVu) or those for DejaVu Sans are filed out and 
then examined using Paint, it is obvious that they are of much higher quality than those 
produced by ImageMagick. The height is exactly right, as can be seen at ascii 129, 132, and 
133. They are the right size and crisp when displayed. This is the quality we should have for a 
fixed-width font. How were these .bmp files produced?

On 25 Jul 2015 at 21:41, Dan Norton wrote:

> Attached is a StrikeFont of Courier New 12. It's hacked - not
> polished by any means. It was 
> made by:
> 
> Making "characters.txt" by printing in a Cuis workspace, copying to
> Notepad, and saving with 
> encoding: ANSI.
> 
> This was input to ImageMagick to make a .png file.
> 
> The .png file was opened in Paint, then saved as a .bmp file.
> 
> The body of the .txt file was generated by:
> (32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 -
> needed to avoid index out of range"
> 
> The first three numbers in .txt were finagled to 12 15 5 (the last
> two anyway).
> 
> The font was installed by running:
> StrikeFont installCourier.  "code in Courier.pck.st "
> 
> Text in the Text Editor pane was highlighted and the font changed to
> Courier 12 point. It 
> looked much too small. Going back to Paint, the glyphs were selected
> and stretched 
> vertically. The font was re-installed. The vertical distortion is
> probably obvious.
> 
> At least it's recognizable as Courier and it's fixed width. Files
> are attached.
> 
>  - Dan
> 
> Attachments:
>   C:\Cuis\CourierExample2.zip





From hannes.hirzel at gmail.com  Wed Jul 29 03:44:36 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Wed, 29 Jul 2015 08:44:36 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
Message-ID: <CAGQxfVjs7DceHza3oyWAPRbJ7YDjoVR=HswXosR9yyJX4auM4w@mail.gmail.com>

Juan produced the fonts. There is some discussion about it in the
mailing list archive.

--HH

On 7/28/15, Dan Norton <dnorton at mindspring.com> wrote:
> When the glyphs for the Cuis default font (DejaVu) or those for DejaVu Sans
> are filed out and
> then examined using Paint, it is obvious that they are of much higher
> quality than those
> produced by ImageMagick. The height is exactly right, as can be seen at
> ascii 129, 132, and
> 133. They are the right size and crisp when displayed. This is the quality
> we should have for a
> fixed-width font. How were these .bmp files produced?
>
> On 25 Jul 2015 at 21:41, Dan Norton wrote:
>
>> Attached is a StrikeFont of Courier New 12. It's hacked - not
>> polished by any means. It was
>> made by:
>>
>> Making "characters.txt" by printing in a Cuis workspace, copying to
>> Notepad, and saving with
>> encoding: ANSI.
>>
>> This was input to ImageMagick to make a .png file.
>>
>> The .png file was opened in Paint, then saved as a .bmp file.
>>
>> The body of the .txt file was generated by:
>> (32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 -
>> needed to avoid index out of range"
>>
>> The first three numbers in .txt were finagled to 12 15 5 (the last
>> two anyway).
>>
>> The font was installed by running:
>> StrikeFont installCourier.  "code in Courier.pck.st "
>>
>> Text in the Text Editor pane was highlighted and the font changed to
>> Courier 12 point. It
>> looked much too small. Going back to Paint, the glyphs were selected
>> and stretched
>> vertically. The font was re-installed. The vertical distortion is
>> probably obvious.
>>
>> At least it's recognizable as Courier and it's fixed width. Files
>> are attached.
>>
>>  - Dan
>>
>> Attachments:
>>   C:\Cuis\CourierExample2.zip
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Wed Jul 29 09:49:14 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 29 Jul 2015 11:49:14 -0300
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <1438119702.2292.5.camel@gmail.com>
References: <55B7757D.80006@jvuletich.org> <1438119702.2292.5.camel@gmail.com>
Message-ID: <55B8E7EA.7060301@jvuletich.org>

On 7/28/2015 6:41 PM, Phil (list) wrote:
> On Tue, 2015-07-28 at 09:28 -0300, Juan Vuletich wrote:
>> Hi Folks,
>>
>> I just did a commit to the repo. It includes the updated ReferenceFinder
>> and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).
>>
>> Open an inspector on a window (using the halo). In the bottom pane
>> evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer
>> openExplorerOn: self'. Check the object trees to see what you have
>> there. Read ClosureScanner class comment. You'll agree with me that this
>> is truly great!
>>
> Very cool stuff indeed!  Are there any notable changes between the old
> and new ReferenceFinder or is it mostly just internals stuff?

I believe it is refactoring to make room for the new WeightTracer.

> Also,
> should WeightTracer be added to the context menu (right click) of
> Explorer and Inspector windows?

Yes! Care to send a cs?

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul 29 09:54:52 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 29 Jul 2015 11:54:52 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
Message-ID: <55B8E93C.7080009@jvuletich.org>

Hi Dan,

I looked for it in old stuff I haven't touched in several years, and 
found it. Glyph rendering is done by FreeType. 
https://www.dropbox.com/sh/9d5xi3x2lvtrtum/AABy17XMTRmciA44ysM-vuxza?dl=0

This original ran on the Mac I had by then, but with the VM I added, it 
seems to work ok on Windows. Anyway, there are no guarantees. I didn't 
try to import the files generated, and for sure you'd need to add glyphs 
for 128, 129, 130 and 131, to follow the Cuis convention.

BTW, I suggest using free fonts, that you can share without concern. 
DejaVu Sans is a good option. Inconsolata is just great. There are 
several more free code-oriented monospaced fonts out there.

Cheers,
Juan Vuletich

On 7/28/2015 7:00 PM, Dan Norton wrote:
> When the glyphs for the Cuis default font (DejaVu) or those for DejaVu Sans are filed out and
> then examined using Paint, it is obvious that they are of much higher quality than those
> produced by ImageMagick. The height is exactly right, as can be seen at ascii 129, 132, and
> 133. They are the right size and crisp when displayed. This is the quality we should have for a
> fixed-width font. How were these .bmp files produced?
>
> On 25 Jul 2015 at 21:41, Dan Norton wrote:
>
>> Attached is a StrikeFont of Courier New 12. It's hacked - not
>> polished by any means. It was
>> made by:
>>
>> Making "characters.txt" by printing in a Cuis workspace, copying to
>> Notepad, and saving with
>> encoding: ANSI.
>>
>> This was input to ImageMagick to make a .png file.
>>
>> The .png file was opened in Paint, then saved as a .bmp file.
>>
>> The body of the .txt file was generated by:
>> (32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 -
>> needed to avoid index out of range"
>>
>> The first three numbers in .txt were finagled to 12 15 5 (the last
>> two anyway).
>>
>> The font was installed by running:
>> StrikeFont installCourier.  "code in Courier.pck.st "
>>
>> Text in the Text Editor pane was highlighted and the font changed to
>> Courier 12 point. It
>> looked much too small. Going back to Paint, the glyphs were selected
>> and stretched
>> vertically. The font was re-installed. The vertical distortion is
>> probably obvious.
>>
>> At least it's recognizable as Courier and it's fixed width. Files
>> are attached.
>>
>>   - Dan
>>
>> Attachments:
>>    C:\Cuis\CourierExample2.zip
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From pbpublist at gmail.com  Wed Jul 29 12:11:37 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 29 Jul 2015 13:11:37 -0400
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <55B8E7EA.7060301@jvuletich.org>
References: <55B7757D.80006@jvuletich.org>
	<1438119702.2292.5.camel@gmail.com> <55B8E7EA.7060301@jvuletich.org>
Message-ID: <1438189897.2292.6.camel@gmail.com>

On Wed, 2015-07-29 at 11:49 -0300, Juan Vuletich wrote:
> On 7/28/2015 6:41 PM, Phil (list) wrote:
> > On Tue, 2015-07-28 at 09:28 -0300, Juan Vuletich wrote:
> >> Hi Folks,
> >>
> >> I just did a commit to the repo. It includes the updated ReferenceFinder
> >> and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).
> >>
> >> Open an inspector on a window (using the halo). In the bottom pane
> >> evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer
> >> openExplorerOn: self'. Check the object trees to see what you have
> >> there. Read ClosureScanner class comment. You'll agree with me that this
> >> is truly great!
> >>
> > Very cool stuff indeed!  Are there any notable changes between the old
> > and new ReferenceFinder or is it mostly just internals stuff?
> 
> I believe it is refactoring to make room for the new WeightTracer.
> 
> > Also,
> > should WeightTracer be added to the context menu (right click) of
> > Explorer and Inspector windows?
> 
> Yes! Care to send a cs?
> 

Done... pull request submitted

> Cheers,
> Juan Vuletich





From hannes.hirzel at gmail.com  Fri Jul 31 01:29:54 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Fri, 31 Jul 2015 06:29:54 +0000
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <1437592756.2326.32.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
	<CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>
	<1437592756.2326.32.camel@gmail.com>
Message-ID: <CAGQxfVhZfsbRw=Fiq0fy5_5MHU5bqEEnM2S1F5akOKUMmxXUJg@mail.gmail.com>

Could we do examples of such Feature Tests?

Class String is a good candidate to start with

Reasons
a) Is  used everywhere
b) Interface is non-trivial
        String selectors size 166   (in Cuis)
                                      338   (in Pharo)
                                      331   (in Squeak)
        --> there are issues when porting.

We might want to have a StringExtensions package

--Hannes

On 7/22/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Wed, 2015-07-22 at 13:29 +0200, Peter van Rooijen wrote:
>> I'm thinking about some features (pun not intentional) of this Feature
>> Test framework:
>>
>>
>> 1. It's reasonable to assume that many tests will depend on something
>> else working, but that cannot be counted on, and
>> we would not want to repeat testing for that and also would not run
>> into it failing all the time and that filling our feedback.
>>
>
> Why not?  I agree that these would be a different category of test in
> that the dependencies would be more complex and often dependent on more
> than one package, but why would their functioning be considered
> optional?  If they fail, shouldn't they either be addressed right away
> or explicitly deprecated?  If you make the tests easy to ignore/forget
> about, they will be.  If the functionality they are testing can't be
> counted on, it won't be used.
>
> If your thinking is that these would be tests that are part of package X
> but might rely on package Y which might not be loaded yet, why not
> instead just make the tests part of package Z which depends on package X
> and Y?  The whole idea is that these are not unit tests in that sense...
> have them live where ever it is appropriate.
>
>>
>> 1a. So it would make sense to add a #precondition method to each
>> Feature Test class.
>>
>>
>> FeatureAnsiArray
>>     class
>>         precondition
>>
>>
>>         self run: 'Array' "i.e. the global Array must be present"
>>
>>
>> then only if the precondition for the class is satisfied, will the
>> test methods be executed. so if most of them start with
>>
>>
>> 'Array new ?' then they would all fail anyway so we don't need to test
>> them.
>>
>>
>> 2. You would want to be able to assure that in a particular object you
>> would be able to access a particular variable.
>>
>>
>> so in the test method you would write:
>>
>>
>> FeatureTest1
>>     class
>>         test1
>>
>>         self setContext: OrderdCollection new
>>
>>
>>         self run: 'elements' "determine if the inst var elements is
>> present in a new OrderedCollection"
>>
>>
>>         self run: 'elements == nil' expect: false
>>
>>
>>         self run: 'elements isOrderedCollection' expect: true
>>
>>
>> let's say the test runner would continue testing even if something
>> failed, e.g. the array is called array, not elements. then we already
>> know that the following expressions will fail
>>
>>
>> so we might instead write:
>>
>>
>>         self run: 'elements' ifFail: [^self]
>>
>>
>>
>>  3. Instead of implicitly testing for a global using run:
>> 'NameOfTheGlobal' or for a class var using setContext: and then
>> run'NameOfTheClassVar' there could be convenience methods for
>>
>>
>>         self expectGlobal: 'NameOfTheGlobal' "argument may be given as
>> a Symbol as well"
>>
>>
>>         self expectClass: 'NameOfTheClass' "additionally verified that
>> the global holds a class"
>>
>>
>>         self expectSharedVariable: 'Foo' inClass: 'Bar'
>>
>>
>> this would make for nicer feedback since the expectation is made
>> clearer
>
> I went the other way when I did the ApiFile tests in that it didn't seem
> terribly important to use most of the testing framework capabilities
> (other than the overall pass/fail aspect to keep the initial PoC as
> simple as possible)  So they are simply small snippets of code that
> performed the desired task but didn't care where it failed (if it
> failed):  the failure to successfully complete the task would be the
> indicator that there was a problem and we would know that either
> something being depended on had broken and needed to be fixed or that
> the test needed to be updated/overhauled to represent the new way of
> accomplishing the task.
>
> My thinking was that as we started to build up a number of these, we
> might start to see common breakage patterns and then we could decide
> whether or not to handle that them more explicitly (whether using the
> existing test framework capabilities, creating a new one, etc.)  Trying
> to engineer it up front didn't seem like a great idea not knowing what
> common failure states would look like yet.
>
>>
>>
>> Okay just 2 more cents!
>>
>
> Mine as well.  This is a worthwhile discussion/exercise IMO as we need
> to get to a common understanding of what we are doing here.
>
>>
>> Cheers, Peter
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen
>> <peter at aba-instituut.nl> wrote:
>>         Hi Ken,
>>
>>         On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey
>>         <Ken.Dickey at whidbey.com> wrote:
>>                 On Tue, 21 Jul 2015 07:59:47 -0700
>>                 Peter van Rooijen <peter at aba-instituut.nl> wrote:
>>
>>                 >> I was thinking: "What should a Feature Test be?".
>>
>>                 I tend to think of a hierarchy of requirements.
>>                 Perhaps something like:
>>
>>                  Feature requireAll: #( <feature name>.. ).
>>                  Classes requireAll: #( <class name>.. ).
>>                  Methods requireAll: #( <selector name>.. ).
>>                  MethodsForKind class: <class name> requireAll:
>>                 #( <selectorName>.. ).
>>                  Tests requireAllPass: #( <unit test name> ).
>>
>>
>>         Yeah, that's not at all what I'm thinking :). I'm thinking of
>>         something that is automatically runnable, like a unit test. It
>>         tests something, like a un test. But if the test does not
>>         pass, it is NOT a bug, unlike with a unit test. It's just that
>>         we would like to know about it. Also, with nit tests there is
>>         the assumption that the code that represents the test is
>>         always compilable, with feature tests that cannot be assumed,
>>         so there would need to be protection against that. Of course
>>         we want to be able to load the feature tests in any condition,
>>         so putting it in the form of source text and compiling that is
>>         a possibility. The fact that that makes it slower than unit
>>         tests is not a problem, because unlike unit tests, we don't
>>         have to run them continuously.
>>
>>                 The Feature class lets us require named (macro)
>>                 Features with a version check.  I prefer that
>>                 requirements at this level actually load the packages
>>                 required and only report failure if that is not
>>                 possible, although we could have a "preflight" verson
>>                 which just checks without loading any featured
>>                 packages.
>>
>>
>>         I see. The thing I was thinking about merely reports about the
>>         state of a system (of code), it does not try to configure that
>>         in any way.
>>
>>
>>                 API's are basically "protocols", which in the absence
>>                 of symbolic execution means checking that classes and
>>                 specific method selectors exist, or more specifically,
>>                 method selectors are applicable to specific KindOf:
>>                 classes.
>>
>>
>>         Well, in my mind some semantics could be expected (and tested
>>         for). For instance I might be interested if there is a
>>         DateTime class in the image and if it implements the ANSI
>>         DateAndTime protocol (not sure if there is one named that). Or
>>         perhaps another class that does that. These tests can test
>>         some actual semantics no problem.
>>
>>
>>         Perhaps some of you remember that Camp Smalltalk started with
>>         Ralph Johnson's desire to build an ANSI test suite. The way
>>         people went about it (extension methods to SUnit? I don't
>>         really remember) was wrong and could not possibly work (in my
>>         opinion anyway), but I could not convince a lot of people and
>>         such a test suite was never written. But with Feature Tests I
>>         think we could come a long way.
>>
>>                 Further, some Unit Tests may be required to pass to
>>                 ensure compliance with some specification.
>>
>>
>>         Well, except that the tests would not be unit tests in the
>>         strictest sense. But semantics, not merely interface, can be
>>         tested for sure.
>>
>>                 We should be able to automate at least some of this
>>
>>
>>         Automate the running of the feature tests? Of course.
>>
>>                 including a first pass of generating the test sets,
>>                 which could then be pruned by hand as required.
>>
>>
>>         That I don't see happening. You test what YOU think is
>>         important to be sure of. No machine can decide/calculate that
>>         for you. Perhaps I'm misunderstanding you.
>>
>>
>>         Cheers, Peter
>>
>>
>>                 $0.02,
>>                 -KenD
>>
>>
>>
>>         _______________________________________________
>>         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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From nicolas.cellier.aka.nice at gmail.com  Wed Jul  1 07:52:56 2015
From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier)
Date: Wed, 1 Jul 2015 14:52:56 +0200
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
References: <1435576183.2309.69.camel@gmail.com>
	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>
	<55917102.4030901@jvuletich.org>
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
Message-ID: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>

2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:

> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>
> > Hi folks,
> >
> > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> > > On Mon, 29 Jun 2015 07:09:43 -0400
> > > "Phil (list)"<pbpublist at gmail.com>  wrote:
> > >> ..  Is it
> > >> worth having a class for this vs. raising the more general
> > Notification
> > >> and then checking for a #ReparseAfterSourceEditing signal, and if
> > it
> > >> isn't, re-raise Notification in its sole handler?
> > >> ..
> > >> This is a specific example of the more general question of where
> > to draw
> > >> the line on having single, or very limited, use classes and
> > methods vs.
> > >> adding a tiny bit of complexity in one or two methods to simplify
> > the
> > >> overall image or package in question.  Thoughts?
> > > I would say the overriding goal is clarity.
> > >
> > > It is important work to refactor code to have the same behavior
> > but be easier to understand.
> > >
> > > A Smalltalk style goal is to have small methods which do things
> > clearly.  This tends to lead to lots of small methods.
> > >
> > > Specializing classes for one or just a few methods may seem
> > wasteful, but computer resources are cheap.
> > >
> > > Look at class #PartsBinMorph.  Would you say the having the
> > additional class is wasteful?
> > >
> > > It is a tough balance.  Aesthetics and restraint require judgement
> > and we don't always get it right.  It takes time.
> > >
> > > I only have so many life hours left.  I feel my time is valuable.
> > I prefer to understand.
> > >
> > > Thank you so much for taking the time to make Cuis more
> > comprehensible.
> > >
> > > $0.02
> > > -KenD
> >
> > I fully support Ken. I don't think that a general answer is correct
> > in
> > all cases here. It is a matter of making code easy to understand.
> > But
> > also making it consistent and pretty.
> >
> > In general, I don't like making general classes know much about
> > details
> > of specific use cases. But there might be exceptions.
> >
> > If you feel like experimenting with this kind of stuff, send your
> > suggestions to the mail list so we can discuss.
> >
> > In the particular case of ReparseAfterSourceEditing, I agree that a
> > class that does nothing is a bit strange. But, what is the
> > alternative?
> > How would the sole exception handler know what to do with a general
> > Notification? I think the handler looks quite reasonable right now.
> > And
> > the pollution of the global space might be tolerable if the
> > alternative
> > is more convoluted code...
> >
>
> Making code easy to understand is very valuable. Simple things should be
> simple to
> accomplish, but achieving this in an API may not always be easy.
>
> This weekend I spent lots of "quality time" with the debugger, trying to
> figure out why I could
> not get a new window with a PluggableListMorph to work like another one
> which had exactly
> the behavior I wanted. The bug was that a method referred to by the
> #indexSetter: keyword
> needed to send the #selectedItem: message, which is not mentioned by
> keyword. Not sure
> what the answer is for that one but I'm working on notes to try to avoid
> that stupid mistake in
> the future. :)
>
> I'm just saying we should do anything we can to enhance clarity as well as
> simplify.
>
>  - Dan
>
>
Since you are using the right keywords, maybe it's time to view it again
Simple made easy
http://www.infoq.com/presentations/Simple-Made-Easy

_______________________________________________
> 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/20150701/06743c77/attachment-0004.html>

From peter at aba-instituut.nl  Wed Jul  1 15:10:31 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 1 Jul 2015 22:10:31 +0200
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>
	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>
	<55917102.4030901@jvuletich.org>
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
Message-ID: <CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>

Hi all,

I believe that a class can be justified simply because it gives you
an intention revealing name in the code, and room to put a
class comment (possibly an extensive one).

Especially with exceptions it can be difficult to understand
what exactly the exception is for, and a class comment can
be extremely helpful.

So, one thing that I am saying is that a class with NO behavior
but a well-chosen name, superclass and a clear class comment, can
be a very valuable part of a system.

Another thing I believe is that a class by itself is not very complex.
Complex in the sense of adding to the overall complexity of the system.

I have been interested in complexity and reducing it for a very long time
(since before I started with Smalltalk) and I have often thought about
the rules one would put into a tool that automatically measured the
complexity of a system of code.

One application of such a tool would be refactoring. Generally, after I
refactor, all my old tests should still run, but also, my overall complexity
should be lower.

At least, that was my thinking, and a tool that measures
complexity could help with that. In a sense it would be a more
sophisticated version of the "rule of three".

In any case, I never implemented such a tool, but did develop a set of
heuristics/rules that I let guide me to decide whether I should extract
methods, extract classes, etc. Part of these heuristics was that a class
by itself did not add that much.

I don't remember most of my rules although I probably still follow them
intuitively. Perhaps a class added more complexity than a method, but not
more than two methods, I don't really know.

I wonder what others do to decide how to factor code.

Cheers, Peter



On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>
>> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>>
>> > Hi folks,
>> >
>> > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>> > > On Mon, 29 Jun 2015 07:09:43 -0400
>> > > "Phil (list)"<pbpublist at gmail.com>  wrote:
>> > >> ..  Is it
>> > >> worth having a class for this vs. raising the more general
>> > Notification
>> > >> and then checking for a #ReparseAfterSourceEditing signal, and if
>> > it
>> > >> isn't, re-raise Notification in its sole handler?
>> > >> ..
>> > >> This is a specific example of the more general question of where
>> > to draw
>> > >> the line on having single, or very limited, use classes and
>> > methods vs.
>> > >> adding a tiny bit of complexity in one or two methods to simplify
>> > the
>> > >> overall image or package in question.  Thoughts?
>> > > I would say the overriding goal is clarity.
>> > >
>> > > It is important work to refactor code to have the same behavior
>> > but be easier to understand.
>> > >
>> > > A Smalltalk style goal is to have small methods which do things
>> > clearly.  This tends to lead to lots of small methods.
>> > >
>> > > Specializing classes for one or just a few methods may seem
>> > wasteful, but computer resources are cheap.
>> > >
>> > > Look at class #PartsBinMorph.  Would you say the having the
>> > additional class is wasteful?
>> > >
>> > > It is a tough balance.  Aesthetics and restraint require judgement
>> > and we don't always get it right.  It takes time.
>> > >
>> > > I only have so many life hours left.  I feel my time is valuable.
>> > I prefer to understand.
>> > >
>> > > Thank you so much for taking the time to make Cuis more
>> > comprehensible.
>> > >
>> > > $0.02
>> > > -KenD
>> >
>> > I fully support Ken. I don't think that a general answer is correct
>> > in
>> > all cases here. It is a matter of making code easy to understand.
>> > But
>> > also making it consistent and pretty.
>> >
>> > In general, I don't like making general classes know much about
>> > details
>> > of specific use cases. But there might be exceptions.
>> >
>> > If you feel like experimenting with this kind of stuff, send your
>> > suggestions to the mail list so we can discuss.
>> >
>> > In the particular case of ReparseAfterSourceEditing, I agree that a
>> > class that does nothing is a bit strange. But, what is the
>> > alternative?
>> > How would the sole exception handler know what to do with a general
>> > Notification? I think the handler looks quite reasonable right now.
>> > And
>> > the pollution of the global space might be tolerable if the
>> > alternative
>> > is more convoluted code...
>> >
>>
>> Making code easy to understand is very valuable. Simple things should be
>> simple to
>> accomplish, but achieving this in an API may not always be easy.
>>
>> This weekend I spent lots of "quality time" with the debugger, trying to
>> figure out why I could
>> not get a new window with a PluggableListMorph to work like another one
>> which had exactly
>> the behavior I wanted. The bug was that a method referred to by the
>> #indexSetter: keyword
>> needed to send the #selectedItem: message, which is not mentioned by
>> keyword. Not sure
>> what the answer is for that one but I'm working on notes to try to avoid
>> that stupid mistake in
>> the future. :)
>>
>> I'm just saying we should do anything we can to enhance clarity as well
>> as simplify.
>>
>>  - Dan
>>
>>
> Since you are using the right keywords, maybe it's time to view it again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy
>
> _______________________________________________
>> 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/20150701/09108f29/attachment-0004.html>

From peter at aba-instituut.nl  Wed Jul  1 15:20:11 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 1 Jul 2015 22:20:11 +0200
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1435627676.2309.133.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<54FEF396.1070509@jvuletich.org>
	<1426014697.2279.25.camel@gmail.com>
	<1435627676.2309.133.camel@gmail.com>
Message-ID: <CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>

Not sure if this is related but InspectorWindow does not cut
off the text in the title bar of the window eagerly enough.

Take an inspector whose title is too long for the window
and see how the text is cut off mid-character at the right
border of the window. Move the window around and it leaves
a trail, exactly where the character pixels touch the side.

BTW, the devoweling of inspector titles I strongly dislike.
If that could be taken out, great. Or perhaps someone has
real good use for that?

Thanks, Peter

On Tue, Jun 30, 2015 at 3:27 AM, Phil (list) <pbpublist at gmail.com> wrote:

> An old issue with some new info...
>
> On Tue, 2015-03-10 at 15:11 -0400, Phil (list) wrote:
> > On Tue, 2015-03-10 at 10:37 -0300, Juan Vuletich wrote:
> > > Hi Phil,
> > >
> > > (inline)
> > > On 3/9/2015 6:54 AM, Phil (list) wrote:
> > > > I've been testing some of my code after migrating to the local
> > > > coordinate system and am running into a few things:
> > > >
> > > > 1) Morph stepping appears to be non-functional (at least in terms of
> > > > running the code as-is from Cuis 4.0)
> > >
> > > You already found #stepAt: . In any case, the "message names" tool is
> > > your friend.
> > >
> >
> > As was FrameRateMorph.
> >
> > > > 2) Halos are behaving badly on occasion... drawing artifacts,
> problems
> > > > resizing, experiencing the odd image crash here and there.
> > >
> > > Please, steps to reproduce.
> > >
> >
> > Working on narrowing down.
>
> At least the drawing artifacts issue doesn't appear to be Halo specific.
> I've been seeing it on occasion with other kinds of Morphs.  Today it
> finally dawned on me what is going on: Morphs are drawing outside of
> their bounds.  I think I have a reproducible scenario: in the Workspace
> type ReparseAfterSourceEditing, select and right click->Smalltalk
> Options->Method Source with it.  On my computer, the default window size
> results in the title text being drawn well outside of the Morph so
> there's no mistaking what's going on.  Drag the window around and notice
> the artifacts.  I think Halos and other Morphs are doing the same thing
> though less obviously.
>
>
> _______________________________________________
> 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/20150701/77b298a2/attachment-0004.html>

From pbpublist at gmail.com  Wed Jul  1 15:30:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 16:30:01 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<54FEF396.1070509@jvuletich.org> <1426014697.2279.25.camel@gmail.com>
	<1435627676.2309.133.camel@gmail.com>
	<CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>
Message-ID: <1435782601.2309.170.camel@gmail.com>

On Wed, 2015-07-01 at 22:20 +0200, Peter van Rooijen wrote:
> Not sure if this is related but InspectorWindow does not cut
> off the text in the title bar of the window eagerly enough.
> 

That's exactly the issue I'm referring to (though it is larger in scope
than just title bars.)

> 
> Take an inspector whose title is too long for the window
> and see how the text is cut off mid-character at the right
> border of the window. Move the window around and it leaves
> a trail, exactly where the character pixels touch the side.
> 

Yup.

> 
> BTW, the devoweling of inspector titles I strongly dislike.
> If that could be taken out, great. Or perhaps someone has
> real good use for that?
> 

I'm not wild about it either but in many cases I think it is probably
better than just truncating the string.  I think that's one of those
things where a better approach would be nice but so far no one has come
up with one...

> 
> Thanks, Peter
> 
> On Tue, Jun 30, 2015 at 3:27 AM, Phil (list) <pbpublist at gmail.com>
> wrote:
>         An old issue with some new info...
>         
>         On Tue, 2015-03-10 at 15:11 -0400, Phil (list) wrote:
>         > On Tue, 2015-03-10 at 10:37 -0300, Juan Vuletich wrote:
>         > > Hi Phil,
>         > >
>         > > (inline)
>         > > On 3/9/2015 6:54 AM, Phil (list) wrote:
>         > > > I've been testing some of my code after migrating to the
>         local
>         > > > coordinate system and am running into a few things:
>         > > >
>         > > > 1) Morph stepping appears to be non-functional (at least
>         in terms of
>         > > > running the code as-is from Cuis 4.0)
>         > >
>         > > You already found #stepAt: . In any case, the "message
>         names" tool is
>         > > your friend.
>         > >
>         >
>         > As was FrameRateMorph.
>         >
>         > > > 2) Halos are behaving badly on occasion... drawing
>         artifacts, problems
>         > > > resizing, experiencing the odd image crash here and
>         there.
>         > >
>         > > Please, steps to reproduce.
>         > >
>         >
>         > Working on narrowing down.
>         
>         At least the drawing artifacts issue doesn't appear to be Halo
>         specific.
>         I've been seeing it on occasion with other kinds of Morphs.
>         Today it
>         finally dawned on me what is going on: Morphs are drawing
>         outside of
>         their bounds.  I think I have a reproducible scenario: in the
>         Workspace
>         type ReparseAfterSourceEditing, select and right
>         click->Smalltalk
>         Options->Method Source with it.  On my computer, the default
>         window size
>         results in the title text being drawn well outside of the
>         Morph so
>         there's no mistaking what's going on.  Drag the window around
>         and notice
>         the artifacts.  I think Halos and other Morphs are doing the
>         same thing
>         though less obviously.
>         
>         
>         _______________________________________________
>         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 Ken.Dickey at whidbey.com  Wed Jul  1 15:35:34 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Wed, 1 Jul 2015 13:35:34 -0700
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1435782601.2309.170.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<54FEF396.1070509@jvuletich.org>
	<1426014697.2279.25.camel@gmail.com>
	<1435627676.2309.133.camel@gmail.com>
	<CAJBxtBb2Q6LMg0Wb3GLvfWb5Cxmj=cBDJGWV6ToefqXHEZ+=7w@mail.gmail.com>
	<1435782601.2309.170.camel@gmail.com>
Message-ID: <20150701133534.7bcc7623e97ea01308b48194@whidbey.com>

On Wed, 01 Jul 2015 16:30:01 -0400
"Phil (list)" <pbpublist at gmail.com> wrote:

> > BTW, the devoweling of inspector titles I strongly dislike.
> > If that could be taken out, great. Or perhaps someone has
> > real good use for that?
> 
> I'm not wild about it either but in many cases I think it is probably
> better than just truncating the string.  I think that's one of those
> things where a better approach would be nice but so far no one has come
> up with one...

I find it much more helpful than truncated strings.

FYI,
-KenD



From pbpublist at gmail.com  Wed Jul  1 15:54:22 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 16:54:22 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>
	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>
	<55917102.4030901@jvuletich.org>
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
Message-ID: <1435784062.2309.192.camel@gmail.com>

On Wed, 2015-07-01 at 22:10 +0200, Peter van Rooijen wrote:
> Hi all,
> 
> 
> I believe that a class can be justified simply because it gives you
> an intention revealing name in the code, and room to put a
> class comment (possibly an extensive one).
> 

I believe that's the thinking that results in most of the current
Exception subclasses.  I personally don't care for it, but will go with
the consensus which seems to be OK with it.

> 
> Especially with exceptions it can be difficult to understand
> what exactly the exception is for, and a class comment can
> be extremely helpful.
> 

But Exceptions have a #signal: value which could also easily convey that
information.  (that's not always true, but the point is there are other
ways to convey the information other than subclassing)  Also keep in
mind that many exceptions, such as the one I was pointing out, are never
even seen by the user: they are used as an alternate messaging channel
by the code.

> 
> So, one thing that I am saying is that a class with NO behavior
> but a well-chosen name, superclass and a clear class comment, can
> be a very valuable part of a system.
> 
> 
> Another thing I believe is that a class by itself is not very complex.
> Complex in the sense of adding to the overall complexity of the
> system.
> 

True, a single class by itself is not very complex.  Multiply that by
100x or more and the story changes.  To me, one of the more obvious
aspects of complexity is the aggregate # of classes/methods/lines of
code in a system.  In this particular case, I was wondering out loud if
this particular trade-off (i.e. creating a class to save 1-2 lines of
code) was worth it.  I find it interesting that exception handling is
one of the younger parts of Smalltalk and, to me at least, it really
stands out as being rather strangely implemented in terms of the class
hierarchy.

> 
> I have been interested in complexity and reducing it for a very long
> time
> (since before I started with Smalltalk) and I have often thought about
> the rules one would put into a tool that automatically measured the
> complexity of a system of code.
> 
> 
> One application of such a tool would be refactoring. Generally, after
> I
> refactor, all my old tests should still run, but also, my overall
> complexity
> should be lower.
> 
> 
> At least, that was my thinking, and a tool that measures
> complexity could help with that. In a sense it would be a more
> sophisticated version of the "rule of three".
> 
> 
> In any case, I never implemented such a tool, but did develop a set of
> heuristics/rules that I let guide me to decide whether I should
> extract
> methods, extract classes, etc. Part of these heuristics was that a
> class
> by itself did not add that much.
> 
> 
> I don't remember most of my rules although I probably still follow
> them
> intuitively. Perhaps a class added more complexity than a method, but
> not
> more than two methods, I don't really know.
> 
> 
> I wonder what others do to decide how to factor code.
> 

You might want to take a look at Moose http://www.moosetechnology.org/
It's a tool to help you analyze and understand a given body of code.
It's a bit fragile/brittle/incomplete, but right now it's about the best
I've found to date to try to analyze and quantify complexity.  Also, you
could take a look at the work VPRI is doing related to FoNC/STEPS as
minimizing complexity is core to what they are working on.

> 
> Cheers, Peter
> 
> 
> 
> 
> 
> On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>         
>         
>         2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>                 On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>                 
>                 > Hi folks,
>                 >
>                 > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>                 > > On Mon, 29 Jun 2015 07:09:43 -0400
>                 > > "Phil (list)"<pbpublist at gmail.com>  wrote:
>                 > >> ..  Is it
>                 > >> worth having a class for this vs. raising the
>                 more general
>                 > Notification
>                 > >> and then checking for a
>                 #ReparseAfterSourceEditing signal, and if
>                 > it
>                 > >> isn't, re-raise Notification in its sole handler?
>                 > >> ..
>                 > >> This is a specific example of the more general
>                 question of where
>                 > to draw
>                 > >> the line on having single, or very limited, use
>                 classes and
>                 > methods vs.
>                 > >> adding a tiny bit of complexity in one or two
>                 methods to simplify
>                 > the
>                 > >> overall image or package in question.  Thoughts?
>                 > > I would say the overriding goal is clarity.
>                 > >
>                 > > It is important work to refactor code to have the
>                 same behavior
>                 > but be easier to understand.
>                 > >
>                 > > A Smalltalk style goal is to have small methods
>                 which do things
>                 > clearly.  This tends to lead to lots of small
>                 methods.
>                 > >
>                 > > Specializing classes for one or just a few methods
>                 may seem
>                 > wasteful, but computer resources are cheap.
>                 > >
>                 > > Look at class #PartsBinMorph.  Would you say the
>                 having the
>                 > additional class is wasteful?
>                 > >
>                 > > It is a tough balance.  Aesthetics and restraint
>                 require judgement
>                 > and we don't always get it right.  It takes time.
>                 > >
>                 > > I only have so many life hours left.  I feel my
>                 time is valuable.
>                 > I prefer to understand.
>                 > >
>                 > > Thank you so much for taking the time to make Cuis
>                 more
>                 > comprehensible.
>                 > >
>                 > > $0.02
>                 > > -KenD
>                 >
>                 > I fully support Ken. I don't think that a general
>                 answer is correct
>                 > in
>                 > all cases here. It is a matter of making code easy
>                 to understand.
>                 > But
>                 > also making it consistent and pretty.
>                 >
>                 > In general, I don't like making general classes know
>                 much about
>                 > details
>                 > of specific use cases. But there might be
>                 exceptions.
>                 >
>                 > If you feel like experimenting with this kind of
>                 stuff, send your
>                 > suggestions to the mail list so we can discuss.
>                 >
>                 > In the particular case of ReparseAfterSourceEditing,
>                 I agree that a
>                 > class that does nothing is a bit strange. But, what
>                 is the
>                 > alternative?
>                 > How would the sole exception handler know what to do
>                 with a general
>                 > Notification? I think the handler looks quite
>                 reasonable right now.
>                 > And
>                 > the pollution of the global space might be tolerable
>                 if the
>                 > alternative
>                 > is more convoluted code...
>                 >
>                 
>                 
>                 Making code easy to understand is very valuable.
>                 Simple things should be simple to
>                 accomplish, but achieving this in an API may not
>                 always be easy.
>                 
>                 This weekend I spent lots of "quality time" with the
>                 debugger, trying to figure out why I could
>                 not get a new window with a PluggableListMorph to work
>                 like another one which had exactly
>                 the behavior I wanted. The bug was that a method
>                 referred to by the #indexSetter: keyword
>                 needed to send the #selectedItem: message, which is
>                 not mentioned by keyword. Not sure
>                 what the answer is for that one but I'm working on
>                 notes to try to avoid that stupid mistake in
>                 the future. :)
>                 
>                 I'm just saying we should do anything we can to
>                 enhance clarity as well as simplify.
>                 
>                  - Dan
>                 
>                 
>         
>         
>         Since you are using the right keywords, maybe it's time to
>         view it again
>         
>         Simple made easy
>         http://www.infoq.com/presentations/Simple-Made-Easy 
>         
>         
>                 _______________________________________________
>                 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Wed Jul  1 16:33:32 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 01 Jul 2015 17:33:32 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <20150701133534.7bcc7623e97ea01308b48194@whidbey.com>
References: <1425894846.2281.37.camel@gmail.com>,
	<1435782601.2309.170.camel@gmail.com>,
	<20150701133534.7bcc7623e97ea01308b48194@whidbey.com>
Message-ID: <55945CAC.22357.1785ED9@dnorton.mindspring.com>

On 1 Jul 2015 at 13:35, Ken.Dickey wrote:

> On Wed, 01 Jul 2015 16:30:01 -0400
> "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > > BTW, the devoweling of inspector titles I strongly dislike.
> > > If that could be taken out, great. Or perhaps someone has
> > > real good use for that?
> > 
> > I'm not wild about it either but in many cases I think it is
> probably
> > better than just truncating the string.  I think that's one of
> those
> > things where a better approach would be nice but so far no one has
> come
> > up with one...
> 
> I find it much more helpful than truncated strings.
> 
> FYI,
> -KenD
> 

+1

Best regards,
 - Dan



From juan at jvuletich.org  Wed Jul  1 19:29:42 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:29:42 -0300
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>	<55917102.4030901@jvuletich.org>	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
Message-ID: <559485F6.3030408@jvuletich.org>

On 7/1/2015 9:52 AM, Nicolas Cellier wrote:
> ...
>
> Since you are using the right keywords, maybe it's time to view it again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy

Thanks Nicolas. This is absolutely wonderful! Really inspiring.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  1 19:37:40 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:37:40 -0300
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>	<20150629065105.3130d6120bb1cc08fff8a6e4@whidbey.com>	<55917102.4030901@jvuletich.org>	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<CAJBxtBbc-eXbWk5SPm_oSV3xOkWpyaWATib-frh37Zo0bGEF5w@mail.gmail.com>
Message-ID: <559487D4.30603@jvuletich.org>

On 7/1/2015 5:10 PM, Peter van Rooijen wrote:
> ...
>
> I don't remember most of my rules although I probably still follow them
> intuitively. Perhaps a class added more complexity than a method, but not
> more than two methods, I don't really know.
>
> I wonder what others do to decide how to factor code.
>
> Cheers, Peter


To me Smalltalk code is an expression of human knowledge. I refactor 
code when I understand better, to express that new understanding.

Writing code is like writing course material, or a technical book on 
some subject. Good code is like a good book. You read it and understand. 
That's the gold standard.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  1 19:43:08 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:43:08 -0300
Subject: [Cuis] Updates
Message-ID: <5594891C.6090104@jvuletich.org>

Hi Folks,

Today I did a commit. I fixed recently reported issues (halos, window 
labels, etc). I also added Dan Norton's port of BouncingAtoms to the 
packages folder (thanks Dan!).

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  1 19:51:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 01 Jul 2015 21:51:34 -0300
Subject: [Cuis] Display units and UI widgets in Morphic 3
In-Reply-To: <1435714029.2309.155.camel@gmail.com>
References: <1435714029.2309.155.camel@gmail.com>
Message-ID: <55948B16.4060100@jvuletich.org>

Hi Phil,

On 6/30/2015 10:27 PM, Phil (list) wrote:
> Juan,
>
> I vaguely recall previously having a discussion somewhere about unit
> scaling / high dpi but can't seem to find the thread.  Anyways, this
> question is specific to Morphic 3: from a UI creation standpoint is
> Morphic 3 still going to use pixel-based units or will some other unit
> of measure be used? i.e. if you design a UI and have say a 32x32
> button, is that going to need to be scaled up (understanding that this
> will be trivial for Morphic 3 to do) for high-dpi displays?  Is this
> even a Morphic concern or will it be up to Cuis as an environment to
> have a preference for display scaling?

In Morphic 3 you can use any unit you want for your Morphs. It is 
perfectly reasonable to use pixels, at your preferred zoom level and 
DPI. You can also use domain specific units.

The user is able to scale the World or any particular Morph to suit his 
needs or taste, much like you do in Google Maps, in Satellite mode.

> Related to this is the question of how much do you anticipate
> higher-level UI code needing to be reworked for Morphic 3? One
> of the many projects I've been playing around with giving things a bit
> of a face-lift (i.e. a logging framework that can handle non-textual
> data, grid and multi-element list pluggable morphs, visualization
> widgets, etc... sort of along the lines of what is being done in Pharo
> with the playground stuff) and am just wondering how far I should go
> with this work before seeing what's involved in migrating to Morphic 3?

In principle, there is no code rework needed. The local coordinates, 
locations, etc. are the standard in Cuis since a few years ago.

The difference is that Morphic 3 will make some new things possible, and 
others will be simpler. It will also give the user a better control on 
how to use the UI.

> (I did take a quick peek at the Morphic 3 package but didn't find
> answers as it looks like you're still working out the lower level
> details)
>
> Thanks,
> Phil

Well, but that experimental code already can draw essentially any Cuis 
morphic World. It is just some lower level details what is missing to 
make it the main graphics engine for Cuis.

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Wed Jul  1 20:59:54 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 21:59:54 -0400
Subject: [Cuis] Updates
In-Reply-To: <5594891C.6090104@jvuletich.org>
References: <5594891C.6090104@jvuletich.org>
Message-ID: <1435802394.2309.194.camel@gmail.com>

On Wed, 2015-07-01 at 21:43 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> Today I did a commit. I fixed recently reported issues (halos, window 
> labels, etc). I also added Dan Norton's port of BouncingAtoms to the 
> packages folder (thanks Dan!).
> 

Looks good to me. (heh... now that Cuis isn't leaving behind artifacts
it exposed the issue that some of my morphs were too :-)

> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From pbpublist at gmail.com  Wed Jul  1 21:02:43 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 01 Jul 2015 22:02:43 -0400
Subject: [Cuis] Display units and UI widgets in Morphic 3
In-Reply-To: <55948B16.4060100@jvuletich.org>
References: <1435714029.2309.155.camel@gmail.com>
	<55948B16.4060100@jvuletich.org>
Message-ID: <1435802563.2309.197.camel@gmail.com>

On Wed, 2015-07-01 at 21:51 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 6/30/2015 10:27 PM, Phil (list) wrote:
> > Juan,
> >
> > I vaguely recall previously having a discussion somewhere about unit
> > scaling / high dpi but can't seem to find the thread.  Anyways, this
> > question is specific to Morphic 3: from a UI creation standpoint is
> > Morphic 3 still going to use pixel-based units or will some other unit
> > of measure be used? i.e. if you design a UI and have say a 32x32
> > button, is that going to need to be scaled up (understanding that this
> > will be trivial for Morphic 3 to do) for high-dpi displays?  Is this
> > even a Morphic concern or will it be up to Cuis as an environment to
> > have a preference for display scaling?
> 
> In Morphic 3 you can use any unit you want for your Morphs. It is 
> perfectly reasonable to use pixels, at your preferred zoom level and 
> DPI. You can also use domain specific units.
> 
> The user is able to scale the World or any particular Morph to suit his 
> needs or taste, much like you do in Google Maps, in Satellite mode.
> 

Excellent... that's what I was hoping for.

> > Related to this is the question of how much do you anticipate
> > higher-level UI code needing to be reworked for Morphic 3? One
> > of the many projects I've been playing around with giving things a bit
> > of a face-lift (i.e. a logging framework that can handle non-textual
> > data, grid and multi-element list pluggable morphs, visualization
> > widgets, etc... sort of along the lines of what is being done in Pharo
> > with the playground stuff) and am just wondering how far I should go
> > with this work before seeing what's involved in migrating to Morphic 3?
> 
> In principle, there is no code rework needed. The local coordinates, 
> locations, etc. are the standard in Cuis since a few years ago.
> 
> The difference is that Morphic 3 will make some new things possible, and 
> others will be simpler. It will also give the user a better control on 
> how to use the UI.
> 

Better and better!

> > (I did take a quick peek at the Morphic 3 package but didn't find
> > answers as it looks like you're still working out the lower level
> > details)
> >
> > Thanks,
> > Phil
> 
> Well, but that experimental code already can draw essentially any Cuis 
> morphic World. It is just some lower level details what is missing to 
> make it the main graphics engine for Cuis.
> 

Hmm... then I need to take another look.  I probably wasn't loading
and/or initializing things correctly.

> Cheers,
> Juan Vuletich





From dnorton at mindspring.com  Thu Jul  2 20:15:27 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 02 Jul 2015 21:15:27 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
References: <1435576183.2309.69.camel@gmail.com>,
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>,
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
Message-ID: <5595E22F.2684.23EA964@dnorton.mindspring.com>

Hi,

I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The 
question is how to view it without disabling my antivirus plus surrendering a bunch of 
"required" info. BTW I'm running Win7, IE, and ESET.

Any other possibilities?

 - Dan

On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:

> 
> 
> 
> 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>     On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>     
>     > Hi folks,
>     >
>     > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>     > > On Mon, 29 Jun 2015 07:09:43 -0400
>     > > "Phil (list)"<pbpublist at gmail.com>? wrote:
>     > >> ..? Is it
>     > >> worth having a class for this vs. raising the more
> general
>     > Notification
>     > >> and then checking for a #ReparseAfterSourceEditing signal,
> and if
>     > it
>     > >> isn't, re-raise Notification in its sole handler?
>     > >> ..
>     > >> This is a specific example of the more general question of
> where
>     > to draw
>     > >> the line on having single, or very limited, use classes
> and
>     > methods vs.
>     > >> adding a tiny bit of complexity in one or two methods to
> simplify
>     > the
>     > >> overall image or package in question.? Thoughts?
>     > > I would say the overriding goal is clarity.
>     > >
>     > > It is important work to refactor code to have the same
> behavior
>     > but be easier to understand.
>     > >
>     > > A Smalltalk style goal is to have small methods which do
> things
>     > clearly.? This tends to lead to lots of small methods.
>     > >
>     > > Specializing classes for one or just a few methods may
> seem
>     > wasteful, but computer resources are cheap.
>     > >
>     > > Look at class #PartsBinMorph.? Would you say the having
> the
>     > additional class is wasteful?
>     > >
>     > > It is a tough balance.? Aesthetics and restraint require
> judgement
>     > and we don't always get it right.? It takes time.
>     > >
>     > > I only have so many life hours left.? I feel my time is
> valuable.
>     > I prefer to understand.
>     > >
>     > > Thank you so much for taking the time to make Cuis more
>     > comprehensible.
>     > >
>     > > $0.02
>     > > -KenD
>     >
>     > I fully support Ken. I don't think that a general answer is
> correct
>     > in
>     > all cases here. It is a matter of making code easy to
> understand.
>     > But
>     > also making it consistent and pretty.
>     >
>     > In general, I don't like making general classes know much
> about
>     > details
>     > of specific use cases. But there might be exceptions.
>     >
>     > If you feel like experimenting with this kind of stuff, send
> your
>     > suggestions to the mail list so we can discuss.
>     >
>     > In the particular case of ReparseAfterSourceEditing, I agree
> that a
>     > class that does nothing is a bit strange. But, what is the
>     > alternative?
>     > How would the sole exception handler know what to do with a
> general
>     > Notification? I think the handler looks quite reasonable right
> now.
>     > And
>     > the pollution of the global space might be tolerable if the
>     > alternative
>     > is more convoluted code...
>     >
> 
>     Making code easy to understand is very valuable. Simple things
> should be simple to
>     accomplish, but achieving this in an API may not always be
> easy.
>     
>     This weekend I spent lots of "quality time" with the debugger,
> trying to figure out why I could
>     not get a new window with a PluggableListMorph to work like
> another one which had exactly
>     the behavior I wanted. The bug was that a method referred to by
> the #indexSetter: keyword
>     needed to send the #selectedItem: message, which is not
> mentioned by keyword. Not sure
>     what the answer is for that one but I'm working on notes to try
> to avoid that stupid mistake in
>     the future. :)
>     
>     I'm just saying we should do anything we can to enhance clarity
> as well as simplify.
>     
>     ?- Dan
> 
> 
> Since you are using the right keywords, maybe it's time to view it
> again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy
> 
>     _______________________________________________
>     Cuis mailing list
>     Cuis at jvuletich.org
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> 





From juan at jvuletich.org  Thu Jul  2 20:55:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 2 Jul 2015 22:55:27 -0300
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <5595E22F.2684.23EA964@dnorton.mindspring.com>
References: <1435576183.2309.69.camel@gmail.com>,
	<5591C3F9.14896.1CCB41B@dnorton.mindspring.com>,
	<CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<5595E22F.2684.23EA964@dnorton.mindspring.com>
Message-ID: <03aa649484e81e74b85e0dcfd201bc9e.squirrel@gator3294.hostgator.com>

Hi Dan,

It plays without problems in Chrome on my Win7 PC. No need to supply any
info at all.

HTH,
Juan vuletich

On Thu, July 2, 2015 10:15 pm, Dan Norton wrote:
> Hi,
>
>
> I would like to view this, especially since it is recommended by Nicolas,
> Paul, and Juan. The
> question is how to view it without disabling my antivirus plus
> surrendering a bunch of "required" info. BTW I'm running Win7, IE, and
> ESET.
>
>
> Any other possibilities?
>
>
> - Dan
>
>
> On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:
>
>
>>
>>
>>
>> 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
>> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>>
>>
>>> Hi folks,
>>>
>>>
>>> On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>>>
>>>> On Mon, 29 Jun 2015 07:09:43 -0400
>>>> "Phil (list)"<pbpublist at gmail.com>? wrote:
>>>>
>>>>> ..? Is it
>>>>> worth having a class for this vs. raising the more
>> general
>>> Notification
>>>
>>>>> and then checking for a #ReparseAfterSourceEditing signal,
>> and if
>>> it
>>>>> isn't, re-raise Notification in its sole handler? ..
>>>>> This is a specific example of the more general question of
>>>>>
>> where
>>> to draw
>>>>> the line on having single, or very limited, use classes
>> and
>>> methods vs.
>>>>> adding a tiny bit of complexity in one or two methods to
>> simplify
>>> the
>>>>> overall image or package in question.? Thoughts?
>>>> I would say the overriding goal is clarity.
>>>>
>>>>
>>>> It is important work to refactor code to have the same
>>>>
>> behavior
>>> but be easier to understand.
>>>>
>>>> A Smalltalk style goal is to have small methods which do
>>>>
>> things
>>> clearly.? This tends to lead to lots of small methods.
>>>>
>>>> Specializing classes for one or just a few methods may
>>>>
>> seem
>>> wasteful, but computer resources are cheap.
>>>>
>>>> Look at class #PartsBinMorph.? Would you say the having
>>>>
>> the
>>> additional class is wasteful?
>>>>
>>>> It is a tough balance.? Aesthetics and restraint require
>>>>
>> judgement
>>> and we don't always get it right.? It takes time.
>>>>
>>>> I only have so many life hours left.? I feel my time is
>>>>
>> valuable.
>>> I prefer to understand.
>>>
>>>>
>>>> Thank you so much for taking the time to make Cuis more
>>>>
>>> comprehensible.
>>>>
>>>> $0.02
>>>> -KenD
>>>>
>>>
>>> I fully support Ken. I don't think that a general answer is
>>>
>> correct
>>> in all cases here. It is a matter of making code easy to
>> understand.
>>> But
>>> also making it consistent and pretty.
>>>
>>> In general, I don't like making general classes know much
>>>
>> about
>>> details of specific use cases. But there might be exceptions.
>>>
>>> If you feel like experimenting with this kind of stuff, send
>>>
>> your
>>> suggestions to the mail list so we can discuss.
>>>
>>> In the particular case of ReparseAfterSourceEditing, I agree
>>>
>> that a
>>> class that does nothing is a bit strange. But, what is the
>>> alternative? How would the sole exception handler know what to do with
>>> a
>> general
>>> Notification? I think the handler looks quite reasonable right
>>>
>> now.
>>> And
>>> the pollution of the global space might be tolerable if the alternative
>>>  is more convoluted code...
>>>
>>
>> Making code easy to understand is very valuable. Simple things
>> should be simple to accomplish, but achieving this in an API may not
>> always be easy.
>>
>> This weekend I spent lots of "quality time" with the debugger,
>> trying to figure out why I could not get a new window with a
>> PluggableListMorph to work like
>> another one which had exactly the behavior I wanted. The bug was that a
>> method referred to by the #indexSetter: keyword needed to send the
>> #selectedItem: message, which is not
>> mentioned by keyword. Not sure what the answer is for that one but I'm
>> working on notes to try to avoid that stupid mistake in the future. :)
>>
>> I'm just saying we should do anything we can to enhance clarity
>> as well as simplify.
>>
>> ?- Dan
>>
>>
>>
>> Since you are using the right keywords, maybe it's time to view it
>> again Simple made easy
>> http://www.infoq.com/presentations/Simple-Made-Easy
>>
>>
>> _______________________________________________
>> 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 pbpublist at gmail.com  Thu Jul  2 21:03:41 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 02 Jul 2015 22:03:41 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <5595E22F.2684.23EA964@dnorton.mindspring.com>
References: <1435576183.2309.69.camel@gmail.com>
	, <5591C3F9.14896.1CCB41B@dnorton.mindspring.com>
	, <CAKnRiT4r0wD=FEk=GvrtOCjHiqpHsbF5JasS1+Nr6Rg6Nwb7mA@mail.gmail.com>
	<5595E22F.2684.23EA964@dnorton.mindspring.com>
Message-ID: <1435889021.2309.200.camel@gmail.com>

You're probably trying one of the download links.  You can stream the
video as long as JavaScript is enabled.  If you can't temporarily do
this in IE, I'd highly recommend keeping Firefox+NoScript around as it
lets you temporarily enable JavaScript & cookies for this type of
scenario.

On Thu, 2015-07-02 at 21:15 -0400, Dan Norton wrote:
> Hi,
> 
> I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The 
> question is how to view it without disabling my antivirus plus surrendering a bunch of 
> "required" info. BTW I'm running Win7, IE, and ESET.
> 
> Any other possibilities?
> 
>  - Dan
> 
> On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:
> 
> > 
> > 
> > 
> > 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
> >     On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
> >     
> >     > Hi folks,
> >     >
> >     > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> >     > > On Mon, 29 Jun 2015 07:09:43 -0400
> >     > > "Phil (list)"<pbpublist at gmail.com>  wrote:
> >     > >> ..  Is it
> >     > >> worth having a class for this vs. raising the more
> > general
> >     > Notification
> >     > >> and then checking for a #ReparseAfterSourceEditing signal,
> > and if
> >     > it
> >     > >> isn't, re-raise Notification in its sole handler?
> >     > >> ..
> >     > >> This is a specific example of the more general question of
> > where
> >     > to draw
> >     > >> the line on having single, or very limited, use classes
> > and
> >     > methods vs.
> >     > >> adding a tiny bit of complexity in one or two methods to
> > simplify
> >     > the
> >     > >> overall image or package in question.  Thoughts?
> >     > > I would say the overriding goal is clarity.
> >     > >
> >     > > It is important work to refactor code to have the same
> > behavior
> >     > but be easier to understand.
> >     > >
> >     > > A Smalltalk style goal is to have small methods which do
> > things
> >     > clearly.  This tends to lead to lots of small methods.
> >     > >
> >     > > Specializing classes for one or just a few methods may
> > seem
> >     > wasteful, but computer resources are cheap.
> >     > >
> >     > > Look at class #PartsBinMorph.  Would you say the having
> > the
> >     > additional class is wasteful?
> >     > >
> >     > > It is a tough balance.  Aesthetics and restraint require
> > judgement
> >     > and we don't always get it right.  It takes time.
> >     > >
> >     > > I only have so many life hours left.  I feel my time is
> > valuable.
> >     > I prefer to understand.
> >     > >
> >     > > Thank you so much for taking the time to make Cuis more
> >     > comprehensible.
> >     > >
> >     > > $0.02
> >     > > -KenD
> >     >
> >     > I fully support Ken. I don't think that a general answer is
> > correct
> >     > in
> >     > all cases here. It is a matter of making code easy to
> > understand.
> >     > But
> >     > also making it consistent and pretty.
> >     >
> >     > In general, I don't like making general classes know much
> > about
> >     > details
> >     > of specific use cases. But there might be exceptions.
> >     >
> >     > If you feel like experimenting with this kind of stuff, send
> > your
> >     > suggestions to the mail list so we can discuss.
> >     >
> >     > In the particular case of ReparseAfterSourceEditing, I agree
> > that a
> >     > class that does nothing is a bit strange. But, what is the
> >     > alternative?
> >     > How would the sole exception handler know what to do with a
> > general
> >     > Notification? I think the handler looks quite reasonable right
> > now.
> >     > And
> >     > the pollution of the global space might be tolerable if the
> >     > alternative
> >     > is more convoluted code...
> >     >
> > 
> >     Making code easy to understand is very valuable. Simple things
> > should be simple to
> >     accomplish, but achieving this in an API may not always be
> > easy.
> >     
> >     This weekend I spent lots of "quality time" with the debugger,
> > trying to figure out why I could
> >     not get a new window with a PluggableListMorph to work like
> > another one which had exactly
> >     the behavior I wanted. The bug was that a method referred to by
> > the #indexSetter: keyword
> >     needed to send the #selectedItem: message, which is not
> > mentioned by keyword. Not sure
> >     what the answer is for that one but I'm working on notes to try
> > to avoid that stupid mistake in
> >     the future. :)
> >     
> >     I'm just saying we should do anything we can to enhance clarity
> > as well as simplify.
> >     
> >      - Dan
> > 
> > 
> > Since you are using the right keywords, maybe it's time to view it
> > again
> > Simple made easy
> > http://www.infoq.com/presentations/Simple-Made-Easy
> > 
> >     _______________________________________________
> >     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 pbpublist at gmail.com  Sat Jul  4 16:30:43 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 04 Jul 2015 17:30:43 -0400
Subject: [Cuis] Display units and UI widgets in Morphic 3
In-Reply-To: <1435802563.2309.197.camel@gmail.com>
References: <1435714029.2309.155.camel@gmail.com>
	<55948B16.4060100@jvuletich.org> <1435802563.2309.197.camel@gmail.com>
Message-ID: <1436045443.2309.205.camel@gmail.com>

On Wed, 2015-07-01 at 22:02 -0400, Phil (list) wrote:
> On Wed, 2015-07-01 at 21:51 -0300, Juan Vuletich wrote:
> >
> > > (I did take a quick peek at the Morphic 3 package but didn't find
> > > answers as it looks like you're still working out the lower level
> > > details)
> > >
> > > Thanks,
> > > Phil
> > 
> > Well, but that experimental code already can draw essentially any Cuis 
> > morphic World. It is just some lower level details what is missing to 
> > make it the main graphics engine for Cuis.
> > 
> 
> Hmm... then I need to take another look.  I probably wasn't loading
> and/or initializing things correctly.
> 

Ahh... I see my mistake (duh!):  I was trying to load Morphic 3 into the
latest image rather than using your experimental image.  One minor
issue: that image is expecting to find the example SVG files in
svgSamples but the directory is now called SVGSamples.  (Easily
addressed with a symlink so I could run the demo render.)  It looks
very, very nice!

> > Cheers,
> > Juan Vuletich
> 





From Ken.Dickey at whidbey.com  Sat Jul  4 03:04:24 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sat, 4 Jul 2015 16:04:24 +0800
Subject: [Cuis] Package wants to require minimum revision on base
Message-ID: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>

Juan,

The Installed Packages browser used to be able to require a minimum revision on the base release.

I use this feature as a backstop when features change in the base release.

Any chance in getting this ability back?

Thanks much,
-KenD



From hannes.hirzel at gmail.com  Sat Jul  4 18:45:41 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 4 Jul 2015 23:45:41 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
Message-ID: <CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>

Juan,

And this brings up the question that it would be good to have a
'release tag' from time to time.

So that releases show up here

    https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases

Currently there are 0 releases. This is very straightforward to do in github.

This will facilitate checking if external packages still run fine.
There are about 50 commits in
Cuis-Smalltalk-Dev in first two quaters of 2015.

I think I some minor releases (i.e. 2 ... 6 a year) would be fine.

Thanks for considering this

--Hannes

On 7/4/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> Juan,
>
> The Installed Packages browser used to be able to require a minimum revision
> on the base release.
>
> I use this feature as a backstop when features change in the base release.
>
> Any chance in getting this ability back?
>
> Thanks much,
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From pbpublist at gmail.com  Sat Jul  4 19:51:18 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 04 Jul 2015 20:51:18 -0400
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
Message-ID: <1436057478.2309.229.camel@gmail.com>

On Sat, 2015-07-04 at 23:45 +0000, H. Hirzel wrote:
> Juan,
> 
> And this brings up the question that it would be good to have a
> 'release tag' from time to time.
> 
> So that releases show up here
> 
>     https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases
> 
> Currently there are 0 releases. This is very straightforward to do in github.
> 
> This will facilitate checking if external packages still run fine.
> There are about 50 commits in
> Cuis-Smalltalk-Dev in first two quaters of 2015.
> 
> I think I some minor releases (i.e. 2 ... 6 a year) would be fine.
> 
> Thanks for considering this
> 

It seems like for most of my packages I'd need to tie to a minimum build
# (what Ken asked for, i.e. #2400) rather than a version # (4.2.7 or
whatever) right now.  How do you envision using a version # given that
people will pretty much grab whatever the current build is at the time
they download Cuis?

> --Hannes
> 
> On 7/4/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> > Juan,
> >
> > The Installed Packages browser used to be able to require a minimum revision
> > on the base release.
> >
> > I use this feature as a backstop when features change in the base release.
> >
> > Any chance in getting this ability back?
> >
> > Thanks much,
> > -KenD
> >
> > _______________________________________________
> > 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  Sun Jul  5 09:01:06 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 05 Jul 2015 11:01:06 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
Message-ID: <559938A2.3040204@jvuletich.org>

Hi Ken,

On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
> Juan,
>
> The Installed Packages browser used to be able to require a minimum revision on the base release.
>
> I use this feature as a backstop when features change in the base release.
>
> Any chance in getting this ability back?
>
> Thanks much,
> -KenD

When was it lost?  I can't remember doing anything related to this...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sun Jul  5 09:03:44 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 05 Jul 2015 11:03:44 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
Message-ID: <55993940.8090704@jvuletich.org>

Hi Hannes,

Sure, let's discuss this. What do other people maintaining external 
packages think? This is for you...

Cheers,
Juan Vuletich

On 04/07/2015 08:45 p.m., H. Hirzel wrote:
> Juan,
>
> And this brings up the question that it would be good to have a
> 'release tag' from time to time.
>
> So that releases show up here
>
>      https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases
>
> Currently there are 0 releases. This is very straightforward to do in github.
>
> This will facilitate checking if external packages still run fine.
> There are about 50 commits in
> Cuis-Smalltalk-Dev in first two quaters of 2015.
>
> I think I some minor releases (i.e. 2 ... 6 a year) would be fine.
>
> Thanks for considering this
>
> --Hannes
>
> On 7/4/15, Ken.Dickey<Ken.Dickey at whidbey.com>  wrote:
>> Juan,
>>
>> The Installed Packages browser used to be able to require a minimum revision
>> on the base release.
>>
>> I use this feature as a backstop when features change in the base release.
>>
>> Any chance in getting this ability back?
>>
>> Thanks much,
>> -KenD
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>




From Ken.Dickey at whidbey.com  Sat Jul  4 20:57:51 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sun, 5 Jul 2015 09:57:51 +0800
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <559938A2.3040204@jvuletich.org>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<559938A2.3040204@jvuletich.org>
Message-ID: <20150705095751.c84ded291d123bac31348c46@whidbey.com>

On Sun, 05 Jul 2015 11:01:06 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Ken,
> 
> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
> > Juan,
> >
> > The Installed Packages browser used to be able to require a minimum revision on the base release.
> >
> > I use this feature as a backstop when features change in the base release.
> >
> > Any chance in getting this ability back?
> >
> > Thanks much,
> > -KenD
> 
> When was it lost?  I can't remember doing anything related to this...

Not sure when.

If there is more than one package loaded, one can Add Requirement with one option being the base release.  If only one package is loaded, one gets the "Required package must already be loaded" popup, rather than an option to require Cuis-Base.

-- 
-KenD



From dnorton at mindspring.com  Sun Jul  5 18:35:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 05 Jul 2015 19:35:22 -0400
Subject: [Cuis] Minor Direction Padding
Message-ID: <5599BF3A.26485.1F11628@dnorton.mindspring.com>

Greetings,

Four LayoutSpec class methods use "minorDirectionPadding:" as a keyword. The parameter 
can be a number or one of: #top, #left, #center, #right, or #bottom. AFAICT when the 
parameter is a number, it refers to the padding which will be applied in the minor direction. 
When it is a symbol, it effectively specifies that morphs will be located as the symbol name 
implies.

Attached are four convenience methods whose keyword emphasizes the visible (morph) 
instead of the invisible (padding). The "morphPlacement:" parameter can be  #top, #left, 
#center, #right, or #bottom. The methods are:

LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
LayoutSpec class>>proportionalWidth:proportionalHeight:morphPlacement:

Are these worth having in the base system?

 - Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: LayoutSpec class-convenience.zip
Type: application/zip
Size: 1988 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150705/2ebc6107/attachment-0004.zip>

From pbpublist at gmail.com  Mon Jul  6 03:01:56 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 06 Jul 2015 04:01:56 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
Message-ID: <1436169716.2678.46.camel@gmail.com>

Hannes,

Sorry for the delay... it's taken me longer than expected to get back to
it.  I really don't have any simple examples of porting as my stuff is
fairly involved (i.e. drawing and keyboard handling as part of a larger
OpenGL project etc.)  However, I do have more specifics re: what needed
to be done.

On Tue, 2015-03-10 at 06:56 +0000, H. Hirzel wrote:
> Phil,
> 
> could you please provide an example code snippet (Morph class).
> 
> Version 4.0
> vs
> Version 4.2
> ?
> 
> On 3/10/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > Created https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/48 for
> > this.
> >
> > On 3/9/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> On Mon, 2015-03-09 at 05:54 -0400, Phil (list) wrote:
> >>> 1) Morph stepping appears to be non-functional (at least in terms of
> >>> running the code as-is from Cuis 4.0)
> >>
> >> Figured this one out... #step appears to be obsolete, use #stepAt:
> >> instead.  In some cases now need to override #wantsSteps to return true
> >> (the default implementation now always returns false.  This is an issue
> >> only for some of my animated morphs.)
> >>

Morphic (continuous) animation

previously:
#step

now:
#stepAt: (just rename #step to #stepAt: milliseconds)
#wantsSteps (^true)

Notes:
1) If this change isn't made, you may get what appears to be animation,
but it's just the morph redrawing after damage.
2) Be sure to call #truncate on bounds etc. if your code can't handle
floats.
3) I used to have several direct Morph subclasses, but it appears that
they now need to be RectangleLikeMorph subclasses to maintain similar
behavior.



Keyboard focus handling

previously:
#handlesKeyboard (^ true)
#keyboardFocusChange: (call any code needed to deal with getting/losing
focus such as drawing a focus indicator)
#handleKeystroke: (when morph has focus, will receive keystroke)

now:
This is my best guess... are there any examples of working Morphs that
deal with keyboard focus but do *not* have text morphs?
#handlesKeyboard (no change)
#handlesMouseOver: (^true to get #mouseEnter: & #mouseLeave:)
#mouseEnter: event
	event hand newKeyboardFocus: self
#mouseLeave: event
	event hand newKeyboardFocus: nil
#keyStroke: event (receives the keystroke when focused, some event
accessors no longer exist)

Thanks,
Phil




From pbpublist at gmail.com  Mon Jul  6 03:12:39 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 06 Jul 2015 04:12:39 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1436169716.2678.46.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
	<1436169716.2678.46.camel@gmail.com>
Message-ID: <1436170359.2678.52.camel@gmail.com>

On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote:
> Hannes,
> 
> Sorry for the delay... it's taken me longer than expected to get back to
> it.  I really don't have any simple examples of porting as my stuff is
> fairly involved (i.e. drawing and keyboard handling as part of a larger
> OpenGL project etc.)  However, I do have more specifics re: what needed
> to be done.
> 
<snip>
> 
> Keyboard focus handling
> 

One additional thing related to keyboard focus that should probably be
handled by Morphic: various mouse (mouse wheel) and trackpad (gesture)
events get sent as keyboard events and should probably be (at least
optionally?) intercepted from the event stream and sent as distinct
events such as #scroll: etc.  No idea how multi-finger touch screen
gestures are handled by the VM these days but that is yet something else
to think about...

> 
> Thanks,
> Phil





From juan at jvuletich.org  Mon Jul  6 08:33:23 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 06 Jul 2015 10:33:23 -0300
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <5599BF3A.26485.1F11628@dnorton.mindspring.com>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>
Message-ID: <559A83A3.5040406@jvuletich.org>

Hi Dan,

On 7/5/2015 8:35 PM, Dan Norton wrote:
> Greetings,
>
> Four LayoutSpec class methods use "minorDirectionPadding:" as a keyword. The parameter
> can be a number or one of: #top, #left, #center, #right, or #bottom. AFAICT when the
> parameter is a number, it refers to the padding which will be applied in the minor direction.
> When it is a symbol, it effectively specifies that morphs will be located as the symbol name
> implies.
>
> Attached are four convenience methods whose keyword emphasizes the visible (morph)
> instead of the invisible (padding). The "morphPlacement:" parameter can be  #top, #left,
> #center, #right, or #bottom. The methods are:
>
> LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
> LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
> LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
> LayoutSpec class>>proportionalWidth:proportionalHeight:morphPlacement:
>
> Are these worth having in the base system?
>
>   - Dan
>

I'd rather replace the keyword 'minorDirectionPadding:' by 
'minorDirectionPlacement:' to:
- Avoid ambiguity
- Avoid duplication

What do you all think?

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Mon Jul  6 10:00:36 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 6 Jul 2015 15:00:36 +0000
Subject: [Cuis] Status of Morphic?
In-Reply-To: <1436170359.2678.52.camel@gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
	<1436169716.2678.46.camel@gmail.com>
	<1436170359.2678.52.camel@gmail.com>
Message-ID: <CAGQxfVgb34x3P9shmHgs9=MMu0uQbAFQdBNSm9VfUCaZvVCQgA@mail.gmail.com>

Phil,

thank you for answering three months later. That is fine, I'd like to
distill from our conversation some upgrade notes from Cuis Morphic 4.0
to Cuis Morphic 4.2.

I created an issue for this for the documentation of Cuis

   https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/65

Quite a number of issues are piled up there and I want to work on them
in batch mode in one go sometime in the upcoming months.

So if this thread goes to sleep for three more months I do not have
any problem with it ...

:-)


The documentation of course is related to the issue of having release
version numbers you can refer to.


Ideally we have release notes from time to time which list the changes
and test reports which packages work with which release.

--Hannes

On 7/6/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote:
>> Hannes,
>>
>> Sorry for the delay... it's taken me longer than expected to get back to
>> it.  I really don't have any simple examples of porting as my stuff is
>> fairly involved (i.e. drawing and keyboard handling as part of a larger
>> OpenGL project etc.)  However, I do have more specifics re: what needed
>> to be done.
>>
> <snip>
>>
>> Keyboard focus handling
>>
>
> One additional thing related to keyboard focus that should probably be
> handled by Morphic: various mouse (mouse wheel) and trackpad (gesture)
> events get sent as keyboard events and should probably be (at least
> optionally?) intercepted from the event stream and sent as distinct
> events such as #scroll: etc.  No idea how multi-finger touch screen
> gestures are handled by the VM these days but that is yet something else
> to think about...
>
>>
>> Thanks,
>> Phil
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Mon Jul  6 10:04:05 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 6 Jul 2015 15:04:05 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <55993940.8090704@jvuletich.org>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<CAGQxfVjQa00=12btpkqwY-mM0uQvpTdxmMPwsoU5Q5cpFM0e3A@mail.gmail.com>
	<55993940.8090704@jvuletich.org>
Message-ID: <CAGQxfVhAxbOCLaztuYifqRR-9rFgHThVF6C5pz5nw1OBXdOiTQ@mail.gmail.com>

On 7/5/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Hannes,
>
> Sure, let's discuss this. What do other people maintaining external
> packages think? This is for you...


Thank you. I think the issue is that the 50 or so commits in the first
six months of this year needed to be grouped into larger chunks,
called minor released.

I understand that in github a release is just a tab on a particular
commit, i.e. they may be still be added.

And the most straightforward thing is to continue numbering with where
you left off before moving to github.

It should be easy for people to check out a particular release of the past.

This in particular as many months might pass between work on Cuis for
a particular project.


>
> Cheers,
> Juan Vuletich
>
> On 04/07/2015 08:45 p.m., H. Hirzel wrote:
>> Juan,
>>
>> And this brings up the question that it would be good to have a
>> 'release tag' from time to time.
>>
>> So that releases show up here
>>
>>      https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/releases
>>
>> Currently there are 0 releases. This is very straightforward to do in
>> github.
>>
>> This will facilitate checking if external packages still run fine.
>> There are about 50 commits in
>> Cuis-Smalltalk-Dev in first two quaters of 2015.
>>
>> I think I some minor releases (i.e. 2 ... 6 a year) would be fine.
>>
>> Thanks for considering this
>>
>> --Hannes
>>
>> On 7/4/15, Ken.Dickey<Ken.Dickey at whidbey.com>  wrote:
>>> Juan,
>>>
>>> The Installed Packages browser used to be able to require a minimum
>>> revision
>>> on the base release.
>>>
>>> I use this feature as a backstop when features change in the base
>>> release.
>>>
>>> Any chance in getting this ability back?
>>>
>>> Thanks much,
>>> -KenD
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>
>



From dnorton at mindspring.com  Mon Jul  6 10:37:06 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 06 Jul 2015 11:37:06 -0400
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <559A83A3.5040406@jvuletich.org>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>,
	<559A83A3.5040406@jvuletich.org>
Message-ID: <559AA0A2.13962.3B4CD8@dnorton.mindspring.com>

On 6 Jul 2015 at 10:33, Juan Vuletich wrote:

> Hi Dan,
> 
> On 7/5/2015 8:35 PM, Dan Norton wrote:
> > Greetings,
> >
> > Four LayoutSpec class methods use "minorDirectionPadding:" as a
> keyword. The parameter
> > can be a number or one of: #top, #left, #center, #right, or
> #bottom. AFAICT when the
> > parameter is a number, it refers to the padding which will be
> applied in the minor direction.
> > When it is a symbol, it effectively specifies that morphs will be
> located as the symbol name
> > implies.
> >
> > Attached are four convenience methods whose keyword emphasizes the
> visible (morph)
> > instead of the invisible (padding). The "morphPlacement:"
> parameter can be  #top, #left,
> > #center, #right, or #bottom. The methods are:
> >
> > LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
> > LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
> > LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
> > LayoutSpec
> class>>proportionalWidth:proportionalHeight:morphPlacement:
> >
> > Are these worth having in the base system?
> >
> >   - Dan
> >
> 
> I'd rather replace the keyword 'minorDirectionPadding:' by 
> 'minorDirectionPlacement:' to:
> - Avoid ambiguity
> - Avoid duplication
> 
OK, as far as the duplication, but I don't see "morphPlacement:" in use. Where does the 
ambiguity occur?

 - Dan



From dnorton at mindspring.com  Mon Jul  6 10:49:46 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 06 Jul 2015 11:49:46 -0400
Subject: [Cuis] Cuis Archive
Message-ID: <559AA39A.19585.46E7C0@dnorton.mindspring.com>

Hi,

There is nothing in the archive for July. Anybody else experiencing this?

 - Dan



From dnorton at mindspring.com  Mon Jul  6 21:05:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 06 Jul 2015 22:05:22 -0400
Subject: [Cuis] Where to put the complexity?
In-Reply-To: <1435889021.2309.200.camel@gmail.com>
References: <1435576183.2309.69.camel@gmail.com>,
	<5595E22F.2684.23EA964@dnorton.mindspring.com>,
	<1435889021.2309.200.camel@gmail.com>
Message-ID: <559B33E2.1296.27A7F1A@dnorton.mindspring.com>

On 2 Jul 2015 at 22:03, Phil (list) wrote:

> You're probably trying one of the download links.  You can stream
> the
> video as long as JavaScript is enabled.  If you can't temporarily
> do
> this in IE, I'd highly recommend keeping Firefox+NoScript around as
> it
> lets you temporarily enable JavaScript & cookies for this type of
> scenario.
> [...]

Thanks, Phil. That's better.

 - Dan




From pbpublist at gmail.com  Mon Jul  6 22:03:26 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 06 Jul 2015 23:03:26 -0400
Subject: [Cuis] Status of Morphic?
In-Reply-To: <CAGQxfVgb34x3P9shmHgs9=MMu0uQbAFQdBNSm9VfUCaZvVCQgA@mail.gmail.com>
References: <1425894846.2281.37.camel@gmail.com>
	<1425941907.2948.6.camel@gmail.com>
	<CAGQxfVgY-XbA8vL9oz_XBgPRDF17xpEWOHW825DWORyHzR9Pfg@mail.gmail.com>
	<CAGQxfVg+DcVOHjq8U+Ww-zH=u+WjAfuCWvXeKiu4nUYkdH5gEw@mail.gmail.com>
	<1436169716.2678.46.camel@gmail.com>
	<1436170359.2678.52.camel@gmail.com>
	<CAGQxfVgb34x3P9shmHgs9=MMu0uQbAFQdBNSm9VfUCaZvVCQgA@mail.gmail.com>
Message-ID: <1436238206.2678.107.camel@gmail.com>

On Mon, 2015-07-06 at 15:00 +0000, H. Hirzel wrote:
> Phil,
> 
> thank you for answering three months later. That is fine, I'd like to
> distill from our conversation some upgrade notes from Cuis Morphic 4.0
> to Cuis Morphic 4.2.
> 

Apologies for taking so long... I figured better late than never.

> I created an issue for this for the documentation of Cuis
> 
>    https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/65
> 
> Quite a number of issues are piled up there and I want to work on them
> in batch mode in one go sometime in the upcoming months.
> 
> So if this thread goes to sleep for three more months I do not have
> any problem with it ...
> 
> :-)
> 

I'll try to stop being such a troublemaker... (promises, promises :-)

> 
> The documentation of course is related to the issue of having release
> version numbers you can refer to.
> 

Ah, now I understand why you're asking for version #'s/tags/something.

> 
> Ideally we have release notes from time to time which list the changes
> and test reports which packages work with which release.
> 

The reporting part sounds like Continuous Integration testing to me...

> --Hannes
> 
> On 7/6/15, Phil (list) <pbpublist at gmail.com> wrote:
> > On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote:
> >> Hannes,
> >>
> >> Sorry for the delay... it's taken me longer than expected to get back to
> >> it.  I really don't have any simple examples of porting as my stuff is
> >> fairly involved (i.e. drawing and keyboard handling as part of a larger
> >> OpenGL project etc.)  However, I do have more specifics re: what needed
> >> to be done.
> >>
> > <snip>
> >>
> >> Keyboard focus handling
> >>
> >
> > One additional thing related to keyboard focus that should probably be
> > handled by Morphic: various mouse (mouse wheel) and trackpad (gesture)
> > events get sent as keyboard events and should probably be (at least
> > optionally?) intercepted from the event stream and sent as distinct
> > events such as #scroll: etc.  No idea how multi-finger touch screen
> > gestures are handled by the VM these days but that is yet something else
> > to think about...
> >
> >>
> >> Thanks,
> >> Phil
> >
> >
> >
> > _______________________________________________
> > 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 pbpublist at gmail.com  Tue Jul  7 01:59:59 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 07 Jul 2015 02:59:59 -0400
Subject: [Cuis] MNU bug with halo in world
Message-ID: <1436252399.2678.117.camel@gmail.com>

Juan,

In an empty area in the world, middle click to bring up a halo for the
world PasteUpMorph.  Middle click again... MNU.

Thanks,
Phil




From hannes.hirzel at gmail.com  Tue Jul  7 06:22:43 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 7 Jul 2015 11:22:43 +0000
Subject: [Cuis] Status of continuous integration testing // release numbers
	to refer to?
Message-ID: <CAGQxfVie+JNw0R3rEXN4-WuUUWc8AS-Pa3k3u42A+A=fFvmibA@mail.gmail.com>

On 7/7/15, Phil (list) <pbpublist at gmail.com> wrote:
....
>
> The documentation of course is related to the issue of having release
> version numbers you can refer to.
>

Ah, now I understand why you're asking for version #'s/tags/something.
..

>> Ideally we have release notes from time to time which list the changes
>> and test reports which packages work with which release.
>>
>
> The reporting part sounds like Continuous Integration testing to me...
>

Hello Juan

You recently had a note to the ML that you are doing integration
testing before each of your releases which are announced on the
mailing list with an 'update' mail.

I understand that you are loading all packages in

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Packages

and run the tests there in addition to the tests built into Cuis core.

Is this so?

Do you produce a log file of the results which might be archived as
well in the repository?

Kind regards

Hannes



From hannes.hirzel at gmail.com  Tue Jul  7 07:06:48 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 7 Jul 2015 12:06:48 +0000
Subject: [Cuis] MNU bug with halo in world
In-Reply-To: <1436252399.2678.117.camel@gmail.com>
References: <1436252399.2678.117.camel@gmail.com>
Message-ID: <CAGQxfViw8_6ow6LGpAG8SkFfkYgh5_P2aZqzDeCNAKqfsLFk8A@mail.gmail.com>

Added to issues

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/66

--HH

On 7/7/15, Phil (list) <pbpublist at gmail.com> wrote:
> Juan,
>
> In an empty area in the world, middle click to bring up a halo for the
> world PasteUpMorph.  Middle click again... MNU.
>
> Thanks,
> Phil
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From Ken.Dickey at whidbey.com  Tue Jul  7 08:04:18 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 7 Jul 2015 06:04:18 -0700
Subject: [Cuis] MorphIt -- toward direct authoring with media
Message-ID: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>

Greetings all,

I have put some pre-Alpha proof-of-concept code in BabySteps

	https://github.com/KenDickey/Cuis-Smalltalk-BabySteps

The package is called MorphIt, the gist being drag-n-drop prototype style modification of Morphs with a general goal of multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..

As some of you may know, my style is to have a bunch of half baked ideas roiling around in my head which I tend to think through by writing code.  

Very early days yet, but anyone with time on their hands can see what works and what doesn't.  The README.md has some notes on directions.

Cheers, 
-KenD

================
When Michael Faraday first demonstrated electromagnetic induction, the Prime Minister asked, ?Of what use is this discovery, Mr. Faraday?? Faraday replied, ?Of what use is a baby, Mr. Prime Minister??



From dnorton at mindspring.com  Tue Jul  7 12:05:17 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 07 Jul 2015 13:05:17 -0400
Subject: [Cuis] Loop during StrikeFont install:
Message-ID: <559C06CD.15379.DC94F3@dnorton.mindspring.com>

To cause this loop:

In directory "Cuis-Smalltalk-Dev-master" have no "AAFonts" directory.
Do (cmd-d) StrikeFont install: 'Optima'
Get a loop instead of "File does not exist" exception.

 - Dan



From pbpublist at gmail.com  Tue Jul  7 16:57:40 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 07 Jul 2015 17:57:40 -0400
Subject: [Cuis] OpenGL questions
Message-ID: <1436306260.2678.148.camel@gmail.com>

Just wanted to see if anyone other than me is currently using my OpenGL
port at https://github.com/pbella/Cuis-Ports?  I ask because what is
currently there is from some old Squeak/Croquet code that only supported
OpenGL 1.x (1.3, I believe) and I'm getting ready to update it but will
need to break some things no matter how I decide to do it (i.e. related
to the next question)

Does anyone care about the 'full' OpenGL API anymore?  My general sense
is that unless one is a developer of CAD software or high-end video game
engines, the full/desktop API doesn't add much value esp. given how
limiting it is in terms of portability.  As recent releases of OpenGL
are supersets of OpenGL ES, I'm thinking of just supporting ES and that
way both desktop and mobile devices can be targeted with the same code
and have a much smaller API to deal with.  However, if anyone has a
burning need for a non-ES flavor, now would be the time to speak up.

Thanks,
Phil




From Ken.Dickey at whidbey.com  Tue Jul  7 02:52:26 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 7 Jul 2015 15:52:26 +0800
Subject: [Cuis] OpenGL questions
In-Reply-To: <1436306260.2678.148.camel@gmail.com>
References: <1436306260.2678.148.camel@gmail.com>
Message-ID: <20150707155226.9877626cbfa5f046b51073c8@whidbey.com>

On Tue, 07 Jul 2015 17:57:40 -0400
"Phil (list)" <pbpublist at gmail.com> wrote:

> Just wanted to see if anyone other than me is currently using my OpenGL
> port at https://github.com/pbella/Cuis-Ports? 

Not me (so far).

ES would be great!

-KenD



From juan at jvuletich.org  Wed Jul  8 09:33:04 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 08 Jul 2015 11:33:04 -0300
Subject: [Cuis] Status of continuous integration testing // release
 numbers to refer to?
In-Reply-To: <CAGQxfVie+JNw0R3rEXN4-WuUUWc8AS-Pa3k3u42A+A=fFvmibA@mail.gmail.com>
References: <CAGQxfVie+JNw0R3rEXN4-WuUUWc8AS-Pa3k3u42A+A=fFvmibA@mail.gmail.com>
Message-ID: <559D34A0.5080102@jvuletich.org>

Hi Hannes,

On 7/7/2015 8:22 AM, H. Hirzel wrote:
> Hello Juan
>
> You recently had a note to the ML that you are doing integration
> testing before each of your releases which are announced on the
> mailing list with an 'update' mail.

Yes, I do that before pushing to github, almost every time.

> I understand that you are loading all packages in
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Packages
>
> and run the tests there in addition to the tests built into Cuis core.
>
> Is this so?

Yes.

> Do you produce a log file of the results which might be archived as
> well in the repository?

Well, recently I did SUnit XML reports.pck.st, so it is not a big deal 
to do it. I'll try to remember. Please nag me if I forget about it.

> Kind regards
>
> Hannes

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  8 09:34:20 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 08 Jul 2015 11:34:20 -0300
Subject: [Cuis] MNU bug with halo in world
In-Reply-To: <1436252399.2678.117.camel@gmail.com>
References: <1436252399.2678.117.camel@gmail.com>
Message-ID: <559D34EC.4000608@jvuletich.org>

On 7/7/2015 3:59 AM, Phil (list) wrote:
> Juan,
>
> In an empty area in the world, middle click to bring up a halo for the
> world PasteUpMorph.  Middle click again... MNU.
>
> Thanks,
> Phil
>

Thanks for reporting! I have the fix, and it will be in the next commit 
I do.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul  8 09:37:15 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 08 Jul 2015 11:37:15 -0300
Subject: [Cuis] OpenGL questions
In-Reply-To: <1436306260.2678.148.camel@gmail.com>
References: <1436306260.2678.148.camel@gmail.com>
Message-ID: <559D359B.9090607@jvuletich.org>

Hi Phil,

I'm not using it, but it is a very nice to have it. I'd say, stick to 
the subset that makes most sense for you. Very few people could need the 
full OpenGL api. ES sounds very reasonable to me.

Cheers,
Juan Vuletich

On 7/7/2015 6:57 PM, Phil (list) wrote:
> Just wanted to see if anyone other than me is currently using my OpenGL
> port at https://github.com/pbella/Cuis-Ports?  I ask because what is
> currently there is from some old Squeak/Croquet code that only supported
> OpenGL 1.x (1.3, I believe) and I'm getting ready to update it but will
> need to break some things no matter how I decide to do it (i.e. related
> to the next question)
>
> Does anyone care about the 'full' OpenGL API anymore?  My general sense
> is that unless one is a developer of CAD software or high-end video game
> engines, the full/desktop API doesn't add much value esp. given how
> limiting it is in terms of portability.  As recent releases of OpenGL
> are supersets of OpenGL ES, I'm thinking of just supporting ES and that
> way both desktop and mobile devices can be targeted with the same code
> and have a much smaller API to deal with.  However, if anyone has a
> burning need for a non-ES flavor, now would be the time to speak up.
>
> Thanks,
> Phil
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From dnorton at mindspring.com  Wed Jul  8 18:44:53 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 08 Jul 2015 19:44:53 -0400
Subject: [Cuis] #browseVersions Key not Found
Message-ID: <559DB5F5.25858.20175F4@dnorton.mindspring.com>

>From a browser, the versions button works as it should.

However, from a ProtocolBrowser, if the message is from a superclass a "key not found" 
error occurs. 

Versions of messages belonging to the class being "protocol browsed" are listed as they 
should be.

 - Dan



From dnorton at mindspring.com  Wed Jul  8 19:03:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 08 Jul 2015 20:03:07 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <559DBA3B.28326.21224C9@dnorton.mindspring.com>

For my PluggableListMorph, the model prepares list elements on a "String new writeStream." 
They are not static. I need for these list elements to be aligned in columns like a small 
spreadsheet. A fixed font would be handy - how can I install one?

Any other approaches to get columns in a list?

 - Dan



From pbpublist at gmail.com  Thu Jul  9 04:15:37 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 09 Jul 2015 05:15:37 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
Message-ID: <1436433337.2325.6.camel@gmail.com>

This is a minor nit but when I'm developing Morphs I often need to
instantiate them manually via something like 'MorphName new
openInWorld.'  When I do that, I almost always find its initial position
annoying and in some cases nearly non-functional since the Morph doesn't
have room for its halo icons.  Just wondering if this bothers anyone
else and if maybe insetting new morphs top left by default to something
like 50 @ 50 (something out of the way, but giving it a bit of margin
from the edge of the screen) might be better?




From hannes.hirzel at gmail.com  Thu Jul  9 05:43:42 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 9 Jul 2015 10:43:42 +0000
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
Message-ID: <CAGQxfVhNEnergmoFZJtyENR7nGLKSgWsPGR5z+o83pzV9TfS7A@mail.gmail.com>

+1

On 7/9/15, Phil (list) <pbpublist at gmail.com> wrote:
> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial position
> annoying and in some cases nearly non-functional since the Morph doesn't
> have room for its halo icons.  Just wondering if this bothers anyone
> else and if maybe insetting new morphs top left by default to something
> like 50 @ 50 (something out of the way, but giving it a bit of margin
> from the edge of the screen) might be better?
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Thu Jul  9 09:49:07 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 09 Jul 2015 10:49:07 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
Message-ID: <559E89E3.19425.2863A2@dnorton.mindspring.com>

On 9 Jul 2015 at 5:15, Phil (list) wrote:

> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial
> position
> annoying and in some cases nearly non-functional since the Morph
> doesn't
> have room for its halo icons.  Just wondering if this bothers
> anyone
> else and if maybe insetting new morphs top left by default to
> something
> like 50 @ 50 (something out of the way, but giving it a bit of
> margin
> from the edge of the screen) might be better?
> 

+1

Also, it's pretty dark up there and the black on blue MinimalStringMorph is hard to see, for 
example.

 - Dan



From sean at clipperadams.com  Thu Jul  9 09:43:55 2015
From: sean at clipperadams.com (Sean P. DeNigris)
Date: Thu, 9 Jul 2015 07:43:55 -0700 (PDT)
Subject: [Cuis] MorphIt -- toward direct authoring with media
In-Reply-To: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
References: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
Message-ID: <1436453035366-4836792.post@n4.nabble.com>

Ken.Dickey wrote
> drag-n-drop prototype style modification of Morphs with a general goal of
> multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..

Sounds fantastic!



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/MorphIt-toward-direct-authoring-with-media-tp4836232p4836792.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From casey.obrien.r at gmail.com  Thu Jul  9 21:05:20 2015
From: casey.obrien.r at gmail.com (Casey Ransberger)
Date: Thu, 9 Jul 2015 19:05:20 -0700
Subject: [Cuis] MorphIt -- toward direct authoring with media
In-Reply-To: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
References: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
Message-ID: <A420D093-D868-490D-AC79-3DDED1561178@gmail.com>

Hey Ken,

Woot! I was working on something that did this but got distracted by a shiny robot before it got close to working. 

I've wanted to see Self-style authoring in Cuis ever since I realized that I liked working with Cuis better than the other distributions. It was the one thing I really enjoyed in Squeak that we're really missing in Cuisland. 

If we can throw in some HyperCard and... what is that thing from Self? Little tool to zero in on a Morph and then inspect it? Anyway, that thing. Would be just amazingly awesome. 

--C

> On Jul 7, 2015, at 6:04 AM, "Ken.Dickey" <Ken.Dickey at whidbey.com> wrote:
> 
> Greetings all,
> 
> I have put some pre-Alpha proof-of-concept code in BabySteps
> 
>    https://github.com/KenDickey/Cuis-Smalltalk-BabySteps
> 
> The package is called MorphIt, the gist being drag-n-drop prototype style modification of Morphs with a general goal of multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..
> 
> As some of you may know, my style is to have a bunch of half baked ideas roiling around in my head which I tend to think through by writing code.  
> 
> Very early days yet, but anyone with time on their hands can see what works and what doesn't.  The README.md has some notes on directions.
> 
> Cheers, 
> -KenD
> 
> ================
> When Michael Faraday first demonstrated electromagnetic induction, the Prime Minister asked, ?Of what use is this discovery, Mr. Faraday?? Faraday replied, ?Of what use is a baby, Mr. Prime Minister??
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



From casey.obrien.r at gmail.com  Thu Jul  9 21:11:24 2015
From: casey.obrien.r at gmail.com (Casey Ransberger)
Date: Thu, 9 Jul 2015 19:11:24 -0700
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
Message-ID: <D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>

I want this too. What needs to be done is to make a StrikeFont, IIRC. I didn't get a round toit. If anyone has an extra round toit that I can borrow, I'd be very appreciative. 

Anyway I think if you look around at the class StrikeFont, you'll find a trailhead or rabbit hole that you can follow toward how to #doIt.

Someone correct me if I'm wrong.

--C

> On Jul 8, 2015, at 5:03 PM, "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> For my PluggableListMorph, the model prepares list elements on a "String new writeStream." 
> They are not static. I need for these list elements to be aligned in columns like a small 
> spreadsheet. A fixed font would be handy - how can I install one?
> 
> Any other approaches to get columns in a list?
> 
> - Dan
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



From dnorton at mindspring.com  Fri Jul 10 09:20:45 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 10 Jul 2015 10:20:45 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
Message-ID: <559FD4BD.26551.31649C@dnorton.mindspring.com>

On 9 Jul 2015 at 19:11, Casey Ransberger wrote:

> I want this too. What needs to be done is to make a StrikeFont,
> IIRC. I didn't get a round toit. If anyone has an extra round toit
> that I can borrow, I'd be very appreciative. 
> 
Thought I had one... must be around here somewhere... :(

> Anyway I think if you look around at the class StrikeFont, you'll
> find a trailhead or rabbit hole that you can follow toward how to
> #doIt.
> 
Browsing through strike fonts, I see no fixed widths. But, true type fonts have a few 
fixed-width examples. There seems to be no way to install a .ttf in Cuis currently.

Can we port TrueType-Support from Squeak?

Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits from AbstractFont?

Any hints or guidance would be most welcomed.

> Someone correct me if I'm wrong.
> 
> --C
> 
> > On Jul 8, 2015, at 5:03 PM, "Dan Norton" <dnorton at mindspring.com>
> wrote:
> > 
> > For my PluggableListMorph, the model prepares list elements on a
> "String new writeStream." 
> > They are not static. I need for these list elements to be aligned
> in columns like a small 
> > spreadsheet. A fixed font would be handy - how can I install
> one?
> > 
> > Any other approaches to get columns in a list?
> > 
> > - Dan
> > 
> > _______________________________________________
> > 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

 - Dan




From pbpublist at gmail.com  Fri Jul 10 12:29:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 10 Jul 2015 13:29:01 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559FD4BD.26551.31649C@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	, <D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
Message-ID: <1436549341.2325.3.camel@gmail.com>

On Fri, 2015-07-10 at 10:20 -0400, Dan Norton wrote:
> On 9 Jul 2015 at 19:11, Casey Ransberger wrote:
> 
> > I want this too. What needs to be done is to make a StrikeFont,
> > IIRC. I didn't get a round toit. If anyone has an extra round toit
> > that I can borrow, I'd be very appreciative. 
> > 
> Thought I had one... must be around here somewhere... :(
> 
> > Anyway I think if you look around at the class StrikeFont, you'll
> > find a trailhead or rabbit hole that you can follow toward how to
> > #doIt.
> > 
> Browsing through strike fonts, I see no fixed widths. But, true type fonts have a few 
> fixed-width examples. There seems to be no way to install a .ttf in Cuis currently.
> 
> Can we port TrueType-Support from Squeak?
> 
> Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits from AbstractFont?
> 
> Any hints or guidance would be most welcomed.

I'd like a fixed-width font as well but I suspect that this is one of
the areas it might be better to wait until Morphic 3 on (i.e. isn't the
existing font support based on bitmap fonts rather than vector?)

> 
> > Someone correct me if I'm wrong.
> > 
> > --C
> > 
> > > On Jul 8, 2015, at 5:03 PM, "Dan Norton" <dnorton at mindspring.com>
> > wrote:
> > > 
> > > For my PluggableListMorph, the model prepares list elements on a
> > "String new writeStream." 
> > > They are not static. I need for these list elements to be aligned
> > in columns like a small 
> > > spreadsheet. A fixed font would be handy - how can I install
> > one?
> > > 
> > > Any other approaches to get columns in a list?
> > > 
> > > - Dan
> > > 
> > > _______________________________________________
> > > 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
> 
>  - Dan
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Fri Jul 10 14:05:50 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 10 Jul 2015 15:05:50 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <1436549341.2325.3.camel@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<559FD4BD.26551.31649C@dnorton.mindspring.com>,
	<1436549341.2325.3.camel@gmail.com>
Message-ID: <55A0178E.16257.13666A4@dnorton.mindspring.com>

On 10 Jul 2015 at 13:29, Phil (list) wrote:

> On Fri, 2015-07-10 at 10:20 -0400, Dan Norton wrote:
> > On 9 Jul 2015 at 19:11, Casey Ransberger wrote:
> > 
> > > I want this too. What needs to be done is to make a
> StrikeFont,
> > > IIRC. I didn't get a round toit. If anyone has an extra round
> toit
> > > that I can borrow, I'd be very appreciative. 
> > > 
> > Thought I had one... must be around here somewhere... :(
> > 
> > > Anyway I think if you look around at the class StrikeFont,
> you'll
> > > find a trailhead or rabbit hole that you can follow toward how
> to
> > > #doIt.
> > > 
> > Browsing through strike fonts, I see no fixed widths. But, true
> type fonts have a few 
> > fixed-width examples. There seems to be no way to install a .ttf
> in Cuis currently.
> > 
> > Can we port TrueType-Support from Squeak?
> > 
> > Should there be a sibling of StrikeFont, say TrueTypeFont, which
> inherits from AbstractFont?
> > 
> > Any hints or guidance would be most welcomed.
> 
> I'd like a fixed-width font as well but I suspect that this is one
> of
> the areas it might be better to wait until Morphic 3 on (i.e. isn't
> the
> existing font support based on bitmap fonts rather than vector?)
>

Yes, the only font now is DejaVu and it's a bitmap font. I found some fixed bitmap fonts 
among the true types at:

http://www.lowing.org/fonts/

Adding a sublcass to AbstractFont to load one of these might be doable near-term until 
Morphic 3 comes along. Porting TrueType from Squeak has a lot of drag.

> > 
> > > Someone correct me if I'm wrong.
> > > 
> > > --C
> > > 
> > > > On Jul 8, 2015, at 5:03 PM, "Dan Norton"
> <dnorton at mindspring.com>
> > > wrote:
> > > > 
> > > > For my PluggableListMorph, the model prepares list elements on
> a
> > > "String new writeStream." 
> > > > They are not static. I need for these list elements to be
> aligned
> > > in columns like a small 
> > > > spreadsheet. A fixed font would be handy - how can I install
> > > one?
> > > > 
> > > > Any other approaches to get columns in a list?
> > > > 
> > > > - Dan
> > > > 
> > > > _______________________________________________
> > > > 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
> > 
> >  - Dan
> > 
> > 
> > _______________________________________________
> > 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 Ken.Dickey at whidbey.com  Fri Jul 10 03:51:44 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 10 Jul 2015 16:51:44 +0800
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A0178E.16257.13666A4@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
Message-ID: <20150710165144.ece0f54787132fed1278bdc4@whidbey.com>

On Fri, 10 Jul 2015 15:05:50 -0400
"Dan Norton" <dnorton at mindspring.com> wrote:

> Yes, the only font now is DejaVu and it's a bitmap font. I found some fixed bitmap fonts 
> among the true types at:
> 
> http://www.lowing.org/fonts/
> 
> Adding a sublcass to AbstractFont to load one of these might be doable near-term until 
> Morphic 3 comes along. Porting TrueType from Squeak has a lot of drag.

My Cuis-Smalltalk-Unicode package subclasses AbstractFont and provides fixed width characters.

See class #UniForms 

Unicode is kinda big, memory wise.  I suspect one should be able to take the ASCII subset of the Unicode glyphs and make a strike font -- or just do what I did for Unicode, but just use the ASCII subset.

FYI,
-KenD



From juan at jvuletich.org  Sat Jul 11 11:11:04 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:11:04 -0300
Subject: [Cuis] #browseVersions Key not Found
In-Reply-To: <559DB5F5.25858.20175F4@dnorton.mindspring.com>
References: <559DB5F5.25858.20175F4@dnorton.mindspring.com>
Message-ID: <55A14018.1050602@jvuletich.org>

On 7/8/2015 8:44 PM, Dan Norton wrote:
> > From a browser, the versions button works as it should.
>
> However, from a ProtocolBrowser, if the message is from a superclass a "key not found"
> error occurs.
>
> Versions of messages belonging to the class being "protocol browsed" are listed as they
> should be.
>
>   - Dan

Oh! Thanks for the report.

This turned out to be a little pandora box. Lots of broken code, unused 
/ incosistent ivars, and the like in ProtocolBrowser and 
TimeProfileBrowser. Setting all this straight is taking a little bit 
longer than expected. But I hope to do a commit with these tools working 
substantially better this weekend. I'm also removing quite a bit of code...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 11:40:28 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:40:28 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
Message-ID: <55A146FC.4020402@jvuletich.org>

Hi Folks,

It is not too hard to build new StrikeFonts. You need to build, by hand, 
files like the ones in here: 
https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zip 
and learn a bit about stuff like #installDejaVu2 . Maybe it was with 
this method and the files in this zip that built the existing instances 
of StrikeFont. Not sure.

I think DejaVu Sans Mono would be a great addition, and would look well 
to the existing DejaVu Sans.

In any case, don't be afraid, and play with the stuff. It is there so 
you can do it.

BTW, yesterday I learnt about https://github.com/tonsky/FiraCode . I 
think it is wonderful. We can't just adopt it, as we don't have 
ligatures. But maybe some time, Morphic 3 could be made to use it.

Cheers,
Juan vuletich

On 7/8/2015 9:03 PM, Dan Norton wrote:
> For my PluggableListMorph, the model prepares list elements on a "String new writeStream."
> They are not static. I need for these list elements to be aligned in columns like a small
> spreadsheet. A fixed font would be handy - how can I install one?
>
> Any other approaches to get columns in a list?
>
>   - Dan




From juan at jvuletich.org  Sat Jul 11 11:42:05 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:42:05 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <559FD4BD.26551.31649C@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
Message-ID: <55A1475D.3030501@jvuletich.org>

On 7/10/2015 11:20 AM, Dan Norton wrote:
> ...
> Browsing through strike fonts, I see no fixed widths. But, true type fonts have a few
> fixed-width examples. There seems to be no way to install a .ttf in Cuis currently.
>
> Can we port TrueType-Support from Squeak?
>
> Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits from AbstractFont?
>
> Any hints or guidance would be most welcomed.
>

I'd say, stick to StrikeFonts, and learn to build new ones. I the other 
message I just sent, I included more details.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 11:46:17 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 13:46:17 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A0178E.16257.13666A4@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<559FD4BD.26551.31649C@dnorton.mindspring.com>,
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
Message-ID: <55A14859.2080409@jvuletich.org>

On 7/10/2015 4:05 PM, Dan Norton wrote:
> ...
> Yes, the only font now is DejaVu and it's a bitmap font. I found some fixed bitmap fonts
> among the true types at:
>
> http://www.lowing.org/fonts/
>
> Adding a sublcass to AbstractFont to load one of these might be doable near-term until
> Morphic 3 comes along. Porting TrueType from Squeak has a lot of drag.
>

ProFontWindows doesn't look bad. In any case, I built the Bitmap DejaVu 
fonts in Cuis (and Squeak and Pharo) by capturing the bits from the 
screen of a text editor, running the TTF. You can do the same with 
DejaVu Sans Mono or any other TTF / OTF / whatever.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 12:27:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 14:27:01 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
Message-ID: <55A151E5.5060409@jvuletich.org>

On 7/9/2015 6:15 AM, Phil (list) wrote:
> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial position
> annoying and in some cases nearly non-functional since the Morph doesn't
> have room for its halo icons.  Just wondering if this bothers anyone
> else and if maybe insetting new morphs top left by default to something
> like 50 @ 50 (something out of the way, but giving it a bit of margin
> from the edge of the screen) might be better?

Sure. Will be there in the next commit.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Jul 11 12:29:39 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 14:29:39 -0300
Subject: [Cuis] MorphIt -- toward direct authoring with media
In-Reply-To: <A420D093-D868-490D-AC79-3DDED1561178@gmail.com>
References: <20150707060418.faf01ed1f10d8e7b252fefc2@whidbey.com>
	<A420D093-D868-490D-AC79-3DDED1561178@gmail.com>
Message-ID: <55A15283.8050104@jvuletich.org>

Hi Folks,

I agree with you. I think it will be great to make Cuis good at that! 
(While keeping the cleanness of the code and the design, of course).

Cheers,
Juan Vuletich

On 7/9/2015 11:05 PM, Casey Ransberger wrote:
> Hey Ken,
>
> Woot! I was working on something that did this but got distracted by a shiny robot before it got close to working.
>
> I've wanted to see Self-style authoring in Cuis ever since I realized that I liked working with Cuis better than the other distributions. It was the one thing I really enjoyed in Squeak that we're really missing in Cuisland.
>
> If we can throw in some HyperCard and... what is that thing from Self? Little tool to zero in on a Morph and then inspect it? Anyway, that thing. Would be just amazingly awesome.
>
> --C
>
>> On Jul 7, 2015, at 6:04 AM, "Ken.Dickey"<Ken.Dickey at whidbey.com>  wrote:
>>
>> Greetings all,
>>
>> I have put some pre-Alpha proof-of-concept code in BabySteps
>>
>>     https://github.com/KenDickey/Cuis-Smalltalk-BabySteps
>>
>> The package is called MorphIt, the gist being drag-n-drop prototype style modification of Morphs with a general goal of multimedia style UI authoring.  Think Myst/Obsidian/Physicus/Syberia/..
>>
>> As some of you may know, my style is to have a bunch of half baked ideas roiling around in my head which I tend to think through by writing code.
>>
>> Very early days yet, but anyone with time on their hands can see what works and what doesn't.  The README.md has some notes on directions.
>>
>> Cheers,
>> -KenD




From juan at jvuletich.org  Sat Jul 11 12:31:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 11 Jul 2015 14:31:27 -0300
Subject: [Cuis] Loop during StrikeFont install:
In-Reply-To: <559C06CD.15379.DC94F3@dnorton.mindspring.com>
References: <559C06CD.15379.DC94F3@dnorton.mindspring.com>
Message-ID: <55A152EF.1030801@jvuletich.org>

Hi Dan,

It looks like you'll be playing a bit with building a good monospaced 
font, right? While you are at it, please send to the mail list any fixes 
you'll for sure be doing in this area...

Thanks,
Juan Vuletich

On 7/7/2015 2:05 PM, Dan Norton wrote:
> To cause this loop:
>
> In directory "Cuis-Smalltalk-Dev-master" have no "AAFonts" directory.
> Do (cmd-d) StrikeFont install: 'Optima'
> Get a loop instead of "File does not exist" exception.
>
>   - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From edgardec2005 at gmail.com  Sat Jul 11 15:24:20 2015
From: edgardec2005 at gmail.com (Edgar J De Cleene)
Date: Sat, 11 Jul 2015 17:24:20 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <55A146FC.4020402@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
Message-ID: <6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>

Quoting Casey

> If we can throw in some HyperCard and... 

A long time algo wish Squeak could read HyperCard stacks.
If Cuis could do this , bet we have thousands users.
Anyway whats the HyperCard status ?
 
Env?ado desde Edgar's iPad mini



> El 11/7/2015, a las 13:40, Juan Vuletich <juan at jvuletich.org> escribi?:
> 
> Hi Folks,
> 
> It is not too hard to build new StrikeFonts. You need to build, by hand, files like the ones in here: https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zip and learn a bit about stuff like #installDejaVu2 . Maybe it was with this method and the files in this zip that built the existing instances of StrikeFont. Not sure.
> 
> I think DejaVu Sans Mono would be a great addition, and would look well to the existing DejaVu Sans.
> 
> In any case, don't be afraid, and play with the stuff. It is there so you can do it.
> 
> BTW, yesterday I learnt about https://github.com/tonsky/FiraCode . I think it is wonderful. We can't just adopt it, as we don't have ligatures. But maybe some time, Morphic 3 could be made to use it.
> 
> Cheers,
> Juan vuletich
> 
>> On 7/8/2015 9:03 PM, Dan Norton wrote:
>> For my PluggableListMorph, the model prepares list elements on a "String new writeStream."
>> They are not static. I need for these list elements to be aligned in columns like a small
>> spreadsheet. A fixed font would be handy - how can I install one?
>> 
>> Any other approaches to get columns in a list?
>> 
>>  - 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/20150711/224e60c8/attachment-0004.html>

From edgardec2005 at gmail.com  Sun Jul 12 04:21:11 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sun, 12 Jul 2015 06:21:11 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436433337.2325.6.camel@gmail.com>
Message-ID: <D1C7B7D7.159F8%edgardec2005@gmail.com>




On 7/9/15, 6:15 AM, "Phil (list)" <pbpublist at gmail.com> wrote:

> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial position
> annoying and in some cases nearly non-functional since the Morph doesn't
> have room for its halo icons.  Just wondering if this bothers anyone
> else and if maybe insetting new morphs top left by default to something
> like 50 @ 50 (something out of the way, but giving it a bit of margin
> from the edge of the screen) might be better?


Morph new openInHand could be better?

Edgar





From pbpublist at gmail.com  Sun Jul 12 12:16:15 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 12 Jul 2015 13:16:15 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <D1C7B7D7.159F8%edgardec2005@gmail.com>
References: <D1C7B7D7.159F8%edgardec2005@gmail.com>
Message-ID: <1436721375.2314.3.camel@gmail.com>

Edgar,


On Sun, 2015-07-12 at 06:21 -0300, Edgar J. De Cleene wrote:
> 
> 
> On 7/9/15, 6:15 AM, "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > This is a minor nit but when I'm developing Morphs I often need to
> > instantiate them manually via something like 'MorphName new
> > openInWorld.'  When I do that, I almost always find its initial position
> > annoying and in some cases nearly non-functional since the Morph doesn't
> > have room for its halo icons.  Just wondering if this bothers anyone
> > else and if maybe insetting new morphs top left by default to something
> > like 50 @ 50 (something out of the way, but giving it a bit of margin
> > from the edge of the screen) might be better?
> 
> 
> Morph new openInHand could be better?
> 

I find that's not always an option in the early stages of working on a
Morph as there are often initialization dependencies that I haven't
worked out at that stage causing openInHand not to work.  Once I have
everything working, then I go back and figure out what needs to happen
to get it running with openInHand...


> Edgar
> 
> 
> 
Thanks,
Phil




From edgardec2005 at gmail.com  Sun Jul 12 13:21:03 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sun, 12 Jul 2015 15:21:03 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436721375.2314.3.camel@gmail.com>
Message-ID: <D1C8365F.15A07%edgardec2005@gmail.com>




On 7/12/15, 2:16 PM, "Phil (list)" <pbpublist at gmail.com> wrote:

> I find that's not always an option in the early stages of working on a
> Morph as there are often initialization dependencies that I haven't
> worked out at that stage causing openInHand not to work.  Once I have
> everything working, then I go back and figure out what needs to happen
> to get it running with openInHand...

Ok.
Could share yours code not working with openInHand ?

Edgar





From pbpublist at gmail.com  Sun Jul 12 15:23:37 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 12 Jul 2015 16:23:37 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <D1C8365F.15A07%edgardec2005@gmail.com>
References: <D1C8365F.15A07%edgardec2005@gmail.com>
Message-ID: <1436732617.2314.17.camel@gmail.com>

On Sun, 2015-07-12 at 15:21 -0300, Edgar J. De Cleene wrote:
> 
> 
> On 7/12/15, 2:16 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > I find that's not always an option in the early stages of working on a
> > Morph as there are often initialization dependencies that I haven't
> > worked out at that stage causing openInHand not to work.  Once I have
> > everything working, then I go back and figure out what needs to happen
> > to get it running with openInHand...
> 
> Ok.
> Could share yours code not working with openInHand ?
> 

I think a recent example was the Dan's BouncingAtomsMorph which could
not be invoked from the New Morph... menu until I submitted a fix.  It
was an easy fix and I run into this problem quite often in the early
stages of Morph development.  openInHand calls doOneCycleNow (or maybe
it's doOneCycle... I forget which) which results in the Morph needing to
draw earlier than with openInWorld.  This is a problem if the Morph
isn't fully initialized and ready to be drawn yet.  It's not a big deal,
just part of how I develop Morphs and why I use openInWorld until I get
things sorted out.  Also, when I'm developing a Morph I'm usually
invoking it from a workspace or code browser and don't want to be
dealing with it interactively yet since it usually isn't fully
functional anyway.

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





From edgardec2005 at gmail.com  Sun Jul 12 16:02:31 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Sun, 12 Jul 2015 18:02:31 -0300
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436732617.2314.17.camel@gmail.com>
Message-ID: <D1C85C37.15A14%edgardec2005@gmail.com>




On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:

> I think a recent example was the Dan's BouncingAtomsMorph which could
> not be invoked from the New Morph... menu until I submitted a fix.  It
> was an easy fix and I run into this problem quite often in the early
> stages of Morph development.  openInHand calls doOneCycleNow (or maybe
> it's doOneCycle... I forget which) which results in the Morph needing to
> draw earlier than with openInWorld.  This is a problem if the Morph
> isn't fully initialized and ready to be drawn yet.  It's not a big deal,
> just part of how I develop Morphs and why I use openInWorld until I get
> things sorted out.  Also, when I'm developing a Morph I'm usually
> invoking it from a workspace or code browser and don't want to be
> dealing with it interactively yet since it usually isn't fully
> functional anyway.

Very instructive.
Thanks a lot.

Edgar





From dnorton at mindspring.com  Sun Jul 12 21:20:55 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 12 Jul 2015 22:20:55 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <D1C85C37.15A14%edgardec2005@gmail.com>
References: <1436732617.2314.17.camel@gmail.com>,
	<D1C85C37.15A14%edgardec2005@gmail.com>
Message-ID: <55A32087.26820.2A728B2@dnorton.mindspring.com>

On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:

> 
> 
> 
> On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > I think a recent example was the Dan's BouncingAtomsMorph which
> could
> > not be invoked from the New Morph... menu until I submitted a fix.
> It
> > was an easy fix and I run into this problem quite often in the
> early
> > stages of Morph development.  openInHand calls doOneCycleNow (or
> maybe
> > it's doOneCycle... I forget which) which results in the Morph
> needing to
> > draw earlier than with openInWorld.  This is a problem if the
> Morph
> > isn't fully initialized and ready to be drawn yet.  It's not a big
> deal,
> > just part of how I develop Morphs and why I use openInWorld until
> I get
> > things sorted out.  Also, when I'm developing a Morph I'm
> usually
> > invoking it from a workspace or code browser and don't want to
> be
> > dealing with it interactively yet since it usually isn't fully
> > functional anyway.
> 
> Very instructive.
> Thanks a lot.
> 
> Edgar
>

Yes, thank you Phil for the fix. I needed to learn that. I put the history of the change on:

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

The commit is "343a986"  "starts from new morph menu"

 - Dan




From pbpublist at gmail.com  Sun Jul 12 23:41:03 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 13 Jul 2015 00:41:03 -0400
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <55A32087.26820.2A728B2@dnorton.mindspring.com>
References: <1436732617.2314.17.camel@gmail.com>
	, <D1C85C37.15A14%edgardec2005@gmail.com>
	<55A32087.26820.2A728B2@dnorton.mindspring.com>
Message-ID: <1436762463.2314.19.camel@gmail.com>

On Sun, 2015-07-12 at 22:20 -0400, Dan Norton wrote:
> On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:
> 
> > 
> > 
> > 
> > On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
> > 
> > > I think a recent example was the Dan's BouncingAtomsMorph which
> > could
> > > not be invoked from the New Morph... menu until I submitted a fix.
> > It
> > > was an easy fix and I run into this problem quite often in the
> > early
> > > stages of Morph development.  openInHand calls doOneCycleNow (or
> > maybe
> > > it's doOneCycle... I forget which) which results in the Morph
> > needing to
> > > draw earlier than with openInWorld.  This is a problem if the
> > Morph
> > > isn't fully initialized and ready to be drawn yet.  It's not a big
> > deal,
> > > just part of how I develop Morphs and why I use openInWorld until
> > I get
> > > things sorted out.  Also, when I'm developing a Morph I'm
> > usually
> > > invoking it from a workspace or code browser and don't want to
> > be
> > > dealing with it interactively yet since it usually isn't fully
> > > functional anyway.
> > 
> > Very instructive.
> > Thanks a lot.
> > 
> > Edgar
> >
> 
> Yes, thank you Phil for the fix. I needed to learn that. I put the history of the change on:
> 

Glad to chip in... thank you for giving us a nice Morphic demo!

> https://github.com/dhnorton/Cuis-Smalltalk-atoms
> 
> The commit is "343a986"  "starts from new morph menu"
> 

There it is  (I was too tired/lazy to dig up the commit reference :-)

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





From hannes.hirzel at gmail.com  Mon Jul 13 00:39:23 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 13 Jul 2015 05:39:23 +0000
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <1436762463.2314.19.camel@gmail.com>
References: <1436732617.2314.17.camel@gmail.com>
	<D1C85C37.15A14%edgardec2005@gmail.com>
	<55A32087.26820.2A728B2@dnorton.mindspring.com>
	<1436762463.2314.19.camel@gmail.com>
Message-ID: <CAGQxfVjPO7Q+BS=N4HEcsKtb_4g4+RmVLvZeM_KDEWPe4+61Tg@mail.gmail.com>

You mean this one

https://github.com/dhnorton/Cuis-Smalltalk-atoms/commit/343a986a8f4bdfb4bee8eb05797e4d75b881ecbe

?

--Hannes

On 7/13/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Sun, 2015-07-12 at 22:20 -0400, Dan Norton wrote:
>> On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:
>>
>> >
>> >
>> >
>> > On 7/12/15, 5:23 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
>> >
>> > > I think a recent example was the Dan's BouncingAtomsMorph which
>> > could
>> > > not be invoked from the New Morph... menu until I submitted a fix.
>> > It
>> > > was an easy fix and I run into this problem quite often in the
>> > early
>> > > stages of Morph development.  openInHand calls doOneCycleNow (or
>> > maybe
>> > > it's doOneCycle... I forget which) which results in the Morph
>> > needing to
>> > > draw earlier than with openInWorld.  This is a problem if the
>> > Morph
>> > > isn't fully initialized and ready to be drawn yet.  It's not a big
>> > deal,
>> > > just part of how I develop Morphs and why I use openInWorld until
>> > I get
>> > > things sorted out.  Also, when I'm developing a Morph I'm
>> > usually
>> > > invoking it from a workspace or code browser and don't want to
>> > be
>> > > dealing with it interactively yet since it usually isn't fully
>> > > functional anyway.
>> >
>> > Very instructive.
>> > Thanks a lot.
>> >
>> > Edgar
>> >
>>
>> Yes, thank you Phil for the fix. I needed to learn that. I put the history
>> of the change on:
>>
>
> Glad to chip in... thank you for giving us a nice Morphic demo!
>
>> https://github.com/dhnorton/Cuis-Smalltalk-atoms
>>
>> The commit is "343a986"  "starts from new morph menu"
>>
>
> There it is  (I was too tired/lazy to dig up the commit reference :-)
>
>>  - Dan
>>
>>
>> _______________________________________________
>> 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 dnorton at mindspring.com  Mon Jul 13 09:23:44 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 13 Jul 2015 07:23:44 -0700 (PDT)
Subject: [Cuis] Default Morph position something other than 0 @ 0?
In-Reply-To: <CAGQxfVjPO7Q+BS=N4HEcsKtb_4g4+RmVLvZeM_KDEWPe4+61Tg@mail.gmail.com>
References: <1436433337.2325.6.camel@gmail.com>
	<D1C7B7D7.159F8%edgardec2005@gmail.com>
	<1436721375.2314.3.camel@gmail.com>
	<D1C8365F.15A07%edgardec2005@gmail.com>
	<1436732617.2314.17.camel@gmail.com>
	<D1C85C37.15A14%edgardec2005@gmail.com>
	<55A32087.26820.2A728B2@dnorton.mindspring.com>
	<1436762463.2314.19.camel@gmail.com>
	<CAGQxfVjPO7Q+BS=N4HEcsKtb_4g4+RmVLvZeM_KDEWPe4+61Tg@mail.gmail.com>
Message-ID: <1436797424888-4837347.post@n4.nabble.com>

Yes, it seems there are several ways to see the commit :-)

GitHub newbie here,

 - Dan



--
View this message in context: http://forum.world.st/Default-Morph-position-something-other-than-0-0-tp4836757p4837347.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From dnorton at mindspring.com  Wed Jul 15 10:54:49 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 15 Jul 2015 11:54:49 -0400
Subject: [Cuis] Array2D newSize:
Message-ID: <55A68249.17883.775BA8@dnorton.mindspring.com>

Maybe it's my dyslexia, but isn't this backward?

"Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
| nil nil |
| nil nil |
| nil nil |

IMO it should be:
| nil nil nil |
| nil nil nil |

For example, in Squeak, "MatrixTransform2x3 identity" produces: MatrixTransform2x3(
1.0	0.0	0.0
0.0	1.0	0.0
)

Please correct me if I'm wrong.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150715/e16d96a2/attachment-0004.html>

From dnorton at mindspring.com  Wed Jul 15 17:23:26 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 15 Jul 2015 15:23:26 -0700 (PDT)
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A68249.17883.775BA8@dnorton.mindspring.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
Message-ID: <1436999006167-4837720.post@n4.nabble.com>


Maybe it's my dyslexia, but isn't this backward?

"Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
| nil nil |
| nil nil |
| nil nil |

IMO it should be:
| nil nil nil |
| nil nil nil |

For example, in Squeak, "MatrixTransform2x3 identity" produces:
MatrixTransform2x3(
1.0	0.0	0.0
0.0	1.0	0.0
)

Please correct me if I'm wrong.

OK, you're wrong - as long as there is a subclass called Matrix in

LinearAlgebra.pck.st

Use Matrix instead of Array2d.

(whew)




--
View this message in context: http://forum.world.st/Array2D-newSize-tp4837696p4837720.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From pbpublist at gmail.com  Wed Jul 15 18:43:12 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 15 Jul 2015 19:43:12 -0400
Subject: [Cuis] Preventing pretty print from replacing := with _?
Message-ID: <1437003792.2401.2.camel@gmail.com>

Is there a setting that will disable this substitution?  I would
actually prefer it to go the other way: if it sees an _ assignment,
replace it with :=

Thanks,
Phil




From pbpublist at gmail.com  Wed Jul 15 19:49:57 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 15 Jul 2015 20:49:57 -0400
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1436999006167-4837720.post@n4.nabble.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
Message-ID: <1437007797.2401.12.camel@gmail.com>

On Wed, 2015-07-15 at 15:23 -0700, Dan Norton wrote:
> Maybe it's my dyslexia, but isn't this backward?
> 
> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
> | nil nil |
> | nil nil |
> | nil nil |
> 
> IMO it should be:
> | nil nil nil |
> | nil nil nil |
> 
> For example, in Squeak, "MatrixTransform2x3 identity" produces:
> MatrixTransform2x3(
> 1.0	0.0	0.0
> 0.0	1.0	0.0
> )
> 
> Please correct me if I'm wrong.
> 
> OK, you're wrong - as long as there is a subclass called Matrix in
> 
> LinearAlgebra.pck.st
> 
> Use Matrix instead of Array2d.
> 

Glad that solved your problem but, ouch... that class is uncomfortably
close in name and function to the 3DTransform package I'm using for
OpenGL.  Juan: would you be open to using an extended version of my
classes so that we don't run into namespace conflicts?

One advantage that the Matrix* and Vector* classes I'm using have is
that they are mapped to native types which makes for transparent and
easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
compute shaders and you have the fastest matrix math you've ever seen,
assuming you've got medium or larger sets of data)

> (whew)
> 
> 
> 
> 
> --
> View this message in context: http://forum.world.st/Array2D-newSize-tp4837696p4837720.html
> Sent from the Cuis Smalltalk mailing list archive at Nabble.com.
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Thu Jul 16 07:43:13 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 09:43:13 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
Message-ID: <55A7A6E1.8000909@jvuletich.org>

Hi Edgar,

Is there such a project? Any reference?

Thanks,
Juan Vuletich

On 7/11/2015 5:24 PM, Edgar J De Cleene wrote:
> Quoting Casey
>
>> If we can throw in some HyperCard and... 
>
> A long time algo wish Squeak could read HyperCard stacks.
> If Cuis could do this , bet we have thousands users.
> Anyway whats the HyperCard status ?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150716/c2dd8b85/attachment-0004.html>

From hannes.hirzel at gmail.com  Thu Jul 16 08:00:03 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 13:00:03 +0000
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <55A7A6E1.8000909@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
Message-ID: <CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>

 I think there was something like that. Need to search in the Squeak
list. And check the porting effort. Might be doable with Cuis these
days.

--Hannes

On 7/16/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Edgar,
>
> Is there such a project? Any reference?
>
> Thanks,
> Juan Vuletich
>
> On 7/11/2015 5:24 PM, Edgar J De Cleene wrote:
>> Quoting Casey
>>
>>> If we can throw in some HyperCard and...
>>
>> A long time algo wish Squeak could read HyperCard stacks.
>> If Cuis could do this , bet we have thousands users.
>> Anyway whats the HyperCard status ?
>>
>
>



From juan at jvuletich.org  Thu Jul 16 08:01:12 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:01:12 -0300
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <1437003792.2401.2.camel@gmail.com>
References: <1437003792.2401.2.camel@gmail.com>
Message-ID: <55A7AB18.5020601@jvuletich.org>

On 7/15/2015 8:43 PM, Phil (list) wrote:
> Is there a setting that will disable this substitution?  I would
> actually prefer it to go the other way: if it sees an _ assignment,
> replace it with :=
>
> Thanks,
> Phil

Please check #syntaxHighlightingAsYouTypeAnsiAssignment and 
#syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.

Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough 
for you?

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Thu Jul 16 08:10:02 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 13:10:02 +0000
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <55A7AB18.5020601@jvuletich.org>
References: <1437003792.2401.2.camel@gmail.com>
	<55A7AB18.5020601@jvuletich.org>
Message-ID: <CAGQxfVhV09RLrLsEsBaRKXERznoP-p+Zdxj4dOF5CnjNFtgH4Q@mail.gmail.com>

I just added an issue for this

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/67

(for Documentation which I'd like to do later, there are more of
issues like this)

Please update the issue when the answer is known.

--Hannes

On 7/16/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/15/2015 8:43 PM, Phil (list) wrote:
>> Is there a setting that will disable this substitution?  I would
>> actually prefer it to go the other way: if it sees an _ assignment,
>> replace it with :=
>>
>> Thanks,
>> Phil
>
> Please check #syntaxHighlightingAsYouTypeAnsiAssignment and
> #syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.
>
> Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough
> for you?
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Thu Jul 16 08:14:17 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:14:17 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A68249.17883.775BA8@dnorton.mindspring.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
Message-ID: <55A7AE29.3010706@jvuletich.org>

Hi Dan,

On 7/15/2015 12:54 PM, Dan Norton wrote:
> Maybe it's my dyslexia, but isn't this backward?

It is not you. It is the unfortunate fact that 2 conventions exist for this

> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
> | nil nil |
> | nil nil |
> | nil nil |

Yes. 2 at 3 is a point with x=2 and y=3. x is usually regarded as the 
horizontal coordinate and y as the vertical coordinate. This is the 
universal convention for pixels in Displays and Forms and for 
mathematical points in the Cartesian plane.

> IMO it should be:
> | nil nil nil |
> | nil nil nil |

Yes. That's why Array2D class also has #height:width: and #width:height. 
Matrices are usually accessed with i, j; where i is the row and j the 
column. Array2D instances have #x:y: and #i:j: , and the order of the 
arguments is swapped. So you can pick the convention that bests suits 
what you are doing.

> For example, in Squeak, "MatrixTransform2x3 identity" produces: 
> MatrixTransform2x3(
> 1.0       0.0       0.0
> 0.0       1.0       0.0
> )

Yes. It uses the matrix convention.

> Please correct me if I'm wrong.
>
>  - Dan
>

  HTH.

In addition to all this Matrices have origin (1,1), while the 
mathematical plane and Forms have origin (0,0). But Matrices and Forms 
have the origin at the topLeft, while the mathematical plane has the 
origin at the bottomLeft (or at the center if you allow negative 
coordinates).

To make things even more complicated, when mapping the mathematical 
plane to a Form, you can map integer numbers in the plane to the center 
of the pixels (the convention that makes most sense to me) or to pixel 
corners (as Squeak / Cuis Rectangles do).

All unnecesary complications, but that we can't avoid.

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

From juan at jvuletich.org  Thu Jul 16 08:16:54 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:16:54 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1436999006167-4837720.post@n4.nabble.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
Message-ID: <55A7AEC6.9090908@jvuletich.org>

On 7/15/2015 7:23 PM, Dan Norton wrote:
> Maybe it's my dyslexia, but isn't this backward?
>
> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
> | nil nil |
> | nil nil |
> | nil nil |
>
> IMO it should be:
> | nil nil nil |
> | nil nil nil |
>
> For example, in Squeak, "MatrixTransform2x3 identity" produces:
> MatrixTransform2x3(
> 1.0	0.0	0.0
> 0.0	1.0	0.0
> )
>
> Please correct me if I'm wrong.
>
> OK, you're wrong - as long as there is a subclass called Matrix in
>
> LinearAlgebra.pck.st
>
> Use Matrix instead of Array2d.
>
> (whew)

No, you are not wrong.

But use Matrix, or maybe FloatMatrix if it makes sense for you.

Also keep in mind that Cuis has AffineTransformation, that is almost 
identical to Squeak's MatrixTransform2x3 (except for Squeak's doing some 
very arguable rounding to integer of results).

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 16 08:23:35 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 16 Jul 2015 10:23:35 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1437007797.2401.12.camel@gmail.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>	<1436999006167-4837720.post@n4.nabble.com>
	<1437007797.2401.12.camel@gmail.com>
Message-ID: <55A7B057.4050803@jvuletich.org>

Hi Phil,

On 7/15/2015 9:49 PM, Phil (list) wrote:
> Glad that solved your problem but, ouch... that class is uncomfortably
> close in name and function to the 3DTransform package I'm using for
> OpenGL.  Juan: would you be open to using an extended version of my
> classes so that we don't run into namespace conflicts?

Indeed we need to do something with this. Check the "Math 3D" package. 
It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need 
double precision for satellite image processing at work.

There is a lot of overlap with yours, but you are using 32 bit Floats.

> One advantage that the Matrix* and Vector* classes I'm using have is
> that they are mapped to native types which makes for transparent and
> easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
> compute shaders and you have the fastest matrix math you've ever seen,
> assuming you've got medium or larger sets of data)

Yes. This is indeed great. We need to build a single, uniform package 
with this stuff, that handles both 32 and 64 bit Floats and can take 
advantage of GPUs.

BTW, have you used OpenCL from Cuis? I'll be needing to work with that 
in a few months.

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Thu Jul 16 08:28:07 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 13:28:07 +0000
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A7AEC6.9090908@jvuletich.org>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
	<55A7AEC6.9090908@jvuletich.org>
Message-ID: <CAGQxfVjFGwyjhX_tJkFx3F8WtBnbuDA1huqcQ=fJwG-M5+4bjQ@mail.gmail.com>

Created an issue for me to sometime later this year add to the documentation

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/68

--Hannes

On 7/16/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/15/2015 7:23 PM, Dan Norton wrote:
>> Maybe it's my dyslexia, but isn't this backward?
>>
>> "Array2D newSize: 2 at 3" produces an array with 3 rows and 2 columns:
>> | nil nil |
>> | nil nil |
>> | nil nil |
>>
>> IMO it should be:
>> | nil nil nil |
>> | nil nil nil |
>>
>> For example, in Squeak, "MatrixTransform2x3 identity" produces:
>> MatrixTransform2x3(
>> 1.0	0.0	0.0
>> 0.0	1.0	0.0
>> )
>>
>> Please correct me if I'm wrong.
>>
>> OK, you're wrong - as long as there is a subclass called Matrix in
>>
>> LinearAlgebra.pck.st
>>
>> Use Matrix instead of Array2d.
>>
>> (whew)
>
> No, you are not wrong.
>
> But use Matrix, or maybe FloatMatrix if it makes sense for you.
>
> Also keep in mind that Cuis has AffineTransformation, that is almost
> identical to Squeak's MatrixTransform2x3 (except for Squeak's doing some
> very arguable rounding to integer of results).
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Thu Jul 16 09:49:52 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 14:49:52 +0000
Subject: [Cuis] Time stamp of source code change of a method?
Message-ID: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>

Hello

I'd like to do a query finding out about the time stamp of  source
code changes of all methods in the Cuis image and then do a list with
the following four columns


ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName, DateOfChange

Help is appreciated.

Hannes



From hannes.hirzel at gmail.com  Thu Jul 16 09:51:58 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 16 Jul 2015 14:51:58 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
Message-ID: <CAGQxfVgdYn2s2A2e54SYhh8se8tJfv1QwHOw7u6fVkTFrrt8jA@mail.gmail.com>

P.S. I'd like to do this on a Cuis image of January 1st and then on a
Cuis image 30th June 2015.

And then do a bar chart


Package
NumberOfMethodsChanged

On 7/16/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Hello
>
> I'd like to do a query finding out about the time stamp of  source
> code changes of all methods in the Cuis image and then do a list with
> the following four columns
>
>
> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName, DateOfChange
>
> Help is appreciated.
>
> Hannes
>



From pbpublist at gmail.com  Thu Jul 16 13:36:29 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 16 Jul 2015 14:36:29 -0400
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <55A7AB18.5020601@jvuletich.org>
References: <1437003792.2401.2.camel@gmail.com>
	<55A7AB18.5020601@jvuletich.org>
Message-ID: <1437071789.2255.28.camel@gmail.com>

Juan,

On Thu, 2015-07-16 at 10:01 -0300, Juan Vuletich wrote:
> On 7/15/2015 8:43 PM, Phil (list) wrote:
> > Is there a setting that will disable this substitution?  I would
> > actually prefer it to go the other way: if it sees an _ assignment,
> > replace it with :=
> >
> > Thanks,
> > Phil
> 
> Please check #syntaxHighlightingAsYouTypeAnsiAssignment and 
> #syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.
> 
> Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough 
> for you?
> 

I'm already setting #syntaxHighlightingAsYouTypeAnsiAssignment to true
and leaving #syntaxHighlightingAsYouTypeLeftArrowAssignment at false.
That seems to work for everything except pretty printing.  I also played
with #allowUnderscoreAssignments but that just determines whether or not
_ is valid and doesn't stop pretty print trying to use underscores
anyway (which is entertaining because then pp produces invalid code :-)

> Cheers,
> Juan Vuletich

Thanks,
Phil




From pbpublist at gmail.com  Thu Jul 16 15:13:48 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 16 Jul 2015 16:13:48 -0400
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A7B057.4050803@jvuletich.org>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
	<1437007797.2401.12.camel@gmail.com> <55A7B057.4050803@jvuletich.org>
Message-ID: <1437077628.2255.77.camel@gmail.com>

Juan,

On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 7/15/2015 9:49 PM, Phil (list) wrote:
> > Glad that solved your problem but, ouch... that class is uncomfortably
> > close in name and function to the 3DTransform package I'm using for
> > OpenGL.  Juan: would you be open to using an extended version of my
> > classes so that we don't run into namespace conflicts?
> 
> Indeed we need to do something with this. Check the "Math 3D" package. 
> It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need 
> double precision for satellite image processing at work.
> 

You space guys with your astronomically large numbers and being sooooo
concerned with precisely where things are.  Why can't you accept
'there-ish' like the rest of us? :-)

(disclaimer: the events depicted in Gravity should in no way cast
aspersions as to the inadequacies of 32-bit floats...)

Ahh... hadn't noticed the Math 3D stuff before.  For OpenGL, I've been
using a combination of the Collections-Arrayed, Collections-Balloon and
3DTransform (i.e. the 3DTransform package which provides the Vector* and
Matrix* classes, which came from Croquet, or whatever upstream source
they pulled from)

The Float64* class hierarchy in Math 3D appears to just be a parallel
64-bit hierarchy (with some slight naming convention differences) to the
32-bit Vector* and Matrix* classes from 3DTransform.  So what we'd
probably want to do there is merge them (i.e. keeping both the 64-bit
and 32-versions... when you need one or the other, you absolutely need
it) into a single package and make sure they have identical
functionality and consistent naming conventions (I have no preference on
which conventions we use other than that they be consistent.  Makes no
difference to me whether I'm using Vector2 or Float32Vector2 or whatever
else would make sense)  If we did that, this would just leave the
question of how the LinearAlgebra and Array2D classes fit into this (one
thing I don't currently have but would like is an arbitrary MxN 32-bit
float matrix class)...

At first glance, the naming convention mapping appears to be:

Float64Color4 -> VectorColor
Float64Matrix4x4 -> Matrix4x4
Float64Rotation -> Quaternion
Float64Vector2 -> Vector2
Float64Vector3 -> Vector3
Float64Vector4 -> Vector4

With the balances of the classes being unique to 3DTransform. (Just
curious: for Float64Vector* why don't you use a common base class
similar to Vector?)

> There is a lot of overlap with yours, but you are using 32 bit Floats.
> 

For now... at some point I'm sure I'll be needing 64-bit Floats as well.
Since both the VM and OpenGL are limited to 32-bits, that's been doing
the job for me. (my priority is currently performance over precision
since for me it's just an errant pixel, for you it might be a house or
your satellite heading for the ISS...)

> > One advantage that the Matrix* and Vector* classes I'm using have is
> > that they are mapped to native types which makes for transparent and
> > easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
> > compute shaders and you have the fastest matrix math you've ever seen,
> > assuming you've got medium or larger sets of data)
> 
> Yes. This is indeed great. We need to build a single, uniform package 
> with this stuff, that handles both 32 and 64 bit Floats and can take 
> advantage of GPUs.
> 
> BTW, have you used OpenCL from Cuis? I'll be needing to work with that 
> in a few months.
> 

Not yet, but pretty much all of the same issues I've run into with
OpenGL would apply for OpenCL (i.e. it's all FFI as far as the VM is
concerned unless you're going to create a plugin, but even then you
still have the same issues) so I think we should be able to get to a
unified vector/matrix structure that works for both of us.  In both
cases the key is to minimize the amount of work done to marshal native
data in and out (slow/expensive conversions have a dramatic and
detrimental cost for small data sets / short computations) while keeping
the data as easy to work with as possible in both the Smalltalk and FFI
(whether OpenGL/OpenCL/CUDA/Metal/Vulcan/etc.) environments.

Something to keep in the back of your mind: OMeta.  One of the many
reasons I get so geeked out about it is that an OpenGL shader is just
another language that can be targeted via source-to-source translation
(i.e. dynamically generated GPU code written in something similar to
Slang or another DSL from Cuis).  OpenCL shouldn't be terribly
different...

> Cheers,
> Juan Vuletich

Thanks,
Phil




From dnorton at mindspring.com  Thu Jul 16 20:43:22 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 16 Jul 2015 21:43:22 -0400
Subject: [Cuis] Block Arguments
Message-ID: <55A85DBA.15429.29625A6@dnorton.mindspring.com>

Hi Juan,

On windows, when the attached class method is added to StrikeFont and cmd-d is done on 
the comment, it produces:

'Error: This block accepts 0 arguments, but was called with 1 argument.'

AFAIKT it is not passing any arguments and the files do exist. Maybe a bug?

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150716/ea2323c1/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StrikeFont class-createTrueTypebolditalicboldItalic.zip
Type: application/zip
Size: 624 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150716/ea2323c1/attachment-0004.zip>

From pbpublist at gmail.com  Thu Jul 16 21:11:45 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 16 Jul 2015 22:11:45 -0400
Subject: [Cuis] Block Arguments
In-Reply-To: <55A85DBA.15429.29625A6@dnorton.mindspring.com>
References: <55A85DBA.15429.29625A6@dnorton.mindspring.com>
Message-ID: <1437099105.2255.92.camel@gmail.com>

On Thu, 2015-07-16 at 21:43 -0400, Dan Norton wrote:
> Hi Juan,
> 
> 
> On windows, when the attached class method is added to StrikeFont and
> cmd-d is done on the comment, it produces:
> 
> 
> 'Error: This block accepts 0 arguments, but was called with 1
> argument.'
> 
> 
> AFAIKT it is not passing any arguments and the files do exist. Maybe a
> bug?
> 
But it is passing an argument to your ifExistsDo: block (the filestream)
and your block doesn't accept any.  If you don't care about the
filestream, change your blocks to [:filestream| {baseName. ' OK'} print]
etc. and ignore the parameter.

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





From juan at jvuletich.org  Fri Jul 17 08:03:16 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:03:16 -0300
Subject: [Cuis] DIRECT version number
In-Reply-To: <CAGQxfVg4pDR8sL9ezpcvtH3DFQuG7Si=wiG=mh+daW0seUTO8g@mail.gmail.com>
References: <CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA@mail.gmail.com>	<55A7A607.7050304@jvuletich.org>	<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A@mail.gmail.com>	<55A7B5DA.1020103@jvuletich.org>	<CAGQxfVg7ZLtdkz211LwJPe6uFxSUBMvgeJhafD+ZSxixSMo6tA@mail.gmail.com>
	<CAGQxfVg4pDR8sL9ezpcvtH3DFQuG7Si=wiG=mh+daW0seUTO8g@mail.gmail.com>
Message-ID: <55A8FD14.8060502@jvuletich.org>

(cc the mail list)

Yes, we could do it. I kinda stopped doing "releases" because with a 
constantly updating GitHub repo, each commit can be considered a "release".

So, the question is,
What is a release? How is it different from a GitHub commit?
What is the value of a release?

Maybe it is just about following a tradition (from the time of diskettes 
and CD Rom). Or maybe it is about crating echos in other places (tweets, 
blogs, etc)...

What do others think?

Cheers,
Juan Vuletich

On 7/16/2015 4:36 PM, H. Hirzel wrote:
> What I mean is this
>
> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
>
> New in Cuis 4.2 (released July 25, 2013)
>
>      Packages now have dependencies
>
>      Package loading greatly enhanced
>
>      Moved non-essential stuff to optional packages. Cuis is now below
> 500 classes and 100kLOC. Reduction was about 25%
>
>      Many bugfixes, and minor enhancements and cleanup
>
>
> NO RELEASE SINCE since July 2013!
>
>
> I suggest to do a release 4.3 soon and among other things have a
> clean-up  and documentation phase and then go for a 4.4 release after
> three months.
> I am willing to contribute to this.
>
> --HH
>
> On 7/16/15, H. Hirzel<hannes.hirzel at gmail.com>  wrote:
>> Thank you for the answer. Your conclusion nicely summarizes my concerns,
>>
>> I will think about it.
>>
>> As for no 1) parts of the system that are affected:
>>
>> Going for a list of all methods, taking the time stamp of last change
>> and do a graph of number of affected methods in each subsystem would
>> be helpful.
>>
>> That shows the impact of changes and allows to choose a proper commit
>> where I want to go for.
>>
>> That could be a built-in report.
>>
>> No 2) Level of risk involved
>> is more difficult to do automaticallyz
>>
>> --HH
>>
>>
>>
>>
>> On 7/16/15, Juan Vuletich<juan at jvuletich.org>  wrote:
>>> Hi Hannes,
>>>
>>> On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>>> Thank you Juan, for answering.
>>>>
>>>> At the moment I feel uncomfortable using Cuis because it is currently
>>>> a quite fast moving target. I perceive quite a number of API changes
>>>> though this might be wrong. But I do not know because there are no
>>>> release notes which summarize it.
>>> Yes, that's true. Besides, we don't have a specification of what is an
>>> API and what is not. So, almost any change can be considered an API
>>> change.
>>>
>>> I don't want you to feel uncomfortable. Let's work this out.
>>>
>>>>    And I do not now in which state my stuff and the general Cuis stuff
>>>> ist.
>>>>
>>>> I need a new 'base line', i.e. a release number to which I can refer
>>>> to when upgrading my code.
>>> Well, but we do have that. It is the update number. It is part of any
>>> Cuis image I've ever committed to the repo.
>>>
>>> The problem, I think, is not identifying well defined Cuis releases. The
>>> problem is knowing how updates could affect your code.
>>>
>>>> Of course the other option  is to just follow the most recent update
>>>> all the time. That would  call for some kind of continuous integration
>>>> testing 'Cuis style' which I not have either.
>>>>
>>>> E.g. if you could do a writeup how you do test Cuis before each new
>>>> commit (there are over 50 this year) and which scripts you use I could
>>>> apply the same thing for my packages.
>>>>
>>>> It has to be something which can be done quickly. Semi-Automatic is
>>>> fine. A check list with
>>>>
>>>> - do this
>>>> - then execute that script
>>>> - Open .. this and that
>>>> - And finally run a report on  ...
>>>>
>>>> would be fine.
>>> I don't have that either. I run the tests from time to time (I'll start
>>> doing it before any commit, and add the xml report to the rep). But this
>>> is not the most important reason why Cuis is solid. Cuis is very
>>> reliable because:
>>> - I'm not too bad as a coder.
>>> - I do my own code revisions at least one day after each change.
>>> - I use Cuis every day, and spot most problems in the updates, before
>>> commtting them to the repo.
>>> - I really, really care about code quality.
>>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>>> is a big responsibility, given how important I think Smalltalk-80 is.
>>>
>>> So, I suggest running your tests when updating your image, or migrating
>>> your code to an updated image.
>>>
>>> In any case, I think this doesn't answer your concerns. What you need is
>>> some way to know which updates could affect you, to review them in
>>> detail, and understanding their effect on your code. A list of the
>>> affected classes and/or methods for each update makes no sense. Cuis can
>>> already show you that very easily. Perhaps each update should include:
>>>
>>> 1) parts of the system that are affected:
>>> - Kernel
>>> - Compiler
>>> - Tools
>>> - Morphic
>>> - etc
>>>
>>> 2) Level of risk involved
>>> - very unlikely to break code that depends on this part of the system
>>> - could perhaps break code that depends on this part of the system
>>> - will most likely break code that depends on this part of the system
>>>
>>> Or something like that.
>>>
>>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>>> free to answer there if you agree.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>> However doing a release tag in github is really not a big deal if you
>>>> actually take the plunge.
>>>>
>>>> You are not alone in not using this option.
>>>>
>>>> It took me two years to realize that I can learn to do it and actually
>>>> do a release in 5 minutes.....
>>>>
>>>> So I suggest do a release just continuing where you left off last time.
>>>>
>>>> Then people will start to realise there is something to test against.
>>>> And new update requests will come and you can do another one.
>>>>
>>>> So the release which I am asking for is not a big deal. Just a tag on a
>>>> commit.
>>>>
>>>> I'd like to explore the direct authoring tools offered by Ken Dickey.
>>>>
>>>> With the aim of producing a very simple Hypercard / Powerpoint like
>>>> authoring environment.
>>>>
>>>> And do more with OMeta.
>>>>
>>>> Happy continued Cuis curating .....
>>>> And thank you very much indeed for your great work maintaining this
>>>> environment.
>>>>
>>>>
>>>> Hannes
>>>>
>>>>
>>>>
>>>> On 7/16/15, Juan Vuletich<juan at jvuletich.org>   wrote:
>>>>> On 7/12/2015 6:27 PM, H. Hirzel wrote:
>>>>>> Hi Juan
>>>>>>
>>>>>> Regarding a Cuis version number. I suggest that you just continue with
>>>>>> a new version number where you left off last time.
>>>>>>
>>>>>> It is just about having a version number to have a new baseline to
>>>>>> refer to. This is helpful for testing and documentation.
>>>>>>
>>>>>> I do not think it is a big issue.
>>>>>>
>>>>>> API changes require a new version number.
>>>>>>
>>>>>> Kind regards
>>>>>> Hannes
>>>>> Hi Hannes,
>>>>>
>>>>> Sometimes I don't pay enough attention to stuff like this, so feel free
>>>>> to request action from me when you feel appropriate :)
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>




From juan at jvuletich.org  Fri Jul 17 08:39:47 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:39:47 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
Message-ID: <55A905A3.1060100@jvuletich.org>

Additional stuff about versioning, and how to keep your code working as 
Cuis changes.

Please share your ideas and thoughts about this.

We all want to ease development and maintenance of all sorts of projects 
while allowing a moderate rate of change to Cuis itself...

Cheers,
Juan Vuletich

-------- Original Message --------
From: 	- Thu Jul 16 10:47:08 2015
X-Mozilla-Status: 	0001
X-Mozilla-Status2: 	00800000
X-Mozilla-Keys: 	
Message-ID: 	<55A7B5DA.1020103 at jvuletich.org>
Date: 	Thu, 16 Jul 2015 10:47:06 -0300
From: 	Juan Vuletich <juan at jvuletich.org>
User-Agent: 	Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; 
rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 	1.0
To: 	H. Hirzel <hannes.hirzel at gmail.com>
Subject: 	Re: DIRECT version number
References: 
<CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA at mail.gmail.com> 
<55A7A607.7050304 at jvuletich.org> 
<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
In-Reply-To: 
<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
Content-Type: 	text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 	7bit



Hi Hannes,

On 7/16/2015 9:57 AM, H. Hirzel wrote:
>  Thank you Juan, for answering.
>
>  At the moment I feel uncomfortable using Cuis because it is currently
>  a quite fast moving target. I perceive quite a number of API changes
>  though this might be wrong. But I do not know because there are no
>  release notes which summarize it.

Yes, that's true. Besides, we don't have a specification of what is an
API and what is not. So, almost any change can be considered an API change.

I don't want you to feel uncomfortable. Let's work this out.

>    And I do not now in which state my stuff and the general Cuis stuff ist.
>
>  I need a new 'base line', i.e. a release number to which I can refer
>  to when upgrading my code.

Well, but we do have that. It is the update number. It is part of any
Cuis image I've ever committed to the repo.

The problem, I think, is not identifying well defined Cuis releases. The
problem is knowing how updates could affect your code.

>  Of course the other option  is to just follow the most recent update
>  all the time. That would  call for some kind of continuous integration
>  testing 'Cuis style' which I not have either.
>
>  E.g. if you could do a writeup how you do test Cuis before each new
>  commit (there are over 50 this year) and which scripts you use I could
>  apply the same thing for my packages.
>
>  It has to be something which can be done quickly. Semi-Automatic is
>  fine. A check list with
>
>  - do this
>  - then execute that script
>  - Open .. this and that
>  - And finally run a report on  ...
>
>  would be fine.

I don't have that either. I run the tests from time to time (I'll start
doing it before any commit, and add the xml report to the rep). But this
is not the most important reason why Cuis is solid. Cuis is very
reliable because:
- I'm not too bad as a coder.
- I do my own code revisions at least one day after each change.
- I use Cuis every day, and spot most problems in the updates, before
commtting them to the repo.
- I really, really care about code quality.
- I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
is a big responsibility, given how important I think Smalltalk-80 is.

So, I suggest running your tests when updating your image, or migrating
your code to an updated image.

In any case, I think this doesn't answer your concerns. What you need is
some way to know which updates could affect you, to review them in
detail, and understanding their effect on your code. A list of the
affected classes and/or methods for each update makes no sense. Cuis can
already show you that very easily. Perhaps each update should include:

1) parts of the system that are affected:
- Kernel
- Compiler
- Tools
- Morphic
- etc

2) Level of risk involved
- very unlikely to break code that depends on this part of the system
- could perhaps break code that depends on this part of the system
- will most likely break code that depends on this part of the system

Or something like that.

BTW, this is a very relevant topic for discussing on the mail list. Feel
free to answer there if you agree.

Cheers,
Juan Vuletich


>  However doing a release tag in github is really not a big deal if you
>  actually take the plunge.
>
>  You are not alone in not using this option.
>
>  It took me two years to realize that I can learn to do it and actually
>  do a release in 5 minutes.....
>
>  So I suggest do a release just continuing where you left off last time.
>
>  Then people will start to realise there is something to test against.
>  And new update requests will come and you can do another one.
>
>  So the release which I am asking for is not a big deal. Just a tag on a commit.
>
>  I'd like to explore the direct authoring tools offered by Ken Dickey.
>
>  With the aim of producing a very simple Hypercard / Powerpoint like
>  authoring environment.
>
>  And do more with OMeta.
>
>  Happy continued Cuis curating .....
>  And thank you very much indeed for your great work maintaining this environment.
>
>
>  Hannes
>
>
>
>  On 7/16/15, Juan Vuletich<juan at jvuletich.org>   wrote:
>>  On 7/12/2015 6:27 PM, H. Hirzel wrote:
>>>  Hi Juan
>>>
>>>  Regarding a Cuis version number. I suggest that you just continue with
>>>  a new version number where you left off last time.
>>>
>>>  It is just about having a version number to have a new baseline to
>>>  refer to. This is helpful for testing and documentation.
>>>
>>>  I do not think it is a big issue.
>>>
>>>  API changes require a new version number.
>>>
>>>  Kind regards
>>>  Hannes
>>  Hi Hannes,
>>
>>  Sometimes I don't pay enough attention to stuff like this, so feel free
>>  to request action from me when you feel appropriate :)
>>
>>  Cheers,
>>  Juan Vuletich
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150717/bf76dfe7/attachment-0004.html>

From Ken.Dickey at whidbey.com  Fri Jul 17 08:40:55 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 17 Jul 2015 06:40:55 -0700
Subject: [Cuis] DIRECT version number
In-Reply-To: <55A8FD14.8060502@jvuletich.org>
References: <CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA@mail.gmail.com>
	<55A7A607.7050304@jvuletich.org>
	<CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A@mail.gmail.com>
	<55A7B5DA.1020103@jvuletich.org>
	<CAGQxfVg7ZLtdkz211LwJPe6uFxSUBMvgeJhafD+ZSxixSMo6tA@mail.gmail.com>
	<CAGQxfVg4pDR8sL9ezpcvtH3DFQuG7Si=wiG=mh+daW0seUTO8g@mail.gmail.com>
	<55A8FD14.8060502@jvuletich.org>
Message-ID: <20150717064055.f8bc194236afd071b8afff51@whidbey.com>

On Fri, 17 Jul 2015 10:03:16 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> So, the question is,
> What is a release? How is it different from a GitHub commit?
> What is the value of a release?

IMHO, a Release is a stable point, expected to be robust and with some level of support, which one can develop against without concern for the ground changing under one's feet.

This is important in commercial projects and things one likes to demo and share around.

In particular, I would expect a Release for Cuis to have major associated packages also maintained at that particular release level.  It would be good to package the core release and associated packages matching that release together.

At this point, I test most of my packages with many (not all) Cuis Commits so that I can find/fix breakage as it happens.  I expect to do this.  I want Cuis to change for the better, radically, but I am not keeping a set of packages pegged to a historical Release.

I am willing to do maintain versions my packages for a particular Cuis release, e.g. for stable demos.  However, I would prefer Releases to be a long intervals (say a year) or after some radical change has been introduced and stabilized.

So far, this has not been a problem, but as usage increases ...

$0.02
-KenD



From juan at jvuletich.org  Fri Jul 17 08:48:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:48:09 -0300
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
Message-ID: <55A90799.7080302@jvuletich.org>

On 7/16/2015 11:49 AM, H. Hirzel wrote:
> Hello
>
> I'd like to do a query finding out about the time stamp of  source
> code changes of all methods in the Cuis image and then do a list with
> the following four columns
>
>
> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName, DateOfChange
>
> Help is appreciated.
>
> Hannes

Check #timeStampFor:class:reverseOrdinal: and in general 
#annotationForSelector:ofClass:

Cheers,
Juan Vuletich



From juan at jvuletich.org  Fri Jul 17 08:51:38 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 10:51:38 -0300
Subject: [Cuis] Preventing pretty print from replacing := with _?
In-Reply-To: <1437071789.2255.28.camel@gmail.com>
References: <1437003792.2401.2.camel@gmail.com>	
	<55A7AB18.5020601@jvuletich.org>
	<1437071789.2255.28.camel@gmail.com>
Message-ID: <55A9086A.9060600@jvuletich.org>

On 7/16/2015 3:36 PM, Phil (list) wrote:
> Juan,
>
> On Thu, 2015-07-16 at 10:01 -0300, Juan Vuletich wrote:
>> On 7/15/2015 8:43 PM, Phil (list) wrote:
>>> Is there a setting that will disable this substitution?  I would
>>> actually prefer it to go the other way: if it sees an _ assignment,
>>> replace it with :=
>>>
>>> Thanks,
>>> Phil
>> Please check #syntaxHighlightingAsYouTypeAnsiAssignment and
>> #syntaxHighlightingAsYouTypeLeftArrowAssignment . Both default to false.
>>
>> Would turning on #syntaxHighlightingAsYouTypeAnsiAssignment be enough
>> for you?
>>
> I'm already setting #syntaxHighlightingAsYouTypeAnsiAssignment to true
> and leaving #syntaxHighlightingAsYouTypeLeftArrowAssignment at false.
> That seems to work for everything except pretty printing.

But, are you using Shout on the code pane? Can you list simple steps to 
reproduce on a fresh Cuis image?

>    I also played
> with #allowUnderscoreAssignments but that just determines whether or not
> _ is valid and doesn't stop pretty print trying to use underscores
> anyway (which is entertaining because then pp produces invalid code :-)

Yep. We could indeed fix that. Ok. I'll include it in the next commit.

Cheers,
Juan Vuletich

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




From juan at jvuletich.org  Fri Jul 17 09:15:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 17 Jul 2015 11:15:53 -0300
Subject: [Cuis] Array2D newSize:
In-Reply-To: <1437077628.2255.77.camel@gmail.com>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>	
	<1436999006167-4837720.post@n4.nabble.com>	
	<1437007797.2401.12.camel@gmail.com>
	<55A7B057.4050803@jvuletich.org>
	<1437077628.2255.77.camel@gmail.com>
Message-ID: <55A90E19.3060005@jvuletich.org>

Hi Phil,

On 7/16/2015 5:13 PM, Phil (list) wrote:
> Juan,
>
> On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
>> Hi Phil,
>>
>> On 7/15/2015 9:49 PM, Phil (list) wrote:
>>> Glad that solved your problem but, ouch... that class is uncomfortably
>>> close in name and function to the 3DTransform package I'm using for
>>> OpenGL.  Juan: would you be open to using an extended version of my
>>> classes so that we don't run into namespace conflicts?
>> Indeed we need to do something with this. Check the "Math 3D" package.
>> It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need
>> double precision for satellite image processing at work.
>>
> You space guys with your astronomically large numbers and being sooooo
> concerned with precisely where things are.  Why can't you accept
> 'there-ish' like the rest of us? :-)

:) I would... But if you want Google Earth level of precision, you do 
need them...

> (disclaimer: the events depicted in Gravity should in no way cast
> aspersions as to the inadequacies of 32-bit floats...)
>
> Ahh... hadn't noticed the Math 3D stuff before.  For OpenGL, I've been
> using a combination of the Collections-Arrayed, Collections-Balloon and
> 3DTransform (i.e. the 3DTransform package which provides the Vector* and
> Matrix* classes, which came from Croquet, or whatever upstream source
> they pulled from)

Croquet was done by Andreas, who previously wrote all the Baloon 3d 
stuff (including "Balloon3D-Math" , that is the base of the Math 3D 
package I did )

> The Float64* class hierarchy in Math 3D appears to just be a parallel
> 64-bit hierarchy (with some slight naming convention differences) to the
> 32-bit Vector* and Matrix* classes from 3DTransform.  So what we'd
> probably want to do there is merge them (i.e. keeping both the 64-bit
> and 32-versions... when you need one or the other, you absolutely need
> it) into a single package and make sure they have identical
> functionality and consistent naming conventions (I have no preference on
> which conventions we use other than that they be consistent.  Makes no
> difference to me whether I'm using Vector2 or Float32Vector2 or whatever
> else would make sense)  If we did that, this would just leave the
> question of how the LinearAlgebra and Array2D classes fit into this (one
> thing I don't currently have but would like is an arbitrary MxN 32-bit
> float matrix class)...
>
> At first glance, the naming convention mapping appears to be:
>
> Float64Color4 ->  VectorColor
> Float64Matrix4x4 ->  Matrix4x4
> Float64Rotation ->  Quaternion
> Float64Vector2 ->  Vector2
> Float64Vector3 ->  Vector3
> Float64Vector4 ->  Vector4
>
> With the balances of the classes being unique to 3DTransform. (Just
> curious: for Float64Vector* why don't you use a common base class
> similar to Vector?)

This comes from "Balloon3D-Math".  I'm sure Andreas did it that way to 
be able to write very efficient slang code for the Ballon3D VM plugin.

WRT to naming conventions, we just need to agree on one. I have no 
preference.

>> There is a lot of overlap with yours, but you are using 32 bit Floats.
>>
> For now... at some point I'm sure I'll be needing 64-bit Floats as well.
> Since both the VM and OpenGL are limited to 32-bits, that's been doing
> the job for me. (my priority is currently performance over precision
> since for me it's just an errant pixel, for you it might be a house or
> your satellite heading for the ISS...)

That's totally ok. Just a remark: the VM is not limited to 32 bits. 
Floats are 64 bits and are handled by the VM. What is limited to 32 bits 
is FloatArrayPlugin. But it is entirely possible to add Float64 (a.k.a. 
double) primitives to it.

WRT the satellites... I'm not doing AOCS (Attitude and Orbital Control 
System), but the image processing pipeline. So, a numeric error would be 
like saying that a picture of L.A. is in Mexico, or such :)

>>> One advantage that the Matrix* and Vector* classes I'm using have is
>>> that they are mapped to native types which makes for transparent and
>>> easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
>>> compute shaders and you have the fastest matrix math you've ever seen,
>>> assuming you've got medium or larger sets of data)
>> Yes. This is indeed great. We need to build a single, uniform package
>> with this stuff, that handles both 32 and 64 bit Floats and can take
>> advantage of GPUs.
>>
>> BTW, have you used OpenCL from Cuis? I'll be needing to work with that
>> in a few months.
>>
> Not yet, but pretty much all of the same issues I've run into with
> OpenGL would apply for OpenCL (i.e. it's all FFI as far as the VM is
> concerned unless you're going to create a plugin, but even then you
> still have the same issues) so I think we should be able to get to a
> unified vector/matrix structure that works for both of us.  In both
> cases the key is to minimize the amount of work done to marshal native
> data in and out (slow/expensive conversions have a dramatic and
> detrimental cost for small data sets / short computations) while keeping
> the data as easy to work with as possible in both the Smalltalk and FFI
> (whether OpenGL/OpenCL/CUDA/Metal/Vulcan/etc.) environments.

Yes.

Something that I would like (and I don't know how to do it without 
Traits) is to share most of the source code between the 32 and 64 bits 
versions. We would need something like two parallel inheritance hierarchies:

GeneralFloatArray
--- FloatArray32
--- --- FloatVector32
--- --- FloatQuaternion32
--- FloatArray64
--- --- FloatVector64
--- --- FloatQuaternion64
for the inheritance of size specific code (#at: #at:put: primitives)

and something like
FloatVector
--- FloatQuaternion
--- --- FloatQuaternion32
--- --- FloatQuaternion64
to share quaternion specific code...

Any idea on this? If code sharing is not possible, at least some help to 
keep both consistent...

> Something to keep in the back of your mind: OMeta.  One of the many
> reasons I get so geeked out about it is that an OpenGL shader is just
> another language that can be targeted via source-to-source translation
> (i.e. dynamically generated GPU code written in something similar to
> Slang or another DSL from Cuis).  OpenCL shouldn't be terribly
> different...

Yes... Although as OpenCL is close to C, I was thinking on a variant of 
Slang... Especially after Bert did a translator Slang -> js

Cheers,
Juan Vuletich



From Ken.Dickey at whidbey.com  Fri Jul 17 09:21:52 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 17 Jul 2015 07:21:52 -0700
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55A905A3.1060100@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
Message-ID: <20150717072152.c4ed6c0e14a113c18966f2d8@whidbey.com>

On Fri, 17 Jul 2015 10:39:47 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> The problem, I think, is not identifying well defined Cuis releases. The
> problem is knowing how updates could affect your code.

This is a large search space.  It is easy for some minor change to have a cascaded interaction.

In thinking about this, I like to think of aerodynamic drag.  I want to be able to make rapid progress, so I like streamlined development processes.  I also want stability and robustness.

I think the inflection point where we go from laminar to turbulent air flow will change over time.

At this point in time, there are the fewest users and projects Cuis is likely to have.  I personally favor minimal drag and maximal progress at the expense of stability.  As stability becomes more important, added drag (heavier duty release process) is justified.

I once was talking with someone about garbage collection and they asked me how I could _prove_ that only "live" objects were left after each GC.  I told them it was a "proof by contradiction".

I.e. it's not a problem until it becomes a problem.

I did software development for a living for a couple of decades.  For me (a vote of 1) Release process is not yet a problem.  But, hey, I'm an old hacker guy.

What does everyone else think?

-- 
-KenD

PS: the random progress graphic is totally unrelated to this discussion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PropEdit-Screenshot.png
Type: image/png
Size: 324850 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150717/563d523a/attachment-0004.png>

From dnorton at mindspring.com  Fri Jul 17 09:57:34 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 17 Jul 2015 10:57:34 -0400
Subject: [Cuis] Block Arguments
In-Reply-To: <1437099105.2255.92.camel@gmail.com>
References: <55A85DBA.15429.29625A6@dnorton.mindspring.com>,
	<1437099105.2255.92.camel@gmail.com>
Message-ID: <55A917DE.23607.2C3F41@dnorton.mindspring.com>

On 16 Jul 2015 at 22:11, Phil (list) wrote:

> On Thu, 2015-07-16 at 21:43 -0400, Dan Norton wrote:
> > Hi Juan,
> > 
> > 
> > On windows, when the attached class method is added to StrikeFont
> and
> > cmd-d is done on the comment, it produces:
> > 
> > 
> > 'Error: This block accepts 0 arguments, but was called with 1
> > argument.'
> > 
> > 
> > AFAIKT it is not passing any arguments and the files do exist.
> Maybe a
> > bug?
> > 
> But it is passing an argument to your ifExistsDo: block (the
> filestream)
> and your block doesn't accept any.  If you don't care about the
> filestream, change your blocks to [:filestream| {baseName. ' OK'}
> print]
> etc. and ignore the parameter.
>

Ahh, now I see it. Interesting. Thanks, Phil.

 - Dan



From dnorton at mindspring.com  Fri Jul 17 10:03:27 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 17 Jul 2015 11:03:27 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150717072152.c4ed6c0e14a113c18966f2d8@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>,
	<20150717072152.c4ed6c0e14a113c18966f2d8@whidbey.com>
Message-ID: <55A9193F.13540.31A0C2@dnorton.mindspring.com>

On 17 Jul 2015 at 7:21, Ken.Dickey wrote:

> On Fri, 17 Jul 2015 10:39:47 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
> 
> > The problem, I think, is not identifying well defined Cuis
> releases. The
> > problem is knowing how updates could affect your code.
> 
> This is a large search space.  It is easy for some minor change to
> have a cascaded interaction.
> 
> In thinking about this, I like to think of aerodynamic drag.  I want
> to be able to make rapid progress, so I like streamlined development
> processes.  I also want stability and robustness.
> 
> I think the inflection point where we go from laminar to turbulent
> air flow will change over time.
> 
> At this point in time, there are the fewest users and projects Cuis
> is likely to have.  I personally favor minimal drag and maximal
> progress at the expense of stability.  As stability becomes more
> important, added drag (heavier duty release process) is justified.
> 
> I once was talking with someone about garbage collection and they
> asked me how I could _prove_ that only "live" objects were left
> after each GC.  I told them it was a "proof by contradiction".
> 
> I.e. it's not a problem until it becomes a problem.
> 
> I did software development for a living for a couple of decades. 
> For me (a vote of 1) Release process is not yet a problem.  But,
> hey, I'm an old hacker guy.
>

+1

 - Dan
 
> What does everyone else think?
> 
> -- 
> -KenD
> 
> PS: the random progress graphic is totally unrelated to this
> discussion.
> 





From pbpublist at gmail.com  Fri Jul 17 10:18:54 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 17 Jul 2015 11:18:54 -0400
Subject: [Cuis] Array2D newSize:
In-Reply-To: <55A90E19.3060005@jvuletich.org>
References: <55A68249.17883.775BA8@dnorton.mindspring.com>
	<1436999006167-4837720.post@n4.nabble.com>
	<1437007797.2401.12.camel@gmail.com> <55A7B057.4050803@jvuletich.org>
	<1437077628.2255.77.camel@gmail.com> <55A90E19.3060005@jvuletich.org>
Message-ID: <1437146334.2255.134.camel@gmail.com>

Juan,

On Fri, 2015-07-17 at 11:15 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> On 7/16/2015 5:13 PM, Phil (list) wrote:
> > Juan,
> >
> > On Thu, 2015-07-16 at 10:23 -0300, Juan Vuletich wrote:
> >> Hi Phil,
> >>
> >> On 7/15/2015 9:49 PM, Phil (list) wrote:
> >>> Glad that solved your problem but, ouch... that class is uncomfortably
> >>> close in name and function to the 3DTransform package I'm using for
> >>> OpenGL.  Juan: would you be open to using an extended version of my
> >>> classes so that we don't run into namespace conflicts?
> >> Indeed we need to do something with this. Check the "Math 3D" package.
> >> It is based on "Balloon3D-Math" for Squeak by Andreas Raab, but I need
> >> double precision for satellite image processing at work.
> >>
> > You space guys with your astronomically large numbers and being sooooo
> > concerned with precisely where things are.  Why can't you accept
> > 'there-ish' like the rest of us? :-)
> 
> :) I would... But if you want Google Earth level of precision, you do 
> need them...
> 

Just aim for Apple Maps level of precision and call it good enough :-)

> > (disclaimer: the events depicted in Gravity should in no way cast
> > aspersions as to the inadequacies of 32-bit floats...)
> >
> > Ahh... hadn't noticed the Math 3D stuff before.  For OpenGL, I've been
> > using a combination of the Collections-Arrayed, Collections-Balloon and
> > 3DTransform (i.e. the 3DTransform package which provides the Vector* and
> > Matrix* classes, which came from Croquet, or whatever upstream source
> > they pulled from)
> 
> Croquet was done by Andreas, who previously wrote all the Baloon 3d 
> stuff (including "Balloon3D-Math" , that is the base of the Math 3D 
> package I did )

Ah, I knew Andreas did most of the graphics stuff in Croquet but wasn't
sure about the math code (just spot-checking, I see 'das' listed as the
person who last touched most of the code back in 2005 with some by
Andreas both before and after)

> 
> > The Float64* class hierarchy in Math 3D appears to just be a parallel
> > 64-bit hierarchy (with some slight naming convention differences) to the
> > 32-bit Vector* and Matrix* classes from 3DTransform.  So what we'd
> > probably want to do there is merge them (i.e. keeping both the 64-bit
> > and 32-versions... when you need one or the other, you absolutely need
> > it) into a single package and make sure they have identical
> > functionality and consistent naming conventions (I have no preference on
> > which conventions we use other than that they be consistent.  Makes no
> > difference to me whether I'm using Vector2 or Float32Vector2 or whatever
> > else would make sense)  If we did that, this would just leave the
> > question of how the LinearAlgebra and Array2D classes fit into this (one
> > thing I don't currently have but would like is an arbitrary MxN 32-bit
> > float matrix class)...
> >
> > At first glance, the naming convention mapping appears to be:
> >
> > Float64Color4 ->  VectorColor
> > Float64Matrix4x4 ->  Matrix4x4
> > Float64Rotation ->  Quaternion
> > Float64Vector2 ->  Vector2
> > Float64Vector3 ->  Vector3
> > Float64Vector4 ->  Vector4
> >
> > With the balances of the classes being unique to 3DTransform. (Just
> > curious: for Float64Vector* why don't you use a common base class
> > similar to Vector?)
> 
> This comes from "Balloon3D-Math".  I'm sure Andreas did it that way to 
> be able to write very efficient slang code for the Ballon3D VM plugin.
> 
> WRT to naming conventions, we just need to agree on one. I have no 
> preference.
> 

I'm OK with changing my stuff to use Float32*.  Since both hierarchies
are dependent on their underlying native types, that would probably be
the most straightforward approach.  Would it make sense to you to use
FloatXXQuaternion? (Rotation seems a bit vague to me since, while
unlikely, there could potentially be other rotation solutions
implemented)

> >> There is a lot of overlap with yours, but you are using 32 bit Floats.
> >>
> > For now... at some point I'm sure I'll be needing 64-bit Floats as well.
> > Since both the VM and OpenGL are limited to 32-bits, that's been doing
> > the job for me. (my priority is currently performance over precision
> > since for me it's just an errant pixel, for you it might be a house or
> > your satellite heading for the ISS...)
> 
> That's totally ok. Just a remark: the VM is not limited to 32 bits. 
> Floats are 64 bits and are handled by the VM. What is limited to 32 bits 
> is FloatArrayPlugin. But it is entirely possible to add Float64 (a.k.a. 
> double) primitives to it.
> 

That's good to know.  I've been meaning to dig back into the VM source
as there are still some questions I have about how FFI is doing some of
what it is doing.  Just lack of time on my part vs other priorities...

> WRT the satellites... I'm not doing AOCS (Attitude and Orbital Control 
> System), but the image processing pipeline. So, a numeric error would be 
> like saying that a picture of L.A. is in Mexico, or such :)
> 

Awww... you've destroyed my Dr. Evil mental image of you at work ;-)

> >>> One advantage that the Matrix* and Vector* classes I'm using have is
> >>> that they are mapped to native types which makes for transparent and
> >>> easy use on a GPU (which aren't just for graphics anymore BTW.  Just add
> >>> compute shaders and you have the fastest matrix math you've ever seen,
> >>> assuming you've got medium or larger sets of data)
> >> Yes. This is indeed great. We need to build a single, uniform package
> >> with this stuff, that handles both 32 and 64 bit Floats and can take
> >> advantage of GPUs.
> >>
> >> BTW, have you used OpenCL from Cuis? I'll be needing to work with that
> >> in a few months.
> >>
> > Not yet, but pretty much all of the same issues I've run into with
> > OpenGL would apply for OpenCL (i.e. it's all FFI as far as the VM is
> > concerned unless you're going to create a plugin, but even then you
> > still have the same issues) so I think we should be able to get to a
> > unified vector/matrix structure that works for both of us.  In both
> > cases the key is to minimize the amount of work done to marshal native
> > data in and out (slow/expensive conversions have a dramatic and
> > detrimental cost for small data sets / short computations) while keeping
> > the data as easy to work with as possible in both the Smalltalk and FFI
> > (whether OpenGL/OpenCL/CUDA/Metal/Vulcan/etc.) environments.
> 
> Yes.
> 
> Something that I would like (and I don't know how to do it without 
> Traits) is to share most of the source code between the 32 and 64 bits 
> versions. We would need something like two parallel inheritance hierarchies:
> 
> GeneralFloatArray
> --- FloatArray32
> --- --- FloatVector32
> --- --- FloatQuaternion32
> --- FloatArray64
> --- --- FloatVector64
> --- --- FloatQuaternion64
> for the inheritance of size specific code (#at: #at:put: primitives)
> 
> and something like
> FloatVector
> --- FloatQuaternion
> --- --- FloatQuaternion32
> --- --- FloatQuaternion64
> to share quaternion specific code...
> 
> Any idea on this? If code sharing is not possible, at least some help to 
> keep both consistent...
> 

That would be the ideal.  But like you, I can only think of ways that
are a bit messy:

1) Traits (dependency complexity)
2) OMeta (using it as a templating system to emit both variants,
dependency complexity)
3) Using class composition rather than inheritance (adds a bit of
complexity as you would need to call something like myMatrix #contents
to actually get at the data to pass to FFI)

Probably the simplest solution short term is just keep a parallel class
hierarchy in the same package and ensure that they stay in sync using
test cases.

> > Something to keep in the back of your mind: OMeta.  One of the many
> > reasons I get so geeked out about it is that an OpenGL shader is just
> > another language that can be targeted via source-to-source translation
> > (i.e. dynamically generated GPU code written in something similar to
> > Slang or another DSL from Cuis).  OpenCL shouldn't be terribly
> > different...
> 
> Yes... Although as OpenCL is close to C, I was thinking on a variant of 
> Slang... Especially after Bert did a translator Slang -> js
> 

However you go about it, just keep language abstraction in mind.  Just
as OpenGL continues to go through backwards-incompatible changes to
'fix' its abstraction layer issues, I suspect we're entering a similar
phase with OpenCL and CUDA.  We will likely end up with something
different such as Vulcan or Metal as the GPU compute standard a few
years from now.  Hopefully it won't take them as many iterations as it
has with OpenGL... (wishful thinking on my part, I fear)

> Cheers,
> Juan Vuletich

Thanks,
Phil




From edgardec2005 at gmail.com  Fri Jul 17 12:36:25 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Fri, 17 Jul 2015 14:36:25 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
Message-ID: <E772B770227A414C8E4912293F62ED5A@gmail.com>

Casey , you begin all this a long time ago.
Hope you could be healthy and join to the quest soon.


Now i away of my dungeons, but this week end I take a torch and try to found the relevant info.
To my short memory , no code or significant progress.
Not knowing if Apple could be persuaded HyperCard go open source or give technical info what could be useful to any wishing bring HyperCard to life again..

But glad Juan , Hannes show interest.

Edgar 

-- 
Edgar De Cleene
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Thursday, July 16, 2015 at 10:00 AM, H. Hirzel wrote:

> I think there was something like that. Need to search in the Squeak
> list. And check the porting effort. Might be doable with Cuis these
> days.
> 
> --Hannes
> 
> On 7/16/15, Juan Vuletich <juan at jvuletich.org (mailto:juan at jvuletich.org)> wrote:
> > Hi Edgar,
> > 
> > Is there such a project? Any reference?
> > 
> > Thanks,
> > Juan Vuletich
> > 
> > On 7/11/2015 5:24 PM, Edgar J De Cleene wrote:
> > > Quoting Casey
> > > 
> > > > If we can throw in some HyperCard and...
> > > 
> > > A long time algo wish Squeak could read HyperCard stacks.
> > > If Cuis could do this , bet we have thousands users.
> > > Anyway whats the HyperCard status ?
> > > 
> > 
> > 
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org (mailto: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/20150717/0f16a00a/attachment-0004.html>

From pbpublist at gmail.com  Fri Jul 17 13:45:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 17 Jul 2015 14:45:01 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55A905A3.1060100@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
Message-ID: <1437158701.2255.245.camel@gmail.com>

On Fri, 2015-07-17 at 10:39 -0300, Juan Vuletich wrote:
> Additional stuff about versioning, and how to keep your code working
> as Cuis changes.
> 
> Please share your ideas and thoughts about this.
> 
> We all want to ease development and maintenance of all sorts of
> projects while allowing a moderate rate of change to Cuis itself...
> 
> Cheers,
> Juan Vuletich
> 
> -------- Original Message -------- 
>                              From: 
> - Thu Jul 16 10:47:08 2015
>                  X-Mozilla-Status: 
> 0001
>                 X-Mozilla-Status2: 
> 00800000
>                    X-Mozilla-Keys: 
> 
> 
>                        Message-ID: 
> <55A7B5DA.1020103 at jvuletich.org>
>                              Date: 
> Thu, 16 Jul 2015 10:47:06 -0300
>                              From: 
> Juan Vuletich <juan at jvuletich.org>
>                        User-Agent: 
> Mozilla/5.0 (Windows; U; Windows NT
> 6.1; en-US; rv:1.9.2.28)
> Gecko/20120306 Thunderbird/3.1.20
>                      MIME-Version: 
> 1.0
>                                To: 
> H. Hirzel <hannes.hirzel at gmail.com>
>                           Subject: 
> Re: DIRECT version number
>                        References: 
> <CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA at mail.gmail.com> <55A7A607.7050304 at jvuletich.org> <CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
>                       In-Reply-To: 
> <CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
>                      Content-Type: 
> text/plain; charset=UTF-8;
> format=flowed
>         Content-Transfer-Encoding: 
> 7bit
> 
> 
> Hi Hannes,
> 
> On 7/16/2015 9:57 AM, H. Hirzel wrote:
> > Thank you Juan, for answering.
> >
> > At the moment I feel uncomfortable using Cuis because it is currently
> > a quite fast moving target. I perceive quite a number of API changes
> > though this might be wrong. But I do not know because there are no
> > release notes which summarize it.
> 

I totally feel Hannes' pain having gone through it a few times myself
over the years.  At the same time, I agree with Ken's point about not
getting too bogged down in process since we're in the best position
right now to break things for the better longer term.

> Yes, that's true. Besides, we don't have a specification of what is an 
> API and what is not. So, almost any change can be considered an API change.
> 

That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
issue, not specific to Cuis)  I believe it is largely fixable without
tons of documentation and tests: the use of private (categories or
method naming convention).  Bernhard pointed out an existing capability
a few months ago
http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
While I personally like the idea of private categories, one of these
approaches should really be seriously considered.

Other than a few specific examples (i.e. mostly the base data types
including the Collection and Number class hierarchies which are pretty
mature and don't change all that much anyway) I would guesstimate that
<20% (probably closer to 10%) of the methods, and and unknown % of
classes (a significantly larger fraction though), should even be
considered public.  If things were indicated as private that would
accomplish two things:

1) We could construct some simple tooling (some combination of up-front
warnings in the editor and/or a lint-type tester after the fact) that
would allow people to identify problematic calls within their code.
(i.e. just because it works now doesn't mean it always will if you keep
calling X, Y, Z...)

2) It would provide a way for people to know if something needs to be
discussed.  i.e. 'In class X method Y is private but I need that type of
functionality' so you would know that there's a need and could consider
either making it public, and therefore supported, or rethinking its
implementation if you'd like to offer a better public API solution.

> I don't want you to feel uncomfortable. Let's work this out.
> 
> >   And I do not now in which state my stuff and the general Cuis stuff ist.
> >
> > I need a new 'base line', i.e. a release number to which I can refer
> > to when upgrading my code.
> 
> Well, but we do have that. It is the update number. It is part of any 
> Cuis image I've ever committed to the repo.
> 
> The problem, I think, is not identifying well defined Cuis releases. The 
> problem is knowing how updates could affect your code.
> 

By narrowing the scope of what the public API is using private
designators, this dramatically reduces what you need to be concerned
with on this front.  It's part of the reason that Apple, Google, and
even Microsoft are so adamant about public APIs these days.  They dealt
with the pain of even major developers depending on private APIs for
decades. It's only been in the last 10 years or so that they've been
able to dig themselves out from under this issue.

This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
attitude of 'you have the source, play around, have fun!' has morphed
into 'everything is a public API!  there are no rules! isn't this
great?'  Well no, it's not great.  It makes life impossible for image
maintainers (Squeak has been in a coma for the last decade or so as the
result of trying to keep everyone happy... yet no one seems to be) and
miserable for those who are trying to keep code running on it (stuff
still breaks all the time.)

I personally believe the minimalism and simplicity that Cuis is based on
has the best long term prospects but we have to get out of this
'everything is public' mindset.  Sure, we have all the source: look at
it, learn from it, poke around, refactor it, submit fixes, etc.  But
there needs to be a manageable subset of it which is considered the
'public API' that people can depend on to write frameworks and apps on
top of that is relatively stable longer term.  Let's start defining what
that is and backfill changes to the public API (which will happen from
time to time as we don't want things to be completely static) with tests
and documentation so you can focus your efforts on where they matter
most and you get the most enjoyment from.

> > Of course the other option  is to just follow the most recent update
> > all the time. That would  call for some kind of continuous integration
> > testing 'Cuis style' which I not have either.
> >
> > E.g. if you could do a writeup how you do test Cuis before each new
> > commit (there are over 50 this year) and which scripts you use I could
> > apply the same thing for my packages.
> >
> > It has to be something which can be done quickly. Semi-Automatic is
> > fine. A check list with
> >
> > - do this
> > - then execute that script
> > - Open .. this and that
> > - And finally run a report on  ...
> >
> > would be fine.
> 
> I don't have that either. I run the tests from time to time (I'll start 
> doing it before any commit, and add the xml report to the rep). But this 
> is not the most important reason why Cuis is solid. Cuis is very 
> reliable because:

reliable != stable

> - I'm not too bad as a coder.
> - I do my own code revisions at least one day after each change.
> - I use Cuis every day, and spot most problems in the updates, before 
> commtting them to the repo.
> - I really, really care about code quality.
> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that 
> is a big responsibility, given how important I think Smalltalk-80 is.
> 

Agree to all this and more.  Cuis would not be where it is without your
continued effort and diligence. (i.e. setting aside that you obviously
created it, if you had just tossed it out into the world and let it go
at best it would have started looking something like Squeak or Pharo by
now.  It's a lot of effort over the long term to *keep* it small and
focused.  THANK YOU JUAN!)

> So, I suggest running your tests when updating your image, or migrating 
> your code to an updated image.
> 

+1 to tests as they do help quite a bit and are a very good practice.
Just be judicious in what/where you test (I personally don't subscribe
to the TDD approach where you spend your days mostly writing tests.
That's just admitting defeat in that you spend all day writing
executable documentation.)

> In any case, I think this doesn't answer your concerns. What you need is 
> some way to know which updates could affect you, to review them in 
> detail, and understanding their effect on your code. A list of the 
> affected classes and/or methods for each update makes no sense. Cuis can 
> already show you that very easily. Perhaps each update should include:
> 
> 1) parts of the system that are affected:
> - Kernel
> - Compiler
> - Tools
> - Morphic
> - etc
> 
> 2) Level of risk involved
> - very unlikely to break code that depends on this part of the system
> - could perhaps break code that depends on this part of the system
> - will most likely break code that depends on this part of the system
> 
> Or something like that.
> 
> BTW, this is a very relevant topic for discussing on the mail list. Feel 
> free to answer there if you agree.
> 

One final thought on this:  I suspect a major cause of people abandoning
Cuis (and Smalltalk in general), behind the 'it's too different from
what I'm used to'/'not mainstream' reaction, is the instability of its
APIs.

> Cheers,
> Juan Vuletich
> 
> 
> > However doing a release tag in github is really not a big deal if you
> > actually take the plunge.
> >
> > You are not alone in not using this option.
> >
> > It took me two years to realize that I can learn to do it and actually
> > do a release in 5 minutes.....
> >
> > So I suggest do a release just continuing where you left off last time.
> >
> > Then people will start to realise there is something to test against.
> > And new update requests will come and you can do another one.
> >
> > So the release which I am asking for is not a big deal. Just a tag on a commit.
> >
> > I'd like to explore the direct authoring tools offered by Ken Dickey.
> >
> > With the aim of producing a very simple Hypercard / Powerpoint like
> > authoring environment.
> >
> > And do more with OMeta.
> >
> > Happy continued Cuis curating .....
> > And thank you very much indeed for your great work maintaining this environment.
> >
> >
> > Hannes
> >
> >
> >
> > On 7/16/15, Juan Vuletich<juan at jvuletich.org>  wrote:
> >> On 7/12/2015 6:27 PM, H. Hirzel wrote:
> >>> Hi Juan
> >>>
> >>> Regarding a Cuis version number. I suggest that you just continue with
> >>> a new version number where you left off last time.
> >>>
> >>> It is just about having a version number to have a new baseline to
> >>> refer to. This is helpful for testing and documentation.
> >>>
> >>> I do not think it is a big issue.
> >>>
> >>> API changes require a new version number.
> >>>
> >>> Kind regards
> >>> Hannes
> >> Hi Hannes,
> >>
> >> Sometimes I don't pay enough attention to stuff like this, so feel free
> >> to request action from me when you feel appropriate :)
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From Ken.Dickey at whidbey.com  Fri Jul 17 14:11:02 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 17 Jul 2015 12:11:02 -0700
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <E772B770227A414C8E4912293F62ED5A@gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
Message-ID: <20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>

HyperCard Factoids

- The reason that HyperCard failed to support color for many years was that the project leader was color blind and could not see using all those extra bits just to support color. [Someone at Apple told me this, I forget who.]

- The original Myst was developed & deployed using HyperCard. [I found this out from Robyn and Rand Miller when they visited Apple.]

FYI,
-KenD



From 0800nacho at gmail.com  Fri Jul 17 14:37:36 2015
From: 0800nacho at gmail.com (Ignacio Sniechowski)
Date: Fri, 17 Jul 2015 16:37:36 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
	<20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
Message-ID: <CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>

This is a good resource for HyperCard and HyperTalk

http://hypercard.org

cheers
Nacho


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

*Tel: (011) 4542-6714*


















On Fri, Jul 17, 2015 at 4:11 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

> HyperCard Factoids
>
> - The reason that HyperCard failed to support color for many years was
> that the project leader was color blind and could not see using all those
> extra bits just to support color. [Someone at Apple told me this, I forget
> who.]
>
> - The original Myst was developed & deployed using HyperCard. [I found
> this out from Robyn and Rand Miller when they visited Apple.]
>
> FYI,
> -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/20150717/190ea4f7/attachment-0004.html>

From hannes.hirzel at gmail.com  Fri Jul 17 17:21:50 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Fri, 17 Jul 2015 22:21:50 +0000
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
	<20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
	<CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
Message-ID: <CAGQxfVh_0LZv+AzQMep1urFYpP36qqdeKmcG01x_-wQyUj3gFg@mail.gmail.com>

At the moment my interest is in creating a very small subset of Hypercard

Pictures on cards with a caption and buttons. Plus cards with bullet lists.

I postpone the direct manipulation aspect currently. I describe what
is on the cards with Smalltalk (you may call it a "DSL" for describing
stacks). And I have a reader for MarkDown and other similar types of
input.

These very days I focus on generating export formats (Just a sequence
of JPEGs to put on a tablet as is, LibreOffice Writer, LibreOffice
Impress, Large JPEG with many cards to create a poster, Microsoft
Word, Powerpoint, Markdown e.g. https://www.swipe.to/).  I work on
Pharo 4 at the moment and I aim at easy porting to Cuis.

More interaction will come later (drag and drop activities).


For a fairly recent Hypercard in Smalltalk / Squeak discussions see
the Squeak mailing list

Feb 24, 2013 at 10:54 AM
About HyperCard

A thread started by Edgar. I downloaded the sample image and could run
a stack like the Hypercard help stack in Squeak (screen shot
attached).


Below an extract of that thread.

-- Hannes


Feb 24, 2013 at 10:54 AM
About HyperCard

http://www.vpri.org/pdf/m2011001_dbjr_spec.pdf

DynaBook Junior Specification
by Ted Kaehler
14 Jan 2009. (Minor corrections 13 Dec 2010)
A specification for DynaBook Junior
shown in itself.
DBJr is a desktop publishing framework and
application builder that is modeled after Apple's HyperCard.

Abstract
DynaBook Junior is a desktop publishing
framework and application builder that is
modeled after Apple's HyperCard(tm). The
purpose of this specification is as a starting
point for the discovery of an extremely simple
way to describe and automatically generate
DynaBook Junior. The specification describes
stacks, pages, backgrounds, objects
embedded in pages, the front-to-back ordering
of objects, and page-specific objects. This
document is itself a DBJr stack that shows
examples of the features it describes.
Algorithms for showing a new page, adding
pages, adding backgrounds, and adding
objects to a page are given in pseudocode.


http://tinlizzie.org/lesserphic2/

download the example stack
http://tinlizzie.org/lesserphic2/aboutDBJr%205-Aug.morph
in addition, locate it with the file browser and then choose 'load as morph'

....
While the DynaBookJr (I always misread "DBJr" as "DataBase Jr") is
indeed a good modern replacement for HyperCard, isn't the normal
BookMorph already available in Squeak a reasonable approximation?

...
The Lesserphic version of DBJr is considered to be obsolete.  It uses
the "Etoys-style" uniclasses for pages but we later figured out a
simpler way of implementing it.
...


http://www.vpri.org/pdf/m2013003_ksapps.pdf


... research report 'Making
applications in KSWorld' and the equally interesting report of October
2012 'A Report on KScript and KSWorld'
http://www.vpri.org/html/writings.php

Chapter 6 of the the October report talks about  the hosting
environment which happens to be Squeak

<citation>
Hosting Environment: Squeak
As of this writing, the KSWorld is hosted on top of Squeak Smalltalk [10]. A
special Morphic widget called KSMorph is created under RectangleMorph.
</citation>


....

In the new document, Section
7.1 discusses the "Document Model" and Section 8.9 says it took about
200 lines to implement.




On 7/17/15, Ignacio Sniechowski <0800nacho at gmail.com> wrote:
> This is a good resource for HyperCard and HyperTalk
>
> http://hypercard.org
>
> cheers
> Nacho
>
>
> *Lic. Ignacio Sniechowski, MBA*
> *Prosavic SRL*
>
> *Tel: (011) 4542-6714*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jul 17, 2015 at 4:11 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
>
>> HyperCard Factoids
>>
>> - The reason that HyperCard failed to support color for many years was
>> that the project leader was color blind and could not see using all those
>> extra bits just to support color. [Someone at Apple told me this, I
>> forget
>> who.]
>>
>> - The original Myst was developed & deployed using HyperCard. [I found
>> this out from Robyn and Rand Miller when they visited Apple.]
>>
>> FYI,
>> -KenD
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StackInDynaBookJunior.gif
Type: image/gif
Size: 55598 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150717/e0b2194d/attachment-0004.gif>

From edgardec2005 at gmail.com  Sat Jul 18 05:55:16 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Sat, 18 Jul 2015 07:55:16 -0300
Subject: [Cuis] [OT] HyperCard
In-Reply-To: <CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55A146FC.4020402@jvuletich.org>
	<6C2C49D9-CD48-4FEC-A427-7882F06DE8C3@gmail.com>
	<55A7A6E1.8000909@jvuletich.org>
	<CAGQxfVjqN72vKudD639DFjaQn_2J5xwp=jFWxy_9JYn8TvCTjA@mail.gmail.com>
	<E772B770227A414C8E4912293F62ED5A@gmail.com>
	<20150717121102.384b0bdef75caa46a39a03fe@whidbey.com>
	<CAMCzT-awG+1x8a4dBw4rcUt0fEci2_4r83eXG1NtOz05ggBHvw@mail.gmail.com>
Message-ID: <40788499-8CB3-4134-97A2-FE1EFA13598F@gmail.com>


> On Jul 17, 2015, at 4:37 PM, Ignacio Sniechowski <0800nacho at gmail.com> wrote:
> 
> This is a good resource for HyperCard and HyperTalk
> 
> http://hypercard.org <http://hypercard.org/>

Ignacio beats me.

But I download Stacksmith and CinsImp
Seems https://github.com/uliwitness/Stacksmith <https://github.com/uliwitness/Stacksmith> and http://hammer-language.com/ <http://hammer-language.com/> should be the docs to read.

Excited !!!

Edgar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150718/2cf88a47/attachment-0004.html>

From dnorton at mindspring.com  Sat Jul 18 13:33:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 14:33:35 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <20150710165144.ece0f54787132fed1278bdc4@whidbey.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A0178E.16257.13666A4@dnorton.mindspring.com>,
	<20150710165144.ece0f54787132fed1278bdc4@whidbey.com>
Message-ID: <55AA9BFF.3085.11B851C@dnorton.mindspring.com>

On 10 Jul 2015 at 16:51, Ken.Dickey wrote:

> On Fri, 10 Jul 2015 15:05:50 -0400
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> > Yes, the only font now is DejaVu and it's a bitmap font. I found
> some fixed bitmap fonts 
> > among the true types at:
> > 
> > http://www.lowing.org/fonts/
> > 
> > Adding a sublcass to AbstractFont to load one of these might be
> doable near-term until 
> > Morphic 3 comes along. Porting TrueType from Squeak has a lot of
> drag.
> 
> My Cuis-Smalltalk-Unicode package subclasses AbstractFont and
> provides fixed width characters.
> 
> See class #UniForms 
> 
> Unicode is kinda big, memory wise.  I suspect one should be able to
> take the ASCII subset of the Unicode glyphs and make a strike font
> -- or just do what I did for Unicode, but just use the ASCII
> subset.
> 
> FYI,
> -KenD

That is awesome, Ken.

 - Dan



From dnorton at mindspring.com  Sat Jul 18 13:37:16 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 14:37:16 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A146FC.4020402@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A146FC.4020402@jvuletich.org>
Message-ID: <55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>

On 11 Jul 2015 at 13:40, Juan Vuletich wrote:

> Hi Folks,
> 
> It is not too hard to build new StrikeFonts. You need to build, by
> hand, 
> files like the ones in here: 
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> p 
> and learn a bit about stuff like #installDejaVu2 . Maybe it was with
> this method and the files in this zip that built the existing
> instances 
> of StrikeFont. Not sure.
> 

That's intrigueing but I can't reproduce it. Maybe the .bmp but where did you get the .txt?

 - Dan



From dnorton at mindspring.com  Sat Jul 18 13:56:46 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 14:56:46 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A14859.2080409@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A0178E.16257.13666A4@dnorton.mindspring.com>,
	<55A14859.2080409@jvuletich.org>
Message-ID: <55AAA16E.24887.130BE16@dnorton.mindspring.com>

On 11 Jul 2015 at 13:46, Juan Vuletich wrote:

> On 7/10/2015 4:05 PM, Dan Norton wrote:
> > ...
> > Yes, the only font now is DejaVu and it's a bitmap font. I found
> some fixed bitmap fonts
> > among the true types at:
> >
> > http://www.lowing.org/fonts/
> >
> > Adding a sublcass to AbstractFont to load one of these might be
> doable near-term until
> > Morphic 3 comes along. Porting TrueType from Squeak has a lot of
> drag.
> >
> 
> ProFontWindows doesn't look bad. In any case, I built the Bitmap
> DejaVu 
> fonts in Cuis (and Squeak and Pharo) by capturing the bits from the
> screen of a text editor, running the TTF. You can do the same with
> DejaVu Sans Mono or any other TTF / OTF / whatever.
>

Currently I am porting TrueType. By way of a progress report, drag has been reduced and by 
installing

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

and cmd-d "tt := TTFontReader parseFileNamed:'c:\windows\fonts\cour.ttf'" you have a true 
type instance "tt" which, when explored, bears a strong resemblance to the same thing if 
done on Squeak, according to my eyeballs.

Now to transform(?) convert(?) this font to something which can be added to AvailableFonts 
and used. WIBGI it could be used as is? There are several fixed-width fonts in the .ttf set.

 - Dan



From hannes.hirzel at gmail.com  Sat Jul 18 13:58:53 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 18 Jul 2015 18:58:53 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55A1475D.3030501@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<55A1475D.3030501@jvuletich.org>
Message-ID: <CAGQxfVjJsjkj1BRj_KoKHH4AZsdSDfMFWZ764-L=5rBPqB1k0Q@mail.gmail.com>

On 7/11/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/10/2015 11:20 AM, Dan Norton wrote:
>> ...
>> Browsing through strike fonts, I see no fixed widths. But, true type fonts
>> have a few
>> fixed-width examples. There seems to be no way to install a .ttf in Cuis
>> currently.
>>
>> Can we port TrueType-Support from Squeak?
>>
>> Should there be a sibling of StrikeFont, say TrueTypeFont, which inherits
>> from AbstractFont?
>>
>> Any hints or guidance would be most welcomed.
>>
>
> I'd say, stick to StrikeFonts, and learn to build new ones. I the other
> message I just sent, I included more details.

+1

or copy a strikefont from Squeak. The Squeak wiki has a lot of
material about Strikefont.



> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Sat Jul 18 14:04:18 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 12:04:18 -0700 (PDT)
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AAA16E.24887.130BE16@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
	<55A14859.2080409@jvuletich.org>
	<55AAA16E.24887.130BE16@dnorton.mindspring.com>
Message-ID: <1437246258310-4838103.post@n4.nabble.com>

Correction:

Currently I am porting TrueType. By way of a progress report, drag has been
reduced and by 
installing /the TrueType package from:/

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

etc.



--
View this message in context: http://forum.world.st/Fixed-Width-Font-tp4836695p4838103.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From hannes.hirzel at gmail.com  Sat Jul 18 14:10:52 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 18 Jul 2015 19:10:52 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <1437246258310-4838103.post@n4.nabble.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<D631D3C2-82D5-4E29-95D1-B0E562B9F815@gmail.com>
	<559FD4BD.26551.31649C@dnorton.mindspring.com>
	<1436549341.2325.3.camel@gmail.com>
	<55A0178E.16257.13666A4@dnorton.mindspring.com>
	<55A14859.2080409@jvuletich.org>
	<55AAA16E.24887.130BE16@dnorton.mindspring.com>
	<1437246258310-4838103.post@n4.nabble.com>
Message-ID: <CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>

https://github.com/dhnorton/Cuis-Smalltalk-fonts/blob/master/Graphics-Text.pck.st#L2

says

    "Description A stripped-down package with changes only to
AbstractFont and StrikeFont."

I assume the code is from the current Squeak 4.6?

--HH

On 7/18/15, Dan Norton <dnorton at mindspring.com> wrote:
> Correction:
>
> Currently I am porting TrueType. By way of a progress report, drag has been
> reduced and by
> installing /the TrueType package from:/
>
> https://github.com/dhnorton/Cuis-Smalltalk-fonts
>
> etc.
>
>
>
> --
> View this message in context:
> http://forum.world.st/Fixed-Width-Font-tp4836695p4838103.html
> Sent from the Cuis Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From dnorton at mindspring.com  Sat Jul 18 14:27:25 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 15:27:25 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<1437246258310-4838103.post@n4.nabble.com>,
	<CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
Message-ID: <55AAA89D.29698.14CCC69@dnorton.mindspring.com>

On 18 Jul 2015 at 19:10, H. Hirzel wrote:

> https://github.com/dhnorton/Cuis-Smalltalk-fonts/blob/master/Graphic
> s-Text.pck.st#L2
> 
> says
> 
>     "Description A stripped-down package with changes only to
> AbstractFont and StrikeFont."
> 
> I assume the code is from the current Squeak 4.6?
> 
> --HH
> 

No, Squeak 4.5.

 - Dan



From dnorton at mindspring.com  Sat Jul 18 14:41:19 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 18 Jul 2015 15:41:19 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<1437246258310-4838103.post@n4.nabble.com>,
	<CAGQxfVhZ3z=-jth=zVaM4DNo5_iQj=4qV-HZUqX+roHL7S2m4Q@mail.gmail.com>
Message-ID: <55AAABDF.5892.15986B3@dnorton.mindspring.com>

On 18 Jul 2015 at 19:10, H. Hirzel wrote:

> https://github.com/dhnorton/Cuis-Smalltalk-fonts/blob/master/Graphic
> s-Text.pck.st#L2
> 
> says
> 
>     "Description A stripped-down package with changes only to
> AbstractFont and StrikeFont."
> 
> I assume the code is from the current Squeak 4.6?
> 
> --HH
> 

Actually, the code is from Cuis, now that I take a closer look.

 - Dan



From Ken.Dickey at whidbey.com  Sat Jul 18 23:33:48 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sat, 18 Jul 2015 21:33:48 -0700
Subject: [Cuis] #printStringLimitedTo:
Message-ID: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>

I find it kind of odd that #printStringLimitedTo: takes the prefix of a too-long string and adds '...etc...', which itself is 9 characters.

I think a shorter addition would make more sense.  After all, the string is already too long, right?

I like '[..]' , which is only four characters. 

Would anyone else like to weigh in on this?  Other options?

-KenD



From pbpublist at gmail.com  Sun Jul 19 01:04:59 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 02:04:59 -0400
Subject: [Cuis] #printStringLimitedTo:
In-Reply-To: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>
References: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>
Message-ID: <1437285899.6934.1.camel@gmail.com>

On Sat, 2015-07-18 at 21:33 -0700, Ken.Dickey wrote:
> I find it kind of odd that #printStringLimitedTo: takes the prefix of a too-long string and adds '...etc...', which itself is 9 characters.
> 
> I think a shorter addition would make more sense.  After all, the string is already too long, right?
> 
> I like '[..]' , which is only four characters. 
> 
> Would anyone else like to weigh in on this?  Other options?

I agree that the current suffix is long-ish and like your [..] idea as
that's unlikely to appear in the majority of strings but would still
convey the information.

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





From juan at jvuletich.org  Sun Jul 19 08:31:14 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 19 Jul 2015 10:31:14 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55A146FC.4020402@jvuletich.org>
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
Message-ID: <55ABA6A2.5090607@jvuletich.org>

On 7/18/2015 3:37 PM, Dan Norton wrote:
> On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>
>> Hi Folks,
>>
>> It is not too hard to build new StrikeFonts. You need to build, by
>> hand,
>> files like the ones in here:
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> p
>> and learn a bit about stuff like #installDejaVu2 . Maybe it was with
>> this method and the files in this zip that built the existing
>> instances
>> of StrikeFont. Not sure.
>>
> That's intrigueing but I can't reproduce it. Maybe the .bmp but where did you get the .txt?
>
>   - Dan

I wrote them with a text editor. Check #installDejaVu2 and really try to 
understand how StrikeFonts work and how they are built with this method. 
Maybe you'll become enlightened.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sun Jul 19 09:20:19 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 19 Jul 2015 11:20:19 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437158701.2255.245.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
Message-ID: <55ABB223.8010309@jvuletich.org>

Hi Folks,

(inline)

On 7/17/2015 3:45 PM, Phil (list) wrote:
> ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>> Thank you Juan, for answering.
>>>
>>> At the moment I feel uncomfortable using Cuis because it is currently
>>> a quite fast moving target. I perceive quite a number of API changes
>>> though this might be wrong. But I do not know because there are no
>>> release notes which summarize it.
> I totally feel Hannes' pain having gone through it a few times myself
> over the years.  At the same time, I agree with Ken's point about not
> getting too bogged down in process since we're in the best position
> right now to break things for the better longer term.
>
>> Yes, that's true. Besides, we don't have a specification of what is an
>> API and what is not. So, almost any change can be considered an API change.
> That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
> issue, not specific to Cuis)  I believe it is largely fixable without
> tons of documentation and tests: the use of private (categories or
> method naming convention).  Bernhard pointed out an existing capability
> a few months ago
> http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
> While I personally like the idea of private categories, one of these
> approaches should really be seriously considered.
>
> Other than a few specific examples (i.e. mostly the base data types
> including the Collection and Number class hierarchies which are pretty
> mature and don't change all that much anyway) I would guesstimate that
> <20% (probably closer to 10%) of the methods, and and unknown % of
> classes (a significantly larger fraction though), should even be
> considered public.  If things were indicated as private that would
> accomplish two things:
>
> 1) We could construct some simple tooling (some combination of up-front
> warnings in the editor and/or a lint-type tester after the fact) that
> would allow people to identify problematic calls within their code.
> (i.e. just because it works now doesn't mean it always will if you keep
> calling X, Y, Z...)
>
> 2) It would provide a way for people to know if something needs to be
> discussed.  i.e. 'In class X method Y is private but I need that type of
> functionality' so you would know that there's a need and could consider
> either making it public, and therefore supported, or rethinking its
> implementation if you'd like to offer a better public API solution.

Ok. Doing something along these lines would be great. But please note 
that it is a rather large amount of work. It is not something I'm able 
or willing to do it alone. If you (any of you all, not just Phil) wants 
to start defining the API for any part of the system or optional 
packages, please start doing it and send the changesets to the list. If 
we get this working, I'll start the tools you mention.

<slowly diverging into OT rant>

On the other hand (and please forgive me if this kills a bit of 
momentum), I don't really think we are changing APIs that much. And I 
don't think we'll be doing it any more in the future than we do today, 
at least in the base image. I hope to see most of the activity and 
incompatible changes to happen in optional packages, and affecting 
package dependencies... Mhhh, now that I write this I think that it 
doesn't really go against the idea of defining APIs. Maybe APIs in the 
base image will almost never change or be a problem, but packages should 
provide APIs too... Optional packages will (I hope!) always be 
improving, and new ones will appear all the time.

If all this work, the Cuis will be a lot less about my personal effort 
and coding style, and the packages maintained by each one of us will 
become the main characters in this story. And this will be a very good 
thing. The base image should be about providing a good base for doing 
the really interesting stuff on top...

Let me tell you a bit about how Cuis got started. Many years ago I did 
my thesis on audio/music processing. The I wanted to turn that into a 
novel and fun application for musicians (both pros and anyone willing to 
play with sound). I started to think about how a good GUI for that could 
be, giving the feeling of modifying sound by direct manipulation of it, 
as if it was clay, as if it was visual and not just auditory. Well, that 
was the start of my questioning of the whole GUI business and Morphic 3. 
And it became clear to me that Squeak had turned into something that was 
not the best possible environment to do all this. The idea of "fixing" 
Squeak, and thus make Cuis, was born. So, Cuis was not and end in 
itself, but a means for allowing experimentation, freedom to build 
applications in new styles, etc.

(The idea that Cuis is a truer Smalltalk-80 than Squeak or any other 
came later, as an observation on facts.)

So, when the moment comes when Cuis stabilizes a bit, and interest moves 
to packages and applications built by all us, Cuis will start to fulfill 
its original objective.

</slowly diverging into OT rant>

>> ...
>> The problem, I think, is not identifying well defined Cuis releases. The
>> problem is knowing how updates could affect your code
> By narrowing the scope of what the public API is using private
> designators, this dramatically reduces what you need to be concerned
> with on this front.  It's part of the reason that Apple, Google, and
> even Microsoft are so adamant about public APIs these days.  They dealt
> with the pain of even major developers depending on private APIs for
> decades. It's only been in the last 10 years or so that they've been
> able to dig themselves out from under this issue.
>
> This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
> attitude of 'you have the source, play around, have fun!' has morphed
> into 'everything is a public API!  there are no rules! isn't this
> great?'  Well no, it's not great.  It makes life impossible for image
> maintainers (Squeak has been in a coma for the last decade or so as the
> result of trying to keep everyone happy... yet no one seems to be) and
> miserable for those who are trying to keep code running on it (stuff
> still breaks all the time.)

Yes.

> I personally believe the minimalism and simplicity that Cuis is based on
> has the best long term prospects but we have to get out of this
> 'everything is public' mindset.  Sure, we have all the source: look at
> it, learn from it, poke around, refactor it, submit fixes, etc.  But
> there needs to be a manageable subset of it which is considered the
> 'public API' that people can depend on to write frameworks and apps on
> top of that is relatively stable longer term.  Let's start defining what
> that is and backfill changes to the public API (which will happen from
> time to time as we don't want things to be completely static) with tests
> and documentation so you can focus your efforts on where they matter
> most and you get the most enjoyment from.

I fully agree and support this.
Maybe an alternative to yet-another-convention-on-categories could be to 
mark public methods with a pragma, or make them send 'self publicAPI' or 
such... This could be better for the tools, also.

> ...
>> I don't have that either. I run the tests from time to time (I'll start
>> doing it before any commit, and add the xml report to the rep). But this
>> is not the most important reason why Cuis is solid. Cuis is very
>> reliable because:
> reliable != stable

;)

>> - I'm not too bad as a coder.
>> - I do my own code revisions at least one day after each change.
>> - I use Cuis every day, and spot most problems in the updates, before
>> commtting them to the repo.
>> - I really, really care about code quality.
>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>> is a big responsibility, given how important I think Smalltalk-80 is.
>>
> Agree to all this and more.  Cuis would not be where it is without your
> continued effort and diligence. (i.e. setting aside that you obviously
> created it, if you had just tossed it out into the world and let it go
> at best it would have started looking something like Squeak or Pharo by
> now.  It's a lot of effort over the long term to *keep* it small and
> focused.  THANK YOU JUAN!)

Thanks for your nice words, Phil. I really appreciate that you all 
accept this rather restrictive dev model for the base image, in contrast 
with a more open trunk style. Hopefully, as the base image becomes 
stable and almost irrelevant, this will be each time less of a problem.

>> So, I suggest running your tests when updating your image, or migrating
>> your code to an updated image.
> +1 to tests as they do help quite a bit and are a very good practice.
> Just be judicious in what/where you test (I personally don't subscribe
> to the TDD approach where you spend your days mostly writing tests.
> That's just admitting defeat in that you spend all day writing
> executable documentation.)

<OT>

I don't subscribe to "extreme" TDD either. To me design is a creative 
activity, both technical and artistic. It should be "driven" by 
creativity and intelligence, not by a process. Any xDD process is 
admitting defeat on design itself!

</OT>

>> In any case, I think this doesn't answer your concerns. What you need is
>> some way to know which updates could affect you, to review them in
>> detail, and understanding their effect on your code. A list of the
>> affected classes and/or methods for each update makes no sense. Cuis can
>> already show you that very easily. Perhaps each update should include:
>>
>> 1) parts of the system that are affected:
>> - Kernel
>> - Compiler
>> - Tools
>> - Morphic
>> - etc
>>
>> 2) Level of risk involved
>> - very unlikely to break code that depends on this part of the system
>> - could perhaps break code that depends on this part of the system
>> - will most likely break code that depends on this part of the system
>>
>> Or something like that.
>>
>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>> free to answer there if you agree.
> One final thought on this:  I suspect a major cause of people abandoning
> Cuis (and Smalltalk in general), behind the 'it's too different from
> what I'm used to'/'not mainstream' reaction, is the instability of its
> APIs.

Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) 
is a PITA too...

As a bottom line, let me repeat: This is too big for me to do it. 
Please, folks, start documenting the APIs you most care about.

Cheers,
Juan Vuletich



From peter at aba-instituut.nl  Sun Jul 19 11:02:20 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Sun, 19 Jul 2015 18:02:20 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55ABB223.8010309@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
Message-ID: <CAJBxtBY7YtLCJwVSOM3w58shed-YcnON=BL2WD2xM6EAMVbn2A@mail.gmail.com>

Hey all,

Just 2 cents from a Cuis noob:

1. Releases... since this stuff is not being sold for money and not being
distributed using off-line media, what use does a "release" have? I like
that stuff gets improved as often as possible. I believe that the things
that get improved the most often, have the best chance of becoming
something really good.

So, I am for adopting practices that increase the number of improvements.
Practices that decrease the number of deteriorations seem helpful as well.
See below if you wonder what my point is ;-).

2. Public vs private API. Stable APIs are nice, if you can get them. If you
have authors who develop a base, and other authors who (have to) develop ON
that base, you need stable APIs, or you will lose the authors dependent on
your base.

So, do we really have those different author groups? Somehow I doubt it. I
recently changed the scoping rules for shared variables (I think they're
done wrong in the base image). I could change what I wanted easily. So I
think I am not in some outsider author group. Instead I am happy that I
could change what I wanted without needing anyone's approval or cooperation.

Suppose we were making money from outside author groups who want us to keep
certain APIs stable. For the right price, I would be happy to provide that
for them. In the mean time, I can live with free. Free to change what I
want, free to use without paying, and others free to change what I am
building on (sometimes frustrating).

3. Maybe what will help everybody is something that prevents functionality
from being lost, especially *unintentionally*. This can include certain
APIs as well. So what if an author who values a certain API, could invest
some of his own time/money, to protect that API? What if he could write a
software component (let's say a class) that was able to detect whenever an
image did not provide the desired API? What if he could submit that class,
and everybody who cared about not breaking that API, could use that class
to see if perhaps they broke it?

4. I believe the idea could be generalized to include any feature of (the
code in) an image for which presence or absence (as may be the case) can be
determined by such a class. Bugs could be reified as classes, and the
presence or absence of the bug could be determined by that class. Feature
requests could be reified as classes, and whether or not the feature had
actually been implemented could be determined by that class.

5. The things I am proposing would basically be Feature Tests, and would be
rather different from Unit Tests (which apply to a unit and which you want
to all be green when you share your software with users of it). Feature
Tests would apply to a system (not a unit) and simply indicate which
features are and which features are not present in the system. Every
"release" could then come with a) the assertion that all the Unit Tests
passed b) a list of the Feature Tests that passed and those that did not.

6. I think it would be pretty cool if people sent in feature requests in
the form of Feature Tests, instead of messages to the mailing list (or the
request tracker). So that anybody who (wished to impress somebody and) had
some time on their hands, could then try to implement the functionality
that made the Feature Test pass.

Hope this helps somebody with something :)

Cheers, Peter

On Sun, Jul 19, 2015 at 4:20 PM, Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Folks,
>
> (inline)
>
> On 7/17/2015 3:45 PM, Phil (list) wrote:
>
>> ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>
>>> Thank you Juan, for answering.
>>>>
>>>> At the moment I feel uncomfortable using Cuis because it is currently
>>>> a quite fast moving target. I perceive quite a number of API changes
>>>> though this might be wrong. But I do not know because there are no
>>>> release notes which summarize it.
>>>>
>>> I totally feel Hannes' pain having gone through it a few times myself
>> over the years.  At the same time, I agree with Ken's point about not
>> getting too bogged down in process since we're in the best position
>> right now to break things for the better longer term.
>>
>>  Yes, that's true. Besides, we don't have a specification of what is an
>>> API and what is not. So, almost any change can be considered an API
>>> change.
>>>
>> That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
>> issue, not specific to Cuis)  I believe it is largely fixable without
>> tons of documentation and tests: the use of private (categories or
>> method naming convention).  Bernhard pointed out an existing capability
>> a few months ago
>> http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
>> While I personally like the idea of private categories, one of these
>> approaches should really be seriously considered.
>>
>> Other than a few specific examples (i.e. mostly the base data types
>> including the Collection and Number class hierarchies which are pretty
>> mature and don't change all that much anyway) I would guesstimate that
>> <20% (probably closer to 10%) of the methods, and and unknown % of
>> classes (a significantly larger fraction though), should even be
>> considered public.  If things were indicated as private that would
>> accomplish two things:
>>
>> 1) We could construct some simple tooling (some combination of up-front
>> warnings in the editor and/or a lint-type tester after the fact) that
>> would allow people to identify problematic calls within their code.
>> (i.e. just because it works now doesn't mean it always will if you keep
>> calling X, Y, Z...)
>>
>> 2) It would provide a way for people to know if something needs to be
>> discussed.  i.e. 'In class X method Y is private but I need that type of
>> functionality' so you would know that there's a need and could consider
>> either making it public, and therefore supported, or rethinking its
>> implementation if you'd like to offer a better public API solution.
>>
>
> Ok. Doing something along these lines would be great. But please note that
> it is a rather large amount of work. It is not something I'm able or
> willing to do it alone. If you (any of you all, not just Phil) wants to
> start defining the API for any part of the system or optional packages,
> please start doing it and send the changesets to the list. If we get this
> working, I'll start the tools you mention.
>
> <slowly diverging into OT rant>
>
> On the other hand (and please forgive me if this kills a bit of momentum),
> I don't really think we are changing APIs that much. And I don't think
> we'll be doing it any more in the future than we do today, at least in the
> base image. I hope to see most of the activity and incompatible changes to
> happen in optional packages, and affecting package dependencies... Mhhh,
> now that I write this I think that it doesn't really go against the idea of
> defining APIs. Maybe APIs in the base image will almost never change or be
> a problem, but packages should provide APIs too... Optional packages will
> (I hope!) always be improving, and new ones will appear all the time.
>
> If all this work, the Cuis will be a lot less about my personal effort and
> coding style, and the packages maintained by each one of us will become the
> main characters in this story. And this will be a very good thing. The base
> image should be about providing a good base for doing the really
> interesting stuff on top...
>
> Let me tell you a bit about how Cuis got started. Many years ago I did my
> thesis on audio/music processing. The I wanted to turn that into a novel
> and fun application for musicians (both pros and anyone willing to play
> with sound). I started to think about how a good GUI for that could be,
> giving the feeling of modifying sound by direct manipulation of it, as if
> it was clay, as if it was visual and not just auditory. Well, that was the
> start of my questioning of the whole GUI business and Morphic 3. And it
> became clear to me that Squeak had turned into something that was not the
> best possible environment to do all this. The idea of "fixing" Squeak, and
> thus make Cuis, was born. So, Cuis was not and end in itself, but a means
> for allowing experimentation, freedom to build applications in new styles,
> etc.
>
> (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other came
> later, as an observation on facts.)
>
> So, when the moment comes when Cuis stabilizes a bit, and interest moves
> to packages and applications built by all us, Cuis will start to fulfill
> its original objective.
>
> </slowly diverging into OT rant>
>
>  ...
>>> The problem, I think, is not identifying well defined Cuis releases. The
>>> problem is knowing how updates could affect your code
>>>
>> By narrowing the scope of what the public API is using private
>> designators, this dramatically reduces what you need to be concerned
>> with on this front.  It's part of the reason that Apple, Google, and
>> even Microsoft are so adamant about public APIs these days.  They dealt
>> with the pain of even major developers depending on private APIs for
>> decades. It's only been in the last 10 years or so that they've been
>> able to dig themselves out from under this issue.
>>
>> This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
>> attitude of 'you have the source, play around, have fun!' has morphed
>> into 'everything is a public API!  there are no rules! isn't this
>> great?'  Well no, it's not great.  It makes life impossible for image
>> maintainers (Squeak has been in a coma for the last decade or so as the
>> result of trying to keep everyone happy... yet no one seems to be) and
>> miserable for those who are trying to keep code running on it (stuff
>> still breaks all the time.)
>>
>
> Yes.
>
>  I personally believe the minimalism and simplicity that Cuis is based on
>> has the best long term prospects but we have to get out of this
>> 'everything is public' mindset.  Sure, we have all the source: look at
>> it, learn from it, poke around, refactor it, submit fixes, etc.  But
>> there needs to be a manageable subset of it which is considered the
>> 'public API' that people can depend on to write frameworks and apps on
>> top of that is relatively stable longer term.  Let's start defining what
>> that is and backfill changes to the public API (which will happen from
>> time to time as we don't want things to be completely static) with tests
>> and documentation so you can focus your efforts on where they matter
>> most and you get the most enjoyment from.
>>
>
> I fully agree and support this.
> Maybe an alternative to yet-another-convention-on-categories could be to
> mark public methods with a pragma, or make them send 'self publicAPI' or
> such... This could be better for the tools, also.
>
>  ...
>>
>>> I don't have that either. I run the tests from time to time (I'll start
>>> doing it before any commit, and add the xml report to the rep). But this
>>> is not the most important reason why Cuis is solid. Cuis is very
>>> reliable because:
>>>
>> reliable != stable
>>
>
> ;)
>
>  - I'm not too bad as a coder.
>>> - I do my own code revisions at least one day after each change.
>>> - I use Cuis every day, and spot most problems in the updates, before
>>> commtting them to the repo.
>>> - I really, really care about code quality.
>>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>>> is a big responsibility, given how important I think Smalltalk-80 is.
>>>
>>>  Agree to all this and more.  Cuis would not be where it is without your
>> continued effort and diligence. (i.e. setting aside that you obviously
>> created it, if you had just tossed it out into the world and let it go
>> at best it would have started looking something like Squeak or Pharo by
>> now.  It's a lot of effort over the long term to *keep* it small and
>> focused.  THANK YOU JUAN!)
>>
>
> Thanks for your nice words, Phil. I really appreciate that you all accept
> this rather restrictive dev model for the base image, in contrast with a
> more open trunk style. Hopefully, as the base image becomes stable and
> almost irrelevant, this will be each time less of a problem.
>
>  So, I suggest running your tests when updating your image, or migrating
>>> your code to an updated image.
>>>
>> +1 to tests as they do help quite a bit and are a very good practice.
>> Just be judicious in what/where you test (I personally don't subscribe
>> to the TDD approach where you spend your days mostly writing tests.
>> That's just admitting defeat in that you spend all day writing
>> executable documentation.)
>>
>
> <OT>
>
> I don't subscribe to "extreme" TDD either. To me design is a creative
> activity, both technical and artistic. It should be "driven" by creativity
> and intelligence, not by a process. Any xDD process is admitting defeat on
> design itself!
>
> </OT>
>
>  In any case, I think this doesn't answer your concerns. What you need is
>>> some way to know which updates could affect you, to review them in
>>> detail, and understanding their effect on your code. A list of the
>>> affected classes and/or methods for each update makes no sense. Cuis can
>>> already show you that very easily. Perhaps each update should include:
>>>
>>> 1) parts of the system that are affected:
>>> - Kernel
>>> - Compiler
>>> - Tools
>>> - Morphic
>>> - etc
>>>
>>> 2) Level of risk involved
>>> - very unlikely to break code that depends on this part of the system
>>> - could perhaps break code that depends on this part of the system
>>> - will most likely break code that depends on this part of the system
>>>
>>> Or something like that.
>>>
>>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>>> free to answer there if you agree.
>>>
>> One final thought on this:  I suspect a major cause of people abandoning
>> Cuis (and Smalltalk in general), behind the 'it's too different from
>> what I'm used to'/'not mainstream' reaction, is the instability of its
>> APIs.
>>
>
> Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) is
> a PITA too...
>
> As a bottom line, let me repeat: This is too big for me to do it. Please,
> folks, start documenting the APIs you most care about.
>
> 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/20150719/8e5a281b/attachment-0004.html>

From hannes.hirzel at gmail.com  Sun Jul 19 14:48:04 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 19:48:04 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <55A90799.7080302@jvuletich.org>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
Message-ID: <CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>

If I use this to find out which methods have a time stamp date
indicating a change after the 1st of January 2015 in a pristine Cuis
4.2-2243 (17 April 2015) image I find out that only the

#postCopy method was changed (probably added) in nearly all classes.

If I change the base line date to 1st of January 2014 I get

a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy #at:ifAbsent:)
as changed/updated methods (i.e. methods which have a time stamp in
this period).

Of course this assumes that a method gets a time stamp when changed.
Many methods have nil as a time stamp.


Could somebody from the list check this please?


|date coll baseLineDate dt  updatedMethods |

baseLineDate := Date year: 2014 month: 1 day: 1.
coll := OrderedCollection new.

Smalltalk allClasses do: [ :cls |
cls allSelectors do: [ :sel |
dt := VersionsBrowser timeStampFor:  sel class: Dictionary reverseOrdinal:  1.

dt notNil ifTrue: [
date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
]) or: [ch = $:]] .
(date = '') ifFalse:
	[date := Date fromString: date.
		(date > baseLineDate) ifTrue: [coll add: (Association key:
(Association key: cls value: sel) value: date)
]]].

]].

updatedMethods := Set new.
coll do: [ :elem | updatedMethods add: (elem key value)].
coll inspect.
updatedMethods inspect




On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/16/2015 11:49 AM, H. Hirzel wrote:
>> Hello
>>
>> I'd like to do a query finding out about the time stamp of  source
>> code changes of all methods in the Cuis image and then do a list with
>> the following four columns
>>
>>
>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
>> DateOfChange
>>
>> Help is appreciated.
>>
>> Hannes
>
> Check #timeStampFor:class:reverseOrdinal: and in general
> #annotationForSelector:ofClass:
>
> Cheers,
> Juan Vuletich
>



From Ken.Dickey at whidbey.com  Sun Jul 19 15:18:38 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sun, 19 Jul 2015 13:18:38 -0700
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55ABB223.8010309@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
Message-ID: <20150719131838.7d00ce57192818d00c38262c@whidbey.com>

On Sun, 19 Jul 2015 11:20:19 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> As a bottom line, let me repeat: This is too big for me to do it. 
> Please, folks, start documenting the APIs you most care about.

Let me repeat, "you don't have to do it".

I'd like to propose a simpler model based on the Smalltalk Way.

We take any stable revision, call it a version, give it a Baseline Version Number (could be just the development version number).  Each Baseline Release has a release document which describes major changes since the previous baseline.  This document is a light-weight description.

Each baseline release starts a new fork.  The only changes to the particular baseline release are bug fixes.

Nice users test their packages and likewise fork a Package Release which matches a Baseline Release.  This fork also only changes with bug fixes, and only in synch with its particular baseline.  Baseline packages Feature the baseline release.

So we forge ahead as usual, once in a while we say "enough has changed that we should re-baseline", do a new Baseline Release, test and release our Package Releases, then again move on forward.

Anyone can now pick any baseline release, require any associated packages, and ship/demo without fear.

Anyone with the time, energy, and interest can document baseline APIs to whatever level they feel comfortable.

Anyone can forge on ahead with the latest revision(s) with the usual "here be dragons, but also gold".

$0.02
-KenD



From hannes.hirzel at gmail.com  Sun Jul 19 15:21:09 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 20:21:09 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
Message-ID: <CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>

If I take a current image (18 Jul 2015, 4.2-2424)  I get the same result


a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy #at:ifAbsent:)

All the FileMan additions are not listed. Maybe because they keep
their original time stamp, not the time stamp of the addition to
Squeak.

And the recent change on #compilerClass does not show up.

--HH

On 7/19/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> If I use this to find out which methods have a time stamp date
> indicating a change after the 1st of January 2015 in a pristine Cuis
> 4.2-2243 (17 April 2015) image I find out that only the
>
> #postCopy method was changed (probably added) in nearly all classes.
>
> If I change the base line date to 1st of January 2014 I get
>
> a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
> #at:ifAbsent:)
> as changed/updated methods (i.e. methods which have a time stamp in
> this period).
>
> Of course this assumes that a method gets a time stamp when changed.
> Many methods have nil as a time stamp.
>
>
> Could somebody from the list check this please?
>
>
> |date coll baseLineDate dt  updatedMethods |
>
> baseLineDate := Date year: 2014 month: 1 day: 1.
> coll := OrderedCollection new.
>
> Smalltalk allClasses do: [ :cls |
> cls allSelectors do: [ :sel |
> dt := VersionsBrowser timeStampFor:  sel class: Dictionary reverseOrdinal:
> 1.
>
> dt notNil ifTrue: [
> date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
> ]) or: [ch = $:]] .
> (date = '') ifFalse:
> 	[date := Date fromString: date.
> 		(date > baseLineDate) ifTrue: [coll add: (Association key:
> (Association key: cls value: sel) value: date)
> ]]].
>
> ]].
>
> updatedMethods := Set new.
> coll do: [ :elem | updatedMethods add: (elem key value)].
> coll inspect.
> updatedMethods inspect
>
>
>
>
> On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
>> On 7/16/2015 11:49 AM, H. Hirzel wrote:
>>> Hello
>>>
>>> I'd like to do a query finding out about the time stamp of  source
>>> code changes of all methods in the Cuis image and then do a list with
>>> the following four columns
>>>
>>>
>>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
>>> DateOfChange
>>>
>>> Help is appreciated.
>>>
>>> Hannes
>>
>> Check #timeStampFor:class:reverseOrdinal: and in general
>> #annotationForSelector:ofClass:
>>
>> Cheers,
>> Juan Vuletich
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis compilerClass Screenshot from 2015-07-19 20:18:32.png
Type: image/png
Size: 33713 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150719/16f947f7/attachment-0004.png>

From hannes.hirzel at gmail.com  Sun Jul 19 15:50:18 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 20:50:18 +0000
Subject: [Cuis] API descriptions in form of an external package / Feature
	tests?
Message-ID: <CAGQxfViw4j2cvFUBf-0G_TE_e3cBi0=r8=d8YXacB4B4vv-zQw@mail.gmail.com>

Hello Peter

I think your proposal to check the presence of an API is very interesting.

You suggest to have API descriptions in form of classes in an external
package which test the presence of an API.

Contrariwise to unit tests they only look for the presence of a
classes with certain methods.

It is an external tool (i.e. not included in the core) to check the
presence or absence of an API.

These tools can focus on a certain part of the system which is of a
particular interest for an external package and be kept with that
package.

--Hannes


On 7/19/15, Peter van Rooijen <peter at aba-instituut.nl> wrote:
> Hey all,
>
> Just 2 cents from a Cuis noob:
>
...
>

A. Increase the number of improvements

> So, I am for adopting practices that increase the number of improvements.


B. Decrease the number of deterioations

> Practices that decrease the number of deteriorations seem helpful as well.
> See below if you wonder what my point is ;-).
>
...

> 3. Maybe what will help everybody is something that prevents functionality
> from being lost, especially *unintentionally*. This can include certain
> APIs as well. So what if an author who values a certain API, could invest
> some of his own time/money, to protect that API? What if he could write a
> software component (let's say a class) that was able to detect whenever an
> image did not provide the desired API? What if he could submit that class,
> and everybody who cared about not breaking that API, could use that class
> to see if perhaps they broke it?
>
> 4. I believe the idea could be generalized to include any feature of (the
> code in) an image for which presence or absence (as may be the case) can be
> determined by such a class. Bugs could be reified as classes, and the
> presence or absence of the bug could be determined by that class. Feature
> requests could be reified as classes, and whether or not the feature had
> actually been implemented could be determined by that class.
>
> 5. The things I am proposing would basically be Feature Tests, and would be
> rather different from Unit Tests (which apply to a unit and which you want
> to all be green when you share your software with users of it). Feature
> Tests would apply to a system (not a unit) and simply indicate which
> features are and which features are not present in the system. Every
> "release" could then come with a) the assertion that all the Unit Tests
> passed b) a list of the Feature Tests that passed and those that did not.
>
> 6. I think it would be pretty cool if people sent in feature requests in
> the form of Feature Tests, instead of messages to the mailing list (or the
> request tracker). So that anybody who (wished to impress somebody and) had
> some time on their hands, could then try to implement the functionality
> that made the Feature Test pass.



From hannes.hirzel at gmail.com  Sun Jul 19 15:53:27 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 20:53:27 +0000
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150719131838.7d00ce57192818d00c38262c@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
Message-ID: <CAGQxfVgj4-zOZazpQcB8hhy_cikBCMJqU0iTPNLZqNZMrC-23A@mail.gmail.com>

KenD

I like your proposal. And earlier you suggested to have one of these
base line versions per year.

--Hannes

On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Sun, 19 Jul 2015 11:20:19 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
>
>> As a bottom line, let me repeat: This is too big for me to do it.
>> Please, folks, start documenting the APIs you most care about.
>
> Let me repeat, "you don't have to do it".
>
> I'd like to propose a simpler model based on the Smalltalk Way.
>
> We take any stable revision, call it a version, give it a Baseline Version
> Number (could be just the development version number).  Each Baseline
> Release has a release document which describes major changes since the
> previous baseline.  This document is a light-weight description.
>
> Each baseline release starts a new fork.  The only changes to the particular
> baseline release are bug fixes.
>
> Nice users test their packages and likewise fork a Package Release which
> matches a Baseline Release.  This fork also only changes with bug fixes, and
> only in synch with its particular baseline.  Baseline packages Feature the
> baseline release.
>
> So we forge ahead as usual, once in a while we say "enough has changed that
> we should re-baseline", do a new Baseline Release, test and release our
> Package Releases, then again move on forward.
>
> Anyone can now pick any baseline release, require any associated packages,
> and ship/demo without fear.
>
> Anyone with the time, energy, and interest can document baseline APIs to
> whatever level they feel comfortable.
>
> Anyone can forge on ahead with the latest revision(s) with the usual "here
> be dragons, but also gold".
>
> $0.02
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Sun Jul 19 16:01:17 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 21:01:17 +0000
Subject: [Cuis] Scoping rules for shared variables ?
Message-ID: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>

On 7/19/15, Peter van Rooijen <peter at aba-instituut.nl> wrote:
....
 I
> recently changed the scoping rules for shared variables (I think they're
> done wrong in the base image). I could change what I wanted easily. So I
> think I am not in some outsider author group. Instead I am happy that I
> could change what I wanted without needing anyone's approval or
> cooperation.

A note:
This applies to any version / distribution of Smalltalk. But it means
that you have your own version of the core system.

Could you elaborate on the issue of the shared variables, maybe it is
something to include in the core Cuis image?

--Hannes



From pbpublist at gmail.com  Sun Jul 19 16:38:25 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 17:38:25 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55ABB223.8010309@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
Message-ID: <1437341905.6934.99.camel@gmail.com>

On Sun, 2015-07-19 at 11:20 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> (inline)
> 
> On 7/17/2015 3:45 PM, Phil (list) wrote:
> > ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
> >>> Thank you Juan, for answering.
> >>>
> >>> At the moment I feel uncomfortable using Cuis because it is currently
> >>> a quite fast moving target. I perceive quite a number of API changes
> >>> though this might be wrong. But I do not know because there are no
> >>> release notes which summarize it.
> > I totally feel Hannes' pain having gone through it a few times myself
> > over the years.  At the same time, I agree with Ken's point about not
> > getting too bogged down in process since we're in the best position
> > right now to break things for the better longer term.
> >
> >> Yes, that's true. Besides, we don't have a specification of what is an
> >> API and what is not. So, almost any change can be considered an API change.
> > That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
> > issue, not specific to Cuis)  I believe it is largely fixable without
> > tons of documentation and tests: the use of private (categories or
> > method naming convention).  Bernhard pointed out an existing capability
> > a few months ago
> > http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
> > While I personally like the idea of private categories, one of these
> > approaches should really be seriously considered.
> >
> > Other than a few specific examples (i.e. mostly the base data types
> > including the Collection and Number class hierarchies which are pretty
> > mature and don't change all that much anyway) I would guesstimate that
> > <20% (probably closer to 10%) of the methods, and and unknown % of
> > classes (a significantly larger fraction though), should even be
> > considered public.  If things were indicated as private that would
> > accomplish two things:
> >
> > 1) We could construct some simple tooling (some combination of up-front
> > warnings in the editor and/or a lint-type tester after the fact) that
> > would allow people to identify problematic calls within their code.
> > (i.e. just because it works now doesn't mean it always will if you keep
> > calling X, Y, Z...)
> >
> > 2) It would provide a way for people to know if something needs to be
> > discussed.  i.e. 'In class X method Y is private but I need that type of
> > functionality' so you would know that there's a need and could consider
> > either making it public, and therefore supported, or rethinking its
> > implementation if you'd like to offer a better public API solution.
> 
> Ok. Doing something along these lines would be great. But please note 
> that it is a rather large amount of work. It is not something I'm able 
> or willing to do it alone. If you (any of you all, not just Phil) wants 
> to start defining the API for any part of the system or optional 
> packages, please start doing it and send the changesets to the list. If 
> we get this working, I'll start the tools you mention.
> 

Agreed that this is a lot of work and I definitely wasn't expecting you
to do it (other than reviewing the work for approval/rejection.)  I'll
be happy to work on this with anyone else who is interested.

> <slowly diverging into OT rant>
> 
> On the other hand (and please forgive me if this kills a bit of 
> momentum), I don't really think we are changing APIs that much. And I 
> don't think we'll be doing it any more in the future than we do today, 
> at least in the base image. I hope to see most of the activity and 
> incompatible changes to happen in optional packages, and affecting 
> package dependencies... Mhhh, now that I write this I think that it 
> doesn't really go against the idea of defining APIs. Maybe APIs in the 
> base image will almost never change or be a problem, but packages should 
> provide APIs too... Optional packages will (I hope!) always be 
> improving, and new ones will appear all the time.
> 

You'd likely be very surprised.  I'd say there's usually at least a
couple changes a month that breaks something, somewhere in my code.  A
few recent examples that have been discussed on the list: removing clone
broke OpenGL a bit (easy fix thanks to the on-list discussion), removing
compilerClass killed OMeta, a while back you were considering removing
storeString which would again break OMeta. etc. (that's just a few
things off the top of my head from the last few months and note that all
were probably considered minor, inconsequential changes)  However the
issue snowballs quickly if one misses a few updates and some of the
breakage is related to changes that weren't discussed on the list or
otherwise documented.  I've been managing through this recently (the
last 6 months or so) by upgrading my image very quickly after you commit
changes but I doubt most people would be able / willing to have that
level of diligence.

A lot of this breakage is no one's 'fault', it's just how a lot of
Smalltalk code has been historically written.  Two examples of how this
happens:

1) For ports of existing code, you're subject to the whims of the
original author who often used techniques described in the next item to
write their code.  And of course, code coming from Squeak/Pharo means
that there were often 10 or more possible ways they could have
implemented parts of their solution.  So after porting a few different
packages, you have several different approaches to the same kinds of
problems.

2) For one's own code because there is currently no distinction between
public and private, you tend to go either with what you already know or
whatever the first thing you find poking around the image that appears
to make sense and work.  Even in Cuis, there are still usually multiple
ways to do most things, so you end up arbitrarily picking one or two
that you like.  As a result, you quickly end up with a potpourri of
calls that may or may not be the best way to do things.  Over time, you
start building new code on top of this code and quickly end up with a
house of cards that comes crashing down as the result of a subsequent
image update.  Again, this often results in each of us as authors
deciding on superficially different solutions to the same problems.

I'm not expecting you to not do things that might break my, or anyone
else's code, going forward.  Like Hannes, I'm just looking for ways to
help manage through the changes and breakage.  One of the key aspects of
this is to have an opinion and to say 'hey, here are the one or two ways
we should be doing this'.  There may be disagreement and discussion as
to what those one or two ways are, but at the end of the day we need to
settle these issues so that both your and our lives are manageable.
That's really the main thing that a public API is, IMO.  There may be
all sorts of internal helper methods and implementation details needed
to make it all work, but like the cells of a living organism, these
details should be hidden and their use discouraged.  Hey, didn't someone
say something along those lines once? :-)
 
> If all this work, the Cuis will be a lot less about my personal effort 
> and coding style, and the packages maintained by each one of us will 
> become the main characters in this story. And this will be a very good 
> thing. The base image should be about providing a good base for doing 
> the really interesting stuff on top...
> 

I both agree (that the packages become more important) and disagree
(that Cuis fades into the background).  I still view the core Cuis image
as the philosophical and stylistic backbone that all of my stuff is
based on.  It's a constant reminder to clean up and get rid of as much
cruft as possible in my code (especially for the packages that have yet
other packages dependent on them)  I freely admit that I am mostly
falling short in my execution on this front, but it would be easy to
lose sight of entirely if Cuis didn't stay the course.

> Let me tell you a bit about how Cuis got started. Many years ago I did 
> my thesis on audio/music processing. The I wanted to turn that into a 
> novel and fun application for musicians (both pros and anyone willing to 
> play with sound). I started to think about how a good GUI for that could 
> be, giving the feeling of modifying sound by direct manipulation of it, 
> as if it was clay, as if it was visual and not just auditory. Well, that 
> was the start of my questioning of the whole GUI business and Morphic 3. 
> And it became clear to me that Squeak had turned into something that was 
> not the best possible environment to do all this. The idea of "fixing" 
> Squeak, and thus make Cuis, was born. So, Cuis was not and end in 
> itself, but a means for allowing experimentation, freedom to build 
> applications in new styles, etc.
> 
> (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other 
> came later, as an observation on facts.)
> 
> So, when the moment comes when Cuis stabilizes a bit, and interest moves 
> to packages and applications built by all us, Cuis will start to fulfill 
> its original objective.
> 

It's already this is as far as I'm concerned.  I can't tell you much
time I burned just trying to extract OpenGL from Croquet so that I could
load it into Squeak, for example.  It was painful on both sides, and by
the time I was done I had to think for a bit to remind myself what my
original objective was... I have *never* had this issue with Cuis.

It is absolutely enabling me to play around with ideas and build things
that I couldn't have / wouldn't have bothered in Squeak.  The only issue
I'm having is that once I've built it, I want to keep it running :-)

> </slowly diverging into OT rant>

Not at all a rant as it reaffirms *why* you're doing what you're doing.
If you lost sight of that, that's when I'd start worrying about Cuis.

> 
> >> ...
> >> The problem, I think, is not identifying well defined Cuis releases. The
> >> problem is knowing how updates could affect your code
> > By narrowing the scope of what the public API is using private
> > designators, this dramatically reduces what you need to be concerned
> > with on this front.  It's part of the reason that Apple, Google, and
> > even Microsoft are so adamant about public APIs these days.  They dealt
> > with the pain of even major developers depending on private APIs for
> > decades. It's only been in the last 10 years or so that they've been
> > able to dig themselves out from under this issue.
> >
> > This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
> > attitude of 'you have the source, play around, have fun!' has morphed
> > into 'everything is a public API!  there are no rules! isn't this
> > great?'  Well no, it's not great.  It makes life impossible for image
> > maintainers (Squeak has been in a coma for the last decade or so as the
> > result of trying to keep everyone happy... yet no one seems to be) and
> > miserable for those who are trying to keep code running on it (stuff
> > still breaks all the time.)
> 
> Yes.
> 
> > I personally believe the minimalism and simplicity that Cuis is based on
> > has the best long term prospects but we have to get out of this
> > 'everything is public' mindset.  Sure, we have all the source: look at
> > it, learn from it, poke around, refactor it, submit fixes, etc.  But
> > there needs to be a manageable subset of it which is considered the
> > 'public API' that people can depend on to write frameworks and apps on
> > top of that is relatively stable longer term.  Let's start defining what
> > that is and backfill changes to the public API (which will happen from
> > time to time as we don't want things to be completely static) with tests
> > and documentation so you can focus your efforts on where they matter
> > most and you get the most enjoyment from.
> 
> I fully agree and support this.
> Maybe an alternative to yet-another-convention-on-categories could be to 
> mark public methods with a pragma, or make them send 'self publicAPI' or 
> such... This could be better for the tools, also.
> 

I like your idea better re: rather than having to go through and mark
the majority as private, just mark the minority as public.  I'm open to
either of your proposed approaches.  I just tossed out the two (method
categories and naming) I was aware of but agree that they would not do
much to ease developing tools to support/enforce.  Of the two ideas, am
I correct in believing that pragma would have the lowest runtime
overhead?  Are there any downsides you can think of to using pragma?

Speaking of enforcing, I am not proposing that we make this a
straight-jacket for anyone: it should be easy to opt-out the way things
like underscore assignment are (except for pp which I'm still trying to
get to an easily repro example with... :-) so that anyone who doesn't
care about this isn't forced into it.  On the other hand, for people who
do care, they should be able to leave it 'enabled', whatever that ends
up meaning, and get help from the tooling to help them minimize
potential future breakage.  The downside to opting out would be that
you, as the author opting out, have decided to take it entirely on
yourself to keep your code running across builds/releases.

> > ...
> >> I don't have that either. I run the tests from time to time (I'll start
> >> doing it before any commit, and add the xml report to the rep). But this
> >> is not the most important reason why Cuis is solid. Cuis is very
> >> reliable because:
> > reliable != stable
> 
> ;)
> 
> >> - I'm not too bad as a coder.
> >> - I do my own code revisions at least one day after each change.
> >> - I use Cuis every day, and spot most problems in the updates, before
> >> commtting them to the repo.
> >> - I really, really care about code quality.
> >> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
> >> is a big responsibility, given how important I think Smalltalk-80 is.
> >>
> > Agree to all this and more.  Cuis would not be where it is without your
> > continued effort and diligence. (i.e. setting aside that you obviously
> > created it, if you had just tossed it out into the world and let it go
> > at best it would have started looking something like Squeak or Pharo by
> > now.  It's a lot of effort over the long term to *keep* it small and
> > focused.  THANK YOU JUAN!)
> 
> Thanks for your nice words, Phil. I really appreciate that you all 
> accept this rather restrictive dev model for the base image, in contrast 
> with a more open trunk style. Hopefully, as the base image becomes 
> stable and almost irrelevant, this will be each time less of a problem.
> 
> >> So, I suggest running your tests when updating your image, or migrating
> >> your code to an updated image.
> > +1 to tests as they do help quite a bit and are a very good practice.
> > Just be judicious in what/where you test (I personally don't subscribe
> > to the TDD approach where you spend your days mostly writing tests.
> > That's just admitting defeat in that you spend all day writing
> > executable documentation.)
> 
> <OT>
> 
> I don't subscribe to "extreme" TDD either. To me design is a creative 
> activity, both technical and artistic. It should be "driven" by 
> creativity and intelligence, not by a process. Any xDD process is 
> admitting defeat on design itself!
> 

Heh... I like the way you put that.

> </OT>
> 
> >> In any case, I think this doesn't answer your concerns. What you need is
> >> some way to know which updates could affect you, to review them in
> >> detail, and understanding their effect on your code. A list of the
> >> affected classes and/or methods for each update makes no sense. Cuis can
> >> already show you that very easily. Perhaps each update should include:
> >>
> >> 1) parts of the system that are affected:
> >> - Kernel
> >> - Compiler
> >> - Tools
> >> - Morphic
> >> - etc
> >>
> >> 2) Level of risk involved
> >> - very unlikely to break code that depends on this part of the system
> >> - could perhaps break code that depends on this part of the system
> >> - will most likely break code that depends on this part of the system
> >>
> >> Or something like that.
> >>
> >> BTW, this is a very relevant topic for discussing on the mail list. Feel
> >> free to answer there if you agree.
> > One final thought on this:  I suspect a major cause of people abandoning
> > Cuis (and Smalltalk in general), behind the 'it's too different from
> > what I'm used to'/'not mainstream' reaction, is the instability of its
> > APIs.
> 
> Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) 
> is a PITA too...

True, neither extreme (changing nothing vs. changing everything) works
very well. <cough>Perl 6</cough> :-)
 
> 
> As a bottom line, let me repeat: This is too big for me to do it. 
> Please, folks, start documenting the APIs you most care about.
> 

Ready to go... we just need to agree on how to do it (pragma/method
call/method category/method name?)  Also, this is most definitely
related to the 'Canonical test cases?' thread from a few months ago as
these types of test cases / docs are part of the backfill I was
referring to.

As I've been writing this it occurs to me that there's probably a pretty
easy way to go about getting started on this: IIRC, there are ~1,500
distinct method names in the core image.  If I do a count of how many
times my code is calling any of those methods, that should pop out what,
for my code, is the low hanging fruit.  The long-tail of say 1-5 calls
for the lesser used methods are the tedious work that will take more
effort for me to sort through.  We could use my 'short list' to at least
provide a starting point and using these most frequently called methods
you could scan through the list and could say 'hey, why are you calling
X instead of Y?' or maybe you'd get some visibility in the sense of
'wow, I didn't think that was being used'.  Hmm... I've got some
analysis to do...

> Cheers,
> Juan Vuletich





From hannes.hirzel at gmail.com  Sun Jul 19 18:01:22 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 23:01:22 +0000
Subject: [Cuis] Baseline version?
Message-ID: <CAGQxfVg7XkxDx0GXRzbM-g-efzvVKeafy3H5DzNJdjkzTwxDUg@mail.gmail.com>

On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Sun, 19 Jul 2015 11:20:19 -0300
....
> I'd like to propose a simpler model based on the Smalltalk Way.
>
> We take any stable revision, call it a version, give it a Baseline Version
> Number (could be just the development version number).

I'd like to suggest to label just the current version as a "baseline".

It would not need a long description, just a few keywords regarding
major changes like the addition of the FileMan package with a
reference to the description of it.

The last one
http://www.jvuletich.org/Cuis/CuisReleaseNotes.html

had

New in Cuis 4.2 (released July 25, 2013)

    Packages now have dependencies

    Package loading greatly enhanced

    Moved non-essential stuff to optional packages. Cuis is now below
500 classes and 100kLOC. Reduction was about 25%

    Many bugfixes, and minor enhancements and cleanup


So this one would have

New in Cuis 4.3 (released July 25, 2015)

     Many bugfixes, and minor enhancements and cleanup

     Addition of FileMan

    .....................

    .......................


    .....................

    .......................



And then after testing various packages on it
another baseline at the end of the year with a release document.

New in Cuis 4.4 (released December 31, 2015)

     Many bugfixes, and minor enhancements and cleanup

    .....................

    .....................

    .......................


    .....................

    .......................

    .....................

    .......................


More text as we will be more aware of the changes.



> Each Baseline
> Release has a release document which describes major changes since the
> previous baseline.  This document is a light-weight description.
>
> Each baseline release starts a new fork.  The only changes to the particular
> baseline release are bug fixes.
>
> Nice users test their packages and likewise fork a Package Release which
> matches a Baseline Release.  This fork also only changes with bug fixes, and
> only in synch with its particular baseline.  Baseline packages Feature the
> baseline release.
>
> So we forge ahead as usual, once in a while we say "enough has changed that
> we should re-baseline", do a new Baseline Release, test and release our
> Package Releases, then again move on forward.
>
> Anyone can now pick any baseline release, require any associated packages,
> and ship/demo without fear.
>
> Anyone with the time, energy, and interest can document baseline APIs to
> whatever level they feel comfortable.
>
> Anyone can forge on ahead with the latest revision(s) with the usual "here
> be dragons, but also gold".
>
> $0.02
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Sun Jul 19 18:52:33 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 23:52:33 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1424720606.2231.10.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
Message-ID: <CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>

On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> On Mon, 23 Feb 2015 08:38:44 +0000
>> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>
>> > As Casey writes "The hard part is time and energy to do so."
>> >
>> > So what can be done with minimal effort and big impact?
>>
>> Looking around, I see that I could make some simple naming changes for
>> test cases.
>>
>> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>>   testExampleHighlevel -> testNaclHiglLevelAPI
>>   textExampleLowLevel -> testNaclLowLevelAPI
>>
>> We could use other words, but API is shorter than Usage, Example,
>> Interface.
>>
>> Having specific test names end in 'API' would clue me in.
>>
>> Adding 'Nacl' means I can use the existing message finder to search for
>> 'api' and note testNacl*API methods.  This lets me find API tests specific
>> to Nacl.
>>
>> And we can do this as I get the chance.
>>
>> Other suggestions?
>
> I started playing around with a couple of example test cases to see what
> I ran into and came up with a distinct class to store all of these per
> test category (i.e. under Test-Files a class ApiFile which could have a
> method testWriteTextFile)  The rationale was that it might make sense to
> keep these test cases separate from traditional test cases which are
> free to make calls that users of the class (i.e. who are calling the
> supported API) should not.

Phil,

where do you keep this class ApiFile?

regards

Hannes


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



From hannes.hirzel at gmail.com  Sun Jul 19 18:57:25 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sun, 19 Jul 2015 23:57:25 +0000
Subject: [Cuis] Where are SUnit tests and how do I get them?
Message-ID: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>

Hello

In the current image when I open the SUnit browser no tests appear.


I assume the SUnit tests now in

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st

?

Are all tests there?

An snippet how to load them in the 'Useful Expression Workspace' would be fine.

Regards
Hannes



From pbpublist at gmail.com  Sun Jul 19 19:39:31 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 20:39:31 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150719131838.7d00ce57192818d00c38262c@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
Message-ID: <1437352771.6934.219.camel@gmail.com>

On Sun, 2015-07-19 at 13:18 -0700, Ken.Dickey wrote:
> On Sun, 19 Jul 2015 11:20:19 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
> 
> > As a bottom line, let me repeat: This is too big for me to do it. 
> > Please, folks, start documenting the APIs you most care about.
> 
> Let me repeat, "you don't have to do it".
> 

I would agree that *Juan* doesn't need to do much of anything at this
stage, but not that it doesn't need to be done.  If and when it does get
done, if he disregards it, it will have been a futile exercise.  So I'd
appreciate it if we could come to an agreement as to whether or not I
should bother...

> I'd like to propose a simpler model based on the Smalltalk Way.
> 
> We take any stable revision, call it a version, give it a Baseline Version Number (could be just the development version number).  Each Baseline Release has a release document which describes major changes since the previous baseline.  This document is a light-weight description.
> 

While I agree that there should be periodic major releases, there are a
lot of things in motion between major releases that will either be
forgotten about or not considered major enough to call out in the major
version release notes.

The issue is what constitutes a major change?  If your code uses it it's
major, if mine uses it it's minor?  Coin toss?  Without a public API
what is considered major is either obvious (i.e. Morphic changes from
global to local coords or changing the File/Directory API so obviously
everything using them breaks) or arbitrary (sorry to hear that you
depended on that... but it wasn't major, now it's gone)  If the image
snapshot is considered the public API, then everything must be both
considered fair game to depend on and to change in the future which is
unmanageable.

Let's look at a few examples along the spectrum of what I'm talking
about:

1)  Things that hopefully we can all agree on as being obvious and
relatively stable.  We have a class called Morph.  Is it reasonable to
assume that that is going to be supported going forward?  How about the
#drawOn: method, is that going to be around for a while?  If Juan were
to randomly decide to change these, I'd expect there would be screaming
from anyone who has a significant amount of drawing code.

2) Multiple ways to do the same thing.  Morphs support stepping to do
animated drawing etc.  There are at least two different ways (one
seemingly obvious, one less so... both different from how things used to
work) currently to do stepping.  Should this be the case, or should we
just have one way we agree that everyone uses?  What is lost by giving
up the 2nd (and 3rd...) way(s)?  Currently, if Juan were to change *any*
of the approaches, it would probably break someones code.  Why not just
have one supported way for him to be concerned with?  (if you think this
doesn't happen, one of my pull requests in the last month was related to
this)

3) Questionable usage / edge cases.  Morph also has
#resumeAfterDrawError and #resumeAfterStepError.  Now taking a few
seconds to look at them (never used myself) they seem like Morphic
implementation details, but hey they're in the image and not even marked
private so I should feel free to make my code depend on them, right?
Conversely, Juan could look at them and decide 'no one would possibly
need these' and change/remove them at any time.

It seems to me that at least 1/2 of 2 and most use cases of 3 are
unnecessary issues waiting to, and eventually will, happen.  I
personally try to stick to depending on things that are in category 1 or
the obvious use case of 2.  But imagine my surprise when I discover as
the result of an update that something I was using was actually in
category 2 (less obvious, to me at least) or 3.  Sure, there's a lot of
gray area that isn't so clear cut, but shouldn't we at least try to
minimize the amount of breakage going forward when it can easily be
avoided or manage it via documentation/communication when it can't?

I'm not trying to restrict Juan in any way from making the changes he
thinks are important for Cuis.  His taste and direction have been
generally excellent and the reason I'm here!  If for example, he decides
that #drawOn: is no longer the way to do things or that even Morph
needed to go away, that's fine as long as what's going on gets
communicated.  However, a problem I think he faces right now is that he
doesn't know who's using / depending on what.

> Each baseline release starts a new fork.  The only changes to the particular baseline release are bug fixes.
> 
> Nice users test their packages and likewise fork a Package Release which matches a Baseline Release.  This fork also only changes with bug fixes, and only in synch with its particular baseline.  Baseline packages Feature the baseline release.
> 
> So we forge ahead as usual, once in a while we say "enough has changed that we should re-baseline", do a new Baseline Release, test and release our Package Releases, then again move on forward.
> 
> Anyone can now pick any baseline release, require any associated packages, and ship/demo without fear.
> 

What you are describing is an application development model, not a
platform development model.  It handles dependencies by ignoring them.
It really comes down to what is Cuis?  Is it:

1) a minimal Smalltalk that you play around with ideas / prototype
something in the short to intermediate term

2) a platform that you can take that idea you were playing around with,
and if it proves out, build something more substantial from for the
longer term

3) a completely experimental environment.  Anything can change at any
time.  Supporting 1 is doable but 2 is doubtful.

Right now, Cuis is great at 1 but seems like it should be able to handle
both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
all, but who knows, others may disagree.  If others look at it
differently, I'd love to know how you look at Cuis.

> Anyone with the time, energy, and interest can document baseline APIs to whatever level they feel comfortable.
> 
> Anyone can forge on ahead with the latest revision(s) with the usual "here be dragons, but also gold".
> 
> $0.02
> -KenD
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From pbpublist at gmail.com  Sun Jul 19 19:43:29 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 20:43:29 -0400
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
Message-ID: <1437353009.6934.223.camel@gmail.com>

Hi Hannes,

On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
> >> On Mon, 23 Feb 2015 08:38:44 +0000
> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
> >>
> >> > As Casey writes "The hard part is time and energy to do so."
> >> >
> >> > So what can be done with minimal effort and big impact?
> >>
> >> Looking around, I see that I could make some simple naming changes for
> >> test cases.
> >>
> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
> >>   testExampleHighlevel -> testNaclHiglLevelAPI
> >>   textExampleLowLevel -> testNaclLowLevelAPI
> >>
> >> We could use other words, but API is shorter than Usage, Example,
> >> Interface.
> >>
> >> Having specific test names end in 'API' would clue me in.
> >>
> >> Adding 'Nacl' means I can use the existing message finder to search for
> >> 'api' and note testNacl*API methods.  This lets me find API tests specific
> >> to Nacl.
> >>
> >> And we can do this as I get the chance.
> >>
> >> Other suggestions?
> >
> > I started playing around with a couple of example test cases to see what
> > I ran into and came up with a distinct class to store all of these per
> > test category (i.e. under Test-Files a class ApiFile which could have a
> > method testWriteTextFile)  The rationale was that it might make sense to
> > keep these test cases separate from traditional test cases which are
> > free to make calls that users of the class (i.e. who are calling the
> > supported API) should not.
> 
> Phil,
> 
> where do you keep this class ApiFile?
> 

It's in Packages/Tests.pck.st package. After loading it will be listed
in the Tests-Files category.

> regards
> 
> Hannes
> 

Thanks,
Phil




From pbpublist at gmail.com  Sun Jul 19 19:50:10 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 20:50:10 -0400
Subject: [Cuis] Where are SUnit tests and how do I get them?
In-Reply-To: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>
References: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>
Message-ID: <1437353410.6934.229.camel@gmail.com>

Hannes,

On Sun, 2015-07-19 at 23:57 +0000, H. Hirzel wrote:
> Hello
> 
> In the current image when I open the SUnit browser no tests appear.
> 
> 
> I assume the SUnit tests now in
> 
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st
> 
> ?
> 
> Are all tests there?
> 
> An snippet how to load them in the 'Useful Expression Workspace' would be fine.
> 

The main Cuis tests are in the Packages/Tests.pck.st file I mentioned in
my previous reply.  Additionally, many of the 3rd party packages also
have optional tests (usually <PackageName>Tests.pck.st or something
similar) which can be loaded.  They don't get loaded by default so you
need to open a file browser, navigate to them, and install the
package(s).

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





From pbpublist at gmail.com  Sun Jul 19 20:01:38 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 21:01:38 -0400
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
	<CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>
Message-ID: <1437354098.6934.240.camel@gmail.com>

On Sun, 2015-07-19 at 20:21 +0000, H. Hirzel wrote:
> If I take a current image (18 Jul 2015, 4.2-2424)  I get the same result
> 
> 
> a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy #at:ifAbsent:)
> 
> All the FileMan additions are not listed. Maybe because they keep
> their original time stamp, not the time stamp of the addition to
> Squeak.
> 

Right, the timestamp will reflect when they were last edited rather than
when they were loaded into the image.

> And the recent change on #compilerClass does not show up.
> 

Same situation: #compilerClass while only recently re-added to the
image, hasn't actually been changed since it was removed and added back
so it still shows an older timestamp.

It sounds like you're looking for more of an image diff to see what
classes/methods changed between timer period X and Y?  This isn't
something that currently exists in an easy to use form that I'm aware
of.
 
> --HH
> 
> On 7/19/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > If I use this to find out which methods have a time stamp date
> > indicating a change after the 1st of January 2015 in a pristine Cuis
> > 4.2-2243 (17 April 2015) image I find out that only the
> >
> > #postCopy method was changed (probably added) in nearly all classes.
> >
> > If I change the base line date to 1st of January 2014 I get
> >
> > a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
> > #at:ifAbsent:)
> > as changed/updated methods (i.e. methods which have a time stamp in
> > this period).
> >
> > Of course this assumes that a method gets a time stamp when changed.
> > Many methods have nil as a time stamp.
> >
> >
> > Could somebody from the list check this please?
> >
> >
> > |date coll baseLineDate dt  updatedMethods |
> >
> > baseLineDate := Date year: 2014 month: 1 day: 1.
> > coll := OrderedCollection new.
> >
> > Smalltalk allClasses do: [ :cls |
> > cls allSelectors do: [ :sel |
> > dt := VersionsBrowser timeStampFor:  sel class: Dictionary reverseOrdinal:
> > 1.
> >
> > dt notNil ifTrue: [
> > date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
> > ]) or: [ch = $:]] .
> > (date = '') ifFalse:
> > 	[date := Date fromString: date.
> > 		(date > baseLineDate) ifTrue: [coll add: (Association key:
> > (Association key: cls value: sel) value: date)
> > ]]].
> >
> > ]].
> >
> > updatedMethods := Set new.
> > coll do: [ :elem | updatedMethods add: (elem key value)].
> > coll inspect.
> > updatedMethods inspect
> >
> >
> >
> >
> > On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
> >> On 7/16/2015 11:49 AM, H. Hirzel wrote:
> >>> Hello
> >>>
> >>> I'd like to do a query finding out about the time stamp of  source
> >>> code changes of all methods in the Cuis image and then do a list with
> >>> the following four columns
> >>>
> >>>
> >>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
> >>> DateOfChange
> >>>
> >>> Help is appreciated.
> >>>
> >>> Hannes
> >>
> >> Check #timeStampFor:class:reverseOrdinal: and in general
> >> #annotationForSelector:ofClass:
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
> >
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Sun Jul 19 20:13:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 19 Jul 2015 21:13:35 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55ABA6A2.5090607@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>,
	<55ABA6A2.5090607@jvuletich.org>
Message-ID: <55AC4B3F.19938.1F92268@dnorton.mindspring.com>

On 19 Jul 2015 at 10:31, Juan Vuletich wrote:

> On 7/18/2015 3:37 PM, Dan Norton wrote:
> > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
> >
> >> Hi Folks,
> >>
> >> It is not too hard to build new StrikeFonts. You need to build,
> by
> >> hand,
> >> files like the ones in here:
> >>
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> >> p
> >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
> with
> >> this method and the files in this zip that built the existing
> >> instances
> >> of StrikeFont. Not sure.
> >>
> > That's intrigueing but I can't reproduce it. Maybe the .bmp but
> where did you get the .txt?
> >
> >   - Dan
> 
> I wrote them with a text editor. Check #installDejaVu2 and really
> try to 
> understand how StrikeFonts work and how they are built with this
> method. 
> Maybe you'll become enlightened.
> 

A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name, and several scalars. 
StrikeFont class methods create fonts by processing file pairs assumed to be in the 
"AAFonts" subdirectory. For example:

DejaVu Sans Oblique 14.bmp
DejaVu Sans Oblique 14.txt

Is one such pair providing the italic (oblique) style for 14-point size. There is a pair for every 
font size and style: base, bold, italic, and bold italic. Therefore a font such as "DejaVu Sans" 
which is available in the size interval 5 to 24 requires 160 files. The file names are stylized 
and encoded in the StrikeFont class methods.

Glyphs come from the .bmp file. The .txt file is a string of numbers; the first three specify 
pointSize, ascent, and	descent. The rest of the numbers in the .txt file are used to form the 
xTable, which is the index into the glyphs for a character. The characterToGlyphMap is an 
array of 256 entries which map a character's ascii value to the xTable and thence to the 
glyphs.

The bold, italic, and bold italic styles are stashed as derivatives of the base and not 
selectable from the current menus.

StrikeFont is a subclass of AbstractFont, which has class variables AvailableFonts and 
DefaultFont.

If it can't find a file, StrikeFont will loop.

In regard to creating the .bmp and .txt files, you say, "I wrote them with a text editor." Please 
tell me which text editor you used. None of mine do that.

 - Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150719/abeacdea/attachment-0004.html>

From pbpublist at gmail.com  Sun Jul 19 20:21:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 19 Jul 2015 21:21:01 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBY7YtLCJwVSOM3w58shed-YcnON=BL2WD2xM6EAMVbn2A@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<CAJBxtBY7YtLCJwVSOM3w58shed-YcnON=BL2WD2xM6EAMVbn2A@mail.gmail.com>
Message-ID: <1437355261.6934.252.camel@gmail.com>

On Sun, 2015-07-19 at 18:02 +0200, Peter van Rooijen wrote:
> Hey all,
> 
> 
> Just 2 cents from a Cuis noob:
> 
> 
> 1. Releases... since this stuff is not being sold for money and not
> being distributed using off-line media, what use does a "release"
> have? I like that stuff gets improved as often as possible. I believe
> that the things that get improved the most often, have the best chance
> of becoming something really good.
> 

It's more a function of managing the dependent code bases than anything
else.  One's view of 'improved as often as possible' changes when said
improvements break things you are depending on without warning.

> 
> So, I am for adopting practices that increase the number of
> improvements. Practices that decrease the number of deteriorations
> seem helpful as well. See below if you wonder what my point is ;-).
> 
> 
> 2. Public vs private API. Stable APIs are nice, if you can get them.
> If you have authors who develop a base, and other authors who (have
> to) develop ON that base, you need stable APIs, or you will lose the
> authors dependent on your base.
> 

Yup.  See Hannes' original comments that started this thread.  I chimed
in because I've been bitten by this several times.  And I'm sure there
are others who don't participate in the lists.  At the same time, I
recognize that there are others like Ken who don't have an issue.  It's
just a discussion that needed to be had and a decision reached whether
or not something needs to be done, and if so what.

> 
> So, do we really have those different author groups? Somehow I doubt
> it. I recently changed the scoping rules for shared variables (I think
> they're done wrong in the base image). I could change what I wanted
> easily. So I think I am not in some outsider author group. Instead I
> am happy that I could change what I wanted without needing anyone's
> approval or cooperation.
> 

We absolutely do.  I fall into several categories: I occasionally submit
changes to 'core' Cuis, work on several add-on frameworks (OMeta and
OpenGL are currently my main focuses on that front), and have a
large-ish base of my own code that I'm developing and maintaining.

The issue isn't one of permission as much as it is of communicating to
those downstream what is considered stable/supported.  Feel free to
change anything you want, just don't be surprised if the next release
breaks your changes.  But what do you do when you're trying to write
something that either won't break in the next release or at least have
some indication before hand what you might run into...

> 
> Suppose we were making money from outside author groups who want us to
> keep certain APIs stable. For the right price, I would be happy to
> provide that for them. In the mean time, I can live with free. Free to
> change what I want, free to use without paying, and others free to
> change what I am building on (sometimes frustrating).
> 

That definitely makes sense when you're talking about things like LTS
(Long Term Support) versions etc.  Free and stable are not mutually
exclusive.

> 
> 3. Maybe what will help everybody is something that prevents
> functionality from being lost, especially *unintentionally*. This can
> include certain APIs as well. So what if an author who values a
> certain API, could invest some of his own time/money, to protect that
> API? What if he could write a software component (let's say a class)
> that was able to detect whenever an image did not provide the desired
> API? What if he could submit that class, and everybody who cared about
> not breaking that API, could use that class to see if perhaps they
> broke it?
> 
> 
> 4. I believe the idea could be generalized to include any feature of
> (the code in) an image for which presence or absence (as may be the
> case) can be determined by such a class. Bugs could be reified as
> classes, and the presence or absence of the bug could be determined by
> that class. Feature requests could be reified as classes, and whether
> or not the feature had actually been implemented could be determined
> by that class.
> 
> 
> 5. The things I am proposing would basically be Feature Tests, and
> would be rather different from Unit Tests (which apply to a unit and
> which you want to all be green when you share your software with users
> of it). Feature Tests would apply to a system (not a unit) and simply
> indicate which features are and which features are not present in the
> system. Every "release" could then come with a) the assertion that all
> the Unit Tests passed b) a list of the Feature Tests that passed and
> those that did not.
> 

I believe what you are proposing is similar to what I proposed a few
months ago in the 'Canonical test cases?' thread.
http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-February/001747.html

> 
> 6. I think it would be pretty cool if people sent in feature requests
> in the form of Feature Tests, instead of messages to the mailing list
> (or the request tracker). So that anybody who (wished to impress
> somebody and) had some time on their hands, could then try to
> implement the functionality that made the Feature Test pass.
> 
> 
> Hope this helps somebody with something :)
> 
> 
> Cheers, Peter
> 
> On Sun, Jul 19, 2015 at 4:20 PM, Juan Vuletich <juan at jvuletich.org>
> wrote:
>         Hi Folks,
>         
>         (inline)
>         
>         On 7/17/2015 3:45 PM, Phil (list) wrote:
>                 ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>                                 Thank you Juan, for answering.
>                                 
>                                 At the moment I feel uncomfortable
>                                 using Cuis because it is currently
>                                 a quite fast moving target. I perceive
>                                 quite a number of API changes
>                                 though this might be wrong. But I do
>                                 not know because there are no
>                                 release notes which summarize it.
>                 I totally feel Hannes' pain having gone through it a
>                 few times myself
>                 over the years.  At the same time, I agree with Ken's
>                 point about not
>                 getting too bogged down in process since we're in the
>                 best position
>                 right now to break things for the better longer term.
>                 
>                         Yes, that's true. Besides, we don't have a
>                         specification of what is an
>                         API and what is not. So, almost any change can
>                         be considered an API change.
>                 That's the problem!  Both for you and us (it's a
>                 general 'Smalltalk Way'
>                 issue, not specific to Cuis)  I believe it is largely
>                 fixable without
>                 tons of documentation and tests: the use of private
>                 (categories or
>                 method naming convention).  Bernhard pointed out an
>                 existing capability
>                 a few months ago
>                 http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
>                 While I personally like the idea of private
>                 categories, one of these
>                 approaches should really be seriously considered.
>                 
>                 Other than a few specific examples (i.e. mostly the
>                 base data types
>                 including the Collection and Number class hierarchies
>                 which are pretty
>                 mature and don't change all that much anyway) I would
>                 guesstimate that
>                 <20% (probably closer to 10%) of the methods, and and
>                 unknown % of
>                 classes (a significantly larger fraction though),
>                 should even be
>                 considered public.  If things were indicated as
>                 private that would
>                 accomplish two things:
>                 
>                 1) We could construct some simple tooling (some
>                 combination of up-front
>                 warnings in the editor and/or a lint-type tester after
>                 the fact) that
>                 would allow people to identify problematic calls
>                 within their code.
>                 (i.e. just because it works now doesn't mean it always
>                 will if you keep
>                 calling X, Y, Z...)
>                 
>                 2) It would provide a way for people to know if
>                 something needs to be
>                 discussed.  i.e. 'In class X method Y is private but I
>                 need that type of
>                 functionality' so you would know that there's a need
>                 and could consider
>                 either making it public, and therefore supported, or
>                 rethinking its
>                 implementation if you'd like to offer a better public
>                 API solution.
>         
>         Ok. Doing something along these lines would be great. But
>         please note that it is a rather large amount of work. It is
>         not something I'm able or willing to do it alone. If you (any
>         of you all, not just Phil) wants to start defining the API for
>         any part of the system or optional packages, please start
>         doing it and send the changesets to the list. If we get this
>         working, I'll start the tools you mention.
>         
>         <slowly diverging into OT rant>
>         
>         On the other hand (and please forgive me if this kills a bit
>         of momentum), I don't really think we are changing APIs that
>         much. And I don't think we'll be doing it any more in the
>         future than we do today, at least in the base image. I hope to
>         see most of the activity and incompatible changes to happen in
>         optional packages, and affecting package dependencies... Mhhh,
>         now that I write this I think that it doesn't really go
>         against the idea of defining APIs. Maybe APIs in the base
>         image will almost never change or be a problem, but packages
>         should provide APIs too... Optional packages will (I hope!)
>         always be improving, and new ones will appear all the time.
>         
>         If all this work, the Cuis will be a lot less about my
>         personal effort and coding style, and the packages maintained
>         by each one of us will become the main characters in this
>         story. And this will be a very good thing. The base image
>         should be about providing a good base for doing the really
>         interesting stuff on top...
>         
>         Let me tell you a bit about how Cuis got started. Many years
>         ago I did my thesis on audio/music processing. The I wanted to
>         turn that into a novel and fun application for musicians (both
>         pros and anyone willing to play with sound). I started to
>         think about how a good GUI for that could be, giving the
>         feeling of modifying sound by direct manipulation of it, as if
>         it was clay, as if it was visual and not just auditory. Well,
>         that was the start of my questioning of the whole GUI business
>         and Morphic 3. And it became clear to me that Squeak had
>         turned into something that was not the best possible
>         environment to do all this. The idea of "fixing" Squeak, and
>         thus make Cuis, was born. So, Cuis was not and end in itself,
>         but a means for allowing experimentation, freedom to build
>         applications in new styles, etc.
>         
>         (The idea that Cuis is a truer Smalltalk-80 than Squeak or any
>         other came later, as an observation on facts.)
>         
>         So, when the moment comes when Cuis stabilizes a bit, and
>         interest moves to packages and applications built by all us,
>         Cuis will start to fulfill its original objective.
>         
>         </slowly diverging into OT rant>
>         
>                         ...
>                         The problem, I think, is not identifying well
>                         defined Cuis releases. The
>                         problem is knowing how updates could affect
>                         your code
>                 By narrowing the scope of what the public API is using
>                 private
>                 designators, this dramatically reduces what you need
>                 to be concerned
>                 with on this front.  It's part of the reason that
>                 Apple, Google, and
>                 even Microsoft are so adamant about public APIs these
>                 days.  They dealt
>                 with the pain of even major developers depending on
>                 private APIs for
>                 decades. It's only been in the last 10 years or so
>                 that they've been
>                 able to dig themselves out from under this issue.
>                 
>                 This gets back to the 'Smalltalk Way' issue I
>                 referenced earlier.  The
>                 attitude of 'you have the source, play around, have
>                 fun!' has morphed
>                 into 'everything is a public API!  there are no rules!
>                 isn't this
>                 great?'  Well no, it's not great.  It makes life
>                 impossible for image
>                 maintainers (Squeak has been in a coma for the last
>                 decade or so as the
>                 result of trying to keep everyone happy... yet no one
>                 seems to be) and
>                 miserable for those who are trying to keep code
>                 running on it (stuff
>                 still breaks all the time.)
>         
>         Yes.
>         
>                 I personally believe the minimalism and simplicity
>                 that Cuis is based on
>                 has the best long term prospects but we have to get
>                 out of this
>                 'everything is public' mindset.  Sure, we have all the
>                 source: look at
>                 it, learn from it, poke around, refactor it, submit
>                 fixes, etc.  But
>                 there needs to be a manageable subset of it which is
>                 considered the
>                 'public API' that people can depend on to write
>                 frameworks and apps on
>                 top of that is relatively stable longer term.  Let's
>                 start defining what
>                 that is and backfill changes to the public API (which
>                 will happen from
>                 time to time as we don't want things to be completely
>                 static) with tests
>                 and documentation so you can focus your efforts on
>                 where they matter
>                 most and you get the most enjoyment from.
>         
>         I fully agree and support this.
>         Maybe an alternative to yet-another-convention-on-categories
>         could be to mark public methods with a pragma, or make them
>         send 'self publicAPI' or such... This could be better for the
>         tools, also.
>         
>                 ...
>                         I don't have that either. I run the tests from
>                         time to time (I'll start
>                         doing it before any commit, and add the xml
>                         report to the rep). But this
>                         is not the most important reason why Cuis is
>                         solid. Cuis is very
>                         reliable because:
>                 reliable != stable
>         
>         ;)
>         
>                         - I'm not too bad as a coder.
>                         - I do my own code revisions at least one day
>                         after each change.
>                         - I use Cuis every day, and spot most problems
>                         in the updates, before
>                         commtting them to the repo.
>                         - I really, really care about code quality.
>                         - I think Cuis keeps Smalltalk-80 and its
>                         ideals alive. And I think that
>                         is a big responsibility, given how important I
>                         think Smalltalk-80 is.
>                         
>                 Agree to all this and more.  Cuis would not be where
>                 it is without your
>                 continued effort and diligence. (i.e. setting aside
>                 that you obviously
>                 created it, if you had just tossed it out into the
>                 world and let it go
>                 at best it would have started looking something like
>                 Squeak or Pharo by
>                 now.  It's a lot of effort over the long term to
>                 *keep* it small and
>                 focused.  THANK YOU JUAN!)
>         
>         Thanks for your nice words, Phil. I really appreciate that you
>         all accept this rather restrictive dev model for the base
>         image, in contrast with a more open trunk style. Hopefully, as
>         the base image becomes stable and almost irrelevant, this will
>         be each time less of a problem.
>         
>                         So, I suggest running your tests when updating
>                         your image, or migrating
>                         your code to an updated image.
>                 +1 to tests as they do help quite a bit and are a very
>                 good practice.
>                 Just be judicious in what/where you test (I personally
>                 don't subscribe
>                 to the TDD approach where you spend your days mostly
>                 writing tests.
>                 That's just admitting defeat in that you spend all day
>                 writing
>                 executable documentation.)
>         
>         <OT>
>         
>         I don't subscribe to "extreme" TDD either. To me design is a
>         creative activity, both technical and artistic. It should be
>         "driven" by creativity and intelligence, not by a process. Any
>         xDD process is admitting defeat on design itself!
>         
>         </OT>
>         
>                         In any case, I think this doesn't answer your
>                         concerns. What you need is
>                         some way to know which updates could affect
>                         you, to review them in
>                         detail, and understanding their effect on your
>                         code. A list of the
>                         affected classes and/or methods for each
>                         update makes no sense. Cuis can
>                         already show you that very easily. Perhaps
>                         each update should include:
>                         
>                         1) parts of the system that are affected:
>                         - Kernel
>                         - Compiler
>                         - Tools
>                         - Morphic
>                         - etc
>                         
>                         2) Level of risk involved
>                         - very unlikely to break code that depends on
>                         this part of the system
>                         - could perhaps break code that depends on
>                         this part of the system
>                         - will most likely break code that depends on
>                         this part of the system
>                         
>                         Or something like that.
>                         
>                         BTW, this is a very relevant topic for
>                         discussing on the mail list. Feel
>                         free to answer there if you agree.
>                 One final thought on this:  I suspect a major cause of
>                 people abandoning
>                 Cuis (and Smalltalk in general), behind the 'it's too
>                 different from
>                 what I'm used to'/'not mainstream' reaction, is the
>                 instability of its
>                 APIs.
>         
>         Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0
>         problem) is a PITA too...
>         
>         As a bottom line, let me repeat: This is too big for me to do
>         it. Please, folks, start documenting the APIs you most care
>         about.
>         
>         Cheers,
>         Juan Vuletich
>         
>         _______________________________________________
>         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 kbrown at mac.com  Sun Jul 19 22:21:29 2015
From: kbrown at mac.com (Ken G. Brown)
Date: Sun, 19 Jul 2015 21:21:29 -0600
Subject: [Cuis]  Baseline version?
In-Reply-To: <mailman.94.1437354099.18328.cuis_jvuletich.org@jvuletich.org>
References: <mailman.94.1437354099.18328.cuis_jvuletich.org@jvuletich.org>
Message-ID: <4CA2DB35-1A26-46CE-B5D1-ACB50DC642B0@mac.com>

Craig Latta has a nice write up about his decent looking versioning system for Spoon: http://netjam.org/versions/

Ken G. Brown

> Date: Sun, 19 Jul 2015 23:01:22 +0000
> From: "H. Hirzel" <hannes.hirzel at gmail.com>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Subject: [Cuis] Baseline version?
> Message-ID:
>    <CAGQxfVg7XkxDx0GXRzbM-g-efzvVKeafy3H5DzNJdjkzTwxDUg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
>> On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
>> On Sun, 19 Jul 2015 11:20:19 -0300
> ....
>> I'd like to propose a simpler model based on the Smalltalk Way.
>> 
>> We take any stable revision, call it a version, give it a Baseline Version
>> Number (could be just the development version number).
> 
> I'd like to suggest to label just the current version as a "baseline".
> 
> It would not need a long description, just a few keywords regarding
> major changes like the addition of the FileMan package with a
> reference to the description of it.
> 
> The last one
> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
> 
> had
> 
> New in Cuis 4.2 (released July 25, 2013)
> 
>    Packages now have dependencies
> 
>    Package loading greatly enhanced
> 
>    Moved non-essential stuff to optional packages. Cuis is now below
> 500 classes and 100kLOC. Reduction was about 25%
> 
>    Many bugfixes, and minor enhancements and cleanup
> 
> 
> So this one would have
> 
> New in Cuis 4.3 (released July 25, 2015)
> 
>     Many bugfixes, and minor enhancements and cleanup
> 
>     Addition of FileMan
> 
>    .....................
> 
>    .......................
> 
> 
>    .....................
> 
>    .......................
> 
> 
> 
> And then after testing various packages on it
> another baseline at the end of the year with a release document.
> 
> New in Cuis 4.4 (released December 31, 2015)
> 
>     Many bugfixes, and minor enhancements and cleanup
> 
>    .....................
> 
>    .....................
> 
>    .......................
> 
> 
>    .....................
> 
>    .......................
> 
>    .....................
> 
>    .......................
> 
> 
> More text as we will be more aware of the changes.
> 
> 
> 
>> Each Baseline
>> Release has a release document which describes major changes since the
>> previous baseline.  This document is a light-weight description.
>> 
>> Each baseline release starts a new fork.  The only changes to the particular
>> baseline release are bug fixes.
>> 
>> Nice users test their packages and likewise fork a Package Release which
>> matches a Baseline Release.  This fork also only changes with bug fixes, and
>> only in synch with its particular baseline.  Baseline packages Feature the
>> baseline release.
>> 
>> So we forge ahead as usual, once in a while we say "enough has changed that
>> we should re-baseline", do a new Baseline Release, test and release our
>> Package Releases, then again move on forward.
>> 
>> Anyone can now pick any baseline release, require any associated packages,
>> and ship/demo without fear.
>> 
>> Anyone with the time, energy, and interest can document baseline APIs to
>> whatever level they feel comfortable.
>> 
>> Anyone can forge on ahead with the latest revision(s) with the usual "here
>> be dragons, but also gold".
>> 
>> $0.02
>> -KenD
>> 
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> 
> 



From hannes.hirzel at gmail.com  Mon Jul 20 02:35:38 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 07:35:38 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AC4B3F.19938.1F92268@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
	<55ABA6A2.5090607@jvuletich.org>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
Message-ID: <CAGQxfVhxnkq00Qi7OhuQo3Lbvqb03nRJi2sFxkQxHVet2439jw@mail.gmail.com>

On 7/20/15, Dan Norton <dnorton at mindspring.com> wrote:
> On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>
>> On 7/18/2015 3:37 PM, Dan Norton wrote:
>> > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>> >
>> >> Hi Folks,
>> >>
>> >> It is not too hard to build new StrikeFonts. You need to build,
>> by
>> >> hand,
>> >> files like the ones in here:
>> >>
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> >> p
>> >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
>> with
>> >> this method and the files in this zip that built the existing
>> >> instances
>> >> of StrikeFont. Not sure.
>> >>
>> > That's intrigueing but I can't reproduce it. Maybe the .bmp but
>> where did you get the .txt?
>> >
>> >   - Dan
>>
>> I wrote them with a text editor. Check #installDejaVu2 and really
>> try to
>> understand how StrikeFonts work and how they are built with this
>> method.
>> Maybe you'll become enlightened.
>>
>
> A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name, and
> several scalars.
> StrikeFont class methods create fonts by processing file pairs assumed to be
> in the
> "AAFonts" subdirectory. For example:
>
> DejaVu Sans Oblique 14.bmp
> DejaVu Sans Oblique 14.txt
>
> Is one such pair providing the italic (oblique) style for 14-point size.
> There is a pair for every
> font size and style: base, bold, italic, and bold italic. Therefore a font
> such as "DejaVu Sans"
> which is available in the size interval 5 to 24 requires 160 files. The file
> names are stylized
> and encoded in the StrikeFont class methods.
>
> Glyphs come from the .bmp file. The .txt file is a string of numbers; the
> first three specify
> pointSize, ascent, and	descent. The rest of the numbers in the .txt file are
> used to form the
> xTable, which is the index into the glyphs for a character. The
> characterToGlyphMap is an
> array of 256 entries which map a character's ascii value to the xTable and
> thence to the
> glyphs.
>
> The bold, italic, and bold italic styles are stashed as derivatives of the
> base and not
> selectable from the current menus.
>
> StrikeFont is a subclass of AbstractFont, which has class variables
> AvailableFonts and
> DefaultFont.
>
> If it can't find a file, StrikeFont will loop.
>
> In regard to creating the .bmp and .txt files, you say, "I wrote them with a
> text editor." Please
> tell me which text editor you used. None of mine do that.
>
>  - Dan

What I used in the past is the StrikeFont bitmap editor which is in
Squeak. In MVC if I remember well. So an early version of Squeak (e.g.
3.8.1 Oct 2006)  is helpful.

These versions are very accessible these days  http://squeak.org/downloads/

--Hannes



From hannes.hirzel at gmail.com  Mon Jul 20 03:06:33 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:06:33 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1437353009.6934.223.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
Message-ID: <CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> Hi Hannes,
>
> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>> >>
>> >> > As Casey writes "The hard part is time and energy to do so."
>> >> >
>> >> > So what can be done with minimal effort and big impact?
>> >>
>> >> Looking around, I see that I could make some simple naming changes for
>> >> test cases.
>> >>
>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>> >>
>> >> We could use other words, but API is shorter than Usage, Example,
>> >> Interface.
>> >>
>> >> Having specific test names end in 'API' would clue me in.
>> >>
>> >> Adding 'Nacl' means I can use the existing message finder to search
>> >> for
>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>> >> specific
>> >> to Nacl.
>> >>
>> >> And we can do this as I get the chance.
>> >>
>> >> Other suggestions?
>> >
>> > I started playing around with a couple of example test cases to see
>> > what
>> > I ran into and came up with a distinct class to store all of these per
>> > test category (i.e. under Test-Files a class ApiFile which could have a
>> > method testWriteTextFile)  The rationale was that it might make sense
>> > to
>> > keep these test cases separate from traditional test cases which are
>> > free to make calls that users of the class (i.e. who are calling the
>> > supported API) should not.
>>
>> Phil,
>>
>> where do you keep this class ApiFile?
>>
>
> It's in Packages/Tests.pck.st package. After loading it will be listed
> in the Tests-Files category.


I loaded the class ApiFile only and I get 3 tests passed and 1 failure
in Cuis 2.4-2424.

Can you confirm this, Phil?

>> regards
>>
>> Hannes
>>
>
> Thanks,
> Phil
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis4.2-2424-ApiFile Test Screenshot from 2015-07-20 07:56:23.png
Type: image/png
Size: 127147 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/7a96c85d/attachment-0004.png>

From hannes.hirzel at gmail.com  Mon Jul 20 03:16:02 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:16:02 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
Message-ID: <CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>

The file testResults.xml which Juan added has

<testcase classname="ApiFile" name="testImagePNG01WriteToFile"
status="passed"/>
<testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
status="passed"/>
<testcase classname="ApiFile" name="testText01WriteToFile" status="passed"/>
<testcase classname="ApiFile" name="testText02ReadFromFile" status="passed"/>

So there is an issue of test setup which was not fullfilled in my case....
Might be a Linux Mint issue (access rights)

On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> Hi Hannes,
>>
>> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>> >>
>>> >> > As Casey writes "The hard part is time and energy to do so."
>>> >> >
>>> >> > So what can be done with minimal effort and big impact?
>>> >>
>>> >> Looking around, I see that I could make some simple naming changes
>>> >> for
>>> >> test cases.
>>> >>
>>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>>> >>
>>> >> We could use other words, but API is shorter than Usage, Example,
>>> >> Interface.
>>> >>
>>> >> Having specific test names end in 'API' would clue me in.
>>> >>
>>> >> Adding 'Nacl' means I can use the existing message finder to search
>>> >> for
>>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>>> >> specific
>>> >> to Nacl.
>>> >>
>>> >> And we can do this as I get the chance.
>>> >>
>>> >> Other suggestions?
>>> >
>>> > I started playing around with a couple of example test cases to see
>>> > what
>>> > I ran into and came up with a distinct class to store all of these per
>>> > test category (i.e. under Test-Files a class ApiFile which could have
>>> > a
>>> > method testWriteTextFile)  The rationale was that it might make sense
>>> > to
>>> > keep these test cases separate from traditional test cases which are
>>> > free to make calls that users of the class (i.e. who are calling the
>>> > supported API) should not.
>>>
>>> Phil,
>>>
>>> where do you keep this class ApiFile?
>>>
>>
>> It's in Packages/Tests.pck.st package. After loading it will be listed
>> in the Tests-Files category.
>
>
> I loaded the class ApiFile only and I get 3 tests passed and 1 failure
> in Cuis 2.4-2424.
>
> Can you confirm this, Phil?
>
>>> regards
>>>
>>> Hannes
>>>
>>
>> Thanks,
>> Phil
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis4.2-2424_Testfiles_on_LinuxMint_Screenshot from 2015-07-20 08:13:48.png
Type: image/png
Size: 36391 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/7a092b24/attachment-0004.png>

From hannes.hirzel at gmail.com  Mon Jul 20 03:22:41 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:22:41 +0000
Subject: [Cuis] Where are SUnit tests and how do I get them?
In-Reply-To: <1437353410.6934.229.camel@gmail.com>
References: <CAGQxfVhnHcsQD1RsbEGR8CyzivGs5ML35Hioqn0YWyMrNKxc3g@mail.gmail.com>
	<1437353410.6934.229.camel@gmail.com>
Message-ID: <CAGQxfVgbdhZasgBHydZ6ykFuu+=O5D9rP4+MZN=Nn1Gitj92dA@mail.gmail.com>

I got the tests, the way you describe. I only loaded class ApiFile,
see other thread.

--Hannes

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> Hannes,
>
> On Sun, 2015-07-19 at 23:57 +0000, H. Hirzel wrote:
>> Hello
>>
>> In the current image when I open the SUnit browser no tests appear.
>>
>>
>> I assume the SUnit tests now in
>>
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st
>>
>> ?
>>
>> Are all tests there?
>>
>> An snippet how to load them in the 'Useful Expression Workspace' would be
>> fine.
>>
>
> The main Cuis tests are in the Packages/Tests.pck.st file I mentioned in
> my previous reply.  Additionally, many of the 3rd party packages also
> have optional tests (usually <PackageName>Tests.pck.st or something
> similar) which can be loaded.  They don't get loaded by default so you
> need to open a file browser, navigate to them, and install the
> package(s).
>
>> Regards
>> Hannes
>>
>> _______________________________________________
>> 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 hannes.hirzel at gmail.com  Mon Jul 20 03:30:38 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:30:38 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
Message-ID: <CAGQxfVg==3cZfayb1xZXiT5pA8mkas9xE12LNHNLwO8cRMEvUg@mail.gmail.com>

On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> The file testResults.xml which Juan added has
>
> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testText01WriteToFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testText02ReadFromFile"
> status="passed"/>
>
> So there is an issue of test setup which was not fullfilled in my case....
> Might be a Linux Mint issue (access rights)

The debugger indicated that I need Graphics-Files-Additional and in
fact the package header says this.

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/Tests.pck.st#L1

'From Cuis 4.2 of 25 July 2013 [latest update: #2424] on 18 July 2015
at 7:09:24.325834 pm'!
'Description Please enter a description for this package '!
!provides: 'Tests' 1 28!
!requires: 'Graphics-Files-Additional' 1 nil nil!
!requires: 'Compression' 1 nil nil!


> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>>> Hi Hannes,
>>>
>>> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>>>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>>>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>>>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>>>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>>> >>
>>>> >> > As Casey writes "The hard part is time and energy to do so."
>>>> >> >
>>>> >> > So what can be done with minimal effort and big impact?
>>>> >>
>>>> >> Looking around, I see that I could make some simple naming changes
>>>> >> for
>>>> >> test cases.
>>>> >>
>>>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>>>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>>>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>>>> >>
>>>> >> We could use other words, but API is shorter than Usage, Example,
>>>> >> Interface.
>>>> >>
>>>> >> Having specific test names end in 'API' would clue me in.
>>>> >>
>>>> >> Adding 'Nacl' means I can use the existing message finder to search
>>>> >> for
>>>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>>>> >> specific
>>>> >> to Nacl.
>>>> >>
>>>> >> And we can do this as I get the chance.
>>>> >>
>>>> >> Other suggestions?
>>>> >
>>>> > I started playing around with a couple of example test cases to see
>>>> > what
>>>> > I ran into and came up with a distinct class to store all of these
>>>> > per
>>>> > test category (i.e. under Test-Files a class ApiFile which could have
>>>> > a
>>>> > method testWriteTextFile)  The rationale was that it might make sense
>>>> > to
>>>> > keep these test cases separate from traditional test cases which are
>>>> > free to make calls that users of the class (i.e. who are calling the
>>>> > supported API) should not.
>>>>
>>>> Phil,
>>>>
>>>> where do you keep this class ApiFile?
>>>>
>>>
>>> It's in Packages/Tests.pck.st package. After loading it will be listed
>>> in the Tests-Files category.
>>
>>
>> I loaded the class ApiFile only and I get 3 tests passed and 1 failure
>> in Cuis 2.4-2424.
>>
>> Can you confirm this, Phil?
>>
>>>> regards
>>>>
>>>> Hannes
>>>>
>>>
>>> Thanks,
>>> Phil
>>>
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis-4.2-2424_ApiFile_SUnit_test_result_Screenshot from 2015-07-20 08:21:33.png
Type: image/png
Size: 20022 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/2ed77677/attachment-0004.png>

From pbpublist at gmail.com  Mon Jul 20 03:33:57 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 04:33:57 -0400
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
Message-ID: <1437381237.2286.13.camel@gmail.com>

On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
> The file testResults.xml which Juan added has
> 
> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
> status="passed"/>
> <testcase classname="ApiFile" name="testText01WriteToFile" status="passed"/>
> <testcase classname="ApiFile" name="testText02ReadFromFile" status="passed"/>
> 
> So there is an issue of test setup which was not fullfilled in my case....
> Might be a Linux Mint issue (access rights)
> 

I don't have the test in front of me right now but if I recall, the
setup code exists to create a temp directory in the same directory the
image was launched from to write the test files. (that was the best way
I could come up with to not introduce any platform-specific path
handling issues to the test)

If the setup code failed, then the test would have probably failed.  Did
you manually do anything or did it just work the 2nd time you ran it?
(if it re-ran successfully without you needing to do anything else, it
definitely sounds like a problem in the test setup.  If it were a rights
issue, it should have continued to fail.)

The good news is we're about to change all the file/directory handling
code so it needs to be updated anyway...

> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> Hi Hannes,
> >>
> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
> >>> >>
> >>> >> > As Casey writes "The hard part is time and energy to do so."
> >>> >> >
> >>> >> > So what can be done with minimal effort and big impact?
> >>> >>
> >>> >> Looking around, I see that I could make some simple naming changes
> >>> >> for
> >>> >> test cases.
> >>> >>
> >>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
> >>> >>
> >>> >> We could use other words, but API is shorter than Usage, Example,
> >>> >> Interface.
> >>> >>
> >>> >> Having specific test names end in 'API' would clue me in.
> >>> >>
> >>> >> Adding 'Nacl' means I can use the existing message finder to search
> >>> >> for
> >>> >> 'api' and note testNacl*API methods.  This lets me find API tests
> >>> >> specific
> >>> >> to Nacl.
> >>> >>
> >>> >> And we can do this as I get the chance.
> >>> >>
> >>> >> Other suggestions?
> >>> >
> >>> > I started playing around with a couple of example test cases to see
> >>> > what
> >>> > I ran into and came up with a distinct class to store all of these per
> >>> > test category (i.e. under Test-Files a class ApiFile which could have
> >>> > a
> >>> > method testWriteTextFile)  The rationale was that it might make sense
> >>> > to
> >>> > keep these test cases separate from traditional test cases which are
> >>> > free to make calls that users of the class (i.e. who are calling the
> >>> > supported API) should not.
> >>>
> >>> Phil,
> >>>
> >>> where do you keep this class ApiFile?
> >>>
> >>
> >> It's in Packages/Tests.pck.st package. After loading it will be listed
> >> in the Tests-Files category.
> >
> >
> > I loaded the class ApiFile only and I get 3 tests passed and 1 failure
> > in Cuis 2.4-2424.
> >
> > Can you confirm this, Phil?
> >
> >>> regards
> >>>
> >>> Hannes
> >>>
> >>
> >> Thanks,
> >> Phil
> >>
> >>
> >> _______________________________________________
> >> 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 hannes.hirzel at gmail.com  Mon Jul 20 03:45:53 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 08:45:53 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1437381237.2286.13.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
	<1437381237.2286.13.camel@gmail.com>
Message-ID: <CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>

The reason was

I only cherry picked the ApiFile class by manual loading.

After adding  Graphics-Files-Additional.pck.st manually it worked.

Another interesting test case is to write out a StrikeFont to the file
system in the proper
canonical export format (bmp and text) with a new name  and read it
back as a new font.

--Hannes

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
>> The file testResults.xml which Juan added has
>>
>> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
>> status="passed"/>
>> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
>> status="passed"/>
>> <testcase classname="ApiFile" name="testText01WriteToFile"
>> status="passed"/>
>> <testcase classname="ApiFile" name="testText02ReadFromFile"
>> status="passed"/>
>>
>> So there is an issue of test setup which was not fullfilled in my
>> case....
>> Might be a Linux Mint issue (access rights)
>>
>
> I don't have the test in front of me right now but if I recall, the
> setup code exists to create a temp directory in the same directory the
> image was launched from to write the test files. (that was the best way
> I could come up with to not introduce any platform-specific path
> handling issues to the test)
>
> If the setup code failed, then the test would have probably failed.  Did
> you manually do anything or did it just work the 2nd time you ran it?
> (if it re-ran successfully without you needing to do anything else, it
> definitely sounds like a problem in the test setup.  If it were a rights
> issue, it should have continued to fail.)
>
> The good news is we're about to change all the file/directory handling
> code so it needs to be updated anyway...
>
>> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >> Hi Hannes,
>> >>
>> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>> >>> >>
>> >>> >> > As Casey writes "The hard part is time and energy to do so."
>> >>> >> >
>> >>> >> > So what can be done with minimal effort and big impact?
>> >>> >>
>> >>> >> Looking around, I see that I could make some simple naming changes
>> >>> >> for
>> >>> >> test cases.
>> >>> >>
>> >>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
>> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>> >>> >>
>> >>> >> We could use other words, but API is shorter than Usage, Example,
>> >>> >> Interface.
>> >>> >>
>> >>> >> Having specific test names end in 'API' would clue me in.
>> >>> >>
>> >>> >> Adding 'Nacl' means I can use the existing message finder to
>> >>> >> search
>> >>> >> for
>> >>> >> 'api' and note testNacl*API methods.  This lets me find API tests
>> >>> >> specific
>> >>> >> to Nacl.
>> >>> >>
>> >>> >> And we can do this as I get the chance.
>> >>> >>
>> >>> >> Other suggestions?
>> >>> >
>> >>> > I started playing around with a couple of example test cases to see
>> >>> > what
>> >>> > I ran into and came up with a distinct class to store all of these
>> >>> > per
>> >>> > test category (i.e. under Test-Files a class ApiFile which could
>> >>> > have
>> >>> > a
>> >>> > method testWriteTextFile)  The rationale was that it might make
>> >>> > sense
>> >>> > to
>> >>> > keep these test cases separate from traditional test cases which
>> >>> > are
>> >>> > free to make calls that users of the class (i.e. who are calling
>> >>> > the
>> >>> > supported API) should not.
>> >>>
>> >>> Phil,
>> >>>
>> >>> where do you keep this class ApiFile?
>> >>>
>> >>
>> >> It's in Packages/Tests.pck.st package. After loading it will be listed
>> >> in the Tests-Files category.
>> >
>> >
>> > I loaded the class ApiFile only and I get 3 tests passed and 1 failure
>> > in Cuis 2.4-2424.
>> >
>> > Can you confirm this, Phil?
>> >
>> >>> regards
>> >>>
>> >>> Hannes
>> >>>
>> >>
>> >> Thanks,
>> >> Phil
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From pbpublist at gmail.com  Mon Jul 20 04:43:58 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 05:43:58 -0400
Subject: [Cuis] Canonical test cases?
In-Reply-To: <CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
	<1437381237.2286.13.camel@gmail.com>
	<CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>
Message-ID: <1437385438.2286.33.camel@gmail.com>

On Mon, 2015-07-20 at 08:45 +0000, H. Hirzel wrote:
> The reason was
> 
> I only cherry picked the ApiFile class by manual loading.
> 
> After adding  Graphics-Files-Additional.pck.st manually it worked.
> 

That would do it.  By adding 'manually' do you mean that you didn't have
the Graphics package downloaded at the time you loaded Tests?  That's
the only reason I can think of that the package manager wouldn't have
loaded Graphics for you automatically given the dependency.

> Another interesting test case is to write out a StrikeFont to the file
> system in the proper
> canonical export format (bmp and text) with a new name  and read it
> back as a new font.
> 

That's the sort of thing I was getting at with these tests: if there is
some useful bit of work that you need to be able to do (especially
something larger than a unit test and/or crossing package boundaries),
to create a test for it to help Juan understand the functionality we're
using.  This was one way I came up with to try to get to some sort of
agreed upon public API.  In retrospect, I probably put the cart before
the horse as doing all of these tests will take considerably longer than
initially flagging methods considered to be public.  But hopefully you
can see how doing both could complement each other.  To reiterate: this
work is on us to do up front, Juan would just review and commit.

> --Hannes
> 
> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> > On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
> >> The file testResults.xml which Juan added has
> >>
> >> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
> >> status="passed"/>
> >> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
> >> status="passed"/>
> >> <testcase classname="ApiFile" name="testText01WriteToFile"
> >> status="passed"/>
> >> <testcase classname="ApiFile" name="testText02ReadFromFile"
> >> status="passed"/>
> >>
> >> So there is an issue of test setup which was not fullfilled in my
> >> case....
> >> Might be a Linux Mint issue (access rights)
> >>
> >
> > I don't have the test in front of me right now but if I recall, the
> > setup code exists to create a temp directory in the same directory the
> > image was launched from to write the test files. (that was the best way
> > I could come up with to not introduce any platform-specific path
> > handling issues to the test)
> >
> > If the setup code failed, then the test would have probably failed.  Did
> > you manually do anything or did it just work the 2nd time you ran it?
> > (if it re-ran successfully without you needing to do anything else, it
> > definitely sounds like a problem in the test setup.  If it were a rights
> > issue, it should have continued to fail.)
> >
> > The good news is we're about to change all the file/directory handling
> > code so it needs to be updated anyway...
> >
> >> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> >> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> >> Hi Hannes,
> >> >>
> >> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
> >> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
> >> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
> >> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
> >> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
> >> >>> >>
> >> >>> >> > As Casey writes "The hard part is time and energy to do so."
> >> >>> >> >
> >> >>> >> > So what can be done with minimal effort and big impact?
> >> >>> >>
> >> >>> >> Looking around, I see that I could make some simple naming changes
> >> >>> >> for
> >> >>> >> test cases.
> >> >>> >>
> >> >>> >> E.g in package Crypto-Nacl there are test cases (class NaclTests)
> >> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
> >> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
> >> >>> >>
> >> >>> >> We could use other words, but API is shorter than Usage, Example,
> >> >>> >> Interface.
> >> >>> >>
> >> >>> >> Having specific test names end in 'API' would clue me in.
> >> >>> >>
> >> >>> >> Adding 'Nacl' means I can use the existing message finder to
> >> >>> >> search
> >> >>> >> for
> >> >>> >> 'api' and note testNacl*API methods.  This lets me find API tests
> >> >>> >> specific
> >> >>> >> to Nacl.
> >> >>> >>
> >> >>> >> And we can do this as I get the chance.
> >> >>> >>
> >> >>> >> Other suggestions?
> >> >>> >
> >> >>> > I started playing around with a couple of example test cases to see
> >> >>> > what
> >> >>> > I ran into and came up with a distinct class to store all of these
> >> >>> > per
> >> >>> > test category (i.e. under Test-Files a class ApiFile which could
> >> >>> > have
> >> >>> > a
> >> >>> > method testWriteTextFile)  The rationale was that it might make
> >> >>> > sense
> >> >>> > to
> >> >>> > keep these test cases separate from traditional test cases which
> >> >>> > are
> >> >>> > free to make calls that users of the class (i.e. who are calling
> >> >>> > the
> >> >>> > supported API) should not.
> >> >>>
> >> >>> Phil,
> >> >>>
> >> >>> where do you keep this class ApiFile?
> >> >>>
> >> >>
> >> >> It's in Packages/Tests.pck.st package. After loading it will be listed
> >> >> in the Tests-Files category.
> >> >
> >> >
> >> > I loaded the class ApiFile only and I get 3 tests passed and 1 failure
> >> > in Cuis 2.4-2424.
> >> >
> >> > Can you confirm this, Phil?
> >> >
> >> >>> regards
> >> >>>
> >> >>> Hannes
> >> >>>
> >> >>
> >> >> Thanks,
> >> >> Phil
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> 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
> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From hannes.hirzel at gmail.com  Mon Jul 20 07:31:22 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:31:22 +0000
Subject: [Cuis] Canonical test cases?
In-Reply-To: <1437385438.2286.33.camel@gmail.com>
References: <1424563348.6221.25.camel@gmail.com>
	<6896E607-2D5B-4915-83D2-807627116F69@generalmagic.at>
	<CAGQxfVjQpBuDB5LH4YfWnk+e92619MTEhRoot3Wy1FbfPxtaeQ@mail.gmail.com>
	<1424651066.2604.27.camel@gmail.com>
	<47F973D5-8B97-4775-AC81-B54F6DE7A914@gmail.com>
	<CAGQxfVj48HRWQfG7q8XVXxmgS-FpCj0XuLJCkQ=hGbOy5yCT1Q@mail.gmail.com>
	<20150223075340.b82426ccba7733ded7b9c881@whidbey.com>
	<1424720606.2231.10.camel@gmail.com>
	<CAGQxfVg-8mDUDh1ef+20TF-+AtJoyY=YkHeXcOB1HYtPKRkeiw@mail.gmail.com>
	<1437353009.6934.223.camel@gmail.com>
	<CAGQxfVjM1uaX=V7q_PwJ7cA=e+mLXNO3ug=7oMOiF47dTX-SVw@mail.gmail.com>
	<CAGQxfVgLYnb+kvnVcrhsPtUnzzB0gQQ61DXne1B36RZ3Kb6k9A@mail.gmail.com>
	<1437381237.2286.13.camel@gmail.com>
	<CAGQxfVhK3ZV5QQRwjjFntnrR+edetUzxvPiBSi592TWA88CATA@mail.gmail.com>
	<1437385438.2286.33.camel@gmail.com>
Message-ID: <CAGQxfViPQp2vBYh_To2nU05A5LVDF9VoAML1SMXbYH6Fm5KJzw@mail.gmail.com>

I think both is valuable and we need both

1. Doing larger tests like the 4 tests you did in ApiFile. They show
typical use cases.

2. flagging methods considered to be public. This can be done with a
test as well.
    Just a long list of checking with respondsTo: if a methods exist.



On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Mon, 2015-07-20 at 08:45 +0000, H. Hirzel wrote:
>> The reason was
>>
>> I only cherry picked the ApiFile class by manual loading.
>>
>> After adding  Graphics-Files-Additional.pck.st manually it worked.
>>
>
> That would do it.  By adding 'manually' do you mean that you didn't have
> the Graphics package downloaded at the time you loaded Tests?  That's
> the only reason I can think of that the package manager wouldn't have
> loaded Graphics for you automatically given the dependency.
>
>> Another interesting test case is to write out a StrikeFont to the file
>> system in the proper
>> canonical export format (bmp and text) with a new name  and read it
>> back as a new font.
>>
>
> That's the sort of thing I was getting at with these tests: if there is
> some useful bit of work that you need to be able to do (especially
> something larger than a unit test and/or crossing package boundaries),
> to create a test for it to help Juan understand the functionality we're
> using.  This was one way I came up with to try to get to some sort of
> agreed upon public API.  In retrospect, I probably put the cart before
> the horse as doing all of these tests will take considerably longer than
> initially flagging methods considered to be public.  But hopefully you
> can see how doing both could complement each other.  To reiterate: this
> work is on us to do up front, Juan would just review and commit.
>
>> --Hannes
>>
>> On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> > On Mon, 2015-07-20 at 08:16 +0000, H. Hirzel wrote:
>> >> The file testResults.xml which Juan added has
>> >>
>> >> <testcase classname="ApiFile" name="testImagePNG01WriteToFile"
>> >> status="passed"/>
>> >> <testcase classname="ApiFile" name="testImagePNG02ReadFromFile"
>> >> status="passed"/>
>> >> <testcase classname="ApiFile" name="testText01WriteToFile"
>> >> status="passed"/>
>> >> <testcase classname="ApiFile" name="testText02ReadFromFile"
>> >> status="passed"/>
>> >>
>> >> So there is an issue of test setup which was not fullfilled in my
>> >> case....
>> >> Might be a Linux Mint issue (access rights)
>> >>
>> >
>> > I don't have the test in front of me right now but if I recall, the
>> > setup code exists to create a temp directory in the same directory the
>> > image was launched from to write the test files. (that was the best way
>> > I could come up with to not introduce any platform-specific path
>> > handling issues to the test)
>> >
>> > If the setup code failed, then the test would have probably failed.
>> > Did
>> > you manually do anything or did it just work the 2nd time you ran it?
>> > (if it re-ran successfully without you needing to do anything else, it
>> > definitely sounds like a problem in the test setup.  If it were a
>> > rights
>> > issue, it should have continued to fail.)
>> >
>> > The good news is we're about to change all the file/directory handling
>> > code so it needs to be updated anyway...
>> >
>> >> On 7/20/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> >> > On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >> >> Hi Hannes,
>> >> >>
>> >> >> On Sun, 2015-07-19 at 23:52 +0000, H. Hirzel wrote:
>> >> >>> On 2/23/15, Phil (list) <pbpublist at gmail.com> wrote:
>> >> >>> > On Mon, 2015-02-23 at 07:53 -0800, Ken.Dickey wrote:
>> >> >>> >> On Mon, 23 Feb 2015 08:38:44 +0000
>> >> >>> >> "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>> >> >>> >>
>> >> >>> >> > As Casey writes "The hard part is time and energy to do so."
>> >> >>> >> >
>> >> >>> >> > So what can be done with minimal effort and big impact?
>> >> >>> >>
>> >> >>> >> Looking around, I see that I could make some simple naming
>> >> >>> >> changes
>> >> >>> >> for
>> >> >>> >> test cases.
>> >> >>> >>
>> >> >>> >> E.g in package Crypto-Nacl there are test cases (class
>> >> >>> >> NaclTests)
>> >> >>> >>   testExampleHighlevel -> testNaclHiglLevelAPI
>> >> >>> >>   textExampleLowLevel -> testNaclLowLevelAPI
>> >> >>> >>
>> >> >>> >> We could use other words, but API is shorter than Usage,
>> >> >>> >> Example,
>> >> >>> >> Interface.
>> >> >>> >>
>> >> >>> >> Having specific test names end in 'API' would clue me in.
>> >> >>> >>
>> >> >>> >> Adding 'Nacl' means I can use the existing message finder to
>> >> >>> >> search
>> >> >>> >> for
>> >> >>> >> 'api' and note testNacl*API methods.  This lets me find API
>> >> >>> >> tests
>> >> >>> >> specific
>> >> >>> >> to Nacl.
>> >> >>> >>
>> >> >>> >> And we can do this as I get the chance.
>> >> >>> >>
>> >> >>> >> Other suggestions?
>> >> >>> >
>> >> >>> > I started playing around with a couple of example test cases to
>> >> >>> > see
>> >> >>> > what
>> >> >>> > I ran into and came up with a distinct class to store all of
>> >> >>> > these
>> >> >>> > per
>> >> >>> > test category (i.e. under Test-Files a class ApiFile which could
>> >> >>> > have
>> >> >>> > a
>> >> >>> > method testWriteTextFile)  The rationale was that it might make
>> >> >>> > sense
>> >> >>> > to
>> >> >>> > keep these test cases separate from traditional test cases which
>> >> >>> > are
>> >> >>> > free to make calls that users of the class (i.e. who are calling
>> >> >>> > the
>> >> >>> > supported API) should not.
>> >> >>>
>> >> >>> Phil,
>> >> >>>
>> >> >>> where do you keep this class ApiFile?
>> >> >>>
>> >> >>
>> >> >> It's in Packages/Tests.pck.st package. After loading it will be
>> >> >> listed
>> >> >> in the Tests-Files category.
>> >> >
>> >> >
>> >> > I loaded the class ApiFile only and I get 3 tests passed and 1
>> >> > failure
>> >> > in Cuis 2.4-2424.
>> >> >
>> >> > Can you confirm this, Phil?
>> >> >
>> >> >>> regards
>> >> >>>
>> >> >>> Hannes
>> >> >>>
>> >> >>
>> >> >> Thanks,
>> >> >> Phil
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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
>> > 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 hannes.hirzel at gmail.com  Mon Jul 20 07:41:41 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:41:41 +0000
Subject: [Cuis] #printStringLimitedTo:
In-Reply-To: <1437285899.6934.1.camel@gmail.com>
References: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>
	<1437285899.6934.1.camel@gmail.com>
Message-ID: <CAGQxfVi0Sjj8YNfYBxDKwa4sqWHJnAbApWfgHOOHdUy72nZYPA@mail.gmail.com>

Ken you ask about other options

one would be to have a method


#printStringLimitedTo:suffix:

so that people can have their own suffix.

Might be better in a multilingual environment.

However  '...etc...' is pretty general.

No objection if it stays as is.

--HH

On 7/19/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Sat, 2015-07-18 at 21:33 -0700, Ken.Dickey wrote:
>> I find it kind of odd that #printStringLimitedTo: takes the prefix of a
>> too-long string and adds '...etc...', which itself is 9 characters.
>>
>> I think a shorter addition would make more sense.  After all, the string
>> is already too long, right?
>>
>> I like '[..]' , which is only four characters.
>>
>> Would anyone else like to weigh in on this?  Other options?
>
> I agree that the current suffix is long-ish and like your [..] idea as
> that's unlikely to appear in the majority of strings but would still
> convey the information.
>
>> -KenD
>>
>> _______________________________________________
>> 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 hannes.hirzel at gmail.com  Mon Jul 20 07:47:19 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:47:19 +0000
Subject: [Cuis] Baseline version?
In-Reply-To: <4CA2DB35-1A26-46CE-B5D1-ACB50DC642B0@mac.com>
References: <mailman.94.1437354099.18328.cuis_jvuletich.org@jvuletich.org>
	<4CA2DB35-1A26-46CE-B5D1-ACB50DC642B0@mac.com>
Message-ID: <CAGQxfVhUXD_P8Tz7vqGh_9U=8C+WcPJKvSqtizMH-yLNNTcKQg@mail.gmail.com>

 http://netjam.org/versions/ is pretty general.

I would be fine with a very simple scheme these days. Just two
releases per year.

--HH

On 7/20/15, Ken G. Brown <kbrown at mac.com> wrote:
> Craig Latta has a nice write up about his decent looking versioning system
> for Spoon: http://netjam.org/versions/
>
> Ken G. Brown
>
>> Date: Sun, 19 Jul 2015 23:01:22 +0000
>> From: "H. Hirzel" <hannes.hirzel at gmail.com>
>> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
>> Subject: [Cuis] Baseline version?
>> Message-ID:
>>    <CAGQxfVg7XkxDx0GXRzbM-g-efzvVKeafy3H5DzNJdjkzTwxDUg at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>>> On 7/19/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
>>> On Sun, 19 Jul 2015 11:20:19 -0300
>> ....
>>> I'd like to propose a simpler model based on the Smalltalk Way.
>>>
>>> We take any stable revision, call it a version, give it a Baseline
>>> Version
>>> Number (could be just the development version number).
>>
>> I'd like to suggest to label just the current version as a "baseline".
>>
>> It would not need a long description, just a few keywords regarding
>> major changes like the addition of the FileMan package with a
>> reference to the description of it.
>>
>> The last one
>> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
>>
>> had
>>
>> New in Cuis 4.2 (released July 25, 2013)
>>
>>    Packages now have dependencies
>>
>>    Package loading greatly enhanced
>>
>>    Moved non-essential stuff to optional packages. Cuis is now below
>> 500 classes and 100kLOC. Reduction was about 25%
>>
>>    Many bugfixes, and minor enhancements and cleanup
>>
>>
>> So this one would have
>>
>> New in Cuis 4.3 (released July 25, 2015)
>>
>>     Many bugfixes, and minor enhancements and cleanup
>>
>>     Addition of FileMan
>>
>>    .....................
>>
>>    .......................
>>
>>
>>    .....................
>>
>>    .......................
>>
>>
>>
>> And then after testing various packages on it
>> another baseline at the end of the year with a release document.
>>
>> New in Cuis 4.4 (released December 31, 2015)
>>
>>     Many bugfixes, and minor enhancements and cleanup
>>
>>    .....................
>>
>>    .....................
>>
>>    .......................
>>
>>
>>    .....................
>>
>>    .......................
>>
>>    .....................
>>
>>    .......................
>>
>>
>> More text as we will be more aware of the changes.
>>
>>
>>
>>> Each Baseline
>>> Release has a release document which describes major changes since the
>>> previous baseline.  This document is a light-weight description.
>>>
>>> Each baseline release starts a new fork.  The only changes to the
>>> particular
>>> baseline release are bug fixes.
>>>
>>> Nice users test their packages and likewise fork a Package Release which
>>> matches a Baseline Release.  This fork also only changes with bug fixes,
>>> and
>>> only in synch with its particular baseline.  Baseline packages Feature
>>> the
>>> baseline release.
>>>
>>> So we forge ahead as usual, once in a while we say "enough has changed
>>> that
>>> we should re-baseline", do a new Baseline Release, test and release our
>>> Package Releases, then again move on forward.
>>>
>>> Anyone can now pick any baseline release, require any associated
>>> packages,
>>> and ship/demo without fear.
>>>
>>> Anyone with the time, energy, and interest can document baseline APIs to
>>> whatever level they feel comfortable.
>>>
>>> Anyone can forge on ahead with the latest revision(s) with the usual
>>> "here
>>> be dragons, but also gold".
>>>
>>> $0.02
>>> -KenD
>>>
>>> _______________________________________________
>>> 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 hannes.hirzel at gmail.com  Mon Jul 20 07:55:57 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 12:55:57 +0000
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <1437354098.6934.240.camel@gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>
	<55A90799.7080302@jvuletich.org>
	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>
	<CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>
	<1437354098.6934.240.camel@gmail.com>
Message-ID: <CAGQxfVjzR=pG2i4+RakCiNZKJ6EMTJGkXu5sX2OAdiMCjS24GQ@mail.gmail.com>

Yes,

an image diff to see what classes/methods changed between timer period X and Y

is what I am looking for.

--Hannes

On 7/20/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Sun, 2015-07-19 at 20:21 +0000, H. Hirzel wrote:
>> If I take a current image (18 Jul 2015, 4.2-2424)  I get the same result
>>
>>
>> a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
>> #at:ifAbsent:)
>>
>> All the FileMan additions are not listed. Maybe because they keep
>> their original time stamp, not the time stamp of the addition to
>> Squeak.
>>
>
> Right, the timestamp will reflect when they were last edited rather than
> when they were loaded into the image.
>
>> And the recent change on #compilerClass does not show up.
>>
>
> Same situation: #compilerClass while only recently re-added to the
> image, hasn't actually been changed since it was removed and added back
> so it still shows an older timestamp.
>
> It sounds like you're looking for more of an image diff to see what
> classes/methods changed between timer period X and Y?  This isn't
> something that currently exists in an easy to use form that I'm aware
> of.
>
>> --HH
>>
>> On 7/19/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> > If I use this to find out which methods have a time stamp date
>> > indicating a change after the 1st of January 2015 in a pristine Cuis
>> > 4.2-2243 (17 April 2015) image I find out that only the
>> >
>> > #postCopy method was changed (probably added) in nearly all classes.
>> >
>> > If I change the base line date to 1st of January 2014 I get
>> >
>> > a Set(#collect: #at:ifPresent: #at:ifPresent:ifAbsent: #postCopy
>> > #at:ifAbsent:)
>> > as changed/updated methods (i.e. methods which have a time stamp in
>> > this period).
>> >
>> > Of course this assumes that a method gets a time stamp when changed.
>> > Many methods have nil as a time stamp.
>> >
>> >
>> > Could somebody from the list check this please?
>> >
>> >
>> > |date coll baseLineDate dt  updatedMethods |
>> >
>> > baseLineDate := Date year: 2014 month: 1 day: 1.
>> > coll := OrderedCollection new.
>> >
>> > Smalltalk allClasses do: [ :cls |
>> > cls allSelectors do: [ :sel |
>> > dt := VersionsBrowser timeStampFor:  sel class: Dictionary
>> > reverseOrdinal:
>> > 1.
>> >
>> > dt notNil ifTrue: [
>> > date := dt select:  [ :ch | (((ch isDigit) or: [ch = $/ ]) or: [ch = $
>> > ]) or: [ch = $:]] .
>> > (date = '') ifFalse:
>> > 	[date := Date fromString: date.
>> > 		(date > baseLineDate) ifTrue: [coll add: (Association key:
>> > (Association key: cls value: sel) value: date)
>> > ]]].
>> >
>> > ]].
>> >
>> > updatedMethods := Set new.
>> > coll do: [ :elem | updatedMethods add: (elem key value)].
>> > coll inspect.
>> > updatedMethods inspect
>> >
>> >
>> >
>> >
>> > On 7/17/15, Juan Vuletich <juan at jvuletich.org> wrote:
>> >> On 7/16/2015 11:49 AM, H. Hirzel wrote:
>> >>> Hello
>> >>>
>> >>> I'd like to do a query finding out about the time stamp of  source
>> >>> code changes of all methods in the Cuis image and then do a list with
>> >>> the following four columns
>> >>>
>> >>>
>> >>> ClassTheMethodBelongsTo, PackageTheClassBelongsTo, MethodName,
>> >>> DateOfChange
>> >>>
>> >>> Help is appreciated.
>> >>>
>> >>> Hannes
>> >>
>> >> Check #timeStampFor:class:reverseOrdinal: and in general
>> >> #annotationForSelector:ofClass:
>> >>
>> >> Cheers,
>> >> Juan Vuletich
>> >>
>> >
>> _______________________________________________
>> 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 Ken.Dickey at whidbey.com  Mon Jul 20 08:55:45 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 20 Jul 2015 06:55:45 -0700
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437352771.6934.219.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
Message-ID: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>

On Sun, 19 Jul 2015 20:39:31 -0400
"Phil (list)" <pbpublist at gmail.com> wrote:

> The issue is what constitutes a major change?  If your code uses it it's
> major, if mine uses it it's minor?  Coin toss?  Without a public API
> what is considered major is either obvious (i.e. Morphic changes from
> global to local coords or changing the File/Directory API so obviously
> everything using them breaks) or arbitrary (sorry to hear that you
> depended on that... but it wasn't major, now it's gone)  If the image
> snapshot is considered the public API, then everything must be both
> considered fair game to depend on and to change in the future which is
> unmanageable.

I don't think this is the issue at all. 

The text editor comes up in every release with goals for Cuis.  Backward compatibility is a stated non-goal.

I am happy to baseline my packages a couple of times a year against a baseline core release and maintain such matched baseline package releases.

I trust Juan's leadership and judgment. His time is a scarce and valuable resource.  He is very responsive to the Cuis community, including requests for backward compatibility and additional support.  I do _not_ want to slow him down.

If you have specific requirements, a package with Feature/Unit-tests is a good way to express this.

> I'm not trying to restrict Juan in any way from making the changes he
> thinks are important for Cuis.  His taste and direction have been
> generally excellent and the reason I'm here!  If for example, he decides
> that #drawOn: is no longer the way to do things or that even Morph
> needed to go away, that's fine as long as what's going on gets
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.

Pardon me, but this sounds exactly like you are trying to restrict certain changes.

It seems that you are trying to "plan" and "rule set" rather than "discover quickly".

My experience is that quick discovery (like writing unit tests and running them very frequently) is the fastest development path.

My guess is that major packages which prove useful will either migrate into the core packages or will be tested against as part of a larger release process.  I just prefer that process to be as small and painless (low drag) as possible.

If some package is not in wide use, the author can test against releases as often as he/she feels it necessary.  We can deal with breakage as it arises rather than planning search strategies for avoiding breakage.  For me, this is much more efficient.

Having API test suites is a good way to communicate importance.


As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful.  I heard that the Arabic word for "miracle" literally translates to "breaking the habit".  Interesting thought.

In the limit, we may be "agreeing loudly" here.  Easy to sound strident in an email.  Not the intent.


What is the simplest thing that will work?
-KenD



From hannes.hirzel at gmail.com  Mon Jul 20 12:26:42 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 17:26:42 +0000
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
Message-ID: <CAGQxfVisvidGE440ZhSTcC=RHjcU2Ega4_uUwh_j-QpdosRFNw@mail.gmail.com>

On 7/20/15, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> On Sun, 19 Jul 2015 20:39:31 -0400
> "Phil (list)" <pbpublist at gmail.com> wrote:
>
>> The issue is what constitutes a major change?  If your code uses it it's
>> major, if mine uses it it's minor?  Coin toss?  Without a public API
>> what is considered major is either obvious (i.e. Morphic changes from
>> global to local coords or changing the File/Directory API so obviously
>> everything using them breaks) or arbitrary (sorry to hear that you
>> depended on that... but it wasn't major, now it's gone)  If the image
>> snapshot is considered the public API, then everything must be both
>> considered fair game to depend on and to change in the future which is
>> unmanageable.
>
> I don't think this is the issue at all.
>
> The text editor comes up in every release with goals for Cuis.  Backward
> compatibility is a stated non-goal.
>
> I am happy to baseline my packages a couple of times a year against a
> baseline core release and maintain such matched baseline package releases.

+1

> I trust Juan's leadership and judgment. His time is a scarce and valuable
> resource.  He is very responsive to the Cuis community, including requests
> for backward compatibility and additional support.  I do _not_ want to slow
> him down.


+1

> If you have specific requirements, a package with Feature/Unit-tests is a
> good way to express this.


+1

>> I'm not trying to restrict Juan in any way from making the changes he
>> thinks are important for Cuis.  His taste and direction have been
>> generally excellent and the reason I'm here!  If for example, he decides
>> that #drawOn: is no longer the way to do things or that even Morph
>> needed to go away, that's fine as long as what's going on gets
>> communicated.


+1

However, a problem I think he faces right now is that he
>> doesn't know who's using / depending on what.
>
> Pardon me, but this sounds exactly like you are trying to restrict certain
> changes.
>
> It seems that you are trying to "plan" and "rule set" rather than "discover
> quickly".
>
> My experience is that quick discovery (like writing unit tests and running
> them very frequently) is the fastest development path.
>
> My guess is that major packages which prove useful will either migrate into
> the core packages or will be tested against as part of a larger release
> process.  I just prefer that process to be as small and painless (low drag)
> as possible.
>
> If some package is not in wide use, the author can test against releases as
> often as he/she feels it necessary.  We can deal with breakage as it arises
> rather than planning search strategies for avoiding breakage.  For me, this
> is much more efficient.
>
> Having API test suites is a good way to communicate importance.

+1

>
> As an aside, I have found some breakage to be very enlightening and
> (sometimes painfully) helpful.  I heard that the Arabic word for "miracle"
> literally translates to "breaking the habit".  Interesting thought.
>
> In the limit, we may be "agreeing loudly" here.  Easy to sound strident in
> an email.  Not the intent.
>
>
> What is the simplest thing that will work?
> -KenD


Probably the easiest is that Juan goes on as he is used to and a
release manager or release team forks off a release / baseline from
time to time.

This allows for documenting an artifact which is no longer moving.
Selected updates might be applied to the release until the next release is due.

The documentation will got later on merged into the main branch as well.

Hannes



From peter at aba-instituut.nl  Mon Jul 20 16:32:46 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Mon, 20 Jul 2015 23:32:46 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
Message-ID: <CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>

On Mon, Jul 20, 2015 at 3:55 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

>
> If you have specific requirements, a package with Feature/Unit-tests is a
> good way to express this.
>

I was thinking: "What should a Feature Test be?". I tried to look up what
others have written, but found nothing useful (I probably did not look hard
enough). Now, I don't mind thinking of something new, so here goes:

1. Clearly (to me), it should not be a kind of Unit Test. When you run a
unit test, you assume that the unit under test is present in the system and
you are trying to ascertain if it does certain things you expect. For this,
unit tests have built-in facilities to detect execution errors and failed
expectations, If such problems happen, unit tests are able to continue the
testing process and report on the problems that occurred after the tests
are run (this is the step forward that SUnit - or TSTTestingFramework as it
ws known at the time - brought).

2. On the other hand, when you run a Feature Test, you may be testing one
or more units, and one or more (or all) of those might not even be present.
Therefore, a feature test should be able to run even if in the absence of
the unit(s) supposed to implement the feature. So then, perhaps what a
class FeatureTest should offer its subclasses, is a #run: aString method
that tries to compile aString and if it compiles, execute it and look for
any foreseen side effects and/or expression value.

a test method might then look like:

testApiReceiverIsPresentAndCanBeSetUp

self run: 'ApiReceiver version > ''1.1.4''' expectEvaluationResult: true
.
self run: 'ApiReceiver setUp'
.
self expectSideEffect: 'ExpectedApiReceiver isSetUp'

3. Then it should be able to report that everything went well, or that
there was a problem compiling (ideally with detailed info such as 'global
Xxx was expected but was not present in the system'. If compiling went
well, the execution should be protected and monitored similarly to unit
tests that are already able to catch exceptions during execution.

4. Perhaps something along these lines would be the simplest thing that
could possibly work?

Would it help anyone if they had the FeatureTest class that they could
subclass and as a result they could always, safely, test if some feature
was present and did what you needed/expected of it? And you could have a
Feature Test Runner that ran your feature test, made sure nothing crashed,
and reported the results in a useful fashion.

Just some thoughts, cheers, Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/9cfb5cc4/attachment-0004.html>

From d.a.tennant.2009 at gmail.com  Mon Jul 20 17:18:13 2015
From: d.a.tennant.2009 at gmail.com (David Tennant)
Date: Mon, 20 Jul 2015 16:18:13 -0600
Subject: [Cuis] Embedding morphs at specific points in a morph?
Message-ID: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>

Hi everyone.
I have been playing arrowed with cuis for a couple of years, but I am
extremely horrible at it. Every time I attempt to code a program I don't
get too far, but this time I want to actually make a program that works. So
I am trying to make a program that you can play mancala with. Mancala is an
abstract board game.
I decided that I should build the board first. the board should look
something like this
http://ecx.images-amazon.com/images/I/51PD0CemQkL._SY300_.jpg . I wanted
the circles and ovals to be separate classes so that I have more
flexibility later. I have 3 classes: Board, BigEllipse, and CircleEllipse.
In BigEllipse and CircleEllipse I just have initialization stuff, like size
and color. in Board I have the initialization stuff too, but I also have
what I thought would create the board, but It does not work. there are two
methods, one I called "addMyEllipse" and th other I called
"addScoreEllipse". these are the methods

addMyEllipse
|n|

    myEllipse:= CircleEllipse new.
        n:=1.
        (1to:12) do:[
            (n<7)
            ifTrue: [self addMorph: (myEllipse at: 35@(35+(60*n)))]
            ifFalse: [self addMorph: (myEllipse at: 110@(35+(60*n)))].
            n:= (n+1).
        ].
note: myEllipse is an instance variable.

addScoreEllipse
| n|

    scoreEllipse:= BigEllipse new.
    n:=1.
    (1to:2) do:[
        (n=1)
        ifTrue:[self addMorph:(scoreEllipse at: 72.5 at 35)]
        ifFalse:[self addMorph:(scoreEllipse at: 72.5 at 455)].
        n=(n+1).
    ].
note: scoreEllipse is an instance variable.

I don't actually know what is wrong. when I type in the workspace: Board
new openInWorld. I just get the background of the board, no ellipses. and
when I type in the workspace: test:= Board new openInWorld. test
addMyEllipse. I get an error that says, this block accepts 0 arguments, but
was called with 1 argument.

Thank you for your time
-- 
David Tennant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/1108b143/attachment-0004.html>

From juan at jvuletich.org  Mon Jul 20 17:33:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 19:33:27 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AC4B3F.19938.1F92268@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>,
	<55ABA6A2.5090607@jvuletich.org>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
Message-ID: <55AD7737.30003@jvuletich.org>

Hi Dan,

On 7/19/2015 10:13 PM, Dan Norton wrote:
> On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>
> > On 7/18/2015 3:37 PM, Dan Norton wrote:
> > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
> > >
> > >> Hi Folks,
> > >>
> > >> It is not too hard to build new StrikeFonts. You need to build,
> > by
> > >> hand,
> > >> files like the ones in here:
> > >>
> > https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> > >> p
> > >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
> > with
> > >> this method and the files in this zip that built the existing
> > >> instances
> > >> of StrikeFont. Not sure.
> > >>
> > > That's intrigueing but I can't reproduce it. Maybe the .bmp but
> > where did you get the .txt?
> > >
> > >   - Dan
> >
> > I wrote them with a text editor. Check #installDejaVu2 and really
> > try to
> > understand how StrikeFonts work and how they are built with this
> > method.
> > Maybe you'll become enlightened.
> >
>
> A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name, 
> and several scalars. StrikeFont class methods create fonts by 
> processing file pairs assumed to be in the "AAFonts" subdirectory. For 
> example:
>
> DejaVu Sans Oblique 14.bmp
> DejaVu Sans Oblique 14.txt
>
> Is one such pair providing the italic (oblique) style for 14-point 
> size. There is a pair for every font size and style: base, bold, 
> italic, and bold italic. Therefore a font such as "DejaVu Sans" which 
> is available in the size interval 5 to 24 requires 160 files. The file 
> names are stylized and encoded in the StrikeFont class methods.
>
> Glyphs come from the .bmp file. The .txt file is a string of numbers; 
> the first three specify pointSize, ascent, and descent. The rest of 
> the numbers in the .txt file are used to form the xTable, which is the 
> index into the glyphs for a character. The characterToGlyphMap is an 
> array of 256 entries which map a character's ascii value to the xTable 
> and thence to the glyphs.
>
> The bold, italic, and bold italic styles are stashed as derivatives of 
> the base and not selectable from the current menus.
>
> StrikeFont is a subclass of AbstractFont, which has class variables 
> AvailableFonts and DefaultFont.
>
> If it can't find a file, StrikeFont will loop.

Great! You got it all.

> In regard to creating the .bmp and .txt files, you say, " I wrote them 
> with a text editor." Please tell me which text editor you used. None 
> of mine do that.

The bmp files can be created with screen capture program, after entering 
suitable text in it. Maybe you need to stitch several pieces together, 
etc. WRT the txt files, well, the editor didn't do it for me. I wrote 
them. I _typed_ them. Maybe I used some (long lost) code to look for 
white columns separating glyphs, but I'm not really sure. 
#xTallyPixelValue:orNot: and friends are great for this kind of stuff.

In any case, it will be easier for you, as you want a monospaced font. 
Printing something like (32 to: 255) collect: [ :ascii | ascii-32 * 9 ] 
into the file might be enough.

You have all the pieces at hand. it just requires a bit of patience.

Cheers,
Juan Vuletich

>  - Dan
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/8664adb8/attachment-0004.html>

From hannes.hirzel at gmail.com  Mon Jul 20 18:33:31 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 20 Jul 2015 23:33:31 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AD7737.30003@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AA9CDC.1049.11EE4D8@dnorton.mindspring.com>
	<55ABA6A2.5090607@jvuletich.org>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
	<55AD7737.30003@jvuletich.org>
Message-ID: <CAGQxfViL7p7GieO3zwYRQpboqeMnfiiQdATeok1rZTeGmrCijw@mail.gmail.com>

https://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format

The Glyph Bitmap Distribution Format (BDF) by Adobe is a file format
for storing bitmap fonts. The content takes the form of a text file
intended to be human- and computer-readable. BDF is typically used in
Unix X Window environments.

Squeak contains a BDFFontReader

<class comment>
I am a conversion utility for reading X11 Bitmap Distribution Format
fonts.  My code is derived from the multilingual Squeak changeset
written by OHSHIMA Yoshiki (ohshima at is.titech.ac.jp), although all
support for fonts with more than 256 glyphs has been ripped out.  See
http://www.is.titech.ac.jp/~ohshima/squeak/squeak-multilingual-e.html
.

My class methods contain tools for fetching BDF source files from a
well-known archive site, batch conversion to Squeak's .sf2 format, and
installation of these fonts as TextStyles.  Also, the legal notices
for the standard 75dpi fonts I process this way are included as
"x11FontLegalNotices'.
</class comment>

The URL no longer works, but the Squeak wiki

http://wiki.squeak.org/squeak/696

has more on fonts.

I have loaded BDF fonts into Squeak in the past and I assume the
Squeak StrikeFonts and the Cuis StrikeFonts are still compatible.

--Hannes

On 7/20/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Dan,
>
> On 7/19/2015 10:13 PM, Dan Norton wrote:
>> On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>>
>> > On 7/18/2015 3:37 PM, Dan Norton wrote:
>> > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>> > >
>> > >> Hi Folks,
>> > >>
>> > >> It is not too hard to build new StrikeFonts. You need to build,
>> > by
>> > >> hand,
>> > >> files like the ones in here:
>> > >>
>> > https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> > >> p
>> > >> and learn a bit about stuff like #installDejaVu2 . Maybe it was
>> > with
>> > >> this method and the files in this zip that built the existing
>> > >> instances
>> > >> of StrikeFont. Not sure.
>> > >>
>> > > That's intrigueing but I can't reproduce it. Maybe the .bmp but
>> > where did you get the .txt?
>> > >
>> > >   - Dan
>> >
>> > I wrote them with a text editor. Check #installDejaVu2 and really
>> > try to
>> > understand how StrikeFonts work and how they are built with this
>> > method.
>> > Maybe you'll become enlightened.
>> >
>>
>> A StrikeFont consists of a characterToGlyphMap, xTable, glyphs, name,
>> and several scalars. StrikeFont class methods create fonts by
>> processing file pairs assumed to be in the "AAFonts" subdirectory. For
>> example:
>>
>> DejaVu Sans Oblique 14.bmp
>> DejaVu Sans Oblique 14.txt
>>
>> Is one such pair providing the italic (oblique) style for 14-point
>> size. There is a pair for every font size and style: base, bold,
>> italic, and bold italic. Therefore a font such as "DejaVu Sans" which
>> is available in the size interval 5 to 24 requires 160 files. The file
>> names are stylized and encoded in the StrikeFont class methods.
>>
>> Glyphs come from the .bmp file. The .txt file is a string of numbers;
>> the first three specify pointSize, ascent, and descent. The rest of
>> the numbers in the .txt file are used to form the xTable, which is the
>> index into the glyphs for a character. The characterToGlyphMap is an
>> array of 256 entries which map a character's ascii value to the xTable
>> and thence to the glyphs.
>>
>> The bold, italic, and bold italic styles are stashed as derivatives of
>> the base and not selectable from the current menus.
>>
>> StrikeFont is a subclass of AbstractFont, which has class variables
>> AvailableFonts and DefaultFont.
>>
>> If it can't find a file, StrikeFont will loop.
>
> Great! You got it all.
>
>> In regard to creating the .bmp and .txt files, you say, " I wrote them
>> with a text editor." Please tell me which text editor you used. None
>> of mine do that.
>
> The bmp files can be created with screen capture program, after entering
> suitable text in it. Maybe you need to stitch several pieces together,
> etc. WRT the txt files, well, the editor didn't do it for me. I wrote
> them. I _typed_ them. Maybe I used some (long lost) code to look for
> white columns separating glyphs, but I'm not really sure.
> #xTallyPixelValue:orNot: and friends are great for this kind of stuff.
>
> In any case, it will be easier for you, as you want a monospaced font.
> Printing something like (32 to: 255) collect: [ :ascii | ascii-32 * 9 ]
> into the file might be enough.
>
> You have all the pieces at hand. it just requires a bit of patience.
>
> Cheers,
> Juan Vuletich
>
>>  - Dan
>>
>
>



From dnorton at mindspring.com  Mon Jul 20 18:55:38 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 19:55:38 -0400
Subject: [Cuis] Embedding morphs at specific points in a morph?
In-Reply-To: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
References: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
Message-ID: <55AD8A7A.26397.2436C64@dnorton.mindspring.com>

On 20 Jul 2015 at 16:18, David Tennant wrote:

> 
> Hi everyone.
> I have been playing arrowed with cuis for a couple of years, but I
> am extremely horrible at it. Every 
> time I attempt to code a program I don't get too far, but this time
> I want to actually make a 
> program that works. So I am trying to make a program that you can
> play mancala with. Mancala is 
> an abstract board game.
> I decided that I should build the board first. the board should look
> something like this 
> http://ecx.images-amazon.com/images/I/51PD0CemQkL._SY300_.jpg . I
> wanted the circles and 
> ovals to be separate classes so that I have more flexibility later.
> I have 3 classes: Board, 
> BigEllipse, and CircleEllipse. In BigEllipse and CircleEllipse I
> just have initialization stuff, like size 
> and color. in Board I have the initialization stuff too, but I also
> have what I thought would create 
> the board, but It does not work. there are two methods, one I called
> "addMyEllipse" and th other I 
> called "addScoreEllipse". these are the methods
> ?
> addMyEllipse
> |n|
> 
> ??? myEllipse:= CircleEllipse new.
> ??? ??? n:=1.
> ??? ??? (1to:12) do:[
> ??? ??? ??? (n<7)
> ??? ??? ??? ifTrue: [self addMorph: (myEllipse at:
> 35@(35+(60*n)))]
> ??? ??? ??? ifFalse: [self addMorph: (myEllipse at:
> 110@(35+(60*n)))].
> ??? ??? ??? n:= (n+1).
> ??? ??? ].
> note: myEllipse is an instance variable.
> 
> addScoreEllipse
> | n|
> 
> ??? scoreEllipse:= BigEllipse new.
> ??? n:=1.
> ??? (1to:2) do:[
> ??? ??? (n=1)
> ??? ??? ifTrue:[self addMorph:(scoreEllipse at: 72.5 at 35)]
> ??? ??? ifFalse:[self addMorph:(scoreEllipse at: 72.5 at 455)].
> ??? ??? n=(n+1).
> ??? ].
> note: scoreEllipse is an instance variable.
> 
> I don't actually know what is wrong. when I type in the workspace:
> Board new openInWorld. I just 
> get the background of the board, no ellipses. and when I type in the
> workspace: test:= Board new 
> openInWorld. test addMyEllipse. I get an error that says, this block
> accepts 0 arguments, but was 
> called with 1 argument.
> 
>
I had the same problem recently in some code that looked like this:

ifExistsDo: [{italicName. ' OK'} print]

The cure was to "expect" an argument, even tho it would not be used:

ifExistsDo: [:x | {italicName. ' OK'} print]

Thanks to Phil for staightening me out.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/6f694e3a/attachment-0004.html>

From dnorton at mindspring.com  Mon Jul 20 19:32:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 20:32:56 -0400
Subject: [Cuis] Terse Guide to Pen, Forms
Message-ID: <55AD9338.29402.26592D8@dnorton.mindspring.com>

Hello,

The Pen and Forms topics in Terse Guide no longer work. For example:

| x y |
x := Form dotOfSize: 20.	"Make a form containing a dot (as yet unseen)."
x displayAt: 500 at 200.		"Cause the form to appear at a point on the display."
Display restore.			"Erase what was displayed."

#displayAt: doesn't.

Similar problems with "Display fillWhite" in the Pen topic.

 - Dan



From juan at jvuletich.org  Mon Jul 20 20:07:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:07:01 -0300
Subject: [Cuis] Time stamp of source code change of a method?
In-Reply-To: <CAGQxfVjzR=pG2i4+RakCiNZKJ6EMTJGkXu5sX2OAdiMCjS24GQ@mail.gmail.com>
References: <CAGQxfVgxUrE04wb06ELaZo9qOKhvJ0Gzi2rycqwfGUL2JpLO-g@mail.gmail.com>	<55A90799.7080302@jvuletich.org>	<CAGQxfViGQRM_B88ucAR8gCJPd9Gk3CiX_roXB6D3Kjaoh2aFGw@mail.gmail.com>	<CAGQxfVgGY+dX2d9cW4Qj8YvS3s--f8+97nq4aVZxCS8kASWaBQ@mail.gmail.com>	<1437354098.6934.240.camel@gmail.com>
	<CAGQxfVjzR=pG2i4+RakCiNZKJ6EMTJGkXu5sX2OAdiMCjS24GQ@mail.gmail.com>
Message-ID: <55AD9B35.5010805@jvuletich.org>

Hi Hannes,

On 7/20/2015 9:55 AM, H. Hirzel wrote:
> Yes,
>
> an image diff to see what classes/methods changed between timer period X and Y
>
> is what I am looking for.
>
> --Hannes

That is easy.

In the newer image, evaluate: SystemOrganization fileOutAllCategories.

Now start the older image. (you might need to file in the attach if you 
get a walkback) Open a File list. Click on the *AllCode.st file 
generated in the newer image. Click on [contents]. Select "No".

Right click on the change list. 'remove up-to-date versions'.

"Right click again. Select methods equivalent to current". "Remove 
selected items".

You can study them right there. Or you can "select all" "file out 
selections". Then select this file in the file list and click on [code] 
and use this view instead. In any of these ways, it is reasonable easy 
to see how much changed, and check each change if desired.

Or you can come up with your own new and creative ways to use the tools 
in the system :)

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2425-privateReadSelector-fix-JuanVuletich-2015Jul20-19h44m-jmv.1.cs.zip
Type: application/zip
Size: 662 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/0304b3af/attachment-0004.zip>

From juan at jvuletich.org  Mon Jul 20 20:21:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:21:34 -0300
Subject: [Cuis] Terse Guide to Pen, Forms
In-Reply-To: <55AD9338.29402.26592D8@dnorton.mindspring.com>
References: <55AD9338.29402.26592D8@dnorton.mindspring.com>
Message-ID: <55AD9E9E.7020407@jvuletich.org>

Hi Dan,

This is a bug I introduced when speeding up Transcript maybe a month 
ago. I'll fix it soon (max 2 days).

Thanks for reporting.

Cheers,
Juan Vuletich

On 7/20/2015 9:32 PM, Dan Norton wrote:
> Hello,
>
> The Pen and Forms topics in Terse Guide no longer work. For example:
>
> | x y |
> x := Form dotOfSize: 20.	"Make a form containing a dot (as yet unseen)."
> x displayAt: 500 at 200.		"Cause the form to appear at a point on the display."
> Display restore.			"Erase what was displayed."
>
> #displayAt: doesn't.
>
> Similar problems with "Display fillWhite" in the Pen topic.
>
>   - Dan
>




From juan at jvuletich.org  Mon Jul 20 20:28:44 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:28:44 -0300
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <559AA0A2.13962.3B4CD8@dnorton.mindspring.com>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>,
	<559A83A3.5040406@jvuletich.org>
	<559AA0A2.13962.3B4CD8@dnorton.mindspring.com>
Message-ID: <55ADA04C.8070100@jvuletich.org>

On 7/6/2015 12:37 PM, Dan Norton wrote:
> On 6 Jul 2015 at 10:33, Juan Vuletich wrote:
>
>> Hi Dan,
>>
>> On 7/5/2015 8:35 PM, Dan Norton wrote:
>>> Greetings,
>>>
>>> Four LayoutSpec class methods use "minorDirectionPadding:" as a
>> keyword. The parameter
>>> can be a number or one of: #top, #left, #center, #right, or
>> #bottom. AFAICT when the
>>> parameter is a number, it refers to the padding which will be
>> applied in the minor direction.
>>> When it is a symbol, it effectively specifies that morphs will be
>> located as the symbol name
>>> implies.
>>>
>>> Attached are four convenience methods whose keyword emphasizes the
>> visible (morph)
>>> instead of the invisible (padding). The "morphPlacement:"
>> parameter can be  #top, #left,
>>> #center, #right, or #bottom. The methods are:
>>>
>>> LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
>>> LayoutSpec class>>fixedWidth:proportionalHeight:morphPlacement:
>>> LayoutSpec class>>proportionalWidth:fixedHeight:morphPlacement:
>>> LayoutSpec
>> class>>proportionalWidth:proportionalHeight:morphPlacement:
>>> Are these worth having in the base system?
>>>
>>>    - Dan
>>>
>> I'd rather replace the keyword 'minorDirectionPadding:' by
>> 'minorDirectionPlacement:' to:
>> - Avoid ambiguity
>> - Avoid duplication
>>
> OK, as far as the duplication, but I don't see "morphPlacement:" in use. Where does the
> ambiguity occur?
>
>   - Dan

The ambiguity in 'morphPlacement' is that it suggest it is about x and y 
placement. It is only for the 'minor' direction: x if a column, y if a 
row. Major direction placement is dictated by the other arguments, and 
siblings, etc.

Does this make sense?

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Mon Jul 20 20:34:16 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 21:34:16 -0400
Subject: [Cuis] Embedding morphs at specific points in a morph?
In-Reply-To: <55AD8A7A.26397.2436C64@dnorton.mindspring.com>
References: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
	<55AD8A7A.26397.2436C64@dnorton.mindspring.com>
Message-ID: <1437442456.2300.57.camel@gmail.com>

Welcome David!

On Mon, 2015-07-20 at 19:55 -0400, Dan Norton wrote:
> On 20 Jul 2015 at 16:18, David Tennant wrote:
> 
> 
> > 
> > Hi everyone.
> > I have been playing arrowed with cuis for a couple of years, but I
> > am extremely horrible at it. Every 
> > time I attempt to code a program I don't get too far, but this time
> > I want to actually make a 
> > program that works. So I am trying to make a program that you can
> > play mancala with. Mancala is 
> > an abstract board game.
> > I decided that I should build the board first. the board should look
> > something like this 
> > http://ecx.images-amazon.com/images/I/51PD0CemQkL._SY300_.jpg . I
> > wanted the circles and 
> > ovals to be separate classes so that I have more flexibility later.
> > I have 3 classes: Board, 
> > BigEllipse, and CircleEllipse. In BigEllipse and CircleEllipse I
> > just have initialization stuff, like size 
> > and color. in Board I have the initialization stuff too, but I also
> > have what I thought would create 
> > the board, but It does not work. there are two methods, one I called
> > "addMyEllipse" and th other I 
> > called "addScoreEllipse". these are the methods
> >  
> > addMyEllipse
> > |n|
> > 
> >     myEllipse:= CircleEllipse new.
> >         n:=1.
> >         (1to:12) do:[
> >             (n<7)
> >             ifTrue: [self addMorph: (myEllipse at:
> > 35@(35+(60*n)))]
> >             ifFalse: [self addMorph: (myEllipse at:
> > 110@(35+(60*n)))].
> >             n:= (n+1).
> >         ].
> > note: myEllipse is an instance variable.
> > 
> > addScoreEllipse
> > | n|
> > 
> >     scoreEllipse:= BigEllipse new.
> >     n:=1.
> >     (1to:2) do:[
> >         (n=1)
> >         ifTrue:[self addMorph:(scoreEllipse at: 72.5 at 35)]
> >         ifFalse:[self addMorph:(scoreEllipse at: 72.5 at 455)].
> >         n=(n+1).
> >     ].
> > note: scoreEllipse is an instance variable.
> > 
> > I don't actually know what is wrong. when I type in the workspace:
> > Board new openInWorld. I just 
> > get the background of the board, no ellipses. and when I type in the
> > workspace: test:= Board new 
> > openInWorld. test addMyEllipse. I get an error that says, this block
> > accepts 0 arguments, but was 
> > called with 1 argument.
> > 
> >
> I had the same problem recently in some code that looked like this:
> 
> 
> ifExistsDo: [{italicName. ' OK'} print]
> 
> 
> The cure was to "expect" an argument, even tho it would not be used:
> 
> 
> ifExistsDo: [:x | {italicName. ' OK'} print]
> 
Dan has it exactly right. The (1 to: 12) do: is trying to pass your
block the current value which *is* your n so you should get rid of the
outer n declaration and change the block to accept the parameter like
this:

(1 to: 12) do: [:n| Transcript show: n asString]

Just replace the Transcript statement with your code and you should be
good to go...

> 
> Thanks to Phil for staightening me out.
> 

Glad I could help... while the debugger is always precise as to what is
wrong, it isn't always clear :-)
> 
>  - Dan
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Mon Jul 20 20:34:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:34:43 -0300
Subject: [Cuis] #printStringLimitedTo:
In-Reply-To: <CAGQxfVi0Sjj8YNfYBxDKwa4sqWHJnAbApWfgHOOHdUy72nZYPA@mail.gmail.com>
References: <20150718213348.de2edfa3097b64706b6ba76f@whidbey.com>	<1437285899.6934.1.camel@gmail.com>
	<CAGQxfVi0Sjj8YNfYBxDKwa4sqWHJnAbApWfgHOOHdUy72nZYPA@mail.gmail.com>
Message-ID: <55ADA1B3.7060504@jvuletich.org>

Why not? I just did the .cs. If nobody objects, Ken' s suggestion will 
be in the next commit.

Cheers,
Juan Vuletich

On 7/20/2015 9:41 AM, H. Hirzel wrote:
> Ken you ask about other options
>
> one would be to have a method
>
>
> #printStringLimitedTo:suffix:
>
> so that people can have their own suffix.
>
> Might be better in a multilingual environment.
>
> However  '...etc...' is pretty general.
>
> No objection if it stays as is.
>
> --HH
>
> On 7/19/15, Phil (list)<pbpublist at gmail.com>  wrote:
>> On Sat, 2015-07-18 at 21:33 -0700, Ken.Dickey wrote:
>>> I find it kind of odd that #printStringLimitedTo: takes the prefix of a
>>> too-long string and adds '...etc...', which itself is 9 characters.
>>>
>>> I think a shorter addition would make more sense.  After all, the string
>>> is already too long, right?
>>>
>>> I like '[..]' , which is only four characters.
>>>
>>> Would anyone else like to weigh in on this?  Other options?
>> I agree that the current suffix is long-ish and like your [..] idea as
>> that's unlikely to appear in the majority of strings but would still
>> convey the information.
>>
>>> -KenD
>>>
>>> _______________________________________________
>>> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Mon Jul 20 20:36:10 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 20 Jul 2015 22:36:10 -0300
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
Message-ID: <55ADA20A.2070105@jvuletich.org>

On 7/19/2015 6:01 PM, H. Hirzel wrote:
> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
> ....
>   I
>> recently changed the scoping rules for shared variables (I think they're
>> done wrong in the base image). I could change what I wanted easily. So I
>> think I am not in some outsider author group. Instead I am happy that I
>> could change what I wanted without needing anyone's approval or
>> cooperation.

Great!

> A note:
> This applies to any version / distribution of Smalltalk. But it means
> that you have your own version of the core system.
>
> Could you elaborate on the issue of the shared variables, maybe it is
> something to include in the core Cuis image?
>
> --Hannes

Agree. It would be nice to know.

Cheers,
Juan Vuletich



From Ken.Dickey at whidbey.com  Mon Jul 20 20:44:43 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 20 Jul 2015 18:44:43 -0700
Subject: [Cuis] Embedding morphs at specific points in a morph?
In-Reply-To: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
References: <CAHH7fnKcZ32-ERU8r4Wq6UGhM-Nb9iZEm7CHosUunJ-VLdFLBw@mail.gmail.com>
Message-ID: <20150720184443.e17db364fc884fd11ac09d87@whidbey.com>

On Mon, 20 Jul 2015 16:18:13 -0600
David Tennant <d.a.tennant.2009 at gmail.com> wrote:

> myEllipse:= CircleEllipse new.
>         n:=1.
>         (1to:12) do:[
>             (n<7)
>             ifTrue: [self addMorph: (myEllipse at: 35@(35+(60*n)))]
>             ifFalse: [self addMorph: (myEllipse at: 110@(35+(60*n)))].
>             n:= (n+1).
>         ].

I don't know what "CircleEllipse new" does (e.g. is the radius zero?), but I would note that you are adding the same morph at different positions.

I suspect each position would like its own morph.

-- 
-KenD



From dnorton at mindspring.com  Mon Jul 20 20:58:43 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 21:58:43 -0400
Subject: [Cuis] Terse Guide to Pen, Forms
In-Reply-To: <55AD9E9E.7020407@jvuletich.org>
References: <55AD9338.29402.26592D8@dnorton.mindspring.com>,
	<55AD9E9E.7020407@jvuletich.org>
Message-ID: <55ADA753.26544.2B41A22@dnorton.mindspring.com>

Great! The transcript speed is impressive, BTW.

 - Dan

On 20 Jul 2015 at 22:21, Juan Vuletich wrote:

> Hi Dan,
> 
> This is a bug I introduced when speeding up Transcript maybe a month
> ago. I'll fix it soon (max 2 days).
> 
> Thanks for reporting.
> 
> Cheers,
> Juan Vuletich
> 
> On 7/20/2015 9:32 PM, Dan Norton wrote:
> > Hello,
> >
> > The Pen and Forms topics in Terse Guide no longer work. For
> example:
> >
> > | x y |
> > x := Form dotOfSize: 20.	"Make a form containing a dot (as yet
> unseen)."
> > x displayAt: 500 at 200.		"Cause the form to appear at a point on the
> display."
> > Display restore.			"Erase what was displayed."
> >
> > #displayAt: doesn't.
> >
> > Similar problems with "Display fillWhite" in the Pen topic.
> >
> >   - Dan
> >
> 





From pbpublist at gmail.com  Mon Jul 20 20:58:55 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 20 Jul 2015 21:58:55 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
Message-ID: <1437443935.2300.77.camel@gmail.com>

On Mon, 2015-07-20 at 06:55 -0700, Ken.Dickey wrote:
> On Sun, 19 Jul 2015 20:39:31 -0400
> "Phil (list)" <pbpublist at gmail.com> wrote:
> 
> > The issue is what constitutes a major change?  If your code uses it it's
> > major, if mine uses it it's minor?  Coin toss?  Without a public API
> > what is considered major is either obvious (i.e. Morphic changes from
> > global to local coords or changing the File/Directory API so obviously
> > everything using them breaks) or arbitrary (sorry to hear that you
> > depended on that... but it wasn't major, now it's gone)  If the image
> > snapshot is considered the public API, then everything must be both
> > considered fair game to depend on and to change in the future which is
> > unmanageable.
> 
> I don't think this is the issue at all. 
> 
> The text editor comes up in every release with goals for Cuis.  Backward compatibility is a stated non-goal.
> 

The first issue (text editor working in every release) is the difference
between reliability and stability, at least as I've been meaning in this
discussion.  Yes, it works in every release because it is part of what
is at least implicitly tested to a degree as part of nearly every build.
Cuis is very reliable in that within a given build things are generally
working better than they did in the previous build.

The backward compatibility non-goal seems like it should decrease as
Cuis matures. (not sure if this is a recent change or not, but it
actually does say that on the Cuis home page)  Once we hit a minimal
feature set, backwards incompatibility should largely go away as the
result of a combination of Cuis becoming the simplest thing that would
work and diminishing returns.  Perhaps we disagree on how close to that
point we are?  As Juan indicated, at some point the packages start to
play a larger role and at some point the same stability discussion
becomes an issue there as well.  (At least if the plan is to be able to
build larger and more complex things using Cuis in the future)

> I am happy to baseline my packages a couple of times a year against a baseline core release and maintain such matched baseline package releases.
> 

In theory what you're saying makes sense but in practice I didn't find
it worked.  I tried that back in the 2.x days and again in 4.x but found
the release notes just didn't have the detail to make this work for me.
I disliked the results enough that I'm currently trying to stay within a
build or two of Juan but that isn't realistic to expect most people to
do (I don't think so, at least) and if I ever fall behind in the current
model, I'm screwed...

> I trust Juan's leadership and judgment. His time is a scarce and valuable resource.  He is very responsive to the Cuis community, including requests for backward compatibility and additional support.  I do _not_ want to slow him down.
> 

I agree.  The question is how do we accomplish this.  My sense is that
we are starting to chew up more of his time peppering him with
questions / issues that he didn't anticipate resulting from recent
changes.  At the same time, for those who are not staying on the
bleeding edge, there is a level of frustration in that we're living in
an environment with very few constants and some of the changes have been
starting to hurt.

> If you have specific requirements, a package with Feature/Unit-tests is a good way to express this.
> 

I guess I see explicitly identified public methods and
feature/unit-tests as being complementary and helping lead to the same
place.

> > I'm not trying to restrict Juan in any way from making the changes he
> > thinks are important for Cuis.  His taste and direction have been
> > generally excellent and the reason I'm here!  If for example, he decides
> > that #drawOn: is no longer the way to do things or that even Morph
> > needed to go away, that's fine as long as what's going on gets
> > communicated.  However, a problem I think he faces right now is that he
> > doesn't know who's using / depending on what.
> 
> Pardon me, but this sounds exactly like you are trying to restrict certain changes.
> 

Poor choice of wording on my part, I probably should have said something
like 'prevent'.  Putting any sort of limits on when / how changes can be
made is a restriction.  But I'm not actually asking him to *not* make
the changes he thinks are necessary, but manage the when / how in some
cases.

> It seems that you are trying to "plan" and "rule set" rather than "discover quickly".
> 

I am asking him to plan a bit more *only* for a subset of things that we
agree need to be more stable than the rest.  I still believe that is <
20% of the unique method names.
  
> My experience is that quick discovery (like writing unit tests and running them very frequently) is the fastest development path.
> 
> My guess is that major packages which prove useful will either migrate into the core packages or will be tested against as part of a larger release process.  I just prefer that process to be as small and painless (low drag) as possible.
> 
> If some package is not in wide use, the author can test against releases as often as he/she feels it necessary.  We can deal with breakage as it arises rather than planning search strategies for avoiding breakage.  For me, this is much more efficient.

I don't think that most people will accept the compatibility through
continual testing/fixing over a long period of time... most will likely
give up after experiencing this for a while if they're attempting to use
Cuis as something more than a playground.

If the long term objective *isn't* for Cuis to be a platform, then an
acceptable answer would be 'you're using it wrong'.  Or Juan could
simply say 'yeah, ok... but I really don't want to do that...'

> 
> Having API test suites is a good way to communicate importance.
> 
> 
> As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful.  I heard that the Arabic word for "miracle" literally translates to "breaking the habit".  Interesting thought.
> 
> In the limit, we may be "agreeing loudly" here.  Easy to sound strident in an email.  Not the intent.
> 

I know you're generally pretty level headed and not looking to be
disagreeable.  I engaged in this discussion because it is an important
one to have and it felt like the right time to have it. A lot of what is
being proposed is a change from how things have historically been.  But
at the same time the pace of change has slowed down (ah, those whirlwind
1.x and 2.x days... :-) so it *seems* like trying to start to try to
stabilize things a bit has relatively little downside.  (Dunno... maybe
Juan is working on chucking the whole Magnitude hierarchy or something
major like that right now...)

> 
> What is the simplest thing that will work?
> -KenD





From dnorton at mindspring.com  Mon Jul 20 21:00:30 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 20 Jul 2015 22:00:30 -0400
Subject: [Cuis] Minor Direction Padding
In-Reply-To: <55ADA04C.8070100@jvuletich.org>
References: <5599BF3A.26485.1F11628@dnorton.mindspring.com>,
	<559AA0A2.13962.3B4CD8@dnorton.mindspring.com>,
	<55ADA04C.8070100@jvuletich.org>
Message-ID: <55ADA7BE.20764.2B5BCE6@dnorton.mindspring.com>

On 20 Jul 2015 at 22:28, Juan Vuletich wrote:

> On 7/6/2015 12:37 PM, Dan Norton wrote:
> > On 6 Jul 2015 at 10:33, Juan Vuletich wrote:
> >
> >> Hi Dan,
> >>
> >> On 7/5/2015 8:35 PM, Dan Norton wrote:
> >>> Greetings,
> >>>
> >>> Four LayoutSpec class methods use "minorDirectionPadding:" as
> a
> >> keyword. The parameter
> >>> can be a number or one of: #top, #left, #center, #right, or
> >> #bottom. AFAICT when the
> >>> parameter is a number, it refers to the padding which will be
> >> applied in the minor direction.
> >>> When it is a symbol, it effectively specifies that morphs will
> be
> >> located as the symbol name
> >>> implies.
> >>>
> >>> Attached are four convenience methods whose keyword emphasizes
> the
> >> visible (morph)
> >>> instead of the invisible (padding). The "morphPlacement:"
> >> parameter can be  #top, #left,
> >>> #center, #right, or #bottom. The methods are:
> >>>
> >>> LayoutSpec class>>fixedWidth:fixedHeight:morphPlacement:
> >>> LayoutSpec
> class>>fixedWidth:proportionalHeight:morphPlacement:
> >>> LayoutSpec
> class>>proportionalWidth:fixedHeight:morphPlacement:
> >>> LayoutSpec
> >> class>>proportionalWidth:proportionalHeight:morphPlacement:
> >>> Are these worth having in the base system?
> >>>
> >>>    - Dan
> >>>
> >> I'd rather replace the keyword 'minorDirectionPadding:' by
> >> 'minorDirectionPlacement:' to:
> >> - Avoid ambiguity
> >> - Avoid duplication
> >>
> > OK, as far as the duplication, but I don't see "morphPlacement:"
> in use. Where does the
> > ambiguity occur?
> >
> >   - Dan
> 
> The ambiguity in 'morphPlacement' is that it suggest it is about x
> and y 
> placement. It is only for the 'minor' direction: x if a column, y if
> a 
> row. Major direction placement is dictated by the other arguments,
> and 
> siblings, etc.
> 
> Does this make sense?
> 

+1

 - Dan



From hannes.hirzel at gmail.com  Tue Jul 21 02:12:34 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Tue, 21 Jul 2015 07:12:34 +0000
Subject: [Cuis] Terse Guide to Pen, Forms
In-Reply-To: <55ADA753.26544.2B41A22@dnorton.mindspring.com>
References: <55AD9338.29402.26592D8@dnorton.mindspring.com>
	<55AD9E9E.7020407@jvuletich.org>
	<55ADA753.26544.2B41A22@dnorton.mindspring.com>
Message-ID: <CAGQxfVhKjD-H3JKj7B8St6f0E-aYJrAMi0b87KHJjJHgcZBgSg@mail.gmail.com>

How would an additinonal test look like which covers this?

--Hannes



On 7/21/15, Dan Norton <dnorton at mindspring.com> wrote:
> Great! The transcript speed is impressive, BTW.
>
>  - Dan
>
> On 20 Jul 2015 at 22:21, Juan Vuletich wrote:
>
>> Hi Dan,
>>
>> This is a bug I introduced when speeding up Transcript maybe a month
>> ago. I'll fix it soon (max 2 days).
>>
>> Thanks for reporting.
>>
>> Cheers,
>> Juan Vuletich
>>
>> On 7/20/2015 9:32 PM, Dan Norton wrote:
>> > Hello,
>> >
>> > The Pen and Forms topics in Terse Guide no longer work. For
>> example:
>> >
>> > | x y |
>> > x := Form dotOfSize: 20.	"Make a form containing a dot (as yet
>> unseen)."
>> > x displayAt: 500 at 200.		"Cause the form to appear at a point on the
>> display."
>> > Display restore.			"Erase what was displayed."
>> >
>> > #displayAt: doesn't.
>> >
>> > Similar problems with "Display fillWhite" in the Pen topic.
>> >
>> >   - Dan
>> >
>>
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From peter at aba-instituut.nl  Tue Jul 21 14:13:15 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Tue, 21 Jul 2015 21:13:15 +0200
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <55ADA20A.2070105@jvuletich.org>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
	<55ADA20A.2070105@jvuletich.org>
Message-ID: <CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>

Hi Juan, Hannes,

since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW,
ST/X, VSE, IIRC) already do it as I want it to work
(Squeak does it "wrong" so perhaps it's not really a Smalltalk
implementation)

This is about the lookup logic when we see a name that is not a local name
(local to the block, method or object)

To resolve it (i.e., determine if it is a valid reference to a shared
variable), this is the order of searching for the name:

1 pool dictionaries declared in this class (from left to right I presume
but I don't care so I haven't paid attention)
2 classPool (i.e. the class variables defined in this class)
3 classPools in superclass chain
4 globals

The code in Squeak (and Cuis) does something recursive in the lookup logic
when it should not, which is probably based on an incorrect understanding
of the lookup rules. I have to admit that it is not easy to find how this
should be done, I have studied the Blue Book and ANSI-98 Smalltalk standard
(long long ago) and they were a bit fuzzy. But the logic all the other
dialects have also makes the most sense (to me) and works for some "clever"
stuff I do to make code 100% portable between dialects, so that's how I
like it to work.

Cheers, Peter

BTW Hannes, I'm not sure I would be able to change this in Dolphin, but in
the other dialects, probably. But like I said, there is no need, it is
Squeak (and Cuis) that's the odd one out.

On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org> wrote:

> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>
>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>> ....
>>   I
>>
>>> recently changed the scoping rules for shared variables (I think they're
>>> done wrong in the base image). I could change what I wanted easily. So I
>>> think I am not in some outsider author group. Instead I am happy that I
>>> could change what I wanted without needing anyone's approval or
>>> cooperation.
>>>
>>
> Great!
>
>  A note:
>> This applies to any version / distribution of Smalltalk. But it means
>> that you have your own version of the core system.
>>
>> Could you elaborate on the issue of the shared variables, maybe it is
>> something to include in the core Cuis image?
>>
>> --Hannes
>>
>
> Agree. It would be nice to know.
>
> 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/20150721/62be7266/attachment-0004.html>

From nicolas.cellier.aka.nice at gmail.com  Tue Jul 21 15:16:42 2015
From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier)
Date: Tue, 21 Jul 2015 22:16:42 +0200
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
	<55ADA20A.2070105@jvuletich.org>
	<CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>
Message-ID: <CAKnRiT68QBMbomVYVDyxpzfAM-g1rMBKZ+=RPp5nmdvb7DmqAA@mail.gmail.com>

2015-07-21 21:13 GMT+02:00 Peter van Rooijen <peter at aba-instituut.nl>:

> Hi Juan, Hannes,
>
> since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW,
> ST/X, VSE, IIRC) already do it as I want it to work
> (Squeak does it "wrong" so perhaps it's not really a Smalltalk
> implementation)
>
> This is about the lookup logic when we see a name that is not a local name
> (local to the block, method or object)
>
> To resolve it (i.e., determine if it is a valid reference to a shared
> variable), this is the order of searching for the name:
>
> 1 pool dictionaries declared in this class (from left to right I presume
> but I don't care so I haven't paid attention)
> 2 classPool (i.e. the class variables defined in this class)
> 3 classPools in superclass chain
> 4 globals
>
> The code in Squeak (and Cuis) does something recursive in the lookup logic
> when it should not, which is probably based on an incorrect understanding
> of the lookup rules. I have to admit that it is not easy to find how this
> should be done, I have studied the Blue Book and ANSI-98 Smalltalk standard
> (long long ago) and they were a bit fuzzy. But the logic all the other
> dialects have also makes the most sense (to me) and works for some "clever"
> stuff I do to make code 100% portable between dialects, so that's how I
> like it to work.
>
>
Ah, you probably mean that you would not want the superclass pool
dictionaries to be inherited, right?

Nicolas


> Cheers, Peter
>
> BTW Hannes, I'm not sure I would be able to change this in Dolphin, but in
> the other dialects, probably. But like I said, there is no need, it is
> Squeak (and Cuis) that's the odd one out.
>
> On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org> wrote:
>
>> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>>
>>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>>> ....
>>>   I
>>>
>>>> recently changed the scoping rules for shared variables (I think they're
>>>> done wrong in the base image). I could change what I wanted easily. So I
>>>> think I am not in some outsider author group. Instead I am happy that I
>>>> could change what I wanted without needing anyone's approval or
>>>> cooperation.
>>>>
>>>
>> Great!
>>
>>  A note:
>>> This applies to any version / distribution of Smalltalk. But it means
>>> that you have your own version of the core system.
>>>
>>> Could you elaborate on the issue of the shared variables, maybe it is
>>> something to include in the core Cuis image?
>>>
>>> --Hannes
>>>
>>
>> Agree. It would be nice to know.
>>
>> Cheers,
>> Juan Vuletich
>>
>> _______________________________________________
>> 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/20150721/c1c50cfa/attachment-0004.html>

From Ken.Dickey at whidbey.com  Tue Jul 21 17:33:00 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 21 Jul 2015 15:33:00 -0700
Subject: [Cuis] (Rescued) Re:  Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
Message-ID: <20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>

On Tue, 21 Jul 2015 07:59:47 -0700
Peter van Rooijen <peter at aba-instituut.nl> wrote:

>> I was thinking: "What should a Feature Test be?". 

I tend to think of a hierarchy of requirements.  Perhaps something like:

 Feature requireAll: #( <feature name>.. ).
 Classes requireAll: #( <class name>.. ). 
 Methods requireAll: #( <selector name>.. ).
 MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).         
 Tests requireAllPass: #( <unit test name> ).                 

The Feature class lets us require named (macro) Features with a version check.  I prefer that requirements at this level actually load the packages required and only report failure if that is not possible, although we could have a "preflight" verson which just checks without loading any featured packages.

API's are basically "protocols", which in the absence of symbolic execution means checking that classes and specific method selectors exist, or more specifically, method selectors are applicable to specific KindOf: classes.

Further, some Unit Tests may be required to pass to ensure compliance with some specification.

We should be able to automate at least some of this, including a first pass of generating the test sets, which could then be pruned by hand as required. 

$0.02,
-KenD



From peter at aba-instituut.nl  Wed Jul 22 05:41:47 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 22 Jul 2015 12:41:47 +0200
Subject: [Cuis] Scoping rules for shared variables ?
In-Reply-To: <CAKnRiT68QBMbomVYVDyxpzfAM-g1rMBKZ+=RPp5nmdvb7DmqAA@mail.gmail.com>
References: <CAGQxfVhbJwU_SWUY5sg-6kfAHbDgdF9g-gb=UiGVKea4YYkOYg@mail.gmail.com>
	<55ADA20A.2070105@jvuletich.org>
	<CAJBxtBY+ER+XR==mm8-WNCXNp+kq=+KBtzcToX6d9s+7T07uqA@mail.gmail.com>
	<CAKnRiT68QBMbomVYVDyxpzfAM-g1rMBKZ+=RPp5nmdvb7DmqAA@mail.gmail.com>
Message-ID: <CAJBxtBb6ahfcNi7tAhJVZab5QfTG2cATrmyRBJjEEPwKc10fiA@mail.gmail.com>

Hi Nicolas,

On Tue, Jul 21, 2015 at 10:16 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:


> Ah, you probably mean that you would not want the superclass pool
> dictionaries to be inherited, right?
>

Indeed they should not be inherited. If the variables are relevant for the
whole hierarchy, the place to put them is in the classPool.

But there is a problem with the class variables by themselves too, although
I always forget what it is. If you really want to know I can look it up of
course.

Cheers, Peter





>
>
> Nicolas
>
>
>> Cheers, Peter
>>
>> BTW Hannes, I'm not sure I would be able to change this in Dolphin, but
>> in the other dialects, probably. But like I said, there is no need, it is
>> Squeak (and Cuis) that's the odd one out.
>>
>> On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org>
>> wrote:
>>
>>> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>>>
>>>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>>>> ....
>>>>   I
>>>>
>>>>> recently changed the scoping rules for shared variables (I think
>>>>> they're
>>>>> done wrong in the base image). I could change what I wanted easily. So
>>>>> I
>>>>> think I am not in some outsider author group. Instead I am happy that I
>>>>> could change what I wanted without needing anyone's approval or
>>>>> cooperation.
>>>>>
>>>>
>>> Great!
>>>
>>>  A note:
>>>> This applies to any version / distribution of Smalltalk. But it means
>>>> that you have your own version of the core system.
>>>>
>>>> Could you elaborate on the issue of the shared variables, maybe it is
>>>> something to include in the core Cuis image?
>>>>
>>>> --Hannes
>>>>
>>>
>>> Agree. It would be nice to know.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> _______________________________________________
>>> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>

On Tue, Jul 21, 2015 at 10:16 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 2015-07-21 21:13 GMT+02:00 Peter van Rooijen <peter at aba-instituut.nl>:
>
>> Hi Juan, Hannes,
>>
>> since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW,
>> ST/X, VSE, IIRC) already do it as I want it to work
>> (Squeak does it "wrong" so perhaps it's not really a Smalltalk
>> implementation)
>>
>> This is about the lookup logic when we see a name that is not a local
>> name (local to the block, method or object)
>>
>> To resolve it (i.e., determine if it is a valid reference to a shared
>> variable), this is the order of searching for the name:
>>
>> 1 pool dictionaries declared in this class (from left to right I presume
>> but I don't care so I haven't paid attention)
>> 2 classPool (i.e. the class variables defined in this class)
>> 3 classPools in superclass chain
>> 4 globals
>>
>> The code in Squeak (and Cuis) does something recursive in the lookup
>> logic when it should not, which is probably based on an incorrect
>> understanding of the lookup rules. I have to admit that it is not easy to
>> find how this should be done, I have studied the Blue Book and ANSI-98
>> Smalltalk standard (long long ago) and they were a bit fuzzy. But the logic
>> all the other dialects have also makes the most sense (to me) and works for
>> some "clever" stuff I do to make code 100% portable between dialects, so
>> that's how I like it to work.
>>
>>
> Ah, you probably mean that you would not want the superclass pool
> dictionaries to be inherited, right?
>
> Nicolas
>
>
>> Cheers, Peter
>>
>> BTW Hannes, I'm not sure I would be able to change this in Dolphin, but
>> in the other dialects, probably. But like I said, there is no need, it is
>> Squeak (and Cuis) that's the odd one out.
>>
>> On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <juan at jvuletich.org>
>> wrote:
>>
>>> On 7/19/2015 6:01 PM, H. Hirzel wrote:
>>>
>>>> On 7/19/15, Peter van Rooijen<peter at aba-instituut.nl>  wrote:
>>>> ....
>>>>   I
>>>>
>>>>> recently changed the scoping rules for shared variables (I think
>>>>> they're
>>>>> done wrong in the base image). I could change what I wanted easily. So
>>>>> I
>>>>> think I am not in some outsider author group. Instead I am happy that I
>>>>> could change what I wanted without needing anyone's approval or
>>>>> cooperation.
>>>>>
>>>>
>>> Great!
>>>
>>>  A note:
>>>> This applies to any version / distribution of Smalltalk. But it means
>>>> that you have your own version of the core system.
>>>>
>>>> Could you elaborate on the issue of the shared variables, maybe it is
>>>> something to include in the core Cuis image?
>>>>
>>>> --Hannes
>>>>
>>>
>>> Agree. It would be nice to know.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> _______________________________________________
>>> 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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150722/ab140f14/attachment-0004.html>

From peter at aba-instituut.nl  Wed Jul 22 05:57:44 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 22 Jul 2015 12:57:44 +0200
Subject: [Cuis] (Rescued) Re:  Fwd: Re: DIRECT version number
In-Reply-To: <20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
Message-ID: <CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>

Hi Ken,

On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

> On Tue, 21 Jul 2015 07:59:47 -0700
> Peter van Rooijen <peter at aba-instituut.nl> wrote:
>
> >> I was thinking: "What should a Feature Test be?".
>
> I tend to think of a hierarchy of requirements.  Perhaps something like:
>
>  Feature requireAll: #( <feature name>.. ).
>  Classes requireAll: #( <class name>.. ).
>  Methods requireAll: #( <selector name>.. ).
>  MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).
>  Tests requireAllPass: #( <unit test name> ).
>

Yeah, that's not at all what I'm thinking :). I'm thinking of something
that is automatically runnable, like a unit test. It tests something, like
a un test. But if the test does not pass, it is NOT a bug, unlike with a
unit test. It's just that we would like to know about it. Also, with nit
tests there is the assumption that the code that represents the test is
always compilable, with feature tests that cannot be assumed, so there
would need to be protection against that. Of course we want to be able to
load the feature tests in any condition, so putting it in the form of
source text and compiling that is a possibility. The fact that that makes
it slower than unit tests is not a problem, because unlike unit tests, we
don't have to run them continuously.


> The Feature class lets us require named (macro) Features with a version
> check.  I prefer that requirements at this level actually load the packages
> required and only report failure if that is not possible, although we could
> have a "preflight" verson which just checks without loading any featured
> packages.
>

I see. The thing I was thinking about merely reports about the state of a
system (of code), it does not try to configure that in any way.


>
> API's are basically "protocols", which in the absence of symbolic
> execution means checking that classes and specific method selectors exist,
> or more specifically, method selectors are applicable to specific KindOf:
> classes.
>

Well, in my mind some semantics could be expected (and tested for). For
instance I might be interested if there is a DateTime class in the image
and if it implements the ANSI DateAndTime protocol (not sure if there is
one named that). Or perhaps another class that does that. These tests can
test some actual semantics no problem.

Perhaps some of you remember that Camp Smalltalk started with Ralph
Johnson's desire to build an ANSI test suite. The way people went about it
(extension methods to SUnit? I don't really remember) was wrong and could
not possibly work (in my opinion anyway), but I could not convince a lot of
people and such a test suite was never written. But with Feature Tests I
think we could come a long way.

>
> Further, some Unit Tests may be required to pass to ensure compliance with
> some specification.
>

Well, except that the tests would not be unit tests in the strictest sense.
But semantics, not merely interface, can be tested for sure.

>
> We should be able to automate at least some of this


Automate the running of the feature tests? Of course.


> including a first pass of generating the test sets, which could then be
> pruned by hand as required.
>

That I don't see happening. You test what YOU think is important to be sure
of. No machine can decide/calculate that for you. Perhaps I'm
misunderstanding you.

Cheers, Peter


>
> $0.02,
> -KenD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150722/32a7fa87/attachment-0004.html>

From peter at aba-instituut.nl  Wed Jul 22 06:29:05 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 22 Jul 2015 13:29:05 +0200
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
Message-ID: <CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>

I'm thinking about some features (pun not intentional) of this Feature Test
framework:

1. It's reasonable to assume that many tests will depend on something else
working, but that cannot be counted on, and
we would not want to repeat testing for that and also would not run into it
failing all the time and that filling our feedback.

1a. So it would make sense to add a #precondition method to each Feature
Test class.

FeatureAnsiArray
    class
        precondition

        self run: 'Array' "i.e. the global Array must be present"

then only if the precondition for the class is satisfied, will the test
methods be executed. so if most of them start with

'Array new ?' then they would all fail anyway so we don't need to test them.

2. You would want to be able to assure that in a particular object you
would be able to access a particular variable.

so in the test method you would write:

FeatureTest1
    class
        test1

        self setContext: OrderdCollection new

        self run: 'elements' "determine if the inst var elements is present
in a new OrderedCollection"

        self run: 'elements == nil' expect: false

        self run: 'elements isOrderedCollection' expect: true

let's say the test runner would continue testing even if something failed,
e.g. the array is called array, not elements. then we already know that the
following expressions will fail

so we might instead write:

        self run: 'elements' ifFail: [^self]

 3. Instead of implicitly testing for a global using run: 'NameOfTheGlobal'
or for a class var using setContext: and then run'NameOfTheClassVar' there
could be convenience methods for

        self expectGlobal: 'NameOfTheGlobal' "argument may be given as a
Symbol as well"

        self expectClass: 'NameOfTheClass' "additionally verified that the
global holds a class"

        self expectSharedVariable: 'Foo' inClass: 'Bar'

this would make for nicer feedback since the expectation is made clearer

Okay just 2 more cents!

Cheers, Peter



On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen <peter at aba-instituut.nl>
wrote:

> Hi Ken,
>
> On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <Ken.Dickey at whidbey.com>
> wrote:
>
>> On Tue, 21 Jul 2015 07:59:47 -0700
>> Peter van Rooijen <peter at aba-instituut.nl> wrote:
>>
>> >> I was thinking: "What should a Feature Test be?".
>>
>> I tend to think of a hierarchy of requirements.  Perhaps something like:
>>
>>  Feature requireAll: #( <feature name>.. ).
>>  Classes requireAll: #( <class name>.. ).
>>  Methods requireAll: #( <selector name>.. ).
>>  MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).
>>  Tests requireAllPass: #( <unit test name> ).
>>
>
> Yeah, that's not at all what I'm thinking :). I'm thinking of something
> that is automatically runnable, like a unit test. It tests something, like
> a un test. But if the test does not pass, it is NOT a bug, unlike with a
> unit test. It's just that we would like to know about it. Also, with nit
> tests there is the assumption that the code that represents the test is
> always compilable, with feature tests that cannot be assumed, so there
> would need to be protection against that. Of course we want to be able to
> load the feature tests in any condition, so putting it in the form of
> source text and compiling that is a possibility. The fact that that makes
> it slower than unit tests is not a problem, because unlike unit tests, we
> don't have to run them continuously.
>
>
>> The Feature class lets us require named (macro) Features with a version
>> check.  I prefer that requirements at this level actually load the packages
>> required and only report failure if that is not possible, although we could
>> have a "preflight" verson which just checks without loading any featured
>> packages.
>>
>
> I see. The thing I was thinking about merely reports about the state of a
> system (of code), it does not try to configure that in any way.
>
>
>>
>> API's are basically "protocols", which in the absence of symbolic
>> execution means checking that classes and specific method selectors exist,
>> or more specifically, method selectors are applicable to specific KindOf:
>> classes.
>>
>
> Well, in my mind some semantics could be expected (and tested for). For
> instance I might be interested if there is a DateTime class in the image
> and if it implements the ANSI DateAndTime protocol (not sure if there is
> one named that). Or perhaps another class that does that. These tests can
> test some actual semantics no problem.
>
> Perhaps some of you remember that Camp Smalltalk started with Ralph
> Johnson's desire to build an ANSI test suite. The way people went about it
> (extension methods to SUnit? I don't really remember) was wrong and could
> not possibly work (in my opinion anyway), but I could not convince a lot of
> people and such a test suite was never written. But with Feature Tests I
> think we could come a long way.
>
>>
>> Further, some Unit Tests may be required to pass to ensure compliance
>> with some specification.
>>
>
> Well, except that the tests would not be unit tests in the strictest
> sense. But semantics, not merely interface, can be tested for sure.
>
>>
>> We should be able to automate at least some of this
>
>
> Automate the running of the feature tests? Of course.
>
>
>> including a first pass of generating the test sets, which could then be
>> pruned by hand as required.
>>
>
> That I don't see happening. You test what YOU think is important to be
> sure of. No machine can decide/calculate that for you. Perhaps I'm
> misunderstanding you.
>
> Cheers, Peter
>
>
>>
>> $0.02,
>> -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/20150722/5bba2659/attachment-0004.html>

From Ken.Dickey at whidbey.com  Wed Jul 22 08:58:12 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Wed, 22 Jul 2015 06:58:12 -0700
Subject: [Cuis] (Rescued) Re:  Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
Message-ID: <20150722065812.da4e892dbe35764801607ace@whidbey.com>

On Wed, 22 Jul 2015 12:57:44 +0200
Peter van Rooijen <peter at aba-instituut.nl> wrote:

> Hi Ken,
> 
> On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> 
> > On Tue, 21 Jul 2015 07:59:47 -0700
> > Peter van Rooijen <peter at aba-instituut.nl> wrote:
> >
> > >> I was thinking: "What should a Feature Test be?".
> >
> > I tend to think of a hierarchy of requirements.  Perhaps something like:
> >
> >  Feature requireAll: #( <feature name>.. ).
> >  Classes requireAll: #( <class name>.. ).
> >  Methods requireAll: #( <selector name>.. ).
> >  MethodsForKind class: <class name> requireAll: #( <selectorName>.. ).
> >  Tests requireAllPass: #( <unit test name> ).
> >
> 
> Yeah, that's not at all what I'm thinking :). I'm thinking of something
> that is automatically runnable, like a unit test. It tests something, like
> a un test. But if the test does not pass, it is NOT a bug, unlike with a
> unit test. It's just that we would like to know about it. Also, with nit
> tests there is the assumption that the code that represents the test is
> always compilable, with feature tests that cannot be assumed, so there
> would need to be protection against that. ...

Remember the phrase "agreeing loudly"?

OK, so you want the "preflight option" for Feature check.

To not "fail a test" one has to test in sequence.

- Are the Features present (as in Feature require: #<whatever> )
- Are the classes present?
- Do the method selectors exist?
- Are the right protocols there (method selectors exist for specific classes; e.g. #isFoo: is a method on a class for some aClass isKindOf: <foo>).
- What code is expected to yield a specific result (actually run some code to check, like, well, a unit test).

Failure at any step/level means something is missing and the more specific tests at the next level don't get run. 

A whole hierarchy of tests can be bundled as one Feature Test.

How is this different than what you are proposing?

-- 
-KenD



From pbpublist at gmail.com  Wed Jul 22 14:19:16 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 22 Jul 2015 15:19:16 -0400
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
	<CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>
Message-ID: <1437592756.2326.32.camel@gmail.com>

On Wed, 2015-07-22 at 13:29 +0200, Peter van Rooijen wrote:
> I'm thinking about some features (pun not intentional) of this Feature
> Test framework:
> 
> 
> 1. It's reasonable to assume that many tests will depend on something
> else working, but that cannot be counted on, and
> we would not want to repeat testing for that and also would not run
> into it failing all the time and that filling our feedback.
> 

Why not?  I agree that these would be a different category of test in
that the dependencies would be more complex and often dependent on more
than one package, but why would their functioning be considered
optional?  If they fail, shouldn't they either be addressed right away
or explicitly deprecated?  If you make the tests easy to ignore/forget
about, they will be.  If the functionality they are testing can't be
counted on, it won't be used.

If your thinking is that these would be tests that are part of package X
but might rely on package Y which might not be loaded yet, why not
instead just make the tests part of package Z which depends on package X
and Y?  The whole idea is that these are not unit tests in that sense...
have them live where ever it is appropriate.

> 
> 1a. So it would make sense to add a #precondition method to each
> Feature Test class.
> 
> 
> FeatureAnsiArray
>     class
>         precondition
> 
>         
>         self run: 'Array' "i.e. the global Array must be present"
> 
> 
> then only if the precondition for the class is satisfied, will the
> test methods be executed. so if most of them start with
> 
> 
> 'Array new ?' then they would all fail anyway so we don't need to test
> them.
> 
> 
> 2. You would want to be able to assure that in a particular object you
> would be able to access a particular variable.
> 
> 
> so in the test method you would write:
> 
> 
> FeatureTest1
>     class
>         test1
>         
>         self setContext: OrderdCollection new
> 
> 
>         self run: 'elements' "determine if the inst var elements is
> present in a new OrderedCollection"
> 
> 
>         self run: 'elements == nil' expect: false
> 
> 
>         self run: 'elements isOrderedCollection' expect: true
> 
> 
> let's say the test runner would continue testing even if something
> failed, e.g. the array is called array, not elements. then we already
> know that the following expressions will fail
> 
> 
> so we might instead write:
> 
> 
>         self run: 'elements' ifFail: [^self]
> 
> 
> 
>  3. Instead of implicitly testing for a global using run:
> 'NameOfTheGlobal' or for a class var using setContext: and then
> run'NameOfTheClassVar' there could be convenience methods for
> 
> 
>         self expectGlobal: 'NameOfTheGlobal' "argument may be given as
> a Symbol as well"
> 
> 
>         self expectClass: 'NameOfTheClass' "additionally verified that
> the global holds a class"
> 
> 
>         self expectSharedVariable: 'Foo' inClass: 'Bar'
> 
> 
> this would make for nicer feedback since the expectation is made
> clearer

I went the other way when I did the ApiFile tests in that it didn't seem
terribly important to use most of the testing framework capabilities
(other than the overall pass/fail aspect to keep the initial PoC as
simple as possible)  So they are simply small snippets of code that
performed the desired task but didn't care where it failed (if it
failed):  the failure to successfully complete the task would be the
indicator that there was a problem and we would know that either
something being depended on had broken and needed to be fixed or that
the test needed to be updated/overhauled to represent the new way of
accomplishing the task.

My thinking was that as we started to build up a number of these, we
might start to see common breakage patterns and then we could decide
whether or not to handle that them more explicitly (whether using the
existing test framework capabilities, creating a new one, etc.)  Trying
to engineer it up front didn't seem like a great idea not knowing what
common failure states would look like yet.

> 
> 
> Okay just 2 more cents!
> 

Mine as well.  This is a worthwhile discussion/exercise IMO as we need
to get to a common understanding of what we are doing here.

> 
> Cheers, Peter
> 
> 
> 
> 
> 
> On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen
> <peter at aba-instituut.nl> wrote:
>         Hi Ken,
>         
>         On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey
>         <Ken.Dickey at whidbey.com> wrote:
>                 On Tue, 21 Jul 2015 07:59:47 -0700
>                 Peter van Rooijen <peter at aba-instituut.nl> wrote:
>                 
>                 >> I was thinking: "What should a Feature Test be?".
>                 
>                 I tend to think of a hierarchy of requirements.
>                 Perhaps something like:
>                 
>                  Feature requireAll: #( <feature name>.. ).
>                  Classes requireAll: #( <class name>.. ).
>                  Methods requireAll: #( <selector name>.. ).
>                  MethodsForKind class: <class name> requireAll:
>                 #( <selectorName>.. ).
>                  Tests requireAllPass: #( <unit test name> ).
>         
>         
>         Yeah, that's not at all what I'm thinking :). I'm thinking of
>         something that is automatically runnable, like a unit test. It
>         tests something, like a un test. But if the test does not
>         pass, it is NOT a bug, unlike with a unit test. It's just that
>         we would like to know about it. Also, with nit tests there is
>         the assumption that the code that represents the test is
>         always compilable, with feature tests that cannot be assumed,
>         so there would need to be protection against that. Of course
>         we want to be able to load the feature tests in any condition,
>         so putting it in the form of source text and compiling that is
>         a possibility. The fact that that makes it slower than unit
>         tests is not a problem, because unlike unit tests, we don't
>         have to run them continuously.
>          
>                 The Feature class lets us require named (macro)
>                 Features with a version check.  I prefer that
>                 requirements at this level actually load the packages
>                 required and only report failure if that is not
>                 possible, although we could have a "preflight" verson
>                 which just checks without loading any featured
>                 packages.
>         
>         
>         I see. The thing I was thinking about merely reports about the
>         state of a system (of code), it does not try to configure that
>         in any way.
>          
>                 
>                 API's are basically "protocols", which in the absence
>                 of symbolic execution means checking that classes and
>                 specific method selectors exist, or more specifically,
>                 method selectors are applicable to specific KindOf:
>                 classes.
>         
>         
>         Well, in my mind some semantics could be expected (and tested
>         for). For instance I might be interested if there is a
>         DateTime class in the image and if it implements the ANSI
>         DateAndTime protocol (not sure if there is one named that). Or
>         perhaps another class that does that. These tests can test
>         some actual semantics no problem.
>         
>         
>         Perhaps some of you remember that Camp Smalltalk started with
>         Ralph Johnson's desire to build an ANSI test suite. The way
>         people went about it (extension methods to SUnit? I don't
>         really remember) was wrong and could not possibly work (in my
>         opinion anyway), but I could not convince a lot of people and
>         such a test suite was never written. But with Feature Tests I
>         think we could come a long way.
>                 
>                 Further, some Unit Tests may be required to pass to
>                 ensure compliance with some specification.
>         
>         
>         Well, except that the tests would not be unit tests in the
>         strictest sense. But semantics, not merely interface, can be
>         tested for sure.
>                 
>                 We should be able to automate at least some of this
>         
>         
>         Automate the running of the feature tests? Of course.
>          
>                 including a first pass of generating the test sets,
>                 which could then be pruned by hand as required.
>         
>         
>         That I don't see happening. You test what YOU think is
>         important to be sure of. No machine can decide/calculate that
>         for you. Perhaps I'm misunderstanding you.
>         
>         
>         Cheers, Peter
>          
>                 
>                 $0.02,
>                 -KenD
>         
>         
>         
>         _______________________________________________
>         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  Thu Jul 23 08:11:37 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 10:11:37 -0300
Subject: [Cuis] Cuis Archive
In-Reply-To: <559AA39A.19585.46E7C0@dnorton.mindspring.com>
References: <559AA39A.19585.46E7C0@dnorton.mindspring.com>
Message-ID: <55B0E809.7010904@jvuletich.org>

Yes, unfortunately.

I hadn't much time for this before, but yesterday I spent over one hour 
chatting with the provider's (HostGator) support. I use them for 
cuis-smalltalk.org, jvuletich.org, personal email and the cuis mail 
list. The service is usually very reliable.

But now this happened. I swear I did not touch anything.

They opened a support ticket, and said they will fix it. I hope they do.

Apologies,
Juan Vuletich

On 7/6/2015 12:49 PM, Dan Norton wrote:
> Hi,
>
> There is nothing in the archive for July. Anybody else experiencing this?
>
>   - Dan
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From juan at jvuletich.org  Thu Jul 23 08:48:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 10:48:34 -0300
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT version
 number
Message-ID: <55B0F0B2.6090202@jvuletich.org>

Very small snip (while preparing an answer for the whole thread):

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.
> ...

Yes. Cuis is MIT, etc. You don't have any obligations, etc.

But, if you tell what are you using Cuis for, and how, that is very 
useful (and nice to know).
If you are maintaining a significant code base, if possible, tell about 
it. This will help us better support you.

It is nice to know to what extent something you do is useful for others. 
I think it is also a polite and reasonable way to say thanks to us, 
working for you.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 23 08:51:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 10:51:09 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437352771.6934.219.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
Message-ID: <55B0F14D.7010405@jvuletich.org>

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> It really comes down to what is Cuis?  Is it:
>
> 1) a minimal Smalltalk that you play around with ideas / prototype
> something in the short to intermediate term
>
> 2) a platform that you can take that idea you were playing around with,
> and if it proves out, build something more substantial from for the
> longer term
>
> 3) a completely experimental environment.  Anything can change at any
> time.  Supporting 1 is doable but 2 is doubtful.
>
> Right now, Cuis is great at 1 but seems like it should be able to handle
> both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
> all, but who knows, others may disagree.  If others look at it
> differently, I'd love to know how you look at Cuis.

I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that way.

Cheers,
Juan Vuletich



From hannes.hirzel at gmail.com  Thu Jul 23 09:09:24 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Thu, 23 Jul 2015 14:09:24 +0000
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55B0F14D.7010405@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<55B0F14D.7010405@jvuletich.org>
Message-ID: <CAGQxfVh5AMJnVr3i-Kc2jomzTFoug5r1u=KbJa1VX6b_jruT6A@mail.gmail.com>

1) and 2) sounds like there is a need for an Ubuntu type of approach.

Labelled releases at regular intervals -- could be semi-annually or
annually. Some of them receive important bux fixes thus constituting
Long Term Releases.

Or stable vs unstable branches in github.

In two days on the 25th of July it will be exactly 2 years after the
last release of 4.2.   :-)

A point to consider as well is that what Juan is doing constitutes a
trunk from which releases are forked from time to time by other
people. The ones who run Feature Tests ....

--Hannes

On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 7/19/2015 9:39 PM, Phil (list) wrote:
>> ...
>> It really comes down to what is Cuis?  Is it:
>>
>> 1) a minimal Smalltalk that you play around with ideas / prototype
>> something in the short to intermediate term
>>
>> 2) a platform that you can take that idea you were playing around with,
>> and if it proves out, build something more substantial from for the
>> longer term
>>
>> 3) a completely experimental environment.  Anything can change at any
>> time.  Supporting 1 is doable but 2 is doubtful.
>>
>> Right now, Cuis is great at 1 but seems like it should be able to handle
>> both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
>> all, but who knows, others may disagree.  If others look at it
>> differently, I'd love to know how you look at Cuis.
>
> I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that
> way.
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Thu Jul 23 09:15:15 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 11:15:15 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437443935.2300.77.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>	<1437352771.6934.219.camel@gmail.com>	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<1437443935.2300.77.camel@gmail.com>
Message-ID: <55B0F6F3.3030503@jvuletich.org>

Another specific comment:

On 7/20/2015 10:58 PM, Phil (list) wrote:
> I agree. The question is how do we accomplish this. My sense is that
> we are starting to chew up more of his time peppering him with
> questions / issues that he didn't anticipate resulting from recent
> changes.

This is a very good thing! I need to know the extent of the trouble I 
create when I change something.
This is no longer my private quest for the perfect Smalltalk-80. Your 
needs are really important now!
If some changes have issues I didn't anticipate, I need to know. This is 
another force (amongst a few others)
driving the evolution of Cuis.

> ...
> I don't think that most people will accept the compatibility through
> continual testing/fixing over a long period of time... most will likely
> give up after experiencing this for a while if they're attempting to use
> Cuis as something more than a playground.

I don't want that to happen.

> If the long term objective *isn't* for Cuis to be a platform, then an
> acceptable answer would be 'you're using it wrong'.  Or Juan could
> simply say 'yeah, ok... but I really don't want to do that...'

But now, after all these years, most of the worst, convoluted, horrible, 
apis and code inherited from Squeak have been cleaned. Right now, if I 
break something badly, and without any prior communication, it is most 
likely a mistake on my part. If I do such mistake, I'll be willing to 
fix it. I think this has happened a few times in this last couple of years.


>> ...
>> As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful.  I heard that the Arabic word for "miracle" literally translates to "breaking the habit".  Interesting thought.
>> ...

Hehehe. Yes.

> I know you're generally pretty level headed and not looking to be
> disagreeable.  I engaged in this discussion because it is an important
> one to have and it felt like the right time to have it. A lot of what is
> being proposed is a change from how things have historically been.  But
> at the same time the pace of change has slowed down (ah, those whirlwind
> 1.x and 2.x days... :-) so it *seems* like trying to start to try to
> stabilize things a bit has relatively little downside.  (Dunno... maybe
> Juan is working on chucking the whole Magnitude hierarchy or something
> major like that right now...)

:D

No, the only important API change we have planned is to move from 
FileDirectory to FileMan.

We'll be doing relatively risky stuff, but not with the objective of 
changing APIs, although that might be a consequence. Some things I'd 
like to work in the next months / years are:
- Spur. The Spur object format requires a few changes in the compiler 
and core classes
- 64 bit. Having 64 and 32 bit images might also break stuff (?)
- Bootstrap from sources
- Switch to Morphic 3

Maybe I'm forgetting about something... And at some point, if possible, 
I'd like to integrate (or support and use as optional packages) Ropes 
and Unicode from Ken, VMMaker, code generation, VM simulation. Morphic 
programming for app developers should be easier and more convenient... 
And we might come up with other cool stuff to be done, that could 
perhaps impact a bit on APIs used by others...

>> What is the simplest thing that will work?
>> -KenD
>

That is indeed the question we need to answer.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 23 09:25:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 11:25:49 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1437341905.6934.99.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>	
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
Message-ID: <55B0F96D.4010706@jvuletich.org>

Hi Phil,

This is  very good and stong advocacy on documented public APIs. Thank you!

(a few comments inline)
On 7/19/2015 6:38 PM, Phil (list) wrote:
> On Sun, 2015-07-19 at 11:20 -0300, Juan Vuletich wrote:
>> Hi Folks,
>>
>> (inline)
>>
>> On 7/17/2015 3:45 PM, Phil (list) wrote:
>>> ...On 7/16/2015 9:57 AM, H. Hirzel wrote:
>>>>> Thank you Juan, for answering.
>>>>>
>>>>> At the moment I feel uncomfortable using Cuis because it is currently
>>>>> a quite fast moving target. I perceive quite a number of API changes
>>>>> though this might be wrong. But I do not know because there are no
>>>>> release notes which summarize it.
>>> I totally feel Hannes' pain having gone through it a few times myself
>>> over the years.  At the same time, I agree with Ken's point about not
>>> getting too bogged down in process since we're in the best position
>>> right now to break things for the better longer term.
>>>
>>>> Yes, that's true. Besides, we don't have a specification of what is an
>>>> API and what is not. So, almost any change can be considered an API change.
>>> That's the problem!  Both for you and us (it's a general 'Smalltalk Way'
>>> issue, not specific to Cuis)  I believe it is largely fixable without
>>> tons of documentation and tests: the use of private (categories or
>>> method naming convention).  Bernhard pointed out an existing capability
>>> a few months ago
>>> http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
>>> While I personally like the idea of private categories, one of these
>>> approaches should really be seriously considered.
>>>
>>> Other than a few specific examples (i.e. mostly the base data types
>>> including the Collection and Number class hierarchies which are pretty
>>> mature and don't change all that much anyway) I would guesstimate that
>>> <20% (probably closer to 10%) of the methods, and and unknown % of
>>> classes (a significantly larger fraction though), should even be
>>> considered public.  If things were indicated as private that would
>>> accomplish two things:
>>>
>>> 1) We could construct some simple tooling (some combination of up-front
>>> warnings in the editor and/or a lint-type tester after the fact) that
>>> would allow people to identify problematic calls within their code.
>>> (i.e. just because it works now doesn't mean it always will if you keep
>>> calling X, Y, Z...)
>>>
>>> 2) It would provide a way for people to know if something needs to be
>>> discussed.  i.e. 'In class X method Y is private but I need that type of
>>> functionality' so you would know that there's a need and could consider
>>> either making it public, and therefore supported, or rethinking its
>>> implementation if you'd like to offer a better public API solution.
>> Ok. Doing something along these lines would be great. But please note
>> that it is a rather large amount of work. It is not something I'm able
>> or willing to do it alone. If you (any of you all, not just Phil) wants
>> to start defining the API for any part of the system or optional
>> packages, please start doing it and send the changesets to the list. If
>> we get this working, I'll start the tools you mention.
>>
> Agreed that this is a lot of work and I definitely wasn't expecting you
> to do it (other than reviewing the work for approval/rejection.)  I'll
> be happy to work on this with anyone else who is interested.
>
>> <slowly diverging into OT rant>
>>
>> On the other hand (and please forgive me if this kills a bit of
>> momentum), I don't really think we are changing APIs that much. And I
>> don't think we'll be doing it any more in the future than we do today,
>> at least in the base image. I hope to see most of the activity and
>> incompatible changes to happen in optional packages, and affecting
>> package dependencies... Mhhh, now that I write this I think that it
>> doesn't really go against the idea of defining APIs. Maybe APIs in the
>> base image will almost never change or be a problem, but packages should
>> provide APIs too... Optional packages will (I hope!) always be
>> improving, and new ones will appear all the time.
>>
> You'd likely be very surprised.  I'd say there's usually at least a
> couple changes a month that breaks something, somewhere in my code.  A
> few recent examples that have been discussed on the list: removing clone
> broke OpenGL a bit (easy fix thanks to the on-list discussion), removing
> compilerClass killed OMeta, a while back you were considering removing
> storeString which would again break OMeta. etc. (that's just a few
> things off the top of my head from the last few months and note that all
> were probably considered minor, inconsequential changes)  However the
> issue snowballs quickly if one misses a few updates and some of the
> breakage is related to changes that weren't discussed on the list or
> otherwise documented.  I've been managing through this recently (the
> last 6 months or so) by upgrading my image very quickly after you commit
> changes but I doubt most people would be able / willing to have that
> level of diligence.
>
> A lot of this breakage is no one's 'fault', it's just how a lot of
> Smalltalk code has been historically written.  Two examples of how this
> happens:
>
> 1) For ports of existing code, you're subject to the whims of the
> original author who often used techniques described in the next item to
> write their code.  And of course, code coming from Squeak/Pharo means
> that there were often 10 or more possible ways they could have
> implemented parts of their solution.  So after porting a few different
> packages, you have several different approaches to the same kinds of
> problems.
>
> 2) For one's own code because there is currently no distinction between
> public and private, you tend to go either with what you already know or
> whatever the first thing you find poking around the image that appears
> to make sense and work.  Even in Cuis, there are still usually multiple
> ways to do most things, so you end up arbitrarily picking one or two
> that you like.  As a result, you quickly end up with a potpourri of
> calls that may or may not be the best way to do things.  Over time, you
> start building new code on top of this code and quickly end up with a
> house of cards that comes crashing down as the result of a subsequent
> image update.  Again, this often results in each of us as authors
> deciding on superficially different solutions to the same problems.
>
> I'm not expecting you to not do things that might break my, or anyone
> else's code, going forward.  Like Hannes, I'm just looking for ways to
> help manage through the changes and breakage.  One of the key aspects of
> this is to have an opinion and to say 'hey, here are the one or two ways
> we should be doing this'.  There may be disagreement and discussion as
> to what those one or two ways are, but at the end of the day we need to
> settle these issues so that both your and our lives are manageable.
> That's really the main thing that a public API is, IMO.  There may be
> all sorts of internal helper methods and implementation details needed
> to make it all work, but like the cells of a living organism, these
> details should be hidden and their use discouraged.  Hey, didn't someone
> say something along those lines once? :-)

Yes. :)

>> If all this work, the Cuis will be a lot less about my personal effort
>> and coding style, and the packages maintained by each one of us will
>> become the main characters in this story. And this will be a very good
>> thing. The base image should be about providing a good base for doing
>> the really interesting stuff on top...
>>
> I both agree (that the packages become more important) and disagree
> (that Cuis fades into the background).  I still view the core Cuis image
> as the philosophical and stylistic backbone that all of my stuff is
> based on.  It's a constant reminder to clean up and get rid of as much
> cruft as possible in my code (especially for the packages that have yet
> other packages dependent on them)  I freely admit that I am mostly
> falling short in my execution on this front, but it would be easy to
> lose sight of entirely if Cuis didn't stay the course.
>
>> Let me tell you a bit about how Cuis got started. Many years ago I did
>> my thesis on audio/music processing. The I wanted to turn that into a
>> novel and fun application for musicians (both pros and anyone willing to
>> play with sound). I started to think about how a good GUI for that could
>> be, giving the feeling of modifying sound by direct manipulation of it,
>> as if it was clay, as if it was visual and not just auditory. Well, that
>> was the start of my questioning of the whole GUI business and Morphic 3.
>> And it became clear to me that Squeak had turned into something that was
>> not the best possible environment to do all this. The idea of "fixing"
>> Squeak, and thus make Cuis, was born. So, Cuis was not and end in
>> itself, but a means for allowing experimentation, freedom to build
>> applications in new styles, etc.
>>
>> (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other
>> came later, as an observation on facts.)
>>
>> So, when the moment comes when Cuis stabilizes a bit, and interest moves
>> to packages and applications built by all us, Cuis will start to fulfill
>> its original objective.
>>
> It's already this is as far as I'm concerned.  I can't tell you much
> time I burned just trying to extract OpenGL from Croquet so that I could
> load it into Squeak, for example.  It was painful on both sides, and by
> the time I was done I had to think for a bit to remind myself what my
> original objective was... I have *never* had this issue with Cuis.
>
> It is absolutely enabling me to play around with ideas and build things
> that I couldn't have / wouldn't have bothered in Squeak.  The only issue
> I'm having is that once I've built it, I want to keep it running :-)
>
>> </slowly diverging into OT rant>
> Not at all a rant as it reaffirms *why* you're doing what you're doing.
> If you lost sight of that, that's when I'd start worrying about Cuis.
>
>>>> ...
>>>> The problem, I think, is not identifying well defined Cuis releases. The
>>>> problem is knowing how updates could affect your code
>>> By narrowing the scope of what the public API is using private
>>> designators, this dramatically reduces what you need to be concerned
>>> with on this front.  It's part of the reason that Apple, Google, and
>>> even Microsoft are so adamant about public APIs these days.  They dealt
>>> with the pain of even major developers depending on private APIs for
>>> decades. It's only been in the last 10 years or so that they've been
>>> able to dig themselves out from under this issue.
>>>
>>> This gets back to the 'Smalltalk Way' issue I referenced earlier.  The
>>> attitude of 'you have the source, play around, have fun!' has morphed
>>> into 'everything is a public API!  there are no rules! isn't this
>>> great?'  Well no, it's not great.  It makes life impossible for image
>>> maintainers (Squeak has been in a coma for the last decade or so as the
>>> result of trying to keep everyone happy... yet no one seems to be) and
>>> miserable for those who are trying to keep code running on it (stuff
>>> still breaks all the time.)
>> Yes.
>>
>>> I personally believe the minimalism and simplicity that Cuis is based on
>>> has the best long term prospects but we have to get out of this
>>> 'everything is public' mindset.  Sure, we have all the source: look at
>>> it, learn from it, poke around, refactor it, submit fixes, etc.  But
>>> there needs to be a manageable subset of it which is considered the
>>> 'public API' that people can depend on to write frameworks and apps on
>>> top of that is relatively stable longer term.  Let's start defining what
>>> that is and backfill changes to the public API (which will happen from
>>> time to time as we don't want things to be completely static) with tests
>>> and documentation so you can focus your efforts on where they matter
>>> most and you get the most enjoyment from.
>> I fully agree and support this.
>> Maybe an alternative to yet-another-convention-on-categories could be to
>> mark public methods with a pragma, or make them send 'self publicAPI' or
>> such... This could be better for the tools, also.
>>
> I like your idea better re: rather than having to go through and mark
> the majority as private, just mark the minority as public.  I'm open to
> either of your proposed approaches.  I just tossed out the two (method
> categories and naming) I was aware of but agree that they would not do
> much to ease developing tools to support/enforce.  Of the two ideas, am
> I correct in believing that pragma would have the lowest runtime
> overhead?  Are there any downsides you can think of to using pragma?

No that I can think of. A bit of experimentation is in order.

> Speaking of enforcing, I am not proposing that we make this a
> straight-jacket for anyone: it should be easy to opt-out the way things
> like underscore assignment are (except for pp which I'm still trying to
> get to an easily repro example with... :-) so that anyone who doesn't
> care about this isn't forced into it.  On the other hand, for people who
> do care, they should be able to leave it 'enabled', whatever that ends
> up meaning, and get help from the tooling to help them minimize
> potential future breakage.  The downside to opting out would be that
> you, as the author opting out, have decided to take it entirely on
> yourself to keep your code running across builds/releases.

Sure.

>>> ...
>>>> I don't have that either. I run the tests from time to time (I'll start
>>>> doing it before any commit, and add the xml report to the rep). But this
>>>> is not the most important reason why Cuis is solid. Cuis is very
>>>> reliable because:
>>> reliable != stable
>> ;)
>>
>>>> - I'm not too bad as a coder.
>>>> - I do my own code revisions at least one day after each change.
>>>> - I use Cuis every day, and spot most problems in the updates, before
>>>> commtting them to the repo.
>>>> - I really, really care about code quality.
>>>> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
>>>> is a big responsibility, given how important I think Smalltalk-80 is.
>>>>
>>> Agree to all this and more.  Cuis would not be where it is without your
>>> continued effort and diligence. (i.e. setting aside that you obviously
>>> created it, if you had just tossed it out into the world and let it go
>>> at best it would have started looking something like Squeak or Pharo by
>>> now.  It's a lot of effort over the long term to *keep* it small and
>>> focused.  THANK YOU JUAN!)
>> Thanks for your nice words, Phil. I really appreciate that you all
>> accept this rather restrictive dev model for the base image, in contrast
>> with a more open trunk style. Hopefully, as the base image becomes
>> stable and almost irrelevant, this will be each time less of a problem.
>>
>>>> So, I suggest running your tests when updating your image, or migrating
>>>> your code to an updated image.
>>> +1 to tests as they do help quite a bit and are a very good practice.
>>> Just be judicious in what/where you test (I personally don't subscribe
>>> to the TDD approach where you spend your days mostly writing tests.
>>> That's just admitting defeat in that you spend all day writing
>>> executable documentation.)
>> <OT>
>>
>> I don't subscribe to "extreme" TDD either. To me design is a creative
>> activity, both technical and artistic. It should be "driven" by
>> creativity and intelligence, not by a process. Any xDD process is
>> admitting defeat on design itself!
>>
> Heh... I like the way you put that.
>
>> </OT>
>>
>>>> In any case, I think this doesn't answer your concerns. What you need is
>>>> some way to know which updates could affect you, to review them in
>>>> detail, and understanding their effect on your code. A list of the
>>>> affected classes and/or methods for each update makes no sense. Cuis can
>>>> already show you that very easily. Perhaps each update should include:
>>>>
>>>> 1) parts of the system that are affected:
>>>> - Kernel
>>>> - Compiler
>>>> - Tools
>>>> - Morphic
>>>> - etc
>>>>
>>>> 2) Level of risk involved
>>>> - very unlikely to break code that depends on this part of the system
>>>> - could perhaps break code that depends on this part of the system
>>>> - will most likely break code that depends on this part of the system
>>>>
>>>> Or something like that.
>>>>
>>>> BTW, this is a very relevant topic for discussing on the mail list. Feel
>>>> free to answer there if you agree.
>>> One final thought on this:  I suspect a major cause of people abandoning
>>> Cuis (and Smalltalk in general), behind the 'it's too different from
>>> what I'm used to'/'not mainstream' reaction, is the instability of its
>>> APIs.
>> Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem)
>> is a PITA too...
> True, neither extreme (changing nothing vs. changing everything) works
> very well.<cough>Perl 6</cough>  :-)
>
>> As a bottom line, let me repeat: This is too big for me to do it.
>> Please, folks, start documenting the APIs you most care about.
>>
> Ready to go... we just need to agree on how to do it (pragma/method
> call/method category/method name?)  Also, this is most definitely
> related to the 'Canonical test cases?' thread from a few months ago as
> these types of test cases / docs are part of the backfill I was
> referring to.

I think pragmas are the best options. Also, "API existence tests" should 
ask for those APIs to be declared as public.

> As I've been writing this it occurs to me that there's probably a pretty
> easy way to go about getting started on this: IIRC, there are ~1,500
> distinct method names in the core image.  If I do a count of how many
> times my code is calling any of those methods, that should pop out what,
> for my code, is the low hanging fruit.  The long-tail of say 1-5 calls
> for the lesser used methods are the tedious work that will take more
> effort for me to sort through.  We could use my 'short list' to at least
> provide a starting point and using these most frequently called methods
> you could scan through the list and could say 'hey, why are you calling
> X instead of Y?' or maybe you'd get some visibility in the sense of
> 'wow, I didn't think that was being used'.  Hmm... I've got some
> analysis to do...

And some automated scripts to generate thos pragmas to write :)

Cheers,
Juan Vuletich



From juan at jvuletich.org  Thu Jul 23 09:59:38 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 23 Jul 2015 11:59:38 -0300
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
	checking them and Releases)
Message-ID: <55B1015A.2080109@jvuletich.org>

Hi Folks,

I've just re-read the very rich threads related to this. Thank you all 
for thoughtful and valuable considerations and opinions. This mail 
attempts to make really small summary, to start taking action.

First, the easiest. Releases
-------------------------------------
Several of you see real value on doing a few named releases per year. 
Theres' no big downside, so, let's do it. I think this is a good time to 
do a release. So, I'll refrain to introduce any major changes, except 
important bugfixes. Please start testing / updating / fixing your 
packages and applications. When we are all happy, and we all agree that 
the whole ecosystem is in a healthy state, we'll call that a release.

We need a name for this release. The obvious choice is "Cuis4.3-nnnn". 
So, there might be a Cuis4.3-2456, and as that branch evolves, a 
Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha" 
updates of Cuis4.4. So, I guess #2459 would be (a potential risky 
change) for Cuis 4.4. What if later we need to apply some patch to the 
stable Cuis4.3? How would we name it?

After a bit of discussion, I can take action. Or you can volunteer for 
Release Manager or member of the Release Team for Cuis 4.3.

Next, Documented, Public APIs
-------------------------------------------

Use pragmas, like PubicAPI (some method we intend to support and keep in 
that hierarchy), or CalledFromOutside (some method our yet-to-be-written 
tool detects as called from another package). Write tools for analyzing 
them. Do not remove them without due discussion.

It should be possible to write tests for existence of APIs.

This area is new to us, and we'll learn as we go.

Anybody can take action here. Documenting APIs by hand, writing tools to 
try to autogenerate them, writing tests that check for existence of 
specific APIs, whatever you can come up with.

This sounds like a major strategic direction, and in a very early stage, 
so maybe we'd not include anything of this in the Cuis4.3 release, but 
make this the start of the Cuis4.4 effort.

Thoughts? Or feel free to start coding!

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Thu Jul 23 16:26:38 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 23 Jul 2015 17:26:38 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <CAGQxfVh5AMJnVr3i-Kc2jomzTFoug5r1u=KbJa1VX6b_jruT6A@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com> <55B0F14D.7010405@jvuletich.org>
	<CAGQxfVh5AMJnVr3i-Kc2jomzTFoug5r1u=KbJa1VX6b_jruT6A@mail.gmail.com>
Message-ID: <1437686798.2326.73.camel@gmail.com>

On Thu, 2015-07-23 at 14:09 +0000, H. Hirzel wrote:
> 1) and 2) sounds like there is a need for an Ubuntu type of approach.
> 
> Labelled releases at regular intervals -- could be semi-annually or
> annually. Some of them receive important bux fixes thus constituting
> Long Term Releases.
> 

LTS releases are a *lot* of work and add quite a bit of drag.
Back-porting can be as much work as forward-porting (sometimes more.)  I
was thinking we start off as streamlined as possible: when 4.3 is
released, it becomes the stable branch.  At some point 4.4 (or whatever
version # makes sense) is nearing release and there is some period of RC
status for it.  When 4.4 goes stable, 4.3 is retired an so on.  That way
we only have one stable release at a time to be concerned with.

Also on the subject of LTS, I think we want to be careful not to get
into a Debian mode of operation.  That results in extreme stability at
the price of glacially slow change.

> Or stable vs unstable branches in github.
> 
> In two days on the 25th of July it will be exactly 2 years after the
> last release of 4.2.   :-)
> 

It's safe to say 2 years is a bit long between stable releases while 3
months would probably be too short.  I like yearly, but every 6 months
works too.  Since there's probably going to be a period of something
along the lines of RC status (a week?  a month?  no idea...) you don't
want the releases too often or you're chewing up a lot of time preparing
and testing releases and people are complaining that releases are too
frequent.  But that's just me spit-balling... I'm fine with whatever
people prefer.

> A point to consider as well is that what Juan is doing constitutes a
> trunk from which releases are forked from time to time by other
> people. The ones who run Feature Tests ....
> 

How this gets implemented depends largely on Juan's preference.  I guess
the way I envisioned it is that most of the changes being made could go
directly to stable (i.e. they are *mostly* bug fixes and behind the
scenes improvements).  Unless I'm mistaken, no one is really complaining
that a change might temporarily break something as the fixes for those
is almost always quick to arrive and don't require changes on our end
(at least nothing that I can recall.)  This would be more about changes
that will break/alter the behavior of the public APIs (i.e. there's good
reason to expect code breakage), either that goes into a
development/alpha branch or could be managed similarly to how I
*believe* Juan is handling Morphic 3 (i.e. changesets/packages that
don't get applied to stable but rather batched up until they're ready
for release driven both by the development effort and release timing)

For example, the FileMan code is something that I would be fine having
introduced in the middle of a stable branch's lifecycle.  Just don't
'flip the switch' on it (i.e. breaking code compatibility from an API
standpoint) until the next major stable release when there is sufficient
notice and documentation for people to make the move.  For me, it's all
a question of 'will the change break my code?'  I rather like bug fixes,
new features, and workflow improvements enough that to the extent
possible these should be encouraged in stable.  Would that be too
aggressive for you?

> --Hannes
> 
> On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:
> > On 7/19/2015 9:39 PM, Phil (list) wrote:
> >> ...
> >> It really comes down to what is Cuis?  Is it:
> >>
> >> 1) a minimal Smalltalk that you play around with ideas / prototype
> >> something in the short to intermediate term
> >>
> >> 2) a platform that you can take that idea you were playing around with,
> >> and if it proves out, build something more substantial from for the
> >> longer term
> >>
> >> 3) a completely experimental environment.  Anything can change at any
> >> time.  Supporting 1 is doable but 2 is doubtful.
> >>
> >> Right now, Cuis is great at 1 but seems like it should be able to handle
> >> both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
> >> all, but who knows, others may disagree.  If others look at it
> >> differently, I'd love to know how you look at Cuis.
> >
> > I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that
> > way.
> >
> > Cheers,
> > Juan Vuletich
> >
> > _______________________________________________
> > 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 pbpublist at gmail.com  Thu Jul 23 17:09:02 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 23 Jul 2015 18:09:02 -0400
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
 checking them and Releases)
In-Reply-To: <55B1015A.2080109@jvuletich.org>
References: <55B1015A.2080109@jvuletich.org>
Message-ID: <1437689342.2326.88.camel@gmail.com>

On Thu, 2015-07-23 at 11:59 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> I've just re-read the very rich threads related to this. Thank you all 
> for thoughtful and valuable considerations and opinions. This mail 
> attempts to make really small summary, to start taking action.

My quick summary to your previous replies: I agree!  :-)

> 
> First, the easiest. Releases
> -------------------------------------
> Several of you see real value on doing a few named releases per year. 
> Theres' no big downside, so, let's do it. I think this is a good time to 
> do a release. So, I'll refrain to introduce any major changes, except 
> important bugfixes. Please start testing / updating / fixing your 
> packages and applications. When we are all happy, and we all agree that 
> the whole ecosystem is in a healthy state, we'll call that a release.
> 
> We need a name for this release. The obvious choice is "Cuis4.3-nnnn". 
> So, there might be a Cuis4.3-2456, and as that branch evolves, a 
> Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha" 
> updates of Cuis4.4. So, I guess #2459 would be (a potential risky 
> change) for Cuis 4.4. What if later we need to apply some patch to the 
> stable Cuis4.3? How would we name it?
> 

My .02 on how we might manage the different branches is in my latest
reply to Hannes.  If you're happy with the way you're managing Morphic
3, why not start with that approach?  Or you could use two git branches
and periodically merge fixes from stable into development while you're
working on it, then merge development back into stable for release... or
something like that.  I'll defer to what you think will work best for
your workflow here...

> After a bit of discussion, I can take action. Or you can volunteer for 
> Release Manager or member of the Release Team for Cuis 4.3.
> 

Consider me volunteered.  I'll be happy to help in whatever way I can...
how can I best do that?  

> Next, Documented, Public APIs
> -------------------------------------------
> 
> Use pragmas, like PubicAPI (some method we intend to support and keep in 
> that hierarchy), or CalledFromOutside (some method our yet-to-be-written 
> tool detects as called from another package). Write tools for analyzing 
> them. Do not remove them without due discussion.
> 
> It should be possible to write tests for existence of APIs.
> 
> This area is new to us, and we'll learn as we go.
> 

Yep.  Undiscovered Country and it will likely take a few iterations to
get to what makes sense.

> Anybody can take action here. Documenting APIs by hand, writing tools to 
> try to autogenerate them, writing tests that check for existence of 
> specific APIs, whatever you can come up with.
> 
> This sounds like a major strategic direction, and in a very early stage, 
> so maybe we'd not include anything of this in the Cuis4.3 release, but 
> make this the start of the Cuis4.4 effort.
> 

Agreed.  Besides, I don't think we'll have even version 1 of APIs ready
for 4.3. (because the stable API stuff will likely still be, umm...
unstable)

> Thoughts? Or feel free to start coding!
> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From Ken.Dickey at whidbey.com  Thu Jul 23 02:13:17 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Thu, 23 Jul 2015 15:13:17 +0800
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
 checking them and Releases)
In-Reply-To: <55B1015A.2080109@jvuletich.org>
References: <55B1015A.2080109@jvuletich.org>
Message-ID: <20150723151317.b0caaf647bf8aecf6ec1491b@whidbey.com>

On Thu, 23 Jul 2015 11:59:38 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> We need a name for this release. The obvious choice is "Cuis4.3-nnnn". 
> So, there might be a Cuis4.3-2456, and as that branch evolves, a 
> Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha" 
> updates of Cuis4.4. So, I guess #2459 would be (a potential risky 
> change) for Cuis 4.4. What if later we need to apply some patch to the 
> stable Cuis4.3? How would we name it?

How about a fork with the suffix "-stable" ?

E.g. "4.2-stable", "4.3-stable", ...  The revisions on these would be independent of the main development thread.  Only bugfixes and (rare) backports.

$0.02
-KenD



From Ken.Dickey at whidbey.com  Thu Jul 23 22:39:03 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Thu, 23 Jul 2015 20:39:03 -0700
Subject: [Cuis] Morph default position
Message-ID: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>

My panels lost their titles.

This was because the WindowTitleMorphs were created and added to the window without setting the morphPosition to 0 at 0, so they were at 50 at 50, way outside the viewport of the windows.

Not difficult to fix, but there is a tension between being required to set morphPosition when/before/during addMorph* method sends and only setting morphPosition when the default is not desired.

FYI,
-KenD



From pbpublist at gmail.com  Fri Jul 24 03:26:52 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 24 Jul 2015 04:26:52 -0400
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT
 version number
In-Reply-To: <55B0F0B2.6090202@jvuletich.org>
References: <55B0F0B2.6090202@jvuletich.org>
Message-ID: <1437726412.2326.290.camel@gmail.com>

Juan,

On Thu, 2015-07-23 at 10:48 -0300, Juan Vuletich wrote:
> Very small snip (while preparing an answer for the whole thread):
> 
> On 7/19/2015 9:39 PM, Phil (list) wrote:
> > ...
> > communicated.  However, a problem I think he faces right now is that he
> > doesn't know who's using / depending on what.
> > ...
> 
> Yes. Cuis is MIT, etc. You don't have any obligations, etc.
> 
> But, if you tell what are you using Cuis for, and how, that is very 
> useful (and nice to know).
> If you are maintaining a significant code base, if possible, tell about 
> it. This will help us better support you.
> 

(You wrote this first but I responded to it last... still couldn't get
it as short as I had hoped... :-)

Much of what I am currently doing in Cuis falls into the broad
categories of data processing, visualization/simulation and prototyping.

1) Data processing: Lots of importers and exporters.  The data I need is
all over the place both on my local filesystem/network as well as from
various Internet sources in just about every format you can imagine
whether it's munging some HTML if that's the only place I can find what
I need or processing some XML, SQLite, other text/binary data files (it
totally depends on the data source: whatever the source uses is what I'm
stuck with.  Additionally, I may need to emit a different format than I
took in.)  As a result, I've had to port a number of packages (some of
which I still maintain, others I've deprecated as things like FFI and
XML have become core Cuis packages) and write my own to support both
getting data into and back out of Cuis.  If all the task I'm doing
requires is data processing, this might be the end of the story: suck
the data in from whatever source/format, perform any needed processing,
and spit it back out to whatever destination/format.

2) Visualization/simulation: often I'm not just doing a simple data
conversion, so once the data is in Cuis I might need to do some analysis
to see what I'm dealing with, generate some charts/graphs, visualize
relationships within a data set or the results of a simulation, etc.
Sometimes it's tabular data, sometimes 2D image data, sometimes 3D,
sometimes temporal (tabular|2D|3D.) This is why I've got both Morphic
and OpenGL code lying around: for quick and easy 2D Morphic is hard to
beat, 3D and/or performance requirements push you to OpenGL.

3) Prototyping: most of the 'production' code I'm dealing with is in
other languages (Java for Android apps as an example). However, I find
non-dynamic languages unpleasant to prototype in.  So I find myself
quite often playing around with my ideas in Cuis even though the
implementation target might be a different language/environment.  This
is all over the place in terms of the 'what' (UI, networking, algorithm,
etc.)  Sometimes these prototypes often result in more code related to 1
and 2. Sometimes I decide that I could re-use whatever I was working on
in Cuis too, so I keep it.  Recently, I've started thinking a bit
differently about this one. (see 4)

1 and 2 almost always go together in some way.  3 is sometimes
standalone, but more and more it includes 1 and/or 2.  All together, I'd
estimate that the uses described above has resulted in about 100K LoC
across dozens of Cuis project files.  Lots of little things, depending
on lots of other little things.

An example of how this all fits together for me just using mostly core
Cuis packages for something you're probably quite familiar with:  I need
to do work on some SVG files.  No problem: XML parser can help there.
But they're out on a web site: easy, use Protocols-HTTP.  Parse the
file: now I depend on some of my framework code that depends on XML
parser since XML parser only deals with structure, not content.  Doh!
The SVG has embedded images: grab the compression and PNG support
(Graphics-File-Additional) packages.  Now the file is loaded and fully
parsed and you want to look at it: grab some Morphic code for that.
Need it to draw fast?  Use OpenGL + yet more framework code instead...
and OpenGL adds an FFI dependency.  So you've now got basic SVG support
with 8 packages and are ready to start doing the actual work which will
require additional packages.  This is both probably not impressive as it
might sound (it's only a subset of SVG, structured in a particular way)
and somewhat oversimplified (uses some custom extensions) but you get
the idea.  It's pretty clean and modular and things can pretty quickly
touch a couple dozen packages for a single task.  Most of my stuff is a
lot of this sort of thing. (i.e. a fair bit of work just to get the data
into a usable internal format. Once in, life gets easier until it's time
to export...)

Some future plans/projects:

4) As a result of spending more time with OMeta, I'm becoming convinced
that I can increase my usage beyond what I describe in 3: design and
build a prototype in Cuis and actually emit the code for the target
platform/environment.  With OMeta, code becomes just another data
source / target so why not? (minor detail of frameworks that I make
hand-wavy motions when reminded of... )  This is on my longer term wish
list and seems doable, it's just a lot of work to get there.  For things
like OpenGL/GPU compute it's looking to be a necessity.  For other
platform targets the payoff is less certain but this is interesting
enough that I don't care... I'll probably try to do it regardless of
whether or not it turns out to be a good idea :-)

5) For web apps, I've been finding Seaside quite nice to work with and
have been steadily increasing the things I'm using it for over the last
couple of years.  While this isn't yet Cuis related, it seems like there
are enough of us interested in something like this that at some point
we'll either figure out how to get Seaside ported or come up with
another solution.  At that point, Cuis will have permeated just about
every aspect of my development life :-)

> It is nice to know to what extent something you do is useful for others. 
> I think it is also a polite and reasonable way to say thanks to us, 
> working for you.
> 

Absolutely.  That's also part of the reason I publish the packages I've
needed to port.  Life would have been so much simpler if someone had
taken care of that part so I didn't have to.  So, I push them out in the
hopes that it might save someone the trouble of having to deal with it
just as all of your efforts and others who have contributed to Cuis have
made my life easier.

> Cheers,
> Juan Vuletich

Thanks,
Phil




From pbpublist at gmail.com  Fri Jul 24 05:23:46 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 24 Jul 2015 06:23:46 -0400
Subject: [Cuis] Morph default position
In-Reply-To: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
References: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
Message-ID: <1437733426.2326.295.camel@gmail.com>

On Thu, 2015-07-23 at 20:39 -0700, Ken.Dickey wrote:
> My panels lost their titles.
> 
> This was because the WindowTitleMorphs were created and added to the window without setting the morphPosition to 0 at 0, so they were at 50 at 50, way outside the viewport of the windows.
> 
> Not difficult to fix, but there is a tension between being required to set morphPosition when/before/during addMorph* method sends and only setting morphPosition when the default is not desired.
> 

Insetting Morphs seemed like such a harmless suggestion...

> FYI,
> -KenD
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Fri Jul 24 07:00:12 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Fri, 24 Jul 2015 09:00:12 -0300
Subject: [Cuis] Morph default position
In-Reply-To: <1437733426.2326.295.camel@gmail.com>
References: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
	<1437733426.2326.295.camel@gmail.com>
Message-ID: <55B228CC.6000102@jvuletich.org>

Hi Folks,

On 7/24/2015 7:23 AM, Phil (list) wrote:
> On Thu, 2015-07-23 at 20:39 -0700, Ken.Dickey wrote:
>> My panels lost their titles.
>>
>> This was because the WindowTitleMorphs were created and added to the window without setting the morphPosition to 0 at 0, so they were at 50 at 50, way outside the viewport of the windows.
>>
>> Not difficult to fix, but there is a tension between being required to set morphPosition when/before/during addMorph* method sends and only setting morphPosition when the default is not desired.
>>
> Insetting Morphs seemed like such a harmless suggestion...

Uh, apologies. I also thought it would harmless. I'll take back that 
change, and set an offset only when adding to World.

Regards,
Juan Vuletich



From hannes.hirzel at gmail.com  Fri Jul 24 08:56:04 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Fri, 24 Jul 2015 13:56:04 +0000
Subject: [Cuis] Managing the evolution of Cuis (Public APIs,
 checking them and Releases)
In-Reply-To: <55B1015A.2080109@jvuletich.org>
References: <55B1015A.2080109@jvuletich.org>
Message-ID: <CAGQxfVgvt5b8AqF+se1mKrkwptFSSYFq3hOdxivuf1x=DvN8RA@mail.gmail.com>

On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:

Thanks for this summary, I think it captures what we have discussed.

Two comments below

--Hannes

> Hi Folks,
>
> I've just re-read the very rich threads related to this. Thank you all
> for thoughtful and valuable considerations and opinions. This mail
> attempts to make really small summary, to start taking action.
>
> First, the easiest. Releases
> -------------------------------------
> Several of you see real value on doing a few named releases per year.
> Theres' no big downside, so, let's do it. I think this is a good time to
> do a release. So, I'll refrain to introduce any major changes, except
> important bugfixes. Please start testing / updating / fixing your
> packages and applications. When we are all happy, and we all agree that
> the whole ecosystem is in a healthy state, we'll call that a release.
>
> We need a name for this release. The obvious choice is "Cuis4.3-nnnn".
> So, there might be a Cuis4.3-2456, and as that branch evolves, a
> Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha"
> updates of Cuis4.4. So, I guess #2459 would be (a potential risky
> change) for Cuis 4.4. What if later we need to apply some patch to the
> stable Cuis4.3? How would we name it?
>
> After a bit of discussion, I can take action. Or you can volunteer for
> Release Manager or member of the Release Team for Cuis 4.3.

A suggestion: label the version of tomorrow as Cuis 4.3

and then have a period (4...8 weeks?) where only bug fixes are allowed
and then release a version Cuis 4.4


Cuis 4.3 would then be what KenD calls a 'baseline' to measure against
until we have 4.4

>
> Next, Documented, Public APIs
> -------------------------------------------
>
> Use pragmas, like PubicAPI (some method we intend to support and keep in
> that hierarchy), or CalledFromOutside (some method our yet-to-be-written
> tool detects as called from another package). Write tools for analyzing
> them. Do not remove them without due discussion.
>
> It should be possible to write tests for existence of APIs.
>
> This area is new to us, and we'll learn as we go.
>
> Anybody can take action here. Documenting APIs by hand, writing tools to
> try to autogenerate them, writing tests that check for existence of
> specific APIs, whatever you can come up with.
>
> This sounds like a major strategic direction, and in a very early stage,
> so maybe we'd not include anything of this in the Cuis4.3 release, but
> make this the start of the Cuis4.4 effort.
>
> Thoughts? Or feel free to start coding!

I think we should start coding with FeatureTests which check for the
presence of classes and methods.

As independent packages in various repositories, after some
evaluation/testing/checking they should go to the packages folder.

> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From Ken.Dickey at whidbey.com  Fri Jul 24 09:10:02 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 24 Jul 2015 07:10:02 -0700
Subject: [Cuis] Morph default position
In-Reply-To: <55B228CC.6000102@jvuletich.org>
References: <20150723203903.c99664a52b20288671ba3f97@whidbey.com>
	<1437733426.2326.295.camel@gmail.com>
	<55B228CC.6000102@jvuletich.org>
Message-ID: <20150724071002.1a76620f39adb183005b4715@whidbey.com>

On Fri, 24 Jul 2015 09:00:12 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Uh, apologies. I also thought it would harmless. I'll take back that 
> change, and set an offset only when adding to World.

Or just add 
 Morph>>defaultPosition
	^ 50 at 50

And let subclasses override when it makes a difference..

$0.02
-KenD



From dnorton at mindspring.com  Fri Jul 24 15:20:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 24 Jul 2015 16:20:35 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55AD7737.30003@jvuletich.org>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>,
	<55AD7737.30003@jvuletich.org>
Message-ID: <55B29E13.29241.F06B25@dnorton.mindspring.com>

On 20 Jul 2015 at 19:33, Juan Vuletich wrote:

> 
> Hi Dan,
> 
> On 7/19/2015 10:13 PM, Dan Norton wrote:
>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
> 
>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>     > >
>     > >> Hi Folks,
>     > >>
>     > >> It is not too hard to build new StrikeFonts. You need to
> build,
>     > by
>     > >> hand,
>     > >> files like the ones in here:
>     > >>
>     >
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>     > >> p
>     > >> and learn a bit about stuff like #installDejaVu2 . Maybe it
> was
>     > with
>     > >> this method and the files in this zip that built the
> existing
>     > >> instances
>     > >> of StrikeFont. Not sure.
>     > >>
>     > > That's intrigueing but I can't reproduce it. Maybe the .bmp
> but
>     > where did you get the .txt?
>     > >
>     > >?? - Dan
>     >
>     > I wrote them with a text editor. Check #installDejaVu2 and
> really
>     > try to
>     > understand how StrikeFonts work and how they are built with
> this
>     > method.
>     > Maybe you'll become enlightened.
>     >
> 
>     A StrikeFont consists of a characterToGlyphMap, xTable, glyphs,
> name, and several 
>     scalars. StrikeFont class methods create fonts by processing
> file pairs assumed to be in the 
>     "AAFonts" subdirectory. For example:
> 
>     DejaVu Sans Oblique 14.bmp
>     DejaVu Sans Oblique 14.txt
> 
>     Is one such pair providing the italic (oblique) style for
> 14-point size. There is a pair for every 
>     font size and style: base, bold, italic, and bold italic.
> Therefore a font such as "DejaVu Sans" 
>     which is available in the size interval 5 to 24 requires 160
> files. The file names are stylized 
>     and encoded in the StrikeFont class methods.
> 
>     Glyphs come from the .bmp file. The .txt file is a string of
> numbers; the first three specify 
>     pointSize, ascent, and?descent. The rest of the numbers in the
> .txt file are used to form the 
>     xTable, which is the index into the glyphs for a character. The
> characterToGlyphMap is an 
>     array of 256 entries which map a character's ascii value to the
> xTable and thence to the 
>     glyphs.
> 
>     The bold, italic, and bold italic styles are stashed as
> derivatives of the base and not 
>     selectable from the current menus.
> 
>     StrikeFont is a subclass of AbstractFont, which has class
> variables AvailableFonts and 
>     DefaultFont.
> 
>     If it can't find a file, StrikeFont will loop.
> 
> Great! You got it all.
> 
>     In regard to creating the .bmp and .txt files, you say, " I
> wrote them with a text editor." 
>     Please tell me which text editor you used. None of mine do
> that.
> 
> The bmp files can be created with screen capture program, after
> entering suitable text in it. Maybe 
> you need to stitch several pieces together, etc. WRT the txt files,
> well, the editor didn't do it for 
> me. I wrote them. I _typed_ them. Maybe I used some (long lost) code
> to look for white columns 
> separating glyphs, but I'm not really sure. #xTallyPixelValue:orNot:
> and friends are great for this 
> kind of stuff.
> 
> In any case, it will be easier for you, as you want a monospaced
> font. Printing something like (32 
> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might be
> enough.
> 
> You have all the pieces at hand. it just requires a bit of
> patience.
> 

Encouraged by this, I have tried cobbling a fixed-width StrikeFont from Courier New which 
comes with Windows7. At this point, if some kind of fixed-width smudges would appear then 
it would be progress. Here's where I am:

The immediate problem is an error: 'Unsupported format. Try 
"Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter 
class>>formFromStream: examines the .bmp file.

Higher in the context, Form class>>fromBinaryStream: has firstByte = 66 which I mention 
because of the way the .bmp file was made. Here is the process I used, from the bottom up:

ImageMagick freeware	 produces the glyphs but with something stubbornly prepended. The 
command line is:
	convert -font \windows\fonts\cour.ttf -pointsize 12 label:@characters.txt 
courier12.bmp

Using NotePad, save characters.txt with encoding: UTF-8.

Paste the character string onto a NotePad

Copy the character string.

In a Cuis workspace print:
	str := String new writeStream.
	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
	str contents.

Code package and files allegedly for courier strike fonts are attached if you're 
interested.

 - Dan
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150724/bf929021/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CourierExample.zip
Type: application/zip
Size: 25150 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150724/bf929021/attachment-0004.zip>

From hannes.hirzel at gmail.com  Sat Jul 25 08:00:45 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 25 Jul 2015 13:00:45 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B29E13.29241.F06B25@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
	<55AD7737.30003@jvuletich.org>
	<55B29E13.29241.F06B25@dnorton.mindspring.com>
Message-ID: <CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>

I would try to save the *.bmp file as a *.gif file in Microsoft Paint
and then try to load it with

ImageReadWriter class>>formFromStream:

HTH

--HH

On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
>
>>
>> Hi Dan,
>>
>> On 7/19/2015 10:13 PM, Dan Norton wrote:
>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>>
>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>>     > >
>>     > >> Hi Folks,
>>     > >>
>>     > >> It is not too hard to build new StrikeFonts. You need to
>> build,
>>     > by
>>     > >> hand,
>>     > >> files like the ones in here:
>>     > >>
>>     >
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>>     > >> p
>>     > >> and learn a bit about stuff like #installDejaVu2 . Maybe it
>> was
>>     > with
>>     > >> this method and the files in this zip that built the
>> existing
>>     > >> instances
>>     > >> of StrikeFont. Not sure.
>>     > >>
>>     > > That's intrigueing but I can't reproduce it. Maybe the .bmp
>> but
>>     > where did you get the .txt?
>>     > >
>>     > >?? - Dan
>>     >
>>     > I wrote them with a text editor. Check #installDejaVu2 and
>> really
>>     > try to
>>     > understand how StrikeFonts work and how they are built with
>> this
>>     > method.
>>     > Maybe you'll become enlightened.
>>     >
>>
>>     A StrikeFont consists of a characterToGlyphMap, xTable, glyphs,
>> name, and several
>>     scalars. StrikeFont class methods create fonts by processing
>> file pairs assumed to be in the
>>     "AAFonts" subdirectory. For example:
>>
>>     DejaVu Sans Oblique 14.bmp
>>     DejaVu Sans Oblique 14.txt
>>
>>     Is one such pair providing the italic (oblique) style for
>> 14-point size. There is a pair for every
>>     font size and style: base, bold, italic, and bold italic.
>> Therefore a font such as "DejaVu Sans"
>>     which is available in the size interval 5 to 24 requires 160
>> files. The file names are stylized
>>     and encoded in the StrikeFont class methods.
>>
>>     Glyphs come from the .bmp file. The .txt file is a string of
>> numbers; the first three specify
>>     pointSize, ascent, and?descent. The rest of the numbers in the
>> .txt file are used to form the
>>     xTable, which is the index into the glyphs for a character. The
>> characterToGlyphMap is an
>>     array of 256 entries which map a character's ascii value to the
>> xTable and thence to the
>>     glyphs.
>>
>>     The bold, italic, and bold italic styles are stashed as
>> derivatives of the base and not
>>     selectable from the current menus.
>>
>>     StrikeFont is a subclass of AbstractFont, which has class
>> variables AvailableFonts and
>>     DefaultFont.
>>
>>     If it can't find a file, StrikeFont will loop.
>>
>> Great! You got it all.
>>
>>     In regard to creating the .bmp and .txt files, you say, " I
>> wrote them with a text editor."
>>     Please tell me which text editor you used. None of mine do
>> that.
>>
>> The bmp files can be created with screen capture program, after
>> entering suitable text in it. Maybe
>> you need to stitch several pieces together, etc. WRT the txt files,
>> well, the editor didn't do it for
>> me. I wrote them. I _typed_ them. Maybe I used some (long lost) code
>> to look for white columns
>> separating glyphs, but I'm not really sure. #xTallyPixelValue:orNot:
>> and friends are great for this
>> kind of stuff.
>>
>> In any case, it will be easier for you, as you want a monospaced
>> font. Printing something like (32
>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might be
>> enough.
>>
>> You have all the pieces at hand. it just requires a bit of
>> patience.
>>
>
> Encouraged by this, I have tried cobbling a fixed-width StrikeFont from
> Courier New which
> comes with Windows7. At this point, if some kind of fixed-width smudges
> would appear then
> it would be progress. Here's where I am:
>
> The immediate problem is an error: 'Unsupported format. Try
> "Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter
> class>>formFromStream: examines the .bmp file.
>
> Higher in the context, Form class>>fromBinaryStream: has firstByte = 66
> which I mention
> because of the way the .bmp file was made. Here is the process I used, from
> the bottom up:
>
> ImageMagick freeware	 produces the glyphs but with something stubbornly
> prepended. The
> command line is:
> 	convert -font \windows\fonts\cour.ttf -pointsize 12 label:@characters.txt
> courier12.bmp
>
> Using NotePad, save characters.txt with encoding: UTF-8.
>
> Paste the character string onto a NotePad
>
> Copy the character string.
>
> In a Cuis workspace print:
> 	str := String new writeStream.
> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
> 	str contents.
>
> Code package and files allegedly for courier strike fonts are attached if
> you're
> interested.
>
>  - Dan
>
>



From hannes.hirzel at gmail.com  Sat Jul 25 08:14:38 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 25 Jul 2015 13:14:38 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>
	<55AD7737.30003@jvuletich.org>
	<55B29E13.29241.F06B25@dnorton.mindspring.com>
	<CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>
Message-ID: <CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>

I did the StrikeFont exercises in Squeak. So it could be that Squeak
has a BMP file reader which is no longer included in Cuis. A thing to
check....

--HH

On 7/25/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> I would try to save the *.bmp file as a *.gif file in Microsoft Paint
> and then try to load it with
>
> ImageReadWriter class>>formFromStream:
>
> HTH
>
> --HH
>
> On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
>> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
>>
>>>
>>> Hi Dan,
>>>
>>> On 7/19/2015 10:13 PM, Dan Norton wrote:
>>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>>>
>>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>>>     > >
>>>     > >> Hi Folks,
>>>     > >>
>>>     > >> It is not too hard to build new StrikeFonts. You need to
>>> build,
>>>     > by
>>>     > >> hand,
>>>     > >> files like the ones in here:
>>>     > >>
>>>     >
>>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>>>     > >> p
>>>     > >> and learn a bit about stuff like #installDejaVu2 . Maybe it
>>> was
>>>     > with
>>>     > >> this method and the files in this zip that built the
>>> existing
>>>     > >> instances
>>>     > >> of StrikeFont. Not sure.
>>>     > >>
>>>     > > That's intrigueing but I can't reproduce it. Maybe the .bmp
>>> but
>>>     > where did you get the .txt?
>>>     > >
>>>     > >?? - Dan
>>>     >
>>>     > I wrote them with a text editor. Check #installDejaVu2 and
>>> really
>>>     > try to
>>>     > understand how StrikeFonts work and how they are built with
>>> this
>>>     > method.
>>>     > Maybe you'll become enlightened.
>>>     >
>>>
>>>     A StrikeFont consists of a characterToGlyphMap, xTable, glyphs,
>>> name, and several
>>>     scalars. StrikeFont class methods create fonts by processing
>>> file pairs assumed to be in the
>>>     "AAFonts" subdirectory. For example:
>>>
>>>     DejaVu Sans Oblique 14.bmp
>>>     DejaVu Sans Oblique 14.txt
>>>
>>>     Is one such pair providing the italic (oblique) style for
>>> 14-point size. There is a pair for every
>>>     font size and style: base, bold, italic, and bold italic.
>>> Therefore a font such as "DejaVu Sans"
>>>     which is available in the size interval 5 to 24 requires 160
>>> files. The file names are stylized
>>>     and encoded in the StrikeFont class methods.
>>>
>>>     Glyphs come from the .bmp file. The .txt file is a string of
>>> numbers; the first three specify
>>>     pointSize, ascent, and?descent. The rest of the numbers in the
>>> .txt file are used to form the
>>>     xTable, which is the index into the glyphs for a character. The
>>> characterToGlyphMap is an
>>>     array of 256 entries which map a character's ascii value to the
>>> xTable and thence to the
>>>     glyphs.
>>>
>>>     The bold, italic, and bold italic styles are stashed as
>>> derivatives of the base and not
>>>     selectable from the current menus.
>>>
>>>     StrikeFont is a subclass of AbstractFont, which has class
>>> variables AvailableFonts and
>>>     DefaultFont.
>>>
>>>     If it can't find a file, StrikeFont will loop.
>>>
>>> Great! You got it all.
>>>
>>>     In regard to creating the .bmp and .txt files, you say, " I
>>> wrote them with a text editor."
>>>     Please tell me which text editor you used. None of mine do
>>> that.
>>>
>>> The bmp files can be created with screen capture program, after
>>> entering suitable text in it. Maybe
>>> you need to stitch several pieces together, etc. WRT the txt files,
>>> well, the editor didn't do it for
>>> me. I wrote them. I _typed_ them. Maybe I used some (long lost) code
>>> to look for white columns
>>> separating glyphs, but I'm not really sure. #xTallyPixelValue:orNot:
>>> and friends are great for this
>>> kind of stuff.
>>>
>>> In any case, it will be easier for you, as you want a monospaced
>>> font. Printing something like (32
>>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might be
>>> enough.
>>>
>>> You have all the pieces at hand. it just requires a bit of
>>> patience.
>>>
>>
>> Encouraged by this, I have tried cobbling a fixed-width StrikeFont from
>> Courier New which
>> comes with Windows7. At this point, if some kind of fixed-width smudges
>> would appear then
>> it would be progress. Here's where I am:
>>
>> The immediate problem is an error: 'Unsupported format. Try
>> "Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter
>> class>>formFromStream: examines the .bmp file.
>>
>> Higher in the context, Form class>>fromBinaryStream: has firstByte = 66
>> which I mention
>> because of the way the .bmp file was made. Here is the process I used,
>> from
>> the bottom up:
>>
>> ImageMagick freeware	 produces the glyphs but with something stubbornly
>> prepended. The
>> command line is:
>> 	convert -font \windows\fonts\cour.ttf -pointsize 12
>> label:@characters.txt
>> courier12.bmp
>>
>> Using NotePad, save characters.txt with encoding: UTF-8.
>>
>> Paste the character string onto a NotePad
>>
>> Copy the character string.
>>
>> In a Cuis workspace print:
>> 	str := String new writeStream.
>> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
>> 	str contents.
>>
>> Code package and files allegedly for courier strike fonts are attached if
>> you're
>> interested.
>>
>>  - Dan
>>
>>
>



From dnorton at mindspring.com  Sat Jul 25 10:40:19 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 25 Jul 2015 11:40:19 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>,
	<CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>
Message-ID: <55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>

Form class>>fromBinaryStream: has firstByte = 66, this is not an error but part of "BM" in the header of the .bmp file.

The "Unsupported format..." error is caused by Cuis wanting biSize = 40 and ImageMagick 
putting a different value.

Squeak has BitstreamVeraSansMono, a fixed-width font. Why couldn't  that be used to 
produce .bmp files instead of ImageMagick? The BM header would be compatible with Cuis 
AFAIKT and it might get us a fixed-width font on Cuis.

On 25 Jul 2015 at 13:14, H. Hirzel wrote:

> I did the StrikeFont exercises in Squeak. So it could be that
> Squeak
> has a BMP file reader which is no longer included in Cuis. A thing
> to
> check....
> 
> --HH
> 
> On 7/25/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > I would try to save the *.bmp file as a *.gif file in Microsoft
> Paint
> > and then try to load it with
> >
> > ImageReadWriter class>>formFromStream:
> >
> > HTH
> >
> > --HH
> >
> > On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
> >> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
> >>
> >>>
> >>> Hi Dan,
> >>>
> >>> On 7/19/2015 10:13 PM, Dan Norton wrote:
> >>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
> >>>
> >>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
> >>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
> >>>     > >
> >>>     > >> Hi Folks,
> >>>     > >>
> >>>     > >> It is not too hard to build new StrikeFonts. You need
> to
> >>> build,
> >>>     > by
> >>>     > >> hand,
> >>>     > >> files like the ones in here:
> >>>     > >>
> >>>     >
> >>>
> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
> >>>     > >> p
> >>>     > >> and learn a bit about stuff like #installDejaVu2 .
> Maybe it
> >>> was
> >>>     > with
> >>>     > >> this method and the files in this zip that built the
> >>> existing
> >>>     > >> instances
> >>>     > >> of StrikeFont. Not sure.
> >>>     > >>
> >>>     > > That's intrigueing but I can't reproduce it. Maybe the
> .bmp
> >>> but
> >>>     > where did you get the .txt?
> >>>     > >
> >>>     > >?? - Dan
> >>>     >
> >>>     > I wrote them with a text editor. Check #installDejaVu2
> and
> >>> really
> >>>     > try to
> >>>     > understand how StrikeFonts work and how they are built
> with
> >>> this
> >>>     > method.
> >>>     > Maybe you'll become enlightened.
> >>>     >
> >>>
> >>>     A StrikeFont consists of a characterToGlyphMap, xTable,
> glyphs,
> >>> name, and several
> >>>     scalars. StrikeFont class methods create fonts by
> processing
> >>> file pairs assumed to be in the
> >>>     "AAFonts" subdirectory. For example:
> >>>
> >>>     DejaVu Sans Oblique 14.bmp
> >>>     DejaVu Sans Oblique 14.txt
> >>>
> >>>     Is one such pair providing the italic (oblique) style for
> >>> 14-point size. There is a pair for every
> >>>     font size and style: base, bold, italic, and bold italic.
> >>> Therefore a font such as "DejaVu Sans"
> >>>     which is available in the size interval 5 to 24 requires
> 160
> >>> files. The file names are stylized
> >>>     and encoded in the StrikeFont class methods.
> >>>
> >>>     Glyphs come from the .bmp file. The .txt file is a string
> of
> >>> numbers; the first three specify
> >>>     pointSize, ascent, and?descent. The rest of the numbers in
> the
> >>> .txt file are used to form the
> >>>     xTable, which is the index into the glyphs for a character.
> The
> >>> characterToGlyphMap is an
> >>>     array of 256 entries which map a character's ascii value to
> the
> >>> xTable and thence to the
> >>>     glyphs.
> >>>
> >>>     The bold, italic, and bold italic styles are stashed as
> >>> derivatives of the base and not
> >>>     selectable from the current menus.
> >>>
> >>>     StrikeFont is a subclass of AbstractFont, which has class
> >>> variables AvailableFonts and
> >>>     DefaultFont.
> >>>
> >>>     If it can't find a file, StrikeFont will loop.
> >>>
> >>> Great! You got it all.
> >>>
> >>>     In regard to creating the .bmp and .txt files, you say, "
> I
> >>> wrote them with a text editor."
> >>>     Please tell me which text editor you used. None of mine do
> >>> that.
> >>>
> >>> The bmp files can be created with screen capture program,
> after
> >>> entering suitable text in it. Maybe
> >>> you need to stitch several pieces together, etc. WRT the txt
> files,
> >>> well, the editor didn't do it for
> >>> me. I wrote them. I _typed_ them. Maybe I used some (long lost)
> code
> >>> to look for white columns
> >>> separating glyphs, but I'm not really sure.
> #xTallyPixelValue:orNot:
> >>> and friends are great for this
> >>> kind of stuff.
> >>>
> >>> In any case, it will be easier for you, as you want a
> monospaced
> >>> font. Printing something like (32
> >>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might
> be
> >>> enough.
> >>>
> >>> You have all the pieces at hand. it just requires a bit of
> >>> patience.
> >>>
> >>
> >> Encouraged by this, I have tried cobbling a fixed-width
> StrikeFont from
> >> Courier New which
> >> comes with Windows7. At this point, if some kind of fixed-width
> smudges
> >> would appear then
> >> it would be progress. Here's where I am:
> >>
> >> The immediate problem is an error: 'Unsupported format. Try
> >> "Graphics-Files-Additional.pck.st".' which arises when
> ImageReadWriter
> >> class>>formFromStream: examines the .bmp file.
> >>
> >> Higher in the context, Form class>>fromBinaryStream: has
> firstByte = 66
> >> which I mention
> >> because of the way the .bmp file was made. Here is the process I
> used,
> >> from
> >> the bottom up:
> >>
> >> ImageMagick freeware	 produces the glyphs but with something
> stubbornly
> >> prepended. The
> >> command line is:
> >> 	convert -font \windows\fonts\cour.ttf -pointsize 12
> >> label:@characters.txt
> >> courier12.bmp
> >>
> >> Using NotePad, save characters.txt with encoding: UTF-8.
> >>
> >> Paste the character string onto a NotePad
> >>
> >> Copy the character string.
> >>
> >> In a Cuis workspace print:
> >> 	str := String new writeStream.
> >> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
> >> 	str contents.
> >>
> >> Code package and files allegedly for courier strike fonts are
> attached if
> >> you're
> >> interested.
> >>
> >>  - Dan
> >>
> >>
> >
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From hannes.hirzel at gmail.com  Sat Jul 25 13:57:43 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Sat, 25 Jul 2015 18:57:43 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>
	<CAGQxfVgg=im4-MnbaR3JQtzQJtpOCqHkDVW+Lc1Ei0BZAWuvzA@mail.gmail.com>
	<CAGQxfViggy3_o6HqTSyJ0T0beCYLdys2errFwomV39ZkCS3ZVg@mail.gmail.com>
	<55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>
Message-ID: <CAGQxfVggp67RO7k4q8Cgh4thyi4AQTWpvwVSapXMb=LTrR3eqQ@mail.gmail.com>

Then I would try to export the Squeak BitstreamVeraSansMono in
StrikeFont format and import into Cuis. That should work ...

On 7/25/15, Dan Norton <dnorton at mindspring.com> wrote:
> Form class>>fromBinaryStream: has firstByte = 66, this is not an error but
> part of "BM" in the header of the .bmp file.
>
> The "Unsupported format..." error is caused by Cuis wanting biSize = 40 and
> ImageMagick
> putting a different value.
>
> Squeak has BitstreamVeraSansMono, a fixed-width font. Why couldn't  that be
> used to
> produce .bmp files instead of ImageMagick? The BM header would be compatible
> with Cuis
> AFAIKT and it might get us a fixed-width font on Cuis.
>
> On 25 Jul 2015 at 13:14, H. Hirzel wrote:
>
>> I did the StrikeFont exercises in Squeak. So it could be that
>> Squeak
>> has a BMP file reader which is no longer included in Cuis. A thing
>> to
>> check....
>>
>> --HH
>>
>> On 7/25/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> > I would try to save the *.bmp file as a *.gif file in Microsoft
>> Paint
>> > and then try to load it with
>> >
>> > ImageReadWriter class>>formFromStream:
>> >
>> > HTH
>> >
>> > --HH
>> >
>> > On 7/24/15, Dan Norton <dnorton at mindspring.com> wrote:
>> >> On 20 Jul 2015 at 19:33, Juan Vuletich wrote:
>> >>
>> >>>
>> >>> Hi Dan,
>> >>>
>> >>> On 7/19/2015 10:13 PM, Dan Norton wrote:
>> >>>     On 19 Jul 2015 at 10:31, Juan Vuletich wrote:
>> >>>
>> >>>     > On 7/18/2015 3:37 PM, Dan Norton wrote:
>> >>>     > > On 11 Jul 2015 at 13:40, Juan Vuletich wrote:
>> >>>     > >
>> >>>     > >> Hi Folks,
>> >>>     > >>
>> >>>     > >> It is not too hard to build new StrikeFonts. You need
>> to
>> >>> build,
>> >>>     > by
>> >>>     > >> hand,
>> >>>     > >> files like the ones in here:
>> >>>     > >>
>> >>>     >
>> >>>
>> https://dl.dropboxusercontent.com/u/13285702/BitmapDejaVuAllSizes.zi
>> >>>     > >> p
>> >>>     > >> and learn a bit about stuff like #installDejaVu2 .
>> Maybe it
>> >>> was
>> >>>     > with
>> >>>     > >> this method and the files in this zip that built the
>> >>> existing
>> >>>     > >> instances
>> >>>     > >> of StrikeFont. Not sure.
>> >>>     > >>
>> >>>     > > That's intrigueing but I can't reproduce it. Maybe the
>> .bmp
>> >>> but
>> >>>     > where did you get the .txt?
>> >>>     > >
>> >>>     > >?? - Dan
>> >>>     >
>> >>>     > I wrote them with a text editor. Check #installDejaVu2
>> and
>> >>> really
>> >>>     > try to
>> >>>     > understand how StrikeFonts work and how they are built
>> with
>> >>> this
>> >>>     > method.
>> >>>     > Maybe you'll become enlightened.
>> >>>     >
>> >>>
>> >>>     A StrikeFont consists of a characterToGlyphMap, xTable,
>> glyphs,
>> >>> name, and several
>> >>>     scalars. StrikeFont class methods create fonts by
>> processing
>> >>> file pairs assumed to be in the
>> >>>     "AAFonts" subdirectory. For example:
>> >>>
>> >>>     DejaVu Sans Oblique 14.bmp
>> >>>     DejaVu Sans Oblique 14.txt
>> >>>
>> >>>     Is one such pair providing the italic (oblique) style for
>> >>> 14-point size. There is a pair for every
>> >>>     font size and style: base, bold, italic, and bold italic.
>> >>> Therefore a font such as "DejaVu Sans"
>> >>>     which is available in the size interval 5 to 24 requires
>> 160
>> >>> files. The file names are stylized
>> >>>     and encoded in the StrikeFont class methods.
>> >>>
>> >>>     Glyphs come from the .bmp file. The .txt file is a string
>> of
>> >>> numbers; the first three specify
>> >>>     pointSize, ascent, and?descent. The rest of the numbers in
>> the
>> >>> .txt file are used to form the
>> >>>     xTable, which is the index into the glyphs for a character.
>> The
>> >>> characterToGlyphMap is an
>> >>>     array of 256 entries which map a character's ascii value to
>> the
>> >>> xTable and thence to the
>> >>>     glyphs.
>> >>>
>> >>>     The bold, italic, and bold italic styles are stashed as
>> >>> derivatives of the base and not
>> >>>     selectable from the current menus.
>> >>>
>> >>>     StrikeFont is a subclass of AbstractFont, which has class
>> >>> variables AvailableFonts and
>> >>>     DefaultFont.
>> >>>
>> >>>     If it can't find a file, StrikeFont will loop.
>> >>>
>> >>> Great! You got it all.
>> >>>
>> >>>     In regard to creating the .bmp and .txt files, you say, "
>> I
>> >>> wrote them with a text editor."
>> >>>     Please tell me which text editor you used. None of mine do
>> >>> that.
>> >>>
>> >>> The bmp files can be created with screen capture program,
>> after
>> >>> entering suitable text in it. Maybe
>> >>> you need to stitch several pieces together, etc. WRT the txt
>> files,
>> >>> well, the editor didn't do it for
>> >>> me. I wrote them. I _typed_ them. Maybe I used some (long lost)
>> code
>> >>> to look for white columns
>> >>> separating glyphs, but I'm not really sure.
>> #xTallyPixelValue:orNot:
>> >>> and friends are great for this
>> >>> kind of stuff.
>> >>>
>> >>> In any case, it will be easier for you, as you want a
>> monospaced
>> >>> font. Printing something like (32
>> >>> to: 255) collect: [ :ascii | ascii-32 * 9 ] into the file might
>> be
>> >>> enough.
>> >>>
>> >>> You have all the pieces at hand. it just requires a bit of
>> >>> patience.
>> >>>
>> >>
>> >> Encouraged by this, I have tried cobbling a fixed-width
>> StrikeFont from
>> >> Courier New which
>> >> comes with Windows7. At this point, if some kind of fixed-width
>> smudges
>> >> would appear then
>> >> it would be progress. Here's where I am:
>> >>
>> >> The immediate problem is an error: 'Unsupported format. Try
>> >> "Graphics-Files-Additional.pck.st".' which arises when
>> ImageReadWriter
>> >> class>>formFromStream: examines the .bmp file.
>> >>
>> >> Higher in the context, Form class>>fromBinaryStream: has
>> firstByte = 66
>> >> which I mention
>> >> because of the way the .bmp file was made. Here is the process I
>> used,
>> >> from
>> >> the bottom up:
>> >>
>> >> ImageMagick freeware	 produces the glyphs but with something
>> stubbornly
>> >> prepended. The
>> >> command line is:
>> >> 	convert -font \windows\fonts\cour.ttf -pointsize 12
>> >> label:@characters.txt
>> >> courier12.bmp
>> >>
>> >> Using NotePad, save characters.txt with encoding: UTF-8.
>> >>
>> >> Paste the character string onto a NotePad
>> >>
>> >> Copy the character string.
>> >>
>> >> In a Cuis workspace print:
>> >> 	str := String new writeStream.
>> >> 	(32 to: 255) do: [ :n | str nextPut: n asCharacter]
>> >> 	str contents.
>> >>
>> >> Code package and files allegedly for courier strike fonts are
>> attached if
>> >> you're
>> >> interested.
>> >>
>> >>  - Dan
>> >>
>> >>
>> >
>>
>> _______________________________________________
>> 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 dnorton at mindspring.com  Sat Jul 25 14:34:34 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 25 Jul 2015 15:34:34 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <CAGQxfVggp67RO7k4q8Cgh4thyi4AQTWpvwVSapXMb=LTrR3eqQ@mail.gmail.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55B3ADE3.25826.BE7BF6@dnorton.mindspring.com>,
	<CAGQxfVggp67RO7k4q8Cgh4thyi4AQTWpvwVSapXMb=LTrR3eqQ@mail.gmail.com>
Message-ID: <55B3E4CA.22470.194F1C5@dnorton.mindspring.com>

On 25 Jul 2015 at 18:57, H. Hirzel wrote:

> Then I would try to export the Squeak BitstreamVeraSansMono in
> StrikeFont format and import into Cuis. That should work ...
>

Yes, but the problem is how to get BitstreamVeraSansMono into StrikeFont format.

In Squeak 4.6, the font of a character string in the transcript can be changed from the default 
to one of the BitstreamVeraSansMono sizes: #(9 12 15 24 36). Digging down through the 
Transcript submorphs I found aTextMorphForEditView. When this is sent 
"exportAsBMPNamed: 'sansmono12.bmp'" for example, the image in the Transcript is placed 
in the .bmp file.

This needs improvement. The good news is that the glyphs appear to be sized and shaped 
based on the font. The bad news is that the .bmp file contains a multi-line image, exactly as it 
appears in the transcript and the entire first line of this appears to result from the blank (ascii 
32). The next line looks pretty good until it reaches the edge of the pane where it stops. The 
following characters are on the next line, etc.

What's needed is a morph which will contain the entire character set 32 to 255 without 
wrapping and with the desired font. That morph can be sent the #exportAsBMPNamed: 
message and then maybe we can make a strikefont.

[ snip ]

 - Dan



From juan at jvuletich.org  Sat Jul 25 16:31:18 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 25 Jul 2015 18:31:18 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B29E13.29241.F06B25@dnorton.mindspring.com>
References: <559DBA3B.28326.21224C9@dnorton.mindspring.com>,
	<55AC4B3F.19938.1F92268@dnorton.mindspring.com>,
	<55AD7737.30003@jvuletich.org>
	<55B29E13.29241.F06B25@dnorton.mindspring.com>
Message-ID: <55B40026.6010208@jvuletich.org>

Hi Dan,

The format saved by image writer is not (currently) supported in Cuis, 
Squeak, etc. Maybe there is a command line option to tell imageMagick to 
use a more standard bmp format. Or you can just save in png. I opened 
them in Windows Paint, clicked on 'save' and then Cuis was able to read 
them.

Your xTables in the txt files are indeed wrong. For Courier12, the width 
of the bmp file is around 1500 pixels. And in the xTable you have 
entries calling pixels around x=2600. Impossible. Take a look at the bmp 
you generated count the width used by each glyph. It is 7 pixels wide. 
Your xTable is multiples of 12...

After fixing this 2 issues, I run your stuff and indeed it starts to 
run. It looks like a bit more work is needed in the xTable, though.

Cheers,
Juan Vuletich

On 7/24/2015 5:20 PM, Dan Norton wrote:
>
> Encouraged by this, I have tried cobbling a fixed-width StrikeFont 
> from Courier New which comes with Windows7. At this point, if some 
> kind of fixed-width smudges would appear then it would be progress. 
> Here's where I am:
>
> The immediate problem is an error: 'Unsupported format. Try 
> "Graphics-Files-Additional.pck.st".' which arises when ImageReadWriter 
> class>>formFromStream: examines the .bmp file.
>
> Higher in the context, Form class>>fromBinaryStream: has firstByte = 
> 66 which I mention because of the way the .bmp file was made. Here is 
> the process I used, from the bottom up:
>
> ImageMagick freeware produces the glyphs but with something stubbornly 
> prepended. The command line is:
>            convert -font \windows\fonts\cour.ttf -pointsize 12 
> label:@characters.txt courier12.bmp
>
> Using NotePad, save characters.txt with encoding: UTF-8.
>
> Paste the character string onto a NotePad
>
> Copy the character string.
>
> In a Cuis workspace print:
>            str := String new writeStream.
>            (32 to: 255) do: [ :n | str nextPut: n asCharacter]
>            str contents.
>
> Code package and files allegedly for courier strike fonts are attached 
> if you're interested.
>
>  - Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150725/797d695b/attachment-0004.html>

From juan at jvuletich.org  Sat Jul 25 17:36:58 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 25 Jul 2015 19:36:58 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <20150705095751.c84ded291d123bac31348c46@whidbey.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>	<559938A2.3040204@jvuletich.org>
	<20150705095751.c84ded291d123bac31348c46@whidbey.com>
Message-ID: <55B40F8A.1030706@jvuletich.org>

I fixed this a few days ago. Please check. If there's some problem there 
yet, please complain :)

Cheers,
Juan Vuletich

Ps. It is getting a bit hard to find enough time for all this. That's 
why I'm slow answering. Please never refrain from insisting if I don't 
answer.

On 7/4/2015 10:57 PM, Ken.Dickey wrote:
> On Sun, 05 Jul 2015 11:01:06 -0300
> Juan Vuletich<juan at jvuletich.org>  wrote:
>
>> Hi Ken,
>>
>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>> Juan,
>>>
>>> The Installed Packages browser used to be able to require a minimum revision on the base release.
>>>
>>> I use this feature as a backstop when features change in the base release.
>>>
>>> Any chance in getting this ability back?
>>>
>>> Thanks much,
>>> -KenD
>> When was it lost?  I can't remember doing anything related to this...
> Not sure when.
>
> If there is more than one package loaded, one can Add Requirement with one option being the base release.  If only one package is loaded, one gets the "Required package must already be loaded" popup, rather than an option to require Cuis-Base.
>




From dnorton at mindspring.com  Sat Jul 25 20:41:03 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 25 Jul 2015 21:41:03 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <55B43AAF.12784.2E478F5@dnorton.mindspring.com>

Attached is a StrikeFont of Courier New 12. It's hacked - not polished by any means. It was 
made by:

Making "characters.txt" by printing in a Cuis workspace, copying to Notepad, and saving with 
encoding: ANSI.

This was input to ImageMagick to make a .png file.

The .png file was opened in Paint, then saved as a .bmp file.

The body of the .txt file was generated by:
(32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 - needed to avoid index out of range"

The first three numbers in .txt were finagled to 12 15 5 (the last two anyway).

The font was installed by running:
StrikeFont installCourier.  "code in Courier.pck.st "

Text in the Text Editor pane was highlighted and the font changed to Courier 12 point. It 
looked much too small. Going back to Paint, the glyphs were selected and stretched 
vertically. The font was re-installed. The vertical distortion is probably obvious.

At least it's recognizable as Courier and it's fixed width. Files are attached.

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CourierExample2.zip
Type: application/zip
Size: 10523 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150725/30c1a018/attachment-0004.zip>

From dnorton at mindspring.com  Sun Jul 26 17:47:53 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 26 Jul 2015 15:47:53 -0700 (PDT)
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT
 version number
In-Reply-To: <55B0F0B2.6090202@jvuletich.org>
References: <55B0F0B2.6090202@jvuletich.org>
Message-ID: <1437950873600-4839529.post@n4.nabble.com>


Very small snip (while preparing an answer for the whole thread):

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.
> ...

Yes. Cuis is MIT, etc. You don't have any obligations, etc.

But, if you tell what are you using Cuis for, and how, that is very 
useful (and nice to know).
If you are maintaining a significant code base, if possible, tell about 
it. This will help us better support you.


How I want to use Cuis:

Multi-player games. Juan, are you going to put your Scrabble in a Cuis
package?

App delivery sans IDE, halos, menus

Apps with feedback; output becomes next input

Recognition biometrics

Financial analysis

Anything fun

 - Dan




--
View this message in context: http://forum.world.st/Please-tell-about-your-projects-Re-Fwd-Re-DIRECT-version-number-tp4838865p4839529.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From hannes.hirzel at gmail.com  Mon Jul 27 01:54:17 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 27 Jul 2015 06:54:17 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <55B40F8A.1030706@jvuletich.org>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<559938A2.3040204@jvuletich.org>
	<20150705095751.c84ded291d123bac31348c46@whidbey.com>
	<55B40F8A.1030706@jvuletich.org>
Message-ID: <CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>

On 7/25/15, Juan Vuletich <juan at jvuletich.org> wrote:
> I fixed this a few days ago. Please check. If there's some problem there
> yet, please complain :)
>
> Cheers,
> Juan Vuletich
>
> Ps. It is getting a bit hard to find enough time for all this. That's
> why I'm slow answering. Please never refrain from insisting if I don't
> answer.

Thank you for this fix. Has it been committed?
The last commit is 8 days ago.
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/e9568515b8db6c5e251e209edae60819d7ba4b63

--Hannes


> On 7/4/2015 10:57 PM, Ken.Dickey wrote:
>> On Sun, 05 Jul 2015 11:01:06 -0300
>> Juan Vuletich<juan at jvuletich.org>  wrote:
>>
>>> Hi Ken,
>>>
>>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>>> Juan,
>>>>
>>>> The Installed Packages browser used to be able to require a minimum
>>>> revision on the base release.
>>>>
>>>> I use this feature as a backstop when features change in the base
>>>> release.
>>>>
>>>> Any chance in getting this ability back?
>>>>
>>>> Thanks much,
>>>> -KenD
>>> When was it lost?  I can't remember doing anything related to this...
>> Not sure when.
>>
>> If there is more than one package loaded, one can Add Requirement with one
>> option being the base release.  If only one package is loaded, one gets
>> the "Required package must already be loaded" popup, rather than an option
>> to require Cuis-Base.
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From hannes.hirzel at gmail.com  Mon Jul 27 01:59:47 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 27 Jul 2015 06:59:47 +0000
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>
	<559938A2.3040204@jvuletich.org>
	<20150705095751.c84ded291d123bac31348c46@whidbey.com>
	<55B40F8A.1030706@jvuletich.org>
	<CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>
Message-ID: <CAGQxfVgT9Crbu1V7TEQ_baYf+On=7aECUMf7MzB7S6Ri4tBw0Q@mail.gmail.com>

BTW you are NOT slow in answering. Take you time.

For confirming  that the feature is back indeed
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/70

On 7/27/15, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> On 7/25/15, Juan Vuletich <juan at jvuletich.org> wrote:
>> I fixed this a few days ago. Please check. If there's some problem there
>> yet, please complain :)
>>
>> Cheers,
>> Juan Vuletich
>>
>> Ps. It is getting a bit hard to find enough time for all this. That's
>> why I'm slow answering. Please never refrain from insisting if I don't
>> answer.
>
> Thank you for this fix. Has it been committed?
> The last commit is 8 days ago.
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/e9568515b8db6c5e251e209edae60819d7ba4b63
>
> --Hannes
>
>
>> On 7/4/2015 10:57 PM, Ken.Dickey wrote:
>>> On Sun, 05 Jul 2015 11:01:06 -0300
>>> Juan Vuletich<juan at jvuletich.org>  wrote:
>>>
>>>> Hi Ken,
>>>>
>>>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>>>> Juan,
>>>>>
>>>>> The Installed Packages browser used to be able to require a minimum
>>>>> revision on the base release.
>>>>>
>>>>> I use this feature as a backstop when features change in the base
>>>>> release.
>>>>>
>>>>> Any chance in getting this ability back?
>>>>>
>>>>> Thanks much,
>>>>> -KenD
>>>> When was it lost?  I can't remember doing anything related to this...
>>> Not sure when.
>>>
>>> If there is more than one package loaded, one can Add Requirement with
>>> one
>>> option being the base release.  If only one package is loaded, one gets
>>> the "Required package must already be loaded" popup, rather than an
>>> option
>>> to require Cuis-Base.
>>>
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>



From juan at jvuletich.org  Mon Jul 27 09:40:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 27 Jul 2015 11:40:34 -0300
Subject: [Cuis] Package wants to require minimum revision on base
In-Reply-To: <CAGQxfVgT9Crbu1V7TEQ_baYf+On=7aECUMf7MzB7S6Ri4tBw0Q@mail.gmail.com>
References: <20150704160424.0c4a7a50547660f288893bbd@whidbey.com>	<559938A2.3040204@jvuletich.org>	<20150705095751.c84ded291d123bac31348c46@whidbey.com>	<55B40F8A.1030706@jvuletich.org>	<CAGQxfViJEAUkwRTv6WWRtxGZrV15-f4z2RSyc3iZY+sx67x55A@mail.gmail.com>
	<CAGQxfVgT9Crbu1V7TEQ_baYf+On=7aECUMf7MzB7S6Ri4tBw0Q@mail.gmail.com>
Message-ID: <55B642E2.6040203@jvuletich.org>

On 7/27/2015 3:59 AM, H. Hirzel wrote:
> BTW you are NOT slow in answering. Take you time.

:)

> For confirming  that the feature is back indeed
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/70

Ken confirmed that it is working ok. I closed the issue.

Thanks,
Juan Vuletich

> On 7/27/15, H. Hirzel<hannes.hirzel at gmail.com>  wrote:
>> On 7/25/15, Juan Vuletich<juan at jvuletich.org>  wrote:
>>> I fixed this a few days ago. Please check. If there's some problem there
>>> yet, please complain :)
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> Ps. It is getting a bit hard to find enough time for all this. That's
>>> why I'm slow answering. Please never refrain from insisting if I don't
>>> answer.
>> Thank you for this fix. Has it been committed?
>> The last commit is 8 days ago.
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/e9568515b8db6c5e251e209edae60819d7ba4b63
>>
>> --Hannes
>>
>>
>>> On 7/4/2015 10:57 PM, Ken.Dickey wrote:
>>>> On Sun, 05 Jul 2015 11:01:06 -0300
>>>> Juan Vuletich<juan at jvuletich.org>   wrote:
>>>>
>>>>> Hi Ken,
>>>>>
>>>>> On 04/07/2015 05:04 a.m., Ken.Dickey wrote:
>>>>>> Juan,
>>>>>>
>>>>>> The Installed Packages browser used to be able to require a minimum
>>>>>> revision on the base release.
>>>>>>
>>>>>> I use this feature as a backstop when features change in the base
>>>>>> release.
>>>>>>
>>>>>> Any chance in getting this ability back?
>>>>>>
>>>>>> Thanks much,
>>>>>> -KenD
>>>>> When was it lost?  I can't remember doing anything related to this...
>>>> Not sure when.
>>>>
>>>> If there is more than one package loaded, one can Add Requirement with
>>>> one
>>>> option being the base release.  If only one package is loaded, one gets
>>>> the "Required package must already be loaded" popup, rather than an
>>>> option
>>>> to require Cuis-Base.
>>>>
>>>
>>> _______________________________________________
>>> 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  Mon Jul 27 09:58:27 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 27 Jul 2015 11:58:27 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6BMwgF9pffS7TWaPKTi8EkE2X-puM=e0NQNBn1gW5Z4Pw@mail.gmail.com>
References: <CAGQxfVhtR6zezHW4Nji0kHU3str2Zf4Dbfdn5VjphgAqwnuz-g@mail.gmail.com>
	<20140501080531.493624077a7c3f67688650f9@whidbey.com>
	<CAGQxfVgeyXkyu5Rqdn2T9T+iY5rYzEVy9w76N0=scZCR+-iy3w@mail.gmail.com>
	<CAEt3aLxfNLqDJ3LhBZFdwSO5VjcPDmQcStXWiTEts8YBsWLvxw@mail.gmail.com>
	<CA+=t-6DwrOQwVB3QeTWaL=rGG7=g5J-poDh5UR9tpMXFtnsPbg@mail.gmail.com>
	<CAGQxfVg4wzvPRBg-XRP3dFWw_EbV=in7ZCiK-TzYJzV+MP9y0A@mail.gmail.com>
	<CAGQxfVjyHyA1R1aEuaNcpiyFqOG+zSy8SzqqqeD7drG8kSzZPQ@mail.gmail.com>
	<555A8705.5080502@jvuletich.org>
	<CA+=t-6C7Bh+2YRfNwEdfUJDcn=cx=NNXTc-DuWfyJ5ZbbKYeHQ@mail.gmail.com>
	<5573BD8C.4010008@jvuletich.org>
	<CA+=t-6BMwgF9pffS7TWaPKTi8EkE2X-puM=e0NQNBn1gW5Z4Pw@mail.gmail.com>
Message-ID: <55B64713.8040806@jvuletich.org>

Hi Masashi,

Recently we found that in FileMan, if we do

'inexistentFile' asFileEntry readStream

we get an empty readStream.

I think it is better to throw the #fileDoesNotExistException , as 
FileDirectory did, and let the user handle the exception appropriately. 
But I would not want to break compatibility with FileMan, as the main 
purpose of FileMan is to give compatibility amongst dialects.

Are there good reasons to avoid the exception? Should we add another 
method, besides #readStream when we want a readStream strictly on 
existing file contents?

Thanks,
Juan Vuletich


On 6/14/2015 8:38 AM, Masashi UMEZAWA wrote:
> Hello Juan,
>
> Thank you for the patches and more tests! I'll adapt those updates for
> other FileMan ports.
>
> Best regards,
>
> 2015-06-07 12:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>> Hi Masashi,
>>
>> I was trying FileMan tests today and I saw they create some folders in my
>> drive. The names looked a bit strange, so I took a closer look and found a
>> couple of bugs. At least on Windows, #testRecursiveDelete instead of
>> creating
>>        subDir/aaa/bbb/ccc/ddd/eee/fff/ggg/test1
>> it created
>>         subDir/bbb/ccc/eee/ggg/test!
>>
>> So I wrote a few more tests on the issues I saw, and teaked the code to make
>> them pass. The result is attached, and I think is useful for all ports of
>> FileMan.
>>
>> Thanks,
>> Juan Vuletich
>>
>> On 5/26/2015 11:34 PM, Masashi UMEZAWA wrote:
>>> Hi all,
>>>
>>> I think it is nice if FileMan is on the core package repository.
>>>
>>> FileMan for Cuis (and Squeak) has minimum dependencies to the existing
>>> FileDirectory and DirectoryEntry. FileMan selectively uses a few
>>> methods of them.
>>>
>>> So we can gradually adopt FileMan interfaces and trim the
>>> FileDirectory and DirectoryEntry's non-intuitive methods.
>>>
>>> Another way of cleaning-up the file-related classes is to port
>>> FileSystems to Cuis.
>>> But since Cuis is a lightweight Smalltalk dialect, FileSystems might
>>> be an overkill.
>>>
>>> Best regards,
>>>
>>> 2015-05-19 9:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>>>> Hi Folks,
>>>>
>>>> I apologize for talking before taking even a quick look, but anyway, We'd
>>>> take a good look at this. And seriously consider replacing files stuff in
>>>> Cuis base. Or at least adopting it as a core package in our repo.
>>>>
>>>> Thoughts?
>>>>
>>>> Masashi-san: opinions?
>>>>
>>>> Thanks,
>>>> Juan Vuletich
>>>>
>>>>
>>>> On 5/17/2015 12:07 PM, H. Hirzel wrote:
>>>>> Below are the comments from the FileMan package.
>>>>>
>>>>> Question: How do you compare the FileMan package to the FileSystem
>>>>> package in Pharo?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L45
>>>>> I represent a single file entry (including directory).
>>>>> You can write data by #fileContents: , and read the data by
>>>>> #fileContents.
>>>>> ---
>>>>> mu 11/6/2006 20:21!
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L53
>>>>> I represent a single file directory.
>>>>> I implement various directory specific behaviors.
>>>>> You can write data by #at:put: , and read the data by #at:.
>>>>> ---
>>>>> mu 11/6/2006 20:21
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L63
>>>>> !FmFileIOAccessor commentStamp: '<historical>' prior: 0!
>>>>> I am an accessor to the low level file IO.
>>>>> You can extend/rewrite me if you port FileMan to other Smalltalk
>>>>> dialects.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L44
>>>>> !FmBackupDirectoryEntry commentStamp: 'mu 5/4/2007 23:26' prior: 0!
>>>>> This is a simple example for adding special behaviors to
>>>>> FmDirectoryEntry.
>>>>> I backup file contents automatically, while users are not conscious
>>>>> about
>>>>> that.
>>>>> Usage:
>>>>> dir := './withBackup' asDirectoryEntry: FmBackupDirectoryEntry.
>>>>> dir at: 'text' put: 'abc'.
>>>>> dir at: 'text' put: 'def'.
>>>>> (dir at: 'text') inspect. "def"
>>>>> (dir backupAt: 'text') inspect. "abc"
>>>>> ((dir / 'sub') at: 'text2' put: '123').
>>>>> ((dir / 'sub') at: 'text2' put: '456').
>>>>> ((dir / 'sub') at: 'text2') inspect. "456"
>>>>> ((dir / 'sub') backupAt: 'text2') inspect. "123"
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L63
>>>>> This is a simple example for adding special behaviors to
>>>>> FmDirectoryEntry.
>>>>> I put and get file contents as gzipped, while users are not conscious
>>>>> about that.
>>>>> Usage:
>>>>> | dir |
>>>>> dir := './gzipped2' asDirectoryEntry: FmGZipDirectoryEntry.
>>>>> dir binaryAt: 'bin' put: #(1 2 3 12 34 56) asByteArray.
>>>>> (dir binaryAt: 'bin') inspect.
>>>>> dir at: 'text' put: 'This will be gzipped'.
>>>>> (dir at: 'text') inspect.
>>>>> I would be useful for storing/loading big contents in a simple
>>>>> dictionary-like manner.
>>>>>
>>>>>
>>>>>
>>>>> On 5/17/15, H. Hirzel<hannes.hirzel at gmail.com>    wrote:
>>>>>> Hello Masashi-san
>>>>>>
>>>>>> I'd like to come back to your FileMan package
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>
>>>>>> and ask a question.
>>>>>>
>>>>>> Is this package a port from somewhere or did you write it from scratch?
>>>>>>
>>>>>> Some background information is appreciated.
>>>>>>
>>>>>> There is no description
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L2
>>>>>>
>>>>>> Thank you in advance
>>>>>>
>>>>>> Hannes Hirzel
>>>>>>
>>>>>>
>>>>>> On 5/2/14, Masashi UMEZAWA<ume at blueplane.jp>    wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Thank you for the kind words. I've just started Cuis on March, and I
>>>>>>> was impressed with its cleanness, simplicity, etc.
>>>>>>> So I did a introductory presentation at Tokyo Smalltalkers meeting. It
>>>>>>> was successful.
>>>>>>> Now I'm planning to port Folktale (telnet-base object shell), and SIXX
>>>>>>> to Cuis. My pace maybe slow, but please stay tuned. ;)
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> 2014-05-02 1:05 GMT+09:00 Germ?n Arduino<garduino at gmail.com>:
>>>>>>>> Wow, I was completely unaware of Masashi working in Cuis! Welcome
>>>>>>>> aboard!!
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-05-01 12:19 GMT-03:00 H. Hirzel<hannes.hirzel at gmail.com>:
>>>>>>>>
>>>>>>>>> Thank you for the link to  Masashi Umezawa's presentation.
>>>>>>>>>
>>>>>>>>> It is from 2014 and talks about
>>>>>>>>>
>>>>>>>>> - the number of classes compared to Squeak and Pharo
>>>>>>>>> - the size of Morphic -- Morph allSelectors size "=>    502"
>>>>>>>>> - something I do not fully get about instance variables
>>>>>>>>>         'bounds owner submorphs fullBounds color extension'
>>>>>>>>>         versus
>>>>>>>>>        'owner submorphs location layoutNeeded layoutSpec properties'
>>>>>>>>> - layoutSpec
>>>>>>>>> - PackageInfo
>>>>>>>>> - version control with git
>>>>>>>>> - Feature require: '<PackageName>'.
>>>>>>>>> - your Unicode package
>>>>>>>>> https://github.com/KenDickey/Cuis-Smalltalk-Unicode
>>>>>>>>> - https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-StyledTextEditor
>>>>>>>>> - How to query for other Cuis-Smalltalk repositories
>>>>>>>>>                 https://github.com/search?q=cuis-smalltalk
>>>>>>>>>
>>>>>>>>> All things which we will include Cuis documentation effort.
>>>>>>>>>
>>>>>>>>> --Hannes
>>>>>>>>>
>>>>>>>>> On 5/1/14, Ken Dickey<Ken.Dickey at whidbey.com>    wrote:
>>>>>>>>>> On Thu, 1 May 2014 07:28:54 +0000
>>>>>>>>>> "H. Hirzel"<hannes.hirzel at gmail.com>    wrote:
>>>>>>>>>>
>>>>>>>>>>> A noteworthy effort
>>>>>>>>>>>
>>>>>>>>>>>          https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>>>> Yes.  Masashi Umezawa is the man in Japan!
>>>>>>>>>>
>>>>>>>>>> He should introduce himself.
>>>>>>>>>>
>>>>>>>>>> He gave a talk about Cuis at the 63rd Smalltalkers' meeting in
>>>>>>>>>> Tokyo:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://www.smalltalk-users.jp/Home/gao-zhi/dai63kaismalltalkbenkyoukai/shiryou
>>>>>>>>>>
>>>>>>>>>> Masashi has ported several packages to CUis.
>>>>>>>>>>
>>>>>>>>>> Because of Unicode interest, I was made aware that recent font
>>>>>>>>>> tweaks
>>>>>>>>>> have
>>>>>>>>>> broken my Unicode package in the latest Cuis versions.
>>>>>>>>>>
>>>>>>>>>> Masashi-san, would you care to tell us about yourself and what
>>>>>>>>>> people
>>>>>>>>>> there
>>>>>>>>>> think about Cuis?
>>>>>>>>>>
>>>>>>>>>> -KenD
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> Cuis at jvuletich.org
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>
>>>
>
>




From hannes.hirzel at gmail.com  Mon Jul 27 13:31:24 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Mon, 27 Jul 2015 18:31:24 +0000
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <55B64713.8040806@jvuletich.org>
References: <CAGQxfVhtR6zezHW4Nji0kHU3str2Zf4Dbfdn5VjphgAqwnuz-g@mail.gmail.com>
	<20140501080531.493624077a7c3f67688650f9@whidbey.com>
	<CAGQxfVgeyXkyu5Rqdn2T9T+iY5rYzEVy9w76N0=scZCR+-iy3w@mail.gmail.com>
	<CAEt3aLxfNLqDJ3LhBZFdwSO5VjcPDmQcStXWiTEts8YBsWLvxw@mail.gmail.com>
	<CA+=t-6DwrOQwVB3QeTWaL=rGG7=g5J-poDh5UR9tpMXFtnsPbg@mail.gmail.com>
	<CAGQxfVg4wzvPRBg-XRP3dFWw_EbV=in7ZCiK-TzYJzV+MP9y0A@mail.gmail.com>
	<CAGQxfVjyHyA1R1aEuaNcpiyFqOG+zSy8SzqqqeD7drG8kSzZPQ@mail.gmail.com>
	<555A8705.5080502@jvuletich.org>
	<CA+=t-6C7Bh+2YRfNwEdfUJDcn=cx=NNXTc-DuWfyJ5ZbbKYeHQ@mail.gmail.com>
	<5573BD8C.4010008@jvuletich.org>
	<CA+=t-6BMwgF9pffS7TWaPKTi8EkE2X-puM=e0NQNBn1gW5Z4Pw@mail.gmail.com>
	<55B64713.8040806@jvuletich.org>
Message-ID: <CAGQxfVijywhcd0rCTnqz53oD0xcKnFjt8rcQ27VWuwZqqDqdYA@mail.gmail.com>

I as well opened an issue for Cuis to get mentioned.

https://github.com/mumez/FileMan/issues/1

--Hannes

On 7/27/15, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Masashi,
>
> Recently we found that in FileMan, if we do
>
> 'inexistentFile' asFileEntry readStream
>
> we get an empty readStream.
>
> I think it is better to throw the #fileDoesNotExistException , as
> FileDirectory did, and let the user handle the exception appropriately.
> But I would not want to break compatibility with FileMan, as the main
> purpose of FileMan is to give compatibility amongst dialects.
>
> Are there good reasons to avoid the exception? Should we add another
> method, besides #readStream when we want a readStream strictly on
> existing file contents?
>
> Thanks,
> Juan Vuletich
>
>
> On 6/14/2015 8:38 AM, Masashi UMEZAWA wrote:
>> Hello Juan,
>>
>> Thank you for the patches and more tests! I'll adapt those updates for
>> other FileMan ports.
>>
>> Best regards,
>>
>> 2015-06-07 12:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>>> Hi Masashi,
>>>
>>> I was trying FileMan tests today and I saw they create some folders in
>>> my
>>> drive. The names looked a bit strange, so I took a closer look and found
>>> a
>>> couple of bugs. At least on Windows, #testRecursiveDelete instead of
>>> creating
>>>        subDir/aaa/bbb/ccc/ddd/eee/fff/ggg/test1
>>> it created
>>>         subDir/bbb/ccc/eee/ggg/test!
>>>
>>> So I wrote a few more tests on the issues I saw, and teaked the code to
>>> make
>>> them pass. The result is attached, and I think is useful for all ports
>>> of
>>> FileMan.
>>>
>>> Thanks,
>>> Juan Vuletich
>>>
>>> On 5/26/2015 11:34 PM, Masashi UMEZAWA wrote:
>>>> Hi all,
>>>>
>>>> I think it is nice if FileMan is on the core package repository.
>>>>
>>>> FileMan for Cuis (and Squeak) has minimum dependencies to the existing
>>>> FileDirectory and DirectoryEntry. FileMan selectively uses a few
>>>> methods of them.
>>>>
>>>> So we can gradually adopt FileMan interfaces and trim the
>>>> FileDirectory and DirectoryEntry's non-intuitive methods.
>>>>
>>>> Another way of cleaning-up the file-related classes is to port
>>>> FileSystems to Cuis.
>>>> But since Cuis is a lightweight Smalltalk dialect, FileSystems might
>>>> be an overkill.
>>>>
>>>> Best regards,
>>>>
>>>> 2015-05-19 9:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>>>>> Hi Folks,
>>>>>
>>>>> I apologize for talking before taking even a quick look, but anyway,
>>>>> We'd
>>>>> take a good look at this. And seriously consider replacing files stuff
>>>>> in
>>>>> Cuis base. Or at least adopting it as a core package in our repo.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Masashi-san: opinions?
>>>>>
>>>>> Thanks,
>>>>> Juan Vuletich
>>>>>
>>>>>
>>>>> On 5/17/2015 12:07 PM, H. Hirzel wrote:
>>>>>> Below are the comments from the FileMan package.
>>>>>>
>>>>>> Question: How do you compare the FileMan package to the FileSystem
>>>>>> package in Pharo?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L45
>>>>>> I represent a single file entry (including directory).
>>>>>> You can write data by #fileContents: , and read the data by
>>>>>> #fileContents.
>>>>>> ---
>>>>>> mu 11/6/2006 20:21!
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L53
>>>>>> I represent a single file directory.
>>>>>> I implement various directory specific behaviors.
>>>>>> You can write data by #at:put: , and read the data by #at:.
>>>>>> ---
>>>>>> mu 11/6/2006 20:21
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Core.pck.st#L63
>>>>>> !FmFileIOAccessor commentStamp: '<historical>' prior: 0!
>>>>>> I am an accessor to the low level file IO.
>>>>>> You can extend/rewrite me if you port FileMan to other Smalltalk
>>>>>> dialects.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L44
>>>>>> !FmBackupDirectoryEntry commentStamp: 'mu 5/4/2007 23:26' prior: 0!
>>>>>> This is a simple example for adding special behaviors to
>>>>>> FmDirectoryEntry.
>>>>>> I backup file contents automatically, while users are not conscious
>>>>>> about
>>>>>> that.
>>>>>> Usage:
>>>>>> dir := './withBackup' asDirectoryEntry: FmBackupDirectoryEntry.
>>>>>> dir at: 'text' put: 'abc'.
>>>>>> dir at: 'text' put: 'def'.
>>>>>> (dir at: 'text') inspect. "def"
>>>>>> (dir backupAt: 'text') inspect. "abc"
>>>>>> ((dir / 'sub') at: 'text2' put: '123').
>>>>>> ((dir / 'sub') at: 'text2' put: '456').
>>>>>> ((dir / 'sub') at: 'text2') inspect. "456"
>>>>>> ((dir / 'sub') backupAt: 'text2') inspect. "123"
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L63
>>>>>> This is a simple example for adding special behaviors to
>>>>>> FmDirectoryEntry.
>>>>>> I put and get file contents as gzipped, while users are not conscious
>>>>>> about that.
>>>>>> Usage:
>>>>>> | dir |
>>>>>> dir := './gzipped2' asDirectoryEntry: FmGZipDirectoryEntry.
>>>>>> dir binaryAt: 'bin' put: #(1 2 3 12 34 56) asByteArray.
>>>>>> (dir binaryAt: 'bin') inspect.
>>>>>> dir at: 'text' put: 'This will be gzipped'.
>>>>>> (dir at: 'text') inspect.
>>>>>> I would be useful for storing/loading big contents in a simple
>>>>>> dictionary-like manner.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/17/15, H. Hirzel<hannes.hirzel at gmail.com>    wrote:
>>>>>>> Hello Masashi-san
>>>>>>>
>>>>>>> I'd like to come back to your FileMan package
>>>>>>>
>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>
>>>>>>> and ask a question.
>>>>>>>
>>>>>>> Is this package a port from somewhere or did you write it from
>>>>>>> scratch?
>>>>>>>
>>>>>>> Some background information is appreciated.
>>>>>>>
>>>>>>> There is no description
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/mumez/Cuis-Smalltalk-FileMan/blob/master/FileMan-Example.pck.st#L2
>>>>>>>
>>>>>>> Thank you in advance
>>>>>>>
>>>>>>> Hannes Hirzel
>>>>>>>
>>>>>>>
>>>>>>> On 5/2/14, Masashi UMEZAWA<ume at blueplane.jp>    wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Thank you for the kind words. I've just started Cuis on March, and
>>>>>>>> I
>>>>>>>> was impressed with its cleanness, simplicity, etc.
>>>>>>>> So I did a introductory presentation at Tokyo Smalltalkers meeting.
>>>>>>>> It
>>>>>>>> was successful.
>>>>>>>> Now I'm planning to port Folktale (telnet-base object shell), and
>>>>>>>> SIXX
>>>>>>>> to Cuis. My pace maybe slow, but please stay tuned. ;)
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> 2014-05-02 1:05 GMT+09:00 Germ?n Arduino<garduino at gmail.com>:
>>>>>>>>> Wow, I was completely unaware of Masashi working in Cuis! Welcome
>>>>>>>>> aboard!!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2014-05-01 12:19 GMT-03:00 H. Hirzel<hannes.hirzel at gmail.com>:
>>>>>>>>>
>>>>>>>>>> Thank you for the link to  Masashi Umezawa's presentation.
>>>>>>>>>>
>>>>>>>>>> It is from 2014 and talks about
>>>>>>>>>>
>>>>>>>>>> - the number of classes compared to Squeak and Pharo
>>>>>>>>>> - the size of Morphic -- Morph allSelectors size "=>    502"
>>>>>>>>>> - something I do not fully get about instance variables
>>>>>>>>>>         'bounds owner submorphs fullBounds color extension'
>>>>>>>>>>         versus
>>>>>>>>>>        'owner submorphs location layoutNeeded layoutSpec
>>>>>>>>>> properties'
>>>>>>>>>> - layoutSpec
>>>>>>>>>> - PackageInfo
>>>>>>>>>> - version control with git
>>>>>>>>>> - Feature require: '<PackageName>'.
>>>>>>>>>> - your Unicode package
>>>>>>>>>> https://github.com/KenDickey/Cuis-Smalltalk-Unicode
>>>>>>>>>> -
>>>>>>>>>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-StyledTextEditor
>>>>>>>>>> - How to query for other Cuis-Smalltalk repositories
>>>>>>>>>>                 https://github.com/search?q=cuis-smalltalk
>>>>>>>>>>
>>>>>>>>>> All things which we will include Cuis documentation effort.
>>>>>>>>>>
>>>>>>>>>> --Hannes
>>>>>>>>>>
>>>>>>>>>> On 5/1/14, Ken Dickey<Ken.Dickey at whidbey.com>    wrote:
>>>>>>>>>>> On Thu, 1 May 2014 07:28:54 +0000
>>>>>>>>>>> "H. Hirzel"<hannes.hirzel at gmail.com>    wrote:
>>>>>>>>>>>
>>>>>>>>>>>> A noteworthy effort
>>>>>>>>>>>>
>>>>>>>>>>>>          https://github.com/mumez/Cuis-Smalltalk-FileMan
>>>>>>>>>>> Yes.  Masashi Umezawa is the man in Japan!
>>>>>>>>>>>
>>>>>>>>>>> He should introduce himself.
>>>>>>>>>>>
>>>>>>>>>>> He gave a talk about Cuis at the 63rd Smalltalkers' meeting in
>>>>>>>>>>> Tokyo:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://www.smalltalk-users.jp/Home/gao-zhi/dai63kaismalltalkbenkyoukai/shiryou
>>>>>>>>>>>
>>>>>>>>>>> Masashi has ported several packages to CUis.
>>>>>>>>>>>
>>>>>>>>>>> Because of Unicode interest, I was made aware that recent font
>>>>>>>>>>> tweaks
>>>>>>>>>>> have
>>>>>>>>>>> broken my Unicode package in the latest Cuis versions.
>>>>>>>>>>>
>>>>>>>>>>> Masashi-san, would you care to tell us about yourself and what
>>>>>>>>>>> people
>>>>>>>>>>> there
>>>>>>>>>>> think about Cuis?
>>>>>>>>>>>
>>>>>>>>>>> -KenD
>>>>>> _______________________________________________
>>>>>> Cuis mailing list
>>>>>> Cuis at jvuletich.org
>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>
>>>>
>>
>>
>
>



From juan at jvuletich.org  Tue Jul 28 07:28:45 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 28 Jul 2015 09:28:45 -0300
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
Message-ID: <55B7757D.80006@jvuletich.org>

Hi Folks,

I just did a commit to the repo. It includes the updated ReferenceFinder 
and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).

Open an inspector on a window (using the halo). In the bottom pane 
evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer 
openExplorerOn: self'. Check the object trees to see what you have 
there. Read ClosureScanner class comment. You'll agree with me that this 
is truly great!

Also, several contributions by Ken (thanks Ken!), and a few fixes to 
Display updating, font creation, etc. by yours truly.

I also included an xml file with the test results.

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Tue Jul 28 16:41:42 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 28 Jul 2015 17:41:42 -0400
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <55B7757D.80006@jvuletich.org>
References: <55B7757D.80006@jvuletich.org>
Message-ID: <1438119702.2292.5.camel@gmail.com>

On Tue, 2015-07-28 at 09:28 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> I just did a commit to the repo. It includes the updated ReferenceFinder 
> and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).
> 
> Open an inspector on a window (using the halo). In the bottom pane 
> evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer 
> openExplorerOn: self'. Check the object trees to see what you have 
> there. Read ClosureScanner class comment. You'll agree with me that this 
> is truly great!
> 

Very cool stuff indeed!  Are there any notable changes between the old
and new ReferenceFinder or is it mostly just internals stuff?  Also,
should WeightTracer be added to the context menu (right click) of
Explorer and Inspector windows?

> Also, several contributions by Ken (thanks Ken!), and a few fixes to 
> Display updating, font creation, etc. by yours truly.
> 
> I also included an xml file with the test results.
> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Tue Jul 28 17:00:02 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 28 Jul 2015 18:00:02 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>

When the glyphs for the Cuis default font (DejaVu) or those for DejaVu Sans are filed out and 
then examined using Paint, it is obvious that they are of much higher quality than those 
produced by ImageMagick. The height is exactly right, as can be seen at ascii 129, 132, and 
133. They are the right size and crisp when displayed. This is the quality we should have for a 
fixed-width font. How were these .bmp files produced?

On 25 Jul 2015 at 21:41, Dan Norton wrote:

> Attached is a StrikeFont of Courier New 12. It's hacked - not
> polished by any means. It was 
> made by:
> 
> Making "characters.txt" by printing in a Cuis workspace, copying to
> Notepad, and saving with 
> encoding: ANSI.
> 
> This was input to ImageMagick to make a .png file.
> 
> The .png file was opened in Paint, then saved as a .bmp file.
> 
> The body of the .txt file was generated by:
> (32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 -
> needed to avoid index out of range"
> 
> The first three numbers in .txt were finagled to 12 15 5 (the last
> two anyway).
> 
> The font was installed by running:
> StrikeFont installCourier.  "code in Courier.pck.st "
> 
> Text in the Text Editor pane was highlighted and the font changed to
> Courier 12 point. It 
> looked much too small. Going back to Paint, the glyphs were selected
> and stretched 
> vertically. The font was re-installed. The vertical distortion is
> probably obvious.
> 
> At least it's recognizable as Courier and it's fixed width. Files
> are attached.
> 
>  - Dan
> 
> Attachments:
>   C:\Cuis\CourierExample2.zip





From hannes.hirzel at gmail.com  Wed Jul 29 03:44:36 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Wed, 29 Jul 2015 08:44:36 +0000
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
Message-ID: <CAGQxfVjs7DceHza3oyWAPRbJ7YDjoVR=HswXosR9yyJX4auM4w@mail.gmail.com>

Juan produced the fonts. There is some discussion about it in the
mailing list archive.

--HH

On 7/28/15, Dan Norton <dnorton at mindspring.com> wrote:
> When the glyphs for the Cuis default font (DejaVu) or those for DejaVu Sans
> are filed out and
> then examined using Paint, it is obvious that they are of much higher
> quality than those
> produced by ImageMagick. The height is exactly right, as can be seen at
> ascii 129, 132, and
> 133. They are the right size and crisp when displayed. This is the quality
> we should have for a
> fixed-width font. How were these .bmp files produced?
>
> On 25 Jul 2015 at 21:41, Dan Norton wrote:
>
>> Attached is a StrikeFont of Courier New 12. It's hacked - not
>> polished by any means. It was
>> made by:
>>
>> Making "characters.txt" by printing in a Cuis workspace, copying to
>> Notepad, and saving with
>> encoding: ANSI.
>>
>> This was input to ImageMagick to make a .png file.
>>
>> The .png file was opened in Paint, then saved as a .bmp file.
>>
>> The body of the .txt file was generated by:
>> (32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 -
>> needed to avoid index out of range"
>>
>> The first three numbers in .txt were finagled to 12 15 5 (the last
>> two anyway).
>>
>> The font was installed by running:
>> StrikeFont installCourier.  "code in Courier.pck.st "
>>
>> Text in the Text Editor pane was highlighted and the font changed to
>> Courier 12 point. It
>> looked much too small. Going back to Paint, the glyphs were selected
>> and stretched
>> vertically. The font was re-installed. The vertical distortion is
>> probably obvious.
>>
>> At least it's recognizable as Courier and it's fixed width. Files
>> are attached.
>>
>>  - Dan
>>
>> Attachments:
>>   C:\Cuis\CourierExample2.zip
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



From juan at jvuletich.org  Wed Jul 29 09:49:14 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 29 Jul 2015 11:49:14 -0300
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <1438119702.2292.5.camel@gmail.com>
References: <55B7757D.80006@jvuletich.org> <1438119702.2292.5.camel@gmail.com>
Message-ID: <55B8E7EA.7060301@jvuletich.org>

On 7/28/2015 6:41 PM, Phil (list) wrote:
> On Tue, 2015-07-28 at 09:28 -0300, Juan Vuletich wrote:
>> Hi Folks,
>>
>> I just did a commit to the repo. It includes the updated ReferenceFinder
>> and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).
>>
>> Open an inspector on a window (using the halo). In the bottom pane
>> evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer
>> openExplorerOn: self'. Check the object trees to see what you have
>> there. Read ClosureScanner class comment. You'll agree with me that this
>> is truly great!
>>
> Very cool stuff indeed!  Are there any notable changes between the old
> and new ReferenceFinder or is it mostly just internals stuff?

I believe it is refactoring to make room for the new WeightTracer.

> Also,
> should WeightTracer be added to the context menu (right click) of
> Explorer and Inspector windows?

Yes! Care to send a cs?

Cheers,
Juan Vuletich



From juan at jvuletich.org  Wed Jul 29 09:54:52 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 29 Jul 2015 11:54:52 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
Message-ID: <55B8E93C.7080009@jvuletich.org>

Hi Dan,

I looked for it in old stuff I haven't touched in several years, and 
found it. Glyph rendering is done by FreeType. 
https://www.dropbox.com/sh/9d5xi3x2lvtrtum/AABy17XMTRmciA44ysM-vuxza?dl=0

This original ran on the Mac I had by then, but with the VM I added, it 
seems to work ok on Windows. Anyway, there are no guarantees. I didn't 
try to import the files generated, and for sure you'd need to add glyphs 
for 128, 129, 130 and 131, to follow the Cuis convention.

BTW, I suggest using free fonts, that you can share without concern. 
DejaVu Sans is a good option. Inconsolata is just great. There are 
several more free code-oriented monospaced fonts out there.

Cheers,
Juan Vuletich

On 7/28/2015 7:00 PM, Dan Norton wrote:
> When the glyphs for the Cuis default font (DejaVu) or those for DejaVu Sans are filed out and
> then examined using Paint, it is obvious that they are of much higher quality than those
> produced by ImageMagick. The height is exactly right, as can be seen at ascii 129, 132, and
> 133. They are the right size and crisp when displayed. This is the quality we should have for a
> fixed-width font. How were these .bmp files produced?
>
> On 25 Jul 2015 at 21:41, Dan Norton wrote:
>
>> Attached is a StrikeFont of Courier New 12. It's hacked - not
>> polished by any means. It was
>> made by:
>>
>> Making "characters.txt" by printing in a Cuis workspace, copying to
>> Notepad, and saving with
>> encoding: ANSI.
>>
>> This was input to ImageMagick to make a .png file.
>>
>> The .png file was opened in Paint, then saved as a .bmp file.
>>
>> The body of the .txt file was generated by:
>> (32 to: 257) collect: [ :ascii | ascii-32 * 7 ]  "note the 257 -
>> needed to avoid index out of range"
>>
>> The first three numbers in .txt were finagled to 12 15 5 (the last
>> two anyway).
>>
>> The font was installed by running:
>> StrikeFont installCourier.  "code in Courier.pck.st "
>>
>> Text in the Text Editor pane was highlighted and the font changed to
>> Courier 12 point. It
>> looked much too small. Going back to Paint, the glyphs were selected
>> and stretched
>> vertically. The font was re-installed. The vertical distortion is
>> probably obvious.
>>
>> At least it's recognizable as Courier and it's fixed width. Files
>> are attached.
>>
>>   - Dan
>>
>> Attachments:
>>    C:\Cuis\CourierExample2.zip
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




From pbpublist at gmail.com  Wed Jul 29 12:11:37 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 29 Jul 2015 13:11:37 -0400
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <55B8E7EA.7060301@jvuletich.org>
References: <55B7757D.80006@jvuletich.org>
	<1438119702.2292.5.camel@gmail.com> <55B8E7EA.7060301@jvuletich.org>
Message-ID: <1438189897.2292.6.camel@gmail.com>

On Wed, 2015-07-29 at 11:49 -0300, Juan Vuletich wrote:
> On 7/28/2015 6:41 PM, Phil (list) wrote:
> > On Tue, 2015-07-28 at 09:28 -0300, Juan Vuletich wrote:
> >> Hi Folks,
> >>
> >> I just did a commit to the repo. It includes the updated ReferenceFinder
> >> and brand new WeightTracer by Andres Valloud and Jan Vrany (thanks folks!).
> >>
> >> Open an inspector on a window (using the halo). In the bottom pane
> >> evaluate 'ReferenceFinder openExplorerOn: self' and 'WeightTracer
> >> openExplorerOn: self'. Check the object trees to see what you have
> >> there. Read ClosureScanner class comment. You'll agree with me that this
> >> is truly great!
> >>
> > Very cool stuff indeed!  Are there any notable changes between the old
> > and new ReferenceFinder or is it mostly just internals stuff?
> 
> I believe it is refactoring to make room for the new WeightTracer.
> 
> > Also,
> > should WeightTracer be added to the context menu (right click) of
> > Explorer and Inspector windows?
> 
> Yes! Care to send a cs?
> 

Done... pull request submitted

> Cheers,
> Juan Vuletich





From hannes.hirzel at gmail.com  Fri Jul 31 01:29:54 2015
From: hannes.hirzel at gmail.com (H. Hirzel)
Date: Fri, 31 Jul 2015 06:29:54 +0000
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <1437592756.2326.32.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<20150719131838.7d00ce57192818d00c38262c@whidbey.com>
	<1437352771.6934.219.camel@gmail.com>
	<20150720065545.f8a69424c7d9ed726e5aef7a@whidbey.com>
	<CAJBxtBb7p_obaEB01EB8a985Hr2f1tyOGbJVWZ=twbOkoC0f_A@mail.gmail.com>
	<20150721153300.f5cd3fa6e683b32d68b09a17@whidbey.com>
	<CAJBxtBYcYAqqbm2mQrTXXEkHb22RuhJQWLtD2Znyn5QTe7mvbw@mail.gmail.com>
	<CAJBxtBaKNggurKapMDa6Ls_=tuN6LnGC5Af=LPbfPBwFemCWoQ@mail.gmail.com>
	<1437592756.2326.32.camel@gmail.com>
Message-ID: <CAGQxfVhZfsbRw=Fiq0fy5_5MHU5bqEEnM2S1F5akOKUMmxXUJg@mail.gmail.com>

Could we do examples of such Feature Tests?

Class String is a good candidate to start with

Reasons
a) Is  used everywhere
b) Interface is non-trivial
        String selectors size 166   (in Cuis)
                                      338   (in Pharo)
                                      331   (in Squeak)
        --> there are issues when porting.

We might want to have a StringExtensions package

--Hannes

On 7/22/15, Phil (list) <pbpublist at gmail.com> wrote:
> On Wed, 2015-07-22 at 13:29 +0200, Peter van Rooijen wrote:
>> I'm thinking about some features (pun not intentional) of this Feature
>> Test framework:
>>
>>
>> 1. It's reasonable to assume that many tests will depend on something
>> else working, but that cannot be counted on, and
>> we would not want to repeat testing for that and also would not run
>> into it failing all the time and that filling our feedback.
>>
>
> Why not?  I agree that these would be a different category of test in
> that the dependencies would be more complex and often dependent on more
> than one package, but why would their functioning be considered
> optional?  If they fail, shouldn't they either be addressed right away
> or explicitly deprecated?  If you make the tests easy to ignore/forget
> about, they will be.  If the functionality they are testing can't be
> counted on, it won't be used.
>
> If your thinking is that these would be tests that are part of package X
> but might rely on package Y which might not be loaded yet, why not
> instead just make the tests part of package Z which depends on package X
> and Y?  The whole idea is that these are not unit tests in that sense...
> have them live where ever it is appropriate.
>
>>
>> 1a. So it would make sense to add a #precondition method to each
>> Feature Test class.
>>
>>
>> FeatureAnsiArray
>>     class
>>         precondition
>>
>>
>>         self run: 'Array' "i.e. the global Array must be present"
>>
>>
>> then only if the precondition for the class is satisfied, will the
>> test methods be executed. so if most of them start with
>>
>>
>> 'Array new ?' then they would all fail anyway so we don't need to test
>> them.
>>
>>
>> 2. You would want to be able to assure that in a particular object you
>> would be able to access a particular variable.
>>
>>
>> so in the test method you would write:
>>
>>
>> FeatureTest1
>>     class
>>         test1
>>
>>         self setContext: OrderdCollection new
>>
>>
>>         self run: 'elements' "determine if the inst var elements is
>> present in a new OrderedCollection"
>>
>>
>>         self run: 'elements == nil' expect: false
>>
>>
>>         self run: 'elements isOrderedCollection' expect: true
>>
>>
>> let's say the test runner would continue testing even if something
>> failed, e.g. the array is called array, not elements. then we already
>> know that the following expressions will fail
>>
>>
>> so we might instead write:
>>
>>
>>         self run: 'elements' ifFail: [^self]
>>
>>
>>
>>  3. Instead of implicitly testing for a global using run:
>> 'NameOfTheGlobal' or for a class var using setContext: and then
>> run'NameOfTheClassVar' there could be convenience methods for
>>
>>
>>         self expectGlobal: 'NameOfTheGlobal' "argument may be given as
>> a Symbol as well"
>>
>>
>>         self expectClass: 'NameOfTheClass' "additionally verified that
>> the global holds a class"
>>
>>
>>         self expectSharedVariable: 'Foo' inClass: 'Bar'
>>
>>
>> this would make for nicer feedback since the expectation is made
>> clearer
>
> I went the other way when I did the ApiFile tests in that it didn't seem
> terribly important to use most of the testing framework capabilities
> (other than the overall pass/fail aspect to keep the initial PoC as
> simple as possible)  So they are simply small snippets of code that
> performed the desired task but didn't care where it failed (if it
> failed):  the failure to successfully complete the task would be the
> indicator that there was a problem and we would know that either
> something being depended on had broken and needed to be fixed or that
> the test needed to be updated/overhauled to represent the new way of
> accomplishing the task.
>
> My thinking was that as we started to build up a number of these, we
> might start to see common breakage patterns and then we could decide
> whether or not to handle that them more explicitly (whether using the
> existing test framework capabilities, creating a new one, etc.)  Trying
> to engineer it up front didn't seem like a great idea not knowing what
> common failure states would look like yet.
>
>>
>>
>> Okay just 2 more cents!
>>
>
> Mine as well.  This is a worthwhile discussion/exercise IMO as we need
> to get to a common understanding of what we are doing here.
>
>>
>> Cheers, Peter
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen
>> <peter at aba-instituut.nl> wrote:
>>         Hi Ken,
>>
>>         On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey
>>         <Ken.Dickey at whidbey.com> wrote:
>>                 On Tue, 21 Jul 2015 07:59:47 -0700
>>                 Peter van Rooijen <peter at aba-instituut.nl> wrote:
>>
>>                 >> I was thinking: "What should a Feature Test be?".
>>
>>                 I tend to think of a hierarchy of requirements.
>>                 Perhaps something like:
>>
>>                  Feature requireAll: #( <feature name>.. ).
>>                  Classes requireAll: #( <class name>.. ).
>>                  Methods requireAll: #( <selector name>.. ).
>>                  MethodsForKind class: <class name> requireAll:
>>                 #( <selectorName>.. ).
>>                  Tests requireAllPass: #( <unit test name> ).
>>
>>
>>         Yeah, that's not at all what I'm thinking :). I'm thinking of
>>         something that is automatically runnable, like a unit test. It
>>         tests something, like a un test. But if the test does not
>>         pass, it is NOT a bug, unlike with a unit test. It's just that
>>         we would like to know about it. Also, with nit tests there is
>>         the assumption that the code that represents the test is
>>         always compilable, with feature tests that cannot be assumed,
>>         so there would need to be protection against that. Of course
>>         we want to be able to load the feature tests in any condition,
>>         so putting it in the form of source text and compiling that is
>>         a possibility. The fact that that makes it slower than unit
>>         tests is not a problem, because unlike unit tests, we don't
>>         have to run them continuously.
>>
>>                 The Feature class lets us require named (macro)
>>                 Features with a version check.  I prefer that
>>                 requirements at this level actually load the packages
>>                 required and only report failure if that is not
>>                 possible, although we could have a "preflight" verson
>>                 which just checks without loading any featured
>>                 packages.
>>
>>
>>         I see. The thing I was thinking about merely reports about the
>>         state of a system (of code), it does not try to configure that
>>         in any way.
>>
>>
>>                 API's are basically "protocols", which in the absence
>>                 of symbolic execution means checking that classes and
>>                 specific method selectors exist, or more specifically,
>>                 method selectors are applicable to specific KindOf:
>>                 classes.
>>
>>
>>         Well, in my mind some semantics could be expected (and tested
>>         for). For instance I might be interested if there is a
>>         DateTime class in the image and if it implements the ANSI
>>         DateAndTime protocol (not sure if there is one named that). Or
>>         perhaps another class that does that. These tests can test
>>         some actual semantics no problem.
>>
>>
>>         Perhaps some of you remember that Camp Smalltalk started with
>>         Ralph Johnson's desire to build an ANSI test suite. The way
>>         people went about it (extension methods to SUnit? I don't
>>         really remember) was wrong and could not possibly work (in my
>>         opinion anyway), but I could not convince a lot of people and
>>         such a test suite was never written. But with Feature Tests I
>>         think we could come a long way.
>>
>>                 Further, some Unit Tests may be required to pass to
>>                 ensure compliance with some specification.
>>
>>
>>         Well, except that the tests would not be unit tests in the
>>         strictest sense. But semantics, not merely interface, can be
>>         tested for sure.
>>
>>                 We should be able to automate at least some of this
>>
>>
>>         Automate the running of the feature tests? Of course.
>>
>>                 including a first pass of generating the test sets,
>>                 which could then be pruned by hand as required.
>>
>>
>>         That I don't see happening. You test what YOU think is
>>         important to be sure of. No machine can decide/calculate that
>>         for you. Perhaps I'm misunderstanding you.
>>
>>
>>         Cheers, Peter
>>
>>
>>                 $0.02,
>>                 -KenD
>>
>>
>>
>>         _______________________________________________
>>         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
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>