From peter at aba-instituut.nl  Sat Aug  1 06:57:13 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Sat, 1 Aug 2015 13:57:13 +0200
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <CAGQxfVhZfsbRw=Fiq0fy5_5MHU5bqEEnM2S1F5akOKUMmxXUJg@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>
	<1437592756.2326.32.camel@gmail.com>
	<CAGQxfVhZfsbRw=Fiq0fy5_5MHU5bqEEnM2S1F5akOKUMmxXUJg@mail.gmail.com>
Message-ID: <CAJBxtBZgJ-ku-6KBu=axEKL=hOX8sTiF7KDAB0heTquLzEMiAg@mail.gmail.com>

Hi Hannes,

You asked for an example of a Feature Test. I assume, but may be wrong,
that you want this to understand better what the intention of such a test
is. Of course I can only answer form my own imagination.

1 It should be something that provides a definite answer to a question
about the image/system, but where there is not necessarily a good or bad
outcome (as there is with a unit test; pass=good, fail or error=bad). So
for instance it could test if there is any class loaded that implements
AnsiDateAndTime protocol (or at least part of it and how much). Or it could
test if the number of classes is less than the number of instance
variables. Or it could test how many classes have a class comment. It could
test how many literals may be in a method. Still, it seems logical to want
to define Features in such a way that the presence of the feature is a good
situation (better or no worse than the absence).

2 An essential feature of a Feature Test is that it should be able to load
and run in in any image. Its no use of course if you want to figure
something out and you can't load and run the test that determines what you
want to know. So The Feature test must be able to compile and run source
code (it could conceivably interpret syntax trees but that seems rather
contrived given that the compiler is normally available in any image). And
while doing that it should be able to suppress any problems.

3 There should be some way to (build Feature Test Suites suites and/or) run
all the loaded Feature tests together, silently, and receive feedback only
at the end. Most simply in the form of a document/text that shows how it
went. Optionally using some kind of GUI, viz. SUnitBrowser. The default
FeatureTestSuite could simply run all loaded Feature Tests, and you could
subclass it if you wanted to define specific Suites.

I think it would be great to have a FeatureTest class that you could
subclass to run tests on how much of the Ansi standard is implemented in
the image and how accurately it follows the semantics prescribed. The
original Camp Smalltalk attempts at such a test suite were based on SUnit
as the test framework, but that didn't work as it is essentially unsuited
to loading tests about code that may not be laoded.

Cheers, Peter



On Fri, Jul 31, 2015 at 8:29 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> 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
> >
>
> _______________________________________________
> 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/20150801/63b2b971/attachment-0002.html>

From squeaklists at fang.demon.co.uk  Sun Aug  2 02:04:13 2015
From: squeaklists at fang.demon.co.uk (Douglas Brebner)
Date: Sun, 02 Aug 2015 08:04:13 +0100
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: <55BDC0ED.3060401@fang.demon.co.uk>

On 19/07/2015 22:38, Phil (list) wrote:
> 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 vaguely recall that many years ago there was a project called 
SmallInterfaces that let you define public interfaces to objects. (Or 
something like that). Would that be a good way to document the 
public/private api using code?

(sorry for being so vague but I've been awake for 24+ hours now)



From dnorton at mindspring.com  Sun Aug  2 20:24:40 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 02 Aug 2015 21:24:40 -0400
Subject: [Cuis] VM Crash
Message-ID: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>

Load Cuis4.2-2439.image. Open File List and go to Packages.
Select Graphics-Files-Additional.pck.st and click on "Install Package".

Get "Fatal VM Error". The zipped crash.dmp is attached.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150802/6f3e6f01/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash.zip
Type: application/zip
Size: 3832 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150802/6f3e6f01/attachment-0002.zip>

From dnorton at mindspring.com  Mon Aug  3 11:54:24 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 03 Aug 2015 12:54:24 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B8E93C.7080009@jvuletich.org>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55B8E93C.7080009@jvuletich.org>
Message-ID: <55BF9CC0.20600.59E8552@dnorton.mindspring.com>

On 29 Jul 2015 at 11:54, Juan Vuletich wrote:

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

I'm trying to get FreeType built and also I did a clone of:

https://github.com/rougier/freetype-gl

Unfortunately when I compile embedded-font.c the following occurs:

fatal error C1083: Cannot open include file: 'vera-16.h': No such file or directory

Do any of you Cexperts know where I can get 'vera-16.h'? Google search produces ads for 
soaps containing aloe vera :-)

 - Dan



From juan at jvuletich.org  Mon Aug  3 13:38:10 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:38:10 -0300
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <1438189897.2292.6.camel@gmail.com>
References: <55B7757D.80006@jvuletich.org>	 <1438119702.2292.5.camel@gmail.com>
	<55B8E7EA.7060301@jvuletich.org>
	<1438189897.2292.6.camel@gmail.com>
Message-ID: <55BFB512.3060109@jvuletich.org>

On 7/29/2015 2:11 PM, Phil (list) wrote:
> 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

And accepted. Thank you!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug  3 13:49:55 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:49:55 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55BDC0ED.3060401@fang.demon.co.uk>
References: <55A905A3.1060100@jvuletich.org>	<1437158701.2255.245.camel@gmail.com>	<55ABB223.8010309@jvuletich.org>	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
Message-ID: <55BFB7D3.4030701@jvuletich.org>

Hi Doug,

On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> On 19/07/2015 22:38, Phil (list) wrote:
>> 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 vaguely recall that many years ago there was a project called 
> SmallInterfaces that let you define public interfaces to objects. (Or 
> something like that). Would that be a good way to document the 
> public/private api using code?
>
> (sorry for being so vague but I've been awake for 24+ hours now)

Thanks for the pointer. I took a look at it. It is quite like Java 
interfaces. The tools are interesting. But I see several downsides:

- Each interface is a class. Each method in the protocol is an actual 
method. If we use this to document all public protocols in Cuis, it 
would mean a lot of new classes and methods.
- The source code of (for example) OrderedCollection>>at: would not 
include the information of it belonging to interface "Indexable". 
Without additional support from tools users can't tell whether a message 
is public protocol or not. And the base image / package maintainer can't 
easily see he's about to change a public api.

I think a method pragma, that includes the name of the protocol avoids 
these issues and is a better choice.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug  3 13:57:21 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:57:21 -0300
Subject: [Cuis] VM Crash
In-Reply-To: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>
References: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>
Message-ID: <55BFB991.1070807@jvuletich.org>

On 8/2/2015 10:24 PM, Dan Norton wrote:
> Load Cuis4.2-2439.image. Open File List and go to Packages.
> Select Graphics-Files-Additional.pck.st and click on "Install Package".
>
> Get "Fatal VM Error". The zipped crash.dmp is attached.
>
>  - Dan
>

I can not reproduce it. Can you reproduce it consistently? Can you 
reproduce it consistently with a fresh image and VM on a local hard 
drive? If so, please provide more details so I can reproduce it.

It seems to be a stack overflow. If you can reproduce it, you can try 
again, and after Install Package do alt+. (User Interrupt) and try to 
find out why there is an unbounded recursion.

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

From juan at jvuletich.org  Mon Aug  3 13:59:47 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:59:47 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55BF9CC0.20600.59E8552@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55B8E93C.7080009@jvuletich.org>
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>
Message-ID: <55BFBA23.4010302@jvuletich.org>

On 8/3/2015 1:54 PM, Dan Norton wrote:
> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
>
>> 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.
>>
> I'm trying to get FreeType built and also I did a clone of:
>
> https://github.com/rougier/freetype-gl
>
> Unfortunately when I compile embedded-font.c the following occurs:
>
> fatal error C1083: Cannot open include file: 'vera-16.h': No such file or directory
>
> Do any of you Cexperts know where I can get 'vera-16.h'? Google search produces ads for
> soaps containing aloe vera :-)
>
>   - Dan

Hi Dan,

I can not help you with the build of FreeType , but could you try the 
image I used to build the fonts? You shouldn't need to build anything to 
run it. The FreeType VM plugin is included for both Windows and Mac. I'd 
appreciate any feedback.

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Mon Aug  3 14:16:21 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 03 Aug 2015 15:16:21 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55BF9CC0.20600.59E8552@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
	, <55B8E93C.7080009@jvuletich.org>
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>
Message-ID: <1438629381.12996.1.camel@gmail.com>

On Mon, 2015-08-03 at 12:54 -0400, Dan Norton wrote:
> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> 
> > 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.
> > 
> 
> I'm trying to get FreeType built and also I did a clone of:
> 
> https://github.com/rougier/freetype-gl
> 
> Unfortunately when I compile embedded-font.c the following occurs:
> 
> fatal error C1083: Cannot open include file: 'vera-16.h': No such file or directory
> 
> Do any of you Cexperts know where I can get 'vera-16.h'? Google search produces ads for 
> soaps containing aloe vera :-)
> 

It looks like it's a file generated from Vera.ttf based on
https://travis-ci.org/rougier/freetype-gl

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





From pbpublist at gmail.com  Mon Aug  3 14:19:42 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 03 Aug 2015 15:19:42 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55BFB7D3.4030701@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org>
Message-ID: <1438629582.12996.4.camel@gmail.com>

On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
> Hi Doug,
> 
> On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> > On 19/07/2015 22:38, Phil (list) wrote:
> >> 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 vaguely recall that many years ago there was a project called 
> > SmallInterfaces that let you define public interfaces to objects. (Or 
> > something like that). Would that be a good way to document the 
> > public/private api using code?
> >
> > (sorry for being so vague but I've been awake for 24+ hours now)
> 
> Thanks for the pointer. I took a look at it. It is quite like Java 
> interfaces. The tools are interesting. But I see several downsides:
> 
> - Each interface is a class. Each method in the protocol is an actual 
> method. If we use this to document all public protocols in Cuis, it 
> would mean a lot of new classes and methods.
> - The source code of (for example) OrderedCollection>>at: would not 
> include the information of it belonging to interface "Indexable". 
> Without additional support from tools users can't tell whether a message 
> is public protocol or not. And the base image / package maintainer can't 
> easily see he's about to change a public api.
> 
> I think a method pragma, that includes the name of the protocol avoids 
> these issues and is a better choice.
> 

I agree.  Let's keep it as simple as possible and see how far that gets
us.

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





From peter at aba-instituut.nl  Mon Aug  3 15:35:51 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Mon, 3 Aug 2015 22:35:51 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1438629582.12996.4.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org>
	<1438629582.12996.4.camel@gmail.com>
Message-ID: <CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>

Hi,

1. I'm totally against introducing pragma's (perhaps they already exist in
Cuis, I don't know).

First of all because they are not Smalltalk, and second because they are
not needed.

What would be wrong with simply introducing a convention and adding a
method cuisPublicSelectors to a class?

To avoid seeing them on the instance side, there could also be
cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class side.

At the top these would be defined as self allSelectors.

If someone wanted to view only the public selectors in a browser, they
would check the checkbox for that and the browser would hide the non-public
selectors.

Or the browser could show a nice public interface report added to the class
comment.

2. On another point: interfaces such as indexable could simply be described
by creating a class CuisInterfaceSpecification which gets a subclass for
each interface specified. The methods belonging to the interface are
defined and get a comment explaining the semantics of the method. This
makes it easy for tools to check which interfaces are (probably)
implemented by a class. If desired, each method could be additionally
defined to return a MethodSpecification object that knows about
preconditions, invariants, return values, argument and return
types/interfaces...but then it becomes progressively more complicated.

But anyway, in this way whoever thinks it's important enough, can add the
info (for public selectors of a class or for whole interface
specifications) without anyone who is not interested in that needing to
know or care about that.

In my mind that gels well with Cuis' philosophy of simplicity. But I could
be missing the whole point...

Cheers, Peter





On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <pbpublist at gmail.com> wrote:

> On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
> > Hi Doug,
> >
> > On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> > > On 19/07/2015 22:38, Phil (list) wrote:
> > >> 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 vaguely recall that many years ago there was a project called
> > > SmallInterfaces that let you define public interfaces to objects. (Or
> > > something like that). Would that be a good way to document the
> > > public/private api using code?
> > >
> > > (sorry for being so vague but I've been awake for 24+ hours now)
> >
> > Thanks for the pointer. I took a look at it. It is quite like Java
> > interfaces. The tools are interesting. But I see several downsides:
> >
> > - Each interface is a class. Each method in the protocol is an actual
> > method. If we use this to document all public protocols in Cuis, it
> > would mean a lot of new classes and methods.
> > - The source code of (for example) OrderedCollection>>at: would not
> > include the information of it belonging to interface "Indexable".
> > Without additional support from tools users can't tell whether a message
> > is public protocol or not. And the base image / package maintainer can't
> > easily see he's about to change a public api.
> >
> > I think a method pragma, that includes the name of the protocol avoids
> > these issues and is a better choice.
> >
>
> I agree.  Let's keep it as simple as possible and see how far that gets
> us.
>
> > 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/20150803/df8af54b/attachment-0002.html>

From dnorton at mindspring.com  Mon Aug  3 19:08:08 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 03 Aug 2015 20:08:08 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55BFBA23.4010302@jvuletich.org>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>,
	<55BFBA23.4010302@jvuletich.org>
Message-ID: <55C00268.12873.72B9E46@dnorton.mindspring.com>

On 3 Aug 2015 at 15:59, Juan Vuletich wrote:

> On 8/3/2015 1:54 PM, Dan Norton wrote:
> > On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> >
> >> 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.
> >>
> > I'm trying to get FreeType built and also I did a clone of:
> >
> > https://github.com/rougier/freetype-gl
> >
> > Unfortunately when I compile embedded-font.c the following
> occurs:
> >
> > fatal error C1083: Cannot open include file: 'vera-16.h': No such
> file or directory
> >
> > Do any of you Cexperts know where I can get 'vera-16.h'? Google
> search produces ads for
> > soaps containing aloe vera :-)
> >
> >   - Dan
> 
> Hi Dan,
> 
> I can not help you with the build of FreeType , but could you try
> the 
> image I used to build the fonts? You shouldn't need to build
> anything to 
> run it. The FreeType VM plugin is included for both Windows and Mac.
> I'd 
> appreciate any feedback.
>

OK, the package works as far as choosing fonts from a list. How the list is derived is not 
clear. Inconsolata is not on it. The chosen font can be used in ListMorphs. The thing which 
eludes me here is the same in the other environs: How to write a .bmp file containing the 
glyphs. That problem was the reason for pursuing FreeType and OpenGL. I see the 
characters displayed in the pane. They are drawn correctly. Where are the glyphs?

 - Dan



From juan at jvuletich.org  Mon Aug  3 19:51:42 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 21:51:42 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C00268.12873.72B9E46@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>,
	<55BFBA23.4010302@jvuletich.org>
	<55C00268.12873.72B9E46@dnorton.mindspring.com>
Message-ID: <55C00C9E.5040207@jvuletich.org>

On 03/08/2015 09:08 p.m., Dan Norton wrote:
> On 3 Aug 2015 at 15:59, Juan Vuletich wrote:
>
>> On 8/3/2015 1:54 PM, Dan Norton wrote:
>>> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
>>>
>>>> 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.
>>>>
>>> I'm trying to get FreeType built and also I did a clone of:
>>>
>>> https://github.com/rougier/freetype-gl
>>>
>>> Unfortunately when I compile embedded-font.c the following
>> occurs:
>>> fatal error C1083: Cannot open include file: 'vera-16.h': No such
>> file or directory
>>> Do any of you Cexperts know where I can get 'vera-16.h'? Google
>> search produces ads for
>>> soaps containing aloe vera :-)
>>>
>>>    - Dan
>> Hi Dan,
>>
>> I can not help you with the build of FreeType , but could you try
>> the
>> image I used to build the fonts? You shouldn't need to build
>> anything to
>> run it. The FreeType VM plugin is included for both Windows and Mac.
>> I'd
>> appreciate any feedback.
>>
> OK, the package works as far as choosing fonts from a list. How the list is derived is not
> clear. Inconsolata is not on it. The chosen font can be used in ListMorphs. The thing which
> eludes me here is the same in the other environs: How to write a .bmp file containing the
> glyphs. That problem was the reason for pursuing FreeType and OpenGL. I see the
> characters displayed in the pane. They are drawn correctly. Where are the glyphs?
>
>   - Dan

When you open that image, you see a browser open on a method called 
#export. Some text is already selected. Before the selected text it says 
"Set FreeType preferences" and "Create a folder named AAFonts". The 
selected text does "FreeTypeFontProvider current updateFromSystem." . 
This loads your Windows / MacOS fonts into the image. Then follows a 
lists of fonts. Those fonts must be available to the system. The rest of 
the selected code does the export, saving the bmp and txt files. To 
export Inconsolata, or any other font, first load it into your Windows 
or MacOS system, then add it to the list, then export.

I thought all this was self-explanatory...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug  3 19:55:10 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 21:55:10 -0300
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT
 version number
In-Reply-To: <1437950873600-4839529.post@n4.nabble.com>
References: <55B0F0B2.6090202@jvuletich.org>
	<1437950873600-4839529.post@n4.nabble.com>
Message-ID: <55C00D6E.3020602@jvuletich.org>

Thanks, folks.

(inline)
On 26/07/2015 07:47 p.m., Dan Norton wrote:
>
> 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?
>

Uh, that was a long time ago... I guess it was around 1997 or 1998... It 
would be fun to do it, though.

Cheers,
Juan Vuletich

> App delivery sans IDE, halos, menus
>
> Apps with feedback; output becomes next input
>
> Recognition biometrics
>
> Financial analysis
>
> Anything fun
>
>   - Dan




From dnorton at mindspring.com  Mon Aug  3 21:52:12 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 03 Aug 2015 22:52:12 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C00C9E.5040207@jvuletich.org>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55C00268.12873.72B9E46@dnorton.mindspring.com>,
	<55C00C9E.5040207@jvuletich.org>
Message-ID: <55C028DC.25658.2EEEB2@dnorton.mindspring.com>

On 3 Aug 2015 at 21:51, Juan Vuletich wrote:

> On 03/08/2015 09:08 p.m., Dan Norton wrote:
> > On 3 Aug 2015 at 15:59, Juan Vuletich wrote:
> >
> >> On 8/3/2015 1:54 PM, Dan Norton wrote:
> >>> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> >>>
> >>>> 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.
> >>>>
> >>> I'm trying to get FreeType built and also I did a clone of:
> >>>
> >>> https://github.com/rougier/freetype-gl
> >>>
> >>> Unfortunately when I compile embedded-font.c the following
> >> occurs:
> >>> fatal error C1083: Cannot open include file: 'vera-16.h': No
> such
> >> file or directory
> >>> Do any of you Cexperts know where I can get 'vera-16.h'?
> Google
> >> search produces ads for
> >>> soaps containing aloe vera :-)
> >>>
> >>>    - Dan
> >> Hi Dan,
> >>
> >> I can not help you with the build of FreeType , but could you
> try
> >> the
> >> image I used to build the fonts? You shouldn't need to build
> >> anything to
> >> run it. The FreeType VM plugin is included for both Windows and
> Mac.
> >> I'd
> >> appreciate any feedback.
> >>
> > OK, the package works as far as choosing fonts from a list. How
> the list is derived is not
> > clear. Inconsolata is not on it. The chosen font can be used in
> ListMorphs. The thing which
> > eludes me here is the same in the other environs: How to write a
> .bmp file containing the
> > glyphs. That problem was the reason for pursuing FreeType and
> OpenGL. I see the
> > characters displayed in the pane. They are drawn correctly. Where
> are the glyphs?
> >
> >   - Dan
> 
> When you open that image, you see a browser open on a method called
> #export. Some text is already selected. Before the selected text it
> says 
> "Set FreeType preferences" and "Create a folder named AAFonts". The
> selected text does "FreeTypeFontProvider current updateFromSystem."
> . 
> This loads your Windows / MacOS fonts into the image. Then follows a
> lists of fonts. Those fonts must be available to the system. The
> rest of 
> the selected code does the export, saving the bmp and txt files. To
> export Inconsolata, or any other font, first load it into your
> Windows 
> or MacOS system, then add it to the list, then export.
> 
> I thought all this was self-explanatory...
> 
> Cheers,
> Juan Vuletich

If a font name is not in the system, the image crashes. Only a reboot recovers.

It is not possible to create a new file in the AAFonts directory. It is possible in the current 
directory however.

I'm going to restore my system to before Visual Studio et al. There is too much wierdness.

 - Dan





From pbpublist at gmail.com  Mon Aug  3 22:20:03 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 03 Aug 2015 23:20:03 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org> <1438629582.12996.4.camel@gmail.com>
	<CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>
Message-ID: <1438658403.12996.35.camel@gmail.com>

On Mon, 2015-08-03 at 22:35 +0200, Peter van Rooijen wrote:
> Hi,
> 
> 
> 1. I'm totally against introducing pragma's (perhaps they already
> exist in Cuis, I don't know).
> 

Too late, they're already there (VM functionality)

> 
> First of all because they are not Smalltalk, and second because they
> are not needed.
> 
> 
> What would be wrong with simply introducing a convention and adding a
> method cuisPublicSelectors to a class?
> 
> 
> To avoid seeing them on the instance side, there could also be
> cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class
> side.
> 
> 
> At the top these would be defined as self allSelectors.
> 
> 
> If someone wanted to view only the public selectors in a browser, they
> would check the checkbox for that and the browser would hide the
> non-public selectors.
> 
> 
> Or the browser could show a nice public interface report added to the
> class comment.
> 
> 
> 2. On another point: interfaces such as indexable could simply be
> described by creating a class CuisInterfaceSpecification which gets a
> subclass for each interface specified. The methods belonging to the
> interface are defined and get a comment explaining the semantics of
> the method. This makes it easy for tools to check which interfaces are
> (probably) implemented by a class. If desired, each method could be
> additionally defined to return a MethodSpecification object that knows
> about preconditions, invariants, return values, argument and return
> types/interfaces...but then it becomes progressively more complicated.
> 
> 
> But anyway, in this way whoever thinks it's important enough, can add
> the info (for public selectors of a class or for whole interface
> specifications) without anyone who is not interested in that needing
> to know or care about that.
> 

This is too complicated for what I think we're trying to achieve...

> 
> In my mind that gels well with Cuis' philosophy of simplicity. But I
> could be missing the whole point...
> 

The intent (what I was going for at least) is to provide a means for
Juan and anyone else modifying the core image / packages to have a
bidirectional communications channel with anyone looking to have a
stable set of APIs that they can depend on.  It needs to be something
that's simple and easy for both Juan and us to use, or it won't get
used.  I think that Juan's pragma approach accomplishes this.  All it
signals is that 'this method will keep working as it currently does
until/unless it is formally decided to change it'.

So here's an example of how this might work:
1) Let's say we propose that #asString as a public API and Juan agrees
that this is a useful method and should be fairly stable.
Implementations of #asString get marked with a publicAPI (or whatever
name makes sense) pragma 
2) Those of us who care can then work to ensure that our code is using
these publicAPI methods when possible.  This will also help drive out
some of our own bad behavior where we were calling things that we really
shouldn't have been.
3) Time passes and life is good :-)
4) Down the line (Cuis 5.x, 6.x... whatever) Juan decides that #asString
needs to change (who knows... unicode support... or maybe he just
decides that #asString is the wrong way to do it)  Seeing that #asString
is flagged publicAPI, he knows not to 'just do it' but rather make sure
that the change gets called out in the release notes (after some mailing
list discussion if he deems it worthwhile to do so... his call) and that
since it will likely break code to probably wait for a major release.

This also allows for deprecating things that are designated as
publicAPI... just because something is public does not mean it always
will be, just that the changes to things that are need to be
communicated more richly.  For me, the documentation aspect of it is a
nice to have secondary objective that falls out of it... getting to a
stable core is the primary objective.  (i.e. we're not documenting for
the sake of documenting)

> 
> Cheers, Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <pbpublist at gmail.com>
> wrote:
>         On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
>         > Hi Doug,
>         >
>         > On 8/2/2015 4:04 AM, Douglas Brebner wrote:
>         > > On 19/07/2015 22:38, Phil (list) wrote:
>         > >> 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 vaguely recall that many years ago there was a project
>         called
>         > > SmallInterfaces that let you define public interfaces to
>         objects. (Or
>         > > something like that). Would that be a good way to document
>         the
>         > > public/private api using code?
>         > >
>         > > (sorry for being so vague but I've been awake for 24+
>         hours now)
>         >
>         > Thanks for the pointer. I took a look at it. It is quite
>         like Java
>         > interfaces. The tools are interesting. But I see several
>         downsides:
>         >
>         > - Each interface is a class. Each method in the protocol is
>         an actual
>         > method. If we use this to document all public protocols in
>         Cuis, it
>         > would mean a lot of new classes and methods.
>         > - The source code of (for example) OrderedCollection>>at:
>         would not
>         > include the information of it belonging to interface
>         "Indexable".
>         > Without additional support from tools users can't tell
>         whether a message
>         > is public protocol or not. And the base image / package
>         maintainer can't
>         > easily see he's about to change a public api.
>         >
>         > I think a method pragma, that includes the name of the
>         protocol avoids
>         > these issues and is a better choice.
>         >
>         
>         
>         I agree.  Let's keep it as simple as possible and see how far
>         that gets
>         us.
>         
>         > 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





From dnorton at mindspring.com  Tue Aug  4 13:35:19 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 14:35:19 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>

On 3 Aug 2015 at 22:52, Dan Norton wrote:

> On 3 Aug 2015 at 21:51, Juan Vuletich wrote:
> 
> > On 03/08/2015 09:08 p.m., Dan Norton wrote:
> > > On 3 Aug 2015 at 15:59, Juan Vuletich wrote:
> > >
> > >> On 8/3/2015 1:54 PM, Dan Norton wrote:
> > >>> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> > >>>
> > >>>> 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.
> > >>>>
> > >>> I'm trying to get FreeType built and also I did a clone of:
> > >>>
> > >>> https://github.com/rougier/freetype-gl
> > >>>
> > >>> Unfortunately when I compile embedded-font.c the following
> > >> occurs:
> > >>> fatal error C1083: Cannot open include file: 'vera-16.h': No
> > such
> > >> file or directory
> > >>> Do any of you Cexperts know where I can get 'vera-16.h'?
> > Google
> > >> search produces ads for
> > >>> soaps containing aloe vera :-)
> > >>>
> > >>>    - Dan
> > >> Hi Dan,
> > >>
> > >> I can not help you with the build of FreeType , but could you
> > try
> > >> the
> > >> image I used to build the fonts? You shouldn't need to build
> > >> anything to
> > >> run it. The FreeType VM plugin is included for both Windows
> and
> > Mac.
> > >> I'd
> > >> appreciate any feedback.
> > >>
> > > OK, the package works as far as choosing fonts from a list.
> How
> > the list is derived is not
> > > clear. Inconsolata is not on it. The chosen font can be used
> in
> > ListMorphs. The thing which
> > > eludes me here is the same in the other environs: How to write
> a
> > .bmp file containing the
> > > glyphs. That problem was the reason for pursuing FreeType and
> > OpenGL. I see the
> > > characters displayed in the pane. They are drawn correctly.
> Where
> > are the glyphs?
> > >
> > >   - Dan
> > 
> > When you open that image, you see a browser open on a method
> called
> > #export. Some text is already selected. Before the selected text
> it
> > says 
> > "Set FreeType preferences" and "Create a folder named AAFonts".
> The
> > selected text does "FreeTypeFontProvider current
> updateFromSystem."
> > . 
> > This loads your Windows / MacOS fonts into the image. Then follows
> a
> > lists of fonts. Those fonts must be available to the system. The
> > rest of 
> > the selected code does the export, saving the bmp and txt files.
> To
> > export Inconsolata, or any other font, first load it into your
> > Windows 
> > or MacOS system, then add it to the list, then export.
> > 
> > I thought all this was self-explanatory...
> > 
> > Cheers,
> > Juan Vuletich
> 
> If a font name is not in the system, the image crashes. Only a
> reboot recovers.
> 
> It is not possible to create a new file in the AAFonts directory. It
> is possible in the current 
> directory however.
> 
> I'm going to restore my system to before Visual Studio et al. There
> is too much wierdness.
>
Hi Juan,

After the restore and after extracting again the two zip files from your dropbox there remain 
fundamental problems. In FreeTypeFont>>export the following statement results in nothing 
written to AAFonts directory:

n := 'AAFonts', FileDirectory slash, face familyName, '-', emph asString , '-', pointSize 
printString.

If changed to spell out the complete path as follows, some of the .bmp and .txt files are 
written to AAFonts before other problems arise:

n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName, '-', emph asString , '-', 
pointSize printString.

 - Dan



From juan at jvuletich.org  Tue Aug  4 14:09:18 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 16:09:18 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>
Message-ID: <55C10DDE.3090700@jvuletich.org>

On 8/4/2015 3:35 PM, Dan Norton wrote:
> On 3 Aug 2015 at 22:52, Dan Norton wrote:
> ...
>> If a font name is not in the system, the image crashes. Only a
>> reboot recovers.
>>
>> It is not possible to create a new file in the AAFonts directory. It
>> is possible in the current
>> directory however.
>>
>> I'm going to restore my system to before Visual Studio et al. There
>> is too much wierdness.
>>
> Hi Juan,
>
> After the restore and after extracting again the two zip files from your dropbox there remain
> fundamental problems. In FreeTypeFont>>export the following statement results in nothing
> written to AAFonts directory:
>
> n := 'AAFonts', FileDirectory slash, face familyName, '-', emph asString , '-', pointSize
> printString.
>
> If changed to spell out the complete path as follows, some of the .bmp and .txt files are
> written to AAFonts before other problems arise:
>
> n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName, '-', emph asString , '-',
> pointSize printString.
>
>   - Dan

Hi Dan,

I tried again. On a Windows 7 system, I stored the contents of both zips 
in a folder, started the image and exported 'Calibri' without any problems.

In any case, this is not part of Cuis. It wasn't even meant for 
distribution, just for my own use when I built the Bitmap Vera Sans 
fonts in Cuis/Squeak/Pharo. I only published it at your personal 
request, and not in the Cuis repo. It is given without support or 
warranties. If you want to use it, try understanding what is going on. 
After all, it is just Smalltalk. If you do that, and ask specific 
questions, I'll answer.

Juan Vuletich



From dnorton at mindspring.com  Tue Aug  4 14:42:39 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 15:42:39 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C10DDE.3090700@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C10DDE.3090700@jvuletich.org>
Message-ID: <55C115AF.28292.158941B@dnorton.mindspring.com>

On 4 Aug 2015 at 16:09, Juan Vuletich wrote:

> On 8/4/2015 3:35 PM, Dan Norton wrote:
> > On 3 Aug 2015 at 22:52, Dan Norton wrote:
> > ...
> >> If a font name is not in the system, the image crashes. Only a
> >> reboot recovers.
> >>
> >> It is not possible to create a new file in the AAFonts directory.
> It
> >> is possible in the current
> >> directory however.
> >>
> >> I'm going to restore my system to before Visual Studio et al.
> There
> >> is too much wierdness.
> >>
> > Hi Juan,
> >
> > After the restore and after extracting again the two zip files
> from your dropbox there remain
> > fundamental problems. In FreeTypeFont>>export the following
> statement results in nothing
> > written to AAFonts directory:
> >
> > n := 'AAFonts', FileDirectory slash, face familyName, '-', emph
> asString , '-', pointSize
> > printString.
> >
> > If changed to spell out the complete path as follows, some of the
> .bmp and .txt files are
> > written to AAFonts before other problems arise:
> >
> > n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName,
> '-', emph asString , '-',
> > pointSize printString.
> >
> >   - Dan
> 
> Hi Dan,
> 
> I tried again. On a Windows 7 system, I stored the contents of both
> zips 
> in a folder, started the image and exported 'Calibri' without any
> problems.
> 

On my Windows 7 I tried to export 'Calibri' and got MNU: receiver of "nextPutAll:" is nil.
This is the same problem which led to my work-around above. Don't waste any more time on 
this. It may be something clobbered a .dll and has nothing to do with Squeak. I will continue 
to work on it because I need a fixed-width font. Not having it has me stalled on a project.

> In any case, this is not part of Cuis. It wasn't even meant for 
> distribution, just for my own use when I built the Bitmap Vera Sans
> fonts in Cuis/Squeak/Pharo. I only published it at your personal 
> request, and not in the Cuis repo. It is given without support or 
> warranties. If you want to use it, try understanding what is going
> on. 
> After all, it is just Smalltalk. If you do that, and ask specific 
> questions, I'll answer.
> 
> Juan Vuletich





From juan at jvuletich.org  Tue Aug  4 15:08:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 17:08:01 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C115AF.28292.158941B@dnorton.mindspring.com>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C10DDE.3090700@jvuletich.org>
	<55C115AF.28292.158941B@dnorton.mindspring.com>
Message-ID: <55C11BA1.6000406@jvuletich.org>

On 8/4/2015 4:42 PM, Dan Norton wrote:
> On 4 Aug 2015 at 16:09, Juan Vuletich wrote:
>
>> On 8/4/2015 3:35 PM, Dan Norton wrote:
>>> On 3 Aug 2015 at 22:52, Dan Norton wrote:
>>> ...
>>>> If a font name is not in the system, the image crashes. Only a
>>>> reboot recovers.
>>>>
>>>> It is not possible to create a new file in the AAFonts directory.
>> It
>>>> is possible in the current
>>>> directory however.
>>>>
>>>> I'm going to restore my system to before Visual Studio et al.
>> There
>>>> is too much wierdness.
>>>>
>>> Hi Juan,
>>>
>>> After the restore and after extracting again the two zip files
>> from your dropbox there remain
>>> fundamental problems. In FreeTypeFont>>export the following
>> statement results in nothing
>>> written to AAFonts directory:
>>>
>>> n := 'AAFonts', FileDirectory slash, face familyName, '-', emph
>> asString , '-', pointSize
>>> printString.
>>>
>>> If changed to spell out the complete path as follows, some of the
>> .bmp and .txt files are
>>> written to AAFonts before other problems arise:
>>>
>>> n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName,
>> '-', emph asString , '-',
>>> pointSize printString.
>>>
>>>    - Dan
>> Hi Dan,
>>
>> I tried again. On a Windows 7 system, I stored the contents of both
>> zips
>> in a folder, started the image and exported 'Calibri' without any
>> problems.
>>
> On my Windows 7 I tried to export 'Calibri' and got MNU: receiver of "nextPutAll:" is nil.
> This is the same problem which led to my work-around above. Don't waste any more time on
> this. It may be something clobbered a .dll and has nothing to do with Squeak. I will continue
> to work on it because I need a fixed-width font. Not having it has me stalled on a project.
>

Then I suggest the following: Save the contents of those zips to a thumb 
drive. Borrow a Windows machine, from someone that doesn't do weird 
stuff with dlls and VisualStudio ;-) . Run from the thumb drive, and 
take it home.

Oh, something else. On the Mac, the procedure generated txt files with 
integer numbers. On Windows there are Floats. Most likely that is wrong...

Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono or 
Inconsolata myself...

>> In any case, this is not part of Cuis. It wasn't even meant for
>> distribution, just for my own use when I built the Bitmap Vera Sans
>> fonts in Cuis/Squeak/Pharo. I only published it at your personal
>> request, and not in the Cuis repo. It is given without support or
>> warranties. If you want to use it, try understanding what is going
>> on.
>> After all, it is just Smalltalk. If you do that, and ask specific
>> questions, I'll answer.
>>
>> Juan Vuletich
>

Cheers,
Juan Vuletich



From dnorton at mindspring.com  Tue Aug  4 17:10:49 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 18:10:49 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C11BA1.6000406@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C115AF.28292.158941B@dnorton.mindspring.com>,
	<55C11BA1.6000406@jvuletich.org>
Message-ID: <55C13869.19799.1E03D95@dnorton.mindspring.com>

(In line...)

On 4 Aug 2015 at 17:08, Juan Vuletich wrote:

> On 8/4/2015 4:42 PM, Dan Norton wrote:
> > On 4 Aug 2015 at 16:09, Juan Vuletich wrote:
> >
> >> On 8/4/2015 3:35 PM, Dan Norton wrote:
> >>> On 3 Aug 2015 at 22:52, Dan Norton wrote:
> >>> ...
> >>>> If a font name is not in the system, the image crashes. Only
> a
> >>>> reboot recovers.
> >>>>
> >>>> It is not possible to create a new file in the AAFonts
> directory.
> >> It
> >>>> is possible in the current
> >>>> directory however.
> >>>>
> >>>> I'm going to restore my system to before Visual Studio et al.
> >> There
> >>>> is too much wierdness.
> >>>>
> >>> Hi Juan,
> >>>
> >>> After the restore and after extracting again the two zip files
> >> from your dropbox there remain
> >>> fundamental problems. In FreeTypeFont>>export the following
> >> statement results in nothing
> >>> written to AAFonts directory:
> >>>
> >>> n := 'AAFonts', FileDirectory slash, face familyName, '-',
> emph
> >> asString , '-', pointSize
> >>> printString.
> >>>
> >>> If changed to spell out the complete path as follows, some of
> the
> >> .bmp and .txt files are
> >>> written to AAFonts before other problems arise:
> >>>
> >>> n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face
> familyName,
> >> '-', emph asString , '-',
> >>> pointSize printString.
> >>>
> >>>    - Dan
> >> Hi Dan,
> >>
> >> I tried again. On a Windows 7 system, I stored the contents of
> both
> >> zips
> >> in a folder, started the image and exported 'Calibri' without
> any
> >> problems.
> >>
> > On my Windows 7 I tried to export 'Calibri' and got MNU: receiver
> of "nextPutAll:" is nil.
> > This is the same problem which led to my work-around above. Don't
> waste any more time on
> > this. It may be something clobbered a .dll and has nothing to do
> with Squeak. I will continue
> > to work on it because I need a fixed-width font. Not having it has
> me stalled on a project.
> >
> 
> Then I suggest the following: Save the contents of those zips to a
> thumb 
> drive. Borrow a Windows machine, from someone that doesn't do weird
> stuff with dlls and VisualStudio ;-) . Run from the thumb drive, and
> take it home.
> 

Did that on my wife's laptop and got the same result. Trust me, she does not have Visual 
Studio or anything else more rad than FireFox :-)


> Oh, something else. On the Mac, the procedure generated txt files
> with 
> integer numbers. On Windows there are Floats. Most likely that is
> wrong...
> 
> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono or
> Inconsolata myself...
> 

That would sure be great. When I started this journey many moons ago, Inconsolata was my 
idea of a great font to have on Cuis.

> >> In any case, this is not part of Cuis. It wasn't even meant for
> >> distribution, just for my own use when I built the Bitmap Vera
> Sans
> >> fonts in Cuis/Squeak/Pharo. I only published it at your
> personal
> >> request, and not in the Cuis repo. It is given without support
> or
> >> warranties. If you want to use it, try understanding what is
> going
> >> on.
> >> After all, it is just Smalltalk. If you do that, and ask
> specific
> >> questions, I'll answer.
> >>
> >> Juan Vuletich
> >
> 
> Cheers,
> Juan Vuletich





From dnorton at mindspring.com  Tue Aug  4 20:22:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 21:22:35 -0400
Subject: [Cuis] VM Crash
In-Reply-To: <55BFB991.1070807@jvuletich.org>
References: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>,
	<55BFB991.1070807@jvuletich.org>
Message-ID: <55C1655B.25215.20DAE4@dnorton.mindspring.com>

On 3 Aug 2015 at 15:57, Juan Vuletich wrote:

> 
> On 8/2/2015 10:24 PM, Dan Norton wrote:
>     Load Cuis4.2-2439.image. Open File List and go to Packages.
>     Select Graphics-Files-Additional.pck.st and click on "Install
> Package".
> 
>     Get "Fatal VM Error". The zipped crash.dmp is attached.
> 
>     ?- Dan
> 
> 
> I can not reproduce it. Can you reproduce it consistently? Can you
> reproduce it consistently with a 
> fresh image and VM on a local hard drive? If so, please provide more
> details so I can reproduce it.
> 
> It seems to be a stack overflow. If you can reproduce it, you can
> try again, and after Install 
> Package do alt+. (User Interrupt) and try to find out why there is
> an unbounded recursion.
> 

The problem occurs with cogwin-15.28.3410. It is consistent and will not yield to alt+. .

The problem does not occur with cogwin-15.27.3397.

These runs were done on Windows 7.

 - Dan



From juan at jvuletich.org  Tue Aug  4 21:47:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 23:47:49 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C13869.19799.1E03D95@dnorton.mindspring.com>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C115AF.28292.158941B@dnorton.mindspring.com>,
	<55C11BA1.6000406@jvuletich.org>
	<55C13869.19799.1E03D95@dnorton.mindspring.com>
Message-ID: <55C17955.7050807@jvuletich.org>

On 8/4/2015 7:10 PM, Dan Norton wrote:
>
>> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono or
>> Inconsolata myself...
>>
> That would sure be great. When I started this journey many moons ago, Inconsolata was my
> idea of a great font to have on Cuis.

Ok. Set up the AAFonts folder with contents. File in both cs'. Evaluate 
[StrikeFont install: 'DejaVu Sans Mono']. I hope it works for you.

I didn't include Inconsolata because it doesn't have italics or bold, 
and also because DejaVuSansMono looks quite better with Freetype.

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DejaVuSansMono.zip
Type: application/zip
Size: 1070498 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150804/d3d63655/attachment-0002.zip>

From juan at jvuletich.org  Tue Aug  4 21:57:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 23:57:43 -0300
Subject: [Cuis] VM Crash
In-Reply-To: <55C1655B.25215.20DAE4@dnorton.mindspring.com>
References: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>,
	<55BFB991.1070807@jvuletich.org>
	<55C1655B.25215.20DAE4@dnorton.mindspring.com>
Message-ID: <55C17BA7.6080008@jvuletich.org>

On 8/4/2015 10:22 PM, Dan Norton wrote:
> On 3 Aug 2015 at 15:57, Juan Vuletich wrote:
>
>> On 8/2/2015 10:24 PM, Dan Norton wrote:
>>      Load Cuis4.2-2439.image. Open File List and go to Packages.
>>      Select Graphics-Files-Additional.pck.st and click on "Install
>> Package".
>>
>>      Get "Fatal VM Error". The zipped crash.dmp is attached.
>>
>>       - Dan
>>
>>
>> I can not reproduce it. Can you reproduce it consistently? Can you
>> reproduce it consistently with a
>> fresh image and VM on a local hard drive? If so, please provide more
>> details so I can reproduce it.
>>
>> It seems to be a stack overflow. If you can reproduce it, you can
>> try again, and after Install
>> Package do alt+. (User Interrupt) and try to find out why there is
>> an unbounded recursion.
>>
> The problem occurs with cogwin-15.28.3410. It is consistent and will not yield to alt+. .
>
> The problem does not occur with cogwin-15.27.3397.
>
> These runs were done on Windows 7.
>
>   - Dan

Yes. Same here. Use 
http://www.mirandabanda.org/files/Cog/VM/VM.r3370/cogwin-15.22.3370.zip 
. About a week ago I reported another problem with later releases of Cog 
to VM-Dev. Still, without luck.

Juan Vuletich



From edgardec2005 at gmail.com  Wed Aug  5 04:04:44 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Wed, 05 Aug 2015 06:04:44 -0300
Subject: [Cuis] Wish Feedback
Message-ID: <D1E757FC.15B3C%edgardec2005@gmail.com>

In the twitter links exploration of today I found

https://github.com/aserg-ufmg/JSCity This maybe could be in future
?Divagaciones?
To people who don?t know , ?Divagaciones? is my perpetual personal learning
tool and could be viewed trough www.squeakros.org

user: visita
pass: (do not type any here)

 
And from here

http://www.inf.usi.ch/phd/wettel/codecity.html

See in what is programmed and tell

Coud pay the work for porting CodeCity
 to Squeak/Cuis ?


Edgar
@morplenauta 


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

From peter at aba-instituut.nl  Wed Aug  5 10:50:12 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 5 Aug 2015 17:50:12 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1438658403.12996.35.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org>
	<1438629582.12996.4.camel@gmail.com>
	<CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>
	<1438658403.12996.35.camel@gmail.com>
Message-ID: <CAJBxtBbAFcAkw7m4kV_U=QeUTNoXYSQxnsE-kT2pv-JT0jWCbg@mail.gmail.com>

Thanks Phil for the explanation.

Cheers, Peter

On Tue, Aug 4, 2015 at 5:20 AM, Phil (list) <pbpublist at gmail.com> wrote:

> On Mon, 2015-08-03 at 22:35 +0200, Peter van Rooijen wrote:
> > Hi,
> >
> >
> > 1. I'm totally against introducing pragma's (perhaps they already
> > exist in Cuis, I don't know).
> >
>
> Too late, they're already there (VM functionality)
>
> >
> > First of all because they are not Smalltalk, and second because they
> > are not needed.
> >
> >
> > What would be wrong with simply introducing a convention and adding a
> > method cuisPublicSelectors to a class?
> >
> >
> > To avoid seeing them on the instance side, there could also be
> > cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class
> > side.
> >
> >
> > At the top these would be defined as self allSelectors.
> >
> >
> > If someone wanted to view only the public selectors in a browser, they
> > would check the checkbox for that and the browser would hide the
> > non-public selectors.
> >
> >
> > Or the browser could show a nice public interface report added to the
> > class comment.
> >
> >
> > 2. On another point: interfaces such as indexable could simply be
> > described by creating a class CuisInterfaceSpecification which gets a
> > subclass for each interface specified. The methods belonging to the
> > interface are defined and get a comment explaining the semantics of
> > the method. This makes it easy for tools to check which interfaces are
> > (probably) implemented by a class. If desired, each method could be
> > additionally defined to return a MethodSpecification object that knows
> > about preconditions, invariants, return values, argument and return
> > types/interfaces...but then it becomes progressively more complicated.
> >
> >
> > But anyway, in this way whoever thinks it's important enough, can add
> > the info (for public selectors of a class or for whole interface
> > specifications) without anyone who is not interested in that needing
> > to know or care about that.
> >
>
> This is too complicated for what I think we're trying to achieve...
>
> >
> > In my mind that gels well with Cuis' philosophy of simplicity. But I
> > could be missing the whole point...
> >
>
> The intent (what I was going for at least) is to provide a means for
> Juan and anyone else modifying the core image / packages to have a
> bidirectional communications channel with anyone looking to have a
> stable set of APIs that they can depend on.  It needs to be something
> that's simple and easy for both Juan and us to use, or it won't get
> used.  I think that Juan's pragma approach accomplishes this.  All it
> signals is that 'this method will keep working as it currently does
> until/unless it is formally decided to change it'.
>
> So here's an example of how this might work:
> 1) Let's say we propose that #asString as a public API and Juan agrees
> that this is a useful method and should be fairly stable.
> Implementations of #asString get marked with a publicAPI (or whatever
> name makes sense) pragma
> 2) Those of us who care can then work to ensure that our code is using
> these publicAPI methods when possible.  This will also help drive out
> some of our own bad behavior where we were calling things that we really
> shouldn't have been.
> 3) Time passes and life is good :-)
> 4) Down the line (Cuis 5.x, 6.x... whatever) Juan decides that #asString
> needs to change (who knows... unicode support... or maybe he just
> decides that #asString is the wrong way to do it)  Seeing that #asString
> is flagged publicAPI, he knows not to 'just do it' but rather make sure
> that the change gets called out in the release notes (after some mailing
> list discussion if he deems it worthwhile to do so... his call) and that
> since it will likely break code to probably wait for a major release.
>
> This also allows for deprecating things that are designated as
> publicAPI... just because something is public does not mean it always
> will be, just that the changes to things that are need to be
> communicated more richly.  For me, the documentation aspect of it is a
> nice to have secondary objective that falls out of it... getting to a
> stable core is the primary objective.  (i.e. we're not documenting for
> the sake of documenting)
>
> >
> > Cheers, Peter
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <pbpublist at gmail.com>
> > wrote:
> >         On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
> >         > Hi Doug,
> >         >
> >         > On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> >         > > On 19/07/2015 22:38, Phil (list) wrote:
> >         > >> 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 vaguely recall that many years ago there was a project
> >         called
> >         > > SmallInterfaces that let you define public interfaces to
> >         objects. (Or
> >         > > something like that). Would that be a good way to document
> >         the
> >         > > public/private api using code?
> >         > >
> >         > > (sorry for being so vague but I've been awake for 24+
> >         hours now)
> >         >
> >         > Thanks for the pointer. I took a look at it. It is quite
> >         like Java
> >         > interfaces. The tools are interesting. But I see several
> >         downsides:
> >         >
> >         > - Each interface is a class. Each method in the protocol is
> >         an actual
> >         > method. If we use this to document all public protocols in
> >         Cuis, it
> >         > would mean a lot of new classes and methods.
> >         > - The source code of (for example) OrderedCollection>>at:
> >         would not
> >         > include the information of it belonging to interface
> >         "Indexable".
> >         > Without additional support from tools users can't tell
> >         whether a message
> >         > is public protocol or not. And the base image / package
> >         maintainer can't
> >         > easily see he's about to change a public api.
> >         >
> >         > I think a method pragma, that includes the name of the
> >         protocol avoids
> >         > these issues and is a better choice.
> >         >
> >
> >
> >         I agree.  Let's keep it as simple as possible and see how far
> >         that gets
> >         us.
> >
> >         > 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
>
>
>
> _______________________________________________
> 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/20150805/81e6c93d/attachment-0002.html>

From dnorton at mindspring.com  Wed Aug  5 16:03:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 05 Aug 2015 17:03:56 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C17955.7050807@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C13869.19799.1E03D95@dnorton.mindspring.com>,
	<55C17955.7050807@jvuletich.org>
Message-ID: <55C27A3C.10878.1AAF223@dnorton.mindspring.com>

On 4 Aug 2015 at 23:47, Juan Vuletich wrote:

> On 8/4/2015 7:10 PM, Dan Norton wrote:
> >
> >> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono
> or
> >> Inconsolata myself...
> >>
> > That would sure be great. When I started this journey many moons
> ago, Inconsolata was my
> > idea of a great font to have on Cuis.
> 
> Ok. Set up the AAFonts folder with contents. File in both cs'.
> Evaluate 
> [StrikeFont install: 'DejaVu Sans Mono']. I hope it works for you.
> 
> I didn't include Inconsolata because it doesn't have italics or
> bold, 
> and also because DejaVuSansMono looks quite better with Freetype.
>

Installs great, included in the alt+k menu of a TextEditor, looks great. Thanks, Juan.

Now I'll look into making list elements use DejaVuSansMono.

 - Dan



From dnorton at mindspring.com  Wed Aug  5 18:21:04 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 05 Aug 2015 19:21:04 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C17955.7050807@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C13869.19799.1E03D95@dnorton.mindspring.com>,
	<55C17955.7050807@jvuletich.org>
Message-ID: <55C29A60.17211.22880DD@dnorton.mindspring.com>

On 4 Aug 2015 at 23:47, Juan Vuletich wrote:

> On 8/4/2015 7:10 PM, Dan Norton wrote:
> >
> >> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono
> or
> >> Inconsolata myself...
> >>
> > That would sure be great. When I started this journey many moons
> ago, Inconsolata was my
> > idea of a great font to have on Cuis.
> 
> Ok. Set up the AAFonts folder with contents. File in both cs'.
> Evaluate 
> [StrikeFont install: 'DejaVu Sans Mono']. I hope it works for you.
> 
> I didn't include Inconsolata because it doesn't have italics or
> bold, 
> and also because DejaVuSansMono looks quite better with Freetype.
> 

Hi Juan,

This is very nice. It's a pleasure to use this fixed-width font.  Your changesets and the zip are 
on:

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

in case anyone wants the font before the next Cuis update :)
The Readme explains how to install it, including how to make a PluggableListMorph use it. 
Please excuse the other clutter in the repo.

 - Dan



From dnorton at mindspring.com  Tue Aug 11 20:53:45 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 11 Aug 2015 21:53:45 -0400
Subject: [Cuis] MNU: String>>skipTo:
Message-ID: <55CAA729.16634.269613E@dnorton.mindspring.com>

Some problems trying to the use Symbol class #readFrom: method:

	In the comment "Symbol readFromString: '#abc'", #readFromString: is unknown

	changing it to #readFrom: gets MNU: String>>skipTo:

The method #skipTo: is in PositionableStream but String is not in that hierarchy. However, 
this works:

	Object readFrom: (ReadStream on: '#abc')

In Squeak, "Symbol readFromString: '#abc'" answers #abc.

 - Dan



From Ken.Dickey at whidbey.com  Tue Aug 11 21:13:11 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 11 Aug 2015 19:13:11 -0700
Subject: [Cuis] Solitaire Update
Message-ID: <20150811191311.9978a35a320fbf1b1c1d6932@whidbey.com>

I noted that the Hand no longer gives dropShadows to morphs it picks up.

Not a big deal, but I missed this in Solitaire, so I gave the cards back their shadows.

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

FYI,
-KenD



From pbpublist at gmail.com  Wed Aug 12 16:36:10 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 12 Aug 2015 17:36:10 -0400
Subject: [Cuis] Curious drawing performance issue
Message-ID: <1439415370.2388.20.camel@gmail.com>

I noticed a while back that something appeared to be going on with Cuis
drawing performance (at idle on my system Morphic consumes ~20% of VM
CPU *miniumum* according to ProcessBrowser) and this seems to give an
indication of what it's currently costing in drawing performance...

After seeing the Squeak 5.0 announcement, I was curious to see roughly
how much of a speed boost we might be able to expect from Spur down the
road.  So I decided to look at BouncingAtomsMorph to try to get a rough
apples-to-apples comparison and was quite surprised: Spur was faster,
but it was too much faster.  So I dropped back to Squeak 4.5 and it also
performs much, much better than the Cuis version on the same VM.   Here
are the numbers I'm seeing using BouncingAtomsMorph with roughly
comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
Cuis 2440 (Cog VM 15.25.3390): 6-8 fps

Granted BouncingAtomsMorph is not 100% identical from a source code
standpoint but it's not nearly different enough where I'd expect that
sort of difference.  Is this a platform-specific issue (I'm on Linux) or
are others noticing drawing issues as well?




From pbpublist at gmail.com  Wed Aug 12 16:44:42 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 12 Aug 2015 17:44:42 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439415370.2388.20.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>
Message-ID: <1439415882.2388.22.camel@gmail.com>

I should also mention that the Morph window is ~ 500x450 and #stepTime
is set to 0 for anyone who wants to try to replicate...

On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> I noticed a while back that something appeared to be going on with Cuis
> drawing performance (at idle on my system Morphic consumes ~20% of VM
> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> indication of what it's currently costing in drawing performance...
> 
> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> how much of a speed boost we might be able to expect from Spur down the
> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> apples-to-apples comparison and was quite surprised: Spur was faster,
> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> performs much, much better than the Cuis version on the same VM.   Here
> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> 
> Granted BouncingAtomsMorph is not 100% identical from a source code
> standpoint but it's not nearly different enough where I'd expect that
> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> are others noticing drawing issues as well?





From dnorton at mindspring.com  Wed Aug 12 21:17:16 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 12 Aug 2015 22:17:16 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439415882.2388.22.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<1439415882.2388.22.camel@gmail.com>
Message-ID: <55CBFE2C.3950.28469D6@dnorton.mindspring.com>

Hi Phil,

On Windows 7 with Cuis loaded and idle, Windows Task Manager > Performance reports 0% 
CPU Usage. Memory Usage is 1.28 GB.

With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000 the report is 24 - 
25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.

Cuis 4.2 2449, cogwin 15.22.3370

 - Dan

On 12 Aug 2015 at 17:44, Phil (list) wrote:

> I should also mention that the Morph window is ~ 500x450 and
> #stepTime
> is set to 0 for anyone who wants to try to replicate...
> 
> On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > I noticed a while back that something appeared to be going on with
> Cuis
> > drawing performance (at idle on my system Morphic consumes ~20% of
> VM
> > CPU *miniumum* according to ProcessBrowser) and this seems to give
> an
> > indication of what it's currently costing in drawing
> performance...
> > 
> > After seeing the Squeak 5.0 announcement, I was curious to see
> roughly
> > how much of a speed boost we might be able to expect from Spur
> down the
> > road.  So I decided to look at BouncingAtomsMorph to try to get a
> rough
> > apples-to-apples comparison and was quite surprised: Spur was
> faster,
> > but it was too much faster.  So I dropped back to Squeak 4.5 and
> it also
> > performs much, much better than the Cuis version on the same VM.  
> Here
> > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > comparable (i.e. eyeballed) morph sizes and atom count set to
> 5000:
> > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > 
> > Granted BouncingAtomsMorph is not 100% identical from a source
> code
> > standpoint but it's not nearly different enough where I'd expect
> that
> > sort of difference.  Is this a platform-specific issue (I'm on
> Linux) or
> > are others noticing drawing issues as well?
> 
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From pbpublist at gmail.com  Thu Aug 13 01:29:40 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 13 Aug 2015 02:29:40 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CBFE2C.3950.28469D6@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>
	, <1439415882.2388.22.camel@gmail.com>
	<55CBFE2C.3950.28469D6@dnorton.mindspring.com>
Message-ID: <1439447380.2388.26.camel@gmail.com>

Dan,


On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> Hi Phil,
> 
> On Windows 7 with Cuis loaded and idle, Windows Task Manager > Performance reports 0% 
> CPU Usage. Memory Usage is 1.28 GB.
> 

What does the cpu usage show via World Menu -> Open... -> Process
Browser for Morphic?

> With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000 the report is 24 - 
> 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> 

OK, so it's not platform specific poor performance.  If you close the
BouncingAtomsMorph and wait for things to settle for a few seconds, what
does Process Browser show the Morphic cpu usage as??

> Cuis 4.2 2449, cogwin 15.22.3370
> 
>  - Dan
> 

Thanks,
Phil

> On 12 Aug 2015 at 17:44, Phil (list) wrote:
> 
> > I should also mention that the Morph window is ~ 500x450 and
> > #stepTime
> > is set to 0 for anyone who wants to try to replicate...
> > 
> > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > I noticed a while back that something appeared to be going on with
> > Cuis
> > > drawing performance (at idle on my system Morphic consumes ~20% of
> > VM
> > > CPU *miniumum* according to ProcessBrowser) and this seems to give
> > an
> > > indication of what it's currently costing in drawing
> > performance...
> > > 
> > > After seeing the Squeak 5.0 announcement, I was curious to see
> > roughly
> > > how much of a speed boost we might be able to expect from Spur
> > down the
> > > road.  So I decided to look at BouncingAtomsMorph to try to get a
> > rough
> > > apples-to-apples comparison and was quite surprised: Spur was
> > faster,
> > > but it was too much faster.  So I dropped back to Squeak 4.5 and
> > it also
> > > performs much, much better than the Cuis version on the same VM.  
> > Here
> > > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > > comparable (i.e. eyeballed) morph sizes and atom count set to
> > 5000:
> > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > 
> > > Granted BouncingAtomsMorph is not 100% identical from a source
> > code
> > > standpoint but it's not nearly different enough where I'd expect
> > that
> > > sort of difference.  Is this a platform-specific issue (I'm on
> > Linux) or
> > > are others noticing drawing issues as well?
> > 
> > 
> > 
> > _______________________________________________
> > 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  Thu Aug 13 10:11:36 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 13 Aug 2015 11:11:36 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439447380.2388.26.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CBFE2C.3950.28469D6@dnorton.mindspring.com>,
	<1439447380.2388.26.camel@gmail.com>
Message-ID: <55CCB3A8.12664.2E45B7@dnorton.mindspring.com>

On 13 Aug 2015 at 2:29, Phil (list) wrote:

> Dan,
> 
> 
> On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > Hi Phil,
> > 
> > On Windows 7 with Cuis loaded and idle, Windows Task Manager >
> Performance reports 0% 
> > CPU Usage. Memory Usage is 1.28 GB.
> > 
> 
> What does the cpu usage show via World Menu -> Open... -> Process
> Browser for Morphic?
> 

It shows 12%.

> > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000
> the report is 24 - 
> > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > 
> 
> OK, so it's not platform specific poor performance.  If you close
> the
> BouncingAtomsMorph and wait for things to settle for a few seconds,
> what
> does Process Browser show the Morphic cpu usage as??
>

It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to measure absolute as 
opposed to relative CPU usage seems inaccurate to me. The /difference/ in Process Browser 
numbers while atoms is running vs not running agree with Win7: 1 - 2%.

I don't like for something to try to measure its own performance :-) - an independent 
instrument is preferable IMHO.
 
> > Cuis 4.2 2449, cogwin 15.22.3370
> > 
> >  - Dan
> > 
> 
> Thanks,
> Phil
> 
> > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > 
> > > I should also mention that the Morph window is ~ 500x450 and
> > > #stepTime
> > > is set to 0 for anyone who wants to try to replicate...
> > > 
> > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > I noticed a while back that something appeared to be going on
> with
> > > Cuis
> > > > drawing performance (at idle on my system Morphic consumes
> ~20% of
> > > VM
> > > > CPU *miniumum* according to ProcessBrowser) and this seems to
> give
> > > an
> > > > indication of what it's currently costing in drawing
> > > performance...
> > > > 
> > > > After seeing the Squeak 5.0 announcement, I was curious to
> see
> > > roughly
> > > > how much of a speed boost we might be able to expect from
> Spur
> > > down the
> > > > road.  So I decided to look at BouncingAtomsMorph to try to
> get a
> > > rough
> > > > apples-to-apples comparison and was quite surprised: Spur
> was
> > > faster,
> > > > but it was too much faster.  So I dropped back to Squeak 4.5
> and
> > > it also
> > > > performs much, much better than the Cuis version on the same
> VM.  
> > > Here
> > > > are the numbers I'm seeing using BouncingAtomsMorph with
> roughly
> > > > comparable (i.e. eyeballed) morph sizes and atom count set
> to
> > > 5000:
> > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > 
> > > > Granted BouncingAtomsMorph is not 100% identical from a
> source
> > > code
> > > > standpoint but it's not nearly different enough where I'd
> expect
> > > that
> > > > sort of difference.  Is this a platform-specific issue (I'm
> on
> > > Linux) or
> > > > are others noticing drawing issues as well?
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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 sean at clipperadams.com  Thu Aug 13 11:00:28 2015
From: sean at clipperadams.com (Sean P. DeNigris)
Date: Thu, 13 Aug 2015 09:00:28 -0700 (PDT)
Subject: [Cuis] Wish Feedback
In-Reply-To: <D1E757FC.15B3C%edgardec2005@gmail.com>
References: <D1E757FC.15B3C%edgardec2005@gmail.com>
Message-ID: <1439481628951-4842594.post@n4.nabble.com>

Edgar De Cleene wrote
> www.squeakros.org

I visited, but wasn't sure what to do there. I tried to sign up, which hung
indefinitely. Then clicked the Help link, which seemed to do nothing.



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Wish-Feedback-tp4841005p4842594.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From eliot.miranda at gmail.com  Thu Aug 13 13:11:09 2015
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Thu, 13 Aug 2015 11:11:09 -0700
Subject: [Cuis] Suggestion for a performance analysis project,
	suitable for a masters student
Message-ID: <CAC20JE2Pac5-SpYjRA+k_PwB8POZbaAdVJXxG8rNtuWh2OMvHQ@mail.gmail.com>

Hi All,

    I had occasion to compare VW (vw7.7nc) and Spur recently and was
pleasantly surprised to see that Spur is on average -40% faster than VW on
a large subset of the benchmarks from the shootout (I didn't include three
because of Regex syntax issues).  Now Spur gets some of its speed from
having direct pointers vs VisualWorks' object header/table indirection, but
it could get other speedups from various other differences.  It would be
great to know exactly how much speedup comes from what, and indeed how much
cost Sour pays for its lazy become:.  I'd like to propose a project to
exactly determine the costs of an explicit read barrier and of lazy
forwarding compared to no check at all.

Spur, part of VMMaker.oscog, is implemented by a hierarchy of classes that
implement a 32-bit and a 64-bit memory manager.  Spur is a sibling to the
old ObjectMemory class that implements the V3 object representation.  The
current Spur does "lazy forwarding" where two objects are become by cloning
each object, making the old versions point to the opposite copy, and
relying on send-time checks to lazily follow forwarding pointers when sends
to forwarded objects fail a message lookup.

The project would create two additional variations on Spur, both of which
dispense with the lazy check.  One would explicitly test for a forwarding
pointers on every access, and one would never check, not need send-time
checking either and would reimplement become: like the old ObjectMemory, by
scanning the entire heap to exchange all references.

These variations could be implemented as subclasses or siblings of Spur.
The project isn't trivial because it also means making changes to the JIT,
albeit within its framework for multiple object representations.  Because
this is probably some months' work I can't do it myself but I'm extremely
interested in the results and I think it would make a really good paper,
e.g. for ISMM, or one of the dynamic language workshops.

If what I've said makes any sense at all to any academics out there who are
looking for a challenging but nicely contained and far from open ended
Masters project then please get in touch and we can see if we can take this
any further.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150813/3cb17141/attachment-0002.html>

From pbpublist at gmail.com  Thu Aug 13 15:01:17 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 13 Aug 2015 16:01:17 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CCB3A8.12664.2E45B7@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>
	, <55CBFE2C.3950.28469D6@dnorton.mindspring.com>
	, <1439447380.2388.26.camel@gmail.com>
	<55CCB3A8.12664.2E45B7@dnorton.mindspring.com>
Message-ID: <1439496077.2388.46.camel@gmail.com>

On Thu, 2015-08-13 at 11:11 -0400, Dan Norton wrote:
> On 13 Aug 2015 at 2:29, Phil (list) wrote:
> 
> > Dan,
> > 
> > 
> > On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > > Hi Phil,
> > > 
> > > On Windows 7 with Cuis loaded and idle, Windows Task Manager >
> > Performance reports 0% 
> > > CPU Usage. Memory Usage is 1.28 GB.
> > > 
> > 
> > What does the cpu usage show via World Menu -> Open... -> Process
> > Browser for Morphic?
> > 
> 
> It shows 12%.
> 
> > > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000
> > the report is 24 - 
> > > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > > 
> > 
> > OK, so it's not platform specific poor performance.  If you close
> > the
> > BouncingAtomsMorph and wait for things to settle for a few seconds,
> > what
> > does Process Browser show the Morphic cpu usage as??
> >
> 
> It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to measure absolute as 
> opposed to relative CPU usage seems inaccurate to me. The /difference/ in Process Browser 
> numbers while atoms is running vs not running agree with Win7: 1 - 2%.
> 
> I don't like for something to try to measure its own performance :-) - an independent 
> instrument is preferable IMHO.

True, the external monitoring tools will tend to give you a better
absolute picture as there may be some VM overhead (esp if plugins are
involved) that Process Browser can't see.  However, CPU utilization as
reported by the OS isn't terribly helpful unless you know how many cores
the system has, was anything else active at the time, etc.
ProcessBrowser, while limited, avoids all that since it shows what was
used vs what was available to it. (usually 100/<num cores> % of total
system CPU)  Just seemed to make for a better apples to apples
comparison in this case to see if you are having the same issue re:
Morphic chewing up cycles while otherwise 'idle'.

>  
> > > Cuis 4.2 2449, cogwin 15.22.3370
> > > 
> > >  - Dan
> > > 
> > 
> > Thanks,
> > Phil
> > 
> > > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > > 
> > > > I should also mention that the Morph window is ~ 500x450 and
> > > > #stepTime
> > > > is set to 0 for anyone who wants to try to replicate...
> > > > 
> > > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > > I noticed a while back that something appeared to be going on
> > with
> > > > Cuis
> > > > > drawing performance (at idle on my system Morphic consumes
> > ~20% of
> > > > VM
> > > > > CPU *miniumum* according to ProcessBrowser) and this seems to
> > give
> > > > an
> > > > > indication of what it's currently costing in drawing
> > > > performance...
> > > > > 
> > > > > After seeing the Squeak 5.0 announcement, I was curious to
> > see
> > > > roughly
> > > > > how much of a speed boost we might be able to expect from
> > Spur
> > > > down the
> > > > > road.  So I decided to look at BouncingAtomsMorph to try to
> > get a
> > > > rough
> > > > > apples-to-apples comparison and was quite surprised: Spur
> > was
> > > > faster,
> > > > > but it was too much faster.  So I dropped back to Squeak 4.5
> > and
> > > > it also
> > > > > performs much, much better than the Cuis version on the same
> > VM.  
> > > > Here
> > > > > are the numbers I'm seeing using BouncingAtomsMorph with
> > roughly
> > > > > comparable (i.e. eyeballed) morph sizes and atom count set
> > to
> > > > 5000:
> > > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > > 
> > > > > Granted BouncingAtomsMorph is not 100% identical from a
> > source
> > > > code
> > > > > standpoint but it's not nearly different enough where I'd
> > expect
> > > > that
> > > > > sort of difference.  Is this a platform-specific issue (I'm
> > on
> > > > Linux) or
> > > > > are others noticing drawing issues as well?
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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 dnorton at mindspring.com  Fri Aug 14 11:42:57 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 14 Aug 2015 12:42:57 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439496077.2388.46.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CCB3A8.12664.2E45B7@dnorton.mindspring.com>,
	<1439496077.2388.46.camel@gmail.com>
Message-ID: <55CE1A91.6602.5A1F06@dnorton.mindspring.com>

On 13 Aug 2015 at 16:01, Phil (list) wrote:

> On Thu, 2015-08-13 at 11:11 -0400, Dan Norton wrote:
> > On 13 Aug 2015 at 2:29, Phil (list) wrote:
> > 
> > > Dan,
> > > 
> > > 
> > > On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > > > Hi Phil,
> > > > 
> > > > On Windows 7 with Cuis loaded and idle, Windows Task Manager
> >
> > > Performance reports 0% 
> > > > CPU Usage. Memory Usage is 1.28 GB.
> > > > 
> > > 
> > > What does the cpu usage show via World Menu -> Open... ->
> Process
> > > Browser for Morphic?
> > > 
> > 
> > It shows 12%.
> > 
> > > > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms
> 5000
> > > the report is 24 - 
> > > > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > > > 
> > > 
> > > OK, so it's not platform specific poor performance.  If you
> close
> > > the
> > > BouncingAtomsMorph and wait for things to settle for a few
> seconds,
> > > what
> > > does Process Browser show the Morphic cpu usage as??
> > >
> > 
> > It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to
> measure absolute as 
> > opposed to relative CPU usage seems inaccurate to me. The
> /difference/ in Process Browser 
> > numbers while atoms is running vs not running agree with Win7: 1 -
> 2%.
> > 
> > I don't like for something to try to measure its own performance
> :-) - an independent 
> > instrument is preferable IMHO.
> 
> True, the external monitoring tools will tend to give you a better
> absolute picture as there may be some VM overhead (esp if plugins
> are
> involved) that Process Browser can't see.  However, CPU utilization
> as
> reported by the OS isn't terribly helpful unless you know how many
> cores
> the system has, was anything else active at the time, etc.
> ProcessBrowser, while limited, avoids all that since it shows what
> was
> used vs what was available to it. (usually 100/<num cores> % of
> total
> system CPU)  Just seemed to make for a better apples to apples
> comparison in this case to see if you are having the same issue
> re:
> Morphic chewing up cycles while otherwise 'idle'.
> 

Rummaging around in my system reveals:

Microsoft Windows 7 Home Premium
6.1.7601 Service Pack 1

Intel(R) Core(TM) i3-2125 CPU @
3.30 GHz

All Programs>Accessories>System Tools>Resource Monitor shows:

an appalling (to me, at least) >170 threads "if the only tool you have is a hammer, every 
problem looks like a nail" sitting there quietly for the most part. Resource Monitor shows four 
"CPUs" with CPU 1 and CPU 3 parked. Total CPU usage < 1%.

When Cuis is started, the Squeak.exe starts out with 17 threads, then eventually settles to 6 
threads. Total CPU usage < 1%.

When BouncingAtoms is running, set up as above, CPU 1 and CPU 3 remain parked, CPU 0 
< 5%, and CPU 2 > 95%. Occasionally something (GC?) cranks CPU 0 to 85 - 90% briefly.

When BouncingAtoms is stopped, all return to CPU 0 < 5%, CPU 2 <1%, CPU 1 and CPU 3 
parked.

So, the question is why should Cuis process browser report that Morphic UI is consuming 10 
- 14% ?

> >  
> > > > Cuis 4.2 2449, cogwin 15.22.3370
> > > > 
> > > >  - Dan
> > > > 
> > > 
> > > Thanks,
> > > Phil
> > > 
> > > > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > > > 
> > > > > I should also mention that the Morph window is ~ 500x450
> and
> > > > > #stepTime
> > > > > is set to 0 for anyone who wants to try to replicate...
> > > > > 
> > > > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > > > I noticed a while back that something appeared to be going
> on
> > > with
> > > > > Cuis
> > > > > > drawing performance (at idle on my system Morphic
> consumes
> > > ~20% of
> > > > > VM
> > > > > > CPU *miniumum* according to ProcessBrowser) and this seems
> to
> > > give
> > > > > an
> > > > > > indication of what it's currently costing in drawing
> > > > > performance...
> > > > > > 
> > > > > > After seeing the Squeak 5.0 announcement, I was curious
> to
> > > see
> > > > > roughly
> > > > > > how much of a speed boost we might be able to expect
> from
> > > Spur
> > > > > down the
> > > > > > road.  So I decided to look at BouncingAtomsMorph to try
> to
> > > get a
> > > > > rough
> > > > > > apples-to-apples comparison and was quite surprised:
> Spur
> > > was
> > > > > faster,
> > > > > > but it was too much faster.  So I dropped back to Squeak
> 4.5
> > > and
> > > > > it also
> > > > > > performs much, much better than the Cuis version on the
> same
> > > VM.  
> > > > > Here
> > > > > > are the numbers I'm seeing using BouncingAtomsMorph with
> > > roughly
> > > > > > comparable (i.e. eyeballed) morph sizes and atom count
> set
> > > to
> > > > > 5000:
> > > > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > > > 
> > > > > > Granted BouncingAtomsMorph is not 100% identical from a
> > > source
> > > > > code
> > > > > > standpoint but it's not nearly different enough where
> I'd
> > > expect
> > > > > that
> > > > > > sort of difference.  Is this a platform-specific issue
> (I'm
> > > on
> > > > > Linux) or
> > > > > > are others noticing drawing issues as well?
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > 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 pbpublist at gmail.com  Fri Aug 14 13:50:52 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 14 Aug 2015 14:50:52 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CE1A91.6602.5A1F06@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>
	, <55CCB3A8.12664.2E45B7@dnorton.mindspring.com>
	, <1439496077.2388.46.camel@gmail.com>
	<55CE1A91.6602.5A1F06@dnorton.mindspring.com>
Message-ID: <1439578252.2318.8.camel@gmail.com>

On Fri, 2015-08-14 at 12:42 -0400, Dan Norton wrote:
> On 13 Aug 2015 at 16:01, Phil (list) wrote:
> 
> > On Thu, 2015-08-13 at 11:11 -0400, Dan Norton wrote:
> > > On 13 Aug 2015 at 2:29, Phil (list) wrote:
> > > 
> > > > Dan,
> > > > 
> > > > 
> > > > On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > > > > Hi Phil,
> > > > > 
> > > > > On Windows 7 with Cuis loaded and idle, Windows Task Manager
> > >
> > > > Performance reports 0% 
> > > > > CPU Usage. Memory Usage is 1.28 GB.
> > > > > 
> > > > 
> > > > What does the cpu usage show via World Menu -> Open... ->
> > Process
> > > > Browser for Morphic?
> > > > 
> > > 
> > > It shows 12%.
> > > 
> > > > > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms
> > 5000
> > > > the report is 24 - 
> > > > > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > > > > 
> > > > 
> > > > OK, so it's not platform specific poor performance.  If you
> > close
> > > > the
> > > > BouncingAtomsMorph and wait for things to settle for a few
> > seconds,
> > > > what
> > > > does Process Browser show the Morphic cpu usage as??
> > > >
> > > 
> > > It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to
> > measure absolute as 
> > > opposed to relative CPU usage seems inaccurate to me. The
> > /difference/ in Process Browser 
> > > numbers while atoms is running vs not running agree with Win7: 1 -
> > 2%.
> > > 
> > > I don't like for something to try to measure its own performance
> > :-) - an independent 
> > > instrument is preferable IMHO.
> > 
> > True, the external monitoring tools will tend to give you a better
> > absolute picture as there may be some VM overhead (esp if plugins
> > are
> > involved) that Process Browser can't see.  However, CPU utilization
> > as
> > reported by the OS isn't terribly helpful unless you know how many
> > cores
> > the system has, was anything else active at the time, etc.
> > ProcessBrowser, while limited, avoids all that since it shows what
> > was
> > used vs what was available to it. (usually 100/<num cores> % of
> > total
> > system CPU)  Just seemed to make for a better apples to apples
> > comparison in this case to see if you are having the same issue
> > re:
> > Morphic chewing up cycles while otherwise 'idle'.
> > 
> 
> Rummaging around in my system reveals:
> 
> Microsoft Windows 7 Home Premium
> 6.1.7601 Service Pack 1
> 
> Intel(R) Core(TM) i3-2125 CPU @
> 3.30 GHz
> 
> All Programs>Accessories>System Tools>Resource Monitor shows:
> 
> an appalling (to me, at least) >170 threads "if the only tool you have is a hammer, every 
> problem looks like a nail" sitting there quietly for the most part. Resource Monitor shows four 
> "CPUs" with CPU 1 and CPU 3 parked. Total CPU usage < 1%.
> 

So you've got a dual core processor with hyperthreading (4 logical
cores)...

> When Cuis is started, the Squeak.exe starts out with 17 threads, then eventually settles to 6 
> threads. Total CPU usage < 1%.
> 
> When BouncingAtoms is running, set up as above, CPU 1 and CPU 3 remain parked, CPU 0 
> < 5%, and CPU 2 > 95%. Occasionally something (GC?) cranks CPU 0 to 85 - 90% briefly.
> 
> When BouncingAtoms is stopped, all return to CPU 0 < 5%, CPU 2 <1%, CPU 1 and CPU 3 
> parked.
> 

Given your above processor info, divide the 10-14% (the idle usage
reported by Cuis) by 4 to get what you should roughly be seeing in
overall system CPU utilization (i.e. 2.5-3.5%, assuming not much else is
going on on the system)  Since the Squeak VM is single threaded for
Smalltalk code the most you should ever see when Cuis is fully busy is
~25% CPU utilization (i.e. 100% of a single core)

> So, the question is why should Cuis process browser report that Morphic UI is consuming 10 
> - 14% ?
> 

That is the question and it relates to why BouncingAtomsMorph is
performing so poorly in Cuis vs. Squeak.  Something is going on (even
when Cuis is 'idle')...

> > >  
> > > > > Cuis 4.2 2449, cogwin 15.22.3370
> > > > > 
> > > > >  - Dan
> > > > > 
> > > > 
> > > > Thanks,
> > > > Phil
> > > > 
> > > > > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > > > > 
> > > > > > I should also mention that the Morph window is ~ 500x450
> > and
> > > > > > #stepTime
> > > > > > is set to 0 for anyone who wants to try to replicate...
> > > > > > 
> > > > > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > > > > I noticed a while back that something appeared to be going
> > on
> > > > with
> > > > > > Cuis
> > > > > > > drawing performance (at idle on my system Morphic
> > consumes
> > > > ~20% of
> > > > > > VM
> > > > > > > CPU *miniumum* according to ProcessBrowser) and this seems
> > to
> > > > give
> > > > > > an
> > > > > > > indication of what it's currently costing in drawing
> > > > > > performance...
> > > > > > > 
> > > > > > > After seeing the Squeak 5.0 announcement, I was curious
> > to
> > > > see
> > > > > > roughly
> > > > > > > how much of a speed boost we might be able to expect
> > from
> > > > Spur
> > > > > > down the
> > > > > > > road.  So I decided to look at BouncingAtomsMorph to try
> > to
> > > > get a
> > > > > > rough
> > > > > > > apples-to-apples comparison and was quite surprised:
> > Spur
> > > > was
> > > > > > faster,
> > > > > > > but it was too much faster.  So I dropped back to Squeak
> > 4.5
> > > > and
> > > > > > it also
> > > > > > > performs much, much better than the Cuis version on the
> > same
> > > > VM.  
> > > > > > Here
> > > > > > > are the numbers I'm seeing using BouncingAtomsMorph with
> > > > roughly
> > > > > > > comparable (i.e. eyeballed) morph sizes and atom count
> > set
> > > > to
> > > > > > 5000:
> > > > > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > > > > 
> > > > > > > Granted BouncingAtomsMorph is not 100% identical from a
> > > > source
> > > > > > code
> > > > > > > standpoint but it's not nearly different enough where
> > I'd
> > > > expect
> > > > > > that
> > > > > > > sort of difference.  Is this a platform-specific issue
> > (I'm
> > > > on
> > > > > > Linux) or
> > > > > > > are others noticing drawing issues as well?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > 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
> 
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Sat Aug 15 08:24:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 10:24:01 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439415370.2388.20.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>
Message-ID: <55CF3D71.6040204@jvuletich.org>

Hi Phil,

I won't spoil your fun, so instead of explaining the difference between 
Squeak and Cuis here, I give you a suggestion: Use the profiler.

Cheers,
Juan Vuletich

On 8/12/2015 6:36 PM, Phil (list) wrote:
> I noticed a while back that something appeared to be going on with Cuis
> drawing performance (at idle on my system Morphic consumes ~20% of VM
> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> indication of what it's currently costing in drawing performance...
>
> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> how much of a speed boost we might be able to expect from Spur down the
> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> apples-to-apples comparison and was quite surprised: Spur was faster,
> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> performs much, much better than the Cuis version on the same VM.   Here
> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
>
> Granted BouncingAtomsMorph is not 100% identical from a source code
> standpoint but it's not nearly different enough where I'd expect that
> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> are others noticing drawing issues as well?
>




From juan at jvuletich.org  Sat Aug 15 08:27:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 10:27:34 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CE1A91.6602.5A1F06@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CCB3A8.12664.2E45B7@dnorton.mindspring.com>,
	<1439496077.2388.46.camel@gmail.com>
	<55CE1A91.6602.5A1F06@dnorton.mindspring.com>
Message-ID: <55CF3E46.6020306@jvuletich.org>

The sum of percentages in the Cuis process browser is always 100%. What 
it is measured is how the time spent by the interpreter is split amongst 
Smalltalk processes.

Cheers,
Juan Vuletich

On 8/14/2015 1:42 PM, Dan Norton wrote:
> ...
> When BouncingAtoms is stopped, all return to CPU 0<  5%, CPU 2<1%, CPU 1 and CPU 3
> parked.
>
> So, the question is why should Cuis process browser report that Morphic UI is consuming 10
> - 14% ?




From dnorton at mindspring.com  Sat Aug 15 09:41:34 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 15 Aug 2015 10:41:34 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CF3E46.6020306@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CE1A91.6602.5A1F06@dnorton.mindspring.com>,
	<55CF3E46.6020306@jvuletich.org>
Message-ID: <55CF4F9E.23944.E8610@dnorton.mindspring.com>

Ahh of course. Stared at it but didn't see it :-)

Thanks,
 - Dan

On 15 Aug 2015 at 10:27, Juan Vuletich wrote:

> The sum of percentages in the Cuis process browser is always 100%.
> What 
> it is measured is how the time spent by the interpreter is split
> amongst 
> Smalltalk processes.
> 
> Cheers,
> Juan Vuletich
> 
> On 8/14/2015 1:42 PM, Dan Norton wrote:
> > ...
> > When BouncingAtoms is stopped, all return to CPU 0<  5%, CPU 2<1%,
> CPU 1 and CPU 3
> > parked.
> >
> > So, the question is why should Cuis process browser report that
> Morphic UI is consuming 10
> > - 14% ?
> 





From pbpublist at gmail.com  Sat Aug 15 14:40:34 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 15:40:34 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CF3D71.6040204@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org>
Message-ID: <1439667634.2323.3.camel@gmail.com>

On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> I won't spoil your fun, so instead of explaining the difference between 
> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> 

I will do that right... hey, where did the profiler option go in
ProcessBrowser?  Well, ok, I'll just do it manually with
#spyOnProcess:... grr!  I see it was taken out in 2409.  Now you're just
having fun with me...

> Cheers,
> Juan Vuletich
> 
> On 8/12/2015 6:36 PM, Phil (list) wrote:
> > I noticed a while back that something appeared to be going on with Cuis
> > drawing performance (at idle on my system Morphic consumes ~20% of VM
> > CPU *miniumum* according to ProcessBrowser) and this seems to give an
> > indication of what it's currently costing in drawing performance...
> >
> > After seeing the Squeak 5.0 announcement, I was curious to see roughly
> > how much of a speed boost we might be able to expect from Spur down the
> > road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> > apples-to-apples comparison and was quite surprised: Spur was faster,
> > but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> > performs much, much better than the Cuis version on the same VM.   Here
> > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> >
> > Granted BouncingAtomsMorph is not 100% identical from a source code
> > standpoint but it's not nearly different enough where I'd expect that
> > sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> > are others noticing drawing issues as well?
> >
> 





From juan at jvuletich.org  Sat Aug 15 15:56:36 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 17:56:36 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439667634.2323.3.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>	
	<55CF3D71.6040204@jvuletich.org>
	<1439667634.2323.3.camel@gmail.com>
Message-ID: <55CFA784.7070704@jvuletich.org>

On 8/15/2015 4:40 PM, Phil (list) wrote:
> On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
>> Hi Phil,
>>
>> I won't spoil your fun, so instead of explaining the difference between
>> Squeak and Cuis here, I give you a suggestion: Use the profiler.
>>
> I will do that right... hey, where did the profiler option go in
> ProcessBrowser?  Well, ok, I'll just do it manually with
> #spyOnProcess:... grr!  I see it was taken out in 2409.  Now you're just
> having fun with me...
>

Swear not. Use any of the class methods in the profiler: 
AndreasSystemProfiler. For example, something like

     AndreasSystemProfiler spyForMilliseconds: 200

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Sat Aug 15 15:58:24 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 16:58:24 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CF3D71.6040204@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org>
Message-ID: <1439672304.4789.9.camel@gmail.com>

On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> I won't spoil your fun, so instead of explaining the difference between 
> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> 

Given your comment it sounds like it's by design...

OK, so I reverted to an older build to get back the process-based
profiler and I can see that Cuis is doing a lot more drawing (work) than
Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
tooling to tell me what that work actually is.  What I think I see going
on is that Squeak is using the old region-based damage system while Cuis
appears to just be bit-blitting the entire frame each time? (I'll hold
off jumping up and down for joy until I get confirmation... if that's
what's going on, that is FANTASTIC!)

> Cheers,
> Juan Vuletich
> 
> On 8/12/2015 6:36 PM, Phil (list) wrote:
> > I noticed a while back that something appeared to be going on with Cuis
> > drawing performance (at idle on my system Morphic consumes ~20% of VM
> > CPU *miniumum* according to ProcessBrowser) and this seems to give an
> > indication of what it's currently costing in drawing performance...
> >
> > After seeing the Squeak 5.0 announcement, I was curious to see roughly
> > how much of a speed boost we might be able to expect from Spur down the
> > road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> > apples-to-apples comparison and was quite surprised: Spur was faster,
> > but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> > performs much, much better than the Cuis version on the same VM.   Here
> > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> >
> > Granted BouncingAtomsMorph is not 100% identical from a source code
> > standpoint but it's not nearly different enough where I'd expect that
> > sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> > are others noticing drawing issues as well?
> >
> 





From pbpublist at gmail.com  Sat Aug 15 16:07:44 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 17:07:44 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CFA784.7070704@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org> <1439667634.2323.3.camel@gmail.com>
	<55CFA784.7070704@jvuletich.org>
Message-ID: <1439672864.4789.10.camel@gmail.com>

On Sat, 2015-08-15 at 17:56 -0300, Juan Vuletich wrote:
> On 8/15/2015 4:40 PM, Phil (list) wrote:
> > On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> >> Hi Phil,
> >>
> >> I won't spoil your fun, so instead of explaining the difference between
> >> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> >>
> > I will do that right... hey, where did the profiler option go in
> > ProcessBrowser?  Well, ok, I'll just do it manually with
> > #spyOnProcess:... grr!  I see it was taken out in 2409.  Now you're just
> > having fun with me...
> >
> 
> Swear not. Use any of the class methods in the profiler: 
> AndreasSystemProfiler. For example, something like
> 
>      AndreasSystemProfiler spyForMilliseconds: 200
> 

segfault (stack overflow)...

> Cheers,
> Juan Vuletich





From juan at jvuletich.org  Sat Aug 15 16:39:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 18:39:53 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439672864.4789.10.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>	
	<55CF3D71.6040204@jvuletich.org>
	<1439667634.2323.3.camel@gmail.com>	
	<55CFA784.7070704@jvuletich.org>
	<1439672864.4789.10.camel@gmail.com>
Message-ID: <55CFB1A9.7050402@jvuletich.org>

On 8/15/2015 6:07 PM, Phil (list) wrote:
>
>> Swear not. Use any of the class methods in the profiler:
>> AndreasSystemProfiler. For example, something like
>>
>>       AndreasSystemProfiler spyForMilliseconds: 200
>>
> segfault (stack overflow)...
>

Use Cog 3370 or older. I reported the problem in VM-Dev, but nobody 
listened.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Aug 15 16:41:59 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 18:41:59 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439672304.4789.9.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>	
	<55CF3D71.6040204@jvuletich.org>
	<1439672304.4789.9.camel@gmail.com>
Message-ID: <55CFB227.9000806@jvuletich.org>

On 8/15/2015 5:58 PM, Phil (list) wrote:
> On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
>> Hi Phil,
>>
>> I won't spoil your fun, so instead of explaining the difference between
>> Squeak and Cuis here, I give you a suggestion: Use the profiler.
>>
> Given your comment it sounds like it's by design...
>
> OK, so I reverted to an older build to get back the process-based
> profiler and I can see that Cuis is doing a lot more drawing (work) than
> Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
> tooling to tell me what that work actually is.  What I think I see going
> on is that Squeak is using the old region-based damage system while Cuis
> appears to just be bit-blitting the entire frame each time? (I'll hold
> off jumping up and down for joy until I get confirmation... if that's
> what's going on, that is FANTASTIC!)
>

C'mon! Isn't it obvious in the profiler tree that the problem is using 
local coordinates and transforming them on each draw?

It is possible to optimize it back. It just requires some work.

Cheers,
Juan Vuletich

>> Cheers,
>> Juan Vuletich
>>
>> On 8/12/2015 6:36 PM, Phil (list) wrote:
>>> I noticed a while back that something appeared to be going on with Cuis
>>> drawing performance (at idle on my system Morphic consumes ~20% of VM
>>> CPU *miniumum* according to ProcessBrowser) and this seems to give an
>>> indication of what it's currently costing in drawing performance...
>>>
>>> After seeing the Squeak 5.0 announcement, I was curious to see roughly
>>> how much of a speed boost we might be able to expect from Spur down the
>>> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
>>> apples-to-apples comparison and was quite surprised: Spur was faster,
>>> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
>>> performs much, much better than the Cuis version on the same VM.   Here
>>> are the numbers I'm seeing using BouncingAtomsMorph with roughly
>>> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
>>> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
>>> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
>>> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
>>>
>>> Granted BouncingAtomsMorph is not 100% identical from a source code
>>> standpoint but it's not nearly different enough where I'd expect that
>>> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
>>> are others noticing drawing issues as well?
>>>
>
>




From pbpublist at gmail.com  Sat Aug 15 21:55:43 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 22:55:43 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CFB227.9000806@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org> <1439672304.4789.9.camel@gmail.com>
	<55CFB227.9000806@jvuletich.org>
Message-ID: <1439693743.2401.15.camel@gmail.com>

On Sat, 2015-08-15 at 18:41 -0300, Juan Vuletich wrote:
> On 8/15/2015 5:58 PM, Phil (list) wrote:
> > On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> >> Hi Phil,
> >>
> >> I won't spoil your fun, so instead of explaining the difference between
> >> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> >>
> > Given your comment it sounds like it's by design...
> >
> > OK, so I reverted to an older build to get back the process-based
> > profiler and I can see that Cuis is doing a lot more drawing (work) than
> > Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
> > tooling to tell me what that work actually is.  What I think I see going
> > on is that Squeak is using the old region-based damage system while Cuis
> > appears to just be bit-blitting the entire frame each time? (I'll hold
> > off jumping up and down for joy until I get confirmation... if that's
> > what's going on, that is FANTASTIC!)
> >
> 
> C'mon! Isn't it obvious in the profiler tree that the problem is using 
> local coordinates and transforming them on each draw?
> 

In the old profiler output (I went back to 2404 to get it), it didn't
jump out at me (the bounds related calls only appear to be <10% of the
time)  It could just be that I'm more dense than usual :-)

I can definitely see how that could cause a problem doing 1000s of local
to global conversions per frame...

> It is possible to optimize it back. It just requires some work.
> 

Fair enough... but I still think that things are generally off
performance-wise with Morphic... (it might just be that we've got a
bunch of fairly unoptimized code similar to what's going on with
BouncingAtomsMorph that will take some time to work through, but things
are definitely feeling slow-ish from a UI standpoint)

> Cheers,
> Juan Vuletich
> 
> >> Cheers,
> >> Juan Vuletich
> >>
> >> On 8/12/2015 6:36 PM, Phil (list) wrote:
> >>> I noticed a while back that something appeared to be going on with Cuis
> >>> drawing performance (at idle on my system Morphic consumes ~20% of VM
> >>> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> >>> indication of what it's currently costing in drawing performance...
> >>>
> >>> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> >>> how much of a speed boost we might be able to expect from Spur down the
> >>> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> >>> apples-to-apples comparison and was quite surprised: Spur was faster,
> >>> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> >>> performs much, much better than the Cuis version on the same VM.   Here
> >>> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> >>> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> >>> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> >>> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> >>> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> >>>
> >>> Granted BouncingAtomsMorph is not 100% identical from a source code
> >>> standpoint but it's not nearly different enough where I'd expect that
> >>> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> >>> are others noticing drawing issues as well?
> >>>
> >
> >
> 





From pbpublist at gmail.com  Sun Aug 16 03:11:10 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 04:11:10 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439693743.2401.15.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org> <1439672304.4789.9.camel@gmail.com>
	<55CFB227.9000806@jvuletich.org> <1439693743.2401.15.camel@gmail.com>
Message-ID: <1439712670.2401.23.camel@gmail.com>

On Sat, 2015-08-15 at 22:55 -0400, Phil (list) wrote:
> On Sat, 2015-08-15 at 18:41 -0300, Juan Vuletich wrote:
> > On 8/15/2015 5:58 PM, Phil (list) wrote:
> > > On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> > >> Hi Phil,
> > >>
> > >> I won't spoil your fun, so instead of explaining the difference between
> > >> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> > >>
> > > Given your comment it sounds like it's by design...
> > >
> > > OK, so I reverted to an older build to get back the process-based
> > > profiler and I can see that Cuis is doing a lot more drawing (work) than
> > > Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
> > > tooling to tell me what that work actually is.  What I think I see going
> > > on is that Squeak is using the old region-based damage system while Cuis
> > > appears to just be bit-blitting the entire frame each time? (I'll hold
> > > off jumping up and down for joy until I get confirmation... if that's
> > > what's going on, that is FANTASTIC!)
> > >
> > 
> > C'mon! Isn't it obvious in the profiler tree that the problem is using 
> > local coordinates and transforming them on each draw?
> > 
> 
> In the old profiler output (I went back to 2404 to get it), it didn't
> jump out at me (the bounds related calls only appear to be <10% of the
> time)  It could just be that I'm more dense than usual :-)
> 

'More dense than usual' it is:  I forgot to ratchet up the atom count
when I got profiling going.  *Then* the local/global conversions start
to dominate.  (The only reason I cranked them up that high originally
was to get some FPS distance between the Cog and Spur Squeak runs.  At
lower atom counts where drawing dominates, Cuis is still significantly
slower than Squeak running on Cog)

> I can definitely see how that could cause a problem doing 1000s of local
> to global conversions per frame...
> 
> > It is possible to optimize it back. It just requires some work.
> > 
> 
> Fair enough... but I still think that things are generally off
> performance-wise with Morphic... (it might just be that we've got a
> bunch of fairly unoptimized code similar to what's going on with
> BouncingAtomsMorph that will take some time to work through, but things
> are definitely feeling slow-ish from a UI standpoint)
> 
> > Cheers,
> > Juan Vuletich
> > 
> > >> Cheers,
> > >> Juan Vuletich
> > >>
> > >> On 8/12/2015 6:36 PM, Phil (list) wrote:
> > >>> I noticed a while back that something appeared to be going on with Cuis
> > >>> drawing performance (at idle on my system Morphic consumes ~20% of VM
> > >>> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> > >>> indication of what it's currently costing in drawing performance...
> > >>>
> > >>> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> > >>> how much of a speed boost we might be able to expect from Spur down the
> > >>> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> > >>> apples-to-apples comparison and was quite surprised: Spur was faster,
> > >>> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> > >>> performs much, much better than the Cuis version on the same VM.   Here
> > >>> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > >>> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> > >>> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > >>> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > >>> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > >>>
> > >>> Granted BouncingAtomsMorph is not 100% identical from a source code
> > >>> standpoint but it's not nearly different enough where I'd expect that
> > >>> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> > >>> are others noticing drawing issues as well?
> > >>>
> > >
> > >
> > 
> 





From juan at jvuletich.org  Sun Aug 16 10:08:04 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 16 Aug 2015 12:08:04 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph performance
Message-ID: <55D0A754.2070602@jvuletich.org>

Hi Folks,

Yesterday and today I pushed new stuff to github. See the attach. Cuis 
can now display both underscores and left arrows in the same method!

I also could not help it and worked on BouncingAtomsMorph performance. 
It should be close to Squeak now.

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis_underscores.png
Type: image/png
Size: 56056 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150816/60ccc446/attachment-0002.png>

From dnorton at mindspring.com  Sun Aug 16 13:02:24 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 14:02:24 -0400
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <55D0D030.28083.B5F605@dnorton.mindspring.com>

On 16 Aug 2015 at 12:08, Juan Vuletich wrote:

> Hi Folks,
> 
> Yesterday and today I pushed new stuff to github. See the attach.
> Cuis 
> can now display both underscores and left arrows in the same
> method!
> 
> I also could not help it and worked on BouncingAtomsMorph
> performance. 
> It should be close to Squeak now.
> 

No, it's faster. Much faster than Squeak in a side-by-side comparison.

 - Dan



From dnorton at mindspring.com  Sun Aug 16 13:33:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 14:33:56 -0400
Subject: [Cuis] Problem in VM-Dev
Message-ID: <55D0D794.31157.D2D674@dnorton.mindspring.com>

Hi Juan,

On 8/15/2015 Juan wrote: 
>On 8/15/2015 6:07 PM, Phil (list) wrote: 
>>
>>> Swear not. Use any of the class methods in the profiler: 
>>> AndreasSystemProfiler. For example, something like 
>>>
>>> AndreasSystemProfiler spyForMilliseconds: 200 
>>>
>> segfault (stack overflow)... 
>>
>
>Use Cog 3370 or older. I reported the problem in VM-Dev, but nobody 
listened. 

I don't see where you reported the problem. Can you give me a specific reference? Maybe if 
more of us post it will get some attention. I searched

gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 

for your posts in 2015 but did not see it.

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

From pbpublist at gmail.com  Sun Aug 16 13:44:22 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 14:44:22 -0400
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <1439750662.16738.6.camel@gmail.com>

On Sun, 2015-08-16 at 12:08 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> Yesterday and today I pushed new stuff to github. See the attach. Cuis 
> can now display both underscores and left arrows in the same method!
> 
> I also could not help it and worked on BouncingAtomsMorph performance. 
> It should be close to Squeak now.

It's definitely improved BouncingAtomsMorph (I'm seeing at least 13-17
FPS now.. I say 'at least' because from time to time it jumps up to the
low 20's).  But more importantly (to me, at least) at first glance it
looks like these changes provide an across the board performance boost
to my other Morphic code. (most of my stuff doesn't have FPS counters
but in looking at Morphic CPU utilization in ProcessBrowser, it's almost
always 5-10% lower now)

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





From pbpublist at gmail.com  Sun Aug 16 13:48:36 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 14:48:36 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <55D0D794.31157.D2D674@dnorton.mindspring.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>
Message-ID: <1439750916.16738.10.camel@gmail.com>

On Sun, 2015-08-16 at 14:33 -0400, Dan Norton wrote:
> Hi Juan,
> 
> 
> On 8/15/2015 Juan wrote: 
> >On 8/15/2015 6:07 PM, Phil (list) wrote: 
> >>
> >>> Swear not. Use any of the class methods in the profiler: 
> >>> AndreasSystemProfiler. For example, something like 
> >>>
> >>> AndreasSystemProfiler spyForMilliseconds: 200 
> >>>
> >> segfault (stack overflow)... 
> >>
> >
> >Use Cog 3370 or older. I reported the problem in VM-Dev, but nobody 
> listened. 
> 
> 
> 
> I don't see where you reported the problem. Can you give me a specific
> reference? Maybe if more of us post it will get some attention. I
> searched
> 
> 
I just posted a reply to it a few hours ago hoping for the same effect.
His original posts were on 7/20 and had 'Cog crash with
AndreasSystemProfiler' in the subject line.

On a related note, I'm having an issue with 3410 hanging the image while
loading packages while 3390 is working (aside from the profiler issue)
for me... it's always something.

> gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 
> 
> 
> 
> for your posts in 2015 but did not see it.
> 
> 
>  - Dan
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Sun Aug 16 15:58:03 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 16:58:03 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <1439750916.16738.10.camel@gmail.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>,
	<1439750916.16738.10.camel@gmail.com>
Message-ID: <55D0F95B.20890.156C93E@dnorton.mindspring.com>

Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following 30+ times successfully:

	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159 printString]].

Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+ times and the VM 
crashed with a stack exception. Dump attached.

Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the following 40+ times 
successfully:

	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].

What is the difference between AndreasSystemProfiler and MessageTally? Their output 
appears similar.

 - Dan

On 16 Aug 2015 at 14:48, Phil (list) wrote:

> On Sun, 2015-08-16 at 14:33 -0400, Dan Norton wrote:
> > Hi Juan,
> > 
> > 
> > On 8/15/2015 Juan wrote: 
> > >On 8/15/2015 6:07 PM, Phil (list) wrote: 
> > >>
> > >>> Swear not. Use any of the class methods in the profiler: 
> > >>> AndreasSystemProfiler. For example, something like 
> > >>>
> > >>> AndreasSystemProfiler spyForMilliseconds: 200 
> > >>>
> > >> segfault (stack overflow)... 
> > >>
> > >
> > >Use Cog 3370 or older. I reported the problem in VM-Dev, but
> nobody 
> > listened. 
> > 
> > 
> > 
> > I don't see where you reported the problem. Can you give me a
> specific
> > reference? Maybe if more of us post it will get some attention.
> I
> > searched
> > 
> > 
> I just posted a reply to it a few hours ago hoping for the same
> effect.
> His original posts were on 7/20 and had 'Cog crash with
> AndreasSystemProfiler' in the subject line.
> 
> On a related note, I'm having an issue with 3410 hanging the image
> while
> loading packages while 3390 is working (aside from the profiler
> issue)
> for me... it's always something.
> 
> > gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 
> > 
> > 
> > 
> > for your posts in 2015 but did not see it.
> > 
> > 
> >  - 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProfilerCrash.zip
Type: application/zip
Size: 3325 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150816/00fbdcd8/attachment-0002.zip>

From pbpublist at gmail.com  Sun Aug 16 16:21:12 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 17:21:12 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <55D0F95B.20890.156C93E@dnorton.mindspring.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>
	, <1439750916.16738.10.camel@gmail.com>
	<55D0F95B.20890.156C93E@dnorton.mindspring.com>
Message-ID: <1439760072.16738.23.camel@gmail.com>

On Sun, 2015-08-16 at 16:58 -0400, Dan Norton wrote:
> Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following 30+ times successfully:
> 
> 	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159 printString]].
> 
> Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+ times and the VM 
> crashed with a stack exception. Dump attached.
> 
> Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the following 40+ times 
> successfully:
> 
> 	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].
> 
> What is the difference between AndreasSystemProfiler and MessageTally? Their output 
> appears similar.

They perform the same function but ASP is more accurate (esp related to
primitives) and capable of higher resolution.  Here's a write up by
Eliot back when it was originally released:
http://forum.world.st/Re-squeak-dev-AndreasSystemProfiler-Released-MIT-td4665183.html

> 
>  - Dan
> 
> On 16 Aug 2015 at 14:48, Phil (list) wrote:
> 
> > On Sun, 2015-08-16 at 14:33 -0400, Dan Norton wrote:
> > > Hi Juan,
> > > 
> > > 
> > > On 8/15/2015 Juan wrote: 
> > > >On 8/15/2015 6:07 PM, Phil (list) wrote: 
> > > >>
> > > >>> Swear not. Use any of the class methods in the profiler: 
> > > >>> AndreasSystemProfiler. For example, something like 
> > > >>>
> > > >>> AndreasSystemProfiler spyForMilliseconds: 200 
> > > >>>
> > > >> segfault (stack overflow)... 
> > > >>
> > > >
> > > >Use Cog 3370 or older. I reported the problem in VM-Dev, but
> > nobody 
> > > listened. 
> > > 
> > > 
> > > 
> > > I don't see where you reported the problem. Can you give me a
> > specific
> > > reference? Maybe if more of us post it will get some attention.
> > I
> > > searched
> > > 
> > > 
> > I just posted a reply to it a few hours ago hoping for the same
> > effect.
> > His original posts were on 7/20 and had 'Cog crash with
> > AndreasSystemProfiler' in the subject line.
> > 
> > On a related note, I'm having an issue with 3410 hanging the image
> > while
> > loading packages while 3390 is working (aside from the profiler
> > issue)
> > for me... it's always something.
> > 
> > > gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 
> > > 
> > > 
> > > 
> > > for your posts in 2015 but did not see it.
> > > 
> > > 
> > >  - 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
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Sun Aug 16 17:09:42 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 18:09:42 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <1439760072.16738.23.camel@gmail.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>,
	<55D0F95B.20890.156C93E@dnorton.mindspring.com>,
	<1439760072.16738.23.camel@gmail.com>
Message-ID: <55D10A26.3277.1986224@dnorton.mindspring.com>

On 16 Aug 2015 at 17:21, Phil (list) wrote:

> On Sun, 2015-08-16 at 16:58 -0400, Dan Norton wrote:
> > Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following
> 30+ times successfully:
> > 
> > 	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159
> printString]].
> > 
> > Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+
> times and the VM 
> > crashed with a stack exception. Dump attached.
> > 
> > Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the
> following 40+ times 
> > successfully:
> > 
> > 	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].
> > 
> > What is the difference between AndreasSystemProfiler and
> MessageTally? Their output 
> > appears similar.
> 
> They perform the same function but ASP is more accurate (esp related
> to
> primitives) and capable of higher resolution.  Here's a write up
> by
> Eliot back when it was originally released:
> http://forum.world.st/Re-squeak-dev-AndreasSystemProfiler-Released-M
> IT-td4665183.html
> 

There is a 2015-01-27 version which preceeds the latest. Would that be worth a try?

 - Dan



From pbpublist at gmail.com  Sun Aug 16 17:41:14 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 18:41:14 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <55D10A26.3277.1986224@dnorton.mindspring.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>
	, <55D0F95B.20890.156C93E@dnorton.mindspring.com>
	, <1439760072.16738.23.camel@gmail.com>
	<55D10A26.3277.1986224@dnorton.mindspring.com>
Message-ID: <1439764874.16738.26.camel@gmail.com>

On Sun, 2015-08-16 at 18:09 -0400, Dan Norton wrote:
> On 16 Aug 2015 at 17:21, Phil (list) wrote:
> 
> > On Sun, 2015-08-16 at 16:58 -0400, Dan Norton wrote:
> > > Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following
> > 30+ times successfully:
> > > 
> > > 	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159
> > printString]].
> > > 
> > > Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+
> > times and the VM 
> > > crashed with a stack exception. Dump attached.
> > > 
> > > Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the
> > following 40+ times 
> > > successfully:
> > > 
> > > 	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].
> > > 
> > > What is the difference between AndreasSystemProfiler and
> > MessageTally? Their output 
> > > appears similar.
> > 
> > They perform the same function but ASP is more accurate (esp related
> > to
> > primitives) and capable of higher resolution.  Here's a write up
> > by
> > Eliot back when it was originally released:
> > http://forum.world.st/Re-squeak-dev-AndreasSystemProfiler-Released-M
> > IT-td4665183.html
> > 
> 
> There is a 2015-01-27 version which preceeds the latest. Would that be worth a try?
> 

Eliot just posted a reply today indicating this bug is on his radar so
it will probably be fixed soon.

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





From Ken.Dickey at whidbey.com  Sun Aug 16 21:11:21 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sun, 16 Aug 2015 19:11:21 -0700
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>

2461 TaskBar seems to lose collapsed morphs.

World >> New Morph >> <whatever>

Then collapse <whatever>.

Works OK with a Browser.  Leaves space to display the TaskBar buttons, but they do not show up (except for the browser).

Something about Morphs.

??
-KenD




From dnorton at mindspring.com  Mon Aug 17 10:14:51 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 17 Aug 2015 08:14:51 -0700 (PDT)
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>
References: <55D0A754.2070602@jvuletich.org>
	<20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>
Message-ID: <1439824491018-4843553.post@n4.nabble.com>

Similar observation here, except that browsers, workspaces, and transcripts
don't appear; other stuff does appear. However, everything is there in
Windows...>find window.

 - Dan



--
View this message in context: http://forum.world.st/Updates-Smart-underscores-BouncingAtomsMorph-performance-tp4843287p4843553.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From juan at jvuletich.org  Mon Aug 17 15:53:48 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 17:53:48 -0300
Subject: [Cuis] Updates: Smart underscores &
	BouncingAtomsMorph	performance
In-Reply-To: <55D0D030.28083.B5F605@dnorton.mindspring.com>
References: <55D0A754.2070602@jvuletich.org>
	<55D0D030.28083.B5F605@dnorton.mindspring.com>
Message-ID: <55D249DC.4020807@jvuletich.org>

On 8/16/2015 3:02 PM, Dan Norton wrote:
> On 16 Aug 2015 at 12:08, Juan Vuletich wrote:
>
>> Hi Folks,
>>
>> Yesterday and today I pushed new stuff to github. See the attach.
>> Cuis
>> can now display both underscores and left arrows in the same
>> method!
>>
>> I also could not help it and worked on BouncingAtomsMorph
>> performance.
>> It should be close to Squeak now.
>>
> No, it's faster. Much faster than Squeak in a side-by-side comparison.
>
>   - Dan
>

Nice!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 17 15:55:36 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 17:55:36 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <1439750662.16738.6.camel@gmail.com>
References: <55D0A754.2070602@jvuletich.org>
	<1439750662.16738.6.camel@gmail.com>
Message-ID: <55D24A48.1060800@jvuletich.org>

On 8/16/2015 3:44 PM, Phil (list) wrote:
> On Sun, 2015-08-16 at 12:08 -0300, Juan Vuletich wrote:
>> Hi Folks,
>>
>> Yesterday and today I pushed new stuff to github. See the attach. Cuis
>> can now display both underscores and left arrows in the same method!
>>
>> I also could not help it and worked on BouncingAtomsMorph performance.
>> It should be close to Squeak now.
> It's definitely improved BouncingAtomsMorph (I'm seeing at least 13-17
> FPS now.. I say 'at least' because from time to time it jumps up to the
> low 20's).  But more importantly (to me, at least) at first glance it
> looks like these changes provide an across the board performance boost
> to my other Morphic code. (most of my stuff doesn't have FPS counters
> but in looking at Morphic CPU utilization in ProcessBrowser, it's almost
> always 5-10% lower now)
>

Yes, that sounds reasonable. Most of the code I optimized is quite 
general. This example was useful, because it was concrete enough to run 
the profiler and get consistent results. It is quite easy to optimize 
code if you know _where_ is the problem!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 17 15:56:57 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 17:56:57 -0300
Subject: [Cuis] Updates: Smart underscores &
	BouncingAtomsMorph	performance
In-Reply-To: <1439824491018-4843553.post@n4.nabble.com>
References: <55D0A754.2070602@jvuletich.org>	<20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>
	<1439824491018-4843553.post@n4.nabble.com>
Message-ID: <55D24A99.3050404@jvuletich.org>

On 8/17/2015 12:14 PM, Dan Norton wrote:
> Similar observation here, except that browsers, workspaces, and transcripts
> don't appear; other stuff does appear. However, everything is there in
> Windows...>find window.
>
>   - Dan

Yes. I introduced a bug in the recent Morphic optimizations. I fixed it 
now. Fortunately, fixed code is both simpler and slightly faster than 
the old code.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 17 16:00:32 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 18:00:32 -0300
Subject: [Cuis] more updates
Message-ID: <55D24B70.3030406@jvuletich.org>

Hi Folks,

I fixed the Taskbar bug I introduced yesterday. Thanks for reporting!

I also added a new folder for optional fonts data. Right now it contains 
several sizes of DejaVu Sans Mono, but we can add there any other font 
you find desirable (if it has a good license). Doing

StrikeFont install: 'DejaVu Sans Mono'

loads it.

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

From juan at jvuletich.org  Mon Aug 17 16:04:45 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 18:04:45 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <55D24C6D.6090500@jvuletich.org>

On 8/16/2015 12:08 PM, Juan Vuletich wrote:
> Hi Folks,
>
> Yesterday and today I pushed new stuff to github. See the attach. Cuis 
> can now display both underscores and left arrows in the same method!
>
> I also could not help it and worked on BouncingAtomsMorph performance. 
> It should be close to Squeak now.
>
> Cheers,
> Juan Vuletich

I'm a bit surprised nobody commented on the attach. I'm quite happy 
about not having to give up our traditional assignment symbol, and at 
the same time, handle and display correctly underscores in names. These 
are sometimes useful when dealing with external code and stuff. I won't 
deny it, I'm also a bit proud of the idea to make it possible. Looking 
at the screenshot, doesn't it make you think "how the hell did he do it?" ?

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis_underscores.png
Type: image/png
Size: 56056 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150817/a271fcf9/attachment-0002.png>

From juan at jvuletich.org  Mon Aug 17 16:17:48 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 18:17:48 -0300
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <1439764874.16738.26.camel@gmail.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>	,
	<55D0F95B.20890.156C93E@dnorton.mindspring.com>	,
	<1439760072.16738.23.camel@gmail.com>	<55D10A26.3277.1986224@dnorton.mindspring.com>
	<1439764874.16738.26.camel@gmail.com>
Message-ID: <55D24F7C.7030909@jvuletich.org>

Yay!

Cheers,
Juan Vuletich

On 8/16/2015 7:41 PM, Phil (list) wrote:
>
> Eliot just posted a reply today indicating this bug is on his radar so
> it will probably be fixed soon.




From lewis at mail.msen.com  Mon Aug 17 16:34:56 2015
From: lewis at mail.msen.com (David T. Lewis)
Date: Mon, 17 Aug 2015 17:34:56 -0400 (EDT)
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D24C6D.6090500@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
Message-ID: <47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>

> On 8/16/2015 12:08 PM, Juan Vuletich wrote:
>> Hi Folks,
>>
>> Yesterday and today I pushed new stuff to github. See the attach. Cuis
>> can now display both underscores and left arrows in the same method!
>>
>> I also could not help it and worked on BouncingAtomsMorph performance.
>> It should be close to Squeak now.
>>
>> Cheers,
>> Juan Vuletich
>
> I'm a bit surprised nobody commented on the attach. I'm quite happy
> about not having to give up our traditional assignment symbol, and at
> the same time, handle and display correctly underscores in names. These
> are sometimes useful when dealing with external code and stuff. I won't
> deny it, I'm also a bit proud of the idea to make it possible. Looking
> at the screenshot, doesn't it make you think "how the hell did he do it?"
> ?

Well, that's what *I* was wondering. So how did you do that???

:-)

Dave








From pbpublist at gmail.com  Mon Aug 17 18:09:15 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 17 Aug 2015 19:09:15 -0400
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D24C6D.6090500@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
Message-ID: <1439852955.16738.31.camel@gmail.com>

On Mon, 2015-08-17 at 18:04 -0300, Juan Vuletich wrote:
> On 8/16/2015 12:08 PM, Juan Vuletich wrote:
> > Hi Folks,
> >
> > Yesterday and today I pushed new stuff to github. See the attach. Cuis 
> > can now display both underscores and left arrows in the same method!
> >
> > I also could not help it and worked on BouncingAtomsMorph performance. 
> > It should be close to Squeak now.
> >
> > Cheers,
> > Juan Vuletich
> 
> I'm a bit surprised nobody commented on the attach. I'm quite happy 
> about not having to give up our traditional assignment symbol, and at 
> the same time, handle and display correctly underscores in names. These 
> are sometimes useful when dealing with external code and stuff. I won't 
> deny it, I'm also a bit proud of the idea to make it possible. Looking 
> at the screenshot, doesn't it make you think "how the hell did he do it?" ?
> 

You packed too much goodness into one post!  I was so occupied with the
Morphic part, the underscore part didn't even register... very nice job!
This has actually been one of my ongoing issues with the use of arrow
assignments so now I can leave them enabled.  So, how the hell did you
do it? :-)

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





From avalloud at smalltalk.comcastbiz.net  Tue Aug 18 19:55:14 2015
From: avalloud at smalltalk.comcastbiz.net (Andres Valloud)
Date: Tue, 18 Aug 2015 17:55:14 -0700
Subject: [Cuis] [Smalltalks 2015] --- Invitation
Message-ID: <55D3D3F2.50607@smalltalk.comcastbiz.net>

The Fundaci?n Argentina de Smalltalk proudly invites you to one of the 
premier Smalltalk conferences in the world.  Let's meet at Buenos Aires, 
November 11-13!  For more details, see the invitation here:

http://www.fast.org.ar/Smalltalks2015-invitation.pdf




From juan at jvuletich.org  Wed Aug 19 07:51:06 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 19 Aug 2015 09:51:06 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
	<47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>
Message-ID: <55D47BBA.3060805@jvuletich.org>

On 8/17/2015 6:34 PM, David T. Lewis wrote:
>>
>> I'm a bit surprised nobody commented on the attach. I'm quite happy
>> about not having to give up our traditional assignment symbol, and at
>> the same time, handle and display correctly underscores in names. These
>> are sometimes useful when dealing with external code and stuff. I won't
>> deny it, I'm also a bit proud of the idea to make it possible. Looking
>> at the screenshot, doesn't it make you think "how the hell did he do it?"
>> ?
> Well, that's what *I* was wondering. So how did you do that???
>
> :-)
>
> Dave
>

Well, the first idea was that it given that a StrikeFont can already 
swap glyphs (#useUnderscores, #useLeftArrow), then it is possible to 
build cheap derivative fonts that do that, and TextStyles for them. 
Then, Shout parses code and sets TextEmphasis like italics or colors for 
differenc code elements. I just made it set a TextEmphasis with 
underscores for identifiers.

It is so simple that I find it surprising that nobody (including me) 
thought about this years ago!

Cheers,
Juan Vuletich



From lewis at mail.msen.com  Wed Aug 19 11:56:22 2015
From: lewis at mail.msen.com (David T. Lewis)
Date: Wed, 19 Aug 2015 12:56:22 -0400 (EDT)
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D47BBA.3060805@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
	<47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>
	<55D47BBA.3060805@jvuletich.org>
Message-ID: <37162.136.2.1.102.1440003382.squirrel@webmail.msen.com>

Juan,

I hope you don't mind if I CC squeak-dev.

> On 8/17/2015 6:34 PM, David T. Lewis wrote:
>>>
>>> I'm a bit surprised nobody commented on the attach. I'm quite happy
>>> about not having to give up our traditional assignment symbol, and at
>>> the same time, handle and display correctly underscores in names. These
>>> are sometimes useful when dealing with external code and stuff. I won't
>>> deny it, I'm also a bit proud of the idea to make it possible. Looking
>>> at the screenshot, doesn't it make you think "how the hell did he do
>>> it?"
>>> ?
>> Well, that's what *I* was wondering. So how did you do that???
>>
>> :-)
>>
>> Dave
>>
>
> Well, the first idea was that it given that a StrikeFont can already
> swap glyphs (#useUnderscores, #useLeftArrow), then it is possible to
> build cheap derivative fonts that do that, and TextStyles for them.
> Then, Shout parses code and sets TextEmphasis like italics or colors for
> differenc code elements. I just made it set a TextEmphasis with
> underscores for identifiers.
>
> It is so simple that I find it surprising that nobody (including me)
> thought about this years ago!
>
> Cheers,
> Juan Vuletich
>

What a great idea!

Dave






From ume at blueplane.jp  Wed Aug 19 20:35:28 2015
From: ume at blueplane.jp (Masashi UMEZAWA)
Date: Thu, 20 Aug 2015 10:35:28 +0900
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: <CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>

Hi all,

Sorry for the late reply. I've missed the mail...

As I recall, I have deliberately selected not using Exceptions mainly
for portability.

Actually there are various non-existent-file exceptions -
FileDoesNotExist (Squeak), FileDoesNotExistException (Pharo),
OSErrorHolder nonexistentSignal (VW).

Originally old FileMan did not have exception wrappers, but it has
now. So I think it is a good time to introduce exception-aware APIs.

How about adding tryReadStream series?

[ readStream := 'foo.txt' asFileEntry tryReadStream ] on:
FmFileIOAccessor fileDoesNotExistException do: [:ex | ].

readStream := 'foo.txt' asFileEntry tryReadStreamIfError: [:ex | ].

Best regards,

2015-07-27 23:58 GMT+09:00 Juan Vuletich <juan at 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
>>>>>
>>>>>
>>>>
>>
>>
>

-- 
[:masashi | ^umezawa]



From juan at jvuletich.org  Thu Aug 20 08:52:42 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 20 Aug 2015 10:52:42 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <37162.136.2.1.102.1440003382.squirrel@webmail.msen.com>
References: <55D0A754.2070602@jvuletich.org>
	<55D24C6D.6090500@jvuletich.org>	<47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>	<55D47BBA.3060805@jvuletich.org>
	<37162.136.2.1.102.1440003382.squirrel@webmail.msen.com>
Message-ID: <55D5DBAA.7090100@jvuletich.org>

Of course not! It would be very nice to see this done in Squeak and 
Pharo too.

Cheers,
Juan Vuletich

> Juan,
>
> I hope you don't mind if I CC squeak-dev.
>
> What a great idea!
>
> Dave
>



From juan at jvuletich.org  Thu Aug 20 09:01:40 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 20 Aug 2015 11:01:40 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@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>
	<55B64713.8040806@jvuletich.org>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
Message-ID: <55D5DDC4.9030101@jvuletich.org>

Hi Masashi,

> Hi all,
>
> Sorry for the late reply. I've missed the mail...
>
> As I recall, I have deliberately selected not using Exceptions mainly
> for portability.
>
> Actually there are various non-existent-file exceptions -
> FileDoesNotExist (Squeak), FileDoesNotExistException (Pharo),
> OSErrorHolder nonexistentSignal (VW).
>
> Originally old FileMan did not have exception wrappers, but it has
> now. So I think it is a good time to introduce exception-aware APIs.
>
> How about adding tryReadStream series?
>
> [ readStream := 'foo.txt' asFileEntry tryReadStream ] on:
> FmFileIOAccessor fileDoesNotExistException do: [:ex | ].
>
> readStream := 'foo.txt' asFileEntry tryReadStreamIfError: [:ex | ].
>
> Best regards,

Thanks for your support.

I guess I would prefer #readStream for the basic, raising exceptions 
api, and maybe #readStreamNoFail or #readStreamOrEmpty or such for the 
"exception eating api" . In any case it is your call, I understand there 
is back compatibility to care about, and I'll be happy with your choice.

Cheers,
Juan Vuletich

> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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 ume at blueplane.jp  Sat Aug 22 08:15:43 2015
From: ume at blueplane.jp (Masashi UMEZAWA)
Date: Sat, 22 Aug 2015 22:15:43 +0900
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <55D5DDC4.9030101@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>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
Message-ID: <CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>

Hi Juan,

Yes, I'm concerning about backward-compatibility.
FmFileEntry>>#readStream has been used long. So I would prefer just
adding new APIs.

Best regards,

> I guess I would prefer #readStream for the basic, raising exceptions api,
> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the "exception
> eating api" . In any case it is your call, I understand there is back
> compatibility to care about, and I'll be happy with your choice.
>
> Cheers,
> Juan Vuletich
>
>
>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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
>>>>>>>
>>>>>>>
>>>>
>



-- 
[:masashi | ^umezawa]



From eliot.miranda at gmail.com  Sat Aug 22 11:38:30 2015
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Sat, 22 Aug 2015 09:38:30 -0700
Subject: [Cuis] New Cog VMs available...
Message-ID: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3427.

Squeak V5 users will want to upgrade their VMs because they, along with
Smalltalk changes to follow soon, fix image segments.  But upgrading is not
a trivial process because the VMs on my site are not complete.  The best
way to update is to take a copy of the Squeak 5.0 all-in-one and replace
the main VM executable there-in with one from my site.  This gets you
up-to-date plugins and an up-to-date VM.  I hope that this process will get
easier soon.


------------------------------------------------------------------------
CogVM binaries as per VMMaker.oscog-eem.1441/r3427

Modify Spur ImageSegment load to become the segmentWordArray into an Array
of
the loaded objects if load is successful, hence decoupling ImageSegment from
the assumption that objects are allocated in order.

Fix Integer receiver, float arg comparison with NaNs in the machine-code
primitive.  This has started failing in the FloatTest>>testNaNCompare since
the
new machine-code perform primitive invoked the machine-code version of the
primitive.  The Interpretewr code has always been correct and the old
perform
primitive would always run the Interpreter primitive if it exsted, since
this
would probably be faster.

Fix the bug introduced by the fix to primitive function invocation in
VMMaker.oscog-eem.1351  The fix correctly changed primitve code to set the
primitiveFunctionPointer appropriately when a jitted external primitive was
rebound, but it didn't remember to void the jit's record of the offset of
the
assignment that sets the primitiveFunctionPointer when switching between
profiling andf non-profiling regimes, so that the address from the wrong
regime
would remain and be used to smash prmitive code.  The fix is simply to void
the
externalSetPrimOffsets in voidCogCompiledCode.  This fixes the bug whose
symptom is a hard VM crash when using AndreasSystemProfilier.

Integrate Marcel Taeumel & Tobias Pape's v2 SSL plugin changes.

Fix negative 64-bit shift in the 64-bit Spur Stack interpreter.

Newspeak:
Fix MNU for cogged self and outer sends.

Make the Newspeak VM packager include the V50 sources file instead of V41.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150822/35d7bb41/attachment-0002.html>

From j.b.shirk at gmail.com  Mon Aug 24 06:42:33 2015
From: j.b.shirk at gmail.com (Joe Shirk)
Date: Mon, 24 Aug 2015 07:42:33 -0400
Subject: [Cuis] IPFS on Smalltalk
Message-ID: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>

Dear all, especially @Masashi

I wanted to draw attention to the http://ipfs.io project, "the permanent
web" which works. It is a distributed peer-to-peer filesystem that works
somewhat like bittorrent. You get the functionality of Git as well. It is
truly ingenious.

Since I have taken an interest in Smalltalk (I'm still learning) I have
salivated at the  possibilities for, say Amber + ipfs.

There is currently a call for APIs implemented in other languages;
https://github.com/ipfs/ipfs/issues
I see no one there is interested in Smalltalk so I though I should
undertake it, but it will be many months before I have the knowledge and
there is no guarantee that I am up to the task... Now seeing that Masashi
is working with filesystems, perhaps you would take an interest in this
idea.

The inventor Juan Benet has many brilliant ideas and has done several
presentations to be found on the ipfs site. Unfortunately, he seems to
drink a lot of coffee and talks extremely fast and does not enunciate,
making the presentations very difficult to understand for those of whom
english is a second language. I can definitely help with this by making a
transcript if there is interest.


On Sat, Aug 22, 2015 at 1:00 PM, <cuis-request at jvuletich.org> wrote:

> Send Cuis mailing list submissions to
>         cuis at jvuletich.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> or, via email, send a message with subject or body 'help' to
>         cuis-request at jvuletich.org
>
> You can reach the person managing the list at
>         cuis-owner at jvuletich.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cuis digest..."
>
>
> Today's Topics:
>
>    1. Re: Wrapper for file access in different Smalltalk dialects
>       (Masashi UMEZAWA)
>    2. New Cog VMs available... (Eliot Miranda)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 22 Aug 2015 22:15:43 +0900
> From: Masashi UMEZAWA <ume at blueplane.jp>
> To: Juan Vuletich <juan at jvuletich.org>
> Cc: Discussion of Cuis Smalltalk <cuis at jvuletich.org>,  "H. Hirzel"
>         <hannes.hirzel at gmail.com>
> Subject: Re: [Cuis] Wrapper for file access in different Smalltalk
>         dialects
> Message-ID:
>         <CA+=
> t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Juan,
>
> Yes, I'm concerning about backward-compatibility.
> FmFileEntry>>#readStream has been used long. So I would prefer just
> adding new APIs.
>
> Best regards,
>
> > I guess I would prefer #readStream for the basic, raising exceptions api,
> > and maybe #readStreamNoFail or #readStreamOrEmpty or such for the
> "exception
> > eating api" . In any case it is your call, I understand there is back
> > compatibility to care about, and I'll be happy with your choice.
> >
> > Cheers,
> > Juan Vuletich
> >
> >
> >> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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
> >>>>>>>
> >>>>>>>
> >>>>
> >
>
>
>
> --
> [:masashi | ^umezawa]
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 22 Aug 2015 09:38:30 -0700
> From: Eliot Miranda <eliot.miranda at gmail.com>
> To: Squeak Virtual Machine Development Discussion
>         <vm-dev at lists.squeakfoundation.org>
> Cc: The general-purpose Squeak developers list
>         <squeak-dev at lists.squeakfoundation.org>,        Discusses
> Development of
>         Pharo <pharo-dev at lists.pharo.org>,
>         "newspeaklanguage at googlegroups.com"
>         <newspeaklanguage at googlegroups.com>,    Discussion of Cuis
> Smalltalk
>         <cuis at jvuletich.org>
> Subject: [Cuis] New Cog VMs available...
> Message-ID:
>         <CAC20JE1-f=nHr-jkoMsmpYaH=
> s2rkNxmaDom6bqZ3shfjDq2_g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3427.
>
> Squeak V5 users will want to upgrade their VMs because they, along with
> Smalltalk changes to follow soon, fix image segments.  But upgrading is not
> a trivial process because the VMs on my site are not complete.  The best
> way to update is to take a copy of the Squeak 5.0 all-in-one and replace
> the main VM executable there-in with one from my site.  This gets you
> up-to-date plugins and an up-to-date VM.  I hope that this process will get
> easier soon.
>
>
> ------------------------------------------------------------------------
> CogVM binaries as per VMMaker.oscog-eem.1441/r3427
>
> Modify Spur ImageSegment load to become the segmentWordArray into an Array
> of
> the loaded objects if load is successful, hence decoupling ImageSegment
> from
> the assumption that objects are allocated in order.
>
> Fix Integer receiver, float arg comparison with NaNs in the machine-code
> primitive.  This has started failing in the FloatTest>>testNaNCompare since
> the
> new machine-code perform primitive invoked the machine-code version of the
> primitive.  The Interpretewr code has always been correct and the old
> perform
> primitive would always run the Interpreter primitive if it exsted, since
> this
> would probably be faster.
>
> Fix the bug introduced by the fix to primitive function invocation in
> VMMaker.oscog-eem.1351  The fix correctly changed primitve code to set the
> primitiveFunctionPointer appropriately when a jitted external primitive was
> rebound, but it didn't remember to void the jit's record of the offset of
> the
> assignment that sets the primitiveFunctionPointer when switching between
> profiling andf non-profiling regimes, so that the address from the wrong
> regime
> would remain and be used to smash prmitive code.  The fix is simply to void
> the
> externalSetPrimOffsets in voidCogCompiledCode.  This fixes the bug whose
> symptom is a hard VM crash when using AndreasSystemProfilier.
>
> Integrate Marcel Taeumel & Tobias Pape's v2 SSL plugin changes.
>
> Fix negative 64-bit shift in the 64-bit Spur Stack interpreter.
>
> Newspeak:
> Fix MNU for cogged self and outer sends.
>
> Make the Newspeak VM packager include the V50 sources file instead of V41.
>
> _,,,^..^,,,_
> best, Eliot
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150822/35d7bb41/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 38, Issue 21
> ************************************
>



-- 

Gmail is unsecure. Why? See: EFF Surveillance Self-Defense Project
<https://ssd.eff.org/tech/email>

My preferred secure email address: infomaniac(at)i2pmail(dot)org
(For more information, please see: About I2P <http://www.i2p2.de/intro.html>
)

If you prefer to send to this gmail account, consider using
https://www.mailpile.is

My Public key:
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x8726E59217F0E6F9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150824/043d26be/attachment-0002.html>

From juanlists at jvuletich.org  Mon Aug 24 08:28:17 2015
From: juanlists at jvuletich.org (J. Vuletich (mail lists))
Date: Mon, 24 Aug 2015 13:28:17 +0000
Subject: [Cuis] [Vm-dev] New Cog VMs available...
In-Reply-To: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
References: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
Message-ID: <20150824132817.Horde.7mj1UgJfqgatW2PykGELgg7@gator3294.hostgator.com>

Thanks Eliot!

It works great, and indeed it fixes the issue with  
AndreasSystemProfiler I had reported.

Cheers,
Juan Vuletich

Quoting Eliot Miranda <eliot.miranda at gmail.com>:

>






From juan at jvuletich.org  Mon Aug 24 08:37:48 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:37:48 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55D3D3F2.50607@smalltalk.comcastbiz.net>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
Message-ID: <55DB1E2C.4010300@jvuletich.org>

Thanks Andr?s,

I'll be there. Maybe I'll submit a talk proposal too.

Folks, what do you think I'd tell about?
- Cuis, introduction for people who don't know much about it, recent 
development and community activity, etc.
- Repeat, and add latest details to the talk I already gave about work 
at Satellogic.
- Morphic 3. I'd rather not. Maybe a short "show us your project" demo, 
given that there are no recent news here.
- anything else?

Cheers,
Juan Vuletich

On 8/18/2015 9:55 PM, Andres Valloud wrote:
> The Fundaci?n Argentina de Smalltalk proudly invites you to one of the 
> premier Smalltalk conferences in the world.  Let's meet at Buenos 
> Aires, November 11-13!  For more details, see the invitation here:
>
> http://www.fast.org.ar/Smalltalks2015-invitation.pdf
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org




From juan at jvuletich.org  Mon Aug 24 08:42:46 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:42:46 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@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>
	<55B64713.8040806@jvuletich.org>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
	<CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>
Message-ID: <55DB1F56.608@jvuletich.org>

Hi Masashi,

Ok. #tryReadStream is reasonable. Or maybe #readStreamOrFail.

Any other suggestion? Preferences?

Thanks,
Juan Vuletich

On 8/22/2015 10:15 AM, Masashi UMEZAWA wrote:
> Hi Juan,
>
> Yes, I'm concerning about backward-compatibility.
> FmFileEntry>>#readStream has been used long. So I would prefer just
> adding new APIs.
>
> Best regards,
>
>> I guess I would prefer #readStream for the basic, raising exceptions api,
>> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the "exception
>> eating api" . In any case it is your call, I understand there is back
>> compatibility to care about, and I'll be happy with your choice.
>>
>> Cheers,
>> Juan Vuletich
>>
>>
>>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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 juan at jvuletich.org  Mon Aug 24 08:43:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:43:09 -0300
Subject: [Cuis] New Cog VMs available...
In-Reply-To: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
References: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
Message-ID: <55DB1F6D.1010006@jvuletich.org>

Works like a charm.

Thanks a lot!

Cheers,
Juan Vuletich

On 8/22/2015 1:38 PM, Eliot Miranda wrote:
> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3427.
>
> Squeak V5 users will want to upgrade their VMs because they, along 
> with Smalltalk changes to follow soon, fix image segments.  But 
> upgrading is not a trivial process because the VMs on my site are not 
> complete.  The best way to update is to take a copy of the Squeak 5.0 
> all-in-one and replace the main VM executable there-in with one from 
> my site.  This gets you up-to-date plugins and an up-to-date VM.  I 
> hope that this process will get easier soon.
>
>
> ------------------------------------------------------------------------
> CogVM binaries as per VMMaker.oscog-eem.1441/r3427
>
> Modify Spur ImageSegment load to become the segmentWordArray into an 
> Array of
> the loaded objects if load is successful, hence decoupling 
> ImageSegment from
> the assumption that objects are allocated in order.
>
> Fix Integer receiver, float arg comparison with NaNs in the machine-code
> primitive.  This has started failing in the FloatTest>>testNaNCompare 
> since the
> new machine-code perform primitive invoked the machine-code version of the
> primitive.  The Interpretewr code has always been correct and the old 
> perform
> primitive would always run the Interpreter primitive if it exsted, 
> since this
> would probably be faster.
>
> Fix the bug introduced by the fix to primitive function invocation in
> VMMaker.oscog-eem.1351  The fix correctly changed primitve code to set the
> primitiveFunctionPointer appropriately when a jitted external 
> primitive was
> rebound, but it didn't remember to void the jit's record of the offset 
> of the
> assignment that sets the primitiveFunctionPointer when switching between
> profiling andf non-profiling regimes, so that the address from the 
> wrong regime
> would remain and be used to smash prmitive code.  The fix is simply to 
> void the
> externalSetPrimOffsets in voidCogCompiledCode.  This fixes the bug whose
> symptom is a hard VM crash when using AndreasSystemProfilier.
>
> Integrate Marcel Taeumel & Tobias Pape's v2 SSL plugin changes.
>
> Fix negative 64-bit shift in the 64-bit Spur Stack interpreter.
>
> Newspeak:
> Fix MNU for cogged self and outer sends.
>
> Make the Newspeak VM packager include the V50 sources file instead of V41.
>
> _,,,^..^,,,_
> best, Eliot
>
>
> _______________________________________________
> 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/20150824/9ffa5f3c/attachment-0002.html>

From juan at jvuletich.org  Mon Aug 24 08:48:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:48:43 -0300
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
Message-ID: <55DB20BB.708@jvuletich.org>

Hi Joe,

Someone saying "awesome!" and "cool!" so many times at his own stuff 
makes me a little uncomfortable... But, anyway:

It looks like Dropbox, but peer to peer, right?

The possibility of publishing and sharing stuff without a central 
provider is of course desirable.

Before starting to implement bindings and calls to the api... Is that 
really needed? It is integrated in the file system, so maybe not.

More interesting than that, what are some apps that could benefit from 
it? How would they do that?

Cheers,
Juan Vuletich

On 8/24/2015 8:42 AM, Joe Shirk wrote:
> Dear all, especially @Masashi
>
> I wanted to draw attention to the http://ipfs.io project, "the 
> permanent web" which works. It is a distributed peer-to-peer 
> filesystem that works somewhat like bittorrent. You get the 
> functionality of Git as well. It is truly ingenious.
>
> Since I have taken an interest in Smalltalk (I'm still learning) I 
> have salivated at the  possibilities for, say Amber + ipfs.
>
> There is currently a call for APIs implemented in other languages;
> https://github.com/ipfs/ipfs/issues
> I see no one there is interested in Smalltalk so I though I should 
> undertake it, but it will be many months before I have the knowledge 
> and there is no guarantee that I am up to the task... Now seeing that 
> Masashi is working with filesystems, perhaps you would take an 
> interest in this idea.
>
> The inventor Juan Benet has many brilliant ideas and has done several 
> presentations to be found on the ipfs site. Unfortunately, he seems to 
> drink a lot of coffee and talks extremely fast and does not enunciate, 
> making the presentations very difficult to understand for those of 
> whom english is a second language. I can definitely help with this by 
> making a transcript if there is interest.
>




From j.b.shirk at gmail.com  Mon Aug 24 09:25:58 2015
From: j.b.shirk at gmail.com (Joe Shirk)
Date: Mon, 24 Aug 2015 10:25:58 -0400
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <55DB20BB.708@jvuletich.org>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
	<55DB20BB.708@jvuletich.org>
Message-ID: <CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>

Hi Juan,

I was trying to diplomatically imply that Benet's forte is not
presentation, however the docs on the site and on github are adequate
introductions, and I think it won't take long to see the value in what is
meant by "permanent" web that is content addressed instead of ip addressed.

I spoke too soon today, not aware that he had recently responded to my post
a week ago:

https:// <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>
github.com <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>
/issues/80#issuecomment-133593050
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>

As at the moment I am thumbing my smartphone, I have to be brief, but I'll
try to cover the basics.

ipfs is a protocal that has the potential to eventually replace http
altogether, though currently content on the ipfs network is accessible
directly through the protocol as well as through http gateways.

ipfs is a content routing system, and so functions like a cdn, but it is
distributed, so is like bittorrent. it does sync like dropbox, but the
routing system ensures that copies of content migrate closer to demand,
which could be an auditorium of people on a local wifi without external
access. Real-time syncing to many peers is thus possible without latency.

There are working demos of HD videos streaming without latency from the
network.

The Directed Acyclical Graph / Merkel Tree allows for just about any data
structure, but is especially well designed for versioning. Everything is
addressed by its hash fingerprint, so one can be absolutely sure what
version one requests, but can also traverse the version tree if the content
referenced is say, a software library that is a dependency for a certain
package. Automatic forwarding to a more recent version is also a feature.

There is a name system too, that allows one to register a permanent or
temporary namespace that references a version tree of any object.

All objects are stored in encrypted chunks, so privacy and publicity are
controlled.

To me, this system implemented in smalltalk, and I suppose that should be
squeak and amber, will make it possible to build distributed apps, because
the app itself can be an object, not only its content or data. Implementing
in smalltalk should mean that the complexity involved would be more easily
managed with few bugs, compared to say, javascript or node.

I see ipfs as a route to put smalltalk in the limelight and on the cutting
edge.

HTH

Joe



> Message: 5
> Date: Mon, 24 Aug 2015 10:48:43 -0300
> From: Juan Vuletich <juan at jvuletich.org>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: Joe Shirk <j.b.shirk at gmail.com>
> Subject: Re: [Cuis] IPFS on Smalltalk
> Message-ID: <55DB20BB.708 at jvuletich.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi Joe,
>
> Someone saying "awesome!" and "cool!" so many times at his own stuff
> makes me a little uncomfortable... But, anyway:
>
> It looks like Dropbox, but peer to peer, right?
>
> The possibility of publishing and sharing stuff without a central
> provider is of course desirable.
>
> Before starting to implement bindings and calls to the api... Is that
> really needed? It is integrated in the file system, so maybe not.
>
> More interesting than that, what are some apps that could benefit from
> it? How would they do that?
>
> Cheers,
> Juan Vuletich
>
> On 8/24/2015 8:42 AM, Joe Shirk wrote:
> > Dear all, especially @Masashi
> >
> > I wanted to draw attention to the http://ipfs.io project, "the
> > permanent web" which works. It is a distributed peer-to-peer
> > filesystem that works somewhat like bittorrent. You get the
> > functionality of Git as well. It is truly ingenious.
> >
> > Since I have taken an interest in Smalltalk (I'm still learning) I
> > have salivated at the  possibilities for, say Amber + ipfs.
> >
> > There is currently a call for APIs implemented in other languages;
> > https://github.com/ipfs/ipfs/issues
> > I see no one there is interested in Smalltalk so I though I should
> > undertake it, but it will be many months before I have the knowledge
> > and there is no guarantee that I am up to the task... Now seeing that
> > Masashi is working with filesystems, perhaps you would take an
> > interest in this idea.
> >
> > The inventor Juan Benet has many brilliant ideas and has done several
> > presentations to be found on the ipfs site. Unfortunately, he seems to
> > drink a lot of coffee and talks extremely fast and does not enunciate,
> > making the presentations very difficult to understand for those of
> > whom english is a second language. I can definitely help with this by
> > making a transcript if there is interest.
> >
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 38, Issue 23
> ************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150824/b30244e6/attachment-0002.html>

From juan at jvuletich.org  Mon Aug 24 10:01:11 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 12:01:11 -0300
Subject: [Cuis] Oops!  [Was package relative fileIns]
In-Reply-To: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>
References: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>
Message-ID: <55DB31B7.4050203@jvuletich.org>

Hi Ken,

On 8/23/2015 12:43 PM, Ken.Dickey wrote:
> Wrong click!  Try this one.
>
> The problem came up with someone loading Cuis-Smalltalk-Morphit-master.zip, so Cuis-Smalltalk-MorphIt-master was the dirName.

It is a good addition. But your implementation fails when the package 
name isn't equal to the category name, but a prefix. For example, 
loading 'Signal-Processing', it works for FFT packagePath, but fails for 
FloatImage packagePath.

This cleaner implementation works for both:

     packagePath
         ^ FileDirectory dirPathFor:
             (CodePackage packageOfClass: self ifNone: [ ^nil ]) 
fullFileName

It will be in the next commit.

> The Portland Camp Smalltalk was much fun, BTW.  Met some interesting folks.  Showed Cuis to Gemstone and Instantiations people + general demo.   Found and fixed a few bugs.  Nice folks.
>
> -KenD

Hey that's great! Thank you! Where the talks recoded on video?

I could not find a program of the CampSmalltalk there, but saw some 
pics. It looks like you had a great time there. I would like to join you 
all there next year!

(cc Cuis mail list. hope you don't mind)

Cheers,
Juan Vuletich



From garduino at gmail.com  Mon Aug 24 10:34:09 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Mon, 24 Aug 2015 12:34:09 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55DB1E2C.4010300@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org>
Message-ID: <CAEt3aLzeNZaMPa+meSVnKDuRp==a6vL_x-NkuCWQVb-+aR1Eeg@mail.gmail.com>

Hi Juan:

I think that all the mentioned topics are interesting.

I have not not much time lately to help / invest in Cuis, but if the
material or part of it that I used in Smalltalks 2013 is of some utility
for you, feel free to use it.


Saludos / Regards,
Germ?n Arduino
@garduino


2015-08-24 10:37 GMT-03:00 Juan Vuletich <juan at jvuletich.org>:

> Thanks Andr?s,
>
> I'll be there. Maybe I'll submit a talk proposal too.
>
> Folks, what do you think I'd tell about?
> - Cuis, introduction for people who don't know much about it, recent
> development and community activity, etc.
> - Repeat, and add latest details to the talk I already gave about work at
> Satellogic.
> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo,
> given that there are no recent news here.
> - anything else?
>
> Cheers,
> Juan Vuletich
>
> On 8/18/2015 9:55 PM, Andres Valloud wrote:
>
>> The Fundaci?n Argentina de Smalltalk proudly invites you to one of the
>> premier Smalltalk conferences in the world.  Let's meet at Buenos Aires,
>> November 11-13!  For more details, see the invitation here:
>>
>> http://www.fast.org.ar/Smalltalks2015-invitation.pdf
>>
>>
>> _______________________________________________
>> 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/20150824/f34b2b6e/attachment-0002.html>

From Ken.Dickey at whidbey.com  Sun Aug 23 19:57:01 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 24 Aug 2015 08:57:01 +0800
Subject: [Cuis] The Layout Resize Problem
Message-ID: <20150824085701.fe1053bcdbe68d36e1db633c@whidbey.com>

Greetings,

I have been thinking about "the layout resize problem".

The basis of the layout resize problem is that when someone changes fonts, we would like windows/panes/labels to adjust themselves with the minimum of fuss.

Also, when I resize a Morph I sometimes find that the layouts shrink below submorph containment size.  Currently, specifying a LayoutSpec which indicates "resize, but use morph extent as a minimum" seems awkward.

My intuitive thought is to make use of Morph>>minimumExtent.  LayoutMorphs (composts) could use the maximum width (mimimumExtent x) of their submorphs and the sum of the morph heights (minimumExtent y), possibly adding an extentBorder, and use this as its minimumExtent.

Note that if no submorph changes size, this value can be cached as it does not have to be recalculated.  Low cost calculations (buttonExtent, measureContents) don't have to be cached.

This leads to two questions: 
 [1] How to be informed when something changes that one depends on to calculate ones size.
 [2] How, when something changes size, to do this once for each affected morph?

My thought here is that the World could be informed that font size (or whatever influences  size calculations) changes.  Then it asks each of its submorphs, recursively, to recalculateMinimumExtent and layoutSubmorphs.  

This should happen top to bottom once for each resize causing event.

We can update our size calculating code and get rid of "Please Close All Open Windows".

Does this sound about right?  Other strategies?

Cheers,
-KenD



From edgardec2005 at gmail.com  Mon Aug 24 12:24:52 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Mon, 24 Aug 2015 14:24:52 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55DB1E2C.4010300@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org>
Message-ID: <5A326ADB-3193-47C2-8233-C45A4A854A33@gmail.com>

i wish a clarification about some Cuis 4 and beyond aspects

> On Aug 24, 2015, at 10:37 AM, Juan Vuletich <juan at jvuletich.org> wrote:
> 
> Thanks Andr?s,
> 
> I'll be there. Maybe I'll submit a talk proposal too.
> 
> Folks, what do you think I'd tell about?
> - Cuis, introduction for people who don't know much about it, recent development and community activity, etc.
> - Repeat, and add latest details to the talk I already gave about work at Satellogic.
> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo, given that there are no recent news here.
> - anything else?
> 
> Cheers,
> Juan Vuletich
> 
> On 8/18/2015 9:55 PM, Andres Valloud wrote:
>> The Fundaci?n Argentina de Smalltalk proudly invites you to one of the premier Smalltalk conferences in the world.  Let's meet at Buenos Aires, November 11-13!  For more details, see the invitation here:
>> 
>> http://www.fast.org.ar/Smalltalks2015-invitation.pdf
>> 
>> 
>> _______________________________________________
>> 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 j.b.shirk at gmail.com  Mon Aug 24 15:14:12 2015
From: j.b.shirk at gmail.com (Joe Shirk)
Date: Mon, 24 Aug 2015 16:14:12 -0400
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
	<55DB20BB.708@jvuletich.org>
	<CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
Message-ID: <CA+VgV_sgcLt=m81266ugSeo42hrMd-jdZsfWmJqm7_6V-X+z2w@mail.gmail.com>

I don't know why I wrote 'Squeak' -- too much reading, I guess. I meant
Pharo. My thinking was to make it work there first, then port to cuis and
newspeak if there is a benefit in doing that. Perhaps that's not the best
way to go about it. Any thoughts on this?

On Mon, Aug 24, 2015 at 10:25 AM, Joe Shirk <j.b.shirk at gmail.com> wrote:

> To me, this system implemented in smalltalk, and I suppose that should be
> squeak and amber, will make it possible to build distributed apps, because
> the app itself can be an object, not only its content or data. Implementing
> in smalltalk should mean that the complexity involved would be more easily
> managed with few bugs, compared to say, javascript or node.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150824/b1f94f7a/attachment-0002.html>

From Ken.Dickey at whidbey.com  Mon Aug 24 17:33:55 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 24 Aug 2015 15:33:55 -0700
Subject: [Cuis] Oops!  [Was package relative fileIns]
In-Reply-To: <55DB31B7.4050203@jvuletich.org>
References: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>
	<55DB31B7.4050203@jvuletich.org>
Message-ID: <20150824153355.5c917d40a1bbea5e7d893085@whidbey.com>

On Mon, 24 Aug 2015 12:01:11 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Ken,
> 
> On 8/23/2015 12:43 PM, Ken.Dickey wrote:
..
> > The Portland Camp Smalltalk was much fun, BTW.  Met some interesting folks.  Showed Cuis to Gemstone and Instantiations people + general demo.   Found and fixed a few bugs.  Nice folks.
> >
> > -KenD
 
> Hey that's great! Thank you! Where the talks recoded on video?

No.  I don't think so.  Pretty informal.  First time I had tried the video out on my ChromeBook.  It works! 

I had been showing the Unicode display to someone, so that showed up when I opened my laptop.  Mentioned that.  I  showed drag n drop behaviors with the PropertyEditor and MorphMorphs (MorphIt package) and then showed the puzzle pieces prototyped for planned Snap! style authoring (Emergence package).  Due to questions, I updated the README.md in Cuis-Smalltalk-BabySteps. Very pre-alpha, but there are documentation classes in the MorphIt and Emergence packages. 

> I could not find a program of the CampSmalltalk there, but saw some 
> pics. 

I presume you mean Mike Taylor's pix at https://goo.gl/photos/QCQz77DKLPAPGY5x9

No formal program.  More like, "Anybody have something they would like to share?".  Who's next?

Of note:
  WireShark packet capture analysis
  Multi-programming-language editing (e.g. syntax hilighting and keywords in Java/whatever within JavaScript within HTML).
  Baby steps to Mist/Fog (smalltalk in itself w/o VM) bootstrap.
  Glamor (Pharo presentation framework) extension project.

I am the guy in the purple Apple shirt, BTW.  [Shows up as row 3 pic 1 in my browser].  I see myself in a couple of other snaps as well.  I must have been there.  ;^)

> It looks like you had a great time there. I would like to join you 
> all there next year!

We all would be delighted if you could make it.  Might even get together an agenda/program for the event.  I heard that there will be another camp in Nanimo (British Colombia, Canada) in October, which I hope to attend.

> (cc Cuis mail list. hope you don't mind)

Not at all!  People came from as far as up from New York, Toronto, Boston, Vista (California).  I'll count Andre as from Salem (Washington).  Really need more folks from down south.

Wrote some code.  Found and fixed some bugs.  Met a great bunch of interesting folks.  Well worth the trip!

-- 
-KenD



From pbpublist at gmail.com  Tue Aug 25 13:47:50 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 25 Aug 2015 14:47:50 -0400
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55DB1E2C.4010300@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org>
Message-ID: <1440528470.2306.13.camel@gmail.com>

On Mon, 2015-08-24 at 10:37 -0300, Juan Vuletich wrote:
> Thanks Andr?s,
> 
> I'll be there. Maybe I'll submit a talk proposal too.
> 
> Folks, what do you think I'd tell about?
> - Cuis, introduction for people who don't know much about it, recent 
> development and community activity, etc.
> - Repeat, and add latest details to the talk I already gave about work 
> at Satellogic.
> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo, 
> given that there are no recent news here.
> - anything else?
> 

My main suggestion would be to go for new material (since your previous
talks were recorded people can watch them already and they're still
pretty relevant... maybe you could link to them from the Cuis site to
make them easier to find)  Recent developments and/or near-future plans
might be interesting for those who don't pay close attention to what's
going on with Cuis.
 
> Cheers,
> Juan Vuletich
> 
> On 8/18/2015 9:55 PM, Andres Valloud wrote:
> > The Fundaci?n Argentina de Smalltalk proudly invites you to one of the 
> > premier Smalltalk conferences in the world.  Let's meet at Buenos 
> > Aires, November 11-13!  For more details, see the invitation here:
> >
> > http://www.fast.org.ar/Smalltalks2015-invitation.pdf
> >
> >
> > _______________________________________________
> > 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 ume at blueplane.jp  Thu Aug 27 10:24:44 2015
From: ume at blueplane.jp (Masashi UMEZAWA)
Date: Fri, 28 Aug 2015 00:24:44 +0900
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <55DB1F56.608@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>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
	<CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>
	<55DB1F56.608@jvuletich.org>
Message-ID: <CA+=t-6D3fbHLyYck0v=wdsUZuGWAJ6uyoWopq_+-+5Haut6Ebg@mail.gmail.com>

Hi Juan,

How about adding #tryWriteStream and #tryWriteStreamIfError: for consistency.
Currently FmFileEntry has #writeStreamConfirming, but it is a bit
ad-hoc. It can be renamed to #tryWriteStream.

So we can write:

[ writeStream := 'foo.txt' asFileEntry tryWriteStream ] on:
FmFileIOAccessor fileExistsException do: [:ex | ].

writeStream := 'foo.txt' asFileEntry tryWriteStreamIfError: [:ex | ].

Best regards,

2015-08-24 22:42 GMT+09:00 Juan Vuletich <juan at jvuletich.org>:
> Hi Masashi,
>
> Ok. #tryReadStream is reasonable. Or maybe #readStreamOrFail.
>
> Any other suggestion? Preferences?
>
> Thanks,
> Juan Vuletich
>
>
> On 8/22/2015 10:15 AM, Masashi UMEZAWA wrote:
>>
>> Hi Juan,
>>
>> Yes, I'm concerning about backward-compatibility.
>> FmFileEntry>>#readStream has been used long. So I would prefer just
>> adding new APIs.
>>
>> Best regards,
>>
>>> I guess I would prefer #readStream for the basic, raising exceptions api,
>>> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the
>>> "exception
>>> eating api" . In any case it is your call, I understand there is back
>>> compatibility to care about, and I'll be happy with your choice.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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
>>>>>>>>>
>>>>>>>>>
>>
>>
>



-- 
[:masashi | ^umezawa]



From Ken.Dickey at whidbey.com  Thu Aug 27 03:48:04 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Thu, 27 Aug 2015 16:48:04 +0800
Subject: [Cuis] Font Preferences Change
Message-ID: <20150827164804.5d251b01c9c085f7874edd4f@whidbey.com>

Hi Juan,

I have done enough with resizing on Font Preference Change that I would like some feedback.

The basic questions are:
  [1] Does this direction/strategy seem OK?
  [2] Am I breaking (too many) things?
  [3] Better ideas?  Simpler strategy?
  [4] In sum, it it worth while to continue?

In base, when the user changes preferred fonts, the world gets a fontPreferenceChanged message which it sends to its submorphs, who in turn propagate the message to their submorphs and so forth.

Morph>>fontPreferenceChanged
    self submorphsDo: [ :m | m fontPreferenceChanged ]

Windows which do special things (like set up buttons with fixed* layoutSpec fields) do any special processing required.  Morphs which set relations based on some font metric update their fonts/relations.  Windows typically set up button sizes, so need to reset these.  Some morphs recalculate their minimumExtent or reset their fonts.

For example:

InnerListMorph>>fontPreferenceChanged
    super fontPreferenceChanged.
    self font: Preferences standardListFont.

Look at senders of #fontPreferenceChanged for details.


Usage:
  I have two change sets to file in to the base image.  In order, load the *LayoutTest* then the *FontResize*.

If you use the layout editors, load the Morphic-Misc1 package, then the UnsavedChanges* file.


Expect some missed resize cases.  

Thanks in advance for thoughtful comments.

-KenD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2464-KenD-LayoutTest-KenD.5.cs.st
Type: application/octet-stream
Size: 7012 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150827/c9a2e255/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st
Type: application/octet-stream
Size: 7428 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150827/c9a2e255/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st
Type: application/octet-stream
Size: 11990 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150827/c9a2e255/attachment-0008.obj>

From Ken.Dickey at whidbey.com  Fri Aug 28 03:28:07 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 28 Aug 2015 16:28:07 +0800
Subject: [Cuis] Font Resize Code
Message-ID: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>

Hmmm.. 

There seems to have a problem with file 2464-KenD-LayoutTest-KenD.5.cs.st.

Here is the complete set again (attached).

File in: 
  2464-KenD-LayoutTest-KenD.5.cs.st
  2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st

Optionally:
  Feature require: #'Morphic-Misc1'.
Then file in:
  UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st

Open browsers and other windows.

Then 
  World Menu>>Preferences>>Font Sizes..

And play a bit.

-- 
-KenD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st
Type: application/octet-stream
Size: 7458 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150828/c007b65a/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2464-KenD-LayoutTest-KenD.5.cs.st
Type: application/octet-stream
Size: 6843 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150828/c007b65a/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st
Type: application/octet-stream
Size: 11990 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150828/c007b65a/attachment-0008.obj>

From dnorton at mindspring.com  Sun Aug 30 13:19:38 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 30 Aug 2015 14:19:38 -0400
Subject: [Cuis] Font Height Change?
Message-ID: <55E3493A.32598.BF01F7@dnorton.mindspring.com>

Hi All,

The attached can illustrate a change in the spaces between lines of text. How can I find what 
is causing this change? Placing a "{...} print" in TextModelMorph>>drawOn: is definitely a bad 
idea. To see the spacing change, unzip and file in the attached, open the window with:

	AnagramWindow open.

Click "New", enter a string such as "illicit" and click "More" a few times. 

For different window sizes, the spaces between lines becomes smaller. I do adjust the width 
of the window to keep the text in columns but I'm trying to find out why the spacing changes.

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AnagramAid.pck.zip
Type: application/zip
Size: 3658 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150830/d01b2558/attachment-0002.zip>

From dnorton at mindspring.com  Sun Aug 30 17:10:13 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 30 Aug 2015 18:10:13 -0400
Subject: [Cuis] Font Height Change?
Message-ID: <55E37F45.4235.1921E41@dnorton.mindspring.com>

Never mind. In a fresh image, I can't reproduce it :-/

On 30 Aug 2015 at 14:20, cuis at jvuletich.org wrote:

> Hi All,
> 
> The attached can illustrate a change in the spaces between lines of
> text. How can I find what 
> is causing this change? Placing a "{...} print" in
> TextModelMorph>>drawOn: is definitely a bad 
> idea. To see the spacing change, unzip and file in the attached,
> open the window with:
> 
> 	AnagramWindow open.
> 
> Click "New", enter a string such as "illicit" and click "More" a few
> times. 
> 
> For different window sizes, the spaces between lines becomes
> smaller. I do adjust the width 
> of the window to keep the text in columns but I'm trying to find out
> why the spacing changes.
> 
>  - Dan
> 
> Attachments:
>   C:\Cuis\Anagram\Cuis-Smalltalk-anagram\AnagramAid.pck.zip





From dnorton at mindspring.com  Sun Aug 30 18:01:20 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 30 Aug 2015 19:01:20 -0400
Subject: [Cuis] Font Height Change?
Message-ID: <55E38B40.31946.1C0E883@dnorton.mindspring.com>

Aha! Game on again. It occurs when the font 'DejaVu Sans Mono' is installed and 
AnagramWindow>>cluesFont uses it for the text, but not always. Otherwise, it does not occur 
when the font is 'DejaVu' which is the default.

Resizing the window reverses the close spacing. A couple more clicks of "More" can cause it 
to recur.

On 30 Aug 2015 at 18:10, cuis at jvuletich.org wrote:

> Never mind. In a fresh image, I can't reproduce it :-/
> 
> On 30 Aug 2015 at 14:20, cuis at jvuletich.org wrote:
> 
> > Hi All,
> > 
> > The attached can illustrate a change in the spaces between lines
> of
> > text. How can I find what 
> > is causing this change? Placing a "{...} print" in
> > TextModelMorph>>drawOn: is definitely a bad 
> > idea. To see the spacing change, unzip and file in the attached,
> > open the window with:
> > 
> > 	AnagramWindow open.
> > 
> > Click "New", enter a string such as "illicit" and click "More" a
> few
> > times. 
> > 
> > For different window sizes, the spaces between lines becomes
> > smaller. I do adjust the width 
> > of the window to keep the text in columns but I'm trying to find
> out
> > why the spacing changes.
> > 
> >  - Dan
> > 
> > Attachments:
> >   C:\Cuis\Anagram\Cuis-Smalltalk-anagram\AnagramAid.pck.zip
> 
> 





From juan at jvuletich.org  Mon Aug 31 07:49:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 09:49:53 -0300
Subject: [Cuis] Font Resize Code
In-Reply-To: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>
References: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>
Message-ID: <55E44D71.7080502@jvuletich.org>

Hi Ken,

Apologies for not answering before.

This is a great and welcome addition. I already integrated it and it 
will be in the next commit to GitHub. Thanks!

Cheers,
Juan Vuletich

On 8/28/2015 5:28 AM, Ken.Dickey wrote:
> Hmmm..
>
> There seems to have a problem with file 2464-KenD-LayoutTest-KenD.5.cs.st.
>
> Here is the complete set again (attached).
>
> File in:
>    2464-KenD-LayoutTest-KenD.5.cs.st
>    2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st
>
> Optionally:
>    Feature require: #'Morphic-Misc1'.
> Then file in:
>    UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st
>
> Open browsers and other windows.
>
> Then
>    World Menu>>Preferences>>Font Sizes..
>
> And play a bit.
>




From juan at jvuletich.org  Mon Aug 31 07:54:20 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 09:54:20 -0300
Subject: [Cuis] Font Height Change?
In-Reply-To: <55E38B40.31946.1C0E883@dnorton.mindspring.com>
References: <55E38B40.31946.1C0E883@dnorton.mindspring.com>
Message-ID: <55E44E7C.7010608@jvuletich.org>

Hi Dan,

On 8/30/2015 8:01 PM, Dan Norton wrote:
> Aha! Game on again. It occurs when the font 'DejaVu Sans Mono' is installed and
> AnagramWindow>>cluesFont uses it for the text, but not always. Otherwise, it does not occur
> when the font is 'DejaVu' which is the default.
>
> Resizing the window reverses the close spacing. A couple more clicks of "More" can cause it
> to recur.

Found it! The problem is that in #atRandom and #permuted first you sent 
the contents to your morph, and then you modify them (without the morph 
really realizing of that). I'm not sure about the details of the 
behavior you found, but the attach is cleaner and fixes the problem.

Cheers,
Juan Vuletich
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: UnsavedChangesTo-AnagramAid-jmv.1.cs.st
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150831/dfc739b3/attachment-0002.ksh>

From juan at jvuletich.org  Mon Aug 31 07:57:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 09:57:49 -0300
Subject: [Cuis] Oops!  [Was package relative fileIns]
In-Reply-To: <20150824153355.5c917d40a1bbea5e7d893085@whidbey.com>
References: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>	<55DB31B7.4050203@jvuletich.org>
	<20150824153355.5c917d40a1bbea5e7d893085@whidbey.com>
Message-ID: <55E44F4D.2060709@jvuletich.org>

Hi Ken,

Thanks for the report :)

Nice to see you!

Cheers,
Juan Vuletich

On 8/24/2015 7:33 PM, Ken.Dickey wrote:
> On Mon, 24 Aug 2015 12:01:11 -0300
> Juan Vuletich<juan at jvuletich.org>  wrote:
>
>> Hi Ken,
>>
>> On 8/23/2015 12:43 PM, Ken.Dickey wrote:
> ..
>>> The Portland Camp Smalltalk was much fun, BTW.  Met some interesting folks.  Showed Cuis to Gemstone and Instantiations people + general demo.   Found and fixed a few bugs.  Nice folks.
>>>
>>> -KenD
>
>> Hey that's great! Thank you! Where the talks recoded on video?
> No.  I don't think so.  Pretty informal.  First time I had tried the video out on my ChromeBook.  It works!
>
> I had been showing the Unicode display to someone, so that showed up when I opened my laptop.  Mentioned that.  I  showed drag n drop behaviors with the PropertyEditor and MorphMorphs (MorphIt package) and then showed the puzzle pieces prototyped for planned Snap! style authoring (Emergence package).  Due to questions, I updated the README.md in Cuis-Smalltalk-BabySteps. Very pre-alpha, but there are documentation classes in the MorphIt and Emergence packages.
>
>> I could not find a program of the CampSmalltalk there, but saw some
>> pics.
> I presume you mean Mike Taylor's pix at https://goo.gl/photos/QCQz77DKLPAPGY5x9
>
> No formal program.  More like, "Anybody have something they would like to share?".  Who's next?
>
> Of note:
>    WireShark packet capture analysis
>    Multi-programming-language editing (e.g. syntax hilighting and keywords in Java/whatever within JavaScript within HTML).
>    Baby steps to Mist/Fog (smalltalk in itself w/o VM) bootstrap.
>    Glamor (Pharo presentation framework) extension project.
>
> I am the guy in the purple Apple shirt, BTW.  [Shows up as row 3 pic 1 in my browser].  I see myself in a couple of other snaps as well.  I must have been there.  ;^)
>
>> It looks like you had a great time there. I would like to join you
>> all there next year!
> We all would be delighted if you could make it.  Might even get together an agenda/program for the event.  I heard that there will be another camp in Nanimo (British Colombia, Canada) in October, which I hope to attend.
>
>> (cc Cuis mail list. hope you don't mind)
> Not at all!  People came from as far as up from New York, Toronto, Boston, Vista (California).  I'll count Andre as from Salem (Washington).  Really need more folks from down south.
>
> Wrote some code.  Found and fixed some bugs.  Met a great bunch of interesting folks.  Well worth the trip!
>




From juan at jvuletich.org  Mon Aug 31 08:01:51 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 10:01:51 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <1440528470.2306.13.camel@gmail.com>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>	<55DB1E2C.4010300@jvuletich.org>
	<1440528470.2306.13.camel@gmail.com>
Message-ID: <55E4503F.6030603@jvuletich.org>

Hi Folks,

On 8/25/2015 3:47 PM, Phil (list) wrote:
> On Mon, 2015-08-24 at 10:37 -0300, Juan Vuletich wrote:
>> Thanks Andr?s,
>>
>> I'll be there. Maybe I'll submit a talk proposal too.
>>
>> Folks, what do you think I'd tell about?
>> - Cuis, introduction for people who don't know much about it, recent
>> development and community activity, etc.
>> - Repeat, and add latest details to the talk I already gave about work
>> at Satellogic.
>> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo,
>> given that there are no recent news here.
>> - anything else?
>>
> My main suggestion would be to go for new material (since your previous
> talks were recorded people can watch them already and they're still
> pretty relevant... maybe you could link to them from the Cuis site to
> make them easier to find)  Recent developments and/or near-future plans
> might be interesting for those who don't pay close attention to what's
> going on with Cuis.

Thanks you all for your suggestions. Please tell if you think of 
something else, or more specific questions or issues to address in a talk.

Phil, the idea to link to the videos is very good. Do you (or anybody) 
know how to do that? Maybe a link to youtube that already includes a 
search for "Cuis Smalltalk"? Or some sort of auto-generated playlist?

Thanks,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 31 08:09:33 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 10:09:33 -0300
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>	<55DB20BB.708@jvuletich.org>
	<CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
Message-ID: <55E4520D.4040105@jvuletich.org>

Hi Joe,

On 8/24/2015 11:25 AM, Joe Shirk wrote:
>
>
> Hi Juan,
>
> I was trying to diplomatically imply that Benet's forte is not 
> presentation, however the docs on the site and on github are adequate 
> introductions, and I think it won't take long to see the value in what 
> is  meant by "permanent" web that is content addressed instead of ip 
> addressed.
>
> I spoke too soon today, not aware that he had recently responded to my 
> post a week ago:
>
> https:// 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>github.com 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/ 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/ 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/issues/80#issuecomment-133593050 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>
>
> As at the moment I am thumbing my smartphone, I have to be brief, but 
> I'll try to cover the basics.
>
> ipfs is a protocal that has the potential to eventually replace http 
> altogether, though currently content on the ipfs network is accessible 
> directly through the protocol as well as through http gateways.
>
> ipfs is a content routing system, and so functions like a cdn, but it 
> is distributed, so is like bittorrent. it does sync like dropbox, but 
> the routing system ensures that copies of content migrate closer to 
> demand, which could be an auditorium of people on a local wifi without 
> external access. Real-time syncing to many peers is thus possible 
> without latency.
>
> There are working demos of HD videos streaming without latency from 
> the network.
>
> The Directed Acyclical Graph / Merkel Tree allows for just about any 
> data structure, but is especially well designed for versioning. 
> Everything is addressed by its hash fingerprint, so one can be 
> absolutely sure what version one requests, but can also traverse the 
> version tree if the content referenced is say, a software library that 
> is a dependency for a certain package. Automatic forwarding to a more 
> recent version is also a feature.
>
> There is a name system too, that allows one to register a permanent or 
> temporary namespace that references a version tree of any object.
>
> All objects are stored in encrypted chunks, so privacy and publicity 
> are controlled.
>
> To me, this system implemented in smalltalk, and I suppose that should 
> be squeak and amber, will make it possible to build distributed apps, 
> because the app itself can be an object, not only its content or data. 
> Implementing in smalltalk should mean that the complexity involved 
> would be more easily managed with few bugs, compared to say, 
> javascript or node.
>
> I see ipfs as a route to put smalltalk in the limelight and on the 
> cutting edge.
>
> HTH
>
> Joe
>

Thanks for the explanation. I think that implementing it, and playing 
and experimenting with it will show new and better ways of sharing code 
and content, in a word, objects.

I look forward for all this.

Cheers,
Juan Vuletich

>
>
>
> > Message: 5
> > Date: Mon, 24 Aug 2015 10:48:43 -0300
> > From: Juan Vuletich <juan at jvuletich.org <mailto:juan at jvuletich.org>>
> > To: Discussion of Cuis Smalltalk <cuis at jvuletich.org 
> <mailto:cuis at jvuletich.org>>
> > Cc: Joe Shirk <j.b.shirk at gmail.com <mailto:j.b.shirk at gmail.com>>
> > Subject: Re: [Cuis] IPFS on Smalltalk
> > Message-ID: <55DB20BB.708 at jvuletich.org 
> <mailto:55DB20BB.708 at jvuletich.org>>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> >
> > Hi Joe,
> >
> > Someone saying "awesome!" and "cool!" so many times at his own stuff
> > makes me a little uncomfortable... But, anyway:
> >
> > It looks like Dropbox, but peer to peer, right?
> >
> > The possibility of publishing and sharing stuff without a central
> > provider is of course desirable.
> >
> > Before starting to implement bindings and calls to the api... Is that
> > really needed? It is integrated in the file system, so maybe not.
> >
> > More interesting than that, what are some apps that could benefit from
> > it? How would they do that?
> >
> > Cheers,
> > Juan Vuletich
> >
> > On 8/24/2015 8:42 AM, Joe Shirk wrote:
> > > Dear all, especially @Masashi
> > >
> > > I wanted to draw attention to thehttp://ipfs.io project, "the
> > > permanent web" which works. It is a distributed peer-to-peer
> > > filesystem that works somewhat like bittorrent. You get the
> > > functionality of Git as well. It is truly ingenious.
> > >
> > > Since I have taken an interest in Smalltalk (I'm still learning) I
> > > have salivated at the  possibilities for, say Amber + ipfs.
> > >
> > > There is currently a call for APIs implemented in other languages;
> > >https://github.com/ipfs/ipfs/issues
> > > I see no one there is interested in Smalltalk so I though I should
> > > undertake it, but it will be many months before I have the knowledge
> > > and there is no guarantee that I am up to the task... Now seeing that
> > > Masashi is working with filesystems, perhaps you would take an
> > > interest in this idea.
> > >
> > > The inventor Juan Benet has many brilliant ideas and has done several
> > > presentations to be found on the ipfs site. Unfortunately, he seems to
> > > drink a lot of coffee and talks extremely fast and does not enunciate,
> > > making the presentations very difficult to understand for those of
> > > whom english is a second language. I can definitely help with this by
> > > making a transcript if there is interest.
> > >
> >
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Cuis mailing list
> >Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
> >http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
> >
> > ------------------------------
> >
> > End of Cuis Digest, Vol 38, Issue 23
> > ************************************
>
>
> _______________________________________________
> 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/20150831/5523cc1f/attachment-0002.html>

From juan at jvuletich.org  Mon Aug 31 08:20:06 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 10:20:06 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6D3fbHLyYck0v=wdsUZuGWAJ6uyoWopq_+-+5Haut6Ebg@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>
	<55B64713.8040806@jvuletich.org>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
	<CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>
	<55DB1F56.608@jvuletich.org>
	<CA+=t-6D3fbHLyYck0v=wdsUZuGWAJ6uyoWopq_+-+5Haut6Ebg@mail.gmail.com>
Message-ID: <55E45486.30506@jvuletich.org>

Hi Masashi,

Looks great to me. Please let us know when you update 
https://github.com/mumez/FileMan (or 
https://github.com/mumez/Cuis-Smalltalk-FileMan ), so we follow. Or post 
code to the mail list. As you prefer.

Thanks!
Juan Vuletich

On 8/27/2015 12:24 PM, Masashi UMEZAWA wrote:
> Hi Juan,
>
> How about adding #tryWriteStream and #tryWriteStreamIfError: for consistency.
> Currently FmFileEntry has #writeStreamConfirming, but it is a bit
> ad-hoc. It can be renamed to #tryWriteStream.
>
> So we can write:
>
> [ writeStream := 'foo.txt' asFileEntry tryWriteStream ] on:
> FmFileIOAccessor fileExistsException do: [:ex | ].
>
> writeStream := 'foo.txt' asFileEntry tryWriteStreamIfError: [:ex | ].
>
> Best regards,
>
> 2015-08-24 22:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>> Hi Masashi,
>>
>> Ok. #tryReadStream is reasonable. Or maybe #readStreamOrFail.
>>
>> Any other suggestion? Preferences?
>>
>> Thanks,
>> Juan Vuletich
>>
>>
>> On 8/22/2015 10:15 AM, Masashi UMEZAWA wrote:
>>> Hi Juan,
>>>
>>> Yes, I'm concerning about backward-compatibility.
>>> FmFileEntry>>#readStream has been used long. So I would prefer just
>>> adding new APIs.
>>>
>>> Best regards,
>>>
>>>> I guess I would prefer #readStream for the basic, raising exceptions api,
>>>> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the
>>>> "exception
>>>> eating api" . In any case it is your call, I understand there is back
>>>> compatibility to care about, and I'll be happy with your choice.
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>>
>>>>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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 Ken.Dickey at whidbey.com  Mon Aug 31 09:50:50 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 31 Aug 2015 07:50:50 -0700
Subject: [Cuis] Font Resize Code
In-Reply-To: <55E44D71.7080502@jvuletich.org>
References: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>
	<55E44D71.7080502@jvuletich.org>
Message-ID: <20150831075050.f99f1041f30d9e155e39caed@whidbey.com>

On Mon, 31 Aug 2015 09:49:53 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Apologies for not answering before.

No worries.  Storm here with high winds knocked out power for 2 days, so I would not have known anyway.

> This is a great and welcome addition. I already integrated it and it 
> will be in the next commit to GitHub. Thanks!

You are very welcome!

Good to give demos.  One has the opportunity to learn and get embarrassed, which leads toward progress.  ;^) 

Back to reading Snap! code..

Cheers,
-KenD



From dnorton at mindspring.com  Mon Aug 31 12:38:47 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 31 Aug 2015 13:38:47 -0400
Subject: [Cuis] Font Height Change?
In-Reply-To: <55E44E7C.7010608@jvuletich.org>
References: <55E38B40.31946.1C0E883@dnorton.mindspring.com>,
	<55E44E7C.7010608@jvuletich.org>
Message-ID: <55E49127.31197.88F661@dnorton.mindspring.com>

Thanks for the answer, Juan. It stops confusing and annoying the morph :)

 - Dan

On 31 Aug 2015 at 9:54, Juan Vuletich wrote:

> Hi Dan,
> 
> On 8/30/2015 8:01 PM, Dan Norton wrote:
> > Aha! Game on again. It occurs when the font 'DejaVu Sans Mono' is
> installed and
> > AnagramWindow>>cluesFont uses it for the text, but not always.
> Otherwise, it does not occur
> > when the font is 'DejaVu' which is the default.
> >
> > Resizing the window reverses the close spacing. A couple more
> clicks of "More" can cause it
> > to recur.
> 
> Found it! The problem is that in #atRandom and #permuted first you
> sent 
> the contents to your morph, and then you modify them (without the
> morph 
> really realizing of that). I'm not sure about the details of the 
> behavior you found, but the attach is cleaner and fixes the
> problem.
> 
> Cheers,
> Juan Vuletich
> 





From pbpublist at gmail.com  Mon Aug 31 16:54:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 31 Aug 2015 17:54:01 -0400
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55E4503F.6030603@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org> <1440528470.2306.13.camel@gmail.com>
	<55E4503F.6030603@jvuletich.org>
Message-ID: <1441058041.8967.11.camel@gmail.com>

On Mon, 2015-08-31 at 10:01 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> On 8/25/2015 3:47 PM, Phil (list) wrote:
> > On Mon, 2015-08-24 at 10:37 -0300, Juan Vuletich wrote:
> >> Thanks Andr?s,
> >>
> >> I'll be there. Maybe I'll submit a talk proposal too.
> >>
> >> Folks, what do you think I'd tell about?
> >> - Cuis, introduction for people who don't know much about it, recent
> >> development and community activity, etc.
> >> - Repeat, and add latest details to the talk I already gave about work
> >> at Satellogic.
> >> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo,
> >> given that there are no recent news here.
> >> - anything else?
> >>
> > My main suggestion would be to go for new material (since your previous
> > talks were recorded people can watch them already and they're still
> > pretty relevant... maybe you could link to them from the Cuis site to
> > make them easier to find)  Recent developments and/or near-future plans
> > might be interesting for those who don't pay close attention to what's
> > going on with Cuis.
> 
> Thanks you all for your suggestions. Please tell if you think of 
> something else, or more specific questions or issues to address in a talk.
> 
> Phil, the idea to link to the videos is very good. Do you (or anybody) 
> know how to do that? Maybe a link to youtube that already includes a 
> search for "Cuis Smalltalk"? Or some sort of auto-generated playlist?
> 

There are a few different ways I can think of depending on your
preference:
1) You could create a 'videos' page on the Cuis site (this is what I was
thinking) and then create embedded players for each video.  Go to a
video you want to add, click the share link, then the embed tab to get
the html snippet.  The reason to keep this on a separate page is that
YouTube embeds aren't 'lightweight' so it would be polite to keep these
off the main page or you will probably annoy visitors and decrease
traffic to the main Cuis page.  If they click on a videos link
presumably they understand that this might be a heavier page but it is
what they want...
2) Create a YouTube playlist on your YouTube channel.  This is just a
matter of going to each video you want and click the add button and add
it to the playlist (and make sure the playlist is public).  This works
but then there is no linkage between the Cuis page and the playlist
(though you could combine this and item 1 and do an embedded playlist)
3) A YouTube search such as
https://www.youtube.com/results?search_query=cuis+smalltalk will 'sort
of' get you in the ballpark, but probably not what visitors will
want/expect.

Here are a couple of videos that would probably be good to add to the
list:
https://www.youtube.com/watch?v=bgIwbx-eDcI
https://www.youtube.com/watch?v=YFn4tShalUI

I seem to also recall a general English Cuis overview presentation you
did (also at a Smalltalks conf?) but can't find the link right now...

> Thanks,
> Juan Vuletich





From peter at aba-instituut.nl  Sat Aug  1 06:57:13 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Sat, 1 Aug 2015 13:57:13 +0200
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <CAGQxfVhZfsbRw=Fiq0fy5_5MHU5bqEEnM2S1F5akOKUMmxXUJg@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>
	<1437592756.2326.32.camel@gmail.com>
	<CAGQxfVhZfsbRw=Fiq0fy5_5MHU5bqEEnM2S1F5akOKUMmxXUJg@mail.gmail.com>
Message-ID: <CAJBxtBZgJ-ku-6KBu=axEKL=hOX8sTiF7KDAB0heTquLzEMiAg@mail.gmail.com>

Hi Hannes,

You asked for an example of a Feature Test. I assume, but may be wrong,
that you want this to understand better what the intention of such a test
is. Of course I can only answer form my own imagination.

1 It should be something that provides a definite answer to a question
about the image/system, but where there is not necessarily a good or bad
outcome (as there is with a unit test; pass=good, fail or error=bad). So
for instance it could test if there is any class loaded that implements
AnsiDateAndTime protocol (or at least part of it and how much). Or it could
test if the number of classes is less than the number of instance
variables. Or it could test how many classes have a class comment. It could
test how many literals may be in a method. Still, it seems logical to want
to define Features in such a way that the presence of the feature is a good
situation (better or no worse than the absence).

2 An essential feature of a Feature Test is that it should be able to load
and run in in any image. Its no use of course if you want to figure
something out and you can't load and run the test that determines what you
want to know. So The Feature test must be able to compile and run source
code (it could conceivably interpret syntax trees but that seems rather
contrived given that the compiler is normally available in any image). And
while doing that it should be able to suppress any problems.

3 There should be some way to (build Feature Test Suites suites and/or) run
all the loaded Feature tests together, silently, and receive feedback only
at the end. Most simply in the form of a document/text that shows how it
went. Optionally using some kind of GUI, viz. SUnitBrowser. The default
FeatureTestSuite could simply run all loaded Feature Tests, and you could
subclass it if you wanted to define specific Suites.

I think it would be great to have a FeatureTest class that you could
subclass to run tests on how much of the Ansi standard is implemented in
the image and how accurately it follows the semantics prescribed. The
original Camp Smalltalk attempts at such a test suite were based on SUnit
as the test framework, but that didn't work as it is essentially unsuited
to loading tests about code that may not be laoded.

Cheers, Peter



On Fri, Jul 31, 2015 at 8:29 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> 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
> >
>
> _______________________________________________
> 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/20150801/63b2b971/attachment-0003.html>

From squeaklists at fang.demon.co.uk  Sun Aug  2 02:04:13 2015
From: squeaklists at fang.demon.co.uk (Douglas Brebner)
Date: Sun, 02 Aug 2015 08:04:13 +0100
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: <55BDC0ED.3060401@fang.demon.co.uk>

On 19/07/2015 22:38, Phil (list) wrote:
> 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 vaguely recall that many years ago there was a project called 
SmallInterfaces that let you define public interfaces to objects. (Or 
something like that). Would that be a good way to document the 
public/private api using code?

(sorry for being so vague but I've been awake for 24+ hours now)



From dnorton at mindspring.com  Sun Aug  2 20:24:40 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 02 Aug 2015 21:24:40 -0400
Subject: [Cuis] VM Crash
Message-ID: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>

Load Cuis4.2-2439.image. Open File List and go to Packages.
Select Graphics-Files-Additional.pck.st and click on "Install Package".

Get "Fatal VM Error". The zipped crash.dmp is attached.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150802/6f3e6f01/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash.zip
Type: application/zip
Size: 3832 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150802/6f3e6f01/attachment-0003.zip>

From dnorton at mindspring.com  Mon Aug  3 11:54:24 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 03 Aug 2015 12:54:24 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B8E93C.7080009@jvuletich.org>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55B8E93C.7080009@jvuletich.org>
Message-ID: <55BF9CC0.20600.59E8552@dnorton.mindspring.com>

On 29 Jul 2015 at 11:54, Juan Vuletich wrote:

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

I'm trying to get FreeType built and also I did a clone of:

https://github.com/rougier/freetype-gl

Unfortunately when I compile embedded-font.c the following occurs:

fatal error C1083: Cannot open include file: 'vera-16.h': No such file or directory

Do any of you Cexperts know where I can get 'vera-16.h'? Google search produces ads for 
soaps containing aloe vera :-)

 - Dan



From juan at jvuletich.org  Mon Aug  3 13:38:10 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:38:10 -0300
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <1438189897.2292.6.camel@gmail.com>
References: <55B7757D.80006@jvuletich.org>	 <1438119702.2292.5.camel@gmail.com>
	<55B8E7EA.7060301@jvuletich.org>
	<1438189897.2292.6.camel@gmail.com>
Message-ID: <55BFB512.3060109@jvuletich.org>

On 7/29/2015 2:11 PM, Phil (list) wrote:
> 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

And accepted. Thank you!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug  3 13:49:55 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:49:55 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55BDC0ED.3060401@fang.demon.co.uk>
References: <55A905A3.1060100@jvuletich.org>	<1437158701.2255.245.camel@gmail.com>	<55ABB223.8010309@jvuletich.org>	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
Message-ID: <55BFB7D3.4030701@jvuletich.org>

Hi Doug,

On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> On 19/07/2015 22:38, Phil (list) wrote:
>> 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 vaguely recall that many years ago there was a project called 
> SmallInterfaces that let you define public interfaces to objects. (Or 
> something like that). Would that be a good way to document the 
> public/private api using code?
>
> (sorry for being so vague but I've been awake for 24+ hours now)

Thanks for the pointer. I took a look at it. It is quite like Java 
interfaces. The tools are interesting. But I see several downsides:

- Each interface is a class. Each method in the protocol is an actual 
method. If we use this to document all public protocols in Cuis, it 
would mean a lot of new classes and methods.
- The source code of (for example) OrderedCollection>>at: would not 
include the information of it belonging to interface "Indexable". 
Without additional support from tools users can't tell whether a message 
is public protocol or not. And the base image / package maintainer can't 
easily see he's about to change a public api.

I think a method pragma, that includes the name of the protocol avoids 
these issues and is a better choice.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug  3 13:57:21 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:57:21 -0300
Subject: [Cuis] VM Crash
In-Reply-To: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>
References: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>
Message-ID: <55BFB991.1070807@jvuletich.org>

On 8/2/2015 10:24 PM, Dan Norton wrote:
> Load Cuis4.2-2439.image. Open File List and go to Packages.
> Select Graphics-Files-Additional.pck.st and click on "Install Package".
>
> Get "Fatal VM Error". The zipped crash.dmp is attached.
>
>  - Dan
>

I can not reproduce it. Can you reproduce it consistently? Can you 
reproduce it consistently with a fresh image and VM on a local hard 
drive? If so, please provide more details so I can reproduce it.

It seems to be a stack overflow. If you can reproduce it, you can try 
again, and after Install Package do alt+. (User Interrupt) and try to 
find out why there is an unbounded recursion.

Thanks,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150803/90602200/attachment-0003.html>

From juan at jvuletich.org  Mon Aug  3 13:59:47 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:59:47 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55BF9CC0.20600.59E8552@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55B8E93C.7080009@jvuletich.org>
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>
Message-ID: <55BFBA23.4010302@jvuletich.org>

On 8/3/2015 1:54 PM, Dan Norton wrote:
> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
>
>> 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.
>>
> I'm trying to get FreeType built and also I did a clone of:
>
> https://github.com/rougier/freetype-gl
>
> Unfortunately when I compile embedded-font.c the following occurs:
>
> fatal error C1083: Cannot open include file: 'vera-16.h': No such file or directory
>
> Do any of you Cexperts know where I can get 'vera-16.h'? Google search produces ads for
> soaps containing aloe vera :-)
>
>   - Dan

Hi Dan,

I can not help you with the build of FreeType , but could you try the 
image I used to build the fonts? You shouldn't need to build anything to 
run it. The FreeType VM plugin is included for both Windows and Mac. I'd 
appreciate any feedback.

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Mon Aug  3 14:16:21 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 03 Aug 2015 15:16:21 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55BF9CC0.20600.59E8552@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
	, <55B8E93C.7080009@jvuletich.org>
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>
Message-ID: <1438629381.12996.1.camel@gmail.com>

On Mon, 2015-08-03 at 12:54 -0400, Dan Norton wrote:
> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> 
> > 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.
> > 
> 
> I'm trying to get FreeType built and also I did a clone of:
> 
> https://github.com/rougier/freetype-gl
> 
> Unfortunately when I compile embedded-font.c the following occurs:
> 
> fatal error C1083: Cannot open include file: 'vera-16.h': No such file or directory
> 
> Do any of you Cexperts know where I can get 'vera-16.h'? Google search produces ads for 
> soaps containing aloe vera :-)
> 

It looks like it's a file generated from Vera.ttf based on
https://travis-ci.org/rougier/freetype-gl

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





From pbpublist at gmail.com  Mon Aug  3 14:19:42 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 03 Aug 2015 15:19:42 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55BFB7D3.4030701@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org>
Message-ID: <1438629582.12996.4.camel@gmail.com>

On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
> Hi Doug,
> 
> On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> > On 19/07/2015 22:38, Phil (list) wrote:
> >> 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 vaguely recall that many years ago there was a project called 
> > SmallInterfaces that let you define public interfaces to objects. (Or 
> > something like that). Would that be a good way to document the 
> > public/private api using code?
> >
> > (sorry for being so vague but I've been awake for 24+ hours now)
> 
> Thanks for the pointer. I took a look at it. It is quite like Java 
> interfaces. The tools are interesting. But I see several downsides:
> 
> - Each interface is a class. Each method in the protocol is an actual 
> method. If we use this to document all public protocols in Cuis, it 
> would mean a lot of new classes and methods.
> - The source code of (for example) OrderedCollection>>at: would not 
> include the information of it belonging to interface "Indexable". 
> Without additional support from tools users can't tell whether a message 
> is public protocol or not. And the base image / package maintainer can't 
> easily see he's about to change a public api.
> 
> I think a method pragma, that includes the name of the protocol avoids 
> these issues and is a better choice.
> 

I agree.  Let's keep it as simple as possible and see how far that gets
us.

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





From peter at aba-instituut.nl  Mon Aug  3 15:35:51 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Mon, 3 Aug 2015 22:35:51 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1438629582.12996.4.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org>
	<1438629582.12996.4.camel@gmail.com>
Message-ID: <CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>

Hi,

1. I'm totally against introducing pragma's (perhaps they already exist in
Cuis, I don't know).

First of all because they are not Smalltalk, and second because they are
not needed.

What would be wrong with simply introducing a convention and adding a
method cuisPublicSelectors to a class?

To avoid seeing them on the instance side, there could also be
cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class side.

At the top these would be defined as self allSelectors.

If someone wanted to view only the public selectors in a browser, they
would check the checkbox for that and the browser would hide the non-public
selectors.

Or the browser could show a nice public interface report added to the class
comment.

2. On another point: interfaces such as indexable could simply be described
by creating a class CuisInterfaceSpecification which gets a subclass for
each interface specified. The methods belonging to the interface are
defined and get a comment explaining the semantics of the method. This
makes it easy for tools to check which interfaces are (probably)
implemented by a class. If desired, each method could be additionally
defined to return a MethodSpecification object that knows about
preconditions, invariants, return values, argument and return
types/interfaces...but then it becomes progressively more complicated.

But anyway, in this way whoever thinks it's important enough, can add the
info (for public selectors of a class or for whole interface
specifications) without anyone who is not interested in that needing to
know or care about that.

In my mind that gels well with Cuis' philosophy of simplicity. But I could
be missing the whole point...

Cheers, Peter





On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <pbpublist at gmail.com> wrote:

> On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
> > Hi Doug,
> >
> > On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> > > On 19/07/2015 22:38, Phil (list) wrote:
> > >> 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 vaguely recall that many years ago there was a project called
> > > SmallInterfaces that let you define public interfaces to objects. (Or
> > > something like that). Would that be a good way to document the
> > > public/private api using code?
> > >
> > > (sorry for being so vague but I've been awake for 24+ hours now)
> >
> > Thanks for the pointer. I took a look at it. It is quite like Java
> > interfaces. The tools are interesting. But I see several downsides:
> >
> > - Each interface is a class. Each method in the protocol is an actual
> > method. If we use this to document all public protocols in Cuis, it
> > would mean a lot of new classes and methods.
> > - The source code of (for example) OrderedCollection>>at: would not
> > include the information of it belonging to interface "Indexable".
> > Without additional support from tools users can't tell whether a message
> > is public protocol or not. And the base image / package maintainer can't
> > easily see he's about to change a public api.
> >
> > I think a method pragma, that includes the name of the protocol avoids
> > these issues and is a better choice.
> >
>
> I agree.  Let's keep it as simple as possible and see how far that gets
> us.
>
> > 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/20150803/df8af54b/attachment-0003.html>

From dnorton at mindspring.com  Mon Aug  3 19:08:08 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 03 Aug 2015 20:08:08 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55BFBA23.4010302@jvuletich.org>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>,
	<55BFBA23.4010302@jvuletich.org>
Message-ID: <55C00268.12873.72B9E46@dnorton.mindspring.com>

On 3 Aug 2015 at 15:59, Juan Vuletich wrote:

> On 8/3/2015 1:54 PM, Dan Norton wrote:
> > On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> >
> >> 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.
> >>
> > I'm trying to get FreeType built and also I did a clone of:
> >
> > https://github.com/rougier/freetype-gl
> >
> > Unfortunately when I compile embedded-font.c the following
> occurs:
> >
> > fatal error C1083: Cannot open include file: 'vera-16.h': No such
> file or directory
> >
> > Do any of you Cexperts know where I can get 'vera-16.h'? Google
> search produces ads for
> > soaps containing aloe vera :-)
> >
> >   - Dan
> 
> Hi Dan,
> 
> I can not help you with the build of FreeType , but could you try
> the 
> image I used to build the fonts? You shouldn't need to build
> anything to 
> run it. The FreeType VM plugin is included for both Windows and Mac.
> I'd 
> appreciate any feedback.
>

OK, the package works as far as choosing fonts from a list. How the list is derived is not 
clear. Inconsolata is not on it. The chosen font can be used in ListMorphs. The thing which 
eludes me here is the same in the other environs: How to write a .bmp file containing the 
glyphs. That problem was the reason for pursuing FreeType and OpenGL. I see the 
characters displayed in the pane. They are drawn correctly. Where are the glyphs?

 - Dan



From juan at jvuletich.org  Mon Aug  3 19:51:42 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 21:51:42 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C00268.12873.72B9E46@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>,
	<55BFBA23.4010302@jvuletich.org>
	<55C00268.12873.72B9E46@dnorton.mindspring.com>
Message-ID: <55C00C9E.5040207@jvuletich.org>

On 03/08/2015 09:08 p.m., Dan Norton wrote:
> On 3 Aug 2015 at 15:59, Juan Vuletich wrote:
>
>> On 8/3/2015 1:54 PM, Dan Norton wrote:
>>> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
>>>
>>>> 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.
>>>>
>>> I'm trying to get FreeType built and also I did a clone of:
>>>
>>> https://github.com/rougier/freetype-gl
>>>
>>> Unfortunately when I compile embedded-font.c the following
>> occurs:
>>> fatal error C1083: Cannot open include file: 'vera-16.h': No such
>> file or directory
>>> Do any of you Cexperts know where I can get 'vera-16.h'? Google
>> search produces ads for
>>> soaps containing aloe vera :-)
>>>
>>>    - Dan
>> Hi Dan,
>>
>> I can not help you with the build of FreeType , but could you try
>> the
>> image I used to build the fonts? You shouldn't need to build
>> anything to
>> run it. The FreeType VM plugin is included for both Windows and Mac.
>> I'd
>> appreciate any feedback.
>>
> OK, the package works as far as choosing fonts from a list. How the list is derived is not
> clear. Inconsolata is not on it. The chosen font can be used in ListMorphs. The thing which
> eludes me here is the same in the other environs: How to write a .bmp file containing the
> glyphs. That problem was the reason for pursuing FreeType and OpenGL. I see the
> characters displayed in the pane. They are drawn correctly. Where are the glyphs?
>
>   - Dan

When you open that image, you see a browser open on a method called 
#export. Some text is already selected. Before the selected text it says 
"Set FreeType preferences" and "Create a folder named AAFonts". The 
selected text does "FreeTypeFontProvider current updateFromSystem." . 
This loads your Windows / MacOS fonts into the image. Then follows a 
lists of fonts. Those fonts must be available to the system. The rest of 
the selected code does the export, saving the bmp and txt files. To 
export Inconsolata, or any other font, first load it into your Windows 
or MacOS system, then add it to the list, then export.

I thought all this was self-explanatory...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug  3 19:55:10 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 21:55:10 -0300
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT
 version number
In-Reply-To: <1437950873600-4839529.post@n4.nabble.com>
References: <55B0F0B2.6090202@jvuletich.org>
	<1437950873600-4839529.post@n4.nabble.com>
Message-ID: <55C00D6E.3020602@jvuletich.org>

Thanks, folks.

(inline)
On 26/07/2015 07:47 p.m., Dan Norton wrote:
>
> 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?
>

Uh, that was a long time ago... I guess it was around 1997 or 1998... It 
would be fun to do it, though.

Cheers,
Juan Vuletich

> App delivery sans IDE, halos, menus
>
> Apps with feedback; output becomes next input
>
> Recognition biometrics
>
> Financial analysis
>
> Anything fun
>
>   - Dan




From dnorton at mindspring.com  Mon Aug  3 21:52:12 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 03 Aug 2015 22:52:12 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C00C9E.5040207@jvuletich.org>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55C00268.12873.72B9E46@dnorton.mindspring.com>,
	<55C00C9E.5040207@jvuletich.org>
Message-ID: <55C028DC.25658.2EEEB2@dnorton.mindspring.com>

On 3 Aug 2015 at 21:51, Juan Vuletich wrote:

> On 03/08/2015 09:08 p.m., Dan Norton wrote:
> > On 3 Aug 2015 at 15:59, Juan Vuletich wrote:
> >
> >> On 8/3/2015 1:54 PM, Dan Norton wrote:
> >>> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> >>>
> >>>> 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.
> >>>>
> >>> I'm trying to get FreeType built and also I did a clone of:
> >>>
> >>> https://github.com/rougier/freetype-gl
> >>>
> >>> Unfortunately when I compile embedded-font.c the following
> >> occurs:
> >>> fatal error C1083: Cannot open include file: 'vera-16.h': No
> such
> >> file or directory
> >>> Do any of you Cexperts know where I can get 'vera-16.h'?
> Google
> >> search produces ads for
> >>> soaps containing aloe vera :-)
> >>>
> >>>    - Dan
> >> Hi Dan,
> >>
> >> I can not help you with the build of FreeType , but could you
> try
> >> the
> >> image I used to build the fonts? You shouldn't need to build
> >> anything to
> >> run it. The FreeType VM plugin is included for both Windows and
> Mac.
> >> I'd
> >> appreciate any feedback.
> >>
> > OK, the package works as far as choosing fonts from a list. How
> the list is derived is not
> > clear. Inconsolata is not on it. The chosen font can be used in
> ListMorphs. The thing which
> > eludes me here is the same in the other environs: How to write a
> .bmp file containing the
> > glyphs. That problem was the reason for pursuing FreeType and
> OpenGL. I see the
> > characters displayed in the pane. They are drawn correctly. Where
> are the glyphs?
> >
> >   - Dan
> 
> When you open that image, you see a browser open on a method called
> #export. Some text is already selected. Before the selected text it
> says 
> "Set FreeType preferences" and "Create a folder named AAFonts". The
> selected text does "FreeTypeFontProvider current updateFromSystem."
> . 
> This loads your Windows / MacOS fonts into the image. Then follows a
> lists of fonts. Those fonts must be available to the system. The
> rest of 
> the selected code does the export, saving the bmp and txt files. To
> export Inconsolata, or any other font, first load it into your
> Windows 
> or MacOS system, then add it to the list, then export.
> 
> I thought all this was self-explanatory...
> 
> Cheers,
> Juan Vuletich

If a font name is not in the system, the image crashes. Only a reboot recovers.

It is not possible to create a new file in the AAFonts directory. It is possible in the current 
directory however.

I'm going to restore my system to before Visual Studio et al. There is too much wierdness.

 - Dan





From pbpublist at gmail.com  Mon Aug  3 22:20:03 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 03 Aug 2015 23:20:03 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org> <1438629582.12996.4.camel@gmail.com>
	<CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>
Message-ID: <1438658403.12996.35.camel@gmail.com>

On Mon, 2015-08-03 at 22:35 +0200, Peter van Rooijen wrote:
> Hi,
> 
> 
> 1. I'm totally against introducing pragma's (perhaps they already
> exist in Cuis, I don't know).
> 

Too late, they're already there (VM functionality)

> 
> First of all because they are not Smalltalk, and second because they
> are not needed.
> 
> 
> What would be wrong with simply introducing a convention and adding a
> method cuisPublicSelectors to a class?
> 
> 
> To avoid seeing them on the instance side, there could also be
> cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class
> side.
> 
> 
> At the top these would be defined as self allSelectors.
> 
> 
> If someone wanted to view only the public selectors in a browser, they
> would check the checkbox for that and the browser would hide the
> non-public selectors.
> 
> 
> Or the browser could show a nice public interface report added to the
> class comment.
> 
> 
> 2. On another point: interfaces such as indexable could simply be
> described by creating a class CuisInterfaceSpecification which gets a
> subclass for each interface specified. The methods belonging to the
> interface are defined and get a comment explaining the semantics of
> the method. This makes it easy for tools to check which interfaces are
> (probably) implemented by a class. If desired, each method could be
> additionally defined to return a MethodSpecification object that knows
> about preconditions, invariants, return values, argument and return
> types/interfaces...but then it becomes progressively more complicated.
> 
> 
> But anyway, in this way whoever thinks it's important enough, can add
> the info (for public selectors of a class or for whole interface
> specifications) without anyone who is not interested in that needing
> to know or care about that.
> 

This is too complicated for what I think we're trying to achieve...

> 
> In my mind that gels well with Cuis' philosophy of simplicity. But I
> could be missing the whole point...
> 

The intent (what I was going for at least) is to provide a means for
Juan and anyone else modifying the core image / packages to have a
bidirectional communications channel with anyone looking to have a
stable set of APIs that they can depend on.  It needs to be something
that's simple and easy for both Juan and us to use, or it won't get
used.  I think that Juan's pragma approach accomplishes this.  All it
signals is that 'this method will keep working as it currently does
until/unless it is formally decided to change it'.

So here's an example of how this might work:
1) Let's say we propose that #asString as a public API and Juan agrees
that this is a useful method and should be fairly stable.
Implementations of #asString get marked with a publicAPI (or whatever
name makes sense) pragma 
2) Those of us who care can then work to ensure that our code is using
these publicAPI methods when possible.  This will also help drive out
some of our own bad behavior where we were calling things that we really
shouldn't have been.
3) Time passes and life is good :-)
4) Down the line (Cuis 5.x, 6.x... whatever) Juan decides that #asString
needs to change (who knows... unicode support... or maybe he just
decides that #asString is the wrong way to do it)  Seeing that #asString
is flagged publicAPI, he knows not to 'just do it' but rather make sure
that the change gets called out in the release notes (after some mailing
list discussion if he deems it worthwhile to do so... his call) and that
since it will likely break code to probably wait for a major release.

This also allows for deprecating things that are designated as
publicAPI... just because something is public does not mean it always
will be, just that the changes to things that are need to be
communicated more richly.  For me, the documentation aspect of it is a
nice to have secondary objective that falls out of it... getting to a
stable core is the primary objective.  (i.e. we're not documenting for
the sake of documenting)

> 
> Cheers, Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <pbpublist at gmail.com>
> wrote:
>         On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
>         > Hi Doug,
>         >
>         > On 8/2/2015 4:04 AM, Douglas Brebner wrote:
>         > > On 19/07/2015 22:38, Phil (list) wrote:
>         > >> 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 vaguely recall that many years ago there was a project
>         called
>         > > SmallInterfaces that let you define public interfaces to
>         objects. (Or
>         > > something like that). Would that be a good way to document
>         the
>         > > public/private api using code?
>         > >
>         > > (sorry for being so vague but I've been awake for 24+
>         hours now)
>         >
>         > Thanks for the pointer. I took a look at it. It is quite
>         like Java
>         > interfaces. The tools are interesting. But I see several
>         downsides:
>         >
>         > - Each interface is a class. Each method in the protocol is
>         an actual
>         > method. If we use this to document all public protocols in
>         Cuis, it
>         > would mean a lot of new classes and methods.
>         > - The source code of (for example) OrderedCollection>>at:
>         would not
>         > include the information of it belonging to interface
>         "Indexable".
>         > Without additional support from tools users can't tell
>         whether a message
>         > is public protocol or not. And the base image / package
>         maintainer can't
>         > easily see he's about to change a public api.
>         >
>         > I think a method pragma, that includes the name of the
>         protocol avoids
>         > these issues and is a better choice.
>         >
>         
>         
>         I agree.  Let's keep it as simple as possible and see how far
>         that gets
>         us.
>         
>         > 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





From dnorton at mindspring.com  Tue Aug  4 13:35:19 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 14:35:19 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>

On 3 Aug 2015 at 22:52, Dan Norton wrote:

> On 3 Aug 2015 at 21:51, Juan Vuletich wrote:
> 
> > On 03/08/2015 09:08 p.m., Dan Norton wrote:
> > > On 3 Aug 2015 at 15:59, Juan Vuletich wrote:
> > >
> > >> On 8/3/2015 1:54 PM, Dan Norton wrote:
> > >>> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> > >>>
> > >>>> 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.
> > >>>>
> > >>> I'm trying to get FreeType built and also I did a clone of:
> > >>>
> > >>> https://github.com/rougier/freetype-gl
> > >>>
> > >>> Unfortunately when I compile embedded-font.c the following
> > >> occurs:
> > >>> fatal error C1083: Cannot open include file: 'vera-16.h': No
> > such
> > >> file or directory
> > >>> Do any of you Cexperts know where I can get 'vera-16.h'?
> > Google
> > >> search produces ads for
> > >>> soaps containing aloe vera :-)
> > >>>
> > >>>    - Dan
> > >> Hi Dan,
> > >>
> > >> I can not help you with the build of FreeType , but could you
> > try
> > >> the
> > >> image I used to build the fonts? You shouldn't need to build
> > >> anything to
> > >> run it. The FreeType VM plugin is included for both Windows
> and
> > Mac.
> > >> I'd
> > >> appreciate any feedback.
> > >>
> > > OK, the package works as far as choosing fonts from a list.
> How
> > the list is derived is not
> > > clear. Inconsolata is not on it. The chosen font can be used
> in
> > ListMorphs. The thing which
> > > eludes me here is the same in the other environs: How to write
> a
> > .bmp file containing the
> > > glyphs. That problem was the reason for pursuing FreeType and
> > OpenGL. I see the
> > > characters displayed in the pane. They are drawn correctly.
> Where
> > are the glyphs?
> > >
> > >   - Dan
> > 
> > When you open that image, you see a browser open on a method
> called
> > #export. Some text is already selected. Before the selected text
> it
> > says 
> > "Set FreeType preferences" and "Create a folder named AAFonts".
> The
> > selected text does "FreeTypeFontProvider current
> updateFromSystem."
> > . 
> > This loads your Windows / MacOS fonts into the image. Then follows
> a
> > lists of fonts. Those fonts must be available to the system. The
> > rest of 
> > the selected code does the export, saving the bmp and txt files.
> To
> > export Inconsolata, or any other font, first load it into your
> > Windows 
> > or MacOS system, then add it to the list, then export.
> > 
> > I thought all this was self-explanatory...
> > 
> > Cheers,
> > Juan Vuletich
> 
> If a font name is not in the system, the image crashes. Only a
> reboot recovers.
> 
> It is not possible to create a new file in the AAFonts directory. It
> is possible in the current 
> directory however.
> 
> I'm going to restore my system to before Visual Studio et al. There
> is too much wierdness.
>
Hi Juan,

After the restore and after extracting again the two zip files from your dropbox there remain 
fundamental problems. In FreeTypeFont>>export the following statement results in nothing 
written to AAFonts directory:

n := 'AAFonts', FileDirectory slash, face familyName, '-', emph asString , '-', pointSize 
printString.

If changed to spell out the complete path as follows, some of the .bmp and .txt files are 
written to AAFonts before other problems arise:

n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName, '-', emph asString , '-', 
pointSize printString.

 - Dan



From juan at jvuletich.org  Tue Aug  4 14:09:18 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 16:09:18 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>
Message-ID: <55C10DDE.3090700@jvuletich.org>

On 8/4/2015 3:35 PM, Dan Norton wrote:
> On 3 Aug 2015 at 22:52, Dan Norton wrote:
> ...
>> If a font name is not in the system, the image crashes. Only a
>> reboot recovers.
>>
>> It is not possible to create a new file in the AAFonts directory. It
>> is possible in the current
>> directory however.
>>
>> I'm going to restore my system to before Visual Studio et al. There
>> is too much wierdness.
>>
> Hi Juan,
>
> After the restore and after extracting again the two zip files from your dropbox there remain
> fundamental problems. In FreeTypeFont>>export the following statement results in nothing
> written to AAFonts directory:
>
> n := 'AAFonts', FileDirectory slash, face familyName, '-', emph asString , '-', pointSize
> printString.
>
> If changed to spell out the complete path as follows, some of the .bmp and .txt files are
> written to AAFonts before other problems arise:
>
> n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName, '-', emph asString , '-',
> pointSize printString.
>
>   - Dan

Hi Dan,

I tried again. On a Windows 7 system, I stored the contents of both zips 
in a folder, started the image and exported 'Calibri' without any problems.

In any case, this is not part of Cuis. It wasn't even meant for 
distribution, just for my own use when I built the Bitmap Vera Sans 
fonts in Cuis/Squeak/Pharo. I only published it at your personal 
request, and not in the Cuis repo. It is given without support or 
warranties. If you want to use it, try understanding what is going on. 
After all, it is just Smalltalk. If you do that, and ask specific 
questions, I'll answer.

Juan Vuletich



From dnorton at mindspring.com  Tue Aug  4 14:42:39 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 15:42:39 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C10DDE.3090700@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C10DDE.3090700@jvuletich.org>
Message-ID: <55C115AF.28292.158941B@dnorton.mindspring.com>

On 4 Aug 2015 at 16:09, Juan Vuletich wrote:

> On 8/4/2015 3:35 PM, Dan Norton wrote:
> > On 3 Aug 2015 at 22:52, Dan Norton wrote:
> > ...
> >> If a font name is not in the system, the image crashes. Only a
> >> reboot recovers.
> >>
> >> It is not possible to create a new file in the AAFonts directory.
> It
> >> is possible in the current
> >> directory however.
> >>
> >> I'm going to restore my system to before Visual Studio et al.
> There
> >> is too much wierdness.
> >>
> > Hi Juan,
> >
> > After the restore and after extracting again the two zip files
> from your dropbox there remain
> > fundamental problems. In FreeTypeFont>>export the following
> statement results in nothing
> > written to AAFonts directory:
> >
> > n := 'AAFonts', FileDirectory slash, face familyName, '-', emph
> asString , '-', pointSize
> > printString.
> >
> > If changed to spell out the complete path as follows, some of the
> .bmp and .txt files are
> > written to AAFonts before other problems arise:
> >
> > n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName,
> '-', emph asString , '-',
> > pointSize printString.
> >
> >   - Dan
> 
> Hi Dan,
> 
> I tried again. On a Windows 7 system, I stored the contents of both
> zips 
> in a folder, started the image and exported 'Calibri' without any
> problems.
> 

On my Windows 7 I tried to export 'Calibri' and got MNU: receiver of "nextPutAll:" is nil.
This is the same problem which led to my work-around above. Don't waste any more time on 
this. It may be something clobbered a .dll and has nothing to do with Squeak. I will continue 
to work on it because I need a fixed-width font. Not having it has me stalled on a project.

> In any case, this is not part of Cuis. It wasn't even meant for 
> distribution, just for my own use when I built the Bitmap Vera Sans
> fonts in Cuis/Squeak/Pharo. I only published it at your personal 
> request, and not in the Cuis repo. It is given without support or 
> warranties. If you want to use it, try understanding what is going
> on. 
> After all, it is just Smalltalk. If you do that, and ask specific 
> questions, I'll answer.
> 
> Juan Vuletich





From juan at jvuletich.org  Tue Aug  4 15:08:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 17:08:01 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C115AF.28292.158941B@dnorton.mindspring.com>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C10DDE.3090700@jvuletich.org>
	<55C115AF.28292.158941B@dnorton.mindspring.com>
Message-ID: <55C11BA1.6000406@jvuletich.org>

On 8/4/2015 4:42 PM, Dan Norton wrote:
> On 4 Aug 2015 at 16:09, Juan Vuletich wrote:
>
>> On 8/4/2015 3:35 PM, Dan Norton wrote:
>>> On 3 Aug 2015 at 22:52, Dan Norton wrote:
>>> ...
>>>> If a font name is not in the system, the image crashes. Only a
>>>> reboot recovers.
>>>>
>>>> It is not possible to create a new file in the AAFonts directory.
>> It
>>>> is possible in the current
>>>> directory however.
>>>>
>>>> I'm going to restore my system to before Visual Studio et al.
>> There
>>>> is too much wierdness.
>>>>
>>> Hi Juan,
>>>
>>> After the restore and after extracting again the two zip files
>> from your dropbox there remain
>>> fundamental problems. In FreeTypeFont>>export the following
>> statement results in nothing
>>> written to AAFonts directory:
>>>
>>> n := 'AAFonts', FileDirectory slash, face familyName, '-', emph
>> asString , '-', pointSize
>>> printString.
>>>
>>> If changed to spell out the complete path as follows, some of the
>> .bmp and .txt files are
>>> written to AAFonts before other problems arise:
>>>
>>> n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName,
>> '-', emph asString , '-',
>>> pointSize printString.
>>>
>>>    - Dan
>> Hi Dan,
>>
>> I tried again. On a Windows 7 system, I stored the contents of both
>> zips
>> in a folder, started the image and exported 'Calibri' without any
>> problems.
>>
> On my Windows 7 I tried to export 'Calibri' and got MNU: receiver of "nextPutAll:" is nil.
> This is the same problem which led to my work-around above. Don't waste any more time on
> this. It may be something clobbered a .dll and has nothing to do with Squeak. I will continue
> to work on it because I need a fixed-width font. Not having it has me stalled on a project.
>

Then I suggest the following: Save the contents of those zips to a thumb 
drive. Borrow a Windows machine, from someone that doesn't do weird 
stuff with dlls and VisualStudio ;-) . Run from the thumb drive, and 
take it home.

Oh, something else. On the Mac, the procedure generated txt files with 
integer numbers. On Windows there are Floats. Most likely that is wrong...

Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono or 
Inconsolata myself...

>> In any case, this is not part of Cuis. It wasn't even meant for
>> distribution, just for my own use when I built the Bitmap Vera Sans
>> fonts in Cuis/Squeak/Pharo. I only published it at your personal
>> request, and not in the Cuis repo. It is given without support or
>> warranties. If you want to use it, try understanding what is going
>> on.
>> After all, it is just Smalltalk. If you do that, and ask specific
>> questions, I'll answer.
>>
>> Juan Vuletich
>

Cheers,
Juan Vuletich



From dnorton at mindspring.com  Tue Aug  4 17:10:49 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 18:10:49 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C11BA1.6000406@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C115AF.28292.158941B@dnorton.mindspring.com>,
	<55C11BA1.6000406@jvuletich.org>
Message-ID: <55C13869.19799.1E03D95@dnorton.mindspring.com>

(In line...)

On 4 Aug 2015 at 17:08, Juan Vuletich wrote:

> On 8/4/2015 4:42 PM, Dan Norton wrote:
> > On 4 Aug 2015 at 16:09, Juan Vuletich wrote:
> >
> >> On 8/4/2015 3:35 PM, Dan Norton wrote:
> >>> On 3 Aug 2015 at 22:52, Dan Norton wrote:
> >>> ...
> >>>> If a font name is not in the system, the image crashes. Only
> a
> >>>> reboot recovers.
> >>>>
> >>>> It is not possible to create a new file in the AAFonts
> directory.
> >> It
> >>>> is possible in the current
> >>>> directory however.
> >>>>
> >>>> I'm going to restore my system to before Visual Studio et al.
> >> There
> >>>> is too much wierdness.
> >>>>
> >>> Hi Juan,
> >>>
> >>> After the restore and after extracting again the two zip files
> >> from your dropbox there remain
> >>> fundamental problems. In FreeTypeFont>>export the following
> >> statement results in nothing
> >>> written to AAFonts directory:
> >>>
> >>> n := 'AAFonts', FileDirectory slash, face familyName, '-',
> emph
> >> asString , '-', pointSize
> >>> printString.
> >>>
> >>> If changed to spell out the complete path as follows, some of
> the
> >> .bmp and .txt files are
> >>> written to AAFonts before other problems arise:
> >>>
> >>> n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face
> familyName,
> >> '-', emph asString , '-',
> >>> pointSize printString.
> >>>
> >>>    - Dan
> >> Hi Dan,
> >>
> >> I tried again. On a Windows 7 system, I stored the contents of
> both
> >> zips
> >> in a folder, started the image and exported 'Calibri' without
> any
> >> problems.
> >>
> > On my Windows 7 I tried to export 'Calibri' and got MNU: receiver
> of "nextPutAll:" is nil.
> > This is the same problem which led to my work-around above. Don't
> waste any more time on
> > this. It may be something clobbered a .dll and has nothing to do
> with Squeak. I will continue
> > to work on it because I need a fixed-width font. Not having it has
> me stalled on a project.
> >
> 
> Then I suggest the following: Save the contents of those zips to a
> thumb 
> drive. Borrow a Windows machine, from someone that doesn't do weird
> stuff with dlls and VisualStudio ;-) . Run from the thumb drive, and
> take it home.
> 

Did that on my wife's laptop and got the same result. Trust me, she does not have Visual 
Studio or anything else more rad than FireFox :-)


> Oh, something else. On the Mac, the procedure generated txt files
> with 
> integer numbers. On Windows there are Floats. Most likely that is
> wrong...
> 
> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono or
> Inconsolata myself...
> 

That would sure be great. When I started this journey many moons ago, Inconsolata was my 
idea of a great font to have on Cuis.

> >> In any case, this is not part of Cuis. It wasn't even meant for
> >> distribution, just for my own use when I built the Bitmap Vera
> Sans
> >> fonts in Cuis/Squeak/Pharo. I only published it at your
> personal
> >> request, and not in the Cuis repo. It is given without support
> or
> >> warranties. If you want to use it, try understanding what is
> going
> >> on.
> >> After all, it is just Smalltalk. If you do that, and ask
> specific
> >> questions, I'll answer.
> >>
> >> Juan Vuletich
> >
> 
> Cheers,
> Juan Vuletich





From dnorton at mindspring.com  Tue Aug  4 20:22:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 21:22:35 -0400
Subject: [Cuis] VM Crash
In-Reply-To: <55BFB991.1070807@jvuletich.org>
References: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>,
	<55BFB991.1070807@jvuletich.org>
Message-ID: <55C1655B.25215.20DAE4@dnorton.mindspring.com>

On 3 Aug 2015 at 15:57, Juan Vuletich wrote:

> 
> On 8/2/2015 10:24 PM, Dan Norton wrote:
>     Load Cuis4.2-2439.image. Open File List and go to Packages.
>     Select Graphics-Files-Additional.pck.st and click on "Install
> Package".
> 
>     Get "Fatal VM Error". The zipped crash.dmp is attached.
> 
>     ?- Dan
> 
> 
> I can not reproduce it. Can you reproduce it consistently? Can you
> reproduce it consistently with a 
> fresh image and VM on a local hard drive? If so, please provide more
> details so I can reproduce it.
> 
> It seems to be a stack overflow. If you can reproduce it, you can
> try again, and after Install 
> Package do alt+. (User Interrupt) and try to find out why there is
> an unbounded recursion.
> 

The problem occurs with cogwin-15.28.3410. It is consistent and will not yield to alt+. .

The problem does not occur with cogwin-15.27.3397.

These runs were done on Windows 7.

 - Dan



From juan at jvuletich.org  Tue Aug  4 21:47:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 23:47:49 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C13869.19799.1E03D95@dnorton.mindspring.com>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C115AF.28292.158941B@dnorton.mindspring.com>,
	<55C11BA1.6000406@jvuletich.org>
	<55C13869.19799.1E03D95@dnorton.mindspring.com>
Message-ID: <55C17955.7050807@jvuletich.org>

On 8/4/2015 7:10 PM, Dan Norton wrote:
>
>> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono or
>> Inconsolata myself...
>>
> That would sure be great. When I started this journey many moons ago, Inconsolata was my
> idea of a great font to have on Cuis.

Ok. Set up the AAFonts folder with contents. File in both cs'. Evaluate 
[StrikeFont install: 'DejaVu Sans Mono']. I hope it works for you.

I didn't include Inconsolata because it doesn't have italics or bold, 
and also because DejaVuSansMono looks quite better with Freetype.

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DejaVuSansMono.zip
Type: application/zip
Size: 1070498 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150804/d3d63655/attachment-0003.zip>

From juan at jvuletich.org  Tue Aug  4 21:57:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 23:57:43 -0300
Subject: [Cuis] VM Crash
In-Reply-To: <55C1655B.25215.20DAE4@dnorton.mindspring.com>
References: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>,
	<55BFB991.1070807@jvuletich.org>
	<55C1655B.25215.20DAE4@dnorton.mindspring.com>
Message-ID: <55C17BA7.6080008@jvuletich.org>

On 8/4/2015 10:22 PM, Dan Norton wrote:
> On 3 Aug 2015 at 15:57, Juan Vuletich wrote:
>
>> On 8/2/2015 10:24 PM, Dan Norton wrote:
>>      Load Cuis4.2-2439.image. Open File List and go to Packages.
>>      Select Graphics-Files-Additional.pck.st and click on "Install
>> Package".
>>
>>      Get "Fatal VM Error". The zipped crash.dmp is attached.
>>
>>       - Dan
>>
>>
>> I can not reproduce it. Can you reproduce it consistently? Can you
>> reproduce it consistently with a
>> fresh image and VM on a local hard drive? If so, please provide more
>> details so I can reproduce it.
>>
>> It seems to be a stack overflow. If you can reproduce it, you can
>> try again, and after Install
>> Package do alt+. (User Interrupt) and try to find out why there is
>> an unbounded recursion.
>>
> The problem occurs with cogwin-15.28.3410. It is consistent and will not yield to alt+. .
>
> The problem does not occur with cogwin-15.27.3397.
>
> These runs were done on Windows 7.
>
>   - Dan

Yes. Same here. Use 
http://www.mirandabanda.org/files/Cog/VM/VM.r3370/cogwin-15.22.3370.zip 
. About a week ago I reported another problem with later releases of Cog 
to VM-Dev. Still, without luck.

Juan Vuletich



From edgardec2005 at gmail.com  Wed Aug  5 04:04:44 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Wed, 05 Aug 2015 06:04:44 -0300
Subject: [Cuis] Wish Feedback
Message-ID: <D1E757FC.15B3C%edgardec2005@gmail.com>

In the twitter links exploration of today I found

https://github.com/aserg-ufmg/JSCity This maybe could be in future
?Divagaciones?
To people who don?t know , ?Divagaciones? is my perpetual personal learning
tool and could be viewed trough www.squeakros.org

user: visita
pass: (do not type any here)

 
And from here

http://www.inf.usi.ch/phd/wettel/codecity.html

See in what is programmed and tell

Coud pay the work for porting CodeCity
 to Squeak/Cuis ?


Edgar
@morplenauta 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150805/4f55649c/attachment-0003.html>

From peter at aba-instituut.nl  Wed Aug  5 10:50:12 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 5 Aug 2015 17:50:12 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1438658403.12996.35.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org>
	<1438629582.12996.4.camel@gmail.com>
	<CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>
	<1438658403.12996.35.camel@gmail.com>
Message-ID: <CAJBxtBbAFcAkw7m4kV_U=QeUTNoXYSQxnsE-kT2pv-JT0jWCbg@mail.gmail.com>

Thanks Phil for the explanation.

Cheers, Peter

On Tue, Aug 4, 2015 at 5:20 AM, Phil (list) <pbpublist at gmail.com> wrote:

> On Mon, 2015-08-03 at 22:35 +0200, Peter van Rooijen wrote:
> > Hi,
> >
> >
> > 1. I'm totally against introducing pragma's (perhaps they already
> > exist in Cuis, I don't know).
> >
>
> Too late, they're already there (VM functionality)
>
> >
> > First of all because they are not Smalltalk, and second because they
> > are not needed.
> >
> >
> > What would be wrong with simply introducing a convention and adding a
> > method cuisPublicSelectors to a class?
> >
> >
> > To avoid seeing them on the instance side, there could also be
> > cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class
> > side.
> >
> >
> > At the top these would be defined as self allSelectors.
> >
> >
> > If someone wanted to view only the public selectors in a browser, they
> > would check the checkbox for that and the browser would hide the
> > non-public selectors.
> >
> >
> > Or the browser could show a nice public interface report added to the
> > class comment.
> >
> >
> > 2. On another point: interfaces such as indexable could simply be
> > described by creating a class CuisInterfaceSpecification which gets a
> > subclass for each interface specified. The methods belonging to the
> > interface are defined and get a comment explaining the semantics of
> > the method. This makes it easy for tools to check which interfaces are
> > (probably) implemented by a class. If desired, each method could be
> > additionally defined to return a MethodSpecification object that knows
> > about preconditions, invariants, return values, argument and return
> > types/interfaces...but then it becomes progressively more complicated.
> >
> >
> > But anyway, in this way whoever thinks it's important enough, can add
> > the info (for public selectors of a class or for whole interface
> > specifications) without anyone who is not interested in that needing
> > to know or care about that.
> >
>
> This is too complicated for what I think we're trying to achieve...
>
> >
> > In my mind that gels well with Cuis' philosophy of simplicity. But I
> > could be missing the whole point...
> >
>
> The intent (what I was going for at least) is to provide a means for
> Juan and anyone else modifying the core image / packages to have a
> bidirectional communications channel with anyone looking to have a
> stable set of APIs that they can depend on.  It needs to be something
> that's simple and easy for both Juan and us to use, or it won't get
> used.  I think that Juan's pragma approach accomplishes this.  All it
> signals is that 'this method will keep working as it currently does
> until/unless it is formally decided to change it'.
>
> So here's an example of how this might work:
> 1) Let's say we propose that #asString as a public API and Juan agrees
> that this is a useful method and should be fairly stable.
> Implementations of #asString get marked with a publicAPI (or whatever
> name makes sense) pragma
> 2) Those of us who care can then work to ensure that our code is using
> these publicAPI methods when possible.  This will also help drive out
> some of our own bad behavior where we were calling things that we really
> shouldn't have been.
> 3) Time passes and life is good :-)
> 4) Down the line (Cuis 5.x, 6.x... whatever) Juan decides that #asString
> needs to change (who knows... unicode support... or maybe he just
> decides that #asString is the wrong way to do it)  Seeing that #asString
> is flagged publicAPI, he knows not to 'just do it' but rather make sure
> that the change gets called out in the release notes (after some mailing
> list discussion if he deems it worthwhile to do so... his call) and that
> since it will likely break code to probably wait for a major release.
>
> This also allows for deprecating things that are designated as
> publicAPI... just because something is public does not mean it always
> will be, just that the changes to things that are need to be
> communicated more richly.  For me, the documentation aspect of it is a
> nice to have secondary objective that falls out of it... getting to a
> stable core is the primary objective.  (i.e. we're not documenting for
> the sake of documenting)
>
> >
> > Cheers, Peter
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <pbpublist at gmail.com>
> > wrote:
> >         On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
> >         > Hi Doug,
> >         >
> >         > On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> >         > > On 19/07/2015 22:38, Phil (list) wrote:
> >         > >> 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 vaguely recall that many years ago there was a project
> >         called
> >         > > SmallInterfaces that let you define public interfaces to
> >         objects. (Or
> >         > > something like that). Would that be a good way to document
> >         the
> >         > > public/private api using code?
> >         > >
> >         > > (sorry for being so vague but I've been awake for 24+
> >         hours now)
> >         >
> >         > Thanks for the pointer. I took a look at it. It is quite
> >         like Java
> >         > interfaces. The tools are interesting. But I see several
> >         downsides:
> >         >
> >         > - Each interface is a class. Each method in the protocol is
> >         an actual
> >         > method. If we use this to document all public protocols in
> >         Cuis, it
> >         > would mean a lot of new classes and methods.
> >         > - The source code of (for example) OrderedCollection>>at:
> >         would not
> >         > include the information of it belonging to interface
> >         "Indexable".
> >         > Without additional support from tools users can't tell
> >         whether a message
> >         > is public protocol or not. And the base image / package
> >         maintainer can't
> >         > easily see he's about to change a public api.
> >         >
> >         > I think a method pragma, that includes the name of the
> >         protocol avoids
> >         > these issues and is a better choice.
> >         >
> >
> >
> >         I agree.  Let's keep it as simple as possible and see how far
> >         that gets
> >         us.
> >
> >         > 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
>
>
>
> _______________________________________________
> 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/20150805/81e6c93d/attachment-0003.html>

From dnorton at mindspring.com  Wed Aug  5 16:03:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 05 Aug 2015 17:03:56 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C17955.7050807@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C13869.19799.1E03D95@dnorton.mindspring.com>,
	<55C17955.7050807@jvuletich.org>
Message-ID: <55C27A3C.10878.1AAF223@dnorton.mindspring.com>

On 4 Aug 2015 at 23:47, Juan Vuletich wrote:

> On 8/4/2015 7:10 PM, Dan Norton wrote:
> >
> >> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono
> or
> >> Inconsolata myself...
> >>
> > That would sure be great. When I started this journey many moons
> ago, Inconsolata was my
> > idea of a great font to have on Cuis.
> 
> Ok. Set up the AAFonts folder with contents. File in both cs'.
> Evaluate 
> [StrikeFont install: 'DejaVu Sans Mono']. I hope it works for you.
> 
> I didn't include Inconsolata because it doesn't have italics or
> bold, 
> and also because DejaVuSansMono looks quite better with Freetype.
>

Installs great, included in the alt+k menu of a TextEditor, looks great. Thanks, Juan.

Now I'll look into making list elements use DejaVuSansMono.

 - Dan



From dnorton at mindspring.com  Wed Aug  5 18:21:04 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 05 Aug 2015 19:21:04 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C17955.7050807@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C13869.19799.1E03D95@dnorton.mindspring.com>,
	<55C17955.7050807@jvuletich.org>
Message-ID: <55C29A60.17211.22880DD@dnorton.mindspring.com>

On 4 Aug 2015 at 23:47, Juan Vuletich wrote:

> On 8/4/2015 7:10 PM, Dan Norton wrote:
> >
> >> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono
> or
> >> Inconsolata myself...
> >>
> > That would sure be great. When I started this journey many moons
> ago, Inconsolata was my
> > idea of a great font to have on Cuis.
> 
> Ok. Set up the AAFonts folder with contents. File in both cs'.
> Evaluate 
> [StrikeFont install: 'DejaVu Sans Mono']. I hope it works for you.
> 
> I didn't include Inconsolata because it doesn't have italics or
> bold, 
> and also because DejaVuSansMono looks quite better with Freetype.
> 

Hi Juan,

This is very nice. It's a pleasure to use this fixed-width font.  Your changesets and the zip are 
on:

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

in case anyone wants the font before the next Cuis update :)
The Readme explains how to install it, including how to make a PluggableListMorph use it. 
Please excuse the other clutter in the repo.

 - Dan



From dnorton at mindspring.com  Tue Aug 11 20:53:45 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 11 Aug 2015 21:53:45 -0400
Subject: [Cuis] MNU: String>>skipTo:
Message-ID: <55CAA729.16634.269613E@dnorton.mindspring.com>

Some problems trying to the use Symbol class #readFrom: method:

	In the comment "Symbol readFromString: '#abc'", #readFromString: is unknown

	changing it to #readFrom: gets MNU: String>>skipTo:

The method #skipTo: is in PositionableStream but String is not in that hierarchy. However, 
this works:

	Object readFrom: (ReadStream on: '#abc')

In Squeak, "Symbol readFromString: '#abc'" answers #abc.

 - Dan



From Ken.Dickey at whidbey.com  Tue Aug 11 21:13:11 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 11 Aug 2015 19:13:11 -0700
Subject: [Cuis] Solitaire Update
Message-ID: <20150811191311.9978a35a320fbf1b1c1d6932@whidbey.com>

I noted that the Hand no longer gives dropShadows to morphs it picks up.

Not a big deal, but I missed this in Solitaire, so I gave the cards back their shadows.

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

FYI,
-KenD



From pbpublist at gmail.com  Wed Aug 12 16:36:10 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 12 Aug 2015 17:36:10 -0400
Subject: [Cuis] Curious drawing performance issue
Message-ID: <1439415370.2388.20.camel@gmail.com>

I noticed a while back that something appeared to be going on with Cuis
drawing performance (at idle on my system Morphic consumes ~20% of VM
CPU *miniumum* according to ProcessBrowser) and this seems to give an
indication of what it's currently costing in drawing performance...

After seeing the Squeak 5.0 announcement, I was curious to see roughly
how much of a speed boost we might be able to expect from Spur down the
road.  So I decided to look at BouncingAtomsMorph to try to get a rough
apples-to-apples comparison and was quite surprised: Spur was faster,
but it was too much faster.  So I dropped back to Squeak 4.5 and it also
performs much, much better than the Cuis version on the same VM.   Here
are the numbers I'm seeing using BouncingAtomsMorph with roughly
comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
Cuis 2440 (Cog VM 15.25.3390): 6-8 fps

Granted BouncingAtomsMorph is not 100% identical from a source code
standpoint but it's not nearly different enough where I'd expect that
sort of difference.  Is this a platform-specific issue (I'm on Linux) or
are others noticing drawing issues as well?




From pbpublist at gmail.com  Wed Aug 12 16:44:42 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 12 Aug 2015 17:44:42 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439415370.2388.20.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>
Message-ID: <1439415882.2388.22.camel@gmail.com>

I should also mention that the Morph window is ~ 500x450 and #stepTime
is set to 0 for anyone who wants to try to replicate...

On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> I noticed a while back that something appeared to be going on with Cuis
> drawing performance (at idle on my system Morphic consumes ~20% of VM
> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> indication of what it's currently costing in drawing performance...
> 
> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> how much of a speed boost we might be able to expect from Spur down the
> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> apples-to-apples comparison and was quite surprised: Spur was faster,
> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> performs much, much better than the Cuis version on the same VM.   Here
> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> 
> Granted BouncingAtomsMorph is not 100% identical from a source code
> standpoint but it's not nearly different enough where I'd expect that
> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> are others noticing drawing issues as well?





From dnorton at mindspring.com  Wed Aug 12 21:17:16 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 12 Aug 2015 22:17:16 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439415882.2388.22.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<1439415882.2388.22.camel@gmail.com>
Message-ID: <55CBFE2C.3950.28469D6@dnorton.mindspring.com>

Hi Phil,

On Windows 7 with Cuis loaded and idle, Windows Task Manager > Performance reports 0% 
CPU Usage. Memory Usage is 1.28 GB.

With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000 the report is 24 - 
25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.

Cuis 4.2 2449, cogwin 15.22.3370

 - Dan

On 12 Aug 2015 at 17:44, Phil (list) wrote:

> I should also mention that the Morph window is ~ 500x450 and
> #stepTime
> is set to 0 for anyone who wants to try to replicate...
> 
> On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > I noticed a while back that something appeared to be going on with
> Cuis
> > drawing performance (at idle on my system Morphic consumes ~20% of
> VM
> > CPU *miniumum* according to ProcessBrowser) and this seems to give
> an
> > indication of what it's currently costing in drawing
> performance...
> > 
> > After seeing the Squeak 5.0 announcement, I was curious to see
> roughly
> > how much of a speed boost we might be able to expect from Spur
> down the
> > road.  So I decided to look at BouncingAtomsMorph to try to get a
> rough
> > apples-to-apples comparison and was quite surprised: Spur was
> faster,
> > but it was too much faster.  So I dropped back to Squeak 4.5 and
> it also
> > performs much, much better than the Cuis version on the same VM.  
> Here
> > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > comparable (i.e. eyeballed) morph sizes and atom count set to
> 5000:
> > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > 
> > Granted BouncingAtomsMorph is not 100% identical from a source
> code
> > standpoint but it's not nearly different enough where I'd expect
> that
> > sort of difference.  Is this a platform-specific issue (I'm on
> Linux) or
> > are others noticing drawing issues as well?
> 
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From pbpublist at gmail.com  Thu Aug 13 01:29:40 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 13 Aug 2015 02:29:40 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CBFE2C.3950.28469D6@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>
	, <1439415882.2388.22.camel@gmail.com>
	<55CBFE2C.3950.28469D6@dnorton.mindspring.com>
Message-ID: <1439447380.2388.26.camel@gmail.com>

Dan,


On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> Hi Phil,
> 
> On Windows 7 with Cuis loaded and idle, Windows Task Manager > Performance reports 0% 
> CPU Usage. Memory Usage is 1.28 GB.
> 

What does the cpu usage show via World Menu -> Open... -> Process
Browser for Morphic?

> With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000 the report is 24 - 
> 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> 

OK, so it's not platform specific poor performance.  If you close the
BouncingAtomsMorph and wait for things to settle for a few seconds, what
does Process Browser show the Morphic cpu usage as??

> Cuis 4.2 2449, cogwin 15.22.3370
> 
>  - Dan
> 

Thanks,
Phil

> On 12 Aug 2015 at 17:44, Phil (list) wrote:
> 
> > I should also mention that the Morph window is ~ 500x450 and
> > #stepTime
> > is set to 0 for anyone who wants to try to replicate...
> > 
> > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > I noticed a while back that something appeared to be going on with
> > Cuis
> > > drawing performance (at idle on my system Morphic consumes ~20% of
> > VM
> > > CPU *miniumum* according to ProcessBrowser) and this seems to give
> > an
> > > indication of what it's currently costing in drawing
> > performance...
> > > 
> > > After seeing the Squeak 5.0 announcement, I was curious to see
> > roughly
> > > how much of a speed boost we might be able to expect from Spur
> > down the
> > > road.  So I decided to look at BouncingAtomsMorph to try to get a
> > rough
> > > apples-to-apples comparison and was quite surprised: Spur was
> > faster,
> > > but it was too much faster.  So I dropped back to Squeak 4.5 and
> > it also
> > > performs much, much better than the Cuis version on the same VM.  
> > Here
> > > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > > comparable (i.e. eyeballed) morph sizes and atom count set to
> > 5000:
> > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > 
> > > Granted BouncingAtomsMorph is not 100% identical from a source
> > code
> > > standpoint but it's not nearly different enough where I'd expect
> > that
> > > sort of difference.  Is this a platform-specific issue (I'm on
> > Linux) or
> > > are others noticing drawing issues as well?
> > 
> > 
> > 
> > _______________________________________________
> > 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  Thu Aug 13 10:11:36 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 13 Aug 2015 11:11:36 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439447380.2388.26.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CBFE2C.3950.28469D6@dnorton.mindspring.com>,
	<1439447380.2388.26.camel@gmail.com>
Message-ID: <55CCB3A8.12664.2E45B7@dnorton.mindspring.com>

On 13 Aug 2015 at 2:29, Phil (list) wrote:

> Dan,
> 
> 
> On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > Hi Phil,
> > 
> > On Windows 7 with Cuis loaded and idle, Windows Task Manager >
> Performance reports 0% 
> > CPU Usage. Memory Usage is 1.28 GB.
> > 
> 
> What does the cpu usage show via World Menu -> Open... -> Process
> Browser for Morphic?
> 

It shows 12%.

> > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000
> the report is 24 - 
> > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > 
> 
> OK, so it's not platform specific poor performance.  If you close
> the
> BouncingAtomsMorph and wait for things to settle for a few seconds,
> what
> does Process Browser show the Morphic cpu usage as??
>

It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to measure absolute as 
opposed to relative CPU usage seems inaccurate to me. The /difference/ in Process Browser 
numbers while atoms is running vs not running agree with Win7: 1 - 2%.

I don't like for something to try to measure its own performance :-) - an independent 
instrument is preferable IMHO.
 
> > Cuis 4.2 2449, cogwin 15.22.3370
> > 
> >  - Dan
> > 
> 
> Thanks,
> Phil
> 
> > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > 
> > > I should also mention that the Morph window is ~ 500x450 and
> > > #stepTime
> > > is set to 0 for anyone who wants to try to replicate...
> > > 
> > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > I noticed a while back that something appeared to be going on
> with
> > > Cuis
> > > > drawing performance (at idle on my system Morphic consumes
> ~20% of
> > > VM
> > > > CPU *miniumum* according to ProcessBrowser) and this seems to
> give
> > > an
> > > > indication of what it's currently costing in drawing
> > > performance...
> > > > 
> > > > After seeing the Squeak 5.0 announcement, I was curious to
> see
> > > roughly
> > > > how much of a speed boost we might be able to expect from
> Spur
> > > down the
> > > > road.  So I decided to look at BouncingAtomsMorph to try to
> get a
> > > rough
> > > > apples-to-apples comparison and was quite surprised: Spur
> was
> > > faster,
> > > > but it was too much faster.  So I dropped back to Squeak 4.5
> and
> > > it also
> > > > performs much, much better than the Cuis version on the same
> VM.  
> > > Here
> > > > are the numbers I'm seeing using BouncingAtomsMorph with
> roughly
> > > > comparable (i.e. eyeballed) morph sizes and atom count set
> to
> > > 5000:
> > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > 
> > > > Granted BouncingAtomsMorph is not 100% identical from a
> source
> > > code
> > > > standpoint but it's not nearly different enough where I'd
> expect
> > > that
> > > > sort of difference.  Is this a platform-specific issue (I'm
> on
> > > Linux) or
> > > > are others noticing drawing issues as well?
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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 sean at clipperadams.com  Thu Aug 13 11:00:28 2015
From: sean at clipperadams.com (Sean P. DeNigris)
Date: Thu, 13 Aug 2015 09:00:28 -0700 (PDT)
Subject: [Cuis] Wish Feedback
In-Reply-To: <D1E757FC.15B3C%edgardec2005@gmail.com>
References: <D1E757FC.15B3C%edgardec2005@gmail.com>
Message-ID: <1439481628951-4842594.post@n4.nabble.com>

Edgar De Cleene wrote
> www.squeakros.org

I visited, but wasn't sure what to do there. I tried to sign up, which hung
indefinitely. Then clicked the Help link, which seemed to do nothing.



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Wish-Feedback-tp4841005p4842594.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From eliot.miranda at gmail.com  Thu Aug 13 13:11:09 2015
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Thu, 13 Aug 2015 11:11:09 -0700
Subject: [Cuis] Suggestion for a performance analysis project,
	suitable for a masters student
Message-ID: <CAC20JE2Pac5-SpYjRA+k_PwB8POZbaAdVJXxG8rNtuWh2OMvHQ@mail.gmail.com>

Hi All,

    I had occasion to compare VW (vw7.7nc) and Spur recently and was
pleasantly surprised to see that Spur is on average -40% faster than VW on
a large subset of the benchmarks from the shootout (I didn't include three
because of Regex syntax issues).  Now Spur gets some of its speed from
having direct pointers vs VisualWorks' object header/table indirection, but
it could get other speedups from various other differences.  It would be
great to know exactly how much speedup comes from what, and indeed how much
cost Sour pays for its lazy become:.  I'd like to propose a project to
exactly determine the costs of an explicit read barrier and of lazy
forwarding compared to no check at all.

Spur, part of VMMaker.oscog, is implemented by a hierarchy of classes that
implement a 32-bit and a 64-bit memory manager.  Spur is a sibling to the
old ObjectMemory class that implements the V3 object representation.  The
current Spur does "lazy forwarding" where two objects are become by cloning
each object, making the old versions point to the opposite copy, and
relying on send-time checks to lazily follow forwarding pointers when sends
to forwarded objects fail a message lookup.

The project would create two additional variations on Spur, both of which
dispense with the lazy check.  One would explicitly test for a forwarding
pointers on every access, and one would never check, not need send-time
checking either and would reimplement become: like the old ObjectMemory, by
scanning the entire heap to exchange all references.

These variations could be implemented as subclasses or siblings of Spur.
The project isn't trivial because it also means making changes to the JIT,
albeit within its framework for multiple object representations.  Because
this is probably some months' work I can't do it myself but I'm extremely
interested in the results and I think it would make a really good paper,
e.g. for ISMM, or one of the dynamic language workshops.

If what I've said makes any sense at all to any academics out there who are
looking for a challenging but nicely contained and far from open ended
Masters project then please get in touch and we can see if we can take this
any further.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150813/3cb17141/attachment-0003.html>

From pbpublist at gmail.com  Thu Aug 13 15:01:17 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 13 Aug 2015 16:01:17 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CCB3A8.12664.2E45B7@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>
	, <55CBFE2C.3950.28469D6@dnorton.mindspring.com>
	, <1439447380.2388.26.camel@gmail.com>
	<55CCB3A8.12664.2E45B7@dnorton.mindspring.com>
Message-ID: <1439496077.2388.46.camel@gmail.com>

On Thu, 2015-08-13 at 11:11 -0400, Dan Norton wrote:
> On 13 Aug 2015 at 2:29, Phil (list) wrote:
> 
> > Dan,
> > 
> > 
> > On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > > Hi Phil,
> > > 
> > > On Windows 7 with Cuis loaded and idle, Windows Task Manager >
> > Performance reports 0% 
> > > CPU Usage. Memory Usage is 1.28 GB.
> > > 
> > 
> > What does the cpu usage show via World Menu -> Open... -> Process
> > Browser for Morphic?
> > 
> 
> It shows 12%.
> 
> > > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000
> > the report is 24 - 
> > > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > > 
> > 
> > OK, so it's not platform specific poor performance.  If you close
> > the
> > BouncingAtomsMorph and wait for things to settle for a few seconds,
> > what
> > does Process Browser show the Morphic cpu usage as??
> >
> 
> It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to measure absolute as 
> opposed to relative CPU usage seems inaccurate to me. The /difference/ in Process Browser 
> numbers while atoms is running vs not running agree with Win7: 1 - 2%.
> 
> I don't like for something to try to measure its own performance :-) - an independent 
> instrument is preferable IMHO.

True, the external monitoring tools will tend to give you a better
absolute picture as there may be some VM overhead (esp if plugins are
involved) that Process Browser can't see.  However, CPU utilization as
reported by the OS isn't terribly helpful unless you know how many cores
the system has, was anything else active at the time, etc.
ProcessBrowser, while limited, avoids all that since it shows what was
used vs what was available to it. (usually 100/<num cores> % of total
system CPU)  Just seemed to make for a better apples to apples
comparison in this case to see if you are having the same issue re:
Morphic chewing up cycles while otherwise 'idle'.

>  
> > > Cuis 4.2 2449, cogwin 15.22.3370
> > > 
> > >  - Dan
> > > 
> > 
> > Thanks,
> > Phil
> > 
> > > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > > 
> > > > I should also mention that the Morph window is ~ 500x450 and
> > > > #stepTime
> > > > is set to 0 for anyone who wants to try to replicate...
> > > > 
> > > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > > I noticed a while back that something appeared to be going on
> > with
> > > > Cuis
> > > > > drawing performance (at idle on my system Morphic consumes
> > ~20% of
> > > > VM
> > > > > CPU *miniumum* according to ProcessBrowser) and this seems to
> > give
> > > > an
> > > > > indication of what it's currently costing in drawing
> > > > performance...
> > > > > 
> > > > > After seeing the Squeak 5.0 announcement, I was curious to
> > see
> > > > roughly
> > > > > how much of a speed boost we might be able to expect from
> > Spur
> > > > down the
> > > > > road.  So I decided to look at BouncingAtomsMorph to try to
> > get a
> > > > rough
> > > > > apples-to-apples comparison and was quite surprised: Spur
> > was
> > > > faster,
> > > > > but it was too much faster.  So I dropped back to Squeak 4.5
> > and
> > > > it also
> > > > > performs much, much better than the Cuis version on the same
> > VM.  
> > > > Here
> > > > > are the numbers I'm seeing using BouncingAtomsMorph with
> > roughly
> > > > > comparable (i.e. eyeballed) morph sizes and atom count set
> > to
> > > > 5000:
> > > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > > 
> > > > > Granted BouncingAtomsMorph is not 100% identical from a
> > source
> > > > code
> > > > > standpoint but it's not nearly different enough where I'd
> > expect
> > > > that
> > > > > sort of difference.  Is this a platform-specific issue (I'm
> > on
> > > > Linux) or
> > > > > are others noticing drawing issues as well?
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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 dnorton at mindspring.com  Fri Aug 14 11:42:57 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 14 Aug 2015 12:42:57 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439496077.2388.46.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CCB3A8.12664.2E45B7@dnorton.mindspring.com>,
	<1439496077.2388.46.camel@gmail.com>
Message-ID: <55CE1A91.6602.5A1F06@dnorton.mindspring.com>

On 13 Aug 2015 at 16:01, Phil (list) wrote:

> On Thu, 2015-08-13 at 11:11 -0400, Dan Norton wrote:
> > On 13 Aug 2015 at 2:29, Phil (list) wrote:
> > 
> > > Dan,
> > > 
> > > 
> > > On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > > > Hi Phil,
> > > > 
> > > > On Windows 7 with Cuis loaded and idle, Windows Task Manager
> >
> > > Performance reports 0% 
> > > > CPU Usage. Memory Usage is 1.28 GB.
> > > > 
> > > 
> > > What does the cpu usage show via World Menu -> Open... ->
> Process
> > > Browser for Morphic?
> > > 
> > 
> > It shows 12%.
> > 
> > > > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms
> 5000
> > > the report is 24 - 
> > > > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > > > 
> > > 
> > > OK, so it's not platform specific poor performance.  If you
> close
> > > the
> > > BouncingAtomsMorph and wait for things to settle for a few
> seconds,
> > > what
> > > does Process Browser show the Morphic cpu usage as??
> > >
> > 
> > It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to
> measure absolute as 
> > opposed to relative CPU usage seems inaccurate to me. The
> /difference/ in Process Browser 
> > numbers while atoms is running vs not running agree with Win7: 1 -
> 2%.
> > 
> > I don't like for something to try to measure its own performance
> :-) - an independent 
> > instrument is preferable IMHO.
> 
> True, the external monitoring tools will tend to give you a better
> absolute picture as there may be some VM overhead (esp if plugins
> are
> involved) that Process Browser can't see.  However, CPU utilization
> as
> reported by the OS isn't terribly helpful unless you know how many
> cores
> the system has, was anything else active at the time, etc.
> ProcessBrowser, while limited, avoids all that since it shows what
> was
> used vs what was available to it. (usually 100/<num cores> % of
> total
> system CPU)  Just seemed to make for a better apples to apples
> comparison in this case to see if you are having the same issue
> re:
> Morphic chewing up cycles while otherwise 'idle'.
> 

Rummaging around in my system reveals:

Microsoft Windows 7 Home Premium
6.1.7601 Service Pack 1

Intel(R) Core(TM) i3-2125 CPU @
3.30 GHz

All Programs>Accessories>System Tools>Resource Monitor shows:

an appalling (to me, at least) >170 threads "if the only tool you have is a hammer, every 
problem looks like a nail" sitting there quietly for the most part. Resource Monitor shows four 
"CPUs" with CPU 1 and CPU 3 parked. Total CPU usage < 1%.

When Cuis is started, the Squeak.exe starts out with 17 threads, then eventually settles to 6 
threads. Total CPU usage < 1%.

When BouncingAtoms is running, set up as above, CPU 1 and CPU 3 remain parked, CPU 0 
< 5%, and CPU 2 > 95%. Occasionally something (GC?) cranks CPU 0 to 85 - 90% briefly.

When BouncingAtoms is stopped, all return to CPU 0 < 5%, CPU 2 <1%, CPU 1 and CPU 3 
parked.

So, the question is why should Cuis process browser report that Morphic UI is consuming 10 
- 14% ?

> >  
> > > > Cuis 4.2 2449, cogwin 15.22.3370
> > > > 
> > > >  - Dan
> > > > 
> > > 
> > > Thanks,
> > > Phil
> > > 
> > > > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > > > 
> > > > > I should also mention that the Morph window is ~ 500x450
> and
> > > > > #stepTime
> > > > > is set to 0 for anyone who wants to try to replicate...
> > > > > 
> > > > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > > > I noticed a while back that something appeared to be going
> on
> > > with
> > > > > Cuis
> > > > > > drawing performance (at idle on my system Morphic
> consumes
> > > ~20% of
> > > > > VM
> > > > > > CPU *miniumum* according to ProcessBrowser) and this seems
> to
> > > give
> > > > > an
> > > > > > indication of what it's currently costing in drawing
> > > > > performance...
> > > > > > 
> > > > > > After seeing the Squeak 5.0 announcement, I was curious
> to
> > > see
> > > > > roughly
> > > > > > how much of a speed boost we might be able to expect
> from
> > > Spur
> > > > > down the
> > > > > > road.  So I decided to look at BouncingAtomsMorph to try
> to
> > > get a
> > > > > rough
> > > > > > apples-to-apples comparison and was quite surprised:
> Spur
> > > was
> > > > > faster,
> > > > > > but it was too much faster.  So I dropped back to Squeak
> 4.5
> > > and
> > > > > it also
> > > > > > performs much, much better than the Cuis version on the
> same
> > > VM.  
> > > > > Here
> > > > > > are the numbers I'm seeing using BouncingAtomsMorph with
> > > roughly
> > > > > > comparable (i.e. eyeballed) morph sizes and atom count
> set
> > > to
> > > > > 5000:
> > > > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > > > 
> > > > > > Granted BouncingAtomsMorph is not 100% identical from a
> > > source
> > > > > code
> > > > > > standpoint but it's not nearly different enough where
> I'd
> > > expect
> > > > > that
> > > > > > sort of difference.  Is this a platform-specific issue
> (I'm
> > > on
> > > > > Linux) or
> > > > > > are others noticing drawing issues as well?
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > 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 pbpublist at gmail.com  Fri Aug 14 13:50:52 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 14 Aug 2015 14:50:52 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CE1A91.6602.5A1F06@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>
	, <55CCB3A8.12664.2E45B7@dnorton.mindspring.com>
	, <1439496077.2388.46.camel@gmail.com>
	<55CE1A91.6602.5A1F06@dnorton.mindspring.com>
Message-ID: <1439578252.2318.8.camel@gmail.com>

On Fri, 2015-08-14 at 12:42 -0400, Dan Norton wrote:
> On 13 Aug 2015 at 16:01, Phil (list) wrote:
> 
> > On Thu, 2015-08-13 at 11:11 -0400, Dan Norton wrote:
> > > On 13 Aug 2015 at 2:29, Phil (list) wrote:
> > > 
> > > > Dan,
> > > > 
> > > > 
> > > > On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > > > > Hi Phil,
> > > > > 
> > > > > On Windows 7 with Cuis loaded and idle, Windows Task Manager
> > >
> > > > Performance reports 0% 
> > > > > CPU Usage. Memory Usage is 1.28 GB.
> > > > > 
> > > > 
> > > > What does the cpu usage show via World Menu -> Open... ->
> > Process
> > > > Browser for Morphic?
> > > > 
> > > 
> > > It shows 12%.
> > > 
> > > > > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms
> > 5000
> > > > the report is 24 - 
> > > > > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > > > > 
> > > > 
> > > > OK, so it's not platform specific poor performance.  If you
> > close
> > > > the
> > > > BouncingAtomsMorph and wait for things to settle for a few
> > seconds,
> > > > what
> > > > does Process Browser show the Morphic cpu usage as??
> > > >
> > > 
> > > It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to
> > measure absolute as 
> > > opposed to relative CPU usage seems inaccurate to me. The
> > /difference/ in Process Browser 
> > > numbers while atoms is running vs not running agree with Win7: 1 -
> > 2%.
> > > 
> > > I don't like for something to try to measure its own performance
> > :-) - an independent 
> > > instrument is preferable IMHO.
> > 
> > True, the external monitoring tools will tend to give you a better
> > absolute picture as there may be some VM overhead (esp if plugins
> > are
> > involved) that Process Browser can't see.  However, CPU utilization
> > as
> > reported by the OS isn't terribly helpful unless you know how many
> > cores
> > the system has, was anything else active at the time, etc.
> > ProcessBrowser, while limited, avoids all that since it shows what
> > was
> > used vs what was available to it. (usually 100/<num cores> % of
> > total
> > system CPU)  Just seemed to make for a better apples to apples
> > comparison in this case to see if you are having the same issue
> > re:
> > Morphic chewing up cycles while otherwise 'idle'.
> > 
> 
> Rummaging around in my system reveals:
> 
> Microsoft Windows 7 Home Premium
> 6.1.7601 Service Pack 1
> 
> Intel(R) Core(TM) i3-2125 CPU @
> 3.30 GHz
> 
> All Programs>Accessories>System Tools>Resource Monitor shows:
> 
> an appalling (to me, at least) >170 threads "if the only tool you have is a hammer, every 
> problem looks like a nail" sitting there quietly for the most part. Resource Monitor shows four 
> "CPUs" with CPU 1 and CPU 3 parked. Total CPU usage < 1%.
> 

So you've got a dual core processor with hyperthreading (4 logical
cores)...

> When Cuis is started, the Squeak.exe starts out with 17 threads, then eventually settles to 6 
> threads. Total CPU usage < 1%.
> 
> When BouncingAtoms is running, set up as above, CPU 1 and CPU 3 remain parked, CPU 0 
> < 5%, and CPU 2 > 95%. Occasionally something (GC?) cranks CPU 0 to 85 - 90% briefly.
> 
> When BouncingAtoms is stopped, all return to CPU 0 < 5%, CPU 2 <1%, CPU 1 and CPU 3 
> parked.
> 

Given your above processor info, divide the 10-14% (the idle usage
reported by Cuis) by 4 to get what you should roughly be seeing in
overall system CPU utilization (i.e. 2.5-3.5%, assuming not much else is
going on on the system)  Since the Squeak VM is single threaded for
Smalltalk code the most you should ever see when Cuis is fully busy is
~25% CPU utilization (i.e. 100% of a single core)

> So, the question is why should Cuis process browser report that Morphic UI is consuming 10 
> - 14% ?
> 

That is the question and it relates to why BouncingAtomsMorph is
performing so poorly in Cuis vs. Squeak.  Something is going on (even
when Cuis is 'idle')...

> > >  
> > > > > Cuis 4.2 2449, cogwin 15.22.3370
> > > > > 
> > > > >  - Dan
> > > > > 
> > > > 
> > > > Thanks,
> > > > Phil
> > > > 
> > > > > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > > > > 
> > > > > > I should also mention that the Morph window is ~ 500x450
> > and
> > > > > > #stepTime
> > > > > > is set to 0 for anyone who wants to try to replicate...
> > > > > > 
> > > > > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > > > > I noticed a while back that something appeared to be going
> > on
> > > > with
> > > > > > Cuis
> > > > > > > drawing performance (at idle on my system Morphic
> > consumes
> > > > ~20% of
> > > > > > VM
> > > > > > > CPU *miniumum* according to ProcessBrowser) and this seems
> > to
> > > > give
> > > > > > an
> > > > > > > indication of what it's currently costing in drawing
> > > > > > performance...
> > > > > > > 
> > > > > > > After seeing the Squeak 5.0 announcement, I was curious
> > to
> > > > see
> > > > > > roughly
> > > > > > > how much of a speed boost we might be able to expect
> > from
> > > > Spur
> > > > > > down the
> > > > > > > road.  So I decided to look at BouncingAtomsMorph to try
> > to
> > > > get a
> > > > > > rough
> > > > > > > apples-to-apples comparison and was quite surprised:
> > Spur
> > > > was
> > > > > > faster,
> > > > > > > but it was too much faster.  So I dropped back to Squeak
> > 4.5
> > > > and
> > > > > > it also
> > > > > > > performs much, much better than the Cuis version on the
> > same
> > > > VM.  
> > > > > > Here
> > > > > > > are the numbers I'm seeing using BouncingAtomsMorph with
> > > > roughly
> > > > > > > comparable (i.e. eyeballed) morph sizes and atom count
> > set
> > > > to
> > > > > > 5000:
> > > > > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > > > > 
> > > > > > > Granted BouncingAtomsMorph is not 100% identical from a
> > > > source
> > > > > > code
> > > > > > > standpoint but it's not nearly different enough where
> > I'd
> > > > expect
> > > > > > that
> > > > > > > sort of difference.  Is this a platform-specific issue
> > (I'm
> > > > on
> > > > > > Linux) or
> > > > > > > are others noticing drawing issues as well?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > 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
> 
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Sat Aug 15 08:24:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 10:24:01 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439415370.2388.20.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>
Message-ID: <55CF3D71.6040204@jvuletich.org>

Hi Phil,

I won't spoil your fun, so instead of explaining the difference between 
Squeak and Cuis here, I give you a suggestion: Use the profiler.

Cheers,
Juan Vuletich

On 8/12/2015 6:36 PM, Phil (list) wrote:
> I noticed a while back that something appeared to be going on with Cuis
> drawing performance (at idle on my system Morphic consumes ~20% of VM
> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> indication of what it's currently costing in drawing performance...
>
> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> how much of a speed boost we might be able to expect from Spur down the
> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> apples-to-apples comparison and was quite surprised: Spur was faster,
> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> performs much, much better than the Cuis version on the same VM.   Here
> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
>
> Granted BouncingAtomsMorph is not 100% identical from a source code
> standpoint but it's not nearly different enough where I'd expect that
> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> are others noticing drawing issues as well?
>




From juan at jvuletich.org  Sat Aug 15 08:27:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 10:27:34 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CE1A91.6602.5A1F06@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CCB3A8.12664.2E45B7@dnorton.mindspring.com>,
	<1439496077.2388.46.camel@gmail.com>
	<55CE1A91.6602.5A1F06@dnorton.mindspring.com>
Message-ID: <55CF3E46.6020306@jvuletich.org>

The sum of percentages in the Cuis process browser is always 100%. What 
it is measured is how the time spent by the interpreter is split amongst 
Smalltalk processes.

Cheers,
Juan Vuletich

On 8/14/2015 1:42 PM, Dan Norton wrote:
> ...
> When BouncingAtoms is stopped, all return to CPU 0<  5%, CPU 2<1%, CPU 1 and CPU 3
> parked.
>
> So, the question is why should Cuis process browser report that Morphic UI is consuming 10
> - 14% ?




From dnorton at mindspring.com  Sat Aug 15 09:41:34 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 15 Aug 2015 10:41:34 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CF3E46.6020306@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CE1A91.6602.5A1F06@dnorton.mindspring.com>,
	<55CF3E46.6020306@jvuletich.org>
Message-ID: <55CF4F9E.23944.E8610@dnorton.mindspring.com>

Ahh of course. Stared at it but didn't see it :-)

Thanks,
 - Dan

On 15 Aug 2015 at 10:27, Juan Vuletich wrote:

> The sum of percentages in the Cuis process browser is always 100%.
> What 
> it is measured is how the time spent by the interpreter is split
> amongst 
> Smalltalk processes.
> 
> Cheers,
> Juan Vuletich
> 
> On 8/14/2015 1:42 PM, Dan Norton wrote:
> > ...
> > When BouncingAtoms is stopped, all return to CPU 0<  5%, CPU 2<1%,
> CPU 1 and CPU 3
> > parked.
> >
> > So, the question is why should Cuis process browser report that
> Morphic UI is consuming 10
> > - 14% ?
> 





From pbpublist at gmail.com  Sat Aug 15 14:40:34 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 15:40:34 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CF3D71.6040204@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org>
Message-ID: <1439667634.2323.3.camel@gmail.com>

On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> I won't spoil your fun, so instead of explaining the difference between 
> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> 

I will do that right... hey, where did the profiler option go in
ProcessBrowser?  Well, ok, I'll just do it manually with
#spyOnProcess:... grr!  I see it was taken out in 2409.  Now you're just
having fun with me...

> Cheers,
> Juan Vuletich
> 
> On 8/12/2015 6:36 PM, Phil (list) wrote:
> > I noticed a while back that something appeared to be going on with Cuis
> > drawing performance (at idle on my system Morphic consumes ~20% of VM
> > CPU *miniumum* according to ProcessBrowser) and this seems to give an
> > indication of what it's currently costing in drawing performance...
> >
> > After seeing the Squeak 5.0 announcement, I was curious to see roughly
> > how much of a speed boost we might be able to expect from Spur down the
> > road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> > apples-to-apples comparison and was quite surprised: Spur was faster,
> > but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> > performs much, much better than the Cuis version on the same VM.   Here
> > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> >
> > Granted BouncingAtomsMorph is not 100% identical from a source code
> > standpoint but it's not nearly different enough where I'd expect that
> > sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> > are others noticing drawing issues as well?
> >
> 





From juan at jvuletich.org  Sat Aug 15 15:56:36 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 17:56:36 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439667634.2323.3.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>	
	<55CF3D71.6040204@jvuletich.org>
	<1439667634.2323.3.camel@gmail.com>
Message-ID: <55CFA784.7070704@jvuletich.org>

On 8/15/2015 4:40 PM, Phil (list) wrote:
> On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
>> Hi Phil,
>>
>> I won't spoil your fun, so instead of explaining the difference between
>> Squeak and Cuis here, I give you a suggestion: Use the profiler.
>>
> I will do that right... hey, where did the profiler option go in
> ProcessBrowser?  Well, ok, I'll just do it manually with
> #spyOnProcess:... grr!  I see it was taken out in 2409.  Now you're just
> having fun with me...
>

Swear not. Use any of the class methods in the profiler: 
AndreasSystemProfiler. For example, something like

     AndreasSystemProfiler spyForMilliseconds: 200

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Sat Aug 15 15:58:24 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 16:58:24 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CF3D71.6040204@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org>
Message-ID: <1439672304.4789.9.camel@gmail.com>

On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> I won't spoil your fun, so instead of explaining the difference between 
> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> 

Given your comment it sounds like it's by design...

OK, so I reverted to an older build to get back the process-based
profiler and I can see that Cuis is doing a lot more drawing (work) than
Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
tooling to tell me what that work actually is.  What I think I see going
on is that Squeak is using the old region-based damage system while Cuis
appears to just be bit-blitting the entire frame each time? (I'll hold
off jumping up and down for joy until I get confirmation... if that's
what's going on, that is FANTASTIC!)

> Cheers,
> Juan Vuletich
> 
> On 8/12/2015 6:36 PM, Phil (list) wrote:
> > I noticed a while back that something appeared to be going on with Cuis
> > drawing performance (at idle on my system Morphic consumes ~20% of VM
> > CPU *miniumum* according to ProcessBrowser) and this seems to give an
> > indication of what it's currently costing in drawing performance...
> >
> > After seeing the Squeak 5.0 announcement, I was curious to see roughly
> > how much of a speed boost we might be able to expect from Spur down the
> > road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> > apples-to-apples comparison and was quite surprised: Spur was faster,
> > but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> > performs much, much better than the Cuis version on the same VM.   Here
> > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> >
> > Granted BouncingAtomsMorph is not 100% identical from a source code
> > standpoint but it's not nearly different enough where I'd expect that
> > sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> > are others noticing drawing issues as well?
> >
> 





From pbpublist at gmail.com  Sat Aug 15 16:07:44 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 17:07:44 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CFA784.7070704@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org> <1439667634.2323.3.camel@gmail.com>
	<55CFA784.7070704@jvuletich.org>
Message-ID: <1439672864.4789.10.camel@gmail.com>

On Sat, 2015-08-15 at 17:56 -0300, Juan Vuletich wrote:
> On 8/15/2015 4:40 PM, Phil (list) wrote:
> > On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> >> Hi Phil,
> >>
> >> I won't spoil your fun, so instead of explaining the difference between
> >> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> >>
> > I will do that right... hey, where did the profiler option go in
> > ProcessBrowser?  Well, ok, I'll just do it manually with
> > #spyOnProcess:... grr!  I see it was taken out in 2409.  Now you're just
> > having fun with me...
> >
> 
> Swear not. Use any of the class methods in the profiler: 
> AndreasSystemProfiler. For example, something like
> 
>      AndreasSystemProfiler spyForMilliseconds: 200
> 

segfault (stack overflow)...

> Cheers,
> Juan Vuletich





From juan at jvuletich.org  Sat Aug 15 16:39:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 18:39:53 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439672864.4789.10.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>	
	<55CF3D71.6040204@jvuletich.org>
	<1439667634.2323.3.camel@gmail.com>	
	<55CFA784.7070704@jvuletich.org>
	<1439672864.4789.10.camel@gmail.com>
Message-ID: <55CFB1A9.7050402@jvuletich.org>

On 8/15/2015 6:07 PM, Phil (list) wrote:
>
>> Swear not. Use any of the class methods in the profiler:
>> AndreasSystemProfiler. For example, something like
>>
>>       AndreasSystemProfiler spyForMilliseconds: 200
>>
> segfault (stack overflow)...
>

Use Cog 3370 or older. I reported the problem in VM-Dev, but nobody 
listened.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Aug 15 16:41:59 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 18:41:59 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439672304.4789.9.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>	
	<55CF3D71.6040204@jvuletich.org>
	<1439672304.4789.9.camel@gmail.com>
Message-ID: <55CFB227.9000806@jvuletich.org>

On 8/15/2015 5:58 PM, Phil (list) wrote:
> On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
>> Hi Phil,
>>
>> I won't spoil your fun, so instead of explaining the difference between
>> Squeak and Cuis here, I give you a suggestion: Use the profiler.
>>
> Given your comment it sounds like it's by design...
>
> OK, so I reverted to an older build to get back the process-based
> profiler and I can see that Cuis is doing a lot more drawing (work) than
> Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
> tooling to tell me what that work actually is.  What I think I see going
> on is that Squeak is using the old region-based damage system while Cuis
> appears to just be bit-blitting the entire frame each time? (I'll hold
> off jumping up and down for joy until I get confirmation... if that's
> what's going on, that is FANTASTIC!)
>

C'mon! Isn't it obvious in the profiler tree that the problem is using 
local coordinates and transforming them on each draw?

It is possible to optimize it back. It just requires some work.

Cheers,
Juan Vuletich

>> Cheers,
>> Juan Vuletich
>>
>> On 8/12/2015 6:36 PM, Phil (list) wrote:
>>> I noticed a while back that something appeared to be going on with Cuis
>>> drawing performance (at idle on my system Morphic consumes ~20% of VM
>>> CPU *miniumum* according to ProcessBrowser) and this seems to give an
>>> indication of what it's currently costing in drawing performance...
>>>
>>> After seeing the Squeak 5.0 announcement, I was curious to see roughly
>>> how much of a speed boost we might be able to expect from Spur down the
>>> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
>>> apples-to-apples comparison and was quite surprised: Spur was faster,
>>> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
>>> performs much, much better than the Cuis version on the same VM.   Here
>>> are the numbers I'm seeing using BouncingAtomsMorph with roughly
>>> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
>>> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
>>> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
>>> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
>>>
>>> Granted BouncingAtomsMorph is not 100% identical from a source code
>>> standpoint but it's not nearly different enough where I'd expect that
>>> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
>>> are others noticing drawing issues as well?
>>>
>
>




From pbpublist at gmail.com  Sat Aug 15 21:55:43 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 22:55:43 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CFB227.9000806@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org> <1439672304.4789.9.camel@gmail.com>
	<55CFB227.9000806@jvuletich.org>
Message-ID: <1439693743.2401.15.camel@gmail.com>

On Sat, 2015-08-15 at 18:41 -0300, Juan Vuletich wrote:
> On 8/15/2015 5:58 PM, Phil (list) wrote:
> > On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> >> Hi Phil,
> >>
> >> I won't spoil your fun, so instead of explaining the difference between
> >> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> >>
> > Given your comment it sounds like it's by design...
> >
> > OK, so I reverted to an older build to get back the process-based
> > profiler and I can see that Cuis is doing a lot more drawing (work) than
> > Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
> > tooling to tell me what that work actually is.  What I think I see going
> > on is that Squeak is using the old region-based damage system while Cuis
> > appears to just be bit-blitting the entire frame each time? (I'll hold
> > off jumping up and down for joy until I get confirmation... if that's
> > what's going on, that is FANTASTIC!)
> >
> 
> C'mon! Isn't it obvious in the profiler tree that the problem is using 
> local coordinates and transforming them on each draw?
> 

In the old profiler output (I went back to 2404 to get it), it didn't
jump out at me (the bounds related calls only appear to be <10% of the
time)  It could just be that I'm more dense than usual :-)

I can definitely see how that could cause a problem doing 1000s of local
to global conversions per frame...

> It is possible to optimize it back. It just requires some work.
> 

Fair enough... but I still think that things are generally off
performance-wise with Morphic... (it might just be that we've got a
bunch of fairly unoptimized code similar to what's going on with
BouncingAtomsMorph that will take some time to work through, but things
are definitely feeling slow-ish from a UI standpoint)

> Cheers,
> Juan Vuletich
> 
> >> Cheers,
> >> Juan Vuletich
> >>
> >> On 8/12/2015 6:36 PM, Phil (list) wrote:
> >>> I noticed a while back that something appeared to be going on with Cuis
> >>> drawing performance (at idle on my system Morphic consumes ~20% of VM
> >>> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> >>> indication of what it's currently costing in drawing performance...
> >>>
> >>> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> >>> how much of a speed boost we might be able to expect from Spur down the
> >>> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> >>> apples-to-apples comparison and was quite surprised: Spur was faster,
> >>> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> >>> performs much, much better than the Cuis version on the same VM.   Here
> >>> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> >>> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> >>> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> >>> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> >>> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> >>>
> >>> Granted BouncingAtomsMorph is not 100% identical from a source code
> >>> standpoint but it's not nearly different enough where I'd expect that
> >>> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> >>> are others noticing drawing issues as well?
> >>>
> >
> >
> 





From pbpublist at gmail.com  Sun Aug 16 03:11:10 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 04:11:10 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439693743.2401.15.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org> <1439672304.4789.9.camel@gmail.com>
	<55CFB227.9000806@jvuletich.org> <1439693743.2401.15.camel@gmail.com>
Message-ID: <1439712670.2401.23.camel@gmail.com>

On Sat, 2015-08-15 at 22:55 -0400, Phil (list) wrote:
> On Sat, 2015-08-15 at 18:41 -0300, Juan Vuletich wrote:
> > On 8/15/2015 5:58 PM, Phil (list) wrote:
> > > On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> > >> Hi Phil,
> > >>
> > >> I won't spoil your fun, so instead of explaining the difference between
> > >> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> > >>
> > > Given your comment it sounds like it's by design...
> > >
> > > OK, so I reverted to an older build to get back the process-based
> > > profiler and I can see that Cuis is doing a lot more drawing (work) than
> > > Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
> > > tooling to tell me what that work actually is.  What I think I see going
> > > on is that Squeak is using the old region-based damage system while Cuis
> > > appears to just be bit-blitting the entire frame each time? (I'll hold
> > > off jumping up and down for joy until I get confirmation... if that's
> > > what's going on, that is FANTASTIC!)
> > >
> > 
> > C'mon! Isn't it obvious in the profiler tree that the problem is using 
> > local coordinates and transforming them on each draw?
> > 
> 
> In the old profiler output (I went back to 2404 to get it), it didn't
> jump out at me (the bounds related calls only appear to be <10% of the
> time)  It could just be that I'm more dense than usual :-)
> 

'More dense than usual' it is:  I forgot to ratchet up the atom count
when I got profiling going.  *Then* the local/global conversions start
to dominate.  (The only reason I cranked them up that high originally
was to get some FPS distance between the Cog and Spur Squeak runs.  At
lower atom counts where drawing dominates, Cuis is still significantly
slower than Squeak running on Cog)

> I can definitely see how that could cause a problem doing 1000s of local
> to global conversions per frame...
> 
> > It is possible to optimize it back. It just requires some work.
> > 
> 
> Fair enough... but I still think that things are generally off
> performance-wise with Morphic... (it might just be that we've got a
> bunch of fairly unoptimized code similar to what's going on with
> BouncingAtomsMorph that will take some time to work through, but things
> are definitely feeling slow-ish from a UI standpoint)
> 
> > Cheers,
> > Juan Vuletich
> > 
> > >> Cheers,
> > >> Juan Vuletich
> > >>
> > >> On 8/12/2015 6:36 PM, Phil (list) wrote:
> > >>> I noticed a while back that something appeared to be going on with Cuis
> > >>> drawing performance (at idle on my system Morphic consumes ~20% of VM
> > >>> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> > >>> indication of what it's currently costing in drawing performance...
> > >>>
> > >>> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> > >>> how much of a speed boost we might be able to expect from Spur down the
> > >>> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> > >>> apples-to-apples comparison and was quite surprised: Spur was faster,
> > >>> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> > >>> performs much, much better than the Cuis version on the same VM.   Here
> > >>> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > >>> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> > >>> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > >>> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > >>> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > >>>
> > >>> Granted BouncingAtomsMorph is not 100% identical from a source code
> > >>> standpoint but it's not nearly different enough where I'd expect that
> > >>> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> > >>> are others noticing drawing issues as well?
> > >>>
> > >
> > >
> > 
> 





From juan at jvuletich.org  Sun Aug 16 10:08:04 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 16 Aug 2015 12:08:04 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph performance
Message-ID: <55D0A754.2070602@jvuletich.org>

Hi Folks,

Yesterday and today I pushed new stuff to github. See the attach. Cuis 
can now display both underscores and left arrows in the same method!

I also could not help it and worked on BouncingAtomsMorph performance. 
It should be close to Squeak now.

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis_underscores.png
Type: image/png
Size: 56056 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150816/60ccc446/attachment-0003.png>

From dnorton at mindspring.com  Sun Aug 16 13:02:24 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 14:02:24 -0400
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <55D0D030.28083.B5F605@dnorton.mindspring.com>

On 16 Aug 2015 at 12:08, Juan Vuletich wrote:

> Hi Folks,
> 
> Yesterday and today I pushed new stuff to github. See the attach.
> Cuis 
> can now display both underscores and left arrows in the same
> method!
> 
> I also could not help it and worked on BouncingAtomsMorph
> performance. 
> It should be close to Squeak now.
> 

No, it's faster. Much faster than Squeak in a side-by-side comparison.

 - Dan



From dnorton at mindspring.com  Sun Aug 16 13:33:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 14:33:56 -0400
Subject: [Cuis] Problem in VM-Dev
Message-ID: <55D0D794.31157.D2D674@dnorton.mindspring.com>

Hi Juan,

On 8/15/2015 Juan wrote: 
>On 8/15/2015 6:07 PM, Phil (list) wrote: 
>>
>>> Swear not. Use any of the class methods in the profiler: 
>>> AndreasSystemProfiler. For example, something like 
>>>
>>> AndreasSystemProfiler spyForMilliseconds: 200 
>>>
>> segfault (stack overflow)... 
>>
>
>Use Cog 3370 or older. I reported the problem in VM-Dev, but nobody 
listened. 

I don't see where you reported the problem. Can you give me a specific reference? Maybe if 
more of us post it will get some attention. I searched

gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 

for your posts in 2015 but did not see it.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150816/51d3414b/attachment-0003.html>

From pbpublist at gmail.com  Sun Aug 16 13:44:22 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 14:44:22 -0400
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <1439750662.16738.6.camel@gmail.com>

On Sun, 2015-08-16 at 12:08 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> Yesterday and today I pushed new stuff to github. See the attach. Cuis 
> can now display both underscores and left arrows in the same method!
> 
> I also could not help it and worked on BouncingAtomsMorph performance. 
> It should be close to Squeak now.

It's definitely improved BouncingAtomsMorph (I'm seeing at least 13-17
FPS now.. I say 'at least' because from time to time it jumps up to the
low 20's).  But more importantly (to me, at least) at first glance it
looks like these changes provide an across the board performance boost
to my other Morphic code. (most of my stuff doesn't have FPS counters
but in looking at Morphic CPU utilization in ProcessBrowser, it's almost
always 5-10% lower now)

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





From pbpublist at gmail.com  Sun Aug 16 13:48:36 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 14:48:36 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <55D0D794.31157.D2D674@dnorton.mindspring.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>
Message-ID: <1439750916.16738.10.camel@gmail.com>

On Sun, 2015-08-16 at 14:33 -0400, Dan Norton wrote:
> Hi Juan,
> 
> 
> On 8/15/2015 Juan wrote: 
> >On 8/15/2015 6:07 PM, Phil (list) wrote: 
> >>
> >>> Swear not. Use any of the class methods in the profiler: 
> >>> AndreasSystemProfiler. For example, something like 
> >>>
> >>> AndreasSystemProfiler spyForMilliseconds: 200 
> >>>
> >> segfault (stack overflow)... 
> >>
> >
> >Use Cog 3370 or older. I reported the problem in VM-Dev, but nobody 
> listened. 
> 
> 
> 
> I don't see where you reported the problem. Can you give me a specific
> reference? Maybe if more of us post it will get some attention. I
> searched
> 
> 
I just posted a reply to it a few hours ago hoping for the same effect.
His original posts were on 7/20 and had 'Cog crash with
AndreasSystemProfiler' in the subject line.

On a related note, I'm having an issue with 3410 hanging the image while
loading packages while 3390 is working (aside from the profiler issue)
for me... it's always something.

> gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 
> 
> 
> 
> for your posts in 2015 but did not see it.
> 
> 
>  - Dan
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Sun Aug 16 15:58:03 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 16:58:03 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <1439750916.16738.10.camel@gmail.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>,
	<1439750916.16738.10.camel@gmail.com>
Message-ID: <55D0F95B.20890.156C93E@dnorton.mindspring.com>

Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following 30+ times successfully:

	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159 printString]].

Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+ times and the VM 
crashed with a stack exception. Dump attached.

Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the following 40+ times 
successfully:

	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].

What is the difference between AndreasSystemProfiler and MessageTally? Their output 
appears similar.

 - Dan

On 16 Aug 2015 at 14:48, Phil (list) wrote:

> On Sun, 2015-08-16 at 14:33 -0400, Dan Norton wrote:
> > Hi Juan,
> > 
> > 
> > On 8/15/2015 Juan wrote: 
> > >On 8/15/2015 6:07 PM, Phil (list) wrote: 
> > >>
> > >>> Swear not. Use any of the class methods in the profiler: 
> > >>> AndreasSystemProfiler. For example, something like 
> > >>>
> > >>> AndreasSystemProfiler spyForMilliseconds: 200 
> > >>>
> > >> segfault (stack overflow)... 
> > >>
> > >
> > >Use Cog 3370 or older. I reported the problem in VM-Dev, but
> nobody 
> > listened. 
> > 
> > 
> > 
> > I don't see where you reported the problem. Can you give me a
> specific
> > reference? Maybe if more of us post it will get some attention.
> I
> > searched
> > 
> > 
> I just posted a reply to it a few hours ago hoping for the same
> effect.
> His original posts were on 7/20 and had 'Cog crash with
> AndreasSystemProfiler' in the subject line.
> 
> On a related note, I'm having an issue with 3410 hanging the image
> while
> loading packages while 3390 is working (aside from the profiler
> issue)
> for me... it's always something.
> 
> > gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 
> > 
> > 
> > 
> > for your posts in 2015 but did not see it.
> > 
> > 
> >  - 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProfilerCrash.zip
Type: application/zip
Size: 3325 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150816/00fbdcd8/attachment-0003.zip>

From pbpublist at gmail.com  Sun Aug 16 16:21:12 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 17:21:12 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <55D0F95B.20890.156C93E@dnorton.mindspring.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>
	, <1439750916.16738.10.camel@gmail.com>
	<55D0F95B.20890.156C93E@dnorton.mindspring.com>
Message-ID: <1439760072.16738.23.camel@gmail.com>

On Sun, 2015-08-16 at 16:58 -0400, Dan Norton wrote:
> Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following 30+ times successfully:
> 
> 	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159 printString]].
> 
> Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+ times and the VM 
> crashed with a stack exception. Dump attached.
> 
> Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the following 40+ times 
> successfully:
> 
> 	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].
> 
> What is the difference between AndreasSystemProfiler and MessageTally? Their output 
> appears similar.

They perform the same function but ASP is more accurate (esp related to
primitives) and capable of higher resolution.  Here's a write up by
Eliot back when it was originally released:
http://forum.world.st/Re-squeak-dev-AndreasSystemProfiler-Released-MIT-td4665183.html

> 
>  - Dan
> 
> On 16 Aug 2015 at 14:48, Phil (list) wrote:
> 
> > On Sun, 2015-08-16 at 14:33 -0400, Dan Norton wrote:
> > > Hi Juan,
> > > 
> > > 
> > > On 8/15/2015 Juan wrote: 
> > > >On 8/15/2015 6:07 PM, Phil (list) wrote: 
> > > >>
> > > >>> Swear not. Use any of the class methods in the profiler: 
> > > >>> AndreasSystemProfiler. For example, something like 
> > > >>>
> > > >>> AndreasSystemProfiler spyForMilliseconds: 200 
> > > >>>
> > > >> segfault (stack overflow)... 
> > > >>
> > > >
> > > >Use Cog 3370 or older. I reported the problem in VM-Dev, but
> > nobody 
> > > listened. 
> > > 
> > > 
> > > 
> > > I don't see where you reported the problem. Can you give me a
> > specific
> > > reference? Maybe if more of us post it will get some attention.
> > I
> > > searched
> > > 
> > > 
> > I just posted a reply to it a few hours ago hoping for the same
> > effect.
> > His original posts were on 7/20 and had 'Cog crash with
> > AndreasSystemProfiler' in the subject line.
> > 
> > On a related note, I'm having an issue with 3410 hanging the image
> > while
> > loading packages while 3390 is working (aside from the profiler
> > issue)
> > for me... it's always something.
> > 
> > > gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 
> > > 
> > > 
> > > 
> > > for your posts in 2015 but did not see it.
> > > 
> > > 
> > >  - 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
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Sun Aug 16 17:09:42 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 18:09:42 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <1439760072.16738.23.camel@gmail.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>,
	<55D0F95B.20890.156C93E@dnorton.mindspring.com>,
	<1439760072.16738.23.camel@gmail.com>
Message-ID: <55D10A26.3277.1986224@dnorton.mindspring.com>

On 16 Aug 2015 at 17:21, Phil (list) wrote:

> On Sun, 2015-08-16 at 16:58 -0400, Dan Norton wrote:
> > Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following
> 30+ times successfully:
> > 
> > 	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159
> printString]].
> > 
> > Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+
> times and the VM 
> > crashed with a stack exception. Dump attached.
> > 
> > Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the
> following 40+ times 
> > successfully:
> > 
> > 	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].
> > 
> > What is the difference between AndreasSystemProfiler and
> MessageTally? Their output 
> > appears similar.
> 
> They perform the same function but ASP is more accurate (esp related
> to
> primitives) and capable of higher resolution.  Here's a write up
> by
> Eliot back when it was originally released:
> http://forum.world.st/Re-squeak-dev-AndreasSystemProfiler-Released-M
> IT-td4665183.html
> 

There is a 2015-01-27 version which preceeds the latest. Would that be worth a try?

 - Dan



From pbpublist at gmail.com  Sun Aug 16 17:41:14 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 18:41:14 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <55D10A26.3277.1986224@dnorton.mindspring.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>
	, <55D0F95B.20890.156C93E@dnorton.mindspring.com>
	, <1439760072.16738.23.camel@gmail.com>
	<55D10A26.3277.1986224@dnorton.mindspring.com>
Message-ID: <1439764874.16738.26.camel@gmail.com>

On Sun, 2015-08-16 at 18:09 -0400, Dan Norton wrote:
> On 16 Aug 2015 at 17:21, Phil (list) wrote:
> 
> > On Sun, 2015-08-16 at 16:58 -0400, Dan Norton wrote:
> > > Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following
> > 30+ times successfully:
> > > 
> > > 	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159
> > printString]].
> > > 
> > > Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+
> > times and the VM 
> > > crashed with a stack exception. Dump attached.
> > > 
> > > Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the
> > following 40+ times 
> > > successfully:
> > > 
> > > 	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].
> > > 
> > > What is the difference between AndreasSystemProfiler and
> > MessageTally? Their output 
> > > appears similar.
> > 
> > They perform the same function but ASP is more accurate (esp related
> > to
> > primitives) and capable of higher resolution.  Here's a write up
> > by
> > Eliot back when it was originally released:
> > http://forum.world.st/Re-squeak-dev-AndreasSystemProfiler-Released-M
> > IT-td4665183.html
> > 
> 
> There is a 2015-01-27 version which preceeds the latest. Would that be worth a try?
> 

Eliot just posted a reply today indicating this bug is on his radar so
it will probably be fixed soon.

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





From Ken.Dickey at whidbey.com  Sun Aug 16 21:11:21 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sun, 16 Aug 2015 19:11:21 -0700
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>

2461 TaskBar seems to lose collapsed morphs.

World >> New Morph >> <whatever>

Then collapse <whatever>.

Works OK with a Browser.  Leaves space to display the TaskBar buttons, but they do not show up (except for the browser).

Something about Morphs.

??
-KenD




From dnorton at mindspring.com  Mon Aug 17 10:14:51 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 17 Aug 2015 08:14:51 -0700 (PDT)
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>
References: <55D0A754.2070602@jvuletich.org>
	<20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>
Message-ID: <1439824491018-4843553.post@n4.nabble.com>

Similar observation here, except that browsers, workspaces, and transcripts
don't appear; other stuff does appear. However, everything is there in
Windows...>find window.

 - Dan



--
View this message in context: http://forum.world.st/Updates-Smart-underscores-BouncingAtomsMorph-performance-tp4843287p4843553.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From juan at jvuletich.org  Mon Aug 17 15:53:48 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 17:53:48 -0300
Subject: [Cuis] Updates: Smart underscores &
	BouncingAtomsMorph	performance
In-Reply-To: <55D0D030.28083.B5F605@dnorton.mindspring.com>
References: <55D0A754.2070602@jvuletich.org>
	<55D0D030.28083.B5F605@dnorton.mindspring.com>
Message-ID: <55D249DC.4020807@jvuletich.org>

On 8/16/2015 3:02 PM, Dan Norton wrote:
> On 16 Aug 2015 at 12:08, Juan Vuletich wrote:
>
>> Hi Folks,
>>
>> Yesterday and today I pushed new stuff to github. See the attach.
>> Cuis
>> can now display both underscores and left arrows in the same
>> method!
>>
>> I also could not help it and worked on BouncingAtomsMorph
>> performance.
>> It should be close to Squeak now.
>>
> No, it's faster. Much faster than Squeak in a side-by-side comparison.
>
>   - Dan
>

Nice!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 17 15:55:36 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 17:55:36 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <1439750662.16738.6.camel@gmail.com>
References: <55D0A754.2070602@jvuletich.org>
	<1439750662.16738.6.camel@gmail.com>
Message-ID: <55D24A48.1060800@jvuletich.org>

On 8/16/2015 3:44 PM, Phil (list) wrote:
> On Sun, 2015-08-16 at 12:08 -0300, Juan Vuletich wrote:
>> Hi Folks,
>>
>> Yesterday and today I pushed new stuff to github. See the attach. Cuis
>> can now display both underscores and left arrows in the same method!
>>
>> I also could not help it and worked on BouncingAtomsMorph performance.
>> It should be close to Squeak now.
> It's definitely improved BouncingAtomsMorph (I'm seeing at least 13-17
> FPS now.. I say 'at least' because from time to time it jumps up to the
> low 20's).  But more importantly (to me, at least) at first glance it
> looks like these changes provide an across the board performance boost
> to my other Morphic code. (most of my stuff doesn't have FPS counters
> but in looking at Morphic CPU utilization in ProcessBrowser, it's almost
> always 5-10% lower now)
>

Yes, that sounds reasonable. Most of the code I optimized is quite 
general. This example was useful, because it was concrete enough to run 
the profiler and get consistent results. It is quite easy to optimize 
code if you know _where_ is the problem!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 17 15:56:57 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 17:56:57 -0300
Subject: [Cuis] Updates: Smart underscores &
	BouncingAtomsMorph	performance
In-Reply-To: <1439824491018-4843553.post@n4.nabble.com>
References: <55D0A754.2070602@jvuletich.org>	<20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>
	<1439824491018-4843553.post@n4.nabble.com>
Message-ID: <55D24A99.3050404@jvuletich.org>

On 8/17/2015 12:14 PM, Dan Norton wrote:
> Similar observation here, except that browsers, workspaces, and transcripts
> don't appear; other stuff does appear. However, everything is there in
> Windows...>find window.
>
>   - Dan

Yes. I introduced a bug in the recent Morphic optimizations. I fixed it 
now. Fortunately, fixed code is both simpler and slightly faster than 
the old code.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 17 16:00:32 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 18:00:32 -0300
Subject: [Cuis] more updates
Message-ID: <55D24B70.3030406@jvuletich.org>

Hi Folks,

I fixed the Taskbar bug I introduced yesterday. Thanks for reporting!

I also added a new folder for optional fonts data. Right now it contains 
several sizes of DejaVu Sans Mono, but we can add there any other font 
you find desirable (if it has a good license). Doing

StrikeFont install: 'DejaVu Sans Mono'

loads it.

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150817/2810cc81/attachment-0003.html>

From juan at jvuletich.org  Mon Aug 17 16:04:45 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 18:04:45 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <55D24C6D.6090500@jvuletich.org>

On 8/16/2015 12:08 PM, Juan Vuletich wrote:
> Hi Folks,
>
> Yesterday and today I pushed new stuff to github. See the attach. Cuis 
> can now display both underscores and left arrows in the same method!
>
> I also could not help it and worked on BouncingAtomsMorph performance. 
> It should be close to Squeak now.
>
> Cheers,
> Juan Vuletich

I'm a bit surprised nobody commented on the attach. I'm quite happy 
about not having to give up our traditional assignment symbol, and at 
the same time, handle and display correctly underscores in names. These 
are sometimes useful when dealing with external code and stuff. I won't 
deny it, I'm also a bit proud of the idea to make it possible. Looking 
at the screenshot, doesn't it make you think "how the hell did he do it?" ?

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis_underscores.png
Type: image/png
Size: 56056 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150817/a271fcf9/attachment-0003.png>

From juan at jvuletich.org  Mon Aug 17 16:17:48 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 18:17:48 -0300
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <1439764874.16738.26.camel@gmail.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>	,
	<55D0F95B.20890.156C93E@dnorton.mindspring.com>	,
	<1439760072.16738.23.camel@gmail.com>	<55D10A26.3277.1986224@dnorton.mindspring.com>
	<1439764874.16738.26.camel@gmail.com>
Message-ID: <55D24F7C.7030909@jvuletich.org>

Yay!

Cheers,
Juan Vuletich

On 8/16/2015 7:41 PM, Phil (list) wrote:
>
> Eliot just posted a reply today indicating this bug is on his radar so
> it will probably be fixed soon.




From lewis at mail.msen.com  Mon Aug 17 16:34:56 2015
From: lewis at mail.msen.com (David T. Lewis)
Date: Mon, 17 Aug 2015 17:34:56 -0400 (EDT)
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D24C6D.6090500@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
Message-ID: <47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>

> On 8/16/2015 12:08 PM, Juan Vuletich wrote:
>> Hi Folks,
>>
>> Yesterday and today I pushed new stuff to github. See the attach. Cuis
>> can now display both underscores and left arrows in the same method!
>>
>> I also could not help it and worked on BouncingAtomsMorph performance.
>> It should be close to Squeak now.
>>
>> Cheers,
>> Juan Vuletich
>
> I'm a bit surprised nobody commented on the attach. I'm quite happy
> about not having to give up our traditional assignment symbol, and at
> the same time, handle and display correctly underscores in names. These
> are sometimes useful when dealing with external code and stuff. I won't
> deny it, I'm also a bit proud of the idea to make it possible. Looking
> at the screenshot, doesn't it make you think "how the hell did he do it?"
> ?

Well, that's what *I* was wondering. So how did you do that???

:-)

Dave








From pbpublist at gmail.com  Mon Aug 17 18:09:15 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 17 Aug 2015 19:09:15 -0400
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D24C6D.6090500@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
Message-ID: <1439852955.16738.31.camel@gmail.com>

On Mon, 2015-08-17 at 18:04 -0300, Juan Vuletich wrote:
> On 8/16/2015 12:08 PM, Juan Vuletich wrote:
> > Hi Folks,
> >
> > Yesterday and today I pushed new stuff to github. See the attach. Cuis 
> > can now display both underscores and left arrows in the same method!
> >
> > I also could not help it and worked on BouncingAtomsMorph performance. 
> > It should be close to Squeak now.
> >
> > Cheers,
> > Juan Vuletich
> 
> I'm a bit surprised nobody commented on the attach. I'm quite happy 
> about not having to give up our traditional assignment symbol, and at 
> the same time, handle and display correctly underscores in names. These 
> are sometimes useful when dealing with external code and stuff. I won't 
> deny it, I'm also a bit proud of the idea to make it possible. Looking 
> at the screenshot, doesn't it make you think "how the hell did he do it?" ?
> 

You packed too much goodness into one post!  I was so occupied with the
Morphic part, the underscore part didn't even register... very nice job!
This has actually been one of my ongoing issues with the use of arrow
assignments so now I can leave them enabled.  So, how the hell did you
do it? :-)

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





From avalloud at smalltalk.comcastbiz.net  Tue Aug 18 19:55:14 2015
From: avalloud at smalltalk.comcastbiz.net (Andres Valloud)
Date: Tue, 18 Aug 2015 17:55:14 -0700
Subject: [Cuis] [Smalltalks 2015] --- Invitation
Message-ID: <55D3D3F2.50607@smalltalk.comcastbiz.net>

The Fundaci?n Argentina de Smalltalk proudly invites you to one of the 
premier Smalltalk conferences in the world.  Let's meet at Buenos Aires, 
November 11-13!  For more details, see the invitation here:

http://www.fast.org.ar/Smalltalks2015-invitation.pdf




From juan at jvuletich.org  Wed Aug 19 07:51:06 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 19 Aug 2015 09:51:06 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
	<47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>
Message-ID: <55D47BBA.3060805@jvuletich.org>

On 8/17/2015 6:34 PM, David T. Lewis wrote:
>>
>> I'm a bit surprised nobody commented on the attach. I'm quite happy
>> about not having to give up our traditional assignment symbol, and at
>> the same time, handle and display correctly underscores in names. These
>> are sometimes useful when dealing with external code and stuff. I won't
>> deny it, I'm also a bit proud of the idea to make it possible. Looking
>> at the screenshot, doesn't it make you think "how the hell did he do it?"
>> ?
> Well, that's what *I* was wondering. So how did you do that???
>
> :-)
>
> Dave
>

Well, the first idea was that it given that a StrikeFont can already 
swap glyphs (#useUnderscores, #useLeftArrow), then it is possible to 
build cheap derivative fonts that do that, and TextStyles for them. 
Then, Shout parses code and sets TextEmphasis like italics or colors for 
differenc code elements. I just made it set a TextEmphasis with 
underscores for identifiers.

It is so simple that I find it surprising that nobody (including me) 
thought about this years ago!

Cheers,
Juan Vuletich



From lewis at mail.msen.com  Wed Aug 19 11:56:22 2015
From: lewis at mail.msen.com (David T. Lewis)
Date: Wed, 19 Aug 2015 12:56:22 -0400 (EDT)
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D47BBA.3060805@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
	<47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>
	<55D47BBA.3060805@jvuletich.org>
Message-ID: <37162.136.2.1.102.1440003382.squirrel@webmail.msen.com>

Juan,

I hope you don't mind if I CC squeak-dev.

> On 8/17/2015 6:34 PM, David T. Lewis wrote:
>>>
>>> I'm a bit surprised nobody commented on the attach. I'm quite happy
>>> about not having to give up our traditional assignment symbol, and at
>>> the same time, handle and display correctly underscores in names. These
>>> are sometimes useful when dealing with external code and stuff. I won't
>>> deny it, I'm also a bit proud of the idea to make it possible. Looking
>>> at the screenshot, doesn't it make you think "how the hell did he do
>>> it?"
>>> ?
>> Well, that's what *I* was wondering. So how did you do that???
>>
>> :-)
>>
>> Dave
>>
>
> Well, the first idea was that it given that a StrikeFont can already
> swap glyphs (#useUnderscores, #useLeftArrow), then it is possible to
> build cheap derivative fonts that do that, and TextStyles for them.
> Then, Shout parses code and sets TextEmphasis like italics or colors for
> differenc code elements. I just made it set a TextEmphasis with
> underscores for identifiers.
>
> It is so simple that I find it surprising that nobody (including me)
> thought about this years ago!
>
> Cheers,
> Juan Vuletich
>

What a great idea!

Dave






From ume at blueplane.jp  Wed Aug 19 20:35:28 2015
From: ume at blueplane.jp (Masashi UMEZAWA)
Date: Thu, 20 Aug 2015 10:35:28 +0900
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: <CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>

Hi all,

Sorry for the late reply. I've missed the mail...

As I recall, I have deliberately selected not using Exceptions mainly
for portability.

Actually there are various non-existent-file exceptions -
FileDoesNotExist (Squeak), FileDoesNotExistException (Pharo),
OSErrorHolder nonexistentSignal (VW).

Originally old FileMan did not have exception wrappers, but it has
now. So I think it is a good time to introduce exception-aware APIs.

How about adding tryReadStream series?

[ readStream := 'foo.txt' asFileEntry tryReadStream ] on:
FmFileIOAccessor fileDoesNotExistException do: [:ex | ].

readStream := 'foo.txt' asFileEntry tryReadStreamIfError: [:ex | ].

Best regards,

2015-07-27 23:58 GMT+09:00 Juan Vuletich <juan at 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
>>>>>
>>>>>
>>>>
>>
>>
>

-- 
[:masashi | ^umezawa]



From juan at jvuletich.org  Thu Aug 20 08:52:42 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 20 Aug 2015 10:52:42 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <37162.136.2.1.102.1440003382.squirrel@webmail.msen.com>
References: <55D0A754.2070602@jvuletich.org>
	<55D24C6D.6090500@jvuletich.org>	<47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>	<55D47BBA.3060805@jvuletich.org>
	<37162.136.2.1.102.1440003382.squirrel@webmail.msen.com>
Message-ID: <55D5DBAA.7090100@jvuletich.org>

Of course not! It would be very nice to see this done in Squeak and 
Pharo too.

Cheers,
Juan Vuletich

> Juan,
>
> I hope you don't mind if I CC squeak-dev.
>
> What a great idea!
>
> Dave
>



From juan at jvuletich.org  Thu Aug 20 09:01:40 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 20 Aug 2015 11:01:40 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@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>
	<55B64713.8040806@jvuletich.org>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
Message-ID: <55D5DDC4.9030101@jvuletich.org>

Hi Masashi,

> Hi all,
>
> Sorry for the late reply. I've missed the mail...
>
> As I recall, I have deliberately selected not using Exceptions mainly
> for portability.
>
> Actually there are various non-existent-file exceptions -
> FileDoesNotExist (Squeak), FileDoesNotExistException (Pharo),
> OSErrorHolder nonexistentSignal (VW).
>
> Originally old FileMan did not have exception wrappers, but it has
> now. So I think it is a good time to introduce exception-aware APIs.
>
> How about adding tryReadStream series?
>
> [ readStream := 'foo.txt' asFileEntry tryReadStream ] on:
> FmFileIOAccessor fileDoesNotExistException do: [:ex | ].
>
> readStream := 'foo.txt' asFileEntry tryReadStreamIfError: [:ex | ].
>
> Best regards,

Thanks for your support.

I guess I would prefer #readStream for the basic, raising exceptions 
api, and maybe #readStreamNoFail or #readStreamOrEmpty or such for the 
"exception eating api" . In any case it is your call, I understand there 
is back compatibility to care about, and I'll be happy with your choice.

Cheers,
Juan Vuletich

> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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 ume at blueplane.jp  Sat Aug 22 08:15:43 2015
From: ume at blueplane.jp (Masashi UMEZAWA)
Date: Sat, 22 Aug 2015 22:15:43 +0900
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <55D5DDC4.9030101@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>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
Message-ID: <CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>

Hi Juan,

Yes, I'm concerning about backward-compatibility.
FmFileEntry>>#readStream has been used long. So I would prefer just
adding new APIs.

Best regards,

> I guess I would prefer #readStream for the basic, raising exceptions api,
> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the "exception
> eating api" . In any case it is your call, I understand there is back
> compatibility to care about, and I'll be happy with your choice.
>
> Cheers,
> Juan Vuletich
>
>
>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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
>>>>>>>
>>>>>>>
>>>>
>



-- 
[:masashi | ^umezawa]



From eliot.miranda at gmail.com  Sat Aug 22 11:38:30 2015
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Sat, 22 Aug 2015 09:38:30 -0700
Subject: [Cuis] New Cog VMs available...
Message-ID: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3427.

Squeak V5 users will want to upgrade their VMs because they, along with
Smalltalk changes to follow soon, fix image segments.  But upgrading is not
a trivial process because the VMs on my site are not complete.  The best
way to update is to take a copy of the Squeak 5.0 all-in-one and replace
the main VM executable there-in with one from my site.  This gets you
up-to-date plugins and an up-to-date VM.  I hope that this process will get
easier soon.


------------------------------------------------------------------------
CogVM binaries as per VMMaker.oscog-eem.1441/r3427

Modify Spur ImageSegment load to become the segmentWordArray into an Array
of
the loaded objects if load is successful, hence decoupling ImageSegment from
the assumption that objects are allocated in order.

Fix Integer receiver, float arg comparison with NaNs in the machine-code
primitive.  This has started failing in the FloatTest>>testNaNCompare since
the
new machine-code perform primitive invoked the machine-code version of the
primitive.  The Interpretewr code has always been correct and the old
perform
primitive would always run the Interpreter primitive if it exsted, since
this
would probably be faster.

Fix the bug introduced by the fix to primitive function invocation in
VMMaker.oscog-eem.1351  The fix correctly changed primitve code to set the
primitiveFunctionPointer appropriately when a jitted external primitive was
rebound, but it didn't remember to void the jit's record of the offset of
the
assignment that sets the primitiveFunctionPointer when switching between
profiling andf non-profiling regimes, so that the address from the wrong
regime
would remain and be used to smash prmitive code.  The fix is simply to void
the
externalSetPrimOffsets in voidCogCompiledCode.  This fixes the bug whose
symptom is a hard VM crash when using AndreasSystemProfilier.

Integrate Marcel Taeumel & Tobias Pape's v2 SSL plugin changes.

Fix negative 64-bit shift in the 64-bit Spur Stack interpreter.

Newspeak:
Fix MNU for cogged self and outer sends.

Make the Newspeak VM packager include the V50 sources file instead of V41.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150822/35d7bb41/attachment-0003.html>

From j.b.shirk at gmail.com  Mon Aug 24 06:42:33 2015
From: j.b.shirk at gmail.com (Joe Shirk)
Date: Mon, 24 Aug 2015 07:42:33 -0400
Subject: [Cuis] IPFS on Smalltalk
Message-ID: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>

Dear all, especially @Masashi

I wanted to draw attention to the http://ipfs.io project, "the permanent
web" which works. It is a distributed peer-to-peer filesystem that works
somewhat like bittorrent. You get the functionality of Git as well. It is
truly ingenious.

Since I have taken an interest in Smalltalk (I'm still learning) I have
salivated at the  possibilities for, say Amber + ipfs.

There is currently a call for APIs implemented in other languages;
https://github.com/ipfs/ipfs/issues
I see no one there is interested in Smalltalk so I though I should
undertake it, but it will be many months before I have the knowledge and
there is no guarantee that I am up to the task... Now seeing that Masashi
is working with filesystems, perhaps you would take an interest in this
idea.

The inventor Juan Benet has many brilliant ideas and has done several
presentations to be found on the ipfs site. Unfortunately, he seems to
drink a lot of coffee and talks extremely fast and does not enunciate,
making the presentations very difficult to understand for those of whom
english is a second language. I can definitely help with this by making a
transcript if there is interest.


On Sat, Aug 22, 2015 at 1:00 PM, <cuis-request at jvuletich.org> wrote:

> Send Cuis mailing list submissions to
>         cuis at jvuletich.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> or, via email, send a message with subject or body 'help' to
>         cuis-request at jvuletich.org
>
> You can reach the person managing the list at
>         cuis-owner at jvuletich.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cuis digest..."
>
>
> Today's Topics:
>
>    1. Re: Wrapper for file access in different Smalltalk dialects
>       (Masashi UMEZAWA)
>    2. New Cog VMs available... (Eliot Miranda)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 22 Aug 2015 22:15:43 +0900
> From: Masashi UMEZAWA <ume at blueplane.jp>
> To: Juan Vuletich <juan at jvuletich.org>
> Cc: Discussion of Cuis Smalltalk <cuis at jvuletich.org>,  "H. Hirzel"
>         <hannes.hirzel at gmail.com>
> Subject: Re: [Cuis] Wrapper for file access in different Smalltalk
>         dialects
> Message-ID:
>         <CA+=
> t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Juan,
>
> Yes, I'm concerning about backward-compatibility.
> FmFileEntry>>#readStream has been used long. So I would prefer just
> adding new APIs.
>
> Best regards,
>
> > I guess I would prefer #readStream for the basic, raising exceptions api,
> > and maybe #readStreamNoFail or #readStreamOrEmpty or such for the
> "exception
> > eating api" . In any case it is your call, I understand there is back
> > compatibility to care about, and I'll be happy with your choice.
> >
> > Cheers,
> > Juan Vuletich
> >
> >
> >> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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
> >>>>>>>
> >>>>>>>
> >>>>
> >
>
>
>
> --
> [:masashi | ^umezawa]
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 22 Aug 2015 09:38:30 -0700
> From: Eliot Miranda <eliot.miranda at gmail.com>
> To: Squeak Virtual Machine Development Discussion
>         <vm-dev at lists.squeakfoundation.org>
> Cc: The general-purpose Squeak developers list
>         <squeak-dev at lists.squeakfoundation.org>,        Discusses
> Development of
>         Pharo <pharo-dev at lists.pharo.org>,
>         "newspeaklanguage at googlegroups.com"
>         <newspeaklanguage at googlegroups.com>,    Discussion of Cuis
> Smalltalk
>         <cuis at jvuletich.org>
> Subject: [Cuis] New Cog VMs available...
> Message-ID:
>         <CAC20JE1-f=nHr-jkoMsmpYaH=
> s2rkNxmaDom6bqZ3shfjDq2_g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3427.
>
> Squeak V5 users will want to upgrade their VMs because they, along with
> Smalltalk changes to follow soon, fix image segments.  But upgrading is not
> a trivial process because the VMs on my site are not complete.  The best
> way to update is to take a copy of the Squeak 5.0 all-in-one and replace
> the main VM executable there-in with one from my site.  This gets you
> up-to-date plugins and an up-to-date VM.  I hope that this process will get
> easier soon.
>
>
> ------------------------------------------------------------------------
> CogVM binaries as per VMMaker.oscog-eem.1441/r3427
>
> Modify Spur ImageSegment load to become the segmentWordArray into an Array
> of
> the loaded objects if load is successful, hence decoupling ImageSegment
> from
> the assumption that objects are allocated in order.
>
> Fix Integer receiver, float arg comparison with NaNs in the machine-code
> primitive.  This has started failing in the FloatTest>>testNaNCompare since
> the
> new machine-code perform primitive invoked the machine-code version of the
> primitive.  The Interpretewr code has always been correct and the old
> perform
> primitive would always run the Interpreter primitive if it exsted, since
> this
> would probably be faster.
>
> Fix the bug introduced by the fix to primitive function invocation in
> VMMaker.oscog-eem.1351  The fix correctly changed primitve code to set the
> primitiveFunctionPointer appropriately when a jitted external primitive was
> rebound, but it didn't remember to void the jit's record of the offset of
> the
> assignment that sets the primitiveFunctionPointer when switching between
> profiling andf non-profiling regimes, so that the address from the wrong
> regime
> would remain and be used to smash prmitive code.  The fix is simply to void
> the
> externalSetPrimOffsets in voidCogCompiledCode.  This fixes the bug whose
> symptom is a hard VM crash when using AndreasSystemProfilier.
>
> Integrate Marcel Taeumel & Tobias Pape's v2 SSL plugin changes.
>
> Fix negative 64-bit shift in the 64-bit Spur Stack interpreter.
>
> Newspeak:
> Fix MNU for cogged self and outer sends.
>
> Make the Newspeak VM packager include the V50 sources file instead of V41.
>
> _,,,^..^,,,_
> best, Eliot
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150822/35d7bb41/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 38, Issue 21
> ************************************
>



-- 

Gmail is unsecure. Why? See: EFF Surveillance Self-Defense Project
<https://ssd.eff.org/tech/email>

My preferred secure email address: infomaniac(at)i2pmail(dot)org
(For more information, please see: About I2P <http://www.i2p2.de/intro.html>
)

If you prefer to send to this gmail account, consider using
https://www.mailpile.is

My Public key:
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x8726E59217F0E6F9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150824/043d26be/attachment-0003.html>

From juanlists at jvuletich.org  Mon Aug 24 08:28:17 2015
From: juanlists at jvuletich.org (J. Vuletich (mail lists))
Date: Mon, 24 Aug 2015 13:28:17 +0000
Subject: [Cuis] [Vm-dev] New Cog VMs available...
In-Reply-To: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
References: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
Message-ID: <20150824132817.Horde.7mj1UgJfqgatW2PykGELgg7@gator3294.hostgator.com>

Thanks Eliot!

It works great, and indeed it fixes the issue with  
AndreasSystemProfiler I had reported.

Cheers,
Juan Vuletich

Quoting Eliot Miranda <eliot.miranda at gmail.com>:

>






From juan at jvuletich.org  Mon Aug 24 08:37:48 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:37:48 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55D3D3F2.50607@smalltalk.comcastbiz.net>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
Message-ID: <55DB1E2C.4010300@jvuletich.org>

Thanks Andr?s,

I'll be there. Maybe I'll submit a talk proposal too.

Folks, what do you think I'd tell about?
- Cuis, introduction for people who don't know much about it, recent 
development and community activity, etc.
- Repeat, and add latest details to the talk I already gave about work 
at Satellogic.
- Morphic 3. I'd rather not. Maybe a short "show us your project" demo, 
given that there are no recent news here.
- anything else?

Cheers,
Juan Vuletich

On 8/18/2015 9:55 PM, Andres Valloud wrote:
> The Fundaci?n Argentina de Smalltalk proudly invites you to one of the 
> premier Smalltalk conferences in the world.  Let's meet at Buenos 
> Aires, November 11-13!  For more details, see the invitation here:
>
> http://www.fast.org.ar/Smalltalks2015-invitation.pdf
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org




From juan at jvuletich.org  Mon Aug 24 08:42:46 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:42:46 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@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>
	<55B64713.8040806@jvuletich.org>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
	<CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>
Message-ID: <55DB1F56.608@jvuletich.org>

Hi Masashi,

Ok. #tryReadStream is reasonable. Or maybe #readStreamOrFail.

Any other suggestion? Preferences?

Thanks,
Juan Vuletich

On 8/22/2015 10:15 AM, Masashi UMEZAWA wrote:
> Hi Juan,
>
> Yes, I'm concerning about backward-compatibility.
> FmFileEntry>>#readStream has been used long. So I would prefer just
> adding new APIs.
>
> Best regards,
>
>> I guess I would prefer #readStream for the basic, raising exceptions api,
>> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the "exception
>> eating api" . In any case it is your call, I understand there is back
>> compatibility to care about, and I'll be happy with your choice.
>>
>> Cheers,
>> Juan Vuletich
>>
>>
>>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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 juan at jvuletich.org  Mon Aug 24 08:43:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:43:09 -0300
Subject: [Cuis] New Cog VMs available...
In-Reply-To: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
References: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
Message-ID: <55DB1F6D.1010006@jvuletich.org>

Works like a charm.

Thanks a lot!

Cheers,
Juan Vuletich

On 8/22/2015 1:38 PM, Eliot Miranda wrote:
> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3427.
>
> Squeak V5 users will want to upgrade their VMs because they, along 
> with Smalltalk changes to follow soon, fix image segments.  But 
> upgrading is not a trivial process because the VMs on my site are not 
> complete.  The best way to update is to take a copy of the Squeak 5.0 
> all-in-one and replace the main VM executable there-in with one from 
> my site.  This gets you up-to-date plugins and an up-to-date VM.  I 
> hope that this process will get easier soon.
>
>
> ------------------------------------------------------------------------
> CogVM binaries as per VMMaker.oscog-eem.1441/r3427
>
> Modify Spur ImageSegment load to become the segmentWordArray into an 
> Array of
> the loaded objects if load is successful, hence decoupling 
> ImageSegment from
> the assumption that objects are allocated in order.
>
> Fix Integer receiver, float arg comparison with NaNs in the machine-code
> primitive.  This has started failing in the FloatTest>>testNaNCompare 
> since the
> new machine-code perform primitive invoked the machine-code version of the
> primitive.  The Interpretewr code has always been correct and the old 
> perform
> primitive would always run the Interpreter primitive if it exsted, 
> since this
> would probably be faster.
>
> Fix the bug introduced by the fix to primitive function invocation in
> VMMaker.oscog-eem.1351  The fix correctly changed primitve code to set the
> primitiveFunctionPointer appropriately when a jitted external 
> primitive was
> rebound, but it didn't remember to void the jit's record of the offset 
> of the
> assignment that sets the primitiveFunctionPointer when switching between
> profiling andf non-profiling regimes, so that the address from the 
> wrong regime
> would remain and be used to smash prmitive code.  The fix is simply to 
> void the
> externalSetPrimOffsets in voidCogCompiledCode.  This fixes the bug whose
> symptom is a hard VM crash when using AndreasSystemProfilier.
>
> Integrate Marcel Taeumel & Tobias Pape's v2 SSL plugin changes.
>
> Fix negative 64-bit shift in the 64-bit Spur Stack interpreter.
>
> Newspeak:
> Fix MNU for cogged self and outer sends.
>
> Make the Newspeak VM packager include the V50 sources file instead of V41.
>
> _,,,^..^,,,_
> best, Eliot
>
>
> _______________________________________________
> 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/20150824/9ffa5f3c/attachment-0003.html>

From juan at jvuletich.org  Mon Aug 24 08:48:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:48:43 -0300
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
Message-ID: <55DB20BB.708@jvuletich.org>

Hi Joe,

Someone saying "awesome!" and "cool!" so many times at his own stuff 
makes me a little uncomfortable... But, anyway:

It looks like Dropbox, but peer to peer, right?

The possibility of publishing and sharing stuff without a central 
provider is of course desirable.

Before starting to implement bindings and calls to the api... Is that 
really needed? It is integrated in the file system, so maybe not.

More interesting than that, what are some apps that could benefit from 
it? How would they do that?

Cheers,
Juan Vuletich

On 8/24/2015 8:42 AM, Joe Shirk wrote:
> Dear all, especially @Masashi
>
> I wanted to draw attention to the http://ipfs.io project, "the 
> permanent web" which works. It is a distributed peer-to-peer 
> filesystem that works somewhat like bittorrent. You get the 
> functionality of Git as well. It is truly ingenious.
>
> Since I have taken an interest in Smalltalk (I'm still learning) I 
> have salivated at the  possibilities for, say Amber + ipfs.
>
> There is currently a call for APIs implemented in other languages;
> https://github.com/ipfs/ipfs/issues
> I see no one there is interested in Smalltalk so I though I should 
> undertake it, but it will be many months before I have the knowledge 
> and there is no guarantee that I am up to the task... Now seeing that 
> Masashi is working with filesystems, perhaps you would take an 
> interest in this idea.
>
> The inventor Juan Benet has many brilliant ideas and has done several 
> presentations to be found on the ipfs site. Unfortunately, he seems to 
> drink a lot of coffee and talks extremely fast and does not enunciate, 
> making the presentations very difficult to understand for those of 
> whom english is a second language. I can definitely help with this by 
> making a transcript if there is interest.
>




From j.b.shirk at gmail.com  Mon Aug 24 09:25:58 2015
From: j.b.shirk at gmail.com (Joe Shirk)
Date: Mon, 24 Aug 2015 10:25:58 -0400
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <55DB20BB.708@jvuletich.org>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
	<55DB20BB.708@jvuletich.org>
Message-ID: <CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>

Hi Juan,

I was trying to diplomatically imply that Benet's forte is not
presentation, however the docs on the site and on github are adequate
introductions, and I think it won't take long to see the value in what is
meant by "permanent" web that is content addressed instead of ip addressed.

I spoke too soon today, not aware that he had recently responded to my post
a week ago:

https:// <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>
github.com <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>
/issues/80#issuecomment-133593050
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>

As at the moment I am thumbing my smartphone, I have to be brief, but I'll
try to cover the basics.

ipfs is a protocal that has the potential to eventually replace http
altogether, though currently content on the ipfs network is accessible
directly through the protocol as well as through http gateways.

ipfs is a content routing system, and so functions like a cdn, but it is
distributed, so is like bittorrent. it does sync like dropbox, but the
routing system ensures that copies of content migrate closer to demand,
which could be an auditorium of people on a local wifi without external
access. Real-time syncing to many peers is thus possible without latency.

There are working demos of HD videos streaming without latency from the
network.

The Directed Acyclical Graph / Merkel Tree allows for just about any data
structure, but is especially well designed for versioning. Everything is
addressed by its hash fingerprint, so one can be absolutely sure what
version one requests, but can also traverse the version tree if the content
referenced is say, a software library that is a dependency for a certain
package. Automatic forwarding to a more recent version is also a feature.

There is a name system too, that allows one to register a permanent or
temporary namespace that references a version tree of any object.

All objects are stored in encrypted chunks, so privacy and publicity are
controlled.

To me, this system implemented in smalltalk, and I suppose that should be
squeak and amber, will make it possible to build distributed apps, because
the app itself can be an object, not only its content or data. Implementing
in smalltalk should mean that the complexity involved would be more easily
managed with few bugs, compared to say, javascript or node.

I see ipfs as a route to put smalltalk in the limelight and on the cutting
edge.

HTH

Joe



> Message: 5
> Date: Mon, 24 Aug 2015 10:48:43 -0300
> From: Juan Vuletich <juan at jvuletich.org>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: Joe Shirk <j.b.shirk at gmail.com>
> Subject: Re: [Cuis] IPFS on Smalltalk
> Message-ID: <55DB20BB.708 at jvuletich.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi Joe,
>
> Someone saying "awesome!" and "cool!" so many times at his own stuff
> makes me a little uncomfortable... But, anyway:
>
> It looks like Dropbox, but peer to peer, right?
>
> The possibility of publishing and sharing stuff without a central
> provider is of course desirable.
>
> Before starting to implement bindings and calls to the api... Is that
> really needed? It is integrated in the file system, so maybe not.
>
> More interesting than that, what are some apps that could benefit from
> it? How would they do that?
>
> Cheers,
> Juan Vuletich
>
> On 8/24/2015 8:42 AM, Joe Shirk wrote:
> > Dear all, especially @Masashi
> >
> > I wanted to draw attention to the http://ipfs.io project, "the
> > permanent web" which works. It is a distributed peer-to-peer
> > filesystem that works somewhat like bittorrent. You get the
> > functionality of Git as well. It is truly ingenious.
> >
> > Since I have taken an interest in Smalltalk (I'm still learning) I
> > have salivated at the  possibilities for, say Amber + ipfs.
> >
> > There is currently a call for APIs implemented in other languages;
> > https://github.com/ipfs/ipfs/issues
> > I see no one there is interested in Smalltalk so I though I should
> > undertake it, but it will be many months before I have the knowledge
> > and there is no guarantee that I am up to the task... Now seeing that
> > Masashi is working with filesystems, perhaps you would take an
> > interest in this idea.
> >
> > The inventor Juan Benet has many brilliant ideas and has done several
> > presentations to be found on the ipfs site. Unfortunately, he seems to
> > drink a lot of coffee and talks extremely fast and does not enunciate,
> > making the presentations very difficult to understand for those of
> > whom english is a second language. I can definitely help with this by
> > making a transcript if there is interest.
> >
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 38, Issue 23
> ************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150824/b30244e6/attachment-0003.html>

From juan at jvuletich.org  Mon Aug 24 10:01:11 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 12:01:11 -0300
Subject: [Cuis] Oops!  [Was package relative fileIns]
In-Reply-To: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>
References: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>
Message-ID: <55DB31B7.4050203@jvuletich.org>

Hi Ken,

On 8/23/2015 12:43 PM, Ken.Dickey wrote:
> Wrong click!  Try this one.
>
> The problem came up with someone loading Cuis-Smalltalk-Morphit-master.zip, so Cuis-Smalltalk-MorphIt-master was the dirName.

It is a good addition. But your implementation fails when the package 
name isn't equal to the category name, but a prefix. For example, 
loading 'Signal-Processing', it works for FFT packagePath, but fails for 
FloatImage packagePath.

This cleaner implementation works for both:

     packagePath
         ^ FileDirectory dirPathFor:
             (CodePackage packageOfClass: self ifNone: [ ^nil ]) 
fullFileName

It will be in the next commit.

> The Portland Camp Smalltalk was much fun, BTW.  Met some interesting folks.  Showed Cuis to Gemstone and Instantiations people + general demo.   Found and fixed a few bugs.  Nice folks.
>
> -KenD

Hey that's great! Thank you! Where the talks recoded on video?

I could not find a program of the CampSmalltalk there, but saw some 
pics. It looks like you had a great time there. I would like to join you 
all there next year!

(cc Cuis mail list. hope you don't mind)

Cheers,
Juan Vuletich



From garduino at gmail.com  Mon Aug 24 10:34:09 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Mon, 24 Aug 2015 12:34:09 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55DB1E2C.4010300@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org>
Message-ID: <CAEt3aLzeNZaMPa+meSVnKDuRp==a6vL_x-NkuCWQVb-+aR1Eeg@mail.gmail.com>

Hi Juan:

I think that all the mentioned topics are interesting.

I have not not much time lately to help / invest in Cuis, but if the
material or part of it that I used in Smalltalks 2013 is of some utility
for you, feel free to use it.


Saludos / Regards,
Germ?n Arduino
@garduino


2015-08-24 10:37 GMT-03:00 Juan Vuletich <juan at jvuletich.org>:

> Thanks Andr?s,
>
> I'll be there. Maybe I'll submit a talk proposal too.
>
> Folks, what do you think I'd tell about?
> - Cuis, introduction for people who don't know much about it, recent
> development and community activity, etc.
> - Repeat, and add latest details to the talk I already gave about work at
> Satellogic.
> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo,
> given that there are no recent news here.
> - anything else?
>
> Cheers,
> Juan Vuletich
>
> On 8/18/2015 9:55 PM, Andres Valloud wrote:
>
>> The Fundaci?n Argentina de Smalltalk proudly invites you to one of the
>> premier Smalltalk conferences in the world.  Let's meet at Buenos Aires,
>> November 11-13!  For more details, see the invitation here:
>>
>> http://www.fast.org.ar/Smalltalks2015-invitation.pdf
>>
>>
>> _______________________________________________
>> 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/20150824/f34b2b6e/attachment-0003.html>

From Ken.Dickey at whidbey.com  Sun Aug 23 19:57:01 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 24 Aug 2015 08:57:01 +0800
Subject: [Cuis] The Layout Resize Problem
Message-ID: <20150824085701.fe1053bcdbe68d36e1db633c@whidbey.com>

Greetings,

I have been thinking about "the layout resize problem".

The basis of the layout resize problem is that when someone changes fonts, we would like windows/panes/labels to adjust themselves with the minimum of fuss.

Also, when I resize a Morph I sometimes find that the layouts shrink below submorph containment size.  Currently, specifying a LayoutSpec which indicates "resize, but use morph extent as a minimum" seems awkward.

My intuitive thought is to make use of Morph>>minimumExtent.  LayoutMorphs (composts) could use the maximum width (mimimumExtent x) of their submorphs and the sum of the morph heights (minimumExtent y), possibly adding an extentBorder, and use this as its minimumExtent.

Note that if no submorph changes size, this value can be cached as it does not have to be recalculated.  Low cost calculations (buttonExtent, measureContents) don't have to be cached.

This leads to two questions: 
 [1] How to be informed when something changes that one depends on to calculate ones size.
 [2] How, when something changes size, to do this once for each affected morph?

My thought here is that the World could be informed that font size (or whatever influences  size calculations) changes.  Then it asks each of its submorphs, recursively, to recalculateMinimumExtent and layoutSubmorphs.  

This should happen top to bottom once for each resize causing event.

We can update our size calculating code and get rid of "Please Close All Open Windows".

Does this sound about right?  Other strategies?

Cheers,
-KenD



From edgardec2005 at gmail.com  Mon Aug 24 12:24:52 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Mon, 24 Aug 2015 14:24:52 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55DB1E2C.4010300@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org>
Message-ID: <5A326ADB-3193-47C2-8233-C45A4A854A33@gmail.com>

i wish a clarification about some Cuis 4 and beyond aspects

> On Aug 24, 2015, at 10:37 AM, Juan Vuletich <juan at jvuletich.org> wrote:
> 
> Thanks Andr?s,
> 
> I'll be there. Maybe I'll submit a talk proposal too.
> 
> Folks, what do you think I'd tell about?
> - Cuis, introduction for people who don't know much about it, recent development and community activity, etc.
> - Repeat, and add latest details to the talk I already gave about work at Satellogic.
> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo, given that there are no recent news here.
> - anything else?
> 
> Cheers,
> Juan Vuletich
> 
> On 8/18/2015 9:55 PM, Andres Valloud wrote:
>> The Fundaci?n Argentina de Smalltalk proudly invites you to one of the premier Smalltalk conferences in the world.  Let's meet at Buenos Aires, November 11-13!  For more details, see the invitation here:
>> 
>> http://www.fast.org.ar/Smalltalks2015-invitation.pdf
>> 
>> 
>> _______________________________________________
>> 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 j.b.shirk at gmail.com  Mon Aug 24 15:14:12 2015
From: j.b.shirk at gmail.com (Joe Shirk)
Date: Mon, 24 Aug 2015 16:14:12 -0400
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
	<55DB20BB.708@jvuletich.org>
	<CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
Message-ID: <CA+VgV_sgcLt=m81266ugSeo42hrMd-jdZsfWmJqm7_6V-X+z2w@mail.gmail.com>

I don't know why I wrote 'Squeak' -- too much reading, I guess. I meant
Pharo. My thinking was to make it work there first, then port to cuis and
newspeak if there is a benefit in doing that. Perhaps that's not the best
way to go about it. Any thoughts on this?

On Mon, Aug 24, 2015 at 10:25 AM, Joe Shirk <j.b.shirk at gmail.com> wrote:

> To me, this system implemented in smalltalk, and I suppose that should be
> squeak and amber, will make it possible to build distributed apps, because
> the app itself can be an object, not only its content or data. Implementing
> in smalltalk should mean that the complexity involved would be more easily
> managed with few bugs, compared to say, javascript or node.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150824/b1f94f7a/attachment-0003.html>

From Ken.Dickey at whidbey.com  Mon Aug 24 17:33:55 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 24 Aug 2015 15:33:55 -0700
Subject: [Cuis] Oops!  [Was package relative fileIns]
In-Reply-To: <55DB31B7.4050203@jvuletich.org>
References: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>
	<55DB31B7.4050203@jvuletich.org>
Message-ID: <20150824153355.5c917d40a1bbea5e7d893085@whidbey.com>

On Mon, 24 Aug 2015 12:01:11 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Ken,
> 
> On 8/23/2015 12:43 PM, Ken.Dickey wrote:
..
> > The Portland Camp Smalltalk was much fun, BTW.  Met some interesting folks.  Showed Cuis to Gemstone and Instantiations people + general demo.   Found and fixed a few bugs.  Nice folks.
> >
> > -KenD
 
> Hey that's great! Thank you! Where the talks recoded on video?

No.  I don't think so.  Pretty informal.  First time I had tried the video out on my ChromeBook.  It works! 

I had been showing the Unicode display to someone, so that showed up when I opened my laptop.  Mentioned that.  I  showed drag n drop behaviors with the PropertyEditor and MorphMorphs (MorphIt package) and then showed the puzzle pieces prototyped for planned Snap! style authoring (Emergence package).  Due to questions, I updated the README.md in Cuis-Smalltalk-BabySteps. Very pre-alpha, but there are documentation classes in the MorphIt and Emergence packages. 

> I could not find a program of the CampSmalltalk there, but saw some 
> pics. 

I presume you mean Mike Taylor's pix at https://goo.gl/photos/QCQz77DKLPAPGY5x9

No formal program.  More like, "Anybody have something they would like to share?".  Who's next?

Of note:
  WireShark packet capture analysis
  Multi-programming-language editing (e.g. syntax hilighting and keywords in Java/whatever within JavaScript within HTML).
  Baby steps to Mist/Fog (smalltalk in itself w/o VM) bootstrap.
  Glamor (Pharo presentation framework) extension project.

I am the guy in the purple Apple shirt, BTW.  [Shows up as row 3 pic 1 in my browser].  I see myself in a couple of other snaps as well.  I must have been there.  ;^)

> It looks like you had a great time there. I would like to join you 
> all there next year!

We all would be delighted if you could make it.  Might even get together an agenda/program for the event.  I heard that there will be another camp in Nanimo (British Colombia, Canada) in October, which I hope to attend.

> (cc Cuis mail list. hope you don't mind)

Not at all!  People came from as far as up from New York, Toronto, Boston, Vista (California).  I'll count Andre as from Salem (Washington).  Really need more folks from down south.

Wrote some code.  Found and fixed some bugs.  Met a great bunch of interesting folks.  Well worth the trip!

-- 
-KenD



From pbpublist at gmail.com  Tue Aug 25 13:47:50 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 25 Aug 2015 14:47:50 -0400
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55DB1E2C.4010300@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org>
Message-ID: <1440528470.2306.13.camel@gmail.com>

On Mon, 2015-08-24 at 10:37 -0300, Juan Vuletich wrote:
> Thanks Andr?s,
> 
> I'll be there. Maybe I'll submit a talk proposal too.
> 
> Folks, what do you think I'd tell about?
> - Cuis, introduction for people who don't know much about it, recent 
> development and community activity, etc.
> - Repeat, and add latest details to the talk I already gave about work 
> at Satellogic.
> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo, 
> given that there are no recent news here.
> - anything else?
> 

My main suggestion would be to go for new material (since your previous
talks were recorded people can watch them already and they're still
pretty relevant... maybe you could link to them from the Cuis site to
make them easier to find)  Recent developments and/or near-future plans
might be interesting for those who don't pay close attention to what's
going on with Cuis.
 
> Cheers,
> Juan Vuletich
> 
> On 8/18/2015 9:55 PM, Andres Valloud wrote:
> > The Fundaci?n Argentina de Smalltalk proudly invites you to one of the 
> > premier Smalltalk conferences in the world.  Let's meet at Buenos 
> > Aires, November 11-13!  For more details, see the invitation here:
> >
> > http://www.fast.org.ar/Smalltalks2015-invitation.pdf
> >
> >
> > _______________________________________________
> > 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 ume at blueplane.jp  Thu Aug 27 10:24:44 2015
From: ume at blueplane.jp (Masashi UMEZAWA)
Date: Fri, 28 Aug 2015 00:24:44 +0900
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <55DB1F56.608@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>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
	<CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>
	<55DB1F56.608@jvuletich.org>
Message-ID: <CA+=t-6D3fbHLyYck0v=wdsUZuGWAJ6uyoWopq_+-+5Haut6Ebg@mail.gmail.com>

Hi Juan,

How about adding #tryWriteStream and #tryWriteStreamIfError: for consistency.
Currently FmFileEntry has #writeStreamConfirming, but it is a bit
ad-hoc. It can be renamed to #tryWriteStream.

So we can write:

[ writeStream := 'foo.txt' asFileEntry tryWriteStream ] on:
FmFileIOAccessor fileExistsException do: [:ex | ].

writeStream := 'foo.txt' asFileEntry tryWriteStreamIfError: [:ex | ].

Best regards,

2015-08-24 22:42 GMT+09:00 Juan Vuletich <juan at jvuletich.org>:
> Hi Masashi,
>
> Ok. #tryReadStream is reasonable. Or maybe #readStreamOrFail.
>
> Any other suggestion? Preferences?
>
> Thanks,
> Juan Vuletich
>
>
> On 8/22/2015 10:15 AM, Masashi UMEZAWA wrote:
>>
>> Hi Juan,
>>
>> Yes, I'm concerning about backward-compatibility.
>> FmFileEntry>>#readStream has been used long. So I would prefer just
>> adding new APIs.
>>
>> Best regards,
>>
>>> I guess I would prefer #readStream for the basic, raising exceptions api,
>>> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the
>>> "exception
>>> eating api" . In any case it is your call, I understand there is back
>>> compatibility to care about, and I'll be happy with your choice.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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
>>>>>>>>>
>>>>>>>>>
>>
>>
>



-- 
[:masashi | ^umezawa]



From Ken.Dickey at whidbey.com  Thu Aug 27 03:48:04 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Thu, 27 Aug 2015 16:48:04 +0800
Subject: [Cuis] Font Preferences Change
Message-ID: <20150827164804.5d251b01c9c085f7874edd4f@whidbey.com>

Hi Juan,

I have done enough with resizing on Font Preference Change that I would like some feedback.

The basic questions are:
  [1] Does this direction/strategy seem OK?
  [2] Am I breaking (too many) things?
  [3] Better ideas?  Simpler strategy?
  [4] In sum, it it worth while to continue?

In base, when the user changes preferred fonts, the world gets a fontPreferenceChanged message which it sends to its submorphs, who in turn propagate the message to their submorphs and so forth.

Morph>>fontPreferenceChanged
    self submorphsDo: [ :m | m fontPreferenceChanged ]

Windows which do special things (like set up buttons with fixed* layoutSpec fields) do any special processing required.  Morphs which set relations based on some font metric update their fonts/relations.  Windows typically set up button sizes, so need to reset these.  Some morphs recalculate their minimumExtent or reset their fonts.

For example:

InnerListMorph>>fontPreferenceChanged
    super fontPreferenceChanged.
    self font: Preferences standardListFont.

Look at senders of #fontPreferenceChanged for details.


Usage:
  I have two change sets to file in to the base image.  In order, load the *LayoutTest* then the *FontResize*.

If you use the layout editors, load the Morphic-Misc1 package, then the UnsavedChanges* file.


Expect some missed resize cases.  

Thanks in advance for thoughtful comments.

-KenD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2464-KenD-LayoutTest-KenD.5.cs.st
Type: application/octet-stream
Size: 7012 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150827/c9a2e255/attachment-0009.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st
Type: application/octet-stream
Size: 7428 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150827/c9a2e255/attachment-0010.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st
Type: application/octet-stream
Size: 11990 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150827/c9a2e255/attachment-0011.obj>

From Ken.Dickey at whidbey.com  Fri Aug 28 03:28:07 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 28 Aug 2015 16:28:07 +0800
Subject: [Cuis] Font Resize Code
Message-ID: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>

Hmmm.. 

There seems to have a problem with file 2464-KenD-LayoutTest-KenD.5.cs.st.

Here is the complete set again (attached).

File in: 
  2464-KenD-LayoutTest-KenD.5.cs.st
  2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st

Optionally:
  Feature require: #'Morphic-Misc1'.
Then file in:
  UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st

Open browsers and other windows.

Then 
  World Menu>>Preferences>>Font Sizes..

And play a bit.

-- 
-KenD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st
Type: application/octet-stream
Size: 7458 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150828/c007b65a/attachment-0009.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2464-KenD-LayoutTest-KenD.5.cs.st
Type: application/octet-stream
Size: 6843 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150828/c007b65a/attachment-0010.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st
Type: application/octet-stream
Size: 11990 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150828/c007b65a/attachment-0011.obj>

From dnorton at mindspring.com  Sun Aug 30 13:19:38 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 30 Aug 2015 14:19:38 -0400
Subject: [Cuis] Font Height Change?
Message-ID: <55E3493A.32598.BF01F7@dnorton.mindspring.com>

Hi All,

The attached can illustrate a change in the spaces between lines of text. How can I find what 
is causing this change? Placing a "{...} print" in TextModelMorph>>drawOn: is definitely a bad 
idea. To see the spacing change, unzip and file in the attached, open the window with:

	AnagramWindow open.

Click "New", enter a string such as "illicit" and click "More" a few times. 

For different window sizes, the spaces between lines becomes smaller. I do adjust the width 
of the window to keep the text in columns but I'm trying to find out why the spacing changes.

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AnagramAid.pck.zip
Type: application/zip
Size: 3658 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150830/d01b2558/attachment-0003.zip>

From dnorton at mindspring.com  Sun Aug 30 17:10:13 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 30 Aug 2015 18:10:13 -0400
Subject: [Cuis] Font Height Change?
Message-ID: <55E37F45.4235.1921E41@dnorton.mindspring.com>

Never mind. In a fresh image, I can't reproduce it :-/

On 30 Aug 2015 at 14:20, cuis at jvuletich.org wrote:

> Hi All,
> 
> The attached can illustrate a change in the spaces between lines of
> text. How can I find what 
> is causing this change? Placing a "{...} print" in
> TextModelMorph>>drawOn: is definitely a bad 
> idea. To see the spacing change, unzip and file in the attached,
> open the window with:
> 
> 	AnagramWindow open.
> 
> Click "New", enter a string such as "illicit" and click "More" a few
> times. 
> 
> For different window sizes, the spaces between lines becomes
> smaller. I do adjust the width 
> of the window to keep the text in columns but I'm trying to find out
> why the spacing changes.
> 
>  - Dan
> 
> Attachments:
>   C:\Cuis\Anagram\Cuis-Smalltalk-anagram\AnagramAid.pck.zip





From dnorton at mindspring.com  Sun Aug 30 18:01:20 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 30 Aug 2015 19:01:20 -0400
Subject: [Cuis] Font Height Change?
Message-ID: <55E38B40.31946.1C0E883@dnorton.mindspring.com>

Aha! Game on again. It occurs when the font 'DejaVu Sans Mono' is installed and 
AnagramWindow>>cluesFont uses it for the text, but not always. Otherwise, it does not occur 
when the font is 'DejaVu' which is the default.

Resizing the window reverses the close spacing. A couple more clicks of "More" can cause it 
to recur.

On 30 Aug 2015 at 18:10, cuis at jvuletich.org wrote:

> Never mind. In a fresh image, I can't reproduce it :-/
> 
> On 30 Aug 2015 at 14:20, cuis at jvuletich.org wrote:
> 
> > Hi All,
> > 
> > The attached can illustrate a change in the spaces between lines
> of
> > text. How can I find what 
> > is causing this change? Placing a "{...} print" in
> > TextModelMorph>>drawOn: is definitely a bad 
> > idea. To see the spacing change, unzip and file in the attached,
> > open the window with:
> > 
> > 	AnagramWindow open.
> > 
> > Click "New", enter a string such as "illicit" and click "More" a
> few
> > times. 
> > 
> > For different window sizes, the spaces between lines becomes
> > smaller. I do adjust the width 
> > of the window to keep the text in columns but I'm trying to find
> out
> > why the spacing changes.
> > 
> >  - Dan
> > 
> > Attachments:
> >   C:\Cuis\Anagram\Cuis-Smalltalk-anagram\AnagramAid.pck.zip
> 
> 





From juan at jvuletich.org  Mon Aug 31 07:49:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 09:49:53 -0300
Subject: [Cuis] Font Resize Code
In-Reply-To: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>
References: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>
Message-ID: <55E44D71.7080502@jvuletich.org>

Hi Ken,

Apologies for not answering before.

This is a great and welcome addition. I already integrated it and it 
will be in the next commit to GitHub. Thanks!

Cheers,
Juan Vuletich

On 8/28/2015 5:28 AM, Ken.Dickey wrote:
> Hmmm..
>
> There seems to have a problem with file 2464-KenD-LayoutTest-KenD.5.cs.st.
>
> Here is the complete set again (attached).
>
> File in:
>    2464-KenD-LayoutTest-KenD.5.cs.st
>    2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st
>
> Optionally:
>    Feature require: #'Morphic-Misc1'.
> Then file in:
>    UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st
>
> Open browsers and other windows.
>
> Then
>    World Menu>>Preferences>>Font Sizes..
>
> And play a bit.
>




From juan at jvuletich.org  Mon Aug 31 07:54:20 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 09:54:20 -0300
Subject: [Cuis] Font Height Change?
In-Reply-To: <55E38B40.31946.1C0E883@dnorton.mindspring.com>
References: <55E38B40.31946.1C0E883@dnorton.mindspring.com>
Message-ID: <55E44E7C.7010608@jvuletich.org>

Hi Dan,

On 8/30/2015 8:01 PM, Dan Norton wrote:
> Aha! Game on again. It occurs when the font 'DejaVu Sans Mono' is installed and
> AnagramWindow>>cluesFont uses it for the text, but not always. Otherwise, it does not occur
> when the font is 'DejaVu' which is the default.
>
> Resizing the window reverses the close spacing. A couple more clicks of "More" can cause it
> to recur.

Found it! The problem is that in #atRandom and #permuted first you sent 
the contents to your morph, and then you modify them (without the morph 
really realizing of that). I'm not sure about the details of the 
behavior you found, but the attach is cleaner and fixes the problem.

Cheers,
Juan Vuletich
-------------- next part --------------
'From Cuis 4.2 of 25 July 2013 [latest update: #2464] on 30 August 2015 at 10:30:15.736488 pm'!

!Anagram methodsFor: 'operating' stamp: 'jmv 8/30/2015 22:29'!
atRandom
	"Display randomly selected clues"
	"estas poniendo el font despues de mandarle el texto al morph... El morph ni se entera...
	Asi, no ncecesitas cluesFont"
	| set temp |
	set _ Set new.
	self class cluesToDisplay timesRepeat: [set add: jmb shuffled].	"avoid duplicates"
	temp _ String new writeStream.
	set do: [:ea |
		temp
			nextPutAll: ea;
			nextPutAll: self separators].
	self board cluesString actualContents: (Text 
		initialFont: (AbstractFont familyName: 'DejaVu Sans Mono' aroundPointSize: 10)
		stringOrText: temp contents).
	count _ count + set size! !

!Anagram methodsFor: 'operating' stamp: 'jmv 8/30/2015 22:29'!
permuted
	"Display a set of permuted clues"
	| clueSet clue str |
	clue _ String new writeStream.
	clueSet _ Set new.
	(1 to: jmb size) permutationsDo: [ :letter |
		clue reset.
		(1 to: jmb size) do: [ :ix |
			clue nextPut: (jmb at: (letter at: ix))].
		clueSet add: clue contents].	"avoid duplicates"
	str _ String new writeStream.
	clueSet do: [:ea |
		str
			nextPutAll: ea;
			nextPutAll: self separators].
	self board cluesString actualContents: (Text 
		initialFont: (AbstractFont familyName: 'DejaVu Sans Mono' aroundPointSize: 10)
		stringOrText: str contents).
	count _ count + clueSet size! !

!methodRemoval: AnagramWindow #cluesFont!
AnagramWindow removeSelector: #cluesFont!

From juan at jvuletich.org  Mon Aug 31 07:57:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 09:57:49 -0300
Subject: [Cuis] Oops!  [Was package relative fileIns]
In-Reply-To: <20150824153355.5c917d40a1bbea5e7d893085@whidbey.com>
References: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>	<55DB31B7.4050203@jvuletich.org>
	<20150824153355.5c917d40a1bbea5e7d893085@whidbey.com>
Message-ID: <55E44F4D.2060709@jvuletich.org>

Hi Ken,

Thanks for the report :)

Nice to see you!

Cheers,
Juan Vuletich

On 8/24/2015 7:33 PM, Ken.Dickey wrote:
> On Mon, 24 Aug 2015 12:01:11 -0300
> Juan Vuletich<juan at jvuletich.org>  wrote:
>
>> Hi Ken,
>>
>> On 8/23/2015 12:43 PM, Ken.Dickey wrote:
> ..
>>> The Portland Camp Smalltalk was much fun, BTW.  Met some interesting folks.  Showed Cuis to Gemstone and Instantiations people + general demo.   Found and fixed a few bugs.  Nice folks.
>>>
>>> -KenD
>
>> Hey that's great! Thank you! Where the talks recoded on video?
> No.  I don't think so.  Pretty informal.  First time I had tried the video out on my ChromeBook.  It works!
>
> I had been showing the Unicode display to someone, so that showed up when I opened my laptop.  Mentioned that.  I  showed drag n drop behaviors with the PropertyEditor and MorphMorphs (MorphIt package) and then showed the puzzle pieces prototyped for planned Snap! style authoring (Emergence package).  Due to questions, I updated the README.md in Cuis-Smalltalk-BabySteps. Very pre-alpha, but there are documentation classes in the MorphIt and Emergence packages.
>
>> I could not find a program of the CampSmalltalk there, but saw some
>> pics.
> I presume you mean Mike Taylor's pix at https://goo.gl/photos/QCQz77DKLPAPGY5x9
>
> No formal program.  More like, "Anybody have something they would like to share?".  Who's next?
>
> Of note:
>    WireShark packet capture analysis
>    Multi-programming-language editing (e.g. syntax hilighting and keywords in Java/whatever within JavaScript within HTML).
>    Baby steps to Mist/Fog (smalltalk in itself w/o VM) bootstrap.
>    Glamor (Pharo presentation framework) extension project.
>
> I am the guy in the purple Apple shirt, BTW.  [Shows up as row 3 pic 1 in my browser].  I see myself in a couple of other snaps as well.  I must have been there.  ;^)
>
>> It looks like you had a great time there. I would like to join you
>> all there next year!
> We all would be delighted if you could make it.  Might even get together an agenda/program for the event.  I heard that there will be another camp in Nanimo (British Colombia, Canada) in October, which I hope to attend.
>
>> (cc Cuis mail list. hope you don't mind)
> Not at all!  People came from as far as up from New York, Toronto, Boston, Vista (California).  I'll count Andre as from Salem (Washington).  Really need more folks from down south.
>
> Wrote some code.  Found and fixed some bugs.  Met a great bunch of interesting folks.  Well worth the trip!
>




From juan at jvuletich.org  Mon Aug 31 08:01:51 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 10:01:51 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <1440528470.2306.13.camel@gmail.com>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>	<55DB1E2C.4010300@jvuletich.org>
	<1440528470.2306.13.camel@gmail.com>
Message-ID: <55E4503F.6030603@jvuletich.org>

Hi Folks,

On 8/25/2015 3:47 PM, Phil (list) wrote:
> On Mon, 2015-08-24 at 10:37 -0300, Juan Vuletich wrote:
>> Thanks Andr?s,
>>
>> I'll be there. Maybe I'll submit a talk proposal too.
>>
>> Folks, what do you think I'd tell about?
>> - Cuis, introduction for people who don't know much about it, recent
>> development and community activity, etc.
>> - Repeat, and add latest details to the talk I already gave about work
>> at Satellogic.
>> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo,
>> given that there are no recent news here.
>> - anything else?
>>
> My main suggestion would be to go for new material (since your previous
> talks were recorded people can watch them already and they're still
> pretty relevant... maybe you could link to them from the Cuis site to
> make them easier to find)  Recent developments and/or near-future plans
> might be interesting for those who don't pay close attention to what's
> going on with Cuis.

Thanks you all for your suggestions. Please tell if you think of 
something else, or more specific questions or issues to address in a talk.

Phil, the idea to link to the videos is very good. Do you (or anybody) 
know how to do that? Maybe a link to youtube that already includes a 
search for "Cuis Smalltalk"? Or some sort of auto-generated playlist?

Thanks,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 31 08:09:33 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 10:09:33 -0300
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>	<55DB20BB.708@jvuletich.org>
	<CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
Message-ID: <55E4520D.4040105@jvuletich.org>

Hi Joe,

On 8/24/2015 11:25 AM, Joe Shirk wrote:
>
>
> Hi Juan,
>
> I was trying to diplomatically imply that Benet's forte is not 
> presentation, however the docs on the site and on github are adequate 
> introductions, and I think it won't take long to see the value in what 
> is  meant by "permanent" web that is content addressed instead of ip 
> addressed.
>
> I spoke too soon today, not aware that he had recently responded to my 
> post a week ago:
>
> https:// 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>github.com 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/ 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/ 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/issues/80#issuecomment-133593050 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>
>
> As at the moment I am thumbing my smartphone, I have to be brief, but 
> I'll try to cover the basics.
>
> ipfs is a protocal that has the potential to eventually replace http 
> altogether, though currently content on the ipfs network is accessible 
> directly through the protocol as well as through http gateways.
>
> ipfs is a content routing system, and so functions like a cdn, but it 
> is distributed, so is like bittorrent. it does sync like dropbox, but 
> the routing system ensures that copies of content migrate closer to 
> demand, which could be an auditorium of people on a local wifi without 
> external access. Real-time syncing to many peers is thus possible 
> without latency.
>
> There are working demos of HD videos streaming without latency from 
> the network.
>
> The Directed Acyclical Graph / Merkel Tree allows for just about any 
> data structure, but is especially well designed for versioning. 
> Everything is addressed by its hash fingerprint, so one can be 
> absolutely sure what version one requests, but can also traverse the 
> version tree if the content referenced is say, a software library that 
> is a dependency for a certain package. Automatic forwarding to a more 
> recent version is also a feature.
>
> There is a name system too, that allows one to register a permanent or 
> temporary namespace that references a version tree of any object.
>
> All objects are stored in encrypted chunks, so privacy and publicity 
> are controlled.
>
> To me, this system implemented in smalltalk, and I suppose that should 
> be squeak and amber, will make it possible to build distributed apps, 
> because the app itself can be an object, not only its content or data. 
> Implementing in smalltalk should mean that the complexity involved 
> would be more easily managed with few bugs, compared to say, 
> javascript or node.
>
> I see ipfs as a route to put smalltalk in the limelight and on the 
> cutting edge.
>
> HTH
>
> Joe
>

Thanks for the explanation. I think that implementing it, and playing 
and experimenting with it will show new and better ways of sharing code 
and content, in a word, objects.

I look forward for all this.

Cheers,
Juan Vuletich

>
>
>
> > Message: 5
> > Date: Mon, 24 Aug 2015 10:48:43 -0300
> > From: Juan Vuletich <juan at jvuletich.org <mailto:juan at jvuletich.org>>
> > To: Discussion of Cuis Smalltalk <cuis at jvuletich.org 
> <mailto:cuis at jvuletich.org>>
> > Cc: Joe Shirk <j.b.shirk at gmail.com <mailto:j.b.shirk at gmail.com>>
> > Subject: Re: [Cuis] IPFS on Smalltalk
> > Message-ID: <55DB20BB.708 at jvuletich.org 
> <mailto:55DB20BB.708 at jvuletich.org>>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> >
> > Hi Joe,
> >
> > Someone saying "awesome!" and "cool!" so many times at his own stuff
> > makes me a little uncomfortable... But, anyway:
> >
> > It looks like Dropbox, but peer to peer, right?
> >
> > The possibility of publishing and sharing stuff without a central
> > provider is of course desirable.
> >
> > Before starting to implement bindings and calls to the api... Is that
> > really needed? It is integrated in the file system, so maybe not.
> >
> > More interesting than that, what are some apps that could benefit from
> > it? How would they do that?
> >
> > Cheers,
> > Juan Vuletich
> >
> > On 8/24/2015 8:42 AM, Joe Shirk wrote:
> > > Dear all, especially @Masashi
> > >
> > > I wanted to draw attention to thehttp://ipfs.io project, "the
> > > permanent web" which works. It is a distributed peer-to-peer
> > > filesystem that works somewhat like bittorrent. You get the
> > > functionality of Git as well. It is truly ingenious.
> > >
> > > Since I have taken an interest in Smalltalk (I'm still learning) I
> > > have salivated at the  possibilities for, say Amber + ipfs.
> > >
> > > There is currently a call for APIs implemented in other languages;
> > >https://github.com/ipfs/ipfs/issues
> > > I see no one there is interested in Smalltalk so I though I should
> > > undertake it, but it will be many months before I have the knowledge
> > > and there is no guarantee that I am up to the task... Now seeing that
> > > Masashi is working with filesystems, perhaps you would take an
> > > interest in this idea.
> > >
> > > The inventor Juan Benet has many brilliant ideas and has done several
> > > presentations to be found on the ipfs site. Unfortunately, he seems to
> > > drink a lot of coffee and talks extremely fast and does not enunciate,
> > > making the presentations very difficult to understand for those of
> > > whom english is a second language. I can definitely help with this by
> > > making a transcript if there is interest.
> > >
> >
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Cuis mailing list
> >Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
> >http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
> >
> > ------------------------------
> >
> > End of Cuis Digest, Vol 38, Issue 23
> > ************************************
>
>
> _______________________________________________
> 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/20150831/5523cc1f/attachment-0003.html>

From juan at jvuletich.org  Mon Aug 31 08:20:06 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 10:20:06 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6D3fbHLyYck0v=wdsUZuGWAJ6uyoWopq_+-+5Haut6Ebg@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>
	<55B64713.8040806@jvuletich.org>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
	<CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>
	<55DB1F56.608@jvuletich.org>
	<CA+=t-6D3fbHLyYck0v=wdsUZuGWAJ6uyoWopq_+-+5Haut6Ebg@mail.gmail.com>
Message-ID: <55E45486.30506@jvuletich.org>

Hi Masashi,

Looks great to me. Please let us know when you update 
https://github.com/mumez/FileMan (or 
https://github.com/mumez/Cuis-Smalltalk-FileMan ), so we follow. Or post 
code to the mail list. As you prefer.

Thanks!
Juan Vuletich

On 8/27/2015 12:24 PM, Masashi UMEZAWA wrote:
> Hi Juan,
>
> How about adding #tryWriteStream and #tryWriteStreamIfError: for consistency.
> Currently FmFileEntry has #writeStreamConfirming, but it is a bit
> ad-hoc. It can be renamed to #tryWriteStream.
>
> So we can write:
>
> [ writeStream := 'foo.txt' asFileEntry tryWriteStream ] on:
> FmFileIOAccessor fileExistsException do: [:ex | ].
>
> writeStream := 'foo.txt' asFileEntry tryWriteStreamIfError: [:ex | ].
>
> Best regards,
>
> 2015-08-24 22:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>> Hi Masashi,
>>
>> Ok. #tryReadStream is reasonable. Or maybe #readStreamOrFail.
>>
>> Any other suggestion? Preferences?
>>
>> Thanks,
>> Juan Vuletich
>>
>>
>> On 8/22/2015 10:15 AM, Masashi UMEZAWA wrote:
>>> Hi Juan,
>>>
>>> Yes, I'm concerning about backward-compatibility.
>>> FmFileEntry>>#readStream has been used long. So I would prefer just
>>> adding new APIs.
>>>
>>> Best regards,
>>>
>>>> I guess I would prefer #readStream for the basic, raising exceptions api,
>>>> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the
>>>> "exception
>>>> eating api" . In any case it is your call, I understand there is back
>>>> compatibility to care about, and I'll be happy with your choice.
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>>
>>>>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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 Ken.Dickey at whidbey.com  Mon Aug 31 09:50:50 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 31 Aug 2015 07:50:50 -0700
Subject: [Cuis] Font Resize Code
In-Reply-To: <55E44D71.7080502@jvuletich.org>
References: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>
	<55E44D71.7080502@jvuletich.org>
Message-ID: <20150831075050.f99f1041f30d9e155e39caed@whidbey.com>

On Mon, 31 Aug 2015 09:49:53 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Apologies for not answering before.

No worries.  Storm here with high winds knocked out power for 2 days, so I would not have known anyway.

> This is a great and welcome addition. I already integrated it and it 
> will be in the next commit to GitHub. Thanks!

You are very welcome!

Good to give demos.  One has the opportunity to learn and get embarrassed, which leads toward progress.  ;^) 

Back to reading Snap! code..

Cheers,
-KenD



From dnorton at mindspring.com  Mon Aug 31 12:38:47 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 31 Aug 2015 13:38:47 -0400
Subject: [Cuis] Font Height Change?
In-Reply-To: <55E44E7C.7010608@jvuletich.org>
References: <55E38B40.31946.1C0E883@dnorton.mindspring.com>,
	<55E44E7C.7010608@jvuletich.org>
Message-ID: <55E49127.31197.88F661@dnorton.mindspring.com>

Thanks for the answer, Juan. It stops confusing and annoying the morph :)

 - Dan

On 31 Aug 2015 at 9:54, Juan Vuletich wrote:

> Hi Dan,
> 
> On 8/30/2015 8:01 PM, Dan Norton wrote:
> > Aha! Game on again. It occurs when the font 'DejaVu Sans Mono' is
> installed and
> > AnagramWindow>>cluesFont uses it for the text, but not always.
> Otherwise, it does not occur
> > when the font is 'DejaVu' which is the default.
> >
> > Resizing the window reverses the close spacing. A couple more
> clicks of "More" can cause it
> > to recur.
> 
> Found it! The problem is that in #atRandom and #permuted first you
> sent 
> the contents to your morph, and then you modify them (without the
> morph 
> really realizing of that). I'm not sure about the details of the 
> behavior you found, but the attach is cleaner and fixes the
> problem.
> 
> Cheers,
> Juan Vuletich
> 





From pbpublist at gmail.com  Mon Aug 31 16:54:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 31 Aug 2015 17:54:01 -0400
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55E4503F.6030603@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org> <1440528470.2306.13.camel@gmail.com>
	<55E4503F.6030603@jvuletich.org>
Message-ID: <1441058041.8967.11.camel@gmail.com>

On Mon, 2015-08-31 at 10:01 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> On 8/25/2015 3:47 PM, Phil (list) wrote:
> > On Mon, 2015-08-24 at 10:37 -0300, Juan Vuletich wrote:
> >> Thanks Andr?s,
> >>
> >> I'll be there. Maybe I'll submit a talk proposal too.
> >>
> >> Folks, what do you think I'd tell about?
> >> - Cuis, introduction for people who don't know much about it, recent
> >> development and community activity, etc.
> >> - Repeat, and add latest details to the talk I already gave about work
> >> at Satellogic.
> >> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo,
> >> given that there are no recent news here.
> >> - anything else?
> >>
> > My main suggestion would be to go for new material (since your previous
> > talks were recorded people can watch them already and they're still
> > pretty relevant... maybe you could link to them from the Cuis site to
> > make them easier to find)  Recent developments and/or near-future plans
> > might be interesting for those who don't pay close attention to what's
> > going on with Cuis.
> 
> Thanks you all for your suggestions. Please tell if you think of 
> something else, or more specific questions or issues to address in a talk.
> 
> Phil, the idea to link to the videos is very good. Do you (or anybody) 
> know how to do that? Maybe a link to youtube that already includes a 
> search for "Cuis Smalltalk"? Or some sort of auto-generated playlist?
> 

There are a few different ways I can think of depending on your
preference:
1) You could create a 'videos' page on the Cuis site (this is what I was
thinking) and then create embedded players for each video.  Go to a
video you want to add, click the share link, then the embed tab to get
the html snippet.  The reason to keep this on a separate page is that
YouTube embeds aren't 'lightweight' so it would be polite to keep these
off the main page or you will probably annoy visitors and decrease
traffic to the main Cuis page.  If they click on a videos link
presumably they understand that this might be a heavier page but it is
what they want...
2) Create a YouTube playlist on your YouTube channel.  This is just a
matter of going to each video you want and click the add button and add
it to the playlist (and make sure the playlist is public).  This works
but then there is no linkage between the Cuis page and the playlist
(though you could combine this and item 1 and do an embedded playlist)
3) A YouTube search such as
https://www.youtube.com/results?search_query=cuis+smalltalk will 'sort
of' get you in the ballpark, but probably not what visitors will
want/expect.

Here are a couple of videos that would probably be good to add to the
list:
https://www.youtube.com/watch?v=bgIwbx-eDcI
https://www.youtube.com/watch?v=YFn4tShalUI

I seem to also recall a general English Cuis overview presentation you
did (also at a Smalltalks conf?) but can't find the link right now...

> Thanks,
> Juan Vuletich





From peter at aba-instituut.nl  Sat Aug  1 06:57:13 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Sat, 1 Aug 2015 13:57:13 +0200
Subject: [Cuis] (Rescued) Re: Fwd: Re: DIRECT version number
In-Reply-To: <CAGQxfVhZfsbRw=Fiq0fy5_5MHU5bqEEnM2S1F5akOKUMmxXUJg@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>
	<1437592756.2326.32.camel@gmail.com>
	<CAGQxfVhZfsbRw=Fiq0fy5_5MHU5bqEEnM2S1F5akOKUMmxXUJg@mail.gmail.com>
Message-ID: <CAJBxtBZgJ-ku-6KBu=axEKL=hOX8sTiF7KDAB0heTquLzEMiAg@mail.gmail.com>

Hi Hannes,

You asked for an example of a Feature Test. I assume, but may be wrong,
that you want this to understand better what the intention of such a test
is. Of course I can only answer form my own imagination.

1 It should be something that provides a definite answer to a question
about the image/system, but where there is not necessarily a good or bad
outcome (as there is with a unit test; pass=good, fail or error=bad). So
for instance it could test if there is any class loaded that implements
AnsiDateAndTime protocol (or at least part of it and how much). Or it could
test if the number of classes is less than the number of instance
variables. Or it could test how many classes have a class comment. It could
test how many literals may be in a method. Still, it seems logical to want
to define Features in such a way that the presence of the feature is a good
situation (better or no worse than the absence).

2 An essential feature of a Feature Test is that it should be able to load
and run in in any image. Its no use of course if you want to figure
something out and you can't load and run the test that determines what you
want to know. So The Feature test must be able to compile and run source
code (it could conceivably interpret syntax trees but that seems rather
contrived given that the compiler is normally available in any image). And
while doing that it should be able to suppress any problems.

3 There should be some way to (build Feature Test Suites suites and/or) run
all the loaded Feature tests together, silently, and receive feedback only
at the end. Most simply in the form of a document/text that shows how it
went. Optionally using some kind of GUI, viz. SUnitBrowser. The default
FeatureTestSuite could simply run all loaded Feature Tests, and you could
subclass it if you wanted to define specific Suites.

I think it would be great to have a FeatureTest class that you could
subclass to run tests on how much of the Ansi standard is implemented in
the image and how accurately it follows the semantics prescribed. The
original Camp Smalltalk attempts at such a test suite were based on SUnit
as the test framework, but that didn't work as it is essentially unsuited
to loading tests about code that may not be laoded.

Cheers, Peter



On Fri, Jul 31, 2015 at 8:29 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> 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
> >
>
> _______________________________________________
> 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/20150801/63b2b971/attachment-0004.html>

From squeaklists at fang.demon.co.uk  Sun Aug  2 02:04:13 2015
From: squeaklists at fang.demon.co.uk (Douglas Brebner)
Date: Sun, 02 Aug 2015 08:04:13 +0100
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: <55BDC0ED.3060401@fang.demon.co.uk>

On 19/07/2015 22:38, Phil (list) wrote:
> 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 vaguely recall that many years ago there was a project called 
SmallInterfaces that let you define public interfaces to objects. (Or 
something like that). Would that be a good way to document the 
public/private api using code?

(sorry for being so vague but I've been awake for 24+ hours now)



From dnorton at mindspring.com  Sun Aug  2 20:24:40 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 02 Aug 2015 21:24:40 -0400
Subject: [Cuis] VM Crash
Message-ID: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>

Load Cuis4.2-2439.image. Open File List and go to Packages.
Select Graphics-Files-Additional.pck.st and click on "Install Package".

Get "Fatal VM Error". The zipped crash.dmp is attached.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150802/6f3e6f01/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash.zip
Type: application/zip
Size: 3832 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150802/6f3e6f01/attachment-0004.zip>

From dnorton at mindspring.com  Mon Aug  3 11:54:24 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 03 Aug 2015 12:54:24 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55B8E93C.7080009@jvuletich.org>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55B8E93C.7080009@jvuletich.org>
Message-ID: <55BF9CC0.20600.59E8552@dnorton.mindspring.com>

On 29 Jul 2015 at 11:54, Juan Vuletich wrote:

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

I'm trying to get FreeType built and also I did a clone of:

https://github.com/rougier/freetype-gl

Unfortunately when I compile embedded-font.c the following occurs:

fatal error C1083: Cannot open include file: 'vera-16.h': No such file or directory

Do any of you Cexperts know where I can get 'vera-16.h'? Google search produces ads for 
soaps containing aloe vera :-)

 - Dan



From juan at jvuletich.org  Mon Aug  3 13:38:10 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:38:10 -0300
Subject: [Cuis] New updates: WeightTracer / ReferenceFinder
In-Reply-To: <1438189897.2292.6.camel@gmail.com>
References: <55B7757D.80006@jvuletich.org>	 <1438119702.2292.5.camel@gmail.com>
	<55B8E7EA.7060301@jvuletich.org>
	<1438189897.2292.6.camel@gmail.com>
Message-ID: <55BFB512.3060109@jvuletich.org>

On 7/29/2015 2:11 PM, Phil (list) wrote:
> 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

And accepted. Thank you!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug  3 13:49:55 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:49:55 -0300
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55BDC0ED.3060401@fang.demon.co.uk>
References: <55A905A3.1060100@jvuletich.org>	<1437158701.2255.245.camel@gmail.com>	<55ABB223.8010309@jvuletich.org>	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
Message-ID: <55BFB7D3.4030701@jvuletich.org>

Hi Doug,

On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> On 19/07/2015 22:38, Phil (list) wrote:
>> 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 vaguely recall that many years ago there was a project called 
> SmallInterfaces that let you define public interfaces to objects. (Or 
> something like that). Would that be a good way to document the 
> public/private api using code?
>
> (sorry for being so vague but I've been awake for 24+ hours now)

Thanks for the pointer. I took a look at it. It is quite like Java 
interfaces. The tools are interesting. But I see several downsides:

- Each interface is a class. Each method in the protocol is an actual 
method. If we use this to document all public protocols in Cuis, it 
would mean a lot of new classes and methods.
- The source code of (for example) OrderedCollection>>at: would not 
include the information of it belonging to interface "Indexable". 
Without additional support from tools users can't tell whether a message 
is public protocol or not. And the base image / package maintainer can't 
easily see he's about to change a public api.

I think a method pragma, that includes the name of the protocol avoids 
these issues and is a better choice.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug  3 13:57:21 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:57:21 -0300
Subject: [Cuis] VM Crash
In-Reply-To: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>
References: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>
Message-ID: <55BFB991.1070807@jvuletich.org>

On 8/2/2015 10:24 PM, Dan Norton wrote:
> Load Cuis4.2-2439.image. Open File List and go to Packages.
> Select Graphics-Files-Additional.pck.st and click on "Install Package".
>
> Get "Fatal VM Error". The zipped crash.dmp is attached.
>
>  - Dan
>

I can not reproduce it. Can you reproduce it consistently? Can you 
reproduce it consistently with a fresh image and VM on a local hard 
drive? If so, please provide more details so I can reproduce it.

It seems to be a stack overflow. If you can reproduce it, you can try 
again, and after Install Package do alt+. (User Interrupt) and try to 
find out why there is an unbounded recursion.

Thanks,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150803/90602200/attachment-0004.html>

From juan at jvuletich.org  Mon Aug  3 13:59:47 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 15:59:47 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55BF9CC0.20600.59E8552@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55B8E93C.7080009@jvuletich.org>
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>
Message-ID: <55BFBA23.4010302@jvuletich.org>

On 8/3/2015 1:54 PM, Dan Norton wrote:
> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
>
>> 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.
>>
> I'm trying to get FreeType built and also I did a clone of:
>
> https://github.com/rougier/freetype-gl
>
> Unfortunately when I compile embedded-font.c the following occurs:
>
> fatal error C1083: Cannot open include file: 'vera-16.h': No such file or directory
>
> Do any of you Cexperts know where I can get 'vera-16.h'? Google search produces ads for
> soaps containing aloe vera :-)
>
>   - Dan

Hi Dan,

I can not help you with the build of FreeType , but could you try the 
image I used to build the fonts? You shouldn't need to build anything to 
run it. The FreeType VM plugin is included for both Windows and Mac. I'd 
appreciate any feedback.

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Mon Aug  3 14:16:21 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 03 Aug 2015 15:16:21 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55BF9CC0.20600.59E8552@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>
	, <55B8E93C.7080009@jvuletich.org>
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>
Message-ID: <1438629381.12996.1.camel@gmail.com>

On Mon, 2015-08-03 at 12:54 -0400, Dan Norton wrote:
> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> 
> > 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.
> > 
> 
> I'm trying to get FreeType built and also I did a clone of:
> 
> https://github.com/rougier/freetype-gl
> 
> Unfortunately when I compile embedded-font.c the following occurs:
> 
> fatal error C1083: Cannot open include file: 'vera-16.h': No such file or directory
> 
> Do any of you Cexperts know where I can get 'vera-16.h'? Google search produces ads for 
> soaps containing aloe vera :-)
> 

It looks like it's a file generated from Vera.ttf based on
https://travis-ci.org/rougier/freetype-gl

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





From pbpublist at gmail.com  Mon Aug  3 14:19:42 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 03 Aug 2015 15:19:42 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <55BFB7D3.4030701@jvuletich.org>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org>
Message-ID: <1438629582.12996.4.camel@gmail.com>

On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
> Hi Doug,
> 
> On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> > On 19/07/2015 22:38, Phil (list) wrote:
> >> 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 vaguely recall that many years ago there was a project called 
> > SmallInterfaces that let you define public interfaces to objects. (Or 
> > something like that). Would that be a good way to document the 
> > public/private api using code?
> >
> > (sorry for being so vague but I've been awake for 24+ hours now)
> 
> Thanks for the pointer. I took a look at it. It is quite like Java 
> interfaces. The tools are interesting. But I see several downsides:
> 
> - Each interface is a class. Each method in the protocol is an actual 
> method. If we use this to document all public protocols in Cuis, it 
> would mean a lot of new classes and methods.
> - The source code of (for example) OrderedCollection>>at: would not 
> include the information of it belonging to interface "Indexable". 
> Without additional support from tools users can't tell whether a message 
> is public protocol or not. And the base image / package maintainer can't 
> easily see he's about to change a public api.
> 
> I think a method pragma, that includes the name of the protocol avoids 
> these issues and is a better choice.
> 

I agree.  Let's keep it as simple as possible and see how far that gets
us.

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





From peter at aba-instituut.nl  Mon Aug  3 15:35:51 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Mon, 3 Aug 2015 22:35:51 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1438629582.12996.4.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org>
	<1438629582.12996.4.camel@gmail.com>
Message-ID: <CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>

Hi,

1. I'm totally against introducing pragma's (perhaps they already exist in
Cuis, I don't know).

First of all because they are not Smalltalk, and second because they are
not needed.

What would be wrong with simply introducing a convention and adding a
method cuisPublicSelectors to a class?

To avoid seeing them on the instance side, there could also be
cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class side.

At the top these would be defined as self allSelectors.

If someone wanted to view only the public selectors in a browser, they
would check the checkbox for that and the browser would hide the non-public
selectors.

Or the browser could show a nice public interface report added to the class
comment.

2. On another point: interfaces such as indexable could simply be described
by creating a class CuisInterfaceSpecification which gets a subclass for
each interface specified. The methods belonging to the interface are
defined and get a comment explaining the semantics of the method. This
makes it easy for tools to check which interfaces are (probably)
implemented by a class. If desired, each method could be additionally
defined to return a MethodSpecification object that knows about
preconditions, invariants, return values, argument and return
types/interfaces...but then it becomes progressively more complicated.

But anyway, in this way whoever thinks it's important enough, can add the
info (for public selectors of a class or for whole interface
specifications) without anyone who is not interested in that needing to
know or care about that.

In my mind that gels well with Cuis' philosophy of simplicity. But I could
be missing the whole point...

Cheers, Peter





On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <pbpublist at gmail.com> wrote:

> On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
> > Hi Doug,
> >
> > On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> > > On 19/07/2015 22:38, Phil (list) wrote:
> > >> 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 vaguely recall that many years ago there was a project called
> > > SmallInterfaces that let you define public interfaces to objects. (Or
> > > something like that). Would that be a good way to document the
> > > public/private api using code?
> > >
> > > (sorry for being so vague but I've been awake for 24+ hours now)
> >
> > Thanks for the pointer. I took a look at it. It is quite like Java
> > interfaces. The tools are interesting. But I see several downsides:
> >
> > - Each interface is a class. Each method in the protocol is an actual
> > method. If we use this to document all public protocols in Cuis, it
> > would mean a lot of new classes and methods.
> > - The source code of (for example) OrderedCollection>>at: would not
> > include the information of it belonging to interface "Indexable".
> > Without additional support from tools users can't tell whether a message
> > is public protocol or not. And the base image / package maintainer can't
> > easily see he's about to change a public api.
> >
> > I think a method pragma, that includes the name of the protocol avoids
> > these issues and is a better choice.
> >
>
> I agree.  Let's keep it as simple as possible and see how far that gets
> us.
>
> > 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/20150803/df8af54b/attachment-0004.html>

From dnorton at mindspring.com  Mon Aug  3 19:08:08 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 03 Aug 2015 20:08:08 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55BFBA23.4010302@jvuletich.org>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>,
	<55BFBA23.4010302@jvuletich.org>
Message-ID: <55C00268.12873.72B9E46@dnorton.mindspring.com>

On 3 Aug 2015 at 15:59, Juan Vuletich wrote:

> On 8/3/2015 1:54 PM, Dan Norton wrote:
> > On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> >
> >> 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.
> >>
> > I'm trying to get FreeType built and also I did a clone of:
> >
> > https://github.com/rougier/freetype-gl
> >
> > Unfortunately when I compile embedded-font.c the following
> occurs:
> >
> > fatal error C1083: Cannot open include file: 'vera-16.h': No such
> file or directory
> >
> > Do any of you Cexperts know where I can get 'vera-16.h'? Google
> search produces ads for
> > soaps containing aloe vera :-)
> >
> >   - Dan
> 
> Hi Dan,
> 
> I can not help you with the build of FreeType , but could you try
> the 
> image I used to build the fonts? You shouldn't need to build
> anything to 
> run it. The FreeType VM plugin is included for both Windows and Mac.
> I'd 
> appreciate any feedback.
>

OK, the package works as far as choosing fonts from a list. How the list is derived is not 
clear. Inconsolata is not on it. The chosen font can be used in ListMorphs. The thing which 
eludes me here is the same in the other environs: How to write a .bmp file containing the 
glyphs. That problem was the reason for pursuing FreeType and OpenGL. I see the 
characters displayed in the pane. They are drawn correctly. Where are the glyphs?

 - Dan



From juan at jvuletich.org  Mon Aug  3 19:51:42 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 21:51:42 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C00268.12873.72B9E46@dnorton.mindspring.com>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55BF9CC0.20600.59E8552@dnorton.mindspring.com>,
	<55BFBA23.4010302@jvuletich.org>
	<55C00268.12873.72B9E46@dnorton.mindspring.com>
Message-ID: <55C00C9E.5040207@jvuletich.org>

On 03/08/2015 09:08 p.m., Dan Norton wrote:
> On 3 Aug 2015 at 15:59, Juan Vuletich wrote:
>
>> On 8/3/2015 1:54 PM, Dan Norton wrote:
>>> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
>>>
>>>> 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.
>>>>
>>> I'm trying to get FreeType built and also I did a clone of:
>>>
>>> https://github.com/rougier/freetype-gl
>>>
>>> Unfortunately when I compile embedded-font.c the following
>> occurs:
>>> fatal error C1083: Cannot open include file: 'vera-16.h': No such
>> file or directory
>>> Do any of you Cexperts know where I can get 'vera-16.h'? Google
>> search produces ads for
>>> soaps containing aloe vera :-)
>>>
>>>    - Dan
>> Hi Dan,
>>
>> I can not help you with the build of FreeType , but could you try
>> the
>> image I used to build the fonts? You shouldn't need to build
>> anything to
>> run it. The FreeType VM plugin is included for both Windows and Mac.
>> I'd
>> appreciate any feedback.
>>
> OK, the package works as far as choosing fonts from a list. How the list is derived is not
> clear. Inconsolata is not on it. The chosen font can be used in ListMorphs. The thing which
> eludes me here is the same in the other environs: How to write a .bmp file containing the
> glyphs. That problem was the reason for pursuing FreeType and OpenGL. I see the
> characters displayed in the pane. They are drawn correctly. Where are the glyphs?
>
>   - Dan

When you open that image, you see a browser open on a method called 
#export. Some text is already selected. Before the selected text it says 
"Set FreeType preferences" and "Create a folder named AAFonts". The 
selected text does "FreeTypeFontProvider current updateFromSystem." . 
This loads your Windows / MacOS fonts into the image. Then follows a 
lists of fonts. Those fonts must be available to the system. The rest of 
the selected code does the export, saving the bmp and txt files. To 
export Inconsolata, or any other font, first load it into your Windows 
or MacOS system, then add it to the list, then export.

I thought all this was self-explanatory...

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug  3 19:55:10 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 03 Aug 2015 21:55:10 -0300
Subject: [Cuis] Please tell about your projects Re: Fwd: Re: DIRECT
 version number
In-Reply-To: <1437950873600-4839529.post@n4.nabble.com>
References: <55B0F0B2.6090202@jvuletich.org>
	<1437950873600-4839529.post@n4.nabble.com>
Message-ID: <55C00D6E.3020602@jvuletich.org>

Thanks, folks.

(inline)
On 26/07/2015 07:47 p.m., Dan Norton wrote:
>
> 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?
>

Uh, that was a long time ago... I guess it was around 1997 or 1998... It 
would be fun to do it, though.

Cheers,
Juan Vuletich

> App delivery sans IDE, halos, menus
>
> Apps with feedback; output becomes next input
>
> Recognition biometrics
>
> Financial analysis
>
> Anything fun
>
>   - Dan




From dnorton at mindspring.com  Mon Aug  3 21:52:12 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 03 Aug 2015 22:52:12 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C00C9E.5040207@jvuletich.org>
References: <55B7FB62.25351.1C4DD5C@dnorton.mindspring.com>,
	<55C00268.12873.72B9E46@dnorton.mindspring.com>,
	<55C00C9E.5040207@jvuletich.org>
Message-ID: <55C028DC.25658.2EEEB2@dnorton.mindspring.com>

On 3 Aug 2015 at 21:51, Juan Vuletich wrote:

> On 03/08/2015 09:08 p.m., Dan Norton wrote:
> > On 3 Aug 2015 at 15:59, Juan Vuletich wrote:
> >
> >> On 8/3/2015 1:54 PM, Dan Norton wrote:
> >>> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> >>>
> >>>> 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.
> >>>>
> >>> I'm trying to get FreeType built and also I did a clone of:
> >>>
> >>> https://github.com/rougier/freetype-gl
> >>>
> >>> Unfortunately when I compile embedded-font.c the following
> >> occurs:
> >>> fatal error C1083: Cannot open include file: 'vera-16.h': No
> such
> >> file or directory
> >>> Do any of you Cexperts know where I can get 'vera-16.h'?
> Google
> >> search produces ads for
> >>> soaps containing aloe vera :-)
> >>>
> >>>    - Dan
> >> Hi Dan,
> >>
> >> I can not help you with the build of FreeType , but could you
> try
> >> the
> >> image I used to build the fonts? You shouldn't need to build
> >> anything to
> >> run it. The FreeType VM plugin is included for both Windows and
> Mac.
> >> I'd
> >> appreciate any feedback.
> >>
> > OK, the package works as far as choosing fonts from a list. How
> the list is derived is not
> > clear. Inconsolata is not on it. The chosen font can be used in
> ListMorphs. The thing which
> > eludes me here is the same in the other environs: How to write a
> .bmp file containing the
> > glyphs. That problem was the reason for pursuing FreeType and
> OpenGL. I see the
> > characters displayed in the pane. They are drawn correctly. Where
> are the glyphs?
> >
> >   - Dan
> 
> When you open that image, you see a browser open on a method called
> #export. Some text is already selected. Before the selected text it
> says 
> "Set FreeType preferences" and "Create a folder named AAFonts". The
> selected text does "FreeTypeFontProvider current updateFromSystem."
> . 
> This loads your Windows / MacOS fonts into the image. Then follows a
> lists of fonts. Those fonts must be available to the system. The
> rest of 
> the selected code does the export, saving the bmp and txt files. To
> export Inconsolata, or any other font, first load it into your
> Windows 
> or MacOS system, then add it to the list, then export.
> 
> I thought all this was self-explanatory...
> 
> Cheers,
> Juan Vuletich

If a font name is not in the system, the image crashes. Only a reboot recovers.

It is not possible to create a new file in the AAFonts directory. It is possible in the current 
directory however.

I'm going to restore my system to before Visual Studio et al. There is too much wierdness.

 - Dan





From pbpublist at gmail.com  Mon Aug  3 22:20:03 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 03 Aug 2015 23:20:03 -0400
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com> <55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org> <1438629582.12996.4.camel@gmail.com>
	<CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>
Message-ID: <1438658403.12996.35.camel@gmail.com>

On Mon, 2015-08-03 at 22:35 +0200, Peter van Rooijen wrote:
> Hi,
> 
> 
> 1. I'm totally against introducing pragma's (perhaps they already
> exist in Cuis, I don't know).
> 

Too late, they're already there (VM functionality)

> 
> First of all because they are not Smalltalk, and second because they
> are not needed.
> 
> 
> What would be wrong with simply introducing a convention and adding a
> method cuisPublicSelectors to a class?
> 
> 
> To avoid seeing them on the instance side, there could also be
> cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class
> side.
> 
> 
> At the top these would be defined as self allSelectors.
> 
> 
> If someone wanted to view only the public selectors in a browser, they
> would check the checkbox for that and the browser would hide the
> non-public selectors.
> 
> 
> Or the browser could show a nice public interface report added to the
> class comment.
> 
> 
> 2. On another point: interfaces such as indexable could simply be
> described by creating a class CuisInterfaceSpecification which gets a
> subclass for each interface specified. The methods belonging to the
> interface are defined and get a comment explaining the semantics of
> the method. This makes it easy for tools to check which interfaces are
> (probably) implemented by a class. If desired, each method could be
> additionally defined to return a MethodSpecification object that knows
> about preconditions, invariants, return values, argument and return
> types/interfaces...but then it becomes progressively more complicated.
> 
> 
> But anyway, in this way whoever thinks it's important enough, can add
> the info (for public selectors of a class or for whole interface
> specifications) without anyone who is not interested in that needing
> to know or care about that.
> 

This is too complicated for what I think we're trying to achieve...

> 
> In my mind that gels well with Cuis' philosophy of simplicity. But I
> could be missing the whole point...
> 

The intent (what I was going for at least) is to provide a means for
Juan and anyone else modifying the core image / packages to have a
bidirectional communications channel with anyone looking to have a
stable set of APIs that they can depend on.  It needs to be something
that's simple and easy for both Juan and us to use, or it won't get
used.  I think that Juan's pragma approach accomplishes this.  All it
signals is that 'this method will keep working as it currently does
until/unless it is formally decided to change it'.

So here's an example of how this might work:
1) Let's say we propose that #asString as a public API and Juan agrees
that this is a useful method and should be fairly stable.
Implementations of #asString get marked with a publicAPI (or whatever
name makes sense) pragma 
2) Those of us who care can then work to ensure that our code is using
these publicAPI methods when possible.  This will also help drive out
some of our own bad behavior where we were calling things that we really
shouldn't have been.
3) Time passes and life is good :-)
4) Down the line (Cuis 5.x, 6.x... whatever) Juan decides that #asString
needs to change (who knows... unicode support... or maybe he just
decides that #asString is the wrong way to do it)  Seeing that #asString
is flagged publicAPI, he knows not to 'just do it' but rather make sure
that the change gets called out in the release notes (after some mailing
list discussion if he deems it worthwhile to do so... his call) and that
since it will likely break code to probably wait for a major release.

This also allows for deprecating things that are designated as
publicAPI... just because something is public does not mean it always
will be, just that the changes to things that are need to be
communicated more richly.  For me, the documentation aspect of it is a
nice to have secondary objective that falls out of it... getting to a
stable core is the primary objective.  (i.e. we're not documenting for
the sake of documenting)

> 
> Cheers, Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <pbpublist at gmail.com>
> wrote:
>         On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
>         > Hi Doug,
>         >
>         > On 8/2/2015 4:04 AM, Douglas Brebner wrote:
>         > > On 19/07/2015 22:38, Phil (list) wrote:
>         > >> 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 vaguely recall that many years ago there was a project
>         called
>         > > SmallInterfaces that let you define public interfaces to
>         objects. (Or
>         > > something like that). Would that be a good way to document
>         the
>         > > public/private api using code?
>         > >
>         > > (sorry for being so vague but I've been awake for 24+
>         hours now)
>         >
>         > Thanks for the pointer. I took a look at it. It is quite
>         like Java
>         > interfaces. The tools are interesting. But I see several
>         downsides:
>         >
>         > - Each interface is a class. Each method in the protocol is
>         an actual
>         > method. If we use this to document all public protocols in
>         Cuis, it
>         > would mean a lot of new classes and methods.
>         > - The source code of (for example) OrderedCollection>>at:
>         would not
>         > include the information of it belonging to interface
>         "Indexable".
>         > Without additional support from tools users can't tell
>         whether a message
>         > is public protocol or not. And the base image / package
>         maintainer can't
>         > easily see he's about to change a public api.
>         >
>         > I think a method pragma, that includes the name of the
>         protocol avoids
>         > these issues and is a better choice.
>         >
>         
>         
>         I agree.  Let's keep it as simple as possible and see how far
>         that gets
>         us.
>         
>         > 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





From dnorton at mindspring.com  Tue Aug  4 13:35:19 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 14:35:19 -0400
Subject: [Cuis] Fixed-Width Font
Message-ID: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>

On 3 Aug 2015 at 22:52, Dan Norton wrote:

> On 3 Aug 2015 at 21:51, Juan Vuletich wrote:
> 
> > On 03/08/2015 09:08 p.m., Dan Norton wrote:
> > > On 3 Aug 2015 at 15:59, Juan Vuletich wrote:
> > >
> > >> On 8/3/2015 1:54 PM, Dan Norton wrote:
> > >>> On 29 Jul 2015 at 11:54, Juan Vuletich wrote:
> > >>>
> > >>>> 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.
> > >>>>
> > >>> I'm trying to get FreeType built and also I did a clone of:
> > >>>
> > >>> https://github.com/rougier/freetype-gl
> > >>>
> > >>> Unfortunately when I compile embedded-font.c the following
> > >> occurs:
> > >>> fatal error C1083: Cannot open include file: 'vera-16.h': No
> > such
> > >> file or directory
> > >>> Do any of you Cexperts know where I can get 'vera-16.h'?
> > Google
> > >> search produces ads for
> > >>> soaps containing aloe vera :-)
> > >>>
> > >>>    - Dan
> > >> Hi Dan,
> > >>
> > >> I can not help you with the build of FreeType , but could you
> > try
> > >> the
> > >> image I used to build the fonts? You shouldn't need to build
> > >> anything to
> > >> run it. The FreeType VM plugin is included for both Windows
> and
> > Mac.
> > >> I'd
> > >> appreciate any feedback.
> > >>
> > > OK, the package works as far as choosing fonts from a list.
> How
> > the list is derived is not
> > > clear. Inconsolata is not on it. The chosen font can be used
> in
> > ListMorphs. The thing which
> > > eludes me here is the same in the other environs: How to write
> a
> > .bmp file containing the
> > > glyphs. That problem was the reason for pursuing FreeType and
> > OpenGL. I see the
> > > characters displayed in the pane. They are drawn correctly.
> Where
> > are the glyphs?
> > >
> > >   - Dan
> > 
> > When you open that image, you see a browser open on a method
> called
> > #export. Some text is already selected. Before the selected text
> it
> > says 
> > "Set FreeType preferences" and "Create a folder named AAFonts".
> The
> > selected text does "FreeTypeFontProvider current
> updateFromSystem."
> > . 
> > This loads your Windows / MacOS fonts into the image. Then follows
> a
> > lists of fonts. Those fonts must be available to the system. The
> > rest of 
> > the selected code does the export, saving the bmp and txt files.
> To
> > export Inconsolata, or any other font, first load it into your
> > Windows 
> > or MacOS system, then add it to the list, then export.
> > 
> > I thought all this was self-explanatory...
> > 
> > Cheers,
> > Juan Vuletich
> 
> If a font name is not in the system, the image crashes. Only a
> reboot recovers.
> 
> It is not possible to create a new file in the AAFonts directory. It
> is possible in the current 
> directory however.
> 
> I'm going to restore my system to before Visual Studio et al. There
> is too much wierdness.
>
Hi Juan,

After the restore and after extracting again the two zip files from your dropbox there remain 
fundamental problems. In FreeTypeFont>>export the following statement results in nothing 
written to AAFonts directory:

n := 'AAFonts', FileDirectory slash, face familyName, '-', emph asString , '-', pointSize 
printString.

If changed to spell out the complete path as follows, some of the .bmp and .txt files are 
written to AAFonts before other problems arise:

n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName, '-', emph asString , '-', 
pointSize printString.

 - Dan



From juan at jvuletich.org  Tue Aug  4 14:09:18 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 16:09:18 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>
Message-ID: <55C10DDE.3090700@jvuletich.org>

On 8/4/2015 3:35 PM, Dan Norton wrote:
> On 3 Aug 2015 at 22:52, Dan Norton wrote:
> ...
>> If a font name is not in the system, the image crashes. Only a
>> reboot recovers.
>>
>> It is not possible to create a new file in the AAFonts directory. It
>> is possible in the current
>> directory however.
>>
>> I'm going to restore my system to before Visual Studio et al. There
>> is too much wierdness.
>>
> Hi Juan,
>
> After the restore and after extracting again the two zip files from your dropbox there remain
> fundamental problems. In FreeTypeFont>>export the following statement results in nothing
> written to AAFonts directory:
>
> n := 'AAFonts', FileDirectory slash, face familyName, '-', emph asString , '-', pointSize
> printString.
>
> If changed to spell out the complete path as follows, some of the .bmp and .txt files are
> written to AAFonts before other problems arise:
>
> n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName, '-', emph asString , '-',
> pointSize printString.
>
>   - Dan

Hi Dan,

I tried again. On a Windows 7 system, I stored the contents of both zips 
in a folder, started the image and exported 'Calibri' without any problems.

In any case, this is not part of Cuis. It wasn't even meant for 
distribution, just for my own use when I built the Bitmap Vera Sans 
fonts in Cuis/Squeak/Pharo. I only published it at your personal 
request, and not in the Cuis repo. It is given without support or 
warranties. If you want to use it, try understanding what is going on. 
After all, it is just Smalltalk. If you do that, and ask specific 
questions, I'll answer.

Juan Vuletich



From dnorton at mindspring.com  Tue Aug  4 14:42:39 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 15:42:39 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C10DDE.3090700@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C10DDE.3090700@jvuletich.org>
Message-ID: <55C115AF.28292.158941B@dnorton.mindspring.com>

On 4 Aug 2015 at 16:09, Juan Vuletich wrote:

> On 8/4/2015 3:35 PM, Dan Norton wrote:
> > On 3 Aug 2015 at 22:52, Dan Norton wrote:
> > ...
> >> If a font name is not in the system, the image crashes. Only a
> >> reboot recovers.
> >>
> >> It is not possible to create a new file in the AAFonts directory.
> It
> >> is possible in the current
> >> directory however.
> >>
> >> I'm going to restore my system to before Visual Studio et al.
> There
> >> is too much wierdness.
> >>
> > Hi Juan,
> >
> > After the restore and after extracting again the two zip files
> from your dropbox there remain
> > fundamental problems. In FreeTypeFont>>export the following
> statement results in nothing
> > written to AAFonts directory:
> >
> > n := 'AAFonts', FileDirectory slash, face familyName, '-', emph
> asString , '-', pointSize
> > printString.
> >
> > If changed to spell out the complete path as follows, some of the
> .bmp and .txt files are
> > written to AAFonts before other problems arise:
> >
> > n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName,
> '-', emph asString , '-',
> > pointSize printString.
> >
> >   - Dan
> 
> Hi Dan,
> 
> I tried again. On a Windows 7 system, I stored the contents of both
> zips 
> in a folder, started the image and exported 'Calibri' without any
> problems.
> 

On my Windows 7 I tried to export 'Calibri' and got MNU: receiver of "nextPutAll:" is nil.
This is the same problem which led to my work-around above. Don't waste any more time on 
this. It may be something clobbered a .dll and has nothing to do with Squeak. I will continue 
to work on it because I need a fixed-width font. Not having it has me stalled on a project.

> In any case, this is not part of Cuis. It wasn't even meant for 
> distribution, just for my own use when I built the Bitmap Vera Sans
> fonts in Cuis/Squeak/Pharo. I only published it at your personal 
> request, and not in the Cuis repo. It is given without support or 
> warranties. If you want to use it, try understanding what is going
> on. 
> After all, it is just Smalltalk. If you do that, and ask specific 
> questions, I'll answer.
> 
> Juan Vuletich





From juan at jvuletich.org  Tue Aug  4 15:08:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 17:08:01 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C115AF.28292.158941B@dnorton.mindspring.com>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C10DDE.3090700@jvuletich.org>
	<55C115AF.28292.158941B@dnorton.mindspring.com>
Message-ID: <55C11BA1.6000406@jvuletich.org>

On 8/4/2015 4:42 PM, Dan Norton wrote:
> On 4 Aug 2015 at 16:09, Juan Vuletich wrote:
>
>> On 8/4/2015 3:35 PM, Dan Norton wrote:
>>> On 3 Aug 2015 at 22:52, Dan Norton wrote:
>>> ...
>>>> If a font name is not in the system, the image crashes. Only a
>>>> reboot recovers.
>>>>
>>>> It is not possible to create a new file in the AAFonts directory.
>> It
>>>> is possible in the current
>>>> directory however.
>>>>
>>>> I'm going to restore my system to before Visual Studio et al.
>> There
>>>> is too much wierdness.
>>>>
>>> Hi Juan,
>>>
>>> After the restore and after extracting again the two zip files
>> from your dropbox there remain
>>> fundamental problems. In FreeTypeFont>>export the following
>> statement results in nothing
>>> written to AAFonts directory:
>>>
>>> n := 'AAFonts', FileDirectory slash, face familyName, '-', emph
>> asString , '-', pointSize
>>> printString.
>>>
>>> If changed to spell out the complete path as follows, some of the
>> .bmp and .txt files are
>>> written to AAFonts before other problems arise:
>>>
>>> n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face familyName,
>> '-', emph asString , '-',
>>> pointSize printString.
>>>
>>>    - Dan
>> Hi Dan,
>>
>> I tried again. On a Windows 7 system, I stored the contents of both
>> zips
>> in a folder, started the image and exported 'Calibri' without any
>> problems.
>>
> On my Windows 7 I tried to export 'Calibri' and got MNU: receiver of "nextPutAll:" is nil.
> This is the same problem which led to my work-around above. Don't waste any more time on
> this. It may be something clobbered a .dll and has nothing to do with Squeak. I will continue
> to work on it because I need a fixed-width font. Not having it has me stalled on a project.
>

Then I suggest the following: Save the contents of those zips to a thumb 
drive. Borrow a Windows machine, from someone that doesn't do weird 
stuff with dlls and VisualStudio ;-) . Run from the thumb drive, and 
take it home.

Oh, something else. On the Mac, the procedure generated txt files with 
integer numbers. On Windows there are Floats. Most likely that is wrong...

Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono or 
Inconsolata myself...

>> In any case, this is not part of Cuis. It wasn't even meant for
>> distribution, just for my own use when I built the Bitmap Vera Sans
>> fonts in Cuis/Squeak/Pharo. I only published it at your personal
>> request, and not in the Cuis repo. It is given without support or
>> warranties. If you want to use it, try understanding what is going
>> on.
>> After all, it is just Smalltalk. If you do that, and ask specific
>> questions, I'll answer.
>>
>> Juan Vuletich
>

Cheers,
Juan Vuletich



From dnorton at mindspring.com  Tue Aug  4 17:10:49 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 18:10:49 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C11BA1.6000406@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C115AF.28292.158941B@dnorton.mindspring.com>,
	<55C11BA1.6000406@jvuletich.org>
Message-ID: <55C13869.19799.1E03D95@dnorton.mindspring.com>

(In line...)

On 4 Aug 2015 at 17:08, Juan Vuletich wrote:

> On 8/4/2015 4:42 PM, Dan Norton wrote:
> > On 4 Aug 2015 at 16:09, Juan Vuletich wrote:
> >
> >> On 8/4/2015 3:35 PM, Dan Norton wrote:
> >>> On 3 Aug 2015 at 22:52, Dan Norton wrote:
> >>> ...
> >>>> If a font name is not in the system, the image crashes. Only
> a
> >>>> reboot recovers.
> >>>>
> >>>> It is not possible to create a new file in the AAFonts
> directory.
> >> It
> >>>> is possible in the current
> >>>> directory however.
> >>>>
> >>>> I'm going to restore my system to before Visual Studio et al.
> >> There
> >>>> is too much wierdness.
> >>>>
> >>> Hi Juan,
> >>>
> >>> After the restore and after extracting again the two zip files
> >> from your dropbox there remain
> >>> fundamental problems. In FreeTypeFont>>export the following
> >> statement results in nothing
> >>> written to AAFonts directory:
> >>>
> >>> n := 'AAFonts', FileDirectory slash, face familyName, '-',
> emph
> >> asString , '-', pointSize
> >>> printString.
> >>>
> >>> If changed to spell out the complete path as follows, some of
> the
> >> .bmp and .txt files are
> >>> written to AAFonts before other problems arise:
> >>>
> >>> n :=  '\cuis\pharo\Squeak4.10.2-2612\AAFonts\', face
> familyName,
> >> '-', emph asString , '-',
> >>> pointSize printString.
> >>>
> >>>    - Dan
> >> Hi Dan,
> >>
> >> I tried again. On a Windows 7 system, I stored the contents of
> both
> >> zips
> >> in a folder, started the image and exported 'Calibri' without
> any
> >> problems.
> >>
> > On my Windows 7 I tried to export 'Calibri' and got MNU: receiver
> of "nextPutAll:" is nil.
> > This is the same problem which led to my work-around above. Don't
> waste any more time on
> > this. It may be something clobbered a .dll and has nothing to do
> with Squeak. I will continue
> > to work on it because I need a fixed-width font. Not having it has
> me stalled on a project.
> >
> 
> Then I suggest the following: Save the contents of those zips to a
> thumb 
> drive. Borrow a Windows machine, from someone that doesn't do weird
> stuff with dlls and VisualStudio ;-) . Run from the thumb drive, and
> take it home.
> 

Did that on my wife's laptop and got the same result. Trust me, she does not have Visual 
Studio or anything else more rad than FireFox :-)


> Oh, something else. On the Mac, the procedure generated txt files
> with 
> integer numbers. On Windows there are Floats. Most likely that is
> wrong...
> 
> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono or
> Inconsolata myself...
> 

That would sure be great. When I started this journey many moons ago, Inconsolata was my 
idea of a great font to have on Cuis.

> >> In any case, this is not part of Cuis. It wasn't even meant for
> >> distribution, just for my own use when I built the Bitmap Vera
> Sans
> >> fonts in Cuis/Squeak/Pharo. I only published it at your
> personal
> >> request, and not in the Cuis repo. It is given without support
> or
> >> warranties. If you want to use it, try understanding what is
> going
> >> on.
> >> After all, it is just Smalltalk. If you do that, and ask
> specific
> >> questions, I'll answer.
> >>
> >> Juan Vuletich
> >
> 
> Cheers,
> Juan Vuletich





From dnorton at mindspring.com  Tue Aug  4 20:22:35 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 04 Aug 2015 21:22:35 -0400
Subject: [Cuis] VM Crash
In-Reply-To: <55BFB991.1070807@jvuletich.org>
References: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>,
	<55BFB991.1070807@jvuletich.org>
Message-ID: <55C1655B.25215.20DAE4@dnorton.mindspring.com>

On 3 Aug 2015 at 15:57, Juan Vuletich wrote:

> 
> On 8/2/2015 10:24 PM, Dan Norton wrote:
>     Load Cuis4.2-2439.image. Open File List and go to Packages.
>     Select Graphics-Files-Additional.pck.st and click on "Install
> Package".
> 
>     Get "Fatal VM Error". The zipped crash.dmp is attached.
> 
>     ?- Dan
> 
> 
> I can not reproduce it. Can you reproduce it consistently? Can you
> reproduce it consistently with a 
> fresh image and VM on a local hard drive? If so, please provide more
> details so I can reproduce it.
> 
> It seems to be a stack overflow. If you can reproduce it, you can
> try again, and after Install 
> Package do alt+. (User Interrupt) and try to find out why there is
> an unbounded recursion.
> 

The problem occurs with cogwin-15.28.3410. It is consistent and will not yield to alt+. .

The problem does not occur with cogwin-15.27.3397.

These runs were done on Windows 7.

 - Dan



From juan at jvuletich.org  Tue Aug  4 21:47:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 23:47:49 -0300
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C13869.19799.1E03D95@dnorton.mindspring.com>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C115AF.28292.158941B@dnorton.mindspring.com>,
	<55C11BA1.6000406@jvuletich.org>
	<55C13869.19799.1E03D95@dnorton.mindspring.com>
Message-ID: <55C17955.7050807@jvuletich.org>

On 8/4/2015 7:10 PM, Dan Norton wrote:
>
>> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono or
>> Inconsolata myself...
>>
> That would sure be great. When I started this journey many moons ago, Inconsolata was my
> idea of a great font to have on Cuis.

Ok. Set up the AAFonts folder with contents. File in both cs'. Evaluate 
[StrikeFont install: 'DejaVu Sans Mono']. I hope it works for you.

I didn't include Inconsolata because it doesn't have italics or bold, 
and also because DejaVuSansMono looks quite better with Freetype.

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DejaVuSansMono.zip
Type: application/zip
Size: 1070498 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150804/d3d63655/attachment-0004.zip>

From juan at jvuletich.org  Tue Aug  4 21:57:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Tue, 04 Aug 2015 23:57:43 -0300
Subject: [Cuis] VM Crash
In-Reply-To: <55C1655B.25215.20DAE4@dnorton.mindspring.com>
References: <55BEC2D8.5596.24B5452@dnorton.mindspring.com>,
	<55BFB991.1070807@jvuletich.org>
	<55C1655B.25215.20DAE4@dnorton.mindspring.com>
Message-ID: <55C17BA7.6080008@jvuletich.org>

On 8/4/2015 10:22 PM, Dan Norton wrote:
> On 3 Aug 2015 at 15:57, Juan Vuletich wrote:
>
>> On 8/2/2015 10:24 PM, Dan Norton wrote:
>>      Load Cuis4.2-2439.image. Open File List and go to Packages.
>>      Select Graphics-Files-Additional.pck.st and click on "Install
>> Package".
>>
>>      Get "Fatal VM Error". The zipped crash.dmp is attached.
>>
>>       - Dan
>>
>>
>> I can not reproduce it. Can you reproduce it consistently? Can you
>> reproduce it consistently with a
>> fresh image and VM on a local hard drive? If so, please provide more
>> details so I can reproduce it.
>>
>> It seems to be a stack overflow. If you can reproduce it, you can
>> try again, and after Install
>> Package do alt+. (User Interrupt) and try to find out why there is
>> an unbounded recursion.
>>
> The problem occurs with cogwin-15.28.3410. It is consistent and will not yield to alt+. .
>
> The problem does not occur with cogwin-15.27.3397.
>
> These runs were done on Windows 7.
>
>   - Dan

Yes. Same here. Use 
http://www.mirandabanda.org/files/Cog/VM/VM.r3370/cogwin-15.22.3370.zip 
. About a week ago I reported another problem with later releases of Cog 
to VM-Dev. Still, without luck.

Juan Vuletich



From edgardec2005 at gmail.com  Wed Aug  5 04:04:44 2015
From: edgardec2005 at gmail.com (Edgar J. De Cleene)
Date: Wed, 05 Aug 2015 06:04:44 -0300
Subject: [Cuis] Wish Feedback
Message-ID: <D1E757FC.15B3C%edgardec2005@gmail.com>

In the twitter links exploration of today I found

https://github.com/aserg-ufmg/JSCity This maybe could be in future
?Divagaciones?
To people who don?t know , ?Divagaciones? is my perpetual personal learning
tool and could be viewed trough www.squeakros.org

user: visita
pass: (do not type any here)

 
And from here

http://www.inf.usi.ch/phd/wettel/codecity.html

See in what is programmed and tell

Coud pay the work for porting CodeCity
 to Squeak/Cuis ?


Edgar
@morplenauta 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150805/4f55649c/attachment-0004.html>

From peter at aba-instituut.nl  Wed Aug  5 10:50:12 2015
From: peter at aba-instituut.nl (Peter van Rooijen)
Date: Wed, 5 Aug 2015 17:50:12 +0200
Subject: [Cuis] Fwd: Re: DIRECT version number
In-Reply-To: <1438658403.12996.35.camel@gmail.com>
References: <55A905A3.1060100@jvuletich.org>
	<1437158701.2255.245.camel@gmail.com>
	<55ABB223.8010309@jvuletich.org>
	<1437341905.6934.99.camel@gmail.com>
	<55BDC0ED.3060401@fang.demon.co.uk>
	<55BFB7D3.4030701@jvuletich.org>
	<1438629582.12996.4.camel@gmail.com>
	<CAJBxtBZtR28S2O=K15yRLuWstZxTt7nKaA7tQjww7KQP69GKBA@mail.gmail.com>
	<1438658403.12996.35.camel@gmail.com>
Message-ID: <CAJBxtBbAFcAkw7m4kV_U=QeUTNoXYSQxnsE-kT2pv-JT0jWCbg@mail.gmail.com>

Thanks Phil for the explanation.

Cheers, Peter

On Tue, Aug 4, 2015 at 5:20 AM, Phil (list) <pbpublist at gmail.com> wrote:

> On Mon, 2015-08-03 at 22:35 +0200, Peter van Rooijen wrote:
> > Hi,
> >
> >
> > 1. I'm totally against introducing pragma's (perhaps they already
> > exist in Cuis, I don't know).
> >
>
> Too late, they're already there (VM functionality)
>
> >
> > First of all because they are not Smalltalk, and second because they
> > are not needed.
> >
> >
> > What would be wrong with simply introducing a convention and adding a
> > method cuisPublicSelectors to a class?
> >
> >
> > To avoid seeing them on the instance side, there could also be
> > cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class
> > side.
> >
> >
> > At the top these would be defined as self allSelectors.
> >
> >
> > If someone wanted to view only the public selectors in a browser, they
> > would check the checkbox for that and the browser would hide the
> > non-public selectors.
> >
> >
> > Or the browser could show a nice public interface report added to the
> > class comment.
> >
> >
> > 2. On another point: interfaces such as indexable could simply be
> > described by creating a class CuisInterfaceSpecification which gets a
> > subclass for each interface specified. The methods belonging to the
> > interface are defined and get a comment explaining the semantics of
> > the method. This makes it easy for tools to check which interfaces are
> > (probably) implemented by a class. If desired, each method could be
> > additionally defined to return a MethodSpecification object that knows
> > about preconditions, invariants, return values, argument and return
> > types/interfaces...but then it becomes progressively more complicated.
> >
> >
> > But anyway, in this way whoever thinks it's important enough, can add
> > the info (for public selectors of a class or for whole interface
> > specifications) without anyone who is not interested in that needing
> > to know or care about that.
> >
>
> This is too complicated for what I think we're trying to achieve...
>
> >
> > In my mind that gels well with Cuis' philosophy of simplicity. But I
> > could be missing the whole point...
> >
>
> The intent (what I was going for at least) is to provide a means for
> Juan and anyone else modifying the core image / packages to have a
> bidirectional communications channel with anyone looking to have a
> stable set of APIs that they can depend on.  It needs to be something
> that's simple and easy for both Juan and us to use, or it won't get
> used.  I think that Juan's pragma approach accomplishes this.  All it
> signals is that 'this method will keep working as it currently does
> until/unless it is formally decided to change it'.
>
> So here's an example of how this might work:
> 1) Let's say we propose that #asString as a public API and Juan agrees
> that this is a useful method and should be fairly stable.
> Implementations of #asString get marked with a publicAPI (or whatever
> name makes sense) pragma
> 2) Those of us who care can then work to ensure that our code is using
> these publicAPI methods when possible.  This will also help drive out
> some of our own bad behavior where we were calling things that we really
> shouldn't have been.
> 3) Time passes and life is good :-)
> 4) Down the line (Cuis 5.x, 6.x... whatever) Juan decides that #asString
> needs to change (who knows... unicode support... or maybe he just
> decides that #asString is the wrong way to do it)  Seeing that #asString
> is flagged publicAPI, he knows not to 'just do it' but rather make sure
> that the change gets called out in the release notes (after some mailing
> list discussion if he deems it worthwhile to do so... his call) and that
> since it will likely break code to probably wait for a major release.
>
> This also allows for deprecating things that are designated as
> publicAPI... just because something is public does not mean it always
> will be, just that the changes to things that are need to be
> communicated more richly.  For me, the documentation aspect of it is a
> nice to have secondary objective that falls out of it... getting to a
> stable core is the primary objective.  (i.e. we're not documenting for
> the sake of documenting)
>
> >
> > Cheers, Peter
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <pbpublist at gmail.com>
> > wrote:
> >         On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
> >         > Hi Doug,
> >         >
> >         > On 8/2/2015 4:04 AM, Douglas Brebner wrote:
> >         > > On 19/07/2015 22:38, Phil (list) wrote:
> >         > >> 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 vaguely recall that many years ago there was a project
> >         called
> >         > > SmallInterfaces that let you define public interfaces to
> >         objects. (Or
> >         > > something like that). Would that be a good way to document
> >         the
> >         > > public/private api using code?
> >         > >
> >         > > (sorry for being so vague but I've been awake for 24+
> >         hours now)
> >         >
> >         > Thanks for the pointer. I took a look at it. It is quite
> >         like Java
> >         > interfaces. The tools are interesting. But I see several
> >         downsides:
> >         >
> >         > - Each interface is a class. Each method in the protocol is
> >         an actual
> >         > method. If we use this to document all public protocols in
> >         Cuis, it
> >         > would mean a lot of new classes and methods.
> >         > - The source code of (for example) OrderedCollection>>at:
> >         would not
> >         > include the information of it belonging to interface
> >         "Indexable".
> >         > Without additional support from tools users can't tell
> >         whether a message
> >         > is public protocol or not. And the base image / package
> >         maintainer can't
> >         > easily see he's about to change a public api.
> >         >
> >         > I think a method pragma, that includes the name of the
> >         protocol avoids
> >         > these issues and is a better choice.
> >         >
> >
> >
> >         I agree.  Let's keep it as simple as possible and see how far
> >         that gets
> >         us.
> >
> >         > 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
>
>
>
> _______________________________________________
> 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/20150805/81e6c93d/attachment-0004.html>

From dnorton at mindspring.com  Wed Aug  5 16:03:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 05 Aug 2015 17:03:56 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C17955.7050807@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C13869.19799.1E03D95@dnorton.mindspring.com>,
	<55C17955.7050807@jvuletich.org>
Message-ID: <55C27A3C.10878.1AAF223@dnorton.mindspring.com>

On 4 Aug 2015 at 23:47, Juan Vuletich wrote:

> On 8/4/2015 7:10 PM, Dan Norton wrote:
> >
> >> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono
> or
> >> Inconsolata myself...
> >>
> > That would sure be great. When I started this journey many moons
> ago, Inconsolata was my
> > idea of a great font to have on Cuis.
> 
> Ok. Set up the AAFonts folder with contents. File in both cs'.
> Evaluate 
> [StrikeFont install: 'DejaVu Sans Mono']. I hope it works for you.
> 
> I didn't include Inconsolata because it doesn't have italics or
> bold, 
> and also because DejaVuSansMono looks quite better with Freetype.
>

Installs great, included in the alt+k menu of a TextEditor, looks great. Thanks, Juan.

Now I'll look into making list elements use DejaVuSansMono.

 - Dan



From dnorton at mindspring.com  Wed Aug  5 18:21:04 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 05 Aug 2015 19:21:04 -0400
Subject: [Cuis] Fixed-Width Font
In-Reply-To: <55C17955.7050807@jvuletich.org>
References: <55C105E7.8689.11AEFEF@dnorton.mindspring.com>,
	<55C13869.19799.1E03D95@dnorton.mindspring.com>,
	<55C17955.7050807@jvuletich.org>
Message-ID: <55C29A60.17211.22880DD@dnorton.mindspring.com>

On 4 Aug 2015 at 23:47, Juan Vuletich wrote:

> On 8/4/2015 7:10 PM, Dan Norton wrote:
> >
> >> Mhhh. Maybe tonight I'll try to export Bitstream Vera Sans Mono
> or
> >> Inconsolata myself...
> >>
> > That would sure be great. When I started this journey many moons
> ago, Inconsolata was my
> > idea of a great font to have on Cuis.
> 
> Ok. Set up the AAFonts folder with contents. File in both cs'.
> Evaluate 
> [StrikeFont install: 'DejaVu Sans Mono']. I hope it works for you.
> 
> I didn't include Inconsolata because it doesn't have italics or
> bold, 
> and also because DejaVuSansMono looks quite better with Freetype.
> 

Hi Juan,

This is very nice. It's a pleasure to use this fixed-width font.  Your changesets and the zip are 
on:

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

in case anyone wants the font before the next Cuis update :)
The Readme explains how to install it, including how to make a PluggableListMorph use it. 
Please excuse the other clutter in the repo.

 - Dan



From dnorton at mindspring.com  Tue Aug 11 20:53:45 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Tue, 11 Aug 2015 21:53:45 -0400
Subject: [Cuis] MNU: String>>skipTo:
Message-ID: <55CAA729.16634.269613E@dnorton.mindspring.com>

Some problems trying to the use Symbol class #readFrom: method:

	In the comment "Symbol readFromString: '#abc'", #readFromString: is unknown

	changing it to #readFrom: gets MNU: String>>skipTo:

The method #skipTo: is in PositionableStream but String is not in that hierarchy. However, 
this works:

	Object readFrom: (ReadStream on: '#abc')

In Squeak, "Symbol readFromString: '#abc'" answers #abc.

 - Dan



From Ken.Dickey at whidbey.com  Tue Aug 11 21:13:11 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Tue, 11 Aug 2015 19:13:11 -0700
Subject: [Cuis] Solitaire Update
Message-ID: <20150811191311.9978a35a320fbf1b1c1d6932@whidbey.com>

I noted that the Hand no longer gives dropShadows to morphs it picks up.

Not a big deal, but I missed this in Solitaire, so I gave the cards back their shadows.

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

FYI,
-KenD



From pbpublist at gmail.com  Wed Aug 12 16:36:10 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 12 Aug 2015 17:36:10 -0400
Subject: [Cuis] Curious drawing performance issue
Message-ID: <1439415370.2388.20.camel@gmail.com>

I noticed a while back that something appeared to be going on with Cuis
drawing performance (at idle on my system Morphic consumes ~20% of VM
CPU *miniumum* according to ProcessBrowser) and this seems to give an
indication of what it's currently costing in drawing performance...

After seeing the Squeak 5.0 announcement, I was curious to see roughly
how much of a speed boost we might be able to expect from Spur down the
road.  So I decided to look at BouncingAtomsMorph to try to get a rough
apples-to-apples comparison and was quite surprised: Spur was faster,
but it was too much faster.  So I dropped back to Squeak 4.5 and it also
performs much, much better than the Cuis version on the same VM.   Here
are the numbers I'm seeing using BouncingAtomsMorph with roughly
comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
Cuis 2440 (Cog VM 15.25.3390): 6-8 fps

Granted BouncingAtomsMorph is not 100% identical from a source code
standpoint but it's not nearly different enough where I'd expect that
sort of difference.  Is this a platform-specific issue (I'm on Linux) or
are others noticing drawing issues as well?




From pbpublist at gmail.com  Wed Aug 12 16:44:42 2015
From: pbpublist at gmail.com (Phil (list))
Date: Wed, 12 Aug 2015 17:44:42 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439415370.2388.20.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>
Message-ID: <1439415882.2388.22.camel@gmail.com>

I should also mention that the Morph window is ~ 500x450 and #stepTime
is set to 0 for anyone who wants to try to replicate...

On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> I noticed a while back that something appeared to be going on with Cuis
> drawing performance (at idle on my system Morphic consumes ~20% of VM
> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> indication of what it's currently costing in drawing performance...
> 
> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> how much of a speed boost we might be able to expect from Spur down the
> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> apples-to-apples comparison and was quite surprised: Spur was faster,
> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> performs much, much better than the Cuis version on the same VM.   Here
> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> 
> Granted BouncingAtomsMorph is not 100% identical from a source code
> standpoint but it's not nearly different enough where I'd expect that
> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> are others noticing drawing issues as well?





From dnorton at mindspring.com  Wed Aug 12 21:17:16 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Wed, 12 Aug 2015 22:17:16 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439415882.2388.22.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<1439415882.2388.22.camel@gmail.com>
Message-ID: <55CBFE2C.3950.28469D6@dnorton.mindspring.com>

Hi Phil,

On Windows 7 with Cuis loaded and idle, Windows Task Manager > Performance reports 0% 
CPU Usage. Memory Usage is 1.28 GB.

With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000 the report is 24 - 
25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.

Cuis 4.2 2449, cogwin 15.22.3370

 - Dan

On 12 Aug 2015 at 17:44, Phil (list) wrote:

> I should also mention that the Morph window is ~ 500x450 and
> #stepTime
> is set to 0 for anyone who wants to try to replicate...
> 
> On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > I noticed a while back that something appeared to be going on with
> Cuis
> > drawing performance (at idle on my system Morphic consumes ~20% of
> VM
> > CPU *miniumum* according to ProcessBrowser) and this seems to give
> an
> > indication of what it's currently costing in drawing
> performance...
> > 
> > After seeing the Squeak 5.0 announcement, I was curious to see
> roughly
> > how much of a speed boost we might be able to expect from Spur
> down the
> > road.  So I decided to look at BouncingAtomsMorph to try to get a
> rough
> > apples-to-apples comparison and was quite surprised: Spur was
> faster,
> > but it was too much faster.  So I dropped back to Squeak 4.5 and
> it also
> > performs much, much better than the Cuis version on the same VM.  
> Here
> > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > comparable (i.e. eyeballed) morph sizes and atom count set to
> 5000:
> > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > 
> > Granted BouncingAtomsMorph is not 100% identical from a source
> code
> > standpoint but it's not nearly different enough where I'd expect
> that
> > sort of difference.  Is this a platform-specific issue (I'm on
> Linux) or
> > are others noticing drawing issues as well?
> 
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From pbpublist at gmail.com  Thu Aug 13 01:29:40 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 13 Aug 2015 02:29:40 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CBFE2C.3950.28469D6@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>
	, <1439415882.2388.22.camel@gmail.com>
	<55CBFE2C.3950.28469D6@dnorton.mindspring.com>
Message-ID: <1439447380.2388.26.camel@gmail.com>

Dan,


On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> Hi Phil,
> 
> On Windows 7 with Cuis loaded and idle, Windows Task Manager > Performance reports 0% 
> CPU Usage. Memory Usage is 1.28 GB.
> 

What does the cpu usage show via World Menu -> Open... -> Process
Browser for Morphic?

> With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000 the report is 24 - 
> 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> 

OK, so it's not platform specific poor performance.  If you close the
BouncingAtomsMorph and wait for things to settle for a few seconds, what
does Process Browser show the Morphic cpu usage as??

> Cuis 4.2 2449, cogwin 15.22.3370
> 
>  - Dan
> 

Thanks,
Phil

> On 12 Aug 2015 at 17:44, Phil (list) wrote:
> 
> > I should also mention that the Morph window is ~ 500x450 and
> > #stepTime
> > is set to 0 for anyone who wants to try to replicate...
> > 
> > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > I noticed a while back that something appeared to be going on with
> > Cuis
> > > drawing performance (at idle on my system Morphic consumes ~20% of
> > VM
> > > CPU *miniumum* according to ProcessBrowser) and this seems to give
> > an
> > > indication of what it's currently costing in drawing
> > performance...
> > > 
> > > After seeing the Squeak 5.0 announcement, I was curious to see
> > roughly
> > > how much of a speed boost we might be able to expect from Spur
> > down the
> > > road.  So I decided to look at BouncingAtomsMorph to try to get a
> > rough
> > > apples-to-apples comparison and was quite surprised: Spur was
> > faster,
> > > but it was too much faster.  So I dropped back to Squeak 4.5 and
> > it also
> > > performs much, much better than the Cuis version on the same VM.  
> > Here
> > > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > > comparable (i.e. eyeballed) morph sizes and atom count set to
> > 5000:
> > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > 
> > > Granted BouncingAtomsMorph is not 100% identical from a source
> > code
> > > standpoint but it's not nearly different enough where I'd expect
> > that
> > > sort of difference.  Is this a platform-specific issue (I'm on
> > Linux) or
> > > are others noticing drawing issues as well?
> > 
> > 
> > 
> > _______________________________________________
> > 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  Thu Aug 13 10:11:36 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Thu, 13 Aug 2015 11:11:36 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439447380.2388.26.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CBFE2C.3950.28469D6@dnorton.mindspring.com>,
	<1439447380.2388.26.camel@gmail.com>
Message-ID: <55CCB3A8.12664.2E45B7@dnorton.mindspring.com>

On 13 Aug 2015 at 2:29, Phil (list) wrote:

> Dan,
> 
> 
> On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > Hi Phil,
> > 
> > On Windows 7 with Cuis loaded and idle, Windows Task Manager >
> Performance reports 0% 
> > CPU Usage. Memory Usage is 1.28 GB.
> > 
> 
> What does the cpu usage show via World Menu -> Open... -> Process
> Browser for Morphic?
> 

It shows 12%.

> > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000
> the report is 24 - 
> > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > 
> 
> OK, so it's not platform specific poor performance.  If you close
> the
> BouncingAtomsMorph and wait for things to settle for a few seconds,
> what
> does Process Browser show the Morphic cpu usage as??
>

It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to measure absolute as 
opposed to relative CPU usage seems inaccurate to me. The /difference/ in Process Browser 
numbers while atoms is running vs not running agree with Win7: 1 - 2%.

I don't like for something to try to measure its own performance :-) - an independent 
instrument is preferable IMHO.
 
> > Cuis 4.2 2449, cogwin 15.22.3370
> > 
> >  - Dan
> > 
> 
> Thanks,
> Phil
> 
> > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > 
> > > I should also mention that the Morph window is ~ 500x450 and
> > > #stepTime
> > > is set to 0 for anyone who wants to try to replicate...
> > > 
> > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > I noticed a while back that something appeared to be going on
> with
> > > Cuis
> > > > drawing performance (at idle on my system Morphic consumes
> ~20% of
> > > VM
> > > > CPU *miniumum* according to ProcessBrowser) and this seems to
> give
> > > an
> > > > indication of what it's currently costing in drawing
> > > performance...
> > > > 
> > > > After seeing the Squeak 5.0 announcement, I was curious to
> see
> > > roughly
> > > > how much of a speed boost we might be able to expect from
> Spur
> > > down the
> > > > road.  So I decided to look at BouncingAtomsMorph to try to
> get a
> > > rough
> > > > apples-to-apples comparison and was quite surprised: Spur
> was
> > > faster,
> > > > but it was too much faster.  So I dropped back to Squeak 4.5
> and
> > > it also
> > > > performs much, much better than the Cuis version on the same
> VM.  
> > > Here
> > > > are the numbers I'm seeing using BouncingAtomsMorph with
> roughly
> > > > comparable (i.e. eyeballed) morph sizes and atom count set
> to
> > > 5000:
> > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > 
> > > > Granted BouncingAtomsMorph is not 100% identical from a
> source
> > > code
> > > > standpoint but it's not nearly different enough where I'd
> expect
> > > that
> > > > sort of difference.  Is this a platform-specific issue (I'm
> on
> > > Linux) or
> > > > are others noticing drawing issues as well?
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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 sean at clipperadams.com  Thu Aug 13 11:00:28 2015
From: sean at clipperadams.com (Sean P. DeNigris)
Date: Thu, 13 Aug 2015 09:00:28 -0700 (PDT)
Subject: [Cuis] Wish Feedback
In-Reply-To: <D1E757FC.15B3C%edgardec2005@gmail.com>
References: <D1E757FC.15B3C%edgardec2005@gmail.com>
Message-ID: <1439481628951-4842594.post@n4.nabble.com>

Edgar De Cleene wrote
> www.squeakros.org

I visited, but wasn't sure what to do there. I tried to sign up, which hung
indefinitely. Then clicked the Help link, which seemed to do nothing.



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Wish-Feedback-tp4841005p4842594.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From eliot.miranda at gmail.com  Thu Aug 13 13:11:09 2015
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Thu, 13 Aug 2015 11:11:09 -0700
Subject: [Cuis] Suggestion for a performance analysis project,
	suitable for a masters student
Message-ID: <CAC20JE2Pac5-SpYjRA+k_PwB8POZbaAdVJXxG8rNtuWh2OMvHQ@mail.gmail.com>

Hi All,

    I had occasion to compare VW (vw7.7nc) and Spur recently and was
pleasantly surprised to see that Spur is on average -40% faster than VW on
a large subset of the benchmarks from the shootout (I didn't include three
because of Regex syntax issues).  Now Spur gets some of its speed from
having direct pointers vs VisualWorks' object header/table indirection, but
it could get other speedups from various other differences.  It would be
great to know exactly how much speedup comes from what, and indeed how much
cost Sour pays for its lazy become:.  I'd like to propose a project to
exactly determine the costs of an explicit read barrier and of lazy
forwarding compared to no check at all.

Spur, part of VMMaker.oscog, is implemented by a hierarchy of classes that
implement a 32-bit and a 64-bit memory manager.  Spur is a sibling to the
old ObjectMemory class that implements the V3 object representation.  The
current Spur does "lazy forwarding" where two objects are become by cloning
each object, making the old versions point to the opposite copy, and
relying on send-time checks to lazily follow forwarding pointers when sends
to forwarded objects fail a message lookup.

The project would create two additional variations on Spur, both of which
dispense with the lazy check.  One would explicitly test for a forwarding
pointers on every access, and one would never check, not need send-time
checking either and would reimplement become: like the old ObjectMemory, by
scanning the entire heap to exchange all references.

These variations could be implemented as subclasses or siblings of Spur.
The project isn't trivial because it also means making changes to the JIT,
albeit within its framework for multiple object representations.  Because
this is probably some months' work I can't do it myself but I'm extremely
interested in the results and I think it would make a really good paper,
e.g. for ISMM, or one of the dynamic language workshops.

If what I've said makes any sense at all to any academics out there who are
looking for a challenging but nicely contained and far from open ended
Masters project then please get in touch and we can see if we can take this
any further.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150813/3cb17141/attachment-0004.html>

From pbpublist at gmail.com  Thu Aug 13 15:01:17 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu, 13 Aug 2015 16:01:17 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CCB3A8.12664.2E45B7@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>
	, <55CBFE2C.3950.28469D6@dnorton.mindspring.com>
	, <1439447380.2388.26.camel@gmail.com>
	<55CCB3A8.12664.2E45B7@dnorton.mindspring.com>
Message-ID: <1439496077.2388.46.camel@gmail.com>

On Thu, 2015-08-13 at 11:11 -0400, Dan Norton wrote:
> On 13 Aug 2015 at 2:29, Phil (list) wrote:
> 
> > Dan,
> > 
> > 
> > On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > > Hi Phil,
> > > 
> > > On Windows 7 with Cuis loaded and idle, Windows Task Manager >
> > Performance reports 0% 
> > > CPU Usage. Memory Usage is 1.28 GB.
> > > 
> > 
> > What does the cpu usage show via World Menu -> Open... -> Process
> > Browser for Morphic?
> > 
> 
> It shows 12%.
> 
> > > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms 5000
> > the report is 24 - 
> > > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > > 
> > 
> > OK, so it's not platform specific poor performance.  If you close
> > the
> > BouncingAtomsMorph and wait for things to settle for a few seconds,
> > what
> > does Process Browser show the Morphic cpu usage as??
> >
> 
> It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to measure absolute as 
> opposed to relative CPU usage seems inaccurate to me. The /difference/ in Process Browser 
> numbers while atoms is running vs not running agree with Win7: 1 - 2%.
> 
> I don't like for something to try to measure its own performance :-) - an independent 
> instrument is preferable IMHO.

True, the external monitoring tools will tend to give you a better
absolute picture as there may be some VM overhead (esp if plugins are
involved) that Process Browser can't see.  However, CPU utilization as
reported by the OS isn't terribly helpful unless you know how many cores
the system has, was anything else active at the time, etc.
ProcessBrowser, while limited, avoids all that since it shows what was
used vs what was available to it. (usually 100/<num cores> % of total
system CPU)  Just seemed to make for a better apples to apples
comparison in this case to see if you are having the same issue re:
Morphic chewing up cycles while otherwise 'idle'.

>  
> > > Cuis 4.2 2449, cogwin 15.22.3370
> > > 
> > >  - Dan
> > > 
> > 
> > Thanks,
> > Phil
> > 
> > > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > > 
> > > > I should also mention that the Morph window is ~ 500x450 and
> > > > #stepTime
> > > > is set to 0 for anyone who wants to try to replicate...
> > > > 
> > > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > > I noticed a while back that something appeared to be going on
> > with
> > > > Cuis
> > > > > drawing performance (at idle on my system Morphic consumes
> > ~20% of
> > > > VM
> > > > > CPU *miniumum* according to ProcessBrowser) and this seems to
> > give
> > > > an
> > > > > indication of what it's currently costing in drawing
> > > > performance...
> > > > > 
> > > > > After seeing the Squeak 5.0 announcement, I was curious to
> > see
> > > > roughly
> > > > > how much of a speed boost we might be able to expect from
> > Spur
> > > > down the
> > > > > road.  So I decided to look at BouncingAtomsMorph to try to
> > get a
> > > > rough
> > > > > apples-to-apples comparison and was quite surprised: Spur
> > was
> > > > faster,
> > > > > but it was too much faster.  So I dropped back to Squeak 4.5
> > and
> > > > it also
> > > > > performs much, much better than the Cuis version on the same
> > VM.  
> > > > Here
> > > > > are the numbers I'm seeing using BouncingAtomsMorph with
> > roughly
> > > > > comparable (i.e. eyeballed) morph sizes and atom count set
> > to
> > > > 5000:
> > > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > > 
> > > > > Granted BouncingAtomsMorph is not 100% identical from a
> > source
> > > > code
> > > > > standpoint but it's not nearly different enough where I'd
> > expect
> > > > that
> > > > > sort of difference.  Is this a platform-specific issue (I'm
> > on
> > > > Linux) or
> > > > > are others noticing drawing issues as well?
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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 dnorton at mindspring.com  Fri Aug 14 11:42:57 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Fri, 14 Aug 2015 12:42:57 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439496077.2388.46.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CCB3A8.12664.2E45B7@dnorton.mindspring.com>,
	<1439496077.2388.46.camel@gmail.com>
Message-ID: <55CE1A91.6602.5A1F06@dnorton.mindspring.com>

On 13 Aug 2015 at 16:01, Phil (list) wrote:

> On Thu, 2015-08-13 at 11:11 -0400, Dan Norton wrote:
> > On 13 Aug 2015 at 2:29, Phil (list) wrote:
> > 
> > > Dan,
> > > 
> > > 
> > > On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > > > Hi Phil,
> > > > 
> > > > On Windows 7 with Cuis loaded and idle, Windows Task Manager
> >
> > > Performance reports 0% 
> > > > CPU Usage. Memory Usage is 1.28 GB.
> > > > 
> > > 
> > > What does the cpu usage show via World Menu -> Open... ->
> Process
> > > Browser for Morphic?
> > > 
> > 
> > It shows 12%.
> > 
> > > > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms
> 5000
> > > the report is 24 - 
> > > > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > > > 
> > > 
> > > OK, so it's not platform specific poor performance.  If you
> close
> > > the
> > > BouncingAtomsMorph and wait for things to settle for a few
> seconds,
> > > what
> > > does Process Browser show the Morphic cpu usage as??
> > >
> > 
> > It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to
> measure absolute as 
> > opposed to relative CPU usage seems inaccurate to me. The
> /difference/ in Process Browser 
> > numbers while atoms is running vs not running agree with Win7: 1 -
> 2%.
> > 
> > I don't like for something to try to measure its own performance
> :-) - an independent 
> > instrument is preferable IMHO.
> 
> True, the external monitoring tools will tend to give you a better
> absolute picture as there may be some VM overhead (esp if plugins
> are
> involved) that Process Browser can't see.  However, CPU utilization
> as
> reported by the OS isn't terribly helpful unless you know how many
> cores
> the system has, was anything else active at the time, etc.
> ProcessBrowser, while limited, avoids all that since it shows what
> was
> used vs what was available to it. (usually 100/<num cores> % of
> total
> system CPU)  Just seemed to make for a better apples to apples
> comparison in this case to see if you are having the same issue
> re:
> Morphic chewing up cycles while otherwise 'idle'.
> 

Rummaging around in my system reveals:

Microsoft Windows 7 Home Premium
6.1.7601 Service Pack 1

Intel(R) Core(TM) i3-2125 CPU @
3.30 GHz

All Programs>Accessories>System Tools>Resource Monitor shows:

an appalling (to me, at least) >170 threads "if the only tool you have is a hammer, every 
problem looks like a nail" sitting there quietly for the most part. Resource Monitor shows four 
"CPUs" with CPU 1 and CPU 3 parked. Total CPU usage < 1%.

When Cuis is started, the Squeak.exe starts out with 17 threads, then eventually settles to 6 
threads. Total CPU usage < 1%.

When BouncingAtoms is running, set up as above, CPU 1 and CPU 3 remain parked, CPU 0 
< 5%, and CPU 2 > 95%. Occasionally something (GC?) cranks CPU 0 to 85 - 90% briefly.

When BouncingAtoms is stopped, all return to CPU 0 < 5%, CPU 2 <1%, CPU 1 and CPU 3 
parked.

So, the question is why should Cuis process browser report that Morphic UI is consuming 10 
- 14% ?

> >  
> > > > Cuis 4.2 2449, cogwin 15.22.3370
> > > > 
> > > >  - Dan
> > > > 
> > > 
> > > Thanks,
> > > Phil
> > > 
> > > > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > > > 
> > > > > I should also mention that the Morph window is ~ 500x450
> and
> > > > > #stepTime
> > > > > is set to 0 for anyone who wants to try to replicate...
> > > > > 
> > > > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > > > I noticed a while back that something appeared to be going
> on
> > > with
> > > > > Cuis
> > > > > > drawing performance (at idle on my system Morphic
> consumes
> > > ~20% of
> > > > > VM
> > > > > > CPU *miniumum* according to ProcessBrowser) and this seems
> to
> > > give
> > > > > an
> > > > > > indication of what it's currently costing in drawing
> > > > > performance...
> > > > > > 
> > > > > > After seeing the Squeak 5.0 announcement, I was curious
> to
> > > see
> > > > > roughly
> > > > > > how much of a speed boost we might be able to expect
> from
> > > Spur
> > > > > down the
> > > > > > road.  So I decided to look at BouncingAtomsMorph to try
> to
> > > get a
> > > > > rough
> > > > > > apples-to-apples comparison and was quite surprised:
> Spur
> > > was
> > > > > faster,
> > > > > > but it was too much faster.  So I dropped back to Squeak
> 4.5
> > > and
> > > > > it also
> > > > > > performs much, much better than the Cuis version on the
> same
> > > VM.  
> > > > > Here
> > > > > > are the numbers I'm seeing using BouncingAtomsMorph with
> > > roughly
> > > > > > comparable (i.e. eyeballed) morph sizes and atom count
> set
> > > to
> > > > > 5000:
> > > > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > > > 
> > > > > > Granted BouncingAtomsMorph is not 100% identical from a
> > > source
> > > > > code
> > > > > > standpoint but it's not nearly different enough where
> I'd
> > > expect
> > > > > that
> > > > > > sort of difference.  Is this a platform-specific issue
> (I'm
> > > on
> > > > > Linux) or
> > > > > > are others noticing drawing issues as well?
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > 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 pbpublist at gmail.com  Fri Aug 14 13:50:52 2015
From: pbpublist at gmail.com (Phil (list))
Date: Fri, 14 Aug 2015 14:50:52 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CE1A91.6602.5A1F06@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>
	, <55CCB3A8.12664.2E45B7@dnorton.mindspring.com>
	, <1439496077.2388.46.camel@gmail.com>
	<55CE1A91.6602.5A1F06@dnorton.mindspring.com>
Message-ID: <1439578252.2318.8.camel@gmail.com>

On Fri, 2015-08-14 at 12:42 -0400, Dan Norton wrote:
> On 13 Aug 2015 at 16:01, Phil (list) wrote:
> 
> > On Thu, 2015-08-13 at 11:11 -0400, Dan Norton wrote:
> > > On 13 Aug 2015 at 2:29, Phil (list) wrote:
> > > 
> > > > Dan,
> > > > 
> > > > 
> > > > On Wed, 2015-08-12 at 22:17 -0400, Dan Norton wrote:
> > > > > Hi Phil,
> > > > > 
> > > > > On Windows 7 with Cuis loaded and idle, Windows Task Manager
> > >
> > > > Performance reports 0% 
> > > > > CPU Usage. Memory Usage is 1.28 GB.
> > > > > 
> > > > 
> > > > What does the cpu usage show via World Menu -> Open... ->
> > Process
> > > > Browser for Morphic?
> > > > 
> > > 
> > > It shows 12%.
> > > 
> > > > > With BouncingAtoms morphExtent: 500 at 450, stepTime 0, nAtoms
> > 5000
> > > > the report is 24 - 
> > > > > 25% CPU Usage, 1.28 GB Memory Usage, 2 - 6 fps.
> > > > > 
> > > > 
> > > > OK, so it's not platform specific poor performance.  If you
> > close
> > > > the
> > > > BouncingAtomsMorph and wait for things to settle for a few
> > seconds,
> > > > what
> > > > does Process Browser show the Morphic cpu usage as??
> > > >
> > > 
> > > It shows 40%. However, Win7 shows 1 - 2%. Using Process Browser to
> > measure absolute as 
> > > opposed to relative CPU usage seems inaccurate to me. The
> > /difference/ in Process Browser 
> > > numbers while atoms is running vs not running agree with Win7: 1 -
> > 2%.
> > > 
> > > I don't like for something to try to measure its own performance
> > :-) - an independent 
> > > instrument is preferable IMHO.
> > 
> > True, the external monitoring tools will tend to give you a better
> > absolute picture as there may be some VM overhead (esp if plugins
> > are
> > involved) that Process Browser can't see.  However, CPU utilization
> > as
> > reported by the OS isn't terribly helpful unless you know how many
> > cores
> > the system has, was anything else active at the time, etc.
> > ProcessBrowser, while limited, avoids all that since it shows what
> > was
> > used vs what was available to it. (usually 100/<num cores> % of
> > total
> > system CPU)  Just seemed to make for a better apples to apples
> > comparison in this case to see if you are having the same issue
> > re:
> > Morphic chewing up cycles while otherwise 'idle'.
> > 
> 
> Rummaging around in my system reveals:
> 
> Microsoft Windows 7 Home Premium
> 6.1.7601 Service Pack 1
> 
> Intel(R) Core(TM) i3-2125 CPU @
> 3.30 GHz
> 
> All Programs>Accessories>System Tools>Resource Monitor shows:
> 
> an appalling (to me, at least) >170 threads "if the only tool you have is a hammer, every 
> problem looks like a nail" sitting there quietly for the most part. Resource Monitor shows four 
> "CPUs" with CPU 1 and CPU 3 parked. Total CPU usage < 1%.
> 

So you've got a dual core processor with hyperthreading (4 logical
cores)...

> When Cuis is started, the Squeak.exe starts out with 17 threads, then eventually settles to 6 
> threads. Total CPU usage < 1%.
> 
> When BouncingAtoms is running, set up as above, CPU 1 and CPU 3 remain parked, CPU 0 
> < 5%, and CPU 2 > 95%. Occasionally something (GC?) cranks CPU 0 to 85 - 90% briefly.
> 
> When BouncingAtoms is stopped, all return to CPU 0 < 5%, CPU 2 <1%, CPU 1 and CPU 3 
> parked.
> 

Given your above processor info, divide the 10-14% (the idle usage
reported by Cuis) by 4 to get what you should roughly be seeing in
overall system CPU utilization (i.e. 2.5-3.5%, assuming not much else is
going on on the system)  Since the Squeak VM is single threaded for
Smalltalk code the most you should ever see when Cuis is fully busy is
~25% CPU utilization (i.e. 100% of a single core)

> So, the question is why should Cuis process browser report that Morphic UI is consuming 10 
> - 14% ?
> 

That is the question and it relates to why BouncingAtomsMorph is
performing so poorly in Cuis vs. Squeak.  Something is going on (even
when Cuis is 'idle')...

> > >  
> > > > > Cuis 4.2 2449, cogwin 15.22.3370
> > > > > 
> > > > >  - Dan
> > > > > 
> > > > 
> > > > Thanks,
> > > > Phil
> > > > 
> > > > > On 12 Aug 2015 at 17:44, Phil (list) wrote:
> > > > > 
> > > > > > I should also mention that the Morph window is ~ 500x450
> > and
> > > > > > #stepTime
> > > > > > is set to 0 for anyone who wants to try to replicate...
> > > > > > 
> > > > > > On Wed, 2015-08-12 at 17:36 -0400, Phil (list) wrote:
> > > > > > > I noticed a while back that something appeared to be going
> > on
> > > > with
> > > > > > Cuis
> > > > > > > drawing performance (at idle on my system Morphic
> > consumes
> > > > ~20% of
> > > > > > VM
> > > > > > > CPU *miniumum* according to ProcessBrowser) and this seems
> > to
> > > > give
> > > > > > an
> > > > > > > indication of what it's currently costing in drawing
> > > > > > performance...
> > > > > > > 
> > > > > > > After seeing the Squeak 5.0 announcement, I was curious
> > to
> > > > see
> > > > > > roughly
> > > > > > > how much of a speed boost we might be able to expect
> > from
> > > > Spur
> > > > > > down the
> > > > > > > road.  So I decided to look at BouncingAtomsMorph to try
> > to
> > > > get a
> > > > > > rough
> > > > > > > apples-to-apples comparison and was quite surprised:
> > Spur
> > > > was
> > > > > > faster,
> > > > > > > but it was too much faster.  So I dropped back to Squeak
> > 4.5
> > > > and
> > > > > > it also
> > > > > > > performs much, much better than the Cuis version on the
> > same
> > > > VM.  
> > > > > > Here
> > > > > > > are the numbers I'm seeing using BouncingAtomsMorph with
> > > > roughly
> > > > > > > comparable (i.e. eyeballed) morph sizes and atom count
> > set
> > > > to
> > > > > > 5000:
> > > > > > > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > > > > > > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > > > > > > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > > > > > > 
> > > > > > > Granted BouncingAtomsMorph is not 100% identical from a
> > > > source
> > > > > > code
> > > > > > > standpoint but it's not nearly different enough where
> > I'd
> > > > expect
> > > > > > that
> > > > > > > sort of difference.  Is this a platform-specific issue
> > (I'm
> > > > on
> > > > > > Linux) or
> > > > > > > are others noticing drawing issues as well?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > 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
> 
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From juan at jvuletich.org  Sat Aug 15 08:24:01 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 10:24:01 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439415370.2388.20.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>
Message-ID: <55CF3D71.6040204@jvuletich.org>

Hi Phil,

I won't spoil your fun, so instead of explaining the difference between 
Squeak and Cuis here, I give you a suggestion: Use the profiler.

Cheers,
Juan Vuletich

On 8/12/2015 6:36 PM, Phil (list) wrote:
> I noticed a while back that something appeared to be going on with Cuis
> drawing performance (at idle on my system Morphic consumes ~20% of VM
> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> indication of what it's currently costing in drawing performance...
>
> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> how much of a speed boost we might be able to expect from Spur down the
> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> apples-to-apples comparison and was quite surprised: Spur was faster,
> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> performs much, much better than the Cuis version on the same VM.   Here
> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
>
> Granted BouncingAtomsMorph is not 100% identical from a source code
> standpoint but it's not nearly different enough where I'd expect that
> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> are others noticing drawing issues as well?
>




From juan at jvuletich.org  Sat Aug 15 08:27:34 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 10:27:34 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CE1A91.6602.5A1F06@dnorton.mindspring.com>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CCB3A8.12664.2E45B7@dnorton.mindspring.com>,
	<1439496077.2388.46.camel@gmail.com>
	<55CE1A91.6602.5A1F06@dnorton.mindspring.com>
Message-ID: <55CF3E46.6020306@jvuletich.org>

The sum of percentages in the Cuis process browser is always 100%. What 
it is measured is how the time spent by the interpreter is split amongst 
Smalltalk processes.

Cheers,
Juan Vuletich

On 8/14/2015 1:42 PM, Dan Norton wrote:
> ...
> When BouncingAtoms is stopped, all return to CPU 0<  5%, CPU 2<1%, CPU 1 and CPU 3
> parked.
>
> So, the question is why should Cuis process browser report that Morphic UI is consuming 10
> - 14% ?




From dnorton at mindspring.com  Sat Aug 15 09:41:34 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sat, 15 Aug 2015 10:41:34 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CF3E46.6020306@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>,
	<55CE1A91.6602.5A1F06@dnorton.mindspring.com>,
	<55CF3E46.6020306@jvuletich.org>
Message-ID: <55CF4F9E.23944.E8610@dnorton.mindspring.com>

Ahh of course. Stared at it but didn't see it :-)

Thanks,
 - Dan

On 15 Aug 2015 at 10:27, Juan Vuletich wrote:

> The sum of percentages in the Cuis process browser is always 100%.
> What 
> it is measured is how the time spent by the interpreter is split
> amongst 
> Smalltalk processes.
> 
> Cheers,
> Juan Vuletich
> 
> On 8/14/2015 1:42 PM, Dan Norton wrote:
> > ...
> > When BouncingAtoms is stopped, all return to CPU 0<  5%, CPU 2<1%,
> CPU 1 and CPU 3
> > parked.
> >
> > So, the question is why should Cuis process browser report that
> Morphic UI is consuming 10
> > - 14% ?
> 





From pbpublist at gmail.com  Sat Aug 15 14:40:34 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 15:40:34 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CF3D71.6040204@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org>
Message-ID: <1439667634.2323.3.camel@gmail.com>

On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> I won't spoil your fun, so instead of explaining the difference between 
> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> 

I will do that right... hey, where did the profiler option go in
ProcessBrowser?  Well, ok, I'll just do it manually with
#spyOnProcess:... grr!  I see it was taken out in 2409.  Now you're just
having fun with me...

> Cheers,
> Juan Vuletich
> 
> On 8/12/2015 6:36 PM, Phil (list) wrote:
> > I noticed a while back that something appeared to be going on with Cuis
> > drawing performance (at idle on my system Morphic consumes ~20% of VM
> > CPU *miniumum* according to ProcessBrowser) and this seems to give an
> > indication of what it's currently costing in drawing performance...
> >
> > After seeing the Squeak 5.0 announcement, I was curious to see roughly
> > how much of a speed boost we might be able to expect from Spur down the
> > road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> > apples-to-apples comparison and was quite surprised: Spur was faster,
> > but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> > performs much, much better than the Cuis version on the same VM.   Here
> > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> >
> > Granted BouncingAtomsMorph is not 100% identical from a source code
> > standpoint but it's not nearly different enough where I'd expect that
> > sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> > are others noticing drawing issues as well?
> >
> 





From juan at jvuletich.org  Sat Aug 15 15:56:36 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 17:56:36 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439667634.2323.3.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>	
	<55CF3D71.6040204@jvuletich.org>
	<1439667634.2323.3.camel@gmail.com>
Message-ID: <55CFA784.7070704@jvuletich.org>

On 8/15/2015 4:40 PM, Phil (list) wrote:
> On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
>> Hi Phil,
>>
>> I won't spoil your fun, so instead of explaining the difference between
>> Squeak and Cuis here, I give you a suggestion: Use the profiler.
>>
> I will do that right... hey, where did the profiler option go in
> ProcessBrowser?  Well, ok, I'll just do it manually with
> #spyOnProcess:... grr!  I see it was taken out in 2409.  Now you're just
> having fun with me...
>

Swear not. Use any of the class methods in the profiler: 
AndreasSystemProfiler. For example, something like

     AndreasSystemProfiler spyForMilliseconds: 200

Cheers,
Juan Vuletich



From pbpublist at gmail.com  Sat Aug 15 15:58:24 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 16:58:24 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CF3D71.6040204@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org>
Message-ID: <1439672304.4789.9.camel@gmail.com>

On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> I won't spoil your fun, so instead of explaining the difference between 
> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> 

Given your comment it sounds like it's by design...

OK, so I reverted to an older build to get back the process-based
profiler and I can see that Cuis is doing a lot more drawing (work) than
Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
tooling to tell me what that work actually is.  What I think I see going
on is that Squeak is using the old region-based damage system while Cuis
appears to just be bit-blitting the entire frame each time? (I'll hold
off jumping up and down for joy until I get confirmation... if that's
what's going on, that is FANTASTIC!)

> Cheers,
> Juan Vuletich
> 
> On 8/12/2015 6:36 PM, Phil (list) wrote:
> > I noticed a while back that something appeared to be going on with Cuis
> > drawing performance (at idle on my system Morphic consumes ~20% of VM
> > CPU *miniumum* according to ProcessBrowser) and this seems to give an
> > indication of what it's currently costing in drawing performance...
> >
> > After seeing the Squeak 5.0 announcement, I was curious to see roughly
> > how much of a speed boost we might be able to expect from Spur down the
> > road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> > apples-to-apples comparison and was quite surprised: Spur was faster,
> > but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> > performs much, much better than the Cuis version on the same VM.   Here
> > are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> > Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> >
> > Granted BouncingAtomsMorph is not 100% identical from a source code
> > standpoint but it's not nearly different enough where I'd expect that
> > sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> > are others noticing drawing issues as well?
> >
> 





From pbpublist at gmail.com  Sat Aug 15 16:07:44 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 17:07:44 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CFA784.7070704@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org> <1439667634.2323.3.camel@gmail.com>
	<55CFA784.7070704@jvuletich.org>
Message-ID: <1439672864.4789.10.camel@gmail.com>

On Sat, 2015-08-15 at 17:56 -0300, Juan Vuletich wrote:
> On 8/15/2015 4:40 PM, Phil (list) wrote:
> > On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> >> Hi Phil,
> >>
> >> I won't spoil your fun, so instead of explaining the difference between
> >> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> >>
> > I will do that right... hey, where did the profiler option go in
> > ProcessBrowser?  Well, ok, I'll just do it manually with
> > #spyOnProcess:... grr!  I see it was taken out in 2409.  Now you're just
> > having fun with me...
> >
> 
> Swear not. Use any of the class methods in the profiler: 
> AndreasSystemProfiler. For example, something like
> 
>      AndreasSystemProfiler spyForMilliseconds: 200
> 

segfault (stack overflow)...

> Cheers,
> Juan Vuletich





From juan at jvuletich.org  Sat Aug 15 16:39:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 18:39:53 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439672864.4789.10.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>	
	<55CF3D71.6040204@jvuletich.org>
	<1439667634.2323.3.camel@gmail.com>	
	<55CFA784.7070704@jvuletich.org>
	<1439672864.4789.10.camel@gmail.com>
Message-ID: <55CFB1A9.7050402@jvuletich.org>

On 8/15/2015 6:07 PM, Phil (list) wrote:
>
>> Swear not. Use any of the class methods in the profiler:
>> AndreasSystemProfiler. For example, something like
>>
>>       AndreasSystemProfiler spyForMilliseconds: 200
>>
> segfault (stack overflow)...
>

Use Cog 3370 or older. I reported the problem in VM-Dev, but nobody 
listened.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Sat Aug 15 16:41:59 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sat, 15 Aug 2015 18:41:59 -0300
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439672304.4789.9.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>	
	<55CF3D71.6040204@jvuletich.org>
	<1439672304.4789.9.camel@gmail.com>
Message-ID: <55CFB227.9000806@jvuletich.org>

On 8/15/2015 5:58 PM, Phil (list) wrote:
> On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
>> Hi Phil,
>>
>> I won't spoil your fun, so instead of explaining the difference between
>> Squeak and Cuis here, I give you a suggestion: Use the profiler.
>>
> Given your comment it sounds like it's by design...
>
> OK, so I reverted to an older build to get back the process-based
> profiler and I can see that Cuis is doing a lot more drawing (work) than
> Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
> tooling to tell me what that work actually is.  What I think I see going
> on is that Squeak is using the old region-based damage system while Cuis
> appears to just be bit-blitting the entire frame each time? (I'll hold
> off jumping up and down for joy until I get confirmation... if that's
> what's going on, that is FANTASTIC!)
>

C'mon! Isn't it obvious in the profiler tree that the problem is using 
local coordinates and transforming them on each draw?

It is possible to optimize it back. It just requires some work.

Cheers,
Juan Vuletich

>> Cheers,
>> Juan Vuletich
>>
>> On 8/12/2015 6:36 PM, Phil (list) wrote:
>>> I noticed a while back that something appeared to be going on with Cuis
>>> drawing performance (at idle on my system Morphic consumes ~20% of VM
>>> CPU *miniumum* according to ProcessBrowser) and this seems to give an
>>> indication of what it's currently costing in drawing performance...
>>>
>>> After seeing the Squeak 5.0 announcement, I was curious to see roughly
>>> how much of a speed boost we might be able to expect from Spur down the
>>> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
>>> apples-to-apples comparison and was quite surprised: Spur was faster,
>>> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
>>> performs much, much better than the Cuis version on the same VM.   Here
>>> are the numbers I'm seeing using BouncingAtomsMorph with roughly
>>> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
>>> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
>>> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
>>> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
>>>
>>> Granted BouncingAtomsMorph is not 100% identical from a source code
>>> standpoint but it's not nearly different enough where I'd expect that
>>> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
>>> are others noticing drawing issues as well?
>>>
>
>




From pbpublist at gmail.com  Sat Aug 15 21:55:43 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sat, 15 Aug 2015 22:55:43 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <55CFB227.9000806@jvuletich.org>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org> <1439672304.4789.9.camel@gmail.com>
	<55CFB227.9000806@jvuletich.org>
Message-ID: <1439693743.2401.15.camel@gmail.com>

On Sat, 2015-08-15 at 18:41 -0300, Juan Vuletich wrote:
> On 8/15/2015 5:58 PM, Phil (list) wrote:
> > On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> >> Hi Phil,
> >>
> >> I won't spoil your fun, so instead of explaining the difference between
> >> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> >>
> > Given your comment it sounds like it's by design...
> >
> > OK, so I reverted to an older build to get back the process-based
> > profiler and I can see that Cuis is doing a lot more drawing (work) than
> > Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
> > tooling to tell me what that work actually is.  What I think I see going
> > on is that Squeak is using the old region-based damage system while Cuis
> > appears to just be bit-blitting the entire frame each time? (I'll hold
> > off jumping up and down for joy until I get confirmation... if that's
> > what's going on, that is FANTASTIC!)
> >
> 
> C'mon! Isn't it obvious in the profiler tree that the problem is using 
> local coordinates and transforming them on each draw?
> 

In the old profiler output (I went back to 2404 to get it), it didn't
jump out at me (the bounds related calls only appear to be <10% of the
time)  It could just be that I'm more dense than usual :-)

I can definitely see how that could cause a problem doing 1000s of local
to global conversions per frame...

> It is possible to optimize it back. It just requires some work.
> 

Fair enough... but I still think that things are generally off
performance-wise with Morphic... (it might just be that we've got a
bunch of fairly unoptimized code similar to what's going on with
BouncingAtomsMorph that will take some time to work through, but things
are definitely feeling slow-ish from a UI standpoint)

> Cheers,
> Juan Vuletich
> 
> >> Cheers,
> >> Juan Vuletich
> >>
> >> On 8/12/2015 6:36 PM, Phil (list) wrote:
> >>> I noticed a while back that something appeared to be going on with Cuis
> >>> drawing performance (at idle on my system Morphic consumes ~20% of VM
> >>> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> >>> indication of what it's currently costing in drawing performance...
> >>>
> >>> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> >>> how much of a speed boost we might be able to expect from Spur down the
> >>> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> >>> apples-to-apples comparison and was quite surprised: Spur was faster,
> >>> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> >>> performs much, much better than the Cuis version on the same VM.   Here
> >>> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> >>> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> >>> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> >>> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> >>> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> >>>
> >>> Granted BouncingAtomsMorph is not 100% identical from a source code
> >>> standpoint but it's not nearly different enough where I'd expect that
> >>> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> >>> are others noticing drawing issues as well?
> >>>
> >
> >
> 





From pbpublist at gmail.com  Sun Aug 16 03:11:10 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 04:11:10 -0400
Subject: [Cuis] Curious drawing performance issue
In-Reply-To: <1439693743.2401.15.camel@gmail.com>
References: <1439415370.2388.20.camel@gmail.com>
	<55CF3D71.6040204@jvuletich.org> <1439672304.4789.9.camel@gmail.com>
	<55CFB227.9000806@jvuletich.org> <1439693743.2401.15.camel@gmail.com>
Message-ID: <1439712670.2401.23.camel@gmail.com>

On Sat, 2015-08-15 at 22:55 -0400, Phil (list) wrote:
> On Sat, 2015-08-15 at 18:41 -0300, Juan Vuletich wrote:
> > On 8/15/2015 5:58 PM, Phil (list) wrote:
> > > On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> > >> Hi Phil,
> > >>
> > >> I won't spoil your fun, so instead of explaining the difference between
> > >> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> > >>
> > > Given your comment it sounds like it's by design...
> > >
> > > OK, so I reverted to an older build to get back the process-based
> > > profiler and I can see that Cuis is doing a lot more drawing (work) than
> > > Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
> > > tooling to tell me what that work actually is.  What I think I see going
> > > on is that Squeak is using the old region-based damage system while Cuis
> > > appears to just be bit-blitting the entire frame each time? (I'll hold
> > > off jumping up and down for joy until I get confirmation... if that's
> > > what's going on, that is FANTASTIC!)
> > >
> > 
> > C'mon! Isn't it obvious in the profiler tree that the problem is using 
> > local coordinates and transforming them on each draw?
> > 
> 
> In the old profiler output (I went back to 2404 to get it), it didn't
> jump out at me (the bounds related calls only appear to be <10% of the
> time)  It could just be that I'm more dense than usual :-)
> 

'More dense than usual' it is:  I forgot to ratchet up the atom count
when I got profiling going.  *Then* the local/global conversions start
to dominate.  (The only reason I cranked them up that high originally
was to get some FPS distance between the Cog and Spur Squeak runs.  At
lower atom counts where drawing dominates, Cuis is still significantly
slower than Squeak running on Cog)

> I can definitely see how that could cause a problem doing 1000s of local
> to global conversions per frame...
> 
> > It is possible to optimize it back. It just requires some work.
> > 
> 
> Fair enough... but I still think that things are generally off
> performance-wise with Morphic... (it might just be that we've got a
> bunch of fairly unoptimized code similar to what's going on with
> BouncingAtomsMorph that will take some time to work through, but things
> are definitely feeling slow-ish from a UI standpoint)
> 
> > Cheers,
> > Juan Vuletich
> > 
> > >> Cheers,
> > >> Juan Vuletich
> > >>
> > >> On 8/12/2015 6:36 PM, Phil (list) wrote:
> > >>> I noticed a while back that something appeared to be going on with Cuis
> > >>> drawing performance (at idle on my system Morphic consumes ~20% of VM
> > >>> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> > >>> indication of what it's currently costing in drawing performance...
> > >>>
> > >>> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> > >>> how much of a speed boost we might be able to expect from Spur down the
> > >>> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> > >>> apples-to-apples comparison and was quite surprised: Spur was faster,
> > >>> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> > >>> performs much, much better than the Cuis version on the same VM.   Here
> > >>> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > >>> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> > >>> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > >>> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > >>> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > >>>
> > >>> Granted BouncingAtomsMorph is not 100% identical from a source code
> > >>> standpoint but it's not nearly different enough where I'd expect that
> > >>> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> > >>> are others noticing drawing issues as well?
> > >>>
> > >
> > >
> > 
> 





From juan at jvuletich.org  Sun Aug 16 10:08:04 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Sun, 16 Aug 2015 12:08:04 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph performance
Message-ID: <55D0A754.2070602@jvuletich.org>

Hi Folks,

Yesterday and today I pushed new stuff to github. See the attach. Cuis 
can now display both underscores and left arrows in the same method!

I also could not help it and worked on BouncingAtomsMorph performance. 
It should be close to Squeak now.

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis_underscores.png
Type: image/png
Size: 56056 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150816/60ccc446/attachment-0004.png>

From dnorton at mindspring.com  Sun Aug 16 13:02:24 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 14:02:24 -0400
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <55D0D030.28083.B5F605@dnorton.mindspring.com>

On 16 Aug 2015 at 12:08, Juan Vuletich wrote:

> Hi Folks,
> 
> Yesterday and today I pushed new stuff to github. See the attach.
> Cuis 
> can now display both underscores and left arrows in the same
> method!
> 
> I also could not help it and worked on BouncingAtomsMorph
> performance. 
> It should be close to Squeak now.
> 

No, it's faster. Much faster than Squeak in a side-by-side comparison.

 - Dan



From dnorton at mindspring.com  Sun Aug 16 13:33:56 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 14:33:56 -0400
Subject: [Cuis] Problem in VM-Dev
Message-ID: <55D0D794.31157.D2D674@dnorton.mindspring.com>

Hi Juan,

On 8/15/2015 Juan wrote: 
>On 8/15/2015 6:07 PM, Phil (list) wrote: 
>>
>>> Swear not. Use any of the class methods in the profiler: 
>>> AndreasSystemProfiler. For example, something like 
>>>
>>> AndreasSystemProfiler spyForMilliseconds: 200 
>>>
>> segfault (stack overflow)... 
>>
>
>Use Cog 3370 or older. I reported the problem in VM-Dev, but nobody 
listened. 

I don't see where you reported the problem. Can you give me a specific reference? Maybe if 
more of us post it will get some attention. I searched

gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 

for your posts in 2015 but did not see it.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150816/51d3414b/attachment-0004.html>

From pbpublist at gmail.com  Sun Aug 16 13:44:22 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 14:44:22 -0400
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <1439750662.16738.6.camel@gmail.com>

On Sun, 2015-08-16 at 12:08 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> Yesterday and today I pushed new stuff to github. See the attach. Cuis 
> can now display both underscores and left arrows in the same method!
> 
> I also could not help it and worked on BouncingAtomsMorph performance. 
> It should be close to Squeak now.

It's definitely improved BouncingAtomsMorph (I'm seeing at least 13-17
FPS now.. I say 'at least' because from time to time it jumps up to the
low 20's).  But more importantly (to me, at least) at first glance it
looks like these changes provide an across the board performance boost
to my other Morphic code. (most of my stuff doesn't have FPS counters
but in looking at Morphic CPU utilization in ProcessBrowser, it's almost
always 5-10% lower now)

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





From pbpublist at gmail.com  Sun Aug 16 13:48:36 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 14:48:36 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <55D0D794.31157.D2D674@dnorton.mindspring.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>
Message-ID: <1439750916.16738.10.camel@gmail.com>

On Sun, 2015-08-16 at 14:33 -0400, Dan Norton wrote:
> Hi Juan,
> 
> 
> On 8/15/2015 Juan wrote: 
> >On 8/15/2015 6:07 PM, Phil (list) wrote: 
> >>
> >>> Swear not. Use any of the class methods in the profiler: 
> >>> AndreasSystemProfiler. For example, something like 
> >>>
> >>> AndreasSystemProfiler spyForMilliseconds: 200 
> >>>
> >> segfault (stack overflow)... 
> >>
> >
> >Use Cog 3370 or older. I reported the problem in VM-Dev, but nobody 
> listened. 
> 
> 
> 
> I don't see where you reported the problem. Can you give me a specific
> reference? Maybe if more of us post it will get some attention. I
> searched
> 
> 
I just posted a reply to it a few hours ago hoping for the same effect.
His original posts were on 7/20 and had 'Cog crash with
AndreasSystemProfiler' in the subject line.

On a related note, I'm having an issue with 3410 hanging the image while
loading packages while 3390 is working (aside from the profiler issue)
for me... it's always something.

> gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 
> 
> 
> 
> for your posts in 2015 but did not see it.
> 
> 
>  - Dan
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Sun Aug 16 15:58:03 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 16:58:03 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <1439750916.16738.10.camel@gmail.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>,
	<1439750916.16738.10.camel@gmail.com>
Message-ID: <55D0F95B.20890.156C93E@dnorton.mindspring.com>

Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following 30+ times successfully:

	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159 printString]].

Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+ times and the VM 
crashed with a stack exception. Dump attached.

Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the following 40+ times 
successfully:

	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].

What is the difference between AndreasSystemProfiler and MessageTally? Their output 
appears similar.

 - Dan

On 16 Aug 2015 at 14:48, Phil (list) wrote:

> On Sun, 2015-08-16 at 14:33 -0400, Dan Norton wrote:
> > Hi Juan,
> > 
> > 
> > On 8/15/2015 Juan wrote: 
> > >On 8/15/2015 6:07 PM, Phil (list) wrote: 
> > >>
> > >>> Swear not. Use any of the class methods in the profiler: 
> > >>> AndreasSystemProfiler. For example, something like 
> > >>>
> > >>> AndreasSystemProfiler spyForMilliseconds: 200 
> > >>>
> > >> segfault (stack overflow)... 
> > >>
> > >
> > >Use Cog 3370 or older. I reported the problem in VM-Dev, but
> nobody 
> > listened. 
> > 
> > 
> > 
> > I don't see where you reported the problem. Can you give me a
> specific
> > reference? Maybe if more of us post it will get some attention.
> I
> > searched
> > 
> > 
> I just posted a reply to it a few hours ago hoping for the same
> effect.
> His original posts were on 7/20 and had 'Cog crash with
> AndreasSystemProfiler' in the subject line.
> 
> On a related note, I'm having an issue with 3410 hanging the image
> while
> loading packages while 3390 is working (aside from the profiler
> issue)
> for me... it's always something.
> 
> > gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 
> > 
> > 
> > 
> > for your posts in 2015 but did not see it.
> > 
> > 
> >  - 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProfilerCrash.zip
Type: application/zip
Size: 3325 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150816/00fbdcd8/attachment-0004.zip>

From pbpublist at gmail.com  Sun Aug 16 16:21:12 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 17:21:12 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <55D0F95B.20890.156C93E@dnorton.mindspring.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>
	, <1439750916.16738.10.camel@gmail.com>
	<55D0F95B.20890.156C93E@dnorton.mindspring.com>
Message-ID: <1439760072.16738.23.camel@gmail.com>

On Sun, 2015-08-16 at 16:58 -0400, Dan Norton wrote:
> Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following 30+ times successfully:
> 
> 	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159 printString]].
> 
> Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+ times and the VM 
> crashed with a stack exception. Dump attached.
> 
> Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the following 40+ times 
> successfully:
> 
> 	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].
> 
> What is the difference between AndreasSystemProfiler and MessageTally? Their output 
> appears similar.

They perform the same function but ASP is more accurate (esp related to
primitives) and capable of higher resolution.  Here's a write up by
Eliot back when it was originally released:
http://forum.world.st/Re-squeak-dev-AndreasSystemProfiler-Released-MIT-td4665183.html

> 
>  - Dan
> 
> On 16 Aug 2015 at 14:48, Phil (list) wrote:
> 
> > On Sun, 2015-08-16 at 14:33 -0400, Dan Norton wrote:
> > > Hi Juan,
> > > 
> > > 
> > > On 8/15/2015 Juan wrote: 
> > > >On 8/15/2015 6:07 PM, Phil (list) wrote: 
> > > >>
> > > >>> Swear not. Use any of the class methods in the profiler: 
> > > >>> AndreasSystemProfiler. For example, something like 
> > > >>>
> > > >>> AndreasSystemProfiler spyForMilliseconds: 200 
> > > >>>
> > > >> segfault (stack overflow)... 
> > > >>
> > > >
> > > >Use Cog 3370 or older. I reported the problem in VM-Dev, but
> > nobody 
> > > listened. 
> > > 
> > > 
> > > 
> > > I don't see where you reported the problem. Can you give me a
> > specific
> > > reference? Maybe if more of us post it will get some attention.
> > I
> > > searched
> > > 
> > > 
> > I just posted a reply to it a few hours ago hoping for the same
> > effect.
> > His original posts were on 7/20 and had 'Cog crash with
> > AndreasSystemProfiler' in the subject line.
> > 
> > On a related note, I'm having an issue with 3410 hanging the image
> > while
> > loading packages while 3390 is working (aside from the profiler
> > issue)
> > for me... it's always something.
> > 
> > > gmane.gmane.comp.lang.smalltalk.squeak.vm.devel 
> > > 
> > > 
> > > 
> > > for your posts in 2015 but did not see it.
> > > 
> > > 
> > >  - 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
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org





From dnorton at mindspring.com  Sun Aug 16 17:09:42 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 16 Aug 2015 18:09:42 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <1439760072.16738.23.camel@gmail.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>,
	<55D0F95B.20890.156C93E@dnorton.mindspring.com>,
	<1439760072.16738.23.camel@gmail.com>
Message-ID: <55D10A26.3277.1986224@dnorton.mindspring.com>

On 16 Aug 2015 at 17:21, Phil (list) wrote:

> On Sun, 2015-08-16 at 16:58 -0400, Dan Norton wrote:
> > Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following
> 30+ times successfully:
> > 
> > 	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159
> printString]].
> > 
> > Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+
> times and the VM 
> > crashed with a stack exception. Dump attached.
> > 
> > Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the
> following 40+ times 
> > successfully:
> > 
> > 	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].
> > 
> > What is the difference between AndreasSystemProfiler and
> MessageTally? Their output 
> > appears similar.
> 
> They perform the same function but ASP is more accurate (esp related
> to
> primitives) and capable of higher resolution.  Here's a write up
> by
> Eliot back when it was originally released:
> http://forum.world.st/Re-squeak-dev-AndreasSystemProfiler-Released-M
> IT-td4665183.html
> 

There is a 2015-01-27 version which preceeds the latest. Would that be worth a try?

 - Dan



From pbpublist at gmail.com  Sun Aug 16 17:41:14 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun, 16 Aug 2015 18:41:14 -0400
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <55D10A26.3277.1986224@dnorton.mindspring.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>
	, <55D0F95B.20890.156C93E@dnorton.mindspring.com>
	, <1439760072.16738.23.camel@gmail.com>
	<55D10A26.3277.1986224@dnorton.mindspring.com>
Message-ID: <1439764874.16738.26.camel@gmail.com>

On Sun, 2015-08-16 at 18:09 -0400, Dan Norton wrote:
> On 16 Aug 2015 at 17:21, Phil (list) wrote:
> 
> > On Sun, 2015-08-16 at 16:58 -0400, Dan Norton wrote:
> > > Using cogwin-15.22.3370 and Cuis4.2-2461.image, ran the following
> > 30+ times successfully:
> > > 
> > > 	AndreasSystemProfiler spyOn:[10000 timesRepeat: [3.14159
> > printString]].
> > > 
> > > Using cogwin-15.28.3410 and Cuis4.2-2461.image, ran the above 20+
> > times and the VM 
> > > crashed with a stack exception. Dump attached.
> > > 
> > > Using cogwin-15.28.3410 and Squeak4.6-15102.image, ran the
> > following 40+ times 
> > > successfully:
> > > 
> > > 	MessageTally spyOn:[10000 timesRepeat: [3.14159 printString]].
> > > 
> > > What is the difference between AndreasSystemProfiler and
> > MessageTally? Their output 
> > > appears similar.
> > 
> > They perform the same function but ASP is more accurate (esp related
> > to
> > primitives) and capable of higher resolution.  Here's a write up
> > by
> > Eliot back when it was originally released:
> > http://forum.world.st/Re-squeak-dev-AndreasSystemProfiler-Released-M
> > IT-td4665183.html
> > 
> 
> There is a 2015-01-27 version which preceeds the latest. Would that be worth a try?
> 

Eliot just posted a reply today indicating this bug is on his radar so
it will probably be fixed soon.

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





From Ken.Dickey at whidbey.com  Sun Aug 16 21:11:21 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Sun, 16 Aug 2015 19:11:21 -0700
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>

2461 TaskBar seems to lose collapsed morphs.

World >> New Morph >> <whatever>

Then collapse <whatever>.

Works OK with a Browser.  Leaves space to display the TaskBar buttons, but they do not show up (except for the browser).

Something about Morphs.

??
-KenD




From dnorton at mindspring.com  Mon Aug 17 10:14:51 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 17 Aug 2015 08:14:51 -0700 (PDT)
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>
References: <55D0A754.2070602@jvuletich.org>
	<20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>
Message-ID: <1439824491018-4843553.post@n4.nabble.com>

Similar observation here, except that browsers, workspaces, and transcripts
don't appear; other stuff does appear. However, everything is there in
Windows...>find window.

 - Dan



--
View this message in context: http://forum.world.st/Updates-Smart-underscores-BouncingAtomsMorph-performance-tp4843287p4843553.html
Sent from the Cuis Smalltalk mailing list archive at Nabble.com.



From juan at jvuletich.org  Mon Aug 17 15:53:48 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 17:53:48 -0300
Subject: [Cuis] Updates: Smart underscores &
	BouncingAtomsMorph	performance
In-Reply-To: <55D0D030.28083.B5F605@dnorton.mindspring.com>
References: <55D0A754.2070602@jvuletich.org>
	<55D0D030.28083.B5F605@dnorton.mindspring.com>
Message-ID: <55D249DC.4020807@jvuletich.org>

On 8/16/2015 3:02 PM, Dan Norton wrote:
> On 16 Aug 2015 at 12:08, Juan Vuletich wrote:
>
>> Hi Folks,
>>
>> Yesterday and today I pushed new stuff to github. See the attach.
>> Cuis
>> can now display both underscores and left arrows in the same
>> method!
>>
>> I also could not help it and worked on BouncingAtomsMorph
>> performance.
>> It should be close to Squeak now.
>>
> No, it's faster. Much faster than Squeak in a side-by-side comparison.
>
>   - Dan
>

Nice!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 17 15:55:36 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 17:55:36 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <1439750662.16738.6.camel@gmail.com>
References: <55D0A754.2070602@jvuletich.org>
	<1439750662.16738.6.camel@gmail.com>
Message-ID: <55D24A48.1060800@jvuletich.org>

On 8/16/2015 3:44 PM, Phil (list) wrote:
> On Sun, 2015-08-16 at 12:08 -0300, Juan Vuletich wrote:
>> Hi Folks,
>>
>> Yesterday and today I pushed new stuff to github. See the attach. Cuis
>> can now display both underscores and left arrows in the same method!
>>
>> I also could not help it and worked on BouncingAtomsMorph performance.
>> It should be close to Squeak now.
> It's definitely improved BouncingAtomsMorph (I'm seeing at least 13-17
> FPS now.. I say 'at least' because from time to time it jumps up to the
> low 20's).  But more importantly (to me, at least) at first glance it
> looks like these changes provide an across the board performance boost
> to my other Morphic code. (most of my stuff doesn't have FPS counters
> but in looking at Morphic CPU utilization in ProcessBrowser, it's almost
> always 5-10% lower now)
>

Yes, that sounds reasonable. Most of the code I optimized is quite 
general. This example was useful, because it was concrete enough to run 
the profiler and get consistent results. It is quite easy to optimize 
code if you know _where_ is the problem!

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 17 15:56:57 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 17:56:57 -0300
Subject: [Cuis] Updates: Smart underscores &
	BouncingAtomsMorph	performance
In-Reply-To: <1439824491018-4843553.post@n4.nabble.com>
References: <55D0A754.2070602@jvuletich.org>	<20150816191121.5ba32a9f9ad8b0901aaf47f5@whidbey.com>
	<1439824491018-4843553.post@n4.nabble.com>
Message-ID: <55D24A99.3050404@jvuletich.org>

On 8/17/2015 12:14 PM, Dan Norton wrote:
> Similar observation here, except that browsers, workspaces, and transcripts
> don't appear; other stuff does appear. However, everything is there in
> Windows...>find window.
>
>   - Dan

Yes. I introduced a bug in the recent Morphic optimizations. I fixed it 
now. Fortunately, fixed code is both simpler and slightly faster than 
the old code.

Cheers,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 17 16:00:32 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 18:00:32 -0300
Subject: [Cuis] more updates
Message-ID: <55D24B70.3030406@jvuletich.org>

Hi Folks,

I fixed the Taskbar bug I introduced yesterday. Thanks for reporting!

I also added a new folder for optional fonts data. Right now it contains 
several sizes of DejaVu Sans Mono, but we can add there any other font 
you find desirable (if it has a good license). Doing

StrikeFont install: 'DejaVu Sans Mono'

loads it.

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150817/2810cc81/attachment-0004.html>

From juan at jvuletich.org  Mon Aug 17 16:04:45 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 18:04:45 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <55D0A754.2070602@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org>
Message-ID: <55D24C6D.6090500@jvuletich.org>

On 8/16/2015 12:08 PM, Juan Vuletich wrote:
> Hi Folks,
>
> Yesterday and today I pushed new stuff to github. See the attach. Cuis 
> can now display both underscores and left arrows in the same method!
>
> I also could not help it and worked on BouncingAtomsMorph performance. 
> It should be close to Squeak now.
>
> Cheers,
> Juan Vuletich

I'm a bit surprised nobody commented on the attach. I'm quite happy 
about not having to give up our traditional assignment symbol, and at 
the same time, handle and display correctly underscores in names. These 
are sometimes useful when dealing with external code and stuff. I won't 
deny it, I'm also a bit proud of the idea to make it possible. Looking 
at the screenshot, doesn't it make you think "how the hell did he do it?" ?

Cheers,
Juan Vuletich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis_underscores.png
Type: image/png
Size: 56056 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150817/a271fcf9/attachment-0004.png>

From juan at jvuletich.org  Mon Aug 17 16:17:48 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 17 Aug 2015 18:17:48 -0300
Subject: [Cuis] Problem in VM-Dev
In-Reply-To: <1439764874.16738.26.camel@gmail.com>
References: <55D0D794.31157.D2D674@dnorton.mindspring.com>	,
	<55D0F95B.20890.156C93E@dnorton.mindspring.com>	,
	<1439760072.16738.23.camel@gmail.com>	<55D10A26.3277.1986224@dnorton.mindspring.com>
	<1439764874.16738.26.camel@gmail.com>
Message-ID: <55D24F7C.7030909@jvuletich.org>

Yay!

Cheers,
Juan Vuletich

On 8/16/2015 7:41 PM, Phil (list) wrote:
>
> Eliot just posted a reply today indicating this bug is on his radar so
> it will probably be fixed soon.




From lewis at mail.msen.com  Mon Aug 17 16:34:56 2015
From: lewis at mail.msen.com (David T. Lewis)
Date: Mon, 17 Aug 2015 17:34:56 -0400 (EDT)
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D24C6D.6090500@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
Message-ID: <47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>

> On 8/16/2015 12:08 PM, Juan Vuletich wrote:
>> Hi Folks,
>>
>> Yesterday and today I pushed new stuff to github. See the attach. Cuis
>> can now display both underscores and left arrows in the same method!
>>
>> I also could not help it and worked on BouncingAtomsMorph performance.
>> It should be close to Squeak now.
>>
>> Cheers,
>> Juan Vuletich
>
> I'm a bit surprised nobody commented on the attach. I'm quite happy
> about not having to give up our traditional assignment symbol, and at
> the same time, handle and display correctly underscores in names. These
> are sometimes useful when dealing with external code and stuff. I won't
> deny it, I'm also a bit proud of the idea to make it possible. Looking
> at the screenshot, doesn't it make you think "how the hell did he do it?"
> ?

Well, that's what *I* was wondering. So how did you do that???

:-)

Dave








From pbpublist at gmail.com  Mon Aug 17 18:09:15 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 17 Aug 2015 19:09:15 -0400
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D24C6D.6090500@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
Message-ID: <1439852955.16738.31.camel@gmail.com>

On Mon, 2015-08-17 at 18:04 -0300, Juan Vuletich wrote:
> On 8/16/2015 12:08 PM, Juan Vuletich wrote:
> > Hi Folks,
> >
> > Yesterday and today I pushed new stuff to github. See the attach. Cuis 
> > can now display both underscores and left arrows in the same method!
> >
> > I also could not help it and worked on BouncingAtomsMorph performance. 
> > It should be close to Squeak now.
> >
> > Cheers,
> > Juan Vuletich
> 
> I'm a bit surprised nobody commented on the attach. I'm quite happy 
> about not having to give up our traditional assignment symbol, and at 
> the same time, handle and display correctly underscores in names. These 
> are sometimes useful when dealing with external code and stuff. I won't 
> deny it, I'm also a bit proud of the idea to make it possible. Looking 
> at the screenshot, doesn't it make you think "how the hell did he do it?" ?
> 

You packed too much goodness into one post!  I was so occupied with the
Morphic part, the underscore part didn't even register... very nice job!
This has actually been one of my ongoing issues with the use of arrow
assignments so now I can leave them enabled.  So, how the hell did you
do it? :-)

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





From avalloud at smalltalk.comcastbiz.net  Tue Aug 18 19:55:14 2015
From: avalloud at smalltalk.comcastbiz.net (Andres Valloud)
Date: Tue, 18 Aug 2015 17:55:14 -0700
Subject: [Cuis] [Smalltalks 2015] --- Invitation
Message-ID: <55D3D3F2.50607@smalltalk.comcastbiz.net>

The Fundaci?n Argentina de Smalltalk proudly invites you to one of the 
premier Smalltalk conferences in the world.  Let's meet at Buenos Aires, 
November 11-13!  For more details, see the invitation here:

http://www.fast.org.ar/Smalltalks2015-invitation.pdf




From juan at jvuletich.org  Wed Aug 19 07:51:06 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Wed, 19 Aug 2015 09:51:06 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
	<47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>
Message-ID: <55D47BBA.3060805@jvuletich.org>

On 8/17/2015 6:34 PM, David T. Lewis wrote:
>>
>> I'm a bit surprised nobody commented on the attach. I'm quite happy
>> about not having to give up our traditional assignment symbol, and at
>> the same time, handle and display correctly underscores in names. These
>> are sometimes useful when dealing with external code and stuff. I won't
>> deny it, I'm also a bit proud of the idea to make it possible. Looking
>> at the screenshot, doesn't it make you think "how the hell did he do it?"
>> ?
> Well, that's what *I* was wondering. So how did you do that???
>
> :-)
>
> Dave
>

Well, the first idea was that it given that a StrikeFont can already 
swap glyphs (#useUnderscores, #useLeftArrow), then it is possible to 
build cheap derivative fonts that do that, and TextStyles for them. 
Then, Shout parses code and sets TextEmphasis like italics or colors for 
differenc code elements. I just made it set a TextEmphasis with 
underscores for identifiers.

It is so simple that I find it surprising that nobody (including me) 
thought about this years ago!

Cheers,
Juan Vuletich



From lewis at mail.msen.com  Wed Aug 19 11:56:22 2015
From: lewis at mail.msen.com (David T. Lewis)
Date: Wed, 19 Aug 2015 12:56:22 -0400 (EDT)
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
 performance
In-Reply-To: <55D47BBA.3060805@jvuletich.org>
References: <55D0A754.2070602@jvuletich.org> <55D24C6D.6090500@jvuletich.org>
	<47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>
	<55D47BBA.3060805@jvuletich.org>
Message-ID: <37162.136.2.1.102.1440003382.squirrel@webmail.msen.com>

Juan,

I hope you don't mind if I CC squeak-dev.

> On 8/17/2015 6:34 PM, David T. Lewis wrote:
>>>
>>> I'm a bit surprised nobody commented on the attach. I'm quite happy
>>> about not having to give up our traditional assignment symbol, and at
>>> the same time, handle and display correctly underscores in names. These
>>> are sometimes useful when dealing with external code and stuff. I won't
>>> deny it, I'm also a bit proud of the idea to make it possible. Looking
>>> at the screenshot, doesn't it make you think "how the hell did he do
>>> it?"
>>> ?
>> Well, that's what *I* was wondering. So how did you do that???
>>
>> :-)
>>
>> Dave
>>
>
> Well, the first idea was that it given that a StrikeFont can already
> swap glyphs (#useUnderscores, #useLeftArrow), then it is possible to
> build cheap derivative fonts that do that, and TextStyles for them.
> Then, Shout parses code and sets TextEmphasis like italics or colors for
> differenc code elements. I just made it set a TextEmphasis with
> underscores for identifiers.
>
> It is so simple that I find it surprising that nobody (including me)
> thought about this years ago!
>
> Cheers,
> Juan Vuletich
>

What a great idea!

Dave






From ume at blueplane.jp  Wed Aug 19 20:35:28 2015
From: ume at blueplane.jp (Masashi UMEZAWA)
Date: Thu, 20 Aug 2015 10:35:28 +0900
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: <CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>

Hi all,

Sorry for the late reply. I've missed the mail...

As I recall, I have deliberately selected not using Exceptions mainly
for portability.

Actually there are various non-existent-file exceptions -
FileDoesNotExist (Squeak), FileDoesNotExistException (Pharo),
OSErrorHolder nonexistentSignal (VW).

Originally old FileMan did not have exception wrappers, but it has
now. So I think it is a good time to introduce exception-aware APIs.

How about adding tryReadStream series?

[ readStream := 'foo.txt' asFileEntry tryReadStream ] on:
FmFileIOAccessor fileDoesNotExistException do: [:ex | ].

readStream := 'foo.txt' asFileEntry tryReadStreamIfError: [:ex | ].

Best regards,

2015-07-27 23:58 GMT+09:00 Juan Vuletich <juan at 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
>>>>>
>>>>>
>>>>
>>
>>
>

-- 
[:masashi | ^umezawa]



From juan at jvuletich.org  Thu Aug 20 08:52:42 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 20 Aug 2015 10:52:42 -0300
Subject: [Cuis] Updates: Smart underscores & BouncingAtomsMorph
	performance
In-Reply-To: <37162.136.2.1.102.1440003382.squirrel@webmail.msen.com>
References: <55D0A754.2070602@jvuletich.org>
	<55D24C6D.6090500@jvuletich.org>	<47674.136.2.1.105.1439847296.squirrel@webmail.msen.com>	<55D47BBA.3060805@jvuletich.org>
	<37162.136.2.1.102.1440003382.squirrel@webmail.msen.com>
Message-ID: <55D5DBAA.7090100@jvuletich.org>

Of course not! It would be very nice to see this done in Squeak and 
Pharo too.

Cheers,
Juan Vuletich

> Juan,
>
> I hope you don't mind if I CC squeak-dev.
>
> What a great idea!
>
> Dave
>



From juan at jvuletich.org  Thu Aug 20 09:01:40 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Thu, 20 Aug 2015 11:01:40 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@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>
	<55B64713.8040806@jvuletich.org>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
Message-ID: <55D5DDC4.9030101@jvuletich.org>

Hi Masashi,

> Hi all,
>
> Sorry for the late reply. I've missed the mail...
>
> As I recall, I have deliberately selected not using Exceptions mainly
> for portability.
>
> Actually there are various non-existent-file exceptions -
> FileDoesNotExist (Squeak), FileDoesNotExistException (Pharo),
> OSErrorHolder nonexistentSignal (VW).
>
> Originally old FileMan did not have exception wrappers, but it has
> now. So I think it is a good time to introduce exception-aware APIs.
>
> How about adding tryReadStream series?
>
> [ readStream := 'foo.txt' asFileEntry tryReadStream ] on:
> FmFileIOAccessor fileDoesNotExistException do: [:ex | ].
>
> readStream := 'foo.txt' asFileEntry tryReadStreamIfError: [:ex | ].
>
> Best regards,

Thanks for your support.

I guess I would prefer #readStream for the basic, raising exceptions 
api, and maybe #readStreamNoFail or #readStreamOrEmpty or such for the 
"exception eating api" . In any case it is your call, I understand there 
is back compatibility to care about, and I'll be happy with your choice.

Cheers,
Juan Vuletich

> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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 ume at blueplane.jp  Sat Aug 22 08:15:43 2015
From: ume at blueplane.jp (Masashi UMEZAWA)
Date: Sat, 22 Aug 2015 22:15:43 +0900
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <55D5DDC4.9030101@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>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
Message-ID: <CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>

Hi Juan,

Yes, I'm concerning about backward-compatibility.
FmFileEntry>>#readStream has been used long. So I would prefer just
adding new APIs.

Best regards,

> I guess I would prefer #readStream for the basic, raising exceptions api,
> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the "exception
> eating api" . In any case it is your call, I understand there is back
> compatibility to care about, and I'll be happy with your choice.
>
> Cheers,
> Juan Vuletich
>
>
>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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
>>>>>>>
>>>>>>>
>>>>
>



-- 
[:masashi | ^umezawa]



From eliot.miranda at gmail.com  Sat Aug 22 11:38:30 2015
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Sat, 22 Aug 2015 09:38:30 -0700
Subject: [Cuis] New Cog VMs available...
Message-ID: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3427.

Squeak V5 users will want to upgrade their VMs because they, along with
Smalltalk changes to follow soon, fix image segments.  But upgrading is not
a trivial process because the VMs on my site are not complete.  The best
way to update is to take a copy of the Squeak 5.0 all-in-one and replace
the main VM executable there-in with one from my site.  This gets you
up-to-date plugins and an up-to-date VM.  I hope that this process will get
easier soon.


------------------------------------------------------------------------
CogVM binaries as per VMMaker.oscog-eem.1441/r3427

Modify Spur ImageSegment load to become the segmentWordArray into an Array
of
the loaded objects if load is successful, hence decoupling ImageSegment from
the assumption that objects are allocated in order.

Fix Integer receiver, float arg comparison with NaNs in the machine-code
primitive.  This has started failing in the FloatTest>>testNaNCompare since
the
new machine-code perform primitive invoked the machine-code version of the
primitive.  The Interpretewr code has always been correct and the old
perform
primitive would always run the Interpreter primitive if it exsted, since
this
would probably be faster.

Fix the bug introduced by the fix to primitive function invocation in
VMMaker.oscog-eem.1351  The fix correctly changed primitve code to set the
primitiveFunctionPointer appropriately when a jitted external primitive was
rebound, but it didn't remember to void the jit's record of the offset of
the
assignment that sets the primitiveFunctionPointer when switching between
profiling andf non-profiling regimes, so that the address from the wrong
regime
would remain and be used to smash prmitive code.  The fix is simply to void
the
externalSetPrimOffsets in voidCogCompiledCode.  This fixes the bug whose
symptom is a hard VM crash when using AndreasSystemProfilier.

Integrate Marcel Taeumel & Tobias Pape's v2 SSL plugin changes.

Fix negative 64-bit shift in the 64-bit Spur Stack interpreter.

Newspeak:
Fix MNU for cogged self and outer sends.

Make the Newspeak VM packager include the V50 sources file instead of V41.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150822/35d7bb41/attachment-0004.html>

From j.b.shirk at gmail.com  Mon Aug 24 06:42:33 2015
From: j.b.shirk at gmail.com (Joe Shirk)
Date: Mon, 24 Aug 2015 07:42:33 -0400
Subject: [Cuis] IPFS on Smalltalk
Message-ID: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>

Dear all, especially @Masashi

I wanted to draw attention to the http://ipfs.io project, "the permanent
web" which works. It is a distributed peer-to-peer filesystem that works
somewhat like bittorrent. You get the functionality of Git as well. It is
truly ingenious.

Since I have taken an interest in Smalltalk (I'm still learning) I have
salivated at the  possibilities for, say Amber + ipfs.

There is currently a call for APIs implemented in other languages;
https://github.com/ipfs/ipfs/issues
I see no one there is interested in Smalltalk so I though I should
undertake it, but it will be many months before I have the knowledge and
there is no guarantee that I am up to the task... Now seeing that Masashi
is working with filesystems, perhaps you would take an interest in this
idea.

The inventor Juan Benet has many brilliant ideas and has done several
presentations to be found on the ipfs site. Unfortunately, he seems to
drink a lot of coffee and talks extremely fast and does not enunciate,
making the presentations very difficult to understand for those of whom
english is a second language. I can definitely help with this by making a
transcript if there is interest.


On Sat, Aug 22, 2015 at 1:00 PM, <cuis-request at jvuletich.org> wrote:

> Send Cuis mailing list submissions to
>         cuis at jvuletich.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> or, via email, send a message with subject or body 'help' to
>         cuis-request at jvuletich.org
>
> You can reach the person managing the list at
>         cuis-owner at jvuletich.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cuis digest..."
>
>
> Today's Topics:
>
>    1. Re: Wrapper for file access in different Smalltalk dialects
>       (Masashi UMEZAWA)
>    2. New Cog VMs available... (Eliot Miranda)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 22 Aug 2015 22:15:43 +0900
> From: Masashi UMEZAWA <ume at blueplane.jp>
> To: Juan Vuletich <juan at jvuletich.org>
> Cc: Discussion of Cuis Smalltalk <cuis at jvuletich.org>,  "H. Hirzel"
>         <hannes.hirzel at gmail.com>
> Subject: Re: [Cuis] Wrapper for file access in different Smalltalk
>         dialects
> Message-ID:
>         <CA+=
> t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Juan,
>
> Yes, I'm concerning about backward-compatibility.
> FmFileEntry>>#readStream has been used long. So I would prefer just
> adding new APIs.
>
> Best regards,
>
> > I guess I would prefer #readStream for the basic, raising exceptions api,
> > and maybe #readStreamNoFail or #readStreamOrEmpty or such for the
> "exception
> > eating api" . In any case it is your call, I understand there is back
> > compatibility to care about, and I'll be happy with your choice.
> >
> > Cheers,
> > Juan Vuletich
> >
> >
> >> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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
> >>>>>>>
> >>>>>>>
> >>>>
> >
>
>
>
> --
> [:masashi | ^umezawa]
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 22 Aug 2015 09:38:30 -0700
> From: Eliot Miranda <eliot.miranda at gmail.com>
> To: Squeak Virtual Machine Development Discussion
>         <vm-dev at lists.squeakfoundation.org>
> Cc: The general-purpose Squeak developers list
>         <squeak-dev at lists.squeakfoundation.org>,        Discusses
> Development of
>         Pharo <pharo-dev at lists.pharo.org>,
>         "newspeaklanguage at googlegroups.com"
>         <newspeaklanguage at googlegroups.com>,    Discussion of Cuis
> Smalltalk
>         <cuis at jvuletich.org>
> Subject: [Cuis] New Cog VMs available...
> Message-ID:
>         <CAC20JE1-f=nHr-jkoMsmpYaH=
> s2rkNxmaDom6bqZ3shfjDq2_g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3427.
>
> Squeak V5 users will want to upgrade their VMs because they, along with
> Smalltalk changes to follow soon, fix image segments.  But upgrading is not
> a trivial process because the VMs on my site are not complete.  The best
> way to update is to take a copy of the Squeak 5.0 all-in-one and replace
> the main VM executable there-in with one from my site.  This gets you
> up-to-date plugins and an up-to-date VM.  I hope that this process will get
> easier soon.
>
>
> ------------------------------------------------------------------------
> CogVM binaries as per VMMaker.oscog-eem.1441/r3427
>
> Modify Spur ImageSegment load to become the segmentWordArray into an Array
> of
> the loaded objects if load is successful, hence decoupling ImageSegment
> from
> the assumption that objects are allocated in order.
>
> Fix Integer receiver, float arg comparison with NaNs in the machine-code
> primitive.  This has started failing in the FloatTest>>testNaNCompare since
> the
> new machine-code perform primitive invoked the machine-code version of the
> primitive.  The Interpretewr code has always been correct and the old
> perform
> primitive would always run the Interpreter primitive if it exsted, since
> this
> would probably be faster.
>
> Fix the bug introduced by the fix to primitive function invocation in
> VMMaker.oscog-eem.1351  The fix correctly changed primitve code to set the
> primitiveFunctionPointer appropriately when a jitted external primitive was
> rebound, but it didn't remember to void the jit's record of the offset of
> the
> assignment that sets the primitiveFunctionPointer when switching between
> profiling andf non-profiling regimes, so that the address from the wrong
> regime
> would remain and be used to smash prmitive code.  The fix is simply to void
> the
> externalSetPrimOffsets in voidCogCompiledCode.  This fixes the bug whose
> symptom is a hard VM crash when using AndreasSystemProfilier.
>
> Integrate Marcel Taeumel & Tobias Pape's v2 SSL plugin changes.
>
> Fix negative 64-bit shift in the 64-bit Spur Stack interpreter.
>
> Newspeak:
> Fix MNU for cogged self and outer sends.
>
> Make the Newspeak VM packager include the V50 sources file instead of V41.
>
> _,,,^..^,,,_
> best, Eliot
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150822/35d7bb41/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 38, Issue 21
> ************************************
>



-- 

Gmail is unsecure. Why? See: EFF Surveillance Self-Defense Project
<https://ssd.eff.org/tech/email>

My preferred secure email address: infomaniac(at)i2pmail(dot)org
(For more information, please see: About I2P <http://www.i2p2.de/intro.html>
)

If you prefer to send to this gmail account, consider using
https://www.mailpile.is

My Public key:
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x8726E59217F0E6F9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150824/043d26be/attachment-0004.html>

From juanlists at jvuletich.org  Mon Aug 24 08:28:17 2015
From: juanlists at jvuletich.org (J. Vuletich (mail lists))
Date: Mon, 24 Aug 2015 13:28:17 +0000
Subject: [Cuis] [Vm-dev] New Cog VMs available...
In-Reply-To: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
References: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
Message-ID: <20150824132817.Horde.7mj1UgJfqgatW2PykGELgg7@gator3294.hostgator.com>

Thanks Eliot!

It works great, and indeed it fixes the issue with  
AndreasSystemProfiler I had reported.

Cheers,
Juan Vuletich

Quoting Eliot Miranda <eliot.miranda at gmail.com>:

>






From juan at jvuletich.org  Mon Aug 24 08:37:48 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:37:48 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55D3D3F2.50607@smalltalk.comcastbiz.net>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
Message-ID: <55DB1E2C.4010300@jvuletich.org>

Thanks Andr?s,

I'll be there. Maybe I'll submit a talk proposal too.

Folks, what do you think I'd tell about?
- Cuis, introduction for people who don't know much about it, recent 
development and community activity, etc.
- Repeat, and add latest details to the talk I already gave about work 
at Satellogic.
- Morphic 3. I'd rather not. Maybe a short "show us your project" demo, 
given that there are no recent news here.
- anything else?

Cheers,
Juan Vuletich

On 8/18/2015 9:55 PM, Andres Valloud wrote:
> The Fundaci?n Argentina de Smalltalk proudly invites you to one of the 
> premier Smalltalk conferences in the world.  Let's meet at Buenos 
> Aires, November 11-13!  For more details, see the invitation here:
>
> http://www.fast.org.ar/Smalltalks2015-invitation.pdf
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org




From juan at jvuletich.org  Mon Aug 24 08:42:46 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:42:46 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@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>
	<55B64713.8040806@jvuletich.org>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
	<CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>
Message-ID: <55DB1F56.608@jvuletich.org>

Hi Masashi,

Ok. #tryReadStream is reasonable. Or maybe #readStreamOrFail.

Any other suggestion? Preferences?

Thanks,
Juan Vuletich

On 8/22/2015 10:15 AM, Masashi UMEZAWA wrote:
> Hi Juan,
>
> Yes, I'm concerning about backward-compatibility.
> FmFileEntry>>#readStream has been used long. So I would prefer just
> adding new APIs.
>
> Best regards,
>
>> I guess I would prefer #readStream for the basic, raising exceptions api,
>> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the "exception
>> eating api" . In any case it is your call, I understand there is back
>> compatibility to care about, and I'll be happy with your choice.
>>
>> Cheers,
>> Juan Vuletich
>>
>>
>>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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 juan at jvuletich.org  Mon Aug 24 08:43:09 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:43:09 -0300
Subject: [Cuis] New Cog VMs available...
In-Reply-To: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
References: <CAC20JE1-f=nHr-jkoMsmpYaH=s2rkNxmaDom6bqZ3shfjDq2_g@mail.gmail.com>
Message-ID: <55DB1F6D.1010006@jvuletich.org>

Works like a charm.

Thanks a lot!

Cheers,
Juan Vuletich

On 8/22/2015 1:38 PM, Eliot Miranda wrote:
> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3427.
>
> Squeak V5 users will want to upgrade their VMs because they, along 
> with Smalltalk changes to follow soon, fix image segments.  But 
> upgrading is not a trivial process because the VMs on my site are not 
> complete.  The best way to update is to take a copy of the Squeak 5.0 
> all-in-one and replace the main VM executable there-in with one from 
> my site.  This gets you up-to-date plugins and an up-to-date VM.  I 
> hope that this process will get easier soon.
>
>
> ------------------------------------------------------------------------
> CogVM binaries as per VMMaker.oscog-eem.1441/r3427
>
> Modify Spur ImageSegment load to become the segmentWordArray into an 
> Array of
> the loaded objects if load is successful, hence decoupling 
> ImageSegment from
> the assumption that objects are allocated in order.
>
> Fix Integer receiver, float arg comparison with NaNs in the machine-code
> primitive.  This has started failing in the FloatTest>>testNaNCompare 
> since the
> new machine-code perform primitive invoked the machine-code version of the
> primitive.  The Interpretewr code has always been correct and the old 
> perform
> primitive would always run the Interpreter primitive if it exsted, 
> since this
> would probably be faster.
>
> Fix the bug introduced by the fix to primitive function invocation in
> VMMaker.oscog-eem.1351  The fix correctly changed primitve code to set the
> primitiveFunctionPointer appropriately when a jitted external 
> primitive was
> rebound, but it didn't remember to void the jit's record of the offset 
> of the
> assignment that sets the primitiveFunctionPointer when switching between
> profiling andf non-profiling regimes, so that the address from the 
> wrong regime
> would remain and be used to smash prmitive code.  The fix is simply to 
> void the
> externalSetPrimOffsets in voidCogCompiledCode.  This fixes the bug whose
> symptom is a hard VM crash when using AndreasSystemProfilier.
>
> Integrate Marcel Taeumel & Tobias Pape's v2 SSL plugin changes.
>
> Fix negative 64-bit shift in the 64-bit Spur Stack interpreter.
>
> Newspeak:
> Fix MNU for cogged self and outer sends.
>
> Make the Newspeak VM packager include the V50 sources file instead of V41.
>
> _,,,^..^,,,_
> best, Eliot
>
>
> _______________________________________________
> 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/20150824/9ffa5f3c/attachment-0004.html>

From juan at jvuletich.org  Mon Aug 24 08:48:43 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 10:48:43 -0300
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
Message-ID: <55DB20BB.708@jvuletich.org>

Hi Joe,

Someone saying "awesome!" and "cool!" so many times at his own stuff 
makes me a little uncomfortable... But, anyway:

It looks like Dropbox, but peer to peer, right?

The possibility of publishing and sharing stuff without a central 
provider is of course desirable.

Before starting to implement bindings and calls to the api... Is that 
really needed? It is integrated in the file system, so maybe not.

More interesting than that, what are some apps that could benefit from 
it? How would they do that?

Cheers,
Juan Vuletich

On 8/24/2015 8:42 AM, Joe Shirk wrote:
> Dear all, especially @Masashi
>
> I wanted to draw attention to the http://ipfs.io project, "the 
> permanent web" which works. It is a distributed peer-to-peer 
> filesystem that works somewhat like bittorrent. You get the 
> functionality of Git as well. It is truly ingenious.
>
> Since I have taken an interest in Smalltalk (I'm still learning) I 
> have salivated at the  possibilities for, say Amber + ipfs.
>
> There is currently a call for APIs implemented in other languages;
> https://github.com/ipfs/ipfs/issues
> I see no one there is interested in Smalltalk so I though I should 
> undertake it, but it will be many months before I have the knowledge 
> and there is no guarantee that I am up to the task... Now seeing that 
> Masashi is working with filesystems, perhaps you would take an 
> interest in this idea.
>
> The inventor Juan Benet has many brilliant ideas and has done several 
> presentations to be found on the ipfs site. Unfortunately, he seems to 
> drink a lot of coffee and talks extremely fast and does not enunciate, 
> making the presentations very difficult to understand for those of 
> whom english is a second language. I can definitely help with this by 
> making a transcript if there is interest.
>




From j.b.shirk at gmail.com  Mon Aug 24 09:25:58 2015
From: j.b.shirk at gmail.com (Joe Shirk)
Date: Mon, 24 Aug 2015 10:25:58 -0400
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <55DB20BB.708@jvuletich.org>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
	<55DB20BB.708@jvuletich.org>
Message-ID: <CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>

Hi Juan,

I was trying to diplomatically imply that Benet's forte is not
presentation, however the docs on the site and on github are adequate
introductions, and I think it won't take long to see the value in what is
meant by "permanent" web that is content addressed instead of ip addressed.

I spoke too soon today, not aware that he had recently responded to my post
a week ago:

https:// <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>
github.com <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>
/issues/80#issuecomment-133593050
<https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>

As at the moment I am thumbing my smartphone, I have to be brief, but I'll
try to cover the basics.

ipfs is a protocal that has the potential to eventually replace http
altogether, though currently content on the ipfs network is accessible
directly through the protocol as well as through http gateways.

ipfs is a content routing system, and so functions like a cdn, but it is
distributed, so is like bittorrent. it does sync like dropbox, but the
routing system ensures that copies of content migrate closer to demand,
which could be an auditorium of people on a local wifi without external
access. Real-time syncing to many peers is thus possible without latency.

There are working demos of HD videos streaming without latency from the
network.

The Directed Acyclical Graph / Merkel Tree allows for just about any data
structure, but is especially well designed for versioning. Everything is
addressed by its hash fingerprint, so one can be absolutely sure what
version one requests, but can also traverse the version tree if the content
referenced is say, a software library that is a dependency for a certain
package. Automatic forwarding to a more recent version is also a feature.

There is a name system too, that allows one to register a permanent or
temporary namespace that references a version tree of any object.

All objects are stored in encrypted chunks, so privacy and publicity are
controlled.

To me, this system implemented in smalltalk, and I suppose that should be
squeak and amber, will make it possible to build distributed apps, because
the app itself can be an object, not only its content or data. Implementing
in smalltalk should mean that the complexity involved would be more easily
managed with few bugs, compared to say, javascript or node.

I see ipfs as a route to put smalltalk in the limelight and on the cutting
edge.

HTH

Joe



> Message: 5
> Date: Mon, 24 Aug 2015 10:48:43 -0300
> From: Juan Vuletich <juan at jvuletich.org>
> To: Discussion of Cuis Smalltalk <cuis at jvuletich.org>
> Cc: Joe Shirk <j.b.shirk at gmail.com>
> Subject: Re: [Cuis] IPFS on Smalltalk
> Message-ID: <55DB20BB.708 at jvuletich.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi Joe,
>
> Someone saying "awesome!" and "cool!" so many times at his own stuff
> makes me a little uncomfortable... But, anyway:
>
> It looks like Dropbox, but peer to peer, right?
>
> The possibility of publishing and sharing stuff without a central
> provider is of course desirable.
>
> Before starting to implement bindings and calls to the api... Is that
> really needed? It is integrated in the file system, so maybe not.
>
> More interesting than that, what are some apps that could benefit from
> it? How would they do that?
>
> Cheers,
> Juan Vuletich
>
> On 8/24/2015 8:42 AM, Joe Shirk wrote:
> > Dear all, especially @Masashi
> >
> > I wanted to draw attention to the http://ipfs.io project, "the
> > permanent web" which works. It is a distributed peer-to-peer
> > filesystem that works somewhat like bittorrent. You get the
> > functionality of Git as well. It is truly ingenious.
> >
> > Since I have taken an interest in Smalltalk (I'm still learning) I
> > have salivated at the  possibilities for, say Amber + ipfs.
> >
> > There is currently a call for APIs implemented in other languages;
> > https://github.com/ipfs/ipfs/issues
> > I see no one there is interested in Smalltalk so I though I should
> > undertake it, but it will be many months before I have the knowledge
> > and there is no guarantee that I am up to the task... Now seeing that
> > Masashi is working with filesystems, perhaps you would take an
> > interest in this idea.
> >
> > The inventor Juan Benet has many brilliant ideas and has done several
> > presentations to be found on the ipfs site. Unfortunately, he seems to
> > drink a lot of coffee and talks extremely fast and does not enunciate,
> > making the presentations very difficult to understand for those of
> > whom english is a second language. I can definitely help with this by
> > making a transcript if there is interest.
> >
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> ------------------------------
>
> End of Cuis Digest, Vol 38, Issue 23
> ************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150824/b30244e6/attachment-0004.html>

From juan at jvuletich.org  Mon Aug 24 10:01:11 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 24 Aug 2015 12:01:11 -0300
Subject: [Cuis] Oops!  [Was package relative fileIns]
In-Reply-To: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>
References: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>
Message-ID: <55DB31B7.4050203@jvuletich.org>

Hi Ken,

On 8/23/2015 12:43 PM, Ken.Dickey wrote:
> Wrong click!  Try this one.
>
> The problem came up with someone loading Cuis-Smalltalk-Morphit-master.zip, so Cuis-Smalltalk-MorphIt-master was the dirName.

It is a good addition. But your implementation fails when the package 
name isn't equal to the category name, but a prefix. For example, 
loading 'Signal-Processing', it works for FFT packagePath, but fails for 
FloatImage packagePath.

This cleaner implementation works for both:

     packagePath
         ^ FileDirectory dirPathFor:
             (CodePackage packageOfClass: self ifNone: [ ^nil ]) 
fullFileName

It will be in the next commit.

> The Portland Camp Smalltalk was much fun, BTW.  Met some interesting folks.  Showed Cuis to Gemstone and Instantiations people + general demo.   Found and fixed a few bugs.  Nice folks.
>
> -KenD

Hey that's great! Thank you! Where the talks recoded on video?

I could not find a program of the CampSmalltalk there, but saw some 
pics. It looks like you had a great time there. I would like to join you 
all there next year!

(cc Cuis mail list. hope you don't mind)

Cheers,
Juan Vuletich



From garduino at gmail.com  Mon Aug 24 10:34:09 2015
From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=)
Date: Mon, 24 Aug 2015 12:34:09 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55DB1E2C.4010300@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org>
Message-ID: <CAEt3aLzeNZaMPa+meSVnKDuRp==a6vL_x-NkuCWQVb-+aR1Eeg@mail.gmail.com>

Hi Juan:

I think that all the mentioned topics are interesting.

I have not not much time lately to help / invest in Cuis, but if the
material or part of it that I used in Smalltalks 2013 is of some utility
for you, feel free to use it.


Saludos / Regards,
Germ?n Arduino
@garduino


2015-08-24 10:37 GMT-03:00 Juan Vuletich <juan at jvuletich.org>:

> Thanks Andr?s,
>
> I'll be there. Maybe I'll submit a talk proposal too.
>
> Folks, what do you think I'd tell about?
> - Cuis, introduction for people who don't know much about it, recent
> development and community activity, etc.
> - Repeat, and add latest details to the talk I already gave about work at
> Satellogic.
> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo,
> given that there are no recent news here.
> - anything else?
>
> Cheers,
> Juan Vuletich
>
> On 8/18/2015 9:55 PM, Andres Valloud wrote:
>
>> The Fundaci?n Argentina de Smalltalk proudly invites you to one of the
>> premier Smalltalk conferences in the world.  Let's meet at Buenos Aires,
>> November 11-13!  For more details, see the invitation here:
>>
>> http://www.fast.org.ar/Smalltalks2015-invitation.pdf
>>
>>
>> _______________________________________________
>> 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/20150824/f34b2b6e/attachment-0004.html>

From Ken.Dickey at whidbey.com  Sun Aug 23 19:57:01 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 24 Aug 2015 08:57:01 +0800
Subject: [Cuis] The Layout Resize Problem
Message-ID: <20150824085701.fe1053bcdbe68d36e1db633c@whidbey.com>

Greetings,

I have been thinking about "the layout resize problem".

The basis of the layout resize problem is that when someone changes fonts, we would like windows/panes/labels to adjust themselves with the minimum of fuss.

Also, when I resize a Morph I sometimes find that the layouts shrink below submorph containment size.  Currently, specifying a LayoutSpec which indicates "resize, but use morph extent as a minimum" seems awkward.

My intuitive thought is to make use of Morph>>minimumExtent.  LayoutMorphs (composts) could use the maximum width (mimimumExtent x) of their submorphs and the sum of the morph heights (minimumExtent y), possibly adding an extentBorder, and use this as its minimumExtent.

Note that if no submorph changes size, this value can be cached as it does not have to be recalculated.  Low cost calculations (buttonExtent, measureContents) don't have to be cached.

This leads to two questions: 
 [1] How to be informed when something changes that one depends on to calculate ones size.
 [2] How, when something changes size, to do this once for each affected morph?

My thought here is that the World could be informed that font size (or whatever influences  size calculations) changes.  Then it asks each of its submorphs, recursively, to recalculateMinimumExtent and layoutSubmorphs.  

This should happen top to bottom once for each resize causing event.

We can update our size calculating code and get rid of "Please Close All Open Windows".

Does this sound about right?  Other strategies?

Cheers,
-KenD



From edgardec2005 at gmail.com  Mon Aug 24 12:24:52 2015
From: edgardec2005 at gmail.com (Edgar De Cleene)
Date: Mon, 24 Aug 2015 14:24:52 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55DB1E2C.4010300@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org>
Message-ID: <5A326ADB-3193-47C2-8233-C45A4A854A33@gmail.com>

i wish a clarification about some Cuis 4 and beyond aspects

> On Aug 24, 2015, at 10:37 AM, Juan Vuletich <juan at jvuletich.org> wrote:
> 
> Thanks Andr?s,
> 
> I'll be there. Maybe I'll submit a talk proposal too.
> 
> Folks, what do you think I'd tell about?
> - Cuis, introduction for people who don't know much about it, recent development and community activity, etc.
> - Repeat, and add latest details to the talk I already gave about work at Satellogic.
> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo, given that there are no recent news here.
> - anything else?
> 
> Cheers,
> Juan Vuletich
> 
> On 8/18/2015 9:55 PM, Andres Valloud wrote:
>> The Fundaci?n Argentina de Smalltalk proudly invites you to one of the premier Smalltalk conferences in the world.  Let's meet at Buenos Aires, November 11-13!  For more details, see the invitation here:
>> 
>> http://www.fast.org.ar/Smalltalks2015-invitation.pdf
>> 
>> 
>> _______________________________________________
>> 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 j.b.shirk at gmail.com  Mon Aug 24 15:14:12 2015
From: j.b.shirk at gmail.com (Joe Shirk)
Date: Mon, 24 Aug 2015 16:14:12 -0400
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>
	<55DB20BB.708@jvuletich.org>
	<CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
Message-ID: <CA+VgV_sgcLt=m81266ugSeo42hrMd-jdZsfWmJqm7_6V-X+z2w@mail.gmail.com>

I don't know why I wrote 'Squeak' -- too much reading, I guess. I meant
Pharo. My thinking was to make it work there first, then port to cuis and
newspeak if there is a benefit in doing that. Perhaps that's not the best
way to go about it. Any thoughts on this?

On Mon, Aug 24, 2015 at 10:25 AM, Joe Shirk <j.b.shirk at gmail.com> wrote:

> To me, this system implemented in smalltalk, and I suppose that should be
> squeak and amber, will make it possible to build distributed apps, because
> the app itself can be an object, not only its content or data. Implementing
> in smalltalk should mean that the complexity involved would be more easily
> managed with few bugs, compared to say, javascript or node.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150824/b1f94f7a/attachment-0004.html>

From Ken.Dickey at whidbey.com  Mon Aug 24 17:33:55 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 24 Aug 2015 15:33:55 -0700
Subject: [Cuis] Oops!  [Was package relative fileIns]
In-Reply-To: <55DB31B7.4050203@jvuletich.org>
References: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>
	<55DB31B7.4050203@jvuletich.org>
Message-ID: <20150824153355.5c917d40a1bbea5e7d893085@whidbey.com>

On Mon, 24 Aug 2015 12:01:11 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Ken,
> 
> On 8/23/2015 12:43 PM, Ken.Dickey wrote:
..
> > The Portland Camp Smalltalk was much fun, BTW.  Met some interesting folks.  Showed Cuis to Gemstone and Instantiations people + general demo.   Found and fixed a few bugs.  Nice folks.
> >
> > -KenD
 
> Hey that's great! Thank you! Where the talks recoded on video?

No.  I don't think so.  Pretty informal.  First time I had tried the video out on my ChromeBook.  It works! 

I had been showing the Unicode display to someone, so that showed up when I opened my laptop.  Mentioned that.  I  showed drag n drop behaviors with the PropertyEditor and MorphMorphs (MorphIt package) and then showed the puzzle pieces prototyped for planned Snap! style authoring (Emergence package).  Due to questions, I updated the README.md in Cuis-Smalltalk-BabySteps. Very pre-alpha, but there are documentation classes in the MorphIt and Emergence packages. 

> I could not find a program of the CampSmalltalk there, but saw some 
> pics. 

I presume you mean Mike Taylor's pix at https://goo.gl/photos/QCQz77DKLPAPGY5x9

No formal program.  More like, "Anybody have something they would like to share?".  Who's next?

Of note:
  WireShark packet capture analysis
  Multi-programming-language editing (e.g. syntax hilighting and keywords in Java/whatever within JavaScript within HTML).
  Baby steps to Mist/Fog (smalltalk in itself w/o VM) bootstrap.
  Glamor (Pharo presentation framework) extension project.

I am the guy in the purple Apple shirt, BTW.  [Shows up as row 3 pic 1 in my browser].  I see myself in a couple of other snaps as well.  I must have been there.  ;^)

> It looks like you had a great time there. I would like to join you 
> all there next year!

We all would be delighted if you could make it.  Might even get together an agenda/program for the event.  I heard that there will be another camp in Nanimo (British Colombia, Canada) in October, which I hope to attend.

> (cc Cuis mail list. hope you don't mind)

Not at all!  People came from as far as up from New York, Toronto, Boston, Vista (California).  I'll count Andre as from Salem (Washington).  Really need more folks from down south.

Wrote some code.  Found and fixed some bugs.  Met a great bunch of interesting folks.  Well worth the trip!

-- 
-KenD



From pbpublist at gmail.com  Tue Aug 25 13:47:50 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue, 25 Aug 2015 14:47:50 -0400
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55DB1E2C.4010300@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org>
Message-ID: <1440528470.2306.13.camel@gmail.com>

On Mon, 2015-08-24 at 10:37 -0300, Juan Vuletich wrote:
> Thanks Andr?s,
> 
> I'll be there. Maybe I'll submit a talk proposal too.
> 
> Folks, what do you think I'd tell about?
> - Cuis, introduction for people who don't know much about it, recent 
> development and community activity, etc.
> - Repeat, and add latest details to the talk I already gave about work 
> at Satellogic.
> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo, 
> given that there are no recent news here.
> - anything else?
> 

My main suggestion would be to go for new material (since your previous
talks were recorded people can watch them already and they're still
pretty relevant... maybe you could link to them from the Cuis site to
make them easier to find)  Recent developments and/or near-future plans
might be interesting for those who don't pay close attention to what's
going on with Cuis.
 
> Cheers,
> Juan Vuletich
> 
> On 8/18/2015 9:55 PM, Andres Valloud wrote:
> > The Fundaci?n Argentina de Smalltalk proudly invites you to one of the 
> > premier Smalltalk conferences in the world.  Let's meet at Buenos 
> > Aires, November 11-13!  For more details, see the invitation here:
> >
> > http://www.fast.org.ar/Smalltalks2015-invitation.pdf
> >
> >
> > _______________________________________________
> > 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 ume at blueplane.jp  Thu Aug 27 10:24:44 2015
From: ume at blueplane.jp (Masashi UMEZAWA)
Date: Fri, 28 Aug 2015 00:24:44 +0900
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <55DB1F56.608@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>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
	<CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>
	<55DB1F56.608@jvuletich.org>
Message-ID: <CA+=t-6D3fbHLyYck0v=wdsUZuGWAJ6uyoWopq_+-+5Haut6Ebg@mail.gmail.com>

Hi Juan,

How about adding #tryWriteStream and #tryWriteStreamIfError: for consistency.
Currently FmFileEntry has #writeStreamConfirming, but it is a bit
ad-hoc. It can be renamed to #tryWriteStream.

So we can write:

[ writeStream := 'foo.txt' asFileEntry tryWriteStream ] on:
FmFileIOAccessor fileExistsException do: [:ex | ].

writeStream := 'foo.txt' asFileEntry tryWriteStreamIfError: [:ex | ].

Best regards,

2015-08-24 22:42 GMT+09:00 Juan Vuletich <juan at jvuletich.org>:
> Hi Masashi,
>
> Ok. #tryReadStream is reasonable. Or maybe #readStreamOrFail.
>
> Any other suggestion? Preferences?
>
> Thanks,
> Juan Vuletich
>
>
> On 8/22/2015 10:15 AM, Masashi UMEZAWA wrote:
>>
>> Hi Juan,
>>
>> Yes, I'm concerning about backward-compatibility.
>> FmFileEntry>>#readStream has been used long. So I would prefer just
>> adding new APIs.
>>
>> Best regards,
>>
>>> I guess I would prefer #readStream for the basic, raising exceptions api,
>>> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the
>>> "exception
>>> eating api" . In any case it is your call, I understand there is back
>>> compatibility to care about, and I'll be happy with your choice.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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
>>>>>>>>>
>>>>>>>>>
>>
>>
>



-- 
[:masashi | ^umezawa]



From Ken.Dickey at whidbey.com  Thu Aug 27 03:48:04 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Thu, 27 Aug 2015 16:48:04 +0800
Subject: [Cuis] Font Preferences Change
Message-ID: <20150827164804.5d251b01c9c085f7874edd4f@whidbey.com>

Hi Juan,

I have done enough with resizing on Font Preference Change that I would like some feedback.

The basic questions are:
  [1] Does this direction/strategy seem OK?
  [2] Am I breaking (too many) things?
  [3] Better ideas?  Simpler strategy?
  [4] In sum, it it worth while to continue?

In base, when the user changes preferred fonts, the world gets a fontPreferenceChanged message which it sends to its submorphs, who in turn propagate the message to their submorphs and so forth.

Morph>>fontPreferenceChanged
    self submorphsDo: [ :m | m fontPreferenceChanged ]

Windows which do special things (like set up buttons with fixed* layoutSpec fields) do any special processing required.  Morphs which set relations based on some font metric update their fonts/relations.  Windows typically set up button sizes, so need to reset these.  Some morphs recalculate their minimumExtent or reset their fonts.

For example:

InnerListMorph>>fontPreferenceChanged
    super fontPreferenceChanged.
    self font: Preferences standardListFont.

Look at senders of #fontPreferenceChanged for details.


Usage:
  I have two change sets to file in to the base image.  In order, load the *LayoutTest* then the *FontResize*.

If you use the layout editors, load the Morphic-Misc1 package, then the UnsavedChanges* file.


Expect some missed resize cases.  

Thanks in advance for thoughtful comments.

-KenD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2464-KenD-LayoutTest-KenD.5.cs.st
Type: application/octet-stream
Size: 7012 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150827/c9a2e255/attachment-0012.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st
Type: application/octet-stream
Size: 7428 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150827/c9a2e255/attachment-0013.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st
Type: application/octet-stream
Size: 11990 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150827/c9a2e255/attachment-0014.obj>

From Ken.Dickey at whidbey.com  Fri Aug 28 03:28:07 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Fri, 28 Aug 2015 16:28:07 +0800
Subject: [Cuis] Font Resize Code
Message-ID: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>

Hmmm.. 

There seems to have a problem with file 2464-KenD-LayoutTest-KenD.5.cs.st.

Here is the complete set again (attached).

File in: 
  2464-KenD-LayoutTest-KenD.5.cs.st
  2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st

Optionally:
  Feature require: #'Morphic-Misc1'.
Then file in:
  UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st

Open browsers and other windows.

Then 
  World Menu>>Preferences>>Font Sizes..

And play a bit.

-- 
-KenD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st
Type: application/octet-stream
Size: 7458 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150828/c007b65a/attachment-0012.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2464-KenD-LayoutTest-KenD.5.cs.st
Type: application/octet-stream
Size: 6843 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150828/c007b65a/attachment-0013.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st
Type: application/octet-stream
Size: 11990 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150828/c007b65a/attachment-0014.obj>

From dnorton at mindspring.com  Sun Aug 30 13:19:38 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 30 Aug 2015 14:19:38 -0400
Subject: [Cuis] Font Height Change?
Message-ID: <55E3493A.32598.BF01F7@dnorton.mindspring.com>

Hi All,

The attached can illustrate a change in the spaces between lines of text. How can I find what 
is causing this change? Placing a "{...} print" in TextModelMorph>>drawOn: is definitely a bad 
idea. To see the spacing change, unzip and file in the attached, open the window with:

	AnagramWindow open.

Click "New", enter a string such as "illicit" and click "More" a few times. 

For different window sizes, the spaces between lines becomes smaller. I do adjust the width 
of the window to keep the text in columns but I'm trying to find out why the spacing changes.

 - Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AnagramAid.pck.zip
Type: application/zip
Size: 3658 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150830/d01b2558/attachment-0004.zip>

From dnorton at mindspring.com  Sun Aug 30 17:10:13 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 30 Aug 2015 18:10:13 -0400
Subject: [Cuis] Font Height Change?
Message-ID: <55E37F45.4235.1921E41@dnorton.mindspring.com>

Never mind. In a fresh image, I can't reproduce it :-/

On 30 Aug 2015 at 14:20, cuis at jvuletich.org wrote:

> Hi All,
> 
> The attached can illustrate a change in the spaces between lines of
> text. How can I find what 
> is causing this change? Placing a "{...} print" in
> TextModelMorph>>drawOn: is definitely a bad 
> idea. To see the spacing change, unzip and file in the attached,
> open the window with:
> 
> 	AnagramWindow open.
> 
> Click "New", enter a string such as "illicit" and click "More" a few
> times. 
> 
> For different window sizes, the spaces between lines becomes
> smaller. I do adjust the width 
> of the window to keep the text in columns but I'm trying to find out
> why the spacing changes.
> 
>  - Dan
> 
> Attachments:
>   C:\Cuis\Anagram\Cuis-Smalltalk-anagram\AnagramAid.pck.zip





From dnorton at mindspring.com  Sun Aug 30 18:01:20 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Sun, 30 Aug 2015 19:01:20 -0400
Subject: [Cuis] Font Height Change?
Message-ID: <55E38B40.31946.1C0E883@dnorton.mindspring.com>

Aha! Game on again. It occurs when the font 'DejaVu Sans Mono' is installed and 
AnagramWindow>>cluesFont uses it for the text, but not always. Otherwise, it does not occur 
when the font is 'DejaVu' which is the default.

Resizing the window reverses the close spacing. A couple more clicks of "More" can cause it 
to recur.

On 30 Aug 2015 at 18:10, cuis at jvuletich.org wrote:

> Never mind. In a fresh image, I can't reproduce it :-/
> 
> On 30 Aug 2015 at 14:20, cuis at jvuletich.org wrote:
> 
> > Hi All,
> > 
> > The attached can illustrate a change in the spaces between lines
> of
> > text. How can I find what 
> > is causing this change? Placing a "{...} print" in
> > TextModelMorph>>drawOn: is definitely a bad 
> > idea. To see the spacing change, unzip and file in the attached,
> > open the window with:
> > 
> > 	AnagramWindow open.
> > 
> > Click "New", enter a string such as "illicit" and click "More" a
> few
> > times. 
> > 
> > For different window sizes, the spaces between lines becomes
> > smaller. I do adjust the width 
> > of the window to keep the text in columns but I'm trying to find
> out
> > why the spacing changes.
> > 
> >  - Dan
> > 
> > Attachments:
> >   C:\Cuis\Anagram\Cuis-Smalltalk-anagram\AnagramAid.pck.zip
> 
> 





From juan at jvuletich.org  Mon Aug 31 07:49:53 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 09:49:53 -0300
Subject: [Cuis] Font Resize Code
In-Reply-To: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>
References: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>
Message-ID: <55E44D71.7080502@jvuletich.org>

Hi Ken,

Apologies for not answering before.

This is a great and welcome addition. I already integrated it and it 
will be in the next commit to GitHub. Thanks!

Cheers,
Juan Vuletich

On 8/28/2015 5:28 AM, Ken.Dickey wrote:
> Hmmm..
>
> There seems to have a problem with file 2464-KenD-LayoutTest-KenD.5.cs.st.
>
> Here is the complete set again (attached).
>
> File in:
>    2464-KenD-LayoutTest-KenD.5.cs.st
>    2465-FontResize-KenD-2015Aug27-13h51m-KenD.4.cs.st
>
> Optionally:
>    Feature require: #'Morphic-Misc1'.
> Then file in:
>    UnsavedChangesTo-Morphic-Misc1-KenD.4.cs.st
>
> Open browsers and other windows.
>
> Then
>    World Menu>>Preferences>>Font Sizes..
>
> And play a bit.
>




From juan at jvuletich.org  Mon Aug 31 07:54:20 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 09:54:20 -0300
Subject: [Cuis] Font Height Change?
In-Reply-To: <55E38B40.31946.1C0E883@dnorton.mindspring.com>
References: <55E38B40.31946.1C0E883@dnorton.mindspring.com>
Message-ID: <55E44E7C.7010608@jvuletich.org>

Hi Dan,

On 8/30/2015 8:01 PM, Dan Norton wrote:
> Aha! Game on again. It occurs when the font 'DejaVu Sans Mono' is installed and
> AnagramWindow>>cluesFont uses it for the text, but not always. Otherwise, it does not occur
> when the font is 'DejaVu' which is the default.
>
> Resizing the window reverses the close spacing. A couple more clicks of "More" can cause it
> to recur.

Found it! The problem is that in #atRandom and #permuted first you sent 
the contents to your morph, and then you modify them (without the morph 
really realizing of that). I'm not sure about the details of the 
behavior you found, but the attach is cleaner and fixes the problem.

Cheers,
Juan Vuletich
-------------- next part --------------
'From Cuis 4.2 of 25 July 2013 [latest update: #2464] on 30 August 2015 at 10:30:15.736488 pm'!

!Anagram methodsFor: 'operating' stamp: 'jmv 8/30/2015 22:29'!
atRandom
	"Display randomly selected clues"
	"estas poniendo el font despues de mandarle el texto al morph... El morph ni se entera...
	Asi, no ncecesitas cluesFont"
	| set temp |
	set _ Set new.
	self class cluesToDisplay timesRepeat: [set add: jmb shuffled].	"avoid duplicates"
	temp _ String new writeStream.
	set do: [:ea |
		temp
			nextPutAll: ea;
			nextPutAll: self separators].
	self board cluesString actualContents: (Text 
		initialFont: (AbstractFont familyName: 'DejaVu Sans Mono' aroundPointSize: 10)
		stringOrText: temp contents).
	count _ count + set size! !

!Anagram methodsFor: 'operating' stamp: 'jmv 8/30/2015 22:29'!
permuted
	"Display a set of permuted clues"
	| clueSet clue str |
	clue _ String new writeStream.
	clueSet _ Set new.
	(1 to: jmb size) permutationsDo: [ :letter |
		clue reset.
		(1 to: jmb size) do: [ :ix |
			clue nextPut: (jmb at: (letter at: ix))].
		clueSet add: clue contents].	"avoid duplicates"
	str _ String new writeStream.
	clueSet do: [:ea |
		str
			nextPutAll: ea;
			nextPutAll: self separators].
	self board cluesString actualContents: (Text 
		initialFont: (AbstractFont familyName: 'DejaVu Sans Mono' aroundPointSize: 10)
		stringOrText: str contents).
	count _ count + clueSet size! !

!methodRemoval: AnagramWindow #cluesFont!
AnagramWindow removeSelector: #cluesFont!

From juan at jvuletich.org  Mon Aug 31 07:57:49 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 09:57:49 -0300
Subject: [Cuis] Oops!  [Was package relative fileIns]
In-Reply-To: <20150824153355.5c917d40a1bbea5e7d893085@whidbey.com>
References: <20150823084311.2236c166d60a99c652f27a04@whidbey.com>	<55DB31B7.4050203@jvuletich.org>
	<20150824153355.5c917d40a1bbea5e7d893085@whidbey.com>
Message-ID: <55E44F4D.2060709@jvuletich.org>

Hi Ken,

Thanks for the report :)

Nice to see you!

Cheers,
Juan Vuletich

On 8/24/2015 7:33 PM, Ken.Dickey wrote:
> On Mon, 24 Aug 2015 12:01:11 -0300
> Juan Vuletich<juan at jvuletich.org>  wrote:
>
>> Hi Ken,
>>
>> On 8/23/2015 12:43 PM, Ken.Dickey wrote:
> ..
>>> The Portland Camp Smalltalk was much fun, BTW.  Met some interesting folks.  Showed Cuis to Gemstone and Instantiations people + general demo.   Found and fixed a few bugs.  Nice folks.
>>>
>>> -KenD
>
>> Hey that's great! Thank you! Where the talks recoded on video?
> No.  I don't think so.  Pretty informal.  First time I had tried the video out on my ChromeBook.  It works!
>
> I had been showing the Unicode display to someone, so that showed up when I opened my laptop.  Mentioned that.  I  showed drag n drop behaviors with the PropertyEditor and MorphMorphs (MorphIt package) and then showed the puzzle pieces prototyped for planned Snap! style authoring (Emergence package).  Due to questions, I updated the README.md in Cuis-Smalltalk-BabySteps. Very pre-alpha, but there are documentation classes in the MorphIt and Emergence packages.
>
>> I could not find a program of the CampSmalltalk there, but saw some
>> pics.
> I presume you mean Mike Taylor's pix at https://goo.gl/photos/QCQz77DKLPAPGY5x9
>
> No formal program.  More like, "Anybody have something they would like to share?".  Who's next?
>
> Of note:
>    WireShark packet capture analysis
>    Multi-programming-language editing (e.g. syntax hilighting and keywords in Java/whatever within JavaScript within HTML).
>    Baby steps to Mist/Fog (smalltalk in itself w/o VM) bootstrap.
>    Glamor (Pharo presentation framework) extension project.
>
> I am the guy in the purple Apple shirt, BTW.  [Shows up as row 3 pic 1 in my browser].  I see myself in a couple of other snaps as well.  I must have been there.  ;^)
>
>> It looks like you had a great time there. I would like to join you
>> all there next year!
> We all would be delighted if you could make it.  Might even get together an agenda/program for the event.  I heard that there will be another camp in Nanimo (British Colombia, Canada) in October, which I hope to attend.
>
>> (cc Cuis mail list. hope you don't mind)
> Not at all!  People came from as far as up from New York, Toronto, Boston, Vista (California).  I'll count Andre as from Salem (Washington).  Really need more folks from down south.
>
> Wrote some code.  Found and fixed some bugs.  Met a great bunch of interesting folks.  Well worth the trip!
>




From juan at jvuletich.org  Mon Aug 31 08:01:51 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 10:01:51 -0300
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <1440528470.2306.13.camel@gmail.com>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>	<55DB1E2C.4010300@jvuletich.org>
	<1440528470.2306.13.camel@gmail.com>
Message-ID: <55E4503F.6030603@jvuletich.org>

Hi Folks,

On 8/25/2015 3:47 PM, Phil (list) wrote:
> On Mon, 2015-08-24 at 10:37 -0300, Juan Vuletich wrote:
>> Thanks Andr?s,
>>
>> I'll be there. Maybe I'll submit a talk proposal too.
>>
>> Folks, what do you think I'd tell about?
>> - Cuis, introduction for people who don't know much about it, recent
>> development and community activity, etc.
>> - Repeat, and add latest details to the talk I already gave about work
>> at Satellogic.
>> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo,
>> given that there are no recent news here.
>> - anything else?
>>
> My main suggestion would be to go for new material (since your previous
> talks were recorded people can watch them already and they're still
> pretty relevant... maybe you could link to them from the Cuis site to
> make them easier to find)  Recent developments and/or near-future plans
> might be interesting for those who don't pay close attention to what's
> going on with Cuis.

Thanks you all for your suggestions. Please tell if you think of 
something else, or more specific questions or issues to address in a talk.

Phil, the idea to link to the videos is very good. Do you (or anybody) 
know how to do that? Maybe a link to youtube that already includes a 
search for "Cuis Smalltalk"? Or some sort of auto-generated playlist?

Thanks,
Juan Vuletich



From juan at jvuletich.org  Mon Aug 31 08:09:33 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 10:09:33 -0300
Subject: [Cuis] IPFS on Smalltalk
In-Reply-To: <CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
References: <CA+VgV_sjhAy64oP2imgKAq6-PU=FSYmKdJgzBLH5ACyswjNUqg@mail.gmail.com>	<55DB20BB.708@jvuletich.org>
	<CA+VgV_ugXu7mWNsc2apZQoiiE7kuQDJ+1mriQTJhj3ZodHjN3g@mail.gmail.com>
Message-ID: <55E4520D.4040105@jvuletich.org>

Hi Joe,

On 8/24/2015 11:25 AM, Joe Shirk wrote:
>
>
> Hi Juan,
>
> I was trying to diplomatically imply that Benet's forte is not 
> presentation, however the docs on the site and on github are adequate 
> introductions, and I think it won't take long to see the value in what 
> is  meant by "permanent" web that is content addressed instead of ip 
> addressed.
>
> I spoke too soon today, not aware that he had recently responded to my 
> post a week ago:
>
> https:// 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>github.com 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/ 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/ 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>ipfs 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>/issues/80#issuecomment-133593050 
> <https://github.com/ipfs/ipfs/issues/80#issuecomment-133593050>
>
> As at the moment I am thumbing my smartphone, I have to be brief, but 
> I'll try to cover the basics.
>
> ipfs is a protocal that has the potential to eventually replace http 
> altogether, though currently content on the ipfs network is accessible 
> directly through the protocol as well as through http gateways.
>
> ipfs is a content routing system, and so functions like a cdn, but it 
> is distributed, so is like bittorrent. it does sync like dropbox, but 
> the routing system ensures that copies of content migrate closer to 
> demand, which could be an auditorium of people on a local wifi without 
> external access. Real-time syncing to many peers is thus possible 
> without latency.
>
> There are working demos of HD videos streaming without latency from 
> the network.
>
> The Directed Acyclical Graph / Merkel Tree allows for just about any 
> data structure, but is especially well designed for versioning. 
> Everything is addressed by its hash fingerprint, so one can be 
> absolutely sure what version one requests, but can also traverse the 
> version tree if the content referenced is say, a software library that 
> is a dependency for a certain package. Automatic forwarding to a more 
> recent version is also a feature.
>
> There is a name system too, that allows one to register a permanent or 
> temporary namespace that references a version tree of any object.
>
> All objects are stored in encrypted chunks, so privacy and publicity 
> are controlled.
>
> To me, this system implemented in smalltalk, and I suppose that should 
> be squeak and amber, will make it possible to build distributed apps, 
> because the app itself can be an object, not only its content or data. 
> Implementing in smalltalk should mean that the complexity involved 
> would be more easily managed with few bugs, compared to say, 
> javascript or node.
>
> I see ipfs as a route to put smalltalk in the limelight and on the 
> cutting edge.
>
> HTH
>
> Joe
>

Thanks for the explanation. I think that implementing it, and playing 
and experimenting with it will show new and better ways of sharing code 
and content, in a word, objects.

I look forward for all this.

Cheers,
Juan Vuletich

>
>
>
> > Message: 5
> > Date: Mon, 24 Aug 2015 10:48:43 -0300
> > From: Juan Vuletich <juan at jvuletich.org <mailto:juan at jvuletich.org>>
> > To: Discussion of Cuis Smalltalk <cuis at jvuletich.org 
> <mailto:cuis at jvuletich.org>>
> > Cc: Joe Shirk <j.b.shirk at gmail.com <mailto:j.b.shirk at gmail.com>>
> > Subject: Re: [Cuis] IPFS on Smalltalk
> > Message-ID: <55DB20BB.708 at jvuletich.org 
> <mailto:55DB20BB.708 at jvuletich.org>>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> >
> > Hi Joe,
> >
> > Someone saying "awesome!" and "cool!" so many times at his own stuff
> > makes me a little uncomfortable... But, anyway:
> >
> > It looks like Dropbox, but peer to peer, right?
> >
> > The possibility of publishing and sharing stuff without a central
> > provider is of course desirable.
> >
> > Before starting to implement bindings and calls to the api... Is that
> > really needed? It is integrated in the file system, so maybe not.
> >
> > More interesting than that, what are some apps that could benefit from
> > it? How would they do that?
> >
> > Cheers,
> > Juan Vuletich
> >
> > On 8/24/2015 8:42 AM, Joe Shirk wrote:
> > > Dear all, especially @Masashi
> > >
> > > I wanted to draw attention to thehttp://ipfs.io project, "the
> > > permanent web" which works. It is a distributed peer-to-peer
> > > filesystem that works somewhat like bittorrent. You get the
> > > functionality of Git as well. It is truly ingenious.
> > >
> > > Since I have taken an interest in Smalltalk (I'm still learning) I
> > > have salivated at the  possibilities for, say Amber + ipfs.
> > >
> > > There is currently a call for APIs implemented in other languages;
> > >https://github.com/ipfs/ipfs/issues
> > > I see no one there is interested in Smalltalk so I though I should
> > > undertake it, but it will be many months before I have the knowledge
> > > and there is no guarantee that I am up to the task... Now seeing that
> > > Masashi is working with filesystems, perhaps you would take an
> > > interest in this idea.
> > >
> > > The inventor Juan Benet has many brilliant ideas and has done several
> > > presentations to be found on the ipfs site. Unfortunately, he seems to
> > > drink a lot of coffee and talks extremely fast and does not enunciate,
> > > making the presentations very difficult to understand for those of
> > > whom english is a second language. I can definitely help with this by
> > > making a transcript if there is interest.
> > >
> >
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Cuis mailing list
> >Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
> >http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
> >
> > ------------------------------
> >
> > End of Cuis Digest, Vol 38, Issue 23
> > ************************************
>
>
> _______________________________________________
> 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/20150831/5523cc1f/attachment-0004.html>

From juan at jvuletich.org  Mon Aug 31 08:20:06 2015
From: juan at jvuletich.org (Juan Vuletich)
Date: Mon, 31 Aug 2015 10:20:06 -0300
Subject: [Cuis] Wrapper for file access in different Smalltalk dialects
In-Reply-To: <CA+=t-6D3fbHLyYck0v=wdsUZuGWAJ6uyoWopq_+-+5Haut6Ebg@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>
	<55B64713.8040806@jvuletich.org>
	<CA+=t-6At1gQJZj_yeruvnEUmwgjg3_iiCBj=Fg40wf82XFvxVg@mail.gmail.com>
	<55D5DDC4.9030101@jvuletich.org>
	<CA+=t-6DYQrpd9421Gq8jX7Zd5HTB05OUjRe2VyMx10UXpDDTPA@mail.gmail.com>
	<55DB1F56.608@jvuletich.org>
	<CA+=t-6D3fbHLyYck0v=wdsUZuGWAJ6uyoWopq_+-+5Haut6Ebg@mail.gmail.com>
Message-ID: <55E45486.30506@jvuletich.org>

Hi Masashi,

Looks great to me. Please let us know when you update 
https://github.com/mumez/FileMan (or 
https://github.com/mumez/Cuis-Smalltalk-FileMan ), so we follow. Or post 
code to the mail list. As you prefer.

Thanks!
Juan Vuletich

On 8/27/2015 12:24 PM, Masashi UMEZAWA wrote:
> Hi Juan,
>
> How about adding #tryWriteStream and #tryWriteStreamIfError: for consistency.
> Currently FmFileEntry has #writeStreamConfirming, but it is a bit
> ad-hoc. It can be renamed to #tryWriteStream.
>
> So we can write:
>
> [ writeStream := 'foo.txt' asFileEntry tryWriteStream ] on:
> FmFileIOAccessor fileExistsException do: [:ex | ].
>
> writeStream := 'foo.txt' asFileEntry tryWriteStreamIfError: [:ex | ].
>
> Best regards,
>
> 2015-08-24 22:42 GMT+09:00 Juan Vuletich<juan at jvuletich.org>:
>> Hi Masashi,
>>
>> Ok. #tryReadStream is reasonable. Or maybe #readStreamOrFail.
>>
>> Any other suggestion? Preferences?
>>
>> Thanks,
>> Juan Vuletich
>>
>>
>> On 8/22/2015 10:15 AM, Masashi UMEZAWA wrote:
>>> Hi Juan,
>>>
>>> Yes, I'm concerning about backward-compatibility.
>>> FmFileEntry>>#readStream has been used long. So I would prefer just
>>> adding new APIs.
>>>
>>> Best regards,
>>>
>>>> I guess I would prefer #readStream for the basic, raising exceptions api,
>>>> and maybe #readStreamNoFail or #readStreamOrEmpty or such for the
>>>> "exception
>>>> eating api" . In any case it is your call, I understand there is back
>>>> compatibility to care about, and I'll be happy with your choice.
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>>
>>>>> 2015-07-27 23:58 GMT+09:00 Juan Vuletich<juan at 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 Ken.Dickey at whidbey.com  Mon Aug 31 09:50:50 2015
From: Ken.Dickey at whidbey.com (Ken.Dickey)
Date: Mon, 31 Aug 2015 07:50:50 -0700
Subject: [Cuis] Font Resize Code
In-Reply-To: <55E44D71.7080502@jvuletich.org>
References: <20150828162807.7f5fafc689d4dba33f7288c9@whidbey.com>
	<55E44D71.7080502@jvuletich.org>
Message-ID: <20150831075050.f99f1041f30d9e155e39caed@whidbey.com>

On Mon, 31 Aug 2015 09:49:53 -0300
Juan Vuletich <juan at jvuletich.org> wrote:

> Apologies for not answering before.

No worries.  Storm here with high winds knocked out power for 2 days, so I would not have known anyway.

> This is a great and welcome addition. I already integrated it and it 
> will be in the next commit to GitHub. Thanks!

You are very welcome!

Good to give demos.  One has the opportunity to learn and get embarrassed, which leads toward progress.  ;^) 

Back to reading Snap! code..

Cheers,
-KenD



From dnorton at mindspring.com  Mon Aug 31 12:38:47 2015
From: dnorton at mindspring.com (Dan Norton)
Date: Mon, 31 Aug 2015 13:38:47 -0400
Subject: [Cuis] Font Height Change?
In-Reply-To: <55E44E7C.7010608@jvuletich.org>
References: <55E38B40.31946.1C0E883@dnorton.mindspring.com>,
	<55E44E7C.7010608@jvuletich.org>
Message-ID: <55E49127.31197.88F661@dnorton.mindspring.com>

Thanks for the answer, Juan. It stops confusing and annoying the morph :)

 - Dan

On 31 Aug 2015 at 9:54, Juan Vuletich wrote:

> Hi Dan,
> 
> On 8/30/2015 8:01 PM, Dan Norton wrote:
> > Aha! Game on again. It occurs when the font 'DejaVu Sans Mono' is
> installed and
> > AnagramWindow>>cluesFont uses it for the text, but not always.
> Otherwise, it does not occur
> > when the font is 'DejaVu' which is the default.
> >
> > Resizing the window reverses the close spacing. A couple more
> clicks of "More" can cause it
> > to recur.
> 
> Found it! The problem is that in #atRandom and #permuted first you
> sent 
> the contents to your morph, and then you modify them (without the
> morph 
> really realizing of that). I'm not sure about the details of the 
> behavior you found, but the attach is cleaner and fixes the
> problem.
> 
> Cheers,
> Juan Vuletich
> 





From pbpublist at gmail.com  Mon Aug 31 16:54:01 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon, 31 Aug 2015 17:54:01 -0400
Subject: [Cuis] [Smalltalks 2015] --- Invitation
In-Reply-To: <55E4503F.6030603@jvuletich.org>
References: <55D3D3F2.50607@smalltalk.comcastbiz.net>
	<55DB1E2C.4010300@jvuletich.org> <1440528470.2306.13.camel@gmail.com>
	<55E4503F.6030603@jvuletich.org>
Message-ID: <1441058041.8967.11.camel@gmail.com>

On Mon, 2015-08-31 at 10:01 -0300, Juan Vuletich wrote:
> Hi Folks,
> 
> On 8/25/2015 3:47 PM, Phil (list) wrote:
> > On Mon, 2015-08-24 at 10:37 -0300, Juan Vuletich wrote:
> >> Thanks Andr?s,
> >>
> >> I'll be there. Maybe I'll submit a talk proposal too.
> >>
> >> Folks, what do you think I'd tell about?
> >> - Cuis, introduction for people who don't know much about it, recent
> >> development and community activity, etc.
> >> - Repeat, and add latest details to the talk I already gave about work
> >> at Satellogic.
> >> - Morphic 3. I'd rather not. Maybe a short "show us your project" demo,
> >> given that there are no recent news here.
> >> - anything else?
> >>
> > My main suggestion would be to go for new material (since your previous
> > talks were recorded people can watch them already and they're still
> > pretty relevant... maybe you could link to them from the Cuis site to
> > make them easier to find)  Recent developments and/or near-future plans
> > might be interesting for those who don't pay close attention to what's
> > going on with Cuis.
> 
> Thanks you all for your suggestions. Please tell if you think of 
> something else, or more specific questions or issues to address in a talk.
> 
> Phil, the idea to link to the videos is very good. Do you (or anybody) 
> know how to do that? Maybe a link to youtube that already includes a 
> search for "Cuis Smalltalk"? Or some sort of auto-generated playlist?
> 

There are a few different ways I can think of depending on your
preference:
1) You could create a 'videos' page on the Cuis site (this is what I was
thinking) and then create embedded players for each video.  Go to a
video you want to add, click the share link, then the embed tab to get
the html snippet.  The reason to keep this on a separate page is that
YouTube embeds aren't 'lightweight' so it would be polite to keep these
off the main page or you will probably annoy visitors and decrease
traffic to the main Cuis page.  If they click on a videos link
presumably they understand that this might be a heavier page but it is
what they want...
2) Create a YouTube playlist on your YouTube channel.  This is just a
matter of going to each video you want and click the add button and add
it to the playlist (and make sure the playlist is public).  This works
but then there is no linkage between the Cuis page and the playlist
(though you could combine this and item 1 and do an embedded playlist)
3) A YouTube search such as
https://www.youtube.com/results?search_query=cuis+smalltalk will 'sort
of' get you in the ballpark, but probably not what visitors will
want/expect.

Here are a couple of videos that would probably be good to add to the
list:
https://www.youtube.com/watch?v=bgIwbx-eDcI
https://www.youtube.com/watch?v=YFn4tShalUI

I seem to also recall a general English Cuis overview presentation you
did (also at a Smalltalks conf?) but can't find the link right now...

> Thanks,
> Juan Vuletich