| 00:08:17 | FromGitter | <zacharycarter> yeah - I used emscripten, but haven't messed with NLVM yet - would be a fun exercise |
| 00:10:44 | * | jlhouchin quit (Ping timeout: 250 seconds) |
| 00:14:51 | * | jlhouchin joined #nim |
| 00:16:27 | * | vlad1777d_ quit (Read error: Connection reset by peer) |
| 00:17:10 | * | vlad1777d joined #nim |
| 00:18:31 | * | jlhouchin quit (Remote host closed the connection) |
| 00:19:25 | * | jlhouchin joined #nim |
| 00:26:52 | * | seni quit (Quit: Leaving) |
| 00:31:15 | * | darithorn quit () |
| 00:39:23 | * | smt quit (Read error: Connection reset by peer) |
| 00:41:21 | * | smt joined #nim |
| 00:47:43 | * | xet7 quit (Remote host closed the connection) |
| 00:54:08 | * | vlad1777d quit (Remote host closed the connection) |
| 00:54:59 | * | vlad1777d joined #nim |
| 01:11:35 | * | martin1__ joined #nim |
| 01:18:20 | * | citycide quit (Ping timeout: 250 seconds) |
| 01:20:50 | * | citycide joined #nim |
| 01:28:16 | FromGitter | <arnetheduck> just pushed llvm 7.0 and nim 0.19+ update for `nlvm` |
| 01:31:14 | * | martin1__ quit (Quit: WeeChat 2.1) |
| 01:44:46 | * | zachk quit (Quit: Leaving) |
| 01:45:11 | FromGitter | <Varriount> @arnetheduck Any idea how C functions would be supported in nlvm? |
| 01:45:25 | FromGitter | <Varriount> Any idea how Rust does it? |
| 01:51:41 | FromGitter | <arnetheduck> how do you mean, c functions? |
| 01:57:10 | * | elrood quit (Remote host closed the connection) |
| 01:57:28 | * | Tanger joined #nim |
| 02:03:04 | * | zachk joined #nim |
| 02:03:07 | * | btbytes joined #nim |
| 02:03:33 | * | zachk quit (Changing host) |
| 02:03:33 | * | zachk joined #nim |
| 02:06:22 | FromGitter | <zacharycarter> I'm giving up on my gamejam project, and instead going to write a UO emulator with Nim |
| 02:06:30 | FromGitter | <zacharycarter> this is the code I'm untangling - https://github.com/ServUO/ServUO/blob/master/Server/Main.cs |
| 02:06:33 | FromGitter | <zacharycarter> god help me |
| 02:12:25 | FromGitter | <Varriount> @arnetheduck Yeah. |
| 02:12:35 | FromGitter | <Varriount> @zacharycarter UO? |
| 02:13:50 | FromGitter | <zacharycarter> Ultima Online |
| 02:13:56 | FromGitter | <zacharycarter> @Varriount ^ |
| 02:14:33 | FromGitter | <zacharycarter> https://uo.com/screenshots/ |
| 02:14:40 | * | rlr quit (Quit: quitting) |
| 02:15:43 | FromGitter | <zacharycarter> these are screenshots from after UO became shitty though |
| 02:16:31 | * | martin1__ joined #nim |
| 02:17:02 | martin1__ | o/ all! question, how do I get nimpretty? I thought it was included in the standard installation but I can't seem to find it |
| 02:18:22 | FromGitter | <zacharycarter> https://www.gdcvault.com/play/1016629/Classic-Game-Postmortem-Ultimavv |
| 02:19:57 | FromGitter | <zacharycarter> if you want to talk about emergent gameplay |
| 02:20:08 | FromGitter | <zacharycarter> there is nothing comparable to UO |
| 02:22:24 | FromGitter | <arnetheduck> @Varriount sorry, I don't understand the question.. C functions are compiled to.. machine code library functions that use the C ABI - nlvm can generate C-ABI-conformant calls, as can rust.. Nim language is underspecified in terms of ABI so there's no freedom to use any other ABI than C, realistically. rust has its own ABI, then if you want to interact with C, you have to ask for the C ABI specifically (for your |
| 02:22:24 | FromGitter | ... types / functions) |
| 02:24:01 | FromGitter | <Varriount> @arnetheduck Ah, I see. So nlvm can interoperate with compiled C libraries, but it can't do things like "include" headers of a C library. |
| 02:30:12 | FromGitter | <arnetheduck> well, C header files basically describe the ABI of the stuff you'll find in compiled libraries - but you can also write these same descriptions in other languages (rust etc) if they're sufficiently powerful. nim is not (hence it needs to `include`header files so that the underlying `C` compiler will take care of it) but it's close enough to cover a lot of ground. there's nothing special about header files really - |
| 02:30:12 | FromGitter | ... instead of using the one from the upstream project, you could just write your own for a particular library, but it tends to be convenient to not do that |
| 02:40:59 | FromGitter | <arnetheduck> another difference I guess is that rust does not use header files to describe the ABI of the library code it generates.. instead, the compiler generates the ABI description and writes it together with the object - this way, there's fewer ways to screw up, because there's no risk of library and header file mismatch (ie in C, there' no guarantee that a particular version of a header file matches the compiled library) |
| 02:41:42 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 02:46:42 | * | dddddd quit (Remote host closed the connection) |
| 02:48:19 | * | btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 03:01:48 | * | darithorn joined #nim |
| 03:05:24 | * | banc quit (Quit: ZNC - http://znc.in) |
| 03:24:19 | * | banc joined #nim |
| 03:25:21 | FromGitter | <kaushalmodi> martin1__: You need to build nimpretty from Nim devel source |
| 03:25:49 | FromGitter | <kaushalmodi> But it's very straightforward |
| 03:26:51 | FromGitter | <kaushalmodi> Clone the repo, cd to nimpretty, and nim c nimpretty |
| 03:29:20 | * | endragor joined #nim |
| 03:38:34 | * | zachk quit (Quit: Leaving) |
| 03:56:49 | * | vlad1777d quit (Ping timeout: 268 seconds) |
| 04:01:06 | martin1__ | thanks!! |
| 04:02:59 | * | jlhouchin quit (Ping timeout: 268 seconds) |
| 04:24:33 | * | smt quit (Read error: Connection reset by peer) |
| 04:35:48 | * | kapil____ joined #nim |
| 05:23:09 | * | martin1__ quit (Ping timeout: 268 seconds) |
| 05:29:33 | * | nsf joined #nim |
| 05:48:43 | * | rlr joined #nim |
| 05:52:42 | * | miran joined #nim |
| 06:03:08 | * | vlad1777d joined #nim |
| 06:09:28 | * | darithorn quit () |
| 06:52:39 | * | voiceftp quit (Remote host closed the connection) |
| 06:59:24 | * | mech422_ joined #nim |
| 07:01:44 | * | voiceftp joined #nim |
| 07:03:03 | * | mech422__ quit (Ping timeout: 268 seconds) |
| 07:03:03 | * | miran quit (Ping timeout: 264 seconds) |
| 07:11:13 | FromGitter | <timotheecour> @kaushalmodi @martin or `./koch tools` |
| 07:11:47 | FromGitter | <timotheecour> i mean @ martin1__ |
| 07:17:42 | * | krux02 joined #nim |
| 07:31:15 | * | jjido joined #nim |
| 07:40:10 | FromGitter | <narimiran> @timotheecour but nimpretty isn't inside of the tools folder |
| 07:51:58 | leorize | `koch tools` builds everything, not just nimpretty |
| 08:07:20 | FromGitter | <narimiran> you're right, just tried it and `koch tools` also builds nimpretty. i guess i had some misinformation or i remembered something wrong |
| 08:10:53 | * | jjido quit (Ping timeout: 245 seconds) |
| 08:17:02 | * | jjido joined #nim |
| 08:35:46 | * | jjido quit (Ping timeout: 246 seconds) |
| 08:37:33 | * | xet7 joined #nim |
| 08:51:18 | livcd | nimpretty is the nim fmt tool ? |
| 08:51:46 | * | jjido joined #nim |
| 08:56:57 | FromGitter | <narimiran> yeah |
| 09:00:49 | FromGitter | <alehander42> i always forget to use it |
| 09:01:07 | FromGitter | <alehander42> do you guys have it as a nimble task or precommit tool |
| 09:02:19 | FromGitter | <narimiran> i write pretty code by myself so i don't use it :P :D |
| 09:03:00 | livcd | and it already works ? |
| 09:03:14 | livcd | alehander42: I run go fmt whenever i save. |
| 09:03:52 | FromGitter | <narimiran> livcd yeah, try it, it is quite nice |
| 09:04:16 | FromGitter | <narimiran> and recently it has received lots of improvements/fixes |
| 09:07:56 | * | PMunch joined #nim |
| 09:12:44 | Araq | https://github.com/joeatbayes/StockCSVAndSMAPerformanceComparison/issues/1 help me guys :-) |
| 09:19:10 | * | floppydh joined #nim |
| 09:24:29 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 09:28:09 | FromGitter | <narimiran> Araq: i'll try to refactor the used nim code. but usually in these kinds of tasks i came to the conclusion "whatever i do, no matter how much i optimize, @mratsim will make code at least 10x more faster" :D |
| 09:28:24 | FromGitter | <mratsim> lolwut? |
| 09:28:47 | PMunch | Haha |
| 09:29:02 | FromGitter | <mratsim> na, things that involves strings are not for me (yet) |
| 09:29:06 | PMunch | Well a trivial test with parsecsv doesn't seem to make it that much faster |
| 09:29:24 | FromGitter | <mratsim> This is the fastest CSV parser I came across: https://github.com/BurntSushi/xsv |
| 09:29:41 | FromGitter | <mratsim> Tested on my lightweight 2GB+ data science CSVs |
| 09:29:59 | FromGitter | <mratsim> (it’s by the author of ripgrep by the way) |
| 09:30:45 | FromGitter | <mratsim> > Quantized Classifier A Machine Learning classifier using novel techniques that delivers precision at 100% recall comparable to with Deep Learning CNN for many classification tasks while running many times faster. If is written in GO and available on a MIT license. ⏎ ^ uh? this is highly doubtful |
| 09:30:57 | FromGitter | <mratsim> from the https://github.com/joeatbayes/StockCSVAndSMAPerformanceComparison#some-of-my-other-projects |
| 09:31:34 | PMunch | Hmm, anyone got any large csv files? |
| 09:31:43 | PMunch | The one in the repo is only 4.9Mb |
| 09:31:59 | FromGitter | <mratsim> otherwise just add that to the repo: https://nim-lang.org/blog/2017/05/25/faster-command-line-tools-in-nim.html |
| 09:36:52 | PMunch | http://ix.io/1ro8/ |
| 09:37:07 | PMunch | Seems to be about the same speed, this is running on the csv file in the repo |
| 09:39:50 | Araq | put it in a main proc |
| 09:41:59 | PMunch | That made it slightly faster: http://ix.io/1ro9/ |
| 09:42:36 | Araq | I don't understand it, our csvparser used to be good in benchmarks |
| 09:43:19 | PMunch | http://ix.io/1roa/ |
| 09:43:26 | PMunch | Hmm, looks like it might be gc related |
| 09:43:55 | PMunch | This is on devel by the way |
| 09:44:28 | Araq | well it allocates a lot, my old nemesis |
| 09:47:10 | Araq | tried --gc:markAndSweep ? |
| 09:51:27 | PMunch | Yeah, about the same as boehm: http://ix.io/1roc/ |
| 09:53:07 | PMunch | cpp + markandSweep seems to be the fastest |
| 09:57:42 | Araq | hmm ok |
| 10:12:32 | Araq | hey ho, 6000 stars |
| 10:12:42 | PMunch | Nice |
| 10:13:54 | * | martin1__ joined #nim |
| 10:16:22 | FromGitter | <gogolxdong> What would the compile time be if chrome written in Nim? Last time I compile chrome takes 7 hours. |
| 10:17:08 | * | jlhouchin joined #nim |
| 10:18:54 | Araq | unknown, maybe 30 minutes but until incremental builds work, Nim is not all that great at compile-times |
| 10:18:55 | FromGitter | <gogolxdong> Is there an estimation? |
| 10:19:47 | FromGitter | <gogolxdong> That's great. |
| 10:20:25 | Calinou | Nim builds itself fairly fast for a full-blown language, so it's not too bad |
| 10:20:29 | Calinou | but yeah, there's no incremental builds yet |
| 10:24:59 | federico3 | few seconds with a globally distributed cache |
| 10:26:25 | * | deathpoison joined #nim |
| 10:26:40 | FromGitter | <alehander42> and if 50% of your files are dirty, no cache can save it |
| 10:27:03 | * | craigger_ joined #nim |
| 10:27:07 | FromGitter | <alehander42> e.g. when you change something that a lot of files depend on |
| 10:27:41 | FromGitter | <alehander42> but I agree in some cases this would be very cool :D |
| 10:27:47 | * | craigger quit (Ping timeout: 240 seconds) |
| 10:33:02 | Calinou | federico3: how do you set up a globally distributed cache? |
| 10:33:17 | Calinou | also, does using ccache benefit the Nim compiler? |
| 10:34:23 | * | ghost64 quit (Quit: See you!) |
| 10:35:41 | FromDiscord_ | <PusiteGA> how do you handle if i have 100procs and i for example my Car type i need only drive , opentrunk , crash , but autocomplete in vscode shows me all 100procs , can this be like fixed somehow to show only thise3 procs or even beter leave all 100procs but just put drive,opentrunk,crash ontop of autocomplete list |
| 10:36:39 | * | martin1__ quit (Ping timeout: 264 seconds) |
| 10:36:51 | * | ghost64 joined #nim |
| 10:37:30 | FromGitter | <narimiran> start typing first letters of what you want? :) |
| 10:39:11 | FromDiscord_ | <PusiteGA> yep but then i need to know how i named all my procs for car in my head |
| 10:40:17 | FromGitter | <narimiran> export just those three, and then in other file you will have autocomplete for only them? |
| 10:41:21 | FromDiscord_ | <PusiteGA> hmm will try that but dont think that will work, it will still show procs from all other files i think |
| 10:41:41 | * | Yardanico joined #nim |
| 10:42:33 | FromDiscord_ | <PusiteGA> or meybe i can just fallow some naming convection, if i am making like OOP stuff i can create object Car and then name all function CarOpenTrunk |
| 10:42:35 | FromGitter | <narimiran> not if Car is the first argument to your functions, and you type `myCar.` |
| 10:43:04 | FromGitter | <narimiran> don't use PascalCase (uppercase first letter) for procs |
| 10:45:56 | federico3 | Calinou: it would be interesting to find out if sccache can be used with Nim and how well it works |
| 10:51:32 | Calinou | distcc-like systems aren't very useful for me |
| 10:51:56 | Calinou | it would be nice to create a Mainframer template for Nim projects perhaps still: https://github.com/buildfoundation/mainframer |
| 10:52:07 | Calinou | remote building is useful when I'm on a laptop and don't want to kill its battery, since I have a 8-core VPS |
| 10:59:55 | federico3 | meh |
| 11:00:29 | Calinou | to each their own, but I don't have access to a build farm or work in a company as a C/C++ developer :) |
| 11:00:51 | Calinou | the Mainframer template should be an easy thing, see the Cargo example. It's just so people can copy-paste it and get going in minutes |
| 11:01:09 | federico3 | a lot of hype for rsync+ssh |
| 11:03:03 | Calinou | heh, pretty much but it makes it simpler |
| 11:27:48 | * | Perkol joined #nim |
| 11:28:42 | Perkol | How do I check if element not in array? |
| 11:34:38 | * | kapil____ joined #nim |
| 11:37:23 | leorize | Perkol: `e notin a` |
| 11:43:17 | * | deathpoison quit (Read error: Connection reset by peer) |
| 11:47:42 | * | ghost64 quit (Quit: See you!) |
| 11:51:26 | * | ghost64 joined #nim |
| 11:56:02 | * | Perkol quit (Quit: Leaving) |
| 12:06:47 | * | smt joined #nim |
| 12:17:25 | * | dddddd joined #nim |
| 12:28:43 | * | Snircle joined #nim |
| 13:05:54 | * | jjido quit (Ping timeout: 264 seconds) |
| 13:12:50 | * | platoff joined #nim |
| 13:13:11 | * | Vladar joined #nim |
| 13:25:25 | FromGitter | <mratsim> for set or tables |
| 13:25:41 | FromGitter | <mratsim> is contain defined on array? I would be surprised since it’s not O(1) |
| 13:30:24 | Araq | it is |
| 13:31:14 | Araq | defined. not O(1) but that's not important, you can profile your code |
| 13:33:14 | FromGitter | <alehander42> can't wait for a algo complexity aspect of a type system :D |
| 13:33:56 | FromGitter | <arnetheduck> ooh! if you could annotate your functions with their complexity and have the language do an automatic analysis... |
| 13:37:46 | FromGitter | <alehander42> oh yeah, I wondered about that before |
| 13:37:54 | FromGitter | <alehander42> I found some cost-based type system papers |
| 13:38:06 | FromGitter | <alehander42> which deal with similar stuff, but I don't think there was mainstream lang doing it |
| 13:38:58 | FromGitter | <alehander42> I suspect it might be very hard to do in general, e.g. sometimes you'll probably hit recurrent relationships etc |
| 13:39:02 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 13:41:36 | FromGitter | <alehander42> ah yeah the inria guys |
| 13:41:37 | FromGitter | <alehander42> http://gallium.inria.fr/~fpottier/slides/fpottier-2011-01-jfla.pdf |
| 13:47:48 | FromGitter | <yglukhov> Araq: just noticed you're moving ospaths back to os. What's the reason for this? I kinda like the fact they are separate. IMO semantically ospaths imply zero reliance on the os or filesystem. ospaths are portable (and semantically correct) across all platforms including in-browser JS, but that's not the case with os. |
| 13:50:49 | Yardanico | 6k stars, yay! :) |
| 13:57:20 | Araq | yglukhov: found a way to make os.nim work with NimScript and NimScript is easier to use when there are fewer special rules |
| 13:57:53 | Araq | also ospaths grew some stuff that it not just string handling with paths so the distinction became arbitrary |
| 13:59:39 | FromGitter | <yglukhov> I understand that it's technically possible to merge ospaths with os, I just liked this os-agnostic distinction, and if you ask me, would keep it that way, and fix it if the distinction went arbitrary. |
| 14:02:17 | FromGitter | <yglukhov> e.g. seing `import os` in a module tells me this module depends on the environment somehow. basically "has side effects" =) |
| 14:02:35 | Araq | well ospaths exists for Nimscript and if we enable e.g. createDir for NimScript this couldn't be moved from os to ospaths and instead nimscript.nim got the declaration ... it's all messed up |
| 14:03:08 | Araq | things were better before we had ospaths IMO. |
| 14:03:38 | Araq | also there are things like isHidden() which is an OS call on Windows but string handling on Unix |
| 14:04:29 | FromGitter | <alehander42> maybe we can have ospaths for e.g. JavaScript which just export the things which are really compatible with everything |
| 14:05:54 | FromGitter | <yglukhov> piling everything into one heap is one way to fix it of course. the other way would be to tidy it up and make it uniform for nimscript and nim. surely that would be more difficult, but its worth it in the long run imo. |
| 14:06:26 | FromGitter | <yglukhov> but maybe its just me... |
| 14:08:49 | Araq | yglukhov: if we split it up further other things come to mind |
| 14:09:38 | Araq | for example, ospaths, osstat, osdirs, oswalk |
| 14:10:00 | Araq | osenv |
| 14:10:51 | FromGitter | <yglukhov> well. ospaths are just paths (strings) to me. osstat, osdirs, oswalk is fs interaction. os is environment, currentdir, etc... |
| 14:11:50 | FromGitter | <yglukhov> maybe it should be std/paths, std/os, and std/fs? =) |
| 14:12:11 | Araq | the problem with strutils and os and maybe time is that you end importing stuff that you don't need all the time. and while that has no runtime cost, compile-times and memory usage of the compiler increase |
| 14:12:53 | FromGitter | <yglukhov> so how is your os+ospaths merge is going to help here? =) |
| 14:13:07 | * | nsf quit (Quit: WeeChat 2.3) |
| 14:25:04 | * | masterm quit (Read error: Connection reset by peer) |
| 14:27:44 | * | endragor quit (Remote host closed the connection) |
| 14:29:02 | * | dom96_w joined #nim |
| 14:32:20 | * | platoff quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 14:38:21 | * | floppydh quit (Quit: WeeChat 2.3) |
| 14:42:07 | * | endragor joined #nim |
| 14:43:49 | Araq | well not at all, but if we change it there are good arguments for splitting up further |
| 14:46:00 | FromGitter | <yglukhov> Are you saying if we merge ospaths+os there are good arguments for splitting up further? Or if we keep os and ospaths separate there are good arguments for splitting up further? |
| 14:46:47 | * | endragor quit (Ping timeout: 268 seconds) |
| 14:48:13 | FromGitter | <yglukhov> Actually I'm not concerned about nim performance that much. That's just an implementation detail that doesn't affect language semantics. What I care about is the semantics and usability in terms of stdlib interface. |
| 14:49:42 | * | PMunch quit (Quit: Leaving) |
| 14:51:53 | Araq | no, I like a big os.nim because that's what every Nim program out there is used to |
| 14:52:55 | Araq | but there would be good arguments for a splitted os.nim |
| 14:53:19 | Araq | and usability is improved with the os,ospaths merge |
| 15:05:52 | * | dom96_w quit (Changing host) |
| 15:05:52 | * | dom96_w joined #nim |
| 15:06:37 | * | Zevv joined #nim |
| 15:13:51 | FromGitter | <yglukhov> Ok, but what's the problem with os reexporting ospaths as it is now? The merge will not change anything for "every Nim program out there". But it will make my nim programs slightly less readable. Not to mention I would remove even exporting ospaths from os, but you'll find it too radical :). |
| 15:20:47 | shashlick | have been playing around with wrapping libclang for https://github.com/nim-lang/Nim/issues/8327 and man is it a can of worms |
| 15:26:33 | * | platoff joined #nim |
| 15:27:20 | krux02 | shashlick, yea let timothee do it |
| 15:27:49 | krux02 | even c++ doesn't have wrapper free interop with c++ you nee do write headers |
| 15:28:43 | shashlick | that's fine - my thought is to make the wrapper invisible to consumer |
| 15:29:10 | krux02 | I don't that it even is a good idea |
| 15:29:36 | krux02 | because the wrapper is always a possible source of problems, and then you wand anything but an invisible wrapper |
| 15:30:00 | krux02 | you want to be able to see the wrapper and be able to agree or disagree on how it works |
| 15:30:39 | shashlick | well how it works would need to be documented |
| 15:31:01 | shashlick | C/C++ data types mapping to Nim |
| 15:31:10 | krux02 | yea and documentation is the strength on Nim programs |
| 15:32:12 | shashlick | the C/C++ headers already exist for the lib that needs to be consumed so how it works is already evident |
| 15:32:55 | shashlick | no need for an intermediate representation in nim |
| 15:33:36 | * | mosORadi joined #nim |
| 15:34:53 | * | alehander42 joined #nim |
| 15:35:17 | alehander42 | hm mode_t is nice |
| 15:37:08 | * | alehander42 quit (Remote host closed the connection) |
| 15:37:40 | * | alehander42 joined #nim |
| 15:40:02 | krux02 | shashlick, a good wrapper doesn't need the original header anymore, it replaces it. |
| 15:40:49 | shashlick | well if you are planning on using a C/C++ lib for some reason, you need to know how to use it |
| 15:40:55 | shashlick | it will be documented by that author |
| 15:41:30 | shashlick | so putting a Nim spin on it means additional documentation burden for the wrapper author or maintainer |
| 15:41:41 | shashlick | as well as for the consumer who needs to understand the interop |
| 15:42:25 | shashlick | i guess there's no escape but one can aspire to make life easier for others eh |
| 15:44:32 | krux02 | if you want wrapper free interop, use {.emit:"...".} |
| 15:44:37 | krux02 | it works |
| 15:46:27 | * | flyx quit (Ping timeout: 240 seconds) |
| 15:49:11 | * | Zevv left #nim (#nim) |
| 15:49:57 | * | natrys joined #nim |
| 15:53:15 | * | flyx joined #nim |
| 15:55:22 | * | citycide quit (Ping timeout: 246 seconds) |
| 15:57:27 | * | citycide joined #nim |
| 15:57:33 | * | iffy joined #nim |
| 15:57:43 | * | iffy left #nim (#nim) |
| 15:58:14 | * | darithorn joined #nim |
| 15:59:33 | * | dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:02:09 | shashlick | can you refer to nim objects within emit somehow? |
| 16:03:07 | * | dom96_w joined #nim |
| 16:04:19 | * | dom96_w quit (Client Quit) |
| 16:05:01 | shashlick | not really extensive looks like |
| 16:07:22 | * | dom96_w joined #nim |
| 16:08:45 | * | miran joined #nim |
| 16:09:03 | benjikun | Araq: How does nim compare to felix? https://github.com/felix-lang/felix |
| 16:10:24 | benjikun | Is it the same sort of "generate optimized C/C++ code and then build from that" idea |
| 16:13:29 | * | PMunch joined #nim |
| 16:15:17 | * | copygirl quit (Quit: copygirl) |
| 16:23:22 | * | dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:26:17 | * | Trustable joined #nim |
| 16:28:12 | FromGitter | <yglukhov> shashlick: you can. use backticks. |
| 16:29:01 | * | dom96_w joined #nim |
| 16:30:39 | FromGitter | <arnetheduck> krux02, did you ever get around to implementing alignments and offsets btw? ie the full thing, with platforms / compiler options / os / underlying compiler affecting layout? |
| 16:31:04 | miran | benjikun: i'm looking at the felix tutorial and the first thing that i've seen is so many unneeded semicolons :) |
| 16:32:30 | krux02 | arnetheduck: actually yes |
| 16:32:47 | alehander42 | the new sizeof is neat |
| 16:33:01 | krux02 | alehander42, thanks |
| 16:33:09 | shashlick | yglukhov: looks like that is deprecated - `For backwards compatibility, if the argument to the emit statement is a single string literal, Nim symbols can be referred to via backticks. This usage is however deprecated.` |
| 16:33:10 | krux02 | was a lot of headache |
| 16:33:23 | FromGitter | <arnetheduck> oh cool - how does it work? ie doubles are sometimes 4 and sometimes 8-byte aligned - where do I see which one is used? |
| 16:33:34 | FromGitter | <arnetheduck> ie where in the compiler code |
| 16:33:52 | krux02 | specifically the platform dependent alignment part was a mess. But after all it is just about initializing the alignment and size values correctly for the base types |
| 16:35:05 | krux02 | somewhere in the compiler there is branching that detects the platform and initializes the alignment value for float64 int64 |
| 16:35:16 | FromGitter | <yglukhov> shaslick: i think it has to be reconsidered. the backticks feature is super useful in a lot of usecases. new emit syntax also has an answer to your question, but I find the syntax too awkward. but it can be used in more contexts than the old syntax. |
| 16:35:49 | krux02 | when you are not 100% sure if the logic is correct in your platform, there is a test tsizeof..something just run it on your platform and see the results |
| 16:36:26 | krux02 | the test is pretty extensive the only thing it can't test is the alignment of a platform that it isn't executed on |
| 16:37:20 | krux02 | so if you have an obscure platform with obscure alignment rules that logic might be wrong, but the test will catch it and the logic can be updated to handle that platform |
| 16:38:17 | miran | benjikun: but other than that, it looks like fun |
| 16:39:36 | FromGitter | <arnetheduck> not sure about "obscure", but if you mean tests/misc/tsizeof, it fails on rpi3 :) |
| 16:39:53 | FromGitter | <arnetheduck> `````` |
| 16:40:21 | krux02 | :( |
| 16:40:41 | krux02 | I have a raspberry pi 3 so I could run the test on it |
| 16:40:56 | krux02 | but I need a new SD card for it I like my emulationstation |
| 16:41:08 | FromGitter | <arnetheduck> that's running a 32-bit arm os (rasbian) |
| 16:41:12 | alehander42 | arnetheduck, please don't edit your gitter msg |
| 16:41:35 | * | copygirl joined #nim |
| 16:41:51 | alehander42 | it seems it isn't resend in irc (i am on both and I am very surprised to see it, I edit my msg often :D ) |
| 16:42:05 | FromGitter | <arnetheduck> right |
| 16:43:37 | FromGitter | <arnetheduck> actually, @krux02, that's a plain 0.19 version (not devel).. is that fresh enough? |
| 16:44:14 | krux02 | I think so |
| 16:44:17 | krux02 | https://github.com/nim-lang/Nim/blob/devel/compiler/semtypes.nim#L1698 |
| 16:44:22 | krux02 | there is the logic |
| 16:44:51 | krux02 | implement the logic for rpi and it should work |
| 16:44:59 | * | wildlander joined #nim |
| 16:46:13 | krux02 | @arnetheduck: there is a comment in the code # Assuming that since ARM, ARM64 don't support unaligned access |
| 16:48:15 | * | jacereda joined #nim |
| 16:48:37 | krux02 | pull requests are very welcome here |
| 16:49:16 | FromGitter | <yglukhov> lack of unaligned access support doesn't prevent you from using packed (and thus unaligned) structs though |
| 16:49:56 | FromGitter | <arnetheduck> I'd assume where that is a problem, the c compiler generally does byte-by-byte copies to a register first |
| 16:50:04 | FromGitter | <yglukhov> yep |
| 16:51:21 | FromGitter | <arnetheduck> that doesn't help when you want to rely on sizeof/offsetof etc.. |
| 16:52:05 | krux02 | as I told you the tests are extensive and packed is fully supported |
| 16:52:25 | krux02 | so when you are worried, just use packed and do manual alignment with padding byte arrays |
| 16:52:56 | krux02 | or fix the logic for your platform |
| 16:53:48 | benjikun | miran: Yeah, I think it looks pretty cool |
| 16:55:39 | FromGitter | <arnetheduck> I wonder though, the github page states: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ is ppc64/armv6l tested anywhere? [https://gitter.im/nim-lang/Nim?at=5be5bc0bc0e6da07fefdb04d] |
| 17:01:35 | * | dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:06:38 | FromGitter | <krux02> we support it, we don't claim it is totally bug free |
| 17:07:17 | * | dom96_w joined #nim |
| 17:10:21 | FromGitter | <arnetheduck> wouldn't "support" imply though that at least the test suite passes? |
| 17:11:28 | FromGitter | <arnetheduck> ie gcc and others solve this by having "secondary" platforms that are kind of supposed to work, but don't receive regular testing |
| 17:20:08 | * | alehander42 quit (Remote host closed the connection) |
| 17:23:50 | * | MyMind joined #nim |
| 17:24:13 | * | Sembei quit (Ping timeout: 245 seconds) |
| 17:38:23 | FromGitter | <brentp> I was expecting this code: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ to result in `4`, instead it shows `12`. Is this a peculiarity of sizeof in nim or is it actually 12 bytes? [https://gitter.im/nim-lang/Nim?at=5be5c60e7326df140eddae04] |
| 17:38:39 | * | kapil____ joined #nim |
| 17:41:23 | leorize | an object contains some padding and a structure that holds the type info AFAIK |
| 17:41:37 | leorize | try adding the `{.pure.}` pragma after `A*` |
| 17:41:53 | miran | leorize: object containing one int16 has size 2 |
| 17:42:49 | * | mosORadi quit (Quit: Connection closed for inactivity) |
| 17:43:38 | leorize | I stand corrected |
| 17:43:49 | leorize | on 0.18.0 it does output the desired result |
| 17:43:52 | FromGitter | <brentp> I think this worked fairly recently. |
| 17:44:35 | leorize | probably a regression, you should file an issue |
| 17:46:19 | miran | can confirm, on 0.19.0 outputs 4, on devel is 12 |
| 17:48:35 | FromGitter | <brentp> done: https://github.com/nim-lang/Nim/issues/9668 |
| 17:50:43 | FromGitter | <brentp> thanks for verifying @leorize and @miran |
| 17:57:16 | * | Aareon_ joined #nim |
| 18:17:14 | * | miran is now known as narimiran |
| 18:20:58 | * | smt quit (Read error: Connection reset by peer) |
| 18:23:56 | * | nsf joined #nim |
| 18:24:58 | * | HuntRD joined #nim |
| 18:31:54 | * | HuntRD quit (Quit: Leaving) |
| 18:33:31 | FromGitter | <kdheepak> @yglukhov I have a really dumb question about nimpy, when this issue (https://github.com/yglukhov/nimpy/issues/18) was closed I thought it would allow raising a Nim Exception and have the equivalent Python Exception generated, but that appears not to be the case. Is that even possible? |
| 18:34:12 | FromGitter | <kdheepak> I've opened an issue to ask a related question here, https://github.com/yglukhov/nimpy/issues/64 mainly because I couldn't find documentation on how to raise the corresponding error. |
| 18:36:58 | narimiran | @kdheepak it seems to me the exceptions work in python->nim direction, not the other way around :/ |
| 18:37:06 | * | Perkol joined #nim |
| 18:40:26 | FromGitter | <kdheepak> I see a `raisePythonError` here: https://github.com/yglukhov/nimpy/blob/3ee68d0/nimpy/py_utils.nim#L127 |
| 18:40:39 | FromGitter | <kdheepak> But this just causes Python to segfault (?) if I call it. |
| 18:41:20 | * | platoff quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:43:05 | FromGitter | <Vindaar> @kdheepak yeah, as narimiran said, issue 18 was closed to support mapping Python exceptions to Nim exceptions. The code you link there is the code that does just that |
| 18:43:48 | FromGitter | <kdheepak> I see. |
| 18:44:03 | FromGitter | <kdheepak> I think it shouldn't be too hard to do it the other way around. |
| 18:44:46 | FromGitter | <Vindaar> If I'm not mistaken the following needs to be added: https://docs.python.org/3/c-api/exceptions.html#c.PyErr_NewException to raise from Nim -> Python |
| 18:44:59 | FromGitter | <kdheepak> That's correct. |
| 18:46:12 | * | awal quit (Quit: ZNC 1.6.4 - http://znc.in) |
| 18:52:38 | FromGitter | <kdheepak> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5be5d7767326df140ede28a9] |
| 18:54:56 | * | smt joined #nim |
| 18:55:20 | FromGitter | <kdheepak> This is the equivalent C code that needs to be generated. |
| 18:57:41 | * | dom96_w quit (Quit: Textual IRC Client: www.textualapp.com) |
| 19:02:23 | * | smt quit (Quit: Leaving) |
| 19:12:47 | * | zachk joined #nim |
| 19:13:30 | * | zachk quit (Changing host) |
| 19:13:30 | * | zachk joined #nim |
| 19:28:31 | * | dddddd quit (Ping timeout: 246 seconds) |
| 19:35:27 | FromGitter | <xmonader> Good evening everyone! |
| 19:39:10 | * | Perkol quit (Quit: Leaving) |
| 19:42:53 | * | dddddd joined #nim |
| 19:43:12 | PMunch | "It's only 600 lines"... |
| 19:46:08 | PMunch | But you have to properly set a 80 field large object.. |
| 19:53:26 | * | Jesin joined #nim |
| 19:57:49 | * | Perkol joined #nim |
| 20:04:25 | * | smt joined #nim |
| 20:07:51 | Perkol | In threadpool module how spawn is different from spawnX? |
| 20:13:14 | Perkol | What does cpu core is ready mean? |
| 20:21:50 | PMunch | Hmm, Araq I can't get the nimsuggest library to work |
| 20:22:08 | PMunch | I echoed out the conf.repr for each of them. And are pretty much the same |
| 20:22:14 | PMunch | But mine doesn't return anything.. |
| 20:25:11 | * | Pisuke joined #nim |
| 20:26:32 | * | MyMind quit (Ping timeout: 244 seconds) |
| 20:28:15 | PMunch | Oh never mind, got it working now |
| 20:28:27 | PMunch | I had forgot to turn on suggestionMode for the graph.. |
| 20:32:11 | Perkol | spawn automatically limits number of running threads? |
| 20:32:48 | Perkol | Not more than MaxThreadPoolSize |
| 20:32:49 | Perkol | ? |
| 20:36:01 | PMunch | Yeah, spawn will not run more threads than MaxThreadPoolSize |
| 20:36:41 | * | Vladar quit (Remote host closed the connection) |
| 20:38:21 | PMunch | spawnX essentially checks if there is a thread running on a CPU core that isn't currently doing anything |
| 20:39:53 | Perkol | What MaxDistinguishedThread does do? |
| 20:41:18 | PMunch | Not sure actually |
| 20:41:21 | PMunch | It doesn't appear to do anything |
| 20:49:57 | * | FromDiscord_ <yspr> awoos |
| 20:50:35 | Perkol | Also, spawn runs into problems when it comes to disc io |
| 20:50:35 | FromGitter | <tim-st> PMunch: do you think the package name suggestion could work with nimlsp ? |
| 20:50:47 | Perkol | Any advice on that? |
| 20:50:47 | PMunch | package name suggestion? |
| 20:51:10 | PMunch | Perkol, what does disk IO have to do with spawn? |
| 20:51:10 | FromGitter | <tim-st> when typed `import a..` it shows all packages with prefix a |
| 20:51:18 | FromGitter | <tim-st> https://gist.github.com/tim-st/df0ce1c4b712abe7d4e2a90f0b8c78a2 |
| 20:51:33 | * | Perkol quit (Remote host closed the connection) |
| 20:51:57 | PMunch | Hmm, yeah I guess it could |
| 20:52:54 | FromGitter | <tim-st> would be very nice, I think the code should work directly on all os'es but only tested on windows |
| 20:53:21 | PMunch | Could you create an issue on the nimlsp repo? |
| 20:53:27 | FromGitter | <tim-st> sure |
| 20:53:29 | PMunch | Just so that I don't forget :) |
| 20:55:33 | FromGitter | <tim-st> btw when you change the temp foler string to "nimlsp" it runs on windows too |
| 20:55:41 | FromGitter | <tim-st> folder |
| 20:55:47 | PMunch | Hmm, not quite sure why. But when I copy nimsuggest to somewhere other than the Nim repo and compile it it's super slow.. |
| 20:56:11 | PMunch | Oh cool |
| 20:56:37 | FromGitter | <tim-st> Though the compilation only works when I think jsonschema debugging is turned off |
| 20:57:23 | PMunch | Hmm, it's slow if I compile it in the Nim folder as well |
| 20:57:44 | PMunch | I guess "koch tools" applies something else than "nimble build" does.. |
| 20:59:12 | PMunch | Oh yeah, changing it to what koch tools uses it's much faster |
| 21:05:43 | * | Trustable quit (Remote host closed the connection) |
| 21:14:34 | * | syfer42 joined #nim |
| 21:15:29 | * | syfer42 quit (Client Quit) |
| 21:16:00 | * | hoijui joined #nim |
| 21:20:51 | * | natrys quit (Quit: natrys) |
| 21:23:10 | * | narimiran quit (Ping timeout: 272 seconds) |
| 21:24:07 | PMunch | Hmm, it tells me that everything is an "Error type" for some reason.. |
| 21:24:37 | PMunch | It also complains about "Error: cannot open '/home/peter/Projects/nimlsp/lib/lib/system.nim'" |
| 21:24:50 | PMunch | It seems like it isn't able to find the system.nim file.. |
| 21:30:45 | * | martin1__ joined #nim |
| 21:37:09 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 21:49:30 | PMunch | Okay, setting that explicitly helps.. |
| 21:49:47 | PMunch | But I use the same code as nimsuggest to find that file.. |
| 22:02:00 | * | Aareon_ quit (Ping timeout: 250 seconds) |
| 22:07:00 | * | martin1_1 joined #nim |
| 22:08:36 | * | Aareon_ joined #nim |
| 22:09:45 | * | martin1__ quit (Ping timeout: 252 seconds) |
| 22:12:22 | * | Yardanico quit (Remote host closed the connection) |
| 22:19:51 | PMunch | Hmm, if I copy the compiled binary into the nimsuggest folder it works |
| 22:20:18 | PMunch | So it seems like it just isn't able to find the config/nim.cfg file when launched from another directory |
| 22:34:30 | PMunch | https://github.com/PMunch/nimlsp/blob/suggestlib/src/nimlsppkg/suggestlib.nim |
| 22:34:43 | PMunch | There is nimsuggest functionality ripped out and put in a library |
| 22:35:37 | PMunch | I'm probably missing something, and it doesn't quite work if it's not in the nimsuggest folder in your Nim installation for some reason. But it's promising |
| 22:37:36 | * | jlhouchin2 joined #nim |
| 22:39:47 | * | jlhouchin quit (Ping timeout: 240 seconds) |
| 22:40:01 | * | PMunch quit (Remote host closed the connection) |
| 22:44:30 | FromGitter | <tim-st> I'd like to test this, but I couldnt get it working with sublime on windows, and with onivim they have the api but they dont support third party lsp plugins currently :\ |
| 23:16:42 | * | jlhouchin2 quit (Quit: Leaving) |
| 23:17:39 | * | hoijui quit (Ping timeout: 252 seconds) |
| 23:33:22 | * | jacereda quit (Remote host closed the connection) |
| 23:33:37 | * | theelous3_ joined #nim |
| 23:33:57 | * | nsf quit (Quit: WeeChat 2.3) |
| 23:52:08 | * | jjido joined #nim |
| 23:58:27 | * | jjido quit (Ping timeout: 240 seconds) |