From leves at caesar.elte.hu  Wed Jul  1 00:55:10 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Wed, 1 Jul 2020 02:55:10 +0200 (CEST)
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <CANzdToG6x4b8jF=+eOxNHDCcSHNujY-GTnBUjbp98ZXF=0d5WQ@mail.gmail.com>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <CACddb62c6mMXcJW7+QLJ_hLLOQd8-0p2SSU55LrYkXiiAAkCdg@mail.gmail.com>
 <CANzdToG6x4b8jF=+eOxNHDCcSHNujY-GTnBUjbp98ZXF=0d5WQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.2007010246440.2544@login03.caesar.elte.hu>

On Tue, 30 Jun 2020, Chris Muller wrote:

> Might be worth reopening this discussion.  ANY dependencies on #class seem like a bad thing to me, especially while it's still an in-lined message.  Below is the MC version that did it.  Looks like the time to change this

Using #class by default sounds correct to me. If some instances of 
classes want to be equal to each other, they should handle that 
themselves by overriding #=.
Using #species everywhere is just horrible.

> 19-year old core method went from "itch" to trunk in all but just a few hours...

How did you come to that conclusion?


Levente

> ________________
> Name: Collections-nice.820
> Author: nice
> Time: 12 February 2019, 11:56:35.262017 pm
> UUID: bb383133-067c-4133-987b-c481a7de69c7
> Ancestors: Collections-ul.819, Collections-cbc.813
> 
> Definitively abandon SequenceableCollection equality tests based on equal species.
> 
> Old behaviour can still be obtained thru hasEqualElements: but the default is to not try to support such trans-class equality feature because it is much too complex.
> 
> Particularly Interval are no more equal to Arrays with same sequence. We can thus optimize hash a bit more and fix the old bugs of equa objects with different hashes. Merge Collections-cbc.813 for this and rehashAll in
> postscript.
> 
> There are not so many classes concerned by this change, mainly RunArray, Interval and LinkedList:
> 
> Collection withAllSubclasses select: [:e | [e basicNew species ~= e] on: Error do: [false]]
> -> an OrderedCollection(WeakRegistry LinkedList Interval ByteCharacterSet CharacterSetComplement LazyCharacterSet WideCharacterSet ShortRunArray Semaphore Mutex TextLineInterval WeakArray Monitor MCVersionName ByteSymbol
> WideSymbol)
> 
> We will have to change the tests that rely on such equality.
> 
> On Mon, Jun 29, 2020 at 3:42 AM Nikolay Suslov <nsuslovi at gmail.com> wrote:
>       Thanks Levente, 
> 
> Yes, seems to be RFB/VNC from the SqueakSource-SqF project page is outdated (at least it is working in Squeak 5.2 and not in 5.3 and later). Your version works fine!
> However, it is interesting what was the reason for that change just in SequenceableCollection #=. As Set, Bitset, SortedCollection etc. classes still use species comparison in #= (checking they have the same set of
> keys)?
> 
> Best regards,
> Nikolai
> 
> On Mon, Jun 29, 2020 at 3:43 AM Levente Uzonyi <leves at caesar.elte.hu> wrote:
>       Hi Nikolai,
>
>       On Mon, 29 Jun 2020, Nikolay Suslov wrote:
>
>       > Hello all,
>       > Figuring out, could we go back to the previous version of SequenceableCollection #= method (as in Squeak 5.2), to check if the receiver is equivalent to the otherCollection by using "self species ==
>       otherCollection species",
>       > instead of "self class = otherCollection class"?
>
>       IIRC there was a good reason for that change though I can't recall
>       what it was. I'm sure the mailing list remembers.
> 
>
>       > The current version of #= method breaks code in different places. For example the RFB/VNC server gives wrong results starting from an authentication process, where RFBMessage is the ByteArray subclass and
>       implements #species.
>
>       If you're looking for a fix, try this:
>       http://leves.web.elte.hu/squeak/RFB-ul.18.mcz
> 
>
>       Levente
>
>       >
>       > Best regards,
>       > Nikolai
>       >
>       >
> 
> 
> 
>

From leves at caesar.elte.hu  Wed Jul  1 00:57:24 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Wed, 1 Jul 2020 02:57:24 +0200 (CEST)
Subject: [squeak-dev] The Inbox: Monticello-ul.726.mcz
In-Reply-To: <CANzdToGxMYKECscguf2gKyEFoauUdGotXXMi8cCuujo-rFMJaQ@mail.gmail.com>
References: <E1jpgxO-0002bn-Aa@andreas>
 <CA+ovNC5je+J9egxHxbP4AyNKJ0G6uFSZi5ZOm9eGzCLMmdkRgg@mail.gmail.com>
 <alpine.DEB.2.02.2006292016130.28257@login03.caesar.elte.hu>
 <CANzdToGxMYKECscguf2gKyEFoauUdGotXXMi8cCuujo-rFMJaQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.2007010255460.2544@login03.caesar.elte.hu>

On Tue, 30 Jun 2020, Chris Muller wrote:

> Hi Levente and Jakob,
>
>       > Am Mo., 29. Juni 2020 um 01:43 Uhr schrieb <commits at source.squeak.org>:
>       >>
>       >> + ----- Method: MCDirectoryRepository>>includesVersionNamed: (in category 'versions') -----
>       >> + includesVersionNamed: aString
>       >> +
>       >> +       | comparable |
>       >> +       comparable := ((aString endsWith: '.mcz') and: [ aString size > 4 ])
>       >> +               ifTrue: [ aString allButLast: 4 ]
>       >> +               ifFalse: [ aString ].
>       >
>       > Thank you for the suggestion. Why not use aString asMCVersionName
>       > versionName here?
>
>       Copy-paste from parent.
>       When Chris introduced MCVersionName, he tried to use #asMCVersionName
>       there, but later he reverted it according to the history of the parent
>       method. It probably broke stuff (see below). 
> 
> 
> Hmm...  that's true, unfortunately, my comment only says, "Fix" it with no other details.  I can't help but wonder if it was due to a #class test somewhere..
>  
>
>       I think MCVersionName is something that should not exists in its current
>       form. Why?
>       - it's a subclass of ByteString, which limits the possible character set
> 
> 
> It's common in the IT industry for Name identifiers to be restricted to a subset of ASCII to support interoperation with as many types of systems as possible.  It seems an appropriate choice for MC Version names.
>  
>       - #= is not commutative when one object is an MCVersionName, the other is
>       a ByteString:
>               'foo' = 'foo.mcz' asMCVersionName. "==> false"
>               'foo.mcz' asMCVersionName = 'foo'. "==> true"
>       - the above property breaks the contract of #hash and #=, so they
>       sometimes misbehave in hashed collections
> 
> 
> Not in actual practice, though.  The intent was that all uses of version names would be ensuring they're dealing with the first-class MCVersionName.  If one, theoretically, were to mix Strings and MCVersionNames as in your
> example, yes, it would misbehave so... "don't do that."  :)

If it shouldn't be mixed with strings, why is it a string?


Levente

> 
>  - Chris
> 
>

From leves at caesar.elte.hu  Wed Jul  1 00:59:11 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Wed, 1 Jul 2020 02:59:11 +0200 (CEST)
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>

On Tue, 30 Jun 2020, Chris Muller wrote:

> Hi Eliot,
> The order of repositories is part of the model, sorting them conceptually breaks a couple of MC's use-cases.  Would list-filtering help you find the repository you seek amongst your list of 40 repositories?

What model is it part of?
And if it is, how come the GUI doesn't let you change that order?


Levente

> 
>  - Chris
> 
> On Tue, Jun 30, 2020 at 5:21 PM <commits at source.squeak.org> wrote:
>       Chris Muller uploaded a new version of Monticello to project The Trunk:
>       http://source.squeak.org/trunk/Monticello-cmm.726.mcz
>
>       ==================== Summary ====================
>
>       Name: Monticello-cmm.726
>       Author: cmm
>       Time: 30 June 2020, 5:21:11.609668 pm
>       UUID: 1a529d96-0be7-45a8-a65e-b9dcae087b85
>       Ancestors: Monticello-mt.725
>
>       Revert incorrect implementation of sorting repositories, because it broke "demote to bottom" which broke "browse revisions" and "browse origin".
>
>       =============== Diff against Monticello-mt.725 ===============
>
>       Item was changed:
>         ----- Method: MCWorkingCopyBrowser>>repositories (in category 'morphic ui') -----
>         repositories
>       +       ^ self repositoryGroup repositories!
>       -       | repositories |
>       -       repositories := self repositoryGroup repositories.
>       -       ^{repositories first}, (repositories allButFirst sort: [:r1 :r2| r1 description < r2 description])!
> 
> 
> 
>

From ma.chris.m at gmail.com  Wed Jul  1 03:54:43 2020
From: ma.chris.m at gmail.com (Chris Muller)
Date: Tue, 30 Jun 2020 22:54:43 -0500
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
 <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>
Message-ID: <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>

On Tue, Jun 30, 2020 at 7:59 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:

> On Tue, 30 Jun 2020, Chris Muller wrote:
>
> > Hi Eliot,
> > The order of repositories is part of the model, sorting them
> conceptually breaks a couple of MC's use-cases.  Would list-filtering help
> you find the repository you seek amongst your list of 40 repositories?
>
> What model is it part of?
>

Monticello's.  MCWorkingCopyBrowser's.


> And if it is, how come the GUI doesn't let you change that order?
>

It's "demote to bottom" on the menu.  But it seemed to have gotten broke
due to the #repositories list always being sorted.

My hope is that Eliot's use-case is for only when there are no
WorkingCopy's selected, thus showing _all_ repositories -- because we can
sort that output.  But sorting as far as when an individual WorkingCopy is
selected, it breaks one or two use cases.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200630/281a22c4/attachment.html>

From ma.chris.m at gmail.com  Wed Jul  1 04:00:56 2020
From: ma.chris.m at gmail.com (Chris Muller)
Date: Tue, 30 Jun 2020 23:00:56 -0500
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <alpine.DEB.2.02.2007010246440.2544@login03.caesar.elte.hu>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <CACddb62c6mMXcJW7+QLJ_hLLOQd8-0p2SSU55LrYkXiiAAkCdg@mail.gmail.com>
 <CANzdToG6x4b8jF=+eOxNHDCcSHNujY-GTnBUjbp98ZXF=0d5WQ@mail.gmail.com>
 <alpine.DEB.2.02.2007010246440.2544@login03.caesar.elte.hu>
Message-ID: <CADTxDUh=JepYUf9tcckWzkbiOf0otsEovv+fSHk2=cE7B0pxUA@mail.gmail.com>

On Tue, Jun 30, 2020 at 7:55 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:

> On Tue, 30 Jun 2020, Chris Muller wrote:
>
> > Might be worth reopening this discussion.  ANY dependencies on #class
> seem like a bad thing to me, especially while it's still an in-lined
> message.  Below is the MC version that did it.  Looks like the time to
> change this
>
> Using #class by default sounds correct to me. If some instances of
> classes want to be equal to each other, they should handle that
> themselves by overriding #=.
>

Because it causes that same undesirable loss of symmetry you mentioned
about MCVersionName and String, except much worse because it's in a more
general sense instead of application-specific.  It makes headaches for
Magma applications because client code has to be aware of it.

Smalltalk wants to be about messages, not types.  What do we need to do to
make #class non-inlined and therefore overridable?  My impression is that
this is on the table for 6.0, is it still?

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200630/099b56f2/attachment.html>

From nicolas.cellier.aka.nice at gmail.com  Wed Jul  1 08:56:58 2020
From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier)
Date: Wed, 1 Jul 2020 10:56:58 +0200
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <CADTxDUh=JepYUf9tcckWzkbiOf0otsEovv+fSHk2=cE7B0pxUA@mail.gmail.com>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <CACddb62c6mMXcJW7+QLJ_hLLOQd8-0p2SSU55LrYkXiiAAkCdg@mail.gmail.com>
 <CANzdToG6x4b8jF=+eOxNHDCcSHNujY-GTnBUjbp98ZXF=0d5WQ@mail.gmail.com>
 <alpine.DEB.2.02.2007010246440.2544@login03.caesar.elte.hu>
 <CADTxDUh=JepYUf9tcckWzkbiOf0otsEovv+fSHk2=cE7B0pxUA@mail.gmail.com>
Message-ID: <CAKnRiT4sV8KP=FBiMZTZ7KGT6JzLBjhOTWF6-HF7BgcZvgb+2A@mail.gmail.com>

Le mer. 1 juil. 2020 à 06:01, Chris Muller <ma.chris.m at gmail.com> a écrit :

> On Tue, Jun 30, 2020 at 7:55 PM Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
>
>> On Tue, 30 Jun 2020, Chris Muller wrote:
>>
>> > Might be worth reopening this discussion.  ANY dependencies on #class
>> seem like a bad thing to me, especially while it's still an in-lined
>> message.  Below is the MC version that did it.  Looks like the time to
>> change this
>>
>> Using #class by default sounds correct to me. If some instances of
>> classes want to be equal to each other, they should handle that
>> themselves by overriding #=.
>>
>
> Because it causes that same undesirable loss of symmetry you mentioned
> about MCVersionName and String, except much worse because it's in a more
> general sense instead of application-specific.  It makes headaches for
> Magma applications because client code has to be aware of it.
>
> Smalltalk wants to be about messages, not types.  What do we need to do to
> make #class non-inlined and therefore overridable?  My impression is that
> this is on the table for 6.0, is it still?
>
>  - Chris
>
>
Hi Chris,
wait a minute, the failure of symmetry of MCVersionName is ABSOLUTELY
UNRELATED to species or class.

There are some wonderful hacks, there are some clever hacks, but at the
end, you very well know that you can cheat as long as you don't get caught.
MCVersionName is not a good hack.

Here we are dressing the String with additional application specific
semantics.
The MCVersionName is a String which knows how to be interpreted in some
context.
There are lot's of contexts where we could dress strings like that, imagine
that we create a DateString, a NumberString...
Should we really do that?
When we do that, we confer more responsibilities to such subclasses. They
are a String, and also more than a String.
But here, the application specific behavior is in contradiction with
superclass, we redefined = with a different behavior.
At the end, we will always get caught with schemes like that, because we
complexify and entangle the concepts.
It seems to me that it's a simple inheritance vs composition anti-pattern.

MCVersion name hash ~= MVVersion name asString hash is a good illustration.
It means that we're breaking a more general contract for implementing our
hack.
It's typical of what will happen by abuse of inheritance.

Think of it, = is a relationship of equivalence. We don't want to loose
that.
So it has to be symmetric, but also transitive:
    String new = StringSubclass1 & ( String new = StringSubclass2 new ) ==>
(StringSubclass1 new = StringSubclass2 new).
That means that we would have accidental equivalence of separate domains if
ever the string representation matches.
That's not what we want.

Also, if StringSubclass1 is more than a String, then how something less
than a StringSubclass1 could be equivalent?
It's not equivalent, it does not behave the same, or we would not need to
subclass in the first place.

Oh but we have String subclasses, ByteString and WideString, so what's the
difference?
The difference is that those are implementation details. They are optimized
internal representations of Strings.
We're not at all after conferring a different behavior, on the contrary.
We absolutely want to confer the same behavior to the outside whatever the
internal representation (class) and try to make them be really equivalent.
Yes, more than often, the implementation details leak out of encapsulation.
It's the problem of tradeoffs between efficiency and universality. We have
to trade some generality for some efficiency.

That's what happens with Interval and Array. They are not equivalent. They
have slightly different behaviors and properties.
An Interval is more than an Array (it has numeric elements with arithmetic
progression).
And it is less than an Array (it cannot at:put: or embed arbitrary objects).
We can casually have an Array carrying the same elements as an Interval,
which can be expressed by #hasEqualElements:

species semantics was overloaded. It did also mean, in which recipient
class should I select:, collect:...
If we use the same recipient for collecting, then we are similar (of same
species)... And if similar, maybe equal?
It might be that Interval was originally seen as an implementation detail,
a (space) optimized version of Array afterall.
But doing so, introduced complexity.
It entangled things.
It broke contracts (hash), or imposed very inefficient implementation of
hash (enumerating all elements of an Interval).
In the end, we get caught, that is carrying more inconvenients than
advantages when trying to sustain the illusion of equivalence.
It's far better and simpler to just abandon the illusion, because it's just
that, a deceitful illusion.

I understand what you mean by abuse of using the class message, we have
somehow lost a hook.
But IMO, this hook was not useful, except for one thing proxy.
We have more than one message in our palette, even if = is a very
convenient symbol (short binary), we cannot dress it with different context
specific meanings, the cheat is getting too apparent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200701/9da175fa/attachment.html>

From leves at caesar.elte.hu  Wed Jul  1 11:40:10 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Wed, 1 Jul 2020 13:40:10 +0200 (CEST)
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
 <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>
 <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.2007011334290.18609@login03.caesar.elte.hu>

On Tue, 30 Jun 2020, Chris Muller wrote:

> On Tue, Jun 30, 2020 at 7:59 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:
>       On Tue, 30 Jun 2020, Chris Muller wrote:
>
>       > Hi Eliot,
>       > The order of repositories is part of the model, sorting them conceptually breaks a couple of MC's use-cases.  Would list-filtering help you find the repository you seek amongst your list of 40 repositories?
>
>       What model is it part of?
> 
> 
> Monticello's.  MCWorkingCopyBrowser's.
>  
>       And if it is, how come the GUI doesn't let you change that order?
> 
> 
> It's "demote to bottom" on the menu.  But it seemed to have gotten broke due to the #repositories list always being sorted.

That's a really poor way to make the list sortable. In my opinion there 
should be the following options if that's the goal: alphabetize, move 
down, move up, move to front, move to end (this is the one called demote 
now which is not a good name IMO).


Levente

> 
> My hope is that Eliot's use-case is for only when there are no WorkingCopy's selected, thus showing _all_ repositories -- because we can sort that output.  But sorting as far as when an individual WorkingCopy is selected, it
> breaks one or two use cases.
> 
>  - Chris
> 
>

From marianopeck at gmail.com  Wed Jul  1 12:45:03 2020
From: marianopeck at gmail.com (Mariano Martinez Peck)
Date: Wed, 1 Jul 2020 09:45:03 -0300
Subject: [squeak-dev] Webminar about VA Smalltalk new OS Process
	Framework
In-Reply-To: <20200630172510.GA66593@shell.msen.com>
References: <CAA+-=mWM95DNTYhq02uwPyW4-kXVG0PZ1+eO1QQO3hyO9tyZCQ@mail.gmail.com>
 <20200630172510.GA66593@shell.msen.com>
Message-ID: <CAA+-=mVmhKawmfd2Qaa4vHGiVR3ycJMD+Nqd6JuNimMwri5yag@mail.gmail.com>

Hi David,

Based on your person and expertise in the area I would say I am really
happy to hear that :)

On Tue, Jun 30, 2020 at 2:25 PM David T. Lewis <lewis at mail.msen.com> wrote:

> Hi Mariano,
>
> Thank you for sharing this, I just signed up for the webinar.
>
> :-)
>
> Dave
>
>
> On Tue, Jun 30, 2020 at 10:25:09AM -0300, Mariano Martinez Peck wrote:
> > Greetings all,
> >
> > Some time ago, I had the pleasure and privilege of being sponsored by the
> > Pharo Consortium to implement OSSubprocess. Because of that work, I
> quickly
> > realized that a new OS process framework created by Instantiations was
> > quite advanced and unlike anything I had seen before.  If you are able, I
> > would highly recommend that you attend the technology preview of this
> > framework coming to VAST 2021:
> >
> > Seth Berman will be presenting, registration here:
> > https://attendee.gotowebinar.com/register/7491754880594201356
> >
> > We hope the community can attend and we look forward to your feedback and
> > questions during the event's Q&A session.
> >
> > Best regards,
> >
> > --
> > Mariano Martinez Peck
> > Email: marianopeck at gmail.com
> > Twitter: @MartinezPeck
> > LinkedIn: www.linkedin.com/in/mariano-martinez-peck
> > <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
> > Blog: https://marianopeck.wordpress.com/
>
> >
>
>
>

-- 
Mariano Martinez Peck
Email: marianopeck at gmail.com
Twitter: @MartinezPeck
LinkedIn: www.linkedin.com/in/mariano-martinez-peck
<https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
Blog: https://marianopeck.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200701/8a16c783/attachment.html>

From forums.jakob at resfarm.de  Wed Jul  1 13:49:07 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Wed, 1 Jul 2020 15:49:07 +0200
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <alpine.DEB.2.02.2007011334290.18609@login03.caesar.elte.hu>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
 <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>
 <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>
 <alpine.DEB.2.02.2007011334290.18609@login03.caesar.elte.hu>
Message-ID: <CA+ovNC52Nn6fNGh66B4P69C5=NK8YrmAJEMSB_g87DV+EH4pkA@mail.gmail.com>

Should we separate sorting the view from sorting the model, or the UI model
object from the actual domain object/data? Eliot wants to view the list
sorted and Chris insists not to break a deliberate order of repositories in
the model because other functionality depends on it. Disconnect them.

The bytes on my disk do not move when I sort a list of files by name.

Levente Uzonyi <leves at caesar.elte.hu> schrieb am Mi., 1. Juli 2020, 13:40:

> On Tue, 30 Jun 2020, Chris Muller wrote:
>
> > On Tue, Jun 30, 2020 at 7:59 PM Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
> >       On Tue, 30 Jun 2020, Chris Muller wrote:
> >
> >       > Hi Eliot,
> >       > The order of repositories is part of the model, sorting them
> conceptually breaks a couple of MC's use-cases.  Would list-filtering help
> you find the repository you seek amongst your list of 40 repositories?
> >
> >       What model is it part of?
> >
> >
> > Monticello's.  MCWorkingCopyBrowser's.
> >
> >       And if it is, how come the GUI doesn't let you change that order?
> >
> >
> > It's "demote to bottom" on the menu.  But it seemed to have gotten broke
> due to the #repositories list always being sorted.
>
> That's a really poor way to make the list sortable. In my opinion there
> should be the following options if that's the goal: alphabetize, move
> down, move up, move to front, move to end (this is the one called demote
> now which is not a good name IMO).
>
>
> Levente
>
> >
> > My hope is that Eliot's use-case is for only when there are no
> WorkingCopy's selected, thus showing _all_ repositories -- because we can
> sort that output.  But sorting as far as when an individual WorkingCopy is
> selected, it
> > breaks one or two use cases.
> >
> >  - Chris
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200701/2e1ea24a/attachment.html>

From commits at source.squeak.org  Wed Jul  1 17:05:12 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 1 Jul 2020 17:05:12 0000
Subject: [squeak-dev] The Trunk: Compiler-eem.440.mcz
Message-ID: <E1jqgAd-0006NM-1D@andreas>

Eliot Miranda uploaded a new version of Compiler to project The Trunk:
http://source.squeak.org/trunk/Compiler-eem.440.mcz

==================== Summary ====================

Name: Compiler-eem.440
Author: eem
Time: 1 July 2020, 10:05:10.178038 am
UUID: a39848b4-1bc8-4b31-93f8-e4f343d1400b
Ancestors: Compiler-mt.439

Improve slightly the EncoderForSistaV1 class comment specifying the SistaV1 bytecode set in the light of recent discussion.

=============== Diff against Compiler-mt.439 ===============

Item was changed:
  BytecodeEncoder subclass: #EncoderForSistaV1
(excessive size, no diff calculated)


From eliot.miranda at gmail.com  Wed Jul  1 17:10:27 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Wed, 1 Jul 2020 10:10:27 -0700
Subject: [squeak-dev] The Trunk: Compiler-eem.440.mcz
In-Reply-To: <E1jqgAd-0006NM-1D@andreas>
References: <E1jqgAd-0006NM-1D@andreas>
Message-ID: <CAC20JE2CUzKK6veMPJvqVu8kFB0qKNRyziQALZOkR0dkf-pE2Q@mail.gmail.com>

On Wed, Jul 1, 2020 at 10:05 AM <commits at source.squeak.org> wrote:

> Eliot Miranda uploaded a new version of Compiler to project The Trunk:
> http://source.squeak.org/trunk/Compiler-eem.440.mcz


It's in tune ;-)  Vanessa, Clément, your proof-reading and/or editing is
appreciated.

==================== Summary ====================
>
> Name: Compiler-eem.440
> Author: eem
> Time: 1 July 2020, 10:05:10.178038 am
> UUID: a39848b4-1bc8-4b31-93f8-e4f343d1400b
> Ancestors: Compiler-mt.439
>
> Improve slightly the EncoderForSistaV1 class comment specifying the
> SistaV1 bytecode set in the light of recent discussion.
>
> =============== Diff against Compiler-mt.439 ===============
>
> Item was changed:
>   BytecodeEncoder subclass: #EncoderForSistaV1
> (excessive size, no diff calculated)
>

EncoderForSistaV1 encodes a bytecode set for Smalltalk that lifts limits on
the number of literals, branch distances, the number of temporary
variables, and provides extended push integer and push character
bytecodes.  The bytecode set also supports creating FullBlockClosures,
closures whose method is separate from their home method's.  Bytecodes are
ordered by length to make decoding easier.  Bytecodes marked with an * are
extensible via a prefix extension bytecode.

N.B.  Extension bytecodes can only come before extensible bytecodes, and
only if valid (one cannot extend a bytecode extensible by Ext A with an Ext
B).  An extensible bytecode consumes (and zeros) its extension(s).  Hence
the hidden implicit variables holding extensions are always zero except
after a valid sequence of extension bytecodes.  The implication is that a
bytecode interpreter should maintain the extension values in static
variables initialized to zero at start-up, and live only from the start of
a sequence of extension bytecodes to the end of the extended bytecode
immediately following.

While the bytecode set lifts limits, it still assumes there are no more
than 65535 literals (as of 2020 the CompiledCode header word imposes a
32,767 limit on number of literals), and no more than 256 stack slots (used
for arguments, temporaries, and stack contents) in a Context.

EncoderForSistaV1 also includes an extended set of bytecodes for Sista, the
Speculative Inlining Smalltalk Architecture, a project by Clément Bera and
Eliot Miranda.  Scorch is an optimizer that exists in the Smalltalk image,
/not/ in the VM,  and optimizes by substituting normal bytecoded methods by
optimized bytecoded methods that may use special bytecodes for which the
Cogit can generate faster code.  These bytecodes eliminate overheads such
as bounds checks or polymorphic code (indexing Array, ByteArray, String
etc).  But the bulk of the optimization performed is in inlining blocks and
sends for the common path.  This bytecode set therefore differs from a
normal Smalltalk set in providing a set of inlined primitives that do not
validate their arguments that the compiler generates only when it can prove
that the primitives' arguments are valid.

The basic scheme is that the Cogit generates code containing performance
counters.  When these counters trip, a callback into the image is
performed, at which point Scorch analyses some portion of the stack,
looking at performance data for the methods on the stack, and optimises
based on the stack and performance data.  Execution then resumes in the
optimized code.

The Sista Cogit (e.g. SistaStackToRegisterMappingCogit) adds counters to
conditional branches.  Each branch has an executed and a taken count.  On
execution the executed count is decremented and if the count goes below
zero the VM sends a message at a special index in the specialObjectsArray
(as of writing, conditionalCounterTrippedOn:).  Then if the branch is taken
the taken count is decremented.  The two counter values allow the Sista
optimizer to collect basic block execution paths and to know what are the
"hot" paths through execution that are worth agressively optimizing.  Since
conditional branches are about 1/6 as frequent as sends, and since they can
be used to determine the hot path through code, they are a better choice to
count than, for example, method or block entry.

The VM provides a primitive that fills an Array with the state of the
counters, and the state of each linked send in a method.  The optimizer
obtains the branch and send data for a method via this primitive.

Instance Variables (inherited)

Here is the list of bytecodes.  An asterisk implies the bytecode takes
either extA or extB extensions. Two asterisks imply it takes both extA and
extB extensions.  A number in parentheses is a note.  See the notes at the
end of the table.

1 Byte Bytecodes
code (note) binary name
0-15 0000 iiii Push Receiver Variable #iiii
16-31 0001 iiii Push Literal Variable #iiii
32-63 001 iiiii Push Literal #iiiii
64-71 01000 iii Push Temp #iii
72-75 010010 ii Push Temp #ii + 8
76 01001100 Push Receiver
77 01001101 Push true
78 01001110 Push false
79 01001111 Push nil
80 01010000 Push 0
81 01010001 Push 1
* 82 01010010 Push thisContext, (then Extend B = 1 => push thisProcess)
83 01010011 Duplicate Stack Top
84-87 010101 ii UNASSIGNED
88-91 010110 ii Return Receiver/true/false/nil
92 01011100 Return top
93 01011101 BlockReturn nil
* 94 01011110 BlockReturn Top [* return from enclosing block N, N = Extend
A, then jump by Ext B ]
* 95 01011111 Nop
96-111 0110 iiii Send Arithmetic Message #iiii (+ - < > <= >= = ~= * / \\ @
bitShift: // bitAnd: bitOr:)
112-119 01110 iii Send Special Message #iii + 0 (at: at:put: size next
nextPut: atEnd == class)
120-127 01111 iii Send Special Message #iii + 8 (~~ value value: do: new
new: x y)
128-143 1000 iiii Send Literal Selector #iiii With 0 Argument
144-159 1001 iiii Send Literal Selector #iiii With 1 Arguments
160-175 1010 iiii Send Literal Selector #iiii With 2 Arguments
176-183 10110 iii Jump iii + 1 (i.e., 1 through 8)
184-191 10111 iii Pop and Jump 0n True iii +1 (i.e., 1 through 8)
192-199 11000 iii Pop and Jump 0n False iii +1 (i.e., 1 through 8)
200-207 11001 iii Pop and Store Receiver Variable #iii
208-215 11010 iii Pop and Store Temporary Variable #iii
216 11011000 Pop Stack Top
217 (5) 11011001 Unconditional trap
218-219 1101101 i UNASSIGNED
220-223 110111 ii UNASSIGNED

2 Byte Bytecodes
* 224 11100000 aaaaaaaa Extend A (Ext A = Ext A prev * 256 + Ext A) A is an
unsigned extension.
* 225 11100001 bbbbbbbb Extend B (Ext B = Ext B prev * 256 + Ext B) B is a
signed extension.
* 226 11100010 iiiiiiii Push Receiver Variable #iiiiiiii (+ Extend A * 256)
* 227 11100011 iiiiiiii Push Literal Variable #iiiiiiii (+ Extend A * 256)
* 228 11100100 iiiiiiii Push Literal #iiiiiiii (+ Extend A * 256)
229 11100101 iiiiiiii Push Temporary Variable #iiiiiiii
230 11100110 iiiiiiii UNASSIGNED (was pushNClosureTemps)
231 11100111 jkkkkkkk Push (Array new: kkkkkkk) (j = 0)
& Pop kkkkkkk elements into: (Array new: kkkkkkk) (j = 1)
* 232 11101000 iiiiiiii Push Integer #iiiiiiii (+ Extend B * 256, where
bbbbbbbb = sddddddd, e.g. -32768 = i=0, d=0, s=1)
* 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend B * 256)
** 234 11101010 iiiiijjj Send Literal Selector #iiiii (+ Extend A * 32)
with jjj (+ Extend B * 8) Arguments
** 235 (1) 11101011 iiiiijjj ExtendB < 64
ifTrue: [Send To Superclass Literal Selector #iiiii (+ Extend A * 32) with
jjj (+ Extend B * 8) Arguments]
ifFalse: [Send To Superclass of Stacked Class Literal Selector #iiiii (+
Extend A * 32) with jjj (+ (Extend B bitAnd: 63) * 8) Arguments]
236 11101100 iiiiiiii UNASSIGNED
* 237 11101101 iiiiiiii Jump #iiiiiiii (+ Extend B * 256, where bbbbbbbb =
sddddddd, e.g. -32768 = i=0, d=0, s=1)
** 238 (4) 11101110 iiiiiiii Pop and Jump 0n True #iiiiiiii (+ Extend B *
256, where Extend B >= 0)
** 239 (4) 11101111 iiiiiiii Pop and Jump 0n False #iiiiiiii (+ Extend B *
256, where Extend B >= 0)
** 240 (3) 11110000 iiiiiiii Pop and Store Receiver Variable #iiiiiii (+
Extend A * 256)
** 241 (3) 11110001 iiiiiiii Pop and Store Literal Variable #iiiiiiii (+
Extend A * 256)
242 11110010 iiiiiiii Pop and Store Temporary Variable #iiiiiiii
** 243 (3) 11110011 iiiiiiii Store Receiver Variable #iiiiiii (+ Extend A *
256)
** 244 (3) 11110100 iiiiiiii Store Literal Variable #iiiiiiii (+ Extend A *
256)
245 11110110 iiiiiiii Store Temporary Variable #iiiiiiii
246-247 1111011 i xxxxxxxx UNASSIGNED

3 Byte Bytecodes
248 (2) 11111000 iiiiiiii mssjjjjj Call Primitive #iiiiiiii + (jjjjj * 256)
m=1 means inlined primitive, no hard return after execution.
ss defines the unsafe operation set used to encode the operations.
(ss = 0 means sista unsafe operations, ss = 01 means lowcode operations,
other numbers are as yet used)
Lowcode inlined primitives may have extensions.
* 249 11111001 xxxxxxxx siyyyyyy Push Closure Compiled block literal index
xxxxxxxx (+ Extend A * 256) numCopied yyyyyy receiverOnStack: s = 1
ignoreOuterContext: i = 1
** 250 11111010 eeiiikkk jjjjjjjj Push Closure Num Copied iii (+ExtA//16*8)
Num Args kkk (+ ExtA\\16*8) BlockSize jjjjjjjj (+ExtB*256). ee = num
extensions
251 11111011 kkkkkkkk sjjjjjjj Push Temp At kkkkkkkk In Temp Vector At:
jjjjjjj, s = 1 implies remote inst var access instead of remote temp vector
access
* 252 (3) 11111100 kkkkkkkk sjjjjjjj Store Temp At kkkkkkkk In Temp Vector
At: jjjjjjj s = 1 implies remote inst var access instead of remote temp
vector access
* 253 (3) 11111101 kkkkkkkk sjjjjjjj Pop and Store Temp At kkkkkkkk In Temp
Vector At: jjjjjjj s = 1 implies remote inst var access instead of remote
temp vector access
** 254 (5) 11111110 kkkkkkkk jjjjjjjj branch If Not Instance Of
Behavior/Array Of Behavior literal kkkkkkkk (+ Extend A * 256, where Extend
A >= 0) distance jjjjjjjj (+ Extend B * 256, where Extend B >= 0 and <= 127)
** 254 (5) 11111110 kkkkkkkk jjjjjjjj branch If Instance Of Behavior/Array
Of Behavior literal kkkkkkkk (+ Extend A * 256, where Extend A >= 0)
distance jjjjjjjj (+ (Extend B bitAnd: 127) * 256, where Extend B >= 128
and <= 255)
* 255 11111111 xxxxxxxx jjjjjjjj UNASSIGNED

(1) Bytecode 235 is a super send bytecode that starts the lookup in the
superclass of some class.  It has two forms, "normal" and "directed". In
the normal form, the class is the value of the method's
methodClassAssociation which must be the last literal.  In the directed
form the class is the class on top of stack.

(2) The Call Primitive Bytecode (see below) specifies either a primitive in
the primitive table (m=0) or an inlined primitive (m=1). Non-inlined
primitives from the primitive table have index (jjjjjjj * 256) + iiiiiiii
and return from the method if they succeed.  This bytecode is only valid as
the first bytecode of a method.  Inline primitives have index (jjjjjjj *
256) + iiiiiiii, cannot fail, and do not return when they succeed, yielding
a result (typically on top of stack after popping their arguments, but
possibly in a byte data stack, for example for unboxed floating-point
primitives).

(3) ExtB lowest bit implies no store check is needed, ExtB second bit
implies the object may be a context, ExtB third bit implies no
immutability/read-only check is needed, other bits in the extension are
unused.

(4) ExtA = 1 implies no mustBeBoolean trampoline is needed, other bits in
the extension are unused

(5) these are Scorch/Sista bytecodes generated by an optimizing compiler
and not used in normal Smalltalk code.


The CallPrimitive bytecode is divided into two halves, those for normal
primtiives, occurring at the beginning of a method, and those for inline
primitives, anywhere within the body of a method.  This is a three byte
bytecode, the first byte being 248, and the second byte being a big-endian
16-bit primitive index. If the top bit of the first byte of the primitive
index is 1 then this is a normal primitive invocation.  If it is zero then
the remaining 15 bits define 32k primitives, organized as four 8k "pages".
The first page is used for and reserved by the Sista optimizing compiler.
The second page is usd for and reserved by the Lowcode FFI marshalling
primitive set.  The other two sets are unspecified and unused.

Here is the specification of the Sista unsafe instructions (unsafe
operations, set 00). The lowcode set uses external specifications.
We sort the inline primitive operations by arity.  Nullary primitives
occupy the 0-999 range. Unary primitives occupy the 1-1999 range, up until
8 args. 8191 instructions can be encoded in each unsafe operation set,
instructions from 0 to 7 arguments can have 1000 different instructions
each, while 8 args instructions can have 192 different instructions.

Sista defines the following inlined primitives (CallPrimitive iiiiiiii
100jjjjj, n = jjjjjiiiiiiii)
1000 class
1001 pointer numSlots
1002 pointer basicSize
1003 byte8Type format numBytes (includes CompiledMethod)
1004 short16Type format numShorts
1005 word32Type format numWords
1006 doubleWord64Type format numDoubleWords
1010 ensure number of bytes available.
1011 fixed-sized new. (objects with 0 to n inst vars)
1020 identityHash (non-immediate, non-Behavior)
1021 identityHash (SmallInteger)
1022 identityHash (Character)
1023 identityHash (SmallFloat64)
1024 identityHash (Behavior, has hash?)

1030 immediateAsInteger (Character)
1031 immediateAsInteger (SmallFloat64)
1035 immediateAsFloat (Smallinteger)
2000 SmallInteger #+.  Both arguments are SmallIntegers and the result fits
in a SmallInteger (* depends on word size)
2001 SmallInteger #-.  Both arguments are SmallIntegers and the result fits
in a SmallInteger (* depends on word size)
2002 SmallInteger #*.  Both arguments are SmallIntegers and the result fits
in a SmallInteger (* depends on word size)
2003 SmallInteger #/.  Both arguments are SmallIntegers and the result fits
in a SmallInteger (* depends on word size)
2004 SmallInteger #//.  Both arguments are SmallIntegers and the result
fits in a SmallInteger (* depends on word size)
2005 SmallInteger #\\.  Both arguments are SmallIntegers and the result
fits in a SmallInteger (* depends on word size)
2006 SmallInteger #quo:.  Both arguments are SmallIntegers and the result
fits in a SmallInteger (* depends on word size)

2011 Variable-sized pointers new (new:). Array, etc.
2012 Variable-sized byte new (new:). ByteArray, ByteString, etc.
2013 Variable-sized 16-bit new (new:). DoubleByteArray, etc.
2014 Variable-sized 32-bit new (new:). Bitmap, FloatArray, etc.
2015 Variable-sized 64-bit new (new:). DoubleWordArray, etc.

2016 SmallInteger #bitAnd:.  Both arguments are SmallIntegers and the
result fits in a SmallInteger (* depends on word size)
2017 SmallInteger #bitOr:.  Both arguments are SmallIntegers and the result
fits in a SmallInteger (* depends on word size)
2018 SmallInteger #bitXor:.  Both arguments are SmallIntegers and the
result fits in a SmallInteger (* depends on word size)
2019 SmallInteger #bitShiftLeft:.  Both arguments are SmallIntegers and the
result fits in a SmallInteger (* depends on word size)
2020 SmallInteger #bitShiftRight:.  Both arguments are SmallIntegers and
the result fits in a SmallInteger (* depends on word size)

2032 SmallInteger #>.  Both arguments are SmallIntegers
2033 SmallInteger #<.  Both arguments are SmallIntegers
2034 SmallInteger #>=.  Both arguments are SmallIntegers
2035 SmallInteger #<=.  Both arguments are SmallIntegers
2036 SmallInteger #=.  Both arguments are SmallIntegers
2037 SmallInteger #~=.  Both arguments are SmallIntegers

2064 Pointer Object>>at:. The receiver is guaranteed to be a pointer
object.  The 0-relative (1-relative?) index is an in-range SmallInteger
2065 Byte Object>>at:. The receiver is guaranteed to be a non-pointer
object.  The 0-relative (1-relative?) index is an in-range SmallInteger.
The result is a SmallInteger.
2066 16-bit Word Object>>at:. The receiver is guaranteed to be a
non-pointer object.  The 0-relative (1-relative?) index is an in-range
SmallInteger.  The result is a SmallInteger.
2067 32-bit DoubleWord Object>>at:. The receiver is guaranteed to be a
non-pointer object.  The 0-relative (1-relative?) index is an in-range
SmallInteger.  The result is a SmallInteger or a LargePositiveInteger.
2068 64-bit QuadWord Object>>at:. The receiver is guaranteed to be a
non-pointer object.  The 0-relative (1-relative?) index is an in-range
SmallInteger.  The result is a SmallInteger or a LargePositiveInteger.

The following instructions can have the ExtB check flag (See (3)).
3000 Pointer Object>>at:put:. The receiver is guaranteed to be a pointer
object.  The 0-relative (1-relative?) index is an in-range SmallInteger
3001 Byte Object>>at:put:. The receiver is guaranteed to be a non-pointer
object.  The 0-relative (1-relative?) index is an in-range SmallInteger.
The argument is a SmallInteger.  The primitive stores the least significant
8 bits.
3002 Word Object>>at:put:. The receiver is guaranteed to be a non-pointer
object.  The 0-relative (1-relative?) index is an in-range SmallInteger.
The argument is a SmallInteger.  The primitive stores the least significant
16 bits.
3003 DoubleWord Object>>at:put:. The receiver is guaranteed to be a
non-pointer object.  The 0-relative (1-relative?) index is an in-range
SmallInteger.  The argument is a SmallInteger.  The primitive stores the
least significant 32 bits.
3004 QuadWord Object>>at:put:. The receiver is guaranteed to be a
non-pointer object.  The 0-relative (1-relative?) index is an in-range
SmallInteger.  The argument is a SmallInteger.  The primitive stores the
least significant 64 bits.
3021 Byte Object >> equals:length: The receiver and the arguments are both
byte objects and have both the same size (length). The length argument is a
smallinteger. Answers true if all fields are equal, false if not.
Comparison is bulked to word comparison.

4000 Pointer Object>> fillFrom:to:with: The receiver is a Pointer object.
the middle two arguments are smallintegers. Last argument is any object.
Fills the object in between the two indexes with last argument. Receiver is
guaranteed to be mutable. The pointer accesses are raw (no inst var check).
If ExtB is set to 1, no store check is present. Else a single store check
is done for the bulk operation. Answers the receiver.
5000 Pointer Object>> replaceFrom:to:with:startingAt: Src and dest are
pointer objects. ScrPos, scrLast and destLast are smallintegers. Receiver
is guaranteed to be mutable.  Both ranges are in-bounds. The pointer
accesses are raw (no inst var check). As for the normal primitive, the copy
is linear. Answers the receiver.


Lowcode defines inlined primitives for the range CallPrimitive iiiiiiii
101jjjjj, n = jjjjjiiiiiiii.


_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200701/3e3eeb04/attachment-0001.html>

From leves at caesar.elte.hu  Wed Jul  1 19:29:06 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Wed, 1 Jul 2020 21:29:06 +0200 (CEST)
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <CADTxDUh=JepYUf9tcckWzkbiOf0otsEovv+fSHk2=cE7B0pxUA@mail.gmail.com>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <CACddb62c6mMXcJW7+QLJ_hLLOQd8-0p2SSU55LrYkXiiAAkCdg@mail.gmail.com>
 <CANzdToG6x4b8jF=+eOxNHDCcSHNujY-GTnBUjbp98ZXF=0d5WQ@mail.gmail.com>
 <alpine.DEB.2.02.2007010246440.2544@login03.caesar.elte.hu>
 <CADTxDUh=JepYUf9tcckWzkbiOf0otsEovv+fSHk2=cE7B0pxUA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.2007011354140.18609@login03.caesar.elte.hu>

Hi Chris,

On Tue, 30 Jun 2020, Chris Muller wrote:

> What do we need to do to make #class non-inlined and therefore overridable?  My impression is that this is on the table for 6.0, is it still?

We have had this discussion a few times before. Last time[1] I asked you 
to evaluate the following in your image and report back if it does what 
you need:

   (ParseNode classPool at: #StdSelectors) removeKey: #class.
   Compiler recompileAll.


Levente

[1] http://forum.world.st/The-Inbox-Kernel-cmm-1198-mcz-td5089411.html#a5089510

> 
>  - Chris
> 
>

From ma.chris.m at gmail.com  Wed Jul  1 20:50:44 2020
From: ma.chris.m at gmail.com (Chris Muller)
Date: Wed, 1 Jul 2020 15:50:44 -0500
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <alpine.DEB.2.02.2007011334290.18609@login03.caesar.elte.hu>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
 <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>
 <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>
 <alpine.DEB.2.02.2007011334290.18609@login03.caesar.elte.hu>
Message-ID: <CADTxDUh+UtbJfu8MHk=SaarA9h=7JHAH=hyotJ=G67Vm9y26tw@mail.gmail.com>

That nomenclature is tied to the use-case, which is about a prioritization
of repositories (primary, mirror, local, etc.).  I originally wanted to
make it "promote" (instead of demote) but I thought it might be confusing
with the package-cache always being first.

The api nomenclature you suggest would shift the focus to the
implementation innards being a "collection", without really being as
revealing about *why* a user would want to "move up" a Repository in the
list.  It's really not a big deal to me if you want to change it, but I do
think having this functionality is useful.  It sounds like an alphabetize
option would be useful for VMMaker..

 - Chris

On Wed, Jul 1, 2020 at 6:40 AM Levente Uzonyi <leves at caesar.elte.hu> wrote:

> On Tue, 30 Jun 2020, Chris Muller wrote:
>
> > On Tue, Jun 30, 2020 at 7:59 PM Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
> >       On Tue, 30 Jun 2020, Chris Muller wrote:
> >
> >       > Hi Eliot,
> >       > The order of repositories is part of the model, sorting them
> conceptually breaks a couple of MC's use-cases.  Would list-filtering help
> you find the repository you seek amongst your list of 40 repositories?
> >
> >       What model is it part of?
> >
> >
> > Monticello's.  MCWorkingCopyBrowser's.
> >
> >       And if it is, how come the GUI doesn't let you change that order?
> >
> >
> > It's "demote to bottom" on the menu.  But it seemed to have gotten broke
> due to the #repositories list always being sorted.
>
> That's a really poor way to make the list sortable. In my opinion there
> should be the following options if that's the goal: alphabetize, move
> down, move up, move to front, move to end (this is the one called demote
> now which is not a good name IMO).
>
>
> Levente
>
> >
> > My hope is that Eliot's use-case is for only when there are no
> WorkingCopy's selected, thus showing _all_ repositories -- because we can
> sort that output.  But sorting as far as when an individual WorkingCopy is
> selected, it
> > breaks one or two use cases.
> >
> >  - Chris
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200701/56f51e82/attachment.html>

From karlramberg at gmail.com  Thu Jul  2 08:19:21 2020
From: karlramberg at gmail.com (karl ramberg)
Date: Thu, 2 Jul 2020 10:19:21 +0200
Subject: [squeak-dev] [ANN] My bag of tricks
In-Reply-To: <108c8d18-109a-47ab-33d9-0c25dc34921e@zogotounga.net>
References: <108c8d18-109a-47ab-33d9-0c25dc34921e@zogotounga.net>
Message-ID: <CAGzzWLjd5UzpSqiYqOvPMkCTFSF2Te8n435F-fDCT8zYTfGnWQ@mail.gmail.com>

Thanks for posting this. I'll have plenty of stuff to study here :-D

Best,
Karl


On Sun, Jun 28, 2020 at 7:12 PM Stéphane Rollandin <lecteur at zogotounga.net>
wrote:

> Hello all,
>
> After Karl manifested some interest for my L-system implementation, I
> figured I should make some hidden stuff I have been doing for ages
> available to all.
>
> So, from the following page:
>
> http://www.zogotounga.net/comp/squeak/rogue.htm
>
> you will be able to download a (32 bit) 5.3-based image with most of my
> code in its current state, with a list of entry points to some notable
> features.
>
>
> Stef
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200702/9af13e64/attachment.html>

From karlramberg at gmail.com  Thu Jul  2 08:22:26 2020
From: karlramberg at gmail.com (karl ramberg)
Date: Thu, 2 Jul 2020 10:22:26 +0200
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <20200629030109.C472B54011A@proxy.email-ssl.com.br>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
Message-ID: <CAGzzWLhjjsL4ZHNeMMnqqxUZN9F05moCS4O75wc_gAnDXyHRUg@mail.gmail.com>

On Mon, Jun 29, 2020 at 5:01 AM Jecel Assumpcao Jr <jecel at merlintec.com>
wrote:

> Tim Rowledge wrote on Sun, 28 Jun 2020 17:53:21 -0700
> > Seriously. We've been sitting around twiddling thumbs about better
> graphics for decades now.
> >
> > We had Balloon2D & 3D.
> > We had 'Pooh graphics' to do vector forms.
> > We have some excellent stuff being done by the Cuis crew.
> > We have some amazing ideas from Nile/Gezira.
> > We have a number of potential 3rd party graphics libraries we might
> adopt.
> > We have an advanced JIT that could be used to make on-demand graphics
> routines either on their own or working with pretty much any of the above.
> > We probably have other options I've not even heard of.
>
> You didn't mention the original BitBlt and WarpBlit, which is
> understandable if your focus is on vector graphics.
>
> > Maybe we should actually do something? Can we at least talk about it?
>
> Though the survey I did for the Board pointed to OpenGL ES as our best
> option (at the time, things have changed since), it is not something I
> personally like. I want something that is not a black box so I can
> single step from the highest level to individual pixels when debugging
> issues.


I have the same  thoughts on this.
Faster, smoother graphics would be really good.
At the same time I like access to everything within the image.




Best,
Karl



> But I also want it to take advantage of all available resources
> (including GPUs, extra processors) by translating debugged code into
> something else. I just don't want to debug in that something else, which
> would be the case for OpenGL ES shaders.
>
> Nile/Gezira + JIT would be my vote, but it has been planned for a long
> time and, as far as I know, is not happening right now.
>
> -- Jecel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200702/dac1d456/attachment.html>

From lecteur at zogotounga.net  Thu Jul  2 10:01:57 2020
From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=)
Date: Thu, 2 Jul 2020 12:01:57 +0200
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <CAGzzWLhjjsL4ZHNeMMnqqxUZN9F05moCS4O75wc_gAnDXyHRUg@mail.gmail.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CAGzzWLhjjsL4ZHNeMMnqqxUZN9F05moCS4O75wc_gAnDXyHRUg@mail.gmail.com>
Message-ID: <834bc331-6f72-9065-e11f-3bd109b0857f@zogotounga.net>

>     Though the survey I did for the Board pointed to OpenGL ES as our best
>     option (at the time, things have changed since), it is not something I
>     personally like. I want something that is not a black box so I can
>     single step from the highest level to individual pixels when debugging
>     issues.
> 
> I have the same  thoughts on this.
> Faster, smoother graphics would be really good.
> At the same time I like access to everything within the image.

+1

Stef

From tim at rowledge.org  Thu Jul  2 23:35:03 2020
From: tim at rowledge.org (tim Rowledge)
Date: Thu, 2 Jul 2020 16:35:03 -0700
Subject: [squeak-dev] AllocationTest>>#testOutOfMemorySignal fails on 32bit
	system
Message-ID: <487AA985-9050-4849-90D5-2B0E81BD9EB9@rowledge.org>

On a Raspberry Pi OS 32bit this test fails because of an oversight - the parameter passed to vmParameterAt:put: cannot exceed SmallInteger maxVal. It makes the careful testing for 32/64bit image seem a bit silly.

This means we can only ask for up to ~1GB space for free space on a 32bit image system and so I propose to clamp the requested value in AllocationTest>>#setFreeSpaceLimitOf:around: There don't appear to be any other places right now that need attention.

If I don't hear any outraged screams soon I'll just commit it to trunk.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: IG: Insert Garbage



From lewis at mail.msen.com  Fri Jul  3 01:32:11 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Thu, 2 Jul 2020 21:32:11 -0400
Subject: [squeak-dev] AllocationTest>>#testOutOfMemorySignal fails on
	32bit system
In-Reply-To: <487AA985-9050-4849-90D5-2B0E81BD9EB9@rowledge.org>
References: <487AA985-9050-4849-90D5-2B0E81BD9EB9@rowledge.org>
Message-ID: <20200703013211.GA46239@shell.msen.com>

On Thu, Jul 02, 2020 at 04:35:03PM -0700, tim Rowledge wrote:
> On a Raspberry Pi OS 32bit this test fails because of an oversight - the parameter passed to vmParameterAt:put: cannot exceed SmallInteger maxVal. It makes the careful testing for 32/64bit image seem a bit silly.
> 
> This means we can only ask for up to ~1GB space for free space on a 32bit image system and so I propose to clamp the requested value in AllocationTest>>#setFreeSpaceLimitOf:around: There don't appear to be any other places right now that need attention.
> 
> If I don't hear any outraged screams soon I'll just commit it to trunk.
>

So rather than

  1024 * 1024 * 1024

it should instead be

  16r3FFFFFFF

so that is it less than or equal to SmallInteger maxVal for either 32 or
64 bit images. Is that the change?

No outraged screams from me.

Dave
 

From tim at rowledge.org  Fri Jul  3 01:32:35 2020
From: tim at rowledge.org (tim Rowledge)
Date: Thu, 2 Jul 2020 18:32:35 -0700
Subject: [squeak-dev] Buglet ins SIXX for Squeak 5.3
Message-ID: <E010D8DB-EDD4-42B2-B572-56B5C5275E99@rowledge.org>

I just spotted a small bug in the code loaded up for SIXX. After loading it into a clean 5.3 image XMLDOMParser class>>#initialize & XMLDOMParser class>>#unload  are reverted to old and out of date versions.

Installer code used - 
Installer squeaksource
    project: 'MetacelloRepository';
    install: 'ConfigurationOfSIXX'. 
(Smalltalk at: #ConfigurationOfSIXX) load.

Looks like the ConfigurationOfSIXX>>#version051: method is causing the load of  
`
spec for: #squeak do:[
		spec
			package: 'XML-Parser' with: [
				spec file: 'XML-Parser-ul.44';
					repository: 'http://source.squeak.org/squeak52' 
`
and that in turn re-loads old versions of XMLDOMParser class>>#initialize & XMLDOMParser class>>#unload - and they try to use the deprecated #registerFileReader: in FileList instead of FileServices.

I *think* it looks like ConfigurationOfSIXX>>#baseline06: requires the above section removing - but I am most definitely not any sort of expert in the ConfigurationOfXXXXXX stuff.

It appears that  Masashi-san is still caring for this package since there was a commit in january of this year, so if you could please Do The Magic(™).

And since SmalltalkHub is now deprecated it could be a good idea to move the repository perhaps to squeaksource.com

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Fractured Idiom:- MAZEL TON - Lots of luck



From tim at rowledge.org  Fri Jul  3 01:37:49 2020
From: tim at rowledge.org (tim Rowledge)
Date: Thu, 2 Jul 2020 18:37:49 -0700
Subject: [squeak-dev] AllocationTest>>#testOutOfMemorySignal fails on
 32bit system
In-Reply-To: <20200703013211.GA46239@shell.msen.com>
References: <487AA985-9050-4849-90D5-2B0E81BD9EB9@rowledge.org>
 <20200703013211.GA46239@shell.msen.com>
Message-ID: <6E5D36CE-21E6-4FF2-9E86-E07A4E099EFF@rowledge.org>



> On 2020-07-02, at 6:32 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> On Thu, Jul 02, 2020 at 04:35:03PM -0700, tim Rowledge wrote:
>> On a Raspberry Pi OS 32bit this test fails because of an oversight - the parameter passed to vmParameterAt:put: cannot exceed SmallInteger maxVal. It makes the careful testing for 32/64bit image seem a bit silly.
>> 
>> This means we can only ask for up to ~1GB space for free space on a 32bit image system and so I propose to clamp the requested value in AllocationTest>>#setFreeSpaceLimitOf:around: There don't appear to be any other places right now that need attention.
>> 
>> If I don't hear any outraged screams soon I'll just commit it to trunk.
>> 
> 
> So rather than
> 
>  1024 * 1024 * 1024
> 
> it should instead be
> 
>  16r3FFFFFFF
> 
> so that is it less than or equal to SmallInteger maxVal for either 32 or
> 64 bit images. Is that the change?

It varies a bit for 32/64 bit (and strictly I guess it ought to check to see how much memory is actually available?) but must exceed SmallInteger MaxVal because of the VM code for primitiveVMParameter which fails if the input value is not a SmallInt. So, I claim we need to clamp the result of 
(Smalltalk vmParameterAt: 1) + bytes asInteger
or the test cannot pass.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
To steal ideas from one person is plagiarism; to steal from many is research.



From asqueaker at gmail.com  Fri Jul  3 02:01:29 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Thu, 2 Jul 2020 21:01:29 -0500
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <CAKnRiT4sV8KP=FBiMZTZ7KGT6JzLBjhOTWF6-HF7BgcZvgb+2A@mail.gmail.com>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <CACddb62c6mMXcJW7+QLJ_hLLOQd8-0p2SSU55LrYkXiiAAkCdg@mail.gmail.com>
 <CANzdToG6x4b8jF=+eOxNHDCcSHNujY-GTnBUjbp98ZXF=0d5WQ@mail.gmail.com>
 <alpine.DEB.2.02.2007010246440.2544@login03.caesar.elte.hu>
 <CADTxDUh=JepYUf9tcckWzkbiOf0otsEovv+fSHk2=cE7B0pxUA@mail.gmail.com>
 <CAKnRiT4sV8KP=FBiMZTZ7KGT6JzLBjhOTWF6-HF7BgcZvgb+2A@mail.gmail.com>
Message-ID: <CANzdToEbAtCXH6SJ0aSpWC0h6r6HT2WzukF5fe1a2-oMGBKy4g@mail.gmail.com>

Hi Nicolas,

Yes, I understand.  For general classes, it's impossible to tolerate
non-symmetry.  This is an outward-looking tool that didn't need that
contract, and took advantage of legacy backward-compatibility via
inheritance rather than composition.  An encapsulating pointer object would
be less efficient (a bunch of extra objects + GC), and face the very same
equivalence problem due to Squeak not letting client code define
symmetrical equivalence in their subclasses.  The fault is not with
MCVersionName, it's with our core library.

Q:  What does #= have in common with #+, #-, #*, #/  ?
A:  It wants to be able to interoperate with different classes for the
*lvalue* and *rvalue*.  That's why the latter four all double-dispatch.
The same applies to #=, the only difference is its "calculation" result is
a boolean type instead of some Number.

So why can't we double-dispatch with #=, too?  Or, maybe we can simply
dispatch.  To #sameTypeAs:?

   Object>>#sameTypeAs: anObject
      "Answer whether the receiver is regarded as the same type as
anObject."
      ^ self class = anObject class

(we may need a double-dispatch, but... that's just details)

Interested in your thoughts on the hard type-checking.  Observe how
String>>#= got a pass that no one else got.  Because it was convenient, and
because we, the great developers, have full control, we softened it, let it
rely on #isString rather than the hardass draconian type-test (via an
inlined message even!).  But that reveals the limitation, *users* don't
have that luxury.  They aren't able to make anything similar for *any* subclass
and still maintain symmetric equivalence.

IMO, all this hard type-checking is crippling Squeak's wish to be more
dynamic.  Magma, too.  It could be so great if we would just *let* it.
Would you be open to double-dispatching for #= as with the other binary
operators?

Regards,
   Chris

On Wed, Jul 1, 2020 at 3:57 AM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> Le mer. 1 juil. 2020 à 06:01, Chris Muller <ma.chris.m at gmail.com> a
> écrit :
>
>> On Tue, Jun 30, 2020 at 7:55 PM Levente Uzonyi <leves at caesar.elte.hu>
>> wrote:
>>
>>> On Tue, 30 Jun 2020, Chris Muller wrote:
>>>
>>> > Might be worth reopening this discussion.  ANY dependencies on #class
>>> seem like a bad thing to me, especially while it's still an in-lined
>>> message.  Below is the MC version that did it.  Looks like the time to
>>> change this
>>>
>>> Using #class by default sounds correct to me. If some instances of
>>> classes want to be equal to each other, they should handle that
>>> themselves by overriding #=.
>>>
>>
>> Because it causes that same undesirable loss of symmetry you mentioned
>> about MCVersionName and String, except much worse because it's in a more
>> general sense instead of application-specific.  It makes headaches for
>> Magma applications because client code has to be aware of it.
>>
>> Smalltalk wants to be about messages, not types.  What do we need to do
>> to make #class non-inlined and therefore overridable?  My impression is
>> that this is on the table for 6.0, is it still?
>>
>>  - Chris
>>
>>
> Hi Chris,
> wait a minute, the failure of symmetry of MCVersionName is ABSOLUTELY
> UNRELATED to species or class.
>
> There are some wonderful hacks, there are some clever hacks, but at the
> end, you very well know that you can cheat as long as you don't get caught.
> MCVersionName is not a good hack.
>
> Here we are dressing the String with additional application specific
> semantics.
> The MCVersionName is a String which knows how to be interpreted in some
> context.
> There are lot's of contexts where we could dress strings like that,
> imagine that we create a DateString, a NumberString...
> Should we really do that?
> When we do that, we confer more responsibilities to such subclasses. They
> are a String, and also more than a String.
> But here, the application specific behavior is in contradiction with
> superclass, we redefined = with a different behavior.
> At the end, we will always get caught with schemes like that, because we
> complexify and entangle the concepts.
> It seems to me that it's a simple inheritance vs composition anti-pattern.
>
> MCVersion name hash ~= MVVersion name asString hash is a good illustration.
> It means that we're breaking a more general contract for implementing our
> hack.
> It's typical of what will happen by abuse of inheritance.
>
> Think of it, = is a relationship of equivalence. We don't want to loose
> that.
> So it has to be symmetric, but also transitive:
>     String new = StringSubclass1 & ( String new = StringSubclass2 new )
> ==> (StringSubclass1 new = StringSubclass2 new).
> That means that we would have accidental equivalence of separate domains
> if ever the string representation matches.
> That's not what we want.
>
> Also, if StringSubclass1 is more than a String, then how something less
> than a StringSubclass1 could be equivalent?
> It's not equivalent, it does not behave the same, or we would not need to
> subclass in the first place.
>
> Oh but we have String subclasses, ByteString and WideString, so what's the
> difference?
> The difference is that those are implementation details. They are
> optimized internal representations of Strings.
> We're not at all after conferring a different behavior, on the contrary.
> We absolutely want to confer the same behavior to the outside whatever the
> internal representation (class) and try to make them be really equivalent.
> Yes, more than often, the implementation details leak out of encapsulation.
> It's the problem of tradeoffs between efficiency and universality. We have
> to trade some generality for some efficiency.
>
> That's what happens with Interval and Array. They are not equivalent. They
> have slightly different behaviors and properties.
> An Interval is more than an Array (it has numeric elements with arithmetic
> progression).
> And it is less than an Array (it cannot at:put: or embed arbitrary
> objects).
> We can casually have an Array carrying the same elements as an Interval,
> which can be expressed by #hasEqualElements:
>
> species semantics was overloaded. It did also mean, in which recipient
> class should I select:, collect:...
> If we use the same recipient for collecting, then we are similar (of same
> species)... And if similar, maybe equal?
> It might be that Interval was originally seen as an implementation detail,
> a (space) optimized version of Array afterall.
> But doing so, introduced complexity.
> It entangled things.
> It broke contracts (hash), or imposed very inefficient implementation of
> hash (enumerating all elements of an Interval).
> In the end, we get caught, that is carrying more inconvenients than
> advantages when trying to sustain the illusion of equivalence.
> It's far better and simpler to just abandon the illusion, because it's
> just that, a deceitful illusion.
>
> I understand what you mean by abuse of using the class message, we have
> somehow lost a hook.
> But IMO, this hook was not useful, except for one thing proxy.
> We have more than one message in our palette, even if = is a very
> convenient symbol (short binary), we cannot dress it with different context
> specific meanings, the cheat is getting too apparent.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200702/3194ecac/attachment.html>

From ma.chris.m at gmail.com  Fri Jul  3 02:30:08 2020
From: ma.chris.m at gmail.com (Chris Muller)
Date: Thu, 2 Jul 2020 21:30:08 -0500
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <alpine.DEB.2.02.2007011354140.18609@login03.caesar.elte.hu>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <CACddb62c6mMXcJW7+QLJ_hLLOQd8-0p2SSU55LrYkXiiAAkCdg@mail.gmail.com>
 <CANzdToG6x4b8jF=+eOxNHDCcSHNujY-GTnBUjbp98ZXF=0d5WQ@mail.gmail.com>
 <alpine.DEB.2.02.2007010246440.2544@login03.caesar.elte.hu>
 <CADTxDUh=JepYUf9tcckWzkbiOf0otsEovv+fSHk2=cE7B0pxUA@mail.gmail.com>
 <alpine.DEB.2.02.2007011354140.18609@login03.caesar.elte.hu>
Message-ID: <CADTxDUhzDV=U_0j_ryZiOEyeBOG1ivxPSkwhT4BiJF=+b8btKA@mail.gmail.com>

Thanks for that reminder, but I was asking about the next Squeak release
image.  Does anyone object to making this one of the goals for 6.0?

 - Chris


On Wed, Jul 1, 2020 at 2:29 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:

> Hi Chris,
>
> On Tue, 30 Jun 2020, Chris Muller wrote:
>
> > What do we need to do to make #class non-inlined and therefore
> overridable?  My impression is that this is on the table for 6.0, is it
> still?
>
> We have had this discussion a few times before. Last time[1] I asked you
> to evaluate the following in your image and report back if it does what
> you need:
>
>    (ParseNode classPool at: #StdSelectors) removeKey: #class.
>    Compiler recompileAll.
>
>
> Levente
>
> [1]
> http://forum.world.st/The-Inbox-Kernel-cmm-1198-mcz-td5089411.html#a5089510
>
> >
> >  - Chris
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200702/f2083879/attachment.html>

From asqueaker at gmail.com  Fri Jul  3 03:42:14 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Thu, 2 Jul 2020 22:42:14 -0500
Subject: [squeak-dev] Squeak on Ubuntu 18.04 desktop
Message-ID: <CANzdToHrrmQj4uy3YuV-BR8Mzpd2yrfg6r6Y5U-zGMC02radUg@mail.gmail.com>

Has anyone figured out how to get Squeak's behavior to behave in 18.04 like
it did in 16.04 and before?

In Ubuntu, Alt+~ (tilde) switches between windows of the same application.
But, in 18.04, it no longer works.  It treats every running instance of
Squeak as a separate "app".

It also won't re-top an existing window when using with a .desktop file.
Nor will it let me anchor the .desktop file to the bar.

Sigh, so Linux..  It makes working with multiple images at once nearly
impossible..

Has anyone else encountered this?

Thanks,
  Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200702/e276e963/attachment.html>

From commits at source.squeak.org  Fri Jul  3 05:24:38 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Fri, 3 Jul 2020 05:24:38 0000
Subject: [squeak-dev] The Trunk: KernelTests-tpr.383.mcz
Message-ID: <E1jrEBj-0002gz-UD@andreas>

tim Rowledge uploaded a new version of KernelTests to project The Trunk:
http://source.squeak.org/trunk/KernelTests-tpr.383.mcz

==================== Summary ====================

Name: KernelTests-tpr.383
Author: tpr
Time: 2 July 2020, 10:24:36.600711 pm
UUID: cb4cc7c5-a318-4424-93dd-1414a73dbc32
Ancestors: KernelTests-tonyg.382

Make the AllocationTest work by preventing the requested free space size (in #setFreeSpaceLimi....) from exceeding SmallInteger>maxVal and thereby failing the vmParameter primitive's limit.

=============== Diff against KernelTests-tonyg.382 ===============

Item was changed:
  ----- Method: AllocationTest>>setFreeSpaceLimitOf:around: (in category 'support') -----
  setFreeSpaceLimitOf: bytes around: aBlock
  	"Attempt to evaluate aBlock with a limit of the requested ammount
  	 of free old space, restoring the extant limit after the evaluation."
  
  	| extantLimit |
  	extantLimit := Smalltalk vmParameterAt: 67.
+ 	Smalltalk vmParameterAt: 67 put: ((Smalltalk vmParameterAt: 1) + bytes asInteger min: SmallInteger maxVal).
- 	Smalltalk vmParameterAt: 67 put: (Smalltalk vmParameterAt: 1) + bytes asInteger.
  	^aBlock ensure: [Smalltalk vmParameterAt: 67 put: extantLimit]!


From tim at rowledge.org  Fri Jul  3 05:42:29 2020
From: tim at rowledge.org (tim Rowledge)
Date: Thu, 2 Jul 2020 22:42:29 -0700
Subject: [squeak-dev] Squeak on Ubuntu 18.04 desktop
In-Reply-To: <CANzdToHrrmQj4uy3YuV-BR8Mzpd2yrfg6r6Y5U-zGMC02radUg@mail.gmail.com>
References: <CANzdToHrrmQj4uy3YuV-BR8Mzpd2yrfg6r6Y5U-zGMC02radUg@mail.gmail.com>
Message-ID: <469351F1-7AC6-4852-B188-12F3992E30B3@rowledge.org>



> On 2020-07-02, at 8:42 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> Has anyone figured out how to get Squeak's behavior to behave in 18.04 like it did in 16.04 and before?

This is with the stock window manager for ubuntu 18? I got away from that horror story as quickly as I could work out. Not that xfce4 is looking much less annoying TBH. What is it with the unix world wanting to make life as miserable as possible?

It may just be from long experience but the least awful unix/gui pair I know is Raspbian - or more correctly since they recently changed the name - Raspberry Pi OS. It's Debian based, the UI is tolerably consistent and best of all the system is being cared for and developed by some people that seem to have a decent clue. It wouldn't be worth mentioning this if they didn't provide an X86 version but they do so it is.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
The less time planning, the more time programming.



From kksubbu.ml at gmail.com  Fri Jul  3 09:06:17 2020
From: kksubbu.ml at gmail.com (K K Subbu)
Date: Fri, 3 Jul 2020 14:36:17 +0530
Subject: [squeak-dev] Squeak on Ubuntu 18.04 desktop
In-Reply-To: <CANzdToHrrmQj4uy3YuV-BR8Mzpd2yrfg6r6Y5U-zGMC02radUg@mail.gmail.com>
References: <CANzdToHrrmQj4uy3YuV-BR8Mzpd2yrfg6r6Y5U-zGMC02radUg@mail.gmail.com>
Message-ID: <3ca47a10-9c1b-1009-dadd-3dc2396e9ab5@gmail.com>

On 03/07/20 9:12 am, Chris Muller wrote:
> Has anyone figured out how to get Squeak's behavior to behave in 18.04 
> like it did in 16.04 and before?

They use two different GUI shells. 16.04 uses Unity and 18.04 uses Gnome 
desktop manager v3 (GDM3). You may install Unity to restore old behavior.

   # apt-get install ubuntu-unity-desktop

and choose lightdm as the desktop manager when prompted.

If you wish to continue with GDM, the keyboard shortcuts are different. 
Use Win (aka Super) key with tilde to switch between windows of the same 
app. More keyboard shortcuts are at:

 
https://help.gnome.org/users/gnome-help/stable/shell-keyboard-shortcuts.html.en

Also, you may find the 20.04 GDM to be much better than that in 18.04.

HTH .. Subbu

From leves at caesar.elte.hu  Fri Jul  3 11:07:08 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Fri, 3 Jul 2020 13:07:08 +0200 (CEST)
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <CADTxDUhzDV=U_0j_ryZiOEyeBOG1ivxPSkwhT4BiJF=+b8btKA@mail.gmail.com>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <CACddb62c6mMXcJW7+QLJ_hLLOQd8-0p2SSU55LrYkXiiAAkCdg@mail.gmail.com>
 <CANzdToG6x4b8jF=+eOxNHDCcSHNujY-GTnBUjbp98ZXF=0d5WQ@mail.gmail.com>
 <alpine.DEB.2.02.2007010246440.2544@login03.caesar.elte.hu>
 <CADTxDUh=JepYUf9tcckWzkbiOf0otsEovv+fSHk2=cE7B0pxUA@mail.gmail.com>
 <alpine.DEB.2.02.2007011354140.18609@login03.caesar.elte.hu>
 <CADTxDUhzDV=U_0j_ryZiOEyeBOG1ivxPSkwhT4BiJF=+b8btKA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.2007031306110.31457@login03.caesar.elte.hu>

On Thu, 2 Jul 2020, Chris Muller wrote:

> Thanks for that reminder, but I was asking about the next Squeak release image.  Does anyone object to making this one of the goals for 6.0?

What is "this" you're referring to?


Levente

>  - Chris
> 
> 
> On Wed, Jul 1, 2020 at 2:29 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:
>       Hi Chris,
>
>       On Tue, 30 Jun 2020, Chris Muller wrote:
>
>       > What do we need to do to make #class non-inlined and therefore overridable?  My impression is that this is on the table for 6.0, is it still?
>
>       We have had this discussion a few times before. Last time[1] I asked you
>       to evaluate the following in your image and report back if it does what
>       you need:
>
>          (ParseNode classPool at: #StdSelectors) removeKey: #class.
>          Compiler recompileAll.
> 
>
>       Levente
>
>       [1] http://forum.world.st/The-Inbox-Kernel-cmm-1198-mcz-td5089411.html#a5089510
>
>       >
>       >  - Chris
>       >
>       >
> 
> 
>

From hmm at heeg.de  Fri Jul  3 11:24:32 2020
From: hmm at heeg.de (Hans-Martin Mosner)
Date: Fri, 3 Jul 2020 13:24:32 +0200
Subject: [squeak-dev] VW font setting
In-Reply-To: <7D5249B4-061C-44FF-925A-2C07AAE208E2@rowledge.org>
References: <7D5249B4-061C-44FF-925A-2C07AAE208E2@rowledge.org>
Message-ID: <442158f3-5afa-98fb-d512-e7be16d1eae2@heeg.de>

Am 26.06.20 um 02:10 schrieb tim Rowledge:
> If there's anyone in the list that has recently used VW and knows how to get fonts set up to be actually readable in a VW8.3 system running on Ubuntu lite with the xfce4 window manager.... I'd appreciate any pointers to helpful info.
>
> So far googling and digging into the colossal pile of code that appears to be font related has secured no effects whatsoever in getting anything better than almost utterly unreadable fonts for menus, buttons etc. My eyes hurt!

This is indeed a pretty unsightly part of VW. Linux just isn't the child of love there :-)

Holger Kleinsorgen implemented an interface to the Xft libraries which give you proper anti-aliased fonts in VW and
which is included (or should I say hidden) in the Contributed parcel list.

From the parcel manager, go to Directories->Contributed->Xft and load the Xft-DesktopIntegration parcel. Save&quit and
restart the image.

Cheers,
Hans-Martin



From lewis at mail.msen.com  Fri Jul  3 12:42:59 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Fri, 3 Jul 2020 08:42:59 -0400
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
	differs from Squeak 5.2
In-Reply-To: <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
Message-ID: <20200703124259.GA76636@shell.msen.com>

On Mon, Jun 29, 2020 at 02:43:26AM +0200, Levente Uzonyi wrote:
> Hi Nikolai,
> 
> On Mon, 29 Jun 2020, Nikolay Suslov wrote:
> 
> >Hello all,
> >Figuring out, could we go back to the previous version of 
> >SequenceableCollection??#= method (as in Squeak 5.2), to check if the 
> >receiver is??equivalent to the otherCollection by using "self species == 
> >otherCollection species",
> >instead of "self class = otherCollection class"?
> 
> IIRC there was a good reason for that change though I can't recall
> what it was. I'm sure the mailing list remembers.
> 

The change has my initials on it, and it was introduced here:

  Name: Collections-dtl.821
  Author: dtl
  Time: 16 February 2019, 6:18:27.925895 pm
  UUID: 9bfa29b3-5e9f-4c61-b19b-e0bb05403589
  Ancestors: Collections-nice.820
  
  Classes are expected to be unique in the system, but in some cases (e.g. Magma)
  it is also useful to expect a proxy for a class to test equivalent to the
  actual class. Therefore, in SequenceableCollection>>= use #= rather than #==
  for the class comparison.


The discussion on the list was here:

  http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-February/201600.html

Dave


From peter at ozzard.org  Fri Jul  3 15:10:58 2020
From: peter at ozzard.org (Peter Crowther)
Date: Fri, 3 Jul 2020 16:10:58 +0100
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <CAGzzWLhjjsL4ZHNeMMnqqxUZN9F05moCS4O75wc_gAnDXyHRUg@mail.gmail.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CAGzzWLhjjsL4ZHNeMMnqqxUZN9F05moCS4O75wc_gAnDXyHRUg@mail.gmail.com>
Message-ID: <CAH8T+yt+o-paAvd6AkjS_-Zb_ei+cfrZ=Fyy53ngK=Z4-rPKfA@mail.gmail.com>

On Thu, 2 Jul 2020 at 09:22, karl ramberg <karlramberg at gmail.com> wrote:

> Faster, smoother graphics would be really good.
> At the same time I like access to everything within the image.
>
> If you could only choose one of these, which would you choose? "Access to
everything within the image" is a really large anchor to attach to a
graphics subsystem these days.  We have a single-threaded Smalltalk that
has deep assumptions about a single memory space and a single rectangular
display area of consistent properties wired in over forty years of
development.  Meanwhile, modern graphics subsystems are *very* heavily
parallel, use custom hardware, and you try to offload everything you can to
the coprocessor because you don't want it even in your memory space.

If we want a teaching and learning system that can be understood and
modified by a normal programmer, we keep everything in the image and accept
limited facilities and slowness.  If we want something that makes use of
all of the varied and wonderful capabilities of modern graphics hardware
then a) what's the smallest subset we'll accept (to make it easy to port
Squeak to new platforms), b) what knowledge do we require of anyone who
wishes to investigate the graphics subsystem?

Cheers,

- Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200703/d39d5c56/attachment.html>

From nicolas.cellier.aka.nice at gmail.com  Fri Jul  3 15:38:58 2020
From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier)
Date: Fri, 3 Jul 2020 17:38:58 +0200
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <20200703124259.GA76636@shell.msen.com>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <20200703124259.GA76636@shell.msen.com>
Message-ID: <CAKnRiT5JV-nnYxU9ei4JHTDrsfNbLL5Fz9KxWE8KKxZiOC-XKA@mail.gmail.com>

Le ven. 3 juil. 2020 à 14:43, David T. Lewis <lewis at mail.msen.com> a écrit :

> On Mon, Jun 29, 2020 at 02:43:26AM +0200, Levente Uzonyi wrote:
> > Hi Nikolai,
> >
> > On Mon, 29 Jun 2020, Nikolay Suslov wrote:
> >
> > >Hello all,
> > >Figuring out, could we go back to the previous version of
> > >SequenceableCollection??#= method (as in Squeak 5.2), to check if the
> > >receiver is??equivalent to the otherCollection by using "self species
> ==
> > >otherCollection species",
> > >instead of "self class = otherCollection class"?
> >
> > IIRC there was a good reason for that change though I can't recall
> > what it was. I'm sure the mailing list remembers.
> >
>
> The change has my initials on it, and it was introduced here:
>
>   Name: Collections-dtl.821
>   Author: dtl
>   Time: 16 February 2019, 6:18:27.925895 pm
>   UUID: 9bfa29b3-5e9f-4c61-b19b-e0bb05403589
>   Ancestors: Collections-nice.820
>
>   Classes are expected to be unique in the system, but in some cases (e.g.
> Magma)
>   it is also useful to expect a proxy for a class to test equivalent to the
>   actual class. Therefore, in SequenceableCollection>>= use #= rather than
> #==
>   for the class comparison.
>
>
> +1 for using =

The discussion on the list was here:
>
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-February/201600.html
>
> Dave
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200703/0a73f38d/attachment.html>

From nsuslovi at gmail.com  Fri Jul  3 15:43:04 2020
From: nsuslovi at gmail.com (Nikolay Suslov)
Date: Fri, 3 Jul 2020 18:43:04 +0300
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <20200703124259.GA76636@shell.msen.com>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <20200703124259.GA76636@shell.msen.com>
Message-ID: <CACddb61UGPDJS1ibYv0bkLn9dx9eOOkuR8ooiM96yV1+kedf=g@mail.gmail.com>

Hello David,

On Fri, Jul 3, 2020 at 3:43 PM David T. Lewis <lewis at mail.msen.com> wrote:
>
> On Mon, Jun 29, 2020 at 02:43:26AM +0200, Levente Uzonyi wrote:
> > Hi Nikolai,
> >
> > On Mon, 29 Jun 2020, Nikolay Suslov wrote:
> >
> > >Hello all,
> > >Figuring out, could we go back to the previous version of
> > >SequenceableCollection??#= method (as in Squeak 5.2), to check if the
> > >receiver is??equivalent to the otherCollection by using "self species ==
> > >otherCollection species",
> > >instead of "self class = otherCollection class"?
> >
> > IIRC there was a good reason for that change though I can't recall
> > what it was. I'm sure the mailing list remembers.
> >
>
> The change has my initials on it, and it was introduced here:
>
>   Name: Collections-dtl.821
>   Author: dtl
>   Time: 16 February 2019, 6:18:27.925895 pm
>   UUID: 9bfa29b3-5e9f-4c61-b19b-e0bb05403589
>   Ancestors: Collections-nice.820
>
>   Classes are expected to be unique in the system, but in some cases (e.g. Magma)
>   it is also useful to expect a proxy for a class to test equivalent to the
>   actual class. Therefore, in SequenceableCollection>>= use #= rather than #==
>   for the class comparison.
>
>
> The discussion on the list was here:
>
>   http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-February/201600.html
>
> Dave
>
>

Thanks for finding that.
But, if you look at the previous version (sma 5/12/2000) of
SequenceableCollection>>=, it checks the equivalents of "species" (the
same 'kind' of thing in collection). So, replacing that with check
equivalents of a "class" introduces a "silent application bug",
especially in code, which expects "species" comparison in
SequenceableCollection>>= (like RFB I mentioned).
Anyway, it is ok to use and upgrade related code to #hasEqualElements:
method instead.
But someone still can find the difference, that in Set, Bitset,
SortedCollection we could use #= for checking equivalents of
"species", but in SequenceableCollection - not, starting from Squeak
5.3

Best regards,
Nikolai

From lecteur at zogotounga.net  Fri Jul  3 15:58:58 2020
From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=)
Date: Fri, 3 Jul 2020 17:58:58 +0200
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <CAH8T+yt+o-paAvd6AkjS_-Zb_ei+cfrZ=Fyy53ngK=Z4-rPKfA@mail.gmail.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CAGzzWLhjjsL4ZHNeMMnqqxUZN9F05moCS4O75wc_gAnDXyHRUg@mail.gmail.com>
 <CAH8T+yt+o-paAvd6AkjS_-Zb_ei+cfrZ=Fyy53ngK=Z4-rPKfA@mail.gmail.com>
Message-ID: <6891ffab-14d6-bda4-7afb-ccab8a25f081@zogotounga.net>

> If you could only choose one of these, which would you choose? 

If new modern, faster, but opaque graphics system is implemented, then 
it does not have to replace the existing, fully accessible one, it can 
just complement it (being available via a specific Canvas subclass, and 
able to deliver a Form on demand). There is no need to have an 
opposition here. Just as we have Morphic *and* MVC, we can have BitBlt 
*and* a bridge to an opaque backend for people interested in that kind 
of performance.

As for me, I am interested in both.

Stef

From hilaire at drgeo.eu  Fri Jul  3 16:15:17 2020
From: hilaire at drgeo.eu (Hilaire)
Date: Fri, 3 Jul 2020 18:15:17 +0200
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <8466da4b-2ded-daaa-645b-573271857b67@zogotounga.net>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CA+CiqoW0rQ3yS5WQVn4Vu+Dg6M3NeCeLj60wWRS=cOFQ8r4D=w@mail.gmail.com>
 <CAN7OfXQyzSK500arwGvnSktLy_b9=RTjvENfLoW3YSraX2E2OQ@mail.gmail.com>
 <8466da4b-2ded-daaa-645b-573271857b67@zogotounga.net>
Message-ID: <rdnlil$b44$1@ciao.gmane.io>


Le 30/06/2020 à 08:26, Stéphane Rollandin a écrit :
>> Is GPU& shader  support necessary/desirable:
>> yes if real-time rendering for thighs like games/VR are important, 
>> but in that case there
>> is a bigger problem jitter caused by GC,
> In the image I just uploaded two days ago and that one can get from 
> http://www.zogotounga.net/comp/squeak/rogue.htm the main feature is a 
> 2D real-time top-down game.
>
> I found that the GC-caused jitter was indeed a problem, but also that 
> the main culprit was the time it takes to simply paint an image which 
> is a surprisingly (to me) slow operation.
>
> That, plus the alpha-blending issue that was discussed on the VM list 
> a little ago, where Juan proposed two new primitives. 

Juan proposed these primitives to speed up the rendering of 
VectorGraphics Widget Morph.

Regarding graphics, Juan's work on Vector Graphics can be of interest 
for Squeak.

Hilaire

-- 
Dr. Geo
http://drgeo.eu
https://pouet.chapril.org/@hilaire

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200703/fc7a33d7/attachment.html>

From tim at rowledge.org  Fri Jul  3 17:00:35 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 3 Jul 2020 10:00:35 -0700
Subject: [squeak-dev] VW font setting
In-Reply-To: <442158f3-5afa-98fb-d512-e7be16d1eae2@heeg.de>
References: <7D5249B4-061C-44FF-925A-2C07AAE208E2@rowledge.org>
 <442158f3-5afa-98fb-d512-e7be16d1eae2@heeg.de>
Message-ID: <5A587C39-3A51-41CD-B828-5EB7825DA550@rowledge.org>

Thank you, thank you, thank you!
This makes actual readable fonts. Excellent.

If by any chance you have a suitable blog relating to VW matters, please consider mentioning this package on it; that way anybody else trying to google for visualworks/fonts/linux has a chance of finding and enjoying this most useful package.

> On 2020-07-03, at 4:24 AM, Hans-Martin Mosner <hmm at heeg.de> wrote:
> 
> Am 26.06.20 um 02:10 schrieb tim Rowledge:
>> If there's anyone in the list that has recently used VW and knows how to get fonts set up to be actually readable in a VW8.3 system running on Ubuntu lite with the xfce4 window manager.... I'd appreciate any pointers to helpful info.
>> 
>> So far googling and digging into the colossal pile of code that appears to be font related has secured no effects whatsoever in getting anything better than almost utterly unreadable fonts for menus, buttons etc. My eyes hurt!
> 
> This is indeed a pretty unsightly part of VW. Linux just isn't the child of love there :-)
> 
> Holger Kleinsorgen implemented an interface to the Xft libraries which give you proper anti-aliased fonts in VW and
> which is included (or should I say hidden) in the Contributed parcel list.
> 
> From the parcel manager, go to Directories->Contributed->Xft and load the Xft-DesktopIntegration parcel. Save&quit and
> restart the image.
> 
> Cheers,
> Hans-Martin
> 
> 
> 
> 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Never write software that anthropomorphizes the machine. They hate that.



From eliot.miranda at gmail.com  Fri Jul  3 18:17:52 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Fri, 3 Jul 2020 11:17:52 -0700
Subject: [squeak-dev] AllocationTest>>#testOutOfMemorySignal fails on
	32bit system
In-Reply-To: <20200703013211.GA46239@shell.msen.com>
References: <20200703013211.GA46239@shell.msen.com>
Message-ID: <FC26F5E3-EDDE-4586-A748-78E61D90A62F@gmail.com>



> On Jul 2, 2020, at 6:32 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> On Thu, Jul 02, 2020 at 04:35:03PM -0700, tim Rowledge wrote:
>> On a Raspberry Pi OS 32bit this test fails because of an oversight - the parameter passed to vmParameterAt:put: cannot exceed SmallInteger maxVal. It makes the careful testing for 32/64bit image seem a bit silly.
>> 
>> This means we can only ask for up to ~1GB space for free space on a 32bit image system and so I propose to clamp the requested value in AllocationTest>>#setFreeSpaceLimitOf:around: There don't appear to be any other places right now that need attention.
>> 
>> If I don't hear any outraged screams soon I'll just commit it to trunk.
>> 
> 
> So rather than
> 
>  1024 * 1024 * 1024
> 
> it should instead be
> 
>  16r3FFFFFFF
> 
> so that is it less than or equal to SmallInteger maxVal for either 32 or
> 64 bit images. Is that the change?
> 
> No outraged screams from me.

Nor from me, but one weak bleat for it to read

    (1024 * 1024 * 1024 min: SmallInteger maxVal)

And perhaps I should fix vmParameterAt:[put:] for very few cases including this one.


> 
> Dave
> 
> 

From karlramberg at gmail.com  Fri Jul  3 19:12:06 2020
From: karlramberg at gmail.com (karl ramberg)
Date: Fri, 3 Jul 2020 21:12:06 +0200
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <CAH8T+yt+o-paAvd6AkjS_-Zb_ei+cfrZ=Fyy53ngK=Z4-rPKfA@mail.gmail.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CAGzzWLhjjsL4ZHNeMMnqqxUZN9F05moCS4O75wc_gAnDXyHRUg@mail.gmail.com>
 <CAH8T+yt+o-paAvd6AkjS_-Zb_ei+cfrZ=Fyy53ngK=Z4-rPKfA@mail.gmail.com>
Message-ID: <CAGzzWLjyTHAWRr12FeVkpET_iN9Bx0xqB5a2ykYFto82MzjspQ@mail.gmail.com>

Hi,
I have tried to use the OpenGL from Squeak and found it very opaque and
hard to use.
Both because the Squeak side is not very well documented and because OpenGL
is hard  itself.

I have also looked briefly at Dolphin Smalltalk which have quite fast
graphics on Windows but
the way you get it to work is quite elaborate and convoluted.


I agree with what Stephane Rollandin wrote; keep BitBlt for simplicity and
work on better way to
access whatever we choose to use as a fast backend.

Best,
Karl

On Fri, Jul 3, 2020 at 5:11 PM Peter Crowther <peter at ozzard.org> wrote:

> On Thu, 2 Jul 2020 at 09:22, karl ramberg <karlramberg at gmail.com> wrote:
>
>> Faster, smoother graphics would be really good.
>> At the same time I like access to everything within the image.
>>
>> If you could only choose one of these, which would you choose? "Access to
> everything within the image" is a really large anchor to attach to a
> graphics subsystem these days.  We have a single-threaded Smalltalk that
> has deep assumptions about a single memory space and a single rectangular
> display area of consistent properties wired in over forty years of
> development.  Meanwhile, modern graphics subsystems are *very* heavily
> parallel, use custom hardware, and you try to offload everything you can to
> the coprocessor because you don't want it even in your memory space.
>
> If we want a teaching and learning system that can be understood and
> modified by a normal programmer, we keep everything in the image and accept
> limited facilities and slowness.  If we want something that makes use of
> all of the varied and wonderful capabilities of modern graphics hardware
> then a) what's the smallest subset we'll accept (to make it easy to port
> Squeak to new platforms), b) what knowledge do we require of anyone who
> wishes to investigate the graphics subsystem?
>
> Cheers,
>
> - Peter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200703/c2c1d13b/attachment.html>

From lewis at mail.msen.com  Fri Jul  3 19:55:21 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Fri, 3 Jul 2020 15:55:21 -0400
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
	differs from Squeak 5.2
In-Reply-To: <CACddb61UGPDJS1ibYv0bkLn9dx9eOOkuR8ooiM96yV1+kedf=g@mail.gmail.com>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <20200703124259.GA76636@shell.msen.com>
 <CACddb61UGPDJS1ibYv0bkLn9dx9eOOkuR8ooiM96yV1+kedf=g@mail.gmail.com>
Message-ID: <20200703195521.GA48491@shell.msen.com>

Hello Nikolay,

On Fri, Jul 03, 2020 at 06:43:04PM +0300, Nikolay Suslov wrote:
> Hello David,
> 
> On Fri, Jul 3, 2020 at 3:43 PM David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > On Mon, Jun 29, 2020 at 02:43:26AM +0200, Levente Uzonyi wrote:
> > > Hi Nikolai,
> > >
> > > On Mon, 29 Jun 2020, Nikolay Suslov wrote:
> > >
> > > >Hello all,
> > > >Figuring out, could we go back to the previous version of
> > > >SequenceableCollection??#= method (as in Squeak 5.2), to check if the
> > > >receiver is??equivalent to the otherCollection by using "self species ==
> > > >otherCollection species",
> > > >instead of "self class = otherCollection class"?
> > >
> > > IIRC there was a good reason for that change though I can't recall
> > > what it was. I'm sure the mailing list remembers.
> > >
> >
> > The change has my initials on it, and it was introduced here:
> >
> >   Name: Collections-dtl.821
> >   Author: dtl
> >   Time: 16 February 2019, 6:18:27.925895 pm
> >   UUID: 9bfa29b3-5e9f-4c61-b19b-e0bb05403589
> >   Ancestors: Collections-nice.820
> >
> >   Classes are expected to be unique in the system, but in some cases (e.g. Magma)
> >   it is also useful to expect a proxy for a class to test equivalent to the
> >   actual class. Therefore, in SequenceableCollection>>= use #= rather than #==
> >   for the class comparison.
> >
> >
> > The discussion on the list was here:
> >
> >   http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-February/201600.html
> >
> > Dave
> >
> >
> 
> Thanks for finding that.
> But, if you look at the previous version (sma 5/12/2000) of
> SequenceableCollection>>=, it checks the equivalents of "species" (the
> same 'kind' of thing in collection). So, replacing that with check
> equivalents of a "class" introduces a "silent application bug",
> especially in code, which expects "species" comparison in
> SequenceableCollection>>= (like RFB I mentioned).
> Anyway, it is ok to use and upgrade related code to #hasEqualElements:
> method instead.
> But someone still can find the difference, that in Set, Bitset,
> SortedCollection we could use #= for checking equivalents of
> "species", but in SequenceableCollection - not, starting from Squeak
> 5.3
> 
> Best regards,
> Nikolai

Yes, I can see that your are right. The current version of the
SequenceableCollection>>#= does this:

   self class = otherCollection class

and the previous version (sma 5/12/2000) did this:

   self species == otherCollection species

I have to say that I am not really qualified to say what is the best
implementation, so I hope that you or others (Nicolas, Levente, Chris?)
can suggest if there is a better way.

For example, is it better to do this (I really do not know):

   self species = otherCollection species

Thanks,
Dave 

From lewis at mail.msen.com  Fri Jul  3 20:06:09 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Fri, 3 Jul 2020 16:06:09 -0400
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <6891ffab-14d6-bda4-7afb-ccab8a25f081@zogotounga.net>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CAGzzWLhjjsL4ZHNeMMnqqxUZN9F05moCS4O75wc_gAnDXyHRUg@mail.gmail.com>
 <CAH8T+yt+o-paAvd6AkjS_-Zb_ei+cfrZ=Fyy53ngK=Z4-rPKfA@mail.gmail.com>
 <6891ffab-14d6-bda4-7afb-ccab8a25f081@zogotounga.net>
Message-ID: <20200703200609.GA52195@shell.msen.com>

On Fri, Jul 03, 2020 at 05:58:58PM +0200, St??phane Rollandin wrote:
> >If you could only choose one of these, which would you choose? 
> 
> If new modern, faster, but opaque graphics system is implemented, then 
> it does not have to replace the existing, fully accessible one, it can 
> just complement it (being available via a specific Canvas subclass, and 
> able to deliver a Form on demand). There is no need to have an 
> opposition here. Just as we have Morphic *and* MVC, we can have BitBlt 
> *and* a bridge to an opaque backend for people interested in that kind 
> of performance.
> 
> As for me, I am interested in both.
> 

+1

Dave


From lewis at mail.msen.com  Fri Jul  3 20:21:18 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Fri, 3 Jul 2020 16:21:18 -0400
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <rdnlil$b44$1@ciao.gmane.io>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CA+CiqoW0rQ3yS5WQVn4Vu+Dg6M3NeCeLj60wWRS=cOFQ8r4D=w@mail.gmail.com>
 <CAN7OfXQyzSK500arwGvnSktLy_b9=RTjvENfLoW3YSraX2E2OQ@mail.gmail.com>
 <8466da4b-2ded-daaa-645b-573271857b67@zogotounga.net>
 <rdnlil$b44$1@ciao.gmane.io>
Message-ID: <20200703202118.GB52195@shell.msen.com>

On Fri, Jul 03, 2020 at 06:15:17PM +0200, Hilaire wrote:
> 
> Le 30/06/2020 ?? 08:26, St??phane Rollandin a ??crit??:
> >>Is GPU& shader ??support necessary/desirable:
> >>yes if real-time rendering for thighs??like games/VR are important, 
> >>but in that case there
> >>is a bigger problem jitter caused by GC,
> >In the image I just uploaded two days ago and that one can get from 
> >http://www.zogotounga.net/comp/squeak/rogue.htm the main feature is a 
> >2D real-time top-down game.
> >
> >I found that the GC-caused jitter was indeed a problem, but also that 
> >the main culprit was the time it takes to simply paint an image which 
> >is a surprisingly (to me) slow operation.
> >
> >That, plus the alpha-blending issue that was discussed on the VM list 
> >a little ago, where Juan proposed two new primitives. 
> 
> Juan proposed these primitives to speed up the rendering of 
> VectorGraphics Widget Morph.

I remember a discussion about that, though I don't have a link to it. It
sounds like we need to follow up on this and make something happen.

> 
> Regarding graphics, Juan's work on Vector Graphics can be of interest 
> for Squeak.
> 

Definitely yes. Juan is working towards *both* high quality rendering
*and* high performance. I think that there may be a perception that
Morphic 3 and VectorGraphics might sacrifice performance for rendering
quality, but I am not sure that is the case at all.

This recent post by Juan would be of interest to any of us attempting to
achieve graphics performance on modern hardware:

  https://lists.cuis.st/mailman/archives/cuis-dev/2020-June/001958.html

I also have to add that the recent work that you (Hilaire) have been
doing with DrGeo on Cuis really illustrates the potential. Your circular
menu will be of interest to anyone who has been involved with Morphic,
Etoys, and Scratch interfaces:

  https://mamot.fr/@drgeo/104310151994863180

Dave


From hilaire at drgeo.eu  Fri Jul  3 20:32:17 2020
From: hilaire at drgeo.eu (Hilaire)
Date: Fri, 3 Jul 2020 22:32:17 +0200
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <20200703202118.GB52195@shell.msen.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CA+CiqoW0rQ3yS5WQVn4Vu+Dg6M3NeCeLj60wWRS=cOFQ8r4D=w@mail.gmail.com>
 <CAN7OfXQyzSK500arwGvnSktLy_b9=RTjvENfLoW3YSraX2E2OQ@mail.gmail.com>
 <8466da4b-2ded-daaa-645b-573271857b67@zogotounga.net>
 <rdnlil$b44$1@ciao.gmane.io> <20200703202118.GB52195@shell.msen.com>
Message-ID: <rdo4kh$h4o$1@ciao.gmane.io>

Le 03/07/2020 à 22:21, David T. Lewis a écrit :
>> Juan proposed these primitives to speed up the rendering of
>> VectorGraphics Widget Morph.
> I remember a discussion about that, though I don't have a link to it. It
> sounds like we need to follow up on this and make something happen.

Here it is:

https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/505

-- 
Dr. Geo
http://drgeo.eu
https://pouet.chapril.org/@hilaire

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200703/7a15b814/attachment.html>

From asqueaker at gmail.com  Fri Jul  3 21:04:29 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Fri, 3 Jul 2020 16:04:29 -0500
Subject: [squeak-dev] Squeak on Ubuntu 18.04 desktop
In-Reply-To: <3ca47a10-9c1b-1009-dadd-3dc2396e9ab5@gmail.com>
References: <CANzdToHrrmQj4uy3YuV-BR8Mzpd2yrfg6r6Y5U-zGMC02radUg@mail.gmail.com>
 <3ca47a10-9c1b-1009-dadd-3dc2396e9ab5@gmail.com>
Message-ID: <CANzdToG=UO2mqcUq-3xBvVjAsVQh+bEZur0Bu4YdozkiJSRR2w@mail.gmail.com>

But the problem is not actually Gnome's window manager -- it works
beautifully with *every other app* *except* Squeak.

At first I thought it was a chink in Fabio's fantastic *squeak.sh* script,
but the same problem occurs even when I launch *bin/squeak* directly.

I sense it's something to do with *how* it's being executed by Linux and/or
Gnome...  The way it's supposed to work is:   when the full command-line (I
think) is exactly the same, it knows to re-top the window for the existing
instance invoked by that command, UNLESS the [Shift] key is pressed, in
which case, it spawns a new process instance of the command again (and
producing another window running instance).

It works with everything except Squeak...

 - Chris


On Fri, Jul 3, 2020 at 4:06 AM K K Subbu <kksubbu.ml at gmail.com> wrote:

> On 03/07/20 9:12 am, Chris Muller wrote:
> > Has anyone figured out how to get Squeak's behavior to behave in 18.04
> > like it did in 16.04 and before?
>
> They use two different GUI shells. 16.04 uses Unity and 18.04 uses Gnome
> desktop manager v3 (GDM3). You may install Unity to restore old behavior.
>
>    # apt-get install ubuntu-unity-desktop
>
> and choose lightdm as the desktop manager when prompted.
>
> If you wish to continue with GDM, the keyboard shortcuts are different.
> Use Win (aka Super) key with tilde to switch between windows of the same
> app. More keyboard shortcuts are at:
>
>
>
> https://help.gnome.org/users/gnome-help/stable/shell-keyboard-shortcuts.html.en
>
> Also, you may find the 20.04 GDM to be much better than that in 18.04.
>
> HTH .. Subbu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200703/9e5e5ab5/attachment.html>

From vanessa at codefrau.net  Fri Jul  3 21:19:10 2020
From: vanessa at codefrau.net (Vanessa Freudenberg)
Date: Fri, 3 Jul 2020 14:19:10 -0700
Subject: [squeak-dev] Squeak on Ubuntu 18.04 desktop
In-Reply-To: <CANzdToG=UO2mqcUq-3xBvVjAsVQh+bEZur0Bu4YdozkiJSRR2w@mail.gmail.com>
References: <CANzdToHrrmQj4uy3YuV-BR8Mzpd2yrfg6r6Y5U-zGMC02radUg@mail.gmail.com>
 <3ca47a10-9c1b-1009-dadd-3dc2396e9ab5@gmail.com>
 <CANzdToG=UO2mqcUq-3xBvVjAsVQh+bEZur0Bu4YdozkiJSRR2w@mail.gmail.com>
Message-ID: <CAOWGXNCD0+HJyjPZeQqndoSEkAsTUg-qMWvjHX=ke7bSFzH1qQ@mail.gmail.com>

My guess is that Squeak is missing some property on its window that the X
window manager uses to identify apps. The VM adds several properties to the
window, but the standards keep evolving. See the latest wm-spec
https://specifications.freedesktop.org
It's also possible that the desktop entry needs additional properties. That
entry is not provided by the vm itself (I think) but added by the
debian/ubuntu maintainers. You may have to edit yours.
That said, I myself have used linux only on servers recently (*), so I am
somewhat out of the loop.

Vanessa

(*) as in, the last decade

On Fri, Jul 3, 2020 at 2:05 PM Chris Muller <asqueaker at gmail.com> wrote:

> But the problem is not actually Gnome's window manager -- it works
> beautifully with *every other app* *except* Squeak.
>
> At first I thought it was a chink in Fabio's fantastic *squeak.sh* script,
> but the same problem occurs even when I launch *bin/squeak* directly.
>
> I sense it's something to do with *how* it's being executed by Linux
> and/or Gnome...  The way it's supposed to work is:   when the full
> command-line (I think) is exactly the same, it knows to re-top the window
> for the existing instance invoked by that command, UNLESS the [Shift] key
> is pressed, in which case, it spawns a new process instance of the command
> again (and producing another window running instance).
>
> It works with everything except Squeak...
>
>  - Chris
>
>
> On Fri, Jul 3, 2020 at 4:06 AM K K Subbu <kksubbu.ml at gmail.com> wrote:
>
>> On 03/07/20 9:12 am, Chris Muller wrote:
>> > Has anyone figured out how to get Squeak's behavior to behave in 18.04
>> > like it did in 16.04 and before?
>>
>> They use two different GUI shells. 16.04 uses Unity and 18.04 uses Gnome
>> desktop manager v3 (GDM3). You may install Unity to restore old behavior.
>>
>>    # apt-get install ubuntu-unity-desktop
>>
>> and choose lightdm as the desktop manager when prompted.
>>
>> If you wish to continue with GDM, the keyboard shortcuts are different.
>> Use Win (aka Super) key with tilde to switch between windows of the same
>> app. More keyboard shortcuts are at:
>>
>>
>>
>> https://help.gnome.org/users/gnome-help/stable/shell-keyboard-shortcuts.html.en
>>
>> Also, you may find the 20.04 GDM to be much better than that in 18.04.
>>
>> HTH .. Subbu
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200703/accb2d32/attachment.html>

From asqueaker at gmail.com  Fri Jul  3 21:36:18 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Fri, 3 Jul 2020 16:36:18 -0500
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <20200703195521.GA48491@shell.msen.com>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <20200703124259.GA76636@shell.msen.com>
 <CACddb61UGPDJS1ibYv0bkLn9dx9eOOkuR8ooiM96yV1+kedf=g@mail.gmail.com>
 <20200703195521.GA48491@shell.msen.com>
Message-ID: <CANzdToGTCPHrBBR8xsQPVZaGJT2U4AOywMZ9fvBptut+P4zcEA@mail.gmail.com>

>
> For example, is it better to do this (I really do not know):
>
>    self species = otherCollection species


Nicolas' arguments for Collections-nice.820 are sound, the challenge is
that some apps, that don't care about equivalence between Intervals and
Array's, were affected in a negative way, and left no good way to fix their
code.  There's a tendency to want to dismiss them with "use
hasEqualElements:" without understanding why hasEqualElements: can't fix
the core issue -- the inability to define implementation-specific
subclasses with symmetric equivalence (e.g., like ByteString and WideString
did for String).

IMO, this is the question we should address.  I posed that we should factor
out this common type-checking behavior, repeated throughout the class
library, into its own method on Object.  I think it could work..

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200703/588a1323/attachment.html>

From tim at rowledge.org  Fri Jul  3 22:08:28 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 3 Jul 2020 15:08:28 -0700
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <rdo4kh$h4o$1@ciao.gmane.io>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CA+CiqoW0rQ3yS5WQVn4Vu+Dg6M3NeCeLj60wWRS=cOFQ8r4D=w@mail.gmail.com>
 <CAN7OfXQyzSK500arwGvnSktLy_b9=RTjvENfLoW3YSraX2E2OQ@mail.gmail.com>
 <8466da4b-2ded-daaa-645b-573271857b67@zogotounga.net>
 <rdnlil$b44$1@ciao.gmane.io> <20200703202118.GB52195@shell.msen.com>
 <rdo4kh$h4o$1@ciao.gmane.io>
Message-ID: <3E4824E0-D3B1-4A7D-B301-A73228785FC6@rowledge.org>



> On 2020-07-03, at 1:32 PM, Hilaire <hilaire at drgeo.eu> wrote:
> 
> Le 03/07/2020 à 22:21, David T. Lewis a écrit :
>>> Juan proposed these primitives to speed up the rendering of 
>>> VectorGraphics Widget Morph.

> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/505

I'm all for such improvements but I have no idea about updating the rather specialised ARM bitblt code that Ben Avison did for RPF a few years ago. That stuff is responsible for no small part of the really good UI performance we get on Pi.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
When all else fails, let a = 7.  If that doesn't help, then read the manual.



From lewis at mail.msen.com  Fri Jul  3 22:26:07 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Fri, 3 Jul 2020 18:26:07 -0400
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <3E4824E0-D3B1-4A7D-B301-A73228785FC6@rowledge.org>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CA+CiqoW0rQ3yS5WQVn4Vu+Dg6M3NeCeLj60wWRS=cOFQ8r4D=w@mail.gmail.com>
 <CAN7OfXQyzSK500arwGvnSktLy_b9=RTjvENfLoW3YSraX2E2OQ@mail.gmail.com>
 <8466da4b-2ded-daaa-645b-573271857b67@zogotounga.net>
 <rdnlil$b44$1@ciao.gmane.io> <20200703202118.GB52195@shell.msen.com>
 <rdo4kh$h4o$1@ciao.gmane.io>
 <3E4824E0-D3B1-4A7D-B301-A73228785FC6@rowledge.org>
Message-ID: <20200703222607.GA76689@shell.msen.com>

On Fri, Jul 03, 2020 at 03:08:28PM -0700, tim Rowledge wrote:
> 
> 
> > On 2020-07-03, at 1:32 PM, Hilaire <hilaire at drgeo.eu> wrote:
> > 
> > Le 03/07/2020 ?? 22:21, David T. Lewis a ??crit :
> >>> Juan proposed these primitives to speed up the rendering of 
> >>> VectorGraphics Widget Morph.
> 
> > https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/505
> 
> I'm all for such improvements but I have no idea about updating the rather specialised ARM bitblt code that Ben Avison did for RPF a few years ago. That stuff is responsible for no small part of the really good UI performance we get on Pi.
> 

Marcel added this comment to the issue on github:

> Would be nice to also have the Smalltalk fall-back code for those new rules. :-)

which seems important if some of the VMs may not yet implement the new rules.

Dave


From lewis at mail.msen.com  Fri Jul  3 22:57:56 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Fri, 3 Jul 2020 18:57:56 -0400
Subject: [squeak-dev] AllocationTest>>#testOutOfMemorySignal fails on
	32bit system
In-Reply-To: <FC26F5E3-EDDE-4586-A748-78E61D90A62F@gmail.com>
References: <20200703013211.GA46239@shell.msen.com>
 <FC26F5E3-EDDE-4586-A748-78E61D90A62F@gmail.com>
Message-ID: <20200703225756.GB76689@shell.msen.com>

On Fri, Jul 03, 2020 at 11:17:52AM -0700, Eliot Miranda wrote:
> 
> 
> > On Jul 2, 2020, at 6:32 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > ???On Thu, Jul 02, 2020 at 04:35:03PM -0700, tim Rowledge wrote:
> >> On a Raspberry Pi OS 32bit this test fails because of an oversight - the parameter passed to vmParameterAt:put: cannot exceed SmallInteger maxVal. It makes the careful testing for 32/64bit image seem a bit silly.
> >> 
> >> This means we can only ask for up to ~1GB space for free space on a 32bit image system and so I propose to clamp the requested value in AllocationTest>>#setFreeSpaceLimitOf:around: There don't appear to be any other places right now that need attention.
> >> 
> >> If I don't hear any outraged screams soon I'll just commit it to trunk.
> >> 
> > 
> > So rather than
> > 
> >  1024 * 1024 * 1024
> > 
> > it should instead be
> > 
> >  16r3FFFFFFF
> > 
> > so that is it less than or equal to SmallInteger maxVal for either 32 or
> > 64 bit images. Is that the change?
> > 
> > No outraged screams from me.
> 
> Nor from me, but one weak bleat for it to read
> 
>     (1024 * 1024 * 1024 min: SmallInteger maxVal)

+1

Weakly bleating in the affermative (the intent is much clearer when written this way).

Dave


From trygver at ifi.uio.no  Sat Jul  4 06:41:17 2020
From: trygver at ifi.uio.no (Trygve Reenskaug)
Date: Sat, 4 Jul 2020 08:41:17 +0200
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <alpine.DEB.2.02.2007011354140.18609@login03.caesar.elte.hu>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
 <CACddb62c6mMXcJW7+QLJ_hLLOQd8-0p2SSU55LrYkXiiAAkCdg@mail.gmail.com>
 <CANzdToG6x4b8jF=+eOxNHDCcSHNujY-GTnBUjbp98ZXF=0d5WQ@mail.gmail.com>
 <alpine.DEB.2.02.2007010246440.2544@login03.caesar.elte.hu>
 <CADTxDUh=JepYUf9tcckWzkbiOf0otsEovv+fSHk2=cE7B0pxUA@mail.gmail.com>
 <alpine.DEB.2.02.2007011354140.18609@login03.caesar.elte.hu>
Message-ID: <014f4e3a-544c-d1e5-5041-5d1bba151c49@ifi.uio.no>

There are two fundamental axioms in Smalltalk:

 1. Everything is an object.
 2. An object is an instance of a class.

The class message is fundamental,  If you override it, it is no longer 
Smalltalk.
Trygve

On 2020-07-01 21:29, Levente Uzonyi wrote:
> Hi Chris,
>
> On Tue, 30 Jun 2020, Chris Muller wrote:
>
>> What do we need to do to make #class non-inlined and therefore 
>> overridable?  My impression is that this is on the table for 6.0, is 
>> it still?
>
> We have had this discussion a few times before. Last time[1] I asked 
> you to evaluate the following in your image and report back if it does 
> what you need:
>
>   (ParseNode classPool at: #StdSelectors) removeKey: #class.
>   Compiler recompileAll.
>
>
> Levente
>
> [1] 
> http://forum.world.st/The-Inbox-Kernel-cmm-1198-mcz-td5089411.html#a5089510
>
>>
>>  - Chris
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200704/7873f35d/attachment.html>

From masashi.umezawa at gmail.com  Sat Jul  4 16:50:12 2020
From: masashi.umezawa at gmail.com (Masashi UMEZAWA)
Date: Sun, 5 Jul 2020 01:50:12 +0900
Subject: [squeak-dev] Buglet ins SIXX for Squeak 5.3
In-Reply-To: <E010D8DB-EDD4-42B2-B572-56B5C5275E99@rowledge.org>
References: <E010D8DB-EDD4-42B2-B572-56B5C5275E99@rowledge.org>
Message-ID: <CAO_ndyXnKntT99A0DjhnNUxMYW33ep5YHktLVjBLCOiH85O90Q@mail.gmail.com>

Hello Tim-san,

Thank you for the feedback.
I've just updated ConfigurationOfSIXX on SqueakSource.com. Now SIXX
can be easily installable to Squeak 5.3.
I will also update SqueakMap entry soon.

Best regards,

2020年7月3日(金) 10:32 tim Rowledge <tim at rowledge.org>:
>
> I just spotted a small bug in the code loaded up for SIXX. After loading it into a clean 5.3 image XMLDOMParser class>>#initialize & XMLDOMParser class>>#unload  are reverted to old and out of date versions.
>
> Installer code used -
> Installer squeaksource
>     project: 'MetacelloRepository';
>     install: 'ConfigurationOfSIXX'.
> (Smalltalk at: #ConfigurationOfSIXX) load.
>
> Looks like the ConfigurationOfSIXX>>#version051: method is causing the load of
> `
> spec for: #squeak do:[
>                 spec
>                         package: 'XML-Parser' with: [
>                                 spec file: 'XML-Parser-ul.44';
>                                         repository: 'http://source.squeak.org/squeak52'
> `
> and that in turn re-loads old versions of XMLDOMParser class>>#initialize & XMLDOMParser class>>#unload - and they try to use the deprecated #registerFileReader: in FileList instead of FileServices.
>
> I *think* it looks like ConfigurationOfSIXX>>#baseline06: requires the above section removing - but I am most definitely not any sort of expert in the ConfigurationOfXXXXXX stuff.
>
> It appears that  Masashi-san is still caring for this package since there was a commit in january of this year, so if you could please Do The Magic(™).
>
> And since SmalltalkHub is now deprecated it could be a good idea to move the repository perhaps to squeaksource.com
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Fractured Idiom:- MAZEL TON - Lots of luck
>
>
>


-- 
[:masashi | ^umezawa]

From commits at source.squeak.org  Sat Jul  4 18:51:48 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Sat, 4 Jul 2020 18:51:48 0000
Subject: [squeak-dev] The Trunk: ShoutCore-eem.84.mcz
Message-ID: <E1jrnGQ-00006k-7F@andreas>

Eliot Miranda uploaded a new version of ShoutCore to project The Trunk:
http://source.squeak.org/trunk/ShoutCore-eem.84.mcz

==================== Summary ====================

Name: ShoutCore-eem.84
Author: eem
Time: 4 July 2020, 11:51:47.113679 am
UUID: 56a7592a-90ef-4c61-8b03-51094781d61f
Ancestors: ShoutCore-mt.83

Shout robustness.  If anything goes wron with source file access (recursive errors in the debugger, etc) then method getSource may not answer sufficient text and a bounds violation can occur in Shout.  This prevents that.

=============== Diff against ShoutCore-mt.83 ===============

Item was changed:
  ----- Method: SHParserST80>>initializeVariablesFromContext (in category 'parse support') -----
  initializeVariablesFromContext
  
+ 	| contextSourcePcIndex contextSource contextSourceParser |
- 	| contextSourcePcIndex contextSourceParser |
  	contextSourcePcIndex := (context debuggerMap
  		rangeForPC: (context isDead ifTrue: [context endPC] ifFalse: [context pc])
  		in: context method
  		contextIsActiveContext: true "... to really use the context's pc.")
  			start.
+ 	contextSource := context method getSource.
  	contextSourceParser := self class new
  		classOrMetaClass: context method methodClass;
  		environment: self environment;
+ 		source: (contextSource first: (contextSourcePcIndex min: contextSource size));
- 		source: (context method getSource first: contextSourcePcIndex);
  		yourself.
  	contextSourceParser parse.
  	arguments := contextSourceParser activeArguments.
+ 	temporaries  := contextSourceParser activeTemporaries!
- 	temporaries  := contextSourceParser activeTemporaries.!


From asqueaker at gmail.com  Sat Jul  4 23:49:13 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Sat, 4 Jul 2020 18:49:13 -0500
Subject: [squeak-dev] Squeak on Ubuntu 18.04 desktop
In-Reply-To: <33786aa2-7c7b-0a55-4ae4-7320778e9562@gmail.com>
References: <CANzdToHrrmQj4uy3YuV-BR8Mzpd2yrfg6r6Y5U-zGMC02radUg@mail.gmail.com>
 <3ca47a10-9c1b-1009-dadd-3dc2396e9ab5@gmail.com>
 <CANzdToG=UO2mqcUq-3xBvVjAsVQh+bEZur0Bu4YdozkiJSRR2w@mail.gmail.com>
 <33786aa2-7c7b-0a55-4ae4-7320778e9562@gmail.com>
Message-ID: <CANzdToEF+Z6BMynnCKST4YSENGKSbZZ78PtAMVXdcoWySVqCzA@mail.gmail.com>

OMG, thank you so much Subbu, that did it!   :-D

The xprop command did already return that exact output, but it wasn't until
adding that line you said to my .desktop file that it worked.

99%, anyway.  I'd hoped I'd be able to have a .desktop file for a specific
image (so it can have its own icon, instead of the Squeak icon).

    # standard Squeak icon for launching any image
    Name=Squeak
    Exec=/usr/local/bin/spur %f
    Icon=/home/cmm/my/icons/Squeak-logo-white-background-68x51.png
    StartupWMClass=squeak
    ...

the other, for MyApp,

    # for launching MyApp's image.
    Name=MyApp
    Exec=/path/for/apps/vm/squeak.sh /path/for/apps/image/app.image
    Icon=/home/cmm/my/icons/My-App-logo.png
    StartupWMClass=squeak
    ...

I put both of the above into separate .desktop files at
~/.local/share/applications.  After an afternoon of tinkering, what I found
was a little strange -- for the icon, Ubuntu 18.04 seems to use whichever
desktop file was launched first.  However, even though it gets the icon
wrong, it at least uses the right Exec= vm specification.   I tried
changing the StartupWMClass on one of them, but it didn't work.  But, I can
at least work again..  :)

Thanks,
  Chris


On Sat, Jul 4, 2020 at 2:37 AM K K Subbu <kksubbu.ml at gmail.com> wrote:

> On 04/07/20 2:34 am, Chris Muller wrote:
> > But the problem is not actually Gnome's window manager -- it works
> > beautifully with _every other app_ *except* Squeak.
>
> Perhaps those apps come with properly configured .desktop file. Squeak
> does not ship with one.
>
> Could you please report Squeak app window has the right class?
>
> $ xprop WM_CLASS
> WM_CLASS(STRING) = "squeak", "Squeak"
>
> If this does not appear, then you will have to add one to your .desktop
> launcher file:
>
> StartupWMClass=squeak
>
> HTH .. Subbu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200704/286ddcdd/attachment.html>

From kksubbu.ml at gmail.com  Sun Jul  5 05:58:55 2020
From: kksubbu.ml at gmail.com (K K Subbu)
Date: Sun, 5 Jul 2020 11:28:55 +0530
Subject: [squeak-dev] Squeak on Ubuntu 18.04 desktop
In-Reply-To: <CANzdToEF+Z6BMynnCKST4YSENGKSbZZ78PtAMVXdcoWySVqCzA@mail.gmail.com>
References: <CANzdToHrrmQj4uy3YuV-BR8Mzpd2yrfg6r6Y5U-zGMC02radUg@mail.gmail.com>
 <3ca47a10-9c1b-1009-dadd-3dc2396e9ab5@gmail.com>
 <CANzdToG=UO2mqcUq-3xBvVjAsVQh+bEZur0Bu4YdozkiJSRR2w@mail.gmail.com>
 <33786aa2-7c7b-0a55-4ae4-7320778e9562@gmail.com>
 <CANzdToEF+Z6BMynnCKST4YSENGKSbZZ78PtAMVXdcoWySVqCzA@mail.gmail.com>
Message-ID: <d45f363f-b547-1a97-5f3c-ba68e57133d3@gmail.com>

On 05/07/20 5:19 am, Chris Muller wrote:
> I put both of the above into separate .desktop files at 
> ~/.local/share/applications.  After an afternoon of tinkering, what I 
> found was a little strange -- for the icon, Ubuntu 18.04 seems to use 
> whichever desktop file was launched first.  However, even though it gets 
> the icon wrong, it at least uses the right Exec= vm specification.   I 
> tried changing the StartupWMClass on one of them, but it didn't work. 
> But, I can at least work again..  :)
Chris,

XDG uses lazy binding for resource paths using many env variables, so it 
is best to use xdg-utils to get/set them and avoid hard-coded paths.  An 
easily overlooked aspect is that env variables for GUI launched programs 
come via .xsessionrc and not .bashrc or its relatives. So if your app 
works from command line but not from GUI launch, you know where to look 
;-). Getting everything right in 18.04 is a chore!

If you are developing your own launcher for your app, it is easier to 
use the gnome-desktop-icon-edit utility to create the .desktop launcher 
file.

For icons, it is better to create a theme with icons of different 
resolutions (start with one) and install them using xdg-icon-resource 
command (part of xdg-utils package).

HTH .. Subbu

From tim at rowledge.org  Mon Jul  6 01:12:34 2020
From: tim at rowledge.org (tim Rowledge)
Date: Sun, 5 Jul 2020 18:12:34 -0700
Subject: [squeak-dev] Buglet ins SIXX for Squeak 5.3
In-Reply-To: <CAO_ndyXnKntT99A0DjhnNUxMYW33ep5YHktLVjBLCOiH85O90Q@mail.gmail.com>
References: <E010D8DB-EDD4-42B2-B572-56B5C5275E99@rowledge.org>
 <CAO_ndyXnKntT99A0DjhnNUxMYW33ep5YHktLVjBLCOiH85O90Q@mail.gmail.com>
Message-ID: <A28BC9C7-3E41-4E23-A6B3-E1025CAF04DB@rowledge.org>

Thank you; I can confirm that it loads correctly on my Pi system.

> On 2020-07-04, at 9:50 AM, Masashi UMEZAWA <masashi.umezawa at gmail.com> wrote:
> 
> Hello Tim-san,
> 
> Thank you for the feedback.
> I've just updated ConfigurationOfSIXX on SqueakSource.com. Now SIXX
> can be easily installable to Squeak 5.3.
> I will also update SqueakMap entry soon.
> 
> Best regards,
> 
> 2020年7月3日(金) 10:32 tim Rowledge <tim at rowledge.org>:
>> 
>> I just spotted a small bug in the code loaded up for SIXX. After loading it into a clean 5.3 image XMLDOMParser class>>#initialize & XMLDOMParser class>>#unload  are reverted to old and out of date versions.
>> 
>> Installer code used -
>> Installer squeaksource
>>    project: 'MetacelloRepository';
>>    install: 'ConfigurationOfSIXX'.
>> (Smalltalk at: #ConfigurationOfSIXX) load.
>> 
>> Looks like the ConfigurationOfSIXX>>#version051: method is causing the load of
>> `
>> spec for: #squeak do:[
>>                spec
>>                        package: 'XML-Parser' with: [
>>                                spec file: 'XML-Parser-ul.44';
>>                                        repository: 'http://source.squeak.org/squeak52'
>> `
>> and that in turn re-loads old versions of XMLDOMParser class>>#initialize & XMLDOMParser class>>#unload - and they try to use the deprecated #registerFileReader: in FileList instead of FileServices.
>> 
>> I *think* it looks like ConfigurationOfSIXX>>#baseline06: requires the above section removing - but I am most definitely not any sort of expert in the ConfigurationOfXXXXXX stuff.
>> 
>> It appears that  Masashi-san is still caring for this package since there was a commit in january of this year, so if you could please Do The Magic(™).
>> 
>> And since SmalltalkHub is now deprecated it could be a good idea to move the repository perhaps to squeaksource.com
>> 
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Fractured Idiom:- MAZEL TON - Lots of luck
>> 
>> 
>> 
> 
> 
> -- 
> [:masashi | ^umezawa]
> 
> 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: MII: Mask all Interrupts and then Interrupt



From Das.Linux at gmx.de  Mon Jul  6 10:02:03 2020
From: Das.Linux at gmx.de (Tobias Pape)
Date: Mon, 6 Jul 2020 12:02:03 +0200
Subject: [squeak-dev] SqueakSSL Error when updating my image
In-Reply-To: <7e48aa65dc24437c9afddf947ba8396a@student.hpi.uni-potsdam.de>
References: <7e48aa65dc24437c9afddf947ba8396a@student.hpi.uni-potsdam.de>
Message-ID: <A7581B37-7DFB-43D2-B931-3A8ECA295762@gmx.de>


> On 12.06.2020, at 15:35, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
> 
> Hi all,
> 
> maybe someone is interested in this error I received when updating my image this week in the debug console:
> 
> LoadLibrary(SqueakSSL) (998: Unzuläÿssiger Zugriff auf einen Speicherbereich.
> 
> )
> LoadLibrary(SqueakSSL.dll) (998: Unzuläÿssiger Zugriff auf einen Speicherbereich.
> 
> )
> 
> Translated to English: SqueakSSL complains about an access violation twice. And by the way, at some point, there happens an interesting encoding error.
> 
> Everything else seems to work, I just wanted to mention this warning. Is this an error in the plugin?

Rather in the way libs are loaded.
I don't know, This does not seem to be SqueakSSL specific, as it happens before the dll has been completely loaded (LoadLibrary):

This is from the respective file:

**************************************
  lstrcpy(libName,prefix);
  lstrcat(libName,baseName);
  lstrcat(libName,postfix);
  h = LoadLibrary(libName);
  if (h == NULL
#ifdef NDEBUG /* in production ignore errors for non-existent modules */
   && GetLastError() != ERROR_MOD_NOT_FOUND
#endif
      )
    vprintLastError(TEXT("LoadLibrary(%s)"), libName);
  return h;
**************************************


But maybe it is the dll itself that does strange things during DllMain or so. I don't see why tho…

Best regards
	-Tobias

From tim at rowledge.org  Mon Jul  6 16:57:46 2020
From: tim at rowledge.org (tim Rowledge)
Date: Mon, 6 Jul 2020 09:57:46 -0700
Subject: [squeak-dev] SqueakSSL Error when updating my image
In-Reply-To: <A7581B37-7DFB-43D2-B931-3A8ECA295762@gmx.de>
References: <7e48aa65dc24437c9afddf947ba8396a@student.hpi.uni-potsdam.de>
 <A7581B37-7DFB-43D2-B931-3A8ECA295762@gmx.de>
Message-ID: <16C0CAB2-E2C0-4A91-91A3-56D946D72D48@rowledge.org>

Any chance this relates to the failures (as in, complete failure, test broken) of the ssl socket stuff? Be nice to solve that one sometime.

> On 2020-07-06, at 3:02 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
> 
>> On 12.06.2020, at 15:35, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>> 
>> Hi all,
>> 
>> maybe someone is interested in this error I received when updating my image this week in the debug console:
>> 
>> LoadLibrary(SqueakSSL) (998: Unzuläÿssiger Zugriff auf einen Speicherbereich.
>> 
>> )
>> LoadLibrary(SqueakSSL.dll) (998: Unzuläÿssiger Zugriff auf einen Speicherbereich.
>> 
>> )
>> 
>> Translated to English: SqueakSSL complains about an access violation twice. And by the way, at some point, there happens an interesting encoding error.
>> 
>> Everything else seems to work, I just wanted to mention this warning. Is this an error in the plugin?
> 
> Rather in the way libs are loaded.
> I don't know, This does not seem to be SqueakSSL specific, as it happens before the dll has been completely loaded (LoadLibrary):
> 
> This is from the respective file:
> 
> **************************************
>  lstrcpy(libName,prefix);
>  lstrcat(libName,baseName);
>  lstrcat(libName,postfix);
>  h = LoadLibrary(libName);
>  if (h == NULL
> #ifdef NDEBUG /* in production ignore errors for non-existent modules */
>   && GetLastError() != ERROR_MOD_NOT_FOUND
> #endif
>      )
>    vprintLastError(TEXT("LoadLibrary(%s)"), libName);
>  return h;
> **************************************
> 
> 
> But maybe it is the dll itself that does strange things during DllMain or so. I don't see why tho…
> 
> Best regards
> 	-Tobias
> 
> 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- "Body by Fisher -- brains by Mattel."



From Das.Linux at gmx.de  Mon Jul  6 17:05:07 2020
From: Das.Linux at gmx.de (Tobias Pape)
Date: Mon, 6 Jul 2020 19:05:07 +0200
Subject: [squeak-dev] SqueakSSL Error when updating my image
In-Reply-To: <16C0CAB2-E2C0-4A91-91A3-56D946D72D48@rowledge.org>
References: <7e48aa65dc24437c9afddf947ba8396a@student.hpi.uni-potsdam.de>
 <A7581B37-7DFB-43D2-B931-3A8ECA295762@gmx.de>
 <16C0CAB2-E2C0-4A91-91A3-56D946D72D48@rowledge.org>
Message-ID: <66180E62-5DDD-408C-8458-A76895C78AF2@gmx.de>


> On 06.07.2020, at 18:57, tim Rowledge <tim at rowledge.org> wrote:
> 
> Any chance this relates to the failures (as in, complete failure, test broken) of the ssl socket stuff? Be nice to solve that one sometime.
> 

i don't think so…

>> On 2020-07-06, at 3:02 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> 
>>> On 12.06.2020, at 15:35, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>>> 
>>> Hi all,
>>> 
>>> maybe someone is interested in this error I received when updating my image this week in the debug console:
>>> 
>>> LoadLibrary(SqueakSSL) (998: Unzuläÿssiger Zugriff auf einen Speicherbereich.
>>> 
>>> )
>>> LoadLibrary(SqueakSSL.dll) (998: Unzuläÿssiger Zugriff auf einen Speicherbereich.
>>> 
>>> )
>>> 
>>> Translated to English: SqueakSSL complains about an access violation twice. And by the way, at some point, there happens an interesting encoding error.
>>> 
>>> Everything else seems to work, I just wanted to mention this warning. Is this an error in the plugin?
>> 
>> Rather in the way libs are loaded.
>> I don't know, This does not seem to be SqueakSSL specific, as it happens before the dll has been completely loaded (LoadLibrary):
>> 
>> This is from the respective file:
>> 
>> **************************************
>> lstrcpy(libName,prefix);
>> lstrcat(libName,baseName);
>> lstrcat(libName,postfix);
>> h = LoadLibrary(libName);
>> if (h == NULL
>> #ifdef NDEBUG /* in production ignore errors for non-existent modules */
>>  && GetLastError() != ERROR_MOD_NOT_FOUND
>> #endif
>>     )
>>   vprintLastError(TEXT("LoadLibrary(%s)"), libName);
>> return h;
>> **************************************
>> 
>> 
>> But maybe it is the dll itself that does strange things during DllMain or so. I don't see why tho…
>> 
>> Best regards
>> 	-Tobias
>> 
>> 
> 
> 
> tim




From eliot.miranda at gmail.com  Mon Jul  6 19:31:08 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Mon, 6 Jul 2020 12:31:08 -0700
Subject: [squeak-dev] AllocationTest>>#testOutOfMemorySignal fails on
 32bit system
In-Reply-To: <487AA985-9050-4849-90D5-2B0E81BD9EB9@rowledge.org>
References: <487AA985-9050-4849-90D5-2B0E81BD9EB9@rowledge.org>
Message-ID: <CAC20JE1tOYr5MMocbpRV2DhFN5V4_v-9H4GuGUyqmdhf2j3MAw@mail.gmail.com>

Hi Tim,

On Thu, Jul 2, 2020 at 4:35 PM tim Rowledge <tim at rowledge.org> wrote:

> On a Raspberry Pi OS 32bit this test fails because of an oversight - the
> parameter passed to vmParameterAt:put: cannot exceed SmallInteger maxVal.
> It makes the careful testing for 32/64bit image seem a bit silly.
>

On looking at the VM codee it's clear that this is really a VM bug, and the
vmParameter primitives really should accept/return full width integers for
this parameter.  I've fixed it and pushed.  So feel free to revert the
image fix at some stage.

This means we can only ask for up to ~1GB space for free space on a 32bit
> image system and so I propose to clamp the requested value in
> AllocationTest>>#setFreeSpaceLimitOf:around: There don't appear to be any
> other places right now that need attention.
>
> If I don't hear any outraged screams soon I'll just commit it to trunk.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: IG: Insert Garbage
>

I have a whole architecture for this ;-)

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200706/5e35efd4/attachment.html>

From marianopeck at gmail.com  Wed Jul  8 14:36:40 2020
From: marianopeck at gmail.com (Mariano Martinez Peck)
Date: Wed, 8 Jul 2020 11:36:40 -0300
Subject: [squeak-dev] Webminar about VA Smalltalk new OS Process
	Framework
In-Reply-To: <CAA+-=mWM95DNTYhq02uwPyW4-kXVG0PZ1+eO1QQO3hyO9tyZCQ@mail.gmail.com>
References: <CAA+-=mWM95DNTYhq02uwPyW4-kXVG0PZ1+eO1QQO3hyO9tyZCQ@mail.gmail.com>
Message-ID: <CAA+-=mX-o_Ho0+f1pd1F0tr26GSb9PPriT=hm=m44F4Uy4pxkA@mail.gmail.com>

Greetings all, This is a friendly reminder of the presentation we will host
tomorrow for VAST's newest OSProcess framework. Best regards,

On Tue, Jun 30, 2020 at 10:25 AM Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

> Greetings all,
>
> Some time ago, I had the pleasure and privilege of being sponsored by the
> Pharo Consortium to implement OSSubprocess. Because of that work, I quickly
> realized that a new OS process framework created by Instantiations was
> quite advanced and unlike anything I had seen before.  If you are able, I
> would highly recommend that you attend the technology preview of this
> framework coming to VAST 2021:
>
> Seth Berman will be presenting, registration here:
> https://attendee.gotowebinar.com/register/7491754880594201356
>
> We hope the community can attend and we look forward to your feedback and
> questions during the event's Q&A session.
>
> Best regards,
>
> --
> Mariano Martinez Peck
> Email: marianopeck at gmail.com
> Twitter: @MartinezPeck
> LinkedIn: www.linkedin.com/in/mariano-martinez-peck
> <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
> Blog: https://marianopeck.wordpress.com/
>


-- 
Mariano Martinez Peck
Email: marianopeck at gmail.com
Twitter: @MartinezPeck
LinkedIn: www.linkedin.com/in/mariano-martinez-peck
<https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
Blog: https://marianopeck.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200708/19c6d7b2/attachment.html>

From commits at source.squeak.org  Thu Jul  9 13:54:04 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Thu, 9 Jul 2020 13:54:04 0000
Subject: [squeak-dev] The Trunk: CommandLine-TheresaHMartenK.17.mcz
Message-ID: <E1jtX02-0002qF-2T@andreas>

Patrick Rein uploaded a new version of CommandLine to project The Trunk:
http://source.squeak.org/trunk/CommandLine-TheresaHMartenK.17.mcz

==================== Summary ====================

Name: CommandLine-TheresaHMartenK.17
Author: TheresaHMartenK
Time: 20 June 2020, 4:33:21.503561 pm
UUID: 1e990100-46c5-7b4a-966c-d1908837d2ca
Ancestors: CommandLine-mt.16

Same reason as: ToolBuilder-Morphic-TheresaHMartenK.261

Copy:
The current implementation searches for the supplied answer in the valueList and if found returns the value at the found index in the valueList which of course is the supplied answer. However from the behaviour that gets mimicked you would expect the implementation to look for the suppliedAnswer in the labelList - the same as you click on the label and not on its connected value. Additionally this produces less readable / understandable code compared to supplying the label, especially if the value happens to be a block.

With the new implementation, the answer is searched in the labelList, and the returned value is the coresponding value from the valueList.

=============== Diff against CommandLine-mt.16 ===============

Item was changed:
  ----- Method: DummyUIManager>>chooseFrom:values:lines:title: (in category 'ui requests') -----
  chooseFrom: labelList values: valueList lines: linesArray title: aString
  	self askForProvidedAnswerTo: aString ifSupplied: [:answer | 
  		(answer = #cancel or: [answer isNil]) ifTrue: [^ nil].
+ 		^ valueList at: (labelList indexOf: answer) ifAbsent: [
- 		^ valueList at: (valueList indexOf: answer) ifAbsent: [
  				answer isNumber 
  					ifTrue: [valueList at: answer ifAbsent: [nil]]
  					ifFalse: [nil]]].
  	
  	^ valueList first!


From commits at source.squeak.org  Thu Jul  9 13:54:15 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Thu, 9 Jul 2020 13:54:15 0000
Subject: [squeak-dev] The Trunk: ToolBuilder-MVC-TheresaHMartenK.60.mcz
Message-ID: <E1jtX0C-0002qJ-S2@andreas>

Patrick Rein uploaded a new version of ToolBuilder-MVC to project The Trunk:
http://source.squeak.org/trunk/ToolBuilder-MVC-TheresaHMartenK.60.mcz

==================== Summary ====================

Name: ToolBuilder-MVC-TheresaHMartenK.60
Author: TheresaHMartenK
Time: 20 June 2020, 4:32:44.419561 pm
UUID: ce7849e7-d47c-434e-8bbd-f6ec2b896a4c
Ancestors: ToolBuilder-MVC-mt.59

Same reason as: ToolBuilder-Morphic-TheresaHMartenK.261

Copy:
The current implementation searches for the supplied answer in the valueList and if found returns the value at the found index in the valueList which of course is the supplied answer. However from the behaviour that gets mimicked you would expect the implementation to look for the suppliedAnswer in the labelList - the same as you click on the label and not on its connected value. Additionally this produces less readable / understandable code compared to supplying the label, especially if the value happens to be a block.

With the new implementation, the answer is searched in the labelList, and the returned value is the coresponding value from the valueList.

=============== Diff against ToolBuilder-MVC-mt.59 ===============

Item was changed:
  ----- Method: MVCUIManager>>chooseFrom:values:lines:title: (in category 'ui requests') -----
  chooseFrom: labelList values: valueList lines: linesArray title: aString
  	"Choose an item from the given list. Answer the selected item."
  	| menu |
  	self askForProvidedAnswerTo: aString ifSupplied: [:answer | 
  		(answer = #cancel or: [answer isNil]) ifTrue: [^ nil].
+ 		^ valueList at: (labelList indexOf: answer) ifAbsent: [
- 		^ valueList at: (valueList indexOf: answer) ifAbsent: [
  				answer isNumber 
  					ifTrue: [valueList at: answer ifAbsent: [nil]]
  					ifFalse: [nil]]].
  	
  	menu := SelectionMenu labels: labelList lines: linesArray selections: valueList.
  	^ aString 
  		ifEmpty: [menu startUp] 
  		ifNotEmpty: [menu startUpWithCaption: aString]!


From commits at source.squeak.org  Thu Jul  9 13:54:25 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Thu, 9 Jul 2020 13:54:25 0000
Subject: [squeak-dev] The Trunk: ToolBuilder-Morphic-TheresaHMartenK.261.mcz
Message-ID: <E1jtX0N-0002qN-6G@andreas>

Patrick Rein uploaded a new version of ToolBuilder-Morphic to project The Trunk:
http://source.squeak.org/trunk/ToolBuilder-Morphic-TheresaHMartenK.261.mcz

==================== Summary ====================

Name: ToolBuilder-Morphic-TheresaHMartenK.261
Author: TheresaHMartenK
Time: 20 June 2020, 4:04:09.471561 pm
UUID: ec0bd065-4cc8-7d48-b940-4bf5a0f4a7cf
Ancestors: ToolBuilder-Morphic-mt.260

The current implementation searches for the supplied answer in the valueList and if found returns the value at the found index in the valueList which of course is the supplied answer. However from the behaviour that gets mimicked you would expect the implementation to look for the suppliedAnswer in the labelList - the same as you click on the label and not on its connected value. Additionally this produces less readable / understandable code compared to supplying the label, especially if the value happens to be a block.

With the new implementation, the answer is searched in the labelList, and the returned value is the coresponding value from the valueList.

=============== Diff against ToolBuilder-Morphic-mt.260 ===============

Item was changed:
  ----- Method: MorphicUIManager>>chooseFrom:values:lines:title: (in category 'ui requests') -----
  chooseFrom: labelList values: valueList lines: linesArray title: aString 
  	"Choose an item from the given list. Answer the selected item."
  	
  	| index |
  	self askForProvidedAnswerTo: aString ifSupplied: [:answer | 
  		(answer = #cancel or: [answer isNil]) ifTrue: [^ nil].
+ 		^ valueList at: (labelList indexOf: answer) ifAbsent: [
- 		^ valueList at: (valueList indexOf: answer) ifAbsent: [
  				answer isNumber 
  					ifTrue: [valueList at: answer ifAbsent: [nil]]
  					ifFalse: [nil]]].
  	
  	index := self chooseFrom: labelList lines: linesArray title: aString.
  	^ index = 0
  		ifTrue: [ nil ]
  		ifFalse: [ valueList at: index ]!


From commits at source.squeak.org  Thu Jul  9 13:54:59 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Thu, 9 Jul 2020 13:54:59 0000
Subject: [squeak-dev] The Trunk: ToolBuilder-Morphic-pre.262.mcz
Message-ID: <E1jtX0v-0002rP-JX@andreas>

Patrick Rein uploaded a new version of ToolBuilder-Morphic to project The Trunk:
http://source.squeak.org/trunk/ToolBuilder-Morphic-pre.262.mcz

==================== Summary ====================

Name: ToolBuilder-Morphic-pre.262
Author: pre
Time: 9 July 2020, 3:52:09.108909 pm
UUID: 55e57017-8d67-424f-9a7b-2b64ed8af8af
Ancestors: ToolBuilder-Morphic-tpr.261, ToolBuilder-Morphic-TheresaHMartenK.261

Merge of ToolBuilder-Morphic-TheresaHMartenK.261

The current implementation searches for the supplied answer in the valueList and if found returns the value at the found index in the valueList which of course is the supplied answer. However from the behaviour that gets mimicked you would expect the implementation to look for the suppliedAnswer in the labelList - the same as you click on the label and not on its connected value. Additionally this produces less readable / understandable code compared to supplying the label, especially if the value happens to be a block.

With the new implementation, the answer is searched in the labelList, and the returned value is the coresponding value from the valueList.

=============== Diff against ToolBuilder-Morphic-tpr.261 ===============

Item was changed:
  ----- Method: MorphicUIManager>>chooseFrom:values:lines:title: (in category 'ui requests') -----
  chooseFrom: labelList values: valueList lines: linesArray title: aString 
  	"Choose an item from the given list. Answer the selected item."
  	
  	| index |
  	self askForProvidedAnswerTo: aString ifSupplied: [:answer | 
  		(answer = #cancel or: [answer isNil]) ifTrue: [^ nil].
+ 		^ valueList at: (labelList indexOf: answer) ifAbsent: [
- 		^ valueList at: (valueList indexOf: answer) ifAbsent: [
  				answer isNumber 
  					ifTrue: [valueList at: answer ifAbsent: [nil]]
  					ifFalse: [nil]]].
  	
  	index := self chooseFrom: labelList lines: linesArray title: aString.
  	^ index = 0
  		ifTrue: [ nil ]
  		ifFalse: [ valueList at: index ]!


From ron at usmedrec.com  Thu Jul  9 18:47:18 2020
From: ron at usmedrec.com (Ron Teitelbaum)
Date: Thu, 9 Jul 2020 14:47:18 -0400
Subject: [squeak-dev] Mailing Lists Admin
Message-ID: <CAEzdQ-ft3_5_EDaGU_PzB-aXv4Xg+TSrVW5q3Mqzcr64GNfrjQ@mail.gmail.com>

Hi All,

I need to reset the elections list admin password.  Who should I talk to
about that?  I'm not sure who manages the high level admin for lists.

Thanks!

Ron Teitelbaum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200709/eef7145d/attachment.html>

From tim at rowledge.org  Thu Jul  9 20:39:42 2020
From: tim at rowledge.org (tim Rowledge)
Date: Thu, 9 Jul 2020 13:39:42 -0700
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <20200703222607.GA76689@shell.msen.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CA+CiqoW0rQ3yS5WQVn4Vu+Dg6M3NeCeLj60wWRS=cOFQ8r4D=w@mail.gmail.com>
 <CAN7OfXQyzSK500arwGvnSktLy_b9=RTjvENfLoW3YSraX2E2OQ@mail.gmail.com>
 <8466da4b-2ded-daaa-645b-573271857b67@zogotounga.net>
 <rdnlil$b44$1@ciao.gmane.io> <20200703202118.GB52195@shell.msen.com>
 <rdo4kh$h4o$1@ciao.gmane.io>
 <3E4824E0-D3B1-4A7D-B301-A73228785FC6@rowledge.org>
 <20200703222607.GA76689@shell.msen.com>
Message-ID: <5DD6E594-6DC4-423B-ABED-AA2B7AAF9AC9@rowledge.org>

What are we going to actually try to do here? Who has time/interest/skill?

Yes, Juan's suggested bitblt improvements sound good. Indeed pretty much anything he's done would be. This all has the advantage of being 'in system' too, with maybe some VM work to get the best results.

Connecting to outside libraries always has costs; after all they're not exactly likely to be set up just as we'd like. An advantage of a decent open source library is that we could at least consider hacking at it to make a version that talks nicely to our bitmaps instead of of messing around with copy/convert to get the results back. More work though... Another option *might* be to use the algorithms if we can't really use the code. Still more work.

We have a framework for dynamic translation in the cog vms. We could use much of it to do dynamically translated bitblts. The ARM specialised bitblt code kinda-sorta does that but we could do much better I think. Maybe that would make borrowing algorithms more sensible than linking to an outside library?

I'm not a huge fan of a direct connect to openGL because of the issues like Apple not supporting it any more, and which version can a Raspberry Pi run etc. That might make sometihng like Skia more sensible since it seems to be aimed at multiple back ends and so maybe we could benefit indirectly. Of course, it leaves us vulnerable to Error 33.

The Nile/Gezira stuff obviously sounds great but there is the question of actually getting it working usefully, let alone finishing it. Will that ever happen? Is what exists good enough and complete enough to be of use? 

There is a downloadable 'Frank' image that seems to start up ok at http://tinlizzie.org/~ohshima/Frank-170908.zip  It is a Squeak 4.4 image as far as I can tell so you need an older VM of roughly that vintage - pre-Spur anyway.

The small examples mostly work ok (see things like GeziraCanvas class>example* & GZKernel class>example*) though one or two take a very long time.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
State-of-the-art: What we could do with enough money.



From tim at rowledge.org  Fri Jul 10 00:13:12 2020
From: tim at rowledge.org (tim Rowledge)
Date: Thu, 9 Jul 2020 17:13:12 -0700
Subject: [squeak-dev] squeak logging package(s)
Message-ID: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>

I'm looking for some good message logging stuff - something a little more flexible that `Transcript show:` level - and so far the best I can see is a rather old package on squeaksource named 'Logging' originally by Keith Hodges but with quite a few updates by Mat Fulmer.

I wonder if anyone is using it in a current image? It seems to rely on some process specific variable code that *looks* like has been incorporated into the trunk. I don't want to spend too much time peering at it is somebody else already knows whether it is unusable now or better yet still 'load and go'

Or indeed, it somebody has a pointer to sometihng newer/better/shinier?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Ubi dubium ibi libertas


From tim at rowledge.org  Fri Jul 10 00:24:09 2020
From: tim at rowledge.org (tim Rowledge)
Date: Thu, 9 Jul 2020 17:24:09 -0700
Subject: [squeak-dev] Buglet ins SIXX for Squeak 5.3
In-Reply-To: <A28BC9C7-3E41-4E23-A6B3-E1025CAF04DB@rowledge.org>
References: <E010D8DB-EDD4-42B2-B572-56B5C5275E99@rowledge.org>
 <CAO_ndyXnKntT99A0DjhnNUxMYW33ep5YHktLVjBLCOiH85O90Q@mail.gmail.com>
 <A28BC9C7-3E41-4E23-A6B3-E1025CAF04DB@rowledge.org>
Message-ID: <CA0808E3-6872-4A0D-B23A-885223231158@rowledge.org>

Oops - another small SIXX issue.

Preferences class>>#sixxStorePreferencesIn: refers to an Undeclared 'DictionaryOfPreferences' which I suspect might need to be changed to refer to 'preferencesDictionary'. Although possibly using 'self allPreferences' might do better since it rejects deprecated items.

> On 2020-07-05, at 6:12 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
> Thank you; I can confirm that it loads correctly on my Pi system.
> 
>> On 2020-07-04, at 9:50 AM, Masashi UMEZAWA <masashi.umezawa at gmail.com> wrote:
>> 
>> Hello Tim-san,
>> 
>> Thank you for the feedback.
>> I've just updated ConfigurationOfSIXX on SqueakSource.com. Now SIXX
>> can be easily installable to Squeak 5.3.
>> I will also update SqueakMap entry soon.
>> 
>> Best regards,
>> 
>> 2020年7月3日(金) 10:32 tim Rowledge <tim at rowledge.org>:
>>> 
>>> I just spotted a small bug in the code loaded up for SIXX. After loading it into a clean 5.3 image XMLDOMParser class>>#initialize & XMLDOMParser class>>#unload  are reverted to old and out of date versions.
>>> 
>>> Installer code used -
>>> Installer squeaksource
>>>   project: 'MetacelloRepository';
>>>   install: 'ConfigurationOfSIXX'.
>>> (Smalltalk at: #ConfigurationOfSIXX) load.
>>> 
>>> Looks like the ConfigurationOfSIXX>>#version051: method is causing the load of
>>> `
>>> spec for: #squeak do:[
>>>               spec
>>>                       package: 'XML-Parser' with: [
>>>                               spec file: 'XML-Parser-ul.44';
>>>                                       repository: 'http://source.squeak.org/squeak52'
>>> `
>>> and that in turn re-loads old versions of XMLDOMParser class>>#initialize & XMLDOMParser class>>#unload - and they try to use the deprecated #registerFileReader: in FileList instead of FileServices.
>>> 
>>> I *think* it looks like ConfigurationOfSIXX>>#baseline06: requires the above section removing - but I am most definitely not any sort of expert in the ConfigurationOfXXXXXX stuff.
>>> 
>>> It appears that  Masashi-san is still caring for this package since there was a commit in january of this year, so if you could please Do The Magic(™).
>>> 
>>> And since SmalltalkHub is now deprecated it could be a good idea to move the repository perhaps to squeaksource.com
>>> 
>>> tim
>>> --
>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>> Fractured Idiom:- MAZEL TON - Lots of luck
>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> [:masashi | ^umezawa]
>> 
>> 
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: MII: Mask all Interrupts and then Interrupt
> 
> 



tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Inoculatte (v): To take coffee intravenously when you are running late



From stephen at heaveneverywhere.com  Fri Jul 10 06:12:07 2020
From: stephen at heaveneverywhere.com (stephen at heaveneverywhere.com)
Date: Thu, 9 Jul 2020 23:12:07 -0700
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
Message-ID: <5593C678-5CD0-43D7-A72A-84B4C3D92A7B@heaveneverywhere.com>


…on a related topic, I’ve started porting old-school MVC* to Cuis with the intention of replacing Morphic with a generic framework that can be back-ended by BitBLT, OpenGL or HTML5.

Anybody want to help?

Stephen

* = starting with traditional MVC classes and system windows, and following that with some version of the “Wrapper” framework as still used in VisualWorks.


--

                    Stephen Travis Pope   Santa Barbara, California, USA    
          http://HeavenEverywhere.com <http://heaveneverywhere.com/>        http://FASTLabInc.com <http://fastlabinc.com/>
                       https://vimeo.com/user19434036/videos <https://vimeo.com/user19434036/videos>      http://heaveneverywhere.com/Reflections

--



> On Jun 28, 2020, at 5:53 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
> Seriously. We've been sitting around twiddling thumbs about better graphics for decades now. 
> 
> We had Balloon2D & 3D.
> We had 'Pooh graphics' to do vector forms.
> We have some excellent stuff being done by the Cuis crew.
> We have some amazing ideas from Nile/Gezira.
> We have a number of potential 3rd party graphics libraries we might adopt.
> We have an advanced JIT that could be used to make on-demand graphics routines either on their own or working with pretty much any of the above.
> We probably have other options I've not even heard of.
> 
> Maybe we should actually do something? Can we at least talk about it?
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: SVE: Skip on Vernal Equinox
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200709/7ebac96f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 2442 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200709/7ebac96f/attachment.tiff>

From craig at blackpagedigital.com  Fri Jul 10 08:12:56 2020
From: craig at blackpagedigital.com (Craig Latta)
Date: Fri, 10 Jul 2020 01:12:56 -0700
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
Message-ID: <re97u9$kkk$1@ciao.gmane.io>


Hi Tim--

> Seriously. We've been sitting around twiddling thumbs about better
> graphics for decades now.

     I'd like to see a concise description of the problem. You used the
word "better", so I take it you find the current graphics deficient. How?

     I'm interested in the topic, and have some time. At the moment, all
my graphics energy goes into leveraging in SqueakJS what others have
done for web browsers, which is quite a lot.


     thanks!

-C

--
Craig Latta
Black Page Digital
Berkeley, California, USA
craig at blackpagedigital.com
+1 415 287 3547



From trygver at ifi.uio.no  Fri Jul 10 09:43:28 2020
From: trygver at ifi.uio.no (Trygve Reenskaug)
Date: Fri, 10 Jul 2020 11:43:28 +0200
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
Message-ID: <80554514-75d6-1431-061e-73d80d281add@ifi.uio.no>

I once did a VW program that logged the messages received by the 
instances of a class. It was easy to code; the challenge was filtering. 
I abandoned the program because its long logs didn't tell me anything 
new. (Logging even a few seconds of /all /messages is prohibitive, there 
are too many of them).

My principle was simple. AFAICR, the code went something like this:

 1. All messages handled by a class pass through its /methodDict/. Make
    a copy of this dict, say /methodDictCopy/
 2. Automatically create a new set of methods for the original
    /methodDict /according to their number of arguments:
    aClass>>perform: aSymbol
    /or /aClass>>perform: aSymbol with: firstObject etc.
    In this method,
          Log message to a file, if wanted.
          Look up the requested method in /methodDictCopy.
    /Execute it.

As I said above, the scheme worked, but it was never used in practice 
because I didn't find it useful. Its weakness is that it only logs 
messages received by instances of one class. An advantage is that it 
does not require any changes to the VM. What's needed is a log of the 
messages flowing between selected instances of many classes. The above 
scheme could be extended to do that, but I thought the description 
belonged to the design stage. May be it could be a reverse engineering tool?

I used the OORAM role modeling tool to move the description of the 
message flows from the execution to the design stage. This tool helped 
the programmer design the answer to three questions: What are the 
objects? How are they interconnected? What do they do? With these three 
answers, the implementation with classes was straight-forward.

I later moved the description from the design stage to the coding stage 
with the /DCI programming paradigm/.

Today, I code the flow of messages explicitly. I have also extended the 
Squeak universe of objects with all objects available through an IoT. 
Alan's object orientation is now literally realized in practice: “/…its 
semantics are a bit like having thousands and thousands of computers all 
hooked together by a very fast network./” But that is another story.

  TRee

On 2020-07-10 02:13, tim Rowledge wrote:
> I'm looking for some good message logging stuff - something a little more flexible that `Transcript show:` level - and so far the best I can see is a rather old package on squeaksource named 'Logging' originally by Keith Hodges but with quite a few updates by Mat Fulmer.
>
> I wonder if anyone is using it in a current image? It seems to rely on some process specific variable code that *looks* like has been incorporated into the trunk. I don't want to spend too much time peering at it is somebody else already knows whether it is unusable now or better yet still 'load and go'
>
> Or indeed, it somebody has a pointer to sometihng newer/better/shinier?
>
> tim
> --
> tim Rowledge;tim at rowledge.org;http://www.rowledge.org/tim
> Ubi dubium ibi libertas
>
>

-- 

/The essence of object orientation is that objects collaborateto achieve 
a goal. /
Trygve Reenskaug mailto: trygver at ifi.uio.no <mailto:%20trygver at ifi.uio.no>
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway                     Tel: (+47) 468 58 625

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200710/ef54f278/attachment.html>

From davide.grandi at email.it  Fri Jul 10 10:57:15 2020
From: davide.grandi at email.it (Davide Grandi)
Date: Fri, 10 Jul 2020 12:57:15 +0200
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
Message-ID: <25a68fdc-f2e3-14f4-cf54-7db66013dca9@email.it>

slicing a small slice of log4* ?
*doc => all classes : not too many classes.

"they" stole sUnit ... so we can slice log4*.

https://logging.apache.org/log4j/2.x/log4j-api/apidocs/index.html

(sorry, just my 0,02€)

Cheers,

     Davide

On 10/07/2020 02:13, tim Rowledge wrote:
> I'm looking for some good message logging stuff - something a little more flexible that `Transcript show:` level - and so far the best I can see is a rather old package on squeaksource named 'Logging' originally by Keith Hodges but with quite a few updates by Mat Fulmer.
>
> I wonder if anyone is using it in a current image? It seems to rely on some process specific variable code that *looks* like has been incorporated into the trunk. I don't want to spend too much time peering at it is somebody else already knows whether it is unusable now or better yet still 'load and go'
>
> Or indeed, it somebody has a pointer to sometihng newer/better/shinier?
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Ubi dubium ibi libertas

-- 
Ing. Davide Grandi
email    : davide.grandi at email.it
mobile   : +39 339 7468 778
linkedin : http://linkedin.com/in/davidegrandi


From marianopeck at gmail.com  Fri Jul 10 13:56:12 2020
From: marianopeck at gmail.com (Mariano Martinez Peck)
Date: Fri, 10 Jul 2020 10:56:12 -0300
Subject: [squeak-dev] Webminar about VA Smalltalk new OS Process
	Framework
In-Reply-To: <CAA+-=mX-o_Ho0+f1pd1F0tr26GSb9PPriT=hm=m44F4Uy4pxkA@mail.gmail.com>
References: <CAA+-=mWM95DNTYhq02uwPyW4-kXVG0PZ1+eO1QQO3hyO9tyZCQ@mail.gmail.com>
 <CAA+-=mX-o_Ho0+f1pd1F0tr26GSb9PPriT=hm=m44F4Uy4pxkA@mail.gmail.com>
Message-ID: <CAA+-=mWnUTjsBX6FXBtHJtV47AoSp3CkzwsBrNcEv-5JGzVPWA@mail.gmail.com>

Thank you everyone for attending. For those that missed it (or want to
re-watch it hahahaha), below is the link to YouTube:

https://youtu.be/uwEu_-tflKg

Best regards,



On Wed, Jul 8, 2020 at 11:36 AM Mariano Martinez Peck <marianopeck at gmail.com>
wrote:

> Greetings all, This is a friendly reminder of the presentation we will
> host tomorrow for VAST's newest OSProcess framework. Best regards,
>
> On Tue, Jun 30, 2020 at 10:25 AM Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>> Greetings all,
>>
>> Some time ago, I had the pleasure and privilege of being sponsored by the
>> Pharo Consortium to implement OSSubprocess. Because of that work, I quickly
>> realized that a new OS process framework created by Instantiations was
>> quite advanced and unlike anything I had seen before.  If you are able, I
>> would highly recommend that you attend the technology preview of this
>> framework coming to VAST 2021:
>>
>> Seth Berman will be presenting, registration here:
>> https://attendee.gotowebinar.com/register/7491754880594201356
>>
>> We hope the community can attend and we look forward to your feedback and
>> questions during the event's Q&A session.
>>
>> Best regards,
>>
>> --
>> Mariano Martinez Peck
>> Email: marianopeck at gmail.com
>> Twitter: @MartinezPeck
>> LinkedIn: www.linkedin.com/in/mariano-martinez-peck
>> <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
>> Blog: https://marianopeck.wordpress.com/
>>
>
>
> --
> Mariano Martinez Peck
> Email: marianopeck at gmail.com
> Twitter: @MartinezPeck
> LinkedIn: www.linkedin.com/in/mariano-martinez-peck
> <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
> Blog: https://marianopeck.wordpress.com/
>


-- 
Mariano Martinez Peck
Email: marianopeck at gmail.com
Twitter: @MartinezPeck
LinkedIn: www.linkedin.com/in/mariano-martinez-peck
<https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
Blog: https://marianopeck.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200710/ffc4a55e/attachment-0001.html>

From forums.jakob at resfarm.de  Fri Jul 10 19:08:52 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Fri, 10 Jul 2020 21:08:52 +0200
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <25a68fdc-f2e3-14f4-cf54-7db66013dca9@email.it>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <25a68fdc-f2e3-14f4-cf54-7db66013dca9@email.it>
Message-ID: <CA+ovNC55osnigsZR_0SDviFLDiLt-8qUhrS+yFXzxGkHv5BJ-Q@mail.gmail.com>

VA Smalltalk has log4s as a Smalltalk port of log4j. But I guess it is
proprietary because you buy it with VA Smalltalk.


Davide Grandi <davide.grandi at email.it> schrieb am Fr., 10. Juli 2020, 12:57:

> slicing a small slice of log4* ?
> *doc => all classes : not too many classes.
>
> "they" stole sUnit ... so we can slice log4*.
>
> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/index.html
>
> (sorry, just my 0,02€)
>
> Cheers,
>
>      Davide
>
> On 10/07/2020 02:13, tim Rowledge wrote:
> > I'm looking for some good message logging stuff - something a little
> more flexible that `Transcript show:` level - and so far the best I can see
> is a rather old package on squeaksource named 'Logging' originally by Keith
> Hodges but with quite a few updates by Mat Fulmer.
> >
> > I wonder if anyone is using it in a current image? It seems to rely on
> some process specific variable code that *looks* like has been incorporated
> into the trunk. I don't want to spend too much time peering at it is
> somebody else already knows whether it is unusable now or better yet still
> 'load and go'
> >
> > Or indeed, it somebody has a pointer to sometihng newer/better/shinier?
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Ubi dubium ibi libertas
>
> --
> Ing. Davide Grandi
> email    : davide.grandi at email.it
> mobile   : +39 339 7468 778
> linkedin : http://linkedin.com/in/davidegrandi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200710/b926ac1e/attachment.html>

From robert.withers at pm.me  Fri Jul 10 19:44:04 2020
From: robert.withers at pm.me (Robert Withers)
Date: Fri, 10 Jul 2020 19:44:04 +0000
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <CA+ovNC55osnigsZR_0SDviFLDiLt-8qUhrS+yFXzxGkHv5BJ-Q@mail.gmail.com>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <25a68fdc-f2e3-14f4-cf54-7db66013dca9@email.it>
 <CA+ovNC55osnigsZR_0SDviFLDiLt-8qUhrS+yFXzxGkHv5BJ-Q@mail.gmail.com>
Message-ID: <a6cb7df0-41f0-8da7-ce29-904e7cf1e087@pm.me>

Hello,

> I would take this opportunity to point out the TraceMonitor [1] package in Cryptography.

> Installer ss project: "Cryptography'; install: 'TraceMonitor'.

The use is very straightforward as shown in the test case.

> TraceMonitorTestCase>>#testTraceMonitor

>> | monitor |
>> monitor := TraceMonitor newNick: 'TestingMonitor'.
>> monitor monitor: self.
>> self etrace: #info msg: '1'.
>> self etrace: #warn msg: '1'.
>> self etrace: #debug msg: '1'.
>> self etrace: #error msg: '1'.

There is additional API, such as TraceMonitor>>#traceToTranscript. The default enabled domains are set in

> TraceMonitor>>#initializeDefaultMonitors

>> self enableDomain: #info.
>> self enableDomain: #warning.
>> self enableDomain: #error.
>> self enableDomain: #debug.

You can always add new domains, such as #over_the_wire or #engine or #obj_references or what ever you need for your project. Then you can throw an event for that new domain with:

>> self etrace: #over_the_wire msg: 'msg received'.self etrace: #engine msg: 'Engine state changed'.
>> self etrace: #obj_references msg: 'new object registered'.

Another aspect is that the monitoring of internal objects can be granted by an previously registered object. So let us say you are monitoring the engine and it wants to extend monitoring to the object tables. First, you would #monitor: the engine:

> | engine monitor |
> monitor := TraceMonitor newNick: 'TestingMonitor'. engine := SampleEngine new.
> monitor monitor: engine.
> engine init.

Then in SampleEngine>>#init we register the Object Tables, called the Scope.

> SampleEngine>>#init
> objectTables := Scope new.
> self monitor: objectTables.

>>

Thus, when inside a Scope method, calls #etrace:msg: the TraceMonitor will post it.

> self etrace: #obj_references msg: 'new object registered'.

I hope this helps you to understand its uses. I hope you find it useful!

>>

Kindly,
rabbit

[1] TraceMonitor - http://www.squeaksource.com/@fLap-whI8O1pUZtu/eNY6xSnW (this link may soon expire)

On 7/10/20 3:08 PM, Jakob Reschke wrote:

> VA Smalltalk has log4s as a Smalltalk port of log4j. But I guess it is proprietary because you buy it with VA Smalltalk.
>
> Davide Grandi <davide.grandi at email.it> schrieb am Fr., 10. Juli 2020, 12:57:
>
>> slicing a small slice of log4* ?
>> *doc => all classes : not too many classes.
>>
>> "they" stole sUnit ... so we can slice log4*.
>>
>> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/index.html
>>
>> (sorry, just my 0,02€)
>>
>> Cheers,
>>
>> Davide
>>
>> On 10/07/2020 02:13, tim Rowledge wrote:
>>> I'm looking for some good message logging stuff - something a little more flexible that `Transcript show:` level - and so far the best I can see is a rather old package on squeaksource named 'Logging' originally by Keith Hodges but with quite a few updates by Mat Fulmer.
>>>
>>> I wonder if anyone is using it in a current image? It seems to rely on some process specific variable code that *looks* like has been incorporated into the trunk. I don't want to spend too much time peering at it is somebody else already knows whether it is unusable now or better yet still 'load and go'
>>>
>>> Or indeed, it somebody has a pointer to sometihng newer/better/shinier?
>>>
>>> tim
>>> --
>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>> Ubi dubium ibi libertas
>>
>> --
>> Ing. Davide Grandi
>> email : davide.grandi at email.it
>> mobile : +39 339 7468 778
>> linkedin : http://linkedin.com/in/davidegrandi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200710/e00ec8fd/attachment.html>

From tim at rowledge.org  Fri Jul 10 20:11:23 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 10 Jul 2020 13:11:23 -0700
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <b63e9eb7-9e2b-2166-aca2-d0420c4407ec@ifi.uio.no>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <b63e9eb7-9e2b-2166-aca2-d0420c4407ec@ifi.uio.no>
Message-ID: <843BEF39-A2AD-4540-BE30-2075F3692E0B@rowledge.org>



> On 2020-07-10, at 2:40 AM, Trygve Reenskaug <trygver at ifi.uio.no> wrote:
> 
> I once did a VW program that logged the messages received by the instances of a class.

That's an interesting attack on a slightly different problem than mine; but I like the idea. If I needed to log the entire message flow I'd probably use a subclass of the simulator these days. A fast machine can simulate with bearable interactive performance, which is amazing.


> On 2020-07-10, at 12:44 PM, Robert Withers via Squeak-dev <squeak-dev at lists.squeakfoundation.org> wrote:
> 
> I would take this opportunity to point out the TraceMonitor [1] package in Cryptography.

That looks interesting, and since I am already loading the cryptography package it will be easy to just include. I'll see how it goes!

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Re vera, potas bene = Say, you sure are drinking a lot.



From pdebruic at gmail.com  Fri Jul 10 22:04:48 2020
From: pdebruic at gmail.com (Paul DeBruicker)
Date: Fri, 10 Jul 2020 17:04:48 -0500 (CDT)
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
Message-ID: <1594418688634-0.post@n4.nabble.com>

Toothpick should load and work in 5.3

http://wiki.squeak.org/squeak/5890


Pharo has this announcements based one:
https://github.com/pharo-project/pharo-beacon  

With a blog post here:
http://www.humane-assessment.com/blog/beacon




timrowledge wrote
> I'm looking for some good message logging stuff - something a little more
> flexible that `Transcript show:` level - and so far the best I can see is
> a rather old package on squeaksource named 'Logging' originally by Keith
> Hodges but with quite a few updates by Mat Fulmer.
> 
> I wonder if anyone is using it in a current image? It seems to rely on
> some process specific variable code that *looks* like has been
> incorporated into the trunk. I don't want to spend too much time peering
> at it is somebody else already knows whether it is unusable now or better
> yet still 'load and go'
> 
> Or indeed, it somebody has a pointer to sometihng newer/better/shinier?
> 
> tim
> --
> tim Rowledge; 

> tim@

> ; http://www.rowledge.org/tim
> Ubi dubium ibi libertas





--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

From cunningham.cb at gmail.com  Fri Jul 10 23:50:17 2020
From: cunningham.cb at gmail.com (Chris Cunningham)
Date: Fri, 10 Jul 2020 16:50:17 -0700
Subject: [squeak-dev] SequenceableCollection #= method in current trunk
 differs from Squeak 5.2
In-Reply-To: <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
References: <CACddb62baLRNnQDepLvhee43PF55nwEbbRkJ6WdpOPvdrY3dxA@mail.gmail.com>
 <alpine.DEB.2.02.2006290238410.25719@login03.caesar.elte.hu>
Message-ID: <CAPp9i4mroU_9YQASD7OoqC2oZGfsRC6hAk1j7jLT9S6kT844gA@mail.gmail.com>

On Sun, Jun 28, 2020 at 5:43 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:

> Hi Nikolai,
>
> On Mon, 29 Jun 2020, Nikolay Suslov wrote:
>
> > Hello all,
> > Figuring out, could we go back to the previous version of
> SequenceableCollection #= method (as in Squeak 5.2), to check if the
> receiver is equivalent to the otherCollection by using "self species ==
> otherCollection species",
> > instead of "self class = otherCollection class"?
>
> IIRC there was a good reason for that change though I can't recall
> what it was. I'm sure the mailing list remembers.
>

If you search for
    #= ==> #hash issues

in the mailing list, I think that thread has the (or a) reason for this
change (although the #= change was done by nice, not me).


> > The current version of #= method breaks code in different places. For
> example the RFB/VNC server gives wrong results starting from an
> authentication process, where RFBMessage is the ByteArray subclass and
> implements #species.
>
> If you're looking for a fix, try this:
> http://leves.web.elte.hu/squeak/RFB-ul.18.mcz
>
>
> Levente
>
> >
> > Best regards,
> > Nikolai
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200710/2cce93b7/attachment.html>

From eric.gade at gmail.com  Sat Jul 11 00:06:56 2020
From: eric.gade at gmail.com (Eric Gade)
Date: Fri, 10 Jul 2020 20:06:56 -0400
Subject: [squeak-dev] Squot and Github
Message-ID: <CA+CiqoWPgMHEUpjBqKhvT936NEMHfM7SWG=jRsW3QT0gS4GOBg@mail.gmail.com>

Hi all,

I have a project I've been working on using Squot and the new Git tools and
pushing to a repository I have on Github. The repository is private but
works with my username and password. I have been successfully pushing
commits to it for a couple of weeks from the same image. This includes
commits that I made yesterday. But today, suddenly, I am no longer able to
push to my remote. Instead, I get the error in the attached image.

Note that I have not changed any Github settings or anything like that. So
I'm not sure what has changed or what's going on. Any ideas?  Is anyone
else having this issue? If I wish to find a way to "back out" of using
Squot, is there some way to convert everything to Monticello (filetree) and
just push it manually from my terminal?

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200710/9ae94afd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-07-10 at 8.03.25 PM.png
Type: image/png
Size: 37248 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200710/9ae94afd/attachment.png>

From davide.grandi at email.it  Sat Jul 11 05:22:07 2020
From: davide.grandi at email.it (Davide Grandi)
Date: Sat, 11 Jul 2020 07:22:07 +0200
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <CA+ovNC55osnigsZR_0SDviFLDiLt-8qUhrS+yFXzxGkHv5BJ-Q@mail.gmail.com>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <25a68fdc-f2e3-14f4-cf54-7db66013dca9@email.it>
 <CA+ovNC55osnigsZR_0SDviFLDiLt-8qUhrS+yFXzxGkHv5BJ-Q@mail.gmail.com>
Message-ID: <fb7298fd-be1e-f4a5-a3c6-3d0e82c5fa22@email.it>

Thank-you,

I'm digging on ".instantiations.com", and there are cues on programmer's 
manual, slides & documentation.

Terms varying from "port" to "inspiration" to "log4s available as open 
source".


Bye & thank-you again,

     Davide

On 10/07/2020 21:08, Jakob Reschke wrote:
> VA Smalltalk has log4s as a Smalltalk port of log4j. But I guess it is 
> proprietary because you buy it with VA Smalltalk.
>
> Davide Grandi <davide.grandi at email.it <mailto:davide.grandi at email.it>> 
> schrieb am Fr., 10. Juli 2020, 12:57:
>
>     slicing a small slice of log4* ?
>     *doc => all classes : not too many classes.
>
>     "they" stole sUnit ... so we can slice log4*.
>
>     https://logging.apache.org/log4j/2.x/log4j-api/apidocs/index.html
>
>     (sorry, just my 0,02€)
>
>     Cheers,
>
>          Davide
>
>     On 10/07/2020 02:13, tim Rowledge wrote:
>     > I'm looking for some good message logging stuff - something a
>     little more flexible that `Transcript show:` level - and so far
>     the best I can see is a rather old package on squeaksource named
>     'Logging' originally by Keith Hodges but with quite a few updates
>     by Mat Fulmer.
>     >
>     > I wonder if anyone is using it in a current image? It seems to
>     rely on some process specific variable code that *looks* like has
>     been incorporated into the trunk. I don't want to spend too much
>     time peering at it is somebody else already knows whether it is
>     unusable now or better yet still 'load and go'
>     >
>     > Or indeed, it somebody has a pointer to sometihng
>     newer/better/shinier?
>     >
>     > tim
>     > --
>     > tim Rowledge; tim at rowledge.org <mailto:tim at rowledge.org>;
>     http://www.rowledge.org/tim
>     > Ubi dubium ibi libertas
>     -- 
>     Ing. Davide Grandi
>     email    : davide.grandi at email.it <mailto:davide.grandi at email.it>
>
-- 
Ing. Davide Grandi
email    : davide.grandi at email.it

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/4bec7cff/attachment-0001.html>

From davide.grandi at email.it  Sat Jul 11 05:42:58 2020
From: davide.grandi at email.it (Davide Grandi)
Date: Sat, 11 Jul 2020 07:42:58 +0200
Subject: [squeak-dev] log4s : free on Pharo (Re: squeak logging package(s))
In-Reply-To: <CA+ovNC55osnigsZR_0SDviFLDiLt-8qUhrS+yFXzxGkHv5BJ-Q@mail.gmail.com>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <25a68fdc-f2e3-14f4-cf54-7db66013dca9@email.it>
 <CA+ovNC55osnigsZR_0SDviFLDiLt-8qUhrS+yFXzxGkHv5BJ-Q@mail.gmail.com>
Message-ID: <e82575ec-7218-eb89-f978-283878c69dae@email.it>

It appears on a Pharo catalog :
     https://catalog.pharo.org/catalog/project/Log4s
with a page on ... Gemstone !
http://ss3.gemstone.com/ss/Log4s.html/Wiki

bye,

     Davide
(smalltalk strikes back ...)

On 10/07/2020 21:08, Jakob Reschke wrote:
> VA Smalltalk has log4s as a Smalltalk port of log4j. But I guess it is 
> proprietary because you buy it with VA Smalltalk.
>
>
> Davide Grandi <davide.grandi at email.it <mailto:davide.grandi at email.it>> 
> schrieb am Fr., 10. Juli 2020, 12:57:
>
>     slicing a small slice of log4* ?
>     *doc => all classes : not too many classes.
>
>     "they" stole sUnit ... so we can slice log4*.
>
>     https://logging.apache.org/log4j/2.x/log4j-api/apidocs/index.html
>
>     (sorry, just my 0,02€)
>
>     Cheers,
>
>          Davide
>
>     On 10/07/2020 02:13, tim Rowledge wrote:
>     > I'm looking for some good message logging stuff - something a
>     little more flexible that `Transcript show:` level - and so far
>     the best I can see is a rather old package on squeaksource named
>     'Logging' originally by Keith Hodges but with quite a few updates
>     by Mat Fulmer.
>     >
>     > I wonder if anyone is using it in a current image? It seems to
>     rely on some process specific variable code that *looks* like has
>     been incorporated into the trunk. I don't want to spend too much
>     time peering at it is somebody else already knows whether it is
>     unusable now or better yet still 'load and go'
>     >
>     > Or indeed, it somebody has a pointer to sometihng
>     newer/better/shinier?
>     >
>     > tim
>     > --
>     > tim Rowledge; tim at rowledge.org <mailto:tim at rowledge.org>;
>     http://www.rowledge.org/tim
>     > Ubi dubium ibi libertas
>
-- 
Ing. Davide Grandi
email    : davide.grandi at email.it

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/34d9cc1d/attachment.html>

From lists at fniephaus.com  Sat Jul 11 06:42:51 2020
From: lists at fniephaus.com (Fabio Niephaus)
Date: Sat, 11 Jul 2020 08:42:51 +0200
Subject: [squeak-dev] Squot and Github
In-Reply-To: <CA+CiqoWPgMHEUpjBqKhvT936NEMHfM7SWG=jRsW3QT0gS4GOBg@mail.gmail.com>
References: <CA+CiqoWPgMHEUpjBqKhvT936NEMHfM7SWG=jRsW3QT0gS4GOBg@mail.gmail.com>
Message-ID: <CADfnKi7A8pSJTJgrTRn7_DJn74OcNuMJ7b-4w77G_HkMFtZDMA@mail.gmail.com>

Hi Eric:

On Sat, Jul 11, 2020 at 2:07 AM Eric Gade <eric.gade at gmail.com> wrote:
>
> Hi all,
>
> I have a project I've been working on using Squot and the new Git tools and pushing to a repository I have on Github. The repository is private but works with my username and password. I have been successfully pushing commits to it for a couple of weeks from the same image. This includes commits that I made yesterday. But today, suddenly, I am no longer able to push to my remote. Instead, I get the error in the attached image.
>

Sorry to hear you're having issues pushing to remote from your image.
I have no idea what's going on, maybe renew your access token and try
again? What OS/VM/image are you using?

> Note that I have not changed any Github settings or anything like that. So I'm not sure what has changed or what's going on. Any ideas?  Is anyone else having this issue? If I wish to find a way to "back out" of using Squot, is there some way to convert everything to Monticello (filetree) and just push it manually from my terminal?
>

No need to back out of using Squot just yet: when you added your
project, the GitBrowser asked you for a local directory. Although
Squot does not touch the working copy on the filesystem (the files
that end up on GitHub), it does keep the repository metadata
(everything in .git) in sync. So that means you can just push from
your terminal from your filesystem repository. This use case is one of
many reasons why Squot asks for a local directory.

Hope this helps,
Fabio

> --
> Eric
>

From robert.withers at pm.me  Sat Jul 11 07:38:24 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sat, 11 Jul 2020 07:38:24 +0000
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <843BEF39-A2AD-4540-BE30-2075F3692E0B@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <b63e9eb7-9e2b-2166-aca2-d0420c4407ec@ifi.uio.no>
 <843BEF39-A2AD-4540-BE30-2075F3692E0B@rowledge.org>
Message-ID: <1d1ac2b7-7b26-cba1-be35-331ea843b879@pm.me>

Hi tim,

On 7/10/20 4:11 PM, tim Rowledge wrote:
> On 2020-07-10, at 12:44 PM, Robert Withers via Squeak-dev 
> <squeak-dev at lists.squeakfoundation.org> wrote:
>> I would take this opportunity to point out the TraceMonitor [1] package in Cryptography.
> That looks interesting, and since I am already loading the cryptography package it will be easy to just include. I'll see how it goes!

Super! I realized it wasn't where it should be, functionally. So I 
published a new version 'TraceMonitor-rww.2.mcz'. I am now initializing 
with a Transcript stream, but able to add multiple steams; Internally 
the monitor writes to a CompositeStream, able to hold multiple streams.

Here we have a Transcript stream, by default, and a file stream.

     | monitor |
     monitor := TraceMonitor newNick: 'TestingMonitor'.
     monitor openTraceStreamNamed: 'traceMonitor.log'.

Calling #etrace:msg: in an object who is being monitored by this 
monitor, will result in the event written to both the Transcript and the 
file named 'traceMonitor.log'.

Unfortunately, I am not making any assertions in the TestCase, which is 
more of an ExampleCase. If you will define your own domains, a test 
example of etraceing with that domain could be built and output 
verified, visually or assertively.

K, r



From forums.jakob at resfarm.de  Sat Jul 11 08:02:12 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Sat, 11 Jul 2020 10:02:12 +0200
Subject: [squeak-dev] Squot and Github
In-Reply-To: <CADfnKi7A8pSJTJgrTRn7_DJn74OcNuMJ7b-4w77G_HkMFtZDMA@mail.gmail.com>
References: <CA+CiqoWPgMHEUpjBqKhvT936NEMHfM7SWG=jRsW3QT0gS4GOBg@mail.gmail.com>
 <CADfnKi7A8pSJTJgrTRn7_DJn74OcNuMJ7b-4w77G_HkMFtZDMA@mail.gmail.com>
Message-ID: <CA+ovNC6gmffmkYozgS35c2KtFR95ctvXTxx9JQ_uYPgoViST0w@mail.gmail.com>

Hi Eric,

Sorry for the issue. Can you please press the Debug button in the
dialog and tell me some more about the `response` variable you should
see in the top context? For example what is the `response code` (401
or 403) or the `response content`? I would ask for the whole object,
but it also contains the request and that should contain your
credentials in the headers, which I don't want to see obviously. :-)
Could you please inspect whether the `response request` actually
contains authentication headers? I have seen in the past that
sometimes the WebClient does not send them when it should.

If you restart the context in the debugger (should be either
GitSmartHTTPProtocol>>#discoverReferencesForService: or
GitSmartHTTPProtocol>>#invokeReceivePackWithRefs:andPack:deleting:) to
repeat the request, does the same error occur again or does it work on
second try? If the WebClient shows further problems, you can also try
to restart the topmost SquitBrowser context that you find on the
stack.

About backing out: like Fabio said, the Git history is all on your
disk and you can still pull/push/... with the Git command line. To see
the files, you just have to checkout a commit (or reset --hard to see
the latest files on the branch). Then you will find everything in
filetree format (or Tonel if you configured it so). A converter exists
for Monticello->Squot (see
https://github.com/hpi-swa/Squot/#converting-monticello-history), but
not for the other way around, since Squot repositories are just
metadata-less filetree repositories. If someone really wants to build
a converter for the other direction, they could probably learn from
the existing converter and turn the read/write logic around. However,
I would rather like to find and fix your push issue.

Kind regards,
Jakob

Am Sa., 11. Juli 2020 um 08:43 Uhr schrieb Fabio Niephaus <lists at fniephaus.com>:
>
> Hi Eric:
>
> On Sat, Jul 11, 2020 at 2:07 AM Eric Gade <eric.gade at gmail.com> wrote:
> >
> > Hi all,
> >
> > I have a project I've been working on using Squot and the new Git tools and pushing to a repository I have on Github. The repository is private but works with my username and password. I have been successfully pushing commits to it for a couple of weeks from the same image. This includes commits that I made yesterday. But today, suddenly, I am no longer able to push to my remote. Instead, I get the error in the attached image.
> >
>
> Sorry to hear you're having issues pushing to remote from your image.
> I have no idea what's going on, maybe renew your access token and try
> again? What OS/VM/image are you using?
>
> > Note that I have not changed any Github settings or anything like that. So I'm not sure what has changed or what's going on. Any ideas?  Is anyone else having this issue? If I wish to find a way to "back out" of using Squot, is there some way to convert everything to Monticello (filetree) and just push it manually from my terminal?
> >
>
> No need to back out of using Squot just yet: when you added your
> project, the GitBrowser asked you for a local directory. Although
> Squot does not touch the working copy on the filesystem (the files
> that end up on GitHub), it does keep the repository metadata
> (everything in .git) in sync. So that means you can just push from
> your terminal from your filesystem repository. This use case is one of
> many reasons why Squot asks for a local directory.
>
> Hope this helps,
> Fabio
>
> > --
> > Eric
> >
>

From commits at source.squeak.org  Sat Jul 11 08:18:16 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Sat, 11 Jul 2020 08:18:16 0000
Subject: [squeak-dev] The Inbox: Graphics-kfr.434.mcz
Message-ID: <E1juAiD-0004Ip-0t@andreas>

A new version of Graphics was added to project The Inbox:
http://source.squeak.org/inbox/Graphics-kfr.434.mcz

==================== Summary ====================

Name: Graphics-kfr.434
Author: kfr
Time: 11 July 2020, 10:18:06.272175 am
UUID: 0e0125f6-3040-6247-9e5a-43bfd1896f84
Ancestors: Graphics-mt.433

I wanted to subclass Rectangle with a instance variable to carry some state, but these methodes indirected to Point>>corner: so it broke the override and returned a ordinary Rectangle instead of my fancy new subclass SuperRectangle

=============== Diff against Graphics-mt.433 ===============

Item was changed:
  ----- Method: Rectangle class>>encompassing: (in category 'instance creation') -----
  encompassing: listOfPoints
  	"A number of callers of encompass: should use this method."
  	| topLeft bottomRight |
  	topLeft := bottomRight := nil.
  	listOfPoints do:
  		[:p | topLeft == nil
  			ifTrue: [topLeft := bottomRight := p]
  			ifFalse: [topLeft := topLeft min: p.
  					bottomRight := bottomRight max: p]].
+ 	^self origin: topLeft corner: bottomRight!
- 	^ topLeft corner: bottomRight!

Item was changed:
  ----- Method: Rectangle class>>merging: (in category 'instance creation') -----
  merging: listOfRects 
  	"A number of callers of merge: should use this method."
  	| minX minY maxX maxY |
  	listOfRects
  		do: [:r | minX
  				ifNil: [minX := r topLeft x. minY := r topLeft y.
  					maxX := r bottomRight x. maxY := r bottomRight y]
  				ifNotNil: [minX := minX min: r topLeft x. minY := minY min: r topLeft y.
  					maxX := maxX max: r bottomRight x. maxY := maxY max: r bottomRight y]].
+ 	^ self origin:minX at minY corner: maxX at maxY!
- 	^ minX at minY corner: maxX at maxY!


From eric.gade at gmail.com  Sat Jul 11 11:53:13 2020
From: eric.gade at gmail.com (Eric Gade)
Date: Sat, 11 Jul 2020 07:53:13 -0400
Subject: [squeak-dev] Squot and Github
In-Reply-To: <CA+ovNC6gmffmkYozgS35c2KtFR95ctvXTxx9JQ_uYPgoViST0w@mail.gmail.com>
References: <CA+CiqoWPgMHEUpjBqKhvT936NEMHfM7SWG=jRsW3QT0gS4GOBg@mail.gmail.com>
 <CADfnKi7A8pSJTJgrTRn7_DJn74OcNuMJ7b-4w77G_HkMFtZDMA@mail.gmail.com>
 <CA+ovNC6gmffmkYozgS35c2KtFR95ctvXTxx9JQ_uYPgoViST0w@mail.gmail.com>
Message-ID: <CA+CiqoUZ0djXi9VWG5BFXG7oEFNCTjL3VK8fqnskyEnsbBE1bw@mail.gmail.com>

Hello Fabio and Jakob, thanks for responding.

Sorry to hear you're having issues pushing to remote from your image.
> I have no idea what's going on, maybe renew your access token and try
> again? What OS/VM/image are you using?
>

I'm running macOS 10.15.1. Here's my about info:
Squeak5.3
latest update: #19448
Current Change Set: HomeProject
Image format 68021 (64 bit)

Virtual Machine
---------------
/Applications/Squeak5.3-19431-64bit.app/Contents/MacOS/Squeak
Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives
VMMaker.oscog-nice.2715] 64 bit
Mac OS X built on Mar  3 2020 08:28:30 GMT Compiler: 4.2.1 Compatible Apple
LLVM 8.1.0 (clang-802.0.42)
platform sources revision VM: 202003021730
https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
https://github.com/OpenSmalltalk/opensmalltalk-vm.git
CoInterpreter VMMaker.oscog-nice.2715 uuid:
78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar  3 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
e40f3e94-3a54-411b-9613-5d19114ea131 Mar  3 2020

Sorry for the issue. Can you please press the Debug button in the
> dialog and tell me some more about the `response` variable you should
> see in the top context? For example what is the `response code` (401
> or 403) or the `response content`?


The response code is `401 Authorization Required`.

Could you please inspect whether the `response request` actually
> contains authentication headers? I have seen in the past that
> sometimes the WebClient does not send them when it should.
>

It looks to me like the WebClient's response request (the original request
sent I assume) headers *don't* have any Auth information: ` 'an
OrderedCollection(''Content-Type''->''application/x-git-receive-pack-request''
''Content-Length''->5343 ''User-Agent''->''git/2.0.5'' ''Host''->''
github.com'')'`

If you restart the context in the debugger (should be either
> GitSmartHTTPProtocol>>#discoverReferencesForService: or
> GitSmartHTTPProtocol>>#invokeReceivePackWithRefs:andPack:deleting:) to
> repeat the request, does the same error occur again or does it work on
> second try?
>

Ok, so this seems to have worked! Restarting
#invokeReceivePackWithRefs:andPack:deleting: and proceeding seems to have
done the trick! I have no idea why, of course. Any hints there? Either way,
thanks for the tip. I've checked github and my latest changes are pushed.


> when you added your
> project, the GitBrowser asked you for a local directory. Although
> Squot does not touch the working copy on the filesystem (the files
> that end up on GitHub), it does keep the repository metadata
> (everything in .git) in sync. So that means you can just push from
> your terminal from your filesystem repository.
>

I was hoping a local file copy was there (as it has been when I manually
pushed Monticello stuff in the past), but when I went snooping I didn't see
anything. Also one thing I've noticed that might be of interest here is
that when I first cloned my existing repo, and it asked for a folder to
clone into, it seems to have put the .git file directly in that folder.
This happens to be a folder that I keep all of my working images in, so
that's not a good place. But the reason I did it that way is because I
expected the normal git behavior: when you clone a repository on the
command line in git, it *creates a new directory with the repo name* and
puts the .git and other files inside of that directory. So when I selected
~/my_images/ or whatever as the clone directory with Squot, my git
experience led me to believe I would find something at
~/my_images/<repo-name>/.git but instead it's just at ~/my_images/.git

One last semi offtopic thing: is the Squeak community aware that Github
will be deprecating password based authentication come November?

Anyway the debugging/solutions you've all provided here seem to have done
the trick for now  -- thanks!



On Sat, Jul 11, 2020 at 4:02 AM Jakob Reschke <forums.jakob at resfarm.de>
wrote:

> Hi Eric,
>
> Sorry for the issue. Can you please press the Debug button in the
> dialog and tell me some more about the `response` variable you should
> see in the top context? For example what is the `response code` (401
> or 403) or the `response content`? I would ask for the whole object,
> but it also contains the request and that should contain your
> credentials in the headers, which I don't want to see obviously. :-)
> Could you please inspect whether the `response request` actually
> contains authentication headers? I have seen in the past that
> sometimes the WebClient does not send them when it should.
>
> If you restart the context in the debugger (should be either
> GitSmartHTTPProtocol>>#discoverReferencesForService: or
> GitSmartHTTPProtocol>>#invokeReceivePackWithRefs:andPack:deleting:) to
> repeat the request, does the same error occur again or does it work on
> second try? If the WebClient shows further problems, you can also try
> to restart the topmost SquitBrowser context that you find on the
> stack.
>
> About backing out: like Fabio said, the Git history is all on your
> disk and you can still pull/push/... with the Git command line. To see
> the files, you just have to checkout a commit (or reset --hard to see
> the latest files on the branch). Then you will find everything in
> filetree format (or Tonel if you configured it so). A converter exists
> for Monticello->Squot (see
> https://github.com/hpi-swa/Squot/#converting-monticello-history), but
> not for the other way around, since Squot repositories are just
> metadata-less filetree repositories. If someone really wants to build
> a converter for the other direction, they could probably learn from
> the existing converter and turn the read/write logic around. However,
> I would rather like to find and fix your push issue.
>
> Kind regards,
> Jakob
>
> Am Sa., 11. Juli 2020 um 08:43 Uhr schrieb Fabio Niephaus <
> lists at fniephaus.com>:
> >
> > Hi Eric:
> >
> > On Sat, Jul 11, 2020 at 2:07 AM Eric Gade <eric.gade at gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > I have a project I've been working on using Squot and the new Git
> tools and pushing to a repository I have on Github. The repository is
> private but works with my username and password. I have been successfully
> pushing commits to it for a couple of weeks from the same image. This
> includes commits that I made yesterday. But today, suddenly, I am no longer
> able to push to my remote. Instead, I get the error in the attached image.
> > >
> >
> > Sorry to hear you're having issues pushing to remote from your image.
> > I have no idea what's going on, maybe renew your access token and try
> > again? What OS/VM/image are you using?
> >
> > > Note that I have not changed any Github settings or anything like
> that. So I'm not sure what has changed or what's going on. Any ideas?  Is
> anyone else having this issue? If I wish to find a way to "back out" of
> using Squot, is there some way to convert everything to Monticello
> (filetree) and just push it manually from my terminal?
> > >
> >
> > No need to back out of using Squot just yet: when you added your
> > project, the GitBrowser asked you for a local directory. Although
> > Squot does not touch the working copy on the filesystem (the files
> > that end up on GitHub), it does keep the repository metadata
> > (everything in .git) in sync. So that means you can just push from
> > your terminal from your filesystem repository. This use case is one of
> > many reasons why Squot asks for a local directory.
> >
> > Hope this helps,
> > Fabio
> >
> > > --
> > > Eric
> > >
> >
>
>

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/ff96ac10/attachment.html>

From forums.jakob at resfarm.de  Sat Jul 11 12:13:24 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Sat, 11 Jul 2020 14:13:24 +0200
Subject: [squeak-dev] Squot and Github
In-Reply-To: <CA+CiqoUZ0djXi9VWG5BFXG7oEFNCTjL3VK8fqnskyEnsbBE1bw@mail.gmail.com>
References: <CA+CiqoWPgMHEUpjBqKhvT936NEMHfM7SWG=jRsW3QT0gS4GOBg@mail.gmail.com>
 <CADfnKi7A8pSJTJgrTRn7_DJn74OcNuMJ7b-4w77G_HkMFtZDMA@mail.gmail.com>
 <CA+ovNC6gmffmkYozgS35c2KtFR95ctvXTxx9JQ_uYPgoViST0w@mail.gmail.com>
 <CA+CiqoUZ0djXi9VWG5BFXG7oEFNCTjL3VK8fqnskyEnsbBE1bw@mail.gmail.com>
Message-ID: <CA+ovNC6sW--1WrANUPRoRUpekY-XSQQeByt-6CueocKJfXJQ5A@mail.gmail.com>

Hi Eric,

I'm glad that the workaround works.

I see your point about the clone behavior. git clone also takes an
optional directory argument [1] that specifies the target directory.
If this is given, git does not create a new directory for the working
copy. Since you have to choose a directory from Squeak anyway, I
thought the clone from Squeak is more similar to the git clone with a
directory specified, so it does not create another directory. How
would you clone into a directory that has a different name than the
repository? Anyway, would you like to open an issue for this on
GitHub? [2]

[1] https://git-scm.com/docs/git-clone#Documentation/git-clone.txt-ltdirectorygt
[2] https://github.com/hpi-swa/Squot/issues

Kind regards,
Jakob

Am Sa., 11. Juli 2020 um 13:53 Uhr schrieb Eric Gade <eric.gade at gmail.com>:
>
> Hello Fabio and Jakob, thanks for responding.
>
>> Sorry to hear you're having issues pushing to remote from your image.
>> I have no idea what's going on, maybe renew your access token and try
>> again? What OS/VM/image are you using?
>
>
> I'm running macOS 10.15.1. Here's my about info:
> Squeak5.3
> latest update: #19448
> Current Change Set: HomeProject
> Image format 68021 (64 bit)
>
> Virtual Machine
> ---------------
> /Applications/Squeak5.3-19431-64bit.app/Contents/MacOS/Squeak
> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715] 64 bit
> Mac OS X built on Mar  3 2020 08:28:30 GMT Compiler: 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)
> platform sources revision VM: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> CoInterpreter VMMaker.oscog-nice.2715 uuid: 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar  3 2020
> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar  3 2020
>
>> Sorry for the issue. Can you please press the Debug button in the
>> dialog and tell me some more about the `response` variable you should
>> see in the top context? For example what is the `response code` (401
>> or 403) or the `response content`?
>
>
> The response code is `401 Authorization Required`.
>
>> Could you please inspect whether the `response request` actually
>> contains authentication headers? I have seen in the past that
>> sometimes the WebClient does not send them when it should.
>
>
> It looks to me like the WebClient's response request (the original request sent I assume) headers *don't* have any Auth information: ` 'an OrderedCollection(''Content-Type''->''application/x-git-receive-pack-request'' ''Content-Length''->5343 ''User-Agent''->''git/2.0.5'' ''Host''->''github.com'')'`
>
>> If you restart the context in the debugger (should be either
>> GitSmartHTTPProtocol>>#discoverReferencesForService: or
>> GitSmartHTTPProtocol>>#invokeReceivePackWithRefs:andPack:deleting:) to
>> repeat the request, does the same error occur again or does it work on
>> second try?
>
>
> Ok, so this seems to have worked! Restarting #invokeReceivePackWithRefs:andPack:deleting: and proceeding seems to have done the trick! I have no idea why, of course. Any hints there? Either way, thanks for the tip. I've checked github and my latest changes are pushed.
>
>>
>> when you added your
>> project, the GitBrowser asked you for a local directory. Although
>> Squot does not touch the working copy on the filesystem (the files
>> that end up on GitHub), it does keep the repository metadata
>> (everything in .git) in sync. So that means you can just push from
>> your terminal from your filesystem repository.
>
>
> I was hoping a local file copy was there (as it has been when I manually pushed Monticello stuff in the past), but when I went snooping I didn't see anything. Also one thing I've noticed that might be of interest here is that when I first cloned my existing repo, and it asked for a folder to clone into, it seems to have put the .git file directly in that folder. This happens to be a folder that I keep all of my working images in, so that's not a good place. But the reason I did it that way is because I expected the normal git behavior: when you clone a repository on the command line in git, it *creates a new directory with the repo name* and puts the .git and other files inside of that directory. So when I selected ~/my_images/ or whatever as the clone directory with Squot, my git experience led me to believe I would find something at ~/my_images/<repo-name>/.git but instead it's just at ~/my_images/.git
>
> One last semi offtopic thing: is the Squeak community aware that Github will be deprecating password based authentication come November?
>
> Anyway the debugging/solutions you've all provided here seem to have done the trick for now  -- thanks!
>
>
>
> On Sat, Jul 11, 2020 at 4:02 AM Jakob Reschke <forums.jakob at resfarm.de> wrote:
>>
>> Hi Eric,
>>
>> Sorry for the issue. Can you please press the Debug button in the
>> dialog and tell me some more about the `response` variable you should
>> see in the top context? For example what is the `response code` (401
>> or 403) or the `response content`? I would ask for the whole object,
>> but it also contains the request and that should contain your
>> credentials in the headers, which I don't want to see obviously. :-)
>> Could you please inspect whether the `response request` actually
>> contains authentication headers? I have seen in the past that
>> sometimes the WebClient does not send them when it should.
>>
>> If you restart the context in the debugger (should be either
>> GitSmartHTTPProtocol>>#discoverReferencesForService: or
>> GitSmartHTTPProtocol>>#invokeReceivePackWithRefs:andPack:deleting:) to
>> repeat the request, does the same error occur again or does it work on
>> second try? If the WebClient shows further problems, you can also try
>> to restart the topmost SquitBrowser context that you find on the
>> stack.
>>
>> About backing out: like Fabio said, the Git history is all on your
>> disk and you can still pull/push/... with the Git command line. To see
>> the files, you just have to checkout a commit (or reset --hard to see
>> the latest files on the branch). Then you will find everything in
>> filetree format (or Tonel if you configured it so). A converter exists
>> for Monticello->Squot (see
>> https://github.com/hpi-swa/Squot/#converting-monticello-history), but
>> not for the other way around, since Squot repositories are just
>> metadata-less filetree repositories. If someone really wants to build
>> a converter for the other direction, they could probably learn from
>> the existing converter and turn the read/write logic around. However,
>> I would rather like to find and fix your push issue.
>>
>> Kind regards,
>> Jakob
>>
>> Am Sa., 11. Juli 2020 um 08:43 Uhr schrieb Fabio Niephaus <lists at fniephaus.com>:
>> >
>> > Hi Eric:
>> >
>> > On Sat, Jul 11, 2020 at 2:07 AM Eric Gade <eric.gade at gmail.com> wrote:
>> > >
>> > > Hi all,
>> > >
>> > > I have a project I've been working on using Squot and the new Git tools and pushing to a repository I have on Github. The repository is private but works with my username and password. I have been successfully pushing commits to it for a couple of weeks from the same image. This includes commits that I made yesterday. But today, suddenly, I am no longer able to push to my remote. Instead, I get the error in the attached image.
>> > >
>> >
>> > Sorry to hear you're having issues pushing to remote from your image.
>> > I have no idea what's going on, maybe renew your access token and try
>> > again? What OS/VM/image are you using?
>> >
>> > > Note that I have not changed any Github settings or anything like that. So I'm not sure what has changed or what's going on. Any ideas?  Is anyone else having this issue? If I wish to find a way to "back out" of using Squot, is there some way to convert everything to Monticello (filetree) and just push it manually from my terminal?
>> > >
>> >
>> > No need to back out of using Squot just yet: when you added your
>> > project, the GitBrowser asked you for a local directory. Although
>> > Squot does not touch the working copy on the filesystem (the files
>> > that end up on GitHub), it does keep the repository metadata
>> > (everything in .git) in sync. So that means you can just push from
>> > your terminal from your filesystem repository. This use case is one of
>> > many reasons why Squot asks for a local directory.
>> >
>> > Hope this helps,
>> > Fabio
>> >
>> > > --
>> > > Eric
>> > >
>> >
>>
>
>
> --
> Eric
>


From forums.jakob at resfarm.de  Sat Jul 11 12:25:05 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Sat, 11 Jul 2020 14:25:05 +0200
Subject: [squeak-dev] Missing auth headers in WebClient request (was: Squot
	and Github)
In-Reply-To: <CA+CiqoUZ0djXi9VWG5BFXG7oEFNCTjL3VK8fqnskyEnsbBE1bw@mail.gmail.com>
References: <CA+CiqoWPgMHEUpjBqKhvT936NEMHfM7SWG=jRsW3QT0gS4GOBg@mail.gmail.com>
 <CADfnKi7A8pSJTJgrTRn7_DJn74OcNuMJ7b-4w77G_HkMFtZDMA@mail.gmail.com>
 <CA+ovNC6gmffmkYozgS35c2KtFR95ctvXTxx9JQ_uYPgoViST0w@mail.gmail.com>
 <CA+CiqoUZ0djXi9VWG5BFXG7oEFNCTjL3VK8fqnskyEnsbBE1bw@mail.gmail.com>
Message-ID: <CA+ovNC5m=QJdiYotO9qhn-RXcGVveGzaUX_S73G1zUF0S_3w7g@mail.gmail.com>

Hi all,

Am Sa., 11. Juli 2020 um 13:53 Uhr schrieb Eric Gade <eric.gade at gmail.com>:
>
>> Could you please inspect whether the `response request` actually
>> contains authentication headers? I have seen in the past that
>> sometimes the WebClient does not send them when it should.
>
>
> It looks to me like the WebClient's response request (the original request sent I assume) headers *don't* have any Auth information: ` 'an OrderedCollection(''Content-Type''->''application/x-git-receive-pack-request'' ''Content-Length''->5343 ''User-Agent''->''git/2.0.5'' ''Host''->''github.com'')'`
>

To me these missing auth headers look like a WebClient bug because the
GitSmartHTTPProtocol class (comes with the Git Browser) clearly
supplies the credentials to the client (see
discoverReferencesForService:, requestCredentials, applyCredentials)
and uses the same WebClient instance for the whole push operation,
which entails two requests (discover references is the first, invoke
receive pack is the second).

If the misbehavior triggers, the second request is usually the one
that is missing the auth headers. I have already seen this
sporadically myself, but not lately. Repeating the request (by
restarting the method) usually resolves the problem.

Does anyone have a hint? It is possible that I have wrong expectations
about the WebClient interface and how it remembers the credentials...

Kind regards,
Jakob

From trygver at ifi.uio.no  Sat Jul 11 12:29:51 2020
From: trygver at ifi.uio.no (Trygve Reenskaug)
Date: Sat, 11 Jul 2020 14:29:51 +0200
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <843BEF39-A2AD-4540-BE30-2075F3692E0B@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <b63e9eb7-9e2b-2166-aca2-d0420c4407ec@ifi.uio.no>
 <843BEF39-A2AD-4540-BE30-2075F3692E0B@rowledge.org>
Message-ID: <98f228a6-193d-8354-6014-4f9756093674@ifi.uio.no>

Thank you for reminding me about the simulator. It sounds like a perfect 
foundation for dynamic reverse engineering, but it will take a lot of 
thought and work to make it into a usable tool.

On 2020-07-10 22:11, tim Rowledge wrote:
>
>> On 2020-07-10, at 2:40 AM, Trygve Reenskaug <trygver at ifi.uio.no> wrote:
>>
>> I once did a VW program that logged the messages received by the instances of a class.
> That's an interesting attack on a slightly different problem than mine; but I like the idea. If I needed to log the entire message flow I'd probably use a subclass of the simulator these days. A fast machine can simulate with bearable interactive performance, which is amazing.
>
>
>> On 2020-07-10, at 12:44 PM, Robert Withers via Squeak-dev <squeak-dev at lists.squeakfoundation.org> wrote:
>>
>> I would take this opportunity to point out the TraceMonitor [1] package in Cryptography.
> That looks interesting, and since I am already loading the cryptography package it will be easy to just include. I'll see how it goes!
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful Latin Phrases:- Re vera, potas bene = Say, you sure are drinking a lot.
>
>
>

-- 

/The essence of object orientation is that objects collaborateto achieve 
a goal. /
Trygve Reenskaug mailto: trygver at ifi.uio.no <mailto:%20trygver at ifi.uio.no>
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway                     Tel: (+47) 468 58 625

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/ea60ba74/attachment.html>

From leves at caesar.elte.hu  Sat Jul 11 13:32:12 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Sat, 11 Jul 2020 15:32:12 +0200 (CEST)
Subject: [squeak-dev] Missing auth headers in WebClient request (was:
 Squot	and Github)
In-Reply-To: <CA+ovNC5m=QJdiYotO9qhn-RXcGVveGzaUX_S73G1zUF0S_3w7g@mail.gmail.com>
References: <CA+CiqoWPgMHEUpjBqKhvT936NEMHfM7SWG=jRsW3QT0gS4GOBg@mail.gmail.com>
 <CADfnKi7A8pSJTJgrTRn7_DJn74OcNuMJ7b-4w77G_HkMFtZDMA@mail.gmail.com>
 <CA+ovNC6gmffmkYozgS35c2KtFR95ctvXTxx9JQ_uYPgoViST0w@mail.gmail.com>
 <CA+CiqoUZ0djXi9VWG5BFXG7oEFNCTjL3VK8fqnskyEnsbBE1bw@mail.gmail.com>
 <CA+ovNC5m=QJdiYotO9qhn-RXcGVveGzaUX_S73G1zUF0S_3w7g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.2007111528570.10597@login03.caesar.elte.hu>

On Sat, 11 Jul 2020, Jakob Reschke wrote:

> Hi all,
>
> Am Sa., 11. Juli 2020 um 13:53 Uhr schrieb Eric Gade <eric.gade at gmail.com>:
>>
>>> Could you please inspect whether the `response request` actually
>>> contains authentication headers? I have seen in the past that
>>> sometimes the WebClient does not send them when it should.
>>
>>
>> It looks to me like the WebClient's response request (the original request sent I assume) headers *don't* have any Auth information: ` 'an OrderedCollection(''Content-Type''->''application/x-git-receive-pack-request'' ''Content-Length''->5343 ''User-Agent''->''git/2.0.5'' ''Host''->''github.com'')'`
>>
>
> To me these missing auth headers look like a WebClient bug because the
> GitSmartHTTPProtocol class (comes with the Git Browser) clearly
> supplies the credentials to the client (see
> discoverReferencesForService:, requestCredentials, applyCredentials)
> and uses the same WebClient instance for the whole push operation,
> which entails two requests (discover references is the first, invoke
> receive pack is the second).
>
> If the misbehavior triggers, the second request is usually the one
> that is missing the auth headers. I have already seen this
> sporadically myself, but not lately. Repeating the request (by
> restarting the method) usually resolves the problem.
>
> Does anyone have a hint? It is possible that I have wrong expectations
> about the WebClient interface and how it remembers the credentials...

Perhaps this part of WebClient >> #sendRequest:contentBlock: is 
responsible:

 	"Flush previous authState.
 	XXXX: Fixme. authState must be preserved for pre-authentication of requests."
 	self flushAuthState.

#flushAuthState removes the passed credentials.

Also, any kind of redirect will remove the credentials.


Levente

>
> Kind regards,
> Jakob

From leves at caesar.elte.hu  Sat Jul 11 13:46:50 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Sat, 11 Jul 2020 15:46:50 +0200 (CEST)
Subject: [squeak-dev] The Inbox: Graphics-kfr.434.mcz
In-Reply-To: <E1juAiD-0004Ip-0t@andreas>
References: <E1juAiD-0004Ip-0t@andreas>
Message-ID: <alpine.DEB.2.02.2007111533080.10597@login03.caesar.elte.hu>

Hi Karl,

While both changes look right, they modify the behavior of those methods 
when their argument is an empty list.
Instead of raising an error, they'll return a Rectangle with both fields 
set to nil.
If the argument is really a list - aka SequenceableCollection, I suggest 
using more specific methods instead of #do: to process the list in order 
to trigger the error as soon as possible.
For example, use #first to get the first element and #allButFirstDo: to 
iterate over the rest. That would simplify the method as well by making 
the nil checks unnecessary.


Levente

On Sat, 11 Jul 2020, commits at source.squeak.org wrote:

> A new version of Graphics was added to project The Inbox:
> http://source.squeak.org/inbox/Graphics-kfr.434.mcz
>
> ==================== Summary ====================
>
> Name: Graphics-kfr.434
> Author: kfr
> Time: 11 July 2020, 10:18:06.272175 am
> UUID: 0e0125f6-3040-6247-9e5a-43bfd1896f84
> Ancestors: Graphics-mt.433
>
> I wanted to subclass Rectangle with a instance variable to carry some state, but these methodes indirected to Point>>corner: so it broke the override and returned a ordinary Rectangle instead of my fancy new subclass SuperRectangle
>
> =============== Diff against Graphics-mt.433 ===============
>
> Item was changed:
>  ----- Method: Rectangle class>>encompassing: (in category 'instance creation') -----
>  encompassing: listOfPoints
>  	"A number of callers of encompass: should use this method."
>  	| topLeft bottomRight |
>  	topLeft := bottomRight := nil.
>  	listOfPoints do:
>  		[:p | topLeft == nil
>  			ifTrue: [topLeft := bottomRight := p]
>  			ifFalse: [topLeft := topLeft min: p.
>  					bottomRight := bottomRight max: p]].
> + 	^self origin: topLeft corner: bottomRight!
> - 	^ topLeft corner: bottomRight!
>
> Item was changed:
>  ----- Method: Rectangle class>>merging: (in category 'instance creation') -----
>  merging: listOfRects
>  	"A number of callers of merge: should use this method."
>  	| minX minY maxX maxY |
>  	listOfRects
>  		do: [:r | minX
>  				ifNil: [minX := r topLeft x. minY := r topLeft y.
>  					maxX := r bottomRight x. maxY := r bottomRight y]
>  				ifNotNil: [minX := minX min: r topLeft x. minY := minY min: r topLeft y.
>  					maxX := maxX max: r bottomRight x. maxY := maxY max: r bottomRight y]].
> + 	^ self origin:minX at minY corner: maxX at maxY!
> - 	^ minX at minY corner: maxX at maxY!

From builds at travis-ci.org  Sat Jul 11 14:27:38 2020
From: builds at travis-ci.org (Travis CI)
Date: Sat, 11 Jul 2020 14:27:38 +0000
Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1755
	(squeak-trunk - 25ebaf1)
In-Reply-To: <squeak-smalltalk/squeak-app+707164943+errored@travis-ci.org>
Message-ID: <5f09cc55d52ab_13fbeda4b3114177642@travis-tasks-6bd9b7b459-kf77b.mail>

Build Update for squeak-smalltalk/squeak-app
-------------------------------------

Build: #1755
Status: Errored

Duration: 17 mins and 45 secs
Commit: 25ebaf1 (squeak-trunk)
Author: Marcel Taeumel
Message: Hi all!

The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for.

All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions.

Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs.

-- The Squeak Oversight Board

[ci skip]

View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7

View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/707164943?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/1e48b2b5/attachment.html>

From commits at source.squeak.org  Sat Jul 11 14:59:21 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Sat, 11 Jul 2020 14:59:21 0000
Subject: [squeak-dev] The Inbox: Graphics-kfr.435.mcz
Message-ID: <E1juGyM-0001PO-V9@andreas>

A new version of Graphics was added to project The Inbox:
http://source.squeak.org/inbox/Graphics-kfr.435.mcz

==================== Summary ====================

Name: Graphics-kfr.435
Author: kfr
Time: 11 July 2020, 4:59:11.970242 pm
UUID: 2ded852c-61bf-9c45-be09-6acb12a6b592
Ancestors: Graphics-kfr.434

I wanted to subclass Rectangle with a instance variable to carry some state, but these methodes indirected to Point>>corner: so it broke the override and returned a ordinary Rectangle instead of my fancy new subclass SuperRectangle

Updated to  use #first to get the first element and #allButFirstDo: to iterate over the rest.
(Suggested by Levente Uzonyi)

=============== Diff against Graphics-kfr.434 ===============

Item was changed:
  ----- Method: Rectangle class>>encompassing: (in category 'instance creation') -----
  encompassing: listOfPoints
  	"A number of callers of encompass: should use this method."
  	| topLeft bottomRight |
+ 	topLeft := bottomRight := listOfPoints first.
+ 	listOfPoints allButFirstDo:
+ 		[:p |topLeft := topLeft min: p.
+ 					bottomRight := bottomRight max: p].
- 	topLeft := bottomRight := nil.
- 	listOfPoints do:
- 		[:p | topLeft == nil
- 			ifTrue: [topLeft := bottomRight := p]
- 			ifFalse: [topLeft := topLeft min: p.
- 					bottomRight := bottomRight max: p]].
  	^self origin: topLeft corner: bottomRight!

Item was changed:
  ----- Method: Rectangle class>>merging: (in category 'instance creation') -----
  merging: listOfRects 
  	"A number of callers of merge: should use this method."
+ 	| bottomRight topLeft |
+ 	topLeft := listOfRects first topLeft.
+ 	bottomRight := listOfRects first bottomRight.
- 	| minX minY maxX maxY |
  	listOfRects
+ 		allButFirstDo: [:r | topLeft := topLeft min: r topLeft.
+ 			bottomRight := bottomRight max: r bottomRight].
+ 	^self origin: topLeft corner: bottomRight.
+ 	!
- 		do: [:r | minX
- 				ifNil: [minX := r topLeft x. minY := r topLeft y.
- 					maxX := r bottomRight x. maxY := r bottomRight y]
- 				ifNotNil: [minX := minX min: r topLeft x. minY := minY min: r topLeft y.
- 					maxX := maxX max: r bottomRight x. maxY := maxY max: r bottomRight y]].
- 	^ self origin:minX at minY corner: maxX at maxY!


From karlramberg at gmail.com  Sat Jul 11 15:03:19 2020
From: karlramberg at gmail.com (karl ramberg)
Date: Sat, 11 Jul 2020 17:03:19 +0200
Subject: [squeak-dev] The Inbox: Graphics-kfr.434.mcz
In-Reply-To: <alpine.DEB.2.02.2007111533080.10597@login03.caesar.elte.hu>
References: <E1juAiD-0004Ip-0t@andreas>
 <alpine.DEB.2.02.2007111533080.10597@login03.caesar.elte.hu>
Message-ID: <CAGzzWLixkf=ktsnPYaqXm_fo4QJN8z-gn=gX_9YohkuhboKv=w@mail.gmail.com>

Thanks for the suggestion. I uploaded a new version based on it.

Best,
Karl


On Sat, Jul 11, 2020 at 3:49 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:

> Hi Karl,
>
> While both changes look right, they modify the behavior of those methods
> when their argument is an empty list.
> Instead of raising an error, they'll return a Rectangle with both fields
> set to nil.
> If the argument is really a list - aka SequenceableCollection, I suggest
> using more specific methods instead of #do: to process the list in order
> to trigger the error as soon as possible.
> For example, use #first to get the first element and #allButFirstDo: to
> iterate over the rest. That would simplify the method as well by making
> the nil checks unnecessary.
>
>
> Levente
>
> On Sat, 11 Jul 2020, commits at source.squeak.org wrote:
>
> > A new version of Graphics was added to project The Inbox:
> > http://source.squeak.org/inbox/Graphics-kfr.434.mcz
> >
> > ==================== Summary ====================
> >
> > Name: Graphics-kfr.434
> > Author: kfr
> > Time: 11 July 2020, 10:18:06.272175 am
> > UUID: 0e0125f6-3040-6247-9e5a-43bfd1896f84
> > Ancestors: Graphics-mt.433
> >
> > I wanted to subclass Rectangle with a instance variable to carry some
> state, but these methodes indirected to Point>>corner: so it broke the
> override and returned a ordinary Rectangle instead of my fancy new subclass
> SuperRectangle
> >
> > =============== Diff against Graphics-mt.433 ===============
> >
> > Item was changed:
> >  ----- Method: Rectangle class>>encompassing: (in category 'instance
> creation') -----
> >  encompassing: listOfPoints
> >       "A number of callers of encompass: should use this method."
> >       | topLeft bottomRight |
> >       topLeft := bottomRight := nil.
> >       listOfPoints do:
> >               [:p | topLeft == nil
> >                       ifTrue: [topLeft := bottomRight := p]
> >                       ifFalse: [topLeft := topLeft min: p.
> >                                       bottomRight := bottomRight max:
> p]].
> > +     ^self origin: topLeft corner: bottomRight!
> > -     ^ topLeft corner: bottomRight!
> >
> > Item was changed:
> >  ----- Method: Rectangle class>>merging: (in category 'instance
> creation') -----
> >  merging: listOfRects
> >       "A number of callers of merge: should use this method."
> >       | minX minY maxX maxY |
> >       listOfRects
> >               do: [:r | minX
> >                               ifNil: [minX := r topLeft x. minY := r
> topLeft y.
> >                                       maxX := r bottomRight x. maxY := r
> bottomRight y]
> >                               ifNotNil: [minX := minX min: r topLeft x.
> minY := minY min: r topLeft y.
> >                                       maxX := maxX max: r bottomRight x.
> maxY := maxY max: r bottomRight y]].
> > +     ^ self origin:minX at minY corner: maxX at maxY!
> > -     ^ minX at minY corner: maxX at maxY!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/a2d02ac8/attachment.html>

From stephen at heaveneverywhere.com  Sat Jul 11 18:02:37 2020
From: stephen at heaveneverywhere.com (Stephen Pope)
Date: Sat, 11 Jul 2020 11:02:37 -0700
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <5593C678-5CD0-43D7-A72A-84B4C3D92A7B@heaveneverywhere.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <5593C678-5CD0-43D7-A72A-84B4C3D92A7B@heaveneverywhere.com>
Message-ID: <97F2A1A6-06AF-4DB2-A79D-816DCFFAAFF9@heaveneverywhere.com>


To put it bluntly: I gave porting old-school MVC to Cuis.

[flame on] Morphic is miserable and really needs to be replaced by MVC, though (IMHO).

Why?

1. There’s a reason views and controllers were initially separated; that reason is reusability and better factoring.

2. The composite design pattern is a good thing (https://en.wikipedia.org/wiki/Composite_pattern <https://en.wikipedia.org/wiki/Composite_pattern>) and should be applied to everything where one builds trees, such as view hierarchies. The root view object should not have subviews, the view-composite should. (I know that old-school MVC didn’t do it that way, but new implementations certainly should).

3. In a good OO framework, the more abstract classes generally have the minimum necessary state (or none at all). Class Morph has 7 instance variables.

4. The goal of OO design is to reuse specifications across multiple implementations, so why does class Morph rename the usual geometry methods of bounds, extent, width, height, etc. as (e.g.,) morphBounds?

I could go on… [flame off] 

It would be really nice to have a simple MVC (and display-list graphics) framework that could be placed on top of several graphics back-ends including BitBLT, OpenGL and HTML5.

stp


--

                    Stephen Travis Pope   Santa Barbara, California, USA    
          http://HeavenEverywhere.com <http://heaveneverywhere.com/>        http://FASTLabInc.com <http://fastlabinc.com/>
                       https://vimeo.com/user19434036/videos <https://vimeo.com/user19434036/videos>      http://heaveneverywhere.com/Reflections

--



> On Jul 9, 2020, at 11:12 PM, stephen at heaveneverywhere.com wrote:
> 
> 
> …on a related topic, I’ve started porting old-school MVC* to Cuis with the intention of replacing Morphic with a generic framework that can be back-ended by BitBLT, OpenGL or HTML5.
> 
> Anybody want to help?
> 
> Stephen
> 
> * = starting with traditional MVC classes and system windows, and following that with some version of the “Wrapper” framework as still used in VisualWorks.
> 
> 
> --
> 
>                     Stephen Travis Pope   Santa Barbara, California, USA    
>  <pastedGraphic.tiff>         http://HeavenEverywhere.com <http://heaveneverywhere.com/>        http://FASTLabInc.com <http://fastlabinc.com/>
>                        https://vimeo.com/user19434036/videos <https://vimeo.com/user19434036/videos>      http://heaveneverywhere.com/Reflections <http://heaveneverywhere.com/Reflections>
> 
> --
> 
> 
> 
>> On Jun 28, 2020, at 5:53 PM, tim Rowledge <tim at rowledge.org <mailto:tim at rowledge.org>> wrote:
>> 
>> Seriously. We've been sitting around twiddling thumbs about better graphics for decades now. 
>> 
>> We had Balloon2D & 3D.
>> We had 'Pooh graphics' to do vector forms.
>> We have some excellent stuff being done by the Cuis crew.
>> We have some amazing ideas from Nile/Gezira.
>> We have a number of potential 3rd party graphics libraries we might adopt.
>> We have an advanced JIT that could be used to make on-demand graphics routines either on their own or working with pretty much any of the above.
>> We probably have other options I've not even heard of.
>> 
>> Maybe we should actually do something? Can we at least talk about it?
>> 
>> tim
>> --
>> tim Rowledge; tim at rowledge.org <mailto:tim at rowledge.org>; http://www.rowledge.org/tim <http://www.rowledge.org/tim>
>> Strange OpCodes: SVE: Skip on Vernal Equinox
>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/fa017e1b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 2442 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/fa017e1b/attachment-0001.tiff>

From lecteur at zogotounga.net  Sat Jul 11 18:41:42 2020
From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=)
Date: Sat, 11 Jul 2020 20:41:42 +0200
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <97F2A1A6-06AF-4DB2-A79D-816DCFFAAFF9@heaveneverywhere.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <5593C678-5CD0-43D7-A72A-84B4C3D92A7B@heaveneverywhere.com>
 <97F2A1A6-06AF-4DB2-A79D-816DCFFAAFF9@heaveneverywhere.com>
Message-ID: <a9edab12-382d-e544-ecab-62c58fd5bfc6@zogotounga.net>

> To put it bluntly: I gave porting old-school MVC to Cuis.
> 
> [flame on] Morphic is miserable and really needs to be replaced by MVC, 
> though (IMHO).

There is no need to replace it: we already have MVC projects alongside 
morphic projects, so you can choose the framework you want. In fact the 
top project in Squeak 5.3 is a MVC one.

> It would be really nice to have a simple MVC (and display-list graphics) 
> framework that could be placed on top of several graphics back-ends 
> including BitBLT, OpenGL and HTML5.

I guess now the question is: what features are missing in MVC that you 
need?

Stef

From Christoph.Thiede at student.hpi.uni-potsdam.de  Sat Jul 11 18:44:42 2020
From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph)
Date: Sat, 11 Jul 2020 18:44:42 +0000
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <97F2A1A6-06AF-4DB2-A79D-816DCFFAAFF9@heaveneverywhere.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <5593C678-5CD0-43D7-A72A-84B4C3D92A7B@heaveneverywhere.com>,
 <97F2A1A6-06AF-4DB2-A79D-816DCFFAAFF9@heaveneverywhere.com>
Message-ID: <4c467091caac43059d676a0adf952f2b@student.hpi.uni-potsdam.de>

Hi Stephen,


> 1. There’s a reason views and controllers were initially separated; that reason is reusability and better factoring.

Afaik a good equivalent for that separation in Morphic are morph + model. If you are going to develop a sophisticated UI, you can use the ToolBuilder framework, and your tool will be even decoupled from the UI framework.

> 2. The composite design pattern is a good thing (https://en.wikipedia.org/wiki/Composite_pattern) and should be applied to everything where one builds trees, such as view hierarchies.

Morphic uses the composite pattern, too, doesn't it? All morphs are nested in each other, beginning at the root morph (the world), and form a big object tree, just like MVC does. Please correct me if I am wrong.

> 3. In a good OO framework, the more abstract classes generally have the minimum necessary state (or none at all). Class Morph has 7 instance variables.

And class View has 13 instance variables. :-) I agree with you that abstract class should not have any unnecessary state, but in fact, graphics aren't a completely abstract domain. A minimum of geometry information (bounds) is vital for graphic representation, and some node links (submorphs, owner) are vital, too, for navigating through the Morphic tree. Note that Morph even has a cleaned-up state by extracting all non-crucial fields into the extension object.

> 4. The goal of OO design is to reuse specifications across multiple implementations, so why does class Morph rename the usual geometry methods of bounds, extent, width, height, etc. as (e.g.,) morphBounds?

I'm afraid I don't get your point here. My image does not even know the selector #morphBounds. But #extent, #width, and #height, for example, are derived attributes, which means that an implementor only needs to manipulate the single underlying representation, which is bounds, in order to adjust all specified attributes.
Are you desiring something like an abstract morph interface that does not yet define core and derived attributes? It's true that Morph is not an abstract class (Morph new openInWorld works like a charm), but in which practical example would you need this?

> It would be really nice to have a simple MVC (and display-list graphics) framework that could be placed on top of several graphics back-ends including BitBLT, OpenGL and HTML5.

That's an interesting thought! As said above, Morphic is a composite framework, too, so couldn't you start by implementing #printHtmlOn: on Morph, next to #drawOn:? But in practice, I guess your desire would be very hard to achieve because HTML5 is a high-level OO framework while OpenGL operates on a quite low level. HTML5 is kind of a competing object tree against Morphic, so you could either try to keep two trees in sync or rebuild one of the trees periodically, which would be performance-extensive. For OpenGL, couldn't something like an OpenGLCanvas be a starting point?

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Stephen Pope <stephen at heaveneverywhere.com>
Gesendet: Samstag, 11. Juli 2020 20:02:37
An: The general-purpose Squeak developers list; Discussion of Cuis Smalltalk
Betreff: Re: [squeak-dev] We need to talk about graphics


To put it bluntly: I gave porting old-school MVC to Cuis.

[flame on] Morphic is miserable and really needs to be replaced by MVC, though (IMHO).

Why?

1. There’s a reason views and controllers were initially separated; that reason is reusability and better factoring.

2. The composite design pattern is a good thing (https://en.wikipedia.org/wiki/Composite_pattern) and should be applied to everything where one builds trees, such as view hierarchies. The root view object should not have subviews, the view-composite should. (I know that old-school MVC didn’t do it that way, but new implementations certainly should).

3. In a good OO framework, the more abstract classes generally have the minimum necessary state (or none at all). Class Morph has 7 instance variables.

4. The goal of OO design is to reuse specifications across multiple implementations, so why does class Morph rename the usual geometry methods of bounds, extent, width, height, etc. as (e.g.,) morphBounds?

I could go on… [flame off]

It would be really nice to have a simple MVC (and display-list graphics) framework that could be placed on top of several graphics back-ends including BitBLT, OpenGL and HTML5.

stp


--

                    Stephen Travis Pope   Santa Barbara, California, USA
          http://HeavenEverywhere.com        http://FASTLabInc.com
                       https://vimeo.com/user19434036/videos      http://heaveneverywhere.com/Reflections

--



On Jul 9, 2020, at 11:12 PM, stephen at heaveneverywhere.com<mailto:stephen at heaveneverywhere.com> wrote:


…on a related topic, I’ve started porting old-school MVC* to Cuis with the intention of replacing Morphic with a generic framework that can be back-ended by BitBLT, OpenGL or HTML5.

Anybody want to help?

Stephen

* = starting with traditional MVC classes and system windows, and following that with some version of the “Wrapper” framework as still used in VisualWorks.


--

                    Stephen Travis Pope   Santa Barbara, California, USA
 <pastedGraphic.tiff>         http://HeavenEverywhere.com<http://heaveneverywhere.com/>        http://FASTLabInc.com<http://fastlabinc.com/>
                       https://vimeo.com/user19434036/videos      http://heaveneverywhere.com/Reflections

--



On Jun 28, 2020, at 5:53 PM, tim Rowledge <tim at rowledge.org<mailto:tim at rowledge.org>> wrote:

Seriously. We've been sitting around twiddling thumbs about better graphics for decades now.

We had Balloon2D & 3D.
We had 'Pooh graphics' to do vector forms.
We have some excellent stuff being done by the Cuis crew.
We have some amazing ideas from Nile/Gezira.
We have a number of potential 3rd party graphics libraries we might adopt.
We have an advanced JIT that could be used to make on-demand graphics routines either on their own or working with pretty much any of the above.
We probably have other options I've not even heard of.

Maybe we should actually do something? Can we at least talk about it?

tim
--
tim Rowledge; tim at rowledge.org<mailto:tim at rowledge.org>; http://www.rowledge.org/tim
Strange OpCodes: SVE: Skip on Vernal Equinox





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/85234304/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 2442 bytes
Desc: pastedGraphic.tiff
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/85234304/attachment.tiff>

From tim at rowledge.org  Sat Jul 11 21:05:24 2020
From: tim at rowledge.org (tim Rowledge)
Date: Sat, 11 Jul 2020 14:05:24 -0700
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <re97u9$kkk$1@ciao.gmane.io>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <re97u9$kkk$1@ciao.gmane.io>
Message-ID: <C25255B1-763E-4635-BB09-7BE43C941E6D@rowledge.org>



> On 2020-07-10, at 1:12 AM, Craig Latta <craig at blackpagedigital.com> wrote:
> 
> 
> Hi Tim--
> 
>> Seriously. We've been sitting around twiddling thumbs about better
>> graphics for decades now.
> 
>     I'd like to see a concise description of the problem. You used the
> word "better", so I take it you find the current graphics deficient. How?

Well, at least in part the issue is that we collectively have been waffling on about 'making better graphics' for about as long as my email record has existed. So it's not solely about what I want, more as case of 'can we try to get something complete?'.

For myself, I'd like to see better rendered text and non-orthogonal lines. Circles, for example. My example here is the little collection of gauges I have for my weather station display. The round gauges as originally done looked terrible. Bob A offered a better circle drawing algorithm and with some over sampling it is a lot better  - but still ugly. 

Our typical fonts are ok but could be a lot better. Not to mention the slightly higher level issue of the font/style & tools. We made a few improvements in that area with the Sophie project, way back.

Not many things *I* want to do are very performance limited, so that isn't something that exercises *me* but I'm sure others have very different perspectives.

I have played a little with a Frank image to see if the Nile/Gezira system as-is does much better. For a circle, for example, it does do somewhat better *if* the stroke alpha is set to ~0.5. I'm way to out of the world of computer graphics to say more than that. 

I suspect that somewhat decoupling the graphics from explicit pixel considerations might help with handling super-resolution screens nicely. Vector graphics improvements to draw our tools would probably be nice.

As I said, it's not so much about what I want as a plea to see if we can actually get *something* done. Lots of us have ideas about what 'something' is. Let's hear some of them.

> 
>     I'm interested in the topic, and have some time. At the moment, all
> my graphics energy goes into leveraging in SqueakJS what others have
> done for web browsers, which is quite a lot.

Yeah, and your demos are amazing.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- The wheel's spinning but the hamster's dead.



From tim at rowledge.org  Sun Jul 12 02:29:16 2020
From: tim at rowledge.org (tim Rowledge)
Date: Sat, 11 Jul 2020 19:29:16 -0700
Subject: [squeak-dev] WatchMorph as an example of anti-aliasing going a bit
 odd (was Re: We need to talk about graphics)
In-Reply-To: <C25255B1-763E-4635-BB09-7BE43C941E6D@rowledge.org>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <re97u9$kkk$1@ciao.gmane.io>
 <C25255B1-763E-4635-BB09-7BE43C941E6D@rowledge.org>
Message-ID: <6A0144EE-EFD9-4D02-BD95-5FE7ECE6E914@rowledge.org>

Playing with stuff; tried a WatchMorph to look at circles drawn by Balloon.
Grabbing one via World->new morph->from alphabetical list produces a decently round clockface with a coloured centre section. However, using the debug menu to turn on the anti-aliasing results in a rather ugly lumpiness, as if it were a fruit that has been poked a bit too often to test for ripeness.
Weird. The B2Dplugin appears to be active and I can make it do profiling etc that makes it pretty certain it is being used.
Is this an ARM/Pi issue... nope, looks the same on a Mac system.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Gotta run, the cat's caught in the printer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/1abb2628/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-07-11 at 7.21.09 PM.png
Type: image/png
Size: 7356 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/1abb2628/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-07-11 at 7.21.20 PM.png
Type: image/png
Size: 10848 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/1abb2628/attachment-0001.png>

From smalltalker2 at mac.com  Sun Jul 12 06:54:03 2020
From: smalltalker2 at mac.com (John Pfersich)
Date: Sat, 11 Jul 2020 23:54:03 -0700
Subject: [squeak-dev] Installer loading cryptography mcm files: used to
	work (I think) and doesn't now
In-Reply-To: <F7A78328-892E-4FD2-9CF3-ADD0EEE9EFC8@gmx.de>
References: <F7A78328-892E-4FD2-9CF3-ADD0EEE9EFC8@gmx.de>
Message-ID: <A4325E8C-FFF6-42E7-A859-B5597EB01DE7@mac.com>

Don’t I wish that were possible...

/—————————————————————/
For encrypted mail use jgpfersich at protonmail.com - Free account at ProtonMail.com
Web: https://objectnets.net and https://objectnets.org
https://datascilv.com https://datascilv.org


> On Jun 16, 2020, at 22:10, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
> 
>> On 17.06.2020, at 05:39, tim Rowledge <tim at rowledge.org> wrote:
>> 
>> It'll do for today. Dang, that random sigline generator is on point today, too ...
>> 
>> tim
>> --
>> tim Rowledge; tim at rowledge.org <mailto:tim at rowledge.org>; http://www.rowledge.org/tim <http://www.rowledge.org/tim>
>> USER ERROR: replace user and press any key to continue.
> 
> Just fell of my chair laughing :)
> -t
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/a9951660/attachment.html>

From karlramberg at gmail.com  Sun Jul 12 10:54:10 2020
From: karlramberg at gmail.com (karl ramberg)
Date: Sun, 12 Jul 2020 12:54:10 +0200
Subject: [squeak-dev] The Inbox: Graphics-kfr.434.mcz
In-Reply-To: <alpine.DEB.2.02.2007111533080.10597@login03.caesar.elte.hu>
References: <E1juAiD-0004Ip-0t@andreas>
 <alpine.DEB.2.02.2007111533080.10597@login03.caesar.elte.hu>
Message-ID: <CAGzzWLjGs3rbH+m86gUwk=zQWxfFGi+e_TNAGBZ-vFJjZ707fg@mail.gmail.com>

Hi,

In Rectangle>>merging: it is quite a bit slower to use points topLeft and
bottomRight, than reading out the min and max of each side.
Also looping with allButFirstDo: is slower than the original method.

This seems to be fastest:

Rectangle>>merging: listOfRects
"A number of callers of merge: should use this method."
| minX minY maxX maxY |
minX := listOfRects first topLeft x.
minY := listOfRects first topLeft y.
maxX := listOfRects first bottomRight x.
maxY := listOfRects first bottomRight y.
listOfRects do: [:r | minX := minX min: r topLeft x.
             minY := minY min: r topLeft y.
             maxX := maxX max: r bottomRight x.
             maxY := maxY max: r bottomRight y].
^self origin: minX at minY corner: maxX at maxY

Best,
Karl

On Sat, Jul 11, 2020 at 3:49 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:

> Hi Karl,
>
> While both changes look right, they modify the behavior of those methods
> when their argument is an empty list.
> Instead of raising an error, they'll return a Rectangle with both fields
> set to nil.
> If the argument is really a list - aka SequenceableCollection, I suggest
> using more specific methods instead of #do: to process the list in order
> to trigger the error as soon as possible.
> For example, use #first to get the first element and #allButFirstDo: to
> iterate over the rest. That would simplify the method as well by making
> the nil checks unnecessary.
>
>
> Levente
>
> On Sat, 11 Jul 2020, commits at source.squeak.org wrote:
>
> > A new version of Graphics was added to project The Inbox:
> > http://source.squeak.org/inbox/Graphics-kfr.434.mcz
> >
> > ==================== Summary ====================
> >
> > Name: Graphics-kfr.434
> > Author: kfr
> > Time: 11 July 2020, 10:18:06.272175 am
> > UUID: 0e0125f6-3040-6247-9e5a-43bfd1896f84
> > Ancestors: Graphics-mt.433
> >
> > I wanted to subclass Rectangle with a instance variable to carry some
> state, but these methodes indirected to Point>>corner: so it broke the
> override and returned a ordinary Rectangle instead of my fancy new subclass
> SuperRectangle
> >
> > =============== Diff against Graphics-mt.433 ===============
> >
> > Item was changed:
> >  ----- Method: Rectangle class>>encompassing: (in category 'instance
> creation') -----
> >  encompassing: listOfPoints
> >       "A number of callers of encompass: should use this method."
> >       | topLeft bottomRight |
> >       topLeft := bottomRight := nil.
> >       listOfPoints do:
> >               [:p | topLeft == nil
> >                       ifTrue: [topLeft := bottomRight := p]
> >                       ifFalse: [topLeft := topLeft min: p.
> >                                       bottomRight := bottomRight max:
> p]].
> > +     ^self origin: topLeft corner: bottomRight!
> > -     ^ topLeft corner: bottomRight!
> >
> > Item was changed:
> >  ----- Method: Rectangle class>>merging: (in category 'instance
> creation') -----
> >  merging: listOfRects
> >       "A number of callers of merge: should use this method."
> >       | minX minY maxX maxY |
> >       listOfRects
> >               do: [:r | minX
> >                               ifNil: [minX := r topLeft x. minY := r
> topLeft y.
> >                                       maxX := r bottomRight x. maxY := r
> bottomRight y]
> >                               ifNotNil: [minX := minX min: r topLeft x.
> minY := minY min: r topLeft y.
> >                                       maxX := maxX max: r bottomRight x.
> maxY := maxY max: r bottomRight y]].
> > +     ^ self origin:minX at minY corner: maxX at maxY!
> > -     ^ minX at minY corner: maxX at maxY!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/0db04dbc/attachment.html>

From leves at caesar.elte.hu  Sun Jul 12 14:10:19 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Sun, 12 Jul 2020 16:10:19 +0200 (CEST)
Subject: [squeak-dev] The Inbox: Graphics-kfr.434.mcz
In-Reply-To: <CAGzzWLjGs3rbH+m86gUwk=zQWxfFGi+e_TNAGBZ-vFJjZ707fg@mail.gmail.com>
References: <E1juAiD-0004Ip-0t@andreas>
 <alpine.DEB.2.02.2007111533080.10597@login03.caesar.elte.hu>
 <CAGzzWLjGs3rbH+m86gUwk=zQWxfFGi+e_TNAGBZ-vFJjZ707fg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.2007121549430.19629@login03.caesar.elte.hu>

Hi Karl,

On Sun, 12 Jul 2020, karl ramberg wrote:

> Hi,
> 
> In Rectangle>>merging: it is quite a bit slower to use points topLeft and bottomRight, than reading out the min and max of each side.

Indeed. Each iteration creates a new point if you use points.

> Also looping with allButFirstDo: is slower than the original method.

I suppose your list of rectangles was an OrderedCollection when you 
measured performance because for most SequenceableCollections 
#allButFirstDo: is slightly faster than #do: by definition.
OrderedCollection overrides #do: for better performance but does not 
have such implementation for #allButFirstDo:/#allButLastDo:.


Levente

> 
> This seems to be fastest:
> 
> Rectangle>>merging: listOfRects
> "A number of callers of merge: should use this method."
> | minX minY maxX maxY |
> minX := listOfRects first topLeft x.
> minY := listOfRects first topLeft y.
> maxX := listOfRects first bottomRight x.
> maxY := listOfRects first bottomRight y.
> listOfRects do: [:r | minX := minX min: r topLeft x.
>              minY := minY min: r topLeft y.
>              maxX := maxX max: r bottomRight x.
>              maxY := maxY max: r bottomRight y].
> ^self origin: minX at minY corner: maxX at maxY
> 
> Best,
> Karl
> 
> On Sat, Jul 11, 2020 at 3:49 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:
>       Hi Karl,
>
>       While both changes look right, they modify the behavior of those methods
>       when their argument is an empty list.
>       Instead of raising an error, they'll return a Rectangle with both fields
>       set to nil.
>       If the argument is really a list - aka SequenceableCollection, I suggest
>       using more specific methods instead of #do: to process the list in order
>       to trigger the error as soon as possible.
>       For example, use #first to get the first element and #allButFirstDo: to
>       iterate over the rest. That would simplify the method as well by making
>       the nil checks unnecessary.
> 
>
>       Levente
>
>       On Sat, 11 Jul 2020, commits at source.squeak.org wrote:
>
>       > A new version of Graphics was added to project The Inbox:
>       > http://source.squeak.org/inbox/Graphics-kfr.434.mcz
>       >
>       > ==================== Summary ====================
>       >
>       > Name: Graphics-kfr.434
>       > Author: kfr
>       > Time: 11 July 2020, 10:18:06.272175 am
>       > UUID: 0e0125f6-3040-6247-9e5a-43bfd1896f84
>       > Ancestors: Graphics-mt.433
>       >
>       > I wanted to subclass Rectangle with a instance variable to carry some state, but these methodes indirected to Point>>corner: so it broke the override and returned a ordinary Rectangle instead of my fancy new
>       subclass SuperRectangle
>       >
>       > =============== Diff against Graphics-mt.433 ===============
>       >
>       > Item was changed:
>       >  ----- Method: Rectangle class>>encompassing: (in category 'instance creation') -----
>       >  encompassing: listOfPoints
>       >       "A number of callers of encompass: should use this method."
>       >       | topLeft bottomRight |
>       >       topLeft := bottomRight := nil.
>       >       listOfPoints do:
>       >               [:p | topLeft == nil
>       >                       ifTrue: [topLeft := bottomRight := p]
>       >                       ifFalse: [topLeft := topLeft min: p.
>       >                                       bottomRight := bottomRight max: p]].
>       > +     ^self origin: topLeft corner: bottomRight!
>       > -     ^ topLeft corner: bottomRight!
>       >
>       > Item was changed:
>       >  ----- Method: Rectangle class>>merging: (in category 'instance creation') -----
>       >  merging: listOfRects
>       >       "A number of callers of merge: should use this method."
>       >       | minX minY maxX maxY |
>       >       listOfRects
>       >               do: [:r | minX
>       >                               ifNil: [minX := r topLeft x. minY := r topLeft y.
>       >                                       maxX := r bottomRight x. maxY := r bottomRight y]
>       >                               ifNotNil: [minX := minX min: r topLeft x. minY := minY min: r topLeft y.
>       >                                       maxX := maxX max: r bottomRight x. maxY := maxY max: r bottomRight y]].
>       > +     ^ self origin:minX at minY corner: maxX at maxY!
>       > -     ^ minX at minY corner: maxX at maxY!
> 
> 
>

From commits at source.squeak.org  Sun Jul 12 14:14:05 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Sun, 12 Jul 2020 14:14:05 0000
Subject: [squeak-dev] The Trunk: Collections-ul.902.mcz
Message-ID: <E1juck7-0003q5-90@andreas>

Levente Uzonyi uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-ul.902.mcz

==================== Summary ====================

Name: Collections-ul.902
Author: ul
Time: 12 July 2020, 4:13:31.850218 pm
UUID: 75865200-256c-40b8-9303-ec9a473c16cf
Ancestors: Collections-ul.901

OrderedCollection changes:

- override #allButFirstDo: and #allButLastDo: the same way #do: is done to achive better performance
- use #to:do: instead of #whileTrue: in all methods iterating over the internal indices

=============== Diff against Collections-ul.901 ===============

Item was added:
+ ----- Method: OrderedCollection>>allButFirstDo: (in category 'enumerating') -----
+ allButFirstDo: aBlock 
+ 	"Override the superclass for performance reasons."
+ 
+ 	firstIndex + 1 to: lastIndex do: [ :index |
+ 		aBlock value: (array at: index) ]!

Item was added:
+ ----- Method: OrderedCollection>>allButLastDo: (in category 'enumerating') -----
+ allButLastDo: aBlock 
+ 	"Override the superclass for performance reasons."
+ 
+ 	firstIndex to: lastIndex - 1 do: [ :index |
+ 		aBlock value: (array at: index) ]!

Item was changed:
  ----- Method: OrderedCollection>>do: (in category 'enumerating') -----
  do: aBlock 
  	"Override the superclass for performance reasons."
+ 	
+ 	firstIndex to: lastIndex do: [ :index | 
+ 		aBlock value: (array at: index) ]!
- 	| index |
- 	index := firstIndex.
- 	[index <= lastIndex]
- 		whileTrue: 
- 			[aBlock value: (array at: index).
- 			index := index + 1]!

Item was changed:
  ----- Method: OrderedCollection>>find: (in category 'private') -----
  find: oldObject
    "  This method answers an index in the range firstIndex .. lastIndex, which is meant for internal use only.
       Never use this method in your code, the methods for public use are:
          #indexOf:
          #indexOf:ifAbsent: "
  
+ 	firstIndex to: lastIndex do: [ :index |
+ 		(array at: index) = oldObject ifTrue: [ ^index ] ].
- 	| index |
- 	index := firstIndex.
- 	[index <= lastIndex]
- 		whileTrue:
- 			[(array at: index) = oldObject ifTrue: [^ index].
- 			index := index + 1].
  	self errorNotFound: oldObject!

Item was changed:
  ----- Method: OrderedCollection>>remove:ifAbsent: (in category 'removing') -----
  remove: oldObject ifAbsent: absentBlock
  
+ 	firstIndex to: lastIndex do: [ :index |
+ 		(array at: index) = oldObject ifTrue: [
+ 			self removeIndex: index.
+ 			^oldObject ] ].
+ 	^absentBlock value!
- 	| index |
- 	index := firstIndex.
- 	[index <= lastIndex]
- 		whileTrue: 
- 			[oldObject = (array at: index)
- 				ifTrue: 
- 					[self removeIndex: index.
- 					^ oldObject]
- 				ifFalse: [index := index + 1]].
- 	^ absentBlock value!

Item was changed:
  ----- Method: OrderedCollection>>reverseDo: (in category 'enumerating') -----
  reverseDo: aBlock 
  	"Override the superclass for performance reasons."
+ 	
+ 	lastIndex to: firstIndex by: -1 do: [ :index |
+ 		aBlock value: (array at: index) ]!
- 	| index |
- 	index := lastIndex.
- 	[index >= firstIndex]
- 		whileTrue: 
- 			[aBlock value: (array at: index).
- 			index := index - 1]!


From builds at travis-ci.org  Sun Jul 12 14:27:50 2020
From: builds at travis-ci.org (Travis CI)
Date: Sun, 12 Jul 2020 14:27:50 +0000
Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1756
	(squeak-trunk - 25ebaf1)
In-Reply-To: <squeak-smalltalk/squeak-app+707368465+errored@travis-ci.org>
Message-ID: <5f0b1de5a34ba_13f8e9649ed7818022@travis-tasks-6c6547cfb5-kwd58.mail>

Build Update for squeak-smalltalk/squeak-app
-------------------------------------

Build: #1756
Status: Errored

Duration: 17 mins and 25 secs
Commit: 25ebaf1 (squeak-trunk)
Author: Marcel Taeumel
Message: Hi all!

The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for.

All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions.

Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs.

-- The Squeak Oversight Board

[ci skip]

View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7

View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/707368465?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/c8c5faf2/attachment.html>

From karlramberg at gmail.com  Sun Jul 12 15:17:06 2020
From: karlramberg at gmail.com (karl ramberg)
Date: Sun, 12 Jul 2020 17:17:06 +0200
Subject: [squeak-dev] The Inbox: Graphics-kfr.434.mcz
In-Reply-To: <alpine.DEB.2.02.2007121549430.19629@login03.caesar.elte.hu>
References: <E1juAiD-0004Ip-0t@andreas>
 <alpine.DEB.2.02.2007111533080.10597@login03.caesar.elte.hu>
 <CAGzzWLjGs3rbH+m86gUwk=zQWxfFGi+e_TNAGBZ-vFJjZ707fg@mail.gmail.com>
 <alpine.DEB.2.02.2007121549430.19629@login03.caesar.elte.hu>
Message-ID: <CAGzzWLgX+4iyr2CHoUciVfpksSD5BDXZ72fr+DHP1s66LOVQPw@mail.gmail.com>

Yes, I tested with OrderedCollection.
Changed to Array and the speed was better.
It seems most senders of the Rectangle>>merging: are with Array eg: subBnds
:= Rectangle merging: (submorphs collect: [:m | m fullBounds]).
But DamageRecorder is an OrderedCollection for example.

I'm not sure how big impact speed will have here though.
I can't measure speed difference for small collections with up to 5000
elements (which will probably cover most use cases)

Change set in attachment.

Best,
Karl

On Sun, Jul 12, 2020 at 4:12 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:

> Hi Karl,
>
> On Sun, 12 Jul 2020, karl ramberg wrote:
>
> > Hi,
> >
> > In Rectangle>>merging: it is quite a bit slower to use points topLeft
> and bottomRight, than reading out the min and max of each side.
>
> Indeed. Each iteration creates a new point if you use points.
>
> > Also looping with allButFirstDo: is slower than the original method.
>
> I suppose your list of rectangles was an OrderedCollection when you
> measured performance because for most SequenceableCollections
> #allButFirstDo: is slightly faster than #do: by definition.
> OrderedCollection overrides #do: for better performance but does not
> have such implementation for #allButFirstDo:/#allButLastDo:.
>
>
> Levente
>
> >
> > This seems to be fastest:
> >
> > Rectangle>>merging: listOfRects
> > "A number of callers of merge: should use this method."
> > | minX minY maxX maxY |
> > minX := listOfRects first topLeft x.
> > minY := listOfRects first topLeft y.
> > maxX := listOfRects first bottomRight x.
> > maxY := listOfRects first bottomRight y.
> > listOfRects do: [:r | minX := minX min: r topLeft x.
> >              minY := minY min: r topLeft y.
> >              maxX := maxX max: r bottomRight x.
> >              maxY := maxY max: r bottomRight y].
> > ^self origin: minX at minY corner: maxX at maxY
> >
> > Best,
> > Karl
> >
> > On Sat, Jul 11, 2020 at 3:49 PM Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
> >       Hi Karl,
> >
> >       While both changes look right, they modify the behavior of those
> methods
> >       when their argument is an empty list.
> >       Instead of raising an error, they'll return a Rectangle with both
> fields
> >       set to nil.
> >       If the argument is really a list - aka SequenceableCollection, I
> suggest
> >       using more specific methods instead of #do: to process the list in
> order
> >       to trigger the error as soon as possible.
> >       For example, use #first to get the first element and
> #allButFirstDo: to
> >       iterate over the rest. That would simplify the method as well by
> making
> >       the nil checks unnecessary.
> >
> >
> >       Levente
> >
> >       On Sat, 11 Jul 2020, commits at source.squeak.org wrote:
> >
> >       > A new version of Graphics was added to project The Inbox:
> >       > http://source.squeak.org/inbox/Graphics-kfr.434.mcz
> >       >
> >       > ==================== Summary ====================
> >       >
> >       > Name: Graphics-kfr.434
> >       > Author: kfr
> >       > Time: 11 July 2020, 10:18:06.272175 am
> >       > UUID: 0e0125f6-3040-6247-9e5a-43bfd1896f84
> >       > Ancestors: Graphics-mt.433
> >       >
> >       > I wanted to subclass Rectangle with a instance variable to carry
> some state, but these methodes indirected to Point>>corner: so it broke the
> override and returned a ordinary Rectangle instead of my fancy new
> >       subclass SuperRectangle
> >       >
> >       > =============== Diff against Graphics-mt.433 ===============
> >       >
> >       > Item was changed:
> >       >  ----- Method: Rectangle class>>encompassing: (in category
> 'instance creation') -----
> >       >  encompassing: listOfPoints
> >       >       "A number of callers of encompass: should use this method."
> >       >       | topLeft bottomRight |
> >       >       topLeft := bottomRight := nil.
> >       >       listOfPoints do:
> >       >               [:p | topLeft == nil
> >       >                       ifTrue: [topLeft := bottomRight := p]
> >       >                       ifFalse: [topLeft := topLeft min: p.
> >       >                                       bottomRight := bottomRight
> max: p]].
> >       > +     ^self origin: topLeft corner: bottomRight!
> >       > -     ^ topLeft corner: bottomRight!
> >       >
> >       > Item was changed:
> >       >  ----- Method: Rectangle class>>merging: (in category 'instance
> creation') -----
> >       >  merging: listOfRects
> >       >       "A number of callers of merge: should use this method."
> >       >       | minX minY maxX maxY |
> >       >       listOfRects
> >       >               do: [:r | minX
> >       >                               ifNil: [minX := r topLeft x. minY
> := r topLeft y.
> >       >                                       maxX := r bottomRight x.
> maxY := r bottomRight y]
> >       >                               ifNotNil: [minX := minX min: r
> topLeft x. minY := minY min: r topLeft y.
> >       >                                       maxX := maxX max: r
> bottomRight x. maxY := maxY max: r bottomRight y]].
> >       > +     ^ self origin:minX at minY corner: maxX at maxY!
> >       > -     ^ minX at minY corner: maxX at maxY!
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/213e18ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RectangleMergeTesting.1.cs
Type: application/octet-stream
Size: 2688 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/213e18ff/attachment-0001.obj>

From robert.withers at pm.me  Sun Jul 12 17:33:09 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sun, 12 Jul 2020 17:33:09 +0000
Subject: [squeak-dev] On the rejection of Promises due to errors
In-Reply-To: <b92c0061-5bfd-d008-5339-b77ca4f353fa@pm.me>
References: <CA+ovNC5FrMheX9rPNv=Yqj00_Cpo4y76Yd2Dc+G56uM-AG0BeA@mail.gmail.com>
 <b92c0061-5bfd-d008-5339-b77ca4f353fa@pm.me>
Message-ID: <4681739d-6353-e128-d06d-9853995f74fd@pm.me>

Hi Jakob,

I was wondering if you had any thoughts regarding PromisesLocal. Have you had a chance to look at this project? I suppose the promise protocol could be extended to capture the protocol specified in Promises/A+, but the same behavior is there (#whenResolved:). I added the ability to open a debugger when an exception gets thrown. Unfortunately, for now this exception blocks the event loop Process. I have another email on how to unblock the event loop Process, yet still open an appropriate Debugger Notifier.

I would welcome any feedback you may have. I am working on the Remote version (PromisesRemote). You can load PromisesLocal and run the tests.

> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.

Kindly,
rabbit

On 6/21/20 5:53 PM, Robert Withers wrote:

> Hi Jakob,
>
> I also have a promises implementation for Squeak and Java, that was derived from ERights, which precedes the JavaScript impl, both by Mark Miller. They do NOT throw up exceptions but they do resolve the promise to a BrokenERef, encapsulating the exception.
>
> You can load the following and run the tests.
>
>> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.
>
> Then I converted the first code you presented as the following.
>
>> promise := 1 eventual / 0.
>>
>> Number compile: 'methodWithTypo ^ self asstring'.
>> promise := 1 eventual methodWithTypo.
>
> They both resolve to BrokenERefs.
>
> I got a little lost in capturing exceptions, within the Vat's event loop #processSends. I have tickled my implementation a little to try and get the Vat event thread to throw an exception, which presents a Debugger. I have been unable to pop up the Debugger on the error, but the promise does get smashed.
>
> These Promises also pipelines the failure to subsequent message sends, with subsequent broken promises. So this also breaks with ZeroDivide.
>
>> (1 eventual / 0) * 10.
>
> Here are the immediate promise return and the smashed promise to a BrokenERef.
>
> Kindly,
> Robert
>
> On 6/21/20 4:57 PM, Jakob Reschke wrote:
>
>> Hi all,
>>
>> Tony has recently fixed our Promise implementation to make it more
>> Promises/A+ compliant, thank you!
>>
>> In the discussion that lead to this fix [1], I already pointed out a
>> difference between exceptions in Smalltalk and in JavaScript, where
>> the Promises/A+ specification originates: Smalltalk exceptions can be
>> resumed, while JavaScript exceptions cannot be resumed and always
>> unroll the stack.
>>
>> The spec [2] says that if the onFulfilled or onRejected callback of a
>> #then call on a promise throws an exception, then the promise returned
>> by the #then call shall be rejected with the exception thrown.
>>
>> Our current Promise implementation matches this for the blocks
>> supplied to #then:, #ifRejected: or #then:ifRejected, by catching all
>> Errors in the blocks and rejecting the promise. But this does not
>> allow a Squeak user to deal with exceptions in a debugger if they are
>> signalled in the callbacks, because they are caught. The same also
>> applies to #future promises. The latter are not really covered by the
>> Promises/A+ spec (because it does not force the resolution or
>> rejection of a promise that is not the result of a #then, and there is
>> no #future in JavaScript), but futures exhibit the same problem of not
>> being resumable in the debugger. Example:
>>
>> promise := 1 future / 0. "<= inspect it => promise is rejected,
>> regardless of your actions in the debugger"
>> Number compile: 'methodWithTypo  ^ self asstring'.
>> promise := 1 future methodWithTypo. "<= inspect it => promise is
>> rejected, no chance to fix the misspelling of asString in the debugger
>> and proceed"
>>
>> I could imagine instead letting all exceptions pass during the future
>> or callback block evaluation, and only reject the promise if the
>> evaluation is eventually curtailed due to the exception (be it an
>> Error or not, think of Warning or ModificationForbidden). Example
>> expectations:
>>
>> promise := 1 future / 0. "<= inspect it, press Proceed in the
>> debugger, => promise is resolved"
>> promise := 1 future / 0. "<= inspect it, press Abandon in the
>> debugger, => promise is rejected"
>> promise := 1 future methodWithTypo. "<= inspect it, fix the typo of
>> asString in the debugger, proceed, => promise is resolved with '1'"
>>
>> It could be done by fulfilling a Promise about aBlock similar to this:
>>
>> [ self resolveWith: aBlock value ]
>>    on: Exception
>>    do: [ :ex | | resumed |
>>       resumed := false.
>>       [ | result |
>>       result := ex outer.
>>       resumed := true.
>>       ex resume: result]
>>          ifCurtailed: [resumed ifFalse: [self future rejectWith: ex]]]
>>
>> (Find the current implementations here:
>> Promise>>#fulfillWith:passErrors: and Promise>>#then:ifRejected:)
>>
>> Note that the #outer send would only trigger handlers in the
>> Project/World loop, or the defaultAction of the exception. The #future
>> in front of #rejectWith: is there to avoid curtailing the unwind block
>> context of ifCurtailed: itself if there are further errors in the
>> rejection callbacks of the promise. The behavior of non-local exits
>> from unwind contexts is undefined in the Smalltalk ANSI standard (just
>> like resume: or return: in a defaultAction, or not sending resume: or
>> return: in an on:do: exception handler at all -- VA Smalltalk
>> interprets that as resume, while Squeak does return, for example).
>>
>> This implementation would also allow all deferred Notifications to
>> pass and not reject the promise. That is because true notifications
>> just resume silently if they are not handled.
>>
>> promise := [Notification signal: 'hi there'. 42] future value. "<=
>> inspect it => Expected: resolved with 42. Actual (today): it is
>> needlessly rejected with Notification 'hi there'"
>>
>> Pressing Proceed in the debugger on officially non-resumable errors
>> (which is possible) would also not reject the promise. But further
>> errors/debuggers are likely to appear, of which one may eventually be
>> used to abort the execution. If the execution finishes after
>> repeatedly pressing Proceed, then fine, resolve the promise with
>> whatever the outcome was.
>>
>> promise := [self error: 'Fatal error'. 42] future value. "<= inspect
>> it, proceed after the so-called fatal error, => Expected: resolved
>> with 42. Actual: there is no debugger, the promise is immediately
>> rejected."
>>
>> promise := [1 / 0 + 3] future value. "<= Cannot be resumed/proceeded
>> because if ZeroDivide is resumed, it will return the exception, and
>> ZeroDivide does not understand +, which cannot be resumed without
>> changing the code. So you'd have to curtail the block execution =>
>> Expected: rejected with ZeroDivide or MessageNotUnderstood (depending
>> on when you press Abandon or recompile the DoIt)."
>>
>> promise := [1 / 0 + 3] future value. "... or instead of changing the
>> code or aborting, you could choose 'return entered value' in one of
>> the debuggers, and thereby complete the evaluation of the block =>
>> Expected: resolved with whatever you entered to return in the
>> debugger"
>>
>> Promises with whenRejected:/ifRejected: callbacks would no longer
>> swallow errors, and would only be rejected when the user aborts in the
>> debuggers, or if the future execution catches errors by itself and
>> converts them to rejected promises, so the future promise will also be
>> rejected. This could pose a compatibility problem for existing code.
>>
>> promise := (1 future / 0) then: [:result | result + 3] ifRejected:
>> [:reason | #cancelled]. "<= inspect it => Actual: resolved with
>> #cancelled immediately. Expected with my proposed changes: it would
>> first show the ZeroDivide debugger, which you can abandon to resolve
>> with #cancelled, or proceed to a MessageNotUnderstood +. If you
>> abandon the MNU, the promise would be rejected with the MNU, not
>> #cancelled, in accordance with the Promises/A+ spec."
>>
>> How to get back a catch-all->reject-immediately future under these
>> circumstances:
>>
>> promise := [[1 / 0] on: Error do: [:e | e return: (Promise new
>> rejectWith: e)]] future value.
>> promise := [1 future + 1 then: [:n | [n / 0] on: Error do: [:e | e
>> return: (Promise new rejectWith: e)]] future value.
>>
>> We could also introduce a convenience constructor for
>> immediately-rejected promises like in JavaScript: Promise rejected: e.
>> Or a convenience exception handler: [...] rejectOn: Error.  Or [...]
>> rejectIfCurtailed (the fullfill/then methods would probably use this
>> as well).
>>
>> What do you think?
>>
>> As Tom Beckmann has already suggested in the last thread on the topic
>> [1], I could also use a custom class of Promise to get just the
>> behavior I want. But then I cannot solve it for the use of #future. At
>> least not without patching something about the compiler in my package
>> preamble... ;-)
>>
>> [1]
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208546.html
>> [2]
>> https://promisesaplus.com/
>> Kind regards,
>> Jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/dcc6ec3f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BrokenERef.jpeg
Type: image/jpeg
Size: 13669 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/dcc6ec3f/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PromiseERef.jpeg
Type: image/jpeg
Size: 14586 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/dcc6ec3f/attachment-0001.jpeg>

From robert.withers at pm.me  Sun Jul 12 17:38:23 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sun, 12 Jul 2020 17:38:23 +0000
Subject: [squeak-dev] Short Stack exception presentation (was Re: Dual
	screen?)
In-Reply-To: <f7466948-31f8-b397-55df-d25bf6d9b890@pm.me>
References: <5a557920-e941-2d62-5144-c6993550d90d@pm.me>
 <6BB60895-1A09-4F85-AFDD-0AD6E7C11E41@rowledge.org>
 <88caa1b0-25b4-2fb3-e53a-6144ae7e0077@pm.me>
 <f7466948-31f8-b397-55df-d25bf6d9b890@pm.me>
Message-ID: <6085c2c4-a33c-63c7-0a6d-a90b87ef7fdd@pm.me>

On 6/26/20 2:37 PM, Robert Withers wrote:

> On 6/26/20 1:55 PM, Robert Withers wrote:
>
>> Closer to my heart, at this point are my questions and request for help
>> in splitting off a pruned stack for an exception, to unblock the event
>> loop yet still allow introspection of an error, or a halt. Here is what
>> I wrote. Tim, might you be able to advise me here?
>>
>> *
>>
>> lost
>>
>> *
>>
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-June/210452.html

The requirements for exceptions within an event loop are:

- Copy stack
- Restart eventLoop
- Prune stack/Create Continuation
- Open Debugger
- When Proceeded, reschedule EventualMessageSend, on the Continuation, in the vat queue.

Would someone please help me here? I am a little lost. I appreciate you!

Kindly,
rabbit

> Not only do I want this, but the short stack, when Proceeded, should reschedule an eventual message on the event loop to reintroduce this short stack back into event loop land. As such, i was thinking perhaps a continuation could enable this. Liekwise, when a exception is thrown, do these steps:
>
>> - Modify the Vat to have a an active stack, a priority queue and a vat-aware continuation pool.
>> - Copy the stack. Does this mean create a special continuation, that is event loop aware?
>> - Resume the event loop by discarding the previous event handling exception.
>> - Prune the stack (of the continuation). above and below. Site of signaled exception.
>> - Open a Debugger
>> - On Proceed, reschedule the eventual message in the Vat's queue.
>
> I have no idea what B looks like. Outside of my experience doing continuations and stack manipulation and pool scheduling. I need a VatSemaphore (please peruse the ResultSemaphore in PromisesRemote). I pray someone may swoop in with solutions!
>
> Kindly,
> rabbit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/4752f0c9/attachment.html>

From lewis at mail.msen.com  Sun Jul 12 17:58:56 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Sun, 12 Jul 2020 13:58:56 -0400
Subject: [squeak-dev] Proposal for new BitBlt rules (was: We need to talk
	about graphics)
In-Reply-To: <rdo4kh$h4o$1@ciao.gmane.io>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CA+CiqoW0rQ3yS5WQVn4Vu+Dg6M3NeCeLj60wWRS=cOFQ8r4D=w@mail.gmail.com>
 <CAN7OfXQyzSK500arwGvnSktLy_b9=RTjvENfLoW3YSraX2E2OQ@mail.gmail.com>
 <8466da4b-2ded-daaa-645b-573271857b67@zogotounga.net>
 <rdnlil$b44$1@ciao.gmane.io> <20200703202118.GB52195@shell.msen.com>
 <rdo4kh$h4o$1@ciao.gmane.io>
Message-ID: <20200712175856.GA12960@shell.msen.com>

Changing the subject line to focus on a specific proposal by Juan Vuletich
for an enhancement to BitBlt rules.

The idea originated from discussion on the Cuis list, and the proposal
is documented in an opensmalltalk-vm issue here:

  https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/505

While I am generally familiar with VM issues, I have no experience with
BitBlt and I am not sure exactly what needs to be done to make this
happen. There are VM (plugin) changes needed, and some image side support
will needed as well (at least for fallback code in the image).

So - who knows how to make this happen, and how do we make it so?

Thanks,
Dave


On Fri, Jul 03, 2020 at 10:32:17PM +0200, Hilaire wrote:
> Le 03/07/2020 ?? 22:21, David T. Lewis a ??crit??:
> >>Juan proposed these primitives to speed up the rendering of
> >>VectorGraphics Widget Morph.
> >I remember a discussion about that, though I don't have a link to it. It
> >sounds like we need to follow up on this and make something happen.
> 
> Here it is:
> 
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/505
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> https://pouet.chapril.org/@hilaire
> 

> 


From tim at rowledge.org  Sun Jul 12 18:01:47 2020
From: tim at rowledge.org (tim Rowledge)
Date: Sun, 12 Jul 2020 11:01:47 -0700
Subject: [squeak-dev] A note for implementers of email programs (was Re:
 Installer loading cryptography mcm files: used to work (I think) and
 doesn't now)
In-Reply-To: <A4325E8C-FFF6-42E7-A859-B5597EB01DE7@mac.com>
References: <F7A78328-892E-4FD2-9CF3-ADD0EEE9EFC8@gmx.de>
 <A4325E8C-FFF6-42E7-A859-B5597EB01DE7@mac.com>
Message-ID: <3CF8E4D2-DC33-4967-87E0-AED45985F1E9@rowledge.org>

In the event that any of you ever have a go at writing an email program, I do urge you to make sure that there is a way to hook up a random number generator and a user editable list of sigline entries. It's not a complex concept but it produces so many moments of "wuh? how on earth did it make such an apposite choice?"

> On 2020-07-11, at 11:54 PM, John Pfersich via Squeak-dev <squeak-dev at lists.squeakfoundation.org> wrote:
> 
> Don’t I wish that were possible...
> 
> /—————————————————————/
> For encrypted mail use jgpfersich at protonmail.com - Free account at ProtonMail.com
> Web: https://objectnets.net and https://objectnets.org
> https://datascilv.com https://datascilv.org
> 
> 
>> On Jun 16, 2020, at 22:10, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> 
>>> On 17.06.2020, at 05:39, tim Rowledge <tim at rowledge.org> wrote:
>>> 
>>> It'll do for today. Dang, that random sigline generator is on point today, too ...
>>> 
>>> tim
>>> --
>>> tim Rowledge; tim at rowledge.org <mailto:tim at rowledge.org>; http://www.rowledge.org/tim <http://www.rowledge.org/tim>
>>> USER ERROR: replace user and press any key to continue.
>> 
>> Just fell of my chair laughing :)
>> -t
>> 
> 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Dukedom: aristocratic birth control



From Yoshiki.Ohshima at acm.org  Sun Jul 12 18:23:52 2020
From: Yoshiki.Ohshima at acm.org (Yoshiki Ohshima)
Date: Sun, 12 Jul 2020 11:23:52 -0700
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <CA+CiqoW0rQ3yS5WQVn4Vu+Dg6M3NeCeLj60wWRS=cOFQ8r4D=w@mail.gmail.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CA+CiqoW0rQ3yS5WQVn4Vu+Dg6M3NeCeLj60wWRS=cOFQ8r4D=w@mail.gmail.com>
Message-ID: <CAHC3jCOL7q4u-Nu9La=CMbmUhtm5hx0itzY1MBXq3vgB3+zh3A@mail.gmail.com>

Hi Eric,

On Mon, Jun 29, 2020 at 4:16 PM Eric Gade <eric.gade at gmail.com> wrote:

> Nile seems like a fascinating option and I've tried to read as much about
> it as I can. Unfortunately aside from the various posted talks online and
> the VPRI papers, there's not a lot of information about using it (unless I
> am missing something -- you can track a github issue about its status here
> <https://github.com/damelang/nile/issues/3>). My guess is that the Gezira
> part, of which there is even less information, is very closely tied to the
> specific Frank environment in which it was used -- is that correct? Using
> plain Squeak how would one even incorporate Nile?
>

Nile and the graphics engine Gezira written in Nile was quite independent
from Squeak. Vanessa made a VM plugin for the C-version of Gezira runtime,
and the bindings code issues Gezira requests from Squeak. That part can is
reusable. But going through the VM plugin had some overhead, and also
Gezira does not on purpose provide optimization for common cases or special
cases (such as filling an integer coordinate rectangle with a uniform
color, etc.) so performance characteristics was not always a win.

There was other comments about JITting. It is potentially a great idea but
it'd be a quite effort to make sure the multi core execution (or even using
GPU) sane and efficient.

-- 
-- Yoshiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/a25c4c39/attachment.html>

From Yoshiki.Ohshima at acm.org  Sun Jul 12 18:28:14 2020
From: Yoshiki.Ohshima at acm.org (Yoshiki Ohshima)
Date: Sun, 12 Jul 2020 11:28:14 -0700
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <5DD6E594-6DC4-423B-ABED-AA2B7AAF9AC9@rowledge.org>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <20200629030109.C472B54011A@proxy.email-ssl.com.br>
 <CA+CiqoW0rQ3yS5WQVn4Vu+Dg6M3NeCeLj60wWRS=cOFQ8r4D=w@mail.gmail.com>
 <CAN7OfXQyzSK500arwGvnSktLy_b9=RTjvENfLoW3YSraX2E2OQ@mail.gmail.com>
 <8466da4b-2ded-daaa-645b-573271857b67@zogotounga.net>
 <rdnlil$b44$1@ciao.gmane.io>
 <20200703202118.GB52195@shell.msen.com> <rdo4kh$h4o$1@ciao.gmane.io>
 <3E4824E0-D3B1-4A7D-B301-A73228785FC6@rowledge.org>
 <20200703222607.GA76689@shell.msen.com>
 <5DD6E594-6DC4-423B-ABED-AA2B7AAF9AC9@rowledge.org>
Message-ID: <CAHC3jCN4-WTLZWm-0z-bxf0-8i8QxDFHoktx4_N5MJYmfDAqgg@mail.gmail.com>

On Thu, Jul 9, 2020 at 1:40 PM tim Rowledge <tim at rowledge.org> wrote:

> What are we going to actually try to do here? Who has time/interest/skill?
>
> The Nile/Gezira stuff obviously sounds great but there is the question of
> actually getting it working usefully, let alone finishing it. Will that
> ever happen? Is what exists good enough and complete enough to be of use?
>

The current implementation probably is not going to work.  I think the
C-runtime does not work on a 64-bit environment, IIRC.

There is a downloadable 'Frank' image that seems to start up ok at
> http://tinlizzie.org/~ohshima/Frank-170908.zip  It is a Squeak 4.4 image
> as far as I can tell so you need an older VM of roughly that vintage -
> pre-Spur anyway.
>

As long as the VM plugin mechanism has not changed that much, it should be
relatively easy to bring it up to date.

>
> The small examples mostly work ok (see things like GeziraCanvas
> class>example* & GZKernel class>example*) though one or two take a very
> long time.
>

Such an example is using the Squeak-runtime; that is all stream data was
processed in the interpreter and each kernel does its job one by one to
illustrate that you can have different Nile runtimes and the core idea is
very simple.  Performance was not a goal for the Squeak-runtime.
-- 
-- Yoshiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/05314df7/attachment-0001.html>

From Yoshiki.Ohshima at acm.org  Sun Jul 12 18:30:31 2020
From: Yoshiki.Ohshima at acm.org (Yoshiki Ohshima)
Date: Sun, 12 Jul 2020 11:30:31 -0700
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <C25255B1-763E-4635-BB09-7BE43C941E6D@rowledge.org>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <re97u9$kkk$1@ciao.gmane.io>
 <C25255B1-763E-4635-BB09-7BE43C941E6D@rowledge.org>
Message-ID: <CAHC3jCPUguD3aDFXG9JuUer3Zc4wNPCOMu_+At=dqY3g+HPZVA@mail.gmail.com>

On Sat, Jul 11, 2020 at 2:05 PM tim Rowledge <tim at rowledge.org> wrote:

>
>
> Not many things *I* want to do are very performance limited, so that isn't
> something that exercises *me* but I'm sure others have very different
> perspectives.
>
> I have played a little with a Frank image to see if the Nile/Gezira system
> as-is does much better. For a circle, for example, it does do somewhat
> better *if* the stroke alpha is set to ~0.5. I'm way to out of the world of
> computer graphics to say more than that.
>

Gezira itself is very consistent.  If you see some artifact, it might be
because the final step of putting bits generated by Gezira onto the screen
has wrong alpha interpretation or such.


>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- The wheel's spinning but the hamster's dead.
>
>
>
>

-- 
-- Yoshiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/2c0bdb00/attachment.html>

From eric.gade at gmail.com  Sun Jul 12 19:30:36 2020
From: eric.gade at gmail.com (Eric Gade)
Date: Sun, 12 Jul 2020 15:30:36 -0400
Subject: [squeak-dev] Squeak RISC-V ISA 32I Implementation
Message-ID: <CA+CiqoUEOyf4UR54Lbhn9P+rfkXebMdWJrkT5PUmxLppY4W5Vw@mail.gmail.com>

Hi all,

I've hit a small milestone on a personal project that I would like to
share. It is a Squeak implementation of the RISC-V ISA, along with a (very
basic for now) CPU and memory for simulation and testing. You can find the
project here <https://github.com/darth-cheney/safe-bet/>.

So far I have only implemented the basic 32I instructions from the
unprivileged ISA <https://riscv.org/specifications/isa-spec-pdf/>. My goal
is to get the basic extension instructions implemented too, along with the
64I instructions. In terms of personal goals for the project, I'm thinking
of doing something stupid like writing my own OS and Squeak seems like the
kind of reduced-frustration environment that might curtail some of the
inevitable hair-pulling.

Disclaimer: my knowledge of the low-level systems stuff is quite limited,
so writing this package has been a learning experience. That's a polite way
of saying "I have no idea what I'm actually doing." So if you spot any
design choices you think are offensive or downright insane, please do file
an issue or send me a message. I'm hoping that somehow this will be useful
to the community.

If you'd like to give this a whirl, your best bet is to check out
RVCPUBasic >> #bootstrap:, which takes an ordered collection of
RVInstructions and loads them into the simulated memory starting at address
0. You can then send the #start message to the CPU and it will run through
the instructions in memory one by one. For the moment there aren't any
example "programs" to run here -- I'm open to suggestions!

I've tried to write tests as comprehensively as possible, but I'm sure I'm
missing some important cases and there are certainly going to be bugs.

Shout out to the TwosComplement package
<http://www.squeaksource.com/TwosComplement/>, which really helped me
figure things out when I was in a bind.

The repo is called "Safe Bet" because it's a "small(talk) risc"

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200712/6141a2f8/attachment.html>

From lecteur at zogotounga.net  Sun Jul 12 20:56:07 2020
From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=)
Date: Sun, 12 Jul 2020 22:56:07 +0200
Subject: [squeak-dev] Disappearing MVC code panes
Message-ID: <9713d621-506d-024e-8545-09819159988d@zogotounga.net>

Hello all,

Playing a bit with MVC I found the following bug:

If preference "optional buttons" in the "browsing" category is turned 
off, the code panes in all MVC browsers are not displayed.

Stef

From tonyg at leastfixedpoint.com  Mon Jul 13 07:01:44 2020
From: tonyg at leastfixedpoint.com (Tony Garnock-Jones)
Date: Mon, 13 Jul 2020 09:01:44 +0200
Subject: [squeak-dev] Squeak RISC-V ISA 32I Implementation
In-Reply-To: <CA+CiqoUEOyf4UR54Lbhn9P+rfkXebMdWJrkT5PUmxLppY4W5Vw@mail.gmail.com>
References: <CA+CiqoUEOyf4UR54Lbhn9P+rfkXebMdWJrkT5PUmxLppY4W5Vw@mail.gmail.com>
Message-ID: <6c60fc99-8702-0a25-ac86-cc9260c351ee@leastfixedpoint.com>

On 7/12/20 9:30 PM, Eric Gade wrote:
> I've hit a small milestone on a personal project that I would like to
> share. It is a Squeak implementation of the RISC-V ISA, along with a
> (very basic for now) CPU and memory for simulation and testing. You can
> find the project here <https://github.com/darth-cheney/safe-bet/>.

This looks like fun!

What kinds of applications or experiments do you have in mind for it?

> The repo is called "Safe Bet" because it's a "small(talk) risc"

Also, this is an excellent name :-)

Tony

From robert.withers at pm.me  Mon Jul 13 07:17:24 2020
From: robert.withers at pm.me (Robert Withers)
Date: Mon, 13 Jul 2020 07:17:24 +0000
Subject: [squeak-dev] look what appeared in my news feed!
Message-ID: <78616baa-99cd-1d03-b80f-e4e1745992ff@pm.me>

Hey, what's up? Well, here was a news article that appeared in my google 
news feed.

https://hackaday.com/2020/07/12/making-smalltalk-on-a-raspberry-pi/

Sadly, they do not mention Squeak, just GNU Smalltalk.

K, r



From Das.Linux at gmx.de  Mon Jul 13 08:03:53 2020
From: Das.Linux at gmx.de (Tobias Pape)
Date: Mon, 13 Jul 2020 10:03:53 +0200
Subject: [squeak-dev] Squeak RISC-V ISA 32I Implementation
In-Reply-To: <6c60fc99-8702-0a25-ac86-cc9260c351ee@leastfixedpoint.com>
References: <CA+CiqoUEOyf4UR54Lbhn9P+rfkXebMdWJrkT5PUmxLppY4W5Vw@mail.gmail.com>
 <6c60fc99-8702-0a25-ac86-cc9260c351ee@leastfixedpoint.com>
Message-ID: <0B11BD3F-57BB-4A28-8827-C4F0F80D6FAC@gmx.de>

Hi!

> On 13.07.2020, at 09:01, Tony Garnock-Jones <tonyg at leastfixedpoint.com> wrote:
> 
> On 7/12/20 9:30 PM, Eric Gade wrote:
>> I've hit a small milestone on a personal project that I would like to
>> share. It is a Squeak implementation of the RISC-V ISA, along with a
>> (very basic for now) CPU and memory for simulation and testing. You can
>> find the project here <https://github.com/darth-cheney/safe-bet/>.
> 
> This looks like fun!

I'm very happy about that.

> 
> What kinds of applications or experiments do you have in mind for it?
> 
>> The repo is called "Safe Bet" because it's a "small(talk) risc"
> 
> Also, this is an excellent name :-)

very nice!

Jecel should have a look at that!

Best regards
	-Tobias

From commits at source.squeak.org  Mon Jul 13 09:48:34 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Mon, 13 Jul 2020 09:48:34 0000
Subject: [squeak-dev] The Trunk: ST80-mt.256.mcz
Message-ID: <E1juv4e-0003DM-8u@andreas>

Marcel Taeumel uploaded a new version of ST80 to project The Trunk:
http://source.squeak.org/trunk/ST80-mt.256.mcz

==================== Summary ====================

Name: ST80-mt.256
Author: mt
Time: 13 July 2020, 11:48:31.957623 am
UUID: 354bbbf1-f342-ca44-92c6-f5556433cecc
Ancestors: ST80-mt.255

Makes MVC lists, window titles, menus, and "dialogs" aware of demo/hi-dpi mode.

=============== Diff against ST80-mt.255 ===============

Item was changed:
  Paragraph subclass: #ListParagraph
  	instanceVariableNames: ''
+ 	classVariableNames: ''
- 	classVariableNames: 'ListStyle'
  	poolDictionaries: ''
  	category: 'ST80-Support'!
  
  !ListParagraph commentStamp: '<historical>' prior: 0!
  I represent a special type of Paragraph that is used in the list panes of a browser.  I  avoid all the composition done by more general Paragraphs, because I know the structure of my Text.!

Item was removed:
- ----- Method: ListParagraph class>>initialize (in category 'initialization') -----
- initialize 
- 	"ListParagraph initialize"
- 	| aFont |
- 	"Allow different line spacing for lists"
- 	aFont := Preferences standardListFont.
- 	ListStyle := TextStyle fontArray: { aFont }.
- 	ListStyle gridForFont: 1 withLead: 1!

Item was changed:
  ----- Method: ListParagraph class>>standardListStyle (in category 'style') -----
  standardListStyle
+ 
+ 	^ (TextStyle fontArray: { Preferences standardListFont })
+ 			gridForFont: 1 withLead: 1;
+ 			yourself!
- 	^ ListStyle!

Item was changed:
  ----- Method: ListParagraph class>>withArray:style: (in category 'instance creation') -----
  withArray: anArray style: aTextStyleOrNil
  	"Convert an array of strings into a ListParagraph using the given TextStyle."
  
  	aTextStyleOrNil
+ 		ifNil: [^ (super withText: Text new style: self standardListStyle) withArray: anArray]
- 		ifNil: [^ (super withText: Text new style: ListStyle) withArray: anArray]
  		ifNotNil: [^ (super withText: Text new style: aTextStyleOrNil) withArray: anArray].
  !

Item was changed:
  ----- Method: MVCProject>>jumpToProject (in category 'utilities') -----
  jumpToProject
  	"Present a list of potential projects and enter the one selected.
  	We use mvcStartUpLeftFlush for possibly no longer valid historical reasons"
  
  	"Project current jumpToProject"
  
+ 	self jumpToSelection: (self buildJumpToMenu: CustomMenu new) startUp!
- 	self jumpToSelection: (self buildJumpToMenu: CustomMenu new) mvcStartUpLeftFlush!

Item was changed:
  ----- Method: PopUpMenu>>computeLabelParagraph (in category '*ST80-Support') -----
  computeLabelParagraph
  	"Answer a Paragraph containing this menu's labels, one per line and centered."
  
+ 	^ Paragraph withText: labelString asText style: self class standardMenuStyle!
- 	^ Paragraph withText: labelString asText style: MenuStyle!

Item was removed:
- ----- Method: PopUpMenu>>mvcStartUpLeftFlush (in category '*ST80-Menus') -----
- mvcStartUpLeftFlush
- 	"Build and invoke this menu with no initial selection.  By Jerry Archibald, 4/01.
- 	If in MVC, align menus items with the left margin.
- 	Answer the selection associated with the menu item chosen by the user or nil if none is chosen.  
- 	The mechanism for getting left-flush appearance in mvc leaves a tiny possibility for misadventure: if the user, in mvc, puts up the jump-to-project menu, then hits cmd period while it is up, then puts up a second jump-to-project menu before dismissing or proceeding through the debugger, it's possible for mvc popup-menus thereafter to appear left-aligned rather than centered; this very unlikely condition can be cleared by evaluating 'PopUpMenu alignment: 2'"
- 
- 	| saveAlignment |
- 	saveAlignment := PopUpMenu alignment.
- 		PopUpMenu leftFlush.
- 	^[self startUp] ensure:
- 		[PopUpMenu alignment: saveAlignment]!

Item was changed:
  View subclass: #StandardSystemView
  	instanceVariableNames: 'labelFrame labelText isLabelComplemented savedSubViews minimumSize maximumSize collapsedViewport expandedViewport labelBits windowBits bitsValid updatablePanes'
+ 	classVariableNames: 'CacheBits'
- 	classVariableNames: 'CacheBits LabelStyle'
  	poolDictionaries: ''
  	category: 'ST80-Support'!
  
  !StandardSystemView commentStamp: '<historical>' prior: 0!
  I represent a view that has a label above its top left corner. The text in the label identifies the kind of view. In addition to a label, I add control over the maximum and minimum size of the display box of my instance. My default controller is StandardSystemController. The elements of ScheduledControllers, the sole instance of ControlManager, are usually controllers for instances of me.!

Item was changed:
  ----- Method: StandardSystemView class>>initialize (in category 'class initialization') -----
  initialize		"StandardSystemView initialize"
+ 	self doCacheBits.!
- 	self doCacheBits.
- 	self setLabelStyle!

Item was removed:
- ----- Method: StandardSystemView class>>setLabelStyle (in category 'class initialization') -----
- setLabelStyle
- 	| aFont |
- 	"StandardSystemView setLabelStyle"
- 	aFont := Preferences windowTitleFont.
- 	LabelStyle := TextStyle fontArray: { aFont }.
- 	LabelStyle gridForFont: 1 withLead: 0!

Item was added:
+ ----- Method: StandardSystemView class>>standardLabelStyle (in category 'class initialization') -----
+ standardLabelStyle
+ 
+ 	^ (TextStyle fontArray: { Preferences windowTitleFont })
+ 			gridForFont: 1 withLead: 0;
+ 			yourself!

Item was changed:
  ----- Method: StandardSystemView>>label: (in category 'label access') -----
  label: aString 
  	"Set aString to be the receiver's label."
  	labelText := Paragraph
  			withText: (Text fromString: ((aString == nil or: [aString isEmpty])
  								ifTrue: ['Untitled' copy]
  								ifFalse: [aString]))
+ 			style: self class standardLabelStyle.
- 			style: LabelStyle.
  	insetDisplayBox == nil ifTrue: [^ self].  "wait for further initialization"
  	self setLabelRegion!

Item was changed:
  ----- Method: StandardSystemView>>labelHeight (in category 'label access') -----
  labelHeight
+ 	^ ((self class standardLabelStyle fontAt: 1) height + 4) max: 20!
- 	^ ((LabelStyle fontAt: 1) height + 4) max: 20!


From commits at source.squeak.org  Mon Jul 13 09:49:24 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Mon, 13 Jul 2020 09:49:24 0000
Subject: [squeak-dev] The Trunk: Tools-mt.982.mcz
Message-ID: <E1juv5U-0003ER-1a@andreas>

Marcel Taeumel uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-mt.982.mcz

==================== Summary ====================

Name: Tools-mt.982
Author: mt
Time: 13 July 2020, 11:49:22.018623 am
UUID: 870fe86a-ad9d-c34d-9103-645414fb1259
Ancestors: Tools-mt.981

Complements ST80-mt.256

=============== Diff against Tools-mt.981 ===============

Item was changed:
  ----- Method: Browser>>buildAndOpenFullBrowser (in category 'toolbuilder') -----
  buildAndOpenFullBrowser
  	"assemble the spec for a full system browser, build it and open it"
  
+ 	| builder window |
- 	| builder  windowSpec |
  	builder := ToolBuilder default.
  
  	"the build-but-don't-open phase is factored out to support the prototypicalToolWindow facility"
+ 	window := self buildDefaultBrowserWith: builder.
+ 	builder open: window.!
- 	windowSpec := self buildDefaultBrowserWith: builder.
- 	builder open: windowSpec.
- 	
- 	^self
- !

Item was changed:
  ----- Method: CustomMenu>>build (in category 'private') -----
  build
  	"Turn myself into an invokable ActionMenu."
  
  	| stream |
  	stream := WriteStream on: (String new).
  	labels do: [:label | stream nextPutAll: label; cr].
  	(labels isEmpty) ifFalse: [stream skip: -1].  "remove final cr"
  	super labels: stream contents
+ 		font: Preferences standardMenuFont
- 		font: MenuStyle defaultFont
  		lines: dividers!

Item was changed:
  ----- Method: HierarchyBrowser>>buildAndOpenBrowserLabel: (in category 'toolbuilder') -----
  buildAndOpenBrowserLabel: aLabelString
  	"assemble the spec for a class list/hierarchy browser, build it and open it"
  
+ 	| builder window |
- 	| builder  windowSpec |
  	builder := ToolBuilder default.
  
+ 	window := self buildDefaultBrowserWith: builder.
+ 	aLabelString ifNotNil: [:str | window label: str].
- 	windowSpec := self buildDefaultBrowserWith: builder.
- 	aLabelString ifNotNil:[:str| windowSpec label: str].
  
+ 	builder open: window.!
- 	builder open: windowSpec.
- 	
- 	^self
- !

Item was changed:
  Object subclass: #PopUpMenu
  	instanceVariableNames: 'labelString font lineArray frame form marker selection'
+ 	classVariableNames: 'CacheMenuForms'
- 	classVariableNames: 'CacheMenuForms MenuStyle'
  	poolDictionaries: ''
  	category: 'Tools-Menus'!
  
  !PopUpMenu commentStamp: '<historical>' prior: 0!
  I represent a list of items. My instances are presented on the display screen in a rectangular area. The user points to an item, pressing a mouse button; the item is highlighted. When the button is released, the highlighted item indicates the selection.!

Item was removed:
- ----- Method: PopUpMenu class>>alignment (in category 'class initialization') -----
- alignment
- 
- 	^ MenuStyle alignment!

Item was removed:
- ----- Method: PopUpMenu class>>alignment: (in category 'class initialization') -----
- alignment: anAlignment
- 
- 	^ MenuStyle alignment: anAlignment!

Item was removed:
- ----- Method: PopUpMenu class>>initialize (in category 'class initialization') -----
- initialize  "PopUpMenu initialize"
- 	(MenuStyle := TextStyle default copy)
- 		gridForFont: TextStyle default defaultFontIndex withLead: 0;
- 		centered.
- 	PopUpMenu allSubInstancesDo: [:m | m rescan]!

Item was changed:
  ----- Method: PopUpMenu class>>labels:lines: (in category 'instance creation') -----
  labels: aString lines: anArray
  	"Answer an instance of me whose items are in aString, with lines drawn 
  	after each item indexed by anArray."
  
  	^ self new
  		labels: aString
+ 		font: Preferences standardMenuFont
- 		font: MenuStyle defaultFont
  		lines: anArray!

Item was removed:
- ----- Method: PopUpMenu class>>leftFlush (in category 'class initialization') -----
- leftFlush
- 
- 	MenuStyle leftFlush!

Item was removed:
- ----- Method: PopUpMenu class>>setMenuFontTo: (in category 'class initialization') -----
- setMenuFontTo: aFont
- 	"Set the menu font as indicated"
- 
- 	MenuStyle := TextStyle fontArray: { aFont }.
- 	MenuStyle 
- 		gridForFont: 1 withLead: 0;
- 		centered.
- 	self allSubInstancesDo: [:m | m rescan]!

Item was added:
+ ----- Method: PopUpMenu class>>standardMenuStyle (in category 'class initialization') -----
+ standardMenuStyle
+ 
+ 	^ (TextStyle fontArray: { Preferences standardMenuFont })
+ 		gridForFont: 1 withLead: 0;
+ 		centered;
+ 		yourself!

Item was changed:
  ----- Method: PopUpMenu>>computeForm (in category 'private') -----
  computeForm
  	"Compute and answer a Form to be displayed for this menu."
  
+ 	| borderInset paraForm menuForm menuStyle inside |
- 	| borderInset paraForm menuForm inside |
  	borderInset := 4 at 4.
+ 	menuStyle := self class standardMenuStyle.
+ 	paraForm := ((DisplayText text: labelString asText textStyle: menuStyle)
- 	paraForm := ((DisplayText text: labelString asText textStyle: MenuStyle)
  		foregroundColor: (self userInterfaceTheme textColor ifNil: [Color black])
  		backgroundColor: (self userInterfaceTheme color ifNil: [Color white])) form.
  	menuForm := Form extent: paraForm extent + (borderInset * 2) depth: paraForm depth.
        menuForm fill: (0 @ 0 extent: menuForm  extent)
                          rule: Form over
                          fillColor: (self userInterfaceTheme color ifNil: [Color white]).
  	menuForm
  		border: menuForm boundingBox
  		width: 2
  		fillColor: (self userInterfaceTheme borderColor ifNil: [Color black]).
  	
  	paraForm displayOn: menuForm at: borderInset.
  	lineArray == nil ifFalse:
  		[lineArray do:
  			[ :line |
  			menuForm
  				fill: (4 @ ((line * font height) + borderInset y)
  						extent: (menuForm width - 8 @ 1))
  				rule: Form over
  				fillColor: (self userInterfaceTheme lineColor ifNil: [Color black])]].
  
  	frame := Quadrangle new.
  	frame region: menuForm boundingBox.
  	frame borderWidth: 4.
  	inside := frame inside.
+ 	marker := inside topLeft extent: (inside width @ menuStyle lineGrid).
- 	marker := inside topLeft extent: (inside width @ MenuStyle lineGrid).
  	selection := 1.
  
  	^ form := menuForm
  !

Item was changed:
  ----- Method: PopUpMenu>>displayAt:withCaption:during: (in category 'displaying') -----
  displayAt: aPoint withCaption: captionOrNil during: aBlock
  	"Display the receiver just to the right of aPoint while aBlock is evaluated.  If the receiver is forced off screen, display it just to the right."
  	| delta savedArea captionForm captionSave outerFrame captionText tFrame frameSaveLoc captionBox |
  	marker ifNil: [self computeForm].
  	frame := frame align: marker leftCenter with: aPoint + (2 at 0).
  	outerFrame := frame.
  	captionOrNil notNil ifTrue:
  		[captionText := (DisplayText
  				text: captionOrNil asText
+ 				textStyle: self class standardMenuStyle copy centered)
- 				textStyle: MenuStyle copy centered)
  					foregroundColor: (self userInterfaceTheme textColor ifNil: [Color black])
  					backgroundColor: (self userInterfaceTheme color ifNil: [Color white]).
  		tFrame := captionText boundingBox insetBy: -2.
  		outerFrame := frame merge: (tFrame align: tFrame bottomCenter
  					with: frame topCenter + (0 at 2))].
  	delta := outerFrame amountToTranslateWithin: Display boundingBox.
  	frame right > Display boundingBox right
  		ifTrue: [delta := 0 - frame width @ delta y].
  	frame := frame translateBy: delta.
  	captionOrNil notNil ifTrue:
  		[captionForm := captionText form.
  		captionBox := captionForm boundingBox expandBy: 4.
  		captionBox := captionBox align: captionBox bottomCenter
  								with: frame topCenter + (0 at 2).
  		captionSave := Form fromDisplay: captionBox.
  		Display border: captionBox width: 4 fillColor: (self userInterfaceTheme color ifNil: [Color white]).
  		Display border: captionBox width: 2 fillColor: (self userInterfaceTheme textColor ifNil: [Color black]).
  		captionForm displayAt: captionBox topLeft + 4].
  	marker := marker align: marker leftCenter with: aPoint + delta +  (2 at 0).
  	savedArea := Form fromDisplay: frame.
  	self menuForm displayOn: Display at: (frameSaveLoc := frame topLeft).
  	selection ~= 0 ifTrue: [Display reverse: marker].
  	Cursor normal showWhile: aBlock.
  	savedArea displayOn: Display at: frameSaveLoc.
  	captionOrNil notNil ifTrue:
  		[captionSave displayOn: Display at: captionBox topLeft]!

Item was changed:
  ----- Method: PopUpMenu>>frameHeight (in category 'accessing') -----
  frameHeight
  	"Designed to avoid the entire frame computation (includes MVC form),
  	since the menu may well end up being displayed in Morphic anyway."
  	| nItems |
  	frame ifNotNil: [^ frame height].
  	nItems := 1 + (labelString occurrencesOf: Character cr).
+ 	^ (nItems * self class standardMenuStyle lineGrid) + 4 "border width"!
- 	^ (nItems * MenuStyle lineGrid) + 4 "border width"!

Item was changed:
  ----- Method: PopUpMenu>>rescan (in category 'private') -----
  rescan
  	"Cause my form to be recomputed after a font change."
  
  	labelString == nil ifTrue: [labelString := 'NoText!!'].
+ 	self labels: labelString font: Preferences standardMenuFont lines: lineArray.
- 	self labels: labelString font: (MenuStyle fontAt: 1) lines: lineArray.
  	frame := marker := form := nil.
  
  	"PopUpMenu allSubInstancesDo: [:m | m rescan]"!


From commits at source.squeak.org  Mon Jul 13 09:49:45 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Mon, 13 Jul 2020 09:49:45 0000
Subject: [squeak-dev] The Trunk: 60Deprecated-mt.79.mcz
Message-ID: <E1juv5m-0003FJ-Il@andreas>

Marcel Taeumel uploaded a new version of 60Deprecated to project The Trunk:
http://source.squeak.org/trunk/60Deprecated-mt.79.mcz

==================== Summary ====================

Name: 60Deprecated-mt.79
Author: mt
Time: 13 July 2020, 11:49:44.479623 am
UUID: 2481d272-5ff4-1f45-a526-3cfcf05bf11e
Ancestors: 60Deprecated-mt.78

Complements ST80-mt.256

=============== Diff against 60Deprecated-mt.78 ===============

Item was changed:
  ----- Method: StandardFileMenu>>makeFileMenuFor: (in category 'menu building') -----
  makeFileMenuFor: aDirectory
  "Initialize an instance of me to operate on aDirectory"
  
  	| theMenu |
  	pattern ifNil: [pattern := {'*'}].
  	Cursor wait showWhile: 
  		[self 
  			labels: 	(self menuLabelsString: aDirectory)
+ 			font: 	Preferences standardMenuFont 
- 			font: 	(MenuStyle fontAt: 1) 
  			lines: 	(self menuLinesArray: aDirectory).
  		theMenu := self selections: (self menuSelectionsArray: aDirectory)].
  	^theMenu!


From commits at source.squeak.org  Mon Jul 13 10:13:40 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Mon, 13 Jul 2020 10:13:40 0000
Subject: [squeak-dev] The Inbox: TrueType-tobe.54.mcz
Message-ID: <E1juvSv-0003Zl-Nr@andreas>

A new version of TrueType was added to project The Inbox:
http://source.squeak.org/inbox/TrueType-tobe.54.mcz

==================== Summary ====================

Name: TrueType-tobe.54
Author: tobe
Time: 13 July 2020, 12:13:36.544882 pm
UUID: 168679d8-a9fa-4d8b-9689-2d2e06dc29f9
Ancestors: TrueType-mt.53

when encountering an invalid font while scanning a file, skip that font

=============== Diff against TrueType-mt.53 ===============

Item was changed:
  ----- Method: TTFileDescription class>>readFontsFrom: (in category 'instance creation') -----
  readFontsFrom: aFilename
  	"Reads and returns all the fonts in the given file"
  	"
  		TTFileDescription readFontsFrom: 'batang.ttc'.
  	"
  	^self openFontFile: aFilename do:[:file|
  		(self fontOffsetsInFile: file)
+ 			collect:[:offset| [self new on: aFilename offset: offset] on: Error do: [nil]]
- 			collect:[:offset| self new on: aFilename offset: offset]
  			thenSelect:[:font| font notNil]].
  	!


From eric.gade at gmail.com  Mon Jul 13 11:43:34 2020
From: eric.gade at gmail.com (Eric Gade)
Date: Mon, 13 Jul 2020 07:43:34 -0400
Subject: [squeak-dev] Squeak RISC-V ISA 32I Implementation
In-Reply-To: <0B11BD3F-57BB-4A28-8827-C4F0F80D6FAC@gmx.de>
References: <CA+CiqoUEOyf4UR54Lbhn9P+rfkXebMdWJrkT5PUmxLppY4W5Vw@mail.gmail.com>
 <6c60fc99-8702-0a25-ac86-cc9260c351ee@leastfixedpoint.com>
 <0B11BD3F-57BB-4A28-8827-C4F0F80D6FAC@gmx.de>
Message-ID: <CA+CiqoX=QW=OHyk29jC0HH13CZXhVBPw07PY+r-J3AWTfVm0ng@mail.gmail.com>

>
> On 13.07.2020, at 09:01, Tony Garnock-Jones <tonyg at leastfixedpoint.com>
> wrote:
>
> What kinds of applications or experiments do you have in mind for it?
>
>
My own ideas are not that well developed. Lately I've been particularly
inspired by the Act 1 papers and would like to take a stab at making an
"actor-based" system at the lowest levels -- ie, have the parts in hardware
behave "as if" they were actors and then build a system on top of that. I
have some early notions about how it would all come together, and I'm part
of a new research group that might take up the question at some point, but
it's early days yet and not our top priority.

I do think, however, that RISC-V could become the basis for new experiments
that rethink a lot of computing truisms. One of the reasons I discovered
Smalltalk in the first place is because I was asking myself why everything
is Unix. Obviously I don't think it has to be.

But really I was hoping that smarter / more experienced people would come
up with something, and I could just handle the grunt work!

Also, this is an excellent name :-)
>

Thanks!


On Mon, Jul 13, 2020 at 4:03 AM Tobias Pape <Das.Linux at gmx.de> wrote:
>
> Jecel should have a look at that!
>

Jecel was kind enough to help me in the Squeak slack with some issues I was
experiencing.

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200713/b88db781/attachment.html>

From robert.withers at pm.me  Mon Jul 13 13:45:52 2020
From: robert.withers at pm.me (Robert Withers)
Date: Mon, 13 Jul 2020 13:45:52 +0000
Subject: [squeak-dev] I/O in latest Squeak
Message-ID: <a885f861-46a3-16e2-2e54-a30d7bd49a12@pm.me>

Hello everyone!

Does the current cog spur 64-it VM use polling I/O? Or is some other 
mechanism used?

Kindly,
rabbit



From robert.withers at pm.me  Mon Jul 13 14:02:01 2020
From: robert.withers at pm.me (Robert Withers)
Date: Mon, 13 Jul 2020 14:02:01 +0000
Subject: [squeak-dev] I/O in latest Squeak
In-Reply-To: <a885f861-46a3-16e2-2e54-a30d7bd49a12@pm.me>
References: <a885f861-46a3-16e2-2e54-a30d7bd49a12@pm.me>
Message-ID: <fd91c177-13f2-4572-f3c8-743f5eff90ac@pm.me>

Hey y'all, there is a discussion thread on this article [1] about Smalltalk on a Pi. I commented pointing to Squeak on a Pi. Another commenter made this statement and I wish to respond.

> I used a Squeak variant to test hardware and prototype UI ideas. Ran like a champ on bare bones 68000, PPC & ARM boards.
>
> The only critique I have of using Squeak out of the box is it’s original VM used polling for I/O. I’m sure there are VMs by now that don’t have this problem. And message dispatch is a bit of a pig in terms of power usage. But again, a properly JITted Smalltalk VM should be fine. I would LOVE IT if Smalltalk or Self became popular for embedded work.

K, r

---

[1] Making Smalltalk On A Raspberry Pi - https://hackaday.com/2020/07/12/making-smalltalk-on-a-raspberry-pi/

On 7/13/20 9:45 AM, Robert Withers wrote:

> Hello everyone!
>
> Does the current cog spur 64-it VM use polling I/O? Or is some other
> mechanism used?
>
> Kindly,
> rabbit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200713/d2e0ac1e/attachment.html>

From builds at travis-ci.org  Mon Jul 13 14:29:41 2020
From: builds at travis-ci.org (Travis CI)
Date: Mon, 13 Jul 2020 14:29:41 +0000
Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1757
	(squeak-trunk - 25ebaf1)
In-Reply-To: <squeak-smalltalk/squeak-app+707640777+errored@travis-ci.org>
Message-ID: <5f0c6fd475f48_13ff356ba74741780ef@travis-tasks-6669f7974f-kxj7s.mail>

Build Update for squeak-smalltalk/squeak-app
-------------------------------------

Build: #1757
Status: Errored

Duration: 17 mins and 58 secs
Commit: 25ebaf1 (squeak-trunk)
Author: Marcel Taeumel
Message: Hi all!

The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for.

All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions.

Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs.

-- The Squeak Oversight Board

[ci skip]

View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7

View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/707640777?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200713/3ded4c52/attachment.html>

From herbertkoenig at gmx.net  Mon Jul 13 15:21:59 2020
From: herbertkoenig at gmx.net (=?UTF-8?Q?Herbert_K=c3=b6nig?=)
Date: Mon, 13 Jul 2020 17:21:59 +0200
Subject: [squeak-dev] I/O in latest Squeak
In-Reply-To: <fd91c177-13f2-4572-f3c8-743f5eff90ac@pm.me>
References: <a885f861-46a3-16e2-2e54-a30d7bd49a12@pm.me>
 <fd91c177-13f2-4572-f3c8-743f5eff90ac@pm.me>
Message-ID: <a5d1409d-c4ac-94c7-04b9-4f4029191a76@gmx.net>

Hi Robert,

I cannot directly reply but a datapoint:
On a PiZeroW an idle Squeak 5.3 uses 15+ % CPU. Also if the Window is
minimized. That does not look event driven but maybe tightvnc plays a
role here too.

Otherwise it runs fine over months at 60 % CPU 24/7 on an A+ since 2014.
Outside between -20 and +40 ^C. That's 5.1 currently. I can really
recommend using Squeak on a Pi. Unless that constant CPU load cannot be
accepted.

Cheers,

Herbert



Am 13.07.2020 um 16:02 schrieb Robert Withers via Squeak-dev:
>
> Hey y'all, there is a discussion thread on this article [1] about
> Smalltalk on a Pi. I commented pointing to Squeak on a Pi. Another
> commenter made this statement and I wish to respond.
>
>     I used a Squeak variant to test hardware and prototype UI ideas.
>     Ran like a champ on bare bones 68000, PPC & ARM boards.
>
>     The only critique I have of using Squeak out of the box is /it’s
>     original VM used polling for I/O/. I’m sure there are VMs by now
>     that don’t have this problem. And /message dispatch is a bit of a
>     pig/ in terms of power usage. But again, a properly JITted
>     Smalltalk VM should be fine. I would LOVE IT if Smalltalk or Self
>     became /popular for embedded work/.
>
> K, r
>
> ---
>
> [1] Making Smalltalk On A Raspberry Pi -
> https://hackaday.com/2020/07/12/making-smalltalk-on-a-raspberry-pi/
>
>
>
> On 7/13/20 9:45 AM, Robert Withers wrote:
>> Hello everyone!
>>
>> Does the current cog spur 64-it VM use polling I/O? Or is some other
>> mechanism used?
>>
>> Kindly,
>> rabbit
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200713/0774505a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ogpojichekdajmne.png
Type: image/png
Size: 32032 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200713/0774505a/attachment-0001.png>

From robert.withers at pm.me  Mon Jul 13 15:46:54 2020
From: robert.withers at pm.me (Robert)
Date: Mon, 13 Jul 2020 15:46:54 +0000
Subject: [squeak-dev] I/O in latest Squeak
In-Reply-To: <a5d1409d-c4ac-94c7-04b9-4f4029191a76@gmx.net>
References: <a885f861-46a3-16e2-2e54-a30d7bd49a12@pm.me>
 <fd91c177-13f2-4572-f3c8-743f5eff90ac@pm.me>
 <a5d1409d-c4ac-94c7-04b9-4f4029191a76@gmx.net>
Message-ID: <kafpOFK6Qut4fp7aoT9eonjcJm3KmF3XtZvy25nrTHCk0TLFDkFBr6wolbu3X27iBYaQHbWxhTFB_r-bSr0NbQ3a5hNpwzbU-YMUp3uDaAU=@pm.me>

Hi Herbert,

That 15+% cpu load at idle seems to indicate polling I/O, yes?

Kindly,
Robert

On Mon, Jul 13, 2020 at 11:21, Herbert König <herbertkoenig at gmx.net> wrote:

> Hi Robert,
>
> I cannot directly reply but a datapoint:
> On a PiZeroW an idle Squeak 5.3 uses 15+ % CPU. Also if the Window is minimized. That does not look event driven but maybe tightvnc plays a role here too.
>
> Otherwise it runs fine over months at 60 % CPU 24/7 on an A+ since 2014. Outside between -20 and +40 ^C. That's 5.1 currently. I can really recommend using Squeak on a Pi. Unless that constant CPU load cannot be accepted.
>
> Cheers,
>
> Herbert
>
> Am 13.07.2020 um 16:02 schrieb Robert Withers via Squeak-dev:
>
>> Hey y'all, there is a discussion thread on this article [1] about Smalltalk on a Pi. I commented pointing to Squeak on a Pi. Another commenter made this statement and I wish to respond.
>>
>>> I used a Squeak variant to test hardware and prototype UI ideas. Ran like a champ on bare bones 68000, PPC & ARM boards.
>>>
>>> The only critique I have of using Squeak out of the box is it’s original VM used polling for I/O. I’m sure there are VMs by now that don’t have this problem. And message dispatch is a bit of a pig in terms of power usage. But again, a properly JITted Smalltalk VM should be fine. I would LOVE IT if Smalltalk or Self became popular for embedded work.
>>
>> K, r
>>
>> ---
>>
>> [1] Making Smalltalk On A Raspberry Pi - https://hackaday.com/2020/07/12/making-smalltalk-on-a-raspberry-pi/
>>
>> On 7/13/20 9:45 AM, Robert Withers wrote:
>>
>>> Hello everyone!
>>>
>>> Does the current cog spur 64-it VM use polling I/O? Or is some other
>>> mechanism used?
>>>
>>> Kindly,
>>> rabbit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200713/50d7f9e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ogpojichekdajmne.png
Type: image/png
Size: 32032 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200713/50d7f9e4/attachment.png>

From herbertkoenig at gmx.net  Mon Jul 13 16:42:01 2020
From: herbertkoenig at gmx.net (=?UTF-8?Q?Herbert_K=c3=b6nig?=)
Date: Mon, 13 Jul 2020 18:42:01 +0200
Subject: [squeak-dev] I/O in latest Squeak
In-Reply-To: <kafpOFK6Qut4fp7aoT9eonjcJm3KmF3XtZvy25nrTHCk0TLFDkFBr6wolbu3X27iBYaQHbWxhTFB_r-bSr0NbQ3a5hNpwzbU-YMUp3uDaAU=@pm.me>
References: <a885f861-46a3-16e2-2e54-a30d7bd49a12@pm.me>
 <fd91c177-13f2-4572-f3c8-743f5eff90ac@pm.me>
 <a5d1409d-c4ac-94c7-04b9-4f4029191a76@gmx.net>
 <kafpOFK6Qut4fp7aoT9eonjcJm3KmF3XtZvy25nrTHCk0TLFDkFBr6wolbu3X27iBYaQHbWxhTFB_r-bSr0NbQ3a5hNpwzbU-YMUp3uDaAU=@pm.me>
Message-ID: <55661e59-81bf-4081-ddc7-b1a790b9d9fd@gmx.net>

Hi Robert,

yes that is my guess but there also is this loop that steps all morphs
(clock, browsers.. ) so I just don't know and I'm not deep into the
innards of Squeak. Just a happy user. And I don't know how VNC handles
the display updates.

So let's wait for someone who knows.

Cheers,

Herbert

Am 13.07.2020 um 17:46 schrieb Robert via Squeak-dev:
> Hi Herbert,
>
> That 15+% cpu load at idle seems to indicate polling I/O, yes?
>
> Kindly,
> Robert
>
>
> On Mon, Jul 13, 2020 at 11:21, Herbert König <herbertkoenig at gmx.net
> <mailto:herbertkoenig at gmx.net>> wrote:
>> Hi Robert,
>>
>> I cannot directly reply but a datapoint:
>> On a PiZeroW an idle Squeak 5.3 uses 15+ % CPU. Also if the Window is
>> minimized. That does not look event driven but maybe tightvnc plays a
>> role here too.
>>
>> Otherwise it runs fine over months at 60 % CPU 24/7 on an A+ since
>> 2014. Outside between -20 and +40 ^C. That's 5.1 currently. I can
>> really recommend using Squeak on a Pi. Unless that constant CPU load
>> cannot be accepted.
>>
>> Cheers,
>>
>> Herbert
>>
>>
>>
>> Am 13.07.2020 um 16:02 schrieb Robert Withers via Squeak-dev:
>>>
>>> Hey y'all, there is a discussion thread on this article [1] about
>>> Smalltalk on a Pi. I commented pointing to Squeak on a Pi. Another
>>> commenter made this statement and I wish to respond.
>>>
>>>     I used a Squeak variant to test hardware and prototype UI ideas.
>>>     Ran like a champ on bare bones 68000, PPC & ARM boards.
>>>
>>>     The only critique I have of using Squeak out of the box is /it’s
>>>     original VM used polling for I/O/. I’m sure there are VMs by now
>>>     that don’t have this problem. And /message dispatch is a bit of
>>>     a pig/ in terms of power usage. But again, a properly JITted
>>>     Smalltalk VM should be fine. I would LOVE IT if Smalltalk or
>>>     Self became /popular for embedded work/.
>>>
>>> K, r
>>>
>>> ---
>>>
>>> [1] Making Smalltalk On A Raspberry Pi -
>>> https://hackaday.com/2020/07/12/making-smalltalk-on-a-raspberry-pi/
>>>
>>>
>>>
>>> On 7/13/20 9:45 AM, Robert Withers wrote:
>>>> Hello everyone!
>>>>
>>>> Does the current cog spur 64-it VM use polling I/O? Or is some other
>>>> mechanism used?
>>>>
>>>> Kindly,
>>>> rabbit
>>>>
>>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200713/b6bc8455/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ogpojichekdajmne.png
Type: image/png
Size: 32032 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200713/b6bc8455/attachment-0001.png>

From forums.jakob at resfarm.de  Mon Jul 13 17:22:30 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Mon, 13 Jul 2020 19:22:30 +0200
Subject: [squeak-dev] Metacello bootstrap fails due to download timeouts
Message-ID: <CA+ovNC7heD+TNTU1172ZVKdPWnEcwoq77d0+f-b-cOAgrwn77A@mail.gmail.com>

Hi all,

My Travis CI builds for Squeak-Trunk 32 bits (and only these) started to
fail due to timeouts. When I looked at it in a Linux VM and it fails
to download Metacello-Base-dkh.109.mcz from SmalltalkHub. When I try
to access this version with a web browser, I get an error HTTP 500
VoMongoConnectionError
http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz

A fresh 64 bit Trunk image from squeak.org when run on Windows instead
hangs when
downloading Metacello-Core-dkh.494.mcz when I do `Metacello new`.
Eventually it erred with "Error: retry with alternate repository
failed: 'ConnectionTimedOut: Data receive timed out.'" ...after about
half an hour or so. The error comes from
ConfigurationOfMetacello>>ensureMetacello:. Though it does look as if
it first tried with a repository at
http://seaside.gemtalksystems.com/ss/metacello and not SmalltalkHub. I
can download the version in a web browser without a problem:
http://seaside.gemtalksystems.com/ss/metacello/Metacello-Core-dkh.494.mcz

Yet a local 64 bit trunk smalltalkCI build succeeded and I don't know
why yet. It also needs to go through the MetacelloStub, doesn't it?

For a start, does anyone experience the same problem or is it my bad
luck with the connections? To test, print `Metacello new` in a fresh image
which does not have the Metacello class yet.

Now SmalltalkHub is deprecated as you can read on its
front page. http://smalltalkhub.com/

Tom, Tobias, Dale, you already started to discuss changing the
bootstrap of current Metacello in Squeak when the Tonel changes were
integrated, didn't you? Is there a path where we can live without any
unmaintained repositories like the ones on SmalltalkHub?

On a different level: shouldn't the bootstrapping of the
MetacelloStub, or rather the downloading of version signal an error
with a timeout sooner when it cannot retrieve a
version, instead of waiting or retrying for a long time?

Kind regards,
Jakob

From Das.Linux at gmx.de  Mon Jul 13 17:23:21 2020
From: Das.Linux at gmx.de (Tobias Pape)
Date: Mon, 13 Jul 2020 19:23:21 +0200
Subject: [squeak-dev] Metacello bootstrap fails due to download timeouts
In-Reply-To: <CA+ovNC7heD+TNTU1172ZVKdPWnEcwoq77d0+f-b-cOAgrwn77A@mail.gmail.com>
References: <CA+ovNC7heD+TNTU1172ZVKdPWnEcwoq77d0+f-b-cOAgrwn77A@mail.gmail.com>
Message-ID: <06BCBF78-A8FB-4FBF-B767-967DDF3DF328@gmx.de>


> On 13.07.2020, at 19:22, Jakob Reschke <forums.jakob at resfarm.de> wrote:
>
> Hi all,
>
> My Travis CI builds for Squeak-Trunk 32 bits (and only these) started to
> fail due to timeouts. When I looked at it in a Linux VM and it fails
> to download Metacello-Base-dkh.109.mcz from SmalltalkHub. When I try
> to access this version with a web browser, I get an error HTTP 500
> VoMongoConnectionError
> http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz


Github was down today.
-t

>
> A fresh 64 bit Trunk image from squeak.org when run on Windows instead
> hangs when
> downloading Metacello-Core-dkh.494.mcz when I do `Metacello new`.
> Eventually it erred with "Error: retry with alternate repository
> failed: 'ConnectionTimedOut: Data receive timed out.'" ...after about
> half an hour or so. The error comes from
> ConfigurationOfMetacello>>ensureMetacello:. Though it does look as if
> it first tried with a repository at
> http://seaside.gemtalksystems.com/ss/metacello and not SmalltalkHub. I
> can download the version in a web browser without a problem:
> http://seaside.gemtalksystems.com/ss/metacello/Metacello-Core-dkh.494.mcz
>
> Yet a local 64 bit trunk smalltalkCI build succeeded and I don't know
> why yet. It also needs to go through the MetacelloStub, doesn't it?
>
> For a start, does anyone experience the same problem or is it my bad
> luck with the connections? To test, print `Metacello new` in a fresh image
> which does not have the Metacello class yet.
>
> Now SmalltalkHub is deprecated as you can read on its
> front page. http://smalltalkhub.com/
>
> Tom, Tobias, Dale, you already started to discuss changing the
> bootstrap of current Metacello in Squeak when the Tonel changes were
> integrated, didn't you? Is there a path where we can live without any
> unmaintained repositories like the ones on SmalltalkHub?
>
> On a different level: shouldn't the bootstrapping of the
> MetacelloStub, or rather the downloading of version signal an error
> with a timeout sooner when it cannot retrieve a
> version, instead of waiting or retrying for a long time?
>
> Kind regards,
> Jakob
>



From forums.jakob at resfarm.de  Mon Jul 13 17:28:01 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Mon, 13 Jul 2020 19:28:01 +0200
Subject: [squeak-dev] Metacello bootstrap fails due to download timeouts
In-Reply-To: <06BCBF78-A8FB-4FBF-B767-967DDF3DF328@gmx.de>
References: <CA+ovNC7heD+TNTU1172ZVKdPWnEcwoq77d0+f-b-cOAgrwn77A@mail.gmail.com>
 <06BCBF78-A8FB-4FBF-B767-967DDF3DF328@gmx.de>
Message-ID: <CA+ovNC5bisshctQWtXkvQiGAFmD7RJALZLZKm7RspaQKdk_N=A@mail.gmail.com>

Maybe, but it did not even get to the steps that involve GitHub as far
as I can tell. Also the 32 bit trunk builds already failed before
today.

Am Mo., 13. Juli 2020 um 19:23 Uhr schrieb Tobias Pape <Das.Linux at gmx.de>:
>
>
> > On 13.07.2020, at 19:22, Jakob Reschke <forums.jakob at resfarm.de> wrote:
> >
> > Hi all,
> >
> > My Travis CI builds for Squeak-Trunk 32 bits (and only these) started to
> > fail due to timeouts. When I looked at it in a Linux VM and it fails
> > to download Metacello-Base-dkh.109.mcz from SmalltalkHub. When I try
> > to access this version with a web browser, I get an error HTTP 500
> > VoMongoConnectionError
> > http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz
>
>
> Github was down today.
> -t
>
> >
> > A fresh 64 bit Trunk image from squeak.org when run on Windows instead
> > hangs when
> > downloading Metacello-Core-dkh.494.mcz when I do `Metacello new`.
> > Eventually it erred with "Error: retry with alternate repository
> > failed: 'ConnectionTimedOut: Data receive timed out.'" ...after about
> > half an hour or so. The error comes from
> > ConfigurationOfMetacello>>ensureMetacello:. Though it does look as if
> > it first tried with a repository at
> > http://seaside.gemtalksystems.com/ss/metacello and not SmalltalkHub. I
> > can download the version in a web browser without a problem:
> > http://seaside.gemtalksystems.com/ss/metacello/Metacello-Core-dkh.494.mcz
> >
> > Yet a local 64 bit trunk smalltalkCI build succeeded and I don't know
> > why yet. It also needs to go through the MetacelloStub, doesn't it?
> >
> > For a start, does anyone experience the same problem or is it my bad
> > luck with the connections? To test, print `Metacello new` in a fresh image
> > which does not have the Metacello class yet.
> >
> > Now SmalltalkHub is deprecated as you can read on its
> > front page. http://smalltalkhub.com/
> >
> > Tom, Tobias, Dale, you already started to discuss changing the
> > bootstrap of current Metacello in Squeak when the Tonel changes were
> > integrated, didn't you? Is there a path where we can live without any
> > unmaintained repositories like the ones on SmalltalkHub?
> >
> > On a different level: shouldn't the bootstrapping of the
> > MetacelloStub, or rather the downloading of version signal an error
> > with a timeout sooner when it cannot retrieve a
> > version, instead of waiting or retrying for a long time?
> >
> > Kind regards,
> > Jakob
> >
>
>

From Tom.Beckmann at student.hpi.uni-potsdam.de  Mon Jul 13 17:47:16 2020
From: Tom.Beckmann at student.hpi.uni-potsdam.de (Beckmann, Tom)
Date: Mon, 13 Jul 2020 17:47:16 +0000
Subject: [squeak-dev] Metacello bootstrap fails due to download timeouts
In-Reply-To: <CA+ovNC5bisshctQWtXkvQiGAFmD7RJALZLZKm7RspaQKdk_N=A@mail.gmail.com>
References: <CA+ovNC7heD+TNTU1172ZVKdPWnEcwoq77d0+f-b-cOAgrwn77A@mail.gmail.com>
 <06BCBF78-A8FB-4FBF-B767-967DDF3DF328@gmx.de>,
 <CA+ovNC5bisshctQWtXkvQiGAFmD7RJALZLZKm7RspaQKdk_N=A@mail.gmail.com>
Message-ID: <b306bde84e9949b2bafddf44658a3de5@student.hpi.uni-potsdam.de>

Hi Jakob,

smalltalkHub had also been offline for the past three days or so, see this thread on the Pharo mailing list: http://forum.world.st/smalltalkhub-down-td5119524.html

My vision for the Squeak/Metacello installation process is as follows (note that I haven't discussed this with anyone else yet, so there may be some false assumptions):
- The Metacello on Github gets a new CI task that, after a successful build for all Squeak platforms, produces a single MCZ that bundles the current Metacello from master
- MetacelloStub downloads the most recent MCZ for Metacello master and installs it
- A postInstall script configures the Github Metacello repository and registers it in the system, but does not download anything, since we already have the most up-to-date version of Metacello installed. This is just to provide the same impression as if we had gone out and downloaded it again.

This would have several advantages:
- no more bootstrapping in-image: the bootstrapping will essentially be moved to the CI to happen only once for everyone
- through this, we get a massively improved installation time (I assume): downloading an MCZ and installing it should be considerably faster than the various installation steps that we currently have to go through to get the most recent Metacello version
- only one source of truth: we no longer have different versions of Metacello on smalltalkHub/Gemsource, but only the one on Github. This would have prevented the short outage we had a couple weeks back where the bootstrap-Metacello version was not able to read some repositories as the format had changed since then


Concerning Squeak-trunk 32bit builds, I just tried to run one locally headful, and a failure occurs in primitiveSSLCreate, leading to a notification about ensuring to have internet and then a quiet image (see Installer>>ensureRecentMetacello, `self inform: ...`). I suppose we could consider changing this to an error instead, such that the CI build would fail rather than happily wait for ever after for you to click on the Okay button of the info window. Or, even better, create an Exception subclass for it that smalltalkCI can catch and handle appropriately, while by default the user sees the same info window.

Best,
Tom
________________________________________
From: Jakob Reschke <forums.jakob at resfarm.de>
Sent: Monday, July 13, 2020 7:28:01 PM
To: Tobias Pape
Cc: The general-purpose Squeak developers list; Beckmann, Tom; Henrichs, Dale (Gemtalksystems); Niephaus, Fabio
Subject: Re: Metacello bootstrap fails due to download timeouts

Maybe, but it did not even get to the steps that involve GitHub as far
as I can tell. Also the 32 bit trunk builds already failed before
today.

Am Mo., 13. Juli 2020 um 19:23 Uhr schrieb Tobias Pape <Das.Linux at gmx.de>:
>
>
> > On 13.07.2020, at 19:22, Jakob Reschke <forums.jakob at resfarm.de> wrote:
> >
> > Hi all,
> >
> > My Travis CI builds for Squeak-Trunk 32 bits (and only these) started to
> > fail due to timeouts. When I looked at it in a Linux VM and it fails
> > to download Metacello-Base-dkh.109.mcz from SmalltalkHub. When I try
> > to access this version with a web browser, I get an error HTTP 500
> > VoMongoConnectionError
> > http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz
>
>
> Github was down today.
> -t
>
> >
> > A fresh 64 bit Trunk image from squeak.org when run on Windows instead
> > hangs when
> > downloading Metacello-Core-dkh.494.mcz when I do `Metacello new`.
> > Eventually it erred with "Error: retry with alternate repository
> > failed: 'ConnectionTimedOut: Data receive timed out.'" ...after about
> > half an hour or so. The error comes from
> > ConfigurationOfMetacello>>ensureMetacello:. Though it does look as if
> > it first tried with a repository at
> > http://seaside.gemtalksystems.com/ss/metacello and not SmalltalkHub. I
> > can download the version in a web browser without a problem:
> > http://seaside.gemtalksystems.com/ss/metacello/Metacello-Core-dkh.494.mcz
> >
> > Yet a local 64 bit trunk smalltalkCI build succeeded and I don't know
> > why yet. It also needs to go through the MetacelloStub, doesn't it?
> >
> > For a start, does anyone experience the same problem or is it my bad
> > luck with the connections? To test, print `Metacello new` in a fresh image
> > which does not have the Metacello class yet.
> >
> > Now SmalltalkHub is deprecated as you can read on its
> > front page. http://smalltalkhub.com/
> >
> > Tom, Tobias, Dale, you already started to discuss changing the
> > bootstrap of current Metacello in Squeak when the Tonel changes were
> > integrated, didn't you? Is there a path where we can live without any
> > unmaintained repositories like the ones on SmalltalkHub?
> >
> > On a different level: shouldn't the bootstrapping of the
> > MetacelloStub, or rather the downloading of version signal an error
> > with a timeout sooner when it cannot retrieve a
> > version, instead of waiting or retrying for a long time?
> >
> > Kind regards,
> > Jakob
> >
>
>

From jecel at merlintec.com  Mon Jul 13 19:36:17 2020
From: jecel at merlintec.com (Jecel Assumpcao Jr)
Date: Mon, 13 Jul 2020 16:36:17 -0300 
Subject: [squeak-dev] Squeak RISC-V ISA 32I Implementation
In-Reply-To: <CA+CiqoX=QW=OHyk29jC0HH13CZXhVBPw07PY+r-J3AWTfVm0ng@mail.gmail.com>
References: <CA+CiqoUEOyf4UR54Lbhn9P+rfkXebMdWJrkT5PUmxLppY4W5Vw@mail.gmail.com>
 <6c60fc99-8702-0a25-ac86-cc9260c351ee@leastfixedpoint.com>
 <0B11BD3F-57BB-4A28-8827-C4F0F80D6FAC@gmx.de>
 <CA+CiqoX=QW=OHyk29jC0HH13CZXhVBPw07PY+r-J3AWTfVm0ng@mail.gmail.com>
Message-ID: <20200713194342.55BCC1241579@proxy.email-ssl.com.br>

Eric,

congratulations on your project!

An interesting direction to take this would be to make it compatible
with the processor simulator interface in Cog. In the case of ARM and
x86 this interface calls external programs but in the case of MIPS it is
a simulator written in Squeak. You can find this in the VMMaker package.
Something like this would be the first step in a port of OpenSmalltalk
VM to RISC-V.

-- Jecel

From asqueaker at gmail.com  Mon Jul 13 21:34:59 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Mon, 13 Jul 2020 16:34:59 -0500
Subject: [squeak-dev] look what appeared in my news feed!
In-Reply-To: <78616baa-99cd-1d03-b80f-e4e1745992ff@pm.me>
References: <78616baa-99cd-1d03-b80f-e4e1745992ff@pm.me>
Message-ID: <CANzdToFPFcNrrMzo_6BPdiaiT3KAxghWPK5VB=1FMFiS7mh5xQ@mail.gmail.com>

The original LinkedIn blog they quoted mentioned Squeak.

Very cool, thanks for sharing.  Did anyone get it going on a RPi?  I
tried on a RPi1 but failed the first time, I might try again.


On Mon, Jul 13, 2020 at 2:17 AM Robert Withers via Squeak-dev
<squeak-dev at lists.squeakfoundation.org> wrote:
>
> Hey, what's up? Well, here was a news article that appeared in my google
> news feed.
>
> https://hackaday.com/2020/07/12/making-smalltalk-on-a-raspberry-pi/
>
> Sadly, they do not mention Squeak, just GNU Smalltalk.
>
> K, r
>
>
>

From forums.jakob at resfarm.de  Mon Jul 13 21:37:51 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Mon, 13 Jul 2020 23:37:51 +0200
Subject: [squeak-dev] Metacello bootstrap fails due to download timeouts
In-Reply-To: <b306bde84e9949b2bafddf44658a3de5@student.hpi.uni-potsdam.de>
References: <CA+ovNC7heD+TNTU1172ZVKdPWnEcwoq77d0+f-b-cOAgrwn77A@mail.gmail.com>
 <06BCBF78-A8FB-4FBF-B767-967DDF3DF328@gmx.de>
 <CA+ovNC5bisshctQWtXkvQiGAFmD7RJALZLZKm7RspaQKdk_N=A@mail.gmail.com>
 <b306bde84e9949b2bafddf44658a3de5@student.hpi.uni-potsdam.de>
Message-ID: <CA+ovNC4ixTYL7=hB1KvN=wEYyB9A6KTEfr9CUQYyc_aFbz6eNw@mail.gmail.com>

Beckmann, Tom <Tom.Beckmann at student.hpi.uni-potsdam.de> schrieb am Mo., 13.
Juli 2020, 19:47:

>
> Concerning Squeak-trunk 32bit builds, I just tried to run one locally
> headful, and a failure occurs in primitiveSSLCreate, leading to a
> notification about ensuring to have internet and then a quiet image (see
> Installer>>ensureRecentMetacello, `self inform: ...`). I suppose we could
> consider changing this to an error instead, such that the CI build would
> fail rather than happily wait for ever after for you to click on the Okay
> button of the info window. Or, even better, create an Exception subclass
> for it that smalltalkCI can catch and handle appropriately, while by
> default the user sees the same info window.
>
>
Since that is not what I observed, we seem to have multiple such points of
non-failures...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200713/3a41482b/attachment.html>

From Tom.Beckmann at student.hpi.uni-potsdam.de  Tue Jul 14 06:28:27 2020
From: Tom.Beckmann at student.hpi.uni-potsdam.de (Beckmann, Tom)
Date: Tue, 14 Jul 2020 06:28:27 +0000
Subject: [squeak-dev] Metacello bootstrap fails due to download timeouts
In-Reply-To: <CA+ovNC4ixTYL7=hB1KvN=wEYyB9A6KTEfr9CUQYyc_aFbz6eNw@mail.gmail.com>
References: <CA+ovNC7heD+TNTU1172ZVKdPWnEcwoq77d0+f-b-cOAgrwn77A@mail.gmail.com>
 <06BCBF78-A8FB-4FBF-B767-967DDF3DF328@gmx.de>
 <CA+ovNC5bisshctQWtXkvQiGAFmD7RJALZLZKm7RspaQKdk_N=A@mail.gmail.com>
 <b306bde84e9949b2bafddf44658a3de5@student.hpi.uni-potsdam.de>,
 <CA+ovNC4ixTYL7=hB1KvN=wEYyB9A6KTEfr9CUQYyc_aFbz6eNw@mail.gmail.com>
Message-ID: <b8b72d1967ee40a783ac7103b27f6d68@student.hpi.uni-potsdam.de>

Ah sorry, I got confused with the various 32- vs 64-bit mentions.
Also, the SqueakSSL issue turned out to be just me forgetting that I did not have a well-configured 32bit environment.

I just tried running the Squot tests locally with squeak32-trunk on smalltalkCI, which turned out all green. For a couple hours now, smalltalkHub is also online again, so maybe the issues you were observing were all related to this part of the infrastructure failing and errors bubbling up to unexpected places? Or are the builds still failing on Travis?
________________________________________
From: Jakob Reschke <forums.jakob at resfarm.de>
Sent: Monday, July 13, 2020 11:37:51 PM
To: Beckmann, Tom
Cc: Tobias Pape; The general-purpose Squeak developers list; Henrichs, Dale (Gemtalksystems); Niephaus, Fabio
Subject: Re: Metacello bootstrap fails due to download timeouts

Beckmann, Tom <Tom.Beckmann at student.hpi.uni-potsdam.de<mailto:Tom.Beckmann at student.hpi.uni-potsdam.de>> schrieb am Mo., 13. Juli 2020, 19:47:

Concerning Squeak-trunk 32bit builds, I just tried to run one locally headful, and a failure occurs in primitiveSSLCreate, leading to a notification about ensuring to have internet and then a quiet image (see Installer>>ensureRecentMetacello, `self inform: ...`). I suppose we could consider changing this to an error instead, such that the CI build would fail rather than happily wait for ever after for you to click on the Okay button of the info window. Or, even better, create an Exception subclass for it that smalltalkCI can catch and handle appropriately, while by default the user sees the same info window.


Since that is not what I observed, we seem to have multiple such points of non-failures...

From marcel.taeumel at hpi.de  Tue Jul 14 08:40:41 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Tue, 14 Jul 2020 10:40:41 +0200
Subject: [squeak-dev] We need to talk about graphics
In-Reply-To: <97F2A1A6-06AF-4DB2-A79D-816DCFFAAFF9@heaveneverywhere.com>
References: <90C7742C-9E88-4DB3-81A5-1CA18B83FB2F@rowledge.org>
 <5593C678-5CD0-43D7-A72A-84B4C3D92A7B@heaveneverywhere.com>
 <97F2A1A6-06AF-4DB2-A79D-816DCFFAAFF9@heaveneverywhere.com>
Message-ID: <Mailbird-371bf906-9594-470f-8a0d-fde1a533b329@hpi.de>

Hi Stephen.

Separation of model, view, and maybe controller-like objects is a choice you can still make in your application designed for and written in Morphic.

Try exploring and working with the direct-manipulation concepts Morphic has to offer. Those concepts can speed up the feedback cycle, which can then lead to a better architectural design in your application.

Many of your thoughts on a "good OO framework" omits the fact that software rather grows -- refactoring being a vital part in its lifecycle.

Happy programming! =)

Best,
Marcel
Am 11.07.2020 20:02:55 schrieb Stephen Pope <stephen at heaveneverywhere.com>:

To put it bluntly: I gave porting old-school MVC to Cuis.


[flame on] Morphic is miserable and really needs to be replaced by MVC, though (IMHO).

Why?

1. There’s a reason views and controllers were initially separated; that reason is reusability and better factoring.

2. The composite design pattern is a good thing (https://en.wikipedia.org/wiki/Composite_pattern [https://en.wikipedia.org/wiki/Composite_pattern]) and should be applied to everything where one builds trees, such as view hierarchies. The root view object should not have subviews, the view-composite should. (I know that old-school MVC didn’t do it that way, but new implementations certainly should).

3. In a good OO framework, the more abstract classes generally have the minimum necessary state (or none at all). Class Morph has 7 instance variables.

4. The goal of OO design is to reuse specifications across multiple implementations, so why does class Morph rename the usual geometry methods of bounds, extent, width, height, etc. as (e.g.,) morphBounds?

I could go on… [flame off] 

It would be really nice to have a simple MVC (and display-list graphics) framework that could be placed on top of several graphics back-ends including BitBLT, OpenGL and HTML5.

stp


--

                    Stephen Travis Pope   Santa Barbara, California, USA    
          http://HeavenEverywhere.com [http://HeavenEverywhere.com]        http://FASTLabInc.com [http://FASTLabInc.com]
                       https://vimeo.com/user19434036/videos [https://vimeo.com/user19434036/videos]      http://heaveneverywhere.com/Reflections [http://heaveneverywhere.com/Reflections]

--



On Jul 9, 2020, at 11:12 PM, stephen at heaveneverywhere.com [mailto:stephen at heaveneverywhere.com] wrote:


…on a related topic, I’ve started porting old-school MVC* to Cuis with the intention of replacing Morphic with a generic framework that can be back-ended by BitBLT, OpenGL or HTML5.

Anybody want to help?

Stephen

* = starting with traditional MVC classes and system windows, and following that with some version of the “Wrapper” framework as still used in VisualWorks.


--

                    Stephen Travis Pope   Santa Barbara, California, USA    
 <pastedGraphic.tiff>         http://HeavenEverywhere.com [http://heaveneverywhere.com/]        http://FASTLabInc.com [http://fastlabinc.com/]
                       https://vimeo.com/user19434036/videos [https://vimeo.com/user19434036/videos]      http://heaveneverywhere.com/Reflections [http://heaveneverywhere.com/Reflections]

--



On Jun 28, 2020, at 5:53 PM, tim Rowledge <tim at rowledge.org [mailto:tim at rowledge.org]> wrote:

Seriously. We've been sitting around twiddling thumbs about better graphics for decades now.

We had Balloon2D & 3D.
We had 'Pooh graphics' to do vector forms.
We have some excellent stuff being done by the Cuis crew.
We have some amazing ideas from Nile/Gezira.
We have a number of potential 3rd party graphics libraries we might adopt.
We have an advanced JIT that could be used to make on-demand graphics routines either on their own or working with pretty much any of the above.
We probably have other options I've not even heard of.

Maybe we should actually do something? Can we at least talk about it?

tim
--
tim Rowledge; tim at rowledge.org [mailto:tim at rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim]
Strange OpCodes: SVE: Skip on Vernal Equinox





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200714/81b5397c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 2442 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200714/81b5397c/attachment-0001.tiff>

From commits at source.squeak.org  Tue Jul 14 13:10:12 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Tue, 14 Jul 2020 13:10:12 0000
Subject: [squeak-dev] The Trunk: ToolBuilder-MVC-mt.61.mcz
Message-ID: <E1jvKhJ-0000bT-O6@andreas>

Marcel Taeumel uploaded a new version of ToolBuilder-MVC to project The Trunk:
http://source.squeak.org/trunk/ToolBuilder-MVC-mt.61.mcz

==================== Summary ====================

Name: ToolBuilder-MVC-mt.61
Author: mt
Time: 14 July 2020, 3:10:12.065552 pm
UUID: 39b7e9cc-2da0-48b8-abc4-da349a22f903
Ancestors: ToolBuilder-MVC-TheresaHMartenK.60

Fixes layout bug in MVC windows.

=============== Diff against ToolBuilder-MVC-TheresaHMartenK.60 ===============

Item was added:
+ ----- Method: MVCToolBuilder>>buildAll:in: (in category 'building') -----
+ buildAll: aList in: newParent
+ 	"Overridden to propagate reduced topSize to widgets."
+ 	
+ 	| priorTopSize |
+ 	priorTopSize := topSize.
+ 	topSize := newParent window.
+ 	super buildAll: aList in: newParent.
+ 	topSize := priorTopSize.!

Item was removed:
- ----- Method: MVCToolBuilder>>positionSubviewsWithin: (in category 'private') -----
- positionSubviewsWithin: widget
- 	"Translate subviews to position the viewport of each subView relative to
- 	the widget window origin. If subviews are repositioned, as in a row of button
- 	views arranged within a view, then the transformations will later be rescaled
- 	to fit the subviews within the widget window."
- 
- 	widget subViews ifNotNil: [:subViews |
- 		subViews isEmpty ifFalse: [ | translation |
- 			translation := widget window origin - subViews first window origin.
- 			subViews do: [:v | 
- 				v setTransformation: (v transformation translateBy: translation)]]].
- !

Item was changed:
  ----- Method: MVCToolBuilder>>setFrame:in: (in category 'private') -----
  setFrame: fractionsRectangleOrLayoutFrame in: widget
+ 
  	| win |
+ 	fractionsRectangleOrLayoutFrame ifNil: [
+ 		"Translate subviews to position the viewport of each subView relative to
+ 	the widget window origin. If subviews are repositioned, as in a row of button
+ 	views arranged within a view, then the transformations will later be rescaled
+ 	to fit the subviews within the widget window."
+ 		self flag: #nonProportionalLayout. "See #setLayout:in:."
+ 		widget setTransformation: (widget transformation translateBy: parent window origin - widget window origin).
+ 		^ self].
+ 	
- 	fractionsRectangleOrLayoutFrame ifNil: [^nil].
  	win := fractionsRectangleOrLayoutFrame isRectangle
  		ifTrue: [self asWindow: fractionsRectangleOrLayoutFrame]
  		ifFalse: [fractionsRectangleOrLayoutFrame layout: nil in: topSize]. "assume LayoutFrame"
  	widget window: win.!

Item was changed:
  ----- Method: MVCToolBuilder>>setLayout:in: (in category 'private') -----
  setLayout: layout in: widget
  	"Arrange subview horizontally or vertically according to layout directive.
  	If the subview dimensions were specified with layout frames rather than explicit
  	rectangle sizes, then their window horizontal or vertical dimensions will be resized
  	as needed to fit within the widget extent."
  
- 	self positionSubviewsWithin: widget.
  	layout == #proportional ifTrue:[^self].
  	layout == #horizontal ifTrue:[
  		| prev subViewWidth widgetWidth xScale |
  		subViewWidth := (widget subViews collect: [:e | e window extent x]) sum.
  		widgetWidth := widget window extent x.
  		xScale := widgetWidth / subViewWidth. "to adjust corner of prev prior to align:"
  		prev := nil.
  		widget subViews do:[:next| | newWindowWidth newCorner |
  			prev ifNotNil:[ "resize prev window prior to aligning next"
  				xScale < 1 ifTrue: [ "proportional placement spec requires resizing"
  					newWindowWidth := (prev window extent x * xScale) truncated.
  					newCorner := (prev window origin x + newWindowWidth)@(prev window corner y).
  					prev setWindow: (prev window origin corner: newCorner)].
  				next align: next viewport topLeft with: prev viewport topRight.
  			].
  			prev := next.
  		].
  		^self].
  	layout == #vertical ifTrue:[
  		| prev subViewHeight widgetHeight yScale |
  		subViewHeight := (widget subViews collect: [:e | e window extent y]) sum.
  		widgetHeight := widget window extent y.
  		yScale := widgetHeight / subViewHeight. "to adjust corner of prev prior to align:"
  		prev := nil.
  		widget subViews do:[:next| | newWindowHeight newCorner |
  			prev ifNotNil:[ "resize prev window prior to aligning next"
  				yScale < 1 ifTrue: [ "proportional placement spec requires resizing"
  					newWindowHeight := (prev window extent y * yScale) truncated.
  					newCorner := (prev window corner x)@(prev window origin y + newWindowHeight).
  					prev setWindow: (prev window origin corner: newCorner)].
  				next align: next viewport topLeft with: prev viewport bottomLeft.
  			].
  			prev := next.
  		].
  		^self].
  	^self error: 'Unknown layout: ', layout.!


From marcel.taeumel at hpi.de  Tue Jul 14 13:10:45 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Tue, 14 Jul 2020 15:10:45 +0200
Subject: [squeak-dev] Disappearing MVC code panes
In-Reply-To: <9713d621-506d-024e-8545-09819159988d@zogotounga.net>
References: <9713d621-506d-024e-8545-09819159988d@zogotounga.net>
Message-ID: <Mailbird-c56aae5d-713f-41ef-a556-19a60fa50a13@hpi.de>

Hi Stef,

try ToolBuilder-MVC-mt.61. :-)

Best,
Marcel
Am 12.07.2020 22:56:10 schrieb Stéphane Rollandin <lecteur at zogotounga.net>:
Hello all,

Playing a bit with MVC I found the following bug:

If preference "optional buttons" in the "browsing" category is turned
off, the code panes in all MVC browsers are not displayed.

Stef

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200714/a1078025/attachment.html>

From builds at travis-ci.org  Tue Jul 14 14:34:44 2020
From: builds at travis-ci.org (Travis CI)
Date: Tue, 14 Jul 2020 14:34:44 +0000
Subject: [squeak-dev] [CRON] Passed: squeak-smalltalk/squeak-app#1759
	(squeak-trunk - 25ebaf1)
In-Reply-To: <squeak-smalltalk/squeak-app+707994097+passed@travis-ci.org>
Message-ID: <5f0dc283efc5e_13ffa5ac4074015017@travis-tasks-79c476dcc5-6sbw6.mail>

Build Update for squeak-smalltalk/squeak-app
-------------------------------------

Build: #1759
Status: Passed

Duration: 22 mins and 34 secs
Commit: 25ebaf1 (squeak-trunk)
Author: Marcel Taeumel
Message: Hi all!

The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for.

All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions.

Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs.

-- The Squeak Oversight Board

[ci skip]

View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7

View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/707994097?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200714/baee562f/attachment.html>

From commits at source.squeak.org  Wed Jul 15 07:04:35 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 15 Jul 2020 07:04:35 0000
Subject: [squeak-dev] The Trunk: PreferenceBrowser-mt.105.mcz
Message-ID: <E1jvbT4-00074Q-9z@andreas>

Marcel Taeumel uploaded a new version of PreferenceBrowser to project The Trunk:
http://source.squeak.org/trunk/PreferenceBrowser-mt.105.mcz

==================== Summary ====================

Name: PreferenceBrowser-mt.105
Author: mt
Time: 15 July 2020, 9:04:35.150352 am
UUID: 6f3e4cc4-0188-4748-abd0-b8f6e3bec8f6
Ancestors: PreferenceBrowser-mt.104

Minor tweaks of visuals in preference browser to match other tools' appearance.

=============== Diff against PreferenceBrowser-mt.104 ===============

Item was changed:
  ----- Method: PreferenceBrowserMorph>>basicButton (in category 'submorphs - buttons') -----
  basicButton
  
  	^ PluggableButtonMorph new
  		model: self model;
  		offColor: self paneColor;
  		hResizing: #spaceFill;
+ 		vResizing: #spaceFill;
  		layoutInset: 4;
  		yourself!

Item was changed:
  ----- Method: PreferenceBrowserMorph>>buttonRowLayoutFrame (in category 'submorphs - buttons') -----
  buttonRowLayoutFrame 
+ 	^LayoutFrame fractions: (0 at 0 corner: 1 at 0) offsets: (0 at 0 corner: 0@ (Preferences standardButtonFont height * 2))!
- 	^LayoutFrame fractions: (0 at 0 corner: 1 at 0) offsets: (0 at 0 corner: 0@ (TextStyle defaultFont height * 2.5))!

Item was changed:
  ----- Method: PreferenceBrowserMorph>>mainPanel (in category 'submorphs - main panel') -----
  mainPanel
  	^mainPanel ifNil: 
  		[mainPanel := BorderedMorph new
  			color: Color transparent;
  			borderWidth: 0;
  			hResizing: #spaceFill;
  			vResizing: #spaceFill;
  			cellGap: 5;
  			changeProportionalLayout;
  			on: #mouseEnter send: #paneTransition: to: self;
  			addMorphBack: self newCategoryList;
  			addMorphBack: self preferenceList;
+ 			layoutFrame: (LayoutFrame fractions: (0 at 0 corner: 1 at 1) offsets: (0@ self searchTextFieldLayoutFrame bottomOffset corner: 0 at 0));
- 			layoutFrame: (LayoutFrame fractions: (0 at 0 corner: 1 at 1) offsets: (0@ 30 corner: 0 at 0));
  			addPaneSplitters;
  			yourself].!

Item was changed:
  ----- Method: PreferenceBrowserMorph>>newButtonRow (in category 'submorphs - buttons') -----
  newButtonRow
  	^BorderedMorph new
  		color: Color transparent;
  		borderWidth: 0;
  		cellGap: 2;
- 		layoutInset: 2;
  		layoutPolicy: TableLayout new;
  		listDirection: #leftToRight;
  		listCentering: #topLeft;
  		cellPositioning: #topLeft;
  		on: #mouseEnter send: #paneTransition: to: self;
  		on: #mouseLeave send: #paneTransition: to: self;
  		addMorphBack: self defaultButton;
  		addMorphBack: self newSeparator;
  		addMorphBack: self saveButton;
  		addMorphBack: self loadButton;
  		addMorphBack: self newSeparator;
  		addMorphBack: self saveToDiskButton;
  		addMorphBack: self loadFromDiskButton;
  		addMorphBack: self newSeparator;
  		addMorphBack: self themeButton;
  		addMorphBack: self newTransparentFiller;
  		addMorphBack: self helpButton;
  		yourself.!

Item was removed:
- ----- Method: PreferenceBrowserMorph>>newSearchButton (in category 'submorphs - search panel') -----
- newSearchButton
- 	^self basicButton
- 			label: 'search' translated; 
- 			actionSelector: #searchSelected;
- 			setBalloonText: 
- 				'Type what you want to search for here, then hit ',
- 				'the "Search" button, or else hit RETURN or ENTER' translated.!

Item was removed:
- ----- Method: PreferenceBrowserMorph>>newSearchPanel (in category 'submorphs - search panel') -----
- newSearchPanel
- 	| bottom |
- 	bottom := Morph new
- 		color: Color transparent;
- 		cellGap: 5;
- 		layoutPolicy: TableLayout new;
- 		listDirection: #leftToRight;
- 		listCentering: #topLeft;
- 		cellPositioning: #topLeft;
- 		hResizing: #spaceFill;
- 		vResizing: #shrinkWrap;
- 		addMorphBack: self newSearchTextField
- 		yourself.
- 	^Morph new
- 		color: Color transparent;
- 		layoutPolicy: TableLayout new;
- 		listDirection: #topToBottom;
- 		listCentering: #topLeft;
- 		cellPositioning: #topLeft;
- 		hResizing: #spaceFill;
- 		vResizing: #shrinkWrap;
- 		cellGap: 3;
- 		addMorphBack: (StringMorph contents: 'Search preferences for: ');
- 		addMorphBack: bottom;
- 		yourself.!

Item was changed:
  ----- Method: PreferenceBrowserMorph>>newSearchTextField (in category 'submorphs - search panel') -----
  newSearchTextField
  	
  	| ptm  |
  	ptm := PluggableTextMorphPlus
  		on: self model
  		text: #searchPatternNeverTriggered
  		accept: #searchPattern:.
  	
  	ptm
  		minimumHeight: 0;
  		balloonText: 'Search preferences ...';
  		hideScrollBarsIndefinitely;
+ 		layoutFrame: self searchTextFieldLayoutFrame;
- 		layoutFrame: (LayoutFrame fractions: (0 at 0 corner: 1 at 0) offsets: (0 at 0 corner: 0@ (TextStyle default lineGrid * 2)));
  		borderInset;
  		vResizing: #spaceFill;
  		hResizing: #spaceFill;
  		acceptOnCR: true;
  		onKeyStrokeSend: #value to: [ ptm hasUnacceptedEdits ifTrue: [ ptm accept ] ].
  	^ptm.!

Item was added:
+ ----- Method: PreferenceBrowserMorph>>searchTextFieldLayoutFrame (in category 'submorphs - search panel') -----
+ searchTextFieldLayoutFrame
+ 	
+ 	^ LayoutFrame
+ 		fractions: (0 at 0 corner: 1 at 0)
+ 		offsets: (0 at 0 corner: 0@ (Preferences standardDefaultTextFont height * 3/2) rounded)!


From commits at source.squeak.org  Wed Jul 15 07:10:22 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 15 Jul 2020 07:10:22 0000
Subject: [squeak-dev] The Trunk: Morphic-mt.1669.mcz
Message-ID: <E1jvbYi-00079d-9e@andreas>

Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1669.mcz

==================== Summary ====================

Name: Morphic-mt.1669
Author: mt
Time: 15 July 2020, 9:10:16.659352 am
UUID: 13e754ac-84e8-403c-8bf8-be99b1586fbb
Ancestors: Morphic-cbc.1668

Fixes icon scaling in tree widgets.

=============== Diff against Morphic-cbc.1668 ===============

Item was changed:
  ----- Method: IndentingListItemMorph>>initWithContents:prior:forList:indentLevel: (in category 'initialization') -----
  initWithContents: anObject prior: priorMorph forList: hostList indentLevel: newLevel
  
  	container := hostList.
  	
  	complexContents := anObject.
  	anObject addDependent: self.
  	
  	self initWithContents: self getLabel font: Preferences standardListFont emphasis: nil.
  	indentLevel := 0.
  	isExpanded := false.
   	nextSibling := firstChild := nil.
  	priorMorph ifNotNil: [
  		priorMorph nextSibling: self.
  	].
  	indentLevel := newLevel.
+ 	icon := self getIcon scaleIconToDisplay.
- 	icon := self getIcon.
  	self extent: self minWidth @ self minHeight!

Item was changed:
  ----- Method: IndentingListItemMorph>>refresh (in category 'initialization') -----
  refresh
  
  	self contents: self getLabel.
+ 	icon := self getIcon scaleIconToDisplay.
- 	icon := self getIcon.
  	
  	(self valueOfProperty: #wasRefreshed ifAbsent: [false]) ifFalse: [
  		self setProperty: #wasRefreshed toValue: true].!


From commits at source.squeak.org  Wed Jul 15 09:22:36 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 15 Jul 2020 09:22:36 0000
Subject: [squeak-dev] The Trunk: Kernel-mt.1333.mcz
Message-ID: <E1jvdce-0000Wb-U5@andreas>

Marcel Taeumel uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-mt.1333.mcz

==================== Summary ====================

Name: Kernel-mt.1333
Author: mt
Time: 15 July 2020, 11:22:34.685718 am
UUID: 4e50519a-d1e3-4a74-85cc-3c02660d650f
Ancestors: Kernel-nice.1332

Clean up code for non-event-based input processing, primarily used in ST80.

Moves some methods to ST80 package. Needs more work to remove all sends from Morphic such as #shiftPressed etc.

Also rely on in-image interrupt-key handling only. Recent VMs do not fire the old-style interrupt semaphore anymore. See #userInterruptWatcher.

=============== Diff against Kernel-nice.1332 ===============

Item was changed:
  Object subclass: #EventSensor
  	instanceVariableNames: 'mouseButtons mousePosition mouseWheelDelta keyboardBuffer interruptKey interruptSemaphore eventQueue inputSemaphore lastEventPoll hasInputSemaphore'
+ 	classVariableNames: 'ButtonDecodeTable EventPollPeriod EventTicklerProcess InterruptWatcherProcess KeyDecodeTable'
- 	classVariableNames: 'ButtonDecodeTable EventPollPeriod EventTicklerProcess InterruptSemaphore InterruptWatcherProcess KeyDecodeTable'
  	poolDictionaries: 'EventSensorConstants'
  	category: 'Kernel-Processes'!
  
  !EventSensor commentStamp: 'mt 12/13/2019 14:38' prior: 0!
  An EventSensor is an interface to the user input devices.
  There is at least one instance of EventSensor named Sensor in the system.
  
  EventSensor is a replacement for the earlier InputSensor implementation based on a set of (optional) event primitives. An EventSensor updates its state when events are received so that all state based users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor mouseButtons) will work exactly as before, by moving the current VM mechanisms into EventSensor itself. An optional input semaphore is part of the new design.
  
  For platforms that support true asynchronous event notification, the semaphore will be signaled to indicate pending events.
  On platforms that do not support asynchronous notifications about events, the UI will have to poll EventSensor periodically to read events from the VM.
  
  Instance variables:
  	mouseButtons <Integer>	- mouse button state as replacement for primMouseButtons
  	mousePosition <Point>	- mouse position as replacement for primMousePt
  	keyboardBuffer <SharedQueue>	- keyboard input buffer
  	interruptKey <Integer>			- currently defined interrupt key
  	interruptSemaphore <Semaphore>	- the semaphore signaled when the interruptKey is detected
  	eventQueue <SharedQueue>	- an optional event queue for event driven applications
  	inputSemaphore <Semaphore>- the semaphore signaled by the VM if asynchronous event notification is supported
  	lastEventPoll <Integer>		- the last millisecondClockValue at which we called fetchMoreEvents
  	hasInputSemaphore <Boolean>	- true if my inputSemaphore has actually been signaled at least once.
  
  Class variables:
  	ButtonDecodeTable <ByteArray> - maps mouse buttons as reported by the VM to ones reported in the events.
  	KeyDecodeTable <Dictionary<SmallInteger->SmallInteger>> - maps some keys and their modifiers to other keys (used for instance to map Ctrl-X to Alt-X)
  	InterruptSemaphore <Semaphore> - signalled by the the VM and/or the event loop upon receiving an interrupt keystroke.
  	InterruptWatcherProcess <Process> - waits on the InterruptSemaphore and then responds as appropriate.
  	EventPollPeriod <Integer>	- the number of milliseconds to wait between polling for more events in the userInterruptHandler.
  	EventTicklerProcess <Process>	- the process that makes sure that events are polled for often enough (at least every EventPollPeriod milliseconds).
  
  Event format:
  The current event format is very simple. Each event is recorded into an 8 element array. All events must provide some SmallInteger ID (the first field in the event buffer) and a time stamp (the second field in the event buffer), so that the difference between the time stamp of an event and the current time can be reported.
  
  Currently, the following events are defined:
  
  Null event
  =============
  The Null event is returned when the ST side asks for more events but no more events are available.
  Structure:
  [1]		- event type 0
  [2-8]	- unused
  
  Mouse event structure
  ==========================
  Mouse events are generated when mouse input is detected.
  [1]	- event type 1
  [2]	- time stamp
  [3]	- mouse x position
  [4]	- mouse y position
  [5]	- button state; bitfield with the following entries:
  		1	-	2r001	yellow (e.g., right) button
  		2	-	2r010	blue (e.g., middle) button
  		4	-	2r100	red (e.g., left) button
  		[all other bits are currently undefined]
  [6]	- modifier keys; bitfield with the following entries:
  		1	-	shift key
  		2	-	ctrl key
  		4	-	(Mac specific) option key
  		8	-	Cmd/Alt key
  		[all other bits are currently undefined]
  [7]	- reserved.
  [8]	- host window id.
  
  Keyboard events
  ====================
  Keyboard events are generated when keyboard input is detected.
  [1]	- event type 2
  [2]	- time stamp
  [3]	- character code (Ascii)
  		For now the character code is in Mac Roman encoding. See #macToSqueak.
  		For key press/release (see [4]), character codes are normalized.
  [4]	- press state; integer with the following meaning
  		0	-	character (aka. key stroke or key still pressed)
  		1	-	key press (aka. key down)
  		2	- 	key release (aka. key up)
  [5]	- modifier keys (same as in mouse events)
  		For key press/release (see [4]), modifier keys are still accessible.
  [6]	- character code (Unicode UTF32)
  		Manual decoding via KeyboardInputInterpreter possible.
  		For key press/release (see [4]), character codes are normalized.
  [7]	- reserved.
  [8]	- host window id.
  	
  Mouse-wheel event structure
  ==========================
  Mouse-wheel events are generated when mouse-wheel input is detected.
  [1] - event type 7
  [2] - time stamp
  [3] - horizontal scroll delta
  [4] - vertical scroll delta
  [5] - button state (same as in mouse events)
  [6] - modifier keys (same as in mouse events)
  [7] - reserved.
  [8] - host window id.
  !

Item was removed:
- ----- Method: EventSensor>>characterForKeycode: (in category 'keyboard') -----
- characterForKeycode: keycode
- 	"Map the given keycode to a Smalltalk character object. Encoding:
- 		A keycode is 12 bits:   <4 modifer bits><8 bit ISO character>
- 		Modifier bits are:       <command><option><control><shift>"
- 
- 	"NOTE: the command and option keys are specific to the Macintosh and may not have equivalents on other platforms."
- 
- 	keycode = nil ifTrue: [ ^nil ].
- 	keycode class = Character ifTrue: [ ^keycode ].  "to smooth the transition!!"
- 	^ Character value: (keycode bitAnd: 16rFF)!

Item was changed:
+ ----- Method: EventSensor>>cursorPoint (in category 'mouse') -----
- ----- Method: EventSensor>>cursorPoint (in category 'cursor') -----
  cursorPoint
  	"Answer a Point indicating the cursor location."
  
  	^ self peekPosition!

Item was changed:
+ ----- Method: EventSensor>>cursorPoint: (in category 'mouse') -----
- ----- Method: EventSensor>>cursorPoint: (in category 'cursor') -----
  cursorPoint: aPoint 
  	"Set aPoint to be the current cursor location."
  
  	^self primCursorLocPut: aPoint!

Item was removed:
- ----- Method: EventSensor>>flushAllButDandDEvents (in category 'accessing') -----
- flushAllButDandDEvents
- 	| newQueue oldQueue  |
- 	
- 	newQueue := SharedQueue new.
- 	self eventQueue ifNil: [ 
- 		self eventQueue: newQueue.
- 		^ self].
- 	oldQueue := self eventQueue.
- 	[oldQueue size > 0] whileTrue: 
- 		[| item type | 
- 		item := oldQueue next.
- 		type := item at: 1.
- 		type = EventTypeDragDropFiles ifTrue: [ newQueue nextPut: item]].
- 	self eventQueue: newQueue.!

Item was changed:
  ----- Method: EventSensor>>flushEvents (in category 'accessing') -----
  flushEvents
+ 
+ 	keyboardBuffer flush.
+ 	mouseWheelDelta := 0 at 0.
+ 
+ 	self eventQueue ifNotNil: [:queue | queue flush].!
- 	self eventQueue ifNotNil:[:queue | queue flush].!

Item was removed:
- ----- Method: EventSensor>>flushKeyboard (in category 'keyboard') -----
- flushKeyboard
- 	"Remove all characters from the keyboard buffer."
- 
- 	[self keyboardPressed]
- 		whileTrue: [self keyboard]!

Item was removed:
- ----- Method: EventSensor>>flushNonKbdEvents (in category 'private') -----
- flushNonKbdEvents
- 	"We do NOT use 'isKeybdEvent: ' here,
- 	 as that would have us flush key press-release events,
- 	 which is not appropriate when flushing non-keyboard events."
- 	self eventQueue ifNotNil:
- 		[:queue |
- 		 queue flushAllSuchThat: [:buf | (self isAnyKbdEvent: buf) not]]!

Item was changed:
  ----- Method: EventSensor>>initialize (in category 'initialize') -----
  initialize
+ 
- 	"Initialize the receiver"
  	mouseButtons := 0.
+ 	mousePosition := 0 at 0.
+ 	mouseWheelDelta := 0 at 0.
- 	mousePosition := 0 @ 0.
- 	mouseWheelDelta := 0 @ 0.
  	keyboardBuffer := SharedQueue new.
+ 	
+ 	interruptKey := $. asciiValue bitOr: 16r0800. 	"cmd-."
+ 	interruptSemaphore := Semaphore new.
+ 	
+ 	eventQueue := SharedQueue new.
+ 	
- 	self setInterruptKey: (interruptKey ifNil: [$. asciiValue bitOr: 16r0800 ]). 	"cmd-."
- 	interruptSemaphore := (Smalltalk specialObjectsArray at: 31) ifNil: [Semaphore new].
- 	self flushAllButDandDEvents.
  	inputSemaphore := Semaphore new.
  	hasInputSemaphore := false.!

Item was changed:
  ----- Method: EventSensor>>installInterruptWatcher (in category 'user interrupts') -----
  installInterruptWatcher
  	"Initialize the interrupt watcher process. Terminate the old process if any."
  	"Sensor installInterruptWatcher"
  
  	InterruptWatcherProcess ifNotNil: [InterruptWatcherProcess terminate].
+ 	InterruptWatcherProcess := [self userInterruptWatcher] forkAt: Processor lowIOPriority.!
- 	InterruptSemaphore := Semaphore new.
- 	InterruptWatcherProcess := [self userInterruptWatcher] forkAt: Processor lowIOPriority.
- 	self primInterruptSemaphore: InterruptSemaphore.!

Item was removed:
- ----- Method: EventSensor>>kbdTest (in category 'keyboard') -----
- kbdTest    "Sensor kbdTest"
- 	"This test routine will print the unmodified character, its keycode,
- 	and the OR of all its modifier bits, until the character x is typed"
- 	| char evt |
- 	char := nil.
- 	[char = $x] whileFalse: 
- 		[[(evt := self peekKeyboardEvent) isNil] whileTrue.
- 		char := self characterForKeycode: evt third.
- 		(String streamContents: 
- 			[:s |
- 			s nextPut: char.
- 			(3 to: 8) with: 'cpmurw' do:
- 				[:i :c|
- 				s space; nextPut: c; nextPut: $:; print: (evt at: i); nextPutAll: '     ']])
- 			displayAt: 10 at 10]!

Item was removed:
- ----- Method: EventSensor>>keyboard (in category 'keyboard') -----
- keyboard
- 	"Answer the next character from the keyboard."
- 
- 	| firstCharacter secondCharactor stream multiCharacter converter |
- 	firstCharacter := self characterForKeycode: self primKbdNext.
- 	secondCharactor := self peekKeyboard.
- 	secondCharactor isNil
- 		ifTrue: [^ firstCharacter].
- 	converter := TextConverter defaultSystemConverter.
- 	converter isNil
- 		ifTrue: [^ firstCharacter].
- 	stream := ReadStream
- 				on: (String with: firstCharacter with: secondCharactor).
- 	multiCharacter := converter nextFromStream: stream.
- 	multiCharacter isOctetCharacter
- 		ifTrue: [^ multiCharacter].
- 	self primKbdNext.
- 	^ multiCharacter
- !

Item was removed:
- ----- Method: EventSensor>>keyboardPressed (in category 'keyboard') -----
- keyboardPressed
- 	"Answer true if keystrokes are available."
- 
- 	^self peekKeyboard notNil!

Item was changed:
  ----- Method: EventSensor>>nextEvent (in category 'accessing') -----
  nextEvent
+ 	"Return the next event from the receiver. If the queue is empty, try to fetch more events once."
- 	"Return the next event from the receiver."
  
  	^ self eventQueue 
+ 		ifNil: [
+ 			self fetchMoreEvents.
+ 			self nextEventSynthesized]
+ 		ifNotNil: [:queue |
+ 			keyboardBuffer flush.
+ 			mouseWheelDelta := 0 at 0.
+ 			queue isEmpty ifTrue: [self fetchMoreEvents].
+ 			queue nextOrNil]!
- 		ifNil: [self nextEventSynthesized]
- 		ifNotNil: [self nextEventFromQueue]
- !

Item was removed:
- ----- Method: EventSensor>>nextEventFromQueue (in category 'private') -----
- nextEventFromQueue
- 	"Return the next event from the receiver. If the queue is empty, try to fetch more events once."
- 
- 	self eventQueue isEmpty
- 		ifTrue: [self fetchMoreEvents].
- 
- 	^ self eventQueue isEmpty
- 		ifTrue: [nil]
- 		ifFalse: [self eventQueue next]!

Item was changed:
  ----- Method: EventSensor>>nextEventSynthesized (in category 'private') -----
  nextEventSynthesized
- 	"Return a synthesized event. This method is called if an event driven client wants to receive events but the primary user interface is not event-driven (e.g., the receiver does not have an event queue but only updates its state). This can, for instance, happen if a Morphic World is run in an MVC window. To simplify the clients work this method will always return all available keyboard events first, and then (repeatedly) the mouse events. Since mouse events come last, the client can assume that after one mouse event has been received there are no more to come. Note that it is impossible for EventSensor to determine if a mouse event has been issued before so the client must be aware of the possible problem of getting repeatedly the same mouse events. See HandMorph>>processEvents for an example on how to deal with this."
- 	| kbd array buttons pos modifiers mapped |
- 	"First check for keyboard"
- 	array := Array new: 8.
- 	kbd := self primKbdNext.
- 	kbd ifNotNil:
- 		["simulate keyboard event"
- 		array at: 1 put: EventTypeKeyboard. "evt type"
- 		array at: 2 put: Time eventMillisecondClock. "time stamp"
- 		array at: 3 put: (kbd bitAnd: 255). "char code"
- 		array at: 4 put: EventKeyChar. "key press/release"
- 		array at: 5 put: (kbd bitShift: -8). "modifier keys"
- 		^ array].
  
+ 	| synthesizedEvent |
+ 	synthesizedEvent := self peekEventSynthesized.
+ 	keyboardBuffer nextOrNil.
+ 	^ synthesizedEvent!
- 	"Then check for mouse"
- 	pos := self peekPosition.
- 	buttons := mouseButtons.
- 	modifiers := buttons bitShift: -3.
- 	buttons := buttons bitAnd: 7.
- 	mapped := self mapButtons: buttons modifiers: modifiers.
- 	array 
- 		at: 1 put: EventTypeMouse;
- 		at: 2 put: Time eventMillisecondClock;
- 		at: 3 put: pos x;
- 		at: 4 put: pos y;
- 		at: 5 put: mapped;
- 		at: 6 put: modifiers.
- 	^ array
- 
- !

Item was removed:
- ----- Method: EventSensor>>peekButtons (in category 'accessing') -----
- peekButtons
- 	self fetchMoreEvents.
- 	self flushNonKbdEvents.
- 	^ mouseButtons!

Item was changed:
  ----- Method: EventSensor>>peekEvent (in category 'accessing') -----
  peekEvent
  	"Look ahead at the next event. Try to fetch more events first."
  
  	^ self eventQueue
+ 		ifNil: [
- 		ifNil: [nil]
- 		ifNotNil: [:queue |
  			self fetchMoreEvents.
+ 			self peekEventSynthesized]
+ 		ifNotNil: [:queue |
+ 			queue isEmpty ifTrue: [self fetchMoreEvents].
  			queue peek]!

Item was added:
+ ----- Method: EventSensor>>peekEventSynthesized (in category 'private') -----
+ peekEventSynthesized
+ 	"Return a synthesized event. This method is called if an event driven client wants to receive events but the primary user interface is not event-driven (e.g., the receiver does not have an event queue but only updates its state). This can, for instance, happen if a Morphic World is run in an MVC window. To simplify the clients work this method will always return all available keyboard events first, and then (repeatedly) the mouse events. Since mouse events come last, the client can assume that after one mouse event has been received there are no more to come. Note that it is impossible for EventSensor to determine if a mouse event has been issued before so the client must be aware of the possible problem of getting repeatedly the same mouse events. See HandMorph>>processEvents for an example on how to deal with this."
+ 	| kbd array buttons pos modifiers mapped |
+ 	"First check for keyboard"
+ 	array := Array new: 8.
+ 	keyboardBuffer isEmpty ifFalse:
+ 		["simulate keyboard event"
+ 		array at: 1 put: EventTypeKeyboard. "evt type"
+ 		array at: 2 put: Time eventMillisecondClock. "time stamp"
+ 		array at: 3 put: ((kbd := keyboardBuffer peek) bitAnd: 255). "char code"
+ 		array at: 4 put: EventKeyChar. "key press/release"
+ 		array at: 5 put: (kbd bitShift: -8). "modifier keys"
+ 		^ array].
+ 
+ 	"Then check for mouse"
+ 	pos := mousePosition.
+ 	buttons := mouseButtons.
+ 	modifiers := buttons bitShift: -3.
+ 	buttons := buttons bitAnd: 7.
+ 	mapped := self mapButtons: buttons modifiers: modifiers.
+ 	array 
+ 		at: 1 put: EventTypeMouse;
+ 		at: 2 put: Time eventMillisecondClock;
+ 		at: 3 put: pos x;
+ 		at: 4 put: pos y;
+ 		at: 5 put: mapped;
+ 		at: 6 put: modifiers.
+ 	^ array
+ 
+ !

Item was removed:
- ----- Method: EventSensor>>peekKeyboard (in category 'keyboard') -----
- peekKeyboard
- 	"Answer the next character in the keyboard buffer without removing it, or nil if it is empty."
- 
- 	| char |
- 	self fetchMoreEvents.
- 	keyboardBuffer isEmpty ifFalse: [^ self characterForKeycode: keyboardBuffer peek].
- 	char := nil.
- 	self eventQueue ifNotNil: [:queue |
- 		queue nextOrNilSuchThat:  "NOTE: must not return out of this block, so loop to end"
- 			[:buf | (self isKbdEvent: buf) ifTrue: [char ifNil: [char := buf at: 3]].
- 			false  "NOTE: block value must be false so Queue won't advance"]].
- 	^ self characterForKeycode: char!

Item was removed:
- ----- Method: EventSensor>>peekKeyboardEvent (in category 'accessing') -----
- peekKeyboardEvent
- 	"Return the next keyboard char event from the receiver or nil if none available"
- 	
- 	^ self eventQueue
- 		ifNil: [nil]
- 		ifNotNil: [:queue |
- 			self fetchMoreEvents.
- 			queue nextOrNilSuchThat: [:buf | 
- 				buf first = EventTypeKeyboard and: [(buf fourth) = EventKeyChar]]]!

Item was removed:
- ----- Method: EventSensor>>peekPosition (in category 'accessing') -----
- peekPosition
- 	self fetchMoreEvents.
- 	"self flushNonKbdEvents. -- mt: Should not be necessary here."
- 	^ mousePosition!

Item was removed:
- ----- Method: EventSensor>>peekWheelDelta (in category 'accessing') -----
- peekWheelDelta
- 	self fetchMoreEvents.
- 	^ mouseWheelDelta!

Item was changed:
+ ----- Method: EventSensor>>primCursorLocPut: (in category 'private-I/O') -----
- ----- Method: EventSensor>>primCursorLocPut: (in category 'primitives-cursor') -----
  primCursorLocPut: aPoint
  	"If the primitive fails, try again with a rounded point."
  
  	<primitive: 91>
  	^ self primCursorLocPutAgain: aPoint rounded!

Item was changed:
+ ----- Method: EventSensor>>primCursorLocPutAgain: (in category 'private-I/O') -----
- ----- Method: EventSensor>>primCursorLocPutAgain: (in category 'primitives-cursor') -----
  primCursorLocPutAgain: aPoint
  	"Do nothing if primitive is not implemented."
  
  	<primitive: 91>
  	^ self!

Item was removed:
- ----- Method: EventSensor>>primInterruptSemaphore: (in category 'private') -----
- primInterruptSemaphore: aSemaphore 
- 	"Primitive. Install the argument as the semaphore to be signalled whenever the user presses the interrupt key. The semaphore will be signaled once each time the interrupt key is pressed."
- 	interruptSemaphore := aSemaphore.
- 	"backward compatibility: use the old primitive which is obsolete now"
- 	self oldPrimInterruptSemaphore: aSemaphore!

Item was removed:
- ----- Method: EventSensor>>primKbdNext (in category 'private') -----
- primKbdNext
- 	"Allows for use of old Sensor protocol to get at the keyboard,
- 	as when running kbdTest or the InterpreterSimulator in Morphic"
- 	| evtBuf |
- 	
- 	self flag: #refactor. "mt: Suspiciously similar to #peekKeyboardEvent"
- 	self fetchMoreEvents.
- 	keyboardBuffer isEmpty ifFalse:[^ keyboardBuffer next].
- 	self eventQueue ifNotNil: [:queue |
- 		evtBuf := queue nextOrNilSuchThat: [:buf | self isKbdEvent: buf].
- 		self flushNonKbdEvents].
- 	^ evtBuf ifNotNil: [evtBuf at: 3]
- !

Item was removed:
- ----- Method: EventSensor>>primSetInterruptKey: (in category 'private') -----
- primSetInterruptKey: anInteger
- 	"Primitive. Register the given keycode as the user interrupt key. The low byte of the keycode is the ISO character and its next four bits are the Smalltalk modifer bits <cmd><opt><ctrl><shift>."
- 	interruptKey := anInteger.
- 	"backward compatibility: use the old primitive which is obsolete now"
- 	self oldPrimSetInterruptKey: anInteger!

Item was changed:
  ----- Method: EventSensor>>processEvent: (in category 'private-I/O') -----
  processEvent: evt 
  	"Process a single event. This method is run at high priority."
  	| type buttons window |
  	type := evt at: 1.
  
  	"Only process main window events, forward others to host window proxies"
  	window := evt at: 8.
  	(window isNil or: [window isZero]) ifTrue: 
  		[window := 1. 
  		evt at: 8 put: window].
  	window = 1 ifFalse: [
  		^Smalltalk at: #HostWindowProxy ifPresent: [:w | w processEvent: evt]].
  
  	"Tackle mouse events and mouse wheel events first"
  	(type = EventTypeMouse or: [type = EventTypeMouseWheel])
  		ifTrue: [buttons := (ButtonDecodeTable at: (evt at: 5) + 1). 
  				evt at: 5 put: (Smalltalk platformName = 'Mac OS'
  							ifTrue: [ buttons ]
  							ifFalse: [ self mapButtons: buttons modifiers: (evt at: 6) ]).
  				self queueEvent: evt.
+ 				type = EventTypeMouseWheel
+ 					ifTrue: [^ self processMouseWheelEvent: evt].				
+ 				type = EventTypeMouse
+ 					ifTrue: [^ self processMouseEvent: evt]].
- 				type = EventTypeMouse ifTrue: [self processMouseEvent: evt].
- 				type = EventTypeMouseWheel ifTrue: [self processMouseWheelEvent: evt].				
- 				^self].
  	
  	"Store the event in the queue if there's any"
  	type = EventTypeKeyboard
  		ifTrue: [ "Check if the event is a user interrupt"
  			((evt at: 4) = EventKeyChar
  				and: [((evt at: 3)
  						bitOr: (((evt at: 5)
  							bitAnd: 8)
  							bitShift: 8))
  							= interruptKey])
  					ifTrue: ["interrupt key is meta - not reported as event"
  							^ interruptSemaphore signal].
  			"Decode keys for characters (i.e., duplicate or swap, ctrl <-> alt/cmd)."
  			(evt at: 4) = EventKeyChar
  				ifTrue: [ | unicode ascii |
  					"Copy lookup key first in case of key swap."
  					unicode := {evt at: 6. evt at: 5}.
  					ascii := {evt at: 3. evt at: 5}.
  					KeyDecodeTable "Unicode character first"
  						at: unicode
  						ifPresent: [:a | evt at: 6 put: a first;
  								 at: 5 put: a second]. 
  					KeyDecodeTable "ASCII character second"
  						at: ascii
  						ifPresent: [:a | evt at: 3 put: a first;
  								 at: 5 put: a second]]. 
  			self queueEvent: evt. 
  			self processKeyboardEvent: evt . 
  			^self ].
  				
  	"Handle all events other than Keyboard or Mouse."
  	self queueEvent: evt.
  	!

Item was changed:
  ----- Method: EventSensor>>processKeyboardEvent: (in category 'private-I/O') -----
  processKeyboardEvent: evt
  	"process a keyboard event, updating EventSensor state"
  	| charCode pressCode |
  	"Never update keyboardBuffer if we have an eventQueue active"
  	mouseButtons := (mouseButtons bitAnd: 7) bitOr: ((evt at: 5) bitShift: 3).
+ 	
- 	self eventQueue ifNotNil:[^self]. 
  	charCode := evt at: 3.
  	charCode = nil ifTrue:[^self]. "extra characters not handled in MVC"
  	pressCode := evt at: 4.
  	pressCode = EventKeyChar ifFalse:[^self]. "key down/up not handled in MVC"
  	"mix in modifiers"
  	charCode := charCode bitOr: ((evt at: 5) bitShift: 8).
  	keyboardBuffer nextPut: charCode.!

Item was changed:
  ----- Method: EventSensor>>processMouseWheelEvent: (in category 'private-I/O') -----
  processMouseWheelEvent: evt
  	"process a mouse wheel event, updating EventSensor state"
  	
  	| modifiers buttons mapped |
+ 	mouseWheelDelta := mouseWheelDelta + ((evt at: 3) @ (evt at: 4)).
- 	mouseWheelDelta := (evt at: 3) @ (evt at: 4).
  	buttons := evt at: 5.
  	modifiers := evt at: 6.
  	mapped := self mapButtons: buttons modifiers: modifiers.
  	mouseButtons := mapped bitOr: (modifiers bitShift: 3).!

Item was removed:
- ----- Method: EventSensor>>setInterruptKey: (in category 'user interrupts') -----
- setInterruptKey: anInteger
- 	"Register the given keycode as the user interrupt key."
- 
- 	self primSetInterruptKey: anInteger.
- !

Item was changed:
  ----- Method: EventSensor>>startUp (in category 'initialize') -----
  startUp
  
  	self initialize.
  	self primSetInputSemaphore: (Smalltalk registerExternalObject: inputSemaphore).
  
  	self installInterruptWatcher.
  	self installEventTickler.
  
+ 	self eventQueue: SharedQueue new.
- 	Smalltalk isMorphic ifTrue: [self flushAllButDandDEvents].
  
  	"Attempt to discover whether the input semaphore is actually being signaled."
  	hasInputSemaphore := false.
  	inputSemaphore initSignals.!

Item was changed:
  ----- Method: EventSensor>>userInterruptWatcher (in category 'user interrupts') -----
  userInterruptWatcher
  	"Wait for user interrupts and open a notifier on the active process when one occurs."
+ 	[ interruptSemaphore wait.
- 	[ InterruptSemaphore wait.
  	Display deferUpdates: false.
  	SoundService stop.
  	Smalltalk handleUserInterrupt ] repeat!


From commits at source.squeak.org  Wed Jul 15 09:24:14 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 15 Jul 2020 09:24:14 0000
Subject: [squeak-dev] The Trunk: ST80-mt.257.mcz
Message-ID: <E1jvdeC-0000YQ-RZ@andreas>

Marcel Taeumel uploaded a new version of ST80 to project The Trunk:
http://source.squeak.org/trunk/ST80-mt.257.mcz

==================== Summary ====================

Name: ST80-mt.257
Author: mt
Time: 15 July 2020, 11:24:14.540718 am
UUID: 0f736417-f062-483c-b2a3-9d1560a1bf1f
Ancestors: ST80-mt.256

Complements Kernel-mt.1333.

Fixes regression: mouse wheel works again in tools.

=============== Diff against ST80-mt.256 ===============

Item was added:
+ ----- Method: EventSensor>>characterForKeycode: (in category '*ST80-Support-keyboard') -----
+ characterForKeycode: keycode
+ 	"Map the given keycode to a Smalltalk character object. Encoding:
+ 		A keycode is 12 bits:   <4 modifer bits><8 bit ISO character>
+ 		Modifier bits are:       <command><option><control><shift>"
+ 
+ 	"NOTE: the command and option keys are specific to the Macintosh and may not have equivalents on other platforms."
+ 
+ 	keycode = nil ifTrue: [ ^nil ].
+ 	keycode class = Character ifTrue: [ ^keycode ].  "to smooth the transition!!"
+ 	^ Character value: (keycode bitAnd: 16rFF)!

Item was added:
+ ----- Method: EventSensor>>keyboard (in category '*ST80-Support-keyboard') -----
+ keyboard
+ 	"Answer the next (single-byte or multi-byte) character from the keyboard."
+ 
+ 	| firstCharacter secondCharactor stream multiCharacter converter |
+ 	"1) Consume next character from buffer."
+ 	(firstCharacter := self characterForKeycode: keyboardBuffer next) ifNil: [^ nil].
+ 	
+ 	"2) Peek additional character and try to read multi-byte character."
+ 	(secondCharactor := self characterForKeycode: keyboardBuffer peek) ifNil: [^ firstCharacter].
+ 	(converter := TextConverter defaultSystemConverter) ifNil: [^ firstCharacter].
+ 	stream := ReadStream on: (String with: firstCharacter with: secondCharactor).
+ 	multiCharacter := [converter nextFromStream: stream] ifError: [firstCharacter].
+ 	
+ 	"3) Only consume that additional character if we got a multi-byte character."
+ 	multiCharacter isOctetCharacter ifFalse: [keyboardBuffer next].
+ 	
+ 	"4) Answer either single-byte or multi-byte character."
+ 	^ multiCharacter
+ !

Item was added:
+ ----- Method: EventSensor>>keyboardPressed (in category '*ST80-Support-keyboard') -----
+ keyboardPressed
+ 	"Answer true if keystrokes are available."
+ 
+ 	^self peekKeyboard notNil!

Item was added:
+ ----- Method: EventSensor>>mouseWheelDelta (in category '*ST80-Support-mouse') -----
+ mouseWheelDelta
+ 
+ 	| delta |
+ 	delta := self peekMouseWheelDelta.
+ 	mouseWheelDelta := 0 at 0.
+ 	^ delta!

Item was added:
+ ----- Method: EventSensor>>mouseWheelDirection (in category '*ST80-Support-mouse') -----
+ mouseWheelDirection
+ 
+ 	| direction |
+ 	direction := self peekMouseWheelDirection.
+ 	mouseWheelDelta := 0 at 0.
+ 	^ direction!

Item was added:
+ ----- Method: EventSensor>>peekButtons (in category '*ST80-Support-mouse') -----
+ peekButtons
+ 
+ 	self fetchMoreEvents.
+ 	self eventQueue ifNotNil: [:queue | queue flush].
+ 	^ mouseButtons!

Item was added:
+ ----- Method: EventSensor>>peekKeyboard (in category '*ST80-Support-keyboard') -----
+ peekKeyboard
+ 	"Answer the next character in the keyboard buffer without removing it, or nil if it is empty."
+ 
+ 	self fetchMoreEvents.
+ 	self eventQueue ifNotNil: [:queue | queue flush].
+ 	^ self characterForKeycode: keyboardBuffer peek!

Item was added:
+ ----- Method: EventSensor>>peekMouseWheelDelta (in category '*ST80-Support-mouse') -----
+ peekMouseWheelDelta
+ 
+ 	self fetchMoreEvents.
+ 	self eventQueue ifNotNil: [:queue | queue flush].
+ 	^ mouseWheelDelta!

Item was added:
+ ----- Method: EventSensor>>peekMouseWheelDirection (in category '*ST80-Support-mouse') -----
+ peekMouseWheelDirection
+ 
+ 	| delta |
+ 	delta := self peekMouseWheelDelta.
+ 			
+ 	delta x > 0 ifTrue: [^ #right].
+ 	delta x < 0 ifTrue: [^ #left].
+ 	
+ 	delta y > 0 ifTrue: [^ #up].
+ 	delta y < 0 ifTrue: [^ #down].
+ 	
+ 	^ nil!

Item was added:
+ ----- Method: EventSensor>>peekPosition (in category '*ST80-Support-mouse') -----
+ peekPosition
+ 
+ 	self fetchMoreEvents.
+ 	self eventQueue ifNotNil: [:queue | queue flush].
+ 	^ mousePosition!

Item was changed:
  ----- Method: ListController>>controlActivity (in category 'control defaults') -----
  controlActivity
+ 	self scrollByMouseWheel ifTrue: [^self].
  	self scrollByKeyboard ifTrue: [^self].
  	self processKeyboard.
  	super controlActivity.
  !

Item was changed:
  ----- Method: MVCDebugger>>openNotifierNoSuspendContents:label: (in category 'initialize') -----
  openNotifierNoSuspendContents: msgString label: label
  
  	| builder spec view |
+ 	EventSensor default flushEvents.
  	super openNotifierNoSuspendContents: msgString label: label.
  	
  	builder := ToolBuilder default.
  	spec := self buildNotifierWith: builder label: label message: msgString.
  	
  	view := builder build: spec.
  	view controller openNoTerminate.
  
  	^ view!

Item was changed:
  ----- Method: MVCProject>>finalExitActions: (in category 'enter') -----
  finalExitActions: enteringProject
  
  	super finalExitActions: enteringProject.
  
  	self world unCacheWindows.
+ 	EventSensor default flushEvents.
- 	Sensor flushAllButDandDEvents.
  	
  	ScheduledControllers := nil.!

Item was changed:
  ----- Method: ParagraphEditor>>undo (in category 'menu messages') -----
  undo
  	"Reset the state of the paragraph prior to the previous edit.
  	 If another ParagraphEditor instance did that edit, UndoInterval is invalid;
  	 just recover the contents of the undo-buffer at the start of the paragraph."
  
+ 	sensor flushEvents. "a way to flush stuck keys"
- 	sensor flushKeyboard. "a way to flush stuck keys"
  	self closeTypeIn.
  
  	UndoParagraph == paragraph ifFalse: "Can't undo another paragraph's edit"
  		[UndoMessage := Message selector: #undoReplace.
  		UndoInterval := 1 to: 0.
  		Undone := true].
  	UndoInterval ~= self selectionInterval ifTrue: "blink the actual target"
  		[self selectInterval: UndoInterval; deselect].
  
  	"Leave a signal of which phase is in progress"
  	UndoParagraph := Undone ifTrue: [#redoing] ifFalse: [#undoing].
  	UndoMessage sentTo: self.
  	UndoParagraph := paragraph!

Item was changed:
  ----- Method: ScrollController>>controlActivity (in category 'control defaults') -----
  controlActivity
+ 	self scrollByMouseWheel ifTrue: [^ self].
  	self scrollByKeyboard ifTrue: [^ self].
  	self scrollBarContainsCursor
  		ifTrue: [self scroll]
  		ifFalse: [self normalActivity]!

Item was changed:
  ----- Method: ScrollController>>scrollByKeyboard (in category 'scrolling') -----
  scrollByKeyboard
  	| keyEvent |
  	keyEvent := sensor peekKeyboard.
  	keyEvent ifNil: [^ false].
  	(sensor controlKeyPressed or:[sensor commandKeyPressed]) ifFalse: [^ false].
  	keyEvent asciiValue = 30
  		ifTrue: 
  			[sensor keyboard.
+ 			self scrollViewUp ifTrue: [self moveMarker].
- 			self scrollViewDown ifTrue: [self moveMarker].
  			^ true].
  	keyEvent asciiValue = 31
  		ifTrue: 
  			[sensor keyboard.
+ 			self scrollViewDown ifTrue: [self moveMarker].
- 			self scrollViewUp ifTrue: [self moveMarker].
  			^ true].
  	^ false!

Item was added:
+ ----- Method: ScrollController>>scrollByMouseWheel (in category 'scrolling') -----
+ scrollByMouseWheel
+ 	| wheelDirection |
+ 	wheelDirection := sensor peekMouseWheelDirection.	
+ 	wheelDirection = #up
+ 		ifTrue: 
+ 			[sensor mouseWheelDirection.
+ 			self scrollViewUp ifTrue: [self moveMarker].
+ 			^ true].
+ 	wheelDirection = #down
+ 		ifTrue: 
+ 			[sensor mouseWheelDirection.
+ 			self scrollViewDown ifTrue: [self moveMarker].
+ 			^ true].
+ 	^ false!

Item was changed:
  ----- Method: ScrollController>>scrollViewDown (in category 'scrolling') -----
  scrollViewDown
  	"Scroll the receiver's view down the default amount.
  	Return true only if scrolling actually took place."
+ 	^ self scrollView: self scrollAmount negated!
- 	^ self scrollView: self scrollAmount!

Item was changed:
  ----- Method: ScrollController>>scrollViewUp (in category 'scrolling') -----
  scrollViewUp
  	"Scroll the receiver's view up the default amount.
  	Return true only if scrolling actually took place."
+ 	^ self scrollView: self scrollAmount!
- 	^ self scrollView: self scrollAmount negated!


From commits at source.squeak.org  Wed Jul 15 09:24:45 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 15 Jul 2020 09:24:45 0000
Subject: [squeak-dev] The Trunk: Tools-mt.983.mcz
Message-ID: <E1jvdei-0000YY-6i@andreas>

Marcel Taeumel uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-mt.983.mcz

==================== Summary ====================

Name: Tools-mt.983
Author: mt
Time: 15 July 2020, 11:24:43.638718 am
UUID: 1a94f354-ff47-4d70-b27d-8134ae3249d2
Ancestors: Tools-mt.982

Complements Kernel-mt.1333

=============== Diff against Tools-mt.982 ===============

Item was changed:
  ----- Method: Debugger>>openNotifierNoSuspendContents:label: (in category 'initialize') -----
  openNotifierNoSuspendContents: msgString label: label
  	"Create, schedule and answer a notifier view with the given label and message. A notifier view shows just the message or the first several lines of the stack, with a menu that allows the user to open a full debugger if so desired."
  	"NOTE: When this method returns, a new process has been scheduled to run the windows, and thus this notifier, but the previous active process has not been suspended.  The sender will do this."
  
- 	Sensor flushKeyboard.
  	savedCursor := Cursor currentCursor.
  	Cursor currentCursor: Cursor normal.
  	
  	self expandNotifierStack.!


From commits at source.squeak.org  Wed Jul 15 09:25:36 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 15 Jul 2020 09:25:36 0000
Subject: [squeak-dev] The Trunk: Morphic-mt.1670.mcz
Message-ID: <E1jvdfc-0000Zd-5R@andreas>

Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1670.mcz

==================== Summary ====================

Name: Morphic-mt.1670
Author: mt
Time: 15 July 2020, 11:25:30.453718 am
UUID: 67b727fe-aab7-47cc-a276-070a5ba8b930
Ancestors: Morphic-mt.1669

Complements Kernel-mt.1333

=============== Diff against Morphic-mt.1669 ===============

Item was removed:
- ----- Method: HandMorph>>checkForMoreKeyboard (in category 'event handling') -----
- checkForMoreKeyboard
- 	"Quick check for more keyboard activity -- Allows, eg, many characters
- 	to be accumulated into a single replacement during type-in."
- 
- 	| evtBuf |
- 	self flag: #arNote.	"Will not work if we don't examine event queue in Sensor"
- 	evtBuf := Sensor peekKeyboardEvent.
- 	evtBuf ifNil: [^nil].
- 	^self generateKeyboardEvent: evtBuf!

Item was changed:
  ----- Method: MorphicProject>>finalExitActions: (in category 'enter') -----
  finalExitActions: enteringProject
  
  	world triggerClosingScripts.
  
  	"Pause sound players, subject to preference settings"
  	(world hasProperty: #letTheMusicPlay)
  		ifTrue: [world removeProperty: #letTheMusicPlay]
  		ifFalse: [SoundService stop].
  
  	world sleep.
  
  	(world findA: ProjectNavigationMorph)
  		ifNotNil: [:navigator | navigator retractIfAppropriate].
  
  	self clearGlobalState.
+ 	EventSensor default flushEvents.
- 	Sensor flushAllButDandDEvents. 
  	
  	self world submorphsDo: [:ea | ea removeProperty: #dropShadow].!

Item was changed:
  ----- Method: PasteUpMorph>>install (in category 'world state') -----
  install
  	owner := nil.	"since we may have been inside another world previously"
  	ActiveWorld := self.
  	ActiveHand := self hands first.	"default"
  	ActiveEvent := nil.
  	submorphs do: [:ss | ss owner isNil ifTrue: [ss privateOwner: self]].
  	"Transcript that was in outPointers and then got deleted."
  	self viewBox: Display boundingBox.
+ 	EventSensor default flushEvents.
- 	Sensor flushAllButDandDEvents.
  	worldState handsDo: [:h | h initForEvents].
  	self installFlaps.
  	self borderWidth: 0.	"default"
  	(Preferences showSecurityStatus 
  		and: [SecurityManager default isInRestrictedMode]) 
  			ifTrue: 
  				[self
  					borderWidth: 2;
  					borderColor: Color red].
  	self presenter allExtantPlayers do: [:player | player prepareToBeRunning].
  	SystemWindow noteTopWindowIn: self.!


From commits at source.squeak.org  Wed Jul 15 09:26:50 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 15 Jul 2020 09:26:50 0000
Subject: [squeak-dev] The Trunk: EToys-mt.398.mcz
Message-ID: <E1jvdgn-0000bS-Od@andreas>

Marcel Taeumel uploaded a new version of EToys to project The Trunk:
http://source.squeak.org/trunk/EToys-mt.398.mcz

==================== Summary ====================

Name: EToys-mt.398
Author: mt
Time: 15 July 2020, 11:26:41.827718 am
UUID: ca4709d0-cf7b-4afa-9938-6aceb743d845
Ancestors: EToys-kfr.397

Removes deprecated, dead method.

=============== Diff against EToys-kfr.397 ===============

Item was removed:
- ----- Method: EventSensor>>swapControlAndAltKeys: (in category '*Etoys-Squeakland-private-I/O') -----
- swapControlAndAltKeys: evt
- 	| char |
- 	char := evt at: 3.
- 	"Cursor keys and mouse wheel are not switched."
- 	(#(28 29 30 31) includes: char) ifTrue: [^ self].
- 	(evt at: 5) == CtrlKeyBit
- 		ifTrue: ["Ctrl -> Alt (^A -> a)"
- 			char < 32 ifTrue: [#(3 6) do: [:ind | evt at: ind put: (char bitOr: 16r60)]].
- 			evt at: 5 put: 8]
- 		ifFalse: [(evt at: 5) == CommandKeyBit
- 			ifTrue: ["Alt -> Ctrl (a -> ^A)"
- 				(char >= 16r60 and:  [char < 16r80]) ifTrue: [#(3 6) do: [:ind | evt at: ind put: (char bitAnd: 16r1F)]].
- 				evt at: 5 put: 2]].!


From commits at source.squeak.org  Wed Jul 15 09:29:34 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 15 Jul 2020 09:29:34 0000
Subject: [squeak-dev] The Trunk: Kernel-mt.1334.mcz
Message-ID: <E1jvdjO-0000dH-BC@andreas>

Marcel Taeumel uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-mt.1334.mcz

==================== Summary ====================

Name: Kernel-mt.1334
Author: mt
Time: 15 July 2020, 11:29:30.243718 am
UUID: 15f827c9-c26e-46bf-a2e7-cddea3a22ee2
Ancestors: Kernel-mt.1333

Re-install interrupt watcher because semaphore changed in Kernel-mt.1333 from classVar to instVar.

=============== Diff against Kernel-mt.1333 ===============

Item was changed:
+ (PackageInfo named: 'Kernel') postscript: 'EventSensor default installInterruptWatcher.'!
- (PackageInfo named: 'Kernel') postscript: '"Transform the cache for #once into IdentityDictionary."
- 
- self systemNavigation allSelectorsAndMethodsDo: [ :behavior :selector :method |
- 	(method hasLiteral: #once)
- 		ifTrue: [(method propertyValueAt: #onceCache ifAbsent: [])
- 			ifNotNil:
- 				[:cache |
- 				method
- 					propertyValueAt: #onceCache
- 					put: (cache as: IdentityDictionary)]]].'!


From commits at source.squeak.org  Wed Jul 15 09:38:18 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 15 Jul 2020 09:38:18 0000
Subject: [squeak-dev] The Trunk: Morphic-mt.1671.mcz
Message-ID: <E1jvdrr-0000l0-Up@andreas>

Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1671.mcz

==================== Summary ====================

Name: Morphic-mt.1671
Author: mt
Time: 15 July 2020, 11:38:13.811718 am
UUID: a357cbeb-ab17-48d7-b9cd-32c9c64d50f9
Ancestors: Morphic-mt.1670

Fixes demo/hi-dpi mode for system progress bar.

=============== Diff against Morphic-mt.1670 ===============

Item was changed:
  ----- Method: SystemProgressMorph class>>applyUserInterfaceTheme (in category 'preferences') -----
  applyUserInterfaceTheme
  
+ 	self initialize; reset.!
- 	self reset.!

Item was changed:
  ----- Method: SystemProgressMorph class>>initialize (in category 'class initialization') -----
  initialize
  	"SystemProgressMorph initialize; reset"
+ 	
+ 	BarHeight := (8 * RealEstateAgent scaleFactor) rounded.
+ 	BarWidth := (300 * RealEstateAgent scaleFactor) rounded.
+ 	Inset := ((30 at 30) * RealEstateAgent scaleFactor) rounded.!
- 	BarHeight := 8.
- 	BarWidth := 300.
- 	Inset := 30 at 30!


From commits at source.squeak.org  Wed Jul 15 10:53:45 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Wed, 15 Jul 2020 10:53:45 0000
Subject: [squeak-dev] The Trunk: Morphic-mt.1672.mcz
Message-ID: <E1jvf2v-0001np-GF@andreas>

Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1672.mcz

==================== Summary ====================

Name: Morphic-mt.1672
Author: mt
Time: 15 July 2020, 12:53:39.33025 pm
UUID: ba486bd0-690f-4685-8c79-0374ab461663
Ancestors: Morphic-mt.1671

Fixes recent regression. Sorry for the noise.

=============== Diff against Morphic-mt.1671 ===============

Item was changed:
  ----- Method: IndentingListItemMorph>>initWithContents:prior:forList:indentLevel: (in category 'initialization') -----
  initWithContents: anObject prior: priorMorph forList: hostList indentLevel: newLevel
  
  	container := hostList.
  	
  	complexContents := anObject.
  	anObject addDependent: self.
  	
  	self initWithContents: self getLabel font: Preferences standardListFont emphasis: nil.
  	indentLevel := 0.
  	isExpanded := false.
   	nextSibling := firstChild := nil.
  	priorMorph ifNotNil: [
  		priorMorph nextSibling: self.
  	].
  	indentLevel := newLevel.
+ 	icon := self getIcon ifNotNil: [:form | form scaleIconToDisplay].
- 	icon := self getIcon scaleIconToDisplay.
  	self extent: self minWidth @ self minHeight!

Item was changed:
  ----- Method: IndentingListItemMorph>>refresh (in category 'initialization') -----
  refresh
  
  	self contents: self getLabel.
+ 	icon := self getIcon ifNotNil: [:form | form scaleIconToDisplay].
- 	icon := self getIcon scaleIconToDisplay.
  	
  	(self valueOfProperty: #wasRefreshed ifAbsent: [false]) ifFalse: [
  		self setProperty: #wasRefreshed toValue: true].!


From tim at rowledge.org  Thu Jul 16 01:19:12 2020
From: tim at rowledge.org (tim Rowledge)
Date: Wed, 15 Jul 2020 18:19:12 -0700
Subject: [squeak-dev] Installing metacello within a 'Smalltalk run:[]' fails
Message-ID: <7BAC259A-CC81-440E-9682-193F08F8E8DF@rowledge.org>

Running 
Installer ensureRecentMetacello 
works. (in a 5.3-19435 image)

Wrapping it in 
Smalltalk run:[Installer ensureRecentMetacello ]
crashes. Specifically in MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration' is nil on the last line. 

Seems a bit odd; possibly sometihng to do with the assorted exception handling in the SmalltalkImage>run: code?

I'm trying to make a simplecommandline  filein that will load a bunch'o'stuff, something that has been doable before, so this is a bit puzzling.

{a bit later}
Hmm, moving the Installer ensureRecentMetacello  outside the run: block lets it install but later use of metacello within the run: block to load Seaside fails because MetacelloIgnorePackageLoaded signal: pkg doesn't return a boolean. So, yeah, probably sometihng to do with the run: handling of exceptions.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"How many tnuctip does it take to change a lightbulb?” 
"Depends what you want them to change it into."




From leves at caesar.elte.hu  Thu Jul 16 02:09:40 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Thu, 16 Jul 2020 04:09:40 +0200 (CEST)
Subject: [squeak-dev] Installing metacello within a 'Smalltalk run:[]'
 fails
In-Reply-To: <7BAC259A-CC81-440E-9682-193F08F8E8DF@rowledge.org>
References: <7BAC259A-CC81-440E-9682-193F08F8E8DF@rowledge.org>
Message-ID: <alpine.DEB.2.02.2007160354510.13842@login03.caesar.elte.hu>

On Wed, 15 Jul 2020, tim Rowledge wrote:

> Running 
> Installer ensureRecentMetacello 
> works. (in a 5.3-19435 image)
>
> Wrapping it in 
> Smalltalk run:[Installer ensureRecentMetacello ]
> crashes. Specifically in MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration' is nil on the last line. 
>
> Seems a bit odd; possibly sometihng to do with the assorted exception handling in the SmalltalkImage>run: code?

I think the cause of the problem is that SmalltalkImage >> #run: 
catches all Notifications, logs them, and finally #resumes them.
But many Notifications override #defaultAction, and the return value of 
that method will be the value the Notification normally returns with when 
not handled.
#resume does not send #defaultAction (it sends #defaultResumeValue, 
which is rarely used).

IMO the code should not #resume the Notifications just #pass them, so that 
they can return with whatever they want (or be handled by an outer 
handler).


Levente

>
> I'm trying to make a simplecommandline  filein that will load a bunch'o'stuff, something that has been doable before, so this is a bit puzzling.
>
> {a bit later}
> Hmm, moving the Installer ensureRecentMetacello  outside the run: block lets it install but later use of metacello within the run: block to load Seaside fails because MetacelloIgnorePackageLoaded signal: pkg doesn't return a boolean. So, yeah, probably sometihng to do with the run: handling of exceptions.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> "How many tnuctip does it take to change a lightbulb?” 
> "Depends what you want them to change it into."

From tim at rowledge.org  Thu Jul 16 04:01:03 2020
From: tim at rowledge.org (tim Rowledge)
Date: Wed, 15 Jul 2020 21:01:03 -0700
Subject: [squeak-dev] Installing metacello within a 'Smalltalk run:[]'
 fails
In-Reply-To: <alpine.DEB.2.02.2007160354510.13842@login03.caesar.elte.hu>
References: <7BAC259A-CC81-440E-9682-193F08F8E8DF@rowledge.org>
 <alpine.DEB.2.02.2007160354510.13842@login03.caesar.elte.hu>
Message-ID: <2A126DD8-C987-40D7-8DBA-BA1290B3EDEC@rowledge.org>



> On 2020-07-15, at 7:09 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> 
> On Wed, 15 Jul 2020, tim Rowledge wrote:
> 
>> Running Installer ensureRecentMetacello works. (in a 5.3-19435 image)
>> 
>> Wrapping it in Smalltalk run:[Installer ensureRecentMetacello ]
>> crashes. Specifically in MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration' is nil on the last line. 
>> Seems a bit odd; possibly sometihng to do with the assorted exception handling in the SmalltalkImage>run: code?
> 
> I think the cause of the problem is that SmalltalkImage >> #run: catches all Notifications, logs them, and finally #resumes them.
> But many Notifications override #defaultAction, and the return value of that method will be the value the Notification normally returns with when not handled.
> #resume does not send #defaultAction (it sends #defaultResumeValue, which is rarely used).

Sounds pretty likely to me. It's another of those 'fun' cases where one tries to handle errors that you don't necessarily know how to handle. Almost always a problem. I think I have a sigline about that mistake.


> 
> IMO the code should not #resume the Notifications just #pass them, so that they can return with whatever they want (or be handled by an outer handler).

Except that surely the problem then becomes that the default action of many Notification type exceptions is to do some UI thing, and the entire point of the run: stuff is to avoid that so it can be a commandline no-UI activity. ;-)

Is it a case of a different type of exception being the right way of doing it within the metacello load code?  I see several Metacello exception classes under Notification, mostly with #defaultAction returning a boolean. Don't see any current exception class that really covers the 'give me a default boolean answer' case.

Exception handling is *such* fun!

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't you dare erase my hard disk!



From commits at source.squeak.org  Thu Jul 16 10:32:30 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Thu, 16 Jul 2020 10:32:30 0000
Subject: [squeak-dev] The Trunk: Morphic-mt.1673.mcz
Message-ID: <E1jw1Bu-0004YD-K2@andreas>

Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1673.mcz

==================== Summary ====================

Name: Morphic-mt.1673
Author: mt
Time: 16 July 2020, 12:32:25.66555 pm
UUID: 4cdee1e0-9104-4e4f-a08f-12a77681f58e
Ancestors: Morphic-mt.1672

Fixes toggle icons in tree widgets for demo/hi-dpi mode.

=============== Diff against Morphic-mt.1672 ===============

Item was changed:
  ----- Method: IndentingListItemMorph>>toggleRectangle (in category 'private') -----
  toggleRectangle
  
+ 	| h indent |
- 	| h |
  	h := bounds height.
+ 	indent := (12 * RealEstateAgent scaleFactor) rounded.
+ 	^(bounds left + self hMargin + (indent * indentLevel)) @ bounds top extent: indent at h!
- 	^(bounds left + self hMargin + (12 * indentLevel)) @ bounds top extent: 12 at h!

Item was added:
+ ----- Method: SimpleHierarchicalListMorph class>>applyUserInterfaceTheme (in category 'preferences') -----
+ applyUserInterfaceTheme
+ 
+ 	expandedForm := nil.
+ 	notExpandedForm := nil.!

Item was changed:
  ----- Method: SimpleHierarchicalListMorph class>>expandedForm (in category 'instance creation') -----
  expandedForm
  	expandedForm
  		ifNotNil: [expandedForm depth ~= Display depth
  				ifTrue: [expandedForm := nil]].
  	^ expandedForm
  		ifNil: [expandedForm := ((Form
  						extent: 10 @ 9
  						depth: 8
  						fromArray: #(4294967295 4294967295 4294901760 4294967295 4294967295 4294901760 4278255873 16843009 16842752 4294902089 1229539657 33488896 4294967041 1229539585 4294901760 4294967295 21561855 4294901760 4294967295 4278321151 4294901760 4294967295 4294967295 4294901760 4294967295 4294967295 4294901760 )
  						offset: 0 @ 0)
+ 						asFormOfDepth: Display depth)
+ 							replaceColor: Color white withColor: Color transparent;
+ 							scaleIconToDisplay]!
- 						asFormOfDepth: Display depth) replaceColor: Color white withColor: Color transparent;
- 						 yourself]!

Item was changed:
  ----- Method: SimpleHierarchicalListMorph class>>notExpandedForm (in category 'instance creation') -----
  notExpandedForm
  	notExpandedForm
  		ifNotNil: [notExpandedForm depth ~= Display depth
  				ifTrue: [notExpandedForm := nil]].
  	^ notExpandedForm
  		ifNil: [notExpandedForm := ((Form
  						extent: 10 @ 9
  						depth: 8
  						fromArray: #(4294967041 4294967295 4294901760 4294967041 33554431 4294901760 4294967041 1224867839 4294901760 4294967041 1229521407 4294901760 4294967041 1229539585 4294901760 4294967041 1229521407 4294901760 4294967041 1224867839 4294901760 4294967041 33554431 4294901760 4294967041 4294967295 4294901760 )
  						offset: 0 @ 0)
  							asFormOfDepth: Display depth)
  								replaceColor: Color white withColor: Color transparent;
+ 								scaleIconToDisplay]!
- 								yourself]!


From forums.jakob at resfarm.de  Thu Jul 16 12:35:09 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Thu, 16 Jul 2020 14:35:09 +0200
Subject: [squeak-dev] Metacello bootstrap fails due to download timeouts
In-Reply-To: <b8b72d1967ee40a783ac7103b27f6d68@student.hpi.uni-potsdam.de>
References: <CA+ovNC7heD+TNTU1172ZVKdPWnEcwoq77d0+f-b-cOAgrwn77A@mail.gmail.com>
 <06BCBF78-A8FB-4FBF-B767-967DDF3DF328@gmx.de>
 <CA+ovNC5bisshctQWtXkvQiGAFmD7RJALZLZKm7RspaQKdk_N=A@mail.gmail.com>
 <b306bde84e9949b2bafddf44658a3de5@student.hpi.uni-potsdam.de>
 <CA+ovNC4ixTYL7=hB1KvN=wEYyB9A6KTEfr9CUQYyc_aFbz6eNw@mail.gmail.com>
 <b8b72d1967ee40a783ac7103b27f6d68@student.hpi.uni-potsdam.de>
Message-ID: <CA+ovNC6ZAUPYpaowM-0TM=eZ6cjt7TiT4+3SSA7Y2O5atup_5w@mail.gmail.com>

All the previously errored builds are green now. So we can again stop
worrying about the present and return to thinking about the future.
;-)

I'm still somewhat confused that the download from the Seaside/Gemtalk
repository did not work and that SmalltalkHub was tried in the first
place. Are versions missing in the Gemtalk repository? Can look it up
myself at earliest on Saturday, more likely next week.


Am Di., 14. Juli 2020 um 08:28 Uhr schrieb Beckmann, Tom
<Tom.Beckmann at student.hpi.uni-potsdam.de>:
>
> Ah sorry, I got confused with the various 32- vs 64-bit mentions.
> Also, the SqueakSSL issue turned out to be just me forgetting that I did not have a well-configured 32bit environment.
>
> I just tried running the Squot tests locally with squeak32-trunk on smalltalkCI, which turned out all green. For a couple hours now, smalltalkHub is also online again, so maybe the issues you were observing were all related to this part of the infrastructure failing and errors bubbling up to unexpected places? Or are the builds still failing on Travis?
> ________________________________________
> From: Jakob Reschke <forums.jakob at resfarm.de>
> Sent: Monday, July 13, 2020 11:37:51 PM
> To: Beckmann, Tom
> Cc: Tobias Pape; The general-purpose Squeak developers list; Henrichs, Dale (Gemtalksystems); Niephaus, Fabio
> Subject: Re: Metacello bootstrap fails due to download timeouts
>
> Beckmann, Tom <Tom.Beckmann at student.hpi.uni-potsdam.de<mailto:Tom.Beckmann at student.hpi.uni-potsdam.de>> schrieb am Mo., 13. Juli 2020, 19:47:
>
> Concerning Squeak-trunk 32bit builds, I just tried to run one locally headful, and a failure occurs in primitiveSSLCreate, leading to a notification about ensuring to have internet and then a quiet image (see Installer>>ensureRecentMetacello, `self inform: ...`). I suppose we could consider changing this to an error instead, such that the CI build would fail rather than happily wait for ever after for you to click on the Okay button of the info window. Or, even better, create an Exception subclass for it that smalltalkCI can catch and handle appropriately, while by default the user sees the same info window.
>
>
> Since that is not what I observed, we seem to have multiple such points of non-failures...

From commits at source.squeak.org  Thu Jul 16 12:43:56 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Thu, 16 Jul 2020 12:43:56 0000
Subject: [squeak-dev] The Inbox: Collections-ul.903.mcz
Message-ID: <E1jw3F1-0006M3-03@andreas>

Levente Uzonyi uploaded a new version of Collections to project The Inbox:
http://source.squeak.org/inbox/Collections-ul.903.mcz

==================== Summary ====================

Name: Collections-ul.903
Author: ul
Time: 16 July 2020, 2:43:29.805477 pm
UUID: 8864e74e-e7c5-4419-b789-cb6b0889df42
Ancestors: Collections-ul.902

- let String >> #compareWith: use primitive 158 even if indirectly

=============== Diff against Collections-ul.902 ===============

Item was changed:
  ----- Method: String>>compareWith: (in category 'comparing') -----
  compareWith: aString
  
  	"<primitive: 158>"
+ 	^self compareWith: aString collated: AsciiOrder!
- 	^(self compare: self with: aString collated: AsciiOrder) - 2!


From leves at caesar.elte.hu  Thu Jul 16 12:50:15 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Thu, 16 Jul 2020 14:50:15 +0200 (CEST)
Subject: [squeak-dev] Installing metacello within a 'Smalltalk run:[]'
 fails
In-Reply-To: <2A126DD8-C987-40D7-8DBA-BA1290B3EDEC@rowledge.org>
References: <7BAC259A-CC81-440E-9682-193F08F8E8DF@rowledge.org>
 <alpine.DEB.2.02.2007160354510.13842@login03.caesar.elte.hu>
 <2A126DD8-C987-40D7-8DBA-BA1290B3EDEC@rowledge.org>
Message-ID: <alpine.DEB.2.02.2007161446320.14732@login03.caesar.elte.hu>

On Wed, 15 Jul 2020, tim Rowledge wrote:

>
>
>> On 2020-07-15, at 7:09 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> 
>> On Wed, 15 Jul 2020, tim Rowledge wrote:
>> 
>>> Running Installer ensureRecentMetacello works. (in a 5.3-19435 image)
>>> 
>>> Wrapping it in Smalltalk run:[Installer ensureRecentMetacello ]
>>> crashes. Specifically in MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration' is nil on the last line. 
>>> Seems a bit odd; possibly sometihng to do with the assorted exception handling in the SmalltalkImage>run: code?
>> 
>> I think the cause of the problem is that SmalltalkImage >> #run: catches all Notifications, logs them, and finally #resumes them.
>> But many Notifications override #defaultAction, and the return value of that method will be the value the Notification normally returns with when not handled.
>> #resume does not send #defaultAction (it sends #defaultResumeValue, which is rarely used).
>
> Sounds pretty likely to me. It's another of those 'fun' cases where one tries to handle errors that you don't necessarily know how to handle. Almost always a problem. I think I have a sigline about that mistake.
>
>
>> 
>> IMO the code should not #resume the Notifications just #pass them, so that they can return with whatever they want (or be handled by an outer handler).
>
> Except that surely the problem then becomes that the default action of many Notification type exceptions is to do some UI thing, and the entire point of the run: stuff is to avoid that so it can be a commandline no-UI activity. ;-)

AFAIK that is why DummyUIManager exists. It lets you provide answers to 
these questions (via Notifications :)) or go with a default value if 
possible.


Levente

>
> Is it a case of a different type of exception being the right way of doing it within the metacello load code?  I see several Metacello exception classes under Notification, mostly with #defaultAction returning a boolean. Don't see any current exception class that really covers the 'give me a default boolean answer' case.
>
> Exception handling is *such* fun!
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't you dare erase my hard disk!

From commits at source.squeak.org  Thu Jul 16 22:10:26 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Thu, 16 Jul 2020 22:10:26 0000
Subject: [squeak-dev] The Trunk: Tools-eem.984.mcz
Message-ID: <E1jwC5G-0005jn-8j@andreas>

Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.984.mcz

==================== Summary ====================

Name: Tools-eem.984
Author: eem
Time: 16 July 2020, 3:10:24.240422 pm
UUID: c9cea967-9685-4ce3-8eea-72da87f12be6
Ancestors: Tools-mt.983

Fix a regression in Tools-ct.952.
This fix constitutes a review of http://forum.world.st/BUG-in-Debugger-gt-gt-newStack-optimization-td5112726.html

=============== Diff against Tools-mt.983 ===============

Item was changed:
  ----- Method: Debugger>>newStack: (in category 'private') -----
  newStack: stack
+ 	| oldStack diff matchIndex |
- 	| oldStack diff |
  	oldStack := contextStack.
  	contextStack := stack.
+ 	(oldStack isNil or: [oldStack last ~~ stack last]) ifTrue:
+ 		[contextStackList := stack collect: [:ctx | ctx printString].
+ 		 ^self].
- 	(oldStack == nil or: [oldStack last ~~ stack last])
- 		ifTrue: [contextStackList := contextStack collect: [:ctx | ctx printString].
- 				^ self].
  	"May be able to re-use some of previous list"
  	diff := stack size - oldStack size.
  	contextStackList := diff <= 0
+ 		ifTrue: [contextStackList copyFrom: 1 - diff to: oldStack size]
+ 		ifFalse:
+ 			[matchIndex := stack lastIndexOf: oldStack first startingAt: diff + 1.
+ 			 matchIndex = 0
+ 				ifTrue: [contextStack collect: [:ctx | ctx printString]]
+ 				ifFalse: [((contextStack first: matchIndex - 1) collect: [:ctx| ctx printString]), contextStackList]]
+ 						"#(d e f h i) => #(a b c d e f g h i)
+ 						diff := 3.
+ 						matchIndex := 4.
+ 						#(a b c d e f g h i) := #(a b c), #(d e f h i)"!
- 		ifTrue: [contextStackList copyFrom: 1-diff to: oldStack size]
- 		ifFalse: [(diff = 1 and: [stack second == oldStack first])
- 			ifTrue: [contextStackList copyWithFirst: stack first printString]
- 			ifFalse: [contextStack collect: [:ctx | ctx printString]]]!


From commits at source.squeak.org  Thu Jul 16 22:13:11 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Thu, 16 Jul 2020 22:13:11 0000
Subject: [squeak-dev] The Trunk: KernelTests-eem.384.mcz
Message-ID: <E1jwC7s-0005lc-Vm@andreas>

Eliot Miranda uploaded a new version of KernelTests to project The Trunk:
http://source.squeak.org/trunk/KernelTests-eem.384.mcz

==================== Summary ====================

Name: KernelTests-eem.384
Author: eem
Time: 16 July 2020, 3:13:09.314392 pm
UUID: da087b71-cc6c-42d5-b8e7-fe03fca763c2
Ancestors: KernelTests-tpr.383

Revert KernelTests-tpr.383's setFreeSpaceLimitOf:around: now that the VM correctly accepts large integers for vm parameter #57.

=============== Diff against KernelTests-tpr.383 ===============

Item was changed:
  ----- Method: AllocationTest>>setFreeSpaceLimitOf:around: (in category 'support') -----
  setFreeSpaceLimitOf: bytes around: aBlock
  	"Attempt to evaluate aBlock with a limit of the requested ammount
  	 of free old space, restoring the extant limit after the evaluation."
  
  	| extantLimit |
  	extantLimit := Smalltalk vmParameterAt: 67.
+ 	Smalltalk vmParameterAt: 67 put: (Smalltalk vmParameterAt: 1) + bytes asInteger.
- 	Smalltalk vmParameterAt: 67 put: ((Smalltalk vmParameterAt: 1) + bytes asInteger min: SmallInteger maxVal).
  	^aBlock ensure: [Smalltalk vmParameterAt: 67 put: extantLimit]!


From tim at rowledge.org  Fri Jul 17 21:48:49 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 17 Jul 2020 14:48:49 -0700
Subject: [squeak-dev] squeak.sh appears unable to allow specifying a
	project/file
Message-ID: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>

We briefly touched on this at the last board meeting and I just got egg on my face trying to demonstrate how easy it was to run a Squeak commandline job.

The immediate problem is that the squeak.sh script included in the current linux-x64 package does not let us run things in the form -
./squeak.sh my.image my.st
because sometihng is making the VM see 'my.image my.st' as a single (bad) filename.
With the shell debugging turned on it seems the last line of the script 
exec "${VM}" "${IMAGE}"
is resulting in the eventual command being 
exec /home/tim/Squeak/{blah=blah}/bin/squeak 'my.image my.st'
If I manually run that line without the quotes around the image & st filenames it runs properly. I imagine the must be some magic tweak to the script that would solve this? Any suggestions anyone?

The equivalent script included in the development build VMs is completely different, doing interesting things related to GDB and LLDPATH and ... other stuff I don't understand. That also appears to wrap the image & st files in ' '.

The equivalent script in the all-in-one is again different and does some working out of which VM to run per the platform but doesn't look like it would handle the st file any better.

The matter discussed at the SOB was that none of them actually do anything akin to a 'proper unix install', which is in itself a can of parasitic brain worms I'd prefer to leave to other people. 

tl;dr - 
a) what magic would make the final command not have ' ' wrapped around the image & st filenames?
b) can we try to make a less confusing system of scripts and have it/them do better? Cue dtl to rant a little on this...

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: CDC: Clear Disks and Crash



From lists at fniephaus.com  Fri Jul 17 22:13:30 2020
From: lists at fniephaus.com (Fabio Niephaus)
Date: Sat, 18 Jul 2020 00:13:30 +0200
Subject: [squeak-dev] squeak.sh appears unable to allow specifying a
	project/file
In-Reply-To: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
References: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
Message-ID: <CADfnKi4XJ1KL-5N8fG_8ELi4t+VsXDxpGc-B=qDzopQZx9eisQ@mail.gmail.com>

On Fri, 17 Jul 2020 at 11:48 pm, tim Rowledge <tim at rowledge.org> wrote:

> We briefly touched on this at the last board meeting and I just got egg on
> my face trying to demonstrate how easy it was to run a Squeak commandline
> job.
>
> The immediate problem is that the squeak.sh script included in the current
> linux-x64 package does not let us run things in the form -
> ./squeak.sh my.image my.st
> because sometihng is making the VM see 'my.image my.st' as a single (bad)
> filename.
> With the shell debugging turned on it seems the last line of the script
> exec "${VM}" "${IMAGE}"
> is resulting in the eventual command being
> exec /home/tim/Squeak/{blah=blah}/bin/squeak 'my.image my.st'
> If I manually run that line without the quotes around the image & st
> filenames it runs properly. I imagine the must be some magic tweak to the
> script that would solve this? Any suggestions anyone?
>
> The equivalent script included in the development build VMs is completely
> different, doing interesting things related to GDB and LLDPATH and ...
> other stuff I don't understand. That also appears to wrap the image & st
> files in ' '.
>
> The equivalent script in the all-in-one is again different and does some
> working out of which VM to run per the platform but doesn't look like it
> would handle the st file any better.
>
> The matter discussed at the SOB was that none of them actually do anything
> akin to a 'proper unix install', which is in itself a can of parasitic
> brain worms I'd prefer to leave to other people.
>
> tl;dr -
> a) what magic would make the final command not have ' ' wrapped around the
> image & st filenames?


Dropping the quotes around ${IMAGE} should help in your case. IIRC we added
those quotes to allow paths with spaces. Looks like the script needs to do
a better job separating image from image args and passing them in correctly.


> b) can we try to make a less confusing system of scripts and have it/them
> do better? Cue dtl to rant a little on this...


The AIO bundles come with multiple VMs for Linux (x86 and arm32), so the
script needs to do some additional work. It'd still be good to reuse as
much of the common logic as possible.

Fabio


>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: CDC: Clear Disks and Crash
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/169c7b31/attachment.html>

From tim at rowledge.org  Fri Jul 17 22:29:56 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 17 Jul 2020 15:29:56 -0700
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <1594418688634-0.post@n4.nabble.com>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <1594418688634-0.post@n4.nabble.com>
Message-ID: <A8C54C44-C709-4038-8779-B6A565E426FF@rowledge.org>

After too many distractions, back to thinking a bit about this;



> On 2020-07-10, at 3:04 PM, Paul DeBruicker <pdebruic at gmail.com> wrote:
> 
> Toothpick should load and work in 5.3

Very nearly; some assumptions about DateAndTime that are no longer valid meant having to fix a few methods. I have a changeset or mcz to offer to solve that. All the tests now pass, though I was under the impression the ISO8601 time stamps were meant to include the timezone.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Put a lens in each ear and you've got a telescope.



From tim at rowledge.org  Fri Jul 17 22:40:25 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 17 Jul 2020 15:40:25 -0700
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <A8C54C44-C709-4038-8779-B6A565E426FF@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <1594418688634-0.post@n4.nabble.com>
 <A8C54C44-C709-4038-8779-B6A565E426FF@rowledge.org>
Message-ID: <13C54EA2-CE3F-4145-A9D0-872280BBAC4F@rowledge.org>

> 
> 
>> On 2020-07-10, at 3:04 PM, Paul DeBruicker <pdebruic at gmail.com> wrote:
>> 
>> Toothpick should load and work in 5.3

Oh, worth mentioning that the URL pointed to for more info (like doc?) is a 404 today.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
A conclusion is the place where you got tired of thinking.



From pdebruic at gmail.com  Fri Jul 17 22:51:58 2020
From: pdebruic at gmail.com (Paul DeBruicker)
Date: Fri, 17 Jul 2020 17:51:58 -0500 (CDT)
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <13C54EA2-CE3F-4145-A9D0-872280BBAC4F@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <1594418688634-0.post@n4.nabble.com>
 <A8C54C44-C709-4038-8779-B6A565E426FF@rowledge.org>
 <13C54EA2-CE3F-4145-A9D0-872280BBAC4F@rowledge.org>
Message-ID: <1595026318440-0.post@n4.nabble.com>

Yeah its a goner.  I don't know of a copy anywhere.  


timrowledge wrote
>> 
>> 
>>> On 2020-07-10, at 3:04 PM, Paul DeBruicker &lt;

> pdebruic@

> &gt; wrote:
>>> 
>>> Toothpick should load and work in 5.3
> 
> Oh, worth mentioning that the URL pointed to for more info (like doc?) is
> a 404 today.
> 
> tim
> --
> tim Rowledge; 

> tim@

> ; http://www.rowledge.org/tim
> A conclusion is the place where you got tired of thinking.





--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

From commits at source.squeak.org  Fri Jul 17 23:51:12 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Fri, 17 Jul 2020 23:51:12 0000
Subject: [squeak-dev] The Trunk: EToys-eem.399.mcz
Message-ID: <E1jwa8M-0001is-KD@andreas>

Eliot Miranda uploaded a new version of EToys to project The Trunk:
http://source.squeak.org/trunk/EToys-eem.399.mcz

==================== Summary ====================

Name: EToys-eem.399
Author: eem
Time: 17 July 2020, 4:51:05.430052 pm
UUID: dfb4916e-d9f3-40e7-8da2-2badb5372778
Ancestors: EToys-mt.398

Fix the WebCamMorph so that more than one camera can be used at the same time.

e,g, if you have a laptop with a secondary display attached with a camera (such as the Apple Cinema Display) you can do this:

WebCamMorph new cameraNumber: 2; openInWorld.
WebCamMorph new cameraNumber: 1; openInWorld.
WebCamMorph new cameraNumber: 2; openInWorld.
WebCamMorph new cameraNumber: 1; openInWorld.

position them around the display, change their size, and even give them rotation.  But interestingly adding rotation invokes the garbage collector since the warp form is not cached.

e.g.
GCs			5,066 (582.7 ms between GCs 314.9 ms runtime between GCs)
	full		245 totalling 221,724 ms (13.9% runtime), avg 905 ms
				marking		128,554 ms (58%) avg 524.7 ms,
				compacting	93,170 ms (42%) avg 380.3 ms
	scavenges	4,821 totalling 24,912 ms (1.56% runtime), avg 5.2 ms
	tenures		232,261 (avg 48 tenures per scavenge)

=============== Diff against EToys-mt.398 ===============

Item was added:
+ ----- Method: WebCamMorph>>cameraIsOn (in category 'accessing') -----
+ cameraIsOn
+ 	^camIsOn!

Item was added:
+ ----- Method: WebCamMorph>>cameraNumber (in category 'accessing') -----
+ cameraNumber
+ 	^camNum!

Item was added:
+ ----- Method: WebCamMorph>>cameraNumber: (in category 'accessing') -----
+ cameraNumber: anInteger
+ 	camNum ~= anInteger ifTrue:
+ 		[camNum := anInteger.
+ 		 self initializeDisplayForm]!

Item was changed:
  ----- Method: WebCamMorph>>delete (in category 'submorphs-add/remove') -----
  delete
+ 	self off.
+ 	super delete!
- 	self class instanceCount > 1
- 		ifFalse: [self off]
- 		ifTrue: [
- 			self stopStepping.
- 			camIsOn := false].
- 	super delete.!

Item was changed:
  ----- Method: WebCamMorph>>drawOn: (in category 'drawing') -----
  drawOn: aCanvas 
+ 	camIsOn ifFalse:
+ 		[self initializeDisplayForm.
+ 		 self on].
+ 	camIsOn ifTrue:
+ 		[(CameraInterface frameExtent: camNum) ~= displayForm extent ifTrue:
+ 			[self initializeDisplayForm]].
+ 	displayForm ifNil:
+ 		[self initializeDisplayForm].
- 
  	useFrameSize ifTrue: [self extent: frameExtent].
  	self drawCameraImageOn: aCanvas.
  	self drawFPSOn: aCanvas.
+ 	self drawOverlayTextOn: aCanvas!
- 	self drawOverlayTextOn: aCanvas.
- !

Item was changed:
  ----- Method: WebCamMorph>>initialize (in category 'initialization') -----
  initialize
  	super initialize.
  	camNum := 1.
  	camIsOn := false.
  	showFPS := false.
  	captureDelayMs := 16. "stepTime"	
  	fps := 60. "guess."
  	lastDisplayTime := 0.
  	framesSinceLastDisplay := 0.
  	useFrameSize := false.
  	resolution := #medium.
  	orientation := #natural.
+ 	frameExtent := self class resolutionFor: resolution!
- 	frameExtent := self class resolutionFor: resolution.
- 	self initializeDisplayForm.
- 	self extent: frameExtent.
- 	self on.
- 
- 	!

Item was changed:
  ----- Method: WebCamMorph>>off (in category 'accessing') -----
  off
  	self stopStepping.
  	camIsOn := false.
+ 	"Be careful not to close the camera if any other morphs are using the same camera."
+ 	(self class allInstances anySatisfy: [:wcm| wcm cameraNumber = camNum and: [wcm cameraIsOn]]) ifFalse:
+ 		[CameraInterface  closeCamera: camNum].
+ 	self changed
- 	self updateDisplay.
- 	CameraInterface  closeCamera: camNum.
  	
+ 	"self allInstances select: [:wcm| wcm cameraNumber = 1 and: [wcm cameraIsOn]]"!
- 
- 	
- !

Item was changed:
  ----- Method: WebCamMorph>>on (in category 'accessing') -----
  on
+ 	camIsOn ifTrue: [^true].
+ 	(CameraInterface cameraIsOpen: camNum) ifFalse:
+ 		[(CameraInterface openCamera: camNum width: frameExtent x height: frameExtent y) ifNil:
+ 			[^false]].
+ 	"The plugin/camera subsystem may end up choosing a different width and height.
+ 	 So use the width and height it has selected; it may not be what was asked for."
- 	
- 	(CameraInterface cameraIsOpen: camNum)
- 		ifTrue: [ ^camIsOn := true.].
- 	(CameraInterface openCamera: camNum width: frameExtent x height: frameExtent y)
- 		ifNil: [^false].
- 	CameraInterface waitForCameraStart: camNum.
  	self initializeDisplayForm.
+ 	CameraInterface waitForCameraStart: camNum.
- 	self extent: frameExtent.
  	camIsOn := true.
+ 	self startStepping!
- 	self startStepping.
- 	!


From tim at rowledge.org  Sat Jul 18 02:27:58 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 17 Jul 2020 19:27:58 -0700
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <1595026318440-0.post@n4.nabble.com>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <1594418688634-0.post@n4.nabble.com>
 <A8C54C44-C709-4038-8779-B6A565E426FF@rowledge.org>
 <13C54EA2-CE3F-4145-A9D0-872280BBAC4F@rowledge.org>
 <1595026318440-0.post@n4.nabble.com>
Message-ID: <34440E10-5B26-4F00-97B7-4F357CD74439@rowledge.org>



> On 2020-07-17, at 3:51 PM, Paul DeBruicker <pdebruic at gmail.com> wrote:
> 
> Yeah its a goner.  I don't know of a copy anywhere.  

Yay for the Wayback machine! Looks like they kept enough to build some doc pages on the squeaksource wiki.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Lightbulb over his head is burned out.



From tim at rowledge.org  Sat Jul 18 02:36:52 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 17 Jul 2020 19:36:52 -0700
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <34440E10-5B26-4F00-97B7-4F357CD74439@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <1594418688634-0.post@n4.nabble.com>
 <A8C54C44-C709-4038-8779-B6A565E426FF@rowledge.org>
 <13C54EA2-CE3F-4145-A9D0-872280BBAC4F@rowledge.org>
 <1595026318440-0.post@n4.nabble.com>
 <34440E10-5B26-4F00-97B7-4F357CD74439@rowledge.org>
Message-ID: <3BF013EE-990A-4417-9A41-352493379884@rowledge.org>



> On 2020-07-17, at 7:27 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
>> On 2020-07-17, at 3:51 PM, Paul DeBruicker <pdebruic at gmail.com> wrote:
>> 
>> Yeah its a goner.  I don't know of a copy anywhere.  
> 
> Yay for the Wayback machine! Looks like they kept enough to build some doc pages on the squeaksource wiki.

Hmm, that old doc implies the existence of socket, Windwos event, and 'user' logger classes. I wonder if anyone has ever kept a copy of those?


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
I'm so skeptical that I'm not sure I'm really a skeptic



From asqueaker at gmail.com  Sat Jul 18 02:41:40 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Fri, 17 Jul 2020 21:41:40 -0500
Subject: [squeak-dev] Installing metacello within a 'Smalltalk run:[]'
	fails
In-Reply-To: <alpine.DEB.2.02.2007161446320.14732@login03.caesar.elte.hu>
References: <7BAC259A-CC81-440E-9682-193F08F8E8DF@rowledge.org>
 <alpine.DEB.2.02.2007160354510.13842@login03.caesar.elte.hu>
 <2A126DD8-C987-40D7-8DBA-BA1290B3EDEC@rowledge.org>
 <alpine.DEB.2.02.2007161446320.14732@login03.caesar.elte.hu>
Message-ID: <CANzdToGzvJN7aq5iQqJ5O5_W3iPvMNJ18iAhOvby0+wH5PB+tw@mail.gmail.com>

Hi Tim and Levente,

IMO, the shortcoming is in the class library not strictly and clearly
defining a Notification as an output, while providing a separate, resumable
Request, for input.  Because of that, over time, clients (mis)used
Notification as a way to dynamically request input, with inconsistent use
of #defaultAction to either resume with a defaultValue, or pop up a UI that
simply *returns* a value (without resuming).

This has basically rendered any and all handling of Notification impossible
to be correct for all cases.  It has no way to tell them apart, which is
the responsibility of the signalers, not the handler.  So Notification
essentially became a catch-all common-superclass "categorizer"...
and a very bad one, at that.

As long as Notification>>#defaultAction remains

    ^nil

instead of

      self resume

then Smalltalk>>#run: *must* handle Notification, otherwise, what Tim said
would happen with headless apps, will happen.

Tim, I'm sure you've figured that those Metacello exceptions can be handled
within your run: block.  Something like:

Smalltalk run:
     [ ...
     [ ensureMetacello ] on: MetacelloNotification do: [ : noti | noti
defaultAction ].
     ... ]

I agree, you shouldn't have to, it'd be so much nicer if they'd inherited
from something besides Notification...

 - Chris


On Thu, Jul 16, 2020 at 7:50 AM Levente Uzonyi <leves at caesar.elte.hu> wrote:
>
> On Wed, 15 Jul 2020, tim Rowledge wrote:
>
> >
> >
> >> On 2020-07-15, at 7:09 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> >>
> >> On Wed, 15 Jul 2020, tim Rowledge wrote:
> >>
> >>> Running Installer ensureRecentMetacello works. (in a 5.3-19435 image)
> >>>
> >>> Wrapping it in Smalltalk run:[Installer ensureRecentMetacello ]
> >>> crashes. Specifically in
MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration'
is nil on the last line.
> >>> Seems a bit odd; possibly sometihng to do with the assorted exception
handling in the SmalltalkImage>run: code?
> >>
> >> I think the cause of the problem is that SmalltalkImage >> #run:
catches all Notifications, logs them, and finally #resumes them.
> >> But many Notifications override #defaultAction, and the return value
of that method will be the value the Notification normally returns with
when not handled.
> >> #resume does not send #defaultAction (it sends #defaultResumeValue,
which is rarely used).
> >
> > Sounds pretty likely to me. It's another of those 'fun' cases where one
tries to handle errors that you don't necessarily know how to handle.
Almost always a problem. I think I have a sigline about that mistake.
> >
> >
> >>
> >> IMO the code should not #resume the Notifications just #pass them, so
that they can return with whatever they want (or be handled by an outer
handler).
> >
> > Except that surely the problem then becomes that the default action of
many Notification type exceptions is to do some UI thing, and the entire
point of the run: stuff is to avoid that so it can be a commandline no-UI
activity. ;-)
>
> AFAIK that is why DummyUIManager exists. It lets you provide answers to
> these questions (via Notifications :)) or go with a default value if
> possible.
>
>
> Levente
>
> >
> > Is it a case of a different type of exception being the right way of
doing it within the metacello load code?  I see several Metacello exception
classes under Notification, mostly with #defaultAction returning a boolean.
Don't see any current exception class that really covers the 'give me a
default boolean answer' case.
> >
> > Exception handling is *such* fun!
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't
you dare erase my hard disk!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200717/42f0f41e/attachment.html>

From tim at rowledge.org  Sat Jul 18 04:59:09 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 17 Jul 2020 21:59:09 -0700
Subject: [squeak-dev] Installing metacello within a 'Smalltalk run:[]'
 fails
In-Reply-To: <CANzdToGzvJN7aq5iQqJ5O5_W3iPvMNJ18iAhOvby0+wH5PB+tw@mail.gmail.com>
References: <7BAC259A-CC81-440E-9682-193F08F8E8DF@rowledge.org>
 <alpine.DEB.2.02.2007160354510.13842@login03.caesar.elte.hu>
 <2A126DD8-C987-40D7-8DBA-BA1290B3EDEC@rowledge.org>
 <alpine.DEB.2.02.2007161446320.14732@login03.caesar.elte.hu>
 <CANzdToGzvJN7aq5iQqJ5O5_W3iPvMNJ18iAhOvby0+wH5PB+tw@mail.gmail.com>
Message-ID: <143C2104-5CD6-4AEE-9228-C2D20EE24603@rowledge.org>



> On 2020-07-17, at 7:41 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> IMO, the shortcoming is in the class library not strictly and clearly defining a Notification as an output, while providing a separate, resumable Request, for input.  

Yup. Pain, annoyance and time wasted. Sigh.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: SEXI: Sign EXtend Integer



From kksubbu.ml at gmail.com  Sat Jul 18 10:57:17 2020
From: kksubbu.ml at gmail.com (K K Subbu)
Date: Sat, 18 Jul 2020 16:27:17 +0530
Subject: [squeak-dev] squeak.sh appears unable to allow specifying a
 project/file
In-Reply-To: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
References: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
Message-ID: <44f6c9d6-0334-678b-7c1a-ddace2183c83@gmail.com>

On 18/07/20 3:18 am, tim Rowledge wrote:
> The immediate problem is that the squeak.sh script included in the
> current linux-x64 package does not let us run things in the form - 
> ./squeak.sh my.image my.st
Tim,

This was patched recently. Does the version below solve your problem?

https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/templates/linux/squeak.sh

HTH .. Subbu

From robert.withers at pm.me  Sat Jul 18 11:09:04 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sat, 18 Jul 2020 11:09:04 +0000
Subject: [squeak-dev] squeak.sh appears unable to allow specifying a
	project/file
In-Reply-To: <44f6c9d6-0334-678b-7c1a-ddace2183c83@gmail.com>
References: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
 <44f6c9d6-0334-678b-7c1a-ddace2183c83@gmail.com>
Message-ID: <d563db54-1b20-5b37-cdf6-69b29c79d58a@pm.me>

Hi Subbu,

On 7/18/20 6:57 AM, K K Subbu wrote:
> On 18/07/20 3:18 am, tim Rowledge wrote:
>> The immediate problem is that the squeak.sh script included in the
>> current linux-x64 package does not let us run things in the form -
>> ./squeak.sh my.image my.st
> Tim,
>
> This was patched recently. Does the version below solve your problem?
>
> https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/templates/linux/squeak.sh

Would there be any chance of modifying the script to open a file chooser 
dialog so the user can select the image s/he wants to run? There is a 
squeak.sh out there somewhere that does this.

Kindly,
rabbit

>
> HTH .. Subbu
>


From kksubbu.ml at gmail.com  Sat Jul 18 11:32:51 2020
From: kksubbu.ml at gmail.com (K K Subbu)
Date: Sat, 18 Jul 2020 17:02:51 +0530
Subject: [squeak-dev] squeak.sh appears unable to allow specifying a
 project/file
In-Reply-To: <d563db54-1b20-5b37-cdf6-69b29c79d58a@pm.me>
References: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
 <44f6c9d6-0334-678b-7c1a-ddace2183c83@gmail.com>
 <d563db54-1b20-5b37-cdf6-69b29c79d58a@pm.me>
Message-ID: <7e701467-e52f-05bf-f682-c67a7abf8135@gmail.com>

On 18/07/20 4:39 pm, Robert Withers wrote:
>> This was patched recently. Does the version below solve your problem?
>>
>> https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/templates/linux/squeak.sh
> Would there be any chance of modifying the script to open a file chooser
> dialog so the user can select the image s/he wants to run? There is a
> squeak.sh out there somewhere that does this.

The script uses a file dialog only when required. It is skipped if an 
image file is specified in the command line or a single image is found 
in the shared/ directory or through SQUEAK_IMAGE env variable.

You can force a dialog by removing the if check in ensure_image function 
in the script. or, move the *.image/*.changes file out of shared/ directory.

If you are developing an GUI app around Squeak, it is better to use XDG 
*.desktop/*.mime files. Then you can either drag/drop an image onto the 
app icon or open an image file through the file manager. They are very 
easy to create. Let me know if you need examples.

Regards .. Subbu

From robert.withers at pm.me  Sat Jul 18 11:50:59 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sat, 18 Jul 2020 11:50:59 +0000
Subject: [squeak-dev] Short Stack exception presentation (was Re: Dual
	screen?)
In-Reply-To: <6085c2c4-a33c-63c7-0a6d-a90b87ef7fdd@pm.me>
References: <5a557920-e941-2d62-5144-c6993550d90d@pm.me>
 <6BB60895-1A09-4F85-AFDD-0AD6E7C11E41@rowledge.org>
 <88caa1b0-25b4-2fb3-e53a-6144ae7e0077@pm.me>
 <f7466948-31f8-b397-55df-d25bf6d9b890@pm.me>
 <6085c2c4-a33c-63c7-0a6d-a90b87ef7fdd@pm.me>
Message-ID: <9ce2ed00-99b4-cfd7-d731-abe2e49fa185@pm.me>

Hi everyone,

Thanks to a response on the Squeak Slack channel, I was able to get most of this done by calling a pre-existing method. Please run:

> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.

Oh! Marcel, this is precisely what I needed, it is already done! I changed the EventualMessageSend>>#value to call this code you shared. StandardToolSet debugException: ex.I run this script to test:(1 eventual / 0) explore.
1 eventual explore.The first line results in an exception and we get a exception notifier and also an explorer on the PromisERef. The promise is resolved to an exception and it #becomes a BrokenERef.

In looking into the exception notifier and the exception browser is that the top frame is the signaler context. Perfect.

The second line validates that the event loop is unblocked. This results in a second inspector on a near value of 1.

The only remaining work is that when proceeded, the exception will reschedule the stack into the vat's queue.

Kindly,
rabbit

On 7/12/20 1:38 PM, Robert Withers wrote:

> On 6/26/20 2:37 PM, Robert Withers wrote:
>
>> On 6/26/20 1:55 PM, Robert Withers wrote:
>>
>>> Closer to my heart, at this point are my questions and request for help
>>> in splitting off a pruned stack for an exception, to unblock the event
>>> loop yet still allow introspection of an error, or a halt. Here is what
>>> I wrote. Tim, might you be able to advise me here?
>>>
>>> *
>>>
>>> lost
>>>
>>> *
>>>
>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-June/210452.html
>
> The requirements for exceptions within an event loop are:
>
> - Copy stack
> - Restart eventLoop
> - Prune stack/Create Continuation
> - Open Debugger
> - When Proceeded, reschedule EventualMessageSend, on the Continuation, in the vat queue.
>
> Would someone please help me here? I am a little lost. I appreciate you!
>
> Kindly,
> rabbit
>
>> Not only do I want this, but the short stack, when Proceeded, should reschedule an eventual message on the event loop to reintroduce this short stack back into event loop land. As such, i was thinking perhaps a continuation could enable this. Liekwise, when a exception is thrown, do these steps:
>>
>>> - Modify the Vat to have a an active stack, a priority queue and a vat-aware continuation pool.
>>> - Copy the stack. Does this mean create a special continuation, that is event loop aware?
>>> - Resume the event loop by discarding the previous event handling exception.
>>> - Prune the stack (of the continuation). above and below. Site of signaled exception.
>>> - Open a Debugger
>>> - On Proceed, reschedule the eventual message in the Vat's queue.
>>
>> I have no idea what B looks like. Outside of my experience doing continuations and stack manipulation and pool scheduling. I need a VatSemaphore (please peruse the ResultSemaphore in PromisesRemote). I pray someone may swoop in with solutions!
>>
>> Kindly,
>> rabbit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/4253843d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NearERef-1.jpg
Type: image/jpeg
Size: 12143 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/4253843d/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Exception-browser-ZeroDivide.jpg
Type: image/jpeg
Size: 75886 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/4253843d/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Exception-notifier-ZeroDivide.jpg
Type: image/jpeg
Size: 21199 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/4253843d/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BrokenERef.jpg
Type: image/jpeg
Size: 13680 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/4253843d/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PromiseERef.jpg
Type: image/jpeg
Size: 13328 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/4253843d/attachment-0009.jpg>

From forums.jakob at resfarm.de  Sat Jul 18 12:10:32 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Sat, 18 Jul 2020 14:10:32 +0200
Subject: [squeak-dev] Installing metacello within a 'Smalltalk run:[]'
	fails
In-Reply-To: <CANzdToGzvJN7aq5iQqJ5O5_W3iPvMNJ18iAhOvby0+wH5PB+tw@mail.gmail.com>
References: <7BAC259A-CC81-440E-9682-193F08F8E8DF@rowledge.org>
 <alpine.DEB.2.02.2007160354510.13842@login03.caesar.elte.hu>
 <2A126DD8-C987-40D7-8DBA-BA1290B3EDEC@rowledge.org>
 <alpine.DEB.2.02.2007161446320.14732@login03.caesar.elte.hu>
 <CANzdToGzvJN7aq5iQqJ5O5_W3iPvMNJ18iAhOvby0+wH5PB+tw@mail.gmail.com>
Message-ID: <CA+ovNC7yTnQ__iY_QOhJF8hvwvXeoarBOM4ndB2sDtqweNwFPA@mail.gmail.com>

Chris Muller <asqueaker at gmail.com> schrieb am Sa., 18. Juli 2020, 04:42:

>
> As long as Notification>>#defaultAction remains
>
>     ^nil
>
> instead of
>
>       self resume
>
> then Smalltalk>>#run: *must* handle Notification, otherwise, what Tim
> said would happen with headless apps, will happen.
>

resume must not be called from defaultAction according to the ANSI
standard. Squeak may differ, but having this in the class library would set
a bad example for applications that implement their own notifications.
Notifications resume by default anyway if not curtailed. The return value
of defaultAction will be the resume value. So maybe it should read ^ self
defaultResumeValue, or the latter selector should not exist in the library
classes.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/2b61696d/attachment.html>

From robert.withers at pm.me  Sat Jul 18 12:25:33 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sat, 18 Jul 2020 12:25:33 +0000
Subject: [squeak-dev] Short Stack exception presentation (was Re: Dual
	screen?)
In-Reply-To: <9ce2ed00-99b4-cfd7-d731-abe2e49fa185@pm.me>
References: <5a557920-e941-2d62-5144-c6993550d90d@pm.me>
 <6BB60895-1A09-4F85-AFDD-0AD6E7C11E41@rowledge.org>
 <88caa1b0-25b4-2fb3-e53a-6144ae7e0077@pm.me>
 <f7466948-31f8-b397-55df-d25bf6d9b890@pm.me>
 <6085c2c4-a33c-63c7-0a6d-a90b87ef7fdd@pm.me>
 <9ce2ed00-99b4-cfd7-d731-abe2e49fa185@pm.me>
Message-ID: <316c8d49-4039-f617-a8cf-91d22305e62f@pm.me>

Strange issue. I found one of the tests is failing, run from the TestRunner. RefsTest>>#testBlockClosure is failing for an unknown reason. I ran the tests from the browser menu and they all pass. There is no failure running or debugging from the Browser. Very strange.

K, r

On 7/18/20 7:50 AM, Robert Withers via Squeak-dev wrote:

> Hi everyone,
>
> Thanks to a response on the Squeak Slack channel, I was able to get most of this done by calling a pre-existing method. Please run:
>
>> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.
>
> Oh! Marcel, this is precisely what I needed, it is already done! I changed the EventualMessageSend>>#value to call this code you shared. StandardToolSet debugException: ex.I run this script to test:(1 eventual / 0) explore.
> 1 eventual explore.The first line results in an exception and we get a exception notifier and also an explorer on the PromisERef. The promise is resolved to an exception and it #becomes a BrokenERef.
>
> In looking into the exception notifier and the exception browser is that the top frame is the signaler context. Perfect.
>
> The second line validates that the event loop is unblocked. This results in a second inspector on a near value of 1.
>
> The only remaining work is that when proceeded, the exception will reschedule the stack into the vat's queue.
>
> Kindly,
> rabbit
>
> On 7/12/20 1:38 PM, Robert Withers wrote:
>
>> On 6/26/20 2:37 PM, Robert Withers wrote:
>>
>>> On 6/26/20 1:55 PM, Robert Withers wrote:
>>>
>>>> Closer to my heart, at this point are my questions and request for help
>>>> in splitting off a pruned stack for an exception, to unblock the event
>>>> loop yet still allow introspection of an error, or a halt. Here is what
>>>> I wrote. Tim, might you be able to advise me here?
>>>>
>>>> *
>>>>
>>>> lost
>>>>
>>>> *
>>>>
>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-June/210452.html
>>
>> The requirements for exceptions within an event loop are:
>>
>> - Copy stack
>> - Restart eventLoop
>> - Prune stack/Create Continuation
>> - Open Debugger
>> - When Proceeded, reschedule EventualMessageSend, on the Continuation, in the vat queue.
>>
>> Would someone please help me here? I am a little lost. I appreciate you!
>>
>> Kindly,
>> rabbit
>>
>>> Not only do I want this, but the short stack, when Proceeded, should reschedule an eventual message on the event loop to reintroduce this short stack back into event loop land. As such, i was thinking perhaps a continuation could enable this. Liekwise, when a exception is thrown, do these steps:
>>>
>>>> - Modify the Vat to have a an active stack, a priority queue and a vat-aware continuation pool.
>>>> - Copy the stack. Does this mean create a special continuation, that is event loop aware?
>>>> - Resume the event loop by discarding the previous event handling exception.
>>>> - Prune the stack (of the continuation). above and below. Site of signaled exception.
>>>> - Open a Debugger
>>>> - On Proceed, reschedule the eventual message in the Vat's queue.
>>>
>>> I have no idea what B looks like. Outside of my experience doing continuations and stack manipulation and pool scheduling. I need a VatSemaphore (please peruse the ResultSemaphore in PromisesRemote). I pray someone may swoop in with solutions!
>>>
>>> Kindly,
>>> rabbit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/a2810e43/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NearERef-1.jpg
Type: image/jpeg
Size: 12143 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/a2810e43/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Exception-browser-ZeroDivide.jpg
Type: image/jpeg
Size: 75886 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/a2810e43/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Exception-notifier-ZeroDivide.jpg
Type: image/jpeg
Size: 21199 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/a2810e43/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BrokenERef.jpg
Type: image/jpeg
Size: 13680 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/a2810e43/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PromiseERef.jpg
Type: image/jpeg
Size: 13328 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/a2810e43/attachment-0009.jpg>

From robert.withers at pm.me  Sat Jul 18 16:35:03 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sat, 18 Jul 2020 16:35:03 +0000
Subject: [squeak-dev] On the rejection of Promises due to errors
In-Reply-To: <b92c0061-5bfd-d008-5339-b77ca4f353fa@pm.me>
References: <CA+ovNC5FrMheX9rPNv=Yqj00_Cpo4y76Yd2Dc+G56uM-AG0BeA@mail.gmail.com>
 <b92c0061-5bfd-d008-5339-b77ca4f353fa@pm.me>
Message-ID: <12dc9626-d501-2838-ec57-cbc3485fd700@pm.me>

Hi Jakob,

Whew! I got her done! Exceptions now work with the event loop in the Vat. Using a suggestion from the Squeak Slack channel, I am using StandardToolSet>>#debugEventualException:, a method I defined in PromisesLocal, modifying #debugException:, called from EventualMessageSend>>#value, on Exception. Yay!

> - Unblocks the event loop and discards the exception in this context.
> - Resolves the promise to broken.
> - Displays a Debugger on the signaler context, pruned.
> - Debugger is proceedable, and schedules the context back into the vat for resumption on the event loop process.

I intend to ask you your view of PromisesLocal as adhering to Promises A+ standard. With #whenResolved: & #whenRejected: this implementation has the equivalent of #then:. Exceptions are captured and linked back to the Vat it came from.

> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.

Then run this script:

> (1 eventual / 0) explore.
> 1 eventual explore.

You should get two explorers on ERefs ( 1 PromiseERef that #become: a BrokenERef and one NearERef) and one Debugger on ZeroDivide. The second line guarantees the event loop is not blocked.

I am working on ASN1 encoding of Remote Promise objects (EventualMessage & EventualDesc), so they can be bit identical between Squeak & Java. Bringing remote capabilities, following the Promise A+ specification.

Since you were working with Futures in Squeak, I welcome your views on this implementation.

Kindly,
rabbit

On 6/21/20 5:53 PM, Robert Withers wrote:

> Hi Jakob,
>
> I also have a promises implementation for Squeak and Java, that was derived from ERights, which precedes the JavaScript impl, both by Mark Miller. They do NOT throw up exceptions but they do resolve the promise to a BrokenERef, encapsulating the exception.
>
> You can load the following and run the tests.
>
>> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.
>
> Then I converted the first code you presented as the following.
>
>> promise := 1 eventual / 0.
>>
>> Number compile: 'methodWithTypo ^ self asstring'.
>> promise := 1 eventual methodWithTypo.
>
> They both resolve to BrokenERefs.
>
> I got a little lost in capturing exceptions, within the Vat's event loop #processSends. I have tickled my implementation a little to try and get the Vat event thread to throw an exception, which presents a Debugger. I have been unable to pop up the Debugger on the error, but the promise does get smashed.
>
> These Promises also pipelines the failure to subsequent message sends, with subsequent broken promises. So this also breaks with ZeroDivide.
>
>> (1 eventual / 0) * 10.
>
> Here are the immediate promise return and the smashed promise to a BrokenERef.
>
> Kindly,
> Robert
>
> On 6/21/20 4:57 PM, Jakob Reschke wrote:
>
>> Hi all,
>>
>> Tony has recently fixed our Promise implementation to make it more
>> Promises/A+ compliant, thank you!
>>
>> In the discussion that lead to this fix [1], I already pointed out a
>> difference between exceptions in Smalltalk and in JavaScript, where
>> the Promises/A+ specification originates: Smalltalk exceptions can be
>> resumed, while JavaScript exceptions cannot be resumed and always
>> unroll the stack.
>>
>> The spec [2] says that if the onFulfilled or onRejected callback of a
>> #then call on a promise throws an exception, then the promise returned
>> by the #then call shall be rejected with the exception thrown.
>>
>> Our current Promise implementation matches this for the blocks
>> supplied to #then:, #ifRejected: or #then:ifRejected, by catching all
>> Errors in the blocks and rejecting the promise. But this does not
>> allow a Squeak user to deal with exceptions in a debugger if they are
>> signalled in the callbacks, because they are caught. The same also
>> applies to #future promises. The latter are not really covered by the
>> Promises/A+ spec (because it does not force the resolution or
>> rejection of a promise that is not the result of a #then, and there is
>> no #future in JavaScript), but futures exhibit the same problem of not
>> being resumable in the debugger. Example:
>>
>> promise := 1 future / 0. "<= inspect it => promise is rejected,
>> regardless of your actions in the debugger"
>> Number compile: 'methodWithTypo  ^ self asstring'.
>> promise := 1 future methodWithTypo. "<= inspect it => promise is
>> rejected, no chance to fix the misspelling of asString in the debugger
>> and proceed"
>>
>> I could imagine instead letting all exceptions pass during the future
>> or callback block evaluation, and only reject the promise if the
>> evaluation is eventually curtailed due to the exception (be it an
>> Error or not, think of Warning or ModificationForbidden). Example
>> expectations:
>>
>> promise := 1 future / 0. "<= inspect it, press Proceed in the
>> debugger, => promise is resolved"
>> promise := 1 future / 0. "<= inspect it, press Abandon in the
>> debugger, => promise is rejected"
>> promise := 1 future methodWithTypo. "<= inspect it, fix the typo of
>> asString in the debugger, proceed, => promise is resolved with '1'"
>>
>> It could be done by fulfilling a Promise about aBlock similar to this:
>>
>> [ self resolveWith: aBlock value ]
>>    on: Exception
>>    do: [ :ex | | resumed |
>>       resumed := false.
>>       [ | result |
>>       result := ex outer.
>>       resumed := true.
>>       ex resume: result]
>>          ifCurtailed: [resumed ifFalse: [self future rejectWith: ex]]]
>>
>> (Find the current implementations here:
>> Promise>>#fulfillWith:passErrors: and Promise>>#then:ifRejected:)
>>
>> Note that the #outer send would only trigger handlers in the
>> Project/World loop, or the defaultAction of the exception. The #future
>> in front of #rejectWith: is there to avoid curtailing the unwind block
>> context of ifCurtailed: itself if there are further errors in the
>> rejection callbacks of the promise. The behavior of non-local exits
>> from unwind contexts is undefined in the Smalltalk ANSI standard (just
>> like resume: or return: in a defaultAction, or not sending resume: or
>> return: in an on:do: exception handler at all -- VA Smalltalk
>> interprets that as resume, while Squeak does return, for example).
>>
>> This implementation would also allow all deferred Notifications to
>> pass and not reject the promise. That is because true notifications
>> just resume silently if they are not handled.
>>
>> promise := [Notification signal: 'hi there'. 42] future value. "<=
>> inspect it => Expected: resolved with 42. Actual (today): it is
>> needlessly rejected with Notification 'hi there'"
>>
>> Pressing Proceed in the debugger on officially non-resumable errors
>> (which is possible) would also not reject the promise. But further
>> errors/debuggers are likely to appear, of which one may eventually be
>> used to abort the execution. If the execution finishes after
>> repeatedly pressing Proceed, then fine, resolve the promise with
>> whatever the outcome was.
>>
>> promise := [self error: 'Fatal error'. 42] future value. "<= inspect
>> it, proceed after the so-called fatal error, => Expected: resolved
>> with 42. Actual: there is no debugger, the promise is immediately
>> rejected."
>>
>> promise := [1 / 0 + 3] future value. "<= Cannot be resumed/proceeded
>> because if ZeroDivide is resumed, it will return the exception, and
>> ZeroDivide does not understand +, which cannot be resumed without
>> changing the code. So you'd have to curtail the block execution =>
>> Expected: rejected with ZeroDivide or MessageNotUnderstood (depending
>> on when you press Abandon or recompile the DoIt)."
>>
>> promise := [1 / 0 + 3] future value. "... or instead of changing the
>> code or aborting, you could choose 'return entered value' in one of
>> the debuggers, and thereby complete the evaluation of the block =>
>> Expected: resolved with whatever you entered to return in the
>> debugger"
>>
>> Promises with whenRejected:/ifRejected: callbacks would no longer
>> swallow errors, and would only be rejected when the user aborts in the
>> debuggers, or if the future execution catches errors by itself and
>> converts them to rejected promises, so the future promise will also be
>> rejected. This could pose a compatibility problem for existing code.
>>
>> promise := (1 future / 0) then: [:result | result + 3] ifRejected:
>> [:reason | #cancelled]. "<= inspect it => Actual: resolved with
>> #cancelled immediately. Expected with my proposed changes: it would
>> first show the ZeroDivide debugger, which you can abandon to resolve
>> with #cancelled, or proceed to a MessageNotUnderstood +. If you
>> abandon the MNU, the promise would be rejected with the MNU, not
>> #cancelled, in accordance with the Promises/A+ spec."
>>
>> How to get back a catch-all->reject-immediately future under these
>> circumstances:
>>
>> promise := [[1 / 0] on: Error do: [:e | e return: (Promise new
>> rejectWith: e)]] future value.
>> promise := [1 future + 1 then: [:n | [n / 0] on: Error do: [:e | e
>> return: (Promise new rejectWith: e)]] future value.
>>
>> We could also introduce a convenience constructor for
>> immediately-rejected promises like in JavaScript: Promise rejected: e.
>> Or a convenience exception handler: [...] rejectOn: Error.  Or [...]
>> rejectIfCurtailed (the fullfill/then methods would probably use this
>> as well).
>>
>> What do you think?
>>
>> As Tom Beckmann has already suggested in the last thread on the topic
>> [1], I could also use a custom class of Promise to get just the
>> behavior I want. But then I cannot solve it for the use of #future. At
>> least not without patching something about the compiler in my package
>> preamble... ;-)
>>
>> [1]
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208546.html
>> [2]
>> https://promisesaplus.com/
>> Kind regards,
>> Jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/7062a6f1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BrokenERef.jpeg
Type: image/jpeg
Size: 13669 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/7062a6f1/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PromiseERef.jpeg
Type: image/jpeg
Size: 14586 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/7062a6f1/attachment-0001.jpeg>

From commits at source.squeak.org  Sat Jul 18 17:47:17 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Sat, 18 Jul 2020 17:47:17 0000
Subject: [squeak-dev] The Inbox: MonticelloConfigurations-RJT.163.mcz
Message-ID: <E1jwqve-0008Dh-1r@andreas>

A new version of MonticelloConfigurations was added to project The Inbox:
http://source.squeak.org/inbox/MonticelloConfigurations-RJT.163.mcz

==================== Summary ====================

Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticell Configurations so that it automatically selects the package that is moved.  This allows you to push the button more than once without having to select the package again.

=============== Diff against MonticelloConfigurations-mt.162 ===============

Item was changed:
  ----- Method: MCConfigurationBrowser>>down (in category 'actions') -----
  down
  	self canMoveDown ifTrue: [
  		self list swap: self index with: self index + 1.
- 		self index: self index + 1.
  		self changedList.
+ 		self index: self index + 1.
+ 
  	].
  !

Item was changed:
  ----- Method: MCConfigurationBrowser>>up (in category 'actions') -----
  up
  	self canMoveUp ifTrue: [
  		self list swap: self index with: self index - 1.
- 		self index: self index - 1.
  		self changedList.
+ 		self index: self index -1.
  	].!


From tim at rowledge.org  Sat Jul 18 17:49:04 2020
From: tim at rowledge.org (tim Rowledge)
Date: Sat, 18 Jul 2020 10:49:04 -0700
Subject: [squeak-dev] squeak.sh appears unable to allow specifying a
 project/file
In-Reply-To: <7e701467-e52f-05bf-f682-c67a7abf8135@gmail.com>
References: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
 <44f6c9d6-0334-678b-7c1a-ddace2183c83@gmail.com>
 <d563db54-1b20-5b37-cdf6-69b29c79d58a@pm.me>
 <7e701467-e52f-05bf-f682-c67a7abf8135@gmail.com>
Message-ID: <AC39EE47-C516-44E4-BA16-B92ECCB1D67F@rowledge.org>



> On 2020-07-18, at 4:32 AM, K K Subbu <kksubbu.ml at gmail.com> wrote:
> Let me know if you need examples.

I'd love some examples so that the info is 'on the record' in a place likely to get searched. Getting all this in the swiki would be a boon too.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Fractured Idiom:- QUIP PRO QUO - A fast retort



From ron at usmedrec.com  Sat Jul 18 17:55:19 2020
From: ron at usmedrec.com (Ron Teitelbaum)
Date: Sat, 18 Jul 2020 13:55:19 -0400
Subject: [squeak-dev] Fix for Monticello Configuration - Question about Inbox
Message-ID: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>

Hi All,

I Added a fix but not sure I did it correctly.  Inbox has other non merged
changes on it for Monticello Configurations.  Realized after the save that
the number it picked was a duplicate of other changes added to inbox.

my change: "
Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticello
Configurations so that it automatically selects the package that is moved.
This allows you to push the button more than once without having to select
the package again.
"

What should I have done in this situation?  Do we just pick a later version
number.  I'm assuming here that we do not merge in others changes to your
own change set.

Thanks for your help.

Ron Teitelbaum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/2123b04a/attachment.html>

From ron at usmedrec.com  Sat Jul 18 18:27:50 2020
From: ron at usmedrec.com (Ron Teitelbaum)
Date: Sat, 18 Jul 2020 14:27:50 -0400
Subject: [squeak-dev] Issue with classType on CompiledCode
Message-ID: <CAEzdQ-cZSHghvQOH1afEi1_q=kC9Z9wCWk0ZiBizmtu6gU5cog@mail.gmail.com>

Hi All,

Ran into a problem trying to load the subclass of ByteArray

CompiledCode

from Monticello Configuration.

It was stored with a typeOfClass of #data but CompiledCode returns
typeOfClass #compiledMethod.

I'm getting the error:

CompiledCode cannot be recompiled

from

Classbuilder >> validateSubclassFormat: newType from: oldClass forSuper:
newSuper extra: newInstSize.

Suggestions on how to fix this or should we
1) allow #data to #compiledMethod to succeed the validation?
2) Manually fix it and commit a new configuration.

Also I see that there are two updates on trunk.

update and
update.spur

Which configuration are we using?  Why are there two?

Thanks for your help!!

Ron Teitelbaum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/4a5f3e93/attachment.html>

From tim at rowledge.org  Sat Jul 18 18:29:52 2020
From: tim at rowledge.org (tim Rowledge)
Date: Sat, 18 Jul 2020 11:29:52 -0700
Subject: [squeak-dev] squeak.sh appears unable to allow specifying a
 project/file
In-Reply-To: <44f6c9d6-0334-678b-7c1a-ddace2183c83@gmail.com>
References: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
 <44f6c9d6-0334-678b-7c1a-ddace2183c83@gmail.com>
Message-ID: <E53F9909-F064-443D-A6C2-D9F24A43CCCD@rowledge.org>



> On 2020-07-18, at 3:57 AM, K K Subbu <kksubbu.ml at gmail.com> wrote:
> 
> On 18/07/20 3:18 am, tim Rowledge wrote:
>> The immediate problem is that the squeak.sh script included in the
>> current linux-x64 package does not let us run things in the form - ./squeak.sh my.image my.st
> Tim,
> 
> This was patched recently. Does the version below solve your problem?
> 
> https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/templates/linux/squeak.sh

Yes, it does. Good news!


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Aio, quantitas magna frumentorum est. = Yes, that is a very large amount of corn.



From tim at rowledge.org  Sat Jul 18 22:13:37 2020
From: tim at rowledge.org (tim Rowledge)
Date: Sat, 18 Jul 2020 15:13:37 -0700
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <3BF013EE-990A-4417-9A41-352493379884@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <1594418688634-0.post@n4.nabble.com>
 <A8C54C44-C709-4038-8779-B6A565E426FF@rowledge.org>
 <13C54EA2-CE3F-4145-A9D0-872280BBAC4F@rowledge.org>
 <1595026318440-0.post@n4.nabble.com>
 <34440E10-5B26-4F00-97B7-4F357CD74439@rowledge.org>
 <3BF013EE-990A-4417-9A41-352493379884@rowledge.org>
Message-ID: <F5A6B21F-25F9-4525-A98E-00C45FDDB79D@rowledge.org>



> On 2020-07-17, at 7:36 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
>> 

>>> On 2020-07-17, at 3:51 PM, Paul DeBruicker <pdebruic at gmail.com> wrote:
>>> 
>>> Yeah its a goner.  I don't know of a copy anywhere.  
>> 
>> Yay for the Wayback machine! Looks like they kept enough to build some doc pages on the squeaksource wiki.
> 
> Hmm, that old doc implies the existence of socket, Windwos event, and 'user' logger classes. I wonder if anyone has ever kept a copy of those?

I've 'rescued' the available cod from the Wayback Machine and added it to the wiki pages attached to the squeaksource listing. I also noticed a possibly functional bit of code for syslog logging within Toothpick, which I will attempt to test sometime.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Life by Norman Rockwell, but screenplay by Stephen King.



From asqueaker at gmail.com  Sat Jul 18 22:30:37 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Sat, 18 Jul 2020 17:30:37 -0500
Subject: [squeak-dev] Installing metacello within a 'Smalltalk run:[]'
	fails
In-Reply-To: <CA+ovNC7yTnQ__iY_QOhJF8hvwvXeoarBOM4ndB2sDtqweNwFPA@mail.gmail.com>
References: <7BAC259A-CC81-440E-9682-193F08F8E8DF@rowledge.org>
 <alpine.DEB.2.02.2007160354510.13842@login03.caesar.elte.hu>
 <2A126DD8-C987-40D7-8DBA-BA1290B3EDEC@rowledge.org>
 <alpine.DEB.2.02.2007161446320.14732@login03.caesar.elte.hu>
 <CANzdToGzvJN7aq5iQqJ5O5_W3iPvMNJ18iAhOvby0+wH5PB+tw@mail.gmail.com>
 <CA+ovNC7yTnQ__iY_QOhJF8hvwvXeoarBOM4ndB2sDtqweNwFPA@mail.gmail.com>
Message-ID: <CANzdToG=xBfVHZG+aY4EraMRwYyf0C1uNn+amUs4CoTtaCw+Aw@mail.gmail.com>

Wow, I actually had to look that up, because I found it incredible, but, lo
and behold, there it is, under *5.5.4.5 Message: resume*.  Does anyone know
why ANSI considers it erroneous?

> Notifications resume by default anyway if not curtailed.

A signaled Notification which is never curtailed is nothing, negative
even.  Their value is derived by being handled.  But, if you try to handle
a Notification, you're basically forced to resume it if you want to retain
the nature as if you didn't handle it.  By not guarantee'ing resumption,
ANSI forces handlers and signalers to coordinate when they should be
decoupled.

> The return value of defaultAction will be the resume value. So maybe it
should read ^ self defaultResumeValue, or the latter selector should not
exist in the library  classes.

Squeak has a couple of places that've been sending #resume from
defaultAction since their inception.  My inclination would be to understand
what we want to get out of Notification before making any changes.

For me, a Notification is informational output from a program that should
*always* resume afterward and, therefore, whose defaultAction should be to
resume: self defaultResumeValue.  *Request* should be its own major sub
branch of *Notification* for input.

 - Chris


On Sat, Jul 18, 2020 at 7:10 AM Jakob Reschke <forums.jakob at resfarm.de>
wrote:

> Chris Muller <asqueaker at gmail.com> schrieb am Sa., 18. Juli 2020, 04:42:
>
>>
>> As long as Notification>>#defaultAction remains
>>
>>     ^nil
>>
>> instead of
>>
>>       self resume
>>
>> then Smalltalk>>#run: *must* handle Notification, otherwise, what Tim
>> said would happen with headless apps, will happen.
>>
>
> resume must not be called from defaultAction according to the ANSI
> standard. Squeak may differ, but having this in the class library would set
> a bad example for applications that implement their own notifications.
> Notifications resume by default anyway if not curtailed. The return value
> of defaultAction will be the resume value. So maybe it should read ^ self
> defaultResumeValue, or the latter selector should not exist in the library
> classes.
>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/df28cbb3/attachment-0001.html>

From asqueaker at gmail.com  Sat Jul 18 23:39:29 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Sat, 18 Jul 2020 18:39:29 -0500
Subject: [squeak-dev] Fix for Monticello Configuration - Question about
	Inbox
In-Reply-To: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
References: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
Message-ID: <CANzdToHf-fmArxnUm-wFh85M2817_i8bmTd00goZRRY=XAtumg@mail.gmail.com>

Generally, it's best for them to be based off of _some_ ancestor that's in
the trunk, and not one that's only in the inbox.

If you find you have an ancestor of one in the inbox, the Reparent button
before saving will let you choose an appropriate parent from the trunk
repository, just be sure to choose one which is *in its ancestry*.

 - Chris

On Sat, Jul 18, 2020 at 12:55 PM Ron Teitelbaum <ron at usmedrec.com> wrote:

> Hi All,
>
> I Added a fix but not sure I did it correctly.  Inbox has other non merged
> changes on it for Monticello Configurations.  Realized after the save that
> the number it picked was a duplicate of other changes added to inbox.
>
> my change: "
> Name: MonticelloConfigurations-RJT.163
> Author: RJT
> Time: 18 July 2020, 1:47:16.459316 pm
> UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
> Ancestors: MonticelloConfigurations-mt.162
>
> Fix the up and down button (to change the load order) of Monticello
> Configurations so that it automatically selects the package that is moved.
> This allows you to push the button more than once without having to select
> the package again.
> "
>
> What should I have done in this situation?  Do we just pick a later
> version number.  I'm assuming here that we do not merge in others changes
> to your own change set.
>
> Thanks for your help.
>
> Ron Teitelbaum
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/b70d3fa5/attachment.html>

From asqueaker at gmail.com  Sat Jul 18 23:39:29 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Sat, 18 Jul 2020 18:39:29 -0500
Subject: [squeak-dev] Fix for Monticello Configuration - Question about
	Inbox
In-Reply-To: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
References: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
Message-ID: <CANzdToHf-fmArxnUm-wFh85M2817_i8bmTd00goZRRY=XAtumg@mail.gmail.com>

Generally, it's best for them to be based off of _some_ ancestor that's in
the trunk, and not one that's only in the inbox.

If you find you have an ancestor of one in the inbox, the Reparent button
before saving will let you choose an appropriate parent from the trunk
repository, just be sure to choose one which is *in its ancestry*.

 - Chris

On Sat, Jul 18, 2020 at 12:55 PM Ron Teitelbaum <ron at usmedrec.com> wrote:

> Hi All,
>
> I Added a fix but not sure I did it correctly.  Inbox has other non merged
> changes on it for Monticello Configurations.  Realized after the save that
> the number it picked was a duplicate of other changes added to inbox.
>
> my change: "
> Name: MonticelloConfigurations-RJT.163
> Author: RJT
> Time: 18 July 2020, 1:47:16.459316 pm
> UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
> Ancestors: MonticelloConfigurations-mt.162
>
> Fix the up and down button (to change the load order) of Monticello
> Configurations so that it automatically selects the package that is moved.
> This allows you to push the button more than once without having to select
> the package again.
> "
>
> What should I have done in this situation?  Do we just pick a later
> version number.  I'm assuming here that we do not merge in others changes
> to your own change set.
>
> Thanks for your help.
>
> Ron Teitelbaum
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/b70d3fa5/attachment-0001.html>

From ron at usmedrec.com  Sun Jul 19 00:25:13 2020
From: ron at usmedrec.com (Ron Teitelbaum)
Date: Sat, 18 Jul 2020 20:25:13 -0400
Subject: [squeak-dev] Fix for Monticello Configuration - Question about
	Inbox
In-Reply-To: <CANzdToHf-fmArxnUm-wFh85M2817_i8bmTd00goZRRY=XAtumg@mail.gmail.com>
References: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
 <CANzdToHf-fmArxnUm-wFh85M2817_i8bmTd00goZRRY=XAtumg@mail.gmail.com>
Message-ID: <CAEzdQ-dub2MBgwC_G8a6E2DUiCSPCu7frjuGfGUv-P-Ju1czpg@mail.gmail.com>

Ok, thanks.

On Sat, Jul 18, 2020 at 7:39 PM Chris Muller <asqueaker at gmail.com> wrote:

> Generally, it's best for them to be based off of _some_ ancestor that's in
> the trunk, and not one that's only in the inbox.
>
> If you find you have an ancestor of one in the inbox, the Reparent button
> before saving will let you choose an appropriate parent from the trunk
> repository, just be sure to choose one which is *in its ancestry*.
>
>  - Chris
>
> On Sat, Jul 18, 2020 at 12:55 PM Ron Teitelbaum <ron at usmedrec.com> wrote:
>
>> Hi All,
>>
>> I Added a fix but not sure I did it correctly.  Inbox has other non
>> merged changes on it for Monticello Configurations.  Realized after the
>> save that the number it picked was a duplicate of other changes added to
>> inbox.
>>
>> my change: "
>> Name: MonticelloConfigurations-RJT.163
>> Author: RJT
>> Time: 18 July 2020, 1:47:16.459316 pm
>> UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
>> Ancestors: MonticelloConfigurations-mt.162
>>
>> Fix the up and down button (to change the load order) of Monticello
>> Configurations so that it automatically selects the package that is moved.
>> This allows you to push the button more than once without having to select
>> the package again.
>> "
>>
>> What should I have done in this situation?  Do we just pick a later
>> version number.  I'm assuming here that we do not merge in others changes
>> to your own change set.
>>
>> Thanks for your help.
>>
>> Ron Teitelbaum
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/e654a56e/attachment.html>

From ron at usmedrec.com  Sun Jul 19 00:25:13 2020
From: ron at usmedrec.com (Ron Teitelbaum)
Date: Sat, 18 Jul 2020 20:25:13 -0400
Subject: [squeak-dev] Fix for Monticello Configuration - Question about
	Inbox
In-Reply-To: <CANzdToHf-fmArxnUm-wFh85M2817_i8bmTd00goZRRY=XAtumg@mail.gmail.com>
References: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
 <CANzdToHf-fmArxnUm-wFh85M2817_i8bmTd00goZRRY=XAtumg@mail.gmail.com>
Message-ID: <CAEzdQ-dub2MBgwC_G8a6E2DUiCSPCu7frjuGfGUv-P-Ju1czpg@mail.gmail.com>

Ok, thanks.

On Sat, Jul 18, 2020 at 7:39 PM Chris Muller <asqueaker at gmail.com> wrote:

> Generally, it's best for them to be based off of _some_ ancestor that's in
> the trunk, and not one that's only in the inbox.
>
> If you find you have an ancestor of one in the inbox, the Reparent button
> before saving will let you choose an appropriate parent from the trunk
> repository, just be sure to choose one which is *in its ancestry*.
>
>  - Chris
>
> On Sat, Jul 18, 2020 at 12:55 PM Ron Teitelbaum <ron at usmedrec.com> wrote:
>
>> Hi All,
>>
>> I Added a fix but not sure I did it correctly.  Inbox has other non
>> merged changes on it for Monticello Configurations.  Realized after the
>> save that the number it picked was a duplicate of other changes added to
>> inbox.
>>
>> my change: "
>> Name: MonticelloConfigurations-RJT.163
>> Author: RJT
>> Time: 18 July 2020, 1:47:16.459316 pm
>> UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
>> Ancestors: MonticelloConfigurations-mt.162
>>
>> Fix the up and down button (to change the load order) of Monticello
>> Configurations so that it automatically selects the package that is moved.
>> This allows you to push the button more than once without having to select
>> the package again.
>> "
>>
>> What should I have done in this situation?  Do we just pick a later
>> version number.  I'm assuming here that we do not merge in others changes
>> to your own change set.
>>
>> Thanks for your help.
>>
>> Ron Teitelbaum
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/e654a56e/attachment-0001.html>

From eliot.miranda at gmail.com  Sun Jul 19 00:46:25 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Sat, 18 Jul 2020 17:46:25 -0700
Subject: [squeak-dev] Issue with classType on CompiledCode
In-Reply-To: <CAEzdQ-cZSHghvQOH1afEi1_q=kC9Z9wCWk0ZiBizmtu6gU5cog@mail.gmail.com>
References: <CAEzdQ-cZSHghvQOH1afEi1_q=kC9Z9wCWk0ZiBizmtu6gU5cog@mail.gmail.com>
Message-ID: <169C2D30-CD20-4816-9C9F-A8357C06B8F8@gmail.com>

Hi Ron,


> On Jul 18, 2020, at 11:28 AM, Ron Teitelbaum <Ron at usmedrec.com> wrote:
> 
> 
> Hi All,
> 
> Ran into a problem trying to load the subclass of ByteArray
> 
> CompiledCode
> 
> from Monticello Configuration.  
> 
> It was stored with a typeOfClass of #data but CompiledCode returns typeOfClass #compiledMethod.
> 
> I'm getting the error: 
> 
> CompiledCode cannot be recompiled
> 
> from 
> 
> Classbuilder >> validateSubclassFormat: newType from: oldClass forSuper: newSuper extra: newInstSize.
> 
> Suggestions on how to fix this or should we 
> 1) allow #data to #compiledMethod to succeed the validation?
> 2) Manually fix it and commit a new configuration.

I would look at specific changes to Monticello that allow CompiledMethod to load.  I believe there is no problem in current trunk.  You and I could take a look at this together tmrw.

> 
> Also I see that there are two updates on trunk.  
> 
> update and 
> update.spur 
> 
> Which configuration are we using? 

update

> Why are there two?

update.spur is historical and was required as we transitioned to Spur from 4.5 to 4.6.

> 
> Thanks for your help!!
> 
> Ron Teitelbaum 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200718/eacc93f6/attachment.html>

From tim at rowledge.org  Sun Jul 19 01:14:05 2020
From: tim at rowledge.org (tim Rowledge)
Date: Sat, 18 Jul 2020 18:14:05 -0700
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <F5A6B21F-25F9-4525-A98E-00C45FDDB79D@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <1594418688634-0.post@n4.nabble.com>
 <A8C54C44-C709-4038-8779-B6A565E426FF@rowledge.org>
 <13C54EA2-CE3F-4145-A9D0-872280BBAC4F@rowledge.org>
 <1595026318440-0.post@n4.nabble.com>
 <34440E10-5B26-4F00-97B7-4F357CD74439@rowledge.org>
 <3BF013EE-990A-4417-9A41-352493379884@rowledge.org>
 <F5A6B21F-25F9-4525-A98E-00C45FDDB79D@rowledge.org>
Message-ID: <AFD0F32F-9ED0-41B2-B0EA-AD3020D939C3@rowledge.org>



> On 2020-07-18, at 3:13 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
>> On 2020-07-17, at 7:36 PM, tim Rowledge <tim at rowledge.org> wrote:
>> 
>>> 
> 
>>>> On 2020-07-17, at 3:51 PM, Paul DeBruicker <pdebruic at gmail.com> wrote:
>>>> 
>>>> Yeah its a goner.  I don't know of a copy anywhere.  
>>> 
>>> Yay for the Wayback machine! Looks like they kept enough to build some doc pages on the squeaksource wiki.
>> 
>> Hmm, that old doc implies the existence of socket, Windwos event, and 'user' logger classes. I wonder if anyone has ever kept a copy of those?
> 
> I've 'rescued' the available cod

... so please feel free to chip in ....
OK, possibly a bit Brit-specific.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Noli me vocare, ego te vocabo = Don't call me, I'll call you.



From kksubbu.ml at gmail.com  Sun Jul 19 07:29:35 2020
From: kksubbu.ml at gmail.com (K K Subbu)
Date: Sun, 19 Jul 2020 12:59:35 +0530
Subject: [squeak-dev] squeak.sh appears unable to allow specifying a
 project/file
In-Reply-To: <AC39EE47-C516-44E4-BA16-B92ECCB1D67F@rowledge.org>
References: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
 <44f6c9d6-0334-678b-7c1a-ddace2183c83@gmail.com>
 <d563db54-1b20-5b37-cdf6-69b29c79d58a@pm.me>
 <7e701467-e52f-05bf-f682-c67a7abf8135@gmail.com>
 <AC39EE47-C516-44E4-BA16-B92ECCB1D67F@rowledge.org>
Message-ID: <510a3ceb-bf79-ae0e-e7af-1376773bbce6@gmail.com>

On 18/07/20 11:19 pm, tim Rowledge wrote:
>> On 2020-07-18, at 4:32 AM, K K Subbu<kksubbu.ml at gmail.com>  wrote: 
>> Let me know if you need examples.
> I'd love some examples so that the info is 'on the record' in a place
> likely to get searched. Getting all this in the swiki would be a boon
> too.

The XDG files depend on the package manager and desktop manager which is 
why I didn't add them to swiki.

Here are the files I use for Ubuntu 16.04 (64bit). I store squeak 
related launchers in /opt/share/bin to keep the OS and my apps on 
separate volumes, so I have to modify .xsessionrc to include this path. 
bashrc is not sufficient because GUI programs may not start a shell.
----- .xsessionrc ------
case "$PATH" in
	*/opt/share/bin:*) ;;
	*) PATH=/opt/share/bin:$PATH ;;
esac
------------------------
(Logout and login to read this .rc file)

I then copy squeak5.png icon into /usr/share/pixmaps and then install 
the desktop file with:

----- squeak-vm.desktop ----
[Desktop Entry]
Type=Application
Name=Squeak VM
Exec=run %F
Icon=squeak
Categories=Development;
MimeType=application/spur-image;application/cog-image;application/stack-image;application/squeak-image;application/cog64-image;application/spur64-image;application/squeak64-image
--------------------------
$ xdg-desktop install squeak-vm.desktop

The mimes are generated as explained in the thread:

  http://forum.world.st/magic-decode-for-image-files-td4941712.html

HTH .. Subbu

From giovanni at corriga.net  Sun Jul 19 10:01:23 2020
From: giovanni at corriga.net (Giovanni Corriga)
Date: Sun, 19 Jul 2020 11:01:23 +0100
Subject: [squeak-dev] UK Smalltalk User Group Meeting - Wednesday, July 29th
Message-ID: <CAJ3_VgaHWpmSba46ncRNcLqO-2Kt_s6UyifPM2CRz3qfqjdgkw@mail.gmail.com>

The next meeting of the UK Smalltalk User Group will be on Wednesday, July
29th.

Peter Svensson will present his work on Cloudsdk-st.

Cloudsdk-st (https://github.com/psvensson/cloudsdk-st) is an experiment in
ways to work with cloud deployment from a Smalltalk image.
Traditionally cloud deployments run 'out of band' in separate build scripts
or build/CI/CD systems. This project lets you define Docker images (using
Dockerfiles) for Smalltalk, send them to the build system of a cloud
provider directly and then choose what kind of service you want your image
to be (cloud function or long-running VM).
Currently it only supports Google Cloud and has a very rough UI. Future
plans include support for AWS and Azure as well as better feedback and a
Spec2 UI.


Given the current COVID-19 restrictions, this will be an online meeting
from home.

If you'd like to join us, please sign up in advance on the meeting's Meetup
page https://www.meetup.com/UKSTUG/events/cbklbrybckbdc/ to receive the
meeting details.

See you there!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200719/d1ce918a/attachment.html>

From robert.withers at pm.me  Sun Jul 19 12:56:09 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sun, 19 Jul 2020 12:56:09 +0000
Subject: [squeak-dev] On the rejection of Promises due to errors
In-Reply-To: <12dc9626-d501-2838-ec57-cbc3485fd700@pm.me>
References: <CA+ovNC5FrMheX9rPNv=Yqj00_Cpo4y76Yd2Dc+G56uM-AG0BeA@mail.gmail.com>
 <b92c0061-5bfd-d008-5339-b77ca4f353fa@pm.me>
 <12dc9626-d501-2838-ec57-cbc3485fd700@pm.me>
Message-ID: <feedc4ec-7e39-b7af-b494-7d3c991a0d75@pm.me>

Here's my images:

On 7/18/20 12:35 PM, Robert Withers wrote:

> Hi Jakob,
>
> Whew! I got her done! Exceptions now work with the event loop in the Vat. Using a suggestion from the Squeak Slack channel, I am using StandardToolSet>>#debugEventualException:, a method I defined in PromisesLocal, modifying #debugException:, called from EventualMessageSend>>#value, on Exception. Yay!
>
>> - Unblocks the event loop and discards the exception in this context.
>> - Resolves the promise to broken.
>> - Displays a Debugger on the signaler context, pruned.
>> - Debugger is proceedable, and schedules the context back into the vat for resumption on the event loop process.
>
> I intend to ask you your view of PromisesLocal as adhering to Promises A+ standard. With #whenResolved: & #whenRejected: this implementation has the equivalent of #then:. Exceptions are captured and linked back to the Vat it came from.
>
>> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.
>
> Then run this script:
>
>> (1 eventual / 0) explore.
>> 1 eventual explore.
>
> You should get two explorers on ERefs ( 1 PromiseERef that #become: a BrokenERef and one NearERef) and one Debugger on ZeroDivide. The second line guarantees the event loop is not blocked.
>
> I am working on ASN1 encoding of Remote Promise objects (EventualMessage & EventualDesc), so they can be bit identical between Squeak & Java. Bringing remote capabilities, following the Promise A+ specification.
>
> Since you were working with Futures in Squeak, I welcome your views on this implementation.
>
> Kindly,
> rabbit
>
> On 6/21/20 5:53 PM, Robert Withers wrote:
>
>> Hi Jakob,
>>
>> I also have a promises implementation for Squeak and Java, that was derived from ERights, which precedes the JavaScript impl, both by Mark Miller. They do NOT throw up exceptions but they do resolve the promise to a BrokenERef, encapsulating the exception.
>>
>> You can load the following and run the tests.
>>
>>> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.
>>
>> Then I converted the first code you presented as the following.
>>
>>> promise := 1 eventual / 0.
>>>
>>> Number compile: 'methodWithTypo ^ self asstring'.
>>> promise := 1 eventual methodWithTypo.
>>
>> They both resolve to BrokenERefs.
>>
>> I got a little lost in capturing exceptions, within the Vat's event loop #processSends. I have tickled my implementation a little to try and get the Vat event thread to throw an exception, which presents a Debugger. I have been unable to pop up the Debugger on the error, but the promise does get smashed.
>>
>> These Promises also pipelines the failure to subsequent message sends, with subsequent broken promises. So this also breaks with ZeroDivide.
>>
>>> (1 eventual / 0) * 10.
>>
>> Here are the immediate promise return and the smashed promise to a BrokenERef.
>>
>> Kindly,
>> Robert
>>
>> On 6/21/20 4:57 PM, Jakob Reschke wrote:
>>
>>> Hi all,
>>>
>>> Tony has recently fixed our Promise implementation to make it more
>>> Promises/A+ compliant, thank you!
>>>
>>> In the discussion that lead to this fix [1], I already pointed out a
>>> difference between exceptions in Smalltalk and in JavaScript, where
>>> the Promises/A+ specification originates: Smalltalk exceptions can be
>>> resumed, while JavaScript exceptions cannot be resumed and always
>>> unroll the stack.
>>>
>>> The spec [2] says that if the onFulfilled or onRejected callback of a
>>> #then call on a promise throws an exception, then the promise returned
>>> by the #then call shall be rejected with the exception thrown.
>>>
>>> Our current Promise implementation matches this for the blocks
>>> supplied to #then:, #ifRejected: or #then:ifRejected, by catching all
>>> Errors in the blocks and rejecting the promise. But this does not
>>> allow a Squeak user to deal with exceptions in a debugger if they are
>>> signalled in the callbacks, because they are caught. The same also
>>> applies to #future promises. The latter are not really covered by the
>>> Promises/A+ spec (because it does not force the resolution or
>>> rejection of a promise that is not the result of a #then, and there is
>>> no #future in JavaScript), but futures exhibit the same problem of not
>>> being resumable in the debugger. Example:
>>>
>>> promise := 1 future / 0. "<= inspect it => promise is rejected,
>>> regardless of your actions in the debugger"
>>> Number compile: 'methodWithTypo  ^ self asstring'.
>>> promise := 1 future methodWithTypo. "<= inspect it => promise is
>>> rejected, no chance to fix the misspelling of asString in the debugger
>>> and proceed"
>>>
>>> I could imagine instead letting all exceptions pass during the future
>>> or callback block evaluation, and only reject the promise if the
>>> evaluation is eventually curtailed due to the exception (be it an
>>> Error or not, think of Warning or ModificationForbidden). Example
>>> expectations:
>>>
>>> promise := 1 future / 0. "<= inspect it, press Proceed in the
>>> debugger, => promise is resolved"
>>> promise := 1 future / 0. "<= inspect it, press Abandon in the
>>> debugger, => promise is rejected"
>>> promise := 1 future methodWithTypo. "<= inspect it, fix the typo of
>>> asString in the debugger, proceed, => promise is resolved with '1'"
>>>
>>> It could be done by fulfilling a Promise about aBlock similar to this:
>>>
>>> [ self resolveWith: aBlock value ]
>>>    on: Exception
>>>    do: [ :ex | | resumed |
>>>       resumed := false.
>>>       [ | result |
>>>       result := ex outer.
>>>       resumed := true.
>>>       ex resume: result]
>>>          ifCurtailed: [resumed ifFalse: [self future rejectWith: ex]]]
>>>
>>> (Find the current implementations here:
>>> Promise>>#fulfillWith:passErrors: and Promise>>#then:ifRejected:)
>>>
>>> Note that the #outer send would only trigger handlers in the
>>> Project/World loop, or the defaultAction of the exception. The #future
>>> in front of #rejectWith: is there to avoid curtailing the unwind block
>>> context of ifCurtailed: itself if there are further errors in the
>>> rejection callbacks of the promise. The behavior of non-local exits
>>> from unwind contexts is undefined in the Smalltalk ANSI standard (just
>>> like resume: or return: in a defaultAction, or not sending resume: or
>>> return: in an on:do: exception handler at all -- VA Smalltalk
>>> interprets that as resume, while Squeak does return, for example).
>>>
>>> This implementation would also allow all deferred Notifications to
>>> pass and not reject the promise. That is because true notifications
>>> just resume silently if they are not handled.
>>>
>>> promise := [Notification signal: 'hi there'. 42] future value. "<=
>>> inspect it => Expected: resolved with 42. Actual (today): it is
>>> needlessly rejected with Notification 'hi there'"
>>>
>>> Pressing Proceed in the debugger on officially non-resumable errors
>>> (which is possible) would also not reject the promise. But further
>>> errors/debuggers are likely to appear, of which one may eventually be
>>> used to abort the execution. If the execution finishes after
>>> repeatedly pressing Proceed, then fine, resolve the promise with
>>> whatever the outcome was.
>>>
>>> promise := [self error: 'Fatal error'. 42] future value. "<= inspect
>>> it, proceed after the so-called fatal error, => Expected: resolved
>>> with 42. Actual: there is no debugger, the promise is immediately
>>> rejected."
>>>
>>> promise := [1 / 0 + 3] future value. "<= Cannot be resumed/proceeded
>>> because if ZeroDivide is resumed, it will return the exception, and
>>> ZeroDivide does not understand +, which cannot be resumed without
>>> changing the code. So you'd have to curtail the block execution =>
>>> Expected: rejected with ZeroDivide or MessageNotUnderstood (depending
>>> on when you press Abandon or recompile the DoIt)."
>>>
>>> promise := [1 / 0 + 3] future value. "... or instead of changing the
>>> code or aborting, you could choose 'return entered value' in one of
>>> the debuggers, and thereby complete the evaluation of the block =>
>>> Expected: resolved with whatever you entered to return in the
>>> debugger"
>>>
>>> Promises with whenRejected:/ifRejected: callbacks would no longer
>>> swallow errors, and would only be rejected when the user aborts in the
>>> debuggers, or if the future execution catches errors by itself and
>>> converts them to rejected promises, so the future promise will also be
>>> rejected. This could pose a compatibility problem for existing code.
>>>
>>> promise := (1 future / 0) then: [:result | result + 3] ifRejected:
>>> [:reason | #cancelled]. "<= inspect it => Actual: resolved with
>>> #cancelled immediately. Expected with my proposed changes: it would
>>> first show the ZeroDivide debugger, which you can abandon to resolve
>>> with #cancelled, or proceed to a MessageNotUnderstood +. If you
>>> abandon the MNU, the promise would be rejected with the MNU, not
>>> #cancelled, in accordance with the Promises/A+ spec."
>>>
>>> How to get back a catch-all->reject-immediately future under these
>>> circumstances:
>>>
>>> promise := [[1 / 0] on: Error do: [:e | e return: (Promise new
>>> rejectWith: e)]] future value.
>>> promise := [1 future + 1 then: [:n | [n / 0] on: Error do: [:e | e
>>> return: (Promise new rejectWith: e)]] future value.
>>>
>>> We could also introduce a convenience constructor for
>>> immediately-rejected promises like in JavaScript: Promise rejected: e.
>>> Or a convenience exception handler: [...] rejectOn: Error.  Or [...]
>>> rejectIfCurtailed (the fullfill/then methods would probably use this
>>> as well).
>>>
>>> What do you think?
>>>
>>> As Tom Beckmann has already suggested in the last thread on the topic
>>> [1], I could also use a custom class of Promise to get just the
>>> behavior I want. But then I cannot solve it for the use of #future. At
>>> least not without patching something about the compiler in my package
>>> preamble... ;-)
>>>
>>> [1]
>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208546.html
>>> [2]
>>> https://promisesaplus.com/
>>> Kind regards,
>>> Jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200719/78272952/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BrokenERef.jpeg
Type: image/jpeg
Size: 13669 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200719/78272952/attachment-0002.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PromiseERef.jpeg
Type: image/jpeg
Size: 14586 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200719/78272952/attachment-0003.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Exception-browser-ZeroDivide.jpg
Type: image/jpeg
Size: 75886 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200719/78272952/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Exception-notifier-ZeroDivide.jpg
Type: image/jpeg
Size: 21199 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200719/78272952/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NearERef-1.jpg
Type: image/jpeg
Size: 12143 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200719/78272952/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BrokenERef.jpg
Type: image/jpeg
Size: 13680 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200719/78272952/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PromiseERef.jpg
Type: image/jpeg
Size: 13328 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200719/78272952/attachment-0009.jpg>

From robert.withers at pm.me  Sun Jul 19 13:44:15 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sun, 19 Jul 2020 13:44:15 +0000
Subject: [squeak-dev] Interested in Kafka?
Message-ID: <ad0d24ca-eb79-b039-4bbb-7dac236fbe2b@pm.me>

Hi Everyone!

I am writing this email to see if there are any folks out there who know 
Kafka. I had heard of a wrapper to the producer and consumer interfaces, 
but I lost this knowledge. Is there any work done in Squeak with Kafka?

My idea that I would be recruiting for, if welcomed, would be to 
implement Kafka in Squeak. Start with defining the Log class and 
proceed. Is anyone interested? This is prime work in the area of big 
data, parallelized, fault-tolerant processing. Squeak can do this!

Is there any interest in this?

Kindly,
rabbit



From lewis at mail.msen.com  Sun Jul 19 16:26:21 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Sun, 19 Jul 2020 12:26:21 -0400
Subject: [squeak-dev] Support an updated image format number for Sista
In-Reply-To: <20200113143334.GA9638@shell.msen.com>
References: <20200113143334.GA9638@shell.msen.com>
Message-ID: <20200719162621.GA89267@shell.msen.com>

<bump>

Background:

Sista bytecodes have been supported in the VM (opensmalltalk-vm) for quite
some time. Shortly after the Squeak 5.3 release Sista became the default
bytecode set in the trunk image.

In Squeak trunk, Sista bytecodes can be activated (or deactivated) with
CompiledCode class>>useSista: aBoolean, which also calls the hook to inform
the VM of Sista bytecode usage:

	<primitive: 'primitiveMultipleBytecodeSetsActive'>
	
This optional primitive is intended to inform the VM that an alternate
bytecode set is (or is not) being used by the image, and the VM can use
this information to update the image format number (first few bytes of
the saved image file) to a new number that indicates that Sista or other
enhanced bytecode set support is required for that image. A proposed
implementation of the primitive for opensmalltalk-vm is in the VMMaker
inbox (VMMaker.oscog-dtl.2711).

An earlier follow-up discussion in this thread included the suggestion
of e.g.  a #primitiveAvailableBytecodeSets that would provide a list of
available bytecode sets to the image. This is also a good idea, but it is
not directly related to the intended use of #primitiveMultipleBytecodeSetsActive.
Perhaps it could be implemented as a zero-argument call to a single primitive,
such that a boolean argument informs the VM of multiple bytecodes active,
and calling primitiveMultipleBytecodeSetsActive without arguments would ask
the VM to tell the image what bytecode sets can be supported by that VM.

@eliot - are you still on board with this concept, and if so could you
please take a look at the inbox proposal? We discussed this in the last
Squeak board meeting, and the board remains supportive of the idea of
updating the image format number for the next Squeak release.

Thanks,
Dave


On Mon, Jan 13, 2020 at 09:33:34AM -0500, David T. Lewis wrote:
> Hi Eliot,
> 
> This is a belated follow up on earlier private discussion during a Squeak
> board meeting a few months ago, in which we agreed that identifying
> "Sista in use" in the image format number would be a useful thing to do.
> I previously added the documentation for this in ImageFormat-dtl.39.mcz
> (as well as the updated ckformat.c program to match).
> 
> Attached here is a change set that can be loaded into a VMMaker image to
> add VM support for setting and reading the updated image format numbers.
> Here I used a primitive to initially set or clear the "sista bit". There
> are other ways this could be done, but this at least gets us started
> with a working implementation.
> 
> By way of explanation, I am copying below both the change set preamble
> and the earlier ImageFormat commit notice:
> 
> ===
> 
>   Change Set:		VMM-Sista-bit-dtl
>   Date:			12 January 2020
>   Author:			David T. Lewis
>   
>   Let the image inform the interpreter that alternate bytecodes either are
>   or are not in use, and remember that setting when writing or reading the
>   image format number in a shapshot file header.
>   
>   Provide primitiveMultipleBytecodesActive to allow the setting to be updated
>   from the image. Expected usage is that the image can call this primitive
>   after recompiling with Systa bytecodes, or after reverting back. Note that
>   an alternative implemenation would be to use a VM parameter. The primitive
>   was chosen here because it can perform parameter checking and does not
>   require coordinated update the the VM parameter usage.
>   
>   Expected usage is that this feature will remain unused for some grace period
>   (perhaps a few months) during which an updated VM can be widely circulated.
>   After that period, images using Sista bytecodes may be safely saved with the
>   updated image format number indicating that multiple bytecodes are in use.
>   
>   This change set includes helper methods in SmalltalkImage for testing or
>   setting the multipleBytecodeSetsActive setting in the VM.
>   
>   Note the change set postscript which is necessary for initializing a class
>   variable prior to code generation.
> 
> ===
> 
>   Name: ImageFormat-dtl.37
>   Author: dtl
>   Time: 20 July 2019, 5:23:59.004 pm
>   UUID: 52b464d5-0bf7-4326-bde3-4f18ad70b239
>   Ancestors: ImageFormat-dtl.36
>   
>   Identify extended bytecodes for Sista in the image format number. Bit 10
>   identifies an image that contains extended bytecodes. Thus a 32 bit Spur
>   image is 6521, with Sista it is 7033, and a 64 bit Spur image is 68021,
>   with Sista it is 68533.
>   
>   It is expected that additional bytecode sets can be identified by an
>   additional field in the image header, probably 32 bits containing two
>   16 bit fields,  if both zero then Sista.
>   
>   Per discussion with Eliot and Bert in a Squeak oversight board meeting
>   2019-05-15.
> 
> 
> Dave
> 

> 'From Squeak5.3beta of 4 January 2020 [latest update: #19304] on 12 January 2020 at 2:10:55 pm'!
"Change Set:		VMM-Sista-bit-dtl
Date:			12 January 2020
Author:			David T. Lewis

Let the image inform the interpreter that alternate bytecodes either are or are not in use, and remember that setting when writing or reading the image format number in a shapshot file header.

Provide primitiveMultipleBytecodesActive to allow the setting to be updated from the image. Expected usage is that the image can call this primitive after recompiling with Systa bytecodes, or after reverting back. Note that an alternative implemenation would be to use a VM parameter. The primitive was chosen here because it can perform parameter checking and does not require coordinated update the the VM parameter usage.

Expected usage is that this feature will remain unused for some grace period (perhaps a few months) during which an updated VM can be widely circulated. After that period, images using Sista bytecodes may be safely saved with the updated image format number indicating that multiple bytecodes are in use.

This change set includes helper methods in SmalltalkImage for testing or setting the multipleBytecodeSetsActive setting in the VM.

Note the change set postscript which is necessary for initializing a class variable prior to code generation."!

VMClass subclass: #InterpreterPrimitives
	instanceVariableNames: 'objectMemory messageSelector argumentCount newMethod primFailCode osErrorCode exceptionPC inFFIFlags profileMethod profileProcess profileSemaphore nextProfileTick preemptionYields newFinalization sHEAFn ffiExceptionResponse multipleBytecodeSetsActive'
	classVariableNames: 'CrossedX EndOfRun MillisecondClockMask'
	poolDictionaries: 'VMBasicConstants VMBytecodeConstants VMMethodCacheConstants VMObjectIndices VMSqueakClassIndices VMStackFrameOffsets'
	category: 'VMMaker-Interpreter'!
InterpreterPrimitives subclass: #StackInterpreter
	instanceVariableNames: 'currentBytecode bytecodeSetSelector localFP localIP localSP stackLimit stackPage stackPages method instructionPointer stackPointer framePointer localReturnValue localAbsentReceiver localAbsentReceiverOrZero extA extB numExtB primitiveFunctionPointer methodCache nsMethodCache atCache lkupClassTag lkupClass methodDictLinearSearchLimit highestRunnableProcessPriority reenterInterpreter nextWakeupUsecs nextPollUsecs inIOProcessEvents interruptKeycode interruptPending savedWindowSize imageHeaderFlags fullScreenFlag sendWheelEvents deferDisplayUpdates pendingFinalizationSignals extraVMMemory interpreterProxy showSurfaceFn primitiveTable primitiveAccessorDepthTable externalPrimitiveTable externalPrimitiveTableFirstFreeIndex overflowedPage extraFramesToMoveOnOverflow globalSessionID jmpBuf jmpDepth suspendedCallbacks suspendedMethods numStackPages desiredNumStackPages desiredEdenBytes classNameIndex thisClassIndex metaclassNumSlots interruptCheckChain suppressHeartbeatFlag breakSelector breakSelectorLength breakLookupClassTag longRunningPrimitiveCheckMethod longRunningPrimitiveCheckSemaphore longRunningPrimitiveStartUsecs longRunningPrimitiveStopUsecs longRunningPrimitiveGCUsecs longRunningPrimitiveCheckSequenceNumber longRunningPrimitiveSignalUndelivered checkAllocFiller tempOop tempOop2 metaAccessorDepth theUnknownShort the2ndUnknownShort imageFloatsBigEndian maxExtSemTabSizeSet lastMethodCacheProbeWrite gcSemaphoreIndex classByteArrayCompactIndex checkedPluginName nativeSP nativeStackPointer lowcodeCalloutState shadowCallStackPointer displayBits displayWidth displayHeight displayDepth statForceInterruptCheck statStackOverflow statStackPageDivorce statCheckForEvents statProcessSwitch statIOProcessEvents statPendingFinalizationSignals statIdleUsecs debugCallbackPath debugCallbackReturns debugCallbackInvokes primitiveDoMixedArithmetic'
	classVariableNames: 'AccessModifierPrivate AccessModifierProtected AccessModifierPublic AltBytecodeEncoderClassName AltLongStoreBytecode AlternateHeaderHasPrimFlag AlternateHeaderIsOptimizedFlag AlternateHeaderNumLiteralsMask AtCacheFixedFields AtCacheFmt AtCacheMask AtCacheOop AtCacheSize AtCacheTotalSize AtPutBase BytecodeEncoderClassName BytecodeTable CacheProbeMax DirBadPath DirEntryFound DirNoMoreEntries DumpStackOnLowSpace EnclosingMixinIndex EnclosingObjectIndex EnforceAccessControl FailImbalancedPrimitives LongStoreBytecode MaxExternalPrimitiveTableSize MaxJumpBuf MaxPrimitiveIndex MaxQuickPrimitiveIndex MethodHeaderArgCountShift MethodHeaderFlagBitPosition MethodHeaderTempCountShift MixinIndex MultipleBytecodeSetsBitmask PrimNumberDoExternalCall PrimNumberDoPrimitive PrimNumberExternalCall PrimNumberFFICall PrimitiveTable ReturnToInterpreter StackPageReachedButUntraced StackPageTraceInvalid StackPageTraced StackPageUnreached V3PrimitiveBitsMask'
	poolDictionaries: 'VMBasicConstants VMBytecodeConstants VMMethodCacheConstants VMObjectIndices VMSpurObjectRepresentationConstants VMSqueakClassIndices VMStackFrameOffsets'
	category: 'VMMaker-Interpreter'!

!InterpreterPrimitives methodsFor: 'other primitives' stamp: 'dtl 1/12/2020 13:47'!
primitiveMultipleBytecodeSetsActive
	"Set the value of multipleBytecodeSetsActive based on the boolean
	argument if supplied. Fail if multiple bytecode sets are not supported.
	Answer the current value of multipleBytecodeSetsActive."

	<export: true>
	argumentCount >1 ifTrue:
		[^self primitiveFailFor: PrimErrBadNumArgs].
	argumentCount = 1
		ifTrue: [self stackTop = objectMemory trueObject
			ifTrue: [self cppIf: MULTIPLEBYTECODESETS
				ifTrue: [multipleBytecodeSetsActive := true]
				ifFalse: [^self primitiveFailFor: PrimErrUnsupported]]
			ifFalse: [self stackTop = objectMemory falseObject
				ifTrue: [multipleBytecodeSetsActive := false]
				ifFalse:[^self primitiveFailFor: PrimErrBadArgument]]].
	multipleBytecodeSetsActive
		ifTrue: [self pop: argumentCount + 1 thenPush: objectMemory trueObject]
		ifFalse: [self pop: argumentCount + 1 thenPush: objectMemory falseObject].
! !


!SmalltalkImage methodsFor: 'system attributes' stamp: 'dtl 1/12/2020 11:55'!
multipleBytecodeSetsActive
	"Answer true if the VM is assuming that multiple bytecode sets such as
	Sista are active in this image."

	<primitive: 'primitiveMultipleBytecodeSetsActive'>.
	self primitiveFailed! !

!SmalltalkImage methodsFor: 'system attributes' stamp: 'dtl 1/12/2020 11:52'!
multipleBytecodeSetsActive: aBoolean
	"Inform the VM that an alternate bytecode set such as EncoderForSistaV1
	is or is not currently in use by this image. The VM may use this to update
	the image format number when saving the image."

	<primitive: 'primitiveMultipleBytecodeSetsActive'>.
	self primitiveFailed! !


!StackInterpreter methodsFor: 'image save/restore' stamp: 'dtl 1/12/2020 11:19'!
readableFormat: imageVersion
	"Anwer true if images of the given format are readable by this interpreter.
	 Allows a virtual machine to accept selected older image formats."
	<api>
	| imageVersionWithoutSistaBit |
	imageVersionWithoutSistaBit := imageVersion bitAnd: ( -1 - MultipleBytecodeSetsBitmask). "Ignore multiple bytecode support identifier"
	[imageVersionWithoutSistaBit = self imageFormatVersion "Float words in platform-order"
	   or: [objectMemory hasSpurMemoryManagerAPI not "No compatibility version for Spur as yet"
			and: [imageVersionWithoutSistaBit = self imageFormatCompatibilityVersion]]] "Float words in BigEndian order"
		ifTrue: [multipleBytecodeSetsActive := imageVersion bitAnd: MultipleBytecodeSetsBitmask. "Remember the Sista bit"
			^ true].
	^ false
! !

!StackInterpreter methodsFor: 'image save/restore' stamp: 'dtl 1/12/2020 11:18'!
writeImageFileIO
	"Write the image header and heap contents to imageFile for snapshot. c.f. writeImageFileIOSimulation.
	 The game below is to maintain 64-bit alignment for all putLong:toFile: occurrences."
	<inline: #never>
	| imageName headerStart headerSize f imageBytes bytesWritten sCWIfn okToWrite |
	<var: #f type: #sqImageFile>
	<var: #headerStart type: #squeakFileOffsetType>
	<var: #sCWIfn type: #'void *'>
	<var: #imageName declareC: 'extern char imageName[]'>

	self cCode: [] inSmalltalk: [imageName := 'sooth compiler'. ^self writeImageFileIOSimulation].

	"If the security plugin can be loaded, use it to check for write permission.
	 If not, assume it's ok"
	sCWIfn := self ioLoadFunction: 'secCanWriteImage' From: 'SecurityPlugin'.
	sCWIfn ~= 0 ifTrue:
		[okToWrite := self cCode: '((sqInt (*)(void))sCWIfn)()'.
		 okToWrite ifFalse:[^self primitiveFail]].
	
	"local constants"
	headerStart := 0.  
	headerSize := objectMemory wordSize = 4 ifTrue: [64] ifFalse: [128].  "header size in bytes; do not change!!"

	f := self sqImageFile: imageName Open: 'wb'.
	f = nil ifTrue: "could not open the image file for writing"
		[^self primitiveFail].

	imageBytes := objectMemory imageSizeToWrite.
	headerStart := self sqImage: f File: imageName StartLocation: headerSize + imageBytes.
	self cCode: '/* Note: on Unix systems one could put an exec command here, padded to 512 bytes */'.
	"position file to start of header"
	self sqImageFile: f Seek: headerStart.
	multipleBytecodeSetsActive
		ifTrue: [self putWord32: (self imageFormatVersion bitOr: MultipleBytecodeSetsBitmask) toFile: f]
		ifFalse: [self putWord32: self imageFormatVersion toFile: f].
	self putWord32: headerSize toFile: f.
	self putLong: imageBytes toFile: f.
	self putLong: objectMemory baseAddressOfImage toFile: f.
	self putLong: objectMemory specialObjectsOop toFile: f.
	self putLong: objectMemory newObjectHash toFile: f.
	self putLong: self getSnapshotScreenSize toFile: f.
	self putLong: self getImageHeaderFlags toFile: f.
	self putWord32: extraVMMemory toFile: f.
	self putShort: desiredNumStackPages toFile: f.
	self putShort: self unknownShortOrCodeSizeInKs toFile: f.
	self putWord32: desiredEdenBytes toFile: f.
	self putShort: (maxExtSemTabSizeSet ifTrue: [self ioGetMaxExtSemTableSize] ifFalse: [0]) toFile: f.
	self putShort: the2ndUnknownShort toFile: f.
	objectMemory hasSpurMemoryManagerAPI
		ifTrue:
			[self putLong: objectMemory firstSegmentBytes toFile: f.
			 self putLong: objectMemory bytesLeftInOldSpace toFile: f.
			 2 timesRepeat: [self putLong: 0 toFile: f]	"Pad the rest of the header."]
		ifFalse:
			[4 timesRepeat: [self putLong: 0 toFile: f]].  "Pad the rest of the header."

	 objectMemory wordSize = 8 ifTrue:
		[3 timesRepeat: [self putLong: 0 toFile: f]]. "Pad the rest of the header."

	self assert: headerStart + headerSize = (self sqImageFilePosition: f).
	"position file after the header"
	self sqImageFile: f Seek: headerStart + headerSize.

	self successful ifFalse: "file write or seek failure"
		[self sqImageFileClose: f.
		 ^nil].

	"write the image data"
	objectMemory hasSpurMemoryManagerAPI
		ifTrue:
			[bytesWritten := objectMemory writeImageSegmentsToFile: f]
		ifFalse:
			[bytesWritten := self sq: (self pointerForOop: objectMemory baseAddressOfImage)
								Image: (self sizeof: #char)
								File: imageBytes
								Write: f].
	self success: bytesWritten = imageBytes.
	self sqImageFileClose: f! !


!StackInterpreter class methodsFor: 'initialization' stamp: 'dtl 1/12/2020 11:19'!
initializeMiscConstants

	super initializeMiscConstants.
	STACKVM := true.

	"These flags function to identify a GC operation, or
	 to specify what operations the leak checker should be run for."
	GCModeFull := 1.				"stop-the-world global GC"
	GCModeNewSpace := 2.		"Spur's scavenge, or V3's incremental"
	GCModeIncremental := 4.		"incremental global gc (Dijkstra tri-colour marking); as yet unimplemented"
	GCModeBecome := 8.			"v3 post-become sweeping/Spur forwarding"
	GCModeImageSegment := 16.	"just a flag for leak checking image segments"
	GCModeFreeSpace := 32.		"just a flag for leak checking free space; Spur only"
	GCCheckPrimCall := 64.		"just a flag for leak checking external primitive calls"

	StackPageTraceInvalid := -1.
	StackPageUnreached := 0.
	StackPageReachedButUntraced := 1.
	StackPageTraced := 2.

	DumpStackOnLowSpace := 0.
	MillisecondClockMask := 16r1FFFFFFF.
	"Note: The external primitive table should actually be dynamically sized but for the sake of inferior platforms (e.g., Mac :-) who cannot allocate memory in any reasonable way, we keep it static (and cross our fingers...)"
	MaxExternalPrimitiveTableSize := 4096. "entries"

	MaxJumpBuf := 32. "max. callback depth"
	FailImbalancedPrimitives := InitializationOptions at: #FailImbalancedPrimitives ifAbsentPut: [true].
	EnforceAccessControl := InitializationOptions at: #EnforceAccessControl ifAbsent: [true].

	ReturnToInterpreter := 1. "setjmp/longjmp code."

	"N.B. some of these DisownFlags are replicated in platforms/Cross/vm/sqVirtualMachine.h.
	 Hence they should always be initialized.  Because of a hack with callbacks in the non-threaded
	 VM they must not conflct with the VM's tag bits."
	DisownVMLockOutFullGC := 8.
	DisownVMForFFICall := 16.
	DisownVMForThreading := 32.
	
	"The Sista bit in the interpreter image format version number"
	MultipleBytecodeSetsBitmask := 512.
! !

"Postscript:
Initialize MultipleByteCodeSets class variable."
StackInterpreter initializeMiscConstants.!

> 


From lewis at mail.msen.com  Sun Jul 19 17:51:24 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Sun, 19 Jul 2020 13:51:24 -0400
Subject: [squeak-dev] Support an updated image format number for Sista
In-Reply-To: <20200719162621.GA89267@shell.msen.com>
References: <20200113143334.GA9638@shell.msen.com>
 <20200719162621.GA89267@shell.msen.com>
Message-ID: <20200719175124.GA98958@shell.msen.com>

I should add that my underlying assumption in proposing the primitive is that
the VM has no easy or efficient way of knowing whether alternate bytecode sets
are currently in use, hence the "helper" primitive to permit the image to
pass a hint to the VM that alternate bytecodes are now active.

But I note that CompiledMethod is in the special object array, so maybe
there is some way to scan object memory for compiled methods that use
the alternate bytecode set.

Dave

On Sun, Jul 19, 2020 at 12:26:21PM -0400, David T. Lewis wrote:
> <bump>
> 
> Background:
> 
> Sista bytecodes have been supported in the VM (opensmalltalk-vm) for quite
> some time. Shortly after the Squeak 5.3 release Sista became the default
> bytecode set in the trunk image.
> 
> In Squeak trunk, Sista bytecodes can be activated (or deactivated) with
> CompiledCode class>>useSista: aBoolean, which also calls the hook to inform
> the VM of Sista bytecode usage:
> 
> 	<primitive: 'primitiveMultipleBytecodeSetsActive'>
> 	
> This optional primitive is intended to inform the VM that an alternate
> bytecode set is (or is not) being used by the image, and the VM can use
> this information to update the image format number (first few bytes of
> the saved image file) to a new number that indicates that Sista or other
> enhanced bytecode set support is required for that image. A proposed
> implementation of the primitive for opensmalltalk-vm is in the VMMaker
> inbox (VMMaker.oscog-dtl.2711).
> 
> An earlier follow-up discussion in this thread included the suggestion
> of e.g.  a #primitiveAvailableBytecodeSets that would provide a list of
> available bytecode sets to the image. This is also a good idea, but it is
> not directly related to the intended use of #primitiveMultipleBytecodeSetsActive.
> Perhaps it could be implemented as a zero-argument call to a single primitive,
> such that a boolean argument informs the VM of multiple bytecodes active,
> and calling primitiveMultipleBytecodeSetsActive without arguments would ask
> the VM to tell the image what bytecode sets can be supported by that VM.
> 
> @eliot - are you still on board with this concept, and if so could you
> please take a look at the inbox proposal? We discussed this in the last
> Squeak board meeting, and the board remains supportive of the idea of
> updating the image format number for the next Squeak release.
> 
> Thanks,
> Dave
> 
> 
> On Mon, Jan 13, 2020 at 09:33:34AM -0500, David T. Lewis wrote:
> > Hi Eliot,
> > 
> > This is a belated follow up on earlier private discussion during a Squeak
> > board meeting a few months ago, in which we agreed that identifying
> > "Sista in use" in the image format number would be a useful thing to do.
> > I previously added the documentation for this in ImageFormat-dtl.39.mcz
> > (as well as the updated ckformat.c program to match).
> > 
> > Attached here is a change set that can be loaded into a VMMaker image to
> > add VM support for setting and reading the updated image format numbers.
> > Here I used a primitive to initially set or clear the "sista bit". There
> > are other ways this could be done, but this at least gets us started
> > with a working implementation.
> > 
> > By way of explanation, I am copying below both the change set preamble
> > and the earlier ImageFormat commit notice:
> > 
> > ===
> > 
> >   Change Set:		VMM-Sista-bit-dtl
> >   Date:			12 January 2020
> >   Author:			David T. Lewis
> >   
> >   Let the image inform the interpreter that alternate bytecodes either are
> >   or are not in use, and remember that setting when writing or reading the
> >   image format number in a shapshot file header.
> >   
> >   Provide primitiveMultipleBytecodesActive to allow the setting to be updated
> >   from the image. Expected usage is that the image can call this primitive
> >   after recompiling with Systa bytecodes, or after reverting back. Note that
> >   an alternative implemenation would be to use a VM parameter. The primitive
> >   was chosen here because it can perform parameter checking and does not
> >   require coordinated update the the VM parameter usage.
> >   
> >   Expected usage is that this feature will remain unused for some grace period
> >   (perhaps a few months) during which an updated VM can be widely circulated.
> >   After that period, images using Sista bytecodes may be safely saved with the
> >   updated image format number indicating that multiple bytecodes are in use.
> >   
> >   This change set includes helper methods in SmalltalkImage for testing or
> >   setting the multipleBytecodeSetsActive setting in the VM.
> >   
> >   Note the change set postscript which is necessary for initializing a class
> >   variable prior to code generation.
> > 
> > ===
> > 
> >   Name: ImageFormat-dtl.37
> >   Author: dtl
> >   Time: 20 July 2019, 5:23:59.004 pm
> >   UUID: 52b464d5-0bf7-4326-bde3-4f18ad70b239
> >   Ancestors: ImageFormat-dtl.36
> >   
> >   Identify extended bytecodes for Sista in the image format number. Bit 10
> >   identifies an image that contains extended bytecodes. Thus a 32 bit Spur
> >   image is 6521, with Sista it is 7033, and a 64 bit Spur image is 68021,
> >   with Sista it is 68533.
> >   
> >   It is expected that additional bytecode sets can be identified by an
> >   additional field in the image header, probably 32 bits containing two
> >   16 bit fields,  if both zero then Sista.
> >   
> >   Per discussion with Eliot and Bert in a Squeak oversight board meeting
> >   2019-05-15.
> > 
> > 
> > Dave
> > 
> 
> > 'From Squeak5.3beta of 4 January 2020 [latest update: #19304] on 12 January 2020 at 2:10:55 pm'!
"Change Set:		VMM-Sista-bit-dtl
Date:			12 January 2020
Author:			David T. Lewis

Let the image inform the interpreter that alternate bytecodes either are or are not in use, and remember that setting when writing or reading the image format number in a shapshot file header.

Provide primitiveMultipleBytecodesActive to allow the setting to be updated from the image. Expected usage is that the image can call this primitive after recompiling with Systa bytecodes, or after reverting back. Note that an alternative implemenation would be to use a VM parameter. The primitive was chosen here because it can perform parameter checking and does not require coordinated update the the VM parameter usage.

Expected usage is that this feature will remain unused for some grace period (perhaps a few months) during which an updated VM can be widely circulated. After that period, images using Sista bytecodes may be safely saved with the updated image format number indicating that multiple bytecodes are in use.

This change set includes helper methods in SmalltalkImage for testing or setting the multipleBytecodeSetsActive setting in the VM.

Note the change set postscript which is necessary for initializing a class variable prior to code generation."!

VMClass subclass: #InterpreterPrimitives
	instanceVariableNames: 'objectMemory messageSelector argumentCount newMethod primFailCode osErrorCode exceptionPC inFFIFlags profileMethod profileProcess profileSemaphore nextProfileTick preemptionYields newFinalization sHEAFn ffiExceptionResponse multipleBytecodeSetsActive'
	classVariableNames: 'CrossedX EndOfRun MillisecondClockMask'
	poolDictionaries: 'VMBasicConstants VMBytecodeConstants VMMethodCacheConstants VMObjectIndices VMSqueakClassIndices VMStackFrameOffsets'
	category: 'VMMaker-Interpreter'!
InterpreterPrimitives subclass: #StackInterpreter
	instanceVariableNames: 'currentBytecode bytecodeSetSelector localFP localIP localSP stackLimit stackPage stackPages method instructionPointer stackPointer framePointer localReturnValue localAbsentReceiver localAbsentReceiverOrZero extA extB numExtB primitiveFunctionPointer methodCache nsMethodCache atCache lkupClassTag lkupClass methodDictLinearSearchLimit highestRunnableProcessPriority reenterInterpreter nextWakeupUsecs nextPollUsecs inIOProcessEvents interruptKeycode interruptPending savedWindowSize imageHeaderFlags fullScreenFlag sendWheelEvents deferDisplayUpdates pendingFinalizationSignals extraVMMemory interpreterProxy showSurfaceFn primitiveTable primitiveAccessorDepthTable externalPrimitiveTable externalPrimitiveTableFirstFreeIndex overflowedPage extraFramesToMoveOnOverflow globalSessionID jmpBuf jmpDepth suspendedCallbacks suspendedMethods numStackPages desiredNumStackPages desiredEdenBytes classNameIndex thisClassIndex metaclassNumSlots interruptCheckChain suppressHeartbeatFlag breakSelector breakSelectorLength breakLookupClassTag longRunningPrimitiveCheckMethod longRunningPrimitiveCheckSemaphore longRunningPrimitiveStartUsecs longRunningPrimitiveStopUsecs longRunningPrimitiveGCUsecs longRunningPrimitiveCheckSequenceNumber longRunningPrimitiveSignalUndelivered checkAllocFiller tempOop tempOop2 metaAccessorDepth theUnknownShort the2ndUnknownShort imageFloatsBigEndian maxExtSemTabSizeSet lastMethodCacheProbeWrite gcSemaphoreIndex classByteArrayCompactIndex checkedPluginName nativeSP nativeStackPointer lowcodeCalloutState shadowCallStackPointer displayBits displayWidth displayHeight displayDepth statForceInterruptCheck statStackOverflow statStackPageDivorce statCheckForEvents statProcessSwitch statIOProcessEvents statPendingFinalizationSignals statIdleUsecs debugCallbackPath debugCallbackReturns debugCallbackInvokes primitiveDoMixedArithmetic'
	classVariableNames: 'AccessModifierPrivate AccessModifierProtected AccessModifierPublic AltBytecodeEncoderClassName AltLongStoreBytecode AlternateHeaderHasPrimFlag AlternateHeaderIsOptimizedFlag AlternateHeaderNumLiteralsMask AtCacheFixedFields AtCacheFmt AtCacheMask AtCacheOop AtCacheSize AtCacheTotalSize AtPutBase BytecodeEncoderClassName BytecodeTable CacheProbeMax DirBadPath DirEntryFound DirNoMoreEntries DumpStackOnLowSpace EnclosingMixinIndex EnclosingObjectIndex EnforceAccessControl FailImbalancedPrimitives LongStoreBytecode MaxExternalPrimitiveTableSize MaxJumpBuf MaxPrimitiveIndex MaxQuickPrimitiveIndex MethodHeaderArgCountShift MethodHeaderFlagBitPosition MethodHeaderTempCountShift MixinIndex MultipleBytecodeSetsBitmask PrimNumberDoExternalCall PrimNumberDoPrimitive PrimNumberExternalCall PrimNumberFFICall PrimitiveTable ReturnToInterpreter StackPageReachedButUntraced StackPageTraceInvalid StackPageTraced StackPageUnreached V3PrimitiveBitsMask'
	poolDictionaries: 'VMBasicConstants VMBytecodeConstants VMMethodCacheConstants VMObjectIndices VMSpurObjectRepresentationConstants VMSqueakClassIndices VMStackFrameOffsets'
	category: 'VMMaker-Interpreter'!

!InterpreterPrimitives methodsFor: 'other primitives' stamp: 'dtl 1/12/2020 13:47'!
primitiveMultipleBytecodeSetsActive
	"Set the value of multipleBytecodeSetsActive based on the boolean
	argument if supplied. Fail if multiple bytecode sets are not supported.
	Answer the current value of multipleBytecodeSetsActive."

	<export: true>
	argumentCount >1 ifTrue:
		[^self primitiveFailFor: PrimErrBadNumArgs].
	argumentCount = 1
		ifTrue: [self stackTop = objectMemory trueObject
			ifTrue: [self cppIf: MULTIPLEBYTECODESETS
				ifTrue: [multipleBytecodeSetsActive := true]
				ifFalse: [^self primitiveFailFor: PrimErrUnsupported]]
			ifFalse: [self stackTop = objectMemory falseObject
				ifTrue: [multipleBytecodeSetsActive := false]
				ifFalse:[^self primitiveFailFor: PrimErrBadArgument]]].
	multipleBytecodeSetsActive
		ifTrue: [self pop: argumentCount + 1 thenPush: objectMemory trueObject]
		ifFalse: [self pop: argumentCount + 1 thenPush: objectMemory falseObject].
! !


!SmalltalkImage methodsFor: 'system attributes' stamp: 'dtl 1/12/2020 11:55'!
multipleBytecodeSetsActive
	"Answer true if the VM is assuming that multiple bytecode sets such as
	Sista are active in this image."

	<primitive: 'primitiveMultipleBytecodeSetsActive'>.
	self primitiveFailed! !

!SmalltalkImage methodsFor: 'system attributes' stamp: 'dtl 1/12/2020 11:52'!
multipleBytecodeSetsActive: aBoolean
	"Inform the VM that an alternate bytecode set such as EncoderForSistaV1
	is or is not currently in use by this image. The VM may use this to update
	the image format number when saving the image."

	<primitive: 'primitiveMultipleBytecodeSetsActive'>.
	self primitiveFailed! !


!StackInterpreter methodsFor: 'image save/restore' stamp: 'dtl 1/12/2020 11:19'!
readableFormat: imageVersion
	"Anwer true if images of the given format are readable by this interpreter.
	 Allows a virtual machine to accept selected older image formats."
	<api>
	| imageVersionWithoutSistaBit |
	imageVersionWithoutSistaBit := imageVersion bitAnd: ( -1 - MultipleBytecodeSetsBitmask). "Ignore multiple bytecode support identifier"
	[imageVersionWithoutSistaBit = self imageFormatVersion "Float words in platform-order"
	   or: [objectMemory hasSpurMemoryManagerAPI not "No compatibility version for Spur as yet"
			and: [imageVersionWithoutSistaBit = self imageFormatCompatibilityVersion]]] "Float words in BigEndian order"
		ifTrue: [multipleBytecodeSetsActive := imageVersion bitAnd: MultipleBytecodeSetsBitmask. "Remember the Sista bit"
			^ true].
	^ false
! !

!StackInterpreter methodsFor: 'image save/restore' stamp: 'dtl 1/12/2020 11:18'!
writeImageFileIO
	"Write the image header and heap contents to imageFile for snapshot. c.f. writeImageFileIOSimulation.
	 The game below is to maintain 64-bit alignment for all putLong:toFile: occurrences."
	<inline: #never>
	| imageName headerStart headerSize f imageBytes bytesWritten sCWIfn okToWrite |
	<var: #f type: #sqImageFile>
	<var: #headerStart type: #squeakFileOffsetType>
	<var: #sCWIfn type: #'void *'>
	<var: #imageName declareC: 'extern char imageName[]'>

	self cCode: [] inSmalltalk: [imageName := 'sooth compiler'. ^self writeImageFileIOSimulation].

	"If the security plugin can be loaded, use it to check for write permission.
	 If not, assume it's ok"
	sCWIfn := self ioLoadFunction: 'secCanWriteImage' From: 'SecurityPlugin'.
	sCWIfn ~= 0 ifTrue:
		[okToWrite := self cCode: '((sqInt (*)(void))sCWIfn)()'.
		 okToWrite ifFalse:[^self primitiveFail]].
	
	"local constants"
	headerStart := 0.  
	headerSize := objectMemory wordSize = 4 ifTrue: [64] ifFalse: [128].  "header size in bytes; do not change!!"

	f := self sqImageFile: imageName Open: 'wb'.
	f = nil ifTrue: "could not open the image file for writing"
		[^self primitiveFail].

	imageBytes := objectMemory imageSizeToWrite.
	headerStart := self sqImage: f File: imageName StartLocation: headerSize + imageBytes.
	self cCode: '/* Note: on Unix systems one could put an exec command here, padded to 512 bytes */'.
	"position file to start of header"
	self sqImageFile: f Seek: headerStart.
	multipleBytecodeSetsActive
		ifTrue: [self putWord32: (self imageFormatVersion bitOr: MultipleBytecodeSetsBitmask) toFile: f]
		ifFalse: [self putWord32: self imageFormatVersion toFile: f].
	self putWord32: headerSize toFile: f.
	self putLong: imageBytes toFile: f.
	self putLong: objectMemory baseAddressOfImage toFile: f.
	self putLong: objectMemory specialObjectsOop toFile: f.
	self putLong: objectMemory newObjectHash toFile: f.
	self putLong: self getSnapshotScreenSize toFile: f.
	self putLong: self getImageHeaderFlags toFile: f.
	self putWord32: extraVMMemory toFile: f.
	self putShort: desiredNumStackPages toFile: f.
	self putShort: self unknownShortOrCodeSizeInKs toFile: f.
	self putWord32: desiredEdenBytes toFile: f.
	self putShort: (maxExtSemTabSizeSet ifTrue: [self ioGetMaxExtSemTableSize] ifFalse: [0]) toFile: f.
	self putShort: the2ndUnknownShort toFile: f.
	objectMemory hasSpurMemoryManagerAPI
		ifTrue:
			[self putLong: objectMemory firstSegmentBytes toFile: f.
			 self putLong: objectMemory bytesLeftInOldSpace toFile: f.
			 2 timesRepeat: [self putLong: 0 toFile: f]	"Pad the rest of the header."]
		ifFalse:
			[4 timesRepeat: [self putLong: 0 toFile: f]].  "Pad the rest of the header."

	 objectMemory wordSize = 8 ifTrue:
		[3 timesRepeat: [self putLong: 0 toFile: f]]. "Pad the rest of the header."

	self assert: headerStart + headerSize = (self sqImageFilePosition: f).
	"position file after the header"
	self sqImageFile: f Seek: headerStart + headerSize.

	self successful ifFalse: "file write or seek failure"
		[self sqImageFileClose: f.
		 ^nil].

	"write the image data"
	objectMemory hasSpurMemoryManagerAPI
		ifTrue:
			[bytesWritten := objectMemory writeImageSegmentsToFile: f]
		ifFalse:
			[bytesWritten := self sq: (self pointerForOop: objectMemory baseAddressOfImage)
								Image: (self sizeof: #char)
								File: imageBytes
								Write: f].
	self success: bytesWritten = imageBytes.
	self sqImageFileClose: f! !


!StackInterpreter class methodsFor: 'initialization' stamp: 'dtl 1/12/2020 11:19'!
initializeMiscConstants

	super initializeMiscConstants.
	STACKVM := true.

	"These flags function to identify a GC operation, or
	 to specify what operations the leak checker should be run for."
	GCModeFull := 1.				"stop-the-world global GC"
	GCModeNewSpace := 2.		"Spur's scavenge, or V3's incremental"
	GCModeIncremental := 4.		"incremental global gc (Dijkstra tri-colour marking); as yet unimplemented"
	GCModeBecome := 8.			"v3 post-become sweeping/Spur forwarding"
	GCModeImageSegment := 16.	"just a flag for leak checking image segments"
	GCModeFreeSpace := 32.		"just a flag for leak checking free space; Spur only"
	GCCheckPrimCall := 64.		"just a flag for leak checking external primitive calls"

	StackPageTraceInvalid := -1.
	StackPageUnreached := 0.
	StackPageReachedButUntraced := 1.
	StackPageTraced := 2.

	DumpStackOnLowSpace := 0.
	MillisecondClockMask := 16r1FFFFFFF.
	"Note: The external primitive table should actually be dynamically sized but for the sake of inferior platforms (e.g., Mac :-) who cannot allocate memory in any reasonable way, we keep it static (and cross our fingers...)"
	MaxExternalPrimitiveTableSize := 4096. "entries"

	MaxJumpBuf := 32. "max. callback depth"
	FailImbalancedPrimitives := InitializationOptions at: #FailImbalancedPrimitives ifAbsentPut: [true].
	EnforceAccessControl := InitializationOptions at: #EnforceAccessControl ifAbsent: [true].

	ReturnToInterpreter := 1. "setjmp/longjmp code."

	"N.B. some of these DisownFlags are replicated in platforms/Cross/vm/sqVirtualMachine.h.
	 Hence they should always be initialized.  Because of a hack with callbacks in the non-threaded
	 VM they must not conflct with the VM's tag bits."
	DisownVMLockOutFullGC := 8.
	DisownVMForFFICall := 16.
	DisownVMForThreading := 32.
	
	"The Sista bit in the interpreter image format version number"
	MultipleBytecodeSetsBitmask := 512.
! !

"Postscript:
Initialize MultipleByteCodeSets class variable."
StackInterpreter initializeMiscConstants.!
> > 
> 
> 

From digit at sonic.net  Sun Jul 19 19:30:14 2020
From: digit at sonic.net (Tim Johnson)
Date: Sun, 19 Jul 2020 12:30:14 -0700
Subject: [squeak-dev] squeak.sh appears unable to allow specifying a
	project/file
In-Reply-To: <7e701467-e52f-05bf-f682-c67a7abf8135@gmail.com>
References: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
 <44f6c9d6-0334-678b-7c1a-ddace2183c83@gmail.com>
 <d563db54-1b20-5b37-cdf6-69b29c79d58a@pm.me>
 <7e701467-e52f-05bf-f682-c67a7abf8135@gmail.com>
Message-ID: <FF2B58A9-E290-4FCC-965A-9EF9F754D77F@sonic.net>

Hi Subbu & all,

On Jul 18, 2020, at 4:32 AM, K K Subbu wrote:

> On 18/07/20 4:39 pm, Robert Withers wrote:
>>> This was patched recently. Does the version below solve your  
>>> problem?
>>>
>>> https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/templates/linux/squeak.sh
>> Would there be any chance of modifying the script to open a file  
>> chooser
>> dialog so the user can select the image s/he wants to run? There is a
>> squeak.sh out there somewhere that does this.
>
> The script uses a file dialog only when required. It is skipped if  
> an image file is specified in the command line or a single image is  
> found in the shared/ directory or through SQUEAK_IMAGE env variable.

Are you sure about the SQUEAK_IMAGE environment variable?  My  
experience in the last ~6 months had been that squeak.sh actually  
interfered with the VM's ability to read SQUEAK_IMAGE.  I hadn't  
posted about it because I feared it might only be my environment:   
self-built VM, Ubuntu or Raspbian.  But now I realize there are  
actually two files named squeak.sh, so I need to get my story straight  
before I post.

Let's differentiate the two squeak.sh files:

(a) The squeak.sh which is produced as part of the opensmalltalk-vm  
build process.  It begins life as  'platforms/unix/config/ 
squeak.sh.in' and/or 'platforms/unix/config/bin.squeak.sh.in' in the  
opensmalltalk-vm repo.  Its stated purpose is to "Run the VM, setting  
SQUEAK_PLUGINS if unset to the VM's containing directory if unset, and  
ensuring LD_LIBRARY_PATH includes the VM's containing directory".

(b) The squeak.sh which lives in the 'squeak-smalltalk/squeak-app'  
repo, and which is significantly different.  Its stated purpose is  
"Script to launch Squeak executable from a bundle".

(Is it fair/correct to say that squeak.sh ("b") would invoke the VM on  
Linux/Unix using squeak.sh ("a")?  Or is this not how the all-in-one  
bundle works?)

In any case:

Note that neither script references SQUEAK_IMAGE directly.   This is  
likely because each script anticipates that the VM will read the  
contents of SQUEAK_IMAGE.  But the Unix Squeak VM binary will only  
honor the contents of the SQUEAK_IMAGE environment variable if no  
image is specified on the command line -- see lines 1448-1450 of  
platforms/unix/vm/sqUnixMain.c:

if (documentName)
	strcpy(shortImageName, documentName);
else if ((ev= getenv(IMAGE_ENV_NAME)))

Aaaaanndddd I think it's fair to say that squeak.sh ("a") allows  
SQUEAK_IMAGE to pass through to the VM, whereas squeak.sh ("b") does  
not.   This is because (I think) squeak.sh ("b") tries very hard to  
find images somewhere (see ensure_image()), and then makes sure to  
ultimately pass an image parameter to the VM:
exec ${SOUNDSERVER} "${VM}" ${VMOPTIONS} ${VMARGS} "${IMAGE}" ${STARGS}

Compared to squeak.sh ("a") which doesn't try to pass any image or  
parameters if none were supplied to it:
LD_LIBRARY_PATH="$PLUGINS:$SVMLLP:${LD_LIBRARY_PATH}" exec $GDB "$BIN/ 
squeak" "$@"


My suggestion would be:  if squeak.sh ("b") from the squeak-app repo  
wants to honor the contents of the SQUEAK_IMAGE environment variable  
on Unix, it should either:  (1) adapt ensure_image() to check whether  
SQUEAK_IMAGE is set, and if it is, consider passing it along;  or (2)  
not supply  "${IMAGE}"  to the VM if no image is found.  Otherwise,  
the legend that the Unix Squeak VM will honor SQUEAK_IMAGE needs a big  
caveat: "unless launched by squeak.sh as provided in the app bundle"...

Also:  perhaps also one of the squeak.sh files could be renamed so  
this is less confusing.

Please ignore me or correct me if I'm totally off-base here.

Thanks,
another Tim



From tim at rowledge.org  Mon Jul 20 01:49:12 2020
From: tim at rowledge.org (tim Rowledge)
Date: Sun, 19 Jul 2020 18:49:12 -0700
Subject: [squeak-dev] squeak logging package(s)
In-Reply-To: <AFD0F32F-9ED0-41B2-B0EA-AD3020D939C3@rowledge.org>
References: <316A3C4A-3EA3-4E38-AB11-0F8D40D025B9@rowledge.org>
 <1594418688634-0.post@n4.nabble.com>
 <A8C54C44-C709-4038-8779-B6A565E426FF@rowledge.org>
 <13C54EA2-CE3F-4145-A9D0-872280BBAC4F@rowledge.org>
 <1595026318440-0.post@n4.nabble.com>
 <34440E10-5B26-4F00-97B7-4F357CD74439@rowledge.org>
 <3BF013EE-990A-4417-9A41-352493379884@rowledge.org>
 <F5A6B21F-25F9-4525-A98E-00C45FDDB79D@rowledge.org>
 <AFD0F32F-9ED0-41B2-B0EA-AD3020D939C3@rowledge.org>
Message-ID: <87AEC7DE-18F8-45D7-887B-855A2ACFAFDB@rowledge.org>

Well, a bit of confusion seems to have set in here wrt loafin Toothpick.

The Squeakmap entry loads the oldest version, Toothpick-tbn.1
There are a number of much newer versions and that includes a ConfigurationOf... so I tried 

Installer squeaksource
    project: 'Toothpick';
    install: 'ConfigurationOfToothpick'. 
(Smalltalk at: #ConfigurationOfToothpick) load

Which worked to load the newer code. It still required the small DateAndTime related patches to pass most of the SUnits, and now three TimestampFormatTestCase test fail for reasons I haven't looked at yet.

I'm currently a touch puzzled about how to load extra bits like the syslog code (clearly one could do Installer ss project: 'Toothpick'; load:... etc but that seems like bypassing what surely ought to be part of the ConfiguratonOf... stuff?) and also where I might contribute the DateAndTime patches without breaking anything. Does Pharo have different structure for DateAndTime, for example?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Sic faciunt omnes. = Everyone is doing it.



From marcel.taeumel at hpi.de  Mon Jul 20 08:58:08 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Mon, 20 Jul 2020 10:58:08 +0200
Subject: [squeak-dev] Installing metacello within a 'Smalltalk
	run:[]'	fails
In-Reply-To: <CANzdToG=xBfVHZG+aY4EraMRwYyf0C1uNn+amUs4CoTtaCw+Aw@mail.gmail.com>
References: <7BAC259A-CC81-440E-9682-193F08F8E8DF@rowledge.org>
 <alpine.DEB.2.02.2007160354510.13842@login03.caesar.elte.hu>
 <2A126DD8-C987-40D7-8DBA-BA1290B3EDEC@rowledge.org>
 <alpine.DEB.2.02.2007161446320.14732@login03.caesar.elte.hu>
 <CANzdToGzvJN7aq5iQqJ5O5_W3iPvMNJ18iAhOvby0+wH5PB+tw@mail.gmail.com>
 <CA+ovNC7yTnQ__iY_QOhJF8hvwvXeoarBOM4ndB2sDtqweNwFPA@mail.gmail.com>
 <CANzdToG=xBfVHZG+aY4EraMRwYyf0C1uNn+amUs4CoTtaCw+Aw@mail.gmail.com>
Message-ID: <Mailbird-7d8dd6fd-48dc-43a0-abec-ce2aa3419007@hpi.de>

Hi all!

Here are related discussions:

Oct 2019: http://forum.world.st/Discussion-Warning-vs-Halt-or-Why-is-a-warning-a-notification-tp5106457.html [http://forum.world.st/Discussion-Warning-vs-Halt-or-Why-is-a-warning-a-notification-tp5106457.html]

Nov 2019: http://forum.world.st/Squeak-s-AssertionFailure-vs-SUnit-s-TestFailure-tp5106818.html [http://forum.world.st/Squeak-s-AssertionFailure-vs-SUnit-s-TestFailure-tp5106818.html]

Apr 2020: http://forum.world.st/Why-is-ModificationForbidden-not-an-Error-tp5114717.html [http://forum.world.st/Why-is-ModificationForbidden-not-an-Error-tp5114717.html]


Best,
Marcel
Am 19.07.2020 00:31:25 schrieb Chris Muller <asqueaker at gmail.com>:
Wow, I actually had to look that up, because I found it incredible, but, lo and behold, there it is, under 5.5.4.5 Message: resume.  Does anyone know why ANSI considers it erroneous?

> Notifications resume by default anyway if not curtailed.

A signaled Notification which is never curtailed is nothing, negative even.  Their value is derived by being handled.  But, if you try to handle a Notification, you're basically forced to resume it if you want to retain the nature as if you didn't handle it.  By not guarantee'ing resumption, ANSI forces handlers and signalers to coordinate when they should be decoupled.

> The return value of defaultAction will be the resume value. So maybe it should read ^ self defaultResumeValue, or the latter selector should not exist in the library  classes.

Squeak has a couple of places that've been sending #resume from defaultAction since their inception.  My inclination would be to understand what we want to get out of Notification before making any changes.

For me, a Notification is informational output from a program that should always resume afterward and, therefore, whose defaultAction should be to resume: self defaultResumeValue.  Request should be its own major sub branch of Notification for input.


 - Chris


On Sat, Jul 18, 2020 at 7:10 AM Jakob Reschke <forums.jakob at resfarm.de [mailto:forums.jakob at resfarm.de]> wrote:

Chris Muller <asqueaker at gmail.com [mailto:asqueaker at gmail.com]> schrieb am Sa., 18. Juli 2020, 04:42:


As long as Notification>>#defaultAction remains 

    ^nil 

instead of 

      self resume

then Smalltalk>>#run: must handle Notification, otherwise, what Tim said would happen with headless apps, will happen.

resume must not be called from defaultAction according to the ANSI standard. Squeak may differ, but having this in the class library would set a bad example for applications that implement their own notifications. Notifications resume by default anyway if not curtailed. The return value of defaultAction will be the resume value. So maybe it should read ^ self defaultResumeValue, or the latter selector should not exist in the library  classes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200720/3d254332/attachment.html>

From marcel.taeumel at hpi.de  Mon Jul 20 09:02:24 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Mon, 20 Jul 2020 11:02:24 +0200
Subject: [squeak-dev] Fix for Monticello Configuration - Question about
 Inbox
In-Reply-To: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
References: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
Message-ID: <Mailbird-61a687f6-e429-4e84-a459-d4e306aad780@hpi.de>

Hi Ron.

Thank you! =)

> Realized after the save that the number it picked was a duplicate of other changes added to inbox.

Make sure to have all three repos in that package's repository group: Trunk, Inbox, Treated. Then the automatic version number calculation will work. Your local package cache will be considered, too.

A small gap in a new version number is okay.

Best,
Marcel
Am 18.07.2020 19:55:41 schrieb Ron Teitelbaum <ron at usmedrec.com>:
Hi All,

I Added a fix but not sure I did it correctly.  Inbox has other non merged changes on it for Monticello Configurations.  Realized after the save that the number it picked was a duplicate of other changes added to inbox.


my change: "
Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticello Configurations so that it automatically selects the package that is moved.  This allows you to push the button more than once without having to select the package again.

"

What should I have done in this situation?  Do we just pick a later version number.  I'm assuming here that we do not merge in others changes to your own change set.  

Thanks for your help.

Ron Teitelbaum 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200720/fda7be90/attachment.html>

From kksubbu.ml at gmail.com  Mon Jul 20 09:35:06 2020
From: kksubbu.ml at gmail.com (K K Subbu)
Date: Mon, 20 Jul 2020 15:05:06 +0530
Subject: [squeak-dev] squeak.sh appears unable to allow specifying a
 project/file
In-Reply-To: <FF2B58A9-E290-4FCC-965A-9EF9F754D77F@sonic.net>
References: <4A013321-6E10-4039-9C2A-6DEFC3E153F1@rowledge.org>
 <44f6c9d6-0334-678b-7c1a-ddace2183c83@gmail.com>
 <d563db54-1b20-5b37-cdf6-69b29c79d58a@pm.me>
 <7e701467-e52f-05bf-f682-c67a7abf8135@gmail.com>
 <FF2B58A9-E290-4FCC-965A-9EF9F754D77F@sonic.net>
Message-ID: <9cdc1b0c-7d7f-11c5-b4f4-f0488b632f15@gmail.com>

On 20/07/20 1:00 am, Tim Johnson wrote:
> Hi Subbu & all,
> 
> On Jul 18, 2020, at 4:32 AM, K K Subbu wrote:
> 
>> On 18/07/20 4:39 pm, Robert Withers wrote:
>>>> This was patched recently. Does the version below solve your problem?
>>>>
>>>> https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/templates/linux/squeak.sh 
>>>>
>>> Would there be any chance of modifying the script to open a file chooser
>>> dialog so the user can select the image s/he wants to run? There is a
>>> squeak.sh out there somewhere that does this.
>>
>> The script uses a file dialog only when required. It is skipped if an 
>> image file is specified in the command line or a single image is found 
>> in the shared/ directory or through SQUEAK_IMAGE env variable.

> Are you sure about the SQUEAK_IMAGE environment variable?  My experience 
> in the last ~6 months had been that squeak.sh actually interfered with 
> the VM's ability to read SQUEAK_IMAGE.

Nice catch! squeak-app is a GUI launcher while the squeak.sh in 
unix/config is meant for shell sessions. The GUI launcher picks its env 
variables from xsession rc files while the script squeak.sh picks them 
from shell rc files. Using SQUEAK_IMAGE in xsessions is very rare. It is 
more likely in shells.

> Let's differentiate the two squeak.sh files:
> 
> (a) The squeak.sh which is produced as part of the opensmalltalk-vm 
> build process.  It begins life as  'platforms/unix/config/squeak.sh.in' 
> and/or 'platforms/unix/config/bin.squeak.sh.in' in the opensmalltalk-vm 
> repo.  Its stated purpose is to "Run the VM, setting SQUEAK_PLUGINS if 
> unset to the VM's containing directory if unset, and ensuring 
> LD_LIBRARY_PATH includes the VM's containing directory".
> 
> (b) The squeak.sh which lives in the 'squeak-smalltalk/squeak-app' repo, 
> and which is significantly different.  Its stated purpose is "Script to 
> launch Squeak executable from a bundle".

The launcher script is just that - a launcher. It is meant to detect and 
use options specific to a Linux distro. The two launchers you list above 
are used in different contexts - xsession and bash.

> My suggestion would be:  if squeak.sh ("b") from the squeak-app repo 
> wants to honor the contents of the SQUEAK_IMAGE environment variable on 
> Unix, it should either:  (1) adapt ensure_image() to check whether 
> SQUEAK_IMAGE is set, and if it is, consider passing it along;  or (2) 
> not supply  "${IMAGE}"  to the VM if no image is found.

1) is an good suggestion. Please propose a patch to the repo or this 
list. 2) does not help in xsession. If an image file is not specified, 
it is better to use a file dialog to get one.

> Please ignore me or correct me if I'm totally off-base here.

I am glad you posted your observation. I too was confused about the 
multiple squeak.sh files. I really wish we could converge them into a 
single one, but the diversity in *ix deployments is too large to be 
captured in a single script.

Regards .. Subbu

From ron at usmedrec.com  Mon Jul 20 13:14:46 2020
From: ron at usmedrec.com (Ron Teitelbaum)
Date: Mon, 20 Jul 2020 09:14:46 -0400
Subject: [squeak-dev] Fix for Monticello Configuration - Question about
	Inbox
In-Reply-To: <Mailbird-61a687f6-e429-4e84-a459-d4e306aad780@hpi.de>
References: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
 <Mailbird-61a687f6-e429-4e84-a459-d4e306aad780@hpi.de>
Message-ID: <CAEzdQ-ezcOUTU8Vyn7gxzH-wQu-1uu6f3=YOuwCDbVh-i=jqOw@mail.gmail.com>

Hi Marcel,

Thanks for the suggestion.  I wasn't aware of Treated but I went and looked
it up.  So things that are sent to Inbox are then moved to either Trunk if
accepted or Treated if not accepted.  Did I get that right?

So someone that wants to contribute should load (or merge) the trunk latest
version but also add Inbox and Treated as repositories to the package for
automatic monticello numbering.  Then save the change verifying that only
their changes show up.  The number that it picks should be an acceptable
number for sending changes?  Should we also verify that the number is
greater than the last number in Inbox?

Thanks!

Ron

On Mon, Jul 20, 2020 at 5:02 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Ron.
>
> Thank you! =)
>
> > Realized after the save that the number it picked was a duplicate of
> other changes added to inbox.
>
> Make sure to have all three repos in that package's repository group:
> Trunk, Inbox, Treated. Then the automatic version number calculation will
> work. Your local package cache will be considered, too.
>
> A small gap in a new version number is okay.
>
> Best,
> Marcel
>
> Am 18.07.2020 19:55:41 schrieb Ron Teitelbaum <ron at usmedrec.com>:
> Hi All,
>
> I Added a fix but not sure I did it correctly.  Inbox has other non merged
> changes on it for Monticello Configurations.  Realized after the save that
> the number it picked was a duplicate of other changes added to inbox.
>
> my change: "
> Name: MonticelloConfigurations-RJT.163
> Author: RJT
> Time: 18 July 2020, 1:47:16.459316 pm
> UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
> Ancestors: MonticelloConfigurations-mt.162
>
> Fix the up and down button (to change the load order) of Monticello
> Configurations so that it automatically selects the package that is moved.
> This allows you to push the button more than once without having to select
> the package again.
> "
>
> What should I have done in this situation?  Do we just pick a later
> version number.  I'm assuming here that we do not merge in others changes
> to your own change set.
>
> Thanks for your help.
>
> Ron Teitelbaum
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200720/b8f7758a/attachment.html>

From forums.jakob at resfarm.de  Mon Jul 20 13:19:52 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Mon, 20 Jul 2020 15:19:52 +0200
Subject: [squeak-dev] Missing auth headers in WebClient request (was:
 Squot and Github)
In-Reply-To: <alpine.DEB.2.02.2007111528570.10597@login03.caesar.elte.hu>
References: <CA+CiqoWPgMHEUpjBqKhvT936NEMHfM7SWG=jRsW3QT0gS4GOBg@mail.gmail.com>
 <CADfnKi7A8pSJTJgrTRn7_DJn74OcNuMJ7b-4w77G_HkMFtZDMA@mail.gmail.com>
 <CA+ovNC6gmffmkYozgS35c2KtFR95ctvXTxx9JQ_uYPgoViST0w@mail.gmail.com>
 <CA+CiqoUZ0djXi9VWG5BFXG7oEFNCTjL3VK8fqnskyEnsbBE1bw@mail.gmail.com>
 <CA+ovNC5m=QJdiYotO9qhn-RXcGVveGzaUX_S73G1zUF0S_3w7g@mail.gmail.com>
 <alpine.DEB.2.02.2007111528570.10597@login03.caesar.elte.hu>
Message-ID: <CA+ovNC54oU7J9vQtMVB_kzt=s5zRVanytLAMU8QN6N9PrTjQvg@mail.gmail.com>

The authParams variable of WebClient contains a Dictionary that holds
associations for #authMethod, #authRealm, #authResponse, #username,
#password.

flushAuthState only removes #authMethod, to the effect that on the
next HTTP 401/407 response the authentication methods are dispatched
again (which is good). If #authMethod remained, all the authentication
methods would assume that a previous method has already supplied
credentials. Since each new WebRequest is not supplied with the
Authorization headers proactively, each new request dispatches again
with an additional round of 401 (which is not optimal, but
acceptable).

#authResponse is removed for each new dispatch of the authentication
methods. If a method matches the challenge in the 401 response, the
method will put a new #authResponse. The basic authentication method
writes an #authResponse if it matches the challenge and finds
#username and #password in the dictionary.

#username and #password seem to never be removed in the code. You can
set them with WebClient>>username: and password:, or by handling the
WebAuthRequired exception. Yet sometimes they appear to be missing
because eventually/sometimes the WebClient does not put new
Authorization headers to repeat the request, and instead returns the
401 response.

Actually I don't see how in WebClient>>#authenticate:from: the code
"The other possibility is that the credentials are wrong. [...]" can
ever be reached if the WebClient is supplied with username: and
password: from outside before the request or after the first 401. Is
the comment wrong and should instead read "The other possibility is
that credentials were not supplied yet. [...]"? I assume that wrong
credentials should be handled by the code that uses the WebClient, in
response to a HTTP 401 response. Or is there a problem in the logic,
or how can this be reached with wrong credentials?

My Git push code does not handle WebAuthRequired, instead checks for
401 responses, then sets username: and password: on the WebClient,
then repeats the request (actually the WebClient creates a new
WebRequest). This is all done for the first URL accessed during a Git
push. For the second URL, the same WebClient is used (so it should
still have #username and #password) and further 401 responses are
simply wrapped in an exception and signalled without further retry
logic. Is this sound or do you have any remarks about this? It looks
like I could avoid the extra 401 round for the first URL by handling
WebAuthRequired instead of the 401 response. But not for the second
URL, where the failure sometimes occurs.

A different issue: #authRealm seems to be mostly ignored by the
WebClient (it is remembered in the dictionary, but not used
afterwards). That means that a single WebClient used to talk to
different realms of a site or to multiple sites would simply send/leak
the same credentials to all the sites, doesn't it?

Am Sa., 11. Juli 2020 um 15:32 Uhr schrieb Levente Uzonyi
<leves at caesar.elte.hu>:
>
> On Sat, 11 Jul 2020, Jakob Reschke wrote:
>
> > Hi all,
> >
> > Am Sa., 11. Juli 2020 um 13:53 Uhr schrieb Eric Gade <eric.gade at gmail.com>:
> >>
> >>> Could you please inspect whether the `response request` actually
> >>> contains authentication headers? I have seen in the past that
> >>> sometimes the WebClient does not send them when it should.
> >>
> >>
> >> It looks to me like the WebClient's response request (the original request sent I assume) headers *don't* have any Auth information: ` 'an OrderedCollection(''Content-Type''->''application/x-git-receive-pack-request'' ''Content-Length''->5343 ''User-Agent''->''git/2.0.5'' ''Host''->''github.com'')'`
> >>
> >
> > To me these missing auth headers look like a WebClient bug because the
> > GitSmartHTTPProtocol class (comes with the Git Browser) clearly
> > supplies the credentials to the client (see
> > discoverReferencesForService:, requestCredentials, applyCredentials)
> > and uses the same WebClient instance for the whole push operation,
> > which entails two requests (discover references is the first, invoke
> > receive pack is the second).
> >
> > If the misbehavior triggers, the second request is usually the one
> > that is missing the auth headers. I have already seen this
> > sporadically myself, but not lately. Repeating the request (by
> > restarting the method) usually resolves the problem.
> >
> > Does anyone have a hint? It is possible that I have wrong expectations
> > about the WebClient interface and how it remembers the credentials...
>
> Perhaps this part of WebClient >> #sendRequest:contentBlock: is
> responsible:
>
>         "Flush previous authState.
>         XXXX: Fixme. authState must be preserved for pre-authentication of requests."
>         self flushAuthState.
>
> #flushAuthState removes the passed credentials.
>
> Also, any kind of redirect will remove the credentials.
>
>
> Levente
>
> >
> > Kind regards,
> > Jakob
>

From marcel.taeumel at hpi.de  Mon Jul 20 13:52:19 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Mon, 20 Jul 2020 15:52:19 +0200
Subject: [squeak-dev] Fix for Monticello Configuration - Question
	about	Inbox
In-Reply-To: <CAEzdQ-ezcOUTU8Vyn7gxzH-wQu-1uu6f3=YOuwCDbVh-i=jqOw@mail.gmail.com>
References: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
 <Mailbird-61a687f6-e429-4e84-a459-d4e306aad780@hpi.de>
 <CAEzdQ-ezcOUTU8Vyn7gxzH-wQu-1uu6f3=YOuwCDbVh-i=jqOw@mail.gmail.com>
Message-ID: <Mailbird-1fe358bb-5017-4699-b6f8-1e8376b63eb3@hpi.de>

Hi Ron.

>  Did I get that right?  

Yes. And a version gets also moved to Treated if that contribution was already merged otherwise, maybe manually. Or if it is a duplicate. Or no longer valid. :-)

> The number that it picks should be an acceptable number for sending changes?  

Yes, it should be.

> Should we also verify that the number is greater than the last number in Inbox?

Your author initials ... kind of ... represent their own space for version numbers -- except that, for each new version, you should consider the biggest number in current Trunk. +1. :-) We do that to compute the overall build number by adding up all the most recent version numbers from all packages in the "update" map (aka. Monticello Configuration). "Squeak-Version" is the package for correcting that build number, e.g., when removing a package.

So, conflicts mostly happen for a single author who forgot about a version in the local package cache or Inbox or Treated. We can still resolve those conflicts because each version has a UUID. However, the more compact "author.number" form -- stored in the MCZ filename -- is used to find the most recent version without having to open up the MCZ file. The number is not that UUID for the above reason and to keep the file name human-readable. Sort-by-name quickly gives you the name of the newest version.

Duplicate version numbers with different authors are possible BUT should be merged as quickly as possible. :-) So "abc.123" and "def.123" should be merged to "foo.124" to not confuse the in-image update process.

Here is more information: https://squeak.org/development_process/ [https://squeak.org/development_process/]

In Trunk we have this:

MonticelloConfigurations-mt.162

MonticelloConfigurations-dtl.161 --- UUID 67fc

MonticelloConfigurations-mt.160

MonticelloConfigurations-mt.159

...

In Inbox we have this:

MonticelloConfigurations-RJT.163 --- for MonticelloConfigurations-mt.162 --- OK!

MonticelloConfigurations-dtl.160 --- for MonticelloConfigurations-mt.159 --- OK!

MonticelloConfigurations-dtl.161 --- UUID 303c --- for MonticelloConfigurations-dtl.160 --- NAME CONFLICT!

MonticelloConfigurations-dtl.162 --- for MonticelloConfigurations-dtl.161 w/ UUID 303c --- ANCESTOR CONFLICT!

MonticelloConfigurations-dtl.163 --- for MonticelloConfigurations-dtl.162 --- INDIRECT ANCESTOR CONFLICT!

MonticelloConfigurations-dtl.164 --- for MonticelloConfigurations-dtl.163 --- INDIRECT ANCESTOR CONFLICT!

MonticelloConfigurations-dtl.165 --- for MonticelloConfigurations-dtl.164 --- INDIRECT ANCESTOR CONFLICT!

MonticelloConfigurations-dtl.166 --- for MonticelloConfigurations-dtl.165 --- INDIRECT ANCESTOR CONFLICT!

MonticelloConfigurations-dtl.167 --- for MonticelloConfigurations-dtl.166 --- INDIRECT ANCESTOR CONFLICT!


Well, it is correct that improvements to existing inbox contributions build on those versions and not on the recent trunk. However, in this case, dtl.161 and dtl.162 introduced a hidden conflict in (file) name and ancestry, which renders all following dtl.* commits problematic. A manual merge would be necessary. All those conflicting versions should be moved to Treated after the merge of their contents.

Best,
Marcel
Am 20.07.2020 15:15:10 schrieb Ron Teitelbaum <ron at usmedrec.com>:
Hi Marcel,

Thanks for the suggestion.  I wasn't aware of Treated but I went and looked it up.  So things that are sent to Inbox are then moved to either Trunk if accepted or Treated if not accepted.  Did I get that right?  

So someone that wants to contribute should load (or merge) the trunk latest version but also add Inbox and Treated as repositories to the package for automatic monticello numbering.  Then save the change verifying that only their changes show up.  The number that it picks should be an acceptable number for sending changes?  Should we also verify that the number is greater than the last number in Inbox?

Thanks!

Ron

On Mon, Jul 20, 2020 at 5:02 AM Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> wrote:

Hi Ron.

Thank you! =)

> Realized after the save that the number it picked was a duplicate of other changes added to inbox.

Make sure to have all three repos in that package's repository group: Trunk, Inbox, Treated. Then the automatic version number calculation will work. Your local package cache will be considered, too.

A small gap in a new version number is okay.

Best,
Marcel
Am 18.07.2020 19:55:41 schrieb Ron Teitelbaum <ron at usmedrec.com [mailto:ron at usmedrec.com]>:
Hi All,

I Added a fix but not sure I did it correctly.  Inbox has other non merged changes on it for Monticello Configurations.  Realized after the save that the number it picked was a duplicate of other changes added to inbox.


my change: "
Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticello Configurations so that it automatically selects the package that is moved.  This allows you to push the button more than once without having to select the package again.

"

What should I have done in this situation?  Do we just pick a later version number.  I'm assuming here that we do not merge in others changes to your own change set.  

Thanks for your help.

Ron Teitelbaum 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200720/f2c5b92f/attachment.html>

From ron at usmedrec.com  Mon Jul 20 14:33:51 2020
From: ron at usmedrec.com (Ron Teitelbaum)
Date: Mon, 20 Jul 2020 10:33:51 -0400
Subject: [squeak-dev] Fix for Monticello Configuration - Question about
	Inbox
In-Reply-To: <Mailbird-1fe358bb-5017-4699-b6f8-1e8376b63eb3@hpi.de>
References: <CAEzdQ-fPoAK5jjwntqab1qWUAGu2pw_at2QAXb=15v8wWWjo8g@mail.gmail.com>
 <Mailbird-61a687f6-e429-4e84-a459-d4e306aad780@hpi.de>
 <CAEzdQ-ezcOUTU8Vyn7gxzH-wQu-1uu6f3=YOuwCDbVh-i=jqOw@mail.gmail.com>
 <Mailbird-1fe358bb-5017-4699-b6f8-1e8376b63eb3@hpi.de>
Message-ID: <CAEzdQ-c6Gioi2Hz8bgutFH6vyo7Qe1r_DcxssVx8smOWYhVmcw@mail.gmail.com>

Hi Marcel,

Thanks.  That all makes sense.

Ron

On Mon, Jul 20, 2020 at 9:52 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Ron.
>
> >  Did I get that right?
>
> Yes. And a version gets also moved to Treated if that contribution was
> already merged otherwise, maybe manually. Or if it is a duplicate. Or no
> longer valid. :-)
>
> > The number that it picks should be an acceptable number for sending
> changes?
>
> Yes, it should be.
>
> > Should we also verify that the number is greater than the last number in
> Inbox?
>
> Your author initials ... kind of ... represent their own space for version
> numbers -- except that, for each new version, you should consider the
> biggest number in current Trunk. +1. :-) We do that to compute the overall
> build number by adding up all the most recent version numbers from all
> packages in the "update" map (aka. Monticello Configuration).
> "Squeak-Version" is the package for correcting that build number, e.g.,
> when removing a package.
>
> So, conflicts mostly happen for a single author who forgot about a version
> in the local package cache or Inbox or Treated. We can still resolve those
> conflicts because each version has a UUID. However, the more compact
> "author.number" form -- stored in the MCZ filename -- is used to find the
> most recent version without having to open up the MCZ file. The number is
> not that UUID for the above reason and to keep the file name
> human-readable. Sort-by-name quickly gives you the name of the newest
> version.
>
> Duplicate version numbers with different authors are possible BUT should
> be merged as quickly as possible. :-) So "abc.123" and "def.123" should be
> merged to "foo.124" to not confuse the in-image update process.
>
> Here is more information: https://squeak.org/development_process/
>
> In Trunk we have this:
>
> MonticelloConfigurations-mt.162
> MonticelloConfigurations-dtl.161 --- UUID 67fc
> MonticelloConfigurations-mt.160
> MonticelloConfigurations-mt.159
> ...
>
> In Inbox we have this:
>
> MonticelloConfigurations-RJT.163 --- for MonticelloConfigurations-mt.162
> --- OK!
>
> MonticelloConfigurations-dtl.160 --- for MonticelloConfigurations-mt.159
> --- OK!
> MonticelloConfigurations-dtl.161 --- UUID 303c --- for MonticelloConfigurations-dtl.160
> --- NAME CONFLICT!
> MonticelloConfigurations-dtl.162 --- for MonticelloConfigurations-dtl.161
> w/ UUID 303c --- ANCESTOR CONFLICT!
> MonticelloConfigurations-dtl.163 --- for MonticelloConfigurations-dtl.162
> --- INDIRECT ANCESTOR CONFLICT!
> MonticelloConfigurations-dtl.164 --- for MonticelloConfigurations-dtl.163
> --- INDIRECT ANCESTOR CONFLICT!
> MonticelloConfigurations-dtl.165 --- for MonticelloConfigurations-dtl.164
> --- INDIRECT ANCESTOR CONFLICT!
> MonticelloConfigurations-dtl.166 --- for MonticelloConfigurations-dtl.165
> --- INDIRECT ANCESTOR CONFLICT!
> MonticelloConfigurations-dtl.167 --- for MonticelloConfigurations-dtl.166
> --- INDIRECT ANCESTOR CONFLICT!
>
> Well, it is correct that improvements to existing inbox contributions
> build on those versions and not on the recent trunk. However, in this case,
> dtl.161 and dtl.162 introduced a hidden conflict in (file) name and
> ancestry, which renders all following dtl.* commits problematic. A manual
> merge would be necessary. All those conflicting versions should be moved to
> Treated after the merge of their contents.
>
> Best,
> Marcel
>
> Am 20.07.2020 15:15:10 schrieb Ron Teitelbaum <ron at usmedrec.com>:
> Hi Marcel,
>
> Thanks for the suggestion.  I wasn't aware of Treated but I went and
> looked it up.  So things that are sent to Inbox are then moved to either
> Trunk if accepted or Treated if not accepted.  Did I get that right?
>
> So someone that wants to contribute should load (or merge) the trunk
> latest version but also add Inbox and Treated as repositories to the
> package for automatic monticello numbering.  Then save the change verifying
> that only their changes show up.  The number that it picks should be an
> acceptable number for sending changes?  Should we also verify that the
> number is greater than the last number in Inbox?
>
> Thanks!
>
> Ron
>
> On Mon, Jul 20, 2020 at 5:02 AM Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
>
>> Hi Ron.
>>
>> Thank you! =)
>>
>> > Realized after the save that the number it picked was a duplicate of
>> other changes added to inbox.
>>
>> Make sure to have all three repos in that package's repository group:
>> Trunk, Inbox, Treated. Then the automatic version number calculation will
>> work. Your local package cache will be considered, too.
>>
>> A small gap in a new version number is okay.
>>
>> Best,
>> Marcel
>>
>> Am 18.07.2020 19:55:41 schrieb Ron Teitelbaum <ron at usmedrec.com>:
>> Hi All,
>>
>> I Added a fix but not sure I did it correctly.  Inbox has other non
>> merged changes on it for Monticello Configurations.  Realized after the
>> save that the number it picked was a duplicate of other changes added to
>> inbox.
>>
>> my change: "
>> Name: MonticelloConfigurations-RJT.163
>> Author: RJT
>> Time: 18 July 2020, 1:47:16.459316 pm
>> UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
>> Ancestors: MonticelloConfigurations-mt.162
>>
>> Fix the up and down button (to change the load order) of Monticello
>> Configurations so that it automatically selects the package that is moved.
>> This allows you to push the button more than once without having to select
>> the package again.
>> "
>>
>> What should I have done in this situation?  Do we just pick a later
>> version number.  I'm assuming here that we do not merge in others changes
>> to your own change set.
>>
>> Thanks for your help.
>>
>> Ron Teitelbaum
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200720/b58b1c47/attachment.html>

From commits at source.squeak.org  Mon Jul 20 14:51:15 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Mon, 20 Jul 2020 14:51:15 0000
Subject: [squeak-dev] The Trunk: Collections-ul.903.mcz
Message-ID: <E1jxX8Q-0003UI-Sb@andreas>

Levente Uzonyi uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-ul.903.mcz

==================== Summary ====================

Name: Collections-ul.903
Author: ul
Time: 16 July 2020, 2:43:29.805477 pm
UUID: 8864e74e-e7c5-4419-b789-cb6b0889df42
Ancestors: Collections-ul.902

- let String >> #compareWith: use primitive 158 even if indirectly

=============== Diff against Collections-ul.902 ===============

Item was changed:
  ----- Method: String>>compareWith: (in category 'comparing') -----
  compareWith: aString
  
  	"<primitive: 158>"
+ 	^self compareWith: aString collated: AsciiOrder!
- 	^(self compare: self with: aString collated: AsciiOrder) - 2!


From gettimothy at zoho.com  Mon Jul 20 18:03:39 2020
From: gettimothy at zoho.com (gettimothy)
Date: Mon, 20 Jul 2020 14:03:39 -0400
Subject: [squeak-dev] A big thank you to whoever made the tree in FileList
 display in alphabetical order
Message-ID: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>

+!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200720/4aee66b7/attachment.html>

From tim at rowledge.org  Mon Jul 20 20:08:57 2020
From: tim at rowledge.org (tim Rowledge)
Date: Mon, 20 Jul 2020 13:08:57 -0700
Subject: [squeak-dev] Time>addSeconds: ignores nanos ivar value
Message-ID: <D328C6DF-31DA-42B3-97C3-EFC1BB1CD0B3@rowledge.org>

Time >addSeconds: completely ignores the nanos ivar value and so
Time now -> (say)  12:51:47.418205 pm
send that #addSeconds: 2 -> 12:51:49 pm

Which is incorrect. Actually *fixing* it seems to be a bit more complex than just "add the nanoseconds stuff".

Should #asSeconds be truncating the seconds and ignoring the nanoseconds? That's also an issue for #addTime: and #subtractTime: (wait, no #subtractSeconds: ?)

Chronology-afficonados assemble!

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Fractured Idiom:- PRO BOZO PUBLICO - Support your local clown



From lewis at mail.msen.com  Mon Jul 20 20:45:46 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Mon, 20 Jul 2020 16:45:46 -0400
Subject: [squeak-dev] Time>addSeconds: ignores nanos ivar value
In-Reply-To: <D328C6DF-31DA-42B3-97C3-EFC1BB1CD0B3@rowledge.org>
References: <D328C6DF-31DA-42B3-97C3-EFC1BB1CD0B3@rowledge.org>
Message-ID: <20200720204546.GA56138@shell.msen.com>

On Mon, Jul 20, 2020 at 01:08:57PM -0700, tim Rowledge wrote:
> Time >addSeconds: completely ignores the nanos ivar value and so
> Time now -> (say)  12:51:47.418205 pm
> send that #addSeconds: 2 -> 12:51:49 pm
> 
> Which is incorrect. Actually *fixing* it seems to be a bit more complex than just "add the nanoseconds stuff".
> 
> Should #asSeconds be truncating the seconds and ignoring the nanoseconds? That's also an issue for #addTime: and #subtractTime: (wait, no #subtractSeconds: ?)
> 
> Chronology-afficonados assemble!
> 
> tim

It looks broken to me. And deserving of a unit test to document the expected result.

In Squeak 3.8 #addSeconds: seems to do the same thing, but "Time now" gives
an instance with nanos equal to zero, so possibly it is old behavior that
was just not noticed.

In DateAndTime, we introduced #asExactSeconds to allow backward compatibility
with the original #asSeconds that answered whole seconds. Maybe something
similar would be needed for Time.

Or maybe it should just be this:

Time class>>addSeconds: nSeconds 
	"Answer a Time that is nSeconds after the receiver."

	^ self class
		seconds:seconds + nSeconds
		nanoSeconds: nanos


Either way a unit test is the first step. The existing TimeTest>>testAddSeconds
does not provide any coverage for instances of Time with non-zero nanos.

Dave


From tim at rowledge.org  Mon Jul 20 21:00:40 2020
From: tim at rowledge.org (tim Rowledge)
Date: Mon, 20 Jul 2020 14:00:40 -0700
Subject: [squeak-dev] Time>addSeconds: ignores nanos ivar value
In-Reply-To: <20200720204546.GA56138@shell.msen.com>
References: <D328C6DF-31DA-42B3-97C3-EFC1BB1CD0B3@rowledge.org>
 <20200720204546.GA56138@shell.msen.com>
Message-ID: <89CE5045-398C-4C5F-AC42-20B945382C1C@rowledge.org>

It isn't my field at all but since time is not really quantised until Plank-time scale, shouldn't we be using floating point for seconds? Or is the argument that keeping a couple of integers is 'cheaper'?

Also, should the added seconds be restricted to an integer number of seconds? What ought happen if a float is passed in?

> On 2020-07-20, at 1:45 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> On Mon, Jul 20, 2020 at 01:08:57PM -0700, tim Rowledge wrote:
>> Time >addSeconds: completely ignores the nanos ivar value and so
>> Time now -> (say)  12:51:47.418205 pm
>> send that #addSeconds: 2 -> 12:51:49 pm
>> 
>> Which is incorrect. Actually *fixing* it seems to be a bit more complex than just "add the nanoseconds stuff".
>> 
>> Should #asSeconds be truncating the seconds and ignoring the nanoseconds? That's also an issue for #addTime: and #subtractTime: (wait, no #subtractSeconds: ?)
>> 
>> Chronology-afficonados assemble!
>> 
>> tim
> 
> It looks broken to me. And deserving of a unit test to document the expected result.
> 
> In Squeak 3.8 #addSeconds: seems to do the same thing, but "Time now" gives
> an instance with nanos equal to zero, so possibly it is old behavior that
> was just not noticed.
> 
> In DateAndTime, we introduced #asExactSeconds to allow backward compatibility
> with the original #asSeconds that answered whole seconds. Maybe something
> similar would be needed for Time.
> 
> Or maybe it should just be this:
> 
> Time class>>addSeconds: nSeconds 
> 	"Answer a Time that is nSeconds after the receiver."
> 
> 	^ self class
> 		seconds:seconds + nSeconds
> 		nanoSeconds: nanos
> 
> 
> Either way a unit test is the first step. The existing TimeTest>>testAddSeconds
> does not provide any coverage for instances of Time with non-zero nanos.
> 
> Dave
> 
> 
> 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Press [ESC] to detonate or any other key to explode.



From lewis at mail.msen.com  Mon Jul 20 23:56:50 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Mon, 20 Jul 2020 19:56:50 -0400
Subject: [squeak-dev] Time>addSeconds: ignores nanos ivar value
In-Reply-To: <89CE5045-398C-4C5F-AC42-20B945382C1C@rowledge.org>
References: <D328C6DF-31DA-42B3-97C3-EFC1BB1CD0B3@rowledge.org>
 <20200720204546.GA56138@shell.msen.com>
 <89CE5045-398C-4C5F-AC42-20B945382C1C@rowledge.org>
Message-ID: <20200720235650.GA83769@shell.msen.com>

No, the magnitude of time should not be a Float. Nor should it be an Integer.

It should be a Number.

In practice, the numbers tend to be integer-ish in nature for one of two reasons:

1) The time value is derived from a system call to some computer operating
system that reports time that way. DateAndTime now has integral instance
variables for this reason.

2) The user is thinking of "time" as something that shows up on a Timex
digital wristwatch display, or on a wind-up clock that makes loud ticking
noises on integer boundaries. Time>>addSeconds: is an example of that
mindset.

Having said that, there is absolutely no reason that this should not work:

   DateAndTime fromSeconds: Float pi

Which it does. And you will find that the magnitude (utcMicroseconds instance
variable) is in fact a SmallFloat64 as it should be.

But in practice Integer, Fraction, and ScaledDecimal are the must useful
and common types of Number to use when representing a time magnitude.

Dave


On Mon, Jul 20, 2020 at 02:00:40PM -0700, tim Rowledge wrote:
> It isn't my field at all but since time is not really quantised until Plank-time scale, shouldn't we be using floating point for seconds? Or is the argument that keeping a couple of integers is 'cheaper'?
> 
> Also, should the added seconds be restricted to an integer number of seconds? What ought happen if a float is passed in?
> 
> > On 2020-07-20, at 1:45 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > On Mon, Jul 20, 2020 at 01:08:57PM -0700, tim Rowledge wrote:
> >> Time >addSeconds: completely ignores the nanos ivar value and so
> >> Time now -> (say)  12:51:47.418205 pm
> >> send that #addSeconds: 2 -> 12:51:49 pm
> >> 
> >> Which is incorrect. Actually *fixing* it seems to be a bit more complex than just "add the nanoseconds stuff".
> >> 
> >> Should #asSeconds be truncating the seconds and ignoring the nanoseconds? That's also an issue for #addTime: and #subtractTime: (wait, no #subtractSeconds: ?)
> >> 
> >> Chronology-afficonados assemble!
> >> 
> >> tim
> > 
> > It looks broken to me. And deserving of a unit test to document the expected result.
> > 
> > In Squeak 3.8 #addSeconds: seems to do the same thing, but "Time now" gives
> > an instance with nanos equal to zero, so possibly it is old behavior that
> > was just not noticed.
> > 
> > In DateAndTime, we introduced #asExactSeconds to allow backward compatibility
> > with the original #asSeconds that answered whole seconds. Maybe something
> > similar would be needed for Time.
> > 
> > Or maybe it should just be this:
> > 
> > Time class>>addSeconds: nSeconds 
> > 	"Answer a Time that is nSeconds after the receiver."
> > 
> > 	^ self class
> > 		seconds:seconds + nSeconds
> > 		nanoSeconds: nanos
> > 
> > 
> > Either way a unit test is the first step. The existing TimeTest>>testAddSeconds
> > does not provide any coverage for instances of Time with non-zero nanos.
> > 
> > Dave
> > 
> > 
> > 
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Press [ESC] to detonate or any other key to explode.
> 
> 
> 

From eliot.miranda at gmail.com  Tue Jul 21 00:55:07 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Mon, 20 Jul 2020 17:55:07 -0700
Subject: [squeak-dev] trunk and new vm etiquette
Message-ID: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>

Hi All,
    I've just found and fixed a VM bug in an as-yet-unpublished pair of
primitives that replace FloatArrayPlugin>>primitiveAt[Put] and
Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows
two methods (at:[put:]) in FloatArray to relace four methods
(Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times
faster than the plugin methods.  The issue is when to publish the
corrections to trunk.

Since the existing VM is broken I don't want to simply push to trunk and
have people inconvenienced by a sudden emergence of failures in the
FoatArrayTests.  However, I do want to push the corrections soon, because
they're a substantial improvement.  So the question is how long should I
wait?

Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do
people using trunk keep an eye on the CI builds and upgrade, or would they
appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask
that you upgrade your VM.
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200720/16491cd5/attachment.html>

From commits at source.squeak.org  Tue Jul 21 07:04:28 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Tue, 21 Jul 2020 07:04:28 0000
Subject: [squeak-dev] The Trunk: System-mt.1167.mcz
Message-ID: <E1jxmKG-000067-Jv@andreas>

Marcel Taeumel uploaded a new version of System to project The Trunk:
http://source.squeak.org/trunk/System-mt.1167.mcz

==================== Summary ====================

Name: System-mt.1167
Author: mt
Time: 21 July 2020, 9:04:24.515795 am
UUID: 962f538f-4a49-4832-8488-4337395436fc
Ancestors: System-mt.1166

In code holders, avoid label contraction in dialogs' buttons that pop up when having to choose a symbol for browsing senders/implementors.

=============== Diff against System-mt.1166 ===============

Item was changed:
  ----- Method: SystemNavigation>>showMenuOf:withFirstItem:ifChosenDo:withCaption: (in category 'ui') -----
  showMenuOf: selectorCollection withFirstItem: firstItem ifChosenDo: choiceBlock withCaption: aCaption
+ 	"Show a sorted menu of the given selectors, preceded by firstItem.  Use aCaption as the menu title, if it is not nil.  Evaluate choiceBlock if a message is chosen."
- 	"Show a sorted menu of the given selectors, preceded by firstItem, and all abbreviated to 40 characters.  Use aCaption as the menu title, if it is not nil.  Evaluate choiceBlock if a message is chosen."
  
  	| index menuLabels sortedList |
  	sortedList := selectorCollection sorted.
  	menuLabels := Array streamContents: 
+ 		[:strm | strm nextPut: firstItem.
+ 		sortedList do: [:sel | strm nextPut: sel]].
- 		[:strm | strm nextPut: (firstItem contractTo: 40).
- 		sortedList do: [:sel | strm nextPut: (sel contractTo: 40)]].
  	index := UIManager default chooseFrom: menuLabels lines: #(1).
  	index = 1 ifTrue: [choiceBlock value: firstItem].
  	index > 1 ifTrue: [choiceBlock value: (sortedList at: index - 1)]!


From marcel.taeumel at hpi.de  Tue Jul 21 08:36:05 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Tue, 21 Jul 2020 10:36:05 +0200
Subject: [squeak-dev] MNU for ifNil: to preserve quick returns? :-)
Message-ID: <Mailbird-d51422e2-2a6a-4aa8-921a-e11d230a565a@hpi.de>

Hi all!

I can choose to initialize an instVar eagerly in #initialize or lazily in its accessor via #ifNil:. Yet, the latter requires me to change that accessor to something not being a quick return.

Could there be a simple way to initialize an instVar on its first read access? Like a #notYetInitialized: callback to the instVar-holding receiver. Instead, we get an MNU on UndefiniedObject ... 

(Why? Performance reasons for a little project of mine.)

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/a967c792/attachment.html>

From forums.jakob at resfarm.de  Tue Jul 21 09:45:27 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Tue, 21 Jul 2020 11:45:27 +0200
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
References: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
Message-ID: <CA+ovNC5MT_54K7WR0detfxAk6ed8XYG7ehBYmA9PWzyQWFnqmQ@mail.gmail.com>

Hi Eliot,

I only ever upgrade my VM if something breaks or if I am asked to. So
if you'd post a message with something like "Please upgrade your VM"
in the subject line to the list once you push the changes to Trunk,
that would be great for me!

Concerning the time span: in an ideal world I would say "as soon as
the CI is green", but I have my doubts that this will be enough for
Squeak. Assuming that you use the new VM immediately and frequently
(or anyone else does), I think a day of work up to a week after the VM
changes is fine. Or as soon as you are confident about it, however you
measure that. ;-)

Kind regards,
Jakob

Am Di., 21. Juli 2020 um 02:55 Uhr schrieb Eliot Miranda
<eliot.miranda at gmail.com>:
>
> Hi All,
>     I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows two methods (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods.  The issue is when to publish the corrections to trunk.
>
> Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests.  However, I do want to push the corrections soon, because they're a substantial improvement.  So the question is how long should I wait?
>
> Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM.
> _,,,^..^,,,_
> best, Eliot
>

From forums.jakob at resfarm.de  Tue Jul 21 10:07:22 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Tue, 21 Jul 2020 12:07:22 +0200
Subject: [squeak-dev] MNU for ifNil: to preserve quick returns? :-)
In-Reply-To: <Mailbird-d51422e2-2a6a-4aa8-921a-e11d230a565a@hpi.de>
References: <Mailbird-d51422e2-2a6a-4aa8-921a-e11d230a565a@hpi.de>
Message-ID: <CA+ovNC4F+2-ZteesDVGPfgaGumS-A77eeTyPn40WxNgYx95U2Q@mail.gmail.com>

Hi Marcel,

Might be cool if the JIT or Scorch emitted code that is equivalent to
a quick return, but with a low-level nil-guard in place. Like a
quick-return-if-not-nil primitive code.

Is eager initialization out of the question for you?

If all your instVars were initialized on the first read of one of
them, you could also change the class of the object after the lazy
initialization, and the new class would have quick accessors. For
added fanciness, you could auto-generate the "optimized" class and
such accessors in both classes. Though I am totally not sure whether
it is worth the effort or improves the performance at all (since the
call sites are then polymorphic).

notYetInitialized: sounds strange to me, since you could send the
getter in one place and actually use the answer in a totally different
place (where your MNU happens). You could eager-initialize and return
some special case proxy instead of nil that is bound to the original
receiver and takes care of the lazy initialization when called.

Kind regards,
Jakob

Am Di., 21. Juli 2020 um 10:36 Uhr schrieb Marcel Taeumel
<marcel.taeumel at hpi.de>:
>
> Hi all!
>
> I can choose to initialize an instVar eagerly in #initialize or lazily in its accessor via #ifNil:. Yet, the latter requires me to change that accessor to something not being a quick return.
>
> Could there be a simple way to initialize an instVar on its first read access? Like a #notYetInitialized: callback to the instVar-holding receiver. Instead, we get an MNU on UndefiniedObject ...
>
> (Why? Performance reasons for a little project of mine.)
>
> Best,
> Marcel
>

From marcel.taeumel at hpi.de  Tue Jul 21 10:22:35 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Tue, 21 Jul 2020 12:22:35 +0200
Subject: [squeak-dev] MNU for ifNil: to preserve quick returns? :-)
In-Reply-To: <CA+ovNC4F+2-ZteesDVGPfgaGumS-A77eeTyPn40WxNgYx95U2Q@mail.gmail.com>
References: <Mailbird-d51422e2-2a6a-4aa8-921a-e11d230a565a@hpi.de>
 <CA+ovNC4F+2-ZteesDVGPfgaGumS-A77eeTyPn40WxNgYx95U2Q@mail.gmail.com>
Message-ID: <Mailbird-5c7c5bd2-4946-4c0e-93e9-0d39e61dc159@hpi.de>

> Is eager initialization out of the question for you?

Not quite. But saving 400 000 extra objects where each may have 5 to 10 instVars ... could be worthwhile if those are not used at all. I suppose that all instVars being "nil" is not optimized in the VM?

Best,
Marcel
Am 21.07.2020 12:07:44 schrieb Jakob Reschke <forums.jakob at resfarm.de>:
Hi Marcel,

Might be cool if the JIT or Scorch emitted code that is equivalent to
a quick return, but with a low-level nil-guard in place. Like a
quick-return-if-not-nil primitive code.

Is eager initialization out of the question for you?

If all your instVars were initialized on the first read of one of
them, you could also change the class of the object after the lazy
initialization, and the new class would have quick accessors. For
added fanciness, you could auto-generate the "optimized" class and
such accessors in both classes. Though I am totally not sure whether
it is worth the effort or improves the performance at all (since the
call sites are then polymorphic).

notYetInitialized: sounds strange to me, since you could send the
getter in one place and actually use the answer in a totally different
place (where your MNU happens). You could eager-initialize and return
some special case proxy instead of nil that is bound to the original
receiver and takes care of the lazy initialization when called.

Kind regards,
Jakob

Am Di., 21. Juli 2020 um 10:36 Uhr schrieb Marcel Taeumel
:
>
> Hi all!
>
> I can choose to initialize an instVar eagerly in #initialize or lazily in its accessor via #ifNil:. Yet, the latter requires me to change that accessor to something not being a quick return.
>
> Could there be a simple way to initialize an instVar on its first read access? Like a #notYetInitialized: callback to the instVar-holding receiver. Instead, we get an MNU on UndefiniedObject ...
>
> (Why? Performance reasons for a little project of mine.)
>
> Best,
> Marcel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/cdf824fa/attachment-0001.html>

From lists at fniephaus.com  Tue Jul 21 11:19:47 2020
From: lists at fniephaus.com (Fabio Niephaus)
Date: Tue, 21 Jul 2020 13:19:47 +0200
Subject: [squeak-dev] MNU for ifNil: to preserve quick returns? :-)
In-Reply-To: <CA+ovNC4F+2-ZteesDVGPfgaGumS-A77eeTyPn40WxNgYx95U2Q@mail.gmail.com>
References: <Mailbird-d51422e2-2a6a-4aa8-921a-e11d230a565a@hpi.de>
 <CA+ovNC4F+2-ZteesDVGPfgaGumS-A77eeTyPn40WxNgYx95U2Q@mail.gmail.com>
Message-ID: <CADfnKi50aK=qMdrB7pXCWABNmdx1F2h3WJ81qWJHC97x4CS7wA@mail.gmail.com>

On Tue, Jul 21, 2020 at 12:07 PM Jakob Reschke <forums.jakob at resfarm.de>
wrote:

> Hi Marcel,
>
> Might be cool if the JIT or Scorch emitted code that is equivalent to
> a quick return, but with a low-level nil-guard in place. Like a
> quick-return-if-not-nil primitive code.
>

In TruffleSqueak, we profile how often a branch is taken. The init branch
is only taken once, so it's unlikely to be part of the compiled code
emitted by the JIT. The decrease in code size then makes it very likely
that inlining is going to happen. Not sure if the OpenSmalltalkVM has
similar optimizations for this in place.

Fabio


>
> Is eager initialization out of the question for you?
>
> If all your instVars were initialized on the first read of one of
> them, you could also change the class of the object after the lazy
> initialization, and the new class would have quick accessors. For
> added fanciness, you could auto-generate the "optimized" class and
> such accessors in both classes. Though I am totally not sure whether
> it is worth the effort or improves the performance at all (since the
> call sites are then polymorphic).
>
> notYetInitialized: sounds strange to me, since you could send the
> getter in one place and actually use the answer in a totally different
> place (where your MNU happens). You could eager-initialize and return
> some special case proxy instead of nil that is bound to the original
> receiver and takes care of the lazy initialization when called.
>
> Kind regards,
> Jakob
>
> Am Di., 21. Juli 2020 um 10:36 Uhr schrieb Marcel Taeumel
> <marcel.taeumel at hpi.de>:
> >
> > Hi all!
> >
> > I can choose to initialize an instVar eagerly in #initialize or lazily
> in its accessor via #ifNil:. Yet, the latter requires me to change that
> accessor to something not being a quick return.
> >
> > Could there be a simple way to initialize an instVar on its first read
> access? Like a #notYetInitialized: callback to the instVar-holding
> receiver. Instead, we get an MNU on UndefiniedObject ...
> >
> > (Why? Performance reasons for a little project of mine.)
> >
> > Best,
> > Marcel
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/4c83ba92/attachment.html>

From marcel.taeumel at hpi.de  Tue Jul 21 12:24:32 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Tue, 21 Jul 2020 14:24:32 +0200
Subject: [squeak-dev] SmallInteger someInstance == nil :(
Message-ID: <Mailbird-27667c62-5b9f-4e8e-8bed-e23557868b1b@hpi.de>

Hi all!

Why is "SmallInteger someInstance == nil"?

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/1531bd1d/attachment.html>

From lists at fniephaus.com  Tue Jul 21 12:53:04 2020
From: lists at fniephaus.com (Fabio Niephaus)
Date: Tue, 21 Jul 2020 14:53:04 +0200
Subject: [squeak-dev] SmallInteger someInstance == nil :(
In-Reply-To: <Mailbird-27667c62-5b9f-4e8e-8bed-e23557868b1b@hpi.de>
References: <Mailbird-27667c62-5b9f-4e8e-8bed-e23557868b1b@hpi.de>
Message-ID: <CADfnKi5whE7SSXE2EpNqkpH0u6_fB10NMDToUy6e02HLR_UPjg@mail.gmail.com>

On Tue, Jul 21, 2020 at 2:24 PM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi all!
>
> Why is "SmallInteger someInstance == nil"?
>

Because SmallIntegers are immediate and cannot be instantiated
(`SmallInteger new` fails). This implies:

"SmallFloat64 someInstance == nil"
"Character someInstance == nil"

Why would you want someInstance of SmallInteger anyway?

Fabio


>
> Best,
> Marcel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/1c8b7a10/attachment.html>

From marcel.taeumel at hpi.de  Tue Jul 21 13:07:01 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Tue, 21 Jul 2020 15:07:01 +0200
Subject: [squeak-dev] SmallInteger someInstance == nil :(
In-Reply-To: <CADfnKi5whE7SSXE2EpNqkpH0u6_fB10NMDToUy6e02HLR_UPjg@mail.gmail.com>
References: <Mailbird-27667c62-5b9f-4e8e-8bed-e23557868b1b@hpi.de>
 <CADfnKi5whE7SSXE2EpNqkpH0u6_fB10NMDToUy6e02HLR_UPjg@mail.gmail.com>
Message-ID: <Mailbird-6befdb68-8560-475a-b9f2-dfd5d37f2364@hpi.de>

Hi Fabio.

>From an object-oriented perspective, it would be nice to get "some instance" when asking a class in the system for #someInstance. :-)

As it is now, I have to start writing a little lookup table with "class == SmallInteger ifTrue: [ .... ]" to lookup exemplary instances for some classes in the system.

Best,
Marcel



Am 21.07.2020 14:53:31 schrieb Fabio Niephaus <lists at fniephaus.com>:
On Tue, Jul 21, 2020 at 2:24 PM Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> wrote:

Hi all!

Why is "SmallInteger someInstance == nil"?

Because SmallIntegers are immediate and cannot be instantiated (`SmallInteger new` fails). This implies:

"SmallFloat64 someInstance == nil"
"Character someInstance == nil"

Why would you want someInstance of SmallInteger anyway?

Fabio
 

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/ae08f0ad/attachment.html>

From marcel.taeumel at hpi.de  Tue Jul 21 13:08:05 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Tue, 21 Jul 2020 15:08:05 +0200
Subject: [squeak-dev] SmallInteger someInstance == nil :(
In-Reply-To: <Mailbird-6befdb68-8560-475a-b9f2-dfd5d37f2364@hpi.de>
References: <Mailbird-27667c62-5b9f-4e8e-8bed-e23557868b1b@hpi.de>
 <CADfnKi5whE7SSXE2EpNqkpH0u6_fB10NMDToUy6e02HLR_UPjg@mail.gmail.com>
 <Mailbird-6befdb68-8560-475a-b9f2-dfd5d37f2364@hpi.de>
Message-ID: <Mailbird-7d027db9-e2aa-46cc-8492-aa848c374fc1@hpi.de>

Maybe I can check for #isImmediateClass first :-)
Am 21.07.2020 15:07:01 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi Fabio.

>From an object-oriented perspective, it would be nice to get "some instance" when asking a class in the system for #someInstance. :-)

As it is now, I have to start writing a little lookup table with "class == SmallInteger ifTrue: [ .... ]" to lookup exemplary instances for some classes in the system.

Best,
Marcel



Am 21.07.2020 14:53:31 schrieb Fabio Niephaus <lists at fniephaus.com>:
On Tue, Jul 21, 2020 at 2:24 PM Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> wrote:

Hi all!

Why is "SmallInteger someInstance == nil"?

Because SmallIntegers are immediate and cannot be instantiated (`SmallInteger new` fails). This implies:

"SmallFloat64 someInstance == nil"
"Character someInstance == nil"

Why would you want someInstance of SmallInteger anyway?

Fabio
 

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/5f378a03/attachment.html>

From lists at fniephaus.com  Tue Jul 21 13:20:43 2020
From: lists at fniephaus.com (Fabio Niephaus)
Date: Tue, 21 Jul 2020 15:20:43 +0200
Subject: [squeak-dev] SmallInteger someInstance == nil :(
In-Reply-To: <Mailbird-7d027db9-e2aa-46cc-8492-aa848c374fc1@hpi.de>
References: <Mailbird-27667c62-5b9f-4e8e-8bed-e23557868b1b@hpi.de>
 <CADfnKi5whE7SSXE2EpNqkpH0u6_fB10NMDToUy6e02HLR_UPjg@mail.gmail.com>
 <Mailbird-6befdb68-8560-475a-b9f2-dfd5d37f2364@hpi.de>
 <Mailbird-7d027db9-e2aa-46cc-8492-aa848c374fc1@hpi.de>
Message-ID: <CADfnKi6S9kCsiw8PZNZpyst-5tto1VMsvEQvwg93zisN8=FAEg@mail.gmail.com>

On Tue, Jul 21, 2020 at 3:08 PM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Maybe I can check for #isImmediateClass first :-)
>

That's a good idea. Note that primitiveSomeInstance also returns nil in
case no instance exists (e.g. `EToyProjectDetailsMorph someInstance ==
nil`).
I believe the behavior you observe wrt immediates has historical reasons:
#someInstance returns the first instance found in the object memory, and
you can use #nextInstance: for iteration (this mechanism was later replaced
by #allInstances). Iterating instances doesn't make sense for immediates,
the "same instance" can occur multiple times in the heap.

Fabio

> Am 21.07.2020 15:07:01 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> Hi Fabio.
>
> From an object-oriented perspective, it would be nice to get "some
> instance" when asking a class in the system for #someInstance. :-)
>
> As it is now, I have to start writing a little lookup table with "class ==
> SmallInteger ifTrue: [ .... ]" to lookup exemplary instances for some
> classes in the system.
>
> Best,
> Marcel
>
>
> Am 21.07.2020 14:53:31 schrieb Fabio Niephaus <lists at fniephaus.com>:
> On Tue, Jul 21, 2020 at 2:24 PM Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
>
>> Hi all!
>>
>> Why is "SmallInteger someInstance == nil"?
>>
>
> Because SmallIntegers are immediate and cannot be instantiated
> (`SmallInteger new` fails). This implies:
>
> "SmallFloat64 someInstance == nil"
> "Character someInstance == nil"
>
> Why would you want someInstance of SmallInteger anyway?
>
> Fabio
>
>
>>
>> Best,
>> Marcel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/7bcf535c/attachment.html>

From eliot.miranda at gmail.com  Tue Jul 21 15:37:53 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Tue, 21 Jul 2020 08:37:53 -0700
Subject: [squeak-dev] SmallInteger someInstance == nil :(
In-Reply-To: <Mailbird-27667c62-5b9f-4e8e-8bed-e23557868b1b@hpi.de>
References: <Mailbird-27667c62-5b9f-4e8e-8bed-e23557868b1b@hpi.de>
Message-ID: <B6A8FB0D-6511-4623-A038-3924107C205D@gmail.com>

Hi Marcel, Hi Fabio,

> On Jul 21, 2020, at 5:24 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> 
> Hi all!
> 
> Why is "SmallInteger someInstance == nil"?

Fabio has it right.  Let me expand a little.

Historically the blue book Smalltalk-80 and Squeak have had garbage collectors that preserved allocation order, so that all instances could reliably be obtained by

    aClass firstInstance => first instance or nil
    anInstance nextInstance => next instance or nil

and all objects could reliably be obtained by

    Object someObject => anObject
    anObject nextObject => next object or nil

When Berkeley Smalltalk introduced generation scavenging allocation order was no longer preserved and so an allInstances primitive was introduced. So VisualWorks and the Spur implementation of Squeak and several other Smalltalks depend on allInstances and allObjects primitives.

In VisualWorks we sped up finding instances of a few classes by providing allInstancesOfAny: which takes an array of classes and has better performance because it makes one pass through the heap while the array of classes stays in the processor’s cache.

Like Marcel I thought that Character allInstances SmallInteger allInstances made sense as intervals, and implemented in VisualWorks so that SmallInteger allInstances answered (SmallInteger minVal to: SmallInteger maxVal).  But the cure was worse than the disease.  Tools that determined the memory usage of classes would have to special case the immediate classes because enumerating their instances, though now possible, took a looooong time ;-).  And of course extending the idea so that allObjects includes these is impossible; there’s not enough address space.  And so I would counsel against implementing allInstances for Character SmallFloat64 and SmallInteger.  It sounds great in theory but in practice it’s a pain in the ass.

Maybe someInstance should fail for immediate classes.  But more realistically we should deprecate someInstance, nextInstance, someObject and  nextObject, with helpful but succinct error messages.

Finally, Spur optimises allInstances.  A class’s identity hash is its instances’ class index.  So a class that doesn’t have an identity hash has no instances.  But if eg one creates a set of all classes they all get an identity hash and the optimization is defeated.  We could add a step in the release process to collect all classes with an identity hash but no instances, check if they’re in any hashed collections and void their identity hash if not.  There is a hidden primitive to test and to force setting of identity hashes fir nefarious purposes such as this.  But the primitive is not for every day use so it should remain hidden IMO.

> Best,
> Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/b36b54f8/attachment.html>

From florin.mateoc at gmail.com  Tue Jul 21 15:56:01 2020
From: florin.mateoc at gmail.com (Florin Mateoc)
Date: Tue, 21 Jul 2020 11:56:01 -0400
Subject: [squeak-dev] SmallInteger someInstance == nil :(
In-Reply-To: <CADfnKi6S9kCsiw8PZNZpyst-5tto1VMsvEQvwg93zisN8=FAEg@mail.gmail.com>
References: <Mailbird-27667c62-5b9f-4e8e-8bed-e23557868b1b@hpi.de>
 <CADfnKi5whE7SSXE2EpNqkpH0u6_fB10NMDToUy6e02HLR_UPjg@mail.gmail.com>
 <Mailbird-6befdb68-8560-475a-b9f2-dfd5d37f2364@hpi.de>
 <Mailbird-7d027db9-e2aa-46cc-8492-aa848c374fc1@hpi.de>
 <CADfnKi6S9kCsiw8PZNZpyst-5tto1VMsvEQvwg93zisN8=FAEg@mail.gmail.com>
Message-ID: <CA+7DxaZqci5P-DA8__+5NwYK-9ohLfK-Yg4MDL6Bp2LdJXHb=A@mail.gmail.com>

Actually, primitiveSomeInstance fails, it does not return nil. It is the
image-side primitive failure code that returns nil.
Which brings us to the question: why not fix it in Smalltalk, if you think
the behavior (as implemented in Behavior :)) is not appropriate for
immediate classes?
If you override the method in the immediate classes and replace the
primitive failure code with something more appropriate for each immediate
class, you can have them return good exemplars

Florin

On Tue, Jul 21, 2020 at 9:21 AM Fabio Niephaus <lists at fniephaus.com> wrote:

> On Tue, Jul 21, 2020 at 3:08 PM Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
>
>> Maybe I can check for #isImmediateClass first :-)
>>
>
> That's a good idea. Note that primitiveSomeInstance also returns nil in
> case no instance exists (e.g. `EToyProjectDetailsMorph someInstance ==
> nil`).
> I believe the behavior you observe wrt immediates has historical reasons:
> #someInstance returns the first instance found in the object memory, and
> you can use #nextInstance: for iteration (this mechanism was later replaced
> by #allInstances). Iterating instances doesn't make sense for immediates,
> the "same instance" can occur multiple times in the heap.
>
> Fabio
>
>> Am 21.07.2020 15:07:01 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>> Hi Fabio.
>>
>> From an object-oriented perspective, it would be nice to get "some
>> instance" when asking a class in the system for #someInstance. :-)
>>
>> As it is now, I have to start writing a little lookup table with "class
>> == SmallInteger ifTrue: [ .... ]" to lookup exemplary instances for some
>> classes in the system.
>>
>> Best,
>> Marcel
>>
>>
>> Am 21.07.2020 14:53:31 schrieb Fabio Niephaus <lists at fniephaus.com>:
>> On Tue, Jul 21, 2020 at 2:24 PM Marcel Taeumel <marcel.taeumel at hpi.de>
>> wrote:
>>
>>> Hi all!
>>>
>>> Why is "SmallInteger someInstance == nil"?
>>>
>>
>> Because SmallIntegers are immediate and cannot be instantiated
>> (`SmallInteger new` fails). This implies:
>>
>> "SmallFloat64 someInstance == nil"
>> "Character someInstance == nil"
>>
>> Why would you want someInstance of SmallInteger anyway?
>>
>> Fabio
>>
>>
>>>
>>> Best,
>>> Marcel
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/22b8c5d3/attachment.html>

From florin.mateoc at gmail.com  Tue Jul 21 16:10:44 2020
From: florin.mateoc at gmail.com (Florin Mateoc)
Date: Tue, 21 Jul 2020 12:10:44 -0400
Subject: [squeak-dev] SmallInteger someInstance == nil :(
In-Reply-To: <CA+7DxaZqci5P-DA8__+5NwYK-9ohLfK-Yg4MDL6Bp2LdJXHb=A@mail.gmail.com>
References: <Mailbird-27667c62-5b9f-4e8e-8bed-e23557868b1b@hpi.de>
 <CADfnKi5whE7SSXE2EpNqkpH0u6_fB10NMDToUy6e02HLR_UPjg@mail.gmail.com>
 <Mailbird-6befdb68-8560-475a-b9f2-dfd5d37f2364@hpi.de>
 <Mailbird-7d027db9-e2aa-46cc-8492-aa848c374fc1@hpi.de>
 <CADfnKi6S9kCsiw8PZNZpyst-5tto1VMsvEQvwg93zisN8=FAEg@mail.gmail.com>
 <CA+7DxaZqci5P-DA8__+5NwYK-9ohLfK-Yg4MDL6Bp2LdJXHb=A@mail.gmail.com>
Message-ID: <CA+7DxabN1t7CTPAWEgHGndY2GSPAQ8iJzMhjw=WWdSi+U50Fzg@mail.gmail.com>

First off, apologies for top-posting, fixed below, with some additional
comments.

On Tue, Jul 21, 2020 at 11:56 AM Florin Mateoc <florin.mateoc at gmail.com>
wrote:

> On Tue, Jul 21, 2020 at 9:21 AM Fabio Niephaus <lists at fniephaus.com>
> wrote:
>
>> On Tue, Jul 21, 2020 at 3:08 PM Marcel Taeumel <marcel.taeumel at hpi.de>
>> wrote:
>>
>>> Maybe I can check for #isImmediateClass first :-)
>>>
>>
>> That's a good idea. Note that primitiveSomeInstance also returns nil in
>> case no instance exists (e.g. `EToyProjectDetailsMorph someInstance ==
>> nil`).
>> I believe the behavior you observe wrt immediates has historical reasons:
>> #someInstance returns the first instance found in the object memory, and
>> you can use #nextInstance: for iteration (this mechanism was later replaced
>> by #allInstances). Iterating instances doesn't make sense for immediates,
>> the "same instance" can occur multiple times in the heap.
>>
>> Fabio
>>
>

Actually, primitiveSomeInstance fails, it does not return nil. It is the
image-side primitive failure code that returns nil.
Which brings us to the question: why not fix it in Smalltalk, if you think
the behavior (as implemented in Behavior :)) is not appropriate for
immediate classes?
If you override the method in the immediate classes and replace the
primitive failure code with something more appropriate for each immediate
class, you can have them return good exemplars

Also note that, as Eliot said, nextInstance does not make sense for
immediate classes. This implies that someInstance does not make sense
either when thought of as the dual of nextInstace (which it is, in many
scenarios).
But I think someInstance can make sense on its own, as in your scenario,
that is the context in which I proposed to "fix it"

Florin


> Am 21.07.2020 15:07:01 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>>> Hi Fabio.
>>>
>>> From an object-oriented perspective, it would be nice to get "some
>>> instance" when asking a class in the system for #someInstance. :-)
>>>
>>> As it is now, I have to start writing a little lookup table with "class
>>> == SmallInteger ifTrue: [ .... ]" to lookup exemplary instances for some
>>> classes in the system.
>>>
>>> Best,
>>> Marcel
>>>
>>>
>>> Am 21.07.2020 14:53:31 schrieb Fabio Niephaus <lists at fniephaus.com>:
>>> On Tue, Jul 21, 2020 at 2:24 PM Marcel Taeumel <marcel.taeumel at hpi.de>
>>> wrote:
>>>
>>>> Hi all!
>>>>
>>>> Why is "SmallInteger someInstance == nil"?
>>>>
>>>
>>> Because SmallIntegers are immediate and cannot be instantiated
>>> (`SmallInteger new` fails). This implies:
>>>
>>> "SmallFloat64 someInstance == nil"
>>> "Character someInstance == nil"
>>>
>>> Why would you want someInstance of SmallInteger anyway?
>>>
>>> Fabio
>>>
>>>
>>>>
>>>> Best,
>>>> Marcel
>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/73db9b44/attachment.html>

From smalltalk at stefan-marr.de  Tue Jul 21 17:00:14 2020
From: smalltalk at stefan-marr.de (Stefan Marr)
Date: Tue, 21 Jul 2020 18:00:14 +0100
Subject: [squeak-dev] [2nd CfP] MPLR 2020 - 17th International Conference on
 Managed Programming Languages & Runtimes
Message-ID: <038F1D2C-8BA4-42F6-9F52-286D52D8E8B6@stefan-marr.de>

========================================================================
                            Call for Papers

               MPLR 2020 - 17th International Conference
              on Managed Programming Languages & Runtimes

            November 4-6, 2020 in Manchester, United Kingdom

                  https://mplr2020.cs.manchester.ac.uk/
                          Follow us @MPLR_Conf
========================================================================

The 17th International Conference on Managed Programming Languages &
Runtimes (MPLR, formerly ManLang) is a premier forum for presenting and
discussing novel results in all aspects of managed programming languages
and runtime systems, which serve as building blocks for some of the most
important computing systems in use, ranging from small-scale (embedded and
real-time systems) to large-scale (cloud-computing and big-data platforms)
and anything in between (desktop, mobile, IoT, and wearable applications).

This year, MPLR will be held virtually. Registration and participation will
be free.

For up-to-date details, check out the conference website:
https://mplr2020.cs.manchester.ac.uk/ and follow us on Twitter @MPLR_Conf.

The areas of interest include but are not limited to:

 * Languages and Compilers
    - Managed languages (e.g., Java, Scala, JavaScript, Python, Ruby, C#, F#, Clojure, Groovy, Kotlin, R, Smalltalk, Racket, Rust, Go, etc.)
    - Domain-specific languages
    - Language design
    - Compilers and interpreters
    - Type systems and program logics
    - Language interoperability
    - Parallelism, distribution, and concurrency

 * Virtual Machines
    - Managed runtime systems (e.g., JVM, Android Runtime (ART), V8, LLVM, .NET CLR, RPython, GraalVM, etc.)
    - VM design and optimization
    - VMs for mobile and embedded devices
    - VMs for real-time applications
    - Memory management and garbage collection
    - Hardware/software co-design

 * Techniques, Tools, and Applications
    - Static and dynamic program analysis
    - Testing and debugging
    - Refactoring
    - Program understanding
    - Program synthesis
    - Security and privacy
    - Performance analysis and monitoring
    - Compiler and program verification


Submission Categories
---------------------

MPLR accepts four types of submissions:

 1. Regular research papers
      describing novel contributions involving managed language platforms.
      Research papers will be evaluated based on their relevance,
      novelty, technical rigor, and contribution to the state-of-the-art.

   Format: up to 12 pages, excluding bibliography and appendix

 2. Work-in-progress research papers
      describing promising new ideas, with perhaps less maturity than full
      Papers.
      Work-in-progress papers will be  evaluated with an emphasis on novelty
      and the potential of the new ideas instead of technical rigor and
      experimental results.

   Format: up to 6 pages, excluding bibliography and appendix

 3. Industry and tool papers
      presenting technical challenges and solutions for managed language
      platforms in the context of deployed applications and systems.
      Industry and tool papers will be evaluated on their relevance,
      usefulness, and results. Suitability for demonstration and availability
      will also be considered for tool papers.

    Format: up to 6 pages, excluding bibliography and appendix

 4. Posters
      They will be evaluated similarly to work-in-progress papers.
      Posters can accompany any submission as a way to provide additional
      demonstration and discussion opportunities.
  
    Format: poster and 1-page abstract

MPLR 2020 submissions must conform to the ACM Policy on Prior Publication
and Simultaneous Submissions and to the SIGPLAN Republication Policy.
See http://www.sigplan.org/Resources/Policies/Republication/


Author Instructions
-------------------

Submissions need to use the ACM `acmart` format with the `sigconf` style:
https://www.acm.org/publications/proceedings-template

If you are using LaTeX, submissions need to use the 'acmart' document class
with the 'sigconf' option. For reviewing, please include page numbers in your submission
using the LaTeX command `\settopmatter{printfolios=true}`.
The standard settings of a 9 point font size and the
Libertine/Biolinum font family are to be kept.

All submissions need to be in PDF format.

MPLR uses single-blind reviewing, i.e., author names are generally included in submissions.

Please also ensure that your submission is legible when printed on a black
and white printer. In particular, please check that colors remain distinct
and font sizes are legible.

Submission Site: https://mplr2020.cs.manchester.ac.uk/submissions/


Important Dates
---------------

Submission Deadline:     12 August 2020
Author Notification:     14 September 2020
Camera Ready:            05 October 2020
Conference Dates:     04-06 November 2020


All deadlines are 23:59 AoE (UTC-12h).

AUTHORS TAKE NOTE: The official publication date is the date the
proceedings are made available in the ACM Digital Library. This date
may be up to two weeks prior to the first day of your conference.
The official publication date affects the deadline for any patent
filings related to published work.


COVID-19
--------

MPLR will be held virtual to avoid any health risks to attendees and
avoid uncertainties around traveling.


Organization
------------

Program Committee:

  Lubomír Bulej, Charles University, Czech Republic
  Jeronimo Castrillon, TU Dresden, Germany
  Shigeru Chiba, University of Tokyo, Japan
  Irene Finocchi, LUISS Guido Carli University, Italy
  Juliana Franco, Microsoft Research, UK
  Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium
  Robert Hirschfeld, Hasso Plattner Institute, Germany
  Roberto Ierusalimschy, PUC-Rio, Brazil
  Georgia Kouveli, ARM, UK
  Burcu Külahçıoğlu Özkan, MPI-SWS, Germany
  Doug Lea, SUNY Oswego, USA
  Daryl Maier, IBM, Canada
  Mark Marron, Microsoft Research, USA
  Hidehiko Masuhara, Tokyo Institute of Technology, Japan
  Hanspeter Mössenböck, JKU Linz, Austria
  Hannes Payer, Google, Germany
  Julien Ponge, Red Hat, France
  Aleksandar Prokopec, Oracle Labs, Switzerland
  Manuel Rigger, ETH Zurich, Switzerland
  Andrea Rosa, USI, Switzerland
  Jeremy Singer, University of Glasgow, UK
  Eli Tilevich, Virginia Tech, USA
  Sam Tobin-Hochstadt, Indiana University, USA
  Tobias Wrigstad, Uppsala University, Sweden

General Chair:
  Christos Kotselidis, University of Manchester, UK

Program Chair:
  Stefan Marr, University of Kent, UK


If you are unsure whether a particular topic falls within the scope of MPRL’20 or if you have any other questions, please do not hesitate to contact the Program Chair (s.marr at kent.ac.uk).


-- 
Stefan Marr
School of Computing, University of Kent
https://stefan-marr.de/research/



From tim at rowledge.org  Tue Jul 21 17:08:44 2020
From: tim at rowledge.org (tim Rowledge)
Date: Tue, 21 Jul 2020 10:08:44 -0700
Subject: [squeak-dev] MNU for ifNil: to preserve quick returns? :-)
In-Reply-To: <Mailbird-d51422e2-2a6a-4aa8-921a-e11d230a565a@hpi.de>
References: <Mailbird-d51422e2-2a6a-4aa8-921a-e11d230a565a@hpi.de>
Message-ID: <16397836-A037-4EB3-8271-498C2B4B724C@rowledge.org>



> On 2020-07-21, at 1:36 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> I can choose to initialize an instVar eagerly in #initialize or lazily in its accessor via #ifNil:. Yet, the latter requires me to change that accessor to something not being a quick return.

I've always been a bit ambivalent about the lazy initialisation stuff; not that it doesn't have uses. The problematic bit in my experience is tied to the lack of properly private messages and the disappointing propensity of people to treat Smalltalk as C code.

To explain: one decides to have lazy init for an instvar and so creates a methods named as the instvar that does the nil check and init dance. Great - now you can write
`self foobleDong`
and guarantee to get a useful answer. The problem now is that you have made your class into little more than a C struct. Any old Thomas, Richard or Harold can send #foobleDong and get at the internal state of your object. I don't like that.
*If* we had private methods one could mark foobleDong as private and thereby safely use it internally. 

I see far too much 'Cmalltalk' where messages are being sent as if they were C struct accessor operators. I really hate seeing
`myThing foo fum bar baz bing: myThing foo fum bar baz bing + 1`



tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"Bother!" said Pooh, as he stood up to his waist in a cow pat.



From leves at caesar.elte.hu  Tue Jul 21 18:21:28 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Tue, 21 Jul 2020 20:21:28 +0200 (CEST)
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
References: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.2007212013320.23984@login03.caesar.elte.hu>

Hi Eliot,

On Mon, 20 Jul 2020, Eliot Miranda wrote:

> Hi All,
>     I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows two methods
> (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods.  The issue is when to publish the corrections to trunk.
> Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests.  However, I do want to push the corrections soon, because they're a
> substantial improvement.  So the question is how long should I wait?
> 
> Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM.

I think most people don't update their VMs often. I still tend to fire 
up the one shipped with the 5.3 release. So, IMO the question is not how 
long to wait but what to do when things are about to break.
I presume that without updating the VM, the image would not work properly.
So, I think the best would be if the user were warned during the update 
if the VM would be incompatible with the changes.
I'm thinking about checking the VM version in the preamble of the package 
and raising a Warning when it clearly lacks the required updates.
Users can still continute with a Warning or terminate the update process, 
while cli tools will act as if an error had occured.


Levente

> _,,,^..^,,,_
> best, Eliot
> 
>

From karlramberg at gmail.com  Tue Jul 21 18:36:47 2020
From: karlramberg at gmail.com (karl ramberg)
Date: Tue, 21 Jul 2020 20:36:47 +0200
Subject: [squeak-dev] MNU for ifNil: to preserve quick returns? :-)
In-Reply-To: <16397836-A037-4EB3-8271-498C2B4B724C@rowledge.org>
References: <Mailbird-d51422e2-2a6a-4aa8-921a-e11d230a565a@hpi.de>
 <16397836-A037-4EB3-8271-498C2B4B724C@rowledge.org>
Message-ID: <CAGzzWLirLJW2E3yQ1dQ8xVcrNMS0+XrhMWcUi4DLPGbk=3uGGA@mail.gmail.com>

Tim,
You can discourage non private use if you write them like this:
foo
 foo ifNil:[foo := OrderedCollection new].
 ^nil

/s

Best,
Karl



On Tue, Jul 21, 2020 at 7:08 PM tim Rowledge <tim at rowledge.org> wrote:

>
>
> > On 2020-07-21, at 1:36 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> >
> > I can choose to initialize an instVar eagerly in #initialize or lazily
> in its accessor via #ifNil:. Yet, the latter requires me to change that
> accessor to something not being a quick return.
>
> I've always been a bit ambivalent about the lazy initialisation stuff; not
> that it doesn't have uses. The problematic bit in my experience is tied to
> the lack of properly private messages and the disappointing propensity of
> people to treat Smalltalk as C code.
>
> To explain: one decides to have lazy init for an instvar and so creates a
> methods named as the instvar that does the nil check and init dance. Great
> - now you can write
> `self foobleDong`
> and guarantee to get a useful answer. The problem now is that you have
> made your class into little more than a C struct. Any old Thomas, Richard
> or Harold can send #foobleDong and get at the internal state of your
> object. I don't like that.
> *If* we had private methods one could mark foobleDong as private and
> thereby safely use it internally.
>
> I see far too much 'Cmalltalk' where messages are being sent as if they
> were C struct accessor operators. I really hate seeing
> `myThing foo fum bar baz bing: myThing foo fum bar baz bing + 1`
>
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> "Bother!" said Pooh, as he stood up to his waist in a cow pat.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/1a1c3239/attachment.html>

From lewis at mail.msen.com  Tue Jul 21 19:24:49 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Tue, 21 Jul 2020 15:24:49 -0400
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <CA+ovNC5MT_54K7WR0detfxAk6ed8XYG7ehBYmA9PWzyQWFnqmQ@mail.gmail.com>
References: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
 <CA+ovNC5MT_54K7WR0detfxAk6ed8XYG7ehBYmA9PWzyQWFnqmQ@mail.gmail.com>
Message-ID: <20200721192449.GA80547@shell.msen.com>

About a week's advance notice on the list(s) seems pretty reasonable,
possibly with an <ACK> from the CI folks to make sure. Switching VMs
might be an inconvenience, but this is trunk after all and that's what
it's for.

I'm assuming that "broken" means the the user would see some failing
tests due to the need for updated VM support, but the image would
still run and be somewhat functional on the previous VM.

This might also be an opportune time to add primitiveMultipleBytecodeSetsActive
if you are so inclined. It requires trunk users to update their VM before
the image format number can be updated, so it would be convenient if
it could come along with the primitiveAt[Put] changes.

Dave


On Tue, Jul 21, 2020 at 11:45:27AM +0200, Jakob Reschke wrote:
> Hi Eliot,
> 
> I only ever upgrade my VM if something breaks or if I am asked to. So
> if you'd post a message with something like "Please upgrade your VM"
> in the subject line to the list once you push the changes to Trunk,
> that would be great for me!
> 
> Concerning the time span: in an ideal world I would say "as soon as
> the CI is green", but I have my doubts that this will be enough for
> Squeak. Assuming that you use the new VM immediately and frequently
> (or anyone else does), I think a day of work up to a week after the VM
> changes is fine. Or as soon as you are confident about it, however you
> measure that. ;-)
> 
> Kind regards,
> Jakob
> 
> Am Di., 21. Juli 2020 um 02:55 Uhr schrieb Eliot Miranda
> <eliot.miranda at gmail.com>:
> >
> > Hi All,
> >     I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows two methods (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods.  The issue is when to publish the corrections to trunk.
> >
> > Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests.  However, I do want to push the corrections soon, because they're a substantial improvement.  So the question is how long should I wait?
> >
> > Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM.
> > _,,,^..^,,,_
> > best, Eliot
> >
> 

From eliot.miranda at gmail.com  Tue Jul 21 19:24:46 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Tue, 21 Jul 2020 12:24:46 -0700
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <alpine.DEB.2.02.2007212013320.23984@login03.caesar.elte.hu>
References: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
 <alpine.DEB.2.02.2007212013320.23984@login03.caesar.elte.hu>
Message-ID: <CAC20JE2g9fs_GOmZjoc1bjw2dZ3G6Bh3qGVuqumRneVh04Y84g@mail.gmail.com>

Hi Levente,

On Tue, Jul 21, 2020 at 11:21 AM Levente Uzonyi <leves at caesar.elte.hu>
wrote:

> Hi Eliot,
>
> On Mon, 20 Jul 2020, Eliot Miranda wrote:
>
> > Hi All,
> >     I've just found and fixed a VM bug in an as-yet-unpublished pair of
> primitives that replace FloatArrayPlugin>>primitiveAt[Put] and
> Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows
> two methods
> > (at:[put:]) in FloatArray to relace four methods
> (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times
> faster than the plugin methods.  The issue is when to publish the
> corrections to trunk.
> > Since the existing VM is broken I don't want to simply push to trunk and
> have people inconvenienced by a sudden emergence of failures in the
> FoatArrayTests.  However, I do want to push the corrections soon, because
> they're a
> > substantial improvement.  So the question is how long should I wait?
> >
> > Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do
> people using trunk keep an eye on the CI builds and upgrade, or would they
> appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and
> ask that you upgrade your VM.
>
> I think most people don't update their VMs often. I still tend to fire
> up the one shipped with the 5.3 release. So, IMO the question is not how
> long to wait but what to do when things are about to break.
> I presume that without updating the VM, the image would not work properly.
> So, I think the best would be if the user were warned during the update
> if the VM would be incompatible with the changes.
> I'm thinking about checking the VM version in the preamble of the package
> and raising a Warning when it clearly lacks the required updates.
> Users can still continute with a Warning or terminate the update process,
> while cli tools will act as if an error had occured.
>

That's a great idea.  I should have thought of that one myself.  I'll do
exactly that.  Thanks!

Levente
>
> > _,,,^..^,,,_
> > best, Eliot
> >
> >
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/3efd7c61/attachment.html>

From eliot.miranda at gmail.com  Tue Jul 21 19:29:49 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Tue, 21 Jul 2020 12:29:49 -0700
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <20200721192449.GA80547@shell.msen.com>
References: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
 <CA+ovNC5MT_54K7WR0detfxAk6ed8XYG7ehBYmA9PWzyQWFnqmQ@mail.gmail.com>
 <20200721192449.GA80547@shell.msen.com>
Message-ID: <CAC20JE0YSmBnRuJ9cJJYKHMGFk=yitSinxu1RX-T6Txyjs1MKQ@mail.gmail.com>

Hi David,

On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <lewis at mail.msen.com> wrote:

> About a week's advance notice on the list(s) seems pretty reasonable,
> possibly with an <ACK> from the CI folks to make sure. Switching VMs
> might be an inconvenience, but this is trunk after all and that's what
> it's for.
>
> I'm assuming that "broken" means the the user would see some failing
> tests due to the need for updated VM support, but the image would
> still run and be somewhat functional on the previous VM.
>
> This might also be an opportune time to add
> primitiveMultipleBytecodeSetsActive
> if you are so inclined. It requires trunk users to update their VM before
> the image format number can be updated, so it would be convenient if
> it could come along with the primitiveAt[Put] changes.
>

We still have to discuss this.  I'm sorry, been too busy to do so.  I still
don't understand the intent here.  The VM already provides a status bit in
parameter 65 which says whether the VM supports multiple bytecode sets.  If
the intent is to mark an image when multiple bytecode sets have been used
then the primitive doesn't appear to me to do what's required.  I'll try
and answer in the context of the thread soon, because I agree it's
important.  Ideally there would be a pair of flags set somewhere that said
if the current image had ever executed a method in either bytecode set.


> Dave
>
>
> On Tue, Jul 21, 2020 at 11:45:27AM +0200, Jakob Reschke wrote:
> > Hi Eliot,
> >
> > I only ever upgrade my VM if something breaks or if I am asked to. So
> > if you'd post a message with something like "Please upgrade your VM"
> > in the subject line to the list once you push the changes to Trunk,
> > that would be great for me!
> >
> > Concerning the time span: in an ideal world I would say "as soon as
> > the CI is green", but I have my doubts that this will be enough for
> > Squeak. Assuming that you use the new VM immediately and frequently
> > (or anyone else does), I think a day of work up to a week after the VM
> > changes is fine. Or as soon as you are confident about it, however you
> > measure that. ;-)
> >
> > Kind regards,
> > Jakob
> >
> > Am Di., 21. Juli 2020 um 02:55 Uhr schrieb Eliot Miranda
> > <eliot.miranda at gmail.com>:
> > >
> > > Hi All,
> > >     I've just found and fixed a VM bug in an as-yet-unpublished pair
> of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and
> Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows
> two methods (at:[put:]) in FloatArray to relace four methods
> (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times
> faster than the plugin methods.  The issue is when to publish the
> corrections to trunk.
> > >
> > > Since the existing VM is broken I don't want to simply push to trunk
> and have people inconvenienced by a sudden emergence of failures in the
> FoatArrayTests.  However, I do want to push the corrections soon, because
> they're a substantial improvement.  So the question is how long should I
> wait?
> > >
> > > Is it OK if I push the fixes to FloatArray and subclasses in a week?
> Do people using trunk keep an eye on the CI builds and upgrade, or would
> they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask
> that you upgrade your VM.
> > > _,,,^..^,,,_
> > > best, Eliot
> > >
> >
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/c2da21d0/attachment.html>

From commits at source.squeak.org  Tue Jul 21 19:33:45 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Tue, 21 Jul 2020 19:33:45 0000
Subject: [squeak-dev] The Trunk: Kernel-eem.1335.mcz
Message-ID: <E1jxy1O-0001yz-FS@andreas>

Eliot Miranda uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-eem.1335.mcz

==================== Summary ====================

Name: Kernel-eem.1335
Author: eem
Time: 21 July 2020, 12:33:42.401688 pm
UUID: 829e7c17-0cb2-4269-a6ca-d85bef9ecc2a
Ancestors: Kernel-mt.1334

Support for FloatArray; add 64-bit duals of the 32-bit float converters, so along side Float>>asIEEE32BitWord & Float class>>fromIEEE32Bit: we have Float>>asIEEE64BitWord & Float class>>fromIEEE64Bit:.

=============== Diff against Kernel-mt.1334 ===============

Item was added:
+ ----- Method: Float class>>fromIEEE64Bit: (in category 'instance creation') -----
+ fromIEEE64Bit: anInteger
+ 	"Convert the given 64 bit word (which is supposed to be a positive 64-bit value) from
+ 	  a 64 bit IEEE floating point representation into an actual Squeak float object (being
+ 	  64 bits wide). Should only be used for conversion in FloatArrays or likewise objects."
+ 	| value |
+ 	value := self basicNew: 2.
+ 	value
+ 		basicAt: 1 put: (anInteger bitShift: -32);
+ 		basicAt: 2 put: (anInteger bitAnd: 16rFFFFFFFF).
+ 	^value isFinite
+ 		ifTrue: [value * 1.0] "reduce to SmallFloat64 if possible"
+ 		ifFalse: [value]!

Item was changed:
  ----- Method: Float>>asIEEE32BitWord (in category 'converting') -----
  asIEEE32BitWord
  	"Convert the receiver into a 32 bit Integer value representing the same number in IEEE 32 bit format.
+ 	 Used for conversion in FloatArrays."
- 	Used for conversion in FloatArrays only."
  	
+ 	| word1 word2 sign mantissa exponent truncatedBits mask roundToUpper |
- 	| word1 word2 sign mantissa exponent destWord truncatedBits mask roundToUpper |
  	
  	"skip fast positive and nnegative zero"
  	self = 0.0 ifTrue: [^self basicAt: 1].
  	
  	"retrieve 64 bits of IEEE 754 double"
  	word1 := self basicAt: 1.
  	word2 := self basicAt: 2.
  	
  	"prepare sign exponent and mantissa of 32 bits float"
  	sign := word1 bitAnd: 16r80000000.
  	exponent := ((word1 bitShift: -20) bitAnd: 16r7FF) - 1023 + 127.
  	mantissa := (word2 bitShift: -29) + ((word1 bitAnd:  16rFFFFF) bitShift: 3).
  	truncatedBits := (word2 bitAnd: 16r1FFFFFFF).
  
  	"We must now honour default IEEE rounding mode (round to nearest even)"
  	
  	"we are below gradual underflow, even if rounded to upper mantissa"
+ 	exponent < -24 ifTrue: [^sign]. "this can be negative zero"
- 	exponent < -24 ifTrue: [^sign "this can be negative zero"].
  	
  	"BEWARE: rounding occurs on less than 23bits when gradual underflow"
  	exponent <= 0
  		ifTrue:
  			[mask := 1 bitShift: exponent negated.
  			mantissa := mantissa bitOr: 16r800000.
  			roundToUpper := (mantissa bitAnd: mask) isZero not
  				and: [truncatedBits isZero not
  					or: [(mantissa bitAnd: mask - 1) isZero not
  						or: [(mantissa bitAnd: mask*2) isZero not]]].
  			mantissa := mantissa bitShift: exponent - 1.
  			"exponent := exponent + 1"]
  		ifFalse:
  			[roundToUpper := (truncatedBits bitAnd: 16r10000000) isZero not
  				and: [(mantissa bitAnd: 16r1) isZero not
+ 					or: [(truncatedBits bitAnd: 16r0FFFFFFF) isZero not]]].
- 					or: [(truncatedBits bitAnd: 16r0FFFFFFF) isZero not]]
- 			].
  		
  	"adjust mantissa and exponent due to IEEE rounding mode"
+ 	roundToUpper ifTrue:
+ 		[mantissa := mantissa + 1.
+ 		mantissa > 16r7FFFFF ifTrue:
+ 			[mantissa := 0.
+ 			exponent := exponent+1]].
- 	roundToUpper
- 		ifTrue:
- 			[mantissa := mantissa + 1.
- 			mantissa > 16r7FFFFF
- 				ifTrue:
- 					[mantissa := 0.
- 					exponent := exponent+1]].
  
+ 	exponent > 254 ifTrue: "Overflow"
+ 		[exponent := 255.
- 	exponent > 254 ifTrue: ["Overflow"
- 		exponent := 255.
  		self isNaN
  			ifTrue: [mantissa isZero
  				ifTrue: ["BEWARE: do not convert a NaN to infinity due to truncatedBits"
  					mantissa := 1]]
  			ifFalse: [mantissa := 0]].
  		
  	"Encode the word"
+ 	^(sign bitOr: ((exponent max: 0) bitShift: 23)) bitOr: mantissa!
- 	destWord := (sign bitOr: ((exponent max: 0) bitShift: 23)) bitOr: mantissa.
- 	^ destWord!

Item was added:
+ ----- Method: Float>>asIEEE64BitWord (in category 'converting') -----
+ asIEEE64BitWord
+ 	"Convert the receiver into a 64 bit Integer value representing the same number in IEEE 64 bit format.
+ 	 Used for conversion in FloatArrays."
+ 	
+ 	^((self basicAt: 1) bitShift: 32) + (self basicAt: 2)!


From commits at source.squeak.org  Tue Jul 21 19:48:51 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Tue, 21 Jul 2020 19:48:51 0000
Subject: [squeak-dev] The Trunk: Collections-eem.904.mcz
Message-ID: <E1jxyFy-0002Bu-Gh@andreas>

Eliot Miranda uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-eem.904.mcz

==================== Summary ====================

Name: Collections-eem.904
Author: eem
Time: 21 July 2020, 12:48:47.966166 pm
UUID: 5aa53764-ee46-4fee-b681-0bc142550102
Ancestors: Collections-ul.903

Supercede the slow Float[64]ArrayPlugin>>at:[put:] primitives with much faster ones in the Spur VM.

=============== Diff against Collections-ul.903 ===============

Item was changed:
+ (PackageInfo named: 'Collections') preamble: '"Use of the Spur FloatArray>>at:[put:] prims requires at least VMMaker.oscog.2778"
- (PackageInfo named: 'Collections') preamble: '"FloatArray is going to become the abstract class above Float32Array and Float64Array.
- In order to avoid spurious instance migration or recompilation errors, this preamble is required."
  
+ Smalltalk vmVMMakerVersion < 2778 ifTrue:
+ 	[Warning signal: ''This virtual machine is too old to support correct versions of the FloatArray>>at:[put:] primitives 238 and 239.  FloatArray subclasses will not behave correctly and FloatArray[64]Test tests will fail.  Please upgrade your VM.  You may continue and upgrade later or abort and upgrade now.'']'!
- FloatArray rename: #Float32Array.'!

Item was removed:
- ----- Method: Float32Array>>at: (in category 'accessing') -----
- at: index
- 	<primitive: 'primitiveAt' module: 'FloatArrayPlugin'>
- 	^Float fromIEEE32Bit: (self basicAt: index)!

Item was removed:
- ----- Method: Float32Array>>at:put: (in category 'accessing') -----
- at: index put: value
- 	<primitive: 'primitiveAtPut' module: 'FloatArrayPlugin'>
- 	value isFloat 
- 		ifTrue:[self basicAt: index put: value asIEEE32BitWord]
- 		ifFalse:[self at: index put: value asFloat].
- 	^value!

Item was removed:
- ----- Method: Float32Array>>defaultElement (in category 'accessing') -----
- defaultElement
- 	"Return the default element of the receiver"
- 	^0.0!

Item was removed:
- ----- Method: Float64Array>>at: (in category 'accessing') -----
- at: index
- 	<primitive: 'primitiveAt' module: 'Float64ArrayPlugin'>
- 	| f64 u64 |
- 	u64 := self basicAt: index.
- 	(f64 := Float basicNew)
- 		basicAt: 1 put: (u64 >> 32);
- 		basicAt: 2 put: (u64 bitAnd: 16rFFFFFFFF).
- 	^f64 * 1.0!

Item was removed:
- ----- Method: Float64Array>>at:put: (in category 'accessing') -----
- at: index put: value
- 	<primitive: 'primitiveAtPut' module: 'Float64ArrayPlugin'>
- 	value isFloat 
- 		ifTrue:[self basicAt: index put: (value basicAt: 1) << 32 + (value basicAt: 2)]
- 		ifFalse:[self at: index put: value asFloat].
- 	^value!

Item was added:
+ ----- Method: FloatArray>>at: (in category 'accessing') -----
+ at: index
+ 	"Answer the Float at index in the receiver.  This method converts from either a 32-bit IEEE representation,
+ 	 or a 64-bit IEEE representation to a Squeak Float object.  Primitive. Optional."
+ 	<primitive: 238 error: ec>
+ 	^self bytesPerElement = 4
+ 		ifTrue: [Float fromIEEE32Bit: (self basicAt: index)]
+ 		ifFalse: [Float fromIEEE64Bit: (self basicAt: index)]!

Item was added:
+ ----- Method: FloatArray>>at:put: (in category 'accessing') -----
+ at: index put: value
+ 	"Store the Float value at index in the receiver.  This method converts from a Squeak Float object,
+ 	 or an Integer, into either a 32-bit IEEE representation, or a 64-bit IEEE representation. Primitive. Optional."
+ 	<primitive: 239 error: ec>
+ 	value isFloat 
+ 		ifTrue:[self basicAt: index put: (self bytesPerElement = 4
+ 				ifTrue: [value asIEEE32BitWord]
+ 				ifFalse: [value asIEEE64BitWord])]
+ 		ifFalse: [self at: index put: value asFloat].
+ 	^value!


From lewis at mail.msen.com  Tue Jul 21 20:40:20 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Tue, 21 Jul 2020 16:40:20 -0400
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <CAC20JE0YSmBnRuJ9cJJYKHMGFk=yitSinxu1RX-T6Txyjs1MKQ@mail.gmail.com>
References: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
 <CA+ovNC5MT_54K7WR0detfxAk6ed8XYG7ehBYmA9PWzyQWFnqmQ@mail.gmail.com>
 <20200721192449.GA80547@shell.msen.com>
 <CAC20JE0YSmBnRuJ9cJJYKHMGFk=yitSinxu1RX-T6Txyjs1MKQ@mail.gmail.com>
Message-ID: <20200721204020.GA94495@shell.msen.com>

He Eliot,

On Tue, Jul 21, 2020 at 12:29:49PM -0700, Eliot Miranda wrote:
> Hi David,
> 
> On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <lewis at mail.msen.com> wrote:
> 
> > About a week's advance notice on the list(s) seems pretty reasonable,
> > possibly with an <ACK> from the CI folks to make sure. Switching VMs
> > might be an inconvenience, but this is trunk after all and that's what
> > it's for.
> >
> > I'm assuming that "broken" means the the user would see some failing
> > tests due to the need for updated VM support, but the image would
> > still run and be somewhat functional on the previous VM.
> >
> > This might also be an opportune time to add
> > primitiveMultipleBytecodeSetsActive
> > if you are so inclined. It requires trunk users to update their VM before
> > the image format number can be updated, so it would be convenient if
> > it could come along with the primitiveAt[Put] changes.
> >
> 
> We still have to discuss this.  I'm sorry, been too busy to do so.  I still
> don't understand the intent here.  The VM already provides a status bit in
> parameter 65 which says whether the VM supports multiple bytecode sets.  If
> the intent is to mark an image when multiple bytecode sets have been used
> then the primitive doesn't appear to me to do what's required.  I'll try
> and answer in the context of the thread soon, because I agree it's
> important.

Thanks :-)

>  Ideally there would be a pair of flags set somewhere that said
> if the current image had ever executed a method in either bytecode set.
> 

Yes, that would be better if it can be done without affecting performance.

Dave

> 
> > Dave
> >
> >
> > On Tue, Jul 21, 2020 at 11:45:27AM +0200, Jakob Reschke wrote:
> > > Hi Eliot,
> > >
> > > I only ever upgrade my VM if something breaks or if I am asked to. So
> > > if you'd post a message with something like "Please upgrade your VM"
> > > in the subject line to the list once you push the changes to Trunk,
> > > that would be great for me!
> > >
> > > Concerning the time span: in an ideal world I would say "as soon as
> > > the CI is green", but I have my doubts that this will be enough for
> > > Squeak. Assuming that you use the new VM immediately and frequently
> > > (or anyone else does), I think a day of work up to a week after the VM
> > > changes is fine. Or as soon as you are confident about it, however you
> > > measure that. ;-)
> > >
> > > Kind regards,
> > > Jakob
> > >
> > > Am Di., 21. Juli 2020 um 02:55 Uhr schrieb Eliot Miranda
> > > <eliot.miranda at gmail.com>:
> > > >
> > > > Hi All,
> > > >     I've just found and fixed a VM bug in an as-yet-unpublished pair
> > of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and
> > Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows
> > two methods (at:[put:]) in FloatArray to relace four methods
> > (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times
> > faster than the plugin methods.  The issue is when to publish the
> > corrections to trunk.
> > > >
> > > > Since the existing VM is broken I don't want to simply push to trunk
> > and have people inconvenienced by a sudden emergence of failures in the
> > FoatArrayTests.  However, I do want to push the corrections soon, because
> > they're a substantial improvement.  So the question is how long should I
> > wait?
> > > >
> > > > Is it OK if I push the fixes to FloatArray and subclasses in a week?
> > Do people using trunk keep an eye on the CI builds and upgrade, or would
> > they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask
> > that you upgrade your VM.
> > > > _,,,^..^,,,_
> > > > best, Eliot
> > > >
> > >
> >
> >
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

> 


From vanessa at codefrau.net  Tue Jul 21 23:51:28 2020
From: vanessa at codefrau.net (Vanessa Freudenberg)
Date: Tue, 21 Jul 2020 16:51:28 -0700
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <CAC20JE0YSmBnRuJ9cJJYKHMGFk=yitSinxu1RX-T6Txyjs1MKQ@mail.gmail.com>
References: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
 <CA+ovNC5MT_54K7WR0detfxAk6ed8XYG7ehBYmA9PWzyQWFnqmQ@mail.gmail.com>
 <20200721192449.GA80547@shell.msen.com>
 <CAC20JE0YSmBnRuJ9cJJYKHMGFk=yitSinxu1RX-T6Txyjs1MKQ@mail.gmail.com>
Message-ID: <CAOWGXNAaM=UBHwXCcSJbPuCpLoW5UZPKgDoGUYB2YHOB4e=8VA@mail.gmail.com>

On Tue, Jul 21, 2020 at 12:30 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi David,
>
> On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <lewis at mail.msen.com>
> wrote:
>
>>
>> This might also be an opportune time to add
>> primitiveMultipleBytecodeSetsActive
>> if you are so inclined. It requires trunk users to update their VM before
>> the image format number can be updated, so it would be convenient if
>> it could come along with the primitiveAt[Put] changes.
>>
>
> We still have to discuss this.  I'm sorry, been too busy to do so.  I
> still don't understand the intent here.  The VM already provides a status
> bit in parameter 65 which says whether the VM supports multiple bytecode
> sets.  If the intent is to mark an image when multiple bytecode sets have
> been used then the primitive doesn't appear to me to do what's required.
> I'll try and answer in the context of the thread soon, because I agree it's
> important.  Ideally there would be a pair of flags set somewhere that said
> if the current image had ever executed a method in either bytecode set.
>

All VMs check the image format to see if they can run the image. That's the
only check they perform, as far as I know.

That's why it seems appropriate to use a bit in the image format to mean
"no, you can't run this if your VM does not understand the new byte code
set".

Otherwise e.g. SqueakJS or other Spur-compatible VMs would have to look at
every single CompiledMethod to see if the alt byte code flag was set.

Btw, Squeak is not going to mix bytecode sets - it's going to recompile all
methods, so when snapshotting, they all use one or the other. In that
scenario, a simple primitive call like David's should work, if it's done
right after recompiling all.

- Vanessa -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/6dba5aaa/attachment.html>

From eliot.miranda at gmail.com  Wed Jul 22 01:42:19 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Tue, 21 Jul 2020 18:42:19 -0700
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <CAOWGXNAaM=UBHwXCcSJbPuCpLoW5UZPKgDoGUYB2YHOB4e=8VA@mail.gmail.com>
References: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
 <CA+ovNC5MT_54K7WR0detfxAk6ed8XYG7ehBYmA9PWzyQWFnqmQ@mail.gmail.com>
 <20200721192449.GA80547@shell.msen.com>
 <CAC20JE0YSmBnRuJ9cJJYKHMGFk=yitSinxu1RX-T6Txyjs1MKQ@mail.gmail.com>
 <CAOWGXNAaM=UBHwXCcSJbPuCpLoW5UZPKgDoGUYB2YHOB4e=8VA@mail.gmail.com>
Message-ID: <CAC20JE1NuiLbm=b=3buNsyXqs2=zDxvHGf1Bjhy9UDEcfNCoNg@mail.gmail.com>

Hi Vanessa,

On Tue, Jul 21, 2020 at 4:52 PM Vanessa Freudenberg <vanessa at codefrau.net>
wrote:

>
>
> On Tue, Jul 21, 2020 at 12:30 PM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>> Hi David,
>>
>> On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <lewis at mail.msen.com>
>> wrote:
>>
>>>
>>> This might also be an opportune time to add
>>> primitiveMultipleBytecodeSetsActive
>>> if you are so inclined. It requires trunk users to update their VM before
>>> the image format number can be updated, so it would be convenient if
>>> it could come along with the primitiveAt[Put] changes.
>>>
>>
>> We still have to discuss this.  I'm sorry, been too busy to do so.  I
>> still don't understand the intent here.  The VM already provides a status
>> bit in parameter 65 which says whether the VM supports multiple bytecode
>> sets.  If the intent is to mark an image when multiple bytecode sets have
>> been used then the primitive doesn't appear to me to do what's required.
>> I'll try and answer in the context of the thread soon, because I agree it's
>> important.  Ideally there would be a pair of flags set somewhere that said
>> if the current image had ever executed a method in either bytecode set.
>>
>
let's discuss this in the context of the thread David started.


>
> All VMs check the image format to see if they can run the image. That's
> the only check they perform, as far as I know.
>
> That's why it seems appropriate to use a bit in the image format to mean
> "no, you can't run this if your VM does not understand the new byte code
> set".
>
> Otherwise e.g. SqueakJS or other Spur-compatible VMs would have to look at
> every single CompiledMethod to see if the alt byte code flag was set.
>
> Btw, Squeak is not going to mix bytecode sets - it's going to recompile
> all methods, so when snapshotting, they all use one or the other. In that
> scenario, a simple primitive call like David's should work, if it's done
> right after recompiling all.
>

Alas no.  We already mix bytecode sets.  IOne can set the preference do
some compiling, change the preference, do some compiling, etcd.  And so far
I've been too lazy to make the quick method generation use the preference.
All quick methods are in the original bytecode set (since quick methods
don't really use a bytecode other than the primitive bytecode).


But as I ask, I think we should discuss this in the thread David created.


> - Vanessa -
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/97a1e922/attachment.html>

From marcel.taeumel at hpi.de  Wed Jul 22 07:40:12 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Wed, 22 Jul 2020 09:40:12 +0200
Subject: [squeak-dev] MNU for ifNil: to preserve quick returns? :-)
In-Reply-To: <16397836-A037-4EB3-8271-498C2B4B724C@rowledge.org>
References: <Mailbird-d51422e2-2a6a-4aa8-921a-e11d230a565a@hpi.de>
 <16397836-A037-4EB3-8271-498C2B4B724C@rowledge.org>
Message-ID: <Mailbird-4fafa9fd-6348-4f80-a32e-c6290543155f@hpi.de>

Hi Tim.

> *If* we had private methods one could mark foobleDong as private and thereby safely use it internally.

As long as programmers cannot make their intent clear with a "private" category or "pvt"-prefix in selectors or just by intentionally (!) using instVars without accessors, having extra annotations for lookup visibility (e.g. public/private/protected) will not make things any better as they are now. We have idioms and patterns for this already.

Sure, programmers that keep on ignoring an interface's intent would be punished if such lookup visibility would be enforced. However, I don't think that's a good way to move forward with Squeak/Smalltalk. ;-) It would lock up the system in a way that might impair liveness and exploration.

Instead, tools can help programmers discover and correct their mistakes. Code critiques, linting tools, code browsers w/ embedded run-time information, ...

Best,
Marcel
Am 21.07.2020 19:08:55 schrieb tim Rowledge <tim at rowledge.org>:


> On 2020-07-21, at 1:36 AM, Marcel Taeumel wrote:
>
> I can choose to initialize an instVar eagerly in #initialize or lazily in its accessor via #ifNil:. Yet, the latter requires me to change that accessor to something not being a quick return.

I've always been a bit ambivalent about the lazy initialisation stuff; not that it doesn't have uses. The problematic bit in my experience is tied to the lack of properly private messages and the disappointing propensity of people to treat Smalltalk as C code.

To explain: one decides to have lazy init for an instvar and so creates a methods named as the instvar that does the nil check and init dance. Great - now you can write
`self foobleDong`
and guarantee to get a useful answer. The problem now is that you have made your class into little more than a C struct. Any old Thomas, Richard or Harold can send #foobleDong and get at the internal state of your object. I don't like that.
*If* we had private methods one could mark foobleDong as private and thereby safely use it internally.

I see far too much 'Cmalltalk' where messages are being sent as if they were C struct accessor operators. I really hate seeing
`myThing foo fum bar baz bing: myThing foo fum bar baz bing + 1`



tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"Bother!" said Pooh, as he stood up to his waist in a cow pat.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200722/01c12e0d/attachment.html>

From marcel.taeumel at hpi.de  Wed Jul 22 07:49:23 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Wed, 22 Jul 2020 09:49:23 +0200
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <alpine.DEB.2.02.2007212013320.23984@login03.caesar.elte.hu>
References: <CAC20JE3FLN8dJj7Qobm=AjF-HGbf1bqB-mtQA0FSmDY9ezA8kw@mail.gmail.com>
 <alpine.DEB.2.02.2007212013320.23984@login03.caesar.elte.hu>
Message-ID: <Mailbird-91b1d560-c279-44fb-9e76-398ff9735544@hpi.de>

Hi Levente.

> I'm thinking about checking the VM version in the preamble of the package
> and raising a Warning when it clearly lacks the required updates.
> Users can still continute with a Warning or terminate the update process,
> while cli tools will act as if an error had occured.

+1

A one-liner would be nice. The warning should also (roughly) point to the location of the new VM for download.

MCMcmUpdater checkVM: 202003021730. "and newer"

Best,
Marcel
Am 21.07.2020 20:21:39 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
Hi Eliot,

On Mon, 20 Jul 2020, Eliot Miranda wrote:

> Hi All,
>     I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows two methods
> (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods.  The issue is when to publish the corrections to trunk.
> Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests.  However, I do want to push the corrections soon, because they're a
> substantial improvement.  So the question is how long should I wait?
>
> Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM.

I think most people don't update their VMs often. I still tend to fire
up the one shipped with the 5.3 release. So, IMO the question is not how
long to wait but what to do when things are about to break.
I presume that without updating the VM, the image would not work properly.
So, I think the best would be if the user were warned during the update
if the VM would be incompatible with the changes.
I'm thinking about checking the VM version in the preamble of the package
and raising a Warning when it clearly lacks the required updates.
Users can still continute with a Warning or terminate the update process,
while cli tools will act as if an error had occured.


Levente

> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200722/2dad3845/attachment.html>

From lists at fniephaus.com  Wed Jul 22 09:33:48 2020
From: lists at fniephaus.com (Fabio Niephaus)
Date: Wed, 22 Jul 2020 11:33:48 +0200
Subject: [squeak-dev] A big thank you to whoever made the tree in
 FileList display in alphabetical order
In-Reply-To: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
Message-ID: <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>

Here's the commit:
http://forum.world.st/The-Trunk-Tools-tpr-980-mcz-td5118919.html

On Mon, Jul 20, 2020 at 8:03 PM gettimothy via Squeak-dev
<squeak-dev at lists.squeakfoundation.org> wrote:
>
> +!
>
>

From gettimothy at zoho.com  Wed Jul 22 12:51:02 2020
From: gettimothy at zoho.com (gettimothy)
Date: Wed, 22 Jul 2020 08:51:02 -0400
Subject: [squeak-dev] A big thank you to whoever made the tree in
 FileList display in alphabetical order
In-Reply-To: <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
 <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
Message-ID: <1737693c362.d1510302118270.4724924007149956132@zoho.com>

Thank you! And thank you TPR!


---- On Wed, 22 Jul 2020 05:33:48 -0400 lists at fniephaus.com wrote ----


Here's the commit:
http://forum.world.st/The-Trunk-Tools-tpr-980-mcz-td5118919.html

On Mon, Jul 20, 2020 at 8:03 PM gettimothy via Squeak-dev
<squeak-dev at lists.squeakfoundation.org> wrote:
>
> +!
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200722/16127bc4/attachment-0001.html>

From eliot.miranda at gmail.com  Wed Jul 22 14:40:53 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Wed, 22 Jul 2020 07:40:53 -0700
Subject: [squeak-dev] trunk and new vm etiquette
Message-ID: <681CA95F-1849-4091-AEFB-CEBD3F2449EB@gmail.com>



>> On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> Hi Levente.
> 
> > I'm thinking about checking the VM version in the preamble of the package
> > and raising a Warning when it clearly lacks the required updates.
> > Users can still continute with a Warning or terminate the update process,
> > while cli tools will act as if an error had occured.
> 
> +1
> 
> A one-liner would be nice. The warning should also (roughly) point to the location of the new VM for download.
> 
> MCMcmUpdater checkVM: 202003021730. "and newer"

I wrote it like this:

 "Use of the Spur FloatArray>>at:[put:] prims requires at least VMMaker.oscog.2778"

Smalltalk vmVMMakerVersion < 2778 ifTrue:
    [Warning signal: 'This virtual machine is too old to support correct versions of the FloatArray>>at:[put:] primitives 238 and 239.  FloatArray subclasses will not behave correctly and FloatArray[64]Test tests will fail.  Please upgrade your VM.  You may continue and upgrade later or abort and upgrade now.']!

> Best,
> Marcel
>> Am 21.07.2020 20:21:39 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
>> 
>> Hi Eliot, 
>> 
>> On Mon, 20 Jul 2020, Eliot Miranda wrote: 
>> 
>> > Hi All, 
>> >     I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows two methods 
>> > (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods.  The issue is when to publish the corrections to trunk. 
>> > Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests.  However, I do want to push the corrections soon, because they're a 
>> > substantial improvement.  So the question is how long should I wait? 
>> > 
>> > Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed 
>> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM. 
>> 
>> I think most people don't update their VMs often. I still tend to fire 
>> up the one shipped with the 5.3 release. So, IMO the question is not how 
>> long to wait but what to do when things are about to break. 
>> I presume that without updating the VM, the image would not work properly. 
>> So, I think the best would be if the user were warned during the update 
>> if the VM would be incompatible with the changes. 
>> I'm thinking about checking the VM version in the preamble of the package 
>> and raising a Warning when it clearly lacks the required updates. 
>> Users can still continute with a Warning or terminate the update process, 
>> while cli tools will act as if an error had occured. 
>> 
>> 
>> Levente 
>> 
>> > _,,,^..^,,,_ 
>> > best, Eliot 
>> > 
>> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200722/566e32b9/attachment.html>

From marcel.taeumel at hpi.de  Wed Jul 22 14:43:45 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Wed, 22 Jul 2020 16:43:45 +0200
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <681CA95F-1849-4091-AEFB-CEBD3F2449EB@gmail.com>
References: <681CA95F-1849-4091-AEFB-CEBD3F2449EB@gmail.com>
Message-ID: <Mailbird-98a3d41c-0d1f-45ca-911e-8e1eb6f5e1c6@hpi.de>

Hi Eliot,

looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm".

Best,
Marcel
Am 22.07.2020 16:41:08 schrieb Eliot Miranda <eliot.miranda at gmail.com>:


On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:



Hi Levente.

> I'm thinking about checking the VM version in the preamble of the package
> and raising a Warning when it clearly lacks the required updates.
> Users can still continute with a Warning or terminate the update process,
> while cli tools will act as if an error had occured.

+1

A one-liner would be nice. The warning should also (roughly) point to the location of the new VM for download.

MCMcmUpdater checkVM: 202003021730. "and newer"

I wrote it like this:

 "Use of the Spur FloatArray>>at:[put:] prims requires at least VMMaker.oscog.2778"

Smalltalk vmVMMakerVersion < 2778 ifTrue:
    [Warning signal: 'This virtual machine is too old to support correct versions of the FloatArray>>at:[put:] primitives 238 and 239.  FloatArray subclasses will not behave correctly and FloatArray[64]Test tests will fail.  Please upgrade your VM.  You may continue and upgrade later or abort and upgrade now.']!

Best,
Marcel
Am 21.07.2020 20:21:39 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
Hi Eliot,

On Mon, 20 Jul 2020, Eliot Miranda wrote:

> Hi All,
>     I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows two methods
> (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods.  The issue is when to publish the corrections to trunk.
> Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests.  However, I do want to push the corrections soon, because they're a
> substantial improvement.  So the question is how long should I wait?
>
> Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM.

I think most people don't update their VMs often. I still tend to fire
up the one shipped with the 5.3 release. So, IMO the question is not how
long to wait but what to do when things are about to break.
I presume that without updating the VM, the image would not work properly.
So, I think the best would be if the user were warned during the update
if the VM would be incompatible with the changes.
I'm thinking about checking the VM version in the preamble of the package
and raising a Warning when it clearly lacks the required updates.
Users can still continute with a Warning or terminate the update process,
while cli tools will act as if an error had occured.


Levente

> _,,,^..^,,,_
> best, Eliot
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200722/313989b6/attachment.html>

From tim at rowledge.org  Wed Jul 22 17:34:00 2020
From: tim at rowledge.org (tim Rowledge)
Date: Wed, 22 Jul 2020 10:34:00 -0700
Subject: [squeak-dev] triggering URLs from Squeak (was Re: trunk and new vm
 etiquette)
In-Reply-To: <Mailbird-98a3d41c-0d1f-45ca-911e-8e1eb6f5e1c6@hpi.de>
References: <681CA95F-1849-4091-AEFB-CEBD3F2449EB@gmail.com>
 <Mailbird-98a3d41c-0d1f-45ca-911e-8e1eb6f5e1c6@hpi.de>
Message-ID: <572588E5-A26C-43C9-9674-1904185DD89F@rowledge.org>



> On 2020-07-22, at 7:43 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> Hi Eliot,
> 
> looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm".

That reminds me; currently the system would complain about o web browser and offer this - 

We can do better, for certain probably interesting definitions of the word 'better'. In Scratch we use the ScratchPlugin primitive primOpenURL: and that defers to platform code within the plugin. In unix-land it uses the slightly scary xdg-open facility; I have no idea what the equivalent might be for other platforms but surely it must be doable. 

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
I am still waiting for the advent of the computer science groupie.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200722/5042169f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-07-22 at 10.20.24 AM.png
Type: image/png
Size: 17678 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200722/5042169f/attachment.png>

From tim at rowledge.org  Wed Jul 22 17:44:38 2020
From: tim at rowledge.org (tim Rowledge)
Date: Wed, 22 Jul 2020 10:44:38 -0700
Subject: [squeak-dev] FileList improvements (was Re: A big thank you to
 whoever made the tree in FileList display in alphabetical order)
In-Reply-To: <1737693c362.d1510302118270.4724924007149956132@zoho.com>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
 <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
 <1737693c362.d1510302118270.4724924007149956132@zoho.com>
Message-ID: <2C4F0A83-A82D-45C1-A64A-A46EF902BDE6@rowledge.org>



> On 2020-07-22, at 5:51 AM, gettimothy via Squeak-dev <squeak-dev at lists.squeakfoundation.org> wrote:
> 
> Thank you! And thank you TPR!

You're welcome. 

I'm thinking maybe an option to show/hide hidden files might be useful at some point too. 

And we still need to do something about better handling of remote servers; ftp isn't the best supported option anymore, the UI for dealing with adding/editing/removing them is terrible and our example servers are long evaporated.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
I'm so skeptical that I'm not sure I'm really a skeptic



From eliot.miranda at gmail.com  Wed Jul 22 17:50:18 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Wed, 22 Jul 2020 10:50:18 -0700
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <Mailbird-98a3d41c-0d1f-45ca-911e-8e1eb6f5e1c6@hpi.de>
References: <Mailbird-98a3d41c-0d1f-45ca-911e-8e1eb6f5e1c6@hpi.de>
Message-ID: <C87BE406-5841-4C6E-B7BC-D9254CD66004@gmail.com>



> On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> 
> Hi Eliot,
> 
> looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm".

Should we augment that with a direct pointer to the Appveyor CI server?

> 
> Best,
> Marcel
>> Am 22.07.2020 16:41:08 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>> 
>> 
>> 
>>>> On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>>>> 
>>> 
>>> Hi Levente.
>>> 
>>> > I'm thinking about checking the VM version in the preamble of the package
>>> > and raising a Warning when it clearly lacks the required updates.
>>> > Users can still continute with a Warning or terminate the update process,
>>> > while cli tools will act as if an error had occured.
>>> 
>>> +1
>>> 
>>> A one-liner would be nice. The warning should also (roughly) point to the location of the new VM for download.
>>> 
>>> MCMcmUpdater checkVM: 202003021730. "and newer"
>> 
>> I wrote it like this:
>> 
>>  "Use of the Spur FloatArray>>at:[put:] prims requires at least VMMaker.oscog.2778"
>> 
>> Smalltalk vmVMMakerVersion < 2778 ifTrue:
>>     [Warning signal: 'This virtual machine is too old to support correct versions of the FloatArray>>at:[put:] primitives 238 and 239.  FloatArray subclasses will not behave correctly and FloatArray[64]Test tests will fail.  Please upgrade your VM.  You may continue and upgrade later or abort and upgrade now.']!
>> 
>>> Best,
>>> Marcel
>>>> Am 21.07.2020 20:21:39 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
>>>> 
>>>> Hi Eliot, 
>>>> 
>>>> On Mon, 20 Jul 2020, Eliot Miranda wrote: 
>>>> 
>>>> > Hi All, 
>>>> >     I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows two methods 
>>>> > (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods.  The issue is when to publish the corrections to trunk. 
>>>> > Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests.  However, I do want to push the corrections soon, because they're a 
>>>> > substantial improvement.  So the question is how long should I wait? 
>>>> > 
>>>> > Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed 
>>>> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM. 
>>>> 
>>>> I think most people don't update their VMs often. I still tend to fire 
>>>> up the one shipped with the 5.3 release. So, IMO the question is not how 
>>>> long to wait but what to do when things are about to break. 
>>>> I presume that without updating the VM, the image would not work properly. 
>>>> So, I think the best would be if the user were warned during the update 
>>>> if the VM would be incompatible with the changes. 
>>>> I'm thinking about checking the VM version in the preamble of the package 
>>>> and raising a Warning when it clearly lacks the required updates. 
>>>> Users can still continute with a Warning or terminate the update process, 
>>>> while cli tools will act as if an error had occured. 
>>>> 
>>>> 
>>>> Levente 
>>>> 
>>>> > _,,,^..^,,,_ 
>>>> > best, Eliot 
>>>> > 
>>>> >
>>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200722/9622f5fd/attachment.html>

From forums.jakob at resfarm.de  Wed Jul 22 18:31:33 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Wed, 22 Jul 2020 20:31:33 +0200
Subject: [squeak-dev] triggering URLs from Squeak (was Re: trunk and new
 vm etiquette)
In-Reply-To: <572588E5-A26C-43C9-9674-1904185DD89F@rowledge.org>
References: <681CA95F-1849-4091-AEFB-CEBD3F2449EB@gmail.com>
 <Mailbird-98a3d41c-0d1f-45ca-911e-8e1eb6f5e1c6@hpi.de>
 <572588E5-A26C-43C9-9674-1904185DD89F@rowledge.org>
Message-ID: <CA+ovNC7YOzZhd6vnXBBJ10rCv8_J-bunYzi9Oogw0Dp4cbtnfQ@mail.gmail.com>

In my image I have wired this for Windows to ShellExecute via FFI. One
could put it in a plugin as well.

Object subclass: #ExternalWindowsWebBrowser
   instanceVariableNames: ''
   classVariableNames: ''
   poolDictionaries: ''
   category: 'jr'

initialize
   "ExternalWindowsWebBrowser initialize"
   WebBrowser register: self.

openOnUrl: aUrl
   ShellExecute execute: aUrl asString.

Object subclass: #ShellExecute
   instanceVariableNames: ''
   classVariableNames: ''
   poolDictionaries: ''
   category: 'jr'

execute: aString
   self assert: aString isString.
   ^ self apiShellExecuteForWindow: nil
      operation: nil
      file: aString
      parameters: nil
      directory: nil
      show: 5 "SW_SHOW"

apiShellExecuteForWindow: hwnd operation: operationString file:
fileString parameters: parametersString directory: directoryString
show: aBitfieldInteger
   <apicall: void* 'ShellExecuteA' (void* char* char* char* char*
long) module: 'Shell32.dll'>
   ^ self externalCallFailed


Am Mi., 22. Juli 2020 um 19:34 Uhr schrieb tim Rowledge <tim at rowledge.org>:
>
>
>
> On 2020-07-22, at 7:43 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>
> Hi Eliot,
>
> looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm".
>
>
> That reminds me; currently the system would complain about o web browser and offer this -
>
> We can do better, for certain probably interesting definitions of the word 'better'. In Scratch we use the ScratchPlugin primitive primOpenURL: and that defers to platform code within the plugin. In unix-land it uses the slightly scary xdg-open facility; I have no idea what the equivalent might be for other platforms but surely it must be doable.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> I am still waiting for the advent of the computer science groupie.
>
>
>

From asqueaker at gmail.com  Thu Jul 23 01:38:24 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Wed, 22 Jul 2020 20:38:24 -0500
Subject: [squeak-dev] FileList improvements (was Re: A big thank you to
 whoever made the tree in FileList display in alphabetical order)
In-Reply-To: <2C4F0A83-A82D-45C1-A64A-A46EF902BDE6@rowledge.org>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
 <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
 <1737693c362.d1510302118270.4724924007149956132@zoho.com>
 <2C4F0A83-A82D-45C1-A64A-A46EF902BDE6@rowledge.org>
Message-ID: <CANzdToEHHMnQ5YhjhujAPP20zbMVAT-tTxRBDX0k374nFw8odg@mail.gmail.com>

Please don't take this personally, I'd really like to see an option to turn
it off.  I *really miss* the plain, blazing-fast text box which let me
begin typing immediately, let me cut and paste fully-qualified names, and
literally, was a 10X faster workflow for the operations that now involve
being forced to navigate a tree, click-by-click, intermixed with scrolling
and visually scanning with my tired, bloodshot eyes.  Operations like
"image save as..." or "add repository..." went from < 1 second with no
disruption in thought, to > 10 seconds for it to put up the big dialog I
don't want to see at all because it almost always leaves me at... "umm..
what was I doing..?"

 - Chris

On Wed, Jul 22, 2020 at 12:44 PM tim Rowledge <tim at rowledge.org> wrote:

>
>
> > On 2020-07-22, at 5:51 AM, gettimothy via Squeak-dev <
> squeak-dev at lists.squeakfoundation.org> wrote:
> >
> > Thank you! And thank you TPR!
>
> You're welcome.
>
> I'm thinking maybe an option to show/hide hidden files might be useful at
> some point too.
>
> And we still need to do something about better handling of remote servers;
> ftp isn't the best supported option anymore, the UI for dealing with
> adding/editing/removing them is terrible and our example servers are long
> evaporated.
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> I'm so skeptical that I'm not sure I'm really a skeptic
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200722/3e4d8aed/attachment.html>

From tim at rowledge.org  Thu Jul 23 05:17:15 2020
From: tim at rowledge.org (tim Rowledge)
Date: Wed, 22 Jul 2020 22:17:15 -0700
Subject: [squeak-dev] FileList improvements (was Re: A big thank you to
 whoever made the tree in FileList display in alphabetical order)
In-Reply-To: <CANzdToEHHMnQ5YhjhujAPP20zbMVAT-tTxRBDX0k374nFw8odg@mail.gmail.com>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
 <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
 <1737693c362.d1510302118270.4724924007149956132@zoho.com>
 <2C4F0A83-A82D-45C1-A64A-A46EF902BDE6@rowledge.org>
 <CANzdToEHHMnQ5YhjhujAPP20zbMVAT-tTxRBDX0k374nFw8odg@mail.gmail.com>
Message-ID: <AB0EB97F-F37D-41CF-945D-090500B98E02@rowledge.org>



> On 2020-07-22, at 6:38 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> Please don't take this personally, I'd really like to see an option to turn it off.  I really miss the plain, blazing-fast text box which let me begin typing immediately, let me cut and paste fully-qualified names, and literally, was a 10X faster workflow for the operations that now involve being forced to navigate a tree, click-by-click, intermixed with scrolling and visually scanning with my tired, bloodshot eyes.  Operations like "image save as..." or "add repository..." went from < 1 second with no disruption in thought, to > 10 seconds for it to put up the big dialog I don't want to see at all because it almost always leaves me at... "umm..  what was I doing..?"

Feel free to add a preference if you feel you must. But note that on a Pi - the slowest machines in regular use with Squeak -  it takes less than 1 tenth of a second to open the image-save-as dialogue, so if your machine is taking even close to 10 seconds there is something interestingly weird going on and we need to profile it to find out why.

Also, simply type a file path in the text box and return. It even does the #assureExistence checks to make sure the path exists. Or use no path and it will save in the same directory it came from. Or paste that stuff in as before. It all still works.

Also, strictly speaking, gettimothy was referring to the FileList anyway...

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash



From marcel.taeumel at hpi.de  Thu Jul 23 11:41:17 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Thu, 23 Jul 2020 13:41:17 +0200
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <C87BE406-5841-4C6E-B7BC-D9254CD66004@gmail.com>
References: <Mailbird-98a3d41c-0d1f-45ca-911e-8e1eb6f5e1c6@hpi.de>
 <C87BE406-5841-4C6E-B7BC-D9254CD66004@gmail.com>
Message-ID: <Mailbird-87eb61d0-30c1-49ad-80bd-4ace0ac173ad@hpi.de>

Hmm... AppVeyor is just for the Windows builds. We might want to do a beta release for such crucial fixes and then point to the GitHub releases page?

Best,
Marcel
Am 22.07.2020 19:50:31 schrieb Eliot Miranda <eliot.miranda at gmail.com>:


On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:



Hi Eliot,

looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm".

Should we augment that with a direct pointer to the Appveyor CI server?


Best,
Marcel
Am 22.07.2020 16:41:08 schrieb Eliot Miranda <eliot.miranda at gmail.com>:


On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:



Hi Levente.

> I'm thinking about checking the VM version in the preamble of the package
> and raising a Warning when it clearly lacks the required updates.
> Users can still continute with a Warning or terminate the update process,
> while cli tools will act as if an error had occured.

+1

A one-liner would be nice. The warning should also (roughly) point to the location of the new VM for download.

MCMcmUpdater checkVM: 202003021730. "and newer"

I wrote it like this:

 "Use of the Spur FloatArray>>at:[put:] prims requires at least VMMaker.oscog.2778"

Smalltalk vmVMMakerVersion < 2778 ifTrue:
    [Warning signal: 'This virtual machine is too old to support correct versions of the FloatArray>>at:[put:] primitives 238 and 239.  FloatArray subclasses will not behave correctly and FloatArray[64]Test tests will fail.  Please upgrade your VM.  You may continue and upgrade later or abort and upgrade now.']!

Best,
Marcel
Am 21.07.2020 20:21:39 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
Hi Eliot,

On Mon, 20 Jul 2020, Eliot Miranda wrote:

> Hi All,
>     I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows two methods
> (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods.  The issue is when to publish the corrections to trunk.
> Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests.  However, I do want to push the corrections soon, because they're a
> substantial improvement.  So the question is how long should I wait?
>
> Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM.

I think most people don't update their VMs often. I still tend to fire
up the one shipped with the 5.3 release. So, IMO the question is not how
long to wait but what to do when things are about to break.
I presume that without updating the VM, the image would not work properly.
So, I think the best would be if the user were warned during the update
if the VM would be incompatible with the changes.
I'm thinking about checking the VM version in the preamble of the package
and raising a Warning when it clearly lacks the required updates.
Users can still continute with a Warning or terminate the update process,
while cli tools will act as if an error had occured.


Levente

> _,,,^..^,,,_
> best, Eliot
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200723/1def044d/attachment-0001.html>

From forums.jakob at resfarm.de  Thu Jul 23 12:50:42 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Thu, 23 Jul 2020 14:50:42 +0200
Subject: [squeak-dev] Debugging of other processes with wait
Message-ID: <CA+ovNC4LjMC+OCB0eidYYz-zmCfvMX3m9wZ7RAh3bB6yfpHJ2A@mail.gmail.com>

Hello,

Yesterday I needed to debug a process that is not the UI process. At
one point this background process waits on a Promise (so it will wait
on a Semaphore) that is supposed to be resolved in the UI process, so
the background process will block. If this point is reached while
stepping in the debugger, the UI process will block instead, since it
evaluates the debugger stepping on behalf of the background process.

What I did for now is to add an accessor on ProcessScheduler that
answers the activeProcess without sending #effectiveProcess, and check
in Promise>>wait whether this real active process is the UI process.
If it is, halt the debugged process before the Semaphore wait
primitive, and I proceed manually as soon as I am confident that the
promise is already resolved or rejected, so the wait will return
immediately.

wait
    "Wait unconditionally for this promise to become fulfilled or rejected."
    | sema |
    (state = #pending and: [Processor realProcess == Project
uiProcess]) ifTrue: [self halt].
    sema := Semaphore new.
    ...

But of course this is just a workaround. Is there a chance to extend
the Squeak debugger to deal with critical sections and waits? In
Eclipse for example, there is a list of threads; blocked/waiting
threads are annotated with an icon, as well as the top frame that
waits for something; you can debug other threads in the meantime. But
in Java the debugger is in another VM than the debugged process, so
the situation that the debugger steps in the UI process needs not be
resolved there in the first place.

Maybe if we know all the points/primitives where processes can be
blocked, we could make the stepping detect these, run them in another
process, make the debugger observe that process and show some info
about the waiting in a special top context in the meantime. Once the
other process is unblocked (or terminated if it does nothing else than
the wait), the debugger would continue to step the background process.
Could this work?

Or is there already another facility that works and which I should use?

Kind regards,
Jakob

From eliot.miranda at gmail.com  Thu Jul 23 14:37:03 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Thu, 23 Jul 2020 07:37:03 -0700
Subject: [squeak-dev] Debugging of other processes with wait
In-Reply-To: <CA+ovNC4LjMC+OCB0eidYYz-zmCfvMX3m9wZ7RAh3bB6yfpHJ2A@mail.gmail.com>
References: <CA+ovNC4LjMC+OCB0eidYYz-zmCfvMX3m9wZ7RAh3bB6yfpHJ2A@mail.gmail.com>
Message-ID: <60A16E3F-BDE8-4FA9-85D9-9F5441F5B751@gmail.com>

Hi Jakob,

    first, this seems like a really important issue that if addressed would improve the debugger a lot.  So in my asking questions I’m not trying to knock dune your proposals, only trying to understand the problem accurately.

> On Jul 23, 2020, at 5:50 AM, Jakob Reschke <forums.jakob at resfarm.de> wrote:
> 
> Hello,
> 
> Yesterday I needed to debug a process that is not the UI process. At
> one point this background process waits on a Promise (so it will wait
> on a Semaphore) that is supposed to be resolved in the UI process, so
> the background process will block. If this point is reached while
> stepping in the debugger, the UI process will block instead, since it
> evaluates the debugger stepping on behalf of the background process.

Can you describe the control flow when this occurs normally, outside the debugger?  I need to understand which processes execute waits.

> What I did for now is to add an accessor on ProcessScheduler that
> answers the activeProcess without sending #effectiveProcess, and check
> in Promise>>wait whether this real active process is the UI process.
> If it is, halt the debugged process before the Semaphore wait
> primitive, and I proceed manually as soon as I am confident that the
> promise is already resolved or rejected, so the wait will return
> immediately.

An alternative might be to have the debugger spawn a new UI process whenever it detects that the UI process is blocked.  This may have to be done by a background helper process that the debugger spawns or allows to run whenever the debugger steps, because of course the ui process is executing the step.

Without thinking things through, another alternative might be to have the debugger always use its own process.  The underlying issue is that if the ui process blocks in reality then it should block in the debugger, but we’d like to keep the debugger alive and we’d like to keep the ui alive.

So I suppose we could introduce a background process whose job it is to observe the ui process and if it detects the ui process is blocked for some time (1 second?) spawns a new ui process had reports (in the Transcript?, a pop-up in the new ui process?) that the ui process blocked.

> 
> wait
>    "Wait unconditionally for this promise to become fulfilled or rejected."
>    | sema |
>    (state = #pending and: [Processor realProcess == Project
> uiProcess]) ifTrue: [self halt].
>    sema := Semaphore new.
>    ...
> 
> But of course this is just a workaround. Is there a chance to extend
> the Squeak debugger to deal with critical sections and waits?

I don’t see how.  The debugger can spot a critical section entry or a wait if one is doing “send”, because then the debugger actually executes the primitive in Context>>#tryPrimitive:..., (IIRC, I’m on my phone).  But if the debugger steps then the critical section entry or wait will be executed by running code (the debugger runs step at full speed by using perform: and the code executed by the perform, while surrounded by an exception handler and an unwind-protect, is not virtualised in any way and so we have no easy way of intercepting critical section entry or waits).

> In
> Eclipse for example, there is a list of threads; blocked/waiting
> threads are annotated with an icon, as well as the top frame that
> waits for something; you can debug other threads in the meantime. But
> in Java the debugger is in another VM than the debugged process, so
> the situation that the debugger steps in the UI process needs not be
> resolved there in the first place.
> 
> Maybe if we know all the points/primitives where processes can be
> blocked, we could make the stepping detect these, run them in another
> process, make the debugger observe that process and show some info
> about the waiting in a special top context in the meantime. Once the
> other process is unblocked (or terminated if it does nothing else than
> the wait), the debugger would continue to step the background process.
> Could this work?
> 
> Or is there already another facility that works and which I should use?

As I say, I think a way that can work is detecting that the ui process has blocked and spawning a new ui process when that happens.  But when in the debugger we want to avoid the debugger blocking in step/send and hence only executing any actions before step/send and not those after step/send (eg removing exception handler and unwind-protect from the stack).  So architecturally, not having the debugger use the ui process and to use its own process seems like a good idea but a major change.

> Kind regards,
> Jakob

Cheers,
Eliot

From forums.jakob at resfarm.de  Thu Jul 23 16:57:12 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Thu, 23 Jul 2020 18:57:12 +0200
Subject: [squeak-dev] Debugging of other processes with wait
In-Reply-To: <60A16E3F-BDE8-4FA9-85D9-9F5441F5B751@gmail.com>
References: <CA+ovNC4LjMC+OCB0eidYYz-zmCfvMX3m9wZ7RAh3bB6yfpHJ2A@mail.gmail.com>
 <60A16E3F-BDE8-4FA9-85D9-9F5441F5B751@gmail.com>
Message-ID: <CA+ovNC6dLBdbKtXb2cBefs__6yAcaGH4+oBRQwDVcFB7UTGvEw@mail.gmail.com>

Hi Eliot,

Am Do., 23. Juli 2020 um 16:37 Uhr schrieb Eliot Miranda
<eliot.miranda at gmail.com>:
>
> > On Jul 23, 2020, at 5:50 AM, Jakob Reschke <forums.jakob at resfarm.de> wrote:
> >
> > Hello,
> >
> > Yesterday I needed to debug a process that is not the UI process. At
> > one point this background process waits on a Promise (so it will wait
> > on a Semaphore) that is supposed to be resolved in the UI process, so
> > the background process will block. If this point is reached while
> > stepping in the debugger, the UI process will block instead, since it
> > evaluates the debugger stepping on behalf of the background process.
>
> Can you describe the control flow when this occurs normally, outside the debugger?  I need to understand which processes execute waits.
>

There is a "background" process that implements a certain workflow.
There are one or more occasions during this workflow where user input
is required. To move away from modal dialogs, nesting the world loop,
and from writing all the business logic in a promise-style control
flow, I want this background process to suspend until the user has
provided the input (which happens in the UI process of course).

So:
1. The background process triggers a request in the UI process via
addDeferredUIMessage: or similar. Mind that this is not a modal
invocation, so it will return immediately.
2. The background process waits for the input. In this particular case
using Promise>>wait, which uses a Semaphore internally.
3. When the user is finished filling in the data, clicking the OK or
Cancel buttons (which happens in the UI process) must somehow signal
the background process to continue. In my current case, this happens
by fulfilling the Promise on which the background process waits. This
will signal the internal Promise Semaphore from the UI process.
4. The background process receives the signal on the Semaphore. It
resumes to get the user's input from the Promise and continues the
workflow.

Instead of a Promise, other mechanisms could be used as well:
- Use a Semaphore directly without Promise.
- Let the background process read from a shared queue.
- Let the background process suspend itself and be resumed from the UI
callback explicitly.


> > What I did for now is to add an accessor on ProcessScheduler that
> > answers the activeProcess without sending #effectiveProcess, and check
> > in Promise>>wait whether this real active process is the UI process.
> > If it is, halt the debugged process before the Semaphore wait
> > primitive, and I proceed manually as soon as I am confident that the
> > promise is already resolved or rejected, so the wait will return
> > immediately.
>
> An alternative might be to have the debugger spawn a new UI process whenever it detects that the UI process is blocked.  This may have to be done by a background helper process that the debugger spawns or allows to run whenever the debugger steps, because of course the ui process is executing the step.
>
> Without thinking things through, another alternative might be to have the debugger always use its own process.  The underlying issue is that if the ui process blocks in reality then it should block in the debugger, but we’d like to keep the debugger alive and we’d like to keep the ui alive.
>
> So I suppose we could introduce a background process whose job it is to observe the ui process and if it detects the ui process is blocked for some time (1 second?) spawns a new ui process had reports (in the Transcript?, a pop-up in the new ui process?) that the ui process blocked.
>

This sounds good at first and for my particular case. But in general
this might break some things even outside of a debugging session:
modal dialogs are allergic to switching the UI process (I guess
everyone has seen Monticello's "This modal dialog was interrupted,
please close it" message at some point). The other thing I can imagine
is that after blocking a few seconds the no-longer-UI process might do
something that needs to be done in the UI process, but won't use
addDeferredUIMessage: because the code was designed to run in the UI
process in the first place.

If we can get around this, an always responsive UI would be great of course.

> >
> > wait
> >    "Wait unconditionally for this promise to become fulfilled or rejected."
> >    | sema |
> >    (state = #pending and: [Processor realProcess == Project
> > uiProcess]) ifTrue: [self halt].
> >    sema := Semaphore new.
> >    ...
> >
> > But of course this is just a workaround. Is there a chance to extend
> > the Squeak debugger to deal with critical sections and waits?
>
> I don’t see how.  The debugger can spot a critical section entry or a wait if one is doing “send”, because then the debugger actually executes the primitive in Context>>#tryPrimitive:..., (IIRC, I’m on my phone).  But if the debugger steps then the critical section entry or wait will be executed by running code (the debugger runs step at full speed by using perform: and the code executed by the perform, while surrounded by an exception handler and an unwind-protect, is not virtualised in any way and so we have no easy way of intercepting critical section entry or waits).
>

We could add an AboutToWait notification around the code that calls
the primitive... but it would slow down processes that don't need it.
And if you add another blocking mechanism and forget to signal the
notification, the debugger will block again.

> > In
> > Eclipse for example, there is a list of threads; blocked/waiting
> > threads are annotated with an icon, as well as the top frame that
> > waits for something; you can debug other threads in the meantime. But
> > in Java the debugger is in another VM than the debugged process, so
> > the situation that the debugger steps in the UI process needs not be
> > resolved there in the first place.
> >
> > Maybe if we know all the points/primitives where processes can be
> > blocked, we could make the stepping detect these, run them in another
> > process, make the debugger observe that process and show some info
> > about the waiting in a special top context in the meantime. Once the
> > other process is unblocked (or terminated if it does nothing else than
> > the wait), the debugger would continue to step the background process.
> > Could this work?
> >
> > Or is there already another facility that works and which I should use?
>
> As I say, I think a way that can work is detecting that the ui process has blocked and spawning a new ui process when that happens.  But when in the debugger we want to avoid the debugger blocking in step/send and hence only executing any actions before step/send and not those after step/send (eg removing exception handler and unwind-protect from the stack).  So architecturally, not having the debugger use the ui process and to use its own process seems like a good idea but a major change.
>

Agreed.


From robert.withers at pm.me  Thu Jul 23 18:00:57 2020
From: robert.withers at pm.me (Robert Withers)
Date: Thu, 23 Jul 2020 18:00:57 +0000
Subject: [squeak-dev] Debugging of other processes with wait
In-Reply-To: <CA+ovNC6dLBdbKtXb2cBefs__6yAcaGH4+oBRQwDVcFB7UTGvEw@mail.gmail.com>
References: <CA+ovNC4LjMC+OCB0eidYYz-zmCfvMX3m9wZ7RAh3bB6yfpHJ2A@mail.gmail.com>
 <60A16E3F-BDE8-4FA9-85D9-9F5441F5B751@gmail.com>
 <CA+ovNC6dLBdbKtXb2cBefs__6yAcaGH4+oBRQwDVcFB7UTGvEw@mail.gmail.com>
Message-ID: <5729379a-9559-e8c7-1233-218e18353293@pm.me>

Hi Jakob,

I have asked you several times to comment on the Promise implementation in PromisesLocal, but you have not responded. This is unfortunate.

> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.

Although the Promise defined in Kernel-Processes has #wait protocol, this is really an anathema to Promise-style control flow. The #whenResolved: protocol should be used to register a reactor and no waits should occur.

One issue immediately apparent is that there is no event loop (In the PriorityVat) that secures single-threaded behavior in the promise. In PromisesLocal there is a LocalResolver who forwards all pending #whenResolved: messages to the new reference, on the event-loop Process (calls #redirectEventualMessage:).

See ERef #promiseInVat: for the pair production of an asociation with a PromiseERef and a LocalResolver. There is no equivalent to this in Kernel-Processes.

Promise-style control flow does not use mutexes nor semaphores. So I believe the fundamental model here is misused.

You said:

On 7/23/20 12:57 PM, Jakob Reschke wrote:

> To move away from modal dialogs, nesting the world loop,
> and from writing all the business logic in a promise-style control
> flow

So it is your intention to "move away from promise-style control flow." then I would suggest not using a Promise.

Kindly,
rabbit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200723/8b4a9187/attachment.html>

From commits at source.squeak.org  Thu Jul 23 23:06:44 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Thu, 23 Jul 2020 23:06:44 0000
Subject: [squeak-dev] The Trunk: EToys-eem.400.mcz
Message-ID: <E1jykIc-0002Z1-GW@andreas>

Eliot Miranda uploaded a new version of EToys to project The Trunk:
http://source.squeak.org/trunk/EToys-eem.400.mcz

==================== Summary ====================

Name: EToys-eem.400
Author: eem
Time: 23 July 2020, 4:06:39.960265 pm
UUID: cd372e46-6184-4c26-9528-da5309945631
Ancestors: EToys-eem.399

Allow the webcam resolution to be set before opening a WebCamMorph.

=============== Diff against EToys-eem.399 ===============

Item was changed:
  ----- Method: WebCamMorph>>setWebCamResolution: (in category 'e-toy - settings') -----
  setWebCamResolution: aSymbol
  	| wasOn |
+ 	"Failing silently here is awful; but that's what the code did :-("
+ 	(WebCamResolution resolutions includes: aSymbol) ifFalse: [^ self].
- 
- 	((WebCamResolution resolutions) includes: aSymbol) ifFalse: [^ self].
  	resolution := aSymbol.
  
  	(wasOn := camIsOn) ifTrue: [self off].
  	frameExtent := self class resolutionFor: aSymbol.
+ 	displayForm ifNotNil:
+ 		[displayForm := displayForm scaledToSize: frameExtent].
- 	displayForm := displayForm scaledToSize: frameExtent.
  	self updateDisplay.
+      wasOn ifTrue: [self on]
-      wasOn ifTrue: [self on].
- 			
- 
  !


From asqueaker at gmail.com  Fri Jul 24 03:36:07 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Thu, 23 Jul 2020 22:36:07 -0500
Subject: [squeak-dev] FileList improvements (was Re: A big thank you to
 whoever made the tree in FileList display in alphabetical order)
In-Reply-To: <AB0EB97F-F37D-41CF-945D-090500B98E02@rowledge.org>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
 <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
 <1737693c362.d1510302118270.4724924007149956132@zoho.com>
 <2C4F0A83-A82D-45C1-A64A-A46EF902BDE6@rowledge.org>
 <CANzdToEHHMnQ5YhjhujAPP20zbMVAT-tTxRBDX0k374nFw8odg@mail.gmail.com>
 <AB0EB97F-F37D-41CF-945D-090500B98E02@rowledge.org>
Message-ID: <CANzdToEeNLZ5nRXxV+w3L37bEfERtMX8Q_7Y90UdQpKbUWd=NA@mail.gmail.com>

>
> Feel free to add a preference if you feel you must.


Thanks since I know you don't care to have more preferences, but a "Sandbox
Mode" will be needed for the Dynabook experience.


> But note that on a Pi - the slowest machines in regular use with Squeak -
> it takes less than 1 tenth of a second to open the image-save-as dialogue,
> so if your machine is taking even close to 10 seconds there is something
> interestingly weird going on and we need to profile it to find out why.
>

It depends on how many and how deep the directories you have, and what kind
of HD they're on.  But another few seconds quickly accumulates simply from
having to grab the mouse just to regain focus on the field where I can type
the filename.  Even with my change which centers that field under the hand,
there's another "feature" which ensures dialogs are always, fully, 100%
on-screen.  So, the focus is lost.  It was trying to be friendly, but I
just wanted to paste in the name and be done.


> Also, simply type a file path in the text box and return. It even does the
> #assureExistence checks to make sure the path exists. Or use no path and it
> will save in the same directory it came from. Or paste that stuff in as
> before. It all still works.
>

Good to know!


> Also, strictly speaking, gettimothy was referring to the FileList anyway...
>

The alphabetization was a very overdue improvement, thanks.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200723/74be54f4/attachment.html>

From bruce.oneel at pckswarms.ch  Fri Jul 24 10:50:52 2020
From: bruce.oneel at pckswarms.ch (Bruce O'Neel)
Date: Fri, 24 Jul 2020 12:50:52 +0200
Subject: [squeak-dev] Flash morphic
Message-ID: <1595587852-8ddc1e8e5b89a3408e735d9e7d0c7581@pckswarms.ch>


  
  
Hi,  
Long time ago I think Andreas wrote a mostly done flash player in Morphic.   Does anyone else remember this or is my mind going?  
  
Is the code still around?  I ask because flash is going away at the end of the year and I might have a need to continue to use it.  An example of reading and displaying a SWF file could be quite useful.  
  
Thanks.  
  
bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/74b912b4/attachment.html>

From karlramberg at gmail.com  Fri Jul 24 17:55:12 2020
From: karlramberg at gmail.com (karl ramberg)
Date: Fri, 24 Jul 2020 19:55:12 +0200
Subject: [squeak-dev] Flash morphic
In-Reply-To: <1595587852-8ddc1e8e5b89a3408e735d9e7d0c7581@pckswarms.ch>
References: <1595587852-8ddc1e8e5b89a3408e735d9e7d0c7581@pckswarms.ch>
Message-ID: <CAGzzWLhsabp7uQsLueA3Sz+Zf8YfjQj6LCmnoh415v0ERtzwuw@mail.gmail.com>

It got removed from the main image long ago, it seems in release 3.10.

It was compatible with Flash version 1 I think.

Best,
Karl


On Fri, Jul 24, 2020 at 12:51 PM Bruce O'Neel <bruce.oneel at pckswarms.ch>
wrote:

>
>
> Hi,
> Long time ago I think Andreas wrote a mostly done flash player in Morphic.
>   Does anyone else remember this or is my mind going?
>
> Is the code still around?  I ask because flash is going away at the end of
> the year and I might have a need to continue to use it.  An example of
> reading and displaying a SWF file could be quite useful.
>
> Thanks.
>
> bruce
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/63d976bb/attachment.html>

From tim at rowledge.org  Fri Jul 24 19:04:01 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 24 Jul 2020 12:04:01 -0700
Subject: [squeak-dev] FileList improvements (was Re: A big thank you to
 whoever made the tree in FileList display in alphabetical order)
In-Reply-To: <CANzdToEeNLZ5nRXxV+w3L37bEfERtMX8Q_7Y90UdQpKbUWd=NA@mail.gmail.com>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
 <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
 <1737693c362.d1510302118270.4724924007149956132@zoho.com>
 <2C4F0A83-A82D-45C1-A64A-A46EF902BDE6@rowledge.org>
 <CANzdToEHHMnQ5YhjhujAPP20zbMVAT-tTxRBDX0k374nFw8odg@mail.gmail.com>
 <AB0EB97F-F37D-41CF-945D-090500B98E02@rowledge.org>
 <CANzdToEeNLZ5nRXxV+w3L37bEfERtMX8Q_7Y90UdQpKbUWd=NA@mail.gmail.com>
Message-ID: <6E623C7A-7334-416B-ADC0-49C437697328@rowledge.org>



> On 2020-07-23, at 8:36 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> It depends on how many and how deep the directories you have, and what kind of HD they're on.

Yes, I guess the directory tree traversing might take a long time in some cases; which in itself is probably sometihng deserving some profiling. Also one might consider a better navigation idiom than the rather (over, in my opinion) extensive "all the subdirectories of my parent directory and up we go" approach. It is (was) a *major* pain for RISC OS because of the expectation of multiple filing systems related to devices that have to try to spin up CDs etc just to decide whether there is a root there. But that just opens up a long complaint about the appalling state of filename handling.

>  But another few seconds quickly accumulates simply from having to grab the mouse just to regain focus on the field where I can type the filename.

The keyboard focus is in the text field immediately the dialogue is opened, so that ought not be a problem. I guess if it really has taken multiple seconds to build the directory tree morph then one might have moved the mousse around in that time and changed that?

The thing that I suspect would make a lot of people happy and have uses in many dialogue related situations is the building of a collapsing dialogue section. We had some discussion of the idea a while back and Marcel tried a few ideas. The dialogue ought to open with a label, the text field and an 'click me for more' icon - something vaguely like this -

Clicking the down-caret would open it up to a full directory handling tree widget. I believe this would be a major improvement.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Fractured Idiom:- HASTE CUISINE - Fast French food


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/238f7c2d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-07-24 at 11.59.34 AM.png
Type: image/png
Size: 42775 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/238f7c2d/attachment-0001.png>

From lewis at mail.msen.com  Fri Jul 24 20:19:18 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Fri, 24 Jul 2020 16:19:18 -0400
Subject: [squeak-dev] FileList improvements (was Re: A big thank you to
	whoever made the tree in FileList display in alphabetical order)
In-Reply-To: <6E623C7A-7334-416B-ADC0-49C437697328@rowledge.org>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
 <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
 <1737693c362.d1510302118270.4724924007149956132@zoho.com>
 <2C4F0A83-A82D-45C1-A64A-A46EF902BDE6@rowledge.org>
 <CANzdToEHHMnQ5YhjhujAPP20zbMVAT-tTxRBDX0k374nFw8odg@mail.gmail.com>
 <AB0EB97F-F37D-41CF-945D-090500B98E02@rowledge.org>
 <CANzdToEeNLZ5nRXxV+w3L37bEfERtMX8Q_7Y90UdQpKbUWd=NA@mail.gmail.com>
 <6E623C7A-7334-416B-ADC0-49C437697328@rowledge.org>
Message-ID: <20200724201918.GA97745@shell.msen.com>

On Fri, Jul 24, 2020 at 12:04:01PM -0700, tim Rowledge wrote:
> 
> 
> > On 2020-07-23, at 8:36 PM, Chris Muller <asqueaker at gmail.com> wrote:
> > 
> > It depends on how many and how deep the directories you have, and what kind of HD they're on.
> 
> Yes, I guess the directory tree traversing might take a long time in some cases; which in itself is probably sometihng deserving some profiling. Also one might consider a better navigation idiom than the rather (over, in my opinion) extensive "all the subdirectories of my parent directory and up we go" approach. It is (was) a *major* pain for RISC OS because of the expectation of multiple filing systems related to devices that have to try to spin up CDs etc just to decide whether there is a root there. But that just opens up a long complaint about the appalling state of filename handling.
> 
> >  But another few seconds quickly accumulates simply from having to grab the mouse just to regain focus on the field where I can type the filename.
> 
> The keyboard focus is in the text field immediately the dialogue is opened, so that ought not be a problem. I guess if it really has taken multiple seconds to build the directory tree morph then one might have moved the mousse around in that time and changed that?
> 

+1 for profiling.

-1 for more preferences.


> The thing that I suspect would make a lot of people happy and have uses in many dialogue related situations is the building of a collapsing dialogue section. We had some discussion of the idea a while back and Marcel tried a few ideas. The dialogue ought to open with a label, the text field and an 'click me for more' icon - something vaguely like this -
> 
> Clicking the down-caret would open it up to a full directory handling tree widget. I believe this would be a major improvement.
> 

That looks like a good approach.

Dave


From ma.chris.m at gmail.com  Fri Jul 24 20:23:20 2020
From: ma.chris.m at gmail.com (Chris Muller)
Date: Fri, 24 Jul 2020 15:23:20 -0500
Subject: [squeak-dev] FileList improvements (was Re: A big thank you to
 whoever made the tree in FileList display in alphabetical order)
In-Reply-To: <6E623C7A-7334-416B-ADC0-49C437697328@rowledge.org>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
 <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
 <1737693c362.d1510302118270.4724924007149956132@zoho.com>
 <2C4F0A83-A82D-45C1-A64A-A46EF902BDE6@rowledge.org>
 <CANzdToEHHMnQ5YhjhujAPP20zbMVAT-tTxRBDX0k374nFw8odg@mail.gmail.com>
 <AB0EB97F-F37D-41CF-945D-090500B98E02@rowledge.org>
 <CANzdToEeNLZ5nRXxV+w3L37bEfERtMX8Q_7Y90UdQpKbUWd=NA@mail.gmail.com>
 <6E623C7A-7334-416B-ADC0-49C437697328@rowledge.org>
Message-ID: <CADTxDUgb6Bse0vLcC-s7dgCaiE5p9ZNbApnAx0rtjY1X6oSYGA@mail.gmail.com>

>
> It depends on how many and how deep the directories you have, and what
> kind of HD they're on.
>
>
> Yes, I guess the directory tree traversing might take a long time in some
> cases; which in itself is probably sometihng deserving some profiling.
>

My understanding is it's a VM issue.


> Also one might consider a better navigation idiom than the rather (over,
> in my opinion) extensive "all the subdirectories of my parent directory and
> up we go" approach. It is (was) a *major* pain for RISC OS because of the
> expectation of multiple filing systems related to devices that have to try
> to spin up CDs etc just to decide whether there is a root there. But that
> just opens up a long complaint about the appalling state of filename
> handling.
>

+1


>
>  But another few seconds quickly accumulates simply from having to grab
> the mouse just to regain focus on the field where I can type the filename.
>
>
> The keyboard focus is in the text field immediately the dialogue is
> opened, so that ought not be a problem. I guess if it really has taken
> multiple seconds to build the directory tree morph then one might have
> moved the mousse around in that time and changed that?
>

It's because I use mouseOverForKeyboardFocus.  The dialog doesn't always
open with the text field under hand, so initial focus is lost.


> The thing that I suspect would make a lot of people happy and have uses in
> many dialogue related situations is the building of a collapsing dialogue
> section. We had some discussion of the idea a while back and Marcel tried a
> few ideas. The dialogue ought to open with a label, the text field and an
> 'click me for more' icon - something vaguely like this -
> Clicking the down-caret would open it up to a full directory handling tree
> widget. I believe this would be a major improvement.
>

I know that's the conventional look for "apps" that use files as their only
storage, but would you be open to considering a more "Squeak-style"
approach?  What if the regular text menu could have a "select file or
directory" entry added to it?  So it would be available _everywhere_ in the
IDE.  This "Squeak-style" approach preserves its sandbox capability
modelessly (e.g., without needing a preference), while still providing
developers that flexible hook for launching your dialog to select and paste
fully-qualified names, anywhere.

Unfortunately, Marcel concluded that ToolBuilder can't open a modal upon a
modal without at least hacking (that's paraphrased, BTW).  If Marcel's
finding is true, at least there's always the single-field text box as a
preference.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/2d8d1775/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-07-24 at 11.59.34 AM.png
Type: image/png
Size: 42775 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/2d8d1775/attachment.png>

From lewis at mail.msen.com  Fri Jul 24 20:37:29 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Fri, 24 Jul 2020 16:37:29 -0400
Subject: [squeak-dev] FileList improvements (was Re: A big thank you to
	whoever made the tree in FileList display in alphabetical order)
In-Reply-To: <CADTxDUgb6Bse0vLcC-s7dgCaiE5p9ZNbApnAx0rtjY1X6oSYGA@mail.gmail.com>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
 <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
 <1737693c362.d1510302118270.4724924007149956132@zoho.com>
 <2C4F0A83-A82D-45C1-A64A-A46EF902BDE6@rowledge.org>
 <CANzdToEHHMnQ5YhjhujAPP20zbMVAT-tTxRBDX0k374nFw8odg@mail.gmail.com>
 <AB0EB97F-F37D-41CF-945D-090500B98E02@rowledge.org>
 <CANzdToEeNLZ5nRXxV+w3L37bEfERtMX8Q_7Y90UdQpKbUWd=NA@mail.gmail.com>
 <6E623C7A-7334-416B-ADC0-49C437697328@rowledge.org>
 <CADTxDUgb6Bse0vLcC-s7dgCaiE5p9ZNbApnAx0rtjY1X6oSYGA@mail.gmail.com>
Message-ID: <20200724203729.GA994@shell.msen.com>

On Fri, Jul 24, 2020 at 03:23:20PM -0500, Chris Muller wrote:
> >
> > It depends on how many and how deep the directories you have, and what
> > kind of HD they're on.
> >
> >
> > Yes, I guess the directory tree traversing might take a long time in some
> > cases; which in itself is probably sometihng deserving some profiling.
> >
> 
> My understanding is it's a VM issue.
> 

Perhaps someone with a real-world use case could run a profiler on it and
find out where the time is going? It is sure to be dependent on the file
systems and operating systems and networks involved, so it might be quite
helpful to see the profile for a case where the system is behaving badly.

Dave


From robert.withers at pm.me  Fri Jul 24 20:51:58 2020
From: robert.withers at pm.me (Robert Withers)
Date: Fri, 24 Jul 2020 20:51:58 +0000
Subject: [squeak-dev] exploration of Cryptography's Local Promises (was: Re:
	Debugging of other processes with wait)
In-Reply-To: <5729379a-9559-e8c7-1233-218e18353293@pm.me>
References: <CA+ovNC4LjMC+OCB0eidYYz-zmCfvMX3m9wZ7RAh3bB6yfpHJ2A@mail.gmail.com>
 <60A16E3F-BDE8-4FA9-85D9-9F5441F5B751@gmail.com>
 <CA+ovNC6dLBdbKtXb2cBefs__6yAcaGH4+oBRQwDVcFB7UTGvEw@mail.gmail.com>
 <5729379a-9559-e8c7-1233-218e18353293@pm.me>
Message-ID: <92089110-31fd-a54e-f29c-4c569478886a@pm.me>

Hi Jakob,

I always want to assume best intentions, so I apologize for being somewhat snarky in my last post. I am not offended nor am I mad at you. Please don't be with me.

On 7/23/20 2:00 PM, Robert Withers wrote:

> I have asked you several times to comment on the Promise implementation in PromisesLocal, but you have not responded.
>
>> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.

In consideration of my promises, I realize you may not understand what I am proposing with the PromisesLocal package. It is a robust amount of functional code. PromisesLocal attempts to be a working implementation of the behaviors from ERights' ELib Concurrency [1], which predates Mark Miller's joining Google Research for the new JavaScript standard with his Promises/A+. I believe now that the differences between the Promise in Kernel-Proccesses and PromisesLocal is that PromisesLocal solves the concurrency issues, with its concurrency model. Read about this here:

[1] ELib's concurrency - http://www.erights.org/elib/concurrency/index.html

So allow me to demonstrate the outcomes of using PromisesLocal.

First image, taking a look at the Workspace, in the lower left above the Transcript, we have a good send, an exception send, and then another good send, demonstrating that the event loop does not get blocked. The first and last explorers resolve to 420. The middle explorer becomes a BrokenERef, due to the ZeroDivide. As well there is a debugger open for this exception, opened on a stack copy of the signaler context. The event loop continues to run but we have another process opened in the debugger.

For this debugger logic, please see

StandardToolSet class>>debugEventualException: anException
"For convenience. Construct a helper process to debug an exception that occurred in the active process later on so that the active process can (try to) resume. Uses a temporary variable to access and copy the signaler context now before it gets GC'ed."

| helperProcess |
helperProcess := (EventualProcess
forContext: anException signalerContext copyStack
priority: Processor activeProcess priority
onVat: Processor activeProcess vat)
shouldResumeFromDebugger: true;
yourself.

Project current addDeferredUIMessage: [
helperProcess
debugWithTitle: anException description
full: false].

I am calling this in EventualMessageSend>>#value if an exception occurs during the send.

Second image is of the situation after proceeding from the Debugger and then running the first line a second time, getting another NearERef of 42. The event-loop is active.

The third image demonstrates the PriorityVat running #nextProcessMsg (the event loop!) as well as another process for the ZeroDivide exception and its copied stack.

Finally, allow me to add a halt in the Vat's machinery to halt when an exception is handled in EventualMessageSend>>#value, this will halt on the ZeroDivide, after resolving the promise to broken, but before the stack copy of the signalerContext. This is before the helperProcess is made, so we see in the Processes there is the event loop open in the debugger (look for the process with a priority of 30). As this broke before the last item in the normalQ of the vat, the last explorer still shows a Promise. The event loop is blocked. When the Debugger is resumed or abandoned, the event loop DIES a quiet death, so we must clear it an restart the #local Vat, to regain operability, thus the new first line in the Workspace. I believe that adding a strategic call to #ifCurtailed: would be helpful here, to restart the Vat. i am unsure where to put this call.

I hope the workspace examples give you more familiarity of use and these images show what is actually happening with PromisesLocal.

Kindly,
rabbit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/f720856b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Promise-event-loop-test-halt.jpg
Type: image/jpeg
Size: 307818 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/f720856b/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Promise-event-loop-test-processes.jpg
Type: image/jpeg
Size: 47352 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/f720856b/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Promise-event-loop-test-post-proceed.jpg
Type: image/jpeg
Size: 226442 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/f720856b/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Promise-event-loop-test.jpg
Type: image/jpeg
Size: 234846 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200724/f720856b/attachment-0007.jpg>

From tim at rowledge.org  Fri Jul 24 21:13:58 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 24 Jul 2020 14:13:58 -0700
Subject: [squeak-dev] FileList improvements (was Re: A big thank you to
 whoever made the tree in FileList display in alphabetical order)
In-Reply-To: <CADTxDUgb6Bse0vLcC-s7dgCaiE5p9ZNbApnAx0rtjY1X6oSYGA@mail.gmail.com>
References: <1736d6543e6.118de13fa31018.2265306667292910863@zoho.com>
 <CADfnKi5RiNKc4r3WEOAzTGSXTdu=51P6zv1c0AsrZXvc977DRg@mail.gmail.com>
 <1737693c362.d1510302118270.4724924007149956132@zoho.com>
 <2C4F0A83-A82D-45C1-A64A-A46EF902BDE6@rowledge.org>
 <CANzdToEHHMnQ5YhjhujAPP20zbMVAT-tTxRBDX0k374nFw8odg@mail.gmail.com>
 <AB0EB97F-F37D-41CF-945D-090500B98E02@rowledge.org>
 <CANzdToEeNLZ5nRXxV+w3L37bEfERtMX8Q_7Y90UdQpKbUWd=NA@mail.gmail.com>
 <6E623C7A-7334-416B-ADC0-49C437697328@rowledge.org>
 <CADTxDUgb6Bse0vLcC-s7dgCaiE5p9ZNbApnAx0rtjY1X6oSYGA@mail.gmail.com>
Message-ID: <4A938BCC-7AE2-49D8-9AD5-409E4DE82615@rowledge.org>



> On 2020-07-24, at 1:23 PM, Chris Muller <ma.chris.m at gmail.com> wrote:
> 
>>  But another few seconds quickly accumulates simply from having to grab the mouse just to regain focus on the field where I can type the filename.
> 
> The keyboard focus is in the text field immediately the dialogue is opened, so that ought not be a problem. I guess if it really has taken multiple seconds to build the directory tree morph then one might have moved the mousse around in that time and changed that?
> 
> It's because I use mouseOverForKeyboardFocus.  The dialog doesn't always open with the text field under hand, so initial focus is lost.

Oh, well I don't use that option because it drives me nuts, so obviously I won't see that issue. 

So, what actually happens when you go for a 'save as'? Somewhere you are triggering it, presumably from the dock or the World menu? What happens that makes it problematic?

> I know that's the conventional look for "apps" that use files as their only storage, but would you be open to considering a more "Squeak-style" approach?  

I'm open to anything that makes it really easy to get people to save a freshly opened new image under a new name and (generally because of the way the all-in-one etc work right now) in a new directory. That was the driving intent that lead me to make the new file dialogues, though I claim they have plenty of other uses.

In a properly thought out GUI (*couch*RISC OS*cough*) the idiom would be to have a tiny file save dialogue with a text field, yes/no buttons and a draggable icon that you drag to any filer anywhere on the systm. That works brilliantly to handle saving to files, other machines, remote sites, printers, fax machines (yes, you could try faxing an application), compression utilities, other applications, all in a perfectly uniform manner. Why did nobody else steal this brilliant idea? 


> What if the regular text menu could have a "select file or directory" entry added to it?  So it would be available _everywhere_ in the IDE.  This "Squeak-style" approach preserves its sandbox capability modelessly (e.g., without needing a preference), while still providing developers that flexible hook for launching your dialog to select and paste fully-qualified names, anywhere.

I'd need some more explanation for that. What would the workflow for it be? Do we want still more entries in menus all over the place (because to be honest I think we need some serious trimming of menus combined with making proper use of hierarchical menus) or am I misunderstanderising?


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Borrow money from pessimists--they don't expect it back.



From robert.withers at pm.me  Sat Jul 25 12:13:38 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sat, 25 Jul 2020 12:13:38 +0000
Subject: [squeak-dev] error on process termination
Message-ID: <a7a1a628-8d90-39f1-bd66-b387bed1e59b@pm.me>

Hi y'all,

I am getting an error when terminating my process and it loops infinitely stacking this error recursively.

> nil doesNotUnderstand: stepToCallee

This is called from Context>>#runUntilErrorOrReturnFrom: aSender after this method has tried to get the topContext. Somehow topContext is nil, and I am guessing that returns from one of the context pops, in the following code from #runUntilErrorOrReturnFrom:.

> "Control resumes here once above ensure block or exception handler is executed"
> ^ error ifNil: [
> "No error was raised, remove ensure context by stepping until popped"
> [ctxt isDead] whileFalse: [topContext := topContext stepToCallee].
> {topContext. nil}

Have I setup the process incorrectly to receive this error or is something else the issue?

Appreciated.

Kindly,
rabbit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200725/ffc92d66/attachment.html>

From robert.withers at pm.me  Sat Jul 25 12:22:47 2020
From: robert.withers at pm.me (Robert Withers)
Date: Sat, 25 Jul 2020 12:22:47 +0000
Subject: [squeak-dev] error on process termination
In-Reply-To: <a7a1a628-8d90-39f1-bd66-b387bed1e59b@pm.me>
References: <a7a1a628-8d90-39f1-bd66-b387bed1e59b@pm.me>
Message-ID: <cf89737d-1816-8a5e-a175-e032e9d9d5c7@pm.me>

To give you more context, I am looking into gaurding the Vat's eventualProcess to restart when curtailed. This method is the main processing event loop. Below that is the #restartEventLoop method.

> PriorityVat>>#processSends
>
> [
> [Processor yield.
> self nextPriorityMsg ifNotNil: [:msg | msg value].
> normalQ notNil ] ifCurtailed: [self restartEventLoop]] whileTrue
>
> PriorityVat>>#restartEventLoop
>
> | currentEventLoop |
> (Processor activeProcess == eventualProcess) ifTrue: [
> eventualProcess ifNotNil: [:ea | currentEventLoop := ea].
> eventualProcess := nil.
> eventualProcess := EventualProcess newOnVat: self.
> eventualProcess resumeAsProcess.
> currentEventLoop ifNotNil: [:ea | ea terminate ]].

The termination is where the #stepToCallee error occurs.

K, r

On 7/25/20 8:13 AM, Robert Withers wrote:

> Hi y'all,
>
> I am getting an error when terminating my process and it loops infinitely stacking this error recursively.
>
>> nil doesNotUnderstand: stepToCallee
>
> This is called from Context>>#runUntilErrorOrReturnFrom: aSender after this method has tried to get the topContext. Somehow topContext is nil, and I am guessing that returns from one of the context pops, in the following code from #runUntilErrorOrReturnFrom:.
>
>> "Control resumes here once above ensure block or exception handler is executed"
>> ^ error ifNil: [
>> "No error was raised, remove ensure context by stepping until popped"
>> [ctxt isDead] whileFalse: [topContext := topContext stepToCallee].
>> {topContext. nil}
>
> Have I setup the process incorrectly to receive this error or is something else the issue?
>
> Appreciated.
>
> Kindly,
> rabbit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200725/452c1518/attachment.html>

From lewis at mail.msen.com  Sat Jul 25 17:04:51 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Sat, 25 Jul 2020 13:04:51 -0400
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak 5.2
	and 5.3 on files.squeak.org?
Message-ID: <20200725170451.GA11257@shell.msen.com>

A couple of years ago, I put a copy of a Squeak 5.2 image in V3 object
memory format on the squeakvm.org server, and I linked to it from the
project page at http://www.squeaksource.com/TrunkUpdateStreamV3. That link
has gone dead, and I think I recall someone noticing it a recently.

I still have the files, should I put them somewhere on files.squeak.org?
I was thinking of putting them under the "various_images" folder:

	files.squeak.org/various_images/squeak_V3_images/

I also have a V3 image that is up to date with the Squeak 5.3 release,
so I could put that on line as well.

These images will run under an up-to-date interpreter VM or a Cog VM. They
may be of interest to people doing VM work, benchmarking, or as a reference
to understand the image-side differences between Spur and V3.

Dave

From tim at rowledge.org  Sat Jul 25 17:35:22 2020
From: tim at rowledge.org (tim Rowledge)
Date: Sat, 25 Jul 2020 10:35:22 -0700
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
 5.2 and 5.3 on files.squeak.org?
In-Reply-To: <20200725170451.GA11257@shell.msen.com>
References: <20200725170451.GA11257@shell.msen.com>
Message-ID: <180A4AA2-AEB1-4EF7-90E9-E2275DFA9260@rowledge.org>

Hard to think of any reason *not* to have them available. 

> On 2020-07-25, at 10:04 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> A couple of years ago, I put a copy of a Squeak 5.2 image in V3 object
> memory format on the squeakvm.org server, and I linked to it from the
> project page at http://www.squeaksource.com/TrunkUpdateStreamV3. That link
> has gone dead, and I think I recall someone noticing it a recently.
> 
> I still have the files, should I put them somewhere on files.squeak.org?
> I was thinking of putting them under the "various_images" folder:
> 
> 	files.squeak.org/various_images/squeak_V3_images/
> 
> I also have a V3 image that is up to date with the Squeak 5.3 release,
> so I could put that on line as well.
> 
> These images will run under an up-to-date interpreter VM or a Cog VM. They
> may be of interest to people doing VM work, benchmarking, or as a reference
> to understand the image-side differences between Spur and V3.
> 
> Dave
> 
> 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
How was Thomas J. Watson buried?  9 edge down.



From lewis at mail.msen.com  Sat Jul 25 20:07:28 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Sat, 25 Jul 2020 16:07:28 -0400
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
	5.2 and 5.3 on files.squeak.org?
In-Reply-To: <180A4AA2-AEB1-4EF7-90E9-E2275DFA9260@rowledge.org>
References: <20200725170451.GA11257@shell.msen.com>
 <180A4AA2-AEB1-4EF7-90E9-E2275DFA9260@rowledge.org>
Message-ID: <20200725200728.GA36939@shell.msen.com>

Moving this to box-admins for assistance.

I have a couple of images that I would like to preserve for posterity
on files.squeak.org. They can go in a new folder under "various_images"

   files.squeak.org/various_images/squeak_V3_images/

Can someone on box-admins help me make this happen? I do not have access
to the server but I can put the files out on a google drive if that works.

I zipped up the files and put them here:

  https://drive.google.com/file/d/1wUZa4IHEkaTqzgwR3K1Wcwa9ckb7iVo2/view?usp=sharing

Thanks,
Dave


On Sat, Jul 25, 2020 at 10:35:22AM -0700, tim Rowledge wrote:
> Hard to think of any reason *not* to have them available. 
> 
> > On 2020-07-25, at 10:04 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > A couple of years ago, I put a copy of a Squeak 5.2 image in V3 object
> > memory format on the squeakvm.org server, and I linked to it from the
> > project page at http://www.squeaksource.com/TrunkUpdateStreamV3. That link
> > has gone dead, and I think I recall someone noticing it a recently.
> > 
> > I still have the files, should I put them somewhere on files.squeak.org?
> > I was thinking of putting them under the "various_images" folder:
> > 
> > 	files.squeak.org/various_images/squeak_V3_images/
> > 
> > I also have a V3 image that is up to date with the Squeak 5.3 release,
> > so I could put that on line as well.
> > 
> > These images will run under an up-to-date interpreter VM or a Cog VM. They
> > may be of interest to people doing VM work, benchmarking, or as a reference
> > to understand the image-side differences between Spur and V3.
> > 
> > Dave
> > 
> > 
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> How was Thomas J. Watson buried?  9 edge down.
> 
> 
> 

From eliot.miranda at gmail.com  Sun Jul 26 03:33:38 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Sat, 25 Jul 2020 20:33:38 -0700
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
 5.2 and 5.3 on files.squeak.org?
In-Reply-To: <20200725170451.GA11257@shell.msen.com>
References: <20200725170451.GA11257@shell.msen.com>
Message-ID: <CAC20JE0vbEN4ShVu2jTuJ3L7Z6G1+0KBuCc64esjLRUQfUyVJQ@mail.gmail.com>

Hi David,

On Sat, Jul 25, 2020 at 10:04 AM David T. Lewis <lewis at mail.msen.com> wrote:

> A couple of years ago, I put a copy of a Squeak 5.2 image in V3 object
> memory format on the squeakvm.org server, and I linked to it from the
> project page at http://www.squeaksource.com/TrunkUpdateStreamV3. That link
> has gone dead, and I think I recall someone noticing it a recently.
>
> I still have the files, should I put them somewhere on files.squeak.org?
> I was thinking of putting them under the "various_images" folder:
>
>         files.squeak.org/various_images/squeak_V3_images/
>
> I also have a V3 image that is up to date with the Squeak 5.3 release,
> so I could put that on line as well.
>
> These images will run under an up-to-date interpreter VM or a Cog VM. They
> may be of interest to people doing VM work, benchmarking, or as a reference
> to understand the image-side differences between Spur and V3.
>

This is definitely useful.  My only concern is if this moves trunk towards
having code that supports both v3 and Spur.  I don't want the complexity or
the unnecessary overhead that entails.  So can we please keep a series of
patches to keep 5.x/6.x v3 going and not change trunk to accomodate?


> Dave
>

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200725/41b6f107/attachment.html>

From commits at source.squeak.org  Sun Jul 26 03:44:48 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Sun, 26 Jul 2020 03:44:48 0000
Subject: [squeak-dev] The Trunk: CollectionsTests-ul.341.mcz
Message-ID: <E1jzXak-00042c-0N@andreas>

Eliot Miranda uploaded a new version of CollectionsTests to project The Trunk:
http://source.squeak.org/trunk/CollectionsTests-ul.341.mcz

==================== Summary ====================

Name: CollectionsTests-ul.341
Author: eem
Time: 25 July 2020, 8:44:46.338509 pm
UUID: 1b22fd11-c092-46ba-bd26-526080294ab8
Ancestors: CollectionsTests-ul.340

Fix an old spelling error.
Using Levente's initials for the package version and the change stamp because this is his code.  I only noticed and fixed the speeling error.  No other changes. eem 7/25/2020.  I beg forgiveness if this is in any way offensive.

=============== Diff against CollectionsTests-ul.340 ===============

Item was added:
+ ----- Method: ByteArrayTest>>testPlatformIndependentIntegerAccessorsAtBitBorders (in category 'tests - platform independent access') -----
+ testPlatformIndependentIntegerAccessorsAtBitBorders
+ 
+ 	#(
+ 		shortAt:put:bigEndian: shortAt:bigEndian: false 16
+ 		longAt:put:bigEndian: longAt:bigEndian: false 32
+ 		long64At:put:bigEndian: long64At:bigEndian: false 64
+ 		unsignedShortAt:put:bigEndian: unsignedShortAt:bigEndian: true 16
+ 		unsignedLongAt:put:bigEndian: unsignedLongAt:bigEndian: true 32
+ 		unsignedLong64At:put:bigEndian: unsignedLong64At:bigEndian: true 64		
+ 	) groupsDo: [ :setter :getter :unsigned :storageBits |
+ 		self
+ 			verifyPlatformIndependentIntegerAccessorsAtBitBordersSetter: setter
+ 			getter: getter
+ 			unsigned: unsigned
+ 			storageBits: storageBits ]!

Item was added:
+ ----- Method: ByteArrayTest>>testPlatformIndependentIntegerAccessorsWithRandomValues (in category 'tests - platform independent access') -----
+ testPlatformIndependentIntegerAccessorsWithRandomValues
+ 
+ 	| random |
+ 	random := Random seed: 36rSqueak.
+ 	#(
+ 		shortAt:put:bigEndian: shortAt:bigEndian: false 16
+ 		longAt:put:bigEndian: longAt:bigEndian: false 32
+ 		long64At:put:bigEndian: long64At:bigEndian: false 64
+ 		unsignedShortAt:put:bigEndian: unsignedShortAt:bigEndian: true 16
+ 		unsignedLongAt:put:bigEndian: unsignedLongAt:bigEndian: true 32
+ 		unsignedLong64At:put:bigEndian: unsignedLong64At:bigEndian: true 64		
+ 	) groupsDo: [ :setter :getter :unsigned :storageBits |
+ 		self
+ 			verifyPlatformIndependentIntegerAccessorsWithRandomValuesSetter: setter
+ 			getter: getter
+ 			unsigned: unsigned
+ 			storageBits: storageBits
+ 			random: random ]!

Item was removed:
- ----- Method: ByteArrayTest>>testPlatformIndepentendIntegerAccessorsAtBitBorders (in category 'tests - platform independent access') -----
- testPlatformIndepentendIntegerAccessorsAtBitBorders
- 
- 	#(
- 		shortAt:put:bigEndian: shortAt:bigEndian: false 16
- 		longAt:put:bigEndian: longAt:bigEndian: false 32
- 		long64At:put:bigEndian: long64At:bigEndian: false 64
- 		unsignedShortAt:put:bigEndian: unsignedShortAt:bigEndian: true 16
- 		unsignedLongAt:put:bigEndian: unsignedLongAt:bigEndian: true 32
- 		unsignedLong64At:put:bigEndian: unsignedLong64At:bigEndian: true 64		
- 	) groupsDo: [ :setter :getter :unsigned :storageBits |
- 		self
- 			verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter: setter
- 			getter: getter
- 			unsigned: unsigned
- 			storageBits: storageBits ]!

Item was removed:
- ----- Method: ByteArrayTest>>testPlatformIndepentendIntegerAccessorsWithRandomValues (in category 'tests - platform independent access') -----
- testPlatformIndepentendIntegerAccessorsWithRandomValues
- 
- 	| random |
- 	random := Random seed: 36rSqueak.
- 	#(
- 		shortAt:put:bigEndian: shortAt:bigEndian: false 16
- 		longAt:put:bigEndian: longAt:bigEndian: false 32
- 		long64At:put:bigEndian: long64At:bigEndian: false 64
- 		unsignedShortAt:put:bigEndian: unsignedShortAt:bigEndian: true 16
- 		unsignedLongAt:put:bigEndian: unsignedLongAt:bigEndian: true 32
- 		unsignedLong64At:put:bigEndian: unsignedLong64At:bigEndian: true 64		
- 	) groupsDo: [ :setter :getter :unsigned :storageBits |
- 		self
- 			verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter: setter
- 			getter: getter
- 			unsigned: unsigned
- 			storageBits: storageBits
- 			random: random ]!

Item was added:
+ ----- Method: ByteArrayTest>>verifyPlatformIndependentIntegerAccessorsAtBitBordersSetter:getter:unsigned:storageBits: (in category 'tests - platform independent access') -----
+ verifyPlatformIndependentIntegerAccessorsAtBitBordersSetter: setter getter: getter unsigned: unsigned storageBits: storageBits
+ 
+ 	| byteArray minValue maxValue baseValues |
+ 	byteArray := ByteArray new: storageBits // 8 * 2.
+ 	unsigned
+ 		ifTrue: [
+ 			minValue := 0.
+ 			maxValue := 1 << storageBits - 1.
+ 			baseValues := #(0 1) ]
+ 		ifFalse: [
+ 			minValue := -1 << (storageBits - 1).
+ 			maxValue := 1 << (storageBits - 1) - 1.
+ 			baseValues := #(-1 0 1) ].
+ 	#(true false) do: [ :bigEndian |
+ 		0 to: storageBits - 1 do: [ :bits |
+ 			baseValues do: [ :baseValue |
+ 				| centerValue |
+ 				centerValue := baseValue << bits.
+ 				centerValue - 1 to: centerValue + 1 do: [ :value |
+ 					(value between: minValue and: maxValue) ifTrue: [
+ 						self
+ 							verifyPlatformIndependentIntegerAccessorsMatch: byteArray
+ 							for: value
+ 							setter: setter
+ 							getter: getter
+ 							storageBits: storageBits
+ 							bigEndian: bigEndian  ] ] ] ] ]
+ 					!

Item was added:
+ ----- Method: ByteArrayTest>>verifyPlatformIndependentIntegerAccessorsMatch:for:setter:getter:storageBits:bigEndian: (in category 'tests - platform independent access') -----
+ verifyPlatformIndependentIntegerAccessorsMatch: byteArray for: value setter: setter getter: getter storageBits: storageBits bigEndian: bigEndian
+ 	
+ 	| expectedSetterResult getterResult bytes |
+ 	expectedSetterResult := self byteArrayFor: value bits: storageBits bigEndian: bigEndian.
+ 	bytes := storageBits // 8.
+ 	1 to: byteArray size - bytes + 1 do: [ :index |
+ 		byteArray
+ 			perform: setter
+ 			with: index
+ 			with: value
+ 			with: bigEndian.
+ 		1 to: bytes do: [ :byteIndex |
+ 			self
+ 				assert: (expectedSetterResult at: byteIndex)
+ 				equals: (byteArray at: index + byteIndex - 1) ].
+ 		getterResult := byteArray
+ 			perform: getter
+ 			with: index
+ 			with: bigEndian.
+ 		self assert: value equals: getterResult ]!

Item was added:
+ ----- Method: ByteArrayTest>>verifyPlatformIndependentIntegerAccessorsWithRandomValuesSetter:getter:unsigned:storageBits:random: (in category 'tests - platform independent access') -----
+ verifyPlatformIndependentIntegerAccessorsWithRandomValuesSetter: setter getter: getter unsigned: unsigned storageBits: storageBits random: random
+ 
+ 	| byteArray randomMax randomOffset |
+ 	byteArray := ByteArray new: storageBits // 8 * 2.
+ 	randomMax := 1 << storageBits.
+ 	randomOffset := unsigned
+ 		ifTrue: [ -1 ]
+ 		ifFalse: [ -1 << (storageBits - 1) - 1 ].
+ 	10000 timesRepeat: [
+ 		| value |
+ 		value := (random nextInt: randomMax) + randomOffset.
+ 		#(true false) do: [ :bigEndian |
+ 			self
+ 				verifyPlatformIndependentIntegerAccessorsMatch: byteArray
+ 				for: value
+ 				setter: setter
+ 				getter: getter
+ 				storageBits: storageBits
+ 				bigEndian: bigEndian ] ]!

Item was removed:
- ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter:getter:unsigned:storageBits: (in category 'tests - platform independent access') -----
- verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter: setter getter: getter unsigned: unsigned storageBits: storageBits
- 
- 	| byteArray minValue maxValue baseValues |
- 	byteArray := ByteArray new: storageBits // 8 * 2.
- 	unsigned
- 		ifTrue: [
- 			minValue := 0.
- 			maxValue := 1 << storageBits - 1.
- 			baseValues := #(0 1) ]
- 		ifFalse: [
- 			minValue := -1 << (storageBits - 1).
- 			maxValue := 1 << (storageBits - 1) - 1.
- 			baseValues := #(-1 0 1) ].
- 	#(true false) do: [ :bigEndian |
- 		0 to: storageBits - 1 do: [ :bits |
- 			baseValues do: [ :baseValue |
- 				| centerValue |
- 				centerValue := baseValue << bits.
- 				centerValue - 1 to: centerValue + 1 do: [ :value |
- 					(value between: minValue and: maxValue) ifTrue: [
- 						self
- 							verifyPlatformIndepentendIntegerAccessorsMatch: byteArray
- 							for: value
- 							setter: setter
- 							getter: getter
- 							storageBits: storageBits
- 							bigEndian: bigEndian  ] ] ] ] ]
- 					!

Item was removed:
- ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsMatch:for:setter:getter:storageBits:bigEndian: (in category 'tests - platform independent access') -----
- verifyPlatformIndepentendIntegerAccessorsMatch: byteArray for: value setter: setter getter: getter storageBits: storageBits bigEndian: bigEndian
- 	
- 	| expectedSetterResult getterResult bytes |
- 	expectedSetterResult := self byteArrayFor: value bits: storageBits bigEndian: bigEndian.
- 	bytes := storageBits // 8.
- 	1 to: byteArray size - bytes + 1 do: [ :index |
- 		byteArray
- 			perform: setter
- 			with: index
- 			with: value
- 			with: bigEndian.
- 		1 to: bytes do: [ :byteIndex |
- 			self
- 				assert: (expectedSetterResult at: byteIndex)
- 				equals: (byteArray at: index + byteIndex - 1) ].
- 		getterResult := byteArray
- 			perform: getter
- 			with: index
- 			with: bigEndian.
- 		self assert: value equals: getterResult ]!

Item was removed:
- ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter:getter:unsigned:storageBits:random: (in category 'tests - platform independent access') -----
- verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter: setter getter: getter unsigned: unsigned storageBits: storageBits random: random
- 
- 	| byteArray randomMax randomOffset |
- 	byteArray := ByteArray new: storageBits // 8 * 2.
- 	randomMax := 1 << storageBits.
- 	randomOffset := unsigned
- 		ifTrue: [ -1 ]
- 		ifFalse: [ -1 << (storageBits - 1) - 1 ].
- 	10000 timesRepeat: [
- 		| value |
- 		value := (random nextInt: randomMax) + randomOffset.
- 		#(true false) do: [ :bigEndian |
- 			self
- 				verifyPlatformIndepentendIntegerAccessorsMatch: byteArray
- 				for: value
- 				setter: setter
- 				getter: getter
- 				storageBits: storageBits
- 				bigEndian: bigEndian ] ]!


From stes at telenet.be  Sun Jul 26 09:39:11 2020
From: stes at telenet.be (stes@PANDORA.BE)
Date: Sun, 26 Jul 2020 11:39:11 +0200 (CEST)
Subject: [squeak-dev] Squeak on Solaris 11.4
Message-ID: <1161131955.101851832.1595756351885.JavaMail.zimbra@telenet.be>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Hi,

To continue the work that was done in the past (see http://squeakvm.org)
on a Solaris (UNIX) version of Squeak, there's now a SourceForge (SF) project:

    https://sourceforge.net/projects/solaris-squeak/

The older versions of squeakvm.org were for older versions of Solaris
(for both SPARC and Intel).

The new site is currently for Solaris 11.3 and Solaris 11.4 Intel only
(no SPARC yet, for the moment).

Specifically there are some notes on installing Squeak on Solaris 11:

    https://sourceforge.net/p/solaris-squeak/wiki/Home/

Also there is a package "squeak-4" which can run Squeak V4 images.

The squeak-4 package was compiled from squeakvm.org sources (subversion).

And a package "squeak-5" (Stack Spur and Cog Spur) :

5.0-202007210625  Sun Jul 26 08:22:09 CEST 2020 cc [Production Spur 64-bit VM]
StackInterpreter VMMaker.oscog-eem.2778 uuid: b747c434-29c0-4abf-9e8b-3787a02c06ea Jul 26 2020

This is a (very recent) VM which includes again (the old) DES,MD5,SHA2 plugins,
that VM was compiled from the recent Cog opensmalltalk sources as of July 26.

In case anyone is using Squeak on Solaris, feel free to visit this SF project.

Regards,
David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJfHU8uAAoJEAwpOKXMq1MazCAH/3ae7QoIANYk0TWUMhZDZZag
S1hngP3coPQExsmDDWFOWHp7N1TbCF0ZohZslZW30Ycn3JaVfoxbcIXuGUrQe2mK
BaB1ik85h8z2/WSKTIcjtiftND5qv4UO1TLoynI8B9m/jqo7L5Pm52BTgwtlHPjS
dIpzNj/uTGKVaXlu2x0Xa3tHtbIJ5frL6n9EqDU5nVAUyFQGbEC0JaJi8nQOoTS1
H5qRGNcJA5OGTti4KnT29DmScV4QJIPYq2wEf8iWficqObB7rnx2OvPfiChPsh2W
4uaPNGYF5d2zRXpqkZzne3VHTGtjn9mlbGFLR+Q1XfQOESLQ64sxsVCmvLhrl5k=
=HwYy
-----END PGP SIGNATURE-----

From stes at telenet.be  Sun Jul 26 10:12:42 2020
From: stes at telenet.be (stes@PANDORA.BE)
Date: Sun, 26 Jul 2020 12:12:42 +0200 (CEST)
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
 5.2 and 5.3 on files.squeak.org?
Message-ID: <1128010759.101982105.1595758362549.JavaMail.zimbra@telenet.be>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


I'm not sure I understand what exactly are "unofficial V3 versions".

By the way, the ckformat.c C program which can be used to identify the
version of an image, could have a useful --help or --list option.

To list all of the image versions it knows about.

I think the Squeak class ImageFormat, which is used to create ckformat.c

via:

ImageFormat createCkFormatProgram

has a method to list all of the  known image formats.

So the ckformat.c program could also have a switch to list those formats;
or ckformat --help could show the known versions.

Regards,
David Stes


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJfHVbOAAoJEAwpOKXMq1Mam6YH/0tlF6iMkQnuUkW8N++KWzJL
lhMJ3I2YnrCijsCJkMfa8D+1JgYh5YB3ITYHuJgY02413rm2nsXxxvzmqp479ua2
o2ZAq/vTyl3mNPOalzHzt4sI6PMmtz5zXjZFKsVZg8hnyPDz+BVBnEFUa+e8tUUh
wLrnHfNzarwcz4vt8B6hU8Gz3H8SYNXJxobKAxLJ+3DvvNHX0SHgVbR71IzDnI0A
x+pbcfV4/dPCbpidvsar1ZdPj/iT+0KTp1StSKdzInahCsQT43rIf5lyujO52GsM
GfKCEHhhEjylYfris1jlKPoySnnwlG3Js504fiThHFUEVkEuPo9tnPHeSyVwlWA=
=ATkr
-----END PGP SIGNATURE-----

From stes at telenet.be  Sun Jul 26 17:27:23 2020
From: stes at telenet.be (stes@PANDORA.BE)
Date: Sun, 26 Jul 2020 19:27:23 +0200 (CEST)
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
 5.2 and 5.3 on files.squeak.org?
In-Reply-To: <1128010759.101982105.1595758362549.JavaMail.zimbra@telenet.be>
References: <1128010759.101982105.1595758362549.JavaMail.zimbra@telenet.be>
Message-ID: <856498418.103028629.1595784443509.JavaMail.zimbra@telenet.be>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Sorry for asking, but from your posting it is not so clear (to me at least),
what V3 format is.

I wonder whether this has anything to do with for example the 68000 format:

bash-4.4$ ckformat sq64-20101106-dtl.image
68000

There was a 68000 format for 64-bit Squeak V4 images, if I understand rightly.

It would be nice if the "ckformat" C program would print the same info as:

ImageFormat versionDescriptions

a Dictionary(6502->'a 32-bit image with no closure support and no native platform float word order requirement (6502)' 6504->'a 32-bit image with closure support and no native platform float word order requirement (6504)' 6505->'a 32-bit image with closure support and float words stored in native platform order (6505)' 6521->'a 32-bit image with closure support and float words stored in native platform order using Spur object format (6521)' 68000->'a 64-bit image with no closure support and no native platform float word order requirement (68000)' 68002->'a 64-bit image with closure support and no native platform float word order requirement (68002)' 68003->'a 64-bit image with closure support and float words stored in native platform order (68003)' 68019->'a 64-bit image with closure support and float words stored in native platform order using Spur object format (68019)' )

First of all in the above there is no mention of "V3 images".

It just states images with or without closure support/float etc. 

The terminology "V3 images" is not used in the ImageFormat class.

But next, based on the Dictionary, the ckformat.c program could print

bach-4.4$ ckformat
6502	a 32-bit image with no closure support and no native platform float word order requirement (6502)
6504	a 32-bit image with closure support and no native platform float word order requirement (6504)
6505	a 32-bit image with closure support and float words stored in native platform order (6505)
6521	a 32-bit image with closure support and float words stored in native platform order using Spur object format (6521)
68000	a 64-bit image with no closure support and no native platform float word order requirement (68000)
68002	a 64-bit image with closure support and no native platform float word order requirement (68002)
68003	a 64-bit image with closure support and float words stored in native platform order (68003)
68019	a 64-bit image with closure support and float words stored in native platform order using Spur object format (68019)

and so on (for example if ckformat is used with --list or without argument).

Like this you have on the UNIX command line with ckformat the same info
as 'ImageFormat versionDescriptions' provides.

David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJfHbykAAoJEAwpOKXMq1MaxMcH/A7xFzmfwMCNIpFIrZ9O+DFk
+yQ8/Q6SD6WAm9Wk8IGubRWgsN+4fFunHFf4fkxAfcOQco+7vy3Tkqfr9uFVx1Hs
75xZCM5hah1k0xEpUIqQYNXrLMQ1xROT3fbK5JDC7gw+QVYd8ceOmiAygE+ZLnlT
sYfj+coo9dpGZ3Q1tVNFhuVnkl+5yJZ6HGZ6R7LBnUBW3j4tOtFre9QSEUw+kT56
VLvonx1fUOjZPjee8MxqWTtaFf/Dfheajtc8YvfEdBcew8HM029GbBCTNDC/IkJz
5PLCbCMweYXbBY4X/gSoGhyQatf0kxGrHSJCIGbMce1ztAYhGuRyd57Y1D6Br88=
=8ET1
-----END PGP SIGNATURE-----

From lewis at mail.msen.com  Sun Jul 26 18:40:03 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Sun, 26 Jul 2020 14:40:03 -0400
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
	5.2 and 5.3 on files.squeak.org?
In-Reply-To: <856498418.103028629.1595784443509.JavaMail.zimbra@telenet.be>
References: <1128010759.101982105.1595758362549.JavaMail.zimbra@telenet.be>
 <856498418.103028629.1595784443509.JavaMail.zimbra@telenet.be>
Message-ID: <20200726184003.GA67750@shell.msen.com>

Hi David,

On Sun, Jul 26, 2020 at 07:27:23PM +0200, stes at PANDORA.BE wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 
> Sorry for asking, but from your posting it is not so clear (to me at least),
> what V3 format is.

Good question, and to be honest I actually don't know where the term "V3"
originates, but within VMMaker it refers to the traditional object memory
format prior to the introduction of Spur.


> 
> I wonder whether this has anything to do with for example the 68000 format:
> 
> bash-4.4$ ckformat sq64-20101106-dtl.image
> 68000
> 
> There was a 68000 format for 64-bit Squeak V4 images, if I understand rightly.
> 

There is a very good (brief) description of the object memory format in
class ObjectMemory, written by Dan Ingalls. It describes the original
32-bit object memory, as well as the simple 64-bit extension of that format
that Dan did with Ian Piumarta. This was (I believe) intended as TSTTCPW
to prove out the viability of 64-bit images. Later work by Eliot Miranda
gave us the 64-bit (and 32-bit) Spur object memory that is used for
Squeak images today.

The original object memory (both 32-bit and 64-bit) was designed at a
time when 64-bit computers and cell phones were in the distant future.
Spur is a newer design that takes better advantage of today's 64-bit
machines, and that also eliminates some design limitations going back
to those earlier days. For example, Spur uses a common object header
design for 32- and 64-bit images, and it permits more kinds of objects
(characters, floating point objects) to be efficiently represented 
internally as immediate objects.

Note, there is no such thing as a "V4 image", we had some releases of
Squeak in the "version 4.x" range. But it is just an accident of naming
conventions that the last of the "V3" image formats ended with the
Squeak 4.6 release. Squeak 5.x is based on Spur, and Squeak 4.6 and
earlier used the V3 image format.


> It would be nice if the "ckformat" C program would print the same info as:
> 
> ImageFormat versionDescriptions
> 
> a Dictionary(6502->'a 32-bit image with no closure support and no native platform float word order requirement (6502)' 6504->'a 32-bit image with closure support and no native platform float word order requirement (6504)' 6505->'a 32-bit image with closure support and float words stored in native platform order (6505)' 6521->'a 32-bit image with closure support and float words stored in native platform order using Spur object format (6521)' 68000->'a 64-bit image with no closure support and no native platform float word order requirement (68000)' 68002->'a 64-bit image with closure support and no native platform float word order requirement (68002)' 68003->'a 64-bit image with closure support and float words stored in native platform order (68003)' 68019->'a 64-bit image with closure support and float words stored in native platform order using Spur object format (68019)' )
> 
> First of all in the above there is no mention of "V3 images".
> 
> It just states images with or without closure support/float etc. 
> 
> The terminology "V3 images" is not used in the ImageFormat class.
> 
> But next, based on the Dictionary, the ckformat.c program could print
> 
> bach-4.4$ ckformat
> 6502	a 32-bit image with no closure support and no native platform float word order requirement (6502)
> 6504	a 32-bit image with closure support and no native platform float word order requirement (6504)
> 6505	a 32-bit image with closure support and float words stored in native platform order (6505)
> 6521	a 32-bit image with closure support and float words stored in native platform order using Spur object format (6521)
> 68000	a 64-bit image with no closure support and no native platform float word order requirement (68000)
> 68002	a 64-bit image with closure support and no native platform float word order requirement (68002)
> 68003	a 64-bit image with closure support and float words stored in native platform order (68003)
> 68019	a 64-bit image with closure support and float words stored in native platform order using Spur object format (68019)
> 
> and so on (for example if ckformat is used with --list or without argument).
> 
> Like this you have on the UNIX command line with ckformat the same info
> as 'ImageFormat versionDescriptions' provides.


That is a very good idea. I just updated ImageFormat-dtl.42 with your suggestion.
When called with no argument, the ckformat program now does this:

$ ./ckformat
usage: ckformat imageFileName
answer the image format number for an image file or 0 if not known
known image formats:
6502: a 32-bit V3 image with no closure support and no native platform float word order requirement
6504: a 32-bit V3 image with closure support and no native platform float word order requirement
6505: a 32-bit V3 image with closure support and float words stored in native platform order
6521: a 32-bit Spur image with closure support and float words stored in native platform order using Spur object format
7033: a 32-bit Spur image with closure support and float words stored in native platform order using Spur object format and multiple bytecode sets 
68000: a 64-bit V3 image with no closure support and no native platform float word order requirement
68002: a 64-bit V3 image with closure support and no native platform float word order requirement
68003: a 64-bit V3 image with closure support and float words stored in native platform order
68004: a 64-bit V3 image with closure support and no native platform float word order requirement
68019: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format (obsolete)
68021: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format
68533: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format and multiple bytecode sets 

I did not attempt to add argument parsing (--list) but I hope that adding
this to the zero-argument message will be good enough. It's certainly a nice
and easy enhancement :-)

Thanks,
Dave


From jecel at merlintec.com  Sun Jul 26 18:58:01 2020
From: jecel at merlintec.com (Jecel Assumpcao Jr)
Date: Sun, 26 Jul 2020 15:58:01 -0300 
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
	5.2 and 5.3 on files.squeak.org?
In-Reply-To: <20200726184003.GA67750@shell.msen.com>
References: <1128010759.101982105.1595758362549.JavaMail.zimbra@telenet.be>
 <856498418.103028629.1595784443509.JavaMail.zimbra@telenet.be>
 <20200726184003.GA67750@shell.msen.com>
Message-ID: <20200726185805.E5EED8C0531@proxy.email-ssl.com.br>

David T. Lewis wrote on Sun, 26 Jul 2020 14:40:03 -0400
> On Sun, Jul 26, 2020 at 07:27:23PM +0200, stes wrote:
> > Sorry for asking, but from your posting it is not so clear (to me at least),
> > what V3 format is.
> 
> Good question, and to be honest I actually don't know where the term "V3"
> originates, but within VMMaker it refers to the traditional object memory
> format prior to the introduction of Spur.

The term was created in 2002 to contrast with Anthony Hannon's VI4
Squeak with its new image format and new bytecodes. This did not get
adopted by our community and it became confusing when the official
Squeak 4.0 and later continued using the V3 image format until Spur was
finally adopted.

https://wiki.squeak.org/squeak/2119

-- Jecel

From lewis at mail.msen.com  Sun Jul 26 19:02:01 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Sun, 26 Jul 2020 15:02:01 -0400
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
	5.2 and 5.3 on files.squeak.org?
In-Reply-To: <CAC20JE0vbEN4ShVu2jTuJ3L7Z6G1+0KBuCc64esjLRUQfUyVJQ@mail.gmail.com>
References: <20200725170451.GA11257@shell.msen.com>
 <CAC20JE0vbEN4ShVu2jTuJ3L7Z6G1+0KBuCc64esjLRUQfUyVJQ@mail.gmail.com>
Message-ID: <20200726190201.GB67750@shell.msen.com>

Hi Eliot,

On Sat, Jul 25, 2020 at 08:33:38PM -0700, Eliot Miranda wrote:
> Hi David,
> 
> On Sat, Jul 25, 2020 at 10:04 AM David T. Lewis <lewis at mail.msen.com> wrote:
> 
> > A couple of years ago, I put a copy of a Squeak 5.2 image in V3 object
> > memory format on the squeakvm.org server, and I linked to it from the
> > project page at http://www.squeaksource.com/TrunkUpdateStreamV3. That link
> > has gone dead, and I think I recall someone noticing it a recently.
> >
> > I still have the files, should I put them somewhere on files.squeak.org?
> > I was thinking of putting them under the "various_images" folder:
> >
> >         files.squeak.org/various_images/squeak_V3_images/
> >
> > I also have a V3 image that is up to date with the Squeak 5.3 release,
> > so I could put that on line as well.
> >
> > These images will run under an up-to-date interpreter VM or a Cog VM. They
> > may be of interest to people doing VM work, benchmarking, or as a reference
> > to understand the image-side differences between Spur and V3.
> >
> 
> This is definitely useful.  My only concern is if this moves trunk towards
> having code that supports both v3 and Spur.  I don't want the complexity or
> the unnecessary overhead that entails.  So can we please keep a series of
> patches to keep 5.x/6.x v3 going and not change trunk to accomodate?
> 

Not to worry, there are no changes to trunk. The project page for
http://www.squeaksource.com/TrunkUpdateStreamV3.html explains what
I have been doing.

In general, I have been able to keep MCM file numbers in sync between
trunk and the packages in TrunkUpdateStreamV3. So for example if you
have a Squeak 5.2 image with Compiler-eem.394 then you can look at
Compiler.V3-dtl.393 in the TrunkUpdateStreamV3 repository to see the
differences. Please don't expect this to be perfect, it definitely
is not.

I should note that Juan has been maintaining Cuis for Spur64, Spur32,
and V3 from a common code base. So if someone is interested in how
much complexity is added by supporting this, then Cuis is the best
reference.

Dave


From lewis at mail.msen.com  Sun Jul 26 19:30:29 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Sun, 26 Jul 2020 15:30:29 -0400
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
	5.2 and 5.3 on files.squeak.org?
In-Reply-To: <20200726185805.E5EED8C0531@proxy.email-ssl.com.br>
References: <1128010759.101982105.1595758362549.JavaMail.zimbra@telenet.be>
 <856498418.103028629.1595784443509.JavaMail.zimbra@telenet.be>
 <20200726184003.GA67750@shell.msen.com>
 <20200726185805.E5EED8C0531@proxy.email-ssl.com.br>
Message-ID: <20200726193029.GA80402@shell.msen.com>

Hello Jecel,

On Sun, Jul 26, 2020 at 03:58:01PM -0300, Jecel Assumpcao Jr wrote:
> David T. Lewis wrote on Sun, 26 Jul 2020 14:40:03 -0400
> > On Sun, Jul 26, 2020 at 07:27:23PM +0200, stes wrote:
> > > Sorry for asking, but from your posting it is not so clear (to me at least),
> > > what V3 format is.
> > 
> > Good question, and to be honest I actually don't know where the term "V3"
> > originates, but within VMMaker it refers to the traditional object memory
> > format prior to the introduction of Spur.
> 
> The term was created in 2002 to contrast with Anthony Hannon's VI4
> Squeak with its new image format and new bytecodes. This did not get
> adopted by our community and it became confusing when the official
> Squeak 4.0 and later continued using the V3 image format until Spur was
> finally adopted.
> 
> https://wiki.squeak.org/squeak/2119
>

Thank you! It make perfect sense now.

Dave
 

From lewis at mail.msen.com  Sun Jul 26 19:37:45 2020
From: lewis at mail.msen.com (David T. Lewis)
Date: Sun, 26 Jul 2020 15:37:45 -0400
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
	5.2 and 5.3 on files.squeak.org?
In-Reply-To: <1128010759.101982105.1595758362549.JavaMail.zimbra@telenet.be>
References: <1128010759.101982105.1595758362549.JavaMail.zimbra@telenet.be>
Message-ID: <20200726193745.GA80806@shell.msen.com>

On Sun, Jul 26, 2020 at 12:12:42PM +0200, stes at PANDORA.BE wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 
> I'm not sure I understand what exactly are "unofficial V3 versions".
> 

By "unofficial" I mean that it is completely unrelated to any officially
announced versions of Squeak that appear on squeak.org and that are expected
to be of high quality and worthy of long term support.

This is just stuff that I have done on my own and that may be of interest
to a few other people, that's all.

Dave


From marcel.taeumel at hpi.de  Mon Jul 27 08:47:07 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Mon, 27 Jul 2020 10:47:07 +0200
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <Mailbird-87eb61d0-30c1-49ad-80bd-4ace0ac173ad@hpi.de>
References: <Mailbird-98a3d41c-0d1f-45ca-911e-8e1eb6f5e1c6@hpi.de>
 <C87BE406-5841-4C6E-B7BC-D9254CD66004@gmail.com>
 <Mailbird-87eb61d0-30c1-49ad-80bd-4ace0ac173ad@hpi.de>
Message-ID: <Mailbird-9111f0d5-1b47-4c3b-b331-bed36255f6f3@hpi.de>

Works: 

Best,
Marcel
Am 23.07.2020 13:41:17 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hmm... AppVeyor is just for the Windows builds. We might want to do a beta release for such crucial fixes and then point to the GitHub releases page?

Best,
Marcel
Am 22.07.2020 19:50:31 schrieb Eliot Miranda <eliot.miranda at gmail.com>:


On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:



Hi Eliot,

looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm".

Should we augment that with a direct pointer to the Appveyor CI server?


Best,
Marcel
Am 22.07.2020 16:41:08 schrieb Eliot Miranda <eliot.miranda at gmail.com>:


On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:



Hi Levente.

> I'm thinking about checking the VM version in the preamble of the package
> and raising a Warning when it clearly lacks the required updates.
> Users can still continute with a Warning or terminate the update process,
> while cli tools will act as if an error had occured.

+1

A one-liner would be nice. The warning should also (roughly) point to the location of the new VM for download.

MCMcmUpdater checkVM: 202003021730. "and newer"

I wrote it like this:

 "Use of the Spur FloatArray>>at:[put:] prims requires at least VMMaker.oscog.2778"

Smalltalk vmVMMakerVersion < 2778 ifTrue:
    [Warning signal: 'This virtual machine is too old to support correct versions of the FloatArray>>at:[put:] primitives 238 and 239.  FloatArray subclasses will not behave correctly and FloatArray[64]Test tests will fail.  Please upgrade your VM.  You may continue and upgrade later or abort and upgrade now.']!

Best,
Marcel
Am 21.07.2020 20:21:39 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
Hi Eliot,

On Mon, 20 Jul 2020, Eliot Miranda wrote:

> Hi All,
>     I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows two methods
> (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods.  The issue is when to publish the corrections to trunk.
> Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests.  However, I do want to push the corrections soon, because they're a
> substantial improvement.  So the question is how long should I wait?
>
> Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM.

I think most people don't update their VMs often. I still tend to fire
up the one shipped with the 5.3 release. So, IMO the question is not how
long to wait but what to do when things are about to break.
I presume that without updating the VM, the image would not work properly.
So, I think the best would be if the user were warned during the update
if the VM would be incompatible with the changes.
I'm thinking about checking the VM version in the preamble of the package
and raising a Warning when it clearly lacks the required updates.
Users can still continute with a Warning or terminate the update process,
while cli tools will act as if an error had occured.


Levente

> _,,,^..^,,,_
> best, Eliot
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200727/1403e680/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 86521 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200727/1403e680/attachment-0001.png>

From marcel.taeumel at hpi.de  Mon Jul 27 09:19:06 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Mon, 27 Jul 2020 11:19:06 +0200
Subject: [squeak-dev] Debugging of other processes with wait
In-Reply-To: <CA+ovNC6dLBdbKtXb2cBefs__6yAcaGH4+oBRQwDVcFB7UTGvEw@mail.gmail.com>
References: <CA+ovNC4LjMC+OCB0eidYYz-zmCfvMX3m9wZ7RAh3bB6yfpHJ2A@mail.gmail.com>
 <60A16E3F-BDE8-4FA9-85D9-9F5441F5B751@gmail.com>
 <CA+ovNC6dLBdbKtXb2cBefs__6yAcaGH4+oBRQwDVcFB7UTGvEw@mail.gmail.com>
Message-ID: <Mailbird-96888028-3e6d-4376-b2e8-eb356348aee6@hpi.de>

Hi all --

There is no explicit support for (coherent) multi-process debugging in Squeak's debugging and code simulation infrastructure (Debugger, Process, Context) yet.

As a first step, we could clarify the meaning of stepping into or over a "semaphore wait" in any process. At the moment, the debugger (i.e. the current UI process) blocks. Well, even if the debugged process would block instead -- and not the current UI process -- how should the debugger react? Inform the user? Disable all stepping buttons? Add an extra watchdog to notify the debugger when the debugged process becomes responsive and hence "simulate-able" again?

One challenging thing is that we cannot simulate the *entire* code execution in Squeak; and we don't have a clear agreement on how to deal with primitive calls during code simulation. Could we always use the fallback code? Hmmm....

Best,
Marcel
Am 23.07.2020 18:57:36 schrieb Jakob Reschke <forums.jakob at resfarm.de>:
Hi Eliot,

Am Do., 23. Juli 2020 um 16:37 Uhr schrieb Eliot Miranda
:
>
> > On Jul 23, 2020, at 5:50 AM, Jakob Reschke wrote:
> >
> > Hello,
> >
> > Yesterday I needed to debug a process that is not the UI process. At
> > one point this background process waits on a Promise (so it will wait
> > on a Semaphore) that is supposed to be resolved in the UI process, so
> > the background process will block. If this point is reached while
> > stepping in the debugger, the UI process will block instead, since it
> > evaluates the debugger stepping on behalf of the background process.
>
> Can you describe the control flow when this occurs normally, outside the debugger? I need to understand which processes execute waits.
>

There is a "background" process that implements a certain workflow.
There are one or more occasions during this workflow where user input
is required. To move away from modal dialogs, nesting the world loop,
and from writing all the business logic in a promise-style control
flow, I want this background process to suspend until the user has
provided the input (which happens in the UI process of course).

So:
1. The background process triggers a request in the UI process via
addDeferredUIMessage: or similar. Mind that this is not a modal
invocation, so it will return immediately.
2. The background process waits for the input. In this particular case
using Promise>>wait, which uses a Semaphore internally.
3. When the user is finished filling in the data, clicking the OK or
Cancel buttons (which happens in the UI process) must somehow signal
the background process to continue. In my current case, this happens
by fulfilling the Promise on which the background process waits. This
will signal the internal Promise Semaphore from the UI process.
4. The background process receives the signal on the Semaphore. It
resumes to get the user's input from the Promise and continues the
workflow.

Instead of a Promise, other mechanisms could be used as well:
- Use a Semaphore directly without Promise.
- Let the background process read from a shared queue.
- Let the background process suspend itself and be resumed from the UI
callback explicitly.


> > What I did for now is to add an accessor on ProcessScheduler that
> > answers the activeProcess without sending #effectiveProcess, and check
> > in Promise>>wait whether this real active process is the UI process.
> > If it is, halt the debugged process before the Semaphore wait
> > primitive, and I proceed manually as soon as I am confident that the
> > promise is already resolved or rejected, so the wait will return
> > immediately.
>
> An alternative might be to have the debugger spawn a new UI process whenever it detects that the UI process is blocked. This may have to be done by a background helper process that the debugger spawns or allows to run whenever the debugger steps, because of course the ui process is executing the step.
>
> Without thinking things through, another alternative might be to have the debugger always use its own process. The underlying issue is that if the ui process blocks in reality then it should block in the debugger, but we’d like to keep the debugger alive and we’d like to keep the ui alive.
>
> So I suppose we could introduce a background process whose job it is to observe the ui process and if it detects the ui process is blocked for some time (1 second?) spawns a new ui process had reports (in the Transcript?, a pop-up in the new ui process?) that the ui process blocked.
>

This sounds good at first and for my particular case. But in general
this might break some things even outside of a debugging session:
modal dialogs are allergic to switching the UI process (I guess
everyone has seen Monticello's "This modal dialog was interrupted,
please close it" message at some point). The other thing I can imagine
is that after blocking a few seconds the no-longer-UI process might do
something that needs to be done in the UI process, but won't use
addDeferredUIMessage: because the code was designed to run in the UI
process in the first place.

If we can get around this, an always responsive UI would be great of course.

> >
> > wait
> > "Wait unconditionally for this promise to become fulfilled or rejected."
> > | sema |
> > (state = #pending and: [Processor realProcess == Project
> > uiProcess]) ifTrue: [self halt].
> > sema := Semaphore new.
> > ...
> >
> > But of course this is just a workaround. Is there a chance to extend
> > the Squeak debugger to deal with critical sections and waits?
>
> I don’t see how. The debugger can spot a critical section entry or a wait if one is doing “send”, because then the debugger actually executes the primitive in Context>>#tryPrimitive:..., (IIRC, I’m on my phone). But if the debugger steps then the critical section entry or wait will be executed by running code (the debugger runs step at full speed by using perform: and the code executed by the perform, while surrounded by an exception handler and an unwind-protect, is not virtualised in any way and so we have no easy way of intercepting critical section entry or waits).
>

We could add an AboutToWait notification around the code that calls
the primitive... but it would slow down processes that don't need it.
And if you add another blocking mechanism and forget to signal the
notification, the debugger will block again.

> > In
> > Eclipse for example, there is a list of threads; blocked/waiting
> > threads are annotated with an icon, as well as the top frame that
> > waits for something; you can debug other threads in the meantime. But
> > in Java the debugger is in another VM than the debugged process, so
> > the situation that the debugger steps in the UI process needs not be
> > resolved there in the first place.
> >
> > Maybe if we know all the points/primitives where processes can be
> > blocked, we could make the stepping detect these, run them in another
> > process, make the debugger observe that process and show some info
> > about the waiting in a special top context in the meantime. Once the
> > other process is unblocked (or terminated if it does nothing else than
> > the wait), the debugger would continue to step the background process.
> > Could this work?
> >
> > Or is there already another facility that works and which I should use?
>
> As I say, I think a way that can work is detecting that the ui process has blocked and spawning a new ui process when that happens. But when in the debugger we want to avoid the debugger blocking in step/send and hence only executing any actions before step/send and not those after step/send (eg removing exception handler and unwind-protect from the stack). So architecturally, not having the debugger use the ui process and to use its own process seems like a good idea but a major change.
>

Agreed.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200727/7173cf24/attachment.html>

From stes at telenet.be  Mon Jul 27 11:50:42 2020
From: stes at telenet.be (stes@PANDORA.BE)
Date: Mon, 27 Jul 2020 13:50:42 +0200 (CEST)
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
 5.2 and 5.3 on files.squeak.org?
In-Reply-To: <856498418.103028629.1595784443509.JavaMail.zimbra@telenet.be>
References: <1128010759.101982105.1595758362549.JavaMail.zimbra@telenet.be>
 <856498418.103028629.1595784443509.JavaMail.zimbra@telenet.be>
Message-ID: <868688880.105677170.1595850642282.JavaMail.zimbra@telenet.be>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Wow, that was fast ...

It didn't take you a lot of time to implement that feature ...

Following the instructions https://wiki.squeak.org/squeak/6177,
(to update/load ImageFormat from the Monticello VMMaker repository)
I recreated the ckformat.c program with : ImageFormat createCkFormatProgram

It seems you now use the term "V3" image and "Spur" image:

bash-4.4$ ./ckformat squeak6.image 
68021

bash-4.4$ ./ckformat 
6502: a 32-bit V3 image with no closure support and no native platform float word order requirement
...
68533: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format and multiple bytecode sets 

Thanks, this is a useful list ...

David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJfHr9RAAoJEAwpOKXMq1Ma1joIAIEwyQV4zNT+vr3AurKhsBwD
YmvV8NDk+Mijgf7GAQBrdk7J6qU0MenwEACvFN3cXTaBD4uaEoVrjpsl80XeeigA
fvOUkSzwLMq9c4tAZ0F8ReNmW1Bq6xKyOmEpz0C2C+Gim3abzgjv+BoPXgX6rO8E
J88WtQHiPVH2BSMiJq1rZyP9QRMaOjp2za3nc7UnT0nLJVlSpYcyvhioSxgTRejM
o/YXHqjRy+CAsYM62CyfuCgFfaG7VHqhjlUtYv4sM2cVB46LXdg23K335kmQytno
65njsthZ3qmLzylu+lrDbD+qw6IeF7L+Ok5QWY4DiskMiZJkxQ9hW8NWbNP9EtA=
=QYe0
-----END PGP SIGNATURE-----

From leves at caesar.elte.hu  Mon Jul 27 19:18:32 2020
From: leves at caesar.elte.hu (Levente Uzonyi)
Date: Mon, 27 Jul 2020 21:18:32 +0200 (CEST)
Subject: [squeak-dev] The Trunk: CollectionsTests-ul.341.mcz
In-Reply-To: <E1jzXak-00042c-0N@andreas>
References: <E1jzXak-00042c-0N@andreas>
Message-ID: <alpine.DEB.2.02.2007272115060.4318@login03.caesar.elte.hu>

Hi Eliot,

On Sun, 26 Jul 2020, commits at source.squeak.org wrote:

> Eliot Miranda uploaded a new version of CollectionsTests to project The Trunk:
> http://source.squeak.org/trunk/CollectionsTests-ul.341.mcz
>
> ==================== Summary ====================
>
> Name: CollectionsTests-ul.341
> Author: eem
> Time: 25 July 2020, 8:44:46.338509 pm
> UUID: 1b22fd11-c092-46ba-bd26-526080294ab8
> Ancestors: CollectionsTests-ul.340
>
> Fix an old spelling error.
> Using Levente's initials for the package version and the change stamp because this is his code.  I only noticed and fixed the speeling error.  No other changes. eem 7/25/2020.  I beg forgiveness if this is in any way offensive.

I think it's perfectly fine in this case since we don't have a way to 
rename a method (or anything else) and keep the history.
Thanks for fixing it.

Levente

>
> =============== Diff against CollectionsTests-ul.340 ===============
>
> Item was added:
> + ----- Method: ByteArrayTest>>testPlatformIndependentIntegerAccessorsAtBitBorders (in category 'tests - platform independent access') -----
> + testPlatformIndependentIntegerAccessorsAtBitBorders
> + 
> + 	#(
> + 		shortAt:put:bigEndian: shortAt:bigEndian: false 16
> + 		longAt:put:bigEndian: longAt:bigEndian: false 32
> + 		long64At:put:bigEndian: long64At:bigEndian: false 64
> + 		unsignedShortAt:put:bigEndian: unsignedShortAt:bigEndian: true 16
> + 		unsignedLongAt:put:bigEndian: unsignedLongAt:bigEndian: true 32
> + 		unsignedLong64At:put:bigEndian: unsignedLong64At:bigEndian: true 64 
> + 	) groupsDo: [ :setter :getter :unsigned :storageBits |
> + 		self
> + 			verifyPlatformIndependentIntegerAccessorsAtBitBordersSetter: setter
> + 			getter: getter
> + 			unsigned: unsigned
> + 			storageBits: storageBits ]!
>
> Item was added:
> + ----- Method: ByteArrayTest>>testPlatformIndependentIntegerAccessorsWithRandomValues (in category 'tests - platform independent access') -----
> + testPlatformIndependentIntegerAccessorsWithRandomValues
> + 
> + 	| random |
> + 	random := Random seed: 36rSqueak.
> + 	#(
> + 		shortAt:put:bigEndian: shortAt:bigEndian: false 16
> + 		longAt:put:bigEndian: longAt:bigEndian: false 32
> + 		long64At:put:bigEndian: long64At:bigEndian: false 64
> + 		unsignedShortAt:put:bigEndian: unsignedShortAt:bigEndian: true 16
> + 		unsignedLongAt:put:bigEndian: unsignedLongAt:bigEndian: true 32
> + 		unsignedLong64At:put:bigEndian: unsignedLong64At:bigEndian: true 64 
> + 	) groupsDo: [ :setter :getter :unsigned :storageBits |
> + 		self
> + 			verifyPlatformIndependentIntegerAccessorsWithRandomValuesSetter: setter
> + 			getter: getter
> + 			unsigned: unsigned
> + 			storageBits: storageBits
> + 			random: random ]!
>
> Item was removed:
> - ----- Method: ByteArrayTest>>testPlatformIndepentendIntegerAccessorsAtBitBorders (in category 'tests - platform independent access') -----
> - testPlatformIndepentendIntegerAccessorsAtBitBorders
> - 
> - 	#(
> - 		shortAt:put:bigEndian: shortAt:bigEndian: false 16
> - 		longAt:put:bigEndian: longAt:bigEndian: false 32
> - 		long64At:put:bigEndian: long64At:bigEndian: false 64
> - 		unsignedShortAt:put:bigEndian: unsignedShortAt:bigEndian: true 16
> - 		unsignedLongAt:put:bigEndian: unsignedLongAt:bigEndian: true 32
> - 		unsignedLong64At:put:bigEndian: unsignedLong64At:bigEndian: true 64 
> - 	) groupsDo: [ :setter :getter :unsigned :storageBits |
> - 		self
> - 			verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter: setter
> - 			getter: getter
> - 			unsigned: unsigned
> - 			storageBits: storageBits ]!
>
> Item was removed:
> - ----- Method: ByteArrayTest>>testPlatformIndepentendIntegerAccessorsWithRandomValues (in category 'tests - platform independent access') -----
> - testPlatformIndepentendIntegerAccessorsWithRandomValues
> - 
> - 	| random |
> - 	random := Random seed: 36rSqueak.
> - 	#(
> - 		shortAt:put:bigEndian: shortAt:bigEndian: false 16
> - 		longAt:put:bigEndian: longAt:bigEndian: false 32
> - 		long64At:put:bigEndian: long64At:bigEndian: false 64
> - 		unsignedShortAt:put:bigEndian: unsignedShortAt:bigEndian: true 16
> - 		unsignedLongAt:put:bigEndian: unsignedLongAt:bigEndian: true 32
> - 		unsignedLong64At:put:bigEndian: unsignedLong64At:bigEndian: true 64 
> - 	) groupsDo: [ :setter :getter :unsigned :storageBits |
> - 		self
> - 			verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter: setter
> - 			getter: getter
> - 			unsigned: unsigned
> - 			storageBits: storageBits
> - 			random: random ]!
>
> Item was added:
> + ----- Method: ByteArrayTest>>verifyPlatformIndependentIntegerAccessorsAtBitBordersSetter:getter:unsigned:storageBits: (in category 'tests - platform independent access') -----
> + verifyPlatformIndependentIntegerAccessorsAtBitBordersSetter: setter getter: getter unsigned: unsigned storageBits: storageBits
> + 
> + 	| byteArray minValue maxValue baseValues |
> + 	byteArray := ByteArray new: storageBits // 8 * 2.
> + 	unsigned
> + 		ifTrue: [
> + 			minValue := 0.
> + 			maxValue := 1 << storageBits - 1.
> + 			baseValues := #(0 1) ]
> + 		ifFalse: [
> + 			minValue := -1 << (storageBits - 1).
> + 			maxValue := 1 << (storageBits - 1) - 1.
> + 			baseValues := #(-1 0 1) ].
> + 	#(true false) do: [ :bigEndian |
> + 		0 to: storageBits - 1 do: [ :bits |
> + 			baseValues do: [ :baseValue |
> + 				| centerValue |
> + 				centerValue := baseValue << bits.
> + 				centerValue - 1 to: centerValue + 1 do: [ :value |
> + 					(value between: minValue and: maxValue) ifTrue: [
> + 						self
> + 							verifyPlatformIndependentIntegerAccessorsMatch: byteArray
> + 							for: value
> + 							setter: setter
> + 							getter: getter
> + 							storageBits: storageBits
> + 							bigEndian: bigEndian  ] ] ] ] ]
> + 					!
>
> Item was added:
> + ----- Method: ByteArrayTest>>verifyPlatformIndependentIntegerAccessorsMatch:for:setter:getter:storageBits:bigEndian: (in category 'tests - platform independent access') -----
> + verifyPlatformIndependentIntegerAccessorsMatch: byteArray for: value setter: setter getter: getter storageBits: storageBits bigEndian: bigEndian
> + 
> + 	| expectedSetterResult getterResult bytes |
> + 	expectedSetterResult := self byteArrayFor: value bits: storageBits bigEndian: bigEndian.
> + 	bytes := storageBits // 8.
> + 	1 to: byteArray size - bytes + 1 do: [ :index |
> + 		byteArray
> + 			perform: setter
> + 			with: index
> + 			with: value
> + 			with: bigEndian.
> + 		1 to: bytes do: [ :byteIndex |
> + 			self
> + 				assert: (expectedSetterResult at: byteIndex)
> + 				equals: (byteArray at: index + byteIndex - 1) ].
> + 		getterResult := byteArray
> + 			perform: getter
> + 			with: index
> + 			with: bigEndian.
> + 		self assert: value equals: getterResult ]!
>
> Item was added:
> + ----- Method: ByteArrayTest>>verifyPlatformIndependentIntegerAccessorsWithRandomValuesSetter:getter:unsigned:storageBits:random: (in category 'tests - platform independent access') -----
> + verifyPlatformIndependentIntegerAccessorsWithRandomValuesSetter: setter getter: getter unsigned: unsigned storageBits: storageBits random: random
> + 
> + 	| byteArray randomMax randomOffset |
> + 	byteArray := ByteArray new: storageBits // 8 * 2.
> + 	randomMax := 1 << storageBits.
> + 	randomOffset := unsigned
> + 		ifTrue: [ -1 ]
> + 		ifFalse: [ -1 << (storageBits - 1) - 1 ].
> + 	10000 timesRepeat: [
> + 		| value |
> + 		value := (random nextInt: randomMax) + randomOffset.
> + 		#(true false) do: [ :bigEndian |
> + 			self
> + 				verifyPlatformIndependentIntegerAccessorsMatch: byteArray
> + 				for: value
> + 				setter: setter
> + 				getter: getter
> + 				storageBits: storageBits
> + 				bigEndian: bigEndian ] ]!
>
> Item was removed:
> - ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter:getter:unsigned:storageBits: (in category 'tests - platform independent access') -----
> - verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter: setter getter: getter unsigned: unsigned storageBits: storageBits
> - 
> - 	| byteArray minValue maxValue baseValues |
> - 	byteArray := ByteArray new: storageBits // 8 * 2.
> - 	unsigned
> - 		ifTrue: [
> - 			minValue := 0.
> - 			maxValue := 1 << storageBits - 1.
> - 			baseValues := #(0 1) ]
> - 		ifFalse: [
> - 			minValue := -1 << (storageBits - 1).
> - 			maxValue := 1 << (storageBits - 1) - 1.
> - 			baseValues := #(-1 0 1) ].
> - 	#(true false) do: [ :bigEndian |
> - 		0 to: storageBits - 1 do: [ :bits |
> - 			baseValues do: [ :baseValue |
> - 				| centerValue |
> - 				centerValue := baseValue << bits.
> - 				centerValue - 1 to: centerValue + 1 do: [ :value |
> - 					(value between: minValue and: maxValue) ifTrue: [
> - 						self
> - 							verifyPlatformIndepentendIntegerAccessorsMatch: byteArray
> - 							for: value
> - 							setter: setter
> - 							getter: getter
> - 							storageBits: storageBits
> - 							bigEndian: bigEndian  ] ] ] ] ]
> - 					!
>
> Item was removed:
> - ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsMatch:for:setter:getter:storageBits:bigEndian: (in category 'tests - platform independent access') -----
> - verifyPlatformIndepentendIntegerAccessorsMatch: byteArray for: value setter: setter getter: getter storageBits: storageBits bigEndian: bigEndian
> - 
> - 	| expectedSetterResult getterResult bytes |
> - 	expectedSetterResult := self byteArrayFor: value bits: storageBits bigEndian: bigEndian.
> - 	bytes := storageBits // 8.
> - 	1 to: byteArray size - bytes + 1 do: [ :index |
> - 		byteArray
> - 			perform: setter
> - 			with: index
> - 			with: value
> - 			with: bigEndian.
> - 		1 to: bytes do: [ :byteIndex |
> - 			self
> - 				assert: (expectedSetterResult at: byteIndex)
> - 				equals: (byteArray at: index + byteIndex - 1) ].
> - 		getterResult := byteArray
> - 			perform: getter
> - 			with: index
> - 			with: bigEndian.
> - 		self assert: value equals: getterResult ]!
>
> Item was removed:
> - ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter:getter:unsigned:storageBits:random: (in category 'tests - platform independent access') -----
> - verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter: setter getter: getter unsigned: unsigned storageBits: storageBits random: random
> - 
> - 	| byteArray randomMax randomOffset |
> - 	byteArray := ByteArray new: storageBits // 8 * 2.
> - 	randomMax := 1 << storageBits.
> - 	randomOffset := unsigned
> - 		ifTrue: [ -1 ]
> - 		ifFalse: [ -1 << (storageBits - 1) - 1 ].
> - 	10000 timesRepeat: [
> - 		| value |
> - 		value := (random nextInt: randomMax) + randomOffset.
> - 		#(true false) do: [ :bigEndian |
> - 			self
> - 				verifyPlatformIndepentendIntegerAccessorsMatch: byteArray
> - 				for: value
> - 				setter: setter
> - 				getter: getter
> - 				storageBits: storageBits
> - 				bigEndian: bigEndian ] ]!

From commits at source.squeak.org  Mon Jul 27 19:28:21 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Mon, 27 Jul 2020 19:28:21 0000
Subject: [squeak-dev] The Trunk: SystemReporter-eem.43.mcz
Message-ID: <E1k08nO-0003Lv-Cd@andreas>

Eliot Miranda uploaded a new version of SystemReporter to project The Trunk:
http://source.squeak.org/trunk/SystemReporter-eem.43.mcz

==================== Summary ====================

Name: SystemReporter-eem.43
Author: eem
Time: 27 July 2020, 12:28:19.766033 pm
UUID: 07d625b9-43e4-47c4-9bd2-afc14f912602
Ancestors: SystemReporter-mt.42

Make accurate the label for desired code code size.

=============== Diff against SystemReporter-mt.42 ===============

Item was changed:
  ----- Method: SystemReporter>>reportVMParameters: (in category 'reporting') -----
  reportVMParameters: aStream
  	| vmParameters isStack isCog isSpur |
  	self header: 'Virtual Machine Parameters' on: aStream.
  	vmParameters := Smalltalk vm getVMParameters.
  	isStack := (vmParameters at: 42 ifAbsent: [0]) ~= 0. "42 = number of stack pages available"
  	isCog := isStack and: [(vmParameters at: 46) ~= 0].  "46 is machine code zone size"
  	isSpur := isStack and: [(vmParameters at: 41) anyMask: 2r10000]. "41 is imageFormatVersion for the VM; bit 16 is the Spur bit"
  	(isSpur
  		ifFalse:
  			[#(	1	'size of old space'
  				2	'size of young+old space'
  				3	'size of memory'
  				4	'allocationCount'
  				5	'allocations between GCs'
  				6	'survivor count tenuring threshold')]
  		ifTrue:
  			[#(	1	'size of old space'
  				2	'used bytes in new space (used eden + used past space)'
  				3	'size of heap')]),
  	#(	7	'full GCs since startup'
  		8	'total milliseconds in full GCs since startup'),
  	(isSpur
  		ifFalse: [#(	9	'incremental GCs since startup'
  					10	'total milliseconds in incremental GCs since startup'
  					11	'tenures of surving objects since startup'),
  					{12 to: 19. 'specific to the translating VM'}]
  		ifTrue: [#(	9	'scavenging GCs since startup'
  					10	'total milliseconds in scavenging GCs since startup'
  					11	'tenures of surving objects since startup'),
  					{12 to: 15. 'reserved for future use'},
  				#(	16	'total microseconds in idle since startup'
  					17	'proportion of code zone available for use (Sista VMs only; read-write)'
  					18	'total milliseconds in full GC compaction since startup (a portion of parameter 8)'
  					19	'scavenge threshold; the effective size of eden')]),
  	#(	20  'utc microseconds at startup (if non-zero)'
  		21	'root/remembered table size (occupancy)'
  		22	'root/remembered table overflows since startup'
  		23	'bytes of extra memory to reserve for VM buffers, plugins, etc.'
  		24	'free memory threshold above which object memory will be shrunk'
  		25	'memory headroom when growing object memory'),
  	(isStack
  		ifFalse:
  			[#(	26  'interruptChecksEveryNms - force an ioProcessEvents every N milliseconds, in case the image is not calling getNextEvent often')]
  		ifTrue:
  			[#(	26  'heartbeat period (ms; see #58)')]),
  	(isSpur
  		ifFalse:
  			[#(	27	'number of times mark loop iterated for current IGC/FGC includes ALL marking'
  				28	'number of times sweep loop iterated  for current IGC/FGC'
  				29	'number of times make forward loop iterated for current IGC/FGC'
  				30	'number of times compact move loop iterated for current IGC/FGC')]
  		ifTrue: [#()]),
  	#(	31	'number of grow memory requests'
  		32	'number of shrink memory requests'),
  	(isSpur
  		ifFalse:
  			[#(	33	'number of root table entries used for current IGC/FGC'
  				34	'number of allocations done before current IGC/FGC'
  				35	'number of survivor objects after current IGC/FGC'
  				36  'millisecond clock when current IGC/FGC completed'
  				37  'number of marked objects for Roots of the world, not including Root Table entries for current IGC/FGC'
  				38  'milliseconds taken by current IGC'
  				39  'Number of finalization signals for Weak Objects pending when current IGC/FGC completed')]
  		ifTrue:
  			[#(	33	'number of root table entries at last scavenge'
  				35	'number of survivor objects at last scavenge (if non-zero)'
  				36  'millisecond clock when current scavenge completed'
  				38  'milliseconds taken by current scavenge'
  				39  'Number of finalization signals for Weak Objects pending when current SGC/FGC completed')]),
  	#(	40  'VM word size - 4 or 8'),
  	(isStack
  		ifTrue:
  			[#(
  				41	'imageFormatVersion for the VM'
  				42	'number of stack pages available'
  				43	'desired number of stack pages (stored in image file header, max 65535)'
  				44	'size of eden, in bytes'
  				45	'desired size of eden, in bytes (stored in image file header)'
  				46	'machine code zone size, in bytes (0 in Stack VM)'
+ 				47	'desired machine code zone size (0 => default 1Mb to 2Mb depending on processor)'
- 				47	'desired machine code zone size (0 => default 1Mb)'
  				48	'various persistent image header flags.  See getCogVMFlags in the VM source.'
  				49	'max size the image promises to grow the external semaphore table to'),
  			(isSpur
  				ifFalse:
  					[{	50 to: 51.	'reserved for VM parameters that persist in the image (such as size of eden above)'.
  						52 to: 56.	'specific to Spur' }]
  				ifTrue:
  					[{	50 to: 51.	'reserved for VM parameters that persist in the image (such as size of eden above)' },
  					#(	52			'root/remembered table capacity'
  						53			'number of old space segments'
  						54			'total free old space'
  						55			'ratio of growth and image size at or above which a GC will be performed post scavenge')]),
  			#(	56	'number of process switches since startup'
  				57	'number of ioProcessEvents calls since startup'
  				58	'number of forceInterruptCheck calls since startup'
  				59	'number of check event calls since startup'
  				60	'number of stack page overflows since startup'
  				61	'number of stack page divorces since startup'
  				62	'compiled code compactions since startup'),
  			(isCog
  				ifFalse:
  					[#()]
  				ifTrue:
  					[#(	63	'total milliseconds in compiled code compactions since startup'
  						64	'the number of methods that currently have jitted machine-code')]),
  			{	65.	'Cog feature flags\		bit 0: set if the VM supports MULTIPLE_BYTECODE_SETS.\		bit 1: set if the VM supports read-only objects.\		bit 2: set if the VM has an ITIMER_HEARTBEAT' withCRs.
  				66.	'the byte size of a stack page'.},
  			(isSpur
  				ifFalse:
  					[{	67 to: 69.	'reserved for more Cog-related info' }]
  				ifTrue:
  					[#(	67		'the maximum allowed size of old space (if zero there is no limit)'
  						68		'the average number of live stack pages when scanned by scavenge/gc/become'
  						69		'the maximum number of live stack pages when scanned by scavenge/gc/become')]),
  			#(	70	'the vmProxyMajorVersion (the interpreterProxy VM_MAJOR_VERSION)'
  				71	'the vmProxyMinorVersion (the interpreterProxy VM_MINOR_VERSION)')]
  		ifFalse:
  			[#()])
  	pairsDo: [:idx :desc | | value values |
  		aStream nextPut: $#.
  		idx isInteger
  			ifTrue:
  				[value := vmParameters at: idx.
  				 aStream print: idx; tab: (idx < 10 ifTrue: [2] ifFalse: [1]); nextPutAll: ((value isInteger and: [idx ~= 41]) ifTrue: [value asStringWithCommas] ifFalse: [value printString])]
  			ifFalse:
  				[value := vmParameters at: idx first.
  				 aStream print: idx first; next: 2 put: $.; print: idx last; tab.
  				 values := idx collect: [:i| vmParameters at: i].
  				 values asSet size = 1
  					ifTrue: [aStream print: value]
  					ifFalse: [values do: [:v| aStream print: v] separatedBy: [aStream nextPutAll: ', ']]].
  		aStream tab; nextPutAll: desc; cr]!


From eliot.miranda at gmail.com  Mon Jul 27 19:29:32 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Mon, 27 Jul 2020 12:29:32 -0700
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
Message-ID: <CAC20JE3=me=J25hEMSo3dT0w6NZ74cpSAdC4Zfd-uEDTqTQkhw@mail.gmail.com>

Hi Chris,

On Tue, Jun 30, 2020 at 4:28 PM Chris Muller <asqueaker at gmail.com> wrote:

> Hi Eliot,
>
> The order of repositories is part of the model, sorting them conceptually
> breaks a couple of MC's use-cases.  Would list-filtering help you find the
> repository you seek amongst your list of 40 repositories?
>

Perhaps, but having a rational sort order makes the most sense.  I've just
got annoyed, and calmed down, as I had to add trunk to one of my packages
and couldn't find it easily in the list.  I have to admit I found your
reverting of my sorting passive aggressive.  This is a real issue for me.
I would have liked to see us fix the issues that introducing sorting
added.  I don't see how anyone can deal with a complex configuration with
the apparently arbitrary and unsorted list we have now.  So I'm reraising
this as a real issue.  Can you explain your commit comment for
Monticello-cmm.726, "Revert incorrect implementation of sorting
repositories, because it broke "demote to bottom" which broke "browse
revisions" and "browse origin"."?  How and why does it break these things?
 ow and why do they rely on the unsorted order?


>  - Chris
>
> On Tue, Jun 30, 2020 at 5:21 PM <commits at source.squeak.org> wrote:
>
>> Chris Muller uploaded a new version of Monticello to project The Trunk:
>> http://source.squeak.org/trunk/Monticello-cmm.726.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Monticello-cmm.726
>> Author: cmm
>> Time: 30 June 2020, 5:21:11.609668 pm
>> UUID: 1a529d96-0be7-45a8-a65e-b9dcae087b85
>> Ancestors: Monticello-mt.725
>>
>> Revert incorrect implementation of sorting repositories, because it broke
>> "demote to bottom" which broke "browse revisions" and "browse origin".
>>
>> =============== Diff against Monticello-mt.725 ===============
>>
>> Item was changed:
>>   ----- Method: MCWorkingCopyBrowser>>repositories (in category 'morphic
>> ui') -----
>>   repositories
>> +       ^ self repositoryGroup repositories!
>> -       | repositories |
>> -       repositories := self repositoryGroup repositories.
>> -       ^{repositories first}, (repositories allButFirst sort: [:r1 :r2|
>> r1 description < r2 description])!
>>
>>
>>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200727/e5b58ee2/attachment.html>

From eliot.miranda at gmail.com  Mon Jul 27 19:31:00 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Mon, 27 Jul 2020 12:31:00 -0700
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
 <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>
 <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>
Message-ID: <CAC20JE1_PPhtdyqUj99q_4SJeRwcQaYBUrX5OLBXwihLxRp65A@mail.gmail.com>

On Tue, Jun 30, 2020 at 8:55 PM Chris Muller <ma.chris.m at gmail.com> wrote:

> On Tue, Jun 30, 2020 at 7:59 PM Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
>
>> On Tue, 30 Jun 2020, Chris Muller wrote:
>>
>> > Hi Eliot,
>> > The order of repositories is part of the model, sorting them
>> conceptually breaks a couple of MC's use-cases.  Would list-filtering help
>> you find the repository you seek amongst your list of 40 repositories?
>>
>> What model is it part of?
>>
>
> Monticello's.  MCWorkingCopyBrowser's.
>
>
>> And if it is, how come the GUI doesn't let you change that order?
>>
>
> It's "demote to bottom" on the menu.  But it seemed to have gotten broke
> due to the #repositories list always being sorted.
>
> My hope is that Eliot's use-case is for only when there are no
> WorkingCopy's selected, thus showing _all_ repositories -- because we can
> sort that output.  But sorting as far as when an individual WorkingCopy is
> selected, it breaks one or two use cases.
>

It's the "show all repositories" use case I care about.  I certainly
*don't* (and didn't) intend to change the sort order of an individual
package's repositories. I understand how I f**ked up now.  I apologize.
Maybe I can do better next time?


>
>  - Chris
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200727/2de351b9/attachment.html>

From ma.chris.m at gmail.com  Tue Jul 28 03:30:47 2020
From: ma.chris.m at gmail.com (Chris Muller)
Date: Mon, 27 Jul 2020 22:30:47 -0500
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <CAC20JE1_PPhtdyqUj99q_4SJeRwcQaYBUrX5OLBXwihLxRp65A@mail.gmail.com>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
 <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>
 <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>
 <CAC20JE1_PPhtdyqUj99q_4SJeRwcQaYBUrX5OLBXwihLxRp65A@mail.gmail.com>
Message-ID: <CADTxDUiae3oWkSNZ49c3KJQPyX21YAVpu3q42EJvvjCXywoTZg@mail.gmail.com>

Hi Eliot,

I care that something in the IDE isn't working optimally for you.  I do
certainly prefer when we engage in a deliberative work style, so when I
went to use those legacy IDE functions and found this change to be the
reason I couldn't, I took care not to fix it more aggressively than it was
committed, and remain sensitive to your use-case to help get it in properly.

So that's good to know you were referring to the "all" list, that should
make it just a presentation issue then..

 - Chris

On Mon, Jul 27, 2020 at 2:31 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
>
> On Tue, Jun 30, 2020 at 8:55 PM Chris Muller <ma.chris.m at gmail.com> wrote:
>
>> On Tue, Jun 30, 2020 at 7:59 PM Levente Uzonyi <leves at caesar.elte.hu>
>> wrote:
>>
>>> On Tue, 30 Jun 2020, Chris Muller wrote:
>>>
>>> > Hi Eliot,
>>> > The order of repositories is part of the model, sorting them
>>> conceptually breaks a couple of MC's use-cases.  Would list-filtering help
>>> you find the repository you seek amongst your list of 40 repositories?
>>>
>>> What model is it part of?
>>>
>>
>> Monticello's.  MCWorkingCopyBrowser's.
>>
>>
>>> And if it is, how come the GUI doesn't let you change that order?
>>>
>>
>> It's "demote to bottom" on the menu.  But it seemed to have gotten broke
>> due to the #repositories list always being sorted.
>>
>> My hope is that Eliot's use-case is for only when there are no
>> WorkingCopy's selected, thus showing _all_ repositories -- because we can
>> sort that output.  But sorting as far as when an individual WorkingCopy is
>> selected, it breaks one or two use cases.
>>
>
> It's the "show all repositories" use case I care about.  I certainly
> *don't* (and didn't) intend to change the sort order of an individual
> package's repositories. I understand how I f**ked up now.  I apologize.
> Maybe I can do better next time?
>
>
>>
>>  - Chris
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200727/41ee9710/attachment.html>

From marcel.taeumel at hpi.de  Tue Jul 28 07:01:12 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Tue, 28 Jul 2020 09:01:12 +0200
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <CADTxDUiae3oWkSNZ49c3KJQPyX21YAVpu3q42EJvvjCXywoTZg@mail.gmail.com>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
 <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>
 <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>
 <CAC20JE1_PPhtdyqUj99q_4SJeRwcQaYBUrX5OLBXwihLxRp65A@mail.gmail.com>
 <CADTxDUiae3oWkSNZ49c3KJQPyX21YAVpu3q42EJvvjCXywoTZg@mail.gmail.com>
Message-ID: <Mailbird-5a917cfd-b081-4d8e-8b22-f99af588ef9f@hpi.de>

Hi Eliot, hi Chris,

what about adding the preference #sortMonticelloRepositoriesAlphabetically like we have #sortMessageCategoriesAlphabetically ?

Best,
Marcel
Am 28.07.2020 05:31:34 schrieb Chris Muller <ma.chris.m at gmail.com>:
Hi Eliot,

I care that something in the IDE isn't working optimally for you.  I do certainly prefer when we engage in a deliberative work style, so when I went to use those legacy IDE functions and found this change to be the reason I couldn't, I took care not to fix it more aggressively than it was committed, and remain sensitive to your use-case to help get it in properly.

So that's good to know you were referring to the "all" list, that should make it just a presentation issue then..

 - Chris

On Mon, Jul 27, 2020 at 2:31 PM Eliot Miranda <eliot.miranda at gmail.com [mailto:eliot.miranda at gmail.com]> wrote:



On Tue, Jun 30, 2020 at 8:55 PM Chris Muller <ma.chris.m at gmail.com [mailto:ma.chris.m at gmail.com]> wrote:

On Tue, Jun 30, 2020 at 7:59 PM Levente Uzonyi <leves at caesar.elte.hu [mailto:leves at caesar.elte.hu]> wrote:

On Tue, 30 Jun 2020, Chris Muller wrote:

> Hi Eliot,
> The order of repositories is part of the model, sorting them conceptually breaks a couple of MC's use-cases.  Would list-filtering help you find the repository you seek amongst your list of 40 repositories?

What model is it part of?


Monticello's.  MCWorkingCopyBrowser's.
 

And if it is, how come the GUI doesn't let you change that order?


It's "demote to bottom" on the menu.  But it seemed to have gotten broke due to the #repositories list always being sorted.

My hope is that Eliot's use-case is for only when there are no WorkingCopy's selected, thus showing _all_ repositories -- because we can sort that output.  But sorting as far as when an individual WorkingCopy is selected, it breaks one or two use cases.

It's the "show all repositories" use case I care about.  I certainly *don't* (and didn't) intend to change the sort order of an individual package's repositories. I understand how I f**ked up now.  I apologize.  Maybe I can do better next time?
 

 - Chris



--

_,,,^..^,,,_

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/14fc3736/attachment.html>

From commits at source.squeak.org  Tue Jul 28 08:00:58 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Tue, 28 Jul 2020 08:00:58 0000
Subject: [squeak-dev] The Trunk: ToolBuilder-Morphic-mt.263.mcz
Message-ID: <E1k0KXk-0005NX-AG@andreas>

Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project The Trunk:
http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.263.mcz

==================== Summary ====================

Name: ToolBuilder-Morphic-mt.263
Author: mt
Time: 28 July 2020, 10:00:57.682779 am
UUID: fecabf05-7969-5f4f-8a7a-c0a2fbf874b8
Ancestors: ToolBuilder-Morphic-pre.262

In tree widgets, fixes refresh for nodes w/o parents (aka. top nodes or roots). See ObjectExplorerWrapper for a similar strategy.

=============== Diff against ToolBuilder-Morphic-pre.262 ===============

Item was changed:
  ----- Method: PluggableTreeItemNode>>refresh (in category 'as yet unclassified') -----
  refresh
  	
+ 	self parent ifNil: [^ self].
  	self setItem: (self parent contents
  		at: self index
  		ifAbsent: [self error: 'No support for changed child count yet!!'])
  			item.!


From marcel.taeumel at hpi.de  Tue Jul 28 10:26:10 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Tue, 28 Jul 2020 12:26:10 +0200
Subject: [squeak-dev] [ANN] MessageSendRecorder (and MethodWrappers) @ GitHub
Message-ID: <Mailbird-fd37176c-dcc5-4532-aaa5-b221657fb08e@hpi.de>

Hi all!

I revived (and cleaned-up) a tracing project for Squeak our group did several years ago:

https://github.com/hpi-swa/MessageSendRecorder [https://github.com/hpi-swa/MessageSendRecorder]

And the end of the readme.md, you will find pointers to papers that (more or less) made use of this approach.


It uses MethodWrappers, which I also pushed to GitHub:
https://github.com/hpi-swa/MethodWrappers [https://github.com/hpi-swa/MethodWrappers]

Happy Squeaking!

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/e81af153/attachment.html>

From dev at stlutz.net  Tue Jul 28 11:33:54 2020
From: dev at stlutz.net (Stephan Lutz)
Date: Tue, 28 Jul 2020 13:33:54 +0200
Subject: [squeak-dev] Rounding in MatrixTransform2x3
Message-ID: <338f01a9-a5a3-eb4a-2369-f1f06723f9c8@stlutz.net>

While transforming points using MatrixTransform2x3 we noticed some 
strange rounding behavior:

    "with plugin"
    (MatrixTransform2x3 withOffset: 5 @ 10) localPointToGlobal: 0 at 0. "5 at 10"
    (MatrixTransform2x3 withOffset: -5 @ -10) localPointToGlobal: 0 at 0.
    "-4@ -9"

    "without plugin"
    ((MatrixTransform2x3 withOffset: 5 @ 10) transformPoint: 0 at 0)
    rounded. "5 at 10"
    ((MatrixTransform2x3 withOffset: -5 @ -10) transformPoint: 0 at 0)
    rounded. "-5@ -10"

It appears the code used to round in the plugin simply adds 0.5 and 
truncates the result, which does not work correctly for negative numbers.
This code can be found in Matrix2x3Plugin >> #roundAndStoreResultPoint: 
and Matrix2x3Plugin >> #roundAndStoreResultRect:x0:y0:x1:y1: .

----

On a kind of related note: Is there even a reason to round the resulting 
floats?

While the class comment of MatrixTransform2x3 notes that this behavior 
is intentional, glancing quickly over its uses we could not find 
anything taking advantage or benefiting from it. It's also not a 
limitation of the DisplayTransform interface, since MorphicTransform 
does produce floating point values. Wouldn't it be much more versatile 
and easier to leave rounding to users if they actually need it?


Stephan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/361c51e1/attachment-0001.html>

From commits at source.squeak.org  Tue Jul 28 11:34:04 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Tue, 28 Jul 2020 11:34:04 0000
Subject: [squeak-dev] FFI: FFI-Kernel-mt.119.mcz
Message-ID: <E1k0Nrx-0008J1-RP@andreas>

Marcel Taeumel uploaded a new version of FFI-Kernel to project FFI:
http://source.squeak.org/FFI/FFI-Kernel-mt.119.mcz

==================== Summary ====================

Name: FFI-Kernel-mt.119
Author: mt
Time: 28 July 2020, 1:34:03.494011 pm
UUID: ad1bfdeb-3a7f-bb49-a61d-199918835891
Ancestors: FFI-Kernel-nice.118

Adds parser hook for callback pragmas. Simplifies loading of FFI-Callback.

=============== Diff against FFI-Kernel-nice.118 ===============

Item was added:
+ ----- Method: Parser>>callback (in category '*FFI-Kernel') -----
+ callback
+ 	<pragmaParser>
+ 	
+ 	| descriptorClass retType externalName args argType |
+ 	descriptorClass := ExternalFunction.
+ 	"Parse return type"
+ 	self advance.
+ 	here = 'const' ifTrue: [self advance].
+ 	retType := self externalType: descriptorClass.
+ 	retType == nil ifTrue:[^self expected:'return type'].
+ 	"Parse function name or index"
+ 	externalName := here.
+ 
+ 	(self match: #leftParenthesis) ifFalse:[^self expected:'function pointer (*)'].
+ 	(self matchToken: #*) ifFalse:[^self expected:'function pointer (*)'].
+ 	(self match: #rightParenthesis) ifFalse:[^self expected:'function pointer (*)'].
+ 
+ 	(self match: #leftParenthesis) ifFalse:[^self expected:'argument list'].
+ 	args := WriteStream on: Array new.
+ 	[self match: #rightParenthesis] whileFalse:[
+ 		here = 'const' ifTrue: [self advance].
+ 		here = ',' ifTrue: [self advance].
+ 		argType := self externalType: descriptorClass.
+ 		argType == nil ifTrue:[^self expected:'argument'].
+ 		argType isVoid & argType isPointerType not ifFalse:[args nextPut: argType]].
+ 
+ 	self addPragma: (Pragma keyword: #callback: arguments: {{retType}, args contents}).
+ 	^true!


From commits at source.squeak.org  Tue Jul 28 11:34:28 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Tue, 28 Jul 2020 11:34:28 0000
Subject: [squeak-dev] FFI: FFI-Tools-mt.20.mcz
Message-ID: <E1k0NsM-0008J9-2X@andreas>

Marcel Taeumel uploaded a new version of FFI-Tools to project FFI:
http://source.squeak.org/FFI/FFI-Tools-mt.20.mcz

==================== Summary ====================

Name: FFI-Tools-mt.20
Author: mt
Time: 28 July 2020, 1:34:28.035011 pm
UUID: f78c718c-8d1c-e141-a601-7e9bcf6d3978
Ancestors: FFI-Tools-mt.19

Adds parser hook for callback pragmas. Simplifies loading of FFI-Callback.

=============== Diff against FFI-Tools-mt.19 ===============

Item was added:
+ ----- Method: SHParserST80>>callback (in category '*FFI-Tools') -----
+ callback
+ 	<pragmaParser>
+ 	
+ 	self scanPast: #externalFunctionCallingConvention.	
+ 	
+ 	self scanPast: #externalCallType.
+ 	currentToken = '*' 
+ 		ifTrue: [self scanPast: #externalCallTypePointerIndicator].
+ 
+ 	currentTokenFirst == $( ifFalse: [^ self fail]. self scanNext.
+ 	currentTokenFirst == $* ifFalse: [^ self fail]. self scanNext.
+ 	currentTokenFirst == $) ifFalse: [^ self fail]. self scanNext.
+ 		
+ 	self failUnless: currentTokenFirst == $(.
+ 	self scanPast: #leftParenthesis.
+ 	[currentTokenFirst ~= $)] 
+ 		whileTrue: [
+ 			self failUnless: currentToken notNil.
+ 			self scanPast: #externalCallType.
+ 			currentToken = '*' 
+ 				ifTrue: [self scanPast: #externalCallTypePointerIndicator]].
+ 	self scanPast: #rightParenthesis.
+ 	currentToken = 'module:' 
+ 		ifTrue: [
+ 			self scanPast: #module.
+ 			self parseStringOrSymbol ].
+ 	currentToken = 'error:' ifTrue: [
+ 		self scanPast: #primitive. "there's no rangeType for error"
+ 		self currentTokenType == #name
+ 			ifTrue: [ self parseTemporary: #patternTempVar ]
+ 			ifFalse: [ self parseStringOrSymbol ] ].
+ 	self failUnless: currentToken = '>'.
+ 	self scanPast: #primitiveOrExternalCallEnd!


From commits at source.squeak.org  Tue Jul 28 11:35:12 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Tue, 28 Jul 2020 11:35:12 0000
Subject: [squeak-dev] FFI: FFI-Callbacks-mt.1.mcz
Message-ID: <E1k0Nt3-0008K1-9r@andreas>

Marcel Taeumel uploaded a new version of FFI-Callbacks to project FFI:
http://source.squeak.org/FFI/FFI-Callbacks-mt.1.mcz

==================== Summary ====================

Name: FFI-Callbacks-mt.1
Author: mt
Time: 18 June 2020, 7:36:50.422967 am
UUID: b0e1b5a9-9625-4e41-b36f-a39f271aec00
Ancestors: 

First version of callback support for Squeak FFI. This is basically a port of the callback support in Alien-Core.tbn.103.

WARNING: You cannot load this package if you already have Alien-Core loaded because this package needs to install a different class into the special-objects array at the same index.

Next steps:
- add GC support for executable pages/blocks when managing thunks and instances of FFICallback
- fix the VM crash that occured on IA32 when return from a callback back to the VM -- iff it turns out to not be an issue in the IA32ABI plugin
- add support for ABI-specific argument marshalling on the callback; maybe include some code generation to get started --- this version just does a #evaluateDynamic:, which assumes a lot of things that might not be true for your ABI
- see if #exampleCqsort finally works then :-)

==================== Snapshot ====================

SystemOrganization addCategory: #'FFI-Callbacks'!

ByteArray variableByteSubclass: #FFICallbackMemory
	instanceVariableNames: ''
	classVariableNames: 'AccessProtect AllocatedThunks ExecutablePages LifoCallbackSemaphore'
	poolDictionaries: ''
	category: 'FFI-Callbacks'!

!FFICallbackMemory commentStamp: 'mt 6/17/2020 12:24' prior: 0!
Interface for memory allocation using the IA32ABI plugin. Also used as a compatibility layer for Alien.

***

An instance of FFICallbackThunk is a reference to a machine-code thunk/trampoline that calls-back into the VM.  The reference can be passed to C code which can use it as a function pointer through which to call-back into Smalltalk.  The machine-code thunk/trampoline is different for each instance, hence its address is a unique key that can be used to assocuate the Smalltalk side of the call-back (e.g. a block) with the thunk.  Since thunks must be executable and some OSs may not provide default execute permission on memory returned by malloc we may not be able to use malloc directly.  Instead we rely on a primitive to provide memory that is guaranteed to be executable.  ExternalAddress class>>allocateExecutablePage answers an instance of ExternalData that references an executable piece of memory that is some (possiby unitary) multiple of the pagesize.  Class-side code then parcels out pieces of a page to individual thunks.  These pieces are recycled when thunks are reclaimed.  Since 
 the first byte of a thunk is non-zero we can use it as a flag indicating if the piece is in use or not.

See FFICallback for the higher-level construct that represents a Smalltalk block to be run in response to a callback.  Callbacks wrap instances of FFICallbackThunk and FFICallbackContext instances that describe the stack layout and register contents for receiving callback arguments.

Class Variables
AccessProtect <Semaphore> critical section for ExecutablePages (de)allocation
AllocatedThunks <AlienWeakTable of <FFICallbackThunk -> Integer>> - weak collection of thunks, used to return thunk storage to the executable page pool.
ExecutablePages <Set of: Alien "executable page"> - collection of pages with execute permissions used to provide executable thunks!

----- Method: FFICallbackMemory class>>allocateExecutableBlock (in category 'executable pages') -----
allocateExecutableBlock

	| blockSize |
	blockSize := FFICallback maxThunkSize.
	AccessProtect critical:
		[ExecutablePages do:
			[:page |
			1 to: page size - blockSize by: blockSize do:
				[:i|
				(page at: i) = 0 ifTrue:
					[page at: i put: 1.
					 ^ page blockAt: i byteSize: blockSize]]]].
	AccessProtect critical: [
		| newPage |
		newPage := ExecutablePages add: self allocateExecutablePage.
		^ (newPage blockAt: 1 byteSize: blockSize)
			at: 1 put: 1;
			yourself]!

----- Method: FFICallbackMemory class>>allocateExecutablePage (in category 'executable pages') -----
allocateExecutablePage
	"Forward allocation to ExternalAddress, which already sends primitives to allocate memory."
	
	^ ExternalAddress allocateExecutablePage!

----- Method: FFICallbackMemory class>>ensureInSpecialObjectsArray (in category 'class initialization') -----
ensureInSpecialObjectsArray
	"FFICallbackMemory must be in the specialObjectsArray to enable the FFI callback mechanism.  Because of
	 the bootstrap the specialObjectsArray may already have been partially initialized with
	 the callback selector and to be large enough (as part of loading immutability), but
	 it will be missing FFICallbackMemory until FFICallbackMemory is loaded.  So check if the specialObjectsArray is
	 of the expected size before recreating and slam FFICallbackMemory in if the specialObjectsArray
	 is already large enough."

	| index |
	self ~~ FFICallbackMemory ifTrue: [^self].

	index := 53.
	((Smalltalk includesKey: #VMObjectIndices)
	 and: [((Smalltalk at: #VMObjectIndices) classPool at: #ClassAlien ifAbsent: []) ~= (index - 1)]) ifTrue:
		[self error: 'index probably wrong'].

	Smalltalk specialObjectsArray size < index ifTrue:
		[Smalltalk recreateSpecialObjectsArray].
	
	Smalltalk specialObjectsArray size < index ifTrue: 
		[self error: 'SystemDictionary>>recreateSpecialObjectsArray appears incompatible'].
	
	((Smalltalk specialObjectsArray at: index) ~~ nil
		and: [(Smalltalk specialObjectsArray at: index) ~~ self]) ifTrue:
			[self error: 'Alien is already installed. You should not load FFI-Callbacks, too.'].

	(Smalltalk specialObjectsArray at: index) ifNil:
		[Smalltalk specialObjectsArray at: index put: self]!

----- Method: FFICallbackMemory class>>fromInteger: (in category 'instance creation') -----
fromInteger: anInteger
	"Like the extension in ExternalAddress, but duplicate byte size to follow the alien format as expected in the IA32ABI plugin."

	^ self new
		addressFieldPut: anInteger;
		yourself	!

----- Method: FFICallbackMemory class>>initialize (in category 'class initialization') -----
initialize

	self ensureInSpecialObjectsArray.
	Smalltalk addToStartUpList: self after: FFIPlatformDescription.
	LifoCallbackSemaphore := Semaphore new.

	AccessProtect := Semaphore forMutualExclusion.
	"AllocatedThunks := AlienWeakTable newForOwner: self."
	ExecutablePages := Set new.!

----- Method: FFICallbackMemory class>>invokeCallbackContext: (in category 'callbacks') -----
invokeCallbackContext: vmCallbackContextAddress "<Integer>" "^<FFICallbackReturnValue>"
	"The low-level entry-point for callbacks sent from the VM/IA32ABI plugin.
	 Evaluate the callback corresponding to the thunk referenced by vmCallbackContextAddress,
	 a pointer to a FFICallbackContext, set up by the VM's thunkEntry
	 routine.  Return to C via primSignal:andReturnAs:fromContext:.  thisContext's sender is the
	 call-out context."
	| callbackContext typeCode helper |
	callbackContext := FFICallbackContext fromHandle: vmCallbackContextAddress.
	helper := self fromInteger: vmCallbackContextAddress.
	
	[typeCode := FFICallback evaluateCallbackForContext: callbackContext]
		ifCurtailed: [self error: 'attempt to non-local return across a callback'].
	typeCode ifNil:
		[typeCode := callbackContext errorResult].
	"Now attempt to return to C.  The primitive will answer false if this is not the most recent Callback,
	 in which case we should wait on the lifoCallbackSemaphore which will be signalled when the most
	 recent callback successfully returns.  If this is the most recent callback the primitive will signal all
	 the processes waiting on the lifoCallbackSemaphore, one of which will be the next most recent.
	 Hence all nested callbacks will end up returning in the right order."
	[helper primSignal: LifoCallbackSemaphore andReturnAs: typeCode fromContext: thisContext] whileFalse:
		[LifoCallbackSemaphore wait]!

----- Method: FFICallbackMemory class>>new (in category 'instance creation') -----
new
	"Only used for holding (alien) pointers."
	
	^ super new: ExternalAddress wordSize * 2!

----- Method: FFICallbackMemory class>>new: (in category 'instance creation') -----
new: n
	
	self shouldNotImplement.!

----- Method: FFICallbackMemory class>>startUp: (in category 'system startup') -----
startUp: resuming
	"Any thunks in the finalization registry at the time the image comes up in a new session MUST NOT be finalized and should  immediately be discarded. Their thunk pointers are no longer valid."
	resuming ifTrue:
		["AllocatedThunks removeAll."
		ExecutablePages := Set new]!

----- Method: FFICallbackMemory class>>unload (in category 'class initialization') -----
unload

	Smalltalk removeFromStartUpList: self.!

----- Method: FFICallbackMemory>>addressField (in category 'alien compatibility') -----
addressField "^<Integer>"
	<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>
	
	^ (ExternalData fromHandle: self type: ExternalType uintptr_t)
		at: ExternalData wordSize + 1!

----- Method: FFICallbackMemory>>addressFieldPut: (in category 'alien compatibility') -----
addressFieldPut: value "<Integer> ^<Integer>"
	<primitive: 'primAddressFieldPut' module: 'IA32ABI' error: errorCode>

	self notify: 'Primitive failed. Proceed to use fallback code.'.	
	^ (ExternalData fromHandle: self type: ExternalType uintptr_t)
		at: ExternalData wordSize + 1
		put: value!

----- Method: FFICallbackMemory>>byteSize (in category 'accessing') -----
byteSize
	"Answer the number of bytes that are allocated when following the #externalPointer."
	^ self sizeField abs!

----- Method: FFICallbackMemory>>externalPointer (in category 'accessing') -----
externalPointer
	"Answer the address that points to allocated memory of #byteSize num bytes."
	^ ExternalAddress fromInteger: self addressField!

----- Method: FFICallbackMemory>>externalPointer: (in category 'accessing') -----
externalPointer: anExternalAddress

	| type integer |
	self flag: #debugging.
	type := ExternalType uintptr_t.
	integer := type
		handle: anExternalAddress asByteArrayPointer
		at: 1.
		
	self addressFieldPut: integer.!

----- Method: FFICallbackMemory>>primSignal:andReturnAs:fromContext: (in category 'callbacks') -----
primSignal: aSemaphore "<Semaphore>" andReturnAs: typeCode "<SmallInteger>" fromContext: context "<MethodContext>"
	<primitive: 'primReturnAsFromContextThrough' module: 'IA32ABI' error: ec>
	^ self primitiveFailed!

----- Method: FFICallbackMemory>>sizeField (in category 'alien compatibility') -----
sizeField "^<Integer>"
	<primitive: 'primSizeField' module: 'IA32ABI' error: errorCode>

	"For some reason, the size is stored as intptr_t, not uintpr_t."
	^ (ExternalData fromHandle: self type: ExternalType intptr_t)
		at: 1!

----- Method: FFICallbackMemory>>sizeFieldPut: (in category 'alien compatibility') -----
sizeFieldPut: size "<Integer> ^<Integer>"
	<primitive: 'primSizeFieldPut' module: 'IA32ABI' error: errorCode>

	self notify: 'Primitive failed. Proceed to use fallback code.'.	

	"For some reason, the size is stored as intptr_t, not uintpr_t."
	^ (ExternalData fromHandle: self type: ExternalType intptr_t)
		at: 1 put: size!

----- Method: ExternalData class>>fromHandle:byteSize: (in category '*FFI-Callbacks') -----
fromHandle: aHandle byteSize: byteSize
	^ (self fromHandle: aHandle type: ExternalType unsignedByte asPointerType)
		size: byteSize;
		yourself!

----- Method: ExternalData>>blockAt:byteSize: (in category '*FFI-Callbacks') -----
blockAt: byteIndex byteSize: numBytes
	"Given that the receiver manages a page of memory, answer a block of that memory to use."
	^ ExternalData
		fromHandle: handle + (byteIndex - 1)
		byteSize: numBytes!

ExternalStructure subclass: #FFICallbackContext
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'FFI-Callbacks'!

----- Method: FFICallbackContext class>>fields (in category 'field definition') -----
fields
	"
	self defineFields.
	"
	^ #(
		(thunkp		'void*')
		(stackPtr		'intptr_t*')	"was: char*"
		(intRegArgs		'intptr_t*')	"was: long* or int*"
		(floatRegArgs	'double*')
		(nil				'void*')		"was: savedCStackPointer"
		(nil				'void*')		"was: savedCFramePointer"
		(rvs				'FFICallbackResult')
	)
	
"
typedef struct {
    void *thunkp;
    char *stackptr;
    long *intRegArgs;
    double *floatRegArgs;
    void *savedCStackPointer;
    void *savedCFramePointer;
    union {
                            intptr_t vallong;
                            struct { int low, high; } valleint64;
                            struct { int high, low; } valbeint64;
                            double valflt64;
                            struct { void *addr; intptr_t size; } valstruct;
                        }   rvs;
	void *savedPrimFunctionPointer;
	jmp_buf	trampoline;
	jmp_buf	savedReenterInterpreter;
 } VMCallbackContext;
"!

----- Method: FFICallbackContext class>>fromHandle: (in category 'instance creation') -----
fromHandle: aHandleOrInteger

	^ super fromHandle: (aHandleOrInteger isInteger
		ifTrue: [ExternalAddress fromInteger: aHandleOrInteger]
		ifFalse: [aHandleOrInteger])!

----- Method: FFICallbackContext>>errorResult (in category 'callback result') -----
errorResult

	^ self wordResult: -1!

----- Method: FFICallbackContext>>externalObjectResult: (in category 'callback result') -----
externalObjectResult: anExternalObject
	"ExternalStructure, ExternalUnion, ExternalData ... handle MUST BE an ExternalAddress"
	
	^ self pointerResult: anExternalObject getHandle!

----- Method: FFICallbackContext>>floatRegArgs (in category 'accessing') -----
floatRegArgs
	"This method was automatically generated. See FFICallbackContext class>>fields."
	<generated>
	^ExternalData fromHandle: (handle shortPointerAt: 13) type: ExternalType double asPointerType!

----- Method: FFICallbackContext>>floatRegArgs: (in category 'accessing') -----
floatRegArgs: someExternalData
	"This method was automatically generated. See FFICallbackContext class>>fields."
	<generated>
	handle shortPointerAt: 13 put: someExternalData getHandle.!

----- Method: FFICallbackContext>>floatResult: (in category 'callback result') -----
floatResult: aFloat

	self rvs floatResult: aFloat.
	^ 3!

----- Method: FFICallbackContext>>intRegArgs (in category 'accessing') -----
intRegArgs
	"This method was automatically generated. See FFICallbackContext class>>fields."
	<generated>
	^ExternalData fromHandle: (handle shortPointerAt: 9) type: ExternalType long asPointerType!

----- Method: FFICallbackContext>>intRegArgs: (in category 'accessing') -----
intRegArgs: someExternalData
	"This method was automatically generated. See FFICallbackContext class>>fields."
	<generated>
	handle shortPointerAt: 9 put: someExternalData getHandle.!

----- Method: FFICallbackContext>>pointerResult: (in category 'callback result') -----
pointerResult: anExternalAddress

	^ self wordResult: anExternalAddress asInteger!

----- Method: FFICallbackContext>>rvs (in category 'accessing') -----
rvs
	"This method was automatically generated. See FFICallbackContext class>>fields."
	<generated>
	^FFICallbackResult fromHandle: (handle structAt: 25 length: 8)!

----- Method: FFICallbackContext>>rvs: (in category 'accessing') -----
rvs: aFFICallbackResult
	"This method was automatically generated. See FFICallbackContext class>>fields."
	<generated>
	handle structAt: 25 put: aFFICallbackResult getHandle length: 8.!

----- Method: FFICallbackContext>>stackPtr (in category 'accessing') -----
stackPtr
	"This method was automatically generated. See FFICallbackContext class>>fields."
	<generated>
	^ExternalData fromHandle: (handle shortPointerAt: 5) type: ExternalType long asPointerType!

----- Method: FFICallbackContext>>stackPtr: (in category 'accessing') -----
stackPtr: someExternalData
	"This method was automatically generated. See FFICallbackContext class>>fields."
	<generated>
	handle shortPointerAt: 5 put: someExternalData getHandle.!

----- Method: FFICallbackContext>>thunkp (in category 'accessing') -----
thunkp
	"This method was automatically generated. See FFICallbackContext class>>fields."
	<generated>
	^ExternalData fromHandle: (handle shortPointerAt: 1) type: ExternalType void asPointerType!

----- Method: FFICallbackContext>>thunkp: (in category 'accessing') -----
thunkp: someExternalData
	"This method was automatically generated. See FFICallbackContext class>>fields."
	<generated>
	handle shortPointerAt: 1 put: someExternalData getHandle.!

----- Method: FFICallbackContext>>voidResult (in category 'callback result') -----
voidResult

	self flag: #discuss. "mt: Is this the expected answer in the IA32ABI plugin?"
	^ self wordResult: 0!

----- Method: FFICallbackContext>>wordResult: (in category 'callback result') -----
wordResult: aValue
	"Accept any value in the -2^31 to 2^32-1 range or booleans."

	aValue isBoolean ifTrue:
		[self rvs booleanResult: aValue].
	
	aValue isInteger ifTrue:
		[aValue >= 0
			ifTrue: [self rvs positiveIntegerResult: aValue]
			ifFalse: [self rvs integerResult: aValue]].

	^1!

----- Method: Parser>>callback (in category '*FFI-Callbacks') -----
callback
	<pragmaParser>
	
	| descriptorClass retType externalName args argType |
	descriptorClass := ExternalFunction.
	"Parse return type"
	self advance.
	here = 'const' ifTrue: [self advance].
	retType := self externalType: descriptorClass.
	retType == nil ifTrue:[^self expected:'return type'].
	"Parse function name or index"
	externalName := here.

	(self match: #leftParenthesis) ifFalse:[^self expected:'function pointer (*)'].
	(self matchToken: #*) ifFalse:[^self expected:'function pointer (*)'].
	(self match: #rightParenthesis) ifFalse:[^self expected:'function pointer (*)'].

	(self match: #leftParenthesis) ifFalse:[^self expected:'argument list'].
	args := WriteStream on: Array new.
	[self match: #rightParenthesis] whileFalse:[
		here = 'const' ifTrue: [self advance].
		here = ',' ifTrue: [self advance].
		argType := self externalType: descriptorClass.
		argType == nil ifTrue:[^self expected:'argument'].
		argType isVoid & argType isPointerType not ifFalse:[args nextPut: argType]].

	self addPragma: (Pragma keyword: #callback: arguments: {{retType}, args contents}).
	^true!

----- Method: SHParserST80>>callback (in category '*FFI-Callbacks') -----
callback
	<pragmaParser>
	
	self scanPast: #externalFunctionCallingConvention.	
	
	self scanPast: #externalCallType.
	currentToken = '*' 
		ifTrue: [self scanPast: #externalCallTypePointerIndicator].

	currentTokenFirst == $( ifFalse: [^ self fail]. self scanNext.
	currentTokenFirst == $* ifFalse: [^ self fail]. self scanNext.
	currentTokenFirst == $) ifFalse: [^ self fail]. self scanNext.
		
	self failUnless: currentTokenFirst == $(.
	self scanPast: #leftParenthesis.
	[currentTokenFirst ~= $)] 
		whileTrue: [
			self failUnless: currentToken notNil.
			self scanPast: #externalCallType.
			currentToken = '*' 
				ifTrue: [self scanPast: #externalCallTypePointerIndicator]].
	self scanPast: #rightParenthesis.
	currentToken = 'module:' 
		ifTrue: [
			self scanPast: #module.
			self parseStringOrSymbol ].
	currentToken = 'error:' ifTrue: [
		self scanPast: #primitive. "there's no rangeType for error"
		self currentTokenType == #name
			ifTrue: [ self parseTemporary: #patternTempVar ]
			ifFalse: [ self parseStringOrSymbol ] ].
	self failUnless: currentToken = '>'.
	self scanPast: #primitiveOrExternalCallEnd!

----- Method: ExternalAddress class>>allocateExecutablePage (in category '*FFI-Callbacks') -----
allocateExecutablePage
	"The IA32ABI plugin answers a byte array where the first half encodes the allocated byte size and the second half the external address to that executable memory. Unpack that byte array and return external data we can read and write conveniently."
	
	| alien |
	alien := self primAllocateExecutablePage.	
	^ ExternalData
		fromHandle: alien externalPointer
		byteSize: alien byteSize!

----- Method: ExternalAddress class>>fromInteger: (in category '*FFI-Callbacks') -----
fromInteger: anInteger
	"Read the given interger as an address pointing to an external memory area."
	
	| buffer type |
	type := ExternalType uintptr_t.
	buffer := ByteArray new: type byteSize.
	type handle: buffer at: 1 put: anInteger.
	^ buffer asExternalPointer!

----- Method: ExternalAddress class>>primAllocateExecutablePage (in category '*FFI-Callbacks') -----
primAllocateExecutablePage "^<Alien>"
	"Answer an Alien around a piece of (probably malloced) memory, of some multiple
	 of the pagesize, that has execute permissions set.  This memory can be parcelled
	 out to individual FFICallbackThunks to hold their thunk/trampoline machine code."
	<primitive: 'primAllocateExecutablePage' module: 'IA32ABI' error: errorCode>
	^self primitiveFailed!

----- Method: FFIPlatformDescription>>abi (in category '*FFI-Callbacks') -----
abi

	| processor |
	processor := self subtype asLowercase.
	
	(processor = 'arm' or: [(processor beginsWith: 'armv') and: [processor fifth <= $7]])
		ifTrue: [^ 'ARM32'].
	(processor first = $i and: [processor = 'intel' or: ['i#86' match: processor]])
		ifTrue: [^ 'IA32'].

	(processor first = $x and: [processor = 'x64' or: [('x86#64*' match: processor)]])
		ifTrue: [^ self isWindows ifTrue: ['X64Win64'] ifFalse: ['X64']].
		
	^ 'UNKNOWN'!

ExternalObject subclass: #FFICallback
	instanceVariableNames: 'abi type evaluableObject thunk argTypes'
	classVariableNames: 'ThunkToCallbackMap'
	poolDictionaries: ''
	category: 'FFI-Callbacks'!

----- Method: FFICallback class>>cdeclQsort:with:with:with: (in category 'examples') -----
cdeclQsort: values with: number with: width with: callback

	<cdecl: void 'qsort' (void* size_t size_t void*) module: 'msvcrt.dll'>
	^ self externalCallFailed!

----- Method: FFICallback class>>evaluateCallbackForContext: (in category 'instance lookup') -----
evaluateCallbackForContext: callbackContext "<FFIallbackContext> ^<Integer> typeCode"

	(ThunkToCallbackMap
		at: callbackContext thunkp getHandle
		ifAbsent: [^self error: 'could not locate Callback instance corresponding to thunk address'])
		ifNil: [self error: 'Callback instance for this thunk address has been garbage collected']
		ifNotNil:
			[:callback|
			^callback valueInContext: callbackContext]!

----- Method: FFICallback class>>exampleCqsort (in category 'examples') -----
exampleCqsort
	"Call the libc qsort function (which requires a callback)."
	"FFICallback exampleCqsort"
	"(Time millisecondsToRun: [100 timesRepeat: [FFICallback exampleCqsort]]) / 100.0"

	| type cb rand nElements sizeofDouble values orig sort libcName knownLibcNames fn |

	knownLibcNames := #('libobjc.dylib' 'libgcc_s.1.dylib' 'libc.dylib' 'libc.so.6' 'libc.so' 'msvcrt.dll').
	libcName := Project uiManager chooseFrom: knownLibcNames title: 'Choose your libc'.
	libcName = 0 ifTrue: [^ self].
	libcName := knownLibcNames at: libcName.

	rand := Random new.
	type := ExternalType double.
	sizeofDouble := type byteSize.
	nElements := 10.
	values := ExternalData
		fromHandle: (ExternalAddress allocate: nElements * sizeofDouble)
		type: type asPointerType.
	"Initialize external data and set size for enumeration."
	1 to: nElements do: [:i| values at: i put: rand next].
	values size: nElements.
	"Fetch a local copy of the external data."
	orig := values collect: [:each | each].
	
	"Construct the callback structure."
	cb := FFICallback
			signature: '<callback: int (*)(double* double*)>'
			"signature: #(int 'double*' 'double*')"
			block: [ :arg1 :arg2 |
				| a  b |
				a := arg1 doubleAt: 1.
				b := arg2 doubleAt: 1.
				Transcript showln: ('Comparing {1} and {2}' format: {a. b}).
				self halt.
				 (a - b) sign].
	
	"void qsort( void *base, size_t number, size_t width, int (__cdecl *compare )(const void *, const void *) );"
	fn := ExternalLibraryFunction
		name: 'qsort' module: libcName
		callType: ExternalLibraryFunction callTypeCDecl
		returnType: ExternalType void
		argumentTypes: (ExternalType lookupTypes: #('void*' size_t size_t 'void*')).
	
	"Invoke!!"
	fn invokeWith: values "getHandle" with: nElements with: sizeofDouble with: cb thunk "getHandle".
	
	sort := values collect: [:each | each].
	values getHandle free.
	^orig -> sort!

----- Method: FFICallback class>>exampleCqsortThree (in category 'examples') -----
exampleCqsortThree
	"Call the libc qsort function (which requires a callback)."
	"
	FFICallback exampleCqsortThree
	"
	"(Time millisecondsToRun: [100 timesRepeat: [FFICallback exampleCqsort]]) / 100.0"

	| type rand nElements sizeofDouble values orig sort cb |

	rand := Random new.
	type := ExternalType double.
	sizeofDouble := type byteSize.
	nElements := 10.
	values := ExternalData
		fromHandle: (ExternalAddress allocate: nElements * sizeofDouble)
		type: type asPointerType.
	"Initialize external data and set size for enumeration."
	1 to: nElements do: [:i| values at: i put: rand next].
	values size: nElements.
	"Fetch a local copy of the external data."
	orig := values collect: [:each | each].
		
	"Construct the callback structure."
	cb := FFICallback
			signature: '<callback: int (*)(double* double*)>'
			"signature: #(int 'double*' 'double*')"
			block: [ :arg1 :arg2 |
				| a  b |
				a := arg1 doubleAt: 1.
				b := arg2 doubleAt: 1.
				Transcript showln: ('Comparing {1} and {2}' format: {a. b}).
				self halt.
				 (a - b) sign].
	
		
	"Invoke!!"
	self
		cdeclQsort: values  with: nElements with: sizeofDouble
		with: cb thunk.
	
	sort := values collect: [:each | each].
	values getHandle free.
	^orig -> sort!

----- Method: FFICallback class>>exampleCqsortTwo (in category 'examples') -----
exampleCqsortTwo
	"Call the libc qsort function (which requires a callback)."
	"
	FFICallback exampleCqsortTwo
	"
	"(Time millisecondsToRun: [100 timesRepeat: [FFICallback exampleCqsort]]) / 100.0"

	| type rand nElements sizeofDouble values orig sort |

	rand := Random new.
	type := ExternalType double.
	sizeofDouble := type byteSize.
	nElements := 10.
	values := ExternalData
		fromHandle: (ExternalAddress allocate: nElements * sizeofDouble)
		type: type asPointerType.
	"Initialize external data and set size for enumeration."
	1 to: nElements do: [:i| values at: i put: rand next].
	values size: nElements.
	"Fetch a local copy of the external data."
	orig := values collect: [:each | each].
		
	"Invoke!!"
	self
		qsort: values  with: nElements with: sizeofDouble
		with:  [ :arg1 :arg2 |
				| a  b |
				a := arg1 doubleAt: 1.
				b := arg2 doubleAt: 1.
				Transcript showln: ('Comparing {1} and {2}' format: {a. b}).
				self halt.
				 (a - b) sign].
	
	sort := values collect: [:each | each].
	values getHandle free.
	^orig -> sort!

----- Method: FFICallback class>>getIntWithData:withData: (in category 'examples - signatures') -----
getIntWithData: anExternalData1 withData: anExternalData2
	"
	(FFICallback class >> #getIntWithData:withData:) pragmaAt: #callback:
	"
	<callback: int (*)(void* void*)>
	
	self shouldNotImplement.!

----- Method: FFICallback class>>getIntWithData:withData:withInt:withInt: (in category 'examples - signatures') -----
getIntWithData: anExternalData1 withData: anExternalData2 withInt: anInteger1 withInt: anInteger2
	"
	(FFICallback class >> #getIntWithData:withData:withInt:withInt:) pragmaAt: #callback:
	"
	<callback: int (*)(void* void* uint32_t intptr_t)>
	
	self shouldNotImplement.
	
	
	self flag: #todo: "Ignore macros, const, and '*,' comma"
	"<signature: #(int CALLBACK (*)(const LOGFONT *, const TEXTMETRIC *, DWORD, LPARAM))>"
!

----- Method: FFICallback class>>getIntWithInt:withString: (in category 'examples - signatures') -----
getIntWithInt: anInteger withString: aString
	"
	(FFICallback class >> #getIntWithInt:withString:) pragmaAt: #callback:
	"
	<callback: int (*)(int char *)>

	self shouldNotImplement.!

----- Method: FFICallback class>>getVoidWithData:withDouble:withDouble: (in category 'examples - signatures') -----
getVoidWithData: anExternalData withDouble: aFloat withDouble: anotherFloat
	"
	(FFICallback class >> #getVoidWithData:withDouble:withDouble:) pragmaAt: #callback:
	"
	<callback: void (*)(void* double double)>
	
	self shouldNotImplement.!

----- Method: FFICallback class>>initialize (in category 'class initialization') -----
initialize

	ThunkToCallbackMap := WeakValueDictionary new.!

----- Method: FFICallback class>>maxThunkSize (in category 'constants') -----
maxThunkSize
	"see FFICallbackThunk initialize & initializeStdcall:; must be big enough for the largest thunk created"
	^ 40!

----- Method: FFICallback class>>message: (in category 'instance creation') -----
message: message "<MessageSend> ^<FFICallback>"
	^ self new
		setMessage: message
!

----- Method: FFICallback class>>qsort:with:with:with: (in category 'examples') -----
qsort: values with: number with: width with: block
	"Indirection to define the signature for the provided block."
	<callback: int (*)(double* double*)>
	
	| callback |
	callback := FFICallback
		signature: ((thisContext method pragmaAt: #callback:) argumentAt: 1)
		block: block.
			
	^ self cdeclQsort: values with: number with: width with: callback thunk!

----- Method: FFICallback class>>signature:block: (in category 'instance creation') -----
signature: signature "<String>" block: aBlock "<BlockClosure> ^<FFICallback>"
	^ self new
		setBlock: aBlock
		signature: signature!

----- Method: FFICallback class>>signature:message: (in category 'instance creation') -----
signature: signature "<String>" message: message "<MessageSend> ^<FFICallback>"
	^ self new
		setMessage: message
		signature: signature!

----- Method: FFICallback>>evaluateDynamic: (in category 'callback - evaluators') -----
evaluateDynamic: callbackContext
	"Read all arguments and make the call(back). Assume that 'handle' and 'type' are set correctly. Only watch out for the sign. See field definition in FFICallbackContext to explore alternative ways to read the arguments."
		
	| offset args |
	offset := 1.	
	args := Array new: argTypes size - 1. "Skip return type"
	
	1 to: args size do: [:argIndex |
		| argType unsigned data |
		argType := argTypes at: argIndex + 1. "Skip return type"
		
		argType isPointerType
			ifTrue: [	
				data := (type handle: handle at: offset).
				
				argType referentClass "pointer to atomic"
					ifNil: [data := data asType: argType]
					ifNotNil: [:structClass | "pointer to external structure or union"
						argType isTypeAliasToPointer
							ifTrue: [data := structClass fromHandle: data getHandle asByteArrayPointer]
							ifFalse: [data := structClass fromHandle: data getHandle]] ]
			ifFalse: [ "non-pointer type"
				self flag: #floats. "mt: When should we switch to callbackContext floatRegArgs?"
				self flag: #todo. "mt: How to make boolean out of integer here? Would it work with floats, too?"
				unsigned := argType isIntegerType ==> [argType isUnsigned].
				data := unsigned
						ifTrue: [type asUnsigned handle: handle at: offset]
						ifFalse: [type asSigned handle: handle at: offset].

				argType isAtomic
					ifFalse: ["structure type, most likely type alias to pointer"
						data := argType referentClass
							fromHandle: (ExternalAddress fromInteger: data) asByteArrayPointer]
					ifTrue: [ argType isTypeAlias
						ifTrue: [ "alias to atomic type"
							data := argType referentClass fromHandle: data]
						ifFalse: [ "atomic, non-pointer type"
							data := data ";-)"]] ].
				
		args at: argIndex put: data.
		offset := offset + type byteSize].
	
	^ self
		setResult: (evaluableObject valueWithArguments: args)
		inContext: callbackContext.!

----- Method: FFICallback>>evaluateDynamic_ARM32: (in category 'callback - evaluators') -----
evaluateDynamic_ARM32: callbackContext
	"Set handle to access arguments as most appropriate for the ABI. For ''RISCs'' it is the pointer to the integer register."
	<abi: 'ARM32'> <evaluator>
	
	self setArgData: callbackContext intRegArgs.
	^ self evaluateDynamic: callbackContext!

----- Method: FFICallback>>evaluateDynamic_IA32: (in category 'callback - evaluators') -----
evaluateDynamic_IA32: callbackContext
	"Set handle to access arguments as most appropriate for the ABI. For x86 (i.e. IA32) it is the stack pointer."
	<abi: 'IA32'> <evaluator>
	
	self setArgData: callbackContext stackPtr.
	^ self evaluateDynamic: callbackContext!

----- Method: FFICallback>>evaluateDynamic_X64: (in category 'callback - evaluators') -----
evaluateDynamic_X64: callbackContext
	"Set handle to access arguments as most appropriate for the ABI. For ''RISCs'' it is the pointer to the integer register."
	<abi: 'X64'> <evaluator>
	
	self setArgData: callbackContext intRegArgs.
	^ self evaluateDynamic: callbackContext!

----- Method: FFICallback>>evaluateDynamic_X64Win64: (in category 'callback - evaluators') -----
evaluateDynamic_X64Win64: callbackContext
	"Set handle to access arguments as most appropriate for the ABI. For ''RISCs'' it is the pointer to the integer register."
	<abi: 'X64Win64'> <evaluator>
	
	self setArgData: callbackContext intRegArgs.
	^ self evaluateDynamic: callbackContext!

----- Method: FFICallback>>init__ccall (in category 'initialization - thunk prepare') -----
init__ccall
	"Initialize the receiver with a __ccall thunk."

	FFICallback methodsDo: [:method |
		(method selector beginsWith: 'init__ccall') ifTrue: [
			(method hasPragma: #init) ifTrue: [
				(method pragmaAt: #abi:)
					ifNotNil: [:pragma | (pragma argumentAt: 1) = abi
						ifTrue: [^ self executeMethod: method]]]]].

	self error: 'Could not initialize thunk for current ABI: ', abi.!

----- Method: FFICallback>>init__ccall_ARM32 (in category 'initialization - thunk prepare') -----
init__ccall_ARM32
	<abi: 'ARM32'> <init>
	"Initialize the receiver with a __ccall thunk.  The thunk calls thunkEntry in the IA32ABI plugin,
	 whose source is in platforms/Cross/plugins/IA32ABI/arm32abicc.c.  thunkEntry is the entry point
	 for Callbacks. The objective of the thunk is to call thunkEntry with all arguments to the call of the
	 thunk (registers and stack) as well as a pointer to the thunk itself.  thunkEntry is as follows:
	
		long long
		thunkEntry(long r0, long r1, long r2, long r3,
		            double d0, double d1, double d2, double d3,
		            double d4, double d5, double d6, double d7,
		            void *thunkpPlus16, sqIntptr_t *stackp)

	thunkEntry then collects the various arguments (thunk, integer register arguments, floating-point
	register arguments, stack pointer) in a VMCallbackContext and invokes the callback via invokeCallbackContext:."

	"0x0 <thunk+0>:		mov     r12, sp			; 0xe1a0c00d
 	 0x4 <thunk+4>:		sub     sp, sp, #16		; 0xe24dd010
 	 0x8 <thunk+8>:		str     pc, [sp, #0]		; 0xe58df000 N.B. passes thunk+16; thunkEntry compensates
 	 0xc <thunk+12>:		str     r12, [sp,#4]		; 0xe58dc004
 	 0x10 <thunk+16>:	str     lr, [sp, #12]		; 0xe58de00c
 	 0x14 <thunk+20>:	ldr     r12, [pc, #8]		; 0xe59fc008
 	 0x18 <thunk+24>:	blx     r12				; 0xe12fff3c
 	 0x1c <thunk+28>:	add     sp, sp, #12		; 0xe28dd00c
 	 0x20 <thunk+32>:	ldr     pc, [sp], #4!!		; 0xe49df004 ; pop     {pc}
 	 0x24 <thunk+36>:     .word thunkEntry"
	self flag: #hidden. "mt: How is the thunk's handle stored to lookup this instance upon callback later?"
	thunk getHandle
		unsignedLongAt:   1 put: 16re1a0c00d;
		unsignedLongAt:   5 put: 16re24dd010;
		unsignedLongAt:   9 put: 16re58df000;
		unsignedLongAt: 13 put: 16re58dc004;
		unsignedLongAt: 17 put: 16re58de00c;
		unsignedLongAt: 21 put: 16re59fc008;
		unsignedLongAt: 25 put: 16re12fff3c;
		unsignedLongAt: 29 put: 16re28dd00c;
		unsignedLongAt: 33 put: 16re49df004;
		shortPointerAt: 37 put: self thunkEntryAddress.!

----- Method: FFICallback>>init__ccall_IA32 (in category 'initialization - thunk prepare') -----
init__ccall_IA32
	<abi: 'IA32'> <init>
	"Initialize the receiver with a __ccall thunk.  The thunk calls thunkEntry in the IA32ABI plugin,
	 whose source is in platforms/Cross/plugins/IA32ABI/x64win64abicc.c.  thunkEntry is the entry point
	 for Callbacks. The objective of the thunk is to call thunkEntry with all arguments to the call of the
	 thunk (registers and stack) as well as a pointer to the thunk itself.  thunkEntry is as follows:

		long
		thunkEntry(void *thunkp, sqIntptr_t *stackp)

	thunkEntry then collects the various arguments (thunk, stack pointer) in a VMCallbackContext and
	invokes the callback via invokeCallbackContext:."

	"thunk:		push   %esp				0x54							0xa1905454
	 thunk+01:	push   %esp				0x54
	 thunk+02:	nop   						0x90
	 thunk+03:	mov    $thunkEntry,%eax	0xb8 0x00 0x00 0x00 0x00	0x00000000 - entry
	 thunk+08:	nop   						0x90							0x68909090
	 thunk+09:	nop   						0x90
	 thunk+10:	nop   						0x90
	 thunk+11:	push   $thunk				0x68 0x00 0x00 0x00 0x00	0x00000000 - thunk
	 thunk+16:	call   *%eax					0xff 0xd0						0xc483d0ff
	 thunk+18:	add    $0xC,%esp			0x83 0xc4 0x0C				0x9090c30C
	 thunk+21:	ret							0xc3
	 thunk+22:	nop							0x90
	 thunk+23:	nop							0x90"
	thunk getHandle
		unsignedLongAt:  1 put: 16rB8905454;
		shortPointerAt: 5 put: self thunkEntryAddress;
		unsignedLongAt:  9 put: 16r68909090;
		shortPointerAt: 13 put: thunk getHandle;
		unsignedLongAt: 17 put: 16rC483D0FF;
		unsignedLongAt: 21 put: 16r9090C30C!

----- Method: FFICallback>>init__ccall_X64 (in category 'initialization - thunk prepare') -----
init__ccall_X64
	<abi: 'X64'> <init>
	"Initialize the receiver with a __ccall thunk.  The thunk calls thunkEntry in the IA32ABI plugin,
	 whose source is in platforms/Cross/plugins/IA32ABI/x64sysvabicc.c.  thunkEntry is the entry point
	 for Callbacks. The objective of the thunk is to call thunkEntry with all arguments to the call of the
	 thunk (registers and stack) as well as a pointer to the thunk itself.  thunkEntry is as follows:

		long
		thunkEntry(long a0, long a1, long a2, long a3, long a4, long a5,
		            double d0, double d1, double d2, double d3,
		            double d4, double d5, double d6, double d7,
		            void *thunkp, sqIntptr_t *stackp)

	thunkEntry then collects the various arguments (thunk, integer register arguments, floating-point
	register arguments, stack pointer) in a VMCallbackContext and invokes the callback via invokeCallbackContext:."

	"thunk+0x0:	pushq  %rsp							54
	 thunk+0x1:	pushq  %rsp							54
	 thunk+0x4:	movabsq $thunk, %rax					48 b8 b0..b7 eight bytes of thunk address a.k.a. handle
	 thunk+0xc:	pushq  %rax							50
	 thunk+0xd:	movabsq $thunkEntry, %rax			48 b8 b0..b7 eight bytes of the thunkEntry address
	 thunk+0x17:	callq  *%rax							ff d0
	 thunk+0x19:	addq   $0x18, %rsp					48 83 c4 18
	 thunk+0x1d:	retq									c3
	 thunk+0x1e:	nop										90
	 thunk+0x1f:	nop										90"
	thunk getHandle
		unsignedLongAt:		  1 put: 16rb8485454;
		longPointerAt:			  5 put: thunk getHandle;
		unsignedLongAt:		13 put: 16r00b84850; "00 is the first byte of the 64-bit constant the movabsq/0x48 opcode moves"
		longPointerAt:			16 put: self thunkEntryAddress;
		unsignedByteAt:		24 put: 16rff;
		unsignedLongAt:		25 put: 16rc48348d0;
		unsignedLongAt:		29 put: 16r9090c318.!

----- Method: FFICallback>>init__ccall_X64Win64 (in category 'initialization - thunk prepare') -----
init__ccall_X64Win64
	<abi: 'X64Win64'> <init>
	"Initialize the receiver with a __ccall thunk.  The thunk calls thunkEntry in the IA32ABI plugin,
	 whose source is in platforms/Cross/plugins/IA32ABI/x64win64abicc.c.  thunkEntry is the entry point
	 for Callbacks. The objective of the thunk is to call thunkEntry with all arguments to the call of the
	 thunk (registers and stack) as well as a pointer to the thunk itself.  thunkEntry is as follows:

		long long
		thunkEntry(long long rcx, long long rdx,
		      		long long r8, long long r9,
					void *thunkp, sqIntptr_t *stackp)

	thunkEntry then collects the various arguments (thunk, integer register arguments, stack pointer)
	in a VMCallbackContext and invokes the callback via invokeCallbackContext:."

	"thunk+0x0:	pushq  %rsp							54
	 thunk+0x1:	pushq  %rsp							54
	 thunk+0x4:	movabsq $thunk, %rax					48 b8 b0..b7 eight bytes of thunk address a.k.a. addressField
	 thunk+0xc:	pushq  %rax							50
	 thunk+0xd:	subq   $0x20, %rsp						48 83 c4 e0 (this is addq -20 since the immediate is signed extended)
	 thunk+0x11:	movabsq $thunkEntry, %rax			48 b8 b0..b7 eight bytes of the thunkEntry address
	 thunk+0x1b:	callq  *%rax							ff d0
	 thunk+0x1d:	addq   $0x38, %rsp					48 83 c4 38
	 thunk+0x21:	retq									c3
	 thunk+0x22:	nop										90
	 thunk+0x23:	nop										90"
	thunk getHandle
		unsignedLongAt:		  1 put: 16rb8485454;
		longPointerAt: 			  5 put: thunk getHandle;
		unsignedLongAt:		13 put: 16rc4834850; 
		unsignedLongAt:		17 put: 16r00b848e0; "00 is the first byte of the 64-bit constant the movabsq/0x48 opcode moves"
		longPointerAt:			20 put: self thunkEntryAddress;
		unsignedByteAt:		28 put: 16rff;
		unsignedLongAt:		29 put: 16rc48348d0;
		unsignedLongAt:		33 put: 16r9090c338.!

----- Method: FFICallback>>init__stdcall: (in category 'initialization - thunk prepare') -----
init__stdcall: numBytes
	"Initialize the receiver with a __stdcall thunk with numBytes argument bytes."

	FFICallback methodsDo: [:method |
		(method selector beginsWith: 'init__stdcall') ifTrue: [
			(method hasPragma: #init) ifTrue: [
				(method pragmaAt: #abi:)
					ifNotNil: [:pragma | (pragma argumentAt: 1) = abi
						ifTrue: [^ self with: numBytes executeMethod: method]]]]].

	self error: 'Could not initialize thunk for current ABI: ', abi.!

----- Method: FFICallback>>init__stdcall_IA32: (in category 'initialization - thunk prepare') -----
init__stdcall_IA32: numBytes
	<abi: 'IA32'> <init>
	"Initialize the receiver with a __stdcall thunk with numBytes argument bytes. (See #init__ccall_IA32 for more info)"
	"thunk:		push   %esp				0x54							0xa1905454
	 thunk+01:	push   %esp				0x54
	 thunk+02:	nop   						0x90
	 thunk+03:	mov    $thunkEntry,%eax	0xb8 0x00 0x00 0x00 0x00	0x00000000 - entry
	 thunk+08:	nop   						0x90							0x68909090
	 thunk+09:	nop   						0x90
	 thunk+10:	nop   						0x90
	 thunk+11:	push   $thunk				0x68 0x00 0x00 0x00 0x00	0x00000000 - thunk
	 thunk+16:	call   *%eax					0xff 0xd0						0xc483d0ff
	 thunk+18:	add    $0xC,%esp			0x83 0xc4 0x0C				0xBYTSc20C
	 thunk+21:	ret    $bytes				0xc2 0xBY 0xTS"

	thunk getHandle
		unsignedLongAt:  1 put: 16rB8905454;
		shortPointerAt: 5 put: self thunkEntryAddress;
		unsignedLongAt:  9 put: 16r68909090;
		shortPointerAt: 13 put: thunk getHandle;
		unsignedLongAt:  17 put: 16rC483D0FF;
		unsignedShortAt: 21 put: 16rC20C;
		unsignedShortAt: 23 put: numBytes.!

----- Method: FFICallback>>primThunkEntryAddress (in category 'initialization - thunk prepare') -----
primThunkEntryAddress "^<Integer>"
	"Answer the address of the entry-point for thunk callbacks:
		x86: long thunkEntry(void *thunkp, long *stackp);
		x64: long thunkEntry(long a, long b, long c, long d, long, e, long f,
								double d0, double d1, double d2, double d3,
								double d4, double d5, double d6, double d7,
								void *thunkp, long *stackp);
		ARM: long thunkEntry(long a, long b, long c, long d,
								double d0, double d1, double d2, double d3,
								double d4, double d5, double d6, double d7,
								void *thunkp, long *stackp);
	 etc.
	 This is the function a callback thunk/trampoline should call to initiate a callback."
	<primitive: 'primThunkEntryAddress' module: 'IA32ABI' error: errorCode>
	^self primitiveFailed!

----- Method: FFICallback>>setArgData: (in category 'callback') -----
setArgData: externalData
	
	handle := externalData getHandle.
	type := externalData externalType.	!

----- Method: FFICallback>>setArgTypes:evaluableObject: (in category 'initialization') -----
setArgTypes: externalTypes evaluableObject: blockOrMessage

	
	abi := FFIPlatformDescription current abi.
	handle := nil.
	type := nil.
	
	evaluableObject := blockOrMessage.
	argTypes := externalTypes.





	"Support for callee pop callbacks (Pascal calling convention such as the Win32 stdcall: convention) are supported using the <calleepops: N> pragma which specifies how many bytes to pop. See http://forum.world.st/Pharo-FFI-on-aarch64-arm64-td5096777.html#a5096786."
	thunk := FFICallbackMemory allocateExecutableBlock.
	self init__ccall.
	"(method pragmaAt: #calleepops:)
		ifNil: [self init__ccall]
		ifNotNil: [:pragma | self init__stdcall: (pragma argumentAt: 1)]."
		
	"numEvaluatorArgs := (evaluator := method selector) numArgs.
	self addToThunkTable"
	ThunkToCallbackMap at: thunk getHandle put: self!

----- Method: FFICallback>>setBlock: (in category 'initialization') -----
setBlock: aBlock
	"We cannot know the signature for an arbitrary block."
	
	self shouldNotImplement.!

----- Method: FFICallback>>setBlock:signature: (in category 'initialization') -----
setBlock: aBlock "<BlockClosure>" signature: signature "<String>"

	self
		setArgTypes: (ExternalType lookupTypes: signature)
		evaluableObject: aBlock.!

----- Method: FFICallback>>setMessage: (in category 'initialization') -----
setMessage: aMessageSend
	"Fetch the argTypes from <callback: ...> pragma in method."
	
	| method |
	self assert: [aMessageSend receiver notNil].
	
	method := aMessageSend receiver class lookupSelector: aMessageSend selector.
	
	self
		setArgTypes: ((method pragmaAt: #callback:) argumentAt: 1)
		evaluableObject: aMessageSend.!

----- Method: FFICallback>>setMessage:signature: (in category 'initialization') -----
setMessage: aMessageSend signature: signature
	"Override the argTypes from <callback: ...> pragma in method."
	
	self assert: [aMessageSend receiver notNil].
	
	self
		setArgTypes: (ExternalType lookupTypes: signature)
		evaluableObject: aMessageSend.!

----- Method: FFICallback>>setResult:inContext: (in category 'callback') -----
setResult: anObject inContext: aCallbackContext
	"Set the result in the callback context. Add some fast checks to detect errors."
	
	argTypes first atomicType = 0 "void"
		ifTrue: [
			"Quick exit for void return type."
			^ aCallbackContext voidResult].

	anObject isInteger
		ifTrue: [
			self assert: [argTypes first isIntegerType].
			^ aCallbackContext wordResult: anObject].

	anObject isBoolean
		ifTrue: [
			self assert: [argTypes first atomicType = 1 "bool"].
			^ aCallbackContext wordResult: anObject].		

	anObject isFloat
		ifTrue: [
			self assert: [argTypes first atomicType >= 12 "float/double"].			
			^ aCallbackContext floatResult: anObject].

	"Try to push pointer for external object."
	^ aCallbackContext externalObjectResult: anObject!

----- Method: FFICallback>>thunk (in category 'accessing') -----
thunk

"	self flag: #debugging.
	^ FFICallbackMemory new
		externalPointer: thunk getHandle;
		yourself"
	^ thunk!

----- Method: FFICallback>>thunkEntryAddress (in category 'initialization - thunk prepare') -----
thunkEntryAddress

	^ ExternalAddress fromInteger: self primThunkEntryAddress!

----- Method: FFICallback>>valueInContext: (in category 'callback') -----
valueInContext: callbackContext "<FFICallbackContext> ^<Integer>"
	
	FFICallback methodsDo: [:method |
		(method hasPragma: #evaluator) ifTrue: [
			(method pragmaAt: #abi:)
				ifNotNil: [:pragma | (pragma argumentAt: 1) = abi
					ifTrue: [^ self with: callbackContext executeMethod: method]]]].
		
	self error: 'Could find evaluator for current ABI: ', abi.!

ExternalUnion subclass: #FFICallbackResult
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'FFI-Callbacks'!

----- Method: FFICallbackResult class>>fields (in category 'field definition') -----
fields
	"
	self defineFields.
	"
	^ #(
		(booleanResult			'bool')
		(floatResult				'double')
		(positiveIntegerResult	'uintptr_t')
		(integerResult			'intptr_t')
	)!

----- Method: FFICallbackResult>>booleanResult (in category 'accessing') -----
booleanResult
	"This method was automatically generated. See FFICallbackResult class>>fields."
	<generated>
	^handle booleanAt: 1!

----- Method: FFICallbackResult>>booleanResult: (in category 'accessing') -----
booleanResult: aBoolean
	"This method was automatically generated. See FFICallbackResult class>>fields."
	<generated>
	handle booleanAt: 1 put: aBoolean!

----- Method: FFICallbackResult>>floatResult (in category 'accessing') -----
floatResult
	"This method was automatically generated. See FFICallbackResult class>>fields."
	<generated>
	^handle doubleAt: 1!

----- Method: FFICallbackResult>>floatResult: (in category 'accessing') -----
floatResult: aFloat
	"This method was automatically generated. See FFICallbackResult class>>fields."
	<generated>
	handle doubleAt: 1 put: aFloat!

----- Method: FFICallbackResult>>integerResult (in category 'accessing') -----
integerResult
	"This method was automatically generated. See FFICallbackResult class>>fields."
	<generated>
	^handle signedLongAt: 1!

----- Method: FFICallbackResult>>integerResult: (in category 'accessing') -----
integerResult: anInteger
	"This method was automatically generated. See FFICallbackResult class>>fields."
	<generated>
	handle signedLongAt: 1 put: anInteger!

----- Method: FFICallbackResult>>positiveIntegerResult (in category 'accessing') -----
positiveIntegerResult
	"This method was automatically generated. See FFICallbackResult class>>fields."
	<generated>
	^handle unsignedLongAt: 1!

----- Method: FFICallbackResult>>positiveIntegerResult: (in category 'accessing') -----
positiveIntegerResult: anInteger
	"This method was automatically generated. See FFICallbackResult class>>fields."
	<generated>
	handle unsignedLongAt: 1 put: anInteger!


From commits at source.squeak.org  Tue Jul 28 11:35:21 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Tue, 28 Jul 2020 11:35:21 0000
Subject: [squeak-dev] FFI: FFI-Callbacks-mt.2.mcz
Message-ID: <E1k0NtC-0008K9-TI@andreas>

Marcel Taeumel uploaded a new version of FFI-Callbacks to project FFI:
http://source.squeak.org/FFI/FFI-Callbacks-mt.2.mcz

==================== Summary ====================

Name: FFI-Callbacks-mt.2
Author: mt
Time: 18 June 2020, 1:26:27.021543 pm
UUID: 4baf5374-6606-fb49-876a-f097fdf20b57
Ancestors: FFI-Callbacks-mt.1

Improves basic logic of #evaluateDynamic:. Still needs either some ABI-specific rules to dynamically dispatch, e.g., floats into floatRegArgs or support for calling other evaluator methods if present to manually read the arguments.

Also fixes initial package loading by adding the missing #lookupTypes: and comment-out the example signatures for now.

=============== Diff against FFI-Callbacks-mt.1 ===============

Item was added:
+ ----- Method: ExternalType class>>lookupTypes: (in category '*FFI-Callbacks') -----
+ lookupTypes: signature
+ 	"
+ 	Supported arguments:
+ 		'<callback: int (*) (double* double*)>' ... pragma as string
+ 		#(int 'double*' 'double*') ... array with type names
+ 		{ ExternalType int. ExternalType double asPointerType. ExternalType double asPointerType } ... array with external types
+ 	"
+ 	
+ 	(signature isString and: [signature first == $<]) ifTrue: [
+ 		^ (Parser new parse: 'foo', String cr, signature class: Object)
+ 			properties pragmas first argumentAt: 1].
+ 	
+ 	signature first isString ifTrue: [
+ 		^ signature collect: [:typeName | self typeNamed: typeName]].
+ 	
+ 	signature first class == ExternalType ifTrue: [
+ 		^ signature].
+ 	
+ 	self error: 'Could not lookup external types from signature'.!

Item was changed:
  ----- Method: FFICallback class>>getIntWithData:withData: (in category 'examples - signatures') -----
  getIntWithData: anExternalData1 withData: anExternalData2
  	"
  	(FFICallback class >> #getIntWithData:withData:) pragmaAt: #callback:
  	"
+ 	"<callback: int (*)(void* void*)>"
- 	<callback: int (*)(void* void*)>
  	
  	self shouldNotImplement.!

Item was changed:
  ----- Method: FFICallback class>>getIntWithData:withData:withInt:withInt: (in category 'examples - signatures') -----
  getIntWithData: anExternalData1 withData: anExternalData2 withInt: anInteger1 withInt: anInteger2
  	"
  	(FFICallback class >> #getIntWithData:withData:withInt:withInt:) pragmaAt: #callback:
  	"
+ 	"<callback: int (*)(void* void* uint32_t intptr_t)>"
- 	<callback: int (*)(void* void* uint32_t intptr_t)>
  	
  	self shouldNotImplement.
  	
  	
  	self flag: #todo: "Ignore macros, const, and '*,' comma"
  	"<signature: #(int CALLBACK (*)(const LOGFONT *, const TEXTMETRIC *, DWORD, LPARAM))>"
  !

Item was changed:
  ----- Method: FFICallback class>>getIntWithInt:withString: (in category 'examples - signatures') -----
  getIntWithInt: anInteger withString: aString
  	"
  	(FFICallback class >> #getIntWithInt:withString:) pragmaAt: #callback:
  	"
+ 	"<callback: int (*)(int char *)>"
- 	<callback: int (*)(int char *)>
  
  	self shouldNotImplement.!

Item was changed:
  ----- Method: FFICallback class>>getVoidWithData:withDouble:withDouble: (in category 'examples - signatures') -----
  getVoidWithData: anExternalData withDouble: aFloat withDouble: anotherFloat
  	"
  	(FFICallback class >> #getVoidWithData:withDouble:withDouble:) pragmaAt: #callback:
  	"
+ 	"<callback: void (*)(void* double double)>"
- 	<callback: void (*)(void* double double)>
  	
  	self shouldNotImplement.!

Item was changed:
  ----- Method: FFICallback>>evaluateDynamic: (in category 'callback - evaluators') -----
  evaluateDynamic: callbackContext
  	"Read all arguments and make the call(back). Assume that 'handle' and 'type' are set correctly. Only watch out for the sign. See field definition in FFICallbackContext to explore alternative ways to read the arguments."
  		
  	| offset args |
  	offset := 1.	
  	args := Array new: argTypes size - 1. "Skip return type"
  	
  	1 to: args size do: [:argIndex |
+ 		| argType data |
- 		| argType unsigned data |
  		argType := argTypes at: argIndex + 1. "Skip return type"
  		
  		argType isPointerType
  			ifTrue: [	
  				data := (type handle: handle at: offset).
  				
  				argType referentClass "pointer to atomic"
  					ifNil: [data := data asType: argType]
  					ifNotNil: [:structClass | "pointer to external structure or union"
  						argType isTypeAliasToPointer
  							ifTrue: [data := structClass fromHandle: data getHandle asByteArrayPointer]
  							ifFalse: [data := structClass fromHandle: data getHandle]] ]
  			ifFalse: [ "non-pointer type"
  				self flag: #floats. "mt: When should we switch to callbackContext floatRegArgs?"
+ 				data := argType handle: handle at: offset.
- 				self flag: #todo. "mt: How to make boolean out of integer here? Would it work with floats, too?"
- 				unsigned := argType isIntegerType ==> [argType isUnsigned].
- 				data := unsigned
- 						ifTrue: [type asUnsigned handle: handle at: offset]
- 						ifFalse: [type asSigned handle: handle at: offset].
  
  				argType isAtomic
  					ifFalse: ["structure type, most likely type alias to pointer"
  						data := argType referentClass
  							fromHandle: (ExternalAddress fromInteger: data) asByteArrayPointer]
  					ifTrue: [ argType isTypeAlias
  						ifTrue: [ "alias to atomic type"
  							data := argType referentClass fromHandle: data]
  						ifFalse: [ "atomic, non-pointer type"
  							data := data ";-)"]] ].
+ 
- 				
  		args at: argIndex put: data.
+ 		offset := offset + ((type byteSize max: argType byteSize) roundUpTo: type byteSize)].
- 		offset := offset + type byteSize].
  	
  	^ self
  		setResult: (evaluableObject valueWithArguments: args)
  		inContext: callbackContext.!

Item was changed:
  ----- Method: FFICallback>>setArgTypes:evaluableObject: (in category 'initialization') -----
  setArgTypes: externalTypes evaluableObject: blockOrMessage
  
  	
  	abi := FFIPlatformDescription current abi.
  	handle := nil.
  	type := nil.
  	
  	evaluableObject := blockOrMessage.
  	argTypes := externalTypes.
  
  
  
  
  
  	"Support for callee pop callbacks (Pascal calling convention such as the Win32 stdcall: convention) are supported using the <calleepops: N> pragma which specifies how many bytes to pop. See http://forum.world.st/Pharo-FFI-on-aarch64-arm64-td5096777.html#a5096786."
  	thunk := FFICallbackMemory allocateExecutableBlock.
  	self init__ccall.
+ 	"self init__stdcall: 0."
  	"(method pragmaAt: #calleepops:)
  		ifNil: [self init__ccall]
  		ifNotNil: [:pragma | self init__stdcall: (pragma argumentAt: 1)]."
  		
  	"numEvaluatorArgs := (evaluator := method selector) numArgs.
  	self addToThunkTable"
  	ThunkToCallbackMap at: thunk getHandle put: self!


From commits at source.squeak.org  Tue Jul 28 11:37:15 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Tue, 28 Jul 2020 11:37:15 0000
Subject: [squeak-dev] FFI: FFI-Callbacks-mt.3.mcz
Message-ID: <E1k0Nv3-0008Ly-QU@andreas>

Marcel Taeumel uploaded a new version of FFI-Callbacks to project FFI:
http://source.squeak.org/FFI/FFI-Callbacks-mt.3.mcz

==================== Summary ====================

Name: FFI-Callbacks-mt.3
Author: mt
Time: 28 July 2020, 1:37:14.847011 pm
UUID: 9d6c3731-a9c3-2742-a9bb-d47d40a156d2
Ancestors: FFI-Callbacks-mt.2

Updates for FFI-Kernel-mt.119. You may need to re-generate the fields in FFICallbackContext and FFICallbackResult.

=============== Diff against FFI-Callbacks-mt.2 ===============

Item was changed:
  ----- Method: ExternalAddress class>>fromInteger: (in category '*FFI-Callbacks') -----
  fromInteger: anInteger
  	"Read the given interger as an address pointing to an external memory area."
  	
  	| buffer type |
+ 	self flag: #refactor. "Maybe: ExternalAddress new fromInteger: anInteger --- and maybe move to FFI-Kernel"
  	type := ExternalType uintptr_t.
  	buffer := ByteArray new: type byteSize.
  	type handle: buffer at: 1 put: anInteger.
  	^ buffer asExternalPointer!

Item was removed:
- ----- Method: FFICallbackContext>>floatRegArgs (in category 'accessing') -----
- floatRegArgs
- 	"This method was automatically generated. See FFICallbackContext class>>fields."
- 	<generated>
- 	^ExternalData fromHandle: (handle shortPointerAt: 13) type: ExternalType double asPointerType!

Item was removed:
- ----- Method: FFICallbackContext>>floatRegArgs: (in category 'accessing') -----
- floatRegArgs: someExternalData
- 	"This method was automatically generated. See FFICallbackContext class>>fields."
- 	<generated>
- 	handle shortPointerAt: 13 put: someExternalData getHandle.!

Item was removed:
- ----- Method: FFICallbackContext>>intRegArgs (in category 'accessing') -----
- intRegArgs
- 	"This method was automatically generated. See FFICallbackContext class>>fields."
- 	<generated>
- 	^ExternalData fromHandle: (handle shortPointerAt: 9) type: ExternalType long asPointerType!

Item was removed:
- ----- Method: FFICallbackContext>>intRegArgs: (in category 'accessing') -----
- intRegArgs: someExternalData
- 	"This method was automatically generated. See FFICallbackContext class>>fields."
- 	<generated>
- 	handle shortPointerAt: 9 put: someExternalData getHandle.!

Item was removed:
- ----- Method: FFICallbackContext>>rvs (in category 'accessing') -----
- rvs
- 	"This method was automatically generated. See FFICallbackContext class>>fields."
- 	<generated>
- 	^FFICallbackResult fromHandle: (handle structAt: 25 length: 8)!

Item was removed:
- ----- Method: FFICallbackContext>>rvs: (in category 'accessing') -----
- rvs: aFFICallbackResult
- 	"This method was automatically generated. See FFICallbackContext class>>fields."
- 	<generated>
- 	handle structAt: 25 put: aFFICallbackResult getHandle length: 8.!

Item was removed:
- ----- Method: FFICallbackContext>>stackPtr (in category 'accessing') -----
- stackPtr
- 	"This method was automatically generated. See FFICallbackContext class>>fields."
- 	<generated>
- 	^ExternalData fromHandle: (handle shortPointerAt: 5) type: ExternalType long asPointerType!

Item was removed:
- ----- Method: FFICallbackContext>>stackPtr: (in category 'accessing') -----
- stackPtr: someExternalData
- 	"This method was automatically generated. See FFICallbackContext class>>fields."
- 	<generated>
- 	handle shortPointerAt: 5 put: someExternalData getHandle.!

Item was removed:
- ----- Method: FFICallbackContext>>thunkp (in category 'accessing') -----
- thunkp
- 	"This method was automatically generated. See FFICallbackContext class>>fields."
- 	<generated>
- 	^ExternalData fromHandle: (handle shortPointerAt: 1) type: ExternalType void asPointerType!

Item was removed:
- ----- Method: FFICallbackContext>>thunkp: (in category 'accessing') -----
- thunkp: someExternalData
- 	"This method was automatically generated. See FFICallbackContext class>>fields."
- 	<generated>
- 	handle shortPointerAt: 1 put: someExternalData getHandle.!

Item was changed:
  ----- Method: FFICallbackMemory class>>unload (in category 'class initialization') -----
  unload
  
+ 	Smalltalk removeFromStartUpList: self.
+ 	Smalltalk specialObjectsArray at: 53 put: nil.!
- 	Smalltalk removeFromStartUpList: self.!

Item was changed:
  ----- Method: FFICallbackMemory>>externalPointer: (in category 'accessing') -----
  externalPointer: anExternalAddress
  
+ 	self addressFieldPut: anExternalAddress asInteger.!
- 	| type integer |
- 	self flag: #debugging.
- 	type := ExternalType uintptr_t.
- 	integer := type
- 		handle: anExternalAddress asByteArrayPointer
- 		at: 1.
- 		
- 	self addressFieldPut: integer.!

Item was removed:
- ----- Method: FFICallbackResult>>booleanResult (in category 'accessing') -----
- booleanResult
- 	"This method was automatically generated. See FFICallbackResult class>>fields."
- 	<generated>
- 	^handle booleanAt: 1!

Item was removed:
- ----- Method: FFICallbackResult>>booleanResult: (in category 'accessing') -----
- booleanResult: aBoolean
- 	"This method was automatically generated. See FFICallbackResult class>>fields."
- 	<generated>
- 	handle booleanAt: 1 put: aBoolean!

Item was removed:
- ----- Method: FFICallbackResult>>floatResult (in category 'accessing') -----
- floatResult
- 	"This method was automatically generated. See FFICallbackResult class>>fields."
- 	<generated>
- 	^handle doubleAt: 1!

Item was removed:
- ----- Method: FFICallbackResult>>floatResult: (in category 'accessing') -----
- floatResult: aFloat
- 	"This method was automatically generated. See FFICallbackResult class>>fields."
- 	<generated>
- 	handle doubleAt: 1 put: aFloat!

Item was removed:
- ----- Method: FFICallbackResult>>integerResult (in category 'accessing') -----
- integerResult
- 	"This method was automatically generated. See FFICallbackResult class>>fields."
- 	<generated>
- 	^handle signedLongAt: 1!

Item was removed:
- ----- Method: FFICallbackResult>>integerResult: (in category 'accessing') -----
- integerResult: anInteger
- 	"This method was automatically generated. See FFICallbackResult class>>fields."
- 	<generated>
- 	handle signedLongAt: 1 put: anInteger!

Item was removed:
- ----- Method: FFICallbackResult>>positiveIntegerResult (in category 'accessing') -----
- positiveIntegerResult
- 	"This method was automatically generated. See FFICallbackResult class>>fields."
- 	<generated>
- 	^handle unsignedLongAt: 1!

Item was removed:
- ----- Method: FFICallbackResult>>positiveIntegerResult: (in category 'accessing') -----
- positiveIntegerResult: anInteger
- 	"This method was automatically generated. See FFICallbackResult class>>fields."
- 	<generated>
- 	handle unsignedLongAt: 1 put: anInteger!

Item was removed:
- ----- Method: Parser>>callback (in category '*FFI-Callbacks') -----
- callback
- 	<pragmaParser>
- 	
- 	| descriptorClass retType externalName args argType |
- 	descriptorClass := ExternalFunction.
- 	"Parse return type"
- 	self advance.
- 	here = 'const' ifTrue: [self advance].
- 	retType := self externalType: descriptorClass.
- 	retType == nil ifTrue:[^self expected:'return type'].
- 	"Parse function name or index"
- 	externalName := here.
- 
- 	(self match: #leftParenthesis) ifFalse:[^self expected:'function pointer (*)'].
- 	(self matchToken: #*) ifFalse:[^self expected:'function pointer (*)'].
- 	(self match: #rightParenthesis) ifFalse:[^self expected:'function pointer (*)'].
- 
- 	(self match: #leftParenthesis) ifFalse:[^self expected:'argument list'].
- 	args := WriteStream on: Array new.
- 	[self match: #rightParenthesis] whileFalse:[
- 		here = 'const' ifTrue: [self advance].
- 		here = ',' ifTrue: [self advance].
- 		argType := self externalType: descriptorClass.
- 		argType == nil ifTrue:[^self expected:'argument'].
- 		argType isVoid & argType isPointerType not ifFalse:[args nextPut: argType]].
- 
- 	self addPragma: (Pragma keyword: #callback: arguments: {{retType}, args contents}).
- 	^true!

Item was removed:
- ----- Method: SHParserST80>>callback (in category '*FFI-Callbacks') -----
- callback
- 	<pragmaParser>
- 	
- 	self scanPast: #externalFunctionCallingConvention.	
- 	
- 	self scanPast: #externalCallType.
- 	currentToken = '*' 
- 		ifTrue: [self scanPast: #externalCallTypePointerIndicator].
- 
- 	currentTokenFirst == $( ifFalse: [^ self fail]. self scanNext.
- 	currentTokenFirst == $* ifFalse: [^ self fail]. self scanNext.
- 	currentTokenFirst == $) ifFalse: [^ self fail]. self scanNext.
- 		
- 	self failUnless: currentTokenFirst == $(.
- 	self scanPast: #leftParenthesis.
- 	[currentTokenFirst ~= $)] 
- 		whileTrue: [
- 			self failUnless: currentToken notNil.
- 			self scanPast: #externalCallType.
- 			currentToken = '*' 
- 				ifTrue: [self scanPast: #externalCallTypePointerIndicator]].
- 	self scanPast: #rightParenthesis.
- 	currentToken = 'module:' 
- 		ifTrue: [
- 			self scanPast: #module.
- 			self parseStringOrSymbol ].
- 	currentToken = 'error:' ifTrue: [
- 		self scanPast: #primitive. "there's no rangeType for error"
- 		self currentTokenType == #name
- 			ifTrue: [ self parseTemporary: #patternTempVar ]
- 			ifFalse: [ self parseStringOrSymbol ] ].
- 	self failUnless: currentToken = '>'.
- 	self scanPast: #primitiveOrExternalCallEnd!


From tim at rowledge.org  Tue Jul 28 16:24:07 2020
From: tim at rowledge.org (tim Rowledge)
Date: Tue, 28 Jul 2020 09:24:07 -0700
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <Mailbird-5a917cfd-b081-4d8e-8b22-f99af588ef9f@hpi.de>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
 <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>
 <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>
 <CAC20JE1_PPhtdyqUj99q_4SJeRwcQaYBUrX5OLBXwihLxRp65A@mail.gmail.com>
 <CADTxDUiae3oWkSNZ49c3KJQPyX21YAVpu3q42EJvvjCXywoTZg@mail.gmail.com>
 <Mailbird-5a917cfd-b081-4d8e-8b22-f99af588ef9f@hpi.de>
Message-ID: <7B80C97D-FE20-4AFA-9E9A-76A5334BC717@rowledge.org>



> On 2020-07-28, at 12:01 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> Hi Eliot, hi Chris,
> 
> what about adding the preference #sortMonticelloRepositoriesAlphabetically like we have #sortMessageCategoriesAlphabetically ?

How about adding sorting to the list *view* morphs instead? Being able to have sorting for name/date/size/colour/whatever in generic list morphs would be pretty helpful.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: HEM: Hide Evidence of Malfunction



From vanessa at codefrau.net  Tue Jul 28 17:33:57 2020
From: vanessa at codefrau.net (Vanessa Freudenberg)
Date: Tue, 28 Jul 2020 10:33:57 -0700
Subject: [squeak-dev] Rounding in MatrixTransform2x3
In-Reply-To: <338f01a9-a5a3-eb4a-2369-f1f06723f9c8@stlutz.net>
References: <338f01a9-a5a3-eb4a-2369-f1f06723f9c8@stlutz.net>
Message-ID: <CAOWGXNBs2bX6dXhjuf7ss3NCxm10hNvrj2D+40f9WvOHG=6CFQ@mail.gmail.com>

On Tue, Jul 28, 2020 at 4:34 AM Stephan Lutz <dev at stlutz.net> wrote:

> While transforming points using MatrixTransform2x3 we noticed some strange
> rounding behavior:
>
> "with plugin"
> (MatrixTransform2x3 withOffset: 5 @ 10) localPointToGlobal: 0 at 0. "5 at 10"
> (MatrixTransform2x3 withOffset: -5 @ -10) localPointToGlobal: 0 at 0. "-4@
> -9"
>
> "without plugin"
> ((MatrixTransform2x3 withOffset: 5 @ 10) transformPoint: 0 at 0) rounded.
> "5 at 10"
> ((MatrixTransform2x3 withOffset: -5 @ -10) transformPoint: 0 at 0) rounded.
> "-5@ -10"
>
> It appears the code used to round in the plugin simply adds 0.5 and
> truncates the result, which does not work correctly for negative numbers.
> This code can be found in Matrix2x3Plugin >> #roundAndStoreResultPoint:
> and Matrix2x3Plugin >> #roundAndStoreResultRect:x0:y0:x1:y1: .
>
> ----
>
> On a kind of related note: Is there even a reason to round the resulting
> floats?
>
> While the class comment of MatrixTransform2x3 notes that this behavior is
> intentional, glancing quickly over its uses we could not find anything
> taking advantage or benefiting from it. It's also not a limitation of the
> DisplayTransform interface, since MorphicTransform does produce floating
> point values. Wouldn't it be much more versatile and easier to leave
> rounding to users if they actually need it?
>
No. Having a float result means that the primitive would need to allocate
two Float objects. Any allocation can fail due to memory exhaustion. So the
primitive would have to be made to retry the allocation after running a
garbage collection.

Secondly, its results are primarily used to set up a WarpBlt IIRC, for
drawing rotated user objects in Etoys. WarpBlt fails if the coords are not
integers. The failure code rounds the numbers and retries. Doing the
rounding in the matrix primitives ensured a fast path to rendering - that's
why it was done that way.

So, there are very good reasons why the plugin returns integers. And there
are Squeak VMs where this still is a very reasonable behavior. It also
would be a good idea to document the reasoning in the class comment
of MatrixTransform2x3.

That being said, there is virtually no reason to use it when running on
Cog, much less Sista, especially on 64 bits where we have immediate floats.
An interesting thing would be to compare a pure Smalltalk implementation to
the performance of the plugin. If you need floating point transform
results, just write it in Smalltalk, would be my suggestion.

- Vanessa -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/f7f051c0/attachment.html>

From ron at usmedrec.com  Tue Jul 28 17:55:39 2020
From: ron at usmedrec.com (Ron Teitelbaum)
Date: Tue, 28 Jul 2020 13:55:39 -0400
Subject: [squeak-dev] Rounding in MatrixTransform2x3
In-Reply-To: <CAOWGXNBs2bX6dXhjuf7ss3NCxm10hNvrj2D+40f9WvOHG=6CFQ@mail.gmail.com>
References: <338f01a9-a5a3-eb4a-2369-f1f06723f9c8@stlutz.net>
 <CAOWGXNBs2bX6dXhjuf7ss3NCxm10hNvrj2D+40f9WvOHG=6CFQ@mail.gmail.com>
Message-ID: <CAEzdQ-d9Tc0gFrXZKsDwXn-vw2KupuQsXdJWxz6cnCu_eLti7w@mail.gmail.com>

>> On Tue, Jul 28, 2020 at 4:34 AM Stephan Lutz <dev at stlutz.net>
>>It appears the code used to round in the plugin simply adds 0.5 and
truncates the result, which does not work correctly for negative numbers.
>>This code can be found in Matrix2x3Plugin >> #roundAndStoreResultPoint:
and Matrix2x3Plugin >> #roundAndStoreResultRect:x0:y0:x1:y1: .
Rounding up for negative numbers is wrong.

  (MatrixTransform2x3 withOffset: -5 @ -10) localPointToGlobal: 0 at 0. "-4@
-9"

All the best,

Ron Teitelbaum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/9a867906/attachment.html>

From karlramberg at gmail.com  Tue Jul 28 18:31:11 2020
From: karlramberg at gmail.com (karl ramberg)
Date: Tue, 28 Jul 2020 20:31:11 +0200
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <Mailbird-9111f0d5-1b47-4c3b-b331-bed36255f6f3@hpi.de>
References: <Mailbird-98a3d41c-0d1f-45ca-911e-8e1eb6f5e1c6@hpi.de>
 <C87BE406-5841-4C6E-B7BC-D9254CD66004@gmail.com>
 <Mailbird-87eb61d0-30c1-49ad-80bd-4ace0ac173ad@hpi.de>
 <Mailbird-9111f0d5-1b47-4c3b-b331-bed36255f6f3@hpi.de>
Message-ID: <CAGzzWLg_Cz_ORU+8fj0CQoyydvXgEGOf9nAuNSf-sQa5aoL1EA@mail.gmail.com>

Who can update so that new bundles from http://files.squeak.org/trunk/ uses
new VM ?

Best,
Karl

On Mon, Jul 27, 2020 at 10:47 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Works:
>
> Best,
> Marcel
>
> Am 23.07.2020 13:41:17 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> Hmm... AppVeyor is just for the Windows builds. We might want to do a beta
> release for such crucial fixes and then point to the GitHub releases page?
>
> Best,
> Marcel
>
> Am 22.07.2020 19:50:31 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>
> 
> Hi Eliot,
>
> looks good. In "About Squeak", we point to "Visit
> https://github.com/OpenSmalltalk/opensmalltalk-vm".
>
>
> Should we augment that with a direct pointer to the Appveyor CI server?
>
>
> Best,
> Marcel
>
> Am 22.07.2020 16:41:08 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
> 
>
> On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
>
> 
> Hi Levente.
>
> > I'm thinking about checking the VM version in the preamble of the
> package
> > and raising a Warning when it clearly lacks the required updates.
> > Users can still continute with a Warning or terminate the update process,
> > while cli tools will act as if an error had occured.
>
> +1
>
> A one-liner would be nice. The warning should also (roughly) point to the
> location of the new VM for download.
>
> MCMcmUpdater checkVM: 202003021730. "and newer"
>
>
> I wrote it like this:
>
>  "Use of the Spur FloatArray>>at:[put:] prims requires at least
> VMMaker.oscog.2778"
>
> Smalltalk vmVMMakerVersion < 2778 ifTrue:
>     [Warning signal: 'This virtual machine is too old to support correct
> versions of the FloatArray>>at:[put:] primitives 238 and 239.  FloatArray
> subclasses will not behave correctly and FloatArray[64]Test tests will
> fail.  Please upgrade your VM.  You may continue and upgrade later or abort
> and upgrade now.']!
>
> Best,
> Marcel
>
> Am 21.07.2020 20:21:39 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
> Hi Eliot,
>
> On Mon, 20 Jul 2020, Eliot Miranda wrote:
>
> > Hi All,
> >     I've just found and fixed a VM bug in an as-yet-unpublished pair of
> primitives that replace FloatArrayPlugin>>primitiveAt[Put] and
> Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows
> two methods
> > (at:[put:]) in FloatArray to relace four methods
> (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times
> faster than the plugin methods.  The issue is when to publish the
> corrections to trunk.
> > Since the existing VM is broken I don't want to simply push to trunk and
> have people inconvenienced by a sudden emergence of failures in the
> FoatArrayTests.  However, I do want to push the corrections soon, because
> they're a
> > substantial improvement.  So the question is how long should I wait?
> >
> > Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do
> people using trunk keep an eye on the CI builds and upgrade, or would they
> appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and
> ask that you upgrade your VM.
>
> I think most people don't update their VMs often. I still tend to fire
> up the one shipped with the 5.3 release. So, IMO the question is not how
> long to wait but what to do when things are about to break.
> I presume that without updating the VM, the image would not work properly.
> So, I think the best would be if the user were warned during the update
> if the VM would be incompatible with the changes.
> I'm thinking about checking the VM version in the preamble of the package
> and raising a Warning when it clearly lacks the required updates.
> Users can still continute with a Warning or terminate the update process,
> while cli tools will act as if an error had occured.
>
>
> Levente
>
> > _,,,^..^,,,_
> > best, Eliot
> >
> >
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/9dad89b0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 86521 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/9dad89b0/attachment-0001.png>

From lists at fniephaus.com  Tue Jul 28 19:09:53 2020
From: lists at fniephaus.com (Fabio Niephaus)
Date: Tue, 28 Jul 2020 21:09:53 +0200
Subject: [squeak-dev] trunk and new vm etiquette
In-Reply-To: <CAGzzWLg_Cz_ORU+8fj0CQoyydvXgEGOf9nAuNSf-sQa5aoL1EA@mail.gmail.com>
References: <Mailbird-98a3d41c-0d1f-45ca-911e-8e1eb6f5e1c6@hpi.de>
 <C87BE406-5841-4C6E-B7BC-D9254CD66004@gmail.com>
 <Mailbird-87eb61d0-30c1-49ad-80bd-4ace0ac173ad@hpi.de>
 <Mailbird-9111f0d5-1b47-4c3b-b331-bed36255f6f3@hpi.de>
 <CAGzzWLg_Cz_ORU+8fj0CQoyydvXgEGOf9nAuNSf-sQa5aoL1EA@mail.gmail.com>
Message-ID: <CADfnKi716=VpyMRt77HOnv-OdVrLO28GmR+pOUG=39eYAqvhQw@mail.gmail.com>

On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg <karlramberg at gmail.com> wrote:

> Who can update so that new bundles from http://files.squeak.org/trunk/
> uses new VM ?
>

I can do that, but I wonder whether there should be a new VM release? I
haven't fully followed the discussion: are the changes backwards compatible?

Fabio


> Best,
> Karl
>
> On Mon, Jul 27, 2020 at 10:47 AM Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
>
>> Works:
>>
>> Best,
>> Marcel
>>
>> Am 23.07.2020 13:41:17 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>> Hmm... AppVeyor is just for the Windows builds. We might want to do a
>> beta release for such crucial fixes and then point to the GitHub releases
>> page?
>>
>> Best,
>> Marcel
>>
>> Am 22.07.2020 19:50:31 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>
>> On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <marcel.taeumel at hpi.de>
>> wrote:
>>
>> 
>> Hi Eliot,
>>
>> looks good. In "About Squeak", we point to "Visit
>> https://github.com/OpenSmalltalk/opensmalltalk-vm".
>>
>>
>> Should we augment that with a direct pointer to the Appveyor CI server?
>>
>>
>> Best,
>> Marcel
>>
>> Am 22.07.2020 16:41:08 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>> 
>>
>> On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <marcel.taeumel at hpi.de>
>> wrote:
>>
>> 
>> Hi Levente.
>>
>> > I'm thinking about checking the VM version in the preamble of the
>> package
>> > and raising a Warning when it clearly lacks the required updates.
>> > Users can still continute with a Warning or terminate the update
>> process,
>> > while cli tools will act as if an error had occured.
>>
>> +1
>>
>> A one-liner would be nice. The warning should also (roughly) point to the
>> location of the new VM for download.
>>
>> MCMcmUpdater checkVM: 202003021730. "and newer"
>>
>>
>> I wrote it like this:
>>
>>  "Use of the Spur FloatArray>>at:[put:] prims requires at least
>> VMMaker.oscog.2778"
>>
>> Smalltalk vmVMMakerVersion < 2778 ifTrue:
>>     [Warning signal: 'This virtual machine is too old to support correct
>> versions of the FloatArray>>at:[put:] primitives 238 and 239.  FloatArray
>> subclasses will not behave correctly and FloatArray[64]Test tests will
>> fail.  Please upgrade your VM.  You may continue and upgrade later or abort
>> and upgrade now.']!
>>
>> Best,
>> Marcel
>>
>> Am 21.07.2020 20:21:39 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
>> Hi Eliot,
>>
>> On Mon, 20 Jul 2020, Eliot Miranda wrote:
>>
>> > Hi All,
>> >     I've just found and fixed a VM bug in an as-yet-unpublished pair of
>> primitives that replace FloatArrayPlugin>>primitiveAt[Put] and
>> Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows
>> two methods
>> > (at:[put:]) in FloatArray to relace four methods
>> (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times
>> faster than the plugin methods.  The issue is when to publish the
>> corrections to trunk.
>> > Since the existing VM is broken I don't want to simply push to trunk
>> and have people inconvenienced by a sudden emergence of failures in the
>> FoatArrayTests.  However, I do want to push the corrections soon, because
>> they're a
>> > substantial improvement.  So the question is how long should I wait?
>> >
>> > Is it OK if I push the fixes to FloatArray and subclasses in a week?
>> Do people using trunk keep an eye on the CI builds and upgrade, or would
>> they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
>> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and
>> ask that you upgrade your VM.
>>
>> I think most people don't update their VMs often. I still tend to fire
>> up the one shipped with the 5.3 release. So, IMO the question is not how
>> long to wait but what to do when things are about to break.
>> I presume that without updating the VM, the image would not work
>> properly.
>> So, I think the best would be if the user were warned during the update
>> if the VM would be incompatible with the changes.
>> I'm thinking about checking the VM version in the preamble of the package
>> and raising a Warning when it clearly lacks the required updates.
>> Users can still continute with a Warning or terminate the update process,
>> while cli tools will act as if an error had occured.
>>
>>
>> Levente
>>
>> > _,,,^..^,,,_
>> > best, Eliot
>> >
>> >
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/d5227f36/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 86521 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/d5227f36/attachment-0001.png>

From forums.jakob at resfarm.de  Tue Jul 28 19:19:33 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Tue, 28 Jul 2020 21:19:33 +0200
Subject: [squeak-dev] The Trunk: Monticello-cmm.726.mcz
In-Reply-To: <7B80C97D-FE20-4AFA-9E9A-76A5334BC717@rowledge.org>
References: <E1jqOcu-0007f7-QP@andreas>
 <CANzdToGjXQe=4hfsHULR_KG1AsUct5CpkE-uCaBS2WKBM2i=7Q@mail.gmail.com>
 <alpine.DEB.2.02.2007010257530.2544@login03.caesar.elte.hu>
 <CADTxDUgg-NC3e92BXUSEm=Tv_BRGymBxxoNHmSZon3C8HY-Z8Q@mail.gmail.com>
 <CAC20JE1_PPhtdyqUj99q_4SJeRwcQaYBUrX5OLBXwihLxRp65A@mail.gmail.com>
 <CADTxDUiae3oWkSNZ49c3KJQPyX21YAVpu3q42EJvvjCXywoTZg@mail.gmail.com>
 <Mailbird-5a917cfd-b081-4d8e-8b22-f99af588ef9f@hpi.de>
 <7B80C97D-FE20-4AFA-9E9A-76A5334BC717@rowledge.org>
Message-ID: <CA+ovNC5rtJmjnqHx+AScB+uokkgfC+Wn7PiNXCv7-MEmhvTU+w@mail.gmail.com>

So far it was the models being responsible for such things as list
ordering. As I said, maybe the GUI model (for browsing the
repositories, here MCWorkingCopyBrowser) should be separate from the
domain object (that holds the order necessary for features like browse
revisions, I don't know which one it is, but I don't think that the
working copy browser should be used there).

If we enable the views (morphs, widgets) to do the sorting, it will be
cool to have sorting everywhere immediately. But then there might be
another thing you have to care about when you design your user
interface ("I must have this order, so I will always return it like
this... but nah it means I will have to tell the morph to disable the
sorting"). And we will have two ways to achieve the same thing (sorted
lists/trees). Is that the right way? If you think so, please proceed.


Am Di., 28. Juli 2020 um 18:24 Uhr schrieb tim Rowledge <tim at rowledge.org>:
>
>
>
> > On 2020-07-28, at 12:01 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> >
> > Hi Eliot, hi Chris,
> >
> > what about adding the preference #sortMonticelloRepositoriesAlphabetically like we have #sortMessageCategoriesAlphabetically ?
>
> How about adding sorting to the list *view* morphs instead? Being able to have sorting for name/date/size/colour/whatever in generic list morphs would be pretty helpful.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: HEM: Hide Evidence of Malfunction
>
>
>

From forums.jakob at resfarm.de  Tue Jul 28 19:23:46 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Tue, 28 Jul 2020 21:23:46 +0200
Subject: [squeak-dev] Debugging of other processes with wait
In-Reply-To: <Mailbird-96888028-3e6d-4376-b2e8-eb356348aee6@hpi.de>
References: <CA+ovNC4LjMC+OCB0eidYYz-zmCfvMX3m9wZ7RAh3bB6yfpHJ2A@mail.gmail.com>
 <60A16E3F-BDE8-4FA9-85D9-9F5441F5B751@gmail.com>
 <CA+ovNC6dLBdbKtXb2cBefs__6yAcaGH4+oBRQwDVcFB7UTGvEw@mail.gmail.com>
 <Mailbird-96888028-3e6d-4376-b2e8-eb356348aee6@hpi.de>
Message-ID: <CA+ovNC7PtuAGN2HtvdZ8eJ8SduBQFx5j+_ruk6A0m09zj-OS6g@mail.gmail.com>

Am Mo., 27. Juli 2020 um 11:19 Uhr schrieb Marcel Taeumel
<marcel.taeumel at hpi.de>:
>
> Could we always use the fallback code? Hmmm....
>

Would it help in this particular situation? "Primitive failed" is "not
fully functional" compared to a real Semaphore>>wait. And I doubt that
it would be right to put in some debugging stub in the fallback
implementation (e. g. a busy wait), though it might be okay. So the
general question would be: what to do when essential primitives are
encountered? And in particular the ones that will block...

From forums.jakob at resfarm.de  Tue Jul 28 19:50:05 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Tue, 28 Jul 2020 21:50:05 +0200
Subject: [squeak-dev] Debugging of other processes with wait
In-Reply-To: <CA+ovNC7sngpqtXOCKf78fSAb+XFn+YfqOJqvUFJD=_YTn2G7hA@mail.gmail.com>
References: <CA+ovNC4LjMC+OCB0eidYYz-zmCfvMX3m9wZ7RAh3bB6yfpHJ2A@mail.gmail.com>
 <60A16E3F-BDE8-4FA9-85D9-9F5441F5B751@gmail.com>
 <CA+ovNC6dLBdbKtXb2cBefs__6yAcaGH4+oBRQwDVcFB7UTGvEw@mail.gmail.com>
 <5729379a-9559-e8c7-1233-218e18353293@pm.me>
 <CA+ovNC7sngpqtXOCKf78fSAb+XFn+YfqOJqvUFJD=_YTn2G7hA@mail.gmail.com>
Message-ID: <CA+ovNC7u5eKJKpfWTK0Aa0E0EjRHQ_OLB1FMaq=iaxap6T2q_Q@mail.gmail.com>

Forward reply to the list... seems like something has changed in the
Gmail interface and I have not yet adapted to it.

Am Do., 23. Juli 2020 um 20:01 Uhr schrieb Robert Withers
<robert.withers at pm.me>:
>
> Although the Promise defined in Kernel-Processes has #wait protocol, this is really an anathema to Promise-style control flow. The #whenResolved: protocol should be used to register a reactor and no waits should occur.
> [...]
> Promise-style control flow does not use mutexes nor semaphores. So I believe the fundamental model here is misused.
> [...]
> So it is your intention to "move away from promise-style control flow." then I would suggest not using a Promise.
>

That's right, but right now I have some dialogs implemented in a
Promise style and want to implement a use case without promise style,
so I have to literally adapt when invoking the dialog if I don't want
to write all of it anew immediately.

Our current Kernel Promise is a two-headed beast: for one it wants to
be a Promises/A+ implementation, but originally it's purpose seems to
be only to support #future sends. Promises/A+ is targeted at
asynchrony in single-thread languages like JavaScript, while futures
are for multi-thread languages like Smalltalk. So Kernel Promise now
tries to serve both single-thread computing (UI process only) and
multi-thread computing (multiple Smalltalk processes).


From digit at sonic.net  Wed Jul 29 03:04:35 2020
From: digit at sonic.net (Tim Johnson)
Date: Tue, 28 Jul 2020 20:04:35 -0700
Subject: [squeak-dev] Should I put my unofficial V3 versions of Squeak
	5.2 and 5.3 on files.squeak.org?
In-Reply-To: <20200726193745.GA80806@shell.msen.com>
References: <1128010759.101982105.1595758362549.JavaMail.zimbra@telenet.be>
 <20200726193745.GA80806@shell.msen.com>
Message-ID: <245B1D4C-3EC2-4EB7-B64A-79F36371270A@sonic.net>

Hi Dave,

On Jul 26, 2020, at 12:37 PM, David T. Lewis wrote:

> By "unofficial" I mean that it is completely unrelated to any  
> officially
> announced versions of Squeak that appear on squeak.org and that are  
> expected
> to be of high quality and worthy of long term support.
>
> This is just stuff that I have done on my own and that may be of  
> interest
> to a few other people, that's all.

It is of interest to me, for whatever that's worth.

Thanks to you for making these images and thanks to whomever helped  
you get them onto files.squeak.org!

Best,
another Tim




From asqueaker at gmail.com  Wed Jul 29 04:39:40 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Tue, 28 Jul 2020 23:39:40 -0500
Subject: [squeak-dev] [ANN] MessageSendRecorder (and MethodWrappers) @
	GitHub
In-Reply-To: <Mailbird-fd37176c-dcc5-4532-aaa5-b221657fb08e@hpi.de>
References: <Mailbird-fd37176c-dcc5-4532-aaa5-b221657fb08e@hpi.de>
Message-ID: <CANzdToHSc2fbUvxkfAOiDFhA=J_7sPUpWmR+kPAWBShVvuYF6g@mail.gmail.com>

IMO, this should be integrated into the base image.


On Tue, Jul 28, 2020 at 5:26 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi all!
>
> I revived (and cleaned-up) a tracing project for Squeak our group did
> several years ago:
> https://github.com/hpi-swa/MessageSendRecorder
> And the end of the readme.md, you will find pointers to papers that (more
> or less) made use of this approach.
>
> It uses MethodWrappers, which I also pushed to GitHub:
> https://github.com/hpi-swa/MethodWrappers
>
> Happy Squeaking!
>
> Best,
> Marcel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/a0edc4c6/attachment.html>

From marcel.taeumel at hpi.de  Wed Jul 29 07:54:58 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Wed, 29 Jul 2020 09:54:58 +0200
Subject: [squeak-dev] [ANN] MessageSendRecorder (and MethodWrappers)
	@	GitHub
In-Reply-To: <CANzdToHSc2fbUvxkfAOiDFhA=J_7sPUpWmR+kPAWBShVvuYF6g@mail.gmail.com>
References: <Mailbird-fd37176c-dcc5-4532-aaa5-b221657fb08e@hpi.de>
 <CANzdToHSc2fbUvxkfAOiDFhA=J_7sPUpWmR+kPAWBShVvuYF6g@mail.gmail.com>
Message-ID: <Mailbird-deab78ac-9888-4508-aabc-ef126c2ec3c7@hpi.de>

Hi all!

MethodWrappers are implemented via object-as-method, which implement #run:with:in:. Other examples in the current Trunk image include ObjectsAsMethodsExample, WrappedBreakpoint, and TestCoverage. While MwMethodWrapper is an Object, WrappedBreakPoint and TestCoverage are both ProtoObject.

Method wrappers could be regarded as proxies for compiled methods, which means they should inherit from ProtoObject, too.

The MethodWrappers package mostly adds (1) a flexible composite pattern for object-as-method (i.e. wrap the wrappers) and (2) a convenience protocol around object-as-method, which includes a blacklist of methods not to wrap. :-)

Best,
Marcel

Am 29.07.2020 06:40:27 schrieb Chris Muller <asqueaker at gmail.com>:
IMO, this should be integrated into the base image.


On Tue, Jul 28, 2020 at 5:26 AM Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> wrote:

Hi all!

I revived (and cleaned-up) a tracing project for Squeak our group did several years ago:

https://github.com/hpi-swa/MessageSendRecorder [https://github.com/hpi-swa/MessageSendRecorder]

And the end of the readme.md, you will find pointers to papers that (more or less) made use of this approach.


It uses MethodWrappers, which I also pushed to GitHub:
https://github.com/hpi-swa/MethodWrappers [https://github.com/hpi-swa/MethodWrappers]

Happy Squeaking!

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200729/55a118f9/attachment.html>

From marcel.taeumel at hpi.de  Wed Jul 29 08:14:16 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Wed, 29 Jul 2020 10:14:16 +0200
Subject: [squeak-dev] Debugging of other processes with wait
In-Reply-To: <CA+ovNC7PtuAGN2HtvdZ8eJ8SduBQFx5j+_ruk6A0m09zj-OS6g@mail.gmail.com>
References: <CA+ovNC4LjMC+OCB0eidYYz-zmCfvMX3m9wZ7RAh3bB6yfpHJ2A@mail.gmail.com>
 <60A16E3F-BDE8-4FA9-85D9-9F5441F5B751@gmail.com>
 <CA+ovNC6dLBdbKtXb2cBefs__6yAcaGH4+oBRQwDVcFB7UTGvEw@mail.gmail.com>
 <Mailbird-96888028-3e6d-4376-b2e8-eb356348aee6@hpi.de>
 <CA+ovNC7PtuAGN2HtvdZ8eJ8SduBQFx5j+_ruk6A0m09zj-OS6g@mail.gmail.com>
Message-ID: <Mailbird-8c6226c0-34dd-4127-9229-682757fc5545@hpi.de>

Hi Jakob.

Just think of two processes: consumer and producer -- shared queue with semaphore in between. How can we have two debuggers that enable us to step each process alternatingly. Your case with the UI process is just a special instance of an overall challenge we might want to address in Squeak's debugging  infrastructure.

I think that we added #effectiveProcess only for process-local variables? Or did we already tackle some semaphore/mutex issues with it?

... maybe the debugger should consider whether a process could be scheduled at all? I don't think that Squeak's processes encode this state at the moment. They are either scheduled or not. The latter could mean anything: waiting for a semaphore, manually suspended for debugging, ...

Best,
Marcel
Am 28.07.2020 21:24:02 schrieb Jakob Reschke <forums.jakob at resfarm.de>:
Am Mo., 27. Juli 2020 um 11:19 Uhr schrieb Marcel Taeumel
:
>
> Could we always use the fallback code? Hmmm....
>

Would it help in this particular situation? "Primitive failed" is "not
fully functional" compared to a real Semaphore>>wait. And I doubt that
it would be right to put in some debugging stub in the fallback
implementation (e. g. a busy wait), though it might be okay. So the
general question would be: what to do when essential primitives are
encountered? And in particular the ones that will block...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200729/db43036b/attachment.html>

From marianopeck at gmail.com  Wed Jul 29 17:06:46 2020
From: marianopeck at gmail.com (Mariano Martinez Peck)
Date: Wed, 29 Jul 2020 14:06:46 -0300
Subject: [squeak-dev] [GemStone-Smalltalk] Webminar about VA Smalltalk
 new OS Process Framework
In-Reply-To: <CAAZgmAk7jh32xMs_hPRfGKcYjx4vM1Sk98qQXO-zNObUXs4iEQ@mail.gmail.com>
References: <CAA+-=mWM95DNTYhq02uwPyW4-kXVG0PZ1+eO1QQO3hyO9tyZCQ@mail.gmail.com>
 <CAA+-=mX-o_Ho0+f1pd1F0tr26GSb9PPriT=hm=m44F4Uy4pxkA@mail.gmail.com>
 <CAAZgmAk7jh32xMs_hPRfGKcYjx4vM1Sk98qQXO-zNObUXs4iEQ@mail.gmail.com>
Message-ID: <CAA+-=mWkkxkkv7b6HGeB+pUZr-AGDgMit=onmvC=5SvVTMFw+A@mail.gmail.com>

Hi,
This webinar already took place but you can see the recording here:
https://youtu.be/uwEu_-tflKg

Best,


On Wed, Jul 29, 2020 at 12:57 PM Norman Nunley via GemStone-Smalltalk <
gemstone-smalltalk at lists.gemtalksystems.com> wrote:

> Is there any chance that you'll record this webinar?  I'd love to attend,
> but I have work meeting conflicts.
>
> Norman
>
> On Wed, Jul 8, 2020 at 10:36 AM Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>> Greetings all, This is a friendly reminder of the presentation we will
>> host tomorrow for VAST's newest OSProcess framework. Best regards,
>>
>> On Tue, Jun 30, 2020 at 10:25 AM Mariano Martinez Peck <
>> marianopeck at gmail.com> wrote:
>>
>>> Greetings all,
>>>
>>> Some time ago, I had the pleasure and privilege of being sponsored by
>>> the Pharo Consortium to implement OSSubprocess. Because of that work, I
>>> quickly realized that a new OS process framework created by Instantiations
>>> was quite advanced and unlike anything I had seen before.  If you are able,
>>> I would highly recommend that you attend the technology preview of this
>>> framework coming to VAST 2021:
>>>
>>> Seth Berman will be presenting, registration here:
>>> https://attendee.gotowebinar.com/register/7491754880594201356
>>>
>>> We hope the community can attend and we look forward to your feedback
>>> and questions during the event's Q&A session.
>>>
>>> Best regards,
>>>
>>> --
>>> Mariano Martinez Peck
>>> Email: marianopeck at gmail.com
>>> Twitter: @MartinezPeck
>>> LinkedIn: www.linkedin.com/in/mariano-martinez-peck
>>> <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
>>> Blog: https://marianopeck.wordpress.com/
>>>
>>
>>
>> --
>> Mariano Martinez Peck
>> Email: marianopeck at gmail.com
>> Twitter: @MartinezPeck
>> LinkedIn: www.linkedin.com/in/mariano-martinez-peck
>> <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
>> Blog: https://marianopeck.wordpress.com/
>>
>> _______________________________________________
> GemStone-Smalltalk mailing list
> GemStone-Smalltalk at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>


-- 
Mariano Martinez Peck
Email: marianopeck at gmail.com
Twitter: @MartinezPeck
LinkedIn: www.linkedin.com/in/mariano-martinez-peck
<https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
Blog: https://marianopeck.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200729/42e51eb7/attachment.html>

From commits at source.squeak.org  Thu Jul 30 01:40:46 2020
From: commits at source.squeak.org (commits at source.squeak.org)
Date: Thu, 30 Jul 2020 01:40:46 0000
Subject: [squeak-dev] The Inbox: Monticello-cmm.727.mcz
Message-ID: <E1k0xYu-00068W-Rs@andreas>

Chris Muller uploaded a new version of Monticello to project The Inbox:
http://source.squeak.org/inbox/Monticello-cmm.727.mcz

==================== Summary ====================

Name: Monticello-cmm.727
Author: cmm
Time: 29 July 2020, 8:40:44.842148 pm
UUID: eb7cbccc-3b20-44ca-8e11-0dc93308a362
Ancestors: Monticello-mt.725

Sort the repository list when no WorkingCopy is selected.

=============== Diff against Monticello-mt.725 ===============

Item was changed:
  ----- Method: MCWorkingCopyBrowser>>repositories (in category 'morphic ui') -----
  repositories
  	| repositories |
  	repositories := self repositoryGroup repositories.
+ 	^ workingCopy
+ 		ifNil: [{repositories first}, (repositories allButFirst sort: #description ascending)]
+ 		ifNotNil: [ repositories ]!
- 	^{repositories first}, (repositories allButFirst sort: [:r1 :r2| r1 description < r2 description])!


From digit at sonic.net  Fri Jul 31 04:30:53 2020
From: digit at sonic.net (Tim Johnson)
Date: Thu, 30 Jul 2020 21:30:53 -0700
Subject: [squeak-dev] 5.3, focus follows mouse, image "save as..."
Message-ID: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>

Hi all,

In 5.3, when using the World menu, "Save as...," on macOS / OS X, with focus-follows-mouse[1] turned on, I enter my new file name, and when I press return or Cmd-S, the dialog does not go away.  (Even if I leave the mouse focus in that input field.)  My "changes are accepted," so to speak (the orange triangle goes away), but the image is not saved and the dialog does not go away.  It seems like I still have to go click "accept".  

I think in every previous version of Squeak I've used, in the dialog that appears upon choosing World menu -> "save as...", I can just type the new name and hit return or Cmd-S and the dialog will go away and the image will be saved.

With focus-follows-mouse turned off, 5.3 works as intended:  enter/return dismisses the dialog and the image is saved with the new name.

Wondering if this can be categorized as a regression[2].  To verify, I just tested in 5.2.  Indeed, in 5.2, whether focus-follows-mouse is turned on or off, I can enter a new file name and press enter/return and the image will be saved under the new name.  I don't have to move my mouse to click the "accept" button.

Could this somehow related to any other issues with where keyboard focus and/or events are going?  (Specifically talking about how entire windows are refreshing with every keypress into a code pane, for example.)  

Thanks,
Tim


[1] Preferences valueOfFlag: #mouseOverForKeyboardFocus

[2] regression meaning: since I care, I have to fix it? :)   Or, regression meaning: I file a bug in Mantis?  :) 



From digit at sonic.net  Fri Jul 31 05:59:29 2020
From: digit at sonic.net (Tim Johnson)
Date: Thu, 30 Jul 2020 22:59:29 -0700
Subject: [squeak-dev] Loading Seaside results in a number of Grease
	related code issues
In-Reply-To: <20200528200855.GA18788@shell.msen.com>
References: <459BB0D4-11CE-45EB-847B-BDF333621151@rowledge.org>
 <20200528200855.GA18788@shell.msen.com>
Message-ID: <D2B038B1-7ACE-4E3B-95E9-3C3760719316@sonic.net>


> On May 28, 2020, at 1:08 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> On Thu, May 28, 2020 at 01:01:55PM -0700, tim Rowledge wrote:
>> Whilst checking things after installing Seaside and Cryptography I noticed that there are a couple of dangling Undeclareds that lead into some faulty loaded code.
>> 
>> 'home' and 'startpc' are referenced in BlockContext>>#tempVarRefs. This is not too much of a problem since there are no senders but since there are also a bunch of methods loaded into the no longer used Context/BlockContext/MethodContext classes it might be an indicator of some updating needed in the Grease package, specifically *grease-squeak5-core. I don't know who looks after this, so if anyone does, please pass it on.
>> 
> 
> The grease package is one of those things that we, the Squeak community,
> need to take more responsibility for. If anyone is looking for a worthwhile
> Sunday Squeaker project, this would be a good one.

I agree.  So here I am trying to do this, and running into obstacles.  :( 

The Grease repo is in Cypress format, which I have no experience with.  I have some experience with FileTree, but Cypress seems different.

So, I thought I would try out Squot and the Git Browser, because they support Cypress.

But now I'm having trouble with the Git Browser, and I don't know if this list is the place to talk about it.  Am I doing something wrong?  Or are these bugs I should file issues at Squot's GitHub repo?

I'm having three or four issues.

1) if I load Grease into my image using [1], then I also clone the Grease repo from [2] in Git Browser as a new project, then the timestamps on the methods are different between what Squot is looking at and what is in the image.  So I don't get a clean record of what has actually changed in my image.  Do I need to load Grease from what Squot knows/handles, instead of [1], so I don't get different timestamps in methods?  If so, how?  (Actually this begs the question, why are method timestamps being changed to the moment the method is being loaded into my image, instead of retaining their original timestamp?  Is this a Cypress thing?)  I don't remember this being an issue with Monticello;  in MC, method timestamps come in with the method, and don't change to the time the method was loaded, right?

MCModification 
	obsoletion timeStamp = ' 7/30/2020 22:03:37'
	modification timeStamp = ' 7/30/2020 22:01:38'

2) When I delete the *extension method category "*grease-squeak5-core" from BlockContext and create my commit, 
carefully Cmd-X'ing the methods that only have a different timestamp, there becomes two issues with my actual commit:
2a) All the *Extensions methods are still part of my commit, even though I Cmd-X'd all but one of them (do I recall right that this this a Monticello bug/feature?  It's all *Extensions or none?)
2b) When I menu-click my commit in Git Browser and "compare with parent commit," my commit now shows the method timestamps as being different in a different way:  the /time/ is the same, but now one method has a leading space in its string and one doesn't:

MCModification 
	obsoletion timeStamp = ' 7/30/2020 20:27:03'
	modification timeStamp = '7/30/2020 20:27:03'

3) If I try to checkout a new branch off the top commit, or off a package, I eventually end up with a Warning dialog that contains this:

This package depends on the following classes:
  TBehavior
You must resolve these dependencies before you will be able to load these definitions: 
  TBehavior>>fullName

I can click Proceed a dozen times, but eventually I get to a DNU.


...
So, I don't really know what to do.  What am I doing wrong?  Should I file a bug report or two with Squot?  Learn Cypress?  Hmm.


A basic way to set up a test case is (not sure if order matters?):

1) Fresh 5.3 image, load Git Browser
2) In Git Browser, tell it not to "add my first project now";  I will menu-click, clone project, enter https://github.com/SeasideSt/Grease.git, create a new folder, watch in awe as it gets checked out (this is cool!)
3) load Grease via [1]
4) Try something like: 
4a) menu-click 'repository/Grease-Squeak5-Core.package' and then Checkout, and inspect the diffs to see the different timestamps
4b) "Create new branch at this commit" (I just tried this, got "Key not found: repository/Grease-Core.package") 
4c) remove (Cmd-X) BlockContext's "*grease-squeak5-core" method category, then (wow, I just did this, and it actually resulted in a EXC_CRASH in copyToOldSpacebytesformat + 90 (gcc3x-cointerp.c:40614), old VM 5.0.201811061137)

Hmm.  I'm no stranger to Git, nor a stranger to Monticello, but this is all new.

Thanks,
Tim


[1] Metacello new
    baseline: 'Grease';
    githubUser: 'SeasideSt' project: 'Grease' commitish: 'master' path: 'repository';
    load


From marcel.taeumel at hpi.de  Fri Jul 31 07:55:27 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Fri, 31 Jul 2020 09:55:27 +0200
Subject: [squeak-dev] 5.3, focus follows mouse, image "save as..."
In-Reply-To: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
References: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
Message-ID: <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>

Hi Tim,

Windows 10 here. Works for me in recent Trunk (Build 19801) with [return]. Does not work with [cmd+s]. "Mouse over for keyboard focus" enabled, of course. ;-)

Best,
Marcel
Am 31.07.2020 06:31:07 schrieb Tim Johnson <digit at sonic.net>:
Hi all,

In 5.3, when using the World menu, "Save as...," on macOS / OS X, with focus-follows-mouse[1] turned on, I enter my new file name, and when I press return or Cmd-S, the dialog does not go away. (Even if I leave the mouse focus in that input field.) My "changes are accepted," so to speak (the orange triangle goes away), but the image is not saved and the dialog does not go away. It seems like I still have to go click "accept".

I think in every previous version of Squeak I've used, in the dialog that appears upon choosing World menu -> "save as...", I can just type the new name and hit return or Cmd-S and the dialog will go away and the image will be saved.

With focus-follows-mouse turned off, 5.3 works as intended: enter/return dismisses the dialog and the image is saved with the new name.

Wondering if this can be categorized as a regression[2]. To verify, I just tested in 5.2. Indeed, in 5.2, whether focus-follows-mouse is turned on or off, I can enter a new file name and press enter/return and the image will be saved under the new name. I don't have to move my mouse to click the "accept" button.

Could this somehow related to any other issues with where keyboard focus and/or events are going? (Specifically talking about how entire windows are refreshing with every keypress into a code pane, for example.)

Thanks,
Tim


[1] Preferences valueOfFlag: #mouseOverForKeyboardFocus

[2] regression meaning: since I care, I have to fix it? :) Or, regression meaning: I file a bug in Mantis? :)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/330f6185/attachment.html>

From marcel.taeumel at hpi.de  Fri Jul 31 08:12:48 2020
From: marcel.taeumel at hpi.de (Marcel Taeumel)
Date: Fri, 31 Jul 2020 10:12:48 +0200
Subject: [squeak-dev] 5.3, focus follows mouse, image "save as..."
In-Reply-To: <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>
References: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
 <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>
Message-ID: <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>

And: Looking at the current implementation of FileSaverDialog, that "unaccepted changes"-triangle is used to let the user type in a file name and only after [cmd+s] check whether that name has the required suffix. [return] or [enter] both combine that behavior with a final accept-and-close in the dialog.

So, [cmd+s] is not intended to close the dialog. Just type in and hit [enter] or [return]. That is implemented via an event filter and works fine in Squeak 5.3 on Windows 10, too.

Yes, it would be possible the change the implementation to let [cmd+s] also close the dialog.

No, it is actually unrelated to the preference "mouse over for keyboard focus". Something else is going on in your image or platform. :-)

Best,
Marcel
Am 31.07.2020 09:55:27 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi Tim,

Windows 10 here. Works for me in recent Trunk (Build 19801) with [return]. Does not work with [cmd+s]. "Mouse over for keyboard focus" enabled, of course. ;-)

Best,
Marcel
Am 31.07.2020 06:31:07 schrieb Tim Johnson <digit at sonic.net>:
Hi all,

In 5.3, when using the World menu, "Save as...," on macOS / OS X, with focus-follows-mouse[1] turned on, I enter my new file name, and when I press return or Cmd-S, the dialog does not go away. (Even if I leave the mouse focus in that input field.) My "changes are accepted," so to speak (the orange triangle goes away), but the image is not saved and the dialog does not go away. It seems like I still have to go click "accept".

I think in every previous version of Squeak I've used, in the dialog that appears upon choosing World menu -> "save as...", I can just type the new name and hit return or Cmd-S and the dialog will go away and the image will be saved.

With focus-follows-mouse turned off, 5.3 works as intended: enter/return dismisses the dialog and the image is saved with the new name.

Wondering if this can be categorized as a regression[2]. To verify, I just tested in 5.2. Indeed, in 5.2, whether focus-follows-mouse is turned on or off, I can enter a new file name and press enter/return and the image will be saved under the new name. I don't have to move my mouse to click the "accept" button.

Could this somehow related to any other issues with where keyboard focus and/or events are going? (Specifically talking about how entire windows are refreshing with every keypress into a code pane, for example.)

Thanks,
Tim


[1] Preferences valueOfFlag: #mouseOverForKeyboardFocus

[2] regression meaning: since I care, I have to fix it? :) Or, regression meaning: I file a bug in Mantis? :)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/2f630bfc/attachment.html>

From forums.jakob at resfarm.de  Fri Jul 31 14:03:19 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Fri, 31 Jul 2020 16:03:19 +0200
Subject: [squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3,
 focus follows mouse, image "save as...")
In-Reply-To: <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>
References: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
 <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>
 <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>
Message-ID: <CA+ovNC7szOijXZQ3RuwoDHBikKhoVGkX58WXvAbY+hQfmE5N_Q@mail.gmail.com>

Hi all,

Under which circumstances do you expect that the "accept" action and
more specifically pressing Cmd-s _close_ a dialog window or whatever
thing you have been entering text in?

Kind regards,
Jakob



Am Fr., 31. Juli 2020 um 10:13 Uhr schrieb Marcel Taeumel
<marcel.taeumel at hpi.de>:
>
> And: Looking at the current implementation of FileSaverDialog, that "unaccepted changes"-triangle is used to let the user type in a file name and only after [cmd+s] check whether that name has the required suffix. [return] or [enter] both combine that behavior with a final accept-and-close in the dialog.
>
> So, [cmd+s] is not intended to close the dialog. Just type in and hit [enter] or [return]. That is implemented via an event filter and works fine in Squeak 5.3 on Windows 10, too.
>
> Yes, it would be possible the change the implementation to let [cmd+s] also close the dialog.
>
> No, it is actually unrelated to the preference "mouse over for keyboard focus". Something else is going on in your image or platform. :-)
>
> Best,
> Marcel
>
> Am 31.07.2020 09:55:27 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>
> Hi Tim,
>
> Windows 10 here. Works for me in recent Trunk (Build 19801) with [return]. Does not work with [cmd+s]. "Mouse over for keyboard focus" enabled, of course. ;-)
>
> Best,
> Marcel
>
> Am 31.07.2020 06:31:07 schrieb Tim Johnson <digit at sonic.net>:
>
> Hi all,
>
> In 5.3, when using the World menu, "Save as...," on macOS / OS X, with focus-follows-mouse[1] turned on, I enter my new file name, and when I press return or Cmd-S, the dialog does not go away. (Even if I leave the mouse focus in that input field.) My "changes are accepted," so to speak (the orange triangle goes away), but the image is not saved and the dialog does not go away. It seems like I still have to go click "accept".
>
> I think in every previous version of Squeak I've used, in the dialog that appears upon choosing World menu -> "save as...", I can just type the new name and hit return or Cmd-S and the dialog will go away and the image will be saved.
>
> With focus-follows-mouse turned off, 5.3 works as intended: enter/return dismisses the dialog and the image is saved with the new name.
>
> Wondering if this can be categorized as a regression[2]. To verify, I just tested in 5.2. Indeed, in 5.2, whether focus-follows-mouse is turned on or off, I can enter a new file name and press enter/return and the image will be saved under the new name. I don't have to move my mouse to click the "accept" button.
>
> Could this somehow related to any other issues with where keyboard focus and/or events are going? (Specifically talking about how entire windows are refreshing with every keypress into a code pane, for example.)
>
> Thanks,
> Tim
>
>
> [1] Preferences valueOfFlag: #mouseOverForKeyboardFocus
>
> [2] regression meaning: since I care, I have to fix it? :) Or, regression meaning: I file a bug in Mantis? :)
>
>
>
>

From forums.jakob at resfarm.de  Fri Jul 31 14:05:57 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Fri, 31 Jul 2020 16:05:57 +0200
Subject: [squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3,
 focus follows mouse, image "save as...")
In-Reply-To: <CA+ovNC7szOijXZQ3RuwoDHBikKhoVGkX58WXvAbY+hQfmE5N_Q@mail.gmail.com>
References: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
 <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>
 <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>
 <CA+ovNC7szOijXZQ3RuwoDHBikKhoVGkX58WXvAbY+hQfmE5N_Q@mail.gmail.com>
Message-ID: <CA+ovNC4NVpEgmdfYzehDJ1FYkd1L+Czh+vp9OYKmyrNLz5cfmg@mail.gmail.com>

My own answer:

I find it highly unusual and never expect to close something with
Cmd-s. Outside of Squeak I know about pressing Enter/Return on a main
text entry, or even the space bar if it is a button, to close a
dialog. But not "save = close".

But it seems like this used to (or should?) work to save an image, and
I also got a ticket in Squot to add this behavior to the commit
dialog.

That's why I would like to know how much of a Squeak interaction idiom
this really is, where does it come from, and what other systems
exhibit this behavior?

Am Fr., 31. Juli 2020 um 16:03 Uhr schrieb Jakob Reschke
<forums.jakob at resfarm.de>:
>
> Hi all,
>
> Under which circumstances do you expect that the "accept" action and
> more specifically pressing Cmd-s _close_ a dialog window or whatever
> thing you have been entering text in?
>
> Kind regards,
> Jakob
>
>
>
> Am Fr., 31. Juli 2020 um 10:13 Uhr schrieb Marcel Taeumel
> <marcel.taeumel at hpi.de>:
> >
> > And: Looking at the current implementation of FileSaverDialog, that "unaccepted changes"-triangle is used to let the user type in a file name and only after [cmd+s] check whether that name has the required suffix. [return] or [enter] both combine that behavior with a final accept-and-close in the dialog.
> >
> > So, [cmd+s] is not intended to close the dialog. Just type in and hit [enter] or [return]. That is implemented via an event filter and works fine in Squeak 5.3 on Windows 10, too.
> >
> > Yes, it would be possible the change the implementation to let [cmd+s] also close the dialog.
> >
> > No, it is actually unrelated to the preference "mouse over for keyboard focus". Something else is going on in your image or platform. :-)
> >
> > Best,
> > Marcel
> >
> > Am 31.07.2020 09:55:27 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> >
> > Hi Tim,
> >
> > Windows 10 here. Works for me in recent Trunk (Build 19801) with [return]. Does not work with [cmd+s]. "Mouse over for keyboard focus" enabled, of course. ;-)
> >
> > Best,
> > Marcel
> >
> > Am 31.07.2020 06:31:07 schrieb Tim Johnson <digit at sonic.net>:
> >
> > Hi all,
> >
> > In 5.3, when using the World menu, "Save as...," on macOS / OS X, with focus-follows-mouse[1] turned on, I enter my new file name, and when I press return or Cmd-S, the dialog does not go away. (Even if I leave the mouse focus in that input field.) My "changes are accepted," so to speak (the orange triangle goes away), but the image is not saved and the dialog does not go away. It seems like I still have to go click "accept".
> >
> > I think in every previous version of Squeak I've used, in the dialog that appears upon choosing World menu -> "save as...", I can just type the new name and hit return or Cmd-S and the dialog will go away and the image will be saved.
> >
> > With focus-follows-mouse turned off, 5.3 works as intended: enter/return dismisses the dialog and the image is saved with the new name.
> >
> > Wondering if this can be categorized as a regression[2]. To verify, I just tested in 5.2. Indeed, in 5.2, whether focus-follows-mouse is turned on or off, I can enter a new file name and press enter/return and the image will be saved under the new name. I don't have to move my mouse to click the "accept" button.
> >
> > Could this somehow related to any other issues with where keyboard focus and/or events are going? (Specifically talking about how entire windows are refreshing with every keypress into a code pane, for example.)
> >
> > Thanks,
> > Tim
> >
> >
> > [1] Preferences valueOfFlag: #mouseOverForKeyboardFocus
> >
> > [2] regression meaning: since I care, I have to fix it? :) Or, regression meaning: I file a bug in Mantis? :)
> >
> >
> >
> >

From forums.jakob at resfarm.de  Fri Jul 31 14:24:41 2020
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Fri, 31 Jul 2020 16:24:41 +0200
Subject: [squeak-dev] Loading Seaside results in a number of Grease
 related code issues
In-Reply-To: <D2B038B1-7ACE-4E3B-95E9-3C3760719316@sonic.net>
References: <459BB0D4-11CE-45EB-847B-BDF333621151@rowledge.org>
 <20200528200855.GA18788@shell.msen.com>
 <D2B038B1-7ACE-4E3B-95E9-3C3760719316@sonic.net>
Message-ID: <CA+ovNC7AGrJHn7cCO=0pzKEtdifgr8yU8Yima_Xt56BskQ1yZQ@mail.gmail.com>

Hi Tim,

The repository has method metadata disabled:
https://github.com/SeasideSt/Grease/blob/master/repository/.filetree

Hence there is no timestamp information with the source and the Squeak
implementation currently seems to fall back to use the load timestamp.
Under these circumstances I think it would also be of no advantage to
clone and load with the Git Browser directly instead of first loading
via Metacello (which at least also pulls the dependencies, if any).

The Git Browser uses Monticello under the hood to read and write
packages, so the hunt for the variable amount of spaces needs to be
sought there, or rather in the FileTree and Cypress classes.

Cypress is slightly different from FileTree, but so far I did not have
problems treating them basically like the same thing. If I am not
mistaken, first Dale created FileTree, later at some conference or so
several people decided on a common format for inter-Smalltalk exchange
based on FileTree and called the result Cypress. Today we have Tonel
in the game, so I guess not many people will call for Cypress anymore.

TBehavior is a Pharo trait. Pharo refactored some parts of the basic
class library to use traits. My guess is that there are packages in
the repository that are not supposed to be loaded in Squeak (not a
surprise for something like Grease), but Squot does not know about
that and tries to load all the packages. You would currently have to
exclude the additions of the non-Squeak packages in the load/merge
dialog.

For the issue that you excluded the extension methods in the commit
dialog (with cmd-x), but some of them were committed nevertheless,
please file a bug report in for Squot on GitHub with the details and a
reference to the published commit (if it is public). Even if this
should be a peculiarity of the underlying Monticello, it is at least
unexpected to me.

https://github.com/hpi-swa/Squot/issues/

Kind regards,
Jakob

Am Fr., 31. Juli 2020 um 07:59 Uhr schrieb Tim Johnson <digit at sonic.net>:
>
>
> > On May 28, 2020, at 1:08 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > On Thu, May 28, 2020 at 01:01:55PM -0700, tim Rowledge wrote:
> >> Whilst checking things after installing Seaside and Cryptography I noticed that there are a couple of dangling Undeclareds that lead into some faulty loaded code.
> >>
> >> 'home' and 'startpc' are referenced in BlockContext>>#tempVarRefs. This is not too much of a problem since there are no senders but since there are also a bunch of methods loaded into the no longer used Context/BlockContext/MethodContext classes it might be an indicator of some updating needed in the Grease package, specifically *grease-squeak5-core. I don't know who looks after this, so if anyone does, please pass it on.
> >>
> >
> > The grease package is one of those things that we, the Squeak community,
> > need to take more responsibility for. If anyone is looking for a worthwhile
> > Sunday Squeaker project, this would be a good one.
>
> I agree.  So here I am trying to do this, and running into obstacles.  :(
>
> The Grease repo is in Cypress format, which I have no experience with.  I have some experience with FileTree, but Cypress seems different.
>
> So, I thought I would try out Squot and the Git Browser, because they support Cypress.
>
> But now I'm having trouble with the Git Browser, and I don't know if this list is the place to talk about it.  Am I doing something wrong?  Or are these bugs I should file issues at Squot's GitHub repo?
>
> I'm having three or four issues.
>
> 1) if I load Grease into my image using [1], then I also clone the Grease repo from [2] in Git Browser as a new project, then the timestamps on the methods are different between what Squot is looking at and what is in the image.  So I don't get a clean record of what has actually changed in my image.  Do I need to load Grease from what Squot knows/handles, instead of [1], so I don't get different timestamps in methods?  If so, how?  (Actually this begs the question, why are method timestamps being changed to the moment the method is being loaded into my image, instead of retaining their original timestamp?  Is this a Cypress thing?)  I don't remember this being an issue with Monticello;  in MC, method timestamps come in with the method, and don't change to the time the method was loaded, right?
>
> MCModification
>         obsoletion timeStamp = ' 7/30/2020 22:03:37'
>         modification timeStamp = ' 7/30/2020 22:01:38'
>
> 2) When I delete the *extension method category "*grease-squeak5-core" from BlockContext and create my commit,
> carefully Cmd-X'ing the methods that only have a different timestamp, there becomes two issues with my actual commit:
> 2a) All the *Extensions methods are still part of my commit, even though I Cmd-X'd all but one of them (do I recall right that this this a Monticello bug/feature?  It's all *Extensions or none?)
> 2b) When I menu-click my commit in Git Browser and "compare with parent commit," my commit now shows the method timestamps as being different in a different way:  the /time/ is the same, but now one method has a leading space in its string and one doesn't:
>
> MCModification
>         obsoletion timeStamp = ' 7/30/2020 20:27:03'
>         modification timeStamp = '7/30/2020 20:27:03'
>
> 3) If I try to checkout a new branch off the top commit, or off a package, I eventually end up with a Warning dialog that contains this:
>
> This package depends on the following classes:
>   TBehavior
> You must resolve these dependencies before you will be able to load these definitions:
>   TBehavior>>fullName
>
> I can click Proceed a dozen times, but eventually I get to a DNU.
>
>
> ...
> So, I don't really know what to do.  What am I doing wrong?  Should I file a bug report or two with Squot?  Learn Cypress?  Hmm.
>
>
> A basic way to set up a test case is (not sure if order matters?):
>
> 1) Fresh 5.3 image, load Git Browser
> 2) In Git Browser, tell it not to "add my first project now";  I will menu-click, clone project, enter https://github.com/SeasideSt/Grease.git, create a new folder, watch in awe as it gets checked out (this is cool!)
> 3) load Grease via [1]
> 4) Try something like:
> 4a) menu-click 'repository/Grease-Squeak5-Core.package' and then Checkout, and inspect the diffs to see the different timestamps
> 4b) "Create new branch at this commit" (I just tried this, got "Key not found: repository/Grease-Core.package")
> 4c) remove (Cmd-X) BlockContext's "*grease-squeak5-core" method category, then (wow, I just did this, and it actually resulted in a EXC_CRASH in copyToOldSpacebytesformat + 90 (gcc3x-cointerp.c:40614), old VM 5.0.201811061137)
>
> Hmm.  I'm no stranger to Git, nor a stranger to Monticello, but this is all new.
>
> Thanks,
> Tim
>
>
> [1] Metacello new
>     baseline: 'Grease';
>     githubUser: 'SeasideSt' project: 'Grease' commitish: 'master' path: 'repository';
>     load
>
>


From digit at sonic.net  Fri Jul 31 15:20:39 2020
From: digit at sonic.net (Tim Johnson)
Date: Fri, 31 Jul 2020 08:20:39 -0700
Subject: [squeak-dev] 5.3, focus follows mouse, image "save as..."
In-Reply-To: <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>
References: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
 <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>
 <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>
Message-ID: <2A01B8A1-A8FB-433C-8DE6-3D814FD8CCF6@sonic.net>


On Jul 31, 2020, at 1:12 AM, Marcel Taeumel wrote:

> No, it is actually unrelated to the preference "mouse over for  
> keyboard focus". Something else is going on in your image or  
> platform. :-)
>

OK, thanks.  I guess I should have tried more permutations of VM and  
image and keyboards before posting.

"But it works in 5.2..."  Hmm.

Tim


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/df37659d/attachment.html>

From digit at sonic.net  Fri Jul 31 15:24:03 2020
From: digit at sonic.net (Tim Johnson)
Date: Fri, 31 Jul 2020 08:24:03 -0700
Subject: [squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3,
	focus follows mouse, image "save as...")
In-Reply-To: <CA+ovNC4NVpEgmdfYzehDJ1FYkd1L+Czh+vp9OYKmyrNLz5cfmg@mail.gmail.com>
References: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
 <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>
 <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>
 <CA+ovNC7szOijXZQ3RuwoDHBikKhoVGkX58WXvAbY+hQfmE5N_Q@mail.gmail.com>
 <CA+ovNC4NVpEgmdfYzehDJ1FYkd1L+Czh+vp9OYKmyrNLz5cfmg@mail.gmail.com>
Message-ID: <23539013-D464-4CC6-89B2-26B451C2338E@sonic.net>

If Cmd-s is a shortcut for "accept" (which I think it is, throughout  
most of Squeak), and in this dialog, "accept" (i.e. the "accept"  
button) saves the image with the new name and closes the dialog, then  
Cmd-s should perform the "accept" operation, which closes the dialog.

I don't mean to defend this metaphor, but it seems consistent  
throughout most of Squeak...

FillInTheBlank request: 'how are you?'

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 29.png
Type: image/png
Size: 9201 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/a2db9a2d/attachment.png>
-------------- next part --------------



^^ see the "(s)" in Accept.



On Jul 31, 2020, at 7:05 AM, Jakob Reschke wrote:

> My own answer:
>
> I find it highly unusual and never expect to close something with
> Cmd-s. Outside of Squeak I know about pressing Enter/Return on a main
> text entry, or even the space bar if it is a button, to close a
> dialog. But not "save = close".
>
> But it seems like this used to (or should?) work to save an image, and
> I also got a ticket in Squot to add this behavior to the commit
> dialog.
>
> That's why I would like to know how much of a Squeak interaction idiom
> this really is, where does it come from, and what other systems
> exhibit this behavior?
>
> Am Fr., 31. Juli 2020 um 16:03 Uhr schrieb Jakob Reschke
> <forums.jakob at resfarm.de>:
>>
>> Hi all,
>>
>> Under which circumstances do you expect that the "accept" action and
>> more specifically pressing Cmd-s _close_ a dialog window or whatever
>> thing you have been entering text in?
>>
>> Kind regards,
>> Jakob
>>
>>
>>
>> Am Fr., 31. Juli 2020 um 10:13 Uhr schrieb Marcel Taeumel
>> <marcel.taeumel at hpi.de>:
>>>
>>> And: Looking at the current implementation of FileSaverDialog,  
>>> that "unaccepted changes"-triangle is used to let the user type in  
>>> a file name and only after [cmd+s] check whether that name has the  
>>> required suffix. [return] or [enter] both combine that behavior  
>>> with a final accept-and-close in the dialog.
>>>
>>> So, [cmd+s] is not intended to close the dialog. Just type in and  
>>> hit [enter] or [return]. That is implemented via an event filter  
>>> and works fine in Squeak 5.3 on Windows 10, too.
>>>
>>> Yes, it would be possible the change the implementation to let [cmd 
>>> +s] also close the dialog.
>>>
>>> No, it is actually unrelated to the preference "mouse over for  
>>> keyboard focus". Something else is going on in your image or  
>>> platform. :-)
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 31.07.2020 09:55:27 schrieb Marcel Taeumel  
>>> <marcel.taeumel at hpi.de>:
>>>
>>> Hi Tim,
>>>
>>> Windows 10 here. Works for me in recent Trunk (Build 19801) with  
>>> [return]. Does not work with [cmd+s]. "Mouse over for keyboard  
>>> focus" enabled, of course. ;-)
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 31.07.2020 06:31:07 schrieb Tim Johnson <digit at sonic.net>:
>>>
>>> Hi all,
>>>
>>> In 5.3, when using the World menu, "Save as...," on macOS / OS X,  
>>> with focus-follows-mouse[1] turned on, I enter my new file name,  
>>> and when I press return or Cmd-S, the dialog does not go away.  
>>> (Even if I leave the mouse focus in that input field.) My "changes  
>>> are accepted," so to speak (the orange triangle goes away), but  
>>> the image is not saved and the dialog does not go away. It seems  
>>> like I still have to go click "accept".
>>>
>>> I think in every previous version of Squeak I've used, in the  
>>> dialog that appears upon choosing World menu -> "save as...", I  
>>> can just type the new name and hit return or Cmd-S and the dialog  
>>> will go away and the image will be saved.
>>>
>>> With focus-follows-mouse turned off, 5.3 works as intended: enter/ 
>>> return dismisses the dialog and the image is saved with the new  
>>> name.
>>>
>>> Wondering if this can be categorized as a regression[2]. To  
>>> verify, I just tested in 5.2. Indeed, in 5.2, whether focus- 
>>> follows-mouse is turned on or off, I can enter a new file name and  
>>> press enter/return and the image will be saved under the new name.  
>>> I don't have to move my mouse to click the "accept" button.
>>>
>>> Could this somehow related to any other issues with where keyboard  
>>> focus and/or events are going? (Specifically talking about how  
>>> entire windows are refreshing with every keypress into a code  
>>> pane, for example.)
>>>
>>> Thanks,
>>> Tim
>>>
>>>
>>> [1] Preferences valueOfFlag: #mouseOverForKeyboardFocus
>>>
>>> [2] regression meaning: since I care, I have to fix it? :) Or,  
>>> regression meaning: I file a bug in Mantis? :)
>>>
>>>
>>>
>>>
>
>


From digit at sonic.net  Fri Jul 31 16:47:16 2020
From: digit at sonic.net (Tim Johnson)
Date: Fri, 31 Jul 2020 09:47:16 -0700
Subject: [squeak-dev] Loading Seaside results in a number of Grease
	related code issues
In-Reply-To: <CA+ovNC7AGrJHn7cCO=0pzKEtdifgr8yU8Yima_Xt56BskQ1yZQ@mail.gmail.com>
References: <459BB0D4-11CE-45EB-847B-BDF333621151@rowledge.org>
 <20200528200855.GA18788@shell.msen.com>
 <D2B038B1-7ACE-4E3B-95E9-3C3760719316@sonic.net>
 <CA+ovNC7AGrJHn7cCO=0pzKEtdifgr8yU8Yima_Xt56BskQ1yZQ@mail.gmail.com>
Message-ID: <D0BD3EBA-7323-4438-B4C2-60464F940526@sonic.net>

Hi Jakob,

Thanks for the help, pointers, and ideas.

I was having trouble last night using Squeak's native Monticello  
tooling to access the FileTree/Cypress repo.  That is why I tried Git  
Browser (and I will continue to experiment with it).  This morning,  
with some fresh coffee, a fresh image, and a fresh "Installer  
ensureRecentMetacello", those troubles have gone away.

I have filed ... erm, not really a bug or issue, but inquiry, hoping  
Dale and/or someone else might be generous enough with their time to  
help direct/guide w/r/t to timeStamps and diffs:

https://github.com/dalehenrich/filetree/issues/228

I'd also like to learn how to load packages (programmatically) via  
Metacello from a local repo or working copy on disk, rather than  
cloning fresh from an URL-based GitHub repo.  Not sure where to start,  
there, or if you have any pointers.

I will come up with a (hopefully) replicable test case for the  
extension methods and file a bug with Squot as you suggest.

Thanks again,
Tim


On Jul 31, 2020, at 7:24 AM, Jakob Reschke wrote:

> Hi Tim,
>
> The repository has method metadata disabled:
> https://github.com/SeasideSt/Grease/blob/master/repository/.filetree
>
> Hence there is no timestamp information with the source and the Squeak
> implementation currently seems to fall back to use the load timestamp.
> Under these circumstances I think it would also be of no advantage to
> clone and load with the Git Browser directly instead of first loading
> via Metacello (which at least also pulls the dependencies, if any).
>
> The Git Browser uses Monticello under the hood to read and write
> packages, so the hunt for the variable amount of spaces needs to be
> sought there, or rather in the FileTree and Cypress classes.
>
> Cypress is slightly different from FileTree, but so far I did not have
> problems treating them basically like the same thing. If I am not
> mistaken, first Dale created FileTree, later at some conference or so
> several people decided on a common format for inter-Smalltalk exchange
> based on FileTree and called the result Cypress. Today we have Tonel
> in the game, so I guess not many people will call for Cypress anymore.
>
> TBehavior is a Pharo trait. Pharo refactored some parts of the basic
> class library to use traits. My guess is that there are packages in
> the repository that are not supposed to be loaded in Squeak (not a
> surprise for something like Grease), but Squot does not know about
> that and tries to load all the packages. You would currently have to
> exclude the additions of the non-Squeak packages in the load/merge
> dialog.
>
> For the issue that you excluded the extension methods in the commit
> dialog (with cmd-x), but some of them were committed nevertheless,
> please file a bug report in for Squot on GitHub with the details and a
> reference to the published commit (if it is public). Even if this
> should be a peculiarity of the underlying Monticello, it is at least
> unexpected to me.
>
> https://github.com/hpi-swa/Squot/issues/
>
> Kind regards,
> Jakob
>
> Am Fr., 31. Juli 2020 um 07:59 Uhr schrieb Tim Johnson <digit at sonic.net 
> >:
>>
>>
>>> On May 28, 2020, at 1:08 PM, David T. Lewis <lewis at mail.msen.com>  
>>> wrote:
>>>
>>> On Thu, May 28, 2020 at 01:01:55PM -0700, tim Rowledge wrote:
>>>> Whilst checking things after installing Seaside and Cryptography  
>>>> I noticed that there are a couple of dangling Undeclareds that  
>>>> lead into some faulty loaded code.
>>>>
>>>> 'home' and 'startpc' are referenced in  
>>>> BlockContext>>#tempVarRefs. This is not too much of a problem  
>>>> since there are no senders but since there are also a bunch of  
>>>> methods loaded into the no longer used Context/BlockContext/ 
>>>> MethodContext classes it might be an indicator of some updating  
>>>> needed in the Grease package, specifically *grease-squeak5-core.  
>>>> I don't know who looks after this, so if anyone does, please pass  
>>>> it on.
>>>>
>>>
>>> The grease package is one of those things that we, the Squeak  
>>> community,
>>> need to take more responsibility for. If anyone is looking for a  
>>> worthwhile
>>> Sunday Squeaker project, this would be a good one.
>>
>> I agree.  So here I am trying to do this, and running into  
>> obstacles.  :(
>>
>> The Grease repo is in Cypress format, which I have no experience  
>> with.  I have some experience with FileTree, but Cypress seems  
>> different.
>>
>> So, I thought I would try out Squot and the Git Browser, because  
>> they support Cypress.
>>
>> But now I'm having trouble with the Git Browser, and I don't know  
>> if this list is the place to talk about it.  Am I doing something  
>> wrong?  Or are these bugs I should file issues at Squot's GitHub  
>> repo?
>>
>> I'm having three or four issues.
>>
>> 1) if I load Grease into my image using [1], then I also clone the  
>> Grease repo from [2] in Git Browser as a new project, then the  
>> timestamps on the methods are different between what Squot is  
>> looking at and what is in the image.  So I don't get a clean record  
>> of what has actually changed in my image.  Do I need to load Grease  
>> from what Squot knows/handles, instead of [1], so I don't get  
>> different timestamps in methods?  If so, how?  (Actually this begs  
>> the question, why are method timestamps being changed to the moment  
>> the method is being loaded into my image, instead of retaining  
>> their original timestamp?  Is this a Cypress thing?)  I don't  
>> remember this being an issue with Monticello;  in MC, method  
>> timestamps come in with the method, and don't change to the time  
>> the method was loaded, right?
>>
>> MCModification
>>        obsoletion timeStamp = ' 7/30/2020 22:03:37'
>>        modification timeStamp = ' 7/30/2020 22:01:38'
>>
>> 2) When I delete the *extension method category "*grease-squeak5- 
>> core" from BlockContext and create my commit,
>> carefully Cmd-X'ing the methods that only have a different  
>> timestamp, there becomes two issues with my actual commit:
>> 2a) All the *Extensions methods are still part of my commit, even  
>> though I Cmd-X'd all but one of them (do I recall right that this  
>> this a Monticello bug/feature?  It's all *Extensions or none?)
>> 2b) When I menu-click my commit in Git Browser and "compare with  
>> parent commit," my commit now shows the method timestamps as being  
>> different in a different way:  the /time/ is the same, but now one  
>> method has a leading space in its string and one doesn't:
>>
>> MCModification
>>        obsoletion timeStamp = ' 7/30/2020 20:27:03'
>>        modification timeStamp = '7/30/2020 20:27:03'
>>
>> 3) If I try to checkout a new branch off the top commit, or off a  
>> package, I eventually end up with a Warning dialog that contains  
>> this:
>>
>> This package depends on the following classes:
>>  TBehavior
>> You must resolve these dependencies before you will be able to load  
>> these definitions:
>>  TBehavior>>fullName
>>
>> I can click Proceed a dozen times, but eventually I get to a DNU.
>>
>>
>> ...
>> So, I don't really know what to do.  What am I doing wrong?  Should  
>> I file a bug report or two with Squot?  Learn Cypress?  Hmm.
>>
>>
>> A basic way to set up a test case is (not sure if order matters?):
>>
>> 1) Fresh 5.3 image, load Git Browser
>> 2) In Git Browser, tell it not to "add my first project now";  I  
>> will menu-click, clone project, enter https://github.com/SeasideSt/Grease.git 
>> , create a new folder, watch in awe as it gets checked out (this is  
>> cool!)
>> 3) load Grease via [1]
>> 4) Try something like:
>> 4a) menu-click 'repository/Grease-Squeak5-Core.package' and then  
>> Checkout, and inspect the diffs to see the different timestamps
>> 4b) "Create new branch at this commit" (I just tried this, got "Key  
>> not found: repository/Grease-Core.package")
>> 4c) remove (Cmd-X) BlockContext's "*grease-squeak5-core" method  
>> category, then (wow, I just did this, and it actually resulted in a  
>> EXC_CRASH in copyToOldSpacebytesformat + 90 (gcc3x-cointerp.c: 
>> 40614), old VM 5.0.201811061137)
>>
>> Hmm.  I'm no stranger to Git, nor a stranger to Monticello, but  
>> this is all new.
>>
>> Thanks,
>> Tim
>>
>>
>> [1] Metacello new
>>    baseline: 'Grease';
>>    githubUser: 'SeasideSt' project: 'Grease' commitish: 'master'  
>> path: 'repository';
>>    load
>>
>>
>
>
>


From digit at sonic.net  Fri Jul 31 17:14:25 2020
From: digit at sonic.net (Tim Johnson)
Date: Fri, 31 Jul 2020 10:14:25 -0700
Subject: [squeak-dev] 5.3, focus follows mouse, image "save as..."
In-Reply-To: <2A01B8A1-A8FB-433C-8DE6-3D814FD8CCF6@sonic.net>
References: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
 <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>
 <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>
 <2A01B8A1-A8FB-433C-8DE6-3D814FD8CCF6@sonic.net>
Message-ID: <53932748-1CFC-4585-B1FA-028D9B1672E9@sonic.net>


On Jul 31, 2020, at 8:20 AM, Tim Johnson wrote:

>
> On Jul 31, 2020, at 1:12 AM, Marcel Taeumel wrote:
>
>> No, it is actually unrelated to the preference "mouse over for  
>> keyboard focus". Something else is going on in your image or  
>> platform. :-)
>>
>
> OK, thanks.  I guess I should have tried more permutations of VM and  
> image and keyboards before posting.
>
> "But it works in 5.2..."  Hmm.

Yes, upon further contemplation, and with the input that it doesn't  
happen on other platforms, I think I must have been running into the  
"modifier keys get stuck when Cmd-Tab is hit to switch away from  
Squeak on OS X" issue.  So, while I thought I was hitting "return",  
the image actually thought I was hitting opt-return, or cmd-return, or  
shift-return, etc.  This issue was so prevalent on macOS / OS X that I  
actually got into the habit of hitting shift - ctrl - option - cmd in  
rapid succession whenever switching back to Squeak using Cmd-Tab.  But  
I've forgotten about the issue lately because I've been using other  
environments.

This issue is also why I wrote ModifierKeysMorph:  https://github.com/tcj/ModifierKeysMorph 
    :)

Thanks, and sorry for the noise.

Tim



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/ae9da67c/attachment.html>

From tim at rowledge.org  Fri Jul 31 17:56:57 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 31 Jul 2020 10:56:57 -0700
Subject: [squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3,
 focus follows mouse, image "save as...")
In-Reply-To: <23539013-D464-4CC6-89B2-26B451C2338E@sonic.net>
References: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
 <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>
 <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>
 <CA+ovNC7szOijXZQ3RuwoDHBikKhoVGkX58WXvAbY+hQfmE5N_Q@mail.gmail.com>
 <CA+ovNC4NVpEgmdfYzehDJ1FYkd1L+Czh+vp9OYKmyrNLz5cfmg@mail.gmail.com>
 <23539013-D464-4CC6-89B2-26B451C2338E@sonic.net>
Message-ID: <A7AF4734-9469-4177-9056-336C22B48837@rowledge.org>



> On 2020-07-31, at 8:24 AM, Tim Johnson <digit at sonic.net> wrote:
> 
> If Cmd-s is a shortcut for "accept" (which I think it is, throughout most of Squeak), and in this dialog, "accept" (i.e. the "accept" button) saves the image with the new name and closes the dialog, then Cmd-s should perform the "accept" operation, which closes the dialog.
> 
> I don't mean to defend this metaphor, but it seems consistent throughout most of Squeak...

I'm pretty much in agreement here; we use cmd-s all over the place as 'save/finish/accept' and it makes sense (to me) for a lot of dialogues. *but*

It would be a problem in dialogues with several input fields though; see for example the SqueakMap edit tool. It could be a problem for dialogues where we allow longer text that might have CRs. We do need to keep it possible to close/accept/cancel with just keyboard input as well.

Possibly it would also help to make the text field in such dialogues *not* have the stuff-changed-triangle; that might be a cue that you don't use cmd-s in it?


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- She doesn't suffer from insanity; she enjoys every minute of it.



From eliot.miranda at gmail.com  Fri Jul 31 18:56:57 2020
From: eliot.miranda at gmail.com (Eliot Miranda)
Date: Fri, 31 Jul 2020 11:56:57 -0700
Subject: [squeak-dev] Anyone else want these in trunk? Anyone not want these
	in trunk?
Message-ID: <CAC20JE0Mg=3vdp4QDQsQ4idAnq9MmcHOykOcULeLxDZe4W-YEw@mail.gmail.com>

SequenceableCollection methods for accessing
indicesOfSubCollection: aSubCollection
"Answer an Array (possibly empty) of all the indices of aSubCollection in
the receiver."

^self indicesOfSubCollection: aSubCollection startingAt: 1

indicesOfSubCollection: aSubCollection startingAt: initialIndex
"Answer an Array (possibly empty) of all the indices of aSubCollection in
the receiver starting at
initialIndex. N.B. This does not (yet) use Boyer-Moore to skip over
unnecessary alignments."

^Array streamContents:
[:s| | index |
index := initialIndex - 1.
[(index := self indexOfSubCollection: aSubCollection startingAt: index + 1)
= 0] whileFalse:
[s nextPut: index]]
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/5a052dbb/attachment.html>

From asqueaker at gmail.com  Fri Jul 31 20:46:32 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Fri, 31 Jul 2020 15:46:32 -0500
Subject: [squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3,
 focus follows mouse, image "save as...")
In-Reply-To: <A7AF4734-9469-4177-9056-336C22B48837@rowledge.org>
References: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
 <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>
 <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>
 <CA+ovNC7szOijXZQ3RuwoDHBikKhoVGkX58WXvAbY+hQfmE5N_Q@mail.gmail.com>
 <CA+ovNC4NVpEgmdfYzehDJ1FYkd1L+Czh+vp9OYKmyrNLz5cfmg@mail.gmail.com>
 <23539013-D464-4CC6-89B2-26B451C2338E@sonic.net>
 <A7AF4734-9469-4177-9056-336C22B48837@rowledge.org>
Message-ID: <CANzdToH+4PQhvSJ8Lhrfy7WoG5R94FD+KJ8vKKGPVGc=fewqYg@mail.gmail.com>

Hi Tim and tim,   :)

> On 2020-07-31, at 8:24 AM, Tim Johnson <digit at sonic.net> wrote:
> >
> > If Cmd-s is a shortcut for "accept" (which I think it is, throughout
> most of Squeak), and in this dialog, "accept" (i.e. the "accept" button)
> saves the image with the new name and closes the dialog, then Cmd-s should
> perform the "accept" operation, which closes the dialog.
> >
> > I don't mean to defend this metaphor, but it seems consistent throughout
> most of Squeak...
>
> I'm pretty much in agreement here; we use cmd-s all over the place as
> 'save/finish/accept' and it makes sense (to me) for a lot of dialogues.


Me too.  +1


> *but*
>
> It would be a problem in dialogues with several input fields though; see
> for example the SqueakMap edit tool.


That's different.  Not modal.  Just like the code browser, where you don't
want Cmd+s to close the code browser.  But for modal dialogs, yes, and,
before FileDialog, "save image as..." did, via the standard
FillInTheBlank.  I miss it terribly, and remain strongly against even the
*concept* of presenting a FileDialog to the user for "save image as..." as
well as for saving and loading preferences.  It's appropriate for adding
Monticello DirectoryRepositories, because that's *what that use-case is
about* but, IMO, it's actually harmful in those other ones.

It could be a problem for dialogues where we allow longer text that might
> have CRs.


Actually, that's where Cmd+s *is* useful isn't it?  So that Return can
insert the CR's instead of accepting the dialog..?


> We do need to keep it possible to close/accept/cancel with just keyboard
> input as well.
>

+1


>
> Possibly it would also help to make the text field in such dialogues *not*
> have the stuff-changed-triangle; that might be a cue that you don't use
> cmd-s in it?
>

-1

Best,
  Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/d0f2f2b9/attachment.html>

From asqueaker at gmail.com  Fri Jul 31 20:59:32 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Fri, 31 Jul 2020 15:59:32 -0500
Subject: [squeak-dev] Anyone else want these in trunk? Anyone not want
 these in trunk?
In-Reply-To: <CAC20JE0Mg=3vdp4QDQsQ4idAnq9MmcHOykOcULeLxDZe4W-YEw@mail.gmail.com>
References: <CAC20JE0Mg=3vdp4QDQsQ4idAnq9MmcHOykOcULeLxDZe4W-YEw@mail.gmail.com>
Message-ID: <CANzdToG0y=LBKCkm5bsL0rMxEmB125XjM=st4gx02q-3hdRVeQ@mail.gmail.com>

Hi Eliot,

I have no opinion about the inclusion of the methods, only about the
variable name "aSubCollection".  Anytime I see a variable named with prefix
"a" or "an", I consider what follows to be a class in the system.  In fact,
the IDE does, too, which is why you can simply double-click on the argument
and it'll open a browser on that class.  Since "SubCollection" is already
part of the selector, "aCollection" seems like it should be a fine
argument.  Otherwise, "subCollection" (as in the legacy method you're
calling) or "aSequenceableCollection".

Best,
  Chris


On Fri, Jul 31, 2020 at 1:57 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> SequenceableCollection methods for accessing
> indicesOfSubCollection: aSubCollection
> "Answer an Array (possibly empty) of all the indices of aSubCollection in
> the receiver."
>
> ^self indicesOfSubCollection: aSubCollection startingAt: 1
>
> indicesOfSubCollection: aSubCollection startingAt: initialIndex
> "Answer an Array (possibly empty) of all the indices of aSubCollection in
> the receiver starting at
> initialIndex. N.B. This does not (yet) use Boyer-Moore to skip over
> unnecessary alignments."
>
> ^Array streamContents:
> [:s| | index |
> index := initialIndex - 1.
> [(index := self indexOfSubCollection: aSubCollection startingAt: index +
> 1) = 0] whileFalse:
> [s nextPut: index]]
> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/587ee94a/attachment.html>

From asqueaker at gmail.com  Fri Jul 31 21:09:52 2020
From: asqueaker at gmail.com (Chris Muller)
Date: Fri, 31 Jul 2020 16:09:52 -0500
Subject: [squeak-dev] The Inbox: Monticello-cmm.727.mcz
In-Reply-To: <E1k0xYu-00068W-Rs@andreas>
References: <E1k0xYu-00068W-Rs@andreas>
Message-ID: <CANzdToHHNvn5GTCySfFG-fubAnts=vd1fX+W34GCpkpDsFp_0w@mail.gmail.com>

Hi Eliot and all,

If we can get away with only alphabetizing on the "all" view (when no
WorkingCopy selected), we can avoid introducing a new feature or preference
at this time.  Is it sufficient for the VMMaker use-case?

 - Chris

On Wed, Jul 29, 2020 at 8:40 PM <commits at source.squeak.org> wrote:

> Chris Muller uploaded a new version of Monticello to project The Inbox:
> http://source.squeak.org/inbox/Monticello-cmm.727.mcz
>
> ==================== Summary ====================
>
> Name: Monticello-cmm.727
> Author: cmm
> Time: 29 July 2020, 8:40:44.842148 pm
> UUID: eb7cbccc-3b20-44ca-8e11-0dc93308a362
> Ancestors: Monticello-mt.725
>
> Sort the repository list when no WorkingCopy is selected.
>
> =============== Diff against Monticello-mt.725 ===============
>
> Item was changed:
>   ----- Method: MCWorkingCopyBrowser>>repositories (in category 'morphic
> ui') -----
>   repositories
>         | repositories |
>         repositories := self repositoryGroup repositories.
> +       ^ workingCopy
> +               ifNil: [{repositories first}, (repositories allButFirst
> sort: #description ascending)]
> +               ifNotNil: [ repositories ]!
> -       ^{repositories first}, (repositories allButFirst sort: [:r1 :r2|
> r1 description < r2 description])!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/3b958582/attachment.html>

From ron at usmedrec.com  Fri Jul 31 22:16:43 2020
From: ron at usmedrec.com (Ron Teitelbaum)
Date: Fri, 31 Jul 2020 18:16:43 -0400
Subject: [squeak-dev] Anyone else want these in trunk? Anyone not want
 these in trunk?
In-Reply-To: <CANzdToG0y=LBKCkm5bsL0rMxEmB125XjM=st4gx02q-3hdRVeQ@mail.gmail.com>
References: <CAC20JE0Mg=3vdp4QDQsQ4idAnq9MmcHOykOcULeLxDZe4W-YEw@mail.gmail.com>
 <CANzdToG0y=LBKCkm5bsL0rMxEmB125XjM=st4gx02q-3hdRVeQ@mail.gmail.com>
Message-ID: <CAEzdQ-ew6qzRHP=ZO+3VG2KW_ueME2dSsYGnPn7sMAL1-ds8eA@mail.gmail.com>

'this is great' indicesOfSubCollection: 'is' #(3 6)

:)
Ron

On Fri, Jul 31, 2020 at 4:59 PM Chris Muller <asqueaker at gmail.com> wrote:

> Hi Eliot,
>
> I have no opinion about the inclusion of the methods, only about the
> variable name "aSubCollection".  Anytime I see a variable named with prefix
> "a" or "an", I consider what follows to be a class in the system.  In fact,
> the IDE does, too, which is why you can simply double-click on the argument
> and it'll open a browser on that class.  Since "SubCollection" is already
> part of the selector, "aCollection" seems like it should be a fine
> argument.  Otherwise, "subCollection" (as in the legacy method you're
> calling) or "aSequenceableCollection".
>
> Best,
>   Chris
>
>
> On Fri, Jul 31, 2020 at 1:57 PM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>>
>> SequenceableCollection methods for accessing
>> indicesOfSubCollection: aSubCollection
>> "Answer an Array (possibly empty) of all the indices of aSubCollection in
>> the receiver."
>>
>> ^self indicesOfSubCollection: aSubCollection startingAt: 1
>>
>> indicesOfSubCollection: aSubCollection startingAt: initialIndex
>> "Answer an Array (possibly empty) of all the indices of aSubCollection in
>> the receiver starting at
>> initialIndex. N.B. This does not (yet) use Boyer-Moore to skip over
>> unnecessary alignments."
>>
>> ^Array streamContents:
>> [:s| | index |
>> index := initialIndex - 1.
>> [(index := self indexOfSubCollection: aSubCollection startingAt: index +
>> 1) = 0] whileFalse:
>> [s nextPut: index]]
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/cc8c5875/attachment.html>

From tim at rowledge.org  Fri Jul 31 23:10:22 2020
From: tim at rowledge.org (tim Rowledge)
Date: Fri, 31 Jul 2020 16:10:22 -0700
Subject: [squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3,
 focus follows mouse, image "save as...")
In-Reply-To: <CANzdToH+4PQhvSJ8Lhrfy7WoG5R94FD+KJ8vKKGPVGc=fewqYg@mail.gmail.com>
References: <F08DCF91-9565-4A2D-A770-6B6710EA9591@sonic.net>
 <Mailbird-1f944d85-ebdd-4371-abce-b7cb62aedef8@hpi.de>
 <Mailbird-3359af8a-2e96-48f0-b6e2-66650d3c3031@hpi.de>
 <CA+ovNC7szOijXZQ3RuwoDHBikKhoVGkX58WXvAbY+hQfmE5N_Q@mail.gmail.com>
 <CA+ovNC4NVpEgmdfYzehDJ1FYkd1L+Czh+vp9OYKmyrNLz5cfmg@mail.gmail.com>
 <23539013-D464-4CC6-89B2-26B451C2338E@sonic.net>
 <A7AF4734-9469-4177-9056-336C22B48837@rowledge.org>
 <CANzdToH+4PQhvSJ8Lhrfy7WoG5R94FD+KJ8vKKGPVGc=fewqYg@mail.gmail.com>
Message-ID: <1BF15B5B-B058-4AF0-85CC-3B1E9702F736@rowledge.org>



> On 2020-07-31, at 1:46 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
>  But for modal dialogs, yes, and, before FileDialog, "save image as..." did, via the standard FillInTheBlank.

<return> works to accept anything you type in the filename field. cmd-S not working is purely down to whatever key filtering wotsit got added and I accept no responsibility for that.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
A hacker does for love what others would not do for money.