Category: Squeak

  • Minnow Wiki

    So what’s going on with Minnow WIKI? http://tinyurl.com/tbyz5

    It’s moving? It’s changing? It’s staying the same? See if you can follow the tread.

  • Call for release team volunteers

    The Squeak Foundation board has issued a call for volunteers to create a release team to guide the development of the next version of Squeak, following the guidelines set up during the last board meeting.

    The board is
    […] looking for people who have available time, the diligence to complete a release, and a good degree of mutual trust with the community. If you’d like to volunteer, please do so here! If you have someone else in mind, please contact them privately and encourage them to volunteer.

  • Squeak Foundation Board meeting notes – October 18th, 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.

    During yesterday’s meeting the following items were discussed:

    1. Squeak License: Yoshiki Ohshima mentioned that Viewpoints plans to contact a lawyer, produce a template of the new Apache-style license agreement that OLPC will use, work with the board to complete the Squeak contributor list, and act as keepers of the license agreement.
    2. Squeak 3.10: The board decided to appoint a release team for Squeak 3.10 development. The team will consist of three persons who will act mainly as integrators and avoid direct development. They can still contribute to the development effort, but such contributions will be outside the scope of the release team’s mission. They will also act as coordinators in order to solve possible conflicting contributions.
    3. Georgia Tech’s Squeak wiki: since Georgia Tech plans the retirement of the current swiki server, the Squeak wiki contents will have to be migrated to a community managed server. The board discussed possible line of actions.

    The board welcomes suggestions on possible agenda items for their meetings.

  • Squeak: toy or instrument?

    A message by Giuseppe Luigi Punzi sparked an interesting “philosophical” discussion on the nature of Squeak.

    Giuseppe remarks that for many developers who work with other languages, Squeak looks like a children toy with no serious applications built with it.

    To this Matthew Fulmer replied:

    Squeak is a toy. That is a good thing.

    Squeak is a toy, and therefore it looks like a toy. Aversion to
    toys is (in my not-so-humble opinion) the worst thing that is
    taught to programmers (adults?) today. Playing is the only way
    to make new ideas. One must enjoy playing before they can
    understand the purpose of Squeak. Until they realize “Squeak is
    a Toy, and I am OK with that”, they are missing the point. A
    clean object memory, simple syntax, and easy debugging are just
    implementation issues. The point of Squeak is to have fun
    building; after that, everything else falls into place.

    .

    This caused a follow up by Alan Kay, that wrote:

    The “other” kind of thing that “can be played with” is an
    “instrument” (musical, wood or metal shaping, etc.). Instruments are
    partly “mess around toys” and partly “serious toys”. And Art enters
    in when one starts to play on an instrument and around with an
    instrument. Dan and I had this in mind when we designed and built Smalltalk.

    Other Squeakers, both old and new, gave their contribution to the discussion.

    So, what do you think?

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

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