| 00:00:17 | Araq | BitPuffin: I fixed EXetoC's babel package |
| 00:00:20 | BitPuffin | dom96: yes and I have nothing on my plate, good plan there |
| 00:00:27 | filwit | lol, still laughing from the first one BitPuffin |
| 00:00:28 | Araq | (don't remember the name) |
| 00:00:38 | BitPuffin | Araq: the glfw one? |
| 00:00:48 | EXetoC | yes |
| 00:00:49 | Demos | Varriount, you want me to compile that code with VCC? |
| 00:01:17 | Varriount | Demos: And debug it, if it crashes, yes |
| 00:01:24 | BitPuffin | Honestly I don't even know what caused the bug because the error wasn't saying anything useful like oh, which line it went south |
| 00:01:31 | BitPuffin | but I'll try it with the latest |
| 00:01:52 | Discoloda | i need to watch SG-1 again |
| 00:02:12 | Araq | Discoloda: StarGate? |
| 00:02:13 | Varriount | Since you are the only one here who has a chance of getting a look into what is going wrong with getcompletionqueuestatus |
| 00:03:02 | Discoloda | Araq: yes |
| 00:03:48 | BitPuffin | filwit: We are watching the programming landscape and it looks like Rod is just penetrating its way into the community |
| 00:04:23 | filwit | BitPuffin: there's so much gold to that idea, it would be hilarious, lol |
| 00:04:52 | Demos | I am really quite opposed to changeing the name |
| 00:04:57 | Discoloda | Araq: i think a language called "Zero Point Module" would be nice, shortened to "zpm". thought of it when you mentioned Stargate |
| 00:05:13 | BitPuffin | raphics/terrain.nim(70, 31) Info: instantiation from here |
| 00:05:15 | BitPuffin | lib/system.nim(698, 9) Error: type mismatch: got (array[0..999999, TVec3], nil) |
| 00:05:17 | BitPuffin | but expected one of: |
| 00:05:27 | BitPuffin | <long list> believe that was the same error as before |
| 00:06:29 | Araq | Discoloda: there is no point in zero point though ;-) |
| 00:07:17 | BitPuffin | actually the error kind of makes sense |
| 00:07:23 | BitPuffin | Which the last one didnlt |
| 00:07:59 | BitPuffin | So I guess you fixed it Araq :) nice |
| 00:08:21 | Araq | no, zahary did, most likely |
| 00:08:27 | Discoloda | Araq: that makes it sound meta |
| 00:08:47 | BitPuffin | ah |
| 00:09:11 | Araq | Discoloda: anyway, stop watching SG1, work on quake 2-3 instead :P |
| 00:09:45 | BitPuffin | so quake -1 |
| 00:10:19 | Discoloda | Araq: heh. im considering parsing a proper AST for C, then convert that to Nimrod AST |
| 00:10:40 | Demos | changeing the name is a really bad idea... I think the name is different enough to sick out, and reflects how nimrod does things in interesting ways that break from the C/Simula derived mainstream languages |
| 00:10:53 | Demos | Discoloda, break out the libclang yo! |
| 00:11:17 | Discoloda | you can get a AST from clang? |
| 00:11:22 | Demos | I think so |
| 00:11:27 | Demos | one for c++ even |
| 00:11:31 | Araq | Discoloda: I considered that too and came to the conclusion it's worthless |
| 00:11:41 | Araq | just patch the nimrod AST afterwards |
| 00:11:43 | dom96 | I think that if **Dr Dobbs** doesn't mind putting Nimrod on their cover letter that the name is really fine. |
| 00:11:47 | Araq | no need for 2 ASTs |
| 00:14:05 | Demos | right. C is simple enough for that to work. It may make c2nim accept more source files though, since right now there is a good chance of it rejecting the code you give it |
| 00:14:26 | Discoloda | other than c2nim, the C AST can then have a API, for doing transformations on C with Nimrod. like https://github.com/eliben/pycparser or http://hackage.haskell.org/package/language-c-0.3.1.1/docs/Language-C-Syntax-AST.html. both the C AST library and c2nim should be babel packages. right? |
| 00:15:45 | Demos | right, however we probably would want to build that API on already existing tools (libclang) which pulls in a whole slew of dependencies, not sure how babel handles c++ deps |
| 00:17:11 | Varriount | God.. no... no autoconf.. *whimper* |
| 00:17:13 | Araq | Discoloda: people won't accept it anyway |
| 00:17:31 | Araq | they will tell you should (lib)clang instead |
| 00:17:38 | BitPuffin | that's true actually, c2nim (+ endb etc) _should_ be babel packages no? |
| 00:18:02 | Araq | BitPuffin: I guess |
| 00:18:31 | Demos | LLVM uses cmake afaik |
| 00:18:43 | Araq | Discoloda: in fact, perhaps you should use (lib)clang and make clang2nim |
| 00:18:47 | BitPuffin | Araq: since you don't wanna end up as disorganized as fowl ;) |
| 00:19:28 | Araq | I was annoyed by the long compile times of LLVM and the enterprisey API, so I wrote my own C parser |
| 00:19:46 | dom96 | Yes. nimgrep, niminst and everything in tools/ should be a babel package too. |
| 00:19:56 | dom96 | The website should be split into a separate repo too. |
| 00:20:14 | Araq | which was more fun anyway plus I could tweak it for my purposes |
| 00:20:25 | dom96 | Anyway, good night. |
| 00:20:58 | Demos | Araq, libclang does not look /that/ bad on first inspection, but I agree that the compile times are pretty bad |
| 00:21:37 | Demos | then again I think that once you add GCC extensions, MSVC extensions, parsing for nonstandard stuff, and c++ things get big |
| 00:22:12 | Demos | I would really like the c parser in c2nim to actually parse 99.9% of source files, which it does not currently |
| 00:22:56 | Araq | dunno, I try to clean up everything anyway |
| 00:23:14 | Araq | so fixing the C or the produced nim makes little difference |
| 00:24:35 | BitPuffin | wat, clang compiles waaaAAAAAy faster than GCC in my experience |
| 00:24:47 | Demos | right, but it is nice to be able to generate the nim file directly from the C header with little changes, then change stuff in nimrod |
| 00:24:58 | Demos | BitPuffin, I have not found that to be the case |
| 00:25:13 | Demos | although it depends on what compile options you have |
| 00:25:21 | BitPuffin | Demos: I guess |
| 00:25:25 | Demos | I hear disableing all xcompalation helps a lot |
| 00:25:27 | BitPuffin | Demos: either way it's a way better compiler imo |
| 00:25:41 | BitPuffin | Demos: since it nice with pointing out where things went wrong |
| 00:25:43 | Demos | clang actually tells you its progress though, which is nice |
| 00:25:57 | Demos | gcc is getting much better as well |
| 00:26:11 | Demos | but yeah, clang is badass |
| 00:26:24 | BitPuffin | at least as badass as a c compiler can be |
| 00:26:32 | * | aruniiird joined #nimrod |
| 00:26:56 | Demos | heh writing a c++ compiler from scratch like they did is no small taks |
| 00:26:58 | Demos | *task |
| 00:27:16 | EXetoC | sounds like a fun weekend project |
| 00:27:30 | filwit | Araq: semexprs:733, 'destType' is be declared be never used.. what am i missing? |
| 00:27:39 | filwit | Araq: any hints? |
| 00:27:50 | filwit | Araq: trying to hunt my OOP bug down again |
| 00:28:04 | * | adoniscik joined #nimrod |
| 00:28:23 | filwit | just wondering what is going on with the code there |
| 00:29:41 | Araq | hi adoniscik welcome |
| 00:29:56 | filwit | Araq: sorry, stupid question, nevermind |
| 00:30:56 | Demos | Varriount, gcc compiles proactor fine but vcc fails with that devide by zero |
| 00:30:56 | adoniscik | Araq, thanks. I came here just to see the community and thank you for the great language. When's 1.0 due? |
| 00:31:06 | filwit | wait.. no it's not, it's just being assigned to something instead of using 'discard' |
| 00:31:08 | Demos | when I run the gcc version I get a bunch of output with lots of []s |
| 00:31:30 | filwit | it builds fine with discard. must have been used at one point and now isn't. |
| 00:31:43 | Varriount | Demos: And it doesn't crash? |
| 00:31:49 | Demos | filwit, I think I may have seen something in the github issues about destType, check the last few issues |
| 00:31:57 | Demos | Varriount, when compiled with gcc no |
| 00:32:07 | filwit | Demos: thanks, i'll check |
| 00:32:14 | Varriount | In both debug and release? What bit-ness? |
| 00:33:00 | Demos | 64bit debug atm |
| 00:33:26 | Demos | whoop release crashes it |
| 00:33:50 | Varriount | Do you get a error or something? |
| 00:34:41 | Demos | just a segfault |
| 00:34:55 | Demos | you said the stacktrace was in msvcrt someplace |
| 00:35:16 | Varriount | Demos: Well, yes, at the call to getQueuedCompletionStatus |
| 00:35:44 | Varriount | However there are no symbols gcc can use to get into those calls, and I can't compile the code with vcc |
| 00:36:27 | Demos | well I can debug it, but I need to generate symbols, so give me a moment |
| 00:36:39 | Demos | my intel command prompt shortcut went and hit |
| 00:36:41 | Demos | *hid |
| 00:36:55 | Araq | adoniscik: 1.0 is december this year ... but it gets more and more unlikely |
| 00:37:39 | reactormonk | Varriount, http://dpaste.com/1576055/ |
| 00:37:41 | reactormonk | not sure if it works |
| 00:38:56 | * | Varriount quit (Quit: Leaving) |
| 00:39:18 | * | Varriount joined #nimrod |
| 00:39:44 | Varriount | Hrm |
| 00:40:18 | Varriount | Araq: Under what circumstances are arguments to procedure calls copies? |
| 00:41:08 | Demos | Varriount, if you put the pragma or if the compiler feels like it |
| 00:41:23 | Demos | with some possible FFI exceptions |
| 00:42:22 | Demos | araq will have to say what the compiler actually does. But I asked him a while ago if the compiler decides for you for regular : T params and he said it did |
| 00:42:47 | Varriount | Ok, that's what I thought |
| 00:43:07 | Varriount | So you should be careful if you try to get the address of a parameter |
| 00:44:10 | Demos | yeah |
| 00:44:25 | filwit | if i'm trying to fix bugs related to macro/templates, should I be hacking on devel or vm2? |
| 00:44:32 | Araq | no. why? you can't take the address of a parameter |
| 00:44:33 | Varriount | filwit: devel |
| 00:44:36 | Demos | and you should not modify the value of something passed like that ever, so taking a pointer is pointless |
| 00:44:41 | filwit | Varriount: k |
| 00:44:52 | Demos | thank you filwit! |
| 00:45:04 | filwit | Demos: for what? |
| 00:45:28 | Demos | for trying to fix all the macro bugs |
| 00:46:09 | filwit | Demos: ah, well i'm mostly trying to fix the ones related to my project |
| 00:46:51 | filwit | Demos: but once i get a bit more familiar with hacking on the compiler i might try and tackle a few things from the bug list |
| 00:51:39 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 00:53:14 | * | BitPuffin joined #nimrod |
| 00:55:46 | Varriount | Demos: How goes the debugging? |
| 00:57:31 | Demos | I needed to reinstall icc, since I removed it a while back when it broken visual studio |
| 00:57:48 | Varriount | Demos: Can you test out a binary for me? |
| 00:58:09 | Demos | I have the binary, I need icc to make debug symbols |
| 00:58:24 | Demos | let me try running the gcc generate binary through windbg |
| 00:58:53 | filwit | from macros, what's the difference between nnkIdent(!"..") and nnkIdent("..") ? |
| 00:59:15 | filwit | what does the '!' do? |
| 01:00:00 | * | adoniscik quit (Quit: Leaving) |
| 01:00:03 | EXetoC | proc `!`*(s: string): TNimrodIdent {.magic: "StrToIdent".} |
| 01:00:45 | filwit | thanks |
| 01:03:19 | Araq | fyi '!' existed before ident"foo" was valid syntax ... |
| 01:03:36 | Araq | nowadays I wouldn't make that an operator |
| 01:05:16 | Varriount | Would would happen if you pass a 'ref' to a native os call, instead of a ptr? |
| 01:05:57 | filwit | Araq: i wasn't going to comment, lol |
| 01:06:16 | filwit | Araq: but they do different things though, ident".." returns a PNimrodNode |
| 01:10:51 | Varriount | Demos: While you wait for intel to setup, please test this binary -> https://drive.google.com/file/d/0B077nrrf63xtMmwyeUJvaXpJQ00/edit?usp=sharing |
| 01:11:38 | Demos | the 32bit one seems to work, the 64bit one not so much |
| 01:11:55 | Varriount | Another segfault? |
| 01:12:06 | Demos | prolly |
| 01:16:32 | Varriount | Demos: How about now -> https://drive.google.com/file/d/0B077nrrf63xtZjBtcjdFSEhWLWs/edit?usp=sharing |
| 01:16:58 | filwit | Araq: any tips on debugging the VM?.. my whole stack trace is just "gen, gen, gen, genIf, gen, etc.." |
| 01:17:46 | filwit | Araq: can't tell exactly which part of my code is causing the VM to crash, and I need the whole thing intact or I'll cause a totally different crash cause the AST isn't setup right.. |
| 01:19:58 | Demos | the 32 one works the 64 does not |
| 01:20:09 | Araq | filwit: give me the stack trace please |
| 01:24:35 | filwit | Araq: it's alright man, i'm not trying to take up all your time. I'm sure i can figure it out myself, just wanted to know if you had any way you usually do it. Here's the stack trace just in case: https://gist.github.com/PhilipWitte/8700931 |
| 01:26:24 | Araq | filwit: ah that thin, you can disable this internal error and see if that already fixes it |
| 01:27:02 | filwit | Araq: not sure what you're suggesting. How to disable internal errors? |
| 01:27:59 | filwit | Araq: now that i take a second look, i can kinda see which part of my macro (which calls a compile-time proc) is messing up, based on the trace |
| 01:29:00 | Araq | hymn.nim(14, 4) ... |
| 01:29:31 | filwit | oh, what? damn how did i miss that... |
| 01:29:42 | filwit | thanks |
| 01:30:09 | Varriount | Araq: This is going to sound redundant, but is there anyway to compile a program in release mode, but retain stack traces? |
| 01:30:10 | filwit | seriously feel kinda retarded now though, so yeah |
| 01:31:30 | Araq | Varriount: you can explicit turn on stack traces but every other check off |
| 01:31:39 | Demos | Varriount, I think in gcc it is -g -O3 |
| 01:31:59 | Demos | for the C compiler, which may be enough |
| 01:32:03 | Araq | oh yeah gdb has its own stack traces, right |
| 01:32:09 | Araq | --lineDir:on |
| 01:32:30 | Varriount | Demos: I think I found a bug, if not *the* bug that's causing the segfault. |
| 01:33:03 | Demos | oh, damn I was just getting set up. I think. I lost my train of actions when like 40 things started happening. |
| 01:33:26 | Varriount | Demos: Huh? |
| 01:34:17 | Demos | I am working on math homework, being pestered by people on steam, dealing with email, getting icc working, and getting the debugger installed all at the same time. |
| 01:37:09 | Araq | good night |
| 01:39:26 | Demos | I am getting symbols when it breaks before starting main but once the segfault happens I get nothing |
| 01:40:36 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 01:42:40 | Demos | shit compileing with --cc:icl -d:release works |
| 01:42:44 | Demos | for the version you gave me |
| 01:43:01 | * | DAddYE quit (Remote host closed the connection) |
| 01:43:37 | * | DAddYE joined #nimrod |
| 01:46:26 | Demos | hm what is the nimrod command to generate nim code in c comments |
| 01:46:59 | * | aruniiird quit (Quit: Leaving) |
| 01:47:44 | Demos | what was the bug you found? |
| 01:48:35 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 01:54:21 | Varriount | Demos: Allocation bug |
| 01:54:40 | Demos | where |
| 01:54:59 | Varriount | Around line 255 |
| 01:55:03 | Varriount | in proactor.nim |
| 01:55:44 | Varriount | An "Overlapped" structure is being allocated on the stack, and then it's address is sent to the connectEx api call |
| 01:56:39 | Varriount | When getQueuedCompletionStatus is later called, the address will point to a deallocated piece of memory |
| 01:57:14 | Varriount | That is, getQueuedCompletionStatus will set one of it's arguments to the address previously passed in |
| 01:58:48 | Varriount | The binaries I gave you fixed that bug (I stored the overlapped object in a sequence, in a Proactor object |
| 01:59:57 | Demos | which binaries |
| 02:00:10 | Demos | the newest ones, because if I recall they still had problems |
| 02:00:15 | Varriount | Yeah |
| 02:00:27 | Varriount | Demos: Let me just give you the updated code |
| 02:01:05 | Varriount | Demos: https://gist.github.com/Varriount/5ec6370dd37bb51cd947 |
| 02:01:11 | Varriount | Only proactor.nim is changed |
| 02:01:36 | Demos | https://gist.github.com/barcharcraz/d7836e3c2d7a497472a9 <--- memory analysis in case you care |
| 02:02:01 | Varriount | Demos: Woah, what program generated that? |
| 02:03:45 | Demos | Intel Inspector, I am 85% sure I can use the license I have (student) to analyze your code, as long as you don't pay me for it |
| 02:04:08 | Demos | and I compiled the new sources with gcc, segfualt ahoy |
| 02:04:17 | Varriount | And the line? |
| 02:04:39 | Demos | frozen bash please wait |
| 02:04:45 | Varriount | O_o |
| 02:09:22 | Varriount | Demos? You there? |
| 02:09:25 | Demos | yeah |
| 02:09:34 | Demos | gdb does not give any debug information... ever |
| 02:09:40 | Demos | or rather gcc does not |
| 02:10:13 | Varriount | You have to use --linedir:on --debuginfo for nimrod debug info |
| 02:10:39 | Demos | I did not |
| 02:10:55 | Demos | still nothing |
| 02:11:04 | Demos | I am compileing in -d:release, but I need to otherwise it works |
| 02:11:28 | Varriount | Demos: Try --passc:"-g" for c info |
| 02:11:58 | Demos | still nothing |
| 02:16:45 | Varriount | Demos: You could compile them yourself, and omit the "-O3" line |
| 02:17:17 | Demos | hm good idea |
| 02:23:26 | Demos | if I give gdb the "info functions" command it returns everything I would want |
| 02:23:43 | Varriount | Huh? |
| 02:24:38 | Demos | yeah debug symbols are not the problem |
| 02:25:14 | Varriount | Then.. stack traces are? |
| 02:25:24 | Demos | yeah |
| 02:25:34 | Varriount | Gah. |
| 02:26:28 | Varriount | Demos: So intel compiler won't use the debug symbols? |
| 02:26:40 | Varriount | Er, the windows debug symbols? |
| 02:26:53 | Demos | the intel compiler can generate windows debug symbols just fine, but it will not generate code that crashes |
| 02:27:10 | Demos | idea |
| 02:28:13 | Varriount | ? |
| 02:33:00 | Demos | try and find the symbol corosponding the the memory address in the executable containing the intruction that caused the segfault, but gcc does not have that symbol or else it would just show it |
| 02:37:43 | Varriount | Demos: I have no idea how to do that (and it might not work for me, seeing as all of the binaries work for me) |
| 02:38:09 | Demos | yeah it is the 64bit binary that fails for me |
| 02:38:12 | Demos | built with gcc |
| 02:38:29 | Varriount | What version gcc do you have? |
| 02:38:47 | Demos | mingw-w64-i686-gcc 4.8.2-6 (mingw-w64-i686-toolchain mingw-w64-i686) |
| 02:41:13 | Varriount | Demos: You're using a 32 bit compiler on a 64 bit machine? |
| 02:41:41 | Demos | what? that is a 64bit compiler |
| 02:42:02 | Demos | wait I have the 64bit one as well |
| 02:42:03 | Varriount | 'i686'? |
| 02:42:16 | Demos | sorry I have both installed |
| 02:42:33 | Demos | using mingw-w64-x86_64-gcc 4.8.2-6 (mingw-w64-x86_64-toolchain mingw-w64-x86_64) |
| 02:42:48 | Varriount | How did you get that specific printout? |
| 02:44:00 | Demos | pacman -Qs gcc |
| 02:44:30 | Varriount | And I could have sworn pacman was meant for arch linux. |
| 02:44:43 | Demos | msys2 uses it as well |
| 02:45:02 | Demos | I personally have built it on arch (ofc) macOS 10.9, and RHEL |
| 02:45:08 | Varriount | Oh, there's an msys2 out now? |
| 02:45:18 | Varriount | I just have silly msys |
| 02:45:19 | Demos | in beta |
| 02:45:34 | Demos | msys64 does the same thing, using gcc-4.8.1 |
| 02:45:41 | Varriount | So, what do we do know? |
| 02:46:21 | Demos | it works in clang 3.4 but never gets to the polling thing |
| 02:46:32 | Varriount | Oh? What happens? |
| 02:46:33 | Demos | oh wait yes it does |
| 02:46:44 | Demos | msys2's console was just being bad |
| 02:47:37 | Demos | also for the gcc build that fails intel inspector reports an invalid memory access at address 1398B |
| 02:47:57 | Demos | which contains: or qword ptr [rcx], 0x0 |
| 02:48:03 | * | DAddYE joined #nimrod |
| 02:48:09 | Varriount | So, a nil pointer? |
| 02:48:18 | Demos | right, or invalid memroy |
| 02:48:40 | Demos | but yeah |
| 02:48:56 | Demos | note that I do not know x86 assembly |
| 02:49:51 | Varriount | Maybe I could set the program to repeatedly connect and disconnect |
| 02:50:02 | Varriount | That might cause the bug to pop up again |
| 02:50:11 | Varriount | That is, again for me |
| 02:52:00 | Varriount | Demos: Any idea why for some procedures you can pass 'nil' as an argument, but not others? |
| 02:52:44 | EXetoC | the literal? are they vars? |
| 02:52:53 | Varriount | literal |
| 02:52:55 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 02:54:18 | Varriount | Demos: Add echos around the getQueuedCompletionStatus call, and any other interesting areas |
| 02:55:11 | EXetoC | I don't know if it fails at compile-time, but if the param is a var then you need to pass in one |
| 02:56:29 | Varriount | EXetoC: This is a wrapped procedures. I'm calling CreateIOCompletionPort, and can't pass in nil to the key params |
| 02:57:08 | Varriount | The key parameter is a ptr to a ptr to a int32 |
| 02:58:25 | Demos | can you cast[ptr ptr int32](0) or something like that? |
| 02:58:39 | Varriount | Is that the same as nil? |
| 02:59:15 | Demos | well... actually I dont think it is garenteed by the C standard. But on any modern system that has an OS it will be |
| 02:59:49 | * | DAddYE joined #nimrod |
| 03:00:02 | Demos | and zero will convert to a null pointer |
| 03:00:05 | Demos | in C |
| 03:00:07 | EXetoC | no csize(0) needed? |
| 03:00:30 | Demos | why would you need that? |
| 03:00:59 | Varriount | Demos: I wonder if it would be possible to add a getlasterror call to the signal handlers |
| 03:01:53 | Varriount | Demos: Also, have the echo statements revealed anything? |
| 03:02:09 | Demos | no, I need to finish this math, it is due at midnight |
| 03:02:15 | Demos | but let me try a quick thing first |
| 03:02:17 | Varriount | Ah, I see |
| 03:03:55 | Demos | you using winsock? |
| 03:04:09 | Varriount | Demos: Yes |
| 03:06:31 | Demos | no dice |
| 03:06:38 | EXetoC | I just forgot about the difference between int in C and Nimrod |
| 03:06:54 | Varriount | EXetoC: What? |
| 03:13:42 | Varriount | EXetoC: Do you have a windows machine available,real or virtual? |
| 03:15:36 | EXetoC | Varriount: no |
| 03:20:54 | Demos | hey it says "setting callback with key: nnn" before crashing, what is that? I notice the number changes based on compile settings |
| 03:21:31 | Varriount | Demos: The number is the socket |
| 03:21:42 | Demos | oh, so it is just picking a differnt socket |
| 03:21:46 | Demos | false alarm |
| 03:21:53 | * | Demos does not know much about networking |
| 03:22:01 | Varriount | Demos: Funny, that's the place where nimrod's gcassertions fail when I turn them on |
| 03:22:40 | EXetoC | debugging socket stuff? |
| 03:22:50 | Varriount | EXetoC: Sorta |
| 03:23:44 | Demos | I mean the crash is in between there and the next time output happens |
| 03:24:18 | Varriount | Demos: Can you add an echo right after the last line on setcallback? |
| 03:24:27 | EXetoC | fun fun fun |
| 03:24:32 | EXetoC | happy coding. cya |
| 03:25:10 | Demos | yeah it gets hit |
| 03:25:23 | Varriount | The echo on the last line? |
| 03:25:30 | Demos | mmhmm |
| 03:25:36 | Demos | what calls that setCallback function |
| 03:25:50 | Varriount | Line 272 |
| 03:26:07 | Varriount | The connect procedure |
| 03:26:55 | Varriount | Demos: If you need to finish your homework, go ahead. I'd hate to keep you from it. |
| 03:27:40 | Demos | it is just stupid linear algebra computation problems... not very hard, not very easy to focus on |
| 03:29:32 | Demos | OK p.poll on line 327 is on the callstack of the crash |
| 03:30:15 | Varriount | Demos: Well, yes, however that's the procedure call of the poll procedure |
| 03:30:32 | Demos | I figured |
| 03:30:53 | Demos | the callstack gdb gave me only had 2 functions on it, although it looked pretty garbled |
| 03:31:15 | Varriount | What was the callstack? |
| 03:32:02 | Varriount | New version of the proactor.nim file. Fixed possible cast errors -> https://gist.github.com/Varriount/5ec6370dd37bb51cd947 |
| 03:32:16 | Demos | wowah more functionz |
| 03:32:33 | Varriount | ? |
| 03:32:52 | Demos | on gcc's callstack |
| 03:33:05 | Varriount | Gist? |
| 03:33:29 | Demos | no meaningful even with debug info they are like 0x0000ajsfhlakfhelk in ?? () |
| 03:34:49 | Demos | still broken |
| 03:35:21 | Varriount | Darn |
| 03:35:35 | Demos | what windows fucntion is GetCompletionStatus calling |
| 03:35:55 | Varriount | That is the windows function |
| 03:43:04 | Varriount | Demos: can you change "statusOverlappedPtr" at around line 160 to point to an actual overlapped object? |
| 03:43:18 | Varriount | So that it looks something like |
| 03:43:20 | Varriount | statusOverlapped: Overlapped |
| 03:43:20 | Varriount | statusOverlappedPtr = addr statusOverlapped |
| 03:44:10 | Demos | where is StatusOverlapped? |
| 03:44:21 | Varriount | No where, I added it |
| 03:47:28 | Demos | it is an out param, and since it does not crash on debug builds... |
| 03:49:49 | Varriount | I'm just at my wits end on what to do. |
| 03:52:30 | Demos | YES! I have it so that it runs fine when just run regularly (using gcc x64 and so on) but crashes under appverifier |
| 03:52:47 | Varriount | appverifier? |
| 03:53:14 | Varriount | What did you change? |
| 03:53:40 | Demos | nothing, I just realized that I had it running with appverifier on |
| 03:53:48 | Demos | appverfier tells windows to be mean to a process |
| 03:54:01 | Demos | like allocateing stuff at the end of pages and stuff |
| 03:55:06 | Varriount | and...? |
| 03:55:48 | Varriount | But appverifier wasn't running when you ran the binaries I gave you, was it? |
| 03:59:34 | Demos | no it was. I think the appverifier just sets some registry settings |
| 04:00:34 | Varriount | Demos: But should we be worried that it crashes under appverifier? |
| 04:00:42 | * | DAddYE quit () |
| 04:01:57 | Demos | well yeah, but crashes are good |
| 04:02:06 | Demos | we are closeing in on the prey |
| 04:02:17 | Varriount | Wait, I think I misunderstand |
| 04:02:43 | Varriount | So, you can now get it crash.. when? In debug mode? |
| 04:02:56 | Varriount | And is this because appverifier is off, or on? |
| 04:05:35 | Demos | it is built in debug but with --opt:speed |
| 04:05:55 | Demos | and if appverifier is on, does not matter what options, it crashes |
| 04:06:24 | Varriount | And the stack trace? |
| 04:07:20 | Demos | well we know the stack trace |
| 04:07:44 | Demos | it crashes at line 162 after poll has been called from the main loop |
| 04:08:34 | Varriount | Demos: Does it crash with icc? |
| 04:08:57 | Varriount | If it does, you can use the windows debug symbols (I think?) |
| 04:09:33 | Demos | nope |
| 04:09:48 | Demos | like I said though, not terrably useful |
| 04:10:24 | Varriount | So how do you think we should precede? |
| 04:10:59 | Demos | OK I got a breakpoint right before the crash |
| 04:11:16 | Demos | wowah I got an appverifier stop |
| 04:11:25 | Varriount | Is that good? |
| 04:12:32 | Demos | well we know that it crashes when I set a breakpoint as well as when I do not, which is nice |
| 04:14:34 | Demos | https://gist.github.com/barcharcraz/437db6c66b1c3f7c7ade <--- crash analysis |
| 04:18:09 | Varriount | Wow, that text at the top seems almost friendly |
| 04:18:58 | Varriount | Demos: It's odd that it says that there were only 2 parameters |
| 04:20:07 | Demos | I think those are params for the Access Violation Exception |
| 04:20:21 | Demos | also known in the unix world as SIGSEGV |
| 04:22:40 | Varriount | Demos: What we don't know is if it was a sub-call in the GetQueuedCompletionStatus code that did it, or a parameter, ir what |
| 04:23:11 | Demos | it was probably a parameter |
| 04:23:30 | Demos | or some kind of callstack thing |
| 04:24:48 | Demos | lets not assume that the windows API is broken |
| 04:24:54 | Varriount | Well, it said it was a *write* access failure |
| 04:25:08 | Varriount | So.. something in one of the 'out' parameters? |
| 04:26:02 | Demos | maybe, we should figure out where in memory each thing is, what registers things are going into, and what is passed where |
| 04:27:45 | Varriount | The thing is, I explicitly took each address parameter from a newly created object, so none of them should be null |
| 04:29:19 | Demos | yeah, I suspect that it is some kind of invalid sized thing, since it is so sensitive to compile options |
| 04:29:29 | Demos | like enableing endb makes it not crash |
| 04:30:24 | Varriount | If only stupid VS would compile things right. |
| 04:30:27 | Demos | you said there were GC assertions getting thrown |
| 04:30:34 | Demos | well this is gcc being bad |
| 04:32:05 | Varriount | Demos: Yeah, but the assertions are in a completely unrelated place. When an entry is being put into the table for a callback |
| 04:32:32 | Demos | what if there is a memory error there and we are getting garbage from the table |
| 04:33:33 | Varriount | Well, let me see if I can remove the table from the equation. |
| 04:34:54 | Varriount | Demos: Does seq type have a find proc? |
| 04:36:46 | Demos | I have no idea, I really wish procs like find could be written seperately from the data structure |
| 04:37:04 | Varriount | Demos: They can |
| 04:37:23 | Demos | right in terms of `[]` |
| 04:37:27 | Varriount | Actually, there is a find, its needed for 'x in y' |
| 04:37:48 | Demos | so can't you just use that one |
| 04:39:28 | Varriount | No, I think I can |
| 04:39:41 | Varriount | Use two seqs, one for keys, one for data |
| 04:40:02 | Varriount | only one key:data pair is added, so indexes will be the same |
| 04:40:53 | Varriount | Demos: Updated gist - https://gist.github.com/Varriount/5ec6370dd37bb51cd947 |
| 04:41:01 | Demos | wowah just noticed tests/showoff/tdrdobbs_examples.nim |
| 04:42:19 | Demos | are the gc asserts fixed |
| 04:42:55 | Demos | the error is different |
| 04:43:09 | Varriount | Which error? |
| 04:43:31 | Demos | a segfault |
| 04:44:29 | Demos | it only happens with -d:release now, not with --opt:speed |
| 04:45:05 | Demos | the stacktrace seems different as well |
| 04:45:13 | Varriount | Demos: The GC assert happens on line 152 |
| 04:45:18 | Demos | still |
| 04:45:20 | Demos | ? |
| 04:45:24 | Varriount | Yeah |
| 04:45:32 | Varriount | When the key is added |
| 04:45:50 | Demos | look, fix the GC assert first, since you can repro it, then we will see if my ghost errors are still around |
| 04:50:52 | Varriount | Demos: Fixed the gc assert |
| 04:50:58 | Varriount | Gist is at the same link |
| 04:52:15 | * | psquid quit (Ping timeout: 272 seconds) |
| 04:53:06 | * | psquid joined #nimrod |
| 04:57:34 | Varriount | Demos? |
| 04:58:34 | Demos | yeah, realized I forgot a math problem, solved it at 11:58, due at 11:59 |
| 04:59:31 | Demos | nuts |
| 04:59:40 | Demos | still segfaults |
| 05:02:15 | Varriount | Demos: Is it possible to turn off divide by zero tracking for vcc? |
| 05:03:01 | Demos | I dont think it is an option |
| 05:03:09 | Demos | it is a bug in VC's preprocessor |
| 05:03:30 | Demos | now one may be able to run cpp from mingw on the files then turn them over to vcc for actual compilation |
| 05:03:53 | Varriount | Oh, in the preprocessor? It's easy to preprocess the files |
| 05:04:03 | Demos | I /think/ |
| 05:04:19 | Demos | I kinda doubt it would help |
| 05:05:41 | Demos | I should go to sleep. I have to be presentable tomorrow |
| 05:05:55 | Varriount | Yeah, I do too |
| 05:06:10 | Varriount | Thanks for your help Demos, I really appreciate it |
| 05:06:28 | Varriount | Hopefully this bug can be tracked down |
| 05:06:44 | Demos | yeah, I would say the best way to get this is to just go through the assembly and track where the execution without the bug differs from the one with |
| 05:06:51 | * | dmac joined #nimrod |
| 05:06:59 | Demos | in terms of the values of the params passed into that windows function |
| 05:10:46 | Demos | in a kinda sick way I like these kind of bug hunts because you are always "right about to find it" |
| 05:11:11 | Varriount | I can completely understand that |
| 05:17:21 | * | xenagi quit (Quit: Leaving) |
| 05:21:22 | * | Demos quit (Quit: Leaving) |
| 05:42:17 | * | xtagon quit (Ping timeout: 272 seconds) |
| 05:46:57 | reactormonk | anyone got an idea on lib/system.nim(1627, 7) Error: undeclared identifier: 'data' ? |
| 06:04:45 | * | brson quit (Quit: leaving) |
| 06:05:13 | * | brson joined #nimrod |
| 06:27:40 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 06:51:44 | * | shodan45 quit (Remote host closed the connection) |
| 06:52:03 | * | shodan45 joined #nimrod |
| 06:53:35 | * | BitPuffin joined #nimrod |
| 06:58:30 | * | BitPuffin quit (Ping timeout: 251 seconds) |
| 07:26:52 | reactormonk | ok, WTF. How can both echo(not indexes[x.len-1] == -1) |
| 07:26:55 | reactormonk | echo(indexes[x.len-1] == -1) |
| 07:26:57 | reactormonk | return false? |
| 07:27:09 | reactormonk | parens apparently O.o |
| 07:33:50 | * | zahary joined #nimrod |
| 07:50:38 | * | brson quit (Ping timeout: 264 seconds) |
| 07:51:49 | * | DAddYE joined #nimrod |
| 07:52:27 | * | brson joined #nimrod |
| 07:54:04 | * | brson quit (Client Quit) |
| 08:00:33 | * | brson joined #nimrod |
| 08:08:06 | NimBot | Araq/Nimrod devel 6aef208 Simon Hafner [+1 ±1 -0]: added Cartesian product |
| 08:09:12 | reactormonk | oops. Oh well, it should work. |
| 08:09:56 | NimBot | Araq/Nimrod devel b7079ec Simon Hafner [+0 ±1 -0]: forgot to export product |
| 08:12:37 | filwit | hey zahary, I was wondering if you could look at my pull-request (https://github.com/Araq/Nimrod/pull/849) when you have a moment since's it's a very simple one-liner fix, but, while it fixes all my tests, I'm not familiar with Nimrod AST yet to know if the change I made was best suited to solve the problem (overload existing templated procs, in my example case 'new', with 'typedesc' as a first param). |
| 08:14:26 | filwit | zahary: i'm not trying to be pushy or anything, but I'm eager to know if I made the right decision :) |
| 08:15:20 | filwit | overloading** |
| 08:22:48 | zahary | sorry filwit, I'm on vacation right now and in the little time I spent on the computer I usually have to respond to some issues from work |
| 08:23:03 | zahary | if the fix works for you, just use it and I'll review it at some point |
| 08:23:55 | Araq | zahary: is tfUnresolved supposed to be set for a tyTypeDesc with no son? |
| 08:25:03 | filwit | zahary: no worries, enjoy your holiday :) I'll look forward to your review when it happens. |
| 08:25:28 | * | dmac quit (Quit: Leaving) |
| 08:26:15 | * | ddl_smurf joined #nimrod |
| 08:26:18 | filwit | bbl |
| 08:26:21 | zahary | not exactly, tfUnresolved is set on a type that will be bound during sigmatch. proc foo(T: typedesc, foo: T) |
| 08:26:45 | zahary | T here is skParam with type typedesc with tfUnresolved set |
| 08:28:00 | Araq | ok then filwit's patch is correct I think |
| 08:33:49 | filwit | Araq, zahary: okay, thanks! I'll look into the specifics of what you're talking about to better understand later. |
| 08:35:34 | filwit | though it sounds all pretty straight forward (I can deduce from the names) |
| 08:37:44 | * | vbtt_ joined #nimrod |
| 08:40:31 | Araq | filwit: read all the type sections in ast.nim and you get a good overview |
| 08:41:17 | vbtt_ | so what's the next cool feature of nim(rod) that's in the works and i could blog about? |
| 08:42:24 | Araq | mimic types I guess |
| 08:42:47 | Araq | but I don't think any work on them has started |
| 08:43:11 | Araq | I'm in feature freeze mode, tracking all the hard bugs |
| 08:45:58 | filwit | Araq: k thanks, will do. I'll be gone for a few hours now, bbl |
| 08:46:17 | * | brson quit (Quit: leaving) |
| 08:48:14 | vbtt_ | glad about feature freeze. |
| 08:48:22 | * | vbtt_ goes to look up mimic types |
| 08:50:22 | * | BitPuffin joined #nimrod |
| 08:51:44 | * | zahary quit (Quit: Leaving.) |
| 08:53:11 | Araq | vbtt_: we invented these, I don't think you can "look them up" |
| 08:53:40 | vbtt_ | yeah, my lookups went nowhere. |
| 08:54:05 | vbtt_ | if you don't mind - what is a mimic type? |
| 08:54:33 | Araq | type Foo = mimic string |
| 08:54:43 | Araq | var s: Foo |
| 08:55:33 | Araq | f(s) # f takes a string, but is generalized to Foo here, so f(s) is valid |
| 08:55:59 | Araq | it's a form of post generalization |
| 08:56:18 | vbtt_ | how is it different from a type alias? |
| 08:56:47 | Araq | well the syntax is not finished |
| 08:57:18 | Araq | type Foo = mimic string object |
| 08:57:44 | Araq | data: array[32, char] # fixed size |
| 08:58:22 | Araq | proc len*(s: Foo): int = strlen(s.data) |
| 08:59:04 | Araq | proc `[]`(s: Foo, i: int): char = s.data[i] # Foo supports len and [] like strings |
| 08:59:35 | Araq | f(s) # f only uses 'len' and '[]', so post generalization of 'f' to Foo works |
| 08:59:53 | vbtt_ | i see |
| 09:00:29 | Araq | but it's highly experimental and has lots of issues |
| 09:01:40 | vbtt_ | you have a non-union type, but then after the fact you define another non-union type and consider the original type to be a union type containing the original non-union and the newly defined type. |
| 09:02:02 | Araq | no |
| 09:02:27 | Araq | for me union type implies they share a representation at runtime |
| 09:02:47 | Araq | but instead 'f' is transformed to f[T] |
| 09:02:52 | vbtt_ | ah ok - i meant conceptually (i.e. s/union type/sum type) |
| 09:03:11 | vbtt_ | yeah parameterized type is another way to think about it. |
| 09:03:27 | Araq | non-generic -> generic # post generalization |
| 09:03:38 | Araq | generic -> non-generic # classic instantiation |
| 09:03:52 | vbtt_ | and this works for static dispatch only? |
| 09:04:26 | Araq | it only works when you have the body of 'f' |
| 09:04:39 | vbtt_ | ah right. |
| 09:07:38 | Araq | in fact, I can only see it working for strings and perhaps matrixes but these are important enough to try the feature |
| 09:08:18 | vbtt_ | i'm thinking about where this could be used. |
| 09:08:35 | Araq | it's obvious, isn't it? |
| 09:08:36 | vbtt_ | why did you go for a new type definition, rather than semantics that adapt any type to another type? |
| 09:09:53 | vbtt_ | e.g. type MyType = object ... |
| 09:10:16 | vbtt_ | # hmm, i'd like to call this function but it only accepts strings... |
| 09:10:39 | vbtt_ | proc `[]`(x: MyType as string, i) = ... |
| 09:10:51 | vbtt_ | proc len(x: MyType as string) = ... |
| 09:10:52 | vbtt_ | etc. |
| 09:10:56 | * | Eruquen quit (Quit: waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah) |
| 09:10:58 | vbtt_ | f(MyType()) |
| 09:11:13 | vbtt_ | this allows the same object to be used as a string and as an int or whatever. |
| 09:11:20 | BitPuffin | EXetoC .com is down |
| 09:12:20 | Araq | vbtt_: how can this possibly work in the compiler? it can't unless you annotate MyType as string-like |
| 09:12:57 | Araq | otherwise foo(bar) # type mismatch, but lets try it anyway? |
| 09:13:17 | vbtt_ | Araq:when the compiler parsed the definition of `[]` it marks MyType as string-like with the `[]` function defined. |
| 09:13:29 | vbtt_ | *parses |
| 09:14:05 | Araq | vbtt_: ok but (a) your notation requires 'MyType as string' in plenty of places |
| 09:14:24 | Araq | and (b) doesn't reflect reality as the compiler needs to implicitly annotate the type |
| 09:14:49 | vbtt_ | yeah |
| 09:15:06 | Araq | but in fact |
| 09:15:20 | Araq | the object defintion and the 'mimic' declaration will be decouple |
| 09:15:23 | Araq | *decoupled |
| 09:15:31 | vbtt_ | ah ok - that makes sense. |
| 09:15:48 | Araq | we haven't decided on a syntax |
| 09:15:49 | vbtt_ | as long as it can say MyType mimics string, footype, anothertype |
| 09:15:59 | Araq | yeah |
| 09:16:38 | vbtt_ | i have to think about this feature. it seems to allow usage of a function that was not intended by the author. |
| 09:16:56 | Araq | exactly, it does |
| 09:16:59 | vbtt_ | so i have a 'string-like' type and i want to use functions defined for strings. |
| 09:17:09 | Araq | yeah |
| 09:17:38 | Araq | it's more of a "quick hack" to make non-generic code behave |
| 09:17:58 | vbtt_ | ok. as long as it's understood as a hack, it's fine. |
| 09:18:25 | vbtt_ | cos really the right thing would be to change the original function to be generic. |
| 09:18:31 | Araq | indeed |
| 09:18:49 | Araq | except for the fact that *everything* could be generic |
| 09:18:56 | vbtt_ | but hacks are needed in practice, so this is fine. |
| 09:19:03 | Araq | at the cost of compile time and complexity |
| 09:19:50 | Araq | well we see how it works out in practice, has never been tried afaict |
| 09:20:49 | Araq | it is in fact, strutils vs D's ranges |
| 09:21:10 | Araq | strutils is simple to understand but doesn't generalize |
| 09:21:38 | Araq | D's ranges are harder but generalized |
| 09:22:11 | vbtt_ | f[T](x:T) means *any* type T but f(x: String) means any type that has been explicitly tagged as 'string'. this may be a good idea in it's own right. |
| 09:23:11 | vbtt_ | it's implied that there is a subset of all types that mimic string, and the function is only valid for those. |
| 09:23:47 | vbtt_ | so the type checks will be easier, rather than checking every operation, first check whether the type has been tagged (this will reject most types with a quick check) |
| 09:23:51 | vbtt_ | am i correct? |
| 09:24:14 | Araq | I can't follow you, sorry |
| 09:24:26 | vbtt_ | ok, nevermind. |
| 09:26:12 | Araq | we *could* later have f(x: like string) so 'f' acknowledges the fact that it is post generalization candidate |
| 09:26:44 | Araq | but then you need to specify what 'string-like' means |
| 09:26:57 | Araq | (uses 'len' and readonly '[]'? who knows...) |
| 09:26:58 | vbtt_ | it's just a tag, an identifier to classify types. |
| 09:27:12 | vbtt_ | it's the first check for any object passed to that function. |
| 09:27:18 | Araq | well there are lots of possibilies |
| 09:27:23 | Araq | *possibilities |
| 09:27:47 | vbtt_ | well if you define what string-like means exactly, then it's just a type class. |
| 09:28:03 | * | CarpNet quit (Ping timeout: 260 seconds) |
| 09:31:13 | Araq | yes, indeed |
| 09:33:00 | vbtt_ | so if you want another feature it could be less precise than a type class, but more than a generic [T]. |
| 09:33:05 | vbtt_ | but yeah, open to possibilities. |
| 09:36:43 | vbtt_ | in summary, interesting idea, but i'll wait until it's fleshed out more. |
| 09:37:11 | vbtt_ | btw, did you have a resolution for re 's' vs re's' ? |
| 09:37:20 | vbtt_ | Araq:^ |
| 09:40:48 | Araq | proc re(s)(s: string{command}): TRegex {.error.} # my idea, doesn't work for obvious reasons |
| 09:41:14 | Araq | you can still prevent it with a TR macro, but this sucks |
| 09:42:41 | * | DAddYE quit (Remote host closed the connection) |
| 09:43:25 | vbtt_ | re @'blah' |
| 09:43:27 | vbtt_ | re !'blah' |
| 09:44:12 | vbtt_ | i guess they're both operators so it won't work. |
| 09:44:23 | Araq | yes, plus what's the problem you're trying to solve? |
| 09:44:59 | vbtt_ | the fact that a space between re and the quoted string literal will behave differently than the no-space |
| 09:45:16 | vbtt_ | it will trip up people all the time, specially because in many cases it will work (when no escapes used) |
| 09:45:25 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 09:45:27 | Araq | that's no problem |
| 09:45:40 | vbtt_ | no? |
| 09:45:54 | Araq | we'll also get echo $foo vs echo $ foo |
| 09:46:31 | Araq | or take C's p/*q vs p/ *q |
| 09:46:47 | Araq | spaces are important, live with it :P |
| 09:48:24 | vbtt_ | yeah the dollar thing is confusing too. |
| 09:49:11 | Araq | why? |
| 09:50:03 | Araq | (btw C# has "" and @"" and indeed it causes problems for the people not knowing c# well. but what is the solution?) |
| 09:51:57 | vbtt_ | Araq: of course when the programmer is careful this is not a problem. but it would be nice if the compiler catches honest mistakes for times when the programmer slips up. |
| 09:53:34 | Araq | vbtt_: this effort however is much better spent on non-trivial things like type mismatch errors etc, errors coming from deeply nested instantiations etc. |
| 09:54:05 | Araq | we have to assume people know the very basics of how lexing and parsing works in nimrod |
| 09:54:14 | Araq | otherwise we'll get nowhere |
| 09:55:06 | * | Mordecai joined #nimrod |
| 09:55:34 | * | BitPuffin joined #nimrod |
| 09:56:38 | * | psquid quit (Ping timeout: 264 seconds) |
| 09:56:41 | vbtt_ | that's kind of acceptable, i suppose |
| 09:57:13 | * | CarpNet joined #nimrod |
| 10:02:12 | * | Eruquen joined #nimrod |
| 10:02:16 | Araq | fyi the plan is that i+1 * 3 will be parsed as (i+1) * 3 |
| 10:02:31 | Araq | spaces determine operator precedence |
| 10:04:29 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 10:04:31 | Araq | likewise e [1, 2, 3] should mean e([1,2,3]) and e[1,2,3] should be array-like access |
| 10:04:49 | Araq | f (1,2) # passes tuple to f |
| 10:04:59 | Araq | f(1,2) # passes 1, 2 to f |
| 10:06:45 | Araq | a|b * c # current situation: argh, does | bind tighter than * |
| 10:06:46 | vbtt_ | what about i + 1 * 3 |
| 10:07:03 | Araq | a|b * c # future situation: no need to lookup anything |
| 10:07:37 | Araq | vbtt_: i + 1 * 3 # fine |
| 10:07:56 | vbtt_ | if space is going to be that important then the raw string/ escaped string is not an issue |
| 10:08:24 | vbtt_ | i mean - what is it parsed as? is 1 space equivalent to any number of spaces? |
| 10:08:35 | Araq | no, it is not |
| 10:08:54 | Araq | number of spaces can be used to encode precedence |
| 10:08:59 | vbtt_ | i see |
| 10:09:07 | Araq | but we can limit it somehow |
| 10:09:18 | vbtt_ | unique feature, don't know if i like it yet. |
| 10:09:19 | Araq | maybe the number of spaces need to be doubled |
| 10:09:41 | Araq | so 0, 1, 2, 4, 8 spaces are fine and everything else is not |
| 10:10:08 | Araq | something like that |
| 10:10:27 | Araq | the difference between 4 vs 5 spaces is hard to see |
| 10:15:06 | Araq | also this feature can give us postfix operators: a* * *b is (a*) * (*b) |
| 10:15:23 | Araq | but I'm not sure we need it |
| 10:15:55 | vbtt_ | wow reading code is going to be like solving puzzles. |
| 10:16:29 | Araq | I don't think so, instead reading code is very intuitive |
| 10:17:01 | Araq | no need to lookup precedence rules in a table like we have in the manual |
| 10:17:18 | Araq | no need to lookup the definitions of * either |
| 10:17:53 | Araq | it is parsed as the layout suggests |
| 10:20:21 | * | filwit quit (Ping timeout: 248 seconds) |
| 10:22:58 | Araq | as a nice side effect people are forced to write 'f(1, 2)' and can't write it as 'f (1, 2)' which I personally cannot stand :-) |
| 10:31:39 | * | BitPuffin joined #nimrod |
| 10:33:55 | * | vbtt_ quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 10:57:07 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 10:59:19 | * | BitPuffin joined #nimrod |
| 10:59:50 | * | bbodi joined #nimrod |
| 11:37:26 | EXetoC | BitPuffin: yup. don't have much to show atm |
| 11:38:02 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 11:50:35 | * | Mordecai is now known as psquid |
| 12:10:26 | * | BitPuffin joined #nimrod |
| 12:18:53 | * | isenmann quit (Ping timeout: 252 seconds) |
| 12:27:34 | EXetoC | BitPuffin: just gotta add a blog post or something |
| 12:27:39 | * | isenmann joined #nimrod |
| 12:44:02 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 12:57:37 | * | BitPuffin joined #nimrod |
| 12:59:12 | EXetoC | BitPuffin: cirjewoxrwe |
| 13:00:05 | * | EXetoC quit (Quit: WeeChat 0.4.2) |
| 13:06:24 | * | PortableEXetoC joined #nimrod |
| 13:06:27 | * | PortableEXetoC quit (Client Quit) |
| 13:13:47 | * | EXetoC joined #nimrod |
| 13:35:33 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 13:35:56 | * | BitPuffin joined #nimrod |
| 13:37:25 | bstrie | Araq: re: changing the name, I'm all for it :P |
| 13:38:40 | bstrie | Araq: let's not forget why makefiles have been stuck with their terrible whitespace syntax for the past 40 years... http://stackoverflow.com/a/1765566/865424 |
| 13:39:00 | bstrie | "oh no, I have a dozen users! I can't change it NOW!!" |
| 13:39:34 | EXetoC | -.- |
| 13:45:47 | Araq | bstrie: do the Rust people consider a name change? |
| 13:46:35 | bstrie | Araq: honestly I think we're all in love with the name "Rust" :P |
| 13:47:23 | Araq | makes sense :P |
| 13:47:24 | bstrie | personally I like it because it has sensory connotations... the color of it, the touch of it |
| 13:47:43 | bstrie | lends itself well to having a "worn and industrial" theme |
| 13:47:50 | bstrie | but maybe I'm silly :P |
| 13:47:59 | bstrie | there are definitely people out there who *don't* like the name |
| 13:48:30 | bstrie | but I've only seen these people on reddit and HN. by the time they make it to the IRC channel we've filtered for people who don't care :P |
| 13:48:42 | * | radsoc joined #nimrod |
| 13:49:49 | bstrie | Araq: to be honest, one of the big reasons why I think the name should be changed is that quote at the top of the website... for any speaker of american english, it's somewhat baffling :P |
| 13:50:40 | bstrie | while "nimrod" as-an-insult might be a fairly obscure word to anyone not raised on bugs bunny cartoons, there's *nobody* who catches the biblical reference |
| 13:51:13 | bstrie | I consider myself much more well-versed in mythology than the average person, and I didn't realize the reference for a very long time |
| 13:51:38 | Araq | well the quote is obviously ironic either way |
| 13:52:12 | Araq | but as I said, I don't like nobody gets the reference either |
| 13:52:29 | bstrie | I do think the logo looks nice though |
| 13:56:50 | bbodi | hi all! |
| 13:57:38 | bbodi | Has typedesc types the .name property in the devel version? I can't echo it: "type: " & T.name |
| 13:57:50 | bbodi | Error: type mismatch: got (typedesc[string]) |
| 13:59:34 | Araq | bbodi: I don't think this feature has been ported to the vm ... sorry |
| 14:00:08 | Araq | but you should get a crash instead of an error message, so there seem to be 2 issues here |
| 14:00:14 | bbodi | what do you mean under 'vm'? |
| 14:00:33 | Araq | the virtual machine that is now used for compile time evaluation |
| 14:00:37 | bbodi | in that case, its a feature, because error messages is better than crash :D |
| 14:01:23 | bbodi | sorry, I havent got the most recent version of the compiler, its just some version of the 9.3 |
| 14:01:54 | Araq | lol neither do I |
| 14:02:08 | Araq | I really need to merge with devel |
| 14:05:33 | bbodi | I really like Nimrod, sometimes I can coding through days with Nimrod and feeling the "Flow". But sometimes I stuck with some weird bug/feature/dunno, and it really make me crazy |
| 14:05:49 | Araq | bstrie: btw how do owned pointer distinguish between thread local and shared allocation? I guess they distinguish with their region parametrization? |
| 14:06:15 | bbodi | I dont want to complaint, morover, let me thank you for your work with that fantastic language :) |
| 14:06:21 | EXetoC | let's see if I can figure out how to transform a template string with a filter |
| 14:06:42 | Araq | bbodi: it will get better soon |
| 14:20:10 | bstrie | Araq: I'm not sure what you mean by "distinguish", owned pointers always point to task-local data. you can't share that data without moving ownership to another task |
| 14:21:27 | bstrie | Araq: though "tasl-local" there is sort of a misnomer, owned things may be allocated in a heap that's independent of tasks, for faster transference of ownership... but that's an implementation detail :P |
| 14:21:48 | bstrie | and also "tasks" might themselves be threads, if you're using the 1:1 runtime |
| 14:23:03 | * | tumak quit (Ping timeout: 245 seconds) |
| 14:23:24 | Araq | "owned things may be allocated in a heap that's independent of tasks, for faster transference of ownership" <-- pretty much what I mean |
| 14:24:04 | * | tumak joined #nimrod |
| 14:24:31 | Araq | how does this work? I can't imagine the compiler does this as an optimization? |
| 14:29:36 | bstrie | Araq: not an expert but... iirc there's just a single heap per process. all owned things from any task get allocated there. there's no runtime checking for access, the compiler ensures that ownership makes sense |
| 14:30:47 | Araq | ok so you have a global shared heap |
| 14:31:25 | Araq | this means you need to lock the heap for 'alloc' or use a lock-free allocator |
| 14:32:40 | Araq | but ok, you can optimize away this if you can prove there is no ownership transfer |
| 14:33:09 | bstrie | according to the people in #rust-internals, "malloc and free are reentrant, so we don't need to lock the heap" |
| 14:33:44 | bstrie | and then of course they go on to say it's more complex than that, but w/e |
| 14:33:45 | bstrie | :P |
| 14:33:58 | Araq | I don't understand this |
| 14:34:10 | Araq | reentrant is a strange word in this context |
| 14:35:09 | bstrie | Araq: https://botbot.me/mozilla/rust-internals/msg/10342764/ |
| 14:37:00 | bstrie | Araq: you know you're welcome to just go over to irc.mozilla.org and ask yourself, I'm not a compiler developer, just a groupie :P |
| 14:38:15 | Araq | I was there but it spams my bouncer ;-) |
| 14:38:23 | Araq | too much action for rust |
| 14:38:40 | Araq | anyway, thank you, I got the answer |
| 14:39:46 | * | darkf quit (Quit: Leaving) |
| 14:44:47 | * | Mordecai joined #nimrod |
| 14:45:37 | * | psquid quit (Ping timeout: 265 seconds) |
| 14:45:39 | * | Mordecai is now known as psquid |
| 14:46:16 | BitPuffin | EXetoC: no excuse |
| 14:50:09 | EXetoC | BitPuffin: is too |
| 14:51:35 | EXetoC | that didn't take too long to figure out https://gist.github.com/EXetoC/8710132 |
| 14:52:25 | Araq | EXetoC: you cannot possibly import from 'compiler'! it's all voodoo code in there :P |
| 14:53:06 | * | brihat quit (Quit: Leaving.) |
| 14:53:14 | EXetoC | :/ |
| 14:53:21 | * | brihat joined #nimrod |
| 14:57:04 | Araq | EXetoC: take it as a compliment |
| 14:57:26 | Araq | and no, these APIs do not change quickly, if at all |
| 14:59:05 | BitPuffin | EXetoC: nop |
| 14:59:31 | EXetoC | ok |
| 15:00:55 | EXetoC | BitPuffin: yes :p but I might create a blog post soon. perhaps about how to navigate with.. GREP :-) |
| 15:01:21 | BitPuffin | EXetoC: ack! |
| 15:01:26 | BitPuffin | och VE |
| 15:01:44 | EXetoC | I don't think it works very well when function prototypes spans multiple lines though, but that hasn't been a problem so far |
| 15:05:53 | EXetoC | BitPuffin: ok, maybe I'll follow up with that some other time |
| 15:06:20 | EXetoC | BitPuffin: VE? |
| 15:08:48 | BitPuffin | EXetoC: ack och ve |
| 15:09:07 | BitPuffin | EXetoC: be swedish damn it |
| 15:14:26 | EXetoC | oh yeah, that showed up when I googled |
| 15:17:43 | * | radsoc quit (Ping timeout: 272 seconds) |
| 15:19:59 | EXetoC | grep "proc.*\*.*TFoo.*\):.*TBar" |
| 15:20:36 | EXetoC | perhaps we could have an ast-based grep tool some day. this works alright like I said, but it's more complicated than it has to be |
| 15:21:06 | Araq | EXetoC: build it, it's cool and 'easy' |
| 15:24:14 | EXetoC | yeah, might not be that hard |
| 15:24:45 | BitPuffin | what's nimgrep then? |
| 15:26:42 | Araq | BitPuffin: still string based |
| 15:27:06 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 15:27:38 | BitPuffin | Araq: but what's the point of it, then? |
| 15:30:35 | Araq | it works? and grep doesn't? |
| 15:33:36 | BitPuffin | that's news |
| 15:33:39 | BitPuffin | ack works though |
| 15:33:47 | BitPuffin | EXetoC claims that grep works though |
| 15:34:43 | * | io2 joined #nimrod |
| 15:35:46 | Araq | so do a feature comparison to get my point |
| 15:35:57 | BitPuffin | as if the time exists |
| 15:45:25 | * | [1]Endy joined #nimrod |
| 15:46:32 | bbodi | Araq: Once you said me that multi-methods work with generic type as well. Is it true in a case where the parent's method doesn't contains the generic type, only the child does? e.g.: method foo(self: Base) for the parent "class" and method foo[T](self: Child[T]) for the children. |
| 15:50:26 | * | [2]Endy joined #nimrod |
| 15:53:59 | * | [1]Endy quit (Ping timeout: 260 seconds) |
| 15:56:32 | EXetoC | BitPuffin: yes, for the use cases I've had to deal with, but it would've been less useful had certain shell features not been available |
| 15:59:04 | BitPuffin | such as aliasing? |
| 16:07:15 | EXetoC | BitPuffin: that and globbing mostly, when -R doesn't suffice |
| 16:07:21 | Araq | bbodi: compiler/semcall.nim, around line 23 |
| 16:07:35 | * | OrionPK quit (Remote host closed the connection) |
| 16:08:41 | Araq | I wrote down my knowledge in a comment in the compiler ... ;-) |
| 16:11:06 | Araq | see tests/methods/tmultim6.nim |
| 16:14:08 | Araq | in other words, yes it works |
| 16:14:30 | Araq | but it is subtle |
| 16:17:06 | Araq | in fact it is taking me 10 minutes to figure it out... |
| 16:25:24 | bbodi | Thanks, I check it |
| 16:27:14 | Araq | no need, I now know everything again |
| 16:27:22 | Araq | so what's your problem? |
| 16:28:49 | bbodi | The example I wrote above. Should it work? |
| 16:29:04 | Araq | yes |
| 16:29:50 | Araq | you need to instantiate things explicitly though so that it is added to the dispatcher as in my example |
| 16:37:30 | bbodi | hm You are right. I reproduced my case in a much simpler way, and here it works. Then I have another problem |
| 16:51:24 | * | shodan45 quit (Quit: Konversation terminated!) |
| 16:58:41 | * | psquid quit (Ping timeout: 272 seconds) |
| 17:08:58 | * | Mat3 joined #nimrod |
| 17:09:02 | Mat3 | hi all |
| 17:21:36 | * | zahary joined #nimrod |
| 17:22:41 | reactormonk | now I've written my product, but I've forgotten what I wanted to use it for :-/ |
| 17:23:04 | Mat3 | hello reactormonk |
| 17:43:30 | * | icebattle quit (Quit: leaving) |
| 17:54:38 | * | Icefoz joined #nimrod |
| 17:54:57 | * | DAddYE joined #nimrod |
| 18:05:22 | * | brson joined #nimrod |
| 18:16:26 | Mat3 | ciao |
| 18:16:35 | * | Mat3 quit (Quit: Verlassend) |
| 18:22:48 | * | brihat left #nimrod (#nimrod) |
| 18:24:33 | EXetoC | BitPuffin: using ack and ack.vim now. do I get a cookie? |
| 18:36:03 | * | brihat joined #nimrod |
| 18:38:15 | reactormonk | I have a bunch of items which are produced from other items. I have the list of products required for each product, the whole graph is about 4 levels deep. How do I construct every possible path of construction? |
| 18:43:16 | * | filwit joined #nimrod |
| 18:46:12 | * | zahary quit (Quit: Leaving.) |
| 19:03:25 | reactormonk | Error: expression ':delegator("input", current)' cannot be called |
| 19:03:29 | reactormonk | possibilities.add(@[TReaction(inputs: current.input*factor, output: current.output*factor, numberOfFactories: current.numberOfFactories*factor)]) |
| 19:03:50 | reactormonk | current is a TReaction |
| 19:04:19 | reactormonk | current is a TReaction |
| 19:04:22 | reactormonk | oops |
| 19:06:25 | EXetoC | is input accessible? |
| 19:06:43 | EXetoC | that error message confused me before, but now I know about delegators |
| 19:11:39 | EXetoC | no tests for delegators eh? the feature appears to work |
| 19:12:21 | reactormonk | fixed it. |
| 19:12:30 | reactormonk | also rewrite a bit of helper functions for cleaner code |
| 19:12:49 | reactormonk | any way to tell repr to give me a ruby-like `inspect`? Without all the memory addresses etc. |
| 19:13:01 | Varriount | What are delegators again? |
| 19:14:20 | EXetoC | Varriount: http://build.nimrod-lang.org/docs/manual.html#delegator-pragma |
| 19:15:34 | EXetoC | "The delegator pragma can be used to intercept and rewrite proc call and field access..." |
| 19:15:53 | Varriount | That could be handy for the parseCfg module |
| 19:17:36 | EXetoC | Just as I started using parsecfg |
| 19:21:14 | * | Icefoz quit (Ping timeout: 264 seconds) |
| 19:25:50 | EXetoC | why do some ctor procs modify some input rather than returning an instance of said type? |
| 19:27:42 | EXetoC | modifying an input and not returning anything that is. just wondering, because the latter is more convenient |
| 19:28:06 | Araq | efficiency |
| 19:32:44 | EXetoC | You think the caller should specify noInit? I can't think of anything else |
| 19:33:45 | Araq | it's re-using memory vs allocating |
| 19:34:06 | Araq | I guess where you encountered it, it doesnt matter |
| 19:34:31 | * | xtagon joined #nimrod |
| 19:36:12 | reactormonk | how much overhead is a set over a seq? |
| 19:36:18 | reactormonk | < 10 elements |
| 19:37:38 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 19:37:48 | Araq | system.set is almost always smaller, TSet is a hash set with 1/3 of space overhead over a seq |
| 19:38:45 | reactormonk | kk, I create them with 16 initial size |
| 19:44:37 | * | LordAndrew joined #nimrod |
| 19:45:01 | * | OrionPK joined #nimrod |
| 19:50:38 | Discoloda | system.set works like a bit array, so a set of an enum with over 300 values would be 38 bytes |
| 19:52:37 | EXetoC | Araq: I don't think so, but then again it's part of the compiler |
| 19:55:30 | EXetoC | I wonder if a syntax unification would involve too much magic, but overloading for this purpose seems to be acceptable |
| 19:56:10 | EXetoC | proc init(): T = init(result) |
| 19:56:39 | Araq | no a "syntax unification" is planned but for different reasons |
| 19:56:52 | Araq | well ... the plans are not fleshed out |
| 19:56:54 | EXetoC | interesting |
| 19:59:21 | * | brson quit (Quit: leaving) |
| 19:59:36 | * | brson joined #nimrod |
| 20:02:04 | EXetoC | Araq: for facilitating in writing generic code? |
| 20:02:13 | reactormonk | TReaction = object of TObject |
| 20:02:15 | reactormonk | inputs: TSet[TItem] |
| 20:02:22 | reactormonk | ^ works with seq[TItem], doesn't work with TSet[Item] |
| 20:02:27 | reactormonk | Error: cannot instantiate: 'A' |
| 20:08:31 | Varriount | can arrays in c hav4 negative subscripts? |
| 20:08:39 | Varriount | *have |
| 20:09:41 | reactormonk | oops, n/m |
| 20:09:47 | reactormonk | Varriount, subscripts? |
| 20:10:11 | Varriount | I'm trying to get nimrod to compile via microsoft's visual c compiler |
| 20:10:28 | Varriount | And am getting copius compiler errors |
| 20:12:32 | reactormonk | How do I write my own hash function? |
| 20:12:36 | reactormonk | ... for my object |
| 20:12:53 | reactormonk | I don't see any function I can combine two hashes with |
| 20:14:35 | reactormonk | !& apparently |
| 20:15:50 | reactormonk | Error: type mismatch: got (TSet[TItem], proc (TItem): TItem{.closure.}) |
| 20:15:57 | reactormonk | system.map(data: var openarray[T], op: proc (var T){.closure.}) |
| 20:15:59 | reactormonk | aww |
| 20:23:54 | * | zahary joined #nimrod |
| 20:30:55 | reactormonk | btw, how do I write a set literal? |
| 20:34:33 | vbtt | I've been thinking about the possible syntax modifications. mixing prefix, postfix, infix syntax with space sensitivity could be very confusing. |
| 20:34:44 | vbtt | a* b |
| 20:35:27 | vbtt | is it an infix operator or a postfix operator with a function call? |
| 20:35:39 | Varriount | reactormonk: A set literal is {} |
| 20:36:00 | vbtt | similarly. a* *b vs. a ** b vs a**b etc. |
| 20:36:32 | Varriount | vbtt: Araq has plans for signicant spacing |
| 20:36:56 | vbtt | Varriount:yeah i know. |
| 20:37:04 | vbtt | which is what i'm expressing concerns about. |
| 20:37:15 | vbtt | but we'll see what syntax rules are chosen. |
| 20:37:27 | vbtt | so far, i dont like the idea. |
| 20:38:00 | vbtt | a+b * c is an easy example but once you have more than one space, parsing it by eye seems harder than just parsing the parenthesized version. |
| 20:38:16 | Varriount | vbtt: Well, you could always turn it off |
| 20:38:31 | vbtt | the problem is other people's code. |
| 20:38:38 | vbtt | which you often have to read. |
| 20:41:07 | vbtt | the only thing simple enough for me to visually parse is if no-space=prefix|postfix|composite-operator and space-on-both-sides=infix-operator |
| 20:41:42 | reactormonk | vbtt, cool |
| 20:41:52 | vbtt | anyway, let's see what syntax is selected. |
| 20:42:28 | reactormonk | {TItem(typeID: TTypeID("2308"), amount: 3000)} gives me Error: ordinal type expected |
| 20:42:35 | reactormonk | uhh @ Varriount |
| 20:44:14 | Varriount | For what? |
| 20:44:31 | Varriount | reactormonk: Yeah. You said a set literal, that is a set |
| 20:45:11 | Varriount | The built in sets can only contain ordinal types |
| 20:46:43 | Varriount | The 'sets' module doesn't have a literal (although that could be fixed with a macro) |
| 20:50:15 | Varriount | reactormonk: Built in sets are bit sets, and can only contain ordinals. The hash sets in the sets module can contain more than just ordinals, but they are also less efficient than built in sets (both are probably quite efficient, but there is a difference) |
| 20:50:51 | Araq | vbtt a* b would be a postfix operator with a function call obviously |
| 20:51:03 | Araq | a * b would be an infix operator |
| 20:51:09 | vbtt | hehe |
| 20:51:23 | Araq | I can't imagine how it can ever be difficult to figure out |
| 20:51:29 | * | vbtt thinks is amusing how Araq tags on 'obviously' to statements. |
| 20:51:49 | Varriount | vbtt: I have to agree with Araq on that one though |
| 20:52:20 | Araq | vbtt: however postfix operators are not in the initial proposal for space sensitivity |
| 20:53:35 | * | filwit quit (Ping timeout: 260 seconds) |
| 20:53:36 | Araq | also the argument "can be confusing" is getting tiresome |
| 20:54:05 | Varriount | Everything can be confusing, given enough ignorance and misuse |
| 20:54:14 | Araq | what if I have in C a+1 * 3 ? is the whitespace that is ignored by the C compiler not confusing? |
| 20:55:06 | Araq | what if "other people" write code this way? should I trust the compiler or the spaces? |
| 20:57:11 | * | [2]Endy quit (Ping timeout: 272 seconds) |
| 20:58:16 | Varriount | Araq: I have an article I think you might like -> http://naildrivin5.com/blog/2013/05/17/source-code-typography.html |
| 20:59:12 | vbtt | of course everything can be confusing but representation matters. |
| 20:59:29 | vbtt | there's a reason we dont do math in roman numerals for e.g. even though its possible. |
| 20:59:54 | Varriount | vbtt: Have you seen calculus? |
| 21:00:14 | vbtt | readability and convenience matter. also how error prone something is. e.g. I know about the 'except A, B:' gotcha in python since forever yet I still make that mistake sometimes. |
| 21:01:42 | vbtt | there's a difference between 'somthing different that just takes getting used to and then its just as easy, if not more' and 'something different that takes getting used to but actually worsens productivity' |
| 21:02:11 | vbtt | Varriount:what about calculus? |
| 21:03:14 | vbtt | calculus semantics have inherent complexity. now imagine calculus using roman numerals - thats like adding unnecessary syntactic complexity on top of it. |
| 21:03:53 | Varriount | vbtt: Have you seem all the logic symbols calculus takes? |
| 21:04:02 | vbtt | Varriount:no. |
| 21:06:05 | vbtt | Araq: C is confusing of course. the type declarations are particularly confusing because of the chosen syntax. |
| 21:06:13 | Varriount | vbtt: http://plato.stanford.edu/entries/logic-linear/psystems2a.jpg |
| 21:07:29 | vbtt | Varriount:ok. what's the point you're making though? |
| 21:08:22 | Varriount | vbtt: Just that technically we do do match in roman numerals |
| 21:08:38 | Varriount | *math |
| 21:08:47 | Varriount | Well, roman symbols anyway |
| 21:08:51 | Varriount | Or greek |
| 21:09:34 | Varriount | vbtt: Perhaps the ability to turn significant spaces to parens could be added to 'nimrod pretty'? |
| 21:09:41 | vbtt | Varriount:I don't think you get my point. I'm not talking about using non numeric symbols to represent something. |
| 21:10:09 | reactormonk | Varriount, hm, so how do I get a TSet literal? |
| 21:10:13 | vbtt | Varriount: I'm talking about roman numerals vs arabic. |
| 21:10:25 | Varriount | vbtt: FYI, I'm neither for nor against significant spaces. I'm just throwing things into the conversation |
| 21:10:53 | Varriount | reactormonk: Probably use a macro to turn a set literal into a tset |
| 21:10:54 | vbtt | both can represent all positive integers, yet, nobody uses roman because its just so inconvenient. |
| 21:11:35 | Varriount | reactormonk: Or just make a set and add things to it manually |
| 21:12:01 | reactormonk | toSet doesn't work :-/ |
| 21:12:03 | reactormonk | Error: undeclared identifier: 'data' |
| 21:12:18 | Varriount | Huh, that seems familier to a recent bug posted. |
| 21:12:30 | reactormonk | yup |
| 21:12:46 | Varriount | reactormonk: Could I get a gist of your code? |
| 21:12:54 | reactormonk | let's reduce the problem a bit |
| 21:13:11 | Varriount | reactormonk: I have to go in a couple minutes. Calculus calls |
| 21:14:32 | reactormonk | Varriount, http://dpaste.com/1577600/ |
| 21:14:37 | reactormonk | full code |
| 21:14:47 | reactormonk | doesn't appear in http://dpaste.com/1577601/ |
| 21:15:05 | vbtt | anyway, g2g. will wait for the syntax details before fruther comments. however i leave you with these: a*(b) (a)*b |
| 21:15:11 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 21:23:56 | * | BitPuffin joined #nimrod |
| 21:28:10 | BitPuffin | EXetoC: yes you get a cookie |
| 21:28:10 | * | silven quit (Remote host closed the connection) |
| 21:31:06 | * | silven joined #nimrod |
| 21:32:03 | * | brson quit (Quit: leaving) |
| 21:33:18 | reactormonk | Varriount, found it. == for sets is broken |
| 21:42:00 | * | shodan45 joined #nimrod |
| 21:55:05 | * | XAMPP quit (Ping timeout: 272 seconds) |
| 22:06:13 | * | io2 quit () |
| 22:13:03 | reactormonk | Araq, https://github.com/Araq/Nimrod/pull/857 can you double-check? |
| 22:19:46 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 22:42:36 | * | Mat3 joined #nimrod |
| 22:42:39 | Mat3 | hi |
| 22:55:14 | * | Mat3 quit (Quit: Verlassend) |
| 23:09:28 | * | brson joined #nimrod |
| 23:11:24 | Araq | reactormonk: ah, makes sense |
| 23:11:40 | Araq | == for object accesses a.data |
| 23:12:02 | Araq | but this is not allowed outside the module as it would break encapsulation |
| 23:12:28 | Araq | your patch is not entirely correct though |
| 23:13:06 | Araq | you need to check that ever element of set a is in set b as the order could differ |
| 23:13:22 | Araq | and that s.counter == t.counter |
| 23:14:00 | Araq | in fact |
| 23:14:14 | Araq | implement '<=' for TSet's |
| 23:14:24 | Araq | and == then becomes: |
| 23:14:44 | Araq | s.counter == t.counter and s <= t |
| 23:16:46 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 23:22:58 | * | darkf joined #nimrod |
| 23:36:59 | * | psquid joined #nimrod |
| 23:48:57 | * | filwit joined #nimrod |
