Category: Development

  • Process Woes

    Since the beginning of the month there’s been a recurring theme on the squeak-dev mailing list regarding Squeak’s development process.
    The discussions started with a message from Goran Krampe about the evolution of Squeak’s development process and how to have a more community-oriented process. Many squeakers replied to this message; this response from Ken Causey is just one of the many.
    More recently, Stephane Ducasse published a possible feature roadmap for Squeak 3.10/4.0 (with comments by Andreas Raab), while Giovanni Corriga sent a proposal for a 3.10 developement process.

  • 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:

  • 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!

  • 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 Simple Squeak testing server

    Pavel Krivanek posted to the Squeak-dev mailing list the code for a simple test server implementation, to automate running of the Squeak SUnit tests.

  • Cryptography On The Move

    The Cryptography Team released the first version of Squeak SSL!  http://lists.squeakfoundation.org/pipermail/announcements/2006-October/000050.html .  There is still much to be done, but it’s nice to see the team on the move.  Come join the team http://lists.squeakfoundation.org/mailman/listinfo/cryptography .

    The code can be found at www.squeaksource.com/Cryptography .   Special thanks to everyone that helped make this possible and espically Rob Withers for pulling it all together.  Rob’s code is really beautiful.

    There is still plenty of work to be done so please stop by and volenteer to help!

    Ron Teitelbaum * Cryptography Team Leader

  • Squeak Documentation Team forming

    Matthew Fulmer has announced the creation of a Documentation Team. The purpose of this new team will be the production and mantainance of Squeak releated documentation: tutorials, references and the like.
    The team will start by compiling an index of the existing documentation, and by starting a Squeak developer tutorial.

    We’d like to wish Matthew and the other team members a good work!