[Pharo-users] How to show the process name in the debugger?

[Stewart MacLean]

Hi,

I am working on a multi green and OS threaded implementation of Apple's
Bonjour service discovery.

I'd like to show the current Smalltalk process name in the Halt window
title.

Any clues are very much appreciated.

Thanks,

Stewart

[Pharo-users] Re: How to show the process name in the debugger?

[Norbert Hartl]

Try

Processor activeProcess name 

regards,

Norbert

> Am 26.04.2022 um 10:45 schrieb Stewart MacLean :
> 
> Hi,
> 
> I am working on a multi green and OS threaded implementation of Apple's 
> Bonjour service discovery.
> 
> I'd like to show the current Smalltalk process name in the Halt window title.
> 
> Any clues are very much appreciated.
> 
> Thanks,
> 
> Stewart

[Pharo-users] Re: How to show the process name in the debugger?

[Steven Costiou]

Hi, 

in Pharo 9-11, from the StDebugger you can access the debugged process
using 

self session interruptedProcess name 

In the debugger class you can prepend that instruction in the window
title update methods: 

StDebugger>>initializeWindow: aWindowPresenter

super initializeWindow: aWindowPresenter.
aWindowPresenter
title: self session interruptedProcess name , ': '
, self debuggerActionModel statusStringForContext;
initialExtent: self initialExtent;
whenClosedDo: [ self clear ].

self initializeShortcuts: aWindowPresenter 

StDebugger>>newTitle

^ self session interruptedProcess name , ': '
  , self debuggerActionModel statusStringForContext 

There is no other ways yet to customize the window title. 

I do not know how to do it in prior versions of Pharo. 

Steven. 

Le 2022-04-26 10:45, Stewart MacLean a écrit :

> Hi, 
> 
> I am working on a multi green and OS threaded implementation of Apple's 
> Bonjour service discovery. 
> 
> I'd like to show the current Smalltalk process name in the Halt window title. 
> 
> Any clues are very much appreciated. 
> 
> Thanks, 
> 
> Stewart

  

[Pharo-users] Re: A question about #beginsWith: and #endsWith:

[Steffen Märcker]

I can only fully agree to Richard's explanation. Also, not having the empty
string pre/suf-fixing every string breaks the free monoid that describes
concatenation of strings and forms the basis of regular expressions. In
effect, this will lead to subtle inconsistencies. Hence, I consider this a
bug rather than a feature.


Kind regards,
Steffen





Richard O'Keefe schrieb am Samstag, 23. April 2022 02:37:48 (+02:00):


Dan Ingalls is of course a big NAME in the
world of Smalltalk, but the stated reason
for changing the behaviour of #beginsWith:
and #endsWith: makes no sense.




We have many ways to define a partial order
on strings.
x <= y iff y beginsWith: x
x <= y iff y endsWith: x
x <= y iff y includesSubCollection: x
x <= y iff y includesSubSequence: x
These things are supposed to obey laws:
if a beginsWith: b , c
then a beginsWith: b
if a endsWith: b , c
then a endsWith: c
if a includesSubCollection: b , c
then a includesSubCollection: b
and a includesSubCollection: c
if a includesSubSequence: b , c
then a includesSubSequence: b
and a includesSubSequence: c.


We also expect the usual rules of equality
to hold.  So
(1) a beginsWith: a
(2) a = '' , a
(3) THEREFORE a beginsWith: ''


(1) a endsWith: a
(2) a = a , ''
(3) THEREFORE a endsWith: ''


(1) a includesSubCollection: a
(2) a = '' , a
(3) THEREFORE a includesSubCollect: ''


Reasoning about strings (as values) gets
enormously more complicated if the operations
do not follow simple sensible rules, and
having '' be the least string under these
orderings and having '' be a prefix and a
suffix of any string is essential if the
rules are going to be simple and coherent.


'' is to strings (and more generally
empty sequences are to sequences) pretty
much what 0 is to integers.   Denying that
'abc' beginsWith: '' is *structurally*
just like denying that 0 <= 123.


Now as it happens I *can* see a use for
versions of #beginsWith: and #endsWith:
that diverge from the ones we have, but
*this* is not where they need to diverge.
a beginsWithGraphemesOf: b
iff a asGraphemes = b asGraphemes , c asGraphemes
for some c, where s asGraphemes returns a
sequence of strings each of which is a maximally
long grapheme cluster, such that concatenating
s asGraphemes recovers s.  That is,
#beginsWithGraphemesOf: and
#endsWithGraphemesOf: would respect the
Unicode Text Segmentation boundaries.
But s beginsWithGraphemesOf: ''
would still need to be true.


The thing is, in practice you often DON'T
KNOW whether a potential affix is empty or
not.  Here are some of my test cases.


testTestData
  "Ensure that the sample string has no duplicates."
  [(Set withAll: string) size = stringSize] assert.

testBeginsWith
  "Test that every prefix of the sample IS a prefix of it."
  0 to: stringSize do: [:n |
[string beginsWith: (string copyFrom: 1 to: n)] assert].

testEndsWith
  "Test that every suffix of the sample IS a suffix of it."
  0 to: stringSize do: [:n |
[string endsWith: (string copyFrom: stringSize - n + 1 to:
stringSize)] assert].

testIndexOfSubCollectionAtBeginning
  "Test that every prefix of 'abcd' is found at the beginning."
  0 to: stringSize do: [:n | |s i t|
s := string copyFrom: 1 to: n.
i := string indexOfSubCollection: s startingAt: 1.
[1 = i] assert.
t := string copyFrom: i to: i - 1 + n.
[t = s] assert].

testIndexOfSubCollectionAtEnd
  "Test that every proper suffix of the sample is found at the end."
  1 to: stringSize do: [:n | |s i t|
s := string copyFrom: stringSize - n + 1 to: stringSize.
i := string indexOfSubCollection: s startingAt: 1.
[stringSize + 1 - n = i] assert.
t := string copyFrom: i to: i - 1 + n.
[t = s] assert].

testLastIndexOfSubCollectionAtBeginning
  "Test that every proper prefix of the sample is found at the
beginning."
  1 to: stringSize do: [:n | |s i t|
s := string copyFrom: 1 to: n.
i := string lastIndexOfSubCollection: s startingAt: stringSize.
[1 = i] assert.
t := string copyFrom: i to: i - 1 + n.
[t = s] assert].

testLastIndexOfSubCollectionAtEnd
  "Test that every suffix of the sample is found at the end."
  0 to: stringSize do: [:n | |s i t|
s := string copyFrom: stringSize - n + 1 to: stringSize.
i := string lastIndexOfSubCollection: s startingAt: stringSize.
[stringSize + 1 - n = i] assert.
t := string copyFrom: i to: i - 1 + n.
[t = s] assert].

testOccurrencesOfEmptyCollection
  "Test that the empty string occurs at the beginning,
   at the end, and in between every pair of adjacent characters."
  [(string occurrencesOfSubCollection: '') = (stringSize + 1)] assert.

testOccurrencesOfUniqueParts
  "Test that unique parts occur as many times as they should."
  |repeated|
  repeated := string , string , string.
  1 to: stringSiz

[Pharo-users] Re: A question about #beginsWith: and #endsWith:

[Kasper Osterbye]

I have now raised it as an issue on the issue tracker

Issue #11165  in 
https://github.com/pharo-project/pharo/issues/11165 



Best,

Kasper

> On 26 Apr 2022, at 12.11, Steffen Märcker  wrote:
> 
> I can only fully agree to Richard's explanation. Also, not having the empty 
> string pre/suf-fixing every string breaks the free monoid that describes 
> concatenation of strings and forms the basis of regular expressions. In 
> effect, this will lead to subtle inconsistencies. Hence, I consider this a 
> bug rather than a feature.
> 
> Kind regards,
> Steffen

[Pharo-users] Re: A question about #beginsWith: and #endsWith:

[Richard O'Keefe]

I discovered that my own code-base was inconsistent due
to sometimes following Pharo and sometimes not.  I've just
spent the last day making it consistent and you would not
BELIEVE how many methods suddenly became simpler.

I finally understood why some of the test cases I had
for XPath were broken.  XPath specifies that the empty
string is a prefix and suffix of every string.

Perhaps better support for XPath may have some
persuasive value.  (Though support for XPath collations
will be a long way off.  There's a LOT of other Unicode
support I need to develop first.)

On Tue, 26 Apr 2022 at 22:12, Steffen Märcker  wrote:

> I can only fully agree to Richard's explanation. Also, not having the
> empty string pre/suf-fixing every string breaks the free monoid that
> describes concatenation of strings and forms the basis of regular
> expressions. In effect, this will lead to subtle inconsistencies. Hence, I
> consider this a bug rather than a feature.
>
> Kind regards,
> Steffen
>
>
>
> Richard O'Keefe schrieb am Samstag, 23. April 2022 02:37:48 (+02:00):
>
> Dan Ingalls is of course a big NAME in the
> world of Smalltalk, but the stated reason
> for changing the behaviour of #beginsWith:
> and #endsWith: makes no sense.
>
>
> We have many ways to define a partial order
> on strings.
> x <= y iff y beginsWith: x
> x <= y iff y endsWith: x
> x <= y iff y includesSubCollection: x
> x <= y iff y includesSubSequence: x
> These things are supposed to obey laws:
> if a beginsWith: b , c
> then a beginsWith: b
> if a endsWith: b , c
> then a endsWith: c
> if a includesSubCollection: b , c
> then a includesSubCollection: b
> and a includesSubCollection: c
> if a includesSubSequence: b , c
> then a includesSubSequence: b
> and a includesSubSequence: c.
>
> We also expect the usual rules of equality
> to hold.  So
> (1) a beginsWith: a
> (2) a = '' , a
> (3) THEREFORE a beginsWith: ''
>
> (1) a endsWith: a
> (2) a = a , ''
> (3) THEREFORE a endsWith: ''
>
> (1) a includesSubCollection: a
> (2) a = '' , a
> (3) THEREFORE a includesSubCollect: ''
>
> Reasoning about strings (as values) gets
> enormously more complicated if the operations
> do not follow simple sensible rules, and
> having '' be the least string under these
> orderings and having '' be a prefix and a
> suffix of any string is essential if the
> rules are going to be simple and coherent.
>
> '' is to strings (and more generally
> empty sequences are to sequences) pretty
> much what 0 is to integers.   Denying that
> 'abc' beginsWith: '' is *structurally*
> just like denying that 0 <= 123.
>
> Now as it happens I *can* see a use for
> versions of #beginsWith: and #endsWith:
> that diverge from the ones we have, but
> *this* is not where they need to diverge.
> a beginsWithGraphemesOf: b
> iff a asGraphemes = b asGraphemes , c asGraphemes
> for some c, where s asGraphemes returns a
> sequence of strings each of which is a maximally
> long grapheme cluster, such that concatenating
> s asGraphemes recovers s.  That is,
> #beginsWithGraphemesOf: and
> #endsWithGraphemesOf: would respect the
> Unicode Text Segmentation boundaries.
> But s beginsWithGraphemesOf: ''
> would still need to be true.
>
> The thing is, in practice you often DON'T
> KNOW whether a potential affix is empty or
> not.  Here are some of my test cases.
>
> testTestData
>   "Ensure that the sample string has no duplicates."
>   [(Set withAll: string) size = stringSize] assert.
>
> testBeginsWith
>   "Test that every prefix of the sample IS a prefix of it."
>   0 to: stringSize do: [:n |
> [string beginsWith: (string copyFrom: 1 to: n)] assert].
>
> testEndsWith
>   "Test that every suffix of the sample IS a suffix of it."
>   0 to: stringSize do: [:n |
> [string endsWith: (string copyFrom: stringSize - n + 1 to:
> stringSize)] assert].
>
> testIndexOfSubCollectionAtBeginning
>   "Test that every prefix of 'abcd' is found at the beginning."
>   0 to: stringSize do: [:n | |s i t|
> s := string copyFrom: 1 to: n.
> i := string indexOfSubCollection: s startingAt: 1.
> [1 = i] assert.
> t := string copyFrom: i to: i - 1 + n.
> [t = s] assert].
>
> testIndexOfSubCollectionAtEnd
>   "Test that every proper suffix of the sample is found at the end."
>   1 to: stringSize do: [:n | |s i t|
> s := string copyFrom: stringSize - n + 1 to: stringSize.
> i := string indexOfSubCollection: s startingAt: 1.
> [stringSize + 1 - n = i] assert.
> t := string copyFrom: i to: i - 1 + n.
> [t = s] assert].
>
> testLastIndexOfSubCollectionAtBeginning
>   "Test that every proper prefix of the sample is found at the
> beginning."
>   1 to: stringSize do: [:n | |s i t|
> s := string copyFrom: 1 to: n.
> i := string lastIndexOfSubCollection: s startingAt: stringSize.
> [1 = i] assert.
> t := string copyFrom: i to: i - 1 + n.

[Pharo-users] Re: A question about #beginsWith: and #endsWith:

[Steffen Märcker]

Maybe I should add an example. Consider the following natural proposition:


> (A, B) beginsWith: A and: [(A, B) endsWith: B]


This breaks for A := '' or B := '' ".


Best, Steffen



Kasper Osterbye schrieb am Dienstag, 26. April 2022 14:50:51 (+02:00):


I have now raised it as an issue on the issue tracker


Issue #11165 in https://github.com/pharo-project/pharo/issues/11165




Best,


Kasper



On 26 Apr 2022, at 12.11, Steffen Märcker  wrote:


I can only fully agree to Richard's explanation. Also, not having the empty 
string pre/suf-fixing every string breaks the free monoid that describes 
concatenation of strings and forms the basis of regular expressions. In effect, 
this will lead to subtle inconsistencies. Hence, I consider this a bug rather 
than a feature.


Kind regards,
Steffen




-- 
Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

[Pharo-users] [ANN] docker-pharo-runtime v10.0.0-1.0.0 [v10.0.0 + 1.0.0] released!

[Buenos Aires Smalltalk]

docker-pharo-runtime, docker image for Pharo reached it's v10.0.0-1.0.0 version.
Changelog
Docker image for running a headless Pharo Image on top of Pharo VM 9.0.14.
Pharo version
Pharo-10.0.0+build.512.sha.bfb3a61094b9b7409b265d3f15a3d126b4ef597c (64 Bit)
VM: v9.0.14 - Commit: 93600e1 - Date: 2022-03-30 16:40:05 +0200

Quickstart
docker run -it ghcr.io/ba-st/pharo-vm:v10.0.0 pharo eval 2+2

Regards,
The Buenos Aires Smalltalk team

[Pharo-users] Re: How to show the process name in the debugger?

[Stewart MacLean]

Thanks Steven - exactly what I needed to know!

Cheers,

Stewart

On Tue, Apr 26, 2022 at 10:08 PM Steven Costiou 
wrote:

> Hi,
>
> in Pharo 9-11, from the StDebugger you can access the debugged process
> using
>
> self session interruptedProcess name
>
> In the debugger class you can prepend that instruction in the window title
> update methods:
>
> StDebugger>>initializeWindow: aWindowPresenter
>
> super initializeWindow: aWindowPresenter.
> aWindowPresenter
> title: self session interruptedProcess name , ': '
> , self debuggerActionModel statusStringForContext;
> initialExtent: self initialExtent;
> whenClosedDo: [ self clear ].
>
> self initializeShortcuts: aWindowPresenter
>
>
>
> StDebugger>>newTitle
>
> ^ self session interruptedProcess name , ': '
>   , self debuggerActionModel statusStringForContext
>
>
>
> There is no other ways yet to customize the window title.
>
> I do not know how to do it in prior versions of Pharo.
>
> Steven.
>
>
>
> Le 2022-04-26 10:45, Stewart MacLean a écrit :
>
> Hi,
>
> I am working on a multi green and OS threaded implementation of Apple's
> Bonjour service discovery.
>
> I'd like to show the current Smalltalk process name in the Halt window
> title.
>
> Any clues are very much appreciated.
>
> Thanks,
>
> Stewart
>
>
>

[Pharo-users] Re: How to show the process name in the debugger?

[Stewart MacLean]

Thanks Norbert - I was meaning how to show it in the title of the Debugger
for when I get a lot of debuggers on different processes.

Please see Steven Costiou's solution.

Cheers,

Stewart

On Tue, Apr 26, 2022 at 9:57 PM Norbert Hartl  wrote:

> Try
>
> Processor activeProcess name
>
> regards,
>
> Norbert
>
> > Am 26.04.2022 um 10:45 schrieb Stewart MacLean :
> >
> > Hi,
> >
> > I am working on a multi green and OS threaded implementation of Apple's
> Bonjour service discovery.
> >
> > I'd like to show the current Smalltalk process name in the Halt window
> title.
> >
> > Any clues are very much appreciated.
> >
> > Thanks,
> >
> > Stewart
>