Author: daitangio

  • Is Javascript the SmallTalk 2012?

    There is a lot of hype surrounding JavaScript.

    Years ago Google started the developing of V8, a super Just in time compiler for its Chrome Browser.

    The V8 compiler revamped competition: Microsoft and Mozilla foundation strike back optimizing their JavaScript interpreters.

    On these days, a strong community is growing using Node.js, a web server “Evented I/O [Web application server] for V8 JavaScript“. Node.js sposts a non-blocking architecture which can lead to very fast server, able to process a lot of request with a single thread.

    A quick peek on the people now. Lars Bak is the leader of the V8 project. It has worked on the design of Self and on the HotSpot JIT.  Lars Bak also co authored “Mixin in StrongTalk”.

    So a lot of the optimization which let  Smalltalk and Java shine, are used in the JavaScript field nowadays. It is a simple “accident” 🙂 ?…or it is destiny?

    JavaScript rocks? There is plenty of documentation all around, even if the first ECMA specification was quite unreadable in my humble opinion 🙂 There are some optimal guidelines for JavaScript module writing, for instance see the manuals on JQuery plugin development. But in JavaScript you are still a free player if you wish: no rule, no even need of structuring your code in some way:

    var sith={}

    sith.name=”DarthVader”;

    sith.name=function(){
    return “Nevermind, I am a function, now”;
    }

    The code above builds a very generic object, and add to it properties (which could be a function).

    Worst, you get very strange things, evaluting:

    [1,2]+[3,4]

    you got:

    “1,23,4”

    This because “+” is not supported for arrays, so the JavaScript  language is effectively doing…

    ([1,2]+””)+[3,4]

    I like dynamic languages like Self, but this is somewhat too…flexible 🙂

    And last but not least JavaScript lacks a true integrated developement environment, even if here we smalltalkers could help a bit 🙂

    So, SmallTalk2012 is not this version of JavaScript, at least not yet; JavaScript Harmony specification is working hard trying to polishing the language…As usual, the better way to predict the future is to …invent it… So let’s give Harmony a chance!

  • Squeak 4.0 is coming…

    On Squeak Mailing list Matthew Fulmer just wrote  (we stressed some lines):

    […]
    Squeak 4.0 is within sight. With this release, the four-year
    relicensing project of the Leadership team will be complete. We
    will be able to incorporate under SFLC, and Pharo will be one
    step closer to a 1.0 release.

    Squeak 4.0 will be the first official squeak release with no
    code under SqueakL; everything in the .image, .changes, and
    .sources files will be under either the MIT license or the
    Apache license.
    […] 

    Are you ready for the Open  Squeak4?

  • Wiki: migrations…

    There is a fair interesting thread on Minnow Wiki Migration, fired on the 18th of October.

    Because Minnow is a very huge wiki, you can find advice and consideration on this topic: the new Pier wiki (which is covered) is fair interesting topic too.

  • Ocean Waves: the applications built on Seaside

    Introduction

    Seaside is a powerful web application framework, which is based on a clean model-view-controller paradigm.

    Seaside frees the programmer to worry about session/request management, and enable also seamless parallel web requests by the same user.
    The Weekly Squeak has already an ad hoc tag for Seaside, and many of us known it.

    For the newbies, is worth to remember Seaside is a bit more comfortable then RubyOnRails, and is based on stack-copying techniques. I have developed quite complex forms in a snap, and its productivity is higher.
    From time to time is good to review the state of this framework.
    So The Weekly Squeak interviewed Avi Brant and some of the most active developers.

    Projects

    QTone

    QTone is a music application written in Seaside. We have interviewed the author, Jay Hardesty.

    Giovanni: How much time need you to develop qtone?

    Jay: The Seaside-based interface was developed for the purpose
    demoing the underlying application, which has a Morphic GUI.
    Writing the Seaside-based code took about two weeks, much of
    which was spent learning the learning Seaside basics. I’ve
    never written a Web-based app before, so I also had to find
    out what http and css were all about.

    (The underlying desktop application has been developed over the
    past three years, and some of the algorithms and design ideas
    go way back to music school days.)

    Do you used a template engine with seaside, or you wrote a bunch of
    code to generate the html page?

    I wrote code to generate html, grabbing snippets from the various
    Seaside axample apps (calculator, alltests, etc.). There are some
    unholy hacks. For instance, I couldn\’t figure out how to rotate
    labels 90 degrees, so those are simply bitmaps rendered in Morphic.
    And there are hot spots all over the place that don\’t belong.
    But again, this was just meant to be a quick and dirty demo of the
    desktop Morphic-based app; it still needs a lot of work, but the
    basic functionality seems to be there.

    Compared to other approach in web development (most notably php),
    how much was easier using seaside in your own opinion?

    I’ve never done Web development before, so I’m not the best
    source for comparisons. I did also create a Java-based Qtone
    applet to run on my cell phone, communicating with the
    same Squeak server application. In that case I needed to do a
    whole client/server implementation, mirroring the state of
    Smalltalk objects by flattening out data and shipping it to
    the Java side via http. Probably there are better ways of
    accomplishing what I did, but in any case it was *much* more
    work than it was to do the Seaside interface (and the phone
    interface is drastically simpler).

    Do you used a database or do you relay on Squeak collections?
    If yes, which?

    I don’t use any database at the moment, other than a Unix directory
    full of MIDI files. In the desktop application there is a Morphic
    GUI built on top of a Qtone object, which is in turn built on a
    large hierarchy of classes that handle the music processing.
    My main Seaside class simply points to the same Qtone object that
    the Morphic application does. All sorts of collection classes
    are used throughout the code, mostly Arrays, OrderedCollections,
    Sets, and custom collections for various music objects such as
    musical notes.

    Your throughts about seaside…?

    I cringed when it was originally suggested that I put together a
    Web demo because I assumed it would require a lot more effort
    than it ultimately did. Not having to mirror the state of objects
    across a client/server divide was by far the main advantage for
    someone in a hurry, and with my lack of experience. I know that
    continuations are an important feature of Seasideand I’m sure
    my appreciation of continuations would soar if I were forced to
    do more traditional Web development, but for now they’re
    something I’m pretty much just taking for granted (benefit of
    being late to the game I guess)

    I have many years experience as a Smalltalk programmer, so I’m
    not sure how Seaside would look to someone without that background.

    DabbleDb

    Developed by Avi Brant, dabbledb is looking very promising. It features a ajax-enabled application, and shares a common look with BackPackIt, developed with RubyOnRails.

    Abeit the success of this new web tools is not for sure, last week google launched a new version of an online Word Processor and a Spreadsheet.

    So we have done a small interview to Avi Brant, about Dabbledb and Seaside:
    Seaside, RubyOnRails, Python Django, CakePHP shares some common idea.
    But I find only in Seaside the complete and automatic session/request management, and a true MVC process. Why other languages cannot take a similar approach?
    There are only technical difficulties or there is also some other
    equally good reason in your own opinion?

    It has very little to do with language. Fundamentally it comes down
    to a single design decision that’s at the heart of Seaside, which is
    to maintain session state in-memory, inside a long-running
    application server process. That’s at odds with a traditional “share
    nothing” philosophy of web development, which seeks to have all
    session state be either persistent on the server side (in files or
    databases), or constantly transmitted from the client in cookies or
    form fields. By making the choice to “share everything” and use in-
    memory session state to its fullest, a lot of the design constraints
    which have shaped our thinking about web development fall away, and
    some pretty radically different approaches are possible. I’d love to
    see people go down that path in other languages, and there’s nothing
    preventing it, but it doesn’t seem to be happening much yet.

    How much time did you take to develop the front end of DabbleDB?

    It’s hard to measure the time exactly, because for most of the
    development we were bootstrapping the company with consulting work,
    and getting in work on Dabble when we could. But I’d say it
    represents about two man-years of development work, plus a few months
    of (very important) help from a web designer.

    What database is used to store data? A relational one or an object oriented one?

    It’s a custom in-memory object database. We were going after a very
    interactive and flexible UI, and we wouldn’t have been able to get
    the performance we needed out of a standard relational database.

    Seaside has just reached 200.000 downloads.
    It looks like the most downloaded Squeak application of the last twelve months.
    What are your project for the future?

    One thing I’d like to do is reduce the dependence of Seaside on
    continuations – they drove a lot of the initial interest in the
    framework but they’re becoming (or seeming) much less important over
    time, and the use cases to which they’re best suited are these days
    often addressed with AJAX instead. Right now they’re creating an
    artificial barrier which stops Seaside from being ported to some
    dialects (like Strongtalk, Smalltalk/X and VAST) which don’t support
    continuations but would still benefit from a continuation-less Seaside.

    Conclusion and call for a follow up

    We’d like to interview more seaside developer!
    If you want a bright & exciting interview by Giovanni Giorgi (!) send him an email.

    If you find comfortable with seaside, feel free to add your comment ad the end of this article.

    References

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

  • 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

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

  • Squeak Tutorial for Java Programmers

    Java is a very well known language.

    There are a lot of fellows out of there which know java and ask themself: how can I learn smalltalk in a fast way?

    Giovanni Giorgi has done a small tutorial for brave youngs like you. This tutorial will help you learning Smalltalk very fast and is Squeak Smalltalk focused.
    Basic concepts apply to VisualWorks and Dolphin Smalltalk too.

    Feel free to give your feedback here.