<< 03-05-2014 >>
00:03:02flaviuJehan_: Wow, thats very fast
00:03:24Jehan_The difference is mostly due to using a different algorithm, not because of Nimrod.
00:04:05Jehan_Though Nimrod made it easy to make the recursion fast and not having to recode it manually into an iterative one.
00:06:20DemosJehan_: did you see my snark about linguistic relittivity?
00:06:30Jehan_Yeah.
00:06:52Jehan_I think you misunderstood me. I didn't say that I subscribe to the Sapir-Whorf hypothesis.
00:07:26Jehan_(Though there's some good evidence for the weak version, even if the strong version is silly.)
00:07:33VarriountAraq: No one ever told me to add GetCurrentProcess.
00:08:19Jehan_NImrod needs self-awareness so that it contribute to SkyNet. Hurry up! :)
00:08:25Demoswell yeah, but the weak version is not all that interesting, it just makes me uneasy since people /want/ it to be true so badly
00:08:26Jehan_can contribute*
00:08:36Jehan_Do they?
00:08:36VarriountAnd unfortunately, the IRC protocol does not support telepathy.
00:08:49Jehan_I'd find it scary if language really determined thought.
00:09:38Jehan_I'm pretty sure that it does influence thought (I think differently, depending on what language I think in). But that's neither surprising nor scary.
00:09:55Demosyeah, I mean thought determines what we say, this is probably true, but totally uninteresting
00:10:05Jehan_I think the topic has come up on LtU more than once.
00:10:32Jehan_No, the weak version is that the language that we use has an effect on how we think.
00:10:38Demosyeah I know
00:10:40Jehan_Not the other way round.
00:10:52Jehan_Oh, I thought you were saying the opposite. Typo?
00:11:08VarriountAraq: If you give me a list of things to wrap, I'll wrap them. However I'm currently studying for my upcoming exams.
00:11:50*q66 quit (Ping timeout: 252 seconds)
00:11:56Demosmy point was that the strong version (and the weak one a bit) is silly because there is not really a whole lot of good ways to test them (I know there are some but still)
00:12:44Jehan_Well, that would make them unfalsifiable (or at least difficult to falsify), I'd say, not per se silly.
00:13:38reactormonkfowl, shouldn't that have a lot of importc statements?
00:14:04reactormonkoh. callconv cdecl does that?
00:14:19fowlreactormonk, no, refresh
00:14:28fowlreactormonk, i push importc:"LLVM$1"
00:15:16reactormonknice
00:16:36reactormonkAraq, I guess I'll get my answer later
00:18:45DemosI love how GTK prints failed asserts to standard error :D
00:18:58Demoseagh whatever
00:19:54flaviuOpencv does the same, I think its typical
00:20:17Demosis openCV a khronos thing?
00:20:34VarriountSpeaking from ignorance, what should failed asserts properly do? Halt the program?
00:21:02Demoswell yes, but asserts should not even be in a release program
00:21:15Jehan_Umm … that depends.
00:21:16flaviuI don't think so. Opencv also throws an exception though
00:21:39Jehan_And yeah, an exception is probably what you'd normally expect.
00:22:08Demoswell yeah, it does depend, and GTK probably has more finegrained control over which asserts do what.
00:22:26flaviushould int32(0x00'i64) work? I might need to do a cast
00:22:54DemosI am gunna go ahead and assume nobody has openBSD binaries of nimrod
00:23:05flaviuDemos: Ports does
00:23:58*q66 joined #nimrod
00:23:59*q66 quit (Changing host)
00:23:59*q66 joined #nimrod
00:24:30DemosI am not seeing it
00:26:21flaviuDemos: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/nimrod/
00:26:34Demosoh it is in lang
00:27:45DemosOK I am not seeing it in my ports tree, running 5.5 stable
00:28:42Jehan_Hmm, I may have to write GMP bindings.
00:28:50flaviuSorry, I'm not familiar with openbsd.
00:29:26fowlflaviu, https://github.com/fowlmouth/llvm.nim
00:30:19flaviuok, thanks
00:30:38fowlwhats your github username, "falviu"?
00:30:46fowl"flaviu"*
00:33:10Varriount"flavorfulio"
00:33:34flaviuflaviut
00:34:24fowlflaviu, i add you as a collab so you can push to the main repo, will add it to packages.json later
00:34:30fowlbbl
00:34:40flaviuThanks
00:43:27*DAddYE quit (Remote host closed the connection)
00:48:07*Demos quit (Quit: WeeChat 0.4.2)
00:57:39*xenagi quit (Read error: Connection reset by peer)
01:11:53*BitPufiin joined #nimrod
01:24:50*Jehan_ quit (Quit: Leaving)
01:38:06flaviuWhats the thing that turns gibberish C into readable words? I found a website that does that, but I lost it
01:42:08*q66 quit (Quit: Leaving)
01:46:54flaviufound it, cdecl.org
01:53:04*Kelet joined #nimrod
02:20:07Skrylarfor some reason i thought defined() worked on custom -d: flags too, though its not in the system.html file
02:20:22KeletIf someone doesn't mind humoring my newbiness:
02:20:51KeletIf I want to make a proc that accepts both arrays and sequences, are generics the way to go, or is it easier?
02:21:15KeletAnd if generics are the way to go, is there anyway to (compile-time?) enforce that everything coming in is an array or seq?
02:22:32flaviuKelet: openarray[whatever]
02:22:45flaviuThat seems to work for me, takes both arrays and seqs
02:24:14Keletah
02:24:42Keletdoh
02:46:49flaviuCgen messes up on an inline function, but I'm not sure whats going on
03:19:48*sebaseba quit (Ping timeout: 240 seconds)
03:22:32reactormonkAraq, can't bisect the problem either, not backwards-compatible
03:34:50*bjz joined #nimrod
03:51:04flaviuDoes docgen do anything to annotated enums?
04:15:20*CARAM quit (Ping timeout: 252 seconds)
04:17:10*TylerE quit (Ping timeout: 252 seconds)
04:32:37*CARAM joined #nimrod
04:32:55*TylerE joined #nimrod
04:42:57*menscrem joined #nimrod
04:46:16*flaviu quit (Remote host closed the connection)
04:59:32*[1]Endy joined #nimrod
04:59:37*brson joined #nimrod
05:03:02*[2]Endy joined #nimrod
05:04:42*[1]Endy quit (Ping timeout: 240 seconds)
05:06:20*[2]Endy left #nimrod (#nimrod)
05:30:59*[1]Endy joined #nimrod
05:31:04*[1]Endy left #nimrod (#nimrod)
05:34:25njoejoehoney badgers meet privacy badger: https://www.eff.org/privacybadger
05:34:55VarriountHmf. We still had the mascot first.
05:35:16Varriountnjoejoe: Does this block ads completely, or just the ones that spy on privacy?
05:36:00VarriountI dislike adblockers (see here for my reason why - http://jayisgames.com/archives/2014/01/jayisgames_ads_the_future_and_you.php)
05:42:39njoejoeit blocks trackers that track you across multiple websites
05:44:11njoejoeads are fine, tracking is not
05:51:10fowlvery nice
05:51:11fowlhttp://fowlmouth.github.io/llvm.nim/doc.html
05:51:36VarriountO_o
05:51:53fowli will write a script to push docs for all my modules to github
06:03:25*ehaliewicz quit (Remote host closed the connection)
06:07:17SkrylarVarriount: eh, its a business problem
06:07:23Skrylari'll go over to offtopic for that
06:09:28Skrylarnjoejoe: unfortunately ads and tracking = same thing
06:09:54Skrylar'do not track' et all is basically like asking really nicely that the NSA not steal any data they can
06:10:21Skrylarbut data is basically profit for data miners, and asking a business to "please not make as much money as you want" never works
06:17:32SkrylarI think some of the more successful webgame people are the ones who put their flash games up on the site for free, and then sell the iOS version for ~2$
06:18:25*DAddYE joined #nimrod
07:17:37*ehaliewicz joined #nimrod
07:48:37*Skrylar quit (Ping timeout: 276 seconds)
08:04:17*Kelet quit (*.net *.split)
08:04:20*musicalchair quit (*.net *.split)
08:04:21*bjz quit (*.net *.split)
08:04:22*noam_ quit (*.net *.split)
08:04:26*vendethiel quit (*.net *.split)
08:04:27*Xuerian quit (*.net *.split)
08:04:28*krusipo quit (*.net *.split)
08:04:34*njoejoe quit (*.net *.split)
08:04:34*Amrykid quit (*.net *.split)
08:04:36*mal`` quit (*.net *.split)
08:06:09*musicalchair joined #nimrod
08:06:55*bjz joined #nimrod
08:06:55*noam_ joined #nimrod
08:06:55*vendethiel joined #nimrod
08:06:55*Xuerian joined #nimrod
08:06:55*krusipo joined #nimrod
08:11:44*njoejoe joined #nimrod
08:11:45*Amrykid joined #nimrod
08:11:45*mal`` joined #nimrod
08:22:03*brson quit (Quit: leaving)
08:26:00*Kelet joined #nimrod
08:33:09*DAddYE quit (Remote host closed the connection)
08:33:36*DAddYE joined #nimrod
08:37:16*Matthias247 joined #nimrod
08:37:54*DAddYE quit (Ping timeout: 240 seconds)
08:52:00*q66 joined #nimrod
08:52:01*q66 quit (Changing host)
08:52:01*q66 joined #nimrod
08:58:21*Skrylar joined #nimrod
09:28:16*ehaliewicz quit (Remote host closed the connection)
09:47:58xyprotoEXetoC: Updated the nimrod package in Arch to use the same method as the nimrod-git package (but using a commit/tag instead of HEAD). Seems to work here. Works for you too? :)
09:48:42*EXetoC quit (Remote host closed the connection)
09:51:33*EXetoC joined #nimrod
10:17:26*q66 quit (Quit: Leaving)
10:22:26*xyproto left #nimrod ("WeeChat 0.4.3")
10:36:26*q66 joined #nimrod
10:36:26*q66 quit (Changing host)
10:36:26*q66 joined #nimrod
11:11:23*Matthias247 quit (Read error: Connection reset by peer)
11:24:16dom96Varriount: ping
11:27:14Araqecho formatFloat(procTotal / sysTotal)
11:27:27Araqproduces -1.#IND00000000000
11:27:31Araqany ideas?
11:55:50*brechtm joined #nimrod
11:56:23brechtmhi
11:57:34brechtmwas going through the c2nim sources to see if I could make some improvements to automate libgit2 (and hopefully others) conversion more
11:58:14brechtmIs it correct that c2nim does not differentiate between function and variable names when mangling them?
11:58:40Araqyes
11:59:21brechtmAraq: any reason not to do that? If not, I can give it a shot
12:01:08brechtmanother thing I had in mind: warn/error or auto-mangle double underscores or names that match nimrod keywords
12:02:17Araqno, these are all great ideas
12:02:20Araqgo for it
12:02:32brechtmgreat, thanks
12:07:05Araqbtw
12:07:16Araqcparse.nim, line 905
12:07:23Araq # typedef struct a a?
12:07:29Araq # ignore the declaration:
12:07:43Araqyour bug is in fact a feature
12:07:52Araqbut I can't remember why we do this
12:10:09brechtmAraq: I see some extra lines there "if mangleName(p.tok.s, p) == nameOrType.ident.s:"
12:13:08brechtmnm
12:17:55brechtmcommit msg says "c2nim: cast-bug fixes (sort of)"
12:19:21brechtmno, it's in there since the first commit
12:30:59*darkf quit (Quit: Leaving)
12:33:48*brechtm quit (Ping timeout: 240 seconds)
13:11:39*silven joined #nimrod
13:55:23*flaviu joined #nimrod
14:01:14*TylerE quit (Ping timeout: 252 seconds)
14:02:57*TylerE joined #nimrod
14:09:12*faassen quit (Quit: Leaving.)
14:10:00*Jehan_ joined #nimrod
14:42:23Jehan_Is there a reason why a dynlib argument would end up in a #include directive?
14:59:21*Matthias247 joined #nimrod
15:01:27AraqJehan_: no idea what you mean
15:03:03Araq.header influences #include directives
15:03:54Jehan_ file not found
15:03:54Jehan_#include "libgmp.dylib"
15:03:54Jehan_ ^
15:05:08Jehan_From: {.pragma: gmpdef, header: "<gmp.h>", cdecl, dynlib: "libgmp.dylib", importc.}
15:05:27Araqwell you can't use header and dynlib at the same time
15:06:01Jehan_Ah. I see. I had already figured out that I wanted to use passL rather than dynlib. But the error is still slightly confusing.
15:06:16Araqsure
15:06:40Araqbtw I prefer 'dynlib' over 'header'
15:07:44Jehan_My problem is with accurately mapping C integer types to Nimrod integer types of the exact corresponding type.
15:08:13Jehan_header should keep me safe there, dynlib doesn't protect me against a mismatch.
15:08:24Araqyes, I avoid the 'accurately'.
15:08:58AraqI only care about ABI compatibility
15:09:16Jehan_Well, getting int, long, and long long mixed up does create ABI compatibility.
15:09:27Jehan_incompatiblity*
15:10:12Araqalso your approach requires me to have 'gmp.h' around
15:11:18Jehan_Yes. Right now, I view that as a benefit.
15:14:50Jehan_Especially since c2nim barfs on gmp.h. :)
15:16:16EXetoCin barfs on a lot of things. sometimes manually patching isn't so bad, but I wouldn't be surprised if gmp was yet another lib that relied on a million macros of varying complexity
15:16:30Jehan_EXetoC: Yeah, not really c2nim's fault.
15:16:50Jehan_I've done enough C parsing myself to know all about these problems. :(
15:17:16Araqfyi clang2nim is in the works
15:17:28Araqbut I don't know the status of it
15:17:43Jehan_At the same time, since I'm manually translating part of the header, I like the safeguard of having it properly matched when compiled.
15:18:37EXetoCit does a good job, so just a little better macro parsing (including ##) would be great
15:19:04*vendethiel quit (Ping timeout: 276 seconds)
15:19:56*vendethiel joined #nimrod
15:21:19EXetoCand "x = (y = z)" remains unchanged. it's a minor thing though, and the clang version might simplify that
15:21:54Jehan_But to get back to headers vs. dynlib, for example, there's stuff like off_t being hardcoded as int64 in posix.nim.
15:22:43Jehan_That works on most architectures, but is not guaranteed to work everywhere.
15:23:18Jehan_Including the relevant header makes sure the C compiler is aware of the actual prototypes defined by the system.
15:23:28Jehan_And can adjust int sizes accordingly.
15:24:06Araqyeah but I don't care. It's (a) a prosix problem that assumes the world only consists of C/C++ and (b) a problem that every other language also has
15:24:34Araqok, nimrod can do better thanks to .header
15:24:42Jehan_Correct, but using prototypes fixes it.
15:24:57Jehan_Another reason why I like C as a compilation target, by the way. :)
15:25:00Araqbut this stops working as soon as we compile to LLVM
15:25:15Jehan_Yup.
15:25:17EXetoCaren't there ways to query these things? it really should be possible to reliably query these things
15:25:38AraqEXetoC: sure, compile a C program that outputs sizeof(off_t)
15:25:44Jehan_This is why the world still depends too much on autoconf, alas.
15:26:03EXetoCwell yeah
15:27:40Jehan_Related problem: I have an int128 library that still depends on running a configuration script.
15:28:11Jehan_Because there's no way to reliably tell at compile time whether long long is 128 bit and thus can be used natively or whether I have to emulate it.
15:29:19EXetoCfortunately we can query a lot of things at compile time, but some languages can't
15:29:46Jehan_Well, querying some of this stuff still requires running the C compiler.
15:30:08Jehan_It's no big deal, I just do it from within scons. But it's annoying all the same that it's necessary.
15:31:36Jehan_And it makes it difficult to distribute the library standalone, because it needs to come with instructions how to configure it.
15:32:15EXetoCwhat have people proposed? easy to parse metadata files?
15:32:33Araqin nimrod you can use staticExec for that, Jehan_
15:32:40Jehan_I'm not sure if anyone has proposed anything. Other than: Just use autoconf, duh. :)
15:33:00Jehan_Araq: Yeah, but I don't want to run a C compiler to figure that out each time I compile.
15:34:23AraqJehan_: you can cache the results though a staticFileExists would come in handy for that ...
15:34:43Jehan_Huh. There's that? I'll have to look at it then.
15:35:31Araqno, it doesn't exist yet
15:36:01Jehan_It would probably be useful to have some nimconf library that packages such facilities for you.
15:36:15*Jehan_ makes a mental note to put it on his to-do list.
15:37:03Araqstatic fileExists("foo.nim") # works as soon as the VM gets the planned plugin system
15:37:56EXetoCmaybe something that uniquely identifies a machine too
15:37:58Jehan_That would definitely be nice.
15:38:23EXetoCso as to prevent accidental copying
15:40:05Jehan_Oh, there's no shorter version of --parallelBuild:1, right?
15:41:26Araqright
15:41:37EXetoCno. I gotta create an alias for that once and for all
15:41:46Jehan_Heh.
15:42:09EXetoCor just make a feature request
15:42:10Jehan_I usually just have a separate build target to use -f --parallelbuild:1
15:42:20Jehan_So it's not like it's a pressing concern.
15:42:28Jehan_I was just curious if I was missing something.
15:44:46Jehan_Incidentally, it looks like I blew the roof off this coding challenge, at least for now: http://codegolf.stackexchange.com/questions/26459/how-high-can-you-go-a-codingalgorithms-challenge/26528 (in part thanks to Nimrod).
15:46:29Jehan_The really interesting part is that I didn't have to sacrifice cleanliness for speed (even putting bound checks back in has virtually no effect on runtime).
15:47:08Jehan_E.g. I could use "template" to partially unroll/inline a recursive search.
15:52:10Araqyeah, pretty nice
15:58:30*enurlyx joined #nimrod
16:02:09*untitaker quit (Ping timeout: 252 seconds)
16:07:43*untitaker joined #nimrod
16:11:34*Kelet quit (Ping timeout: 258 seconds)
16:13:02enurlyxAraq: Why can i not call a function set(a[], 2) as a.set(2)? (auto deref)
16:24:06*Kelet joined #nimrod
16:24:06*Kelet quit (Ping timeout: 258 seconds)
16:24:07*Kelet joined #nimrod
16:32:12*Kelet quit (*.net *.split)
16:32:27*Kelet joined #nimrod
16:36:33Jehan_enurlyx: That only works for accessing data directly. You do have to write wrappers if you want to do that.
16:36:49Jehan_In practice, you want to decide whether you need a value or reference type and pick one or the other.
16:37:02Araqenurlyx: it's on our roadmap
16:38:02Jehan_Araq: That's nice. :) using ref TTable's was always a bit painful. :)
16:39:29AraqI made all the effort and wrote down a nice roadmap
16:39:39Araqand apparently nobody reads it :P
16:39:56enurlyxActually i did, but seems i did miss this point ...
16:41:02Jehan_Because it's cleverly hidden? :)
16:42:21*BitPufiin quit (Quit: WeeChat 0.4.3)
16:42:48EXetoCit's mentioned in the community tab at least
16:43:32Jehan_Incidentally, {.warning[LineTooLong]: off.} does not seem to work. Am I doing something wrong or should I file a bug report?
16:44:25EXetoCThat has never been triggered for me
16:44:56Jehan_I'm getting an invalid pragma, even though it's directly copied and pasted from the manual.
16:50:41enurlyxlol the first entry in the list XD
16:54:26AraqJehan_: yeah please make a bug report
16:54:33Jehan_Will do!
16:55:08Araqno idea why that doesn't work though, strange
16:55:18Jehan_I'd look at it myself, but don't really have the time to dig into parts of the compiler that I don't know all that well yet.
16:56:47Araqah
16:57:16Jehan_FWIW, hints do have the same problem.
16:57:21Jehan_That's how I ran into it.
16:57:30Araqthere is also: {.warning: "my message".} and so it conflicts and so warning[Foo]:off only works within 'push'
16:57:45reactormonkhow do I run the caas tests?
16:57:49Jehan_Hmm, push didn't seem to work for me, either?
16:58:22Araqtoo bad then
16:58:56Araqreactormonk: tests/testament/caasdriver does it but I don't know how it works
16:59:09Araqthere is a comment:
16:59:16Araq## Compiler as a service tester.
16:59:18Araq## Please read docs/idetools.txt for information about this.
16:59:42Jehan_Araq: It's not critical, I just thought I should note it.
17:00:33Araqreactormonk: it's all documented in there, section "Test suite"
17:02:42Araqthe author was "Britney Spears" for SEO reasons ...
17:02:52Araqmaybe we should change that :P
17:07:10AraqJehan_: the Windows API has rather good support for retrieving information about the NUMA architecture
17:07:22Araqbut I have no idea what Linux offers for that
17:07:28Araqbbl
17:07:31reactormonkAraq, hm, apparently not that simple.
17:08:11Jehan_Araq: /proc/cpuinfo
17:08:52Jehan_There's also a fair amount of kernel API stuff. But /proc/cpuinfo is the low-hanging fruit.
17:09:09EXetoCnah it's good. sed -i "s/Andreas Rumpf/Britney Spears" **/*.nim
17:09:16reactormonkEXetoC, kk, commit it
17:09:40Jehan_I have to say that I think that this may be misguided SEO.
17:10:01Jehan_It is not as though there's a lot of overlap between system programmers and Britney Spears fandom.
17:10:09Jehan_I hope.
17:10:10EXetoCare you sure?
17:10:14Jehan_I really hope so.
17:11:30EXetoCyeah me too
17:14:06reactormonkAraq, the caas test just dies :-/
17:14:13EXetoCmake it donald knuth
17:15:41NimBotAraq/Nimrod devel dfeb573 Simon Hafner [+0 ±2 -0]: fixed paths because caasdriver is now in testament
17:16:09*DAddYE_ joined #nimrod
17:17:03EXetoCI think it'd be nice to have a separate dir for testament
17:29:22reactormonkany idea why flushing kills my process?
17:37:54reactormonkhow do you handle signals in nimrod?
17:40:34*DAddYE_ quit (Remote host closed the connection)
17:41:00*DAddYE joined #nimrod
17:45:19EXetoCsystem/excpt.nim might give you a clue
17:45:41*DAddYE quit (Ping timeout: 258 seconds)
17:45:45EXetoCat least ctrl-c is easy to register
17:48:53EXetoC(system.setControlCHook(hook: proc () {.noconv.})
17:53:26Araqreactormonk: no way, I'm not the author, gradha is
18:24:02reactormonkAraq, looks like the nimrod serve dies
18:26:58EXetoCdom96: "subtypeName = $returnType[1].ident" this chokes on PFuture[T[U]]
18:27:04EXetoCwill report when I get back
18:28:01reactormonkAraq, of which code?
18:28:31dom96EXetoC: should be an easy fix, report it.
18:28:59*BitPuffin joined #nimrod
18:31:07NimBotAraq/Nimrod sigpipe 4098c65 Simon Hafner [+0 ±1 -0]: Fixes #1168
18:31:34reactormonkhttps://github.com/Araq/Nimrod/pull/1169 <- acceptable?
18:33:07Araqreactormonk: hmm I don't know. does this even exist on windows or on mac?
18:35:15reactormonkAraq, maybe not... you think it will fail?
18:35:31Araq... yes?
18:35:47reactormonkso when defined SIGPIPE it is
18:35:54reactormonkAraq, and see nimbuild ^^
18:36:10Araqwell I did
18:36:27Araqwhat do you want me to do? blame you in public?
18:37:22reactormonkAraq, dun worry, it's not on the devel branch
18:38:33reactormonkany reason why SIGPIPE is not defined on linux?
18:38:37Araqand neither on master I hope
18:38:52EXetoCnah won't go out, too boring
18:38:55AraqI don't know about SIGPIPE, that's why
18:39:24EXetoCdom96: I'll try to fix it myself. debugging with $ fails yet again though
18:39:40dom96EXetoC: use treeRepr
18:40:03reactormonkdom96, why not alias that to $ for trees?
18:40:15EXetoCI am
18:40:27dom96reactormonk: dunno, sounds like a good idea.
18:40:53dom96unless lispRepr is your preference
18:41:57Araqsignals, interprocess communication, fork, root, errno .... in case you didn't notice, reactormonk, nothing works on Unix.
18:42:15Araqit should have died decades ago
18:43:07reactormonkhow do you talk to children in windows?
18:43:45Araq"no, no, no, don't eat the keys!"
18:44:06reactormonk...
18:45:29*enurlyx quit (Ping timeout: 245 seconds)
18:47:17*Matthias247 quit (Read error: Connection reset by peer)
18:47:39EXetoCdom96: I haven't found any shortcuts so I guess I have to manually patch things together recursively
18:48:27dom96EXetoC: i'm not sure what you mean
18:52:42EXetoCdom96: it's an nnkBracketExpr, so it doesn't have the ident field
18:55:14dom96EXetoC: What you should do is remove subtypeName and introduce an 'subtypeIsVoid' boolean var
18:56:07dom96or perhaps 'isSubtypeVoid' because it sounds better.
18:56:39EXetoCand is more consistent in general
18:56:55dom96indeed
18:57:57EXetoCbut that's unrelated. I still need a way to get the string of the inner nnkBracketExpr in this case
18:58:10EXetoCand it might be recursive
18:58:16dom96just use toStrLit
18:58:35EXetoCI did but it crashes the VM. should it work?
18:58:42dom96isSubtypeVoid = returnType[1].toStrLit == "void"
18:58:56dom96anything that crashes the VM is a bug
19:00:30EXetoCno that's not it. I get "lib/core/macros.nim(211, 21) Error: undeclared identifier: 'seq[TBson]'"
19:00:52EXetoCsubtypeName = $returnType[1].toStrLit
19:06:18dom96that's an odd error, try removing the `$`
19:10:32EXetoCdom96: newStrLitNode: result = newNimNode(nnkStrLit) "lib/core/macros.nim(191, 21) Error: type expected"
19:10:53EXetoCodd
19:11:12EXetoCbad line info?
19:15:44dom96does it happen on the first invokation of async?
19:15:54dom96or just your function?
19:17:24EXetoCpretty sure it's my function only. will check
19:32:30EXetoCok so that last error message applies to one of my await statements which is confusing
19:32:31*flaviu quit (Remote host closed the connection)
19:33:18*Jesin quit (Quit: Leaving)
19:36:07*Jesin joined #nimrod
19:41:45Varriountdom96: Pong
19:42:26dom96PM'd you
19:44:44Varriountdom96: Change the Overlapped struct so that the first two members are pointers please.
19:44:58fowli cant believe that the default `==` doestn work for json nodes
19:45:22fowlecho(%1 == %1) false
19:45:51fowllet h = %"h"; h == h
19:45:54fowlthats true
19:46:06dom96I guess we need a special == for json nodes
19:46:14dom96Varriount: why?
19:46:31fowldom96, i wonder what the deal is though, the default == should work
19:46:42Varriountdom96: Because the members are incorrect.
19:46:48dom96fowl: It's likely because json nodes are not value types, they're refs
19:47:11Varriountdom96: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684342(v=vs.85).aspx
19:47:53VarriountIt says that the first two members are ULONG_PTR's, which are data types meant for casting pointers to when doing pointer arithmatic.
19:48:05fowli tried to test echo((%"Hello")[] == (%"Hello")[])
19:48:17fowlsystem.nim(1770, 2) Error: parallel 'fields' iterator does not work for 'case' objects
19:48:22fowlwut.wut
19:48:55*enurlyx joined #nimrod
19:49:20VarriountThat, plus reading of the data types pages (http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx) plus printing the sizeof(ulong_ptr) in a C program shows that the type is 32 bits on a 32 bit system, and 64 bits on a 64 bit system
19:49:47dom96Varriount: And what does printing sizeof(int) give you?
19:50:09Varriountdom96: In a C program, or a nimrod program?
19:50:14dom96a nimrod program
19:50:32dom96actually hrm, dword is an int43
19:50:33dom96*32
19:50:44VarriountYeah, which is why it's incorrect.
19:51:22VarriountI discovered this after finding that all my calls to ReadDirectoryChanges were failing with "Invalid Handle"
19:51:32VarriountEven when supplying a good file handle.
19:52:11dom96Does changing dword to ulong_ptr fix it for you?
19:52:38EXetoCdunno why await is undeclared now
19:52:51VarriountWell, there currently is no ulong_ptr type, or else my autocomplete failed. I changed it to 'pointer'
19:53:01dom96EXetoC: The macro should remove all 'awaits'
19:53:25VarriountDigging around (and finding some pascal forum posts with the same problem), I discovered that the "Invalid Handle" error will also occur if the overlapped struct isn't zeroed when passed.
19:53:46dom96Varriount: does it work if you change it to 'pointer'?
19:53:49VarriountYes.
19:53:57dom96Varriount: try PULONG
19:54:26EXetoCdom96: "proc f: PFuture[int] {.async.} = await newAsyncSocket().connect("www.google.com", TPort(80)) let x = await f()" bug?
19:54:38Varriountdom96: Yep.
19:55:00EXetoCthe proc ends after the first await. I didn't make that clear
19:55:19dom96EXetoC: You can't await in the global scope
19:55:45EXetoCforgot about that..
19:55:46dom96Varriount: ok, i'll change it to PULONG then
19:56:17EXetoCcan that be highlighted?
19:56:18VarriountAm I correct in assuming that the await an async macros transform the procedure they're used in into a closure iterator?
19:56:32Varriount*await and async
19:57:03dom96Varriount: Yes. Have you read my blog post yet?
19:57:07dom96It explains it all.
19:57:13VarriountNot all of it.
19:57:17dom96'await' isn't a macro btw
19:57:33dom96if anyone else wants to read it I can send you a link through PM because it's not finished yet
19:57:37reactormonkwhat's `when const X defined` again?
19:58:16Jehan_Huh. In queues.nim:dequeue, assert q.count > 0 fails because the compiler thinks it doesn't know 'count'?
20:00:07Jehan_Hmm, should assert be an immediate template?
20:00:43EXetoCok 2 reports submitted
20:00:46Jehan_Or is this a deeper bug?
20:00:46Varriountdom96: Incidentally, the way Nimrod's async and await works is quite similar to the python networking library Twisted's inline_callbacks decorator.
20:02:09VarriountAlso, where did you get the CSS layout for your site?
20:02:24dom96I wrote it myself
20:02:45Varriount:O
20:03:29NimBotAraq/Nimrod devel 24babde Dominik Picheta [+0 ±1 -0]: DWORD -> PULONG for POverlapped.
20:03:31EXetoCI wonder if there are any good CSS wrappers that hide all the weird crap
20:03:54dom96Varriount: You like it?
20:04:10Varriountdom96: Yes. It's nice and clean, without being too plain.
20:06:24dom96Varriount: Good because I worry it may be hard to read because the blue is too bright.
20:07:40*dom96 is never happy with his designs
20:11:12*Puffin joined #nimrod
20:16:34*BitPuffin quit (*.net *.split)
20:16:35*Kelet quit (*.net *.split)
20:17:11NimBotnimrod-code/nimbuild master ff7c13d Dominik Picheta [+0 ±1 -0]: Ensure +x permissions when switching binaries.
20:17:11NimBotnimrod-code/nimbuild master 62e2a3e Dominik Picheta [+0 ±3 -0]: Merge branch 'master' of github.com:nimrod-code/nimbuild
20:21:21dom96EXetoC: have you given up on fixing #1171 then?
20:22:21EXetoCI don't know what to do next
20:22:52dom96All you need to do is check the kind of the node.
20:23:18dom96if it's an nnkIdent check if the ident equals 'void'
20:24:39EXetoCas I said before, I wasn't able to retrieve the identifier for nodes that aren't nnkIdent
20:25:05dom96you don't need to
20:25:14dom96if it's not an nnkIdent then it's not void
20:25:24dom96so set isSubtypeVoid = false
20:25:34dom96s/=/to/
20:29:43EXetoCright, and then just replace that ident node with the node in returnType, as well as the other instances of subtypeName
20:30:50*Kelet joined #nimrod
20:39:48*menscrem quit (Ping timeout: 240 seconds)
20:40:26reactormonkwhat's `when const X defined` again?
20:40:29reactormonkehh
20:41:06fowlo.O
20:42:08reactormonkgood old `defined`
20:43:05NimBotAraq/Nimrod sigpipe ea5cc5f Simon Hafner [+0 ±2 -0]: Fixes #1168
20:49:03reactormonkhttp://pastie.org/private/f9uchpteivkcn3ea39qknq <- will this work as expected?
20:49:08reactormonk... and is there a better way?
20:49:38Araqreactormonk: how about an 'else' ?
20:51:13reactormonkAraq, how do I mix that with the when? duplicate the unknown action?
20:52:20Araqyeah
20:52:27AraqI guess your solution is fine
20:52:53reactormonkwould it be ugly to mix runtime and compiletime in a single if?
20:52:57Araqdefined + if is a common problem, maybe we can do something about it
20:53:15Araqthe problem is not that it is ugly, the problem is that it cannot work
20:53:33Araqit requires a language change to support that
20:54:09NimBotnimrod-code/nimbuild master edddfa0 Dominik Picheta [+0 ±1 -0]: Fix last incorrect change.
20:57:59NimBotnimrod-code/nimbuild master c563a04 Dominik Picheta [+0 ±1 -0]: Reintroduce gcsafe.
20:59:11NimBotAraq/Nimrod sigpipe 9428bed Simon Hafner [+0 ±2 -0]: Fixes #1168
21:03:24EXetoCdom96: what do I add to outerProcBody?
21:04:55dom96EXetoC: returnType[1] I think
21:10:50*fowl quit (Quit: rebooting)
21:13:23*Dispatch joined #nimrod
21:13:47Dispatchhello
21:14:10dom96hi Dispatch
21:14:28DispatchI have a question
21:14:40Dispatchwhen I add --debugger:on to the nimrod command
21:14:41DispatchI get:
21:14:51Dispatchlib/core/typeinfo.nim(113, 22) Error: type mismatch: got (PNimType) but expected 'PNimType'
21:15:24Dispatchwithout the debugger on it compiles ok
21:20:51dom96Sadly I think the debugger is broken.
21:21:03Jehan_Hmm, it works for me right now?
21:21:22Jehan_At the very least I can compile with --debugger:on and I can run the code from it.
21:21:57reactormonkwhich system are you two on?
21:22:14Jehan_Hmm, may be an OS thing. Running this on OS X.
21:22:21DispatchI am on this one: nimrod_0.9.4_linux_amd64
21:22:33EXetoCdom96: does this look right? var retType = if returnType.kind == nnkEmpty: newIdentNode("void") else: returnType[1]
21:22:46EXetoCit works
21:23:53dom96EXetoC: sure, but call it subRetType or subtype or returnSubtype
21:25:00Jehan_Hmm, Linux works for me, too. Odd.
21:25:27DispatchI am using opengl could that have anything to do with it?
21:25:28Jehan_Maybe something specific about the source that causes compilation of the debugger code to fail?
21:25:40dom96Jehan_: Are you using 0.9.4?
21:25:40Jehan_Hmm. Does it work when compiling an empty file?
21:25:57Jehan_On OS X, I've tried both 0.9.4 and devel.
21:25:57Dispatchyes, 0.9.4, let me check an empty file
21:26:14Jehan_On Linux, I've got only devel available right now.
21:28:22Dispatchok, simple hello world works
21:28:40DispatchI'll try building up the code, see where it fails
21:28:43Dispatchthx for now!
21:28:48Jehan_Hmm. Looks like a module confuses the type system.
21:30:05Dispatchbtw, it was also a problem in 0.9.3, I upgraded because of it
21:30:14DispatchI'll let yo know if I find out more
21:32:44EXetoCdom96: so I should just omit the discarded string if I just want to make sure that a test compiles?
21:33:37dom96EXetoC: I think so, run the tester on the category you added the test to.
21:33:46dom96I'm assuming async so: koch tests cat async
21:33:57dom96To make sure it works
21:34:05EXetoCit does. just wanted to make sure
21:36:57*Dispatch quit (Quit: Page closed)
21:37:27*Jehan_ quit (Quit: Leaving)
21:40:46EXetoCI've create a PR
21:41:04EXetoCwait
21:42:05EXetoCno I tested the whole category so nvm
21:43:34dom96thanks
21:51:05NimBotAraq/Nimrod devel 8802688 EXetoC [+1 ±1 -0]: Fix #1171.
21:51:05NimBotAraq/Nimrod devel 05712fe Dominik Picheta [+1 ±1 -0]: Merge pull request #1173 from EXetoC/pfuture-nested-type-param... 2 more lines
22:02:08EXetoCnp dude
22:22:45*Demos joined #nimrod
22:42:51skyfexis zaharay = zah on github?
22:44:38dom96yeah
22:46:55*fowl joined #nimrod
22:50:29*Demos quit (Ping timeout: 245 seconds)
22:55:12*Demos joined #nimrod
22:55:27*skyfex quit (Quit: Computer has gone to sleep.)
22:57:40*enurlyx quit (Quit: Nettalk6 - www.ntalk.de)
23:01:47EXetoCdom96: node.kind == nnkDiscardStmt doesn't correspond do "discard await x" which is what the comment implies. do I just ignore it?
23:03:53dom96EXetoC: That's what the AST begins with if I dumpTree that expression
23:06:38EXetoCok I need to add another check
23:11:56*runvnc quit (Quit: WeeChat 0.4.1)
23:15:50EXetoCdom96: does that call to createVar do anything useful?
23:15:55*darkf joined #nimrod
23:16:15dom96EXetoC: of course
23:16:39dom96in fact, it's very important
23:17:10EXetoCI mean in this case. I'm trying to figure out when it matters
23:19:10EXetoCthe one on line 872
23:21:51dom96you're fixing your other issue right?
23:21:57EXetoCyes
23:22:43EXetoCI've added "node[0].kind != nnEmpty", which fixes it, but now I'm just looking at that
23:22:44dom96because there is no 'await' the discard shouldn't be transformed
23:22:58dom96so code shouldn't reach createVar
23:27:16EXetoCit works now but I still wanted to know if that branch actually does anything to the semantics
23:29:22dom96yeah, that should do it.
23:29:44dom96Take a look at createVar
23:29:48dom96It's pretty simple
23:29:57fowlliteral dice roll: proc d* (max: int): int = random(max)+1
23:30:07dom96if you want to see what code it generates uncomment line 990
23:30:20fowlecho "2*d6: ", d 6, d 6
23:34:13EXetoCdom96: "discard [indent] var future = f(); yield future; future.read" -> "var future = f(); yield future; discard future.read"
23:36:21dom96EXetoC: what?
23:36:57EXetoCdom96: with and without the call to createVar
23:37:49dom96EXetoC: yep, that's correct
23:38:04EXetoCare those semantically different?
23:38:20dom96no, the former won't compile.
23:38:32EXetoCboth compile
23:39:00dom96huh
23:39:16dom96I suppose they are the same then
23:39:35dom96in the former the whole block is discarded
23:39:50dom96but that's equivalent to discarding the last statement in the block
23:40:03EXetoCI'll just adhere to "don't fix what's not broken"
23:41:05dom96sure, it certainly shows nimrod's flexibility.
23:42:08EXetoCit must be the output that is wrong
23:43:08dom96hrm?
23:43:40EXetoCit doesn't compile if you put it in a module
23:46:02dom96where did you put it before?
23:46:21EXetoCit was the output of that echo
23:47:12dom96The fact that the code is output does not mean that it is correct.
23:47:41dom96So the former is not correct.
23:53:11*oxful_ joined #nimrod
23:53:32*oxful quit (Read error: Operation timed out)
23:53:45EXetoCdunno what it compiles to then
23:57:44dom96that is what it compiles to