[Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: doing first run soon

2022-08-05 Thread Shaping 
I’ll make my first run soon on my first package. I’ll do one package extra each 
time I run, building up the code.  Each package will have its own Transform method, per the examples.  I’m not sure how to build these 
methods, except to assume that rewriting the pharo base methods is never wrong. 
 I’ll file-in the resulting .st file to see what breaks.   Then I’ll go back to 
the package whose .st source is not loading completely and add additional fixes 
(class keeps, base methods rewrites if needed and missing, method code body 
replacements if needed) to its transform method until it loads completely on 
the next run.  That could take a while.  Is that what you do in practice?  

 

Perfect! That is exactly how I do it.

I start with an empty PackageChange. Then I add incrementally transforms until 
the code loads - phase one. This has been achieved for PDFtalk with the first 
release on GitHub. The second and final phase is to make all tests run 
(including the new to-write tests). This can take a while, because all 
syntactic and semantic differences must be addressed. Here, some 
cross-fertilization is possible.

 

Yeah, and I have to be thorough finally about all my SUnit tests…  

 

The nice thing is, that the system is always telling you what to do. In fact, 
at first there are so many issues that it is a lot of fun to browse them and 
chose a nice one. Always the nicest or easiest bug first :-).

 

Right.

 

I’m assuming the code writer is taking into account inter-package dependencies 
in order to get the load order right.

 

Yes.

 

Shaping

 

 

From: christian.hai...@smalltalked-visuals.com 
  
mailto:christian.hai...@smalltalked-visuals.com> > 
Sent: Friday, 5 August, 2022 05:53
To: 'Any question about pharo is welcome' mailto:pharo-users@lists.pharo.org> >; 'Pharo Development List' 
mailto:pharo-...@lists.pharo.org> >
Subject: [Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: 
pdftalkPackageChanges

 

The full project in which the mentioned method used looks like this:

PDFtalkProject

^ProjectChange

   name: #PDFtalk

   source: ((OrderedCollection new)

   add: (Package name: #Values);

   add: (Bundle name: #PDFtalk);

   add: (Package name: #'Values 
Testing');

   add: (Bundle name: #'PDFtalk 
Testing');

   add: (Package name: #'PDFtalk 
Demonstrations');

   yourself)

   changes: self pdftalkPackageChanges

   nameMapping: (NameMapping

   keep: ((OrderedCollection new)

   add: 
#{Smalltalk.PDF};

   add: 
#{PostScript.PSDictionary};

   add: 
#{PDFtalk.PDFObject};

   add: 
#{PDFtalk.PDFArray};

   add: 
#{PDFtalk.PDFDictionary};

   add: 
#{PDFtalk.PDFStream};

   add: 
#{PDFtalk.PDFString};

   add: 
#{PDFtalk.PDFDate};

   add: 
#{PDFtalk.PDFTypeDefinition};

   add: 
#{PDFtalk.PDFEncoder};

   yourself)

   classToNames: ((Valuemap new)

   add: 
#{SubscriptOutOfBoundsError} -> #Error;

   add: 
#{NonIntegerIndexError} -> #Error;

   add: 
#{NotFoundError} -> #KeyNotFound;

   add: 
#{KeyNotFoundError} -> #KeyNotFound;

   yourself)

   namespaceToPrefixes: ((Valuemap 
new)

   add: 
#{Smalltalk.PostScript} -> 'PS';

   add: 
#{Smalltalk.PDFtalk} -> 'Pt';

   add: 
#{PDFtalk.Fonts} -> 'PtF';

   add: 
#{PDFtalk.Fonts.O

[Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: doing first run soon

2022-08-05 Thread christian.haider 
Von: Shaping  
Gesendet: Freitag, 5. August 2022 15:55
An: 'Any question about pharo is welcome' ; 'Pharo 
Development List' 
Betreff: [Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: doing 
first run soon

 

I’ll make my first run soon on my first package. I’ll do one package extra each 
time I run, building up the code.  Each package will have its own Transform method, per the examples.  I’m not sure how to build these 
methods, except to assume that rewriting the pharo base methods is never wrong. 
 I’ll file-in the resulting .st file to see what breaks.   Then I’ll go back to 
the package whose .st source is not loading completely and add additional fixes 
(class keeps, base methods rewrites if needed and missing, method code body 
replacements if needed) to its transform method until it loads completely on 
the next run.  That could take a while.  Is that what you do in practice?  

 

Perfect! That is exactly how I do it.

I start with an empty PackageChange. Then I add incrementally transforms until 
the code loads - phase one. This has been achieved for PDFtalk with the first 
release on GitHub. The second and final phase is to make all tests run 
(including the new to-write tests). This can take a while, because all 
syntactic and semantic differences must be addressed. Here, some 
cross-fertilization is possible.

 

The nice thing is, that the system is always telling you what to do. In fact, 
at first there are so many issues that it is a lot of fun to browse them and 
chose a nice one. Always the nicest or easiest bug first :-).

 

I’m assuming the code writer is taking into account inter-package dependencies 
in order to get the load order right.

 

Yes.

 

Shaping

 

Christian

 

 

From: christian.hai...@smalltalked-visuals.com 
<mailto:christian.hai...@smalltalked-visuals.com>  
mailto:christian.hai...@smalltalked-visuals.com> > 
Sent: Friday, 5 August, 2022 05:53
To: 'Any question about pharo is welcome' mailto:pharo-users@lists.pharo.org> >; 'Pharo Development List' 
mailto:pharo-...@lists.pharo.org> >
Subject: [Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: 
pdftalkPackageChanges

 

The full project in which the mentioned method used looks like this:

PDFtalkProject

^ProjectChange

   name: #PDFtalk

   source: ((OrderedCollection new)

   add: (Package name: #Values);

   add: (Bundle name: #PDFtalk);

   add: (Package name: #'Values 
Testing');

   add: (Bundle name: #'PDFtalk 
Testing');

   add: (Package name: #'PDFtalk 
Demonstrations');

   yourself)

   changes: self pdftalkPackageChanges

   nameMapping: (NameMapping

   keep: ((OrderedCollection new)

   add: 
#{Smalltalk.PDF};

   add: 
#{PostScript.PSDictionary};

   add: 
#{PDFtalk.PDFObject};

   add: 
#{PDFtalk.PDFArray};

   add: 
#{PDFtalk.PDFDictionary};

   add: 
#{PDFtalk.PDFStream};

   add: 
#{PDFtalk.PDFString};

   add: 
#{PDFtalk.PDFDate};

   add: 
#{PDFtalk.PDFTypeDefinition};

   add: 
#{PDFtalk.PDFEncoder};

   yourself)

   classToNames: ((Valuemap new)

   add: 
#{SubscriptOutOfBoundsError} -> #Error;

   add: 
#{NonIntegerIndexError} -> #Error;

   add: 
#{NotFoundError} -> #KeyNotFound;

   add: 
#{KeyNotFoundError} -> #KeyNotFound;

   yourself)

   namespaceToPrefixes: ((Valuemap 
new)

   add: 
#{Smalltalk.PostScript}

[Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: doing first run soon

2022-08-05 Thread Shaping 
I’ll make my first run soon on my first package. I’ll do one package extra each 
time I run, building up the code.  Each package will have its own Transform method, per the examples.  I’m not sure how to build these 
methods, except to assume that rewriting the pharo base methods is never wrong. 
 I’ll file-in the resulting .st file to see what breaks.   Then I’ll go back to 
the package whose .st source is not loading completely and add additional fixes 
(class keeps, base methods rewrites if needed and missing, method code body 
replacements if needed) to its transform method until it loads completely on 
the next run.  That could take a while.  Is that what you do in practice?  

 

I’m assuming the code writer is taking into account inter-package dependencies 
in order to get the load order right.

 

 

Shaping

 

From: christian.hai...@smalltalked-visuals.com 
 
Sent: Friday, 5 August, 2022 05:53
To: 'Any question about pharo is welcome' ; 'Pharo 
Development List' 
Subject: [Pharo-users] Re: [Pharo-users]Porting from VW 8.3 to Pharo: 
pdftalkPackageChanges

 

The full project in which the mentioned method used looks like this:

PDFtalkProject

^ProjectChange

   name: #PDFtalk

   source: ((OrderedCollection new)

   add: (Package name: #Values);

   add: (Bundle name: #PDFtalk);

   add: (Package name: #'Values 
Testing');

   add: (Bundle name: #'PDFtalk 
Testing');

   add: (Package name: #'PDFtalk 
Demonstrations');

   yourself)

   changes: self pdftalkPackageChanges

   nameMapping: (NameMapping

   keep: ((OrderedCollection new)

   add: 
#{Smalltalk.PDF};

   add: 
#{PostScript.PSDictionary};

   add: 
#{PDFtalk.PDFObject};

   add: 
#{PDFtalk.PDFArray};

   add: 
#{PDFtalk.PDFDictionary};

   add: 
#{PDFtalk.PDFStream};

   add: 
#{PDFtalk.PDFString};

   add: 
#{PDFtalk.PDFDate};

   add: 
#{PDFtalk.PDFTypeDefinition};

   add: 
#{PDFtalk.PDFEncoder};

   yourself)

   classToNames: ((Valuemap new)

   add: 
#{SubscriptOutOfBoundsError} -> #Error;

   add: 
#{NonIntegerIndexError} -> #Error;

   add: 
#{NotFoundError} -> #KeyNotFound;

   add: 
#{KeyNotFoundError} -> #KeyNotFound;

   yourself)

   namespaceToPrefixes: ((Valuemap 
new)

   add: 
#{Smalltalk.PostScript} -> 'PS';

   add: 
#{Smalltalk.PDFtalk} -> 'Pt';

   add: 
#{PDFtalk.Fonts} -> 'PtF';

   add: 
#{PDFtalk.Fonts.OpenType} -> 'PtOT';

   yourself))

 

In the #source: are the bundles and packages to be transformed. The #changes: 
(your method) specify the transforms (PackageChange) for each package 
explicitly. Only packages contain code and therefore, only packages need the 
code transformations. Bundles are transformed without transformations. (Well, 
the code for pre-, post- whatever blocks are transformed with the class name 
mappings rules).

So, the mapping from packages to the corresponding PackageChange has to be 
stated somehow. Using a dictionary (Valuemap) for this seems also natural. The 
only change I might like is to use pragmas to tag the PackageChange returning 
methods with “their” package like

 or so. Putting the package reference into the 
PackageChange is not a good idea, because all those Objects need to be created 
before your can find out which pac