[00:03:58] <duckinator> hi
[00:04:07] <copyboy> hey again
[00:04:53] <duckinator> Oddity007: would ArrayList<Func(IRC, Message)> new() .add(fn) require that init() returns a reference to "this"?
[00:05:02] <Oddity007> no
[00:05:21] <Oddity007> init shouldn't have a return type
[00:05:26] <Oddity007> If it does, it's ignored
[00:05:50] <duckinator> wait
[00:05:57] <duckinator> what does .add() return
[00:05:58] <Oddity007> because Object new() just calls init() as if it were a subprocedure anyway
[00:06:03] <Oddity007> nothing
[00:06:11] <Oddity007> chained functions should never have a return value
[00:06:19] <duckinator> then that's what the issue is
[00:06:56] <duckinator> or wait
[00:07:01] <Oddity007> no, because ArrayList<> new() returns
[00:07:06] <duckinator> damn this shit's confusing, this is why i almost never bother using chaining
[00:07:14] <Oddity007> yeah, it's really confusing
[00:07:14] <copyboy> add() may return the index, lemme check
[00:07:37] <duckinator> copyboy: i don't think chained calls are supposed to return anything, but either way you'd probably be better off with something like this:
[00:08:05] <duckinator> er, nvm it's almost exactly the same...
[00:08:11] <copyboy> nope, does not return the index
[00:08:14] <duckinator> copyboy: try this and see if it works, if it does i think there's a bug somewhere:
[00:08:24] <duckinator> list := ArrayList<Func(IRC, Message)> new() .add(fn)
[00:08:29] <duckinator> callbacks put(name, list)
[00:08:45] <copyboy> alrighty
[00:09:09] <copyboy> (it's a bug either way, imo :P)
[00:09:24] <duckinator> well yea, i'd agree
[00:09:24] <Oddity007> hehe yeah
[00:10:03] <duckinator> if that code works, it's an issue with passing chained calls to a function; if it doesn't then (i think) it's likely to be with chaining in general
[00:10:05] <copyboy> yes, it works that way
[00:10:37] <duckinator> copyboy: what about this?: callbacks put(name, ArrayList<Func(IRC, Message)> new())
[00:10:53] <Oddity007> Oh, I think I remember this bug
[00:11:01] <Oddity007> Yeah, chaining doesn't work as an argument
[00:11:07] <copyboy> that's what the code used to look like
[00:11:15] <duckinator> copyboy: with the new() at the end, does it work?
[00:11:19] <Oddity007> Wow, really old bug
[00:11:23] <copyboy> yes
[00:11:31] <duckinator> Oddity007: define 'really old'
[00:11:31] <Oddity007> copyboy: What version of rock are you using?
[00:11:45] <copyboy> i pulled a few hours ago
[00:11:54] <Oddity007> duckinator: like, last reported about 1 year ago
[00:11:59] <duckinator> wow
[00:12:09] <duckinator> copyboy: can you paste rock --version?
[00:12:25] <copyboy> rock 0.9.2-head, built on 2011-05-09 at 12:39
[00:12:39] <copyboy> oh
[00:12:40] <copyboy> wait
[00:12:41] <copyboy> wait
[00:12:43] <copyboy> wait a second
[00:12:56] * copyboy hides in a corner
[00:13:11] <duckinator> wow :D
[00:13:16] <Oddity007> heh
[00:13:28] <duckinator> copyboy: test if your socket bug is fixed after recompiling, btw!
[00:13:31] <duckinator> brb
[00:13:38] <copyboy> will do
[00:15:02] <copyboy> duckinator: i don't think so, but i'm not sure if i did everything correctly
[00:17:29] <copyboy> rock is still at 0.9.2?
[00:24:03] <Oddity007> has been... for a year or so
[00:24:07] <Oddity007> hehe
[00:25:27] <duckinator> back
[00:25:35] <duckinator> copyboy: `rock --version` again? check the date
[00:29:03] <copyboy> today
[00:29:07] <copyboy> @ duckinator
[00:29:18] <duckinator> then you did it right :P
[00:29:31] <duckinator> btw it's 0.9.2 prealpha if that explains anything ;P
[00:29:45] <duckinator> imo it should probably be like 0.123456789.2 or something by now, but who cares
[00:31:10] <copyboy> I'd prefer 0.9.2.2493
[00:31:59] <duckinator> lol
[00:34:15] <copyboy> increasing by 1 each day, if there are any commits
[00:34:38] *** Raynes is now known as lazybot
[00:34:39] <duckinator> that's a bit of a bizarre method
[00:34:47] *** lazybot is now known as Raynes
[00:34:54] <duckinator> if you bother with that, may as well just do 0.9.2-head-<date>
[00:35:15] <duckinator> at least then you don't have to manually version bump endlessly
[00:36:05] <copyboy> i don't really care
[00:38:03] <copyboy> last time i pulled was at least a month ago i think
[00:40:59] <copyboy> probably two ...
[00:44:03] <copyboy> duckinator: both bugs are still present
[00:44:21] <duckinator> hm, ok
[00:44:34] <duckinator> Oddity007: can you toss me a link to that bug you found on github?
[00:44:51] <Oddity007> I don't remember where, but I remember it being discussed before
[00:44:57] <duckinator> ah, ok
[00:45:10] <Oddity007> :'(
[01:03:02] *** lijat has quit IRC
[01:04:20] *** lijat has joined #ooc-lang
[01:25:15] <copyboy> oh DAMN
[01:25:34] <copyboy> init: func ~args (.command, args: ...)
[01:25:39] <copyboy> init: func ~fromString (line: String)
[01:26:03] <copyboy> guess which one gets executed when i call Message new("test")
[01:26:31] <copyboy> command is a string too
[01:32:19] <Oddity007> Well, what else would you expect? :p
[01:34:28] <duckinator> huh
[01:34:37] <duckinator> i'd have actually expected it to run the latter, BUT i can understand why it wouldn't
[01:34:39] <copyboy> i sould still be able to run the ~args one if i do new("test", [])
[01:34:57] <duckinator> er wait
[01:35:03] <copyboy> should*
[01:35:16] <duckinator> you expected it to run init~args() when you only passed one arg? :P
[01:35:36] <copyboy> uhm ... no?
[01:35:48] <duckinator> i'm confused then. nevermind o/
[01:35:54] <copyboy> \o
[01:36:27] <Oddity007> copyboy: if you want to manually call one, just put the Message new~fromString("test")
[01:36:59] <Oddity007> Who ever thought of the ~ thing was genius
[01:37:08] <copyboy> i don't wanna!
[01:38:08] <duckinator> Oddity007: agreed. so simple, but so useful
[01:38:58] <Oddity007> Although, I think it's actually optional now
[01:39:15] <Oddity007> Or, has been since the beginning of rock
[01:40:59] <copyboy> well, otherwise there wouldn't be any reason for it
[01:41:49] <copyboy> wouldn't it be wise to prioritize other funcs over those that use valargs?
[01:42:17] <Oddity007> no, why should it
[01:42:26] <copyboy> this case is a little weird, because those two don't do the same
[01:42:49] <Oddity007> Well, usually, if you see a case like that, it means that the programmer was stupid :p
[01:42:53] <duckinator> lol
[01:43:02] <copyboy> but if you have print(text) and print(format, ...)?
[01:43:23] <Oddity007> It'd be the same function
[01:43:43] <duckinator> copyboy: there's no reason for those to be different functions
[01:43:49] <copyboy> but the first one would be a faster version
[01:43:55] <Oddity007> The way to look at it is that a vararg function is defining every possible overload
[01:44:01] <duckinator> copyboy: there's no reason to separate them at all
[01:44:19] <duckinator> there's no optimization aside from whether or not varargs are used
[01:44:47] <copyboy> what about print(text) and print(format, ...) using that first print function?
[01:45:06] <copyboy> DRY
[01:45:39] <Oddity007> How on earth would the compiler know which you were using?
[01:46:04] <copyboy> by prioritizing?
[01:46:58] <Oddity007> the nature of a vararg function is that it defines every possible overload, even to an infinite number of arguments with any type, so to have an overload on top of an overload is really crazy
[01:48:18] <Oddity007> It'd be likely to tell which overload you wanted in some cases, but it would be very unpredictable, even with prioritization
[01:48:19] <copyboy> "compiler, print(something)" - "alrighty then, calling print(for- wait there already is a overload which doesn't use valargs!"
[01:48:27] <copyboy> like that?
[01:48:45] <Oddity007> ?
[01:48:52] * Oddity007 didn't get that
[01:49:20] <copyboy> yeah, the compiler doesn't call it, sorry
[01:49:36] <copyboy> fingers are faster than my brain
[01:50:08] <Oddity007> Basically: If you try to overload a vararg function, u mad bro.
[01:50:16] <copyboy> fingers: *typing something* - brain: "wait that doesn't make sense" - fingers: "too late"
[01:55:46] <copyboy> nvmd then
[02:00:19] <copyboy> interesting
[02:00:38] <copyboy> [Exception in Cast]: Casting to ArrayType String in unrecognized parent node this params = list as String (BinaryOp)!
[02:03:48] <copyboy> i didn't know list as String[] didn't work, it does work in the other direction it seems
[02:06:39] <Oddity007> Where?
[02:06:45] <Oddity007> Oh
[02:06:45] <Oddity007> heh
[02:07:00] <Oddity007> Yeah, ooc sdk nuttiness
[02:07:03] <copyboy> i don't understand arrays in ooc quite, yet
[02:07:19] <copyboy> maybe that's it
[02:07:21] <Oddity007> more ooc sdk nuttiness
[02:07:25] <copyboy> is String[] a valid type?
[02:07:34] <Oddity007> Yeah.. I think
[02:07:40] * Oddity007 uses his own sdk
[02:07:45] <copyboy> heheh
[02:10:59] <Oddity007> Although, it's last update was about a year ago...  which is when I pretty much stopped using ooc
[02:12:31] <copyboy> for what reason?
[02:12:51] <Oddity007> what reason for what?
[02:13:12] <copyboy> for stopping using ooc
[02:13:42] <copyboy> here's another one i don't understand:
[02:13:45] <copyboy> ./IRC/IRC.ooc:121:10 ERROR No such function new(String, <unknown type>) for `MessageClass`
[02:13:45] <copyboy>     send(Message new("QUIT", []))
[02:13:47] <Oddity007> No reason to use it over C at the time, and it wasn't stabilizing
[02:14:16] <Oddity007> ...
[02:14:22] <Oddity007> what is [] supposed to be?
[02:14:26] <copyboy> init: func ~withArrayWithoutPrefix (.command, params: String[])
[02:14:45] <Oddity007> use null instead
[02:14:51] <Oddity007> [] is nuts
[02:15:00] <Oddity007> or just use Array<String> new()
[02:15:15] <Oddity007> Errr, maybe String[] new(0)
[02:15:21] <Oddity007> I don't remember
[02:15:25] <copyboy> [] is shorter than any of those two
[02:15:40] <copyboy> three*
[02:16:42] <Oddity007> [] is just nonsense
[02:16:58] <copyboy> it's an empty array
[02:17:04] <Oddity007> Empty array of what?
[02:17:34] <copyboy> of String, that's what the function wants
[02:18:10] <Oddity007> But you are giving it an empty array of no type, which is why it comes up with <unknown type>
[02:18:23] <Oddity007> Which means that it can't find the correct overload
[02:18:37] <Oddity007> casting and overloading don't mix well
[02:20:08] <copyboy> if i give 1 to a function which expects a byte, do i have to cast it first?
[02:20:19] <copyboy> takeByte(1 as Byte)
[02:20:29] <Oddity007> no, I don't think so
[02:20:36] <Oddity007> numbers are casted
[02:21:02] <Oddity007> (which is just as risky)
[02:21:47] <copyboy> what about takeByteArray([1, 2, 3]) ?
[02:22:00] <Oddity007> That'll be an array of ints, not of bytes
[02:22:11] <Oddity007> Actually, it'll be an array of SSizeTs
[02:22:24] <Oddity007> beat in rofl0r for that one
[02:22:32] <Oddity007> (ndd claims)
[02:23:24] <copyboy> it's known at compile time, so there is a way to resolve this, isn't there?
[02:23:42] <Oddity007> There is a way, but it's all going to be unpredictable
[02:23:57] <Oddity007> casting and overloading don't mix well
[02:24:13] <copyboy> example please, so my simple mind understand ^^
[02:24:46] <Oddity007> casting relies on knowing the type of the function it is being passed to, overloading relies on knowing the type of the arguments
[02:25:21] <Oddity007> trying to cast while overloading is a nightmare, because no one knows what type it's supposed to be
[02:28:23] <copyboy> mhkay
[02:29:06] <copyboy> by the way:
[02:29:07] <copyboy> rock_tmp/./IRC/IRC.c:248:5: error: incompatible type for argument 2 of ?IRC_Message__Message_new_withArrayWithoutPrefix?
[02:29:07] <copyboy> .libs/ircbot/./IRC/Message-fwd.h:36:23: note: expected ?_lang_array__Array? but argument is of type ?void *?
[02:29:20] <Oddity007> You're using null?
[02:29:24] <copyboy> yes
[02:29:28] <Oddity007> need to cast it
[02:29:43] <Oddity007> Or, just use String[] new(0)
[02:29:54] <Oddity007> To prevent crashes
[02:30:09] <Oddity007> (but you should really have your code designed to handle nulls anyway)
[02:30:58] <copyboy> why do i have to cast it?
[02:31:08] <Oddity007> because null is of the type void*
[02:31:52] <Oddity007> and, implicit casting + overloading == bad
[02:32:31] <copyboy> can't pass null when it expects a class?
[02:32:45] <Oddity007> no, because null is of the type void*
[02:34:03] <copyboy> i can do this: init(command, null, params)
[02:34:10] <duckinator> hi
[02:34:15] <copyboy> why can't i do the same for an array?
[02:34:18] <copyboy> wb
[02:34:40] <Oddity007> if it were to do that, you wouldn't be able to have someFunction ~takingAPointer (arg: Pointer) and someFunction ~takingAnObject (arg: Object) and someFunction ~takingAnArray (items: Int[])
[02:34:47] <copyboy> ohh, i think i get it
[02:34:51] <Oddity007> because they'd all be pointers
[02:35:03] <Oddity007> Which kills the point of overloading
[02:35:28] <copyboy> well that's why there's casting
[02:35:55] <Oddity007> which is exactly what you have to do manually
[02:35:57] <Oddity007> :)
[02:36:05] <Oddity007> and why you have to do it
[02:36:17] <Oddity007> the compiler doesn't know enough to do it all by itself
[02:36:40] <copyboy> anyway, an array is not like a normal class in ooc, right?
[02:37:35] <Oddity007> It's a cover, I think
[02:37:49] <Oddity007> and a whole lot of magic thrown on top of it
[02:37:57] <Oddity007> makes me shiver
[02:38:04] *** Oddity007 is now known as OddityAFK
[02:38:18] <copyboy> i'm used to using them just like any other class
[02:38:43] <OddityAFK> That's pretty much how they are supposed to be used, but don't go expecting that you can overload it
[02:38:45] <OddityAFK> hehe
[02:38:58] <OddityAFK> err, inherit from it
[02:40:53] <copyboy> still, i think i should be able to write null and have it implicitly cast to an array
[02:41:25] <copyboy> if there's problems with overloading, i can still cast it
[02:42:33] <copyboy> or not
[02:43:26] <copyboy> segmentation fault
[02:43:29] <copyboy> fffffFFFFF
[03:06:35] *** OddityAFK is now known as Oddity007
[03:06:46] <Oddity007> probably because your code doesn't expect a null
[03:08:20] <Oddity007> Or that Arrays aren't pointers....
[03:08:24] * Oddity007 facepalms
[03:08:30] <Oddity007> *sigh*
[03:08:33] <Oddity007> It's been a while
[03:09:04] <Oddity007> copyboy: check that your code can handle a null pointer, then try String[] new(0)
[03:09:20] <Oddity007> If it all fails, try [""]
[03:10:52] <copyboy> it's fine i can figure it out
[03:20:28] <copyboy> thanks and good night
[03:20:43] *** copyboy has quit IRC
[03:22:08] <Oddity007> woah
[03:22:21] <Oddity007> this channel is picking up talk lately
[03:22:41] <Oddity007> and it's ooc related as well
[03:23:49] *** boredomist has joined #ooc-lang
[04:11:29] *** bertrand has joined #ooc-lang
[04:19:57] *** bertrand has quit IRC
[04:48:35] *** mickael9 has quit IRC
[04:57:12] *** shahri has quit IRC
[05:08:32] *** Oddity007 has quit IRC
[05:08:39] *** Jetbeard has quit IRC
[05:10:05] *** shahri has joined #ooc-lang
[06:41:04] *** boredomist has quit IRC
[06:58:39] *** shahri has quit IRC
[09:32:24] <Ycros> \o/
[09:54:08] *** Raynes_ has joined #ooc-lang
[09:57:23] *** Raynes has quit IRC
[09:57:25] *** Raynes_ is now known as Raynes
[09:57:26] *** Raynes has joined #ooc-lang
[09:57:59] *** locks has quit IRC
[09:58:26] *** locks has joined #ooc-lang
[10:56:44] *** joshthecoder has quit IRC
[11:29:36] *** copyboy has joined #ooc-lang
[12:38:25] *** Jetbeard has joined #ooc-lang
[12:38:28] *** Jetbeard- has joined #ooc-lang
[12:46:48] *** Jetbeard- has quit IRC
[13:51:42] *** MayDaniel_ has joined #ooc-lang
[14:05:29] *** MayDaniel_ has quit IRC
[14:34:55] *** mickael9 has joined #ooc-lang
[14:48:33] *** edwinirving has joined #ooc-lang
[15:12:09] <copyboy> nargh, what's going on?
[15:13:14] <copyboy> i'm getting a segmentation fault when appending a string to another one
[15:14:02] <copyboy> well, i think it's a string which i'm appending
[15:16:43] <copyboy> this is so weird for me
[15:21:22] <copyboy> i think it's something with the varargs
[15:28:08] <copyboy> ah great, segmentation fault when compiling!
[15:32:04] <copyboy> for (i in 0..args length) list add(args[i])
[15:32:18] <copyboy> compiles to structs_ArrayList__ArrayList_add(list, (uint8_t*) &(_lang_array__Array_get(args, i, lang_String__String*)));
[15:32:37] <copyboy> rock_tmp/./IRC/IRC.c: In function ?IRC_IRC__IRC_send_impl?:
[15:32:37] <copyboy> rock_tmp/./IRC/IRC.c:196:13: error: lvalue required as unary ?&? operand
[15:33:17] <copyboy> and "[] as String[]" seems to end in a segmentation fault when compiling
[15:33:32] *** edwinirving has quit IRC
[15:33:44] <copyboy> duckinator: *highlight*
[15:58:33] <copyboy> ok, it's not the varargs causing the segmentation fault
[16:00:45] <copyboy> what?
[16:00:53] <copyboy> ./IRC/IRC.ooc:30:7 ERROR No such function (Hint: there's such a function in lang/IO)
[16:00:53] <copyboy>       params[0] println()
[16:01:17] <copyboy> oh wait
[16:01:23] <copyboy> params doesn't exist
[16:01:36] <copyboy> why can't you tell me that any sooner?!
[16:04:01] <copyboy> okaaaay
[16:04:38] <copyboy> it doesn't seem to like it when i cann this function
[16:04:40] <copyboy> call*
[16:05:08] <copyboy> pong: func (server: String) { /* contents commented out */ }
[16:05:26] <copyboy> probably because server is already used in the class
[16:06:55] <copyboy> no, that's not it, either
[16:12:06] <copyboy> finally
[16:12:10] <copyboy> *sigh*
[16:12:44] <copyboy> working code: on("ping", |irc, msg| irc pong(msg params[0]) )
[16:13:00] <copyboy> segmentation fault: on("ping", |_, msg| pong(msg params[0]) )
[16:58:11] *** Oddity007 has joined #ooc-lang
[16:59:59] <Oddity007> copyboy: You can just use for(arg in args)
[17:00:33] <Oddity007> you can even use args each(|arg| doSomethingWithArg(arg) )
[17:34:05] <copyboy> Oddity007: still, why the error?
[17:34:57] <Oddity007> I don't know, but I've never seen _ used before in ooc
[17:36:41] <Oddity007> I don't think ooc has wildcards
[17:36:49] <Oddity007> Only for tuples
[17:47:20] *** boredomist has joined #ooc-lang
[17:49:02] *** shahri has joined #ooc-lang
[18:29:47] <duckinator> no, ooc does not have wildcards
[18:30:01] <duckinator> because C can not implement them unless you do some painful hackery, afaik
[18:30:13] <duckinator> and I do mean painful
[18:30:45] <Oddity007> well, wildcards are just ignored arguments, you could do them by simply assigning them to a variable that is never used
[18:30:54] <duckinator> mmm
[18:31:03] <duckinator> in that case it'd just be nasty, not painful
[18:31:15] <duckinator> naming it <normal arg name>_unused or similar
[18:31:22] <duckinator> well, no
[18:31:27] <Oddity007> If you want to see nasty, don't look at how wildcards in tuples are implemented
[18:31:28] <duckinator> unused_<normal arg name> because the former would conflict
[18:31:35] <Oddity007> hehe
[18:32:09] <duckinator> agh, ok, nevermind
[18:32:18] <duckinator> unused_arg_<arg position in list>
[18:32:28] <duckinator> THERE. THAT WILL WORK. *finds exploded bits of brain*
[18:33:16] <duckinator> using <normal arg name> doesn't make sense if there's no name to start with ;D
[18:33:38] <Oddity007> yeah, you confused me
[18:34:26] <duckinator> you know, that really shouldn't be too hard to implement, but i don't know how it'd ever be needed
[18:35:13] <duckinator> i think there's a decent alternative for basically any usecase for that. copyboy's issue with that, i believe was just him trying random things to get it working ;)
[18:35:38] <duckinator> maybe i'll just stop commenting on code until i'm fully awake
[18:35:43] * duckinator wanders off
[18:36:46] <copyboy> sorry for spamming the channel earlier
[18:37:29] <copyboy> i think i found a few bugs
[18:40:35] <copyboy> and i don't remember hwo to create a an empty array of some type
[18:43:17] <duckinator> hmm, i'm not either :P
[18:43:23] <duckinator> most people use ArrayLists
[18:44:21] <Oddity007> There's no point to an empty array
[18:44:33] <Oddity007> Arrays aren't resizable, ArrayLists are
[18:45:15] <Oddity007> And likewise, it can't have a type if nothing is in it
[19:16:56] <copyboy> stop saying that
[19:17:27] <copyboy> if a function accepts arrays, it's easier for me to give it an empty array than a null pointer
[19:18:49] <copyboy> because i have to check for null
[19:19:17] <Oddity007> Well, what do you think an array with nothing in it would be?
[19:19:19] <copyboy> and i have to cast null first, for some reason
[19:20:32] <Oddity007> an empty array just isn't going to work no matter how you go about it, and in many other languages, it degrades into a nil value anyway
[19:21:54] <Oddity007> 1) it can't get the type 2) if it actually did work past that, it would end up allocating by calling gc_malloc(0), which is an error
[19:22:08] <Oddity007> (undefined nonsense)
[19:22:38] <Oddity007> You're better off making your code correct/safe and handling the case where you get the null pointer
[19:24:24] <copyboy> and i thought arrays could hold anything from 0 to X values
[19:26:29] <Oddity007> no, an array of nothing defeats the point of an arrayu
[19:26:53] <Oddity007> Few languages allow it, and those that do usually break it down into a null
[19:27:46] <curtism> that doesn't sound right
[19:34:38] <Oddity007> Well, lua and other languages where array literals are mutable allow it because an array of nothing usually means that you'll add something to it, but an immutable array of nothing means nothing
[19:35:01] <Oddity007> if it were that case, you'd use an arraylist, not an array
[19:41:00] *** Oddity007 has quit IRC
[20:22:23] *** Oddity007 has joined #ooc-lang
[20:22:48] *** Jetbeard has quit IRC
[20:39:27] *** Jetbeard has joined #ooc-lang
[20:51:32] *** curtism has quit IRC
[20:53:53] *** curtism has joined #ooc-lang





top