00:01:24*Jjp137 joined #nim
00:25:50*leorize joined #nim
00:33:41FromGitter<dandevelo> More details here: https://forum.nim-lang.org/t/4581
00:46:38leorizeInstead of linking staticlib with Nim, you could just do the ordinary "import"
00:47:09leorizecurrently the lib generation options only generate libs for use outside of Nim
00:54:51FromGitter<dandevelo> @leorize what if I need to use multiple libs created with Nim in the same application outside of Nim?
00:55:11leorizethat's not possible atm, sadly
00:55:42leorizethe GC has to be shared, so we have to wait until someone manage to split the GC to a lib of it's own
00:57:04*Tyresc quit (Quit: WeeChat 2.4-dev)
01:04:39rayman22201use nimrtl
01:04:49rayman22201that is literally the GC split into it's own lib
01:05:01*zachk quit (Quit: Leaving)
01:05:27*abm quit (Ping timeout: 244 seconds)
01:05:38rayman22201or use one of the no GC options. --gc:none, --gc:regions, or --gc:destructors
01:06:52rayman22201idk what's up with the noMain issue. That seems like a bug, but I'm not sure.
01:07:02leorizeNimMain is used to initialize the Gc
01:07:08leorizeit'll always be there
01:07:39leorizenimrtl is bigger than just the GC however
01:07:49leorizeand it's a shared lib :/
01:09:29rayman22201it's a valid option, what ever your opinion of shared libs.
01:10:19leorizewell, the person asking want to use static libs
01:10:40leorizewith a bit of modification it might be possible to generate static nimrtl however
01:10:52rayman22201that's a good point. I missed that. :-/
01:12:20rayman22201this makes the no gc options seem more attractive.
01:13:30leorizewell NimMain also inits the module, should there be any initialization code
01:17:20*skellock joined #nim
01:25:05JnRI have a good question. I thought of the idea of a cross platform compiler being run strictly as a liveboot on my Raspberry Pi and acting like a cross-platform translator for running virtual machines and x64 programs on Arm7. I found out that Nim actually has a cross-platform function built into it. Has anyone tried anything like this?
01:26:15JnRObviously the Arm7 device would have to have a significant amount of memory but I think it can be done
01:32:22*darithorn quit (Quit: Leaving)
01:35:25rayman22201Nim just spits out C. So if you have a C compiler for a platform, you can cross compile to it. In theory anyway... Cross compiling is a bit of an art in practice.
01:37:33rayman22201Your bigger problem is not memory. Arm is notoriously bad at x86/x64 emulation (same going the other way as well. This is why android emulators typically have crap performance). It's very slow. Not because of memory, just because the assembly languages and architectures are so different.
01:41:18*ghost64 quit (Read error: Connection reset by peer)
01:42:13FromGitter<JasperJenkins> Is this a bug or is their some logic I'm not seeing? ```proc returnsInt(): int {.compileTime.} = ⏎ var x = 1 ⏎ ⏎ proc noReturn() {.compileTime.} = ⏎ var x = 2 ... [https://gitter.im/nim-lang/Nim?at=5c47c675cb47ec300088470f]
01:46:12*ghost64 joined #nim
01:47:04rayman22201better: https://pastebin.com/raw/RrKEhDDQ
01:47:14rayman22201You are trying to run a compileTime proc at runtime
01:49:40JnRrayman22201 Yeah that's pretty much the answer I was expecting. I only want to use the Arm device as a remote host but I guess you can't just float over top of the architecture
01:50:19rayman22201@JasperJenkins, does that make sense?
01:50:19*xace quit (Ping timeout: 246 seconds)
01:51:15rayman22201@JnR, yeah. Still neat idea though :-P
02:50:15*darithorn joined #nim
03:01:55*JnR quit (Remote host closed the connection)
03:02:06*banc quit (Quit: Bye)
03:10:57*skellock quit (Quit: WeeChat 2.3)
03:22:46*banc joined #nim
03:37:26*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:44:49*darithorn quit (Remote host closed the connection)
03:50:58*darithorn joined #nim
04:00:28*smitop quit (Quit: Connection closed for inactivity)
04:07:38*xace joined #nim
04:21:26FromGitter<kaushalmodi> I am trying to get `gzgets` from `zip/zlib` to work for a while, but am out of ideas: https://ptpb.pw/Tpe-/nim
04:24:33FromGitter<kaushalmodi> If I replace `gzgets` with a `gzgetc` loop, it works. I had a typo in the earlier link, but even after fixing it (see updated in https://ptpb.pw/DDTl/nim), I have the same issue
04:24:50FromGitter<kaushalmodi> the `line` read is always an empty string and the file pointer never increments
04:25:52*nsf joined #nim
04:30:18FromGitter<kaushalmodi> arghh, sorry folks, that version had another mistake .. was making mistake in creating this minimal version..
04:31:08FromGitter<kaushalmodi> so here are the tested version: the version with gzgetc works ( https://ptpb.pw/JheU/nim ), and this same code with gzgets does not ( https://ptpb.pw/s12O/nim )
04:36:18*oculux quit (Quit: blah)
04:37:11*oculux joined #nim
04:47:26FromGitter<kaushalmodi> got some interesting results after I tweaked the `gzgets` mapping with the header file
04:47:32FromGitter<kaushalmodi> https://ptpb.pw/WuFB/nim
04:48:03FromGitter<kaushalmodi> after that tweak, I get this output: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c47f203ba355012a4820a0d]
04:48:23FromGitter<kaushalmodi> can someone explain the reason behind this?
04:49:10FromGitter<kaushalmodi> zlib.h has ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c47f246dab15872ceda4e14]
04:51:27leorizeyou didn't initialize Pbytef
04:51:40*darithorn quit (Quit: Leaving)
04:51:54FromGitter<kaushalmodi> *what's that -- looking into zlib.nim*
04:51:55leorizecstring is nil by default lol
04:52:12leorizelook at your old example
04:52:26leorizethe pointer didn't increment because you passed a nil cstring in
04:53:06leorize```Pbytef = cstring```
04:53:24FromGitter<kaushalmodi> right, but I didn't understand the initialization part
04:54:05leorizeyour old example did: `var line: Pbytef`
04:54:12leorizethis is `nil` by default
04:54:38leorize`gzgets` work on an preallocated buffer, not an empty one
04:54:52FromGitter<kaushalmodi> how do I do that?
04:55:38FromGitter<kaushalmodi> I could preallocate that char array
04:55:57FromGitter<kaushalmodi> but the `gzgets` signature does not like that
04:56:22leorizepass in the pointer to the first variable
04:56:29leorizefirst index*
04:56:59leorize`addr lineArr[0]`
04:58:13leorizeif the compiler complain, just cast that expression to cstring
04:58:23leorizeinterfacing with C is never a nice thing :P
04:59:09FromGitter<kaushalmodi> finally! https://ptpb.pw/YrZg/nim
04:59:15FromGitter<kaushalmodi> thank you!
04:59:24FromGitter<kaushalmodi> I wasted about 2-3 hours on this
04:59:25FromGitter<kaushalmodi> :(
05:00:07FromGitter<kaushalmodi> *Learning C the hard way*
05:00:20leorizethere's a book with that name ;)
05:00:27FromGitter<kaushalmodi> I know
05:00:33*leorize quit (Remote host closed the connection)
05:00:39FromGitter<kaushalmodi> but never took up learning C
05:01:09FromGitter<kaushalmodi> I thought that the difference between cstring and string was that one ended in null and other didn't
05:01:26FromGitter<kaushalmodi> has no idea that cstring had to be manually initialized
05:01:51FromGitter<kaushalmodi> I reread this so many times: https://github.com/madler/zlib/blob/master/zlib.h#L1491
05:02:20FromGitter<kaushalmodi> I thought that `gzgets` would populated the `buf` with the contents from file
05:15:59FromGitter<kaushalmodi> leorize: this was really enlightening, thanks again!
05:34:07*oculux quit (Ping timeout: 244 seconds)
05:41:25*NimBot joined #nim
05:44:30TangerIs AndreiRegiani on IRC?
06:13:03*oculux joined #nim
06:23:38*miran joined #nim
06:38:16*oculux quit (Quit: blah)
06:39:24*oculux joined #nim
06:47:43*leorize joined #nim
06:54:16*kapil____ joined #nim