<< 28-05-2014 >>
00:05:28*freezerburnv joined #nimrod
00:13:16flaviu1Coq takes forever to compile
00:15:35*DAddYE quit (Remote host closed the connection)
00:18:10*DAddYE_ joined #nimrod
00:22:27*DAddYE_ quit (Ping timeout: 252 seconds)
00:26:40*Joe_knock is now known as Joe_knock_ITZ_
00:30:42OrionPKbleh
00:30:48OrionPKstatic keyword is taken, lame :P
00:34:17filwitreally?
00:34:27filwitany idea on it's planned use?
00:34:36flaviu1filwit: Its already in use
00:34:45filwitfor what?
00:34:45flaviu1Compile time execution IIRC
00:34:58filwithmmm.. anywhere in the docs? or can you give an example?
00:35:06filwiter... let me search the index...
00:35:54flaviu1I think I read that somewhere, I may have imagined it.
00:35:56filwiti see
00:36:05filwityeah it's right here: http://build.nimrod-lang.org/docs/manual.html#static-statement-expression
00:36:16filwitused to enforce compile-time execution
00:37:22filwitsometimes I think we could make better use of keywords and pragmas for these things... like `block {.static.}: ...` so `static` is no longer a keyword
00:37:22*flaviu1 quit (Read error: Connection reset by peer)
00:37:32filwitbut meh, that's just completely nit-picky
00:38:09*flaviu1 joined #nimrod
00:38:20filwitanyways, bbl
00:43:30OrionPKor just block(static): w/ macro syntax
00:48:30*q66 quit (Quit: Leaving)
01:11:58*hoverbear joined #nimrod
01:12:48*freezerburnv quit (Quit: freezerburnv)
01:14:53*saml_ joined #nimrod
01:17:49*brson quit (Quit: leaving)
01:18:05*saml_ quit (Client Quit)
01:18:53*DAddYE joined #nimrod
01:19:37*saml_ joined #nimrod
01:23:27*DAddYE quit (Ping timeout: 265 seconds)
02:04:30*Joe_knock_ITZ_ is now known as Joe_knock
02:12:20*Joe_knock quit (Quit: Leaving)
02:19:28*DAddYE joined #nimrod
02:24:21*DAddYE quit (Ping timeout: 265 seconds)
02:33:06*OrionPK quit (Remote host closed the connection)
02:37:47*filwit quit (Ping timeout: 245 seconds)
02:48:15*Demos joined #nimrod
02:51:00reactormonkBitPuffin, just load the nimrod-mode.el file, I haven't packaged it IIRC
02:51:40*perturbation quit (Quit: g'night all)
02:54:00*DAddYE joined #nimrod
02:59:41reactormonkAraq, anything inaccurate in https://github.com/Araq/Nimrod/pull/1228 ?
03:06:58*def- joined #nimrod
03:10:17*def-_ quit (Ping timeout: 252 seconds)
03:11:40*xtagon joined #nimrod
03:11:52*boydgreenfield quit (Quit: boydgreenfield)
03:18:50*OrionPK joined #nimrod
03:23:46*DAddYE quit (Remote host closed the connection)
03:24:12*DAddYE joined #nimrod
03:24:44*xenagi quit (Quit: Leaving)
03:28:35*DAddYE quit (Ping timeout: 258 seconds)
03:49:22*New-Guy joined #nimrod
03:49:56New-GuyWithin a macro, how does one give a proc a pragma?
03:50:43New-GuyI can't find it in the doc, but I figured proc_name.pragma = new_nim_node(nnk_pragma, ident("closure"))
03:52:56fowlthere should be a pragma= function, it will operate on the proc def, not the name
03:53:43New-Guyfowl: Didn't mean name.
03:54:11New-Guyfowl: But when on a proc def, that's right?
03:54:34fowlhttp://build.nimrod-lang.org/docs/macros.html#pragma=,PNimrodNode,PNimrodNode
03:55:12New-Guyval: PNimrodNode doesn't answer that really well.
03:55:25New-GuyNor does "set the pragma of a proc type"
03:55:47fowlthe documentation is wrong, it expects a routine type (proc def, lambda expr, do expr)
03:57:24New-GuyNo, I know the proc def part and everything, I'm asking the format of the pragma type. since pragma= takes another PNimrodNode as the value of the pragma to assign to the procedure.
03:57:54New-Guynew_nim_node(nnk_pragma, ident("closure") will assign the closure pragma to the procedure, right?
03:58:47*saml_ quit (Ping timeout: 252 seconds)
04:02:12fowlNew-Guy, maybe
04:02:29fowlNew-Guy, i always double check the ast with macros.dumptree before doing anything
04:11:59New-GuyWell it compiles, and looking at a dumpTree of a pragma it's Pragma Ident !"closure"
04:13:10New-GuyBut I wrote a small file to test this: http://pastebin.com/iE7PGfZX
04:14:01New-GuyBut when I compile it, it fails. Then parallelBuild:1 gives me the error shown at the bottom of that pastebin file.
04:15:37New-GuyIn the process of building the latest compiler and switching back from Clang to gcc
04:16:12New-GuyTell you how that goes.
04:18:01*bjz joined #nimrod
04:24:45*DAddYE joined #nimrod
04:26:28New-GuyNothing changed. TMP138 replaced TMP137 though.
04:29:06*DAddYE quit (Ping timeout: 258 seconds)
04:34:55fowlNew-Guy, you dont build the pragma right
04:35:10fowlNew-Guy, new_nim_node(nnk_pragma).add(ident("closure"))
04:35:15fowlthats not the problem though
04:36:33New-Guyfowl: That's the same as new_nim_node(nnk_pragma, ident("closure")) isn't it?
04:37:05fowlno
04:37:20New-Guyfowl: Ah, okay. And what do you think the problem is?
04:38:33fowloh i know what it is
04:39:18fowlNew-Guy, add nnkLambda as the last parameter to the new_proc call (for the proc type)
04:40:02New-GuyYeah, that did it!
04:40:47New-Guyfowl: Thanks!
04:40:55fowlit doesnt seem to be very forgiving for malformed ast :/
04:41:17New-Guyfowl: Yeah, it really doesn't.
04:41:18fowlNew-Guy, btw, to check what a node represents in syntax you can use repr(node)
04:41:35New-Guyfowl: Oh, okay. Thanks for the tip.
04:41:52fowli usually end my macros with when defined(debug): echo repr(result)
04:42:23New-Guyfowl: That's a good idea, I'm going to start doing that as well.
04:42:25New-Guyfowl: One more thing before I get back to workin' - what's the second parameter of new_nim_node()?
04:42:32New-GuyI thought it would be the children of the new node.
04:43:46fowldunno, ive never used it
04:44:14New-Guyfowl: Oh, okay. Well g'night, and thanks for the help!
04:44:19*New-Guy quit (Quit: Page closed)
04:44:20fowlthats a good question..hrm
04:51:14*xtagon quit (Read error: Connection reset by peer)
05:12:35*ehaliewicz quit (Ping timeout: 255 seconds)
05:28:12*flaviu1 quit (Ping timeout: 245 seconds)
05:43:18*DAddYE joined #nimrod
05:53:35*Demos quit (Read error: Connection reset by peer)
05:55:32*hoverbear quit ()
06:16:29*DAddYE quit (Remote host closed the connection)
06:16:56*DAddYE joined #nimrod
06:21:07*DAddYE quit (Ping timeout: 245 seconds)
07:27:36*DAddYE joined #nimrod
07:32:05*DAddYE quit (Ping timeout: 264 seconds)
08:05:15*ehaliewicz joined #nimrod
08:25:43*kunev joined #nimrod
08:47:23*Mat3 joined #nimrod
08:47:26Mat3hello
09:00:28*freezerburnv joined #nimrod
09:04:57*freezerburnv quit (Ping timeout: 252 seconds)
09:09:23*Mat3 quit (Quit: Verlassend)
09:37:24*wan quit (Quit: WeeChat 1.0-dev)
09:53:49*BitPuffin quit (Ping timeout: 252 seconds)
09:58:53*freezerburnv joined #nimrod
10:32:25Araqreactormonk: no, please pull it
10:36:21*ehaliewicz quit (Ping timeout: 252 seconds)
10:56:15*BitPuffin joined #nimrod
10:57:49BitPuffinreactormonk: okay I'll give it a go
11:07:00*dLog_ quit (Ping timeout: 258 seconds)
11:09:16*noam quit (Read error: Connection reset by peer)
11:10:57*noam joined #nimrod
11:13:47*dLog joined #nimrod
11:23:37*noam quit (Read error: Connection reset by peer)
11:32:51*noam joined #nimrod
11:45:00VarriountAraq: Pong
11:47:15AraqVarriount: well yesterday evening I was ready to teach you the compiler's internals
11:47:16Araqnow you have to wait ... dunno if I can do it today
11:48:22VarriountAraq: I'm not gonna be on until much later today, so if nothing else, tell me your plans
11:48:44VarriountMaybe on Saturday?
11:48:52Araqok
11:49:00Araqsaturday sounds good
12:14:30*untitaker quit (Ping timeout: 265 seconds)
12:15:26*freezerburnv quit (Quit: freezerburnv)
12:19:12*untitaker joined #nimrod
12:51:22*onibaka joined #nimrod
13:06:13*darkf quit (Quit: Leaving)
13:13:25*onibaka_ joined #nimrod
13:13:29*onibaka quit (Ping timeout: 264 seconds)
13:29:39*onibaka joined #nimrod
13:30:17*onibaka_ quit (Ping timeout: 264 seconds)
13:36:11*onibaka_ joined #nimrod
13:36:53*onibaka quit (Ping timeout: 264 seconds)
13:37:26*Puffin joined #nimrod
13:37:31*BitPuffin quit (Ping timeout: 240 seconds)
13:47:26*Mat3 joined #nimrod
13:47:34Mat3good afternoon
13:51:01Mat3I have a record 'tDictEl' and a function 'proc dictSearch (o: var tDictStack, n: string, e: var tDictEl) : bool'
13:52:11*freezerburnv joined #nimrod
13:52:15Mat3in this function, I can change elements of parameter 'o' but not elements of 'e' (and I do not know what is the problem)
13:56:39Mat3have someone an idea ?
14:16:39*onibaka_ quit (Quit: onibaka_)
14:37:33Mat3ok, found the problem
15:04:48*Mat3 quit (Quit: Verlassend)
15:09:09*bjz quit (Ping timeout: 252 seconds)
15:18:03*kunev quit (Quit: leaving)
16:11:06*hoverbear joined #nimrod
16:19:07*dymk quit (Ping timeout: 240 seconds)
16:22:29*vendethiel quit (Ping timeout: 264 seconds)
16:22:48*dymk joined #nimrod
16:22:56*vendethiel joined #nimrod
16:28:08*Puffin is now known as BitPuffin
16:43:06*q66 joined #nimrod
16:43:06*q66 quit (Changing host)
16:43:06*q66 joined #nimrod
16:43:35*onibaka joined #nimrod
16:44:53*onibaka_ joined #nimrod
16:48:17*onibaka quit (Ping timeout: 264 seconds)
16:54:34*Johz joined #nimrod
16:59:24*brson joined #nimrod
17:05:40*Demos joined #nimrod
17:05:56*Matthias247 joined #nimrod
17:12:52*onibaka_ quit (Quit: onibaka_)
17:14:42*Demos_ joined #nimrod
17:17:41*Demos quit (Ping timeout: 258 seconds)
17:19:07*Demos_ quit (Ping timeout: 240 seconds)
17:19:19*flaviu1 joined #nimrod
17:21:59*DAddYE joined #nimrod
17:26:14flaviu1Araq: I'm 99% sure thats right
17:26:20flaviu1http://i.imgur.com/fUJ98qp.png
17:30:42*Varriount|Mobile joined #nimrod
17:31:08Varriount|MobileMeep
17:34:31Varriount|Mobiledom96: Well is there any part of the typeToString procedure which is unclear?
17:35:43*gsingh93_ joined #nimrod
17:36:21*gsingh93_ quit (Client Quit)
17:36:33*gsingh93_ joined #nimrod
17:37:32*onibaka joined #nimrod
17:53:40*foodoo joined #nimrod
18:05:31*Varriount|Mobile quit (Ping timeout: 240 seconds)
18:18:17*nequitans_ joined #nimrod
18:20:59nequitans_Hi all, is there a quick answer to this error when trying to compile Nimrod: lib/system.nim(2721, 5) Error: implementation of 'system.rand(max: int): int' expected
18:25:34*Demos joined #nimrod
18:32:39flaviu1nequitans_: I don't know the solution to the problem, but what OS are you compiling on?
18:35:40nequitans_ubuntu 14.04
18:37:30Araqnequitans_: it means your system.nim is not compatbile with your compiler
18:37:30*flaviu1 quit (Read error: Connection reset by peer)
18:38:05Araqyou can remove that defintion in your system.nim to make it work
18:38:13Araqor reinstall things properly
18:39:24nequitans_i see thx. where's my system.nim or how would i reinstall properly then
18:39:40nequitans_the lib/ one?
18:40:18*flaviu1 joined #nimrod
18:42:19Araqnequitans_: the compiler outputs its search directories
18:58:51*Varriount|Mobile joined #nimrod
19:04:49*gsingh93_ quit ()
19:07:58*gsingh93_ joined #nimrod
19:07:59*Mat3 joined #nimrod
19:09:25Mat3hello
19:12:13*xtagon joined #nimrod
19:12:19*Demos quit (Ping timeout: 240 seconds)
19:13:03Araqhi
19:22:25nequitans_kk i removed the definition and it worked
19:22:53nequitans_tho i'm not sure how to make system.nim compatible with the compiler
19:25:27AraqI dunno how you installed it
19:26:24nequitans_ah, yea, i duplicated exactly the commands under the 'source' section on the download web page
19:32:17Mat3hi Araq and nequitans_
19:38:14*Varriount-Mobile joined #nimrod
19:41:55*Varriount|Mobile quit (Ping timeout: 240 seconds)
19:42:37nequitans_on an unrelated note, i've been using a combination of buffered io or memory mapping + the memchr function to get pretty large speedups over lines() when parsing lines of a file. was curious whether this would be a useful package/addition to nimrod/already exists. an example using memory mapping is here: https://gist.github.com/geetduggal/9d2e528c79a8a03f620f
19:47:11Araqnequitans_: your code is ugly :P
19:52:35Araqyou should check out the "lexbase" module which has some good buffer handling
19:54:01nequitans_ah, thanks
19:56:41nequitans_love how the docs link straight to the source
19:58:10*freezerburnv quit (Quit: freezerburnv)
19:58:43*onibaka left #nimrod (#nimrod)
19:59:42Araqnequitans_: int(ch) == 10 is better written as ch == '\L'
20:00:01Araqalso you use multiple 'yields' in an inline iterator
20:00:23Araqthat leads to code bloat
20:00:36Araq(I guess the compiler should warn about that)
20:00:50Araqyou can either use a .closure iterator which does not have this problem
20:01:13Araqor you modify your code slightly:
20:01:17flaviu1Can't the C compiler see and fix that?
20:01:31flaviu1I should actually do some tests on that
20:02:18Araqyield (floc, (if newLineLoc == 0: fend else: newLineLoc) - floc)
20:02:20nequitans_yea, i think i can get rid of the fact that there are two termination conditions
20:02:39Araqif newLineLoc == 0: break
20:03:04nequitans_ah, thanks
20:03:58Araqflaviu1: perhaps but I wouldn't count on it. it's not idiomatic C code to have lots of identical blocks
20:04:52Araqnequitans_: also using 'cstring' instead of 'ptr char' and all the casts is better style
20:06:06nequitans_thought you guys may get a kick out of the comments in this C file for memchr: http://www.opensource.apple.com/source/patch_cmds/patch_cmds-7/patch/memchr.c
20:06:11*io2 joined #nimrod
20:12:00Araqnequitans_: Ialready know the technique ;-)
20:12:16Araqusually it's implemented in assembler though
20:13:27flaviu1Wow, http://highlightjs.readthedocs.org/en/latest/language-guide.html is really nice to work with
20:13:49*nande_ joined #nimrod
20:15:14Araq"Highlight.js tries to automatically detect the language of a code fragment. "
20:15:39flaviu1Really impressive how easy it is to implement things like r" asdd "" "
20:17:02Araqmeh guessing a programming language doesn't really work
20:17:34flaviu1Yeah, but it just needs to guess a language close enough so that the highlighting is roughly correct
20:17:57flaviu1The user doesn't really care how its guessed if it looks right
20:20:43foodooBeginner programmers can get really confused when they think something is wrong when their editor highlights something incorrectly
20:22:13*nande_ quit (Remote host closed the connection)
20:22:23Araqthis is simply yet another issue "must not look at the file extension to determine anything" masked as a feature ("it guesses the programming language")
20:22:32Araq*unix issue
20:23:25Mat3*nix design is full of such 'nice' ideas
20:25:27Araqspeaking of which ... which Linux distribution do you recommend, flaviu1 ?
20:26:10AraqI need to reinstall my linux, so I might as well try out a new distro
20:27:07*foodoo likes ArchLinux
20:27:23*Mat3 likes NetBSD
20:27:39*Varriount likes Windows
20:27:49*xtagon likes sandwiches
20:28:36Mat3*lol*
20:28:37Varriountxtagon: Woah, you can run those on a computer?
20:28:56xtagonVarriount, if you have a big enough case, you can make them on a computer
20:29:00foodooI guess with Nimrod everything is possible
20:30:04*Varriount-Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
20:30:18Mat3Varriount: Just install one of the newer graphic cards avariable and you can use your computer as toaster!
20:30:39VarriountMm. Toast.
20:30:59flaviu1Araq: I like Arch, if you're feeling adventurous, install a tiling window manager
20:31:43Araqhmm indeed
20:31:59Araqnever tried a tiling wm
20:32:07*DAddYE quit ()
20:32:37VarriountAraq: What do the preferName, preferDesc, preferExported members of the TPreferedDesc enum stand for?
20:32:50flaviu1highlight.js is usually used for inline syntax highlighting, like `let b = c`, where there is no extension. Anyway, for my usecase I can practically check every output for bugs
20:33:13VarriountAraq: They are used in the typeToString proc
20:33:20*nande_ joined #nimrod
20:34:09Araqtype Foo = array[8, int]
20:34:14AraqpreferName --> Foo
20:34:23AraqpreferDesc --> array[8, int]
20:35:05AraqpreferExported --> Foo (but ensure it stays this way as it's exposed via typetraits)
20:37:04VarriountAraq: Thanks. I'm looking at dom96's recent PR (https://github.com/Araq/Nimrod/pull/1232) and trying to decide if adding another TPreferedDesc member is appropriate
20:38:38foodooflaviu1: Tiling window managers as an adventure? Everything is so clearly and neatly structured, that it's hardly an adventure. I guess you want to imply that you don't have the system preferences as a handy menu entry waiting for you but you have to do everything on the command line, right?
20:38:49*DAddYE joined #nimrod
20:39:00flaviu1foodoo: I just mean its something new
20:40:42flaviu1Nothing was intended by my word choice except to point out they're a different experience from the more typical floating window managers
20:41:36*hoverbea_ joined #nimrod
20:42:36Araqthe typical window manager doesn't "manage" anything :-)
20:43:41nequitans_i had a surprisingly long stint with twm
20:45:17*hoverbear quit (Ping timeout: 264 seconds)
20:45:45Varriountfowl: Adding hard to test code reproductions with issues does not make me happy.
20:46:03Varriountfowl: I do not want to have to download things just to fix a bug.
20:46:14*filwit joined #nimrod
20:46:35nequitans_just liked how i could collapse my windows into little icons and place them freely on a desktop. for tiling i really like 'smart snap resizing'
20:47:12*Joe_knock joined #nimrod
20:48:58*DAddYE quit ()
20:49:24VarriountAraq: By the way, any other bugs I can fix?
20:50:17AraqVarriount: of course
20:50:33EXetoCwhat about that type constraint issue?
20:50:56EXetoCthe one where int literals can bypass constraints.
20:51:23AraqEXetoC: yeah, for instance that one
20:52:25EXetoCthough I don't know much about those 18 high priority bugs, but that one seems pretty intrusive. not many people have noticed that though apparently
20:53:05fowlVarriount, good morning, what are you talking about?
20:53:57*DAddYE joined #nimrod
20:54:42flaviu1fowl: He probably doesn't like that you included an import that isn't in the stdlib
20:55:53Mat3ciao
20:56:00*Mat3 quit (Quit: Verlassend)
20:57:01AraqVarriount!!! I sent you a pm
21:02:01*freezerburnv joined #nimrod
21:05:05Joe_knockHello nimrod soldiers
21:05:37EXetoCdom96: what was it that you didn't like about gtk?
21:05:40EXetoCJoe_knock: hola
21:06:15dom96EXetoC: it's not flexible enough
21:08:10*DAddYE quit ()
21:08:27EXetoCok
21:13:50*Demos joined #nimrod
21:23:03*DAddYE joined #nimrod
21:25:11BitPuffindom96: said your mum during schlucking
21:25:41dom96wut
21:25:49BitPuffindom96: it's not flexible enough
21:28:15*foodoo quit (Remote host closed the connection)
21:28:56Joe_knock:O
21:31:33EXetoCdom96: that scrolling issue included? what else?
21:31:44EXetoCdunno if that's an issue with gtksourceview
21:32:10*Joe_knock quit (Quit: Leaving)
21:52:24*hoverbear joined #nimrod
21:55:27*freezerburnv quit (Quit: freezerburnv)
22:01:20*hoverbea_ quit (Ping timeout: 264 seconds)
22:07:04*DAddYE_ joined #nimrod
22:07:04*DAddYE quit (Read error: Connection reset by peer)
22:37:46*nequitans_ quit (Ping timeout: 258 seconds)
22:40:27*bjz_ joined #nimrod
22:43:37Araqfyi I'm adding the option of 'sortoutput' for the tester
22:43:54Araqso that the tester can make the output deterministic for threading tests
22:45:17*bjz_ quit (Ping timeout: 245 seconds)
22:46:17*OrionPK quit (Ping timeout: 252 seconds)
22:52:47filwitAraq: out of curiosity, do you know how much time your GC spends on cyclic detection compared to reference scanning? Is it by far the most costly step, or what?
22:55:07Araqdepends on your code
22:55:47Araqhowever it's not incremental at all
22:56:09Araqso say good bye to the realtime guarantee if it triggers
22:56:34filwithmm.. okay. good to know.
22:56:57Araqthat's the primary reason why we say it's "soft realtime"
22:57:13Araqotherwise it's really good enough for "hard realtime" afaict
22:57:34flaviu1Getting syntax autodetection to work is "fun"
22:57:35filwitso the worse case scenario for Nimrod's GC is heavy cyclic code then. Good thing we have a pragma for that.
22:58:03flaviu1Apparently it can barely tell the difference between nimrod and XML
22:58:25Araqfilwit: there are at least 2 ways to fix that though
22:58:34filwitstill, my question was more academic in nature. I'm just wondering in general if the Cyclic detection of most GC's is the slowest step in most cases, and if so, by how much.
22:59:03Araqmost GC algorithms have no "cycle detection"
22:59:18filwiterr.. what really?
22:59:19Araqmost don't care at all about cycles
22:59:28filwitso they just keep junk memory around?
22:59:33Araqit's not a concept in these algorithms
22:59:49flaviu1Araq: I wouldn't say most
22:59:52Araqno, they happily free cyclic structures with no problem
23:00:00flaviu1oh, I see
23:00:10flaviu1Copying collectors
23:00:24filwitwow, didn't realize that. Surely not Java & C#'s GCs tho?
23:00:42flaviu1filwit: They free cycles, but they don't special-case it
23:01:01filwitflaviu1: not entire sure what you mean.
23:01:10filwitflaviu1: special case it?
23:01:14Araqfilwit: he answered your question
23:01:24filwitsorry, brb one sec
23:01:33Araq" Surely not Java & C#'s GCs tho?" yes, they do!
23:02:53flaviu1Non-conservative copying collectors have a little area of memory where they allocate stuff. When the area fills up, they scan every available pointer and copy all the referenced memory to another, bigger arena. It doesn't matter if there's a cycle, if no element in the cycle is referenced, it'll be collected,
23:03:33filwitk, back
23:04:02filwitAraq: wow... good to know. So technically Nimrod's GC is more 'safe' than Java and C#'s GCs?
23:04:29flaviu1filwit: No, it isn't
23:04:50filwitflaviu1: okay, thanks for the explanation. That makes some sense.
23:06:01filwitI see i have a lot more to learn about GC designs than what I initially thought :\
23:07:23*OrionPK joined #nimrod
23:07:24Araqyou can spend your lifetime with GCs
23:07:28flaviu1Nimrod can't have a copying collector like that until semantics are more carefully defined to make low-level operations possible without having to scan conservatively. Also, C interop might become more difficult, it'd have to assume that anything that gets passed to C is referenced from then on and be unable to free it.
23:08:16Araqcopying collectors have their own problems though
23:08:30flaviu1hmm?
23:08:37Araqthey tend to be the state of the art for throughput though
23:09:13flaviu1Copying collectors do very well with lots of garbage allocation
23:09:25Araqflaviu1: you need a 2nd strategy for big objects, forward references are not trivial to handle
23:09:55flaviu1And they're also compacting, so the linked list you boneheadly made will likely be contiguous.
23:10:23Araqand what is worst, they traverse graphs in Breadth-first
23:10:54Araqwhich is unlikely the traversal that the mutator uses
23:11:08Araqso that's bad for caches
23:12:22filwitwell i'm glad i asked, this cleared some things up for me
23:13:01flaviu1Araq: Big objects typically get their own arena, and usually a bit of the arena is reserved for forward references. I don't see why a GC couldn't transverse Depth-first
23:13:50Araqfair enough. but baker's algorithm is breadth-first
23:14:57flaviu1Mark-sweep seems to be depth first
23:15:04Araqit is
23:15:46Araqapart from mark&sweep every other collector needs a "companion"
23:16:12Araqcopying collector need special handling for big objects
23:16:27AraqRC collectors need special handling for cycles
23:16:36Araqmark&sweep just works :P
23:17:10Demoscopying collectors would seem to be really aggrivateing if you need to interface with code that does not know about the collector, you get c#'s pinning and debugging errors is TERRABLE
23:17:26flaviu1Usually copying collectors are generational and use a arena for big objects, only checking for free every few collections
23:18:56flaviu1I wonder how having a separate arena that gets collected by regular mark&sweep would work for C interop
23:19:37filwitDemos: yeah i was just thinking the same thing. Suddenly C#'s 'fixed' stuff makes a whole lot more sense
23:19:42Demosyeah
23:20:04filwitcan you have a Copy Collector that is incremental? Seems difficult if not impossible.
23:20:23Demoson the one hand being able to just move stuff around as you wish is really appealing for the implementer, but on the other hand it requires a lot of runtime support
23:21:12flaviu1filwit: Control pause times by nursery area size
23:21:21filwitwell i can imagine copy collectors would be bad for games, by causing random stutter. Then again, best practice in most games is to prealloc everything anyways, so maybe not.
23:21:31DemosI am having trouble imagineing a GC that runs faster than non-atomic RC though
23:21:49filwitflaviu1: ah, okay. makes sense.
23:22:09flaviu1Demos: A GC might have positive side effects tat non-atomic RC doesn't, like heap compaction and possibly better cache coherence
23:23:07Demoswell in a language like nimrod you may as well just not allocate horrible linked structures. I mean if the GC can compact them than you probably don't really need them anyways
23:23:15Demosheap defragmentation is nice
23:23:32Demosalthough modern virtual memory managers make heap fragmentation less of an issue
23:23:55flaviu1Demos: Really? I'm not familiar with allocation strategies.
23:24:24Demosone thing we can not do now (apperently according to araq) is move a whole structure to a different heap. I suppose a copying GC can do that
23:26:34*nequitans_ joined #nimrod
23:27:10Araqfragmentation is an academic problem
23:27:27AraqI always thought this and recently I found a paper that agrees with me :P
23:28:08Demosa paper that thinks its topic is academic! what is this madness
23:28:35AraqDemos: the upcoming 'spawn' mitigates the thread local heaps tremendously
23:28:44*hoverbear quit ()
23:29:29Araqit's still not a 'move' technically but I think it's very good
23:30:36Demoswhat are the semantics of spawn?
23:30:47DemosI guess I will have to wait and see
23:31:20Demosand why is fragmentation academic, just because solutions only apply where it does not matter and if you care you would just use the heap less?
23:31:34flaviu130% of memory is wasted in one application
23:31:36flaviu1http://www.research.rutgers.edu/~bohra/pubs/malloc.pdf
23:32:03flaviu1Almost academic, but they have weird allocation patterns. Emacs wastes 3% of memory to fragmentation
23:33:27flaviu1Page 10 has the nice graphs and tables
23:35:22filwitstill, copying large chunks of memory around seems rather stutter prone, even with incremental nurseries.
23:36:31VarriountAraq: If you're still awake/able, what kinds of bugs could I work on in my spare time?
23:36:44flaviu1And even then you have to deal with the survivor group, which is even larger. Java does GC in parallel, so it isn't stop-the-world though.
23:37:33flaviu1And you could tell the GC not to do a major collection until certain points like respawns or anywhere where it won't be especially noticeable
23:37:36*Varriount wonders how much of Java runtime is spent locking/unlocking memory
23:38:57filwitflaviu1: good point. Idk if i like a dedicated GC thread though (would prefer thread-local heaps which scan on allocation) because it sounds like a race condition waiting to happen.
23:39:22filwitbut i have only given this minor thought so far, and Java obviously is living just fine with it...
23:40:53filwitanyone know if D uses a copy collector ?
23:41:16flaviu1filwit: It uses a conservative collector
23:41:36AraqD uses a primitive stop the world mark&sweep GC and will never use something better
23:41:39flaviu1You can stick pointers in integers and have no problems
23:42:14Araqok, never say never
23:42:29Araqbut the language is hostile to a GC like no other "modern" language
23:42:36VarriountHowso?
23:42:43flaviu1D will never use anything but a conservative collector
23:43:10Araqflaviu1: make that "partially conservative"
23:43:24filwitAraq: yeah i've heard bad things about D's GC, though I never made anything memory heavy enough in D to stress that myself
23:43:44Araqthe problem is not that the GC is bad
23:43:49filwitAraq: perhaps D is hostile towards GC because of it's GC design
23:44:00Araqthe problem is that the language design is bad
23:44:30filwitit's not all bad, compared to C/C++ it has some nice features
23:44:37Araqfilwit: they thought a good GC is a quality of implementation issue
23:44:44Araqbut it's not
23:44:48flaviu1Yeah, but only because they don't also check floating point mantissas for pointers
23:45:02Araqflaviu1: lol
23:45:40filwita lot of things in D seem like a hack tho, like float default to NaN, and mixin(..) everywhere cause they don't have a proper macro systems
23:46:09Demosit's like Horders with pointers!
23:46:11Varriountfilwit: Float defaults to NaN? Why not zero?
23:46:53filwitVarriount: cause of some unrealistic condition Walter thinks will happen if things default to useful variables.
23:46:54flaviu1Varriount: So you can't accidentally use it without initializing
23:47:21flaviu1Defaulting to NaN must also be a bit of a pain to implement.
23:47:42Demoswhat do integers default to?
23:47:45filwit..except i *want* to use it without *needing* to explicitly initialize it.. because that's how everything else works...
23:48:10flaviu1Demos: 0 IIRC
23:48:42flaviu1yep, 0
23:48:44filwitchars in D also default to some odd 'nil like' symbol
23:48:56filwitalthough that one makes a little more sense
23:49:26AraqVarriount: #1216 for a start (look at guards.nim)
23:49:31filwitWalter said that if int had a 'NaN' he would make them default to it
23:49:34DemosI suspect that the whole "you must initialize stuff everywhere" came from C89 where you had to declare all your vars at the top of a scope, and it made some sense to default to undefined
23:50:02flaviu1Oh, so that's why so much C code is horrible to read
23:50:24flaviu1I had no idea there was a technical reason for it
23:50:27Demoswell I think C should be written in C89 As God Intended
23:50:33Varriountflaviu1: I don't know about that, I tend to write my Nimrod code in that manner.
23:50:39Demosand because you may want to compile with MSVC at some point
23:50:46Araq#1142
23:50:59Araq#1143
23:50:59filwitDemos: nah, his argument was about big projects, and someone else removing your explicit initialization (after the var declaration), in which case you would get a NaN in the output which would expose the bug..
23:51:02VarriountThat is, for the variables that I will always need, I put them at the top of the procedure.
23:51:05flaviu1Varriount: Heresy, keep your local variables as close to their usage
23:52:16Araq#1144
23:52:18filwitDemos: i tried to explain that this would just lead programmers to do "auto i = 0" everywhere, thus avoiding this "security feature"..
23:52:23VarriountAraq: Already fixed #1216
23:52:28DemosI have never actually heard default to undefined justified that way, but it is the only sane thing I think
23:52:35AraqVarriount: sorry
23:53:23VarriountAraq: No problem. Sleep is a pain at times, no?
23:54:33filwitDemos: i also said that it only adds confusion, since int's don't default to NaN, and that if you really want to catch these sort of things, and explicit assignment to NaN would make more sense (thus indicating at declaration that a later assignment was required)
23:55:17Araqfilwit: exactly. IF you really want that feature 'int' should default to low(int) but not to 0!
23:55:36Araq0 is a very common value
23:55:45Araqlow(int) is useless
23:55:54VarriountYou know, the alternative to buggy run-time mechanisms like this is to just use static analysis.
23:56:07filwiti don't even know what low(int) does
23:56:08*darkf joined #nimrod
23:56:26filwit-12121.. (some odd number) ?
23:56:30Varriountfilwit: Lowest number int can handle, I think.
23:56:34filwityeah
23:56:36flaviu1Varriount: Static analysis is hard, its better to use some half-baked measure
23:56:58flaviu1I think that high(int) would be better, especially if wraparound was defined to crash
23:57:27flaviu1my first statement was sarcasm
23:57:46Araqflaviu1: does tests/macros/tdumptree.nim pass now?
23:58:21flaviu1Araq: I think it always did, I think the compile-time message annotation didn't at its creation
23:58:32Araqok
23:58:41NimBotAraq/Nimrod devel 4d4ac62 flaviut [+1 ±0 -0]: Add test for #1149
23:58:41NimBotAraq/Nimrod devel 2fcc911 flaviut [+0 ±1 -0]: Enable disabled test
23:58:41NimBotAraq/Nimrod devel 7d9042b Andreas Rumpf [+1 ±1 -0]: Merge pull request #1231 from flaviut/test1149... 2 more lines
23:59:24NimBotAraq/Nimrod devel 056c780 flaviut [+0 ±1 -0]: Fix #1226
23:59:24NimBotAraq/Nimrod devel 85e6e2a flaviut [+0 ±2 -0]: Document mangling
23:59:24NimBotAraq/Nimrod devel 7ab2bc3 Andreas Rumpf [+0 ±2 -0]: Merge pull request #1230 from flaviut/fix1226... 2 more lines
23:59:28filwitC#'s static analysis on local var initilization is the best (for both sanity and performances reasons), but failing that, Nimrod's useful defaults + {.noInit.} is a close second. My opinion.