Archives for category: Uncategorized

It’s been a while since we did a Self release, and although there is a never ending stream of things which should be done and aren’t, I’m moving towards a new release so that our GitHub version isn’t too far out of sync with the last release version.

As part of that preparation process, I’ve fixed up some work Tobias started and have integrated with travis-ci.org.  Every push to the master branch on GitHub now builds and tests four VMs: Linux with GCC, Linux with Clang, macOS with GCC, macOS with Clang.

You’ll be pleased to know that our current status is:

I would like to spur discussion about structure of the project and also about the community, its organization and knowledge bases. I believe that this discussion is really important for the future of Self development.

I’ve spent 26 days reading 26 years of messages from the Self mail conference archive. Here is what I’ve learned. Please note, that everything is highly subjective and may be even wrong. Read the rest of this entry »

I have long maintained that Self is the finest Yak shaving system in existence. Everything is possible and nothing is finished 🙂

So I was playing with building a website front end for the mailing list archives, which led me to improving the Self web server, which led me to making a new experimental stream framework for Self. This also led me to some interesting ideas on automatically checking for methods which should be present in an object but aren’t, but I’ll write about that later!

Self already has a readStream and writeStream prototypes, which are very basic entities modelled largely on Smalltalk-80. They’re mainly used in the context reading and writing to files and sockets.

What I’ve put together is a quick stream framework for putting together pipelines of filters etc and streaming objects through them. The general aim is to avoid the technical and conceptual overhead of copying collections multiple times as you handle them.

This isn’t particularly groundbreaking, lots of other languages do this sort of thing. I’d like to hear suggestions on how to make what I’ve done more elegant and Self-ish.

The code is at https://github.com/russellallen/flow

Basically, streams are entities which understand either readIfFail: or write:IfFail:. Streams can only be read or write.

Flow streams are composable, which means you can link them in a chain with pipeable connectors.

The relevant parts are in the global object ‘flow’.

This isn’t optimised at all – ideally streams should cheat by copying larger chunks behind the scenes where appropriate for performance. Also file streams probably need to be more aware of reading and writing chunks with internal buffers, and string writing should be optimised to reduce copying!

Possible improvements include adding spitting and merging pipes, specific buffering pipes etc.

Using flow streams is a two or three step process:

## 1 Build structure.

| myPipeline |

myPipeline:
'This is a bit of text for us to play with' reading
|= (flow pipeable map copyOn: [|:c| c capitalize])
|= (flow pipeable filter copyOn: [|:c| c isVowel])
|= (flow pipeable gather copyOn: [|:c| (c & c) asList])
|= flow writable string copy.


## 2 Put pipeline into action

myPipeline flush.


## 3 (Optionally) convert your stream into something else

[myPipeline contents = 'IIIIAAIIOOEEOOUUOOAAII'] assert.

And that’s about it. I’ll play with this some more, any suggestions?

## tl;dr

Basic informations here: https://github.com/Bystroushaak/self_mbox Read the rest of this entry »

David Ungar and Harold Ossher’s talk at SPLASH 2013, called “Dancing with Symmetry to Harness the Power of Complexity: Subjective Programming in Context” is now online with slides and video at InfoQ.

David and Harold discuss a new programming language and environment they have been researching which allows to contextual, multidimensional dispatch of messages so that the behaviour of objects depends on the context of the method invocation. They also give a quick demonstration of a development environment they have build to explore these ideas in Self.

Check it out!

Named after the majestic, awe inspiring Anas platyrhynchos, the latest Self release 4.5.0 is now available for download.

What’s new since 4.4?

• Build system redone by Tobias Pape. Now based on cmake, with a single modern build process for both Linux and OS X. The VM can be built on both GCC and Clang on the latest vesions of both operating systems.
• New Self Control.app on OS X to manage your running worlds as a more robust and featured replacement for the older ‘Self Droplet’. Use of this app is optional and you can still access the Self VM through the command line.
• New look for standard world, with better fonts, colours and greater use of space.
• Various fixes to the standard world, including a new build script ‘worldBuilder.self’ replacing several ad hoc build scripts.
• Updated Self Handbook at handbook.selflanguage.org

Sources for the VM and for the basic Self world are available as always from the GitHub repository. Although Self, like Smalltalk80, can use an image (in Self called a snapshot of a world), this can be built from text sources.

Self Mallard is available for OS X and Linux. You can download binaries:

• For OSX, a disk image containing the Self Control.app and a prebuilt clean snapshot (“Clean.snap”). Copy the app to your Applications folder, run it and click the Choose snapshot… button.
• For Linux, a gripped tar file containing a prebuilt 32-bit binary and Clean.snap. Unpack, then run ./Self -s Clean.snap

Following on from his SelfVM build for Android x86, Chris Double has fixed up some bitrot in an old Self application, which allows sharing a Self world through a Java applet (without requiring a X11 server).

Check out his writeup here, including a screencast of how to make it work. His changes have been merged into the Self tree.

Chris Double has announced a build of the Self VM for x86 Android. No GUI yet and only x86:

For several components of Self, it is necessary to have a few bits of assembly. For example, executing a method compiled by the JIT-compiler requires a small stub, named EnterSelf. About 5 % of Self’s codebase is written in assembler, mostly AT&T style.

As you remember, the two main compilers I use to build Self are gcc and clang. Using gcc is no problem, it also has been tested and used for years with Self. However, clang turned out to be troublesome.

## Background: Assembling with gcc

While gcc until 4.2 was a (relatively) cross-platform operating thing, it always relayed on platform-specific assemblers or the GNU assembler gas (or as).

If you happen to use a Linux Distribution, try to run

$as -v </dev/null For the Ubuntu box I use I get GNU assembler version 2.22 (x86_64-linux-gnu) using BFD ↩ version (GNU Binutils for Ubuntu) 2.22  and for the Fedora box it is GNU assembler version 2.22.52.0.1 (x86_64-redhat-linux) ↩ using BFD version version 2.22.52.0.1-10.fc17 20120131 Now go and try it on your Mac. You will get something like Apple Inc version cctools-822, GNU assembler version 1.38 with varying values for the cctools version. The “GNU assembler version”, however, will stay the same: 1.381 You see, there is at least one major version difference between the assemblers. The Apple assembler even isn’t an actual GNU assembler but merely supports the version 1 syntax of GNU as. This divergence has been the case for a long time and in Self’s codebase you find abstractions to cope for exactly these divergences: • On Linux, use syntax features of GNU as v2 • On Mac OS X, use syntax features of GNU as v1 ## Self Assembler Code There is one very important assembly function already mentioned: EnterSelf. This function, besides entering compiled code, has the responsibility to serve as data; to provide references to certain addresses of code in the Self VM2,3: start_exported_function firstSelfFrame_returnPC jmp_label send_desc_end .long 0 jmp_label contNLR // … .long 0 .long 0 .long 0 .long 20 Without going too much into details, the Self VM code expects the 0x14 (the .long 20) at the 26th byte after the label. Now the difficulty: the send_desc_end label follows immediately after the code just given. Hence, most assemblers—when using a normal jmp instruction—will generate a short jump, resulting in our 0x14 being placed at the 23rd instead of the 26th byte. The effect is that our compiled VM crashes as soon as it tries to enter Self compiled code. To alleviate this, the jmp_label macro is defined in a way that the resulting jump is always to a 32bit address. Disregarding a syntax change in Apples assembler around 2007, jmp_label on OS X is a simple jump, which always is handled with 32bit addresses. Original Self New version .macro jmp_label MACRO(jmp_label, label) ↩ // jump to label with four bytes for label jmp$0                       jmp \$0
.endmacro                    ENDMACRO

On Linux, however, we work around the generated “short” jump by introducing a global label, which forces relocation.

Original Self                        New version

.macro jmp_label label               MACRO(jmp_label, label)
.globl \label ↩                    .globl \label ↩
// force 32-bits for the label     // force 32-bits for the label
jmp \label                         jmp \label
.endm                                ENDMACRO

That way, the structure of firstSelfFrame_returnPC is retained on both platforms.

## Clang’s Integrated Assembler

Clang aims to be a drop-in replacement for gcc under nearly any circumstances. It is, however, supported the most by the FreeBSD and Apple communities. And the latter fact seems to leak through.

On OS X, you won’t notice any difference. Using the integrated assembler of clang is just the same as using assembly with gcc. This also holds for the generation of jumps. However, running clang on Linux turns out to be surprising. After some elaboration, it turns out that the internal assembler of clang mimics just the Apple assembler with its GNU as 1.38 compatibility.

The effect of this is that the abstractions in the Self codebase for different assemblers had to be adjusted to differentiate between OS X, Linux with gcc and Linux with clang. Yet, this did not suffice. Our jmp_label macro seemed not to work for firstSelfFrame_returnPC on Linux with clang,

• neither using a simple jmp as on OS X,
• nor forcing the label to be global as on Linux with gcc.

Either way, clang insisted on generating a “short” jump, which is encoded in only two bytes instead of five bytes for the other cases. I tried other different ways of forcing a 32 bit address jump, but to no avail.

## Solution?

In the end, I disabled using the integrated assembler of clang on Linux. clang now—happily?—uses the GNU as of the system as if it were gcc and our jmp_label again encodes to a 32 bit address jump, a five byte instruction.

## Aftermath

Arguably, it is possible to adjust the Self C++ code to not expect the 0x14 at the 26th byte but earlier and then using short jumps. After all, this code still dates from days where SPARC and PPC, and not Intel CPUs, where the main supported platforms within Self. After all, the assembly code in Self is not position independent and Assembly will be an issue once Mac OS X 10.8 is there. But again, this is another story.

1 This holds at least for Xcode 3.2 to Xcode 4.2
2 start_exported_function is an Assembler macro to ensure that a certain label is global and linkable.
3 I did a refactoring of the assembler code in my Self VM fork for better portability. Hence, whenever they diverge, the assembler code is given in two ways, the original form and my “portable” version.