<< 04-05-2019 >>
00:06:16*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:09:26*shashlick joined #nim
00:24:31*Manny8888 quit (Ping timeout: 264 seconds)
00:25:13noonienthe archive at https://nim-lang.org/download/nim-0.19.4.tar.xz has a build.sh file
00:25:53noonienwhere does this file come from? i don't see it in the gitrepo root @ https://github.com/nim-lang/Nim/tree/v0.19.4
00:25:55*jjido joined #nim
00:28:24*rnrwashere joined #nim
00:30:53*Manny8888 joined #nim
00:32:24*stefanos82 quit (Remote host closed the connection)
00:32:42leorizenoonien: it's from nim-lang/csources
00:33:47leorizethe release archive is a hybrid of nim-lang/Nim and nim-lang/csources for bootstraping purposes
00:34:38noonienis there a link for nightlies? or development releases?
00:34:46noonieni found these: https://github.com/nim-lang/nightlies/releases
00:34:57leorizeyep, those are the links
00:35:17nooniengreat, thanks!
00:37:29*cy1 joined #nim
00:48:52*rnrwashere quit (Remote host closed the connection)
00:49:52*rnrwashere joined #nim
00:50:11*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:55:18*ricardo quit (Quit: ricardo)
00:57:04*ricardo joined #nim
00:58:06*ricardo quit (Client Quit)
00:58:11*dddddd quit (Remote host closed the connection)
01:00:27*ricardo joined #nim
01:01:14*Frosted quit (Quit: Page closed)
01:06:35*rnrwashere quit (Remote host closed the connection)
01:08:04*rnrwashere joined #nim
01:23:47shashlickwe need to link nightlies on the download page
01:29:14nooniennightlies on that page don't seem to have the same format as the release archives
01:30:14noonienhmm, actually, nvm, they do, they also contain prebuilt binaries though
01:30:48nooniena pure-source nightly release, like a normal release would be great
01:31:16*smitop quit (Quit: Connection closed for inactivity)
01:34:18*ricardo quit (Quit: ricardo)
01:34:19*rnrwashere quit ()
01:35:19*rnrwashere joined #nim
01:36:17*rnrwashe_ joined #nim
01:38:22shashlickyou can use the binary builds just the same
01:38:33shashlickonly extra files are in bin\* and koch binary
01:38:41*rayman22201 joined #nim
01:38:48shashlickand there's html files generated
01:38:56shashlickbut i think those are in the release as well
01:39:07shashlickif you don't want anything then use the osx binaries which are empty
01:39:32shashlickif you run build.sh and koch, etc. per usual on the binary build, you can still recompile
01:39:48*rnrwashere quit (Ping timeout: 252 seconds)
01:40:52noonieni'm using nix, and the source gets added to my nix store, didn't want to waste space with compiled binaries i don't use
01:41:15noonienyou are correct, the osx release doesn't contain binaries, why is that?
01:47:08*rnrwashe_ quit (Remote host closed the connection)
01:51:24shashlicki haven't gotten around to packaging those yet
01:51:48leorizenoonien: you can just clone the git repos directly, no?
01:52:02leorizeI believe the nightlies are meant for binaries only
01:52:32nooniensure, but then i also need to close c_sources, it's not difficult, but i didn't want to modify the nix recipe as much
01:52:35shashlickwell, the nightlies are what will be posted on releases going forward
01:54:18leorizewell, but going forward it's gonna be more efficient than redownloading the entire source code for that one line change in devel
01:57:00*rnrwashere joined #nim
02:00:17*banc quit (Quit: Bye)
02:03:59*cyberjpn joined #nim
02:05:54*Hexeratops quit (Read error: Connection reset by peer)
02:12:09*Snircle quit (Read error: Connection reset by peer)
02:12:46*Snircle joined #nim
02:24:18*banc joined #nim
02:25:28*shashlick quit (Ping timeout: 245 seconds)
02:32:14*rnrwashere quit (Remote host closed the connection)
02:33:24*shashlick joined #nim
02:41:17*cyberjpn quit (Ping timeout: 245 seconds)
02:49:36*ricardo joined #nim
02:54:00*ricardo quit (Client Quit)
03:40:14*theelous3_ quit (Ping timeout: 250 seconds)
03:46:54cy1So... does anyone use a gui?
03:47:50cy1I tried the gintro one, but all the callbacks are so unsafe it's ridiculous. And nimgui doesn't work.
03:50:49leorizeI've used gintro
03:53:06cy1I was finding gintro colliding badly with asyncdispatch.
03:53:26cy1"Exception message: Async procedure (activate3) yielded `nil`, are you await'ing a `nil` Future?"
03:53:39FromGitter<jrfondren> http://yglukhov.github.io/nimx/livedemo/main.html looks OK, but I haven't needed a UI yet.
03:55:19cy1and no I'm not awaiting a nil Future...
03:55:46FromGitter<jrfondren> on bad days I await a nil Future
03:56:00leorizecy1: you can try reporting the bug to gintro
03:56:07leorizethe maintainer is rather active
03:57:10cy1leorize: I don't know that it's their bug, since it's asyncdispatch that's spazzing out
03:58:43leorizewell, if it's trivial to reproduce, then a report should be made
03:59:05cy1Not sure it's a bug, or just me doing things wrong...
03:59:39leorizewell for a start, you can make a small reproducible sample and post it here :)
03:59:58cy1I have asyncdispatch draining on a gtk timeout, and I call an async method inside a gtk signal handler, passing the result to asyncCheck, and I get the above runtime error. So I don't THINK it should have that error...
04:00:12cy1on the other hand, maybe draining on a gtk timeout is a horrible idea?
04:02:25*rnrwashere joined #nim
04:06:07*rnrwashere quit (Remote host closed the connection)
04:06:47*rnrwashere joined #nim
04:06:59cy1And now there's no error in my small reproducible sample. Sigh...
04:07:24*fredrik92 quit (Read error: Connection reset by peer)
04:07:47*fredrik92 joined #nim
04:10:57*rnrwashere quit (Ping timeout: 246 seconds)
04:11:49*rnrwashere joined #nim
04:29:15FromGitter<jrfondren> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ccd151ab489bb6ed710e644]
04:30:15FromGitter<jrfondren> how do I prevent these N_CDECL things from being emitted? all that's doing is allowing gcc to complain that the pointer type isn't the same as the other definition of initscr
04:31:16FromGitter<jrfondren> from `extern NCURSES_EXPORT(WINDOW *) initscr (void);`. This is a purely dlopen'd library that I'm trying to link, instead.
04:31:30leorizeannotate the wrapper function with `{.header: "<ncurses-header-file-name>".}`
04:31:42leorizeor `{.nodecl.}`
04:38:34*rayman22201 quit (Quit: Connection closed for inactivity)
04:40:18leorizeofc the even better way is to stop using {.header.} and gcc will stop complaining
04:45:10FromGitter<jrfondren> thanks. that left me with the problem of not noticing my own -l:-liconv in the command I was running
04:57:20cy1I wonder how you'd do lazy futures...
04:58:19cy1Like... this COULD be a calculation, but until I force it, it won't start looking. I guess a memoized procedure that returns a future...?
04:58:28cy1I'm probably overthinking it.
05:05:43*rnrwashere quit (Remote host closed the connection)
05:26:16*nsf joined #nim
05:26:18cy1...why doesn't the expression "addr X" have a not nil type? Is it possible to have an object whose address is nil?
05:36:22*vlad1777d quit (Ping timeout: 250 seconds)
05:40:27*solitudesf joined #nim
05:41:07leorizecy1: not nil is not stable and kinda broken
05:41:24leorizeit's now placed back in `{.experimental.}`
05:55:37cy1It does seem like maybe not such a good idea, if obviously provably not nil expressions are not... not nil.
05:56:51cy1leorize: Basically I'm trying to figure how to pass a future by reference to a gtk callback, so that when completed it'll actually resume awaiting stuff.
05:58:03cy1So when I complete the future outside the callback, it works. When I pass its ref to the callback and complete it then, it just sits there.
05:59:20leorizearen't Future themselves `ref`?
05:59:42leorizewhy would you want to pass one by reference?
06:00:07leorizesee https://nim-lang.github.io/Nim/asyncfutures.html
06:00:25cy1If I passed a future by value, there wouldn't be any callbacks on the new value. That's the only reason I can think it wouldn't be working.
06:00:56cy1You're right that futures are already references though...
06:01:26leorizemost likely you were passing in a ptr to the stack, which... yea
06:02:53cy1No, I was passing them by value, leorize. Then I tried passing by ref, because the callbacks weren't being called...
06:03:31cy1And now that I switch back ofc it's going to work perfectly, because I was doing something even stupider before and didn't know it
06:04:11leorizewe've all been there :P
06:05:38cy1I wish I could look at a future's callbacks.
06:05:44cy1Just for debugging
06:09:03*slugm joined #nim
06:15:51cy1gdb is no help at all of course. endb is broken, hm...
06:16:16leorizewhy wouldn't gdb work?
06:16:45*hzx joined #nim
06:17:12leorizeand there's also the nim-gdb gdb plugin that makes nim debugging much easier
06:18:56*xet7 joined #nim
06:21:29*slugm quit (Remote host closed the connection)
06:22:15*slugm joined #nim
06:22:40cy1I didn't know there was a nim-gdb plugin!
06:23:36cy1leorize: gdb wouldn't work if when you "print future" instead it only lets you "print T32_.base.base.base.S032" and stuff like that.
06:31:16*solitudesf- joined #nim
06:32:16*solitudesf quit (Ping timeout: 250 seconds)
06:32:39cy1yeah, the plugin doesn't demystify any of the opaque variables...
06:37:43leorize:p try using the `$` there
06:38:12leorizetypically it will take a bit of digging to get what you want
06:57:17cy1leorize: they're not very forthcoming with their internals... it's pretty much impossible to inspect unexported fields.
06:59:01*solitudesf- quit (Ping timeout: 258 seconds)
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:49*gmpreussner joined #nim
07:07:43cy1anyway, nigui seems to work better than gintro.
07:19:13*druonysus joined #nim
07:19:13*druonysus quit (Changing host)
07:19:13*druonysus joined #nim
07:20:06*jjido joined #nim
07:36:22*rayman22201 joined #nim
07:48:55*cyberjpn joined #nim
07:56:29*salewski joined #nim
07:57:22salewskihttps://irclogs.nim-lang.org/04-05-2019.html#07:07:43
07:57:59salewski>cy1 anyway, nigui seems to work better than gintro.
07:59:15salewskicy1, nigui and other GUI toolkits are fine. What are the most pressing problems with gintro for you?
08:03:32salewskiOK, found it many lines above...
08:04:19salewskiWell, callbacks are not unsafe. Nim compiler checks all parameters well.
08:05:21salewskiBut you are free to improve the callback mechanismn, maybe using a other syntax.
08:06:28salewskiBut we do not want very easy, but powerless callbacks. A plain button-press callback is useless
08:07:09salewskiin real life, we need at least all the callback variants and parameters that C GTK offers.
08:08:22salewskiFor asyncdispatch with gintro -- I have never tested that. I do not assume that it is a real gintro issue,
08:08:29FromGitter<mratsim> @noonien use typedesc instead of type, type was a pretty recent addition that is all kinds of broken :p
08:08:32salewskimaybe a GTK one.
08:09:10FromGitter<mratsim> basically it allows to pass a type as a function parameter
08:09:29FromGitter<mratsim> you can have type constrains like
08:09:56salewskiFor the callback stuff: Maybe a real macro expert can indeed improve that. I was happy to get it working
08:10:01FromGitter<mratsim> proc foo(T: typedesc[int or uint]): T = T(0)
08:10:39salewskiat all in a nearly safe caompile time checked way, but I will of course better solutions.
08:11:55*Vladar joined #nim
08:12:06salewskiquit
08:15:07*salewski quit (Quit: WeeChat 2.3)
08:17:14*vlad1777d joined #nim
08:17:38*salewski joined #nim
08:17:53FromGitter<mratsim> Try Alt+F4 or Ctrl+Q ;)
08:19:02salewskicy1, and when you are one of the macro experts: We have already a collection of examples for gintro
08:19:31*cyberjpn quit (Ping timeout: 258 seconds)
08:19:54salewskiwhich uses some variants of callbacks, including the latest cairo drawing examples, see bottom
08:20:49salewskiof gintro github page. Maybe you can make some suggestions how to rewrite the callback stuff for these working well
08:21:29*stefanos82 joined #nim
08:21:34salewskiexamples. I assume the other devs can make suggestions, but they have have more importants tasks to do.
08:22:15salewskiBye.
08:22:19*salewski quit (Quit: WeeChat 2.3)
08:32:47*nsf quit (Quit: WeeChat 2.4)
08:54:30*zestyr quit (Quit: WeeChat 2.4)
08:57:05*leorize quit (Ping timeout: 256 seconds)
09:05:31*vlad1777d quit (Ping timeout: 258 seconds)
09:32:22*clyybber joined #nim
09:33:50clyybbermratsim Btw I fixed that type vs typedesc issue, https://github.com/nim-lang/Nim/pull/11172
09:39:22*salewski joined #nim
09:40:47salewskiSeems that with latest compiler sizeof(seq[int]) is still only 8 bytes, so
09:41:27salewskiwhen I have an object and add a new field f: seq[int] size of object is only increased
09:42:05salewskiby 8 bytes. That is better as I assumed, as now seqs are value objects.
09:42:48salewskiHow can a seq value object be so small? I assumed at least a few fields in the value
09:43:16salewskiobjects, so maybe a pointer to actual data, and a size field.
09:43:23salewskiOver.
09:44:24*rayman22201 quit (Quit: Connection closed for inactivity)
09:45:27salewskiAnd seq[int] is indeed a value object, as var x: seq[int]; echo x == nil does not compile any more.
09:47:40salewskiWell, I assume it is a value object with only one field, a pointer. And compiler knows when poiter is nil then seq is empty.
09:47:44salewskiFine.
09:47:51salewskiBye.
09:50:07*slugm quit (Remote host closed the connection)
09:50:29*slugm joined #nim
09:50:47*salewski quit (Quit: WeeChat 2.3)
10:05:12*ackersond joined #nim
10:11:06*rokups joined #nim
10:11:42FromGitter<jrfondren> found a benchmark where nim#head is 26x faster than 0.19.4
10:13:15*neceve joined #nim
10:13:40FromGitter<jrfondren> not sure why. the only thing distinctive about the test is https://gist.github.com/jrfondren/06f47d9905a71018b1ef5f0f9897f3bb . is there something wrong with that getline() implementation?
10:16:09*ackersond quit (Quit: Page closed)
10:20:30*slugm quit (Read error: Connection reset by peer)
10:20:36*slugm_ joined #nim
10:23:11*zestyr joined #nim
10:27:53*neceve quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
10:28:16*neceve joined #nim
10:37:09clyybberjrfonden: Thats f'ing cool. Can't see anything wrong with the implementation.
10:37:25clyybberWhat happens when you {.inline.} the iterator?
10:38:20*hzx quit (Quit: Going offline, see ya! (www.adiirc.com))
10:39:33FromGitter<jrfondren> no real change to devel performance
10:40:06clyybberAnd to 19.4?
10:40:40FromGitter<jrfondren> / - \ | /
10:42:03FromGitter<jrfondren> no real change to 19.4 performance
10:46:50clyybberinteresting.
10:48:39*rayman22201 joined #nim
10:49:11Zevvwhat is your full test? I can not see any big difference in performance?
10:51:25*kapil____ joined #nim
10:52:24*dddddd joined #nim
10:57:31FromGitter<jrfondren> https://github.com/jrfondren/topsender-bench/blob/master/topsender_npeg_getline.nim is the full test
10:58:48FromGitter<jrfondren> ah, oh wait.
10:59:06FromGitter<jrfondren> I forgot that CountTable.sort was so slow in 0.19.4
10:59:25Zevv:)
11:00:24ZevvI had a funny incident while doing your npeg test last week: I was looking for a generic exim log so I googled for 'exim_mainlog', and found a server somewhere that had its full root open through http. Happened to be from a server hosting a few thousand sites for a few thousand users. It took me sevent attempts to get past first line support of that company before I found anyone *willing* to hear me out to
11:00:30Zevvreport a security issue. They had their FTP (FTP!) passwords in plain text for all users, etc
11:00:44FromGitter<jrfondren> yeah with that switched to altsort, there's no difference in speed anymore.
11:00:49Zevvok, great
11:01:02ZevvIs your own iterator so much faster then then stdlib lines?
11:01:46FromGitter<jrfondren> it's not faster enough to bother with, which makes me thing there's some trick I'm missing with string copying still.
11:02:06ZevvI believe cstring->string is pretty expensive.
11:02:37ZevvI did some tests with npeg the other day to have it work on cstring instead of string internally. The matching was faster, but the capture collection slowed it down more then it won
11:02:40FromGitter<jrfondren> well I could leave it as cstring until the final reporting step, but I probably still have to copy it
11:03:10FromGitter<jrfondren> that server you found is one of mine btw :/
11:03:16Zevvbluehosting?!
11:03:25Zevvor what was it called
11:03:26Zevvsomething blue
11:03:30FromGitter<jrfondren> Bluehost, aye.
11:03:35Zevvyeah, how is that yours?
11:05:11FromGitter<jrfondren> I work for them. I got pulled into the security event that eventually got raised over your contacts
11:05:21FromGitter<jrfondren> I'm the one that deleted the symlink.
11:05:25ZevvWell, Say Hi to Rafeel from me
11:05:32Zevvdang, it's a small small world!
11:05:34Zevvhttp://zevv.nl/div/4.png
11:05:38FromGitter<jrfondren> the one you were supposed to call eh?
11:05:47*ng0 joined #nim
11:06:00FromGitter<jrfondren> aye I saw a screencap of the other side of that, including the last bit :)
11:06:09ZevvI was so frigging annoyed. I'm here trying to do the right thing, and people just refuse to listen to me because I can not tell them my password.
11:06:14Zevvwow, this is so funny
11:06:37ZevvThis can only mean one thing: you are the only remaining exim user on the whole internet
11:07:08FromGitter<jrfondren> I authored a kernel patch that breaks name resolution when it goes through a user-owned symlink and ends up at anything but that user's own files, but mostly we're not using the kernel version I wrote that patch for, so we've got something else that isn't as good.
11:07:11ZevvYour not rafael yourself, right :)
11:07:34FromGitter<jrfondren> nah not him.
11:08:01Zevvhehe. I just run a cron job detecting links pointing outside docroots. It's nasty but it works
11:10:44Zevvanyway, tell your boss to send me an apple pie for reporting that :)
11:10:54ZevvI'm looking into speeding up your readlines
11:11:42*slugm joined #nim
11:11:46*slugm_ quit (Ping timeout: 246 seconds)
11:13:34FromGitter<jrfondren> cool. I reckon that's the gap between Nim and the D options that are using pcre and getline.
11:13:49Zevvnah pcre is just plain faster
11:17:10FromGitter<jrfondren> with nim#head, topsender_npeg_getline.nim consistently beats topsender.nim though
11:17:31FromGitter<jrfondren> not by much
11:20:56FromGitter<jrfondren> and getline+pcre should still be marginally faster. I'm just saying, from here, if I wanted speed, switching to pcre is the smaller win.
11:23:01*Perkol joined #nim
11:30:53*nsf joined #nim
11:33:24*Perkol quit (Remote host closed the connection)
11:33:38ZevvDoing a getlines1()/discard loop shows over 50% of the time is spent in cstrToNimStr
11:34:20ZevvSo the obvious solution would be to have a C stdlib function read straight into a nim string buffer instead
11:35:19Zevvproblem is that getline() will try to realloc your buffer, so if you pass it addr buf[0] it will mess up things
11:35:35Zevvand fgets() will read happily, but does not report line lenght, and you don't want to do a strlen() of course
11:38:02clyybbercstrToNimStr is O(n) right?
11:40:04*slugm quit (Remote host closed the connection)
11:40:29*slugm joined #nim
11:40:33FromGitter<jrfondren> it does a copyMem yeah
11:47:42*lritter joined #nim
11:49:55clyybberbut it has to traverse the cstring until it finds a \0 right?
11:50:26clyybberbecause Nim strings have a length field
11:50:55FromGitter<jrfondren> it also does that, yes.
11:53:32FromGitter<jrfondren> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ccd7d3a5b3f941aa5ddb7bb]
11:54:06FromGitter<jrfondren> even if I could skip the len() needed to populate the length, I'd have to copyMem the string into data.
11:54:06*Perkol joined #nim
11:55:01*NimBot joined #nim
11:55:32FromGitter<jrfondren> it'd be a different story entirely if those cap: and region: fields were in NimStringV2, and p: was a ptr cstring
11:59:08*leorize joined #nim
11:59:36FromGitter<jrfondren> anyway, I bet there'd be a bigger win in using pairs of indices instead of strings, in npeg and in captures, and then only copying strings for the CountTable.
12:08:12*leorize quit (Remote host closed the connection)
12:08:38*leorize joined #nim
12:11:23*neceve quit (Read error: Connection reset by peer)
12:14:24*Gertm joined #nim
12:14:29*Gertm left #nim ("Be back later...")
12:24:31*jjido quit (Quit: Textual IRC Client: www.textualapp.com)
12:25:48Zevvyou can do a setLen on the cstring
12:25:50Zevvto truncate
12:31:21dom96AFAIK that only works on string
12:32:10Zevvyeah, but if we would have the C stdlib read the data straight into the string buffer
12:32:14Zevvand then adjust the lenght with setLen
12:32:56ZevvI haven't looked into the string implementation though, but I guess it is not likely the actual buffer is ever shrinked with a setLen?
12:33:52FromGitter<jrfondren> on a shrink the buffer size remains. the code's in lib/core/strs.nim
12:34:32*bars0 quit (Quit: leaving)
12:34:48*bars0 joined #nim
12:35:14Zevvthat makes sense, so you should be free to read data straight into the string buffer to save the mem copy
12:35:48FromGitter<jrfondren> ah I see.
12:35:51Zevvstill the problem that getline() is eager to realloc your buffer
12:35:57Zevvand fgets() does not tell you the length
12:36:04ZevvC stdlib is so sucky
12:36:37Zevvone step back: why do you even need to read *lines* though?
12:37:01*bars0 quit (Client Quit)
12:37:18*bars0 joined #nim
12:37:34FromGitter<jrfondren> libc has fgetln() now. That should be the one to use.
12:38:16Zevvpff never saw that one. And I consider myself a C programmer :/
12:38:21FromGitter<jrfondren> I don't need to read lines, but I do need to not read the entire file into memory.
12:38:36Zevvyou can mmap
12:38:58FromGitter<jrfondren> I feel like that would tend to read the entire file into memory.
12:39:02Zevvnope
12:40:33ZevvBut for large files you might need a 64 bit machine to be able to have enough virtual address space to be able to map the whole thing
12:40:50*rokups quit (Quit: Connection closed for inactivity)
12:40:58Zevvbut then again, it's stil not a Nim string, it's raw memory
12:41:01Zevvso that might also be cumbersome
12:41:11ZevvI think fgetnl() is the right way to go
12:41:29*bars0 quit (Client Quit)
12:41:48*bars0 joined #nim
12:41:52Zevvnaah, also not: it gives you the pointer, but you can't say "put it here please"
12:43:19Zevvso, now you need to replace the data pointer in a Nim string :)
12:44:03FromGitter<jrfondren> that requires a memCopy anyway
12:46:22leorize[m]isn't fgetln a BSD-extension?
12:47:00Zevvwell, no, the string itself is a thingy with a length and a pointer to the data. If you could replace the data pointer and point it to the result of fgetln()
12:47:46leorizewouldn't that be unsafe? unless you could generate a "immutable" string which you can't
12:47:47FromGitter<jrfondren> the ptr is shown above though. It has extra data, so I'd have to move the string contents anyway
12:48:12FromGitter<jrfondren> you can't turn a cstring into a Nim string with a few assignments. a memCopy is required
12:48:22*rockcavera quit (Ping timeout: 245 seconds)
12:49:05Zevvof coure it is unsafe, but can't we have some fun here?
12:49:25FromGitter<jrfondren> creating a large Nim string and then reading into it's a good bet, but the C API sucks.
12:49:39Zevvindeed
12:50:08FromGitter<jrfondren> yeah fgetln's on macOS but not on Linux
12:50:14*hzx joined #nim
12:50:33FromGitter<jrfondren> that's too bad. it was basically the getline() iterator in libc.
12:50:50*slugm_ joined #nim
12:51:04leorizewell `libbsd` has a linux implementation of that interface :p
12:51:12leorizemaybe someone could dig it and replicate it in Nim
12:52:11*slugm quit (Ping timeout: 248 seconds)
12:53:57*Perkol quit (Quit: Leaving)
12:57:24*rayman22201 quit (Quit: Connection closed for inactivity)
13:01:02*rnrwashere joined #nim
13:05:31*rnrwashere quit (Ping timeout: 248 seconds)
13:24:22*vlad1777d joined #nim
13:38:40Zevvfgetln is in linux, in libbsd
13:39:31Zevvbut you can't use that; it just gives you the pointer in the FILE * buf
13:45:49*theelous3_ joined #nim
14:17:00*deech joined #nim
14:24:07*slugm_ quit (Remote host closed the connection)
14:24:29*slugm_ joined #nim
14:27:07*vlad1777d quit (Ping timeout: 248 seconds)
14:27:08*vlad1777d_ joined #nim
14:46:43*FromGitter quit (Ping timeout: 264 seconds)
14:47:03*FromGitter joined #nim
14:50:20*solitudesf- joined #nim
14:59:45*slugm joined #nim
15:00:05*slugm_ quit (Read error: Connection reset by peer)
15:05:31*vlad1777d_ quit (Ping timeout: 248 seconds)
15:10:17FromGitter<liquid600pgm> is it possible to make macros whose arguments are not explicitly NimNodes?
15:10:44leorizein the end they'll still be nimnodes :p
15:10:49ZevvYou can, but then they're implicity nimnodes
15:11:01FromGitter<liquid600pgm> I know, that's what I'm trying to deal with
15:11:01leorizeyou can pass `static[T]` into macros, but that's rather buggy
15:12:05FromGitter<liquid600pgm> I wanted to create an aux template inside of a macro, which does some stuff for the macro, but seems impossible
15:12:29FromGitter<liquid600pgm> basically I need the macro to get some info for the template and then use the template
15:13:07leorizeit should be possible, no?
15:13:17leorizecan you make a sample of what you're trying to do?
15:13:26Zevvyeah, sounds like the normal thing to do
15:13:28FromGitter<liquid600pgm> sure, give me a second
15:15:40FromGitter<liquid600pgm> https://termbin.com/1iik
15:16:31leorizeuse `macros.quote`
15:16:31FromGitter<liquid600pgm> it seems the argument `win` is a NimNode, but in the template I need an `RWindow`
15:16:42leorizeit should be able to do exactly what you want
15:17:49FromGitter<liquid600pgm> thank you, this is exactly what I need
15:18:01Zevvand I learned something new as well, thanks for that
15:24:53FromGitter<liquid600pgm> quote did the job perfectly
15:34:41*rnrwashere joined #nim
15:36:38*slugm quit (Remote host closed the connection)
15:55:59*rnrwashere quit (Remote host closed the connection)
15:56:42*rnrwashere joined #nim
15:57:38*rnrwashere quit (Remote host closed the connection)
15:57:53*rnrwashere joined #nim
15:59:05*nsf quit (Quit: WeeChat 2.4)
16:05:16FromGitter<liquid600pgm> is it possible to enforce the lifetime of a variable?
16:08:08FromGitter<liquid600pgm> by that I mean, I want to limit the variable's lifetime to a single block. in the block, user-specified actions are done, and I want to prevent this variable from being carried outside of this scope
16:16:15*abm joined #nim
16:22:15*Tyresc joined #nim
16:22:53leorizeliquid600pgm: there aren't anyway
16:22:53*salewski joined #nim
16:23:01leorizeyou just have to trust your users :P
16:23:10FromGitter<liquid600pgm> too bad, I'll warn them in my docs
16:23:39leorizeyea, because preventing copies are hard
16:23:47leorizeunless I misinterpret what you say :p
16:24:01FromGitter<liquid600pgm> not exactly
16:24:42FromGitter<liquid600pgm> I have a graphics context which I want to be available for only when the frame's rendered
16:24:43leorizethere's a "way" for this but might be damaging
16:25:18leorizeproc `=`(dest: var ObjA; src: ObjB) {.error.}
16:25:25leorize^ that will prevents all copies
16:25:29leorize```proc `=`(dest: var ObjA; src: ObjB) {.error.}```
16:25:38FromGitter<liquid600pgm> no, it's not really what I want
16:25:54FromGitter<liquid600pgm> I don't want to prevent *all* copies, only copying to an outer scope
16:26:23FromGitter<liquid600pgm> I'll just warn my users saying that copying the graphics context and using it from an outside scope is undefined behavior
16:27:16leorizeif you define that proc inside the block then it'll block every single copies of that variable
16:27:25Zevv~
16:27:42leorizewell documenting is still the better way :p
16:28:25salewskiliquid600pgm, for the newruntime we may have something like that. Because copying outside of scope for a not owned ref is illegal then.
16:28:42Zevvis that enforced by the compiler?
16:28:45FromGitter<liquid600pgm> I'm not using the new runtime yet
16:29:09salewskiNo one is, but we may get it.
16:29:10leorizeZevv: yes, after a few bugs report it should be working fine-ish now :p
16:29:13*abm quit (Ping timeout: 246 seconds)
16:29:19Zevvthat is pretty cool
16:29:55salewskiYes, I hope it will really work. Will be great.
16:32:36ZevvSo, is it time for normal users to start looking into using the new runtime yet?
16:33:48salewskiThere are fast progress for newruntime indeed. Two weeks ago many of my small tests gave segfault, but no the compile and work.
16:33:58salewskiBut I did only some minimal tests.
16:36:13*solitudesf- quit (Ping timeout: 246 seconds)
16:36:31*salewski quit (Quit: WeeChat 2.3)
16:42:25Zevvleorize: the new indent is bugging me
16:42:55Zevvalthough the behaviour does seem right, now that I think of it.
16:43:38leorizeoh, how's that? can you give me a sample file?
16:43:53leorizejust a few lines around the buggy area
16:43:56ZevvI'm making one of these nifty recordings you always do
16:44:01leorizesure :)
16:44:07Zevvbut I need to create an account somewhere
16:44:13Zevvso nevermind that
16:44:23leorizeyou don't have to actually :p
16:44:46Zevvoh, yeah, I see, sorry
16:44:47Zevvhttps://asciinema.org/a/WoQtOYv0sFTwb2uI7ekBI38WJ
16:45:11FromGitter<liquid600pgm> is there a way to add a stack trace entry?
16:45:38Araqleorize, the "borrow check" that I implemented is wrong but useful and easy to work around
16:45:39leorizeZevv: that's a bug
16:45:43Zevv\o/
16:45:54leorizecan you try to update to the latest one?
16:45:59Araqleorize, I would appreciate your opinion
16:46:05leorizeZevv: I've already fixed it sometime ago :p
16:46:22leorizeAraq: sorry, haven't got much time to play w it yet :P
16:46:32ZevvHm I guess I might have updated my other machines, but not this one, I just realiazed. let me check
16:47:20Zevvleorize: sorry for the noise, indeed fixed, I had an old version here
16:53:56*golechwi joined #nim
16:56:53golechwihello, i'm planning to develop some mapreduce clone in nim for educational purposes. does nim's standard library provides some rpc support?
16:57:51*rockcavera joined #nim
16:57:55leorizeother than an unified interface to spawn processes, no :p
16:58:04ZevvChannels?
17:00:23shashlick@Araq: pinging about https://github.com/nim-lang/Nim/pull/11148
17:01:43golechwiaren't channels about communication between threads? i would like to achieve inter-process communication
17:02:14leorizeno standard interface atm
17:02:16ZevvSockets
17:02:18Zevvis standard
17:02:26leorizeother than pipes :p
17:02:36leorizeand yea, sockets
17:02:41golechwiwell pipes obviously :p
17:02:57ZevvBut you'd have to make the RPC part on top of that yourself
17:03:14Zevvbut that's pretty trivial, you could just serialize json, for example
17:03:39golechwiyeah, i'd rather do it mostly right the first time
17:03:53*deech quit (Remote host closed the connection)
17:03:58ZevvI never got anything right the first time :(
17:04:08golechwithat's why i said "mostly" :p
17:04:19Zevvhehe
17:04:21leorizethere's no "right" way in Nim atm :p
17:04:40golechwialso i would want some "at most" once behavior
17:04:55golechwiso where do i start?
17:05:02golechwijust try to build some library on top of sockets?
17:05:14golechwior you guys have other suggestions?
17:05:23ZevvI'd start with a "nimble search rpc"
17:05:47shashlickUse nng
17:06:02shashlickI have a working wrapper I use in my text editor
17:06:19Zevvthat's cheating
17:06:56shashlickhttps://github.com/genotrance/feud/blob/master/wrappers/nng.nim
17:08:00shashlickI prefer lazy :)
17:08:07golechwiomg, this is super cool
17:08:50shashlickI use nng in my remote plugin https://github.com/genotrance/feud/blob/master/plugins/remote.nim
17:09:11golechwii will definitely try this out
17:10:00shashlickPick the right protocol for your use case
17:10:08golechwianyway, do you guys have plans to add some rpc support to standard library?
17:10:15shashlickI've not enabled ssl though so that might need some extra work
17:10:18*kapil____ quit (Quit: Connection closed for inactivity)
17:11:53*nsf joined #nim
17:16:13*jjido joined #nim
17:19:31dom96golechwi, you can use this: https://github.com/dom96/nim-jsonrpc
17:19:37dom96(or one of the many others RPC packages)
17:21:23dom96I would suggest something written in Nim though
17:22:05*tefter joined #nim
17:24:18shashlick@dom96 - i added the newline in that eraseLine PR
17:30:40*Vladar quit (Remote host closed the connection)
17:34:35FromDiscord_<Zireael> I need to http serve a directory, I noticed httpserve package docs have a depreciation note now? what should I use?
17:35:51dom96You mean httpserver module?
17:36:02dom96Use asynchttpserver or httpbeast or a web framework like Jester
17:38:29*solitudesf joined #nim
17:38:45FromDiscord_<Zireael> thanks, will take a look at httpbeast (I have a web site already and literally all I need is a one-liner similar to python3 -m http.serve 😉
17:46:51*solitudesf quit (Ping timeout: 258 seconds)
17:47:50*hzx quit (Quit: Going offline, see ya! (www.adiirc.com))
17:48:48*rnrwashere quit (Remote host closed the connection)
17:58:31FromGitter<liquid600pgm> shashlick: is there any way of cross-compiling nimterop wrappers to windows?
17:59:49FromGitter<liquid600pgm> `-d:mingw` on devel gives me this error: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ccdd315b489bb6ed7160ddb]
18:02:02FromGitter<liquid600pgm> I might make a simple cmd replacement just for that, but it's more of a workaround than a real fix
18:04:05shashlickya its too dumb right now since I'm checking for when defined(windows)
18:04:18shashlickAraq had told me a way to check active OS, let me check
18:04:40FromGitter<liquid600pgm> this could maybe be fixed by checking `defined(mingw)`?
18:04:57*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:05:13shashlickwell, that's still a hack - i need to know what os i'm running on, otherwise any other cross compile will fail
18:05:20shashlick-d:mingw sets os to windows
18:05:32FromGitter<liquid600pgm> I know, that's what causes the error
18:06:50*vlad1777d_ joined #nim
18:07:06shashlickAra-q suggested hostOS - let me see
18:09:13FromGitter<liquid600pgm> I submitted a ticket for this: https://github.com/nimterop/nimterop/issues/126
18:18:35*nsf quit (Quit: WeeChat 2.4)
18:22:39shashlickPutting in a fix on a branch - will you be able to test it?
18:23:42FromGitter<liquid600pgm> I'll try and ask for advice if I can't figure something out
18:27:47FromGitter<liquid600pgm> which branch is the one with the fix?
18:28:01*rockcavera quit (Remote host closed the connection)
18:29:06clyybberAraq I fixed the typedesc bind once issue: https://github.com/nim-lang/Nim/pull/11172
18:29:44clyybberBut I'm not sure why we have to check for the indent
18:30:11clyybberwouldn't it also work to just remove that check?
18:30:54FromGitter<liquid600pgm> shashlick: are you sure you pushed the branch to GitHub?
18:31:01*jjido joined #nim
18:31:43*jjido quit (Client Quit)
18:32:48*solitudesf joined #nim
18:34:13shashlickno not yet, still working on it
18:34:55FromGitter<liquid600pgm> sure, notify me when you're done and I'll test
18:35:57shashlickokay just pushed
18:36:19shashlickhttps://github.com/nimterop/nimterop/tree/mingw
18:42:36FromGitter<liquid600pgm> strange, the same error occurs
18:42:43FromGitter<liquid600pgm> I'm not sure if I'm testing it right though
18:43:19FromGitter<liquid600pgm> I copied the source from the mingw branch into ~/.nimble/pkgs/nimterop-0.1.0/nimterop
18:43:50FromGitter<liquid600pgm> is there a better way? I don't feel comfortable copying source code into a nimble package like that
18:44:42FromGitter<liquid600pgm> it should work though, I even cleared the nimcache
18:45:42FromGitter<liquid600pgm> so hostOS isn't the correct approach, under mingw it returns windows
18:46:22shashlickclone it this way - git clone --single-branch --branch mingw https://github.com/nimterop/nimterop
18:46:28shashlickthen nimble uninstall nimterop
18:46:38shashlickthen nimble install -y in that directory where you cloned
18:47:00FromGitter<liquid600pgm> feels much more appropriate, thanks
18:47:12FromGitter<liquid600pgm> but yeah hostOS doesn't work properly.
18:47:15shashlickwith -d:mingw hostOS = windows?
18:47:19FromGitter<liquid600pgm> yes
18:47:41shashlickok then Araq needs to be notified cause changing os in nim.cfg for mingw shouldn't mean we cannot know what OS we are on anymore
19:17:13Araqshashlick, why?
19:17:24Araqmingw still means we have a mingw compiler
19:17:36Araqand so the switches to it apply, the hostOS doesn't matter
19:19:29FromGitter<liquid600pgm> is there a way to specify a different mingw executable? on openSUSE my MinGW GCC is called `mingw32-gcc`, and not `x86_64-w32-mingw32-gcc` (or something like that)
19:21:31FromGitter<liquid600pgm> shashlick: maybe `defined(windows) and not defined(mingw)`?
19:24:50*jjido joined #nim
19:27:04shashlickthe target OS is windows, why does hostOS also get changed if os is set in nim.cfg
19:27:21shashlickhow do I know what system compilation is happening on?
19:27:39AraqhostOS
19:27:48shashlickhostOS is also changing if -d:mingw is set
19:27:55Araqer
19:27:57Araqsorry
19:28:00AraqbuildOS
19:28:37shashlickbut buildOS is not there in nim proper, only nimscript
19:29:10Araqyup
19:29:28shashlickso how do i run OS specific stuff at compile time, like nimterop does
19:30:03Araqconst buildOS* {.magic: "BuildOS".}: string = ""
19:30:20Araqwell you need to add this declaration to your code first and then it might work
19:30:38*Jesin quit (Quit: Leaving)
19:30:42Araqand if so we can think about moving this to system.nim or something
19:32:05shashlickit works
19:32:11*abm joined #nim
19:32:23shashlickwell, but i think we need to test that with -d:mingw
19:32:32*Jesin joined #nim
19:36:47shashlick@liquid600pgm - i updated that branch, can you try again?
19:47:26*abm quit (Ping timeout: 250 seconds)
20:00:23FromGitter<liquid600pgm> now it fails here: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ccdef5797dcb371d863562b]
20:08:15*solitudesf quit (Remote host closed the connection)
20:08:40*solitudesf joined #nim
20:10:04shashlickneed to run, will check later
20:19:04*abm joined #nim
20:22:52cy1huh, so nit is an interesting language. The compiler is a hack, but the language has some stuff that might be nice to see in nim.
20:24:22cy1like "adaptive typing" where a variable can change its static type when reassigned, except when in a loop whose check requires it stays an integer or whatever, so checking anything in a loop binds it to that type.
20:25:19cy1also "intrude import." <_< (for debugging of course)
20:29:21clyybbercy1 "adaptive typing" makes the most sense when your IR is a CFG, but with a scope based AST it's much more nitty gritty
20:29:24cy1Automatic construction, where you can mark fields that aren't required to be specified in the constructor.
20:29:26cy1Or you can mark procedures that take some of the arguments in the constructor that aren't even the object's fields.
20:30:00clyybbercy1 Automatic construction: Does that mean default values?
20:30:44*solitudesf quit (Remote host closed the connection)
20:30:57cy1No, like how in nim you say Type(field: 1, field2: 2, field3: 3) and you don't have to write a "__init__(self, field, field2, field3): self.field = field, self.field2 = field2 etc" like in python
20:31:11*solitudesf joined #nim
20:31:44cy1Nit adds something to that where you can have an object with fields "a,b,c" but the constructor is just T(a: a, b: b) and c gets calculated from the other two in an initializer.
20:32:24cy1clyybber: what's a CFG?
20:32:32clyybberControl flow graph
20:33:31cy1That's a... graphical representation of a program using bubbles and arrows? Not sure how you'd "parse" that at all.
20:35:17cy1I think the rebinding thing is mostly paranoia. I can do let a = 42 ... let a1 = "42" ... let a3 = Thing(field: 42) and it's the same as "a = 42 ... a = "42" ... a = Thing(field: 42)" the compiler could just generate a2 and a3 instead of raising an error. But uh...
20:35:38cy1That leads to confusion when you think a variable is bound to the wrong type.
20:35:40clyybbercy1 Check out https://github.com/nim-lang/Nim/blob/devel/compiler/dfa.nim to see what I mean.
20:36:16clyybberits handy sometimes to represent the code of a program as a CFG
20:36:32cy1I kind of like how in nim a symbolic identifier like "foo" is always bound to a specific type, or a specific value in the case of "let."
20:36:32clyybberbecause you can then check more easily for stuff like: is this variable initialized
20:36:46cy1But it's neat to consider if that could change to be more specialized.
20:37:18clyybberYeah
20:37:51cy1Oh, so analyzing the AST as if you were going to draw a CFG, then drawing inferences from that analysis?
20:38:03clyybberSo those automatic constructors, in Nim you can have default values for proc arguments, that can depend on other arguments.
20:38:15cy1you can?
20:39:11cy1wow, I guess I just didn't know about that. I thought default values had to be just compile time constants
20:39:12clyybberYeah, for example: func sort*[T](input: var seq[T], start: int = 0, fin: int = input.len - 1) =
20:42:41Araqcy1, I fail to see the advantage in allowing a let/var have more than one type
20:43:28AraqI don't fear that it is confusing, but I don't see the point
20:45:11clyybberAraq: What style is preferred in the compiler?: `if t == "typedesc" or t == "type": ...` or `if t in {"typedesc", "type"}: ...`
20:45:17cy1It's not a huge advantage. I just liked how they figured how to rebind it in a way that wouldn't mess with loop variables.
20:45:44Araqthey "figured out" SSA?
20:45:50cy1like while t > 0 do now t has to be an integer end now t can be a string
20:46:02cy1Yeah, they figured out how to do it.
20:46:39AraqSSA is super old stuff :P
20:46:59*rockcavera joined #nim
20:47:30Araqclyybber, t.kind == tyTypeDesc
20:47:39cy1I'm not sure it's SSA...
20:48:03cy1It's limiting the type of a variable based on the context it's used in, while still allowing it to change somewhat
20:48:17clyybberAraq: It looks like in https://github.com/nim-lang/Nim/pull/11172 that Ident check hack is required though.
20:49:28cy1What I really like is intrude import. Just because it automates the process of me going in and adding a bunch of asterisks to someone else's code, so I can debug whether the data I set internally is still valid.
20:49:49Araqjust use a debugger
20:49:57cy1what debugger? :p
20:50:01Araqlikewise, use an IDE and auto-complete
20:50:45cy1I used gdb, and it said all the local variables were named T41_ T37_ T22_ and were all nested structures of raw pointers.
20:51:18cy1so... checking to see if the future still had my callbacks in it was not possible
20:51:53clyybbercy1 You have to use nim-gdb
20:51:59cy1clyybber: I did use nim-gdb
20:52:18Araqso ... instead of fixing the debugger you dream up of language features to compensate for shitty tooling?
20:52:21cy1I'm pretty sure at least. But it still wouldn't let me see the variables.
20:52:39cy1Araq: language features that make writing a debugger easier are good IMO.
20:52:53Araqbut yeah, fair point, the async transformation is HARD to teach GDB
20:53:30Araqclyybber, the check paramTypId.id == getIdent(c.cache, "typedesc").id is preferable to your solution IMO
20:53:45Araqand no, I don't know why this doesn't check tyTypedesc
20:54:10cy1It was in a gtk callback, not anything marked {.async.} I think. I just switched from gintro to nigui and everything just worked, so I'm happy.
20:54:16*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:54:44cy1I mean it's not a problem anymore.
20:54:52cy1At least not currently
20:55:09Araqwell async and closures are both affected
20:55:42Araqwith the new runtime I'm thinking about giving "fibers" another try
20:56:12Araqdebuggers tend to understand these better and I like to have a real stack
20:57:46cy1I think async rewriting makes more sense than allocating a stack per function call. But yeah fibers are... nice I guess. I never can figure out how big to make their stack.
20:59:41Araqit doesn't matter on 64 bits, you can have a 100 MB stack and all you lose is virtual address space
21:00:36clyybberAraq: Whats the actual difference between those ways to check? I don't know the cache mechanism well enough to tell.
21:01:17clyybberAraq: yay fibers \o/
21:01:49clyybbertheres a pkg that provided goroutines in nim afaicr
21:04:20Araqclyybber, the cache mechanism in this case cares for silly ways to write typedesc like tyPeDESC
21:04:25cy1goroutines kind of seem like CPS to me, where you don't return anything from a goroutine, but pass it to the next goroutine. I'm not too familiar with Go though.
21:04:50cy1t_y_p_e_d_e_s_c
21:04:54Araqyeah, we need to think about return values
21:05:09AraqFuture[T] is much better than not being able to return anything
21:05:23cy1I agree futures are awesome.
21:08:55clyybberAraq: Got it, reverted that incorrect part of the fix
21:09:07cy1huh, httpclient can't stream the post body, it's got to be a string looks like.
21:10:53clyybberCool, travis has some sweet caching
21:11:54clyybberit remembers if commits were green or not even after force pushing, possibly going back in git history
21:15:44*stefanos82 quit (Remote host closed the connection)
21:16:23shashlickAraq should I move buildOS from nimscript to system? Should still work in both places right?
21:16:23*rockcavera quit (Remote host closed the connection)
21:18:29cy1Is there a way to slice to "end of sequence" like sequence[3..?] or something? Or do you always have to specify sequence.len like sequence[3..<sequence.len]
21:19:03FromGitter<liquid600pgm> yes, iirc it's ..^
21:19:21FromGitter<liquid600pgm> you can also index backwars using the ^ operator, like ^3
21:19:32Araqshashlick, ok
21:20:36cy1thanks liquit600pgm
21:20:41cy1...
21:20:47cy1thanks liquid600pgm
21:21:14*abm quit (Remote host closed the connection)
21:21:38*abm joined #nim
21:22:40*solitudesf quit (Ping timeout: 258 seconds)
21:24:10*jjido joined #nim
21:26:17*bars0 quit (Quit: leaving)
21:35:51cy1so... if you have a seq[T], and a procedure that takes varargs[T], you can... do... nothing, right?
21:36:21FromGitter<liquid600pgm> you can pass the seq[T] to that procedure
21:36:46cy1really? I must be doing something wrong here, hmm...
21:40:22*arecaceae quit (Remote host closed the connection)
21:40:41*arecaceae joined #nim
21:42:03*rockcavera joined #nim
21:43:53cy1Oh, right I'm thinking passing foo(a, b[0..^1]) will prepend a onto b, sorry dumb mistake.
21:47:15*slugm joined #nim
21:58:01*rockcavera quit (Remote host closed the connection)
21:58:45*rnrwashere joined #nim
22:02:46clyybbergood night
22:02:48*clyybber quit (Quit: WeeChat 2.4)
22:02:56FromGitter<liquid600pgm> goodnight
22:08:57Araqsame here, good night
22:09:17*rnrwashere quit (Remote host closed the connection)
22:09:38*rnrwashere joined #nim
22:16:24*rnrwashere quit (Remote host closed the connection)
22:16:58*rnrwashere joined #nim
22:17:43*luis__ joined #nim
22:20:16*slugm quit (Remote host closed the connection)
22:25:20*Jesin quit (Quit: Leaving)
22:27:14*Jesin joined #nim
22:39:18*deech joined #nim
22:49:02*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:08:19*lritter quit (Quit: Leaving)
23:09:48cy1I wonder if you could have an async iterator... like a future that returned a future, that etc
23:28:49dom96Don't think so
23:29:09dom96Async procs are actually an iterator under the hood already
23:31:37*rnrwashere quit (Remote host closed the connection)
23:32:12FromGitter<kayabaNerve> Why?
23:32:41FromGitter<kayabaNerve> I'm sure there's a good reason, just can't think of one of the top of my head
23:35:01dom96because that's how they're implemented, as resumable iterators where 'await' is transformed to a 'yield'
23:35:13FromDiscord_<פ ח ו ף> how do i concentrate two arrays?
23:36:19FromGitter<jrfondren> a&b, or a.add b
23:37:24FromDiscord_<פ ח ו ף> i mean like [1, 2] + [3, 4] = [1, 2, 3, 4]
23:37:33FromGitter<jrfondren> so actual arrays and not seqs.
23:37:47FromGitter<jrfondren> you could convert them to seqs, @a & @b
23:38:09FromDiscord_<פ ח ו ף> should i be using seqs all the time?
23:39:38FromGitter<jrfondren> I'd default to seqs and only use arrays for a good reason, like the same cases where I might define a tuple with lettered fields, like vec3 in a raytracer.
23:40:33FromDiscord_<פ ח ו ף> got it
23:43:49*ricardo_ joined #nim
23:46:22FromGitter<jrfondren> for arrays you could do something like this though: https://gist.github.com/jrfondren/646b8ad330d62dacb169d189e0e1f85e
23:48:34FromDiscord_<פ ח ו ף> im a beginner to nim and i like just writing code and it working without me messing up some thing syntatically or whatever
23:49:03FromGitter<jrfondren> then go with seqs. they're just convenience-enhanced arrays that can change their size and know which allocator to use.
23:55:53*luis__ quit (Ping timeout: 245 seconds)
23:57:00FromGitter<JasperJenkins> auto return type is useful for this, you can keep the `&` syntax, http://ix.io/1I4g/nim