| 00:21:32 | FromGitter | <Varriount> @miran: Perhaps there could be inline versions of the iterables? |
| 00:22:04 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 00:52:05 | * | find0x90 joined #nim |
| 00:52:48 | * | find0x90 quit (Client Quit) |
| 01:09:21 | * | gokr quit (Ping timeout: 264 seconds) |
| 01:09:55 | * | cspar_ joined #nim |
| 01:11:57 | * | cspar quit (Ping timeout: 240 seconds) |
| 01:24:46 | * | dddddd quit (Read error: Connection reset by peer) |
| 01:45:46 | * | find0x90 joined #nim |
| 02:00:09 | * | find0x90 quit (Ping timeout: 260 seconds) |
| 02:06:47 | * | find0x90 joined #nim |
| 02:08:50 | shashlick | probably too late now, but I tried that and it complains that <string, bool> provided but static[string], static[bool] expected |
| 02:33:45 | arthurz | Just to say https://www.onivim.io is such a nice editor |
| 02:40:51 | shashlick | arthurz: looks nice, nim support works |
| 02:40:51 | shashlick | ? |
| 02:44:07 | arthurz | Not Nim, sadly |
| 02:49:21 | * | find0x90 quit (Quit: find0x90) |
| 02:53:32 | * | user1101 quit (Ping timeout: 268 seconds) |
| 02:55:21 | * | user1101 joined #nim |
| 02:56:56 | shashlick | can't you add the nim plugin? |
| 03:00:52 | arthurz | did not see any provided. Maybe Oni needs some love from us |
| 03:07:43 | * | endragor joined #nim |
| 03:13:32 | FromGitter | <seruum> Is there anytime exceptions aren't caught. I have a complex program that loops indefinitely inside a while true block. The while true block is wrapped with a try-finally so that files and such can be cleanly closed with appropriate logs, but the finally is not ran. What I believe to be a normal trace is given. Any ideas why the error wouldn't be caught? if it helps, it is SIG PIPE error because of a network break on a |
| 03:13:32 | FromGitter | ... socket. Thanks. |
| 03:34:30 | * | aguspiza quit (Ping timeout: 260 seconds) |
| 03:37:30 | FromGitter | <gogolxdong> Why does this template hints me has to be discarded ? |
| 03:37:34 | FromGitter | <gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ab86afef3f6d24c68b67827] |
| 03:55:31 | * | arthurz quit () |
| 05:11:35 | * | rockcavera joined #nim |
| 05:12:11 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 05:16:17 | FromGitter | <cavariux> Hi, is there any official list of the reserved Nim words? |
| 05:16:50 | FromGitter | <cavariux> @gogolxdong , sry for being 2 hours late, but does client.getContent returns something? |
| 05:16:57 | FromGitter | <cavariux> if that is the case you have to discard that |
| 05:17:37 | FromGitter | <gogolxdong> sure, it returns Future[string] |
| 05:18:10 | FromGitter | <cavariux> most likely the error is that you have you discard it |
| 05:18:16 | FromGitter | <cavariux> discard client.getContent(tencentUrlWithCommonParams(action, host, payload)) |
| 05:45:47 | * | nsf joined #nim |
| 06:26:28 | * | gokr joined #nim |
| 06:26:36 | * | tinkerbeast joined #nim |
| 06:27:35 | * | tinkerbeast left #nim (#nim) |
| 06:46:04 | * | PMunch joined #nim |
| 07:13:35 | def- | @cavariux https://nim-lang.org/docs/manual.html#lexical-analysis-identifiers-keywords |
| 07:14:46 | FromGitter | <Varriount> @gogolxdong `client.getContent` returns something, and where ever you're calling the template isn't assigning that result to a variable. |
| 07:16:09 | FromGitter | <Varriount> arthurz: Oh yay, yet another text editor built on a browser engine. :/ |
| 07:18:01 | PMunch | Varriount, they even say "Built with web tech" as if that was a good thing.. |
| 07:18:37 | FromGitter | <Varriount> Call me back when it can load a 1GB CSV file without performance degradation. |
| 07:19:15 | PMunch | Call me back when you can open a text editor without it immediately gobbling up a GB of RAM for no good reason.. |
| 07:19:56 | FromGitter | <Varriount> *looks at PyCharm sadly* |
| 07:22:07 | FromGitter | <Varriount> I only use PyCharm because it is ridiculously good at what it does. |
| 07:34:01 | * | jaco60 joined #nim |
| 07:34:39 | FromGitter | <narimiran> > @miran: Perhaps there could be inline versions of the iterables? ⏎ ⏎ Can you expand a bit on this? |
| 07:35:20 | FromGitter | <narimiran> infinite iterators are made as closures, terminating iterators are inline |
| 07:36:13 | FromGitter | <narimiran> or did you mean something else? ( @Varriount ) |
| 07:38:33 | FromGitter | <narimiran> re: Oni editor - yeah, it surely won't work as good/fast as vim, but the comparison with vscode (speed-wise, RAM-wise) might be interesting to see.... |
| 07:47:04 | FromGitter | <Varriount> @narimiran I mean, I want to be able to do "for I in cycle(...)" without any overhead. |
| 07:49:51 | Araq | for loops that don't terminate are evil |
| 07:50:02 | FromGitter | <narimiran> @Varriount for infinite iterators i chose the closure variant so you can terminate them at the wanted point with `for i in 1 .. enough: myCycle()`. terminating iterators can be used as you propose |
| 07:51:12 | FromGitter | <narimiran> i had some long discussions here on IRC with couple of guys regarding closures vs inline, as i was undecided what was the better way to do it.... |
| 07:54:09 | * | Vladar joined #nim |
| 07:54:22 | * | floppydh joined #nim |
| 07:55:27 | * | aguspiza joined #nim |
| 08:01:26 | * | dddddd joined #nim |
| 08:06:45 | Araq | use inline iterators unless you can't |
| 08:21:43 | * | aguspiza left #nim (#nim) |
| 08:21:50 | * | Trustable joined #nim |
| 08:22:10 | * | aguspiza2 joined #nim |
| 08:25:28 | * | salewski joined #nim |
| 08:26:27 | salewski | Araq, no comment for three days on https://forum.nim-lang.org/t/3681 ? |
| 08:29:57 | * | sendell joined #nim |
| 08:30:13 | * | salewski quit (Client Quit) |
| 08:35:29 | * | aguspiza2 left #nim (#nim) |
| 08:35:45 | * | aguspiza joined #nim |
| 08:51:25 | * | aguspiza left #nim (#nim) |
| 08:52:10 | * | aguspiza joined #nim |
| 08:52:46 | aguspiza | 0.18.0 is 20% faster but it is using 5x more memory than 0.17.2 in my test (mostly async calls), is it a known issue? |
| 08:57:06 | aguspiza | --gc:markandsweep also blocks randomly for ~100ms in 0.18.0 |
| 08:59:32 | Araq | aguspiza, I've only seen it use 10% more memory |
| 09:00:00 | Araq | well it doesn't block "randomly", it collects and if you use 5x more memory, it collects more often |
| 09:00:31 | Araq | try --gc:v2 which is incremental |
| 09:01:35 | aguspiza | This is my test https://gist.github.com/aguspiza/80e34b5cf65aa3bbfd19c7339ee9b695 |
| 09:02:02 | aguspiza | Linux x64 0.17.2 boehm 24MB used (release 14MB) |
| 09:02:29 | aguspiza | Linux x64 0.18.0 boehm 94MB used (release 84MB) |
| 09:03:01 | aguspiza | other gc's have similar increases +40MB, i have not tried v2 |
| 09:03:27 | Araq | --gc:boehm does not use Nim's allocator. |
| 09:03:30 | aguspiza | doing now, thx, great language BTW |
| 09:03:48 | Araq | strange numbers. :-) |
| 09:04:23 | aguspiza | default gc 70MB (release 30-36MB) |
| 09:07:51 | aguspiza | 0.18.0 default gc 146MB (release 110MB) |
| 09:08:22 | aguspiza | similar result with gc:v2 146MB (release 110MB) |
| 09:09:29 | aguspiza | v2 should be better than boehm? |
| 09:10:31 | Araq | I never know. v2 should be without the blocking |
| 09:11:07 | Araq | the only thing all GCs have in common is the conservative stack marking |
| 09:11:27 | Araq | so roots on the stack can things alive for longer than required |
| 09:12:07 | Araq | post your issue on the forum, people are always interested in performance issues :-) |
| 09:15:19 | aguspiza | I'll do, thank you |
| 09:23:20 | * | rokups joined #nim |
| 09:25:34 | FromGitter | <narimiran> > nice, rawgit seems cool ⏎ ⏎ @alehander42 well, @nitely gave me a better advice regarding hosting docs - just create `docs` folder and use github pages for documentation - works quite nicely |
| 09:27:21 | FromGitter | <alehander42> hm, that makes sense |
| 09:27:33 | FromGitter | <alehander42> and that common nim theme, it's generated by `nim doc` ? |
| 09:31:39 | FromGitter | <narimiran> it is |
| 09:33:11 | FromGitter | <narimiran> btw, @Araq: i haven't been able to find documentation of `nim doc` (i have tried to run `nim doc --help`) to see which options can i pass to it - is this documented somewhere? |
| 09:34:32 | Araq | https://nim-lang.org/docs/docgen.html ? |
| 09:43:03 | FromGitter | <narimiran> heh, i guess that's it! now i see it is under 'Tools Documentation' |
| 09:45:04 | * | arnetheduck quit (Read error: Connection reset by peer) |
| 09:45:23 | * | arnetheduck joined #nim |
| 09:54:14 | * | xkapastel quit (Quit: Connection closed for inactivity) |
| 10:07:00 | * | dddddd quit (Read error: Connection reset by peer) |
| 10:54:57 | * | aguspiza quit (Ping timeout: 264 seconds) |
| 11:02:37 | * | Snircle joined #nim |
| 11:24:06 | * | kier_ quit (Quit: This cannot continue.) |
| 11:24:59 | * | kier joined #nim |
| 11:34:29 | * | Sentreen_ quit (Ping timeout: 256 seconds) |
| 11:43:13 | * | Sentreen joined #nim |
| 11:58:24 | * | SenasOzys joined #nim |
| 11:58:44 | PMunch | Hmm, is there any performance difference with nested procs? |
| 12:01:36 | * | Syneh__ quit (Quit: Connection closed for inactivity) |
| 12:07:36 | * | r3d9u11 joined #nim |
| 12:21:32 | * | r3d9u11 quit (Remote host closed the connection) |
| 12:22:46 | PMunch | Any plans on merging this by the way? https://github.com/nim-lang/Nim/pull/7343 |
| 12:23:10 | PMunch | I'm just wondering if I need to implement my workaround or not in the protobuf code |
| 12:25:54 | Araq | PMunch, I'll ask Zahary then |
| 12:29:09 | * | xet7 quit (Quit: Leaving) |
| 12:30:16 | * | NimBot joined #nim |
| 12:31:53 | * | xet7 joined #nim |
| 12:41:31 | PMunch | He seemed skeptical in the GitHub thread :P |
| 12:41:51 | PMunch | It's a bit of a dirty trick, but it works none the less |
| 12:44:55 | * | dddddd joined #nim |
| 12:55:53 | * | gokr quit (Ping timeout: 276 seconds) |
| 12:56:18 | * | athenot joined #nim |
| 13:04:47 | * | r3d9u11 joined #nim |
| 13:08:07 | * | sleepyqt joined #nim |
| 13:09:06 | * | r3d9u11 quit (Remote host closed the connection) |
| 13:11:49 | FromGitter | <Varriount> @Araq Just saw the commits on toOpenArray - nice work! |
| 13:15:48 | shashlick | @varriount - thanks for your reply on the macro forum post, just replied if you could take a look |
| 13:31:02 | * | gokr joined #nim |
| 13:50:28 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 14:03:35 | * | SenasOzys quit (Ping timeout: 240 seconds) |
| 14:11:05 | * | SenasOzys joined #nim |
| 14:16:56 | * | endragor quit (Remote host closed the connection) |
| 14:24:30 | * | aguspiza joined #nim |
| 14:25:45 | * | nsf quit (Quit: WeeChat 2.0.1) |
| 14:29:15 | * | endragor joined #nim |
| 14:39:01 | PMunch | Best thing to happen to the macros module: quote |
| 14:39:11 | PMunch | It seriously makes macros so much more readable |
| 14:39:53 | PMunch | A combination of that and dumpAstGen and macro writing is a breeze |
| 14:42:27 | FromGitter | <alehander42> yeah, can't really imagine them without quote, when was quote added? |
| 14:43:30 | PMunch | Not sure, but it was after I did my genui macros |
| 14:46:38 | PMunch | https://github.com/PMunch/gtkgenui/blob/master/gtkgenui.nim |
| 14:46:45 | PMunch | So that's what you had to do |
| 14:47:18 | PMunch | To be fair though, I'm not sure how much of that could be replaced by quote do |
| 14:48:44 | PMunch | Huh, I remember that looking worse actually |
| 14:49:03 | PMunch | The protobuf macro as already about 1000 lines with the parsing and stuff. And looks way worse :P |
| 14:51:36 | FromGitter | <alehander42> :D I am so hesitant to work on my area42 parser dsl, so hard to decide what do I want to support in the end |
| 14:51:50 | FromGitter | <alehander42> is the protobuf lib kinda working already? |
| 14:51:51 | PMunch | area42? |
| 14:52:38 | PMunch | alehander42, well it is able to parse the protobuf syntax. And I think writing a message and getting the length of a message on the wire based on an object should be working. |
| 14:52:43 | PMunch | Doing reading atm |
| 14:52:58 | PMunch | So when that's done I can finally try to read and write some messages :) |
| 14:58:13 | * | kaliy quit (Quit: leaving) |
| 15:00:27 | * | kaliy joined #nim |
| 15:01:15 | * | miran joined #nim |
| 15:03:32 | FromGitter | <alehander42> sorry, I meant the parser dsl I am writing for a simple library for easier prototyping of toy prog languages |
| 15:04:22 | FromGitter | <alehander42> nice! do you have already some benchmarks for parsing? |
| 15:04:24 | PMunch | Oh nice |
| 15:04:54 | PMunch | Nothing more than a single file I've written which contains most of the protobuf features |
| 15:05:12 | PMunch | Along with a series of tests for the varies sub-parts |
| 15:05:28 | * | endragor quit (Remote host closed the connection) |
| 15:12:39 | FromGitter | <alehander42> great, are you basing the protobuf lib on your other parsing libs ? |
| 15:13:34 | PMunch | Yeah, the parsing is based on combparser |
| 15:13:39 | PMunch | I wrote it to parse protobuf |
| 15:37:09 | shashlick | araq: so I want to staticRead() a file during compile time and want to use a relative path but given staticRead runs relative to the source file and not build working directory, how do I get an absolute path to the file at compile time? I don't have expandFilename() and hard coding an absolute file path isn't helpful for a git repo |
| 15:40:26 | * | r3d9u11 joined #nim |
| 15:46:05 | * | sz0 joined #nim |
| 15:55:10 | * | BitPuffin joined #nim |
| 15:55:36 | * | PMunch quit (Quit: Leaving) |
| 15:56:45 | * | gokr quit (Ping timeout: 263 seconds) |
| 16:02:08 | * | r3d9u11 quit (Remote host closed the connection) |
| 16:12:24 | * | r3d9u11 joined #nim |
| 16:21:41 | FromGitter | <mratsim> @PMunch, if you’re nested proc is a closure it will be slow, if it’s result only depends on the passed params it will be as fast as if it was in the global scope |
| 16:30:56 | * | noonien joined #nim |
| 16:35:12 | * | tiocavera joined #nim |
| 16:35:12 | * | rockcavera is now known as Guest56262 |
| 16:35:12 | * | Guest56262 quit (Killed (livingstone.freenode.net (Nickname regained by services))) |
| 16:35:13 | * | tiocavera is now known as rockcavera |
| 16:41:09 | FromGitter | <alehander42> is there a good way to somehow call mapIt on `pairs`? |
| 16:42:17 | Yardanico | it probably wouldn't be very efficient, but you can use toSeq probably |
| 16:43:02 | FromGitter | <alehander42> oh I forgot they're both iterators, nvm |
| 16:45:17 | Yardanico | ofc it would be cool if there was something in stdlib to allow iterator chaining |
| 16:46:01 | shashlick | is it possible to create const objects in macros? |
| 16:48:10 | Yardanico | shashlick, what do you mean by that? |
| 16:53:41 | shashlick | So I want to create an object at compile time that can be used at runtime |
| 16:53:47 | shashlick | Custom object |
| 16:54:57 | FromGitter | <alehander42> hm, do we have some kind of tuple destructuring for for loops? |
| 16:55:58 | * | sendell quit (Remote host closed the connection) |
| 16:59:45 | miran | something like `for (a, b) in seqOfTuples: ...`? that would be nice! |
| 17:06:51 | miran | from nim tutorial: "Tuples can be unpacked during variable assignment (and only then!). " :( |
| 17:16:40 | * | floppydh quit (Quit: WeeChat 2.1) |
| 17:21:04 | * | Trustable quit (Remote host closed the connection) |
| 17:21:43 | FromGitter | <alehander42> I guess it might be ambigious with `pairs` |
| 17:21:55 | FromGitter | <alehander42> but still in the first case you have `()` with pairs you don't |
| 17:23:15 | FromGitter | <alehander42> hm, actually I can override |
| 17:23:19 | FromGitter | <alehander42> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ab92c87e4ff28713a770f50] |
| 17:23:27 | FromGitter | <alehander42> and this way I'll get this behavior |
| 17:23:43 | FromGitter | <alehander42> ```for a, b in @[(2, "z")]: ⏎ echo a ⏎ echo b ⏎ ⏎ ``` [https://gitter.im/nim-lang/Nim?at=5ab92c9fe3d0b1ff2c6d256f] |
| 17:24:05 | FromGitter | <alehander42> but it contradicts with default ⏎ ⏎ 0, (2, "z") ⏎ ⏎ vs ... [https://gitter.im/nim-lang/Nim?at=5ab92cb5f3f6d24c68ba349e] |
| 17:24:25 | FromGitter | <alehander42> so it might be still surprising for a reader |
| 17:31:05 | miran | yeah, that would be surprising |
| 17:33:09 | miran | IMO, it would be ok if tuple unpacking worked if you provide parentheses - `for a, b in seq` gives `index, element` while `for (a, b) in seq` upacks the tuple. then we can have `for i, (a, b) in seq` for index + unpacking |
| 17:34:47 | * | r3d9u11 quit (Remote host closed the connection) |
| 17:39:22 | dom96 | Agreed |
| 17:50:13 | Araq | that idea has come up before and I think it'll be yet another gotcha for beginners |
| 17:51:23 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 17:55:19 | miran | Araq: we already have `(a, b)` for tuple unpacking inside of `let`. making it available with the same syntax in for-loops would/should not confuse anybody |
| 17:55:46 | Araq | maybe |
| 18:06:44 | * | xkapastel joined #nim |
| 18:15:01 | * | tiocavera joined #nim |
| 18:15:01 | * | tiocavera quit (Changing host) |
| 18:15:01 | * | tiocavera joined #nim |
| 18:15:01 | * | rockcavera quit (Killed (leguin.freenode.net (Nickname regained by services))) |
| 18:15:01 | * | tiocavera is now known as rockcavera |
| 18:20:11 | FromGitter | <data-man> https://github.com/nim-lang/Nim/issues/7402#issuecomment-376242818 ⏎ Is it just for me not working? :) |
| 18:25:58 | * | aguspiza quit (Ping timeout: 260 seconds) |
| 18:28:30 | Yardanico | works for me |
| 18:28:35 | Yardanico | where did you put that config? |
| 18:37:04 | FromGitter | <data-man> ```@if debug: ⏎ nimcache="./debug" ⏎ @else: ⏎ nimcache="./release" ⏎ @end``` ⏎ ⏎ For any .nim file, the release folder is created [https://gitter.im/nim-lang/Nim?at=5ab93dd02b9dfdbc3a24c342] |
| 18:39:28 | * | r2 joined #nim |
| 18:40:31 | FromGitter | <Varriount> Araq: Python has tuple unpacking in `for` loops. |
| 18:55:34 | miran | varriount: but it doesn't have `for index, element in seq` unless you explicitly use `enumerate` - i guess that's why there might be confusion in nim if it is "enumeration" or tuple unpacking |
| 18:55:57 | * | yglukhov_ joined #nim |
| 18:56:00 | miran | but if we stick to parentheses as mandatory for tuple unpacking, i don't see a problem |
| 18:56:10 | miran | and it would be a very nice addition to the language |
| 18:58:59 | * | ldlework quit (Read error: Connection reset by peer) |
| 18:59:14 | * | yglukhov quit (Ping timeout: 268 seconds) |
| 19:03:20 | * | Vladar quit (Quit: Leaving) |
| 19:05:37 | * | ldleworker joined #nim |
| 19:06:34 | * | ldleworker is now known as ldlework |
| 19:06:39 | * | ldlework quit (Changing host) |
| 19:06:39 | * | ldlework joined #nim |
| 19:10:54 | * | gokr joined #nim |
| 19:12:05 | * | SenasOzys quit (Ping timeout: 240 seconds) |
| 19:12:15 | FromGitter | <Varriount> miran: `for index, (element_one, element_two) in enumerate(zip(list_a, list_b))` |
| 19:12:16 | * | yglukhov_ quit (Read error: Connection reset by peer) |
| 19:13:03 | * | yglukhov joined #nim |
| 19:13:53 | miran | yeah, this is unpacking a tuple and then unpacking the second element of that tuple, which is also tuple :) |
| 19:33:40 | * | BitPuffin quit (Remote host closed the connection) |
| 19:34:00 | * | kinkinkijkin_ is now known as kinkinkijkin |
| 19:34:19 | kinkinkijkin | so what is the diff between all of the different multi-item container types? |
| 19:34:26 | kinkinkijkin | seq, set, tuple etc. |
| 19:34:48 | kinkinkijkin | array I know is immutable |
| 19:35:01 | kinkinkijkin | but what is the difference between that and an openArray for example? |
| 19:35:03 | * | nsf joined #nim |
| 19:35:30 | kinkinkijkin | idk how to google this |
| 19:35:52 | miran | kinkinkijkin: openArrays are used only as arguments in procs |
| 19:36:15 | miran | tuples are heterogenous containers (can contain various types of data) |
| 19:36:17 | dom96 | openarray can be thought of as a generic type |
| 19:36:45 | miran | sets are containers of unique values (you cannot have two identical items inside of a set) |
| 19:37:36 | miran | read from here downwards: https://nim-lang.org/docs/tut1.html#advanced-types-sets |
| 19:38:12 | * | mrwonko joined #nim |
| 19:38:36 | mrwonko | What's the proper way to register a signal handler? Do I need to use the posix module? |
| 19:38:52 | kinkinkijkin | ooooh set seems useful for some of the stuff I do |
| 19:39:25 | kinkinkijkin | what is the equivalent of a mutable array? as in, not a set of references like a list, but still mutable? |
| 19:39:35 | kinkinkijkin | does such exist in nim? |
| 19:39:56 | dom96 | arrays aren't immutable |
| 19:40:03 | kinkinkijkin | o |
| 19:40:10 | dom96 | arrays have a constant size |
| 19:40:46 | kinkinkijkin | well that's what I meant by mutable sorry, my terminology is a little confused since I haven't talked to people much about programming until lately |
| 19:41:03 | dom96 | mrwonko: seems there is a template for this in the posix module: https://nim-lang.org/docs/posix.html#onSignal.t,varargs%5Bcint%5D,untyped |
| 19:41:07 | kinkinkijkin | an array equivalent with inconstant size |
| 19:41:14 | miran | seq |
| 19:41:40 | kinkinkijkin | thanks |
| 19:42:35 | kinkinkijkin | so does nim have an equivalent to a list as well? |
| 19:42:54 | miran | seq |
| 19:43:14 | kinkinkijkin | is seq a reference variable or a value variable? |
| 19:43:28 | kinkinkijkin | or can it be both? |
| 19:44:00 | kinkinkijkin | I'm coming from c# for reference, where lists are exclusively references |
| 19:44:33 | dom96 | always a reference |
| 19:45:16 | kinkinkijkin | so is there something like a seq which isn't a reference? or would I have to find an implementation/implement that myself to use it? |
| 19:49:10 | * | SenasOzys joined #nim |
| 19:49:18 | kinkinkijkin | sorry, I want to rewrite an application I made in c# in nim but I had to go really far out my way to be able to avoid using a complex multibuffering system and I'd like to be able to simply avoid it this time |
| 19:49:38 | FromGitter | <Vindaar> @mrwonko: In addition to what dom96 already said, you may also want to look at how `setControlCHook` from the system module is implemented here: https://github.com/nim-lang/Nim/blob/devel/lib/system/excpt.nim#L485 |
| 19:50:14 | mrwonko | In particular I'm working with an asynchttpserver, it looks like that may already have signal handling in serve() |
| 19:54:52 | mrwonko | hmm no, it's actually waitFor that's turning the signal into an exception |
| 19:55:39 | dom96 | kinkinkijkin: Huh, I've never needed to use a seq that wasn't a reference, why is that a problem? |
| 19:55:50 | dom96 | mrwonko: What signal are you trying to handle? |
| 19:55:58 | mrwonko | INT & TERM |
| 19:56:24 | mrwonko | in particular I'd like to know how to finish outstanding requests on TERM before shutting down |
| 19:56:28 | dom96 | async doesn't mess with those |
| 19:56:45 | dom96 | Nim is turning them into exceptions somewhere |
| 19:56:51 | mrwonko | I get a ValueError of "No handles or timers registered in dispatcher." |
| 19:57:11 | mrwonko | when I Ctrl+C my server |
| 19:57:27 | kinkinkijkin | I was using lists to build arbitrary-length buffers the entire length of the current audio channel in a mixer inside of an MML compiler |
| 19:57:51 | kinkinkijkin | when I sent the channel to the mixer, the previous channel disappeared |
| 19:58:27 | kinkinkijkin | the way I fixed it was arrays of length decided directly after parsing the input MML file |
| 19:58:50 | kinkinkijkin | which ended with a random tail after the render |
| 19:59:08 | kinkinkijkin | well, "random", it depended on how many non-music commands were in the file |
| 20:00:15 | kinkinkijkin | of course, afair, nim arrays are set length at compile time right? |
| 20:00:22 | kinkinkijkin | so I can't do that |
| 20:00:33 | mrwonko | MML = Music Macro Language? |
| 20:00:37 | kinkinkijkin | yes |
| 20:00:39 | dom96 | yeah, I'm still not clear why lists aren't good enough |
| 20:01:17 | shashlick | answering my question from before: https://pastebin.com/TRctb7kn |
| 20:01:19 | dom96 | do you just want a seq that's on the stack? |
| 20:01:20 | kinkinkijkin | to keep the lists from emptying, I'd have to copy the data inside of them somewhere else and make a new list referencing that data |
| 20:01:24 | kinkinkijkin | yeah |
| 20:01:39 | kinkinkijkin | I guess? |
| 20:01:42 | * | rokups quit (Quit: Connection closed for inactivity) |
| 20:01:57 | dom96 | huh |
| 20:02:02 | kinkinkijkin | idk, I'm not entirely up on how memory works except for the parts that have disadvantaged me not knowing previously |
| 20:03:01 | dom96 | It would help if you could explain the problem in more generic terms, I'm really not familiar with audio processing :) |
| 20:03:25 | mrwonko | is this an accurate example of the kind of file you're trying to process? https://en.wikipedia.org/wiki/Music_Macro_Language#Example |
| 20:03:52 | kinkinkijkin | no, mrwonko, that's classic MML, nobody really uses it anymore |
| 20:04:03 | kinkinkijkin | I'm using a pseudoMML based on modern MML |
| 20:04:35 | kinkinkijkin | https://github.com/kinkinkijkin/kPMML/blob/master/examples/referenceexample4.txt this is an example |
| 20:04:38 | mrwonko | but the general idea is the same - it's a "programming language" for describing music patterns built from small "music literals" (the "strings" in that example) |
| 20:04:49 | kinkinkijkin | yeah |
| 20:05:27 | mrwonko | my general approach would be parsing that into a tree first, then interpreting the tree |
| 20:06:30 | mrwonko | I'm not entirely clear at which part you're having trouble with lists/arrays/sequences |
| 20:06:47 | mrwonko | are you trying to store the result of "running" these music programs? |
| 20:06:50 | kinkinkijkin | dom96, the flow I was doing was I was sending arbitrary-length buffers of data to be processed together and only together, and I was sending them all before processing, and every time I sent a new one the previous one disappeared |
| 20:07:13 | kinkinkijkin | yes the result of running |
| 20:07:52 | mrwonko | and there I suppose you calculate the next couple of notes and then send them off to be played, before calculating more? |
| 20:08:28 | kinkinkijkin | no, I calculate all of the notes for one channel, then send it to the mixer (which just adds the data together at each position) |
| 20:08:36 | kinkinkijkin | then send the next channel |
| 20:08:58 | kinkinkijkin | I was sending all of the channels before mixdown |
| 20:09:05 | mrwonko | I see. And you're having trouble with accidentally clearing previously sent results when you send/calculate the next one? |
| 20:09:14 | kinkinkijkin | yes, I was |
| 20:09:41 | kinkinkijkin | but in c# I was able to use arrays sized at runtime to get around this |
| 20:09:47 | kinkinkijkin | in nim I can't do this |
| 20:09:55 | kinkinkijkin | I think |
| 20:10:45 | mrwonko | you should be able to use a seq for the result of a channel and create a new one for each channel |
| 20:11:14 | mrwonko | maybe you're accidentally re-using a single seq and overwriting it? it might help to see some of the code where you're handling a single channel |
| 20:11:20 | kinkinkijkin | but I need to create seqs for an arbitrary number of channels |
| 20:11:50 | mrwonko | so have a seq of seqs |
| 20:12:05 | kinkinkijkin | hence I was intentionally using the same list in my original, nonworking implementation, but |
| 20:12:06 | kinkinkijkin | oh |
| 20:12:08 | kinkinkijkin | that works yes |
| 20:12:26 | kinkinkijkin | you can't do that in c# but I didn't think about that again after dismissing it when I was using c# |
| 20:13:49 | mrwonko | I guess you can't nest variable-sized arrays in C#, but you could probably use a List of List. |
| 20:14:04 | kinkinkijkin | there is an issue with possible memory expansion with that though, but I think if I cared enough about memory expansion I'd figure out a working method to integrate the mixer into the generation loop |
| 20:14:08 | * | sleepyqt quit (Quit: Leaving) |
| 20:14:35 | kinkinkijkin | which might actually also be faster... |
| 20:14:53 | kinkinkijkin | actually talking about this I just figured out a really simple way to do that... |
| 20:14:55 | mrwonko | if you care about memory use, you could consider generators for each channel and then generate only a couple of notes on demand |
| 20:15:14 | mrwonko | not sure how to best build generators in Nim, I think closure iterators might work? |
| 20:16:12 | kinkinkijkin | the way I was doing it in c# was just going through the channels with one generator |
| 20:16:31 | * | r3d9u11 joined #nim |
| 20:16:53 | kinkinkijkin | which is slightly slow, unless you use c#'s for loop multithreading |
| 20:17:09 | * | r2 quit (Ping timeout: 264 seconds) |
| 20:17:25 | kinkinkijkin | but even then only speeds up like 1.5x on my 4-core cpu |
| 20:17:35 | kinkinkijkin | and breaks my filter implementation |
| 20:17:43 | mrwonko | but yeah, the simplest way to get something up and running is probably a seq of seqs, even if that's not super efficient in terms of memory |
| 20:18:36 | * | athenot quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 20:19:25 | * | yglukhov quit (Remote host closed the connection) |
| 20:19:59 | * | yglukhov joined #nim |
| 20:22:24 | kinkinkijkin | these are good conversations, in here |
| 20:22:32 | kinkinkijkin | best language-specific programming channel I've been in so far |
| 20:23:19 | mrwonko | Maybe it's because Nim is not super widely used yet, so most people in here are probably enthusiasts? |
| 20:23:32 | kinkinkijkin | yeah maybe |
| 20:23:54 | kinkinkijkin | but it really helps that the language devs are active in here and aren't dicks |
| 20:24:21 | Araq | thanks :-) |
| 20:24:28 | miran | :D :D :D |
| 20:25:10 | Araq | I'm trying my best :-) |
| 20:25:23 | mrwonko | I love people who try not to be dicks! |
| 20:25:54 | kinkinkijkin | where would I go to submit a feature request though? a container type that isn't referrential and is arbitrarily-expansible or sizeable on runtime would be useful for some projects |
| 20:26:06 | kinkinkijkin | and I have no idea how to implement that, personally |
| 20:26:25 | Araq | our bug tracker is full of feature requests |
| 20:26:30 | kinkinkijkin | sounds hard, and c# has it but only for strings and it's buggy as hell |
| 20:26:34 | mrwonko | how would that work though? if it's arbitrarily-expansible it's have to go on the heap? |
| 20:26:44 | mrwonko | *it'll have |
| 20:26:56 | dom96 | you can allocate stack memory dynamically too |
| 20:27:08 | dom96 | but I'm still sceptical about its usefulness, sorry :) |
| 20:27:59 | Araq | it's prone to stack overflows. and the stack is something we have the least amount of control over |
| 20:28:01 | kinkinkijkin | yeah, it sounds like more of a headache to implement than the amount of headache it would reduce |
| 20:28:15 | mrwonko | yeah, but as far as I can imagine only if all (re-)allocation happens inside the function that defines the variable-sized array, and it couldn't be returned |
| 20:28:49 | mrwonko | there's no way of nesting them, you can only have a compile-time-constant number of them |
| 20:29:01 | mrwonko | so that couldn't work for a two-dimensional variable-sized array |
| 20:29:04 | Araq | maybe try a pool of seqs to save allocations |
| 20:29:30 | mrwonko | you could flatten your arrays, put it all in one seq and have a second one containing the start offsets into the first |
| 20:30:14 | mrwonko | but I still think generating/streaming chunks of results on demand is probably better than computing everything up-front |
| 20:30:23 | * | r3d9u11 quit (Remote host closed the connection) |
| 20:30:45 | mrwonko | you're essentially writing an interpreter for a programming language that outputs to an arbitrary number of streams, so I'd look into ways to handle streams and how to write compilers |
| 20:31:07 | kinkinkijkin | compute-first type things tend to be far faster in audio |
| 20:31:48 | mrwonko | hmm, I have no idea really |
| 20:32:00 | kinkinkijkin | the issue is because of the heaviness of the generator, sending out as computing can cause corruption on slow computers |
| 20:32:28 | mrwonko | you'd buffer chunks and stream, say, a couple of seconds every time |
| 20:32:34 | kinkinkijkin | and all of my software is aimed to be able to run on a 2001 laptop if needed, because I write for the demoscene and a lot of people are sticklers about updating their modern hardware |
| 20:32:45 | * | miran_ joined #nim |
| 20:32:50 | mrwonko | that explains the file format. cool. |
| 20:33:05 | * | miran quit (Ping timeout: 248 seconds) |
| 20:33:10 | kinkinkijkin | I already have issues with generating at realtime on my extremely modern computer |
| 20:33:13 | kinkinkijkin | as in 2011 |
| 20:33:35 | kinkinkijkin | anyways I have to be right back |
| 20:33:43 | mrwonko | and I have to leave |
| 20:33:59 | dom96 | oooh, I love demoscene |
| 20:34:51 | mrwonko | I still think it'd make sense to have some kind of pipelining solution where one thread generates chunks of audio for all channels and sends them to the player if you have limited memory |
| 20:35:22 | mrwonko | you either need to wait for load times on startup and have enough memory or dedicate some computational power at runtime |
| 20:36:33 | mrwonko | if the total amount of memory is low enough and binary size is not an issue (which it might be, this being the demo scene and all...) and you know what files you need to play when you build (it's a demo, after all) it'd actually be cool to pre-compute the whole thing at compile time, which Nim is a great choice for, and store it as a constant... |
| 20:37:10 | mrwonko | the "How I Start" guide actually does something similar for Brainfuck, which admittedly is a much simpler language: http://howistart.org/posts/nim/1/index.html |
| 20:39:09 | mrwonko | but I guess the whole point is probably to use MML as a kind of extreme compression to save on binary size, otherwise you might as well include a .wav |
| 20:39:44 | mrwonko | in that case you might consider pre-parsing the text file into a more efficient binary representation at compile-time though? |
| 20:40:08 | mrwonko | I need to write a demo some day, it'd be the best way to try my hands at some graphics programming. I just don't want to worry about keeping binaries small :D |
| 20:40:49 | dom96 | Hrm, indeed, I thought about getting into graphics programming that way as well. |
| 20:41:33 | dom96 | On a side note, I'm so glad I created Nimble and the Nim community have adopted it as the official Nim package manager: https://news.ycombinator.com/item?id=16679760 |
| 20:41:53 | mrwonko | haha, I get to write Go at work |
| 20:42:42 | mrwonko | I actually found Nim because I looked for a language that also compiles to a static binary, maybe with GC, and uses async/await instead of Goroutines |
| 20:43:03 | dom96 | You poor soul. |
| 20:43:20 | Araq | we need to do something about Nimble's enforced package structure warning |
| 20:43:29 | Araq | every package I install triggers it. |
| 20:43:35 | Araq | I understand why it's there. |
| 20:43:38 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 20:43:55 | Araq | but maybe default unknown directories to 'ignore me' ? |
| 20:44:08 | mrwonko | Yeah, coming from C++ I'm not particularly fond of Go's forced "simplicity", but I've learned to accept it |
| 20:44:14 | * | yglukhov joined #nim |
| 20:44:17 | dom96 | Araq: Did you submit bug reports on those package's repos? |
| 20:44:28 | Araq | no, lol. |
| 20:44:30 | mrwonko | the lack of Generics particularly annoyed me, so I was happy to see Nim has Generics, Templates _and_ Macros :D |
| 20:44:32 | dom96 | It'd be nice if you could give me a list of these packages now |
| 20:44:38 | dom96 | and if you did it would be pretty easy for you to do so ;) |
| 20:44:55 | dom96 | mrwonko: Well, I was joking, I'm sure Go isn't /that/ bad :) |
| 20:44:56 | Araq | nimble install asyncmysql |
| 20:44:59 | kinkinkijkin | the program does not play audio, it makes a .wav or .mp3 containing it |
| 20:45:24 | mrwonko | there's a reason Go has a large community, it's a great language for bad C programmers, which I suppose is why Google built it |
| 20:45:56 | Araq | Google employs more C++ programmer though. |
| 20:46:06 | Araq | C is a niche language at Google. |
| 20:46:10 | mrwonko | Good C++ is way harder to write than C :D |
| 20:46:15 | * | miran_ quit (Quit: Konversation terminated!) |
| 20:46:40 | Araq | the jury is still out on that one. :P |
| 20:46:44 | dom96 | Araq: Okay, good example. |
| 20:46:45 | kinkinkijkin | except if you're working with strings or large data management of any sort |
| 20:46:54 | mrwonko | Oh, I see, kinkinkijkin. In that case neither memory nor execution time are quite that importan, I suppose |
| 20:46:54 | dom96 | Araq: So what should Nimble do here? |
| 20:47:30 | mrwonko | hmm okay, let me rephrase that: there are way more ways to write bad C++ than bad C |
| 20:47:32 | Araq | do what it suggests. treat it like skipDirs = @["test] |
| 20:47:43 | FromGitter | <Varriount> mrwonko: What do you dislike about Go? |
| 20:47:47 | dom96 | if srcDir == "": installDirs = @[pkgName]; installFiles = @[pkgName.addFileExt("nim")] ? |
| 20:48:13 | Araq | not sure this snippet captures what I mean. |
| 20:48:22 | kinkinkijkin | memory is important as the c# version currently uses up to 100mb for a 7-channel 1-minute file (!) and some of my user targets are running 512mb laptops |
| 20:48:32 | Araq | think about it this way: |
| 20:48:33 | dom96 | Araq: So it should skip 'test' by default? |
| 20:48:38 | kinkinkijkin | and the format is made for one-hour battles, where tool time is of the essence |
| 20:48:41 | dom96 | What other directories should it magically skip? |
| 20:48:53 | kinkinkijkin | which is why I'm dropping c# |
| 20:49:02 | Araq | all directories it warns about. |
| 20:49:24 | * | user1101 quit (Ping timeout: 246 seconds) |
| 20:49:35 | Araq | think about it this way: the nimble user who is unaware of the directory rules |
| 20:49:47 | Araq | will read this warning and blindly edit his .nimble file |
| 20:50:10 | Araq | so Nimble could do that. |
| 20:50:28 | mrwonko | Varriount: Primarily that I need to make a tradeoff between type safety and abstraction (I dislike passing raw interface{} around, I really miss templates/generics), but also how often you're forced to spawn Goroutines when working with channels (just look at the Context implementation) |
| 20:50:49 | dom96 | Araq: There are more cases where this won't work |
| 20:51:14 | FromGitter | <Varriount> Isn't the whole point of channels to use them with Goroutines? Under what conditions would you not use a channel with a Goroutine? |
| 20:52:02 | dom96 | Araq: It really isn't the package manager's job to guess |
| 20:52:07 | FromGitter | <Varriount> Or rather, what other uses do channels have? |
| 20:52:34 | Araq | dom96, it doesn't guess, it ignores dirs that don't adhere to the rules |
| 20:52:39 | mrwonko | Varriount: Generally channels are for communication between Goroutines, yes. But say you have one channel and now you want to listen to everything in it in two locations. You now need a new Goroutine that takes everything from the first channel and writes it to two others. |
| 20:53:12 | dom96 | Araq: I'll consider it, but I'd rather go with my approach |
| 20:53:32 | dom96 | which will fix this package |
| 20:53:34 | kinkinkijkin | mrwonko sounds like the kind of runaround youd expect from java |
| 20:53:45 | dom96 | There are packages which aren't just a simple skipDir |
| 20:53:53 | Araq | your approach does not work IMO. nobody bothers with these warnings. |
| 20:53:55 | dom96 | they need restructuring, I hope you know that. |
| 20:54:13 | mrwonko | kinkinkijkin: I see. In that case you'll definitely need some kind of streaming in chunks to limit memory use at the cost of some CPU overhead. |
| 20:54:25 | Araq | if 95% of all people use your tool wrong, it's time to fix the tool. |
| 20:55:58 | Araq | and yes I understand why Nimble emits these warnings |
| 20:56:29 | dom96 | Like I said, I will fix this case |
| 20:56:35 | dom96 | But there are others which I can't |
| 20:56:49 | dom96 | It would require moving the .nim files into different directories |
| 20:56:49 | mrwonko | kinkinkijkin: I still have this vague feeling that async/await might help, but the futures there can only be completed once so it doesn't quite fit. One could probably write an asynchronous channel implementation for Nim though, and make it very easy to use thanks to the powerful Macro support |
| 20:56:49 | Araq | people will notice if 'nimble install myownpackage' doesn't work or lacks files |
| 20:57:03 | dom96 | and modifying the 'import' lines in the .nim files |
| 20:57:18 | Araq | or maybe do this instead: |
| 20:58:01 | mrwonko | The stackless async/await proposal for C++ would actually support that, you can await something repeatedly in it. |
| 20:58:06 | * | r2 joined #nim |
| 20:58:10 | Araq | do a test 'nimble install package && nimble test package' ... ugh |
| 20:58:29 | Araq | nimble can't run the package tests after installation :-) |
| 20:58:45 | mrwonko | In fact I was considering writing channels/"goroutines" on top of it in C++ to try it out at some point, but never quite got around to it... I have a partial proof of concept in Haskell so I could wrap my head around it and never got any further |
| 20:58:46 | Araq | or can it? |
| 20:59:11 | mrwonko | hmm I forgot how chaotic IRC gets when you have multiple simultaneous conversations :D |
| 20:59:15 | kinkinkijkin | I've lost which conversation you're pinging me about, mrwonko |
| 20:59:26 | mrwonko | still the MML converter, kinkinkijkin |
| 20:59:32 | kinkinkijkin | oki |
| 20:59:34 | mrwonko | but I'm going off on tangents |
| 20:59:50 | * | aguspiza joined #nim |
| 20:59:50 | dom96 | Araq: https://github.com/nim-lang/nimble/issues/469 |
| 20:59:58 | kinkinkijkin | how does await help with memory/work time exactly? |
| 21:00:28 | mrwonko | await facilitates writing lazy generators, which save memory |
| 21:00:36 | Araq | dom96, another problem is that the warning has the wrong receiver. |
| 21:00:51 | Araq | I am not responsible for the package(s) I install. |
| 21:00:57 | mrwonko | closure iterators can probably do something similar in Nim |
| 21:01:18 | kinkinkijkin | I'm not quite sure we're talking about the same kind of generator |
| 21:01:26 | mrwonko | I'm using it in the Python sense |
| 21:01:43 | dom96 | Araq: There is no way distinguish that |
| 21:01:47 | mrwonko | and/or coroutine sense, maybe? |
| 21:02:01 | kinkinkijkin | in audio a generator is just a function that creates the audio output of a channel or group of channels given the input |
| 21:02:03 | dom96 | Araq: These warnings don't show up when your package's dependency is installed (I'm pretty sure) |
| 21:02:20 | kinkinkijkin | in audio software it's really just jargon for "generation function" |
| 21:02:32 | dom96 | Araq: Also, the warning is a good indication to you that the package is broken. |
| 21:02:36 | mrwonko | I see. In programming a generator is something that generates any kind of output lazily as you request stuff from it. |
| 21:02:39 | kinkinkijkin | it only has separatem eaning on hardware |
| 21:02:47 | mrwonko | a lazy sequence, basically |
| 21:02:51 | kinkinkijkin | I see |
| 21:03:38 | kinkinkijkin | that's what it means on audio hardware but in audio software it's often faster to just run a function on a known length |
| 21:03:52 | Araq | dom96, maybe, I'm used to broken Nimble packages though, an invalid package structure is usually the least of my worries |
| 21:04:11 | kinkinkijkin | actually, the great functional superiority in nim over literally any .NET language is a huge reason why I've just dropped c# |
| 21:05:00 | kinkinkijkin | except c++.net but I like to forget microsoft did that |
| 21:05:08 | mrwonko | Talking about lazy sequences: I think Haskell would be a great fit for your problem. Lists are lazily evaluated there, so you can just write your code as if everything was calculated at once, and it will magically do it with very little memory |
| 21:05:25 | mrwonko | plus it's a wonderful language for writing compilers |
| 21:05:57 | mrwonko | and what you have is basically a pure function converting an MML file to a waveform |
| 21:06:06 | kinkinkijkin | yeah but I don't like haskell, and my best programming friend shot me in the dark at nim and crystal and I chose nim |
| 21:06:17 | * | vlad1777d joined #nim |
| 21:06:18 | kinkinkijkin | there's an alternate reality where I chose crystal probably |
| 21:06:55 | kinkinkijkin | I've also used nim for a bunch of system tools on my laptop and it's been amazing for that |
| 21:07:38 | kinkinkijkin | usually I'd use bash or C for system tools but it's just so much better than both for someone who doesn't want to have to know POSIX in and out and wants a fast tool |
| 21:08:05 | kinkinkijkin | as a bonus, all of my nim tools technically will run on windows, too |
| 21:08:12 | mrwonko | Are you familiar with C++? I don't recommend you switch to it, but the Ranges proposal would probably allow for an efficient implementation of this and could be reproduced in Nim. Admittedly I haven't looked at it too closely. |
| 21:08:30 | mrwonko | but again, these are all just different ways of representing lazy sequences |
| 21:08:31 | kinkinkijkin | I'm a little bit familiar with c++ |
| 21:08:44 | kinkinkijkin | I just write it like I write C, though, just with the extra conveniences of c++ |
| 21:09:13 | mrwonko | In the end, all you need is a function that returns the next note for a channel when called |
| 21:09:48 | mrwonko | everything else is just different ways of implementing that which differ in complexity |
| 21:10:40 | kinkinkijkin | okay, lemme walk you through how bad my current implementation is so you can get an idea for where I was in my programming skill when I originally wrote this thing |
| 21:11:03 | mrwonko | Okay, but bear in mind that it's 11PM in Germany and I need to sleep at some point :D |
| 21:11:43 | Araq | mrwonko, huch ein Deutscher? |
| 21:11:54 | kinkinkijkin | the parser returns a list of strings containing a token and token information |
| 21:11:55 | * | vlad1777d quit (Ping timeout: 256 seconds) |
| 21:11:57 | kinkinkijkin | a list of lists |
| 21:12:05 | mrwonko | In der Tat, Araq |
| 21:12:09 | kinkinkijkin | the first list contains one item, a string saying a number as in the number of channels |
| 21:12:32 | kinkinkijkin | the tokens are things like "envSet" instead of actually shortened tokens |
| 21:13:16 | kinkinkijkin | the generator loop iterates over each item in each sublist and generates audio one tick at a time, then pushes it into the channel's list |
| 21:13:40 | kinkinkijkin | it figures out what to do with a 17-part-long if-else if structure |
| 21:13:53 | kinkinkijkin | with the most common thing, notes, being at the end |
| 21:14:09 | mrwonko | Hmm I wonder if there are any compiler generators for nim similar to Boost.Spirit... |
| 21:14:46 | kinkinkijkin | all of this was done with .Contains instead of .StartsWith |
| 21:14:51 | kinkinkijkin | for checking tokens |
| 21:14:59 | kinkinkijkin | which is orders of magnitude slower in c# |
| 21:15:51 | kinkinkijkin | on top of this, it did all of this then iterated through all the channels again (but the output data this time) with the mixer |
| 21:15:57 | kinkinkijkin | the output data is a list of arrays |
| 21:16:04 | mrwonko | So Araq is German, too. Cool. Now I feel even more compelled to contribute to Nim. |
| 21:16:30 | mrwonko | Which is weird, nationality shouldn't factor into that |
| 21:17:01 | kinkinkijkin | makes me wonder if there are any french on the nim team, since I am québecois (living in ontario) and wish I were in france |
| 21:20:10 | dom96 | I wonder if we should worry about "partial code upgrades" in regards to package management. I.e. the ability for a single package to depend on two different versions of the same package. |
| 21:20:21 | mrwonko | okay, looks like 4 years ago there weren't yet any parser generators for Nim: https://forum.nim-lang.org/t/356 Maybe I could write the first one? |
| 21:20:39 | dom96 | Araq: ^ |
| 21:21:01 | dom96 | mrwonko: PMunch is working on one IIRC |
| 21:25:19 | Araq | dom96, nah |
| 21:25:43 | dom96 | Araq: Please read the discussion here, it's interesting: https://news.ycombinator.com/item?id=16679760 |
| 21:26:32 | * | nsf quit (Quit: WeeChat 2.0.1) |
| 21:26:40 | FromGitter | <alehander42> @mrwonko I am thinking about a simple parser dsl for a project of mine too : https://github.com/alehander42/area42/blob/master/lispy.grammar , but my parsers would be simpler and probably slower, parsing is not an important part of the project |
| 21:30:12 | FromGitter | <alehander42> @PMunch is working on some more serious parsing usecases and libs, he has a parser combinator library, you might be able to cooperate |
| 21:30:26 | * | krux02 joined #nim |
| 21:31:44 | FromGitter | <alehander42> he also has some binary parser generator libs etc |
| 21:33:17 | mrwonko | interesting, alehander42, I'll have to check out PMunch's work, I'm envisioning something very close to boost.Spirit except with a hopefully much simpler implementation thanks to Macros (which I've yet to try, this would be a great project for that) |
| 21:34:16 | kinkinkijkin | I really like the ability to give compiler instructions in nim, it seems gimmicky from the outside but genuinely has a lot of use cases |
| 21:37:34 | mrwonko | okay, I like this PMunch fella, he also had the idea of building a zero-overhead abstraction for cross-platform native GUIs, except he did it in Nim while I was thinking about maybe starting to do it in C++ one day: https://github.com/PMunch/genui |
| 21:38:56 | kinkinkijkin | so the nim compiler emits C, correct? |
| 21:39:20 | mrwonko | C or C++ or Objective-C or JS |
| 21:39:29 | kinkinkijkin | I see |
| 21:39:33 | krux02 | but by default it's C, yes |
| 21:39:39 | kinkinkijkin | what standard of C does it emit when emitting C? |
| 21:39:49 | mrwonko | Ah, I think I found the parser combinator you were talking about: https://github.com/PMunch/combparser |
| 21:40:07 | krux02 | kinkinkijkin: it depends |
| 21:40:19 | kinkinkijkin | configurable? |
| 21:40:42 | krux02 | it just creates C code, and there are some branches in the code generation where nim checks the backend C compiler and generats specific instructions for that |
| 21:40:51 | kinkinkijkin | ah I see |
| 21:41:04 | mrwonko | anyway, it's getting way to late, if you have anything else for me just tag me and gitter should send me a notification. See you later and happy hacking! |
| 21:41:18 | kinkinkijkin | so, theoretically, could it be made to emit C99 for BCC? |
| 21:41:38 | krux02 | yes |
| 21:41:40 | dom96 | It emits C99 |
| 21:42:03 | dom96 | AFAIK |
| 21:42:12 | krux02 | dom96: it is not strict c99 |
| 21:42:19 | * | jaco60 quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 21:42:51 | krux02 | I think the calling convention declarations for windows are not standard C |
| 21:43:12 | kinkinkijkin | oh wait, BCC only does K&R C lol |
| 21:43:18 | kinkinkijkin | so no making nim applications for DOS then |
| 21:43:32 | kinkinkijkin | unless there's a newer DOS C compiler |
| 21:44:36 | krux02 | kinkinkijkin: I heared a conference talk where someone did modern c++ and compiled it to commodore 64 |
| 21:46:15 | kinkinkijkin | interesting |
| 21:47:24 | krux02 | kinkinkijkin: I think you can understand that DOS is not an important target for the Nim community, but there should be nothing in your way to just create BCC target in the nim compiler on your own branch and whenever you actually get a problem you can create the correnponding braches in the code |
| 21:47:52 | kinkinkijkin | the issue is I don't know K&R C lol |
| 21:48:02 | kinkinkijkin | well, the first issue |
| 21:48:08 | kinkinkijkin | then the second issue is I don't actually care much |
| 21:48:17 | krux02 | well yea why do you want to program for DOS in the first place? |
| 21:48:29 | kinkinkijkin | I've been doing some testing for a PC emulator |
| 21:49:05 | kinkinkijkin | would like to write my tools in something I can write like english or french, instead of C, but it's fine |
| 21:49:32 | * | mrwonko quit (Quit: mrwonko) |
| 21:50:58 | krux02 | honestly I think at some time in the future it will be possible to do that. But a very fast computer and AI would be required to solve the ambiguety in the language |
| 21:51:33 | kinkinkijkin | I can write nim very easily |
| 21:51:37 | kinkinkijkin | is what I mean |
| 21:51:43 | kinkinkijkin | while I have some issues with C |
| 21:51:58 | * | littleli quit (Ping timeout: 264 seconds) |
| 21:52:02 | krux02 | well C is not too bad if you adopt a good style |
| 21:52:22 | kinkinkijkin | I haven't properly learned C so I don't think that'll happen soon |
| 21:52:54 | kinkinkijkin | I've mostly just transferred what I knew from java, c#, python, turing, and lua to it |
| 21:53:17 | kinkinkijkin | notice how all of them are JIT or interpreter languages that I knew beforehand |
| 21:53:29 | kinkinkijkin | so not very much good code gets written by myself |
| 21:53:34 | * | timotheecour joined #nim |
| 21:54:13 | * | littleli joined #nim |
| 21:56:37 | dom96 | Couldn't resist: https://forum.nim-lang.org/t/3689 |
| 21:57:57 | dom96 | PMunch: oh no, seems somebody beat you to it: https://github.com/oswjk/protobuf-nim |
| 21:58:34 | * | dgwana joined #nim |
| 22:14:11 | FromGitter | <mratsim> @kinkinkijkin, when you ask for non-referential dynamically size, did you mean something with value semantics (i.e. copy on assignment) or did you really meant something resizable on the stack? |
| 22:14:41 | FromGitter | <mratsim> by default Nim seq have value semantics, if you want reference semantics you need to wrap them in an object and add the pragma {.shallow.} |
| 22:15:08 | kinkinkijkin | oooooh that's what I meant |
| 22:15:16 | kinkinkijkin | okay no issues :ok_hand: |
| 22:16:21 | FromGitter | <mratsim> For a while I thought C sharp had value semantics resizeable array even though it’s a super mess in C and C++ xD |
| 22:18:06 | FromGitter | <mratsim> @pMunch, seems like you were too slow :P https://forum.nim-lang.org/t/3687 |
| 22:18:33 | FromGitter | <Varriount> @mratsim Or you can use the shallow() proc |
| 22:19:18 | FromGitter | <mratsim> oh right, I always forgot about this one. I prefer to encode bahaviours in types :) |
| 22:19:27 | FromGitter | <Varriount> So do I. |
| 22:26:44 | * | Snircle joined #nim |
| 22:27:23 | FromGitter | <zetashift> If I want my TokenType type to be a simple string, how do I do that again? Using `distinct`? I can't find it in the tutorial but I could swear I read it somewhere |
| 22:27:49 | FromGitter | <Varriount> @zetashift Do you want it to be implicitly convertible to a string? |
| 22:27:53 | Araq | Nim targets C89 fwiw |
| 22:28:07 | FromGitter | <zetashift> @Varriount yeah |
| 22:28:23 | FromGitter | <Varriount> Then just do `type TokenType = string` |
| 22:28:51 | FromGitter | <zetashift> Sweet thanks! |
| 22:30:27 | * | gokr quit (Ping timeout: 240 seconds) |
| 22:39:44 | * | yglukhov quit (Remote host closed the connection) |
| 22:40:17 | * | yglukhov joined #nim |
| 22:41:57 | * | yglukhov_ joined #nim |
| 22:41:58 | * | yglukhov quit (Read error: Connection reset by peer) |
| 22:46:18 | * | yglukhov_ quit (Ping timeout: 246 seconds) |
| 22:46:51 | Araq | dom96, doesn't convince me. |
| 22:47:03 | Araq | instead let's finally have lockfiles :P |
| 23:25:10 | * | find0x90 joined #nim |
| 23:51:49 | * | noonien quit (Quit: Connection closed for inactivity) |