| 00:01:59 | rayman22201 | in 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:26 | Araq | should be pretty simple? |
| 00:03:33 | * | chenhq2005 quit (Ping timeout: 260 seconds) |
| 00:03:45 | Araq | 'owned' is not a thing, you have GC_ref/unref |
| 00:04:05 | rayman22201 | in arc? |
| 00:05:34 | rayman22201 | oh shit |
| 00:07:06 | disruptek | is unown impl for arc? |
| 00:07:12 | disruptek | i can't remember. |
| 00:07:27 | rayman22201 | it didn't error, but it didn't seem to do anything |
| 00:08:11 | rayman22201 | idk |
| 00:08:19 | rayman22201 | where do I check? |
| 00:08:41 | disruptek | i dunno 'cause leorize's plugin is broken. |
| 00:08:49 | rayman22201 | lol |
| 00:09:01 | leorize | disruptek: ? |
| 00:09:01 | disruptek | lib/system.nim |
| 00:09:11 | leorize | have you updated? |
| 00:09:13 | disruptek | leorize: sorry; rayman22201 made me. |
| 00:09:28 | * | krux02_ quit (Ping timeout: 245 seconds) |
| 00:09:35 | leorize | I fixed the system.nim highlighting bug sometime ago :P |
| 00:11:25 | rayman22201 | I see it, but idk if that means it's implemented for arc lol |
| 00:12:38 | disruptek | arc vs. orc is a disaster on even that tiny amount of async. |
| 00:13:07 | disruptek | it's a 16k line diff. |
| 00:16:58 | rayman22201 | the segv I'm getting makes me think unown doesn't work in arc |
| 00:17:12 | rayman22201 | but I also shouldn't be getting a segv, so that's confusing lol |
| 00:17:15 | FromDiscord | <Clyybber> guddamnit, my algorithm is still wrong |
| 00:17:25 | FromDiscord | <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:36 | FromDiscord | <Clyybber> maybe sleeping solves it for me |
| 00:22:38 | FromDiscord | <Clyybber> gn8 |
| 00:22:59 | * | krux02_ joined #nim |
| 00:24:21 | rayman22201 | https://play.nim-lang.org/#ix=27vY |
| 00:24:39 | rayman22201 | if you are interested disruptek. Why does this cause a segv? |
| 00:25:50 | rayman22201 | specifically the segv is here: https://github.com/nim-lang/Nim/blob/d19206755bbbb6482b3e29499eda92d3d97b2f1b/lib/pure/asyncfutures.nim#L172 |
| 00:26:04 | rayman22201 | which implies the callback ptr was moved |
| 00:26:54 | rayman22201 | my thought was that maybe it sinks on `b[] =`, but unown doesn't seem to help |
| 00:30:49 | rayman22201 | eqsink___tz9aAourd6w9cPKT5l11V9cEw_2((&(*(*b))), T5_); |
| 00:30:54 | rayman22201 | it is doing a sink |
| 00:31:03 | rayman22201 | son of a biscut |
| 00:31:11 | * | krux02_ quit (Remote host closed the connection) |
| 00:31:49 | rayman22201 | how do I prevent the `=sink` from happening |
| 00:38:26 | rayman22201 | `=lent` doesn't seem to work |
| 00:39:57 | rayman22201 | everyone 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:02 | Zevv | I whish |
| 01:38:04 | FromGitter | <Varriount> Hi Zevv |
| 01:38:41 | Zevv | oi |
| 01:39:33 | leorize | rayman22201: probably an optimization bug? |
| 01:51:49 | * | r4vi joined #nim |
| 02:00:43 | * | r4vi quit (Ping timeout: 272 seconds) |
| 02:02:41 | disruptek | rayman22201: i'm up. |
| 02:02:58 | disruptek | that's the bit i rewrote, but you're in the wrong branch, no? |
| 02:11:33 | * | chenhq2005 joined #nim |
| 02:15:26 | rayman22201 | what 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:57 | disruptek | that clause in call, but it was before i learned that unowned does nothing. |
| 02:16:01 | disruptek | unown |
| 02:16:55 | rayman22201 | I think that's part of the bug here. unown needs to be fixed |
| 02:17:56 | disruptek | i dunno, it's more correct to write the code the way we want it written. |
| 02:18:03 | * | hlavaty` joined #nim |
| 02:18:05 | disruptek | that was your idea and i think it's right. |
| 02:18:29 | rayman22201 | Fair point |
| 02:18:37 | rayman22201 | still seems like a bug though |
| 02:18:47 | disruptek | what i did was to just move the ref and free the callback. |
| 02:18:54 | disruptek | then recurse. |
| 02:19:15 | rayman22201 | I don't understand? |
| 02:19:42 | disruptek | i think that, due to the way arc works, it won't get cleaned up before it recurses. |
| 02:20:43 | disruptek | we're talking about running the callbacks, right? |
| 02:21:07 | rayman22201 | no. I'm talking about properly freeing the callback after it's done |
| 02:21:21 | disruptek | right, the same code though, right? |
| 02:21:22 | disruptek | call() |
| 02:21:27 | rayman22201 | not just any callback, the specific callback that async generates |
| 02:21:40 | rayman22201 | no. 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:04 | disruptek | it's like like 180 in asyncfutures, right? |
| 02:22:14 | disruptek | ^line |
| 02:22:54 | rayman22201 | That's where my example crashes, but that isn't where the bug is |
| 02:23:35 | disruptek | tell me where to look. |
| 02:23:50 | rayman22201 | the 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:23:59 | rayman22201 | https://play.nim-lang.org/#ix=27vY |
| 02:24:04 | rayman22201 | line 45 of this example |
| 02:24:26 | rayman22201 | and that line causes an example because it generates an eq_sink |
| 02:24:35 | rayman22201 | causes the bug even |
| 02:25:00 | disruptek | yeah, so it's destroying b. |
| 02:25:30 | rayman22201 | no, it's not. It's moving asyncProcNimAsyncContinue_400016 into b, and destroying future.callback |
| 02:25:49 | disruptek | if there was anything in b before, it's gone now. |
| 02:26:14 | rayman22201 | when is "before" and when is "now"? |
| 02:26:20 | rayman22201 | not true |
| 02:26:41 | disruptek | sink will destroy any contents before it assigns rhs to lhs. |
| 02:27:05 | rayman22201 | there was nothing in b to begin with, look at line 52 |
| 02:27:33 | rayman22201 | the entire point of b was to give the calling function control over the lifetime of `asyncProcNimAsyncContinue_400016` |
| 02:27:48 | rayman22201 | it's an out param |
| 02:27:57 | disruptek | okay, holdon. lemme actually put this somewhere where i can read it. |
| 02:28:59 | disruptek | yeah, this shouldn't be hard to figure out. |
| 02:29:28 | rayman22201 | well, I'm pretty sure it's a sink optimization bug |
| 02:29:33 | rayman22201 | but idk how to fix those |
| 02:30:12 | leorize | well you can even tinker with the code a bit more |
| 02:30:20 | rayman22201 | it brings me back to my original question. can I force line 45 of that example to not sink? |
| 02:30:25 | disruptek | one good thing is that it doesn't crash in orc. |
| 02:30:48 | rayman22201 | it does for me |
| 02:30:58 | disruptek | you incref but i think we should fix arc instead, if possible. |
| 02:31:04 | * | chenhq2005_ joined #nim |
| 02:31:19 | rayman22201 | both orc and arc crash the same way for me |
| 02:31:45 | disruptek | oh, you're right. |
| 02:32:38 | * | msmorgan joined #nim |
| 02:33:17 | * | dddddd quit (Ping timeout: 265 seconds) |
| 02:33:37 | rayman22201 | heres 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:11 | disruptek | ok |
| 02:34:18 | * | chenhq2005 quit (Ping timeout: 268 seconds) |
| 02:34:28 | leorize | rayman22201: I can't help but realise that b wasn't allocated |
| 02:35:08 | rayman22201 | It doesn't need to be? |
| 02:35:17 | leorize | uhmm that ref is nil |
| 02:35:23 | leorize | you can't deref something that's nil |
| 02:35:39 | leorize | added a new to the closurePtr declaration and everything works |
| 02:35:40 | rayman22201 | you can assign to a nil pointer right? |
| 02:35:46 | rayman22201 | orly |
| 02:35:52 | rayman22201 | maybe I'm just dumb |
| 02:36:12 | disruptek | anyway, it /should/ be destroyed when you sink it. |
| 02:36:15 | leorize | b[] = (proc(){.closure.})(asyncProcNimAsyncContinue_400016) |
| 02:36:24 | disruptek | it will be broken if it doesn't. |
| 02:36:26 | leorize | ^ b is nil, like the `b` itself |
| 02:36:32 | leorize | you can't `[]` a nil pointer |
| 02:36:45 | rayman22201 | I see. |
| 02:36:55 | disruptek | b = is the sink |
| 02:37:27 | * | msmorgan quit (Ping timeout: 272 seconds) |
| 02:38:17 | disruptek | no, it looks fine to me. |
| 02:38:23 | leorize | https://play.nim-lang.org/#ix=27wc |
| 02:38:25 | rayman22201 | leorize is right |
| 02:38:29 | leorize | fixed :P |
| 02:38:38 | disruptek | i mean, it's fine if it's alloc'd. |
| 02:38:50 | disruptek | that code leaks for you? |
| 02:39:13 | rayman22201 | I think there may be a better way to do what I want to do here |
| 02:39:19 | rayman22201 | might be getting lost in the trees |
| 02:39:51 | leorize | I thought it was an arc problem |
| 02:39:56 | leorize | but it crashed with the normal gc :P |
| 02:42:43 | rayman22201 | with the leorize fix, calling GC_unref(closurePtr) hits the infinite recursion, just like before... |
| 02:43:29 | rayman22201 | Essentially, 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:35 | rayman22201 | because I know it's safe. |
| 02:44:18 | disruptek | there's an acyclic pragma but i don't know what it's for. |
| 02:44:20 | leorize | there's the {.cursor.} |
| 02:44:27 | disruptek | cursor is a lent |
| 02:45:02 | rayman22201 | bah. I feel like I'm following this hack too far, and I should just try doing it the right way |
| 02:45:17 | rayman22201 | if it's still broke, then I'll report back. |
| 02:45:25 | FromDiscord | <Rika> AFAIK the acyclic pragma is no longer used |
| 02:45:38 | disruptek | oh yeah? |
| 02:45:58 | leorize | yea, it's now a no op iirc |
| 02:50:11 | leorize | rayman22201: hmm, I use -d:useMalloc and no infinite cycle happened |
| 02:50:22 | leorize | maybe this is a bug in Nim's allocator? |
| 02:50:59 | disruptek | i 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:47 | disruptek | we would have found it with the gc tests. |
| 02:52:21 | disruptek | but it's true that it might not be a bug in arc per se. |
| 02:52:53 | disruptek | could be in the async code more generally but just not exposed by the impl in rc. |
| 02:55:55 | leorize | rayman22201: my walkaround for the infinite recursion is to manually set closurePtr to nil before unref-ing it |
| 02:56:10 | leorize | oh wait :P |
| 03:06:49 | disruptek | nothing like a 19-digit line number to arouse suspicion: `10 goto L9223372036854775807 #39` |
| 03:08:12 | leorize | that's 7FFFFFFFFFFFFFFF |
| 03:08:19 | leorize | sounds like underflow |
| 03:08:43 | disruptek | i dunno, but that many lines feels more like overflow to me. |
| 03:09:01 | disruptek | araq needs to lay off the red bull while coding. |
| 03:09:39 | leorize | maybe compile the compiler with -d:release? |
| 03:09:46 | disruptek | i did. |
| 03:10:02 | disruptek | oh, no, this is danger. |
| 03:10:50 | disruptek | i 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:32 | disruptek | release also produces red bull sessions. |
| 03:15:52 | leorize | grep for checks: off or intcheck: off then :P |
| 03:15:56 | leorize | also cast if needed |
| 03:16:11 | leorize | maybe the koch temp compiler have more debug stuff in it |
| 03:16:25 | disruptek | i'm not worried about it right now. |
| 03:17:14 | disruptek | thing is, orc works. |
| 03:17:27 | disruptek | orc tells us that it's a cycle. |
| 03:18:51 | leorize | well it stops being a cycle once -d:useMalloc is added |
| 03:18:53 | leorize | which is just weird |
| 03:19:17 | disruptek | it's the env var. |
| 03:19:33 | disruptek | but why... |
| 03:20:07 | disruptek | it's a funky deref. |
| 03:21:55 | disruptek | it's the sysFatal exception handler. |
| 03:22:55 | disruptek | that's gotta be a bug in the trace. |
| 03:23:32 | * | endragor joined #nim |
| 03:24:33 | rayman22201 | wat? I'm using -d:useMalloc, I still get a leak. are we talking about something else? |
| 03:24:54 | rayman22201 | I dipped out for a minute and now I'm totally lost lol |
| 03:25:02 | leorize | about the infinite cycle for that GC_unref? |
| 03:25:06 | disruptek | i don't lose the cycle, either. |
| 03:25:19 | disruptek | but, leorize is on musl and acid, so... |
| 03:25:42 | rayman22201 | lol. a real heavy combo |
| 03:26:11 | disruptek | oh, it's a future. |
| 03:26:28 | rayman22201 | I'm pretty sure GC_unref is trying to follow the cycle caused by the future |
| 03:27:15 | rayman22201 | that's why I need a "GC_unref_shallow" operation :-P |
| 03:27:53 | disruptek | yeah, everyone wants a weakasgn. |
| 03:28:56 | rayman22201 | I have a feeling it will still be an issue even with my disposableFuture design. It will just make it more obvious. |
| 03:29:14 | disruptek | eqdestroy___dS1BF3Vxjg9aJMmmhVJKSpQ((&(*dest).a2)); |
| 03:29:18 | disruptek | oh ffs |
| 03:30:46 | rayman22201 | I need to try it though. |
| 03:31:00 | rayman22201 | I have to pop out again for a bit. bbl. |
| 03:31:04 | disruptek | kk |
| 03:46:15 | disruptek | this 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:50 | disruptek | we set a ptr to zero, we then destroy it. then we actually alloc it. |
| 03:52:26 | rayman22201 | welcome 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:44 | disruptek | i 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:12 | voltist | disruptek: Any developments in your video/streaming channel idea? |
| 04:49:08 | disruptek | no, but i started writing a nim tutorial. |
| 04:49:18 | disruptek | Nim at a Medium Pace |
| 04:51:16 | voltist | Nice. Sounds like a refreshing change from the "<language> in <5-10> minutes" stuff |
| 04:51:43 | disruptek | well, i partly want to see how hard it is to write the sort of docs i want to read. |
| 04:52:30 | voltist | Ok |
| 04:52:47 | disruptek | i mean, i want to see something get written. |
| 04:52:59 | disruptek | the way i write software is a slow acretion of tools. |
| 04:53:20 | disruptek | then i hit a tipping point where things just get increasingly easy. |
| 04:54:01 | disruptek | i want to repeat the same code until it's ready to be swapped out for a new way of achieving similar semantics. |
| 04:54:12 | disruptek | that that everything is truly built upon everything else. |
| 04:54:27 | disruptek | but, i mean, in a tutorial. |
| 04:56:15 | voltist | Like a slow gathering of deep understand rather than a quick surface level rundown? |
| 04:56:23 | * | hlavaty` quit (Ping timeout: 260 seconds) |
| 04:56:32 | disruptek | i want this sucker to scroll like toilet paper. |
| 04:57:00 | voltist | Fair enough |
| 04:57:09 | disruptek | but you should be tired of seeing enums before i show you how to give them string values, etc. |
| 04:57:27 | disruptek | so it'll be like gardening. |
| 04:57:59 | disruptek | no mental leaps. i hate those because i have a tiny brain with two left feet. |
| 04:58:24 | disruptek | like, the whole thing with discard? |
| 04:58:33 | disruptek | hell yes lets put it up front. |
| 04:59:39 | voltist | Yeah thats definately one thing that annoys me in tutorials, when quick things like that are put at the end |
| 05:00:57 | disruptek | i 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:07 | disruptek | not stupid. i dunno why i said stupid; i'm an idiot. |
| 05:01:21 | disruptek | student. that sounds better. |
| 05:02:25 | disruptek | discard is a good example because if you don't understand the fundamental architecture of the language, it seems like an annoying exception. |
| 05:02:58 | disruptek | but 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:42 | disruptek | would 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:17 | voltist | I'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:38 | disruptek | hah, writing is probably the hardest part. |
| 05:07:59 | voltist | Depends on how impromptu it is I suppose |
| 05:08:49 | disruptek | so a bunch of 20min episodes that culminate in completing a small app. |
| 05:11:51 | voltist | Well 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:03 | disruptek | yeah, if i knew how to write a piece of code, i probably wouldn't be interested in writing it. |
| 05:13:48 | disruptek | probably why i'm unemployed. |
| 05:14:05 | FromDiscord | <treeform> maybe you should dm me |
| 05:14:50 | disruptek | discord won't let me login because hax0r. |
| 05:16:30 | * | treeform joined #nim |
| 05:16:40 | treeform | test |
| 05:16:50 | treeform | can 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:11 | silvernode | Good morning |
| 06:38:04 | FromDiscord | <Rika> good morning to you silvernode |
| 06:38:15 | Yardanico | good morning nimmers |
| 06:38:32 | silvernode | I'm in the parking lot at work. I clock in at 20 minutes from now. |
| 06:39:10 | silvernode | I 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:13 | FromDiscord | <Rika> nimmers almost sounds like the expletive |
| 06:39:15 | Yardanico | https://forum.nim-lang.org/t/3596 :P |
| 06:39:49 | FromDiscord | <Rika> HAHAHAHAHAH |
| 06:39:52 | FromDiscord | <Rika> C-MIANS |
| 06:39:57 | FromDiscord | <Rika> OML |
| 06:42:42 | silvernode | Just clicked the link. I never realized that C programmers don't refer to themselves as a group. |
| 06:43:03 | silvernode | They 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:46 | silvernode | So every night I try to read at least one chapter of Nim in action. |
| 06:49:51 | * | l1x joined #nim |
| 06:50:24 | silvernode | I am on the arrays section and didn't know what arrays are static |
| 06:50:54 | silvernode | I haven't used arrays in practice yet with Nim. |
| 06:52:25 | * | npgm joined #nim |
| 06:53:24 | silvernode | Well, 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:09 | FromDiscord | <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:35 | FromDiscord | <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:57 | Zevv | PMunch: ping |
| 08:22:16 | PMunch | Zevv, pong |
| 08:28:28 | Zevv | oi. You're fosdemtalking about embedded stuff, right? |
| 08:28:39 | PMunch | Yup |
| 08:29:10 | Zevv | a 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:20 | Yardanico | Zevv: nice :) |
| 08:29:26 | Zevv | interested in pulling that in your talk, or too late for that? |
| 08:29:26 | PMunch | Well, on running Nim on everything, so also embeded stuff |
| 08:29:34 | PMunch | Oooh |
| 08:29:38 | Yardanico | with --gc:arc and --os:any nim will probably become better to use in embedded systems |
| 08:29:57 | PMunch | So compile without --gc:none and with --os:any? |
| 08:30:04 | Zevv | and --d:useMalloc |
| 08:30:28 | Zevv | os:standalone is kind of a stupid beast, it makes a static heap for allocs |
| 08:30:37 | PMunch | That I'll definitely have to try |
| 08:30:51 | Zevv | that 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:14 | Zevv | and --os:any is almost nothing, it makes sure you don't get the Nim fake heap |
| 08:31:38 | PMunch | So what does --os:any actually do? |
| 08:31:56 | PMunch | If you don't throw in -d:useMalloc |
| 08:32:04 | Zevv | imho its standalone done right. It does the bare necessities and has no dependencies on any operating system, it only assumes ANSI C |
| 08:32:14 | Zevv | so basic stdlib.h and stdio.h and a bit |
| 08:32:32 | Zevv | I also run it inside the linux kernel, there I stub alloc() and free() into kmalloc() and kfree() and stuff simply runs |
| 08:32:38 | Zevv | no more 32MB allocs at load time |
| 08:32:56 | PMunch | Hmm, what exactly does Nim use from the OSes by default? |
| 08:33:11 | Zevv | that's hairy, stuff is a bit all over the place |
| 08:33:29 | Zevv | but 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:40 | PMunch | Or rather, what's the reason to not run --os:any for everything? |
| 08:33:57 | Zevv | malloc() is stupid on some systems. Araq did work to do it faster |
| 08:34:08 | PMunch | Aah |
| 08:34:17 | Zevv | so if you request X bytes, NIm goes to to OS to request a large chunk and starts working with that |
| 08:34:29 | Zevv | but on a lot of systems, malloc() is just the right thing |
| 08:34:54 | Zevv | there 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:07 | Zevv | there is redundency, there are c_malloc() calls in tons of places, ideally it should be in one place only |
| 08:35:10 | PMunch | Haha, that's always fun |
| 08:35:32 | Zevv | and 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:46 | Zevv | ideally I want my "hello" world to boil down to one fwrite() and nothing else |
| 08:35:56 | Zevv | so hello.nim should result in about the same size as hello.c |
| 08:36:32 | Zevv | also 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:01 | Zevv | Let's make Nim the obvious choice for IOT |
| 08:37:07 | Zevv | although I loathe that term |
| 08:37:11 | narimiran | +1 |
| 08:37:41 | narimiran | clarification: +1 goes for "Let's make Nim the obvious choice for IOT" |
| 08:37:53 | PMunch | Hmm, in my testing I was able to get to the same size in bytes as the C implementation |
| 08:38:45 | PMunch | That's with a bunch of flags though |
| 08:38:51 | PMunch | And it wraps most of the library from C |
| 08:39:03 | Zevv | yeah but probably no seqs and string and tables for you then, right? |
| 08:39:07 | PMunch | And +1 from me as well :) |
| 08:39:09 | Zevv | or just everytinh leaking until death |
| 08:39:20 | PMunch | Oh yeah, no seqs or strings |
| 08:39:26 | PMunch | This is with --gc:none |
| 08:39:28 | Zevv | friends don't let friends use --gc:none |
| 08:39:35 | PMunch | Haha :P |
| 08:39:56 | Yardanico | I thought --gc:arc with --os:any is a good choice for embedded, no? |
| 08:40:03 | PMunch | It'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:09 | Yardanico | well, also with -d:useMalloc i guess |
| 08:40:19 | Zevv | and 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:48 | PMunch | Is --gc:arc stable enough to be used? |
| 08:40:56 | Zevv | but when I change something now I break --newruntime or --nimseqsv2 or --gc:orc or something else |
| 08:41:04 | Zevv | --gc:arc for my simple tests it does well, npeg also runs with it |
| 08:41:25 | Zevv | disruptek and varriount have been looking into async stuff I believe, which was a bit of a pita |
| 08:41:45 | Zevv | I 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:55 | PMunch | Yeah it's starting to become a bit messy :P |
| 08:48:34 | PMunch | Okay, I'm going to run a quick test to see if this all works on the embedded stuff |
| 08:48:54 | PMunch | Still without any actual allocations though as all the code I have lying around is written for gc:none |
| 08:49:10 | Zevv | I compiled it for atmel, but I wasn't home so hardware to run it on |
| 08:49:30 | Zevv | let me get you a nice set of options |
| 08:49:52 | PMunch | I will be running it on an emulator atm since I'm at work |
| 08:55:34 | PMunch | Hmm, 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:50 | Yardanico | -d:useMalloc ? |
| 08:56:12 | PMunch | Yup |
| 08:57:01 | PMunch | http://ix.io/27wT |
| 08:57:46 | Zevv | http://ix.io/27wV |
| 08:58:18 | * | floppydh joined #nim |
| 08:58:48 | Zevv | you miss --gc:arc |
| 08:59:20 | Zevv | flto good idea, dropped to 1822 bytes .text now |
| 09:00:09 | PMunch | Yeah, those options are taken from what the Arduino IDE does when compiling |
| 09:01:22 | PMunch | Okay, 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:41 | Zevv | https://github.com/zevv/mininim |
| 09:01:48 | Zevv | nim.cfg? |
| 09:01:53 | Yardanico | PMunch: see Zevv's config, you need to pass compiler as avr.any.gcc.exe etc |
| 09:02:08 | Yardanico | since it's --os:any and not --os:standalone |
| 09:02:27 | PMunch | Oooh, of course |
| 09:02:35 | Yardanico | Zevv: where will that string print out on the microcontroller? |
| 09:02:55 | Zevv | stdout |
| 09:03:07 | Zevv | so on an atmel you typically set up your oun stdout stream |
| 09:03:15 | Yardanico | ah, makes sense |
| 09:03:28 | PMunch | http://ix.io/27wY |
| 09:03:29 | PMunch | Hmm |
| 09:05:08 | Zevv | PMunch: does https://github.com/zevv/mininim work for you? |
| 09:05:38 | PMunch | Define work |
| 09:05:41 | PMunch | It compiles |
| 09:06:36 | Zevv | :) |
| 09:06:40 | Zevv | ship it |
| 09:08:38 | PMunch | But why doesn't my code work? Because it compiles with C++? |
| 09:10:39 | Zevv | good quiestion |
| 09:12:53 | PMunch | I'm guessing that either os:standalone or gc:none means that <exception> isn't included in the sources |
| 09:14:53 | Zevv | have a meeting, will try c++ later |
| 09:20:22 | * | solitudesf quit (Remote host closed the connection) |
| 09:20:48 | * | solitudesf joined #nim |
| 09:22:54 | FromGitter | <dawkot> How can I prevent nim from generating an almost empty .js file on each save |
| 09:23:02 | FromGitter | <dawkot> or at least tell it to create the file somewhere else |
| 09:24:14 | PMunch | Uhm, how did you get Nim to do that? |
| 09:24:21 | PMunch | You say almost empty, what is in the file? |
| 09:27:00 | FromGitter | <dawkot> https://pastebin.com/0PbuKs72 |
| 09:30:01 | PMunch | Ah, so you're compiling for the JS target? |
| 09:30:03 | * | marmotini_ joined #nim |
| 09:30:13 | Zevv | PMunch: something is fishy with using cpp still, so for now drop to "nim c" if possible |
| 09:30:15 | FromGitter | <dawkot> Yes |
| 09:30:30 | Zevv | PMunch: --gc:arc uses goto exceptions by default anyway |
| 09:30:38 | PMunch | Zevv, I unfortunately can't do that since I interface with the Arduino C++ libraries |
| 09:32:07 | PMunch | dawkot, the contents of that file should be the pre-amble of your JS output |
| 09:32:19 | PMunch | But it seems like your actual JS output ends up somewhere else |
| 09:32:33 | Zevv | http://zevv.nl/div/hal.png |
| 09:33:06 | PMunch | Haha, I like that you've actually uploaded that image to your own server :P |
| 09:33:07 | Zevv | PMunch: ok, I'll see if I can figure out what is needed to get this to work |
| 09:33:16 | Zevv | PMunch: it's just a local mount :) |
| 09:33:28 | PMunch | A local mount? |
| 09:33:35 | PMunch | So that image is on your machine? |
| 09:33:47 | Zevv | yeah |
| 09:34:45 | Zevv | I 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:25 | Zevv | I will die sad and lonely, but will not host my stuff at other companies, especially not for free. |
| 09:35:45 | PMunch | Haha, I know the feel |
| 09:35:46 | * | marmotini_ joined #nim |
| 09:36:02 | PMunch | However I get to host my server at the university for free |
| 09:36:03 | FromGitter | <kayabaNerve> PMunch: Ngl, if the event is with people who know me from online, I'll generally just go by Kayaba. |
| 09:36:14 | FromGitter | <kayabaNerve> (responding to a discussion from earlier) |
| 09:36:20 | FromGitter | <kayabaNerve> Side note, I may need some help. |
| 09:36:43 | FromGitter | <kayabaNerve> Nim's async macro caused a SIGSEGV. |
| 09:37:07 | FromGitter | <kayabaNerve> I would create an issue, except I have no idea how it happened, so I can't create a MWE. |
| 09:37:18 | FromGitter | <kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e202ece000f497899065eb8] |
| 09:37:53 | FromGitter | <kayabaNerve> The code itself is just ⏎ ⏎ ```try: ⏎ x = y ⏎ except CustomException: ⏎ ... ⏎ x = z``` [https://gitter.im/nim-lang/Nim?at=5e202ef1714883789883c5a2] |
| 09:38:09 | FromGitter | <kayabaNerve> Any print statement within the exception handler body runs. Any print statement outside of it does not. |
| 09:38:55 | FromGitter | <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:25 | FromGitter | <kayabaNerve> Could I manually set the Exception? |
| 09:40:12 | * | marmotini_ quit (Ping timeout: 258 seconds) |
| 09:42:23 | * | marmotini_ joined #nim |
| 09:43:33 | Zevv | PMunch: that is how I started, ages ago |
| 09:44:34 | Zevv | hosted 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:41 | FromGitter | <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:18 | PMunch | Sorry, I had to run around and fix some stuff |
| 10:09:59 | * | opal joined #nim |
| 10:19:52 | FromDiscord | <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:26 | Yardanico | well, an easy alternative might be to use getHomeDir() and get username from there |
| 10:21:11 | Yardanico | that's in os module |
| 10:22:25 | FromDiscord | <highDevGuy> thank you... I'll check that out now |
| 10:24:37 | FromDiscord | <highDevGuy> yes, that will work! Thank you again 😉 |
| 10:28:09 | Zevv | that's nasty |
| 10:28:58 | Zevv | at least use getenv("USER") then |
| 10:29:13 | Zevv | my username is 'ico' but my home is '/data/home' |
| 10:32:08 | Araq | progress! found the bug for async-arc-windows |
| 10:32:09 | * | narimiran quit (Read error: Connection reset by peer) |
| 10:32:29 | Araq | was nasty, will make the compiler error instead, I think |
| 10:32:40 | * | narimiran joined #nim |
| 10:33:15 | FromGitter | <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:03 | Araq | I don't think so |
| 10:41:39 | Araq | next version will be 1.2 btw and more likely to arrive in March |
| 10:52:41 | FromGitter | <alehander92> so what happens |
| 10:52:47 | FromGitter | <alehander92> with the roadmap for 1.1 :O |
| 10:56:54 | * | abm joined #nim |
| 10:59:10 | * | marmotini_ joined #nim |
| 11:01:28 | Araq | odd vs even |
| 11:01:39 | Araq | 1.1 already exists, it's called "Nim devel" |
| 11:02:31 | FromGitter | <alehander92> yeah but there was this roadmpa |
| 11:03:05 | Yardanico | well maybe it's roadman for "1.1 devel" so basically 1.2 🤔 |
| 11:03:35 | FromGitter | <alehander92> hm maybe i misremember |
| 11:03:54 | Yardanico | well it always was like this even before 1.0 |
| 11:04:17 | Yardanico | well, 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:35 | narimiran | speaking 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:21 | PMunch | Oooh, what's new? |
| 11:45:37 | PMunch | And Zevv, he wanted the Windows user username |
| 11:46:48 | PMunch | highDevGuy, 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:58 | PMunch | That 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:00 | PMunch | And @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:29 | PMunch | Do 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:27 | narimiran | PMunch: 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:19 | PMunch | Oh 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:31 | Zevv | PMunch: the c++ thing is not my fault: nim emits `#include <exception>` when compiling for c++, which does not exist for avr-libc |
| 12:30:40 | PMunch | But it works with os:standalone and gc:none |
| 12:30:47 | PMunch | So it has to be in there somewhere |
| 12:31:17 | FromGitter | <alehander92> hello |
| 12:32:03 | Zevv | PMunch: yeah, it says `when os != "standalone"`, bwah |
| 12:33:26 | Zevv | do you add -fexpections to cflags? |
| 12:34:12 | PMunch | Nope |
| 12:34:19 | PMunch | Should I? |
| 12:34:33 | Zevv | avr-gcc says "error: exception handling disabled, use -fexceptions to enable" |
| 12:34:36 | Zevv | dunno |
| 12:34:39 | Zevv | I never target cpp |
| 12:35:01 | PMunch | Well for AVR it should be the go-to target as it allows you to use Arduino libraries |
| 12:35:17 | Zevv | fair enough |
| 12:35:47 | Zevv | why is stuff always complicate |
| 12:35:48 | PMunch | So when os notin {"standalone", "any"} |
| 12:35:48 | Zevv | d |
| 12:36:05 | Zevv | that solves the include ,but then my avr starts whining about the -fexecptions |
| 12:36:18 | PMunch | Programming have gotten so user friendly that we sometimes forget that what we do is actually quite complex :P |
| 12:36:28 | Zevv | naah, I *never* forget |
| 12:36:58 | PMunch | Hmm, that's weird. It doesn't complain about that when I do os:standalone gc:none |
| 12:39:14 | Zevv | "Arduino doesn't support exception handling." |
| 12:40:05 | PMunch | Yeah, but it's weird that I don't get that error when I compile with os:standalone gc:none |
| 12:40:23 | Zevv | yeah but do you actually throw and catch something |
| 12:40:24 | PMunch | What triggers it? Is there something in the os:any target that uses exceptions? |
| 12:40:30 | PMunch | Nope |
| 12:40:43 | PMunch | Because Arduino doesn't support exception handling :P |
| 12:40:58 | Zevv | the plot thickens |
| 12:41:05 | FromGitter | <alehander92> well exception handling is just a language concept, no? |
| 12:41:18 | FromGitter | <alehander92> how can arduino not support it :P |
| 12:41:34 | FromGitter | <alehander92> or you talk about interrupts |
| 12:41:45 | Zevv | you tell me |
| 12:41:57 | * | Zevv and c++ do not work together |
| 12:42:10 | FromGitter | <alehander92> yeah yeah |
| 12:42:17 | FromGitter | <alehander92> i dont know about c++ :P |
| 12:42:43 | Zevv | well, nim generates catches() |
| 12:42:46 | Zevv | so what now |
| 12:43:02 | Zevv | even with -d:noCppExceptions |
| 12:45:01 | Zevv | and why does it not do goto exceptions when I ask it to |
| 12:45:18 | * | endragor quit (Remote host closed the connection) |
| 12:45:21 | PMunch | It seems like the compiler handles exceptions just fine, but the Arduino IDE disables them by default |
| 12:46:41 | PMunch | Oh wait, maybe not.. |
| 12:56:54 | * | marmotini_ joined #nim |
| 12:57:35 | Araq | case p.config.exc |
| 12:57:36 | Araq | of excGoto: |
| 12:57:36 | Araq | genTryGoto(p, n, d) |
| 12:57:36 | Araq | of excCpp: |
| 12:57:36 | Araq | genTryCpp(p, n, d) |
| 12:57:37 | Araq | else: |
| 12:57:38 | Araq | genTrySetjmp(p, n, d) |
| 12:57:43 | Araq | looks correct to me |
| 12:58:03 | Araq | but maybe 'cpp' sets --exceptions to cpp |
| 12:58:33 | PMunch | In that case it should produce an error/warning if you try to override it |
| 12:59:22 | Araq | ah yeah, Zevv look at compiler/main.nim:192 |
| 13:00:25 | Zevv | but --arc implies excpetions:goto, right? |
| 13:01:05 | Araq | not for 'nim cpp' |
| 13:05:54 | Zevv | yes but no but |
| 13:12:36 | Araq | fix it or let me fix it, tell me what you prefer |
| 13:13:06 | Zevv | yeah, busy, but other stuff is now happening |
| 13:13:11 | Zevv | gimme a minute |
| 13:16:04 | * | nsf quit (Quit: WeeChat 2.7) |
| 13:16:10 | Zevv | yeah "except" gets pulled in and is explicity omited for 'standalone', so that needs to be omitted for 'any' as well |
| 13:17:22 | Zevv | https://github.com/zevv/Nim/commit/993cdc5a6a680550a370a23c63f0dd15f6e4bc23 should do it |
| 13:18:02 | Zevv | ow dang more... |
| 13:19:09 | FromGitter | <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:10 | FromGitter | ... 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:14 | Araq | not what I'm talking about |
| 13:20:51 | FromGitter | <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:09 | Zevv | Araq: yeah I know, but some other things are not right yet for os:any |
| 13:22:50 | Araq | whatever you do, do not use embedded.nim |
| 13:23:14 | Araq | it's a legacy and I'm hardly aware of its existence |
| 13:23:39 | FromGitter | <kayabaNerve> PMunch: MWE, thanks. Got some inspiration from what you said. |
| 13:23:41 | Zevv | ok |
| 13:24:02 | Zevv | well, this seems an avr quirk anyway. It allows cpp but no exceptions, but not sure why/how not |
| 13:26:24 | Zevv | PMunch: os:embedded throws out exceptions, but I don't want to do that for os:any |
| 13:26:56 | Zevv | but nim generates c++ exceptions by default for cpp, which for some reasons are not working on avr |
| 13:27:18 | Araq | goto based exceptions are no problem for 'nim cpp' |
| 13:27:26 | Araq | except for the bug that currently disables them :P |
| 13:27:31 | Zevv | ok, right |
| 13:27:37 | Zevv | that was what I wanted to know |
| 13:30:15 | PMunch | kayabaNerve, glad my random questions could help :P |
| 13:30:54 | FromGitter | <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:02 | PMunch | Zevv, huh it's weird that avr-g++ doesn't complain then.. |
| 13:31:15 | PMunch | Oh wait, it doesn't do it for os:standalone? |
| 13:31:37 | FromGitter | <kayabaNerve> It's this super specific daisy chain that causes a SIGSEGV :/ |
| 13:31:47 | PMunch | kayabaNerve, yeah that sounds sketchy |
| 13:31:56 | PMunch | As the async library says, it has "limited support" for exceptions |
| 13:31:58 | FromGitter | <kayabaNerve> I promise you I have a valid reason |
| 13:32:13 | FromGitter | <kayabaNerve> I want that established :P |
| 13:32:54 | FromGitter | <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:01 | FromGitter | <alehander92> i think i should also do that somewhere |
| 13:33:11 | FromGitter | <alehander92> but probably i dont await in those handlers |
| 13:33:11 | FromGitter | <kayabaNerve> I think I even had a discussion with dom96 where it said that isn't true, but I may be misremembering. |
| 13:33:40 | FromGitter | <kayabaNerve> Anyways. Starting an async task from within an except block shouldn't cause a segfault, even if there was 'limited support'. |
| 13:34:28 | FromGitter | <kayabaNerve> *starting an awaited async task from within a checked async task started from within a except block |
| 13:34:30 | FromGitter | <alehander92> techincally it should be possible to start it outside of the except |
| 13:34:34 | FromGitter | <alehander92> as a workaround |
| 13:34:38 | FromGitter | <alehander92> otherwise i agree |
| 13:34:57 | FromGitter | <kayabaNerve> Yeah, I can definitely set a flag about it to remove my setCurrentException patch. Thanks for the idea. |
| 13:35:08 | Zevv | Araq: I can fix it in a lot of ways, not sure what you'd prefer. |
| 13:35:58 | PMunch | Yeah 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:27 | Araq | Zevv, add excNone to ExceptionSystem |
| 13:36:36 | Araq | and only set it if it's still excNone |
| 13:36:43 | Zevv | sure |
| 13:36:44 | Araq | or maybe name it excUnselected |
| 13:37:57 | * | jholland__ joined #nim |
| 13:37:57 | Zevv | I already typed 'excUnknown', but ok :) |
| 13:38:26 | Araq | so ... what can we do about the misunderstandings about ARC and newruntime? writing an article about it? |
| 13:38:50 | FromGitter | <kayabaNerve> PMunch: Yeah, pushing the fix now |
| 13:40:02 | Zevv | Araq: I guess that would help. people have been awaiting newruntime and destructors for a long time, and then arc came along |
| 13:40:33 | Zevv | peronally I was assuming arc was the evolutionary resutlt of newruntime and that the latter would be phased out |
| 13:41:22 | Zevv | the 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:23 | Araq | FATAL: external references exist to the subgraph rooted at 'x' |
| 13:41:31 | FromGitter | <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:51 | Araq | do you think this error message is good enough? it happens at runtime |
| 13:42:12 | FromGitter | <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:18 | FromGitter | <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:09 | FromGitter | <alehander92> but thats what i feel about many errors |
| 13:43:21 | Araq | no the point is |
| 13:43:32 | Araq | if we think this error message is terrible |
| 13:43:55 | Araq | then I see little change for us but to re-introduce 'owned' |
| 13:44:35 | Araq | multi-threading in 2020 longs for an ownership system |
| 13:45:19 | Zevv | excGoto is broken with cpp: Error: only a 'ref object' can be raised |
| 13:45:26 | Zevv | first other things to do, will dig on later |
| 13:45:41 | Araq | strange but can't be hard to fix |
| 13:47:21 | Araq | kaushalmodi: let me try to explain it and let's see how far I get. |
| 13:47:52 | Araq | proc add(x: var Container; element: sink T) |
| 13:48:24 | Araq | proc `[]=`(x: var Container; key: sink K; value: sink V) |
| 13:48:40 | Araq | proc `==`(a, b: T): bool # no sinks |
| 13:49:16 | Araq | proc id(x: sink T): T = result = x |
| 13:49:55 | Araq | proc `+`(a, b: T): T # no sinks |
| 13:50:09 | Araq | do you get a "feeling" for what 'sink' is about or not? |
| 13:50:44 | FromGitter | <kaushalmodi> umm.. if one of the proc parameters gets updated, that parameter is a sink? |
| 13:50:56 | FromGitter | <kaushalmodi> but `[]=` does not fit that definition |
| 13:51:14 | FromGitter | <kaushalmodi> why are key and value sink there? |
| 13:51:16 | Araq | if one parameter is put into a data structure or return back |
| 13:51:27 | Araq | then it should be a 'sink' |
| 13:51:41 | Araq | if you forget to annotate it, nothing happens. |
| 13:52:16 | Araq | except maybe that your code runs a little slower |
| 13:52:46 | FromGitter | <kaushalmodi> hmm, I wrote my first `[]=` when I was mapping std::vector :) |
| 13:53:01 | FromGitter | <kaushalmodi> so `sink` is used before the parameter type? |
| 13:53:13 | Araq | if you know C++ I can explain it to you in one sentence |
| 13:53:23 | FromGitter | <kaushalmodi> no I do not |
| 13:53:32 | FromGitter | <kaushalmodi> std:vector mapping was my closest brush to C++ |
| 13:53:37 | Araq | alright :-) |
| 13:53:44 | FromGitter | <kaushalmodi> But I am learning these things, slowly |
| 13:53:55 | FromGitter | <kaushalmodi> thanks |
| 13:55:07 | Araq | I'm thinking about how to explain it best |
| 13:55:22 | Araq | maybe "ownership" and "moves" are not the best terms |
| 13:55:37 | FromGitter | <kaushalmodi> the wiki for sink is not very helpful: https://en.wikipedia.org/wiki/Sink_(computing) |
| 13:55:54 | FromGitter | <kaushalmodi> why is x a sink in `proc id(x: sink T): T = result = x`? |
| 13:56:13 | FromGitter | <kaushalmodi> looks like x is just an input to the id proc and it is used to derive the return value |
| 13:56:14 | Araq | because it's returned back to you, but it's an edge case |
| 13:56:15 | FromGitter | <alehander92> i also dont get it |
| 13:56:32 | FromGitter | <alehander92> so is it just a "borrow" ? |
| 13:56:52 | FromGitter | <kaushalmodi> It's a sink here too? `proc id(x: sink T): T = result = x+3` |
| 13:56:56 | Araq | not really, better not to think about borrowing |
| 13:57:12 | Araq | no sink for x+3 |
| 13:57:22 | FromGitter | <kaushalmodi> ok.. that makes sense |
| 13:57:38 | Araq | but yeah you get it, 'id' is the weird outlier |
| 13:57:43 | FromGitter | <kaushalmodi> .. that matches how the a and b args are not sink in the `==` |
| 13:57:53 | Araq | and arguably it shouldn't be 'sink' |
| 13:58:36 | FromGitter | <alehander92> but is it about ownership |
| 13:59:20 | Araq | yeah it is but it's maybe more confusing than helpful |
| 14:01:24 | FromGitter | <alehander92> but why "sink" |
| 14:01:29 | FromGitter | <alehander92> i wonder about the name itself |
| 14:02:32 | Araq | maybe this is a good explanation: it's about what will be "remembered" |
| 14:02:57 | Araq | if you add element X to a seq, the X will be in the seq afterwards, it will be remembered |
| 14:03:01 | FromGitter | <alehander92> ok, so `sink` is when something is being read from and put in the other args/result |
| 14:03:10 | FromGitter | <alehander92> ok |
| 14:03:35 | FromGitter | <alehander92> so `del(a: var Container, b: T)` doesnt need sink? |
| 14:03:41 | FromDiscord | <Clyybber> we can make sink implicit eventually |
| 14:03:45 | Araq | yup |
| 14:04:03 | Araq | 'del' almost never takes a sink parameter |
| 14:04:26 | Araq | (I'm only saying 'almost' because maybe eventually somebody will find a use case for it) |
| 14:05:34 | FromGitter | <alehander92> but yeah |
| 14:05:36 | FromGitter | <alehander92> something like undo |
| 14:05:40 | FromGitter | <alehander92> might require it |
| 14:05:48 | FromGitter | <alehander92> so del saves in a deleted list |
| 14:06:06 | FromGitter | <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:46 | Araq | A parameter is a sink parameter if it is the *source* of a *store*. |
| 14:07:08 | Araq | A parameter is a var parameter if it is the *destination* of a *store*. |
| 14:07:20 | Araq | maybe 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:36 | disruptek | the way to explain it is to visualize the cfg. |
| 15:06:38 | disruptek | the 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:28 | Araq | disruptek, wait what? |
| 15:45:44 | Araq | does that mean with --gc:orc there are no leaks and no crashes? |
| 15:47:58 | * | endragor joined #nim |
| 15:47:59 | Araq | shashlick, https://github.com/nim-lang/Nim/pull/13170 |
| 15:48:00 | disbot | ➥ make 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:29 | disruptek | Araq: yep. |
| 16:00:57 | disruptek | Araq: well, for a simple async test. not tasyncawait. |
| 16:02:12 | FromGitter | <alehander92> hmmm, so |
| 16:02:31 | disruptek | there'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:34 | FromGitter | <alehander92> can something be sink var |
| 16:03:04 | * | tane joined #nim |
| 16:03:15 | FromGitter | <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:14 | disruptek | also, this is all ray's earlier work. i didn't add anything. |
| 16:06:49 | Zevv | so, booked the full fosdem package after all |
| 16:08:09 | tane | Zevv, what does that include? :) |
| 16:08:27 | Zevv | 3 night sleep and thalys train travel instead of going up and down by car on the sunday :) |
| 16:09:03 | tane | nice |
| 16:09:10 | disruptek | nice. you can rub oil into my back Friday night and i'll make pancakes Saturday morning. |
| 16:09:33 | tane | we'll be there friday till monday, I'm excited already :) |
| 16:09:59 | Zevv | Sie sagen waß?! |
| 16:12:37 | FromGitter | <alehander92> guys |
| 16:12:42 | FromGitter | <alehander92> just keep calm with the waffles |
| 16:12:46 | Zevv | and gals, and gals! |
| 16:13:04 | Zevv | I decided I could do with a few days off, away from tiresome family life. |
| 16:13:05 | disruptek | keep calm and waffle iron? |
| 16:13:13 | Zevv | fosdem is a good excuse as any |
| 16:13:42 | FromGitter | <alehander92> zevv you are married |
| 16:13:52 | FromGitter | <alehander92> amazing i somehow imagine you as a mature youngster |
| 16:13:54 | Zevv | what, am I?! |
| 16:13:57 | Zevv | dude |
| 16:13:59 | disruptek | ssshhh you're ruining my fantasy. |
| 16:14:00 | FromGitter | <alehander92> deal with it |
| 16:14:07 | Zevv | did you not hear disruptek and me discussing UUCP yesterday? |
| 16:14:27 | disruptek | fidonet was where it's at. |
| 16:14:28 | FromGitter | <alehander92> sounds like udp for waffle people |
| 16:14:35 | Zevv | I operated my own BBS |
| 16:14:46 | FromGitter | <alehander92> so you are a gradnpa |
| 16:14:47 | FromGitter | <sheerluck> so now it's "Guess who is oldest here" thread |
| 16:14:47 | FromGitter | <alehander92> gotcha |
| 16:15:02 | disruptek | i think sheerluck is oldest. |
| 16:15:04 | FromGitter | <alehander92> i am happy that you're able to use the modern internet |
| 16:15:06 | Zevv | When I got started, we only got zero bits. The ones came later. |
| 16:15:42 | FromGitter | <alehander92> i eventually plan to get married in february |
| 16:15:53 | disruptek | time is running out. |
| 16:15:55 | Zevv | congrats! |
| 16:16:06 | FromGitter | <alehander92> i might talk to nim-ers in 2030 how i used irc several times |
| 16:16:08 | livcd | i am planning to divorce but not in february |
| 16:16:31 | FromGitter | <alehander92> please dont |
| 16:16:48 | FromGitter | <sheerluck> divorce is no laughing matter |
| 16:16:57 | livcd | yeah |
| 16:17:03 | livcd | but we are both pragmatic |
| 16:17:27 | FromGitter | <alehander92> eh thats a great road to living old and happy pragmatically together ! |
| 16:17:42 | FromGitter | <alehander92> sheerluck where are you from |
| 16:17:49 | livcd | yeah but that's not the way i want to live |
| 16:19:01 | FromGitter | <alehander92> those other ways to live periods can be fleeting |
| 16:19:15 | FromGitter | <alehander92> i had one last year before fosdem, it was a great mistake |
| 16:19:30 | FromGitter | <alehander92> so now, no fosdem this year! |
| 16:19:39 | FromGitter | <sheerluck> @alehander92 I am a Ukrainian who lives in Russia, because my father was a military man during the USSR |
| 16:20:16 | livcd | alehander92: did you fool around during fosdem ? :D |
| 16:20:39 | FromGitter | <alehander92> @sheerluck awesome, we have @yglukhov from ukraine as well |
| 16:20:41 | Zevv | with that girl that was there |
| 16:20:44 | * | dcmertens joined #nim |
| 16:20:57 | FromGitter | <alehander92> zevv i might not remember so much as in my young days, but you werent there |
| 16:21:01 | FromGitter | <alehander92> no, i did not |
| 16:21:06 | Zevv | my wife is not concerned I'm going for a solo outing. She nows the kind of audience of where I'm going |
| 16:21:10 | FromGitter | <alehander92> but my worldview did! |
| 16:21:51 | livcd | alehander92: well think about what will change for you. I thought nothing would. And indeed nothing did not |
| 16:22:00 | livcd | and that is basically why we are thinking about it |
| 16:22:04 | FromGitter | <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:22 | Araq | so ... since I'm about to give a talk about it, who understands 'sink' now? |
| 16:29:41 | disruptek | ✋ |
| 16:30:15 | Zevv | I 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:31 | Zevv | and can/does the compiler infer sinks in some cases already? |
| 16:31:03 | disruptek | when sinking a non-sink? |
| 16:31:57 | Zevv | e.g. you tell the compiler an argument is a sink, but it actually is not |
| 16:32:02 | Zevv | false positive |
| 16:32:28 | disruptek | oh, that's a good question. |
| 16:32:41 | Zevv | I got tons of those. But I save them for special occasions only |
| 16:33:17 | Zevv | dinner, bbl |
| 16:34:52 | FromGitter | <kaushalmodi> Araq: The concept of sink has definitely sunk in more after the last chat |
| 16:35:46 | disruptek | the 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:27 | disruptek | if you sink when you shouldn't, you'll know because you will access a var that is unexpectedly empty. |
| 16:37:10 | disruptek | but i don't know if the compiler has any machinery to invalidate a programmer-recommended sink. |
| 16:42:33 | * | Trustable joined #nim |
| 16:43:14 | Araq | when you write 'sink' where it doesn't belong you get another pessimization |
| 16:43:31 | Araq | but no bugs. |
| 16:44:56 | disruptek | nice. |
| 16:45:27 | Araq | the "unexpected empty" case can only arise when you write an explicit 'move' |
| 16:45:59 | disruptek | that'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:53 | disruptek | hey jasper |
| 17:02:08 | FromGitter | <alehander92> livcd, internal fam changes are hard, but sooner or later fruitful, but the alternative is always much worse imho |
| 17:02:23 | FromGitter | <alehander92> Araq so can you have var sink |
| 17:08:21 | disruptek | i'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:12 | Araq | alehander92: there is no 'var sink' or 'sink var' |
| 17:30:36 | FromGitter | <alehander92> but why? e.g. if my function reads b into a but changes it to c |
| 17:30:39 | FromGitter | <alehander92> isnt it sink var |
| 17:31:10 | Araq | if you have 'var T' you already "own" it already, no need to 'sink var' it |
| 17:31:26 | FromGitter | <alehander92> and btw when does karax update event handlers, only on id/class change of the vnode? |
| 17:31:46 | FromGitter | <alehander92> i see, so sink is read of unowned location |
| 17:32:02 | Araq | it's a bit like T < sink T < var T where '<' is some order of capabilities |
| 17:32:43 | Araq | alternatively you can see 'sink T' as a "var T that can also bind immutable values" |
| 17:34:25 | FromGitter | <alehander92> ok |
| 17:34:40 | Araq | earlier versions of the spec used only 'var T' but this butchered the rest of Nim with its var vs let distinctions |
| 17:38:17 | disruptek | Jjp137: you here? |
| 17:45:19 | FromGitter | <alehander92> hm it seems that my logic makes karax think an element is not updated even if it is |
| 17:46:02 | FromGitter | <alehander92> Araq is there a way to somehow force event handler to always be readded (so my closure doesnt get old) |
| 17:47:01 | Jjp137 | disruptek, I'm here |
| 17:47:16 | FromGitter | <alehander92> i can do it as well |
| 17:47:32 | disruptek | Jjp137: was just gonna bounce some commits off you but i guess i don't have it fully fixed. |
| 17:47:56 | Jjp137 | ah did I overlook something? |
| 17:48:01 | disruptek | nope. |
| 17:48:55 | disruptek | i fixed one bug that's due to me trying to "help" arc, but there remains a git-side memory corruption issue. |
| 17:50:37 | Zevv | that might be valgrindable then |
| 17:51:14 | disruptek | yeah, should be easy to find just by reading the code, though. |
| 17:52:26 | disruptek | malloc_consolidate(): invalid chunk size |
| 17:52:48 | Araq | async works on Windows! :-) |
| 17:52:53 | disruptek | w00t |
| 17:53:11 | Araq | there were 2 bugs |
| 17:53:23 | livcd | that's cool! |
| 17:53:33 | Araq | preparing a PR |
| 17:54:12 | Araq | well 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:20 | leorize | so --gc:arc default soon? |
| 18:05:01 | disruptek | another 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:10 | leorize | does anyone actually use the "live" test view of azure pipelines? |
| 18:06:33 | leorize | currently I think the test load from Nim is stressing MS servers too much |
| 18:07:01 | livcd | i have no idea what arc does for me |
| 18:07:07 | leorize | and 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:19 | leorize | livcd: suddenly your code run faster and crashes less :) |
| 18:08:03 | leorize | I'm pretty sure once arc is ready for the prime time you'll see more documentations of it |
| 18:11:05 | leorize | I think --gc:arc could have been communicated better though |
| 18:12:12 | leorize | I totally don't know what happened when I stopped tracking nim's devel for a week |
| 18:12:15 | FromDiscord | <Clyybber> Will happen once its ready |
| 18:12:17 | disruptek | i watch araq try to explain bits and pieces of these new features as they are being invented. it's not that easy. |
| 18:13:06 | Zevv | key point is: --gc:arc is shared_ptr like refcounting, so without the GC overheade |
| 18:13:16 | leorize | Clyybber: yea but little is being communicated to people who don't track nim devel |
| 18:13:17 | Zevv | but it might still misbehave with cycles, iirc |
| 18:13:19 | leorize | https://forum.nim-lang.org/t/5814#36068 |
| 18:13:34 | leorize | even andrea is being concerned as he has no idea what's going on |
| 18:13:38 | disruptek | yes, but orc is arc with cycle detection. |
| 18:13:48 | FromDiscord | <Clyybber> leorize: chill until its ready :p |
| 18:13:55 | FromDiscord | <Clyybber> is what I would tell them |
| 18:14:34 | disruptek | i guess people need to be told that we will take care of them. |
| 18:14:48 | leorize | I still do, but people are raising concerns to whether it's worth programming in Nim before gc:arc |
| 18:15:16 | disruptek | there will be, generally speaking, no changes required. |
| 18:15:53 | leorize | this 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:10 | disruptek | "features start off in the unfortunate state of `unimplemented.`" |
| 18:19:41 | disruptek | this is not a great sign: "More than 1000 different errors detected. I'm not reporting any more." |
| 18:19:50 | disruptek | is 1000 errors a lot? |
| 18:20:50 | FromDiscord | <Clyybber> sounds like it |
| 18:21:09 | FromDiscord | <Clyybber> disruptek: Btw, can you use golden to detect since when the CI has timeout problems? |
| 18:21:22 | disruptek | how would it know? |
| 18:21:54 | FromDiscord | <Clyybber> it can detect steep increases in testing time right? |
| 18:22:00 | FromDiscord | <Clyybber> thats how it could now |
| 18:22:34 | disruptek | it's not 1000 errors. |
| 18:22:38 | disruptek | ERROR SUMMARY: 38531375 errors from 10478 contexts (suppressed: 0 from 0) |
| 18:22:49 | disruptek | 38.5 million errors. |
| 18:22:58 | FromDiscord | <Clyybber> thats a lotta errors |
| 18:23:09 | disruptek | but i'm only leaking about 200k. |
| 18:23:59 | disruptek | golden doesn't save any data yet. or, if it does, it's in a black box. |
| 18:24:34 | disruptek | but you could develop a sense for how long tests take in your env. |
| 18:25:28 | disruptek | only 3.3MM errors in -d:useMalloc. |
| 18:26:22 | * | rockcavera quit (Remote host closed the connection) |
| 18:28:21 | Araq | I'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:47 | Araq | so if you feel ill-informed, read them please |
| 18:29:52 | Araq | lots 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:42 | Zevv | Araq: what is the use of setTerminate |
| 18:31:20 | Zevv | from system/excpt.nim |
| 18:32:03 | disruptek | maybe 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:34 | Zevv | oh right it's C++ interfacing |
| 18:43:43 | Zevv | bwah am I too stupid or is it just me |
| 18:44:12 | Zevv | what the h*** are polymorphic exceptions |
| 18:45:03 | Zevv | "artificially forward-declare popCurrentExceptionEx" |
| 18:45:06 | Zevv | I give up |
| 18:45:41 | * | Zevv switches on the PS4 |
| 18:51:36 | lqdev[m] | Zevv: try mindustry, it's a cool game. https://anuke.itch.io/mindustry |
| 18:52:18 | planetis[m] | guys: https://nim-lang.github.io/Nim/tut1.html 😬 |
| 18:52:19 | FromDiscord | <Clyybber> ha, I have that on my phone |
| 18:52:26 | planetis[m] | (nim doc is broken) |
| 18:52:39 | * | jxy quit (Quit: leaving) |
| 18:52:55 | FromDiscord | <Clyybber> hmm, I think timothee fixed |
| 18:52:55 | lqdev[m] | oh crap this looks broken |
| 18:52:55 | FromDiscord | <Clyybber> it |
| 18:53:01 | disruptek | planetis[m]: known defect. |
| 18:54:09 | planetis[m] | yes there was a PR but now nothing works 🤭 |
| 18:54:59 | Zevv | lqdev[m]: know factorio? |
| 18:55:11 | FromDiscord | <Clyybber> it was merged 6 hours ago, I don't know if the docs have been rebuilt since then |
| 18:55:32 | FromDiscord | <Clyybber> Zevv: One can not know it |
| 18:58:07 | Zevv | I still dream of belts with red cards |
| 18:58:16 | Zevv | after all those years |
| 19:02:15 | Araq | Zevv, I have a new implementation of C++ based exceptions in a branch |
| 19:02:26 | Araq | which 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:19 | FromDiscord | <Clyybber> Araq, planetis[m]: The doc is broken, *after* the fix from timothee |
| 19:06:18 | FromDiscord | <Clyybber> I think because the href to nimdoc.out.css is somehow wrong |
| 19:07:32 | FromDiscord | <Clyybber> Araq: Can I merge https://github.com/nim-lang/Nim/pull/13173 ? |
| 19:07:34 | disbot | ➥ Cleanup DFA a tiny bit |
| 19:08:29 | Zevv | Araq: ok, I'll just let this be then |
| 19:08:34 | Zevv | http://zevv.nl/div/ni.jpg |
| 19:08:53 | Zevv | exceptions galore |
| 19:09:36 | FromDiscord | <Clyybber> Zevv: Damn, did you make this? |
| 19:09:47 | FromDiscord | <Clyybber> it looks really cool |
| 19:09:52 | Araq | clyybber ok |
| 19:10:12 | planetis[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:35 | FromDiscord | <Clyybber> nice, I have a PR, gotta redo it though since I messed up |
| 19:24:30 | FromDiscord | <exelotl> lol zevv |
| 19:32:47 | FromDiscord | <Clyybber> @timotheecour , disruptek, Araq: Not sure whom to ask, but is this correct? https://github.com/nim-lang/Nim/pull/13176 |
| 19:32:47 | disbot | ➥ Fix docs |
| 19:33:38 | Yardanico | Well, 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:52 | disruptek | lgtm but the issue is that the generator isn't correctly finding the nimpath iirc. |
| 19:34:08 | disruptek | hence recent machinations on timotheecour's part. |
| 19:34:27 | dom96 | Zevv, official FOSDEM 2020 Nim merch? |
| 19:34:32 | dom96 | ;) |
| 19:34:45 | FromDiscord | <Clyybber> disruptek: Can you test if my PR breaks your user docs? |
| 19:35:02 | * | jxy joined #nim |
| 19:35:10 | disruptek | i can test if it fixes them. they are already broken, i'm sure. 😁 |
| 19:35:10 | FromDiscord | <Clyybber> *docs for your nimble packages |
| 19:35:23 | FromDiscord | <Clyybber> disruptek: were they not fixed by timothee? |
| 19:37:17 | Araq | dom96, async+arc works on Windows! |
| 19:37:25 | dom96 | :o |
| 19:37:36 | Araq | still writing the PR |
| 19:37:44 | Araq | but it does work |
| 19:37:50 | disruptek | that means `i'm still deleting echo statements` |
| 19:38:03 | dom96 | awesome, happy to review if you think that would be helpful |
| 19:38:12 | Araq | no, I'm adding tests and do the github dance |
| 19:40:31 | planetis[m] | works for me https://b3liever.github.io/patgraph/ |
| 19:41:06 | disruptek | https://disruptek.github.io/sigv4/sigv4.html |
| 19:42:22 | FromDiscord | <Clyybber> nice.. |
| 19:42:26 | FromDiscord | <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:56 | FromDiscord | <treeform> Araq, nice! |
| 19:50:14 | FromDiscord | <treeform> Araq is the best human! |
| 19:50:15 | * | abm joined #nim |
| 19:51:10 | * | kungtotte joined #nim |
| 19:55:42 | disruptek | nonsense. |
| 19:55:54 | disruptek | whenever araq stands next to you, he makes you look like an imbecile. |
| 19:56:01 | disruptek | not very nice. 😢 |
| 19:58:13 | FromDiscord | <treeform> Who does he think he is! |
| 19:58:22 | disruptek | it's just plain rude. |
| 19:58:43 | disruptek | i had a really high opinion of myself. |
| 19:58:46 | disruptek | then i met araq. |
| 19:59:44 | FromGitter | <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:58 | FromGitter | <timotheecour> will comment further on your PR https://github.com/nim-lang/Nim/pull/13176 |
| 20:00:59 | disbot | ➥ Fix docs |
| 20:01:17 | FromDiscord | <treeform> disruptek, mee too. His level of intelligence should be illegal! |
| 20:01:52 | Zevv | dom96: no, just have one made :) |
| 20:03:30 | * | nsf quit (Quit: WeeChat 2.7) |
| 20:04:32 | disruptek | Zevv: you have that in svg for us? i can make some shirts up. |
| 20:08:48 | Zevv | I got a potato png only: http://zevv.nl/div/ni.png |
| 20:09:00 | Zevv | that's what I sent to the budget potato shirt printing guy |
| 20:09:20 | disruptek | at least it's alpha'd. |
| 20:09:21 | Zevv | you could probably pull it through inkscape or somthing similar to vectorize it |
| 20:09:25 | * | Vladar quit (Quit: Leaving) |
| 20:09:33 | disruptek | yeah. |
| 20:10:11 | Zevv | I think I'll get a cheap photoprint. To do it properly it should be a proper rubbery three color print I guess |
| 20:10:32 | Zevv | I wonder if they even handle the alpha properly, or if they just print translucent plastic all over the place |
| 20:10:49 | disruptek | too many stringy bits for rubber. it'll peel off in a few months. |
| 20:11:07 | disruptek | better to use a light background; then you get ink with no peel. |
| 20:11:16 | Zevv | not possible |
| 20:11:30 | disruptek | anything is possible, zevv. |
| 20:11:34 | disruptek | even 3-second ci. |
| 20:11:54 | Zevv | nope, I don't wear anything above #3f3f3f |
| 20:11:59 | disruptek | ah, i see. |
| 20:12:14 | disruptek | well, i wasn't planning on letting you wear clothing in brussels. |
| 20:12:46 | Zevv | you'll find europe is surprisingly open minded in these things |
| 20:13:00 | disruptek | yes and no. |
| 20:13:10 | * | adeohluwa joined #nim |
| 20:13:20 | disruptek | i spent three weeks tied to a bed in cannes and the police wouldn't even take a statement. |
| 20:13:35 | Zevv | sure, what's so special about that |
| 20:14:04 | Zevv | cannes, of all places. as good a place to be tied to a bed for three weeks as they come |
| 20:16:14 | disruptek | it's nice we can laugh about it now. |
| 20:16:23 | * | qwertfisch quit (Quit: ZNC - http://znc.in) |
| 20:19:32 | FromGitter | <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:45 | disruptek | what is your native language? |
| 20:19:53 | FromGitter | <sheerluck> Russian |
| 20:20:22 | disruptek | neat. i worked with an old russian guy years ago. it's a great accent in english, i love it. |
| 20:20:57 | disruptek | where in russia? |
| 20:21:36 | * | qwertfisch joined #nim |
| 20:21:55 | FromGitter | <sheerluck> near Ukraine, almost south |
| 20:22:13 | * | dcmertens quit (Ping timeout: 265 seconds) |
| 20:24:04 | disruptek | if it makes you feel better, i think there are those in here who wish they only understood 30% of what was said. |
| 20:24:41 | FromGitter | <sheerluck> I am Python Developer, nothing can make me feel better |
| 20:27:29 | lqdev[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:32 | lqdev[m] | sorry for the late response |
| 20:27:40 | FromGitter | <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:52 | Zevv | the 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:18 | lqdev[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:08 | tane | lqdev[m], best if you have other people playing with you, it's faster that way :D |
| 20:33:08 | Zevv | lqdev[m]: I also play it socially, which makes it fun |
| 20:33:26 | disruptek | Araq: asyncmacro uses repr in release code... 🙁 |
| 20:34:29 | * | JustASlacker joined #nim |
| 20:34:43 | * | abm quit (Quit: Leaving) |
| 20:35:19 | dom96 | disruptek, at compile-time? |
| 20:35:34 | FromDiscord | <Clyybber> @timotheecour Hey, are you there? |
| 20:35:42 | disruptek | yeah |
| 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:40 | lqdev[m] | Zevv, tane: yeah, multiplayer in these RTS/tower defense style games is what really makes them fun :) |
| 20:40:01 | FromDiscord | <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:50 | disruptek | we should use the cfg to bound string sizes. |
| 20:45:02 | disruptek | won't always be possible, but often will be. |
| 20:45:40 | disruptek | just hate seeing all this unoptimized string code. |
| 20:45:47 | disruptek | maybe the compilers are sorting it out for me. |
| 20:45:51 | FromGitter | <Clyybber> @kaushalmodi_gitlab Ping |
| 20:45:52 | * | marmotini_ quit (Remote host closed the connection) |
| 20:45:52 | disruptek | kinda doubt it, though. |
| 20:46:07 | * | marmotini_ joined #nim |
| 20:46:08 | FromGitter | <Clyybber> disruptek: You mean upper bound the length? |
| 20:46:12 | disruptek | yeah. |
| 20:47:37 | disruptek | even if we don't do custom allocators, we could still do a little optimization there. |
| 20:48:53 | disruptek | even if we did it at runtime, it'd be an improvement. |
| 20:49:19 | FromGitter | <Clyybber> Hmm, maybe yeah |
| 20:50:02 | FromGitter | <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:03 | disbot | ➥ Fix docs |
| 20:53:16 | FromGitter | <kaushalmodi> Clybber: Yep got the first ping |
| 20:53:31 | FromGitter | <Clyybber> Ah, nice |
| 20:53:45 | FromGitter | <Clyybber> Do you know if base-href won't fuck up all other hrefs? |
| 20:53:52 | FromGitter | <kaushalmodi> it probably will |
| 20:53:55 | FromGitter | <kaushalmodi> hehe |
| 20:53:57 | FromGitter | <kaushalmodi> I was thinking more |
| 20:53:57 | FromGitter | <Clyybber> Hmm |
| 20:54:02 | disruptek | it'll only break relative hrefs. |
| 20:54:06 | FromGitter | <kaushalmodi> I see that nim doc accepts --git:url switch |
| 20:54:30 | FromGitter | <kaushalmodi> may be we need another switch like --git:base and prefix that to the css, js, etc |
| 20:54:41 | FromGitter | <kaushalmodi> for local docs, we would do `--git:base:/` |
| 20:54:44 | FromGitter | <timotheecour> that would be the most robust solution |
| 20:54:44 | FromGitter | <Clyybber> maybe we should just add an ../ to the href if we are in a subdir |
| 20:55:07 | FromGitter | <kaushalmodi> Clybber: THe subdir depth is not always 1 |
| 20:55:18 | FromGitter | <Clyybber> Sure, add N ../ I meant |
| 20:55:24 | FromGitter | <kaushalmodi> just prefixing the absolute base URL with make it always work |
| 20:56:00 | FromGitter | <Clyybber> I think relative is better no? Then we can move stuff around later, and it won't suddenly break |
| 20:56:18 | FromGitter | <kaushalmodi> it's kind of dynamic because we use the switch to specify the base |
| 20:56:42 | FromGitter | <kaushalmodi> .. and the base prefixing is only for resources |
| 20:56:58 | FromGitter | <kaushalmodi> so even if you move the files, the css, js will be fetched from the same base URL |
| 20:57:49 | FromGitter | <kaushalmodi> btw I am not a web expert, just talking based off my experience using the Hugo static site generator |
| 20:57:50 | FromGitter | <Clyybber> Hmm, is there any disadvantage over just prepending ../ times the subdir depth? |
| 20:58:06 | FromGitter | <kaushalmodi> then it becomes file position dependent |
| 20:58:20 | FromGitter | <Clyybber> But independent of the url |
| 20:58:24 | FromGitter | <kaushalmodi> true |
| 20:58:41 | FromGitter | <Clyybber> Hmm, I think independence of the url is preferable no? |
| 20:58:47 | FromGitter | <Clyybber> disruptek: Wdyt? |
| 20:59:35 | FromGitter | <kaushalmodi> instead of "../", why not just put the subdir name there? |
| 20:59:55 | FromGitter | <kaushalmodi> we would know the subdir names as well when we are creating those docs, right? |
| 20:59:58 | disruptek | no opinion, but i'm not too bothered since this stuff is created with software. |
| 21:00:10 | FromGitter | <kaushalmodi> nevermind, ignore my last message |
| 21:00:16 | FromGitter | <Clyybber> :p |
| 21:00:42 | disruptek | if it works, move on to something interesting. 😉 |
| 21:00:48 | FromGitter | <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:50 | disbot | ➥ `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:37 | FromGitter | <kaushalmodi> so.. I am good with relative links too.. using "../"xN makes sense |
| 21:01:45 | FromGitter | <Clyybber> @timotheecour Flattening the hierarchy would mean I can't have different docs for similarily named modules right? |
| 21:01:58 | FromGitter | <Clyybber> @kaushalmodi Ok, nice |
| 21:02:37 | FromGitter | <timotheecour> no read the issue ; it’d use mangling to allow that (just like nim c does) |
| 21:02:42 | FromGitter | <kaushalmodi> @timotheecour why not retain the subdirs? |
| 21:02:54 | FromGitter | <kaushalmodi> the mangled flat files names will be painful to read |
| 21:03:00 | FromGitter | <kaushalmodi> also they will be non-intuitive |
| 21:03:18 | FromGitter | <Clyybber> @timotheecour I wonder what it would solve |
| 21:03:22 | sschwarzer | kaushalmodi: agreed |
| 21:03:27 | FromGitter | <Clyybber> I don't entirely get it :p |
| 21:04:21 | sschwarzer | disruptek: better than moving on _before_ it works. ;) |
| 21:04:22 | FromGitter | <kaushalmodi> in the static site community, they have "ugly URLs" and "pretty URLs". I am in the pretty URLs camp |
| 21:04:45 | FromGitter | <kaushalmodi> ugly URL: `foo.com/abc.html` ⏎ pretty URL: `foo.com/abc/index.html` |
| 21:04:50 | disruptek | yep. |
| 21:05:09 | * | sschwarzer quit (Quit: leaving) |
| 21:05:29 | FromGitter | <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:50 | FromGitter | <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:59 | FromGitter | <Clyybber> @timotheecour That should be fixed yeah, but I don't agree we should flatten the hierarchy |
| 21:07:10 | FromGitter | <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:42 | FromGitter | <Clyybber> I agree |
| 21:18:03 | * | oculux quit (Quit: blah) |
| 21:18:22 | * | oculux joined #nim |
| 21:20:14 | FromGitter | <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:59 | FromGitter | <Clyybber> In this case I want to make the/path/of/nimdoc.out.css relative to the /path/of/the/current/file |
| 21:34:04 | shashlick | @leorize: how did you statically link with openssl |
| 21:36:37 | * | inv2004 joined #nim |
| 21:37:15 | Araq | https://github.com/nim-lang/Nim/pull/13179 significant milestone achieved, world domination is inevitable |
| 21:37:16 | disbot | ➥ ARC works for async on Windows |
| 21:38:31 | inv2004 | In 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:43:04 | Araq | thanks |
| 21:44:36 | FromDiscord | <exelotl> w...world domination!? |
| 21:45:10 | FromGitter | <Clyybber> Araq: Nice! |
| 21:46:43 | * | JustASlacker quit (Ping timeout: 260 seconds) |
| 21:51:25 | FromDiscord | <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:25 | FromDiscord | <Recruit_main_70007> (One of the latest entries) |
| 21:51:25 | FromDiscord | <Recruit_main_70007> https://forum.nim-lang.org/t/3 |
| 21:55:10 | FromDiscord | <demotomohiro> @Recruit_main_70007 Here is macro tutorial: https://nim-lang.org/docs/tut3.html |
| 21:57:30 | Araq | there is also a book covering this very example |
| 21:57:43 | Araq | online book, forgot the link but it's on our website |
| 21:59:36 | leorize | shashlick: --dynlibOverrideAll --passL:'-static -lssl -lcrypto' |
| 22:00:22 | FromDiscord | <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:33 | FromGitter | <kaushalmodi> about the Nim macros book: https://github.com/FemtoEmacs/nimacros/blob/master/nimacros/nimdoc.pdf |
| 22:01:08 | FromGitter | <kaushalmodi> .. https://forum.nim-lang.org/t/5383 |
| 22:03:22 | FromDiscord | <Recruit_main_70007> Tanks |
| 22:03:52 | lqdev[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:03 | Araq | yes, that one I had in mind |
| 22:05:06 | Araq | thanks lqdev[m] |
| 22:05:13 | FromDiscord | <Recruit_main_70007> Cool, now have to study, thank you all |
| 22:05:24 | FromGitter | <Clyybber> How do I run the doc tests? |
| 22:08:20 | shashlick | @leorize: core dump |
| 22:08:25 | shashlick | on ubuntu |
| 22:08:52 | leorize | your build or mine? |
| 22:08:54 | FromGitter | <Clyybber> disruptek: Can you test if your docs still work with https://github.com/Clyybber/Nim/commit/de2cb0664d550ea3cfeb67746ebccd138761ae16 ? |
| 22:08:59 | FromGitter | <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:08:59 | shashlick | mine |
| 22:09:25 | leorize | note that glibc is never meant to be linked statically... |
| 22:09:30 | FromGitter | <Clyybber> @timotheecour Yep, check your DM |
| 22:11:38 | leorize | shashlick: you might be better off spinning a void-linux musl variant docker |
| 22:11:54 | leorize | don't know if they build their libressl statically though |
| 22:12:31 | disruptek | static ssl libs are the new hotness. |
| 22:13:06 | rayman22201_ | 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:26 | rayman22201_ | Yesterday for you? Timezones are hard lol |
| 22:13:43 | leorize | :p why? |
| 22:14:23 | leorize | shouldn't it be too simple or am I missing something? |
| 22:15:27 | rayman22201_ | Well, consider it does not crash on the assignment. It crashes on a later read. |
| 22:17:23 | shashlick | Well ya I really want to do this for windows |
| 22:17:31 | shashlick | Will try that later |
| 22:18:18 | rayman22201_ | And the codegen produces a n eq_sink, which doesn't care that it was a null deref |
| 22:18:58 | leorize | rayman22201_: the eqsink is targetted torwards the deref of `b` |
| 22:19:06 | leorize | that's how I figured it out |
| 22:19:16 | leorize | but wdym by it crashes later? |
| 22:19:44 | leorize | the proc call after the assignment never showed up for me |
| 22:20:58 | rayman22201_ | For me, the assignment always worked, it was only a later call in asyncfutures line 172 that crashed. |
| 22:22:14 | leorize | fwiw I was using useMalloc |
| 22:22:21 | rayman22201_ | Me too |
| 22:22:36 | rayman22201_ | Gc arc and usemalloc |
| 22:22:50 | disruptek | that code never worked for me, and i'm on linux, too. |
| 22:23:03 | rayman22201_ | Weird.... |
| 22:23:35 | rayman22201_ | Something smells buggy and I can't put my finger on it... |
| 22:24:40 | leorize | eqsink___tz9aAourd6w9cPKT5l11V9cEw_2((&(*b)), T5_); |
| 22:24:47 | leorize | ^ that's the generated eqsink for me |
| 22:24:58 | leorize | it was targeting the pointer of b, which is NULL |
| 22:25:01 | leorize | causing the crash |
| 22:25:31 | leorize | heck it even dereference it before taking the address :p though I guess the C compiler would optimize that out |
| 22:30:22 | Araq | it has to optimize this because it can be the result of the C preprocessor |
| 22:30:26 | disruptek | gittyup now failing in cpp w/o arc. 🤦 |
| 22:30:44 | Araq | iirc the C spec requires this |
| 22:31:43 | * | NimBot joined #nim |
| 22:32:16 | disruptek | you told me what it means when windows takes too long to complete tests, but i've forgotten. |
| 22:32:53 | rayman22201_ | I bet the optimization is the issue. |
| 22:33:14 | * | filcuc joined #nim |
| 22:33:19 | rayman22201_ | Maybe no bug then |
| 22:34:19 | disruptek | it's a bug because memory starts off in the unfortunately state of `unallocated`. |
| 22:34:36 | leorize | well it's documented in Nim |
| 22:34:40 | leorize | ref are nil by default |
| 22:34:55 | disruptek | clearly. |
| 22:35:33 | Araq | disruptek: you really like my remark about features don't you... |
| 22:35:42 | disruptek | one of my favorites. |
| 22:36:36 | disruptek | technically, this is a codegen bug. |
| 22:40:26 | * | solitudesf quit (Ping timeout: 240 seconds) |
| 22:49:27 | shashlick | ok --gc:arc at least compiles toast now but crashes on run |
| 22:50:06 | * | natrys quit (Quit: natrys) |
| 22:50:44 | shashlick | crashes in nim-regex but could be anything |
| 22:52:37 | shashlick | ok well master doesn't even compile |
| 22:56:58 | shashlick | http://ix.io/27Ay |
| 22:59:40 | disruptek | probably simple but i don't recognize that behavior; is this 0.4.4 on head? |
| 23:00:44 | shashlick | yep |
| 23:00:53 | disruptek | reproduced it. |
| 23:01:06 | shashlick | newalgo branch compiles but crashes |
| 23:01:41 | * | inv2004 quit (Remote host closed the connection) |
| 23:01:50 | disruptek | well, you do have some include statements in here. |
| 23:03:00 | * | abm joined #nim |
| 23:07:33 | shashlick | how does that matter? |
| 23:07:44 | disruptek | free(foo: sink var Bar) breaks cpp codegen but free(foo: sink Bar) is fine. |
| 23:07:57 | disruptek | shashlick: 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…) |
