Saturday, July 16, 2016

Smalltalks 2015 videos now available

The videos from Smalltalks 2015 are now available here.

Stay tuned for coming information about Smalltalks 2016 :).

Sunday, June 26, 2016

Reliable email matters

Many of today's issues with software ultimately cause unreliable service.  Software's popularity does not seem greatly influenced by reliability, so the audience seems to tolerate the situation.  However, when unreliability becomes the norm, the resulting ecosystem is one in which nothing works as advertised.  You have effectively no recourse other than to roll out your own, become a system administrator, or put up with it.

This kind of environment directly limits what you can accomplish in life.  Take for instance email.  Although delivery was never guaranteed, at least you had some chance to track down problems and there seemed to be a general willingness to ensure correct transmission.  Today, emails simply vanish with no explanation, and you're not supposed to know what has happened.  After some debugging, the best working hypothesis for the latest occurrence is as follows:

Comcast silently refuses to deliver you emails that contain your email address.

To verify this hypothesis, I sent myself emails with just "blah@comcast.net" in the message body.  These emails did not bounce, did not show up in a junk email folder, and were not delivered.  But emails reading "blah@comcast.ne", with the last 't' missing, were delivered.

That aggressive spam filtering is a necessary evil, the usual excuse, doesn't cut it in this case.  Someone replies to you, and the text says "at some point, blah@comcast.net wrote:".  Or someone comments on a forwarded email of yours that reads "From: blah@comcast.net".  These ubiquitous, well established email body patterns are being dropped without notice.

This new form of unreliability started at least a few weeks ago.  Comcast's first approach to resolve the issue was to unilaterally reset my password on a Saturday, while stating the department taking action does not work on weekends.  When resetting a password predictably didn't fix the delivery problem, Comcast's final position was for me to complain to Thunderbird, GMail, and several other ISPs / email client software makers for their evident, collective, and synchronized fault.

The side effects of unreliable software are allowed to spread unchecked in part because, in an unknowable and incomprehensible software world, naturally there is no responsibility and thus no recourse.  Hence, the above diagnosis is merely a best working hypothesis.  Occam's razor suggests the email problem is Comcast's fault.  But how do you find where the problem actually is without access, much less appropriate support?

I don't think this will get any better as long as software and derived services can be sold without any form of accountability whatsoever.  Consequently, until then, protecting yourself from unreliability is up to you.  In the case of email, that means implementing and/or managing your own email server.  But where does that road end?  Email is hardly a top reliability concern.  The go-it-alone approach does not scale.

Tuesday, October 20, 2015

Smalltalks 2015 keynote speakers

Smalltalks 2015 is around the corner.  We're very pleased with this year's keynote presenters: John Brant, Damien Cassou, and Clément Béra.  Such quality speakers are possible thanks to our sponsors, community donors, and collaborators.  We really appreciate your support, thank you!

... I can't wait for the conference to start :).

Tuesday, October 06, 2015

Smalltalks 2009 videos online

I am very happy to report that Smalltalks 2009 videos are now online here, including the incredible talks by Dan Ingalls.

Monday, August 31, 2015

Smalltalks 2010 videos on YouTube

You can see the freshly uploaded playlist here!

Sunday, August 23, 2015

Camp Smalltalk PDX wrap up

We wrapped up Camp Smalltalk PDX tonight.  The Saturday barbeque with fresh Oregon food and the Flat Nines jazz band was really nice!  Thank you Instantiations, FAST, and others who contributed to make it such a great experience --- including the cooks Paul DeBruicker and Dave Caster.  The CTRL-H hackerspace was a welcoming venue.  Thank you CTRL-H!  We had room and amenities, they lent us their backyard for the barbeque, and we also heard about the hackerspace's member projects.  And we even got Camp Smalltalk shirts courtesy of Dave Caster.

Of course, there was a lot of Smalltalk.  I heard of people working on VA Smalltalk, Monticello, Squeak, Cuis, web frameworks, GemStone, and so on.  Personally, I had a lot of fun hacking some VM stuff until a while ago.  And it's not just the work itself --- it's also the people you meet, the connections you make, and the passion you can share.

Photos will become available I am sure --- such as here.  In the mean time, enjoy this preview :).



Tuesday, August 18, 2015

Camp Smalltalk PDX Thursday dinner

Attention Camp Smalltalk PDX attendees!  We now have a place for dinner on Thursday.  Feel free to drop by at pdx.st or at the Camp Smalltalk wiki page for details.

Smalltalks 2015 invitation

The Fundación Argentina de Smalltalk proudly invites you to one of the premier Smalltalk conferences in the world.  Let's meet in Buenos Aires, November 11-13!  For more details, see the invitation here.

Sunday, July 26, 2015

New Reference Finder / Weight Tracer

During ESUG's Show Us Your Projects, I gave a demo of a really fast reference finder I had written in Cuis a number of years ago.  During ESUG, Jan Vrany and I wrote an enhancement to the reference finder: a so-called weight tracer.  What this tracer does is tell you which objects only "hang" from a given object.  That is, if the given object goes away, the weight tracer shows what other objects would be collected as well.

Initially, the weight tracer required about two minutes per scan.  I managed to cut that in half at ESUG with some less than ideal hackery.  But today I really understood what was going on.  After deleting the unnecessary hackery, and with just a few tiny changes, the weight tracer runs just as quickly as the reference finder: a couple tenths of a second.

And it's tidy code, too :).

Saturday, July 18, 2015

Linked Weak Reference Arrays paper --- IWST 2015 prize winner

My paper on Linked Weak Reference Arrays was awarded a prize as the second best paper at IWST 2015.  I would like to thank the IWST 2015 chairs for the opportunity to submit and present my paper, as well as to LAM Research for sponsoring IWST.

In a nutshell, the paper asserts the following.  Whereas regular weak arrays tombstone slots ideally tombstone with the small integer zero, linked weak arrays tombstone with a linked list of small integers.  Each small integer tombstone points to the next tombstoned indexed slot.  The small integer zero indicates the end of the linked list.  The root of the linked list is stored in the linked weak array's first instance variable.  Data races are avoided by adopting the ephemeron finalization convention: when a linked weak array is queued for finalization, the VM turns it into a regular strong array.  When the linked weak array finishes mourning, it makes itself weak again.

This functionality requires a memory manager supporting dynamic slot reference strength.  There are examples of this type of memory manager in the wild.  Most of the complexity appears in the presence of an incremental garbage collector.  Changing weakness (as well as doing a become:, or a oneWayBecome:, or changing classes, etc) can easily invalidate the incremental garbage collector's working assumptions.  A number of years ago, I got HPS to handle this complexity for regular weak arrays and ephemerons.  GemStone/S has been using the improved HPS functionality in production for quite some time.  To date, I know of no problems with the implementation.

The benefit of this different approach to weak array finalization is that the image no longer has to reconstruct information the garbage collector knew.  That is, when a linked weak array mourns, it does not have to perform linear search to find where the garbage collector "hid" the tombstones.  Even better, measurements indicate the linked weak array mourning overhead is lower than that of a regular weak array.  Linked weak array mourning does not have to send the message #size, and does not need a #to:do: loop.  The baseline speed improvement, when every slot is tombstoned, is about 30% (Cuis on Cog r3164).

Regarding the second volume of my Fundamentals book, the next chapter to write is on weak references.  How convenient!

See you next year :).