| 00:13:15 | * | d10n-work quit (Ping timeout: 264 seconds) |
| 00:13:22 | * | dddddd quit (Remote host closed the connection) |
| 00:27:40 | * | oculux quit (Quit: blah) |
| 00:29:16 | * | oculux joined #nim |
| 00:31:10 | * | oculux quit (Client Quit) |
| 00:32:04 | * | oculux joined #nim |
| 00:35:50 | * | jjido quit (Quit: Connection closed for inactivity) |
| 00:38:52 | * | whaletechno joined #nim |
| 00:42:08 | * | whaletechno quit (Client Quit) |
| 00:42:51 | * | whaletechno joined #nim |
| 00:44:14 | * | d10n-work joined #nim |
| 00:59:05 | * | mosORadi joined #nim |
| 01:11:57 | * | abm joined #nim |
| 01:12:07 | * | oculux quit (Quit: blah) |
| 01:12:27 | * | oculux joined #nim |
| 01:21:25 | * | Tyresc quit (Quit: WeeChat 2.5-dev) |
| 01:34:24 | * | ng0_ joined #nim |
| 01:37:45 | * | ng0 quit (Ping timeout: 256 seconds) |
| 01:39:39 | * | vlad1777d joined #nim |
| 01:39:54 | * | abm quit (Ping timeout: 255 seconds) |
| 01:44:07 | * | whaletechno quit (Quit: ha det bra) |
| 02:06:07 | * | rnrwashere joined #nim |
| 02:07:03 | * | banc quit (Quit: Bye) |
| 02:17:49 | * | Sonderblade joined #nim |
| 02:29:17 | * | banc joined #nim |
| 02:46:39 | * | seni quit (Quit: Leaving) |
| 03:27:24 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 03:35:32 | * | rnrwashere quit (Remote host closed the connection) |
| 03:38:49 | * | mosORadi quit (Quit: Connection closed for inactivity) |
| 03:39:59 | * | rnrwashere joined #nim |
| 03:40:59 | * | rnrwashere quit (Remote host closed the connection) |
| 03:41:12 | * | rnrwashere joined #nim |
| 04:01:48 | * | rnrwashere quit (Remote host closed the connection) |
| 04:05:09 | * | rnrwashere joined #nim |
| 04:42:59 | * | rnrwashere quit (Remote host closed the connection) |
| 04:50:43 | FromGitter | <Varriount> ryukoposting: Well, if you can't use nimcrypto or that other lib (I forget the name) that the signing code depends on, you can try modifying it to suit your needs. The biggest challenge in that case would be finding an alternative library that allows iterative construction of digests and hashes |
| 04:52:03 | FromGitter | <Varriount> Although, if I had concerns about dependencies and versions, I would probably just vendorize the requirements. It's not too hard to do. |
| 04:59:45 | * | dddddd joined #nim |
| 05:11:32 | I_Right_I | Is this the correct way to allocate a string to shared memory? --> var readBuf: string = cast[string](allocShared0(sizeof(char)*listener.readSize)) |
| 05:13:59 | I_Right_I | or var readBuf: string = cast[string](allocShared0(sizeof(readBufSize)) |
| 05:15:15 | I_Right_I | then --> deallocShared(addr readBuf) |
| 05:31:58 | Araq | I_Right_I: no, the compiler doesn't understand shared "string" |
| 05:39:47 | * | ptdel quit (Ping timeout: 240 seconds) |
| 05:40:27 | I_Right_I | Araq: Okay thanks |
| 05:47:45 | shashlick | @Araq, @dom96 - good amount done in https://github.com/genotrance/nimble/commits/nocompiler but still need to fix stuff, if you want to take a look - i've added nimscriptwrapper.nim to supplant nimscriptsupport.nim |
| 06:05:15 | * | lrz_phone joined #nim |
| 06:07:11 | lrz_phone | Araq: I've tested with the latest commits from devel and koch is still not compiling with newruntime |
| 06:10:10 | * | lrz_phone quit (Remote host closed the connection) |
| 06:13:09 | * | lrz_phone joined #nim |
| 06:13:24 | * | lrz_phone quit (Remote host closed the connection) |
| 06:14:42 | * | lrz_phone joined #nim |
| 06:15:05 | lrz_phone | Araq: http://ix.io/1G39 <- the stacktrace in case it helps |
| 06:15:20 | * | rnrwashere joined #nim |
| 06:19:48 | * | rnrwashere quit (Ping timeout: 252 seconds) |
| 06:21:24 | * | lrz_phone quit (Remote host closed the connection) |
| 06:28:57 | * | xylef joined #nim |
| 06:28:59 | * | narimiran joined #nim |
| 06:29:34 | * | solitudesf joined #nim |
| 06:32:32 | * | xylef quit (Client Quit) |
| 06:33:27 | * | xylef joined #nim |
| 06:37:45 | FromGitter | <bluenote10> @shashlick I saw the discussion on making .nimble properly compiled with "nim c ..." and I really like the idea. I often run into problems writing Nimble tasks related to VM (missing functionality or just bugs like you cannot use toSeq or so). A full compilation would avoid all these limitations. |
| 06:40:14 | * | I_Right_I quit (Remote host closed the connection) |
| 06:41:05 | * | ng0_ is now known as ng0 |
| 06:44:06 | * | disruptek quit (Ping timeout: 255 seconds) |
| 06:46:24 | * | disruptek joined #nim |
| 06:47:46 | FromGitter | <bluenote10> Another nimble question: Is it possible to rename a package that is already published? If I just edit the nimble file and `nimble publish` again, will the old entry be deleted? |
| 06:48:19 | narimiran | you need to create an alias |
| 06:49:27 | narimiran | search for 'alias' in packages.json to see how to do it |
| 06:52:06 | FromGitter | <alehander42> heh i was just writing an "alias a method" template |
| 06:52:10 | FromGitter | <alehander42> offtopic tho |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:04:27 | * | gmpreussner joined #nim |
| 07:16:28 | * | chickendan joined #nim |
| 07:16:32 | FromGitter | <bluenote10> @narimiran I see, thanks! I assume I create the dummy/alias entry for the old name and the real entry is the new one. But this cannot be done via CLI, manual PR required, right? |
| 07:17:00 | narimiran | yes, i think manual is the way to go |
| 07:43:57 | * | enigmeta quit (Ping timeout: 252 seconds) |
| 07:44:17 | * | enigmeta joined #nim |
| 07:55:34 | * | Sonderblade quit (Read error: No route to host) |
| 08:12:39 | * | solitudesf quit (Ping timeout: 264 seconds) |
| 08:21:56 | * | xylef quit (Quit: WeeChat 2.4) |
| 08:27:38 | * | Vladar joined #nim |
| 08:30:53 | FromGitter | <bluenote10> @narimiran Regarding my PR https://github.com/nim-lang/Nim/pull/10967: I think we should fix that inconsistency that `exec("exit 1")` throws an exception (as desired, because the process fails) whereas the overload `exec("exit 1", "", "")` silently swallows the failing process. It's a breaking change, but I don't think it was intended that the overloads behave so differently. What's you opinion? |
| 08:32:43 | * | kapil____ joined #nim |
| 08:40:27 | * | cyraxjoe quit (Ping timeout: 245 seconds) |
| 08:48:03 | * | cyraxjoe joined #nim |
| 08:51:09 | * | uvegbot quit (Quit: Konversation terminated!) |
| 08:51:24 | * | uvegbot joined #nim |
| 08:52:33 | * | Trustable joined #nim |
| 09:12:23 | * | nsf joined #nim |
| 10:06:58 | * | believer joined #nim |
| 10:12:32 | believer | is the syntax: |
| 10:12:33 | believer | Event* = ref EventObj |
| 10:12:34 | believer | EventObj {. importc .} = object of RootObj |
| 10:13:11 | believer | (used in dom module) legacy? or it has a reason |
| 10:29:16 | * | al_ joined #nim |
| 10:32:13 | leorize | I don't know how they are translated to JS, but afaik those aren't legacy in Nim |
| 10:35:47 | believer | i mean the syntax |
| 10:36:15 | believer | why it not just: Event {.importc.} = ref object of RootObj |
| 10:36:31 | believer | *it's |
| 10:42:19 | believer | anyway.. shouldn't the this module be autogenerated from WebIDL https://heycam.github.io/webidl/ |
| 10:42:53 | believer | or it was written by hand? plz tell me what you think |
| 10:45:41 | * | xylef joined #nim |
| 10:45:48 | * | shomodj joined #nim |
| 10:45:49 | believer | also what about using integers in CanvasContext2d.moveTo, etc. Is it good thinking? or make them floats? |
| 10:46:10 | believer | gtg later |
| 11:10:02 | dom96 | it's legacy |
| 11:10:15 | dom96 | and yes, it would be nice to auto generate it |
| 11:14:45 | * | Snircle joined #nim |
| 11:15:14 | dom96 | DOM was definitely written before Web IDL was even imagined |
| 11:16:24 | * | rnrwashere joined #nim |
| 11:20:27 | * | rnrwashere quit (Ping timeout: 240 seconds) |
| 11:42:35 | * | luis_ joined #nim |
| 11:51:15 | * | Vladar quit (Remote host closed the connection) |
| 11:53:27 | * | luis_ quit (Ping timeout: 264 seconds) |
| 12:06:41 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 12:22:25 | FromGitter | <liquid600pgm> Araq: I was reading through your owned refs RFC the other day, and I have a question – will owned refs completely replace `ref`? |
| 12:24:08 | * | vlad1777d quit (Remote host closed the connection) |
| 12:26:38 | * | vlad1777d joined #nim |
| 12:28:01 | * | luis_ joined #nim |
| 12:30:42 | luis_ | Hi all, what is the recommended REPL for nim? nim secret or nrpl from https://github.com/vegansk/nrpl? |
| 12:38:27 | * | luis_ quit (Ping timeout: 240 seconds) |
| 12:48:50 | FromGitter | <alehander42> I remember inim |
| 12:49:03 | FromGitter | <alehander42> And eventually we should have a new one based on her |
| 12:49:26 | FromGitter | <alehander42> Btw someody knows if Victor's Nim talk is going to be |
| 12:49:32 | FromGitter | <alehander42> Online ? |
| 12:56:45 | believer | dom96: I will close my PR, since it wasn't well received |
| 12:56:59 | believer | but I will make an issue with a suggestion |
| 12:59:45 | * | abm joined #nim |
| 13:05:55 | believer | take a look: https://github.com/nim-lang/Nim/issues/11021 |
| 13:06:19 | * | Minimisthupper joined #nim |
| 13:06:26 | Minimisthupper | Hey |
| 13:12:00 | * | believer quit (Quit: Konversation terminated!) |
| 13:19:02 | * | vlad1777d quit (Ping timeout: 246 seconds) |
| 13:23:42 | * | natrys joined #nim |
| 13:25:48 | dom96 | hello Minimisthupper |
| 13:26:43 | * | a_chou joined #nim |
| 13:33:18 | FromGitter | <Minimisthupper> How are you? :D |
| 13:33:41 | * | a_chou quit (Quit: a_chou) |
| 13:36:22 | dom96 | good, you? :) |
| 13:39:54 | FromGitter | <Minimisthupper> I'm fine too :D thanks for asking |
| 13:45:32 | * | Minimisthupper quit (Quit: Konversation terminated!) |
| 13:47:26 | * | stefanos82 joined #nim |
| 13:51:27 | FromGitter | <alehander42> There was this one guy writing something like rails in Nim half an year ago in gitter |
| 13:51:55 | FromGitter | <alehander42> Does somebody remember the project getting a release or his exact nick |
| 13:52:05 | FromGitter | <alehander42> Something like yyy...stuff |
| 13:52:23 | dom96 | if it did you'd probably have heard about it :) |
| 13:55:13 | * | Trustable quit (Remote host closed the connection) |
| 14:14:44 | * | Trustable joined #nim |
| 14:46:54 | * | jjido joined #nim |
| 14:50:45 | * | abm quit (Ping timeout: 252 seconds) |
| 14:51:52 | * | solitudesf joined #nim |
| 15:02:04 | FromGitter | <kayabaNerve> Can you pipe the replace filter? |
| 15:02:27 | FromGitter | <kayabaNerve> I have a piece of code that isn't working, and that would explain why, and I feel like there was a discussion forever ago about how you can't. |
| 15:06:23 | * | abm joined #nim |
| 15:15:02 | * | rnrwashere joined #nim |
| 15:18:21 | * | abm quit (Remote host closed the connection) |
| 15:18:48 | * | abm joined #nim |
| 15:23:19 | * | abm quit (Ping timeout: 264 seconds) |
| 15:23:57 | * | abm joined #nim |
| 15:26:21 | * | rnrwashere quit (Remote host closed the connection) |
| 15:27:00 | * | rnrwashere joined #nim |
| 15:28:51 | * | abm quit (Remote host closed the connection) |
| 15:29:17 | * | abm joined #nim |
| 15:31:33 | WilhelmVonWeiner | does anyone in here use nixos? |
| 15:31:51 | * | rnrwashere quit (Ping timeout: 264 seconds) |
| 15:32:12 | ryukoposting | I think someone uses guix |
| 15:32:44 | WilhelmVonWeiner | not the same - Nix does this crazy sandboxing thing I don't think guix does |
| 15:33:19 | ryukoposting | hmm, neat |
| 15:33:23 | WilhelmVonWeiner | Nim has a weird way with libraries and so I can't find libSDL2.so when running a binary that requires it |
| 15:33:35 | WilhelmVonWeiner | maybe I'll have to reinstall Void |
| 15:34:08 | ryukoposting | I tried void, never figured out the appeal honestly |
| 15:34:24 | ng0 | reminds me.. i should wrap up a patch with the fixed Nim I have for Guix for about a year now.. |
| 15:34:43 | WilhelmVonWeiner | simple init, simple package manager that's hard to f up, simple defaults - simple life |
| 15:34:47 | ng0 | it's kinda not-working last time I checked in in guix master.. which was a very long time ago |
| 15:36:55 | ryukoposting | bah, the very first thing I did with xbps (or whatever it's called) it promptly blew up xfce |
| 15:37:13 | ryukoposting | I haven't used it since, maybe it was a fluke or maybe it got better |
| 15:37:48 | ryukoposting | either way I've been very happy with devuan ascii, though I might start migrating to debian testing soon |
| 15:39:09 | WilhelmVonWeiner | not a fan of debian |
| 15:39:18 | WilhelmVonWeiner | everything seems slightly different but for no reason |
| 15:39:58 | ryukoposting | idk, I have 4 systems that run pretty much identically for day-to-day use despite having wildly disparate hardware |
| 15:40:40 | ryukoposting | even if it's different from other distros, it's very easy to make debian/devuan behave consistently across different machines |
| 15:40:58 | WilhelmVonWeiner | I find the same for void |
| 15:41:17 | leorize | if you have the skill, it's the same for every distro :p |
| 15:42:03 | ryukoposting | leorize I've never been much of a distro hopper, I tried some stuff when I built my new PC but other than that, I basically moved from ubuntu to debian and stayed |
| 15:42:21 | WilhelmVonWeiner | I use OpenBSD now anyway - the only reason I have a nixos (soon to be void again) machine is because I can't be arsed to become the maintainer for >nim=0.16.0 |
| 15:42:41 | ryukoposting | my concern with moving to one of the more niche distros is that I'm gonna lose software support |
| 15:42:54 | leorize | arch used to be a niche one |
| 15:43:05 | ryukoposting | arch is the epitome of a toy distro |
| 15:43:22 | ryukoposting | actually no, that award goes to gentoo |
| 15:43:31 | leorize | although with flatpak your base distro wouldn't matter that much anymore |
| 15:43:39 | ryukoposting | pacman is kinda nice, I use it on my windows machines in MSYS2 |
| 15:44:01 | WilhelmVonWeiner | gentoo isn't a toy distro |
| 15:44:04 | leorize | I love pacman, but my need for multiple versions dragged me to gentoo |
| 15:44:29 | ryukoposting | WilhelmVonWeiner the overwhelming majority of people who use gentoo for a normal, everyday use system, use it as a toy distro |
| 15:44:35 | ryukoposting | it has use cases, don't get me wrong |
| 15:44:43 | leorize | although I think we should move to #nim-offtopic |
| 15:44:44 | WilhelmVonWeiner | I honestly don't think so |
| 15:45:47 | ryukoposting | the problem for me when moving to a "weird" distro would be that I lean on some packages that I might not necessarily be able to get on other distros |
| 15:45:59 | WilhelmVonWeiner | I suppose it is offtopic but my crippling OCD keeps me out of more than 10 channels so I'll close on that, later |
| 15:46:11 | ryukoposting | stuff like the Xilinx FPGA suite |
| 15:46:17 | ryukoposting | but yeah, so nim |
| 15:46:44 | ryukoposting | is nim in the debian repos yet? I just use choosenim for it |
| 15:47:06 | leorize | federico3 maintains debian packages for nim iirc |
| 15:47:12 | ryukoposting | nice |
| 15:47:33 | ryukoposting | I just don't want to see us go down the rabbit hole of widespread distro support lmao |
| 15:48:17 | leorize | nim is pretty easy to package already, so that shouldn't be a problem |
| 15:48:47 | ryukoposting | that's not the problem |
| 15:49:38 | ryukoposting | the dozens of disparate and sometimes ill-defined packaging standards for every distro is the problem |
| 15:50:58 | ryukoposting | the best way to solve that problem is what Nim does now imo, which is package for the big distros, and have the users of weird distros figure it out themselve |
| 15:51:01 | Calinou | that's why choosenim is love, choosenim is life |
| 15:51:01 | ryukoposting | s |
| 15:51:08 | leorize | Nim support on different distros has always been volunteer work I believe, so those standard are easily tackled by people who use those distros themselves |
| 15:51:08 | ryukoposting | exactly Calinou |
| 15:51:11 | Calinou | likewise, rustup for Rust, gimme for Go, … |
| 15:51:36 | Calinou | building Nim from source is quite easy too |
| 15:51:47 | ryukoposting | rustup always seemed really finicky, though I was using it pretty shortly after its release |
| 15:52:01 | Calinou | it works well, except that some packages aren't always available in `nightly` due to failing builds |
| 15:52:08 | ryukoposting | back when rust still recommended piping the output of curl directly into sh in order to download rust |
| 15:52:09 | Calinou | ("components", I should say, actually) |
| 15:52:25 | Calinou | that's still the case if you install rustup, but other installation methods are offered |
| 15:52:34 | Calinou | see https://rustup.rs/ |
| 15:52:37 | ryukoposting | wait they still do that?\ |
| 15:52:52 | leorize | even we do that with choosenim iirc |
| 15:53:15 | Calinou | yeah, it's not much of an issue. The only real improvement is downloading to a temporary file and running it; this avoids a piping detection attack |
| 15:53:25 | Calinou | (where an attacker would send different content depending on whether you are piping or downloading the file to disk) |
| 15:54:09 | * | rnrwashere joined #nim |
| 15:54:16 | Calinou | like this: tmp=$(mktemp) && curl <URL> -fsSLo $tmp && bash $tmp && rm $tmp |
| 15:54:20 | Calinou | (that's a Bash one-liner) |
| 15:54:35 | Calinou | oh, you'll need to chmod +x too |
| 15:54:42 | Calinou | so add a chmod +x before the bash command :) |
| 15:54:50 | leorize | not reading the downloaded script is no different to piping :p |
| 15:55:01 | Calinou | it's only about avoiding the piping content attack |
| 15:55:26 | Calinou | also, wait, I realized you don't need to chmod +x the file if you run it with "bash" explicitly |
| 15:55:49 | * | rnrwashere quit (Client Quit) |
| 15:56:44 | * | rnrwashere joined #nim |
| 15:57:12 | disruptek | what is this "piping content attack" of which you speak? |
| 15:57:41 | Calinou | "(where an attacker would send different content depending on whether you are piping or downloading the file to disk)" |
| 15:57:52 | * | natrys quit (Quit: natrys) |
| 15:57:58 | Calinou | so they can send a malicious script if you pipe it, but an innocent-looking script if you save it to disk using curl or a Web browser |
| 15:58:08 | disruptek | and how would the attack know what you're doing with the content? |
| 15:58:11 | * | rnrwashere quit (Client Quit) |
| 15:58:17 | leorize | https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ |
| 15:58:21 | Calinou | piping can be detected because the request flow goes at a different speed |
| 15:58:25 | Calinou | something along those lines |
| 15:58:39 | disruptek | you mean, buffering? |
| 15:58:47 | Calinou | granted, well-reputed websites like github.com is unlikely to do it, but better safe than sorry :P |
| 16:01:09 | dom96 | lol, piping curl into bash ain't that scary |
| 16:01:17 | dom96 | we're not killing kittens here |
| 16:01:36 | disruptek | bummer. if there's one thing i hate, it's kittens. |
| 16:02:23 | leorize | in a way, we should also be careful when installing any nimble packages |
| 16:03:04 | Calinou | most package managers allow running pre/post-install scripts |
| 16:03:10 | leorize | since nimble files are nimscript and can contain stuff like `rmDir(getEnv("HOME"))` |
| 16:03:14 | disruptek | that's the case for any package management, but the canary is tricky in nim because there is so much ace in the compiler. |
| 16:03:16 | Calinou | .deb/.rpm packages are the worst offenders here, since they run as root :) |
| 16:03:43 | leorize | shouldn't be a problem if you trust your distro maintainers |
| 16:04:38 | disruptek | still talking about nimble, here. |
| 16:05:26 | disruptek | point is, even without nimble, nim can run a lot of code with side effects during compilation. |
| 16:05:28 | * | nsf quit (Quit: WeeChat 2.4) |
| 16:05:37 | * | rnrwashere joined #nim |
| 16:06:09 | dom96 | indeed |
| 16:06:48 | dom96 | AFAIK all package managers are susceptible to this |
| 16:07:05 | dom96 | Surprisingly it doesn't seem to happen? |
| 16:07:32 | leorize | as far as user generated content go, it does happen |
| 16:07:53 | dom96 | or maybe Nimble really is the only package manager crazy enough to allow arbitrary code to run during installation of packages |
| 16:08:07 | disruptek | not about package management. how hard is it to write some C that, during compilation, does something very bad to your environment? how imagine the same attack in Nim. |
| 16:08:17 | leorize | on AUR sometime ago there was someone taking over some orphaned packages and inject malicious code into it |
| 16:09:10 | leorize | you could bury a `staticExec("rm -rf ~/")` in your 10k LoC module and no one would figure it out |
| 16:09:14 | dom96 | disruptek, sure, you don't even need to mess with the C pre-processor. Most C programs are compiled via make which can run anything |
| 16:09:41 | disruptek | not talking about make, either. i'm talking about the compiler. |
| 16:09:43 | ryukoposting | nim might have that concern to a greater degree than other languages solely because of nimvm, but realistically nimvm is limited in ways that would make it difficult to exploit |
| 16:10:08 | dom96 | ryukoposting, how so? You've got execCmd which lets you do anything |
| 16:10:19 | disruptek | the Nim source is an atomic unit that we're comparing to C for the purposes of measuring an attack vector. |
| 16:10:24 | leorize | staticExec + bash and limits just fly away |
| 16:10:43 | ryukoposting | in order for execCmd to do something truly unsafe you'd hopefully have to be running the compiler as root |
| 16:11:08 | disruptek | i value my user environment. |
| 16:11:19 | leorize | copying your gpg secrets are easy without root ;) |
| 16:11:25 | disruptek | maybe that makes me paranoid? |
| 16:11:29 | FromGitter | <Minimisthupper> @dom96 I'm currently reading nim-in-action. Can I ask you here when i have questions? :D |
| 16:11:43 | ryukoposting | fair enough leorize |
| 16:12:24 | leorize | Minimisthupper: you can ask anyone here :) |
| 16:12:25 | ryukoposting | though you could just as easily stick something in at the top of __init__.py and not have to fight with a limited compile-time environment |
| 16:12:27 | * | abm quit (Ping timeout: 240 seconds) |
| 16:13:27 | leorize | never know how python folks solved that (or if they even try) :p |
| 16:13:53 | dom96 | Minimisthupper: ask the channel, others will likely know the answer too and I'm not always around |
| 16:14:24 | ryukoposting | I think the python way of solving that was to kinda just sweep it under the rug until someone actually exploits it |
| 16:15:54 | FromGitter | <Minimisthupper> @dom96 @leorize I will do it ;) |
| 16:16:32 | federico3 | leorize: I do the packaging for Debian and derivatives |
| 16:19:18 | leorize | ryukoposting: I'm pretty sure that's how everyone is doing it |
| 16:19:51 | ryukoposting | I think that risk is kind of just inherent in scripting languages/whatever you'd call nimvm |
| 16:20:00 | leorize | only if openbsd model of pledge and unveil catched on other operating systems |
| 16:20:22 | ryukoposting | and if you're not running stuff as root, then it's fine |
| 16:21:07 | * | hoijui joined #nim |
| 16:22:58 | disruptek | the whole root/user distinction is meaningless these days. it's more about whether you run code in environments that you value or not, since everything is containerized. |
| 16:23:31 | disruptek | ^ for people that care, that is. |
| 16:25:31 | disruptek | i guess the canary can just look at the ast and refuse to compile if staticExec is detected. |
| 16:26:36 | leorize | that can easily be walked around with some clever macros |
| 16:29:48 | FromGitter | <Minimisthupper> Can I import variables from other files ? (I don't want to import the whole file) |
| 16:30:15 | leorize | import keeps only what's used, so you don't have to worry about that :) |
| 16:30:59 | FromGitter | <Minimisthupper> Okay I will try it :D |
| 16:31:10 | leorize | that said, if you only wanted to import a subset, use `from <module> import proc1, var2, something` |
| 16:32:11 | leorize | useful when a lot of namespace collision is happening |
| 16:32:46 | disruptek | leorize: hmm, you're right. |
| 16:33:12 | FromGitter | <Minimisthupper> @leorize Thanks :D |
| 16:34:39 | disruptek | maybe a compiler plugin or a cli switch to enable safe mode. |
| 16:37:21 | FromGitter | <Minimisthupper> (https://files.gitter.im/nim-lang/Nim/NTQo/image.png) |
| 16:37:56 | federico3 | leorize: seccomp is the closest approximation |
| 16:38:23 | leorize | seccomp is a beast unfortunately :/ |
| 16:38:37 | FromGitter | <Minimisthupper> tried this but the compiler said i have to turn on threads option and when i do that it runs the client file ? @leorize |
| 16:39:15 | leorize | what are you making? |
| 16:40:16 | FromGitter | <Minimisthupper> tried to get the username variable from the client to the server |
| 16:41:57 | shashlick | @bluenote10: I am working on removing the embedded compiler from nimble, will move to nim e as a first step. We can always evaluate if we want to compile as next step. |
| 16:42:27 | shashlick | Considering this conversation though, seems like it's even more dangerous |
| 16:43:25 | * | Minimisthupper joined #nim |
| 16:44:22 | leorize | Minimisthupper: it'd be nice to have a little more context |
| 16:44:59 | * | luis_ joined #nim |
| 16:46:13 | luis_ | Lost connection last time, my question again: Hi all, what is the recommended REPL for nim? nim secret or nrpl from https://github.com/vegansk/nrpl? |
| 16:48:51 | * | druonysus quit (*.net *.split) |
| 16:48:51 | * | masterdonx quit (*.net *.split) |
| 16:48:51 | * | Jjp137 quit (*.net *.split) |
| 16:48:51 | * | flyx quit (*.net *.split) |
| 16:48:51 | * | matti quit (*.net *.split) |
| 16:48:51 | * | federico3 quit (*.net *.split) |
| 16:51:06 | * | nsf joined #nim |
| 16:56:20 | Araq | shashlick: IMO it's less dangerous than 'nim e' |
| 16:58:05 | * | rnrwashere quit (Remote host closed the connection) |
| 16:58:29 | shashlick | so you okay with me reimplementing the missing nimscript procs? |
| 16:58:48 | shashlick | will probably just be wrappers of existing runtime procs |
| 17:00:58 | Araq | I don't think it's much more than removing 'when defined(nimscript)' checks |
| 17:01:13 | Araq | so that the compiled libs also grow the same features |
| 17:01:15 | * | oz quit (Ping timeout: 264 seconds) |
| 17:01:23 | * | oz joined #nim |
| 17:01:48 | shashlick | what about all these procs? https://nim-lang.org/docs/nimscript.html |
| 17:02:03 | * | narimiran quit (Remote host closed the connection) |
| 17:03:43 | Araq | ok yeah, we need them all |
| 17:03:53 | Araq | and we need to do the implementation differently |
| 17:04:18 | shashlick | ok so i'm going to move to nim e as step one |
| 17:04:28 | shashlick | once that works, then i'll move to full compiled |
| 17:04:58 | Araq | hmm ok but the problems may be different |
| 17:05:06 | shashlick | right now i'm working on getting all tests to pass |
| 17:05:17 | * | I_Right_I joined #nim |
| 17:05:21 | Araq | if 'nim e' fails, 'nim c' might still work out |
| 17:05:56 | shashlick | well, the concern is having to implement all those additional procs |
| 17:06:01 | * | matti joined #nim |
| 17:06:01 | shashlick | https://github.com/genotrance/nimble/commits/nocompiler is what i have so far |
| 17:06:03 | * | federico3 joined #nim |
| 17:06:08 | * | flyx joined #nim |
| 17:06:08 | * | druonysus joined #nim |
| 17:06:09 | * | matti quit (Changing host) |
| 17:06:09 | * | matti joined #nim |
| 17:06:09 | * | Jjp137 joined #nim |
| 17:06:11 | * | masterdonx joined #nim |
| 17:06:20 | shashlick | and some of the tests pass, but that doesn't mean much since most of the functionality is in nimble compiled itself (install/build/download, etc) |
| 17:06:24 | * | druonysus quit (Changing host) |
| 17:06:24 | * | druonysus joined #nim |
| 17:06:32 | shashlick | want to keep the diff minimal |
| 17:06:38 | shashlick | let's see |
| 17:06:40 | shashlick | feedback is great |
| 17:13:33 | * | dddddd quit (Read error: Connection reset by peer) |
| 17:16:15 | * | abm joined #nim |
| 17:16:35 | * | jjido quit (Quit: Connection closed for inactivity) |
| 17:16:45 | * | rnrwashere joined #nim |
| 17:19:01 | leorize | Araq: how's the --newruntime performance compared to the GC atm? |
| 17:20:48 | Araq | I don't even benchmark it |
| 17:23:16 | FromGitter | <Minimisthupper> @leorize got it :d Thanks for help |
| 17:23:48 | Araq | it can be slower than the GC but it's too many other advantages to compensate for it. For example, you can use custom allocators to optimize your code, you can write your own SmallSeq[T] implementation that doesn't allocate for small seqs |
| 17:24:21 | FromGitter | <liquid600pgm> are shared refs going away for the new runtime? |
| 17:24:49 | Araq | you can use any micro-threading library since we don't trace runtime stacks |
| 17:25:55 | Araq | what do you mean? we don't have 'shared ref' in the language |
| 17:26:28 | FromGitter | <liquid600pgm> I mean, regular `ref object`s |
| 17:26:59 | FromGitter | <liquid600pgm> afaik they work just like `std::shared_ptr` in C++, just like `owned` is supposed to work like `std::unique_ptr` |
| 17:28:34 | Araq | well in some sense the proposal is an interesting mixture of unique_ptr and shared_ptr |
| 17:28:38 | * | Minimisthupper quit (Quit: Konversation terminated!) |
| 17:29:30 | FromGitter | <liquid600pgm> I understand what the proposal is talking about, what I'm asking is does `owned` replace `ref` completely |
| 17:29:39 | disruptek | it will be fun to have arbitrary pluggable microthreads. |
| 17:29:43 | * | rnrwashere quit (Remote host closed the connection) |
| 17:30:22 | I_Right_I | Araq: Have you explored Go style context switching like libmill/libdill? |
| 17:31:28 | I_Right_I | wait I'm not sure its called context switching |
| 17:31:32 | FromGitter | <Minimisthupper> @leorize are you in the Telegram group? :D |
| 17:31:45 | leorize | no, I don't use telegram :p |
| 17:32:27 | leorize | maybe someone should bridge telegram to irc |
| 17:33:01 | FromGitter | <Minimisthupper> yeah |
| 17:33:33 | * | Minimisthupper joined #nim |
| 17:33:41 | * | Minimisthupper quit (Client Quit) |
| 17:34:48 | leorize | Araq: so far https://github.com/frol/completely-unscientific-benchmarks/blob/master/nim/main.nim is a tiny bit faster with --newruntime |
| 17:34:49 | FromGitter | <Minimisthupper> @leorize https://github.com/stevesoltys/telegram-irc |
| 17:34:57 | * | ryukoposting quit (Quit: WeeChat 1.6) |
| 17:34:59 | I_Right_I | I guess its called structured concurrency. |
| 17:35:13 | leorize | maybe it would be faster if you properly port it to owned ref |
| 17:41:06 | Araq | why does that even compile? it shouldn't |
| 17:41:21 | Araq | regression :P |
| 17:41:28 | Araq | damn I need to add more tests |
| 17:42:04 | Araq | I_Right_I: not really explored, but with the new runtime we're compatible with it |
| 17:42:35 | I_Right_I | Araq: I was kind of think it would be. |
| 17:42:44 | leorize | Araq: I've added a bunch of `owned` and `move` to the file and it... ICE :p |
| 17:43:41 | * | believer joined #nim |
| 17:48:52 | leorize | in case anyone wanna know how hard is it to migrate to owned, this is how I migrated the completely unscientific benchmark: http://ix.io/1G6B/diff |
| 17:54:02 | shashlick | the telegram gang don't want to bridge over to here |
| 17:54:10 | shashlick | we raised the idea a while ago |
| 17:56:49 | * | xylef quit (Ping timeout: 250 seconds) |
| 17:57:30 | * | rauss joined #nim |
| 17:58:22 | * | rauss quit (Client Quit) |
| 17:58:32 | * | rauss joined #nim |
| 17:58:42 | * | rauss quit (Client Quit) |
| 17:59:03 | * | rauss joined #nim |
| 18:18:55 | * | xylef joined #nim |
| 18:23:19 | * | Sonderblade joined #nim |
| 18:26:18 | FromGitter | <Minimisthupper> @leorize whats ix.io ? :D |
| 18:26:34 | FromGitter | <liquid600pgm> it's a terminal pastebin |
| 18:27:39 | FromGitter | <Minimisthupper> is there any understandable description for usage ? ;D |
| 18:28:00 | Araq | leorize: I'm not sure you got the 'move's right :P |
| 18:28:16 | FromGitter | <liquid600pgm> @Minimisthupper sure, read the manpage http://ix.io/ |
| 18:28:28 | * | al_ quit (Quit: al_) |
| 18:28:51 | * | luis_ quit (Remote host closed the connection) |
| 18:28:56 | I_Right_I | In the instance of 'proc getData(data: var string)' is the mutable string still passed by reference? |
| 18:30:43 | Araq | sure |
| 18:31:35 | leorize | Araq: I just add whatever the compiler yell at me :p |
| 18:32:53 | leorize | it yelled that I can't copy owned, so I `move`, even tho it looks like that was already last read, but *shrug* :p |
| 18:37:30 | Araq | the move analyser doesn't understand object fields |
| 18:37:36 | Araq | I'm adding that :P |
| 18:51:41 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 19:01:01 | * | xylef quit (Ping timeout: 252 seconds) |
| 19:05:56 | believer | narimiran: you think I'm your slave? (https://github.com/nim-lang/Nim/pull/11013#issuecomment-482672521) Just because you write documentation, and that's your work, you can make demand from others? |
| 19:07:04 | Araq | believer: calm down please :-) |
| 19:07:21 | believer | ok whatever |
| 19:07:38 | Araq | and fwiw I agree with you. |
| 19:07:55 | Araq | however, that's how we got the "argh, bad docs everywhere" in the past :P |
| 19:09:29 | believer | sure thats a good argument |
| 19:11:25 | believer | also consider this: everyone wraps the canvas module themselves (I found 3 wrappers in github, 1 in nimble) and none wants to upstream it |
| 19:12:49 | believer | which causes ofc fragmentation. |
| 19:12:58 | believer | also I didn't want to say it, but these wrappers are all terrible. |
| 19:13:16 | * | NimBot joined #nim |
| 19:17:32 | * | xylef joined #nim |
| 19:17:45 | dom96 | I don't think "there are multiple implementations" is a good argument for adopting something into the stdlib |
| 19:21:20 | believer | dom96: it's a wrapper for js Canvas Api, why you think that shouldn't be in the stdlib? |
| 19:21:54 | * | Sonderblade quit (Read error: No route to host) |
| 19:22:01 | dom96 | because I have no reasons why it should be |
| 19:24:17 | believer | bc nim compiles to javascript and should be able to use the Api's standardized and offered by the browsers. |
| 19:27:46 | * | luis_ joined #nim |
| 19:30:38 | FromGitter | <bluenote10> imho it would be nice to have: (1) less fragmentation, (2) more attractive to JS devs. But the price is to maintain it, and the one wrapper on Nimble didn't look too bad on first glance. |
| 19:30:54 | * | xylef quit (Ping timeout: 255 seconds) |
| 19:32:21 | * | xylef joined #nim |
| 19:33:33 | * | kungtotte quit (Quit: leaving) |
| 19:34:28 | believer | i don't know if you saw it but there is a repo in github that autogenerates all those bindings: https://github.com/awkward-ninja/nim-whatwg |
| 19:34:39 | believer | what you think of this? |
| 19:37:38 | * | xylef quit (Read error: Connection reset by peer) |
| 19:37:47 | Araq | I have no opinion, I wasn't aware of it |
| 19:37:48 | federico3 | leorize: beast? |
| 19:38:35 | Araq | we might want to decide about this constant stdlib vs nimble package question |
| 19:40:33 | FromGitter | <bluenote10> was your PR the result from the auto generator? |
| 19:40:45 | believer | no i did it manualy |
| 19:41:08 | Araq | I'm for a "batteries included" design, fwiw. but it has its downsides (tied to the Nim versioning, needs to be of high quality then etc.) |
| 19:41:43 | FromGitter | <bluenote10> did you test if the generator produces similar quality? |
| 19:42:15 | Araq | bundling Nim with a selected set of packages would also work except that even our own nim-lang packages tend to be mismanaged |
| 19:43:50 | believer | No but you can see the output in `whatwg` directory |
| 19:44:13 | believer | it needs some work |
| 19:45:24 | * | luis_ quit (Ping timeout: 252 seconds) |
| 19:45:31 | FromGitter | <bluenote10> looks comprehensive ;) |
| 19:48:18 | * | xylef joined #nim |
| 19:51:44 | * | Jesin quit (Quit: Leaving) |
| 19:52:31 | * | ptdel joined #nim |
| 19:54:04 | * | d10n-work quit (Quit: Connection closed for inactivity) |
| 19:57:32 | * | ptdel quit (Ping timeout: 268 seconds) |
| 19:58:31 | * | Jesin joined #nim |
| 20:03:25 | FromGitter | <deech> My 2 cents, Haskell is a cautionary tale against standard libraries. There were decisions made early that were right for a young language but not for what it has become and they still plague and cause friction to this day. |
| 20:04:10 | * | luis_ joined #nim |
| 20:04:36 | * | luis_ quit (Client Quit) |
| 20:04:59 | * | luis_ joined #nim |
| 20:06:03 | FromGitter | <deech> I predict this happening with the async/await. That design space itself is so young and immature that decisions made now and baked in to the stdlib will be a burden to future Nim devs. |
| 20:06:14 | believer | ftr, i did my best to avoid conflict and i don't think that just bc someone has a hard day should lash out at others. Everyone is responsible for their behaviour. From my side, apologies if i over reacted. |
| 20:06:50 | FromGitter | <deech> That said I think it's important to have a good base set of string handling and math libraries. |
| 20:08:04 | * | shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 20:10:20 | * | luis_ quit (Ping timeout: 252 seconds) |
| 20:11:13 | * | shomodj joined #nim |
| 20:17:25 | * | seni joined #nim |
| 20:19:04 | shashlick | from my side, I write a lot of nim with mostly stdlib stuff, i've only used 10 odd packages from nimble |
| 20:19:19 | shashlick | i don't know if the larger stdlib discourages discovering more stuff on nimble |
| 20:27:44 | * | stefanos82 quit (Remote host closed the connection) |
| 20:29:06 | Zevv | I guess people tend to trust stdlib packages much more over nimble - if it's part of the stdlib it is probably good and tested and will be supported on the long run. Nimble packages are kind of anonymous - you can' tell the quaility from the outside, you need to go to github to find out who's behind it and how recent it is. All that discourages nimble over stdlib. |
| 20:38:42 | disruptek | i'd have the stdlib have a very distinct and separate mission from nimble. it'd be carefully tied to the compiler, full of magic, and highly optimized for the compiler's needs. then let everything else evolve separately, and make using and creating packages just as easy as stdlib is now. |
| 20:41:55 | * | shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 20:45:30 | disruptek | this allows the compiler to move fast and break things and lets packages move at whatever speed they need to, however they wish, according to the needs of the userbase. |
| 20:48:48 | * | hoijui quit (Ping timeout: 252 seconds) |
| 20:49:47 | * | believer quit (Ping timeout: 240 seconds) |
| 20:54:06 | * | dddddd joined #nim |
| 20:55:56 | * | hoijui joined #nim |
| 20:56:28 | * | hoijui quit (Remote host closed the connection) |
| 20:56:50 | * | nsf quit (Quit: WeeChat 2.4) |
| 20:58:29 | xace | https://nim-lang.org/docs/httpclient.html#getContent%2Cstring%2Cstring%2Cint%2CSSLContext%2CProxy # getContent reads: Deprecated since version 0.15.0: use HttpClient.getContent instead. # isn't that the exact function that is deprecated? |
| 21:08:17 | * | xylef quit (Quit: WeeChat 2.4) |
| 21:09:45 | FromGitter | <alehander42> Araq batteries included means you have to update a much bigger stdlib to language changes |
| 21:09:57 | FromGitter | <alehander42> Makes it harder to change the language |
| 21:10:17 | FromGitter | <alehander42> Maybe that's a good thing tho if people need to do it with ecosystem anyw |
| 21:14:12 | * | xylef joined #nim |
| 21:16:16 | * | Trustable quit (Remote host closed the connection) |
| 21:18:50 | * | solitudesf quit (Ping timeout: 250 seconds) |
| 21:20:09 | * | Cthalupa quit (Ping timeout: 252 seconds) |
| 21:22:11 | * | Cthalupa joined #nim |
| 21:23:19 | Araq | alehander42: language changes are already hard. For me "batteries included" wins because users can trust the Nim core team and contributors, but they cannot trust a web of N dependencies |
| 21:23:33 | Araq | and that's not because Araq is inherently trustworthy. |
| 21:23:39 | Araq | it's about numbers |
| 21:24:01 | Araq | I can trust 5-10 people more easily than 100. |
| 21:24:38 | FromGitter | <alehander42> It's a full time job to maintain a quality batteries included set of libraries |
| 21:24:53 | FromGitter | <alehander42> Even = many full time jobs imho |
| 21:25:37 | Araq | the Node.js ecosystem seems to be a disaster for security, you can semver and enforce semver all you want |
| 21:26:04 | FromGitter | <alehander42> And if one designs wrongly a stdlib module it stays for compat reasons , you don't have competition between libs etc |
| 21:26:32 | Araq | well any way you do it, it's wrong |
| 21:26:41 | FromGitter | <alehander42> It's cool to have it but I think it requires a lot of resources and some patience and conservative inclusion |
| 21:27:58 | FromGitter | <alehander42> Well ok but still a huge amount of useful stuff is in 3rd party libs in all languages |
| 21:28:13 | FromGitter | <alehander42> And some languages even have alternative stdlibs |
| 21:28:38 | FromGitter | <alehander42> There should be some kind of balance |
| 21:28:44 | Araq | true but occasionally the 3rd party lib should be moved into the stdlib |
| 21:28:47 | FromGitter | <alehander42> Can you imagine addin owned andove |
| 21:28:54 | FromGitter | <alehander42> To 400 |
| 21:28:57 | FromGitter | <alehander42> Modules |
| 21:28:58 | * | arecacea1 quit (Remote host closed the connection) |
| 21:29:08 | FromGitter | <alehander42> Instead of e.g 100 |
| 21:29:12 | Araq | andove? |
| 21:29:17 | * | arecacea1 joined #nim |
| 21:29:22 | FromGitter | <alehander42> And move' |
| 21:29:27 | FromGitter | <alehander42> Just an example |
| 21:29:52 | Araq | I think that's a bad comparison. |
| 21:30:00 | FromGitter | <alehander42> But the burden is more serious because each module can be its own self contained problem domain |
| 21:30:33 | Araq | I can imagine to do it for 100 modules, but can you imagine to do it for 100 Nimble packages? all in their own git repo and stuff |
| 21:31:14 | FromGitter | <alehander42> And you can go from parsing formats to solving gui problems to x and y it's hard to keep all this together with 2 3 ppl |
| 21:31:18 | Araq | the Linux kernel has thousands of drivers, they make an API change, they update all the drivers |
| 21:31:41 | FromGitter | <alehander42> Well that's the point you don't need to do it because lib maintainers should update not the core team |
| 21:32:24 | Araq | but this is the mistake. we're talking about how to split up *projects* |
| 21:32:34 | Araq | and you conflate it with the number of people involved. |
| 21:33:08 | * | Cthalupa quit (Ping timeout: 250 seconds) |
| 21:33:13 | FromGitter | <alehander42> But my point is that it doesnt scale well |
| 21:33:19 | FromGitter | <alehander42> If a language gets usage |
| 21:33:42 | FromGitter | <alehander42> You start to need 1000 libs for various tasks wrappings etc |
| 21:33:59 | FromGitter | <alehander42> You need the community to maintain them you can't include them all |
| 21:34:08 | FromGitter | <alehander42> So now you need to prioritize |
| 21:34:15 | * | Cthalupa joined #nim |
| 21:34:20 | FromGitter | <alehander42> So the only difference between my position and yours is |
| 21:34:25 | FromGitter | <alehander42> Where to cut the line |
| 21:35:01 | FromGitter | <alehander42> To provide e.g. small or bigger % of modules solving the usual problems people deal with |
| 21:35:19 | Araq | why does "community maintains it" mean "everything in its own Nimble package". I mean, ok, that's how things are, but does it have to be this way? I don't know. |
| 21:37:13 | FromGitter | <alehander42> Because otherwise still the responsibility falls on the core team |
| 21:37:28 | FromGitter | <alehander42> And code rots more easily imo |
| 21:37:42 | FromGitter | <alehander42> Otherwise people see a is not maintained and just switch to b |
| 21:37:48 | FromGitter | <alehander42> But if a is in stdlib |
| 21:38:05 | FromGitter | <alehander42> You need to support it even if you wrote a much better b |
| 21:38:48 | Araq | and if I add it to Nimble instead I don't have to support it? |
| 21:39:39 | Araq | that's the current situation: Nimble package A could be abandoned anytime. Can I rely on its existence? Can I use it? Unclear. |
| 21:40:14 | Araq | if it's a stdlib module at least I know there will be a proper deprecation period |
| 21:40:35 | Araq | and I know that it got at least a single code review process. |
| 21:40:45 | Araq | and usually I can assume it has some tests. |
| 21:41:53 | Araq | and now multiply this case with the factor of 100. For end users "batteries included" wins hands down. |
| 21:42:16 | * | luis_ joined #nim |
| 21:43:33 | Araq | and that's why Python is super popular right now and Lua remained a niche language even though Lua is faster, smaller and more elegant and doesn't use freaking indentation. I'm kidding. ;-) |
| 21:43:33 | luis_ | arraymancer is asking for nim version 0.19.9, I have 0.19.4 installed, how can I go to the .9 version |
| 21:43:39 | luis_ | ? |
| 21:44:28 | Araq | luis_: that's nim "devel", aka install from github |
| 21:44:47 | luis_ | oh, ok |
| 21:50:48 | Araq | https://docs.python.org/3/library/winsound.html |
| 21:51:54 | Araq | Python version 3.7 still has 'winsound', how do they survive? it's obviously bad... Or maybe it isn't and we can learn something here. |
| 21:57:18 | FromGitter | <alehander42> Well yeah python have a lot of old stuff that seems too much to be in stdlib |
| 21:57:32 | FromGitter | <alehander42> And people use a lot of stuff outside it's stdlib |
| 21:58:20 | FromGitter | <alehander42> All the science / ml / most of web stuff is outside |
| 21:58:36 | FromGitter | <alehander42> Developed as competing libs |
| 22:00:58 | shashlick | i guess a good middle is core team managed nimble packages |
| 22:01:41 | FromGitter | <alehander42> Mu point is you cant depend on the core team being able to moderate and maintain a huge library : if it can good but you always need to have a good package ecosystem story to survive these days |
| 22:01:42 | shashlick | the burden of moving a good lib to stdlib is too high, easier to get a nimble package adopted by the core team |
| 22:01:54 | shashlick | a good start is the fact that 70+ packages are now part of the nim CI |
| 22:02:21 | shashlick | i think such a curated list is very good to have - should highlight these packages somewhere so that they get some advertising |
| 22:02:49 | * | prometheus joined #nim |
| 22:02:57 | * | xet7 quit (Ping timeout: 250 seconds) |
| 22:03:14 | shashlick | i don't mean the nim core team as it stands right now, they take care of compiler and stdlib but not everyone can enhance/fix everything |
| 22:03:35 | shashlick | better to talk in terms of a separate core team that manages stdlib |
| 22:03:48 | shashlick | saying community is like talking about random people out there |
| 22:03:50 | disruptek | my position is that you never want the language to be held back by the stdlib, and that's why you decouple them. |
| 22:04:26 | shashlick | but you have to maintain the stdlib or the language is useless with an unloved stdlib |
| 22:05:22 | disruptek | sure, but it's a separate problem. the stdlib can have a devel branch that tracks the compiler, but it doesn't /have/ to. |
| 22:06:47 | * | luis_ quit (Ping timeout: 240 seconds) |
| 22:06:49 | shashlick | i guess you are talking of three things then - a compiler core team which can move as fast as they want, an stdlib team and a distro team perhaps that is part of the stdlib team that ships a stable and devel release |
| 22:07:50 | disruptek | once you split off most of the stdlib from the compiler, that software can evolve separately. it means that for 0.20.0, you don't necessarily need to port everything that ran in 0.19.4. |
| 22:08:29 | prometheus | I agree that with that, imo nim have too many libraries in its stdlib already, and that hold back the language to evolve faster/better, because it have too many components to maintain |
| 22:08:37 | * | rnrwashere joined #nim |
| 22:08:52 | * | chickendan quit (Quit: Quit) |
| 22:10:32 | disruptek | yes, and the only people that will worry about that maintenance is people that use the software. so you're not needlessly porting stuff that no one uses. everything moves at whatever rate is appropriate given interest. |
| 22:10:45 | shashlick | i think ultimately, what matters is Araq's experience with dragging along the stdlib as we perceive - it does make using Nim convenient since everything is tested in one place |
| 22:11:13 | shashlick | in fact, having 70+ nimble packages in teh CI now is a sign that it helps the compiler to stay stable through these changes, identifying breaks fast |
| 22:11:27 | shashlick | i don't think we are at a point where we need compiler agility but stability |
| 22:11:28 | disruptek | but that's a separate concern. |
| 22:12:13 | disruptek | the compiler can be as stable as you want -- just stop updating it. |
| 22:12:57 | * | rnrwashere quit (Ping timeout: 252 seconds) |
| 22:13:22 | disruptek | unless everyone uses all of the stdlib, all of the time, and is always running the latest compiler, it will never be more efficient to integrate stdlib development with the compiler. |
| 22:14:47 | disruptek | personally, i am worried about async. i would say that's the major pain point that feels too weakly specified, too dangerous to depend upon. too likely to change dramatically, breaking a lot of my code. |
| 22:15:16 | * | xet7 joined #nim |
| 22:17:19 | prometheus | I do think that the stdlib should have been trimmed down to just the most used stuff, there are things like cgi, smtp, etc that must be used by like 1% of the users? and the core team keeps maintaining them while they should be focusing on what of the others 99% users use/would use |
| 22:17:58 | Araq | we tried to move cgi out and gave up, not worth the costs |
| 22:18:30 | Araq | in retrospect you can of course argue that cgi should have never been added |
| 22:18:48 | Araq | but changing things is more effort than leaving things as they are ;-) |
| 22:19:18 | shashlick | Perhaps it will help to know which stdlib modules haven't been touched in years - not that changes == usage |
| 22:20:12 | Araq | also, we did remove quite some modules from the stdlib. |
| 22:20:40 | Araq | things like nim-lang/x11 which now doesn't have git tags or a CI setup... |
| 22:21:31 | shashlick | How about a script that searches Nim projects on github and checks for imports |
| 22:22:06 | Araq | or c2nim with the "compiler Nimble package" problems... |
| 22:22:28 | shashlick | Correlate with number of clones or activity of those projects |
| 22:23:07 | Araq | monorepos simply work better, all things considered. I know you don't agree, that's ok. |
| 22:24:20 | Araq | good night |
| 22:28:52 | disruptek | alehander42: what's missing from languist? what doesn't work? |
| 22:36:17 | * | seni quit (Quit: Leaving) |
| 22:36:23 | * | prometheus quit (Ping timeout: 256 seconds) |
| 22:40:56 | * | luis_ joined #nim |
| 22:41:16 | * | rnrwashere joined #nim |
| 23:05:15 | * | xylef quit (Quit: WeeChat 2.4) |
| 23:10:38 | * | rnrwashere quit (Remote host closed the connection) |
| 23:14:29 | shashlick | Monorepos are the way to go in the Googles of the world |
| 23:18:58 | * | rnrwashere joined #nim |
| 23:20:21 | * | abm quit (Quit: Leaving) |
| 23:23:45 | * | luis_ quit (Read error: Connection reset by peer) |
| 23:24:41 | * | luis_ joined #nim |
| 23:28:20 | * | rnrwashere quit (Remote host closed the connection) |
| 23:31:52 | * | luis_ quit (Ping timeout: 250 seconds) |
){kind=link}