[Pharo-users] AST vs. Bytecode Interpreters

[Steffen Märcker]

Hi folks!

Today I found this interesting paper via Stefan Marr on the performance
differences of ast vs. bytecode interpreters (for meta compilation):
https://stefan-marr.de/downloads/oopsla23-larose-et-al-ast-vs-bytecode-interpreters-in-the-age-of-meta-compilation.pdf


It was a really interesting read. I do not remember seeing this on the
list. If it was, please apologize double posting.

Cheers!
Steffen

[Pharo-users] Packages

[Steffen Märcker]

Hi,

is there a way to create an empty package programatically, and how do I
rename a package programmatically? Is there a documentation about packages
and how exactly their naming scheme relates to tags?

Kind regards,
Steffen

[Pharo-users] Re: Porting from VW to Pharo

[Steffen Märcker]

Hi Christian!


I'll have a look. Over the weekend, I pushed a bit forward. The #category: 
worked as expected. However, I observed that Pharo seems to create packages and 
package tags implicitly. For instance: 
- If I import the VW packages "Transducers" and "Transducers Tests", two 
packages are created as expected. 
- If I import "Transducers-Tests" (note the -) instead, no new package is 
created and a new package tag is created instead.


This means, we have to be careful when porting packages including - in their 
name from VW to Pharo. So far I could not figure out how to avoid this 
automatic categorization. But maybe I am missing something as a Pharo newbee.


I was also experimenting with baselines. It would be nice to be able to define 
a baseline already in the export. For now, I created a package 
"BaselineOf" with a class of the same name. It inherits from a dummy 
class "BaselineOf" in my project transform package. It would be nice to have 
the baseline in this package too and to create the same-named package during 
the export. Is there a way to do this right now? 


I noticed in the wiki that #unusedClasses: is #ignoredNames: now, right?


Regarding crypto in PDFtalk: I was just wondering. This is quite difficult to 
do right, I am certainly missing too much knowledge to do it on my own right 
now. Maybe some day. ;-)


Important: Thank you for your kind support!


Best,
Steffen

Christian Haider schrieb am Samstag, 6. Mai 2023 19:05:22 (+02:00):



All references disentangled. Everything should be clean now.

 

Happy hacking,

Christian

 

Von: Steffen Märcker 
Gesendet: Freitag, 5. Mai 2023 10:15
An: Any question about pharo is welcome 
Betreff: [Pharo-users] Re: Porting from VW to Pharo

 

Dear Christian,

 

I just gave it a try with a virgin 64 Bit 8.3 image and loaded

* Smalltalk Transform Project

* PDFtalk Project

* Pharo FileOut PDFtalk

 

The code loaded fine but I had a few hiccups with the tests.

* Many tests use #assert:equals: which SUnitToo (loaded automatically) 
surprisingly does not provide.

* After adding this method to TestCase, all but four test run. The Pattern that 
is used to match in

  - testVASmalltalkAddTimeAndVersion

  - testSqueakAddTimeAndVersion

  - testPharoAddTimeAndVersion

  - testGemstoneAddTimeAndVersion

  Did not take PUL into account. This works: '# From VisualWorks®*, * of * on * 
at *'

* In the following tests, some selectors cannot be found:

  - testMethodAddsForValuemap - #_gs_printvalueWith:

  - testMethodAddsForObject - #_gs_Symbol_literalString

  - testWriteSystemExtensionMethods - #_gs_printvalueWith:

 

Btw, I switched to SUnit to ease Porting to Pharo. I'll have a look into the 
#category parameter today.

 

OT PDFtalk: Do you have plans to support verifying signatures in PDF files or 
singing using a certificate?

 

Kind regards,

Steffen

 

 

Christian Haider schrieb am Mittwoch, 12. April 2023 21:07:05 (+02:00):

Hi Steffen,

 

thanks for trying and asking!

 

I was loading the code needed into a 8.3, 64bit virgin image and realized that 
loading is not that straight forward and described too briefly.

First, you need a non-default setting for the store prerequisites. I added this 
to the store access page: https://wiki.pdftalk.de/doku.php?id=storeaccess . It 
is critical to load the prereqs from store and not from parcels!

 

The first thing to load is the bundle {Smalltalk Transform Project}.

To see examples you need to load the subject of transformation: PDFtalk.

You need to load to top bundle {PDFtalk Project} which includes the test 
classes you are missing in your image.

At last, load the [Pharo Fileout PDFtalk] package.

I improved the landing page 
https://wiki.pdftalk.de/doku.php?id=smalltalktransform a bit to make this 
clearer.

 

I just tried and this loads without errors or warnings.

 

(Actually good that the load did not work for you, because I added a mistake in 
January which causes a 8.3 image to crash when you open a browser. Sorry for 
that.)

 

Now you should be all set for generating a fileout of PDFtalk for Pharo (in the 
current unfinished state).

 

Thanks for spotting the problems with the documentation. I will get over it 
tomorrow.

I am quick in renaming and making structural changes when things are not 
working as I want… But the docs should be correct, of course.

 

 

About the project structure.

Currently, everything belonging to a project, need to be transformed in one go. 
This is not a big deal, because all code transformations are described on the 
package level and can be easily recombined as the bundle structure changes.

 

The last piece of the transformation puzzle is to make the transformations 
modular, so that the renamings of prerequisite packages can be used without the 
need to transform the prereqs as well. I hope to get at that soon…

In the meantime, I would start with your Core project to get a fee

[Pharo-users] Re: Porting from VW to Pharo

[Steffen Märcker]

Dear Christian,


I just gave it a try with a virgin 64 Bit 8.3 image and loaded
* Smalltalk Transform Project
* PDFtalk Project
* Pharo FileOut PDFtalk


The code loaded fine but I had a few hiccups with the tests.
* Many tests use #assert:equals: which SUnitToo (loaded automatically) 
surprisingly does not provide.
* After adding this method to TestCase, all but four test run. The Pattern that 
is used to match in
  - testVASmalltalkAddTimeAndVersion
  - testSqueakAddTimeAndVersion
  - testPharoAddTimeAndVersion
  - testGemstoneAddTimeAndVersion
  Did not take PUL into account. This works: '# From VisualWorks®*, * of * on * 
at *'
* In the following tests, some selectors cannot be found:
  - testMethodAddsForValuemap - #_gs_printvalueWith:
  - testMethodAddsForObject - #_gs_Symbol_literalString
  - testWriteSystemExtensionMethods - #_gs_printvalueWith:


Btw, I switched to SUnit to ease Porting to Pharo. I'll have a look into the 
#category parameter today.


OT PDFtalk: Do you have plans to support verifying signatures in PDF files or 
singing using a certificate?


Kind regards,
Steffen




Christian Haider schrieb am Mittwoch, 12. April 2023 21:07:05 (+02:00):



Hi Steffen,

 

thanks for trying and asking!

 

I was loading the code needed into a 8.3, 64bit virgin image and realized that 
loading is not that straight forward and described too briefly.

First, you need a non-default setting for the store prerequisites. I added this 
to the store access page: https://wiki.pdftalk.de/doku.php?id=storeaccess . It 
is critical to load the prereqs from store and not from parcels!

 

The first thing to load is the bundle {Smalltalk Transform Project}.

To see examples you need to load the subject of transformation: PDFtalk.

You need to load to top bundle {PDFtalk Project} which includes the test 
classes you are missing in your image.

At last, load the [Pharo Fileout PDFtalk] package.

I improved the landing page 
https://wiki.pdftalk.de/doku.php?id=smalltalktransform a bit to make this 
clearer.

 

I just tried and this loads without errors or warnings.

 

(Actually good that the load did not work for you, because I added a mistake in 
January which causes a 8.3 image to crash when you open a browser. Sorry for 
that.)

 

Now you should be all set for generating a fileout of PDFtalk for Pharo (in the 
current unfinished state).

 

Thanks for spotting the problems with the documentation. I will get over it 
tomorrow.

I am quick in renaming and making structural changes when things are not 
working as I want… But the docs should be correct, of course.

 

 

About the project structure.

Currently, everything belonging to a project, need to be transformed in one go. 
This is not a big deal, because all code transformations are described on the 
package level and can be easily recombined as the bundle structure changes.

 

The last piece of the transformation puzzle is to make the transformations 
modular, so that the renamings of prerequisite packages can be used without the 
need to transform the prereqs as well. I hope to get at that soon…

In the meantime, I would start with your Core project to get a feel for the 
mechanics. I am sure the rest will fall nicely into its places.

 

About how to structure your code in Pharo with Git, I don’t know much about 
that. Actually, I would also be interested in some guidelines to bake them into 
the transformations…

 

If you are seriously interested, we could have an online session to hack around 
with it…

 

Cheers,

Christian

 

 

Von: Steffen Märcker 
Gesendet: Dienstag, 11. April 2023 17:52
An: Any question about pharo is welcome 
Betreff: [Pharo-users] Re: Porting from VW to Pharo

 

Dear Christian and Richard,

 

thanks for your answers. I'll try to go through the process step by step and 
come back with questions to the list if that's okay.

 

First, after loading the "Pharo Fileout PDFTalk", VW (8.3, 64 Bit) shows two 
unloadable definitions:

- PostscriptInterpreterTests>>_ph_testOperatorNotFound
- ColorValueTest>>_ph_testBridgedNamedColors

Both classes are not loaded

 

 

 

Second, it appears that some of the selectors mentioned on 
https://wiki.pdftalk.de/doku.php?id=smalltalktransformdocumentation have been 
renamed, e.g., PackageChanges>>unusedClasses

 

More general, regarding project structure. What is the best approach to port a 
project that consists of multiple loosely coupled packages (not in a bundle) 
some of which being optional? Like

- Package Project Core

- Package Project Core Tests (requires Core)

- Package Project Extension A (requires Core)
- Package Project Extension A Tests (requires Extension A)

- Package Project Examples (requires Core and Extension A)

 

And how should I structure this on the Pharo site and in an iceberg repository? 
One Git repository per package or all in the same? Is there a guide to this or 
a specific Mooc lesson?

 

Kind regards,

Stef

[Pharo-users] Re: Picking neighbouring elements

[Steffen Märcker]

… and after the second block #map

[Pharo-users] Re: Picking neighbouring elements

[Steffen Märcker]

Coding in mail is not easy after all. SortedCollection>>greaterThan: contains a 
silly mistake from editing. At the end it should read:

   ^[:y | y = x] dropWhileTrue
  <~ [:i | self at: i]
  <~ (index to: self size)

[Pharo-users] Re: Picking neighbouring elements

[Steffen Märcker]

, and at that
point I'm no longer building a transducer out of
pluggable pieces.


So that's the point of this exercise.
How do we get
(a) composition of transducers out of pluggable parts
AND
(b) automatic selection of appropriate algorithms




On Fri, 21 Apr 2023 at 20:35, Steffen Märcker  wrote:

Hi Richard,


Now that's much clearer to me:
min{y | y in c . y > x} "strict supremum"
max{y | y in c . y < x} "strict infimum"


For the general case of a sequence (not sorted) of elements we can do


strictSupremumOf: x in: sequence


^(sequence transduce filter: [:y | y > x])  
"virtual sequence"
inject: nil
into: [:min :b | min ifNotNil: [:a | a min: b]]


I just picked a variant of minimum that answers nil if no element is found. 
Other variants would work, too.
The focus of transducers is on re-use and composition of processing steps. We 
can break this up into steps if needed:


minimum := [:min :b | min ifNotNil: [:a | a min: b]] init: nil. 
"reduction"
upperBounds := Filter predicate: [:y | y > x].  
"transducer"
strictSup := minimum transduce: upperBounds.
"transformed reduction"
^strictSup reduce: sequence


We can also use a different notation similar to a data flow:


minimum <~ upperBounds <~ sequence


Of course, if we know how the sequence is sorted, we should use another 
algorithm. Assuming an ascending order with no random access, we'd change 
minimum to stop early:


minimum := [:min :b | Stop result: b].


Kind regards,
Steffen



Richard O'Keefe schrieb am Freitag, 21. April 2023 05:33:44 (+02:00):


successor of x in c = the smallest element of c that is larger than x
 min {y | y in c . y > x}

predecessor of x in c = the largest element of c that is smaller than x
 max {y | y in c . y < x}



On Thu, 20 Apr 2023 at 21:08, Steffen Märcker  wrote:

Dear Richard,


thanks for that additional piece. I'll put insert- on my list of 
possible variants. I think we come back to naming after the initial port is 
done and everyone can play with it. Generally, I made the observation to better 
be careful with names since it's too easy to alienate other or trigger wrong 
assumptions.


New  topic! (quote below)


Honestly, my knowledge of Haskell is rather limited and rusted. Hence, I am 
having difficulties understanding what exactly these operations with a sequence 
of elements. Can you give an example or some pseude/smalltalk code from your 
use-case and library?


Kind regards


Changing the subject a wee bit, there's an operation family
in my library, and I wonder how it would fit into Transducers?
To avoid bias, here's a specification in Haskell (for lists,
because I haven't had any luck installing Data.Witherable).


uccessorBy, predecessorBy :: (a -> a -> Ordering) -> a -> [a] -> a
successor,   predecessor   :: Ord a=> a -> [a] -> a

successor = successorBy compare

successorBy cmp x = minimumBy cmp . filter (\y -> cmp x y == LT)

predecessor = predecessorBy compare

predecessorBy cmp = successorBy (flip cmp)


The reason these operations exist is to pick neighbouring
elements in SortedCollections and SortedSets.  But they make
*sense* for any Enumerable.  So there are "generic"
definitions with orderrides for those two classes.


A filter + a reduce .  Traditionally, a #select:thenFold:ifNone:
in order to avoid building an intermediate collection.  That much
I see how to do with transducers.  But you can't get the desired
override for #successor:[sortBlock:][ifNone:] by overriding
#select:thenFold:ifNone: in SortedCollection or SortedSet.  So what
*should* one do?

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

[Pharo-users] Re: Picking neighbouring elements

[Steffen Märcker]

Hi Richard,


Now that's much clearer to me:
min{y | y in c . y > x} "strict supremum"
max{y | y in c . y < x} "strict infimum"


For the general case of a sequence (not sorted) of elements we can do


strictSupremumOf: x in: sequence


^(sequence transduce filter: [:y | y > x])  
"virtual sequence"
inject: nil
into: [:min :b | min ifNotNil: [:a | a min: b]]


I just picked a variant of minimum that answers nil if no element is found. 
Other variants would work, too.
The focus of transducers is on re-use and composition of processing steps. We 
can break this up into steps if needed:


minimum := [:min :b | min ifNotNil: [:a | a min: b]] init: nil. 
"reduction"
upperBounds := Filter predicate: [:y | y > x].  
"transducer"
strictSup := minimum transduce: upperBounds.
"transformed reduction"
^strictSup reduce: sequence


We can also use a different notation similar to a data flow:


minimum <~ upperBounds <~ sequence


Of course, if we know how the sequence is sorted, we should use another 
algorithm. Assuming an ascending order with no random access, we'd change 
minimum to stop early:


minimum := [:min :b | Stop result: b].


Kind regards,
Steffen



Richard O'Keefe schrieb am Freitag, 21. April 2023 05:33:44 (+02:00):


successor of x in c = the smallest element of c that is larger than x
 min {y | y in c . y > x}

predecessor of x in c = the largest element of c that is smaller than x
 max {y | y in c . y < x}



On Thu, 20 Apr 2023 at 21:08, Steffen Märcker  wrote:

Dear Richard,


thanks for that additional piece. I'll put insert- on my list of 
possible variants. I think we come back to naming after the initial port is 
done and everyone can play with it. Generally, I made the observation to better 
be careful with names since it's too easy to alienate other or trigger wrong 
assumptions.


New  topic! (quote below)


Honestly, my knowledge of Haskell is rather limited and rusted. Hence, I am 
having difficulties understanding what exactly these operations with a sequence 
of elements. Can you give an example or some pseude/smalltalk code from your 
use-case and library?


Kind regards


Changing the subject a wee bit, there's an operation family
in my library, and I wonder how it would fit into Transducers?
To avoid bias, here's a specification in Haskell (for lists,
because I haven't had any luck installing Data.Witherable).


uccessorBy, predecessorBy :: (a -> a -> Ordering) -> a -> [a] -> a
successor,   predecessor   :: Ord a=> a -> [a] -> a

successor = successorBy compare

successorBy cmp x = minimumBy cmp . filter (\y -> cmp x y == LT)

predecessor = predecessorBy compare

predecessorBy cmp = successorBy (flip cmp)


The reason these operations exist is to pick neighbouring
elements in SortedCollections and SortedSets.  But they make
*sense* for any Enumerable.  So there are "generic"
definitions with orderrides for those two classes.


A filter + a reduce .  Traditionally, a #select:thenFold:ifNone:
in order to avoid building an intermediate collection.  That much
I see how to do with transducers.  But you can't get the desired
override for #successor:[sortBlock:][ifNone:] by overriding
#select:thenFold:ifNone: in SortedCollection or SortedSet.  So what
*should* one do?

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

[Pharo-users] Re: Picking neighbouring elements

[Steffen Märcker]

Dear Richard,


thanks for that additional piece. I'll put insert- on my list
of possible variants. I think we come back to naming after the initial port
is done and everyone can play with it. Generally, I made the observation to
better be careful with names since it's too easy to alienate other or
trigger wrong assumptions.


New  topic! (quote below)


Honestly, my knowledge of Haskell is rather limited and rusted. Hence, I am
having difficulties understanding what exactly these operations with a
sequence of elements. Can you give an example or some pseude/smalltalk code
from your use-case and library?


Kind regards


Changing the subject a wee bit, there's an operation family
in my library, and I wonder how it would fit into Transducers?
To avoid bias, here's a specification in Haskell (for lists,
because I haven't had any luck installing Data.Witherable).


uccessorBy, predecessorBy :: (a -> a -> Ordering) -> a -> [a] -> a
successor,   predecessor   :: Ord a=> a -> [a] -> a

successor = successorBy compare

successorBy cmp x = minimumBy cmp . filter (\y -> cmp x y == LT)

predecessor = predecessorBy compare

predecessorBy cmp = successorBy (flip cmp)


The reason these operations exist is to pick neighbouring
elements in SortedCollections and SortedSets.  But they make
*sense* for any Enumerable.  So there are "generic"
definitions with orderrides for those two classes.


A filter + a reduce .  Traditionally, a #select:thenFold:ifNone:
in order to avoid building an intermediate collection.  That much
I see how to do with transducers.  But you can't get the desired
override for #successor:[sortBlock:][ifNone:] by overriding
#select:thenFold:ifNone: in SortedCollection or SortedSet.  So what
*should* one do?

[Pharo-users] Re: Project and package structure recommendations

[Steffen Märcker]

Thank you both for your answers. That is certainly helpful.


- I just noticed that most (all?) package names in the Pharo image do not 
contain spaces although it is possible to create such names. Is this 
discouraged or are there issues to watch out for?
- Is there a reference how the name mangling of packages, categories and such 
works? For instance, it seems if a class def states "MyPackage-Tests" it 
appears in MyPackage under the category tests.


Kind regards,
Steffen

Noury Bouraqadi schrieb am Mittwoch, 19. April 2023 19:10:13 (+02:00):


BTW, Beside this mailing list, there is the Pharo Discord for discussions.


Noury
On Apr 19 2023, at 7:06 pm, Gabriel Cotelli  wrote:
Most projects that I'm aware of, follow something like this:
- 1 project per git repository
- One or more packages for the functional part, separate packages for the tests 
(because if you only use categories you can't load only the runtime required 
code and exclude the tests)
- If your project has optional parts, and this code is in different packages 
you can provide in the Baseline "groups" for loading sub-sets of the packages 


Usually, we use https://github.com/ba-st/GitHub-setup for generating the 
initial boilerplate of new projects.


Regards,
Gabriel


On Wed, Apr 19, 2023 at 12:55 PM Steffen Märcker  wrote:
Hi,


I'd like to ask for your advice or best practices regarding the package
structure of a project. So far I have understood:
- Iceberg can store multiple packages (project?) in a git repository
- A package (or multiple?) and its dependencies is loaded via a baseline
- A package can have flags (= categories?)


Suppose, a project has
- A core part
- One or multipel optional parts, that a user may or may not want to load,
too
- Tests for the core
- Tests for each optional part


What's the recommended way to structure this in Pharo? For example, I've
seen that some code in Pharo has its tests in the same package but
flagged/categorized, other code has a separate package for tests. Also, can
a (git) repository have multiple baselines?


Sorry, if I am asking the obvious but I did not manage to find guidlines in
the documentation yet. It might very well an oversight be myself.


Kind regards,
Steffen

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

[Pharo-users] Project and package structure recommendations

[Steffen Märcker]

Hi,

I'd like to ask for your advice or best practices regarding the package
structure of a project. So far I have understood:
- Iceberg can store multiple packages (project?) in a git repository
- A package (or multiple?) and its dependencies is loaded via a baseline
- A package can have flags (= categories?)

Suppose, a project has
- A core part
- One or multipel optional parts, that a user may or may not want to load,
too
- Tests for the core
- Tests for each optional part

What's the recommended way to structure this in Pharo? For example, I've
seen that some code in Pharo has its tests in the same package but
flagged/categorized, other code has a separate package for tests. Also, can
a (git) repository have multiple baselines?

Sorry, if I am asking the obvious but I did not manage to find guidlines in
the documentation yet. It might very well an oversight be myself.

Kind regards,
Steffen

[Pharo-users] Re: Collection>>reduce name clash with transducers

[Steffen Märcker]

ceRight: is not, despite
them sensibly supporting #reverseDo:.  For that matter, Deques
support #reverseDo: but are not sequences... 

To the limited extent that I understand the Transducers package,
this view that (s reduce{Left,Right}: b) should really be
(b reduce{Left,Right}) applyTo: s
seems 100% in the spirit of Transducers.


In fact, now that I understand a bit about Transducers,
 reduce: 
(a) seems back to front compared with
 applyTo: 
(b) seems like a misnomer because in general much may be
generated transformed and retained, with nothing
getting smaller, so why 'reduce'?
It seems like a special case of applying a function-like
object (the transducer) to an argument (the collection),
so why not
transducer applyTo: dataSource
transducer applyTo: dataSource initially: initial


Did you look at Richard Waters' "obviously synchronizable series
expressions"?  (MIT AI Memo 958A and 959A)  Or his later SERIES
package?  (Appendix A of Common Lisp the Language, 2nd edition)


    




On Fri, 14 Apr 2023 at 22:32, Steffen Märcker  wrote:

Hi Richard!


Thanks for sharing your thoughts. 


  There's a reason why #inject:into: puts the block argument
  last.  It works better to have "heavy" constituents on the
  right in an English sentence, and it's easier to indent
  blocks when they come last.


Nice, I never though of it this way. I always appreciate a historical 
background.


Let me try to respond to the rest with a focus on the ideas. First of all, the 
point of the transducers framework is to cleanly separate between iteration 
over sequences, processing of the elements and accumulation of a result. It 
enables easy reuse the concepts common to different data structures.


1. What do I mean by completion? If we iterate over a sequence of objects, we 
sometimes want to do a final step after all elements have seen to complete the 
computation. For instance, after copying elements to a new collection, we may 
want to trim it to its actual size:


distinct := col inject: Set new into: #add.
distinct trim.


For some cases it turns out to be useful to have an object that knows how to do 
both:


distinct := col reduce: (#add completing: #trim) init: Set new.


#reduce:init: knows how to deal with both this new objects and ordinary blocks. 
For now I will call both variants a "reducing function". Note, completion is 
completely optional and the implementation is literally #inject:into: plus 
completion if required.




2. What is a reduction? In some cases, it turns out to be useful to pair up a 
reducing function with an (initial) value. You called it a magma and often its 
indeed the neutral element of a mathematical operator, e.g., + and 0. But we 
can use a block that yields the initial value, too. For instance:


sum := #+ init: 0.
result := numbers reduce: sum.


toSet := (#add completing: #trim) initializer: [Set new].
distinct := col reduce: toSet.


#reduce: is just a shorthand that passes the function and the value to 
#reduce:init: Maybe #reduceMagma: is a reasonable name?




3. The reason I implemented #reduce:init: directly on collections, streams, 
etc. is that these objects know best how to efficiently iterate over their 
elements. And if a data structure knows how to #reduce:init: we can use it with 
all the transducers functions, e.g., for partitioning, filtering etc. Other 
useful methods  could then be added to the behaviour with a trait, e.g., 
#transduce:reduce:init which first apples a transducer and then reduces. As 
traits are not available in plain VW 8.3, I did not try this approach, though.




4. Lets take #reduce:Left: as and example and reimplement the method using 
transducers, shall we? The following code works for each 
sequence/collection/stream that supports #transduce:reduce:init:


reduceLeft: aBlock

| head rest arity |
head := self transduce: (Take number: 1) reduce: [:r :e | e] init: nil.
rest := Drop number: 1.


arity := aBlock arity.
^arity = 2
ifTrue: [self transduce: rest reduce: aBlock init: head]
ifFalse: [
| size arguments |
size := arity - 1.
rest := rest * (Partition length: size) * (Remove 
predicate: [:part | part size < size]).
arguments := Array new: arity.
arguments at: 1 put: head.
self
transduce: rest
reduce: ([:args :part |
args
replaceFrom: 2 to: arity with: 
part;
at: 1 put: (aBlock 
valueWithArguments: args);
yourself] completing: [:args | 
args first

[Pharo-users] Re: Collection>>reduce name clash with transducers

[Steffen Märcker]

or, it fails to
   provide a fast path for the common case of a dyadic block.


reduceLeft: aBlock
  aBlock argumentCount = 2 ifTrue: [
|r|
r := self first.
self from: 2 to: self last do: [:each |
  r := aBlock value: r value: each].
^r].
... everything else as before ...



Adding up a million floats takes half the time using the
fast path (67 msec vs 137 msec).  Does your #reduce:
also perform "a completion action"?  If so, it definitely
should not be named after #inject:into:.






At any rate, if it does something different, it should have
a different name, so #reduce: is no good.


#reduce:init:
  There's a reason why #inject:into: puts the block argument
  last.  It works better to have "heavy" constituents on the
  right in an English sentence, and it's easier to indent
  blocks when they come last.


  Which of the arguments here specifies the 'completion action'?
  What does the 'completion action' do?  (I can't tell from the name.)


I think the answer is clear:
* choose new intention-revealing names that do not clash.


If I have have understood your reduce: aReduction correctly,
a Reduction specifies
 - a binary operation (not necessarily associative)
 - a value which can be passed to that binary operation
which suggests that it represents a magma with identity.
By the way, it is not clear whether
 {x} reduce: <>
answers x or binop value: ident value: x.
It's only when ident is an identity for binop that you
can say 'it doesn't matter'. 

I don't suppose you could bring yourself to call
aReduction aMagmaWithIdentity?


Had you considered
  aMagmaWithIdentity reduce: aCollection
where the #reduce: method is now in your class so
can't *technically* clash with anything else?
All you really need from aCollection is #do: so
it could even be a stream.


MagmaWithIdentity
>> identity
>> combine:with:
>> reduce: anEnumerable
 |r|
 r := self identity.
 anEumerable do: [:each | r := self combine: r with: each].
 ^r


MagmaSansIdentity
>> combine:with:
>> reduce: anEnumerable
 |r f|
 f := r := nil.
 anEnumerable do: [:each |
   r := f ifNil: [f := self. each] ifNotNil: [self combine: r with: each]].
 f ifNil: [anEnumerable error: 'is empty'].
 ^r




 



On Fri, 14 Apr 2023 at 05:02, Steffen Märcker  wrote:

The reason I came up with the naming question in the first place is that I 
(finally !) finish my port of Transducers to Pharo. But currently, I am running 
into a name clash. Maybe you have some good ideas how to resolve the following 
situation in a pleasant way.


- #fold: exists in Pharo and is an alias of #reduce:
- #reduce: exists in Pharo and calls #foldLeft: which also deals with more than 
two block arguments



Both of which are not present in VW. Hence, I used the following messages in VW 
with no name clash:


- #reduce: aReduction "= block + initial value"
- #reduce:init: is similar to #inject:into: but executes an additional 
completion action


Some obvious ways to avoid a clash in Pharo are:


1) Make #reduce: distinguish between a reduction and a simple block (e.g. by 
double dispatch)
2) Rename the transducers #reduce: to #injectInto: and adapt #inject:into: to 
optionally do the completion
3) Find another selector that is not too counter-intuitive


All three approaches have some downsides in my opinion:
1) Though straight forward to implement, both flavors behave quite different, 
especially with respect to the number of block arguments. The existing one 
creates a SequenceableCollection and partitions it according to the required 
number of args. Transducers' #reduce: considers binary blocks as the binary 
fold case but ternary blocks as fold with indexed elements.
2) This is a real extension of #inject:into: but requires to touch multiple 
implementations of that message. Something I consider undesirabe.
3) Currently, I cannot think of a good name that is not too far away from what 
we're familiar with.


Do you have some constructive comments and ideas?


Kind regards,
Steffen







Steffen Märcker schrieb am Donnerstag, 13. April 2023 17:11:15 (+02:00):


:-D I don't know how compress made onto that site. There is not even an example 
in the list of language examples where fold/reduce is named compress.



Richard O'Keefe schrieb am Donnerstag, 13. April 2023 16:34:29 (+02:00):


OUCH.  Wikipedia is as reliable as ever, I see.
compress and reduce aren't even close to the same thing.
Since the rank of the result of compression is the same
as the rank of the right operand, and the rank of the
result of reducing is one lower, they are really quite
different.  compress is Fortran's PACK.
https://gcc.gnu.org/onlinedocs/gfortran/PACK.html


On Fri, 14 Apr 2023 at 01:34, Steffen Märcker  wrote:

Hi Richard and Sebastian!


Interesting read. I obviously was not aware of the variety of meanings for 
fold/reduce. Thanks for pointing this out. Also, in s

[Pharo-users] Re: Collection>>reduce name clash with transducers

[Steffen Märcker]

The reason I came up with the naming question in the first place is that I 
(finally !) finish my port of Transducers to Pharo. But currently, I am running 
into a name clash. Maybe you have some good ideas how to resolve the following 
situation in a pleasant way.


- #fold: exists in Pharo and is an alias of #reduce:
- #reduce: exists in Pharo and calls #foldLeft: which also deals with more than 
two block arguments



Both of which are not present in VW. Hence, I used the following messages in VW 
with no name clash:


- #reduce: aReduction "= block + initial value"
- #reduce:init: is similar to #inject:into: but executes an additional 
completion action


Some obvious ways to avoid a clash in Pharo are:


1) Make #reduce: distinguish between a reduction and a simple block (e.g. by 
double dispatch)
2) Rename the transducers #reduce: to #injectInto: and adapt #inject:into: to 
optionally do the completion
3) Find another selector that is not too counter-intuitive


All three approaches have some downsides in my opinion:
1) Though straight forward to implement, both flavors behave quite different, 
especially with respect to the number of block arguments. The existing one 
creates a SequenceableCollection and partitions it according to the required 
number of args. Transducers' #reduce: considers binary blocks as the binary 
fold case but ternary blocks as fold with indexed elements.
2) This is a real extension of #inject:into: but requires to touch multiple 
implementations of that message. Something I consider undesirabe.
3) Currently, I cannot think of a good name that is not too far away from what 
we're familiar with.


Do you have some constructive comments and ideas?


Kind regards,
Steffen







Steffen Märcker schrieb am Donnerstag, 13. April 2023 17:11:15 (+02:00):


:-D I don't know how compress made onto that site. There is not even an example 
in the list of language examples where fold/reduce is named compress.



Richard O'Keefe schrieb am Donnerstag, 13. April 2023 16:34:29 (+02:00):


OUCH.  Wikipedia is as reliable as ever, I see.
compress and reduce aren't even close to the same thing.
Since the rank of the result of compression is the same
as the rank of the right operand, and the rank of the
result of reducing is one lower, they are really quite
different.  compress is Fortran's PACK.
https://gcc.gnu.org/onlinedocs/gfortran/PACK.html


On Fri, 14 Apr 2023 at 01:34, Steffen Märcker  wrote:

Hi Richard and Sebastian!


Interesting read. I obviously was not aware of the variety of meanings for 
fold/reduce. Thanks for pointing this out. Also, in some languages it seems the 
same name is used for both reductions with and without an initial value. 
There's even a list on WP on the matter: 
https://en.wikipedia.org/wiki/Fold_%28higher-order_function%29#In_various_languages


Kind regards,
Steffen

Richard O'Keefe schrieb am Donnerstag, 13. April 2023 13:16:28 (+02:00):


The standard prelude in Haskell does not define anything
called "fold".  It defines fold{l,r}{,1} which can be
applied to any Foldable data (see Data.Foldable).  For
technical reasons having to do with Haskell's
non-strict evaluation, foldl' and foldr' also exist.
But NOT "fold".


https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-Foldable.html#laws




On Thu, 13 Apr 2023 at 21:17, Sebastian Jordan Montano 
 wrote:

Hello Steffen,

Let's take Kotlin documentation 
(https://kotlinlang.org/docs/collection-aggregate.html#fold-and-reduce)

> The difference between the two functions is that fold() takes an initial 
> value and uses it as the accumulated value on the first step, whereas the 
> first step of reduce() uses the first and the second elements as operation 
> arguments on the first step.

Naming is not so consistent in all the programming languages, they mix up the 
names "reduce" and "fold". For example in Haskell "fold" does not take an 
initial value, so it is like a "reduce" in Kotlin. In Kotlin, Java, Scala and 
other oo languages "reduce" does not take an initial value while "fold" does. 
Pharo align with those languages (except that out fold is called #inject:into:)

So for me the Pharo methods #reduce: and #inject:into represent well what they 
are doing and they are well named.

Cheers,
Sebastian

- Mail original -
> De: "Steffen Märcker" 
> À: "Any question about pharo is welcome" 
> Envoyé: Mercredi 12 Avril 2023 19:03:01
> Objet: [Pharo-users] Collection>>reduce naming

> Hi!
>
> I wonder whether there was a specific reason to name this method #reduce:?
> I would have expected #fold: as this is the more common term for what it
> does. And in fact, even the comment reads "Fold the result of the receiver
> into aBlock." Whereas #reduce: is the common term for what we call with
> #inject:into: .
>
> I am asking not

[Pharo-users] Re: Collection>>reduce naming

[Steffen Märcker]

:-D I don't know how compress made onto that site. There is not even an example 
in the list of language examples where fold/reduce is named compress.



Richard O'Keefe schrieb am Donnerstag, 13. April 2023 16:34:29 (+02:00):


OUCH.  Wikipedia is as reliable as ever, I see.
compress and reduce aren't even close to the same thing.
Since the rank of the result of compression is the same
as the rank of the right operand, and the rank of the
result of reducing is one lower, they are really quite
different.  compress is Fortran's PACK.
https://gcc.gnu.org/onlinedocs/gfortran/PACK.html


On Fri, 14 Apr 2023 at 01:34, Steffen Märcker  wrote:

Hi Richard and Sebastian!


Interesting read. I obviously was not aware of the variety of meanings for 
fold/reduce. Thanks for pointing this out. Also, in some languages it seems the 
same name is used for both reductions with and without an initial value. 
There's even a list on WP on the matter: 
https://en.wikipedia.org/wiki/Fold_%28higher-order_function%29#In_various_languages


Kind regards,
Steffen

Richard O'Keefe schrieb am Donnerstag, 13. April 2023 13:16:28 (+02:00):


The standard prelude in Haskell does not define anything
called "fold".  It defines fold{l,r}{,1} which can be
applied to any Foldable data (see Data.Foldable).  For
technical reasons having to do with Haskell's
non-strict evaluation, foldl' and foldr' also exist.
But NOT "fold".


https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-Foldable.html#laws




On Thu, 13 Apr 2023 at 21:17, Sebastian Jordan Montano 
 wrote:

Hello Steffen,

Let's take Kotlin documentation 
(https://kotlinlang.org/docs/collection-aggregate.html#fold-and-reduce)

> The difference between the two functions is that fold() takes an initial 
> value and uses it as the accumulated value on the first step, whereas the 
> first step of reduce() uses the first and the second elements as operation 
> arguments on the first step.

Naming is not so consistent in all the programming languages, they mix up the 
names "reduce" and "fold". For example in Haskell "fold" does not take an 
initial value, so it is like a "reduce" in Kotlin. In Kotlin, Java, Scala and 
other oo languages "reduce" does not take an initial value while "fold" does. 
Pharo align with those languages (except that out fold is called #inject:into:)

So for me the Pharo methods #reduce: and #inject:into represent well what they 
are doing and they are well named.

Cheers,
Sebastian

- Mail original -
> De: "Steffen Märcker" 
> À: "Any question about pharo is welcome" 
> Envoyé: Mercredi 12 Avril 2023 19:03:01
> Objet: [Pharo-users] Collection>>reduce naming

> Hi!
>
> I wonder whether there was a specific reason to name this method #reduce:?
> I would have expected #fold: as this is the more common term for what it
> does. And in fact, even the comment reads "Fold the result of the receiver
> into aBlock." Whereas #reduce: is the common term for what we call with
> #inject:into: .
>
> I am asking not to annoy anyone but out of curiosity. It figured this out
> only by some weird behaviour after porting some code that (re)defines
> #reduce .
>
> Ciao!
> Steffen


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

[Pharo-users] Re: Comparison of blocks

[Steffen Märcker]

I forgot:


Is there currently a good way to test whether a block is a copying block (in 
the VW meaning) in Pharo (11)? This means a block that:
- Copies only variables not changing after block creation
- Does not need the outer context for evaluation
So far did not find an obvious way. It seems that a block always has a 
reference to its outer context. Variables in copiedValues are not modified 
after block creation if I understand the class comment correctly, but variables 
in tempVector can, right?


Best,
Steffen

Steffen Märcker schrieb am Donnerstag, 13. April 2023 15:14:16 (+02:00):


Hi Richard!


You're completely right. Function equivalence is a beast and in the context of 
a computer program undecidable for nontrivial cases. And that's a valid reason 
to ban this entirely. Personally, I can also see some value in recognizing 
equality in trivial cases, e.g.,
1) constant blocks: [  ] = [  ]
2) pure functions:  [:a1 ... |  ] = [:a1 ... |  ]
3) enclosed constants: same as 1) and 2) but with references to variables that 
do not change after block creation.


If I am not mistaken VW 1) and 2) are considered clean blocks and 3) a copying 
block. For both equality is recognized if the bytecode is identical even if 
they are created in different contexts. Why do think VW regards them not equal? 
Do you mean another case or did I miss something? I did a short positive test 
in my VW 8.3 image.


Of course, one can have different opinions on the matter depending on the 
applications. I just wonder whether it was a conscious decision not to 
implement this in Pharo or just one of the thing that could be but haven't been 
done yet. And no, I do not rely on this functionality. I am just curious. ;-)


Kind regards,
Steffen

Richard O'Keefe schrieb am Donnerstag, 13. April 2023 12:17:05 (+02:00):


There is no agreement between Smalltalk systems about how to
compare block contexts for equality.  In Smalltalk-80 (and I
have two versions of Smalltalk-80 to compare), block equality
is identity.  The same in VisualAge Smalltalk 8.6.3.  The
same in GNU Smalltalk.  The same in Smalltalk/X-JV.
Squeak has a similar definition to  VW.
My reading of the ANSI standard is that it is carefully vague about this.


Equality of functions has been troublesome for decades.
Haskell: bans it.
Standard ML: bans it.
Some other ML-family languages: it's a run-time error.
Lisp family: varies.  Interlisp says nothing.  Scheme gives lower and upper 
bounds.


Imagine a Smalltalk that recognises [] blocks and
allocates one static closure per .  Then
[true] == [true] hence [true] = [true] even when the two
s were in different methods.  The Squeak
and VW definitions would regard them as unequal.  (This is
on my TODO list, principally for [] [true] [false] and [0].)
For the special case of [], you don't *have* to imagine it.
If I'm reading VAST correctly, it treats "empty blocks"
specially.


If you *rely* on the definition of #= for block contexts/closures
you are almost certainly doing something dangerous.  You are
certainly doing something that is not portable.



On Thu, 13 Apr 2023 at 18:55, Steffen Märcker  wrote:

Hi!

In VisualWorks, blocks can be compared with each other. In Pharo the
comparison just checks for Identity. Is this on purpose? For reference,
that's how BlockClosure>>= is implemented in VW:


= aBlockClosure
^aBlockClosure class = self class and:
 [method = aBlockClosure method and:
  [outerContext = aBlockClosure outerContext and:
   [copiedValues = aBlockClosure copiedValues]]]

Kind regards,
Steffen


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

[Pharo-users] Re: Collection>>reduce naming

[Steffen Märcker]

Hi Richard and Sebastian!


Interesting read. I obviously was not aware of the variety of meanings for 
fold/reduce. Thanks for pointing this out. Also, in some languages it seems the 
same name is used for both reductions with and without an initial value. 
There's even a list on WP on the matter: 
https://en.wikipedia.org/wiki/Fold_%28higher-order_function%29#In_various_languages


Kind regards,
Steffen

Richard O'Keefe schrieb am Donnerstag, 13. April 2023 13:16:28 (+02:00):


The standard prelude in Haskell does not define anything
called "fold".  It defines fold{l,r}{,1} which can be
applied to any Foldable data (see Data.Foldable).  For
technical reasons having to do with Haskell's
non-strict evaluation, foldl' and foldr' also exist.
But NOT "fold".


https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-Foldable.html#laws




On Thu, 13 Apr 2023 at 21:17, Sebastian Jordan Montano 
 wrote:

Hello Steffen,

Let's take Kotlin documentation 
(https://kotlinlang.org/docs/collection-aggregate.html#fold-and-reduce)

> The difference between the two functions is that fold() takes an initial 
> value and uses it as the accumulated value on the first step, whereas the 
> first step of reduce() uses the first and the second elements as operation 
> arguments on the first step.

Naming is not so consistent in all the programming languages, they mix up the 
names "reduce" and "fold". For example in Haskell "fold" does not take an 
initial value, so it is like a "reduce" in Kotlin. In Kotlin, Java, Scala and 
other oo languages "reduce" does not take an initial value while "fold" does. 
Pharo align with those languages (except that out fold is called #inject:into:)

So for me the Pharo methods #reduce: and #inject:into represent well what they 
are doing and they are well named.

Cheers,
Sebastian

- Mail original -
> De: "Steffen Märcker" 
> À: "Any question about pharo is welcome" 
> Envoyé: Mercredi 12 Avril 2023 19:03:01
> Objet: [Pharo-users] Collection>>reduce naming

> Hi!
>
> I wonder whether there was a specific reason to name this method #reduce:?
> I would have expected #fold: as this is the more common term for what it
> does. And in fact, even the comment reads "Fold the result of the receiver
> into aBlock." Whereas #reduce: is the common term for what we call with
> #inject:into: .
>
> I am asking not to annoy anyone but out of curiosity. It figured this out
> only by some weird behaviour after porting some code that (re)defines
> #reduce .
>
> Ciao!
> Steffen


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

[Pharo-users] Re: Comparison of blocks

[Steffen Märcker]

Hi Richard!


You're completely right. Function equivalence is a beast and in the context of 
a computer program undecidable for nontrivial cases. And that's a valid reason 
to ban this entirely. Personally, I can also see some value in recognizing 
equality in trivial cases, e.g.,
1) constant blocks: [  ] = [  ]
2) pure functions:  [:a1 ... |  ] = [:a1 ... |  ]
3) enclosed constants: same as 1) and 2) but with references to variables that 
do not change after block creation.


If I am not mistaken VW 1) and 2) are considered clean blocks and 3) a copying 
block. For both equality is recognized if the bytecode is identical even if 
they are created in different contexts. Why do think VW regards them not equal? 
Do you mean another case or did I miss something? I did a short positive test 
in my VW 8.3 image.


Of course, one can have different opinions on the matter depending on the 
applications. I just wonder whether it was a conscious decision not to 
implement this in Pharo or just one of the thing that could be but haven't been 
done yet. And no, I do not rely on this functionality. I am just curious. ;-)


Kind regards,
Steffen

Richard O'Keefe schrieb am Donnerstag, 13. April 2023 12:17:05 (+02:00):


There is no agreement between Smalltalk systems about how to
compare block contexts for equality.  In Smalltalk-80 (and I
have two versions of Smalltalk-80 to compare), block equality
is identity.  The same in VisualAge Smalltalk 8.6.3.  The
same in GNU Smalltalk.  The same in Smalltalk/X-JV.
Squeak has a similar definition to  VW.
My reading of the ANSI standard is that it is carefully vague about this.


Equality of functions has been troublesome for decades.
Haskell: bans it.
Standard ML: bans it.
Some other ML-family languages: it's a run-time error.
Lisp family: varies.  Interlisp says nothing.  Scheme gives lower and upper 
bounds.


Imagine a Smalltalk that recognises [] blocks and
allocates one static closure per .  Then
[true] == [true] hence [true] = [true] even when the two
s were in different methods.  The Squeak
and VW definitions would regard them as unequal.  (This is
on my TODO list, principally for [] [true] [false] and [0].)
For the special case of [], you don't *have* to imagine it.
If I'm reading VAST correctly, it treats "empty blocks"
specially.


If you *rely* on the definition of #= for block contexts/closures
you are almost certainly doing something dangerous.  You are
certainly doing something that is not portable.



On Thu, 13 Apr 2023 at 18:55, Steffen Märcker  wrote:

Hi!

In VisualWorks, blocks can be compared with each other. In Pharo the
comparison just checks for Identity. Is this on purpose? For reference,
that's how BlockClosure>>= is implemented in VW:


= aBlockClosure
^aBlockClosure class = self class and:
 [method = aBlockClosure method and:
  [outerContext = aBlockClosure outerContext and:
   [copiedValues = aBlockClosure copiedValues]]]

Kind regards,
Steffen


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

[Pharo-users] Re: Porting from VW to Pharo

[Steffen Märcker]

Hi Christian,


I am working slowly through the required changes. Thanks for your comprehensive 
answer. When I have made some more progress, I think having a call would be 
nice. I'll try loading the package again from store later today.


One quick question:
As far as I understand, to extend classes in the target dialect with methods 
that are not extended in the source project, I have to define a System class 
change like this:


SystemClassChange
className: #Color
instanceChanges: (Array with: (Add method: #asColorValue code: 
#_ph_asColorValue)


The actual code for the extension has to be implemented in CodeHolder, correct? 
How do I deal then with methods that need to access instance variables not 
present in CodeHolder? Just add them to the class or is there another way?


Kind regards,
Steffen



Christian Haider schrieb am Mittwoch, 12. April 2023 21:07:05 (+02:00):



Hi Steffen,

 

thanks for trying and asking!

 

I was loading the code needed into a 8.3, 64bit virgin image and realized that 
loading is not that straight forward and described too briefly.

First, you need a non-default setting for the store prerequisites. I added this 
to the store access page: https://wiki.pdftalk.de/doku.php?id=storeaccess . It 
is critical to load the prereqs from store and not from parcels!

 

The first thing to load is the bundle {Smalltalk Transform Project}.

To see examples you need to load the subject of transformation: PDFtalk.

You need to load to top bundle {PDFtalk Project} which includes the test 
classes you are missing in your image.

At last, load the [Pharo Fileout PDFtalk] package.

I improved the landing page 
https://wiki.pdftalk.de/doku.php?id=smalltalktransform a bit to make this 
clearer.

 

I just tried and this loads without errors or warnings.

 

(Actually good that the load did not work for you, because I added a mistake in 
January which causes a 8.3 image to crash when you open a browser. Sorry for 
that.)

 

Now you should be all set for generating a fileout of PDFtalk for Pharo (in the 
current unfinished state).

 

Thanks for spotting the problems with the documentation. I will get over it 
tomorrow.

I am quick in renaming and making structural changes when things are not 
working as I want… But the docs should be correct, of course.

 

 

About the project structure.

Currently, everything belonging to a project, need to be transformed in one go. 
This is not a big deal, because all code transformations are described on the 
package level and can be easily recombined as the bundle structure changes.

 

The last piece of the transformation puzzle is to make the transformations 
modular, so that the renamings of prerequisite packages can be used without the 
need to transform the prereqs as well. I hope to get at that soon…

In the meantime, I would start with your Core project to get a feel for the 
mechanics. I am sure the rest will fall nicely into its places.

 

About how to structure your code in Pharo with Git, I don’t know much about 
that. Actually, I would also be interested in some guidelines to bake them into 
the transformations…

 

If you are seriously interested, we could have an online session to hack around 
with it…

 

Cheers,

Christian

 

 

Von: Steffen Märcker 
Gesendet: Dienstag, 11. April 2023 17:52
An: Any question about pharo is welcome 
Betreff: [Pharo-users] Re: Porting from VW to Pharo

 

Dear Christian and Richard,

 

thanks for your answers. I'll try to go through the process step by step and 
come back with questions to the list if that's okay.

 

First, after loading the "Pharo Fileout PDFTalk", VW (8.3, 64 Bit) shows two 
unloadable definitions:

- PostscriptInterpreterTests>>_ph_testOperatorNotFound
- ColorValueTest>>_ph_testBridgedNamedColors

Both classes are not loaded

 

 

 

Second, it appears that some of the selectors mentioned on 
https://wiki.pdftalk.de/doku.php?id=smalltalktransformdocumentation have been 
renamed, e.g., PackageChanges>>unusedClasses

 

More general, regarding project structure. What is the best approach to port a 
project that consists of multiple loosely coupled packages (not in a bundle) 
some of which being optional? Like

- Package Project Core

- Package Project Core Tests (requires Core)

- Package Project Extension A (requires Core)
- Package Project Extension A Tests (requires Extension A)

- Package Project Examples (requires Core and Extension A)

 

And how should I structure this on the Pharo site and in an iceberg repository? 
One Git repository per package or all in the same? Is there a guide to this or 
a specific Mooc lesson?

 

Kind regards,

Steffen

 

 


Christian Haider schrieb am Donnerstag, 6. April 2023 18:16:00 (+02:00):

Yes, PDFtalk is the only example, because it was created to port that library. 
Any other uses are welcome.

 

The project has been dormant for a year now because of ot

[Pharo-users] Comparison of blocks

[Steffen Märcker]

Hi!

In VisualWorks, blocks can be compared with each other. In Pharo the
comparison just checks for Identity. Is this on purpose? For reference,
that's how BlockClosure>>= is implemented in VW:


= aBlockClosure
^aBlockClosure class = self class and:
 [method = aBlockClosure method and:
  [outerContext = aBlockClosure outerContext and:
   [copiedValues = aBlockClosure copiedValues]]]

Kind regards,
Steffen

[Pharo-users] Re: [vwnc] Block evaluation with n+1 arguments

[Steffen Märcker]

Dear Richard,


thanks for elaborating on your ideas. As I am still figuring out what works
best, I'll give them a try. Especially the approach to let the source deal
with passing the arguments to the block - though this requires more
changes.



The problem is NOT, as some commentators apparently think, that
you are using a block.


Indeed. A block provided (by the user) is actual the natural way in my
case.


The problem is that having thought of
one way to wire things up -- not an unreasonable way, in fact --
you concentrated on making *that* way faster instead of looking
for other ways to do it.


You're right. I first wanted to see how far I can get with this "direct"
approach before trying other techniques. :-D


All the best!
Steffen

[Pharo-users] Collection>>reduce naming

[Steffen Märcker]

Hi!

I wonder whether there was a specific reason to name this method #reduce:?
I would have expected #fold: as this is the more common term for what it
does. And in fact, even the comment reads "Fold the result of the receiver
into aBlock." Whereas #reduce: is the common term for what we call with
#inject:into: .

I am asking not to annoy anyone but out of curiosity. It figured this out
only by some weird behaviour after porting some code that (re)defines
#reduce .

Ciao!
Steffen

[Pharo-users] Re: [vwnc] Block evaluation with n+1 arguments

[Steffen Märcker]

Hi!

First, thanks for your engaging answers Richard, Stephane and the others!

The objective is to avoid unnecessary object creation in a tight loop that
interfaces between a value source and a block that processes the values.
- The source object returns multiple values as a tuple (for good reasons).
- The block processes theses values but needs another argument (at the
first place).
We do not know the number of values at compile time but know that they
match the arity of the block. Something like this (though more involved in
practice):

(1 to: 1000) do: [:i | | args |
args := source compute: i.
block valueWithArguments: {i} , args ]

Since prepending the tuple with the first argument and then sending
#valueWithArguments: creates an intermediate Array, I wonder whether we can
avoid (some of) that overhead in the loop without changing this structure.
Note, "{i}, args" is only for illustration and creates an additional third
array as Steve already pointed out.

To sum up the discussion so far:
- If possible, change the structure, e.g., processing the tuple directly.
- Fast primitives exist for the special cases of 1, 2 and 3 arguments only.
- Code for > 3 arguments would have to use #valueWithArguments: after all.

Did I miss something?

Kind regards,
Steffen

[Pharo-users] Re: [vwnc] Block evaluation with n+1 arguments

[Steffen Märcker]

Hi Stephane,


thanks for linking the upcoming lesson. I'll have a look. :-D


Best, Steffen

stephane.duca...@free.fr schrieb am Montag, 10. April 2023 16:03:16 (+02:00):


BTW to me when a block needs too many arguments it feels like that an object 
has to be born :)
With an object I can just sent or not a given extra argument. 


Now I do not know enough your specific context but what I learned is that 
complex blocks are difficult to follow, manipulate…
so I keep block as simple as possible and else I create little objects.




This is a little lectures from a super cool forthcoming mooc



https://rmod-files.lille.inria.fr/DesignCoffeeClub/ForLearningLab/7-Lang-04-BlocksVsObjects.pdf






On 6 Apr 2023, at 15:28, Steffen Märcker  wrote:


Hi!

I want to evaluate a block an argument 'arg1' and additional n arguments
given in an array 'args'. The following code does the trick:

  block valueWithArguments: (Array with: arg1) , args.

Is there a way to do this without the overhead of creating a new Array?
(How) Can I add additional #value:value:[...] methods to BlockClosure that
evaluate the block with n arguments directly without falling back to
#valueWithArguments: ? If yes, what's the maximum?

Cheers!
Steffen




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

[Pharo-users] Re: Block evaluation with n+1 arguments

[Steffen Märcker]

Hi Joachim,


interesting approach. Unfortunately it won't work here, since the additional 
argument has to be the first. But I keep it in mind for another use case.


Ciao,
Steffen


Joachim Tuchel schrieb am Samstag, 8. April 2023 10:42:08 (+02:00):



Steffen,





if you fear performance bottlenecks, did you consider using a Stream as a 
single block parameter?


Your requirement sounds  a bit as if you do some diving into a structure 
(recursion?) where "someone" (maybe even conditionally) adds another argument 
before the block is evaluated. I've had good results in both performance and 
readability with Streams in such scenarios...

Just an idea, maybe completely useless...




Joachim


Am 07.04.23 um 19:18 schrieb Noury Bouraqadi:

Steffen,


My first response, is do NOT optimize too early. The performance bottlenecks 
are not always where we think they are.
 
In Pharo you can add methods to BlockClosure class. You can go up to 255 
arguments IIRC.
But, of course there is no primitive to handle them, so you endup writing the 
same code.
Better use valueWithArguments: 


block valueWithArguments: (multipleArgs copyWith: singleArg) 


Noury
On Apr 6 2023, at 3:28 pm, Steffen Märcker  wrote:
Hi!


I want to evaluate a block an argument 'arg1' and additional n arguments
given in an array 'args'. The following code does the trick:


block valueWithArguments: (Array with: arg1) , args.


Is there a way to do this without the overhead of creating a new Array?
(How) Can I add additional #value:value:[...] methods to BlockClosure that
evaluate the block with n arguments directly without falling back to
#valueWithArguments: ? If yes, what's the maximum?


Cheers!
Steffen
-- 

--- 
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de 
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0Fax: +49 7141 56 10 86 1



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

[Pharo-users] Re: Porting from VW to Pharo

[Steffen Märcker]

Thanks Stewart, I'll keep that in mind!


Cheers,
Steffen





Stewart MacLean schrieb am Freitag, 7. April 2023 03:18:40 (+02:00):


Hi,



Having been through this process I found I had to completely rewrite the UI 
side of things - you can either choose to use Morphic, or the more modern Spec 
overlay. I used this in conjunction with Roassal, as my UI is mainly graphic. 
It also renders using Cairo, giving it a nice look. I also used Pango to make 
the text look good too.


You'll need to abandon name spaces. Just prefix your class names as appropriate.


If you've got objects to port SIXX is really useful.


My two cents...


Stew


On Fri, Apr 7, 2023 at 4:16 AM Christian Haider  wrote:


Yes, PDFtalk is the only example, because it was created to port that library. 
Any other uses are welcome.

 

The project has been dormant for a year now because of other obligations, but I 
hope to resume soon.

 

The documentation is, as Richard notes, in a suboptimal state. I think that the 
information is still accurate.

Any help with this would be welcome, for example by asking questions or by 
criticizing concrete issues.

 

Christian

 

Von: Richard Sargent 
Gesendet: Donnerstag, 6. April 2023 17:55
An: Any question about pharo is welcome 
Betreff: [Pharo-users] Re: Porting from VW to Pharo

 

The best(?) place to start is perhaps 
https://wiki.pdftalk.de/doku.php?id=smalltalktransform.

The only examples are various ports of PDFtalk (from VisualWorks) to Pharo, 
Squeak, GemStone, and VAST.

 

PDFtalk is quite complex and the porting rules are correspondingly complex. The 
Transform documentation does leave something to be desired.

 

On Thu, Apr 6, 2023 at 8:22 AM Steffen Märcker  wrote:

Hi!

this topic pops up from time to time on the mailing list. I want to port a
number of packages to Pharo. I remember "Shaping" asking this for porting
PDFtalk.

1. Is the workflow still up to date or is there a new way of doing things?
2. From what I understand so far, I just need the following package from
Store:
- Smalltalk Transform Project
3.  Is there a page that documents the process process in general?
https://wiki.pdftalk.de/doku.php?id=setupvisualworks seems to be specific
for PDFtalk like the thread on this list.

Kind regards,
Steffen


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

[Pharo-users] Re: Porting from VW to Pharo

[Steffen Märcker]

Dear Christian and Richard,


thanks for your answers. I'll try to go through the process step by step and 
come back with questions to the list if that's okay.


First, after loading the "Pharo Fileout PDFTalk", VW (8.3, 64 Bit) shows two 
unloadable definitions:
- PostscriptInterpreterTests>>_ph_testOperatorNotFound
- ColorValueTest>>_ph_testBridgedNamedColors
Both classes are not loaded


Second, it appears that some of the selectors mentioned on 
https://wiki.pdftalk.de/doku.php?id=smalltalktransformdocumentation have been 
renamed, e.g., PackageChanges>>unusedClasses


More general, regarding project structure. What is the best approach to port a 
project that consists of multiple loosely coupled packages (not in a bundle) 
some of which being optional? Like
- Package Project Core
- Package Project Core Tests (requires Core)
- Package Project Extension A (requires Core)
- Package Project Extension A Tests (requires Extension A)
- Package Project Examples (requires Core and Extension A)


And how should I structure this on the Pharo site and in an iceberg repository? 
One Git repository per package or all in the same? Is there a guide to this or 
a specific Mooc lesson?


Kind regards,
Steffen





Christian Haider schrieb am Donnerstag, 6. April 2023 18:16:00 (+02:00):



Yes, PDFtalk is the only example, because it was created to port that library. 
Any other uses are welcome.

 

The project has been dormant for a year now because of other obligations, but I 
hope to resume soon.

 

The documentation is, as Richard notes, in a suboptimal state. I think that the 
information is still accurate.

Any help with this would be welcome, for example by asking questions or by 
criticizing concrete issues.

 

Christian

 

Von: Richard Sargent 
Gesendet: Donnerstag, 6. April 2023 17:55
An: Any question about pharo is welcome 
Betreff: [Pharo-users] Re: Porting from VW to Pharo

 

The best(?) place to start is perhaps 
https://wiki.pdftalk.de/doku.php?id=smalltalktransform.

The only examples are various ports of PDFtalk (from VisualWorks) to Pharo, 
Squeak, GemStone, and VAST.

 

PDFtalk is quite complex and the porting rules are correspondingly complex. The 
Transform documentation does leave something to be desired.

 

On Thu, Apr 6, 2023 at 8:22 AM Steffen Märcker  wrote:

Hi!

this topic pops up from time to time on the mailing list. I want to port a
number of packages to Pharo. I remember "Shaping" asking this for porting
PDFtalk.

1. Is the workflow still up to date or is there a new way of doing things?
2. From what I understand so far, I just need the following package from
Store:
- Smalltalk Transform Project
3.  Is there a page that documents the process process in general?
https://wiki.pdftalk.de/doku.php?id=setupvisualworks seems to be specific
for PDFtalk like the thread on this list.

Kind regards,
Steffen


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

[Pharo-users] Porting from VW to Pharo

[Steffen Märcker]

Hi!

this topic pops up from time to time on the mailing list. I want to port a
number of packages to Pharo. I remember "Shaping" asking this for porting
PDFtalk.

1. Is the workflow still up to date or is there a new way of doing things?
2. From what I understand so far, I just need the following package from
Store:
- Smalltalk Transform Project
3.  Is there a page that documents the process process in general?
https://wiki.pdftalk.de/doku.php?id=setupvisualworks seems to be specific
for PDFtalk like the thread on this list.

Kind regards,
Steffen

[Pharo-users] Re: A blog on graph algorithms library of Pharo

[Steffen Märcker]

Hi Goutham,


thanks for sharing that post. Looks interesting, indeed!


Best, Steffen


Guillermo Polito schrieb am Mittwoch, 5. April 2023 10:03:28 (+02:00):


Hi Goutham!


Thanks for the post!
I like the concrete examples.
I did not find them in the repo, I think pushing the examples as comments or 
executable code in the relevant classes is a great first PR ;)


G



El 4 abr. 2023, a las 18:29, DK Goutham  escribió:


Dear Pharo Users,


Here's a blog on pharo-ai/graph-algorithms library. This acts as a primer for 
people new to this library and discusses the flow and architecture of the 
library. The motive of this blog is to introduce people to the amazing graph 
library of Pharo and give them enough confidence to contribute to this library.


Link: https://medium.com/@dkgoutham1806/graph-algorithms-in-pharo-7d12af0be060



Happy reading!


Thank you,
Goutham



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

[Pharo-users] Block evaluation with n+1 arguments

[Steffen Märcker]

Hi!

I want to evaluate a block an argument 'arg1' and additional n arguments
given in an array 'args'. The following code does the trick:

   block valueWithArguments: (Array with: arg1) , args.

Is there a way to do this without the overhead of creating a new Array?
(How) Can I add additional #value:value:[...] methods to BlockClosure that
evaluate the block with n arguments directly without falling back to
#valueWithArguments: ? If yes, what's the maximum?

Cheers!
Steffen

[Pharo-users] Re: ESUG 2023 Call for participation

[Steffen Märcker]

Hi! Is there a firm submission deadline set yet?

Ciao, Steffen


stephane ducasse schrieb am Samstag, 11. Februar 2023 18:49:42 (+01:00):

> ESUG 2023 Call for Presentations
>   28.8.2023 to 01.9.2023
>   Lyon France 
>   https://esug.github.io
>   https://esug.github.io/2023-Conference/conf2023.html
> 
> ESUG is the premium and fun conference around smalltalk technologies. 
> You can support the ESUG conference in many different ways:
>   - Sponsor the conference. New sponsoring packages are described at  
> http://www.esug.org/supportesug/becomeasponsor/
>   - Submit a talk, a software or a paper to one of the events. See below.
>   - Attend the conference. We'd like to beat the previous record of 
> attendance (180 people at Koln 2019)!
>   - Students can get free registration and hosting if they enroll into 
> the the Student Volunteers program. See below.
> 
> ## Developers Forum: International Smalltalk Developers Conference
> 
> We are looking for YOUR experience on using Smalltalk. You will have 30 min 
> for presentations and 45 min for hands-on tutorials. 
> The list of topics for the normal talks and tutorials includes, but is not 
> limited to the following:
>   - XP practices, Development tools, Experience reports
>   - Model driven development, Web development, Team management
>   - Meta-Modeling, Security, New libraries & frameworks
>   - Educational material, Embedded systems and robotics
>   - SOA and Web services, Interaction with other programming languages
>   - Teaching Pearls and Show us Your Business
> 
> New this year!!! We added two types of sessions in addition to the regular 
> talks and show us your projects sessions.
> Show your business 10 min session (Get prepared!!)
> Teaching pearls : we want some session on how to teach some design aspects. 
> We want your tip and tricks to teach Smalltalk or OOP.
> We expect to have several 10 to 15 min sessions aggregated.
> 
> ### How to submit?
> 
> Make a Pull Request here 
> https://github.com/ESUG/esug.github.io/tree/source/2023-Conference/talks
> [Or but only if you are not connected to the world… send an email to 
> stephane.duca...@inria.fr]
> 
> Title: [ESUG 2023] Please follow the template below the email will be 
> automatically processed!
> Name:
> Email:
> Abstract:
> Bio:
> 
> ## Call for Student Volunteers
> Student volunteers help keep the conference running smoothly; in return, they 
> have free accommodations, while still having most of the time to enjoy the 
> conference.
> 
> Pay attention: the places are limited so do not wait till the last minute to 
> apply.
> 
> Conference details:
> Send an email to stephane.ducasse at inria.fr and  Oleksandr Zaitsev  with:
> 
> Title: [ESUG 2023 Student]
>   name, gender, university/school, country, email address
>   short description of you and why you are interested in participating
> 
> For which period is accommodation covered? Accommodation is covered from 
> Sunday 27.8.2023 to 01.9.2023 (including nights from Sunday to Monday and 
> from Thursday to Friday). Students will be hosted in student rooms. ESUG 
> additionally covers for the lunches during the week and one dinner.
> 
> Duties include handling registration as people arrive at the conference, 
> filling coffee machines, collecting presentation slides for ESUG right after 
> the presentation is given, being present at an information desk to answer 
> questions, and generally being helpful. Student volunteering makes the 
> conference better, takes a fairly small amount of time and doesn't 
> significantly interfere with enjoying and learning from the conference. 
> Please Note, this role requires discipline and constant attention to all 
> attendees.
> 
> Information about hotel
> Student Volunteer rooms are booked at (to be announced). If you are student 
> volunteer, do not book yourself, we have arranged the booking already!
> 

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

[Pharo-users] Re: Recovering old images in mac

[Steffen Märcker]

Is there a way to save / convert such an image to 64 Bit?

Best, Steffen

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

[Steffen Märcker]

Hi Kasper,


I've thought about that approach too. But then asked myself whether it is
more likely that there is code that relies on this bug than code where this
went unnoticed and is therefore broken. What do the other think about that
matter and the fix in Squeak?


Best, Steffen







Kasper Osterbye schrieb am Donnerstag, 28. April 2022 19:03:07 (+02:00):


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


If I may suggest a solution it will be to:
add two new methods - prefixedBy:  and suffixedBy: to handle the empty
prefix/suffix correctly
add comments to beginsWith:  and endsWith:  referring to the two new
methods


The problem is that there is client code which depend on the (wrong)
implementation of the beginsWith and endsWith methods.

[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] 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: 

[Pharo-users] Re: [ANN] Pharo Launcher 3.0 released!

[Steffen Märcker]

Hi Christophe,


thanks, that's great news! [Downloading ...]


Cheers! Steffen

Christophe Demarey schrieb am Donnerstag, 14. April 2022 14:26:26 (+02:00):


Hi all,

Pharo Launcher 3.0 has just been released! It is available from
http://pharo.org/download.
It is based on latest Spec2 and Pharo 10 image.
It now comes with a native Apple Silicon version and Mac OS packages are
notarized.
Big thanks to all contributors, including issue reports.

Here is the changelog:
Pharo Launcher v3.0

New features:

Full rewrite of the UI using Spec 2 and Pharo 10
Pharo Launcher can now run natively on Apple Silicon #544
Pharo Launcher is now signed with a Mac Os developper account and notarized
#529
Windows "portable" package (only an archive without installer) #534

Improvements:

While importing image .sources and .version are not moved #543
recreate the image does not re apply the script if one is provided #536
(thanks to @hogoww)
Save keybind for scripts #545 (thanks to @hogoww and @Inao0)

Bug fixes:

GitHub releases artefacts download were not always working #535
"Basic launch" does not do its job in Pharo 10 #540
Proxy settings not applied through settings screen #541

Regards,
The Pharo team.

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

[Pharo-users] Re: [ANN] Pharo 10 released!

[Steffen Märcker]

Congratulations to the new release. That's quite an impressive amount of 
changes and cleanups. Will the stable version be available in the PharoLauncher 
soon?


Cheers, Steffen


Esteban Lorenzano schrieb am Dienstag, 5. April 2022 12:39:44 (+02:00):


Dear Pharo users and dynamic language lovers: 


We have released Pharo version 10 !


Pharo is a pure object-oriented programming language and a powerful 
environment, focused on simplicity and immediate feedback.




Pharo 10 was a short iteration where we focused mainly on stability and 
enhancement of the environment :


Massive system cleanup
gained speed
removed dead code
removed old/deprecated frameworks (Glamour, GTTools, Spec1)
All Remaining tools written using the deprecated frameworks have been 
rewritten: Dependency Analyser, Critique Browser, and many other small 
utilities.
Modularisation has made a leap, creating correct baselines (project 
descriptions) for many internal systems, making possible the work and 
deployment of minimal images.
Removing support for the old Bytecode sets and embedded blocks simplified the 
compiler and language core.
As a result, our image size has been reduced by 10% (from 66MB to 58MB)
The VM has also improved in several areas: better async I/O support, socket 
handling, FFI ABI,  
Even being a short iteration, we have closed a massive amount of issues: around 
600 issues and 700 pull requests. A more extended changelog can be found at 
https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo100ChangeLogs.md.


While the technical improvements are significant, still the most impressive 
fact is that the new code that got in the main Pharo 10 image was contributed 
by more than 80 people.


Pharo is more than code. It is an exciting project involving a great community. 


We thank all the contributors to this release:


Aaron Bieber, Ackerley Tng, Alban Benmouffek, Alejandra Cossio, Aless Hosry, 
Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Arturo Zambrano, Asbathou 
Biyalou-Sama, Axel Marlard, Bastien Degardins, Ben Coman, Bernardo Contreras, 
Bernhard Pieber, Carlo Teixeira, Carlos Lopez, Carolina Hernandez, Christophe 
Demarey, Clotilde Toullec, Connor Skennerton, Cyril Ferlicot, Dave Mason, David 
Wickes, Denis Kudriashov, Eric Gade, Erik Stel, Esteban Lorenzano, Evelyn Cusi 
Lopez, Ezequiel R. Aguerre, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni 
Corriga, Guille Polito, Himanshu, Jan Bliznicenko, Jaromir Matas, Kasper 
Østerbye, Kausthub Thekke Madathil, Konrad Hinsen, Kurt Kilpela, Luz Paz, Marco 
Rimoldi, Marcus Denker, Martín Dias, Massimo Nocentini, Max Leske, 
Maximilian-ignacio Willembrinck Santander, Miguel Campero, Milton Mamani 
Torres, Nahuel Palumbo, Norbert Hartl, Norm Green, Nour Djihan, Noury 
Bouraqadi, Oleksandr Zaitsev, Pablo Sánchez Rodríguez, Pablo Tesone, Pavel 
Krivanek, Pierre Misse-Chanabier, Quentin Ducasse, Raffaello Giulietti, 
Rakshit, Renaud de Villemeur, Rob Sayers, Roland Bernard, Ronie Salgado, 
Santiago Bragagnolo, Sean DeNigris, Sebastian Jordan Montt, Soufyane Labsari, 
Stephan Eggermont, Steven Costiou, Stéphane Ducasse, Sven Van Caekenberghe, 
Theo Rogliano, Thomas Dupriez, Théo Lanord, Torsten Bergmann, Vincent Blondeau.
 


(If you contributed to Pharo 10 development in any way and we missed your name, 
please send us an email and we will add you).


Enjoy!


The Pharo Team


Discover Pharo: https://pharo.org/features


Try Pharo: http://pharo.org/download


Learn Pharo: http://pharo.org/documentation

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

[Pharo-users] Run old 32-Bit image on 64-Bit macOS

[Steffen Märcker]

Hi,
I am looking for a way to run an old 32-Bit image on a modern Mac
(Montery). Pharo launcher gives me the following error:

Cannot run Prism Grammar (Pharo 6.1)!
This image requires a 32-Bit VM to run and 32-Bit applications are not
supported on this Operating System.

Is there a way to run it nevertheless? I want to extract some old app/code
from the image for further use.

Best, Steffen

[Pharo-users] Re: Pharo 9 arbitrarily changes temporary variable names

[Steffen Märcker]

Hi Robert,


have you checked that you're seeing the code you've typed and not just
decompiled methods?


Best,
Steffen



Robert Briggs via Pharo-users schrieb am Montag, 27. Dezember 2021 11:43
(+01:00):



Hi



I define temporary variables in a method, e.g. |e r |, e.g. in a unit test,
but when I run the test Pharo automatically replaces these with | tmp1 tmp2
|.

A similar thing happens with method arguments.  For example methodName:
aString at: anInteger will become methodName: arg1 at: arg2.



This has happened through my entire model, not just as described above.
What is going on.  Is it a bug, or is there a setting that needs to be
changed?



Many thanks for any feedback on this.



Regards

Robert Briggs


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

[Pharo-users] Re: Fwd: [vwnc] Exception in Regex11 1.4.6

[Steffen Märcker]

Thanks Sebastian, that's exactly what I was looking for. I vaguely remembered 
that such a site exits. =)


Have a nice day!
Steffen



Sebastian Jordan schrieb am Dienstag, 29. Juni 2021 18:23:23 (+02:00):


Here


https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo



Sebastian


From: Steffen Märcker 
Sent: Tuesday, June 29, 2021 6:13:00 PM
To: Any question about pharo is welcome 
Subject: [Pharo-users] Re: Fwd: [vwnc] Exception in Regex11 1.4.6
 
Dear all!


I just checked and found that Regex in Pharo is indeed based on Regex11. It 
suffers from the same bug as the original. I'd like to bring the fix to Pharo. 
As a first-timer, where can I read about the procedure of contributing code?


Kind regards,
Steffen

Steffen Märcker schrieb am Donnerstag, 24. Juni 2021 18:52:16 (+02:00):


Hi!


Does Pharo use the Regex11 package? If yes, has it already diverged from the 
version shipped with VisualWorks?


The reason I am asking is that I just pushed an update to the public store. It 
addresses a bug that prevented $[ to be used in a character class. For details, 
see the excerpt below. Furthermore, you might have an opinion on allowing more 
escape sequences in character classes, don't you?


Kind regards,
Steffen


- Weitergeleitete Nachricht -
Von: Steffen Märcker 
An: 'VWNC' 
Betreff: Re: [vwnc] Exception in Regex11 1.4.6
Datum: Thu Jun 24 2021 18:47:01 GMT+0200 (Mitteleuropäische Sommerzeit)


Hi!


I just published Regex11 version 1.4.7 with the following changes:


1. Fix: Character sets could not contain an opening bracket $[.
2. Fix: Character sets could not contain the characters '[:', e.g. as in 
'[[:something]' asRegex.


I also provided additional tests for the improved functionality. I might tidy 
the code a bit later in a minor version bump.



Just to note that Regex11 uses [[:xxx:]] as a special syntax, which might 
interfere with attempts to allow [[] and []]. 



Indeed. If I did no mistake, the new version does not break this.



I agree with the idea to allow backslash escaping in character classes too, 
with the default being that backslash followed by any character is parsed as 
that character.

I also like the idea of allowing more backslash escaping in character classes. 
However, I still have the bad feeling that this might change the semantics of 
existing code. Hence, I refrained from implementing this right away until I am 
more confident that this does not break other peoples stuff.



Currently only a few explicitly defined backslash escapes are recognized, 
forcing the user to remember whether a given character can be used as-is in a 
given context, or must be escaped.

 

A couple of gotchas (probably not applicable in a character set?):

\<   an empty string at the beginning of a word

\>   an empty string at the end of a word

Thanks, I'll keep them in mind and consider them when I decide to implement the 
changes.


OT: I also noticed that repetition, e.g. '.{5}' behaves strange. For instance, 
'.{{5}}' should match 'a{}' but it doesn't. Has anyone an opinion on that 
one?


Best regards, Steffen

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

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

[Pharo-users] Re: Fwd: [vwnc] Exception in Regex11 1.4.6

[Steffen Märcker]

Dear all!


I just checked and found that Regex in Pharo is indeed based on Regex11. It 
suffers from the same bug as the original. I'd like to bring the fix to Pharo. 
As a first-timer, where can I read about the procedure of contributing code?


Kind regards,
Steffen

Steffen Märcker schrieb am Donnerstag, 24. Juni 2021 18:52:16 (+02:00):


Hi!


Does Pharo use the Regex11 package? If yes, has it already diverged from the 
version shipped with VisualWorks?


The reason I am asking is that I just pushed an update to the public store. It 
addresses a bug that prevented $[ to be used in a character class. For details, 
see the excerpt below. Furthermore, you might have an opinion on allowing more 
escape sequences in character classes, don't you?


Kind regards,
Steffen


- Weitergeleitete Nachricht -
Von: Steffen Märcker 
An: 'VWNC' 
Betreff: Re: [vwnc] Exception in Regex11 1.4.6
Datum: Thu Jun 24 2021 18:47:01 GMT+0200 (Mitteleuropäische Sommerzeit)


Hi!


I just published Regex11 version 1.4.7 with the following changes:


1. Fix: Character sets could not contain an opening bracket $[.
2. Fix: Character sets could not contain the characters '[:', e.g. as in 
'[[:something]' asRegex.


I also provided additional tests for the improved functionality. I might tidy 
the code a bit later in a minor version bump.



Just to note that Regex11 uses [[:xxx:]] as a special syntax, which might 
interfere with attempts to allow [[] and []]. 



Indeed. If I did no mistake, the new version does not break this.



I agree with the idea to allow backslash escaping in character classes too, 
with the default being that backslash followed by any character is parsed as 
that character.

I also like the idea of allowing more backslash escaping in character classes. 
However, I still have the bad feeling that this might change the semantics of 
existing code. Hence, I refrained from implementing this right away until I am 
more confident that this does not break other peoples stuff.



Currently only a few explicitly defined backslash escapes are recognized, 
forcing the user to remember whether a given character can be used as-is in a 
given context, or must be escaped.

 

A couple of gotchas (probably not applicable in a character set?):

\<   an empty string at the beginning of a word

\>   an empty string at the end of a word

Thanks, I'll keep them in mind and consider them when I decide to implement the 
changes.


OT: I also noticed that repetition, e.g. '.{5}' behaves strange. For instance, 
'.{{5}}' should match 'a{}' but it doesn't. Has anyone an opinion on that 
one?


Best regards, Steffen

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

[Pharo-users] Fwd: [vwnc] Exception in Regex11 1.4.6

[Steffen Märcker]

Hi!


Does Pharo use the Regex11 package? If yes, has it already diverged from the 
version shipped with VisualWorks?


The reason I am asking is that I just pushed an update to the public store. It 
addresses a bug that prevented $[ to be used in a character class. For details, 
see the excerpt below. Furthermore, you might have an opinion on allowing more 
escape sequences in character classes, don't you?


Kind regards,
Steffen


- Weitergeleitete Nachricht -
Von: Steffen Märcker 
An: 'VWNC' 
Betreff: Re: [vwnc] Exception in Regex11 1.4.6
Datum: Thu Jun 24 2021 18:47:01 GMT+0200 (Mitteleuropäische Sommerzeit)


Hi!


I just published Regex11 version 1.4.7 with the following changes:


1. Fix: Character sets could not contain an opening bracket $[.
2. Fix: Character sets could not contain the characters '[:', e.g. as in 
'[[:something]' asRegex.


I also provided additional tests for the improved functionality. I might tidy 
the code a bit later in a minor version bump.



Just to note that Regex11 uses [[:xxx:]] as a special syntax, which might 
interfere with attempts to allow [[] and []]. 



Indeed. If I did no mistake, the new version does not break this.



I agree with the idea to allow backslash escaping in character classes too, 
with the default being that backslash followed by any character is parsed as 
that character.

I also like the idea of allowing more backslash escaping in character classes. 
However, I still have the bad feeling that this might change the semantics of 
existing code. Hence, I refrained from implementing this right away until I am 
more confident that this does not break other peoples stuff.



Currently only a few explicitly defined backslash escapes are recognized, 
forcing the user to remember whether a given character can be used as-is in a 
given context, or must be escaped.

 

A couple of gotchas (probably not applicable in a character set?):

\<   an empty string at the beginning of a word

\>   an empty string at the end of a word

Thanks, I'll keep them in mind and consider them when I decide to implement the 
changes.


OT: I also noticed that repetition, e.g. '.{5}' behaves strange. For instance, 
'.{{5}}' should match 'a{}' but it doesn't. Has anyone an opinion on that 
one?


Best regards, Steffen

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

[Pharo-users] Re: Rounding in Floats

[Steffen Märcker]

Typo: FP should read floating point and not fixed point.

Steffen Märcker schrieb am Dienstag, 15. Juni 2021 08:47:24 (+02:00):

> Have you considered using fixed-point arithmetic? For example:
> 7.1s2 roundTo: 0.1s2
>
> The rule of thumb I stick to is to use FP only if I know the inaccuracies
> won't bite me. Funny enough, both 7.1 and 0.1 are already not accurately
> representable as floats. (And by coincidence, I prepared exam questions
> about floats for my students yesterday. )
>
> Kind regards,
> Steffen
>
>
> Konrad Hinsen schrieb am Dienstag, 15. Juni 2021 07:02:30 (+02:00):
>
> > On 15/06/2021 01:03, Esteban Maringolo wrote:
> > > Sure, but what initiated this thread was a reference to roundTo: 0.1
> > > which produced a "wrong" output.
> > >
> > > (9.1 + (-2.0)) roundTo: 0.1 "=> 7.1005"
> > > 7.1 roundTo: 0.1 "=> 7.1005"
> > >
> > > However, at this point I know that Pharo "does the right, raw, thing"
> > > (at least compared to other mainstream languages), but it still
> > > produces a surprise effect.
> >
> > That's the "floating point surprise" that everyone has at some point, no
> matter the language and runtime system. If that surprise is a problem for
> you, are you sure that floating-point arithmetic is what you really want?
> Maybe your needs are better served with integers and fractions.
> >
> >
> > Konrad.
> >
> >
> --
> Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com
> herunter.
>
-- 
Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

[Pharo-users] Re: Rounding in Floats

[Steffen Märcker]

Have you considered using fixed-point arithmetic? For example:
7.1s2 roundTo: 0.1s2

The rule of thumb I stick to is to use FP only if I know the inaccuracies
won't bite me. Funny enough, both 7.1 and 0.1 are already not accurately
representable as floats. (And by coincidence, I prepared exam questions
about floats for my students yesterday. )

Kind regards,
Steffen


Konrad Hinsen schrieb am Dienstag, 15. Juni 2021 07:02:30 (+02:00):

> On 15/06/2021 01:03, Esteban Maringolo wrote:
> > Sure, but what initiated this thread was a reference to roundTo: 0.1
> > which produced a "wrong" output.
> >
> > (9.1 + (-2.0)) roundTo: 0.1 "=> 7.1005"
> > 7.1 roundTo: 0.1 "=> 7.1005"
> >
> > However, at this point I know that Pharo "does the right, raw, thing"
> > (at least compared to other mainstream languages), but it still
> > produces a surprise effect.
>
> That's the "floating point surprise" that everyone has at some point, no
matter the language and runtime system. If that surprise is a problem for
you, are you sure that floating-point arithmetic is what you really want?
Maybe your needs are better served with integers and fractions.
>
>
> Konrad.
>
>
--
Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com
herunter.

[Pharo-users] Re: [Pharo-dev] [Ann] Pharo new version available & mooc needs subtitle translaters

[Steffen Märcker]

*rofl* Well, I was not even close ... Thanks!

Am .11.2020, 11:04 Uhr, schrieb jtuc...@objektfabrik.de
:


YEs, you miss the year ;-) It says 2021



Am 10.11.20 um 10:13 schrieb Steffen Märcker:

Hi!

Is it still possible to attend / watch the Mooc? The page
(https://www.fun-mooc.fr/courses/course-v1:inria+41024+session01/about)
tells that registration ended on nov 07. Or do I miss other ways to
access the course and its material?

Best,
Steffen

Am .11.2020, 18:02 Uhr, schrieb Hernán Morales Durand
:


<---Schnitt--->

[Pharo-users] Re: [Pharo-dev] [Ann] Pharo new version available & mooc needs subtitle translaters

[Steffen Märcker]

Hi!

Is it still possible to attend / watch the Mooc? The page  
(https://www.fun-mooc.fr/courses/course-v1:inria+41024+session01/about)  
tells that registration ended on nov 07. Or do I miss other ways to access  
the course and its material?


Best,
Steffen

Am .11.2020, 18:02 Uhr, schrieb Hernán Morales Durand  
:



El mié., 4 nov. 2020 a las 5:30, Stéphane Ducasse (<
stephane.duca...@inria.fr>) escribió:


Hello

We are about to launch the new version of the Pharo mooc. Spread the  
word

around you. It will open the 9th of november
https://www.fun-mooc.fr/courses/course-v1:inria+41024+session01/about


This new version contains
70 new videos about the Pharo ide (in french and english voice) +  
subtitles

better english dubs

Now we are looking for help for the subtitles
All the subtitles of the previous mooc and the new ones are at

https://github.com/pharo-mooc/PharoMooc/tree/master/2020-All-Subtitles-Reorganized
The new ones in folders named C048SD or 2018-Prese*
The old ones in folders named C019SD.




I will help to translate the new ones to Spanish.

Cheers,

Hernán

[Pharo-users] Re: order of execution

[Steffen Märcker]

Hi,

don't forget to read the expression from left to right:


currTotal := prevTotal + (prevTotal := currTotal).

5  1 43  2
1. the current value (X) of prevTotal is fetched.
2. the current value (Y) of currTotal is fetched
3. prevTotal is assigned currTotal which is also the value of the
parenthesis
4. X is sent the message + with the argument Y
5. currTotal is assigned the result from 4.

Kind regards,
Steffen

Am .09.2020, 15:05 Uhr, schrieb Russ Whaley :


Can someone please explain this? I'm guessing I don't understand order of
execution.

When perusing >>fibonacciSequence, I get a proper result, but I don't
understand why when looking at the code.

Consider this fragment...

prevTotal := 0.
currTotal := 1.
currTotal := prevTotal + (prevTotal := currTotal).

My understanding *was* that parentheses are executed first.

(prevTotal := currTotal) - assigns and returns 1


currTotal := prevTotal + (1)


and since prevTotal = 1

currTotal := 1 + (1)


prevTotal = 1.

currTotal = 2.


Yet what appears to be happening is...

prevTotal = 0

currTotal := 0 + (prevTotal := currTotal)


then the parentheses...

currTotal := 0 + (1)


prevTotal = 1.

currTotal = 1.


Care to school me?

Thanks!
Russ

Re: [Pharo-users] Can it do this way ?

[Steffen Märcker]

Hi Richard and Roelof,

thanks for your comprehensive answer. I brought up Regex only to point out  
alternative solutions. Another one is the following using transducers,  
where Tee works like the tee command from the command line.


IsbnValidator>>isValidIsbn: aString
  | length countChars separators getSeparators lastChar getLastChar  
filterDigits computeCheckSum checkSum |


  "Count number of characters"
  length := 0.
  countChars := [:count :char | length := length + 1] init: length.

  "Get non-digit characters"
  separators := Set new
  getSeparators := separators <~ #isDigit remove.

  "Get last character"
  lastChar := nil.
  getLastChar := [:prev :char | lastChar := char ] init: lastChar.

  "Get digits"
  filterDigits := #isDigit filter.

  "Calculate check sum"
  computeCheckSum := ([:sum :index :digit | sum + index * digit value]  
init: 0) completing: #\\ .


  "Compute"
  checkSum := aString
transduce: (Tee to: countChars) * (Tee to: getSeparators) * (Tee to:  
getLastChar) * filterDigits

reduce: computeCheckSum
init: 0.

  "Check validity"
  ^((length = 10 or: [length = 13])
and: [separators = Set with: $-])
and: [checkSum = (lastChar = $X ifTrue: [10]  ifFalse: [lastChar  
value])]


Kind regards,
Steffen


Am .09.2020, 08:30 Uhr, schrieb Roelof Wobben via Pharo-users  
:



Op 8-9-2020 om 04:22 schreef Richard O'Keefe:

There are two quite different questions.
(1) Where may dashes occur in a real ISBN-10?
(2) What does Exercism require in the specification and check in the
test cases?

For (1) the rules are

Each ISBN consists of 5 elements with each section being separated by  
spaces or hyphens. Three of the five elements may be of >>varying  
length:
Prefix element – currently this can only be either 978 or 979. It is  
always 3 digits in lengthRegistration group element – this identifies  
the particular country, geographical region, or language area  
participating >>in the ISBN system. This element may be between 1 and 5  
digits in lengthRegistrant element - this identifies the particular  
publisher or imprint. This may be up to 7 digits in lengthPublication  
element – this identifies the particular edition and format of a  
specific title. This may be up to 6 digits >>in lengthCheck digit –  
this is always the final single digit that mathematically validates the  
rest of the number. It is >>calculated using a Modulus 10 system with  
alternate weights of 1 and 3.An ISBN-10 does not have the three-digit  
prefix.  So we have

 [0-9]{1,5}   -- prefix
 [0-9]{1,7}   -- registrant
 [0-9]{1,6}   -- publication
 [0-9X]
 -- check digit

As an examplw, "Standard C++ IOStreams and Locales" by Langer & Kreft  
has

ISBN-10 0-201-18395-1
ISBN-13 9780201183955
so I shall assume the separators are optional.
/^[0-9]{1,5}[- ]?[0-9]{1,7}[- ]?[0-9]{1,6}[- ]?[0-9X]$/
Of course the elements cannot all have their maximum length at the same
time.  In AWK I would write
  x = a_putative_ISBN_10
  y = x
  gsub(/[- ]+/, "", y)
  if (x ~ /^[0-9]{1,5}[- ]?[0-9]{1,7}[- ]?[0-9]{1,6}[- ]?[0-9X]$/ \
   && y ~ /^[0-9]{9,9}[0-9X]$/ \
  ) {
  x *might* be valid, we still need to check the checksum
  }

For (2), there appear to be no restrictions on where dashes may occur
or how many: "These may be communicated with or without hyphens".
Exercism doesn't allow spaces.

Regular expressions are elegant in their own way, BUT for this problem
they are (a) excessive, (b) inefficient, and (c) insufficient.

  digit count := 0.
  check sum := 0.
  for each character c of the string
  if c is not a hyphen then
  if c is a digit then
  digit value := c's value as a digit
  else if c is X and digit count = 9 then
  digit value := 10
  else
  return false.
  digit count := digit count + 1.
  if digit count > 10 then return false.
  check sum := (11 - digit count) * digit value + check sum.
   return check sum mod 11 is zero.

Part of the insight here is "don't DO it, just PRETEND you did."
That is, instead of copying the string without the hyphens,
just ignore the hyphens as they turn up.
Another part is "if you are only going to use it once, don't store it."
That is, we need a digit's value just once, in the update to check sum,
so we should compute it just before we need it, not store it.

Now the pseudo-code above is classic sequential imperative coding.

Classic functional coding does something like
  let no_dashes = filter (/= '-') (explode string) in
  length no_dashes = 10 and
  let check = last no_dashes in
  (is_digit check or check = 'X') and
  all is_digit (take 9 no_dashes) and
  let xval c = if x = 'X' then 10 else digit_value c in
  dot (map xval no_dashes) [10,9..1]) mod 11 = 0

This pseudo-code translates nicely to Smalltalk too.
You might want to add

SequenceableCollection>>
 with: other inject: initial into: aBlock
   |r|
   r := initial.
   self with: other do: [:x :y |
 r := 

Re: [Pharo-users] Can it do this way ?

[Steffen Märcker]

Now having a Workspace at hand, I fixed some minor typos:

IsbnVarifier>>isSyntacticIsbn: aString
  | nonGrouped dashes spaces grouped |
  nonGrouped := '\d{9}[0-9X]' asRegex.
  "groups separated by either dashes or spaces"
  dashes := '\d{1,7}-\d{1,7}-\d{1,7}-[0-9X]'.
  spaces := '\d{1,7} \d{1,7} \d{1,7} [0-9X]'.
  grouped := (dashes , '|' , spaces) asRegex.
  ^(aString matchesRegex: nonGrouped) or:
[(aString matchesRegex: grouped) and:
  [aString size = (10 + 3)]]

Best, Steffen


Am .09.2020, 19:01 Uhr, schrieb Steffen Märcker :


Hi,

after reading the link and some additional sources, it turns out that a
valid ISBN-10 has either no separators or four blocks separated by either
dashes or spaces:
   Group-Publisher-Title-CheckDigit

Assuming Regex11 (and that I made no mistake), the following should do  
the

trick:

IsbnVarifier>>isSyntacticIsbn: aString
   "no groups"
   noGrouped := '\d{9}[0-9X]' asRegex.
   "groups separated by either dashes or spaces"
   dashes := '\d{1,7}-\d{1,7}-\d{1,7}-[0-9X]'
   spaces := '\d{1,7} \d{1,7} \d{1,7} [0-9X]'
   grouped := (dashed , '|' , spaces) asRegex.

   ^(aString matches: nonGrouped) or:
 [(aString matches: grouped) and:
   [aString size = 10 + 3]]

Surely, you could cleverly compress the regex even further but that does
not matter for this example. After checking the syntax, you can just
iterate over the string and compute the check-digit on the fly.

Kind regards,
Steffen

Am .09.2020, 18:19 Uhr, schrieb Roelof Wobben via Pharo-users
:


See here for all the tests :
https://github.com/exercism/pharo-smalltalk/blob/master/exercises/isbn-verifier/IsbnVerifierTest.class.st#L88

Roelof

Re: [Pharo-users] Can it do this way ?

[Steffen Märcker]

Hi,

after reading the link and some additional sources, it turns out that a
valid ISBN-10 has either no separators or four blocks separated by either
dashes or spaces:
  Group-Publisher-Title-CheckDigit

Assuming Regex11 (and that I made no mistake), the following should do the
trick:

IsbnVarifier>>isSyntacticIsbn: aString
  "no groups"
  noGrouped := '\d{9}[0-9X]' asRegex.
  "groups separated by either dashes or spaces"
  dashes := '\d{1,7}-\d{1,7}-\d{1,7}-[0-9X]'
  spaces := '\d{1,7} \d{1,7} \d{1,7} [0-9X]'
  grouped := (dashed , '|' , spaces) asRegex.

  ^(aString matches: nonGrouped) or:
[(aString matches: grouped) and:
  [aString size = 10 + 3]]

Surely, you could cleverly compress the regex even further but that does
not matter for this example. After checking the syntax, you can just
iterate over the string and compute the check-digit on the fly.

Kind regards,
Steffen

Am .09.2020, 18:19 Uhr, schrieb Roelof Wobben via Pharo-users
:


See here for all the tests :
https://github.com/exercism/pharo-smalltalk/blob/master/exercises/isbn-verifier/IsbnVerifierTest.class.st#L88

Roelof

Re: [Pharo-users] Can it do this way ?

[Steffen Märcker]

No problem. I am not knowledgeable about isbn numbers. At which places may a 
dash occur?

Kind regards,
Steffen

07.09.2020 16:18:22 Roelof Wobben via Pharo-users :

> Op 6-9-2020 om 10:07 schreef Steffen Märcker:
>> Maybe this is a naive question, but can you just split the task into the
>> following two?
>> 
>> 1. Check whether whether the string is syntactically an ISBN number.
>> This can be done, e.g., using a regex.
>> 
>> 2. Check the the check character.
>> Calculate the check character from the (now to be known) syntactically
>> valid string.
>> 
>> ISBNValidator>>isValidISBN: aString
>> ^(self isSyntacticallyValid: aString) and: [self isCheckCharacterValid:
>> aString]
>> 
>> Kind regards,
>> Steffen nder if the code will not be too big. I learned that it is good
>> 
> Sorry to respond not earlier but your respons seems to be in the spam folder 
> of my provider.
> 
> I could do that but if very bad in regex so I do not know a regex which van 
> validate 123456789 or 123-456-78-9
> 
> Roelof
> 

Re: [Pharo-users] Can it do this way ?

[Steffen Märcker]

Maybe this is a naive question, but can you just split the task into the
following two?

1. Check whether whether the string is syntactically an ISBN number.
This can be done, e.g., using a regex.

2. Check the the check character.
Calculate the check character from the (now to be known) syntactically
valid string.

ISBNValidator>>isValidISBN: aString
  ^(self isSyntacticallyValid: aString) and: [self isCheckCharacterValid:
aString]

Kind regards,
Steffen

Am .09.2020, 07:35 Uhr, schrieb Roelof Wobben via Pharo-users
:


Nope, with your idea I cannot make this part work :

he ISBN-10 format is 9 digits (0 to 9) plus one check character (either
a digit
or an X only). In the case the check character is an X, this represents
the
value '10'. These may be communicated with or without hyphens, and can be
checked for their validity by the following formula:

(x1 * 10 + x2 * 9 + x3 * 8 + x4 * 7 + x5 * 6 + x6 * 5 + x7 * 4 + x8 * 3
+ x9 * 2 +

so I mean the calculation.


Roelof


Op 4-9-2020 om 06:45 schreef Roelof Wobben:

oke, then I could use your idea but then I have to make the code for
calculating
if its a valid number.
and I wonder if the code will not be too big. I learned that it is good
that a
method does only 1 thing and this one seems to be doing more then 1
thing.

Roelof



Op 4-9-2020 om 05:24 schreef Richard O'Keefe:

What part of "return false if there are not exactly 10 characters

left after discarding dashes" fails to handle the empty string?

A test case for the empty string is is only valuable if the

empty string is NOT a special case.



On Wed, 2 Sep 2020 at 22:52, Roelof Wobben  wrote:

Op 2-9-2020 om 12:38 schreef Richard O'Keefe:

There is simply no point in "taking the first nine numbers out".

And there shouldn't BE a test for the string being empty, anywhere.

'' '-' '---' and so on should all be handled the same way.


Oh well, what stops you doing


digits := aString select: [:each | each ~= $-].

digits size = 10 ifFalse: [^false].

lastDigit := digits la ost.

digits := digits copyFrom: 1 to: 9.

( (lastDigit = $X or: [lastDigit isDigit]) and: [

digits allSatisfy: #isDigit]

) ifFalse: [^false].


Now my code does not do this, but it is just 16 lines of code with

nothing that it would make sense to extract.



Nothing only that I could not think of this one for myself.
If I do it the TDD way I come more on the way Im currently thinking

but does this case then be covered

test14_EmptyIsbn
| result |
result := isbnVerifierCalculator isValidIsbn: ''.
self assert: result equals: false

and still I have to do the calcualation to see if it's valid.
If I understand the code well I can use the digits variable ?


Roelof

Re: [Pharo-users] Rosetta Code

[Steffen Märcker]

Hi,

I'd be interested to see how youe approached these problems.

Best,
Steffen

Am .04.2020, 15:49 Uhr, schrieb Richard O'Keefe :


I've tackled more than 600 of the RosettaCode problems in Smalltalk.
Unfortunately, this was done as exercises in developing my own Smalltalk
system.  If anyone would like to have a zip file to serve as a shortcut
for
developing Pharo versions, you'd be very welcome.

On Fri, 17 Apr 2020 at 21:31, Steffen Märcker  wrote:


Hi,

some of you might have hear of Rosetta Code, a Wiki that presents
solutions to standard programming tasks in various languages. I figured
that in many categories no Smalltalk/Pharo solutions are shown. Maybe we
can contribute some pieces from time to time? I started with the
following:

https://rosettacode.org/wiki/Tree_traversal#Smalltalk

Your comments are welcome.

Best, Steffen

[Pharo-users] Rosetta Code

[Steffen Märcker]

Hi,

some of you might have hear of Rosetta Code, a Wiki that presents
solutions to standard programming tasks in various languages. I figured
that in many categories no Smalltalk/Pharo solutions are shown. Maybe we
can contribute some pieces from time to time? I started with the following:

https://rosettacode.org/wiki/Tree_traversal#Smalltalk

Your comments are welcome.

Best, Steffen

[Pharo-users] Hi-DPI Support

[Steffen Märcker]

Hi,

I'd like to ask about the state of Hi-DPI support for Pharo. I already
found two related GitHub issues which where inconclusive so far. Does the
discussion take place elsewhere? If so, where? If not:

- What is the current state?
- Does a plan exist how to get there?
- What are the missing pieces?
- How can I support this endeavor in practice?

Best, Steffen

Re: [Pharo-users] [ANN] uFFI Booklet v1.0

[Steffen Märcker]

Great! Thanks for the effort of putting this example-driven booklet together!


Steffen

Guillermo Polito schrieb am Wed Feb 12 2020 10:30:31 GMT+0100 
(Mitteleuropäische Normalzeit):


Hi all,


We have been working a lot in the last months in the documentation of uFFI, and 
we are happy to announce a first stable version of it that you’ll find in a 
link below :)
The booklet talks about uFFI, how to use it, how marshalling works, how to use 
structures, unions, etc.
And it is aimed for the version present on Pharo8.0.


https://github.com/SquareBracketAssociates/Booklet-uFFI/releases/tag/v1.0.1


Of course, a v1 does not mean it’s perfect. Future versions will include new 
chapters/features that are on the pipeline such as callbacks and how to specify 
string encodings in your bindings.
Also, so if you find something to fix, to add, to remove, or something hard to 
follow, let us know 
 - by email or
 - by issue (will be easier to track actually than an email) or
 - by PR (and we will have a boost of happiness in addition)


Cheers,
Guille in behalf of everybody that helped and contributed to this

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

Dear Sean,

thanks for bringing this up and for the interesting link [1]. I'll have a  
look. Meanwhile, I am still on both lists. ;-)



Steffen Märcker wrote

I wrote a PetitParserGenerator that takes the DSL and builds a
PetitParser.


I don't know how I could've missed this gem! I hope Steffen is still
subscribed. I googled "PetitParserGenerator", but only found these ML  
posts

:/


It was easy to miss, since I never actually posted that code. Here's what  
I've done:


From Xtreams.PEG syntax:
- PetitParserGenerater > PetitParser code
- PetitParserParser> PetitParser instance

I can send you that code. It should be straight forward to adapt it for  
PP2. However, I moved away from Xtreams own PEG flavor to Bryan Ford's  
original PEG syntax (close but more common) and programmed for Xtreams, PP  
and PP2:


From Bryan Ford's original PEG syntax:
1. Xtreams Grammer and Actor that build an Xtreams parser
2. PP(2)PEGParserParser that builds a PP(2) parser instance
3. PP(2)PEGParserCompiler that builds PP(2) parser classes

All three are available for VW in the Cincom's public repository:
- Xtreasm-Parsing (8.2-3,stm): +PEG parser +some fixes to Xtreams parser
- PetitParser-PEG (1.11,stm)
- PetitParser2-PEG (1.11,stm)

And 2, 3 for Pharo on GitHub, e.g.
- https://github.com/kursjan/petitparser2/tree/master/PetitParser2-PEG

Speaking of, I just noticed that translator form Xtreams.PEG to PEG is  
missing to complete the picture here. ;-)



IIRC Xtreams can take a BNF and generate a parser.


As far as I know, there is no BNF-like parser generator for Xtreams,  
available.



wouldn't mind a two step BNF -> Xtreams -> PP process.


Is it an option for you to convert your BNF to PEG manually?

Best regards,
Steffen

Re: [Pharo-users] BlockClosure

[Steffen Märcker]

Looks nice!

Just my two cents. To make function comopostion work with multiple
aruments, I implemented * as:

  BlockClosure class>>* first
^ComposedFunction first: first second: self

And use a dedicated class to make multiple arguments work:

  ComposedFunction>>value: arg
^second value: (first value: arg)

  ComposedFunction>>value: arg1 value: arg2
^second value: (first value: arg1 value arg2)

Then, we can write:

  [:x | x factorial ] * [:x :y | x + y]
value: 1 value: 2


(I usually use the mathematical compostion operator, wich evalutes from
right to left.)

However, it is often convenient to interchange Symbols and Blocks, e.g.,
the above can be rewritten as

  #factorial * #+
value: 1 value: 2

That requires to implement the * operator on symbols, too. And depending
on your Smalltalk implemenation, you may have to implement the evaluation
protocol on symbols.

Best, Steffen


Am .10.2019, 15:12 Uhr, schrieb main :


Hi again!

Just putting it out there for anyone interested.

What I did was define the following in Object:

|> aBlock
^ [ :x | x => self => aBlock ]

and also:

=> msg
^ msg value: self


This enabled me to compose like this (I know I probably violate every
rule
in the book, whatever ):

f :=  [ :x | x + 100 ].
g := [ :x | x +   20 ].
h := [ :x | x + 3 ].

0 => (f |> g |> h). 123

Also tried using ~:

0 => (f ~ g ~ h). 123

It's just a matter of taste I guess, but for me it warms my heart



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Concurrency Best Practices + Tests

[Steffen Märcker]

I can definitely second all the points. If you want to verify your design
formally, Vereofy (http://www.vereofy.de) is another model checker that
focuses on communication and coordination.

Best, Steffen



Am .10.2019, 08:49 Uhr, schrieb Richard O'Keefe :


(1) Be very clear in your design about which objects are shared and
which are not.
(2) Immutable objects can be shared safely.  Mutable ones are much
much harder to work with.
(3) Lazy initialisation does not work well in concurrent programming,
*except* when you are
 constructing an immutable value and it doesn't matter if the
variable is initialised twice.
(4) If you can possibly do so, *SEPARATE* the concurrency structure
from the application-
 specific work.  Use something like Promela/SPIN, or NuSMV, or
NuXmv, to check your
 concurrency structure,  or CPN Tools if you prefer Coloured Petri
Nets as a modelling
 notation.  This is what Erlang does with great success with
"behaviours"; the concurrency
 structures are there in the library and you just plug in the
non-concurrent part.  Look up
"parallelism patterns" and "algorithmic skeletons".  The book
 
https://pdfs.semanticscholar.org/f43e/7c6a40b96743f2217472a49cd616622bdc26.pdf
 may be helpful.  Separation of concerns: this way you can test
the concurrency
 structure of your code independently of the rest.
(5) It isn't clear to me that TDD is a good way to develop concurrent
programs.  It's a great
 way to develop the non-concurrent *parts*.  One reason I say this
is that I've found that
 it is better to avoid adding unneeded sequencing in a design than
to add concurrency
 to a sequential code.  If you try to *add* critical sections in a
language like Lisp or
 Smalltalk, you *will* miss some.  So the TDD Way of is likely to
seduce you into
 making your code too sequential too soon.
(6) I personally find processes communicating via SharedQueues *much*
easier to design
 and make work than processes communicating via shared variables
and mutexes or
 semaphores.  (Basically, a Semaphore is a SharedQueue that can
only remember how
 many items it's holding, not what they were.)  Your experience
may be different, but
 Processes with private data communicating via SharedQueues
transfer much easier
 to concurrent activities on separate machines communicating via
sockets.

On Thu, 5 Sep 2019 at 01:32, Noury Bouraqadi  wrote:


Hi everyone,

Can I get your input on the following questions :

- What are your best practices and recommendations for developing and
testing concurrent software?

- How to discover need for synchronization/critical sections/ when
doing TDD?

- How to write code to avoid dead-locks?

Noury

Re: [Pharo-users] Lazy Streams - was: Re: Set >> collect:thenDo:

[Steffen Märcker]

Hi,

I really think we should have an efficient way to chain operations on
collections and alike. In my personal opinion, this should be backed by
transducers, as they decouple the operations from the type the data source
and sink. Hence they are applicable to different collection types, streams
and so on. Also, transducers allow for straight-forward parallization of
operations that are concurrency-safe.

However, the transducers port is not complete yet. I think I'll finish it
in October/November, but definitely this year. Maybe this could be a
starting point to discuss how to move forward?

One related question: Is there a somewhat comprehensive benchmark yielding
a baseline of Pharo's collection/streams/iteration performance? I'd really
like to compare the existing implemenation to the alternative approaches.

Best regards,
Steffen


Am .09.2019, 11:30 Uhr, schrieb Kasper Østerbye
:


On 10 September 2019 at 00.56.28, Richard O'Keefe (rao...@gmail.com)
wrote:

Does that sound like a way forward?
I could convert my implementation of this interface to
Pharo if people would like me to.

Hi Richard,

It seems like what you propose (in sofar as I understand it) is already
present in at least three other libraries which have not yet made it to
the
core of Pharo:

The Iterator framework Julien is working on:
https://github.com/juliendelplanque/Iterators

The XStreams framework: https://code.google.com/archive/p/xtreams/


The transducers: https://github.com/Pharophile/Transducers


I was not aware of the virtual collections from Strongtalk.

I am aware you know them (as you commented on the Iterators Julien
proposed).

I have been working with the LINQ stream/iterator framework in C#, and
found that to be a rather sound library, lazy evaluation. The streams in
Java are also nice, and are actually very good at exploiting multi cores.

It is sad there is no lazy streams in the core of Pharo, and I would find
it intersting to participate in a project to build one.

Best,

Kasper

Re: [Pharo-users] Set >> collect:thenDo:

[Steffen Märcker]

I think this thread indicates that the selector #collect:thenDo: may
indeed cause some missunderstanding given standard semantics of #collect:.
Is there any reason not to use a different one, such as #map:thenDo:, to
make the difference clearer?

A nice side effect could be a new automatic refactoring rule that
consolidates chained #collect: and #do: sends into a faster
#collect:thenDo: send without breaking existing code.

Am .09.2019, 07:46 Uhr, schrieb Richard O'Keefe :


(1) If you want (aSet collect: collectBlock) do: doBlock
you can write exactly that.  Nothing stops you, and it will
be as clear and reliable as any use of Set>>collect:, which
is to say NOT VERY CLEAR OR RELIABLE AT ALL.

(2) #collect:then{Do:Select:Reject:} had no other purpose than
to avoid creating an intermediate and otherwise useless
collection.  If you are not trying to involve an intermediate
set then it just plain wrong to use #collect:thenDo:.

(3) Oddly enough, the reason that #collect:thenDo: exists in my
library is that I copied it from Squeak, at a time when it had
the same definition as Pharo and ST/X.  Had I known of the change
in Squeak I would have bitterly opposed it.  The comment in the
current Squeak code, that it is for readability, is 100% the
reverse of the truth.  Using the version with parentheses is WAY
clearer than using the portmanteau method.  Sigh.  I see they
broke #collect:thenSelect: in the same way.

(4) Let me offer you another member of the #collect:then* family.

Collection
  collect: collectBlock thenInject: initial into: injectBlock
|r|
r := initial.
self do: [:each |
  r := injectBlock value: r value: (collectBlock value: each)].
^r

#(now is the hour for us to say goodbye) asSet
  collect: [:each | each size]
  thenInject: 0 into: [:acc :each | acc + each]
 => 29
(#(now is the hour for us to say goodbye) asSet
  collect: [:each | each size])
  inject: 0 into: [:acc :each | acc + each]
 => 16

   That is, it would be WRONG to implement #collect:thenInject:into:
   as #collect: followed by #inject:into:.  The point is NOT to
   coalesce things that the receiver might (in general, incorrectly)
   regard as equal.

(5) The bottom line is that if #collect:thenDo: and its relatives did
not have their present semantics in Pharo (and ST/X), they would
need to be reinvented, with names that were not as clear.

(1) Just to repeat for emphasis, if you *want* (_ collect: _) do: _
then that is exactly what you should write.  There is no
excuse for using #collect:thenDo: in that case.  It is NOT
clearer to do so.  And you should imagine me jumping up and
down screaming that sending #collect: to a set is a bad code
smell which demands very explicit documentation as to why you
(for example) want a Set to answer a Set but an IdentitySet
to also answer a Set, not the expected IdentitySet.  (I have
been bitten by that more than once.)



On Mon, 9 Sep 2019 at 01:33, Herby Vojčík  wrote:


On 8. 9. 2019 14:28, Peter Kenny wrote:
> Two comments:
> First, the method comment for Collection>>collect:thenDo: is "Utility
method
> to improve readability", which is exactly the same as for
> collect:thenSelect: and collect:thenReject:. This suggests that the
> *intention* of the method is not to introduce new behaviour, but
simply
to
> provide a shorthand for the version with parentheses. For other kinds
of

I had that same impression.

> collection this is true; just the deduping makes Set different. If we
want

I would be more defensive here and say that generic collection should
have (collect:)do: implementation and only sequenceable collections have
the optimized one (if it indeed is the case that it is a shotrhand for
parenthesized one).

> the different behaviour, this should be indicated by method name and
> comment.
> Second, if we remove asSet from the second snippet, the output is
exactly
> the same. It will be the same as long as the original collection has
no
> duplicates. Somehow the effect is to ignore the asSet. It just smells
wrong.
>
> Peter Kenny

Herby

> Kasper Osterbye wrote
>> The first version:
>>
>> (#(1 2 3) asSet collect: #odd)
>> do: [ :each | Transcript show: each; cr ]
>>
>> is rather straight forward I believe, as collect: and do: has been
around
>> forever (relatively speaking).
>>
>>
>> #(1 2 3) asSet collect: #odd
>> thenDo: [ :each | Transcript show: each; cr ]
>>
>>
>> On 8 September 2019 at 09.13.36, Richard Sargent (
>
>> richard.sargent@
>
>> ) wrote:
>>
>>   I am skeptical of one that relies on a specific implementation
rather
>> than
>> a specific definition.
>>
>> I share your feeling. I am not sure where such a definition would
come
>> from. In Squeak it is defined as:
>>
>> collect: collectBlock thenDo: doBlock
>>
>> ^ (self collect: collectBlock) do: doBlock
>>
>> In pharo as:
>>
>> collect: collectBlock thenDo: 

Re: [Pharo-users] Set >> collect:thenDo:

[Steffen Märcker]

Surprise!

The selector #collect:thenDo: strongly suggests that it behaves just as 
#collect: then #do:. But as #collect: usually means map + aggregate in the 
reveiver type, I'd expect the input to the do block to be deduped already. At 
least it is an easy to miss source of subtle bugs. Maybe an additional method 
#map:thenDo: would make sense?

Best, Steffen

Am 8. September 2019 08:02:30 MESZ schrieb "Kasper Østerbye" 
:
>Feature!
>
>collect: forms a new collection of the same kind as its receiver. In
>this
>case a set. As the result of your collect:
>#(1 2 3) asSet collect: #odd)
>is booleans, the resulting set will contain only to elements (the
>duplicate
>odd resulting in true is removed).
>
>collect: thenDo: applies the collect-block to each element of the
>receiver,
>and then applies the do to each of those results. You can see the
>implementation of collect:thenDo: in class Collection.
>
>Best,
>
>Kasper
>
>
>On 7 September 2019 at 17.22.03, Herby Vojčík (he...@mailbox.sk) wrote:
>
>Hello!
>
>
>(#(1 2 3) asSet collect: #odd)
>do: [ :each | Transcript show: each; cr ]
>
>> true
>> false
>
>
>
>#(1 2 3) asSet collect: #odd
>thenDo: [ :each | Transcript show: each; cr ]
>
>> true
>> false
>> true
>
>
>
>Bug or feature?
>
>Herby

Re: [Pharo-users] [ANN] Iterators

[Steffen Märcker]

Hi Julien,

nice work! Could you please tell how your approach is related to
transducers from the user perspective and technically?
(https://github.com/Pharophile/Transducers)

Your example suggests that the API is quite similar to the data flow API
of transducers. Let me show your example using transducers.


result := (#+ init: 0) <~ [:x | x * 2] map <~ #(1 2 3).
OrderedCollection with: result.


Or the more classical way:


result := #(1, 2, 3)
transduce: [:x | x * 2] map
reduce: #+
init: 0.
OrderedCollection with: result.



Best regards,
Steffen

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

[Steffen Märcker]

This is exactly how I think and feel about bags. Thanks Richard.

Am .03.2019, 01:35 Uhr, schrieb Richard O'Keefe :


To me, a bag is first and foremost a multiset.
Yes, it's a collection, but it's not *just* a collection.
It's a very specific kind of collection with a very
salient "characteristic function".

In my own Smalltalk library, #asDictionary isn't even *defined*
on things that are not dictionaries or some kind of mapping,
because let's face it, a dictionary *isn't* a collection of
Associations, and trying to make it look like one made
Smalltalk-80 rather inconsistent.  For example, if a dictionary
were a collection of associations, you would expect
(Dictionary with: #a -> 1 with: #b -> 2) includes: #a -> 1
to be true. No, it's false.  You would expect
(Dictionary with: #a -> 1 with: #b -> 2) asArray
to be (a->1 b->2).  No, it's (1 2).  In order to avoid major
confusion, I had to learn never to think of Associations in
connection with Dictionaries.  So I expect #asDictionary to
have something to do with #keysAndValuesDo:.
or something like that.

For {1->2. 3->4} asDictionary I would have to write
Dictionary withAllAssociations: {1->2. 3->4}
except that I never actually found a use for it.

#valuesAndCounts is a method that violates good OO practice,
because it exposes (what you'd expect to be) private state.
For example,
  b := 'abracadabra' asBag.
  b valuesAndCounts at: $a put: 'BOOM!'.
  b
select, Print It, BOOM!.  It should *copy* the dictionary.



On Thu, 7 Mar 2019 at 04:50, Sven Van Caekenberghe  wrote:


I was just explaining how it is now, what I think the rationale is
behind
it.

I understand #asDictionary as working on a collection of
pairs/associations (because it basically goes to #withAll:).

A bag is just a collection that is optimised for many duplicates, the
fact
that you have values and counts is more an implementation detail than an
intrinsic property.

The conversion that you want, and that already exists in
#valuesAndCounts
is one interpretation of what a bag is, not the only one. A bag is
foremost
a collection of things.

I am not immediately convinced that #valuesAndCounts should be the
default
#asDictionary interpretation.

What about the inverse for example ?

  { #foo->2. #bar->3 } asDictionary asBag.

But this is certainly an interesting discussion.

> On 6 Mar 2019, at 16:23, Tim Mackinnon  wrote:
>
> As Richard said - as a bag is relationship between keys and
frequencies,
I would expect it to be able to convert to a dictionary.
>
> It displays in an inspector just like a Dictionary - which is why I
figured I could convert to pass it back to the exercise that was written
with Dictionaries in mind.
>
> 
>
>
> The code to fix it is quite simple, but on these kinds of things - I
thought it worth checking before submitting a PR.
>
> Tim
>
>
>> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe  wrote:
>>
>> Why would that work ? What would you expect the output to be ?
>>
>> Try:
>>
>>  #(1 2 3) asDictionary
>>
>> it fails in exactly the same way. You need key/value pairs
(Associations).
>>
>> These do work
>>
>>  Bag new add: #foo->100; asDictionary.
>>
>>  Bag new addAll: 'ABABAB'; valuesAndCounts.
>>
>>> On 6 Mar 2019, at 14:25, Tim Mackinnon  wrote:
>>>
>>> I was surprised to find that a Bag can’t convert to a dictionary -
e.g.
>>>
>>> Bag new
>>> addAll: 'aacddd’;
>>> asDictionary
>>>
>>> Gives an error - Dnu #key
>>>
>>>
>>> It looks to me like Bag is inheriting a bad version of
#associationsDo:  and instead could simply forward it to
#doWithOccurences:
instead?
>>>
>>> I know Bag is not used that much - but it comes up a lot in
programming exercises.
>>>
>>> Tim
>>
>>
>

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

[Steffen Märcker]

Is it consistent with the definition of #= in String such that
'aSymbol = aString' iff 'aString = aSymbol'?
Sorry, I don't have an image at hand.


Am 1. März 2019 18:40:11 MEZ schrieb Sven Van Caekenberghe :
>Why ? Please explain ...
>
>> On 1 Mar 2019, at 18:02, David T. Lewis  wrote:
>> 
>> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe
>wrote:
>>> 
>>> 
 On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users
> wrote:
 
 
 From: Petr Fischer 
 Subject: Symbol equality method #= - weird condition in the Pharo
>sourcecode
 Date: 1 March 2019 at 17:08:03 GMT+1
 To: pharo-users@lists.pharo.org
 
 
 Hello, this is Symbol equality method in Pharo:
 
 1: = aSymbol
 2: "Compare the receiver and aSymbol." 
 3: self == aSymbol ifTrue: [^ true].
 4: self class == aSymbol class ifTrue: [^ false].
 5: "Use String comparison otherwise"
 6: ^ super = aSymbol
 
 Look at line 4 - what does it mean? That's wrong, isn't it?
 
 Typically, every symbol comparisons end up in line 3, but if you do
>some work with forward proxies for example, condition on line 3 is
>"false" and then weird things on line 4 happens.
 
 If line 4 and further are correct, can someone explain a little?
 
 Thanks! pf
>>> 
>>> Yes, that looks weird. Line 4 should probably be removed, unless I
>am missing something.
>> 
>> It is wrong in a Spur image, because we now have subclasses of
>Symbol.
>> But removing line 4 is not the right solution. See Nicolas'
>implementation
>> in Squeak:
>> 
>> Symbol>>= aSymbol
>>  "Compare the receiver and aSymbol." 
>>  self == aSymbol ifTrue: [^ true].
>>  aSymbol isSymbol ifTrue: [^ false].
>>  "Use String comparison otherwise"
>>  ^ super = aSymbol
>> 
>> Dave
>> 
>>> 
>>> Symbols are by definition always #== so in that sense, #= should not
>even be implemented (as #= on Object is defined as #==), but since its
>direct super class String already overwrote #=, it has to follow.
>>> 
>>> The super call in line 6 is what allows Symbols and String to be
>compared.
>>> 
>>> I would say line 4 is a kind of sanity check, but probably not
>needed.

Re: [Pharo-users] Documentation on Traits

[Steffen Märcker]

Maybe I missed that part: Can conflicts with slots occur? The section on 
conflicts only mentions methods as cause.

Do you have a pointer to a slots documentation?


Am 9. Januar 2019 20:32:51 MEZ schrieb "Cyril Ferlicot D." 
:
>Le 09/01/2019 à 18:49, Steffen Märcker a écrit :
>> Nice. Do you know where to find details on stateful traits and slots?
>I
>> am familiar with stateless traits and wonder how state is
>incoeporated
>> and how conflicts are handled.
>> 
>
>The guide I send cover the user documentation of Stateful traits and
>how
>to handle conflict.
>
>What it does not cover are Slots (that are independents from Traits)
>and
>implementation documentation.
>
>> Best, Steffen
>> 
>
>
>-- 
>Cyril Ferlicot
>https://ferlicot.fr

Re: [Pharo-users] Documentation on Traits

[Steffen Märcker]

Nice. Do you know where to find details on stateful traits and slots? I am 
familiar with stateless traits and wonder how state is incoeporated and how 
conflicts are handled.

Best, Steffen

Am 9. Januar 2019 15:21:09 MEZ schrieb Konrad Hinsen 
:
>Cyril Ferlicot  writes:
>
>> There is documentation on Traits here:
>>
>https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Traits.md
>
>Great, thanks!
>
>Konrad.

Re: [Pharo-users] Updating singletons

[Steffen Märcker]

Hi Konrad,

sorry, I might have misread your question such that it was about updating  
references to an obsolete object.


However, there is another fun possibility to figure out that a change  
happened that does not involve configuration - though, a bit hacky. ;-)  
You could write the accessor method such that it recompiles itself with  
the first access after loading new code. For example:



Singleton>>uniqueInstance
 instance := self class new.
 self class compile: 'uniqueInstance ^instance'.
 ^instance


Best, Steffen


Am .01.2019, 18:04 Uhr, schrieb Konrad Hinsen :


Hi Steffen,

Have you considered to yield (an) proxy object(s) instead of the  
actual  > Singleton in uniqueInstance? This way it suffices to update  
the proxy

 > with each update of the code.
I am not sure I understand what you are proposing. My problem is  
figuring out how to change in-memory objects when they become obsolete  
after a code change. So I'd say it doesn't matter much if the object I  
need to change is the singleton or a proxy to it, but maybe I am missing  
something!


Cheers,
   Konrad.

Re: [Pharo-users] Updating singletons

[Steffen Märcker]

Have you considered to yield (an) proxy object(s) instead of the actual 
Singleton in uniqueInstance? This way it suffices to update the proxy with each 
update of the code.

Am 3. Januar 2019 15:36:27 MEZ schrieb Ben Coman :
>On Thu, 3 Jan 2019 at 20:01, Konrad Hinsen via Pharo-users <
>pharo-users@lists.pharo.org> wrote:
>
>> Dear Pharo experts,
>>
>> I am wondering if there is a good way to deal with singleton objects
>> whose value needs to be updated following changes in the code that
>> initializes it.
>>
>> Following the model of many examples in Pharo itself, I have defined
>a
>> singleton class with a uniqueInstance method for accessing (and
>creating
>> if necessary) the single instance, and a method "reset" marked as a
>> script to set the uniqueInstance back to nil when required, i.e.
>after
>> source code changes make the prior value inappropriate.
>>
>> This works very well, as long as I don't forget to do the reset,
>which
>> has already caused me a few hours of debugging time. Worse, suppose
>> someone else is using my project in progress, pulling changes from my
>> GitHub repo once per week. That person cannot know if the latest
>changes
>> require a singleton reset. More importantly, users shouldn't have to
>> know about such internal details at all.
>>
>> So is there a way to do the reset automatically whenever a new
>version
>> of my package is loaded into an image?
>>
>> Thanks in advance,
>>   Konrad.
>>
>
>You might use a Baseline #postLoadDoIt:
>https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md
>
>
>Consider that a person pulling your changes cannot know if you have
>upgraded the library versions of any dependencies,
>so always updating via a Baseline might be a reasonable expectation.
>
>But that doesn't help you while developing within the one image.
>
>cheers -ben

Re: [Pharo-users] (no subject)

[Steffen Märcker via Pharo-users]

--- Begin Message ---
Did you already try to measure the impaired overhead of a wrapper  
solution? It might very well be negligible in an otherwise purely symbolic  
computation.


A hybrid solution might be - instead of wrapping each value - to add a  
single method to the value classes that wraps a value on the fly if  
needed, e.g.


Integer>>asExpression
  ^ExpressionWrapper wrap: self.

If the expression protocol is invoked only rarely on the pure values, this  
solution reduces the overhead while keeping the value classes clean of  
foreign methods.


Another option might be to build a trait that adds the behavior to the  
value classes.


Best, Steffen

Am .12.2018, 09:29 Uhr, schrieb Konrad Hinsen :


Richard Sargent  writes:

I understand your desire to utilize the existing Smalltalk mechanisms.  
But,

I think the most important thing is modelling consistency.

What are the behaviours you expect from Expression, SumExpression, and
ProductExpression? Do they know their parent expression? Their children?
Other things?


I certainly agree that this should be the main consideration, but in my
case that's done. Each Expression subclass stored its own specific
information, which for leaf nodes such as integer expressions is really
just a value. All I need is integers with added behavior.


I think that, in general, you will benefit from fully and consistently
modelling the parse tree.


I should have mentioned that my Expressions are not parse trees. They
are used as values in symbolic computation. They are constructed and
deconstructed all the time, which is one reason I want to eliminate
overhead, the other reason being clarity of code.

Konrad.





--- End Message ---

Re: [Pharo-users] [ANN] PetitParser (1) has been migrated to Github

[Steffen Märcker]

Great, thanks a lot!

Steffen

Am .12.2018, 10:22 Uhr, schrieb Julien :


Hello,

I just finished the migration of PetitParser (1) on Github:  
https://github.com/moosetechnology/PetitParser  
 .


I created a release v1.9.2 which mirrors latest release of Smalltalkhub.

Cheers,

Julien

---
Julien Delplanque
Doctorant à l’Université de Lille
http://juliendelplanque.be/phd.html
Equipe Rmod, Inria
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40

Re: [Pharo-users] Playing with Pharo 7

[Steffen Märcker]

Great!

Am .11.2018, 21:47 Uhr, schrieb Cyril Ferlicot D.  
:



Le 26/11/2018 à 16:57, Konrad Hinsen a écrit :


Thanks for the pointer! Unfortunately all the documentation there
assumes way more familiarity with Smalltalk than I have. And even a lot
of familiarity with Metacello itself, as the documentation only explains
the latest functionality.

The good news is that it refers to "Deep into Pharo", so I will download
that book and see if answers my questions.

Konrad.



Hello,

There is also a recent guide here:
https://github.com/pharo-tips-and-tricks/pharo-tips-and-tricks/blob/master/General/Baselines.md

I don't know if it is more beginner friendly. Feedback is welcome.

Re: [Pharo-users] VW2Pharo ? (Was: Pharo2VW (Was:[vwnc] Parsing in Smalltalk))

[Steffen Märcker]

Please let me know if I can help with that porting tool! Btw, is it RDF  
like Resource Description Framework?


Dreamer mode: It would be awesome to teach VW tonel and Git for export and  
versioning!


Best, Steffen

Am .11.2018, 11:37 Uhr, schrieb Christian Haider  
:



Hi,


I did a tool for porting PDFtalk from VW to Gemstone (bundle {Gemstone  
Fileout Project}) .


When I have time, I plan to extend it for Pharo in order to port RDF  
(and Values).


I am thinking of making Pharo my RDF engine… we’ll see…


Happy hacking,

Christian


Von: Cédrick Béler 
Gesendet: Mittwoch, 14. November 2018 21:23
An: Any question about pharo is welcome 
Cc: Christian Haider ;  
Christian Haider 

Betreff: VW2Pharo ? (Was: Pharo2VW (Was:[vwnc] Parsing in Smalltalk))



Objet: Rép : [Pharo-users] Pharo2VW (Was:[vwnc] Parsing in Smalltalk)


I really like the tool as it makes cross-platform-life a lot easier.


Thanks :-)




I really wish there was a similar tool for the reverse direction, too!


That is interesting. Anyone else interested in such a tool?



A tool to port from VW to Pharo ?


Me interested, at least to port Christian work on RDF :)


Cheers,


Cédrick









Cheers,
Alexandre






Cheers! Steffen

Am .10.2018, 22:38 Uhr, schrieb Alexandre Bergel via Pharo-users  
mailto:pharo-users@lists.pharo.org> >:





Thanks Steffen for your contribution to Pharo2VW.
We reviewed and accepted your PullRequests.

Alexandre




On Oct 19, 2018, at 6:29 AM, Steffen Märcker <mailto:merk...@web.de> > wrote:


Nevermind, I figured it out easily. Must been blind before.

Many thanks to the Iceberg team, the tool works like a charm in 6.1!


Am .10.2018, 10:58 Uhr, schrieb Steffen Märcker <mailto:merk...@web.de> >:


<---Schnitt--->

[Pharo-users] [ANN] PEG Grammar, Compiler and Parser for PetitParser2

[Steffen Märcker]

Hi,

I've just published a small tool that helped me prototyping grammars.

PP2PEGGrammar - the original PEG ASCII syntax
PP2PEGParserParser - parse a PEG and build a parser object
PP2PEGParserCompiler - compile a PEG to methods and variables in a given  
parser class


It is available as PetitParser2-PEG in the PublicStore (VW) and on GitHub  
(https://github.com/merkste/petitparser2/tree/PEG).


Best, Steffen


Am .10.2018, 22:46 Uhr, schrieb Steffen Märcker :

I gave Xtreams-Parsing and PetitParser a shot and like to share my  
findings.[*]


The task was to parse the modelling language of the probabilistic model  
checker PRISM. I've written a grammer of about 130 definitions in the  
Xtreams DSL, which is close to Bryan Fords syntax. To avoid doing it all  
again with PetitParser, I wrote a PetitParserGenerator that takes the  
DSL and builds a PetitParser.


The numbers below are just parsing times, no further actions involved.  
For reference I show the times from PRISM (which uses JavaCC), too --  
although they involve additional verification and normalization steps on  
the AST.


input  PrismXP   PP 
230kB14s9s   2s
544kB   121s   20s   5s
1.1MB   421s   34s   8s
1.4MB  1091s   47s  12s
2.2MB  63s  16s
2.9MB  81s  20s
3.8MB 107s  25s
4.4MB 123s  30s

Please note that these times are not representative at all. It's just a  
single example and I put zero effort in optimization. However, I am  
quite satisfied with the results.


[*] I was already familiar with the DSL of Xtreams-Parsing, which I like  
very much. I did not consider SmaCC, as I find PEGs easier to use.


Best, Steffen



Am .10.2018, 20:14 Uhr, schrieb Steffen Märcker :


Dear all,

I have two questions regarding parsing frameworks.

1) Do you have any insights on the performance of SmaCC VS Xtreams  
Parsing VS PetitParser?
2) Has anybody started to port PetitParser 2 from Pharo to VW? Is it  
worth the effort?


Sorry for cross-posting, I thought this might interest both communities.

Cheers, Steffen

Re: [Pharo-users] Pharo2VW (Was:[vwnc] Parsing in Smalltalk)

[Steffen Märcker]

You're welcome. =) I really like the tool as it makes cross-platform-life  
a lot easier. I really wish there was a similar tool for the reverse  
direction, too!


Cheers! Steffen

Am .10.2018, 22:38 Uhr, schrieb Alexandre Bergel via Pharo-users  
:



Thanks Steffen for your contribution to Pharo2VW.
We reviewed and accepted your PullRequests.

Alexandre


On Oct 19, 2018, at 6:29 AM, Steffen Märcker  wrote:

Nevermind, I figured it out easily. Must been blind before.

Many thanks to the Iceberg team, the tool works like a charm in 6.1!


Am .10.2018, 10:58 Uhr, schrieb Steffen Märcker :


<---Schnitt--->

[Pharo-users] [ANN] PetitParser2 for VisualWorks (Was: [vwnc] Parsing in Smalltalk)

[Steffen Märcker]

Hi,

I am happy to announce that I've just finished an initial port of (the  
impressive) PetitParser2 (https://github.com/kursjan/petitparser2) to  
VisualWorks. It is available in the Public Store. The port consists of 4  
bundles:

* PetitParser2
* PetitParser2-Tests
* PetitParser2-Smalltalk (defunct, test support only)
* PetitParser2-Validation (defunct, test support only)

I'd be happy to hear your comments.

Cheers,
Steffen

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

Hi,

my current shot is to subclass IdentityDictionary with  
NildentityDictionary. The class checks on indexed access whether the key  
is nil. If so, storing/retrival uses a singleton Object as key (stored in  
instance variable NIL := Object new). I needed to override at least:


  >>at:ifAbsent:
  >>associationsAt:ifAbsent:
  >>at:put:
  >>findElementLike:ifAbsent:
  >>initialize
  class>>new
  class>>new:

It works for PP2 (without serious performance impact so far), although the  
class is yet incomplete wrt. Collection/Dictionary protocol.


Currently, all but the Morphic-related tests are green. \o/ After some  
cleanup of the bundles, I'll publish an inital version to the Public Store.


@James: If you like, I we could discuss our ports later to double-check an  
making the future process easier. How about that?

@Jan: I'd be happy to hear your thoughts on the porting matter.

Best, Steffen



Am .10.2018, 16:06 Uhr, schrieb James Foster :

We will have the same issue porting PP2 to GemStone and look forward to  
suggestions.



On Oct 22, 2018, at 4:40 AM, Steffen Märcker  wrote:

Hi Jan,

I am trying to port PP2 to VW and managed to get most of the tests  
green. =) Some of the remaining test failures occur in


PP2DebuggingStrategy>>cacheIfNeeded:debugResult:

where a result of nil is to be stored in an IdentityDictionary. But in  
VW Dictionaries do not accept nil as a key. If this is indeed intended,  
I wonder how to circumvent the limitation best. Would it be feasible to  
use a placeholder object instead of nil (which code would be effected)?  
Or would it be better to not cache nil at all?


I'd be happy to hear your thoughts.

Best, Steffen





Am .10.2018, 20:58 Uhr, schrieb Jan Kurš :

I run PP2 on travis [1], seems Pharo 6.1 loads all configurations,  
both on
linux and mac. Pharo 5, Pharo 6.0 got broken, why is build  
configuration so
hard :'( I don't know, how can I support you. I myself had to gave up  
on

some tools, because I failed to load them.

There is no specific reason to use SmallInteger maxVal...  and nobody  
ever

thought it might be too little. 'PP2 min: X' fails if there are less
repetitions that X. 'PP2 max: X' parses at most X repetitions.

($a asPParser min: 2 max: 3) parse: 'a'. -> Failure
($a asPParser min: 2 max: 3) parse: 'aa'.  #($a $a)
($a asPParser min: 2 max: 3) parse: 'aaa'. #($a $a $a)
($a asPParser min: 2 max: 3) parse: ''. #($a $a $a)


Use $- asPParser for characters, e.g:
$- asPParser parse: '-'

[1]: https://travis-ci.org/kursjan/petitparser2/builds/438358467

On Thu, Oct 11, 2018 at 8:13 PM Steffen Märcker  wrote:


Reading the code of PetitParser, I wonder why PPRepeatingParser
initializes 'max' with SmallInteger maxVal instead of some notion of
infinity, like Float infinity (and PP2RepeatingNode as well). If I
understand the code correctly, PParser>>min: fails if the number of
repetitions exceeds SmallInteger maxVal, doesn't it?

Best, Steffen


Am .10.2018, 17:10 Uhr, schrieb Steffen Märcker :

> I am using MacOS 10.13.6 and the 32bit VM:
>
> Pharo 6.0
> Latest update: #60546
>
> ... the String in about is wrong, it should be 6.1. I installed it  
via
> the launcher as "Official Distribution: Pharo 6.1 - 32Bit (stable)"  
I
> just noticed, that the sources file is missing from  
vms/private/6521/,

> too.
>
> Am .10.2018, 17:02 Uhr, schrieb Sean P. DeNigris  

>:
>
>> Steffen Märcker wrote
>>> I did the following:
>>> 1)  Download and start Pharo 6.1 stable via the launcher.
>>> 2b) Attempt to install PP2 via the scripts from GitHub:
>>>  Metacello new
>>>  baseline: 'PetitParser2';
>>>  repository: 'github://kursjan/petitparser2';
>>>  load.
>>>  Metacello new
>>>  baseline: 'PetitParser2Gui';
>>>  repository: 'github://kursjan/petitparser2';
>>>  load.
>>
>> This way worked for me in Pharo #60546 (check in
World->System->About).
>> What
>> exact Pharo version/OS are you on? 32 or 64-bit
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from:  
http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

>>
>
>

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

Hi Jan,

I am trying to port PP2 to VW and managed to get most of the tests green.  
=) Some of the remaining test failures occur in


PP2DebuggingStrategy>>cacheIfNeeded:debugResult:

where a result of nil is to be stored in an IdentityDictionary. But in VW  
Dictionaries do not accept nil as a key. If this is indeed intended, I  
wonder how to circumvent the limitation best. Would it be feasible to use  
a placeholder object instead of nil (which code would be effected)? Or  
would it be better to not cache nil at all?


I'd be happy to hear your thoughts.

Best, Steffen





Am .10.2018, 20:58 Uhr, schrieb Jan Kurš :

I run PP2 on travis [1], seems Pharo 6.1 loads all configurations, both  
on
linux and mac. Pharo 5, Pharo 6.0 got broken, why is build configuration  
so

hard :'( I don't know, how can I support you. I myself had to gave up on
some tools, because I failed to load them.

There is no specific reason to use SmallInteger maxVal...  and nobody  
ever

thought it might be too little. 'PP2 min: X' fails if there are less
repetitions that X. 'PP2 max: X' parses at most X repetitions.

($a asPParser min: 2 max: 3) parse: 'a'. -> Failure
($a asPParser min: 2 max: 3) parse: 'aa'.  #($a $a)
($a asPParser min: 2 max: 3) parse: 'aaa'. #($a $a $a)
($a asPParser min: 2 max: 3) parse: ''. #($a $a $a)


Use $- asPParser for characters, e.g:
$- asPParser parse: '-'

[1]: https://travis-ci.org/kursjan/petitparser2/builds/438358467

On Thu, Oct 11, 2018 at 8:13 PM Steffen Märcker  wrote:


Reading the code of PetitParser, I wonder why PPRepeatingParser
initializes 'max' with SmallInteger maxVal instead of some notion of
infinity, like Float infinity (and PP2RepeatingNode as well). If I
understand the code correctly, PParser>>min: fails if the number of
repetitions exceeds SmallInteger maxVal, doesn't it?

Best, Steffen


Am .10.2018, 17:10 Uhr, schrieb Steffen Märcker :

> I am using MacOS 10.13.6 and the 32bit VM:
>
> Pharo 6.0
> Latest update: #60546
>
> ... the String in about is wrong, it should be 6.1. I installed it via
> the launcher as "Official Distribution: Pharo 6.1 - 32Bit (stable)" I
> just noticed, that the sources file is missing from vms/private/6521/,
> too.
>
> Am .10.2018, 17:02 Uhr, schrieb Sean P. DeNigris  

>:
>
>> Steffen Märcker wrote
>>> I did the following:
>>> 1)  Download and start Pharo 6.1 stable via the launcher.
>>> 2b) Attempt to install PP2 via the scripts from GitHub:
>>>  Metacello new
>>>  baseline: 'PetitParser2';
>>>  repository: 'github://kursjan/petitparser2';
>>>  load.
>>>  Metacello new
>>>  baseline: 'PetitParser2Gui';
>>>  repository: 'github://kursjan/petitparser2';
>>>  load.
>>
>> This way worked for me in Pharo #60546 (check in
World->System->About).
>> What
>> exact Pharo version/OS are you on? 32 or 64-bit
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>
>

Re: [Pharo-users] library to chain select:/collect:/ ... via cascade

[Steffen Märcker]

Another important difference is that no intermediate collections are  
built. In contrast, chaining x enumeration statements #select:, #collect:,  
etc. iterates x times over the collection elements and builds x-1  
intermediate collections.


Am .10.2018, 11:59 Uhr, schrieb Steffen Märcker :


Hi,

indeed, transducers provided a way to achieve this, e.g.

#(12 7 'a' nil #(0)) pipe
filter: #notNil;
filter: #isNumber;
map: #squared;
filter: #even;
into: OrderedCollection.

But this feature is deprecated, as it was not that useful. The preferred  
way to do this is either:


#(12 7 'a' nil #(0))
	transduce: #notNil filter * #isNumber filter * squared map * #even  
filter

reduce: Set accumulate.

or:

Set <~ #even filter
 <~ #squared map
 <~ #isNumber filter
 <~ #notNil filter
 <~ #(12 7 'a' nil #(0)).

The advantage of the transducer approach is that it decouples  
filtering/mapping/etc. from iteration and aggregation. This facilitates  
reuse and makes it trivial to provide all operations to new custom data  
types.


However, I didn't have time to finish the Pharo port of Transducers,  
yet. Hence, the a current version is available in Cincom's Public Store  
or (most current) directly from me only. But if you are interested and  
have a nice use case, I'd be happy to help out.


Best, Steffen


Am .10.2018, 08:45 Uhr, schrieb Julien :


I think this was the idea of Transducers as well.

Julien

---
Julien Delplanque
Doctorant à l’Université de Lille
http://juliendelplanque.be/phd.html
Equipe Rmod, Inria
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40


<---Schnitt--->

Re: [Pharo-users] library to chain select:/collect:/ ... via cascade

[Steffen Märcker]

Hi,

indeed, transducers provided a way to achieve this, e.g.

#(12 7 'a' nil #(0)) pipe
filter: #notNil;
filter: #isNumber;
map: #squared;
filter: #even;
into: OrderedCollection.

But this feature is deprecated, as it was not that useful. The preferred  
way to do this is either:


#(12 7 'a' nil #(0))
transduce: #notNil filter * #isNumber filter * squared map * #even 
filter
reduce: Set accumulate.

or:

Set <~ #even filter
<~ #squared map
<~ #isNumber filter
<~ #notNil filter
<~ #(12 7 'a' nil #(0)).

The advantage of the transducer approach is that it decouples  
filtering/mapping/etc. from iteration and aggregation. This facilitates  
reuse and makes it trivial to provide all operations to new custom data  
types.


However, I didn't have time to finish the Pharo port of Transducers, yet.  
Hence, the a current version is available in Cincom's Public Store or  
(most current) directly from me only. But if you are interested and have a  
nice use case, I'd be happy to help out.


Best, Steffen


Am .10.2018, 08:45 Uhr, schrieb Julien :


I think this was the idea of Transducers as well.

Julien

---
Julien Delplanque
Doctorant à l’Université de Lille
http://juliendelplanque.be/phd.html
Equipe Rmod, Inria
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40


Le 17 oct. 2018 à 09:13, Peter Uhnak  a écrit :

Hi,

is there some library that will allow me to chain select:/collect:/...  
via cascade?


E.g.

#(12 7 'a' nil #(0)) query reject: #isNil; select: #isNumber; collect:  
#squared; select: #even?


The point is to not have to write billion parentheses when building a  
more complex query.


I imagine this would be pretty easy to write, but figured I ask first.

Thanks,
Peter

Re: [Pharo-users] Pharo2VW (Was:[vwnc] Parsing in Smalltalk)

[Steffen Märcker]

Nevermind, I figured it out easily. Must been blind before.

Many thanks to the Iceberg team, the tool works like a charm in 6.1!


Am .10.2018, 10:58 Uhr, schrieb Steffen Märcker :


Hi,

I tried the tool yesterday and found some hickups. After opening issues  
on GitHub, I wonder how I can easily contribute a PR there. I imagine  
there is a straight-forward way with Iceberg now, isn't it? I a sorry if  
I miss the obvious but I am still not familiar with Pharos comprehensive  
tool set.


Best, Steffen


Am .10.2018, 18:06 Uhr, schrieb milton mamani :


Hi you can use

https://github.com/ObjectProfile/Pharo2VW

Cheers, Milton

El sáb., 13 oct. 2018 a las 12:38, Steffen Märcker ()
escribió:


Hi,

I gave PetitParser 2 a try and I am pretty impressed by the results,
please see the updated table below. =) Again, that's pure parsing and
Array-based AST-building. Moving to PP2 was indeed as easy as sending
#asPParser and working around character ranges ($a - $z). Is there a
preferred way to do the latter?

Jan mentioned that there might be an automated tool to port stuff to
VisualWorks. Do you have a name? And again the old question: what is  
the
preferred workflow to exchange code between the two dialects? Till now  
I

stick to FileOut30.

input  PrismStorm  Xtreams.PEG  PP PP2
size   parse check  check  parse cache  parse  parse optim
230kB   0.1s   10s 6s 9s3s 2s 4s  0.2s
544kB   0.2s   90s20s20s7s 5s 9s  0.5s
1.1MB   0.4s  392s46s34s   13s 8s15s  1.0s
1.4MB   0.8s 1091s85s47s   20s12s20s  1.3s
2.2MB63s   30s16s27s  1.9s
2.9MB81s   44s20s34s  2.5s
3.8MB   107s   61s25s45s  3.1s
4.4MB   123s   76s30s56s  3.7s

Best, Steffen


Am .10.2018, 05:22 Uhr, schrieb Tudor Girba :

> Hi,
>
> Interesting experiment. Thanks for sharing!
>
> I assume that you tried the original PetitParser. PetitParser2 offers
> the possibility to optimize the parser (kind of a compilation), and
this
> provides a significant speedup:
> https://github.com/kursjan/petitparser2
>
> Would you be interested in trying this out?
>
> Cheers,
> Doru
>
>
>
>> On Oct 4, 2018, at 10:46 PM, Steffen Märcker  wrote:
>>
>> I gave Xtreams-Parsing and PetitParser a shot and like to share my
>> findings.[*]
>>
>> The task was to parse the modelling language of the probabilistic
model
>> checker PRISM. I've written a grammer of about 130 definitions in  
the

>> Xtreams DSL, which is close to Bryan Fords syntax. To avoid doing it
>> all again with PetitParser, I wrote a PetitParserGenerator that  
takes

>> the DSL and builds a PetitParser.
>>
>> The numbers below are just parsing times, no further actions  
involved.
>> For reference I show the times from PRISM (which uses JavaCC), too  
--
>> although they involve additional verification and normalization  
steps

>> on the AST.
>>
>> input  PrismXP   PP
>> 230kB14s9s   2s
>> 544kB121s   20s   5s
>> 1.1MB421s   34s   8s
>> 1.4MB  1091s   47s  12s
>> 2.2MB  63s  16s
>> 2.9MB  81s  20s
>> 3.8MB 107s  25s
>> 4.4MB 123s  30s
>>
>> Please note that these times are not representative at all. It's  
just

a
>> single example and I put zero effort in optimization. However, I am
>> quite satisfied with the results.
>>
>> [*] I was already familiar with the DSL of Xtreams-Parsing, which I
>> like very much. I did not consider SmaCC, as I find PEGs easier to  
use.

>>
>> Best, Steffen
>>
>>
>>
>> Am .10.2018, 20:14 Uhr, schrieb Steffen Märcker :
>>
>>> Dear all,
>>>
>>> I have two questions regarding parsing frameworks.
>>>
>>> 1) Do you have any insights on the performance of SmaCC VS Xtreams
>>> Parsing VS PetitParser?
>>> 2) Has anybody started to port PetitParser 2 from Pharo to VW? Is  
it

>>> worth the effort?
>>>
>>> Sorry for cross-posting, I thought this might interest both
>>> communities.
>>>
>>> Cheers, Steffen
>
> --
> www.feenk.com
>
> "No matter how many recipes we know, we still value a chef."
>
>
>
>
>
>
>

[Pharo-users] Pharo2VW (Was:[vwnc] Parsing in Smalltalk)

[Steffen Märcker]

Hi,

I tried the tool yesterday and found some hickups. After opening issues on  
GitHub, I wonder how I can easily contribute a PR there. I imagine there  
is a straight-forward way with Iceberg now, isn't it? I a sorry if I miss  
the obvious but I am still not familiar with Pharos comprehensive tool set.


Best, Steffen


Am .10.2018, 18:06 Uhr, schrieb milton mamani :


Hi you can use

https://github.com/ObjectProfile/Pharo2VW

Cheers, Milton

El sáb., 13 oct. 2018 a las 12:38, Steffen Märcker ()
escribió:


Hi,

I gave PetitParser 2 a try and I am pretty impressed by the results,
please see the updated table below. =) Again, that's pure parsing and
Array-based AST-building. Moving to PP2 was indeed as easy as sending
#asPParser and working around character ranges ($a - $z). Is there a
preferred way to do the latter?

Jan mentioned that there might be an automated tool to port stuff to
VisualWorks. Do you have a name? And again the old question: what is the
preferred workflow to exchange code between the two dialects? Till now I
stick to FileOut30.

input  PrismStorm  Xtreams.PEG  PP PP2
size   parse check  check  parse cache  parse  parse optim
230kB   0.1s   10s 6s 9s3s 2s 4s  0.2s
544kB   0.2s   90s20s20s7s 5s 9s  0.5s
1.1MB   0.4s  392s46s34s   13s 8s15s  1.0s
1.4MB   0.8s 1091s85s47s   20s12s20s  1.3s
2.2MB63s   30s16s27s  1.9s
2.9MB81s   44s20s34s  2.5s
3.8MB   107s   61s25s45s  3.1s
4.4MB   123s   76s30s56s  3.7s

Best, Steffen


Am .10.2018, 05:22 Uhr, schrieb Tudor Girba :

> Hi,
>
> Interesting experiment. Thanks for sharing!
>
> I assume that you tried the original PetitParser. PetitParser2 offers
> the possibility to optimize the parser (kind of a compilation), and
this
> provides a significant speedup:
> https://github.com/kursjan/petitparser2
>
> Would you be interested in trying this out?
>
> Cheers,
> Doru
>
>
>
>> On Oct 4, 2018, at 10:46 PM, Steffen Märcker  wrote:
>>
>> I gave Xtreams-Parsing and PetitParser a shot and like to share my
>> findings.[*]
>>
>> The task was to parse the modelling language of the probabilistic
model
>> checker PRISM. I've written a grammer of about 130 definitions in the
>> Xtreams DSL, which is close to Bryan Fords syntax. To avoid doing it
>> all again with PetitParser, I wrote a PetitParserGenerator that takes
>> the DSL and builds a PetitParser.
>>
>> The numbers below are just parsing times, no further actions  
involved.

>> For reference I show the times from PRISM (which uses JavaCC), too --
>> although they involve additional verification and normalization steps
>> on the AST.
>>
>> input  PrismXP   PP
>> 230kB14s9s   2s
>> 544kB121s   20s   5s
>> 1.1MB421s   34s   8s
>> 1.4MB  1091s   47s  12s
>> 2.2MB  63s  16s
>> 2.9MB  81s  20s
>> 3.8MB 107s  25s
>> 4.4MB 123s  30s
>>
>> Please note that these times are not representative at all. It's just
a
>> single example and I put zero effort in optimization. However, I am
>> quite satisfied with the results.
>>
>> [*] I was already familiar with the DSL of Xtreams-Parsing, which I
>> like very much. I did not consider SmaCC, as I find PEGs easier to  
use.

>>
>> Best, Steffen
>>
>>
>>
>> Am .10.2018, 20:14 Uhr, schrieb Steffen Märcker :
>>
>>> Dear all,
>>>
>>> I have two questions regarding parsing frameworks.
>>>
>>> 1) Do you have any insights on the performance of SmaCC VS Xtreams
>>> Parsing VS PetitParser?
>>> 2) Has anybody started to port PetitParser 2 from Pharo to VW? Is it
>>> worth the effort?
>>>
>>> Sorry for cross-posting, I thought this might interest both
>>> communities.
>>>
>>> Cheers, Steffen
>
> --
> www.feenk.com
>
> "No matter how many recipes we know, we still value a chef."
>
>
>
>
>
>
>

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

Hi,

I gave PetitParser 2 a try and I am pretty impressed by the results,  
please see the updated table below. =) Again, that's pure parsing and  
Array-based AST-building. Moving to PP2 was indeed as easy as sending  
#asPParser and working around character ranges ($a - $z). Is there a  
preferred way to do the latter?


Jan mentioned that there might be an automated tool to port stuff to  
VisualWorks. Do you have a name? And again the old question: what is the  
preferred workflow to exchange code between the two dialects? Till now I  
stick to FileOut30.


input  PrismStorm  Xtreams.PEG  PP PP2
size   parse check  check  parse cache  parse  parse optim
230kB   0.1s   10s 6s 9s3s 2s 4s  0.2s
544kB   0.2s   90s20s20s7s 5s 9s  0.5s
1.1MB   0.4s  392s46s34s   13s 8s15s  1.0s
1.4MB   0.8s 1091s85s47s   20s12s20s  1.3s
2.2MB63s   30s16s27s  1.9s
2.9MB81s   44s20s34s  2.5s
3.8MB   107s   61s25s45s  3.1s
4.4MB   123s   76s30s56s  3.7s

Best, Steffen


Am .10.2018, 05:22 Uhr, schrieb Tudor Girba :


Hi,

Interesting experiment. Thanks for sharing!

I assume that you tried the original PetitParser. PetitParser2 offers  
the possibility to optimize the parser (kind of a compilation), and this  
provides a significant speedup:

https://github.com/kursjan/petitparser2

Would you be interested in trying this out?

Cheers,
Doru




On Oct 4, 2018, at 10:46 PM, Steffen Märcker  wrote:

I gave Xtreams-Parsing and PetitParser a shot and like to share my  
findings.[*]


The task was to parse the modelling language of the probabilistic model  
checker PRISM. I've written a grammer of about 130 definitions in the  
Xtreams DSL, which is close to Bryan Fords syntax. To avoid doing it  
all again with PetitParser, I wrote a PetitParserGenerator that takes  
the DSL and builds a PetitParser.


The numbers below are just parsing times, no further actions involved.  
For reference I show the times from PRISM (which uses JavaCC), too --  
although they involve additional verification and normalization steps  
on the AST.


input  PrismXP   PP 
230kB14s9s   2s
544kB   121s   20s   5s
1.1MB   421s   34s   8s
1.4MB  1091s   47s  12s
2.2MB  63s  16s
2.9MB  81s  20s
3.8MB 107s  25s
4.4MB 123s  30s

Please note that these times are not representative at all. It's just a  
single example and I put zero effort in optimization. However, I am  
quite satisfied with the results.


[*] I was already familiar with the DSL of Xtreams-Parsing, which I  
like very much. I did not consider SmaCC, as I find PEGs easier to use.


Best, Steffen



Am .10.2018, 20:14 Uhr, schrieb Steffen Märcker :


Dear all,

I have two questions regarding parsing frameworks.

1) Do you have any insights on the performance of SmaCC VS Xtreams  
Parsing VS PetitParser?
2) Has anybody started to port PetitParser 2 from Pharo to VW? Is it  
worth the effort?


Sorry for cross-posting, I thought this might interest both  
communities.


Cheers, Steffen


--
www.feenk.com

"No matter how many recipes we know, we still value a chef."

Re: [Pharo-users] Persistant Taskbar Previews

[Steffen Märcker]

Thanks both of you. It turned out to be not a second UI process but simply  
some orphan morphs. I got rid of them using alt-shift. I was just not  
aware of bringing up the halos. =)


Am .10.2018, 10:48 Uhr, schrieb Sven Van Caekenberghe :

I would guess you have 2 instances of the Morphic UI process, probably  
left over from some debugging. Kill one using the Process Browser. But  
this is just a blind guess.



On 13 Oct 2018, at 04:51, Ben Coman  wrote:



On Fri, 12 Oct 2018 at 18:57, Steffen Märcker  wrote:
Hi,

Using Pharo 6.1 for some hours, I ended up with quite a few previews  
from

(long gone) taskbar entries that refuse to go away. They seem to be
PanelMorphs. How do I get rid of them?

Best, Steffen

I'd guess like any morph you could meta-click on them and choose to  
delete them.

e.g. on Windows SHIFT-ALT-middleClick

cheers -ben

[Pharo-users] Persistant Taskbar Previews

[Steffen Märcker]

Hi,

Using Pharo 6.1 for some hours, I ended up with quite a few previews from  
(long gone) taskbar entries that refuse to go away. They seem to be  
PanelMorphs. How do I get rid of them?


Best, Steffen

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

Hi, I tried it some more times and things are different now:
- image appeared to lock up (1st)
- no network traffic at all (2nd)
- image unresponsive, loading successful after 2 minutes (3rd)
Call me a fool, but I didn't do anything different. Notably, it succeeded  
each time in 7.0. =)


There is no specific reason to use SmallInteger maxVal...  and nobody  
ever thought it might be too little.


Maybe it makes sense to change this? It appears to be just wrong and on  
32bit the limit is well in practical reach. With a little guidance, I'd  
try to do a first PR myself (if the change is considered sensible).


I was mentioning #min: since it is implemented in terms of 'min: min max:  
SmallInteber maxVal'.


Is there an easy way to create a character class, similar to [1-2x-z]?

Best, Steffen




Use $- asPParser for characters, e.g:
$- asPParser parse: '-'

[1]: https://travis-ci.org/kursjan/petitparser2/builds/438358467

On Thu, Oct 11, 2018 at 8:13 PM Steffen Märcker  wrote:


Reading the code of PetitParser, I wonder why PPRepeatingParser
initializes 'max' with SmallInteger maxVal instead of some notion of
infinity, like Float infinity (and PP2RepeatingNode as well). If I
understand the code correctly, PParser>>min: fails if the number of
repetitions exceeds SmallInteger maxVal, doesn't it?

Best, Steffen


Am .10.2018, 17:10 Uhr, schrieb Steffen Märcker :

> I am using MacOS 10.13.6 and the 32bit VM:
>
> Pharo 6.0
> Latest update: #60546
>
> ... the String in about is wrong, it should be 6.1. I installed it via
> the launcher as "Official Distribution: Pharo 6.1 - 32Bit (stable)" I
> just noticed, that the sources file is missing from vms/private/6521/,
> too.
>
> Am .10.2018, 17:02 Uhr, schrieb Sean P. DeNigris  

>:
>
>> Steffen Märcker wrote
>>> I did the following:
>>> 1)  Download and start Pharo 6.1 stable via the launcher.
>>> 2b) Attempt to install PP2 via the scripts from GitHub:
>>>  Metacello new
>>>  baseline: 'PetitParser2';
>>>  repository: 'github://kursjan/petitparser2';
>>>  load.
>>>  Metacello new
>>>  baseline: 'PetitParser2Gui';
>>>  repository: 'github://kursjan/petitparser2';
>>>  load.
>>
>> This way worked for me in Pharo #60546 (check in
World->System->About).
>> What
>> exact Pharo version/OS are you on? 32 or 64-bit
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>
>

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

Reading the code of PetitParser, I wonder why PPRepeatingParser  
initializes 'max' with SmallInteger maxVal instead of some notion of  
infinity, like Float infinity (and PP2RepeatingNode as well). If I  
understand the code correctly, PParser>>min: fails if the number of  
repetitions exceeds SmallInteger maxVal, doesn't it?


Best, Steffen


Am .10.2018, 17:10 Uhr, schrieb Steffen Märcker :


I am using MacOS 10.13.6 and the 32bit VM:

Pharo 6.0
Latest update: #60546

... the String in about is wrong, it should be 6.1. I installed it via  
the launcher as "Official Distribution: Pharo 6.1 - 32Bit (stable)" I  
just noticed, that the sources file is missing from vms/private/6521/,  
too.


Am .10.2018, 17:02 Uhr, schrieb Sean P. DeNigris :


Steffen Märcker wrote

I did the following:
1)  Download and start Pharo 6.1 stable via the launcher.
2b) Attempt to install PP2 via the scripts from GitHub:
 Metacello new
 baseline: 'PetitParser2';
 repository: 'github://kursjan/petitparser2';
 load.
 Metacello new
 baseline: 'PetitParser2Gui';
 repository: 'github://kursjan/petitparser2';
 load.


This way worked for me in Pharo #60546 (check in World->System->About).  
What

exact Pharo version/OS are you on? 32 or 64-bit



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

I am using MacOS 10.13.6 and the 32bit VM:

Pharo 6.0
Latest update: #60546

... the String in about is wrong, it should be 6.1. I installed it via the  
launcher as "Official Distribution: Pharo 6.1 - 32Bit (stable)" I just  
noticed, that the sources file is missing from vms/private/6521/, too.


Am .10.2018, 17:02 Uhr, schrieb Sean P. DeNigris :


Steffen Märcker wrote

I did the following:
1)  Download and start Pharo 6.1 stable via the launcher.
2b) Attempt to install PP2 via the scripts from GitHub:
 Metacello new
 baseline: 'PetitParser2';
 repository: 'github://kursjan/petitparser2';
 load.
 Metacello new
 baseline: 'PetitParser2Gui';
 repository: 'github://kursjan/petitparser2';
 load.


This way worked for me in Pharo #60546 (check in World->System->About).  
What

exact Pharo version/OS are you on? 32 or 64-bit



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

Can you give more details? IIRC I have PP2 loaded in several 6.


I did the following:
1)  Download and start Pharo 6.1 stable via the launcher.
2a) Attempt to install PetitParser2 via the CatalogBrowser:
"Information
There was an error while trying to install PetitParser2.
Installation was cancelled."
2b) Attempt to install PP2 via the scripts from GitHub:
Metacello new
baseline: 'PetitParser2';
repository: 'github://kursjan/petitparser2';
load.
Metacello new
baseline: 'PetitParser2Gui';
repository: 'github://kursjan/petitparser2';
load.
"Could not resolve: [BaselineOfPetitParser2] in [...]"

Interestingly, it works in Pharo 7 dev, but there the GUI-Tools won't load  
because of some issues with their dependencies.


I hope this helps. As I am not familiar with Pharo, I'd appreciate any  
hints.


Best, Steffen

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

Dear Jan,

I just tried to use PP2 but ran into two issues:

1. PP2 does not load into Pharo 6.1 stable.
2. I use #- to create character classes but was not able to find the  
equivalent in PP2 yet.



There should be no fundamental issue with porting PP2 to VW. As far as I
know, there is an automated tool to do so, right?


I am not aware of this tool. Can you give me some hints what exactly to  
look for?


Best, Steffen


On the other hand, PP

is
stable and does not change, PP2 is maintained and updated from time to  
time
(mostly adding optimizations), so there might be an overhead of syncing  
PP2

to VW2.

Cheers,
Jan

[1]:
https://kursjan.github.io/petitparser2/pillar-book/build/Chapters/memoization.html

On Fri, Oct 5, 2018, 13:26 Steffen Märcker  wrote:


Hi Doru!

> I assume that you tried the original PetitParser. PetitParser2 offers
> the possibility to optimize the parser (kind of a compilation), and
this
> provides a significant speedup:
> https://github.com/kursjan/petitparser2
>
> Would you be interested in trying this out?

Yes, I'd like to give this a shot, too. However, as far as I know, PP2  
is

only available for Pharo and not VW, is it?

Speaking of optimizations, I also tried to use memoizing the petit
parser.
However, the times got worse instead of better. Is there a rule of thumb
where to apply #memoized in a sensible way? As far as I understand,
applying it to the root parser does not memoize subsequent parsers, does
it?

Kind regards, Steffen

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

Hi Doru!

I assume that you tried the original PetitParser. PetitParser2 offers  
the possibility to optimize the parser (kind of a compilation), and this  
provides a significant speedup:

https://github.com/kursjan/petitparser2

Would you be interested in trying this out?


Yes, I'd like to give this a shot, too. However, as far as I know, PP2 is  
only available for Pharo and not VW, is it?


Speaking of optimizations, I also tried to use memoizing the petit parser.  
However, the times got worse instead of better. Is there a rule of thumb  
where to apply #memoized in a sensible way? As far as I understand,  
applying it to the root parser does not memoize subsequent parsers, does  
it?


Kind regards, Steffen

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

Hi Ben!


Thanks for your report Steffen. Nice to see such comparisons even when a
bit apples & oranges.
Will you be implementing those "additional verification and normalization
steps" ?
It seems they have an exponential or power impact on times.


I certainly will. Meanwhile, I have some more precise numbers. As it turns  
out, it is indeed the additional steps (nobuild) that causes the impact. I  
also added the (nobuild) times from another tool, the probabilistic model  
checker Storm.


input Prism Storm   XPPP
size  parse nobuild nobuild parse parse 
230kB  0.1s 10s  6s9s2s
544kB  0.2s 90s 20s   20s5s
1.1MB  0.4s392s 46s   34s8s
1.4MB  0.8s   1091s 85s   47s   12s
2.2MB 63s   16s
2.9MB 81s   20s
3.8MB107s   25s
4.4MB123s   30s

Best, Steffen

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

[Steffen Märcker]

I gave Xtreams-Parsing and PetitParser a shot and like to share my  
findings.[*]


The task was to parse the modelling language of the probabilistic model  
checker PRISM. I've written a grammer of about 130 definitions in the  
Xtreams DSL, which is close to Bryan Fords syntax. To avoid doing it all  
again with PetitParser, I wrote a PetitParserGenerator that takes the DSL  
and builds a PetitParser.


The numbers below are just parsing times, no further actions involved. For  
reference I show the times from PRISM (which uses JavaCC), too -- although  
they involve additional verification and normalization steps on the AST.


input  PrismXP   PP 
230kB14s9s   2s
544kB   121s   20s   5s
1.1MB   421s   34s   8s
1.4MB  1091s   47s  12s
2.2MB  63s  16s
2.9MB  81s  20s
3.8MB 107s  25s
4.4MB 123s  30s

Please note that these times are not representative at all. It's just a  
single example and I put zero effort in optimization. However, I am quite  
satisfied with the results.


[*] I was already familiar with the DSL of Xtreams-Parsing, which I like  
very much. I did not consider SmaCC, as I find PEGs easier to use.


Best, Steffen



Am .10.2018, 20:14 Uhr, schrieb Steffen Märcker :


Dear all,

I have two questions regarding parsing frameworks.

1) Do you have any insights on the performance of SmaCC VS Xtreams  
Parsing VS PetitParser?
2) Has anybody started to port PetitParser 2 from Pharo to VW? Is it  
worth the effort?


Sorry for cross-posting, I thought this might interest both communities.

Cheers, Steffen

[Pharo-users] Parsing in VW

[Steffen Märcker]

Dear all,

I have two questions regarding parsing frameworks.

1) Do you have any insights on the performance of SmaCC VS Xtreams Parsing  
VS PetitParser?
2) Has anybody started to port PetitParser 2 from Pharo to VW? Is it worth  
the effort?


Sorry for cross-posting, I thought this might interest both communities.

Cheers, Steffen

Re: [Pharo-users] Pharo 7 streams API

[Steffen Märcker]

No worries! =)

Let me clarify the relation between Transducers and function composition.

The main component in the framework are so-called ReducingFunctions, which  
are the operations you want to perform. They are functions that take two  
arguments, an 'intermediate value' and a 'current element', and map them  
to a new intermediate value, i.e.,

rf : A x I -> A.
In the example, #nextPut: is a reducing function, since it takes a stream  
and an element to put to the stream (I assume #nextPut: returns the stream  
itself).


Basic operations like mapping, filtering, partitioning etc. are generic
and independent of streams/collections/whatsoever. Hence, they should be
resuable. This can be achieved by Transducers which are objects that take
a reducing function and transform it to incorporate the additional
functionality, e.g., mapping. The transducers signature is similar to
xf : (A x I -> A) -> (A x I -> A).
The classic approach adds these basic operations by wrapping the data  
(collections/streams). In contrast, transducers add them to the operations.


Function composition of transducer objects chains multiple basic
operations and allows to attach them to a reducing function. In fact, the
implementation indeed uses function composition for this purpose. However,
its up to the context how to make use of these functions, e.g., via
#reduce:init:.

Feel free to ask if anything remains unclear! =)

Best, Steffen


Am .07.2018, 16:20 Uhr, schrieb :


Solutions to different problems.

I proposed a simple generic thing that only composes functions, allowing  
for transformation of block arg.


Transducers seem like streaming, data-flow specific, thing.

Maybe yours helps the original problem in the long run.

I just tried to find something to solve more specific part of it while  
being such generic that it helps in other places as well.


Just pointing it out so there isn't a perception they are competing to  
solve same problem and only one should be selected.


Herby

On July 3, 2018 3:57:21 PM GMT+02:00, "Steffen Märcker"   
wrote:

I think, streams and functional composition match up nicely and
transducers are a way to do this. I've introduced them earlier on this

list. (I hesitated to weight into the discussion, as I won't have time
to
work on the Pharo port of Transducers until October.)

Let me give a simplified example. I assume the basic messages are
#nextPut: and #close: to write to aStream and close it.

  aString
transduce: LineEndCrLf flatMap
reduce: (#nextPut: completing: #close)
init: aStream

* Let aString be the source, i.e., some object that yields a sequence
of
characters:
  a CR b
* Let LineEndConventionLF a function that maps CR to #(CR LF):
  a CR b -> a #(CR LF) b
* #flatMap embeds #(CR LF) into the sequence:
  a CR LF b
* (#nextPut: completing: #close) puts each character on the stream and

calls #close at the end:
  aStream
nextPut: $a;
nextPut: CR;
nextPut: LF;
nextPut: $b;
close;
yourself.
* #transduce:reduce:init: actually starts the writing process.

First, (LineEndConventionLF flatMap) is composable with other
transformations, e.g., encoding. The example above would change to:

  aString
transduce: LineEndCrLf flatMap * EncodeUTF8 flatMap
reduce: (#nextPut: completing: #close)
init: aByteStream

LineEndCrLf and EncodeUTF8 only have to know how to process single
characters. Hence, they are highly reusable.

Second, as the source the transformations, the writing process and the

data sink are distinct objects, we can freely interact with them and
build
arbitrary pipelines. It is straight-forward to come up with other
iteration methods than #reduce:init:, e.g., step-wise processing of
streams.

Best, Steffen

Re: [Pharo-users] Pharo 7 streams API

[Steffen Märcker]

No worries! =) Let me clarify the relation between Transducers and
function composition.

The basic component in the framework is the so-called ReducingFunction.
This are functions that take two arguments, an 'intermediate value' and a
'current element', and map them to a new intermediate value, i.e., rf : A
x I -> A.
In the example, #nextPut: is a reducing function, since it takes a stream
and an element to put to the stream (I assume #nextPut: would return the
stream).

Basic operations like mapping, filtering, partitioning etc. are generic
and independent of streams/collections/whatsoever. Hence, they should be
resuable. This can be achieved by Transducers which are objects that take
reducing functions and transform them to incorporate the additional
functionality, e.g., mapping. Their signature is similar to xf : (A x I ->
A) -> (A x I -> A).

Function composition of transducer objects chains multiple basic
operations and allows to attach them to a reducing function. In fact, the
implementation indeed uses function composition for this purpose. However,
its up to the context how to make use of these functions, e.g., via
#reduce:init:.

Feel free to ask if anything remains unclear! =)

Best, Steffen


Am .07.2018, 16:20 Uhr, schrieb :


Solutions to different problems.

I proposed a simple generic thing that only composes functions, allowing  
for transformation of block arg.


Transducers seem like streaming, data-flow specific, thing.

Maybe yours helps the original problem in the long run.

I just tried to find something to solve more specific part of it while  
being such generic that it helps in other places as well.


Just pointing it out so there isn't a perception they are competing to  
solve same problem and only one should be selected.


Herby

On July 3, 2018 3:57:21 PM GMT+02:00, "Steffen Märcker"   
wrote:

I think, streams and functional composition match up nicely and
transducers are a way to do this. I've introduced them earlier on this

list. (I hesitated to weight into the discussion, as I won't have time
to
work on the Pharo port of Transducers until October.)

Let me give a simplified example. I assume the basic messages are
#nextPut: and #close: to write to aStream and close it.

  aString
transduce: LineEndCrLf flatMap
reduce: (#nextPut: completing: #close)
init: aStream

* Let aString be the source, i.e., some object that yields a sequence
of
characters:
  a CR b
* Let LineEndConventionLF a function that maps CR to #(CR LF):
  a CR b -> a #(CR LF) b
* #flatMap embeds #(CR LF) into the sequence:
  a CR LF b
* (#nextPut: completing: #close) puts each character on the stream and

calls #close at the end:
  aStream
nextPut: $a;
nextPut: CR;
nextPut: LF;
nextPut: $b;
close;
yourself.
* #transduce:reduce:init: actually starts the writing process.

First, (LineEndConventionLF flatMap) is composable with other
transformations, e.g., encoding. The example above would change to:

  aString
transduce: LineEndCrLf flatMap * EncodeUTF8 flatMap
reduce: (#nextPut: completing: #close)
init: aByteStream

LineEndCrLf and EncodeUTF8 only have to know how to process single
characters. Hence, they are highly reusable.

Second, as the source the transformations, the writing process and the

data sink are distinct objects, we can freely interact with them and
build
arbitrary pipelines. It is straight-forward to come up with other
iteration methods than #reduce:init:, e.g., step-wise processing of
streams.

Best, Steffen

Re: [Pharo-users] Pharo 7 streams API

[Steffen Märcker]

I think, streams and functional composition match up nicely and  
transducers are a way to do this. I've introduced them earlier on this  
list. (I hesitated to weight into the discussion, as I won't have time to  
work on the Pharo port of Transducers until October.)


Let me give a simplified example. I assume the basic messages are  
#nextPut: and #close: to write to aStream and close it.


  aString
transduce: LineEndCrLf flatMap
reduce: (#nextPut: completing: #close)
init: aStream

* Let aString be the source, i.e., some object that yields a sequence of  
characters:

  a CR b
* Let LineEndConventionLF a function that maps CR to #(CR LF):
  a CR b -> a #(CR LF) b
* #flatMap embeds #(CR LF) into the sequence:
  a CR LF b
* (#nextPut: completing: #close) puts each character on the stream and  
calls #close at the end:

  aStream
nextPut: $a;
nextPut: CR;
nextPut: LF;
nextPut: $b;
close;
yourself.
* #transduce:reduce:init: actually starts the writing process.

First, (LineEndConventionLF flatMap) is composable with other  
transformations, e.g., encoding. The example above would change to:


  aString
transduce: LineEndCrLf flatMap * EncodeUTF8 flatMap
reduce: (#nextPut: completing: #close)
init: aByteStream

LineEndCrLf and EncodeUTF8 only have to know how to process single  
characters. Hence, they are highly reusable.


Second, as the source the transformations, the writing process and the  
data sink are distinct objects, we can freely interact with them and build  
arbitrary pipelines. It is straight-forward to come up with other  
iteration methods than #reduce:init:, e.g., step-wise processing of  
streams.


Best, Steffen

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Steffen Märcker]

Dear Serge,

on the VM mailing list, Levente pointed out, that this could also be  
related to some lib the VM uses (e.g., Freetype) that might change the  
rounding mode. I'll dig into it and give your idea a try and come back  
with the results.


I think it would be nice to have in Pharo 7. But before I want to make  
sure it a) works as expected and b) does not cause some nasty side effects.


Bye, Steffen


Am .05.2018, 12:26 Uhr, schrieb Serge Stinckwich  
:



On Thu, May 24, 2018 at 12:27 PM Steffen Märcker  wrote:


Hi,

now I've observed the same issue. It might be related to context
switching, since introducing a delay has a similar effect. Consider:

   | FE_TONEAREST FE_DOWNWARD FE_UPWARD FE_TOWARDZERO |
   FE_TONEAREST  := 16r.
   FE_DOWNWARD   := 16r0400.
   FE_UPWARD := 16r0800.
   FE_TOWARDZERO := 16r0C00.
   "For some reasons we have to call fegetround once."
   "c := LibC new fegetround."
   LibC new fesetround: FE_DOWNWARD.
   (Delay forSeconds: 1) wait.
   v1 := 1.0/10.0.
   LibC new fesetround: FE_UPWARD.
   v2 := 1.0/10.0.
   LibC new fesetround: FE_TONEAREST.
   v1 < v2.

If the delay is inserted, the script evaluates to false. Using the same
LibC-instance or creating a new one does not seem to change anything
here.
Interestingly, a similar approach in VisualWorks does not show this  
issue

yet.



​Ok, so maybe we need to use put evaluation in a block and use
valueNoContextSwitch ?
​Maybe use an API like the one you propose before :
Double roundToMinusInfWhile: [ ... ]




Actually, I expect the FE_* macros to be platform/implementation
dependent, as suggested here:

http://www.enseignement.polytechnique.fr/informatique/INF478/docs/Cpp/en/c/numeric/fenv/FE_round.html



​Ok.

Can we try to pack everything in a PR for Pharo 7.0 ?
​Thank you.

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Steffen Märcker]

Hi,

now I've observed the same issue. It might be related to context  
switching, since introducing a delay has a similar effect. Consider:


  | FE_TONEAREST FE_DOWNWARD FE_UPWARD FE_TOWARDZERO |
  FE_TONEAREST  := 16r.
  FE_DOWNWARD   := 16r0400.
  FE_UPWARD := 16r0800.
  FE_TOWARDZERO := 16r0C00.
  "For some reasons we have to call fegetround once."
  "c := LibC new fegetround."
  LibC new fesetround: FE_DOWNWARD.
  (Delay forSeconds: 1) wait.
  v1 := 1.0/10.0.
  LibC new fesetround: FE_UPWARD.
  v2 := 1.0/10.0.
  LibC new fesetround: FE_TONEAREST.
  v1 < v2.

If the delay is inserted, the script evaluates to false. Using the same  
LibC-instance or creating a new one does not seem to change anything here.  
Interestingly, a similar approach in VisualWorks does not show this issue  
yet.


Actually, I expect the FE_* macros to be platform/implementation  
dependent, as suggested here:

http://www.enseignement.polytechnique.fr/informatique/INF478/docs/Cpp/en/c/numeric/fenv/FE_round.html

Best, Steffen




Am .05.2018, 11:57 Uhr, schrieb Serge Stinckwich  
<serge.stinckw...@gmail.com>:


What is really strange is when I print the following lines, I obtain  
2048:


current := LibC uniqueInstance fegetround.
LibC uniqueInstance fesetround: 2048.
LibC uniqueInstance fegetround.

and 0 when I remove the first line :
LibC uniqueInstance fesetround: 2048.
LibC uniqueInstance fegetround.



On Thu, May 24, 2018 at 10:37 AM Serge Stinckwich <
serge.stinckw...@gmail.com> wrote:




On Thu, May 24, 2018 at 10:31 AM Steffen Märcker <merk...@web.de> wrote:


I actually made progress: It works like a charm! Basically, I
implemented
the same code as you. Testing is straightforward (using the constant
values from libc):

   current := LibC fegetround.
   LibC fesetround: FE_DOWNWARDS.
   v1 := 1.0/10.0.
   LibC feesetround: FE_UPWARDS.
   v2 := 1.0/10.0.
   LibC feesetround: current.
   v1 < v2. "true"

> ​but apparently nothing happens when you do :
>   LibC uniqueInstance fesetround: 1024.
>   LibC uniqueInstance fegetround.
> always return 0.​

This is expected, since the fesetround function returns 0 only if the
set
operation was successful.



​I was talking about fgetround function.
​ Can you check the value returns by your fegetround function ?​

Constants values are not dependent of the platform ?​

​Can you commit yr code to Pharo 7.0 or if there is no interest for this
to PolyMath ?​
​Thank you.​
--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Steffen Märcker]

I actually made progress: It works like a charm! Basically, I implemented  
the same code as you. Testing is straightforward (using the constant  
values from libc):


  current := LibC fegetround.
  LibC fesetround: FE_DOWNWARDS.
  v1 := 1.0/10.0.
  LibC feesetround: FE_UPWARDS.
  v2 := 1.0/10.0.
  LibC feesetround: current.
  v1 < v2. "true"


​but apparently nothing happens when you do :
  LibC uniqueInstance fesetround: 1024.
  LibC uniqueInstance fegetround.
always return 0.​


This is expected, since the fesetround function returns 0 only if the set  
operation was successful.


Thanks again for your support!

Best,
Steffen