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

Re: Porting from VW to Pharo

by Steffen MÃ¤rcker

Dear Christian and Richard, thanks for your answers. I'll try to go through the process step by step and come back with questions to the list if that's okay. First, after loading the "Pharo Fileout PDFTalk", VW (8.3, 64 Bit) shows two unloadable definitions: - PostscriptInterpreterTests>>_ph_testOperatorNotFound - ColorValueTest>>_ph_testBridgedNamedColors Both classes are not loaded Second, it appears that some of the selectors mentioned on https://wiki.pdftalk.de/doku.php?id=smalltalktransformdocumentation have been renamed, e.g., PackageChanges>>unusedClasses More general, regarding project structure. What is the best approach to port a project that consists of multiple loosely coupled packages (not in a bundle) some of which being optional? Like - Package Project Core - Package Project Core Tests (requires Core) - Package Project Extension A (requires Core) - Package Project Extension A Tests (requires Extension A) - Package Project Examples (requires Core and Extension A) And how should I structure this on the Pharo site and in an iceberg repository? One Git repository per package or all in the same? Is there a guide to this or a specific Mooc lesson? Kind regards, Steffen Christian Haider schrieb am Donnerstag, 6. April 2023 18:16:00 (+02:00): Yes, PDFtalk is the only example, because it was created to port that library. Any other uses are welcome. The project has been dormant for a year now because of other obligations, but I hope to resume soon. The documentation is, as Richard notes, in a suboptimal state. I think that the information is still accurate. Any help with this would be welcome, for example by asking questions or by criticizing concrete issues. Christian Von: Richard Sargent <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

headless mode

by Christophe TouzÃ©

Bonjour, Quelqu'un pourrait-il me dire svp comment lancer une image Pharo 10 en mode headless (sous Ubuntu) ? J'ai essayÃ© "pharo --headless monImage.image" sans succÃ¨s. PrÃ©cision, j'ai Seaside dans mon image. Merci d'avance ! Hello, Could somebody tell me how to launch a Pharo 10 image in headless mode, under Ubuntu ? I have tried "pharo --headless myImage.image", without success. I have the Seaside package in my image, I don't know if it matters. Thanks !

April 11, 2023

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

by Richard O'Keefe

>From the slides: "What is the difference between a block and a simple object understanding #value?" The slides give the wrong answer. The right answer is that - a block can see the variables of the blocks, method, and object containing it which allows ENCAPSULATION of long term and short term state - an object cannot see those variables, forcing long term and short term state to be dispersed to other objects, harming encapsulation. The slides also say " imagine passing a block around and want to accumulate information â¦ you can't!" which is of course not really so. Consider |b s| b := [:state :argument | state nextPut: argument]. s := Summary new. #(3 1 4 1 5 9) do: (b bindFirst: s). s printOn: Transcript. Transcript cr. That's actual working code and the output is Summary(count: 6 min: 1 max: 9 mean: 3.833333333333333 sd: 2.994439290863428 skew: 1.044066600910494) Far from "you can't", it's dead simple. My library includes #bindFirst:[bindSecond:[bindThird:]] #bindSecond:[bindThird:] #bindThird: for binding any subset of the first three arguments of a block. So far that's been enough. The slides further say "Adding behavior (i.e., offering another message) is impossible" which is sort of true but misleading: you cannot add additional behaviour to *an individual block*, but you CAN add additional behaviour to the class it is an instance of. Which is how come I have #value:valueWithArguments: #bindFirst: and its relatives, and a host of other combinators. It really really helps that I have a separate class for each block arity. For example, I have about 20 non-ANSI methods on TriadicBlock but about 50 on DyadicBlock. The additional 30 on DyadicBlock would make no sense for TriadicBlock, and smushing everything up into a single Block class would not work well. That whole set of slides reads like a hymn of praise to Java nested classes, which can do things blocks can't but on the other hand can't do things that blocks can. The issue we are discussing in this thread, of course, is not blocks as such. It isn't even blocks with many arguments. In aBlock value: firstArgument valueWithArguments: restArguments we have been given no reason to suppose that restArguments is long. I still have a couple of stickers that Brian Marick gave me, reading AN EXAMPLE WOULD BE GOOD ABOUT NOW. I'd still like to know what the original poster wanted to DO with value: firstArgument value: restArguments ^self valueWithArguments: {firstArgument} , restArguments On Tue, 11 Apr 2023 at 04:25, Richard Sargent <rsargent(a)5x5.on.ca> wrote: > Excellent write up, Stephane! > > I will add that over the years, there have been many times (countless!) > when developing/debugging involved a complex block and that turned out to > be significant nuisance. > > I can elaborate on the details, but once a block gets passed around, > revising it on the fly breaks debug and continue. > > Having a block comprise a single message send allows one to revise that > method as and when needed. > > > > > > *From:* vwnc-request(a)lists.cs.illinois.edu < > vwnc-request(a)lists.cs.illinois.edu> *On Behalf Of * > stephane.ducasse(a)free.fr > *Sent:* April 10, 2023 07:03 > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Cc:* vwnc(a)lists.cs.illinois.edu > *Subject:* Re: [vwnc] [Pharo-users] Block evaluation with n+1 arguments > > > > 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… > <https://urldefense.com/v3/__https:/rmod-files.lille.inria.fr/DesignCoffeeCl…> > > > > > > > > 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 > > >

April 11, 2023

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

by Richard Sargent

Excellent write up, Stephane! I will add that over the years, there have been many times (countless!) when developing/debugging involved a complex block and that turned out to be significant nuisance. I can elaborate on the details, but once a block gets passed around, revising it on the fly breaks debug and continue. Having a block comprise a single message send allows one to revise that method as and when needed. From: vwnc-request(a)lists.cs.illinois.edu <vwnc-request(a)lists.cs.illinois.edu> On Behalf Of stephane.ducasse(a)free.fr Sent: April 10, 2023 07:03 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Cc: vwnc(a)lists.cs.illinois.edu Subject: Re: [vwnc] [Pharo-users] Block evaluation with n+1 arguments 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… <https://urldefense.com/v3/__https:/rmod-files.lille.inria.fr/DesignCoffeeCl…> On 6 Apr 2023, at 15:28, Steffen MÃ¤rcker <merkste(a)web.de <mailto:merkste@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

April 10, 2023

Re: Block evaluation with n+1 arguments

by Richard O'Keefe

(1) I have #value:valueWithArguments: in my personal library. (2) The way to answer your question is to look at #valueWithArguments:, It normally goes through a primitive. However, it *does* have backup code that you could adapt. (3) Without benchmarking, it's not clear whether the cost of not being able to go through the primitive will exceed the saving of not making another array. It might not be the win you expect. Have you profile your code to find out whether this way of invoking a block is *worth* speeding up? (4) aBlock value: {a} , remaining has the merit of working in other Smalltalks and the merit of being familiar to other programmers. (5) Is there no way that you can restructure your code so that you no longer want to do this? Point (1) is true, but only because I've never bothered to throw it away. In the system where I wrote it, it *does* save time overall, but in the complete context, it wasn't worth doing. On Fri, 7 Apr 2023 at 01:29, 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 >

April 10, 2023

Re: Block evaluation with n+1 arguments

by Joachim Tuchel

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 Tuchelmailto:jtuchel@objektfabrik.de Fliederweg 1http://www.objektfabrik.de D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

April 8, 2023

Re: Block evaluation with n+1 arguments

by 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 >

April 7, 2023

English subtitles for Adele Goldberg

by Richard Kenneth Eng

https://youtu.be/8uGV9hcIN_Y I've added an English subtitle track (NOT auto-generated) to correct for the two minutes of audio difficulty in Adele Goldberg's keynote talk. The auto-generated subtitle track is incomplete during these two minutes (5:26).

April 7, 2023

This week (13/2023) on the Pharo Issue Tracker

by Marcus Denker

#This week (13/2023) on the Pharo Issue Tracker. We merged around 100 Pull Reuests this week (Pharo11 and Pharo12) To see the state of not yet merged PRs easier, we added a GitHub Board https://github.com/orgs/pharo-project/projects/34 To see what is happing in Pharo11 and Pharo12, we are staring to check if Kanban style boards can help Pharo11: https://github.com/orgs/pharo-project/projects/35 Pharo12: https://github.com/orgs/pharo-project/projects/38 #Pharo 11 ## Epemerons - Move weak dictionaries to new finalization #13212 https://github.com/pharo-project/pharo/pull/13212 ## Fixes - Update find sdl2 #13031 https://github.com/pharo-project/pharo/pull/13031 - Playground not able to evaluate simple #timesRepeat: #13321 https://github.com/pharo-project/pharo/pull/13321 - Handle Cmd/Ctrl + right arrow during completion. #13217 https://github.com/pharo-project/pharo/pull/13217 - Added new text selection for pharo #13231 https://github.com/pharo-project/pharo/pull/13231 - Fast table should not manage keydown as keystroke #13214 https://github.com/pharo-project/pharo/pull/13214 - Socket error handling can get in a loop #13228 https://github.com/pharo-project/pharo/pull/13228 - SDL2 on MacOS required to postpone focus #12946 https://github.com/pharo-project/pharo/pull/12946 - KeyboardKey class>>#initializeKeyFromCharacterCompatibilityTable maps 3 characters incorrectly #13211 https://github.com/pharo-project/pharo/pull/13211 - Fix selection of multiword #13218 https://github.com/pharo-project/pharo/pull/13218 - Fix the UI of the spotter by outlining the input field. Fix pharo/#10993 #421 https://github.com/pharo-spec/NewTools/pull/421 - Fix DNU trimBoth on non-strings #1372 https://github.com/pharo-spec/Spec/pull/1372 ## Cleanups - StFilterFuzzy>>#applyFilterWithQuery send missing #takeFirst: #13242 https://github.com/pharo-project/pharo/pull/13242 - 12165-ReAbstractRule-mentions-missing-help-in-class-comment #13252 https://github.com/pharo-project/pharo/pull/13252 - Replace allProtocols by protocols #1373 https://github.com/pharo-spec/Spec/pull/1373 - SpCodePresenter>>#evaluate source code is string #1371 https://github.com/pharo-spec/Spec/pull/1371 ## Speed - do not compute message sends dependencies in browser dependencies tool #13268 https://github.com/pharo-project/pharo/pull/13268 #Pharo12 - Weekly P11 sync in P12 #13253 https://github.com/pharo-project/pharo/pull/13253 ## Fixes - 4969-Epicea-Reverting-a-class-remove-looses-class-comment #13332 https://github.com/pharo-project/pharo/pull/13332 - hotfix ClassTest>>#testCommentSourcePointer #13281 https://github.com/pharo-project/pharo/pull/13281 - Fix #13246 class comments can get lost when commiting code #13276 https://github.com/pharo-project/pharo/pull/13276 - Finder: Ignoring combinations selector for collections #13226 https://github.com/pharo-project/pharo/pull/13226 ## Compiler - Faulty Code: compiler honor failBlock #13261 https://github.com/pharo-project/pharo/pull/13261 - Faulty code: improve error block node #13264 https://github.com/pharo-project/pharo/pull/13264 - RBNotice: add isSyntaxError and make it easier to sort them #13344 https://github.com/pharo-project/pharo/pull/13344 - Faulty code: forbid read of undeclared variables #13238 https://github.com/pharo-project/pharo/pull/13238 - Faulty code: don't permit undeclared by default #13286 https://github.com/pharo-project/pharo/pull/13286 - Compiler simplify OCSemanticScope #13303 https://github.com/pharo-project/pharo/pull/13303 - Faulty parser: better faulty literal (byte) arrays #13300 https://github.com/pharo-project/pharo/pull/13300 - Some compiler cleanup #13302 https://github.com/pharo-project/pharo/pull/13302 - Faulty code: make undeclared write resumable with the right value #13297 https://github.com/pharo-project/pharo/pull/13297 - Faulty code: add permitUndeclared #13280 https://github.com/pharo-project/pharo/pull/13280 - Faulty code: move code reparator to RBNotice #13277 https://github.com/pharo-project/pharo/pull/13277 - Snippets: split badExpressions into 3 methods #13263 https://github.com/pharo-project/pharo/pull/13263 - Faulty code: various undeclared cleanups #13248 https://github.com/pharo-project/pharo/pull/13248 - Faulty code: inspect notice #13243 https://github.com/pharo-project/pharo/pull/13243 - Cleanup some compiler clients #13235 https://github.com/pharo-project/pharo/pull/13235 - Faulty code: forbid write to undeclared variables #13201 https://github.com/pharo-project/pharo/pull/13201 - Faulty code snippet: test evaluation #13223 https://github.com/pharo-project/pharo/pull/13223 - Compiler: replace parseForRequestor by checkNotice #13222 https://github.com/pharo-project/pharo/pull/13222 ## SystemOrganizer Cleanup - Remove the need to give a SystemOrganizer to SystemDictionary #13314 https://github.com/pharo-project/pharo/pull/13314 - Remove SystemOrganisation global #13306 https://github.com/pharo-project/pharo/pull/13306 - Remove references to SystemOrganization #13271 https://github.com/pharo-project/pharo/pull/13271 - Remove references to SystemOrganizer #13259 https://github.com/pharo-project/pharo/pull/13259 - Make RPackageOrganizer polymorphic with SystemOrganizer #13258 https://github.com/pharo-project/pharo/pull/13258 - RPackageOrganizer should not call system organizer global but keep a reference #13245 https://github.com/pharo-project/pharo/pull/13245 - Rename SystemOrganizer "elements" into "Behavior" #13206 https://github.com/pharo-project/pharo/pull/13206 ##Protocol vs Category - Protocol: Rename "category" into protocol in rules #13203 https://github.com/pharo-project/pharo/pull/13203 - Rename some "category" into protocol in code export #13190 https://github.com/pharo-project/pharo/pull/13190 - Remove usage of Protocol>>#canBeRemoved #13311 https://github.com/pharo-project/pharo/pull/13311 - Remove nullProtocolName #13333 https://github.com/pharo-project/pharo/pull/13333 - Use Protocol>>#unclassified instead of #defaultName #13331 https://github.com/pharo-project/pharo/pull/13331 - Remove class AllProtocol #13289 https://github.com/pharo-project/pharo/pull/13289 - Remove ClassOrganization>>allProtocol #13275 https://github.com/pharo-project/pharo/pull/13275 - hotfix: add missing return in ClassOrganization>>#ensureProtocol: #13278 https://github.com/pharo-project/pharo/pull/13278 - Protocols: Allow to compile a method with a real protocol #13247 https://github.com/pharo-project/pharo/pull/13247 - Rename #methodsInProtocolNamed: into #methodSelectorsInProtocol: #13257 https://github.com/pharo-project/pharo/pull/13257 - Remove ClassOrganization>>allProtocolNames #13256 https://github.com/pharo-project/pharo/pull/13256 - Inline protocol organizer #13187 https://github.com/pharo-project/pharo/pull/13187 - ProtocolOrganizer: Inline more behavior into ClassOrganization #13234 https://github.com/pharo-project/pharo/pull/13234 ## Refactoring Engine - [Refactoring] push down method in some classes driver #13175 https://github.com/pharo-project/pharo/pull/13175 - Refactor: insert new class refactoring #13216 https://github.com/pharo-project/pharo/pull/13216 - 13215-RB-RBRefactoringChangeTesttestPerformChangeMetaclass #13221 https://github.com/pharo-project/pharo/pull/13221 ## CI / Bootstrap - Skip windows broken tests #13308 https://github.com/pharo-project/pharo/pull/13308 - Remove PBOldExtendedBootstrap #13290 https://github.com/pharo-project/pharo/pull/13290 - Bootstrap: allow to authetificate github requests during the bootstrap #13279 https://github.com/pharo-project/pharo/pull/13279 - Declare global variables Display, World and ActiveWorld #13236 https://github.com/pharo-project/pharo/pull/13236 ## Small Cleanups - unskip #testPerformChangeClass #13213 https://github.com/pharo-project/pharo/pull/13213 - Remove some unecessary not from the kernel #13197 https://github.com/pharo-project/pharo/pull/13197 - Faulty code: fix syntax error on empty closers #13262 https://github.com/pharo-project/pharo/pull/13262 - SettingBrowser class>>viewAllSettings has no senders and is broken #13288 https://github.com/pharo-project/pharo/pull/13288 - Restore comment of MockForCompilation #13293 https://github.com/pharo-project/pharo/pull/13293 - remove Deprecated11 #13291 https://github.com/pharo-project/pharo/pull/13291 - Fix some deprecated sends #13287 https://github.com/pharo-project/pharo/pull/13287 - Remove dependency of Collections-Abstract/Sequenceable over Random-Core #13294 https://github.com/pharo-project/pharo/pull/13294 - Extract SourceFileArrayTest to System-Sources-Tests #13307 https://github.com/pharo-project/pharo/pull/13307 - Do not disable system announcements during rpackage tests #13298 https://github.com/pharo-project/pharo/pull/13298 - Clean ChangeSetClassChangesTest #13317 https://github.com/pharo-project/pharo/pull/13317 - Remove deprecated modelwants steps in in p12 #13325 https://github.com/pharo-project/pharo/pull/13325 - Finish to cut 'Tests' package #13338 https://github.com/pharo-project/pharo/pull/13338 - Cleanup small cleanups in baseline of base libraries package #13327 https://github.com/pharo-project/pharo/pull/13327 - Deprecate OneShotArmed / doOnlyOnce: mechanism in ProtoObject (P12) #13320 https://github.com/pharo-project/pharo/pull/13320 - Cleanup: Move as "Arrayed" tagged test classes from generic "Collections-Tests" package to specific "Collections-Native-Tests" package #13336 https://github.com/pharo-project/pharo/pull/13336 - Fix and load SystemCommands tests #13340 https://github.com/pharo-project/pharo/pull/13340 - Remove general help package from the repo #13339 https://github.com/pharo-project/pharo/pull/13339 - extract return and use and: expression. add some tests #13343 https://github.com/pharo-project/pharo/pull/13343 - deprecate classesThatImplementAllOf: method. fix: #12832 #13266 https://github.com/pharo-project/pharo/pull/13266 - PositionableStream>>nextChunkText is dead code #13232 https://github.com/pharo-project/pharo/pull/13232 - This commit simplifies some conditionals using isEmpty followed by an #ifTrue:[ifFalse:] #13200 https://github.com/pharo-project/pharo/pull/13200 - Move runarray to collections support #13140 https://github.com/pharo-project/pharo/pull/13140

April 7, 2023

Re: Porting from VW to Pharo

by Stewart MacLean

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 > >

April 7, 2023