<< 02-01-2020 >>
00:41:38*tane quit (Quit: Leaving)
00:44:05*rockcavera joined #nim
00:56:44*rockcavera quit (Remote host closed the connection)
01:00:41*rockcavera joined #nim
01:05:03*hpyc9 quit (Remote host closed the connection)
01:05:26*hpyc9 joined #nim
01:20:53*mug3n joined #nim
01:21:33*mug3n left #nim (#nim)
01:30:28*ng0 quit (Quit: leaving)
01:35:16FromDiscord<treeform> @mratsim I replied to your comment. cgreenlet already benches setcontext.
01:35:55FromDiscord<treeform> cgevent switcher appears to be 220 times faster then setcontext
01:36:59FromDiscord<mratsim> As vyukov analyzed in there: http://www.1024cores.net/home/lock-free-algorithms/tricks/fibers, setcontext requires 2 syscalls (which are about 150 cycles each if you remember)
01:37:31FromDiscord<mratsim> his code uses setjmp combined with setcontext AFAIk to avoid those costs
01:37:49FromDiscord<mratsim> so pure setcontext or pure setjmp benchmarks are probably not applicable
01:43:10FromDiscord<treeform> setjmp way faster, but can you use it that way?
01:43:20FromDiscord<treeform> i bench setjmp as well?
01:43:29FromDiscord<treeform> which is fast but not faster then doing less
01:44:01*ng0 joined #nim
01:44:43*ng0 quit (Client Quit)
01:48:02*ng0 joined #nim
01:48:02*ng0 quit (Changing host)
01:48:02*ng0 joined #nim
01:54:09*MarquisdeFalbala quit (Ping timeout: 268 seconds)
01:59:03*endragor joined #nim
02:06:30FromDiscord<mratsim> well i'm just saying that the benchmarks of just setjmp or just setcontext do not represent his "fast fiber trick"
02:06:46FromDiscord<mratsim> goign to sleep
02:06:51FromDiscord<treeform> good night
02:07:31FromDiscord<mratsim> indeed, doing less is very probably faster, but by how much is interesting as well
02:08:26FromDiscord<mratsim> especially given that his solution would be pure C and so wouldn't require PowerPC/Itanium/MIPS hardware to test on (assuming the compiler generates crrect code)
02:21:09*ng0 quit (Quit: leaving)
02:21:51*dwdv quit (Ping timeout: 265 seconds)
02:23:14FromDiscord<treeform> My bench only does switching I have no bench to test whole fiber implementation?
02:23:18FromDiscord<treeform> I already test setjmp
02:23:26FromDiscord<treeform> I already bench setjmp
03:02:56FromGitter<Varriount> Araq: Regarding goto-based exceptions, if they are more performant than C++ exceptions, why doesn't C++ use them?
03:04:46*muffindrake quit (Ping timeout: 252 seconds)
03:07:07*muffindrake joined #nim
03:18:42*dddddd quit (Ping timeout: 260 seconds)
03:43:41*rockcavera quit (Remote host closed the connection)
04:03:04*muffindrake quit (Ping timeout: 252 seconds)
04:05:22*muffindrake joined #nim
04:16:49*Hideki_ joined #nim
04:36:48muffindrakeIs there no short-hand slicing syntax for 'start at index x and give me everything up until the end', or did I miss something?
04:37:03disruptekfoo[45 .. ^1]
04:37:13muffindrakeD'oh. Thank you.
04:37:22muffindrakeFor a second I assumed that was part of a different language
04:37:22disruptekfoo[45 .. foo.high] would work, too.
04:37:46muffindrakethe latter would be too verbose either way
04:38:40*chemist69_ joined #nim
04:38:53disruptekuseful for generics.
04:39:04shashlick..<
04:41:42*chemist69 quit (Ping timeout: 258 seconds)
05:06:57*nsf joined #nim
05:19:30*Hideki_ quit (Ping timeout: 268 seconds)
05:48:04*endragor quit (Remote host closed the connection)
06:16:06*marmotini_ joined #nim
06:22:22*marmotini_ quit (Remote host closed the connection)
06:22:34*nsf quit (Quit: WeeChat 2.6)
06:40:38*Hideki_ joined #nim
06:56:27*narimiran joined #nim
07:08:27*endragor joined #nim
07:12:53*endragor quit (Ping timeout: 260 seconds)
07:28:59*solitudesf joined #nim
07:30:55*PMunch joined #nim
07:38:06PMunchHappy new years everyone!
08:00:00*gmpreussner quit (Quit: kthxbye)
08:05:16*gmpreussner joined #nim
08:30:45*nsf joined #nim
08:37:43*JustASlacker joined #nim
08:45:58*marmotini_ joined #nim
08:46:10*Vladar joined #nim
08:49:47FromGitter<alehander92> i start to agree with araq
08:50:03FromGitter<alehander92> and others that richer bare metal frameworks
08:50:08FromGitter<alehander92> might be the better fix
08:50:28FromGitter<alehander92> think about it, if they provide you with a good set of different modules/primitives you can combine
08:50:43FromGitter<alehander92> how you need for your very optimized server/app
08:51:24FromGitter<alehander92> why doing the whole syscall/normal kernel overhead and tricks to make it play with 30 years of compatiblity
08:51:38FromGitter<alehander92> (which is great for user systems, but just not so obvious to me for this usecase)
08:52:01*marmotini_ quit (Ping timeout: 258 seconds)
08:52:34FromGitter<alehander92> also easier to static check / whole "kernel+app" optimize / review for security
08:53:09FromGitter<alehander92> compared to 100k/?m loc + your app + deps
08:53:31FromGitter<alehander92> wonder why this isn't the mainstream
08:54:09FromGitter<alehander92> in the same way a lot of server stuff moved to linux because you dont really need to make it work with windows/osx if you really focus on that
08:54:17*marmotini_ joined #nim
08:55:43FromGitter<alehander92> a ecosystem of relatively compatible components which can generate small bare metal apps (so you can easily still add shells/different kinds of processes/tools etc etc ) and can be easily ran in light vm-s on dev machines
08:56:42FromGitter<alehander92> it makes sense its not yet popular, but it just sounds good to me, + makes it much easier to experiment with new os research if you just import the experimental components instead
08:59:18*marmotini_ quit (Ping timeout: 258 seconds)
09:06:38FromGitter<gogolxdong> Anyone knows `/mnt/d/llvm-project/llvm/include/llvm/Support/FileSystem.h:702:19: error: ‘class llvm::sys::fs::file_status’ has no member named ‘getSize’ ⏎ Result = Status.getSize();`
09:10:19*Hideki_ quit (Remote host closed the connection)
09:11:31*Hideki_ joined #nim
09:16:04*Hideki_ quit (Ping timeout: 265 seconds)
09:24:08Araqalehander92: plus most stuff runs on a "virtualized" server with containers and stuff anyway, in other words, nobody really trusts the C based OSes with their millions of lines of 'if err goto ErrorHandler' bullshit hand-written code
09:27:24JustASlackeras opposed to code that is not hand-written?
09:28:43Araqyeah, you can generate code, use a compiler in order to do that
09:31:27JustASlackerah, you mean hand-written C code
09:33:02PMunchI prefer to type all my code using my feet
09:33:16PMunchSince it's so much harder it really makes you think about what you should be writing
09:33:25PMunchSo it makes for better code quality
09:33:45fireglowmanufacture for bespoke hand-crafted code
09:33:58JustASlackerme, Im a nose-typing guy
09:34:17JustASlackerI feel that gets me closer to my code and really helps understand it
09:34:23PMunchI would be too, but my keyboard smell of feet..
09:34:29JustASlackerthats tough
09:35:59AraqPMunch, yeah, that's it in a nutshell. Also let's not use safety belts and instead drive very carefully instead
09:46:36*Hideki_ joined #nim
09:47:16*uvegbot quit (Ping timeout: 248 seconds)
09:52:32*noonien quit (Quit: Connection closed for inactivity)
10:02:43go|dfish
10:07:09*Hideki_ quit (Ping timeout: 258 seconds)
10:08:18*ng0 joined #nim
10:20:24FromGitter<alehander92> Araq yes i agree
10:20:42FromGitter<alehander92> but indeed you're right that even in production this kinda works
10:21:24FromGitter<alehander92> i meant more like that this kind of setup doesnt make it much harder to develop for and thats important
10:21:48FromGitter<alehander92> the target of software X doesnt need to support .. being a good dev environment for writing X
10:22:06*endragor joined #nim
10:27:08Araqanyway, devel's ARC is now shipping with "goto based exception handling"
10:27:51Araqthis means pretty much all of Nim can be used for kernel development or simply when you lack an OS
10:28:13Araqhowever, I'm struggling with the design of the compiler switches
10:29:31Araqwe have --os:standalone but it disabled too much stuff
10:31:12FromGitter<sheerluck> I wanted to write some code in the Nim, but I still celebrate the New Year, because a lot of delicious food is left. And when I'm full I can’t program. I'm sorry and happy new year to all
10:37:39*moon-chi1led joined #nim
10:38:58*lmariscal06 quit (Ping timeout: 258 seconds)
10:39:40*moon-chilled quit (Ping timeout: 264 seconds)
10:40:52*Vladar quit (Quit: Leaving)
10:42:11Araqhappy new year too
10:42:14*Hideki_ joined #nim
10:42:23*leorize quit (Ping timeout: 240 seconds)
10:42:35*sammich quit (Ping timeout: 265 seconds)
10:42:45*pbb quit (Ping timeout: 246 seconds)
10:42:56Araqlol "Almost every single response on this page would have been avoided if people had just read the paper."
10:43:04Araqfrom https://wiki.c2.com/?ExoKernel
10:43:15*moon-chi1led quit (Ping timeout: 264 seconds)
10:44:02*lmariscal06 joined #nim
10:44:18*sammich joined #nim
10:45:22*pbb joined #nim
10:46:59*leorize joined #nim
10:47:38*moon-chilled joined #nim
10:49:57*Amun_Ra joined #nim
10:50:36*marmotini_ joined #nim
10:51:30*Cthalupa quit (Read error: Connection reset by peer)
10:51:46*Cthalupa joined #nim
10:55:22FromGitter<alehander92> good!
10:55:40FromGitter<alehander92> yeah i have to try again building with devel + os:arc
10:55:41FromGitter<alehander92> then
10:56:37FromGitter<alehander92> indeed i remember there were maybe some limitations with --os:standalone, but were they about allocation or only about syscall-dependent sttuff
10:57:12*sealmove joined #nim
10:58:35*sealmove quit (Client Quit)
10:58:52*sealmove joined #nim
11:01:36*Hideki_ quit (Remote host closed the connection)
11:01:44*sealmove quit (Client Quit)
11:02:01*sealmove joined #nim
11:02:33*sealmove quit (Client Quit)
11:02:48*sealmove joined #nim
11:02:53*Trustable joined #nim
11:04:03*Hideki_ joined #nim
11:06:41*Hideki_ quit (Remote host closed the connection)
11:06:56*Hideki_ joined #nim
11:11:51sealmoveZevv: there is an annoying leftover echo, I think in peg() in npeg.nim.
11:13:17Zevvyou're easily annoyed?
11:13:51sealmoveeh, just didn't want to make a github issue for something like this
11:13:54Zevv:)
11:14:18Zevvthanks for reporting, threw it out!
11:14:26Zevvis that worth a release?
11:14:29sealmovenah
11:14:33Zevvk!
11:15:18sealmovejust got a new laptop, installed all nerdy things (archlinux + i3 + fish + ranger + neovim)
11:15:36Zevvpff, *real* nerds use Xmonad!
11:15:54sealmovehaha, I draw the line somewhere, otherwise yes, and gentoo
11:19:29*Hideki_ quit (Remote host closed the connection)
11:20:07sealmovecan I get command-line parameters at CT>
11:20:08sealmove?*
11:20:14*Hideki_ joined #nim
11:25:11*Hideki_ quit (Ping timeout: 268 seconds)
11:28:41*Hideki_ joined #nim
11:33:20*Hideki_ quit (Ping timeout: 265 seconds)
11:33:57*nsf quit (Quit: WeeChat 2.6)
11:34:34lqdev[m]real nerds use a plain tty.
11:37:48fireglowi read text on a line printer and input by having the computer parse rubik cubes
11:38:02*dwdv joined #nim
11:38:07Araqthe lumberjacks here in the woods use chain saws.
11:38:32Araqfor some reason they don't use axes anymore.
11:39:01Araqmaybe they believe in technology and progress, I don't know
11:39:10Araqgood that real programmers don't.
11:40:52JustASlackeris there a nice way to talk to ldap with nim?
11:42:25FromDiscord<mratsim> "dragonvoice" (sorry couldn't resist)
11:43:00Araqhey mratsim
11:43:17Araqhere is an idea I had, it's nothing new
11:43:24Araqbut maybe useful
11:43:41Araqor maybe it's what you've been doing all along aready in Picasso
11:43:46FromDiscord<mratsim> I'm grasping at straws anyway.
11:43:57Araqso ...
11:44:10Araqwe have N threads
11:44:22Araqand we have queue(s)
11:44:28Araqwith work items / tasks
11:45:17Araqnow the threads run tasks, some of which are CPU intensive, some of which are IO intensive
11:45:51Araqlet's say the threads run an O(n^3) matrix operation
11:46:12Araqthey are all busy, nobody can run the incoming IO task
11:46:57Araqso what we can do is inject "yield points" into most/all/some loops
11:47:11Araqfor example
11:47:50FromGitter<alehander92> that's what `go` wanted to do iirc
11:48:49FromGitter<mratsim> Weave has yield points
11:48:50Araq if <cond>: (t = schedule(); t())
11:49:19FromGitter<mratsim> It's called "loadBalance(Weave)" and they are auto injected in parallel for loopa
11:49:22FromGitter<alehander92> but its interesting to see their
11:49:30FromGitter<alehander92> colnclusins as well: https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md
11:49:57Araqand now the trick is that 't' *runs* on the thread's stack as it's just a proc call, no cactus stacks required
11:50:16Araqalehander92: yeah I know it's nothing new
11:50:20FromGitter<alehander92> (e.g. "@dr2chase has put significant effort into prototyping cooperative preemption points in loops, which is one way to solve this problem. However, even sophisticated approaches to this led to unacceptable slow-downs in tight loops (where slow-downs are generally least acceptable").
11:50:22FromGitter<mratsim> See: https://github.com/mratsim/weave/blob/5d9017239ca9792cc37e3995f422f86ac57043ab/weave/parallel_for.nim#L49
11:50:34FromGitter<alehander92> but it still seems as a good idea to me
11:51:14Araqmratsim: ah so you already do that
11:51:24FromGitter<mratsim> Yes no problem for me
11:51:27Araqhowever, we also have control over the compiler technology
11:51:34Araqso we can make the compiler do it
11:51:42Araqin even more loops
11:52:03FromGitter<mratsim> What I have been thinking is having an extra queue for cooperative multithreading
11:52:34FromGitter<mratsim> And I would run the proc in there as a blackbox
11:55:24FromGitter<mratsim> See there: https://github.com/mratsim/weave/issues/68#issuecomment-569410844
11:55:25disbot➥ BLAS matmul vs Laser, Intel MKL, MKL-DNN, OpenBLAS and co ; snippet at 12https://play.nim-lang.org/#ix=25Ub
11:55:48FromGitter<mratsim> @FedericoCeratto also expressed that having a cooperative scheduling queue would be nice
11:56:50FromGitter<mratsim> By the way, I think I have found a killer app for Weave that no open-source multithreading runtime is able to do
11:57:07FromGitter<mratsim> Soft real time scheduling with support for job priorities
11:57:32FromGitter<mratsim> See here: https://github.com/mratsim/weave/issues/88
11:57:32disbot➥ Latency-optimized / job priorities / soft real-time parallel scheduling
11:58:25FromGitter<mratsim> I.e I can add a priority queue to each thread and also change the work-stealing deque from LIFO to FIFO for the best-effort tasks and done
11:59:38FromGitter<mratsim> Tldr: Weave scheduling is very flexible because with message-passing you don't have to deal with concurrency in your scheduling data structures (deque, priority queue)
12:00:19FromGitter<mratsim> Once you solve the (huge) overhead problem of message passing you can do anything
12:01:59FromGitter<mratsim> So that really means that we can have Nim be a killer language for audio/video/game work where we want high-level code with low-level memory management, multithreading and low latency concerns
12:02:16*Hideki_ joined #nim
12:02:31FromGitter<mratsim> (now that I think about it that would make an awesome blog post)
12:02:44FromGitter<mratsim> deterministic memory management*
12:05:27*dddddd joined #nim
12:07:38*Hideki_ quit (Remote host closed the connection)
12:07:51*Hideki_ joined #nim
12:11:56sealmovecan I get these cmd arguments at CT? :3
12:18:59FromGitter<alehander92> https://lucumr.pocoo.org/2020/1/1/async-pressure/
12:19:15FromGitter<alehander92> interesting argument, i never thought about async api for that before
12:22:11*Hideki_ quit (Remote host closed the connection)
12:23:23*Hideki_ joined #nim
12:27:22Araqmratsim: can we make this "hard" realtime?
12:27:25FromDiscord<mratsim> @sealmove? cmd arguments? are you talking about weave?
12:27:52sealmoveno, normal cmd arguments; can I get them at CT somehow?
12:28:04Araqonly in the Nimscript environment
12:28:16*Hideki_ quit (Ping timeout: 268 seconds)
12:28:23dom96alehander92: I believe this shows a bad API design in Python: write should be awaitable and it is in Nim
12:28:35sealmovehmm, this will be my true intro to nimscript then :)
12:28:52FromDiscord<mratsim> I'm not sure, real-time is something I'm completely unfamiliar with. I.e. my memory pool still needs to fetch from the OS
12:29:19FromDiscord<mratsim> it could be adptated to reserve a lot at the beginning but currently you have unpredictable OS delays
12:29:36FromDiscord<mratsim> hard real-time also requires channel to be wait-free
12:29:58FromDiscord<mratsim> right now they are just lockless
12:30:07FromDiscord<mratsim> wait-free is expensive
12:40:44Araqhard realtime doesn't mean "fast" (though fast is still better)
12:40:52Araqit means bounded in time
12:43:46Araqfor example, my TLSF allocator is O(1) if we allocate the heap from the OS upfront, now we need to add a lock around it for the "shared" heap aspect and it's still hard realtime for N threads because in the worst case you have to wait for the N-1 other threads. If we have a "realtime" lock, that is
12:44:37Araqthe usual spinlock should suffice
12:51:18sealmoveis there a convenient proc for concatinating NimNode identifiers?
12:51:47Araqturn them to strings, use & and convert it back into an ident
12:52:00Araqbut it might mean you're really looking for gensym() instead
12:52:33Araqor that you need to work on the tree level, not on the string level
12:52:49sealmoveyes, have to think how to model scope resolution
12:52:53sealmoveaka ::
12:53:10sealmove(transpiling an expression language which includes it)
12:54:16Araqignore what I said, spinlocks are not good enough, apparently
12:54:53Araqyou need "fair" locks
12:58:07*krux02 joined #nim
13:03:33sealmoveif I have an ident NimNode, is it possible to get the type of the identifier?
13:04:59*lritter joined #nim
13:05:01*Hideki_ joined #nim
13:05:23*noonien joined #nim
13:09:08*rockcavera joined #nim
13:12:02FromDiscord<mratsim> no
13:12:15FromDiscord<mratsim> you need a srm NimNode
13:12:18FromDiscord<mratsim> sym*
13:12:53sealmovei see
13:18:24FromDiscord<Fern & Simula (They/Them)> is there a way to get the type/parameters of a proc from inside a macro?
13:20:09FromDiscord<mratsim> is it a proc call or declared proc?
13:20:21FromDiscord<mratsim> (because I have solutions for both but in 2 different repos)
13:21:09FromDiscord<Fern & Simula (They/Them)> declared proc, but it looks like `echo type myproc` is what i want :P
13:21:28FromDiscord<mratsim> oh, you just want to view
13:21:33FromDiscord<Fern & Simula (They/Them)> yeah
13:23:37FromDiscord<mratsim> otherwise I just use macro foo(myProcSymbol: typed) = myProcSymbol.fetImpl.treeRepr
13:23:49FromDiscord<mratsim> treeRepr or toStrLit depending on the view I want
13:23:57FromDiscord<mratsim> getImpl*
13:24:01*Hideki_ quit (Ping timeout: 265 seconds)
13:24:31FromDiscord<Fern & Simula (They/Them)> that'll work nicely in the future, thanks :)
13:25:35FromDiscord<mratsim> if your proc gets overloaded getImpl will give you some nnkClosedSymChoice that you will have to iterate though instead of just a nnkSym
13:25:47FromDiscord<mratsim> see for example: https://github.com/numforge/laser/blob/master/laser/lux_compiler/frontend/lux_sigmatch.nim#L44-L50
13:26:19FromDiscord<mratsim> ah no sorry the "procSymbol" will not be a symbol but a nnkClosedSymChoice
13:26:32FromDiscord<mratsim> so you will need to iterate through it before calling getImpl
13:27:33FromDiscord<mratsim> (the code is a proc signature matcher)
13:28:04FromDiscord<Fern & Simula (They/Them)> huh, is there a reason that matchAST defines inspect as a closure instead of just a regular proc?
13:28:38FromDiscord<mratsim> no reason, most of my macros code is like that
13:29:10FromDiscord<mratsim> i.e. this is mine too 😉 https://github.com/nim-lang/Nim/blob/0944b0f4415a262968cf68f1dbb035cfc3326680/lib/pure/sugar.nim#L146-L159
13:29:34FromDiscord<Fern & Simula (They/Them)> alright, just wondering. i always thought i was a good programmer, but the more i use nim the more i realize how much i have to learn
13:29:45FromDiscord<Fern & Simula (They/Them)> so i like asking questions about weird little details like that :P
13:30:07FromDiscord<mratsim> Nim metaprogramming is unlike anything (maybe jquery / dom manipulation?)
13:31:13FromDiscord<Fern & Simula (They/Them)> it's wild and i love it so much
13:37:24FromGitter<alehander92> @dom96 sorry you re right
13:37:29FromGitter<alehander92> i overlooked it
13:38:14FromGitter<alehander92> but still it seems there are many possible needs for more precise strategies on how to handler timeouts
13:38:34FromDiscord<Skaruts> are converters more than just syntactic sugar for procs?
13:38:38FromGitter<alehander92> as usually always something is there waiting synchronously for a limited timee
13:41:15FromDiscord<mratsim> @Skaruts, converter are done implictly if the argument of procs don't exactly match the expected inputs but a converter for that type to the expected input exist
13:42:11FromDiscord<mratsim> you can do "converter strToInt(foo: string): int = parseInt(foo)" and try echo "10" + "100"
13:42:32FromDiscord<mratsim> welcome to PHP by the way 😉
13:43:36FromDiscord<Skaruts> wouldn't a proc have the exact same effect?
13:43:55FromDiscord<mratsim> yes, but a proc is not called implicitly
13:44:19FromDiscord<mratsim> you have to do strToInt("10") + strToInt("100")
13:44:30FromDiscord<mratsim> with converters, the compiler automatically insert the calls
13:44:37*Hideki_ joined #nim
13:44:56FromDiscord<Skaruts> ah so it's more like a template?
13:45:01FromDiscord<mratsim> my experience in general is that converters create hard to debug bugs because you forget about the implicit conversion
13:45:25FromDiscord<mratsim> in practive it's a proc that is implicitly inserted by the compiler
13:46:03*Hideki_ quit (Remote host closed the connection)
13:46:58*Hideki_ joined #nim
13:47:01*couven92 joined #nim
13:47:20FromDiscord<Skaruts> hmm, now I'm not even sure a converter is what I should be using
13:48:06FromDiscord<Skaruts> I created a proc (with a few overloads) that wraps sfml to allow creating colors from hex strings (among other things)
13:48:35FromDiscord<Skaruts> and now I created a script that is framework agnostic, and implements its own Color type
13:48:49FromDiscord<Skaruts> so I need to convert them to sfml color type
13:49:03FromDiscord<Skaruts> and what I did was this:
13:49:15FromDiscord<Skaruts> 1 sec.....
13:50:28FromDiscord<Skaruts> oh I almost forgot to not post code here...
13:50:52FromDiscord<mratsim> basically the question boils down to "do you want people to always explicitly call a conversion proc" --> use a proc. "Do you want people to be able to pass the color as is and have them transparently converter" --> use a converter
13:51:08FromDiscord<mratsim> converted*
13:51:44FromDiscord<Skaruts> well the convertion will have to be implemeted by the user, I can't predict what framework they'll be using
13:51:53*Hideki_ quit (Ping timeout: 260 seconds)
13:53:04FromDiscord<mratsim> then not your problem, just expose the enum/Color type
13:53:26FromDiscord<Skaruts> basically I have these procs to wrap sfml `proc sf_Color( some args)` and my converter is basically just the same, except it takes a RPColor as argument `converter sf_Color(col:RPColor)`
13:54:07FromDiscord<Skaruts> and it seems like a proc would do the same thing
13:55:13FromDiscord<Skaruts> essentially, I'm not sure I'm fully grasping their actual purpose
13:56:15FromDiscord<mratsim> it's basically if you want to avoid typing a proc and have the compiler do it for you
13:57:11FromDiscord<mratsim> an example would be auto-converting integer to floats. and then something like `/` would accept integers
13:57:19FromDiscord<mratsim> or float to complex
13:58:30FromDiscord<Skaruts> hmm, wait, does this mean that for a proc that takes sfml colors as paramters, the compiler will fetch the converter if I give my type of colors to that proc?
13:58:39FromDiscord<mratsim> yes
13:58:46FromDiscord<Skaruts> ah!
14:01:03FromDiscord<Skaruts> oh it does work
14:01:32FromDiscord<Skaruts> I was invoking the converter since I never realized I didn't have to
14:02:07FromDiscord<Skaruts> thanks
14:12:19sealmovehmm, running nimscript with shebang doesn't allow for command-line argument passing?
14:13:06*gangstacat quit (Quit: Ĝis!)
14:25:07*Hideki_ joined #nim
14:27:27solitudesfit does
14:31:22*Hendriks joined #nim
14:31:30FromDiscord<Fern & Simula (They/Them)> design question for y'all. i'm writing a (toy) static site generator in nim. the main file is just going to be configuration done through a macro. What I'm wondering is, should the entire site generation be done at compile-time, or should i have it just compile a simple binary that does the work at runtime?
14:32:53FromDiscord<mratsim> runtime
14:32:58FromDiscord<mratsim> poor nim compiler
14:33:20FromDiscord<Fern & Simula (They/Them)> that's what i thought, would just be fun to do everything at compile-time and then have a binary that does nothing lmao :P
14:33:50FromDiscord<mratsim> people might want to generate multiple websites as well 😉
14:34:26FromDiscord<Fern & Simula (They/Them)> well, use multiple config files then :P
14:34:43FromDiscord<Fern & Simula (They/Them)> the generator is just a library that uses a macro for a configuration DSL
14:39:41lqdev[m]but... then, you eliminate the barrier between compile and runtime, leading to a point where an executable is no longer useful and you're left with the compiler and the NimVM
14:40:00FromDiscord<Fern & Simula (They/Them)> exactly
14:40:08FromDiscord<Fern & Simula (They/Them)> i didn't say it was a *good* idea
14:43:16*Hendriks quit (Quit: Hendriks)
14:46:31*gangstacat joined #nim
14:47:14*Hideki_ quit (Ping timeout: 240 seconds)
14:57:46*PMunch quit (Quit: Leaving)
15:09:05*ng0_ joined #nim
15:09:05*ng0_ quit (Changing host)
15:09:05*ng0_ joined #nim
15:11:14FromDiscord<Clyybber> I think its a good idea to do it all at compile-time
15:11:27FromDiscord<Clyybber> but then otoh, its totally equivalent to writing a nimscript that does it
15:12:30FromDiscord<Clyybber> probably best to write it in a proc or something, and then if you later want to do it at compile time, call that proc in a `static:` block
15:12:44*ng0 quit (Ping timeout: 268 seconds)
15:13:49*ng0_ is now known as ng0
15:15:30sealmoveWOW
15:15:46*NimBot joined #nim
15:15:59sealmoveawesome 0.0
15:16:41sealmoveand the thing is I just ported a small script that simply runs "nim c file"
15:17:15FromDiscord<Clyybber> lol. but yeah, bash is not exactly fast
15:17:23FromDiscord<Clyybber> dash should be though
15:17:52sealmovebut how did this result in such a speed-up? the heavy lifting is done by a nim executable. bash was just calling it
15:18:19FromDiscord<Clyybber> hmm, dunno
15:20:06FromDiscord<Fern & Simula (They/Them)> `cannot 'importc' variable at compile time` any way around this or am i just screwed?
15:23:20FromDiscord<Fern & Simula (They/Them)> oswalkdir exists, nvm
15:24:14FromDiscord<Clyybber> @Fern & Simula (They/Them) Try ```
15:24:16FromDiscord<Clyybber> nim c --experimental:compiletimeFFI
15:24:16FromDiscord<Clyybber> ```
15:24:23FromDiscord<Fern & Simula (They/Them)> ahh, thank you
15:24:30disruptekhearts and... damn.
15:24:38disruptekcan't remember the rest of it.
15:25:00FromDiscord<Fern & Simula (They/Them)> works perfectly, thanks clyybber!
15:25:06FromDiscord<Clyybber> nice, np
15:25:28FromDiscord<Fern & Simula (They/Them)> lmao nope, nevermind. forgot to save the file before compiling
15:26:33FromDiscord<Clyybber> ugh, ok. I think you need to compile the compiler with -d:nimHasLibFFI to work
15:26:51FromDiscord<Clyybber> @Fern & Simula (They/Them) what are you importc'ing ?
15:27:01FromDiscord<Fern & Simula (They/Them)> i'm importing os
15:27:38FromDiscord<Fern & Simula (They/Them)> which errors at line 980 in lib/pure/os.nim
15:28:37FromDiscord<Fern & Simula (They/Them)> which is `return stat(dir, res) >= 0'i32 and S_ISDIR(res.st_mode)`
15:28:49FromDiscord<Fern & Simula (They/Them)> looks like the issue is with the call to `stat()`
15:31:01FromDiscord<Fern & Simula (They/Them)> i just need to check if a directory exists at compile-time
15:31:12FromDiscord<Clyybber> Ah, I suggest asking shashlick
15:31:19FromDiscord<Fern & Simula (They/Them)> and i don't want to parse `ls` output
15:32:32FromDiscord<Fern & Simula (They/Them)> dirExists works at compile time
15:32:42FromDiscord<Fern & Simula (They/Them)> that *really* needs a documentation update
15:32:50disruptekyou can't walkdir at compile-time due to missing staticCurrentDir.
15:33:02FromDiscord<Fern & Simula (They/Them)> oswalkdir is compile-time
15:33:22sealmoveyou can with oswalkdir yes
15:33:39FromDiscord<Fern & Simula (They/Them)> dirExists and fileExists work at compile-time, despite the documentation saying they're synonyms for existsDir and existsFile
15:33:55disruptekhmm, well i couldn't use it for some reason. i guess i should look at that again.
15:34:37FromDiscord<mratsim> known "bug", one should be deleted
15:34:51FromDiscord<mratsim> well deprecated
15:35:13sealmovedisruptek: oswalkdir.walkDir is different than os.walkDir
15:35:25disruptekyeah, i know.
15:35:47shashlicksealmove: https://github.com/nim-lang/Nim/pull/12950
15:35:49disbot➥ Add getCompileOptionString() to get Nim config at compile time
15:35:56sealmovealso, nobody claimed currentDir() works at CT, but you can still use some other path
15:36:50FromDiscord<mratsim> currentSourcePath works at compiletime
15:37:10disrupteki think the way bump works is that i pass it a proc that i want it to use to get currentDir, and at c-t that can only be a hack to fetch cwd from the env.
15:37:18sealmovebtw what's zah's nickname in irc?
15:37:30disrupteklarry. i know, it's weird.
15:41:02sealmoveah it's already reported: https://github.com/zah/nim.vim/issues/87
15:41:04disbot➥ nim#init executes nimscript on load ; snippet at 12https://play.nim-lang.org/#ix=26cd
15:41:50FromDiscord<Clyybber> sealmove: Just zah, hes from gitter
15:43:21FromDiscord<mratsim> seems like another instance of https://github.com/nim-lang/Nim/issues/12125
15:43:22disbot➥ Prevent nimsuggest from executing staticExec
15:44:27sealmovevery annoying
15:45:33shashlickI worked around that in nimterop
15:45:39FromDiscord<mratsim> basically we need tooling that doesn't execute things with OS sideeffects
15:46:18FromDiscord<mratsim> obviously that would render nimscript useless :p
15:46:59disruptekit's an unpopular opinion, but i think having the manifest in nimscript is nuts.
15:48:05FromGitter<alehander92> sealmove it should be zah
15:48:11FromGitter<alehander92> are you trying to ping him?
15:48:41FromGitter<alehander92> (zah or zachary?)
15:50:23shashlickWhat's the issue you are seeing?
15:55:30sealmoveabout the vim plugin, but nvm, it's already known and reported issue
16:05:15*hzx joined #nim
16:14:38*couven92 quit (Ping timeout: 265 seconds)
16:32:18narimiransealmove: if you're willing to switch to neovim, leorize's nim.nvim kicks ass
16:33:51AraqClyybber: any chance you can help cooldome with the =sink elisions?
16:34:15AraqI'm focussing on the C(++) backend regressions
16:35:46*ng0 quit (Quit: leaving)
16:37:36sealmovenarimiran: I heard asyncomplete has issues
16:37:49narimiransealmove: what kinds of issues?
16:38:28narimiranand from what i understand, you can use other completion plugins if you set them up yourself
16:38:49sealmovei shall try it then
16:40:11narimirani'm asking about issues because i'm using asyncomplete and it works quite alright for me
16:40:24kungtotteSame here, no issues whatsoever.
16:40:41blackbeard420yeah nim.nvim + asynccomplete is <3
16:42:31sealmovesorry I haven't used it. just remembered someone complaining here the other day.
16:42:58sealmovewell, I dislike some things about nim.nvim
16:43:33sealmovethe automatic folds (can they be disabled?)
16:43:33narimiranalready? :D
16:43:36narimiranyep
16:43:44blackbeard420yeah i had to disable those as well
16:43:54sealmovewell I did install it in the past but didn't use it much
16:44:05sealmovethe other thing is the syntax highlighting
16:44:09narimiran:set nofoldenable
16:44:19sealmoveit's too much, i like lighter highlighting
16:44:36kungtotteThat's not the nim plugin, that's your colorscheme?
16:44:46narimiranleorize: maybe two variants of highlighting in the future?
16:44:55sealmoveit's not the colorscheme, it's the plugin
16:45:05disruptekyes, but you configure that.
16:45:18disruptekit's vim configuration, not configuration of the plugin.
16:45:20sealmoveI tried 50 themes, they all look terrible with this plugin
16:45:53narimiranyeah, it feels like nim.nvim goes 'beyond' the colorscheme
16:45:53disrupteki agree it doesn't sound like vim is the right editor for you.
16:46:31FromDiscord<Clyybber> Araq: Sure, I wanted to do them anyways,
16:46:46sealmovedisruptek: why?
16:47:06FromDiscord<Clyybber> I was working on them in my defaultfields branch, but I think I'll extract it out of there
16:47:13disruptek'cause it's kinda predicated on the idea that you are willing to perform a fair amount of customization.
16:47:35disruptekit doesn't sound like you really want to have that kind of relationship with your editor.
16:47:53narimirandisruptek: but to be fair, nim(.nvim) is by default much more colorful than any other language that i've written in vim
16:48:28disruptekit has more comprehensive tagging of syntax, maybe, but it's not the plugin that is responsible for color.
16:49:13sealmovewell, i would have to modify the plugin
16:49:35disruptekno, you'd have to configure the editor.
16:49:37sealmoveyeah, i am not willing to mess with vim script, but that doesn't mean vim is not for me
16:50:12disruptekthis makes my comments italicized: `highlight Comment cterm=italic`
16:50:21disruptekis that too burdensome?
16:50:26lqdev[m]sealmove: have you tried onedark? it looks great with nim.nvim
16:50:33*couven92 joined #nim
16:50:35lqdev[m]all other colorschemes look terrible though :P
16:50:46shashlickmade a mess of my PR with a rebase from devel, have to redo
16:51:02shashlickanyone knows safest way to update branch?
16:51:08lqdev[m]I was so used to ayu from VS Code, but it's too colorful with nim.nvim
16:51:13sealmovelqdev: still way toooo heavy
16:51:21disruptekthis configures foobar"bif": `highlight nimQuote cterm=italic ctermfg=DarkCyan`
16:51:37disruptekshashlick: rebase
16:52:54shashlicki did git rebase and it borked my branch
16:53:06shashlickhttps://github.com/nim-lang/Nim/pull/12950/commits
16:53:07disbot➥ Add getCompileOptionString() to get Nim config at compile time
16:54:15sealmovethis is a good amount of highlighting: https://ibb.co/BLXYFrJ
16:54:55narimiransealmove: and a not good amount of opacity/background :P
16:56:23FromGitter<Varriount> Anyone know why Nim's `goto` exceptions are faster than C++ exceptions, and why C++ doesn't use goto?
16:56:28disruptekshashlick: well, reset it for starters.
16:56:56sealmoveVarriount: I think C++ doesn't use goto because RAII doesn't allow it
16:57:29FromGitter<Varriount> Oh, is it the whole "constructors can't throw exceptions" thing?
16:57:36sealmoveyeah
16:57:38FromGitter<Varriount> (or is that destructors?)
16:57:44sealmovedestructors
16:58:00FromGitter<Varriount> How is Nim different though?
16:58:43sealmoveNim doesn't use RAII idiom
16:59:03sealmoveat least not in the same sense
16:59:25sealmoveconstructor/destructor pairs are ensured by the compiler
16:59:35sealmovewhile in C++ you make both by hand
17:01:44shashlickdisruptek: just created a new branch, pleasures of git
17:02:21disruptekgit is a deep rabbithole, for sure.
17:02:50disrupteki like how gittyup is looking with nim-result.
17:03:33disrupteki want go-like error handling, though. probably will require a macro.
17:03:50*matic joined #nim
17:04:11shashlickhow does it differ from options
17:04:19*matic quit (Client Quit)
17:04:51disruptekyou can use an arbitrary type to pass errors, just as you do success values.
17:04:55*matic joined #nim
17:06:13shashlickokay, i've not used either approach so far
17:06:39shashlickthough i've started putting in lots of comments now 😉
17:07:00disrupteknice, so i might actually be able to hack on nimterop. 😜
17:07:38disruptekresult should probably just be absorbed into stdlib's option module.
17:08:19sealmovedisruptek: you were right, it wasn't too hard to configure nvim to use a different syntax tagging file than the one provided by leorize (I used zah's)
17:08:20disruptekoptions are good, but usually insufficient for me, which means creating more verbose code. not nimish.
17:08:45disrupteksealmove: sweet, welcome to the elite club. 👍
17:09:59sealmovethough a lot of its feature just went to garbage bin
17:30:28Yardanicohttps://github.com/mattgodbolt/compiler-explorer/pull/1753 was merged yesterday and they fixed it today
17:30:28disbot➥ Add support for Nim language
17:30:51Yardanicoand it's already live on godbolt.org
17:31:01narimiranYardanico: THIS. IS. HUGE.
17:31:33Yardanicowell, it's not my PR but yes :P
17:31:45narimiranbut you're the messenger :)
17:36:00FromDiscord<Clyybber> damn nice
17:39:07*JustASlacker quit (Ping timeout: 258 seconds)
17:43:51*JustASlacker joined #nim
17:49:08FromDiscord<Milerius> Yeah
17:49:13FromDiscord<Milerius> My idea :p
17:49:18FromDiscord<Milerius> With Daemon :p
17:52:25FromDiscord<Milerius> It's a good friend of mine that did the pr after I showed him nim Lang ^^
17:54:04*Vladar joined #nim
17:55:19disruptekno sooner do i bless nim-result then it starts producing a codegen bug for me.
18:01:58*marmotini_ quit (Remote host closed the connection)
18:02:33*marmotini_ joined #nim
18:07:23*marmotini_ quit (Ping timeout: 260 seconds)
18:09:29*marmotini_ joined #nim
18:16:38FromGitter<Varriount> What does compiler explorer actual do, other than show the assembly output of a program?
18:16:57Yardanicowell, for languages like Zig it can show both LLVM IR and the assembly itself
18:17:23Yardanicoalso it can highlight which parts of the source code correspond to lines in assembly
18:17:29Yardaniconot for nim though :(
18:17:51Araqbah, why not?
18:17:59Araqoh well, it's useful anyway
18:18:22YardanicoI don't really know why it doesn't work for nim :D
18:18:47Yardanicoalso there's no nim source highlighting on godbolt.org
18:29:11FromDiscord<treeform> godbolt.org yey!
18:30:20*natrys joined #nim
18:32:30*nsf joined #nim
18:32:35*notevil joined #nim
18:38:40*couven92 quit (Ping timeout: 265 seconds)
18:39:22*Hideki_ joined #nim
18:40:40*couven92 joined #nim
18:41:23FromDiscord<treeform>
18:41:23FromDiscord<treeform> https://cdn.discordapp.com/attachments/371759389889003532/662364836268867664/unknown.png
18:41:48FromDiscord<treeform> Wow there is a ton of setup code. Does C/C++ mode strips it out some how?
18:42:57FromDiscord<Clyybber> wdym strip it out? That *is* the output of C/C++ mode
18:43:15FromDiscord<Clyybber> or do you mean C/C++ mode on godbolt?
18:44:08*Hideki_ quit (Ping timeout: 260 seconds)
18:45:57Araqwe made it hard to be optimized away because of our legacy GCs
18:46:13Araqwith ARC we can remove most of it...
18:46:49Araqbut it's only the init code anyway
18:48:36*Trustable quit (Quit: Leaving)
18:50:57FromDiscord<treeform> I mean does godbolt strip out the setup stuff from C code? Or does c code have no setup stuff? I don't think nim should do anything.
18:51:58FromDiscord<treeform> like fortran for example?
18:51:59FromDiscord<treeform>
18:51:59FromDiscord<treeform> https://cdn.discordapp.com/attachments/371759389889003532/662367503724576793/unknown.png
18:52:00FromDiscord<mratsim> godbolt stripcs the .loc and .cfi directives
18:52:06FromDiscord<treeform> does it no have setup stuff?
18:52:13FromDiscord<treeform> does it not have setup stuff?
18:52:39FromDiscord<mratsim> because Nim auto-adds a main function
18:52:45FromDiscord<mratsim> I think it's fine
18:53:21FromDiscord<mratsim> or maybe not
18:53:30FromDiscord<mratsim> trying I don't see the square function name appearing
18:54:46FromDiscord<mratsim> even with {.noinline.}
18:54:58Yardanico{.exportc.}
18:55:02Yardanicowith that you'll see it :P
18:56:16FromDiscord<mratsim> yes the example needs a main function
18:56:23FromDiscord<mratsim> because square is compiled away
18:56:49Yardanicoah right
18:57:22Yardanicobut for example zig example code doesn't have a main function but uses "export" as well
18:57:27Yardanicoso that it appears in the assembly listing
18:58:31FromDiscord<mratsim> this is better: https://godbolt.org/z/EhQ7cz
18:58:57FromDiscord<mratsim> but export is just equivalent to * in Zig no? a public marker?
18:59:03FromDiscord<treeform> Ideally I want to stick a function in and see what that function compiles too... not that it compiles away or main or setup stuff... but its a new thing I am just glad its there.
18:59:27FromDiscord<mratsim> maybe exportc by default is better
18:59:40Yardanico@mratsim nah, export is for exporting for C ABI and stuff like that
18:59:46Yardanicofor * there's `pub`
19:00:24FromDiscord<mratsim> okay
19:00:41FromDiscord<mratsim> and I suppose Zig is stripping their main as well or is there no runtime at all in Zig?
19:01:04Yardanicothere's no runtime in Zig really
19:01:09FromDiscord<mratsim> pretty sure D is stripping a lot of things
19:01:26Yardanicoonly some error checking (if compiled in debug mode)
19:01:37Yardanicowith --release-fast the zig code example is just 4 lines of assembly
19:01:54FromDiscord<mratsim> I think D or Ada are better reference
19:02:04FromDiscord<mratsim> they have a runtime and it seems stripped
19:03:47*MightyJoe joined #nim
19:03:48*cyraxjoe quit (Ping timeout: 265 seconds)
19:04:01FromDiscord<treeform> this is what I would like to see:
19:04:03FromDiscord<treeform>
19:04:03FromDiscord<treeform> https://cdn.discordapp.com/attachments/371759389889003532/662370538991255552/unknown.png
19:04:22FromDiscord<treeform> But I am fine not getting things I want... in fact I am used to it!
19:05:25Yardanicolmao
19:06:09Araqbtw C does have a runtime fwiw
19:06:36Araqand it's stripped out in the asm output
19:06:51Yardanicoah, well, then the Zig does too :P
19:07:03Yardanicoim not sure
19:07:39AraqI finally figured out how to do "exension points"
19:07:43Araq*extension
19:07:50Araqin hindsight it's obvious
19:08:55Araqon the other hand it'll bring us into the lovely land of linker errors
19:12:19FromDiscord<treeform> what is "exension points"? Android and iOS nim dev is all linker errors...
19:13:45*seerix joined #nim
19:14:18FromGitter<Varriount> Yardanico: But does Zig offer GC?
19:15:01Yardanico@Varriount well, it doesn't, all stdlib (or third party) functions/objects which require memory allocation take an allocator argument, and you can create any allocator you want (even the garbage-collecting one AFAIK)
19:15:10*marmotini_ quit (Remote host closed the connection)
19:15:45*marmotini_ joined #nim
19:15:46Yardanicohttps://ziglang.org/#Manual-memory-management
19:16:28YardanicoI don't know Zig very well, I only tried it a bit :)
19:20:02*marmotini_ quit (Ping timeout: 240 seconds)
19:21:00FromGitter<deech> Doesn't D do this as well?
19:21:04*Hideki_ joined #nim
19:24:29Araqno, D is much more like Nim in this regard
19:25:34*Hideki_ quit (Ping timeout: 268 seconds)
19:27:11FromGitter<deech> Oh I guess it's considered experimental: https://dlang.org/phobos/std_experimental_allocator.html
19:28:43FromDiscord<Lantos>
19:28:43FromDiscord<Lantos> https://cdn.discordapp.com/attachments/371759389889003532/662376742765330432/New_Project.png
19:28:47FromDiscord<Lantos> Man I am dumb
19:29:27FromDiscord<Lantos> I did this and then someone has already done it and it was depreciated...
19:29:48FromDiscord<Lantos> google didn't come up with the right search so I thought it was new
19:29:52Araqthere is a proposal to add 'using allocator' to C++
19:29:52FromDiscord<Milerius> @treeform How did you get this output ?
19:30:07*tane joined #nim
19:30:10AraqI abandoned the idea fwiw
19:31:25FromGitter<deech> Araq, yeah doesn't seem like Nim's focus.
19:31:43*endragor quit (Remote host closed the connection)
19:32:23Araqwell with destructors you can write your own "allocator aware" seqs and tables
19:33:57Araqand thus all the focus was put on destructors
19:34:26Araqit's C++'s key feature that brought it its success IMHO
19:34:39FromGitter<deech> Oh that's good to know. Haven't played around with it enough.
19:36:27Araqat the same time it also enables refcounting which I consider the secret behind Python's success for scientific computing
19:37:27Araqso you have this 2000x2000 matrix and perform operations on it. when should it be freed? as soon as possible, don't wait for a tracing GC to clean it up
19:38:59Araqoh and with destructors we can finally use sockets and cannot forget to close() them.
19:39:17Araqit's quite a feature
19:39:37FromDiscord<treeform> @Milerius I edited the screenshot.
19:39:50Araq3 different techniques all enabled by a single feature
19:39:59FromGitter<deech> Yes, I always liked how RAII didn't just focus on memory. Rust has this too with the Drop trait.
19:40:08Araqyeah I know
19:41:28*prometheus joined #nim
19:42:02FromDiscord<treeform> I like ref counting, it is very deterministic... and technically its not garbage collection ...
19:45:17FromDiscord<kodkuce> C++ is using Refcounting RAII right?
19:46:50FromGitter<Varriount> Araq: Why is Nim able to use `goto`'s for exception handling, but C++ is not?
19:47:54AraqVarriount: there is a proposal to do the same for C++
19:48:12FromGitter<Varriount> Yardanico: That's... actually not a bad idea. A bit repetitive, but perhaps there's a way to auto-fill that parameter.
19:48:13AraqC++'s mechanism is faster though
19:48:27FromGitter<Varriount> I thought `goto` was faster?
19:48:35Araqit's faster than setjmp
19:48:44Araqwhich is what we used before for the C target
19:49:19FromGitter<Varriount> Poor `setjmp`, unloved by everyone
19:49:32AraqC++ is "only" faster though if you rarely raise an exception, it's heavily optimized for the optimistic case
19:49:45Araqwhich is fine though.
19:49:49disruptekas it should be.
19:50:04Araqyeah well the jury is still out on that one
19:50:57disruptekthe argument that you wouldn't use exceptions if you didn't expect exceptions is... mind boggling.
19:51:15Araqno, the point is:
19:51:33Araqas a library writer I don't really know how frequent it is that e.g. parseInt fails
19:51:41Araqor openFile
19:52:04disrupteki know, we're a slave to those scenarios.
19:52:27Araqso if I don't know an exception implementation that is not as biased is better
19:52:31disruptekthat's not something to be solved downstream, though, imo.
19:53:01disrupteki'd rather err in favor of those that actually want to design high-performance interfaces.
19:53:23Araqwell with --exceptions:goto we now have a mechanism that is fast and not as biased for the happy case
19:53:33disruptekyeah, it's cool.
19:53:46disruptekany thought on whether nre will be arc'able?
19:54:09Araqit only requires yet another compiler patch afaict
19:54:23disruptekokay, good.
19:54:26AraqI underestimated how popular finalizers are
19:54:29Araq:D
19:54:38disrupteksays the author. 🤣
20:01:40*rockcavera is now known as Guest23228
20:01:41*tiorock joined #nim
20:01:41*Guest23228 quit (Killed (livingstone.freenode.net (Nickname regained by services)))
20:01:41*tiorock is now known as rockcavera
20:05:12*ng0 joined #nim
20:07:38FromDiscord<Clyybber> ugh
20:07:49FromDiscord<Clyybber> does that mean we have to support newFinalize?
20:12:32*jxy joined #nim
20:25:53*endragor joined #nim
20:26:31planetis[m]so in order for a library like nim-lang/cairo to support destructors, how hard can it be? Now it uses ptr Surface, ptr Context, etc what changes need to be made? https://github.com/nim-lang/cairo/blob/master/src/cairo.nim
20:27:23*JustASlacker quit (Ping timeout: 260 seconds)
20:29:55*jjido joined #nim
20:30:53*endragor quit (Ping timeout: 260 seconds)
20:32:30*krux02 quit (Remote host closed the connection)
20:40:37FromDiscord<mratsim> you need to wrap the ptr Foo in an object because only objects can have destructors
20:41:01FromDiscord<mratsim> (and I find it annoying as hell)
20:41:53FromDiscord<mratsim> then you create proc `=destroy`(myObject: MyObject)
20:42:32FromDiscord<mratsim> and you also create proc `=`(dst: var Foo, src: Foo) {.error: "This is a move-only object".}
20:43:33FromDiscord<mratsim> to ensure you don't duplicate your object (otherwise when one is destroyed, the other will try to access a nil pointer)
20:44:07planetis[m]mratsim: thanks
20:46:54*zyklon joined #nim
20:47:06FromDiscord<Fern & Simula (They/Them)> is there a way to check if the code is currently being executed in a static context?
20:47:13FromDiscord<Fern & Simula (They/Them)> lol not even sure if i'm using the right terms
20:47:27disruptekwhen nimvm:
20:47:45FromDiscord<Fern & Simula (They/Them)> ahh, i was checking for nimscript. thanks!
20:48:05FromDiscord<mratsim> note that it's a bit tricky, I never remember if you must or if you cannot have a "else" with when nimvm
20:48:16FromDiscord<Fern & Simula (They/Them)> hmmm, getting "Error: illegal context for 'nimvm' magic"
20:48:28FromDiscord<mratsim> then you must have a else clause 😉
20:48:40FromDiscord<Fern & Simula (They/Them)> i dont lol
20:48:40planetis[m]so its kind of incorrect that the T and P prefixed types were deprecated, because now we need different names in order not to break api? or can I make a Pr that uses ``type Surface = object data: ptr TSurface``
20:48:41disrupteki think you can have else but not elif... you can't have `not nimvm`, maybe.
20:49:19FromDiscord<Fern & Simula (They/Them)> https://play.nim-lang.org/#ix=26ec
20:49:59planetis[m]..and add destructors to Surface
20:50:22FromDiscord<mratsim> https://play.nim-lang.org/#ix=26ed
20:50:39FromDiscord<Fern & Simula (They/Them)> incredible
20:50:45FromDiscord<mratsim> ^ you can open an issue with that
20:51:01FromDiscord<mratsim> it's impossible to find the workaround without dumb luck
20:51:14FromDiscord<Fern & Simula (They/Them)> it's not in documentation anywhere?
20:52:09FromDiscord<mratsim> not sure, I had a couple of nimvm statement, some worked som didn't, I checked the difference, and I though "perhaps ..." "No it can't be ..." "let's make sure ..." "no way ..."
20:52:24FromDiscord<mratsim> and then never raised a bug 😛
20:52:36FromDiscord<Fern & Simula (They/Them)> this causes me pain lmao
20:52:38disruptekyeah, it's a pita.
20:53:11disruptektry not to use nimvm. i have used it only a few times and it's always a head-scratcher.
20:53:23FromDiscord<mratsim> well i'll raise the bug
20:53:52FromDiscord<mratsim> ah no it's there: https://github.com/nim-lang/Nim/issues/12517
20:53:54disbot➥ Error: illegal context for 'nimvm' magic if 'nimvm' is used with single branch 'when' ; snippet at 12https://play.nim-lang.org/#ix=26ee
20:55:41planetis[m]its not only that, prefixed proc names ex: ``cairo_surface_get_content`` need to be imported as is, so that the nimified variants ``getContent `` return these objects
20:56:52planetis[m]will the nim devs accept these changes or make a fork instead?
20:57:46FromDiscord<Fern & Simula (They/Them)> disruptek: i honestly only need it so i can know if i need to call readFile or staticRead
20:59:16FromDiscord<Fern & Simula (They/Them)> oh i don't need to, readFile works in a static block
20:59:39FromDiscord<mratsim> @planetis, I think you should open an issue with your plan.
20:59:39FromDiscord<mratsim> 1. pretty sure no ones maintain Cairo so if someone wants to maintian it because they actually uses it, it's good.
20:59:39FromDiscord<mratsim> 2. so that we can discuss
20:59:39FromDiscord<mratsim> 3. for backward compat we can expose the old and new names unless there are some difficulties I'm missing
21:01:18FromGitter<deech> Is there a reliable way to check if code run at compile time is doing any IO? This includes my NimScript files and all the statically run code in my package and it's dependencies.
21:02:05FromGitter<deech> I could just use `compiler` and check for `staticRead` but that seems pretty brittle in the face of macros and the like.
21:02:54planetis[m]problem is the nimified names are all used for stuff that interfaces with c
21:04:27*couven92 quit (Ping timeout: 240 seconds)
21:06:01FromDiscord<mratsim> @deech, it's a painful issue, see https://github.com/nim-lang/Nim/issues/8219 and https://github.com/nim-lang/Nim/issues/12125
21:06:02disbot➥ Prevent nimsuggest from executing staticExec
21:06:36FromDiscord<mratsim> maybe the proc are properly tagged ReadIOEffect and WriteIOEffect though
21:13:47FromDiscord<treeform> @mratsim I have done tons of work on Cairo recently
21:14:08planetis[m]but we are discussing now aren't we?
21:15:49FromDiscord<mratsim> of course, but assuming there is any decisions, it's better to have it tracked in an issue
21:15:57FromDiscord<treeform> https://github.com/nim-lang/cairo/graphs/contributors
21:15:58FromDiscord<mratsim> and also others might want to chime in
21:16:43FromDiscord<mratsim> I have absolutely zero experience with Cairo but if I was an user and the library changes, I would appreciate a link in the change log "reason given in this issue #foo"
21:17:16FromDiscord<mratsim> i.e. get a feel on IRC and take decision on Github
21:17:23FromDiscord<mratsim> or "enshrine"
21:17:29FromDiscord<mratsim> because sometimes there is consensus
21:18:01FromDiscord<treeform> I want to make a vector lib that can use both Cairo and JS's Canvas as APIs.
21:18:31FromDiscord<treeform> It will probably be close to the JS Canvas API
21:18:45FromDiscord<treeform> Some thing like a JS Canvas to Cairo translation layer...
21:19:51planetis[m]treeform: so what's your opinion?
21:20:04FromDiscord<exelotl> I ended up ditching all the staticExec magic in my project, cause nimsuggest would presumably not run the command, miss all the generated variables, and then vscode would report false errors to me.
21:20:06FromDiscord<treeform> What is your proposal?
21:21:02FromGitter<deech> mratsim: Why not disable these at the compiler level by default and require something like `-d:allowCompileTimeIO`? This would at least address issues in app/lib code but not in Nimble and nims files Matters much less there anyway.
21:22:23planetis[m]i'm writing an issue btw
21:22:49*natrys quit (Quit: natrys)
21:22:51planetis[m]pretty much the above
21:28:18FromDiscord<mratsim> @deech sounds good to me. It's quite annoying that tooling executes anything
21:28:42FromDiscord<mratsim> well more than annoying, dangerous
21:29:51AraqI don't want nimsuggest to staticExec anything
21:30:26Araqand I don't see how pushing it into the config helps it
21:30:49Araqthe config is project specific, we are trying to create an ecosystem of nimble packages that simply work
21:32:00disrupteki still think the compiler should only run nimscript files marked executable.
21:32:17AraqI also don't understand why a single 'nim c foobar' that produces your .nim files before you use nimsuggest is oh so painful
21:32:49Araqit's pretty much how it works everywhere else when makefiles run flex producing a lexer.c file etc
21:32:56disrupteki think it's more painful to do it the other way.
21:35:27disruptekthe problem is, i want to be able to toggle it.
21:35:47Araqrun 'nim c' to "toggle it"
21:35:50shashlickthat's how i fixed nimterop - user is expected to run one nim c which caches the data which is then used in nimsuggest and nim check
21:36:06rayman22201https://github.com/mattgodbolt/compiler-explorer/pull/1762
21:36:06disbot➥ Added Monaco editor syntax highlight support for Nim.
21:36:23disruptekif i don't need it for nimterop, i don't care. 😁
21:36:26Araqrayman22201, any news?
21:36:28rayman22201Happy New year
21:36:37Araqthanks, same to you!
21:36:51rayman22201I'm back! sorry I dropped off for the holidays. Family got busy
21:37:18rayman22201No news on on Async, but it seems like you have been busy with arc
21:37:32Araqsure but I'm also waiting for your insights
21:37:52rayman22201oh? what insights do you need?
21:38:07Araqwhere to put 'x.field = nil' to beak up cycles
21:38:13Araq*break
21:38:14planetis[m]https://github.com/nim-lang/cairo/issues/13
21:38:16disbot➥ Use destructors for automaticaly closing of resources ; snippet at 12https://play.nim-lang.org/#ix=26eu
21:40:06rayman22201essentially, it's after last read of the promise
21:41:30Araqthere is also an easy to solve callback type problem
21:41:44AraqCallbackFunc = proc () {.closure, gcsafe.} -->
21:41:52AraqCallbackFunc = proc (fut: FutureBase) {.closure, gcsafe.}
21:42:06Araqso that we don't encourage closing over the future var which creates the cycle
21:42:59*JustASlacker joined #nim
21:44:04AraqI did this refactoring before and very little broke after it
21:44:49rayman22201I'm worried that it is a big api change
21:46:41Araqif it means we can use without a cycle collector it's very worth the breakage
21:46:48Araq*can use async
21:47:03disruptekto put it mildly.
21:48:55rayman22201I have to test the disposable async with arc. If that works, it will just be a change to how the async macro works, and no api change.
21:49:00rayman22201have our cake and eat it too
21:49:09rayman22201but if it doesn't work out, then yeah, this is an option
21:49:23Araqarc doesn't offer 'dispose'
21:49:30Araqinstead you can set things to nil
21:49:33rayman22201well, same idea
21:49:36Araqyup
21:49:58disruptekugh.
21:50:18Araqwow what a new year, Nim is getting =sink elision, https://github.com/nim-lang/Nim/pull/13002
21:50:19disbot➥ Sink to MemMove optimization in injectdestructors
21:50:37rayman22201the async macro needs to be modified to set the cycle to nil in the right place, which I proved works already in my dispose version.
21:51:07*narimiran quit (Ping timeout: 260 seconds)
21:51:08disruptekwhy can't we have explicit dispose/disarm?
21:51:44Araqdisruptek, well it's the same thing, template dispose(x) = x = nil
21:52:10Araqquite elegant IMHO
21:52:31disrupteki know it's net-net the same, but for the future in which we don't have nil or want to optimize something, maybe we want to know the programmer's intent.
21:53:32Araqah good point
21:53:33disruptekor are you saying `template dispose` is in stdlib?
21:54:01Araqtemplate disarm*(x: typed) =
21:54:01Araq ## Useful for ``disarming`` dangling pointers explicitly for the
21:54:01Araq ## --newruntime. Regardless of whether --newruntime is used or not
21:54:01Araq ## this sets the pointer or callback ``x`` to ``nil``. This is an
21:54:02Araq ## experimental API!
21:54:03Araq x = nil
21:54:08Araqit already exists
21:54:24Araqand for the "not nil" future it seems to be a good idea to embrace it
21:54:36disrupteki guess as a result of my last comment on the subject. 😝
21:54:55Araqwe should update its doc comment though
21:57:17*JustASlacker quit (Ping timeout: 268 seconds)
21:57:23disruptekit should be like three paragraphs of wisdom followed simply by `x = nil`.
21:58:45Araqlooks like you understand Nim very well.
21:59:03AraqNim: the language where documentation comments are longer than implementations.
22:00:02*couven92 joined #nim
22:03:23rayman22201lol. that's a good thing imo :-P
22:03:57FromGitter<Varriount> What is disarm?
22:06:05madpropsI want to do list.sortedByIt(it.path) , but i want it to be case insensitive. Is there a better way than making path toLower ?
22:10:16Araqos.cmpPaths
22:10:53Araqdunno if 'sortedByIt' support that but the ordinary 'sort' does
22:11:10*Vladar quit (Quit: Leaving)
22:16:13Araqer what? there is a processor called "Motorola DragonBall"?!
22:16:23Araqnerds...
22:22:40*hzx quit (Quit: Going offline, see ya! (www.adiirc.com))
22:25:59*narwic joined #nim
22:26:05*narwic left #nim ("WeeChat 2.7")
23:02:12*matic quit (Read error: Connection reset by peer)
23:02:36*endragor joined #nim
23:06:20*solitudesf quit (Ping timeout: 268 seconds)
23:07:14*endragor quit (Ping timeout: 258 seconds)
23:11:19rayman22201does anybody remember the flag to make nim spit out the index file that maps symbol names to source locations?
23:11:34rayman22201for the godbolt thing. I forgot to write it down. damn
23:13:05FromDiscord<mratsim> --debugger:native?
23:13:20FromDiscord<mratsim> or --linedir
23:13:54FromDiscord<mratsim> not sure about the second, I know the first works
23:13:56rayman22201no, there was some way to make nim spit out a json file that had the mappings
23:14:45rayman22201--debugger:native wasn't sufficient for godbolt. That's where I got stuck. Araq showed me some flag that produced a json mapping file, but I don't remember it...
23:15:03rayman22201bah. oh well]
23:15:36FromDiscord<mratsim> maybe sourcemap search would help
23:22:47*Hideki_ joined #nim
23:24:39rayman22201--debuginfo :-)
23:27:38*Hideki_ quit (Ping timeout: 260 seconds)
23:34:50*lritter quit (Ping timeout: 258 seconds)
23:35:32*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:57:17madpropswhat's the biggest project written in nim?
23:58:02shashlickNim?
23:58:15madpropswell apart from nim