00:07:13  * phuujoined
00:34:29  * phuuquit (Quit: phuu)
01:00:43  * hij1nxquit (Quit: hij1nx)
01:35:04  * mmaleckichanged nick to mmalecki[zzz]
02:53:48  * alejandromgjoined
04:09:09  <indutny_sleeping>heya
04:09:11  <indutny_sleeping>good morning
04:09:13  * indutny_sleepingchanged nick to indutny
04:21:35  * hij1nxjoined
04:25:00  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
04:54:54  <indutny>creationix: fixed one of two issues
06:06:05  <indutny>creationix: and second too
06:06:29  <indutny>creationix: timers are working, woot! :)
06:16:00  <indutny>creationix: though, you should persist your timer object
06:45:10  * alejandromgquit (Quit: leaving)
07:15:18  * mmalecki[zzz]changed nick to mmalecki
08:41:11  * mmaleckichanged nick to mmalecki[away]
10:07:48  * mmalecki[away]changed nick to mmalecki
10:51:40  * mmaleckichanged nick to mmalecki[away]
11:34:49  <indutny>creationix: that cdata thing won't work
11:35:01  <indutny>creationix: I'm testing it with __$gc() calls
11:35:12  <indutny>fixed all issues in candor, btw :)
11:35:15  <indutny>there was a lot
11:35:31  <indutny>reentering, visiting functions from GC
11:35:32  <indutny>and etc
12:28:53  * piscisaureus_joined
13:44:25  * hij1nxquit (Quit: hij1nx)
13:52:04  * piscisaureus_quit (Ping timeout: 265 seconds)
13:52:46  <indutny>creationix: implemented weak references
14:10:10  * piscisaureus_joined
14:15:18  * mmalecki[away]changed nick to mmalecki
14:29:41  <indutny>oooh
14:29:50  <indutny>some unexpected problems with old space stuff :D
14:40:24  <indutny>yeah, fixed
15:11:56  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:11:58  <indutny>creationix: yt?
15:12:19  <indutny>creationix: you should like that -> https://github.com/indutny/candor/commit/fa62eb92e5bd6557631718c045583bc079c73734
15:12:22  <indutny>:D
15:16:05  * piscisaureus_joined
15:19:00  <indutny>piscisaureus_: hey man
15:19:12  <indutny>piscisaureus_: https://github.com/indutny/candor/commit/fa62eb92e5bd6557631718c045583bc079c73734
15:19:20  <indutny>what do you think about API?
15:24:40  * phuujoined
15:24:41  <phuu>yoo
15:24:51  <phuu>oops, sorry, wrong window
15:36:15  <creationix>morning
15:36:26  <creationix>thunderstorm knocked out power yesterday
15:38:12  <creationix>indutny, nice, you made good progress
15:41:39  <creationix>so sizeof and typeof just return the original value for now?
15:42:42  <indutny>creationix: they don't do anything
15:42:51  <indutny>creationix: but yeah, probably
15:43:00  <indutny>creationix: implementing them at the moment
15:45:32  <creationix>did you see my code for the first two?
15:46:05  <indutny>creationix: looking
15:46:28  <creationix>you can probably do something faster, but that's what I used
15:46:31  <indutny>yes
15:46:34  <indutny>I'll do it in JIT
15:46:40  <indutny>and won't create any strings
15:46:41  <creationix>that works
15:46:53  <indutny>btw, setTimeout should work now
15:47:00  <indutny>but you should move to CWrapper or CData
15:47:03  <indutny>and use SetWeakCallback
16:00:19  <phuu>hey guys - i'd love to get involved but i don't have a huge amount of C++ experience (nothing better than jumping in at the deep end!). what can I do that'll help you?
16:00:50  <indutny>phuu: cool! are you familiar with gyp?
16:01:20  <phuu>no, sorry
16:02:18  <indutny>phuu: let me think
16:03:39  <phuu>are you trying to build candor on various platforms?
16:03:56  <indutny>phuu: yes
16:04:04  <indutny>phuu: but now it works only on linux and x64
16:04:26  <phuu>yeah, I was just asking cos I was having a look at gyp
16:04:42  <indutny>phuu: great!
16:04:51  <indutny>phuu: that would be a great help
16:07:44  <phuu>which environments are you targeting first?
16:08:29  <indutny>phuu: linux/x64, but I'll add linux/ia32 soon
16:08:41  <indutny>and osx
16:08:49  <indutny>no win support in near future
16:08:54  <indutny>and no arm/mips
16:18:45  <phuu>is gyp for configuring build environments in any context, or for specific IDE project files?
16:18:46  <indutny>ok, typeof is here
16:19:00  <indutny>phuu: gyp is high-level alternative to makefile
16:19:05  <indutny>phuu: it's a build system
16:19:22  <indutny>phuu: what I do want, is to move from Makefile to gyp
16:20:14  <phuu>ok. the gyp docs are a bit confusing on that front, thanks.
16:21:42  <indutny>phuu: yeah, you can try looking at joyent/node for example
16:24:59  <phuu>indutny: yeah i was, makes sense now.
16:26:57  <indutny>creationix: what sizeof 1 should return?
16:26:59  <indutny>creationix: 1?
16:29:37  <creationix>nil
16:29:44  <creationix>it only matters for arrays and strings
16:30:24  <indutny>ok
16:35:08  <indutny>creationix: one more question, sizeof {a: 1, b : 2} == 2 ?
16:35:50  <creationix>I don't think so
16:35:57  <creationix>what would that be useful for?
16:36:07  <indutny>dunno :)
16:36:23  <creationix>btw, are arrays and objects going to be different internally?
16:36:46  <indutny>creationix: that's a interesting question
16:36:50  <indutny>creationix: no arrays here so far
16:37:01  <indutny>creationix: but object is actually two heap values
16:37:05  <indutny>creationix: HObject and HMap
16:38:42  <creationix>sizeof needs to know maxInt
16:38:46  <indutny>yes
16:38:55  <indutny>HArray may have it
16:39:01  <creationix>I guess they can be the same, especially once we can store numbers as keys
16:39:04  <creationix>not just strings
16:39:12  <creationix>it's an "array" if there is at lease one int key?
16:39:23  <creationix>the only problem there is you can't tell the difference between [] and {}
16:39:23  <indutny>that's a good question
16:39:28  <indutny>yes
16:39:35  <creationix>which when dealing with JSON can matter
16:39:43  <indutny>ok, I'll add arrays later
16:39:49  <indutny>I need to think about implementation
16:39:57  <indutny>separate heap value would work fine
16:40:13  <creationix>maybe instead of maxInt, have length (maxInt + 1)
16:40:19  <creationix>and set it to 0 for arrays
16:40:23  <creationix>and -1 for objects
16:40:24  <creationix>?
16:41:04  <creationix>and only on arrays do we update maxint when new int keys are added
16:44:54  <indutny>hm..
16:52:08  <creationix>well, whatever you want internally, but objects stay objects and arrays stay arrays
16:52:33  <phuu>ach, i jumped in way over my head i think. good luck guys, i'll be really interested to see what candor becomes.
16:53:43  <creationix>indutny, language wise, I even think it's fine for only objects to have arbitrary keys on them
16:53:56  <creationix>arrays could be dense lists and functions propertyless
16:54:28  <creationix>if it makes the vm a lot faster, I think it would be worth it. arbitrary properties on arrays and functions is kinda edge case
16:55:36  <creationix>if functions and arrays can have arbitrary properties, it would consistent to do the same for cdata as well
17:05:21  * piscisaureus_quit (Ping timeout: 246 seconds)
17:13:03  <indutny>creationix: hm... I got your point
17:13:16  <indutny>creationix: yes, arrays will support only int64_t keys
17:14:01  <creationix>cool
17:14:33  <indutny>that makes sense
17:14:51  <creationix>will they be dense
17:14:53  <creationix>or allow holes
17:15:24  <indutny>creationix: with holes
17:15:28  <indutny>creationix: they'll be a hashmaps
17:15:34  <indutny>but with specific hashing
17:16:12  <creationix>ok
17:30:04  <creationix>ok, sparse is fine as long as keysof works with it
17:30:48  <creationix>bonus points if the keys come out sorted
17:30:51  <creationix>but not required
17:31:16  * bradleymeckjoined
17:35:20  <indutny>I'm afraid that's imposible
17:35:24  <indutny>impossible*
17:36:10  <creationix>yeah, hashes aren't really ordered
17:36:29  <creationix>unless you used a linked list or something
17:36:37  <creationix>with a shortcut to the last accessed index
17:36:43  <creationix>(since most access will be in order)
17:36:59  <indutny>linked lists are slow
17:37:03  <creationix>or maybe linked list and hash?
17:37:07  <creationix>or is that too much overhead
17:37:11  <indutny>yes
17:37:32  <creationix>linked lists are slow for random access
17:37:38  <creationix>but much faster for ordered traversal
17:37:49  <indutny>nono
17:37:52  <indutny>for allocation
17:38:01  <creationix>yeah, that I can believe
17:38:17  <creationix>just trying to think of how to make the loop case fast for sparse arrays
17:38:21  <creationix>or does that not matter?
17:38:28  <indutny>that does matter
17:38:38  <indutny>dense arrays will have different structure
17:38:45  <indutny>but for now let me implement them as hashmaps
17:39:01  <creationix>well, dense arrays are easy, just use for(;;) in candor
17:39:07  <creationix>0 to sizeof - 1
17:39:53  <creationix>but yeah, later add real dense stores internally would make some cases more effecient
17:40:07  <creationix>I know v8 does this for some arrays
17:40:15  <creationix>that's why Array.prototype.shift is fast for small arrays
17:40:24  <creationix>it just moves the offset pointer instead of renumbering all keys
17:41:14  <creationix>I always end up implementing my own fast queue in js anyway
17:41:20  <creationix>since the v8 trick only works for small queues
17:41:59  <creationix>candor won't have push and shift built-in to the core vm, so it's all fair ground
17:43:49  <indutny>:)
17:45:24  <creationix>can I have a way to store an integer type tag on cdata?
17:45:39  <indutny>creationix: no
17:45:55  <indutny>creationix: I don't think there're use for it
17:46:03  <creationix>type saftey
17:46:04  <indutny>and it can be easilty implemented in user-land
17:46:07  <indutny>meh
17:46:16  <indutny>you still need to coordinate numbers
17:46:17  <creationix>it shouldn't be possible for scripts to trigger segfaults (assuming no bugs in the vm)
17:46:43  <indutny>yes
17:47:13  <indutny>you can create class with 'type' property
17:47:25  <indutny>and inherit all your objects from it
17:47:33  <creationix>I can, but people can replace the cdata property with an invalid one
17:47:46  <indutny>and that class from CWrapper
17:48:00  <indutny>creationix: no, they can't
17:48:04  <indutny>only C++ side can
17:48:15  <indutny>and for CWrapper, cdata value is a pointer
17:48:23  <indutny>to class instance
17:48:40  <creationix>no, I mean 'timer = {cdata:[CData], type:"Handle"}
17:48:46  <creationix>timer.cdata = evilCdata
17:49:04  <indutny>type should be in C++
17:49:10  <creationix>you're right though
17:49:11  <indutny>just create a middle-class
17:49:18  <creationix>numbers can conflict too
17:49:20  <indutny>yes
17:49:23  <indutny>that's it
17:49:26  <creationix>I guess embedding the type inside my cdata is just as good
17:49:38  <creationix>I wonder if libuv has that already
17:49:45  <indutny>I went the way of less complexity
17:49:51  <creationix>in part of the common structure between all the structs
17:50:10  <indutny>you should definitely use CWrapper
17:50:15  <creationix>then assuming it's any uv type, I can read that property safely
17:50:22  <indutny>or at least have a weak callbacks
17:50:58  <creationix>what do cwrapper instances look like to the script?
17:51:01  <creationix>are they objects
17:51:05  <creationix>or opaque values
17:51:16  <creationix>cdata instances are opaque I assume
17:51:21  <indutny>they're cdata
17:51:39  <creationix>ok, so no properties can be set on them from candor script
17:51:44  <indutny>yes
17:51:48  <creationix>or read from them
17:52:46  <creationix>so the difference between cdata and cwrapper is cdata is managed by the vm and cwrapper is managed by the c++ class with a gc callback (WeakCallback)
17:54:05  <creationix>hmm, so I could make a UVHandle class that inherits from CWrapper
17:54:27  <creationix>and use value->As<UVHandle>() and value->Is<UVHandle>() ?
17:58:14  <indutny>yes
17:58:22  <indutny>cwrapper is API on the top of cdata
17:58:30  <indutny>that won't work
17:59:12  <indutny>aaah
17:59:13  <indutny>fuck
17:59:16  <creationix>ok, so CWrapper isn't a Value type?
17:59:18  <indutny>sorry, I'll fix API
17:59:22  <indutny>one second
17:59:23  <indutny>yes
18:02:01  <indutny>creationix: https://github.com/indutny/candor/commit/d8d231ba1e1f8d12016ddbac73ce3b17fbaa579e
18:02:26  <indutny>creationix: ->Wrap() to get CData* object which inherits from Value
18:02:44  <indutny>creationix: ->Unwrap<YourClass>(CData* data)
18:02:49  <indutny>to get YourClass* c
18:02:50  <indutny>one sec
18:03:25  <indutny>it should be possible to do ->Unwrap<YourClass>(Value* value)
18:03:45  <creationix>what happens if the value isn't the right type?
18:03:51  <indutny>done
18:04:03  <indutny>creationix: segfault :D
18:04:13  <indutny>creationix: but cdata is dangerous itself
18:04:20  <indutny>:D
18:04:26  <indutny>ok, gtg
18:04:33  <creationix>it is, but that kind of type unsafty can make for easy security holes
18:04:34  <creationix>take care
18:04:45  <indutny>yeah
18:04:53  <indutny>but that's a danger zone for all APIs
18:05:01  <indutny>supporting storing pointer to any object
18:05:11  <indutny>you can't get guarantee that this object is instance of some class
18:05:17  <creationix>not if you tag it with a type somehow so that it's never typecast to the wrong type
18:05:26  <indutny>that won't work
18:05:41  <indutny>that's illusion of type safity
18:05:47  <indutny>by the cost of API speed
18:05:56  <indutny>though it may prevent some stupid errors
18:06:05  <indutny>lets see how it'll go with that API
18:06:09  <creationix>ok
18:06:13  <indutny>we're pretty flexible with it now
18:06:24  * indutnychanged nick to indutny_away
18:06:31  <indutny_away>have you tried new API?
18:06:43  <indutny_away>looking forward to see how candor.io will work with it
18:06:49  <indutny_away>btw, HandleScope are gone
18:06:55  <indutny_away>they were useless
18:07:05  <indutny_away>ok, finally, I'm away
18:07:07  <indutny_away>for 30-45 minutes
18:08:45  <creationix>ok
18:31:15  <indutny_away>back
18:31:18  * indutny_awaychanged nick to indutny
18:47:27  <indutny>creationix: I think sizeof should return number
18:47:33  <indutny>may be 0 instead of nil
18:47:48  <indutny>would be good if one would always now that sizeof returns number
18:47:52  <indutny>less type checks and etc
19:34:15  <indutny>creationix: arrays landed
19:34:19  <indutny>adding API support for them
19:43:18  <indutny>done
19:50:29  <indutny>creationix: should keys of [1,2,3,4] return [0,1,2,3] ?
19:50:44  <indutny>should it work for arrays?
19:51:15  <indutny>ok, it'll
20:03:12  <indutny>keysof are here now too
20:06:47  <indutny>creationix: I urgently insist on using SetWeakCallback or some sort of persistent handle here, better using CWrapper
20:07:16  <indutny>creationix: things may go wierd if GC will run between timer's callbacks
20:07:24  <indutny>creationix: like calling .onClose for destroyed object
20:07:27  <indutny>not good at all
20:07:49  <indutny>or GCing object with running interval timer
20:07:59  <indutny>so timer won't ever stop
20:14:53  <indutny>btw, I don't like for loops
20:15:00  <indutny>no semicolons in candor
20:15:06  <indutny>I removed them
20:15:14  <indutny>they're essentially the same thing as while
20:15:19  <indutny>just a sugar
20:15:38  <indutny>and array iteration can be implemented as high-level function
20:57:10  <indutny>hey people, vote up http://news.ycombinator.com/item?id=3685883
21:02:16  * irrumat0rjoined
21:03:24  <creationix>back
21:03:39  <indutny>creationix: cool
21:03:40  <irrumat0r>haha: `code := statement*
21:03:42  <creationix>so what's the error handling story for candor
21:03:54  <irrumat0r>are any of you here J-ers by chance? :>
21:03:54  <indutny>irrumat0r: that's a grammar :)
21:04:01  <creationix>I know we don't want exceptions
21:04:06  <irrumat0r>in J, that would be code=: statement
21:04:19  <irrumat0r>except probably with not as many words
21:04:35  <indutny>irrumat0r: candor is very js-like
21:04:48  <indutny>irrumat0r: := is only for a grammar definiteion
21:04:52  <indutny>definition*
21:04:58  <irrumat0r>ah, I see (I don't do js)
21:05:00  <indutny>and is not a part of candorlang
21:05:40  <indutny>creationix: so, sizeof nil = 0
21:05:44  <indutny>creationix: keysof nil = []
21:05:49  <creationix>I think in general, the error handling should be early fatal errors for programming mistakes, but be more graceful on user-suplied problems (like invalid input or connecting to a server that's down
21:05:53  <irrumat0r>Oh, I see. I just got excited thinking another kewl array language was born :D
21:06:07  <indutny>irrumat0r: :)
21:06:15  <indutny>creationix: yes, compile-time fatal errors
21:06:33  <creationix>for sure we want compile time errors about using undefined variables
21:06:45  <indutny>hm...
21:06:47  * irrumat0rpart ("may the progeny of APL spread far and wide!")
21:06:54  <creationix>it's really hard to debug as it is now
21:07:01  <creationix>even my tiny experiments were very painful
21:07:12  <indutny>ok
21:07:13  <creationix>things simply don't happen and there is no indication why
21:07:22  <indutny>yes
21:07:25  <indutny>stuff like
21:07:31  <indutny>nil.a = x is not really good
21:07:35  <creationix>that and there were some nasty bugs in the vm that you just fixed
21:07:43  <indutny>yeah, there were a lot
21:08:02  <creationix>if we design the language in such a way that a static type inference can run on it, then that can catch a ton of errors
21:08:05  <creationix>and would probably be enough
21:08:14  <creationix>not having eval goes a long ways towards that
21:08:20  <indutny>hehe :)
21:08:40  <creationix>and that engine doesn't even have to be in the core, it could be part of a lint tool
21:08:41  <indutny>yes, we can do that at cost of compile time
21:08:53  <indutny>yeah, probably
21:09:02  <indutny>that can be implemented in candor.io ;)
21:09:11  <creationix>or candor.js
21:09:16  <indutny>may be
21:09:22  <creationix>since I need to re-implement the parser anyway
21:09:37  <creationix>or implement it in candor itself
21:09:40  <creationix>and it can run on either
21:09:52  <indutny>ok
21:09:55  <indutny>time to sleep for me
21:10:00  <indutny>err
21:10:11  <indutny>bad bad grammar
21:10:18  <indutny>going to sleep, anyway
21:10:20  <indutny>:)
21:10:23  <indutny>4am in my place
21:10:29  <indutny>so ttyl, thanks for your work man
21:10:34  * indutnychanged nick to indutny_sleeping
21:10:36  <creationix>ok, so sizeof and keysof always return the same type
21:10:39  <creationix>I'm fine with that
21:10:46  <indutny_sleeping>yes
21:11:15  <indutny_sleeping>and btw
21:11:17  * mralephjoined
21:11:22  <indutny_sleeping>array length won't decrement
21:11:24  <indutny_sleeping>mraleph: heya!
21:11:28  <indutny_sleeping>nice to see you there :)
21:11:41  <mraleph>I am just passing by :-)
21:11:46  <indutny_sleeping>creationix: not sure how to implement decrementing
21:11:54  <indutny_sleeping>creationix: but will add that to TODO
21:12:22  <indutny_sleeping>mraleph: language is going more mature :)
21:15:03  <mraleph>well, it looks just like many other languages out there
21:15:17  <mraleph>so it's not surprising it is getting mature :-)
21:16:13  <indutny_sleeping>:)
21:16:17  <indutny_sleeping>heh
21:16:31  <indutny_sleeping>yeah, nothing brilliant here
21:16:35  <indutny_sleeping>but anyway I like it
21:21:25  <indutny_sleeping>ok, time to sleep
21:38:21  * bradleymeckquit (Ping timeout: 246 seconds)
22:53:01  * phuuquit (Quit: phuu)
23:02:56  * mmaleckichanged nick to mmalecki[zzz]
23:55:06  * alejandromgjoined