00:00:34 | * | vonHabsi_ joined #nim |
00:10:08 | ryukoposting | dom96_w it never asked me about package managers... weird |
00:10:51 | dom96_w | same :/ |
00:11:33 | ryukoposting | It asked me a lot about objective-c and swift, but I've never used swift nor did I mark it down so I'm very confused |
00:11:47 | ryukoposting | I guess... apple? |
00:16:20 | * | dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
00:24:06 | * | Jesin quit (Quit: Leaving) |
00:42:13 | * | Jesin joined #nim |
00:52:23 | * | cspar_ joined #nim |
00:52:55 | PMunch | Domn, that was a long survey dom.. |
00:59:27 | * | cspar_ quit (Ping timeout: 240 seconds) |
01:00:08 | * | PMunch quit (Remote host closed the connection) |
01:01:11 | * | cspar joined #nim |
01:11:43 | * | cspar quit (Ping timeout: 245 seconds) |
01:15:21 | * | lritter joined #nim |
01:35:58 | rayman22201 | @ryukoposting. I have only played with embedded Nim very little, but I think it has potential to be a very good language in that space. Waaay more ergonomic than Rust and works in places Rust can't because it's not tied to llvm. I'm glad to see more people interested. |
01:36:27 | ryukoposting | yeah Rust's ABI is insane |
01:37:24 | ryukoposting | not to mention, the lack of compatibility with common toolchains is really damning |
01:37:40 | ryukoposting | if LLVM doesn't support it, Rust doesn't support it |
01:39:02 | rayman22201 | yup.... I'm still waiting for LLVM esp8266 support.... Tensilica will get to it... when they feel like it??? screw that.... |
01:39:45 | ryukoposting | good luck convincing any of the major vendors to support anything that isn't C |
01:39:51 | ryukoposting | or sepples |
01:40:26 | * | vlad1777d quit (Ping timeout: 246 seconds) |
01:40:35 | rayman22201 | yeah... In the mean time, Nim just compiles to mostly readable C, just plug into what ever toolchain you want. |
01:41:19 | ryukoposting | well, it isn't quite that simple since you can |
01:41:36 | ryukoposting | can't inject debug information into executables, or at least there's no clean way of doing it |
01:42:00 | rayman22201 | Of course. I'm exaggerating a little. but still, I feel like Nim is closer to where it needs to be than other similar languages. |
01:42:21 | ryukoposting | it's a hell of a lot better than dealing with incomprehensible LLVM linker errors |
01:42:47 | rayman22201 | lol. #preach |
01:47:08 | ryukoposting | nim is comfy dude |
01:47:46 | ryukoposting | I wrote a little makefile generator for work in it and fell in love with it, I've basically spent the last 2 weeks shilling this language to my coworkers |
01:49:03 | * | memeboi quit (Ping timeout: 256 seconds) |
01:52:29 | rayman22201 | excellent lol |
01:53:54 | rayman22201 | My company is way to entrenched. Fin-tech will be C/C++ and Java for a long long time. But I can at least play around with Nim in my free time lol :-) |
01:54:34 | * | vlad1777d joined #nim |
01:54:37 | ryukoposting | I work in embedded, so we're all C naturally |
01:55:02 | ryukoposting | but I wrote a few tools in nim, and we use them quite a bit |
01:56:11 | rayman22201 | That's good to hear |
02:01:10 | rayman22201 | so how does this Jlink thing work? I wonder how hard it would be to make Nim compatible with it. |
02:01:32 | ryukoposting | It would require fundamentally changing the way Nim compiles |
02:01:56 | ryukoposting | it would have to be able to produce its own binaries, and pack the debug info itself |
02:04:50 | rayman22201 | how does it work for C? |
02:06:50 | ryukoposting | so you know how gcc and others have the -g flag? |
02:07:40 | rayman22201 | yup |
02:08:04 | ryukoposting | the compiler essentially creates a region in the binary filled with symbol names, the files they're from, and their corresponding locations in memory. That's all stored in a predefined format, e.g. ELF or motorola S-record |
02:08:05 | rayman22201 | sorry for the noob questions btw. I appreciate it :-) |
02:08:22 | rayman22201 | yup. I'm very familiar with ELF goodies |
02:08:53 | ryukoposting | the reason Nim can't do that is because it's not the part generating the binary- gcc/whatever backend is generating the binary, and thus would be packing the binary with debug information for the C code Nim generated |
02:09:27 | * | vlad1777d quit (Ping timeout: 240 seconds) |
02:09:30 | ryukoposting | there are potential ways around that, like having Nim's codegen spit out C comments |
02:10:13 | * | vlad1777d joined #nim |
02:10:33 | rayman22201 | Oh, I see what you are getting at. Yeah. Nim currently "solves" this in two ways. It can output C comments, and we have GDB python scripts to teach GDB how to interpret the C code better. |
02:10:41 | ryukoposting | and I'm sure Araq and friends will find a way |
02:11:10 | ryukoposting | aaaaah i see, that's pretty neat |
02:11:49 | ryukoposting | OpenOCD might be easier to work with since it's foss, J-Link is proprietary so you might have to go through them to get Nim support |
02:12:22 | ryukoposting | and that's a big problem, because at least in my industry J-Link is by far the most common debugger in use |
02:12:23 | rayman22201 | yeah. in other words, J-Link probably won't happen. But OpenOCD might be doable. |
02:13:02 | ryukoposting | of course, if you raise enough hell and customers are demanding Nim support, then J-Link will probably get Nim support eventually |
02:13:33 | rayman22201 | When Nim gets enough embedded developers to do that, I will be a very happy person lol. |
02:14:22 | ryukoposting | I think it's possible, but it will take time |
02:14:58 | ryukoposting | A lot of the guys I work with have been doing this stuff for 25-30 years, they balk at the idea of anything more abstracted than C |
02:16:04 | * | vonHabsi joined #nim |
02:16:16 | ryukoposting | and, to be fair, I don't think anyone I've worked with has ever found C++ to be a pleasant language to work with, so I can see why they'd hesitate |
02:17:02 | rayman22201 | The GDB stuff is very cool, but still a bit experimental / still rough around the edges. Although it was done by one of the main core devs Arne Doring. |
02:17:07 | * | ng0_ joined #nim |
02:17:53 | rayman22201 | lol. True. C++ is ..... special.... But that is no reason to stay stuck in the 1970's. People get very entrenched. |
02:18:02 | ryukoposting | I'm not super familiar with names yet, besidea Araq and dom96 |
02:18:41 | rayman22201 | I don't remember his irc handle :-P. He was the first official person they hired I believe. |
02:18:50 | ryukoposting | cool |
02:19:30 | ryukoposting | it's good to know this is somethign that's actually getting off the ground, I'm dumping time into a few nimble packages right now lol |
02:19:35 | * | ng0 quit (Ping timeout: 256 seconds) |
02:20:49 | rayman22201 | It's trying lol. 2019 is a good year for the language I think. |
02:22:01 | ryukoposting | Does nim have a big corporate sponsor? It seems like a lot of the other new langs (Go, Kotlin, etc) have some huge company behind them |
02:22:06 | * | vonHabsi_ quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
02:23:08 | rayman22201 | Krux02! that's Arne! He wrote a cool Nim to GPU Shader compiler: https://github.com/krux02/opengl-sandbox, and here is the gdb script: https://github.com/nim-lang/Nim/blob/devel/tools/nim-gdb.py |
02:23:40 | ryukoposting | alright that's pretty damn cool |
02:24:21 | ryukoposting | that makes me think, nimble.directory is still missing a lot of the popular GPU compute libraries |
02:24:36 | rayman22201 | Nim does not have a "big" corporate sponsor. Late last year they got a medium corporate sponsor from the Etherium Blockchain company Status. |
02:24:54 | ryukoposting | nice |
02:26:25 | rayman22201 | that has been the closest we have gotten to proper sponsorship. They are writing an entire Etherium stack from the ground up in Nim, and they give enough to hire a few devs (2 people now?) to work on the langauge itself full time. I don't love blockchain, but I appreciate the sponsorship for the language :-P |
02:26:46 | * | vonHabsi_ joined #nim |
02:27:18 | rayman22201 | Which is good because Dom96 went and got hired by Facebook! the bastard ;-) |
02:28:19 | rayman22201 | As far as GPU compute the biggest contender is https://github.com/mratsim/Arraymancer |
02:29:44 | rayman22201 | nobody else can really compare to that. mratsim is basically rebuilding numpy / pandas, and tensorflow all in one crazy package lol. He is a pretty smart guy... |
02:31:42 | dom96 | Now if only I could just get Facebook to adopt Nim :) |
02:33:09 | rayman22201 | Nim evangalism strike force engage! |
02:33:26 | ryukoposting | aaay |
02:34:23 | ryukoposting | if Nim wants to get into embedded, industrial automation has an unholy amount of money in it |
02:37:20 | dom96 | ryukoposting: huh, I see you mentioning that Rust isn't ideal for embedded. Everything I've seen so far from everyone is that Rust is the holy saviour for embedded :) |
02:37:51 | * | vonHabsi_ quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
02:38:49 | rayman22201 | I've seen a few loud Rust people say that, but LLVM never had enough adoption in that space for it to be true. |
02:38:59 | dom96 | interesting |
02:40:04 | dom96 | Guess we just need to copy Rust's compile-time lifetimes and I'll feel confident to tell everyone to use Nim instead for embedded :P |
02:40:26 | dom96 | Perhaps it's not as important as I think for embedded? |
02:41:00 | dom96 | It really seems like a killer feature that's tough to compete with |
02:41:32 | * | vonHabsi_ joined #nim |
02:41:49 | rayman22201 | I think we need to get the Nim SPARK thing going. It will solve the same problems in what I think is a more egonomic way. IDK for sure though. |
02:42:12 | dom96 | SPARK thing? |
02:42:52 | vonHabsi_ | test connection |
02:43:09 | rayman22201 | Ada SPARK, the formal verification tool. |
02:44:00 | rayman22201 | Araq had floated the idea with someone recently on IRC about doing a formal verification solver, or some features from a SAT solver into Nim. |
02:44:16 | rayman22201 | https://en.wikipedia.org/wiki/SPARK_(programming_language) |
02:44:59 | dom96 | I don't know, it just feels like bloating the language and splitting our focus even more |
02:45:13 | rayman22201 | You can use it to verify lifetimes, along with a lot of other stuff. These days it's mostly used for high integrity software like aerospace, where you CANNOT have an integer overflow or people die. |
02:45:44 | ryukoposting | dom96 rust is a meme |
02:46:25 | ryukoposting | ok i shouldn't say that, the borrow checker is actually a brilliant invention and the fact that the language works at all is impressive |
02:48:10 | ryukoposting | conceptually, it's a great language. The problem is that the rust compiler is painfully slow and its LLVM IR output is more UB-packed than babby's first C program |
02:48:27 | dom96 | It indeed seems like there is a lot of hype around it, and that some of it is warranted... until people talk about writing web apps in it and I think they're going too far |
02:48:45 | ryukoposting | it might have a place there honestly, moreso than embedded |
02:49:03 | rayman22201 | @dom96 fair point. Nim probably does not need to go this far, and Nim has had a history of chasing shiny new features maybe a little too much in the past. That being said, I think destructors are a big step in the right direction for embedded / systems programming in general. And the advantage of not being tied to LLVM or any particular C toolchain is underrated. |
02:49:39 | dom96 | ryukoposting: really? I can only imagine dealing with lifetimes and the slow compile times when developing a web app would be a massive PITA |
02:49:57 | ryukoposting | I'm new and my opinion is meaningless, but imo Nim should be looking at stabilizing what it has, and going 1.0 by mid-next year |
02:50:07 | ryukoposting | do a feature freeze, new stuff goes in 1.1 or whatever |
02:50:20 | dom96 | also, by UB-package I guess you mean undefined behaviour? If so, that's funny considering pcwalton complained about undefined behaviour in Nim on HN a while back |
02:50:54 | ryukoposting | dom96 if you think it's bad for webdev, you should see what it's like trying to write to a special function register in Rust |
02:51:03 | rayman22201 | Don't worry, that is definitely happening @ryukoposting. The stuff I'm talking about is very pie in the sky experimental stuff, not at all the focus of the core team right now. |
02:51:15 | dom96 | ryukoposting: just wrap everything in unsafe {}? :P |
02:51:31 | ryukoposting | you literally have to have like 4 layers of """abstractions""" just to get it to write to a damn VGA buffer |
02:51:52 | dom96 | rayman22201: Yeah, destructors are something I'm looking forward to as well. |
02:51:57 | ryukoposting | and documentation on embedded Rust is abysmal at best |
02:52:06 | ryukoposting | nooooooooo not destructors :( |
02:52:22 | dom96 | hehe, why not? |
02:52:39 | ryukoposting | I guess if they're optional, and not in there by default like sepples it's proibably fine |
02:52:47 | ryukoposting | they're just super annoying to debug |
02:53:36 | dom96 | I suppose you just want to be absolutely explicit about everything when writing embedded |
02:53:57 | ryukoposting | yep, implicit behaviors and bare metal don't play nice |
02:54:26 | rayman22201 | lol. They are better than C++ destructors. Also better than a GC. |
02:54:58 | rayman22201 | they will definitely be optional. Though some core data structurs, namely seqs and strings are going to use them. |
02:55:06 | ryukoposting | what it comes down to is that you can't handle errors in destructors, and normally when a destructor fails, your program crashes |
02:55:18 | dom96 | https://github.com/nim-lang/Nim/wiki/Destructors |
02:55:22 | ryukoposting | but when there isn't an OS to protect your program from itself, what does your program do when it crashes? |
02:55:27 | dom96 | Please read and tell us if this is a bad idea :) |
02:55:59 | dom96 | (here is the relevant issue that tracks it: https://github.com/nim-lang/Nim/issues/7041, props to Araq for documenting this all) |
02:56:01 | * | vonHabsi_ quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
02:56:34 | ryukoposting | I like that they're being used for the explicit purpose of removing stdlib reliance on GC |
02:56:35 | * | vonHabsi_ joined #nim |
02:56:54 | ryukoposting | the moment your destructors have side effects is when bad things begin to happen |
02:56:54 | rayman22201 | Araq and the community has had thorough thoughts and discussions on this lol. Also this is tangentially relevant: https://nim-lang.org/araq/quirky_exceptions.html |
02:57:11 | dom96 | quirky exceptions aren't really |
02:57:16 | * | vonHabsi left #nim (#nim) |
02:57:20 | dom96 | They're just a crazy concept that Araq had |
02:57:27 | dom96 | Unlikely to be implemented |
02:57:38 | rayman22201 | but they illustrate his thought process about error states |
02:58:02 | ryukoposting | is this man the buddha |
02:58:25 | rayman22201 | imo, destructors are Araq taking the best parts of the borrow checker and saying screw the rest. |
02:58:31 | rayman22201 | Nim destructors* |
02:58:32 | dom96 | lol |
02:58:33 | ryukoposting | I can see where Nim got its function calling syntax |
02:58:33 | rayman22201 | lmao |
02:59:06 | ryukoposting | the idea of kinda flipping traditional imperative code inside-out is what attracted me to Nim in the first place |
03:00:35 | * | banc quit (Quit: Bye) |
03:01:39 | ryukoposting | I would say that, if possible, destructors must have some kind of compiler-enforced control of side effects |
03:01:50 | ryukoposting | it's the lack thereof in C++ that causes so many problems |
03:02:00 | * | dom96 should head to sleep, flight back to London tomorrow |
03:02:03 | dom96 | bye guys! |
03:02:08 | rayman22201 | GN! |
03:02:08 | ryukoposting | cya |
03:02:40 | * | vonHabsi joined #nim |
03:03:13 | rayman22201 | Nim can be lax on side effects, but it actually has a decent effect tracking system that you can use to compiler enforce if you need. that's exactly what {.gc_safe.} does. |
03:03:46 | ryukoposting | yeah, it seems to be pretty effective, just from my messing around |
03:04:41 | ryukoposting | the way it enforces proper use of async/await through pragmas is pretty damn cool |
03:05:09 | leorize | there's also {.noSideEffects.} |
03:05:09 | rayman22201 | definitely agree |
03:05:20 | ryukoposting | func makes me happy |
03:05:52 | rayman22201 | 😎 |
03:06:19 | leorize | what mind blowing is that async/await are just regular macros :P |
03:06:32 | leorize | that's infinitely cooler than anything else |
03:06:51 | ryukoposting | i haven't peeked under the hood, but it feels like iterators to me |
03:07:11 | leorize | yea, they're implemented with closure iterators |
03:07:34 | leorize | you can use `macros.dumpMacro` to see what async generates |
03:07:38 | ryukoposting | aaaah makes sense |
03:07:49 | ryukoposting | dumpAstGen is a hell of a drug |
03:09:08 | rayman22201 | I came to Nim for the macros and type system as well |
03:10:30 | ryukoposting | I wish type-safe variants were a bit cleaner, but that's my only complaint with the type system |
03:10:57 | ryukoposting | I love the square brackets instead of <this garbage> |
03:12:37 | * | ng0_ quit (Quit: Alexa, when is the end of world?) |
03:14:47 | rayman22201 | lol. I 100% agree on both counts. |
03:17:13 | * | oculux quit (Quit: blah) |
03:18:18 | * | oculux joined #nim |
03:20:03 | * | Jjp137 joined #nim |
03:21:09 | * | banc joined #nim |
03:22:04 | * | vlad1777d quit (Ping timeout: 250 seconds) |
03:26:01 | * | vlad1777d joined #nim |
03:31:05 | * | vonHabsi_ quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
03:31:30 | * | vonHabsi_ joined #nim |
03:32:10 | vonHabsi_ | test message |
03:33:04 | * | vonHabsi_ quit (Client Quit) |
03:33:50 | * | vonHabsi_ joined #nim |
03:36:24 | * | vonHabsi_ quit (Client Quit) |
03:36:49 | * | vonHabsi_ joined #nim |
03:37:09 | ryukoposting | test succeeded? |
03:40:08 | * | lritter quit (Ping timeout: 246 seconds) |
03:40:57 | * | lritter joined #nim |
03:50:43 | * | zachk quit (Quit: Leaving) |
03:52:40 | * | abm quit (Quit: Leaving) |
04:18:04 | * | vlad1777d quit (Remote host closed the connection) |
04:20:04 | * | vlad1777d joined #nim |
04:37:25 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
04:42:42 | * | theelous3 joined #nim |
04:57:51 | FromGitter | <adrianperreault> Has adding a theme to the Nim subreddit been suggested? Perhaps something along these lines? ⏎ ((https://imgur.com/a/cjKkGsa)) |
05:20:48 | * | theelous3 quit (Ping timeout: 250 seconds) |
05:39:28 | * | al1ranger joined #nim |
05:40:22 | * | nsf joined #nim |
05:57:28 | * | darithorn quit (Read error: Connection reset by peer) |
06:00:19 | * | ikan-keli joined #nim |
06:02:45 | * | narimiran joined #nim |
06:05:52 | * | dddddd quit (Remote host closed the connection) |
06:17:36 | * | ikan-keli_ joined #nim |
06:17:42 | * | ikan-keli quit () |
06:38:13 | * | al1ranger quit (Remote host closed the connection) |
06:39:31 | * | al1ranger joined #nim |
06:40:53 | ikan-keli_ | hi |
06:42:38 | narimiran | hi |
06:44:35 | * | al1ranger quit (Ping timeout: 246 seconds) |
07:32:33 | FromGitter | <gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c42d2910a491251e31e158e] |
08:00:00 | * | gmpreussner quit (Quit: kthxbye) |
08:04:35 | * | gmpreussner joined #nim |
08:06:27 | * | leorize quit (Ping timeout: 252 seconds) |
08:12:56 | * | cspar joined #nim |
08:17:30 | FromGitter | <alehander42> i agree with @dom96 rust just doesnt make a lot of sense for web/backend to me |
08:18:31 | FromGitter | <alehander42> the think-about-lifetime overhead isn't worth it at all for the minimal perf/memory + (which is nothing compared to other variables there) |
08:29:20 | * | leorize joined #nim |
08:39:52 | * | platoff joined #nim |
09:00:34 | * | Vladar joined #nim |
09:02:21 | * | platoff quit (Read error: Connection reset by peer) |
09:53:15 | * | zyklon joined #nim |
09:59:12 | * | enow joined #nim |
10:02:31 | * | cspar_ joined #nim |
10:03:48 | * | cspar quit (Ping timeout: 245 seconds) |
10:29:19 | FromGitter | <gogolxdong> occasionally occurs Tip: 8 messages have been suppressed, use --verbose to show them. ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c42fbfe8ce4bb25b8d6daf8] |
10:29:28 | FromGitter | <gogolxdong> when nimble install |
10:30:32 | FromGitter | <gogolxdong> haven't got a fixed solution to fix. |
10:31:32 | FromGitter | <timotheecour> where can i find precompiled nim binary for OSX or linux ? it’s for CI |
10:40:01 | * | solitudesf joined #nim |
10:44:05 | Zevv | https://github.com/nim-lang/nightlies/releases? |
10:44:16 | Zevv | oh that's source, sorry |
10:48:11 | FromGitter | <timotheecour> it’s actually confusing: why is `nim-0.19.9-osx.tar.xz` only source, no binary? and if it’s only source, why have both `nim-0.19.9-osx.tar.xz` and `nim-0.19.9-windows_x64.zip` ? |
10:54:28 | * | narimiran quit (Ping timeout: 250 seconds) |
10:58:52 | * | kobi7 quit (Quit: Leaving) |
11:01:44 | Zevv | windows version is binary, right? |
11:02:42 | FromGitter | <timotheecour> correct, that’s the only 1 i didnt’ try, but just vertified, yes |
11:02:55 | FromGitter | <timotheecour> So looks like a bug for OSX/linux then? |
11:03:46 | Zevv | I have no clue. I'm tryin to understand the difference between the mac and linux version first |
11:03:59 | Zevv | and now I realize I have no clue how the csources bootstrapping works |
11:05:32 | FromGitter | <timotheecour> any specific question? |
11:05:55 | Zevv | I should be able to figure it out, but I was wondering what all the numbered subdirectories with C code are |
11:06:11 | Zevv | and I recently pushed a PR which breaks because the C sources in CI are too old it seems |
11:06:29 | Zevv | so probably pays to figure out how this all works |
11:06:29 | FromGitter | <timotheecour> i believe that’s de-duplication (maybe to cover different platforms) but i’m not 100% sure |
11:06:47 | FromGitter | <timotheecour> ya id be curious to know as well |
11:06:54 | Zevv | From waht I can diff here the nightlies linux and macos are identical, apart from paths and timestamps |
11:07:10 | FromGitter | <timotheecour> ok so that’s a bug, i’ll file it |
11:08:43 | FromGitter | <timotheecour> https://github.com/nim-lang/nightlies/issues/18 |
11:09:12 | Zevv | I don't think that's a bug |
11:09:13 | Zevv | "he Windows zips contain platform specific binaries whereas the the Linux and OSX archives contain pre-packaged source that can be used to build Nim on Linux, OSX and even Windows." |
11:09:31 | Zevv | shipping binaries for linux is always problematic |
11:10:14 | FromGitter | <timotheecour> right... |
11:10:33 | FromGitter | <timotheecour> so back to my original question then: is there an easy way to get osx binaries for latest release ? |
11:10:39 | Zevv | :) |
11:10:40 | FromGitter | <timotheecour> that’s for speeding up CI |
11:14:55 | * | stefanos82 joined #nim |
11:15:40 | FromGitter | <timotheecour> > shipping binaries for linux is always problematic ⏎ ⏎ but not on OSX though |
11:16:02 | FromGitter | <timotheecour> > whereas the the Linux and OSX archives contain pre-packaged source that can be used to build Nim on Linux, OSX and even Windows ⏎ ⏎ do u know what exactly that means? |
11:16:51 | FromGitter | <timotheecour> does that it allows cross compiling from, say host=osx to target=windows? |
11:22:48 | * | nc-x joined #nim |
11:23:27 | nc-x | @timotheecour it probably means that it contains the complete source+csource which can then be used on windows/linux/macos for building nim |
11:23:58 | nc-x | like you usually do by cloning with git |
11:24:13 | nc-x | just that, now you have an archive file |
11:35:27 | * | lritter quit (Ping timeout: 240 seconds) |
11:35:54 | federico3 | sorry Araq, is this comment still valid? install.sh is currently installing the "compiler" directory https://github.com/nim-lang/Nim/issues/4866#issuecomment-271194805 |
11:37:54 | * | Trustable joined #nim |
11:38:16 | FromGitter | <timotheecour> @nc-x ok thx for clarification; so do u know of a way to get binaries for linux (say ubuntu) for latest release? |
11:39:41 | FromGitter | <timotheecour> ditto w OSX (note, on OSX, `brew install nim`uses bottle install so it’s a maybe good enough workaround, but still, i’d assume there shd be osx binaries for latest release *somewhere* ; ) |
11:40:41 | federico3 | timotheecour: https://packages.debian.org/sid/nim |
11:40:56 | leorize | federico3: it's still valid |
11:41:25 | leorize | just that now you have the compiler package pre-installed instead |
11:41:55 | leorize | the sad part is that nimble doesn't know this so it'd still try to download one to your user directory |
11:42:13 | federico3 | leorize: so we should open a bug to change install.sh to stop installing that directory |
11:42:43 | leorize | I found installing that directory useful |
11:43:02 | leorize | I can compile nimble outside of Nim source code and it'd still work well |
11:43:08 | FromGitter | <timotheecour> @federico3 thanks! that answers for linux; do u know for osx (besides `brew install osx` which does use a bottle ) |
11:43:24 | federico3 | but the comment says that other tools should use the *compiler Nimble package* |
11:44:41 | * | cspar joined #nim |
11:44:44 | leorize | the compiler Nimble package might be too new/old and those tools wouldn't work well with the installed stdlib |
11:44:57 | leorize | and besides, it wasn't installing the compiler directory |
11:45:06 | leorize | it was also installing compiler.nimble |
11:45:36 | leorize | packagers should place it to the system nimble dir :) |
11:45:51 | leorize | ofc the bad part is still that nimble doesn't support multiple nimble directory |
11:45:54 | federico3 | that sounds like job for a dedicated package |
11:46:04 | * | cspar_ quit (Ping timeout: 246 seconds) |
11:46:04 | federico3 | yep :( |
11:46:16 | leorize | I'll try to tackle that sometime later |
11:46:28 | leorize | it's quite easy to hack in multiple nimble dir support |
11:48:32 | leorize | just that I don't have a good idea on what to do with the current NIMBLE_DIR and friends |
12:02:25 | federico3 | this should be discussed in a dedicated issue on Nimble |
12:04:05 | * | kobi7 joined #nim |
12:04:08 | kobi7 | hi there! |
12:04:39 | kobi7 | is it normal to get index out of bounds error in nativesockets.nim ? |
12:05:18 | kobi7 | I don't know what I'm doing wrong? can I paste a gist for someone to look? |
12:05:38 | Araq | it's definitely not normal :-) |
12:05:54 | Araq | and I think it's always a bug, report it please |
12:06:14 | * | cspar quit (Ping timeout: 246 seconds) |
12:07:50 | kobi7 | I am not entirely sure it's from that location. Here's what I did: https://gist.github.com/kobi2187/bfe1fa6a5dc131a17d4fe13123f92cd5 |
12:09:06 | kobi7 | Hey araq, it seems like innocent code. is it working for you? |
12:12:38 | kobi7 | oh, it's in oserr.nim#62 |
12:12:41 | FromGitter | <alehander42> faith |
12:12:45 | FromGitter | <alehander42> so narimiran |
12:12:47 | FromGitter | <alehander42> i am going to |
12:12:59 | FromGitter | <alehander42> keep code blocks for now in jsffi |
12:13:03 | kobi7 | I guess the exception msg was empty |
12:13:12 | FromGitter | <alehander42> as it doesnt make a lot of sense to add runnable |
12:14:22 | kobi7 | Araq: will do. |
12:14:34 | * | nc-x quit (Quit: Page closed) |
12:20:50 | Araq | nim c -d:release --define:nimMinHeapPages=20000 --gc:regions tests/gc/thavlak && time tests/gc/thavlak |
12:20:56 | Araq | nim c -d:release --define:nimMinHeapPages=20000 --gc:boehm tests/gc/thavlak && time tests/gc/thavlak |
12:21:02 | Araq | nim c -d:release --define:nimMinHeapPages=20000 --gc:refc tests/gc/thavlak && time tests/gc/thavlak |
12:21:11 | Araq | nim c -d:release --define:nimMinHeapPages=20000 --gc:markAndSweep tests/gc/thavlak && time tests/gc/thavlak |
12:21:21 | Araq | needs the devel version that I just pushed |
12:21:32 | Araq | it will be interesting to see your results |
12:27:10 | enow | allright so a really really green question |
12:27:33 | enow | what's the relationship between C arrays / pointers and nim sequences and or arrays |
12:27:48 | enow | I'm really struggling even though I'd thought this be simple |
12:28:16 | enow | so I have a JSAMPROW with pixels which in C would be: unsigned char **pixbuf |
12:29:08 | enow | can I allocate the memory as a sequence and then use .addr and cast to send it to the C side of things? |
12:29:14 | Araq | yup |
12:29:27 | Araq | addr myseq[0] |
12:30:52 | enow | okay and if I want to create a 2 dimensional array, can I do a seq[HEIGHT,seq[WIDTH,cuchar]] |
12:31:05 | enow | or how does that work |
12:31:53 | Araq | 2 dimensional array would be newSeq[T](M*N); addr myseq[0] |
12:32:08 | Araq | ensure you don't use seq of seq for this. |
12:32:09 | Araq | bbl |
12:32:12 | enow | mkay |
12:32:23 | enow | thanks a bunch!! |
12:33:10 | kobi7 | Araq: https://github.com/nim-lang/Nim/pull/10381 |
12:40:27 | kobi7 | I am still not sure how to debug nim in vscode |
12:42:53 | kobi7 | tiny change btw. I don't know if it's breaking some assumption (that is, supposed to fail on linux error code 0) |
12:43:17 | kobi7 | well, I guess it would have been explicit with an assert or something |
12:45:12 | * | vlad1777d quit (Remote host closed the connection) |
12:47:12 | * | vlad1777d joined #nim |
12:48:35 | kobi7 | How does one check for an open port? is it enough to do try: socket.connect(host,port); return true except: return false finally: socket.close |
12:48:36 | kobi7 | ? |
12:48:57 | * | vlad1777d quit (Remote host closed the connection) |
12:51:23 | * | vlad1777d joined #nim |
13:01:16 | * | cspar joined #nim |
13:01:43 | * | kobi7 quit (Quit: Leaving) |
13:02:50 | * | dddddd joined #nim |
13:12:11 | enow | kobi7 wouldn't know in nim specifically but it seems to make sense |
13:15:41 | enow | kobi7 could you share the source code?? |
13:23:44 | FromGitter | <kaushalmodi> @timotheecour , Zevv: (about archives on nightlies) the Linux and macOS archives are the same, but they each get deployed only after they pass koch testinstall on the respective OSes. |
13:24:42 | FromGitter | <kaushalmodi> And yes, the Windows archive is a different animal altogether, that packs the binary, and koch testinstall doesn't run on that one. |
13:26:11 | FromGitter | <kaushalmodi> It would be nice to get binaries for Linux and macOS too, but someone working on that needs to ensure to create those for multiple architectures and OS flavors. |
13:36:39 | FromGitter | <timotheecour> actually `sudo apt-get install nim` installs a really old nim: 0.12 |
13:37:12 | FromGitter | <timotheecour> so i still don’t know how to get latest release for nim without building it (for CI) |
13:37:21 | FromGitter | <timotheecour> on ubuntu, say |
13:37:38 | * | skellock joined #nim |
13:38:54 | skellock | good saturday morning nimfolk! |
13:40:03 | skellock | what's everyone hacking on this weekend? (i'm doing random cli stuff) |
13:43:02 | * | zyklon quit (Ping timeout: 250 seconds) |
13:46:59 | * | cspar_ joined #nim |
13:47:13 | enow | skellock: plugging my software keyboard thingy into the os via websocket and json |
13:47:38 | enow | skellock: got sidetracked and wanted mjpeg output so that it can serve as a shitty html-vnc replacement |
13:47:56 | enow | skellock: so working on accessing libjpeg from nim in my wine setup |
13:49:29 | * | cspar quit (Ping timeout: 246 seconds) |
13:49:31 | skellock | enow: oh wow, that's cool |
13:52:23 | enow | skellock: if you like black and white images :D somehow the colorspace is getting messed up |
13:52:59 | enow | I'm working without proper debugging because it's such a mess to set it up through 2 languages and 2 operating systems and wine and whatnot |
13:53:30 | enow | the irony is that nim interop is a patch away from doing all of this automagically but I'm learning a lot |
13:55:43 | FromGitter | <kaushalmodi> this weekend, I hope to create a wrapper around a .h file in Nim |
13:55:48 | FromGitter | <kaushalmodi> does anyone have tips? |
13:56:09 | FromGitter | <kaushalmodi> I don't know C, so it's going to take me few trials and errors to get it right |
13:56:11 | leorize | c2nim it first, then start from there |
13:56:18 | FromGitter | <timotheecour> (and nimterop) |
13:56:32 | leorize | the C people use in headers is simple, don't worry :P |
13:56:34 | FromGitter | <kaushalmodi> I need to just create a .h file wrapper |
13:56:51 | FromGitter | <kaushalmodi> not translate C to nim |
13:57:14 | FromGitter | <timotheecour> ya, nimterop or c2nim shd help |
13:57:46 | * | cspar_ quit (Ping timeout: 250 seconds) |
13:57:50 | FromGitter | <kaushalmodi> thanks, will read up on that |
13:58:37 | leorize | some progress with nimsuggest highlighting: https://asciinema.org/a/pDWdE4ZSuW0TcNhfnIISgoIec |
13:58:47 | leorize | it highlight while you type! |
13:59:16 | FromGitter | <kaushalmodi> leorize: nice! |
13:59:21 | FromGitter | <timotheecour> Cool! |
13:59:51 | * | zyklon joined #nim |
14:00:17 | FromGitter | <timotheecour> would be great to integrate in sublime text (which used to use nimsuggest but stopped because of number of bugs, a number of which were fixed in meantime) |
14:00:55 | * | narimiran joined #nim |
14:01:02 | leorize | I'm fixing a lot of those highlighting bug atm |
14:01:18 | leorize | mostly boils to lineinfo errors |
14:04:45 | Zevv | leorize: what's under your vim here? |
14:05:17 | leorize | what do you mean? |
14:05:30 | Zevv | what plugin is handling the nimsuggest <-> vim? |
14:05:48 | leorize | my own homegrown plugin :) |
14:05:54 | leorize | I'll publish it soon-ish |
14:05:56 | Zevv | share please! |
14:06:08 | skellock | leorize: now-ish!!! <3 |
14:06:20 | Zevv | yesterday-ish! |
14:06:25 | * | Zevv <- eager beta tester |
14:08:49 | federico3 | leorize: alpha version is better than no version |
14:09:13 | leorize | I'm doing the clean-up now, please wait :P |
14:11:45 | Zevv | do you also handle indenting and jump-to-definition? |
14:11:54 | leorize | indenting, yes |
14:12:00 | leorize | everything else, no :P |
14:12:09 | leorize | I've only done writing the highlighter interfacing part |
14:12:52 | Zevv | I've tried the various vim/nim things available, but they're all long unsupported and not quite stable |
14:13:31 | Zevv | and the autocompletions popping up, is that triggereed by nimsuggest as well? |
14:13:47 | leorize | told you, I've only done the highlighter :P |
14:13:58 | leorize | that's the basic keyword completion in vim |
14:14:50 | Zevv | oh yeah I noticed, I thougt it came up with `mod` and `add` itself, but it was only the second round :) |
14:17:33 | leorize | note, you'd need nimsuggest in devel to use this plugin |
14:17:50 | Zevv | I run devel, but what's new in nimsuggest then? |
14:18:49 | leorize | --autobind |
14:19:05 | leorize | which offload the port picking work to nimsuggest |
14:19:16 | Zevv | ah ok |
14:22:37 | FromGitter | <kaushalmodi> an attempt at nimterop failed |
14:22:55 | FromGitter | <kaushalmodi> if anyone is interested in looking at the issue, I opened it here: https://github.com/genotrance/nimterop/issues/47 |
14:26:55 | leorize | Zevv: https://github.com/alaviss/nim.nvim |
14:27:08 | leorize | patches are not welcomed atm :P |
14:27:25 | leorize | I might redesign the internals soon |
14:27:33 | FromGitter | <kaushalmodi> c2nim fails at parsing this svdpi.h: https://ptpb.pw/9z4q/c |
14:27:49 | FromGitter | <kaushalmodi> svdpi.h(19, 34) Error: token expected: ; |
14:28:08 | FromGitter | <kaushalmodi> it's this line: `typedef unsigned __int64 uint64_t;` |
14:30:37 | * | enow quit (Remote host closed the connection) |
14:34:03 | * | cspar_ joined #nim |
14:38:45 | Calinou | I got my Nim t-shirt yesterday :) |
14:38:53 | Calinou | it looks cool |
14:38:56 | * | cspar_ quit (Ping timeout: 250 seconds) |
14:44:48 | leorize | Zevv: have you tested it? |
14:46:34 | * | Trustable quit (Remote host closed the connection) |
14:47:31 | * | Trustable joined #nim |
14:48:03 | * | cspar joined #nim |
14:48:33 | FromGitter | <zacharycarter> slightly OT - so please reply in OT - got my PC build sorted out (I think) thanks to a lot of feedback from Mamy and Vindaar and others yesterday: https://pcpartpicker.com/user/zacharycarter/saved/d2J3bv |
14:48:52 | FromGitter | <zacharycarter> would love any final look overs / suggestions - about to start ordering pats |
14:49:35 | * | Vladar quit (Remote host closed the connection) |
14:51:49 | shashlick | @kaushalmodi will check but try zestyr's suggestion in the issue |
14:52:03 | shashlick | Might be some define that needs to be set |
14:52:28 | shashlick | Need better error message highlighting in cimport |
14:55:24 | * | cspar quit (Ping timeout: 250 seconds) |
14:55:29 | Calinou | @zacharycarter how do I reply in OT? |
14:55:53 | FromGitter | <zacharycarter> Calinou: I think you'd need to join #nim-offtopic if you're on IRC |
14:55:58 | Calinou | right |
14:56:02 | FromGitter | <zacharycarter> if you're on gitter - the channel is named nim-lang/twitch |
15:00:46 | * | cspar joined #nim |
15:07:20 | * | abm joined #nim |
15:07:34 | * | Snircle joined #nim |
15:19:48 | * | enow joined #nim |
15:25:29 | * | darithorn joined #nim |
15:29:27 | zestyr | shashlick: might have discovered another tree-sitter bug :) |
15:30:52 | shashlick | :) |
15:32:14 | shashlick | Yep yet another syntax extension |
15:32:58 | * | cspar quit (Ping timeout: 245 seconds) |
15:33:20 | shashlick | Need to post that tree sitter bug here - https://github.com/tree-sitter/tree-sitter-cpp/issues |
15:34:03 | shashlick | Meanwhile you can work around it by defining those types in the Nim file before cimport |
15:37:33 | FromGitter | <kaushalmodi> shashlick: Does it mean that if I get "Error: undeclared identifier: 's_vpi_vecval'", I need to define a Nim `object` mirroring that struct, before cImport? |
15:37:52 | FromGitter | <kaushalmodi> \* `object` type |
15:37:53 | zestyr | shashlick: opened an issue |
15:39:41 | zestyr | kaushalmodi: can you change the issue title? |
15:41:09 | FromGitter | <kaushalmodi> zestyr: I did .. I hope I got that right |
15:42:33 | zestyr | thanks :) |
15:43:27 | * | Geezus42 quit (Ping timeout: 240 seconds) |
15:43:57 | enow | no problems with try {} catching out of bounds exceptions right? |
15:45:11 | shashlick | Ya simply hand wrap anything that gets missed and you can proceed @kaushalmodi |
15:45:29 | shashlick | Doesn't matter that tree sitter or nimterop don't understand it |
15:47:11 | shashlick | Meanwhile better to change the issue title to say that error in preprocessor isn't obvious at all |
15:47:42 | shashlick | Need to improve that so that you can figure out next step without having to run toast manually |
15:47:44 | * | Geezus42 joined #nim |
15:48:27 | zestyr | an error for "toast not in path" would also be nice, "exitCode == 0" threw me off at first |
15:50:04 | zestyr | hmm nevermind I guess, in my case toast was another program, and kaushal had some gcc issue, so maybe that's not the case anyway |
15:51:44 | * | skellock quit (Ping timeout: 244 seconds) |
15:53:40 | Zevv | leorize: back; looking at your plugin I see its neovim, not vim |
15:56:26 | * | skellock joined #nim |
15:57:40 | shashlick | Nice leorize - I might consider neovim again |
16:00:34 | FromGitter | <kaushalmodi> shashlick: I finally got it working, with that minor workaround, yay! |
16:00:35 | FromGitter | <kaushalmodi> thanks |
16:01:02 | FromGitter | <kaushalmodi> .. and then I find that the systemverilog tool I am using hasn't implemented that DPI function :P |
16:01:04 | FromGitter | <kaushalmodi> > xmsim: *W,NOIMPL: This function svDpiVersion of DPI API is not implemented yet. |
16:01:28 | FromGitter | <xmonader> Looks like Nim made it to Derek Banas short list! |
16:01:53 | FromGitter | <kaushalmodi> shashlick: another 101 question. I have: ⏎ ⏎ ```type ⏎ s_vpi_vecval = object ⏎ aval: uint32 ⏎ bval: uint32``` [https://gitter.im/nim-lang/Nim?at=5c4349f1ba355012a4646538] |
16:02:07 | FromGitter | <kaushalmodi> do I need importc somewhere in there? |
16:02:19 | FromGitter | <kaushalmodi> actually exportc? |
16:05:28 | shashlick | Ya the * |
16:05:45 | shashlick | And then importc with the struct name equivalent in C |
16:15:04 | leorize | Zevv: yea, only neovim got the required async facilities |
16:15:51 | Zevv | well, finally a reason to consider switching |
16:16:24 | solitudesf | vim has async too now, or is it not functionally equivalent? |
16:18:23 | leorize | not functionally equivalent |
16:18:33 | leorize | vim don't have async semantic highlighting functions |
16:18:35 | * | federico3 quit (Remote host closed the connection) |
16:18:57 | leorize | also I need the tcp sockets from neovim to talk to nimsuggest properly |
16:20:28 | * | skellock quit (Ping timeout: 245 seconds) |
16:27:32 | * | federico3 joined #nim |
16:46:35 | * | xet7 quit (Ping timeout: 268 seconds) |
16:54:28 | * | dom96_w joined #nim |
16:58:14 | * | xet7 joined #nim |
17:17:36 | * | d10n-work joined #nim |
17:25:58 | * | skellock joined #nim |
17:29:53 | * | dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
17:30:01 | * | cspar joined #nim |
17:41:36 | dom96 | What a difference 10 years makes https://twitter.com/nim_lang/status/1086679947907756032 :) |
17:43:15 | * | memeboi joined #nim |
17:50:19 | * | skellock quit (Quit: WeeChat 2.3) |
17:54:24 | * | PMunch joined #nim |
18:01:36 | federico3 | there was already a roadmap for 1.0 ?! :( |
18:02:19 | narimiran | yeah, that doesn't look good |
18:06:12 | FromGitter | <kaushalmodi> honestly 2009 website seems to have more material |
18:06:26 | FromGitter | <kaushalmodi> 2019 website has a lot of whitespace |
18:07:36 | PMunch | That's what's trendy |
18:07:52 | PMunch | And part of the reason why I hate on-line chat applications in 2019 |
18:08:14 | PMunch | With HexChat and most other IRC clients it fills my entire screen with text, which is what I'm interested in |
18:08:27 | PMunch | I'm not interested in only the last three messages and tons of whitespace.. |
18:08:40 | dom96 | Perhaps I should have just included the above the fold content |
18:08:41 | dom96 | hmmm |
18:09:54 | * | so quit (Ping timeout: 246 seconds) |
18:10:09 | * | so joined #nim |
18:10:17 | PMunch | Oh don't get me wrong, I really like the new Nim site |
18:10:55 | PMunch | And if you click through to articles you have more or less what was on the 09 site. |
18:11:22 | PMunch | Oh wait no, I was thinking of the side-bar |
18:11:51 | PMunch | I guess the "Learn More" link takes you to something like the 09 site |
18:11:57 | * | Vladar joined #nim |
18:14:35 | * | s3govesus joined #nim |
18:17:59 | * | calebwin[m] joined #nim |
18:26:18 | * | cspar quit (Ping timeout: 245 seconds) |
18:27:56 | * | memeboi quit (Quit: Page closed) |
18:28:40 | * | narimiran quit (Remote host closed the connection) |
18:38:51 | FromGitter | <kaushalmodi> dom96: The way you compared the screenshots makes the current site look bad |
18:39:14 | FromGitter | <kaushalmodi> you should show how each section in current page unfolds to more useful content |
18:42:35 | dom96 | I can't do that easily, unless you have some ideas :/ |
18:42:44 | dom96 | Maybe I should just delete it, it's a silly meme anyway |
18:43:57 | FromGitter | <kaushalmodi> yeah .. |
18:44:49 | dom96 | Argh, it'll be pretty visible if I delete it I think |
18:46:23 | FromGitter | <kaushalmodi> there's another way |
18:46:39 | FromGitter | <kaushalmodi> i don't know how to took those long screenshots |
18:46:41 | * | zachk joined #nim |
18:47:05 | FromGitter | <kaushalmodi> but take one each from https://nim-lang.org/features.html, https://nim-lang.org/blog.html, https://nim-lang.org/learn.html and stitch them side by side |
18:47:12 | * | dddddd quit (Remote host closed the connection) |
18:49:40 | * | Perkol joined #nim |
18:51:55 | * | dddddd joined #nim |
18:52:05 | dom96 | I don't think that would work |
18:53:11 | * | nsf quit (Quit: WeeChat 2.3) |
18:54:26 | PMunch | Just leave it up, I don't think it looks that bad |
18:54:38 | FromGitter | <kaushalmodi> I replied to your tweet |
18:54:54 | PMunch | I mean graphically it's pretty obvious which site is better. And visiting the site shows how complete the content is |
18:55:36 | Araq | the old website was nice too. |
18:58:28 | * | hoijui joined #nim |
19:00:27 | * | Perkol quit (Remote host closed the connection) |
19:01:06 | * | Geezus42 quit (Ping timeout: 268 seconds) |
19:02:52 | * | Geezus42 joined #nim |
19:04:45 | * | zachk quit (Changing host) |
19:04:45 | * | zachk joined #nim |
19:07:52 | FromGitter | <Bennyelg> actual size is 5 but when I get the return students from proc I get 10 ⏎ any idea what's wrong ? ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c43758820b78635b64d5aeb] |
19:09:38 | * | cspar joined #nim |
19:09:42 | FromGitter | <Bennyelg> proc all ⏎ ⏎ ```let students = getStudentsByInstructorId(conn, 12, 5, 0) ⏎ ``` [https://gitter.im/nim-lang/Nim?at=5c4375f69bfa375aab297b1e] |
19:11:38 | FromGitter | <Bennyelg> ```var students: seq[JsonNode] = @[]``` ⏎ ⏎ this works. [https://gitter.im/nim-lang/Nim?at=5c43766acb47ec30006cfbac] |
19:21:37 | dom96 | Why are you calling insert instead of 'add'? |
19:22:16 | FromGitter | <Bennyelg> donnu :| entering now the docs to see the difference , sorry for ignorance :| |
19:22:56 | FromDiscord_ | <exelotl> it's actually really hard to find out that `add` is what you should call in order to append an item to a seq... |
19:23:22 | FromDiscord_ | <exelotl> a few months ago I wanted to find this out but there's just no obvious place to look for it |
19:23:51 | dom96 | Indeed |
19:24:02 | dom96 | It would really be helpful if we could split up system.nim conceptually at least |
19:24:22 | dom96 | and have system/seq.html with all the sequence operations + some intro into what a seq is |
19:24:23 | FromGitter | <Bennyelg> Can someone explain to me? since I am not find this in the docs :/ |
19:24:26 | * | dom96 creates that issue |
19:24:56 | FromGitter | <Bennyelg> inserts `item` into `x` at position `i` |
19:24:58 | FromGitter | <Bennyelg> ok got it |
19:25:09 | dom96 | yeah, insert is inefficient |
19:25:14 | dom96 | but it shouldn't be doubling your count |
19:25:18 | dom96 | Might be a bug in insert |
19:25:23 | dom96 | try reproducing it with a simpler example |
19:25:28 | FromGitter | <Bennyelg> checking right now |
19:26:15 | FromGitter | <Bennyelg> @dom96 nop. its the same |
19:27:45 | federico3 | https://github.com/nim-lang/Nim/issues/2809 has this been implemented? The bug was closed but I'm not seeing a safety define |
19:30:10 | Araq | 'add' is covered in tutorial 1 |
19:30:16 | dom96 | https://github.com/nim-lang/Nim/issues/10385 |
19:30:45 | Araq | federico3: duplicate of the "Nim is unsafe RFC" |
19:30:51 | dom96 | Araq: Yes, but even so it's good to have a dedicated place to document every aspect of something as important as `seq` |
19:31:16 | dom96 | I think my plan could work and shouldn't be too much work |
19:31:27 | FromGitter | <Bennyelg> And what about the issue I mention above? about adding with newSeqJsonNode (size) returns double size ? |
19:31:49 | Araq | I dunno. If you don't know 'add' why do you know 'if'. |
19:32:05 | dom96 | It's not just about 'add' |
19:32:24 | FromGitter | <Bennyelg> Araq conceptually what do you understand from 'insert' and 'add' |
19:32:45 | dom96 | Bennyelg: do you have a small reproduction? |
19:33:09 | FromGitter | <Bennyelg> @dom96 of the bad return size? yea |
19:33:12 | Araq | it's about 'add'. about what else would it be? |
19:35:11 | dom96 | Araq: It's about making the documentation easier to browse and digest |
19:35:30 | dom96 | system.html is far too long |
19:36:25 | FromGitter | <Bennyelg> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c437c3995e17b452579a5c1] |
19:37:10 | dom96 | Bennyelg: oh, you're creating a seq that has 5 items |
19:37:12 | dom96 | then adding 5 more items |
19:37:16 | dom96 | that's why the size is different |
19:37:26 | leorize | Araq: for ident like: "`$`", would you like nimsuggest to just highlight the "$" or the entire thing? |
19:37:34 | FromGitter | <Bennyelg> so if i do so i need insert(x, position) ? |
19:37:51 | dom96 | then you're also inserting a new item |
19:38:02 | dom96 | if you want to replace an item then do seq[position] = x |
19:38:12 | FromGitter | <Bennyelg> I now understand this call is initialize empty seq |
19:38:14 | FromGitter | <Bennyelg> :/ |
19:38:15 | FromGitter | <Bennyelg> ok |
19:38:29 | dom96 | I gotta go. Time to head to the airport, see you guys |
19:38:39 | FromGitter | <Bennyelg> bye thanks. |
19:40:12 | FromGitter | <Bennyelg> What is the different between `var s: seq[int]` and `var s: seq[int] = @[] |
19:40:21 | Zevv | Araq: I have a PR that bounces in travis, seemingle because the nim built from the C sources can not cope with a sizeof() in my patch. Is there something I can do to make this work? (#10338) |
19:42:20 | Zevv | dom96: system.html also has no structure at all and would benefit greatly from some kind of categorization |
19:42:57 | Zevv | Theres quite a lot of things I learned just from reading it top to bottom, but it is hard to find the gems between the trivialities |
19:56:13 | * | darithorn quit (Quit: Leaving) |
19:56:22 | FromGitter | <iffy> What is this assertion asserting? https://github.com/nim-lang/Nim/blob/devel/lib/system/gc.nim#L174 |
19:57:48 | FromGitter | <iffy> (I mean, in English... I don't understand why my code is failing this assertion or what it's trying to assert) |
20:05:58 | Araq | Zevv: when defined(nimHasalignOf) for when the Nim compiler understands your sizeof |
20:10:29 | * | narimiran joined #nim |
20:13:34 | FromDiscord_ | <exelotl> Bennyelg: there's no difference anymore, since seqs can't be nil in 0.19 |
20:14:06 | FromDiscord_ | <exelotl> so `var s: seq[int]` will be initialised to an empty seq anyway |
20:24:12 | * | miran joined #nim |
20:25:57 | * | nsf joined #nim |
20:26:02 | * | narimiran quit (Ping timeout: 250 seconds) |
20:26:51 | * | miran is now known as narimiran |
20:36:46 | * | d10n-work quit (Quit: Connection closed for inactivity) |
20:39:28 | * | zyklon quit (Quit: WeeChat 1.9) |
20:50:43 | * | nsf quit (Quit: WeeChat 2.3) |
20:51:30 | shashlick | putting a try/except around parseStmt() doesn't allow catching errors |
20:52:53 | * | noonien joined #nim |
20:53:28 | Araq | variant of the "exceptions in os.nim are swallowed", maybe |
20:55:21 | * | noonien is now known as nuunien |
20:56:31 | * | nuunien is now known as noonien |
20:57:55 | shashlick | can you run a nim check on a blob of text or parseStmt output without having to create a file and run gorge |
20:59:47 | * | narimiran quit (Ping timeout: 240 seconds) |
21:01:04 | Araq | there is some way to check parseStmt, iirc |
21:01:09 | Araq | fyi http://homepages.ihug.com.au/~ijoyner/Ian_Joyner/Structured_Programming.html |
21:02:39 | * | quipa joined #nim |
21:06:24 | PMunch | Haha, why is the title of that page just the entire contents? |
21:10:28 | * | Cthalupa- quit (Ping timeout: 245 seconds) |
21:10:50 | shashlick | well parseStmt is supposed to check and raise an error so i don't know if there will be yet another facility |
21:11:36 | * | Cthalupa joined #nim |
21:13:42 | shashlick | Araq: whenever you get a chance, please review nimterop and let me know how it can be better |
21:14:06 | shashlick | i'm getting good feedback from the community but would help to have your thoughts as well |
21:16:21 | Araq | sure thing but I'm busy with "structured" programming |
21:18:14 | Araq | finally understood it :P |
21:28:23 | * | Cthalupa quit (Ping timeout: 245 seconds) |
21:29:41 | * | Cthalupa joined #nim |
21:52:51 | * | hoijui quit (Ping timeout: 264 seconds) |
22:14:39 | * | PMunch quit (Remote host closed the connection) |
22:18:10 | * | oculux quit (Quit: blah) |
22:22:02 | * | Tyresc joined #nim |
22:39:24 | * | stefanos82 quit (Remote host closed the connection) |
22:46:00 | * | Vladar quit (Remote host closed the connection) |
22:50:52 | rayman22201 | @Araq, are you still awake by any chance? |
22:51:04 | Araq | yes |
22:51:42 | rayman22201 | Can you help me understand this situation? https://github.com/nim-lang/Nim/pull/10354#issuecomment-455808937 |
22:52:17 | rayman22201 | sorry. It's much less glamorous than CFG's :/ |
22:53:14 | * | enow quit (Quit: Lost terminal) |
22:53:21 | rayman22201 | am I just using `typeToString` wrong? |
22:54:13 | * | aguspiza quit (Ping timeout: 245 seconds) |
22:55:00 | Araq | I dunno, it's crap. |
22:55:33 | rayman22201 | lmao. Is the PR crap or the proc? |
22:55:52 | Araq | somebody exposed typeToString to Nim's externals (macro system...) and now we're stuck with this clusterfuck of options |
22:56:34 | rayman22201 | Which is why I'm afraid to touch that proc. It's already borderline spaghetti code. |
22:58:35 | Araq | genericParamsToString is wrong |
22:59:59 | rayman22201 | can you elaborate? |
23:00:06 | Araq | instead use typeToString(t, preferDesc) |
23:00:10 | * | oculux joined #nim |
23:00:32 | rayman22201 | I tried that. If you look at the comment, It gives incorrect output |
23:00:44 | rayman22201 | it's broken |
23:00:45 | Araq | and patch typeToString so that 'preferDesc' renders tyGenericBody as T[U, V] and not as T |
23:01:02 | rayman22201 | ok. So I should patch the mode. That is a bug |
23:01:29 | rayman22201 | I can do that. cool |
23:01:31 | Araq | preferDesc is hardly used, I don't think you can break much with it |
23:02:01 | Araq | and well "bug" ... it's not specified |
23:02:17 | rayman22201 | Good to know. That gives me more confidence to change it. |
23:02:46 | rayman22201 | I am being conservative. It was meant to be a small PR. I don't want to accidentally break all the things. |
23:02:47 | Araq | we have tests that cover most of typeToString's expected behaviour |
23:03:51 | Araq | and the rest of the spec is just "render it nicely as you see fit" |
23:03:51 | rayman22201 | great. Thank you |
23:04:12 | rayman22201 | lol. ok |
23:29:35 | * | Trustable quit (Remote host closed the connection) |
23:50:34 | * | vlad1777d quit (Ping timeout: 250 seconds) |