<< 27-07-2013 >>
00:01:28BitPuffinEXetoC: please also add a comment to the pull request containing the text from http://unlicense.org/ under "unlicensing contributions" :)
00:03:06BitPuffinor to a commit message or something
00:05:07*rubino123 quit (Quit: Leaving)
00:06:18EXetoCit's a range, either implicitly or explicitly. anyway, I'll use the previous convention
00:06:21BitPuffinEXetoC: actually what does ~= do?
00:06:42BitPuffinEXetoC: well T is still something like int, float or whatever
00:06:54BitPuffinbut it works when I is not constrained I guess
00:09:03EXetoCthat's usually just the letter they start at, and then they continue with U etc, unless given a proper name, but yeah sure. ~= is for approximate equality, but I should modify that function a little
00:12:09BitPuffinapproximate equality you say
00:12:14BitPuffinwell
00:12:18BitPuffinmaybe that's useful
00:13:09EXetoCshould T not be constrained to TNumber?
00:13:41BitPuffinEXetoC: I was planning to change that a bit later
00:13:43BitPuffinbut yeah
00:13:47BitPuffindefinitely
00:15:37BitPuffinEXetoC: I see a problem in your implementation of swizzle
00:15:57BitPuffinch in SwizzleArray blabla is not the best idea
00:16:11BitPuffinit should be adapted after the dimension of the vector
00:16:17BitPuffinnot the chars of the string
00:17:17EXetoCyes, I hit that len bug and then I forgot about it
00:17:48BitPuffinbtw thanks for putting in the work to do this :)
00:20:08dom96good night
00:20:14BitPuffinshouldn't swizzleimpl be an iterator really?
00:20:17BitPuffinnight dom96!
00:20:28BitPuffinor I guess maybe not
00:21:42BitPuffinfor i, component in swizzleImpl[range[0.. <str.len], vec[0].type](str):, type and range should be reversed
00:22:15BitPuffinand it seems like range[0..<str.len] might benefit from being computed only once?
00:22:34BitPuffinwell str.len at least
00:22:54BitPuffinit is computed 3 times
00:23:47BitPuffinand there is minor stuff that you didn't know that I'll refactor later :)
00:24:07EXetoCok, but it's probably inlined an everything
00:25:27EXetoCand only of them at run-time
00:26:32EXetoCI'm so used to the order of the array type params
00:26:37BitPuffinEXetoC: which is?
00:26:58BitPuffinah yeah I can see why
00:29:44BitPuffinEXetoC: why the #Ditto over ~=?
00:30:28BitPuffincome to think about it a[i] + b[i] > 0.000001 doesn't work at all
00:30:43EXetoCthere was a comment above it before
00:31:15BitPuffinwhat if a[i] = 4.00000000007, and b = 4.00000000008
00:31:24BitPuffinthen it will definitely be > 0.0000001
00:31:43BitPuffinso it should really be a[i] - b[i] < 0.0000001
00:31:50BitPuffinor wait
00:31:55BitPuffinwithin some range
00:32:08BitPuffinless than whatever and greater than whatever
00:33:19EXetoCit was supposed to be abs(a[i] - b[i])
00:37:10BitPuffinEXetoC: adding some notes so it's an easy list to go through
00:38:14EXetoCit is, but my brain power is low
00:38:19EXetoCtoo late for coffee? :>
00:39:26BitPuffinmaybe a little!
00:39:31BitPuffindoesn't have to be done tonight :)
00:39:39BitPuffinbut I guess it's nice when it's fresh
00:42:28BitPuffinEXetoC: there we go, think that was all the things I mentioned
00:44:11EXetoCalright
00:44:49*DAddYE quit (Remote host closed the connection)
00:51:54BitPuffinwell I'm going to bed, cheers everybody!
00:52:05EXetoCbye
00:52:05BitPuffinand thanks EXetoC again for your work :)
00:52:18EXetoCwhen .. for ch in str: when... doesn't work
00:52:22EXetoCnp c(:)
00:52:43EXetoC"Error: constant expression expected" oh well. some other time then
00:54:22BitPuffinEXetoC: oh right, but yeah check dom96's comment, should pretty much solve it
00:54:50BitPuffinnight!
00:56:12EXetoCgood luck
00:59:58*BitPuffin quit (Ping timeout: 276 seconds)
01:46:02*DAddYE joined #nimrod
01:50:30*DAddYE quit (Ping timeout: 264 seconds)
02:03:54*EXetoC quit (Quit: WeeChat 0.4.1)
02:03:55*rubino123 joined #nimrod
02:04:10rubino123does nimrod allow for manual memory mangement?
02:40:50*q66 quit (Quit: Leaving)
02:51:48*Associat0r joined #nimrod
02:51:48*Associat0r quit (Changing host)
02:51:48*Associat0r joined #nimrod
02:58:42OrionPKrubino123 see: http://nimrod-code.org/gc.html
02:58:53OrionPKyou can turn GC off with a compiler switch, gc:none
03:01:17OrionPKand this: http://nimrod-code.org/system.html#606
03:09:44*DAddYE joined #nimrod
04:08:43*Endy joined #nimrod
04:17:50rubino123thansk
04:17:55rubino123thanks
04:35:09*OrionPK quit (Quit: Leaving)
05:39:31*DAddYE quit (Remote host closed the connection)
05:40:03*DAddYE joined #nimrod
05:44:30*DAddYE quit (Ping timeout: 264 seconds)
05:52:11*rubino123 quit (Quit: Leaving)
05:53:18*[1]Endy joined #nimrod
05:57:06*Endy quit (Ping timeout: 264 seconds)
05:57:06*[1]Endy is now known as Endy
06:40:52*DAddYE joined #nimrod
06:48:06*DAddYE quit (Ping timeout: 264 seconds)
07:21:36*zahary quit (Quit: Leaving.)
07:48:00*DAddYE joined #nimrod
08:41:41*Associat0r quit (Quit: Associat0r)
09:23:39dom96'morning
09:29:25Araqhi dom96
09:31:32dom96sup?
09:32:03Araqnot much
09:32:11Araqfilling all the missing stuff for vm
09:38:52dom96cool cool
09:52:16*BitPuffin joined #nimrod
09:56:03dom96BitPuffin: o/
09:56:11BitPuffindom96: \o
09:58:10dom96hrm, seems graphics.drawEllipse is broken.
09:59:15Araqlol
09:59:27Araqyou worked on it for hours :P
10:03:33Araqyay lunch, bbl
10:04:02BitPuffinhaha
10:04:15BitPuffinis the VM thing in master yet?
10:04:28Araqsure but it can only run small things
10:04:35Araqimport compiler/nimeval
10:04:56Araqexecute("""my nimrod code here""")
10:06:14dom96hrm, so you changed what Natural means.
10:07:02*DAddYE quit (Remote host closed the connection)
10:07:34*DAddYE joined #nimrod
10:07:46BitPuffinthat's awesome
10:09:12BitPuffinhmm
10:09:15BitPuffinah
10:09:17BitPuffincompiler/nimeval
10:10:01BitPuffinError: cannot open 'compiler/nimeval'
10:12:06*DAddYE quit (Ping timeout: 264 seconds)
10:13:14BitPuffinoh we''
10:14:47BitPuffinHow does one do to kind of emulate interfaces in nimrod
10:15:28dom96a list of closures.
10:15:30BitPuffinI want the user to be able to pass whatever, a tuple of proc pointers or whatever to customize the behaviour of the api
10:16:27BitPuffindom96: I guess that should be fair enough
10:16:57BitPuffinbut does this give me polymorphism?
10:20:14dom96Dunno. Maybe.
10:21:18BitPuffinwell
10:21:40NimBotAraq/Nimrod master 8ece3f5 Dominik Picheta [+0 ±1 -0]: Fixes #543.... 2 more lines
10:21:40NimBotAraq/Nimrod master dd2263b Dominik Picheta [+0 ±1 -0]: Fixes graphics.drawEllipse.... 4 more lines
10:22:03BitPuffina tuple of the same dimensions and types are considered equal
10:28:49Araqdom96: I don't think so but the compiler emits more range checks, that was a bug
10:29:02*EXetoC joined #nimrod
10:29:18dom96Araq: ahh, well I changed it to an Int and all is fine.
10:32:57EXetoChi
10:33:06dom96hey EXetoC
10:41:26EXetoCBitPuffin: static doesn't help
10:48:15EXetoCdom96: yep, 'error' does work
10:48:25dom96good :)
10:49:23BitPuffinhey EXetoC
10:49:33BitPuffinhmm okay
10:51:28BitPuffinAraq: hey! Funny thing, Apple doesn't even allow you to download scripts ._.
10:52:03EXetoCsurprising
10:52:48BitPuffinso basically, I'm gonna have to put the full game in the apple store then and then log in to unlock
10:53:03BitPuffinmaking updates huge but yeah
10:56:42*q66 joined #nimrod
10:57:18EXetoCwhat about cross product for 7D vectors? :>
11:10:04AraqBitPuffin: lets hope apple is dead when your game is ready
11:10:22EXetoCyeah!!!
11:11:59BitPuffinEXetoC: fuckit :)
11:12:11BitPuffinEXetoC: meh I might add it later on. Just a PITA :)
11:12:16BitPuffinAraq: yeah seriously
11:12:41BitPuffinAraq: the funny thing is that the guys on mac will have a wonderful experience, but iOS? noooo
11:43:52BitPuffinbut yeah
11:44:08BitPuffinwill probably not do iOS version until it's finished for all platforms
11:45:33BitPuffinEXetoC: did macros.error fix the runtime thing?
11:48:12EXetoCBitPuffin: nah, the check was basically the same as the one in the exported function
11:48:38BitPuffinEXetoC: so there's no solution?
11:48:45BitPuffinwhere is the error exactly
11:51:11EXetoCit was an error check. something like this: "when vec.len <= 3: for ch in str: when ch...", and yes I tried with static as well, which should be the correct way of doing it, but 'ch' is not being recognized as a constant expression
11:52:42BitPuffinHmm
11:52:45BitPuffinfile a bug report?
11:53:02BitPuffinafter all we're taking a string literal so it should be a constant expression
11:55:21BitPuffinEXetoC: the problem is that swizzleimpl is a proc
11:55:41dom96hrm, where is this?
11:56:00BitPuffinhttps://gist.github.com/BitPuffin/6094661
11:56:27BitPuffindom96: in swizzleImpl
11:57:09BitPuffinor wait
11:57:12BitPuffinisn't it this line?
11:57:20BitPuffinhttps://github.com/BitPuffin/linagl/pull/1/files#L0R129
11:58:29EXetoCit compiles as it is
11:58:37BitPuffinAlso isn't it more efficient to make swizzleimpl an iterator? now we are creating an array (thus iterating through it) and then we are iterating through it once again in {}
11:58:43dom96have you tried using string{lit} in the proc?
11:58:55BitPuffinthat works?
11:59:00dom96no idea
11:59:17EXetoCdom96: no, but it runs at compile-time already
11:59:26EXetoCso I don't know what it's supposed to solve
11:59:38dom96well then what's the problem?
11:59:49EXetoCmaking it a lit anyway
11:59:54EXetoCdom96: I'll gist it
12:01:04BitPuffinwell
12:01:19BitPuffinI guess the problem is that it stops working gwith d:release too doesn't it?
12:01:32BitPuffinmaybe that's fine
12:05:21EXetoCyes it's a pretty minor issue
12:05:48dom96that doesn't seem like a minor issue
12:06:06BitPuffinif you've tested it in debug mode and it works then you don't want unecessary checks in the release version
12:06:20EXetoCbut it's an assert
12:06:20BitPuffindom96: well asserts are removed in d:release
12:06:38EXetoCyeah but what are you getting at then?
12:06:47EXetoCmaybe I misread
12:06:49dom96why is it a problem then?
12:06:56dom96if that is in fact what you want?
12:07:19EXetoCdom96: it's possible to catch this at compile-time
12:07:25BitPuffinyeah
12:07:32dom96FYI You can use doAssert which will stay in release mode.
12:07:36BitPuffinthat's the problem it should always be cought at compile time
12:07:39EXetoCit should be, but the impl doesn't allow it. like I said, minor issue, but I'll add it some day
12:07:42BitPuffindom96: isn't that runtime?
12:07:56dom96yes.
12:08:30dom96So the problem is that swizzleImpl doesn't work at compile-time?
12:08:31BitPuffinwell then there is no point
12:08:50BitPuffinit doesn't catch invalid characters at compile time when doing d:release
12:09:44EXetoCI still consider it a minor issue. how often would that be caught in a release build but not otherwise?
12:10:30BitPuffinyou mean the other way around?
12:11:37dom96oh i see, you guys are referring to this: https://github.com/EXetoC/linagl/blob/swizzle/src/linagl/vector.nim#L129
12:12:08dom96I should have clicked BitPuffin's earlier link heh
12:12:46BitPuffindom96: yes you should have! >:)
12:13:15dom96I guess the compiler doesn't allow: when component < vec.len: {.fatal: ....}
12:14:13EXetoCdom96: no it's not that
12:14:15BitPuffinno I think the problem is that you can't do when inside a loop
12:14:39dom96yes, i see.
12:15:09BitPuffinwhich I don't really get why
12:15:19BitPuffinyou should be able to do when inside of a case statement even :P
12:15:25dom96The for loop is the same as an 'if' i.e. it's not happening at compile-time.
12:15:28BitPuffinthat's how I was gonna do it initially
12:15:50BitPuffinwhen the length is greater than bla, add this of branch
12:16:03dom96would be nice if we could just prepend some symbol to force it to happen at compile-time
12:16:12EXetoCdom96: static?
12:16:23EXetoCno good?
12:16:24dom96yes, but we're not C.
12:16:41EXetoCbut it's used in this way already
12:16:58BitPuffinI really would like a way to do what I just said
12:16:58dom96You would have to use a {.static.} pragma.
12:17:16BitPuffinconditional compilation to add extra of branches etc or elif or whatever
12:17:19EXetoCBitPuffin: that's what I was trying to do
12:17:25dom96BitPuffin: I think you would need to use macros for that.
12:18:02BitPuffinhmm
12:18:03dom96EXetoC: where?
12:18:06BitPuffinwrite my own macro?
12:18:13dom96yes
12:18:13BitPuffinor an existing one
12:18:13EXetoCseems like the wrong way to go, when these compile-time checks are supposed to work
12:18:43dom96indeed, I think we should have a compile-time equivalent to for, while, case, etc.
12:18:51dom96just like we have when as a compile-time equivalent to 'if'
12:18:58BitPuffinyeah
12:19:43BitPuffinbut also add a line inside a runtime loop based on conditional compilation
12:19:52dom96but actually
12:20:00dom96It would be pretty simple to just replace the for loop with a macro
12:20:08BitPuffin(and add branches to conditions based on conditional compilation)
12:20:22dom96the macro could do all the checking and generate the result[i]
12:21:09dom96I would almost argue that templates can only get you this far and that you should use macros for stuff like this.
12:21:11EXetoCbut the only thing missing is these checks
12:22:49dom96let me try to write a macro which does this
12:22:54*BitPuffin needs to finish reading the manual, haven't gotten to macros yet :P
12:23:20dom96btw I don't think you need that 'result' at the end.
12:23:28dom96Result is returned implicitly.
12:23:56BitPuffindom96: ah, I wasn't sure if templates had a result variable like procs
12:24:08EXetoCdom96: no, that doesn't work. the result is the whole expression inside the template
12:24:17EXetoCI've tried it
12:24:38dom96oh
12:24:41dom96I see.
12:25:12dom96I'm still not used to the stmt/expr unification
12:25:27dom96Pretty cool that so much code can be considered a single expr nowadays
12:25:28BitPuffinunification?
12:25:45EXetoCdom96: I might've been thinking of AST's when you said macro
12:25:55EXetoCI tried to use a macro, but got "out of memory", which isn't very helpful
12:26:15dom96that is what you should have thought of
12:26:25dom96BitPuffin: yeah, that only happened recently.
12:26:28EXetoCwhat is?
12:26:39dom96AST's when I said macro
12:26:43BitPuffinwell what do you mean?
12:27:03EXetoCok it's still unnecessary then, but go ahead
12:27:35EXetoCBitPuffin: "var w = if x: y: else: z"
12:27:46EXetoCyou wouldn't be able to do that had 'if' not been an expression
12:28:03EXetoCoops, too many colons
12:28:22BitPuffinEXetoC: ah yeah I saw that in the docs, made me happy
12:28:23EXetoCbut now almost everything is, so that's why the template can generate an expression
12:28:27EXetoCya
12:28:36dom96yes and also: if (var x = blah.foo; x == 5): "hello"
12:28:38dom96works I think.
12:28:52dom96I didn't even have a chance to try this stuff properly.
12:29:02EXetoCoh, that's useful
12:29:34EXetoCBitPuffin: there are a couple of limitations though. that example won't work if there's another branch that unwinds the stack
12:30:10dom96Although I would still in most cases prefer to take the var definition out of the if condition.
12:31:34EXetoCso then you must do "if x: w = y elif a: w = p else: raise EOhai". but it's mostly an issue when the branch count is high
12:36:08BitPuffinah
12:36:10BitPuffinoh well
12:44:50dom96why is swizzleImpl's array's type a generic?
12:45:01dom96It's always set to an int?
12:47:08EXetoCgood question
12:51:52dom96well, I crashed the compiler...
12:52:18dom96Generics don't go well with macros I guess heh
12:53:13dom96on the bright side I got a nice example to reproduce it
12:56:02EXetoCadding compile-time variations of every block type would add nothing since we have static.
12:56:05*jbe_ joined #nimrod
12:57:08dom96https://github.com/Araq/Nimrod/issues/552
12:57:13dom96If you're interested in seeing what I tried.
12:59:22dom96If I get rid of the generics I get 'constant expression expected', which is what you got EXetoC isn't it?
13:10:26EXetoCdom96: yes
14:05:46EXetoCMy issue hasn't been reported before, right? Nothing of relevance is open
14:07:19dom96Not that I can recall
14:10:39BitPuffindom96: sure you have the latest version of the compiler?
14:10:58dom96possibly a couple commits old why?
14:11:12dom96oh did Araq fix the .len stuff
14:13:06BitPuffindom96: yeah he fixed the constant expression required
14:13:16BitPuffinexpected
14:13:16BitPuffin*
14:23:22*BitPuffin quit (Ping timeout: 276 seconds)
14:25:10*BitPuffin joined #nimrod
14:29:27*OrionPK joined #nimrod
14:31:18*BitPuffin quit (Ping timeout: 264 seconds)
14:37:06*[1]Endy joined #nimrod
14:39:06*Endy quit (Ping timeout: 264 seconds)
14:39:06*[1]Endy is now known as Endy
14:48:49EXetoCbeepbeep
14:51:43dom96boop boop
15:08:31dom96Araq: Looks like your C code gen for gensym is a bit broken. When I use gensym my object doesn't get initialised properly.
15:08:44dom96(When initialising with a contructor)
15:08:47dom96*constructor
15:13:03*Araq0 joined #nimrod
15:14:03Araq0Dom96 you still need to put the gensym in a var/let block
15:14:30dom96I did
15:14:48Araq0Hmm
15:15:32Araq0Oh well i will fix it
15:18:53Araq0La la la bugs everywwhere
15:20:34*Araq0 quit (Quit: Bye)
15:55:35*jbe_ quit (Remote host closed the connection)
16:01:40*Endy quit (Ping timeout: 264 seconds)
16:16:27EXetoCbugs, still? oh man :p
16:43:03*DAddYE joined #nimrod
16:49:43EXetoCDAddYE: lo
16:49:56DAddYEEXetoC: moooooooorning
16:50:09dom96afternoooon
16:54:09EXetoCwe don't have something like "iterator stride[T](a: openarray[T], step: int): seq[T]", right?
16:54:44EXetoCor openarray[T] -> set[T]
16:54:45dom96countdown/countup has a step param
17:04:11DAddYEdo you know if there is some thing better than boehmgc?
17:04:25DAddYEas a C library
17:10:07EXetoCdom96: it's different, but not too far off
17:16:10*Endy joined #nimrod
17:37:36*DAddYE quit (Remote host closed the connection)
17:38:03*DAddYE joined #nimrod
17:42:28*DAddYE quit (Ping timeout: 264 seconds)
18:03:07*Mat2 joined #nimrod
18:03:12Mat2hi @ all
18:08:46*DAddYE joined #nimrod
18:12:37EXetoClo
18:30:43*DAddYE quit (Remote host closed the connection)
18:30:55*DAddYE joined #nimrod
18:34:36*Endy quit (Quit: HydraIRC -> http://www.hydrairc.com <- The alternative IRC client)
19:11:12EXetoCteach me how to not suck at bit-fiddling plz
19:12:06Araq(x and 0b11) == 0b11 # last 2 bits are 1
19:12:40Araqx = x or 0b010 # set bit number 1, other bits are left as they are
19:12:47Mat2EXetoC: you don't want to suck what ???
19:13:15Araqx = x and not 0b10 # clear 1st bit (bits start at 0 of course)
19:13:29AraqEXetoC: that's pretty much it
19:13:43Araqyou can convert the 0b to 0x number to feel like a C programmer
19:16:00EXetoCj/k. it just takes ages because of lack of imagination
19:24:54EXetoCthere's no 'high' for uint?
19:25:56Araqno the compiler uses int64 internally and high(Uint) can be high(uint64) which the compiler can't handle :P
19:32:10EXetoCI don't get it. it's just 0xffffffffffffffff'u64
19:32:59*gradha joined #nimrod
19:35:35EXetoCis returning a different type no good?
19:38:23AraqEXetoC: meh I don't feel like explaining it
19:42:54EXetoCok. I'll just disallow uint64. not worth the hassle
19:43:57Araqdisallow unsigned numbers altogether. they have very bad properties anyway
19:44:51Araqthe extra half dimension (aka negative numbers) really helps avoiding bugs
19:45:57*Araq uses unsigned mostly for bit vectors, not for arithmetic
19:46:48gradhaAraq: the idetools interface accepting column numbers doesn't handle unicode, meaning that the input is not a column number but rather byte offset
19:47:05Araqgradha: that's a feature
19:48:40gradhadoes the compiler support non ascii/utf8 file encodings?
19:48:48Araqnope
19:50:51EXetoCsame here. still, it's just "proc high*(t: typedesc[uint64]): uint64 = 0xffff_ffff_ffff_ffff'u64". and "uint is uint64" is false. I can just use sizeof though
19:52:03AraqEXetoC: ever occured to you that 0xffff_ffff_ffff_ffff is -1?
19:53:45Mat2EXetoC: https://en.wikipedia.org/wiki/Two%27s_complement
20:02:59EXetoCAraq: I don't know. it's not like it's easy to validate
20:06:08EXetoCdoesn't it mean that it first treats that part of the literal as int or int64 or whatever, and then converts it to uint64? which would be confusing since it's a single literal
20:14:44gradhaif you want to use nimrod's forum, you will now have to accept the new license http://forum.nimrod-code.org/t/186
20:15:07gradhato accept the license, you can send me all your monies and click with your head on the screen
20:15:14EXetoCin other words, isn't the suffix relevant?
20:15:38EXetoCit doesn't overflow or anything
20:28:57*Associat0r joined #nimrod
20:28:57*Associat0r quit (Changing host)
20:28:57*Associat0r joined #nimrod
20:29:20AraqEXetoC: dunno, I'm busy
20:30:08*rubino123 joined #nimrod
20:43:26*DAddYE quit (Remote host closed the connection)
20:44:24EXetoCso it's never converted to -1 or anything. it is if I get rid of the suffix, but then it's unsigned, so yeah
20:45:29EXetoCyeah that's fine. this is a minor issue like you said. almost no one needs to manipulate very large values arithmetically
20:46:16AraqEXetoC: lots of people need to do that but then the 1 additional bit for "unsigned" doesn't cut it
20:49:21EXetoCright
20:50:09EXetoCinitColor(0xrrrr_gggg_bbbb_aaaa'u64). reeeally useful :p
20:51:36gradhawouldn't you need to unpack the values first anyway to operate on them?
20:55:59EXetoCgradha: what do you mean? the components are converted to floats and then normalized. the color type is just a tuple of floats
20:57:45gradhain that call you are using an u64, it wouldn't make much difference if it was a signed integer, right? as you say, you need to convert them first to normalized floats
20:58:09*DAddYE joined #nimrod
20:58:44*Endy joined #nimrod
20:59:48dom96never fear I is here.
21:00:51EXetoCgradha: it accepts any unsigned type, so it'd be a little weird
21:00:59EXetoCanyway, it's not supposed to be particularly useful :p
21:01:07EXetoCI have an overload that takes a string anyway
21:03:41dom96What's up guys?
21:04:04EXetoCdom96: 101011010101
21:04:46gradhadon't be so negative
21:05:09gradhaunless you are being unsigned
21:05:26EXetoClol
21:07:20gradhadom96: have you decided already what will you waste your month of freedom on?
21:08:17Mat2ehm, converting from unsigned integers to floats without precision loss ? Yeah, how ??
21:08:26EXetoC?
21:08:40dom96gradha: All sorts of Nimrod projects
21:08:46EXetoCI don't know what precision has to do with it
21:08:55EXetoCit's just another way of specifying color components
21:09:00gradhadom96: that's not really a decission, just a rough idea
21:10:14gradhato be more specific you could improve the "Could not bind socket, retrying in 30 seconds" jester thingy
21:11:19EXetoCI managed to avoid that before. that is, having to wait for some time after exiting the program, if that's even the same issue
21:11:38dom96gradha: yes, my priority is currently to finish the new async stuff.
21:12:43Mat2EXetoC: Since a float has a larger range, it necessarily sacrifices some precision. This means that there are some unsigned int values that cannot be accurately represented in a float
21:12:56dom96gradha: I will fix it eventually though.
21:13:07EXetoCMat2: yeah, but it doesn't matter in this case
21:14:05Mat2ok, then feel free to go on
21:14:39dom96Araq: Fixed the gensym bug yet?
21:18:39Araqdom96: no, is there a bug report for it?
21:19:11dom96not really
21:19:11EXetoCMat2: I'm just implementing this: let red = initColor("f00f"), and some other overloads
21:19:15*DAddYE quit (Remote host closed the connection)
21:19:19EXetoC== (1.0, 0.0, 0.0, 1.0)
21:21:02Araq4 floats for a single color value? that's madness
21:22:00gradhaespecially if you deal with hdr/raw pictures
21:22:28dom96Araq: I don't feel like reproducing it :P Mind just building tasyncitermacro?
21:22:57Mat2well, that would probably make sense as alpha vector for some kind of sophisticated filter ?
21:22:57Araqis that a test you added?
21:23:01dom96yes
21:23:12dom96It's in the asyncmacro branch
21:23:43Araqhow nice of you
21:23:55Araqnow I need to switch branches, gah :P
21:25:07EXetoCMat2: I'm writing OpenGL code
21:28:18Mat2why don't you just create a texture map, spanned to a solid with screen depth and use it as bitmap ?
21:29:09Mat2or use a library like Allegro, which does this for you
21:30:07EXetoCit's just one color per primitive, which is passed to the shader
21:37:49EXetoCallegro, and not have to write stuff myself? never :p
21:37:54*gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=1ZZC82dgJr8 again)
21:39:11Mat2have you ever programmed in Basic ?
21:39:39EXetoCno
21:40:34Mat2C++ ?
21:40:45EXetoCyeah
21:41:00Mat2ah .. ok
21:41:05EXetoCstopped using it maybe 3 years ago
21:49:57*DAddYE joined #nimrod
21:57:40*DAddYE quit (Read error: No route to host)
21:57:53*DAddYE joined #nimrod
22:01:21Mat2get some sleep, ciao
22:01:27EXetoCalready? :/
22:01:28EXetoCcya
22:01:43*Mat2 quit (Quit: Verlassend)
22:02:13*Endy quit (Ping timeout: 248 seconds)
22:06:39*DAddYE quit (Remote host closed the connection)
22:19:04dom96Someone should recreate this in Nimrod: https://www.bloc.io/ruby-warrior
22:21:06EXetoCyeah, I don't know Ruby :/
22:21:47dom96huh, that's not open source :\
22:22:15EXetoCpfft, lame
22:32:02apotheonSomeone should make a version for Nimrod that's better.
22:32:13apotheon. . . and use a copyfree license for it.
22:32:36apotheon. . . 'cause "not open source" is lame.
22:33:07apotheonNow, I'm off to a wing grilling party. I must deliver a case of beer and consume wings.
22:35:55dom96have fun :)
22:37:47*DAddYE joined #nimrod
22:54:38*rubino123 quit (Ping timeout: 240 seconds)
23:07:46*rubino123 joined #nimrod
23:11:33*DAddYE quit (Ping timeout: 248 seconds)
23:29:17*Associat0r quit (Read error: Connection reset by peer)
23:30:27*Associat0r joined #nimrod
23:50:52dom96oh cool, tangentstorm's repo is on top of HN
23:56:27EXetoCof wut
23:56:41dom96oh look someone is advertising Free Pascal
23:56:44dom96Time to mention Nimrod
23:58:49EXetoCtell them about my pretty single-colored widgets
23:59:24dom96your what?
23:59:34EXetoCnm