<< 25-01-2018 >>
00:05:12*Snircle_ joined #nim
00:05:28*Snircle quit (Ping timeout: 252 seconds)
00:17:51*chemist69 quit (Ping timeout: 256 seconds)
00:18:31*chemist69 joined #nim
00:24:50*MJCaley quit (Quit: MJCaley)
00:38:15user0Ahm, this might be a stupid question, but why doesn't nimble create a standard project structure with `nimble init`?
00:38:43*MJCaley joined #nim
00:40:09*gokr quit (Quit: Leaving.)
00:46:12FromGitter<Quelklef> i guess cause it's more useful for it to work on existing projects
00:47:40user0That's `nimble develop`, isn't it?
01:13:42*marenz_ quit (Ping timeout: 268 seconds)
01:28:42*tinAndi joined #nim
01:31:56*user0 quit (Ping timeout: 255 seconds)
01:32:05*user0 joined #nim
01:34:10*tinAndi quit (Ping timeout: 240 seconds)
01:46:01*ludocode quit (Quit: ludocode)
01:46:42*ludocode joined #nim
01:50:25*xet7 quit (Ping timeout: 260 seconds)
01:54:29*MJCaley quit (Quit: MJCaley)
02:02:40*xet7 joined #nim
02:05:47*tinAndi joined #nim
02:11:10*tinAndi quit (Ping timeout: 240 seconds)
02:21:52*chemist69 quit (Ping timeout: 260 seconds)
02:37:03*chemist69 joined #nim
02:39:30*MJCaley joined #nim
02:56:44TangerHey folks! What factors would you consider when picking between using object variance or an object hierarchy?
03:03:20*vlad1777d quit (Remote host closed the connection)
03:05:33FromGitter<Araq> if it needs to be "extensible", object hierarchy, otherwise case object
03:24:15*dddddd quit (Remote host closed the connection)
03:30:08*Snircle_ quit (Quit: Textual IRC Client: www.textualapp.com)
03:33:47TangerThanks Araq
03:42:14*MJCaley quit (Quit: MJCaley)
04:01:11*endragor joined #nim
04:09:11*MJCaley joined #nim
04:19:54*MJCaley quit (Quit: MJCaley)
04:28:27*arecaceae quit (Remote host closed the connection)
04:28:46user0I have two constructor functions doing mostly identical operations. The only differences are the name of the function and return statement. Any tips so that I don't repeat myself? https://play.nim-lang.org/?gist=85b677900aab25e36d9d4d6aa309c372
04:28:47*arecaceae joined #nim
04:29:38user0I mean I could ask for isRef: bool but that's a bit too inelegant
04:36:27*yglukhov joined #nim
04:40:40*yglukhov quit (Ping timeout: 240 seconds)
04:43:42*c0ntribut0r joined #nim
05:02:40*c0ntribut0r quit (Ping timeout: 240 seconds)
05:04:28*c0ntribut0r joined #nim
05:07:32Araqtemplate it?
05:17:30*c0ntribut0r quit (Ping timeout: 252 seconds)
05:18:15*c0ntribut0r joined #nim
05:22:10*c0ntribut0r quit (Ping timeout: 240 seconds)
05:24:36*c0ntribut0r joined #nim
05:44:48*c0ntribut0r quit (Ping timeout: 240 seconds)
05:47:14*c0ntribut0r joined #nim
05:48:46*Yardanico joined #nim
05:52:20*Yardanico quit (Remote host closed the connection)
05:55:09*Yardanico joined #nim
06:00:46*endragor quit (Remote host closed the connection)
06:08:21*leorize joined #nim
06:25:01*nsf joined #nim
06:29:22*jared joined #nim
06:29:36*endragor joined #nim
06:29:36*jared is now known as j_rods_s
06:30:32*j_rods_s quit (Client Quit)
06:30:47*j_rods_s joined #nim
06:40:20*j_rods_s quit (Quit: j_rods_s)
06:40:34*j_rods_s joined #nim
06:47:50FromGitter<survivorm> @shashlick nice editor, found no bugs so far (Alt linux, xfce terminal)
07:27:32*gokr joined #nim
07:33:44FromGitter<ZarsBranchkin> shaslick: Had some issues building the binary, since there exists a directory with the same name `qnim`, heh. Also, maybe automatically replace tabs with 2 or 4 spaces? At least now it inserted hard tabs
07:38:52FromGitter<ZarsBranchkin> Although, I see that you managed a nice UI, looks great
07:44:40FromGitter<ZarsBranchkin> Also, it seems that my terminal emulator shadows F12 key..
07:53:11*yglukhov joined #nim
08:02:58*yglukhov quit (Remote host closed the connection)
08:04:04*PMunch joined #nim
08:05:00Araqlink to this editor please?
08:11:38FromGitter<mratsim> The dropbox link that was posted yesterday a couple lines above
08:11:45PMunchAraq, https://irclogs.nim-lang.org/24-01-2018.html#22:39:36
08:13:14PMunchHmm, I get a timeout on the dropbox link
08:14:14*Ven`` joined #nim
08:15:19*c0ntribut0r quit (Read error: No route to host)
08:15:47*c0ntribut0r joined #nim
08:15:57FromGitter<mratsim> OpenCL is so verbose, (want to support int32 + int64 + float32 + float64, happy typing) I understand people prefer Cuda just because of the C++ template support. I think non-hair splitting OpenCL usage can be a killer feature of Nim.
08:24:32*pelle joined #nim
08:27:00PMunchHmm, I'm working on the parser library and I have some questions about tuples. What I'm using as my "inspiration" is this library for Ruby: http://kschiess.github.io/parslet/
08:28:10PMunchIt supports the .as procedure that names the output of a parser in the object that is returned
08:29:54PMunchBut I don't really need the names to be available on runtime, so I was thinking about using tuples
08:31:25PMunchBut if I have a proc defined as "proc something[T](x: string): Maybe[(T, string)]" it seems like the name get's stripped
08:34:52FromGitter<alehander42> btw why doesn't nimble init create a src directory etc, if that's the expected nimble file structure
08:35:26FromGitter<alehander42> `.as` would be very useful, I always hate using parser gen where I can't have fine grained control on what kind of node is constructed
08:36:37leorizeAnyone encountered this bug? https://github.com/nim-lang/Nim/issues/7136
08:42:04PMunchHuh, that looks really weird
08:57:48*c0ntribut0r quit (Ping timeout: 240 seconds)
08:58:48*Yardanico quit (Ping timeout: 240 seconds)
08:59:34*pelle quit (Ping timeout: 260 seconds)
09:04:39*gmpreussner quit (Ping timeout: 256 seconds)
09:05:21*gmpreussner joined #nim
09:18:21*floppydh joined #nim
09:18:53*yglukhov joined #nim
09:21:13*yglukhov quit (Read error: Connection reset by peer)
09:21:36*yglukhov joined #nim
09:24:22*dddddd joined #nim
09:27:14*xkapastel quit (Quit: Connection closed for inactivity)
09:28:48*Ven`` quit (Ping timeout: 240 seconds)
09:37:49*Ven`` joined #nim
09:40:12FromGitter<dom96> @alehander42 because that's not implemented in your version of nimble...
09:47:56FromGitter<alehander42> oh well my nimble was *ancient*
09:48:30FromGitter<alehander42> :D
09:51:28*leorize quit (Quit: WeeChat 2.0.1)
09:54:03*user0 quit (Quit: user0)
10:01:18*c0ntribut0r joined #nim
10:04:05*oprypin quit (Ping timeout: 240 seconds)
10:04:40*oprypin joined #nim
10:17:55*zama quit (Ping timeout: 260 seconds)
10:24:18*arnetheduck joined #nim
10:25:25*zama joined #nim
10:31:24*vlad1777d joined #nim
10:35:05*solitudesf joined #nim
10:37:55*floppydh quit (Quit: WeeChat 2.0.1)
10:41:44*floppydh joined #nim
10:57:00*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:57:03*crem quit (Ping timeout: 256 seconds)
10:58:15*crem joined #nim
11:13:04*tinAndi joined #nim
11:13:14*user0 joined #nim
11:15:31*couven92 joined #nim
11:18:18*tinAndi quit (Ping timeout: 240 seconds)
11:18:44*gokr quit (Quit: Leaving.)
11:41:00*samhain joined #nim
11:41:04*Arrrr joined #nim
11:41:04*Arrrr quit (Changing host)
11:41:04*Arrrr joined #nim
11:41:27*MJCaley joined #nim
11:52:12*MJCaley quit (Quit: MJCaley)
11:56:04*vlad1777d quit (Ping timeout: 252 seconds)
11:58:57*sz0 joined #nim
12:23:48*Vladar joined #nim
12:45:09shashlickThanks for checking it out survivorm, @zarsbranchkin
12:45:35shashlickI still need to handle tabs, will look into it
12:46:05shashlickAraq: I'll add it to GitHub later today
12:46:14PMunchI would like to check it out. But the link appears to be broken :(
12:46:19PMunchOh okay, nice
12:46:45shashlickRight now I'm calling it qnim but I'm open to better names 🙂
12:47:21*marenz_ joined #nim
12:47:22*leorize joined #nim
12:48:25*euphoricemu joined #nim
12:48:51FromGitter<ZarsBranchkin> Also, I wonder what could be done about the qnim being compiled in source directory, thus clashing with the `qnim` directory
12:49:02PMunch--out
12:49:04FromGitter<ZarsBranchkin> On windows, I guess, it wasn't a problem because of the `.exe`
12:49:26FromGitter<ZarsBranchkin> Yeah, I guess that. Maybe should output it to the directory with the makefile or create `bin`
12:49:28PMunchJust have a nim.cfg file that specifies where the output should go :)
12:53:26shashlickWhat OS are you on?
12:55:36PMunchme or Zars?
12:56:24FromGitter<ZarsBranchkin> I'm on arch linux
12:58:06shashlickCause it builds fine with nimble build
12:59:25FromGitter<ZarsBranchkin> ah, alright
13:01:51*Yardanico joined #nim
13:04:15*Snircle joined #nim
13:05:31PMunchhmm, is there a way to chain procedures always changing the input?
13:05:40*samhain quit (Ping timeout: 240 seconds)
13:06:32PMunchI tried "proc (old: var something): something = old.field = "Hello"; return old" but it complains that the input isn't a variable when I chain it with a constructor..
13:14:47*endragor quit (Remote host closed the connection)
13:16:36FromGitter<ZarsBranchkin> PMunch: hah, found the way. You must specify return type as var too
13:16:42FromGitter<ZarsBranchkin> Hadn't seen that before, but makes sense
13:17:40FromGitter<ZarsBranchkin> I guess usually you'd be passing around some object reference, so that's why you don't see var return types for chainable procedures
13:18:02PMunchOh huh, interesting
13:20:20*Ven`` joined #nim
13:21:55FromGitter<ZarsBranchkin> Alright yeah, passing by reference also allows modifying the object
13:23:06PMunchObviously
13:23:55PMunchI think that's what Nim does behind the scenes when you use var
13:24:08PMunchIt passes a reference to where the object is stored
13:24:55FromGitter<ZarsBranchkin> Didn't it pass variables as reference either way, just Nim compiler enforces the `var` for when you want to modify the argument
13:25:02PMunchWell that's what it does without var as well for more complex types. The compiler just checks that you don't modify it
13:25:15FromGitter<ZarsBranchkin> Yeah, thought so
13:25:34PMunchAnything else would be pretty punishing for performance :P
13:25:45PMunchBut if you pass an int it copies it without var
13:25:47PMunchIIRC
13:33:55FromGitter<survivorm> @PMunch - are you still interested in translating article on parsers? Cause it's already 10 pages on google doc by now (including some code, but not much) and is going to grow at least 3 or 5 pages more
13:34:17FromGitter<survivorm> First parts may be considered stable already :)
13:34:52FromGitter<survivorm> So i may pass it throu google translator for the later manual fixup
13:35:17PMunchWell I won't be able to translate as I don't speak Russian :P But if you want to write an English (or Norwegian :P) version I'll be happy to help you writing a "better" version
13:35:33PMunchOh yeah, I guess I could take the Google translate version and just rewrite that
13:35:43PMunchHmm, that might be interesting to try actually
13:36:26FromGitter<survivorm> If something comes unclear, you may ask at any time, of cource
13:36:49*gokr joined #nim
13:38:21FromGitter<survivorm> The point is - writing the article, i've boosted my knowlege on pasers immensely, including practical
13:38:32FromGitter<survivorm> That may be of help for You too
13:39:34PMunchOh yeah, definitely
13:39:52PMunchI'm slowly working through the parser combinator thing
13:39:59PMunchTrying to add error handling now
13:40:30FromGitter<survivorm> And i've found just great tool, very verbose too
13:40:41FromGitter<survivorm> Too bad it's python
13:41:16FromGitter<survivorm> Though it has a cli for grammar checking and even FA visualisation
13:43:54PMunchOoh, what's it called?
13:44:28FromGitter<survivorm> just look at its debug output https://gist.github.com/survivorm/a37b4048ebd9d1b02673036ca8097034
13:44:46PMunchBy the way I'm thinking of making the parser combinator thing more generic, so it can work on Nim AST as well as strings
13:44:49FromGitter<survivorm> https://github.com/igordejanovic/parglare
13:45:19FromGitter<survivorm> That's interesting idea
13:45:34*arecaceae quit (Remote host closed the connection)
13:45:41FromGitter<survivorm> Though i'm not quite sure i like it
13:45:53*arecaceae joined #nim
13:46:26FromGitter<survivorm> Something bothers me about it
13:46:53PMunchThat just seems a bit too verbose :P
13:47:38FromGitter<survivorm> As for the grammar, i think really BNF has no restrictions on the terminal symbols TYPE. Though real parsers do, of cource
13:47:48PMunchI'm working off-of this thing: http://kschiess.github.io/parslet/
13:47:48FromGitter<survivorm> that's debug mode
13:48:31FromGitter<survivorm> but at least it gives you full idea of just what's happening
13:49:31PMunchYeah I guess
13:49:44PMunchI have a bunch of echo statements littered around my code for debugging :P
13:50:39PMunchCould add in a compile-time switch that actually prints them out
13:50:58PMunchBut it wouldn't be as pretty as that with the full structure thing
13:51:00FromGitter<survivorm> Do they accidentaly are bound to the "debug level" var?
13:51:04FromGitter<survivorm> :)
13:51:16PMunchHuh?
13:51:39FromGitter<survivorm> like parse(debug=True)?
13:54:47*leorize quit (Quit: WeeChat 2.0.1)
13:55:27PMunchYeah either that or -d:debugParsing
13:55:49PMunchThe way it's implemented now is that every step returns a parser proc
13:56:08PMunchSo you don't have to call a .parse function
13:56:23PMunchAnd making the value propogate through all the inner procs would just be annoying
13:56:37FromGitter<survivorm> don't really get it
13:56:43FromGitter<survivorm> recursive?
13:56:50PMunchI'm a little curious to see how this thing fares with longer things though. Hopefully it won't have trouble with blowing the stack..
13:56:54PMunchYeah
13:57:02*Jesin quit (Quit: Leaving)
13:57:03PMunchhttps://github.com/PMunch/combparser/blob/master/combparser.nim
13:57:03FromGitter<survivorm> Too bad
13:57:17PMunchThe Parser[T] type is proc(input: string): Maybe[(T, string)]
13:57:22FromGitter<survivorm> even GLR is O(n^3)
13:57:24PMunchWell it's pretty neat actually
13:57:53FromGitter<survivorm> I shudder to imagine, how's this
13:58:32FromGitter<survivorm> But, recursive decent is the most wide, on the other hand
13:59:03FromGitter<survivorm> but, most LL and LR-variants are O(n) :P
14:02:05FromGitter<survivorm> Worst-case for recursive descent is O(exp(n))
14:02:33FromGitter<survivorm> Though it's rare in practice
14:04:11*yglukhov quit (Remote host closed the connection)
14:06:33*yglukhov joined #nim
14:07:14*sz0 quit (Quit: Connection closed for inactivity)
14:10:25yglukhovAraq: hi. do i understand correctly that ndi files need to opened all the time until the last module is written because a module codegen can trigger write to ndi of a different module?
14:13:59PMunchsurvivorm, yeah it will be interesting to see
14:14:28FromGitter<survivorm> @PMunch what?
14:14:38FromGitter<survivorm> real speed?
14:14:41*gokr quit (Quit: Leaving.)
14:14:41PMunchYeah
14:14:55PMunchAnd if it can even handle larger inputs without blowing the stack..
14:15:14PMunchWe should have tail-end recursion in Nim, that would help at least a little bit :P
14:15:17FromGitter<survivorm> Yeah, that's a thing
14:15:53FromGitter<survivorm> What's why most classic parsers use only FSA
14:15:59FromGitter<survivorm> not the recursion
14:17:12FromGitter<survivorm> it will be too bad if your nim implementation will be slower than python's lr in task of handling big json, for example :)
14:17:34FromGitter<survivorm> And funny too
14:18:45PMunchWell it might..
14:19:05PMunchCurrently I'm just focusing on flexibility and ease of use
14:19:10PMunchThen I'll look into speed later
14:19:38PMunchBad way of doing it, I know, but I wanted to see how "good" I could make it before I decided to try and optimize anything
14:19:52PMunchTrying to not add too much cruft though
14:21:03FromGitter<survivorm> I remember, once one of my collegues had a bet with another one too about his C's version of some math's algorithm implementation(that was Fourier transform, if i remember correctly) being faster than matlab's version (because C is faster!)
14:21:31FromGitter<survivorm> The result was matlab's version was 5 times faster...
14:25:34*dddddd quit (Remote host closed the connection)
14:29:55*Arrrr quit (Read error: Connection reset by peer)
14:30:09PMunchYeah, Matlab has some serious optimization work built in
14:30:41PMunchPlus, the Matlab fourier transform call is probably a native call anyways
14:39:41*Ven`` quit (Ping timeout: 268 seconds)
14:39:50*Ven`` joined #nim
14:40:49FromGitter<survivorm> yeah, think so too
14:59:53*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:07:25*gokr joined #nim
15:09:37*dddddd joined #nim
15:10:45Araqyglukhov: sorry, I'm not sure. maybe. can't remember how these work
15:11:02yglukhovok thanks
15:15:48Araqwhy do you ask?
15:23:32FromGitter<krux02> Araq: how much work do you think would it be to have both stderr and stdout at compile time?
15:24:11Araqstderr and stdout are quite easy
15:24:20Araqharder are all the IO procs that come with these
15:26:01FromGitter<krux02> well at least the ones that are implemented in nim would work
15:26:05FromGitter<krux02> I think
15:26:13FromGitter<krux02> for example styledEcho
15:27:14yglukhovAraq: got a bug. --debugger:native causes nim to error with "cannot open file: somefile.nim". because fd number exceeds macos default 256.
15:27:35yglukhovthe reason is ndi files are opened and not closed.
15:27:43Araqah yeah
15:28:00*PMunch_ joined #nim
15:28:04Araqthat one can be fixed more elegantly when we parse the full module to an AST before processing it
15:28:38*PMunch quit (Disconnected by services)
15:28:42*PMunch_ is now known as PMunch
15:29:16yglukhovAraq: or. collect ndi content into a temp string instead of writing it to the file all the time.
15:29:31yglukhovwill eat more ram though (
15:30:42Araqkrux02: FILE* can be mapped to integer literals in the VM
15:30:50Araqthat's what I did for the FFI support before
15:30:57FromGitter<ZarsBranchkin> @krux02 Been exploring the `nim-mode`, getting closer to figuring out what the hell is going on with completion. Just found out that their caching doesn't work at all, each new character calls nimsuggest process
15:31:01yglukhovAraq: but not that much. ndis are 5mb total for my somewhat significant codebase
15:31:46FromGitter<ZarsBranchkin> Also, their completion at point seems to ignore some company predicate functions, because it will try to complete things while post-processing acquired suggestions
15:31:55*miran_ joined #nim
15:32:31*Ven`` joined #nim
15:32:46yglukhovAraq: actually the fact that ndi contain different nim files makes me believe that my assumption was wrong. about "module codegen can trigger write to ndi of a different module"
15:33:09FromGitter<ZarsBranchkin> I mean, I already didn't quite like the "force completion no matter the configuration, if previous character is a dot" override they have
15:40:30*derlafff quit (Remote host closed the connection)
15:41:20*derlafff joined #nim
15:42:17FromGitter<krux02> @ZarsBranchkin It is good to know that you can actually get what is going on. I could not understand that codebase.
15:43:10FromGitter<krux02> To be honest nim-mode feels like it has too much code. Something in there is structurally wrong to need so much lisp code.
15:43:47*derlafff quit (Remote host closed the connection)
15:44:22FromGitter<ZarsBranchkin> Yeah, it took some time debugging the functions and exploring the backtrace of the calls
15:44:36*derlafff joined #nim
15:45:16FromGitter<ZarsBranchkin> I think I'll fix the ugly forced completion hack and see if that helps. But still need to explore the code more
15:46:49FromGitter<ZarsBranchkin> Problem is that company is already complex mode, so i'm not exactly sure how the completion backend should behave. So i'm pretty much learning company by exploring
15:47:25FromGitter<krux02> ok, sounds like a good plan. I have no idea how it works
15:47:40FromGitter<krux02> All I did was to improve the nim-compile mode.
15:47:59FromGitter<krux02> I added a regular expression to parse the nim compilation errors.
15:52:32FromGitter<ZarsBranchkin> Look at this, just completely bypassing the company mode completion predicate logic https://i.imgur.com/m27soVP.png
15:53:28FromGitter<ZarsBranchkin> Not everyone wants completion to begin at the dot, that's why there is the variable to control the minimum prefix length, before completion should kick in. THis completely disregards that
15:58:23FromGitter<krux02> to be honest I don't understand that code
16:00:07FromGitter<krux02> I am not an emacs lisp programmer I understand a few basics but these characters still confuse me ,#`:
16:00:55*PMunch quit (Ping timeout: 260 seconds)
16:01:37FromGitter<ZarsBranchkin> oh, right. `,` before a list makes it semi-literal, where if it detects the grave symbol, it will evaluate the expression. And as for `#`, i think it tells elisp that the function should get byte code compiled
16:03:24FromGitter<ZarsBranchkin> never mind, it's other way around, grave marks list as semi-literal, `,` evaluates expression within it
16:04:00FromGitter<ZarsBranchkin> ```("abc" "def" "abcdef" "123")``` [https://gitter.im/nim-lang/Nim?at=5a69fff00ad3e04b1b699ba4]
16:10:01FromGitter<krux02> ah, ok makes sense
16:10:37FromGitter<krux02> I read about it, but I never use it, and then I forgot what it does.
16:10:59*BitPuffin joined #nim
16:12:42*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
16:12:48*gokr quit (Ping timeout: 240 seconds)
16:20:23*xkapastel joined #nim
16:28:45*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:28:56FromGitter<krux02> @ZarsBranchkin I made some hack in nim-mode, so that files that are included somewhere else work
16:29:28FromGitter<krux02> nimsuggest needs a root of the project to work on files that are included.
16:29:47FromGitter<krux02> otherwise there will be a lot of errors in that file
16:29:58FromGitter<ZarsBranchkin> Right, and you have some files that are outside of the project root?
16:30:47FromGitter<krux02> well not outside of the project root. But emacs does not really work on projects and project roots
16:30:56FromGitter<krux02> it just opens files
16:31:35FromGitter<krux02> and those files are always opened in that directory. It is not like other editors where your working directory is where you open up the editor, in emacs the working directory is always the file itself
16:32:05FromGitter<ZarsBranchkin> oh alright, I haven't really worked with big enough Nim projects yet to notice it
16:32:11FromGitter<krux02> then projectile allows to detect if a file is in a "project" which is nothing more than a git repository and allows to navigate faster in that
16:32:48FromGitter<krux02> all I did is to modify nim-mode marginally to look for a file in the source tree that tells what the root of the project is
16:33:29*vivus joined #nim
16:34:03FromGitter<krux02> https://github.com/krux02/nim-mode/commit/771ed20fc4fc9393a7a11c59df2b1455fe5e4f5e
16:34:46*kier quit (Quit: No Ping reply in 180 seconds.)
16:35:26FromGitter<krux02> and then in the init hook I do this: ⏎ ⏎ `````` [https://gitter.im/nim-lang/Nim?at=5a6a074ed9f895c3605de66a]
16:37:43FromGitter<krux02> nimsuggest-project-file is a file in the root of my project that has only one line. The filename of the root of the project
16:38:35FromGitter<ZarsBranchkin> Right, makes sense
16:40:09*kier joined #nim
16:41:30FromGitter<krux02> could not convince anybody
16:41:44FromGitter<krux02> I think nim should know on it's own what the root of the project is
16:42:01AraqI think that's downright impossible.
16:42:30FromGitter<krux02> Well I think it is not impossible, it just requires a few constraints.
16:43:54FromGitter<ZarsBranchkin> Well there won't be a general case, but you can mark directory like you did it, find the nimble file or detect git directory
16:44:21FromGitter<ZarsBranchkin> ah but you need the Nim file not directory for nimsuggest, right
16:44:40FromGitter<krux02> yes
16:44:53FromGitter<krux02> I think in a few cases a directory works, too. But I don't know
16:45:39FromGitter<ZarsBranchkin> Maybe could add nimsuggest feature to accept root directory for where to look for dependant modules
16:46:08FromGitter<krux02> Araq: All you need is a convention that generally allows to deduce the root of a nim file
16:47:36FromGitter<krux02> Then make this convention a constraint, and you do a favor for all editor integrations
16:51:35*marenz_ quit (Ping timeout: 240 seconds)
16:51:48Araqor
16:51:56FromGitter<krux02> I once had the idea to tag an included file in the first like with some kind of comment `# included from "../someroot.nim"
16:52:17Araqyou pass a directory to nimsuggest and it makes an educated guess about the main file.
16:52:52FromGitter<krux02> I don't like thet directory parameter
16:52:53Araqas I told you multiple times now.
16:52:58FromGitter<krux02> because it is not reliable
16:53:13FromGitter<krux02> yea I know, and I am hard headed
16:53:48FromGitter<krux02> Araq: does it work on the Nim project?
16:54:14*miran_ quit (Remote host closed the connection)
16:54:25FromGitter<krux02> I mean does nimsuggest work on the Nim programming language when I just tell it the root of that?
16:54:47Araqwhat do you mean? it works when you pass it $nim/compiler
16:58:09FromGitter<krux02> well that is too bad, because it means that no editor will be able to work on the Nim without that knowledge
16:58:33*c0ntribut0r quit (Ping timeout: 264 seconds)
16:58:59*c0ntribut0r joined #nim
16:59:03Araq?
16:59:23Araqcompiler/ast.nim # chop off the filename and there you go, pass the rest to nimsuggest
16:59:39FromGitter<krux02> get emacs with nim-mode and then open up a file in nim-lang and you will get a lot of false positives
17:00:22AraqI'm not responsible for misprogrammed nimsuggest editor support.
17:00:41AraqI'm only responsible for nimsuggest (and that's a bitch already)
17:00:55FromGitter<krux02> yea you can't do everything
17:00:58*miran_ joined #nim
17:02:25FromGitter<krux02> all I did, was to create a file called "nimsuggest-project-file"
17:03:24FromGitter<krux02> create that file in nim-lang/compiler with no content and (use my fork of nim-mode) and nimsuggest will be started with the correct parameter
17:04:01FromGitter<krux02> but when I can deduce the project file automatically, because I've put it in the filesysetm, wher is the problem for nimsuggest to do the exact same thing?
17:04:16FromGitter<krux02> Put the knowledge of the root of the project in the filesystem.
17:04:54Araqor: you create a project.nims/project.nim.cfg file
17:05:08Araqto make project.nim the project file. as it's widely known.
17:05:59*nsf quit (Quit: WeeChat 2.0.1)
17:06:30miran_https://play.nim-lang.org/ doesn't work?
17:06:48FromGitter<krux02> then why doesn't nimsuggest look for for the project.nim.cfg on it's own?
17:06:50FromGitter<krux02> or does it?
17:07:21Araqit does when you pass a directory to it
17:07:37Araqmaybe it doesn't go "up" yet in the file hiearchy, don't remember.
17:07:45Araqbut that would be simple to add.
17:07:56FromGitter<ZarsBranchkin> oh, didn't know you can pass directory to nimsuggest
17:10:11miran_from nim tutorial: "Different tuple-types are equivalent if they specify fields of the same type **and of the same name** in the same order."
17:10:13*c0ntribut0r quit (Read error: Connection reset by peer)
17:10:17miran_https://gist.github.com/anonymous/51dcb4c890f2acfd8275480614ab9b35
17:10:43miran_without you trying it, based on the written - is this relation true or false?
17:10:44*floppydh quit (Quit: WeeChat 2.0.1)
17:10:45*c0ntribut0r joined #nim
17:10:45*fvs joined #nim
17:11:17dom96miran_: sadly the maintainer isn't around :\
17:12:53*c0ntribut0r quit (Read error: Connection reset by peer)
17:13:04FromGitter<andreaferretti> I would say yes
17:13:29FromGitter<andreaferretti> It should be the whole point of tuples vs objects
17:13:37*c0ntribut0r joined #nim
17:14:23dom96same ^
17:14:53miran_dom96, andreaferetti: but the fields are not the same!?
17:15:22dom96that doesn't matter
17:15:50dom96The tutorial seems invalid
17:16:15miran_dom96: it does, but not if one of the tuples has defauld field names
17:16:56miran_if we make `p = (names: "Banana", weights: 2, ratings: 'c')`, we can compare `n` and `p`, but not `o` and `p` - it throws an error
17:20:01miran_it seems like default field names have some special treatment. if they have a correct number of fields, they can be anything they want.... :)
17:20:10*gokr joined #nim
17:20:32dom96hey gokr, did you see my issue on GitHub?
17:20:44gokrMmmm
17:21:05dom96tempted to give my suggestion a try? :)
17:21:06*yglukhov quit (Remote host closed the connection)
17:23:43*yglukhov joined #nim
17:25:12gokronesec
17:26:14gokr"Use the library's synchronous API in a Nim thread. This will ensure that all threads are handled by nim and thus there should be no trouble."
17:26:23gokrThat's basically what I did you know.
17:27:12*user0 is now known as Guest20619
17:27:22gokrI created a Nim thread with a channel to it - letting that thread interleave calling receive (timeout 20 ms) and checking for a send request on the Nim channel.
17:27:50gokrBut that still means I had to use threads:on - and that still makes nim-httpauth go bonkers.
17:28:04dom96yes, but that fixed the crashes
17:28:06dom96right?
17:28:10*yglukhov quit (Ping timeout: 240 seconds)
17:28:30dom96fixing nim-httpauth to work with --threads:on should be relatively trivial
17:28:53gokryes, sure. In fact... I already have another project using that style.
17:29:26gokrhttps://github.com/evothings/ecraft2learn/tree/master/arduinobot
17:30:45gokrNow... for Canoe I already did the 2-hour port to nodejs and have already progressed further than I did in Nim. So that train has gone.
17:31:42gokrThing is - in Nodejs I "only" need to do battle on the js front - not down in C level, memory messing, can't-understand-what-to-do stuff.
17:31:57FromGitter<krux02> @ZarsBranchkin I think it would make sense to have an interactive lisp function to change the root of a project when you have a buffer open
17:31:59dom96federico3: any chance you could fix nim-httpauth to make it gc safe? btw why is 'httpauth' installed as a binary?
17:32:26dom96gokr: Understandable :\
17:32:43gokrdom96: So short answer - the Canoe train left. But I still think MQTT is increasingly important to Nim.
17:34:59federico3dom96: I was going to do that
17:46:26*sz0 joined #nim
17:52:50*gokr quit (Ping timeout: 252 seconds)
17:55:48*xet7 quit (Ping timeout: 240 seconds)
17:58:45*devdri joined #nim
18:03:16*yglukhov joined #nim
18:08:05*yglukhov quit (Ping timeout: 260 seconds)
18:09:08*xet7 joined #nim
18:26:22*PMunch joined #nim
18:43:54*j_rods_s quit (Quit: j_rods_s)
18:46:35*kier quit (Ping timeout: 240 seconds)
18:47:15*j_rod_s joined #nim
19:01:23*kier joined #nim
19:03:30*Senketsu quit (Remote host closed the connection)
19:04:39*kier quit (Client Quit)
19:06:26*fvs left #nim ("ERC (IRC client for Emacs 25.3.1)")
19:10:03*kier joined #nim
19:12:01*Senketsu joined #nim
19:22:58FromGitter<Bennyelg> Nim in path via ~/.zshrc, ⏎ VS code yield ⏎ ```No 'nim' binary could be found in PATH environment variable``` ⏎ Nim installed from git (devel) [https://gitter.im/nim-lang/Nim?at=5a6a2e92c95f22546de548f6]
19:25:38*Yardanico quit (Remote host closed the connection)
19:28:53*yglukhov joined #nim
19:32:12*gangstacat quit (*.net *.split)
19:32:15FromGitter<ZarsBranchkin> @Bennyelg Try append to path variable inside `.profile` instead of `.zshrc`, VS code definitely doesn't use zsh
19:32:37*gangstacat joined #nim
19:32:50*miran_ quit (Quit: Konversation terminated!)
19:32:54*yglukhov quit (Read error: Connection reset by peer)
19:33:29*yglukhov joined #nim
19:35:24FromGitter<Bennyelg> i tried .profile , .bashrc
19:35:27FromGitter<Bennyelg> nothing helps :|
19:36:05*BitPuffin quit (Remote host closed the connection)
19:37:12*arecaceae quit (Quit: WeeChat 2.0.1)
19:40:52FromGitter<ZarsBranchkin> Hm, VS code doesn't have any settings for that?
19:41:24FromGitter<Bennyelg> I fixed the problem.
19:42:00FromGitter<Bennyelg> Apparently VSCode check in the /usr/local/bin directory
19:42:09FromGitter<Bennyelg> so I add a link
19:42:12FromGitter<Bennyelg> soft one
19:43:08FromGitter<ZarsBranchkin> Heh, well that's one way to solve that. I usually throw my custom applications in there too
19:48:25FromGitter<Bennyelg> Ic :P
19:49:35*Trustable joined #nim
19:56:22*marenz_ joined #nim
20:00:06*sz0 quit (Quit: Connection closed for inactivity)
20:01:35*xet7 quit (Ping timeout: 240 seconds)
20:06:16*kier quit (Quit: This cannot continue.)
20:06:43*kier joined #nim
20:07:44*xkapastel quit (Quit: Connection closed for inactivity)
20:10:30*xkapastel joined #nim
20:16:44*xet7 joined #nim
20:19:45FromGitter<krux02> @ZarsBranchkin the shell is a setting of the user, not the program
20:20:36FromGitter<krux02> that is also kind of a problem, because when a program wants to run a shell command it can't rely on the fact that it is bash or something
20:20:55FromGitter<krux02> @Bennyelg did you re login after setting PATH in .profile
20:21:04FromGitter<Bennyelg> yea
20:21:05FromGitter<krux02> dot provile is evaluated at login (afaik)
20:22:11FromGitter<krux02> maybe you can inspect the PATH variable of the VSCode process somehow
20:22:20FromGitter<krux02> because it claims to actually look in PATH
20:22:54FromGitter<krux02> the environment variables in unix are actually per process and when you create a new process it is a fork with the same environment variables
20:23:18FromGitter<krux02> that is why when you set path in a shell it is only set in that shell but not in other shells
20:24:06FromGitter<krux02> `cat /proc/<pid>/environ`
20:24:24FromGitter<krux02> and <pid> you get with `pgrep vscode`
20:24:47FromGitter<krux02> cat /proc/<pid>/environ | grep PATH
20:25:02FromGitter<krux02> @Bennyelg can you do that?
20:25:31*matic joined #nim
20:25:40FromGitter<Bennyelg> yep sec
20:26:10shashlickis it possible to get a sequence of all enum
20:26:33FromGitter<Bennyelg> @krux02 I dont get anything from pgrep vscode.
20:26:44shashlickor to loop over every enum entry
20:26:54FromGitter<krux02> I don't know the name of the vscode process
20:27:41FromGitter<krux02> maybe it is a browser so it might have that name :/
20:27:56FromGitter<Bennyelg> sec
20:28:05shashlickitems() works
20:28:21FromGitter<krux02> and I don't have vscode on this computer so I can't figure it out
20:28:50FromGitter<Bennyelg> i fetched it using ps -ef | grep vscode
20:28:57*yglukhov quit (Remote host closed the connection)
20:30:26FromGitter<krux02> ok
20:30:45FromGitter<Bennyelg> ```➜ projects cat /proc/7606/environ ⏎ cat: /proc/7606/environ: No such file or directory ⏎ ``` [https://gitter.im/nim-lang/Nim?at=5a6a3e75c95f22546de5ac2e]
20:31:53GitDisc<awr> which standard of C does the nim compiler target? C99?
20:32:53FromGitter<krux02> that is weird
20:33:09FromGitter<Bennyelg> Im osx
20:33:14FromGitter<Bennyelg> not linux
20:45:43*yglukhov joined #nim
20:45:58dom96The 2018 Stack Overflow Developer Survey is here. You know what to do (mention Nim as often as possible :P) https://stackoverflow.com/dev-survey/start/
20:51:13*matic quit (Quit: Leaving)
20:51:31*nsf joined #nim
20:53:39*rauss quit (Read error: Connection reset by peer)
20:54:09*skelett quit (Ping timeout: 265 seconds)
20:54:20*rauss joined #nim
21:01:37FromGitter<Bennyelg> how can I flush stdin using nim?
21:01:43FromGitter<Bennyelg> like clear the screen
21:02:05dom96terminal.eraseScreen?
21:02:19FromGitter<Bennyelg> I'll try
21:02:21FromGitter<Bennyelg> thanks
21:02:22dom96I guess you want to clear the stdin though
21:02:33dom96read it and then discard it?
21:02:55FromGitter<Bennyelg> I am writing some terminal console and I want in some cases clear the menu screen to show another
21:04:31FromGitter<Bennyelg> from where i get terminal.eraseScreen
21:11:26*scriptum quit (Remote host closed the connection)
21:12:42FromGitter<ZarsBranchkin> Probably meant clearing stdout then
21:12:51FromGitter<Bennyelg> yea
21:19:15FromGitter<Bennyelg> I'll clerafiy how I make python stdout.flush on nim
21:20:07PMunchstdout.flushFile?
21:20:51FromGitter<Bennyelg> Thanks.
21:28:33*yglukhov quit (Remote host closed the connection)
21:30:19FromGitter<krux02> I think it should be renamed to flush. the "File" suffix is so redundant.
21:37:05*obadz joined #nim
21:37:36*yglukhov joined #nim
21:51:26*nsf quit (Quit: WeeChat 2.0.1)
21:56:28*gokr joined #nim
21:59:17*c0ntribut0r quit (Ping timeout: 256 seconds)
22:00:20*euphoricemu quit (Read error: Connection reset by peer)
22:14:10*Vladar quit (Quit: Leaving)
22:22:27*PMunch quit (Quit: leaving)
22:25:34*tankfeeder_ joined #nim
22:26:07*tankfeeder_ left #nim (#nim)
22:35:53*Snircle joined #nim
22:48:05*solitudesf quit (Ping timeout: 240 seconds)
22:56:24*vlad1777d joined #nim
22:58:03*marenz__ joined #nim
22:58:57*marenz_ quit (Ping timeout: 240 seconds)
23:17:22*MJCaley joined #nim
23:21:26*Trustable quit (Remote host closed the connection)
23:50:50*yglukhov quit (Remote host closed the connection)
23:53:17*MJCaley quit (Quit: MJCaley)