Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
portingblog [2022/05/29 08:12]
christian [First fileout of the full PDFtalk for Pharo]
portingblog [2022/06/22 10:57] (current)
christian [Observations]
Line 6: Line 6:
  
 Now the real project starts and will be recorded here. Now the real project starts and will be recorded here.
 +
 +===== Second PDFtalk fileOut for Squeak and Pharo =====
 +
 +//Tuesday, 21. June 2022//
 +
 +This version includes fileOuts for [[https://github.com/PortingPDFtalk/SqueakPDFtalk/releases/tag/1.0.2|Squeak]] and [[https://github.com/PortingPDFtalk/PharoPDFtalk/releases/tag/1.3.1|Pharo]]. All load without fatal errors.
 +
 +**Squeak: [[StateOfThePort#squeak-6-0|608 run, 317 pass, 63 fail, 228 error]]**
 +
 +**Pharo: [[StateOfThePort#pharo-10-0|608 run, 285 pass, 54 fail, 269 error]]**
 +
 +==== Observations ====
 +
 +After the first raw fileOut, here is the result of the first porting changes. 
 +
 +Fortunately, I had nice coding sessions with Marcel Taeumel (Squeak) and Sean DiNigris (Pharo). We talked about porting, explored the image and tests and fixed things on the way without much of a plan. That was fun! Now, I followed up on all the issues, fixed them and added the transformations. The other issues reported on the list and on GitHub were fixed a well. Thank you, Christoph Thiede for the detailed and constructive list of issues. Thank you, Thorsten Bergmann for the discussion about names and new tests for Values.
 +
 +Since Squeak and Pharo are still very similar, I fixed the issues in both Smalltalks. The new fileOut improves the test statistics quite nicely:
 +  * +11 tests, +169 pass, +44 fail, -202 error (Squeak)
 +  * +11 tests, +137 pass, +35 fail, -161 error (Pharo)
 +Details at the [[https://wiki.pdftalk.de/doku.php?id=stateoftheport|state of the port]].
 +PostScript is now almost ripe to pick. BTW, if anybody has use for PostScript, this package can be used stand-alone.
 +
 +Now the list of issues. Maybe too detailed for most of you, but maybe you find an issue to comment on?
 +
 +  * harvested 11 tests from the independent [[https://github.com/astares/Pharo-Values|Values port]] of Thorsten Bergmann
 +  * fixed UTF16 encoding (using Zinc in Pharo - I don't how yet how to load prerequisites. Zinc seems to be in the base though)
 +  * added ''Character class>>#illegalCode''
 +  * replaced ''#decodeASCII85Group:''. The problem is a difference in ''#first:'' (of lists): in VW it never fails (that's why I like and use it alot), because the parameter is forced into range. In Squeak and Pharo, it raises an error when the parameter is negative or the list has not enough elements. Here, the checks are done by the caller.
 +  * ''#doWithIndex:'' instead of ''#withIndexDo:''
 +  * replaced ''#tokensBasedOn:''
 +  * ''WideString'' instead of ''TwoByteString'' - I am not sure about this...
 +  * Squeak: replaced ''MD5'' hash. Added a Monticello preload
 +  * ''#signal(:)'' instead of ''#raiseSignal(:)''
 +  * replaced ''#isSignalledException'' by ''#isKindOf:''
 +  * ''#theNonMetaClass'' instead of ''#instanceBehavior''
 +  * ''Integer class>>#readFrom:base:'' instead of ''Number class>>#readIntegerFrom:radix:''
 +  * ''Mutex'' instead of ''RecursionLock''
 +  * added ''Pragma class>>#allInMethod:''
 +  * Pharo: ''Pragma>>#methodSelector'' instead of ''#selector''
 +  * Pharo: ''WebBrowser'' instead of ''ExternalWebBrowser''
 +  * Pharo: added ''Valuemap>>#valuesDo:''
 +
 +===== First fileout of the full PDFtalk for VA Smalltalk =====
 +
 +//Saturday, 11. June 2022//
 +
 +This version includes fileOuts for VAST 10.0 and VAST 11.0. All load without fatal errors.
 +
 +[[https://github.com/PortingPDFtalk/VASTPDFtalk/releases/tag/1.0.0.19|Download the fileout]] and file it into a fresh VAST image.
 +
 +**[[StateOfThePort#va-smalltalk-11-0|585 run, 143 pass, 14 fail, 428 error]]**
 +
 +==== Observations ====
 +
 +VA Smalltalk is a bit stricter than other Smalltalks when it comes to compiling code. A fileIn aborts
 +  * when you define a class with an undeclared //superclass//,
 +  * when you //extend// an undeclared class or
 +  * when a method contains a //reference// to an undeclared class.
 +Syntax errors are shown on the Transcript and methods with syntax errors are not added to the system, but the fileIn proceeds.
 +
 +Usually, for the initial fileOut, I add all the affected classes to the ''ignore'' list of the package change. This is not very practical, because much code is not written to the fileOut and references break. 
 +
 +But, hey, we do Smalltalk, right? Why not adding an error handler to the compilation and define the missing classes on the fly? The new class would subclasses Object and is useless otherwise. But now the class references stay valid and code browsing is much more meaningful. With some inlining and simplyfication I ended up with a handful methods without state - they could be attached to any class. I put them on the class side of the application class of a mini application.
 +
 +{{:pdf:pdftalk_organizer.png?nolink&400|}}
 +
 +This works very nicely. The freshly created classes are put into a subapplication with "_Undeclared" attached to the name. The goal for the port is to empty and remove that subapplication by modifying the code, so that the undeclared classes are not needed anymore.
 +
 +**I love Smalltalk!**
 +
 +But a problem remains. Now I have code for VAST to read the fileOut. But I want to have everything automatic. I don't want to ask the user to install whatever other software.
 +
 +But, hey, we do Smalltalk, right? Why not adding the code of the ''AugmentingReader'', as I call it, at the beginning of the fileOut and then use it to read the rest of the file? Wait, how can code which was just read from a file stream take over reading from that very stream? Ok, this is dark magic which you should not do at work :-). In Smalltalk we can ask for the current method invocation(!). Usually, this is accessed through the pseudo variable ''thisContext''. VA Smalltalk does not have ''thisContext'', but you can get a stack frame by using ''Processor currentProcess contextAtFrame: <Integer>''. This is good enough. Now, I pick a frame a couple of sends before where the stream is an argument to that method. With the stream I continue reading with my AugmentingReader. When everything has been read, the original fileIn concludes normally. Of course, one could delete the AugmentingReader at the end of the fileIn automatically :-), but that may be too much dark magic.
 +
 +**I love Smalltalk!**
  
 ===== First fileout of the full PDFtalk for Pharo ===== ===== First fileout of the full PDFtalk for Pharo =====
  • portingblog.1653804735.txt.gz
  • Last modified: 2022/05/29 08:12
  • by christian