| 00:07:06 | * | Mister_Magister quit (Quit: bye) |
| 00:08:58 | * | Mister_Magister joined #nim |
| 01:39:50 | * | SchweinDeBurg joined #nim |
| 01:47:50 | * | Balls joined #nim |
| 01:48:16 | Balls | Hey there, why still no working debug tooling ? |
| 01:54:59 | * | jkl__ joined #nim |
| 01:55:21 | * | def-- joined #nim |
| 01:55:45 | * | jkl quit (Ping timeout: 242 seconds) |
| 01:55:45 | * | def- quit (Ping timeout: 242 seconds) |
| 01:55:45 | * | def-- is now known as def- |
| 02:03:01 | FromDiscord | <_timurski> ? |
| 02:03:21 | FromDiscord | <_timurski> Nim compiles to C. just compile with debug symbols on and everything works great |
| 02:04:08 | FromDiscord | <_timurski> i personally don't really find myself needing more than that, it's pretty easy to follow |
| 02:08:17 | * | jkl joined #nim |
| 02:11:47 | * | jkl__ quit (*.net *.split) |
| 02:11:48 | * | tokyovigilante quit (*.net *.split) |
| 02:11:48 | * | noeontheend quit (*.net *.split) |
| 02:11:48 | * | redj quit (*.net *.split) |
| 02:11:48 | * | Jhonny2x4 quit (*.net *.split) |
| 02:13:14 | * | Balls quit (Quit: Client closed) |
| 02:27:10 | * | noeontheend joined #nim |
| 02:27:14 | * | Jhonny2x4 joined #nim |
| 02:27:15 | * | tokyovigilante joined #nim |
| 02:27:19 | * | redj joined #nim |
| 04:04:22 | * | KawaiiSelbst quit (Remote host closed the connection) |
| 04:05:09 | * | KawaiiSelbst joined #nim |
| 04:13:11 | FromDiscord | <joetroll> sent a long message, see https://paste.rs/zhgQs |
| 04:48:11 | FromDiscord | <_timurski> In reply to @joetroll "not sure where to": you should be able to pretty easily have zero overhead currying with macros |
| 04:49:15 | FromDiscord | <_timurski> also your `add` doesn't need to be a closure |
| 04:49:25 | FromDiscord | <_timurski> (edit) "closure" => "closure, can be just a nimcall" |
| 04:50:44 | FromDiscord | <joetroll> In reply to @_timurski "you should be able": how so? right now it needs to create closures for each step, and i guess i could try some template stuff but i'm not sure if it's worth it in the end↵overhead is around 1.75x slower anyways on real world usage, the problem is more so immediate currying that's SUPER slow |
| 04:55:18 | FromDiscord | <_timurski> sent a code paste, see https://paste.rs/NcHma |
| 04:55:25 | FromDiscord | <_timurski> In reply to @joetroll "how so? right now": you should not be using `{.closure.}` btw |
| 04:55:37 | FromDiscord | <_timurski> `{.closure.}` implies it captures an environment variable |
| 04:55:42 | FromDiscord | <_timurski> which your `add` doesn't need to |
| 04:55:48 | FromDiscord | <_timurski> In reply to @_timurski "`{.closure.}` implies it captures": this adds some overhead |
| 04:56:47 | FromDiscord | <_timurski> that probably accounts for your performance loss |
| 04:58:19 | FromDiscord | <joetroll> sent a code paste, see https://paste.rs/9WEat |
| 04:58:27 | FromDiscord | <joetroll> (edit) "https://paste.rs/klx0i" => "https://paste.rs/hFXcD" |
| 04:58:34 | FromDiscord | <_timurski> sent a code paste, see https://paste.rs/wkEQC |
| 04:59:39 | FromDiscord | <_timurski> it's just too fun designing ncie interfaces |
| 04:59:43 | FromDiscord | <_timurski> (edit) "ncie" => "nice" |
| 05:01:36 | FromDiscord | <_timurski> it's kinda funny, i've been inspired to start learning graph theory because of this orchestration project ive been working on just because so much of it is graph-related |
| 05:02:11 | FromDiscord | <_timurski> and i think there might even be some research potential in graph-generators, so if i learn enough maybe ill talk to a professor about it |
| 05:06:46 | FromDiscord | <joetroll> In reply to @_timurski "when i was like": this is very cool! so `lift` takes just an ordinary function and adapts it to operate inside whatever computational structure `so[...]` is using? |
| 05:06:54 | FromDiscord | <DetermiedNim1> In reply to @joetroll "not sure where to": do you have this on github/codeberg/smth 👀 |
| 05:07:08 | FromDiscord | <joetroll> In reply to @determiedmech1 "do you have this": not yet, will post soon probably though! |
| 05:07:20 | FromDiscord | <DetermiedNim1> 🔥 |
| 05:11:08 | FromDiscord | <joetroll> In reply to @_timurski "which your `add` doesn't": also hm i checked, the pragma doesnt seem to affect much. a + b captures nothing so no environment is allocated↵it DOES fail, however, on something like `typeof(add1) is typeof(add2)` (when add2 is a nimcall), prob because the pragma pins the type to the closure |
| 05:13:31 | FromDiscord | <_timurski> sent a code paste, see https://paste.rs/f0fER |
| 05:15:27 | FromDiscord | <_timurski> so if you have a tuple `(A, B, A)` and `f : A -> C`, then `lift[(here, _, here](f)` would be of type `(A, B, A) -> (C, B, C)` where `f` is applied independently to the first and third slots of the incoming tuple |
| 05:15:55 | FromDiscord | <_timurski> In reply to @_timurski "when i was like": so here it's used to apply `fix` to `(code, audit.issues)` but not the other field |
| 05:17:13 | FromDiscord | <_timurski> you could also write like `decompose >>> lift[seq[here]](solve) >>> synthesize` and it would apply `solve` to each element of the `seq` outputted by `decompose` |
| 06:35:30 | * | Skippy8 joined #nim |
| 06:53:19 | * | Skippy8 quit (Ping timeout: 247 seconds) |
| 07:47:08 | FromDiscord | <joetroll> In reply to @determiedmech1 "do you have this": there you go, i'll post to nimble when i can later <https://gitlab.com/joetroll/naskell> . code improvements and suggestions are always welcome!↵fyi, the js backend cant use thunks atm. i opened an issue and if it gets fixed i'll check again |
| 08:07:06 | * | SchweinDeBurg quit (Remote host closed the connection) |
| 08:12:26 | * | SchweinDeBurg joined #nim |
| 08:12:56 | * | SchweinDeBurg quit (Read error: Connection reset by peer) |
| 08:13:39 | * | SchweinDeBurg joined #nim |
| 08:29:47 | * | SchweinDeBurg quit (Remote host closed the connection) |
| 08:30:33 | * | SchweinDeBurg joined #nim |
| 08:32:46 | * | KawaiiSelbst quit (Remote host closed the connection) |
| 08:33:04 | * | KawaiiSelbst joined #nim |
| 08:59:38 | * | Skippy8 joined #nim |
| 10:50:43 | * | beholders_eye joined #nim |
| 11:27:22 | * | noeontheend_ joined #nim |
| 11:34:37 | * | Skippy8 quit (*.net *.split) |
| 11:34:37 | * | noeontheend quit (*.net *.split) |
| 11:34:37 | * | acidsys quit (*.net *.split) |
| 11:34:38 | * | noeontheend_ is now known as noeontheend |
| 11:35:14 | * | Skippy8 joined #nim |
| 11:36:55 | * | acidsys joined #nim |
| 11:42:41 | * | beholders_eye quit (Ping timeout: 265 seconds) |
| 11:42:58 | * | insanescholar joined #nim |
| 11:49:58 | * | insanescholar quit (Ping timeout: 262 seconds) |
| 12:01:35 | FromDiscord | <moigagoo> Hi!↵↵I never thought about it, but isn't it weird that you can only inherit from non-final object types (https://nim-lang.org/docs/manual.html#types-tuples-and-object-types)? I mean, final objects are the ones that do not have an ancestor. Doesn't that make them ideal inheritable roots? |
| 12:07:05 | * | insanescholar joined #nim |
| 12:08:23 | * | sdothum quit (Remote host closed the connection) |
| 12:11:27 | * | beholders_eye joined #nim |
| 12:13:59 | * | sdothum joined #nim |
| 12:15:30 | FromDiscord | <Laylie> the point of `{.final.}` is to specify that the type cannot be inherited from, so the question is why do we want object types to be uninheritable by default, and i think the answer is because we typically expect inheritable objects to have type info, you need to explicitly say `{.inheritable.}` if you want to break this expectation. |
| 12:35:21 | * | KawaiiSelbst quit (Remote host closed the connection) |
| 12:36:07 | * | KawaiiSelbst joined #nim |
| 12:39:44 | * | beholders_eye quit (Ping timeout: 246 seconds) |
| 12:41:45 | * | beholders_eye joined #nim |
| 13:00:09 | FromDiscord | <moigagoo> sent a long message, see https://paste.rs/vpoiU |
| 13:17:35 | FromDiscord | <Laylie> i wouldn't say 1. is one of the meanings of final, it just happens that the compiler treats objects that have no ancestor (i.e. that have no typeinfo and are not already part of an inheritance hierarchy) as not inheritable unless explicitly marked as such. |
| 13:47:23 | FromDiscord | <b0rsuk> @_timurski Are there any news about CPUs designed specifically for functional programming languages? I found some mention of "Reducetron" but the website stopped publishing news. |
| 13:51:06 | * | xet7 quit (Remote host closed the connection) |
| 13:59:14 | FromDiscord | <b0rsuk> sent a long message, see https://paste.rs/eGdsy |
| 14:00:04 | FromDiscord | <b0rsuk> (I was looking for explanation of what `{.inline.}` is, I thought maybe it changes the language syntax, but no, it's a hint to the compiler) |
| 14:01:39 | FromDiscord | <Laylie> macros might count as a third use |
| 14:01:53 | FromDiscord | <Laylie> macro calls |
| 14:02:47 | FromDiscord | <b0rsuk> It would be nice if all the possible uses of this were explained in one place. Proc signatures often have those things and I wasn't sure if they were trying to tell me something how those procs should be used. |
| 14:03:35 | FromDiscord | <b0rsuk> (edit) "explained" => "listed(not necessarily explained)" |
| 14:03:55 | FromDiscord | <Laylie> macro pragmas are covered along with the rest of the pragmas (under "User-defined pragmas"), but I guess there isn't anywhere that specifically mentions calling conventions in relation to pragmas |
| 14:06:12 | FromDiscord | <_timurski> In reply to @b0rsuk "<@670122070448799774> Are there any": no idea |
| 14:11:05 | FromDiscord | <_timurski> doesn't really sound necessary though |
| 14:23:11 | * | KawaiiSelbst quit (Remote host closed the connection) |
| 14:23:27 | * | KawaiiSelbst joined #nim |
| 14:49:42 | * | sdothum quit (Remote host closed the connection) |
| 14:52:00 | * | sdothum joined #nim |
| 15:14:35 | * | sdothum quit (Remote host closed the connection) |
| 15:17:52 | * | sdothum joined #nim |
| 15:33:07 | FromDiscord | <moigagoo> In reply to @Laylie "i wouldn't say 1.": Yeah, that's kinda the thing that confused me. Why would the compiler treat objects that don't have an ancestor as ones that can't have ancestors? These properties sound completely unrelated. |
| 15:41:22 | FromDiscord | <Laylie> inheriting from RootObj is how you get typeinfo into your object type, so I assume that implicit final-ness is meant to prevent people from accidentally inheriting from a type that doesn't have typeinfo and hitting unexpected behavior. |
| 16:33:03 | * | PMunch joined #nim |
| 16:36:36 | FromDiscord | <DetermiedNim1> In reply to @joetroll "there you go, i'll": I just looked at the gitlab and the logo is amazing |
| 17:44:10 | * | PMunch quit (Quit: Leaving) |
| 17:46:29 | * | PMunch joined #nim |
| 18:05:29 | * | midgard_ joined #nim |
| 18:05:51 | * | tokyovigilante quit (Ping timeout: 240 seconds) |
| 18:05:51 | * | om3ga quit (Ping timeout: 240 seconds) |
| 18:05:51 | * | midgard quit (Read error: Connection reset by peer) |
| 18:05:51 | * | redj quit (Quit: No Ping reply in 180 seconds.) |
| 18:05:53 | * | Ekho quit (Ping timeout: 240 seconds) |
| 18:05:57 | * | om3ga_ joined #nim |
| 18:05:59 | * | ftajhii quit (Write error: Connection reset by peer) |
| 18:06:32 | * | Jhonny2x4 quit (Ping timeout: 256 seconds) |
| 18:06:32 | * | tanami quit (Ping timeout: 256 seconds) |
| 18:06:39 | * | tanami joined #nim |
| 18:06:46 | * | Jhonny2x4 joined #nim |
| 18:06:57 | * | redj joined #nim |
| 18:07:01 | * | midgard_ is now known as midgard |
| 18:10:53 | * | Ekho joined #nim |