<< 23-06-2018 >>
00:14:16FromGitter<Varriount> @kaushalmodi That will probably require a macro, not a template. Even then, documentation comments can only appear at certain points in the AST
00:15:25shashlickvarriount: will appreciate a review of nimdeps when you get a chance
00:28:56FromGitter<kaushalmodi> @Varriount Thanks. Isn't the doc comment for return _t at the right place?
00:34:19*dddddd quit (Remote host closed the connection)
01:05:29*zahary quit (Quit: Leaving.)
01:13:39*erratic joined #nim
01:19:25*endragor joined #nim
01:21:45*cspar quit (Ping timeout: 260 seconds)
01:24:05*endragor quit (Ping timeout: 260 seconds)
01:34:37*ipjk quit (Quit: Leaving)
02:09:30*sledat joined #nim
02:09:39sledathi guys!
02:09:51sledatis nim's distinct T types similar to rust's new existential types?
02:14:27PMunchUhm, don't think so
02:15:05PMunchdistinct types in Nim are basically a way to create a type alias that isn't compatible with any of the root types methods
02:15:44sledatwhat about distinct concepts
02:15:56PMunchDistinct concepts=
02:16:02PMunchs/=/?
02:16:21sledatlike when a proc argument is distinct Enumerable instead of just Enumerable
02:16:43PMunchNot quite sure what you mean
02:17:05PMunchConcepts is a thing in Nim, but I'm guessing that's not what you're talking about
02:18:20*sledat quit (Quit: Page closed)
02:18:55PMunchI don't really know what existential types are in Rust, do you have a good resource for them? Then I might be able to point you to something in Nim that matches the use-case
02:19:05PMunchOh, he quit
02:19:09PMunchOh well
02:24:16*PMunch quit (Quit: leaving)
02:25:38FromGitter<rayman22201> I was super curious so I looked it up: https://www.infoq.com/news/2018/05/rust-1.26-existential-types
02:26:02FromGitter<rayman22201> sounds a lot like Nim concepts?
02:31:42*NimBot joined #nim
03:45:39*Bevo joined #nim
03:55:27*yglukhov[i] joined #nim
03:59:50*yglukhov[i] quit (Ping timeout: 260 seconds)
05:07:53*Vladar joined #nim
05:27:02*lompik joined #nim
05:28:01*thomasross joined #nim
05:28:57*endragor joined #nim
05:56:56*yglukhov[i] joined #nim
06:01:17*xet7 joined #nim
06:01:39*yglukhov[i] quit (Ping timeout: 256 seconds)
06:09:04*xkapastel quit (Quit: Connection closed for inactivity)
06:51:29*nsf joined #nim
07:17:10*lompik quit (Ping timeout: 264 seconds)
07:23:34*yglukhov[i] joined #nim
07:29:24*Trustable joined #nim
07:38:28*Vladar quit (Quit: Leaving)
07:42:13*Vladar joined #nim
07:43:41*Trustable quit (Remote host closed the connection)
08:12:42*rockcavera joined #nim
08:12:50*endragor quit (Remote host closed the connection)
08:26:20*NimBot joined #nim
08:34:06*yglukhov[i] quit (Remote host closed the connection)
08:42:16*yglukhov[i] joined #nim
08:46:38*yglukhov[i] quit (Ping timeout: 255 seconds)
08:53:25*yglukhov[i] joined #nim
08:56:45*nsf quit (Quit: WeeChat 2.1)
09:02:26*rauss quit (Read error: Connection reset by peer)
09:03:25*rauss joined #nim
09:12:00dom96The talk I did recently is finally on YouTube https://www.youtube.com/watch?v=hzxr9_ZK9uY
09:12:06dom96Probably the best talk I ever gave :)
09:12:11*yglukhov[i] quit (Remote host closed the connection)
09:14:15dom96Upboats on r/programming appreciated :)
09:15:04*zahary joined #nim
09:23:17*yglukhov[i] joined #nim
09:36:20Yardanicodom96, we need to get like ~5-10 upvotes, then other people will see it on the top page
09:37:45*dddddd joined #nim
09:39:59*zahary quit (Quit: Leaving.)
09:41:29*zahary joined #nim
09:44:00dom96It'll get there
09:44:03dom96It's already on the front page
10:00:18Zevv+1
10:09:02*yglukhov[i] quit (Remote host closed the connection)
10:14:19*zahary quit (Quit: Leaving.)
10:19:11federico3Snake should be an easter egg in the forum
10:26:48dom96Good idea, Konami code :)
10:36:08*elrood joined #nim
10:37:21Bevowhere's the upvote button? :)
10:44:18FromGitter<bevo009> nevermind found it
10:57:02*dorelix joined #nim
11:08:41FromGitter<tim-st> If I understood correctly nim strings become not nil (`""`) by default in future; but can I still make them nil?
11:10:03FromGitter<tim-st> or is there some post about this?
11:16:13FromGitter<mratsim> it’s already committed in devel
11:16:24FromGitter<mratsim> if you want nil string you can use cstring
11:17:02FromGitter<mratsim> for C interop those are nullables
11:17:23FromGitter<tim-st> Thanks, does this mean, `var s: string = nil` doesnt work anymore only `var cs: cstring = nil`?
11:17:31FromGitter<mratsim> yes
11:17:43FromGitter<tim-st> I think, this will break many libs
11:18:28FromGitter<mratsim> it did for about 1 week, it also broke the compiler error messages
11:18:32*lompik joined #nim
11:18:54FromGitter<tim-st> e.g. when I want to implement `db.get(key: string): string` how can I signalize that the key was available without raisning exception
11:19:01FromGitter<mratsim> but I would be surprised if libraries with no C interop whre relying on nil string
11:19:17FromGitter<mratsim> db.hasKey?
11:20:23FromGitter<tim-st> yes, but now I always need `if db.hasKey: key = db.get(key)`
11:20:41FromGitter<mratsim> relying on nil pointer to avoid exceptions is a bad idea
11:21:17FromGitter<tim-st> I hope nim's code will look like golang error management one day
11:21:25FromGitter<tim-st> *wont
11:22:12livcddom96: upvoted! good talk
11:22:25dom96livcd: thanks!
11:22:29FromGitter<tim-st> @mratsim Ok, thanks for the information about this nil string thing, that's very important
11:22:55FromGitter<mratsim> some could return, -1, some could throw
11:23:37FromGitter<tim-st> what are the best pros of this change with not nil?
11:24:14*leru joined #nim
11:25:32FromGitter<mratsim> no null pointer exceptions
11:25:48FromGitter<tim-st> on the dev site or one the compiler/gc site?
11:26:00FromGitter<mratsim> dev mostly
11:26:11FromGitter<tim-st> Ok, thanks, I never had this though
11:26:26*cspar joined #nim
11:26:28FromGitter<mratsim> if the result value is a string you don’t have to use result = newString(10) or result = “"
11:26:41FromGitter<mratsim> or result = @\[\]
11:26:47FromGitter<mratsim> and then do your thing
11:27:26FromGitter<mratsim> i.e. string and seq works more consistently as value types and don’t leak implementation details (pointer)
11:27:45FromGitter<mratsim> you can always add the {.noInit.} pragma
11:27:55FromGitter<tim-st> ok, thanks, good information
11:28:06FromGitter<mratsim> ideally it should be done automatically but well.
11:31:50*clyybber joined #nim
11:52:32*salewski joined #nim
11:53:04salewskiDo we have Roaring Bitmaps?
11:53:52salewskiJust saw https://lemire.me/blog/ , newer heard the term before, seems interesting.
11:56:00salewskihttps://github.com/RoaringBitmap/CRoaring
11:58:10*salewski quit (Quit: WeeChat 2.0.1)
11:59:07*mostly-harmless quit (Quit: leaving)
12:08:25*nsf joined #nim
12:08:31*clyybber quit (Ping timeout: 268 seconds)
12:08:51*clyybber joined #nim
12:09:03*clyybber quit (Client Quit)
12:09:38*yglukhov[i] joined #nim
12:10:03*clyybber joined #nim
12:10:35*clyybber quit (Client Quit)
12:10:47dom96https://github.com/nim-lang/nimforum/issues/161 :/
12:10:50*clyybber joined #nim
12:11:02*clyybber quit (Client Quit)
12:12:31*clyybber joined #nim
12:12:50*clyybber quit (Client Quit)
12:13:02*clyybber joined #nim
12:13:51*clyybber quit (Client Quit)
12:14:04*zahary joined #nim
12:14:05*yglukhov[i] quit (Ping timeout: 255 seconds)
12:14:07*vegax87 quit (Changing host)
12:14:07*vegax87 joined #nim
12:14:07*vegax87 quit (Changing host)
12:14:07*vegax87 joined #nim
12:14:10*clyybber joined #nim
12:14:11*clyybber quit (Client Quit)
12:18:22*clyybber joined #nim
12:18:22*clyybber quit (Client Quit)
12:18:49*clyybber joined #nim
12:18:49*clyybber quit (Client Quit)
12:19:59*clyybber joined #nim
12:19:59*clyybber quit (Client Quit)
12:22:01*clyybber joined #nim
12:22:52FromGitter<Varriount> salewski: But what is the performance like compared to regular bitmaps?
12:27:16*salewski joined #nim
12:28:21salewskiPerformance seems to be great, saw that late yesterday night. Will give you the link soon...
12:30:06salewskiOne is here at the bottom: https://github.com/Ezibenroc/PyRoaringBitMap
12:32:10salewskiAnd I think the other one I saw was on the Lemire blog itself, was for JavaScript:
12:32:22salewskihttps://lemire.me/blog/
12:33:06salewskiWell as I sad, I never heard of that term, and I do not need it currently :-)
12:33:39*NimBot joined #nim
12:37:33*leru quit (Quit: Leaving)
12:38:07federico3dom96: regarding https://github.com/dom96/jester/issues/68 chunking is part of HTTP 1.1 and can be useful
12:39:20dom96Yeah, I want streaming support for Jester
12:39:31dom96But first we need better future streams in the stdlib
12:41:04federico3the method in #68 is not ok?
12:42:19FromGitter<kdheepak> @dom96 Nice talk at BelFoss2018! ( Link here (https://www.youtube.com/watch?v=hzxr9_ZK9uY) for those interested )
12:42:55dom96federico3: it's a bit rough
12:43:11dom96@kdheepak thanks!
12:43:52federico3uhm my browser seems to be waiting for the end...
12:44:18dom96lol yeah
12:45:23FromGitter<kdheepak> This may be a silly question, but is it possible in theory to target Rust as a backend as an alternative to C/CPP? Presumably currently there is no support. Do you have thoughts on if you think that's a direction nim will take?
12:45:46dom96Sure it's possible, but what would be the benefit?
12:47:13federico3odd, I can see jester sending out traffic...
12:47:50dom96federico3: Chunked encoding isn't streaming, the browser will wait until all the chunks have been received before displaying the page AFAIK
12:48:11dom96it probably depends on the content type
12:48:17federico3dom96: try http://stream.meetup.com/2/rsvps
12:49:11dom96interesting
12:49:32federico3aha
12:49:46federico3"Content-Type": "application/json", instead of text/plain
12:50:01dom96ahh, so I was right :)
12:50:31*clyybber quit (Quit: good night)
12:50:36salewskikdheepak, we had that discussion https://forum.nim-lang.org/t/2688
12:52:17dom96federico3: I wonder how well our stdlib httpclient handles this
12:52:23dom96Wouldn't be surprised if it fails
12:55:06federico3https://github.com/nim-lang/Nim/blob/master/lib/pure/httpclient.nim#L276
13:00:43FromGitter<tim-st> @kdheepak It would be quite difficult to support a rust backend. The problem is that rust has things like lifetime parameters, three different string types and more things are different. If it would be easy for a compiler to determine the correct lifetime parameters, the rust compiler could do it by itself and wouldnt annoy the dev by such complex things, so how should nim's compiler find out the correct lifetime
13:00:43FromGitter... parameters if even rust's cant do it without the help of the dev?
13:00:50FromGitter<kdheepak> Thanks for the discussion thread! That was an interesting read. I'd know enough about any implementation details to comment on the technical / objective benefit. I have some colleagues who are now "pro rust" and would like to "rust all the things", because they've admittedly been burnt by C. Having a Nim to Rust backend would give me strong ammunition when advocating for Nim.
13:01:14*leorize joined #nim
13:02:16*leorize quit (Client Quit)
13:02:42FromGitter<kdheepak> *definitely do not know
13:03:54FromGitter<tim-st> But I'm only a beginner in rust, if the rust lifetime parameter "live forever" (the worst one) would be enough, I think it would be possible if all nim system procs are mapped, but of course the performance wouldnt be as good then
13:08:57FromGitter<tim-st> maybe if all types are copied and no refs are made, then it works, but you can image that has massive performance impacts
13:10:49*yglukhov[i] joined #nim
13:15:21*yglukhov[i] quit (Ping timeout: 240 seconds)
13:19:17FromGitter<kaushalmodi> Thanks @GULPF for fixing the time zone issue in https://github.com/nim-lang/Nim/pull/8091/files.
13:19:39FromGitter<kaushalmodi> Looking at the diff, may be Nim should fail compilation for trailing spaces too :P
13:19:59FromGitter<kaushalmodi> It always irks to see such code with stray spaces.
13:22:20federico3dom96: however httpclient seems to try to receive the whole answer while stuff like meetup.com is meant to have each chunk decoded and processed on the fly
13:25:00dom96federico3: httpclient exposes a `body` which is a FutureStream
13:25:17dom96So you can read it progressively
13:25:18dom96bbl
13:50:30*xet7 quit (Quit: Leaving)
13:51:29*xet7 joined #nim
13:59:00*gb00s joined #nim
14:02:09*xkapastel joined #nim
14:20:42*gangstacat quit (Quit: Ĝis!)
14:26:55*salewski quit (Quit: WeeChat 2.0.1)
14:28:52FromGitter<kaushalmodi> I believe this comment about providing platform specific binary is the key: https://www.reddit.com/r/programming/comments/8t8slk/belfoss_2018_nim_language_intro_by_dominik_picheta/e15uusb/. I think that, getting Go-like just download the binary and put in your PATH, approach will bring a much more Nim adoption boost than releasing a 1.0.
14:29:34FromGitter<kaushalmodi> As it is, I see that Nim is really awesome. The problem is getting it to more masses.
14:30:40FromGitter<kaushalmodi> I, for example, don't care about the advanced features that are still is pipeline. I believe that would be the same for prospective Python transistioners too.
14:34:31FromGitter<kaushalmodi> That "don't care" statement came out as too callous. The fact is that influx of new users will be somewhat proportional to new folks contributing to the Nim source.
14:43:48*gangstacat joined #nim
14:44:27FromGitter<codenoid> morning bob
14:49:35*yglukhov[i] joined #nim
14:49:43FromGitter<codenoid> @bob
15:05:12*skrylar joined #nim
15:13:00FromGitter<tim-st> @kaushalmodi Yes, I also said here before that the number one issue of nim for windows is not having a setup like golang, that just installs nim and gcc to path, also if it's possible to build such an installer maybe, people wont do this
15:13:32FromGitter<tim-st> (I mean the people who are interested to try nim)
15:19:30FromGitter<tim-st> Also when this installer exists, it should be easier to people to find out about ide's with plugins that support nim, I found out about nim in vscode after using nim for more then two months
15:36:04shashlicktim-st: choosenim is close, I have a PR open that installs the Windows binary
15:36:17shashlickonce that gets accepted, i'll look into linux binaries
15:43:23FromGitter<tim-st> ok, interesting, but not sure if new people understand how to use it. at golang they just type "download go" then they see "setup.exe" and everything is done
15:49:31*nsf quit (Quit: WeeChat 2.1)
15:50:00shashlickwell, the installer effort is long winded since there's multiple approaches - clone/build, ZIP+finish and choosenim
15:50:33shashlickmy aim is to consolidate under one umbrella but given I don't own any of the repos, the going is slow
15:50:42shashlicki don't want to make yet another random tool
15:50:56FromGitter<tim-st> yes, I understand
15:51:27shashlickand I don't know a good way to continue working on a tool if a PR branch isn't pulled in yet
15:51:47FromGitter<tim-st> why isn't pulled?
15:52:33FromGitter<tim-st> maybe it's better to save the last known good gcc version urls on a github page instead of a direct url to nim page, that can be changed easier
15:52:50shashlickdom96 will get to it when he has the time
15:52:57FromGitter<tim-st> ok
15:53:05shashlickit's hard to context switch from repo to repo
15:58:05shashlicktim-st: which direct URL are you talking about?
15:59:54FromGitter<tim-st> `mingwUrl = "http://nim-lang.org/download/mingw32.tar.gz"` also it uses HTTP which is not good
16:00:02federico3yep
16:02:13FromGitter<tim-st> Also choosenim should determine mingw32 or mingw64 based on arch instead of choosing mingw32
16:03:09shashlicktim-st: that's there in the PR
16:03:25shashlickhttps://github.com/dom96/choosenim/pull/63
16:03:59shashlickanother thing I'm planning is to use nimarchive, that way we can extract 7z files and install mingw32 or 64
16:04:15shashlickbut like I said, till that PR is accepted, I cannot build on it
16:04:28shashlicka PR that depends on another PR without reusing the same branch
16:04:37FromGitter<tim-st> I didnt saw it there, I thought the `const mingwUrl` always links to mingw32
16:05:55FromGitter<tim-st> my idea was put on github the file `mingw_latest.json` and put in x64 and x86 urls that are newest working versions with nim
16:06:58shashlickwe can use symlinks on the http://nim-lang.org server to point to latest supported
16:07:22shashlickya, i don't have code yet to pick correct gz for mingw yet since only one gz is posted online
16:07:23FromGitter<tim-st> yes, that would be possible, but github is more stable and safe to always use ssl
16:07:44shashlickboth 32 and 64-bit 7z files are posted and used by finish.exe but problem is that choosenim doesn't support 7z yet
16:07:55shashlickwhich is why i wrapped libarchive
16:08:19shashlickyes SSL is correct
16:08:26FromGitter<tim-st> ok, I think it's also ok to replace the files on nimlang by high compressed zip or tar.gz
16:08:38federico3even better - signing the files being used
16:08:49FromGitter<tim-st> and update version, gcc 8.1.0 works good with nim
16:08:55FromGitter<tim-st> on windows
16:09:06shashlick7z files are already posted, and we can update to latest I agree
16:09:11shashlickthat we need to coax Araq 🙂
16:09:52FromGitter<tim-st> also it's maybe good to host these files also on github, the costs on nim-lang server maybe will be lower
16:10:30FromGitter<deech> Why are enums and constants not exportable to C? https://nim-lang.org/docs/manual.html#foreign-function-interface-exportc-pragma
16:11:37*xkapastel quit (Quit: Connection closed for inactivity)
16:13:32shashlicktim-st: they are already hosted on http://sf.net
16:13:44shashlickhttps://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/
16:14:01*lompik quit (Ping timeout: 256 seconds)
16:16:26FromGitter<tim-st> yes, I know, from what I remember sf gives their best against hotlinking
16:17:18*jjido joined #nim
16:17:47FromGitter<tim-st> well it works: https://datapacket.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-posix/seh/x86_64-8.1.0-release-posix-seh-rt_v6-rev0.7z
16:35:41*yglukhov[i] quit (Remote host closed the connection)
16:36:15*yglukhov[i] joined #nim
16:40:39*yglukhov[i] quit (Ping timeout: 256 seconds)
16:52:41*themagician joined #nim
16:57:57*Jesin quit (Quit: Leaving)
16:58:30*thomasross quit (Read error: Connection reset by peer)
17:01:14*dddddd quit (Remote host closed the connection)
17:08:50*yglukhov[i] joined #nim
17:13:10*yglukhov[i] quit (Ping timeout: 245 seconds)
17:13:15FromGitter<ephja> some wrapped C function is sometimes causing a crash past the end of the main code. how fun. also when the GC is disabled. I tried that just to make sure
17:22:47FromGitter<rayman22201> @deech that's an @Araq question, but enums and Const in Nim have extra type safety Metadata attached. They work very differently than C enums which are really just integers.
17:28:48FromGitter<rayman22201> @dom96 I'm in the wrong timezone, but congrats on the talk! How many people attended the talk, if you don't mind me asking?
17:32:02*lompik joined #nim
17:37:33*lompik quit (Ping timeout: 264 seconds)
17:39:08FromGitter<ephja> 5000 I was told, but I'm beginning to suspect that my sources aren't reliable
17:42:03FromGitter<Lite5h4dow> is anyone working on a xamarin header for nim?
17:42:13FromGitter<Lite5h4dow> i know its not that likely
17:42:19*yglukhov[i] joined #nim
17:45:27shashlickWhich portion of it?
17:47:01*yglukhov[i] quit (Ping timeout: 260 seconds)
17:51:49FromGitter<Lite5h4dow> the UI
17:52:07*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:52:08FromGitter<Lite5h4dow> since nim is a mess when it comes to UI
17:52:22FromGitter<Lite5h4dow> nimx now doesnt work (for whatever reason o.o)
17:52:40FromGitter<Lite5h4dow> nim ui is so simple its almost impossible to make apretty ui out of it
17:53:11FromGitter<Lite5h4dow> iup wrapper looks ok but messy. no real documentation appart from the original iuo
17:53:38FromGitter<Lite5h4dow> and nuklear nim. so pretty. but wtf is its code
17:53:45FromGitter<Lite5h4dow> i dont get whats going on
17:54:11FromGitter<Lite5h4dow> xamarin looks like a good balance of all of it
17:54:22*zahary quit (Quit: Leaving.)
17:54:23FromGitter<Lite5h4dow> seing as A. its microsoft and B its somewhat userfriendly
17:54:59FromGitter<Lite5h4dow> and bonus its cross platform
17:55:12FromGitter<Lite5h4dow> linux windows and android all in one package
17:55:24FromGitter<Lite5h4dow> (lets be real no one cares about mac os at this point)
17:58:00FromGitter<kayabaNerve> We have a number of Mac OS devs in this community, IIRC
17:58:23FromGitter<kayabaNerve> And they deprecated OpenGL, as idiots, but they are very popular for ultrabooks
17:58:33FromGitter<kayabaNerve> Lightweight and all that
17:58:58FromGitter<kayabaNerve> I even have friends that use Darwin. Not Mac OS, just commenting...
18:01:36*brainproxy quit (Ping timeout: 260 seconds)
18:03:50*cspar quit (Ping timeout: 276 seconds)
18:08:03FromGitter<Lite5h4dow> i was just messing
18:08:10FromGitter<Lite5h4dow> mac os has its up for simple uses
18:08:18FromGitter<Lite5h4dow> but i find it frustrating to do anything on
18:08:43FromGitter<Lite5h4dow> i have windows only for games dev at uni
18:08:52FromGitter<Lite5h4dow> if it wasnt for that i would be on linux for everything
18:10:28FromGitter<Lite5h4dow> apart form that, what do you guys use for UI's in nim (if you make UI's at all?)
18:11:25shashlickCan you point me to the specific GitHub repo?
18:11:46FromGitter<Lite5h4dow> what for?
18:12:01shashlickI can look into wrapping it
18:12:06FromGitter<Lite5h4dow> oh sure
18:12:51shashlickNot that I have a shortage of projects but if it's doable and you are willing to help test out what we come up with
18:12:52FromGitter<Lite5h4dow> https://github.com/xamarin/Xamarin.Forms
18:13:04FromGitter<Lite5h4dow> absoloutly
18:13:42FromGitter<Lite5h4dow> it uses .net or c# depending on the platform
18:13:52FromGitter<Lite5h4dow> idk though
18:14:07shashlickWell then that's beyond my capabilities
18:14:24FromGitter<Lite5h4dow> ah ok
18:14:32FromGitter<Lite5h4dow> thanks for showing interest though
18:14:34shashlickCause I use c2nim and that only supports c and c++
18:14:47FromGitter<Lite5h4dow> ah ok
18:14:47shashlickWondering if others have wrapped c# dlls
18:15:16FromGitter<Lite5h4dow> https://gist.github.com/zah/fe8f5956684abee6bec9
18:15:18shashlickWondering if this has c interop headers
18:15:51FromGitter<Lite5h4dow> i think that might be the other way round tho
18:16:04FromGitter<Lite5h4dow> importing nim from c#
18:16:18FromGitter<Lite5h4dow> if its done one way it should be possible to do it the other
18:16:31shashlickThat's backwards
18:17:30FromGitter<Lite5h4dow> ah rip
18:18:41shashlickhttps://docs.microsoft.com/en-us/xamarin/tools/dotnet-embedding/get-started/c
18:19:29shashlickSeems feasible
18:19:35shashlickBaby steps
18:23:29FromGitter<Lite5h4dow> thinking of doing it via .net C?
18:26:53shashlickWell once you get the c headers, it's easy to wrap
18:27:06shashlickI'll try it once I get home
18:27:07FromGitter<Lite5h4dow> uh ok
18:27:13FromGitter<Lite5h4dow> thanks man
18:28:19FromGitter<Lite5h4dow> would be nice to have a functional UI system that isnt hyper manual
18:29:54*gangstacat quit (Ping timeout: 256 seconds)
18:31:36*brainproxy joined #nim
18:34:14*nsf joined #nim
18:34:20shashlickWell the main challenge with wrapping is that I don't use any of this stuff
18:34:35shashlickSo if you can provide feedback, it will be great
18:34:46FromGitter<Lite5h4dow> gladly
18:46:33FromGitter<juturnas> Is there a way to reference things `#define`'d in C via the ffi?
18:47:35*xkapastel joined #nim
18:48:44*yglukhov[i] joined #nim
18:59:46shashlickC2nim converts those to const
19:02:26FromGitter<juturnas> Ah gotcha, thanks
19:06:10shashlickThey don't really exist in the binary
19:08:04*Vladar quit (Quit: Leaving)
19:20:58*Trustable joined #nim
19:22:54FromGitter<tim-st> I try c2nim but it fails on this line `# define MDB_SCNy(t) SCN##t##64` what does `SCN##t##64` mean? gcc can compile it...
19:28:08shashlickYou might do better to use nimgen
19:28:34FromGitter<tim-st> thanks, will try it
19:28:36shashlickUse preprocess so that it gets rid of complicated #defines
19:28:52shashlickWhich lib you wrapping?
19:29:05FromGitter<tim-st> https://github.com/LMDB/lmdb/tree/mdb.master/libraries/liblmdb
19:29:30FromGitter<tim-st> there are already two nim impl. but they are missing some features like range iteration
19:29:46shashlickAnd use defines = true to retain some simple ones so that they are converted into const
19:30:13FromGitter<tim-st> can I just skip defines? wont that create wrong file?
19:30:19shashlickCheck out some other nimgen wrapped libs to get an idea of how to do it
19:30:25FromGitter<tim-st> ok
19:30:38shashlickYou might want some of them
19:30:46shashlickLike numeric values
19:31:37FromGitter<tim-st> nimble install nimgen fails
19:31:49FromGitter<tim-st> same head version
19:32:54FromGitter<tim-st> `lib\impure\nre.nim(13, 22) Error: undeclared identifier: 'toLower'`
19:33:28shashlickWhat version of Nim
19:33:51FromGitter<tim-st> 1) 18.0 win64
19:37:29shashlickWeird
19:37:39elrood## is a simple concatenation directive for the c preprocessor
19:37:48elroodif that's all you're after you can just replace all occurrences of MDB_SCNy(foo) with SCNfoo64 in your favourite text editor. or run your c source file through gcc -E
19:38:22FromGitter<tim-st> thanks, what does gcc -E do?
19:39:15shashlickThat's what nimgen does
19:39:23shashlickRun thru preprocessor
19:39:42shashlickProcesses all #defines, ifdef etc
19:40:23FromGitter<tim-st> I now have 4mb file^^
19:41:28shashlickYep but that includes code from all included files
19:41:49shashlickNimgen then filters out the code only from the file being processed
19:42:25FromGitter<tim-st> ok, c2nim still fails..
19:58:33shashlickOk I'll have to check it out in the evening
19:58:44shashlickDid you get nimgen working?
19:59:13*dddddd joined #nim
20:04:17*yglukhov[i] quit (Remote host closed the connection)
20:05:54*gangstacat joined #nim
20:06:52*nsf quit (Quit: WeeChat 2.1)
20:07:07FromGitter<tim-st> no I only tried via nimble and the error I posted above appeared
20:11:20shashlickCan you try a GitHub clone and nimble install?
20:13:23FromGitter<tim-st> it asked me if I want to try "head", isnt head the newest github version?
20:13:46shashlickYep
20:13:56shashlickWell latest checked in code
20:14:03*endragor joined #nim
20:14:05FromGitter<tim-st> I can try manually
20:14:15shashlickMay not be versioned with a tag
20:15:59FromGitter<tim-st> https://gist.github.com/tim-st/1061c97863878f597329bb2c90c84748
20:18:21FromGitter<tim-st> shashlick: It's not your bug, it's a nim bug
20:18:45*endragor quit (Ping timeout: 265 seconds)
20:19:10FromGitter<tim-st> in nre line 13: ```from strutils import toLower, `%```` has to become toLowerAscii
20:22:13FromGitter<tim-st> now it compiles after changing this file, so there is nothing you can do about it
20:23:39shashlickHow come it has worked all this time
20:24:09shashlickThat was changed many releases ago in Nim
20:26:07FromGitter<tim-st> that's not correct. see: https://nim-lang.org/download/nim-0.18.0_x64.zip
20:26:15FromGitter<tim-st> this wasnt fixed
20:26:46shashlickI see it was changed only two months ago
20:26:59FromGitter<tim-st> ok, but 0.18.0 is from march first
20:27:20shashlickProbably toLower was deprecated all this time and removed in 18
20:27:27FromGitter<tim-st> the question is: why is there no test case that compiles each import as main module before ship out?
20:28:09FromGitter<tim-st> (I mean nim, not your lib)
20:31:32shashlickI think nre has test cases
20:37:37dom96Where is that package that makes it easy to evaluate embed Nim?
20:37:44dom96s/evaluate embed/embed/
20:37:59dom96Anyone know?
20:41:27*yglukhov[i] joined #nim
20:43:02*elrood quit (Quit: Leaving)
20:43:45*Cthalupa quit (Ping timeout: 256 seconds)
20:46:49FromGitter<ephja> "-nThe system cannot find the file specified." makefiles...
21:05:06*Cthalupa joined #nim
21:11:11*aziz joined #nim
21:41:18dom96https://goo.gl/forms/t2gWWBEDC1walw6s2
21:41:47dom96About to post this out to nim-lang.org and other social channels
21:41:59dom96It's the new Nim community survey!
21:42:03dom96Let me know if you find any issues
21:58:40federico3dom96: \o/
21:59:29federico3dom96: How do you learn about the new functionality added to Nim? -> should be multiple choice
21:59:51dom96I don't think so
22:00:14dom96The idea is to learn how frequently people follow Nim's development
22:01:08*nsf joined #nim
22:10:35FromGitter<rayman22201> Maybe there should be an "I don't Know" option for the Should Nim 1.0 have been released already? question.
22:10:48dom96rayman22201: good call
22:10:52dom96I'll add it
22:11:08FromGitter<rayman22201> 👍
22:37:48*nsf quit (Quit: WeeChat 2.1)
22:38:00*Sentreen quit (Remote host closed the connection)
22:45:02shashlickSubmitted!
22:46:32*clyybber joined #nim
22:48:23dom96Thanks :)
23:00:47*cspar joined #nim
23:22:05*clyybber quit (Quit: good night)
23:26:04*aziz quit (Remote host closed the connection)
23:35:31*rockcavera quit (Remote host closed the connection)
23:38:22*yglukhov[i] quit (Remote host closed the connection)
23:43:35*Trustable quit (Remote host closed the connection)