02:53 <MikeKnoop> Anyone active?

02:53 <joeytwiddle> athletes training for the olympics

02:54 <MikeKnoop> And apparently, me

02:56 <MikeKnoop> I'm tripping up with CS (1.2.0) and Node (0.6.1)

02:56 <MikeKnoop> Keeping hitting `Error: watch EMFILE` when watching a dir with approx 90 files

02:57 <MikeKnoop> Typical advise is to increase OS file descriptor limit (which I've done, to an absurd amount for both my user and root) but still hitting the same error

03:00 <MikeKnoop> -- any thoughts are welcome

03:00 <joeytwiddle> have you tried watching only the folder itself? on my linux, the folder date changes whenever a file in that dir is written

03:01 <* joeytwiddle> is not particularly confident about his ability to help

03:03 <MikeKnoop> Well I am using a command like `coffee -c -b -o target --watch source` which I believe is watching the folder itself

03:03 <joeytwiddle> dang

03:06 <MikeKnoop> I actually think it might have to do with a folder-depth issue

03:07 <MikeKnoop> because I can drill down one more folder and it works (including if I add a bunch of copy-pasted files into that drilled down folder such that the file count exceeds what it was before I drilled down)

03:51 <MikeKnoop> temporary solution is to fallback to CoffeeSccript 1.1.3

03:51 <MikeKnoop> Which uses the older watchFile command, I think

03:51 <joeytwiddle> :D

07:05 <manveru> yeah, had nothing but trouble with the new watcher

07:05 <manveru> here it just silently stops noticing changes to files

07:06 <joeytwiddle> that's unfortunate. it's supposed to have a new feature now

07:06 <joeytwiddle> i think that it will recognise a file changing, if the inode is entirely replaced

07:06 <manveru> i replaced it with `watch -n 1 'coffee -o public/js coffee/*.coffee 2>&1'`

07:07 <manveru> yeah, but different editors change files differently

07:07 <joeytwiddle> i think that's what it was trying to address

07:08 <manveru> well, another way would be using inotifywait

07:09 <manveru> but i don't have inotify-tools on every machine

07:14 <superjoe> I have few enough files that I just use `watch make`

07:34 <test__> test

07:34 <test__> :)

10:54 <CIA-132> coffee-script-tmbundle: Kris Khaira master * ra24b9d5 / Syntaxes/CoffeeScript.tmLanguage : Merge git://github.com/jashkenas/coffee-script-tmbundle - http://git.io/AN0fgQ

10:54 <CIA-132> coffee-script-tmbundle: Jeremy Ashkenas master * r2930525 / (3 files):

10:54 <CIA-132> coffee-script-tmbundle: Merge pull request #96 from kriskhaira/master

10:54 <CIA-132> coffee-script-tmbundle: Snippets for comment headers. - http://git.io/1le4fQ

11:02 <epegzz> can i write something like that in multiple lines?: foo.bar().baz().buz().boo()

11:02 <epegzz> in python you can do this by ending a line with '\'

11:04 <shesek_> yes, you can

11:04 <shesek_> epegzz, http://coffeescript.org/#try:foo%0A%20%20.bar()%0A%20%20.baz()%0A%20%20.buz()%0A%20%20.boo()

11:05 <shesek_> I prefer to keep the dots on the beginning of the line, but it works on the end too

11:05 <epegzz> cool, thx shesek_

11:05 <epegzz> yeah, me too (:

11:05 <epegzz> nice

12:14 <CIA-132> coffee-script: Trevor Burnham master * rde99704 / (lib/coffee-script/browser.js src/browser.coffee): Making bare the default for eval in the browser (fixes #2148) - http://git.io/r4cSRA

12:24 <Visualiza> yo. are people getting TextMate 2 code folding to work with coffeescript?

13:03 <lucian> dkog: it's exactly like in js

14:45 <jscheel> jashkenas: hey man, I'm a little confused on how the "this" context binding has changed. Here's an example with the old way and new way: https://gist.github.com/ab880137b25c7d45c0c6

14:45 <jscheel> jashkenas: specifically, the "start" callback in the new way does not have any access to what I would expect @ to represent (the instance of foo)

14:46 <jscheel> jashkenas: also, I noticed that "console.log @" compiles to "console.log(_this.)"

14:46 <jscheel> (with a trailing dot)

14:50 <jashkenas> eh?

14:50 <shesek_> jscheel, it should be the `Foo` instance

14:51 <shesek_> and why do people use empty parentheses when there are no arguments?

14:51 <jscheel> shesek_: I usually don't, but I did for expressiveness here

14:51 <jashkenas> re: the "_this." -- that's bad.

14:51 <shesek_> how's that more expressive?

14:51 <jashkenas> I haven't seen that before.

14:52 <jscheel> shesek_: it's more explicit, clearer to read quickly that you are defining a function. It's not really a big idea

14:52 <jscheel> s/idea/deal/

14:52 <jashkenas> start *does* have access to the instance of Foo.

14:54 <jscheel> jashkenas: well, I would expect it to, but I'm getting _this = undefined

14:54 <jashkenas> then something else is up.

14:54 <shesek_> jscheel, you have an invisible character after the `@` that causes the `.`

14:54 <jscheel> shesek_: ah, thanks

14:55 <shesek_> jscheel, are you sure you're using `new` when creating the instance?

14:55 <jscheel> shesek_: wait, nope, no character

14:55 <jscheel> after there

14:55 <jscheel> shesek_: yes

14:56 <shesek_> the function in `start` will have `this` set to whatever `this` is inside `Foo`

14:57 <shesek_> I mean, `_this` in JavaScript that's compiled from `this`

14:57 <jscheel> whoa

14:57 <jscheel> wait a second

14:57 <jscheel> weird

14:57 <shesek_> my guess is that the console.log doesn't display that because of the invisible character (that _is_ there)

14:57 <jscheel> so, the gist was just a quick explanation

14:57 <jashkenas> invisible character, whoa.

14:58 <jashkenas> holy cow -- that's right.

14:58 <jashkenas> how'd that get there?

14:58 <jscheel> I have no idea

14:58 <jscheel> :)

14:58 <jashkenas> whew

14:58 <jashkenas> had me scared for a minute.

14:58 <shesek_> jashkenas, it drove me insane for a minute or two - I tried to reproduce it and just couldn't

14:58 <jashkenas> that was looking like a "how the hell did that happen" bug.

14:58 <jashkenas> good on ya from typing it from scratch.

14:59 <jashkenas> I just copied and pasted, and therefore was seeing it.

14:59 <jscheel> that's what I get for typing in between jsfiddle, coffeescript.org, and sublime text

14:59 <shesek_> I rewrote pretty much the entire structure in his code and couldn't get it to reproduce, than pasting it caused it to happen :O

14:59 <jscheel> crazy

14:59 <shesek_> yeah, I tried to find a more minimal case where it happens

14:59 <jashkenas> that's what CoffeeScript get for supporting Unicode identifiers.

14:59 <jscheel> anyways, the binding thing is weird too. I see something else going on

14:59 <jscheel> my demo actually produces the correct code

14:59 <jscheel> the closure is right

14:59 <jscheel> but

15:00 <jscheel> that was just demo code I type quickly

15:00 <jscheel> but

15:00 <jscheel> in my actual code

15:00 <jscheel> _this = this isn't in the outer function

15:01 <jscheel> oh, nevermind yes it is

15:01 <jscheel> couple of hard refreshes in chrome

15:01 <jscheel> but even with it there

15:01 <jscheel> I throw a debugger in start

15:01 <jscheel> try to look at _this in my inspector

15:01 <jscheel> ReferenceError: _this is not defined

15:02 <jscheel> hmm

15:04 <jscheel> this makes no sense

15:04 <jscheel> that _this would not be defined

15:08 <shesek_> are you sure you're in a breakpoint in the correct scope when you're checking that?

15:11 <jscheel> shesek_: here's my actual code (not dummy code) https://gist.github.com/e782d55641a1331cf5a8

15:12 <jscheel> shesek_: and here's what that compiles to: https://gist.github.com/8d14667c9e59b129be41

15:12 <jscheel> when chrome hits that debugger, and I type "_this" I get the reference error

15:12 <shesek_> Assuming its Backbone, @$('.library .assets > li') is the same as @$(@el).find(...)

15:12 <jscheel> shesek_: yes

15:13 <jscheel> but el is actually a little further out that that in the dom

15:13 <jscheel> and @$ is already scoped to @el, so I figured I would save some typing :)

15:14 <jscheel> exact opposite of empty parentheses on functions I guess

15:14 <shesek_> what you're saying makes no sense... you know that @$ is already scoped to @el, yet @el is little further in the dom than what @$ is scoped to?

15:15 <jscheel> it's further up

15:15 <jscheel> so

15:15 <shesek_> and btw, you have `@$el` instead of doing $(@el), and the draggable parameters accepts plain DOM element, no need to jqueryify them

15:15 <shesek_> but back to your original issue...

15:16 <jscheel> ah, good point

15:16 <jscheel> btw, ising 0.5.3 still

15:17 <shesek_> put a breakpoint in the line that assigns to $drop, and check the value of `this` and `_this` there

15:17 <shesek_> are they correct?

15:18 <jscheel> shesek_: yep, both point to my instance of the class

15:19 <shesek_> and the breakpoint inside that callback says that `_this` doesn't exists?

15:19 <jscheel> shesek_: yep

15:19 <shesek_> this makes no sense

15:19 <jscheel> shesek_: yep :)

15:20 <shesek_> you either found a bug in your JavaScript engine (highly unlikely) or doing something wrong

15:26 <jscheel> shesek_: ok, so I downgraded to coffeescript 1.1.2, and everything works as expected

15:26 <jscheel> shesek_: but at 1.2.0, it works differently

15:26 <jscheel> this is really confusing

15:26 <shesek_> is there a live version of that somewhere?

15:27 <jscheel> unfortunately no

15:27 <shesek_> or, better yet, can you reproduce on jsfiddle?

15:27 <jscheel> shesek_: jsfiddle still uses 1.1.2 or 1.1.3 I believe

15:27 <shesek_> just give it the produced JavaScript code directly

15:32 <jscheel> shesek_: ok, one sec, while I do that, here's the demo running in fiddle

15:33 <jscheel> http://jsfiddle.net/8xFCj/1/

15:45 <ronny> hi

15:46 <ronny> i invented a dsl for something, and i wonder if i could do the same using coffeescript

15:47 <ronny> the dsl looks like http://paste.pocoo.org/show/557693/

15:48 <lucian> ronny: http://coffeekup.org/

15:50 <ronny> lucian: not exactly what im looking for

15:51 <lucian> ronny: i know, it's just an example of what a DSL could look like

15:51 <lucian> you could put some -> in that example you have and get it to run as CS

15:52 <ronny> lucian: the main issue is getting the semantics right

15:52 <ronny> lucian: im expressing transitions in a statemachine and conditions for those

15:52 <lucian> it's mostly a matter of defining the right functions

15:53 <ronny> lucian: and handling the context

15:53 <lucian> sure

15:55 <ronny> lucian: i consider handling context my main issue

15:56 <lucian> read CoffeeKup's source

15:56 <ronny> lucian: note that i dont want to parse the dls to something else, i want to figure if i can have a coffeescript api thats close enough

15:57 <lucian> sure, that's what CK does

15:57 <lucian> it just also spits out html after it's done

15:57 <shesek__> lucian,

15:57 <shesek__> lucian, http://bit.ly/zucjUc

15:57 <shesek__> not sure exactly what it should do, so it might be far from what you need

15:58 <shesek__> but the syntax can be quite similar to it

15:58 <lucian> ronny: ^

15:58 <shesek__> oh, right, ronny

15:59 <lucian> ronny: the DSL could eval as a function, which you would then explicitly call in a context

15:59 <lucian> could even bind the context to this

16:01 <ronny> lucian: not sure i get it

16:03 <ronny> shesek__: looks close, just need to figure how to make the context

16:05 <jscheel> ok shesek__: I can't get this in fiddle, it's just too big of a project with too many dependencies. But, I have an event binding in my initialize that uses a fat arrow to call another method, which calls the method (which has a fat arrow) in question (setting up the drag). On the drag, the start callback is a fat arrow as well, that is not able to access the closure around it for some unknow reason.

16:05 <jscheel> super weird

16:05 <ronny> hmm

16:05 <jscheel> and I'm pretty sure I'm not doing anything wrong when it works fine in coffeescript 1.1.2, and is totally borked in 1.2.0

16:05 <ronny> is there a way to have something like named parameters in coffeescript?

16:10 <ronny> hmm

16:10 <lucian> ronny: pass an object in

16:10 <jscheel> holy balls

16:10 <jscheel> figured it out

16:10 <jscheel> sort of

16:11 <lucian> ronny: you could bind the DSL function to the context, then inside it this.foo will point to something in the context

16:11 <lucian> or rather @foo in CS

16:13 <ronny> lucian: so i would use @start and @ require?

16:13 <ronny> hmm

16:14 <ronny> ok, is there a reason why mixing normal args and positional args just makes a incomprehensible syntax error

16:14 <jscheel> hey jashkenas: I found it. In my start function, if I access "@" in my coffeescript, I can get _this in my breakpoint, if I don't, then I can't

16:15 <ronny> foo 1 a:2 gives a parse error, unexpected {

16:16 <jscheel> jashkenas: so, here's another gist with the both the working and failing versions: https://gist.github.com/10210efa440492f9cf3c

16:16 <jscheel> notice the only difference is actually accessing @ in the method

16:16 <jscheel> is this expected?

16:16 <jashkenas> what fails?

16:17 <jscheel> jashkenas: in the failing version, when I open my inspector, _this is not defined

16:17 <jashkenas> so?

16:17 <jashkenas> _this isn't a user-exposed variable.

16:17 <jscheel> so, it should be defined

16:17 <jashkenas> you don't access it directly.

16:17 <jscheel> right?

16:17 <jashkenas> not unless you're using it.

16:17 <jashkenas> nice optimization.

16:17 <jscheel> well, for testing my code in the debugger

16:19 <jscheel> jashkenas: I was trying to debug a different issue, and so I needed to set a breakpoint to figure out what was going on

16:19 <jashkenas> gotcha.

16:20 <jashkenas> but no -- not a thing we should change, IMO.

16:20 <jarek> I find it a bit confusing that this:

16:20 <jarek> config.get('position') == 'left'

16:20 <jarek> is not equal to this:

16:20 <jarek> config.get 'position' == 'left'

16:20 <jarek> is it by design that second example compiles to "config.get('position' === 'left');"?

16:20 <jscheel> jarek: that probably compiles to config.get(false), right?

16:21 <jscheel> well, not compiles to, probably equivalent to, I mean

16:21 <jashkenas> jarek: yes, it's by design.

16:21 <jashkenas> implicit parens extend to the end of the line.

16:21 <jashkenas> print inspect object

16:21 <jashkenas> print(inspect(object))

16:21 <jashkenas> console.log x == 5

16:21 <jashkenas> console.log(x == 5)

16:22 <jscheel> so, jashkenas, I feel like I can't be the only person that has ever discovered that the optimization will get in the way of debugging unless you understand the internals of coffeescript's compiler

16:22 <jscheel> throwing quick breakpoints in is a great debugging tool, but now when you get a totally unexpected result

16:23 <jscheel> or is it documented somewhere that I'm missing

16:23 <jscheel> (which I totally could be)

16:24 <jashkenas> jscheel: for better or for worse, your breakpoints are in JavaScript.

16:24 <jashkenas> you can't expect "@" to be available inside of an arbitrary "debugger"

16:24 <jashkenas> or any other CS feature.

16:25 <jscheel> jashkenas: well, of course, but if the idea is that @ "translates" to this, then it's super confusing for that to not always be the case

16:26 <jscheel> I guess I'm really used to the way 1.1.2 did it

16:28 <jashkenas> hey, it's still available if you prefer it.

16:28 <jashkenas> this way is higher performance for bound functions.

16:28 <jashkenas> (where possible)

16:29 <jashkenas> not possible in bound member functions of classes.

16:29 <jscheel> jashkenas: nah, I don't really want to stay in the past, I'm sure there's plenty of updates and fixes I will need in the future

16:30 <jscheel> jashkenas: thanks for the help explaining though

16:30 <jashkenas> sure thing.

16:36 <_john> !cs

16:36 <_john> !cs $.ajax()

16:36 <_john> hrmm

16:48 <ronny> what cann i do to avoid requiring @ for context binding?

16:53 <jarek> ronny: what are you trying to do?

16:53 <jarek> ronny: '@' can have different meaning depending on where it is used

16:54 <ronny> jarek: im trying to turn a dsl for declaring statemachine transitions/state validations into literal coffeescript

16:55 <ronny> jarek: i started with http://paste.pocoo.org/show/557693/

16:55 <ronny> and im currently at http://paste.pocoo.org/show/557794/

16:57 <jarek> ronny: ohh... sorry, I have no idea what you are talking about :)

16:57 <ronny> jarek: basically each of the steps has to be executed with the context of the outer ones

16:58 <ronny> the @ means this, so i can bind

16:58 <ronny> but i would like to get rid of it

16:59 <jarek> ronny: there is Function.prototype.bind(), Function.prototype.call() and Function.prototype.apply()

16:59 <jarek> though I'm not sure if that's what you are looking for

17:00 <ronny> jarek: i want to get rid of the need for @ in font of the things like the require

17:00 <jarek> those methods allow you for manipulating the meaning of @ (or 'this')

17:00 <ronny> jarek: but i have only access to the function that calls them

19:37 <jocafa> i see in the changelog that you can use —watch and —join together… when i try, it builds but doesn't watch. the command i'm running is: coffee -j build/built.js -cw src

19:38 <jocafa> am i Doing It Wrong™?

23:49 <MikeKnoop> Hi

23:50 <superjoe> hi

23:51 <MikeKnoop> I have a question about the cs compiler - I asked last night but there weren't very many people on

23:52 <superjoe> ask

23:54 <MikeKnoop> Ubuttu (10.04), Node (0.6.11), CoffeeScript (1.2.0) gives me an EMFILE error when I try to --watch a directory. I have raised my file descriptor limit as suggested in several blog and issue posts to no avail

23:55 <MikeKnoop> I am back on Coffeescript 1.1.1 which uses the older Node fs.watchFile function as a temporary workaround.

23:55 <MikeKnoop> But going forward it would be nice to nail down why this is happening so I can upgrade again when CS 1.3 (and on) comes out

23:55 <rlidwka> how many files do you have there?

23:57 <MikeKnoop> approximately 90 files, and the directory is 4 or 5 levels deep at it's max.

23:57 <MikeKnoop> I mention the folder depth because I can --watch a child folder (even after adding dummy .coffee files so the count is greater than 90) without problems.

23:58 <MikeKnoop> I suspect it is an issue on the Node side of things but I though I'd start here first to see if anyone has encountered this before.