[00:09:04] *** fredreichbier has joined #ooc-lang
[00:09:04] *** ChanServ sets mode: +v fredreichbier
[00:09:24] <nddrylliog> fredreichbier:
[00:09:31] <nddrylliog> o/
[00:09:49] <fredreichbier> yo!
[00:14:16] <fredreichbier> howsit!
[00:15:13] <nddrylliog> good, good
[00:15:18] <nddrylliog> ooch works fine :D
[00:16:11] *** fredreichbier_ has joined #ooc-lang
[00:16:40] <fredreichbier_> damn :O
[00:16:53] <fredreichbier_> niiiice!
[00:17:04] <fredreichbier_> ooc-mongodb is working okay so far, too. :D
[00:18:56] <nddrylliog> fredreichbier_: how featureful?
[00:20:01] *** fredreichbier has quit IRC
[00:20:07] <fredreichbier_> well, it's not meeting the mongo driver requirements yet
[00:20:14] <fredreichbier_> but it can insert, query, delete
[00:20:25] <fredreichbier_> asynchronously, with fancy callbacks
[00:21:28] <nddrylliog> fredreichbier_: oh, nice.
[00:23:31] <fredreichbier_> luckily the mongo wire protocol is very simple
[00:25:01] <nddrylliog> :)
[00:25:08] <nddrylliog> I'm onto some new project
[00:25:11] <fredreichbier_> AND VERY FUN \o/
[00:25:13] <fredreichbier_> yay!
[00:25:25] <nddrylliog> fredreichbier_: but you know, don't look it up on GitHub.
[00:25:34] <nddrylliog> fredreichbier_: all it's got a crummy README and a crappy spec draft.
[00:25:38] <nddrylliog> +is
[00:25:50] <fredreichbier_> i love crappy spec drafts
[00:26:36] <fredreichbier_> awr nice
[00:27:01] <nddrylliog> first task: B-ENCODING
[00:27:37] <fredreichbier_> what language are you using? :D
[00:27:48] <nddrylliog> http://wiki.theory.org/BitTorrentSpecification#Bencoding
[00:27:53] <nddrylliog> fredreichbier_: well ooc for the daemon, of course
[00:28:01] <fredreichbier_> niiiice
[00:28:03] <nddrylliog> fredreichbier_: and I was thinking maybe node.js for the app's backend, but now I'm wondering
[00:28:46] <fredreichbier_> or all-ooc? ;)
[00:33:46] <nddrylliog> fredreichbier_: well depends how painful it is to build the app
[00:33:56] <nddrylliog> fredreichbier_: I was hoping to spend most of my effort on the daemon and leave smarter people do the app itself ^^
[00:41:00] <fredreichbier_> nddrylliog, :D
[00:41:05] <fredreichbier_> nddrylliog, but sounds like a fun project!
[00:41:30] <nddrylliog> fredreichbier_: ^^ yup
[00:41:57] <fredreichbier_> though i haven't used bittorrent for anything besides downloading linux isos in years :D
[00:44:53] <duckinator> hi
[00:44:56] <fredreichbier_> hi duckinator
[00:45:03] <fredreichbier_> and now, i'll go to sleep
[00:45:14] <fredreichbier_> nddrylliog, duckinator, gnight, have fun!
[00:45:20] <duckinator> o/ fredreichbier_
[00:45:23] <nddrylliog> fredreichbier_: nighty
[00:45:29] <nddrylliog> fredreichbier_: yeah ;Germany sucks :x
[00:46:03] 
[00:46:32] <fredreichbier_> ((so yeah, sucks. :D))
[00:46:41] <fredreichbier_> (((anyway, too many parens)))
[00:46:42] <fredreichbier_> bye!
[00:46:44] *** fredreichbier_ has quit IRC
[00:50:10] *** Oddity007 has quit IRC
[00:51:45] <nddrylliog> hey nobody said fallacious was for downloading copyrighted material O_o.
[00:52:13] <duckinator> lol
[01:19:40] *** shahri has quit IRC
[01:29:40] <nddrylliog> oh god, the commit messages https://github.com/nddrylliog/fallacious/commits/master
[01:49:03] <nddrylliog> and it compiles!
[01:49:08] * nddrylliog salutes
[01:49:15] * nddrylliog ..and quits for the night.
[01:49:19] <duckinator> lol
[01:49:22] <duckinator> 'night nddrylliog o/
[01:49:31] <nddrylliog> duckinator: nighty night
[01:49:33] *** nddrylliog has quit IRC
[02:12:40] *** Nilium has quit IRC
[02:36:31] *** Nilium has joined #ooc-lang
[03:09:04] <locks> all hail the ndd
[03:16:39] <locks> dayum, fallacious seems interesting
[03:22:58] *** curtism has joined #ooc-lang
[03:55:45] *** mickael9 has quit IRC
[04:20:27] *** Oddity007 has joined #ooc-lang
[05:24:51] *** Oddity007 has quit IRC
[08:36:27] *** joshthecoder has quit IRC
[09:24:43] *** MrSamuel has joined #ooc-lang
[10:43:42] <CIA-126> rock: Amos Wenger master * r8eb8dd1 / sdk/io/Reader.ooc : Fixed indentation in Reader, was getting on our collective nerves. - http://git.io/HA8e8w
[10:48:06] <locks> ^ lol
[11:44:57] *** lijat has quit IRC
[11:46:44] *** lijat has joined #ooc-lang
[12:59:20] *** MayDaniel has joined #ooc-lang
[13:22:23] *** MayDaniel has quit IRC
[15:07:57] *** fredreichbier has joined #ooc-lang
[15:07:57] *** ChanServ sets mode: +v fredreichbier
[15:14:27] *** MayDaniel has joined #ooc-lang
[15:14:39] *** fredreichbier has quit IRC
[15:16:26] *** fredreichbier has joined #ooc-lang
[15:16:27] *** ChanServ sets mode: +v fredreichbier
[15:34:00] *** Nilium has quit IRC
[15:34:42] *** Nilium has joined #ooc-lang
[16:48:09] *** Oddity007 has joined #ooc-lang
[17:19:41] *** mickael9 has joined #ooc-lang
[17:39:02] *** joshthecoder has joined #ooc-lang
[17:39:02] *** ChanServ sets mode: +v joshthecoder
[17:49:03] *** mickael9` has joined #ooc-lang
[17:49:48] *** mickael9 has quit IRC
[18:00:39] *** fredreichbier has quit IRC
[18:08:05] <duckinator> hi
[18:09:48] <Oddity007> 'lo
[18:33:24] *** MrSamuel has quit IRC
[18:33:58] *** curtism has quit IRC
[18:54:46] <duckinator> https://github.com/nddrylliog/rock/pull/299 :D
[18:57:58] <duckinator> Oddity007, locks ^^ we have a good socket API waiting for ndd to pull it in, now
[18:58:10] <Oddity007> cool
[18:58:16] <Oddity007> Not that I'll ever use sockets...
[19:00:15] <locks> MUHAHAHA
[19:05:28] <duckinator> Oddity007: well, a side effect of that is i added loop(|| ...) ages ago ;P
[19:06:31] <joshthecoder> duckinator: tg someone finally rewrote that
[19:06:33] <duckinator> aka:   loop: func(f: Func -> Bool) { while(f()) {} }
[19:06:43] <duckinator> joshthecoder: loop(|| ...) was merged in last year, you know... :P
[19:06:48] <duckinator> it was one of the first bits i added
[19:07:13] <duckinator> or were you referring to the socket API that isn't just a paper-thin layer over C? :P
[19:07:19] <joshthecoder> when did we get that ruby style closures?
[19:07:27] <joshthecoder> That new API feels very Nodeish
[19:07:41] <joshthecoder> +1
[19:08:01] <duckinator> "ruby style closures" as in foo(|bar, baz| ...) ?
[19:08:03] <duckinator> forever ago
[19:08:12] <duckinator> i don't even remember if it was last year or earlier than that
[19:08:33] <joshthecoder> I recall it only being like: (conn) -> before
[19:08:38] <joshthecoder> maybe I am wrong, it's been a while :)
[19:08:52] <duckinator> well, it was in place prior to november 7th of last year ^^
[19:08:55] <joshthecoder> it may have been like that in the old compiler
[19:09:05] <Oddity007> joshthecoder: ACS has been here for a long time....
[19:09:53] <joshthecoder> so is rock going to be the compiler going forward? I remember ndd starting yet another compiler (occ?)
[19:10:16] <joshthecoder> I am kind of interested in tryin to code a llvm backend.
[19:10:26] <duckinator> the new one is 'oc', idk what the deal is with that
[19:10:39] <joshthecoder> I don't want to write it for rock if it's going dead
[19:11:16] <duckinator> well it's definitely not dying any time soon, considering it took me like an hour to make oc compile itself :|
[19:11:19] <duckinator> er
[19:11:20] <duckinator> not even
[19:11:22] <duckinator> to make rock compile oc
[19:13:40] <joshthecoder> I think we could just improve rock rather than scrap it all together
[19:14:31] <duckinator> at this point i think you're right, considering how long it'd likely take to duplicate all of it
[19:15:08] <duckinator> there are /parts/ we should probably redo completely, but i think as a whole we'll end up with the compiler equivalent of HURD if we try to start again without *at least* continuing rock alongside it
[19:15:31] <joshthecoder> incremental improvements is usually better than rewrites
[19:16:08] <duckinator> hm
[19:16:35] <joshthecoder> if we do rewrite it, do it in java again! ;)
[19:17:02] <Oddity007> lol
[19:17:22] * duckinator sets joshthecoder on fire
[19:17:36] <joshthecoder> duckinator: I was already on fire man!
[19:17:40] <joshthecoder> hehe
[19:17:42] <duckinator> lies
[19:19:48] <joshthecoder> duckinator: what you using for the event loop? libev?
[19:19:53] <joshthecoder> or trying to roll your own
[19:20:19] <duckinator> well, i just rolled my own for now
[19:20:38] <duckinator> i tried to abstract it enough that if we find a need for switching to libev or similar, it shouldn't be noticeable to anyone not looking in the sdk itself
[19:21:03] <duckinator> and i personally think i did a fairly good job :)
[19:21:09] <duckinator> afaik i didn't even break any old code with all of that
[19:21:14] <joshthecoder> yeah good idea. Really depends on what your coding and what event loop works best.
[19:21:22] <duckinator> and that was completely unintentional, to :D
[19:21:25] <duckinator> too, even
[20:01:06] <duckinator> hmm
[20:01:22] <locks> omg, progress in ooc land
[20:02:05] <duckinator> joshthecoder: seems i missed the part about TCPSocket being a bitch to use on it's own :P but i want ndd to pull that change in, since it fixes basically everything but a few callback-based features in TCPSocket (they exist in ServerSocket, not sure how to do them in UDPSocket)
[20:31:52] *** Nilium has quit IRC
[20:40:58] <duckinator> wtf? seriously?...
[20:41:27] <duckinator> oh, ok, that's a bit more reasonable
[20:41:46] <duckinator> StringTokenizer just adds features to String...i thought it was a separate class just for that purpose :|
[20:41:49] * duckinator hasn't used it in ages
[20:52:22] <duckinator> D:
[20:52:28] <duckinator> there's no ArrayList<T> flatten() or similar :(
[20:54:48] <duckinator> woah
[20:55:31] <duckinator> i don't think that'd work, because it assumes ArrayList<ArrayList<something>> which is sorta a silly idea and won't work
[20:56:31] <duckinator> but if we add something more akin to ruby's arrays (elements of any type, etc) and slowly migrate to using that, we can get this in my irc bot:
[20:56:47] <duckinator> handle: func(line: String) -> String {
[20:56:59] <duckinator>     params := line split(':') map(|part| part split(' ')) flatten() /* Tada, you just parsed IRC */
[20:57:02] <duckinator>     /* ... */
[20:57:03] <duckinator> }
[20:57:41] <duckinator> that assumes String split(Char) returns said currently-non-existent type instead of the current ArrayList<This>
[21:03:04] <duckinator> joshthecoder, Oddity007, locks: do you think aforementioned ArrayList-ish class that allows mixing of element types would be worthwhile if it can be implemented without insane amounts of bloat?
[21:03:45] <locks> can it though?
[21:04:12] <duckinator> i know it can be done, but i'm not sure if it can be done without being a bloattastic monstrosity
[21:04:50] <duckinator> brb. i have a rough idea for it, i'll try to implement it (outside of the sdk, purely for testing purposes :P) when i get back
[21:07:59] <duckinator> back
[21:08:35] <duckinator> hm
[21:08:40] <duckinator> locks: what would be a good class name for it?
[21:09:15] <duckinator> MixedList?
[21:09:51] <locks> TemplateList or something?
[21:10:06] <duckinator> hm?
[21:10:23] <duckinator> i don't understand why you chose that name. care to clarify? ^^
[21:10:27] <locks> as in c++ templates
[21:10:32] <locks> it can be any type
[21:11:14] <duckinator> i don't think that's quite the same thing.
[21:11:34] <locks> MixedList is fine
[21:11:55] <duckinator> ArrayList<T> lets you have an array of items of the class T, without the limits C usually imposes in arrays. mine basically makes it so you can have any classes
[21:12:22] <duckinator> ie, you could have what is basically [1, 'x', "foobar", This] without any issues
[21:13:14] <duckinator> ArrayList<T> is good if you want to be strict with types, but i like my idea in certain circumstances because it allows a fuckload more flexibility
[21:14:12] <duckinator> huh, i might be able to use an ArrayList<Array> to represent this o.o
[21:14:25] <duckinator> er
[21:14:29] <duckinator> s/to represent this/internally/
[21:14:44] <locks> wouldn't that == [[1],["string"],[This]] ?
[21:15:29] <duckinator> er..hm. i should think through my ideas a bit more before saying them publicly ^^
[21:16:27] <duckinator> locks: ArrayList<Pointer>, perhaps?
[21:16:39] <locks> better xP
[21:16:43] <duckinator> that one at least makes sense ;P
[21:17:14] <duckinator> damn...
[21:17:26] <duckinator> i can't extend the List class, it's List<T>
[21:17:38] <duckinator> guess i just have to try to copy it as close as possible, then
[21:19:27] <duckinator> or..derp
[21:20:42] <duckinator> MixedList: class extends List<Pointer> { ... } should work, i think
[21:21:10] <duckinator> and then i'll proceed to duplicate half of ArrayList...*cough*
[21:21:44] <locks> Godspeed, Son.
[21:22:47] <Oddity007> duckinator: We used to have Cell<T>, which if you made some CellInstance<T> have an interface as Cell (nongeneric), then you  could have ArrayList<Cell>
[21:22:56] <duckinator> oh? O.o
[21:23:33] <Oddity007> ?
[21:23:54] <locks> why can't you just use List<Pointer>?
[21:24:07] <Oddity007> ArrayList<Cell> would be typesafe
[21:24:50] <duckinator> ...
[21:24:54] * duckinator looks at structs/Bag
[21:25:16] * Oddity007 looks up how to use interfaces in ooc XD
[21:25:25] <Oddity007> It's been a while since I've seen the syntax
[21:25:38] <Oddity007> I'll code up a quick sample of what I mean
[21:25:49] <duckinator> hmm
[21:25:52] <duckinator> alright
[21:29:07] <duckinator> Bag might be what i want, or close, actually
[21:29:19] <duckinator> i'm still trying to write something that uses it without segfaulting...
[21:29:34] <Oddity007> Ewww, rock's sdk's Cell is so halfassed it's lol
[21:29:41] <duckinator> oh?
[21:29:59] <Oddity007> It's like, it was started but never finished
[21:32:14] <duckinator> wtf?!
[21:32:28] <duckinator> ArrayList.ooc:  operator += <T> (list: ArrayList<T>, element: T) { list add(element) }
[21:32:38] <Oddity007> *sigh*
[21:32:42] <duckinator> my test:  foo := ArrayList<String>; foo += "tada"
[21:32:51] <duckinator> and yet: ERROR Invalid use of operator += between operands of type ArrayListClass and String
[21:32:57] <duckinator> i don't understand why it's doing that, at all
[21:33:23] <Oddity007> Perhaps it's looking for the two ends of the operator to be the same type
[21:33:30] <duckinator> hm?
[21:34:22] <duckinator> doesn't that `operator ...` line mean (something with the class ArrayList<T>) += (something with the class T) is valid?
[21:34:59] <duckinator> oh, derp...
[21:35:33] <duckinator> Oddity007: take a careful look at what my test is...notice something missing? :D
[21:35:49] <Oddity007> new
[21:35:58] <duckinator> yea lol
[21:36:08] <Oddity007> derpadelicioso
[21:36:27] <duckinator> now for some reason `rock mixedlist.ooc` but if i use HEAD from my fork it's fine
[21:36:34] <duckinator> the only major difference is socket-related stuff
[21:37:26] <duckinator> ok, now i'm just sounding retarded and missing words
[21:37:31] <duckinator> `rock mixedlist.ooc` segfaults*
[21:37:44] <duckinator> (rock itself segfaulted)
[21:38:11] <duckinator> doing a `make clean all` to see if it's an issue on my end, or if i really managed to unintentionally fix a bug
[21:38:22] <duckinator> alright, it works now
[21:38:24] <duckinator> strange
[21:39:03] <Oddity007> https://gist.github.com/1168985
[21:39:50] <duckinator> hmm
[21:40:06] <Oddity007> the tricky part would be getting the value out
[21:40:11] <duckinator> yea
[21:40:31] <Oddity007> The user of the class would have to give type info on the way out
[21:40:55] <Oddity007> I don't know if generics work correctly with the as operator
[21:43:25] <Oddity007> we could do it like get: func<T>(index: SizeT){super(index) getRawValue<T>()}
[21:43:41] <Oddity007> Of course, cell needs to implement getRawValue
[21:44:20] <duckinator> yea
[21:45:11] <duckinator> Oddity007: i'm seeing if using pointers might work, but i can't seem to print a string reference stored in an ArrayList<Pointer> :P
[21:46:49] <duckinator> argh
[21:48:56] <duckinator> Oddity007: am i wrong in thinking that this should be adding a pointer to x into the ArrayList named 'foo'?: x := "tada";  foo add(x@)
[21:49:13] <duckinator> and that this should retrieve said value and print it?:  foo get(0)& println()
[21:49:45] <Oddity007> @ is the dereference operator, I think
[21:49:47] <duckinator> er... i seem to be failign a lot
[21:50:00] <duckinator> @ is the same as * in C, & is the same as & in C
[21:50:11] <duckinator> i don't particularly remember the proper terminology
[21:50:11] <Oddity007> and I don't think that & can be applied to an rvalue...
[21:50:40] <duckinator> hm
[21:51:05] <duckinator> why not?
[21:51:19] <Oddity007> A value doesn't have an address.
[21:51:35] <duckinator> hm
[21:52:49] <duckinator> it seems all i've managed to do is butcher everything :D
[21:58:24] <duckinator> Oddity007: well using Cell works
[21:58:54] <duckinator> foo := ArrayList<Cell> new()
[21:58:54] <duckinator> foo += Cell<String> new("tada")
[21:58:54] <duckinator> (foo[0] val as String) println()
[21:59:03] <Oddity007> Oh, cool
[21:59:20] <duckinator> so i can just make a nice wrapper for that and try to figure out how to make it not require casting
[21:59:23] <Oddity007> I didn't know that just ArrayList<Cell> would work
[21:59:33] <Oddity007> Looks like someone's been using java a little too much
[21:59:42] <Oddity007> when they designed it
[21:59:56] <duckinator> hm?
[22:03:27] <duckinator> damnit
[22:04:14] <duckinator> Oddity007: so there's an issue...namely that you have to know the type at compile time for this to work :(
[22:05:27] <Oddity007> At which part?
[22:05:50] <duckinator> retrieving the item
[22:05:57] <Oddity007> Yeah, pretty much
[22:06:10] <Oddity007> I figure that to do this correctly, you'd need compiler assistance
[22:06:37] <duckinator> hmm
[22:07:39] <Oddity007> correctly == cleanly, nonhacky, easy to use
[22:07:49] <duckinator> yea..
[22:11:14] <duckinator> i think this is the first time i've seen a weakness in ooc that i couldn't be addressed in even a hacky manner via the sdk
[22:11:23] <duckinator> s/i couldn't/couldn't/
[22:12:01] <Oddity007> Pretty much
[22:12:20] <Oddity007> Although, what you're trying to do likely has limited actual use, to be honest
[22:13:18] <duckinator> well, there's probably better alternatives
[22:13:50] <duckinator> what made me start looking into this was working on an irc bot. for each line i get, it calls handle(line)
[22:14:06] <duckinator> if we had a MixedList or similar and String split() used that, you could get this:
[22:14:08] <duckinator> words := line split(':') map(|part| part split(' ')) flatten()
[22:14:18] <duckinator> or...derp
[22:14:30] <duckinator> ok, you're right. that line's broken so i have no case where it'd be useful :D
[22:15:01] <duckinator> that line would split stuff after the last : by spaces, which is wrong
[22:25:00] <duckinator> agh
[22:30:32] *** shahri has joined #ooc-lang
[22:35:44] <duckinator> hi shahri
[22:36:15] <shahri> hoi
[22:38:14] <duckinator> https://github.com/nddrylliog/rock/pull/299 we finally have a nice socket API mostly finished :>
[22:38:57] <duckinator> there's some TCPSocket stuff left to do, but i won't even be starting on that for a couple days so i sent a pull request for the ServerSocket/UDPSocket stuff i finished :P
[22:39:16] <duckinator> and TCPSockets are a hell of a lot easier to create now..one line instead of like 6
[22:48:32] <duckinator> https://github.com/duckinator/oocbot/blob/master/oocbot.ooc irc bot i wrote using the socket API
[22:48:54] <duckinator> there's some bug with it not detecting closed connections under some circumstances...will have to look into that a bit more
[23:22:29] <duckinator> huh
[23:22:52] <duckinator> down to 36 lines for an irc bot, that's not too shabby
[23:23:00] <duckinator> and that's with keeping it easily-readable
[23:43:46] *** Nilium has joined #ooc-lang
[23:47:14] <duckinator> wtf is this nonsense
[23:48:14] <duckinator> hmm
[23:48:47] <duckinator> why wouldn't i be able to move ReaderWriterPair from net/ServerSocket.ooc to net/TCPSocket.ooc, if ServerSocket imports TCPSocket?
[23:49:02] <duckinator> I get this for any attempt to use a ReaderWriterPair, if i move it: rock_tmp/./ooch.c:62:85: error: dereferencing pointer to incomplete type
[23:51:00] <duckinator> argh
[23:52:18] <duckinator> if i toss thisat the bottom:
[23:52:26] <duckinator> ServerReaderWriterPair: class extends ReaderWriterPair {
[23:52:26] <duckinator>     init: func (=sock) { super(sock) }
[23:52:26] <duckinator> }
[23:52:41] <duckinator> bottom of ServerSocket.ooc*, and use ServerReaderWriterPair in ServerSocket...it works
[23:52:58] *** fredreichbier has joined #ooc-lang
[23:52:58] *** ChanServ sets mode: +v fredreichbier
[23:53:04] <duckinator> i don't understand why just importing net/TCPSocket isn't enough :|
[23:53:19] <duckinator> hi fredreichbier, i'm having issues fighting with rock again :P
[23:53:26] <fredreichbier> hai ho
[23:53:28] <fredreichbier> reallly? :D
[23:53:32] <duckinator> this time merely from moving ReaderWriterPair from ServerSocket.ooc -> TCPSocket.ooc
[23:55:22] <duckinator> fredreichbier: apparently importing net/TCPSocket in net/ServerSocket doesn't automagically make ReaderWriterPair available to functions inside net/ServerSocket
[23:55:39] <fredreichbier> uhm!
[23:55:52] <duckinator> my thoughts exactly
[23:56:26] <duckinator> it creates this line:  io_Writer__Writer_write_implicitLength((io_Writer__Writer*) conn->out, __strLit232);
[23:56:35] <duckinator> which gives:  rock_tmp/./ooch.c:62:85: error: dereferencing pointer to incomplete type
[23:57:36] <fredreichbier> ah yeah
[23:57:38] <fredreichbier> well
[23:57:45] <fredreichbier> had these errors too and worked around them, somehow
[23:58:03] <duckinator> i can make another class for ServerSocket that extends ReaderWriterPair and calls super()





top