[Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: Pharo100 fileOutValues
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 th
[Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: Pharo100 fileOutValues
Hi Shaping,
Ha, lots of good questions – nice.
I’ll try to answer both emals inline, so, don’t stop after the first :) ).
Von: Shaping
Gesendet: Donnerstag, 4. August 2022 12:01
An: 'Any question about pharo is welcome' ; 'Pharo
Development List'
Betreff: [Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: Pharo100
fileOutValues
Hi Christian. (You can find some other discussion of this in Discord with
Yanni and others.)
I will look, although this kind of always available on demand thing is too
disruptive for me…
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)
Exactly
but for my own packages. No bundles are transformed (just their contained
packages) because Pharo doesn’t have bundles.
Is that right?
No, bundles are handled. For real examples, you need to look at the PDFtalk
transforms.
Yes, Pharo does not have a concept of bundles (ordered aggregates of packages).
Instead it relies on a naming convention for packages. That convention is
honored in the fileout, so that packages will be partly grouped in Pharo
according to the category prefix.
For each VW-package, one Pharo package is created. A bundle itself is also
represented as Pharo package with one class About with class
methods for the metadata of the bundle, including a method giving you the
ordered list of component packages. So, all contents and metadata of packages
and bundles are transformed for Pharo. No code or info gets lost.
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.
Yes, this method returns a PackageChange Value describing the transformations
needed to create the Pharo fileout for this specific package (inspect the
return value for the fully expanded Value). Methods exist with the same name
for other Smalltalks. Depending on the dialect (or version of a dialect), the
transforms are different. Squeak and Pharo are quite similar, because they
share a common history, but VA or Gemstone need quite different transforms.
So, in general, for each package, there is one such method/Value for each
target Smalltalk/version. I do not dare to extract commonalities before the
machinery is really robust and stable. For now everything is neatly separate
and self-contained (and probably it will stay that way, although there are lots
of duplications).
The mapping of class names is the responsibility of the enclosing ProjectChange
Value where you define the list of source bundles/packages to transform, the
PackageChanges for all packages and the mapping of “global” names.
(The bridge classes above are no renames, but a subclass relationship (is-a) to
avoid renamings. The new class Timestamp will be created as subclass of
DateAndTime which has almost the same semantics. Therefore, I can still use
Timestamp which will be basically a DateAndTime now.)
There is still a technical challenge here. Currently, a ProjectChange need to
include all prerequisites (Values is part of the PDFtalk project and will be
transformed with it). A ProjectWriter, which coordinates the transform, keeps
track of the mappings when they are create
[Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: Pharo100 fileOutValues
I will look, although this kind of always available on demand thing is too
disruptive for me…
I know what you mean. I try be disciplined about it. I really like to be able
to fix typos, because there are almost always typos. But e-mail is okay.
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)
Exactly
but for my own packages. No bundles are transformed (just their contained
packages) because Pharo doesn’t have bundles.
Is that right?
No, bundles are handled. For real examples, you need to look at the PDFtalk
transforms.
Yes, Pharo does not have a concept of bundles (ordered aggregates of packages).
Instead it relies on a naming convention for packages. That convention is
honored in the fileout, so that packages will be partly grouped in Pharo
according to the category prefix.
For each VW-package, one Pharo package is created. A bundle itself is also
represented as Pharo package with one class About with class
methods for the metadata of the bundle, including a method giving you the
ordered list of component packages. So, all contents and metadata of packages
and bundles are transformed for Pharo. No code or info gets lost.
Okay.
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 Timestamp to DateAndTime.
Yes, this method returns a PackageChange Value describing the transformations
needed to create the Pharo fileout for this specific package (inspect the
return value for the fully expanded Value). Methods exist with the same name
for other Smalltalks. Depending on the dialect (or version of a dialect), the
transforms are different. Squeak and Pharo are quite similar, because they
share a common history, but VA or Gemstone need quite different transforms.
So, in general, for each package, there is one such method/Value for each
target Smalltalk/version.
Okay.
I do not dare to extract commonalities before the machinery is really robust
and stable. For now everything is neatly separate and self-contained (and
probably it will stay that way, although there are lots of duplications).
The mapping of class names is the responsibility of the enclosing ProjectChange
Value where you define the list of source bundles/packages to transform, the
PackageChanges for all packages and the mapping of “global” names.
(The bridge classes above are no renames, but a subclass relationship (is-a) to
avoid renamings. The new class Timestamp will be created as subclass of
DateAndTime which has almost the same semantics. Therefore, I can still use
Timestamp which will be basically a DateAndTime now.)
Okay.
There is still a technical challenge here. Currently, a ProjectChange need to
include all prerequisites (Values is part of the PDFtalk project and will be
transformed with it). A ProjectWriter, which coordinates the transform, keeps
track of the mappings when they are created (either explicitly or through a
namespace renaming – see implementers of #PDFtalkProject).
I would like to have this more modular: the mappings from the Values
transformation should be persistently saved, so that other transformation
projects can just use them, instead of including the sources into one own
project.
For this, I need to have renamings local to a package (where they first occur),
not
[Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: pdftalkPackageChanges
This method pdftalkPackageChanges ^(Valuemap new) add: 'Values' -> self ValuesTransform; add: 'PostScript' -> self PostScriptTransform; add: 'PDFtalk Basics' -> self PDFtalkBasicsTransform; add: 'PDFtalk Typing' -> self PDFtalkTypingTransform; add: 'PDFtalk Basic Objects' -> self PDFtalkBasicObjectsTransform; add: 'PDFtalk Streams' -> self PDFtalkStreamsTransform; add: 'PDFtalk Data Structures' -> self PDFtalkDataStructuresTransform; add: 'PDFtalk Parsing' -> self PDFtalkParsingTransform; add: 'PDFtalk Colour' -> self PDFtalkColourTransform; add: 'PostScript Fonts' -> self PostScriptFontsTransform; add: 'PostScript CIDInit' -> self PostScriptCIDInitTransform; add: 'PDFtalk Fonts Basics' -> self PDFtalkFontsBasicsTransform; add: 'PDFtalk Fonts Type1' -> self PDFtalkFontsType1Transform; add: 'PDFtalk Fonts OpenType' -> self PDFtalkFontsOpenTypeTransform; add: 'PDFtalk Fonts' -> self PDFtalkFontsTransform; add: 'PDFtalk Graphics' -> self PDFtalkGraphicsTransform; add: 'PDFtalk Graphics Operations' -> self PDFtalkGraphicsOperationsTransform; add: 'PDFtalk XObjects' -> self PDFtalkXObjectsTransform; add: 'PDFtalk Images' -> self PDFtalkImagesTransform; add: 'PDFtalk Files' -> self PDFtalkFilesTransform; add: 'PDFtalk Document' -> self PDFtalkDocumentTransform; add: 'PDFtalk Rendering' -> self PDFtalkRenderingTransform; add: 'PDFtalk Shading' -> self PDFtalkShadingTransform; add: 'PDFtalk Interactive Features' -> self PDFtalkInteractiveFeaturesTransform; add: 'PDFtalk Deploying' -> self PDFtalkDeployingTransform; add: 'Values Testing' -> self ValuesTestingTransform; add: 'PDFtalk test resources' -> self PDFtalkTestResourcesTransform; add: 'PostScript Testing' -> self PostScriptTestingTransform; add: 'PostScript CIDInit Testing' -> self PostScriptCIDInitTestingTransform; add: 'PDFtalk Fonts tests' -> self PDFtalkFontsTestsTransform; add: 'PDFtalk tests' -> self PDFtalkTestsTransform; add: 'PDFtalk Demonstrations' -> self PDFtalkDemonstrationsTransform; yourself effectively looks like the head transform structure for a project, in this case all the PDFtalk stuff, which includes Values and Postscript. This is not exactly a bundle idea, is it? It’s project spread across potentially many bundles and packages. I’ll start coding my transform with a similar method, and work down toward the details. Takes a bit to get used to all the correct, yet dangling VW methods that are useless in VW, but which will become new code in the target image and there no longer appear to be dangling (with syntax highlighting aberrations). Odd looking but completely by design. Shaping From: Shaping Sent: Thursday, 4 August, 2022 19:18 To: 'Any question about pharo is welcome' Subject: [Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: Pharo100 fileOutValues I will look, although this kind of always available on demand thing is too disruptive for me… I know what you mean. I try be disciplined about it. I really like to be able to fix typos, because there are almost always typos. But e-mail is okay. 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) Exactly but for my own packages. No bundles are transformed (just their contained packages) because Pharo doesn’t have bundles. Is that right? No, bundles are handled. For real examples, you need to look at the PDFtalk transforms. Yes,
