It's been pretty quiet on this list, so I thought I'd start a
conversation to see if the list is working. Anyone doing any
interesting Self work?
I sidelined my VNC client in Self for a bit due to getting busy in my
day job but plan to get back to it soon and finish it off. It's pretty
close. The missing part is mostly key handling.
I'd like to tidy up my Android patches too and get them submitted so
at least Intel android would work out of the box.
What do people feel would make Self more viable as a fun project to hack on?
While I'm on a roll, the 'transporter-trees' branch of github.com/russellallen/self now has some changes to the modules/transporter code which adds the ability for modules to check their environment before fileIn with a preFileIn method, and gives them a 'tree' slot which allows multiple tree roots for source code.
Please checkout and let me know if anything breaks and if you think we should do this some other way.
Also feel free to improve on the minimum viable documentation below.
By default, the tranporter writes out Self modules out to a tree rooted in the current working directory, or the 'objects' subdirectory of the directory given to the VM in the shell environment variable SELFWORKING_DIR.
Howevever Self modules have a slot 'tree' which can take a name of a tree. If the name of the tree is not an empty string, then the module writer will look up a directory in the dictionary found at ``modules init treeDictionary``.
This allows the developer to maintain several separate trees. For example::
modules init registerTree: 'webserver' At: '/Users/username/webserver'.
bootstrap read: 'webserver' From: 'applications' InTree: 'webserver'.
modules webserver fileOut.
Each transporter module has a slot named ``revision`` containing a string version number. It is recommended that you use Semantic Versioning [#f10]_ so that the version of a module can be tested as follows::
modules string version < (modules init moduleVersion copyOn: '1.0.0')
ifTrue: [log warning: 'Old string version']
This test could be placed in the ``preFileIn`` slot of your module to ensure a sane file in environment before the rest of the file is read.
I needed a simple logging framework for the webserver - there is a bunch of partial ‘warning:’ ‘error:’ etc methods spread about the image but mostly they just print raw strings to stdout. I’ve written a very simple one which allows for pluggable handlers. It’s currently in the ‘logging’ branch on github.com/russellallen/self <http://github.com/russellallen/self>
Below is the, um, somewhat minimal documentation.
If you want to look at it, checkout the logging branch, then build a new snapshot. Then have a look at the ‘log’ slot of globals.
Any feedback would be great. If people think this is a good idea I’d like to merge it (or something like it) into the main branch for the next release.
``log`` is a useful system-wide logging mechanism. You can find it in the ``system`` category of ``globals``.
How to log
There are a number of useful messages in the ``logging`` category of ``log`` which allow you to simply and cleanly log messages. For example::
log warn: 'This is a warning.'
You can log with one of five levels found at ``log levels``. These are, in order of severity, ``debug``, ``info``, ``warn``, ``error``, ``fatal``.
You can also tag log entries, for example::
log fatal: 'The server has caught fire' For: 'webserver'
By default, entries of either error or fatal severity which aren't tagged are logged to stderr in the form::
[Thu Oct 23 16:25:07 2014] error -- Something went wrong!
How logging works
The helper methods shown above constuct a ``log entry`` and hand it to the ``log dispatcher``. The dispatcher has a number of handlers, each is given a chance to handle the log entry. The handlers can choose which entries to act on. Example handlers are in ``log prototypeHandlers``.
When making a handler, please keep in mind that the log entry's ``message`` is expected to be something which understands ``value``, returning an object (or itself) which understands ``asString``. If you do not need to resolve the message by sending it ``value`` please don't; that way logs can be sent blocks which are only resolved if necessary; eg::
log debug: ['We have reached: ', somethingComplicatedToCalculate]
will not slow down your code if no log handler is interested in handling debuggers.
If your handler breaks the logging process you can restart it by::
log dispatcher hup
I've just pushed a minor update to the Self webserver code to github.com/russellallen/self-webserver
Apart from some refactoring, the code now handles methods other than GET and HEAD, so shouldn't be as liable to failure.
Also, more experimentally, requests to servlets are unceremoniously killed if they haven't returned an answer in 30 seconds. Does this sound like a good idea? Should it be longer? Shorter? The aim is to stop broken processes clogging up the system.
I've created a pull request for a couple of minor fixes to the web browser code:
One is a typo in calling a method to create a JPEG image. The other is
for handling hex entities in HTML pages. The latter can be
demonstrated by running the following:
bootstrap read: 'webBrowser' From: 'applications/webBrowser'
'http://bluishcoder.co.nz/index.html' asURL getPageForUser
This will load a page containing entities in hex format. The page
gives an error without this commit. With this commit it loads further
with one unrelated error later on due to not identifying an image.