| 00:10:08 | * | XAMPP_ joined #nimrod |
| 00:11:34 | * | XAMPP quit (Ping timeout: 246 seconds) |
| 00:19:39 | * | XAMPP_ quit (Quit: Leaving) |
| 00:20:19 | * | XAMPP joined #nimrod |
| 00:28:32 | * | Trixar_za is now known as Trix[a]r_za |
| 01:51:19 | * | q66 quit (Quit: Quit) |
| 04:47:43 | * | XAMPP quit (Ping timeout: 246 seconds) |
| 05:18:30 | * | silven quit (Ping timeout: 268 seconds) |
| 05:20:03 | * | silven joined #nimrod |
| 06:53:25 | * | comex quit (Read error: Operation timed out) |
| 06:56:07 | * | comex joined #nimrod |
| 09:09:20 | * | zahary joined #nimrod |
| 09:20:08 | * | zahary quit (Quit: Leaving.) |
| 09:20:35 | * | zahary joined #nimrod |
| 10:08:06 | * | Trix[a]r_za is now known as Trixar_za |
| 10:12:28 | * | q66 joined #nimrod |
| 10:20:18 | * | Boscop quit (Disconnected by services) |
| 10:20:20 | * | Boscop joined #nimrod |
| 12:51:51 | * | apriori_ joined #nimrod |
| 13:21:24 | * | Araq is now known as Araq_win |
| 13:22:46 | Araq_win | today is release day :-) |
| 13:24:05 | * | dom96 jumps up and down in excitement |
| 13:25:11 | Araq_win | and afterwards we'll move to a branch based model so that people get bugfixes without code breakage |
| 13:26:41 | apriori_ | Araq_win: could you elaborate on that |
| 13:26:44 | apriori_ | ? |
| 13:27:07 | apriori_ | you will have 1) stable branch, compatible bugfixes only and 2) breaking next release? |
| 13:27:16 | Araq_win | yes exactly |
| 13:27:22 | apriori_ | okay |
| 13:27:41 | Araq_win | we always tell people to use the github version as the latest stable release is always too old |
| 13:27:44 | apriori_ | question is.. will you backport patches? |
| 13:27:52 | apriori_ | this is often quite some extra work |
| 13:27:57 | Araq_win | I will backport patches, yes |
| 13:28:03 | apriori_ | okay |
| 13:28:23 | Araq_win | it's almost always very easy for me to decide whether it will break code or not |
| 13:28:24 | dom96 | Well looks like I will have to add branch support to nimbuild ASAP |
| 13:28:59 | Araq_win | well it would be nice if nimbuild would at least compile with 0.9.0 :P |
| 13:29:00 | apriori_ | Araq_win: with a tigther test suite you can pretty much automate that |
| 13:29:14 | Araq_win | our test suite is not bad |
| 13:29:42 | Araq_win | we have over 500 tests some of which are quite stressing |
| 13:29:47 | apriori_ | didn't really check.. but it was obvious that it didnt catch all (hell, which testsuite does?) |
| 13:30:17 | apriori_ | 500... well, that's really much |
| 13:30:34 | Araq_win | well *cough* the tester used to skip a large fraction of the tests and nobody noticed :D |
| 13:30:44 | Araq_win | but I fixed that |
| 13:31:43 | apriori_ | hehe |
| 13:32:14 | apriori_ | so one would need a tester for the tester.. for the tester of the tester of the tester :P |
| 13:32:22 | Araq_win | yeah well |
| 13:32:37 | Araq_win | better output of the test results would have helped too |
| 13:32:50 | Araq_win | like absolute numbers instead of % |
| 13:32:54 | apriori_ | yeah |
| 13:33:20 | apriori_ | bwt, Araq_win, out of curiosity.. may I ask where you work at? |
| 13:33:36 | Araq_win | nah, it's a secret |
| 13:33:41 | apriori_ | ok :) |
| 13:42:38 | Araq_win | but yeah given the amount of features and their interactions, we have not nearly enough tests |
| 13:43:15 | Araq_win | in fact, I only need to look at the compiler's source code to construct an example program that triggers some bug |
| 13:44:07 | Araq_win | but *shrug* we can't do better with the resources we got |
| 13:44:23 | apriori_ | yeah, that's always the problem |
| 13:44:52 | apriori_ | not nearly enough people work on the compiler itself |
| 13:46:52 | Araq_win | true but constantly changing specs don't help ;-) |
| 13:48:42 | apriori_ | yup, indeed |
| 14:04:41 | dom96 | zahary: I hear you use Mac OS X. One of my friends tried running https://github.com/dom96/multipaint but got an abnormal termination, any chance you could investigate? |
| 14:08:15 | apriori_ | Araq_win, btw, wouldn it be better if you linearize history using rebase in the nimrod repo, master? |
| 14:08:57 | Araq_win | I don't care ;-) |
| 14:09:00 | apriori_ | :P |
| 14:09:29 | apriori_ | well, I think, I gonna write a git bisect script now... |
| 14:09:45 | apriori_ | since I dont know what change caused my code to no longer compile |
| 14:10:08 | apriori_ | some changes with templates, proc = templateInvocation.. the template doesnt see the variable result anymore |
| 14:11:20 | Araq_win | hrm, try {.immediate, dirty.} for the template |
| 14:11:25 | apriori_ | I did |
| 14:11:41 | apriori_ | hrm |
| 14:12:11 | apriori_ | well, anyway.. not wanting to waste your time, Araq_win, I gonne find the commit that caused it |
| 14:12:26 | Araq_win | alright thanks |
| 14:13:22 | Araq_win | brb |
| 14:20:07 | dom96 | hrm. |
| 14:20:22 | dom96 | Araq_win: re.`=~` is broken |
| 14:20:48 | dom96 | or is it hrm |
| 14:24:54 | dom96 | it seems that 'definedInScope(matches)' returns true if there is a field by the name of 'matches' |
| 14:26:35 | * | Araq_win is now known as Araq |
| 14:27:40 | Araq | hrm, is easy to fix |
| 14:28:06 | dom96 | good |
| 14:29:45 | Araq | well ugh, not really |
| 14:29:54 | dom96 | lol |
| 14:31:59 | Araq | hrm it should work already |
| 14:32:05 | * | zahary quit (Quit: Leaving.) |
| 14:32:30 | * | zahary joined #nimrod |
| 14:33:55 | Araq | dom96: pegs module has the same =~ and it works |
| 14:34:17 | dom96 | Maybe I'm doing something silly then? |
| 14:34:40 | Araq | what are you compiling? |
| 14:34:44 | dom96 | jester |
| 14:34:59 | Araq | file, line? |
| 14:35:41 | dom96 | jester.nim 232 |
| 14:37:21 | zahary | dom96, I tried running multipaint and it fails on the very first newScreenSurface call. my SDL is 1.2.15 |
| 14:37:29 | dom96 | zahary: yeah |
| 14:37:44 | dom96 | zahary: That's exactly what happened for my friend. |
| 14:39:48 | dom96 | Any ideas why it happens? |
| 14:41:22 | zahary | not really. I tried running a SDL sample and it seems to work (there was some visual glitches, but I guess that's another problem) |
| 14:42:11 | Araq | dom96: lookup rules within generics got stricter |
| 14:42:15 | zahary | well, there is SDL_Init in the sample |
| 14:42:22 | zahary | why are you skipping this? |
| 14:42:44 | Araq | and =~ is not invoked in the generic, so it claims 'matches' is not declared |
| 14:43:08 | dom96 | zahary: I use 'init(INIT_EVERYTHING)' |
| 14:44:02 | dom96 | zahary: Is that the problem? |
| 14:44:06 | zahary | aha, my bad - missed that |
| 14:45:09 | dom96 | Araq: ok. So... can you fix it? |
| 14:45:26 | Araq | well I'm not sure how |
| 14:45:55 | Araq | you found another design problem with my new stricter lookup rules in generics ... |
| 14:47:00 | Araq | maybe I should make the error a warning ... |
| 14:47:19 | Araq | but then you have no means to shut it up |
| 14:47:35 | Araq | the planned 'mixin' feature will fix it |
| 14:47:49 | Araq | but that's been delayed until 0.9.0 is finally out |
| 14:48:52 | Araq | you can hack around it though: |
| 14:49:13 | Araq | template setMatches(req: expr) = req.matches = matches |
| 14:49:20 | Araq | setMatches(req) |
| 14:51:57 | dom96 | alright |
| 14:56:12 | apriori_ | Araq: am I right assuming that the bootstrapping part, using build.sh never changes? |
| 14:56:17 | apriori_ | only the koch rebuild phase? |
| 15:03:18 | Araq | it does change |
| 15:03:39 | Araq | for instance if the compiler gets another module then build.sh will reflect that |
| 15:04:03 | apriori_ | ok |
| 15:06:00 | Araq | btw dom96, your global 'j' variable is really evil :P |
| 15:06:17 | dom96 | I know. |
| 15:06:22 | Araq | should have named it 'gj' at least |
| 15:06:30 | dom96 | really? |
| 15:06:36 | dom96 | Why? |
| 15:07:18 | Araq | because loop vars are often named 'j' |
| 15:07:42 | Araq | and a 'g' prefix for a global var is common in nimrod |
| 15:08:06 | dom96 | Well it's not exported so it should be fine, no? |
| 15:08:21 | Araq | yeah |
| 15:08:58 | Araq | except that your templates bind it and so clients might see it due to compiler bugs :P |
| 15:09:21 | Araq | well I don't think the compiler has such a bug |
| 15:10:29 | dom96 | lol |
| 15:23:33 | * | zahary1 joined #nimrod |
| 15:24:46 | * | zahary quit (Read error: Operation timed out) |
| 15:40:31 | * | Trixar_za is now known as Trix[a]r_za |
| 15:43:25 | * | Trix[a]r_za is now known as Trixar_za |
| 15:58:36 | fowl | dom96: how do i run this |
| 15:58:45 | dom96 | fowl: multipaint? |
| 15:58:46 | fowl | it looks like its half ruby half nimrod |
| 15:58:59 | fowl | yea |
| 15:59:04 | dom96 | My friend made the server so I'm not sure how to run that :P |
| 15:59:23 | dom96 | but hrm, maybe he has a server still running |
| 15:59:25 | * | dom96 asks |
| 16:01:42 | dom96 | fowl: ./multipaint gewt.net |
| 16:06:33 | Araq | I have to go, see you later |
| 16:09:39 | dom96 | fowl: Well? :P |
| 16:14:31 | apriori_ | hrm, how could rev 056a16547d1d50c65c052ff5c2b6facd86531f50 possibly break templates? |
| 16:17:51 | apriori_ | http://pastebin.com/T4eDLnGx |
| 16:30:16 | apriori_ | yay.. git bisect fooled me ;) |
| 16:41:08 | * | shevy quit (Read error: Operation timed out) |
| 16:48:44 | fowl | sorry |
| 16:49:17 | fowl | missing a font |
| 16:49:42 | apriori_ | grr.. |
| 16:49:46 | apriori_ | I'm stupid :/ |
| 16:50:03 | apriori_ | wonder why a template doesnt find a result variable, if its supposed to implement the body of a void function |
| 16:51:06 | * | Araq is now known as Araq_win |
| 16:51:12 | dom96 | fowl: It's hard coded in the source code |
| 16:51:20 | dom96 | fowl: Change it, or move any font to that path. |
| 16:52:06 | Araq_win | lol, apriori |
| 16:52:19 | Araq_win | apriori_: a void function has no 'result' :D |
| 16:52:49 | Araq_win | is that the only "bug" you encountered? |
| 16:53:05 | apriori_ | Araq_win: not quite, one moment, still investigating |
| 16:53:13 | Araq_win | hrm I only have a 64bit gcc installed |
| 16:53:21 | Araq_win | I guess that's the reason it crashes ... |
| 16:53:41 | fowl | Error: unhandled exception: invalid float: 1.3484191968232739e+09 |
| 16:53:54 | dom96 | fowl: You need the latest from git |
| 16:54:25 | fowl | o |
| 16:55:16 | Araq_win | ugh providing binaries for windows sucks |
| 16:56:28 | * | shevy joined #nimrod |
| 16:57:35 | apriori_ | Araq_win: then try providing non-static binaries for linux distros :) |
| 16:57:58 | fowl | my lag is pretty bad |
| 16:58:03 | fowl | this is cool though |
| 16:58:04 | dom96 | yeah |
| 16:58:13 | dom96 | That's because my friend is erasing a lot... |
| 16:58:20 | dom96 | Also it's pretty inefficient :P |
| 16:58:26 | Araq_win | apriori_: that's why I'm not even trying ;-) |
| 16:58:33 | apriori_ | hehe, yeah |
| 16:59:05 | dom96 | fowl: Try now |
| 17:00:23 | Araq_win | fowl: which GCC did you use on windows? |
| 17:01:01 | fowl | i think the one that comes with mingw is 32bit |
| 17:01:05 | * | Trixar_za is now known as Trix[a]r_za |
| 17:01:28 | Araq_win | I got a 64bit one for testing but want to ship a 32bit build |
| 17:03:03 | apriori_ | Araq_win: template error messages need some improvement |
| 17:03:12 | apriori_ | like, what actual invocation triggered it |
| 17:03:24 | Araq_win | "instantiation from here" |
| 17:03:29 | fowl | dom96: why do you create a huge string each loop var line: string = newString(65536) o_O |
| 17:03:38 | apriori_ | Araq_win: apparently not available in the rev I'm on |
| 17:03:53 | Araq_win | apriori_: nope, it's been there since forever |
| 17:04:03 | apriori_ | then its not working in that case or what not |
| 17:04:09 | dom96 | fowl: Dunno. |
| 17:04:12 | Araq_win | then it's in the same line ;-) |
| 17:04:14 | dom96 | Wrote this a long time ago. |
| 17:04:48 | apriori_ | oh hell no.. |
| 17:04:50 | apriori_ | not again.. |
| 17:05:05 | dom96 | fowl: I'm sure there is a lot of room for optimization. |
| 17:05:18 | dom96 | Especially with the server. |
| 17:05:26 | dom96 | And UDP isn't really good for this. |
| 17:05:31 | apriori_ | Araq_win: funny enough.. later revs picked up an obvious error which earlier didnt |
| 17:05:43 | apriori_ | yet another case of that stupid "void function + result body template" |
| 17:06:01 | Araq_win | well yes when I change something I try to improve the situation ;-) |
| 17:06:12 | apriori_ | hehe |
| 17:06:18 | Araq_win | btw you can now do: |
| 17:06:27 | Araq_win | proc p: int = 23 + 45 |
| 17:06:34 | Araq_win | no 'result = ' needed anymore |
| 17:06:43 | apriori_ | unfortunately git bisect had serious problems with the non-linear history |
| 17:07:13 | apriori_ | so my bisect script even fooled me into believing, any commit after the last merge commit was the root cause |
| 17:07:17 | Araq_win | I don't really care but I noticed that git's there are 2 ways to handle history is insane ... |
| 17:08:05 | apriori_ | I even dont quite get it.. |
| 17:08:16 | Araq_win | especially since it seems to use the wrong default |
| 17:08:27 | Araq_win | but then I didn't want to change the deafult |
| 17:08:35 | apriori_ | yes, it does save your whole "decision" graph, you could say.... but only 1 way actually matters when traversing from a start to an end version |
| 17:08:45 | apriori_ | so why isn't git bisect able to enumerate these versions? |
| 17:09:07 | fowl | git is the most unusable 'software' i've ever encountered |
| 17:09:17 | apriori_ | fowl: not really |
| 17:09:20 | Araq_win | I'm at constant war with version control ... |
| 17:09:20 | apriori_ | its just a bit hard |
| 17:09:28 | apriori_ | and svn is way too limited |
| 17:09:40 | fowl | in the future all my projects will be on mercurial |
| 17:09:41 | Araq_win | doesn't matter if svn, git or launchpad's |
| 17:10:07 | Araq_win | whatever launchpad's name was |
| 17:10:29 | Araq_win | the python thingie with incredibly versbose and yet not very helpful docs ;-) |
| 17:10:30 | apriori_ | Araq_win: one question btw.. do we _really_ need forward declarations? |
| 17:10:44 | dom96 | Araq_win: Bazaar :P |
| 17:10:48 | apriori_ | I ask because, well.. its somehow ancient, although I get it does improve performance |
| 17:11:02 | Araq_win | we really need it for templates and macros |
| 17:11:10 | apriori_ | but for procs? |
| 17:11:11 | Araq_win | but not for procs, so I'll support that |
| 17:11:19 | apriori_ | ok |
| 17:11:19 | Araq_win | but it'll be quite some work |
| 17:11:25 | Araq_win | and there are edge cases like: |
| 17:11:26 | apriori_ | ok, low priority then |
| 17:11:35 | Araq_win | proc p(x: type(q)) |
| 17:11:40 | Araq_win | proc q(x: type(p)) |
| 17:11:49 | Araq_win | :P |
| 17:12:12 | apriori_ | yeah |
| 17:13:05 | Araq_win | and the resulting grouping of procs ain't bad for the caches ;-) |
| 17:13:25 | Araq_win | but ultimately a good optimizer should do that |
| 17:14:33 | Araq_win | does the windows installer really include mingw GCC? |
| 17:18:46 | apriori_ | do we have a pow operator? |
| 17:19:06 | Araq_win | there is math.pow and ^ has been reserved for it |
| 17:19:10 | apriori_ | ok |
| 17:19:32 | apriori_ | that's also a good case for simple tr macro, btw. |
| 17:20:11 | apriori_ | one could simply unroll the pow for ints..that can dramatically improve performance |
| 17:20:24 | apriori_ | if exponent is int, I mean |
| 17:20:39 | Araq_win | maybe but often the same can be accomplished with overloading based on ASTs |
| 17:20:50 | Araq_win | once that is implemented, of course |
| 17:21:01 | apriori_ | okay ;) |
| 17:21:23 | apriori_ | I guess that overloading will be faster than the "optimize everything searching for matches via tr macros" |
| 17:21:39 | Araq_win | that's the plan, yeah |
| 17:21:53 | Araq_win | I'll rewrite the overloading resolution to support AST matching |
| 17:22:06 | apriori_ | wow ;) |
| 17:22:07 | Araq_win | and all the other features like overloading of 'var T' |
| 17:23:13 | apriori_ | yeah |
| 17:33:44 | Araq_win | I decided that as long as mingw is such an annoying install, I'll ship it with nimrod |
| 17:33:54 | apriori_ | indeed, it is |
| 17:34:53 | apriori_ | btw, for tr macros I'd like to have {.changesSemantics.} flag.. so those can't be deactivated via flag |
| 17:35:34 | Araq_win | -.- |
| 17:35:37 | apriori_ | :P |
| 17:35:38 | Araq_win | we'll see about that |
| 17:35:55 | Araq_win | optimizations are always hard to get right ... :P |
| 17:36:01 | apriori_ | yes, sure.. |
| 17:36:09 | apriori_ | but I think there is a distinction needed |
| 17:36:36 | Araq_win | use overloading based on ASTs for changing semantics |
| 17:36:46 | apriori_ | those which only optimaze dont change semantics.. and should be deactivatable (e.g. because every optimisation makes some assumption, e.g. about hardware) |
| 17:37:05 | apriori_ | well, yeah.. later ;) |
| 17:38:12 | Araq_win | well I don't think TR macros are stable already either |
| 17:38:22 | Araq_win | so "later" may apply to them too |
| 17:38:52 | Araq_win | doesn't matter though, I'll spam reddit with Nimrod's awesome TR macro features |
| 17:38:58 | apriori_ | :P |
| 17:39:11 | Araq_win | after all, that's what D does too ... :P |
| 17:39:15 | apriori_ | do that.. you deserve respect for that |
| 17:39:32 | apriori_ | damn |
| 17:39:37 | apriori_ | didnt file the bug I found in them yet :P |
| 17:41:45 | Araq_win | spamming reddit about half implemented feature which mostly works by wishful thinking |
| 17:43:11 | apriori_ | well, I can't overly blame them... |
| 17:43:19 | Araq_win | I call it "D-like marketing" :P |
| 17:43:27 | apriori_ | unfortunately you need some hype to be successful with a new language |
| 17:44:02 | apriori_ | Araq_win: http://pastebin.com/KjjBbNQK |
| 17:44:03 | fowl | i think it would be more effective to list nimrod on those wikipedia pages where different languages are compared/listed by feature |
| 17:44:06 | apriori_ | anything wrong with that? |
| 17:44:29 | fowl | nobody thinks of reddit as a respectable source for programming news anyways |
| 17:44:50 | apriori_ | it should rewrite, shouldn't it? |
| 17:45:44 | Araq_win | yep |
| 17:45:55 | Araq_win | strange bug |
| 17:46:14 | apriori_ | k, ignore.. i Just file it |
| 17:46:20 | apriori_ | so it wont get lost |
| 17:46:20 | Araq_win | thanks |
| 17:46:36 | Araq_win | but hrm |
| 17:46:46 | Araq_win | I think 'int' can never alias 'int' ... :P |
| 17:47:01 | Araq_win | the analysis is type based, so hrm |
| 17:47:36 | Araq_win | it's pushed by copy on the stack after all |
| 17:48:06 | apriori_ | Araq_win: some when using expr instead of int in the macro |
| 17:49:04 | apriori_ | *same |
| 17:49:17 | apriori_ | but as said.. sry to bother you.. ignore it ;) |
| 17:49:28 | apriori_ | if its invalid, one can close it later |
| 17:49:36 | Araq_win | it doesn't matter if it's "expr" in the template or "int" |
| 17:49:45 | Araq_win | testVar is of type 'int' ... |
| 17:49:52 | apriori_ | yeah, I know |
| 17:50:10 | apriori_ | but how is aliasing defined here then? |
| 17:50:31 | Araq_win | and before you ask, it'll likely do the same for "string" as I wrote the analysis with a very narrow use case in mind |
| 17:51:04 | Araq_win | which however does what you really need, I hope |
| 17:51:14 | Araq_win | and yeah it needs to be specified properly |
| 17:51:28 | apriori_ | okay |
| 18:13:42 | * | XAMPP joined #nimrod |
| 18:22:43 | Araq_win | hrm mingw is 70MB now ... |
| 18:25:46 | Araq_win | gcc: error: CreateProcess: No such file or directory |
| 18:25:49 | Araq_win | -.- |
| 18:34:21 | * | Araq_win wonders how much work it would be to merge minw's installer with nimrod's |
| 19:11:32 | apriori_ | any reason why that shouldnt work?: http://pastebin.com/C7pcadSm |
| 19:11:40 | apriori_ | I mean only the case, nothing else |
| 19:13:59 | * | Araq_win is now known as Araq |
| 19:14:43 | Araq | yes, the compiler is correct |
| 19:14:49 | apriori_ | ah |
| 19:15:02 | Araq | within a macro's body 'i' has the type PNimNode |
| 19:15:06 | apriori_ | well, it wasnt obvious to me, that in the macro i is a pnimnode |
| 19:15:16 | apriori_ | yeah, so I guess using intVal is the way |
| 19:15:30 | Araq | yeah and I guess the docs do not mention it |
| 19:15:34 | Araq | it's rather new ... |
| 19:15:42 | apriori_ | no problem |
| 19:16:36 | apriori_ | same goes for expr etc.. I wondere how to convert those to PNimnode.. but they already are of that type :) |
| 19:16:38 | apriori_ | *wondered |
| 19:18:14 | fowl | o cool you did the docgen thing |
| 19:18:23 | fowl | thanks Araq |
| 19:19:16 | Araq | np, was easy ;-) |
| 19:33:49 | apriori_ | and yet another issue :(: http://pastebin.com/ET9X8ZNb |
| 19:33:58 | apriori_ | why should "intVal" be a field? |
| 19:39:09 | Araq | that's not the problem |
| 19:39:19 | Araq | the problem is that 'times' is not a literal |
| 19:39:24 | apriori_ | yeah |
| 19:40:03 | Araq | well it used to internalError or crash, so it's an improvement :P |
| 19:41:04 | apriori_ | so how could I get the value behind that symbol? |
| 19:41:39 | Araq | dunno I guess the API is missing |
| 19:42:23 | Araq | but your example can't work |
| 19:42:47 | Araq | 'exponent' has no literal that could be looked up |
| 19:42:58 | apriori_ | so only literals are allowed? |
| 19:43:03 | Araq | yes |
| 19:43:05 | apriori_ | ok, then I definetly need tr macros |
| 19:43:08 | Araq | yes |
| 19:43:16 | apriori_ | okay then |
| 19:43:43 | apriori_ | hrm |
| 19:44:06 | apriori_ | question is.. whether a tr macro would be able to catch non-literal, compile-time constant vars.. |
| 19:44:18 | apriori_ | well. I gonna see how far I get .. |
| 19:44:37 | Araq | apriori_: yes it should |
| 19:44:45 | Araq | I implemented that |
| 19:44:48 | apriori_ | k |
| 19:44:55 | apriori_ | then let me stress test that ;) |
| 19:45:08 | Araq | btw store these tests somewhere |
| 19:45:17 | apriori_ | yeah, I will |
| 19:45:22 | Araq | I'd like to add them to the test suite |
| 19:45:28 | apriori_ | yeah, why not |
| 20:06:42 | dom96 | huh, that's weird. |
| 20:06:50 | dom96 | Why is Github behind? |
| 20:07:09 | Araq | I only did 'push --tags' |
| 20:07:34 | Araq | maybe I need to do 'push master origin' for github? |
| 20:08:02 | Araq | remind me to make a backup of the website the next time btw |
| 20:08:15 | Araq | I'm updating without any backups ... |
| 20:09:10 | dom96 | Araq: Yeah, do push master origin too |
| 20:10:01 | dom96 | lol. |
| 20:10:16 | dom96 | That's a bug in NimBot ;) |
| 20:10:30 | Araq | nah it's a feature |
| 20:11:10 | Araq | so does nimbuild compile again? |
| 20:12:14 | dom96 | ...no |
| 20:12:35 | dom96 | sorry |
| 20:12:39 | dom96 | I don't have time. |
| 20:12:43 | Araq | np |
| 20:13:18 | Araq | we need the tester to test jester and nimbuild and all the other stuff that's out there |
| 20:13:46 | Araq | it should have a list of URLs to checkout and try to compile |
| 20:14:36 | dom96 | If only github fixed linguist we could just pull out a list of Nimrod repos on github and voila. |
| 20:19:57 | apriori_ | Araq: and more bugs with tr macro :).. compiler rejecting some keywords as constraints |
| 20:20:01 | apriori_ | e.g. const or proc |
| 20:20:11 | Araq | use `proc` |
| 20:20:20 | Araq | no bug :P |
| 20:20:33 | apriori_ | ok, what about const? |
| 20:20:41 | Araq | `const`? |
| 20:20:46 | apriori_ | invalid expression |
| 20:20:54 | apriori_ | oh well |
| 20:20:56 | apriori_ | wait sec |
| 20:22:28 | Araq | brb have to build and upload the windows installer |
| 20:22:40 | apriori_ | k |
| 20:22:45 | Araq | somebody please test the .zip |
| 20:22:48 | apriori_ | good luck :P |
| 20:23:16 | * | dom96 should create a AUR package for 0.9.0 ;) |
| 20:23:28 | apriori_ | that shouldnt take long |
| 20:23:34 | dom96 | yeah |
| 20:37:30 | * | Araq is now known as Araq_win |
| 20:38:03 | Araq_win | so anybody please tell me the damn .zip still works |
| 20:39:02 | * | dom96 will test it for you now |
| 20:39:22 | Araq_win | and fix it if it doesn't because its your fault anyway :P |
| 20:39:37 | dom96 | huh? |
| 20:39:38 | * | Araq_win never touches niminst anymore |
| 20:39:51 | Araq_win | posix shell scripts are fragile |
| 20:39:56 | dom96 | I see :P |
| 20:44:19 | apriori_ | what limitations do tr macros have? because doesn't seem to allow returning anything (via return) |
| 20:46:00 | dom96 | Araq_win: It works. |
| 20:49:39 | * | Araq_win is now known as Araq |
| 20:50:11 | Araq | yay :D |
| 20:50:13 | Araq | uploading the windows installer |
| 20:50:46 | Araq | and you set the topic already |
| 20:50:50 | Araq | excellent |
| 20:51:08 | dom96 | :) |
| 20:55:28 | Araq | and done |
| 21:02:24 | dom96 | Soooo many changes :) |
| 21:02:33 | Araq | I made a summary :P |
| 21:12:18 | apriori_ | asking again.. tr macros dont allow the "return" statement? |
| 21:12:46 | apriori_ | I need that of course to tests for a more detailed constraint and emit an expr depending on that |
| 21:12:52 | Araq | they do, but matching against it is tricky |
| 21:13:02 | Araq | better match against 'result = expr' |
| 21:13:05 | apriori_ | nhah, I meant something like this: |
| 21:13:54 | apriori_ | http://pastebin.com/BW8cuj5V |
| 21:16:13 | Araq | you can't 'return 0' here |
| 21:16:26 | Araq | you need to construct an int literal with a 0 |
| 21:17:31 | apriori_ | and what about line 28, with the error? |
| 21:17:42 | Araq | the compiler is correct |
| 21:17:55 | apriori_ | I dont always the compiler isnt correct ;) |
| 21:17:58 | apriori_ | it just shows I don |
| 21:18:09 | apriori_ | I don't get how tr macros are supposed to work there |
| 21:18:17 | apriori_ | examples only include "direct" rewrites.. |
| 21:18:39 | Araq | well if you need procedural rewriting, use a macro, not a template |
| 21:19:01 | Araq | problem is that the template needs to produce an 'expr' |
| 21:19:10 | apriori_ | when using that I had "could not evaluate" or something |
| 21:19:16 | apriori_ | wait a sec |
| 21:19:24 | Araq | no need |
| 21:19:30 | Araq | you can't evaluate 'cast' |
| 21:19:42 | Araq | use 'toInt(ceiled)' instead |
| 21:19:44 | apriori_ | actually it only complained about `*` |
| 21:19:45 | apriori_ | ok |
| 21:20:19 | Araq | b: expr{lit|`const`} # --> expr{lit} should do |
| 21:20:25 | apriori_ | http://pastebin.com/j9yG3GYb |
| 21:20:27 | zahary1 | apriori_, I don't why keeps forgetting to mention it, but you can get the equivalent of int{const} by using expr{int} with the current compiler |
| 21:20:57 | apriori_ | ah, ok |
| 21:21:00 | Araq | not in a TR macro |
| 21:21:02 | zahary1 | it's likely to become int{lit} in the future |
| 21:21:20 | Araq | expr{int} means something different in a TR macro ... |
| 21:21:45 | Araq | er |
| 21:21:46 | apriori_ | any expression that is an int.. no limitation on const or something |
| 21:21:49 | apriori_ | or isnt it? |
| 21:22:06 | Araq | zahary1 could be right |
| 21:22:18 | Araq | well expr{int} makes no sense really |
| 21:22:23 | apriori_ | Araq: my attempt with lit|`const` was.. literal vs. only const variable |
| 21:22:25 | Araq | it's the same as 'int' |
| 21:22:44 | Araq | apriori_: I know but 'lit' supports named constants |
| 21:22:48 | apriori_ | ok |
| 21:23:22 | apriori_ | return getAst(unfoldExprOperator(a, `*`, bInt))whats wrong now about: |
| 21:23:29 | apriori_ | never really used getAst.. so there for sure is something wrong |
| 21:23:34 | zahary1 | personally, I find static the least confusing variant. int{static} |
| 21:24:12 | Araq | but 'static' means enforced CTE |
| 21:24:31 | Araq | there is a subtle difference between 'const' and 'static' ... |
| 21:24:40 | zahary1 | wouldn |
| 21:25:05 | zahary1 | woudn't int{lit} try to evaluate implicitly? (line expr{int} now) |
| 21:25:08 | zahary1 | like * |
| 21:25:42 | Araq | yeah but you can have: |
| 21:26:01 | Araq | (echo "x"; 13) |
| 21:26:16 | Araq | expr{static} --> executes 'echo' at compile time |
| 21:26:24 | Araq | expr{lit} --> shouldn't match |
| 21:26:52 | Araq | it's not implemented properly yet however |
| 21:27:16 | Araq | on the other hand, I don't know if we really need it |
| 21:28:07 | zahary1 | aha, if there are 3-levels (side effects, implicit CTFE, literals), then maybe const is the most appropriate for middle one |
| 21:30:22 | * | zahary1 is now known as zahary |
| 21:30:49 | Araq | I like 'lit' ;-) |
| 21:31:39 | apriori_ | I think there would others also confusing lit with literal only :) |
| 21:31:47 | apriori_ | but well. if it gets documented, its just fine |
| 21:32:09 | apriori_ | actually.. given the tiny pitfalls I ran in, I could also just improve the docs on that. |
| 21:32:52 | Araq | hell ya |
| 21:35:18 | Araq | I don't think there is something confusing about it |
| 21:35:33 | * | Trix[a]r_za is now known as Trixar_za |
| 21:35:40 | Araq | it's growing into a DWIM (do what I mean) feature |
| 21:35:56 | zahary | btw, is there a TR constraint that requires analysis that's performed after DirectOp? why aren't we adding the same support in sigmatch already? |
| 21:36:35 | Araq | because I wanted to get 0.9.0 out finally? |
| 21:36:58 | Araq | and I want to do it properly |
| 21:37:03 | Araq | and rewrite sigmatch |
| 21:37:57 | zahary | I want to change the way overloads are scored, but what's else is there to rewrite? |
| 21:38:10 | Araq | semOpAux needs to become lazy |
| 21:38:36 | Araq | and I want the code to do: * construct the list of overloads |
| 21:38:48 | Araq | * match all possible procs in parallel |
| 21:39:03 | Araq | * perform a better check for ambiguous calls |
| 21:39:17 | Araq | C++-like where the most specific overload gets chosen |
| 21:39:56 | Araq | "in parallel" does not mean threading here |
| 21:40:09 | zahary | I see, don't forget about the return type overloading btw - it's interleaved with the mechanics there |
| 21:40:50 | Araq | hrm |
| 21:40:59 | Araq | alright |
| 21:41:12 | Araq | plus the 'auto' return type I guess |
| 21:41:23 | zahary | yep |
| 21:41:37 | Araq | and it will do less copyTree calls ;-) |
| 21:43:08 | zahary | let me tell you what I want to change about the scoring - I want to add a set of matched type classes (or more generally "perks/traits"). if the set of some candidate is strictly a superset of some other, it gets picked |
| 21:43:25 | Araq | C++ style? |
| 21:43:43 | Araq | er, you mean subset, right? |
| 21:44:10 | zahary | you pick the superset - the one that have everything like the other plus something else |
| 21:44:37 | Araq | but seq[seq[T]] matches better than seq[T] for seq[seq[T]] |
| 21:45:22 | Araq | anyway, feel free to implement the new sigmatch, but before that we need branch support for nimbuild |
| 21:45:35 | Araq | I will work on the effects system instead then |
| 21:46:18 | zahary | yes, there are some transform that are applied to generic signatures: |
| 21:46:19 | zahary | proc [T](seq[seq[T]]) becomes proc (T: seq and T.Item == seq and T.Item.Item == T) - so you get 3 "perks" here |
| 21:47:27 | Araq | oh and we'd like auto deref for ptr/ref |
| 21:47:37 | Araq | and proxy support |
| 21:47:55 | Araq | will be a hell of a patch :D |
| 21:48:24 | Araq | dom96: can you hear us? we NEED branch support for nimbuild! |
| 21:49:21 | dom96 | Araq: Sure, tell my teachers to stop giving me so much homework and I will have it done. :P |
| 21:49:47 | Araq | well I will help you getting nimbuild to compile |
| 21:53:59 | apriori_ | Araq: well, it seems the macro doesn't like ceil.. |
| 21:54:08 | apriori_ | I guess because its not marked as having no side effects |
| 21:54:22 | Araq | it's imported from math.h I guess |
| 21:54:45 | Araq | it can't evaluate an importc |
| 21:54:51 | Araq | unfortunately |
| 21:54:55 | apriori_ | yeah, ok |
| 21:55:59 | apriori_ | yeah, anyway.. that's definetly not the most important task right now |
| 21:56:05 | apriori_ | continuing with matrices/vectors |
| 21:56:28 | apriori_ | in which I still dont know.. whether I should allow strange indices for their components |
| 21:58:25 | Araq | the current compiler doesn't really give you a choice, does it? |
| 21:58:38 | apriori_ | yup, it doesn't.. |
| 21:59:07 | apriori_ | currently I transform the index range of a dim to [0..n-1] and use that as a offset into the respective index type |
| 21:59:39 | Araq | sounds good to me |
| 22:00:51 | Trixar_za | Wait |
| 22:00:57 | Trixar_za | You released 0.9.0? |
| 22:01:15 | * | dom96 nods |
| 22:01:36 | Trixar_za | Interesting timing |
| 22:01:36 | Trixar_za | :P |
| 22:01:50 | dom96 | oh? |
| 22:02:35 | Trixar_za | Yeah, I've stopped slacking off on my dev status on SliTaz |
| 22:02:56 | Trixar_za | I was just about to write a build receipt to add nimrod :P |
| 22:03:06 | Trixar_za | So the timing couldn't have been better |
| 22:03:11 | dom96 | :D |
| 22:14:05 | dom96 | https://aur.archlinux.org/packages.php?ID=26701 :) |
| 22:16:56 | Araq | cool |
| 22:17:20 | fowl | reading a book on vm design |
| 22:18:16 | fowl | going to write a programming language where the instructions are input by drawing snow-capped mountains |
| 22:20:58 | Araq | good night everyone |
| 22:21:00 | fowl | also the bytecode will be represented as paralogical metaphors |
| 22:21:08 | apriori_ | bye |
| 22:21:09 | fowl | night |
| 22:21:49 | dom96 | I'm going to sleep too. bye. |
| 22:22:35 | apriori_ | same here.. |
| 22:22:37 | apriori_ | its about time |
| 22:22:39 | apriori_ | bye |
| 22:22:48 | * | apriori_ quit (Quit: Konversation terminated!) |
| 22:30:30 | * | q66 quit (Quit: Quit) |
| 23:18:03 | Trixar_za | Well, nimrod is added. Let's hope it's compiles on the build server |
| 23:18:04 | Trixar_za | :P |
| 23:32:00 | * | XAMPP quit (Quit: Leaving) |
| 23:48:05 | * | XAMPP joined #nimrod |