<< 27-12-2023 >>
01:35:13FromDiscord<Chronos [She/Her]> In reply to @isofruit "Like, I have my": What if you used an alternative approach to this, using pragmas instead? Idk, I'm not the smartest :P
02:22:17NimEventerNew Nimble package! ipacore - A base International Phonetic Alphabet type definition. , see https://github.com/phononim/ipacore
07:07:05*azimut joined #nim
07:14:29FromDiscord<nnsee> In reply to @isofruit "Did I mention that": i like KQL
07:16:55*azimut quit (Ping timeout: 240 seconds)
07:26:05*azimut joined #nim
09:20:48FromDiscord<Phil> In reply to @chronos.vitaqua "What if you used": For the entire thing: not necessarily, only the code blocks should be split out imo as they do not belong anywhere specifically.↵A new macro used as pragma could be valid, but that still requires a decent name😄
09:30:09FromDiscord<Elegantbeef> What does your macro actually do to those procs?
09:41:01FromDiscord<Phil> threadServer ? or the new one I'm contemplating?
09:41:30FromDiscord<Elegantbeef> The aforementioned proc inside the `codeBlocks`
09:43:52FromDiscord<Elegantbeef> Ostensibly the macro needs those procs to exist before it expands for reasons
09:44:30FromDiscord<Phil> ThreadServer eats it (codeblocks is not a macro in that example, threadServer is eats an untyped body).↵the codeblocks section is emitted back out with the `prepareServer` call.↵That way I can guarantee that the procs defined in there have access to all Message-Types I generate in the various invocations of the ThreadServer macro
09:48:16*PMunch joined #nim
09:51:37FromDiscord<Elegantbeef> Could almost use the effect system here, shame that `runAsTask` is not owned by you 😄
09:51:58FromDiscord<Phil> In what sense? It is a template of mine
09:52:05FromDiscord<Elegantbeef> Oh it is
09:52:10FromDiscord<Elegantbeef> We're in business
09:52:22FromDiscord<Elegantbeef> You can force the procedure it runs to have a specific tag
09:52:25FromDiscord<Phil> I hide status/nim-taskpools "spawn" call with it
09:52:40FromDiscord<Elegantbeef> No clue if all `runAsTask` need the call at the end though
09:55:18FromDiscord<Phil> Call in the end? You mean the invocation?
09:55:34FromDiscord<Elegantbeef> I mean does `runAsTask` always expect a procedure call
09:55:36FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
09:55:45FromDiscord<Phil> it itself does not, nim-taskpools does
09:56:03FromDiscord<Elegantbeef> Right so then maybe effect tracking is the real solution here
09:57:44FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
09:57:46FromDiscord<Elegantbeef> For an example
09:57:54FromDiscord<Elegantbeef> Notice it errors at line 22
09:57:56FromDiscord<Phil> I'll need to read up on that when I can fully focus to see how that would help me.↵So far I've understood the effects system solely as a kind of "tagging" mechanism where you can exclude non-tagged stuff
09:58:17FromDiscord<Elegantbeef> You can also use macros to introspect expressions and force them to have tags
09:58:28FromDiscord<Elegantbeef> Well calls rather
09:59:27FromDiscord<Elegantbeef> If you annotate your procs with your given tag you can ensure at `runAsTask` that they match a specific call.... and that falls apart since you'd need to forward declare
09:59:29FromDiscord<Elegantbeef> Nevermind
10:00:56FromDiscord<Phil> Yeh, the need to forward declare is what made me thing of a "eat proc def in a macro and spawn it back when calling prepareServers"
10:01:03FromDiscord<Phil> (edit) "thing" => "think" | "thinkof a "eat proc def in a macro and spawn it back when calling prepareServers" ... " added "approach"
10:01:09FromDiscord<Elegantbeef> I mean the forward declare is fine
10:01:22FromDiscord<Elegantbeef> The issue is mainly just you cannot force the body to do anything with a forward declare
10:01:32FromDiscord<Elegantbeef> Which tags would work... if you didnt need the forward declare 😄
10:01:56FromDiscord<Phil> Because you have this implicit dependency that if a handler spawns a task the proc that will be outsourced must be defined ahead of time, but the task-proc must be defined after the threadServer calls whose message types it needs
10:02:37FromDiscord<Phil> And I feel like hammering that into user's head is meh
10:03:47FromDiscord<Elegantbeef> Yea this is exactly where effect tracking would shine
10:03:49FromDiscord<Elegantbeef> If someone did not call your proc they would either have to call your proc or lie and annotate it as `tags: [RunTag]`
10:05:05FromDiscord<Elegantbeef> Single pass compilers are a fickle beast
10:05:26FromDiscord<Elegantbeef> Nim 3.0 with order independent procedures so effect tracking can be used more!
10:24:45PMunchThis is so damn weird.. I have a --passC:"-I<some path>" statement in my config.nims that doesn't show up in the compiler command line
10:24:59PMunchI have more than one of these, and most of them do show up
10:25:06PMunchBut one particular one doesn't
10:28:58PMunchShuffling two statements around made it work..
10:29:05PMunchNow both statements are included
10:29:09PMunchThis is super strange..
10:36:00ehmryis there a trick to make a `when` statement to check for compile-time?
10:36:23ehmry`nimvm` is a `let` in system and I can't use it inside type definitions
10:36:44PMunchWhat do you mean? `when` is always evaluated on compile-time
10:37:31ehmrywhat I'm really trying to do is remove a field from an object when the object is a compile-time const
10:37:43ehmryand `when nimvm:` doesn't work
10:38:39ehmrybecause the field is a `ref object`
10:38:55PMunchDo you have a minimal reproduction? That sounds weird
10:40:05PMunchOh wait, you want to have a type, and when it is used in a compile-time const context for that type to be different from its runtime counterpart?
10:42:17ehmryyea
10:43:09PMunchI'm not sure that's allowed
10:43:50ehmryokay, I may have to make a constable base objec and then inherit the runtime object from it
10:43:56PMunchWhy do you want to remove it? Since it's compile-time it shouldn't really affect performance or anything
10:44:32ehmryI want to remove a field because its a ref, and you can't have a const ref (as I understand it)
10:45:12ehmryI'm parsing this object out of a pragma at compile-time…
10:47:30ehmryI can parametrize the field in the type but I think that makes things too complicated later on
10:48:53PMunchAh I see
11:21:38FromDiscord<redmechanics> how can i reverse a sequence ?
11:26:33FromDiscord<demotomohiro> https://nim-lang.org/docs/algorithm.html#reversed%2CopenArray%5BT%5D
11:27:33FromDiscord<redmechanics> In reply to @demotomohiro "https://nim-lang.org/docs/algorithm.html#reversed%2": thanks i've been struggling for 30min but i realized i didn't import the library
12:38:49*Guest11 joined #nim
12:39:02*Guest11 quit (Client Quit)
13:07:05*krux02 joined #nim
13:46:11*jmdaemon quit (Ping timeout: 264 seconds)
14:55:44FromDiscord<nasuray> In reply to @PMunch "This is so damn": where you setting the `--cc` or `--os` at any point in those switches?
14:57:52PMunchYup
15:10:00PMunchUgh, stuck again with this wrapping project..
15:10:32PMunchIt builds, nothing complains any longer, but it doesn't work..
15:26:51FromDiscord<nasuray> In reply to @PMunch "Yup": that resets the other flags I think so it needs to come before the other related flags
15:29:32*krux02 quit (Remote host closed the connection)
16:04:34PMunchWell, those are set at the top, then all the other stuff beneath it. My reshuffling only shuffled --passC statements
16:04:36*PMunch quit (Quit: Leaving)
16:04:46*derpydoo joined #nim
16:10:13FromDiscord<nasuray> In reply to @PMunch "Well, those are set": Ah a true mystery then
16:32:52FromDiscord<redmechanics> sent a code paste, see https://play.nim-lang.org/#ix=html>
16:49:13FromDiscord<pmunch> Not much
16:50:14FromDiscord<pmunch> `return` obviously breaks the procedure at that point, while `result` is just a normal assignment and isn't returned until the end
17:40:34FromDiscord<Phil> In reply to @redmechanics "what the difference of": Stylistically you can use result if you want to build up a value over multiple operations, it's kinda neat there. You can of course also forego it entirely
18:10:14*xet7 quit (Remote host closed the connection)
18:33:07*xet7 joined #nim
18:34:25FromDiscord<Phil> sent a long message, see <!doctype html>
18:34:54FromDiscord<Phil> (edit)
18:58:09FromDiscord<Phil> Or did you mean to sort of force users to tag their tasks with e.g. a specific macro that allows emitting the actual proc later where it'll have access to all the symbols it needs?
19:10:29FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
19:10:39FromDiscord<Phil> (edit)
19:10:55FromDiscord<Phil> (edit)
19:11:56FromDiscord<Phil> (edit)
19:25:02FromDiscord<Prestige> Does the io package not exist anymore?
19:27:24FromDiscord<nnsee> In reply to @avahe "Does the io package": iirc it got renamed to syncio
19:27:47FromDiscord<nnsee> in std it is, not system
19:27:58FromDiscord<Prestige> thank you
19:37:41FromDiscord<Elegantbeef> I meant that you would not need to force the macro to take in a proc and just use forward declares like a normal Nim program↵(@Phil)
19:37:59FromDiscord<Elegantbeef> Forward declares are not ugly imo and are preferable to a DSL
19:38:58FromDiscord<Phil> I mean I sorta agree. I don't per se have a problem with the forward declare.↵I have a problem with the fact that _you must know that the implementation must be placed between the call to threadServer() and the call to prepareServers()
19:41:29FromDiscord<Phil> sent a long message, see <!doctype html>
19:42:34FromDiscord<Phil> (edit)
20:09:33*junaid_ joined #nim
20:22:44FromDiscord<user2m> anyone know of a good full featured terminal ui for nim?
20:22:51FromDiscord<user2m> (edit) "anyone know of a good full featured terminal ui ... for" added "lib"
20:25:38FromDiscord<nnsee> In reply to @user2m "anyone know of a": nimwave, illwill
20:25:54FromDiscord<nnsee> depends on your definition of "full featured" though
20:28:09FromDiscord<user2m> In reply to @nnsee "depends on your definition": I just need a menu lol was hoping to find something like etxtual (https://github.com/Textualize/textual). illwill looks nice thx!
20:51:26*junaid_ quit (Remote host closed the connection)
21:01:13*mj_ joined #nim
21:08:49*jmdaemon joined #nim
21:52:07*mj_ quit (Quit: mj_)
21:52:25*mjensen joined #nim
21:55:31*mjensen quit (Remote host closed the connection)
22:29:34FromDiscord<nasuray> In reply to @user2m "I just need a": https://github.com/enthus1ast/illwillWidgets might be helpful as well
22:39:52FromDiscord<Phil> @can.l Sanity check, did you ever contemplate an extension for owlkettle where one just provides a single central store instance (ref-type) and passes that to all widgets?↵The idea would be that whenever the user changes any field on the proc it triggers a re-render.↵Easier state sharing throughout the application, particularly when one Widget that is "far away" from another Widget in the same Widget-tree needs to use the same state.
23:15:43*azimut quit (Ping timeout: 240 seconds)
23:20:28NimEventerNew thread by RegularAlias: Nimstrict: A case sensitivity linter for Nim , see https://forum.nim-lang.org/t/10809
23:29:52*mal`` quit (Quit: Leaving)
23:49:43FromDiscord<can.l> In reply to @isofruit "<@893965307171979326> Sanity check, did": You can already do that as an architecture design pattern.
23:50:38FromDiscord<can.l> I usually recoomennd having a `Model = ref object` type that stores the application state.
23:53:36FromDiscord<can.l> E.g. for the Graphing app there is a [`Project` type](https://github.com/can-lehmann/Graphing/blob/main/src/graphing.nim#L753) that can be passed around.
23:55:17FromDiscord<can.l> And the crud example has the [`UserModel`](https://github.com/can-lehmann/owlkettle-crud/blob/main/src/model/user_model.nim#L55) type
23:57:50*Lord_Nightmare quit (Quit: ZNC - http://znc.in)