<< 01-11-2019 >>
00:03:39FromGitter<alehander42> ok
00:03:40FromGitter<alehander42> sorry
00:03:47FromGitter<alehander42> in this case you can put `()` around the case
00:03:50FromGitter<alehander42> and it works
00:03:55FromDiscord<Nat> no worries, I appreciate the help!
00:04:22FromGitter<alehander42> around the whole case multiline
00:05:34FromGitter<alehander42> another variant is to use `do ` as mratsim suggests, but then you need `()` around the whole toSeq expr
00:05:48FromGitter<alehander42> and `do` might be deprecated in the future
00:06:37FromGitter<alehander42> also you need to import sugar
00:06:49FromGitter<alehander42> because `=>` is a helper defined there
00:06:53FromGitter<alehander42> (syntax sugar module)
00:07:01FromDiscord<Nat> Not sure I understand the wrapping the case statement, it seems like something like https://gist.github.com/natdempk/31fc44cb3c195cf015113f2bb859be5f doesn't work
00:07:11FromDiscord<Nat> ah
00:07:16FromDiscord<Nat> it was the import sugar, thanks!
00:08:14FromDiscord<Nat> thanks for the help 🙂
00:08:30FromGitter<alehander42> no problem
00:08:53FromDiscord<Nat> slowly working through the exercism nim stuff
00:09:41FromGitter<alehander42> if you are interested in using it for bio stuff, you can always take a peek at https://github.com/brentp (many bio-related nim )
00:09:48FromGitter<alehander42> ah, if its exercises, great
00:10:07FromDiscord<Nat> yeah just basic coding exercises to learn the language
00:10:14FromGitter<alehander42> ook
00:10:19FromDiscord<Nat> not serious bio stuff 😛
00:17:09*couven92 quit (Quit: Client Disconnecting)
00:32:15FromGitter<Willyboar> @federico3 are you here?
00:34:32FromGitter<Willyboar> @VPashkov are you abandon awesome_nim?
00:42:49federico3not much :)
00:44:57*nixfreak quit (Ping timeout: 240 seconds)
00:46:11*ng0 quit (Quit: Alexa, when is the end of world?)
00:46:17*krux02_ joined #nim
00:49:03*krux02 quit (Ping timeout: 245 seconds)
01:29:34*krux02_ quit (Remote host closed the connection)
01:38:50*lritter quit (Quit: Leaving)
01:45:19*Jjp137 quit (Ping timeout: 268 seconds)
01:47:25*Jjp137 joined #nim
02:10:57FromDiscord<LinuxTerm> hi
02:14:04FromDiscord<Rika> hello
02:42:21rayman22201anybody online that knows how to get -d:nimTracing to work?
02:43:10disruptekwhat is it?
02:44:34rayman22201extra debugging in the garbage collector code
02:45:02rayman22201I think only Araq really knows but my timezone is wrong :/
02:45:18disrupteki've done some gc debugging but i'm not very familiar with it, and i don't believe i've used nimTracing.
02:46:25disruptekgrep says it's there but you need hasThreadSupport.
02:47:28rayman22201hrmmm. I will try it
02:47:37rayman22201apparently I don't grep as well as you lol
02:47:56disruptekwell, it's under the when at L29 in gc_ms.nim.
02:48:12disrupteksorry, that's wrong. i'm dumb.
02:48:18*nif quit (Quit: ...)
02:48:28*nif joined #nim
02:48:34disruptekcouldn't read my screen. 😁
02:48:37rayman22201wait, wat lol
02:48:39rayman22201ok then
02:48:54disruptekbut still, it's clear that it's used in there.
02:49:06disruptekjust, y'know, doesn't seem that you need hasThreadSupport.
02:49:30rayman22201I don't want to turn on threads unless I need to, since I'm debugging the GC, and threads just make everything more complicated
02:49:31leorizegcTracing probably only works with --gc:markandsweep
02:49:37rayman22201that is correct
02:49:42rayman22201and I am using markandsweep
02:49:52rayman22201but I am not using threads
02:50:27disrupteki think it's working.
02:50:43rayman22201what is lol?
02:52:21disruptek/home/adavidoff/git/Nim/lib/system/gc_ms.nim(370, 48) Error: undeclared identifier: 'stdout'
02:52:32rayman22201that's the error I get. congrats lol
02:52:46disruptekso open a file somewhere.
02:53:19rayman22201solve any problem. just open a file somewhere :-P
02:53:22disruptekgotta reorder things so you have io.
02:54:02rayman22201it's ok. I have other ways to get what I need. I just thought I would ask if anybody had the easy way working
02:54:15rayman22201the point is not to rewrite my own debugging code if some is already there
02:54:32disruptekyeah, i was surprised stdmsg() didn't work.
02:55:44*leorize quit (Ping timeout: 260 seconds)
02:58:51disrupteki don't think this has been used in a long time.
02:59:20rayman22201yeah :/
02:59:22rayman22201oh well
02:59:46disruptekjan of last year isn't that long ago i guess.
03:00:10*leorize joined #nim
03:00:55leorizeit's probably was broken by the io.nim split
03:01:08rayman22201ahhh. that makes sense
03:01:40rayman22201good news. I think I made good progress on fixing async so it works with araqgc now. Bad news, I think I found a boehm bug :-/
03:02:03leorizeyou made it work with araqgc?
03:02:10disruptekif it's a bug in boehm, that's pretty great news.
03:02:14rayman22201modulo bugs :-P
03:02:16leorizeI guess --gc:destructors is gonna be the next gc :p
03:02:26leorize--newruntime failed :P
03:03:39rayman22201It could be a bug in my fix, but if I insert an `await sleepAsync(1)` in the test, it suddenly works.
03:03:55rayman22201This makes me think it's a boehm bug, and not a bug in my async impl.
03:04:40rayman22201but I think I need Araq super powers to figure out in more detail what is happening
03:06:05rayman22201Thanks peeps. bbl
03:15:27*GordonBGood joined #nim
03:34:10disruptekif there's one thing i cannot abide, it's tornados.
03:42:51*disruptek quit (Ping timeout: 252 seconds)
03:43:06*snooptek quit (Ping timeout: 268 seconds)
03:49:51*jwm224 quit (Ping timeout: 264 seconds)
03:55:36yumaikashttps://github.com/yumaikas/comic-trakr tiny website in Jester I just made, if anyone is interested
04:03:39*oscar1 joined #nim
04:04:58*dchem joined #nim
04:06:03dchemhi everyone
04:18:40leorizeo/
04:20:22*dchem quit (Quit: WeeChat 2.4)
04:20:49yumaikasleorize: you read webcomics much?
04:23:04*abm quit (Quit: Leaving)
04:23:43leorizeno :P
04:24:42*oscar1 quit (Quit: WeeChat 2.4)
04:25:35skrylar[m]hastyscribe looks a lot like multimarkdown 😉
04:29:15*rockcavera quit (Remote host closed the connection)
04:37:26*nsf joined #nim
04:51:03*dchem joined #nim
04:59:50*chemist69 quit (Ping timeout: 276 seconds)
05:01:13*chemist69 joined #nim
05:10:39*dchem quit (Quit: WeeChat 2.4)
05:49:22*dchem joined #nim
06:29:42*Trustable joined #nim
06:33:13*lj00nal joined #nim
06:34:33*MightyJoe quit (Ping timeout: 265 seconds)
06:35:05*cyraxjoe joined #nim
06:35:38*ljoonal quit (Ping timeout: 240 seconds)
06:38:33Araqrayman22201: so what did you find out?
06:46:13*zombiefisch is now known as qwertfisch
06:52:59*kevin_ joined #nim
06:53:31*narimiran joined #nim
07:00:00*gmpreussner_ quit (Quit: kthxbye)
07:04:53*gmpreussner joined #nim
07:08:28*dchem quit (Quit: WeeChat 2.4)
07:17:02GordonBGoodAraq, can you or anyone help me understand why TestObj captured in a temporty closure isn't showing as testroyed? - https://gist.github.com/GordonBGood/9971e9ccca6ecef010f925f3d057e701
07:17:43GordonBGoodDoesn't seem to matter what GC used, so not really related to ref counting...
07:17:58GordonBGoodJust me investigating closure environments
07:18:15GordonBGood^ temporary closure
07:20:00GordonBGoodOutside closures, ref's internal to proc's get destroyed as expected, whether elements of seq's, fields of objects/tuples, etc.
07:21:16GordonBGoodI understood that closure environments are ref's, thus the investigation...
07:21:56GordonBGoodOr are closure environments ptr's and somehow the automatic destruction isn't being triggered?
07:24:32GordonBGoodAraq, also trying to generate a MCVE of the "nested closure" problem with my test program from yesterday that is a problem to do with --gc:destructors/ref counting, but...
07:24:54GordonBGoodSo far I haven't come up with anything simpler than that "hammings" test program
07:25:36*PMunch joined #nim
07:28:15*theelous3 quit (Ping timeout: 264 seconds)
07:36:37*theelous3 joined #nim
07:40:11*solitudesf joined #nim
07:45:57*ftsf joined #nim
07:51:33PMunchHmm, seems like rebuilding the playground images didn't go as planned
07:52:24PMunchplay.nim-lang.org/versions replies with {"versions":["Segmentation fault"]}
07:52:56ftsfhmm is it expected that certain procs won't show up in a stacktrace on error? I'm getting an AssertionError when calling del on a seq, but the proc that calls del doesn't show up in the stacktrace, nor does del. (iterators delete does though)
07:59:47Araqftsf: templates have no stack entry due to their inlining semantics
07:59:54Araqbut procs are usually not missing
08:00:19FromDiscord<Lantos> @shashlick nimgraphql seems to be creating a empty folder in any nimible projects even if it dosen't have nimgraphql
08:00:24ftsfhmm, definitely procs in this instance, i'll try narrow down the case and file an issue
08:01:50FromDiscord<Lantos> @benjikun I was able to run the tests in nimetry but can not import it in other projects. I have run nimble install nimetry and also using cpp backend
08:03:54*gmpreussner_ joined #nim
08:04:27*gmpreussner quit (Ping timeout: 265 seconds)
08:06:13*kungtotte joined #nim
08:06:19GordonBGoodAraq: Got it, a MCVE showing the nested closure problem with --gc:destructors/ref counting - https://gist.github.com/GordonBGood/705a1faa51eabb72514b6b976d5dc47d
08:09:18*nif quit (Quit: ...)
08:09:29*nif_ joined #nim
08:10:29FromDiscord<Lantos> I think it might have to do with my nimble pkg dir setup
08:14:30GordonBGoodAraq: on investigating the proc `symToClosure` with my comments after you left last night starting at - https://irclogs.nim-lang.org/31-10-2019.html#19:41:48
08:15:47GordonBGoodAraq: I'm running the MCVE gist on devel of two days ago, as yesterdays commits seem to be unreleated
08:18:58ftsf@Araq, aha, it is showing in the stacktrace, but with the wrong filename https://gist.github.com/ftsf/4e354e33e43d697d659c62fee781212c (bar says it's in iterators.nim, not nimseqdel.nim) or am I misreading the stacktrace?
08:23:38*dddddd quit (Remote host closed the connection)
08:28:56Araqftsf: it is nothing new, hard to fix/improve
08:29:21AraqGordonBGood: I wrapped your top level statements in a 'main' proc
08:29:24Araqthen I did:
08:29:30ftsfAraq, okay
08:29:31Araqconst toDebug = "main"
08:29:39Araqin injectdestructors.nim
08:29:43Araqand ran:
08:29:57Araqkoch temp c --gc:destructors -r temp.nim
08:30:07Araqand it doesn't inject destructors, that's why :P
08:32:15Araqsome logic needs to be adapted
08:32:36AraqcanBeMoved() is also suboptimal for --gc:destructors
08:35:23*kevin_ quit (Ping timeout: 265 seconds)
08:37:42FromDiscord<Lantos> cant find it whats the best way to turn "30" to 30'f32
08:37:44FromDiscord<Lantos> cant find it whats the best way to turn "30" to 30'f32?
08:37:58FromGitter<alehander42> parseFloat + float32
08:38:05FromGitter<alehander42> ?
08:38:16FromDiscord<Lantos> tried cast[float](string) no work
08:38:36FromGitter<alehander42> well, cast works only when the memory representation would be valid for both types
08:38:44FromGitter<alehander42> a string "30" looks very different to a float
08:38:52FromGitter<alehander42> you need to use a parsing function
08:39:04FromGitter<alehander42> from strutils
08:39:18FromDiscord<Lantos> float(int) -> float works fine
08:39:18FromDiscord<Lantos> float(str) -> ~~~~
08:39:32FromGitter<alehander42> ok, please read my suggestion
08:40:17FromGitter<alehander42> sorry
08:40:31FromGitter<alehander42> i understand: you expect the python behavior
08:40:41FromDiscord<Rika> lantos are you having internet issues perhaps?
08:40:44FromGitter<alehander42> here `(type)(value)` is something different: its a type conversion
08:41:11FromDiscord<Lantos> import strutils
08:41:11FromDiscord<Lantos> parseFloat()
08:42:33FromGitter<alehander42> yes
08:42:54PMunchLantos: https://play.nim-lang.org/#ix=20tr
08:42:56FromGitter<alehander42> honestly this is a good question: i cant fully explain what is the big difference between type conversions and the `parse` family
08:43:08FromGitter<alehander42> and why e.g. `float()` works for int, not for string
08:43:29PMunchWell, int->float will always work, string->float not so much
08:43:32FromGitter<alehander42> it makes sense to me as a simpler operation but not sure about the rationale
08:43:54FromGitter<alehander42> well, not sure: e.g. you can write int(floatvalue) iirc
08:44:11FromGitter<alehander42> and if you write int16(float64value)
08:44:23FromGitter<alehander42> i guess it works in a sense, but hm
08:44:25PMunchParse is about taking something and reading some information out of it. Type conversions just change things between representations (potentially lossy)
08:44:42FromDiscord<Lantos> best way to handle errors on this?
08:44:55FromDiscord<Lantos> https://play.nim-lang.org/#ix=20ts
08:45:18PMunchLantos, depends on where you are using it..
08:45:32FromGitter<alehander42> good question
08:45:40FromDiscord<Lantos> uhhh to default to 0
08:45:46FromGitter<alehander42> people often dont think that similar primitives can fail
08:45:55FromDiscord<Lantos> like js short circuit
08:46:27FromDiscord<Lantos> var s = parseFloat("") || 0;
08:47:04FromGitter<alehander42> hm, well honestly you would need to define your own wrapper for that
08:47:22PMunchhttps://play.nim-lang.org/#ix=20tt
08:47:50FromDiscord<Lantos> thanks punch man 🙂
08:48:05FromGitter<alehander42> : hehe
08:48:21PMunchOr if you want to use `||`: https://play.nim-lang.org/#ix=20tu
08:48:26*kevin joined #nim
08:48:46PMunchNice side-effect of Nim returning the last value in a block if it makes sense :)
08:48:49*kevin is now known as Guest47739
08:49:30PMunchSame reason ternaries in Nim are just regular if statements
08:50:41PMunchI tend to abuse that quite a bit, assigning things with `let` through an if statement instead of defining a `var` and then have an if statement that assign it.
08:55:32PMunchExample of the benefits of using let and ternaries: https://play.nim-lang.org/#ix=20tw
08:56:34PMunchOr not ternaries, but rather the implicit return from if blocks :)
08:56:59PMunchThis of course also works for case statements, and try blocks as you saw earlier
08:59:53PMunchAnd `block` statements for that matter, so you can create temporary variables that doesn't stick around: https://play.nim-lang.org/#ix=20ty
09:04:59GordonBGoodAraq: does "and it doesn't inject destructors" refer to my first question on why closure environments arn't destroyed?
09:05:22Araqyes, but looking further at it, it seems correct
09:05:46Araqyou don't capture anything let clsr = () => (...)
09:05:55GordonBGoodFor that one, I can't get TestObj to show it being destroyed with run with default GC either
09:06:45Araqmoving TestObj containing from/to: 42 0
09:06:45Araqdestroying TestObj containing: 0
09:06:53Araqit does destroy it.
09:06:57GordonBGoodThat clsr doesn't capture, but the "tst" value inside the body is a closure that has captured "c", a TestObj
09:07:38Araqwell it's destroyed too early
09:07:55GordonBGoodThat's when the TestObj is moved into the closure and destroys the default zero it replaces
09:08:02*Vladar joined #nim
09:08:39Araqgosh write tests that are not convoluted messes please
09:09:52GordonBGoodFirst it is created as a temp containing 42, then that is copied into the closure, destroying the 0 that was there; there are no other destructions ever
09:10:37GordonBGoodI tried to make it simpler; but couldn't come up with a way to show when closure environments are destroyed...
09:11:49GordonBGoodthe reason for the global clsr is that global values don't get destroyed; I should have just wrapped it all in a maiin and called that as you have done
09:12:13GordonBGoodYou can then eliminate the indirection of the extra outer clsr
09:13:19Araqvar tst
09:13:19Araqtry:
09:13:19Araq `=sink`(tst, makeInnerClosure())
09:13:21Araq write(stdout, "as obtained: ")
09:13:23Araq tst()
09:13:25Araqfinally:
09:13:27Araq `=destroy`(tst)
09:13:31GordonBGoodI made the `=destroy` and `=sink` hooks so I could tell when TestObj was being destroyed and why (the only time is the result of the move)
09:13:53Araqso it kinda works but the =destroy for 'tst' is likely wrong or empty
09:21:39GordonBGoodAraq: tried it your way inside a main() with var tst: () -> void - still don't see any extra destructor messages, and it's not to do with --gc:destructors, I ran default
09:22:18GordonBGoodthe only destrution is as a result of the `=sink`
09:22:59GordonBGoodI tried an explicit call to `=destroy` before with no difference just as here
09:31:14GordonBGoodAraq: it seems to me there is a severe memory leak to do with closure environments, and it's not limited to --gc:destructors...
09:32:28GordonBGoodI changed TestObj to include a "big" field of a million int's, chaned to printing to only print cntnts, even added a GC_fullCollect in the finally, then...
09:33:21GordonBGoodtook the difference in getOccupiedMem between the beginning and end of mem and the difference is 8 million bytes (64-bit compile)
09:35:08Araqrun it in a loop and watch its stable memory usage
09:35:09GordonBGoodThe added "big" field of TestObj is an array[1024*1024, int]
09:35:41GordonBGoodOkay, just a mo
09:40:06Araqthe bugs we're hunting are all new, the old stuff works
09:42:43GordonBGoodYou're right, with the default GC, memory usage goes up 8 meg and doesn't continue up for repeated loops; the only question there is when the actual destruction is being done and why aren't we seeing the messages
09:43:49GordonBGoodWhen I run the same looping program with --gc:destructors, it crashes after the first loop with "[FATAL] unpaired dealloc", which should give some clues
09:47:38FromDiscord<Lantos> An attempt at templates mpunch
09:47:38FromDiscord<Lantos> https://play.nim-lang.org/#ix=20tI
09:48:41FromDiscord<Rika> @Lantos convert x into a bool, somehow
09:48:49FromDiscord<Rika> nim doesnt have truthiness
09:49:02FromDiscord<Rika> (i think it doesnt...)
09:51:14GordonBGoodAraq: now I don't even need a loop to get the "[FATAL] unpaired dealloc" error, it is generated by the finally call to `=destroy`
09:53:27FromDiscord<Rika> ok lantos disregard what i said, i misread the error
09:54:01PMunchLantos, sorry you didn't ping me correctly so I didn't see this until now: https://play.nim-lang.org/#ix=20tK
09:54:42PMunchThe error is a bit odd, but essentially the if block can't return anything if it doesn't have an else part. Otherwise it wouldn't be guaranteed to return anything
09:54:57GordonBGoodAraq: so I eliminated the finally call to `=destroy` and ran the loop and memory use stabalizes at 72 bytes - there are just two things...
09:55:40PMunchThis might be a more generic solution: https://play.nim-lang.org/#ix=20tM
09:56:16GordonBGoodJust as for the default GC, why don't we see destruction messages for TestObj (if it isn't being destroyed and contained pointers to the heap, that would cause memory leaks), and...
09:56:23PMunchEssentially that default(typeof(y)) will return the default value of the type of y if the check fails. So 0 for numbers, and an empty string or seq for those.
09:57:07PMunchOf course in this case I guess you might've wanted a raise statement there instead
09:57:11GordonBGoodif the closure environment has already beed deallocated, why is it not also nil'ed so that it can't be done again by `=destroy`?
09:57:20*gmpreussner joined #nim
09:58:02*gmpreussner_ quit (Ping timeout: 265 seconds)
09:59:48PMunchLantos: something like this: https://play.nim-lang.org/#ix=20tN
10:04:18GordonBGoodAraq: it seems to me that there is a memory leak for closures that has been lurking...
10:05:10GordonBGoodWhoops, maybe not, just let me check again
10:08:33GordonBGoodNope, it seems the leak is real: I changed the "big" field to an allocation of a megabyte per TestObj, and deallocated the pointer when not nil as part of the `=destroy`...
10:09:15GordonBGoodThe closure environment is being deallocated, but it's not calling through the the environment contents destructors...
10:09:54FromDiscord<Lantos> Lol I am actually so surprised how well and readable that is @PMunch even when reading from my phone.
10:09:54FromDiscord<Lantos>
10:09:54FromDiscord<Lantos> How is nim not used more then it is?
10:10:17GordonBGoodSo memory use increases by a megabyte per loop for GC or --gc:destructors
10:12:02*ZORR0W joined #nim
10:12:25*ZORR0W quit (Client Quit)
10:16:26GordonBGoodAraq: for both --gc:refc and --gc:destructors, resource monitor agrees that memory use continually increase by a megabyte per loop over the duration of the run, after which if drops back to normal
10:18:03GordonBGoodIt seems to me that the problem is that the calls to the environment contents destructors is not being injected before the closure environment is deallocated, leaving the potential for a leak
10:18:49PMunchLantos, beats me. Nim is a great language :)
10:20:53FromDiscord<Rika> @Lantos lack of endorsement
10:21:04FromDiscord<Rika> Also no major company sponsor I guess?
10:21:19FromDiscord<Rika> Rust has Mozilla, golang has Google
10:21:36FromDiscord<Rika> No company comes to mind for Nim
10:21:48FromDiscord<Rika> That might be a factor
10:22:10FromDiscord<Chiqqum_Ngbata> Some things are just too cool for school
10:24:47*disruptek joined #nim
10:35:16GordonBGoodAraq, this problem has been lurking since forever, but isn't a problem for normal use, as the GC takes care of ref's eventually, and there was special logic for legacy strings and seq's to make them treated as ref's...
10:36:41GordonBGoodAlso, before destructors, if an inner field wan't a ref's programmers would ahve used the finalizer to take care of it when it was GC'ed...
10:37:08GordonBGoodHowever, now that we want/need to depend on destructors, the bug pops into play
10:38:11FromDiscord<Lantos> A magor sponsor is important. From someone from the outside. It looks like a project that is the hobby of a lot of really smart guys. At the same time v is fairly new but has a lot of movement behind it
10:38:38FromDiscord<Lantos> A major sponsor is important. From someone from the outside. It looks like a project that is the hobby of a lot of really smart guys. At the same time v is fairly new but has a lot of movement behind it
10:39:21*clyybber joined #nim
10:39:55PMunchOh, by the way Lantos, whenever you edit a message on Discord the entire thing is resent to IRC..
10:40:23FromDiscord<Lantos> Oh okay will, double check my post before sending 👍
10:40:33PMunchDoes V really have a lot of movement behind it? It got a lot of hype, but I haven't heard of anyone actually using it
10:41:40FromDiscord<Lantos> Yeah I guess, more so hype. Id like to see it reach 1.0
10:48:33*jjido joined #nim
10:54:35*thomasross quit (Ping timeout: 265 seconds)
11:05:13*narimiran quit (Ping timeout: 265 seconds)
11:22:55FromGitter<alehander42> i dont know, i think the sponsor thing is a bit overrated sometimes
11:23:02clyybberyeah
11:23:28FromGitter<alehander42> i'd prefer a multitude of smaller companies/people helping
11:23:38FromGitter<alehander42> similarly to languages like python/ruby etc
11:23:49FromGitter<alehander42> (ok, they also have big sponsors, but not a main one)
11:23:53PMunchDefinitiely, but I think having one big company shows other companies that it is worth trying
11:24:11PMunchSo it's easier to get quick adoption
11:24:39PMunchPython really is the odd man out in the programming language game, it just sorta got popular over time. Without any large bump
11:25:07clyybberI prefer a language thats loved by the people over one thats loved by managers
11:25:34PMunchOh course, but it doesn't help that it's being loved by programmers if they aren't allowed to use it
11:26:10clyybberPMunch: In the case of python its so simple so they use it in their free-time and eventually it will spill into the work environment
11:26:49*Guest47739 quit (Remote host closed the connection)
11:26:50*solitudesf quit (Ping timeout: 268 seconds)
11:27:41PMunchYeah, Python just sorta got popular because people used it a lot. And I can see something similar happening for Nim
11:27:49clyybberdisruptek: why did you leave offtopic :(
11:27:49*Vladar quit (Quit: Leaving)
11:28:17PMunchWhen I started this job I actually found a guy who used Nim a bit, and was experimenting with using it for work stuff as well :)
11:28:30clyybberHuh, cool :D
11:29:01FromDiscord<Rika> `No variable shadowing` woah V sounds monakshake
11:30:14clyybberwth is monakshake?
11:30:34FromDiscord<Rika> sorry just some dumb emote i got a habit of using
11:30:44clyybber:monakshake:
11:30:49PMunchYeah I was a bit surprised actually. And it was sorta the perfect use case, he was writing installers, and the language the installer framework used was Pascal-script (which is just a horrible version of Pascal). But it also offered the possibility to load and use DLLs, so he was looking for a language to replace C for creating DLLs. Just to implement some simple logic stuff and system calls to not have to use Pascal-script.
11:31:25PMunchUnfortunately creating DLLs isn't all that trivial.. Maybe that should be my next article
11:33:15*theelous3 quit (Ping timeout: 265 seconds)
11:51:02*chemist69 quit (Quit: WeeChat 2.6)
11:54:52FromDiscord<mratsim> and the next one after DLL should be hot code reloading 😉
11:56:09FromDiscord<Lantos> I see that v doesn't have macros but after using the template it makes me wond why no macros
11:57:22*clyybber quit (Quit: WeeChat 2.6)
11:58:17FromDiscord<mratsim> @Araq I'm confused by the pure refcounting gc for gc:destructors, where does the Bacon goes then? or will the refcounting GC turned into Bacon once it's ready?
11:59:54FromGitter<kaushalmodi> Hello all
12:00:13FromGitter<kaushalmodi> Just came by to say thanks once again for this aweso
12:00:21FromGitter<kaushalmodi> *awesome language
12:02:27PMunchHi kaushalmodi, what're you up to?
12:02:32FromDiscord<mratsim> @Lantos Nim will be sponsored by Oracle soon: https://forum.nim-lang.org/t/5438
12:02:53FromDiscord<Rika> OOOH
12:03:06FromDiscord<Rika> baited :/
12:03:18FromGitter<kaushalmodi> PMunch: Just too busy with work
12:04:06FromGitter<kaushalmodi> But still playing with Nim.. I occasionally git pull to the latest and keep on using it. No breaking issues so far, which is nice.
12:04:24FromDiscord<mratsim> still using for SystemVerilog interop?
12:04:24*chemist69 joined #nim
12:04:34FromGitter<kaushalmodi> Everyday!
12:04:48*rockcavera joined #nim
12:04:55FromGitter<kaushalmodi> It's heart of the test bench that I've set up
12:05:01FromDiscord<mratsim> nice 🙂
12:05:25FromGitter<kaushalmodi> Now there's me and one more Nim coder at work
12:06:10FromDiscord<mratsim> spreading the word I see 🙂
12:06:36FromGitter<kaushalmodi> Just yesterday I was playing with plotting of data sent over to Nim from SV: https://github.com/kaushalmodi/nim-systemverilog-dpic/blob/master/plot/README.org
12:07:23*krux02 joined #nim
12:17:07PMunchOh cool, so I'm not the only one who tries to sneak Nim in at work :P
12:19:50*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:22:28FromDiscord<Lantos> hahaha the baits
12:23:26*nsf quit (Quit: WeeChat 2.6)
12:24:28FromDiscord<Lantos> I'm going to try sneak nim in
12:24:41FromDiscord<Lantos> Some other dev is trying to sneak moonscript in
12:26:19FromDiscord<Rika> moonscript >_>
12:31:42*thomasross joined #nim
12:35:08FromDiscord<Lantos> ```
12:35:08FromDiscord<Lantos> hello = (name) => (print name)
12:35:08FromDiscord<Lantos> hello("meme")
12:35:08FromDiscord<Lantos> ```
12:35:08FromDiscord<Lantos> ```
12:35:09FromDiscord<Lantos> local hello
12:35:09FromDiscord<Lantos> hello = function(self, name)
12:35:09FromDiscord<Lantos> return (print(name))
12:35:10FromDiscord<Lantos> end
12:35:12FromDiscord<Lantos> return hello("meme")
12:35:12FromDiscord<Lantos> ```
12:40:17PMunchAgain, plase don't paste directly..
12:41:03PMunchHmm, I have a curious bug. The .so build works flawless. But when I cross compile to Windows it does something weird
12:41:36FromGitter<alehander42> https://github.com/nim-lang/packages/pull/1233
12:41:42PMunchI change the value through a pointer, but when I try to access that value in the calling code it is still 0..
12:41:56FromGitter<alehander42> hm, so what should we do when package name is taken
12:42:26PMunchAsk him to rename I guess
12:42:43*ng0 joined #nim
12:46:45FromGitter<Willyboar> @alehander42 nothing. CI fails because name exists.
12:49:24FromGitter<Willyboar> Sorry i thought you are norm owner. Send him a message to change the name is the better solution. :)
13:04:26*GordonBGood quit (Ping timeout: 240 seconds)
13:07:27*GordonBGood joined #nim
13:17:50*thomasross quit (Ping timeout: 268 seconds)
13:22:49*jjido joined #nim
13:28:23FromDiscord<Lantos> Is that you Jonas? Someone take the norm name already?
13:33:55*NimBot joined #nim
13:34:39GordonBGoodmratsim: Araq says that ref counting and cleaning up GC is for Nim version 1.0; looking for ways to combing the use of B/D for Nim version 2.0 - https://irclogs.nim-lang.org/31-10-2019.html#09:51:49
13:37:39GordonBGoodmratsim: he is thinking of ways to combine ref counting and even cycle detection with B/D, but they perhaps aren't clear and haven't been tried yet
13:40:22*lritter joined #nim
13:52:39*shadowbane quit (Quit: Konversation terminated!)
13:53:59PMunchHmm, is there anything comparitve to offsetof in Nim?
13:55:00*hed0n1st joined #nim
13:56:50*ftsf quit (Ping timeout: 240 seconds)
14:06:16*ng0_ joined #nim
14:08:40*ng0 quit (Ping timeout: 260 seconds)
14:08:41leorizePMunch: system.offsetof?
14:09:05PMunchOh
14:09:11PMunchThat simple, eh :)
14:09:38*GordonBGood quit (Ping timeout: 268 seconds)
14:09:48PMunchAraq, I remember you mentioning once that the result variable could be directly set in the callers stack. Is this actually done? I look at the generated C code and it appears just like a regular variable.
14:11:17*ng0_ is now known as ng0
14:25:21*thomasross joined #nim
14:28:19*testgovno[m] quit (Quit: 30 day idle timeout.)
14:36:26AraqPMunch: it is done if the codegen thinks it's a good idea
14:39:44*solitudesf joined #nim
14:44:52PMunchAha
14:45:17PMunchAnd what conditions would make it think that it's a good idea?
14:57:13PMunchAha, my DLL issue seems to be what I expected. Somehow my value definition produces different results on Windows and linux
14:57:20PMunchNow just to figure out which field causes it..
14:57:39FromDiscord<mratsim> How come I don't find any paper on MPSC channels/queues backed by a ringbuffer :/
15:06:21*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:08:58PMunch@Lantos, you inspired me to write a little article on implicit return values: https://peterme.net/tips-and-tricks-with-implicit-return-in-nim.html
15:09:06FromGitter<kaushalmodi> Is there a way to specify the nimble path? (not append)
15:09:31FromGitter<kaushalmodi> e.g. `--noNimblePath` removes all nimble pkg paths, while `--NimblePath` appends to existing nimble paths
15:10:07FromGitter<kaushalmodi> I am maintaining two separate nimble pkgs directories (bleeding edge and stable) and I would like `nim` binary to pick one of the two. How do I do that?
15:10:20*filcuc joined #nim
15:10:21*PMunch quit (Quit: Leaving)
15:10:29FromGitter<kaushalmodi> By default, I have the bleeding edge nimble path as the default `~/.nimble/`.
15:11:28FromGitter<kaushalmodi> But for work stuff deployment, I am maintaining a separate nimble directory. If I run `nim --NimblePath:/stable/path`, nim still pulls in the bleeding edge version of a nimble pkg from the default ~/.nimble dir
15:11:36FromGitter<kaushalmodi> Any good solution?
15:12:49*rockcavera quit (Remote host closed the connection)
15:14:55*snooptek joined #nim
15:16:14disruptekkaushalmodi: no solution. it's something we've been discussing recently.
15:18:08FromGitter<kaushalmodi> hmm, I am using this ugly workaround until then: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dbc4cb0bbdf5f17b420b286]
15:19:06FromGitter<kaushalmodi> @Araq May be we need a `--NimblePathOverride`
15:19:35FromDiscord<mratsim> @kaushalmodi: export NIMBLE_DIR=path/to/nimble
15:19:51FromGitter<kaushalmodi> oh, that will replace the default nimble dir?
15:19:55FromGitter<kaushalmodi> *trying it now*
15:20:01disruptekwhoa.
15:20:32FromDiscord<Rika> PMunch, your blog or site looks nice
15:20:40disruptekso there's actually 6 things that need to be deprecated and replaced with a single api. 🤣
15:21:23FromDiscord<Rika> disruptek is there something wrong with your client, some messages get sent with garbage data at the end
15:21:41disruptekit's an emoji.
15:21:50disruptekit's the garbage data emoji.
15:22:02FromDiscord<mratsim> makes sense
15:22:16FromDiscord<Rika> are you using unicode?
15:22:16disruptekit would have to be, right?
15:22:33disruptekunicode makes my nipples throb.
15:23:19*thomasross quit (Ping timeout: 265 seconds)
15:23:32FromGitter<kaushalmodi> @mratsim That env var did not work.. tried setting it to /path/to/nimbledir and also /path/to/nimbledir/pkgs
15:25:18*shadowbane joined #nim
15:25:41FromGitter<kaushalmodi> even though that `nimbledir/pkgs/` has `nimterop-#head/` dir, I get: ⏎ ⏎ > Error: cannot open file: nimterop/cimport
15:25:47*sedfox quit (Ping timeout: 276 seconds)
15:29:01disruptekjust get rid of your ~/.nimble/pkgs. it'll cause nothing but problems because the compiler cannot be made blind to it.
15:29:27disruptekonce that's gone, you can achieve package local deps.
15:30:23FromGitter<kaushalmodi> looking into source: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ My guess is that `pass==passPP` (whatever that means) is false and so the NIMBLE_DIR is ineffective [https://gitter.im/nim-lang/Nim?at=5dbc4f8e3f4ea333f2c52b94]
15:31:29FromGitter<kaushalmodi> oh well, I will stick with the above workaround.. cannot get rid of `~/.nimble`
15:32:16*sedfox joined #nim
15:32:17disruptekthat's the only alternative, yes.
15:36:03FromGitter<alehander42> obviously
15:36:03FromGitter<alehander42> https://repl.it/site/blog/upm
15:36:08FromGitter<kaushalmodi> btw I was looking at the wrong source.. looking at: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ NIMBLE_DIR should work.. but it's not [https://gitter.im/nim-lang/Nim?at=5dbc50e88fbe1d5faba1faaa]
15:36:18FromGitter<alehander42> i have to share another related to package management link
15:38:32disruptekthat seems worth trying.
15:43:11disruptekah, they make you implement the backends in go.
15:44:39*dddddd joined #nim
15:50:37FromGitter<alehander42> their software can also be written in nim
15:50:49FromGitter<alehander42> there are so many of those developer tools that people write in go
15:50:57FromGitter<alehander42> that nim is a good fit for imo
15:53:15shashlickrunning into an issue with cOverride / cPlugin and was wanting some community input cc @kaushalmodi
15:53:34shashlickhttps://github.com/nimterop/nimterop/issues/149
15:53:53*theelous3 joined #nim
15:54:22shashlickall calls to cImport will use the preceding cOverride and cPlugin calls
15:54:48shashlickone way is to clear everything once cImport is done which means every cImport will expect its own cOverride / cPlugin
15:54:55shashlickbut that is big effort for user
15:55:00FromGitter<kaushalmodi> there's isn't a way to have a `block:` to limit the impact of a cOverride/cPlugin, right?
15:55:36disruptekit seemed to me that you write a shim that operates a pre-existing package manager; the shim is in go, but admittedly small. still, it begs the question...
15:55:38FromGitter<kaushalmodi> > one way is to clear everything once cImport is done ⏎ ⏎ Yes, please no :) I have 10 cImports
15:55:42*filcuc quit (Ping timeout: 265 seconds)
15:56:35shashlickwell, other option is that cPlugin can be shared but cOverride will get consumed and cleared after cImport
15:57:12shashlickso if you want to override for multiple cImport, you need a cOverride for each
15:57:55FromGitter<kaushalmodi> But that would mean copy pasting dozens of lines 10 times.
15:58:16shashlickwhy?
15:58:42shashlickyou will be cOverriding specific symbols in a subsequent cImport
15:58:50FromGitter<kaushalmodi> .. because you said that the overrides will auto clear
15:59:28shashlickit's convenient to put everything in the top no doubt but the way cOverride works, if it finds a symbol that needs overriding, it replaces in place
15:59:37shashlickat the end, if there are any remaining symbols, it simply adds those to the top
15:59:42FromGitter<kaushalmodi> Hmm.. now that I think about it, I will need to copy paste types reused in multiple comports, but not that many
15:59:53shashlickso it is not designed to wait to override in later cimports
16:00:29shashlickand I don't see a way to do both - adding symbols vs. retaining for later cimports
16:00:45FromGitter<kaushalmodi> I can try out a branch with your proposal
16:01:08shashlickdoes your cOverride right now include symbols across multiple cImports?
16:01:50FromGitter<kaushalmodi> It includes consts which are reused in repeated cimports
16:02:14shashlickThat's cause they are symbols you aren't overriding but simply injecting
16:03:20shashlickIn fact subsequent cimports will reinject even override symbols since it won't see them in the next header
16:03:46shashlickI'm open to ideas but don't see a better way
16:04:24yumaikasdom96: Made a small thing in Jester last night: https://github.com/yumaikas/comic-trakr
16:04:49FromGitter<kaushalmodi> shashlick: Should there be a cache of previously injected symbols?
16:04:59yumaikasGoing to use it as the example for the cookie-counter bit of the docs, but wanted a way to keep my place in a webcomic without mucking with history and the like
16:05:13FromGitter<kaushalmodi> Because all the symbol injection happens in the global scope, right?
16:05:31shashlickEverything in cOverride gets injected in first cImport
16:06:05shashlickEither in place or at the top since there's no way to know the user's intention
16:06:16FromGitter<kaushalmodi> Now that you would have it autoclearing, it probably won't be an issue
16:06:27FromGitter<kaushalmodi> Hmm.. I would like to try it out.
16:06:45shashlickIf an override is relevant to a third cImport I think it should be next to it anyway
16:07:02FromGitter<kaushalmodi> Makes sense.
16:07:03shashlickBut this is more being expected from the user
16:07:41shashlickCan you also share the const that isn't getting wrapped?
16:09:14*nixfreak_work joined #nim
16:09:45FromGitter<kaushalmodi> I have this in the .h file: ⏎ ⏎ ```# Declaration 'NO_OF_PROFILES' skipped``` [https://gitter.im/nim-lang/Nim?at=5dbc58c96570b076740f6f21]
16:10:23FromGitter<kaushalmodi> So I add it manually using: ⏎ ⏎ ```cOverride: ⏎ const ⏎ NO_OF_PROFILES* = 4``` [https://gitter.im/nim-lang/Nim?at=5dbc58efa85791488f895aa8]
16:11:48FromGitter<kaushalmodi> oops, we should be in nimterop channel?
16:12:21shashlickya we can continue there - just wanted to ask the cOverride question in front of more eyes
16:12:39shashlicknimterop doesn't wrap consts today, just #defines
16:13:09yumaikas@dom96: Also, I have a PR in to remove the devel compiler notice from the Jester readme.
16:21:55*filcuc joined #nim
16:22:27FromGitter<brentp> how can I set precision of floats in json output? I tried definding `$` for floats, but it doesn't get used.
16:23:25disruptekyou shouldn't really be able to do that.
16:24:00disruptekuse a string if you want to approximate a number.
16:24:44disruptekbtw, thanks for plotly. i'm looking forward to using it.
16:27:43FromGitter<brentp> sure thing. though most of it is done by @Vindaar, by now.
16:28:59*nixfreak_work quit (Ping timeout: 260 seconds)
16:37:11*MagicMissile joined #nim
16:38:10FromGitter<Vindaar> @brentp I don't think there's an easy way. Both `toUgly` and `toPretty` just call `addFloat` https://github.com/nim-lang/Nim/blob/devel/lib/pure/json.nim#L745
16:38:49FromGitter<Vindaar> oh, wait. `addFloat` itself just calls `$` so hmm
16:39:43*Vladar joined #nim
16:48:32*solitudesf quit (Quit: Leaving)
16:49:12*hed0n1st quit (Quit: Leaving)
16:56:24*solitudesf joined #nim
17:01:49MagicMissileWhy nested for loop so slow? https://play.nim-lang.org/#ix=20vn Without the -d: release flag of course
17:02:48FromGitter<alehander42> 10_000 ** 2
17:02:53FromGitter<alehander42> is 100_000_000
17:02:56FromGitter<alehander42> not 10_000_000
17:03:43FromGitter<alehander42> it happens, thats why
17:03:53FromGitter<alehander42> using `_` is cool when you have it
17:06:56*ng0 quit (Ping timeout: 260 seconds)
17:07:48FromGitter<brentp> plus you're not resetting j in the while loop.
17:12:37*ng0 joined #nim
17:19:04*narimiran joined #nim
17:19:23MagicMissileCorrected https://play.nim-lang.org/#ix=20vQ But the difference with the -d: release flag is annoying
17:20:18FromDiscord<Lantos> @PMunch good stuff
17:20:19FromDiscord<Lantos> templates are cool
17:20:56FromGitter<brentp> @MagicMissile use -d:danger
17:39:38rayman22201@araq poke. you around?
17:44:40*MagicMissile quit (Remote host closed the connection)
17:58:26*clyybber joined #nim
18:06:30clyybberMagicMissile: WDYM "annoying"? Would you rather have everything be slow?
18:06:45*Jesin quit (Quit: Leaving)
18:07:24rayman22201so what does it mean when a GC crash goes away when you turn on `-d:leakDetector` lol?
18:07:52rayman22201is it the classic, "it hurts until you see the doctor, then it goes away?" :-P
18:08:54rayman22201This smells like an alignment bug....
18:10:25*nsf joined #nim
18:11:53*Jesin joined #nim
18:12:58clyybberAraq: Ha, I found a bug in semobjconstr by looking at the code..
18:14:10clyybberIf you provide only a runtime value to the discriminator that has a range type that only fits in one branch, it will still check all branches for mandatory fields..
18:14:59disruptekthat's only on ranges?
18:15:06clyybberrayman22201: heisenbug
18:15:07disruptek'cause that feels like the same bug we already saw.
18:15:15clyybberdisruptek: Yeah, thats only on ranges
18:15:21clyybberdisruptek: Which bug?
18:15:24clyybberIt was no bug
18:15:37clyybberDateTimeLocal is a mandatory field
18:15:57disruptekyes, but not given the value of the runtime.
18:15:57clyybberAnd thus needs to be initialized, which means the compiler needs to know which branch will be taken
18:16:17rayman22201oh no @clyybber. It's very reproducible. turn the flag off, it crashes consistently in the same spot. turn the flag on, it goes away.
18:16:37disruptekit's a schrodinger bug, then.
18:16:43rayman22201:-P
18:16:47clyybberyeah that fits better
18:16:54rayman22201meow
18:17:17clyybberdisruptek: lemme pull that snippet up and check again
18:17:57disruptekthe compiler produces an error about `b uninit'd` but b isn't in the branch given the runtime value. change the runtime to a const and it works.
18:18:31disruptekmaybe the code for ranges was copied and the bug copied with it.
18:19:42clyybberdamnit
18:19:45clyybbercant find the snippet
18:20:02*filcuc quit (Ping timeout: 240 seconds)
18:20:17clyybberdisruptek: But it makes sense, because it is not clear at compile time which branch will be taken
18:20:30clyybberand thus the initalization of DateTimeLocal can not be guaranteed
18:20:59rayman22201re: my bug: The `-d:leakDetector` flag adds extra fields to GC Cell objects, this really makes me think it's an alignment bug....
18:21:26clyybberrayman22201: Makes sense, are you working on async again?
18:21:32disruptekhttps://github.com/nim-lang/Nim/issues/11428
18:22:06rayman22201@clyybber. Yeah. I think I have a solution to make async work with dispose/ AraqGC
18:22:44clyybbernice
18:22:49clyybberdisruptek: Thanks
18:23:09clyybberdisruptek: The issue will be solved with defaultfields
18:23:12clyybbereventually
18:23:20disrupteki get why it happens, i just think if you're able to fix ranges, you'll be able to fix that the same way.
18:23:23clyybberbut not the issue in your snippet
18:23:43clyybberdisruptek: But that means I generate a case statement after the object constructor
18:23:48clyybberand that has a runtime impact
18:24:14disruptekit should be a new check, then.
18:24:43clyybberdisruptek: I'm not sure what exactly you mean
18:25:00clyybberI can implement default values for ranges and other types
18:25:29clyybberbut the branches they are in have to be selected at compile time.
18:25:30disruptekthe runtime cost should be borne by !release builds.
18:26:04clyybberdisruptek: No, it would generate assignments not checks
18:26:56disrupteki mean, just don't generate them.
18:27:01disrupteklet the code crash.
18:27:05clyybberAh
18:27:10clyybberUmm
18:27:25clyybberbut that means that some code will work with -d:release and crash with danger
18:27:29clyybberand thats broken
18:27:39clyybberunless I error on -d:release
18:27:52clyybberbut then again I can catch the possibility at compile time and thats better
18:27:59clyybberIMO
18:28:28clyybberand if we get better deduction for case statements it also won't be so bothersome
18:29:19clyybbertype
18:29:21clyybber needsInit = object
18:29:22disruptekhmm, you're right, this won't make any sense.
18:29:23clyybber v: range[1..11]
18:29:25clyybber cObj = object
18:29:27clyybber case i: int
18:29:29clyybber of 0..3:
18:29:31clyybber v: int
18:29:33clyybber of 4..7:
18:29:35clyybber n: needsInit
18:29:37clyybber else:
18:29:39clyybber d: uint
18:29:41clyybberproc test(i: range[0..3]) =
18:29:43clyybber echo cObj(i: i)
18:29:45clyybberSorry for the paste
18:29:47clyybberBut this is the bug I found
18:29:49clyybberwhich really is a bug
18:29:51clyybberSince the compiler shouldn't error on this code.
18:30:04clyybberOr should it?
18:30:05disruptekwell that's clearly broken.
18:30:19clyybberHmm. at least it shouldn't with default objects
18:30:22clyybberfields
18:31:28clyybberyeah its broken, with or without default fields
18:31:30clyybberheh
18:31:33clyybbertime to fix it
18:33:27clyybberand fix the bad fields initialized error along the way
18:33:36clyybberbecause that sucks
18:34:03disruptekbooyah 😊
18:34:06clyybberdisruptek: low for range types as a default makes sense right?
18:34:13disruptekyes.
18:34:23disruptekalso enums.
18:34:30clyybberIf people want to overwrite it they can use default values
18:34:34clyybberdisruptek: Yeah enums
18:34:37clyybberalso
18:35:09disruptekthis is good stuff you're doing. 🎉
18:35:27clyybberthanks
18:37:06clyybberdisruptek: Should I error like we do for range types if enums could end up in an invalid state?
18:37:11clyybberOf course only for non holy enums
18:37:25disruptekhow could non-holy enums end up invalid?
18:37:32clyybber+ 1
18:37:36clyybberinc e
18:37:43clyybbere += 1
18:37:52clyybberoh
18:37:56clyybbernon holy enums
18:37:57disruptekoh. gah how can you check that?
18:38:10clyybberdisruptek: I'm dumb I thought you wrote holy enums
18:38:26clyybberFor non-holy ones its easy
18:38:32clyybberNo
18:38:45clyybberits not. But hey I don't think we check it ucrrently
18:38:50disruptekat compile time?
18:39:02clyybberah right, we check at runtime
18:39:04clyybberI think
18:39:11clyybberbut I'm not sure if we do for enums
18:39:29disrupteksounds like a debug flag that's off for release, but, yeah.
18:39:30clyybberAt least for enums with holes (holy enums) it doesn't make sense to check
18:40:02disruptekhow are holy enums implemented? i can't remember.
18:40:20clyybberbrb asking the pater
18:40:54clyybbers/pater/pastor
18:41:12clyybberor priest or how its called
18:41:37clyybberdisruptek: They are just an ints with aliases
18:41:39clyybberas all enums
18:41:48clyybberand with a $ implementation I think
18:42:08disruptekso right now i can give an enum a bogus value with inc?
18:42:25clyybberFor a holed enum yeah
18:42:32clyybberFor a non-holed one, not so sure
18:42:39clyybberneed to check
18:43:05disrupteki thought they were a set of range[short].
18:43:30clyybbera set?
18:43:42clyybberhuh
18:43:52disruptekno, not a set. but maybe i'm confusing this with some other lang.
18:44:08clyybberyou can make an enum thats the size of an int64
18:44:14clyybberI think
18:45:49rayman22201For @Araq and anybody who wants to follow along: I have a GC bug. I don't have a "minimal" repro, but hopefully it's small enough
18:46:00clyybberpaste it in irc
18:46:02clyybberfor the lulz
18:46:05disrupteklol
18:46:42clyybberand while you are at it rename all variables to members that are currently online
18:46:52disruptekomg
18:47:06rayman22201https://github.com/nim-lang/Nim/compare/devel...rayman22201:async-with-dispose
18:47:10rayman22201starting from here
18:47:40clyybberproc disruptek(d: isruptek) = d.isruptek
18:48:02clyybbersorry I made you a useless proc disruptek..
18:48:12rayman22201This is the failing test: https://github.com/nim-lang/Nim/blob/devel/tests/async/tnewasyncudp.nim#L55
18:48:13disruptekdon't sweat it; all my procs are useless.
18:48:20clyybberthats the spirit
18:49:13rayman22201here is the stack trace: https://www.irccloud.com/pastebin/GTqWiFY0/
18:49:47rayman22201turning on `-d:leakDetector` makes the test pass.
18:49:49Araqthis is not a GC bug, you inject the new 'dispose' calls
18:50:01Araqand apparently not in the right place
18:50:17rayman22201I don't believe that is the case. I am confident they are in the right place.
18:50:41rayman22201if they were in the wrong place, `-d:leakdetector` would not suddenly make it work?
18:50:46clyybberAraq: Do we currently range check enums?
18:51:13Araqsure they would, a memory corruption is not deterministic
18:51:28Araqso changing anything unrelated can influence it
18:51:41rayman22201let me clarify. I do think the new `dispose` causing the issue. But I don't think it's the fault of `dispose`. I think the GC is doing something wrong.
18:52:20Araqwhich is why memory safety is such a big thing, without it you need non-local reasoning for everything
18:52:31FromDiscord<kodkuce> some dude haraisng me to do some c# for 50$, like i am doing it and am now like wtf its slow to type nim faster, like now am even frogoting to type ; end of line
18:53:14rayman22201follow me on the bug here. I think something very specific is going on that I want to understand.
18:53:58Araqrayman22201: you dispose(x), other pointers to x must not exist
18:54:08clyybberkodkuce: I feel you.
18:54:18Araqotherwise the GC follows these pointers and crashes as in your stack trace
18:54:23clyybberjava is even more extreme
18:54:55FromDiscord<kodkuce> pain is real 🙂
18:55:06Araq-d:leakDetector is heavy, it changes the involved object sizes
18:55:36rayman22201right. Why would the size change a lifetime bug?
18:57:31rayman22201also, if the lifetimes were wrong, wouldn't the GC crash on the first mark pass? not let the loop run for many iterations before crashing?
18:59:37*cyraxjoe quit (Ping timeout: 240 seconds)
19:00:17Araq-d:nimBurnFree to make it crash faster
19:01:05Araqbut no, it doesn't have to crash on the first mark pass, it's all quite unpredictable
19:01:23Araqclyybber: we do check range enums
19:01:46clyybberAraq: So does an enum field make an object nfRequiresInit currently?
19:02:04Araqit if lacks myenum(0)
19:02:10Araq*if it
19:02:12clyybberOk
19:02:21clyybberSo I won't be breaking any code
19:02:23clyybbergood
19:02:31clyybberthanks
19:02:53*cyraxjoe joined #nim
19:03:21rayman22201What I believe is happening: https://www.irccloud.com/pastebin/btk14aPk/
19:03:30*rockcavera joined #nim
19:03:31rayman22201can you confirm this Araq?
19:03:53rayman22201If so, is there a way to transfer ownership of the pointer from step 1?
19:03:56Araqsounds likely
19:04:08FromDiscord<eacyy> I'm on Discord. Can you guys actually see Discord's code formatting stuff?
19:04:08FromDiscord<eacyy> ```nim
19:04:08FromDiscord<eacyy> echo "Is this being formatted on your platform/site?"
19:04:08FromDiscord<eacyy> ```
19:04:23rayman22201the proc needs to be able to relinquish ownership of that pointer.
19:04:47Araqrayman22201: however 'dispose' does 'nil' out the pointer and it's transformed into someClosure.fut
19:05:08Araqso it's hard to see where the remaining refs come from
19:05:30rayman22201there can only be that one ref AFAIK
19:06:30rayman22201the closure from here: https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncdispatch.nim#L1469
19:07:17rayman22201well, 2 refs. One ref for the await itself obviously + the ref for the socket callback closure.
19:07:18*jjido joined #nim
19:08:39rayman22201my printf debugging and the stack trace seem to support this
19:09:10rayman22201somehow the `dispose` call does not `nil` out the closure.fut ref
19:09:30Araqlet's assume that's the case. the problem is there are other allocations
19:09:51Araqcan we 'dispose' them all properly for the common async cases?
19:10:07rayman22201which other allocations?
19:10:49rayman22201for the special case of closure.fut I know (Because of the cpc paper) that it is safe to nill that reference.
19:10:49Araqthe closures, for example
19:11:53Araqsurely looks like it, yeah
19:11:55*jjido quit (Client Quit)
19:12:05Araqbut that's 1 allocation out of 3 or 4
19:12:27rayman22201for the general case of everything in a closure environment, harder to answer. I have to think about it harder.
19:12:32rayman22201But that is the entire point of dispose
19:12:47rayman22201you know some particular ref is safe to destroy
19:12:50rayman22201so you destory it
19:12:57rayman22201*destroy
19:13:20Araqsure
19:14:21rayman22201I can also reasonably say that for this particular closure, it's safe to destory it. The socket read is finished, and the promise has been read. (That is why the GC is kicking in for that closure anyway.)
19:14:37rayman22201that doesn't extend to the general case of course
19:15:52rayman22201essentially, b/c I have extra information about this case, I was able to call 'dispose' and free one small piece of the closure environment a little bit early.
19:16:33clyybberAraq
19:16:36clyybberproc test(i: range[0..3]) =
19:16:38clyybber echo cObj(i: i)
19:16:39rayman22201brb
19:16:40clyybbery
19:16:55clyybberIn this snippet the type of i in the object constructor is tyInt
19:16:59clyybberand not tyRange?
19:17:04clyybberThats a bug right?
19:19:29Araqlooks like it
19:22:49ehmryI'm crawling the nimble package list, and there are more packages without version tags than with tags
19:23:12shashlickmeh, not able to code, brain isn't working
19:23:17ehmryversion your code people
19:24:17FromGitter<brentp> @mratsim, what would be the way to do something like this in Arraymancer given 2D tensor Q: `(Q.astype(int) == -1).mean(axis=0)` ?
19:26:28ehmrythe good news is that we are over 1K packages
19:29:33Araqehmry: yeah, I stopped "new runtime" development after this threshold :P
19:30:12Araqwe don't need a Python 2/3 situation
19:30:54Araq(there were other reasons too, for example "it doesn't actually work")
19:31:59ehmryFWIW we probably don't have 1K packages that pass their own tests
19:32:35ehmryI shouldn't say that, I have no idea
19:42:06rayman22201@Araq I'm on my phone but I'm online
19:42:24rayman22201Does what I said make sense?
19:42:49Araqrayman22201: yes but I dunno if I'll fix it, 1 out of 4 allocations ain't good enough
19:43:03*nxl4_ joined #nim
19:43:07rayman22201I don't understand why
19:43:26rayman22201It's arguably the most important one
19:44:06nxl4_Hello, is anyone aware of documentation that could explain Nim throwing this error: "Error: unhandled exception: Parsed integer outside of valid range [ValueError]"
19:44:20rayman22201Ok. Well, I have an alternative if you don't want to fix it. I don't think it's as elegant though.
19:44:38nxl4_It's in response to this line of code:
19:44:39nxl4_let jsonRsp = parseJson(rspJson)
19:45:01nxl4_I can compile some JSON objects fine, but others will throw the error.
19:45:58nxl4_I know that the JSON object is valid. It's coming from the Shodan API, and is parsed fine by jq.
19:48:14disruptekyeah, it happens with large numbers.
19:48:30disruptekintegers, that is.
19:48:52rayman22201I could actually dispose the entire closure if I could get access to the closure environment ptr
19:49:12rayman22201But I don't think I have a way to get access to that
19:49:45rayman22201That's the problem with implicit closure allocation
19:50:24*Perkol joined #nim
19:50:51Araqsomeproc.rawPtr exists
19:51:31AraqJSON doesn't have "large" numbers
19:51:39Araqjq is not a JSON validator
19:53:09rayman22201Hrmmm. Interesting. If I could have the future also return that ptr it might work...
19:54:34disrupteki only see overlarge numbers in json from microsoft. go figure.
19:55:46rayman22201My alternative solution is to have async procs use an "out" param for the future, instead of allocating their own future directly. Then the parent has total control of the lifetime of the future. I think this is closer to what the cpc paper does. It's a much bigger change to how async works though...
19:56:10Araqrayman22201: I like it
19:56:19Araqcould help in all sort of ways
19:56:28rayman22201Lol. Ok then
19:56:30nxl4_Any known methods of dealing with the overlarge integer issue for JSON parsing?
19:56:40Araqbut them inside ""
19:56:46Araq*put
19:56:47Araqlol
19:57:48nxl4_Well...since it's coming from an API...
19:57:58nxl4_I'm guessing it's this one: "serial": 4.647487688093299e+37
19:59:30Araqmaybe don't map it to an integer type
19:59:47Araqlooks like a floating point number to me
20:00:23disrupteknxl4_: are you using openapi for this?
20:01:17nxl4_disruptek: Is that a module? If so, I'm not. I'm just using httpClient and json for this part.
20:02:08disruptekokay, i was just curious if it was based on a swagger/openapi definition.
20:02:23nxl4_Also, I'm not generating the JSON, I'm pulling it down from a REST API.
20:02:44nxl4_So, I can't control the format of the raw data; I'm just trying to parse it.
20:02:45disruptekthe idea of using a float as a serial kinda blows my mind.
20:02:58*Jesin quit (Quit: Leaving)
20:03:33rayman22201I have a second problem with async. Loops... Is there an elegant way to get a "last read of" a symbol?
20:03:49nxl4_Looks like that's how Shodan's presenting SSL cert serials.
20:04:31disruptekput shodan on the phone; lemme talk to him.
20:04:35disrupteki'll straighten this bozo right out.
20:04:37rayman22201The cpc paper solves this by converting loops into recursive calls. Which is lame imo.
20:05:11nxl4_lol, yeah I'll get John M on the line right away
20:07:34rayman22201Although, making all loops async would "increase the async-ness" of the system overall... That could be advantageous?
20:07:58AraqI doubt it
20:09:29rayman22201Lol... Yeah...
20:10:58rayman22201If there isn't some pass I can already leverage, my idea is to make a poor man's "last read of" pass inside the async macro itself.
20:12:57Araqwell in the compiler I have this knowledge but it's hard to expose
20:13:26Araqfor a prototype you can annotate it on your own inside .async, no need to compute it
20:13:58rayman22201Fair enough
20:14:58FromGitter<kaushalmodi> Araq: A minor question about the `zip` proc in sequtils.. ⏎ ⏎ It's signature is `proc zip*[S, T](s1: openArray[S], s2: openArray[T]): seq[tuple[a: S, b: T]] =`
20:15:27FromGitter<kaushalmodi> yesterday, I was using it to create seqs to pass to another proc expection seq's of 2-field tuples
20:15:28clyybberdisruptek: shodan sent you a message via nim docs
20:15:47FromGitter<kaushalmodi> problem is that the returned seq by zip is a seq of named tuples
20:16:22FromGitter<kaushalmodi> so the other proc won't take the `zip` returned seq unless on both sides, the tuples have the exact `a` and `b` fields
20:16:38FromGitter<kaushalmodi> does it make sense to have `zip` return anon tuple seq i.e. no field names?
20:16:46disruptekyes.
20:16:48Araqdefinitely
20:16:55rayman22201I still need to detect a 'future.read' inside a loop, since the dispose can only be called after the loop completes
20:17:04FromGitter<kaushalmodi> Araq: OK, PR upcoming
20:17:18disruptekor, just name all your tuple pairs a: and b:. problem solved. 🤣
20:17:24FromGitter<kaushalmodi> heh
20:17:28rayman22201Lol 😆
20:17:30disruptekthanks for fixing that.
20:18:05FromGitter<kaushalmodi> `zip` is useful.. found its use 2 days back.. but was stumped seeing its marriage with a and b fields
20:18:55disruptekthere are a few things like that in stdlib.
20:19:23disruptekhttps://github.com/disruptek/foreach
20:19:34disruptekhelps me trip over them all the time.
20:28:35Araqrayman22201: you should call GC_disable() and see you can get a stable memory usage
20:28:48FromGitter<kaushalmodi> done: https://github.com/nim-lang/Nim/pull/12575
20:28:52Araqaka injecting 'dispose' in all the right places
20:29:15FromDiscord<ndl> hi
20:29:20*Jesin joined #nim
20:30:01Araqhi, ndl
20:30:52rayman22201Currently, The closures will leak (unless there is some distructor for the closure that don't know about)
20:31:16AraqFuture.T which is often a string should also leak
20:31:27rayman22201I don't think so
20:31:36rayman22201But I can check
20:39:00*Perkol quit (Quit: Leaving)
20:40:05*nxl4_ quit (Quit: Konversation terminated!)
20:41:12*exelotl joined #nim
20:42:59*GordonBGood joined #nim
20:46:23rayman22201What are the 4 allocations? The closure, the Future, the T, ... What else?
20:47:27*GordonBGood quit (Ping timeout: 264 seconds)
21:04:02FromDiscord<mratsim> omg, the discord bot is awful to full IRC/Gitter conversion :/
21:05:51*rockcavera quit (Remote host closed the connection)
21:08:02FromGitter<nixfreakz_twitter> @yglukhov Are you still working on nimX ?
21:08:13FromDiscord<mratsim> btw, can I pass a closure to another thread? is it thread safe?
21:11:09rayman22201If you use boehm it is 😛
21:12:06rayman22201What is the type of a closure env? rawEnv returns an untyped ptr
21:12:46rayman22201Different question, @Araq can I expose a version of dispose that takes a ptr?
21:13:26rayman22201Oh wait. NVM. You already solved this. I didn't see the overload
21:15:26FromDiscord<mratsim> @rayman22201 "proc (param: pointer) {.closure.}"
21:15:37shashlick@kaushalmodi - i have a fix, are you able to test?
21:16:07FromDiscord<mratsim> ah I didn't understand your question
21:16:21FromDiscord<mratsim> I'm curious, it's probably magic hidden deep in the compiler
21:16:30FromDiscord<mratsim> (th type of the closure environment that is)
21:20:08*clyybber quit (Quit: WeeChat 2.6)
21:27:39shashlick@kaushalmodi - i have created branch `issue149` for you to try, please let me know if it works for you
21:29:51rayman22201Lucky for me, Araq already figured it out. I just need to read better lol 😛
21:30:28dom96hey all, what's new?
21:31:35*thomasross joined #nim
21:33:09rayman22201Hey Dom. I think I'm close to getting async working with araqGC. Maybe... Lol 😆
21:36:50dom96nice, but what is `araqGC` again? :)
21:38:10shashlick@dom96 - please clear my choosenim PR
21:38:35rayman22201Hybrid between boehm and C++ style manual mm. A compromise / alternative for newruntime
21:41:25dom96shashlick, merged
21:47:38shashlickthanks!
21:47:58shashlickwhen would you like to spin the next release? or are there some other things you'd like to fix before that
21:48:25*Trustable quit (Remote host closed the connection)
21:49:29dom96would be nice to fix this: https://github.com/dom96/choosenim/issues/116
21:49:37dom96and see if there are other high pri bugs
21:49:46*GordonBGood joined #nim
21:50:50*narimiran quit (Ping timeout: 240 seconds)
21:57:14Araqrayman22201: closure + closure iterator + Future + T, 4 allocations
21:57:25dom96ooh, just realised our user record has been broken
21:57:40FromGitter<kaushalmodi> shashlick: It works perfectly!
21:57:45dom96Last time we had 170 users was in 2015
21:57:57Araqyaaayy...
21:58:15Araqbut this predates all these bridges we have
21:58:23Araqso you cannot count it anymore
21:58:38dom96it makes it even more impressive
21:58:43dom96I can still count it
21:59:03shashlickCool I'll take a look
21:59:17shashlick@Araq any favorite choosenim bugs you want addressed?
21:59:33Araqthey are all marked with a tag
21:59:39FromDiscord<kodkuce> how much now users?
21:59:48shashlickI'm in the middle of the nimble local deps proposal, there are caveats
21:59:55shashlickWill share soon
21:59:57Araqwere "acceptance criteria" before choosenim can becomes the official way to install Nim.
22:01:38*nsf quit (Quit: WeeChat 2.6)
22:02:12dom96kodkuce: 177
22:02:34shashlickNot able to find the list on the phone, will check later
22:02:53FromDiscord<kodkuce> where you read that 177
22:03:26dom96IRC
22:05:34shashlickThanks @kaushalmodi
22:05:47rayman22201The iterator. Of course!
22:06:13FromDiscord<kodkuce> does discord bot show me on IRC too?
22:06:22FromDiscord<kodkuce> or you just using IRC as ref 🙂
22:08:11AraqGordonBGood: I found the problem
22:09:09*mwbrown quit (Excess Flood)
22:09:18dom96kodkuce: the latter
22:09:36*mwbrown joined #nim
22:11:25GordonBGoodAraq: ah good on the problem, is it hard to fix?
22:11:36Araqdon't think so
22:12:00rayman22201@Araq, a very simple test using Future[string] shows 3 out of 4 things get freed with my dispose calls.
22:12:25rayman22201which seems to line up with what I expect
22:12:37rayman22201only the closure can't be freed
22:13:10Araqwith a backref from the Future to the closure it could be
22:13:50rayman22201yeah. I think so
22:14:17Araqimpressive results
22:14:21GordonBGoodAraq, Ah, good if it's easy to fix - was I right that the leak has been lurking all this time but just didn't come up for most use cases when there was GC?
22:14:57Araqnah, it's specific to --gc:destructors
22:16:13GordonBGoodDoes it explain why we can't see trace the TestObj destructor calls in both --gc:destructors and "ordinary" GC?
22:18:00GordonBGoodIf I make a raw allocation within TestObj and dealloc it in the =destroy, it never gets deallocated when it's moved to a closure environment for all GC's and --gc:destructors
22:18:41GordonBGoodmemory use continuously increased with repeated creation of the "tst" closures
22:20:04Araq=destroy is not called, the memory itself is freed afaict
22:20:31GordonBGoodAraq: I've also been thinking about what you said about not liking repr for the new destructors/newruntime modes, you said you didn't like the use of RTTI
22:20:50GordonBGoodDo you see the way forward gradually eliminating RTTI?
22:21:48Araqwe can keep it and generate it on demand
22:21:49GordonBGood"=destroy" is indeed not used; isn't that a problem when an object relies on =destroy to do clean up of raw allocations?
22:22:25GordonBGoodI see that the memory itself is freed
22:23:43GordonBGoodFor legacy GC, in this situation we would just write a finalizer to do the clean up, but I'm don't think we can write a finalizer that would work for the closure captures in destrucors/newruntime
22:24:36GordonBGood?
22:27:23Araqit's a bug affecting destructors, I'm fixing it. should be backported to 1.0
22:29:25GordonBGoodAraq: Okay on the bug in destructors, I'll check that again when you commit - but would you mind having a look at this "causing memory leak even within GC"?
22:30:04GordonBGoodI'll simplify the MCVE more than last tiime along the lines we discussed :)
22:30:25Araqreport it on github
22:30:56GordonBGoodOK, I'll file an issue
22:32:02Araqbut I know there is no leak because it's logically impossible, the GC doesn't know about closures, it's all lowered to 'new' and has been stress tested to death :P
22:33:30GordonBGoodAraq, I am maybe/probably misunderstanding my own test, but instrumentation says I'm causing a memory leak even using refc GC
22:34:12GordonBGoodBut embarrassement doesn't matter to me in the search for further knowledge ;)
22:34:46disruptekeveryone says that before they get into porn.
22:35:37GordonBGooddisruptek: I had better qualify that be qualifying it with "as applied to Nim" then
22:37:08GordonBGoodAraq: do you want me to file an issue on the following gist as well: https://gist.github.com/GordonBGood/705a1faa51eabb72514b6b976d5dc47d
22:37:18FromDiscord<kodkuce> embarrasment is for pussys
22:37:39FromDiscord<kodkuce> i infront declare myself as crazy newb xD
22:37:41shashlick@Araq - are these really all that remain on your wishlist? https://github.com/dom96/choosenim/milestone/1
22:37:41GordonBGoodI think it may be simpler as it definitely only applies to destructors
22:37:57FromDiscord<kodkuce> but 1 day will get my revange
22:38:42FromDiscord<kodkuce> i go sleep cya all
22:38:50disruptekpeace puppy
22:40:24Araqshashlick: yes.
22:42:25shashlickwell, life is allowed to appear easy sometimes
22:45:53shashlick@kaushalmodi - made a minor change, can you please retest if you have time?
22:49:46GordonBGoodAraq: I'll hold off on filing the first issue until I see if your fix of the destructor issue also fixes this...
22:50:16*solitudesf quit (Ping timeout: 240 seconds)
22:51:16GordonBGoodAraq: this last gist link has to do with a compiler crash when a closure creation is nested in another proc, only for --gc:destructors/ref counting AFAICT
22:53:53GordonBGoodThe compiler error message comes from lambdalifting.nim at the end of symToClosure
22:57:00GordonBGoodAraq, you need to go soon and I need some more sleep; I'll check the log later for replies... gn8
22:57:14Araqbye
22:58:03*jjido joined #nim
23:01:15rayman22201see you! thanks for the help
23:01:49*GordonBGood quit (Ping timeout: 268 seconds)
23:13:11shashlick@disruptek - bump rocks
23:18:09dom96yay! My game runs on iOS
23:18:26dom96still a while to go before it renders correctly though :)
23:20:02rayman22201🎉
23:25:09*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:35:05shashlickon project local deps support for Nimble - https://gist.github.com/genotrance/ee2ce321a56c95df2d4bb7ce4bd6b5ab
23:35:08shashlickappreciate feedback
23:39:17dom96I would prefer if we have a dedicated command to initiate local deps
23:39:24dom96for example `nimble freeze`
23:39:34dom96instead of this "local = true" in the .nimble file
23:39:51*nxl4 joined #nim
23:40:04shashlickthere's really nothing to do besides creating a directory
23:40:18shashlickbut it will drive a bunch of code changes with no real benefit
23:40:23shashlickthe .nimble change can be checked in
23:40:34dom96The whole idea is to have Nimble copy the deps
23:40:35AraqElif .nimble file for a project contains local = true, create $prj/deps and force nimbleDir = $prj/deps
23:40:37shashlicka command is equivalent to mkdir
23:41:10dom96I don't want to change `nimble install` behaviour
23:41:12Araq^ this is problematic as the project.nimble file describes its dependencies for other clients
23:41:20dom96at least not for now
23:41:33shashlicknimble install isn't changing, i've described in notes
23:41:44AraqI think 'local = true' is not required.
23:41:58shashlickwe can skip it, it avoids having to check in an empty txt file
23:42:24shashlicklocal = true will be ignored if the package is installed as a dependency itself
23:42:32shashlickit is only relevant when the package is the project itself
23:42:39Araqok
23:42:42dom96from what I can see in your proposal: `nimble install -d` will install into $prj/deps
23:42:48Araqnimble install URL | packagename will again install the package to ~/.nimble per usual even if the command is run in a project dir with local deps enabled.
23:43:00Araq^ seems not intuitive
23:43:15Araqjust use my deps dir please
23:43:22dom96no
23:43:27dom96that's valid
23:43:43shashlickbut what happens if you simply do `nimble install` - does it not do anything, install the package back into its own deps dir, or use ~/.nimble
23:43:57shashlicki've still not even thought through `nimble develop`
23:44:04dom96the behaviour of `nimble install` shouldn't change at all
23:44:09dom96same for `nimble develop`
23:44:39shashlickso you want a new sub-command that will do this?
23:44:45dom96yes
23:45:06shashlickthen what will nimble build do
23:45:35dom96what should change is dependency resolution.
23:45:48shashlickif you isolate this to a separate command then it isn't intuitive like Araq says
23:46:00shashlicka whole bunch of commands that continue to just use the global ~/.nimble
23:46:18Araqexactly, we have discussed this already
23:46:21shashlickif you want local deps then everything should adjust to that
23:46:36Araqyes.
23:46:56shashlick`nimble install` could just process deps and quit since there's no copying to ~/.nimble required
23:47:00shashlickthat's the alternative
23:47:01AraqGordonBGood: pushed my patch
23:47:13shashlickand still intuitive that once you create a deps dir, there's nothing new to learn
23:47:28dom96You shouldn't use `nimble install`
23:47:32AraqI was talking about 'nimble install url'
23:48:04Araqand that should install url to deps if it exists
23:48:04dom96what you always want to do is add a dependency in your .nimble file
23:49:08Araqno, the dependency comes later. I might want to "install" a package, see if it's useful and then add the dependency to my .nimble file
23:50:05shashlickthat's a good thought but again it means all commands need to adapt to local deps
23:50:28FromGitter<Willyboar> why don't you create something similar to virtualenv?
23:50:38shashlickanyway, i know it is late for you guys, get some rest and we can debate it more tomorrow
23:50:43dom96Araq, you can add the dependency and remove it later then
23:50:50shashlicki just want to document all behaviors so that we can implement it correctly
23:51:07shashlickthis is one thought process - i'm open to any as long as it is consistent
23:51:09Araqdom96: that's a super annoying setup and you know it.
23:51:22*nxl4 quit (Quit: Konversation terminated!)
23:51:24Araqnimble search keyword
23:51:34Araqnimble install let-me-see-this
23:51:51Araqyour solution: edit the .nimble file already after 'nimble search'.
23:52:13shashlicknote also that even packages.json and other metadata will live in `$prj/deps` - i don't think we should change any of the nimbleDir behaviors
23:52:31shashlicki've also noted bin dir concerns
23:53:09Araqif deps exists, use it.
23:53:12Araqsimple.
23:53:14Araqworks.
23:53:41shashlicknimterop won't be impacted since the binary is relative to currentSourcePath of nimterop nim file - that might be a solution for that but not everyone will have a bin file that is referenced in a source file
23:54:09Araqmight even apply to 'nimble develop'
23:54:22Araqit's worth a try at least
23:54:32Araqbut I need to sleep indeed, good night.
23:54:47FromGitter<Willyboar> good night
23:55:14dom96This is turning into a more disruptive feature than I thought
23:55:52shashlickI have aimed to minimize the code impact
23:56:02shashlickAnd complexity
23:56:19rayman22201Everything in Nim land: this seemed easy.... nope, actually super complicated :-P
23:56:23shashlickBut it will affect all areas yes
23:56:37shashlickThe code might be minimal or seems
23:56:43dom96What is the aim here? Is it to replace lock files or just make it easier to develop packages?