00:08:17FromGitter<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:16FromGitter<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:11FromGitter<Varriount> @arnetheduck Any idea how C functions would be supported in nlvm?
01:45:25FromGitter<Varriount> Any idea how Rust does it?
01:51:41FromGitter<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:22FromGitter<zacharycarter> I'm giving up on my gamejam project, and instead going to write a UO emulator with Nim
02:06:30FromGitter<zacharycarter> this is the code I'm untangling - https://github.com/ServUO/ServUO/blob/master/Server/Main.cs
02:06:33FromGitter<zacharycarter> god help me
02:12:25FromGitter<Varriount> @arnetheduck Yeah.
02:12:35FromGitter<Varriount> @zacharycarter UO?
02:13:50FromGitter<zacharycarter> Ultima Online
02:13:56FromGitter<zacharycarter> @Varriount ^
02:14:33FromGitter<zacharycarter> https://uo.com/screenshots/
02:14:40*rlr quit (Quit: quitting)
02:15:43FromGitter<zacharycarter> these are screenshots from after UO became shitty though
02:16:31*martin1__ joined #nim
02:17:02martin1__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:22FromGitter<zacharycarter> https://www.gdcvault.com/play/1016629/Classic-Game-Postmortem-Ultimavv
02:19:57FromGitter<zacharycarter> if you want to talk about emergent gameplay
02:20:08FromGitter<zacharycarter> there is nothing comparable to UO
02:22:24FromGitter<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:24FromGitter... types / functions)
02:24:01FromGitter<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:12FromGitter<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:12FromGitter... 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:59FromGitter<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:21FromGitter<kaushalmodi> martin1__: You need to build nimpretty from Nim devel source
03:25:49FromGitter<kaushalmodi> But it's very straightforward
03:26:51FromGitter<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: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:13FromGitter<timotheecour> @kaushalmodi @martin or `./koch tools`
07:11:47FromGitter<timotheecour> i mean @ martin1__
07:17:42*krux02 joined #nim
07:31:15*jjido joined #nim
07:40:10FromGitter<narimiran> @timotheecour but nimpretty isn't inside of the tools folder
07:51:58leorize`koch tools` builds everything, not just nimpretty
08:07:20FromGitter<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:18livcdnimpretty is the nim fmt tool ?
08:51:46*jjido joined #nim
08:56:57FromGitter<narimiran> yeah
09:00:49FromGitter<alehander42> i always forget to use it
09:01:07FromGitter<alehander42> do you guys have it as a nimble task or precommit tool
09:02:19FromGitter<narimiran> i write pretty code by myself so i don't use it :P :D
09:03:00livcdand it already works ?
09:03:14livcdalehander42: I run go fmt whenever i save.
09:03:52FromGitter<narimiran> livcd yeah, try it, it is quite nice
09:04:16FromGitter<narimiran> and recently it has received lots of improvements/fixes
09:07:56*PMunch joined #nim
09:12:44Araqhttps://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:09FromGitter<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:24FromGitter<mratsim> lolwut?
09:29:02FromGitter<mratsim> na, things that involves strings are not for me (yet)
09:29:06PMunchWell a trivial test with parsecsv doesn't seem to make it that much faster
09:29:24FromGitter<mratsim> This is the fastest CSV parser I came across: https://github.com/BurntSushi/xsv
09:29:41FromGitter<mratsim> Tested on my lightweight 2GB+ data science CSVs
09:29:59FromGitter<mratsim> (it’s by the author of ripgrep by the way)
09:30:45FromGitter<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:57FromGitter<mratsim> from the https://github.com/joeatbayes/StockCSVAndSMAPerformanceComparison#some-of-my-other-projects
09:31:34PMunchHmm, anyone got any large csv files?
09:31:43PMunchThe one in the repo is only 4.9Mb
09:31:59FromGitter<mratsim> otherwise just add that to the repo: https://nim-lang.org/blog/2017/05/25/faster-command-line-tools-in-nim.html
09:37:07PMunchSeems to be about the same speed, this is running on the csv file in the repo
09:39:50Araqput it in a main proc
09:41:59PMunchThat made it slightly faster: http://ix.io/1ro9/
09:42:36AraqI don't understand it, our csvparser used to be good in benchmarks
09:43:26PMunchHmm, looks like it might be gc related
09:43:55PMunchThis is on devel by the way
09:44:28Araqwell it allocates a lot, my old nemesis
09:47:10Araqtried --gc:markAndSweep ?
09:51:27PMunchYeah, about the same as boehm: http://ix.io/1roc/
09:53:07PMunchcpp + markandSweep seems to be the fastest
09:57:42Araqhmm ok
10:12:32Araqhey ho, 6000 stars
10:13:54*martin1__ joined #nim
10:16:22FromGitter<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:54Araqunknown, maybe 30 minutes but until incremental builds work, Nim is not all that great at compile-times
10:18:55FromGitter<gogolxdong> Is there an estimation?
10:19:47FromGitter<gogolxdong> That's great.
10:20:25CalinouNim builds itself fairly fast for a full-blown language, so it's not too bad
10:20:29Calinoubut yeah, there's no incremental builds yet
10:24:59federico3few seconds with a globally distributed cache
10:26:25*deathpoison joined #nim
10:26:40FromGitter<alehander42> and if 50% of your files are dirty, no cache can save it
10:27:03*craigger_ joined #nim
10:27:07FromGitter<alehander42> e.g. when you change something that a lot of files depend on
10:27:41FromGitter<alehander42> but I agree in some cases this would be very cool :D
10:27:47*craigger quit (Ping timeout: 240 seconds)
10:33:02Calinoufederico3: how do you set up a globally distributed cache?
10:33:17Calinoualso, does using ccache benefit the Nim compiler?
10:34:23*ghost64 quit (Quit: See you!)
10:35:41FromDiscord_<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:30FromGitter<narimiran> start typing first letters of what you want? :)
10:39:11FromDiscord_<PusiteGA> yep but then i need to know how i named all my procs for car in my head
10:40:17FromGitter<narimiran> export just those three, and then in other file you will have autocomplete for only them?
10:41:21FromDiscord_<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:33FromDiscord_<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:35FromGitter<narimiran> not if Car is the first argument to your functions, and you type `myCar.`
10:43:04FromGitter<narimiran> don't use PascalCase (uppercase first letter) for procs
10:45:56federico3Calinou: it would be interesting to find out if sccache can be used with Nim and how well it works
10:51:32Calinoudistcc-like systems aren't very useful for me
10:51:56Calinouit would be nice to create a Mainframer template for Nim projects perhaps still: https://github.com/buildfoundation/mainframer
10:52:07Calinouremote building is useful when I'm on a laptop and don't want to kill its battery, since I have a 8-core VPS
11:00:29Calinouto 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:51Calinouthe 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:09federico3a lot of hype for rsync+ssh
11:03:03Calinouheh, pretty much but it makes it simpler
11:27:48*Perkol joined #nim
11:28:42PerkolHow do I check if element not in array?
11:34:38*kapil____ joined #nim
11:37:23leorizePerkol: `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:25FromGitter<mratsim> for set or tables
13:25:41FromGitter<mratsim> is contain defined on array? I would be surprised since it’s not O(1)
13:30:24Araqit is
13:31:14Araqdefined. not O(1) but that's not important, you can profile your code
13:33:14FromGitter<alehander42> can't wait for a algo complexity aspect of a type system :D
13:33:56FromGitter<arnetheduck> ooh! if you could annotate your functions with their complexity and have the language do an automatic analysis...
13:37:46FromGitter<alehander42> oh yeah, I wondered about that before
13:37:54FromGitter<alehander42> I found some cost-based type system papers
13:38:06FromGitter<alehander42> which deal with similar stuff, but I don't think there was mainstream lang doing it
13:38:58FromGitter<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:36FromGitter<alehander42> ah yeah the inria guys
13:41:37FromGitter<alehander42> http://gallium.inria.fr/~fpottier/slides/fpottier-2011-01-jfla.pdf
13:47:48FromGitter<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:49Yardanico6k stars, yay! :)
13:57:20Araqyglukhov: found a way to make os.nim work with NimScript and NimScript is easier to use when there are fewer special rules
13:57:53Araqalso ospaths grew some stuff that it not just string handling with paths so the distinction became arbitrary
13:59:39FromGitter<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:17FromGitter<yglukhov> e.g. seing `import os` in a module tells me this module depends on the environment somehow. basically "has side effects" =)
14:02:35Araqwell 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:08Araqthings were better before we had ospaths IMO.
14:03:38Araqalso there are things like isHidden() which is an OS call on Windows but string handling on Unix
14:04:29FromGitter<alehander42> maybe we can have ospaths for e.g. JavaScript which just export the things which are really compatible with everything
14:05:54FromGitter<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:26FromGitter<yglukhov> but maybe its just me...
14:08:49Araqyglukhov: if we split it up further other things come to mind
14:09:38Araqfor example, ospaths, osstat, osdirs, oswalk
14:10:51FromGitter<yglukhov> well. ospaths are just paths (strings) to me. osstat, osdirs, oswalk is fs interaction. os is environment, currentdir, etc...
14:11:50FromGitter<yglukhov> maybe it should be std/paths, std/os, and std/fs? =)
14:12:11Araqthe 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:53FromGitter<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:49Araqwell not at all, but if we change it there are good arguments for splitting up further
14:46:00FromGitter<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:13FromGitter<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:53Araqno, I like a big os.nim because that's what every Nim program out there is used to
14:52:55Araqbut there would be good arguments for a splitted os.nim
14:53:19Araqand 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:51FromGitter<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:47shashlickhave 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:20krux02shashlick, yea let timothee do it
15:27:49krux02even c++ doesn't have wrapper free interop with c++ you nee do write headers
15:28:43shashlickthat's fine - my thought is to make the wrapper invisible to consumer
15:29:10krux02I don't that it even is a good idea
15:29:36krux02because the wrapper is always a possible source of problems, and then you wand anything but an invisible wrapper
15:30:00krux02you want to be able to see the wrapper and be able to agree or disagree on how it works
15:30:39shashlickwell how it works would need to be documented
15:31:01shashlickC/C++ data types mapping to Nim
15:31:10krux02yea and documentation is the strength on Nim programs
15:32:12shashlickthe C/C++ headers already exist for the lib that needs to be consumed so how it works is already evident
15:32:55shashlickno need for an intermediate representation in nim
15:33:36*mosORadi joined #nim
15:34:53*alehander42 joined #nim
15:35:17alehander42hm mode_t is nice
15:37:08*alehander42 quit (Remote host closed the connection)
15:37:40*alehander42 joined #nim
15:40:02krux02shashlick, a good wrapper doesn't need the original header anymore, it replaces it.
15:40:49shashlickwell if you are planning on using a C/C++ lib for some reason, you need to know how to use it
15:40:55shashlickit will be documented by that author
15:41:30shashlickso putting a Nim spin on it means additional documentation burden for the wrapper author or maintainer
15:41:41shashlickas well as for the consumer who needs to understand the interop
15:42:25shashlicki guess there's no escape but one can aspire to make life easier for others eh
15:44:32krux02if you want wrapper free interop, use {.emit:"...".}
15:44:37krux02it 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:09shashlickcan 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:01shashlicknot really extensive looks like
16:07:22*dom96_w joined #nim
16:08:45*miran joined #nim
16:09:03benjikunAraq: How does nim compare to felix? https://github.com/felix-lang/felix
16:10:24benjikunIs 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:12FromGitter<yglukhov> shashlick: you can. use backticks.
16:29:01*dom96_w joined #nim
16:30:39FromGitter<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:04miranbenjikun: i'm looking at the felix tutorial and the first thing that i've seen is so many unneeded semicolons :)
16:32:30krux02arnetheduck: actually yes
16:32:47alehander42the new sizeof is neat
16:33:01krux02alehander42, thanks
16:33:09shashlickyglukhov: 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:10krux02was a lot of headache
16:33:23FromGitter<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:34FromGitter<arnetheduck> ie where in the compiler code
16:33:52krux02specifically 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:05krux02somewhere in the compiler there is branching that detects the platform and initializes the alignment value for float64 int64
16:35:16FromGitter<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:49krux02when 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:26krux02the 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:20krux02so 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:17miranbenjikun: but other than that, it looks like fun
16:39:36FromGitter<arnetheduck> not sure about "obscure", but if you mean tests/misc/tsizeof, it fails on rpi3 :)
16:39:53FromGitter<arnetheduck> ``````
16:40:41krux02I have a raspberry pi 3 so I could run the test on it
16:40:56krux02but I need a new SD card for it I like my emulationstation
16:41:08FromGitter<arnetheduck> that's running a 32-bit arm os (rasbian)
16:41:12alehander42arnetheduck, please don't edit your gitter msg
16:41:35*copygirl joined #nim
16:41:51alehander42it 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:05FromGitter<arnetheduck> right
16:43:37FromGitter<arnetheduck> actually, @krux02, that's a plain 0.19 version (not devel).. is that fresh enough?
16:44:14krux02I think so
16:44:22krux02there is the logic
16:44:51krux02implement the logic for rpi and it should work
16:44:59*wildlander joined #nim
16:46:13krux02@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:37krux02pull requests are very welcome here
16:49:16FromGitter<yglukhov> lack of unaligned access support doesn't prevent you from using packed (and thus unaligned) structs though
16:49:56FromGitter<arnetheduck> I'd assume where that is a problem, the c compiler generally does byte-by-byte copies to a register first
16:50:04FromGitter<yglukhov> yep
16:51:21FromGitter<arnetheduck> that doesn't help when you want to rely on sizeof/offsetof etc..
16:52:05krux02as I told you the tests are extensive and packed is fully supported
16:52:25krux02so when you are worried, just use packed and do manual alignment with padding byte arrays
16:52:56krux02or fix the logic for your platform
16:53:48benjikunmiran: Yeah, I think it looks pretty cool
16:55:39FromGitter<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:38FromGitter<krux02> we support it, we don't claim it is totally bug free
17:07:17*dom96_w joined #nim
17:10:21FromGitter<arnetheduck> wouldn't "support" imply though that at least the test suite passes?
17:11:28FromGitter<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:23FromGitter<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:23leorizean object contains some padding and a structure that holds the type info AFAIK
17:41:37leorizetry adding the `{.pure.}` pragma after `A*`
17:41:53miranleorize: object containing one int16 has size 2
17:42:49*mosORadi quit (Quit: Connection closed for inactivity)
17:43:38leorizeI stand corrected
17:43:49leorizeon 0.18.0 it does output the desired result
17:43:52FromGitter<brentp> I think this worked fairly recently.
17:44:35leorizeprobably a regression, you should file an issue
17:46:19mirancan confirm, on 0.19.0 outputs 4, on devel is 12
17:48:35FromGitter<brentp> done: https://github.com/nim-lang/Nim/issues/9668
17:50:43FromGitter<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:31FromGitter<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:12FromGitter<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:58narimiran@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:26FromGitter<kdheepak> I see a `raisePythonError` here: https://github.com/yglukhov/nimpy/blob/3ee68d0/nimpy/py_utils.nim#L127
18:40:39FromGitter<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:05FromGitter<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:48FromGitter<kdheepak> I see.
18:44:03FromGitter<kdheepak> I think it shouldn't be too hard to do it the other way around.
18:44:46FromGitter<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:59FromGitter<kdheepak> That's correct.
18:46:12*awal quit (Quit: ZNC 1.6.4 - http://znc.in)
18:52:38FromGitter<kdheepak> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5be5d7767326df140ede28a9]
18:54:56*smt joined #nim
18:55:20FromGitter<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:27FromGitter<xmonader> Good evening everyone!
19:39:10*Perkol quit (Quit: Leaving)
19:42:53*dddddd joined #nim
19:43:12PMunch"It's only 600 lines"...
19:46:08PMunchBut 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:51PerkolIn threadpool module how spawn is different from spawnX?
20:13:14PerkolWhat does cpu core is ready mean?
20:21:50PMunchHmm, Araq I can't get the nimsuggest library to work
20:22:08PMunchI echoed out the conf.repr for each of them. And are pretty much the same
20:22:14PMunchBut mine doesn't return anything..
20:25:11*Pisuke joined #nim
20:26:32*MyMind quit (Ping timeout: 244 seconds)
20:28:15PMunchOh never mind, got it working now
20:28:27PMunchI had forgot to turn on suggestionMode for the graph..
20:32:11Perkolspawn automatically limits number of running threads?
20:32:48PerkolNot more than MaxThreadPoolSize
20:36:01PMunchYeah, spawn will not run more threads than MaxThreadPoolSize
20:36:41*Vladar quit (Remote host closed the connection)
20:38:21PMunchspawnX essentially checks if there is a thread running on a CPU core that isn't currently doing anything
20:39:53PerkolWhat MaxDistinguishedThread does do?
20:41:18PMunchNot sure actually
20:41:21PMunchIt doesn't appear to do anything
20:49:57*FromDiscord_ <yspr> awoos
20:50:35PerkolAlso, spawn runs into problems when it comes to disc io
20:50:35FromGitter<tim-st> PMunch: do you think the package name suggestion could work with nimlsp ?
20:50:47PerkolAny advice on that?
20:50:47PMunchpackage name suggestion?
20:51:10PMunchPerkol, what does disk IO have to do with spawn?
20:51:10FromGitter<tim-st> when typed `import a..` it shows all packages with prefix a
20:51:18FromGitter<tim-st> https://gist.github.com/tim-st/df0ce1c4b712abe7d4e2a90f0b8c78a2
20:51:33*Perkol quit (Remote host closed the connection)
20:51:57PMunchHmm, yeah I guess it could
20:52:54FromGitter<tim-st> would be very nice, I think the code should work directly on all os'es but only tested on windows
20:53:21PMunchCould you create an issue on the nimlsp repo?
20:53:27FromGitter<tim-st> sure
20:53:29PMunchJust so that I don't forget :)
20:55:33FromGitter<tim-st> btw when you change the temp foler string to "nimlsp" it runs on windows too
20:55:41FromGitter<tim-st> folder
20:55:47PMunchHmm, 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:11PMunchOh cool
20:56:37FromGitter<tim-st> Though the compilation only works when I think jsonschema debugging is turned off
20:57:23PMunchHmm, it's slow if I compile it in the Nim folder as well
20:57:44PMunchI guess "koch tools" applies something else than "nimble build" does..
20:59:12PMunchOh 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:07PMunchHmm, it tells me that everything is an "Error type" for some reason..
21:24:37PMunchIt also complains about "Error: cannot open '/home/peter/Projects/nimlsp/lib/lib/system.nim'"
21:24:50PMunchIt 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:30PMunchOkay, setting that explicitly helps..
21:49:47PMunchBut 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:51PMunchHmm, if I copy the compiled binary into the nimsuggest folder it works
22:20:18PMunchSo it seems like it just isn't able to find the config/nim.cfg file when launched from another directory
22:34:43PMunchThere is nimsuggest functionality ripped out and put in a library
22:35:37PMunchI'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:30FromGitter<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)