00:03:14 | * | opi_ joined #nim |
00:07:28 | * | opi_ quit (Ping timeout: 250 seconds) |
00:18:03 | * | tzui quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
00:35:29 | * | so joined #nim |
01:01:22 | * | opi_ joined #nim |
01:05:54 | * | opi_ quit (Ping timeout: 264 seconds) |
01:19:21 | * | abm quit (Ping timeout: 260 seconds) |
01:24:35 | * | gsilvapt1 joined #nim |
01:32:58 | * | gsilvapt1 quit (Ping timeout: 245 seconds) |
01:40:37 | FromGitter | <retsyo> hi, all. Is there any nim packages for math integral, and finding roots? |
02:04:11 | * | kapil___ joined #nim |
02:27:55 | * | skellock quit (Quit: WeeChat 1.9.1) |
02:47:08 | * | slothtrop quit (Ping timeout: 245 seconds) |
03:06:21 | * | dddddd quit (Remote host closed the connection) |
03:13:08 | FromGitter | <zacharycarter> @kayabaNerve - yes |
03:13:10 | FromGitter | <zacharycarter> all day long |
03:14:59 | dom96 | HTTP/JSON? What's wrong with that? |
03:15:51 | FromGitter | <zacharycarter> It's just heavy for backend services talking to each other |
03:16:14 | FromGitter | <zacharycarter> especially when you have services toss payloads of several hundred KBs across the wire |
03:16:25 | FromGitter | <zacharycarter> and you have to invoke multiple services to get at the data you need |
03:18:16 | FromGitter | <zacharycarter> would be better off using rpc with a less heavy protocol |
03:19:05 | FromGitter | <zacharycarter> err sorry - less heavy data format - whatever I'm tired |
03:20:24 | FromGitter | <zacharycarter> @retsyo I'm not sure - have you tried https://nimble.directory/ ? |
03:30:39 | dom96 | oh, I didn't realise it was for backend service communication |
03:31:00 | dom96 | Thought you were talking about web browser -> server |
03:36:31 | FromGitter | <zacharycarter> nah - I wish |
03:36:54 | FromGitter | <zacharycarter> well - I guess I don't really care - it's their issue not mine |
03:46:00 | * | slothtrop joined #nim |
03:46:00 | * | slothtrop quit (Client Quit) |
03:46:02 | * | arecaceae quit (Remote host closed the connection) |
03:46:23 | * | arecaceae joined #nim |
03:47:03 | FromGitter | <kayabaNerve> I would just use ASCII/UTF-8 strings + readLine. Nice and simple. Supported by every platform. |
03:49:30 | FromGitter | <Varriount> Anyone seen this? https://github.com/piscisaureus/wepoll |
03:53:07 | FromGitter | <gogolxdong> I'm compiling https://github.com/emekoi/nimkernel hints Error: system module needs: nimToCStringConv |
03:54:08 | FromGitter | <zacharycarter> @Varriount nope - looks interesting though! |
04:14:21 | FromGitter | <gogolxdong> anyone compiled the kernel with devel branch? |
04:29:38 | FromGitter | <gogolxdong> after some tweaking, it returns ⏎ Error: execution of an external compiler program 'gcc -c -w -ffreestanding -fno-stack-protector -nostdlib -Wall -Wextra -O3 -fno-strict-aliasing -I/root/nimkernel/src/runtime -I/root/nimkernel/src/runtime/nlibc/include -o /root/.cache/nim/main_r/boot.c.o /root/.cache/nim/main_r/boot.c' failed with exit code: 1 ⏎ ⏎ /root/.cache/nim/main_r/boot.c: Assembler messages: ⏎ |
04:29:38 | FromGitter | ... /root/.cache/nim/main_r/boot.c:69: Error: symbol `kernel_start' is already defined [https://gitter.im/nim-lang/Nim?at=5ba9b9b256877c463a7d14c3] |
04:37:27 | * | PrimHelios quit (Quit: Leaving) |
04:38:01 | * | miran joined #nim |
04:52:50 | FromGitter | <gogolxdong> qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000000a0000 |
04:57:40 | FromGitter | <vivekimsit> Hi Guys, can anyone please check my last message, I am getting error while publishing the library |
05:02:09 | leorize | vivekimsit: please repost it |
05:02:58 | FromGitter | <vivekimsit> Error: unhandled exception: Connection was closed before full request has been made [ProtocolError] |
05:04:38 | * | ludwig joined #nim |
05:06:45 | FromGitter | <codenoid> good evening all ✨ |
05:17:11 | leorize | vivekimsit: Is there any stack trace? |
05:17:27 | FromGitter | <vivekimsit> no |
05:18:10 | FromGitter | <vivekimsit> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ba9c5128ddf5867dc6d3422] |
05:29:07 | * | nsf joined #nim |
05:30:37 | * | jdevlieghere joined #nim |
05:33:25 | * | jdevlieghere quit (Killed (Sigyn (Spam is off topic on freenode.))) |
05:38:18 | * | darithorn quit (Quit: Konversation terminated!) |
05:43:17 | * | ludwig quit (Quit: WeeChat 2.2) |
05:54:17 | * | opi24 joined #nim |
06:01:04 | * | opi24 quit (Remote host closed the connection) |
06:04:13 | * | miran quit (Ping timeout: 245 seconds) |
06:09:52 | * | ponkyS1 joined #nim |
06:14:04 | * | ponkyS1 quit (Remote host closed the connection) |
06:25:34 | * | jamesdenton6 joined #nim |
06:32:01 | * | jamesdenton6 quit (Ping timeout: 260 seconds) |
06:48:43 | * | hihihi joined #nim |
06:49:55 | * | hihihi quit (Client Quit) |
06:54:15 | * | chemist69 joined #nim |
06:55:00 | chemist69 | Hi, for a defined custom `type MyTable = Table[int, int]`, how can an instance of this type be initialized? |
06:55:06 | chemist69 | (other than `var t = initTable[int, int]()`, which kind of defeats the purpose of defining the custom type) |
06:57:47 | cavariux | the initTable is a proc so you can make your own proc to init it |
06:59:04 | cavariux | chemist69, the [int, int] is a generic, so you can remove them in your own proc just returning the generated value |
07:04:22 | chemist69 | cavariux: yes, thanks. I was more thinbking if there was a way to generically initialize these self-defined tables. |
07:04:41 | chemist69 | like var `t = init(MyTable)` |
07:05:34 | chemist69 | So I have to define the initializer for each custom type myself? |
07:05:52 | cavariux | not all of them, just some that need to do heap allocation like the table |
07:06:20 | cavariux | you could make your own init proc that receives certain data and create the table |
07:06:38 | chemist69 | yes, ok. |
07:07:13 | Araq | chemist69: there is a well-thought out RFC about it, somewhere. |
07:07:28 | Araq | and likely to be accepted and implemented eventually |
07:07:32 | Araq | :-)# |
07:07:46 | chemist69 | Thanks, Araq, I will look it up. |
07:09:00 | cavariux | Araq have you used vulkan? |
07:09:18 | cavariux | if so, what do you think would fit better nim, vulkanhpp or vanilla vulkan? |
07:11:15 | Araq | never used it, sorry |
07:11:34 | Araq | but "vanilla vulkan" I guess |
07:11:53 | Araq | if in doubt, leave out one level of indirection |
07:12:55 | cavariux | haha, thanks Araq |
07:15:46 | FromGitter | <narimiran> Araq: is this the RFC that you mentioned: https://github.com/nim-lang/Nim/issues/7474 ? |
07:16:46 | chemist69 | I think, it's this one: https://github.com/nim-lang/Nim/issues/7832 |
07:24:54 | * | opi_ joined #nim |
07:46:16 | * | leru joined #nim |
07:51:30 | Araq | chemist69: yeah, that one |
07:52:47 | * | koobs28 joined #nim |
07:55:22 | * | koobs28 quit (Remote host closed the connection) |
07:56:24 | * | Dragonkeeper6 joined #nim |
07:58:52 | * | Dragonkeeper6 quit (Remote host closed the connection) |
08:00:24 | * | abm joined #nim |
08:02:49 | * | gmpreussner_ quit (Ping timeout: 246 seconds) |
08:03:40 | * | gmpreussner joined #nim |
08:11:55 | FromGitter | <Bennyelg> Liked the proposal # 1 |
08:12:59 | * | xet7 joined #nim |
08:17:26 | * | floppydh joined #nim |
08:27:30 | FromGitter | <alehander42> @Araq so actually caseStmtMacros idea is to override match for the case arg type ? I initially thought it works in a different way |
08:29:09 | Araq | I don't know |
08:29:18 | Araq | well yes. |
08:31:01 | FromGitter | <alehander42> in my lib I can use this to maybe limit the valid patterns for each type and improve error messages (e.g. error "You can't use @[..] pattern with an object type A") |
08:31:23 | Araq | "so does this mean the macro would be invoked for every case usage? this would kinda break case" |
08:31:29 | Araq | I don't understand this question. |
08:32:01 | FromGitter | <alehander42> that's because currently my macro assumes `n` is `untyped` |
08:32:39 | FromGitter | <alehander42> but nvm, when I wrote that comment I thought caseStmtMacro works differently |
08:33:44 | Araq | well it's based on overloading |
08:34:12 | Araq | but the macro gets to transform the full case body, not just the selector expression which the overloading is based on |
08:34:23 | FromGitter | <alehander42> yeah, yeah, I get it now |
08:34:24 | Araq | slightly subtle but I found this to be the best design |
08:34:48 | FromGitter | <alehander42> I see the idea |
08:35:04 | FromGitter | <alehander42> so what I do instead in my lib is this concept of "unpackers" |
08:35:19 | FromGitter | <alehander42> the point is that it seems simpler to me to add special behavior for types |
08:35:23 | FromGitter | <alehander42> with it |
08:35:51 | FromGitter | <alehander42> because you just have to return a seq or a tuple of values |
08:36:30 | FromGitter | <alehander42> e.g. |
08:38:22 | * | Widdershins quit (Ping timeout: 244 seconds) |
08:43:01 | FromGitter | <alehander42> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ba9f51541177e0bc7a291d4] |
08:43:59 | * | PMunch joined #nim |
08:46:48 | * | Widdershins joined #nim |
08:50:45 | FromGitter | <alehander42> or e.g. if I extend unpackers a bit |
08:50:56 | * | Vladar joined #nim |
08:51:43 | FromGitter | <alehander42> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ba9f71f8ddf5867dc6e45b3] |
08:52:42 | FromGitter | <alehander42> my point is that usually it seems simpler to return some data (or maybe an iterator) than to rewrite the whole case stmt |
08:55:50 | Araq | fair but that could also be just a helper to rewrite the whole case stmt |
08:56:06 | Araq | that every overloaded 'match' macro ends up using |
08:58:37 | * | data-man joined #nim |
08:59:21 | FromGitter | <alehander42> or even better ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ba9f8e941177e0bc7a2a99f] |
08:59:55 | FromGitter | <alehander42> yeah one can add a helper, but then it seems that one would lose consistency |
09:00:36 | FromGitter | <alehander42> e.g. I don't know if the match for type `Magic` doesn't rewrite its macro in some bizarre way, so now `@[..]` matches an integer and `@name` matches a tuple |
09:04:01 | FromGitter | <alehander42> also, I support a limited kind of expressions as branch conditions, as I assume they're all patterns, and e.g. I always rewrite top level `and` to an if guard |
09:06:21 | FromGitter | <alehander42> so let's see what happens if a pass a bool ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ba9fa8d691dc567db9dc1eb] |
09:08:50 | FromGitter | <alehander42> which is a simple example, but I feel it would be hard to be fully consistent with `case` (and you don't want to change case's default behavior for builtin types, but you still want to support them in special ways, e.g. capturing seq elements or unifying tuple fields) |
09:14:28 | * | LotR4 joined #nim |
09:14:50 | * | LotR4 quit (Remote host closed the connection) |
09:15:36 | chemist69 | Do I have to implement a hash function for my enum when I want to use it as keys in a table? https://gist.github.com/apahl/a23280267324baf7f2769ad692d563a8 |
09:16:00 | skelett | Hi all, is there a way to have compile time object variants - similiar to this: http://ix.io/1nuq ? |
09:19:50 | Araq | chemist69: better use an array[MyEnum, T] instead |
09:19:58 | FromGitter | <alehander42> Araq tl;dr it seems hard to combine having some "always available" dsl features with the ability for an user to rewrite freely a branch: which makes reading `of` very hard, as you need to know if caseStmtMacros were enabled and if a match overload introduced/changed syntax ⏎ ⏎ the last point is important: currently library's `match` defined a single DSL which is mostly consistent: extensions all use the same |
09:19:58 | FromGitter | ... syntax of `Name(elements)` |
09:21:20 | Araq | alehander42: well the idea is we put a standard DSL in sugar.nim and be done with it |
09:22:02 | FromGitter | <alehander42> yeah, but if one can freely rewrite the statement |
09:22:14 | Araq | and it's nice that 'case' can be used with the familiar syntax rather than 'match foo:' with the enforced colon at the end which 'case' doesn't require |
09:22:14 | FromGitter | <alehander42> I can't be sure the standard DSL isn't overriden |
09:22:27 | Araq | though maybe we can patch the parser to make this colon optional. |
09:23:30 | FromGitter | <alehander42> because if you can override the whole statement in `match` the standard DSL stops being standard |
09:24:03 | FromGitter | <alehander42> yeah, I think the colon thing can be fixed |
09:24:07 | Araq | well you can be sure that the DSL is made fit to the type at hand, an Option[T] match doesn't need unification |
09:24:14 | FromGitter | <alehander42> (I didn't even know one can use case without it) |
09:24:28 | chemist69 | Araq: even when the enum is not continuous (as in my case)? |
09:24:38 | Araq | skelett: that is currently not supported and you need to use 'let' instead |
09:25:08 | Araq | the enum shouldn't have holes, I hate holes and am writing an RFC to remove this misfeature |
09:25:15 | FromGitter | <alehander42> are you sure? I might want to do ⏎ `of Some([0, 0, _, @last]):` |
09:25:44 | FromGitter | <alehander42> the point is that I want to keep subpatterns always working consistently |
09:25:48 | skelett | Araq: Ok thanks! |
09:25:54 | chemist69 | Ok, good to know. Then I shouldn't be using an enum for my type Element in the first place. |
09:26:21 | FromGitter | <alehander42> so it would make perfect sense to be able to unify subvalues of an option in a `of` |
09:28:14 | FromGitter | <alehander42> how would overloading `match` preserve subpatterns behavior (without a lot of code) |
09:32:26 | Araq | well it wouldn't, it's more adhoc and I imagine that the DSL I want to have for the compiler's PNode is very different from a DSL I want to have for "general" subpatterns |
09:32:53 | Araq | for example the compiler Nodes include line information that I never want to match on |
09:33:14 | Araq | but maybe I'm wrong. :-) |
09:33:54 | FromGitter | <mratsim> We need a stdlib module that mimicks enum with holes including set with a int backend then |
09:46:07 | FromDiscord | <Tomohiro> I think you can use sets module if you want to use set with int type |
09:47:21 | * | Guest17626 joined #nim |
09:47:51 | FromGitter | <alehander42> Araq well, you don't need to match on it: you can just pass the fields you're interested in |
09:48:44 | FromGitter | <alehander42> PNode is a perfectly usual variant type |
09:50:33 | * | Guest17626 quit (Remote host closed the connection) |
09:52:30 | FromGitter | <alehander42> you can always just do stuff like ⏎ ⏎ ```of nkCall(sons: @[_, (typ: (kind: SomeType))]):``` [https://gitter.im/nim-lang/Nim?at=5baa055e8ddf5867dc6ea216] |
09:54:10 | FromGitter | <mratsim> @Tomohiro, it’s regarding removing enum with holes. |
09:54:58 | FromGitter | <alehander42> equivalent to ⏎ `if a.kind == nkCall and a.sons.len == 2 and not a.sons[1].isNil and not a.sons[1].typ.isNil and a.sons[1].typ.kind == SomeType` |
09:55:40 | FromGitter | <alehander42> Araq: if you want something closer to newTree you can still just override unpack for PNode and have |
09:55:54 | FromGitter | <alehander42> ```of nnkCall(_, (typ: (kind: SomeType)))``` |
09:56:04 | FromGitter | <alehander42> and the override is |
09:57:11 | FromGitter | <alehander42> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5baa06777bd81c5b9dae35c9] |
10:00:59 | FromGitter | <alehander42> in any way, you *don't* want to break default matching on your type: if I know how to match some kind of object in Nim, this knowledge should be transferrable in all cases (e.g. variant => all variant objects) |
10:03:19 | * | yuitimothy4 joined #nim |
10:03:32 | FromGitter | <alehander42> (now, one should be able to define unpack as a template instead of a proc to make sure it's zero overhead, that's TODO) |
10:07:28 | * | yuitimothy4 quit (Remote host closed the connection) |
10:09:03 | Araq | alehander42: maybe, I need to try it out. |
10:09:29 | Araq | if in the end experimental case macros are removed again, that's fine with me |
10:12:42 | leorize | Araq: please merge https://github.com/nim-lang/Nim/pull/9065 |
10:14:11 | * | stefanos82 joined #nim |
10:14:48 | FromGitter | <alehander42> @Araq I still need to fix several bugs today, but when I do, I'll try to add some more examples with existing nim types/libs |
10:27:07 | * | chicocvenancio23 joined #nim |
10:29:02 | * | chicocvenancio23 quit (Remote host closed the connection) |
10:37:11 | * | searedvandal12 joined #nim |
10:41:52 | * | searedvandal12 quit (Remote host closed the connection) |
10:49:03 | FromGitter | <mratsim> why would case macros would be removed? |
10:49:10 | FromGitter | <mratsim> type matching issues? |
10:55:41 | * | SenasOzys quit (Ping timeout: 260 seconds) |
11:13:03 | Araq | mratsim: alehander42 argues they are more harmful than useful |
11:13:16 | * | kapil___ quit (Quit: Connection closed for inactivity) |
11:13:17 | FromGitter | <narimiran> i've seen that Zig language was added to https://godbolt.org/ . what prevents Nim to be added? |
11:13:32 | FromGitter | <mratsim> Is there a RFC with the details @alehander42 ? |
11:14:21 | FromGitter | <narimiran> now i've seen this: https://github.com/mattgodbolt/compiler-explorer/issues/206 |
11:20:32 | * | data-man quit (Quit: Konversation terminated!) |
11:26:43 | FromGitter | <bung87> I’m developping a lib ,what ‘ s the right way to specify the resource file path ? ⏎ `mm = memfiles.open("src/maxnseg/backward_gram.dict", mode = fmRead)` I do this currently |
11:27:50 | FromGitter | <kaushalmodi> On Tildes (you need an account to see this, let me know if you need one):https://tildes.net/~comp/6pb/nim_a_programming_language_underdog |
11:28:34 | FromGitter | <kaushalmodi> Many people are just pissed at compile error on tabs, and not willing to look at the Nim features past that.. |
11:29:23 | FromGitter | <kaushalmodi> I don't get why folks are so uptight.. why can't they accept TAB as invalid syntax? Period. |
11:29:55 | Araq | they can use any editor that can convert tabs to spaces. Which is every editor I know about. |
11:30:01 | FromGitter | <zacharycarter> People program in one style of language and get used to it and think anything else is wrong |
11:30:05 | FromGitter | <zacharycarter> that too |
11:30:28 | FromGitter | <zacharycarter> People I talk to complain about whitespace and lack of braces / semis |
11:30:39 | FromGitter | <zacharycarter> you can't win with syntax design w/ everyone |
11:30:45 | FromGitter | <zacharycarter> someone is going to be miffed |
11:31:52 | FromGitter | <kaushalmodi> Yeah, I'd think that such people are not ready or qualified to use Nim :P |
11:31:57 | stefanos82 | I used to dislike whitespace syntax in languages, but Python soften my eccentricity and Nim with its 2-spaces made me love it |
11:35:06 | Araq | btw you *can* use tabs in Nim with a #? filter |
11:36:08 | FromGitter | <kaushalmodi> :) |
11:37:27 | FromGitter | <kaushalmodi> A random thought, different topic: Would it be possible to override docgen behavior using a user library |
11:38:02 | stefanos82 | Araq: tabs...yuck lol! |
11:38:08 | FromGitter | <kaushalmodi> I was just curious.. what if I used Markdown for doc strings and parsed then as so when generating docs? |
11:38:57 | FromGitter | <kaushalmodi> I.e. have the RST parsing modular enough to be replaced with Markdown parsing (or may be even.. ahem.. Org mode parsing) |
11:39:15 | Araq | I don't think it's that wise. We are in the "force me" age of programming. |
11:39:41 | Araq | so we force you to use RST. You should appreciate we treat you as some code zombie. |
11:40:00 | Araq | bbl |
11:40:29 | FromGitter | <kaushalmodi> I started thinking of this when I saw the limitation of inline formatting in RST yesterday |
11:40:46 | FromGitter | <kaushalmodi> I.e. you cannot nest monospace in italics, and such |
11:41:02 | FromGitter | <kaushalmodi> (may be the RST developer did not like recursion) |
11:48:35 | FromDiscord | <Shield> is it just me or the docs for the system module doesn't show all the atomic functions? |
11:49:13 | FromDiscord | <Shield> what's the correct function for getting/setting the value of an atomic bool? |
12:07:43 | * | SenasOzys joined #nim |
12:19:29 | FromGitter | <Quelklef> What do you mean |
12:19:36 | FromGitter | <Quelklef> @Shield |
12:20:19 | c15ade4 | C++ supports semicolon indentation |
12:20:26 | c15ade4 | just an fyi |
12:30:15 | * | a_b_m joined #nim |
12:32:12 | Araq | kaushalmodi: yeah but we have our own RST dialect, we can just fix it. |
12:32:36 | Araq | However what I want to do is to replace nimdoc.cfg with a NimScript instead that guides the HTML generation |
12:32:50 | * | a_b_m quit (Client Quit) |
12:33:10 | FromGitter | <kaushalmodi> "we have our own RST dialect, we can just fix it." +1 |
12:33:11 | Araq | should be much simpler to understand than that terrible $substitution based approach |
12:33:14 | * | abm quit (Ping timeout: 252 seconds) |
12:33:19 | FromGitter | <kaushalmodi> so I should leave that commit as-is? |
12:33:39 | FromGitter | <kaushalmodi> i.e. leave the ``` *foo ``bar``* ``` |
12:33:43 | Araq | no, docs must look nice and today is release day (famous last words) |
12:33:55 | FromGitter | <kaushalmodi> ok, will submit a PR ASAP |
12:34:26 | FromGitter | <kaushalmodi> yeah, I noticed the version update commit 👍 |
12:36:22 | FromDiscord | <Shield> @Quelklef, the docs for the system module only has atomicInc/Dec defined twice and and addAndFetch, it doesn't include all the functions defined in the atomics module |
12:37:16 | FromDiscord | <Shield> I was asking about the correct way to check for a condition atomically, and what's the correct AtomMemModel for it |
12:39:58 | FromGitter | <Quelklef> Got it. Also, TIL what an atomic inc and atomic dec are :) |
12:59:23 | FromGitter | <alehander42> @mratsim there's no RFC, I just don't see pro-s of them (at least for my gara lib, but it seems to me patty & ast_pattern_matching also work similarly) |
13:00:04 | FromGitter | <narimiran> nobody even blinked an eye on "today is release day" :D |
13:00:23 | FromGitter | <alehander42> @mratsim you can read the discussion before the "maybe we can remove them" message |
13:00:27 | FromGitter | <alehander42> 1) 19 ? |
13:01:28 | FromGitter | <mratsim> I didn’t play with them yet but for me a pro would be for example ⏎ ⏎ case (a, b, c): ⏎ of (x, 0, 0): x ⏎ of (x, 0, y): x * y [https://gitter.im/nim-lang/Nim?at=5baa31a7691dc567db9f1749] |
13:01:54 | FromGitter | <mratsim> i.e. implementing destructuring sugar |
13:02:22 | FromGitter | <kaushalmodi> @alehander42 Yep, https://github.com/nim-lang/Nim/commit/c240806756579c3375b1a79e1e65c40087a52ac5 |
13:02:52 | FromGitter | <alehander42> @mratsim well, capturing works well, I don't have sugar specifically for nameless tuples yet |
13:02:58 | FromGitter | <alehander42> but you can do e.g. |
13:03:38 | FromGitter | <alehander42> ```case (a: 2, b: 4): ⏎ of (a: @a, b: 0): a ⏎ of (a: @a, b: @b): a * b``` [https://gitter.im/nim-lang/Nim?at=5baa322a8ddf5867dc6fc6e2] |
13:03:40 | * | tzui joined #nim |
13:03:49 | FromGitter | <alehander42> eventually your example would be |
13:03:51 | FromGitter | <arnetheduck> speaking of sugar, what's the recommended way to turn a tuple/object into function args? ie `proc f(x, y: int); z = (0, 1); f(<something>z)` |
13:04:16 | FromGitter | <alehander42> ```match((a, b, c)): ⏎ of (@x, 0, 0): x ⏎ of (@x, 0, @y): x * y``` [https://gitter.im/nim-lang/Nim?at=5baa325041177e0bc7a41ca2] |
13:04:56 | FromGitter | <mratsim> @arnetheduck you mean something like a splat operator for a varargs function? |
13:05:17 | FromGitter | <mratsim> i.e. Python *foo |
13:05:58 | FromGitter | <mratsim> in a macro result = nnkArglist, and then copy all fields of the object/tuple to the nnkArgList |
13:06:12 | FromGitter | <narimiran> @arnetheduck unfortunately, there doesn't exist the equivalent of python's `*z` |
13:06:20 | FromGitter | <alehander42> @mratsim there are some problems with mixing match functionality in case, but as I said, it's easier if you read the discussion |
13:06:26 | FromGitter | <narimiran> what you can do is `let (z1, z2) = z` |
13:09:32 | FromGitter | <arnetheduck> @mratsim @narimiran yeah, that's the one.. tuple unpacking is what I'd google for, over splat ;) but it could equally apply to objects |
13:10:05 | FromGitter | <arnetheduck> I guess an interesting discussion to have would be whether to base it on names or order (or have both operators) |
13:10:12 | FromGitter | <mratsim> there is an unpack macro in the stdlib but it’s limited iirc |
13:11:09 | FromGitter | <mratsim> anyway, just make sure to use nnkArgList when passing as varargs param. Using nnkBracket will cause issues (all required to be of the same type for example) |
13:13:23 | FromGitter | <alehander42> @mratsim but a short summary of my thoughts is https://gist.github.com/alehander42/2bd15a289432f7f7832a02b1e064f6ab |
13:18:08 | FromGitter | <alehander42> @krux02 I want to reuse your(scala's?) idea for quoting literal code in matches |
13:18:26 | * | skellock joined #nim |
13:18:45 | FromGitter | <alehander42> overally I wondered if it makes sense to keep my variant match syntax closest as possible to your lib, so people can use them both without much confusion |
13:19:40 | * | nathanj left #nim ("WeeChat 2.2") |
13:31:20 | * | kapil___ joined #nim |
13:31:35 | * | goofie22 joined #nim |
13:32:29 | * | goofie22 quit (Remote host closed the connection) |
13:34:46 | * | krux02 joined #nim |
13:35:40 | * | pppingme20 joined #nim |
13:35:44 | skellock | alehander42: anything i can do to help push the sourcemap feature along? |
13:37:32 | * | pppingme20 quit (Remote host closed the connection) |
13:38:04 | FromGitter | <kaushalmodi> Nim already has `-d:release` and `--opt:size` which remove debug info and optimizes the binary size. |
13:38:15 | FromGitter | <kaushalmodi> But the GNU binutils `strip` is able to optimize that even more |
13:38:29 | FromGitter | <kaushalmodi> so what is it that `--opt:size` doesn't remove, that `strip` can |
13:43:32 | enthus1ast | afaik "--opt:size" calls gcc with "-Os" so gcc is instructed to do not increase file size while optimizing, "strip -s" removes unneeded (for running it) symbols/information |
13:44:07 | FromGitter | <kaushalmodi> enthus1ast: thanks |
13:44:15 | enthus1ast | you can add --passl:"-s" to your nim compilation line to have a similar effect |
13:45:46 | FromGitter | <kaushalmodi> actually I was googling about this in parallel |
13:45:48 | FromGitter | <kaushalmodi> https://stackoverflow.com/questions/1349166/what-is-the-difference-between-gcc-s-and-a-strip-command |
13:45:59 | FromGitter | <kaushalmodi> turns out `strip -s` does even more than just `gcc -s`? |
13:48:16 | enthus1ast | i dont know but maybe you yould compare the executable with a tool like readelf or objdump |
13:48:20 | enthus1ast | could |
13:48:26 | FromGitter | <kaushalmodi> yeah |
13:48:56 | * | redarrow joined #nim |
13:52:43 | FromDiscord | <Shield> even with -d:release you still need to use --lineTrace:off |
13:53:08 | * | redarrow quit (Remote host closed the connection) |
13:58:00 | FromGitter | <arnetheduck> `linetrace` is one of those features that has such an unnaturally high cost the way it's implemented now.. throws off everything: reg allocation, inlining, code size - and all that to print some line info on exceptions that can be equally well done with debug info |
13:59:04 | FromGitter | <kaushalmodi> Shield: Thanks. I've made a note of that. I need to try that on a real Nim project; my toy "hello world" program sees no difference on using that switch. |
14:00:34 | Araq | "equally well", be my guest. so far I got PRs that only work on some OS, some of the time with worse results |
14:01:12 | Araq | also, -d:release implies --lineTrace:off |
14:06:33 | FromGitter | <arnetheduck> well, it could be a staggered feature that uses debug info where avail and the slow way where not |
14:08:56 | * | SenasOzys quit (Remote host closed the connection) |
14:13:23 | * | SenasOzys joined #nim |
14:13:23 | Araq | how can it fall back to the "slow way"? |
14:13:26 | * | craigger_ quit (Quit: bye) |
14:13:38 | Araq | without injecting all this crap that makes it slow to begin with |
14:13:42 | * | craigger joined #nim |
14:14:53 | Araq | and just so that we're on same page: linetracing is indeed a terrible implementation |
14:16:26 | FromGitter | <arnetheduck> on platforms that have good debug info support, use debug info - on others, don't. or rework the line tracing to use a lookup table, though that brings you into platform specific again because you (probably) need to know a lot about addressing to pull it off |
14:36:35 | * | PMunch quit (Quit: Leaving) |
14:42:43 | FromGitter | <retsyo> @zacharycarter so bad, none of `scientific, integrate, integration, integral, root` finds something useful on https://nimble.directory. I don't know whether arrayfire, which has a nim package, can handle my question( in fact I think it only treats array); but I don't want to use it because arrayfire seems toooo big. In fact, I am doing some calculation with python's numpy/scipy which is some slow. Any way, thanks |
14:47:32 | planetis[m] | hi, what do you say for this syntax: http://ix.io/1nw0 for an interface macro? |
14:51:30 | FromGitter | <Vindaar> @retsyo Not quite what you're asking for (but maybe you also need it), I created wrappers for mpfit (non linear least squares fitting) and NLopt (general non linear optimization). Lately I haven't needed any numeric integrations. However, if you know some C library for that, I'd be happy to write a wrapper (or help you with it). On the other hand as an intermediate step using numpy and scipy from Nim is now pretty easy |
14:51:30 | FromGitter | ... with https://github.com/yglukhov/nimpy. |
14:55:09 | FromGitter | <kaushalmodi> > On the other hand as an intermediate step using numpy and scipy from Nim is now pretty easy with https://github.com/yglukhov/nimpy. ⏎ ⏎ This deserves a blog post by someone who has done that. |
14:55:36 | FromGitter | <kaushalmodi> Probably by @yglukhov himself :) |
14:56:01 | FromGitter | <kaushalmodi> .. and then have that featured on Nim blog |
14:57:07 | FromGitter | <Vindaar> @kaushalmodi I've been meaning to write blog posts about all sorts of things and haven't gotten to do it :( Maybe I'll start with this... |
14:57:22 | FromGitter | <kaushalmodi> Go for it! |
15:05:27 | FromGitter | <bung87> `mm = memfiles.open("src/maxnseg/backward_gram.dict", mode = fmRead)` is the file path still releative to the source after compiled ? |
15:07:38 | Araq | no, it's relative to the current working directory |
15:08:02 | * | fuxx19 joined #nim |
15:08:21 | FromGitter | <bung87> so if it’s as a third party lib ,what’s the right way to do this? |
15:08:34 | * | fuxx19 quit (Remote host closed the connection) |
15:09:34 | * | chemist69 quit (Quit: WeeChat 1.9.1) |
15:09:55 | * | SenasOzys quit (Remote host closed the connection) |
15:10:05 | FromGitter | <bung87> let user `define` the source path ? |
15:10:10 | * | SenasOzys joined #nim |
15:10:36 | FromGitter | <bung87> resource |
15:11:13 | * | miran joined #nim |
15:13:37 | Araq | const res = staticRead"src/maxnseg/backward_gram.dict" ? |
15:14:08 | FromGitter | <kaushalmodi> @bung87 I'd add support for toml config or something |
15:14:13 | FromGitter | <bung87> but memfiles doest have a proc put the string content |
15:14:14 | * | noonien joined #nim |
15:15:10 | FromGitter | <bung87> @kaushalmodi so that will also work for some kind of resource like this? |
15:16:47 | FromGitter | <kaushalmodi> I believe so |
15:16:58 | FromGitter | <kaushalmodi> use `getConfigDir` to get your app's config file: https://nim-lang.github.io/Nim/ospaths.html#getConfigDir, |
15:17:11 | FromGitter | <kaushalmodi> If a config.toml is present in that config dir, use that |
15:17:19 | FromGitter | <kaushalmodi> else use the default that you set in your app |
15:17:55 | FromGitter | <kaushalmodi> with the parsetoml library from nimble, you can do something like this: |
15:18:02 | FromGitter | <kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5baa51aa56877c463a80dc9a] |
15:18:55 | FromGitter | <kaushalmodi> and then you can do: ⏎ ⏎ ```for key, val in pairs(cfg): ⏎ ..``` [https://gitter.im/nim-lang/Nim?at=5baa51df56877c463a80de23] |
15:19:57 | FromGitter | <bung87> so the way like a c++ program does |
15:20:12 | FromGitter | <kaushalmodi> hmm, I don't know how c++ does :) |
15:20:58 | FromGitter | <kaushalmodi> I like TOML and to give the user an ability to set vars for an app from a central place, I have something like this for one of my toy Nim projects |
15:21:42 | * | tbodt17 joined #nim |
15:22:24 | FromGitter | <bung87> I got the point , I just thought the resource is a static file belongs to package. |
15:22:30 | * | tbodt17 quit (Remote host closed the connection) |
15:23:28 | FromGitter | <kaushalmodi> Understood. So if this resource file could be changed by the user, then you can use this configdir approach to let the user point to their resource file. |
15:23:44 | FromGitter | <Bennyelg> Hashtable ⏎ hashtable -> ⏎ insert o(1) ⏎ delete -> o(1) ⏎ get -> o(1) ... [https://gitter.im/nim-lang/Nim?at=5baa5300fea613709414784d] |
15:24:06 | FromGitter | <bung87> well, that would split the way they get the resource. |
15:24:10 | FromGitter | <kaushalmodi> But if this is something that you use during build (and don't need to let the user configure) then use `staticRead` as Araq said |
15:24:33 | FromGitter | <Quelklef> @Bennyelg technically hash tables are O(n) for all in worst case |
15:24:53 | FromGitter | <Bennyelg> why because nim implemented it as a tuple ? |
15:24:57 | FromGitter | <Quelklef> no |
15:25:02 | FromGitter | <Quelklef> because that's how hash tables work |
15:25:05 | FromGitter | <Bennyelg> shouldnt be key -value an o(1) ? |
15:25:05 | FromGitter | <Quelklef> https://en.wikipedia.org/wiki/Hash_table |
15:25:06 | FromGitter | <kaushalmodi> I believe critbits are better? (that's what I heard) |
15:25:38 | FromGitter | <Quelklef> worst case is that there's only one bin, in which it's O(n) |
15:28:15 | FromGitter | <kaushalmodi> About critbit trees, see https://github.com/agl/critbit/blob/master/critbit.pdf |
15:28:39 | FromGitter | <kaushalmodi> and its implementation in Nim: https://nim-lang.org/docs/critbits.html |
15:29:41 | FromGitter | <bung87> if you dont search item with prefix , you dont need this. |
15:34:04 | FromGitter | <Quelklef> Is there a nice way to iterate over two sequences in parallel in an expression? |
15:34:24 | FromGitter | <Quelklef> 'cause `zip(S1, S2).all((p) => somePredicate(p[0], p[1]))` is ugly |
15:35:03 | * | SenasOzys quit (Ping timeout: 245 seconds) |
15:35:26 | FromGitter | <mratsim> @Quelklef use zero-functional |
15:35:58 | FromGitter | <Quelklef> But then I'm just using `it` instead of `p`, yeah? |
15:36:07 | FromGitter | <Quelklef> I mean good point regardless but does that solve my problem |
15:36:24 | FromGitter | <mratsim> or for idx in 0 ..< min(S1.len, S2.len): doSomething(S1\[idx\], S2\[idx\]) |
15:36:46 | FromGitter | <mratsim> zero functional uses it? (anaphoric convention?) |
15:36:48 | FromGitter | <Quelklef> I'd, but it's in an `all` call |
15:36:57 | FromGitter | <Quelklef> Yeah the iterator variable is `it` |
15:37:02 | FromGitter | <Quelklef> so I'd still have to unpack |
15:37:52 | FromGitter | <mratsim> zer-functional will inline the loops including the all call |
15:38:10 | FromGitter | <mratsim> and a naive for loop, you can do anything inside. |
15:38:17 | FromGitter | <Quelklef> ...? |
15:38:18 | FromGitter | <Quelklef> enlighten me |
15:39:09 | * | SenasOzys joined #nim |
15:39:36 | FromGitter | <Quelklef> oh is this `loop:` in the readme |
15:39:40 | FromGitter | <mratsim> zip(S1, S2).allIt(somePredicate(it\[0\], it\[1\])) |
15:39:56 | FromGitter | <mratsim> see here: https://github.com/zero-functional/zero-functional |
15:40:02 | FromGitter | <Quelklef> Yeah I was there :p |
15:40:12 | FromGitter | <Quelklef> I suppose that's slightly better |
15:40:18 | FromGitter | <Quelklef> still don't like the hardcoded 0/1 index but |
15:40:44 | FromGitter | <mratsim> use loop-fusion then |
15:41:03 | FromGitter | <mratsim> https://github.com/numforge/loop-fusion |
15:41:33 | FromGitter | <Quelklef> oh fuck |
15:41:34 | FromGitter | <Quelklef> thanks |
15:42:19 | FromGitter | <mratsim> I think I might change again forZip to forEach, it rings better |
15:42:54 | FromGitter | <Quelklef> imo forUnzip |
15:43:00 | FromGitter | <Quelklef> since that makes the most sense to me |
15:43:12 | FromGitter | <Quelklef> Can these be used to emulate an `all` call inline? |
15:43:22 | FromGitter | <Quelklef> 'cause the innards look like statements for imperative code |
15:43:25 | FromGitter | <mratsim> uh lol, no it zips 2 sequences together before applying the function body |
15:43:47 | FromGitter | <mratsim> you don’t need `all` anymore |
15:43:53 | FromGitter | <Quelklef> hold on I think I need to actually read the readme closely before I talk about this lol |
15:44:33 | FromGitter | <mratsim> let c = forZip(x in a, y in b): ⏎ ⏎ ```SomePredicate(x, y)``` [https://gitter.im/nim-lang/Nim?at=5baa57e153c31c111161f7df] |
15:44:42 | FromGitter | <mratsim> done |
15:44:59 | FromGitter | <Quelklef> then `c` would be `seq[bool]`, right? |
15:45:04 | FromGitter | <mratsim> yes |
15:45:12 | FromGitter | <Quelklef> Yeah so then I'd need to `all(c)` |
15:45:24 | FromGitter | <mratsim> ah you need a reduction after |
15:45:42 | FromGitter | <Quelklef> Hmmm, how inline can we get |
15:45:57 | FromGitter | <Quelklef> some way to do `forZip(x in a, y in b; somePredicate(x, y))`? |
15:46:12 | FromGitter | <mratsim> var c = true ⏎ forZip(x in a, y in b): ⏎ ⏎ ```c and SomePredicate(x, y)``` [https://gitter.im/nim-lang/Nim?at=5baa58448196693171b23639] |
15:46:22 | FromGitter | <Quelklef> No, def don't want that |
15:46:28 | FromGitter | <Quelklef> all'll work fine |
15:46:52 | FromGitter | <Quelklef> oh cool wait it's `varargs[untyped]` so that should just work, right? |
15:46:57 | FromGitter | <mratsim> all will do one loop for applying the predicate and one loop for reduction, this does a single loop |
15:47:06 | FromGitter | <Quelklef> Ah |
15:47:22 | FromGitter | <Quelklef> At this phase of the project, idc about efficiency tbh |
15:47:27 | FromGitter | <mratsim> zero-functional too will do a single loop |
15:47:41 | FromGitter | <Quelklef> Also the seqs should be length like 1-10 for all cases, so the difference should be minimal |
15:48:26 | FromGitter | <mratsim> sorry the body should be `c = c and SomePredicate(x, y)` |
15:48:46 | FromGitter | <Quelklef> `c and= somePredicate(x, y)` lol |
15:50:05 | FromGitter | <Quelklef> OK, so ⏎ ⏎ ```let a = @[1, 2, 3}``` [https://gitter.im/nim-lang/Nim?at=5baa592caedb375b9c452d97] |
15:50:27 | FromGitter | <Quelklef> so this is just about perfect |
15:50:31 | FromGitter | <Quelklef> thank you ver much |
15:50:45 | FromGitter | <Quelklef> (also I think a `forZipAll` template could be made to be both single-pass and readable) |
15:51:02 | FromGitter | <Quelklef> (not as in you should make it but just to note a possible compromise between out positions) |
15:51:39 | * | darithorn joined #nim |
15:55:54 | * | junland quit (Quit: Disconnected.) |
15:56:05 | planetis[m] | what do you say for this syntax: http://ix.io/1nw0 for an interface macro? |
15:56:57 | * | junland joined #nim |
15:58:07 | miran | @mratsim: re: renaming `forZip` to `forEach`: it is a better name :) (but i still like my proposal `forAll` :)) |
15:58:38 | FromGitter | <alehander42> skellock let me rebase it on the last devel branch |
15:58:56 | FromGitter | <alehander42> after that honestly not sure, you can test it and see if it works well for you |
16:00:44 | FromGitter | <alehander42> if it works well in general and we decide to merge it like that, without refactoring of jsgen, it mostly needs several fixes, e.g. faster tokenization etc |
16:06:19 | * | kaychaks14 joined #nim |
16:10:34 | FromGitter | <kayabaNerve> Can you `'bitwsie'=` @Quelklef |
16:10:46 | Araq | planetis[m]: seems fine to me |
16:11:02 | * | kaychaks14 quit (Remote host closed the connection) |
16:11:35 | * | leru quit (Ping timeout: 252 seconds) |
16:16:11 | * | leru joined #nim |
16:17:04 | FromGitter | <mratsim> @kayabaNerve no you can’t it was a joke :P |
16:17:19 | FromGitter | <bung87> with latest update the nimsuggest needs `—address` ? |
16:19:47 | FromGitter | <bung87> with this arg vscode-nim can start nimsuggest process successfully but still not work properly |
16:20:21 | * | kapil___ quit (Quit: Connection closed for inactivity) |
16:23:20 | FromGitter | <kayabaNerve> @mratsim I doubted it but Nim does have some interesting features |
16:23:30 | FromGitter | <kayabaNerve> I just did a whole thing with bit shifting so I wanted to check |
16:24:09 | FromGitter | <mratsim> btw Can we change this line in the Github repo summary "Nim is a compiled, garbage-collected systems programming language with a design that focuses on efficiency, expressiveness, and elegance (in that order of priority). “ ⏎ ⏎ I think it’s key to convey that GC is tunable and can be disabled or you can use non-GC-ed type |
16:25:23 | FromGitter | <kayabaNerve> "Nim is a compiled systems programming language, that offers garbage collecting, with a design that focuses on efficiency, expressiveness, and elegance (in that order of priority). “ |
16:25:48 | FromGitter | <mratsim> @kayabaNerve feel free to use ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5baa618c8196693171b273b5] |
16:26:22 | FromGitter | <mratsim> but that’ s ugly :P |
16:27:12 | FromGitter | <bung87> optional garbage collecting |
16:27:14 | FromGitter | <mratsim> "Nim is a compiled systems programming language, that offers tunable and optional garbage collection, with a design that focuses on efficiency, expressiveness, and elegance (in that order of priority). “ |
16:27:27 | * | Trustable joined #nim |
16:27:32 | FromGitter | <kayabaNerve> Oh that's ugly as f*** |
16:27:52 | FromGitter | <kayabaNerve> The word offers implies optional IMO |
16:27:55 | miran | "...offers garbage collection (optional and tunable) ..." |
16:28:10 | FromGitter | <kayabaNerve> Offers + tunable makes it sound like some level of GC is needed |
16:28:17 | * | enthus1ast quit (Read error: Connection reset by peer) |
16:28:19 | FromGitter | <alehander42> btw Araq I wondered is there anyway to expose on compile time info about the types using an enum as a discriminator |
16:28:50 | FromGitter | <bung87> ` that offers ` does not seem like keyword. |
16:28:53 | FromGitter | <alehander42> e.g. `loadDiscriminatorUses(enumType) => seq[NimNode] # with thos types` or something like that |
16:30:55 | miran | "...compiled, garbage collected (various options, including none) systems programming language..." ? |
16:33:07 | FromGitter | <kayabaNerve> "Nim is a compiled systems programming language, offering optional and tunable garbage collecting, with a design that focuses on efficiency, expressiveness, and elegance (in that order of priority). “ ⏎ ⏎ "Nim is a compiled systems programming language, offering optional and tunable garbage collecting, which focuses on efficiency, expressiveness, and elegance (in that order of priority). “ |
16:33:31 | FromGitter | <kayabaNerve> First one has how I would write up the GC; second one went a bit further and edited a diff part as well |
16:34:54 | miran | sounds good to me |
16:35:02 | FromGitter | <bung87> offering can be cut, |
16:35:59 | FromGitter | <kayabaNerve> "Nim is a compiled systems programming language, optional and tunable garbage collecting, with" |
16:36:05 | FromGitter | <kayabaNerve> It really can't be. |
16:36:15 | FromGitter | <kayabaNerve> It can be replaced. It can't be cut. |
16:36:39 | * | Jesin quit (Quit: Leaving) |
16:37:58 | miran | offering -> with? |
16:38:29 | FromGitter | <bung87> I think it’s fine to me . even it’s just bunch of keywords |
16:38:47 | FromDiscord | <Shield> could be "offers both manual memory management and a tunable garbage collector" |
16:38:58 | FromGitter | <kayabaNerve> I think that's too long |
16:39:17 | FromGitter | <kayabaNerve> This isn't the Wikipedia page |
16:39:20 | FromDiscord | <Shield> some people see GC and automatically expects it is forced |
16:39:34 | FromGitter | <kayabaNerve> "offering optional and tunable garbage collecting" |
16:41:05 | * | Jesin joined #nim |
16:42:17 | FromDiscord | <Shield> "offers multiple memory management models"? |
16:50:32 | planetis[m] | Araq: would this macro be a good candidate for the stdlib? |
16:53:26 | FromGitter | <Quelklef> @kayabaNerve I wish lol |
16:55:10 | * | SenasOzys quit (Ping timeout: 246 seconds) |
16:59:22 | miran | dom96: somebody is hidden here: https://forum.nim-lang.org/t/4237 |
17:01:38 | * | SenasOzys joined #nim |
17:17:08 | * | jmarion joined #nim |
17:20:28 | * | jmarion quit (Remote host closed the connection) |
17:29:13 | Araq | planetis[m]: yes, but *after* it has been battle-tested :-) |
17:32:46 | FromGitter | <Bennyelg> I dont get the idiom of noSideEffects and func / proc |
17:32:54 | FromGitter | <Bennyelg> so confusing |
17:34:54 | FromGitter | <kayabaNerve> When it comes to using pragmas for code safety, I remember @Quelklef once saying annotate every single proc as func if it compiles like that. |
17:34:59 | FromDiscord | <Shield> what's confusing about it? |
17:35:44 | FromGitter | <kayabaNerve> It should be obvious to detect side effects but calling inc() on a variable in the proc crashed with noSideEffects |
17:35:50 | FromGitter | <kayabaNerve> The triggers are a bit archaic |
17:36:03 | FromGitter | <kayabaNerve> And then func (currently proc with noSideEffects) is subject to change. |
17:36:06 | FromGitter | <Bennyelg> this is the first language I know which distinguish between these two. ⏎ but i am newbie so I donnu. ⏎ Whats count as a sideEffect ? |
17:36:17 | FromGitter | <kayabaNerve> @Bennyelg If it edits data outside of the function. |
17:36:32 | FromGitter | <kayabaNerve> That's what the idea is. That said, it's not always obvious. |
17:36:34 | FromGitter | <Bennyelg> so most of the time proc is a func |
17:36:48 | FromGitter | <arnetheduck> @Shield - he std lib assumes GC - there's a small core / subset that you can use to avoid GC but idiomatic use of the language requires it, so by all practical meanings of "forced", it's true |
17:36:50 | FromGitter | <kayabaNerve> Do you use global variables, ref objects, or use (x: var type) |
17:36:55 | miran | @Bennyelg echoing inside of a proc is a side effect, for example |
17:36:57 | FromGitter | <Bennyelg> functional programming paradigma ? |
17:37:10 | FromDiscord | <Shield> since the pure pragma was removed from enums, I suggest to replace noSideEffects with pure |
17:37:12 | FromGitter | <Bennyelg> echoing is not chaning state |
17:37:13 | miran | as it is anything that would modify input parameters |
17:37:15 | FromGitter | <Bennyelg> so why and how |
17:37:48 | FromGitter | <kayabaNerve> @arnetheduck That's being improved upon. |
17:37:56 | miran | or what would make function return different results if it was called with the same parameters several times |
17:38:00 | FromGitter | <kayabaNerve> miran: Or calling inc() on a variable defined inside the function. |
17:38:17 | FromGitter | <Bennyelg> calling inc on defined variable inside it's side effect? |
17:38:20 | FromGitter | <Bennyelg> so strange :/ |
17:38:29 | FromGitter | <kayabaNerve> That's why I call it archaic. |
17:38:32 | FromGitter | <Bennyelg> if it's inside the proc /func scope so why the hell |
17:38:57 | FromGitter | <kayabaNerve> Because I'm sure inc itself would count as noSideEffects, but anything that calls it isn't |
17:39:12 | FromGitter | <Bennyelg> if everything defined in the scope and has no interaction with the rest then it should be "no side effects" |
17:39:17 | FromGitter | <kayabaNerve> It seems to be an useful feature that complains too much to be useful IMO |
17:39:31 | miran | @kayabaNerve i've tried a basic example with `inc` and it does work inside of a `func` |
17:39:46 | FromGitter | <kayabaNerve> Didn't when I tried it. :thinking: |
17:39:47 | FromGitter | <Bennyelg> reasonable |
17:39:53 | FromGitter | <kayabaNerve> It was a couple of month ago though. |
17:39:54 | FromGitter | <Bennyelg> inc should work |
17:40:26 | FromGitter | <arnetheduck> I'm wondering about `func` - ostensibly it's been added by there are *no* examples of its use in the stdlib.. |
17:40:56 | miran | @Bennyelg if you're confused when to use which (proc or func): my rule of thumb is: change everything to `func` and then "undo" some procs where you get an error :) |
17:41:03 | FromGitter | <kayabaNerve> But why |
17:41:23 | FromGitter | <bung87> input -> output no side effect , input -> output (or with changed input) side effect |
17:41:34 | miran | @arnetheduck because `func` meaning "proc with no side effect" is a recent change/addition |
17:41:42 | FromGitter | <kayabaNerve> noSideEffects just means it'll error if there is one. All that does is detect if the proc has a side effect, but then if it does, you don't actually care. You just change it back to proc. |
17:41:45 | FromGitter | <Bennyelg> change input when passing var maybe |
17:41:50 | FromDiscord | <Shield> inc works fine with noSideEffect |
17:41:50 | FromGitter | <arnetheduck> I suspect that if one were to actually update the std lib, there would be lots and lots of code that would qualify for `func`/`noSideEffects` |
17:42:06 | miran | @arnetheduck yup |
17:43:10 | FromGitter | <kayabaNerve> miran: noSideEffects is a label to make sure the function doesn't have side effects. If you just change it back to proc, then you're not caring about the label. It also encourages that if it ends up causing a side effect, ignoring the fact you caused one, and just getting it to compile, when the compiled code should be the same. |
17:43:33 | FromGitter | <kayabaNerve> Don't do it just do it; do it on functions that shouldn't cause side effects so you can make sure they don't. |
17:43:49 | FromGitter | <kayabaNerve> func is currently proc {.noSideEffects.} but I don't think func is finalized. |
17:43:49 | miran | @kayabaNerve: i think we misunderstood each other |
17:44:32 | FromGitter | <arnetheduck> @miran I guess adding new features is more fun that finishing old ones :) |
17:44:44 | FromGitter | <Bennyelg> thanks all |
17:44:56 | FromGitter | <kayabaNerve> miran: noSideEffects is a label that doesn't affect compiled code IIRC. Just if your code compiles. Labeling procs as funcs just because it compiles as a func doesn't benefit you in any way unless you use it to make sure you don't introduce one. That said, you labelled it as func just because you code, not because it shouldn't have side effects. |
17:45:49 | miran | if you have the existing code with, let's say, 20 procs. and most of them have no side effects - the quickest way to make your code "easier to read" (by using `func`) is to just do a quick find-replace, and then tune back when needed |
17:46:07 | FromGitter | <kayabaNerve> Instead of using the pragmas noSideEffects? |
17:46:53 | FromGitter | <kayabaNerve> How is code easier to read if some say func and some say pragma? It just tells me the specific proc doesn't have side effects but if someone only did it with a FAR, they don't care if it has side effects or not. |
17:46:55 | miran | for me, when i see `func`, i know the following function is guaranteed to be sideeffect-free |
17:47:21 | FromGitter | <kayabaNerve> But if you do it with a FAR, you don't care if it does IMO. The noSideEffects label doesn't edit the AST. It just checks it. |
17:47:35 | miran | FAR? |
17:47:42 | FromGitter | <kayabaNerve> Find and replace |
17:47:45 | FromGitter | <arnetheduck> `func` is a way to tell the readers of your code that they can safely assume certain things won't happen, thus making the surface area for bug-hunting radically smaller |
17:47:53 | miran | this. |
17:48:10 | FromGitter | <kayabaNerve> @arnetheduck Unless the issue isn't a side effect but a main affect. |
17:49:18 | * | Jesin quit (Quit: Leaving) |
17:49:21 | FromGitter | <kayabaNerve> So yes, labeling everything you can as func because it compiles can have some benefit. I think if you care that much you should pick procs that should never have side effects and use func there, and not switch between proc and func as the compiler yells at you. |
17:49:27 | FromGitter | <kayabaNerve> That said, your code is yours, not mine. |
17:50:17 | FromGitter | <kayabaNerve> I personally don't bother with them because of the work involved/the fact they're hard to detect/if I just use FAR it feels pointless. I also wouldn't use func just for noSideEffect until func is finalized as I think it's still subject to change. If func is finalized as just noSideEffect, please let me know/feel free to just func. ⏎ ⏎ That said, I do use raises. |
17:50:40 | FromGitter | <alehander42> @skellock I updated my sourcemap branch (in my github nim fork https://github.com/alehander42/nim/tree/sourcemap ) |
17:51:14 | miran | see func/proc differences here: https://github.com/narimiran/AdventOfCode2017/blob/master/nim/day16.nim |
17:51:22 | FromGitter | <alehander42> I still have to optimize it a bit , but one should be able to try it if he builds the compiler from this branch and passes `--lineDir:on --sourcemap:on` while compiling js |
17:51:32 | FromGitter | <alehander42> I have to check if sourcemap assumes linedir too |
17:52:00 | miran | by using `func`, i immediately know that first two functions have no side effect, while the last two do have them |
17:53:42 | FromGitter | <bung87> well ,if you can make sure it’s func then you make sure it’s proc no sideeffect. |
17:54:11 | * | kapil___ joined #nim |
17:56:04 | * | skellock quit (Ping timeout: 240 seconds) |
17:59:10 | FromGitter | <kayabaNerve> I personally don't care if they don't have side effects. I care if they shouldn't. |
17:59:23 | FromGitter | <kayabaNerve> That's my personal view point though |
18:01:17 | * | Quozl7 joined #nim |
18:01:31 | FromGitter | <bung87> it’s useful for Editor give you some hints, when you dont read the source . |
18:01:38 | * | Trustable_2 joined #nim |
18:02:36 | * | Trustable quit (Ping timeout: 252 seconds) |
18:05:24 | * | Quozl7 quit (Remote host closed the connection) |
18:09:48 | * | Jesin joined #nim |
18:10:22 | Araq | kayabaNerve: 'func's design is finished as far as I'm concerned |
18:10:38 | Araq | it means .noSideEffect, nothing more, nothing less |
18:11:09 | Araq | as a rule of thumb, use 'func' in libraries, use 'proc' in application code |
18:12:51 | Araq | or use proc, the compiler also infers .noSideEffect. |
18:13:32 | FromGitter | <Bennyelg> yea |
18:13:38 | FromGitter | <Bennyelg> thanks for the clarification Araq |
18:19:24 | FromDiscord | <demotomohiro> All procs with noSideEffect pragma in PR #8166 should be replaced with func? |
18:19:53 | FromDiscord | <demotomohiro> https://github.com/nim-lang/Nim/pull/8166 |
18:20:43 | Araq | no, the prevalent style in Nim's codebase is proc {.noSideEffect.} |
18:23:25 | FromDiscord | <demotomohiro> So, use 'func' in libraries, but not in Nim's standard libary? |
18:24:47 | Araq | yup :-) |
18:24:55 | FromDiscord | <demotomohiro> Thx! |
18:25:05 | Araq | btw how does your implementation compare to mine? |
18:25:46 | Araq | https://github.com/nim-lang/Nim/blob/devel/compiler/pathutils.nim#L136 |
18:26:49 | FromGitter | <kayabaNerve> Araq Good to know. Thanks. |
18:27:59 | * | nsf quit (Quit: WeeChat 2.2) |
18:29:13 | FromDiscord | <demotomohiro> I didn't know nim already has relativeTo |
18:29:37 | Araq | it's not in the stdlib yet, but the compiler now has it |
18:31:43 | * | SenasOzys quit (Ping timeout: 245 seconds) |
18:33:41 | * | lagrenouille22 joined #nim |
18:35:49 | * | skellock joined #nim |
18:36:09 | * | lagrenouille22 quit (Remote host closed the connection) |
18:41:40 | FromDiscord | <demotomohiro> `relativePath` in PR #8166 can take both absolute path and relative path. |
18:42:54 | * | SenasOzys joined #nim |
18:46:18 | FromDiscord | <demotomohiro> This test code shows this proc can take both absolute path and relative path. |
18:46:19 | FromDiscord | <demotomohiro> https://github.com/demotomohiro/Nim/blob/getRelPathFromAbs/tests/stdlib/tospaths.nim |
18:47:52 | * | scrts23 joined #nim |
18:51:55 | * | scrts23 quit (Remote host closed the connection) |
18:55:18 | FromDiscord | <demotomohiro> Suppose when current working directory is "/home/xyz", you got a relative path "../d"(Absolute path is "/home/d") |
18:55:18 | FromDiscord | <demotomohiro> If you want to convert that path to relative to path "/usr", call `relativePath("../d", "/usr", "/home/xyz")`. |
18:55:18 | FromDiscord | <demotomohiro> It returns "../home/d" |
18:55:18 | FromDiscord | <demotomohiro> This is impossible without third parameter. |
19:04:06 | federico3 | how can I get the current path at compile time? |
19:16:21 | * | regtools_ left #nim (#nim) |
19:16:51 | * | regtools joined #nim |
19:18:46 | * | miran quit (Quit: Konversation terminated!) |
19:22:23 | FromDiscord | <demotomohiro> const s = staticExec("pwd") |
19:32:14 | FromDiscord | <Shield> I have something that's bothering me, what's there about D to make it outperform Nim when it's strictly OOP |
19:37:43 | * | elrood joined #nim |
19:42:49 | FromGitter | <Vindaar> @federico3: `getProjectPath` from the macros module might also give you what you need |
19:47:09 | * | d0py joined #nim |
19:47:15 | federico3 | it errors out due to failing importc |
19:47:28 | FromGitter | <zacharycarter> Shield: There are a number of differences b/w D and Nim - which benchmark are you looking at? |
19:47:41 | FromGitter | <Vindaar> getProjectPath does? |
19:50:27 | * | d0py quit (Remote host closed the connection) |
19:59:17 | FromDiscord | <Shield> there are few benchmarks that show nim and D together |
20:00:57 | * | kapil___ quit (Quit: Connection closed for inactivity) |
20:01:29 | * | PMunch joined #nim |
20:17:13 | * | kapil___ joined #nim |
20:20:26 | * | Pisuke joined #nim |
20:20:57 | * | MyMind quit (Ping timeout: 252 seconds) |
20:24:03 | * | Vladar quit (Remote host closed the connection) |
20:31:58 | * | vivus joined #nim |
20:33:06 | * | Trustable_2 quit (Remote host closed the connection) |
20:44:37 | FromGitter | <zacharycarter> I'm sure there are more than a few |
20:44:49 | FromGitter | <zacharycarter> benchmarks can be tailored to favor certain outcomes |
20:44:57 | FromGitter | <zacharycarter> also I'm sure D does certain things better than Nim |
20:45:30 | ldlework | I think the better question is why conflate OOP with benchmark status? |
20:45:40 | ldlework | what does that have to do with anything whatsoever? |
20:45:43 | FromGitter | <zacharycarter> that too |
20:54:17 | FromDiscord | <Shield> it's kinda like java where everything is an object even simple types, you'd think that introduces at least some overhead |
21:10:07 | * | leru quit (Ping timeout: 244 seconds) |
21:45:28 | * | PrimHelios joined #nim |
21:54:12 | * | Choruptian17 joined #nim |
21:57:34 | ldlework | Depends on the implementation really. For something like Python, that's an exceedingly good point. But the JVM is probably one of the most optimized pieces of software that has ever existed. |
21:58:13 | * | Choruptian17 quit (Remote host closed the connection) |
21:58:28 | ldlework | Shield, but I didn't realize what you were getting at, at first. Thanks for clarifying. |
22:00:04 | * | elrood quit (Quit: Leaving) |
22:03:39 | * | AndrewMC9 joined #nim |
22:05:51 | * | AndrewMC9 quit (Remote host closed the connection) |
22:18:32 | * | Kerk joined #nim |
22:18:56 | * | Kerk quit (Remote host closed the connection) |
22:20:54 | * | WebWalker3D29 joined #nim |
22:21:06 | * | zcheng3_ joined #nim |
22:21:57 | * | WebWalker3D29 quit (Remote host closed the connection) |
22:24:54 | * | aarontc28 joined #nim |
22:25:57 | * | zcheng3_ quit (Remote host closed the connection) |
22:28:33 | * | boneskull27 joined #nim |
22:29:15 | * | aarontc28 quit (Read error: Connection reset by peer) |
22:30:21 | AlexMax | Are there any known issues with using more up-to-date versions of mingw than what nim's finish.exe downloads? |
22:30:39 | AlexMax | Apparently, a newer version of gdb recognizes attempts at renaming threads using RaiseException |
22:32:47 | * | boneskull27 quit (Ping timeout: 244 seconds) |
22:34:23 | * | krux02 quit (Remote host closed the connection) |
22:40:59 | * | jbeta14 joined #nim |
22:42:57 | * | seni joined #nim |
22:42:59 | * | M`vy joined #nim |
22:43:20 | * | alok12 joined #nim |
22:43:28 | * | jbeta14 quit (Remote host closed the connection) |
22:43:55 | * | alok12 quit (Remote host closed the connection) |
22:46:31 | * | tzui quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
22:46:55 | * | ArmOrAttAk joined #nim |
22:47:32 | * | M`vy quit (Remote host closed the connection) |
22:48:40 | * | gmpreussner2 joined #nim |
22:49:17 | * | ArmOrAttAk quit (Remote host closed the connection) |
22:49:36 | * | gmpreussner2 quit (Remote host closed the connection) |
22:49:58 | * | PMunch quit (Remote host closed the connection) |
22:54:00 | * | ephemeron10 joined #nim |
22:54:48 | * | apopovych22 joined #nim |
22:56:38 | * | [NC]8 joined #nim |
22:56:48 | * | apopovych22 quit (Remote host closed the connection) |
22:57:51 | * | ephemeron10 quit (Remote host closed the connection) |
22:59:19 | * | Guest97822 joined #nim |
23:01:19 | * | [NC]8 quit (Read error: Connection reset by peer) |
23:01:44 | * | wiqd6 joined #nim |
23:02:00 | * | Guest97822 quit (Remote host closed the connection) |
23:05:49 | * | wiqd6 quit (Remote host closed the connection) |
23:08:25 | * | Guest15325 joined #nim |
23:10:06 | * | Guest15325 quit (Remote host closed the connection) |
23:11:46 | shashlick_ | @AlexMax: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/ |
23:11:50 | shashlick_ | I use the latest version |
23:15:42 | * | xet7 quit (Remote host closed the connection) |
23:18:19 | * | DerRaiden joined #nim |
23:22:05 | * | TinkerT3 joined #nim |
23:23:03 | * | s0_iggie joined #nim |
23:23:31 | * | DerRaiden quit (Ping timeout: 260 seconds) |
23:25:25 | * | TinkerT3 quit (Remote host closed the connection) |
23:25:31 | * | garo19 joined #nim |
23:26:37 | * | rjackson22 joined #nim |
23:27:39 | * | s0_iggie quit (Remote host closed the connection) |
23:30:25 | * | rjackson22 quit (Remote host closed the connection) |
23:30:28 | * | garo19 quit (Read error: Connection reset by peer) |
23:42:27 | * | BaronKrause25 joined #nim |
23:43:34 | * | stefanos82 quit (Quit: Quitting for now...) |
23:45:41 | * | seni quit (Quit: Leaving) |
23:46:05 | * | ZeiP7 joined #nim |
23:47:10 | * | BaronKrause25 quit (Remote host closed the connection) |
23:50:42 | * | ZeiP7 quit (Remote host closed the connection) |
23:55:49 | * | Ikoru1 joined #nim |
23:56:51 | * | Ikoru1 quit (Remote host closed the connection) |
23:57:28 | * | Alforz20 joined #nim |