<< 03-10-2016 >>
00:05:52*nsf quit (Quit: WeeChat 1.5)
00:27:21*rtr_ quit (Remote host closed the connection)
00:30:05kulelu88Anything Google does is "awesome"
00:56:57*ldlework is now known as LindsayLojban
00:58:36*Matthias247 quit (Read error: Connection reset by peer)
01:27:31*Kaini quit (Remote host closed the connection)
01:27:32*kulelu88 quit (Quit: Leaving)
01:27:41*Kaini joined #nim
01:29:26*fredrik92 quit (Read error: Connection reset by peer)
01:42:32*chemist69 quit (Ping timeout: 252 seconds)
01:55:16*chemist69 joined #nim
02:26:55*dddddd quit (Ping timeout: 272 seconds)
03:00:26*mitai quit (Ping timeout: 244 seconds)
03:04:33*mitai___ joined #nim
03:26:05*RushPL joined #nim
03:46:20*mitai joined #nim
03:47:21*mitai___ quit (Ping timeout: 272 seconds)
03:51:50*mitai___ joined #nim
03:52:42*mitai quit (Ping timeout: 264 seconds)
03:58:07*Demon_Fox quit (Ping timeout: 272 seconds)
04:03:19*mitai joined #nim
04:03:31*Demon_Fox joined #nim
04:04:06*mitai___ quit (Ping timeout: 264 seconds)
04:05:02*rtr_ joined #nim
04:09:56*gangstacat quit (Ping timeout: 252 seconds)
04:23:54*rtr_ quit (Remote host closed the connection)
05:04:58*gokr joined #nim
05:29:55*ARCADIVS joined #nim
05:35:44*gokr quit (Ping timeout: 252 seconds)
05:52:09*chemist69 quit (Ping timeout: 248 seconds)
05:56:40*chemist69 joined #nim
06:38:22*desophos quit (Read error: Connection reset by peer)
06:46:47*nsf joined #nim
06:51:30*bjz joined #nim
07:03:13*brechtm_ quit (Remote host closed the connection)
07:03:51*brechtm joined #nim
07:09:53*bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
07:14:48*gokr joined #nim
07:15:09*mitai quit (Ping timeout: 244 seconds)
07:15:14*mitai___ joined #nim
07:21:21*Demon_Fox quit (Ping timeout: 244 seconds)
07:22:56*bjz joined #nim
07:24:18*Demon_Fox joined #nim
07:25:45*mitai joined #nim
07:25:48*mitai___ quit (Ping timeout: 265 seconds)
07:31:07*yglukhov quit (Ping timeout: 265 seconds)
07:36:53*Andris_zbx joined #nim
07:37:24*Arrrr joined #nim
07:37:53*mitai quit (Ping timeout: 244 seconds)
07:38:12*mitai joined #nim
07:38:53*xet7 quit (Quit: Leaving)
07:43:13*xet7 joined #nim
07:48:39*mitai___ joined #nim
07:49:06*mitai quit (Ping timeout: 264 seconds)
07:53:08*mitai joined #nim
07:53:50Arrrrbit_pass_213
07:53:53Arrrrups
07:53:54*mitai___ quit (Ping timeout: 264 seconds)
07:54:46ArrrrDamn, i have to remove this splitted console.
08:00:18*PMunch joined #nim
08:14:16def-Arrrr: cool password
08:16:35ArrrrIt is not my password, it is the nickname of a certain user *nervous smile*
08:31:16*yglukhov joined #nim
08:41:59*Demon_Fox quit (Quit: Leaving)
08:48:05*fredrik92 joined #nim
09:25:52*irrequietus joined #nim
09:26:43*bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
09:26:59*Matthias247 joined #nim
09:31:10*aaasad_ quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
09:34:24flyx„a spider walked over my keyboard“
09:36:56*udmmya joined #nim
09:37:19*udmmya left #nim (#nim)
09:39:08flyxhum, nim just seems to fail loading dylibs for me. otool -L tells me that they are not hardwired into the executable, so they are loaded dynamically, right?
09:39:10FromGitter<dom96> must have been a fat spider
09:40:26flyxI have libgobject-2.0.dylib in my DYLD_LIBRARY_PATH, but the compiled executable is still not able to find it
09:40:34flyxis there something else I need to do?
09:42:33kierany reason why readFile(string) is listed twice in the system docs?
09:44:42Araq_kier: I fear that's an old docgen bug
09:46:52*Salewski joined #nim
09:47:34Salewski$ cat nim.cfg
09:47:40Salewskinimcache:"/tmp/$projectdir"
09:47:55*bjz joined #nim
09:47:55Salewski# That should be the default.
09:48:15SalewskiSaves SSD and speeds up HDD.
09:50:21flyxhow can I query more information about `could not load: libgobject-2.0.dylib`? like, telling me *why* it could not load it?
09:51:15*fredrik92 quit (Read error: Connection reset by peer)
09:52:02*bjz quit (Client Quit)
09:52:05Salewskiflyx, do you have installed GTK3 developer libs for your box, does a file with taht name exists on your box.
09:52:39flyxSalewski: yes, they are available in DYLD_LIBRARY_PATH
09:52:45*bjz joined #nim
09:52:54cheatfateflyx, write your own "import dynlib" and use loadLib
09:53:06cheatfateand get your osLastError
09:53:22*bjz quit (Client Quit)
09:53:47Araq_flyx: use -d:nimDebugDlOpen
09:54:08Araq_(is this documented?)
09:54:10cheatfateyeah, more undocumented features :)
09:54:38flyxAraq_: nice, but yields `lib/system/dyncalls.nim(77, 19) Error: undeclared identifier: 'c_stderr'`
09:55:01Araq_patch lib/system/dyncalls.nim please
09:55:02*aaasad joined #nim
09:55:08flyxI'll try
09:55:40Araq_ stderr.write(error)
09:55:41Araq_ stderr.rawWrite("\n")
09:55:47Araq_^ should work instead
10:00:04flyxjep. now I get `dlopen(libgobject-2.0.dylib, 2): Symbol not found: __cg_jpeg_resync_to_restart`
10:00:39flyxsoooooo I don't think I have time for this. no nim-chess for me :/
10:01:06*allan0 quit (Ping timeout: 264 seconds)
10:01:27flyxpr: https://github.com/nim-lang/Nim/pull/4848
10:02:00Araq_flyx: please add something like "compile with -d:nimDebugDlOpen for more information"
10:02:18Araq_so that people don't have to read the nonexisting docs about this switch
10:02:20Salewskiflyx, may that be an 32 vs 64 bit issue?
10:02:24*chemist69 quit (Ping timeout: 265 seconds)
10:02:35flyxSalewski: I don't think so, I checked the dylib
10:03:00*fredrik92 joined #nim
10:05:10Salewskiflyx: of course the basic test for gobject lib trouble would be to compile a plain C test program using gobject.
10:06:13FromGitter<dom96> Anybody using the Yahoo Finance API here?
10:07:38cheatfateflyx, http://stackoverflow.com/questions/17643509/conflict-between-dynamic-linking-priority-in-osx i think this helps
10:07:54*ARCADIVS quit (Quit: ARCADIVS)
10:08:10flyxAraq_: okay, updated pr
10:09:58*allan0 joined #nim
10:10:42Araq_ty
10:11:11flyxcheatfate: not really. it works in cases where the lib is hardwired in the executable (seen with otool -L), but as I said, Nim does not do that
10:11:44flyxcheatfate: if I try the answer with `export DYLD_LIBRARY_PATH=/usr/lib/:$DYLD_LIBRARY_PATH`, I get a different error afterwards
10:12:06flyx‚Incompatible library version: libTIFF.dylib requires version 8.0.0 or later, but liblzma.5.dylib provides version 6.0.0’
10:12:09FromGitter<dom96> Araq_: Why hide this behind a define?
10:12:31Araq_flyx: Nim can do these linker dances too via --dynlibOverride
10:13:44flyxdom96: how do you compile against GTK on OSX? I am used to jhbuild. maybe that just doesn't work nice with Nim
10:14:32FromGitter<dom96> flyx: with a lot of sweat and prayers
10:14:57FromGitter<dom96> I'm still fairly sure that it doesn't work 100%
10:14:59Araq_every scripting language uses the dlopen mechanism
10:15:14Araq_but ok, if Nim uses it, it's bad (TM)
10:15:21FromGitter<dom96> I had to switch to using the homebrew built DLLs.
10:15:41Araq_and instead we should hack linker commands together
10:16:02FromGitter<dom96> Araq_: nah, but we should give the user as much information as possible about why the dynlib loading failed
10:16:03Araq_IMO Unix doesn't support shared libraries.
10:16:06cheatfateAraq_, its not bad techinque at all, its just an OS which don't like anything except ObjectiveC
10:16:09FromGitter<dom96> So once again, why is this hidden behind a define?
10:16:23flyxAraq_: I think the jhbuild system is not really made for scripting languages, and they won't work easily with it either
10:18:03flyxthe problem is, it bootstraps almost everything itself and duplicates libraries already existing on the system. which works as long as dependencies are hardwired to the right versions of the library, but once you use dlopen, it fails. I don't think it is something Nim does wrong
10:18:45flyxcheatfate: that problem doesn't have to do anything with ObjC
10:19:44flyxdom96: well homebrew will probably work because it uses the libs already available on the system, I guess. too bad I use nix for installing my unix tools and that does not support GTK on OSX
10:20:08flyxif I install homebrew besides nix, everything will *surely* explode
10:22:21flyxfor the time being, I will not investigate this further. I just thought a game of chess would be nice, but I won't put that much effort in it…
10:23:03Araq_dom96: because it's not always available
10:23:13Araq_we had some issues with it on some OSes
10:24:09FromGitter<dom96> Araq_: so what? Is there no way to check if it is available?
10:25:26Araq_I don't know, if I get something that doesn't work, I disable it and let others clean it up. I also have real bugs to fix.
10:25:58FromGitter<dom96> flyx: can you look into adding this without a define?
10:26:12Araq_feel free o enable it on osx and linux out of the box
10:26:22*bjz joined #nim
10:26:25Araq_oh wait linux with muslC might not support it either
10:26:33Araq_here we go ...
10:26:53FromGitter<dom96> What is "it"?
10:27:12cheatfatemuslC is small C library uses in some linux distros
10:27:35FromGitter<dom96> ``dlerror``?
10:27:43Araq_yes
10:28:06FromGitter<dom96> And what happens when it is not supported?
10:28:13FromGitter<dom96> SIGSEGV?
10:28:51cheatfateAraq_, i think you are wrong, https://github.com/seL4/libmuslc/blob/master/include/dlfcn.h
10:29:10*chemist69 joined #nim
10:29:18*bjz quit (Read error: Connection reset by peer)
10:29:30cheatfateand official repo http://git.musl-libc.org/cgit/musl/tree/include/dlfcn.h
10:29:59flyxdom96: I cannot evaluate that with anything but my own OS, and from what Araq_ is saying, I do not feel informed enough about it to make that change with good conscience.
10:30:35*bjz joined #nim
10:31:12FromGitter<dom96> @flyx: ok, create an issue for it then please instructing us to investigate it more
10:31:22flyxwill do
10:31:26FromGitter<dom96> and feel free to keep your PR as-is
10:36:53Araq_cheatfate: yes, my point is: I don't remember where it caused problems
10:37:34cheatfateAraq_, i think if `dlopen` is available then `dlerror` is available too
10:37:46flyxissue: https://github.com/nim-lang/Nim/issues/4849
10:41:30*brechtm_ joined #nim
10:44:50*brechtm quit (Ping timeout: 252 seconds)
10:46:12*bjz quit (Remote host closed the connection)
10:48:11*pafmaf joined #nim
10:48:18*Salewski left #nim (#nim)
10:49:17FromGitter<dom96> flyx: thanks
10:50:33FromGitter<dom96> This seems like a cool thing we could set up for Nim http://www.brendangregg.com/flamegraphs.html
10:50:35*bjz joined #nim
10:51:30corecodehi
10:51:47*bjz quit (Read error: Connection reset by peer)
10:51:52corecodeso i had a look at UML StateMachines
10:52:03corecodethat's some big spec
10:53:11corecodeunfortuately they don't talk about implementation nor about text syntax
10:53:25*bjz joined #nim
10:56:50FromGitter<moigagoo> Hi! ⏎ ⏎ I'm trying a sample from tutorial 2 about property setters. The setter proc is not invoked. Here's the code I'm running. It's basically just the sample with a minor change: ⏎ ⏎ ```code paste, see link``` ... [https://gitter.im/nim-lang/Nim?at=57f2397234a8d5681cd92633]
11:00:29FromGitter<moigagoo> Here's where I took the code from http://nim-lang.org/docs/tut2.html#object-oriented-programming-properties
11:01:06FromGitter<moigagoo> ``host=`(s, 34)`` does work and produces 68.
11:05:46*Salewski joined #nim
11:07:06Salewskimoigagoo, the example is for different modules. When all your code is in one module, it is a plain assignment.
11:08:25SalewskiFor different modules, assignment would not work, because host is not exportet.
11:11:00*foocraft joined #nim
11:13:51SalewskiBut I am not sure if proc host= should overwrite assignment. Is this for Nim v 0.15?
11:14:44SalewskiBye...
11:14:47*Salewski left #nim (#nim)
11:16:21*elrood joined #nim
11:16:29*arnetheduck joined #nim
11:16:32Araq_builtin dot interpretation is preferred over accessors
11:16:47Araq_so the proc host= should not produce an infinite recursion
11:20:58FromGitter<moigagoo> @Salewski @Araq Sorry, I don't get it. Does this code work only if I call s.host = 34 from a different module?
11:21:19FromGitter<moigagoo> Oh, sorry. Got it.
11:21:33FromGitter<moigagoo> Thanks.
11:21:50FromGitter<moigagoo> (The docs should probably make this bit clear.)
11:23:07FromGitter<moigagoo> And now for something completely different. ⏎ ⏎ Are there any conferences featuring Nim planned for 2017? Workshops, meetups, whatever?
11:24:08FromGitter<moigagoo> My company is planning the budget on conference attendance for the employees, and I'd love to partake in a Nim conference.
11:27:21hohlerdemoigagoo: this has been brought up yesterday, but there is nothing planned yet
11:28:17*bjz quit (Read error: Connection reset by peer)
11:29:20*bjz joined #nim
11:33:42*brechtm_ quit (Remote host closed the connection)
11:34:20*brechtm joined #nim
11:41:20*Arrrr quit (Quit: WeeChat 1.5)
12:05:40hohlerdemulti methods and var parameters seem to have problems. I fear this has been asked many times before, but I couldn't find any references.
12:05:44hohlerdehttps://gist.github.com/hohlerde/a7ea83f0d1db37ddbaca8dc622f36589
12:07:35*chemist69 quit (Ping timeout: 265 seconds)
12:08:18cheatfatehohlerde, if you using `refs` you do not need `var`
12:09:12hohlerdecheatfate: I know, but I wondered if it works, maybe the compiler is just ignoring it due to the ref.
12:09:39*chemist69 joined #nim
12:12:15Araq_hohlerde: they don't have problems. It's your misunderstanding of the subtype relation.
12:12:30Araq_in a nutshell: there is none for 'var refs'
12:12:39Araq_it would be unsound.
12:13:35hohlerdearaq: alright, makes sense to me
12:13:49baabelfishhas anyone used coro?
12:14:43*gangstacat joined #nim
12:19:04Araq_baabelfish: it's not tested well and everybody uses async instead
12:28:42*PMunch quit (Ping timeout: 264 seconds)
12:33:59FromGitter<moigagoo> I've just installed Nim 0.15.0 on Windows. I noticed that DLLs are no longer shipped with Nim, which makes it painful to launch Nimble and build packages that used to be build easily on 0.14.2. What's the reasoning behind this decision? I must admit it complicates my life a lot. ⏎ ⏎ Also, even after adding the necessary DLL to path, I can't make Nimble work. It crashes with "nimscriptapi.nim not found" error.
12:34:41Araq_moigagoo: the installer asks you about support DLLs
12:35:36Araq_nimble should work out of the box without any further installation
12:35:56Araq_what does 'where nimble.exe' say?
12:36:03FromGitter<moigagoo> Hmm, I see. I'm not running the official installer. I'm using [scoop](scoop.sh) which extracts the content of the installation package.
12:36:10FromGitter<moigagoo> So this must be the reason.
12:36:57FromGitter<moigagoo> It used to work with 0.14.2 because it included all the DLLs by default.
12:37:48Araq_possible, but an artifact of an unclear installer generation process :P
12:40:52*aaasad_ joined #nim
12:44:25*aaasad quit (Ping timeout: 248 seconds)
12:45:01Calinouwow, Scoop looks nice
12:45:03Calinouthanks for sharing :P
12:45:39FromGitter<moigagoo> You're welcome :-) Scoop is fantastic, it changed Windows for me.
12:46:10FromGitter<moigagoo> I refuse to install software that can be installed with scoop with their original installers :-D
12:48:27Calinouhow does it compare against Chocolatey?
12:48:32Calinou(other than being usable as non-admin easily)
12:48:33Araq_yeah, refuse to use anything that doesn't work with some unofficial barely known tool. smart move. :P
12:48:40FromGitter<moigagoo> It's superior in any way.
12:49:04FromGitter<moigagoo> It installs software to a single place instead of polluting the disk and PATH.
12:49:32FromGitter<moigagoo> As you rightly mentioned, it doesn't require admin privileges.
12:50:38FromGitter<moigagoo> Contributing is also much easier. A scoop package is just a json file in a GitHub repo. So when a new version of software is released, it takes a minute to update it on scoop.
12:50:50*PMunch joined #nim
12:52:07FromGitter<moigagoo> Also, the package registry is far less cluttered and chaotic than choco's. Git is git, openssh is openssh, plain and simple. In choco, you have like 5 packages for git, none of which is called git.
12:52:33FromGitter<dom96> to be fair, DLLs should be installed by default by Nim
12:53:34FromGitter<moigagoo> > **<Araq_>** yeah, refuse to use anything that doesn't work with some unofficial barely known tool. smart move. :⁠P ⏎ I just like installing devtools through console and using the best tool to do the task out there. Is it bad? :-)
12:54:51Araq_moigagoo: Nothing wrong with using tools that suit you, everything wrong with becoming religious about it.
12:57:10Araq_"gosh these idiots did break my scoop install, I refuse to use it" is not a sane thing to do when 'scoop' is as known as Yoshinori Ohsumi
12:59:40FromGitter<moigagoo> > "gosh these idiots did break my scoop install, I refuse to use it" ⏎ ⏎ Well, that's not remotely what I said. Definitely not calling anyone an idiot. And definitely not forcing anyone to use scoop. I'm far from being religious about it, that's for sure. Just asking for some help in adapting the installer for scoop, that's all.
13:00:31cheatfatedom96, as for me i dont want situation, when Nim install on my system pretty old and renamed openssl dlls...
13:02:42cheatfatei'm also don't want to install libpcre and libsqlite to run tests...
13:03:23cheatfateand don't want to install gtk, sdl, nodejs and all other useless shit to run all tests
13:03:32Araq_moigagoo: I am not trying to put words in your mouth and I'm willing to help you. It's just that you shouldn't "refuse to use" things, but whatever.
13:09:33*dddddd joined #nim
13:10:00FromGitter<moigagoo> Please notice the smiley face after the "refuse to use" sentence. While scoop is indeed an extremely convenient way to install software on Windows, I'm far from *seriously* claiming it's the only one.
13:12:31FromGitter<moigagoo> Anyway. It's quite clear that since the DLLs are not shipped with the installer now, the right way to fix the scoop installer is to download them from nim-lang.org and copy the files into Nim's installation directory. Thanks for the clarification!
13:14:29FromGitter<dom96> cheatfate: then you can deselect the option to install it ;)
13:15:06FromGitter<dom96> @moigagoo but they are shipped with the installer
13:15:27cheatfatedom96, i think they are downloaded but not shipped/bundled in installer
13:16:45Araq_hmm I need to install scoop
13:17:48Araq_cheatfate: yeah we should get rid of these deps for the tester
13:18:36cheatfateAraq_, i dont think you need to...
13:19:51cheatfateAraq_, first it uses unofficial not signed binary distributions so you can easily download and install malware by yourself
13:20:22FromGitter<dom96> Ahh right.
13:20:34FromGitter<dom96> If somebody compromises our servers then things won't be pretty...
13:21:20*chemist69 quit (Quit: WeeChat 1.5)
13:23:52*chemist69 joined #nim
13:24:48flyxsince nim-lang.org doesn't support https, we're all screwed anyway.
13:25:43cheatfateflyx, most of us using github and source distributions...
13:26:15cheatfateflyx, signed binary distributions is much better then https
13:26:46flyxthat wasn't a serious comment.
13:28:02*nsf quit (Read error: Connection reset by peer)
13:28:36*nsf joined #nim
13:45:48*Matthias247 quit (Read error: Connection reset by peer)
13:51:15*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
14:11:45*Dankrad1 quit (Quit: Leaving.)
14:15:37*derka quit (Ping timeout: 272 seconds)
14:26:55*irrequietus quit ()
14:27:10*irrequietus joined #nim
14:28:40*derka joined #nim
14:30:04*gangstacat quit (Quit: Leaving)
14:34:26*PMunch quit (Quit: leaving)
14:43:41*Dankrad joined #nim
14:51:24*brechtm quit (Read error: Connection reset by peer)
14:51:48FromGitter<dom96> So I guess bundling Nimble didn't fix these problems either huh? https://github.com/nim-lang/nimble/issues/258
14:52:16FromGitter<dom96> @moigagoo unless scoop installed things strangely?
14:52:45*brechtm joined #nim
14:53:16Araq_dom96: he never told us what 'where nimble.exe' says for him
14:53:59*FromGitter * dom96 just remembered that he was planning on statically reading that file into nimble.exe anyway
14:54:08Araq_bundling Nimble did fix every problem.
14:54:43Araq_yeah right, read everything from lib/*.nim into the exe
14:54:53Araq_what can possibly go wrong?
14:55:09Araq_nobody will be confused updating the stdlib had no effect...
14:56:50FromGitter<dom96> nimscriptapi.nim isn't part of the stdlib
14:57:12FromGitter<dom96> it will use the statically included one as a fallback
14:57:50Araq_ah, my bad, sorry then.
14:58:06Araq_yeah maybe we don't ship nimscriptapi.nim
14:58:25FromGitter<dom96> I think we do
14:59:31federico3fwiw nimscriptapi.nim is in the source tarball
15:02:01*gokr quit (Ping timeout: 248 seconds)
15:34:48*foocraft quit (Quit: Leaving)
15:38:52*xet7 quit (Quit: Leaving)
15:42:01*pregressive joined #nim
15:43:20*pregressive quit (Client Quit)
15:44:57*pregressive joined #nim
15:49:01*Andris_zbx quit (Remote host closed the connection)
15:57:02*yglukhov_ joined #nim
16:00:32*yglukhov quit (Ping timeout: 252 seconds)
16:01:42*yglukhov_ quit (Ping timeout: 264 seconds)
16:20:14*derka quit (Ping timeout: 244 seconds)
16:30:30*Jesin quit (Quit: Leaving)
16:33:13*derka joined #nim
16:39:02*gokr joined #nim
16:47:37*yglukhov joined #nim
16:49:02*desophos joined #nim
16:51:45*yglukhov quit (Ping timeout: 244 seconds)
16:52:25*aaasad_ quit (Remote host closed the connection)
16:56:00*nsf quit (Quit: WeeChat 1.5)
17:04:57*yglukhov joined #nim
17:06:36*brechtm_ joined #nim
17:06:54*brechtm quit (Read error: Connection reset by peer)
17:07:23*Trustable joined #nim
17:09:28daekanoI’m quite new to compiled languages. When tinkering with a Go application, I was able to “append” a file onto the executable and read it from within the application. Am I able to do something similar with Nim, or should I be encouraged to move configuration/data into an API call and avoid compiler magic? (I don’t want the data to be a data structure within code).
17:11:04daekanoThe method I used: https://www.ueber.net/who/mjl/blog/p/assets-in-go-binaries/
17:13:30dom96You don't need any hacks to do this in Nim, just use staticRead: http://nim-lang.org/docs/system.html#staticRead,string
17:14:33daekano:D
17:14:45daekanoThanks, still learning where the books are in the library, so to speak.
17:16:20daekanoSo when compiled, the program checks for the file and reads it, keeps any values in the resultant binary. If there are any issues reading or using that data, Nim issues a compiler error.
17:16:25daekanoSound about right?
17:18:42dom96yeah
17:21:24*vegai joined #nim
17:21:48daekanothanks @dom96
17:22:15daekanoAs usual, the implemented solution is easier than even asking the question.
17:22:57elrooda great tactic to confuse the hell out of any tamper-protection software or advanced antivirus one might be running
17:25:09*brson joined #nim
17:26:54federico3elrood: how?
17:32:07elroodisn't that obvious, with what daekano is doing? altering executables by storing configuration data within? mildly interesting as a proof-of-concept and a nice *look, mom, no hands*-approach, but not sane or advisable in any way beyond that
17:40:01cheatfateelrood, you are right, but you can create section with some gcc/vcc pragmas and put data there in compile time... so there will be no problems with AV or any other shit
17:40:04federico3elrood: with "confuse" you mean trigger false positives? potentially, but many antivirus are smarter than that. (anyhow, of course it's an odd thing to do - embedding stuff in binaries it's what arcade games were doing in those times)
17:44:07*pregressive quit ()
17:47:23elroodif it's static immutable data, true, while still a questionable practice. the idea of storing configuration data that way within the executable doesn't seem overly well thought-out, though
17:50:28*gangstacat joined #nim
17:52:14*brechtm joined #nim
17:55:29*pregressive joined #nim
17:56:04*brechtm_ quit (Ping timeout: 265 seconds)
17:57:17*brechtm quit (Ping timeout: 272 seconds)
18:00:11*Jesin joined #nim
18:04:44*Jesin quit (Client Quit)
18:05:06*Jesin joined #nim
18:21:24*kulelu88 joined #nim
18:25:11*derka quit (Ping timeout: 252 seconds)
18:36:14daekanoelrood: Thanks for your insight. Manually modifying the executable aside, is using staticRead a better approach? Is there a better way to encapsulate state (always immutable in this case)? I would prefer to rely on just the executable and not on an external server.
18:41:18*Sentreen quit (Ping timeout: 264 seconds)
18:41:49federico3daekano: forgive the stupid question but why don't you just ship conf files with the executable?
18:46:10daekanoNot a stupid question, I’m sure my decisions are suspect.
18:46:50daekanoI am thinking of distributing a CLI application, and the goal is to have little to no setup
18:47:44federico3ah and maybe you are creating a conf file if it's not already there - on the first run?
18:48:00daekanoIt’s more data than configuration, really.
18:48:21daekanoI don’t want to couple to the system with a database connection or even a sqlite file
18:48:45daekanoThe alternative is a client-server architecture
18:48:58*pregress_ joined #nim
18:49:02daekanobut then I have to sell serving it from somewhere on the network
18:49:08*pregressive quit (Read error: Connection reset by peer)
18:49:17federico3what prevents you from shipping a file on the side?
18:49:54daekanoNothing I suppose. The binary could have an install command to move things to an expected location.
18:50:08federico3or an external installer of some sort?
18:50:34daekanoThat is something I have never done before so that could explain why I haven’t considered it.
18:50:43daekanoI’m coming from a web background.
18:54:45*Dankrad1 joined #nim
18:54:51*Sentreen joined #nim
18:56:49*Dankrad quit (Ping timeout: 272 seconds)
18:57:16elrooddaekano, not a nim expert myself, but for static data nim's readFile seems like the way to go. if you need modifiable data that's a different question though, and essentially not a nim-related one. there won't really be a way around a second file i'm afraid
18:57:34daekanoAll the data is totally immutable
18:58:15daekanoI think it would be sufficient for an initial iteration and I can move to a more robust configuration method or server architecture if I need it.
18:58:22daekanothanks elrood
18:58:26daekanoand thanks federico3
18:59:02federico3daekano: how big is the file to embed?
19:00:02daekanoNot large, we’re looking at 3-4 rows of text relating repository names and release names with a freshness field
19:00:35daekanoI had considered just planting it inside of Nim as a data structure but I don’t want people to have to know Nim to update it, thus a configuration file and a build step.
19:01:05*aaasad joined #nim
19:01:29federico3aah then it's not different than a having few large strings - embedding it's ok
19:01:40daekanocool
19:02:03daekanoI use this project as a way to learn a new language. I went the embedding route with Golang, and I built an API with Crystal.
19:02:09daekanoHoping one day it sticks
19:02:27federico3(now, if it was 1GB of images and sounds it would be odd)
19:02:32daekanohaha
19:02:34daekanoof course
19:02:51Araq_daekano: staticRead is fine and so is readFile(os.getAppDir() / "file.txt")
19:03:30Araq_then you have file.txt next to your executable and it always can be found
19:07:43daekanoright
19:08:15daekanoYes, the alternative to a full blown API server would be a fileserver where I can just pull down the latest .txt configuration file alongside the binary.
19:08:28daekanoMuch less work from an operations point of view.
19:08:29daekanohaha
19:14:53*derka joined #nim
19:16:51*Kingsquee joined #nim
19:20:11*brson quit (Ping timeout: 252 seconds)
19:30:21*brson joined #nim
20:06:23*brson quit (Ping timeout: 252 seconds)
20:07:27*brson joined #nim
20:16:43*pafmaf quit (Ping timeout: 265 seconds)
20:29:18*derka quit (Ping timeout: 264 seconds)
20:31:37*libman joined #nim
20:38:07*Trustable quit (Remote host closed the connection)
20:38:39*libman quit (Quit: Leaving.)
20:38:49*libman joined #nim
20:43:59*ofelas quit (Remote host closed the connection)
20:44:18*ofelas joined #nim
20:47:19*Jesin quit (Quit: Leaving)
20:53:54*Matthias247 joined #nim
21:00:59*bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:35:56*libman wants to build a Sistine Chapel replica and have flyx's post from http://forum.nim-lang.org/t/2563 painted in oils as one of the ceiling frescoes - it's that awesome! :D
21:38:55*bjz joined #nim
21:52:06*Demon_Fox joined #nim
21:52:27*bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:01:31libmanExcept, come to think of it, syntax highlighting on the forum could be much better.
22:04:29*PMunch joined #nim
22:05:47*irrequietus quit (Remote host closed the connection)
22:06:01*JeffCanJam4a20 joined #nim
22:08:50*nsf joined #nim
22:15:37*gokr quit (Ping timeout: 265 seconds)
22:23:26*pafmaf joined #nim
22:23:47*pafmaf quit (Read error: Connection reset by peer)
22:29:39*pregress_ quit (Remote host closed the connection)
22:32:04FromGitter<girvo> I'm trying to set up a Travis CI config for 0.15.0, but I'm struggling on compiling Nim -- `undefined reference to "clock_gettime"` -- anyone seen that before? It's with GCC, and what I've come across says that it's missing `-lrt` which shouldn't be needed from newer versions of GCC, but Travis says I'm at the latest version for its `bash` environment :(
22:32:18FromGitter<girvo> `c_code/2_2/stdlib_osproc.o: In function `nospwaitForExit':`
22:38:50*Dankrad joined #nim
22:38:54FromGitter<girvo> Heres the full command and output: http://hastebin.com/sirenamopa.sh
22:38:56*derka joined #nim
22:39:30cheatfategirvo what version of gcc you are using?
22:39:51FromGitter<girvo> cheatfate: Clang, heh. Still getting the same error :/
22:40:35FromGitter<girvo> I'm getting the full version number now, one moment
22:41:13*Dankrad1 quit (Ping timeout: 248 seconds)
22:41:54cheatfateand why do you think its not needed from newer versions of GCC?
22:42:11cheatfatei have gcc 6.2.1 and i still need -lrt
22:42:28*Dankrad quit (Client Quit)
22:43:53cheatfateand also i think -lrt not depends on GCC but depends on your C library...
22:44:18cheatfateAlso Nim uses Travis Ci and it run tests every PR
22:46:31*aaasad_ joined #nim
22:47:56FromGitter<girvo> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
22:48:03*elrood quit (Quit: Leaving)
22:48:27cheatfategirvo looks like you even not near with latest version of GCC
22:48:47FromGitter<girvo> Yep. But it's damned package system won't let me install a newer one so far :/
22:48:55FromGitter<girvo> I'll see if I can work around it, will let you know how I go
22:49:16cheatfatei recommend you 4.8+
22:49:36FromGitter<girvo> I'll see if I can get 6 up and running, seems it's supported, just got to work out how!
22:49:45*aaasad quit (Ping timeout: 248 seconds)
22:50:06FromGitter<girvo> Ah I see -- it actually does have gcc 6, but it's accessed via `gcc-6` instead of `gcc`?
22:55:37*irrequietus joined #nim
22:56:13GaveUpinteresting you say 4.8 ... cross compile toolchain here on 4.9.3 and it looks like something between 14.2 and 15 seems to have broke things (hello world throws and OOM)
23:00:15cheatfatei'm successfully build nim with 4.2.1
23:00:42cheatfatecompiler is not a problem, c library is a problem
23:01:06*JeffCanJam4a20 quit (Read error: Connection reset by peer)
23:01:07FromGitter<girvo> cheatfate: Okay interesting. I'll give it a try with `trusty` which should have newer versions of clib
23:01:36*irrequietus quit ()
23:01:37cheatfategirvo first try to find -lrt
23:01:54cheatfateif it present in system then we need to update something
23:01:54FromGitter<girvo> cheatfate: yeah, good plan
23:07:22FromGitter<girvo> Using dist: trusty seems to have fixed it within Travis
23:07:35FromGitter<girvo> Perhaps it's something to do with its old-as-the-hills libc... Not sure
23:07:43FromGitter<girvo> Might make a note on the wiki though, for future reference
23:10:35FromGitter<girvo> Whoa, oops, apparently not :/
23:12:30FromGitter<girvo> The final `gcc -o bin/nim` command to link it all together doesn't actually have an `-lrt` -- is it supposed to?
23:13:07FromGitter<girvo> Aside from the object list, it only has: `-ldl -lm`
23:14:50FromGitter<girvo> What. Okay, so, running it with `sudo: true` instead of `sudo: false` works, with nothing else changed... that's crazy Travis.
23:22:27*Matthias247 quit (Read error: Connection reset by peer)
23:38:49*derka quit (Ping timeout: 248 seconds)
23:48:32kulelu88question about Nim syntax: if we suggest syntax changes, how adversely can these affect the compiler/compile-times, etc. ?
23:57:15*derka joined #nim
23:58:22libmanA big problem in the software industry is fragmentation between different language ecosystems. JVM/CLR tried to solve this problem, but there's nothing on native level.
23:59:17libmanMaybe Nim can solve this problem by offering different syntax front-ends sharing the same modules (nimble). :P