Hi Christian!
I'll have a look. Over the weekend, I pushed a bit forward. The #category:
worked as expected. However, I observed that Pharo seems to create packages and
package tags implicitly. For instance:
- If I import the VW packages "Transducers" and "Transducers Tests", two
packages are created as expected.
- If I import "Transducers-Tests" (note the -) instead, no new package is
created and a new package tag is created instead.
This means, we have to be careful when porting packages including - in their
name from VW to Pharo. So far I could not figure out how to avoid this
automatic categorization. But maybe I am missing something as a Pharo newbee.
I was also experimenting with baselines. It would be nice to be able to define
a baseline already in the export. For now, I created a package
"BaselineOf" with a class of the same name. It inherits from a dummy
class "BaselineOf" in my project transform package. It would be nice to have
the baseline in this package too and to create the same-named package during
the export. Is there a way to do this right now?
I noticed in the wiki that #unusedClasses: is #ignoredNames: now, right?
Regarding crypto in PDFtalk: I was just wondering. This is quite difficult to
do right, I am certainly missing too much knowledge to do it on my own right
now. Maybe some day. ;-)
Important: Thank you for your kind support!
Best,
Steffen
Christian Haider schrieb am Samstag, 6. Mai 2023 19:05:22 (+02:00):
All references disentangled. Everything should be clean now.
Happy hacking,
Christian
Von: Steffen Märcker
Gesendet: Freitag, 5. Mai 2023 10:15
An: Any question about pharo is welcome
Betreff: [Pharo-users] Re: Porting from VW to Pharo
Dear Christian,
I just gave it a try with a virgin 64 Bit 8.3 image and loaded
* Smalltalk Transform Project
* PDFtalk Project
* Pharo FileOut PDFtalk
The code loaded fine but I had a few hiccups with the tests.
* Many tests use #assert:equals: which SUnitToo (loaded automatically)
surprisingly does not provide.
* After adding this method to TestCase, all but four test run. The Pattern that
is used to match in
- testVASmalltalkAddTimeAndVersion
- testSqueakAddTimeAndVersion
- testPharoAddTimeAndVersion
- testGemstoneAddTimeAndVersion
Did not take PUL into account. This works: '# From VisualWorks®*, * of * on *
at *'
* In the following tests, some selectors cannot be found:
- testMethodAddsForValuemap - #_gs_printvalueWith:
- testMethodAddsForObject - #_gs_Symbol_literalString
- testWriteSystemExtensionMethods - #_gs_printvalueWith:
Btw, I switched to SUnit to ease Porting to Pharo. I'll have a look into the
#category parameter today.
OT PDFtalk: Do you have plans to support verifying signatures in PDF files or
singing using a certificate?
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
