blurgle blurgle blurgle

Moving the blog

2008-11-20T22:18:00.002-05:00

Well, leaving this up here, won't delete it, for all the Io related material in the archives that people might find interesting... But as far as Caribou goes, I'm moving all the updates to the new website, which is at http://www.cariboulanguage.org/.

Just a note, there's obviously a blog on the site, very simple, no more than I need... also the issue tracker is under development. I've also posted the URL to the git repository, though the source code is a little incomplete right now, but feel free to follow development if you want.

Anyway, read me soon over here!

Been busy with other things...

2008-10-30T15:05:00.002-04:00

No new news on Moose, except that I've renamed it "Caribou". I've been busy with real life matters lately, namely getting married.

I'm now married to the most wonderful woman on the planet, Adriana and I'm taking some time away from coding for the next little while.

So ... new MacBook

2008-10-24T18:14:00.002-04:00

Well, I went out and bought a brand shiny new aluminum MacBook... the 13.3", 2.4 GHz model. It's really nice, and one thing I've been wanting for the longest time -- NO TRACKPAD BUTTON!!! Well, I should clarify... They haven't got rid of the button, they have just made the whole trackpad a button. Which can be a little annoying, but meh.

Anyway, it's my new development machine, have to adjust to the qwerty-us layout again, but give me a week. More on Moose later.

Moose development resumes

2008-10-17T15:19:00.003-04:00

Well, this is my first post in a long time, but some good news to announce: Moose development has resumed.

I should note right off the hop, design decisions that have been made:

The object model is very lightweight. It's actually an implementation of the id object model with one minor modification: I don't like the name "vtable" so I renamed it "behaviour". If you are not familiar with that object model, read the paper linked to get an idea.

Secondly, the language as being implemented currently is just the first stage bootstrap compiler. That is, it is going to be extremely lightweight with nothing but the absolute bare necessities required to implement a second stage compiler which will be written in the language proper. This second stage compiler will be more complete.

As you can guess from the above descriptions, Moose will be a compiled language. That is, we will generate managed C code, which our compiler will then invoke the system C compiler to generate code. That said, there will be an interactive REPL for interpreting code without compiling it. However, you will not be able to access the low level system from the REPL. That is, instead of building a virtual machine for Moose to be implemented on, we will simply allow you to access the C structures, wrap C libraries trivially, create bindings for C libraries that do not require you to actually implement some protocol in C code, and then integrate it to the virtual machine for it to be visible in Moose.

I know right now, this sounds a lot like pepsi, and you know what? It is a lot like pepsi. However, it is meant to be a general purpose language, whereas pepsi is meant to be a language used for construction of other languages as far as I've been able to tell. The primary goal for Moose is to be small (both in memory footprint, learning curve) and fast (in terms of performance, debugging, and otherwise). While that previous blurb sounds more like marketspeak, it's hard to get concrete at this stage of development since not a lot of decisions have been made yet. There are a bunch of tentative decisions that are in my head right now, but whether they'll actually work, remains to be seen.

Currently I have the object model completely implemented, tested and debugged; and have started to performance benchmark it against other models, with surprisingly good results. However, I'm going to belay posting those until the system is anything more than a few routines ontop of C. Once a parsing subsystem is implemented, and a basic set of primitive objects are in place, then I'll test again and we will see.

More will follow in the coming days, week, whenever I post again.

[UPDATE: In case you didn't infer it from my posting, this version of Moose is a complete rewrite of any other versions that have existed.]

iPhone anySIM

2007-09-21T13:06:00.000-04:00

While not really related to this blog, I'm not starting another one just because of this.

In any event, I've recently noticed that drudge from ##iphone on freenode, and of conceitedsoftware.com fame, has stopped distributing the anySIM software unlock under concerns about the DMCA and legality of distributing it in the USA. I've started distributing it on my iPhone Installer.app repository now, as I fall outside the jurisdiction of the DMCA.

In any event, mine is live now (though it may take up until tomorrow for the DNS to propogate, so if it doesn't work right away, try again tomorrow). Open up Safari on your iPhone, and point it at: http://iphone.blurgle.ca/repo/ (the trailing slash is important). Tap "Yes" when prompted, then you will be able to install anySIM again. The 1.0.1-3 version is the same as the 1.0.1 version, but it received the version bump due to the version bump given on conceitedsoftware.com's version which removed it from their service.

If you have any problems, the instructions still exist over at conceitedsoftware.com as to how to fix it. In the coming days I'll be duplicating those over on my server.

Musings on conditional execution

2007-08-13T23:23:00.000-04:00

Well I've been mulling over the idea lately that perhaps I should include, as a core language feature, the ability to execute "instructions" conditionally. Now I know exactly what you're thinking: "Isn't this what the if() construct, and the like are used for?" Well, you'd be absolutely right. Except one key little thing: I think that having to explicitly define if(someCondition, onTruth, otherwise) is kind of silly when one could write:


(bob age == 42) "bob is forty-two" println.
(bob age == 23) "bob is twenty-three" println.

Now this does bring into play a couple of issues. What about duplication? Multiple comparison? Fallback conditions? Performance?

Well, I can answer a couple of those right now. Let's start in no particular order with the fallback condition. Consider if you want to fall back to a traditional else block:


(
  (bob age == 42) "bob is forty-two" println.
  (bob age == 23) "bob is twenty-three" println.
  (true) "god only knows how old bob is" println.
)

Is one way to solve this, however there surely has to be a better way to accomplish this syntactically.

What about performance? Well, we'd encode a single bit in each object which basically states "yes, this object has a predicate" or not. If it does not, then the condition is expected to be true, and the code will be executed. Now, this check will add minimal time to the execution of a Moose program, as Moose is already very slow compared to some other folks expectations.

Finally, on the duplication front. There could be a syntactic extension to reduce this, but I don't see a need. Just assign your predicate to an object before hand, then use it in the parenthesis.

In any event, I cannot really answer the question about multiple comparison yet, as I haven't hashed out any ideas on that yet.

All this said however, this may very well just be a pipe dream to get rid of both for() and if() in one language, but I think it can be done w/o going declarative.

Not dead, honest!

2007-07-27T15:52:00.000-04:00

Well, it's been quite a while since I've posted here. Basically I'll give a rundown of what I've been doing with my time, and why I've not been bothered posting here.

1) Progress on Moose has been next to nil since the start of the year; it's gone through two redesigns, and three implementations and I'm no further ahead than I was back then really.
2) Home life has been busy.
3) Our company has been expanding our network so much it's eaten into a lot of my extra time.

In any event, nothing really interesting to post about right now, other than I just received my new iPhone today, and it's really nice.

Lots of fun...

2006-12-03T10:22:00.000-05:00

Well, my birthday came and went, and I decided now was about time to pick up a macbook; so I did that on yesterday. It's really nice looking, and speedy, I like it.

In any event, I've not been doing much work on Moose this past week, but I will endeveur to work some more on it in the coming weeks, but I make no promises of real progress until after the holidays.

Cya!

A functioning prototype

2006-11-26T21:29:00.000-05:00

Well, I've got a very rough working version of Moose running now with a crude object system and not much else. =] In any event, I thought I'd show it (the syntax is just what comes naturally to me, it may change so don't get too attached to it, or annoyed by it). Let's start with a factorial:


fact := method(1): [ n | (n = 0) ifTrue: [return 1] ifFalse: [return n * fact(n - 1)]].

At first glance it looks a lot like Smalltalk, but it's not; it's a lot more like Io than the syntax makes it appear. I'll break down that example at a source code level, then break down (in brief) the elements that make it go.


fact := method(1)

Is akin to the Io code:


fact := method(
  if(call message arguments size != 1,
    Exception raise("Invalid number of arguments, expected 1 got " .. call message arguments size)
  )
)

Noting of course that this argument is entirely optional -- without it, calls to the returned method won't bail on any errors no matter how many (or how few) arguments you supply.

But you may be wondering, what's that ':' and [] code after it? Well, that's the body of the method -- i.e., the "connected" code block (sorta like in Ruby). Unfortunately for the moment (until I find a syntax which is better equipped to handle this case), only one code block can be connected to a message.

Now, just to finish up the comparison:


[ n | (n = 0) ifTrue: [return 1] ifFalse: [return n * fact(n - 1)]].

Is a block (lexical closure) like in Smalltalk. It expects one parameter (enforced by the method(1) declaration earlier), and checks whether the condition "n = 0" is true or not (ifTrue/ifFalse being different methods as in Io, not as in Smalltalk). The same code in Io could be written like:


block(n, (n = 0) ifTrue(return 1) ifFalse(return n * fact(n - 1))

One final note about the syntax, you'll note the trailing "."; this is a break in the message tree. In Io, you'd use ";" or a newline (provided an open parenthesis or comma wasn't the last token on that line) -- in Moose, I've elected to require a message tree termination character. This is again, something I may drop, let's not get hung up on it -- suffice to say, I put it in there as just a thought to allowing line continuation (a common complaint in Io).

Now then, the object system is really primitive. Currently, there is no form of inheritance or anything fancy like that so I'm not even sure you'd call it an object system yet, but in any event, what's happening isn't that different than what's happening in Io (except everything is being executed within the context of a single object -- the Lobby): The parsing system transforms the assignment into this call:


defineSlot(#fact): method(1): [...]

Which as you can gather, sets a slot named "fact" (# being the symbol literal character, as in Smalltalk) in the Lobby with the value of the method object as defined above. Now then, we look up the symbol "defineSlot" in the Lobby, and if it's not present blow up, otherwise continue evaluating and do the same lookups for the arguments. Note that connected code blocks are not currently arguments to the calling method as in Ruby, but separate entities which can be attached to any method even if they weren't written to take advantage of. Connected code blocks are actually said to be connected to the message of the receiving method/block/closure so you are able to do some manipulations with them.

There's a couple reasons I chose to create this extension to basic Io syntax. First off, it will help out detecting syntax errors immensely! This has been a long standing gripe of mine -- though to Io's credit, it's not an easy fix w/o changing Io's syntax. Good error reporting is critical to any language for it to be successful in my opinion, and a syntax as flexible as Io's can easily be extended to help facilitate this without giving up anything flexibility. Secondly, it just flows better in my mind.

It should also be noted that incase you didn't infer this behaviour, I should mention it explicitly: Connected code blocks activation is the responsibility of the method it's being connected to.

In any event, this is just a teaser, I need to fix up the object system as currently all that happens when you "create a new object" (integers and symbols are exceptions, they're immediate values); is it just copies the lobby, and modifies it -- which as you can imagine, can lead to some weird behaviour.

Until next time...Enjoy!

Moose: Manifesto

2006-11-19T12:22:00.000-05:00

"Why another language?" might be the first thought a lot of people might have, and others can probably see the need: There is currently a major gap for powerful high-level languages with a small footprint both in size and memory -- which is important for embedded devices, and some general purpose software.

Small

With the trend we've been seeing over the last 25 years is an ever increasing push to smaller devices. While the trend recently has been that these smaller devices are getting more and more storage (with increasing flash sizes and increased RAM), this does not preclude the need for efficient languages. C is without a doubt the most prevalent language in this arena, and probably will be for a very long time (with good reason: it's very efficient and very fast). However, I don't see the speed issue as a big one. These embedded devices are always getting faster and faster with reduced power consumption, and for most tasks handled today, one need not have a super fast language, all the time. So long as it is easy to extend with a language like C where needed, so much the better.

Concurrency

It is inevitable that we will also see the emergence of multiple core processors in this market, and as a result, to take advantage of this extra hardware, the ability to spawn multiple threads of execution will be key. However, concurrency as it exists in most languages today is heavily burdensome, and error prone. Languages of the future will need to have a sophisticated concurrency model in order to lift some of the burden of writing concurrent code, from the programmer.

Comparative Simplicity

While the above points are important, there is also one final absolutely key element to Moose: Comparative simplicity. First, let me define comparative simplicity, as it is not likely a term you've heard before. I define comparative simplicity as being as simple as possible to perform a given task without violating any of the pre-defined key goals. That is to say, any and all code should be written as simple as possible given that it should also be as memory efficient as possible, and without sacrificing flexibility.

I'm aware that nothing here is concrete in so much as it probably should be, but this is but a first step down a long road that will be paved with many changes in the concrete representations of these abstract goals.

In any event, until next time.

Moose - A primer

2006-11-07T13:51:00.000-05:00

Well, I'll give a quick little rundown of various items, just more of an "about Moose" than anything technical, so feel free to ignore this since it's mostly useless.

In any event, it is my opinion that Io isn't moving back towards use in an embedded market. Sure, currently it seems quite like a good tool for a control language in many applications; but as for use in embedded devices, it's sorely lacking and not looking as if it's going to be making any strides in that area any time soon. This isn't really a shot on Io, it's just there's really nobody interested in doing this -- and the more and more the language is written in itself, the less and less that is practical for embedded devices, as the memory footprint grows. This is one main area of focus for Moose.

Secondly, but more as an extension to the first point; the memory footprint must be small, and as a result, Io's choice in garbage collection strategy, just doesn't lend itself very well to operating with a small memory footprint. So instead of copying Io's mistakes, all objects will not be of the same size, as mandated by Baker's Treadmill collector, and instead, we'll use a slight variation on cheney's copying collector supporting generations initially, and eventually find and implement a better algorithm for time.

Thirdly, and finally for now, I'm going to design a new standard library which will be mostly incompatible with that of Io and will probably more resemble standard libraries distributed with many Smalltalk vendors implementations thereof.

Finally, the name... If anybody has ever seen a Moose (Alces alces), it's a very large member of the deer family (Cervidae) with long springy legs, a heavy body and quite awkward looking when in motion. It's the most awkward animal I could think of that is native to Canada.

More details will be forthcoming when they well... are. =]

A lot has happened in the last 20 days...

2006-11-05T19:29:00.000-05:00

As you've no doubt noticed, I haven't been posting a lot in the last couple weeks, and there's a reason for that: Increased load at work, work on the book, and other time consumables. In any event, this post is pretty important, so I'll get on with it.

I've made a decision today, one that will help me offload some of the backlog on my free time, and allow me to focus more on some specific priorities. Namely, I'm no longer actively contributing to the Io project. The rationale behind this is simple, I find myself more and more steering away from the direction everyone else wishes to take Io, which is fine. So I'm going to focus more on this half-ass fork I've been nurturing for the last while--though it's not really a fork, more of a re-implementation.

That said, I've also decided it'd only be prudent to rethink the focus of my book. I'm no longer dedicating it to Io (though certainly a lot of the data it will contain will be applicable to Io too), instead I will be focusing it as the introductory material for my language.

As a side note, I won't be returning to the #io IRC channel, and won't be running Hæmus any longer. If someone from #io wishes to run it for #io, I'd be more than happy to send that person the up to date sources and accumulated data, subject to the conditions of the BSD License with an advertising clause.

And finally, as of this moment, this blog is no more dedicated towards Io, but instead, my language: Moose. I'll make a new post within the few days outlining my rationale behind the name, direction I wish to take the language, and when I think there's something worth making available, I'll post a repository where one might fetch my language.

Until then, later.

Fixed block arity

2006-10-16T19:57:00.000-04:00

Well, a while ago on the mailing list I got into a heated debate with a few people over the idea of a fixed-arity on blocks, and I'm here to eat my hat. Recently I've come into a few cases where it just made sense to limit the number of arguments passed in, so I modified IoBlock to support this. By default, we set the arity of a block to -1 which indicates that you can pass in as many (or as few) arguments as you want (just like the current behaviour), but if you pass "setArity" with an argument greater than or equal to 0, when that block is activated, Io will make sure that the person who called it, supplied the right number of arguments or it will raise a non-fatal exception.

I've made a patch and pushed it out to my public repository, I'm asking for you folks to try it out, see what you think, and leave a comment pro, for, undecided, whatever... My darcs repository is here and if it times out or is slow, my apologies, having connection issues of late, just try again later.

Enjoy!

Rational Numbers

2006-10-15T13:59:00.000-04:00

Well, I've written rational number support for Io, which I plan on making into an addon RSN! In any event, if you want an early sneak peak at the code, you can have a look here and let me know what you think.

There is one little caveat that you should be aware of if you intend to use this; and that simply put is this: Io uses floating point numbers as its numbers, and since floating point numbers are well, imprecise, you can get some interesting results if you were to say:


0.111111 asRational

and expect to get "1/9", but instead get "8.006391e+15/7.205759e+16". I don't know what else I can do to stop this from happening, but if anybody has any ideas, I'd be more than happy to look at them.

That said, things like this work fine:


0.25 asRational == Rational with(1, 4)

In any event, as always, enjoy!

Welcome waxbolt

2006-10-09T18:04:00.000-04:00

This is more related to the blog itself than to Io, but I'd like to take a moment to welcome a contributing author to posting on this blog. His name is waxbolt and he'll be documenting various items that may closer pertain to beginning users than the more advanced audience I usually target.

Anyway, I look forward to reading some of his stuff.

LISP DSL

2006-10-09T12:41:00.000-04:00

This afternoon in #io, we got to talking about how I am going to make a post demonstrating the evilness of the grouping slot (group()) without the "group" identifier, so just ""() without the quotes). Anyhow, someone said they'd like to see a LISP DSL akin to my C DSL, so here's a trivial LISP DSL (it could be a lot better with just a bit more code, but it's mid-day and I'm lazy).


Lisp := Object clone do(
  setSlot("", method(
    m := call argAt(0)
    arg := m attached
    args := list
    while(arg,
      t := arg clone
      arg = arg attached
      args append(t setAttached)
    )
    m setAttached
    m setArguments(args)
    call sender doMessage(m)
  ))

  ' := method(
    l := list
    m := call message argAt(0)
    while(m,
      t := m
      m = m attached
      l append(t setAttached)
    )
    l mapInPlace(v, call sender doMessage(v))
  )
)

So then, first we create a Lisp object, so we're not polluting the Lobby (as setting "" there would be bad, mmkay (but more on this in a future posting)). Then we define the "" slot -- grouping message has no name. Just for a bit of background, this grouping message is used in cases like: (2 + 3) factorial <-- where you want to compute the value of 2 + 3 before passing the factorial message, as opposed to 2 + 3 factorial which would be parsed as 2 +(3 factorial).

Anyway... let's continue.

Next we grab the message argument at position 0, (there can only be one Io argument in a valid LISP funciton call), and we grab onto the attached message (an "atom" in LISP speak). Now we loop over each attached message (atom), and add it to the args list. Once we've evaluated all attached messages (next messages are ignored too), we erase all attached messages since everything inside the grouping character is treated as one single method call; and set the arguments of our message to the values we just poached from the attached message chain. Finally, we execute that message.

Now, the ' method is special. It's sugar for the "quote" lisp function call, and it is sorta handicapped here. Anyway, it is much like the previous method, so I won't go on explaining it.

As I say, this could be much, much better; but I'm just lazy at the moment. It wouldn't be terribly difficult to implement a basic scheme interpreter using just Io code, but I'll leave that as an exercise for the reader.

As always, this is not the best way to implement such a beast, but it was merely done at the request of another.

Design By Contract

2006-10-09T00:38:00.000-04:00

Those who are long time readers of my blog will have seen something on this topic before, or at least, the makings thereof. I've revisited pre/post method hooks and changed the semantics a little. Basically put, now I wrote a new extension that isn't visually intrusive, and retains the expected semantics. As always, I'll post it now, and go over it piece by piece:


Object do(
contract := method(
  args := call message arguments
  body := args removeLast
  pre := true
  if(call message attached ?name == "setPreCondition",
    pre = call message attached argAt(0)
    call message setAttached(call message attached attached)
    if(call message attached ?name != "setPostCondition",
      body = """if(#{pre}, self, Exception raise("pre-condition failed"))""" interpolate asMessage setNext(body)
    )
  )
  if(call message attached ?name == "setPostCondition",
    post := call message attached argAt(0)
    call message setAttached(call message attached attached)
    m := """
      __body := "#{body}"
      __args := call evalArgs
      __meth := getSlot("self") getSlot("Block") clone setMessage(__body asMessage) setArgumentNames(#{args map(name)})
      __preMethod := getSlot("self") getSlot("Block") clone setMessage(message(if(#{pre}, self, Exception raise("pre-condition failed")))) setArgumentNames(#{args map(name)}) setIsActivatable(true)
      __tempMsg := message(__preMethod) setArguments(call message arguments)
      getSlot("__preMethod") performOn(call sender, Object clone, __tempMsg)
      __tempMsg = message(__meth) setArguments(call message arguments)
      result := getSlot("__meth") performOn(call sender, Object clone, __tempMsg)
      if(#{post}, result, Exception raise("post-condition failed"))
    """ interpolate asMessage
    getSlot("self") getSlot("Block") clone setMessage(m) setArgumentNames(args map(name)) setIsActivatable(true)
  ,
    getSlot("self") getSlot("Block") clone setMessage(body) setArgumentNames(args map(name)) setIsActivatable(true)
  )
)

Now then, we're defining "contract" as a method() like method constructor. Just for background, we're not setting a scope here, so the returned method acts like a method and not a closure.

So we start off by fetching the argument list and then getting the body of the method (always the last argument in Io by convention), then we define the "pre" method's message containing a true value -- if we actually have a pre method, it'll get a real message.

Next we check attached message to see if its name is "setPreCondition" (I'll explain later as to why these aren't just regular methods). If the attached message's name is "setPreCondition", we update the pre message to point to the argument. Then we crop the "setPreCondition" message out of the message tree, setting the attached message to its attached message. Finally, we update the "body" method (for use here only if there's no "setPostCondition" attached message) to throw an exception if the condition doesn't report a truth value.

Like before, we check the attached message now for "setPostCondition". Now here it gets complicated. Like before we set up the post message this time (containing the condition expression which we'll later use to test against), and update the message's attached message just like before. Now we create a "m" message, which we'll construct from a Sequence. First we define a "__body" slot, which is just the interpolated string value of the "body" message, which is the actual method body. Then we define an "__args" slot which points to the arguments passed in -- which are evaluated within the context of the caller. Now we create a "__meth" method, which builds up the actual method (that is, if you define: contract(a, b, a + b) it builds a message up with the arguments "a" and "b" with the message body "a + b"), inserting the pre-condition check (note that pre will be true if no setPreCondition message was found, so while this pre-condition check is inserted, it'll never evaluate to non-truth). Next we build up a "__tempMsg" message which basically makes a call __preMethod(a, b) where "a and b" are symbolic of the message arguments passed into the method at call time. I.e., 'a' and 'b' may be messages representing the values 2 and 3. We use "__tempMsg" to perform the "__preMethod" on the locals of the caller, which we do on the next line. Next, we update "__tempMsg" to do the same thing but for "__meth". On the next line, we capture the result of the evaluation of "__meth" within the locals of the caller and set the value it returns to the slot name "result" -- Note this is important since it will be available to you in the post condition code block. Finally, if the post condition matches, return the result, otherwise raise an exception. This complex message we just built up is set as the message of a newly created block and returned. Otherwise (if no post condition was found) we create the block using just the pre-condition (if it was found) or we just create a regular method() with no pre/post conditions.

I'm going to create an addon for this, and submit it. So in the next release (or the release after that) you should be able to type in: Contracts to pull in support for this, and get the "contract" method constructor on Object.

[UPDATE: This has made its way into the Io Darcs repository; as a result, it will appear in the next Io release.]

Hæmus

2006-10-07T22:19:00.000-04:00

I recently rebuilt a new repository for my IRC bot Hæmus, which sits in the #io IRC channel and made the repo available for any who wish to view it. The code is rough but it work; and there's a few bugs, including one I've not yet tracked down relating to timers.

Anyway, I accept patches, so if you find something and correct it, write a new plugin, or just clean up some code, I'd be greatful.

CSV Parser/Interpreter

2006-10-06T00:30:00.000-04:00

So I got to thinking that I could use Io's parser to parse CSV files. As you've seen before you can bend and twist Io code in such a way that it's not really distinguishable as Io code. In the case of CSV however, there's a much simpler way to handle it -- Create a message and parse its arguments as the values. I figured I could write it in about 6 lines of code (and I'm still confident that I can, but this version is a little longer).

Anyway, here's the code:


parseCSV := method(str,
  r := list
  str split("\n") foreach(line,
    m := line asMutable prependSeq("(") appendSeq(")") asMessage
    l := list
    m arguments foreach(arg,
      tokens := Compiler tokensForString(arg name)
      if(tokens at(0) type != "Number" and tokens at(0) type != "MonoQuote",
        Exception raise("Element not a number or a string.")
      )
      l append(doMessage(arg))
    )
    r append(l)
    )
  r
)

Now then, this parseCSV method is pretty straight forward; takes a string as input, creates an empty list to store the return values in. Then it splits the string up into lines and iterates over each line. Now it has to insert grouping characters around the argument list before converting it to a message, otherwise Io's parser will throw a fit, so we prependSeq and appendSeq before converting the string to a message.

Now we create the inner a new list, which will be used for each individual line (each element representing a comma separated value), and iterate over the arguments in our message. Now we need to know what tokens are in the CSV file; I'm not sure that the only kind of CSV data that's valid is numbers and strings, but for the sake of this, that's all I'm assuming. So we need to figure out what token is at the beginning of the argument (note that this doesn't perform any checking to make sure it's the only thing added, but it could easily with a tiny bit of extra code). Then we evaluate the message and add it to the list and repeat for each argument. Once we've iterated over each element in the CSV line, we append that list to our list pointed at by "r", and iterate over the next line in the sequence until we run out of lines, then we just return the list.

There's nothing super magical about this, but I thought it would be interesting to demonstrate how to write something like this in about a dozen lines.

OS Threading making its way into Io

2006-10-05T19:08:00.000-04:00

Recently, Trevor Fancher has added support for OS threading to Io. Basically how it works is that for every processor core (real or virtual) in the system, Io will start up an additional thread (this logic currently isn't written yet, but soon) and create a new state which is then run on that processor. This of course means that you only get one thread per processor, but with Io's distributed objects support (which is mostly transparent), communicating between these threads for various synchronization requirements should be trivial.

I think we're going to see some interesting concurrency models evolve out of this perhaps, I guess we'll have to wait and see.

Io Profiler

2006-10-01T15:31:00.000-04:00

So a while ago I started working on a profiler for Io code. As with many of my other projects, I put it away for a while to come back to later. Anyhow, today I came back to it and got it usable, and while it's not complete, I present what is done below:


Profiler := Object clone do(
  calls := Map clone
  newSlot("startTime")
  newSlot("endTime")
  newSlot("timing")
  newSlot("lastMessage")
) 
Debugger prependProto(Profiler)
    
Debugger vmWillSendMessage := method(
  if(timing,
    self vmHasSentMessage(lastMessage)
    setTiming
  )
  setTiming(true)
  k := self message name
  calls atIfAbsentPut(k, list(0, 0))
  setStartTime(Date clone now asNumber)
  setLastMessage(self message)
) 
Debugger vmHasSentMessage := method(m,
  setEndTime(Date clone now asNumber)
  k := m name
  calls atPut(k,
    x := calls atIfAbsentPut(k, list(0, 0))
    x atPut(0, x at(0) + (endTime - startTime))
    x atPut(1, x at(1) + 1)
    x
  )
)

Coroutine currentCoroutine setMessageDebugging(true)
doFile("main.io")
Coroutine currentCoroutine setMessageDebugging

writeln("""#{"message" alignLeft(25)}  #{"times" alignRight(8)} #{"time"}""" interpolate)
Profiler result := list
Profiler calls foreach(k, v, Profiler result append(list(v, k) flatten))
Profiler result = Profiler result sort reverse
Profiler result foreach(v,
  t := v at(0)
  x := v at(1) asString
  k := v at(2)
  writeln("#{k alignLeft(25)} #{x alignRight(8)}x #{t}" interpolate)
)

Now then, starting at the top we define a Profiler object which is going to store some bookkeeping information. Then we need to prepend our Profiler object to the Debugger object, since we're just extending its functionality. This is all pretty straight forward.

The Debugger vmWillSendMessage is the interesting bit. This is the method that is called before the debugger resumes the message that is being debugged. Once this completes, that coroutine is resumed, so we need to set up everything beforehand.

First we check to make sure that if we're already measuring time, then we need to call the vmHasSentMessage method which we define later on, with the argument lastMessage (which represents the last message that was debugged), then we tell the profiler that we're not timing anymore. From there, we turn back on timing (this is probably best to be refactored out, these last two calls). Next we get the name of the message that is being debugged (note the use of "self" instead of "call"). From there, we create an entry in the Map if one doesn't already exist for that particular message, with a list value with two numbers, 0 and 0. They represent the time it has taken cumulative to execute all the messages with this name, and the number of times it has been executed respectively. Now we set the start time for the current message, and set the last message to the current message (so when we re-enter vmWillSendMessage, we can call vmHasSentMessage properly).

That brings us to vmHasSentMessage. When it starts, we set the end time (since by this time, the message has already stopped). Then we set the value for the name of the last message (the message that just finished executing before vmHasSentMessage was entered) into the calls Map object. We want to make sure that the first item in the list (the value we're associating to the last message name) is the cumulative time taken to execute the message, so we add the time it just took, to the previous total time. Likewise, we need to keep track of the number of times it has executed, so we update the second element in the list too, by adding 1 to it. Finally we return that list object we just built up to set it back into the Map.

Now comes the interesting part, we turn on message debugging via the setMessageDebugging(true) message on a particular coroutine (in this case, the current coroutine (the main coroutine)). From there, we execute a file called "main.io", then turn off message debugging. Below is the main.io (but you can put whatever your little heart desires in it):


1 + 2
System sleep(2)
10 factorial pow(5)
System sleep(1)
5 * 3
1 + 9

After we execute main.io, we print out the result in a nice pretty form. (Note that if Io had an ordered dictionary, this section could be tidied up a lot.)

As always, if you have any questions, feel free to post comments.

Le sommet de l'OIF

2006-09-30T15:03:00.000-04:00

EDIT: My apologies, I meant to post this on my other blog, not this one.

Not strictly Io, but cute nonetheless

2006-09-27T15:07:00.000-04:00

Well this post doesn't contain any Io code (I'm sorry, I've been busy). However, it does contain a little thing I found humorous from a website I stumbled across called World's Last Chance. Specifically, I enjoyed this paragraph:

World's Last Chance dares to declare this interpretation to the world because we adhere only to sound Biblical interpretation. This means we unlock Bible prophecy by using the Bible as its own interpreter. By doing so we are certain of the correctness of the revelation.

Perhaps some of you will have noticed what I caught about this that made me instantly think of Io; for the rest of you, I'll explain.

Io is a very dynamic language, capable of some really cool self-introspective features. When I read the passage "This means we unlock the Bible prophecy by using the Bible as its own interpreter." I thought, hey neat, if the Bible can do this and people revere it for being sacred, curious, couldn't one also revere Io for the same "explain the world away by self introspective capabilities?" I brought this up in #io and SteveDekorte said: "14:45:44 < SteveDekorte2> of course ;-)"

Food for thought (Note, I don't accept hate mail from evangelicals, though crazy nutjobs, feel free!)

Fun with a C DSL

2006-09-20T21:01:00.000-04:00

Well, having fun here the last hour in #io about C and whatnot, to be honest, I didn't pay attention to the entire discussion. I was intrigued with the possibility of executing legal C code as Io code. I mean, I knew it was possible, but I'd not actually seen an implementation doing so, so I figured I'd make one, I present it below:


C := Object clone do(
  libc := DynLib clone open("libSystem.dylib")

  curlyBrackets := method(call argAt(0))

  forward := method(
    libc performWithArgList("call", list(call message name, call message arguments map(x, self doMessage(x))) flatten)
  )

  int := Object clone
  int updateSlot := method(str, C setSlot(str, call evalArgAt(1)))
  int forward := method(
    if(call message arguments size > 0,
      attached := call message attached
      args := call message arguments map(v, v attached name)
      body := attached arguments at(0)
      call message setAttached(attached attached)
      C setSlot(call message name, self getSlot("Block") clone setMessage(body) setArgumentNames(args) setIsActivatable(true))
    ,
      call message arguments foreach(v, call sender setSlot(v attached name, nil))
    )
  )
)

Now then, just to trim it up, you've seen the libc stuff before, if not, check postings from yesterday; so I'll skip over that (this includes the C forward method).

Now I defined a curlyBrackets method on C, which you might be asking, what's it do? Well Io transforms {} into a message curlyBrackets with whatever arguments you specified between the { and }. All this does is return the message argument since for the basic subset of C we're defining, we only want access to the first element in a { }.

Next I defined an int object. As you can assume, it's C's type "int", but could easily be a "long" or "double". It defines an updateSlot method which is what comes out of the parser when it sees an "=" identifier. In it, we pass setSlot onto the C object and evaluate the argument on the right hand side of = within the body of where it was called. Then I defined a forward method on int, which basically is just used for defining a C function. It doesn't check to make sure that the attached message is a curlyBrackets, which it probably should, but I'm lazy, sue me. =] This forward method sets a slot with the name supplied after the int and before the first parenthesis within the context of the C object. We can later call C thatFunction(args, it, defined) to call it.

And we wrap up our C code in a do message on C because that's where we defined our C DSL.


C do( 
  int foo(int a, int b) {
    return a + b;
  }
  int x = foo(1, 2);
  printf("%d\n", x);
)

Hope you enjoyed this!

[UPDATE: Oh and I should note that this isn't the best way to write a C-like syntax in Io]

Defining slots on a proxy

2006-09-20T04:29:00.000-04:00

Once again with Scott Baldwin in #io and his never-ending quest for all things wild and whacky... He's wanted a setScope on CFunction for doing things like setting slots on a proxy object. I've come up with an alternative which I define below:


ProxyObject := Object clone do(removeAllProtos)

getSlot("setSlot") performOn(ProxyObject, Object clone, message(setSlot("foo", 42)))
ProxyObject foo // returns 42

The first argument is the object you want to perform the message on, while the second argument is the locals to use for the call, and the third object is the actual message to execute (the "setSlot" there can be anything your little heart desires, it just represents the setSlot CFunction which will be receiving the performOn message (it needs arguments we have to supply, otherwise we could leave the last two parameters off).

Enjoy!

Calling the actual function name

2006-09-20T01:15:00.000-04:00

I got to thinking today after talking in the #io IRC channel that perhaps it would be good to allow people to call the name of the function directly when using DynLib rather than having them have to pass it through a "call" method on DynLib itself. For instance, let's say we want to call printf with some arguments and that our libc is called libSystem.dylib (OSX). We could write this code like:


libc := DynLib clone open("libSystem.dylib")
libc call("printf", "My name is %s", "Jeremy")

And the above would print out the text "My name is Jeremy". Now let's suppose we wanted to write that like this:


libc printf("My name is %s", "Jeremy")

We can do that. It just involves making use of Io's special forward method that can be set on any object. Like so:


libc forward := method(
  self performWithArgList("call",
    list(call message name, call message arguments map(x, self doMessage(x))) flatten
  )
)

What this does is when we send our printf() call to our libc object, if it cannot find printf in the lookup tree, it will manipulate the call turning it into the code we'd need to write using DynLib's call() method, so we can execute a C function from pure Io code without any glue code.

I'm thinking about adding this to Io depending on input from everyone, and Steve, so let me know what you think.

My Io book

2006-09-11T00:31:00.000-04:00

As many frequenters to the IRC channel know, I've been working on an Io book for the last couple weeks, and I've decided to put out a little call. If anyone has some short examples of various items, or even just ideas you think would be good to demonstrate Io (keeping in mind that the book is an example driven model), send them to me. I'll select a few that are of good quality, and add them to the book. book@blurgle.ca.

Converting lists into messages and more...

2006-08-31T21:01:00.000-04:00

I got the idea of turning a list into a message today after thinking about Scott Baldwin's request for a Block callWithArgList method which would allow you to call a block with a list of arguments instead of supplying the arguments manually one by one. I figured converting the list into a message would be the first step, and that's what I'm posting about today. The second half, making a union of two messages, I'll do tommorrow or sometime next week when I have some more time. Anyway, here's the code:


List asMessage := method(
  m := Message clone
  foreach(elem,
    m setArguments(
      m arguments append(Message clone setCachedResult(getSlot("elem")))
    )
  )
  m
)

Now this will return an unnamed message, with as many arguments as there were list elements, creating new, unnamed Message objects with their cached result set to the value of the element (without activating any activatable elements).

In any event, hope this is useful, it's going to go into my next patch for Io provided Steve thinks it useful.

UPDATE: I just finished writing a union method on Message which combines two messages into one (separating them by arguments). Anyway, here's the code:


Message union := method(m,
  r := Message clone
  l := list(self)
  m arguments foreach(arg, l append(arg))
  r setArguments(l)
)

Should work great, in my limited tests it works just as I want. If you have any suggestions for it, leave them in the comments.

Enjoy!

More useful(?) goodies...

2006-08-29T03:22:00.000-04:00

This is something I pulled out of my enhance.io (old scratchpad I just recently dug up in my archives). It demonstrates a transformation hook in Io, wherein [] messages get translated into squareBrackets() method calls. So all you need to do is define squareBrackets on a particular object, and then you can pass [...] to an object. Anyway, I made squareBrackets multifunctional -- would return a list datastructure as in Ruby or Python if given just an argument list, or would create a lexically scoped block of code if given an arglist in brackets first, followed by a method body (either as an attached message, or as a next message).

Code follows:


squareBrackets := method(
  if(call argAt(0) name == "",
    args := call argAt(0) arguments map(name)
    m := call argAt(0)
    m = if(m attached, m attached, m next)
    Block clone setMessage(m) setArgumentNames(args) setScope(call sender) setIsActivatable(true)
  ,
    call evalArgs
  )
)

Anyway, you can use it like this:


[1, 2, 3] // returns list(1, 2, 3)
x := [(a, b, c) a + b + c]; x(1, 2, 3) // returns 6
[(x, y); x * y] call(5, 10) // returns 50

Anyway, it's just one of those things that someone may find useful; I know many in the Io community look down on squareBrackets/curlyBrackets but I think they can be useful, though this is perhaps not the best use of them.

Range enhancements

2006-08-25T20:21:00.000-04:00

This afternoon I made some changes to the Range implementation. Specifically, I added three methods: indexOf, at and slice. Now these three methods do the same thing as their respective methods on List, but obviously their implementation is a little different. Below is a description of what they do:

indexOf - Rewinds the Range (returns it to the start element) and then proceeds to calculate all occurrences between the start and the item you specify as its parameter. Once it comes along that item it returns the index (offset using zero counting from the beginning of the Range). Will return nil if the value is not in the Range.

at - Like indexOf but it returns the element at a specific index, calculating all the required items between the start (index 0) and the supplied index parameter. Raises an exception if the index is out of bounds.

slice - Takes three parameters, the starting point, the ending point, and the increment value. Returns a list of the subset of items between the starting and ending point supplied, and skips every N items, where N is the increment value. Raises an exception if the starting point is greater than the ending point or the starting point or ending point is out of range.

Anyway, I added these so you could, for example, use Range like a lazy list and take only as many items from the list as you wanted. For instance:


r := 1 to(Number constants inf) // creates an infinite list
r slice(50, 55) // will return: list(50, 51, 52, 53, 54, 55)

This patch should appear within the Io repo within the next couple days I hope.

Passing methods as first class values

2006-08-24T18:47:00.000-04:00

This is nothing spectacular, but handy sometimes, so I figured I'd post it.

Using higher-order methods in Io require you to either turn off the activation record of the object beforehand, get it, in your method and do it then, (reactivating it later); or to litter your code with getSlot()'s. I've come up with a simple solution which still requires one getSlot, but doesn't require anything special like adjusting the activation record. Code is below:


square := method(n, n * n)

docSlot("calculateResult(f, aNumber)", "Calculates a result based on the function f for the number aNumber.")
calculateResult := method(
  f := call sender getSlot(call argAt(0) name)
  input := call evalArgAt(1)
  f(input)
)

calculateResult(square, 5) /* returns 25 */

There's still a little bit of cruft since you can't define an argument list on the method(); or at least, I havn't figured out a clean way to do it yet.

[Update: Err.. the topic of this posting is a little misleading given the example. It should have (and not does) read first class instead.]

Enjoy.

pre and post method hooks

2006-08-18T17:57:00.000-04:00

After being asked by Brian Olsen if it was possible to run some code before the body of a method within a new type of method constructor, I whipped up something similar to this (actually borrowed it from my IRC bot Haemus); but later extended it to support pre and post hooks. It currently looks like this:


prepost := getSlot("Block") clone setMessage(
  message(
    args := call message arguments
    list("post", "body", "pre") foreach(v, setSlot(v, args removeLast))
    pre setNextMessage(body)
    body setNextMessage(post)
    self getSlot("Block") clone setMessage(pre) setArgumentNames(args map(name)) setIsActivatable(true)
  )
)

And it can be used like this:


foo := prepost(a, b,
  // This code is the pre-method hook
  ("a = " .. a .. "; b = " .. b) println
,
  // This code is the actual method
  r := a + b
,
  // This is the post-method hook
  ("result = " .. r) println
)

As you can judge, the locals are shared amongst both pre/post hooks and the method itself. This is to allow for tasks such as normalization without repeating yourself. As a result, you'll need to be careful not to be surprised when naming slots.

Cleaning this up would be nice, allowing for optional pre/post hooks, but I'm not sure how to do it cleanly without keyword arguments. If anyone has any ideas, please post them.

Improved Date object (mostly) done

2006-08-05T16:20:00.000-04:00

I've completed work on the first revision of the new Date object. I say "new" but it's really the same one with a couple new methods added, and the backend tweaked to support timezones. If you want to have a go at this code, please feel free, it's up on my darcs repository:

http://repos.blurgle.ca/darcs/io

There is one caveat. This new Date doesn't support dates less than 1970 properly.
Please report any problems you have to me (I'm on IRC - freenode, #io is probably the best place, but in comments here is fine too); and note that this is just beta quality right now.

UPDATE: Would appear as though Steve isn't too happy with the change in semantics, and won't consider allowing the change in Date objects to go through, so I won't be updating this anymore -- not worth my time. I will however, create a Calendar object like I was going to to supplement this new Date, and if someone wants to convert it to C to replace the broken-ass Date object, they're free to be my guest.

Enjoy!

Working on the Date code...

2006-08-03T13:27:00.000-04:00

Finally up on my todo list is the Date object. It needs some overhauling to support time zones. Been putting this off for a long time and I'll finally commit to doing it now. Anyway, more news forthcoming.