Hypothetical Labs - Latest Comments

Re: Protected: Part 1: Introducing riak_core

Tim — Thu, 19 Aug 2010 10:28:34 -0000

Any chance of a post on luke? I've just dropped a question onto the basho issue tracker about support for map-reduce-merge (a la http://cs.baylor.edu/~speeg... - riak for data warehousing anyone? :)

Re: Protected: Part 1: Introducing riak_core

Ben Godfrey — Mon, 02 Aug 2010 09:38:30 -0000

riak_core sounds like an extremely useful framework. You guys are doing a great job of pushing out useful tools and knowledge. I look forward to the graph DB posts.

Re: Restarting This Thing

Vychodil Hynek — Thu, 29 Jul 2010 17:30:10 -0000

It sounds good. I'm looking forward to this.

Re: Restarting This Thing

Marcus — Thu, 29 Jul 2010 10:24:43 -0000

Me too looking forward to this.

Re: Restarting This Thing

grantmichaels — Thu, 29 Jul 2010 10:16:31 -0000

i'm very much looking forward to this =)

grantmichaels

Re: Erlang Pattern: The Router

kevin — Mon, 19 Oct 2009 17:47:25 -0000

@Dizzy - I'll have to think about this a bit. I knew going into this that we'd get bogus timeout messages but for what we were doing that was acceptable. We have fairly robust logging so between the data in the message and the log output we can debug timeouts.

@Hunter - The lookup was a simple ETS table which contained some metadata about the service (interface version, acceptable messages, etc). We used monitors to determine when to remove a service and judicious use of pg2 to sync up information across the cluster.

Re: Erlang Pattern: The Router

Hunter Morris — Mon, 19 Oct 2009 17:14:41 -0000

I like this.

What was the lookup mechanism in the recent implementation you talked about? I'm interested in how the "target" processes notify the lookup bookkeeping about their deaths.

Re: Erlang Pattern: The Router

Dizzy — Mon, 19 Oct 2009 15:49:48 -0000

I'll admit that this pattern bugs me a bit. The root of my discomfort is the fact that you're doing a gen:call on the router process, which causes the caller to setup a monitor on that (router) process. However, what we REALLY want to monitor is the target process. After all, if the target crashes, we'll never know how/why -- we'll just get a timeout from the router, which is misleading to say the least.

So there are two options, I suppose:
1. Do a call to get the target PID, followed by a call to that process
2. Do a cast to the router which in turn does a cast to the target

The downside with 1 is increased latency (likely). However, you get more meaningful errors, which in my book, is worth a bit of latency. Option 2 makes it impossible to know if the router or target actually recv'd the message.

A third option would be to split the difference like so:
1. Setup monitor on router
2. Cast request to router
3. Recv status notif from router with target pid
4. Setup monitor on target (delete router monitor)
5. Recv completion notice from target

This way you would know where the message fails, with slightly better concurrency. But you'd have to show me a pretty convincing chunk o' profiling to justify that over option 1. :)

My $0.02. :)

Re: CodeWriMo

Chuck McKnight — Mon, 19 Oct 2009 12:49:23 -0000

Just a thought, but what about having folks working on the docs in parallel to the coding? I tend to try to structure projects in that fashion so that the docs only need a little polishing at the end. :-)

Re: Tomorrow Night

Serge S — Mon, 28 Sep 2009 15:38:20 -0000

Kevin - your talk on WebMachine was not that long, but very inspiring - I actually looked into it and was seriously moved. I even posted a cool StickyNotes project WebMachine-y follow-up. Erlang rules even more than I thought :)

Re: Tomorrow Night

Kevin — Sat, 12 Sep 2009 10:42:35 -0000

Are the slides available? Or better yet, video?

Re: Tomorrow Night

Luc Castera — Thu, 10 Sep 2009 12:41:27 -0000

Kevin,

Thank you so much for coming to speak to the DC Erlang community.

I can't wait to hear your talk tonight.

Re: Tomorrow Night

Paul Barry — Wed, 09 Sep 2009 20:34:42 -0000

Looking forward to it. See you there!

Re: Win32 Linked-In Drivers and A Project Idea

kevin — Fri, 19 Jun 2009 07:22:03 -0000

@David - I looked at using couch_js.c but it's a wrapper around SpiderMonkey's JS shell which handles encoding/decoding data. It's not a linked-in driver and so Erlang has to talk to it over stdout/in. Not that's necessarily a bad thing, but it didn't fit my needs.

Re: Win32 Linked-In Drivers and A Project Idea

Sean Cribbs — Thu, 18 Jun 2009 22:53:43 -0000

@David
I think CouchDB uses an Erlang port to communicate with SpiderMonkey. Although not the same as shelling out, data still has to cross the serialization boundary.

Re: Win32 Linked-In Drivers and A Project Idea

David Budworth — Thu, 18 Jun 2009 22:45:00 -0000

Doesn't couchdb include a linked in spidermonkey driver already?

or do they just call the "js" binary and pipe through sdin/out?

Re: Win32 Linked-In Drivers and A Project Idea

kevin — Thu, 18 Jun 2009 22:27:58 -0000

I had the same thought myself but couldn't figure out where VC++ keeps that info. What should I look for? A link dependency on kernel32.lib?

Re: Hands-On Erlang Cancelled

Will Schenk — Tue, 16 Jun 2009 17:07:02 -0000

Wow that sucks... I was getting close to getting tickets!

Re: Tail Recursion: An Exhaustive Treatment

Serge — Sat, 30 May 2009 08:13:46 -0000

I especially like the limited ring for storing part of the trace as the counter argument to GvR's loss of debugging information in the Tail Call Optimized languages (in Part IV)

Re: Basic Erlang Driver Revisited

Matt Williamson — Wed, 27 May 2009 23:24:15 -0000

Also, I have a walkthrough for making a driver using the method described here: http://dawsdesign.com/drupa...

Re: Basic Erlang Driver Revisited

kevin — Wed, 27 May 2009 10:03:05 -0000

Matt - Thanks. I thought about using a single char but that seemed too restrictive.

James - baberl is working I'm doing for EA so they own the copyright. I own the copyright on the basic driver so that's assigned to Hypothetical Labs. I don't see any refs to EA in that code. If you find any let me know and I'll remove it.

Re: Basic Erlang Driver Revisited

James Bowes — Wed, 27 May 2009 09:23:46 -0000

Is copyright EA a copy-pasteo?

Re: Basic Erlang Driver Revisited

Matt Williamson — Wed, 27 May 2009 09:14:40 -0000

I like the way you used ASCII characters as the command instead of the way I did it with a single byte.

Re: More Screencasts

lenz — Thu, 21 May 2009 18:06:34 -0000

otp stuff ... i think there is plenty of "getting this started" things around now, otp is kind of underrepresented though.

... at least my impression :-)

cheers
lenz

Re: Thoughts on Training

kevin — Tue, 12 May 2009 21:29:20 -0000

Luc -

Hopefully my most recent posting addresses your first two concerns so I won't say more about those points here. What I do want to talk about is how the class differs from my screencasts.

The classes are primarily different from the screencasts in that we go into much more detail on each topic, especially gen_server and the OTP bits. Also, there are more lab exercises which allow everyone to get very comfortable with Erlang. I'd say everyone in the last class had at least one "aha!" moment even though most of them had watched the 'casts.

There's only so much you can cover in two days and I chose to focus on the practical basics. My goal for everyone who attends the class is to be comfortable enough with Erlang they could look at the source for a complex project, like webmachine or even CouchDB, and be able to figure out what's going on.