<< 22-11-2018 >>
00:03:52zachcarterworking with a different architecture on the game engine this time
00:04:17zachcartergoing with a dod oriented design - going to allow the engine to run in a server mode where you can register different data compilers with the server
00:04:50zachcarteror you can just run the engine in standalone mode and it will compile the resources locally
00:05:44zachcartergame code - for instance - will be a data resource that needs to be compiled
00:06:26zachcarterbut I think this should lead to an architecture where A) potentially people can work on the same project simultaneously
00:07:34zachcarterB) incremental compilation for the project
00:07:40zachcarterand C) potential for hot swapping compiled resources
00:07:56zachcarteralso - if there's a more efficient data layout for a compiled resource, there's control over that as well
00:15:58*dom96_w joined #nim
00:18:55FromGitter<zetashift> Did you get bgfx working?
00:24:24*gangstacat quit (Ping timeout: 252 seconds)
00:24:57zachcarternot yet
00:25:06zachcarterI'm far away from needing gfx though
00:25:13zachcarterworking on plumbing at ths point
00:26:07*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:29:48dom96shashlick: Why don't you just let the build crash for nimzbar on macOS?
00:30:18dom96or better yet, raise the error in your .nim file
00:30:28dom96it will work much better, Nimble doesn't have output integrated yet
00:36:44zachcartershashlick: I plan on trying bullet3 after bgfx
00:36:51zachcarterI want bullet3 for this engine
00:37:23zachcarterI already have the perfect repo name for it
00:37:41zachcarterhttps://github.com/zacharycarter/casing
00:37:42zachcarter:P
00:38:42*gangstacat joined #nim
00:45:40zachcarterdon't understand why bullet3 has to be the most complicated project in existence
00:45:47zachcarterbut either way it will be fun to wrap
00:51:52shashlickdom96: okay i'll change it into a raise
00:52:20shashlickzachcarter: sounds cool 🙂
01:05:15zachcartershashlick: hopefully the design of the engine works out better than it has previously
01:05:58*theelous3_ quit (Ping timeout: 244 seconds)
01:06:00zachcartermy goal is to end up with something that allows for a more iterative design process - although I have a feeling advancements in the language will help this realization along as well
01:11:50zachcarterI have a naive question - I understand today, it's possible to write GC-free code
01:12:11zachcarterbut you won't be able to use a LOT of the stdlid
01:12:53zachcarterthere is the new runtime in the works - which is going to provide for the possibility of RAII, ownership semantics and a borrow checking feature
01:13:38zachcarterwhere does this put us though - in terms of stdlib usage? can I write custom allocators and if I want to use sockets let's say - is it going to be possible to use the higher level stdlib modules?
01:14:40zachcarterapologies if alot of ^ doesn't make sense - I'm learning computer science backwards and trying to understand all of these concepts at once
01:14:59zachcarterbut if I'm not mistaken - there are allocators that Nim already has which work with the GC
01:16:38zachcarterand if someone wants to supply their own custom allocator - if that's even a|going to be a thing - how does that work if the object has a field of a something that is allocated by a stdlib module - like a AsyncSocket for example?
01:23:01*zachk quit (Quit: Leaving)
01:25:07*rauss joined #nim
01:32:00*rauss quit (Quit: WeeChat 2.3)
01:36:02zachcarterI think - https://github.com/nim-lang/Nim/wiki/Destructors - explains what I was asking
01:45:25FromGitter<rayman22201> As far as I understand it, destructors are basically done and implemented: https://github.com/nim-lang/Nim/issues/7041 ⏎ but you have three problems that are going to cause a lot of work for you: ⏎ ⏎ 1) ) The stdlib is going to be a crap shoot until it gets fully ported over to the new runtime. ⏎ 2) ) Other than the wiki and Araq's blog on destructors, there isn't much docs on it, so you are really on your
01:45:25FromGitter... own figuring out all the sharp edges. ... [https://gitter.im/nim-lang/Nim?at=5bf60a34e25cc2740522f9ba]
02:46:06*dddddd quit (Remote host closed the connection)
02:48:57zachcarterthanks rayman22201
02:50:13zachcarterthis all as me wondering whether or not I'd be better off just using Nim for gameplay code
02:50:18zachcarterand writing the core of the engine in C++
02:51:09zachcartercould also use Nim for any code where a GC wouldn't present problems
02:51:25zachcarterI'll keep going with Nim though until I find a reason that it's really becoming problematic
02:56:46leorizeanyone got experience with sharing GC-ed memory between threads?
02:57:06zachcarterleorize: you need to use channels
02:57:20zachcarteror allocate on the shared heap using createSharedU
02:57:30leorizethat won't work for string :/
02:57:33leorizebut channel might
02:58:25leorizenew runtime would make this much easier...
02:58:47zachcarteryes - I have a feeling the majority of the community shares that sentiment right now
02:59:02zachcarterbut I also think it is what it is - going to be ready when it can be
03:05:43*banc quit (Quit: ZNC - http://znc.in)
03:21:34*banc joined #nim
03:24:11FromGitter<rayman22201> lol. Yes. we all want the new runtime. But like a good pie, you can't rush it out of the oven :-P
03:24:54FromGitter<rayman22201> Holiday season in the U.S. is putting food on my mind lol
03:32:23FromGitter<rayman22201> Honestly, for your usecase @zachcarter, I still think gc:regions would be perfect. It lacks documentation but I think it's pretty stable???
03:45:23zachcarterI don't know
03:45:28zachcarterI'm actually thinking of just going gc none
03:45:32zachcarterand starting from scratch
03:45:43zachcarterI think this actually might be my best option
03:53:16zachcarterrayman2201:looking into regions now
03:57:29zachcarterI just read through - https://www.stephanboyer.com/post/60/region-based-memory-management - yes this sounds ideal
03:57:53zachcarterassuming I can supply custom allocators with gc regions
04:04:04zachcarteryeah - thanks rayman2201: should have just listened earlier to you haha - this looks perfect
04:04:13zachcarterhttps://github.com/nim-lang/Nim/blob/master/lib/system/gc_regions.nim - I mean
04:05:04zachcarterprobably didn't understand a lot of these concepts before either in my defense - but now that I do - this seems very suitable
04:52:19*nsf joined #nim
04:54:24FromGitter<rayman22201> Cool! Glad it's working for you.
04:55:23FromGitter<rayman22201> Also. Neat article on regions. I don't think I've seen that one before!
05:19:58*kapil____ joined #nim
05:46:52FromGitter<AchalaSB> Is any package is required to support the Nim code in webassembly? If yes is there any package?
05:56:44leorizeI don't think so
07:03:12*mech422__ quit (Ping timeout: 268 seconds)
07:09:30*shashlick_ quit (Ping timeout: 272 seconds)
07:10:27*mech422 joined #nim
07:19:45*mech422_ joined #nim
07:24:11*mech422 quit (Ping timeout: 268 seconds)
07:43:31*krux02 joined #nim
08:05:56*leorize quit (Quit: WeeChat 2.3)
08:16:48FromGitter<m4d3bug> Does smtp.nim support html by setting Content-Type?
08:17:01FromGitter<m4d3bug> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf665fd6621313894fcee7c]
08:17:32FromGitter<m4d3bug> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf6661ca115c91ef773dffb]
08:18:14FromGitter<m4d3bug> (https://files.gitter.im/nim-lang/Nim/MhTk/image.png)
08:18:47FromGitter<m4d3bug> Add this for attachment,doesn't work too
08:18:54FromGitter<m4d3bug> "Content-Disposition": "attachment; filename=xxxx.xls"
08:19:08FromGitter<m4d3bug> ```"Content-Disposition": "attachment; filename=xxxx.xls"```
08:24:31*jjido joined #nim
08:28:03FromGitter<gogolxdong> hmac_sha256 of nimSHA2 doesn't generate the same SHA256 digest with the Go's or anyone knows how to? Because nimSHA2's takes string parameters while Go's takes seq[byte]
08:33:51*jjido quit (Ping timeout: 260 seconds)
08:43:50*stefanos82 joined #nim
08:44:54*jacereda joined #nim
08:46:59*Pisuke joined #nim
08:47:25*MyMind quit (Ping timeout: 268 seconds)
08:48:03*jjido joined #nim
08:56:14*floppydh joined #nim
08:57:30*leorize joined #nim
08:58:02FromGitter<mratsim> You can use nimcrypto hmac: https://github.com/cheatfate/nimcrypto/blob/master/nimcrypto/hmac.nim#L222
08:58:16*vlad1777d quit (Ping timeout: 246 seconds)
08:59:04*vlad1777d joined #nim
08:59:33*jjido quit (Remote host closed the connection)
09:02:59FromGitter<gogolxdong> oh, thanks, trying.
09:05:24FromGitter<gogolxdong> It implements HKDF?
09:09:16*PMunch joined #nim
09:12:15FromGitter<mratsim> pbkdf2
09:12:36FromGitter<mratsim> impl is here: https://github.com/cheatfate/nimcrypto/blob/master/nimcrypto/pbkdf2.nim
09:13:18FromGitter<gogolxdong> yes, I noticed that, I'm trying to implement HKDF. Don't know what the difference.
09:14:08FromGitter<mratsim> in the future we might implement scrypt but no plan for hkdf so PR welcome ;)
09:14:55FromGitter<gogolxdong> result of sha256.hmac also doesn't match the one of nimSHA2 , what should I do.
09:15:17FromGitter<mratsim> nimSHA2 may have an issue then
09:16:07FromGitter<mratsim> nimcrypto is tested and I used Ethereum HMAC test vectors from here: https://github.com/ethereum/eth-keyfile
09:16:40FromGitter<mratsim> the test vectors are here: https://github.com/cheatfate/nimcrypto/blob/master/tests/testhmac.nim#L69
09:18:09FromGitter<mratsim> note that you can cast a `seq[byte]` to `string` as they have the same underlying representation (including GC) to avoid potential conversion issue
09:27:09FromGitter<gogolxdong> how ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf6766d6621313894fd5242]
09:27:53FromGitter<gogolxdong> it's the reverse of casting "hello world" to seq[byte].
09:29:08FromGitter<gogolxdong> identical conversion.
09:31:16FromGitter<narimiran> @gogolxdong it prints "llo world" on my end
09:31:27FromGitter<gogolxdong> me too
09:31:56leorize`cast` the entire seq
09:32:01leorizenot the first element
09:32:04leorizeand it'll work
09:32:31FromGitter<gogolxdong> It doesn't.
09:33:57FromGitter<gogolxdong> It's `l l o w o r l d` exactly. With 7 spaces between each letter.
09:34:07leorizehttps://ptpb.pw/0bNK/nim
09:34:55FromGitter<gogolxdong> 'u8
09:35:05FromGitter<gogolxdong> is the key.
09:36:15leorizealso, you'll have to cast the entire seq
09:36:34leorizegot "out of memory" if you just cast the address of the first element
09:36:51FromGitter<gogolxdong> sure, this is significant.
09:37:25leorizeI'm not sure if this "hack" continues to work with string and seq v2, so I usually avoids it
09:37:49FromGitter<gogolxdong> also it's the same result with Go's uses 'u8 denotation.
09:38:13FromGitter<gogolxdong> when will the v2 come out.
09:38:50leorizeonce Araq makes it works
09:39:02FromGitter<gogolxdong> sounds soon
09:39:21leorizecurrently `--gc:destructors` (which employ these newer strings and seqs) works for a simple "Hello, world!"
09:40:18leorizeit's a no go when more complex code is involved however
09:40:20FromGitter<gogolxdong> does gc:destructors mean scope collected?
09:40:52leorizeonly Araq knows :P
09:44:47FromGitter<gogolxdong> We have to refactor our production code when destructors come out.
09:48:03FromGitter<gogolxdong> but it's also close to release 1.0 and stable before Nim v2
09:49:59leorizefyi, here's the roadmap https://github.com/nim-lang/Nim/issues/7041
09:51:27*vlad1777d quit (Ping timeout: 250 seconds)
09:52:18*vlad1777d joined #nim
09:52:25FromGitter<gogolxdong> Sure.
09:52:42*jjido joined #nim
09:53:19Araqleorize, casting between seqs and strings is still possible with the destructor based runtime
09:55:00FromGitter<gogolxdong> haha, it's of great convenience.
09:55:17leorizeAraq: are we gonna get some kind of "official" support for that?
09:56:32leorizeif `cast`ing between `seq[byte]` and `string` happens a lot, then would it make sense to introduce support for it in the spec?
09:58:44*Sentreen joined #nim
10:01:17FromGitter<gogolxdong> > AFAIK, there is no significant difference between HKDF and single-iteration PBKDF2 in practice. Both effectively achieve the goal of expanding the input key to a potentially longer sequence of derived keys, in a way that does not allow the original input key to be efficiently recovered from the derived keys.
10:01:34*kapil____ quit (Remote host closed the connection)
10:02:12jaceredaAraq: do you have any comment on https://github.com/nim-lang/Nim/issues/3629#issuecomment-440953864 ? I badly want that feature and I'm willing to attempt an implementation of your proposal or mine
10:03:27FromGitter<gogolxdong> it's * in practice, wonder * in theory .
10:05:50Araqleorize, well we better have some system.toByteSeq or similar
10:06:26Araqdoesn't seem particularly future-proof to allow the cast for good
10:06:39Araq(what if we map string to std::string in C++ interop mode?)
10:07:17FromGitter<tim-st> Araq: then seq[char] would be mapped too to this type
10:08:50*dom96_w joined #nim
10:09:11Araqtim-st: huh? std::string is not std::vector<char>
10:09:59Araqdon't ruin the "perfect" C++ interop that in theory we can get/strive for
10:10:33FromGitter<tim-st> I mean these types are always the same it shouldnt matter if it is matched to string or vector
10:10:55Araqjacereda, well I like my syntax better, so if you want to implement it, please support mine :-)
10:11:30Araqhowever
10:11:49Araqalternatively you can implement 'if' in objects :-)
10:12:07FromGitter<tim-st> I think this one is the best: https://github.com/nim-lang/Nim/issues/3629#issue-120833923
10:12:25FromGitter<tim-st> it's what i tried at very first when I didnt know it doesnt work
10:12:38Araqtim-st: It is not clear to me what it means
10:12:54leorizeit just look silly tbh...
10:13:27FromGitter<tim-st> you mean regarding string?
10:13:32Araqthis feature should not be optimized for "looks good", it needs to be obvious what it means
10:13:56Araqand it needs to acknowledge that Nim is not Rust/ML/Haskell
10:14:07FromGitter<tim-st> exactly, and thus I wrote that my first assumption was that it should work
10:14:11jaceredaAraq: any previous issue requesting `if` for objects?
10:14:23Araqwe have the unprotected field accesses and need to live with them for the time being
10:15:09Araqjacereda, well it would be
10:15:13Araqobject
10:15:20Araq kind: MyEnum
10:15:27Araq if kind in {a, b, c}:
10:15:32Araq fieldA: string
10:15:41Araq if kind in {a, b}:
10:15:48Araq fieldB, etc: int
10:15:59FromGitter<tim-st> I think `when` would make more sense than `if`
10:16:14Araqno 'when' in object already exist and has a different meaning
10:16:14*dom96_w quit (Read error: Connection reset by peer)
10:16:15leorize`when` is strictly compile time in Nim's grammar afaik
10:16:31Araqand it is a runtime decision so the 'if' is correct
10:16:45FromGitter<tim-st> well, the definition is compile time but the value is runtime
10:16:59leorizebut that condition is evaluated in runtime
10:17:24Araqit's all at runtime.
10:17:25jaceredaAraq: `case` compiles down to a `switch`, this `if` would just compile a C `if`, right?
10:17:51Araqprobably but it doesn't matter
10:18:06FromGitter<tim-st> ok, I thought the compiler calculates at compile time the minimum needed size for the type
10:18:06Araqthe harder problem is how to map it C's unions
10:18:35Araqtim-st: That is true but it still has plenty of runtime aspects
10:19:43leorizeAraq: how should `system.toByteSeq` be implemented? I doubt anything out there can rival `cast[seq[byte]]` in speed
10:21:13Araqwell it would use the cast in the implementation
10:21:35jaceredaAraq: understood, I'll give it another thought
10:21:58Araqtemplate toByteSeq(x: string): seq[byte] = cast[seq[byte]](x)
10:22:11FromGitter<mratsim> I would like people to stop using string for binary blob ...
10:22:50*kapil____ joined #nim
10:23:00Araqmratsim, yeah, but that's hard and originally I thougth there shouldn't be a difference
10:23:36FromGitter<mratsim> the main issue is that when you do {.deprecated.} on an overloaded proc, you get it on all overloads :/
10:24:23*pigmej_ quit (Ping timeout: 276 seconds)
10:24:25Araqthat's a bug
10:24:28Araqeasy to fix
10:24:31FromGitter<mratsim> ah, I’m confusing with this: https://github.com/nim-lang/Nim/issues/6436
10:25:35FromGitter<mratsim> but I guess a trnsition start with that and adding seq\[byte\] to the NEP-1
10:27:19FromGitter<mratsim> and this might be useful in the stdlib as well: https://github.com/status-im/nim-byteutils/blob/master/byteutils.nim
10:41:22Araqmeh, the new Nim is more about "what we lack cannot be broken"
10:45:58FromGitter<mratsim> #brainfuck
10:46:16*dddddd joined #nim
10:59:12FromGitter<alehander42> https://github.com/nim-lang/Nim/issues/3629#issue-120833923 is absolutely the best syntax imo
10:59:24FromGitter<alehander42> i totally don't get this "where is this field shared" thing
10:59:30FromGitter<alehander42> 90% of the time i care about
10:59:36FromGitter<alehander42> which fields does this kind have
11:00:37Araqso read it again, I don't understand how you can not understand it
11:01:20FromGitter<alehander42> i understand it, I just don't get how is this a more common usecase
11:01:48FromGitter<alehander42> I almost never ask myself "where is this field" shared, because usually I know the current `kind` value
11:02:08AraqI don't want to repeat myself
11:03:01Araqyglukhov[m], ping
11:03:21FromGitter<yglukhov> hey
11:03:36AraqI'm looking at https://github.com/nim-lang/Nim/issues/9716#issuecomment-440444324
11:04:11Araqand I wonder ... since we transform it into a state machine with explicit frames on the heap that are linked
11:04:35FromGitter<alehander42> Araq, well every other language with adt-s defines the fields together with the discriminator
11:04:43FromGitter<alehander42> it's not such a unique opinion
11:04:57Araqcould it be that every new loop iteration causes a new frame to be allocated and linked?
11:05:13Araqthen the GC has no chance and it leaks until the loop ends (which is way too late)
11:05:26FromGitter<alehander42> but nvm, I also agree that the other design would do, one can write a macro around that
11:06:01Araqalehander42, yes, I know how ML works, thanks. Nim doesn't work like this.
11:07:37FromGitter<alehander42> ok, if you agree on the other design, let jacereda do it, people like me can use a macro on top of it, everybody is happy
11:07:44FromGitter<yglukhov> Araq: oh my. there's a lot of text there. what should i focus on? :)
11:07:56FromGitter<alehander42> (the nim-ish design)
11:10:02Araqwrong link, try https://github.com/nim-lang/Nim/issues/9716#issuecomment-440399661
11:11:19*Vladar joined #nim
11:12:20Araqthe downloaded file is about 1MB
11:12:41Araqand so the memory should never grow beyond, let's say, 8 MB
11:14:29FromGitter<yglukhov> Araq: well loops shouldn't be a problem, because env fields are eventually overwritten as iterations go, so the old ones should no longer be referenced. I recall there was a bug in our server that it leaked GBs of mem in 64bit mode, but in 32bits it never exceeded a few hundred mb. That was some time ago, and we switched to 32bit, and never revisited since.
11:15:30FromGitter<yglukhov> do you agree about "loops shouldnt be a problem" part?
11:15:53FromGitter<yglukhov> anyway, i'll have a look at this.
11:18:03AraqI agree that in theory there is no problem
11:18:17Araqin practice it would explain exactly the behaviour I'm seeing
11:20:09FromGitter<yglukhov> well currently i can't imagine how that could happen. i mean what kind of codegen could lead to the "loops" problem.
11:20:34FromGitter<yglukhov> but i can reproduce the issue. thats good already.
11:22:23Araqthis runForever() after the asyncCheck(test(url)) escapes me already
11:22:35Araqno idea how this works
11:22:50Araqah nvm
11:24:47Araqno, I don't get it
11:26:12FromGitter<yglukhov> why? that's perfectly normal way of using it :)
11:26:31*dom96_w joined #nim
11:26:46Araqwell runForever never stops
11:26:54FromGitter<yglukhov> true
11:26:56Araqwhat if I wanna make 5 downloads and then stop?
11:27:03Araqdrain() doesn't work either
11:27:11FromGitter<yglukhov> then you don't use runForever =)
11:27:51Araqok, waitFor it is
11:28:09*dom96_w quit (Changing host)
11:28:09*dom96_w joined #nim
11:28:42FromGitter<yglukhov> actually maybe runForefer will return/raise when there's nothing to poll, i don't remember exactly.
11:28:58dom96_wAt a hackathon today, hopefully will add support for Nim to FB's build system Buck :)
11:29:35Araqlet url = "https://jsonplaceholder.typicode.com/photos"
11:29:35AraqwaitFor(test(url))
11:29:35AraqGC_fullcollect()
11:29:35Araq echo formatSize getOccupiedMem()
11:29:39*kklas joined #nim
11:29:52Araqit's like I say, after the loop the GC can free the memory
11:30:51dom96_wAre you debugging async mem leaks?
11:30:56Araqyup
11:31:16Araqfinally have something we all can reproduce
11:31:32dom96_wAwesome
11:32:45dom96_wIf you want to make 5 downloads why don't you add a counter var?
11:33:13dom96_wIt's not like poll() is equivalent to one download
11:33:25AraqI have a counter var
11:33:35Araqand I now understand the program, everything is fine
11:33:53Araqso ... from the GC's perspective it is a logical memory leak
11:34:06dom96_wlink to the code?
11:34:18Araqhttps://github.com/nim-lang/Nim/issues/9716#issuecomment-440399661
11:35:28*theelous3 joined #nim
11:35:46*theelous3 quit (Changing host)
11:35:46*theelous3 joined #nim
11:39:11dom96_wso where is the leak?
11:39:43Araqmy hypothesis is in the closure iterator transformation
11:40:28dom96_wI'm curious how you came to the conclusion that from GC's perspective it's a logical leak
11:40:44Araqbecause the GC can free the memory after the loop
11:41:03Araqthe loop runs for 10_000 iterations though and so that's way too late
11:41:27Araqit feels like every loop iteration keeps the data of the previous iterations alive
11:42:01Araqif it were a GC leak, the GC would never free it.
11:42:37Araqbut it does, as soon as 'start' returns
11:44:16*theelous3 quit (Remote host closed the connection)
11:44:17Araqand now I'm getting a nice crash in asyncnet.nim line 221
11:44:44*theelous3 joined #nim
11:45:21dom96_wYeah. so it seems the GC isn't optimised for long running procedures
11:45:50Araq"optimised for"? it's not a GC problem, it's a codegen bug
11:46:06Araqwell IMO, I could be wrong of course
11:46:44Araqbut now appeaseSsl crashes, any idea why?
11:48:49dom96_wwhat error?
11:49:10Araqasyncnet.nim(221) appeaseSslIter
11:49:10AraqSIGSEGV: Illegal storage access.
11:49:37dom96_wweird, can you reproduce it?
11:49:45dom96_wDid you change something that could have caused this?
11:49:59Araqno, but I'm likely misusing the API
11:50:06Araqwriting a real bug report...
11:52:16*Vladar quit (Remote host closed the connection)
11:52:43*Vladar joined #nim
11:53:39*theelous3 quit (Ping timeout: 268 seconds)
11:53:55Araqhttps://github.com/nim-lang/Nim/issues/9785
12:07:19*NimBot joined #nim
12:07:39FromGitter<yglukhov> Araq: found the problem
12:08:06FromGitter<yglukhov> it is codegen indeed. along with mem usage, log body.len :)
12:09:39FromGitter<yglukhov> however, i'm not sure how it worked before the new transformations... if it worked at all..
12:11:25FromGitter<yglukhov> looks like a showstopper to me.
12:11:51Araqit's fair to assume it never worked properly
12:11:56Araq:D
12:14:04FromGitter<yglukhov> i can fix it if you tell me how to convert `let x` or `var x` to `pretendAsItIsDeclarationAndInit(x)`
12:14:28Araqwell it's
12:14:39Araqvar closureEnv.x
12:15:07Araqthe old transformation did use that one
12:15:41FromGitter<yglukhov> oh really? interesting. ok ill try.
12:24:29*jjido quit (Remote host closed the connection)
12:27:41*theelous3_ joined #nim
12:49:24FromGitter<yglukhov> Araq: I've checked it and that's what the transformation currently does. `var :envP.a3: int`. So is it the backend issue then?
12:52:43dom96_wis install.sh in the release archives deprecated now?
12:52:57dom96_wwondering if I should use it or if I need to use `koch install`
12:55:04*Vladar quit (Read error: Connection reset by peer)
12:55:31*Vladar joined #nim
12:59:06dom96_wAraq ^
12:59:48dom96_w`koch distrohelper` I guess
13:00:07dom96_wWe should properly deprecate install.sh if it's truly obsolete
13:00:17dom96_wWhich this suggests that it is https://github.com/nim-lang/Nim/issues/5912#issuecomment-305121774
13:03:21Araqyglukhov[m], hmmm
13:03:31Araqprobably but what does it mean?
13:03:44Araqthat var env.foo = value is ignored?
13:04:05Araqdom96_w, yeah, we decided for installation into /usr/bin people should use their package managers
13:04:31FromGitter<yglukhov> Araq. no assignment is fine. it's just vars with type and no assignment
13:04:44FromGitter<yglukhov> `var s: string`
13:05:25Araqah these need to be reset() ?
13:05:33FromGitter<yglukhov> yup
13:06:25Araqbut then if the code does var buffer = "" the bug should disappear, right?
13:06:32FromGitter<yglukhov> yes
13:07:19Araqindeed
13:07:23Araqinteresting
13:07:38Araqyeah ok, codegen bug, will add a [backport]
13:07:53Araqand hopefully we can release 0.19.2 this weekend
13:08:07FromGitter<yglukhov> cool. you'll take care of it?
13:08:36Araqyeah
13:08:44FromGitter<yglukhov> cool
13:09:09Araqdom96_w, that means only some async code is affected
13:09:43dom96_wRemind me to recompile NimForum with the fix
13:09:46FromGitter<yglukhov> Araq: i've added a test for this to tyieldintry. I can push it to a branch if you want.
13:09:47dom96_wI sorta doubt this was the cause though
13:09:56Araqyglukhov[m], yes please
13:10:04dom96_wI'm guessing this was introduced by yglukhov's changes to the iterators?
13:10:05Araqdom96_w, yeah, my point
13:10:14Araqno, it is an old codegen bug
13:10:24Araq0.18 and prior should also be affected
13:10:32federico3Araq: do you plan to generate csources etc for RISC-V as well? (see #7541)
13:11:01federico3I can run tests if needed
13:11:36Araqfederico3, I don't know, I run 'koch xz'
13:11:55Araqand it builds the C sources for what the config says
13:12:03dom96_wAraq: So I need to install these files into an install directory, what should I use `koch install`? right?
13:12:30Araqneither 'koch install' nor install.sh is really supported but I would go with install.sh
13:13:06Araqbecause you can easily skim over what it does
13:14:14FromGitter<yglukhov> Araq: done. branch yglukhov-test-9716
13:14:15zachcarterrayman22201: one reason I think regions may not be what I need, and a gc-less approach is a better one to take, is the fragmentation that article mentions
13:14:26zachcarteror maybe it does
13:15:01zachcarterthis wikipedia article states - programs that contain many sparse regions will exhibit internal fragmentation - https://en.wikipedia.org/wiki/Region-based_memory_management
13:15:05zachcarterthat scares me a bit
13:15:29AraqIME Nim's allocator got really good at fighting fragmentation problems and it's usually something on top of alloc/dealloc that introduces problems
13:15:39FromGitter<mratsim> why don’t you allocate an big arena and slice chunks from it?
13:15:48FromGitter<mratsim> a*
13:16:02zachcarterI could try it
13:16:38FromGitter<yglukhov> maybe i should do it in a pr though...
13:16:51zachcarterI'm studying the foundation library from bitsquid - https://bitbucket.org/bitsquid/foundation
13:17:28zachcarterit features a number of different allocators
13:18:31zachcarterwhich I'm not sure I'd even need if I went with regions
13:18:41zachcarterbut I'm also not sure whether or not these allocators do anything special
13:18:52FromGitter<mratsim> doesn’t seem like it
13:19:03FromGitter<mratsim> default_allocator is a simple one
13:19:17FromGitter<mratsim> scratchspace allocator is just an arena
13:19:24zachcarterokay
13:19:37FromGitter<mratsim> and temp allocator is using array[64, byte] as scratch space
13:19:47FromGitter<mratsim> 64 being an arbitrary number.
13:20:32Araq64 bytes are good enough for everybody
13:20:35*nsf quit (Quit: WeeChat 2.3)
13:20:46FromGitter<mratsim> not me :P
13:21:14zachcarterhttps://github.com/dbartolini/crown/tree/master/src/core/memory - is another library I'm referencing, and he has another slew of allocators
13:21:24FromGitter<mratsim> my temp alloc are in the 5~30MB range :D
13:21:39zachcarterlinear, pool, proxy, and stack
13:21:46zachcartertemp allocator I believe is the same as the one from the foundation lib
13:22:44FromGitter<mratsim> temp_allocator seems like stack allocator with destructors
13:22:57FromGitter<mratsim> pool_alloc is similar to the scratch allocator
13:23:38zachcarterneed to learn all this stuff
13:24:33zachcarterand determine whether it's going to cause me any issues - but it doesn't sound like it
13:24:44FromGitter<mratsim> it’s not hard. Basically you can have automatic memory management = stack allocation, or going through the OS = heap allocation
13:24:47zachcarterI was worried that there was a certain magic to how his allocators were laying out things in memory
13:25:07zachcarterbut it doesn't seem that's the case - sounds like they're just standard implementations of allocators that are commonly used
13:25:15FromGitter<mratsim> for heap allocation, either it’s GC-managed, or manually managed, or destructor managed
13:25:20zachcarterright
13:25:44zachcarteroh I get most of that stuff (I think anyway) - I meant more in terms of how different allocators are implemented / what use cases are for different implementations
13:25:52FromGitter<mratsim> also often, instead of returning chunks to the OS because you know that you will re-use them a lot, you keep them in a “pool"
13:26:08zachcarterlike object pooling - or connection pooling
13:26:48FromGitter<mratsim> Use-case: stack allocation - very fast, no exceptions, no dealloc needed, limited stack space, max size must be known at compile-time
13:26:58FromGitter<mratsim> heap alloc: everything else
13:27:32FromGitter<mratsim> pool alloc: when you need heap alloc often due to size, but you know that you will alloc/dealloc often in a tight loop
13:28:01zachcarterthank you - that makes sense
13:28:20FromGitter<mratsim> I don’t really see the point of scratch/temp alloc, for me it’s served by pool allocation
13:28:29Araqzachcarter, relax, it doesn't really matter that much, there is only "bump pointer allocator" vs "traditional size classes"
13:28:45zachcartergotcha
13:29:03Araqand size classes can work with bitmasks or linked lists
13:29:47Araqand nobody uses bitmasks because they are not as fast as a bump pointer allocator and not as general as linked lists
13:30:29zachcartergotcha - okay I'm going to try to play with regions this morning
13:30:42zachcarterthank you both for the explanations and reassurance
13:38:37*theelous3_ quit (Ping timeout: 246 seconds)
13:49:54FromGitter<arnetheduck> @Araq tested `storage` vs `getStorageLoc` - by echoing whenever `storage` is read and they don't match - there's indeed a large number of cases where there's a discrepancy, and I'm not confident enough with the logic to go fix them.. pushed https://github.com/nim-lang/Nim/pull/9777 without the storageloc removal however
13:50:27Araqah ok, thanks for looking into this
13:56:17*theelous3 joined #nim
14:00:34*jacereda quit (Ping timeout: 250 seconds)
14:06:37dom96_wFor some reason I needed to add -lpthread to Nim's config
14:07:01dom96_wThis is the sort of error I got https://github.com/linux-test-project/ltp/issues/255
14:07:05dom96_wcentos-specific issue?
14:14:42leorizethere's a `{.link: "-lpthread".}` in threads.nim for Linux
14:14:49leorizeso I'm not sure why you'd need it
14:16:06dom96_wyeah, it's odd. This was during the compilation of `koch` as well
14:16:12dom96_wwhich AFAIK doesn't need threads
14:16:54*theelous3 quit (Changing host)
14:16:54*theelous3 joined #nim
14:24:02Araqindeed, it doesn't
14:25:08dom96_whuh, install.sh doesn't install nimble etc.?
14:27:32Araqtold you it's unsupported
14:27:46dom96_wso what do I use instead?
14:28:04Araqwell 'koch tools' builds Nimble
14:28:21dom96_wI wonder if I can get away with simply copying everything
14:28:45Araqyou unzip Nim into your ~ and either adapt PATH or you create symlinks in /usr/bin
14:29:28dom96_wThat doesn't scale
14:29:50Araqthat phrase lost its meaning long ago
14:30:45dom96_wNo, I mean literally
14:30:56dom96_wI'm trying to get Nim into the hands of thousands of people
14:31:08dom96_wIt needs to scale
14:31:36Araqas I said, for /usr/bin use your package manager
14:32:00dom96_wI'm effectively the packager in this situation
14:32:10euantorCreate a deb package or an RPM then
14:32:35dom96_weuantor: That doesn't help me.
14:32:46dom96_wI am creating a package, sort of.
14:32:57Araqwell 'koch distrohelper' is to help you create a package
14:32:59dom96_wI'm wondering how to ensure I get everything that's needed into the package
14:33:24euantorAnd that's not too useful either ;) Knowing what kind of environment it's meant to run in and who it's targeted at might help
14:33:32dom96_w`distrohelper` takes a "bin dir"
14:33:39dom96_wbut I can see that the code doesn't use it...
14:34:23dom96_weuantor: Custom environment used at my company
14:35:19euantorCouldn't you just provide a zip or something with the built binaries in it then and drop it into somewhere in the `PATH`?
14:38:00dom96_wNot really
14:39:11euantorOk, and why can't you use choosenim which you created for this task?
14:42:39dom96_wBecause that would require everyone to install Nim manually
14:42:45dom96_wThat's not how things are done here.
14:43:19euantorIf you were using Windows you could do it via the domain server
14:44:36*vlad1777d quit (Ping timeout: 252 seconds)
14:44:37Araqwell I'm not saying that it will work well
14:45:02Araqbut the solution you're supposed to use is 'koch distrohelper', build a .dep or similar and install it this way
14:46:14dom96_wwell, federico is manually copying nimble etc.
14:46:16dom96_wWhich IMO sucks
14:46:24dom96_wBut no better solution
14:46:33dom96_wSo I'll do the same
14:46:45federico3heh, and that's what makes Nim difficult to package
14:47:14AraqPRs for 'koch distrohelper' are welcome
14:47:28Araqideally we will also patch travis to test this feature
14:47:29*narimiran joined #nim
14:48:05dom96_wYeah. It's a painful process. But I think there is a certain level of pain when packaging anything
14:51:01zachcarterwhen compiling with `-d:gcRegions` I'm getting: `Error: system module needs: nimGCvisit`
14:51:22Araqzachcarter, the switch is --gc:regions
14:51:58zachcarterah thank you my bad
14:52:24zachcarterI guess it was working then previously - I wasn't sure haha but I believe that's how I had my nims file before `switch("gc", "regions")`
14:52:56zachcarterI expected it to crash or do something different - which is what made me start fiddling with the switch
14:59:21*seni joined #nim
14:59:38leorizeNim is surprisingly easy to package actually
15:00:09*nsf joined #nim
15:01:08leorizeeverything fits in a folder and you can just symlink what you need to the correct places
15:14:22FromGitter<yyyc514> `method `message:add`*` how do i then call this?
15:15:58zachcarterI'm not understanding something here - https://gist.github.com/zacharycarter/cd9e94026c582d99cbd1e85577515520
15:16:48zachcarterI'm using a MemRegion, and the withRegion template - and I expected the region's memory usage to change at some point during the program's execution - but it's always 0
15:17:06zachcarterso I'm assuming I'm either doing something incorrectly or misunderstanding something completely :P
15:28:28Zevvshould hasKey() on a Table to throw IndexError?
15:28:37Zevvs/be able to/
15:29:28narimiranZevv: `hasKey()` is bool
15:29:58narimiranin what situations would you like to see that error?
15:30:12ZevvI would not, but I get it
15:30:15Zevvunexpectedly
15:30:27narimiranpost a short example please
15:30:53FromGitter<Varriount> @zachcarter Is this a memory map?
15:32:07zachcarter@Varriount: I'm just playing with --gc:regions
15:32:14zachcarterhttps://github.com/nim-lang/Nim/blob/devel/lib/system/gc_regions.nim
15:32:16Zevvnarimiran: http://paste.debian.net/1052817/
15:32:48narimiranZevv: just by looking at it, without running — your table is not initialized
15:32:55ZevvAw dang
15:32:56narimiranuse `initTable`
15:33:00Zevvyessss
15:33:05Zevvthat bit me before
15:35:44*shashlick_ joined #nim
15:52:09FromGitter<alehander42> @yyyc514 why would you do this
15:52:11FromGitter<alehander42> :D
15:55:28*leorize quit (Quit: WeeChat 2.2)
15:56:03*PMunch quit (Quit: Leaving)
15:59:56*leorize joined #nim
16:03:29dom96_wnimsuggest still gives the same output for -v as the nim compiler :D
16:33:32*arnetheduck joined #nim
16:33:43*arnetheduck left #nim (#nim)
16:35:35*shpx joined #nim
16:37:31*ng0 joined #nim
16:43:27AraqI fixed the async leak but now tasyncdiscard fails
16:46:13*narimiran quit (Remote host closed the connection)
16:49:43*narimiran joined #nim
17:07:57narimiranAraq: your fix for #9716 is in your branch — what is stopping the merge into devel?
17:08:20narimiranaha, "but now tasyncdiscard fails"
17:10:17*seni quit (Quit: Leaving)
17:28:19Araqyeah yglukhov[m], please take a look
17:31:03*Trustable joined #nim
17:42:07*shpx quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:43:19narimirani don't know if he checks his matrix account (i know that i don't do very often), so here goes gitter ping: @yglukhov
17:43:37FromGitter<yglukhov> hey guys
17:43:59FromGitter<yglukhov> should i look at your fix, Araq? where is it?
17:44:30Araqaraq-fixes-9716 branch
17:44:34FromGitter<alehander42> those pings are really effective
17:44:34narimiranhttps://github.com/nim-lang/Nim/tree/araq-fixes-9716
17:45:13AraqI should probably code it differently and have looked at the C code diffs though
17:49:41serialdev[m]Hey guys first of all been trying out nim today and it is significantly nicer to work with than current alternatives
17:50:30*serialdev[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/jgIIluRxzbjQyhSXAdRPPzTf >
17:50:39serialdev[m]dont know if any of you could give me a hand
17:51:12FromGitter<Varriount> Sounds like a problem with the nake file for nimx
17:51:53narimiranserialdev[m]: we (on IRC) don't see your message. i guess it is some long code-paste. better to use some 3rd party service for that, and give us a link
17:52:27narimiran(ok, clicking the link opens up the whole message, no need to resend it)
17:52:37serialdev[m]no further info on the nake files on nimx docs so I just have it with pretty much naketools imported
17:52:38serialdev[m]import nimx/naketools
17:52:44serialdev[m]Good to know narimiran
17:53:23narimiranunfortunately i have no experience with JS so cannot help you there
17:56:02serialdev[m]I will post it if I figure it out :) thanks
18:01:19FromGitter<yglukhov> Araq: i see the problem. :state got inited in the beginning of the state loop, inside it. that's likely my bug.
18:03:06FromGitter<yglukhov> serialdev: oh I haven't yet seen this. but js is broken now anyway, sorry.
18:04:51*nsf quit (Quit: WeeChat 2.3)
18:05:24Araqis that my fault?
18:06:36FromGitter<yglukhov> Araq: err.. not sure yet...
18:07:15AraqI mean the JS breakage
18:08:34FromGitter<yglukhov> oh, sure. https://github.com/nim-lang/Nim/issues/9644 and https://github.com/nim-lang/Nim/issues/9643 to name a few :)
18:11:01Araqhttps://www.zdnet.com/article/intel-cpus-impacted-by-new-portsmash-side-channel-vulnerability/
18:11:38AraqOh ok, but that's just some 0.19.0 pain
18:13:25FromGitter<yglukhov> what puzzles me is how tyieldintry managed to succeed with that kind of issue.
18:14:03Araqfor me it's why only *one* async test fails due to it
18:14:20FromGitter<yglukhov> yeah, exactly.
18:14:44*Trustable quit (Remote host closed the connection)
18:14:50FromGitter<yglukhov> well the c code is clearly wrong. so wrong that it should fail everything async
18:15:52FromGitter<yglukhov> oooh i think i get it
18:16:53FromGitter<yglukhov> its because of the lambdalifting subtlety. lamdalifting+closureitertransform can sometimes be reordered.
18:16:59FromGitter<yglukhov> and that's the case.
18:17:33FromGitter<yglukhov> i'm not sure 100%, but that's my best guess.
18:37:18FromGitter<yglukhov> Araq: ok, found the bug in the transformation.
18:39:38*theelous3 quit (Ping timeout: 245 seconds)
18:50:43FromGitter<yglukhov> Araq: however i'm not sure how to fix this. Here's the problem. If lamdalifting was not done, we add stup local vars in nkVarSection at the beginning of the loop, so they are lifted later. Now the place where we add them was pretty arbitrary (and i didn't notice the possibility of such outcome), however now that makes a difference. I could add those to state0, that would be the "logical" fix, but we really don't want
18:50:43FromGitter... resets for them...
18:51:08*MightyJoe joined #nim
18:51:39*cyraxjoe quit (Ping timeout: 264 seconds)
18:57:45Araqwell we can special case ':state' and not reset it in the backend
19:00:09*theelous3 joined #nim
19:01:52*theelous3 quit (Remote host closed the connection)
19:07:37*floppydh quit (Quit: WeeChat 2.3)
19:09:41*krux02 quit (Remote host closed the connection)
19:10:03FromGitter<yglukhov> Araq: there are temps as well, not only state
19:11:09FromGitter<yglukhov> and :curExc, :tmpResult, :unrollFinally
19:13:18FromGitter<yglukhov> ok, I will add them to state0 anyway, we can revisit this "optimization" part later.
19:20:28FromGitter<alehander42> ahhh elif is my enemy
19:31:55FromGitter<alehander42> dynamic languages are a nightmare, let me tell you that
19:31:57FromGitter<alehander42> </rant>
19:32:07narimirantell us more :)
19:32:21narimiranand what's the problem with elif
19:38:09*narimiran quit (Remote host closed the connection)
19:39:37*narimiran joined #nim
19:40:24*miran joined #nim
19:42:27*miran quit (Remote host closed the connection)
20:01:14*nsf joined #nim
20:06:58*shashlick_ quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
20:10:22serialdev[m]quick question is there an equivalent to type() from python? or anything resembling the introspection module ?
20:10:44serialdev[m]I feel like improving the emacs integration, so having access to that would be awesome
20:15:42FromGitter<yglukhov> Araq: done
20:17:51dom96_wAraq: please make sure to backport the fix for Nimble not being compiled in release mode
20:20:34Araqserialdev[m], for introspection you use nimsuggest
20:20:44Araqdom96_w, oh hmmm
20:21:08Araqthat should have been backported already
20:30:52FromGitter<yglukhov> Araq: btw, i ended up adding those not to state0, but in the limbo between state jump and state0, so that code gets never executed, and likely will be dead-eliminated by the C compiler. That's good for now, but will have to be moved elsewhere when we change state jump to switch-case.
20:32:00serialdev[m]thanks!
20:32:26Araqyglukhov, can't follow you
20:33:46FromGitter<yglukhov> not a big deal. seen my commit?
20:36:33FromGitter<yglukhov> what i mean is, the codegen is now like this:
20:38:22FromGitter<yglukhov> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf713be97a8982b9a4b1953]
20:38:39narimiranserialdev[m]: until https://github.com/nim-lang/Nim/pull/7100 is merged, if you want to just print some types, use `typetraits` module
20:40:39Araqcan't be bothered, I'm trying to make this terrible IC work. what an annoying piece of junk
20:43:47Araqah...
20:44:02Araqwhy did this ever work then...
20:44:18FromGitter<yglukhov> ic - integrated circuit? :)
20:44:31Araqincremental compilation
20:45:33FromGitter<yglukhov> Araq: ok, now i can't follow. let me try that again. the gist above is the codegen after my fix.
20:45:43FromGitter<yglukhov> the one that was before my fix is like this
20:46:32FromGitter<yglukhov> ```while true: ⏎ :env.state = 0 ⏎ jumpToState :env.state ⏎ STATE0: ...``` [https://gitter.im/nim-lang/Nim?at=5bf715a8baf43f2b9b5a5856]
20:58:41FromGitter<Araq> ok
20:58:51Araqthat makes sense
21:07:38*nsf quit (Quit: WeeChat 2.3)
21:14:43*theelous3_ joined #nim
21:14:48FromGitter<yglukhov> the one that was before *your* fix is this ⏎ ⏎ `````` [https://gitter.im/nim-lang/Nim?at=5bf71c48c6cf4524d15f993a]
21:24:07zachcarteram I doing anything correct here haha? - https://gist.github.com/zacharycarter/e186bde161ed76eeaa5359e45a039ad8
21:31:13*kungtotte joined #nim
21:31:50*kungtotte quit (Client Quit)
21:34:41*kungtotte joined #nim
21:42:18*narimiran quit (Ping timeout: 252 seconds)
21:44:31*kungtotte quit (Quit: leaving)
21:45:19*kungtotte joined #nim
21:58:24*stefanos82 quit (Quit: Quitting for now...)
22:13:11*Vladar quit (Remote host closed the connection)
22:37:06*blarghz[m] joined #nim
22:39:12zachcarterokay - I made a very simple example with a heap allocation - https://gist.github.com/zacharycarter/30f81e39a3da4267cf86da3b65771ac1
22:40:16zachcarterand I can definitely see the gc_region calls being made - https://imgur.com/a/1o2X0aF
22:40:52zachcartercurious though about how to visualize what's going on memory wize
22:43:08zachcarterokay I see the problem - I was running massif without stack profiling on
22:43:36zachcarteronce I turn it on - I see the stack allocations
22:44:59zachcarternow I need to figure out how to make this work across threads - my first stab at it didn't work, going to eat and then try again
22:47:06*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:47:13*kklas quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:05:53*kungtotte quit (Ping timeout: 245 seconds)
23:21:58*kapil____ quit (Quit: Connection closed for inactivity)
23:24:59*vlad1777d joined #nim
23:28:41*kungtotte joined #nim
23:42:59*shpx joined #nim
23:51:18*Ven`` joined #nim