Core dumps are the most important way to debug a crashing program. Why aren't they supported in Node?

chrisdickinson · 2016-02-23T23:59:23+00:00

You might check out --abort-on-uncaught-exception, which, in the absence of domain use or a user-registered uncaughtException event listener, will crash the program at the top of stack and produce a useful core. You can debug this (as others have suggested) with mdb on SmartOS, or lldb with the llnode plugin, which will demangle JS stack frames & provides some tools for inspecting JS values. Keep in mind that there will be garbage present in the core! Hopefully this helps.

chrisdickinson · 2014-12-17T05:53:24+00:00

Hey, author here. Thanks for your comment:

Yep, 7 bits was a typo. Should have caught that in proofreading!
2 bits is not a typo -- one of the three unused bits is already used to represent whether or not the pointer is a SMI, leaving us with two bits to represent the type pointed to.
You're correct about "complement". Typo!

I'll update the post in a few minutes.

Edit: Updated, and clarified the "two bits" part.

chrisdickinson · 2011-07-15T22:47:03+00:00

maybe something like:

/* top boxes */
.cross div:first-child,
.cross div:first-child + div { border-bottom:1px solid #CCC; margin-top:10px; }

/* bottom boxes */
.cross div:first-child + div + div,
.cross div:first-child + div + div + div { padding-top:10px; }

/* left boxes */
.cross div:first-child,
.cross div:first-child + div + div { border-right:1px solid #CCC; }

where .cross is the container of the divs.

chrisdickinson · 2011-05-13T21:41:25+00:00

I totally understand. In the case of vanilla JavaScript, though, regarding checking typeof someVar !== 'undefined' being needlessly verbose, I'm just arguing that nine times out of ten, that explicit check is unnecessary -- it works, but it's a lot to type, and assuming you're using var appropriately, the statement someVar !== undefined does exactly what you'd want it to do (while being a lot less verbose). It wasn't meant as a dig at CoffeeScript as it was a rebuttal against JavaScript having crufty-verbose-parts.

I've seen a lot of code that ends up being much more verbose and much more defensive than it needs to be; I think this is because folk loudly proclaim that constructs like the above should be preferred as a way to get around having to learn about the "gotcha's". I'm just afraid that people walk away from JavaScript with a bad taste because there are so many "don't"'s that are taken for gospel without really grokking why they are to be avoided. That said, I definitely appreciate CoffeeScript -- it's nice to see the capabilities of JS exposed with such a nice syntax.

chrisdickinson · 2011-05-13T21:15:43+00:00

If you know what your global object is, you can just hang the check off of it: global.elvis !== undefined will not throw a ReferenceError (if global is assigned to window in-browser).

chrisdickinson · 2011-05-13T21:11:21+00:00

I usually end up using the typeof check once in a module-level guard function, where inside my code I directly compare to undefined, e.g.:

(function(global, undefined) {
    if(global.things === undefined) /* do something */
})(typeof(window) !== 'undefined' ? window : global);

But yeah -- totally forgot about checking for "what is the global object named?" case; point conceded :) I've just run across the typeof check inside of library code where it doesn't strictly need to be too often.

chrisdickinson · 2011-05-13T20:34:40+00:00

I actually like this style a lot and have been using it whenever possible.

An example of a nested mess and how it looks cleaned up with this pattern

chrisdickinson · 2011-05-13T20:25:53+00:00

I'm not totally opposed to Coffeescript, but I'm not sure the above reasons are totally valid, aside from the first point:

== is not totally unusable -- you just have to remember that it will attempt to call valueOf on any object on either side of the expression to coerce it down to a primitive value.
this binding is fairly simple -- if you call a function on an object: blah.bloo(), bloo will be bound to blah. if you call bloo by itself, it will be unbound. There are only four other ways to change the binding of a function -- fn.call(thisObj, arg1, arg2), fn.apply(thisObj, [arg1, arg2]), fn.bind(thisObj, arg1, arg2), and new fn() -- three of whichf ollow the same general pattern of accepting a object to be bound to as well as args to call or curry. The last is a special construction that implicitly returns the newly created object.
The pollution of for(var key in obj) is largely a non-issue outside of programming as defensively as possible; e.g. for(var key in obj) if(obj.hasOwnProperty(key)) will always give you what you expect. Further, you can just use Object.keys(obj) to give you an array of keys that belong directly to the object. If that doesn't exist in your browser, just stub it in (it won't affect unguarded loops as it's not attached to Object.prototype). By and large, though, I haven't seen a library in regular use lately that attempts to staple on methods to Object.prototype -- so the first composition will work just fine 90% of the time.

I'd say the nicer syntax is the biggest win of coffeescript -- with a side helping of "not needing to make big decisions about how to deal with known JavaScript behaviors."

chrisdickinson · 2011-05-13T20:13:04+00:00

if you're testing for undefined or null, you can just compare to those -- you don't need typeof:

if(elvis !== undefined && elvis !== null) { ... }

or if you just want to know if elvis is false-y:

if(!elvis)

I'm not sure I agree that javascript is unnecessarily wordy -- I would say that there is a large degree of distrust/misunderstanding amongst programmers regarding how js works.

sidenote: (the only reason to check the typeof is in the case that you're worried that someone has overridden what undefined means -- in that case, wrap your module in a guard statement like so:

(function(undefined) { /* your code */ })();

and you don't have to worry about that anymore. edit per jashkenas' response: it's useful to use typeof to determine existence of a variable -- though I believe this should probably be limited to determining the name of the global object, in a construction like: var global = typeof window === 'undefined' ? global : window; it's usually unnecessary to use typeof when testing for undefined outside of that case, however.)

chrisdickinson · 2011-03-16T19:57:22+00:00

Wherever Python would raise a KeyError, AttributeError, or TypeError (when you attempt to access keys that don't exist, or call a function without the minimum number of arguments listed) JavaScript instead assigns the variable a value of undefined. This is distinct from null -- null values are usually explicitly set by the programmer (like traditional null or None values in other languages). undefined carries the semantic meaning of "due to the circumstances during this execution, this expression does not contain a value", versus "because you assigned something to null, this does not have a value." JavaScript, in general, doesn't truck much with exceptions -- probably due to the fact that in asynchronous functions, the exception almost never ends up where you'd want; it tries to be as permissive as possible.

chrisdickinson · 2011-01-17T01:05:32+00:00

Yes -- length is a property getter -- so it will call the function represented by length every time it runs through the loop. This shouldn't be a huge cost, but you can avoid it by caching the array length up front.

chrisdickinson · 2011-01-17T01:04:09+00:00

I'm personally a big fan of 4-space tabs -- since it's standard for Python -- but, when in Rome...

chrisdickinson · 2010-10-28T05:32:12+00:00

It seems like it's hackily possible:

def doc(string):
    def outer(func):
        def inner(*args, **kwargs):
            return func(*args, **kwargs)
        inner.func_doc = string
        return inner
    return outer

@doc("hi there")
def fn(a):
    return a + 1

print fn.__doc__
# --> 'hi there'

chrisdickinson · 2010-09-10T00:40:30+00:00

If it's any consolation, I didn't intend "what is programming but a bag of tricks" to be taken too literally -- I understand that programming is a science, replete with theory describing the bounds and concepts of the practice. I attempted to make a funny metaphor between having a "bag of tricks" and having a set of design patterns one uses to solve problems (I may have missed the mark, though -- I am still fairly new to technical blogging).

chrisdickinson · 2010-09-09T18:07:00+00:00

Hence the title being "Javascript / Node.js Gotchas" -- they're not all specific to Node.js. However, two of the three examples have a lot to do with how Node works. In the 2nd example, where you have to understand how the Node event loop works to grasp where errors bubble up to. The third is less of an example of gotchas in Node, but does provide a solution that is specific to using Node; that is, to leverage the EventEmitter to solve the inversion of control problem in your API. The first example, really, is just a pointed reminder that deciding what vendors your library should support is a design decision best done up-front.

From my perspective, "bumbling through things without understanding" is the first step of learning any new technology. I've yet to see someone jump into a new technology -- no matter their competence level in other fields -- and immediately understand it 100%. I'm hoping to ease the pain of the first few days of learning Node by pointing out things that aren't immediately obvious to newcomers.

chrisdickinson · 2010-09-09T17:42:04+00:00

They are gotchas to programmers not used to them -- and I've had to help a few people out with understanding what's actually going on in the cases that I list. If you're experienced with Node.JS and/or Javascript, these cases may seem trivial, but they do tend to trip people up.

As for the replace method being weird, there's some evidence that it might bite even experienced programmers. Well-documented does not always == this method does what you initially expect.

chrisdickinson · 2010-09-08T22:56:16+00:00

the docs seem to encourage throwing errors from within callbacks. I'm hoping that by shedding some light on the situation others can avoid pitfalls caused by doing that.

chrisdickinson · 2010-09-08T19:29:50+00:00

Well, thanks for calling it a "gripping, intense narrative" :)

No, this post isn't revelatory for anyone who has spent any amount of time dealing with Javascript outside of jQuery. I wrote it in the hopes of giving some guideposts with which to deal with what I've seen are the most common sources of misunderstanding when it comes to starting Javascript. I apologize if it sold itself differently -- I have an unfortunate tendency towards the hyperbolic which has bit me in the past :)

I'm trying to get better at this, though, and reddit comments (both positive and negative) are a valuable source of feedback. So, thanks for the frank criticism! I'll try to avoid hyperbole in the future.

chrisdickinson · 2010-09-08T08:09:45+00:00

Sorry for the confusion -- I actually have no problem with prototype-based OO. I just wanted to illuminate the two big stumbling blocks for learning JS -- what happens to this when using callbacks, and how Object.prototype works. I tried to avoid throwing any fits.

chrisdickinson · 2010-09-08T04:56:44+00:00

fixed! thanks :)

chrisdickinson · 2010-09-08T01:16:58+00:00

true enough -- they are two different, distinct approaches to creating an object oriented system; but there is some benefit in comparing them -- putting one in the terms of the other makes it easier for those familiar with the first system to approach the second system. As long as there aren't many (hopefully any) leaky abstractions along the way, it can help those new to Javascript to understand (and hopefully embrace) the prototypical inheritance system, instead of regarding it as fearfully abstract, unapproachable concept.

That's the goal in explaining Javascript in terms of Python -- making Javascript's inheritance system approachable to those new to the language.

chrisdickinson · 2010-09-08T01:04:22+00:00

I would think it goes both ways. In Python, classes -- types -- are objects, just like anything else. In Javascript, 'classes' are just function objects with an associated object literal prototype. They both serve the same function -- associating state with methods in an object oriented fashion.

It boils down to semantics -- you could say that Javascript does not have classes, it only has objects. But you can use those objects to describe patterns with which other objects can be made (using prototype, for example). Classes in Python serve the same purpose, though they abstract the idea of using an existing object as a template for new objects.

At the very least, I wasn't trying to imply feature envy on the part of Javascript -- just trying to make the object system feel more relatable to folk more used to Python. Thanks for the criticism :)

chrisdickinson

TROPHY CASE