| 00:01:43 | Varriount | Araq: Any idea what 'checkDepMem' is? |
| 00:01:50 | Araq | ah the irony, dom96 |
| 00:02:17 | Araq | Varriount: sounds like a debugging thing you shouldn't bother |
| 00:02:21 | Araq | with |
| 00:03:18 | NimBot | Araq/Nimrod devel 4c63b0d Araq [+16 ±5 -16]: better tester |
| 00:03:18 | NimBot | Araq/Nimrod devel 71b5b6c Araq [+0 ±6 -0]: unittest module works again |
| 00:03:41 | Araq | how come nobody comments on our new kick-ass test suite? |
| 00:04:33 | Varriount | Woo! Yeah! We have a great new test suite! |
| 00:08:05 | Varriount | Now, besides the directory structure changes, how is it different from the old test suite? |
| 00:09:08 | Araq | well we also have a new tester which stores its results in a sqlite database and a nice HTML frontend to that |
| 00:09:24 | Araq | and the directory changes are a massive improvement |
| 00:09:51 | Araq | because now I can fix exception handling related bugs and run only that part of the test suite for quick iteration |
| 00:10:47 | * | io2 quit (Ping timeout: 252 seconds) |
| 00:13:39 | Varriount | Wow. There are a *lot* of undocumented compiler commands. |
| 00:15:41 | Araq | I don't think so |
| 00:15:44 | Araq | what do you mean? |
| 00:17:34 | Varriount | Lets see.. |
| 00:19:01 | Araq | dom96: can't you just push your ole2 changes? |
| 00:19:14 | Varriount | There's all the compile variations that aren't documented in the help printout |
| 00:19:26 | Araq | argh the linking times on windows kill me |
| 00:19:33 | Araq | has clang its own linker now? |
| 00:20:01 | vbtt | posted my suggention for generic to the forum |
| 00:21:06 | dom96 | Araq: I haven't made any |
| 00:21:49 | Varriount | There are also the 'parse', 'scan', 'reset', and 'e' commands |
| 00:21:57 | Araq | vbtt: I like your suggestion, I think zahary will be against it though |
| 00:22:10 | Araq | Varriount: these are not documented for a reason |
| 00:22:27 | Araq | vbtt: one problem is that we already have high(int) etc. everywhere |
| 00:22:51 | Araq | which is where this features comes from really, it's a generalization of what always existed |
| 00:23:01 | dom96 | Araq: I still don't understand how this new SQL stuff works in the tester. |
| 00:23:21 | Araq | tester cat closure |
| 00:23:33 | Araq | tester --print html |
| 00:23:44 | Araq | dom96: you don't need to understand it really |
| 00:25:00 | vbtt | Araq: what does high(int) mean? |
| 00:25:01 | Varriount | vbtt: I agree with you on the whole ':' prefix |
| 00:25:43 | vbtt | I think the ':' changes the code to look less like a magical language for typeclasses and more like standard nimrod. |
| 00:25:47 | Varriount | Since, in nimrod, ':' (usually) precedes a type |
| 00:26:08 | dom96 | Araq: Will each test run have a separate db? |
| 00:26:46 | Araq | dom96: no |
| 00:27:02 | Araq | vbtt: high(int) returns MAX_INT |
| 00:28:03 | NimBot | Araq/Nimrod devel d3a0194 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds example to locals() docstring. |
| 00:28:03 | NimBot | Araq/Nimrod devel b6cdee4 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds docstring to rstgen.defaultConfig. |
| 00:28:03 | NimBot | Araq/Nimrod devel 3fcbbb8 Billingsly Wetherfordshire [+0 ±1 -0]: Update os.nim... 2 more lines |
| 00:28:03 | NimBot | Araq/Nimrod devel a2a5395 Dominik Picheta [+0 ±2 -0]: Added --noBabelPath override. |
| 00:28:03 | NimBot | 16 more commits. |
| 00:28:12 | vbtt | ok, i just read about it but no sure how it relates to my suggestion. |
| 00:28:32 | Araq | well it would become high(:int) obviously |
| 00:30:24 | vbtt | hmm, I dont really understand why. Let me think about it. |
| 00:31:10 | Araq | consistency? |
| 00:32:30 | vbtt | I dont think you should be able to write f(:T) anywhere in executable code. Because passing and unnamed value doesn't mean anything. However you could write `proc f(:T)` if you don't need to capture the argument passed. |
| 00:32:57 | Araq | dom96: well please fix ole2 then, I need to sleep now |
| 00:33:00 | vbtt | so you could write `proc f(: typedesc[int])` because really it can only recieve the int type itself. |
| 00:33:22 | Araq | nah, that's not necessary |
| 00:33:32 | Varriount | Wait a sec. I thought you meant to use the ':' prefix in the context of typeclass *definitions* |
| 00:33:35 | dom96 | Araq: I'm working on async, i'll create an issue and do it later. |
| 00:33:36 | Araq | parameter names are usually nice to have |
| 00:33:46 | Araq | dom96: sure thing |
| 00:33:53 | vbtt | Varriount: that is correct. which is why I'm not sure how it relates to code outside typeclass definitions. |
| 00:34:09 | vbtt | but Araq brought up high(int) |
| 00:34:48 | Varriount | high(int) is a procedure call that takes a typedesc parameter, it's not a typedesc definition in and of itself. |
| 00:35:15 | dom96 | Araq: oh but I just remembered, in my own code I had to explicitly make each int an int8 in the ``D4`` array. |
| 00:35:26 | dom96 | (When constructing the GUID) |
| 00:35:45 | Araq | oh wait a sec |
| 00:35:51 | dom96 | Definitely looks like the compiler could infer this stuff better. |
| 00:35:58 | Araq | I think I misunderstood your proposal, vbtt |
| 00:36:16 | Araq | dom96: oh no, kill me already |
| 00:36:40 | Araq | what we have is already too smart and bug prone in the compiler |
| 00:37:20 | Araq | integer types are a constant pita because people can't be bothered to write 45'i8 |
| 00:37:24 | dom96 | Well the compiler shouldn't require me to make each member of the array an int8, should it? |
| 00:37:52 | Araq | well only the first member needs to be an int8 |
| 00:38:02 | Araq | though arguably that's strange too |
| 00:38:12 | dom96 | Yeah, well. That didn't work, so this may be some bug? |
| 00:38:36 | Araq | are you talking about ole2? |
| 00:40:42 | Varriount | Why in the world does the sqlite downloads page not have a 64 bit dll?! |
| 00:41:18 | dom96 | Araq: https://gist.github.com/dom96/909448434f7053c02e4b |
| 00:41:22 | dom96 | Doesn't work |
| 00:41:32 | dom96 | Perhaps there is a reason for it. |
| 00:41:34 | * | icebattle quit (Quit: Leaving) |
| 00:41:48 | Araq | dom96: yes |
| 00:42:05 | Araq | for instance 0x8c is not a valid int8 |
| 00:42:20 | Araq | you need to change the type so it uses byte instead of int8 |
| 00:42:40 | Araq | fix the TGUID please |
| 00:43:08 | Araq | Varriount: oh really? damn, I can feel your pain |
| 00:43:34 | Araq | vbtt: I misunderstood your proposal then |
| 00:44:03 | Araq | I thought you argue for :T everywhere a type is passed to a parameter |
| 00:45:31 | vbtt | on no, just in typeclass definitions. |
| 00:45:59 | Araq | hmm alright |
| 00:46:05 | Araq | that surely doesn't break any code then |
| 00:47:03 | vbtt | gret |
| 00:47:41 | vbtt | Araq: taking the design further, you could also eliminate 'is' by rewriting `(x > y) is bool` to `_: bool = x > y`. basically a *normal* nimrod statement. |
| 00:48:22 | vbtt | taking it even further, you can say 'just write normal nimrod code in typeclass definition with the feature that any expression can be replaced by ':T' to mean `a value here of type T`. if the definition compiles, the check passes. |
| 00:48:50 | vbtt | not sure if that's feasible, but it certainly means I have to remember less rules when writing generics. also the generic definition serves as a usage example. |
| 00:49:11 | Araq | yeah that was one original idea behind it |
| 00:49:22 | Araq | making it close to its usage |
| 00:50:16 | Araq | I like your idea, but I don't have all use cases in mind; so let's see what zahary thinks |
| 00:50:50 | vbtt | taking it even further (heh I'm really twisting this now :) - you dont define it as a type, but a new top level keyword 'generic' that looks somewhat like a proc definition. E.g generic stream(s) = write(s, :bytearray) |
| 00:51:17 | Araq | bah, watch out now :P |
| 00:51:44 | Araq | I know "type" sections are not loved but still, let's not make it inconsistent for no good reason |
| 00:51:55 | vbtt | this is more powerful because you can define the relationship between two types. generic complement(x, y) = y = xform(x); x = xform(y) |
| 00:52:15 | Araq | you can do that in a single type section too |
| 00:52:23 | vbtt | how? |
| 00:52:26 | Araq | mutual recursion is allowed in a type section |
| 00:53:03 | * | foxcub joined #nimrod |
| 00:53:05 | vbtt | this is different. |
| 00:53:10 | Araq | but go on and then update your forum post |
| 00:53:18 | Araq | I need to sleep now finally |
| 00:53:24 | vbtt | ok, good night. |
| 00:53:56 | * | Araq tries to remember the time when he could sleep for more than 6 hours |
| 00:54:01 | * | Araq fails |
| 01:12:25 | Varriount | I wonder, in the combined total of x86 and x64 processors in the world, what percentage are 64 bit? |
| 01:20:23 | Varriount | vbtt: You still there? |
| 01:21:19 | vbtt | yes, just updated proposal. |
| 01:21:47 | vbtt | the forum lets you edit, which is weird, i can change history :) |
| 01:22:01 | vbtt | because I edited after araq repled |
| 01:22:07 | vbtt | *replied. |
| 01:22:21 | Varriount | Be careful not to lose your password, the forum doesn't have a password recovery feature. |
| 01:23:23 | Varriount | vbtt: What would you think of generalizing the generic instanciation syntax genericProj[T], |
| 01:23:42 | Varriount | to a simple partial procedure applicator? |
| 01:23:51 | vbtt | not sure what you mean |
| 01:23:57 | vbtt | ah wait. |
| 01:24:16 | vbtt | You mean f(T, x, y) instead of f[T](x, y) ? |
| 01:24:30 | Varriount | vbtt: Well, you can actually already do that |
| 01:24:47 | vbtt | can you describe your proposal with an example? |
| 01:24:47 | Varriount | You just have to use the 'typedesc' type for the parameter def |
| 01:24:53 | Varriount | Yeah, one moment |
| 01:25:53 | * | brson quit (Quit: leaving) |
| 01:26:23 | * | brson joined #nimrod |
| 01:27:10 | LordAndrew | Is anyone here familiar with how software licensing works? I'm a bit confused on some aspects of Nimrod's licensing. |
| 01:27:46 | Varriount | LordAndrew: Ask away |
| 01:29:12 | LordAndrew | The COPYING file says the compiler and standard library are MIT, but the GitHub repo has a few files in it that seem to be under a few different licences (GPL, MPL, BSD), and the compiler itself seems to utilize GCC? |
| 01:30:46 | Varriount | LordAndrew: The compiler is in actuality a translator, which can translate nimrod to several different backends. |
| 01:30:58 | Varriount | It only makes use of gcc as an external tool |
| 01:31:10 | Varriount | (or visual studio, or clang, etc) |
| 01:31:35 | Varriount | I don't know much about the other files, which ones are they? |
| 01:31:44 | Varriount | vbtt: Hasty example here -> https://gist.github.com/anonymous/8484880 |
| 01:32:35 | LordAndrew | The files under different licenses all appear to be in the /lib/wrappers/ directory. |
| 01:33:07 | Varriount | LordAndrew: Ah, that's likely because they were generated using c2nim, and the generator copied the comments over |
| 01:40:23 | vbtt | Varriount: currently, do I have to instantiate generic procedures before i can call them? iow, can I write f(1, 2) or must I write f[int](1, 2) |
| 01:40:47 | Varriount | vbtt: Depends on if the compiler is smart enough to instantiate them for you. |
| 01:40:49 | vbtt | Varriount: btw, I think what you're asking for is called dependent typing. |
| 01:41:26 | Varriount | vbtt: I (possibly mistakenly) call it partial procedure application |
| 01:47:36 | vbtt | Varriount: partial procedure application would happen if you call the proc with fewer than required arguments. |
| 01:47:51 | vbtt | I believe dependent typing is in the longer term plan. |
| 01:48:03 | vbtt | you'll have to ask araq. it has it's uses. |
| 01:48:08 | Varriount | vbtt: Which is what I did in the example |
| 01:48:53 | Varriount | vbtt: For me, its main use would be for closure iterators. Then it would be relatively trivial to simulate python-style iterators |
| 01:49:40 | Varriount | Currently, for closure iterators, all arguments must be passed each time the iterator is iterated |
| 01:49:57 | LordAndrew | I see. So then there are no hidden license goblins hiding in Nimrod then? I'm interested in using the language bit I don't want to have to deal with the licensing mess of the GPL/MPL/etc. |
| 01:50:44 | Varriount | LordAndrew: The only licensing problems you would might have is if you used the libraries that the wrappers interface with. |
| 01:53:22 | vbtt | Varriount: oh I though nimrod has python style iterators already. |
| 01:53:33 | Varriount | vbtt: Let me show you another example |
| 01:53:36 | vbtt | ok |
| 01:54:04 | * | j-renner joined #nimrod |
| 01:54:18 | j-renner | does anyone know how I can add a color scheme to Aporia? |
| 01:54:25 | j-renner | I've edited an xml file, but I can't see it in prefs |
| 01:54:44 | LordAndrew | Varriount: Alright then. Thanks! |
| 01:54:51 | Varriount | j-renner: You just missed dom96 I think. He's the force behind aporia. |
| 01:55:02 | j-renner | k |
| 01:55:38 | * | DAddYE quit (Remote host closed the connection) |
| 01:56:14 | * | DAddYE joined #nimrod |
| 01:59:01 | Varriount | vbtt: https://gist.github.com/Varriount/8485141 |
| 02:00:06 | vbtt | cant you do: for x in counter(1, 10) echo i |
| 02:00:50 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 02:00:56 | Varriount | Yes you can, but that wouldn't show you the fact that the arguments must be manually passed in |
| 02:01:41 | vbtt | I'm not sure what you mean. you're just creating a number of distinct iterators from what I see. |
| 02:02:25 | Varriount | Nope. That first var, counterInstance, is a single iterator instance |
| 02:02:27 | vbtt | rather - can you write some python code to show what nimrod cannot do? |
| 02:02:49 | Varriount | Certainly. |
| 02:03:04 | Varriount | vbtt: Do you want it in another gist, or the same one? |
| 02:03:11 | vbtt | doesn't matter |
| 02:03:17 | vbtt | Varriount: I see, it's a function call without any args - how does that work? doesn't it need start and stop (sorry i'm new to nimrod) |
| 02:04:00 | Varriount | that 'var counterInstance' is a single instance of a closure iterator |
| 02:04:30 | Varriount | each subsequent call iterates the iterator, the python equivalent of calling the 'next' method |
| 02:05:48 | vbtt | ah i see what you mean. |
| 02:05:59 | vbtt | you dont have a next method in nimrod.. |
| 02:06:18 | vbtt | in python you can call next(itr), next(itr) |
| 02:07:03 | vbtt | but couldn't you wrap the counterIterator(0,5) call in a closure? |
| 02:07:26 | Varriount | vbtt: Theoretically, however that currently fails due to compiler bugs |
| 02:07:44 | Varriount | And believe me, it's a very... mind numbing bug |
| 02:08:19 | Varriount | vbtt: The trouble comes when you can't always get the exact args the iterator was started with |
| 02:08:30 | vbtt | ok i'll look into iterators more when i find time. i g2g now. |
| 02:08:43 | Varriount | See the series where counterInstance is given a '10' instead of a '5'? |
| 02:08:50 | Varriount | Ok, see you later. |
| 02:09:06 | vbtt | the behaviour you describe sounds broken. |
| 02:09:33 | vbtt | the point of a *closure* iterator should be to save state. |
| 02:09:37 | Varriount | It has its upsides, but yes, it makes closure iterators less than what they could be. |
| 02:10:20 | vbtt | ttyl |
| 02:10:24 | * | vbtt quit (Quit: Page closed) |
| 02:10:27 | Varriount | vbtt: You can also do some tricks with default arguments and explicit capturing of initial arguments, but again, those are things that the iterator should be doing. |
| 03:11:13 | xtagon | Wow, Nimrod has come a long way since I first learned of it (that was a few years ago) |
| 03:11:34 | xtagon | I think it's my new favorite language |
| 03:39:50 | * | foxcub quit (Quit: foxcub) |
| 03:42:41 | * | vbtt joined #nimrod |
| 03:57:44 | * | vbtt quit (Ping timeout: 272 seconds) |
| 03:58:55 | * | foxcub joined #nimrod |
| 04:00:13 | * | dymk quit (Quit: Leaving) |
| 04:07:25 | * | vbtt joined #nimrod |
| 04:12:43 | vbtt | hello |
| 04:14:11 | * | foxcub quit (Quit: foxcub) |
| 04:18:08 | * | foxcub joined #nimrod |
| 04:35:33 | * | foxcub quit (Quit: foxcub) |
| 04:52:24 | xtagon | Is there an XCB wrapper for Nimrod, or just Xlib? |
| 05:03:42 | * | ddl_smurf joined #nimrod |
| 05:04:29 | * | vbtt quit (Quit: Page closed) |
| 05:15:56 | * | Xuehas joined #nimrod |
| 05:16:28 | * | Xuehas left #nimrod (#nimrod) |
| 05:57:41 | * | j-renner quit (Quit: WeeChat 0.4.1) |
| 06:03:39 | * | vvbitt joined #nimrod |
| 06:04:52 | discoloda | is there a pragma to link a c file? |
| 06:09:27 | * | xtagon quit (Ping timeout: 260 seconds) |
| 06:13:51 | * | foxcub joined #nimrod |
| 06:19:27 | * | Demos joined #nimrod |
| 06:20:06 | * | foxcub quit (Quit: foxcub) |
| 06:21:51 | discoloda | {. link: "some_c_file.c" .} works |
| 06:35:59 | * | Demos quit (Quit: Textual IRC Client: www.textualapp.com) |
| 06:39:47 | LordAndrew | Is it possible to read multiple files at once? Like, from a directory? |
| 06:42:39 | * | AndChat|206976 joined #nimrod |
| 06:42:40 | * | vvbitt quit (Read error: Connection reset by peer) |
| 07:00:51 | * | vvbitt joined #nimrod |
| 07:00:52 | * | AndChat|206976 quit (Read error: Connection reset by peer) |
| 07:01:38 | * | vvbitt quit (Client Quit) |
| 07:50:50 | * | vbtt joined #nimrod |
| 08:12:37 | Araq | LordAndrew: see os.walkFiles, os.walkDir etc. |
| 08:27:24 | Araq | ping Varriount |
| 08:42:12 | * | brson quit (Quit: leaving) |
| 09:17:45 | Araq | dom96: I'd like to add nimrod.res for the icon to aporia |
| 09:17:59 | Araq | but that's a binary file and people will burn me |
| 09:18:32 | dom96 | That icon is a bit meh though |
| 09:19:08 | Araq | better than no icon |
| 09:19:28 | Araq | I guess we really need a compile-time when fileExists ... |
| 09:19:46 | Araq | then I could patch the source and not provide the .res file |
| 09:20:23 | dom96 | we might get a better icon soon |
| 09:20:26 | dom96 | just be patient |
| 09:22:36 | Araq | no |
| 09:22:53 | Araq | I want to commit so that I can update and see if devel compiles aporia |
| 09:23:11 | dom96 | git stash |
| 09:23:22 | Araq | I know about git stash |
| 09:23:36 | dom96 | I like the little GTK icon |
| 09:23:41 | Araq | but this only makes me forget about it |
| 09:26:02 | dom96 | I don't see a problem with that :P |
| 09:26:13 | Araq | does git stash create a branch? |
| 09:27:16 | dom96 | no |
| 09:32:08 | * | vbtt quit (Ping timeout: 272 seconds) |
| 09:44:06 | Araq | dom96: can I run "babel install" from anywhere? |
| 09:45:51 | dom96 | yes |
| 09:48:03 | Araq | let's try :P |
| 09:49:39 | Araq | gah zahary's patch shows up quite some bugs in the wrappers |
| 09:53:59 | Araq | PGsource = pointer # I don't know and don't care |
| 09:54:20 | Araq | ah the joys of old code |
| 10:01:20 | Araq | I guess I can't use babel to push to some git repo, right? |
| 10:02:11 | Araq | dom96: that might be a problem: |
| 10:02:28 | Araq | I now have pkgs/gtk2-1.0 but no .git in there |
| 10:02:37 | Araq | so I can't update the package easily |
| 10:02:43 | Araq | s/update/fix |
| 10:11:40 | dom96 | You need to clone it manually. |
| 10:48:31 | * | Mordecai joined #nimrod |
| 10:49:53 | * | psquid quit (Ping timeout: 252 seconds) |
| 10:54:41 | Araq | bbl |
| 10:56:57 | * | odc joined #nimrod |
| 11:02:42 | * | bbodi joined #nimrod |
| 11:11:24 | bbodi | Hi all! I try to compile the following source code, but i get an internal error.In the source code there is an object variant, and I want to define a proc for that variant. If I comment out the proc (called setProcessed), it works fine. What is the problem? The code can be found here: http://pastebin.com/YWHLtKJm thanks in advance! |
| 11:15:24 | bbodi | I found it. It is caused by the command branch, which contains a "ref object" type |
| 11:44:29 | dom96 | bbodi: Create a bug report on github please if you haven't already |
| 11:44:47 | bbodi | ok |
| 12:15:42 | * | psquid joined #nimrod |
| 12:15:58 | * | Mordecai quit (Ping timeout: 265 seconds) |
| 12:21:54 | * | bbodi quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 13:06:48 | Araq | dom96: that's the old "generic type in non-generic type" bug again |
| 13:07:58 | Araq | zahary: I think we need to get rid of all the keyword type classes like "ptr" and introduce somePtr, someObject etc. that's less error prone |
| 13:19:56 | * | zahary quit (Quit: Leaving.) |
| 13:21:11 | * | zahary joined #nimrod |
| 13:42:17 | * | darkf quit (Quit: Leaving) |
| 13:43:40 | zahary | I think I just need to improve the error messages. I haven't been very diligent in updating procs like typeAllowed, etc in the compiler with all the new types |
| 13:43:55 | * | delian66 joined #nimrod |
| 13:47:48 | * | zahary quit (Read error: Connection reset by peer) |
| 13:47:48 | * | zahary1 joined #nimrod |
| 13:55:27 | Araq | he ok |
| 13:55:32 | Araq | hi delian66 welcome |
| 13:56:27 | delian66 | Araq: hi |
| 14:36:50 | * | faassen joined #nimrod |
| 14:44:01 | * | psquid quit (Ping timeout: 272 seconds) |
| 14:53:16 | * | zahary1 quit (Read error: Connection reset by peer) |
| 14:53:39 | * | zahary joined #nimrod |
| 15:14:28 | * | psquid joined #nimrod |
| 15:30:34 | * | [1]Endy joined #nimrod |
| 15:49:31 | * | faassen quit (*.net *.split) |
| 15:49:33 | * | OrionPK quit (*.net *.split) |
| 15:49:33 | * | eigenlicht quit (*.net *.split) |
| 15:49:34 | * | discoloda quit (*.net *.split) |
| 15:52:03 | * | faassen joined #nimrod |
| 15:52:03 | * | OrionPK joined #nimrod |
| 15:52:03 | * | eigenlicht joined #nimrod |
| 15:52:03 | * | discoloda joined #nimrod |
| 15:56:10 | * | faassen quit (*.net *.split) |
| 15:56:11 | * | OrionPK quit (*.net *.split) |
| 15:56:12 | * | eigenlicht quit (*.net *.split) |
| 15:56:13 | * | discoloda quit (*.net *.split) |
| 15:58:37 | * | faassen joined #nimrod |
| 15:58:37 | * | OrionPK joined #nimrod |
| 15:58:37 | * | eigenlicht joined #nimrod |
| 15:58:37 | * | discoloda joined #nimrod |
| 16:30:07 | * | randallsquared joined #nimrod |
| 16:45:50 | * | foxcub joined #nimrod |
| 16:46:50 | * | [2]Endy joined #nimrod |
| 16:47:31 | foxcub | I have a mysterious problem in Nimrod. Does anyone have time to take a look at a little code? |
| 16:49:19 | OrionPK | post it up |
| 16:49:35 | * | foxcub quit (Remote host closed the connection) |
| 16:49:56 | * | foxcub joined #nimrod |
| 16:50:31 | * | faassen left #nimrod (#nimrod) |
| 16:50:35 | * | [1]Endy quit (Ping timeout: 272 seconds) |
| 16:51:40 | foxcub | https://bitbucket.org/mrzv/serialization/src |
| 16:51:52 | foxcub | If you look in examples/bintree.nim |
| 16:52:03 | foxcub | It currently imports tables, but it really shouldn't have to. |
| 16:52:17 | foxcub | But if I don't, it will complain in archive.nim that hasKey() is not found. |
| 16:52:25 | foxcub | Despite the fact that archive.nim imports tables. |
| 16:55:26 | OrionPK | so you're wondering why you have to import tables? |
| 16:56:02 | foxcub | Why I have to import tables in bin tree.nim |
| 16:56:15 | foxcub | It's already imported in archive.nim, and bintree.nim doesn't actually use tables. |
| 16:56:34 | OrionPK | ahh I didnt see the examples folder, thought you were referring to a nimrod repo example |
| 16:56:45 | foxcub | No-no, sorry |
| 16:56:50 | foxcub | It's all local to that repository. |
| 16:56:58 | OrionPK | yep |
| 16:57:29 | OrionPK | you're basically calling tables.hasKey |
| 16:57:35 | OrionPK | without importing tables |
| 16:57:41 | OrionPK | so you have a couple options |
| 16:57:50 | foxcub | Wait |
| 16:57:54 | foxcub | But I am importing tables. |
| 16:57:59 | foxcub | Right at the top of archive.nim |
| 16:57:59 | OrionPK | in a different module |
| 16:58:08 | foxcub | But hasKey is only used in archive.nim |
| 16:58:19 | foxcub | tables are not used at all in bintree.nim |
| 16:58:20 | OrionPK | ah |
| 16:58:29 | OrionPK | you're righ |
| 16:58:30 | OrionPK | t |
| 16:58:30 | OrionPK | :) |
| 16:58:42 | foxcub | Yeah, the whole thing is very mysterious. |
| 17:00:17 | OrionPK | yep, you got me there |
| 17:02:43 | foxcub | It really looks like a bug to me. |
| 17:02:53 | foxcub | But I can't boil it down to a smaller example. |
| 17:03:30 | foxcub | I guess I'll ask Araq later, if I'm missing something or if it's a bug. |
| 17:03:42 | foxcub | Thanks for looking at it, OrionPK |
| 17:04:03 | OrionPK | yep |
| 17:05:03 | * | vbtt joined #nimrod |
| 17:05:32 | vbtt | hello |
| 17:07:09 | * | foxcub quit (Quit: foxcub) |
| 17:17:45 | * | io2 joined #nimrod |
| 17:25:52 | * | vbtt quit (Ping timeout: 272 seconds) |
| 17:26:15 | * | vvbitt joined #nimrod |
| 17:27:05 | * | vvbitt quit (Client Quit) |
| 17:27:20 | * | vbtt joined #nimrod |
| 18:00:58 | * | io2 quit (Ping timeout: 246 seconds) |
| 18:01:01 | * | io2_ joined #nimrod |
| 18:02:43 | vbtt | Hi zahary |
| 18:07:36 | zahary | хи |
| 18:07:39 | zahary | hi |
| 18:26:13 | * | vbtt quit (Ping timeout: 248 seconds) |
| 19:01:47 | * | io2_ quit () |
| 19:01:59 | * | io2_ joined #nimrod |
| 19:02:02 | * | io2_ is now known as io2 |
| 19:18:04 | * | aftersha_ joined #nimrod |
| 19:56:22 | Araq | dom96: I fixed the gtk wrappers for devel, but now I get: |
| 19:56:26 | Araq | aporia.nim(2003, 21) Error: type mismatch: got (PTreeView, PListStore) |
| 19:56:27 | Araq | but expected one of: |
| 19:56:29 | Araq | gtk2.set_model(tree_view: PTreeView, model: PTreeModel) |
| 19:56:30 | Araq | gtk2.set_model(combo_box: PComboBox, model: PTreeModel) |
| 19:56:38 | Araq | with aporia from git head |
| 19:56:57 | dom96 | Hrm, seems you broke object inheritance? |
| 19:57:07 | dom96 | PListStore inherits from PTreeModel IIRC |
| 19:57:14 | Araq | nope it doesnt |
| 19:57:24 | dom96 | well then how did that ever work? |
| 19:57:25 | Araq | TListStore* = object of TGObject |
| 19:57:39 | Araq | it was an alias to an untyped pointer before |
| 19:57:40 | dom96 | That looks wrong. |
| 19:57:49 | Araq | ok, let's see |
| 19:58:02 | dom96 | There are two types of TreeModels |
| 19:58:15 | dom96 | A list store and a tree store or whatever it's called |
| 19:58:34 | dom96 | TreeModel is the generic thing |
| 20:01:05 | Araq | https://developer.gnome.org/gtk3/stable/GtkListStore.html |
| 20:01:12 | Araq | it inherits from GObject |
| 20:01:57 | dom96 | "GtkListStore implements GtkTreeModel" |
| 20:01:59 | dom96 | Interesting |
| 20:02:38 | Araq | so I'll cast it to PTreeModel |
| 20:03:04 | dom96 | That's ugly. |
| 20:03:14 | dom96 | Can't we fix the wrapper somehow? |
| 20:03:23 | Araq | ok so I'll add an overload to the wrapper |
| 20:03:28 | Araq | or a converter perhaps |
| 20:03:44 | dom96 | converter would work yeah |
| 20:17:09 | * | bbodi joined #nimrod |
| 20:18:10 | * | bbodi quit (Changing host) |
| 20:18:10 | * | bbodi joined #nimrod |
| 20:35:12 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 20:38:25 | * | aftersha_ joined #nimrod |
| 20:42:06 | * | aftersha_ quit (Client Quit) |
| 20:43:27 | * | aftersha_ joined #nimrod |
| 20:44:44 | * | bbodi quit (Ping timeout: 272 seconds) |
| 20:45:09 | * | aftersha_ quit (Client Quit) |
| 21:10:59 | * | delian66 quit (Ping timeout: 272 seconds) |
| 21:19:10 | * | [2]Endy quit (*.net *.split) |
| 21:19:12 | * | EXetoC quit (*.net *.split) |
| 21:19:12 | * | athaudia quit (*.net *.split) |
| 21:19:12 | * | mal`` quit (*.net *.split) |
| 21:20:44 | * | [2]Endy joined #nimrod |
| 21:20:44 | * | EXetoC joined #nimrod |
| 21:20:44 | * | athaudia joined #nimrod |
| 21:20:44 | * | mal`` joined #nimrod |
| 21:30:53 | Varriount | Araq: I agree with you on using 'somePtr", "someObject", etc |
| 21:31:20 | Varriount | Also, you pinged me? |
| 21:31:58 | Araq | oh yeah |
| 21:32:25 | Araq | did you change something in windows.nim? |
| 21:32:25 | * | [2]Endy quit (Ping timeout: 272 seconds) |
| 21:32:39 | Varriount | Araq: In what timeframe? |
| 21:34:31 | Araq | ever |
| 21:35:08 | Varriount | I don't think so. I've added things to winlean.nim, but not windows.nim |
| 21:36:33 | Araq | ok |
| 21:37:18 | Varriount | git's file history doesn't show anything related to me. |
| 21:37:27 | Varriount | for windows.nim |
| 21:42:56 | Araq | ok, was too lazy to ask git :P |
| 21:43:48 | Varriount | Araq: Well, I didn't *think* I had changed anything, but I wanted to make sure. Why do you want to know? |
| 21:43:56 | * | brson joined #nimrod |
| 21:44:10 | OrionPK | nimbot needs to become semi sentient so you can ask him questions like that |
| 21:44:44 | Varriount | OrionPK: 'import sentience' doesn't work? |
| 21:44:46 | Araq | Varriount: because it didnt compile with devel anymore |
| 21:44:56 | Araq | but i know why by now |
| 21:44:58 | Varriount | Araq: Oh. Lovely/ |
| 21:45:07 | OrionPK | not in 0.9.3 |
| 21:45:12 | Araq | fixed it already |
| 21:45:27 | OrionPK | must be a bug in the sentience module |
| 21:45:48 | Varriount | Sorry I haven't been on all day. I wanted to finish up an adventure game I've been working my way through for a while now. |
| 21:46:00 | OrionPK | which |
| 21:46:19 | Varriount | 'The Inner World', by Studio Fizbin |
| 21:46:52 | Varriount | Another German based studio, of course. |
| 21:49:16 | Araq | stop playing games, work on the compiler instead |
| 21:49:58 | Varriount | You mean, like lambdalifting.nim? |
| 21:50:31 | Araq | yeah |
| 21:50:45 | Varriount | *shudder* |
| 21:51:53 | Araq | hi randallsquared welcome |
| 21:52:04 | Araq | or like nimrod serve |
| 21:52:30 | Varriount | Araq: I am working on nimrod serve |
| 21:52:58 | Varriount | Also, I'm writing that procedure generator pragma for the winlean.nim procedures |
| 21:53:18 | Araq | what's that? |
| 21:54:04 | Varriount | You annotate a single windows api call that would normally be imported by cimport with this pragma |
| 21:54:49 | Varriount | And you get 2 other procedures auto-generated - one that converts any string args to WideCString or CString depending on the defines |
| 21:55:28 | Varriount | and another that is just a copy of the first procedure, but with 'A' or 'W' appended to the end of the name. |
| 21:55:53 | Araq | I hope you're writing a macro for that instead of patching the compiler |
| 21:56:00 | Varriount | Of course! |
| 21:56:09 | Araq | cool :-) |
| 21:56:18 | Araq | excellent |
| 21:56:30 | Varriount | Unfortunately, it's not something a template can really do. :/ |
| 21:56:43 | Varriount | So I have to get my hands dirty working with the ast |
| 21:56:49 | Araq | yup |
| 22:18:16 | Varriount | Araq: Is it possible to define a converter inside a procedure, and have the converter's effects be limited to just that procedure? |
| 22:18:48 | * | faassen joined #nimrod |
| 22:20:16 | Araq | I think the compiler restricts converters to top level routines |
| 22:20:49 | Varriount | Ah well. |
| 22:21:03 | Araq | your idea makes sense but is rather hard to support |
| 22:21:16 | Varriount | Yeah, I understand |
| 22:28:00 | * | shodan45 quit (Quit: Konversation terminated!) |
| 22:28:05 | * | shodan45_ joined #nimrod |
| 22:32:40 | * | shodan45_ quit (Client Quit) |
| 22:32:47 | * | shodan45_ joined #nimrod |
| 22:34:48 | * | shodan45_ quit (Read error: Connection reset by peer) |
| 22:34:58 | * | shodan45_ joined #nimrod |
| 22:36:25 | Varriount | Gah, whats the equivalent of repr for a nimrod stmtlist node? |
| 22:37:20 | * | shodan45_ quit (Client Quit) |
| 22:39:53 | Araq | repr? |
| 22:40:16 | Varriount | Nevermind, it's treeRepr |
| 22:40:50 | Varriount | Don't know why I kept missing that one in the docs |
| 22:42:24 | Araq | ah! got it! |
| 22:42:48 | Varriount | Oh? Did you catch the monster that keeps eating all the cheese tarts? |
| 22:43:27 | Araq | now I know how the compiler needs to treat injected symbols for the new symbol binding rules in templates |
| 22:43:41 | Varriount | Good! |
| 22:45:09 | * | odc quit (Ping timeout: 252 seconds) |
| 23:03:07 | NimBot | Araq/Nimrod master b2410ab Josh Girvin [+0 ±1 -0]: Koch now uses PATH/nimrod correctly |
| 23:03:07 | NimBot | Araq/Nimrod master 19574a3 Andreas Rumpf [+0 ±1 -0]: Merge pull request #812 from girvo/koch-fix... 2 more lines |
| 23:05:58 | NimBot | Araq/Nimrod master a30b428 Billingsly Wetherfordshire [+0 ±1 -0]: Update endians.nim... 2 more lines |
| 23:05:58 | NimBot | Araq/Nimrod master 250249c Andreas Rumpf [+0 ±1 -0]: Merge pull request #775 from fowlmouth/patch-3... 2 more lines |
| 23:13:52 | Araq | what about https://github.com/Araq/Nimrod/pull/692 ? |
| 23:14:02 | Araq | do we want the submodule stuff? |
| 23:14:23 | Varriount | Submodule? |
| 23:15:11 | Varriount | Araq: I don't know. It would be nice, but on the other hand, you don't have to use csources to bootstrap nimrod |
| 23:15:42 | Varriount | I mean, the first time I bootstrapped nimrod's master branch, I used the 9.2 release on the website. |
| 23:20:20 | Araq | you got lucky |
| 23:21:08 | Araq | usually the previous release cannot compile any newer release |
| 23:22:33 | * | darkf joined #nimrod |
| 23:22:37 | Araq | though it's a good point |
| 23:22:49 | Araq | we should ensure 0.9.2 can compile 0.9.4 |
| 23:27:42 | * | brson quit (Quit: Lost terminal) |
| 23:28:13 | * | brson joined #nimrod |
| 23:29:00 | Varriount | Araq: If nothing else, make sure that koch can be built by as many versions as reasonably possible. Otherwise you get stuck in the same situation as autotools and its associated utilities. |
| 23:29:24 | Varriount | *we need to make sure that |
| 23:36:48 | * | vbtt joined #nimrod |
| 23:36:50 | vbtt | hi guys |
| 23:37:13 | Varriount | Hey vbtt |
| 23:37:54 | vbtt | Varriount:did you find a better solution for the iterator stuff? |
| 23:38:12 | vbtt | Varriount:you should file a bug, if it doesn't exist. |
| 23:39:12 | Varriount | Oh, it's been files. The question is if anyone has the mental complexity and time to fix it. |
| 23:39:17 | Varriount | *filed |
| 23:39:24 | vbtt | I see. |
| 23:39:32 | Varriount | I'm sure Araq has the mental complexity, but time, not so much. |
| 23:39:39 | vbtt | btw, the nimrod forum is nice, but can i have it notify to my email? |
| 23:39:55 | Varriount | I don't think it has those features. |
| 23:39:57 | Araq | the forum supports rss these days iirc |
| 23:40:16 | Varriount | But surprisingly, not password recorvery. :/ |
| 23:40:24 | Varriount | *recovery |
| 23:40:25 | vbtt | Araq:yeah i just noticed that, not quite email but still nice - i'll add the feed to my reader. |
| 23:40:55 | Araq | hey, I hacked the forum together in my spare spare time and then luckily dom96 took over |
| 23:42:21 | Araq | Varriount: so implement password recovery |
| 23:42:28 | vbtt | Araq:btw, once i better understood the generic stuff, i really like it. of course i'd prefer if we had to use :T instead of T but that's a syntax issue. the semantics are quite powerful and something i've been wanting in a language. |
| 23:43:03 | vbtt | Araq:far superior to the 'interfaces' people ask for. |
| 23:43:09 | Varriount | Araq: vbtt and I were talking about closure iterators yesterday. :P |
| 23:43:45 | Araq | Varriount: I noticed but I still don't get your p[T] is a "partial whatever" idea |
| 23:43:55 | vbtt | Ah right - Varriount said closure iterators don't save the state (you have to pass it in every time) and I didn't believe it. But I haven't tested them yet. |
| 23:44:14 | Araq | closure iterators do save the state |
| 23:44:28 | Araq | however they can't yet capture outer variables |
| 23:44:46 | Araq | which makes them very limited |
| 23:45:04 | Araq | but since we need that for async/await it's of pretty high priority |
| 23:45:25 | vbtt | Araq - why do you have to pass in the function args every time? is that what you're saying will be fixed? https://gist.github.com/Varriount/8485141 |
| 23:45:30 | vbtt | the gist is from Varriount. |
| 23:46:24 | Araq | so use a proc that returns an anonymous iterator instead |
| 23:46:49 | Araq | which doesn't work yet, but you get the idea |
| 23:48:12 | Araq | zahary had the same objection |
| 23:48:27 | Araq | maybe my design really is wrong ... hm |
| 23:49:05 | vbtt | well the point of the iterator is you pass in some args then it just emits values. |
| 23:49:15 | vbtt | what if i pass in different args the second time? |
| 23:49:23 | vbtt | also, I should only have to all the iterator once, no? |
| 23:49:37 | * | faassen quit (Quit: Leaving.) |
| 23:49:50 | Araq | then it uses different args the second time? |
| 23:49:56 | Araq | what's the problem? |
| 23:51:20 | vbtt | what if the args don't match the state the iterator has saved? |
| 23:51:21 | vbtt | sorry either i dont understand the semantics or this really doesn't make sense. |
| 23:51:31 | vbtt | counterInstance(0, 10); counterInstance(100, 200); |
| 23:52:08 | Araq | if the args don't match the state it'll crash or produce stupid things |
| 23:52:12 | vbtt | right. |
| 23:53:07 | Araq | well look at my examples |
| 23:53:17 | Araq | you can use them for a simple tasking system |
| 23:53:31 | Araq | so you can pass "stop: bool" each time you call it |
| 23:53:39 | Araq | makes perfect sense to me |
| 23:54:59 | Varriount | Araq: It's not that having to give the arguments each time is bad - it's just restricting |
| 23:55:10 | Araq | no, it's the opposite |
| 23:55:16 | Araq | it's more flexible this way |
| 23:55:40 | Araq | as I said, you can easily capture everything and return iterator () with no args |
| 23:57:01 | Varriount | vbtt: Maybe when closure iterators get fixed, we can make a pragma macro to do the capturing for us. |
| 23:58:01 | Araq | proc counter(start, stop:int): iterator (): int {.closure.} = |
| 23:58:03 | Araq | return iterator () = |
| 23:58:04 | Araq | var x = start |
| 23:58:06 | Araq | while x < stop: |
| 23:58:07 | Araq | yield x |
| 23:58:09 | Araq | inc(x) |
| 23:58:57 | Araq | makes perfect sense to me and avoids a magic protocol via 'next' that Python uses |