April 2023 - Pharo-users - lists.pharo.org

Re: Collection>>reduce name clash with transducers

by Richard O'Keefe

#reduce: aReduction Are you saying that aReduction is an object from which a dyadic block and an initial value can be derived? That's going to confuse the heck out of Dolphin and Pharo users (like me, for example). And in my copy of Pharo, #reduce: calls #reduceLeft:, not #foldLeft:. The sad thing about #reduceLeft: in Pharo is that in order to provide extra generality I have no use for, 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: <<ident. binop>> 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 <merkste(a)web.de> 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 <merkste(a)web.de> 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_l… >> >> 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#l… >> >> >> On Thu, 13 Apr 2023 at 21:17, Sebastian Jordan Montano < >> sebastian.jordan(a)inria.fr> 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" <merkste(a)web.de> >>> > Ã: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >>> > 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. > >

April 14, 2023

Re: Collection>>reduce name clash with transducers

by 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 <merkste(a)web.de> 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_l… 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#l… On Thu, 13 Apr 2023 at 21:17, Sebastian Jordan Montano <sebastian.jordan(a)inria.fr> 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" <merkste(a)web.de> > Ã: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > 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.

April 13, 2023

Re: Collection>>reduce naming

by 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 <merkste(a)web.de> 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_l… 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#l… On Thu, 13 Apr 2023 at 21:17, Sebastian Jordan Montano <sebastian.jordan(a)inria.fr> 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" <merkste(a)web.de> > Ã: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > 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.

April 13, 2023

Re: Collection>>reduce naming

by Richard O'Keefe

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 <merkste(a)web.de> 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_l… > > 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#l… > > > On Thu, 13 Apr 2023 at 21:17, Sebastian Jordan Montano < > sebastian.jordan(a)inria.fr> 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" <merkste(a)web.de> >> > Ã: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >> > 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. >

April 13, 2023

Re: Comparison of blocks

by 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: [ <same code> ] = [ <same code> ] 2) pure functions: [:a1 ... | <same code> ] = [:a1 ... | <same code> ] 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 [<literal>] blocks and allocates one static closure per <literal>. Then [true] == [true] hence [true] = [true] even when the two <block constructor>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 <merkste(a)web.de> 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.

April 13, 2023

Re: Collection>>reduce naming

by 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_l… 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#l… On Thu, 13 Apr 2023 at 21:17, Sebastian Jordan Montano <sebastian.jordan(a)inria.fr> 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" <merkste(a)web.de> > Ã: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > 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.

April 13, 2023

Re: Comparison of blocks

by 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: [ <same code> ] = [ <same code> ] 2) pure functions: [:a1 ... | <same code> ] = [:a1 ... | <same code> ] 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 [<literal>] blocks and allocates one static closure per <literal>. Then [true] == [true] hence [true] = [true] even when the two <block constructor>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 <merkste(a)web.de> 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.

April 13, 2023

Re: Porting from VW to Pharo

by Christian Haider

Great, you perfectly understood the CodeHolder! Instance variables not present? Leave them undeclared. Since that code never runs in this image, it does no harm. It just fills your Undeclareds list. Here is an example where I extend an existing class referencing a variable (#array) only available in the target dialect: Happy hacking, Christian Von: Steffen MÃ¤rcker <merkste(a)web.de> Gesendet: Donnerstag, 13. April 2023 10:41 An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Betreff: [Pharo-users] Re: Porting from VW to Pharo 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> 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> 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 <merkste(a)web.de <mailto:merkste@web.de> > Gesendet: Dienstag, 11. April 2023 17:52 An: Any question about pharo is welcome < <mailto:pharo-users@lists.pharo.org> pharo-users(a)lists.pharo.org> 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> 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 < <mailto:richard.sargent@gemtalksystems.com> richard.sargent(a)gemtalksystems.com> Gesendet: Donnerstag, 6. April 2023 17:55 An: Any question about pharo is welcome < <mailto:pharo-users@lists.pharo.org> pharo-users(a)lists.pharo.org> Betreff: [Pharo-users] Re: Porting from VW to Pharo The best(?) place to start is perhaps <https://wiki.pdftalk.de/doku.php?id=smalltalktransform> 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 < <mailto:merkste@web.de> merkste(a)web.de> 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> 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. -- Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

April 13, 2023

Re: Collection>>reduce naming

by Richard O'Keefe

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#l… On Thu, 13 Apr 2023 at 21:17, Sebastian Jordan Montano < sebastian.jordan(a)inria.fr> 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" <merkste(a)web.de> > > Ã: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > > 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 >

April 13, 2023

Re: Collection>>reduce naming

by Richard O'Keefe

Actually, #inject:into: is what is normally called fold or foldl, and #reduce: is commonly called fold1. It is very confusing to call foldl1 #fold:. To the best of my knowledge, the name 'reduce' comes from APL. "Z <- LO/R has the effect of placing the function LO between adjacent pairs of items along the last axis of R and evaluating the resulting expression for each subarray. If R is the vector A B C the LO-reduction is defined as follows: LO/R <-> A LO B LO C" which for APL means A LO (B LO C), so it's technically foldr1. -- IBM APL2 Language Reference, 1994, page 209. The name given to #inject:into: when it was first invented was LIT, short for List ITeration. Here's a reference: Functional Programming, Application and Implementation, Peter Henderson, 1980, page 41: <quote> As another example of a higher-order function consider the following operation of reduction (the idea and the name are in fact taken from the programming language APL). We define reduce(x,g,a) where x is a list, g is a binary function, and a is a constant, so that the list x = (Xl. . . Xk) is reduced to the value g(X1, g(X2, ... g(Xk,a) ...)) <snip> reduce(x,g,a) = if x = NIL then a else g(car(x),reduce(cdr(x),g,a)) </quote> So APL used "reduce" for foldr1, and Henderson, because most functions don't carry their identity with them, used it for foldr. As I recall it, the name "reduce" was dropped because people wanted to support both foldl and foldr (and did NOT want to apply it to higher-ranked arrays, so that 'rank reduced by 1' wasn't an aid to memory). But it IS a name for the operation that predates Smalltalk and is still in use (as APL itself is). If it comes to that, this higher-order function is called 'reduce' in Swift: https://developer.apple.com/documentation/swift/array/reduce(_:_:) and of course the Map-Reduce paradigm is famous, and guess what 'Reduce' stands for? An intention-revealing name in Smalltalk would have been aCollection injectInto: aBinaryValuable [ifNone: emptyBlock] On Thu, 13 Apr 2023 at 07:03, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > 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 >

April 13, 2023

Re: Comparison of blocks

by Richard O'Keefe

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 [<literal>] blocks and allocates one static closure per <literal>. Then [true] == [true] hence [true] = [true] even when the two <block constructor>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 <merkste(a)web.de> 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 >

April 13, 2023

Re: Collection>>reduce naming

by Sebastian Jordan Montano

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" <merkste(a)web.de> > Ã: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > 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

April 13, 2023

Re: Porting from VW to Pharo

by 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 <merkste(a)web.de> Gesendet: Dienstag, 11. April 2023 17:52 An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> 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 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 <richard.sargent(a)gemtalksystems.com> Gesendet: Donnerstag, 6. April 2023 17:55 An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> 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 <merkste(a)web.de> 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. -- Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

April 13, 2023

Comparison of blocks

by 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

April 13, 2023

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

by 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

April 12, 2023

Re: Porting from VW to Pharo

by Christian Haider

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 <merkste(a)web.de> Gesendet: Dienstag, 11. April 2023 17:52 An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> 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 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 <richard.sargent(a)gemtalksystems.com <mailto:richard.sargent@gemtalksystems.com> > Gesendet: Donnerstag, 6. April 2023 17:55 An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Betreff: [Pharo-users] Re: Porting from VW to Pharo The best(?) place to start is perhaps <https://wiki.pdftalk.de/doku.php?id=smalltalktransform> 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 < <mailto:merkste@web.de> merkste(a)web.de> 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> 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.

April 12, 2023

Collection>>reduce naming

by 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

April 12, 2023

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

by Richard O'Keefe

You say <quote> - 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). </quote> On the first point, we have to take your word for it. It's not clear why you could not pass an n+1-element array to the source method and have it fill in elements after the first rather than having it allocate a new array. If you are concerned about object allocation in a tight loop this would be a good place to start. argArray := Array new: block argumentCount. ... source compute: i into: argArray. argArray at: 1 put: i. block valueWithArguments: argArray. If for some reason it is utterly impossible to modify 'source compute: i' in this way, we can *still* use the technique of allocating an array once for the whole loop. argArray := Array new: block argumentCount. ... argArray at: 1 put: i; replaceFrom: 2 to: argArray size with: (source compute: i). block valueWithArguments: argArray. This seems like the smallest possible change to your code. You still have the overhead of copying from one array to another -- which is why I prefer modifying #compute: -- but you do not have the overhead of allocating an array per iteration. On the second point, right there you have the assumption that is limiting your vision. You are viewing the problem as "pass an extra first argument to the block" when you *should* frame it as "ensure that the block knows the value of i SOMEHOW". Presumably these blocks are generated by code written by you. So let's start with Someclass methods for: 'generating blocks' blockFor: aSituation ^[:x0 :x1 ... :xn | ....] block := Someclass blockFor: theSourceSituation. (1 to: 1000) do: [:i | | args | args := source compute: i. block valueWithArguments: {i} , args So now we change it to Someclass methods for: 'generating blocks' blockFor: aSituation sharing: stateObject ^[:x1 ... :xn | |x0| x0 := stateObject contents. .....] ref := Ref with: 0. block := Someclass blockFor: theSourceSituation sharing: ref. 1 to: 1000 do: [:i | |args| ref contents: i. args := source compute: i. block valueWithArguments: args]. Ref is an actual class in my library modelled on the Pop-2 and SML types of the same name. It's not important. What *is* important is that information can be supplied to a block through a shared object as well as through a parameter. I am a little bit twitchy about the 'coincidence' of the size of #compute:'s result and the argument count of the block. Why not pass the block to #compute: so that there never is any array in the first place? compute: index ... ^{e1. ... en} ... => compute: index thenDo: aBlock ... ^aBlock value: e1 ... value: en ... ref := Ref with: 0. block := Someclass blockFor: theSourceSituation sharing: ref. 1 to: 1000 do: [:i | |args| ref contents: i. source compute: i thenDo: block]. Now there are even fewer arrays being allocated and no use of #valueWithArguments: in any guise. The problem is NOT, as some commentators apparently think, that you are using a block. 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. We have several idioms here: Reuse Object (convert an allocation per iteration to an allocation per loop by reinitialising a object instead of allocating a new one) Communicate Through Shared Microstate (communicate information between a method and a block or object through a 'microstate' object created by the method and passed when the block or object is created) Multiple Values by Callback (instead of 'returning' multiple values in a data structure, pass a block to receive those values as parameters). On Wed, 12 Apr 2023 at 04:44, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > 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 >

April 12, 2023

Fwd: [Esug-list] [IWST 2023]Call for Papers

by stephane ducasse

> Begin forwarded message: > > From: Gocrdana Rakic via Esug-list <esug-list(a)lists.esug.org> > Subject: [Esug-list] [IWST 2023]Call for Papers > Date: 11 April 2023 at 19:40:35 CEST > To: esug-list(a)lists.esug.org > Reply-To: Gocrdana Rakic <goca(a)dmi.uns.ac.rs> > > Call For Papers > IWST 2023: International Workshop on Smalltalk Technologies > Lyon, France; August 29th-31st, 2023 > Goals and scope > The goals of the workshop is to create a forum around contributions and experiences in building or using technologies related to Smalltalk. While maturity of presented ideas and results is not crucial, it is expected that their presentation trigger discussion and exchange of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Authors are invited to submit research articles or industrial papers. > > Important Dates > Submission deadline: May 14th, 2023 > > Notification deadline: June 11th, 2023 > > Re-submission deadline: July 1st, 2023 > > Workshop: August 29th-31st, 2023 > > Topics > We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: > > Aspect-oriented programming, > > Design patterns, > > Experience reports, > > Frameworks, > > Implementation, new dialects or languages implemented in Smalltalk, > > Interaction with other languages, > > Meta-programming and Meta-modeling, > > Tools > > Submissions, reviews, and selection > We are looking for papers of two kinds: > > Short position papers (5 to 10 pages) describing fresh ideas and early results. > > Long research papers (more than 10 pages) with deeper description of experiments and of research results. > > Both submissions and final papers must be prepared using the CEUR ARTÂ 1-columnÂ style <https://ceur-ws.org/Vol-XXX/CEURART.zip>. > > All submissions must be sent via EasyChair submission page <https://easychair.org/conferences/?conf=iwst23>. > > Reviewing > > Submissions will be reviewed by at least 3 reviewers. Selected papers will be invited to be presented at the workshop in Lyon and published in the CEUR-WS Proceedings <https://ceur-ws.org/>. > > As the workshop form encourage bringing fresh ideas and early results to be presented and discussed, and aims for giving a chance to young community members to learn and grow, it may happen that submissions with discussion potential be conditionally accepted. In this case authors are expected to strictly follow the recommendation of the reviewers and resubmit a new version for the second fast review by the chairs in collaboration with assigned reviewers, and for making the final decision. > > Best Paper Award > > To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. > > We thank our financial contributors who make it possible for prizes for the three best papers (estimated): 1000 USD for first place, 600 USD for second place and 400 USD for third place. > > The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. > > The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be eligible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. > > Program chairs > Stephane Ducasse, Inria Lille, France (chair), > Gordana Rakic, University of Novi Sad, Serbia (chair) > Program committee > > Nour Agouf, Inria Lille, France, > Vincent Blondeau, Lifeware, Switzerland, > Cedrick Beler, Ecole Nationale d Ingenieurs de Tarbes, Hautes-Pyrenees, France, > Nicolas Cardozo, Universidad de los Andes, Bogota, Colombia, > Celine Deknop, Universite catholique de Louvain (UCL), Belgium, > Michele Lanza, Software Institute, Universita della Svizzera italiana, Lugano, Switzerland, > Eric Lepors, Thales DMS, France, > Dave Mason, Ryerson University, Toronto, Canada, > Kim Mens, Universite catholique de Louvain (UCL), Belgium, > Ana-Maria Oprescu, University of Amsterdam, Neatherlands, > Jean Privat, University of Quebec in Montreal, Canada, > Pooja Rani, University of Bern, Switzerland, > Larisa Safina, Inria Lille, France, > Joao Saraiva, University of Minho, Portugal, > BenoÃ®t Verhaeghe, Berger-Levrault, Lyon, France, > Oleksandr Zaytsev, Cirad, UMR SENS, France > _______________________________________________ > Esug-list mailing list -- esug-list(a)lists.esug.org <mailto:esug-list@lists.esug.org> > To unsubscribe send an email to esug-list-leave(a)lists.esug.org <mailto:esug-list-leave@lists.esug.org>

April 12, 2023

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

by Richard Sargent

Steffen, I think the trouble you are seeing comes from trying to use a block in a way that is inappropriate. A Block provides an anonymous function, but why use a Block that makes it so much more complicated? Perhaps, you should reconsider an approach like: (1 to: 1000) do: [:i | | data | data:= source compute: i. MyProcessor handleSourceData: data index: i ] That allows you to factor out the block code into clean and intention revealing code, and eliminates the need to compose the arguments into a form compatible with Block invocation. -----Original Message----- From: Steffen MÃ¤rcker <merkste(a)web.de> Sent: April 11, 2023 09:44 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Cc: vwnc(a)lists.cs.illinois.edu Subject: [Pharo-users] Re: [vwnc] Block evaluation with n+1 arguments 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

April 11, 2023

Re: Porting from VW to Pharo

by Todd Blanchard

You mean we can't just ask ChatGPT to do it? /s > On Apr 11, 2023, at 8:52 AM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > > 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 <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 <richard.sargent(a)gemtalksystems.com> > Gesendet: Donnerstag, 6. April 2023 17:55 > An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Betreff: [Pharo-users] Re: Porting from VW to Pharo > > The best(?) place to start is perhaps https://wiki.pdftalk.de/doku.php?id=smalltalktransform <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 <merkste(a)web.de <mailto:merkste@web.de>> 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 <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 <http://vivaldi.com/> herunter.

April 11, 2023

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

by 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

April 11, 2023

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

by Steffen MÃ¤rcker

Hi Stephane, thanks for linking the upcoming lesson. I'll have a look. :-D Best, Steffen stephane.ducasse(a)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… On 6 Apr 2023, at 15:28, Steffen MÃ¤rcker <merkste(a)web.de> 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.

April 11, 2023

Re: Block evaluation with n+1 arguments

by 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 <merkste(a)web.de> 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:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 -- Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

April 11, 2023

Re: Porting from VW to Pharo

by 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 <mail(a)christianhaider.de> 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 <richard.sargent(a)gemtalksystems.com> Gesendet: Donnerstag, 6. April 2023 17:55 An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> 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 <merkste(a)web.de> 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.

April 11, 2023