| 00:03:30 | * | Hideki_ joined #nim |
| 00:05:00 | FromDiscord | <SolarOmni> Think I'm gonna check out SDL2 |
| 00:07:37 | * | Hideki_ quit (Ping timeout: 240 seconds) |
| 00:29:47 | FromDiscord | <SolarOmni> Nimble init isn't working? o.o |
| 00:30:55 | FromDiscord | <SolarOmni> I ran the installer properly and I just checked to make sure the paths were correct |
| 00:34:41 | * | GordonBGood joined #nim |
| 00:40:56 | jken | Does the standard lib have any kind of dynamically allocated ring buffer type? |
| 00:41:13 | jken | or some kind of circule array/seq with a max length |
| 00:41:16 | FromDiscord | <treeform> deque? |
| 00:41:16 | jken | circular* |
| 00:41:23 | disruptek | jken: see lists module. |
| 00:42:15 | FromDiscord | <treeform> maybe this can work for you? https://nim-lang.org/docs/deques.html |
| 00:42:15 | disruptek | you will have to keep track of the length yourself, if you want to put runtime bounds on the ring. |
| 00:42:45 | jken | ah, okay. |
| 00:43:10 | disruptek | trivial to do, of course, just a heads-up that there's no `len` implemented, etc. |
| 00:43:26 | jken | Thanks! |
| 00:44:10 | jken | I think a dequeue suits my needs more |
| 00:44:18 | yumaikas | o/ |
| 00:45:32 | disruptek | thing is, deques aren't linked lists. |
| 00:45:49 | yumaikas | Are they build atop seq? |
| 00:45:52 | disruptek | ie. they aren't circular and they are a seq underneath. |
| 00:46:29 | FromDiscord | <treeform> that's true, but he needed a ring buffer, not a linked circular list. |
| 00:46:38 | yumaikas | Wouldn't index modulus length be enough for a ring buffer? |
| 00:46:38 | jken | I asked for something circular but should have said something with a max length that is filo |
| 00:46:48 | jken | fifo* |
| 00:46:52 | disruptek | ahh, deques are perfect for that. |
| 00:46:57 | jken | no, filo is right |
| 00:47:01 | jken | its late here lol |
| 00:47:16 | disruptek | you're making it feel pretty late here, too. 😁 |
| 00:47:26 | FromDiscord | <treeform> deques can do both, there was and older queue module that did less |
| 00:47:31 | yumaikas | Are there any frameworks for game dev that target nim js at the moment? |
| 00:47:54 | FromDiscord | <treeform> dom96 had some thing, I think a webGL wrapper. |
| 00:48:08 | yumaikas | Hrm... Ok |
| 00:48:20 | yumaikas | Does dom96 do much with Nim these days? |
| 00:48:38 | FromDiscord | <treeform> I think so, he is here everyday. |
| 00:48:58 | yumaikas | Ah, ok |
| 00:49:50 | * | yumaikas needs to send in a PR to clear out the 0.3.0 devel version of nim required on Jester |
| 00:50:14 | * | sz0 joined #nim |
| 00:51:03 | yumaikas | treeform: Mind if I ask what you use Nim for? |
| 00:51:19 | FromDiscord | <treeform> I use it for both work and play. |
| 00:51:36 | FromDiscord | <treeform> I love making stuff at home - mostly game dev related. |
| 00:51:40 | yumaikas | What *sorts* of work and play? |
| 00:51:54 | yumaikas | Fair enough |
| 00:52:02 | FromDiscord | <treeform> At work I do internal data tools. |
| 00:52:13 | yumaikas | Yeah, it seems like it'd be nice for that |
| 00:52:36 | FromDiscord | <treeform> Yeah I think nim is great |
| 00:52:46 | FromDiscord | <SolarOmni> Okay it's working after restarting >_> |
| 00:52:59 | yumaikas | Right now I use it at work for 1) spitting out pretty terminal colors and 2) for a little CLI punch-clock |
| 00:53:16 | FromDiscord | <treeform> thats how it starts |
| 00:53:22 | yumaikas | I made a light-weight wiki in it that I currently use for 3 websites |
| 00:53:39 | FromDiscord | <treeform> neat, did you use markdown for the wiki? |
| 00:53:42 | disruptek | treeform: where in chroma is the code that actually creates the README.md? |
| 00:54:07 | shashlick | will npeg be faster than regex |
| 00:54:15 | disruptek | no. |
| 00:54:18 | FromDiscord | <treeform> disruptek, its a separate tool, https://github.com/treeform/mddoc |
| 00:54:34 | disruptek | treeform: aha! thanks. sorry to interrupt. |
| 00:54:45 | FromDiscord | <treeform> I just go to any of my repos and type `mddoc` and it regens the README.md |
| 00:54:56 | FromDiscord | <SolarOmni> So |
| 00:55:05 | FromGitter | <Vindaar> treeform: I've gotta go to bed now, but it'd be cool if you could take a look at https://github.com/treeform/chroma/issues/5 :) |
| 00:55:11 | FromDiscord | <SolarOmni> Can anyone recommend an IDE for Nim? Or is the extension for VSCode still good? |
| 00:55:12 | FromDiscord | <treeform> I think its nicer to have docs in the read me instead of some other HTML page. Because usually docs are small. |
| 00:55:21 | FromGitter | <Vindaar> good night! |
| 00:55:25 | FromDiscord | <treeform> I use VSCode, I recommend VSCode . |
| 00:55:31 | FromDiscord | <treeform> Vindaar, good night |
| 00:55:40 | FromDiscord | <SolarOmni> alrighty |
| 00:55:44 | FromDiscord | <SolarOmni> Night |
| 00:55:56 | yumaikas | treeform: yessir. I have the code at https://github.com/yumaikas/kbwiki |
| 00:56:02 | yumaikas | night vindaar |
| 00:56:11 | disruptek | shashlick: there are two things that are great about npeg: 1) it's portable nim, and 2) zevv |
| 00:56:44 | yumaikas | As opposed to RE/NRE which are tied to PRCE? |
| 00:56:51 | disruptek | yep. |
| 00:57:29 | yumaikas | They work pretty handy on both windows and linux, which is about as portable as I need right now. |
| 00:57:45 | yumaikas | I suppose when I'm targeting JS I'll need to wrap JS regexen |
| 00:58:47 | disruptek | well, you can't run pcre at compile-time, which is a show-stopper for some applications. that's the main reason i use npeg in openapi. |
| 00:59:08 | yumaikas | good to know |
| 00:59:19 | yumaikas | disruptek: What is openapi? |
| 00:59:31 | disruptek | i'm just saying... some of that portability is in the compile-time "platform." |
| 00:59:44 | yumaikas | yeah, in what nimscript can do |
| 00:59:46 | disruptek | https://github.com/disruptek/openapi |
| 00:59:53 | FromDiscord | <treeform> yumaikas, oh I wrapped JS regexes some place... I think it was like 3 lines of code pretty easy. |
| 01:00:02 | yumaikas | I don't doubt it'd be easy |
| 01:00:29 | yumaikas | Also, does nim just generally have a 40k-ish overhead when compiling to JS (before gziping) |
| 01:00:47 | disruptek | i guess that doesn't say what openapi is. it's a yaml/json format for specifying how to operate web apis. |
| 01:01:29 | FromDiscord | <treeform> yumaikas, 40k sounds big, but if you have tons of types and other stuff I can believe it. |
| 01:02:21 | yumaikas | treeform: I might need to look into it more later, but when I was compiling some stuff to JS, it seemed about that big. It relied on htmlgen, tho |
| 01:05:00 | yumaikas | IDK. I was trying to figure out how to use Karax in the browser, and having a bit of a time with it |
| 01:05:51 | FromDiscord | <treeform> Yeah I don't use Karax, I use my fidget UI library. |
| 01:06:09 | FromDiscord | <treeform> So I don't know if Karax makes it generate a ton of code. You could look at what it is? |
| 01:06:10 | FromGitter | <Willyboar> Yumaikas i have a lib for console color |
| 01:06:46 | yumaikas | treeform: It looked like a lot of code for casting between nim and JS strings? It's been a week or two |
| 01:07:03 | yumaikas | treeform: What is your fidget UI library? |
| 01:07:36 | FromDiscord | <treeform> https://github.com/treeform/fidget |
| 01:08:14 | FromDiscord | <treeform> Its a UI lib I am working on but its not ready yet. I want to target web, windows, macOS, linux, iOS and Android. |
| 01:08:27 | yumaikas | Thats....... ambitious |
| 01:08:42 | yumaikas | *That's |
| 01:09:15 | FromDiscord | <treeform> https://media.discordapp.net/attachments/142827852402917376/624658376068169760/unknown.png?width=1516&height=680 |
| 01:09:19 | yumaikas | Looks like a project that could take 2.5+ years |
| 01:09:22 | * | yumaikas is in IRC |
| 01:09:32 | FromDiscord | <treeform> IRC? |
| 01:09:51 | disruptek | he's the ghost in your machine, brah |
| 01:09:57 | yumaikas | That screencap an example of it working? |
| 01:10:05 | * | yumaikas is now known as yumaikaghost |
| 01:10:06 | FromDiscord | <treeform> It's working for me on windows, mac and web right now. |
| 01:10:17 | FromDiscord | <treeform> Yeah its the thing it can render right now. |
| 01:10:43 | yumaikaghost | treeform: Cool. Do see if you can make datatables, and treeviews. Those are some of the more sticky controls to get right |
| 01:11:15 | yumaikaghost | Well, if you're needing a challenge. You may not, lol |
| 01:11:16 | FromDiscord | <treeform> yumaikaghost, I have no plans on making them part of fidget, sorry! |
| 01:11:54 | * | yumaikaghost is slightly disappointed. Data tables are *handy* to have on hand |
| 01:12:13 | yumaikaghost | Hopefully you at least have text boses |
| 01:12:15 | yumaikaghost | *boxes |
| 01:12:33 | yumaikaghost | Well, at least have them planned |
| 01:13:09 | yumaikaghost | Still, 'grats on getting something to run against windows, mac and web |
| 01:13:12 | FromDiscord | <treeform> yumaikaghost, text box was really hard to make: https://cdn.discordapp.com/attachments/142827852402917376/615585944103288872/2019-08-26_09-38-13.mp4 |
| 01:13:50 | yumaikaghost | Not surprised. Text is *hard* to do well |
| 01:13:55 | FromDiscord | <treeform> yumaikaghost, I implemented my own font stack: https://github.com/treeform/typography |
| 01:15:24 | yumaikaghost | treeform: This work in JS? |
| 01:15:45 | FromDiscord | <treeform> Yes, but in JS I use a HTML textbox. |
| 01:15:51 | yumaikaghost | lol, fair enough |
| 01:15:57 | FromDiscord | <treeform> On other platforms I use openGL. |
| 01:16:01 | yumaikaghost | I was more talking about your font stack |
| 01:16:03 | yumaikaghost | ok |
| 01:16:11 | yumaikaghost | What's the target for this? gamedev? |
| 01:16:19 | FromDiscord | <treeform> No font stack does not work in JS mode. |
| 01:16:27 | FromDiscord | <treeform> Mainly because streams don't work in JS mode. |
| 01:16:36 | FromDiscord | <treeform> Which is getting fixed. |
| 01:17:09 | FromDiscord | <treeform> yumaikaghost, apps and games. I want to target both. |
| 01:17:20 | yumaikaghost | Fair enough |
| 01:18:13 | yumaikaghost | treeform: How hard is it to cross compile OpenGL from Mac to windows, or have you done it? |
| 01:18:56 | yumaikaghost | (Or rather, Nim code that binds to OpenGL) |
| 01:19:17 | FromDiscord | <treeform> To make a good high quality app, you need animations and usually charts and stuff. So they are all pretty graphical. |
| 01:19:20 | * | krux02_ quit (Remote host closed the connection) |
| 01:19:36 | FromDiscord | <treeform> I also want to abandon native look and feel. I think all really well designed apps do that now. |
| 01:19:58 | yumaikaghost | Eh, I do think there's a case for using the native look and feel for some things. |
| 01:20:03 | FromDiscord | <treeform> Cross compiling is too hard. I just use a KVM and switch between machines. |
| 01:20:18 | FromDiscord | <treeform> Nothing beats real hardware... when you are doing graphics you want real hardware. |
| 01:20:23 | yumaikaghost | Fair enough |
| 01:21:03 | FromDiscord | <treeform> Lets see I have 14 apps open |
| 01:21:27 | yumaikaghost | ok.... |
| 01:22:08 | FromDiscord | <treeform> No native look and feel: Chrome, Subline, VS Code, Figma, Cura, Steam, MagixVoxel, and Messanger |
| 01:22:21 | FromDiscord | <treeform> Oh and Discord - no native look and feel. |
| 01:23:11 | yumaikaghost | To be fair, I wasn't saying that it's bad to get away from native look and feel, just that it's a nice default for when you're making something that doesn't need to impress |
| 01:23:17 | FromDiscord | <treeform> The only native look and feel apps I have open are: Commander and File Explorer. |
| 01:23:27 | FromDiscord | <treeform> Commander looks like butt |
| 01:23:39 | FromDiscord | <treeform> I bet it looked more like sublime or some thing |
| 01:23:39 | yumaikaghost | Like when I made a C# app for helping me extract names from SQL files |
| 01:24:07 | FromDiscord | <treeform> The only thing that has OK looking feel is File Explorer by Microsoft that ships with Windows. |
| 01:24:29 | yumaikaghost | Yeah, that looks pretty decent. I think PowerShell ISE ends out looking decent as well. |
| 01:24:31 | FromDiscord | <treeform> Oh Also OBS. It looks ugly. I bet it would look much better if it did not follow the native look and feel. |
| 01:24:41 | yumaikaghost | Notepad++ I'm 50/50 on |
| 01:24:54 | FromDiscord | <treeform> I think the age of Native look and feel is gone. |
| 01:25:02 | FromDiscord | <treeform> If you have an app you want it to have your own brand |
| 01:25:21 | * | yumaikaghost puts Comic Sans *everywhere* |
| 01:26:27 | yumaikaghost | treeform: What do you think of https://feed.junglecoder.com? First website I put together in Nim |
| 01:26:33 | FromDiscord | <treeform> To make an app for non-UI/UX people I would recommend downloading a Figma template. |
| 01:26:41 | FromDiscord | <treeform> And messing with that till you get some thing that looks like what you want. |
| 01:27:04 | FromDiscord | <treeform> There are so many to choose from: https://www.figmafreebies.com/ |
| 01:27:59 | FromDiscord | <treeform> Take some thing like this: |
| 01:28:01 | FromDiscord | <treeform> |
| 01:28:01 | FromDiscord | <treeform> https://cdn.discordapp.com/attachments/371759389889003532/637462404862836736/free-preview800.png |
| 01:28:13 | FromDiscord | <treeform> And shuffle buttons and panels around till you get some thing to look nice. |
| 01:28:20 | FromDiscord | <treeform> Then use my export tool to fidget to make it work. |
| 01:29:20 | * | Hideki_ joined #nim |
| 01:30:00 | yumaikaghost | That might be handy, though it'll probably be a good while before I'm using figma templates |
| 01:31:26 | FromDiscord | <treeform> That's another thing I don't get. We programmers positions divs and buttons by hand in code. We don't do that anywhere else. Do we make 3d models in code? Do we make 2d sprites in code? Do we make sound in code? We used to... but we don't. |
| 01:31:28 | yumaikaghost | (mostly because I'm either working with pre-existing UI at work, or I'm making something where that level of UI isn't a goal) |
| 01:31:42 | FromDiscord | <treeform> I think a time will come where we will not be making UIs in code. |
| 01:31:47 | FromDiscord | <treeform> I want to get there. |
| 01:32:04 | FromDiscord | <treeform> I just want to write the glue between the UI elements, I don't want to positions or layout UI elements in code. |
| 01:32:37 | yumaikaghost | treeform: You ever used Windows Forms? That's GUI layout without code |
| 01:32:52 | yumaikaghost | Having done it both ways, there are tradeoffs |
| 01:33:04 | FromDiscord | <treeform> I used windows forms. I used Visual Basic 1.0 on Win 3.11. It was great for what it did. |
| 01:33:13 | FromDiscord | <treeform> Then it got complex and awkward from there. |
| 01:33:21 | FromDiscord | <treeform> I also used flash, I also used XML. |
| 01:33:23 | yumaikaghost | I think xcode has interfacebuilder |
| 01:33:34 | FromDiscord | <treeform> I also used XCode iOS layout files. |
| 01:34:05 | FromDiscord | <treeform> The main issue they have is that they build their own design tools ... not the tools UI/UX designers wanted to use. |
| 01:34:17 | yumaikaghost | And all of that doesn't fit your vision of UI design? |
| 01:34:28 | FromDiscord | <treeform> The thing with Figma is that many UI/UX designers love it. Whole industry is switching to it from Photoshop/Illustartor/Sketch. |
| 01:34:39 | yumaikaghost | (Also, it sounds like you've been around the blog a couple more times than I have) |
| 01:34:43 | yumaikaghost | *block |
| 01:35:25 | FromDiscord | <treeform> I want to take tool people already use and love, Figma, and make it into a UI builder like WinForms/XML/XCode/Glade ... |
| 01:35:38 | FromDiscord | <treeform> Instead of the other way around. |
| 01:36:11 | yumaikaghost | treeform: You should pitch this to Figma, if you haven't. Sounds like you're part of the way there |
| 01:36:51 | FromDiscord | <treeform> They have an plugin API, that just shipped like a month ago. |
| 01:37:00 | FromDiscord | <treeform> I already made a plugin. |
| 01:37:10 | FromDiscord | <treeform> Before that I was parsing their file format. |
| 01:37:13 | yumaikaghost | Ok |
| 01:37:31 | FromDiscord | <treeform> Figma would not be interested in a Nim tool. |
| 01:37:46 | FromDiscord | <treeform> I bet that would do a UI builder that can build iOS, Android and HTML layout code. |
| 01:37:56 | FromDiscord | <treeform> Some one made a plug in to do Figma -> HTML. |
| 01:38:01 | FromDiscord | <treeform> Some one made a plugin to do Figma -> HTML. |
| 01:40:43 | yumaikaghost | cool |
| 01:42:30 | * | ftsf quit (Ping timeout: 246 seconds) |
| 01:43:35 | yumaikaghost | treeform: Well, interesting to hear about fidget. Is that the main thing you've been working on in Nim then? |
| 01:44:35 | * | yumaikaghost is now known as yumaikas |
| 01:48:27 | * | stefantalpalaru quit (Ping timeout: 246 seconds) |
| 02:02:11 | FromDiscord | <treeform> yumaikaghost, I would not say its the main thing. I work on things that are on top of fidget. |
| 02:02:49 | FromDiscord | <treeform> Those are my main things. Fidget is a library for the main things. |
| 02:33:18 | * | Hideki_ quit (Ping timeout: 268 seconds) |
| 02:38:29 | * | oculuxe joined #nim |
| 02:41:19 | * | oculux quit (Ping timeout: 268 seconds) |
| 02:57:47 | * | GordonBGood quit (Remote host closed the connection) |
| 02:59:10 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 02:59:41 | * | GordonBGood joined #nim |
| 03:00:39 | * | GordonBGood quit (Remote host closed the connection) |
| 03:06:55 | * | traviss quit (Quit: Leaving) |
| 03:15:18 | * | chemist69 quit (Ping timeout: 245 seconds) |
| 03:17:35 | * | chemist69 joined #nim |
| 03:36:58 | FromDiscord | <k1tt3hk4t> are tuples in Nim unboxed? |
| 03:37:12 | FromDiscord | <k1tt3hk4t> that is, is `(int, int)` the same as just having a struct with two integers in it |
| 03:37:18 | FromDiscord | <k1tt3hk4t> or is there some memory allocation going on |
| 03:39:18 | FromDiscord | <treeform> I don't think there is boxing in nim. I feel like it's the same. But I would look at c code to verify. |
| 03:48:04 | * | nif quit (Quit: ...) |
| 03:48:14 | * | nif joined #nim |
| 04:05:10 | * | GordonBGood joined #nim |
| 04:09:18 | FromDiscord | <Rika> ive been wondering if there is a deeper reason to nim disallowing tabs as indentation |
| 04:11:12 | disruptek | i think it's just cause guido regretted allowing them. silly, if you ask me. |
| 04:18:38 | * | chemist69 quit (Ping timeout: 245 seconds) |
| 04:18:45 | FromDiscord | <Rika> but thats guido |
| 04:19:19 | disruptek | yep. |
| 04:20:26 | FromDiscord | <Rika> ive been seeing more people use tabs over spaces because "readability" and "you can configure it in the good editors", but imo i think the fact that spaces are consistent to each editor, and "you can convert space -> tabs and back in the good editors" rebuts the arguments above well |
| 04:20:47 | * | chemist69 joined #nim |
| 04:21:22 | disruptek | i found it hard to row against the current on this one. |
| 04:22:41 | disruptek | it doesn't matter how easy it is to convert, because nim pretty isn't good enough to use against all commits, so you can't just edit in your preferred tabulator mode. |
| 04:23:49 | disruptek | i'll be using https://github.com/disruptek/gully soon and even less interested in `nim pretty` running on my code. |
| 04:29:50 | * | Hideki_ joined #nim |
| 04:33:57 | * | Hideki_ quit (Ping timeout: 240 seconds) |
| 04:41:13 | FromDiscord | <treeform> I think nim made the right choice on not allowing tabs. |
| 05:02:52 | * | fanta1 joined #nim |
| 05:13:54 | shashlick | @disruptek nitely's regex works at compile time |
| 05:14:04 | shashlick | That's all I use these days |
| 05:14:20 | disruptek | oh, that one's pure nim, right? |
| 05:14:36 | shashlick | Yep |
| 05:14:39 | shashlick | Works great |
| 05:15:09 | shashlick | Spent some time optimizing toast, shaved off 20% perhaps |
| 05:15:11 | disruptek | i should take a look. |
| 05:15:27 | shashlick | It's a drop in replacement for pcre |
| 05:16:08 | disruptek | nimterop got such a huge bump that it no longer bothers me. |
| 05:16:23 | shashlick | What kind of bump |
| 05:16:31 | disruptek | problem is, i'm wed to nre api now. |
| 05:16:37 | disruptek | a speed bump. |
| 05:16:58 | shashlick | Well what changed? |
| 05:17:10 | shashlick | I used nre until last year |
| 05:17:21 | shashlick | Moving to regex was not much effort at all |
| 05:17:22 | disruptek | i dunno because you weren't releasing back then. 😁 |
| 05:17:27 | shashlick | Heh |
| 05:17:42 | disruptek | i think it was mostly a caching change. |
| 05:17:54 | shashlick | I didn't release anything for 3 months since getHeader took a long time |
| 05:18:06 | shashlick | Caching had been in place for a long time now |
| 05:18:36 | shashlick | Anyway, as long as it is better now |
| 05:18:46 | shashlick | It's good to see more wrappers showing up |
| 05:19:42 | disruptek | yeah, i just wanna get gully dogfood and then i will go back to golden and make some real progress. |
| 05:20:16 | disruptek | i feel bad for not exploiting nimgit more. 😄 |
| 05:20:57 | shashlick | I want to get thru nested structs but it is a hard problem and I'm a bit tired of struggling |
| 05:21:15 | disruptek | is there a particular wrapper that is blocked? |
| 05:21:40 | shashlick | I really want to start on c++ but until c is smooth, feels like a bad idea |
| 05:22:05 | shashlick | There's always weirdos who like nesting things |
| 05:22:09 | shashlick | Just because |
| 05:22:27 | shashlick | Why would you allow 15k ways to do things |
| 05:22:43 | shashlick | Just makes maintenance a chore |
| 05:22:54 | disruptek | sounds like you are really anxious to add c++, alright. |
| 05:25:32 | shashlick | Well there's so many good c++ libraries out there that are hard to work with |
| 05:27:04 | shashlick | You will always find good stuff since production grade performance = c++ |
| 05:27:32 | shashlick | If you can live in the Nim bubble and leverage such good libs why not |
| 05:27:34 | disruptek | heavier, but yes. |
| 05:28:49 | disruptek | i would love to use the aws cpp api instead of my own crap. |
| 05:29:09 | shashlick | Eventually |
| 05:29:21 | shashlick | I hope to get around to Go and Rust too |
| 05:29:37 | disruptek | yeah, it's ridiculously large. |
| 05:30:07 | shashlick | Let's see, I can aspire, reality can be whatever |
| 05:30:11 | disruptek | go should be pretty easy. |
| 05:30:50 | disruptek | maybe that would be a better choice to do next, as it will grow your model without having so many unbearable challenges. |
| 05:30:57 | shashlick | Well assuming they build libs into dlls or make it relatively easy to do so |
| 05:30:59 | FromDiscord | <Rika> rust tho >_> |
| 05:32:01 | shashlick | Cause tree-sitter can parse all of these and many more langs |
| 05:32:24 | shashlick | But they need to be importc compatible |
| 05:34:02 | shashlick | Most of these newer languages distribute libs as source |
| 05:34:21 | shashlick | Unlike c/c++ which are static or dynamic libs |
| 05:34:34 | shashlick | Things will get harder with GCs as well |
| 05:34:37 | shashlick | Let's see |
| 05:34:59 | disruptek | yeah, my suggestion of dynamic lib use went over like a lead balloon. |
| 05:38:41 | shashlick | Nim or Go |
| 05:38:44 | * | narimiran joined #nim |
| 05:38:55 | disruptek | nim |
| 05:40:50 | * | theelous3_ quit (Ping timeout: 265 seconds) |
| 05:41:52 | shashlick | It's not like rust or go offer it either |
| 05:42:25 | shashlick | Nim has --app:lib and works great |
| 05:42:55 | shashlick | Just that nimrtl isn't heavily tested |
| 05:42:59 | FromDiscord | <treeform> there are some many typescript bindings to js apis. There might be a way to convert them to nim js style things. |
| 05:43:05 | disruptek | well, it was clearly unpopular in the nimble thread where i mentioned it. |
| 05:43:45 | disruptek | treeform: ah that's an interesting angle. |
| 05:45:15 | shashlick | Ya as soon as you want to ship closed source stuff, you get stuck |
| 05:45:35 | * | theelous3 joined #nim |
| 05:45:56 | disruptek | oh, no, this was about dependencies and such. |
| 05:48:25 | shashlick | I vaguely remember the thread |
| 05:49:54 | disruptek | https://github.com/nim-lang/packages/issues/1051 |
| 05:51:05 | * | solitudesf joined #nim |
| 05:51:57 | disruptek | i give up on this stuff, obviously. |
| 05:53:07 | FromDiscord | <treeform> I don't care about releases, git commit hash all the way |
| 05:54:23 | disruptek | well, it'll be a losing battle until the tooling improves. |
| 05:55:05 | disruptek | i'm trying to make nimble work for me, but it's hard. |
| 05:56:04 | * | dddddd quit (Remote host closed the connection) |
| 05:56:24 | FromDiscord | <treeform> i made my own package manager thingy in 200 lines I like: https://github.com/treeform/nimby |
| 05:58:07 | disruptek | honesty, i might use it. |
| 05:58:43 | disruptek | i have to think about this. but not at 2a. bbl 😉 |
| 06:00:51 | shashlick | That thread is exhausting, bed for me too |
| 06:01:43 | FromDiscord | <treeform> I guess I'll go to sleep for solidarity |
| 06:01:53 | shashlick | I'd work more on nimble but it takes too long to be enjoyable |
| 06:02:49 | shashlick | Anyway, point to learn in life is that there is no such thing as perfection so better to figure out how to live with it |
| 06:02:55 | shashlick | L8r |
| 06:06:55 | Araq | treeform: hmm, we could join forces, I made something similar ("nawabs") |
| 06:07:15 | Araq | but it took my more than 200 lines of code. |
| 06:07:23 | Araq | do you evaulate .nimble files? |
| 06:18:02 | * | fanta1 quit (Quit: fanta1) |
| 06:23:10 | * | nsf joined #nim |
| 06:23:10 | FromDiscord | <treeform> I do not evaluate |
| 06:23:28 | FromDiscord | <treeform> I would prefer just json files |
| 06:24:34 | FromDiscord | <treeform> Instead of evaling the nimble file I was thinking maybe regex it? |
| 06:27:12 | FromDiscord | <treeform> The main ideas I wanted to try out were: url based install, always vendor and git submodules |
| 06:28:00 | FromDiscord | <treeform> What ideas you wanted to play with? |
| 06:29:48 | Araq | nimble evaluation is dead simple, you pass 'nim e foo.nimble' to the compiler |
| 06:30:09 | FromDiscord | <Chiqqum_Ngbata> Is the only supported protocol is http(s) ? |
| 06:30:53 | FromDiscord | <treeform> It passes it to git, so https and git and ssh? |
| 06:32:00 | FromDiscord | <Chiqqum_Ngbata> Nice |
| 06:32:15 | FromDiscord | <treeform> Araq, how do you get the variables out with nim e? |
| 06:33:02 | Araq | dunno the details but check Nimble's source code, Nimble uses 'nim e' for evaluation too |
| 06:34:25 | FromDiscord | <treeform> Ok |
| 06:35:10 | FromDiscord | <treeform> Araq, why did you start on nawabs? |
| 06:36:42 | Araq | nawabs is dead but I started it because nimble solves the wrong problems for me |
| 06:37:59 | Araq | this whole "versioning" idea is wrong for small projects, too much mental overhead, too little gain |
| 06:39:22 | Araq | if stuff stops working a compiler error message is good enough. and it actually tells you the problem. instead of "foobar requires banana version 2 but you use version 3" |
| 06:39:52 | FromDiscord | <treeform> I feel versions are nice, but I want direct git hash, I want exact same code they saw. |
| 06:40:31 | Araq | yeah, that's it, if you want determinism, use git hashes, don't mess around with meaningless number triples |
| 06:41:52 | FromDiscord | <treeform> I am also just not into other ppls libraries. |
| 06:42:26 | FromDiscord | <treeform> Half the time if I use some one else lib, I fork it and modify it. |
| 06:42:30 | FromDiscord | <Chiqqum_Ngbata> Versions are good for frame of reference for end users, no? Version is out of date, read changelog for new version to get a sense for compatibility or upgrade path, bump dependency version |
| 06:42:45 | FromDiscord | <treeform> I don't even know how to make nimble use my new fork |
| 06:42:55 | FromDiscord | <Chiqqum_Ngbata> There's still the functional compatibility test at the end of the day |
| 06:43:03 | Araq | treeform: via 'nimble develop' |
| 06:43:33 | FromDiscord | <treeform> I had so much issues with nimble develop |
| 06:43:50 | Araq | Chiqqum_Ngbata: the picture changes for bigger projects |
| 06:44:08 | FromDiscord | <treeform> I think because it's still global path file some place |
| 06:44:32 | Araq | treeform: nawabs predates 'nimble develop', for me ever since 'nimble develop' nimble became bearable |
| 06:44:34 | FromDiscord | <treeform> I think I have to manually fix it all the time |
| 06:44:46 | Araq | for me it just works |
| 06:46:40 | FromDiscord | <treeform> I think what happens I have two projects, I nimble develop the same library twice |
| 06:46:52 | FromDiscord | <treeform> And now it gets confused |
| 06:47:29 | Araq | well I have the "same" library only once in my projects dir |
| 06:47:31 | FromDiscord | <treeform> Also if I delete a lib, it gets confused and I have to delete the link file of some sort |
| 06:47:57 | FromDiscord | <treeform> What if you have two projects dir? |
| 06:48:16 | Araq | ah, I don't |
| 06:48:27 | Araq | and that explains why I never had any trouble ;-) |
| 06:48:35 | FromDiscord | <treeform> I think that might be my problem |
| 06:48:42 | Araq | yes |
| 06:50:08 | Araq | lol yeah, the whole setup cannot work when you have multiple project dirs |
| 06:50:11 | Araq | :D |
| 06:50:15 | FromDiscord | <treeform> I largely make my own problems |
| 06:50:46 | Araq | that's a very good argument for killing the nimbledir and to install packages locally |
| 06:50:57 | Araq | thank you, one more argument for me |
| 06:52:21 | FromDiscord | <treeform> Thoughts on packages.json? |
| 06:53:49 | Araq | it doesn't solve the problem that .nimble files solve |
| 06:55:35 | FromDiscord | <Chiqqum_Ngbata> TOML is a lot friendlier to human editing |
| 06:56:24 | FromDiscord | <treeform> Araq, what do you think nim's killer app would be? |
| 06:58:46 | Araq | huh? we have nimbus, arraymancer, norm, your UI library, the windows UI library (for some reason I cannot remember UI library names) |
| 06:58:59 | FromDiscord | <Chiqqum_Ngbata> IMO some languages/platforms have more general utility than specific "killer" use cases. The killer app is probably exceptional case no? |
| 06:59:20 | Araq | your UI lib could be the "killer app" |
| 06:59:34 | * | kungtotte quit (Quit: WeeChat 2.6) |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:01:19 | FromDiscord | <treeform> Hmm got to put more time into it then :) it's not even released. |
| 07:04:01 | * | theelous3 quit (Ping timeout: 268 seconds) |
| 07:05:06 | * | gmpreussner joined #nim |
| 07:38:17 | * | solitudesf quit (Ping timeout: 240 seconds) |
| 07:39:48 | * | solitudesf joined #nim |
| 07:42:20 | FromGitter | <alehander42> i think we can have cool web toolkits |
| 07:42:27 | FromGitter | <alehander42> but i wouldnt say they would be killer apps |
| 07:43:49 | FromGitter | <alehander42> i also think nim is very good for various cli tools / "system" software etc where currently go shines |
| 07:43:58 | FromGitter | <alehander42> e.g. if you write something like docker |
| 07:44:10 | FromGitter | <alehander42> i'd say nim might be a cool choice |
| 07:45:08 | Araq | for cli tools everything that doesn't run on the JVM is fine anyway |
| 07:45:21 | * | fanta1 joined #nim |
| 07:46:20 | FromGitter | <alehander42> yes, but i just feel nim/go/crystal etc are nice for it |
| 07:46:33 | FromGitter | <alehander42> this class of languages |
| 07:46:41 | FromGitter | <alehander42> which dont require a vm |
| 07:46:45 | FromGitter | <alehander42> can produce binaries |
| 07:47:16 | * | GordonBGood quit (Remote host closed the connection) |
| 07:47:16 | solitudesf | cool, compiler says that it cant find the module that is clearly there and worked before. i bet its because i changed nimbleDir and it isnt actually respected properly. back to littering home i go. |
| 07:47:19 | FromGitter | <alehander42> but are not too low level like c++/rust, so its simpler to write |
| 07:47:25 | * | fanta1 quit (Client Quit) |
| 07:47:39 | FromGitter | <alehander42> so c#/java/etc python/ruby etc c++/rust etc dont quite do it for me |
| 07:47:47 | FromGitter | <alehander42> so i feel there are not so many languages well suited for it |
| 07:48:03 | solitudesf | ah, i guess i should expect that if im not building with nimble, whatever |
| 07:48:23 | FromGitter | <alehander42> maybe the functional ones are also good, but they're bit less approachable |
| 07:48:26 | * | fanta1 joined #nim |
| 07:50:32 | Araq | well self-contained binaries are nice but they are nice for everything, that's not related to "cli" |
| 07:50:51 | FromGitter | <alehander42> well, i feel ui apps are usually bigger |
| 07:51:00 | FromGitter | <alehander42> so people dont really care if they use a runtime |
| 07:51:03 | FromGitter | <alehander42> like .NET |
| 07:51:07 | FromGitter | <alehander42> or jvm |
| 07:51:09 | FromGitter | <alehander42> i mean, we use electron |
| 07:51:40 | FromGitter | <alehander42> its not so important to be easy to deploy/pass around |
| 07:51:59 | Araq | the average cli comes with python, ruby, perl, bash and nobody cares. well I do, but I'm in the crackpot minority |
| 07:52:14 | FromGitter | <alehander42> yeah, but this is not perfect |
| 07:52:22 | FromGitter | <alehander42> distros have different versions |
| 07:52:30 | FromGitter | <alehander42> windows doesnt really come with some iirc |
| 07:52:35 | FromGitter | <alehander42> overally people do care |
| 07:52:42 | FromGitter | <alehander42> and thats why so many cli stuff is written in go |
| 07:52:44 | FromGitter | <alehander42> these days imo |
| 07:52:53 | Araq | yeah but the "cli" itself is an anachronism |
| 07:53:11 | Araq | and certainly not "perfect" |
| 07:55:18 | Araq | or to make this short: "hey, it's superb for cli development" is never going to be a "killer app", simply because cli itself is only relevant in the programmer bubble. Rails targets the web and the web is important. |
| 07:56:29 | FromGitter | <alehander42> well |
| 07:56:38 | FromGitter | <alehander42> its still an important niche |
| 07:56:45 | FromGitter | <alehander42> because if programmers like your tech |
| 07:56:55 | FromGitter | <alehander42> they would start using it for other stuff |
| 07:57:00 | FromGitter | <alehander42> writing web and other frameworks |
| 07:57:11 | FromGitter | <alehander42> so they can keep using it for the more public stuff they need to do |
| 07:57:13 | * | Vladar joined #nim |
| 07:57:42 | FromGitter | <alehander42> rails happened, because dhh and his peers found ruby and liked it |
| 07:58:44 | FromGitter | <alehander42> and i mean overally system software |
| 07:58:46 | FromGitter | <alehander42> not just cli tools |
| 07:58:51 | FromGitter | <alehander42> like docker and kubernete |
| 08:01:35 | Araq | you can create a platform or target one. "cli" is not a platform anybody cares about. show your cli app to your Mum and she thinks "yay, DOS is back" |
| 08:02:31 | Araq | bbl |
| 08:03:49 | * | gmpreussner_ joined #nim |
| 08:04:51 | * | gmpreussner quit (Ping timeout: 240 seconds) |
| 08:05:03 | FromGitter | <alehander42> well, my mum programs excel man |
| 08:07:13 | FromGitter | <alehander42> i am just saying its a good niche, if you want ui, imo we need something like flutter which can target mobile |
| 08:08:01 | FromGitter | <alehander42> however thats part of the thing, almost every lang has a web/ui framework/toolkit ecosystem |
| 08:08:08 | FromGitter | <alehander42> its much bigger competitition |
| 08:09:29 | FromGitter | <alehander42> e.g. i think nim can be quite useful for web too, but it needs a much harder push |
| 08:15:42 | * | ng0 joined #nim |
| 08:19:49 | FromDiscord | <mratsim> Every language has Electron? :p |
| 08:21:16 | * | solitudesf quit (Remote host closed the connection) |
| 08:24:37 | * | solitudesf joined #nim |
| 08:28:20 | FromGitter | <sheerluck> > show your cli app to your Mum and she thinks "yay, DOS is back" ⏎ :D |
| 08:31:40 | * | Hideki_ joined #nim |
| 08:35:38 | * | Hideki_ quit (Ping timeout: 240 seconds) |
| 08:59:42 | livcd | i dont think so |
| 08:59:58 | livcd | the only langs that have any GUI toolkits are Java and C# |
| 09:01:48 | * | Hideki_ joined #nim |
| 09:03:11 | * | tklohna_ joined #nim |
| 09:12:52 | * | rolfr joined #nim |
| 09:13:27 | * | rolfr quit (Client Quit) |
| 09:21:36 | * | kungtotte joined #nim |
| 09:23:19 | * | jjido joined #nim |
| 09:26:05 | * | luis_ joined #nim |
| 09:26:55 | FromDiscord | <mratsim> Pascal, Delphi, C++, Javascript |
| 09:27:08 | FromDiscord | <mratsim> arguably GTK is C as well |
| 09:27:49 | FromDiscord | <mratsim> Red/Rebol |
| 09:27:54 | FromDiscord | <mratsim> Swift |
| 09:31:22 | * | luis_ quit (Remote host closed the connection) |
| 09:35:21 | * | letto quit (Ping timeout: 246 seconds) |
| 09:43:29 | lqdev[m] | wait. c++ has a gui toolkit? |
| 09:43:58 | * | NimBot joined #nim |
| 09:45:16 | leorize_ | wxWidgets, Qt |
| 09:45:20 | * | leorize_ is now known as leorize |
| 09:45:34 | * | letto joined #nim |
| 09:45:43 | * | lmariscal quit (Quit: Ping timeout (120 seconds)) |
| 09:46:21 | * | lmariscal joined #nim |
| 09:50:03 | Zevv | well, it doesn't *have* a toolkit like java |
| 09:50:12 | Zevv | but there are common toolkits implemented in that language |
| 10:04:42 | * | Hideki_ quit (Ping timeout: 268 seconds) |
| 10:05:58 | FromGitter | <alehander42> mratsim yee not electron sorry |
| 10:06:08 | FromGitter | <alehander42> but many languages target ui |
| 10:07:01 | FromGitter | <alehander42> c#, java, typescript, javascript, swift, kotlin, c++, pascal, objective c, dart |
| 10:07:15 | FromGitter | <alehander42> probably even go, python as well |
| 10:07:25 | FromGitter | <alehander42> its a big field |
| 10:10:18 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 10:12:04 | * | fanta1 quit (Quit: fanta1) |
| 10:18:47 | * | jjido joined #nim |
| 10:23:47 | * | luis_ joined #nim |
| 10:24:14 | * | stefantalpalaru joined #nim |
| 10:34:42 | * | luis_ quit (Ping timeout: 265 seconds) |
| 10:43:53 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 10:47:16 | * | letto quit (Ping timeout: 265 seconds) |
| 10:55:38 | * | lritter joined #nim |
| 11:01:05 | FromGitter | <gogolxdong> @treeform does fidget use VDOM for js backend? |
| 11:07:55 | * | krux02 joined #nim |
| 11:07:57 | * | solitudesf quit (Ping timeout: 240 seconds) |
| 11:41:01 | FromGitter | <Willyboar> A little late for this but i strongly believe that nim needs a central library hosting like rubygems |
| 11:42:57 | FromGitter | <Willyboar> @treeform i liked nimby a lot. |
| 11:47:57 | FromDiscord | <mratsim> btw @Araq, I have a test case in Arraymancer that took ages to compile in 0.20.0: |
| 11:47:57 | FromDiscord | <mratsim> Hint: operation successful (109082 lines compiled; 11.859 sec total; 952.492MiB peakmem; Debug Build) [SuccessX] |
| 11:47:57 | FromDiscord | <mratsim> |
| 11:47:57 | FromDiscord | <mratsim> And was somehow mafically much faster and much more memory efficient since 0.20.2 |
| 11:47:57 | FromDiscord | <mratsim> Hint: operation successful (128799 lines compiled; 2.194 sec total; 261.719MiB peakmem; Debug Build) [SuccessX] |
| 11:48:31 | dom96 | Willyboar: It's not too late for this and it does need to happen |
| 11:49:24 | dom96 | I've argued in one of Araq's recent RFCs that resources should be focused on that instead of a Nim distribution |
| 11:49:35 | FromGitter | <Willyboar> i mean late because they talk about it a few hours ago :) |
| 11:51:31 | FromGitter | <Willyboar> Of course can be done now. |
| 11:52:06 | FromGitter | <Willyboar> But i strongly believed that it must be official |
| 11:52:49 | FromGitter | <Willyboar> What did you think about @dom96 ? |
| 11:53:02 | livcd | i dont think there is even a possibility of having reasonably useful gui lib |
| 11:53:40 | dom96 | Willyboar: oh I see, I misunderstood you. I think it's a must-have for any successful package ecosystem. |
| 11:54:22 | dom96 | Somebody just need to write a good website for this and integrate Nimble with it |
| 11:55:46 | FromDiscord | <Rika> Isn't there nimble.directory or is that different |
| 11:56:09 | FromGitter | <Willyboar> Well yesterday i told federico if he is interested about a redesign |
| 11:56:37 | FromGitter | <Willyboar> but i think nimble.directory is not official |
| 11:56:53 | * | sealmove joined #nim |
| 11:57:06 | FromDiscord | <Rika> Oh really? Always thought it was official |
| 11:57:15 | FromGitter | <Willyboar> i am not sure |
| 11:57:51 | FromGitter | <Willyboar> but nimble.directory don't host packages |
| 12:10:50 | zedeus | dom96: would you rather I open the issue in Nim's or Jester's repo? it concerns asynchttpserver but I haven't tested without Jester |
| 12:12:10 | dom96 | zedeus, nim |
| 12:12:34 | dom96 | yeah, nimble.directory doesn't host packages |
| 12:12:39 | dom96 | we would need it to do that |
| 12:12:41 | dom96 | bbl |
| 12:13:04 | FromGitter | <Willyboar> @dom96 is nimble.directory official? |
| 12:13:42 | FromDiscord | <mratsim> it's not |
| 12:14:31 | FromGitter | <Willyboar> yes but federico is in the core team i think |
| 12:24:37 | * | jjido joined #nim |
| 12:30:52 | * | GordonBGood joined #nim |
| 12:35:31 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 12:36:11 | * | clyybber joined #nim |
| 12:36:40 | Araq | it's semi-official |
| 12:39:30 | FromGitter | <Willyboar> @Araq what did you think about an official package host? |
| 12:40:05 | Araq | I don't mind it but it's unrelated to my "Nim distribution" idea |
| 12:41:33 | * | jjido joined #nim |
| 13:01:01 | * | nsf quit (Quit: WeeChat 2.6) |
| 13:04:48 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:07:28 | * | dddddd joined #nim |
| 13:08:09 | * | GordonBGood quit (Remote host closed the connection) |
| 13:11:53 | kungtotte | +- |
| 13:15:02 | * | solitudesf joined #nim |
| 13:18:05 | clyybber | -+ |
| 13:18:20 | FromGitter | <Willyboar> ++? |
| 13:18:30 | clyybber | # |
| 13:18:36 | Araq | Half Life++ confirmed! |
| 13:18:44 | clyybber | Half Life# |
| 13:19:06 | clyybber | They should have called it C++++ |
| 13:19:26 | Araq | C+=2 |
| 13:30:23 | * | jjido joined #nim |
| 13:41:36 | clyybber | We shall create C== |
| 13:49:50 | sealmove | C++++ is C# |
| 13:50:15 | sealmove | if you connect the 4 plus signs in a squarish way |
| 13:50:45 | federico3 | ...besides what does "official" mean in this context? |
| 13:52:36 | * | Romanson joined #nim |
| 13:55:07 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 13:55:32 | * | ng0 joined #nim |
| 13:56:33 | clyybber | sealmove: Yeah, thats why I want C== |
| 13:56:42 | clyybber | Its C---- |
| 13:56:51 | clyybber | And there already exists C-- |
| 13:57:17 | * | ng0 quit (Client Quit) |
| 13:57:37 | * | ng0 joined #nim |
| 13:57:37 | sealmove | cool, although C# beats you beacuse it combines 4 symbols in 1, while you combine 4 symbols in 2 |
| 13:58:32 | * | clyybber quit (Read error: Connection reset by peer) |
| 13:58:38 | * | clyybber1 joined #nim |
| 13:58:56 | sealmove | maybe C≢ ? |
| 13:59:36 | * | ng0 quit (Client Quit) |
| 13:59:55 | * | ng0 joined #nim |
| 14:00:13 | clyybber1 | Arguably C= would be enough since a - could be -- |
| 14:01:10 | * | clyybber1 quit (Client Quit) |
| 14:01:26 | * | ng0 quit (Client Quit) |
| 14:01:45 | * | ng0 joined #nim |
| 14:02:05 | * | clyybber joined #nim |
| 14:03:08 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 14:03:16 | federico3 | Willyboar, dom96: nimble.directory is not hosting packages at the moment (but it would be easy to add) but it's testing the installation and doc generation and hosting the generated docs, kind of like readthedocs.io for Python |
| 14:05:43 | federico3 | it also has an api to sign package metadata to implement a trusted package list |
| 14:08:32 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 14:08:49 | * | ng0 joined #nim |
| 14:09:58 | * | letto joined #nim |
| 14:18:17 | * | clyybber quit (Ping timeout: 240 seconds) |
| 14:27:24 | FromGitter | <Willyboar> Yes. I think nimble directory would be a nice base for that we are talking about. |
| 14:33:21 | federico3 | is the unittest module kind-of deprecated? The "please consider to use the testament tool" remark does not bode well |
| 14:33:36 | federico3 | can we fix it instead? |
| 14:33:59 | disruptek | apparently unittest, which works great for me, is being replaced with something built for testing the compiler which i don't know how to use. |
| 14:34:42 | sealmove | testament |
| 14:34:43 | federico3 | unittest has a lot of nice features that belong to a testing tool/lib |
| 14:35:08 | sealmove | what I dislike about unittest is that you can't split a testsuite to multiple files |
| 14:35:15 | * | solitudesf- joined #nim |
| 14:35:38 | sealmove | I want to produce 1 junit out of multiple unittest files |
| 14:36:12 | federico3 | sealmove: 1 junit makes sense but it does not need to be one testsuite |
| 14:36:44 | sealmove | still, how do you get 1 junit out of many nim files? |
| 14:36:45 | federico3 | sealmove: adding the requirement to https://github.com/nim-lang/Nim/issues/5114 |
| 14:36:50 | * | solitudesf quit (Ping timeout: 240 seconds) |
| 14:37:55 | sealmove | federico3: oh ok, nice, thanks |
| 14:39:28 | * | nsf joined #nim |
| 14:41:32 | * | baysao joined #nim |
| 14:42:43 | * | jjido joined #nim |
| 14:44:03 | FromDiscord | <Rika> is there a tutorial on testament or is testament still experimental |
| 14:45:26 | FromGitter | <alehander42> i dont think testament |
| 14:45:40 | FromGitter | <alehander42> should replace unittest |
| 14:45:59 | FromGitter | <alehander42> i think unittest with some improvements is pretty good for 70% of nim projects |
| 14:46:10 | FromGitter | <alehander42> and more similar to other lang frameworks |
| 14:47:10 | federico3 | by all means we can improve unittest and add isolation |
| 14:48:09 | sealmove | testament is not "experimental", it has been used for testing most of Nim codebase since forever |
| 14:48:35 | sealmove | documentation of how to use testament, especially in other projects, is lacking though |
| 14:50:51 | sealmove | is there a way to represent all positive and negative numbers respectively in a way that `case` understands it? https://play.nim-lang.org/#ix=1ZTl |
| 14:52:48 | Zevv | sealmove: https://play.nim-lang.org/#ix=1ZTm |
| 14:55:14 | sealmove | oh, didn't expect this to work, nice |
| 14:55:14 | stefantalpalaru | @sealmove, you can use Nim modules to split your test suite: https://github.com/status-im/nim-chronos/blob/master/tests/testall.nim |
| 14:56:18 | * | tklohna_ quit (Ping timeout: 252 seconds) |
| 14:56:44 | * | tklohna_ joined #nim |
| 14:56:46 | sealmove | stefantalpalaru: oh! this works? and it produces 1 junit? |
| 14:58:29 | stefantalpalaru | I'm not familiar with Java's unit testing, but you do get a single test binary: https://github.com/status-im/nim-chronos/blob/5f1391f39f1adc447874e21c590efcb4921fb822/chronos.nimble#L16 |
| 15:00:22 | sealmove | I don't see how this would work. testall.nim just imports the other tests. Yes, you get to compile them all in a single binary file, but I don't think you can get 1 junit file that way. |
| 15:02:57 | * | tklohna_ quit (Ping timeout: 265 seconds) |
| 15:08:10 | Araq | I don't want to maintain unittest.nim |
| 15:08:36 | disruptek | thus spaketh the powers that he. |
| 15:09:01 | Araq | I know it's very popular and we cannot really remove it |
| 15:09:16 | Araq | but if you want to see its bugs fixed, create PRs for it |
| 15:09:16 | disruptek | so let it be written, so let it be done. |
| 15:09:48 | disruptek | what's the pain point for maintaining it, in your opinion? |
| 15:10:00 | * | sealmove quit (Quit: WeeChat 2.6) |
| 15:14:12 | * | theelous3_ joined #nim |
| 15:14:18 | Araq | the used coding style looks like a stress-test for Nim's template expansion algorithm |
| 15:15:53 | Araq | but ultimately it doesn't give me anything over 'when isMainModule: doAssert' |
| 15:15:54 | * | tklohna_ joined #nim |
| 15:16:11 | Araq | whereas testament gives me process isolation and parallel testing |
| 15:16:11 | disruptek | the only issue i have with it, which should be trivial to solve, is that it disrupts the new "symbol unused" warnings. i don't mind attempting to fix that. |
| 15:16:35 | FromGitter | <alehander42> araq talks about the compiler needs imo |
| 15:16:38 | FromGitter | <alehander42> which are widely different |
| 15:16:40 | FromGitter | <alehander42> than most |
| 15:16:55 | disruptek | yes, this is the same perspective from which krux02 approaches the problem, sadly. |
| 15:17:02 | stefantalpalaru | Much easier to get parallel testing with a thread pool: https://github.com/stefantalpalaru/nim-unittest2 |
| 15:17:09 | disruptek | i mean, at least they share the same perspective. 😁 |
| 15:17:15 | Araq | I am not sure about that, you can test for good error messages |
| 15:17:27 | Araq | for your DSL, for example via testament |
| 15:17:30 | FromGitter | <alehander42> but you can do it with expect .. this exception anyway |
| 15:17:43 | FromGitter | <alehander42> well, you can still make it easy to invoke a process and test its output |
| 15:17:48 | FromGitter | <alehander42> without making this the default mode |
| 15:17:50 | Araq | no, you can't test for good compiler error messages via unittest |
| 15:17:51 | disruptek | it's harder to test output with unittest. |
| 15:17:54 | FromGitter | <alehander42> most libs are small and its enough |
| 15:18:02 | FromGitter | <alehander42> to just run them directly calling them |
| 15:18:05 | FromGitter | <alehander42> as the user code would |
| 15:18:11 | Araq | sure but then so is 'when isMainModule' |
| 15:18:15 | FromGitter | <alehander42> not running 10 processes with each test |
| 15:18:20 | FromGitter | <alehander42> eh maybe |
| 15:18:32 | FromGitter | <alehander42> but still i find the idea of `check` and `expect` useful |
| 15:18:38 | FromGitter | <alehander42> they need some improvement |
| 15:18:41 | FromGitter | <alehander42> in impl |
| 15:18:59 | FromGitter | <alehander42> and the template thing |
| 15:19:00 | disruptek | yes, check could be better: it could unwrap the values. |
| 15:19:06 | FromGitter | <alehander42> one can implement a similar dsl without so much templates |
| 15:19:20 | FromGitter | <alehander42> i did for my project with function pointers |
| 15:19:24 | Araq | yeah but I don't see the value in the DSL |
| 15:19:28 | FromGitter | <alehander42> just didnt realize i can do it all with templates |
| 15:19:45 | FromGitter | <alehander42> well "test <this thing>: my test" |
| 15:19:51 | FromGitter | <alehander42> it cant be much more simpler imo |
| 15:20:20 | FromDiscord | <Chiqqum_Ngbata> {.skip.} and {.only.} pragmas |
| 15:20:25 | FromGitter | <alehander42> now, should it be in the same file or different, its a differentmatter |
| 15:20:37 | Araq | well if you all like so much, how about you fix its bugs |
| 15:20:47 | FromGitter | <alehander42> well, i wrote my own little replacement :( |
| 15:20:52 | Araq | for example the one that triggers "too many global variables" |
| 15:20:53 | disruptek | what bugs? |
| 15:21:01 | FromGitter | <alehander42> yeah i know |
| 15:21:15 | FromGitter | <alehander42> i also asked about that one several days ago |
| 15:21:18 | disruptek | i asked you what the pain point was and you said "it exercises the compiler which could help us identify flaws in that application sooner." |
| 15:21:38 | disruptek | and, "it doesn't help ME do anything i cannot already do elsewise." |
| 15:21:46 | FromGitter | <alehander42> i wonder |
| 15:21:51 | FromGitter | <alehander42> parallelizing shouldnt be too hard in principle |
| 15:22:08 | FromGitter | <alehander42> tests are supposed to mostly be independent |
| 15:22:12 | Araq | that's your interpretation, disruptek |
| 15:22:16 | FromGitter | <alehander42> so with proper setup/teardown |
| 15:22:16 | disruptek | it is. |
| 15:22:27 | FromGitter | <alehander42> one should be ok to run them in parallel |
| 15:22:30 | disruptek | feel free to put another spin on it. |
| 15:22:40 | Araq | what I really said was: "I don't like to maintain it because it looks overly complicated for what it does" |
| 15:22:43 | FromGitter | <alehander42> but i admit, maybe not so obvious |
| 15:23:09 | Araq | "Plus is lacks important features." |
| 15:23:32 | FromGitter | <alehander42> which are the main ones |
| 15:23:51 | disruptek | i expect to run golden on the compiler tests. maybe i can generalize it and put more of the testing into it. it already hashes input and output and measures exit code, memory, cpu. so it might be an upgrade for some. |
| 15:23:52 | Araq | "And it has known bugs nobody can be bothered to fix." |
| 15:23:52 | FromGitter | <alehander42> for me testament is useful only for big projects where you cant really call them easily programatically |
| 15:23:59 | FromGitter | <alehander42> and another *big* problem |
| 15:24:02 | FromGitter | <alehander42> of testament's design is |
| 15:24:19 | Araq | that are 3 objective reasons to justify "I don't like to maintain it" |
| 15:24:36 | FromGitter | <alehander42> ok, my bad, not big,small |
| 15:24:43 | FromGitter | <alehander42> but you either have to compile many test files |
| 15:24:50 | FromGitter | <alehander42> which is still not very fast |
| 15:25:07 | FromGitter | <alehander42> or to somehow list the expected output of 20 different tests in tge same file |
| 15:25:10 | FromGitter | <alehander42> which is very confusing |
| 15:25:16 | disruptek | the code works, today. today it is doing work. today it is getting the job done. it's unfriendly to remove it. |
| 15:25:37 | disruptek | is there an RFC for this testing discussion? |
| 15:25:38 | FromGitter | <alehander42> but if you can call your lib directly from nim, it doesnt make sense to me to start a new process and test its output |
| 15:25:47 | FromGitter | <alehander42> when you can test the actual nim values |
| 15:25:51 | Araq | it didn't get the {.deprecated.} pragma, so don't complain |
| 15:25:52 | FromGitter | <alehander42> and program your tests |
| 15:26:02 | FromGitter | <alehander42> yea |
| 15:26:47 | Araq | become a code owner for the module, fix the "too many globals" bug and you can remove the bitter comment about 'testament' |
| 15:27:03 | disruptek | is there an issue for the bug? |
| 15:27:10 | Araq | sure, one sec |
| 15:27:33 | FromGitter | <alehander42> ah i dont care so much about the testament comment |
| 15:27:42 | FromGitter | <alehander42> ok, i obviously care |
| 15:27:48 | FromGitter | <alehander42> but i just wanted to argue |
| 15:27:49 | FromGitter | <alehander42> mostly |
| 15:28:02 | disruptek | i found the issue. |
| 15:28:07 | disruptek | https://github.com/nim-lang/Nim/issues/8500 |
| 15:28:46 | Araq | there are also more here, https://github.com/nim-lang/Nim/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+unittest+in%3Atitle |
| 15:30:45 | * | baysao_ joined #nim |
| 15:31:01 | disruptek | this will surprise no one, but i'm having trouble finding the docs for testament. |
| 15:31:23 | FromGitter | <alehander42> https://www.wezm.net/technical/2019/10/useful-command-line-tools/ |
| 15:31:59 | federico3 | https://github.com/nim-lang/Nim/issues/5114 tracks improvements already |
| 15:32:18 | federico3 | we can add a big cleanup and simplification |
| 15:33:47 | * | baysao quit (Ping timeout: 276 seconds) |
| 15:34:03 | Araq | https://github.com/nim-lang/Nim/blob/devel/doc/contributing.rst#compiler disruptek |
| 15:34:11 | disruptek | danke. |
| 15:34:29 | Araq | I agree it needs to be moved to somewhere findable |
| 15:34:36 | disruptek | ah, this is good docs, though, at least. |
| 15:36:08 | Araq | and yeah it needs further cleanup for a "general purpose testing tool", but it's getting there and is the tool we used for almost a decade now, it's not going away |
| 15:37:31 | FromDiscord | <k1tt3hk4t> |
| 15:37:31 | FromDiscord | <k1tt3hk4t> https://cdn.discordapp.com/attachments/371759389889003532/637676178013945876/2019-10-26-103613_1280x1024_scrot.png |
| 15:37:34 | FromDiscord | <k1tt3hk4t> did this inspired by those "beating C wc with (haskell/APL/futhark)" articles.. probably a silly competition given that mine doesn't support streaming yet but happy to see it's around 2x faster on files, as those two articles did |
| 15:37:58 | FromDiscord | <k1tt3hk4t> except without "cheating" and either using a GPU or multiple cores |
| 15:38:31 | FromDiscord | <k1tt3hk4t> (I assume the discord image link was sent over IRC? If not let me know) |
| 15:38:33 | * | baysao joined #nim |
| 15:38:57 | disruptek | it was, it's just, like, ridiculously enlarged. |
| 15:39:03 | stefantalpalaru | Implementing/using a different algorithm than the C version is also cheating. |
| 15:40:18 | FromGitter | <ingoogni> Very first attempt and stuck on the second line :( ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ Error: cannot evaluate at compile time: res ... [https://gitter.im/nim-lang/Nim?at=5db468e2e886fb5aa2fda789] |
| 15:40:31 | stefantalpalaru | (made even more clear by Nim being compiled to C ;-)) |
| 15:41:05 | FromDiscord | <k1tt3hk4t> well yeah, it's not a good way to benchmark C vs Nim, but language benchmarks are also kinda stupid imo :^P |
| 15:41:08 | * | baysao_ quit (Ping timeout: 265 seconds) |
| 15:41:26 | FromDiscord | <k1tt3hk4t> using the same algorithm in every language at the expense of it not being idiomatic or being overly complicated is kind of silly |
| 15:41:29 | lqdev[m] | is there any way I can run a macro which needs `typed` params in a macro with `untyped` params without exporting the first one? |
| 15:42:11 | FromDiscord | <k1tt3hk4t> in this case I just more found it amusing that people were fawning over the C implementation as "hAnD oPtImIzEd" when it was clearly just thrown together with a "good enough" badge on it |
| 15:42:16 | disruptek | ingooni: use a seq if you want an array whose size is defined at runtime. |
| 15:42:17 | lqdev[m] | ingoogni: use a `seq` in this case. arrays are fixed size |
| 15:42:30 | FromDiscord | <k1tt3hk4t> and using that as "THE" measure of C's performance |
| 15:42:52 | FromDiscord | <k1tt3hk4t> it would be trivial for me to write the exact same as the Nim program in C using designated initializers to do the same LUT strategy |
| 15:42:55 | disruptek | also, gitter is tough for some of us to read. better to use a pastebin service. |
| 15:43:31 | lqdev[m] | especially because gitter highlights the message with a bright yellow which has practically 0 contrast with the message's text |
| 15:43:36 | lqdev[m] | (great design, 10/10) |
| 15:44:19 | FromGitter | <ingoogni> Ok, `seq` it will be. |
| 15:44:29 | disruptek | it's the fact that gitter consumes almost the entire screen with ads and presence list, so the trough in which the code sits is like 5 characters wide. and this, on a 4k display. it's inane. |
| 15:45:39 | lqdev[m] | disruptek: what ads? also, I hid my presence list long ago. |
| 15:47:40 | lqdev[m] | regarding my macros thing, right now I'm doing something like this: `result.add(newCall(ident"addProcAux", callArgs))` however, it requires `addProcAux` to be exported which I want to stay private because it's an implementation detail. |
| 15:48:20 | disruptek | https://imgur.com/QwQu9K7 |
| 15:48:40 | disruptek | i mean, c'mon... |
| 15:48:52 | lqdev[m] | what the hell is this |
| 15:49:03 | disruptek | that's what gitter looks like to me. |
| 15:49:17 | lqdev[m] | I guess they want you to sign in really bad |
| 15:49:29 | lqdev[m] | you can hide the user list using the icon in the bottom right corner |
| 15:49:47 | lqdev[m] | saves a tiny bit of space |
| 15:49:56 | disruptek | i know. but, every time i click a link? and, no, i don't want them to have access to my account. |
| 15:50:19 | disruptek | i swear, it's like no one tests the software they write. |
| 15:50:33 | disruptek | not unit tests, tests for serviceability. |
| 15:50:39 | disruptek | suitability for purpose. |
| 15:50:45 | disruptek | fitness. |
| 15:51:24 | lqdev[m] | I guess they're like microsoft: they make users test their updates, and then they don't fix it anyway because what's the point if it works on their VMs. |
| 15:52:11 | * | Trustable joined #nim |
| 15:52:57 | disruptek | not sure what your macro comment is in reference to, but one hack i'm aware of is to `include` a file so you don't need to export its symbols. |
| 15:53:03 | disruptek | could work for you here. |
| 15:53:39 | disruptek | i remember when gitter was created. i thought, "what a stupid idea." |
| 15:55:21 | lqdev[m] | disruptek: not what I need, the two macros are declared in the same file. |
| 15:59:42 | disruptek | maybe what you want to do is (inside your macro) run a proc that yields a NimNode? |
| 16:00:03 | disruptek | i'm just reading scrollback from, i guess a day or two ago. |
| 16:07:54 | stefantalpalaru | @disruptek, you're holding it wrong. Sign in with GitHub and get this (sidebars can be folded by clicking on those hamburger buttons): https://i.imgur.com/c0LRCik.png |
| 16:08:02 | lqdev[m] | clyybber: Commodore? |
| 16:08:03 | lqdev[m] | clyybber: Commodore? |
| 16:09:11 | disruptek | stefantalpalaru: yes and no. i even wrote a bookmarklet to try to vanish some of the ui, but i guess the gitter folks are smarter than i am. |
| 16:09:26 | Zevv | disruptek: nice eh this gitter thing |
| 16:09:33 | disruptek | it's choice, alright. |
| 16:10:24 | Zevv | one vs the other, hard choice: http://zevv.nl/div/shot.png |
| 16:10:27 | disruptek | "you're holding it wrong." true and so funny. |
| 16:10:44 | Zevv | I already hate things like whatsapp and 'modern' sms where you have these little clouds taking 80% of your screen estate away |
| 16:10:53 | disruptek | one of these days ima put my eye out with this thing. |
| 16:12:32 | disruptek | javascript:(function() { $('#chat-input-wrapper').remove(); $('.right-toolbar').classList.add("collapsed"); $('div .root').remove(); })(); |
| 16:12:51 | disruptek | my bookmarklet. iirc, it does click some hamburgers or w/e and close some things. but, not enough. |
| 16:14:36 | * | nif quit (Quit: ...) |
| 16:14:45 | * | nif joined #nim |
| 16:17:16 | disruptek | stefantalpalaru: how well does unittest2 work? |
| 16:20:27 | FromDiscord | <treeform> gogolxdong, I do not use VDOM in fidget js backend. Do you think that would improve performance? |
| 16:21:55 | FromDiscord | <treeform> gogolxdong, reading about Virtual DOM on the react docs, I might be using some thing like this. |
| 16:22:11 | FromDiscord | <treeform> I have a cache where I minimize all HTML/CSS transitions. |
| 16:22:45 | lqdev[m] | Zevv, disruptek: at least discord has a compact mode which looks a little like IRC. it's quite usable. |
| 16:22:47 | FromDiscord | <treeform> I try very hard to make the most minimal amount of dom calls to update the page. |
| 16:23:12 | * | lqdev[m] uploaded an image: image.png (7KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/RnecPgJsoylqUiUbNtHFFFBV > |
| 16:23:33 | FromDiscord | <treeform> gogolxdong, i also reuse HTML tags so that they don't have to be allocated again. I take DOM mutation and DOM node creation very seriously. |
| 16:30:34 | lqdev[m] | disruptek: regarding my macro issue, here's what I'm working with: http://ix.io/1ZTW/nim#n-249 |
| 16:31:21 | lqdev[m] | line 227 |
| 16:31:41 | stefantalpalaru | disruptek: unittest2 works as advertised. I'm waiting for the Nim 0.19.6 to 1.0.2 transition on Status projects before using it for Nimbus and nim-beacon-chain where the runtime of CI tests is becoming a problem. |
| 16:31:58 | lqdev[m] | the macros I want to keep private are on lines 227 and 249, and the macro that calls them is on line 261 |
| 16:32:09 | stefantalpalaru | Had to wait for these fixes to reach us: https://github.com/nim-lang/Nim/issues?utf8=%E2%9C%93&q=is%3Aissue+threadpool+is%3Aclosed+author%3Astefantalpalaru |
| 16:32:44 | disruptek | cool, i will use it instead. doesn't really make sense to develop the version in stdlib. |
| 16:33:49 | disruptek | lqdev[m]: why is getOverload a macro and not a procedure? |
| 16:34:37 | lqdev[m] | lqdev: making it a procedure somehow triggers the `error()` at line 259, haven't debugged it properly yet. |
| 16:39:11 | disruptek | maybe writing comments would help. |
| 16:41:30 | lqdev[m] | sorry, haven't gotten to documenting the codebase yet. |
| 16:41:59 | disruptek | i find it useful to explain my assumptions. |
| 17:08:00 | * | ng0 quit (Ping timeout: 260 seconds) |
| 17:14:04 | * | ng0 joined #nim |
| 17:17:52 | * | Trustable quit (Remote host closed the connection) |
| 17:19:26 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:23:12 | * | Romanson quit (Quit: Connection closed for inactivity) |
| 17:25:51 | * | chun joined #nim |
| 17:38:05 | lqdev[m] | disruptek: I added some comments, they may help you a bit http://ix.io/1ZUc/nim#n-227 |
| 17:48:15 | FromGitter | <auxym> Could anyone help my understand why this won't compile? https://play.nim-lang.org/#ix=1ZUe |
| 17:48:48 | Yardanico | @auxym there's no such field "keys" in a table |
| 17:49:03 | Yardanico | I think you should use let keys = toSeq(tab.keys) |
| 17:49:38 | Yardanico | (keys in an iterator) |
| 17:49:39 | Yardanico | *is |
| 17:50:07 | FromGitter | <auxym> huh. I guess I don't get ufcs then, I thought those would be equivalent |
| 17:50:18 | FromGitter | <auxym> tab.keys.toSeq vs toSeq(tab.keys) |
| 17:50:26 | Yardanico | well toSeq is not a function but a template |
| 17:50:39 | Yardanico | and keys is not a field but an iterator which can't be simply called like tab.keys() |
| 17:50:57 | FromGitter | <auxym> ah. I think I sort of get it |
| 18:08:18 | * | chun quit (Quit: Leaving) |
| 18:11:02 | FromGitter | <Willyboar> @dom96 , @FedericoCeratto i made a quick prototype https://nimble-prototype.netlify.com |
| 18:12:42 | * | ng0_ joined #nim |
| 18:13:24 | FromGitter | <Willyboar> of course everybodys feed is welcome |
| 18:15:40 | * | ng0 quit (Ping timeout: 260 seconds) |
| 18:15:53 | * | ng0_ is now known as ng0 |
| 18:23:52 | FromGitter | <Willyboar> the showcase needs more work |
| 18:24:12 | FromGitter | <auxym> if I'm getting a SIGSEGV from the gc without using any unsafe feature (ptr, etc), how likely is it I've hit a compiler bug? |
| 18:24:25 | FromGitter | <auxym> (working on putting together a minimal example) |
| 18:25:08 | FromGitter | <alehander42> do you use openarray |
| 18:26:25 | FromGitter | <auxym> in my own proc defs? no. do I use any stdlib procs defined with openArray? likely |
| 18:30:58 | federico3 | dom96: what happens when an async proc a() calls a sync proc b() and the latter calls "waitFor somethingAsync()" ? |
| 18:34:07 | federico3 | Willyboar: nice! |
| 18:34:30 | federico3 | Willyboar: "You don't have Nim in your computer." huh? |
| 18:35:48 | FromGitter | <Willyboar> hahaha of course i have. 1.0.2 |
| 18:35:50 | FromGitter | <Willyboar> :) |
| 18:35:56 | * | filcuc joined #nim |
| 18:38:19 | * | nsf quit (Quit: WeeChat 2.6) |
| 18:44:35 | * | GordonBGood joined #nim |
| 18:44:38 | federico3 | I mean: why is the page making that claim? |
| 18:46:43 | FromGitter | <Willyboar> I just put it to cover some space. |
| 18:48:52 | FromGitter | <Willyboar> But it is always a chance someone to come here first :) |
| 18:49:34 | * | sagax quit (Quit: Konversation terminated!) |
| 18:51:09 | disruptek | s/Treding/Trending/ |
| 18:52:10 | FromGitter | <Willyboar> where? |
| 18:52:12 | FromGitter | <Willyboar> :) |
| 18:52:22 | disruptek | ctrl-F |
| 18:53:25 | FromGitter | <Willyboar> ctrl - R |
| 18:54:56 | federico3 | dom96: what happens when an async proc a() calls a sync proc b() and the latter calls "waitFor somethingAsync()" ? <--- it blocks, that sucks :( |
| 18:55:02 | disruptek | s/tly\.E/tly. E/ |
| 18:55:19 | * | jjido joined #nim |
| 18:55:24 | disruptek | if you're in an async proc, you can await. |
| 18:55:34 | disruptek | if you don't want to wait, simply don't. |
| 18:56:28 | disruptek | basically, you're right, but there are solutions that work in the ecosystem. which is to say, the `what color is your function?` ecosystem. |
| 18:57:39 | disruptek | willyboar: the only important feature to me is to browse by package introduction date, with links to their homepages and maybe some repo/version stats. fwiw. |
| 18:57:49 | FromGitter | <alehander42> but isnt that the only reasonable behavior |
| 18:58:10 | FromGitter | <alehander42> what can somethingAsync do? |
| 18:58:42 | FromGitter | <alehander42> it *Blocks* the current thread until the specified future completes. |
| 18:58:46 | disruptek | waitFor by definition means `wait for`. i think his point is that sync code doesn't have the affordances that async code does. |
| 18:58:47 | FromGitter | <alehander42> thats what the docs say |
| 18:59:18 | FromGitter | <alehander42> ah sotrrry |
| 18:59:35 | disruptek | i mean, everyone is right, here. 😀 |
| 18:59:43 | FromGitter | <alehander42> i see, so he wants it to be async -inferring |
| 18:59:49 | federico3 | disruptek: no, waitFor when called *within* a greenthread could block only that thread |
| 18:59:50 | disruptek | i think so? |
| 19:00:23 | FromGitter | <alehander42> asyncdispatch isnt defined for green threads tho |
| 19:00:25 | disruptek | again, it's the `what color is your function` problem. |
| 19:01:01 | FromGitter | <alehander42> do you want it to await if its called by async and waitFor if its called by sync |
| 19:01:08 | FromGitter | <alehander42> thats what i thought is wanted |
| 19:01:18 | FromGitter | <alehander42> and it seems multisync might kinda do it |
| 19:01:23 | federico3 | disruptek: the color is not enough: you have to be sure that all the functions are async-colored in your stack |
| 19:01:37 | disruptek | that's the point of the argument, yes. |
| 19:01:46 | disruptek | because red demands red demands red. |
| 19:02:04 | federico3 | and if you don't they'll just block without any warning |
| 19:02:07 | FromGitter | <alehander42> ah, is that about detecting async might call a "blocking" call? |
| 19:02:15 | FromGitter | <alehander42> i wanted to somehow typecheck that |
| 19:02:20 | FromGitter | <alehander42> but it seemed very hard to do |
| 19:02:24 | FromGitter | <alehander42> even with an effect system |
| 19:02:32 | disruptek | effects become colors. |
| 19:03:28 | disruptek | lqdev[m]: i will look, but the idea was that documenting gets you to consider your own assumptions. it wasn't meant to be a criticism; sorry if it came across that way. |
| 19:04:24 | federico3 | the only "solution" is to use async across all your code in case something somewhere might block now or in future :( |
| 19:04:48 | disruptek | virtually everything is blocking unless you're writing go. |
| 19:05:00 | FromGitter | <alehander42> well, thats the point |
| 19:05:24 | FromGitter | <alehander42> you can annotate those primitives which "block" with `{.blocking.}` .. thing |
| 19:05:46 | disruptek | yes. async works, provided you grok the limitations and they align with your needs. if you show up with an expectation that won't be met, well, you are in for disappointment. |
| 19:05:48 | FromGitter | <alehander42> and somehow compiletime check that async stuff cant await them |
| 19:05:59 | FromGitter | <alehander42> but even this wouldnt really help all cases |
| 19:06:06 | federico3 | disruptek: no, this is a syntax and tooling problem |
| 19:06:10 | FromGitter | <alehander42> because as araq said once iirc, what is blocking |
| 19:06:16 | disruptek | but i think everything blocks. |
| 19:06:17 | FromGitter | <alehander42> e.g. a heavy loop |
| 19:06:20 | FromGitter | <alehander42> is also blocking |
| 19:06:25 | disruptek | an expression is blocking. |
| 19:06:38 | FromGitter | <alehander42> and go people thought about inserting preemptive stuff in loops as well |
| 19:06:39 | FromGitter | <alehander42> iirc |
| 19:06:50 | FromGitter | <alehander42> its not just a syntax problem with async/await |
| 19:06:56 | federico3 | we are talking about async I/O which has nothing to do with blocking on CPU |
| 19:07:04 | disruptek | yes, that's why go works. it's full of yields. |
| 19:07:14 | FromGitter | <alehander42> ok, but generally it is similar: you need a way to say |
| 19:07:30 | * | vesper11 joined #nim |
| 19:07:43 | FromGitter | <alehander42> sorry, not the same indeed |
| 19:07:49 | FromGitter | <alehander42> "this operation is <blocking>" |
| 19:08:16 | disruptek | oh, if you just want async i/o, that's different. |
| 19:08:30 | FromGitter | <alehander42> and to prove that your await cant "wait" for code that somehow invokes it directly |
| 19:08:36 | FromGitter | <alehander42> or to automatically somehow offload it |
| 19:08:42 | FromGitter | <alehander42> to a thread and await that |
| 19:08:47 | FromGitter | <alehander42> (very handwavy) |
| 19:09:20 | federico3 | the async support in Nim is about async i/o, not multithreading |
| 19:09:34 | FromGitter | <alehander42> but federico3 follow me here |
| 19:09:40 | * | vesper quit (Ping timeout: 264 seconds) |
| 19:09:41 | FromGitter | <alehander42> i am just talking about different possible solutions |
| 19:10:13 | FromGitter | <alehander42> or do you mean that you would never need |
| 19:10:20 | FromGitter | <alehander42> to use actual blocking io syscalls |
| 19:10:39 | FromGitter | <alehander42> in this case sorry, i was focused on detecting that you dont call those by *accident* |
| 19:10:49 | federico3 | alehander42: I get your point, but you are describing a completely different approach :) |
| 19:10:50 | disruptek | i think he's saying he wants better effects percolation so that async can magically multisync everything. |
| 19:11:33 | federico3 | "<alehander42> to a thread and await that" <-- you meant real thread on "green" thread here? |
| 19:12:05 | FromGitter | <alehander42> well, i suppose real thread, as otherwise the real thread which actually runs the green thread will still block |
| 19:12:09 | FromGitter | <alehander42> as its just a syscall |
| 19:12:24 | FromGitter | <alehander42> but i might be thinking of something else |
| 19:13:15 | federico3 | alehander42: didn't you just described Go's runtime? :) |
| 19:13:32 | FromGitter | <alehander42> i probably got the idea to offload it from go yeah |
| 19:13:38 | FromGitter | <alehander42> i remember i was trying to read what they do |
| 19:13:52 | federico3 | https://github.com/nim-lang/RFCs/issues/160 <-- then read this |
| 19:15:25 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 19:17:13 | disruptek | lqdev[m]: is 237-238 correct? |
| 19:17:41 | * | luis_ joined #nim |
| 19:18:05 | lqdev[m] | disruptek: yeah, it's a glitch in pygments's syntax highlighting |
| 19:18:18 | disruptek | no, i don't mean the highlight. |
| 19:19:00 | disruptek | you're just basically add(ty) N times, right? just seems like a confusing way to express that. |
| 19:19:08 | * | luis_ quit (Client Quit) |
| 19:19:24 | lqdev[m] | well, how else would you do that? |
| 19:19:30 | * | luis_ joined #nim |
| 19:19:36 | * | ng0 quit (Ping timeout: 260 seconds) |
| 19:19:44 | lqdev[m] | oh, I'm an idiot. |
| 19:19:59 | lqdev[m] | that's why you shouldn't code at 11 pm |
| 19:20:01 | lqdev[m] | I see what you mean now |
| 19:21:37 | disruptek | if it were me, i'd rewrite that proc and heavily comment it. i'm just too stupid to write stuff like this. |
| 19:21:50 | disruptek | also, i would eliminate the found bool by using block/break. |
| 19:22:57 | disruptek | but, my criticism is purely syntax because i dunno what any of these values or indices represent. 😀 |
| 19:23:11 | * | ng0 joined #nim |
| 19:23:48 | lqdev[m] | I get what you mean, I'll improve on that later. anyways, what about my original question? |
| 19:26:09 | disruptek | well, i'm not sure what this stuff does. |
| 19:26:24 | disruptek | you're marking up some nim for binding into wren? |
| 19:27:48 | dom96 | federico3, of course it blocks. We should make `waitFor` be an error if used in an {.async.} proc. |
| 19:28:00 | federico3 | :-/ |
| 19:28:05 | disruptek | that would not be good. |
| 19:28:17 | disruptek | i don't necessarily want to yield control in an async. |
| 19:29:44 | * | luis_ quit (Ping timeout: 276 seconds) |
| 19:29:50 | lqdev[m] | disruptek: exactly, I'm building a DSL whose purpose is to generate all the appropriate glue code for binding to Wren. |
| 19:30:08 | disruptek | can i see some hello world input? |
| 19:31:54 | disruptek | you say you don't want addProxAux to be public, but how is it public? it's accessible to the user's mod code? |
| 19:32:00 | lqdev[m] | disruptek: http://ix.io/1ZUM/nim |
| 19:32:01 | lqdev[m] | this is the problem |
| 19:32:20 | disruptek | that helps, thanks. |
| 19:32:24 | lqdev[m] | the code generated by `foreign` has a call to `addProcAux` |
| 19:32:25 | dom96 | federico3, why is this a problem? |
| 19:32:48 | lqdev[m] | but that macro is an implementation detail which I don't want visible to the user |
| 19:33:05 | federico3 | dom96: see above: |
| 19:33:18 | lqdev[m] | brb |
| 19:33:19 | disruptek | oh, that's why you wanted it to be a macro? so it would dissolve? |
| 19:33:21 | federico3 | you have to be sure that all the functions are async-colored in your stack |
| 19:33:30 | federico3 | and if you don't they'll just block without any warning |
| 19:34:33 | dom96 | federico3, yes, it's a problem that we need to fix. I think the best way is with Nim's effect system. |
| 19:34:53 | dom96 | But there is always the challenge of C libraries that you call into |
| 19:34:59 | dom96 | You never know what they'll do |
| 19:35:02 | dom96 | AFAIK Go has the same problem |
| 19:35:15 | disruptek | it does. |
| 19:35:55 | federico3 | well of course you have to assume they'll block or ensure they are async |
| 19:36:40 | disruptek | or, in theory, you could position yourself on an empty thread for the ffi and then keep chugging along in your other threads. |
| 19:37:22 | dom96 | yeah, I have a feeling Go might have some magic here |
| 19:37:28 | disruptek | which is how go does it, iirc. |
| 19:37:35 | federico3 | unsurprisingly |
| 19:37:53 | federico3 | but you have to pay the price of pinning a thread to a single "greenlet" for a while |
| 19:39:45 | disruptek | lqdev[m]: as a hack, you could make it crash at runtime, right? |
| 19:40:25 | rayman22201 | am I missing all the fun async discussions? |
| 19:40:40 | disruptek | no, they won't start until you contribute. 😁 |
| 19:41:38 | rayman22201 | lol, uh oh! |
| 19:42:32 | federico3 | our async discussion is blocked |
| 19:42:53 | rayman22201 | lmao |
| 19:43:01 | disruptek | how would nested tests work in #5114? |
| 19:43:20 | disruptek | i mean, what are the desired semantics? |
| 19:43:42 | disruptek | do i have to specify dependencies or does it figure that out? |
| 19:57:18 | FromDiscord | <treeform> I ran 25,000 threads on Windows and it ran ok... Do we really need async? |
| 19:57:43 | disruptek | it makes sharing memory quite a bit easier. |
| 20:00:17 | * | gangstacat quit (Ping timeout: 276 seconds) |
| 20:04:23 | lqdev[m] | disruptek: yeah, a `ISwearIKnowWhatIAmDoing` parameter which causes a compilation error `user doesn't know what they're doing` when set to false. |
| 20:06:05 | disruptek | i was thinking maybe just add `.compileTime.`, but your idea works too. 🤣 |
| 20:12:52 | * | gangstacat joined #nim |
| 20:14:05 | * | nsf joined #nim |
| 20:21:45 | Zevv | oi rayman22201 how is the async discussio going then |
| 20:21:53 | Zevv | you dont stop do you |
| 20:22:27 | disruptek | i switched to semaphores but they aren't working, either. |
| 20:26:44 | FromGitter | <alehander42> circle road |
| 20:28:45 | * | Balu_ joined #nim |
| 20:37:24 | * | narimiran quit (Ping timeout: 268 seconds) |
| 20:44:25 | FromDiscord | <kodkuce> +1 on running 25k threads insted async tought, meybe option 2 build some new async that works with newruntime |
| 20:47:47 | FromDiscord | <kodkuce> dom is sharpening his axe |
| 20:48:53 | rayman22201 | My sole purpose in Nim right now is making async work with new runtime. |
| 20:49:19 | FromDiscord | <kodkuce> i would blow you if i were a girl xD |
| 20:49:47 | rayman22201 | And also fighting Dom with my +1 sword of yak shaving |
| 20:50:22 | * | GordonBGood quit (Remote host closed the connection) |
| 20:51:05 | rayman22201 | Lol. I appreciate the sentiment but I'm happily married :-P |
| 20:52:25 | rayman22201 | Zevv which async discussion are you referring to? There are so many *threads* xD |
| 20:52:27 | FromDiscord | <kodkuce> ok then when you go on dungeon run to kill all mighty Dom i can play support or suicide tank while you kill him |
| 20:56:02 | rayman22201 | In all seriousness, I'm in a support roll. The real work for the better multithreaded async runtime is mratsim and project Picasso. |
| 20:57:06 | Zevv | rayman22201: all of them. youre like a pitbull there |
| 20:57:27 | rayman22201 | X.X |
| 20:57:32 | FromGitter | <auxym> any reason why `new` isn't called implicitly on `result` in procs returning ref types? (that was the cause of my segfault earlier...) |
| 20:58:06 | disruptek | yeah, that would cause an undesireable alloc sometimes. |
| 20:58:36 | rayman22201 | This ^ |
| 21:00:38 | FromGitter | <auxym> aight, just wondering, seemed like a gotcha especially since there isn't even a compile time warning |
| 21:00:51 | disruptek | what would it say? |
| 21:01:47 | disruptek | nil is a valid value for a ref type. you might be returning a ref that you pluck somehow from other inputs to the proc, or even values outside the closure. check your assumptions. |
| 21:03:40 | FromGitter | <auxym> I see. Would it be possible in some limited cases to warn at compiletime against assignments on fields of `nil` refs? Just thinking out loud, have no idea if this is possible |
| 21:03:53 | FromGitter | <auxym> (and I'm entirely aware the mistake is mine) |
| 21:05:08 | disruptek | it's easy to do at runtime, but i'm not sure it's possible at compile-time. interesting question. |
| 21:05:21 | rayman22201 | No nil refs is currently being worked on |
| 21:06:16 | disruptek | i can't think of a way to do it, but i wouldn't dare to say it's impossible. |
| 21:07:43 | disruptek | there are ways you could hack in that functionality, with eg. overloading `.` or using macros to wrap field accesses and register assignments, etc. it's a lot of work for very little gain. |
| 21:08:27 | disruptek | what field are you in? |
| 21:08:55 | disruptek | if it's e-sports, i'd say go nuts. if you're in the medical field, i say please no. i value dom96 too highly. |
| 21:12:04 | rayman22201 | https://github.com/nim-lang/RFCs/pull/169 |
| 21:12:12 | rayman22201 | https://github.com/nim-lang/Nim/pull/12401 |
| 21:14:13 | rayman22201 | mostly I am in the field of bullshitting. Don't get the wrong impression. I also value dom96 very highly! |
| 21:15:17 | disruptek | no, i know your field. i was directing that at auxym. 😜 |
| 21:16:16 | rayman22201 | lol. fair enough :-) |
| 21:16:52 | FromGitter | <auxym> toying around mostly :) thanks for humoring me though! |
| 21:17:47 | rayman22201 | The thing about refs, I find it most helpful to think about them as a fancy pointers. |
| 21:18:09 | rayman22201 | just like you can return a null pointer, you can return a nil ref. |
| 21:19:46 | rayman22201 | But, when we finally get #12401, IMO you will get a lot of the null safety you are looking for though. stay tuned :-P |
| 21:20:13 | disruptek | yep, it'll be a really nice improvement. |
| 21:21:58 | rayman22201 | @Zevv, My biggest annoyance right now is that I found a race condition in Virtual Async Events. |
| 21:22:01 | * | jjido joined #nim |
| 21:22:51 | rayman22201 | The thing I don't understand is that I would expect regular Async Events to have the same race condition, but it doesn't. |
| 21:23:45 | rayman22201 | This has me totally confused. I need to dig into the epoll Select Event implementation weeds again to see exactly what's happening there. |
| 21:24:47 | * | solitudesf- quit (Ping timeout: 265 seconds) |
| 21:25:24 | rayman22201 | unfortunately I am quite busy with real life things this weekend, so I won't really have time to investigate for a while. :/ |
| 21:25:37 | rayman22201 | speaking of which, bbl |
| 21:28:49 | FromGitter | <auxym> rayman22201: #12401 sounds great! |
| 21:31:05 | Zevv | rayman22201: I'd be happy to look into your issues tomorrow. But I'm kind of not in the proper state of mind at this moment for any task requiring rational thinking |
| 21:31:27 | disruptek | Zevv: is kodkuce over at your place? |
| 21:31:33 | rayman22201 | lol. I'm jealous :-P |
| 21:31:49 | Zevv | what is kodkcuse |
| 21:32:03 | rayman22201 | I'll poke you with more details tomorrow if I can |
| 21:32:12 | Zevv | please do |
| 21:34:39 | Zevv | rayman22201: the good thing is that *you* found it, and not cheatfate, right? |
| 21:39:41 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 21:39:41 | * | filcuc quit (Ping timeout: 268 seconds) |
| 21:41:17 | rayman22201 | lol :/ |
| 21:41:55 | * | Vladar quit (Quit: Leaving) |
| 21:50:32 | * | sagax joined #nim |
| 21:57:54 | * | stefantalpalaru quit (Quit: stefantalpalaru) |
| 22:00:25 | * | stefantalpalaru joined #nim |
| 22:03:34 | * | stefantalpalaru quit (Client Quit) |
| 22:05:11 | * | stefantalpalaru joined #nim |
| 22:10:01 | * | stefantalpalaru quit (Client Quit) |
| 22:10:10 | * | stefantalpalaru joined #nim |
| 22:27:24 | * | stefantalpalaru quit (Changing host) |
| 22:27:24 | * | stefantalpalaru joined #nim |
| 22:35:42 | FromDiscord | <kodkuce> lol |
| 22:36:11 | * | thomasross joined #nim |
| 22:39:12 | * | oculux joined #nim |
| 22:41:17 | * | oculuxe quit (Ping timeout: 240 seconds) |
| 22:45:30 | * | Hideki_ joined #nim |
| 22:49:38 | * | Hideki_ quit (Ping timeout: 240 seconds) |
| 22:52:54 | * | ng0 joined #nim |
| 23:01:26 | * | Hideki_ joined #nim |
| 23:16:26 | * | tklohna_ quit (Ping timeout: 252 seconds) |
| 23:17:06 | * | krux02_ joined #nim |
| 23:17:19 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 23:19:52 | * | krux02 quit (Ping timeout: 264 seconds) |
| 23:22:52 | * | setenforce quit (Quit: ZNC 1.7.4 - https://znc.in) |
| 23:26:08 | * | zedeus quit (Ping timeout: 245 seconds) |
| 23:26:08 | FromDiscord | <++x;> Been a while since i texted in here |
| 23:26:30 | FromDiscord | <++x;> Seems like the members increased |
| 23:29:51 | * | GordonBGood joined #nim |
| 23:30:27 | * | lritter quit (Ping timeout: 265 seconds) |
| 23:32:01 | * | krux02_ quit (Remote host closed the connection) |
| 23:39:22 | jken | size() does not work for cstrings, anyone know how I can get the size of a string when cast to a cstring? or if there is a difference? |
| 23:44:11 | jken | actually, looks like I can't get the size of a string either! |
| 23:44:54 | * | nsf quit (Quit: WeeChat 2.6) |
| 23:44:58 | jken | new question, how do I get the size of a string? |
| 23:46:42 | jken | string.len * sizeOf(char) ? |
| 23:57:36 | GordonBGood | I would say not quite due to the terminating null... |
| 23:58:10 | GordonBGood | You would have to do (string.len + 1) * char.sizeof |
| 23:58:22 | GordonBGood | https://nim-lang.org/docs/manual.html#types-string-type |
