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

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