The Weekly Squeak

Category: Squeak

  • Dynamic messages: a tour of Pepsi

    Ian Piumarta is already known for the efforts on the Unix port of Squeak.
    The last Ian work is Pepsi, a dynamic-compiled language which is promising very well.

    Weekly Squeak has just done some questions to him, and a deep analysis ofPepsi.

    Giorgi:What are exactly Id and Pepsi?

    Piumarta: ‘Id‘ is an object model. It’s the simplest possible model that
    permits an object to receive a message without introducing any early bound assumptions in the mechanisms.
    ‘Pepsi‘ is a generic name for the universe of simple object models and
    languages that can be built directly on top of Id.
    These exist mainly to provide a message-oriented foundation for making object structures in.

    ‘Idst‘ is a Smalltalk-like syntax (and object library) built on Id using
    prototypes rather than [meta]classes. The runtime is entirely
    dynamic but the code compiles to a static (native) executable.

    And now the code!

    I have downloaded the code found in http://piumarta.com/pepsi/

    The source pack has a lot of example.
    With Pepsi, Ian rewrote a pice of Smalltalk library using a prototype-based approach (like Self or IoLanguage).

    There are a lot of concepts, and this article is not going to explore them all.

    These are the major point in my own opinion:

    1. Id provide a compiled executable with dynamic message sending and a Garbage Collector.
      Id is based on Self, and it is able to create “slot” for objects and to attach methods to them.
    2. You can mix C-code and “Id” code in a very simple way. So it is easy to integrate with O.S. services. The idea is quite the opposite of Objective-C: you think in terms of objects all the time (as in SmallTalk).
      Then you “come back” to C-Language for the dirty part of your work.
      I have done some basic stuff using the Java Native Interface (JNI) and the “id compiler” seems to me simpler to use.
    3. Very very very flexible.

    You can find more interesting example like:

    • A port of the Squeak Virtual Machine (sqvm). The VM is able to interpret a “mini” squeak image even if is not very fast.
    • An X11 Integration example
    • Some more complex examples based on Jolt, an implementation of Coke.

    The id compiler (idc) works well under cygwin too, so it seems to me quite independent from the O.S. and the available libraries.

    This approach is far more promising then the interpreted one out of there; more notably, FScript is very nice, but is interpreted and limited to a Cocoa implementation.
    Id instead is still a bit slow, but you can tune it where you need using a snippet of C-code.

    About Giovanni Giorgi
    Born in the 1974, he is working as a professional IT Software Architect from year 2000.
    In the free time he likes doing trip and reading books.
    His blog has some interesting photo about his trips and he uses Smalltalk from 1996

  • CurlPlugin – call for testing

    Danil Osipchuk has created a new version of the CurlPlugin. This is a plugin that wraps the libcurl library, a multiprotocol file transfer library.
    Danil is now looking for people interested in testing his plugin. For this plugin there’s also a bounty offered by Avi Bryant.

  • September team reports

    Every month the various Squeak teams should deliver a report on their activities. For the month of September, the following reports have been sent to the squeak-dev mailing list:

    Updates:

  • Squeak Foundation Board meeting notes – October 4th, 2006

    Craig Latta posted the notes of the Squeak Foundation Board meeting that occured on October 4th. The Squeak Foundation Board meets twice a month via IM on the first and third wednesday, and Craig has been appointed to speak for the board.

  • The NewCompiler project

    The NewCompiler project aims at developing a new compiler to take the place of the one currently in use in the Squeak image. This will bring many advantages: a better integration with the Refactoring Browser subsystem; a cleaner internal structure with better maintainability, and “real” closures that will make the #fixTemps workaround unnecessary.

  • More info on Exupery

    Looks like Exupery is in the spotlight in these days! Many messages ha appeared on the Squeak-dev mailing list asking questions and details about this project. Bryce Kampjes and others provided answers to these questions here, here, and here.

    Also, don’t forget to read to our little Exupery FAQ!

  • Squeak startup process, explained

    In replying to a question on the Beginners mailing list, Yoshiki Ohshima explained the startup process of a Squeak image, from the moment the VM is invoked by the operating system, to the moment the user can start interacting with the Squeak system.

  • Exupery FAQ 1.0

    Giovanni Giorgi has tried Exupery, the Squeak byte compiler written by Bryce Kampjes. Exupery is still in beta but is usable for experimenting.
    The Weekly Squeak is happy to publish a prime-time FAQ on it.

    Introduction
    First of all, the master reference for exupery is the omnipresent wiki.

    I have done a small interview to Bryce Kampjes, and we ended up building an interesting FAQ for Exupery.

    Q: What is Exupery?
    A: Exupery is a native code compiler for Squeak. It translates byte-code into machine code. It can compile most methods which don’t include primitives and a handful of primitives. It is becoming something like a JIT but with the compiler written in Smalltalk. At the moment, it can dynamically inline a handful of primtives but not full methods.

    Q: Exupery is not only a “Just in time compiler” (JIT) as we will see in the next few answers. What does “Exupery” means?
    A: It’s named after a French author and early aviator.

    Q: I have installed if from SqueakMap. How can I use it?
    A: Instructions in the wiki pages above. But you’ll need a custom VM. I’ve had to modify the VM so it’ll jump into the native code from interpreted code. For now you need to manually compile methods.
    In the latest development builds the following is good:

    ExuperyProfiler optimise: [ExuperyBenchmarks new compilerBenchmark].
    Exupery dynamicallyInline.

    The first line profiles the expression in the block then tries to compile the hot spots. The second line inlines any primitives called by compiled code.
    [See this link for the VM]

    Q: Can I compile my class and try it at my own risk?
    Sure.

    Q: Can I compile only some classes?
    Exupery will only ever compile some methods. It’s goal is to compile frequently called methods well producing good code, rather than all methods quickly. You tell it to compile methods rather than classes.

    Q: How much stable is Exupery? Can I use it for my important Flower Collection Blog? (Ok I was just kidding, I haven’t a Flower blog… 😉
    Yes, but it’s still an alpha compiler. Expect bugs and crashes. If you really need to speed up your blog, then compile the critical methods and script compilation. Don’t let Exupery use it’s profiler or any dynamic compiler in production. That should allow you to test it better.For now, if you really want to use it in production explicitly compile the methods that you think will lead to a speed gain then test it. This should reduce the risk of crashes.

    Q: Can I use MessageTally to profile Exupery and compare against interpreted code?
    Not at the moment. The problem is compiled code does not check for interrupts so MessageTally will never see it.To compare use

    Time millisecondsToRun: [...].

    Q: I want to come back! Is it easy?
    You can always stop using Exupery. At any point you can tell it to remove all compiled code from the system. There are VM hooks, but it removes all compiled contexts before saving so it’s always possible to go back to a vanilla VM. If you go back to a vanilla VM you are in exactly the same place you were before you started experimenting with Exupery (besides having a few extra classes in the image).

    Q: I’d like to work on Exupery. Where should I start?
    Q: Join the exupery mailing list and ask for things to work on. Say what you’re interested in doing. If you email me, I’ll reply.
    There’s a decent amount of stuff to do. The first thing is probably building an Exupery VM. For most things it helps to have a local build environment both for staying current and for debugging. If you’re just working on in-image stuff, say the profiler or testing then you could live with pre-compiled VMs. But if you want to work on new primitives or features then you’ll need to be able to debug. At a minimum that involves recompiling VMs to add logging.
    I can only supply Linux VM’s. If you’re running another OS, then you’ll need to build your own or get one from someone else.

    Final words
    We thank a lot Bryce Kampjes for the rapid reply. We hope this FAQ will help Squeak fan to try Exupery. That said, your comments are welcome: please ask more question so that we can enhance this document.
    We feel that Exupery is a very interesting project, and can attract many developers because of the performance gain.

  • A call for suggestions for the Foundation Board meetings’ agenda items

    Craig Latta has setup a page on Squeak People in order to gather agenda items for the biweekly IM meetings of the Squeak Foundation board. Anyone interested in suggesting an item may do so by leaving a comment to Craig’s article.

  • Spoon progress report – October 3rd 2006

    Craig Latta posted a new progress report on his Spoon project, which aims to create a minimal live system based on Squeak.
    Craig announces that in his quest for getting a really minimal system, he managed to remove the SystemDictionary class, a class that plays a fundamental role in a standard Squeak (and Smalltalk system).