Disqus - Friends of kasajian

Re: Too much online?

meshula — Fri, 13 Nov 2009 01:39:46 -0000

Your mileage may vary :) I personally expect to be messing with things that haven't even been invented yet. Who knows, right?

Re: Coal, Glitchy Update Loops, and Waiting

meshula — Sat, 14 Nov 2009 17:01:01 -0000

Important note, the technique related in this post relates to Windows XP.

@Repi mentioned on twitter:
Yes, Sleep() seems to be much more accurate now on Vista/Win7. Probably related to the HPET

All this complexity might not be necessary now...

Re: Communicating Sequential Processes

meshula — Mon, 07 Dec 2009 01:51:22 -0000

Oops! Thanks for pointing that out. It's now fixed.

Re: Mujik [iPhone, Sound]

meshula — Tue, 29 Dec 2009 16:56:30 -0000

Entering for a promo code :)

Re: These are the ten best video games of the decade, dammit!

meshula — Sun, 03 Jan 2010 02:49:23 -0000

FFVII or HL2 FTW.

Re: Screen Space Ambient Occlusion

meshula — Mon, 04 Jan 2010 03:18:03 -0000

traceback: http://d.hatena.ne.jp/tueda...

Re: Fine Print

meshula — Sun, 21 Mar 2010 17:36:41 -0000

Kevin, thanks for the nice comment. I don't have contact info for you, but would be happy to answer your question...

Re: The Science of Telepathy

meshula — Sun, 21 Mar 2010 17:42:22 -0000

@Gina lots of people have definitely experienced "completing each other's sentences," which means the experience you describe might not be so unfamiliar to most people!

Re: TextScanner, now in C

meshula — Wed, 24 Mar 2010 10:23:43 -0000

Thanks, glad you like it :) You've posted so much useful stuff, so thanks to you too for your postings.

Re: Neural Architecture

meshula — Sun, 25 Apr 2010 02:00:11 -0000

@Trung: I got my info out of books, such as Neuroethology by D.W. Guthrie. A great place to start is in college level first year biology text books. Most of them have several chapters on neural architecture. There is a journal that is very helpful - the journal of computational biology. Another great resource is the Santa Fe Institute - http://www.santafe.edu/

Re: A simple LSystem in Python

meshula — Sat, 12 Jun 2010 02:28:33 -0000

Hey, very cool! Thanks for the mention in your new code.

Re: Designed in California

meshula — Tue, 21 Jun 2011 22:27:35 -0000

My old brown Zune says "Hello from Seattle" on the back.

Re: Writing Your Own WebSocket Server « #AltDevBlogADay

meshula — Mon, 23 Jan 2012 02:27:26 -0000

I had a web socket server working with the old protocol (which is still alive in Safari). For the new protocol, I'd got as far as a successful handshake, but hadn't worked out what to do next. Thanks for this article!

Re: #AltDevBlogADay » A Coroutine Kernel in C#

meshula — Sun, 09 Sep 2012 17:08:24 -0000

This is a good set of concepts, and a cool way to implement it in C#.

Re: #AltDevBlogADay » A Coroutine Kernel in C#

meshula — Sun, 09 Sep 2012 17:12:53 -0000

For C++ I'd hold out for an implementation built around lambdas. I've never seen (or written) a version of yield that wasn't super vulnerable to breaking when the optimizer decides to rearrange things a little. Here's a typical spooky example: http://www.crystalclearsoft... I think the last time I saw it usefully pulled off was with a frozen version of gcc 2.9x targetting PS2.

Re: The Best Alternative Apps to Everything in Adobe Creative Cloud

meshula — Wed, 23 Oct 2013 21:47:15 -0000

As an Illustrator alternative, Pixelmator has Vectormator hidden inside it. http://www.pixelmator.com/b...

Re: ET Phone Home

meshula — Fri, 21 Nov 2014 10:15:01 -0000

Absolutely beautiful shots!

Re: MCOR’s Desktop 3D Paper Printing Aspirations?

meshula — Sat, 06 Dec 2014 14:54:00 -0000

Although I appreciate the ingenious and clever technology, I come from an area that was once heavily forested, I hope this technology does not become widespread. The inclusion of recycled material would not offset the waste.

Re: Joe Duffy - Performance Culture

meshula — Mon, 11 Apr 2016 10:35:45 -0000

Great post, and I agree with your stance. This back out point all by itself is troubling though. Dev A checks in a change that introduces an undetected n squared pathology, dev B, years later triggers it. The likely outcome given time constraints and fear of undetected regressions due to dependencies on A's original work, is that dev B will rewrite around the pathology. It seems like you need additional culture formalized on tracking and correcting the root pathology.

Re: Joe Duffy - Blogging about Midori

Joe Duffy — Sun, 10 Jan 2016 13:43:07 -0000

On #1, sadly I wish it were possible, but -- for reasons too complex to get into here -- trust me that it's not.

On #2, this is an superb idea. There were many things we tried that didn't work, either outright, or they had to be significantly changed. (I'd say writing an entire OS with an explicit callback async model was one of them.) I've added this post to my backlog. I probably won't get to it until later in the series, however look for something in the February-to-March timeframe. Thanks so much for the suggestion.

Re: Joe Duffy - A few thoughts on the role of software architects

Joe Duffy — Mon, 18 Jan 2016 12:57:32 -0000

Absolutely agree. If I had written the article today, I'd have emphasized this point more. I actively avoid creating cultures where all ideas come from the senior individuals, and/or ideas aren't properly discussed and debated. The RFC process is a great one to follow. Thanks for sharing!

Re: Joe Duffy - The Error Model

Joe Duffy — Mon, 08 Feb 2016 21:00:36 -0000

That was a boneheaded and accidental omission. Of course Erlang was hugely influential on not just the philosophy ("let it crash") but also the whole fault-tolerant, fine-grained process and isolation architecture. I should have spent more time covering this -- the post was already rather lengthy -- but I did just patch it with a paragraph. Better than nothing. Thanks for the feedback.

Re: Joe Duffy - The Error Model

Joe Duffy — Mon, 08 Feb 2016 21:01:55 -0000

Colin, thanks for the pointer. I didn't realize this had graduated from being GCC-specific to something Clang supports too. I absolutely love the idea of incremental adoption of a RAII programming style within C, without needing to buy into C++ destructors, copy constructors, etc., in their full glory. I wonder if it has a chance of standardization.

Re: Joe Duffy - The Error Model

Joe Duffy — Mon, 08 Feb 2016 21:05:45 -0000

Inference is possible, however it brings about a few problems.

First, inference for properties like these are more difficult than, say, an ML Hindley-Milner type system that is designed to facilitate inference (https://en.wikipedia.org/wi.... As a result, simple refactorings of the implementation might change the result.

Second, these inferred properties are part of a function's signature. It's a matter of personal taste, however I always prefer that things like these -- which I think of as "chiseled in stone" (at least for public APIs) -- are explicitly stated.

The final point is that, with some of the more advanced features I mention later on in the article -- non-null types and slices, namely -- most of the need to explicitly annotate contracts fades into the background. You go from nearly every method needing contracts to a vast subset of them. At this point, I think the burden is well within reason, for the payoff you get (auto-documenting APIs, robust error checking, versionability of API behavior outside of the type system, etc). YMMV, of course.

Re: Joe Duffy - The Error Model

Joe Duffy — Tue, 09 Feb 2016 19:07:32 -0000

You're right, there's a lot more to cover here.

The answer to most of your questions is "yes." Being a pattern, it did have many permutations. We always thought we'd more concretely embellish the common patterns as 1st class mechanisms, but we never did. I'll admit, keepers were not nearly as popular as the other error handling mechanisms described in the post.

The encouraged pattern was to associate the keeper with a context. For example, maybe you have a FilesystemContext you're using for all filesystem operations. Because Midori used capabilities, capability objects like files were always derived from other capability objects, making the context flow naturally without using ambient state like static variables. So, you'd provide the keeper to the context when first asking for the Filesystem capability, and then it'd flow transparently to all subsequent operations in your session.

The "pass an error handler" pattern was certainly used in a few places, but it's not nearly as elegant.

Chaining was definitely an elegant way to compose keepers. It's relatively common that you just want to override, say, one method on the keeper, and chain the others to a NullKeeper that always propagates the error rather than handling it.

HTH.