<< 16-01-2020 >>

00:01:59rayman22201in theory. I was hoping to proof of concept without re-building the new Future type though. it looks like that isn't going to work out unfortunately :-(
00:03:26Araqshould be pretty simple?
00:03:33*chenhq2005 quit (Ping timeout: 260 seconds)
00:03:45Araq'owned' is not a thing, you have GC_ref/unref
00:04:05rayman22201in arc?
00:05:34rayman22201oh shit
00:07:06disruptekis unown impl for arc?
00:07:12disrupteki can't remember.
00:07:27rayman22201it didn't error, but it didn't seem to do anything
00:08:19rayman22201where do I check?
00:08:41disrupteki dunno 'cause leorize's plugin is broken.
00:09:01leorizedisruptek: ?
00:09:11leorizehave you updated?
00:09:13disruptekleorize: sorry; rayman22201 made me.
00:09:28*krux02_ quit (Ping timeout: 245 seconds)
00:09:35leorizeI fixed the system.nim highlighting bug sometime ago :P
00:11:25rayman22201I see it, but idk if that means it's implemented for arc lol
00:12:38disruptekarc vs. orc is a disaster on even that tiny amount of async.
00:13:07disruptekit's a 16k line diff.
00:16:58rayman22201the segv I'm getting makes me think unown doesn't work in arc
00:17:12rayman22201but I also shouldn't be getting a segv, so that's confusing lol
00:17:15FromDiscord<Clyybber> guddamnit, my algorithm is still wrong
00:17:25FromDiscord<Clyybber> this stuff is hard
00:18:42*zielmicha__ quit (Ping timeout: 246 seconds)
00:18:48*matti quit (Read error: Connection reset by peer)
00:20:12*matti joined #nim
00:20:19*zielmicha__ joined #nim
00:22:36FromDiscord<Clyybber> maybe sleeping solves it for me
00:22:38FromDiscord<Clyybber> gn8
00:22:59*krux02_ joined #nim
00:24:39rayman22201if you are interested disruptek. Why does this cause a segv?
00:25:50rayman22201specifically the segv is here: https://github.com/nim-lang/Nim/blob/d19206755bbbb6482b3e29499eda92d3d97b2f1b/lib/pure/asyncfutures.nim#L172
00:26:04rayman22201which implies the callback ptr was moved
00:26:54rayman22201my thought was that maybe it sinks on `b[] =`, but unown doesn't seem to help
00:30:49rayman22201 eqsink___tz9aAourd6w9cPKT5l11V9cEw_2((&(*(*b))), T5_);
00:30:54rayman22201it is doing a sink
00:31:03rayman22201son of a biscut
00:31:11*krux02_ quit (Remote host closed the connection)
00:31:49rayman22201how do I prevent the `=sink` from happening
00:38:26rayman22201`=lent` doesn't seem to work
00:39:57rayman22201everyone is asleep I guess
00:42:23*matti quit (Ping timeout: 245 seconds)
00:42:34*nuxdie quit (Ping timeout: 252 seconds)
00:43:13*LyndsySimon quit (Ping timeout: 245 seconds)
00:43:27*npgm quit (Ping timeout: 272 seconds)
00:43:38*matlock quit (Ping timeout: 245 seconds)
00:43:38*d10n-work quit (Ping timeout: 245 seconds)
00:44:24*surma quit (Ping timeout: 252 seconds)
00:46:28*r4vi quit (Ping timeout: 248 seconds)
00:47:02*zielmicha__ quit (Ping timeout: 260 seconds)
00:47:02*nimblepoultry quit (Ping timeout: 260 seconds)
00:47:02*Hotbees quit (Ping timeout: 260 seconds)
00:50:25*msmorgan quit (Ping timeout: 272 seconds)
00:51:42*MD87 quit (Ping timeout: 260 seconds)
00:52:52*euantor quit (Ping timeout: 248 seconds)
00:53:23*zielmicha__ joined #nim
00:57:38*zielmicha__ quit (Ping timeout: 240 seconds)
01:16:00*icebattle quit (Read error: Connection reset by peer)
01:19:58*icebattle joined #nim
01:36:02ZevvI whish
01:38:04FromGitter<Varriount> Hi Zevv
01:39:33leorizerayman22201: probably an optimization bug?
01:51:49*r4vi joined #nim
02:00:43*r4vi quit (Ping timeout: 272 seconds)
02:02:41disruptekrayman22201: i'm up.
02:02:58disruptekthat's the bit i rewrote, but you're in the wrong branch, no?
02:11:33*chenhq2005 joined #nim
02:15:26rayman22201what did you rewrite disruptek? I'm on the latest devel (which has the latest fixes. araq merged them before he went to sleep)
02:15:57disruptekthat clause in call, but it was before i learned that unowned does nothing.
02:16:55rayman22201I think that's part of the bug here. unown needs to be fixed
02:17:56disrupteki dunno, it's more correct to write the code the way we want it written.
02:18:03*hlavaty` joined #nim
02:18:05disruptekthat was your idea and i think it's right.
02:18:29rayman22201Fair point
02:18:37rayman22201still seems like a bug though
02:18:47disruptekwhat i did was to just move the ref and free the callback.
02:18:54disruptekthen recurse.
02:19:15rayman22201I don't understand?
02:19:42disrupteki think that, due to the way arc works, it won't get cleaned up before it recurses.
02:20:43disruptekwe're talking about running the callbacks, right?
02:21:07rayman22201no. I'm talking about properly freeing the callback after it's done
02:21:21disruptekright, the same code though, right?
02:21:27rayman22201not just any callback, the specific callback that async generates
02:21:40rayman22201no. If you create a future and add a call by hand, it works fine
02:21:48*hlavaty quit (Ping timeout: 260 seconds)
02:22:04disruptekit's like like 180 in asyncfutures, right?
02:22:54rayman22201That's where my example crashes, but that isn't where the bug is
02:23:35disruptektell me where to look.
02:23:50rayman22201the bug is that line 45 of my example code sinks the callback, so when it finally gets to asyncfutures:172, the pointer has moved and is no longer valid.
02:24:04rayman22201line 45 of this example
02:24:26rayman22201and that line causes an example because it generates an eq_sink
02:24:35rayman22201causes the bug even
02:25:00disruptekyeah, so it's destroying b.
02:25:30rayman22201no, it's not. It's moving asyncProcNimAsyncContinue_400016 into b, and destroying future.callback
02:25:49disruptekif there was anything in b before, it's gone now.
02:26:14rayman22201when is "before" and when is "now"?
02:26:20rayman22201not true
02:26:41disrupteksink will destroy any contents before it assigns rhs to lhs.
02:27:05rayman22201there was nothing in b to begin with, look at line 52
02:27:33rayman22201the entire point of b was to give the calling function control over the lifetime of `asyncProcNimAsyncContinue_400016`
02:27:48rayman22201it's an out param
02:27:57disruptekokay, holdon. lemme actually put this somewhere where i can read it.
02:28:59disruptekyeah, this shouldn't be hard to figure out.
02:29:28rayman22201well, I'm pretty sure it's a sink optimization bug
02:29:33rayman22201but idk how to fix those
02:30:12leorizewell you can even tinker with the code a bit more
02:30:20rayman22201it brings me back to my original question. can I force line 45 of that example to not sink?
02:30:25disruptekone good thing is that it doesn't crash in orc.
02:30:48rayman22201it does for me
02:30:58disruptekyou incref but i think we should fix arc instead, if possible.
02:31:04*chenhq2005_ joined #nim
02:31:19rayman22201both orc and arc crash the same way for me
02:31:45disruptekoh, you're right.
02:32:38*msmorgan joined #nim
02:33:17*dddddd quit (Ping timeout: 265 seconds)
02:33:37rayman22201heres the thing. this is me being lazy. this is a simple hack to prove where the leak is. I.E. I think the leak / cycle is b/c of `asyncProcNimAsyncContinue_400016`
02:34:18*chenhq2005 quit (Ping timeout: 268 seconds)
02:34:28leorizerayman22201: I can't help but realise that b wasn't allocated
02:35:08rayman22201It doesn't need to be?
02:35:17leorizeuhmm that ref is nil
02:35:23leorizeyou can't deref something that's nil
02:35:39leorizeadded a new to the closurePtr declaration and everything works
02:35:40rayman22201you can assign to a nil pointer right?
02:35:52rayman22201maybe I'm just dumb
02:36:12disruptekanyway, it /should/ be destroyed when you sink it.
02:36:15leorize b[] = (proc(){.closure.})(asyncProcNimAsyncContinue_400016)
02:36:24disruptekit will be broken if it doesn't.
02:36:26leorize^ b is nil, like the `b` itself
02:36:32leorizeyou can't `[]` a nil pointer
02:36:45rayman22201I see.
02:36:55disruptekb = is the sink
02:37:27*msmorgan quit (Ping timeout: 272 seconds)
02:38:17disruptekno, it looks fine to me.
02:38:25rayman22201leorize is right
02:38:29leorizefixed :P
02:38:38disrupteki mean, it's fine if it's alloc'd.
02:38:50disruptekthat code leaks for you?
02:39:13rayman22201I think there may be a better way to do what I want to do here
02:39:19rayman22201might be getting lost in the trees
02:39:51leorizeI thought it was an arc problem
02:39:56leorizebut it crashed with the normal gc :P
02:42:43rayman22201with the leorize fix, calling GC_unref(closurePtr) hits the infinite recursion, just like before...
02:43:29rayman22201Essentially, the situation is, "there is a cycle. But I as the developer know that, and want an escape hatch to dispose of this object, but not follow the recursion. I want to manually break the cycle.
02:43:35rayman22201because I know it's safe.
02:44:18disruptekthere's an acyclic pragma but i don't know what it's for.
02:44:20leorizethere's the {.cursor.}
02:44:27disruptekcursor is a lent
02:45:02rayman22201bah. I feel like I'm following this hack too far, and I should just try doing it the right way
02:45:17rayman22201if it's still broke, then I'll report back.
02:45:25FromDiscord<Rika> AFAIK the acyclic pragma is no longer used
02:45:38disruptekoh yeah?
02:45:58leorizeyea, it's now a no op iirc
02:50:11leorizerayman22201: hmm, I use -d:useMalloc and no infinite cycle happened
02:50:22leorizemaybe this is a bug in Nim's allocator?
02:50:59disrupteki know i will be able to find the problem, unless it's due to, like, an arithmetic error. but i think that's unlikely.
02:51:47disruptekwe would have found it with the gc tests.
02:52:21disruptekbut it's true that it might not be a bug in arc per se.
02:52:53disruptekcould be in the async code more generally but just not exposed by the impl in rc.
02:55:55leorizerayman22201: my walkaround for the infinite recursion is to manually set closurePtr to nil before unref-ing it
02:56:10leorizeoh wait :P
03:06:49disrupteknothing like a 19-digit line number to arouse suspicion: `10 goto L9223372036854775807 #39`
03:08:12leorizethat's 7FFFFFFFFFFFFFFF
03:08:19leorizesounds like underflow
03:08:43disrupteki dunno, but that many lines feels more like overflow to me.
03:09:01disruptekaraq needs to lay off the red bull while coding.
03:09:39leorizemaybe compile the compiler with -d:release?
03:09:46disrupteki did.
03:10:02disruptekoh, no, this is danger.
03:10:50disrupteki have to admit, this leak isn't jumping out at me. on the other hands, it's 16,000 lines to read through.
03:13:32disruptekrelease also produces red bull sessions.
03:15:52leorizegrep for checks: off or intcheck: off then :P
03:15:56leorizealso cast if needed
03:16:11leorizemaybe the koch temp compiler have more debug stuff in it
03:16:25disrupteki'm not worried about it right now.
03:17:14disruptekthing is, orc works.
03:17:27disruptekorc tells us that it's a cycle.
03:18:51leorizewell it stops being a cycle once -d:useMalloc is added
03:18:53leorizewhich is just weird
03:19:17disruptekit's the env var.
03:19:33disruptekbut why...
03:20:07disruptekit's a funky deref.
03:21:55disruptekit's the sysFatal exception handler.
03:22:55disruptekthat's gotta be a bug in the trace.
03:23:32*endragor joined #nim
03:24:33rayman22201wat? I'm using -d:useMalloc, I still get a leak. are we talking about something else?
03:24:54rayman22201I dipped out for a minute and now I'm totally lost lol
03:25:02leorizeabout the infinite cycle for that GC_unref?
03:25:06disrupteki don't lose the cycle, either.
03:25:19disruptekbut, leorize is on musl and acid, so...
03:25:42rayman22201lol. a real heavy combo
03:26:11disruptekoh, it's a future.
03:26:28rayman22201I'm pretty sure GC_unref is trying to follow the cycle caused by the future
03:27:15rayman22201that's why I need a "GC_unref_shallow" operation :-P
03:27:53disruptekyeah, everyone wants a weakasgn.
03:28:56rayman22201I have a feeling it will still be an issue even with my disposableFuture design. It will just make it more obvious.
03:29:18disruptekoh ffs
03:30:46rayman22201I need to try it though.
03:31:00rayman22201I have to pop out again for a bit. bbl.
03:46:15disruptekthis code makes no sense to me. i've been looking at it for 20mins.
03:47:22*xet7 quit (Remote host closed the connection)
03:48:47*xet7 joined #nim
03:50:50disruptekwe set a ptr to zero, we then destroy it. then we actually alloc it.
03:52:26rayman22201welcome to the mind bending world of async :-P
03:52:36*rayman22201 still bopped out, just came to check irc real quick
03:53:34*abm quit (Quit: Leaving)
03:55:44disrupteki think we need WasMoved in here.
03:58:13*muffindrake quit (Ping timeout: 245 seconds)
04:00:27*muffindrake joined #nim
04:14:59*martinium joined #nim
04:23:50*npgm joined #nim
04:26:35*npgm quit (Max SendQ exceeded)
04:32:55*nsf joined #nim
04:33:10*npgm joined #nim
04:34:40*yumaikas quit (Quit: WeeChat 0.4.2)
04:37:23*npgm quit (Ping timeout: 245 seconds)
04:48:12voltistdisruptek: Any developments in your video/streaming channel idea?
04:49:08disruptekno, but i started writing a nim tutorial.
04:49:18disruptekNim at a Medium Pace
04:51:16voltistNice. Sounds like a refreshing change from the "<language> in <5-10> minutes" stuff
04:51:43disruptekwell, i partly want to see how hard it is to write the sort of docs i want to read.
04:52:47disrupteki mean, i want to see something get written.
04:52:59disruptekthe way i write software is a slow acretion of tools.
04:53:20disruptekthen i hit a tipping point where things just get increasingly easy.
04:54:01disrupteki want to repeat the same code until it's ready to be swapped out for a new way of achieving similar semantics.
04:54:12disruptekthat that everything is truly built upon everything else.
04:54:27disruptekbut, i mean, in a tutorial.
04:56:15voltistLike a slow gathering of deep understand rather than a quick surface level rundown?
04:56:23*hlavaty` quit (Ping timeout: 260 seconds)
04:56:32disrupteki want this sucker to scroll like toilet paper.
04:57:00voltistFair enough
04:57:09disruptekbut you should be tired of seeing enums before i show you how to give them string values, etc.
04:57:27disruptekso it'll be like gardening.
04:57:59disruptekno mental leaps. i hate those because i have a tiny brain with two left feet.
04:58:24disrupteklike, the whole thing with discard?
04:58:33disruptekhell yes lets put it up front.
04:59:39voltistYeah thats definately one thing that annoys me in tutorials, when quick things like that are put at the end
05:00:57disrupteki mean, i'm not saying i'm gonna do a good job, but i think it's helpful to the teacher and the stupid.
05:01:07disrupteknot stupid. i dunno why i said stupid; i'm an idiot.
05:01:21disruptekstudent. that sounds better.
05:02:25disruptekdiscard is a good example because if you don't understand the fundamental architecture of the language, it seems like an annoying exception.
05:02:58disruptekbut if you see how it works together, it's not exceptional. it's just a nice design feature supported/produced by the rest of the model.
05:03:42disruptekwould you want to do some streaming? 4hrs/week?
05:05:06*zielmicha__ joined #nim
05:05:53*martinium quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:06:17voltistI'm not keen on actaully being on a stream, but if there are any behind the scenes stuff I can help with (eg. organization, writing, etc.) then I'd definately do that
05:06:38disruptekhah, writing is probably the hardest part.
05:07:59voltistDepends on how impromptu it is I suppose
05:08:49disruptekso a bunch of 20min episodes that culminate in completing a small app.
05:11:51voltistWell I'll certainly avoid writing any code for it, since I'm horrible at planning out projects in a staged way like that :)
05:13:03disruptekyeah, if i knew how to write a piece of code, i probably wouldn't be interested in writing it.
05:13:48disruptekprobably why i'm unemployed.
05:14:05FromDiscord<treeform> maybe you should dm me
05:14:50disruptekdiscord won't let me login because hax0r.
05:16:30*treeform joined #nim
05:16:50treeformcan you dm me now?
05:18:57*zielmicha__ quit (Ping timeout: 272 seconds)
05:32:25*msmorgan joined #nim
05:37:33*msmorgan quit (Ping timeout: 246 seconds)
05:43:11*npgm joined #nim
05:45:37*npgm quit (Excess Flood)
05:54:49*msmorgan joined #nim
06:02:02*chenhq2005_ quit (Read error: Connection reset by peer)
06:02:20*narimiran joined #nim
06:09:24*msmorgan quit (Ping timeout: 246 seconds)
06:21:54*npgm joined #nim
06:24:56*npgm quit (Read error: Connection reset by peer)
06:25:00*rockcavera quit (Remote host closed the connection)
06:36:53*silvernode joined #nim
06:37:11silvernodeGood morning
06:38:04FromDiscord<Rika> good morning to you silvernode
06:38:15Yardanicogood morning nimmers
06:38:32silvernodeI'm in the parking lot at work. I clock in at 20 minutes from now.
06:39:10silvernodeI do night stock at a grocery store and there is a big truck tonight. Then corporate is coming in the morning to audit the store.
06:39:13FromDiscord<Rika> nimmers almost sounds like the expletive
06:39:15Yardanicohttps://forum.nim-lang.org/t/3596 :P
06:39:49FromDiscord<Rika> HAHAHAHAHAH
06:39:52FromDiscord<Rika> C-MIANS
06:39:57FromDiscord<Rika> OML
06:42:42silvernodeJust clicked the link. I never realized that C programmers don't refer to themselves as a group.
06:43:03silvernodeThey refer to themselves as programmers.
06:48:39*msmorgan joined #nim
06:49:05*matti joined #nim
06:49:18*r4vi joined #nim
06:49:46silvernodeSo every night I try to read at least one chapter of Nim in action.
06:49:51*l1x joined #nim
06:50:24silvernodeI am on the arrays section and didn't know what arrays are static
06:50:54silvernodeI haven't used arrays in practice yet with Nim.
06:52:25*npgm joined #nim
06:53:24silvernodeWell, it's time to clock in. Good night everyone
06:53:28*treeform quit (Remote host closed the connection)
06:58:25*silvernode quit (Ping timeout: 268 seconds)
06:59:09FromDiscord<Rika> damn, that's a quick day night cycle over at the planet you live in
06:59:20*matlock joined #nim
06:59:24*nimblepoultry joined #nim
06:59:35FromDiscord<Rika> arrays are useful if you know the size of the container beforehand
07:00:50*surma joined #nim
07:04:20*zielmicha__ joined #nim
07:11:30*MD87 joined #nim
07:14:04*euantor joined #nim
07:15:41*shadowbane quit (Ping timeout: 268 seconds)
07:16:08*shadowbane joined #nim
07:33:49*solitudesf joined #nim
07:33:51*nuxdie joined #nim
07:41:22*xet7 quit (Ping timeout: 258 seconds)
07:53:21*marmotini_ joined #nim
08:00:00*gmpreussner quit (Quit: kthxbye)
08:04:48*gmpreussner joined #nim
08:06:33*d10n-work joined #nim
08:07:02*PMunch joined #nim
08:14:36*LyndsySimon joined #nim
08:20:57ZevvPMunch: ping
08:22:16PMunchZevv, pong
08:28:28Zevvoi. You're fosdemtalking about embedded stuff, right?
08:29:10Zevva premature --os:any has made it into devel, this allows heap allocs on tiny cpus, bringing in a lot of the stdlib that was not usable before
08:29:12*marmotini_ quit (Remote host closed the connection)
08:29:20YardanicoZevv: nice :)
08:29:26Zevvinterested in pulling that in your talk, or too late for that?
08:29:26PMunchWell, on running Nim on everything, so also embeded stuff
08:29:38Yardanicowith --gc:arc and --os:any nim will probably become better to use in embedded systems
08:29:57PMunchSo compile without --gc:none and with --os:any?
08:30:04Zevvand --d:useMalloc
08:30:28Zevvos:standalone is kind of a stupid beast, it makes a static heap for allocs
08:30:37PMunchThat I'll definitely have to try
08:30:51Zevvthat sucks because you just lose a whole block of data. So use useMalloc instead, so every allocation is simply done with malloc/free
08:31:14Zevvand --os:any is almost nothing, it makes sure you don't get the Nim fake heap
08:31:38PMunchSo what does --os:any actually do?
08:31:56PMunchIf you don't throw in -d:useMalloc
08:32:04Zevvimho its standalone done right. It does the bare necessities and has no dependencies on any operating system, it only assumes ANSI C
08:32:14Zevvso basic stdlib.h and stdio.h and a bit
08:32:32ZevvI also run it inside the linux kernel, there I stub alloc() and free() into kmalloc() and kfree() and stuff simply runs
08:32:38Zevvno more 32MB allocs at load time
08:32:56PMunchHmm, what exactly does Nim use from the OSes by default?
08:33:11Zevvthat's hairy, stuff is a bit all over the place
08:33:29Zevvbut if you have linux, you get posix stuff for example, which you don't have here. If you have windows, it uses win32 API's, etc
08:33:40PMunchOr rather, what's the reason to not run --os:any for everything?
08:33:57Zevvmalloc() is stupid on some systems. Araq did work to do it faster
08:34:17Zevvso if you request X bytes, NIm goes to to OS to request a large chunk and starts working with that
08:34:29Zevvbut on a lot of systems, malloc() is just the right thing
08:34:54Zevvthere is still some superfluous hair in the malloc layer. I've been trying to clean that out over the last days, but I keep breaking CI in interesting and unexpected ways, so that needs more love and time
08:35:07Zevvthere is redundency, there are c_malloc() calls in tons of places, ideally it should be in one place only
08:35:10PMunchHaha, that's always fun
08:35:32Zevvand there is some nifty callback hooks allocator thing that just sits there taking memory and an extra function call, that should go out as well
08:35:46Zevvideally I want my "hello" world to boil down to one fwrite() and nothing else
08:35:56Zevvso hello.nim should result in about the same size as hello.c
08:36:32Zevvalso for tiny systems there is a new flag to omit the reporting of uncaught expcetions, as this does string contacts and int-to-strings, etc, which add up if you have 4Kb flash and 512B ram
08:37:01ZevvLet's make Nim the obvious choice for IOT
08:37:07Zevvalthough I loathe that term
08:37:41narimiranclarification: +1 goes for "Let's make Nim the obvious choice for IOT"
08:37:53PMunchHmm, in my testing I was able to get to the same size in bytes as the C implementation
08:38:45PMunchThat's with a bunch of flags though
08:38:51PMunchAnd it wraps most of the library from C
08:39:03Zevvyeah but probably no seqs and string and tables for you then, right?
08:39:07PMunchAnd +1 from me as well :)
08:39:09Zevvor just everytinh leaking until death
08:39:20PMunchOh yeah, no seqs or strings
08:39:26PMunchThis is with --gc:none
08:39:28Zevvfriends don't let friends use --gc:none
08:39:35PMunchHaha :P
08:39:56YardanicoI thought --gc:arc with --os:any is a good choice for embedded, no?
08:40:03PMunchIt's actually a bit annoying, because I have to throw in a lot of "my string".cstring every time I want to pass a string somewhere
08:40:09Yardanicowell, also with -d:useMalloc i guess
08:40:19Zevvand although I am still in a pretty permanent state of consfusion over allocators, garbage colelctors and memory management strategies over the last year or so, I found that --gc:arc kind of seems to do the right thing for me
08:40:48PMunchIs --gc:arc stable enough to be used?
08:40:56Zevvbut when I change something now I break --newruntime or --nimseqsv2 or --gc:orc or something else
08:41:04Zevv--gc:arc for my simple tests it does well, npeg also runs with it
08:41:25Zevvdisruptek and varriount have been looking into async stuff I believe, which was a bit of a pita
08:41:45ZevvI just hope that one day the dust will settle and we get two options: one GC and one refcount, and all the other mess will go away
08:44:55PMunchYeah it's starting to become a bit messy :P
08:48:34PMunchOkay, I'm going to run a quick test to see if this all works on the embedded stuff
08:48:54PMunchStill without any actual allocations though as all the code I have lying around is written for gc:none
08:49:10ZevvI compiled it for atmel, but I wasn't home so hardware to run it on
08:49:30Zevvlet me get you a nice set of options
08:49:52PMunchI will be running it on an emulator atm since I'm at work
08:55:34PMunchHmm, I'm unable to compile, just get an error "nim-#devel/lib/system/osalloc.nim(300, 10) Error: Port memory manager to your platform"
08:55:50Yardanico-d:useMalloc ?
08:58:18*floppydh joined #nim
08:58:48Zevvyou miss --gc:arc
08:59:20Zevvflto good idea, dropped to 1822 bytes .text now
09:00:09PMunchYeah, those options are taken from what the Arduino IDE does when compiling
09:01:22PMunchOkay, that seems to have made it pass the Nim step. But for some reason it is now trying to use GCC and not avr-g++
09:01:53YardanicoPMunch: see Zevv's config, you need to pass compiler as avr.any.gcc.exe etc
09:02:08Yardanicosince it's --os:any and not --os:standalone
09:02:27PMunchOooh, of course
09:02:35YardanicoZevv: where will that string print out on the microcontroller?
09:03:07Zevvso on an atmel you typically set up your oun stdout stream
09:03:15Yardanicoah, makes sense
09:05:08ZevvPMunch: does https://github.com/zevv/mininim work for you?
09:05:38PMunchDefine work
09:05:41PMunchIt compiles
09:06:40Zevvship it
09:08:38PMunchBut why doesn't my code work? Because it compiles with C++?
09:10:39Zevvgood quiestion
09:12:53PMunchI'm guessing that either os:standalone or gc:none means that <exception> isn't included in the sources
09:14:53Zevvhave a meeting, will try c++ later
09:20:22*solitudesf quit (Remote host closed the connection)
09:20:48*solitudesf joined #nim
09:22:54FromGitter<dawkot> How can I prevent nim from generating an almost empty .js file on each save
09:23:02FromGitter<dawkot> or at least tell it to create the file somewhere else
09:24:14PMunchUhm, how did you get Nim to do that?
09:24:21PMunchYou say almost empty, what is in the file?
09:27:00FromGitter<dawkot> https://pastebin.com/0PbuKs72
09:30:01PMunchAh, so you're compiling for the JS target?
09:30:03*marmotini_ joined #nim
09:30:13ZevvPMunch: something is fishy with using cpp still, so for now drop to "nim c" if possible
09:30:15FromGitter<dawkot> Yes
09:30:30ZevvPMunch: --gc:arc uses goto exceptions by default anyway
09:30:38PMunchZevv, I unfortunately can't do that since I interface with the Arduino C++ libraries
09:32:07PMunchdawkot, the contents of that file should be the pre-amble of your JS output
09:32:19PMunchBut it seems like your actual JS output ends up somewhere else
09:33:06PMunchHaha, I like that you've actually uploaded that image to your own server :P
09:33:07ZevvPMunch: ok, I'll see if I can figure out what is needed to get this to work
09:33:16ZevvPMunch: it's just a local mount :)
09:33:28PMunchA local mount?
09:33:35PMunchSo that image is on your machine?
09:34:45ZevvI live most of my live through ssh on a little box somewhere on my attick
09:35:12*marmotini_ quit (Remote host closed the connection)
09:35:25ZevvI will die sad and lonely, but will not host my stuff at other companies, especially not for free.
09:35:45PMunchHaha, I know the feel
09:35:46*marmotini_ joined #nim
09:36:02PMunchHowever I get to host my server at the university for free
09:36:03FromGitter<kayabaNerve> PMunch: Ngl, if the event is with people who know me from online, I'll generally just go by Kayaba.
09:36:14FromGitter<kayabaNerve> (responding to a discussion from earlier)
09:36:20FromGitter<kayabaNerve> Side note, I may need some help.
09:36:43FromGitter<kayabaNerve> Nim's async macro caused a SIGSEGV.
09:37:07FromGitter<kayabaNerve> I would create an issue, except I have no idea how it happened, so I can't create a MWE.
09:37:18FromGitter<kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e202ece000f497899065eb8]
09:37:53FromGitter<kayabaNerve> The code itself is just ⏎ ⏎ ```try: ⏎ x = y ⏎ except CustomException: ⏎ ... ⏎ x = z``` [https://gitter.im/nim-lang/Nim?at=5e202ef1714883789883c5a2]
09:38:09FromGitter<kayabaNerve> Any print statement within the exception handler body runs. Any print statement outside of it does not.
09:38:55FromGitter<kayabaNerve> So my top priority is getting it not cause a SIGSEGV, but if doing so helps create a valid MWE, I'd be happy to create an issue.
09:39:25FromGitter<kayabaNerve> Could I manually set the Exception?
09:40:12*marmotini_ quit (Ping timeout: 258 seconds)
09:42:23*marmotini_ joined #nim
09:43:33ZevvPMunch: that is how I started, ages ago
09:44:34Zevvhosted my stuff with some friends for a few years. After studying we hired rack space and put our machine there for more years. But recently people are lacking with system administration and it was me fixing stuff all the time, so I was sick and bored and moved everything onto my own box.
09:44:41FromGitter<kayabaNerve> `except CE as e: setCurrentException(e)` Unfortunately doesn't work, even though e != nil. I'll stop dumping my thoughts yet would appreciate anyone who has advice.
09:53:54*Vladar joined #nim
09:55:52*marmotini_ quit (Remote host closed the connection)
09:56:28*marmotini_ joined #nim
10:01:23*marmotini_ quit (Ping timeout: 268 seconds)
10:04:47*yumaikas joined #nim
10:09:18PMunchSorry, I had to run around and fix some stuff
10:09:59*opal joined #nim
10:19:52FromDiscord<highDevGuy> hi guys. I'm just starting to play around with nim and I wanted to rewrite my python script but encountered an issue when I needed to get the current windows user. With python I use `getpass.getuser()`, but I can't seem to find a nim alternative for the same feature
10:20:26Yardanicowell, an easy alternative might be to use getHomeDir() and get username from there
10:21:11Yardanicothat's in os module
10:22:25FromDiscord<highDevGuy> thank you... I'll check that out now
10:24:37FromDiscord<highDevGuy> yes, that will work! Thank you again 😉
10:28:09Zevvthat's nasty
10:28:58Zevvat least use getenv("USER") then
10:29:13Zevvmy username is 'ico' but my home is '/data/home'
10:32:08Araqprogress! found the bug for async-arc-windows
10:32:09*narimiran quit (Read error: Connection reset by peer)
10:32:29Araqwas nasty, will make the compiler error instead, I think
10:32:40*narimiran joined #nim
10:33:15FromGitter<sheerluck> @Araq is there any roadmap for 1.1 release? Maybe... 1 february? :)
10:34:40*NimBot joined #nim
10:35:06*voltist quit (Remote host closed the connection)
10:41:01*dddddd joined #nim
10:41:03AraqI don't think so
10:41:39Araqnext version will be 1.2 btw and more likely to arrive in March
10:52:41FromGitter<alehander92> so what happens
10:52:47FromGitter<alehander92> with the roadmap for 1.1 :O
10:56:54*abm joined #nim
10:59:10*marmotini_ joined #nim
11:01:28Araqodd vs even
11:01:39Araq1.1 already exists, it's called "Nim devel"
11:02:31FromGitter<alehander92> yeah but there was this roadmpa
11:03:05Yardanicowell maybe it's roadman for "1.1 devel" so basically 1.2 🤔
11:03:35FromGitter<alehander92> hm maybe i misremember
11:03:54Yardanicowell it always was like this even before 1.0
11:04:17Yardanicowell, kinda
11:06:54*marmotini_ quit (Remote host closed the connection)
11:07:30*marmotini_ joined #nim
11:12:03*marmotini_ quit (Ping timeout: 260 seconds)
11:14:35narimiranspeaking of new versions, here is a beta version of 1.0.6 if you would like to test it: https://github.com/nim-lang/nightlies/releases/tag/2020-01-16-version-1-0-2f557f7
11:20:06*krux02 joined #nim
11:33:32*marmotini_ joined #nim
11:45:21PMunchOooh, what's new?
11:45:37PMunchAnd Zevv, he wanted the Windows user username
11:46:48PMunchhighDevGuy, Yardanico: According to the Python documentation for getuser all it does is: "This function checks the environment variables LOGNAME, USER, LNAME and USERNAME, in order, and returns the value of the first one which is set to a non-empty string. If none are set, the login name from the password database is returned on systems which support the pwd module, otherwise, an exception is raised."
11:46:58PMunchThat should be simple to implement in Nim
11:47:10*opal quit (Remote host closed the connection)
11:47:53*marmotini_ quit (Remote host closed the connection)
11:48:14*rockcavera joined #nim
11:48:28*marmotini_ joined #nim
11:48:54*marmotini_ quit (Read error: Connection reset by peer)
11:49:10*marmotini_ joined #nim
11:49:12*marmotini_ quit (Read error: Connection reset by peer)
11:50:00PMunchAnd @kayabaNerve, looking at your issue it seems like it's currException that is somehow nil, so popCurrentException which probably happens at the end of the except block somehow triggers
11:50:05*marmotini_ joined #nim
11:50:29PMunchDo you start any async jobs inside an exception or something?
11:52:25*opal joined #nim
11:52:26*marmotini_ quit (Remote host closed the connection)
11:52:58*marmotini_ joined #nim
11:54:44*marmotini_ quit (Remote host closed the connection)
11:54:57*marmotini_ joined #nim
11:57:54*marmotini_ quit (Remote host closed the connection)
11:58:28*marmotini_ joined #nim
12:03:01*marmotini_ quit (Ping timeout: 272 seconds)
12:03:27narimiranPMunch: it is a bugfix release, so probably nothing that might make headlines; here is the diff compared to 1.0.4: https://github.com/nim-lang/Nim/compare/v1.0.4...version-1-0
12:04:16*JustASlacker joined #nim
12:06:25*marmotini_ joined #nim
12:06:42*marmotini_ quit (Remote host closed the connection)
12:07:15*marmotini_ joined #nim
12:07:19PMunchOh nice, my AVR bugfixes are in this version :) That means I can publish the wrapper I've been working on for the Arduboy
12:11:50*marmotini_ quit (Ping timeout: 265 seconds)
12:17:38*kungtotte quit (Read error: Connection reset by peer)
12:18:37*kungtotte joined #nim
12:20:31ZevvPMunch: the c++ thing is not my fault: nim emits `#include <exception>` when compiling for c++, which does not exist for avr-libc
12:30:40PMunchBut it works with os:standalone and gc:none
12:30:47PMunchSo it has to be in there somewhere
12:31:17FromGitter<alehander92> hello
12:32:03ZevvPMunch: yeah, it says `when os != "standalone"`, bwah
12:33:26Zevvdo you add -fexpections to cflags?
12:34:19PMunchShould I?
12:34:33Zevvavr-gcc says "error: exception handling disabled, use -fexceptions to enable"
12:34:39ZevvI never target cpp
12:35:01PMunchWell for AVR it should be the go-to target as it allows you to use Arduino libraries
12:35:17Zevvfair enough
12:35:47Zevvwhy is stuff always complicate
12:35:48PMunchSo when os notin {"standalone", "any"}
12:36:05Zevvthat solves the include ,but then my avr starts whining about the -fexecptions
12:36:18PMunchProgramming have gotten so user friendly that we sometimes forget that what we do is actually quite complex :P
12:36:28Zevvnaah, I *never* forget
12:36:58PMunchHmm, that's weird. It doesn't complain about that when I do os:standalone gc:none
12:39:14Zevv"Arduino doesn't support exception handling."
12:40:05PMunchYeah, but it's weird that I don't get that error when I compile with os:standalone gc:none
12:40:23Zevvyeah but do you actually throw and catch something
12:40:24PMunchWhat triggers it? Is there something in the os:any target that uses exceptions?
12:40:43PMunchBecause Arduino doesn't support exception handling :P
12:40:58Zevvthe plot thickens
12:41:05FromGitter<alehander92> well exception handling is just a language concept, no?
12:41:18FromGitter<alehander92> how can arduino not support it :P
12:41:34FromGitter<alehander92> or you talk about interrupts
12:41:45Zevvyou tell me
12:41:57*Zevv and c++ do not work together
12:42:10FromGitter<alehander92> yeah yeah
12:42:17FromGitter<alehander92> i dont know about c++ :P
12:42:43Zevvwell, nim generates catches()
12:42:46Zevvso what now
12:43:02Zevveven with -d:noCppExceptions
12:45:01Zevvand why does it not do goto exceptions when I ask it to
12:45:18*endragor quit (Remote host closed the connection)
12:45:21PMunchIt seems like the compiler handles exceptions just fine, but the Arduino IDE disables them by default
12:46:41PMunchOh wait, maybe not..
12:56:54*marmotini_ joined #nim
12:57:35Araqcase p.config.exc
12:57:36Araq of excGoto:
12:57:36Araq genTryGoto(p, n, d)
12:57:36Araq of excCpp:
12:57:36Araq genTryCpp(p, n, d)
12:57:37Araq else:
12:57:38Araq genTrySetjmp(p, n, d)
12:57:43Araqlooks correct to me
12:58:03Araqbut maybe 'cpp' sets --exceptions to cpp
12:58:33PMunchIn that case it should produce an error/warning if you try to override it
12:59:22Araqah yeah, Zevv look at compiler/main.nim:192
13:00:25Zevvbut --arc implies excpetions:goto, right?
13:01:05Araqnot for 'nim cpp'
13:05:54Zevvyes but no but
13:12:36Araqfix it or let me fix it, tell me what you prefer
13:13:06Zevvyeah, busy, but other stuff is now happening
13:13:11Zevvgimme a minute
13:16:04*nsf quit (Quit: WeeChat 2.7)
13:16:10Zevvyeah "except" gets pulled in and is explicity omited for 'standalone', so that needs to be omitted for 'any' as well
13:17:22Zevvhttps://github.com/zevv/Nim/commit/993cdc5a6a680550a370a23c63f0dd15f6e4bc23 should do it
13:18:02Zevvow dang more...
13:19:09FromGitter<kayabaNerve> PMunch: Yeah, I did get that much :P There's a reason my patch manually sets the current exception (my first attempt at it placed it too early). I localized it to the two separate calls it could occur at, cached the exception, and set it if the current exception became null (and if it was meant to be null, it's set to null). It's an imperfect fix with a very subpar write up, but beyond linking to my codebase and
13:19:10FromGitter... answering questions, it's the best I can do. ⏎ ⏎ I did call asyncCheck a couple times, as mentioned in my issue on GitHub.
13:19:14Araqnot what I'm talking about
13:20:51FromGitter<kayabaNerve> The weird thing is not all asyncChecks are the same. The two asyncCheck calls can both trigger the current exception clear (I tried commenting them both and then each individually). They're effectively NOPs, yet when replacing them with an `asyncCheck x()`(where x just prints "NOP"), the exception doesn't trigger.
13:22:09ZevvAraq: yeah I know, but some other things are not right yet for os:any
13:22:50Araqwhatever you do, do not use embedded.nim
13:23:14Araqit's a legacy and I'm hardly aware of its existence
13:23:39FromGitter<kayabaNerve> PMunch: MWE, thanks. Got some inspiration from what you said.
13:24:02Zevvwell, this seems an avr quirk anyway. It allows cpp but no exceptions, but not sure why/how not
13:26:24ZevvPMunch: os:embedded throws out exceptions, but I don't want to do that for os:any
13:26:56Zevvbut nim generates c++ exceptions by default for cpp, which for some reasons are not working on avr
13:27:18Araqgoto based exceptions are no problem for 'nim cpp'
13:27:26Araqexcept for the bug that currently disables them :P
13:27:31Zevvok, right
13:27:37Zevvthat was what I wanted to know
13:30:15PMunchkayabaNerve, glad my random questions could help :P
13:30:54FromGitter<kayabaNerve> I had to write a function which, while handling an exception, calls asyncCheck on a function which calls await on a function :/
13:31:02PMunchZevv, huh it's weird that avr-g++ doesn't complain then..
13:31:15PMunchOh wait, it doesn't do it for os:standalone?
13:31:37FromGitter<kayabaNerve> It's this super specific daisy chain that causes a SIGSEGV :/
13:31:47PMunchkayabaNerve, yeah that sounds sketchy
13:31:56PMunchAs the async library says, it has "limited support" for exceptions
13:31:58FromGitter<kayabaNerve> I promise you I have a valid reason
13:32:13FromGitter<kayabaNerve> I want that established :P
13:32:54FromGitter<kayabaNerve> I remember it saying that when I last read it... months ago? But I believe it's been treated as a non-issue for a long time now.
13:33:01FromGitter<alehander92> i think i should also do that somewhere
13:33:11FromGitter<alehander92> but probably i dont await in those handlers
13:33:11FromGitter<kayabaNerve> I think I even had a discussion with dom96 where it said that isn't true, but I may be misremembering.
13:33:40FromGitter<kayabaNerve> Anyways. Starting an async task from within an except block shouldn't cause a segfault, even if there was 'limited support'.
13:34:28FromGitter<kayabaNerve> *starting an awaited async task from within a checked async task started from within a except block
13:34:30FromGitter<alehander92> techincally it should be possible to start it outside of the except
13:34:34FromGitter<alehander92> as a workaround
13:34:38FromGitter<alehander92> otherwise i agree
13:34:57FromGitter<kayabaNerve> Yeah, I can definitely set a flag about it to remove my setCurrentException patch. Thanks for the idea.
13:35:08ZevvAraq: I can fix it in a lot of ways, not sure what you'd prefer.
13:35:58PMunchYeah I mean a try that handles the exception by setting a flag and then doing your stuff after the try block based on the flag should work fine.
13:36:27AraqZevv, add excNone to ExceptionSystem
13:36:36Araqand only set it if it's still excNone
13:36:44Araqor maybe name it excUnselected
13:37:57*jholland__ joined #nim
13:37:57ZevvI already typed 'excUnknown', but ok :)
13:38:26Araqso ... what can we do about the misunderstandings about ARC and newruntime? writing an article about it?
13:38:50FromGitter<kayabaNerve> PMunch: Yeah, pushing the fix now
13:40:02ZevvAraq: I guess that would help. people have been awaiting newruntime and destructors for a long time, and then arc came along
13:40:33Zevvperonally I was assuming arc was the evolutionary resutlt of newruntime and that the latter would be phased out
13:41:22Zevvthe problem is that I might not know when to choose which now. arc has a clear advantage for the no-overhead case, but when would I then use newruntime? these kind of questions
13:41:23AraqFATAL: external references exist to the subgraph rooted at 'x'
13:41:31FromGitter<kaushalmodi> Araq: Personally, I eyes just glaze over the terms like sink and move. I just hope I don't have to type any of those in my code. Probably some CS background is needed to understand those?
13:41:51Araqdo you think this error message is good enough? it happens at runtime
13:42:12FromGitter<kaushalmodi> From that forum thread, it's a bit comforting reading you say that those things probably won't be needed in the end user code
13:42:18FromGitter<alehander92> it needs at least a hint link to more detailed doc explanation
13:42:33*vesper11 quit (Ping timeout: 260 seconds)
13:42:47*vesper11 joined #nim
13:43:09FromGitter<alehander92> but thats what i feel about many errors
13:43:21Araqno the point is
13:43:32Araqif we think this error message is terrible
13:43:55Araqthen I see little change for us but to re-introduce 'owned'
13:44:35Araqmulti-threading in 2020 longs for an ownership system
13:45:19ZevvexcGoto is broken with cpp: Error: only a 'ref object' can be raised
13:45:26Zevvfirst other things to do, will dig on later
13:45:41Araqstrange but can't be hard to fix
13:47:21Araqkaushalmodi: let me try to explain it and let's see how far I get.
13:47:52Araqproc add(x: var Container; element: sink T)
13:48:24Araqproc `[]=`(x: var Container; key: sink K; value: sink V)
13:48:40Araqproc `==`(a, b: T): bool # no sinks
13:49:16Araqproc id(x: sink T): T = result = x
13:49:55Araqproc `+`(a, b: T): T # no sinks
13:50:09Araqdo you get a "feeling" for what 'sink' is about or not?
13:50:44FromGitter<kaushalmodi> umm.. if one of the proc parameters gets updated, that parameter is a sink?
13:50:56FromGitter<kaushalmodi> but `[]=` does not fit that definition
13:51:14FromGitter<kaushalmodi> why are key and value sink there?
13:51:16Araqif one parameter is put into a data structure or return back
13:51:27Araqthen it should be a 'sink'
13:51:41Araqif you forget to annotate it, nothing happens.
13:52:16Araqexcept maybe that your code runs a little slower
13:52:46FromGitter<kaushalmodi> hmm, I wrote my first `[]=` when I was mapping std::vector :)
13:53:01FromGitter<kaushalmodi> so `sink` is used before the parameter type?
13:53:13Araqif you know C++ I can explain it to you in one sentence
13:53:23FromGitter<kaushalmodi> no I do not
13:53:32FromGitter<kaushalmodi> std:vector mapping was my closest brush to C++
13:53:37Araqalright :-)
13:53:44FromGitter<kaushalmodi> But I am learning these things, slowly
13:53:55FromGitter<kaushalmodi> thanks
13:55:07AraqI'm thinking about how to explain it best
13:55:22Araqmaybe "ownership" and "moves" are not the best terms
13:55:37FromGitter<kaushalmodi> the wiki for sink is not very helpful: https://en.wikipedia.org/wiki/Sink_(computing)
13:55:54FromGitter<kaushalmodi> why is x a sink in `proc id(x: sink T): T = result = x`?
13:56:13FromGitter<kaushalmodi> looks like x is just an input to the id proc and it is used to derive the return value
13:56:14Araqbecause it's returned back to you, but it's an edge case
13:56:15FromGitter<alehander92> i also dont get it
13:56:32FromGitter<alehander92> so is it just a "borrow" ?
13:56:52FromGitter<kaushalmodi> It's a sink here too? `proc id(x: sink T): T = result = x+3`
13:56:56Araqnot really, better not to think about borrowing
13:57:12Araqno sink for x+3
13:57:22FromGitter<kaushalmodi> ok.. that makes sense
13:57:38Araqbut yeah you get it, 'id' is the weird outlier
13:57:43FromGitter<kaushalmodi> .. that matches how the a and b args are not sink in the `==`
13:57:53Araqand arguably it shouldn't be 'sink'
13:58:36FromGitter<alehander92> but is it about ownership
13:59:20Araqyeah it is but it's maybe more confusing than helpful
14:01:24FromGitter<alehander92> but why "sink"
14:01:29FromGitter<alehander92> i wonder about the name itself
14:02:32Araqmaybe this is a good explanation: it's about what will be "remembered"
14:02:57Araqif you add element X to a seq, the X will be in the seq afterwards, it will be remembered
14:03:01FromGitter<alehander92> ok, so `sink` is when something is being read from and put in the other args/result
14:03:10FromGitter<alehander92> ok
14:03:35FromGitter<alehander92> so `del(a: var Container, b: T)` doesnt need sink?
14:03:41FromDiscord<Clyybber> we can make sink implicit eventually
14:04:03Araq'del' almost never takes a sink parameter
14:04:26Araq(I'm only saying 'almost' because maybe eventually somebody will find a use case for it)
14:05:34FromGitter<alehander92> but yeah
14:05:36FromGitter<alehander92> something like undo
14:05:40FromGitter<alehander92> might require it
14:05:48FromGitter<alehander92> so del saves in a deleted list
14:06:06FromGitter<alehander92> but you will know from the signature that a reference to b is kept alive in a/result then?
14:06:19*lritter joined #nim
14:06:46AraqA parameter is a sink parameter if it is the *source* of a *store*.
14:07:08AraqA parameter is a var parameter if it is the *destination* of a *store*.
14:07:20Araqmaybe like this. bbl.
14:16:51*xet7 joined #nim
14:20:20*endragor joined #nim
14:32:03*leorize quit (Remote host closed the connection)
14:32:32*leorize joined #nim
14:34:31*endragor quit (Remote host closed the connection)
14:39:27*JustASlacker quit (Ping timeout: 272 seconds)
14:46:26*JustASlacker joined #nim
14:51:29*nsf joined #nim
14:58:36disruptekthe way to explain it is to visualize the cfg.
15:06:38disruptekthe way to explain the state of async on arc is to visualize rayman22201 having already fixed it in his `dispose` branch. in devel, it leaks due to a cycle which is broken and freed in --gc:orc.
15:09:59*JustASlacker quit (Remote host closed the connection)
15:10:13*PMunch quit (Quit: Leaving)
15:11:41*fireglow left #nim ("puf")
15:12:04*dcmertens joined #nim
15:15:00*ng0_ joined #nim
15:15:38*kungtotte quit (Ping timeout: 240 seconds)
15:18:05*ng0 quit (Ping timeout: 272 seconds)
15:28:11*ng0_ is now known as ng0
15:31:44*abm quit (Read error: Connection reset by peer)
15:38:00*icebattl1 joined #nim
15:38:06*natrys joined #nim
15:40:26*dcmertens quit (Ping timeout: 240 seconds)
15:45:28Araqdisruptek, wait what?
15:45:44Araqdoes that mean with --gc:orc there are no leaks and no crashes?
15:47:58*endragor joined #nim
15:47:59Araqshashlick, https://github.com/nim-lang/Nim/pull/13170
15:48:00disbotmake case-object transitions explicit, make unknownLineInfo a const, …
15:48:15*lj00nal quit (Quit: ljoonal.xyz)
15:49:39*ljoonal joined #nim
15:50:50*endragor quit (Remote host closed the connection)
15:56:50*icebattle quit (Quit: leaving)
15:58:36*icebattle joined #nim
16:00:29disruptekAraq: yep.
16:00:57disruptekAraq: well, for a simple async test. not tasyncawait.
16:02:12FromGitter<alehander92> hmmm, so
16:02:31disruptekthere's a 3-unit cycle that i want to figure out. then when arc is leak-free for the simple case, we can start adding complexity.
16:02:34FromGitter<alehander92> can something be sink var
16:03:04*tane joined #nim
16:03:15FromGitter<alehander92> e.g. (A a, sink var B b) = a.b = b; b = B()
16:04:14*marmotini_ quit (Remote host closed the connection)
16:04:14disruptekalso, this is all ray's earlier work. i didn't add anything.
16:06:49Zevvso, booked the full fosdem package after all
16:08:09taneZevv, what does that include? :)
16:08:27Zevv3 night sleep and thalys train travel instead of going up and down by car on the sunday :)
16:09:10disrupteknice. you can rub oil into my back Friday night and i'll make pancakes Saturday morning.
16:09:33tanewe'll be there friday till monday, I'm excited already :)
16:09:59ZevvSie sagen waß?!
16:12:37FromGitter<alehander92> guys
16:12:42FromGitter<alehander92> just keep calm with the waffles
16:12:46Zevvand gals, and gals!
16:13:04ZevvI decided I could do with a few days off, away from tiresome family life.
16:13:05disruptekkeep calm and waffle iron?
16:13:13Zevvfosdem is a good excuse as any
16:13:42FromGitter<alehander92> zevv you are married
16:13:52FromGitter<alehander92> amazing i somehow imagine you as a mature youngster
16:13:54Zevvwhat, am I?!
16:13:59disruptekssshhh you're ruining my fantasy.
16:14:00FromGitter<alehander92> deal with it
16:14:07Zevvdid you not hear disruptek and me discussing UUCP yesterday?
16:14:27disruptekfidonet was where it's at.
16:14:28FromGitter<alehander92> sounds like udp for waffle people
16:14:35ZevvI operated my own BBS
16:14:46FromGitter<alehander92> so you are a gradnpa
16:14:47FromGitter<sheerluck> so now it's "Guess who is oldest here" thread
16:14:47FromGitter<alehander92> gotcha
16:15:02disrupteki think sheerluck is oldest.
16:15:04FromGitter<alehander92> i am happy that you're able to use the modern internet
16:15:06ZevvWhen I got started, we only got zero bits. The ones came later.
16:15:42FromGitter<alehander92> i eventually plan to get married in february
16:15:53disruptektime is running out.
16:16:06FromGitter<alehander92> i might talk to nim-ers in 2030 how i used irc several times
16:16:08livcdi am planning to divorce but not in february
16:16:31FromGitter<alehander92> please dont
16:16:48FromGitter<sheerluck> divorce is no laughing matter
16:17:03livcdbut we are both pragmatic
16:17:27FromGitter<alehander92> eh thats a great road to living old and happy pragmatically together !
16:17:42FromGitter<alehander92> sheerluck where are you from
16:17:49livcdyeah but that's not the way i want to live
16:19:01FromGitter<alehander92> those other ways to live periods can be fleeting
16:19:15FromGitter<alehander92> i had one last year before fosdem, it was a great mistake
16:19:30FromGitter<alehander92> so now, no fosdem this year!
16:19:39FromGitter<sheerluck> @alehander92 I am a Ukrainian who lives in Russia, because my father was a military man during the USSR
16:20:16livcdalehander92: did you fool around during fosdem ? :D
16:20:39FromGitter<alehander92> @sheerluck awesome, we have @yglukhov from ukraine as well
16:20:41Zevvwith that girl that was there
16:20:44*dcmertens joined #nim
16:20:57FromGitter<alehander92> zevv i might not remember so much as in my young days, but you werent there
16:21:01FromGitter<alehander92> no, i did not
16:21:06Zevvmy wife is not concerned I'm going for a solo outing. She nows the kind of audience of where I'm going
16:21:10FromGitter<alehander92> but my worldview did!
16:21:51livcdalehander92: well think about what will change for you. I thought nothing would. And indeed nothing did not
16:22:00livcdand that is basically why we are thinking about it
16:22:04FromGitter<alehander92> or maybe you were .. this Pmunch guy had somebody with him
16:23:10*narimiran quit (Ping timeout: 265 seconds)
16:23:50*tiorock joined #nim
16:23:50*tiorock quit (Changing host)
16:23:50*tiorock joined #nim
16:23:50*rockcavera is now known as Guest14397
16:23:50*Guest14397 quit (Killed (cherryh.freenode.net (Nickname regained by services)))
16:23:50*tiorock is now known as rockcavera
16:26:22Araqso ... since I'm about to give a talk about it, who understands 'sink' now?
16:30:15ZevvI guess I do. Just some additional questions: not explicitly sinking a sink is harmless, albeit it might be slower. What is the worst that can happen when sinking a non-sink?
16:30:31Zevvand can/does the compiler infer sinks in some cases already?
16:31:03disruptekwhen sinking a non-sink?
16:31:57Zevve.g. you tell the compiler an argument is a sink, but it actually is not
16:32:02Zevvfalse positive
16:32:28disruptekoh, that's a good question.
16:32:41ZevvI got tons of those. But I save them for special occasions only
16:33:17Zevvdinner, bbl
16:34:52FromGitter<kaushalmodi> Araq: The concept of sink has definitely sunk in more after the last chat
16:35:46disruptekthe compiler can figure out a workable graph but `sink` can help optimize it so the lifecycles work the way you want, preventing useless copies.
16:36:27disruptekif you sink when you shouldn't, you'll know because you will access a var that is unexpectedly empty.
16:37:10disruptekbut i don't know if the compiler has any machinery to invalidate a programmer-recommended sink.
16:42:33*Trustable joined #nim
16:43:14Araqwhen you write 'sink' where it doesn't belong you get another pessimization
16:43:31Araqbut no bugs.
16:45:27Araqthe "unexpected empty" case can only arise when you write an explicit 'move'
16:45:59disruptekthat's awesome.
16:48:15*Kameleon joined #nim
16:52:37*Jjp137 quit (Quit: Leaving)
16:53:20*Jjp137 joined #nim
16:53:27*JustASlacker joined #nim
16:55:15*Jjp137 quit (Client Quit)
16:55:47*Jjp137 joined #nim
16:55:53disruptekhey jasper
17:02:08FromGitter<alehander92> livcd, internal fam changes are hard, but sooner or later fruitful, but the alternative is always much worse imho
17:02:23FromGitter<alehander92> Araq so can you have var sink
17:08:21disrupteki'm your huckleberry.
17:21:51*arecaceae quit (Remote host closed the connection)
17:22:09*arecaceae joined #nim
17:29:07*marmotini_ joined #nim
17:30:12Araqalehander92: there is no 'var sink' or 'sink var'
17:30:36FromGitter<alehander92> but why? e.g. if my function reads b into a but changes it to c
17:30:39FromGitter<alehander92> isnt it sink var
17:31:10Araqif you have 'var T' you already "own" it already, no need to 'sink var' it
17:31:26FromGitter<alehander92> and btw when does karax update event handlers, only on id/class change of the vnode?
17:31:46FromGitter<alehander92> i see, so sink is read of unowned location
17:32:02Araqit's a bit like T < sink T < var T where '<' is some order of capabilities
17:32:43Araqalternatively you can see 'sink T' as a "var T that can also bind immutable values"
17:34:25FromGitter<alehander92> ok
17:34:40Araqearlier versions of the spec used only 'var T' but this butchered the rest of Nim with its var vs let distinctions
17:38:17disruptekJjp137: you here?
17:45:19FromGitter<alehander92> hm it seems that my logic makes karax think an element is not updated even if it is
17:46:02FromGitter<alehander92> Araq is there a way to somehow force event handler to always be readded (so my closure doesnt get old)
17:47:01Jjp137disruptek, I'm here
17:47:16FromGitter<alehander92> i can do it as well
17:47:32disruptekJjp137: was just gonna bounce some commits off you but i guess i don't have it fully fixed.
17:47:56Jjp137ah did I overlook something?
17:48:55disrupteki fixed one bug that's due to me trying to "help" arc, but there remains a git-side memory corruption issue.
17:50:37Zevvthat might be valgrindable then
17:51:14disruptekyeah, should be easy to find just by reading the code, though.
17:52:26disruptekmalloc_consolidate(): invalid chunk size
17:52:48Araqasync works on Windows! :-)
17:53:11Araqthere were 2 bugs
17:53:23livcdthat's cool!
17:53:33Araqpreparing a PR
17:54:12Araqwell there is still one bug left but it's an old one I knew about
17:55:14*JustASlacker quit (Ping timeout: 240 seconds)
18:04:20leorizeso --gc:arc default soon?
18:05:01disruptekanother week at this rate and it can go into important packages ci, maybe.
18:05:40*floppydh quit (Quit: WeeChat 2.7)
18:06:04*rayman22201_ joined #nim
18:06:10leorizedoes anyone actually use the "live" test view of azure pipelines?
18:06:33leorizecurrently I think the test load from Nim is stressing MS servers too much
18:07:01livcdi have no idea what arc does for me
18:07:07leorizeand I might have to throttle the test reporting, but the easiest way I could think of is to just report all tests at the end
18:07:19leorizelivcd: suddenly your code run faster and crashes less :)
18:08:03leorizeI'm pretty sure once arc is ready for the prime time you'll see more documentations of it
18:11:05leorizeI think --gc:arc could have been communicated better though
18:12:12leorizeI totally don't know what happened when I stopped tracking nim's devel for a week
18:12:15FromDiscord<Clyybber> Will happen once its ready
18:12:17disrupteki watch araq try to explain bits and pieces of these new features as they are being invented. it's not that easy.
18:13:06Zevvkey point is: --gc:arc is shared_ptr like refcounting, so without the GC overheade
18:13:16leorizeClyybber: yea but little is being communicated to people who don't track nim devel
18:13:17Zevvbut it might still misbehave with cycles, iirc
18:13:34leorizeeven andrea is being concerned as he has no idea what's going on
18:13:38disruptekyes, but orc is arc with cycle detection.
18:13:48FromDiscord<Clyybber> leorize: chill until its ready :p
18:13:55FromDiscord<Clyybber> is what I would tell them
18:14:34disrupteki guess people need to be told that we will take care of them.
18:14:48leorizeI still do, but people are raising concerns to whether it's worth programming in Nim before gc:arc
18:15:16disruptekthere will be, generally speaking, no changes required.
18:15:53leorizethis should be emphasized in every post about gc:arc progress :p
18:16:03*pbb quit (Ping timeout: 272 seconds)
18:16:23*pbb joined #nim
18:16:59*Trustable quit (Remote host closed the connection)
18:17:10disruptek"features start off in the unfortunate state of `unimplemented.`"
18:19:41disruptekthis is not a great sign: "More than 1000 different errors detected. I'm not reporting any more."
18:19:50disruptekis 1000 errors a lot?
18:20:50FromDiscord<Clyybber> sounds like it
18:21:09FromDiscord<Clyybber> disruptek: Btw, can you use golden to detect since when the CI has timeout problems?
18:21:22disruptekhow would it know?
18:21:54FromDiscord<Clyybber> it can detect steep increases in testing time right?
18:22:00FromDiscord<Clyybber> thats how it could now
18:22:34disruptekit's not 1000 errors.
18:22:38disruptekERROR SUMMARY: 38531375 errors from 10478 contexts (suppressed: 0 from 0)
18:22:49disruptek38.5 million errors.
18:22:58FromDiscord<Clyybber> thats a lotta errors
18:23:09disruptekbut i'm only leaking about 200k.
18:23:59disruptekgolden doesn't save any data yet. or, if it does, it's in a black box.
18:24:34disruptekbut you could develop a sense for how long tests take in your env.
18:25:28disruptekonly 3.3MM errors in -d:useMalloc.
18:26:22*rockcavera quit (Remote host closed the connection)
18:28:21AraqI'm sure it doesn't help but we have a plan for Nim in 2020 and it's covered by a set of RFCs
18:28:47Araqso if you feel ill-informed, read them please
18:29:52Araqlots of effort is going into these things and it's always easy to dismiss it as "TL;DR, WTF is going on with Nim? I'm scared"
18:30:34*pbb_ joined #nim
18:30:37*pbb quit (Ping timeout: 272 seconds)
18:30:42ZevvAraq: what is the use of setTerminate
18:31:20Zevvfrom system/excpt.nim
18:32:03disruptekmaybe we should come up with some code that actually exploits arc so people can A/B it themselves and play with it in the playground. i know we have the demo benchmark, but maybe it should be more centrally advertised.
18:36:34Zevvoh right it's C++ interfacing
18:43:43Zevvbwah am I too stupid or is it just me
18:44:12Zevvwhat the h*** are polymorphic exceptions
18:45:03Zevv"artificially forward-declare popCurrentExceptionEx"
18:45:06ZevvI give up
18:45:41*Zevv switches on the PS4
18:51:36lqdev[m]Zevv: try mindustry, it's a cool game. https://anuke.itch.io/mindustry
18:52:18planetis[m]guys: https://nim-lang.github.io/Nim/tut1.html 😬
18:52:19FromDiscord<Clyybber> ha, I have that on my phone
18:52:26planetis[m](nim doc is broken)
18:52:39*jxy quit (Quit: leaving)
18:52:55FromDiscord<Clyybber> hmm, I think timothee fixed
18:52:55lqdev[m]oh crap this looks broken
18:52:55FromDiscord<Clyybber> it
18:53:01disruptekplanetis[m]: known defect.
18:54:09planetis[m]yes there was a PR but now nothing works 🤭
18:54:59Zevvlqdev[m]: know factorio?
18:55:11FromDiscord<Clyybber> it was merged 6 hours ago, I don't know if the docs have been rebuilt since then
18:55:32FromDiscord<Clyybber> Zevv: One can not know it
18:58:07ZevvI still dream of belts with red cards
18:58:16Zevvafter all those years
19:02:15AraqZevv, I have a new implementation of C++ based exceptions in a branch
19:02:26Araqwhich removes most of this stuff
19:02:38*drewr` quit (Quit: ERC (IRC client for Emacs 26.3))
19:03:18*drewr joined #nim
19:05:19FromDiscord<Clyybber> Araq, planetis[m]: The doc is broken, *after* the fix from timothee
19:06:18FromDiscord<Clyybber> I think because the href to nimdoc.out.css is somehow wrong
19:07:32FromDiscord<Clyybber> Araq: Can I merge https://github.com/nim-lang/Nim/pull/13173 ?
19:07:34disbotCleanup DFA a tiny bit
19:08:29ZevvAraq: ok, I'll just let this be then
19:08:53Zevvexceptions galore
19:09:36FromDiscord<Clyybber> Zevv: Damn, did you make this?
19:09:47FromDiscord<Clyybber> it looks really cool
19:09:52Araqclyybber ok
19:10:12planetis[m]Clybber: you are right, removing the `/` infront of ``nidoc.out.css`` and it work!
19:12:37*marmotini_ quit (Remote host closed the connection)
19:13:09*marmotini_ joined #nim
19:17:14*marmotini_ quit (Ping timeout: 240 seconds)
19:23:35FromDiscord<Clyybber> nice, I have a PR, gotta redo it though since I messed up
19:24:30FromDiscord<exelotl> lol zevv
19:32:47FromDiscord<Clyybber> @timotheecour , disruptek, Araq: Not sure whom to ask, but is this correct? https://github.com/nim-lang/Nim/pull/13176
19:32:47disbotFix docs
19:33:38YardanicoWell, if the resulting link to nimdoc.out.css will be "https://nim-lang.github.io/Nim/nimdoc.out.css", then it's working
19:33:52disrupteklgtm but the issue is that the generator isn't correctly finding the nimpath iirc.
19:34:08disruptekhence recent machinations on timotheecour's part.
19:34:27dom96Zevv, official FOSDEM 2020 Nim merch?
19:34:45FromDiscord<Clyybber> disruptek: Can you test if my PR breaks your user docs?
19:35:02*jxy joined #nim
19:35:10disrupteki can test if it fixes them. they are already broken, i'm sure. 😁
19:35:10FromDiscord<Clyybber> *docs for your nimble packages
19:35:23FromDiscord<Clyybber> disruptek: were they not fixed by timothee?
19:37:17Araqdom96, async+arc works on Windows!
19:37:36Araqstill writing the PR
19:37:44Araqbut it does work
19:37:50disruptekthat means `i'm still deleting echo statements`
19:38:03dom96awesome, happy to review if you think that would be helpful
19:38:12Araqno, I'm adding tests and do the github dance
19:40:31planetis[m]works for me https://b3liever.github.io/patgraph/
19:42:22FromDiscord<Clyybber> nice..
19:42:26FromDiscord<Clyybber> well that was easy
19:43:58*rockcavera joined #nim
19:47:08*oculux quit (Ping timeout: 265 seconds)
19:48:11*marmotini_ joined #nim
19:48:33*oculux joined #nim
19:49:10*narimiran joined #nim
19:49:56FromDiscord<treeform> Araq, nice!
19:50:14FromDiscord<treeform> Araq is the best human!
19:50:15*abm joined #nim
19:51:10*kungtotte joined #nim
19:55:54disruptekwhenever araq stands next to you, he makes you look like an imbecile.
19:56:01disrupteknot very nice. 😢
19:58:13FromDiscord<treeform> Who does he think he is!
19:58:22disruptekit's just plain rude.
19:58:43disrupteki had a really high opinion of myself.
19:58:46disruptekthen i met araq.
19:59:44FromGitter<timotheecour> @Clyybber sorry i broke css after my fixes; yes you PR will fix published docs but (IIUC) break user docs ; I think we shd be able to have both working :)
20:00:58FromGitter<timotheecour> will comment further on your PR https://github.com/nim-lang/Nim/pull/13176
20:00:59disbotFix docs
20:01:17FromDiscord<treeform> disruptek, mee too. His level of intelligence should be illegal!
20:01:52Zevvdom96: no, just have one made :)
20:03:30*nsf quit (Quit: WeeChat 2.7)
20:04:32disruptekZevv: you have that in svg for us? i can make some shirts up.
20:08:48ZevvI got a potato png only: http://zevv.nl/div/ni.png
20:09:00Zevvthat's what I sent to the budget potato shirt printing guy
20:09:20disruptekat least it's alpha'd.
20:09:21Zevvyou could probably pull it through inkscape or somthing similar to vectorize it
20:09:25*Vladar quit (Quit: Leaving)
20:10:11ZevvI think I'll get a cheap photoprint. To do it properly it should be a proper rubbery three color print I guess
20:10:32ZevvI wonder if they even handle the alpha properly, or if they just print translucent plastic all over the place
20:10:49disruptektoo many stringy bits for rubber. it'll peel off in a few months.
20:11:07disruptekbetter to use a light background; then you get ink with no peel.
20:11:16Zevvnot possible
20:11:30disruptekanything is possible, zevv.
20:11:34disruptekeven 3-second ci.
20:11:54Zevvnope, I don't wear anything above #3f3f3f
20:11:59disruptekah, i see.
20:12:14disruptekwell, i wasn't planning on letting you wear clothing in brussels.
20:12:46Zevvyou'll find europe is surprisingly open minded in these things
20:13:00disruptekyes and no.
20:13:10*adeohluwa joined #nim
20:13:20disrupteki spent three weeks tied to a bed in cannes and the police wouldn't even take a statement.
20:13:35Zevvsure, what's so special about that
20:14:04Zevvcannes, of all places. as good a place to be tied to a bed for three weeks as they come
20:16:14disruptekit's nice we can laugh about it now.
20:16:23*qwertfisch quit (Quit: ZNC - http://znc.in)
20:19:32FromGitter<sheerluck> @disruptek I don't have that problem with @Araq bc Engilsh is not my native lang. So I just don't understand 70% of what you guys say. That's why I don't chat too much here.
20:19:45disruptekwhat is your native language?
20:19:53FromGitter<sheerluck> Russian
20:20:22disruptekneat. i worked with an old russian guy years ago. it's a great accent in english, i love it.
20:20:57disruptekwhere in russia?
20:21:36*qwertfisch joined #nim
20:21:55FromGitter<sheerluck> near Ukraine, almost south
20:22:13*dcmertens quit (Ping timeout: 265 seconds)
20:24:04disruptekif it makes you feel better, i think there are those in here who wish they only understood 30% of what was said.
20:24:41FromGitter<sheerluck> I am Python Developer, nothing can make me feel better
20:27:29lqdev[m]Zevv: yeah, factorio's cool too, but I haven't played much of it. I prefer mindustry, tbh, not because it's free, but because it's simpler to grasp
20:27:32lqdev[m]sorry for the late response
20:27:40FromGitter<sheerluck> But if it wasn't for Python, I would never get interested in Nim, so I got that going for me which is nice
20:27:52Zevvthe lack of simplicity is what makes factorio so great, but I'll checkout mindustiry!
20:30:28*qwertfisch quit (Quit: ZNC - http://znc.in)
20:31:18lqdev[m]I bet factorio's much better once you get later into the game, but I got into a bit of a grind and took a break. and didn't come back to it. yet
20:31:19*Kameleon quit (Read error: Connection reset by peer)
20:32:08tanelqdev[m], best if you have other people playing with you, it's faster that way :D
20:33:08Zevvlqdev[m]: I also play it socially, which makes it fun
20:33:26disruptekAraq: asyncmacro uses repr in release code... 🙁
20:34:29*JustASlacker joined #nim
20:34:43*abm quit (Quit: Leaving)
20:35:19dom96disruptek, at compile-time?
20:35:34FromDiscord<Clyybber> @timotheecour Hey, are you there?
20:37:09*qwertfisch joined #nim
20:37:59*drewr quit (Quit: ERC (IRC client for Emacs 26.3))
20:38:09*sschwarzer joined #nim
20:39:40lqdev[m]Zevv, tane: yeah, multiplayer in these RTS/tower defense style games is what really makes them fun :)
20:40:01FromDiscord<Clyybber> @kaushalmodi: Ping
20:40:59*drewr joined #nim
20:42:09*qwertfisch quit (Remote host closed the connection)
20:42:49*qwertfisch joined #nim
20:44:50disruptekwe should use the cfg to bound string sizes.
20:45:02disruptekwon't always be possible, but often will be.
20:45:40disruptekjust hate seeing all this unoptimized string code.
20:45:47disruptekmaybe the compilers are sorting it out for me.
20:45:51FromGitter<Clyybber> @kaushalmodi_gitlab Ping
20:45:52*marmotini_ quit (Remote host closed the connection)
20:45:52disruptekkinda doubt it, though.
20:46:07*marmotini_ joined #nim
20:46:08FromGitter<Clyybber> disruptek: You mean upper bound the length?
20:47:37disruptekeven if we don't do custom allocators, we could still do a little optimization there.
20:48:53disruptekeven if we did it at runtime, it'd be an improvement.
20:49:19FromGitter<Clyybber> Hmm, maybe yeah
20:50:02FromGitter<Clyybber> Araq: Can I merge https://github.com/nim-lang/Nim/pull/13176 ? Its still broken for subdirectories, but it fixes the rest
20:50:03disbotFix docs
20:53:16FromGitter<kaushalmodi> Clybber: Yep got the first ping
20:53:31FromGitter<Clyybber> Ah, nice
20:53:45FromGitter<Clyybber> Do you know if base-href won't fuck up all other hrefs?
20:53:52FromGitter<kaushalmodi> it probably will
20:53:55FromGitter<kaushalmodi> hehe
20:53:57FromGitter<kaushalmodi> I was thinking more
20:53:57FromGitter<Clyybber> Hmm
20:54:02disruptekit'll only break relative hrefs.
20:54:06FromGitter<kaushalmodi> I see that nim doc accepts --git:url switch
20:54:30FromGitter<kaushalmodi> may be we need another switch like --git:base and prefix that to the css, js, etc
20:54:41FromGitter<kaushalmodi> for local docs, we would do `--git:base:/`
20:54:44FromGitter<timotheecour> that would be the most robust solution
20:54:44FromGitter<Clyybber> maybe we should just add an ../ to the href if we are in a subdir
20:55:07FromGitter<kaushalmodi> Clybber: THe subdir depth is not always 1
20:55:18FromGitter<Clyybber> Sure, add N ../ I meant
20:55:24FromGitter<kaushalmodi> just prefixing the absolute base URL with make it always work
20:56:00FromGitter<Clyybber> I think relative is better no? Then we can move stuff around later, and it won't suddenly break
20:56:18FromGitter<kaushalmodi> it's kind of dynamic because we use the switch to specify the base
20:56:42FromGitter<kaushalmodi> .. and the base prefixing is only for resources
20:56:58FromGitter<kaushalmodi> so even if you move the files, the css, js will be fetched from the same base URL
20:57:49FromGitter<kaushalmodi> btw I am not a web expert, just talking based off my experience using the Hugo static site generator
20:57:50FromGitter<Clyybber> Hmm, is there any disadvantage over just prepending ../ times the subdir depth?
20:58:06FromGitter<kaushalmodi> then it becomes file position dependent
20:58:20FromGitter<Clyybber> But independent of the url
20:58:24FromGitter<kaushalmodi> true
20:58:41FromGitter<Clyybber> Hmm, I think independence of the url is preferable no?
20:58:47FromGitter<Clyybber> disruptek: Wdyt?
20:59:35FromGitter<kaushalmodi> instead of "../", why not just put the subdir name there?
20:59:55FromGitter<kaushalmodi> we would know the subdir names as well when we are creating those docs, right?
20:59:58disruptekno opinion, but i'm not too bothered since this stuff is created with software.
21:00:10FromGitter<kaushalmodi> nevermind, ignore my last message
21:00:16FromGitter<Clyybber> :p
21:00:42disruptekif it works, move on to something interesting. 😉
21:00:48FromGitter<timotheecour> so https://github.com/nim-lang/Nim/issues/13150 would simplify all this (and we’d use relative instead of absolute ref)
21:00:50disbot`nim doc --project` should flatten file hierarchy, currently broken ; snippet at 12https://play.nim-lang.org/#ix=27zR
21:01:12*adeohluwa quit (Remote host closed the connection)
21:01:37FromGitter<kaushalmodi> so.. I am good with relative links too.. using "../"xN makes sense
21:01:45FromGitter<Clyybber> @timotheecour Flattening the hierarchy would mean I can't have different docs for similarily named modules right?
21:01:58FromGitter<Clyybber> @kaushalmodi Ok, nice
21:02:37FromGitter<timotheecour> no read the issue ; it’d use mangling to allow that (just like nim c does)
21:02:42FromGitter<kaushalmodi> @timotheecour why not retain the subdirs?
21:02:54FromGitter<kaushalmodi> the mangled flat files names will be painful to read
21:03:00FromGitter<kaushalmodi> also they will be non-intuitive
21:03:18FromGitter<Clyybber> @timotheecour I wonder what it would solve
21:03:22sschwarzerkaushalmodi: agreed
21:03:27FromGitter<Clyybber> I don't entirely get it :p
21:04:21sschwarzerdisruptek: better than moving on _before_ it works. ;)
21:04:22FromGitter<kaushalmodi> in the static site community, they have "ugly URLs" and "pretty URLs". I am in the pretty URLs camp
21:04:45FromGitter<kaushalmodi> ugly URL: `foo.com/abc.html` ⏎ pretty URL: `foo.com/abc/index.html`
21:05:09*sschwarzer quit (Quit: leaving)
21:05:29FromGitter<kaushalmodi> with pretty URLs, you can have as much nesting as you like: ⏎ ⏎ 1) `foo.com/abc` -> `foo.com/abc/index.html` ⏎ 2) `foo.com/abc/def` -> `foo.com/abc/def/index.html` [https://gitter.im/nim-lang/Nim?at=5e20d0197148837898887acd]
21:05:50FromGitter<timotheecour> sure but that scheme currently is broken (see the issue i mentioned inside, with `..` etc)
21:06:25*narimiran quit (Ping timeout: 272 seconds)
21:06:59FromGitter<Clyybber> @timotheecour That should be fixed yeah, but I don't agree we should flatten the hierarchy
21:07:10FromGitter<kaushalmodi> Yes I read the issue, but there should be a way to fix it without making everything flat
21:07:40*tane quit (Quit: Leaving)
21:07:42FromGitter<Clyybber> I agree
21:18:03*oculux quit (Quit: blah)
21:18:22*oculux joined #nim
21:20:14FromGitter<Clyybber> @timotheecour Since you already dug into the inner workings of the docgen already, do you know how I can make a path relative to another one?
21:20:59FromGitter<Clyybber> In this case I want to make the/path/of/nimdoc.out.css relative to the /path/of/the/current/file
21:34:04shashlick@leorize: how did you statically link with openssl
21:36:37*inv2004 joined #nim
21:37:15Araqhttps://github.com/nim-lang/Nim/pull/13179 significant milestone achieved, world domination is inevitable
21:37:16disbotARC works for async on Windows
21:38:31inv2004In 1 month you are doing more than rust-community in 1 year :)
21:40:29*Jjp137 quit (Read error: Connection reset by peer)
21:41:06*Jjp137 joined #nim
21:44:36FromDiscord<exelotl> w...world domination!?
21:45:10FromGitter<Clyybber> Araq: Nice!
21:46:43*JustASlacker quit (Ping timeout: 260 seconds)
21:51:25FromDiscord<Recruit_main_70007> Araq, I saw this old thread and wondered, how would I make myself a class macro, and first, how can I learn about macros/templates.
21:51:25FromDiscord<Recruit_main_70007> (One of the latest entries)
21:51:25FromDiscord<Recruit_main_70007> https://forum.nim-lang.org/t/3
21:55:10FromDiscord<demotomohiro> @Recruit_main_70007 Here is macro tutorial: https://nim-lang.org/docs/tut3.html
21:57:30Araqthere is also a book covering this very example
21:57:43Araqonline book, forgot the link but it's on our website
21:59:36leorizeshashlick: --dynlibOverrideAll --passL:'-static -lssl -lcrypto'
22:00:22FromDiscord<Recruit_main_70007> I can't look for it rn, @ me if you can or something to let me know pls, (maybe ask someone in discord to do it)
22:00:33FromGitter<kaushalmodi> about the Nim macros book: https://github.com/FemtoEmacs/nimacros/blob/master/nimacros/nimdoc.pdf
22:01:08FromGitter<kaushalmodi> .. https://forum.nim-lang.org/t/5383
22:03:22FromDiscord<Recruit_main_70007> Tanks
22:03:52lqdev[m]@Recruit_main_70007 this exact example is covered by Nim by Example https://nim-by-example.github.io/macros/
22:04:54*marmotini_ quit (Remote host closed the connection)
22:05:03Araqyes, that one I had in mind
22:05:06Araqthanks lqdev[m]
22:05:13FromDiscord<Recruit_main_70007> Cool, now have to study, thank you all
22:05:24FromGitter<Clyybber> How do I run the doc tests?
22:08:20shashlick@leorize: core dump
22:08:25shashlickon ubuntu
22:08:52leorizeyour build or mine?
22:08:54FromGitter<Clyybber> disruptek: Can you test if your docs still work with https://github.com/Clyybber/Nim/commit/de2cb0664d550ea3cfeb67746ebccd138761ae16 ?
22:08:59FromGitter<timotheecour> > @timotheecour Since you already dug into the inner workings of the docgen already, do you know how I can make a path relative to another one? ⏎ ⏎ @Clyybber os.relativePath and pathutils.relativeTo ; are you working on a follow-up PR to fix subdirs in user docs?
22:09:25leorizenote that glibc is never meant to be linked statically...
22:09:30FromGitter<Clyybber> @timotheecour Yep, check your DM
22:11:38leorizeshashlick: you might be better off spinning a void-linux musl variant docker
22:11:54leorizedon't know if they build their libressl statically though
22:12:31disruptekstatic ssl libs are the new hotness.
22:13:06rayman22201_leorize: your fix for my async example last night. The more I think about it, the more it doesn't make sense to me why it works lol
22:13:26rayman22201_Yesterday for you? Timezones are hard lol
22:13:43leorize:p why?
22:14:23leorizeshouldn't it be too simple or am I missing something?
22:15:27rayman22201_Well, consider it does not crash on the assignment. It crashes on a later read.
22:17:23shashlickWell ya I really want to do this for windows
22:17:31shashlickWill try that later
22:18:18rayman22201_And the codegen produces a n eq_sink, which doesn't care that it was a null deref
22:18:58leorizerayman22201_: the eqsink is targetted torwards the deref of `b`
22:19:06leorizethat's how I figured it out
22:19:16leorizebut wdym by it crashes later?
22:19:44leorizethe proc call after the assignment never showed up for me
22:20:58rayman22201_For me, the assignment always worked, it was only a later call in asyncfutures line 172 that crashed.
22:22:14leorizefwiw I was using useMalloc
22:22:21rayman22201_Me too
22:22:36rayman22201_Gc arc and usemalloc
22:22:50disruptekthat code never worked for me, and i'm on linux, too.
22:23:35rayman22201_Something smells buggy and I can't put my finger on it...
22:24:40leorizeeqsink___tz9aAourd6w9cPKT5l11V9cEw_2((&(*b)), T5_);
22:24:47leorize^ that's the generated eqsink for me
22:24:58leorizeit was targeting the pointer of b, which is NULL
22:25:01leorizecausing the crash
22:25:31leorizeheck it even dereference it before taking the address :p though I guess the C compiler would optimize that out
22:30:22Araqit has to optimize this because it can be the result of the C preprocessor
22:30:26disruptekgittyup now failing in cpp w/o arc. 🤦
22:30:44Araqiirc the C spec requires this
22:31:43*NimBot joined #nim
22:32:16disruptekyou told me what it means when windows takes too long to complete tests, but i've forgotten.
22:32:53rayman22201_I bet the optimization is the issue.
22:33:14*filcuc joined #nim
22:33:19rayman22201_Maybe no bug then
22:34:19disruptekit's a bug because memory starts off in the unfortunately state of `unallocated`.
22:34:36leorizewell it's documented in Nim
22:34:40leorizeref are nil by default
22:35:33Araqdisruptek: you really like my remark about features don't you...
22:35:42disruptekone of my favorites.
22:36:36disruptektechnically, this is a codegen bug.
22:40:26*solitudesf quit (Ping timeout: 240 seconds)
22:49:27shashlickok --gc:arc at least compiles toast now but crashes on run
22:50:06*natrys quit (Quit: natrys)
22:50:44shashlickcrashes in nim-regex but could be anything
22:52:37shashlickok well master doesn't even compile
22:59:40disruptekprobably simple but i don't recognize that behavior; is this 0.4.4 on head?
23:00:53disruptekreproduced it.
23:01:06shashlicknewalgo branch compiles but crashes
23:01:41*inv2004 quit (Remote host closed the connection)
23:01:50disruptekwell, you do have some include statements in here.
23:03:00*abm joined #nim
23:07:33shashlickhow does that matter?
23:07:44disruptekfree(foo: sink var Bar) breaks cpp codegen but free(foo: sink Bar) is fine.
23:07:57disruptekshashlick: i thought maybe there was some symbol duping, but no.
23:07:57*xet7 quit (Remote host closed the connection)
23:08:24*filcuc quit (Quit: Konversation terminated!)
23:11:20*martinium joined #nim
23:28:14*noonien joined #nim
23:34:36*rayman22201 quit (Remote host closed the connection)
23:34:36*rayman22201_ is now known as rayman22201
23:41:18*martinium quit (Quit: My MacBook has gone to sleep. ZZZzzz…)