Several weeks ago, loading Pier in a Pharo 10 image would fail with an error:
Warning: Package *Pier-Seaside depends on the following classes: GRPharoZnUtf8CodecStream You must resolve ...
Since then, someone has resolved the issue and it cleanly loads. It may have been a change to a project that Pier depends. Below are a list of recent changes merged into the main Pier branch:
- Loading
PRValueLink>>#redirectIn: raised errors because it sent #fromString: to PRLink. No similar classes implement this so it was replaced with #fromReference: - Pier Scheduled Tasks that have syntax errors can cause the whole webserver to crash, for example:
PRScheduledTaskExamples newForKernelNamed: 'Pier') reportOfHistoryOnPageAt: '/example/line/should/begin/with/an/open/paran/Report'.
adding this message allows it to be ignored instead:
class compiler failBlock: [ :ignore | ]
- Improve wiki search - the previous version would begin the search results page with:
Your search for "..." - this could instead explain what the search was executed as, like: searching for "-bad good" excludes "bad" but includes "good"; it could be displayed as: NOT bad AND GOOD - Updated web scraping to reduce timeouts.
- Updated
workouts: so a test passes (replaced collectAll: with add:/addAll:).
If you loaded Pier into a Pharo image after September, 2022, then it would likely bring up the following error when editing the settings:
Add: Input is conflicting with concurrent modification
Tracing into this error, the cause is found in this Magritte commit, the error is in MACheckedMemento>>reset. Older code had:
self setOriginal: self pullRaw
The newer code has:
self setOriginal: (self pullRawTransforming: [ :e | e copy ])
When you click save, Magritte checks that the original in the memento matches the original model. For the PRPage in the environment field, the style sheet is a PRFile. The check fails since the memento contains a copy, not the original PRFile.
The Pier project is better off if it stays up-to-date with the projects that it depends on like Pillar and Magritte. The solution chosen to resolve this is to redefine the equals method so it is true for structures and their copies. The message #hash is related to equals, and is also redefined.
For making backups, it is a common problem to copy a large tar file from one machine to another in the same network. Normally I would use commands like:
SourceServer> ncat -l --send-only 1701 < backup.tgz
DestinClient> ncat SourceServer 1701 > backup.tgz
Then compare the checksums:
DestinClient> cksum backup.tgz
This is taken from the NMap group. Recently a problem came up where the client did not have ncat, I thought to use Pharo instead so the client code is below (lifted from the SocketStream class comment):
| file socketStream result blocksize writeStream |
blocksize := 1024.
file := File openForWriteFileNamed: 'backup.tgz'.
[
socketStream := SocketStream openConnectionToHostNamed: '127.0.0.1' port: 1701.
[ [ socketStream binary.
[ socketStream atEnd ] whileFalse: [
result := socketStream next: blocksize.
file nextPutAll: result ] ]
ensure: [ socketStream close ] ]
on: ConnectionTimedOut
do: [:ex | Transcript show: ex asString; cr. ex resume]
] ensure: [ file close ]
The address '127.0.0.1' needs to be changed to the IP where the ncat listener is already running once local testing is done.
With the Pharo project progressing as it has, it is necessary to load Pier on Pharo 9. This should also help to Retrieve HTTPS from Pharo.
A good introduction to baselines is on Github.
Pier work started with a separate baseline for core, add-ons, to-do, google, etc. This matched the setup on the previous code repository - Smalltalkhub. Problems would occur when loading the larger projects, the package dependencies are:
PierAddons -requires-> PierCore -requires-> Pillar
When everything cleanly loads, things work well. Recently Pillar loads with with dirty package (internal code is updated), so after loading PierCore, Pillar is attempted to reload when loading PierAddons. This causes the load time to drag on for an hour.
Another recent problem is that the tests would not load due to missing the core class PRObjectTest from the Pillar-Tests-Core package.
To bypass these problems, it was easier to create a large Pier baseline, which has labels for each of the possible parts - addons, todo, etc.
One way to test faster is create the BaselineOfPier class in the image and load it without writing to the repository.
Suppose one has a wiki page for a project, named Smallwiki. Sub-pages can be added and link back to the main page with the text *..*. If the project changes name to Pier, then a single page can have the title changed and all of the sub-pages have the correct name.
An example of a parent link for this page is *..* which goes to Updates, and *../..* goes to John Borden.
A problem occurs when reading in a wiki during an upgrade. Each page is read as an independent entity with no reference to the other pages. A link to a parent like *..* is changed to *.*. This is the expected behavior when editing the root page.
One option is to link to the parent/grandparents/etc to be fully qualified before exporting:
(PRKernel instanceNamed: 'pier') root enumerator all; do: [ :page | page outgoingReferences do: [ :link | (link isInternal and: [ link target ~~ page and: [ page parents includes: link target ] ]) ifTrue: [ link reference: link target absolutePath ] ] ].
If one is not importing into the latest Pier code, this can convert back to relative links with:
(PRKernel instanceNamed: 'pier') root enumerator all; do: [ :page | page outgoingReferences do: [ :link | (link isInternal and: [ (link reference first = $/) and: [ page parents includes: link target ]]) ifTrue: [ link reference: (page relativePathTo: link target) ] ] ].