Hi Christian. (You can find some other discussion of this in Discord with
Yanni and others.)
I just evaled:
SmalltalkTransform.Pharo100 fileOutValues
This wrote file Values.Pharo100.st of size 42 KB to my VW image directory.
So that little example is a test that shows how the transformation is done. It
converts just package Values to a Pharo-compatible file-in. My task is then to
queue a bunch of ProjectChange instances like this one:
SmalltalkTransform.Pharo100>>
ValuesProject
^ProjectChange
name: #Values
source: (Array with: (Package name: #Values))
changes: (Valuemap with: 'Values' -> self
ValuesTransform)
but for my own packages. No bundles are transformed (just their contained
packages) because Pharo doesn’t have bundles.
Is that right?
Is method
ValuesTransform
^PackageChange
ignoredNames:
#(#{Smalltalk.GeneralBindingReference})
bridgeClasses: (Valuemap
with: #{Timestamp} ->
#DateAndTime
with: #{Smalltalk.ColorValue}
-> #Color)
localChanges: self valuesLocalTransform
extensions: (Array
with: (SystemClassChange
className:
#Color
instanceChanges: (Array with: (Add method: #asColorValue code:
#_ph_asColorValue)))
with: (SystemClassChange
className:
#TextStream
instanceChanges: (Array with: (Add method: #nextPutAllText: code:
#_ph_nextPutAllText:))))
written specifically for that package? I would think it applies to all
packages. I see some expected mappings like Timestampe to DateAndTime.
What about conversion of VW arrays to Pharo literal arrays? How is that done?
I recall that one of the Smalltalks (I don’t recall which) had Stream semantics
differing from VW’s.
… I just checked. VW’s #upTo: method includes the object and leaves the index
after it, and Pharo’s excludes the object and leaves the index at the object.
So that is some major breakage if we don’t correct it. Can it be done
automatically?
>> valuesLocalTransform
has lots of juicy bits. But this doesn’t look very simple. We can’t just
replace an old method with a new one. We also have to write the new one to
tweak how the indices are used in #upTo:, and make sure that new method gets
filed-in as well into the Pharo target image. Or, we have to do this kind of
change manually.
How did you handle conversion to literal arrays conversion and Stream semantic
adjustment?
This bit
(SystemClassChange
className:
#Color
instanceChanges: (Array with: (Add method: #asColorValue code:
#_ph_asColorValue)))
is replacing #asColorValue with #_ph_asColorValue because some special
Pharo-color conversion needs to happen. But how does #_ph_asColorValue get
defined? It’s neither in VW nor in Pharo 10.
Shaping
[…]
How does one generate the source (run the transformation)? Where are the
aforementioned “defined code transformations”, Is there an example of how to
setup the declarative template needed to map VW namespace names to Pharo class
prefixes?
I loaded the following packages into my VW 8.3 image:
Values Project Yes
Values
Values Fileout Pharo
Values Testing
Values Tools
Values Tools Testing Automatic
Load PDFtalk Project bundle. Since the main target is PDFtalk. Values (and
PostScript) are just bycatch.
Pharo Fileout Values No, this package has been renamed to [Pharo Fileout
PDFtalk]. Load this.
Pharo Transform No, not separate. This is part of the Transform Project.
Smalltalk Transform Project Yes
Smalltalk Transform TestBundle
Smalltalk Transform Tests
Smalltalk Transform
Smalltalk Transform Model
Smalltalk Transform Testing
Smalltalk Transform TestPackage
Smalltalk Transform Tools Automatic
Yes, I just loaded the head packages and the dependencies were also loaded.
Thanks for trimming that down for me.
Any package not updated recently (in the last few months) I didn’t load.
Did I miss anything?
Yes. The ideal setup from a virgin image
Ok. I don’t have a virgin image. I have a very non-virgin image, about 27
years of development I’m trying to port to Pharo. I don’t yet have a specific
interest in the PDFtalk, though I do see a need for PDF generation later, and
will probably revisit that. For now, I just want my own stuff to run in Pharo.
is:
Load {Values Project] bundle
Load {PDFtalk Project} bundle
Load {Smalltalk Transform Project} bundle
Load [Pharo Fileout PDFtalk] package
Save, done
Okay, so do I understand correctly that I need to include the PDFtalk stuff
even if I’m not interested in PDFtalk, because that’s where a lot of the
Smalltalk transformation machinery lives? Or is the PDFtalk just being used as
an example for how to do a massive transformation? Or Both?
To transform Values do: “Pharo100 fileOutValues”
The [Pharo Fileout PDFtalk] package includes the latest Values transformations.
I am thinking about a better modularization…
Also, the wiki is a bit out of control. It really needs some restructuring.
In the cites wiki page, there is a link to a blog where I record the changes.
This might be informative.
2. Port the Values package. This is easy, since no namespaces are involved.
This first instruction after VW package setup says to port the contents of the
Values package from VW to Pharo. Do you mean manually? Probably not.
No, no. This has been finished in March.
For each dialect, I have a GitHub repository where I release important
versions: <https://github.com/PortingPDFtalk/PharoPDFtalk>
https://github.com/PortingPDFtalk/PharoPDFtalk. You can find the working port
as first release “
<https://github.com/PortingPDFtalk/PharoPDFtalk/releases/tag/1.3.0.0> Working
version“. There you can download the ported Values fileout with the exact
description with which versions of what it was created.
This should be a good starting example.
Why do I need any new code installed in Pharo before I begin the
transformation, if I’m transforming code from VW to pharo? I’m not
understanding the basic constraints of the problem, even when the detailed
steps are clear.
I’ve done these steps so far:
1. Went to <https://github.com/PortingPDFtalk/PharoPDFtalk>
https://github.com/PortingPDFtalk/PharoPDFtalk.
2. Saved down PDFtalk.Pharo100.st into <my Pharo 10 image
directory>/pharo-local/Smalltalk-Transformation. (I figured that was a good
place to save it. If anyone disagrees, or has a better or more conventional
idea about where files should be saved, please say so. I setup a Pharo Git
repo and played with it briefly for the first time yesterday. I’ve used Pharo
off an on for 16 years, but this is the first time I’m making a serious effort
to manage source, and not throw away what I’m working on.)
3. Filed-in PDFtalk.Pharo100.st. This went on for about 7 minutes or so. I
have a hundreds if not over a thousand classes showing in Epicea. Is there
anyway to get Epicea to give me a count of changes with a time-range filter?
4. Deleted (forgot) yesterday’s, old Main practice-repo from both the image
and the drive, and made a new one. I need to add to Main all the packages I
just filed-in, but I don’t see an efficient way to do that. I would like to
use the Add Package button, but this gives a filtered list of available
packages. I can filter subgroups, and then individually select each of the
checkboxes to the left of each package (there is no Ctrl-A [select all] option
here, which seems to be a strange omission given the potentially large number
of packages involved). I see lots of prefixes for the classes just loaded. I
could easily miss something if I filter/select/add one prefix-group at a time.
Is there an easier way? Over in Epicea I don’t see a way to push the loaded
items listed to a specific repo. The first thought I have is to select all
filed-in code artifacts by datetime span. I did that and saved it as an .ombu
file (I have no idea what that is). I don’t see a way to import that .ombu
file into repo Main’s “Working copy” window. It must be easy, but I don’t see
it. Please suggest the best way.
I feel like I’ve missed the main details of how to start the transformation.
I’d like to do a small fully contained test package with no external
dependencies as a first test, probably my Magnitude or Collection packages.
Suggestions are welcome. Thanks for doing this and sharing it.
If I may suggest, I would look at the transformations on the class side of the
SmalltalkTransform.Pharo class: methods #ValuesProject and #PDFtalkProject (I
know, some would detest, that I start methods sometimes with a capital letter…).
I used to be this way. I’m okay with it now, and actually have selectors that
are completely capitalized Acronyms. Times change.
To get a feel for the machinery, you could debug through “Pharo100
fileOutValues” (for Pharo 10.0).
This will be my next step, but I’m trying to understand the big picture of
dependencies. The file-in was clean. I want to commit that before moving on.
As said, Values don’t use namespaces. To see what is involved there, you could
look at #PDFtalkProject for the name mapping.
But beware! The PDFtalk transformation is not finished yet. Still, you could
get some inspiration and can probably reuse some of the rules.
Great that you are trying to use the transformation project. The more use, the
better it should get.
Please share your questions and insights (and successes :)).
I’ve been looking for a tool like this for many years. Thanks again.
Shaping
From: christian.haider <[email protected]
<mailto:[email protected]> >
Sent: Wednesday, 22 June, 2022 05:42
To: [email protected] <mailto:[email protected]>
Subject: [Pharo-users] [PDFtalk] second fileOut for Squeak and Pharo
With help from the community some issues were fixed which improved the test
statistics nicely.
Check it out:
https://wiki.pdftalk.de/doku.php?id=portingblog#second_pdftalk_fileout_for_squeak_and_pharo
Thanks to everybody involved!
Happy hacking,
Christian
