| 00:00:03 | FromGitter | <zacharycarter> thanks @krux02 for pointing me to that |
| 00:02:01 | dom96 | if in doubt about the API you should use, ask here :) |
| 00:02:19 | dom96 | or rather I should say: if in doubt about how to design the API |
| 00:03:14 | FromGitter | <zacharycarter> I will |
| 00:03:27 | FromGitter | <zacharycarter> well - I'll definitely ask for feedback anyway |
| 00:03:47 | dom96 | Creating a TUI is amazingly fun |
| 00:05:57 | * | noonien quit (Quit: Connection closed for inactivity) |
| 00:07:04 | dom96 | Might just end up creating a package out of this |
| 00:07:52 | FromGitter | <zacharycarter> out of what? |
| 00:11:18 | dom96 | out of my little tui module |
| 00:11:42 | FromGitter | <zacharycarter> sounds interesting |
| 00:14:35 | dom96 | Pretty sure I just captured a Coinbase JSON response over my WiFi |
| 00:14:39 | dom96 | in plain text |
| 00:14:41 | dom96 | Fun |
| 00:15:15 | FromGitter | <zacharycarter> :D |
| 00:39:21 | * | gangstacat joined #nim |
| 01:03:35 | * | girvo quit (Quit: Ping timeout (120 seconds)) |
| 01:03:57 | * | arthurz joined #nim |
| 01:04:04 | * | girvo joined #nim |
| 01:13:48 | * | zarthur joined #nim |
| 01:16:59 | * | arthurz quit (Ping timeout: 276 seconds) |
| 01:41:40 | * | smt joined #nim |
| 01:42:18 | * | find0x90_ quit (Quit: find0x90_) |
| 01:46:05 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 01:48:59 | * | MJCaley joined #nim |
| 01:53:21 | * | MJCaley quit (Ping timeout: 240 seconds) |
| 01:54:28 | * | zarthur quit (Quit: Leaving) |
| 02:01:41 | * | find0x90 joined #nim |
| 02:02:56 | * | Snircle joined #nim |
| 02:10:44 | * | rockcavera quit (Ping timeout: 256 seconds) |
| 02:22:26 | shashlick | dom96: do share your TUI module, am definitely interested |
| 02:26:13 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 02:29:02 | * | rockcavera joined #nim |
| 02:32:08 | * | find0x90 quit (Quit: find0x90) |
| 02:54:03 | kinkinkijkin | anyone here who knows unix named pipes well? I want to work on fixing something but have a potential series of questions |
| 02:54:52 | kinkinkijkin | potential, which is why I'm not just outright asking |
| 02:55:37 | kinkinkijkin | don't have much battery time on my laptop to work on it so just ping me if you know named pipes and see this so I can start up my laptop |
| 02:56:26 | kinkinkijkin | actually one question I can just ask |
| 02:57:28 | * | S1tiSchu joined #nim |
| 02:57:29 | kinkinkijkin | is there any extraneous data extracted from named pipes in nim? I'm trying stream.readLine but apparently it's pulling in some garbage so idk how to continue with it |
| 02:58:01 | kinkinkijkin | this garbage is causing the demon I'm making to crash and pull down its layer with it (extremely unexpected behaviour, considering the simplicity of the code) |
| 02:58:24 | kinkinkijkin | as in, if I run the demon to test in a urxvt window, it crashes urxvt |
| 02:58:45 | kinkinkijkin | only when it reaches garbage in the named pipe |
| 03:00:54 | * | S1t1Schu quit (Ping timeout: 260 seconds) |
| 03:01:40 | * | r2 joined #nim |
| 03:06:51 | * | r2 quit (Ping timeout: 240 seconds) |
| 03:29:13 | * | dddddd quit (Remote host closed the connection) |
| 04:02:23 | * | leorize quit (Read error: Connection reset by peer) |
| 04:06:40 | * | leorize joined #nim |
| 04:16:23 | * | SenasOzys quit (Ping timeout: 276 seconds) |
| 04:18:32 | FromDiscord | <Yardanico> https://github.com/nim-lang/Nim/pull/7403 lol |
| 04:19:37 | * | r2 joined #nim |
| 04:20:51 | kinkinkijkin | isn't D made for systems stuff? |
| 04:21:43 | FromDiscord | <Yardanico> I mean I'm not sure that it's true that Nim took ctfe from D and not from lisp (I may be wrong though) |
| 04:23:57 | * | r2 quit (Ping timeout: 240 seconds) |
| 04:28:11 | FromGitter | <Varriount> kinkinkijin: What OS are you running on? |
| 04:28:29 | kinkinkijkin | openbsd |
| 04:28:42 | kinkinkijkin | with the 0.16 from the openbsd pkg system |
| 04:29:02 | kinkinkijkin | have to manually compile with egcc to use 0.18 |
| 04:29:10 | kinkinkijkin | for known reasons |
| 04:30:07 | kinkinkijkin | idk why openbsd doesn't just start using clang, other than their strange opposition to using c++ |
| 04:31:16 | FromGitter | <Varriount> Have you tried reading from the pipe using standard read() calls? |
| 04:32:47 | kinkinkijkin | I have not, with the design of my program that would be impractical to implement since I need arbitrary command lengths, do you think this would change what it's getting? |
| 04:47:31 | * | Ven`` joined #nim |
| 04:49:20 | kinkinkijkin | I've gotta go to bed, if you reply again that's where I went |
| 05:23:20 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 05:27:27 | * | nsf joined #nim |
| 06:04:17 | * | r3d9u11 joined #nim |
| 06:07:35 | * | r2 joined #nim |
| 06:08:50 | * | yglukhov quit (Ping timeout: 276 seconds) |
| 06:12:50 | * | r2 quit (Ping timeout: 276 seconds) |
| 06:16:22 | * | yglukhov joined #nim |
| 06:20:49 | * | yglukhov quit (Ping timeout: 248 seconds) |
| 07:13:34 | * | Trustable joined #nim |
| 07:22:35 | * | miran joined #nim |
| 07:25:31 | * | SitiSchu joined #nim |
| 07:27:37 | * | S1tiSchu quit (Ping timeout: 256 seconds) |
| 07:28:41 | * | yglukhov joined #nim |
| 07:58:10 | Araq | hmm is everybody fine with the compiler producing URLs in its error messages? |
| 07:58:36 | Araq | that lead to some online help? |
| 07:58:47 | * | rauss quit (Ping timeout: 256 seconds) |
| 08:03:15 | * | rokups joined #nim |
| 08:05:08 | FromDiscord | <Yardanico> IDK, maybe it's good for some cases so you don't need to Google the error :) But generally it will probably be annoying if compiler gives you url for all errors |
| 08:06:18 | FromGitter | <alehander42> @krux02 one of the first reasons for zero_functional was to optimize chaining "iterators" & zip: https://github.com/alehander42/zero-functional/blob/master/test.nim#L34 |
| 08:06:57 | FromGitter | <alehander42> however, if iterators could be chained natively, that would be the best option always, as loopfusion and zero_functional are hard to extend with new methods for outside users |
| 08:08:21 | FromGitter | <alehander42> @Araq for all messages? I think it's a nice idea with the right formatting, at least for some errors |
| 08:08:21 | * | r2 joined #nim |
| 08:10:48 | Araq | no, for the 'var T' stuff I'm doing which is subtle |
| 08:11:04 | Araq | and maybe for 'gcsafe', effects |
| 08:11:29 | Araq | not for all error messages. |
| 08:13:33 | * | r2 quit (Ping timeout: 264 seconds) |
| 08:15:32 | FromGitter | <alehander42> then, I think it can very useful |
| 08:15:37 | FromGitter | <alehander42> can be* |
| 08:20:03 | FromGitter | <abijahm> does nim lang have asyncstreams |
| 08:24:35 | * | yglukhov quit () |
| 08:24:42 | * | r2 joined #nim |
| 08:29:19 | * | r2 quit (Ping timeout: 260 seconds) |
| 08:35:30 | * | yglukhov joined #nim |
| 08:43:07 | FromGitter | <abijahm> found it |
| 08:52:13 | FromGitter | <mratsim> I also think URL with "Relevant article: https://yourawesomeURL” is good. It can started pointing to the manual and as Nim develops to a wiki/FAQ that everyone can edit for example. |
| 08:53:10 | Yardanico | I've added a couple of issues in this D_vs_nim repo (it contains some invalid data), for example it says that nimble only has 194(!) packages. https://github.com/timotheecour/D_vs_nim/issues/3 |
| 08:54:40 | Araq | mratsim: I am thinking about short articles specialized for these error messages |
| 08:54:49 | Yardanico | and btw, dlang only has 1248 packages, wtf |
| 08:55:08 | Yardanico | I thought it will have much more of them :) |
| 08:55:12 | Araq | that then might link into the manual for further clarification |
| 08:56:18 | Yardanico | also, nim supports local imports, right? |
| 08:58:48 | Araq | no. |
| 08:59:21 | Araq | they would cause scoping problems. See D ;-) |
| 08:59:41 | Yardanico | Araq, I'm just checking if stuff in https://github.com/timotheecour/D_vs_nim about Nim is valid :) |
| 09:00:19 | FromGitter | <mratsim> @Araq: I don’t have fold and foldl, I have fold, reduce, foldaxis, fold_enumerableAxis ;). But I completely agree with your points. @dom96 Here is what I want to replace with loopfusion in Arraymancer, 3 files of various: zip, zipAxis, mzip, enumerateAxis, map, map2, map3, apply, apply2, apply3, template and higher-order function versions: https://github.com/mratsim/Arraymancer/blob/master/src/tensor/accessors.nim, |
| 09:00:19 | FromGitter | ... https://github.com/mratsim/Arraymancer/blob/master/src/tensor/higher_order_applymap.nim, https://github.com/mratsim/Arraymancer/blob/master/src/tensor/higher_order_foldreduce.nim ⏎ ⏎ In the end for Tensors I only need a `forEach`, `forEachOMP` (cannot allow heap alloc inside), and a “forEachOMPreduce” (name to find). |
| 09:01:04 | FromGitter | <mratsim> oh I forgot about menumerateAxis, enumerateZip and menumerateZip |
| 09:05:18 | Araq | a new error message to confuse you. 'x' is not the first parameter; context: 'x.field[0]' |
| 09:05:52 | * | r2 joined #nim |
| 09:06:19 | FromGitter | <mratsim> Don’t break mpairs by the way ;) |
| 09:06:36 | Araq | I did 'tt collections' |
| 09:06:45 | Araq | and assume mpairs is covered by that |
| 09:07:48 | FromGitter | <mratsim> anyway, if you add the corresponding macros stuff for “from”/“scope” I will update loopfusion to hide that. |
| 09:08:14 | Araq | hmm? |
| 09:08:21 | Araq | 'from' is not part of the RFC |
| 09:09:50 | FromGitter | <mratsim> ah right, future directions |
| 09:11:09 | * | r2 quit (Ping timeout: 264 seconds) |
| 09:12:01 | Yardanico | Araq, should I use assert or doAssert in runnableExamples? |
| 09:12:20 | FromGitter | <mratsim> https://github.com/timotheecour/D_vs_nim |
| 09:12:29 | miran | Yardanico: i'm using doAssert, as shown in the release notes for 0.18 |
| 09:12:39 | FromGitter | <mratsim> @yardanico doAssert otherwise your examples will always succeed in release mode |
| 09:12:44 | Yardanico | ok, thanks |
| 09:13:14 | FromGitter | <mratsim> Timothee is the maintainer of Dub, the D package manager and opened a PR to add D as influence to Nim yesterday ;) |
| 09:13:30 | Yardanico | yes :D |
| 09:13:36 | Yardanico | also D_vs_nim repo says that nimble has 194 packages |
| 09:14:28 | miran | btw, iterators taking openArray[T] are working fine (as shown in sequtils.filter), but when i use proc which takes openArray[T] and it returns an iterator (i'm wrapping the iterator) - compiler doesn't like that. |
| 09:15:02 | Araq | Yardanico: doAssert |
| 09:15:05 | FromGitter | <mratsim> don’t capture openarrays in iterators, otherwise it can escape |
| 09:15:19 | FromGitter | <mratsim> I struggled with that too miran ;) |
| 09:15:26 | miran | i get "illegal capture" - what am i doing wrong and how to make it right? |
| 09:15:29 | FromGitter | <mratsim> in closure* iterators |
| 09:16:01 | FromGitter | <mratsim> basically a closure iterator copies it’s environment, but you cannot copy an openarray, it’s not a first class type |
| 09:16:05 | FromGitter | <mratsim> its* |
| 09:16:30 | FromGitter | <mratsim> so you can overload for seq and arrays |
| 09:17:42 | miran | oh, so basically have two version of everything? |
| 09:18:05 | Araq | capture the @x instead |
| 09:18:28 | Araq | proc outer(x: openArray[T]) = |
| 09:18:34 | Araq | let x = @x |
| 09:18:40 | Araq | proc inner = use(x) |
| 09:19:00 | Araq | no need for two versions. |
| 09:19:12 | miran | Araq: wow, very nice, thanks! |
| 09:19:41 | miran | my first nible package (to be released :)) just became much more useful |
| 09:23:41 | FromGitter | <mratsim> @Araq @x on seq is a noop? |
| 09:24:39 | FromGitter | <mratsim> I’m worried (like always) that let x = @x will allocate :/ |
| 09:36:54 | Araq | well it does |
| 09:37:13 | Yardanico | Hmmm, I have a weird formatting issue with runnableExamples and a template - https://i.imgur.com/QlNiOMH.png |
| 09:37:53 | Yardanico | (it works fine with normal procedures) |
| 09:38:41 | FromGitter | <mratsim> @yardanico: thoughts? https://github.com/timotheecour/D_vs_nim/pull/6 |
| 09:39:10 | Yardanico | @mratsim: yeah, cool one |
| 09:39:37 | miran | Yardanico: if you add a second line to docstring, "examples" will be in a separate row |
| 09:39:55 | Yardanico | miran, oh, thanks for the workaround |
| 09:39:58 | Yardanico | but it seems to be a real bug |
| 09:40:42 | Yardanico | Yeah, adding second line works |
| 09:41:30 | Yardanico | Also I thought that `nim doc` will preserve comments inside of runnableExamples section, but it doesn't |
| 09:41:36 | miran | Yardanico: yeah, it is a workaround and i would rather see that examples are always on the separate lines, but i can live with it (for now) |
| 09:43:20 | miran | yeah, dropping comments is a pity |
| 09:43:56 | Yardanico | I'll probably use plain code insertion via markdown for now |
| 09:45:05 | miran | but doing it like that - it is not tested, right? |
| 09:45:19 | Yardanico | miran, yes :( |
| 09:46:48 | FromGitter | <abijahm> how do one transfer contents of on future stream to another,something like pipe() in nodejs im trying this but i only get two writes ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ only hello and hello1 is written to rec [https://gitter.im/nim-lang/Nim?at=5ab61e88e3d0b1ff2c612f0a] |
| 09:54:59 | * | xkapastel quit (Quit: Connection closed for inactivity) |
| 10:01:37 | * | gokr joined #nim |
| 10:09:22 | dom96 | Araq: URLs in error messages sound nice. But it should be something like "This 'var' type is <some reason for error here>. For more details see here: ..." |
| 10:11:47 | miran | +1 |
| 10:13:49 | Araq | can't come up for a short reason |
| 10:15:26 | dom96 | well please don't just have an url |
| 10:15:41 | Araq | read my RFC and tell me |
| 10:15:47 | Araq | what the error message should say |
| 10:18:33 | FromGitter | <wu-lee> Newbie trying concepts here... I can't get any examples or my own experiments to work, I always get an error "'x' is declared but not used" |
| 10:19:27 | leorize | wu-lee: Some code snippets would be helpful |
| 10:21:24 | FromGitter | <wu-lee> Well, I'm starting with the example in the nim manual... |
| 10:22:05 | FromGitter | <wu-lee> If I could find a working example of concepts, that might help me get off the ground. |
| 10:22:55 | FromGitter | <wu-lee> The only other mention of this error i can find is on this post: https://forum.nim-lang.org/t/3560 |
| 10:23:26 | Yardanico | you can post your code via gist so we can check it |
| 10:23:35 | Yardanico | or with any other pasting service |
| 10:23:41 | Yardanico | also play.nim-lang.org is useful |
| 10:24:06 | Araq | Error: unhandled exception: getTime() + hours(24) == getTime() + days(1) [AssertionError] |
| 10:24:18 | Araq | looks like our time tests are not correct |
| 10:24:38 | Yardanico | Araq, getTime() can probably change? |
| 10:24:45 | Yardanico | before first and second call |
| 10:25:04 | Araq | well my HW clock is always 5 minutes off |
| 10:25:16 | Araq | maybe it's got something to do with it. |
| 10:25:18 | FromGitter | <wu-lee> @Yardanico , @leorize, it really seems barely worth posting what I have, I've hit a brick wall so early it's not changed significantly from the examples |
| 10:27:39 | FromGitter | <wu-lee> Here's someone else's example which gets the same XDeclaredButNotUsed error https://gist.githubusercontent.com/PhilipWitte/33819b40112a18c30b43/raw/4fb1fb665c91fa2fa3b10c538be178b0da657cb7/concepts.nim |
| 10:27:52 | Araq | XDeclaredButNotUsed is not an error |
| 10:28:52 | FromGitter | <wu-lee> @araq, Ok, point taken. But should I ignore it? |
| 10:29:05 | FromGitter | <alehander42> where is the errors RFC |
| 10:29:11 | miran | wu-lee: either ignore it or use X :) |
| 10:30:06 | Yardanico | wu-lee it's just a hint for programmer :) |
| 10:30:16 | Araq | it is used. |
| 10:30:23 | Yardanico | green - some [hint], yellow - warning, red - error |
| 10:31:09 | Araq | wu-lee: your code works with a 'mixin dance' annotation in your proc doBallet |
| 10:31:40 | FromGitter | <wu-lee> Hmm. In PhilipWitte's example, is the 'x' in the concept not used? |
| 10:32:30 | Araq | it is used and the compiler should not report it, looking into it |
| 10:41:03 | Araq | why does hot code reloading require a 'once'? |
| 10:41:29 | Araq | breaks the abstraction. |
| 10:41:43 | FromGitter | <alehander42> sometimes you need to init something or to preserve state between reloadings |
| 10:43:35 | Araq | yes, obviously. when is that? |
| 10:43:55 | Araq | and why does JS offer hot code reloading without a 'once' construct? |
| 10:48:09 | dom96 | I'm still of the opinion that 'once' should be the default behaviour |
| 10:48:31 | FromGitter | <alehander42> well, you often have to deal with 3rd party / framework / host code that isn't "hot reloaded", so you have to e.g. setup listeners/create some intiial state/register hooks only once |
| 10:49:42 | Araq | again, how does JS deal with it? |
| 10:49:47 | dom96 | surely you'd want to explicitly specify the parts that should be reloaded |
| 10:49:50 | dom96 | not the parts that shouldn't |
| 10:51:00 | Araq | for me hot-code-reloading is like variable inspection in a debugger. the language shouldn't be concerned about it. |
| 10:51:33 | Araq | alternatively you can request a reload via an API call |
| 10:52:01 | Araq | but the PR doesn't offer such an API |
| 10:52:42 | Araq | and thinking about it |
| 10:52:46 | Araq | I agree with dom96. |
| 10:52:55 | Araq | you want to reload the code, not the state |
| 10:53:05 | Araq | so globals should all be 'once' |
| 10:55:23 | Araq | I think the JS codegen should create 2 .js files, globals.js and functions.js and functions.js are reloaded |
| 10:55:31 | Araq | bbl |
| 10:55:57 | FromGitter | <alehander42> well js hot reloading systems probably use some global variable-based checking for "once", that's what this PR does too, once is just a useful dsl for it |
| 10:56:32 | FromGitter | <GULPF> @Araq Where is that times test? I can't find it. |
| 10:57:57 | FromGitter | <alehander42> maybe globals should be `once` by default indeed, if that's the most common case |
| 10:58:53 | FromGitter | <alehander42> well, how would top-level code that depends on a function work in that case? globals.js and functions.js would depend on each other |
| 11:00:24 | FromGitter | <GULPF> The reason that it fails is because `1.days` is only equal to `24.hours` when there are no UTC offset changes. Europe switches to summer time tomorrow, so "add one day" actually means "add 23 hours". |
| 11:01:45 | * | dddddd joined #nim |
| 11:04:33 | FromGitter | <zah> Araq, a construct like once is needed in pretty much every project that employs hot reloading. As far as I understand you expect that only reloading the function definitions is enough, but this is naive. Even my Karax example woudn't work if there wasn't a call to "redraw" at the top level of the module |
| 11:05:12 | FromGitter | <zah> And executing all of the top-level code is obviously wrong too, so the programmer just needs to have this control |
| 11:05:46 | FromGitter | <zah> it could be argued what should be the default, but let us gain some more experience and we'll see |
| 11:11:39 | * | SenasOzys joined #nim |
| 11:12:07 | FromGitter | <zah> I'm not sure what you refer to when you say "how does JS do it?". I've used hot reloading in the context of game scripting and web development and each project had specific peculiarities that must be taken care of during hot reloads |
| 11:16:34 | * | Vladar joined #nim |
| 11:42:15 | * | NimBot joined #nim |
| 11:42:58 | FromGitter | <mratsim> How does nrpl does it for its nim repo? (didn’t read the code): https://github.com/wheineman/nrpl |
| 11:48:57 | * | Vladar quit (Ping timeout: 240 seconds) |
| 11:55:26 | * | Ven`` joined #nim |
| 11:55:51 | FromGitter | <zah> I've considered one alternative API that might work well (subscribing to a "onCodeReload" event), but it would have been more complicated to implement |
| 12:07:33 | * | miran quit (Ping timeout: 256 seconds) |
| 12:24:52 | * | SenasOzys_ joined #nim |
| 12:25:16 | * | SenasOzys quit (Ping timeout: 276 seconds) |
| 12:30:24 | Araq | GULPF: it was in tests/stdlib |
| 12:36:30 | Araq | zah: for the C target I imagined a call like reloadDll("foo.dll") that can be wired to some console command (assuming your engine has a console) |
| 12:37:07 | Araq | and that would reload the DLL, but not the state. your example about 'redraw' is also only about "code"/functions |
| 12:38:30 | FromGitter | <zah> No, reloading code in C++ is much more complicated. My plan is to allow the user to supply a module that will be responsible for two things: ⏎ ⏎ 1) Listening for external notifications (e.g. on the network, by monitoring a file, by listening on a PIPE, etc) ⏎ 2) Calling a function provided by the compiler that does the rest [https://gitter.im/nim-lang/Nim?at=5ab646c6e4ff28713a6ba75e] |
| 12:39:04 | FromGitter | <zah> The first part depends very strongly on what kind of event loop the program is executing |
| 12:41:42 | FromGitter | <zah> I didn't understand your comment about redraw being a "code" function |
| 12:42:13 | FromGitter | <zah> Perhaps you've missed the part of the spec where I explain that variable initializations happen only once by default |
| 12:51:07 | * | Vladar joined #nim |
| 13:07:37 | FromGitter | <zah> the event-like API has some benefits though - it allows you to execute code even in modules that are not being changed in the current reload. I could declare the current API experimental and perhaps change it later when the C hot reloading is also implemented? |
| 13:17:14 | * | yglukhov quit (Remote host closed the connection) |
| 13:17:47 | * | yglukhov joined #nim |
| 13:21:57 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 13:34:26 | FromGitter | <zacharycarter> how are you going to address state? |
| 13:34:44 | FromGitter | <zacharycarter> unless you're talking about JS |
| 13:34:47 | FromGitter | <zacharycarter> then ignore my question |
| 13:34:49 | * | SenasOzys_ quit (Ping timeout: 276 seconds) |
| 13:35:27 | * | cspar_ quit (Ping timeout: 240 seconds) |
| 13:39:56 | * | SenasOzys_ joined #nim |
| 13:41:48 | FromGitter | <zah> the state is not touched on reloads unless explicitly requested by the programmer |
| 13:42:32 | FromGitter | <zah> if type definitions change, you must restart the program |
| 13:43:58 | leorize | hi everyone, what are your recommendations regarding unit tests? |
| 13:44:51 | * | brainproxy quit (Ping timeout: 240 seconds) |
| 13:45:15 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:49:11 | FromGitter | <zacharycarter> https://plg.uwaterloo.ca/~cforall/ |
| 13:49:52 | FromGitter | <zacharycarter> leorize: use the unittest module |
| 14:17:15 | * | find0x90 joined #nim |
| 14:25:23 | * | brainproxy joined #nim |
| 14:25:27 | * | find0x90 quit (Ping timeout: 240 seconds) |
| 14:28:32 | * | find0x90_ joined #nim |
| 14:31:20 | Araq | @zah, I'm probably too much in the "REPL" mindset. Python has a REPL and yet no need for 'once' sections. |
| 14:31:28 | Araq | or let's say |
| 14:31:38 | Araq | no clean distinction between once and not-once |
| 14:37:05 | * | Ven`` joined #nim |
| 14:38:59 | * | find0x90_ quit (Quit: find0x90_) |
| 14:58:23 | * | brainproxy quit (Ping timeout: 260 seconds) |
| 15:05:32 | * | miran joined #nim |
| 15:07:32 | * | brainproxy joined #nim |
| 15:12:42 | Yardanico | BTW, C and JS backends produce different results for 0/0 |
| 15:12:51 | Yardanico | C backend produces fcNan, JS backend - fcZero :D |
| 15:13:39 | Araq | C backend is right |
| 15:13:44 | Araq | as usual for these things. |
| 15:14:34 | * | xkapastel joined #nim |
| 15:14:51 | * | jaco60 joined #nim |
| 15:20:49 | miran | i'm still torn between normal iterators and iterators wrapped in proc for nim version of https://docs.python.org/3.5/library/itertools.html |
| 15:21:32 | miran | each version has some (dis)advantages, and i don't know what is more important/useful and/or easier to use.... |
| 15:22:54 | miran | if any of you has a clear favourite, please let me know.... |
| 15:28:41 | FromGitter | <mratsim> This is awesome: https://github.com/nim-lang/Nim/commit/121b9e26fb9d1ae6037c806dbb12a3ae0e26ded6 !! |
| 15:29:30 | FromGitter | <mratsim> @miran, if you can chain normal iterator, use the normal one, the closure iterator are unnecessarily slow for those use case. |
| 15:30:46 | miran | currently my iterators take seqs (or more generally openarrays) as a first argument. for chaining i would need versions which take iterators as first argument? |
| 15:31:02 | miran | (haven't tried chaining yet) |
| 15:32:06 | FromGitter | <mratsim> cooldome once said that it’s easy to fix if you want to dive in nim compiler: https://github.com/nim-lang/Nim/issues/4516 and https://github.com/nim-lang/Nim/blob/8f67b90997d1c0416c4991ecec666a63339103c2/compiler/semstmts.nim#L665 |
| 15:33:27 | FromGitter | <mratsim> yes if this was fixed, you could just do `let foo = yours.items.map(bar).filter(baz).collect` or something like this |
| 15:33:40 | FromGitter | <mratsim> yourseq not yours |
| 15:33:52 | miran | i'm not experienced enough to mess with compiler :) |
| 15:34:58 | FromGitter | <mratsim> in my opinion, closure iterators creates strange things like here: https://github.com/mratsim/nim-projecteuler/blob/master/src/pe002_even_fibonacci_numbers.nim#L16 |
| 15:35:32 | FromGitter | <mratsim> see the parenthesis: s().toSeq, s() is to call the closure iterator. |
| 15:36:44 | miran | yeah, i'm torn between that kind of syntax and the (imo) simpler one which is: `for i in cycle(myseq): echo i` |
| 15:37:16 | miran | ...which has some other disadvantages in other places |
| 15:37:30 | FromGitter | <mratsim> do both :P, keep in mind this package: https://github.com/Michedev/sequtils2 |
| 15:39:51 | FromGitter | <mratsim> Oh, closure iterators sometimes get super weird, check out this one: https://github.com/mratsim/nim-projecteuler/blob/09c6bf59d974b530e0a4a2b64aa1ce263214d0f9/src/pe008_largest_product_in_a_series.nim#L64-L69 |
| 15:40:21 | FromGitter | <mratsim> `proc genWindows(n_str: string, size: int): iterator (): DigProduct = result = iterator(): DigProduct = … ` |
| 15:40:34 | miran | :D |
| 15:40:36 | Araq | the good news is: I'm pretty sure how closure iterators should be done |
| 15:40:55 | * | brainproxy quit (Ping timeout: 276 seconds) |
| 15:41:00 | Araq | the bad news: It's a ton of work and we're held back by some legacy code (all of .async) |
| 15:42:36 | miran | mratsim: i guess the plain and simple `iterator foo...` (instead of `proc foo...`) would also help with using openArrays without the need to convert it to a seq.... |
| 15:43:46 | miran | but most of iterators i have seen in the wild are wrapped in proc, and my thinking is: these people are more experienced than me, and chose that version for a reason, i should follow that |
| 15:44:11 | Araq | huh? most iterators are .inline |
| 15:44:13 | FromGitter | <mratsim> nah, ask questions :P |
| 15:44:49 | FromGitter | <mratsim> iterators are mostly inline. mora and me used proc because we wanted to chain them in functional style and inline cannot be chained |
| 15:45:11 | miran | Araq: i've seen iterators in sequtils are inline, but people (including mratsim :)) writing their own iterators are wrapping them inside of procs |
| 15:45:19 | FromGitter | <mratsim> I’m not doing that anymore, I use template with {.inject.} now |
| 15:46:59 | miran | well, if imposibility of chaining is the only major disadvantage of inline iterators, i guess i can then use inline for these: https://docs.python.org/3.5/library/itertools.html ? |
| 15:47:01 | FromGitter | <mratsim> Or I would use loopfusion (if I don’t want to use functional style) or zero_functional (if I want functional style) |
| 15:48:06 | FromGitter | <mratsim> yes use a normal iterator for these and kindly wait for inline iterator chaining to be fixed :shipit: |
| 15:48:38 | Yardanico | Araq, well it will be fine if we'll be able to write async using new iterators :) |
| 15:48:46 | Yardanico | or implement async in some another way... |
| 15:48:51 | * | rauss joined #nim |
| 15:48:55 | Yardanico | but yeah, this will break a LOT of code |
| 15:48:57 | * | brainproxy joined #nim |
| 15:49:15 | miran | i'm thinking there might be a reason to have these first three infinite iterators are closures, others can be inline |
| 15:51:29 | planetis[m] | btw when I want to use some kind of iterator I write an object and a while loop, much easier to read and structure correctly |
| 15:58:28 | * | cspar_ joined #nim |
| 16:22:23 | * | brainproxy quit (Ping timeout: 260 seconds) |
| 16:25:32 | * | brainproxy joined #nim |
| 16:28:36 | * | nsf quit (Quit: WeeChat 2.0.1) |
| 16:30:35 | * | PMunch joined #nim |
| 16:58:51 | * | brainproxy quit (Ping timeout: 240 seconds) |
| 17:02:01 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:02:17 | * | Ven`` joined #nim |
| 17:02:49 | * | Ven`` quit (Client Quit) |
| 17:09:45 | * | brainproxy joined #nim |
| 17:15:16 | * | yglukhov joined #nim |
| 17:23:35 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 17:24:35 | * | yglukhov joined #nim |
| 17:24:53 | Araq | itertools.starmap :-) |
| 17:42:35 | * | brainproxy quit (Ping timeout: 240 seconds) |
| 17:45:56 | * | Ven`` joined #nim |
| 17:46:20 | * | brainproxy joined #nim |
| 18:02:03 | * | Trustable quit (Remote host closed the connection) |
| 18:05:58 | PMunch | Hmm, the protobuf format has a weird thing with sub-messages |
| 18:06:11 | PMunch | They are encoded as number of bytes, and then the message |
| 18:06:37 | PMunch | Which means you need to first figure out how many bytes the message is, then write the size, then write the message.. |
| 18:07:22 | PMunch | And of course they can have variable length fields, and further sub-messages.. |
| 18:07:34 | * | SenasOzys_ quit (Ping timeout: 264 seconds) |
| 18:07:57 | PMunch | I'm tempted to just write all sub-messages into a string stream, get the position and write that out, then write the entire string stream into the output stream.. |
| 18:08:34 | PMunch | And of course the length is a varint, meaning variable size. So you can't just reserve N bytes either.. |
| 18:09:05 | Araq | can you oversize the varint? |
| 18:09:20 | PMunch | Hmm, I guess you theoretically could.. |
| 18:09:20 | Araq | like always use 4 bytes for the varint even it might fit into 2? |
| 18:10:00 | PMunch | The varint format is basically "if the byte starts with a 1 it is the final byte, otherwise concatenate to the current value and read the next byte" |
| 18:10:18 | PMunch | So I guess you could send null bytes to begin with |
| 18:10:48 | Araq | yup |
| 18:10:56 | PMunch | Oh no, wait |
| 18:11:30 | PMunch | They store them with least significant bit group first, not last. But you could still use "empty" bytes at the end |
| 18:11:53 | PMunch | But that means seeking in the stream, which isn't all that nice.. |
| 18:12:40 | PMunch | I guess each message type could also declare a len proc, that calculates the length of it's fields |
| 18:13:13 | PMunch | I guess that would be the "cleaner" option |
| 18:19:13 | * | brainproxy quit (Ping timeout: 248 seconds) |
| 18:29:36 | * | brainproxy joined #nim |
| 18:42:12 | * | SenasOzys_ joined #nim |
| 18:57:21 | * | find0x90 joined #nim |
| 19:02:55 | * | brainproxy quit (Ping timeout: 256 seconds) |
| 19:04:21 | * | find0x90 quit (Quit: find0x90) |
| 19:05:32 | * | tiocavera joined #nim |
| 19:05:32 | * | rockcavera quit (Killed (adams.freenode.net (Nickname regained by services))) |
| 19:05:32 | * | tiocavera is now known as rockcavera |
| 19:07:44 | * | brainproxy joined #nim |
| 19:13:28 | * | rauss quit (Ping timeout: 276 seconds) |
| 19:15:13 | * | rauss joined #nim |
| 19:27:28 | Araq | toOpenArray is now a thing, enjoy. (and report bugs of course) |
| 19:35:31 | miran | nice, thanks! :) |
| 19:47:21 | * | xet7 quit (Ping timeout: 240 seconds) |
| 19:50:43 | * | nsf joined #nim |
| 19:58:37 | shashlick | when you have a macro in a nimble library and call it from your code, why does nim chdir into that directory during build time? |
| 19:59:11 | shashlick | i'm doing some file related ops in the macro and all my relative paths fail |
| 20:00:57 | shashlick | i tried both import and include of the lib but directory still changes |
| 20:07:02 | dom96 | https://twitter.com/d0m96/status/977637733173792769 |
| 20:10:13 | * | r3d9u11 quit (Remote host closed the connection) |
| 20:18:21 | Yardanico | Araq, what is "syntax sugar yet to come" for toOpenArray? |
| 20:32:32 | * | arecaceae quit (Remote host closed the connection) |
| 20:32:55 | * | arecaceae joined #nim |
| 20:50:17 | * | gus_ joined #nim |
| 20:58:29 | * | yglukhov quit (Remote host closed the connection) |
| 20:59:04 | * | yglukhov joined #nim |
| 21:00:51 | Araq | Yardanico, a[x..y] = b[u..v] should not produce a temp seq |
| 21:01:14 | Araq | and takesOpenArray(x[1..3]) can also be optimized to a non-copy slice |
| 21:03:57 | * | yglukhov quit (Ping timeout: 264 seconds) |
| 21:07:41 | shashlick | araq: any idea why macros change directory during compile time? ^ |
| 21:07:57 | Araq | change directory? |
| 21:08:58 | shashlick | as I described earlier, if you do file operations in a macro in a nimble library, it changes dir to that nimble package dir during compile time |
| 21:09:06 | shashlick | so any relative file paths don't work |
| 21:09:16 | Araq | nimble issue? |
| 21:09:28 | Araq | I don't use setCurrentDir in the compiler |
| 21:09:34 | * | rokups quit (Quit: Connection closed for inactivity) |
| 21:09:52 | Araq | well except to support it in NimScript |
| 21:10:22 | shashlick | let me check real quick |
| 21:12:34 | shashlick | yep, could reproduce it without nimble |
| 21:12:48 | Araq | how? |
| 21:13:05 | shashlick | posting gist |
| 21:13:19 | Yardanico | Araq, wow, that'll be cool |
| 21:15:04 | shashlick | b.nim which calls test() macro from a.nim: http://ix.io/124Z |
| 21:15:25 | shashlick | a.nim = http://ix.io/1252 |
| 21:15:39 | shashlick | put them in different directories and used --path:xyz |
| 21:15:39 | * | gus_ quit (Ping timeout: 260 seconds) |
| 21:16:02 | Araq | oh so it's about staticExec |
| 21:16:41 | shashlick | well, in the real code, I was using staticRead but it could never find the file |
| 21:17:52 | shashlick | it will print out the path to a.nim even though you are building in b.nim's directory |
| 21:19:02 | * | smt` joined #nim |
| 21:23:05 | * | smt quit (Ping timeout: 268 seconds) |
| 21:26:26 | * | zolk3ri joined #nim |
| 21:34:00 | * | gokr quit (Quit: Leaving.) |
| 21:42:44 | * | rockcavera quit (Remote host closed the connection) |
| 21:51:39 | * | aguspiza joined #nim |
| 21:54:40 | Araq | shashlick, for me it outputs C:\Users\rumpf\projects\nim\testresults |
| 21:54:47 | Araq | which is where my a.nim resides |
| 21:55:16 | Araq | and that's how it should be, stuff is relative to current module |
| 21:55:48 | Araq | because the module knows its relative position but a cwd is fragile |
| 21:56:18 | shashlick | but b.nim is what you are building, and a.nim is somewhere else |
| 21:56:42 | Araq | a.nim does the staticRead |
| 21:56:52 | shashlick | how do you reference build artifacts in the build directory in a library macro then? |
| 21:56:55 | * | Vladar quit (Remote host closed the connection) |
| 21:57:40 | Araq | src/nested/foo.nim foo.nim uses staticRead("../../resources/x.txt") |
| 21:58:23 | shashlick | agreed, but it's not useful in a library context - i'm trying to build a lib that bundles data files into the executable |
| 21:59:16 | Araq | so pass the path to the library |
| 21:59:44 | Araq | instead of relying on cwd. cwd never works anyway |
| 22:00:59 | shashlick | makes it much more complicated since on execution, the data files should be extracted back to the relative locations, operating on absolutes is roundabout |
| 22:01:35 | shashlick | anyway, i was just wondering what's the logic of changing directories |
| 22:02:04 | shashlick | i kind of get it but it makes it fragile when you want to make libraries that everyone can consume |
| 22:02:36 | Araq | it doesn't change directories. |
| 22:02:49 | Araq | it sets the directory for staticExec invokations |
| 22:03:37 | shashlick | ya, that's what i meant to say, being relative to the nim file rather than build process |
| 22:04:21 | shashlick | makes it complicated to put your macros in source files in sub-directories |
| 22:04:23 | Araq | I don't see how cwd enables "libraries everyone can consume" |
| 22:05:02 | Araq | all I see are projects where 'nim c src/main' becomes different from 'cd src; nim c main' |
| 22:05:15 | Araq | which is the far worse solution |
| 22:06:17 | Araq | and staticExec was changed to behave this way based on bug reports |
| 22:06:22 | Araq | fyi. |
| 22:06:33 | Araq | it's not just my opinion |
| 22:12:03 | shashlick | found the issue - it was inconsistent and you made it consistent 🙂- cc flyx |
| 22:12:17 | shashlick | it's still confusing so documenting will help |
| 22:12:18 | shashlick | https://github.com/nim-lang/Nim/issues/4871 |
| 22:14:47 | * | yglukhov joined #nim |
| 22:18:24 | * | jaco60 quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:19:33 | * | yglukhov quit (Ping timeout: 256 seconds) |
| 22:28:31 | * | find0x90_ joined #nim |
| 22:37:57 | * | find0x90_ quit (Quit: find0x90_) |
| 22:40:54 | FromGitter | <dandevelo> Is it possible to have a set of refs in Nim? I create some objects and need to add them to a set in order to prevent adding them multiple times. |
| 22:41:38 | Araq | give it a hash proc and off you go |
| 22:42:09 | * | miran quit (Quit: Konversation terminated!) |
| 22:42:16 | FromGitter | <dandevelo> @Araq how would I do that? |
| 22:42:16 | Araq | HashSet[ref X] is pretty easy to do |
| 22:42:42 | Araq | proc hash(x: ref X): int {.inline.} = cast[int](x) |
| 22:49:34 | * | yglukhov joined #nim |
| 22:51:29 | FromGitter | <dandevelo> Just tried it. Thanks @Araq ! Worked great! |
| 22:53:51 | * | yglukhov quit (Ping timeout: 246 seconds) |
| 23:01:03 | * | cspar__ joined #nim |
| 23:03:51 | * | cspar_ quit (Ping timeout: 240 seconds) |
| 23:07:32 | * | so joined #nim |
| 23:18:09 | * | aguspiza quit (Ping timeout: 260 seconds) |
| 23:26:32 | * | nsf quit (Quit: WeeChat 2.0.1) |
| 23:27:25 | * | yglukhov joined #nim |
| 23:31:58 | * | yglukhov quit (Ping timeout: 268 seconds) |
| 23:37:22 | * | cspar joined #nim |
| 23:39:27 | * | cspar__ quit (Ping timeout: 240 seconds) |
| 23:52:18 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
