<< 28-11-2023 >>

00:04:27FromDiscord<michaelb.eth> In reply to @whisperecean "Does cosmopolitan work nicely": you can look into: https://github.com/Yardanico/cosmonim↵↵it might work great with Nim but I haven’t seen much discussion of it in this discord nor in the forum so ymmv
00:12:16FromDiscord<jviega> Not sure why people seem to be so enthralled by cosmopolitan. Last I checked it requires a linux exe file type handler be added to Linux to run. You're in a better place if you ship a shell script that uudecodes the correct exe for your platform, and in an even better place if you ship a shell script that pulls down the right version for the architecture.
00:25:39FromDiscord<Elegantbeef> Yea it's an odd thing
00:25:45FromDiscord<Elegantbeef> It seems like a cool idea, but it does not work for any GUI programs and you might as well work on cross compiling better like Zig does
00:27:14FromDiscord<Elegantbeef> If clang adopted the Zig cross compilation stuffs, it'd be preferable to using something like cosmo
01:41:14*lucasta quit (Remote host closed the connection)
01:47:28Amun-RaElegantbeef: it turned out that cdecl procs are NIM_CONST
01:47:53Amun-RaI mean let vars of cdecl proc type
01:48:21Amun-Rabut that method works with nimcall ones
01:51:37*averymt_ joined #nim
01:52:59*krux02 quit (Remote host closed the connection)
01:56:43FromDiscord<Elegantbeef> time to get codegendecl out 😛
02:00:16*averymt_ quit (Quit: ZNC - https://znc.in)
02:01:13*averymt joined #nim
02:10:32*rockcavera joined #nim
02:11:03FromDiscord<lanky.lemur> Some days I feel really stupid
02:11:40FromDiscord<lanky.lemur> I'm getting a bunch of these errors in my code: https://media.discordapp.net/attachments/371759389889003532/1178880860016095242/Screen_Shot_2023-11-27_at_8.10.59_PM.png?ex=6577c15b&is=65654c5b&hm=63b199cbda3f27ae6ba94c4d56768b441c38ff37e46a73e2ef00c511f281fa03&
02:12:15FromDiscord<lanky.lemur> https://media.discordapp.net/attachments/371759389889003532/1178881008473481266/message.txt?ex=6577c17e&is=65654c7e&hm=5982a3722074928937acf744bdf04cf35de842b6dea64f9e3847a6ffe980e34e&
02:12:47FromDiscord<lanky.lemur> I just cannot figure out what is causing the issue 😦
02:15:05FromDiscord<Elegantbeef> Looking at the code now but I'm 99% certain you have an unconstrained generic
02:15:34FromDiscord<Elegantbeef> `links` inside of `KanBantree` lacks a generic parameter
02:15:46FromDiscord<lanky.lemur> Ahhh okay
02:15:54FromDiscord<lanky.lemur> But I want it to be able to hold any kind of link
02:16:05FromDiscord<Elegantbeef> Nim generics are compile time only
02:16:47FromDiscord<lanky.lemur> Would I be better off using an enum as one of the fields instead of generics?
02:16:58FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4MF9
02:17:10FromDiscord<lanky.lemur> Oh, that works, too
02:18:16FromDiscord<Elegantbeef> You are likely better to use an object variant
02:18:48FromDiscord<lanky.lemur> Okay, making that change didn't break things further, but I'm still getting the same error
02:19:17FromDiscord<Elegantbeef> Your table should be `links: Table[string, LinkBase]`
02:19:27FromDiscord<lanky.lemur> Yep, I changed that
02:19:35FromDiscord<Elegantbeef> Everywhere you use `Link` should be that
02:19:54*averymt left #nim (Leaving)
02:20:20FromDiscord<lanky.lemur> The only other place that I use Link right now is in the Link constructor
02:20:36FromDiscord<Elegantbeef> It's in `Card`
02:20:37FromDiscord<lanky.lemur> sent a code paste, see https://play.nim-lang.org/#ix=4MFb
02:20:57FromDiscord<Elegantbeef> It's an awful error message but it is what it is 😄
02:21:08FromDiscord<lanky.lemur> Good catch, but that didn't resolve it
02:21:11FromDiscord<Elegantbeef> That error message generally means "You have an incorrect generic type, or type annotation"
02:23:25FromDiscord<lanky.lemur> These are the errors that appear right now https://media.discordapp.net/attachments/371759389889003532/1178883813556895805/Screen_Shot_2023-11-27_at_8.23.09_PM.png?ex=6577c41b&is=65654f1b&hm=807af6cef187b04a9d4ff4f9c0fdd0a8f8235c1b377440bedf4284539d4133ee&
02:24:32FromDiscord<Elegantbeef> I do not see any other usages of Link, nor any uninstantiated generics
02:24:33FromDiscord<Elegantbeef> Assuming you got both the `Link` and `seq[Link]` changed
02:24:33FromDiscord<Elegantbeef> Want to throw your current code here https://play.nim-lang.org/?
02:24:38FromDiscord<Elegantbeef> What the compiler says is always more pertinent 😄
02:25:36FromDiscord<lanky.lemur> https://play.nim-lang.org/#ix=4MFc
02:27:22FromDiscord<Elegantbeef> Oh you have a few `file = string` apparently
02:27:30FromDiscord<Elegantbeef> You should use inheritance to reduce redundant code
02:27:48FromDiscord<Elegantbeef> `file, name, description` can all be shared in a single object
02:30:07FromDiscord<Elegantbeef> You did find a bug "Defaulting a value to a type silently works"
02:30:52FromDiscord<Elegantbeef> image.png https://media.discordapp.net/attachments/371759389889003532/1178885692219207720/image.png?ex=6577c5db&is=656550db&hm=f402885fa8c3f79dd917ae2acb8d7689c6ad1c5d605db195cc8678d46645bf33&
02:30:52FromDiscord<Elegantbeef> The fuck github
02:32:00FromDiscord<lanky.lemur> Okay, I added in a new type `KanbanObj`, which has `file`, `name`, `description`, and `loaded` as fields and all of my other objects inherit from this (I eliminated the `LinkObj` type and had `Link` inherit from it)
02:34:04FromDiscord<Elegantbeef> Nice now you should not have an error, and less redundant code
02:34:18FromDiscord<Elegantbeef> I will say that unless you have super wild `T` values for `Link` I'd suggest using an object variant
02:36:06FromDiscord<lanky.lemur> Can you explain what you mean by that?
02:36:11FromDiscord<Elegantbeef> Unrelated, but I feel like your name is a ubuntu version
02:36:29FromDiscord<Elegantbeef> https://nim-lang.org/docs/tut2.html#object-oriented-programming-object-variants
02:36:48FromDiscord<Elegantbeef> Instead of using generics, you can use a tagged union of all your possible values
02:36:49FromDiscord<lanky.lemur> Okay, cool. So having an enum for the type of Link
02:37:18FromDiscord<lanky.lemur> Link will only ever contain one of my types or string
02:37:49FromDiscord<Elegantbeef> Then in that case a branch for every one of your types + string seems very sensible
02:37:57FromDiscord<Elegantbeef> This ensures that you handle ever case everywhere you use it
02:38:15FromDiscord<Elegantbeef> If you dispatch on it you do `case myLink.kind` and handle every branch, instead of using methods and silently not
02:38:37FromDiscord<Elegantbeef> Plus this is more strongly typed as you explicitly define type branches
02:42:43FromDiscord<Elegantbeef> Oh and amun-ra that issue is only really a problem on windows since `nimcall` is cdecl on linux 😄
02:47:39FromDiscord<lanky.lemur> Okay, thank you so much for your help so far
02:49:00FromDiscord<lanky.lemur> I implemented object variants for Link and adjusted all the other code (including my deprecated way of adding items to a table), but I'm still getting an error about using `string` for `KanbanObj.file`
02:49:32FromDiscord<lanky.lemur> https://play.nim-lang.org/#ix=4MFh
02:51:47FromDiscord<Elegantbeef> You changed it to `file: string`?
02:52:02FromDiscord<lanky.lemur> Yep, line 5
02:52:18FromDiscord<Elegantbeef> Yea you need to use `file: string`
02:52:22FromDiscord<lanky.lemur> ugh
02:52:25FromDiscord<lanky.lemur> so stupid
02:53:56FromDiscord<lanky.lemur> It compiles!!!
02:53:57FromDiscord<lanky.lemur> Thank you
02:54:23FromDiscord<lanky.lemur> It sucks when there's real issues mixed in with stupid issues, like using `=` instead of `:`
02:56:35FromDiscord<Elegantbeef> Yea on the plus side https://github.com/nim-lang/Nim/issues/22996
02:57:19FromDiscord<lanky.lemur> Yeah! It's the compiler's fault, not mine!
02:57:31FromDiscord<Elegantbeef> It is if you remove `ref` it errors
03:13:51*rockcavera quit (Remote host closed the connection)
03:25:07*edr quit (Quit: Leaving)
03:37:13*derpydoo quit (Ping timeout: 260 seconds)
03:39:11NimEventerNew thread by alireza: Creating nimstring using pre-allocated buffer to prevent copy, see https://forum.nim-lang.org/t/10694
04:59:06*redj quit (Ping timeout: 256 seconds)
04:59:35*redj joined #nim
06:03:43*azimut quit (Ping timeout: 240 seconds)
07:35:59*kenran joined #nim
07:36:25FromDiscord<Phil> MSYS2 question because that confuses the hell out of me currently
07:36:41*PMunch joined #nim
07:37:49FromDiscord<Phil> sent a long message, see http://ix.io/4MG1
07:38:19FromDiscord<Elegantbeef> Compiler does matter if you do not prepare for it, but it's likely for static libraries
07:39:11FromDiscord<Phil> So for static linking a lib from gcc is not interoperable with one for clang (as a linux analogy, no idea what ucrt is)
07:39:14FromDiscord<Phil> (edit) "is)" => "is)?"
07:40:02*advesperacit joined #nim
07:40:18FromDiscord<nnsee> ucrt is a c lib
07:40:49FromDiscord<nnsee> you will probably find this illuminating
07:40:53FromDiscord<nnsee> https://www.msys2.org/docs/environments/
07:41:03FromDiscord<ElegantBeef> Answer was made in matrix, but bridge went kapoot
07:41:15FromDiscord<ElegantBeef> https://media.discordapp.net/attachments/371759389889003532/1178963802612584458/image.png?ex=65780e9a&is=6565999a&hm=6063e2a115964bae988dab348527fd8d161cc553825a4712f0ada6f7915b2911&
07:41:37FromDiscord<ElegantBeef> Ah you jumped over there
07:41:46FromDiscord<ElegantBeef> Saving me wasting the precious resource of internet bandwidth
07:41:47FromDiscord<Phil> This does not apply to dynamically loaded libs I take it because I feel like that kind of complexity I'd have noticed
07:41:56FromDiscord<Elegantbeef> By prepare for it I mean properly expose things and not rely on compiler behaviour to expose symbols
07:41:57FromDiscord<Elegantbeef> Correct
07:41:59FromDiscord<Elegantbeef> Static libraries are practically funny object files, which are specific to the compiler
07:42:16FromDiscord<ElegantBeef> Partially right, actual dynamic libraries are fine as they have an exposed ABI
07:42:40FromDiscord<ElegantBeef> We generally agree on this using 'Ctypes' and 'C calling conventions'
07:42:54FromDiscord<ElegantBeef> Sorta standard ABI that should not explode in your face
07:43:26FromDiscord<ElegantBeef> For an ABI to be usable from any other compiler the fields have to have the same offsets, calling conventions have to be the same and more!
07:44:29FromDiscord<Phil> Okay, then next question, why recommend installing static libs to compile owlkettle on windows?↵That basically means you're making a static binary of every owlkettle project, right? Why not use DLLs same as on Linux?
07:44:47FromDiscord<Phil> (edit) "Okay, then next question, why recommend installing static libs to compile owlkettle ... on" added "projects"
07:45:12FromDiscord<ElegantBeef> Cause windows does not ship gtk
07:45:14FromDiscord<ElegantBeef> Linux ships gtk
07:45:26FromDiscord<ElegantBeef> Well "Ships it" is a silly statement for linux
07:45:39FromDiscord<ElegantBeef> But gtk is generally available on 99% of users setups running linux
07:45:53FromDiscord<ElegantBeef> GTK is a big project that's like 40+ mb on windows
07:46:07FromDiscord<ElegantBeef> Shipping what you do not use with every project quickly can add up
07:46:20FromDiscord<Phil> Yeah but isn't the general way of shipping applications providing an installation wizard that installs the application?↵As part of that you could just add said libs to the users DLL direcotires
07:46:23FromDiscord<ElegantBeef> But if you statically link and only include what you use it quickly gets down to a much more managable sub 10MB size
07:46:29FromDiscord<ElegantBeef> Right you can
07:46:37FromDiscord<Phil> Or has the world moved on and windows users are all on static binaries nowadays?
07:46:40FromDiscord<ElegantBeef> But some view that as ugly and a waste of time when static linking would've sufficed
07:46:48FromDiscord<ElegantBeef> I mean windows has always been static binaries in disguise
07:46:55FromDiscord<Phil> TIL
07:46:57FromDiscord<ElegantBeef> They always shit the dlls next to the exe
07:47:01FromDiscord<ElegantBeef> (edit) "shit" => "ship"
07:47:08FromDiscord<ElegantBeef> Like on windows there is 0 regard to DLL reuse
07:48:20FromDiscord<ElegantBeef> Of course it's still dynamic linking but given that you're tying the dlls to the program it's only difference is you can update the dlls or replace them with reimplmentations
07:48:32FromDiscord<ElegantBeef> It defeats the main purpose of size savings that dlls give you
07:49:55FromDiscord<Phil> Actually that's also an interesting questions:↵What are all the differences between e.g. a 100MB statically linked binary vs. 3x 33mb DLLs and a 1mb binary?↵I assume statically linked binaries are slightly faster since static compilation means you can link things together more... well statically.
07:50:08FromDiscord<Phil> (edit) "statically." => "statically and don't need to spend time loading anything."
07:50:15FromDiscord<ElegantBeef> The main difference is no opening dlls and smaller binaries
07:50:24FromDiscord<ElegantBeef> Statically linked binaries only include what's needed
07:50:30FromDiscord<ElegantBeef> If you do not use a procedure it's not there
07:50:40FromDiscord<ElegantBeef> Dynamic libraries ship the kitchen sink, so everything you might ever use is there
07:51:28FromDiscord<ElegantBeef> There should be no implicit overhead to a DLL with the exception that the logic is inlined when using a static library(due to the fact it can actually see the body at link time)
07:52:02FromDiscord<ElegantBeef> There is slight startup time when loading the dll, but barring that it's all just procedures
07:53:17*kenran quit (Remote host closed the connection)
07:53:20FromDiscord<ElegantBeef> Your example of 100mb vs 3 33mb is flawed of course due to the fact it'd only work that way if you used 100% of the dlls
07:53:31FromDiscord<ElegantBeef> Which is possible but is highly unlikely 😛
07:53:51FromDiscord<Elegantbeef> Ping
07:54:00FromDiscord<Phil> Look beef, it's beef!
07:54:07FromDiscord<Elegantbeef> Shit get him boys!
07:54:52FromDiscord<Elegantbeef> Anywho any more questions?!
07:55:25FromDiscord<Phil> Not atm, mostly got curious about this because takemichi made a PR about MSYS2 docs to owlkettle
07:55:40FromDiscord<Phil> And the fact there were separate installation steps for GTK libs was confusing to me
07:55:53FromDiscord<Elegantbeef> I should've just forced you to benchmark the dll vs. static just to not take my word for it
07:55:54FromDiscord<Phil> (edit) "And the fact there were separate installation steps for GTK libs ... was" added "per toolchain"
07:56:29*kenran` joined #nim
07:56:44FromDiscord<Elegantbeef> I'm an uneducated swine, taking my word is a awful idea!
07:57:30FromDiscord<Phil> Wouldn't have happened either way, I'm about to start work
07:57:55FromDiscord<Elegantbeef> "Sorry I need to do very important life altering research"
09:04:06PMunchHmm, interesting. I somehow managed to get a SIGSEGV from a `nimfr_` statement..
09:17:34PMunchHmm, what is nimfr_ actually?
09:31:17FromDiscord<ravinder387> sent a code paste, see https://play.nim-lang.org/#ix=
09:32:05FromDiscord<ravinder387> sent a code paste, see https://play.nim-lang.org/#ix=4MGq
09:37:03FromDiscord<ravinder387> why it didn't write gcc -c
09:37:12FromDiscord<ravinder387> why it avoid gcc -c
09:38:40FromDiscord<ravinder387> sent a code paste, see https://play.nim-lang.org/#ix=4MGt
09:38:54FromDiscord<ravinder387> how to compile this then create object file so that i can link it
09:41:30Amun-Raadd --nomain and point --nimcache to local directory, than compile and link all .c files
09:42:33FromDiscord<ravinder387> sent a code paste, see https://play.nim-lang.org/#ix=
09:43:54FromDiscord<ravinder387> i did.. but I don't able to compile nim generated c and link it
09:44:22FromDiscord<ravinder387> "nim generated c" cache dir
09:47:53Amun-Rawhy not?
11:20:17FromDiscord<Phil> PMunch out there doing his best to break the nim programming language at its core
11:20:29FromDiscord<Phil> Instantiating variables that blow up the stack willy nilly
11:22:43FromDiscord<odexine> More of a limitation of the platform they’re using
11:29:31*azimut joined #nim
11:52:36PMunch@Phil, yeah it turns out I was just blowing the stack by creating an 8Mb variable :P
11:53:15FromDiscord<Phil> I would like to question how you get a single variable the size of 8 MB
11:54:20PMunch`array[32, array[32, tuple[x, y: int, p: set[uint16]]]]`
11:54:23PMunchNot that hard :P
11:54:47PMunchThe set is of course what eats memory there, 8Kb per set
11:55:42Amun-RaPhil: var x: array[8_000_000, byte]
12:44:51PMunchHoly shit, intsets are su much faster than set[uint16] as well!
12:45:24PMunchHad to turn off memoization because they don't have a hash proc, but even without it it's considerably aster!
12:45:42FromDiscord<odexine> perhaps it is expensive to index an array the size of a few kb
12:45:50*PMunch quit (Quit: Leaving)
12:46:04*PMunch joined #nim
13:19:30*cnx quit (Ping timeout: 245 seconds)
13:27:54FromDiscord<pmunch> Probably
13:28:01*cnx joined #nim
13:28:07FromDiscord<pmunch> Doesn't help that I have a couple `for x in mySet` in there as well
13:33:09*xet7 joined #nim
13:46:16*edr joined #nim
13:49:24*kenran` quit (Remote host closed the connection)
13:57:56*derpydoo joined #nim
14:26:00FromDiscord<shourchats> does nim have an any type?
14:27:11FromDiscord<shourchats> hmm
14:31:23FromDiscord<shourchats> also wdym by kinda lol
14:31:29FromDiscord<ravinder387> In reply to @PMunch "https://play.nim-lang.org/#ix=4MHr": it works.. send me another link
14:33:04FromDiscord<shourchats> 💀
14:34:28FromDiscord<odexine> In reply to @shourchats "also wdym by kinda": it probably doesnt work as you would expect
14:34:56FromDiscord<shourchats> hmm
14:35:01FromDiscord<shourchats> ok
14:36:02FromDiscord<shourchats> how is echo defined
14:36:22FromDiscord<shourchats> can i find it's source?
14:36:37FromDiscord<odexine> https://nim-lang.org/docs/system.html#echo%2Cvarargs%5Btyped%2C%5D
14:37:25FromDiscord<ravinder387> do u know any company who provide nim programming consulting?
14:37:31*ox is now known as oz
14:37:38FromDiscord<odexine> no
14:39:56PMunchravinder387, depends on what you need
14:40:27PMunchSome people in the community probably does on a small scale, and the Nim project itself offers support and such
14:40:49FromDiscord<ravinder387> is that true. if language share same feature then iterop become easy. for ex:- nim <--> vlang becoz they both static compiled , gc. than nim <--> C
14:41:23FromDiscord<ravinder387> In reply to @PMunch "<@1014948291806511245>, depends on what": thanks... do u know any people
14:41:51PMunchshourchats, I mean kinda as in you can't have a `var x: any`. It's more of a automatic generic parameter thing than an actual type
14:42:49PMunchravinder387, well yes and no. Both having a GC for example could cause some trouble if the GCs start fighting each other
14:43:12PMunchBut mixing Nim and C is easier than mixing Nim and Haskell I'd imagine
14:43:29PMunchBecause the languages share more similarities
14:43:51PMunchravinder387, try asking in the #jobs channel :)
14:44:05FromDiscord<ravinder387> In reply to @PMunch "But mixing Nim and": haskell is very difficult alone to understand. I can't think to mix it
14:44:28FromDiscord<ravinder387> nim <--> c but easier
14:44:53FromDiscord<shourchats> In reply to @PMunch "<@910186395463725188>, I mean kinda": ah
14:45:11*xet7 quit (Remote host closed the connection)
14:52:04PMunchWell mixing Nim and C is always possible
14:52:16PMunchWhoops, wrong channel
14:54:53FromDiscord<nnsee> but yet still surprisingly relevant to the discussion
14:55:59FromDiscord<shourchats> ha
15:00:32PMunchTrue :P
15:00:43*kenran joined #nim
15:08:30PMunchMost cursed embedded stack: One of these chips: https://www.waveshare.com/luckfox-pico-min.htm running Alpine Linux with only Python installed :P
15:09:12FromDiscord<bostonboston> <:ex_breakbad:772529788631384124>
15:10:09PMunchDamn it.. That was also intended or the embedded channel :P
15:17:58*PMunch quit (Quit: Leaving)
15:24:43FromDiscord<mratsim> In reply to @ravinder387 "do u know any": @_araq provides consulting,↵↵There used to be a get support on the website but I don't remember where
16:01:06FromDiscord<Clonkk> https://nim-lang.org/donate.html↵(@mratsim)
16:01:11FromDiscord<Clonkk> "Commercial support"
16:11:00*jmdaemon quit (Ping timeout: 268 seconds)
16:42:17*kenran quit (Remote host closed the connection)
17:54:02NimEventerNew post on r/nim by cacheson: Launching the 2023 Nim Community Survey, see https://reddit.com/r/nim/comments/18622rf/launching_the_2023_nim_community_survey/
18:03:19*azimut quit (Ping timeout: 240 seconds)
18:07:21*azimut joined #nim
18:12:57*rockcavera joined #nim
18:18:57om3gaHow csources were generated?
18:58:14FromDiscord<nnsee> using nim
18:59:18om3gaWhich came first, the chicken or the egg?
18:59:56FromDiscord<alxhr0> sent a code paste, see https://play.nim-lang.org/#ix=4MJb
19:00:19om3gaI mean, modifying these csources for new os is not the best experience
19:00:40FromDiscord<alxhr0> sent a code paste, see https://play.nim-lang.org/#ix=4MJd
19:00:52FromDiscord<alxhr0> (edit) "https://play.nim-lang.org/#ix=4MJd" => "https://play.nim-lang.org/#ix=4MJe"
19:01:30Amun-Raom3ga: the egg
19:02:49om3gaAmun-Ra, probably I need to see first commits? or code looks there the same?
19:16:14FromDiscord<nervecenter> In reply to @NimEventer "New post on r/nim": Done.
19:35:00FromDiscord<Chronos [She/Her]> Ugh I need the energy for my projects
19:35:30Amun-RaChronos: have you ever tried Red Bull? ;)
19:35:54*xet7 joined #nim
19:40:25FromDiscord<Chronos [She/Her]> Nope, I've had Monster energy drinks though
19:40:29FromDiscord<Chronos [She/Her]> And they make me sleepy
19:40:34FromDiscord<Chronos [She/Her]> Sleepy/calm
19:40:42FromDiscord<Elegantbeef> Cocaine!
19:40:46FromDiscord<Chronos [She/Her]> Not energised or hyper, hyper is my natural state of being
19:40:51FromDiscord<Elegantbeef> You'll have a lot of energy, but probably worse health if you take my joke suggestion.
19:41:01FromDiscord<Chronos [She/Her]> In reply to @Elegantbeef "Cocaine!": I mean some ADHD meds are basically diet meth-
19:47:52FromDiscord<saint.___.> Anyone going to be doing advent of code in nim?
19:48:07FromDiscord<saint.___.> In reply to @chronos.vitaqua "I mean some ADHD": Some ADHD meds are actual meth
19:48:38FromDiscord<saint.___.> desoxyn
20:00:31FromDiscord<JJ> In reply to @saint.___. "Anyone going to be": yeah, a bunch. there's a couple of leaderboards: https://nim-lang.org/blog/2021/11/26/advent-of-nim-2021.html
20:10:01FromDiscord<Chronos [She/Her]> In reply to @saint.___. "Anyone going to be": Perhaps, not sure
20:12:15FromDiscord<Chronos [She/Her]> In reply to @saint.___. "Some ADHD meds are": Not surprised oof
20:20:38FromDiscord<saint.___.> Awesome!
20:21:00FromDiscord<saint.___.> In reply to @omentic "yeah, a bunch. there's": Awesome
20:21:01FromDiscord<saint.___.> (edit) "Awesome" => "Awesome!"
20:31:49FromDiscord<saint.___.> In reply to @Amun-Ra "Chronos: have you ever": Redbull and monster are both great but I quit caffeine, almost a year
20:31:51FromDiscord<saint.___.> Can sleep a lot better
20:32:16FromDiscord<saint.___.> Was never super big into it but just thought I should take an effort to cut it out completely