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

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