<< 31-10-2019 >>
00:11:31disruptekbut nimdeps makes my elbows itch.
00:18:55*macsek1911[m] quit (*.net *.split)
00:18:55*Asbrn[m] quit (*.net *.split)
00:18:55*nc-x[m] quit (*.net *.split)
00:18:56*Manny8888 quit (*.net *.split)
00:18:56*leorize[m] quit (*.net *.split)
00:18:56*LyndsySimon quit (*.net *.split)
00:18:56*surma quit (*.net *.split)
00:19:40*leorize[m] joined #nim
00:19:41*Manny8888 joined #nim
00:20:23*macsek1911[m] joined #nim
00:20:25*Asbrn[m] joined #nim
00:20:25*nc-x[m] joined #nim
00:22:02*GordonBGood quit (Ping timeout: 240 seconds)
00:23:12*GordonBGood joined #nim
00:24:41*LyndsySimon joined #nim
00:24:41*surma joined #nim
00:47:48*krux02_ joined #nim
00:50:28*krux02 quit (Ping timeout: 264 seconds)
00:55:48*nextloop joined #nim
01:24:06skrylar[m]alright. there's a couple headers left out because of tweaks, but https://git.sr.ht/~skrylar/sknGLIB is almost a thing. gonna boop off for the night tho
01:52:33FromDiscord<treeform> dom96, I had code to load resource files.
01:52:44FromDiscord<treeform> dom96, I am glad you like my iOS docs.
01:53:09FromDiscord<treeform> I found that `macosx` makes `ios` build not work.
01:55:15FromDiscord<treeform> dom96, you can get the root of your iOS bundle with this code: `NSString* filePath = [NSBundle mainBundle].resourcePath;`
01:55:20FromDiscord<treeform> See more here: https://github.com/treeform/glfm/search?q=glfmBundleDir&unscoped_q=glfmBundleDir
01:57:04FromDiscord<treeform> This repo has more instructions: https://github.com/treeform/glfm
01:57:46FromDiscord<treeform> SSL on iOS has to be statically linked ... i have not tried ... but I feel it will be a major pain.
02:12:27*Guest89904 joined #nim
02:14:57*krux02_ quit (Remote host closed the connection)
02:25:14*Romanson joined #nim
02:55:26*rockcavera quit (Remote host closed the connection)
03:50:59*Hideki_ joined #nim
03:54:47stefantalpalaruHN is for filthy casuals fishing for VC money. The real tech talk is on Reddit: https://old.reddit.com/r/nim/comments/dpdsh7/nim_is_the_friendliest_language_to_start/ ;-)
03:55:31*Hideki_ quit (Ping timeout: 268 seconds)
04:04:45*ponyrider joined #nim
04:20:02*Guest89904 quit (Ping timeout: 240 seconds)
04:47:59*nsf joined #nim
04:51:57*cyraxjoe joined #nim
04:59:39*chemist69_ quit (Ping timeout: 250 seconds)
05:01:19*cyraxjoe quit (Quit: I'm out!)
05:01:30*cyraxjoe joined #nim
05:01:45*chemist69 joined #nim
05:18:05*ponyrider quit (Quit: WeeChat 2.6)
05:18:37*ponyrider joined #nim
05:19:21FromDiscord<Winton> HI
05:39:25*narimiran joined #nim
05:46:13FromDiscord<Rika> hello
05:52:03*cyraxjoe quit (Ping timeout: 240 seconds)
05:53:15*ponyrider quit (Quit: WeeChat 2.6)
05:53:40*ponyrider joined #nim
05:58:31FromDiscord<Winton> how are you
05:58:48FromDiscord<Winton> I am new to this programming language and I think it's great
05:59:16*cyraxjoe joined #nim
05:59:33FromDiscord<Rika> well im just here trying to figure out how the master branch is supposed to work
06:00:32FromDiscord<Rika> also i think no one is here because its night time for those in americas or evening in europe
06:01:12narimiran@Rika what master branch?
06:01:36FromDiscord<Winton> Exactly I am from the Dominican Republic, I really knew this language today and the only thing that is theory is that since I read quite according to the opinions it is a good language to program almost everything
06:03:10FromDiscord<Rika> narimiran, master branches in general
06:03:34FromDiscord<Rika> do i commit directly to it? is it always supposed to be by PR? etc etc
06:03:43FromDiscord<Rika> still figuring out git in general basically
06:04:12narimiranah, ok. i thought you were talking about nim-lang/Nim's master branch, which is deprecated and not used. nim's "main branch" is called `devel`
06:04:26FromDiscord<Rika> oh really? why?
06:04:51narimiranwhy is deprecated or why is devel our main thing?
06:05:27FromDiscord<Rika> both, i guess? i thought they'd have similar reasons
06:05:51narimiranin short: our `master` is a relict of past where we released stable versions differently. `devel` is where the action was and is happening, and you should send PRs against it
06:06:32narimiranwhen you go to https://github.com/nim-lang/Nim you will by default see `devel`, and PRs will be based on that
06:06:43*cyraxjoe quit (Quit: I'm out!)
06:09:28*cyraxjoe joined #nim
06:11:39*cyraxjoe quit (Client Quit)
06:14:26*cyraxjoe joined #nim
06:15:10*LargeEpsilon joined #nim
06:16:55*theelous3 joined #nim
06:20:24*kevin joined #nim
06:20:48*kevin is now known as Guest82626
06:21:18*cyraxjoe quit (Quit: I'm out!)
06:24:09*Guest82626 👑
06:25:58*dddddd quit (Read error: Connection reset by peer)
06:27:41AraqGod mode on.
06:29:41*cyraxjoe joined #nim
06:29:59FromDiscord<Rika> ._. time to take cover then
06:35:40*LargeEpsilon quit (Ping timeout: 265 seconds)
06:36:39*solitudesf joined #nim
06:38:15AraqGuest82626 enabled the cheat.
06:47:33*cyraxjoe quit (Quit: I'm out!)
06:51:16*cyraxjoe joined #nim
07:00:00*gmpreussner_ quit (Quit: kthxbye)
07:05:02*gmpreussner joined #nim
07:09:25*Romanson quit (Quit: Connection closed for inactivity)
07:13:16*cyraxjoe quit (Quit: I'm out!)
07:16:01*cyraxjoe joined #nim
07:21:31*PMunch joined #nim
07:27:46*nif quit (Quit: ...)
07:27:56*nif joined #nim
07:29:19*cyraxjoe quit (Quit: I'm out!)
07:29:27*LargeEpsilon joined #nim
07:32:11*cyraxjoe joined #nim
07:36:19Zevvcan someone just delete master than? I find myself checking it out and failing to build it twice a month at least
07:42:50*tklohna joined #nim
07:47:23narimiranZevv: i've put a large warning to master's readme. (but who reads that, right?) i'm afraid to delete it if there is somebody using some pre-0.19 stuff which might depend on master branch
07:49:52Zevvfair enough
07:49:56Araqpre-0.19 should die though, I'm for deleting the master branch
07:50:14Araqor maybe we can rename it
07:50:37Araqto "legacy"
07:51:03*filcuc joined #nim
07:52:49*Hideki_ joined #nim
07:53:17narimiranmore people stumble on `Tables.add` ;)
07:54:34narimirani'd much rather remove that one or put it behind some `-d:iKnowWhatImDoing` flag
07:56:15Araqin what world should 'add' not 'add' though?
07:56:55Araqwe can deprecate 'add' and introduce 'addAnother'
07:57:20narimirani am not confused by it, i'm ok with having it, i don't touch it. but i've seen numerous times people using it, thinking they're doing what `[]=` does
07:57:21Araqif you want to 'add' a key, value pair that's what 'add' does, not sure why people stumble upon it
07:57:32*Hideki_ quit (Ping timeout: 276 seconds)
07:57:53narimiranit is like caSe_inSeNSitiviTy.
07:58:05Araqno, it's different
07:58:39Araqcase_insensitivity is what you bring up when you have no clue about programming (hint: to obfuscate your code every PL offers plenty of opportunity already)
07:58:40narimirani meant in the sense that it just produces meaningless discussion about it
07:59:10Araqwhereas 'add' seems to be really bug-prone
07:59:17Araqtotally different things
07:59:54narimiran"we can deprecate 'add' and introduce 'addAnother'" -- this might do the trick
08:00:32Araqvoid caSe_inSeNSitiviTy() { caSe_inSeNSitiviTy(); } // I can do the same in C++ btw
08:01:05Araqand then in C++ I can introduce
08:01:18AraqcaSe_inSeNsitiviTy and it's something different, the horror
08:01:47AraqPython: AttributeError: 'dict' object has no attribute 'add'
08:02:23Araqsame for 'append'
08:02:38Araqso why does it come up? Python uses []=, Nim uses []=
08:02:52narimiranpeople coming from some other language, i guess?
08:03:23*gmpreussner_ joined #nim
08:04:41*gmpreussner quit (Ping timeout: 276 seconds)
08:05:05*krux02 joined #nim
08:05:55Araq/ The Add method throws an exception if the new key is
08:05:55Araq/ already in the dictionary.
08:06:09AraqC#
08:06:14Araqso that's why...
08:07:10PMunchI just always assumed they were the same, so I probably have some macro out there that creates an add call instead of `[]=` simply because it's easier to do..
08:10:58PMunchAnd I guess that's the issue, `add` simply isn't descriptive enough because it's been mis-used in other languages
08:11:41PMunch`assign` would probably be a better word to use for what `[]=` does, but I think it's easier to change Nim than to change every other language.
08:11:59PMunchDo we know how many bugs this have caused? Never really ran into it myself.
08:40:55*floppydh joined #nim
08:44:17*Vladar joined #nim
08:47:36FromDiscord<Lantos> hey guys, new to nim!
08:47:36FromDiscord<Lantos> any thoughts on optimizing this code?
08:47:36FromDiscord<Lantos> https://github.com/LantosTG/write_file_test/blob/master/src/main_nim.nim
08:48:20FromDiscord<Rika> ~~use a rope maybe~~ but araq said ropes should die so i dont know tbh
08:50:03FromDiscord<Rika> @Lantos ^ (link here https://nim-lang.org/docs/ropes.html)
08:51:15FromDiscord<Rika> (or if you dont want to import, make a seq[string] then add to that, then at the end call `{the seq}.join('')`
08:51:29*solitudesf quit (Ping timeout: 265 seconds)
08:52:55*ng0 joined #nim
08:53:12narimiran@Rika nim is not python. no need to have seq and then convert back to string. strings are mutable in nim
08:53:26FromDiscord<Rika> oops, char cant be empty
08:53:46FromDiscord<Rika> narimiran, but from my experience concat'ing a string that long took ages
08:54:44FromDiscord<Rika> hmm took longer on the seq anyway
08:54:54FromDiscord<Rika> guess it needs a longer string to show slowdowns
08:58:26PMunchLantos, since you're completely new to Nim I'll mention this: turn on -d:release
08:58:43PMunchOn my machine that made it drop from taking 395ms to 48ms
09:09:45GordonBGoodAraq, I see your latest devel commit merging refcounting in --gc:destructorss...
09:10:36GordonBGoodGlad to see you are working on repr.nim as it wasn't disabled with --gc:destructors before and didn't work for seqsv2, I was going to report it
09:11:06GordonBGoodBut I still can't seem to get refcounting working with my test program: https://wandbox.org/permlink/vZIUDOyygNxh7FOb
09:11:28PMunch@Lantos, some minor tweaks, got it down to 60ms on my machine now: http://ix.io/20oz/nim
09:11:44GordonBGoodAs noted, it's functional with lots of small allocations/deallocations so pushes the MM system
09:12:14GordonBGoodAs you can see, it works pretty good with Boehm, even with threading turned on (which it doesn't need)
09:12:49GordonBGoodBut it won't work with --gc:destructors on my machine after getting the latest devel branch
09:13:57GordonBGoodI'm curious to see how straight refcounting compares to using Boehm and others
09:14:24GordonBGoodIt won't work with newruntime because of not being able to share ownership
09:15:36GordonBGoodAlso, unrelated, I'm trying to test my seqsv2 project across all GC'd but can't run --gc:go due to lack of the library file on both Linux and Windows?
09:15:40*theelous3 quit (Ping timeout: 264 seconds)
09:16:12GordonBGood^all GC's
09:17:52GordonBGoodThe go GC library file isn't in the windeps download either
09:18:53GordonBGoodOne could likely produce it using the GCC/go repo, but thats a pain :(
09:20:30*floppydh quit (Quit: WeeChat 2.6)
09:22:56*Ven`` joined #nim
09:23:56PMunch@Lantos, down to 54ms now: http://ix.io/20oC/nim
09:27:11*floppydh joined #nim
09:34:27AraqGordonBGood, it's fine to ignore the Go GC for now
09:35:05*luis__ joined #nim
09:35:22*tamago324 joined #nim
09:35:39*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:35:50AraqI don't know why your program doesn't work with --gc:destructors but --gc:destructors is in development
09:36:22Araqit worked for me for the couple of tests I did manage to do yesterday
09:37:22GordonBGoodAraq: yes, I've set --gc:go tests aside for now
09:39:14GordonBGoodAraq: yes, I recognize that refcounting is a WIP; just submitting this little hamming numbers test to that can maybe serve as a "macro" benchmark; when it works then it must be getting close
09:40:27GordonBGoodThere are faster ways to find an iteration of Hamming numbers, but this serves as a good test due to all the allocations and deallocations
09:41:37GordonBGoodIt tests on a lot of levels, including using closures in the LazyList's
09:42:01Araqlooks like a decent test, yes
09:42:44GordonBGoodand it should work the same whether threading is turned on or not even though it doesn't use threading, and thus shows the slow down due to shared alloc/dealloc
09:42:45*Ven`` joined #nim
09:43:02GordonBGoodand will show the slow-down due to atomic refcounting
09:43:45Araqwell I haven't ported the threading subsystem and I don't want to
09:44:04Araqprefer to write a new one
09:44:46GordonBGoodNo, I understand no porting threading as it's a mess, but I assume that your allocs/deallocs are shared when threading is on and...
09:45:05GordonBGoodthat you use atomic ref counts when threading is on?
09:45:06Araqyou need -d:useMalloc with --threads:on
09:45:38*Hideki_ joined #nim
09:45:46Araqlikewise I don't want to have the old RTTI, 'repr' should be in a library
09:45:57Araqand not depend on RTTI
09:46:36GordonBGoodI've been having problems with -d:useMalloc; you can turn it on for the wandbox link, but that's running the Oct 15 head currently, not the latest
09:46:46Araqideally we only have --gc:boehm and --gc:destructors, both supporting =destroy in the core data structures (seqs, tables, etc)
09:46:56Araqboth supporting shared memory
09:47:29Araqone is for throughput and one is for latency and interop with webassembly, Python etc
09:47:56*luis__ quit (Quit: luis__)
09:48:25*luis__ joined #nim
09:48:45FromDiscord<mratsim> what about araqsgc and newruntime?
09:48:48GordonBGoodAraq: yes, that's my thinking, and after you telling us on the forum how well Boehm works, I've been testing with it - it's quite good
09:49:22Araqmratsim: newruntime evolved into --gc:destructors as far as I'm concerned
09:49:34FromDiscord<mratsim> ah I thought that was the other way around but OK
09:49:52Araqask me again next Monday :P
09:49:52GordonBGoodAraq: your're dropping devel on B/D?
09:49:55FromDiscord<mratsim> so the idea is that for builtin types, both uses the destructors, and they differ only for ref types right?
09:51:00Araqmratsim: yes but we have some implementation freedom, we don't have to have =destroy for seqs we know only contain "Collectable data"
09:51:49AraqGordonBGood, B/D is for version 2.0, cleaning up the GC solutions is for 1.2
09:52:07GordonBGoodAraq: Ah, okay
09:52:09FromDiscord<mratsim> As long as whatever the --gc:MyGC used supports the following (move-only types) I think I can progress on a nicely done threading library: https://github.com/mratsim/weave/blob/master/picasso/memory/object_pools.nim#L72-L78
09:53:39*tamago324 quit (Remote host closed the connection)
09:54:18Araqmove-only types are totally fine
09:55:22AraqGordonBGood, but we also need to teach people how to write code with =destroy ;-) as the 'ref' types don't get faster...
09:55:42FromDiscord<mratsim> so `result = move pool.stack[pool.remaining]` is still the proper syntax to enforce moving?
09:55:58Araqyes
09:58:21GordonBGoodAraq: yes, we need to get people always thinking about using =destroy and what sink and lent do but what do you mean 'the "ref" types don't get faster'?
09:58:21Araqand if we remove the RTTI we need a new marshal.nim, we could embrace Status's serialization library but we don't have a process for moving things into the stdlib nor do we have the "distribution"...
09:59:11Araqwell they produce atomic RC ops, that's slow
09:59:29GordonBGoodI recognize that ref counted ref's even backed by destructors aren't going to be that fast
09:59:53GordonBGoodwhen threading is turned on, the reference counts will be atomic operations
09:59:59FromDiscord<mratsim> that's why I said before 1.0 that it would be nice to document a way for improving the stdlib :/
10:00:34Araqmratsim: I wrote the document afterwards, so what
10:00:45*jjido joined #nim
10:01:08FromDiscord<mratsim> to manage expectations of stability guarantees
10:01:52FromDiscord<mratsim> anyway, not really important, just my "I told you so" moment 😉
10:02:45Araqqueue up.
10:03:26*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:04:22AraqGordonBGood, in a nutshell: We need to teach that 'Node' is the wrong granularity, it should be Tree or Graph
10:05:23GordonBGoodAraq: Ah, you are talking runtime metadata or AST manipulations?
10:05:50*EvilKhaosKat joined #nim
10:06:04Araqneither, I am talking about we need examples how to design parse trees and the like
10:06:33GordonBGoodAre Tree and/or Graph already exist that we can build examples against?
10:06:47Araqnah
10:07:26FromGitter<alehander42> but whats the difference with node and tree
10:07:29FromGitter<alehander42> parent links?
10:08:18GordonBGoodAraq: I'd like to help, but it sounds like it's at a level of abstraction beyond my level of expertise; I'm a specialist in low level things
10:08:41Araqdon't worry, it means I can sell more books... :P
10:09:20GordonBGoodBut if I see a different better way suggested by you "high-level" guys, I can grab onto it and run with it if it's better
10:10:51GordonBGoodAraq: With the amount of the time you spend here on IRC, following up on the forum, writing actual code, and managing the repo, I don't know when you are going to find time to write books :)
10:11:13Araqbtw if you 'move' refs around, you only have the atomic read operation which is free on x86
10:11:14*Guest82626 quit (Ping timeout: 265 seconds)
10:11:35leorizeif I know that I'll throw an error frequently, then should I use a Result type or exceptions are performant enough?
10:11:36Araqcheck the code :P
10:12:10Araqleorize, you are probably better off with the Result type
10:13:47FromGitter<alehander42> PMunch https://github.com/NimParsers/parsetoml
10:14:01FromGitter<alehander42> seems nice, but it needs to show in the readme that it can actually generate toml back
10:14:06PMunchalehander42, huh?
10:14:25FromGitter<alehander42> well, from the readme i thought it can only parse toml
10:14:36FromGitter<alehander42> i found some random example of toTomlString in a issue :P
10:14:40PMunchAh yeah.. The create TOML is a bit experimental..
10:14:43PMunchIIRc
10:15:04FromGitter<alehander42> so i'll probably create very simple seq with objects
10:15:08FromGitter<alehander42> i guess it should work for that
10:15:30PMunchMaybe, try it :)
10:18:29Zevvhow widespread is this toml?
10:19:31PMunchUsed quite a bit in Ruby land I think
10:19:41PMunchI just like it because it's so readable
10:20:02ZevvI made the mistake to consider yaml again the other day
10:20:18ZevvI should make this post it note saying "DONT DO YAML" and staple it to my forehead, maybe that helps
10:20:18FromGitter<Vindaar> and toml is simple, which is nice for a change. not like yaml..
10:22:50*kevin_ joined #nim
10:26:37ZevvI think I like the dotted-keys thingy, but I also might not
10:27:51PMunchI mean it certainly has its limitations, but that means it is easier to reason about
10:27:57PMunchBoth for humans, and for parsers
10:28:05Zevvand it has comments :)
10:28:36*Ven`` joined #nim
10:29:18*EvilKhaosKat quit (Quit: Leaving)
10:29:41FromGitter<alehander42> i use submodules
10:29:46FromGitter<alehander42> for my nim packages currently
10:29:49FromGitter<alehander42> so AMA
10:30:01FromGitter<alehander42> clyybber
10:30:11FromGitter<alehander42> yaml is nice
10:30:21FromGitter<alehander42> if you use a subset but i decided to try toml this
10:30:57*LargeEpsilon quit (Ping timeout: 276 seconds)
10:31:51FromGitter<alehander42> oh man it doesnt accept a random structure PMunch
10:32:23AraqGordonBGood, one thing that I'm thinking about it shared memory + non-atomic RC ops
10:32:43Araqto pass stuff to a different thread a 'move' is good enough
10:32:54FromGitter<alehander42> PMunch one idea is to just reuse the https://github.com/status-im/nim-serialization lib
10:32:55PMunchalehander42, what do you mean?
10:33:10FromGitter<alehander42> and to just add a reader (parser) / writer similar to https://github.com/status-im/nim-json-serialization
10:33:21FromGitter<alehander42> so we can get all the type stuff automatically
10:33:33FromGitter<alehander42> and do Toml.decode(stuff, mytype)
10:33:50FromGitter<alehander42> PMunch well i wanted to directly encode my own type
10:34:14FromGitter<alehander42> working with low level toml values overally feels unnecesary for me in language like nim where usually its easier to type your schema
10:34:23FromGitter<alehander42> but its best to have both options
10:34:31PMunchDid you try `?`
10:34:54PMunchDecoding would be nice though..
10:35:10PMunchFeel free to PR :)
10:35:25FromGitter<alehander42> PMunch but my point is: it doesnt make sense to reinvent it
10:35:50FromGitter<alehander42> so a lib like nim-serialization where all the from/to type stuff is already written and one have to mostly implement the low level reading/writing procs
10:35:54FromGitter<alehander42> seems easier to me
10:36:37FromGitter<alehander42> hm, `?` is cool, but i dont want to work with toml values at all: i want to work with normal nim types
10:37:10PMunchYou should be able to write the serialisers for nim-serialization
10:38:08*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:38:25*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:42:50FromGitter<alehander42> well, its not a trivial amount of work i admit
10:43:25FromGitter<alehander42> but if i really find the need of toml more i can try to map some of your code to such a deserializer
10:43:51FromGitter<alehander42> i'd put it in the nimparsers org tho
10:44:01*Ven`` joined #nim
10:45:18PMunchThat would be great!
10:45:34PMunchI'd probably do it myself if I actually used parsetoml for any larger project
10:45:41PMunchThe interface is a bit clunky
10:46:13*Ven`` quit (Read error: Connection reset by peer)
10:47:00GordonBGoodAraq: sorry, was away looking at the why my test porgram doesn't work with your ref counting - it's to do with generating a closure in a nested closure - line 71 on the test program
10:48:01*luis__ quit (Quit: luis__)
10:48:03GordonBGoodand there are comments in the lambdalifting file at line 696 that it will find it and doesn't like nested closures much!
10:48:23GordonBGoodThe "up" field is nil...
10:48:31*luis__ joined #nim
10:48:56*Hideki_ quit (Ping timeout: 240 seconds)
10:49:04FromGitter<alehander42> PMunch awesome: i'll thik about it, but not having a lot of time and prefer to try one other idea
10:50:03GordonBGoodAraq: re: "shared memory + non-atomic RC ops" and "to pass stuff to a different thread a 'move' is good enough"...
10:51:12GordonBGoodI've been thinking about it, too - a move is good enough when ownership doesn't have to be retained in the calling thread...
10:51:55GordonBGoodand we can maybe eliminate atomic ref counting or any ref counting when within the same scope by DFA...
10:52:42GordonBGoodLeaving atomic ref counting maybe only necessary when there are multiple owners across threads...
10:53:18*clyybber joined #nim
10:53:32GordonBGoodAnd speed isn't really a concern much then as the overheads of context switching even from a thread pool will be much greater than the cost of atomic ref counting
10:54:04clyybberalehander42: Ha, how comes?
10:56:10FromGitter<alehander42> well i do it for a long time
10:56:29FromGitter<alehander42> just our project uses several patches of the compiler
10:56:35FromGitter<alehander42> or other projects
10:56:41FromGitter<alehander42> 1) some lib forks
10:56:48FromGitter<alehander42> so i guess it just made sense
10:57:09FromGitter<alehander42> 1) some closed source deps
10:57:21GordonBGoodbrb
10:57:33FromGitter<alehander42> i think it was more because of the reproducability, i didnt take decision
10:58:09FromGitter<alehander42> but i still use nimble with almost all my other nim projects
11:05:07*jjido joined #nim
11:15:59AraqGordonBGood, if you actually *share* the ownership on mutable data it's unlikely you will have it correct just because Nim used atomic ops for you
11:16:30Araqbut if you don't mutate it concurrently it will work out, so *shrug*
11:17:21Araqstill the design doesn't strike me as particularly elegant, paying the costs for what is done in some half-assed way
11:17:45*letto quit (Quit: Konversation terminated!)
11:19:17*letto joined #nim
11:25:56*letto quit (Quit: Konversation terminated!)
11:26:35GordonBGoodAraq: shrug, most of it has been done before by somebody for some PL; I had hopes the by somehow using the ideas from B/D we would end up with something different...
11:27:52GordonBGoodA lot of algorithms can get away with just moving ownership to the other thread and getting ownership back with the result if necessary, so moving would work...
11:28:49GordonBGoodAnd a lot of the rest only mutate the data in one thread, so shared ownership would work
11:30:12GordonBGoodUnless in continually going back to stir the pot someone comes up with some brilliant break-through idea
11:30:45*abm joined #nim
11:39:37*kevin_ quit (Quit: leaving)
11:44:51Araq> And a lot of the rest only mutate the data in one thread, so shared ownership would work
11:45:04Araqexactly but then it uses atomics and it doesn't have to
11:46:36Araqhere is what you can do: you use bit 0 or the RC to mean "shared between threads"
11:46:44Araq*of the RC
11:46:45GordonBGoodAraq: Yes, unless DFA can eliminate some of the ref counts as it was said to do in the
11:47:02GordonBGood""Biased ref counting" article about Swift
11:47:18Araqand then when we move x to a different thread and if RC == 1 the bit remains unaffected
11:47:34Araqbut if we have RC > 1 we set the bit to enable atomics
11:47:39GordonBGoodYes, something like that
11:47:50Araqbiased refcounting is different
11:47:58Araqthan that. very different.
11:49:38Araqhere is the problem with my idea: only the outer 'ref' is moved to a different thread, it can contain other refs and they could be shared wildly
11:50:07Araqwe would need a deepMove() operation :P
11:50:27Araqhowever, here is where B/D could help us, it enforces deep uniqueness
11:52:25*clyybber quit (Read error: Connection reset by peer)
11:53:02*LargeEpsilon joined #nim
11:53:40*clyybber joined #nim
11:55:41GordonBGoodYes, I understand that bias ref counting is different, I was just talking about that they stated that Swift already elides many ref counts away...
11:55:45*Vladar quit (Quit: Leaving)
11:55:59*lritter joined #nim
11:57:02GordonBGoodThe only problem with shared ownership of some sort of shared data with inner ref's is mutation (may) need to have locks, but not always
11:57:24GordonBGoodI've looks into deepMove and don'e like it - it stinks of deepCopy
11:57:27*rockcavera joined #nim
11:58:35GordonBGoodOh, I suppose you mean inc all internal ref counts and then deepDestroy dec's them when the outer ref is destroyed, I don't think that's actually necessary
11:58:45FromDiscord<mratsim> we should defer shared data structures to library
11:59:33GordonBGoodmratsim, in my current thinking, I agree that everything other than ref handling should be somewhere else
11:59:34FromDiscord<mratsim> that's what C++ did for a very ong-time, it's only very recently that they have parallel STL
12:00:49GordonBGoodAraq: yes, I still like B/D in the long term if we can figure oot some sort of shared ownership angle on top of it
12:02:16*tklohna quit (Ping timeout: 240 seconds)
12:02:25*letto joined #nim
12:02:53PMunchSorry, I was trying to clean up the playground and unfortunately managed to delete all the images.. I'm rebuilding them now, but it takes a while..
12:04:00Araqmratsim: the default allocation for C++ always was 'shared memory' though
12:04:22Araqso you could get away with locks on top of std::vector
12:04:49Araqand you don't get away with this in Nim v1
12:05:27FromDiscord<mratsim> I don't know, Arraymancer and neo gets away with using seqs as a backend and multithreading on top 😛
12:09:11*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:21:50*tklohna joined #nim
12:28:30*clyybber quit (Quit: Quit)
12:28:41*clyybber joined #nim
12:28:41*clyybber quit (Client Quit)
12:30:09*tiorock joined #nim
12:30:09*tiorock quit (Changing host)
12:30:09*tiorock joined #nim
12:30:09*rockcavera is now known as Guest28913
12:30:09*Guest28913 quit (Killed (cherryh.freenode.net (Nickname regained by services)))
12:30:09*tiorock is now known as rockcavera
12:38:28*luis__ quit (Ping timeout: 264 seconds)
12:38:38*clyybber joined #nim
12:41:22FromDiscord<Lantos> I was running with nim c --opt:speed --d:release
12:41:22FromDiscord<Lantos> I couldn't seem to get the one PMunch going any faster
12:42:57clyybberGordonBGood: Whats B/D standing for?
12:43:40PMunchLantos, --opt:speed is implied with -d:release :)
12:44:02PMunchDid you try --gc:markandsweep?
12:44:07PMunchThat gave me a nice speedup
12:44:14*ertp07 joined #nim
12:45:02*nsf quit (Quit: WeeChat 2.6)
12:45:35clyybberboehm/destructor??
12:45:56FromDiscord<Lantos> oh ahah sure not keeping --opt:speed and -d:release makes it 2x fast 😉
12:46:19FromDiscord<Lantos> I'll try nim c --d:release --gc:markandsweep
12:47:30PMunchDid you see the paste I made? That was the fastest I got it
12:47:39PMunchIn includes the flags I used to compile with
12:48:05FromDiscord<Lantos> mark sweep gives a nice bump
12:52:35FromDiscord<Lantos> ```
12:52:35FromDiscord<Lantos> dell:~/Documents/nim/write_bench/src$ cat main_nim.nim
12:52:35FromDiscord<Lantos> import times
12:52:35FromDiscord<Lantos>
12:52:35FromDiscord<Lantos> let time = cpuTime()
12:52:35FromDiscord<Lantos> let f = open("test_nim.txt", fmWrite)
12:52:35FromDiscord<Lantos>
12:52:37FromDiscord<Lantos> var data: string
12:52:39FromDiscord<Lantos> for i in 0..1000_000:
12:52:40FromDiscord<Lantos> data.add("line ")
12:52:41FromDiscord<Lantos> data.add($i)
12:52:43FromDiscord<Lantos> data.add("\n")
12:52:44FromDiscord<Lantos>
12:52:45FromDiscord<Lantos> f.write(data)
12:52:47FromDiscord<Lantos> f.close()
12:52:48FromDiscord<Lantos> echo "Time taken: " & $((cpuTime() - time)*1000.0'f32) & "ms"
12:52:51FromDiscord<Lantos> dell:~/Documents/nim/write_bench/src$ nim c -d:release --gc:markandsweep -r ../src/main_nim.nim
12:52:52PMunchPlease don't post long things directly to Discord..
12:52:53FromDiscord<Lantos> Hint: used config file '~/.choosenim/toolchains/nim-1.0.0/config/nim.cfg' [Conf]
12:52:55FromDiscord<Lantos> Hint: operation successful (300 lines compiled; 0.046 sec total; 6.004MiB peakmem; Release Build) [SuccessX]
12:52:57FromDiscord<Lantos> Hint: ~/Documents/nim/write_bench/src/main_nim [Exec]
12:52:58PMunchUse a paste service..
12:52:58FromDiscord<Lantos> Time taken: 142.021312ms
12:53:00FromDiscord<Lantos> dell:~/Documents/nim/write_bench/src$
12:53:00narimiranyay, code paste from discord
12:53:02FromDiscord<Lantos> dell:~/Documents/nim/write_bench/src$ cat main_nim.nim
12:53:03FromDiscord<Lantos> import times
12:53:04FromDiscord<Lantos>
12:53:06FromDiscord<Lantos> proc main() =
12:53:07FromDiscord<Lantos> let time = cpuTime()
12:53:09FromDiscord<Lantos> let f = open("test_nim.txt", fmWrite, high(cint))
12:53:10FromDiscord<Lantos>
12:53:11FromDiscord<Lantos> const l = "line "
12:53:13FromDiscord<Lantos> for i in 0..1_000_000: <message clipped>
12:53:15FromDiscord<mratsim> @Clyybber: Bacon and Dingle paper
12:53:16FromDiscord<Lantos> oh
12:53:17FromDiscord<Lantos> sure
12:53:19FromDiscord<Lantos> does it kill irc?
12:53:24PMunchCan someone please fix the Discord bot..
12:53:32PMunchIt doesn't kill it, it's just massively spammy
12:53:36FromGitter<Vindaar> nah, it just fills up my whole main screen with blue messages :)
12:53:50FromDiscord<Lantos> https://pastebin.com/Vqet46Tu
12:53:54FromDiscord<Lantos> 🙂
12:54:01FromDiscord<mratsim> Maybe we should bridge Discord to Gitter, instead of brdigning to IRC
12:54:21FromDiscord<mratsim> discord <-> Gitter supports properly Discord code paste
12:54:27PMunchWouldn't that give us double nick wrapping?
12:55:24FromDiscord<mratsim> you can adjust that in the from gitter bot I think
12:57:05FromDiscord<mratsim> the discord <-> IRC bot is also awful on the Discord side because there is no proper text separation
12:57:05FromDiscord<Lantos> I'm off lunch but I will try this rope method when. I get home.
12:57:43PMunchText separation?
12:58:10FromDiscord<mratsim> yeah, if you then another irc people talks, it all seems like new lines
12:58:26FromDiscord<mratsim> you don't have the same separation as one someone on discord talks
12:59:18FromDiscord<mratsim>
12:59:18FromDiscord<mratsim> https://cdn.discordapp.com/attachments/371759389889003532/639448312423907334/DeepinScreenshot_select-area_20191031135847.png
12:59:42PMunchOh right
12:59:52PMunchBecause they are all messages by the same "person"
13:00:03FromDiscord<Lantos> It's kind of confusing at first didn't realize what was going on for a minute
13:00:34FromDiscord<mratsim> actually the Gitter-Discord bridge that we used for Status channels properly separates
13:01:07narimiranquick question (i haven't tried it yet): is it possible to have recursive iterators?
13:01:45FromDiscord<mratsim> apparently it shouldn't be possible but I have one specific case where it works
13:02:07FromDiscord<mratsim> not sure if the discussion was on github or IRC though
13:02:28Araqnarimiran: no.
13:02:53FromDiscord<mratsim> ah yes mine were recursive at compile time
13:05:52narimiranah, ok. i'll try to think of some workaround (which hopefully won't be too slow and inefficient)
13:07:08*jjido joined #nim
13:08:17Araqfor some reason my first gist ever is 'proc parseBool(s: string): bool = ...'
13:08:35FromDiscord<Rika> is there an issue with that being your first gist
13:09:23AraqI think it's a gist because I switched between computers and needed this piece of code
13:09:56FromDiscord<mratsim> My first fist is upgrade-python-3 😛 - https://gist.github.com/mratsim/8135b4f6824b61955122fdf828652298
13:10:36FromDiscord<mratsim> omg the things that python package management forces you to do
13:11:45Araqbut but but ... it's better than having useful stuff in Python's stdlib
13:12:16*ertp07 quit (Ping timeout: 240 seconds)
13:12:23Araqwe all know package management is easy to do perfectly and the internet connections never fail.
13:13:18clyybbermratsim: Thanks
13:13:56*LargeEpsilon quit (Ping timeout: 265 seconds)
13:15:16clyybbermratsim: Didn't you succees in doing a recursive iterator?
13:15:23clyybberWith : auto ?
13:15:47FromDiscord<mratsim> that was a recursive with fixed depth known at compile time
13:16:01clyybberAh.
13:16:08FromDiscord<mratsim> https://github.com/mratsim/Arraymancer/blob/master/src/private/nested_containers.nim#L22-L30
13:16:54FromDiscord<mratsim> that was because the iteration depth depended on the types
13:17:14clyybberPretty cool
13:17:43FromDiscord<mratsim> there was a thread were people tried several stuff and had a iterator cannot be recursive error or something like that otherwise
13:20:24*Vladar joined #nim
13:20:54shashlick@dom96 the choosenim PR is done, hope you can merge it
13:21:31shashlickNative 7z and xz support so we can stop the gz duplicate archives going forward
13:21:41shashlickInstall Linux binaries
13:21:54*ertp07 joined #nim
13:22:06shashlickWindows CI
13:23:07*ertp07 quit (Read error: Connection reset by peer)
13:25:18*ertp07 joined #nim
13:25:29*Hideki_ joined #nim
13:26:07FromDiscord<mratsim> .xz is super slow to compress though :/
13:26:13FromDiscord<mratsim> (benches: https://community.centminmod.com/threads/round-3-compression-comparison-benchmarks-zstd-vs-brotli-vs-pigz-vs-bzip2-vs-xz-etc.17259/#post-73060)
13:26:23*Hideki_ quit (Remote host closed the connection)
13:27:01*Hideki_ joined #nim
13:27:48*sagax joined #nim
13:27:56*Hideki_ quit (Remote host closed the connection)
13:28:14shashlickYep but that's what we post today for all posix archives
13:28:40shashlickNightlies pay the price but they extract quite fast
13:29:37federico3fast? not really
13:30:49shashlickWell that's cause a 12mb archive expands to 500+ mb of source in csources
13:32:51federico3I suspect the download time / decompress time is not the best tradeoff
13:40:09*nixfreak65 joined #nim
13:40:21*nixfreak65 is now known as nixfreak_work
13:42:09nixfreak_workDoes anyone have an example of using compiler options to link a static lib (nim c -d:mingw --cpu:amd64 --passC="<static lib>" --threads:on window.nim ) I kind of confused on how to do this
13:44:25*dddddd joined #nim
13:45:00*LargeEpsilon joined #nim
13:48:08shashlickYou need to copy the static lib from windows and link that in
13:48:44nixfreak_workok thank you
13:48:46shashlickAnd you need the .a file, not the dll
13:49:14shashlickStatic = a, dynamic = dll, so or dylib
13:59:48*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:00:04*ertp07 quit (Read error: Connection reset by peer)
14:00:23*ertp07 joined #nim
14:00:54FromGitter<alehander42> Araq the fact that python's package management has issues
14:00:56FromGitter<alehander42> is not an argument
14:01:15FromGitter<alehander42> most ppl in python-land are like "if we just had rubygems or npm"
14:01:17FromGitter<alehander42> (yes, npm)
14:02:25FromGitter<alehander42> from what i've seen from most lang communities/forum/subreddits third party libs are absolutely the normal thing, nobody is really wondering why he doesnt have a web framework or specific data lib in stdlib
14:03:13FromGitter<alehander42> usually people are annoyed by more specific things like the too-many-small dependencies thing or build/deploy/reproduce specifics
14:03:39FromGitter<alehander42> i just want to point out that i think the "people dont like deps" thing is a fallacy
14:04:02*tklohna quit (Ping timeout: 240 seconds)
14:04:19FromGitter<alehander42> not that i dont think having a distribution might be nice, but just not to base it on such a thesis imho
14:05:38FromGitter<alehander42> if you think about it, even with the novelty of ownership i've seen *a lot* of people actually think cargo is one of the main pro-s of rust compared to c++
14:08:22disruptekyou think python people want npm?
14:08:36disruptekhave you used npm for anything of significant size?
14:09:32*jjido joined #nim
14:11:08FromGitter<alehander42> have you used python package management
14:11:23disrupteknot recently. 😁
14:11:31FromGitter<alehander42> the point is that it has its own problems, people design several competing package managers for it and there isnt just one good solution
14:11:44FromGitter<alehander42> npm is still better than that imo
14:12:32FromGitter<alehander42> but the point isnt that npm is good or not good, but that people want deps, and most modern languages focus on having very good package managers/3rd party lib tooling
14:13:14*GordonBGood quit (Ping timeout: 276 seconds)
14:13:42disruptekit's an outgrowth of the language features, though. and npm is just the largest example. there are other package managers in the js ecosystem, but they largely share the same issues.
14:13:45FromGitter<alehander42> so while the discussions these days about how exactly nim managers should work are great, i just wanted to disagree with the "people dont want dependencies" sentiment
14:13:45FromDiscord<Rika> is a sort proc supposed to be inplace
14:14:11FromGitter<alehander42> maybe, in some particular situations with some caveats thats true, but in 80% its not imo
14:14:36FromGitter<alehander42> disruptek but i almost never heard anybody in ruby world complaining about gems
14:14:40FromGitter<alehander42> or in rust about cargo
14:14:42disruptekpython's package management is really pretty tame compared to npm. like, by an two orders of magnitude.
14:14:51FromGitter<alehander42> people loved their package ecosystems
14:15:04FromGitter<alehander42> they were like "look just add one like to this, import and great stuff happens"
14:15:32disrupteksome people complain that the only way to do anything in rust is via cargo.
14:15:35FromGitter<alehander42> i think python's and npm might just have different issues
14:15:47FromGitter<alehander42> disruptek well i am sure you can still use makefiles if you want
14:16:15FromGitter<alehander42> but making 90% of the projects at least able to work with the main package manager is good
14:16:31FromGitter<alehander42> look at c++: they're scraping for something like that with conan and all other efforts
14:17:01FromGitter<alehander42> and it's probably very hard when 90% of the stuff there just isnt developed with that in mind
14:17:22disruptekthis. you're comparing newer ecosystems with older ones.
14:17:36FromGitter<alehander42> look at even go: they had the simple-ish vendor thing, but still people wanted a normal package manager
14:17:39disruptekcargo doesn't have competition.
14:18:07FromGitter<alehander42> yes, but the c/c++ ecosystem started in 70/80s
14:18:15FromGitter<alehander42> thats not an excuse for any newer lang
14:18:16disruptekthat's my point.
14:18:23*tklohna joined #nim
14:18:44FromGitter<alehander42> but my point is that this is also what happens if a language doesnt have a good standartized solution or at least convention
14:18:45disruptekso are you in favor of opinionated package management or...?
14:18:49FromDiscord<Rika> older ecosystems have more projects/managers which means more competition
14:19:08FromGitter<alehander42> how do you define it
14:19:08disruptekit means more code written that might not work in a different view of packaging.
14:19:23FromGitter<alehander42> well, this different view of packaging should be somehow compatible
14:19:33disruptekgo is pretty opinionated.
14:19:39clyybberAraq: Re: Default fields, it's actually really easy to do the checks(very lightweight) in sem and the transformation still in transf.nim.
14:19:41FromGitter<alehander42> otherwise we get 3-4 interesting package managers, some projects that work with one, some with other
14:19:49FromGitter<alehander42> and this sucks for the user
14:19:53FromGitter<alehander42> who just wants to use a and b
14:20:23disruptekthe compiler defines certain requirements. if the manager can produce them to spec, it shouldn't matter which they use.
14:20:34FromGitter<alehander42> but go now has https://github.com/golang/dep
14:20:36FromGitter<alehander42> do you mean dep
14:20:45disruptekthis is why the compiler needs to be patched. 😉
14:20:46FromGitter<alehander42> disruptek i also agree with that
14:21:03FromGitter<alehander42> having some kind of api/format that is universal
14:21:31FromGitter<alehander42> but the important thing is it works for most packages and that people can easily do whatever they need with at least one of those managers
14:21:44disruptekit already has command-line options, nim.cfg, and config.nims. the problem is, it's not narrow enough.
14:22:18disruptekjust make it more naive and then package management can innovate as needs be.
14:22:29Araqclyybber: oh?
14:22:44Araqalehander42: your argument is convincing.
14:23:15Araqproblem remains about how to ship e.g. comprehensions with Nim
14:23:37clyybberAraq: So I could make it transparent to macros which is IMO more consistent with the way other variables will be initialized.
14:23:47Araqor cligen or other small libs widely regarded as an improvement over what the stdlib overs.
14:23:55clyybberLike result, or `var s: SomeObj`
14:24:08disrupteki think the real issue is that we have to be able to control the venn diagram of what the compiler sees.
14:24:31disruptekif you can constrain the compiler to look in a single place, we can put whatever we want there. no problem.
14:25:21disruptekgo uses an env var, iirc. not sure that's still the case.
14:26:08disrupteki'm talking about that level of simplicity. like nimblepath. because our packages are flat.
14:26:14FromGitter<alehander42> Araq well, i think one can have a "distribution" with such libs, but as i said even this looked harder to define to me
14:26:22*tklohna quit (Ping timeout: 268 seconds)
14:26:39disruptekdid you look at my nimph readme?
14:27:00FromGitter<alehander42> e.g. why cligen and not https://github.com/iffy/nim-argparse or confutils
14:27:14FromGitter<alehander42> i guess stars can be a metric for inclusion
14:27:54disruptekthe real question is, which packages best-serve the users.
14:27:55FromGitter<alehander42> but other option is to just have a single metapackage which one can install or even the compiler recommends
14:28:16disruptekcligen and npeg best-serve the users because their developers are so active in the community.
14:28:27disruptekthey provide the best possible experience.
14:28:30FromGitter<alehander42> but this can change tomorrow
14:28:40FromGitter<alehander42> tomorrow somebody can come and write an amazing altetrnative parser lib
14:28:44FromGitter<alehander42> and people start using that
14:29:11FromGitter<alehander42> thats the point with 3rd party libs imo
14:29:13disruptekyes, and if it serves the users better, it will doubtless get stars and get distributed.
14:29:20FromGitter<alehander42> but thats already how it works
14:29:24disruptekyes.
14:29:25Araqdisruptek: I did but it's beyond me
14:29:25FromGitter<alehander42> anybody that needs npeg
14:29:30FromGitter<alehander42> can go and `install npeg`
14:29:37disruptekhey, i'm the one that said araq's post was pointless, remember? 😁
14:29:42FromGitter<alehander42> thats exactly the point of having a package manager
14:30:32FromGitter<alehander42> still, one can have a set of distributions, but i think that things get a bit political there
14:30:38disrupteknimph is just a way to nest distributions in a single file, ad infinitum.
14:30:57clyybberdo we actually have an pkg issue aside from that noboy "loves" nimble?
14:31:09FromGitter<alehander42> but anyway both seem useful but imo 1.) great package manager 2.) good distribution mechanism
14:31:17disruptekpackage local deps is the open packaging issue that's problematic.
14:31:21Araqdisruptek: what I do understand is that you want to keep --nimblePath or have something like --path:subdir/**
14:31:46disruptekAraq: that, or ffs don't look anywhere but where i tell you.
14:32:04FromDiscord<Chiqqum_Ngbata> Put me in the small-core camp. Competition amongst third parties is good / encourages engagement. Local nimble installs plz
14:32:37clyybberWhy can't nimble put in a config that includes --path:nimblePath ?
14:32:44FromGitter<alehander42> disruptek nimph looks interesting but i have to read more later
14:33:04disruptekthere's nothing to it.
14:33:24disruptekit trades disk space for correctness.
14:33:55Araqlook, the distribution is about how to grow/evolve the stdlib, you tell me "omg, no distribution please" but then I don't know how to evolve the stdlib.
14:34:14disruptekyes you do.
14:34:25Araqok. how?
14:34:28disruptekit's just my opinion, but i agree with everything you wrote about stdlib.
14:34:50disruptekbut you know that. you and i already had that discussion.
14:35:00*solitudesf joined #nim
14:35:04Araqso please help my memory
14:35:14disruptekwell, i feel that stdlib is about the compiler.
14:35:18*ertp07 quit (Ping timeout: 245 seconds)
14:35:41federico3Araq: did you summarize the idea somewhere?
14:35:50FromDiscord<mratsim> It's not about package managers it's about API. As long as core API and data format (.nimble file) is the same, competing managers will be interoperable
14:35:57disruptekyes.
14:36:06disruptekbut that api is too poorly defined right now.
14:36:11FromDiscord<mratsim> there will be period where innovations to the API (say lock files) will only be supported in one implementation
14:36:16Araqfederico3: haven't you seen https://github.com/nim-lang/RFCs/issues/173 ?
14:36:38FromDiscord<mratsim> but hopefully either they converge, or one disappears
14:36:45*ertp07 joined #nim
14:37:00federico3no
14:37:06clyybbermratsim: What core API/data format does a pkg really need? version, name and dependencies. I guess
14:37:23FromDiscord<Chiqqum_Ngbata> Personal opinion, small stdlib with great documentation. Things like cligen /might/ be a good idea to ship with nim. At a certain point the standard library probably doesn't need to grow, right?
14:37:32FromDiscord<Chiqqum_Ngbata> Is it a common complaint that the standard library isn't featureful enough?
14:38:00disrupteki'd prefer that the stdlib shrank, honestly. the larger nim grows, the less constrained it should be by its stdlib.
14:38:04FromDiscord<arnetheduck> I generally find it pretty confusing that `nim` looks for libraries all over the place in magic folders - that's the kind of stuff I'd want my package manager to take care of - specifically, if the package manager is managing paths, `nim` itself should definately not add magic lookup paths to the mix, so that I don't accidentally include some "rogue" code
14:38:19disruptekyes, it drives me nuts.
14:38:25clyybberconcur
14:38:28FromDiscord<arnetheduck> lots of us think the std lib is way too big
14:38:44*ertp07 quit (Read error: Connection reset by peer)
14:38:53FromGitter<alehander42> Araq i dont say distribution is bad, just that a people dont want deps thing is not true imo
14:38:56disruptekif it's hard to find good 3rd-party nim code, that's a separate issue.
14:38:56FromDiscord<Chiqqum_Ngbata> (Being relatively new to nim I sympathize with that idea)
14:39:04clyybberI think the stdlib tries to do too much, but then doesn't fully go with it. I think we should cut off modules that are better implemented elsewhere.
14:39:13FromDiscord<arnetheduck> also, it's certainly too big for the current community to maintain leading to low quality overall
14:39:14disruptekyes.
14:39:41disruptekthe fact that an implementation exists is not a high enough barrier to entry into the stdlib.
14:39:52FromDiscord<mratsim> I think that's the main issue. there are stuff that should be in the std lib but are not (big ints, not like a big int API is controversial)
14:40:02disruptekand the reliance upon the stdlib means you are forever relying upon those low-barrier-to-entry implementations.
14:40:02FromDiscord<arnetheduck> but more importantly, it's a slow and inefficient development model and holds nim itself back
14:40:15disruptekyep.
14:40:17FromGitter<alehander42> evolvng stdlib can be done with a distro, but also with just having wannabe modules under experimental/
14:40:21FromDiscord<mratsim> and some stuff that may benefit from agility in the design space (streams)
14:40:21FromGitter<alehander42> or just with rfc-s
14:40:45disrupteka distribution really has nothing to do with nim/compiler.
14:40:54disruptekjust let the community build that.
14:41:00disruptekas needed.
14:41:03disruptekas desired.
14:41:34FromDiscord<mratsim> but the thing we need it's just that everyone knows there is a way to improve and potentially replace a standard library and we will not stay with those for 1à years (aka Python 2)
14:41:34Araqthat's a bit like saying "let the community fix nimble, it's open source"
14:41:39disruptekto me, the important thing is to put up signs that say, "don't use ropes; they're slow", or "don't use coro; it's getting pulled out soon"
14:41:53FromDiscord<mratsim> yes exactly disruptek: managing expectations
14:41:58disruptekmy opinion on nimble is well-documented.
14:42:07disrupteknimble, n: somehow, the opposite of agile.
14:43:22clyybberAraq: I would say that ;p
14:43:45clyybberAnd the community does, apparently.
14:44:04Araqif anything shashlick does.
14:44:09*ertp07 joined #nim
14:44:10Araq:-)
14:44:22clyybberpraise shashlick
14:44:27disruptekPRAISE
14:44:30clyybbertasty
14:44:47disruptekwhere is ol' shashlick?
14:46:00clyybberAraq: Is it intended that we don't infere the discriminator? And instead error with:
14:46:14clyybbercannot prove that its safe to initalize with the runtime value for the discriminator
14:46:38clyybbers/intended/intentional
14:46:39FromDiscord<mratsim> use Foo(kind: myKind, value: value, ...)
14:46:45FromDiscord<mratsim> that was changed in 1.0
14:46:53Araqa custom error message for this case? yes, that means it's intentional.
14:47:01disruptekchanged in 0.20. grrr.
14:47:21clyybberAraq: But the error message is a bit off, it says runtime value for discriminator
14:47:21disruptekbut hardly worth complaining about in the grand scheme of things.
14:47:29clyybberBut I don't provide the value at all.
14:47:49FromDiscord<mratsim> it's the same thing as uninitialized objects
14:47:55FromDiscord<mratsim> it might contain garbage
14:48:14clyybbermratsim: I'm talking about `Foo(value: value)`
14:48:14Zevvdoesn't nim zeromem *everything* always?
14:48:17FromDiscord<mratsim> though it's a bit annoying when you want to use case object with lazy initialization
14:48:26clyybberWhere the presence of value could be used to infer the kind.
14:48:33disruptekyes, that's what he's working on in the compiler right now.
14:48:35clyybberZevv: bout to change that :D
14:48:46Zevvwow for performance reasons, right?
14:49:00clyybberfor default values rather
14:49:25clyybberthere is actually code in the compiler to remove unneccessary inits with the help of the dfa but its disabled
14:49:26FromDiscord<mratsim> zero init is good, it prevents a lot of bug and exploits
14:49:33Zevvah ok. So my profiler #1 memsets() will now be replaced by memcpys() :)
14:49:52FromDiscord<mratsim> There is probably a way to divide the memset by 2 😛
14:50:11FromDiscord<mratsim> I don't remember the trigger but for some datastructures memset is done twice
14:50:34disruptekwhat i'd really like is to hoist my lets to definitions at the top of the block and then let me assign them values once in one of N spots in the block.
14:50:42clyybberAraq: It's rather easy to make it infer the discriminator and is a safe feature.
14:50:57disruptekrather than making me use a var.
14:51:30clyybberdisruptek: Yeah I thought about something like that in general, like immutability after the first use
14:51:41clyybberOr in a more general sense after n uses
14:52:06disruptekafter 7 uses i just want it to call the destructor.
14:52:23disruptekalso, make sure there's no way for me to measure uses.
14:52:28FromDiscord<mratsim> let foo = block: ...long code block...
14:52:47clyybberwhat do you ppl think: Should the compiler infer the discriminator kind where its inferrable?
14:53:02clyybberPro: It's convinient
14:53:11clyybberCon: It could be a bit confusing with default fields
14:53:17FromDiscord<mratsim> ideally, I would prefer if we do not have to spell the name of the field for constructor
14:53:46FromDiscord<mratsim> Foo(kind: mykind, value: myvalue) is very noisy compared to Foo(mykind, myvalue)
14:54:04disruptekmaybe it infers it but you have to add a pragma if defaults are enabled, to say "i know what i'm doing".
14:54:04clyybberThats a seperate issue
14:54:05FromDiscord<mratsim> that would save much more typings and noise than inferring the discriminator kind
14:54:26FromDiscord<mratsim> and that would also avoid issues if we want to change the syntax of case objects to allow some common fileds I think
14:54:34FromDiscord<mratsim> fields*
14:54:45clyybberYeah, also a seperate issue tho :p
14:54:56disruptekthat noise is just noise, though. doesn't affect the boilerplate we're currently saddled with.
14:55:01*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:55:01disruptekno semantics to it.
14:57:49clyybberdisruptek: The issue of the idea in conjucntion with default fields is that, when I write `Foo(valuethatonlyexistswhenkindis1: 3)` and the default value of kind is 0, should I error then, because we are in the wrong branch or should I overwrite the default kind with the value I can infer.
14:58:10leorizeerror please
14:58:21disruptekerror.
14:58:36clyybberOk, so I'll just improve the current error msg.
14:59:05clyybberI take that as you don't want to infer the kind even if it doesn't have a default value?
14:59:15disrupteki have an issue somewhere for a problem where it actually errors and shouldn't, but maybe jasper fixed that.
14:59:20shashlickAm on work calls, will have to catch up later
15:00:41disruptekif it doesn't have a default value, we need to error or at least warn because discriminator objects may eventually support fields shared between variants.
15:00:58disruptekalthough i guess you could error when that happens instead.
15:01:23clyybberdisruptek: Yeah, I'm only talking about cases where its not ambiguous
15:01:31*solitudesf quit (Ping timeout: 268 seconds)
15:02:25clyybberdisruptek, leorize: So do you agree that I should infer when its not ambiguous and error when the inferred value is at odds with the default value?
15:02:41disruptekhttps://github.com/nim-lang/Nim/issues/11428
15:02:44clyybberOr should I just not infer at all?
15:03:30*solitudesf joined #nim
15:03:46disruptekit seems pretty convenient in the code that i'm writing these days.
15:04:48Araqclyybber: there is already inference in a 'case' statement context
15:05:00Araqiirc, never tried it myself
15:05:06*floppydh quit (Quit: WeeChat 2.6)
15:05:29Araqdisruptek: I'm still waiting for your reply
15:05:30disruptekcan't seem to find the issue i had in mind, but the behavior changed in a subtle way.
15:05:43disruptekAraq: wrt what?
15:06:20Araq"you do know how to manage the stdlib already"
15:06:31disrupteki feel a little dirty saying it, but yes, i want a smaller, stricter, more naive api from the compiler wrt module search space.
15:06:32clyybberAraq: https://play.nim-lang.org/#ix=20pI doesn't work
15:07:00disrupteki agree with everything you said about the stdlib.
15:07:01PMunchclyybber, the images are being rebuilt, so the latest version in the playground is 0.17.0
15:07:11PMunchJust FYI
15:07:14clyybberOh
15:07:26clyybberWell the issue is reproducable in 1.0.99 too
15:07:31clyybberor whatever devel is rn
15:07:41Araqdisruptek: ok, so no replacement for sugar.lc in the stdlib
15:07:52Araqwe deprecate lc, then we remove it
15:08:30disruptekif you're going to remove it, the least you should do is move it to nimble. but, yeah.
15:08:47disruptekthink about it.
15:08:56disruptekyou're talking about not wanting to carry code that you don't use.
15:09:02disruptekwhy would you?
15:09:03*nixfreak_work quit (Ping timeout: 260 seconds)
15:09:10AraqI want my for loop expressions. alehander42 wrote the code
15:09:21disruptekso put them in.
15:09:29clyybberAraq: Is that snippet supposed to work or not?
15:09:43Araqclyybber: no.
15:09:50disruptekit would be crazy to create a whole programming language and then not use any of the code people write in it to make it even better.
15:09:52Araqthat's not the inference I was talking about.
15:10:27clyybberAraq: Not sure I understand how in case statements one can infer
15:10:46clyybberAh
15:11:00clyybberYou mean infer properties for the code inside the branches?
15:11:04disruptekbecause the clauses are known.
15:11:31clyybberI'm talking about the opposite thing, in object constructors. Infer the discriminator from the branches' fields
15:11:33shashlicksome quick comments - package local deps has a solution - I will document later today and share for any feedback
15:11:43shashlickimplementation isn't too hard from initial review, will need to run some tests
15:11:57shashlickthe main thing is ensuring backwards compatibility
15:12:26shashlickre: simplifying Nim's awareness of paths, a nim.cfg solution seems viable but the question is how to ensure it is backwards compatible again
15:12:34Araqclyybber: https://play.nim-lang.org/#ix=20pJ unfortunately this doesn't compile
15:12:41shashlickthat will get figured out as well, it isn't too complicated
15:12:48AraqI thought it would, bummer :-(
15:13:01disruptekthat is exactly the issue, Araq.
15:13:47disruptekshashlick: all we need is a --pleaseReallyDontLookAnywhereElse
15:13:51*kungtotte joined #nim
15:14:00shashlickthe main thing I'd like everyone to focus on is that nimble can be fixed and improved and what we really need is a clear path forward on how to improve it while providing stability for the community
15:14:37shashlick@disruptek, noted and it isn't really a hard problem - there's a variety of ways to improve the status quo
15:15:08*PMunch quit (Quit: Leaving)
15:15:12disruptekyes, when you have a shashlick in your back pocket, anything is possible. 😍
15:15:20clyybberOne consistency problem I see with infering the kind is that one could argue that the default for every kind is 0 and thus should be treated like a default value (which it isn't currently)
15:15:39shashlickre: the Nim distro topic, I feel that's not really a big issue in my mind
15:15:55shashlickstdlib needs to be lean and maintainable and I like the important packages idea
15:16:05clyybberAraq: Wdyt discriminator inference yay or nay or later maybe?
15:16:07shashlickwe can simply add a meta package that install all important packages
15:16:18Araqclyybber: if in doubt, leave it out.
15:16:23shashlickwhy do we need to take it on as a core effort, I'm not sure
15:16:27clyybberfine
15:16:59shashlickwe can vote and add good packages to the stdlib if there's interest but if we want to keep things lean, I'm fine with that
15:17:18shashlickpackage management can be the goto way to pull in what you need
15:17:26disruptekyou can do meta-packages today, so that's a done deal, afaiac.
15:17:29shashlickand we can innovate in terms of enabling binary packages
15:18:07shashlicklike pip allows downloading pre-built binaries
15:18:32shashlickI know there's a bunch of issues but with some focus on nimble, we can take it places
15:18:59clyybberwhat does one need binary packages for?
15:19:00shashlickI just want to have the ability to move faster somehow
15:19:16*drewr joined #nim
15:19:43shashlickyou don't need any deps for that package installed
15:20:06clyybberBut thats only useful for executables right?
15:20:24shashlickwe can just as well pull in static libs and dlls
15:20:38clyybberAnd embed them into the binary?
15:20:42shashlickright now, Nim only relies on source distribution, we should look into prebuilt
15:21:01clyybberSeems unneccessary IMO
15:21:27disruptekstart with the nail, not the hammer.
15:21:34shashlickthat's how C/C++ works - sure you can build your own copy
15:21:44shashlickbut there's pre-built stuff in the OS ready to use
15:21:53clyybberWhy would I install the dll dependency with my pkg manager when the user thats going to run my executable has to have it anyways?
15:21:57disruptekwe're talking about people who have C and Nim compilers. do they need binaries?
15:22:16shashlickand you don't care what torture that maintainer had to go thru to get it built, you don't inherit that problem
15:22:49clyybberUmm, but build configurations can be shared
15:23:00clyybberAnd that seems more sane than sharing random binaries
15:23:07shashlickdependencies don't end at the package you nimble install - it can also install a variety of things
15:23:10clyybberthen embedding them into the binary (because thats the only use)
15:23:16shashlickand every end user has to deal with that
15:23:17disruptekbut if you care so much about that tortue, why don't you contribute your binary distributions to libarchive and reach a much larger audience?
15:23:39disruptekdon't hide your light under a bushel, shashlick.
15:23:47disrupteknim can afford to share you with the rest of the world.
15:23:47clyybberI don't get why nimble cares about binaries/executables at all,
15:24:19disruptekclyybber: because if it didn't, `nimble develop` would work correctly for most of cli tools. and we can't have that.
15:24:27Araqclyybber: mostly because some packages come with helper binaries, eg. 'karun' from Karax
15:24:30shashlicktoday, if anyone wants to use nimarchive, they have to build the whole thing and deal with the nuances of CI
15:24:47clyybberah
15:24:49shashlickI added it to choosenim and all the learnings had to be applied to the choosenim CI
15:25:16shashlicknimble does not support installing binaries unless they are checked into source control
15:25:26shashlickthis is not how it is with pypi for example
15:25:42shashlickand the entire world lives with shared and static libs, it doesn't need some new justification
15:27:27FromGitter<zacharycarter> sokol_gfx and sokol_app bindings are working \o/
15:27:30disruptekit's open to debate, but most importantly, it doesn't seem like the thing that's holding back nim adoption.
15:27:32FromGitter<zacharycarter> (https://files.gitter.im/nim-lang/Nim/Rkbk/image.png)
15:28:23disrupteki want one of those gold nims you got there.
15:29:15shashlickIf Nim made it easier to create Dynamic libraries that can be used by other communities, it would make it even more popular than it is today
15:30:22FromGitter<zacharycarter> is this ever coming: `import lib/[sokol_app as sapp, sokol_gfx as sgfx]`
15:30:45federico3shashlick: *yes*
15:30:50disruptekyou can't say that you want us to improve deficiencies in nimble and then list a bunch of greenfield features that you want to work on.
15:32:56shashlickStep by step
15:33:00jxypypi supports very limited amount of arch/os and goes crazy with non-standard compiler/library locations
15:33:32shashlickBut all related to the deps
15:33:35*solitudesf quit (Ping timeout: 268 seconds)
15:34:18*solitudesf joined #nim
15:34:54jxyleaving deps to system/package manager would be better
15:34:59Araqzacharycarter: can't see why not
15:36:13FromGitter<zacharycarter> sweet :D
15:36:35clyybberBtw, why array syntax instead of tuple?
15:37:05clyybber`import lib/(sokol_app as sapp, sokol_gfx as sgfx)` ?
15:37:21clyybberHmm, nevermind
15:37:44FromGitter<zacharycarter> man supercell'
15:37:45clyybberThe current one looks cooler
15:38:18clyybberno entry for supercell in the manual
15:38:33FromGitter<zacharycarter> extending it in any way takes a lot of work - it's pretty refreshing to come home and work on my Nim project
15:38:51FromGitter<zacharycarter> heh - I wish there was a manual for it, it'd make my job easier
15:39:51FromGitter<zacharycarter> oh - I realize now, because I typed in man supercell at first haha
15:39:57shashlick@jxy good luck getting every distro to pick up Nim let alone packages
15:41:39clyybberzacharycarter: What were you intending to write?
15:41:47clyybberThe edits don't appear here I think
15:42:11FromGitter<Clyybber> ah
15:42:28FromGitter<Clyybber> @zacharycarter are you working at supercell now?
15:43:34FromGitter<zacharycarter> no - Frogmind but we use supercell's backend from clash of clans / royale
15:44:01clyybberOh cool, thats the badland devs right?
15:44:05FromGitter<zacharycarter> yup
15:44:23clyybberI remember playing that game with 15 fps or so on my 480p galaxy y phone :D
15:44:44FromGitter<zacharycarter> haha :P that's more playing of it than I've done
15:45:16FromGitter<zacharycarter> I've only played the games that we're working on now, but I've positive things about badlands
15:46:17clyybberwhat games are you working on rn?
15:46:35FromGitter<zacharycarter> Badland Brawl and Rumble Stars
15:46:52FromGitter<zacharycarter> they've already globally launched, and then we have one in soft launch called Feast Island
15:47:01jxyshashlick: maybe leave the external deps to system package manager
15:47:25clyybberzacharycarter: Mulitplayer games
15:47:28jxynimble needs a robust way to check the existing shared libraries
15:47:41clyybberalso I have to confess, I never bought badlands, used luckypatcher :p
15:48:01*jxy quit (Quit: leaving)
15:48:07FromGitter<zacharycarter> clyybber: yup! the backend scales well but it's a complex beast, especially with the physics simulations
15:48:30clyybberI can imagine.
15:48:48clyybberdo you use your vector graphics?
15:48:55FromGitter<zacharycarter> I think I'm also rusty working on large object-oriented codebases
15:49:49FromGitter<zacharycarter> hmm - I haven't looked at the art assets too closely yet, I'm not sure what format they're in and how they're being rendered
15:50:19FromGitter<zacharycarter> about all I've done with the game client is get it to run, right now I'm working on loading game settings from a database rather than files
15:50:42clyybberAh cool. I was always wondering
15:50:52clyybbermobile games have to be fairly efficient
15:51:00clyybberand still most of them use vector graphics
15:51:01FromGitter<zacharycarter> which I thought I had solved today, but the past two days have been digging through code all day, thinking I've found a solution, only to realize later that my solution won't work and then starting over
15:51:14FromGitter<zacharycarter> yeah - I wouldn't be surprised if that was the case
15:52:08clyybberpoor config files have to die.
15:52:14FromDiscord<Rika> dont know where to ask, but i'd appreciate a review of this code if no one minds https://github.com/de-odex/circa/blob/feature/ordered-mods/src/circa/mods.nim
15:52:30clyybberbut I guess its fair in a multiplayer focused mobile game, dont want people to mess around too much
15:53:00FromGitter<zacharycarter> well - it's not great when adjusting liveops requires a whole new client and server build
15:53:19FromGitter<zacharycarter> like scheduling a new event or something
15:54:31clyybberRika: Looks fine, but use const instead of a global let if possible.
15:54:43clyybberRika: Are you building an osu! client?
15:56:17FromGitter<zacharycarter> what is osu?
15:56:48clyybbera rythm game
15:56:54FromDiscord<Winton> Hi
15:56:54FromGitter<zacharycarter> ah
15:57:08clyybberwhere you move the cursor a lot
15:57:30FromDiscord<Winton> Some library to create interface
16:00:11*jxy joined #nim
16:01:41FromDiscord<Rika> clyybber, shit ive been found out
16:02:17FromDiscord<Rika> its just a utility library, not for recreating osu but for calculating things like pp or replay stuff
16:02:52FromDiscord<Rika> its actually further in development than what's shown in the repo, i just haven't sorted out all of the commits because its really taxing to keep an organized history
16:10:47FromDiscord<Rika> clyybber, is there no issue with the way i create a table for the mod to string mapping?
16:12:42FromDiscord<Winton> clyybber
16:12:43FromDiscord<Winton> ?
16:13:40clyybberWinton ?
16:13:59*NimBot joined #nim
16:14:35clyybberRika: No issue
16:15:28clyybberBut when you know the mappings at compiletime anyways you can just use string enums
16:15:38disruptekso is there a plan for this? https://github.com/nim-lang/Nim/issues/11428
16:15:52disruptekjust curious.
16:16:21*LargeEpsilon_ joined #nim
16:16:51*solitudesf quit (Quit: Leaving)
16:17:06clyybberdisruptek: Default fields are one step
16:17:09*solitudesf joined #nim
16:17:15clyybberthe next steps should follow
16:18:08disruptekcool.
16:19:30FromDiscord<Rika> clyybber, i need both long names and short names ("HalfTime", "ht")
16:20:02*LargeEpsilon quit (Ping timeout: 240 seconds)
16:20:43*ertp07 quit (Ping timeout: 245 seconds)
16:21:04*LargeEpsilon_ quit (Ping timeout: 268 seconds)
16:25:00clyybberRika: Ah, yeah seems appropriate then.
16:25:44clyybberRika: I think you shoul use `let` for the table instead of `const` though, but I am not sure why. Araq may chime in and explain
16:26:21FromDiscord<Rika> the table needs let afaik
16:26:52clyybberAh, ok. Then its all fine.
16:27:25clyybberRika: its gone
16:27:27clyybberthe link is dead
16:28:17clyybberah, I see. YOu just cleaned up the repo structure a bit
16:28:19*jjido joined #nim
16:28:20FromDiscord<Rika> ah, i deleted the branch
16:28:30FromDiscord<Rika> i merged it already into devel
16:28:53clyybberI see
16:29:05FromDiscord<Rika> since you and i am the only ones reviewing the code, there isnt much to do with PRs yet
16:30:12*ertp07 joined #nim
16:34:35*sagax quit (Quit: Konversation terminated!)
16:34:56*sagax joined #nim
16:36:57shashlick@jxy - getHeader in nimterop does that for you
16:37:36shashlickIt can search the standard shared and static libs
16:38:16*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:03:09*Ekho quit (Quit: An alternate universe was just created where I didn't leave. But here, I left you. I'm sorry.)
17:03:59*jjido joined #nim
17:04:03*Ekho joined #nim
17:08:46*Ekho quit (Max SendQ exceeded)
17:12:49*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:15:01FromDiscord<Lantos> so guys what irc do you use?
17:17:20lqdev[m]freenode#nim
17:19:03clyybberI think he meant irc client :)
17:19:08clyybberI use weechat
17:20:25lqdev[m]clyybber: I know he probably meant that, but IRC is IRC and an IRC client is an IRC client ;)
17:21:04FromGitter<alehander42> hm why does
17:21:04FromGitter<alehander42> withPackageName
17:21:12FromGitter<alehander42> not return the nimcahe path + .c file to me
17:21:27*Ekho joined #nim
17:21:32*Ekho quit (Max SendQ exceeded)
17:21:42FromGitter<alehander42> maybe i should pass .cfilename
17:21:43FromGitter<alehander42> sorry
17:22:26FromGitter<alehander42> hm withPackageName(p.config, p.module.cfilename) still returns /home/al/codetracer/examples/@mfind.nim
17:22:43FromGitter<alehander42> i expect something like <path to nimcache>/mfind.c
17:27:57FromDiscord<Lantos> how do I connect to the nim in weechat
17:27:58FromDiscord<Lantos> /server add gitter irc.gitter.im -username=user -password=***** -autoconnect
17:28:10FromDiscord<Lantos> how do I connect to the nim in weechat
17:28:10FromDiscord<Lantos> ```/server add gitter irc.gitter.im -username=user -password=***** -autoconnect```
17:28:54*clyybber quit (Ping timeout: 268 seconds)
17:29:27*Ekho joined #nim
17:29:31*filcuc quit (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
17:30:34*clyybber joined #nim
17:31:18FromGitter<LantosTG> Oh
17:32:15narimiranconnect to freenode
17:35:05disruptekgah today's code is creepier than usual.
17:35:11FromDiscord<Lantos> whats the nickserve for nim?
17:35:41*clyybber quit (Ping timeout: 268 seconds)
17:35:46leorizeis there proc in Nim for removing diacritics from utf-8 strings?
17:38:32disruptekyou could do it with unidecode i guess.
17:39:49ZevvI doubt Nim has the tables onboard for that
17:40:03disrupteknope.
17:40:10*anon joined #nim
17:40:21anonhello
17:40:31*anon is now known as LantosTG
17:40:37LantosTG:)
17:40:46narimiranLantosTG: welcome :)
17:41:00*LargeEpsilon_ joined #nim
17:41:02disruptekyou made it, huh?
17:41:07LantosTGmade it
17:41:16disruptekwhat's good about weechat?
17:41:30LantosTGtook the words out of my mouth
17:42:00Zevvleorize: just map 'àáâãäçèéêëìíîïñòóôõöùúûüýÿÀÁÂÇÈÉÊËÌÍÎÏÑÒÓÔÕÖÙÚÛÜÝ' to 'aaaaaceeeeiiiinooooouuuuyyAAAAACEEEEIIIINOOOOOUUUUY' :)
17:42:25disruptekprobably the best solution.
17:42:25leorizenim has an unidecode table :P
17:42:30leorizelooks like I can use that
17:42:35LantosTGcan you @disruptek
17:42:40Zevv"an usnicode table"
17:42:46Zevvthere's *tons* of unicode tables, but nim only has a few
17:43:00disruptekyou need my new renderer, `disruptex`.
17:43:17leorizeZevv: that mapping won't work for my language :P
17:45:29*LargeEpsilon_ quit (Read error: Connection reset by peer)
17:45:47narimiranleorize: what weird language is that?
17:46:01narimiranoh, it won't work for mine too :D
17:46:14Zevvpfff last time I helped any of you
17:47:14narimiranZevv: how could you missed čćšđž?
17:47:27Zevveasy :)
17:47:35narimiran:Đ
17:49:02leorizespot the differences: Đ Ð
17:49:14*Trustable joined #nim
17:49:19narimirani can't
17:49:44narimiranis one icelandic and the other one ex-yugoslavian?
17:51:01narimirani know that iceland has ð, whose capital is Ð. and ex-yu has đ whoce capital is Đ
17:51:06leorizeyea
17:51:17narimiranhow many internet points did i win?
17:51:57narimiranand what is your language, leorize? ;)
17:52:43leorizetry to guess :) it should appear in one or two of my repos somewhere on the internet :P
17:52:50leorizemine*
17:53:21FromGitter<Willyboar> This αεδφθψωξ
17:53:30FromGitter<Willyboar> ???
17:54:00narimiranis that.... aedftfox?
17:54:02disruptekthat's my dad's name.
17:54:50narimiran*aedftpox
17:56:01narimiranleorize: descriptions for all your repos are written in english. thanks for the hint, it really helped :P
17:56:33*ertp07 quit (Ping timeout: 245 seconds)
17:57:37ZevvWhy the hell did I get some CDN page checking my browser when going to nim playground?
17:57:57narimiranmaybe somebody is trying to DDOS the playground?
17:58:12Zevvyeah but is it behind cloudflare or something?!
17:58:13narimiranbecause exactly that happened yesterday with that N++ stuff
17:58:23Zevvanyway, here is the thingy remover: https://play.nim-lang.org/#ix=20qu
17:58:30Zevvscroll right to find the 'submit' button :)
17:59:07leorizeI got 502 :P
17:59:41LantosTGexit
17:59:45*LantosTG quit (Quit: WeeChat 1.9.1)
18:00:03leorizeweechat 1.9.1? how old is that?
18:02:21disruptekremember, PMunch is rebuilding it. he said it'd be running an old version of the container.
18:02:44Zevvah right
18:03:19federico3leorize: only 2 years actually
18:03:38*jfoutaise quit (Ping timeout: 240 seconds)
18:05:47*jfoutaise joined #nim
18:10:16*kungtotte quit (Read error: Connection reset by peer)
18:11:05*ertp07 joined #nim
18:11:41*nsf joined #nim
18:12:26*ertp07 quit (Read error: Connection reset by peer)
18:14:19*rockcavera quit (Remote host closed the connection)
18:15:03leorizenarimiran: well I do have more than just github :P
18:15:29leorizebut probably I've taken down things with my name on it :P
18:15:53disruptekeasy: vimscript is your native tongue.
18:16:08*fredrik92 joined #nim
18:18:43*couven92 quit (Disconnected by services)
18:18:51*fredrik92 is now known as couven92
18:19:08*fredrik92 joined #nim
18:22:59*clyybber joined #nim
18:23:10*ertp07 joined #nim
18:24:24narimiranleorize: nothing useful on gitlab either. i give up.
18:25:52clyybberI believe its what disruptek said
18:25:57clyybber
18:26:16disrupteki think he just took his name down. i saw it the other day.
18:26:49*ertp07 quit (Client Quit)
18:32:56*jken left #nim ("Leaving")
18:33:02*jken joined #nim
18:39:00*theelous3 joined #nim
18:42:34FromGitter<Willyboar> @narimiran θ = theta , ψ = psi
18:42:42*jjido joined #nim
18:43:29*GordonBGood joined #nim
18:49:57GordonBGoodclyyber: sorry, grabbed some zz's: re: B/D, that's the Bacon/Dingle paper upon which Araq based the owned ref's of newruntime
18:50:16GordonBGoodNSorry, clyybber
18:50:28FromGitter<awr1> i now have some free time again!
18:50:37FromGitter<awr1> i'm updating choosenim to head and i'm getting this error
18:50:41FromGitter<awr1> ... /usr/bin/ld: /home/awr/.cache/nim/nimsuggest_r/@m..@[email protected]: file not recognized: file truncated
18:50:50FromGitter<awr1> should i just delete the nim cache folder
18:50:58disruptekctrl-alt-del
18:53:01clyybberGordonBGood: Ah yeah, I remember
19:00:33AraqGordonBGood, were you saying that 'up' needs to stay a 'ref' for your code to work?
19:02:29*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:04:42FromDiscord<Lantos> anyone used https://github.com/genotrance/nimgraphql?
19:04:42FromDiscord<Lantos> or some sort of graphql in nim ?
19:05:38*sentreen_ joined #nim
19:08:11disruptekLantos: https://github.com/jdhorwitz/NimQL
19:08:16disruptekhaven't used it.
19:08:42disruptekseems to be all of 3 lines long, of which all are comments.
19:09:03disruptektests pass though, so...
19:09:15disruptek`doAssert(1 + 1 == 2)`
19:10:02*sentreen quit (Ping timeout: 268 seconds)
19:10:08clyybberthe best code is that which isn't needed
19:10:17disruptekno code is fast code.
19:10:29FromGitter<awr1> deleting the folder worked
19:11:08clyybberI detached all io from my PC, and now its freaking fast
19:11:17*jjido joined #nim
19:11:25clyybberalso I might have solved NP P
19:11:50clyybber(im writing this from inside)
19:12:42disrupteki thought i smelled something burning.
19:12:42Araqlet N = 1 ==> NP == P. Simple.
19:13:04disruptekawr1: welcome to the docker era of sysadmin.
19:14:55FromDiscord<Lantos> lol disruptek you got me excited
19:15:22disruptekme too. i forked that package ages ago.
19:15:23shashlick@Lantos - i wasn't able to recreate your nimgraphql issue
19:15:50shashlickwhat version of gcc are you using?
19:16:06FromDiscord<Lantos> are you the maintainer ?
19:16:40FromDiscord<Lantos> ```
19:16:41FromDiscord<Lantos> Thread model: posix
19:16:41FromDiscord<Lantos> gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
19:16:41FromDiscord<Lantos> ```
19:17:15disrupteknah, i usually sprinkle code among my comments, but it's about the same result -- trivial and similarly useless.
19:18:45GordonBGoodAraq: I got the test program to compile and run by manual lifting the smults proc out of the hamming iterator and the inner LazyList generator out so it wasn't nested...
19:19:48GordonBGoodSo it now is able to find the upfield with less nesting, but while the program runs, the answers are wrong...
19:20:09Araq:O
19:20:19disruptekwrong answers fast. some people pay a lot for that.
19:20:36AraqGordonBGood, need to run it via valgrind
19:21:44shashlick@Lantos - yep
19:22:43GordonBGoodThere is something incomplete in the region of line 696 of lambdalifting.nim; even when upfield is found, I can't see where it returns a closure - makeClosure is never called out the bottom
19:22:53FromDiscord<Lantos> do you need to run it with nim cpp rather then nim c?
19:22:54shashlicklooks like your gcc is quite up to date, not sure what to do cause i have tested this on ubuntu
19:23:38shashlickyep - https://github.com/genotrance/nimgraphql/blob/master/nimgraphql.nimble#L30
19:23:38GordonBGoodAraq: valgrind? I've never used it. How do you set it up, any docs?
19:24:05FromDiscord<Lantos> I'll give it a shot with cpp
19:24:12Araqit's not for Windows
19:27:01disruptekshashlick: your nimgraphql builds for me but it looks like some test data is missing.
19:28:07GordonBGoodAraq: valgrind's not for Windows? Can't be compiled under MSYS2?
19:29:02Araqforget MSYS2
19:29:24AraqI'll have a look at it soon. what's the status of --seqsv2?
19:29:28GordonBGoodAraq: anyway, if the bottom of the symToClosure proc in lambdalifting.nim isn't complete, it can't work, can it?
19:31:16shashlick@disruptek - it is barebones
19:31:21FromDiscord<Lantos> no longer getting the ast error. It build but getting data missing
19:31:38FromDiscord<Lantos> Unhandled exception: cannot open: nimgraphql/test/kitchen-sink.graphql [IOError]
19:31:39FromDiscord<Lantos> [FAILED] parsing without schema support
19:31:39FromDiscord<Lantos> /home/anon/Documents/nim/nimgraphql/tests/tnimgraphql.nim(26) tnimgraphql
19:31:39FromDiscord<Lantos> /home/anon/.choosenim/toolchains/nim-1.0.0/lib/system/io.nim(667) readFile
19:31:39FromDiscord<Lantos>
19:31:41FromDiscord<Lantos> Unhandled exception: cannot open: nimgraphql/test/schema-kitchen-sink.graphql [IOError]
19:31:41FromDiscord<Lantos> [FAILED] parsing with schema support
19:31:44FromDiscord<Lantos> Error: execution of an external program failed: '/home/anon/Documents/nim/nimgraphql/tests/tnimgraphql '
19:31:50FromDiscord<Lantos> but I think I kknow where they are
19:31:57GordonBGoodAraq, seqv2 is coming along but I keep running into snags dealing with the difference of being object based rather than ptr (or ref?) based, requiring more "when" cases
19:31:58FromDiscord<Lantos> its generated after nimble install isnt it?
19:33:07GordonBGoodI spent most of today your time investigating this ref counting, which actually helped as in digging into some of your patches I think I understand better what needs to be done
19:33:09AraqGordonBGood, how is symToClosure incomplete?
19:33:31FromDiscord<Lantos> [Suite] GraphQL Parsing Tests
19:33:31FromDiscord<Lantos> [OK] parsing without schema support
19:33:31FromDiscord<Lantos> [OK] parsing with schema support
19:34:53disruptekoh, yeah. works fine after i install it.
19:35:14disruptekanother gold star for shashlick.
19:35:16disruptekPRAISE
19:36:06FromDiscord<Lantos> (::) cookie
19:36:13disrupteksadly, another case where the tests for a nimble package failed for no explicable reason.
19:37:15GordonBGoodAraq: on symToClosure, it seems we are dealing with the bottom "else" case, and which every other successful case ends with a call to makeClosure (or closureCreationForIter)...
19:37:38GordonBGoodthe code seems to be able to fall out the bottom without assigning anything to result
19:37:51dom96ooh treeform, thanks for the links
19:37:55GordonBGoodAt least, if I understand the code correctly
19:39:18Araqwell no, it's a 'while true' loop that must exit via some 'return'
19:39:19*rockcavera joined #nim
19:39:36Araqthere is no "fall out to the bottom"
19:39:42GordonBGoodBy lifting the closure creation code so it wasn't as deeply nested, I managed to get past the check for upfield being nil, but now it runs, but incorrectly
19:40:02FromDiscord<Lantos> Now just got to work out how to use it ;p
19:40:20Araqmust be something else, in theory lambdalifting requires no further patches
19:40:22shashlickseems like i didn't check in the test file 🙂
19:40:31shashlick@dom96 - choosenim PR 😄
19:40:36Araqbbl
19:41:00AraqGordonBGood, anyway, keep up the good work and no rush
19:41:07dom96Happy halloween/no-brexit day :D
19:41:41shashlick@disruptek / @Lantos - it should be in the the code that's checked out
19:41:48GordonBGoodAraq, well something gets assigned to access, and then the proc ends, which would mean that result just contains whatever is default for PNode, which would be nil, right?
19:41:49shashlickneed to run the test in the root dir, not in tests
19:41:54shashlicksince file is relative to project root
19:42:23disruptekokay, but it seems that it's only pulled it when you install the package.
19:42:37shashlickyou need to run `nimble setup`
19:42:40FromDiscord<Lantos> thanks shashlick will check it out after dinner. Have you pushed this to the nimble package manager?
19:42:40FromDiscord<Lantos> https://nimble.directory/search?query=graphql
19:42:52shashlickno i hadn't yet
19:43:12GordonBGoodAnd the generated code errors kind of reflect this as if the generated closures are just placeholders
19:43:14FromDiscord<Lantos> I think it has building pass/fails to help
19:43:57disruptekshashlick: maybe `before test: setupTask()`?
19:43:58GordonBGoodThe code runs and gives answers, but the answers are just 2 and 3 as if the LazyList's were never advanced
19:44:00shashlickmain problem is that nimble doesn't like nimgen wrappers too much cause i need to do stuff in `before install` which is problematic
19:44:11GordonBGoodAnd the test program exits with an error
19:44:23disruptekdamn lazy lists.
19:44:28disruptekdon't do a lick of work.
19:45:38clyybberGordonBGood: Might be handy to push your changes so we can check them out
19:47:46GordonBGoodThe good news is that the test program runs quite fast compared to Boehm, but I don't know how valid that is because of the errrors...
19:48:53GordonBGoodalso, the current --gc:destructors, if I turn on --threads:on, the test program doesn't get very far before crashing
19:49:15*cyraxjoe quit (Quit: I'm out!)
19:49:34shashlick@Lantos - https://github.com/nim-lang/packages/pull/1231
19:50:54GordonBGoodclyybber: the above problems aren't related to seqsv2, they are related to me writing a test program that more thouroughly tests GC/ref counting, including closures
19:52:03*cyraxjoe joined #nim
19:52:20GordonBGoodclyybber: When I get back to seqsv2 today, and if I run into further time delaying problems, I'll push my changes to see if you guys can help
19:52:59GordonBGoodI'm new at this, so you might jump right to what my problems are
19:53:36*cgfuh joined #nim
19:54:15GordonBGoodI regard both seqsv2 and araq's ref counting project as top priorities that need to get finished in order to get closure to Nim version 1.2
19:55:24GordonBGoodBut I didn't think the testing of GC was thorough enough, especially including closures and speed benchmarks, so wanted to contribute the LazyList Hammings benchmark
19:57:39GordonBGoodclyybber: GC/ref counting benchmark running under Boehm - https://wandbox.org/permlink/vZIUDOyygNxh7FOb
19:58:28GordonBGoodThe Wandbox head hasn't been updated to the latest ref counting branch yet, so won't run with --gc:destructors...
19:58:46*wo joined #nim
19:59:03GordonBGoodAnd even with the latest devel on my machine, there are the above described problems
20:01:26*wo quit (Remote host closed the connection)
20:01:33*shadowbane joined #nim
20:02:49GordonBGooddisruptek: lazy lists only work when you force them (to work) ;)
20:03:08*shadowbane quit (Client Quit)
20:03:23disruptekget out the whip.
20:04:09*disruptek cracks the whip at the lazy lists.
20:04:20disrupteky'know the real problem with these lists?
20:04:40disruptekthey're async. it looks like they're all working, from a distance, but when you get closer... only one is.
20:04:48GordonBGoodAraq: re: keep up the good work - we won't know how good it is until I get something working :/
20:04:52*disruptek cracks the whip at the lazy lists.
20:06:23GordonBGooddisruptek: yeah, lazy lists have their limitations, but they seem to be a good way to "stress test" araq's implentations of MM
20:06:42FromDiscord<Lantos> great stuff shashlick!
20:07:01disruptekthat's why i'm glad i'm not a cow.
20:08:36GordonBGooddisruptek: although cow's never worry about being async - they never worry about anything much other than the next bite of feed
20:08:48disruptekare you kidding?
20:09:06disruptekcows live in a veritable crucible of stress over how they'll provide us enough milk.
20:09:20GordonBGoodI am personally acquainted with quite a few cows
20:09:21disruptektalk to a cow sometime.
20:09:26disruptekwell, then you know.
20:09:37shashlickcows are async, they swallow food for later chewing
20:09:39FromDiscord<Lantos> it'd be nice to be a swiss cow. nice fields
20:09:45shashlicknever know what algorithm it uses behind the scenes
20:09:57disruptekthey are multi-core when it comes to digestion.
20:10:04disrupteksome work-stealing going on, to boot.
20:10:12shashlicka really good balance of async and multi-threading
20:10:29disruptekwell, we know async excels at i/o.
20:10:46GordonBGoodIn my personal experience with cows, they never even think that they produce milk, they just feel relief when someone relieves them of it
20:11:59FromDiscord<Lantos> did you say you uploaded an example shashlick
20:12:00GordonBGoodshashlick: I think they just produce futures - not necessary to multi-thread
20:12:22disruptekyep, beef futures.
20:13:04GordonBGoodcows excel at io; food and air in, milk and s..t out
20:13:52GordonBGoodyep, milk and beef futers, but quite a few "andThen's" inbetween
20:14:17clyybberI have to implement a lazy-scheduler, based on the principle that is the opposite of work-stealing
20:14:44clyybberand then watch those lazy fucks do no work
20:15:18*shadowbane joined #nim
20:15:52*shadowbane quit (Client Quit)
20:17:07shashlick@Lantos no just published to nimble directory
20:17:58GordonBGoodclyybber: yeah, lazy/deferred has it's uses, but we need a really good closure implementation to make it work...
20:18:37*shadowbane joined #nim
20:18:38GordonBGoodIt's actually incredible how well the legacy closures work, considering C didn't have them
20:19:06GordonBGood^legacy closures in Nim.
20:25:17GordonBGoodexcuse me for a few hours, middle of the night here
20:27:40clyybberGordonBGood: Oh I wasn't referring to anything, just talking out of my ass
20:28:10clyybberGordonBGood: Good night. I assume you are in asia?
20:28:32GordonBGoodclyybber: yeah, Thailand
20:29:03clyybberHa, nice.
20:29:45GordonBGoodclyybber: can be nice; it can be whatever you make it...
20:30:41GordonBGoodclyybber: pretty good place for entering geezerhood, as I am
20:31:12clyybberA friend of mine used to live in thailand for soem years
20:31:36clyybberthe best thing must be eating coconuts as a whole
20:31:41*nsf quit (Quit: WeeChat 2.6)
20:31:47GordonBGoodI've been here for over 27 years
20:32:15clyybberGordonBGood: rural or urban?
20:33:13GordonBGoodclyybber: I've been both, was on a place on the beach about 12 km out of town, now in a smallish city, about 100,000 pop
20:34:08GordonBGoodBoth have their advantages, outside was more laid back; now everything is convenient, walking distance away
20:35:29clyybberhmm, hows the temperature?
20:35:36GordonBGoodstill just 500 m away from the beach
20:35:44clyybberthats awesome
20:36:42GordonBGoodNot as hot as some places in Asia because of being on the sea - 24 C at night, usually about 33 in the day unless it's raining, when it might be not much above the night
20:37:23clyybberI assume its like that the whole year?
20:37:37clyybberIt's 2 C at night here
20:38:07GordonBGoodYeah, some place in northern Thailand have more definitive seasons, but here we hardly do:
20:38:44GordonBGoodraing season it rains more, but often doesn't - hot season it's mostly clear but might rain
20:39:41GordonBGoodI'm originally from Canada, don't tell me about cold, I'm trying to forget
20:40:08GordonBGoodclyybber: here is EU?
20:40:15clyybberyeah bavaria
20:40:54GordonBGoodAh, nice, never been there but have met lots of ppl from there; I hear it's beautiful
20:42:36clyybberyeah, it's very nice here
20:42:59clyybberthough I feel a kind of sadness whenever the urban industrial areas expand
20:43:57GordonBGoodclyybber: that happens everywhere, including here - 20 years ago one could find lats of undeveloped islands, now almost none
20:45:31GordonBGoodand everytime they improve a road, factories, housing evelopements, businesses rapidly fill in along it...
20:46:34GordonBGoodWhen I first came here, few ordinary people such as teachers had cars, only 100 cc motorcycles, now almost everyone except poor people do
20:48:13GordonBGoodAnyway, my bed is still calling me; chat tomorrow if you like
20:48:17GordonBGoodgn8
20:48:20clyybbergn8
20:49:50clyybberAraq: What to do about cases like `proc newXmlNode(kind: XmlNodeKind): XmlNode =
20:49:52clyybber ## Creates a new ``XmlNode``.
20:49:54clyybber result = XmlNode(k: kind)
20:49:56clyybbery
20:50:45*GordonBGood quit (Read error: Connection reset by peer)
20:50:57clyybberI can't create any defaults this way. I'm not sure how or why this is supported.
20:54:42disruptekwhat do you mean?
20:55:21disruptekit's been that way for months. you can only ever pass it a const.
20:57:56*narimiran quit (Ping timeout: 265 seconds)
20:58:30clyybberbut thats not a const
20:59:10disruptekyes, doesn't it blow up otherwise?
20:59:58disruptekor maybe i'm just confusing this with the case thing.
21:00:11clyybberassignments to fields afterwards would just use nkCheckedField tihnk
21:00:20clyybberso it would error at runtime if its wrong
21:00:42clyybberdisruptek: This is just a case I haven't thought of.
21:01:09clyybberAnd I'm not sure I shoould/can support it without it getting a bit ugly.
21:01:39disruptekyeah it's only clauses that taint and shouldn't.
21:01:43clyybberI mean its no problem with my previous approach that doesn't rely on the discrimininator being constant
21:03:02FromGitter<alehander42> clyybber shouldn't this be a template
21:03:10disruptekignore me. i've been eating blue berry flavored dog treats and thinking they were halloween candy.
21:03:21clyybberalehander42: looks like it to me
21:03:24FromGitter<alehander42> the other option is to autogenerate a `case` which creates
21:03:28disruptekon the plus side, my coat is more luxurious than ever.
21:03:29FromGitter<alehander42> a XmlNode dynamically
21:03:33FromGitter<alehander42> i've done it once i think
21:03:36FromGitter<alehander42> with a genCase macro
21:03:42clyybberalehander42: THat was my previous apprach
21:04:08clyybberBut it creates a runtime impact
21:04:28clyybberBut I find it weird that this is still supported despite the spec saying its not
21:04:35FromGitter<alehander42> https://github.com/alehander42/lang/blob/master/src/tools.nim
21:04:50clyybberthanks
21:05:02FromGitter<alehander42> well, i thought we're left with `const` kind: kind
21:05:31clyybberI thought so too
21:06:01disruptekit's only when you taint it with variant fields that things go haywire.
21:06:18clyybberwhat disruptek says
21:06:20FromGitter<alehander42> from what i see
21:06:24clyybberthe compiler chooses a different path then
21:06:27FromGitter<alehander42> all newXmlNode usages use a const value
21:06:30FromGitter<alehander42> so it should be fine
21:06:33FromGitter<alehander42> with template
21:07:57disruptekhttps://play.nim-lang.org/#ix=20rr
21:08:16clyybberalehander42: You see `Foo(kind: runtime, valuethatdependsonkind: 1)` wont work but `Foo(kind: runtime)` will
21:08:20disrupteki retab'ed it to 8 spaces for ya.
21:09:17disruptekbut the issue is actually that the error occurs on line 15 which doesn't have any fields other than the discriminator.
21:09:57disruptekif you change d to a const, it works.
21:10:23clyybberdisruptek: wtf
21:10:32disruptekyes. that's why it's a bug.
21:10:42FromGitter<alehander42> clyybber well, i gotta admit i dont remember the rationale for the whole thing
21:10:57FromGitter<alehander42> but yeah sounds like a bug
21:11:23disrupteki guess it existed in 19.6 too. i can never find this report when i'm looking for it because i only got bit by it; dumjyl is the one that wrote it up for me.
21:12:03clyybberAraq help us ^\o/^
21:13:13disruptekas i said earlier, i'm okay with variants being tighter, but this is pretty surprising.
21:16:03clyybberkrux02: Hey, does https://github.com/nim-lang/Nim/pull/12555 fix https://github.com/nim-lang/Nim/issues/12282 too ?
21:17:33krux02I don't know yet, since I didn't test it.
21:18:08clyybberOk, might be worthwile to test https://github.com/nim-lang/Nim/issues/12551 too
21:18:13clyybberNot sure if related
21:18:55*eterps joined #nim
21:20:23eterpsWhat is the name of this language construct? -> []=
21:23:34Araq'put' operator
21:23:34disruptekboris.
21:23:45Araqclyybber: help with what?
21:23:51eterpsthanks
21:27:41clyybberAraq: Why xmltree.nim:71 is allowed
21:27:52clyybberproc newXmlNode(kind: XmlNodeKind): XmlNode =
21:27:55clyybber ## Creates a new ``XmlNode``.
21:27:57clyybber result = XmlNode(k: kind)
21:27:59clyybbery
21:28:03clyybberThis ^
21:28:15clyybberBecause clearly k is a runtime value here
21:28:54clyybberAnd as disruptek has shown in his snippet the compiler normally prevents this.
21:29:13Araqthat's still allowed because no other field is set
21:29:39clyybberYeah that makes sense
21:29:47clyybberIt's unfortunate for defaultfields though
21:30:09Araqyeah I can see why
21:30:13FromGitter<alehander42> but why does it make sense
21:30:21clyybberAnd the compiler prevents it sometimes: play.nim-lang.org/#ix=20rr
21:30:58clyybberoh well, playground doesn't work rn
21:31:27clyybberalehander42: Because its safe.
21:31:44disruptekhttps://github.com/nim-lang/Nim/issues/11428
21:31:48Araqclyybber: because DateTime has a requiresInit constraint?
21:31:57AraqI dunno.
21:32:32FromGitter<alehander42> but why is then k: kind, fielddepending: b not safe
21:32:42FromGitter<alehander42> ah nvm
21:33:00FromGitter<alehander42> so then is k: kind, fieldwhichallhave: 2
21:33:02FromGitter<alehander42> ok
21:33:04clyybberAraq: It doesn't
21:33:09Araqit does
21:33:18AraqDateTime contains MonthdayRange* = range[1..31]
21:33:24clyybberAha
21:33:42Araqso effectively the compiler already checks for what you seek to do
21:33:43disruptekjasper explains it a bit in the issue.
21:34:20clyybberAraq: Ok, so I'll disallow that like the compiler already does for defaults
21:34:28Araqyup
21:35:50clyybberAraq: Or should I describe it in the spec that default values of the corresponding branches will just be ingored then?
21:36:09clyybberBecause arguably a default value isn't a constraint like a range
21:36:19clyybberI could make it spit out a warning
21:36:31disruptekbut you could fix this.
21:36:37clyybberdisruptek: How?
21:36:38disruptekbrb
21:40:41disruptekso, maybe you've already fixed this, but it was possible to have an invalid value in a range field.
21:41:20clyybberI can indeed fix it, but with a runtime impact.
21:41:31disruptekor enums, when enums don't start at 0.
21:41:52*Trustable quit (Remote host closed the connection)
21:42:54clyybberdisruptek: Hmm, do you have a link to reproduce?
21:43:00disrupteki guess it could be a check that produces a warning and/or could be disabled.
21:43:53clyybberTheres a certain difference between default values and ranges
21:44:01disrupteki could probably reproduce it locally.
21:44:23clyybberRanges should enforce a value to be initialized to a certain value since the object is invalid otherwise
21:44:32clyybberBut the same is not really true for default values
21:44:36clyybberNot in the same sense
21:44:46clyybberSo I guess spitting out a warning is fine
21:44:52clyybberFor now
21:45:13disrupteki think almost anything is better than having a field that actually holds a value that is invalid for the type.
21:46:21disruptekhttps://gist.github.com/6d75ab0d5a66f3f6c18e99d276499fa4
21:46:59*abm quit (Quit: Leaving)
21:47:17clyybberHmm, this seems easy to fix.
21:47:31clyybberJust do the same thing we already do for ranges, I think
21:47:42disruptekoh, it's fixed for ranges?
21:48:33disruptekwell, you'll break the world if you force init on a non-zero enum.
21:48:58disruptekit's a hard error on ranges right now, looks like.
21:49:01clyybberdisruptek: I didn't check yet, but its the ting that prevented your previous snippet from compiling
21:49:10clyybberdisruptek: Should be the same for enums IMO
21:51:19disruptekyes, but breakage...
21:51:33clyybberwarning first error later?
21:51:56disrupteki don't think there's any other way to do it.
21:52:57clyybberShould it also error for holed enums then?
21:53:10clyybberBecause holed enums can end up in invalid state anyways.
21:53:31disruptekit's only initialization, and only when 0 is an invalid value.
21:56:01FromGitter<alehander42> btw is `default(T)` working with the default values
21:56:36clyybberalehander42: I'm patching default(T) for the whole object
21:57:07clyybberBut not for the fields themselves, because the fields still retain their types, and the object they are in shouldn't affect that
21:59:37*MightyJoe joined #nim
21:59:37*cyraxjoe quit (Ping timeout: 268 seconds)
22:10:31*Vladar quit (Quit: Leaving)
22:16:12*cgfuh quit (Quit: WeeChat 2.5)
22:20:35*solitudesf quit (Ping timeout: 265 seconds)
22:24:55*abm joined #nim
22:37:32*clyybber quit (Quit: WeeChat 2.6)
22:40:25*cyraxjoe joined #nim
22:42:11*MightyJoe quit (Ping timeout: 276 seconds)
22:46:40*cyraxjoe quit (Quit: I'm out!)
22:47:55stefantalpalaruHear me out, guys: Nimbian - a new Linux distribution where you can "aptitude update; aptitude install jester". Source packages, binary packages, dependency resolution using 3-SAT solvers, stable/testing/unstable distro variants, distro images to run inside emulators on lesser platforms, containers to combine and deploy Nim packages in production through state-of-the-art DevOps practices, custom patchsets to rename Glibc's "atexit"
22:47:55stefantalpalaruto "addQuitProc", the works! Who's in? I already have the logo, you guys: https://i.imgur.com/niFyg7t.png
22:48:31stefantalpalaruCan you feel the hype building up? This is it!
22:49:18*cyraxjoe joined #nim
22:49:23disruptekfinally.
22:54:07*MightyJoe joined #nim
22:55:44*cyraxjoe quit (Ping timeout: 268 seconds)
22:57:26*cyraxjoe joined #nim
22:57:30FromGitter<alehander42> man you're way behind
22:57:42FromGitter<alehander42> i expect a nim custom kernel
22:58:19FromGitter<alehander42> with all programs running as async functions and event loop == os scheduler
22:59:14*MightyJoe quit (Ping timeout: 240 seconds)
23:02:15stefantalpalaruPfffft! That's nothing. I'm working on a custom Nim CPU in FPGA with micro-ops that will speed up the Nim VM. I call it "ARniM". No logo yet.
23:03:13disruptekboy, ya give a dog a Hershey's bar and they lose their freakin' mind.
23:04:14*MightyJoe joined #nim
23:04:22*cyraxjoe quit (Ping timeout: 268 seconds)
23:08:05FromDiscord<kodkuce> https://github.com/dom96/nimkernel
23:10:20*ng0 quit (Ping timeout: 260 seconds)
23:12:05*oprypin quit (Quit: Bye)
23:12:13*oprypin joined #nim
23:12:26*abm quit (Ping timeout: 240 seconds)
23:12:29dom96stefantalpalaru, be careful, sometimes you make a joke and 2 years later you somehow end up maintaining a Linux distro
23:15:36stefantalpalaruToo late. I already maintain a Gentoo overlay with 172 packages: https://github.com/stefantalpalaru/gentoo-overlay
23:16:52disruptekchaoslab has a newer ungoogled-chromium.
23:17:12disruptekfor whatever that's worth.
23:17:56dom96this is pretty nice, can we have this? https://twitter.com/andy_kelley/status/1190016044569636864
23:17:59FromGitter<alehander42> i seriously planned doing the nim-program-with-gc-as kernel idea
23:18:07dom96Maybe instead of the distributions which we've already spent far too much energy arguing over?
23:20:00FromGitter<alehander42> hm, how do they do it
23:20:40disrupteki don't think UB in C is all that rare.
23:20:56FromGitter<alehander42> dom96 well be careful with desiring for lang features instead, there is a whole z3 mechanism waiting on
23:21:03disruptekit'll be fun to sort out all the false positives.
23:21:41dom96alehander42: another feature that I don't see myself using I'm afraid to say. :/
23:22:31disruptekit will help performance, convenience, and testing.
23:22:38*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:23:11*abm joined #nim
23:24:05FromGitter<alehander42> well, it would be mostly a separate tool to be honest probably
23:24:05*ng0 joined #nim
23:24:28FromGitter<alehander42> but it has its own very cool usages
23:25:23dom96to be far, it's something someone from our community wants to work on
23:25:28dom96so fair enough
23:28:05FromGitter<alehander42> i worked on some stuff which lets you
23:28:17FromGitter<alehander42> see a "callstack" of the current macro/template expansions btw
23:28:37FromGitter<alehander42> on runtime
23:28:50FromGitter<alehander42> but have to see how hard would it be to upstream something like that
23:29:06*cyraxjoe joined #nim
23:29:16FromGitter<alehander42> mostly useful for stacktraces/debugging
23:30:56*MightyJoe quit (Ping timeout: 276 seconds)
23:30:56disruptekon runtime?
23:33:28FromGitter<alehander42> on runtime
23:34:11FromGitter<alehander42> e.g. you have test "a": check(call() == b) and you can get that call() is in `test` > `check` expansions
23:34:31disruptekis it only calls?
23:34:44FromGitter<alehander42> well, its whatever
23:34:50FromGitter<alehander42> line it is
23:34:59disruptekwhere's the code?
23:35:02FromGitter<alehander42> basically you can also see the expanded actual code
23:35:16FromGitter<alehander42> and compare with differetn expansions until the original
23:35:19FromGitter<alehander42> well
23:35:23FromGitter<alehander42> its not open yet
23:35:35disrupteki'm having trouble imagining how it could be generalized. sounds pretty interesting.
23:35:38FromGitter<alehander42> but i can try to PR when it's readier
23:36:12FromGitter<alehander42> basically we're creating a macro expansion source map and serializing it in the compiler
23:36:25disruptekoh, i guess you could embed a beacon at compile-time and then trigger it at runtime, right?
23:36:27FromGitter<alehander42> not the most genius possible solution but i guess maybe fine for debugging mode
23:36:38disruptekyeah, that's a cool idea.
23:36:44FromGitter<alehander42> thats also an option, probably embedding this source map in the binary would be best
23:36:49shashlick@dom96 - any luck on that PR?
23:37:26FromGitter<alehander42> but we're not really triggering anything: its just a mapping of nim lines to macro/expansion/definition lines
23:37:47FromGitter<alehander42> so one can always just construct a "expand stack" for a given line
23:38:04FromGitter<alehander42> e.g. in gdb as a python command or in a stacktrace
23:38:44disruptekbut you call your macro on the block of code you wanna instrument, right?
23:38:55FromGitter<alehander42> you dont instrument anything
23:39:38FromGitter<alehander42> it should work for existing code with no changes
23:39:55FromGitter<alehander42> the point is you can e.g. step in gdb to a random nim line which is in a macro expansion
23:40:53FromGitter<alehander42> and two things will be different: you'll be seeing the "expanded" code e.g. `echo ``b``` would be `echo 0`
23:41:14FromGitter<alehander42> and you can run a command which would calculate which template expansions you're inside right now
23:41:48disrupteksounds useful.
23:42:33FromGitter<alehander42> probably: when we open the PR, we'll see where the discussion goes
23:44:45*MightyJoe joined #nim
23:46:55*cyraxjoe quit (Ping timeout: 268 seconds)
23:52:06FromDiscord<Nat> hopefully a quick question, is there any way to use a multiline anonymous function with the `=>` sugar like https://gist.github.com/natdempk/8010443b8cd82bf44ac5f3af0d313904
23:53:19FromDiscord<Nat> didn't see too much googling briefly
23:54:52FromDiscord<mratsim> do notation
23:55:38FromDiscord<mratsim> see: https://forum.nim-lang.org/t/5431 @Nat
23:56:12FromGitter<alehander42> i'd guess that multiReplace
23:56:18FromGitter<alehander42> from strutils might be easier for your usecase
23:57:04FromGitter<alehander42> with fewer allocations
23:57:30FromDiscord<Nat> I think it's required that I throw for invalid chars
23:57:37FromDiscord<Nat> but cool to know that exists 🙂
23:57:40FromGitter<alehander42> even with additional check for invalid chars
23:57:44FromGitter<alehander42> it should be faster
23:58:28FromGitter<alehander42> as you're copying just one string and then doing a replace + maybe one loop, not constructing a sequence and then a new string with join
23:58:40FromGitter<alehander42> but i might be wrong, best to benchmark
23:59:27FromDiscord<Nat> yeah that's interesting to know, I'm also just doing toy problems to learn the language a bit so not super interesting in the most performant stuff atm
23:59:36FromDiscord<Nat> still trying to wrap my head around the basics