FFI Load Failure

When Agile Artificial Intelligence was published as a book I was so excited to pick up a copy. I was quite surprised to see my name in the acknowledgements even though I had only contributed a few suggestions.

One of the interesting examples in the book is using FFI (Foreign Function Interface) to utilize C for matrix operations. This was something new to me, but I was disappointed to see that the MMAtrixTest fail with the error:

Error: External module not found

I moved matrix.dylib to several different directories including the bin and MacOS/Plugins but nothing worked. Testing the same code on RedHat Linux was successful, but not not as enjoyable as working on the Mac. Finally I tried installing Pharo 8 again (upgrading from vers. 68021 to vers. 6521), and the code was suddenly successful. It seems that using Pharo Launcher would be a good practice.

Posted by John Borden at 18 July 2020, 2:42 pm link

Missing Favicon

The file favicon.ico is a file that appears as an icon for the webpage. This file can generally be found in the root director - for example: https://www.google.com/favicon.ico is a G representing Google, likewise a lighthouse for pharo.org:

Server Alias
The favicon can either be found in the root directory (like the google example), or as a link listed in the page header.

For Pier 5 and older, one would login as root and open setting at the root page, choose the file in 'Shortcut Icon:'. For Seaside 3.2 pages have the following in the header:

<link rel="shortcut icon" type="image/png" href="/pier?_s=fe-YRIO0hdXYmPie"/>

Loading the same icon and setting up accordingly in a newer version has the source:

<link rel="shortcut icon" type="image/png" href="/pier?_s="/>

This does not display the icon correctly.

If NGinX is running in front of Pier, then it can be setup with the following work-around in the config file:

 location = /favicon.ico {
   alias /data/static/favicon.ico;
Posted by John Borden at 1 June 2020, 2:54 am with tags Pier link

Complete Task in List of Changes

Currently, when one clicks Changes for a ToDo list, it raises an error. The Changes view shows a logged-in user what has been updated, but clicking on a completed task brings up an error:

Unable to open 'Complete' in the current context

This should do something else. If a task is opened and a user clicks changes, it displays the editor on that task.

This is due to the following code:

	^ (super isValidIn: aContext) and: [ aContext structure isRoot not and: [ aContext structure parent isToDo ] ]

One reason the code is written this way is so the Complete option only shows up on the menu when a task is open - it doesn't make sense to "complete" the Syntax page. The menu is the gray text at the bottom of this page, or in the left pane of the default install:

Complete in bold for a task
The code related to this is:

isValidIn: aContext
	^ (super isValidIn: aContext)
		and: [ aContext command class = self
				or: [ aContext command isView
						and: [ aContext command viewComponentClass isNotNil
								and: [ aContext command viewComponentClass = PRChangesView ] ] ] ]

The scenarios that this handles are:

  • When viewing or editing a page which is not a task or todo option, the Complete menu option should not show up
  • When opening the changes view from a page that contains some child which is a ToDo Task, any time the task was completed should be listed, and clicking on the open link should access that page
  • The Complete menu option is only available when viewing a complete history item, it opens the normal pier page editor

The tests for equality make adding a subclass of PRCompleteToDoTaskCommand more difficult than necessary, but this code is sufficient to create a non-abstract test. This allows adding:

	^ false
	^ self viewComponentClass isNotNil
		and: [ self viewComponentClass = PRChangesView ]
	^ true

Then #isValidIn: can ask aContext's command if it should be displayed instead of performing checks itself.

Posted by John Borden at 26 April 2020, 10:31 pm with tags Pier link

Missing Parser in Pharo 8

Loading Pier 3.2 in Pharo 8 fails with the error:

This package depends on the following classes:
You must resolve these dependencies before you will be able to load these definitions:

The problem is clear from the code:

SPHighlightedCode>>rangesFor: aString
	"Try to find out if this is a method, maybe with a class declaration. Otherwise parse as expression."
	| parser index string |
	parser := SHParserST80 new.
	parser classOrMetaClass: classOrMetaClass.

This is found in the NECompletion package, which is loaded in BaselineOfBasicTools & BaselineOfIDE.

The shout package is used for code blocks like this (taken from Pillar docs):

[[[label=script1|caption=My script that works|language=smalltalk
self foo bar

Unfortunately these square brackets haven't worked in Pier since before Pharo 5. Removing the shout package seems like a logical choice.

A second problem is the load order for the Seaside and Grease. For Pharo 7 it can be loaded in either order, but for Pharo 8 if conflicts are ignored, or #onConflictUseIncoming is used, then http://localhost:8080 brings up the error:

Internal Error: BlockClosure>> #fixCallbackTemps

Using #onConflictUseLoaded resolves this problem.

Posted by John Borden at 26 March 2020, 12:02 pm with tags Pharo, pier link

Teapot Tutorial

While working through the Teapot tutorial in Chapter 1 & 2 of Enterprise Pharo, everything worked well locally. When installing on the Digital Ocean virtual server, a library issue popped up due to 32bit Pharo:

root@ubuntu-s-1vcpu-1gb-nyc1-01:~# ./pharo Pharo.image printVersion
Error. Could not determine platform's libc path for VM.
Try forcing $PLATFORMLIBDIR in /root/pharo-vm/pharo, based on LIBC_SO.
Please report what works to pharo [vm-dev] mail list.
  System seems to be 64 bit. You may need to (re)install the 32-bit libraries.
root@ubuntu-s-1vcpu-1gb-nyc1-01:~# apt install pharo6-32-ui pharo6-64-ui
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: The repository 'http://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/xUbuntu_16.04 ./ Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Installing the 64bit of Pharo 8 worked well, similar to what was done for the example Pier install.

Posted by John Borden at 20 March 2020, 2:15 am link
<< 1 2 3 4 5 6 7 8 9 10 >>