| 00:00:13 | Araq_ | it can be longer than 4K though |
| 00:00:33 | yglukhov | oh i forgot youre windows fan |
| 00:00:36 | yglukhov | =) |
| 00:00:37 | Araq_ | which used to be the limitation on old Linux? DOS? whatever |
| 00:00:56 | yglukhov | not Linux i guess.. |
| 00:01:58 | Araq_ | $ xargs --show-limits |
| 00:01:58 | Araq_ | Your environment variables take up 2572 bytes |
| 00:01:58 | Araq_ | POSIX upper limit on argument length (this system): 2092532 |
| 00:02:00 | Araq_ | POSIX smallest allowable upper limit on argument length (all systems): 4096 |
| 00:02:02 | Araq_ | Maximum length of command we could actually use: 2089960 |
| 00:02:04 | Araq_ | Size of command buffer we are actually using: 131072 |
| 00:02:19 | Araq_ | there you go, it's POSIX. |
| 00:03:40 | * | bpr joined #nim |
| 00:05:11 | bpr | So the new-ll branch compiles the integration example, but still fails with my 'method-suite' examples for implementing dynamic dispatch. |
| 00:06:04 | Araq_ | bpr: gist? |
| 00:06:22 | bpr | I get warnings that top level {.closure.} is deprecated, but it compiles and then clang can't compile the generated C. |
| 00:06:43 | Araq_ | top level .closures are not supported by the new LL |
| 00:06:45 | bpr | Araq, I will do that ASAP |
| 00:06:54 | Araq_ | why do you need them? |
| 00:07:20 | yglukhov | getconf ARG_MAX = 262144 on macos |
| 00:08:31 | Araq_ | come on. |
| 00:09:04 | Araq_ | @if linux: gcc.path = "" @else: gcc.path = "other" @end # guess the syntax with nims |
| 00:09:12 | Araq_ | with cmd line only? |
| 00:10:06 | Araq_ | exec "nim c $1" % someOption where you can then at least use Nim syntax to set someOption |
| 00:10:17 | Araq_ | but it's still back to string munging. |
| 00:10:46 | Araq_ | oh and don't forget to quote properly if someOption has a space. Fun. |
| 00:10:53 | yglukhov | my point is to have a nice configuration api in nims (nimble) which produces a set of args to nim. |
| 00:11:30 | Araq_ | we have that and it's called NimScript support for both the compiler and nimble. |
| 00:12:08 | Araq_ | there is no advantage in crippling the compiler when it's the compiler which understands Nim syntax in the first place. |
| 00:12:27 | kernasi | "NimScript as a build tool" nice :) |
| 00:13:09 | kernasi | "NimScript can also be used directly as a portable replacement for Bash and Batch files" ooooh, "Nicer" |
| 00:14:09 | * | bpr quit (Quit: Page closed) |
| 00:14:28 | * | bpr joined #nim |
| 00:15:06 | bpr | Araq, here's the example, pretty much what I posted to the forum earlier https://gist.github.com/bpr/263a6bc73afebaaba778 |
| 00:15:17 | bpr | Have to run now, be back soon |
| 00:15:51 | yglukhov | As i said, i don't really care who runs the task, but i want one explicit way of doing it. |
| 00:16:11 | * | irrequietus quit () |
| 00:16:16 | * | kniteli joined #nim |
| 00:16:29 | * | kniteli left #nim (#nim) |
| 00:17:42 | yglukhov | if nimble myTsk and nim myTask both work but in slighlty different ways that would be surprising. |
| 00:17:56 | yglukhov | surprising in a bad way =) |
| 00:19:46 | yglukhov | if nimscriptapi in nimble eventually diverges from nimscript in compiler, that would be bad as well |
| 00:19:54 | * | bpr quit (Ping timeout: 252 seconds) |
| 00:20:36 | yglukhov | ok, have to go. see you tomorrow. |
| 00:24:46 | Araq_ | bye bye |
| 00:25:14 | Araq_ | bpr: I have to go now, we can talk tomorrow, but I think you just need to get rid of top level .closure procs |
| 00:27:33 | * | def- joined #nim |
| 00:28:09 | * | yglukhov quit (Remote host closed the connection) |
| 00:33:39 | * | def- quit (Quit: -) |
| 00:48:27 | * | bpr joined #nim |
| 00:52:18 | * | brson quit (Quit: leaving) |
| 00:55:39 | * | def- joined #nim |
| 00:56:10 | bpr | OK, we can talk tomorrow, but removing the top level {.closure.} annotations does not fix the problem; I added them to assuage the compiler's type checker. |
| 00:57:05 | bpr | That example works on the devel branch, provided I keep those deprecated top level {.closure.} annotations on the procs. |
| 00:59:41 | bpr | But applying the identical transformation to the expr example from the Nim tutorial leads to bad C being generated. |
| 01:00:02 | * | bigfondue quit (Ping timeout: 272 seconds) |
| 01:01:27 | * | bigfondue joined #nim |
| 01:03:05 | * | gokr quit (Quit: Leaving.) |
| 01:04:25 | * | def- quit (Quit: -) |
| 01:05:00 | * | johnsoft joined #nim |
| 01:13:56 | * | desophos quit (Read error: Connection reset by peer) |
| 01:14:24 | * | def- joined #nim |
| 01:15:31 | * | gokr joined #nim |
| 01:19:15 | * | def- quit (Ping timeout: 260 seconds) |
| 01:24:23 | * | jakesyl joined #nim |
| 01:28:39 | * | yglukhov joined #nim |
| 01:32:50 | * | yglukhov quit (Ping timeout: 246 seconds) |
| 01:38:14 | * | fedons joined #nim |
| 01:41:18 | * | bpr quit (Ping timeout: 252 seconds) |
| 01:44:09 | * | def- joined #nim |
| 01:51:40 | * | kernasi quit (Quit: Verlassend) |
| 02:15:41 | * | vendethiel quit (Quit: q+) |
| 02:19:35 | * | fedons_ joined #nim |
| 02:19:57 | * | gokr quit (Quit: Leaving.) |
| 02:22:50 | * | fedons quit (Ping timeout: 260 seconds) |
| 02:30:13 | * | yglukhov joined #nim |
| 02:35:38 | * | fedons joined #nim |
| 02:35:50 | * | yglukhov quit (Ping timeout: 255 seconds) |
| 02:36:46 | * | fedons quit (Client Quit) |
| 02:37:52 | * | fedons_ quit (Ping timeout: 250 seconds) |
| 02:45:17 | * | desophos joined #nim |
| 02:46:04 | * | def- quit (Ping timeout: 265 seconds) |
| 02:55:40 | * | def- joined #nim |
| 03:00:08 | * | def- quit (Ping timeout: 255 seconds) |
| 03:10:41 | * | def- joined #nim |
| 04:15:44 | * | jakesyl quit (Ping timeout: 255 seconds) |
| 04:32:44 | * | yglukhov joined #nim |
| 04:37:00 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 05:01:19 | * | desophos_ joined #nim |
| 05:06:12 | * | desophos_ quit (Ping timeout: 256 seconds) |
| 05:35:25 | * | Demon_Fox quit (Quit: Leaving) |
| 05:52:44 | * | darkf joined #nim |
| 06:19:50 | * | darkf_ joined #nim |
| 06:22:12 | * | darkf quit (Ping timeout: 272 seconds) |
| 06:34:00 | * | yglukhov joined #nim |
| 06:38:33 | * | yglukhov quit (Ping timeout: 265 seconds) |
| 06:53:05 | * | darkf_ is now known as darkf |
| 06:59:33 | * | desophos_ joined #nim |
| 07:00:46 | * | desophos quit (Ping timeout: 240 seconds) |
| 07:07:13 | * | desophos_ quit (Read error: Connection reset by peer) |
| 07:18:04 | * | vikaton quit (Quit: Connection closed for inactivity) |
| 07:27:51 | * | dv joined #nim |
| 08:18:08 | * | yglukhov joined #nim |
| 09:16:28 | * | reactormonk quit (Quit: WeeChat 1.1.1) |
| 09:16:36 | * | reactormonk joined #nim |
| 10:00:50 | * | fedons joined #nim |
| 10:04:33 | * | Trustable joined #nim |
| 10:04:34 | * | irrequietus joined #nim |
| 11:09:37 | * | fedons quit (Quit: This computer has gone to sleep) |
| 11:09:51 | * | fedons joined #nim |
| 11:15:48 | * | Deavmj_web joined #nim |
| 11:15:52 | * | deavmi_mobile joined #nim |
| 11:15:59 | * | vendethiel joined #nim |
| 11:25:39 | * | fedons quit (Quit: This computer has gone to sleep) |
| 11:28:41 | * | Arrrr joined #nim |
| 11:31:14 | Arrrr | Merry christmas |
| 11:43:20 | reactormonk | Arrrr, you successfully traveled 5 days ahead in time |
| 11:44:28 | Arrrr | Only five? I thought i was in 1982's christmas, damn |
| 11:48:06 | dom96 | hello guys |
| 11:48:09 | dom96 | how are you? |
| 12:00:29 | Araq_ | hi dom96 |
| 12:07:02 | dom96 | hey Araq_ |
| 12:07:50 | dom96 | So you think the ability for users to edit nimscriptapi is important enough to not staticRead the file? |
| 12:08:58 | * | fedons joined #nim |
| 12:13:32 | * | fedons quit (Client Quit) |
| 12:19:37 | Araq_ | staticRead it if you cannot solve the problem where to find the single file, but IMO it's the poorest non-scalable solution of all |
| 12:20:54 | Araq_ | and you will hate it soon enough that nimble doesn't read the file but instead has some old version of it built into its exe and that you need to recompile nimble all the time |
| 12:31:35 | dom96 | Araq_: I agree. Like I said, you can just copy the whole nimblepkg dir beside nimble.exe |
| 12:31:40 | dom96 | is that satisfactory? |
| 12:32:30 | Araq_ | yup |
| 12:34:18 | dom96 | Good. |
| 12:34:26 | dom96 | So, wanna test Nimble? |
| 12:40:30 | * | fedons joined #nim |
| 12:53:38 | * | silven joined #nim |
| 12:56:23 | * | fedons quit (Quit: This computer has gone to sleep) |
| 12:56:46 | Araq_ | dunno. that tjester still fails is not important, right?! ;-) |
| 12:57:25 | * | def- quit (Quit: -) |
| 13:00:15 | * | def- joined #nim |
| 13:01:42 | * | NimBot joined #nim |
| 13:01:59 | dom96 | Araq_: I hope your new LL fixes the nimforum and nimbot memory leaks. |
| 13:02:19 | Araq_ | unlikely, but my new GC will ... |
| 13:05:05 | * | fedons joined #nim |
| 13:05:34 | * | def- quit (Ping timeout: 245 seconds) |
| 13:10:03 | Araq_ | yay, I was right, under 3s bootstrapping times now with the new LL |
| 13:10:29 | * | def- joined #nim |
| 13:10:59 | yglukhov | Araq: What do you think about my pr? https://github.com/nim-lang/Nim/pull/3667 |
| 13:11:50 | Araq_ | I like it but I think it's something bad. |
| 13:11:59 | Araq_ | muahaha, that never gets old |
| 13:12:12 | Araq_ | why is the line info wrong? |
| 13:15:18 | * | def- quit (Ping timeout: 250 seconds) |
| 13:17:45 | dom96 | yglukhov: hey, how's Nimble's nimscript support so far, anything big missing? |
| 13:18:21 | yglukhov | dom96, there has been some discussion with me and Araq yesterday. have you read it? |
| 13:18:31 | dom96 | yeah |
| 13:19:11 | yglukhov | Araq: previously lineinfo in getType nodes was taken from the lineinfo of getType invocation |
| 13:19:33 | yglukhov | that is not really helpful |
| 13:19:46 | * | def- joined #nim |
| 13:23:47 | dom96 | So you guys want ``nimble --allowAllPackages build`` instead of ``nim build``? |
| 13:25:04 | Araq_ | yglukhov: it's ok but the real problem is somewhere else, see my comment |
| 13:25:26 | Araq_ | dom96: yeah. |
| 13:26:52 | dom96 | okay, that's easy I guess. |
| 13:27:00 | dom96 | Is that really needed in the short-term though? |
| 13:27:35 | Araq_ | no. |
| 13:28:23 | * | def- quit (Quit: -) |
| 13:29:51 | dom96 | Good |
| 13:31:49 | * | def- joined #nim |
| 13:32:05 | dom96 | What about things which are needed before I release the new version? |
| 13:35:44 | Araq_ | do you support multiple packages.jsons in an easy fashion? |
| 13:42:12 | dom96 | Araq_: Hrm. No, but I can make it super easy super easily. |
| 13:42:29 | dom96 | Although editing a config file is already pretty easy IMO |
| 13:44:43 | Araq_ | well but does Nimble support a single remote URL or multiple? |
| 13:44:55 | Araq_ | to retrieve the package list? |
| 13:45:06 | Araq_ | it should support multiple sources. |
| 13:45:06 | dom96 | multiple |
| 13:45:14 | Araq_ | cool. how does that work? |
| 13:45:22 | Araq_ | do you merge these lists on startup? |
| 13:45:31 | dom96 | https://github.com/nim-lang/nimble#configuration |
| 13:45:52 | dom96 | You can have multiple package lists defined |
| 13:45:57 | dom96 | and each package list can have multiple URLs |
| 13:46:26 | Araq_ | yeah, read it. |
| 13:46:29 | Araq_ | that's cool. |
| 13:46:47 | Araq_ | glad this feature already exists and works. |
| 13:46:58 | Araq_ | seems like it's ready for production. :-) |
| 13:47:25 | dom96 | heh, true. |
| 13:47:35 | dom96 | I actually didn't even realise how powerful of a feature that is |
| 13:47:50 | dom96 | It's a must for private package lists |
| 13:47:56 | Araq_ | exactly. |
| 13:49:08 | yglukhov | dom96: have you read the discussion regarding nim and nimble configuration with a single nimscript file? One of the concerns that nimble may not be able to pass a big config to nim over cmdline. And thus it may be better for nim to handle tasks, and leave nimble only for pkg management. Also diverging nimscript.nim and nimscriptapi.nim may turn out to be a bad thing. |
| 13:49:38 | Araq_ | well that concern is just the top of the iceberg really. |
| 13:50:05 | Araq_ | Nim configuration cannot be done per Nimble package. Some people always enjoy to override the default C compiler, for instance. |
| 13:50:22 | dom96 | Yes, and I don't think the former is a valid concern. |
| 13:50:50 | Araq_ | whether I use GCC or Clang is only in edge cases a decision that should be left to the Nimble package |
| 13:51:00 | dom96 | Keeping nimble-related definitions in nimscript is a mistake. |
| 13:51:26 | dom96 | Why do you think the divergence may turn out to be a bad thing? |
| 13:53:27 | yglukhov | dom96. nimble supports tasks. nim supports tasks. what should i use? nimble myTask or nim myTask? will the behavior differ? will the behavior when nimscriptapi diverges? its so confusing. |
| 13:55:19 | yglukhov | my point is that either nim or nimble should stop providing ambiguous functionality. and yesterday i thought that nimble should run tasks, but nim configuration concern made me change my opinion to nim. |
| 13:57:27 | dom96 | I don't know anymore. |
| 13:57:53 | dom96 | If tasks are out of the picture then why support NimScript in Nimble at all? |
| 13:57:59 | * | boopisaway is now known as boop |
| 13:58:49 | Araq_ | use 'nimble task' unless it for some reason does not work, but it should since Nimble's features are a strict superset of Nim's features |
| 13:59:00 | dom96 | yeah |
| 13:59:15 | dom96 | Nimble can run any task that Nim can. |
| 13:59:29 | Araq_ | and for this Nimble really needs to support 'switch' and pass it to the Nim compiler. |
| 13:59:36 | dom96 | But the task must be defined inside a .nimble file. |
| 13:59:47 | Araq_ | yeah. |
| 14:01:54 | Araq_ | and yeah, we could think about removing 'nim task' from 'nim' so there is no confusion. If you want tasks, write a .nimble file. |
| 14:02:50 | Araq_ | setCommand("c") can then refer to a Nimble command. |
| 14:03:48 | * | Deavmj_web quit (Ping timeout: 252 seconds) |
| 14:03:52 | Araq_ | but I would leave 'nim task' as it is for now, I like to gain some experience how it all works out in practice. |
| 14:04:20 | Araq_ | 'nimble/nim tests' is an important feature that we need to get right. |
| 14:04:45 | Araq_ | for example, c2nim has its own test cases that end up comparing produced Nim files |
| 14:05:31 | dom96 | still not convinced about this whole 'switch'/'setCommand' stuff |
| 14:06:08 | dom96 | it seems like such an awkward way to change the command. |
| 14:06:11 | Araq_ | dom96: --foo:bar is just sugar for switch("foo", "bar") and it's absolutely essential for using Nimscript as the config system |
| 14:06:47 | dom96 | right. That's what it should be used for in Nim. |
| 14:06:58 | dom96 | hrm |
| 14:07:19 | dom96 | nah, it's just to weird to have Nim flags inside a .nimble file |
| 14:07:32 | Araq_ | it's not. |
| 14:07:49 | yglukhov | JNINativeInterface {.importc: "JNIEnv", header: jniHeader, incompleteStruct.} = object blablabla |
| 14:07:51 | dom96 | With that syntax it is |
| 14:08:00 | yglukhov | Araq: quick question. i define a type JNINativeInterface {.importc: "JNIEnv", header: jniHeader, incompleteStruct.} = object blablabla |
| 14:08:37 | yglukhov | somewhere in generated C code i get: TMP3775[117].offset = offsetof(struct JNINativeInterface_, NewGlobalRef); |
| 14:09:08 | yglukhov | can i get rid of that offsetofs? |
| 14:09:54 | dom96 | Araq_: It's fine to have an option called "buildFlags" |
| 14:10:06 | dom96 | but specifying build flags "globally" using `--` is just weird |
| 14:11:29 | dom96 | How is a user meant to know that these will be passed to Nim when building? |
| 14:12:15 | Araq_ | yglukhov: dunno, sorry. usually type info is only generated when something requires it. I guess you can make the codegen shut up for incompleteStruct though. |
| 14:12:36 | Araq_ | dom96: you can use --foo:bar in the task too. |
| 14:13:07 | Araq_ | doesn't have to be globally. |
| 14:15:52 | dom96 | but then it still begs the question, why don't I just exec "nim --foo:bar ..."? |
| 14:16:42 | Araq_ | --define:release |
| 14:16:56 | Araq_ | execNim "helper" |
| 14:17:07 | Araq_ | execNim "foo" |
| 14:17:25 | Araq_ | # builds helper and foo as release. |
| 14:17:44 | Araq_ | with strings I end up doing: |
| 14:17:52 | Araq_ | const flags = "--define:release" |
| 14:17:58 | dom96 | Okay |
| 14:18:03 | dom96 | But then it should be context sensitive |
| 14:18:04 | Araq_ | execNim "helper $1" % flags |
| 14:18:09 | dom96 | it shouldn't /just/ apply to Nim |
| 14:18:29 | Araq_ | etc etc, been there done that, I don't like string munging. |
| 14:19:02 | Araq_ | I only have to look at koch.nim to see it in action. |
| 14:19:11 | yglukhov | can i say that a type is a pointer to C struct with fields, and i don't know the name of the struct? |
| 14:19:35 | Araq_ | yes. Don't use .header then. |
| 14:19:47 | Araq_ | .header is overly restrictive anyway |
| 14:20:19 | Araq_ | who cares how the #includes of JNI look like and where to find them? |
| 14:21:03 | yglukhov | but if its an incomplete sctruct? |
| 14:21:13 | yglukhov | if i dont know its layout? |
| 14:21:16 | Araq_ | type Foo = ptr object |
| 14:21:29 | Araq_ | you only use the pointer, contents don't matter |
| 14:21:47 | yglukhov | but i want to refer to contents in my code =) |
| 14:21:57 | Araq_ | huh? |
| 14:22:15 | yglukhov | jnienv contains the function ptrs to jni impl. |
| 14:22:35 | Araq_ | so it's an imcomplete struct with known fields? |
| 14:22:46 | Araq_ | how is that incomplete then? |
| 14:22:59 | * | fedons quit (Quit: This computer has gone to sleep) |
| 14:23:18 | yglukhov | even more. Jnienv it's a pointer to struct (we don't know its name) with those functions. |
| 14:23:21 | Araq_ | is this some Posix shit where you only know "some of these fields exist but maybe more and we don't tell you the order" |
| 14:23:53 | yglukhov | Araq: you may say that. |
| 14:25:19 | Araq_ | how come you don't know the struct's name? gimme some link please |
| 14:27:30 | yglukhov | https://gist.github.com/yglukhov/f503cf27cb94857599c5 |
| 14:27:46 | yglukhov | please see how JNIEnv is defined in both files |
| 14:32:10 | * | fedons joined #nim |
| 14:35:55 | Araq_ | JNINativeInterface {.importc: "struct JNINativeInterface", header: jniHeader.} = object |
| 14:36:35 | * | bpr joined #nim |
| 14:37:01 | Araq_ | it's not incomplete at all, it's just that its name always starts with 'struct ' because C is a single big hack. |
| 14:37:59 | bpr | Hi |
| 14:39:29 | Araq_ | servus |
| 14:39:42 | yglukhov | Araq: you missed the point. on android JNIEnv is "JNINativeInterface", an mac is is "JNINativeInterface_" with underscore |
| 14:40:10 | yglukhov | but you're right that i can just define the struct without header dependency |
| 14:40:14 | yglukhov | ill probably do that |
| 14:40:40 | bpr | I tried several methods (ha!) to get rid of the top level closure procs in my method suite example (nesting the procs, removing and changing pragma to {.procvar.}, etc.) but new-ll still chokes on it. |
| 14:41:25 | Araq_ | what does 'chokes on it' mean? |
| 14:41:36 | Araq_ | bug or valid error message? |
| 14:42:12 | Araq_ | btw your code is totally weird |
| 14:42:31 | bpr | clang fails on the generated code. |
| 14:42:34 | Araq_ | the point of the closure is to hide your 'Figure/Circle' types |
| 14:43:02 | Araq_ | not to simply use the unspecific base type Figure everywhere instead |
| 14:43:06 | bpr | What does 'weird' mean? It was a fairly direct translation of Oberon code. |
| 14:43:37 | Araq_ | see what I just wrote. |
| 14:43:50 | Araq_ | clang failing means it's a bug. |
| 14:45:19 | Araq_ | yglukhov: const interfName = when defined(android): "JNINativeInterfac" else: "JNINativeInterface_" |
| 14:45:25 | Araq_ | importc: inferName ? |
| 14:45:32 | Araq_ | importc: interfName ? |
| 14:47:31 | bpr | The point of the code was to demonstrate run time dispatching without calling 'method'. |
| 14:51:05 | yglukhov | Araq: thats a dirty fix. who knows what else can JNIEnv be on other platforms. |
| 14:52:36 | Araq_ | what? JNI seems to be platform specific and you consider platform specific code dirty? |
| 14:53:48 | Araq_ | bpr: well is your gist still valid to reproduce the bug? |
| 15:00:06 | bpr | Yes, I just tried it now with new-ll and OS X and I get 'Error: execution of an external compiler program' blah blah blah |
| 15:00:36 | bpr | bbl |
| 15:01:46 | Araq_ | ok, will fix it. but afaict your code doesn't need .closure, you got just use .nimcall instead for your proc types |
| 15:04:51 | * | bpr quit (Ping timeout: 252 seconds) |
| 15:38:03 | dom96 | hah cool https://github.com/yglukhov/nimble-tag |
| 15:39:44 | * | vendethiel quit (Read error: Connection reset by peer) |
| 15:40:07 | * | vendethiel joined #nim |
| 15:44:33 | dom96 | Araq_: I'm going to implement pre/post-hooks for now. Implementing install(), uninstall() (etc for each nimble command) + an override is much more work |
| 15:46:03 | * | bpr joined #nim |
| 15:47:44 | bpr | I tried {.closure.}, {.procvar.}, and {.nimcall.}. With the latter two, I get type errors from nim suggesting that {.closure.} is expected. |
| 15:48:05 | reactormonk | bpr, code plz |
| 15:48:27 | bpr | I already posted the gist. |
| 15:51:50 | * | matias quit (Quit: WeeChat 1.3) |
| 15:52:09 | * | thotypous joined #nim |
| 16:04:14 | * | fedons quit (Quit: This computer has gone to sleep) |
| 16:05:13 | * | krux02 joined #nim |
| 16:13:19 | * | bpr quit (Quit: Page closed) |
| 16:24:04 | * | fedons joined #nim |
| 16:25:14 | krux02 | how can I distinguish in a typed macro the two distinct int types? getType is on both types distinct[int]. |
| 16:30:25 | krux02 | anyone online? |
| 16:31:24 | * | yglukhov_ joined #nim |
| 16:34:27 | * | yglukhov_ quit (Remote host closed the connection) |
| 16:35:00 | * | yglukhov_ joined #nim |
| 16:35:05 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 16:38:23 | Arrrr | Yes, but we dont know and we just pretend we are sleeping |
| 16:43:23 | * | polde quit (Ping timeout: 250 seconds) |
| 16:44:46 | krux02 | :/ |
| 16:45:39 | reactormonk | I know, but I'm actually sleeping. |
| 16:48:07 | Arrrr | Why do you need that krux02 ? |
| 16:49:33 | krux02 | I have several types that are all just distinct int types, and in a macro I would like to have different behavior depending on the type. |
| 16:50:00 | krux02 | the proplem is, that getType in the typed macro expression always returns distinct[int], and not the name |
| 16:50:11 | krux02 | so I cant't distinguish any of the types. |
| 16:50:41 | Arrrr | I suppose you dont have other choice than to dive in those nodes and get the name by yourself |
| 16:51:09 | krux02 | there is no name in the nodes |
| 16:52:00 | krux02 | BracketExpr |
| 16:52:00 | krux02 | Sym "distinct" |
| 16:52:00 | krux02 | Sym "int" |
| 16:52:28 | krux02 | getType is the same result on all types |
| 16:52:31 | krux02 | that's the problem |
| 16:54:18 | Arrrr | Yes, what i mean is that you should give up getType |
| 16:54:44 | krux02 | then what should I do then? |
| 16:55:05 | Arrrr | node[0][0][1][n] ... |
| 16:55:09 | Arrrr | by hand |
| 16:56:20 | krux02 | the node is just a symbol |
| 16:56:44 | krux02 | node[0] is already not defined |
| 16:57:00 | yglukhov_ | krux02: related https://github.com/nim-lang/Nim/pull/3667 |
| 16:57:05 | * | fedons quit (Quit: This computer has gone to sleep) |
| 16:57:45 | yglukhov_ | krux02: related as well https://github.com/yglukhov/variant/blob/master/variant.nim#L200 |
| 16:58:41 | yglukhov_ | Araq, ping as well =) |
| 17:01:33 | krux02 | actually what Araq wrote in that link is totally what makes it complicated for me. |
| 17:01:46 | krux02 | nice to see that people are aware of this |
| 17:07:43 | * | allan0_ quit (Quit: no) |
| 17:08:27 | * | allan0 joined #nim |
| 17:20:01 | * | BitPuffin|osx joined #nim |
| 17:23:32 | * | desophos joined #nim |
| 17:23:52 | krux02 | here I made a forum post http://forum.nim-lang.org/t/1910/1#11808 |
| 17:24:18 | krux02 | I pit in some more detail |
| 17:26:54 | * | pregressive joined #nim |
| 17:28:25 | * | Demon_Fox joined #nim |
| 17:32:15 | * | thotypous quit (Quit: WeeChat 1.3) |
| 17:32:32 | * | thotypous joined #nim |
| 17:34:12 | * | fedons joined #nim |
| 17:43:07 | * | vikaton joined #nim |
| 18:01:47 | * | Ven joined #nim |
| 18:18:42 | Araq_ | krux02: that's just a getType() bug, I can fix it later |
| 18:25:28 | * | yglukhov joined #nim |
| 18:28:29 | * | yglukhov_ quit (Ping timeout: 255 seconds) |
| 18:29:35 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 18:39:44 | * | krux02 quit (Quit: Verlassend) |
| 18:45:20 | onionhammer | Araq, what kind of new gc is this? |
| 19:03:46 | Araq_ | onionhammer: should fix the annoying memory leaks that people report with async |
| 19:07:44 | * | pregressive quit (Remote host closed the connection) |
| 19:10:43 | * | fedons quit (Quit: This computer has gone to sleep) |
| 19:21:09 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 19:22:38 | * | yglukhov joined #nim |
| 19:22:51 | * | Ven joined #nim |
| 19:26:14 | * | fedons joined #nim |
| 19:27:10 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 19:27:43 | * | matkuki joined #nim |
| 19:30:22 | * | fedons quit (Client Quit) |
| 19:36:58 | * | yglukhov joined #nim |
| 19:38:23 | * | yglukhov quit (Client Quit) |
| 19:39:47 | * | shodan45 joined #nim |
| 19:40:01 | * | yglukhov joined #nim |
| 19:42:21 | * | yglukhov quit (Read error: Connection reset by peer) |
| 19:46:38 | * | yglukhov joined #nim |
| 19:55:24 | * | darkf quit (Quit: Leaving) |
| 19:57:13 | * | kernasi joined #nim |
| 19:57:15 | kernasi | hi |
| 20:01:10 | kernasi | guys, ian murdock committed suicide :( |
| 20:01:15 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 20:03:13 | * | pregressive joined #nim |
| 20:05:31 | dom96 | That's sad to hear :\ |
| 20:06:39 | vikaton | https://www.youtube.com/watch?v=zKK9I-OvZng |
| 20:06:44 | vikaton | Nim Gource Visiual ^ |
| 20:06:48 | vikaton | Visual* |
| 20:07:52 | Arrrr | "He complained of police brutality and said they ripped off his undergarments" |
| 20:08:12 | Arrrr | He said he was to commit suicide on twitter |
| 20:11:29 | dom96 | indeed. Just read that. Really sad. |
| 20:12:30 | vikaton | o man bad timing :( |
| 20:13:02 | kernasi | he died in the age of 42 |
| 20:15:10 | Arrrr | Ey vikaton, long time no see. Are you still nimming around? |
| 20:16:27 | vikaton | Arrrr: not at the moment, I'm learning C atm |
| 20:17:06 | Arrrr | That's important |
| 20:17:24 | kernasi | nim is more interesting, vikaton :) |
| 20:18:07 | vikaton | kernasi: what powers Nim's interesting features? :) |
| 20:18:36 | * | yglukhov quit (Remote host closed the connection) |
| 20:18:54 | kernasi | just wanted to tease you :) |
| 20:35:39 | matkuki | Anyone tried viewing winlean module docs of the standard library? http://nim-lang.org/docs/winlean.html |
| 20:35:40 | matkuki | I get a 404 error |
| 20:36:22 | kernasi | http://nim-lang.org/0.11.0/winlean.html <-- old but perhaps it helps |
| 20:36:39 | matkuki | kernasi: thanks |
| 20:45:43 | * | pregressive quit (Remote host closed the connection) |
| 20:46:15 | matkuki | dom96: Should an issue be opened for this? http://nim-lang.org/docs/winlean.html |
| 20:46:56 | dom96 | yeah |
| 20:46:57 | dom96 | please |
| 20:47:04 | matkuki | OK |
| 20:49:24 | * | yglukhov joined #nim |
| 20:54:50 | * | boop quit (Ping timeout: 246 seconds) |
| 20:56:20 | matkuki | dom96: which repository should the issue go to? |
| 20:57:54 | Arrrr | Merry christmas |
| 20:57:56 | * | Arrrr quit (Quit: WeeChat 1.2) |
| 20:57:57 | dom96 | nim-lang/nim |
| 20:58:40 | dom96 | yglukhov: I implemented pre/post hooks in Nimble, I don't think I'll be able to get runtime imports for this release though. |
| 20:58:43 | matkuki | dom96: ok, i didn't mess up, thanks. Done |
| 21:01:35 | yglukhov | dom96: nice. does it now support install hooks? |
| 21:03:10 | dom96 | yglukhov: it should, yeah |
| 21:03:48 | dom96 | You can also return `false` from them to prevent the execution of the action. |
| 21:03:53 | dom96 | before install: return false |
| 21:04:45 | yglukhov | super-awesome! pity i still dont have a need for them =)) |
| 21:07:23 | yglukhov | is anyone here proficient in javascript? i want to make a nim regressions collector, and it kinda works locally but not online. some CORS problem. http://yglukhov.github.io/regressnim/ |
| 21:10:06 | * | dv is now known as dv- |
| 21:13:57 | * | boop joined #nim |
| 21:16:04 | Araq_ | what does CORS mean? |
| 21:17:12 | yglukhov | cross-origin requests. the "security" you like to talk about ;) |
| 21:19:38 | yglukhov | the "security" mechanism which is implemented in clients to protect servers. haha.... |
| 21:22:47 | * | yglukhov quit (Remote host closed the connection) |
| 21:34:27 | * | sora joined #nim |
| 21:50:05 | * | yglukhov joined #nim |
| 21:54:07 | * | JStoker quit (Excess Flood) |
| 21:54:24 | * | JStoker joined #nim |
| 22:00:14 | * | deavmi_mobile quit (Read error: Connection reset by peer) |
| 22:09:28 | * | deavmi_mobile joined #nim |
| 22:11:12 | M-max | Is there a design reason why closure iterators can't be recursive? Or is it just not implemented yet? |
| 22:11:39 | * | pregressive joined #nim |
| 22:13:11 | * | sora quit (Remote host closed the connection) |
| 22:15:06 | M-max | I'm trying to walk a directory tree, excluding some subdirectories - strikes me as a good use case for recursive iterators, but perhaps there's a reason why that's bad. (I get why inline iterators can't be recursive) |
| 22:15:26 | * | JStoker quit (Ping timeout: 240 seconds) |
| 22:15:33 | Araq_ | M-max: closure iterators translate into a state machine. state machines don't have a stack. |
| 22:16:21 | Araq_ | there is some support for proper coroutines in Nim, but these are not used for closure iterators and ... well I cannot see them work well with async where the main goal is to get rid of stacks |
| 22:16:29 | * | shodan45 quit (Quit: Konversation terminated!) |
| 22:16:38 | M-max | So it's a function of the implementation |
| 22:17:35 | M-max | (Sorry, not really understanding your answer) |
| 22:18:25 | M-max | Ok, will need to come up with a different design :) |
| 22:18:27 | Araq_ | no, more like a concious worse-is-better tradeoff |
| 22:19:09 | Araq_ | different design: append to sequence in the proc and make the iterator call the recursive helper proc |
| 22:19:38 | Araq_ | that's what the compiler and stdlib does too when this problem arises |
| 22:19:40 | * | zepolen quit (Remote host closed the connection) |
| 22:19:40 | M-max | But what if the sequence is really big? |
| 22:20:13 | Araq_ | you're more likely to run out of stack space rather than of heap space |
| 22:20:25 | M-max | Fair point |
| 22:20:42 | M-max | Guess it depends if my directory is wide or deep :) |
| 22:21:06 | Araq_ | well there are other approaches. you can also model the stack explicitly. |
| 22:21:30 | Araq_ | that way you get the same log N storage requirements that a tree walk might result into |
| 22:22:04 | Araq_ | and ... that's also what the compiler does in its ropes.nim module, check it out |
| 22:22:37 | M-max | Hmm. Food for thought. Ah, haven't looked at ropes implementation, will check it out |
| 22:23:10 | Araq_ | if you're really cool, you write a macro that does the transformation for you |
| 22:23:50 | Araq_ | hrm ... well yeah, actually. We could do that in the compiler too. XD |
| 22:24:03 | M-max | :) |
| 22:24:38 | Araq_ | never considered it. It's hard to do for mutually recursive procs, but for simple recursions it seems doable |
| 22:25:05 | M-max | Think I'll go with recursive procs and a big sequence for now. Am saving diving into macros for elsewhere in the code... |
| 22:25:23 | Araq_ | but oh well, as I said, it doesn't come up that often and manual recursion elimination makes you a better programmer. :P |
| 22:25:37 | M-max | Or look into how walkFiles works |
| 22:26:03 | Araq_ | walkFiles is not particularly stimulating. |
| 22:26:05 | * | JStoker joined #nim |
| 22:26:15 | Araq_ | ropes is more interesting. |
| 22:26:28 | M-max | You could always add tail call elimination? |
| 22:28:42 | M-max | Ah. A stack. That's probably good enough for my purposes |
| 22:29:38 | M-max | Much less scary than I thought - barely more work than the recursive call :) |
| 22:34:32 | M-max | On macros, is there any reason why I can't create a data structure in a static block, then pass it into a macro to create a class that matches that structure? All the examples I've seen are passing expressions into the macro not, for example, dicts of strings |
| 22:35:17 | M-max | This is for an argparse clone I'm writing, but I imagine something similar would be needed for an ORM |
| 22:45:30 | Araq_ | not sure what you mean but macros that go up in the syntax tree are an abomination, IMO. |
| 22:45:43 | * | JStoker quit (Excess Flood) |
| 22:45:58 | * | JStoker joined #nim |
| 22:47:30 | * | pilne joined #nim |
| 22:50:05 | * | JStoker quit (Excess Flood) |
| 22:50:29 | * | JStoker joined #nim |
| 22:53:51 | * | kernasi quit (Quit: n8 int9h) |
| 22:56:01 | M-max | I want to be able to have a user say that a type should have a foo member (of a particular type) and then be able to call it from my code and from theirs in a type- and existence-safe way. Guess I'll have to finish my work and show you :) |
| 22:58:43 | Araq_ | seems easy to do with getType() |
| 22:59:24 | Araq_ | so how does this travis thing work? do I have to create a PR or does it test my branch already? |
| 23:00:51 | * | fedons joined #nim |
| 23:07:27 | * | irrequietus quit () |
| 23:17:03 | NimBot | nim-lang/Nim new-ll 2162a71 Andreas Rumpf [+0 ±1 -0]: closure iterators do have 'result' |
| 23:17:03 | NimBot | nim-lang/Nim new-ll 307a609 Andreas Rumpf [+0 ±10 -0]: made closure iterators tests green, updated docs |
| 23:19:57 | * | pilne left #nim ("Leaving") |
| 23:21:22 | * | yglukhov quit (Remote host closed the connection) |
| 23:25:58 | * | matkuki quit (Quit: ChatZilla 0.9.92 [Firefox 43.0.3/20151223140742]) |
| 23:32:13 | * | boop is now known as boopisaway |
| 23:48:18 | * | krux02 joined #nim |
| 23:53:35 | * | shodan45 joined #nim |