[00:01:26] *** Ttech has quit IRC
[00:01:26] *** Ttech has joined #ooc-lang
[00:42:29] *** Ttech has quit IRC
[00:42:29] *** Ttech has joined #ooc-lang
[00:42:47] *** fredreichbier has joined #ooc-lang
[00:42:48] *** ChanServ sets mode: +v fredreichbier
[01:09:26] *** Ttech has quit IRC
[01:09:26] *** Ttech has joined #ooc-lang
[01:14:12] *** fredreichbier has quit IRC
[02:22:10] *** shahri has quit IRC
[02:41:04] *** mickael9` has quit IRC
[03:08:36] *** joshthecoder has quit IRC
[03:08:41] *** Oddity007 has quit IRC
[03:12:22] *** Oddity007 has joined #ooc-lang
[03:23:01] *** Ttech is now known as The_Doctor
[03:25:07] *** The_Doctor is now known as Ttech
[03:51:37] *** Oddity007 has quit IRC
[03:52:29] *** Jetbeard has quit IRC
[03:57:28] *** Oddity007 has joined #ooc-lang
[03:59:00] *** Oddity007 has quit IRC
[05:57:55] *** curtism has joined #ooc-lang
[06:46:19] *** Nilium has quit IRC
[06:52:22] *** Nilium has joined #ooc-lang
[06:52:22] *** ChanServ sets mode: +v Nilium
[08:00:18] *** aanderse has quit IRC
[08:00:42] *** aanderse has joined #ooc-lang
[08:30:55] *** shamanas has joined #ooc-lang
[11:00:58] <shamanas> 3 issues to go :)
[11:01:08] <shamanas> when pulls are accepted :P
[11:03:34] <shamanas> The 3 elite ones, the most difficult and weird :O
[11:05:45] *** fredreichbier has joined #ooc-lang
[11:05:45] *** ChanServ sets mode: +v fredreichbier
[11:06:27] <shamanas> hey fred :0)
[11:06:30] <shamanas> :-)*
[11:07:08] <fredreichbier> hiyo!
[11:07:28] <shamanas> everything ok? :D
[11:07:43] <shamanas> just fixed one more issue btw :P
[11:08:09] <shamanas> 3 left when the pull requests are accepted :D + i fixed one from 0.9.3 :P
[11:16:08] <shamanas> Btw if anyone is feeling suicidal enough he could try to write an ooc binding generator with swig :o
[11:48:01] <fredreichbier> niiiice :)
[11:48:04] <fredreichbier> hehe, swig
[11:48:07] <fredreichbier> i don't know :D
[11:51:35] <shamanas> yay we now has a libt binding! :P
[11:51:41] <shamanas> shamanas/libootcc x)
[11:52:11] <shamanas> libtcc*
[12:04:22] *** MayDaniel has joined #ooc-lang
[12:15:28] *** MayDaniel has quit IRC
[12:25:03] *** Jetbeard has joined #ooc-lang
[12:49:56] *** Jetbeard has quit IRC
[12:54:27] *** Jetbeard has joined #ooc-lang
[13:12:03] *** mickael9 has joined #ooc-lang
[13:43:24] *** mickael9` has joined #ooc-lang
[13:44:18] *** mickael9 has quit IRC
[15:31:01] *** shahri has joined #ooc-lang
[15:40:18] *** MayDaniel has joined #ooc-lang
[16:50:52] *** bartwe has joined #ooc-lang
[16:53:30] *** MayDaniel has quit IRC
[16:57:01] <CIA-126> rock: Alexandros Naskos master * r5c07283 / source/rock/backend/cnaughty/CGenerator.ooc : Closes #268 - http://git.io/RX3Kyw
[16:57:06] <CIA-126> rock: Amos Wenger master * r2d59836 / source/rock/backend/cnaughty/CGenerator.ooc :
[16:57:06] <CIA-126> rock: Merge pull request #314 from shamanas/writeFtypes
[16:57:06] <CIA-126> rock: Closes #268 - http://git.io/bjzrMg
[17:54:42] *** zc00gii has joined #ooc-lang
[17:55:28] <zc00gii> what the fuck happened to everyone in here?
[17:55:32] <zc00gii> this channel used to be pretty big
[18:00:05] *** bartwe has quit IRC
[18:04:03] <shamanas> hm
[18:04:30] <zc00gii> fredreichbier, ping
[18:04:33] <shamanas> most people left when rock started to be less and less maintained
[18:05:01] <shamanas> but now it has picked up again. At least i try to maintain it as much as i can :/
[18:07:39] <zc00gii> shamanas, I had a lot of hope for this project
[18:07:52] <zc00gii> but now it doesn't seem like there's much
[18:08:02] <shamanas> ooc and rock?
[18:08:04] <zc00gii> then again, I always see the glass as half empty
[18:08:05] <zc00gii> yeah
[18:08:11] <shamanas> im hoping it will start to bloom again :)
[18:08:25] <zc00gii> popularity is the issue
[18:08:48] <shamanas> if we maintain rock well and make many things in ooc
[18:08:58] <shamanas> it will start to have more followers
[18:09:05] <shamanas> i hope
[18:09:10] <shamanas> with some publicity ;)
[18:10:32] <zc00gii> yeah
[18:10:33] <shamanas> for example, you can help by forking rock and trying to fix some issues
[18:10:34] <shamanas> or
[18:10:47] <zc00gii> eh, I can't program for a while
[18:10:53] <shamanas> make some bindings
[18:10:53] <zc00gii> I haven't my own computer
[18:10:57] <shamanas> oh k then ;)
[18:13:50] <shamanas> well alternitavely you can just hang out on IRC so we are more :D
[18:17:18] <fredreichbier> zc00gii, pong
[18:17:27] <zc00gii> fredreichbier, how's it?
[18:17:39] <zc00gii> providing you still remember me, and give a rats ass about me
[18:17:44] <fredreichbier> pretty good!
[18:17:46] <fredreichbier> i remember you
[18:17:47] <fredreichbier> how are you?
[18:18:48] <shamanas> hello again fred :)
[18:18:48] <zc00gii> I'm alright
[18:19:38] <fredreichbier> hi shamanas!
[18:19:38] <shamanas> 4 issues, 3 if someones accepts the pull request duckinator said works :O
[18:19:49] <fredreichbier> okay, i have 5 minutes, let's test that shit :D
[18:19:57] <shamanas> and now the top 3 are left :P
[18:20:54] <shamanas> btw read the comments i tried to explain the fix as much as i could
[18:22:26] <duckinator> hi shamanas
[18:22:33] <shamanas> duckinator: hello :)
[18:24:18] *** duckinator changes topic to "Welcome to the official ooc programming language IRC channel | Channel's logged: http://tinyurl.com/ooc-lang | We're 3 bugs away from 0.9.2!"
[18:24:27] <CIA-126> rock: Nick Markwell master * rd8af9d8 / source/rock/backend/cnaughty/ModuleWriter.ooc :
[18:24:27] <CIA-126> rock: Merge pull request #312 from shamanas/master
[18:24:27] <CIA-126> rock: Closes #262 - http://git.io/xYxZ7A
[18:24:37] <shamanas> yay! :D
[18:25:40] <shamanas> i have no idea on how to fix #246 + im not on arch xO
[18:25:46] <shamanas> so lets skip that
[18:25:59] <duckinator> brb
[18:26:18] <fredreichbier> not sure if it's related to arch though
[18:26:46] <shamanas> oh
[18:26:57] <shamanas> i guess i gotta test it then :P
[18:28:34] <fredreichbier> i'm on #311/#239
[18:29:04] <shamanas> you have some curage
[18:29:08] <shamanas> courage*
[18:30:55] <shamanas> well i get socketerrors all the time with the given example but i guess i dont need to use sockets if the problem is with os/Channel
[18:32:18] <fredreichbier> hmmm. but the socketerrors aren't good either :D
[18:32:24] <shamanas> yes, indeed my test program just hangs
[18:32:53] <shamanas> its a problem on my side, the serversocket cant bind
[18:41:10] <shamanas> ok the bug is really really weird
[18:41:31] <shamanas> i can do for(_ in 0 .. 10000) go(|| "lol
[18:41:37] <shamanas> " println())
[18:41:43] <shamanas> without bugging
[18:41:49] <shamanas> r call it 150 times
[18:42:11] <shamanas> but once it is in loop(||) or while(true) it just hangs :O
[18:45:27] <fredreichbier> strangey!
[18:45:52] <shamanas> well, actually it is because of bad design
[18:46:12] <shamanas> apparent when you do go(|| ) you put a corostartinfo in a likedlist
[18:46:24] <shamanas> fr coros to start executing
[18:46:29] <shamanas> scheduler() must be called
[18:46:37] <shamanas> and there is atexit(scheduler)
[18:46:53] <shamanas> the problem is we never exit, we are in an infinite list
[18:47:45] <fredreichbier> duckinator, does your first exmaple in #311 compile for you?
[18:48:51] <shamanas> it does for me
[18:51:24] <fredreichbier> mmhm strangey
[18:53:13] <shamanas> what is the error you get?
[18:54:48] <fredreichbier> uh. it was related to my ... "fix" :D
[18:54:58] <fredreichbier> shit
[18:55:06] <fredreichbier> `git stash drop` is not `git stash pop`
[18:55:06] <shamanas> oh i see :P
[18:55:11] <shamanas> xD
[18:55:21] <shamanas> btw are you getting anywhere ? :)
[18:56:08] <fredreichbier> yeah, i think a warning shouldn't be too hard :)
[18:56:34] <shamanas> well it isnt a "real" fix :o
[18:57:26] <shamanas> but i guess its better than nothing ;)
[18:57:28] *** zc00gii has quit IRC
[18:58:29] <fredreichbier> it's a really nasty bug :D
[18:58:50] <fredreichbier> especially if you do something like
[18:59:03] <shamanas> yeah i guess so :-(
[18:59:06] <fredreichbier> item != null ? add(item) : somethingelse()
[18:59:09] <fredreichbier> and add is a vararg function
[18:59:13] <fredreichbier> and it just segfaults. :D
[18:59:24] <shamanas> with your "fix"?
[18:59:29] <shamanas> or from master?
[19:01:37] <fredreichbier> that's master's current behaviour
[19:01:40] <fredreichbier> (#311)
[19:02:23] <shamanas> I guess #246 is not a real bug but well have to talk with ndd bout that
[19:02:51] <shamanas> wasnt the bug that item was rvaluated at that case?
[19:02:56] <shamanas> evaluated*
[19:03:07] <shamanas> saw nothing about segfaults
[19:05:45] <fredreichbier> hmmm dunno about #246
[19:06:15] <fredreichbier> well
[19:06:18] <fredreichbier> i have to go now
[19:06:22] <fredreichbier> bbq is waiting for me
[19:06:30] <shamanas> niice :D
[19:06:39] <shamanas> have a good time ;)
[19:06:56] <fredreichbier> thank you! will be back later. :)
[19:06:57] <fredreichbier> seeya
[19:06:59] *** fredreichbier has quit IRC
[19:28:15] *** bartwe has joined #ooc-lang
[19:31:35] <duckinator> hi
[19:32:22] <duckinator> shamanas: re the bug fred mentioned about the warning: i opened another bug without a milestone
[19:32:28] <duckinator> basically we decided on a warning for now, proper fix long-term
[19:32:47] <shamanas> ok
[19:32:59] <shamanas> im working on #237 atm
[19:34:53] <duckinator> lol @ #246 ^^
[19:35:45] <shamanas> the thing is
[19:35:52] <shamanas> im not sure
[19:35:56] <duckinator> well
[19:36:16] <shamanas> it might be an issue that it cannot be used in inf. loops
[19:37:19] <shamanas> POKING SPREE!
[19:37:38] <duckinator> indeed
[19:37:45] <shamanas> btw
[19:37:55] <shamanas> try running scheduler manually after go()
[19:38:01] <duckinator> hmm, ok
[19:38:03] <duckinator> un momento
[19:38:11] <shamanas> it may fix it although i doubt it
[19:40:32] <duckinator> hm
[19:40:36] <duckinator> shamanas: scheduler is blocking
[19:40:38] <duckinator> won't work
[19:40:42] <duckinator> well actually
[19:40:47] <duckinator> i can check if it works for at least one instance
[19:40:55] <shamanas> hm
[19:40:59] <duckinator> like, call it after the first go()
[19:41:07] <duckinator> if i do that and the first connection works, then it is in fact the issue
[19:41:26] <shamanas> well look at code im sure this is the issue
[19:41:30] <shamanas> but try it anyway
[19:41:57] <duckinator> O.o
[19:41:58] <duckinator> it works
[19:42:16] <duckinator> consistently
[19:42:22] <shamanas> you see ;)
[19:42:24] <duckinator> wait WHAT
[19:42:42] <duckinator> it works better than the 100%-equivalent version with go() xD
[19:42:51] <duckinator> without*
[19:42:58] <shamanas> oO
[19:43:00] <duckinator> like...if you take out the go(||) it barfs all over the browser
[19:43:01] <shamanas> nice :D
[19:43:11] <shamanas> so
[19:43:13] <duckinator> that's...rather funny
[19:43:16] <shamanas> the question is
[19:43:25] <shamanas> should go() actually call scheduler
[19:43:38] <shamanas> or should we just let it that way and call it manually?
[19:43:48] <duckinator> hmm
[19:43:59] <duckinator> well
[19:44:09] <duckinator> i may be using go() in a way not intended, i honestly do not know
[19:44:17] <duckinator> BUT it does work if i call it, so possibly
[19:44:24] <duckinator> actually
[19:44:32] <duckinator> shamanas: go() blocks until the last go()-call exits, i think
[19:44:40] <shamanas> calling it after each go() beats its purpose actually :P
[19:45:03] <shamanas> no
[19:45:09] <shamanas> go() does not block
[19:45:14] <duckinator> er
[19:45:22] <duckinator> scheduler()* blocks until the last go() call exits
[19:45:23] <shamanas> it just adds an instance of corosinfo in a list
[19:45:31] <shamanas> wich scheduler turns into coros and calls
[19:45:34] <duckinator> i think
[19:45:35] <shamanas> oh :P
[19:45:50] <duckinator> while(true) { if(coros empty?() && newCoros empty?()) break /* ... */ }
[19:45:53] <duckinator> i believe that's a yes :P
[19:46:00] <shamanas> if switchTo() is bloking y
[19:46:13] <shamanas> no this is not a reason :P
[19:46:26] <shamanas> it goes through the coros list and switches through them
[19:46:29] <shamanas> then clears list
[19:46:38] <shamanas> if the switch function is not blocking
[19:46:43] <shamanas> neither is scheduler
[19:46:48] <duckinator> hm
[19:47:05] <shamanas> and the startCoro one xD
[19:47:21] <shamanas> how could we test this?
[19:47:25] <duckinator> i'm not sure
[19:48:02] <locks> hey smart people
[19:48:10] <shamanas> hey :P
[19:48:12] <duckinator> hey person
[19:48:36] <duckinator> 3 bugs until 1.9.2
[19:48:45] <shamanas> 0.9.2
[19:48:53] <shamanas> misstype again? xD
[19:49:00] <duckinator> ...yea :|
[19:49:04] <shamanas> :)
[19:49:13] <duckinator> i need to either stop using my numpad, or stop failing at using it xD
[19:49:16] <shamanas> ok lemme see those other 2 funcs
[19:49:20] <bartwe> so what is needed for 1.0.0 ?
[19:49:28] <shamanas> more stuff
[19:49:35] <shamanas> like rules or
[19:49:36] <locks> MOAR STUFF
[19:49:37] <duckinator> bartwe: ndd being happy with it :P
[19:49:42] <duckinator> locks: INDEED
[19:49:48] <duckinator> bartwe: or something like that
[19:50:06] <shamanas> thrw: @exit func <- how id you call that again?
[19:50:11] <shamanas> throw**
[19:50:20] <duckinator> hm?
[19:50:28] <shamanas> i saw that in an issue
[19:50:31] <shamanas> lemme find it
[19:51:04] <shamanas> ndd  woke up from the pokes :P
[19:51:47] <shamanas> found it! #179
[19:52:01] <shamanas> ANNOTATIONS!
[19:52:16] *** joshthecoder has joined #ooc-lang
[19:52:16] *** ChanServ sets mode: +v joshthecoder
[19:58:39] <shamanas> lulz @ code molestation
[19:58:54] <duckinator> well, it's true
[20:00:12] <shamanas> anyway i dont see how we could unwrap in if/else with x&&y||z (only adapted to ternary expressions)
[20:00:27] <duckinator> yea, hence the edit about it exploding/killing kittens/etc ;P
[20:00:53] <duckinator> only x&&y||z could be unwrapped, if you take it any further than that you get chaos
[20:01:36] <duckinator> like x&&y||z&&asdf == splat
[20:02:03] <shamanas> woot get outta here
[20:02:17] <duckinator> hm?
[20:02:19] <shamanas> :p
[20:02:36] <shamanas> yes i see how it could turn chaotic
[20:02:45] <duckinator> hmm
[20:02:47] <duckinator> oh!
[20:02:57] <duckinator> derp nevermind
[20:03:15] <duckinator> i was going to say we could handle it similarly to closures, but that doesn't work so well unless we can pass the entire context to it
[20:03:22] <duckinator> because, well
[20:03:48] <shamanas> you mean instead of embedded function -> closure/like thingy?
[20:03:54] <duckinator> blah: func { a := "hi"; return true ? a : "bai" }
[20:04:11] <duckinator> bah fuck it, i fail at explaining lol
[20:04:13] <duckinator> hm
[20:04:16] <duckinator> shamanas: yea
[20:04:23] <duckinator> but i'm not sure if that'll work
[20:04:30] <shamanas> i could see hw it could work
[20:04:32] <shamanas> how*
[20:04:45] <duckinator> well
[20:04:46] <shamanas> lemme think
[20:04:52] <duckinator> it can't be a real closure, because closures trigger the same bug
[20:04:56] <duckinator> so...problem...
[20:05:09] <duckinator> er, can't be treated like a normal ooc closure
[20:05:33] <shamanas> well we are talking at code generation level anyways right?
[20:05:40] <duckinator> ea
[20:05:41] <duckinator> yea*
[20:05:46] <duckinator> the issue is solely with code generation
[20:06:04] <shamanas> y
[20:06:04] <shamanas> so
[20:06:16] <shamanas> we create a context structure just like closures
[20:06:46] <shamanas> and the wrapper-like closure-like thingy
[20:06:53] <shamanas> that returns the Bool
[20:07:18] <shamanas> and just call the thingy with the context structure
[20:07:24] <shamanas> that does not seem SO bad
[20:07:37] <shamanas> if we limit this code generation to buggy cases
[20:07:39] <shamanas> now
[20:08:04] <shamanas> how do we determine if the expression needs wrapping or not?
[20:08:24] <duckinator> shamanas: i think if we replace function calls inside an expression with that setup, it should work
[20:08:26] <duckinator> like...
[20:08:27] <shamanas> just check for function in varargs? :P
[20:08:47] <duckinator> er
[20:08:50] <duckinator> man i wish i could explain shit xD
[20:09:04] <duckinator> hm
[20:09:11] <duckinator> brb
[20:09:12] <shamanas> gimme code if you can its a universal explanaton language :P
[20:09:21] <shamanas> ok waiting ;)
[20:10:05] <duckinator> shamanas: i actually have an idea to try when i get back, basically `a ? { b; c } : d` instead of `b; a ? c : d` if you get what i mean
[20:10:07] * duckinator brb
[20:10:45] *** joshthecoder has quit IRC
[20:11:20] <shamanas> what? that changes semantics
[20:11:39] <shamanas> b is supposed to be executed only if a is true
[20:12:00] <duckinator> back
[20:12:13] <duckinator> shamanas: where `b` is what rock /currently/ spews out
[20:12:17] <duckinator> aka everything i wrapped in a function
[20:12:22] <duckinator> i'm curious if a mere block would suffice
[20:12:28] <shamanas> oh lemme se
[20:12:29] <shamanas> see*
[20:13:35] <shamanas> but the call to the closure is in b right? :-/
[20:13:53] <duckinator> right
[20:14:17] <shamanas> so it will be called anyway, we want it to be called only if a == true
[20:14:36] <duckinator> hmm?
[20:14:37] <duckinator> well
[20:14:49] <shamanas> either i am terribly confused or ...
[20:15:03] <duckinator> well i'll pastebin what i just tried
[20:15:11] <duckinator> shamanas: i just tried this: https://gist.github.com/e0aa472fd50b88fcc533
[20:15:15] <duckinator> it doesn't even compile, it seems
[20:15:36] <duckinator> yea it expects an expression before the { :(
[20:15:57] <shamanas> oh i see :P
[20:16:15] <shamanas> why is this not valid
[20:16:21] <shamanas> C is stoopid  :-(
[20:16:34] <duckinator> it is
[20:16:53] <duckinator> and the inline function thing would be perfect, BUT you're right about it being hilariously hard to port
[20:17:06] <duckinator> afak it'd only work on gcc and /possibly/ clang
[20:17:10] <shamanas> y
[20:17:17] <shamanas> i think clang supports it
[20:17:53] <shamanas> (it has its own lambdas, i guss they would have implemented that before implementing them :P)
[20:18:12] <duckinator> hm
[20:18:13] <shamanas> so we come back to the closure-like thingy idea
[20:18:22] <shamanas> basically we are doing the inline function a-la ooc
[20:18:53] <duckinator> http://clang.llvm.org/docs/UsersManual.html#c_unimpl_gcc :(
[20:19:05] <duckinator> clang does not support nested functions; this is a complex feature which is infrequently used, so it is unlikely to be implemented anytime soon.
[20:19:11] <shamanas> :O
[20:19:13] <duckinator> </3 clang
[20:19:16] <shamanas> :P
[20:19:35] <shamanas> well nested functions do have some serious complications in C
[20:19:38] <shamanas> but anyway
[20:19:53] <shamanas> so just using them is out of question
[20:19:56] <duckinator> yea
[20:20:05] <duckinator> hmm
[20:20:34] <duckinator> or...hm
[20:20:54] <duckinator> shamanas: we might be able to use gcc's nested functions and clang's lambdas
[20:21:01] <duckinator> it'd be trickier, but possible
[20:21:04] <duckinator> but still, portability :(
[20:21:08] <shamanas> i dont like the idea
[20:21:34] <duckinator> hmm
[20:21:40] <duckinator> we support at least 3 compilers atm, i'm pretty sure
[20:21:52] <shamanas> we just use an ooc lambda :D
[20:21:54] <duckinator> `rock --help` says gcc tcc icc and clang, but idk about icc
[20:21:55] <shamanas> tcc is broken
[20:21:58] <duckinator> orly
[20:22:05] <shamanas> y there is an issue
[20:22:06] <duckinator> what about icc?
[20:22:11] <shamanas> dunno
[20:22:14] <duckinator> lol
[20:22:20] <duckinator> hm
[20:22:35] <shamanas> but still, why use compiler-only lambdas when we have ooc lambdas? :D
[20:22:44] <duckinator> shamanas: do you think using an ooc lambda would work?
[20:22:57] <shamanas> look
[20:23:05] <shamanas> i think
[20:23:08] <shamanas> if we construct a closure
[20:23:20] <shamanas> with the wrapped function as a thunk
[20:23:26] <duckinator> ooc closures have the same bug as vararg stuff
[20:23:28] <shamanas> and the needed variablesas a context
[20:23:39] <shamanas> and then just call it inside the ternary expr
[20:23:46] <duckinator> we could probably do something *similar*, though
[20:23:53] <duckinator> wait
[20:24:04] <duckinator> https://github.com/nddrylliog/rock/issues/239
[20:24:12] <duckinator>     lang_types__Closure __comboRoot1 = c__f();
[20:24:12] <duckinator>     false ? ((lang_types__Bool (*)(void*)) __comboRoot1.thunk)(__comboRoot1.context) : true;
[20:24:24] <duckinator> i wonder if that can be combined in some manner
[20:24:56] <shamanas> define combined
[20:25:06] <duckinator> into one statement that returns ((lang_types__Bool (*)(void*)) __comboRoot1.thunk)(__comboRoot1.context)
[20:25:59] <shamanas> that would be your wrapper thingy in this case
[20:26:03] <shamanas> something like
[20:26:16] <duckinator> right, BUT i meant something that isn't doing basically what a closure already does ;P
[20:26:30] <shamanas> { lang_types__Closure __comboRoot1 = c__f(); return ((lang_types__Bool (*)(void*)) __comboRoot1.thunk)(__comboRoot1.context); }
[20:26:38] <duckinator> would that work?
[20:26:49] <shamanas> no
[20:26:56] <duckinator> that's what i thought, because it exploded for me :(
[20:27:00] <duckinator> hmm
[20:27:10] <shamanas> the { ... } are here to indicate that they are in the nested func/lambda
[20:27:14] <duckinator> right
[20:27:43] <duckinator> well
[20:27:47] <shamanas> oh
[20:27:49] <shamanas> you mean
[20:27:55] <shamanas> the treranry should be
[20:28:14] <shamanas>  false ? ((lang_types__Bool (*)(void*))c__f().thunk)(c__f().context) : true;
[20:28:20] <duckinator> well, see
[20:28:26] <shamanas> this is wrong btw
[20:28:27] <duckinator> that's not what i meant, but at first i did think that
[20:28:43] <shamanas> we must not call c__f two times
[20:28:49] <duckinator> then i realized that since it's not a purely-functional language, that's just a huge mess waiting to happen
[20:28:51] <shamanas> ok go ahead with the fresh idea ;)
[20:29:00] <duckinator> well see, i don't know the syntax for it
[20:29:12] <duckinator> it's something like (foo, bar, baz) runs all of them and returns baz
[20:29:22] <duckinator> BUT you can't define vars
[20:29:28] <duckinator> so we end up back at square one
[20:30:02] <shamanas> wait
[20:30:13] <shamanas>  false ? ((lang_types__Bool (*)(void*))( __comboRoot1 = c__f()).thunk)(__comboRoot1.context) : true;
[20:30:16] <shamanas> MAY work
[20:30:38] <shamanas> i think C allows that
[20:30:44] <duckinator> o.o
[20:30:53] <duckinator> if plain c99 allows that, it'll work
[20:31:32] <duckinator> hm
[20:31:51] <shamanas> i have seen stuff like while(a = smth()) wich stp when a == NULL so i guess the value of (a = smth()) is a
[20:32:03] <shamanas> also
[20:32:12] <shamanas> i have an ooc sample wich allows this i think :P
[20:32:17] <shamanas> wait
[20:33:06] <shamanas> for(i in 0 .. (((b := stdin readLine() toInt()) > 0) ? b : 0)) { i toString() println() }
[20:33:23] <shamanas> pretty nice, huh? :D
[20:33:41] <duckinator> nice in the 'holy shit that really works? :O' sort of way, horrifying in terms of readability :D
[20:33:49] <shamanas> it does work
[20:33:58] <shamanas> it was designed to be a one-liner ;)
[20:34:20] <shamanas> could you try false ? ((lang_types__Bool (*)(void*))( __comboRoot1 = c__f()).thunk)(__comboRoot1.context) : true; then?
[20:34:23] <shamanas> i will brb
[20:35:35] <shamanas> back
[20:35:37] <duckinator> woah what...
[20:35:39] <duckinator> i found a fun bug
[20:35:54] <duckinator> f2: func -> Func -> Bool { "f was called." println(); g }
[20:35:54] <duckinator> g: func -> Bool { true }
[20:36:12] <duckinator> that compiles
[20:36:45] <duckinator> add this, still compiles: false ? f2()() : true
[20:37:02] <duckinator> ok nvm i failed
[20:37:22] <duckinator> i accidentally had `false && f2()() : true` not `false && f2()() || true` + did silly things with stderr ^^
[20:37:36] <shamanas> ok :P
[20:37:56] <duckinator> but yea
[20:38:21] <duckinator> currently testing both ?: and &&|| as well as both vararg and closures
[20:38:25] <shamanas> I actually came across the idea about the one-liner from php
[20:38:36] <shamanas> where you frquently do
[20:38:56] <shamanas> while($data = mysql_fetch_data($query)) { /* ... */ }
[20:39:01] <shamanas> or smth similar
[20:39:56] <duckinator> yea
[20:40:02] <duckinator> similar things done in C a lot, too
[20:40:07] <duckinator> especially when playing with sockets
[20:44:33] <shamanas> btw can we verload ? operator in ooc btw?
[20:44:48] <duckinator> hm
[20:44:49] <duckinator> idk
[20:44:49] <shamanas> overload*
[20:45:08] <shamanas> any luck?
[20:46:07] <duckinator> about to test
[20:46:37] <shamanas> kthnx
[20:47:25] <duckinator> no luck
[20:47:30] <duckinator> at least not directly copying yours
[20:47:33] <duckinator> i'll fiddle around a bit
[20:48:20] <shamanas> :-(
[20:50:08] <shamanas> "An assignment expression evaluates to the new value of the left-most operand. "
[20:50:27] <shamanas> should work :
[20:50:29] <shamanas> :O*
[20:52:37] <duckinator> oh i see what happened
[20:52:40] <duckinator> ((lang_types__Bool (*)(void*))( __comboRoot1 = test__f2()).thunk)(__comboRoot1.context)
[20:52:59] <duckinator> i think as soon as that ) after .thunk is reached, __comboRoot1 is no longer useful
[20:53:29] <shamanas> how so?
[20:54:06] <shamanas> The result of a simple assignment expression is the value assigned to the left operand
[20:54:15] <shamanas> comes from C specs i believe
[20:54:16] <duckinator> hm, actually..derp
[20:54:28] <shamanas> so the left operand is both assigned
[20:54:38] <shamanas> plus its value is the result of the expression
[20:54:43] <duckinator> hang on
[20:54:52] <duckinator> HAH
[20:55:01] <duckinator> shamanas: i forgot to declare it :)
[20:55:11] <shamanas> I loled :D
[20:55:18] <duckinator> YAY IT WORKS
[20:55:21] <duckinator> HOLY SHIT IN A BUCKET, IT WORKS
[20:55:22] <shamanas> :D:D:D:D:
[20:55:24] <shamanas> :D:D:D:D:D:D
[20:55:26] <shamanas> :D:D:D:D:
[20:55:33] <shamanas> Nice :)
[20:55:43] <duckinator> old:
[20:55:46] <shamanas> now lets see how it is done with other cases
[20:55:50] <duckinator> lang_types__Closure test____comboRoot1 = test__f2();
[20:55:50] <duckinator> false ? ((lang_types__Bool (*)(void*)) test____comboRoot1.thunk)(test____comboRoot1.context) : true;
[20:56:03] <duckinator> new:
[20:56:04] <duckinator> lang_types__Closure test____comboRoot1;
[20:56:04] <duckinator> false ? ((lang_types__Bool (*)(void*))( test____comboRoot1 = test__f2()).thunk)(test____comboRoot1.context) : true;
[20:56:23] <duckinator> does not call f2()
[20:56:28] <duckinator> i tried with `true ? ...` as well, and it called f2() :)
[20:56:55] <shamanas> oh
[20:57:13] <duckinator> oh?
[20:57:15] <shamanas> wait what
[20:57:17] <shamanas> :P
[20:57:23] <duckinator> it works
[20:57:24] <duckinator> that's all :P
[20:57:31] <shamanas> ok nothing i was confused forno reason
[20:57:32] <shamanas> xD
[20:58:31] <shamanas> false ? test__vargarg((lang_VarArgs__VarArgs) {          &({          lang_String__String_class(),          test__f()     };),          NULL,          1     };) : true;
[20:58:36] <shamanas> muhaha
[20:58:41] <duckinator> *twitch*
[20:59:22] <shamanas> false ? test__vargarg((lang_VarArgs__VarArgs) { &( lang_String__String_class(), test__f() }), NULL, 1 }) : true;
[20:59:49] <shamanas> this does not even use the new "technique"
[21:00:28] <shamanas> just throw the structure definition in the function call
[21:00:32] <duckinator> right
[21:00:47] <shamanas> this should work, right?
[21:00:54] <duckinator> i think so :D
[21:01:01] <duckinator> ok, it's official: my method works for closures
[21:01:11] <duckinator> including with the &&|| method
[21:01:20] <shamanas> nice :)
[21:02:36] <shamanas> i guess we just have to alter the code generation of closures in that case
[21:02:40] <duckinator> yup
[21:02:51] <duckinator> and it shouldn't be TOO difficult of a change, i don't think
[21:03:07] <duckinator> then again, this is coming from someone who's not touched that part of rock in ages
[21:03:12] <shamanas> but wont that change closure generation in all cases?
[21:03:21] <shamanas> in all places*
[21:03:23] <duckinator> shamanas: there's no real loss to doing so
[21:03:30] <shamanas> I hope we dont break anything
[21:03:35] <shamanas> y
[21:03:42] <duckinator> it should actually keep it from introducing more bugs in the future :)
[21:03:44] <shamanas> i think that the transition will be smooth :)
[21:03:57] <duckinator> i'm looking into vararg stuff now
[21:05:28] <shamanas> ok in the meanwhile i will try to apply the changes to my fork ;)
[21:05:39] <duckinator> \o/
[21:05:52] <duckinator> i'd love to get a real solution for this pushed by 0.9.2 ^^
[21:06:02] <duckinator> that'd be great
[21:06:05] <shamanas> y
[21:06:09] <shamanas> i agree :)
[21:06:19] <shamanas> and it will be a burden well disposed of :)
[21:08:21] <duckinator> inlining 12 lines of code into a function call is going to be horrifying :D
[21:09:37] <shamanas> but sweet :D
[21:09:38] <shamanas> :P
[21:09:41] <shamanas> nah jk
[21:10:04] <shamanas> actually the change we decided is quite specific will not afect all closures
[21:10:13] <duckinator> hm?
[21:10:28] <duckinator> shamanas: so they're printed differently in those cases?
[21:10:44] <shamanas> i do not know exactly
[21:10:45] <shamanas> aaarg
[21:10:58] <shamanas> lemme find the place to change i talked too early :)
[21:11:05] <duckinator> either way
[21:11:15] <duckinator> i do not see *ANY* way for it to cause damage unless something else was designed horribly wrong
[21:11:19] <duckinator> in which case... :)
[21:13:01] <duckinator> FUCK
[21:13:02] <duckinator> YES
[21:13:03] <duckinator> FUCK YES
[21:13:08] <duckinator> YAY
[21:13:26] <duckinator> shamanas: I GOT IT :D:D:D:D:D:DDD::D:::D:D:D:D:DDD:D::D:DD:::DD:D:D
[21:13:38] <shamanas> how? :D
[21:13:44] <duckinator> i also condensed 13 lines into 8 in the process xD
[21:13:51] <shamanas> niiice :D
[21:13:57] <shamanas> :P
[21:14:00] <duckinator> it's long and spammy, i'll pastebin after verifying it works on two() :)
[21:14:02] <shamanas> show me show me!
[21:14:14] <shamanas> :D
[21:16:52] <duckinator> shamanas: https://gist.github.com/1191631
[21:17:23] <shamanas> yay as i thought :)
[21:17:32] <duckinator> well i have to go
[21:17:33] <duckinator> bbl o/
[21:17:40] <shamanas> now we must find the places to edit
[21:17:42] <shamanas> noes!: P
[21:17:46] <shamanas> ok ill try to fix
[21:17:55] <duckinator> alright i'll take a look later if you can't get it :D
[21:17:56] <shamanas> cya then
[21:33:35] <shamanas> bb every1 gtg
[21:33:44] *** shamanas has quit IRC





top