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 :).

Monday, June 29, 2015

Camp Smalltalk Portland 2015 --- registration is open!

Camp Smalltalk Portland 2015 in beautiful Oregon is go for August 21st through the 23rd!  (and if you arrive earlier on the 20th that's cool too)  Please register for the event here --- help us by filling in the questions so you can get your event shirt.  And also see that we're having a BBQ with live music on Saturday.  You can't miss it!

Wednesday, May 06, 2015

Camp Smalltalk Portland 2015

Dear artful programming enthusiasts,

The Pacific Northwest Smalltalk crew would like to invite you to Camp Smalltalk PDX this summer.  Come join us August 21-23 in beautiful Portland, Oregon!

We all know coding is a lot of fun, and that the best coding is done with the delete key.  Accordingly, Camp Smalltalk PDX will be at Portland’s CTRL-H hackerspace, http://www.ctrlh.org.

There is no set schedule, but of course we all have strong interests.  Some of the areas that will surely be covered include:

* Smalltalk on small devices, such as Scratch on Raspberry PI
* Web frameworks such as Seaside
* Virtual machine implementations
* Data processing applications
* Language design, Smalltalk and beyond

If you are curious about Smalltalk, feel free to drop by and give Smalltalk a try.

And yes, there are also the well known regulars --- we all know who you are :).  It’s time to catch up and plot inventing our future.

Feel free to contact us directly if you have questions regarding travel or accommodations.  Also, if you know you will be coming and you haven’t completed our survey yet, doing so will help us coordinate the infrastructure around the event: http://goo.gl/forms/XVLOLRe8OF.  For event information, see here: http://www.pdx.st/.  As the dates get closer, additional organization information may become available here: http://wiki.squeak.org/squeak/811.


See you in Portland!

Saturday, May 02, 2015

Windows 95 still flies today

Remember the days of Windows 95?  After 49.7 days of continued operation, the system would crash.  That was before the Y2K bug, when nobody knew or even expected that a counter would overflow.  We should have learned our lesson by now: even seriously defective software can hang around for a very long time.

Unfortunately, we can't quite start feeling warm and fuzzy yet.  Recently, it was discovered that a Boeing 787's electrical system will shut down after 248 days of continued operation.  The result?  Among other things, the cockpit controls no longer work.  And with fly by wire, that means pilots can become irrelevant at any time.


In other words, please make sure you periodically reboot the 787 until that software bug is fixed.  If the problem is ever fixed.

At least this is a bit of technology we all understand.  That is, rebooting makes flaky programs appear to work for a bit longer.  The underlying assumption is deeply problematic.  The message is that this is the extent to which we are supposed to participate in our technological adventure.  You yearn of concerning yourself with whether the maintenance crew hit ctrl-alt-del before take off, don't you?  Wait, why isn't the expert doing that in the first place?  Or even better: how is it that a simple counter overflow can completely disable a modern airplane?  How are these machines being designed such that these failure modes are even possible?

But forget wondering what other 787 bugs could exist when that kind of defect went undetected.  What's next?  Cars that drive themselves (except when they don't)?  Smart electric meters, traffic lights, and gasoline pumps connected to the internet securely (except when security isn't --- really --- there)?  Everything will be just fine, right?

Seriously, these are not toys or apps.  Please demand reliable software.

Thursday, April 02, 2015

Fundamentals volume 2 --- chapter 7 is done

Wow, it's been such a long time since I posted updates.  Surely a lot of stuff has been going on since December 2012, but still!

I found a new editor and the teamwork is great.  Since none of volume 2's text had been edited, the first order of business was to review the ~200 extant pages.  This took a while, but I'm really happy because we ended up deleting roughly 15 pages --- and that's the net effect, because I added some extra material as I went through the text too.

Not long ago we started reviewing chapter 7, and a few weeks ago we finally got to the tip of the written text.  And now, all the text for chapter 7 ("On Threading") is basically done.  The exercises include real gems.  But there are "only" 27 of them right now, so who knows... I might add more over time :).

Chapter 8, "On Recursion", is next.  Reviewing my notes for the chapter was exciting, there is a lot of new material I haven't talked about yet!

The draft is at 204 pages.

Thursday, March 19, 2015

Camp Smalltalk PDX, August 20-23

A small group of Smalltalkers have been discussing the possibility of having a Camp Smalltalk in Portland Oregon, August 20-23.  If you think you might be interested in attending such a gathering, please let us know filling our short survey.  We also encourage you to join the SCONA mailing list here.

The proposed format is:

* Thursday 20th evening prior: An informal welcoming dinner at a local pub or similar.

* Friday 21st morning - Sunday 23rd afternoon: The event proper, consisting of a blend of scheduled talks or discussions and free-form pair programming.

* Sunday 23rd evening - Farewell dinner.

The whole event is envisioned as being informal enough that showing up for only part of the time is perfectly acceptable.

Your responses will help us with our planning efforts.  Feel free to forward this message to any other Smalltalk forums or individual Smalltalkers you think might be interested.

Saturday, December 27, 2014

3x+1 and T^n(k)'s evaluation matrix

In previous posts I've been talking about the 3x+1 problem and the fabulous T(x) function that satisfies

T^n(k2^n + r) = k3^j + T^n(r)

If you let 0 <= r < 2^n, and evaluate T^m(x) for all the resulting values, and for 1 < m <= n, you get a so-called evaluation matrix.  In this evaluation matrix, such as the one below,
  • 16k + 0    8k + 0    4k + 0    2k + 0    1k + 0
  • 16k + 1    24k + 2    12k + 1    18k + 2    9k + 1
  • 16k + 2    8k + 1    12k + 2    6k + 1    9k + 2
  • 16k + 3    24k + 5    36k + 8    18k + 4    9k + 2
  • 16k + 4    8k + 2    4k + 1    6k + 2    3k + 1
  • 16k + 5    24k + 8    12k + 4    6k + 2    3k + 1
  • 16k + 6    8k + 3    12k + 5    18k + 8    9k + 4
  • 16k + 7    24k + 11    36k + 17    54k + 26    27k + 13
  • 16k + 8    8k + 4    4k + 2    2k + 1    3k + 2
  • 16k + 9    24k + 14    12k + 7    18k + 11    27k + 17
  • 16k + 10    8k + 5    12k + 8    6k + 4    3k + 2
  • 16k + 11    24k + 17    36k + 26    18k + 13    27k + 20
  • 16k + 12    8k + 6    4k + 3    6k + 5    9k + 8
  • 16k + 13    24k + 20    12k + 10    6k + 5    9k + 8
  • 16k + 14    8k + 7    12k + 11    18k + 17    27k + 26
  • 16k + 15    24k + 23    36k + 35    54k + 53    81k + 80
there are various k 2^a 3^b + r expressions.  I just proved that all such expressions satisfy 0 <= r < 2^a 3^b.  In other words, T^m(r) is the remainder of dividing T^m(x) by the corresponding 2^a 3^b.

Sunday, December 14, 2014

Smalltalks 2014 videos now available

All Smalltalks 2014 videos are now available here.  Enjoy, and happy holidays!

Tuesday, October 28, 2014

Smalltalks 2014 conference schedule

Hello from FAST.  Smalltalks 2014's schedule is now available at our website.  We are very pleased with this year's strong program.  See you at the conference!