<< 24-02-2018 >>
00:01:04*jackprob quit (Remote host closed the connection)
00:15:28GitDisc<spaceghost> I'm going to be working with nim and libretro in just a bit, I have some ideas I'm excited to be able to do more easily with nim.
00:17:06*SenasOzys quit (Read error: Connection reset by peer)
00:18:07*SenasOzys joined #nim
01:13:29*xkapastel joined #nim
01:24:44*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
01:25:33*arthurz quit (Ping timeout: 263 seconds)
01:26:29*arthurz joined #nim
01:43:59*vivus quit (Quit: Leaving)
01:48:01*zolk3ri quit (Remote host closed the connection)
02:03:44*el_tejon quit (Quit: el_tejon)
02:06:05*tongir quit (Ping timeout: 240 seconds)
02:27:14*francisl joined #nim
02:32:09*francisl quit (Ping timeout: 264 seconds)
02:43:11*tongir joined #nim
03:02:58*endragor joined #nim
03:03:23*francisl joined #nim
03:07:32*francisl quit (Ping timeout: 240 seconds)
03:25:44*zarthur joined #nim
03:27:35*arnetheduck quit (Remote host closed the connection)
03:30:44*arnetheduck joined #nim
03:34:17*francisl joined #nim
03:38:41*francisl quit (Ping timeout: 252 seconds)
04:22:11FromGitter<sclee15> Hello. does anybody know how to convert cstring to string for js targets?
04:33:48*francisl joined #nim
04:34:49*endragor quit (Remote host closed the connection)
04:37:57*francisl quit (Ping timeout: 240 seconds)
04:41:32zarthur Hi @sclee15, did not try, but wouldn't this work: `var mystr: string = $mycstring` ?
04:51:47FromGitter<sclee15> @zarthur it works. thank you.
04:52:19zarthurYW @sclee15
04:58:57*endragor joined #nim
04:59:05*endragor quit (Remote host closed the connection)
05:00:31*zarthur quit (Quit: Leaving)
05:09:38*SenasOzys quit (Remote host closed the connection)
05:18:24*dddddd quit (Remote host closed the connection)
05:32:01*francisl joined #nim
05:36:57*francisl quit (Ping timeout: 264 seconds)
05:54:41*r3d9u11 joined #nim
05:58:48*BitPuffin joined #nim
06:14:05*j_rod_s quit (Ping timeout: 255 seconds)
06:28:44*nsf joined #nim
06:40:43*j_rod_s joined #nim
06:57:48*miran joined #nim
07:31:23*solitudesf joined #nim
07:44:44*solitudesf quit (Quit: solitudesf)
07:47:36*solitudesf joined #nim
08:02:23*SenasOzys joined #nim
08:08:18*rokups joined #nim
08:10:56*xkapastel quit (Quit: Connection closed for inactivity)
08:11:02*Trustable joined #nim
08:11:09*r3d9u11 quit (Remote host closed the connection)
08:12:31*nsf quit (Quit: WeeChat 2.0.1)
08:36:26*j_rod_s quit (Ping timeout: 268 seconds)
08:38:47*r3d9u11 joined #nim
08:39:15*j_rod_s joined #nim
08:51:25*Vladar joined #nim
09:30:33*yglukhov joined #nim
09:38:01*yglukhov quit (Remote host closed the connection)
09:40:32*SenasOzys quit (Remote host closed the connection)
09:40:51*SenasOzys joined #nim
09:52:27*SenasOzys quit (Ping timeout: 240 seconds)
10:00:15*r3d9u11 quit (Remote host closed the connection)
10:05:33*el_tejon joined #nim
10:13:30*SenasOzys joined #nim
10:18:26*smt joined #nim
10:24:30FromGitter<alehander42> can I somehow test that a typedesc argument matches a concept ?
10:24:49FromGitter<alehander42> e.g.` proc mapInternal*U (a: typedesc, handler: proc(element: a): U): seq[U] =`
10:25:12FromGitter<alehander42> signify that `a` is always `EnumLike` (actually `enum`, but not sure how else to express it)
10:25:38FromGitter<alehander42> ha, typedesc[enum] might work
11:14:23*el_tejon quit (Quit: el_tejon)
11:19:57*couven92 quit (Ping timeout: 240 seconds)
11:26:01*r3d9u11 joined #nim
11:28:52FromGitter<mratsim> yes typedesc[enum] works
12:03:02*Snircle joined #nim
12:15:35*SenasOzys quit (Ping timeout: 240 seconds)
12:23:29*miran quit (Ping timeout: 248 seconds)
12:23:48*SenasOzys joined #nim
12:37:42*r3d9u11 quit (Remote host closed the connection)
13:02:41*endragor joined #nim
13:02:44*Snircle quit (Ping timeout: 276 seconds)
13:03:52*Snircle joined #nim
13:06:52*endragor quit (Ping timeout: 240 seconds)
13:17:20*yglukhov joined #nim
13:24:01*rokups quit (Quit: Connection closed for inactivity)
13:29:06*francisl joined #nim
13:30:06*couven92 joined #nim
13:31:45*rokups joined #nim
13:33:57*francisl quit (Ping timeout: 264 seconds)
13:34:53*arecacea1 quit (Remote host closed the connection)
13:35:17*arecacea1 joined #nim
13:44:53*ipjk joined #nim
13:45:50ipjkdom96: Any plans for something like, https://code.dlang.org/?
13:46:15dom96https://nimble.directory
13:47:33Yardanico@dom96, one thing I don't like about nimble.directory - you can't just browse packages list :)
13:47:48Yardanicootherwise it's great
13:48:16ipjkTags would be nice, too.
13:48:24dom96Tags are there
13:48:58dom96It's a start in any case, PRs very much welcome :)
13:50:55ipjkAlso, should be linked from the hompage.
13:51:09*dddddd joined #nim
13:56:00*smt` joined #nim
13:58:45*jonafato- joined #nim
13:59:00*jonafato quit (Ping timeout: 264 seconds)
13:59:09*smt quit (Ping timeout: 264 seconds)
14:03:22*mal``` joined #nim
14:03:49*solitudesf_ joined #nim
14:07:40*vlad1777d_ joined #nim
14:08:17*smt` is now known as smt
14:08:49*shodan45_ joined #nim
14:09:59*Yardanico_ quit (Ping timeout: 264 seconds)
14:09:59*mal`` quit (Ping timeout: 264 seconds)
14:10:00*solitudesf quit (Ping timeout: 264 seconds)
14:10:00*joshbaptiste quit (Ping timeout: 264 seconds)
14:10:01*BitPuffin quit (Ping timeout: 264 seconds)
14:10:01*tongir quit (Ping timeout: 264 seconds)
14:10:01*vlad1777d quit (Ping timeout: 264 seconds)
14:10:28*shodan45 quit (Ping timeout: 264 seconds)
14:11:15*joshbaptiste joined #nim
14:14:53*francisl joined #nim
14:16:20*tongir joined #nim
14:19:27*francisl quit (Ping timeout: 240 seconds)
14:28:18*endragor joined #nim
14:30:16*endragor quit (Remote host closed the connection)
14:43:22federico3Yardanico: browse? e.g. by category?
14:46:40Yardanicofederico3, well yeah
14:46:45Yardanicoor sort all packages by last update date
14:49:18federico3Yardanico: unfortunately there aren't categories on packages.json , only tags
14:49:27federico3but I'll add a browsable list
14:50:45Yardanicofederico3, thanks!
14:53:25*xkapastel joined #nim
15:02:37*j_rod_s quit (Ping timeout: 256 seconds)
15:02:37*kunev quit (Ping timeout: 265 seconds)
15:02:39*miran joined #nim
15:05:14*kunev joined #nim
15:18:10*j_rod_s joined #nim
15:21:57*couven92 quit (Ping timeout: 252 seconds)
15:24:13*Vladar quit (Quit: Leaving)
15:33:01*natrys joined #nim
15:51:26*ipjk quit (Read error: Connection reset by peer)
15:52:54*vlad1777d_ quit (Quit: Leaving)
15:54:27*vlad1777d joined #nim
16:03:05*nsf joined #nim
16:11:19*couven92 joined #nim
16:33:59*Trustable quit (Remote host closed the connection)
16:43:33*endragor joined #nim
16:49:35*natrys quit (Ping timeout: 240 seconds)
16:52:40*far4ia4650 left #nim ("WeeChat 2.0.1")
16:58:07*endragor quit (Remote host closed the connection)
16:58:42*endragor joined #nim
17:02:23*couven92 quit (Ping timeout: 248 seconds)
17:03:09*endragor quit (Ping timeout: 252 seconds)
17:08:13*tongir quit (Ping timeout: 240 seconds)
17:15:11*tongir joined #nim
17:19:09*far4ia4650 joined #nim
17:21:26*tongir quit (Ping timeout: 245 seconds)
17:23:19FromGitter<krux02> I would like to have something like this for Nim: https://gowalker.org/
17:25:22*natrys joined #nim
17:30:16*PMunch joined #nim
17:31:27federico3uhm, that could be arranged
17:33:33*tongir joined #nim
17:51:14*r3d9u11 joined #nim
18:07:36*nsf quit (Quit: WeeChat 2.0.1)
18:10:27*Sembei quit (Ping timeout: 240 seconds)
18:10:41*MyMind joined #nim
18:40:03*salewski joined #nim
18:41:09salewskidom96, why have you closed nimble bug 280 ?
18:42:07salewskiI just saw it and had the hope that now a plain "nimble install gintro" would work. But it does not :-(
18:42:53salewskihttps://github.com/StefanSalewski/gintro/blob/master/gintro.nimble
18:42:55dom96genotrance fixed it, no?
18:43:43salewskiis the new install script, gintro.nimble.bak2 the old one.
18:44:22*MJCaley joined #nim
18:44:26salewskibefore install: is still ignored, so it does not work. I will have to revert last push.
18:44:44salewskiSad.
18:44:45dom96You certain you got 0.8.10?
18:45:19salewskiInstalled 10 minutes ago -- new nim, new nimble.
18:45:37dom96Did you check `nimble -v`?
18:46:04salewskinimble v0.8.10 compiled at 2018-02-24 19:07:28
18:46:13dom96oh well, pity
18:46:17dom96please comment on the issue
18:46:27dom96I'll reopen soon
18:46:35salewskiYou may try yourself, it is available at github still.
18:46:55salewskinimble install gintro
18:47:04dom96I believe you :)
18:47:31salewskiYou will notice that install script called prep is not executed.
18:48:03salewskiAnd indeed, bug 280 was called hard by someone.
18:49:00salewskiI would guess that "before install" is special.
18:49:30salewskiBecause it is the first action to do.
18:50:30*MJCaley quit (Read error: Connection reset by peer)
18:50:35*xet7 quit (Quit: Leaving)
18:50:39salewskiOK, I will revert last push tomorrow for now. And we should reopen bug 280.
18:50:55*MJCaley joined #nim
18:51:57*MJCaley quit (Read error: Connection reset by peer)
18:52:55*MJCaley joined #nim
18:53:03dom96salewski: wait a minute
18:53:08dom96Your package has releases
18:53:18dom96You need to run `nimble install gintro@#head`
18:53:31salewskiOh.
18:53:44salewskiWill try.
18:54:04FromGitter<krux02> I think this `@#` is very confusing in nimble
18:54:54FromGitter<krux02> in zsh is isn't even possible without quoting
18:55:06salewskidom96, great! It installs.
18:55:08*xet7 joined #nim
18:55:33*SenasOzys quit (Ping timeout: 240 seconds)
18:56:14dom96krux02: what do you propose we change it to?
18:57:12dom96salewski: awesome :)
18:58:13*MJCaley quit (Read error: Connection reset by peer)
18:58:23Araqoh yeah, I agree, # is for comments, right?
18:58:37*MJCaley joined #nim
18:58:49Araqgintro-head, gintro-1.0
18:58:58Araqwould be my proposal
18:59:31dom96that doesn't distinguish between a commit hash and a version
18:59:41salewskiYes, successfully installed, and t0.nim example compiles and works fine!
19:00:42*MJCaley quit (Read error: Connection reset by peer)
19:00:56*zama quit (Ping timeout: 256 seconds)
19:01:38*MJCaley joined #nim
19:02:38*MJCaley quit (Read error: Connection reset by peer)
19:03:14*zama joined #nim
19:03:32*MJCaley joined #nim
19:04:15GitDisc<Lua> Heyo.
19:04:20*yglukhov quit (Remote host closed the connection)
19:04:25*rockcavera quit (Remote host closed the connection)
19:05:03GitDisc<treeform> Hi
19:05:43*SenasOzys joined #nim
19:06:15dom96hi Lua
19:06:35GitDisc<Lua> A friend of mine got me interested in Nim, it looks pretty good with the syntax..
19:07:25GitDisc<ZarsBranchkin> Yay, I'm evangelising Nim
19:07:46GitDisc<Lua> I'm gonna go read more of the documentation now.
19:08:36GitDisc<ZarsBranchkin> Read the tutorial, it's not too long and simple to understand. From there can start checking out some things in manual
19:09:09GitDisc<Lua> That's what I'm doing.
19:09:12GitDisc<Lua>
19:09:12GitDisc<Lua> https://cdn.discordapp.com/attachments/371759389889003532/417035251680935936/unknown.png
19:09:56FromGitter<zetashift> If you have any questions feel free to ask here or on the forum!
19:10:56*MJCaley quit (Read error: Connection reset by peer)
19:11:20GitDisc<Lua> What's the forum link?
19:11:28*MJCaley joined #nim
19:11:40GitDisc<Lua> Wait I'm an idiot.
19:11:41GitDisc<Lua> Lol
19:12:41*MJCaley quit (Read error: Connection reset by peer)
19:13:14*Lua joined #nim
19:13:42*MJCaley joined #nim
19:14:27*MJCaley quit (Client Quit)
19:14:37*Lua quit (Client Quit)
19:15:55*solitudesf_ quit (Quit: solitudesf_)
19:19:01salewskiSorry, I still do not really understand the gintro@#head problem. Have I to make a new release? Or are releases a bad idea at all?
19:19:29salewskiI think someone recommended to makes releases.
19:20:05dom96The idea is that you don't want users to be installing possibly broken code
19:20:20dom96so make releases whenever you're confident your code is ready to be used by your users
19:20:59salewskiOK, that makes sense, thanks. So I will test and make a new release when all is fine.
19:22:44*rockcavera joined #nim
19:22:53*solitudesf joined #nim
19:23:59FromGitter<tim-st> is there a tool planned to format source code in nim similar to nimsuggest?
19:24:49FromGitter<zetashift> yea nimpretty
19:25:24FromGitter<tim-st> good to know, thanks!
19:42:53salewskiBye.
19:42:57*salewski quit (Quit: WeeChat 1.9.1)
19:53:57*salewski joined #nim
19:55:02salewskiCurrently I do not install examples from https://github.com/StefanSalewski/gintro/tree/master/examples at all,
19:55:17salewskiso users have to do it their own.
19:56:07salewskiI guess it may be better to offer a nimble install. But which destination location may I use?
19:56:49salewskiFor linux /tmp may be OK, so users can do a short test after installation. And for other OS like windows?
19:58:54salewskiOr should we copy examples to ~/.nimble/pkgs/gintro/ ?
19:59:30salewskiBut that is a hidden directory, untrained users may not see that dir at all?
20:00:13FromGitter<tim-st> I just read that nullterminated strlen() has O(n) runtime, is this the same for nim?
20:00:37*nsf joined #nim
20:01:11salewskiI guess copying examples to /tmp is fine indeed, but would fail on windows.
20:02:07salewskitim, nim stores lenght for strings, so it is O(1) as it was in Turbo-Pascal :-)
20:02:21FromGitter<tim-st> thanks, I hoped this :)
20:03:17salewskiBut it does not really matter, looking for the 0 char is very very fast in C.
20:04:02FromGitter<krux02> strings in Nim are 0 terminated and have a length stored. That is kind of redundant, but it helps for compatibility. no copying required when a 0 terminated string is required.
20:05:45FromGitter<tim-st> ok, I read a wikipedia article talking about O(n). When nim can store additional fields for string, wouldnt it be good to store string start too, so some operation could be much faster?
20:05:46salewskiI may have read that Rust does not append the 0 char. And terminating 0 char and explizit length may be confusing sometimes.
20:06:31FromGitter<tim-st> *start index
20:07:19salewskitim, I do not really understand, start is generally first char.
20:07:28FromGitter<krux02> well yes, it can be confusing at times to have both terminating 0 and length
20:07:47FromGitter<krux02> especially because you don't know if the length tells the length including the 0 or not
20:07:49FromGitter<tim-st> for example lstrip
20:08:13FromGitter<krux02> and no storing a start index doesn't help at all
20:09:11FromGitter<tim-st> atm lstrip insitu does copying, I assumed that step could be skipped than
20:11:06*j_rod_s_ joined #nim
20:12:11dom96salewski: My plan is to add support for examples to Nimble
20:12:22salewskitim, i guess avoiding copying for operations like lstrip or slicing is hard -- araq and other devs no why they do it currently as it is.
20:12:31dom96so that Nimble installs them somewhere
20:12:45dom96IMO you should just point people to the GitHub source tree
20:13:08salewskidom96, great, so I will wait with example installation until nimble supports it. It is not urgent.
20:13:13*j_rod_s quit (Ping timeout: 240 seconds)
20:13:13*j_rod_s_ is now known as j_rod_s
20:13:33*MyMind quit (Read error: Connection reset by peer)
20:13:37salewskiBye.
20:14:02*rokups quit (Quit: Connection closed for inactivity)
20:14:13FromGitter<tim-st> @ salewski ok, just think it's used quite often, also in python. If the string is bigger that could have big performance boost, compared to one 64bit int that is in memory now, but of course I dont have the deep knowledge, it was just an idea ;)
20:14:38*MyMind joined #nim
20:14:40*salewski quit (Quit: WeeChat 1.9.1)
20:21:22*r3d9u11 quit (Remote host closed the connection)
20:31:39*francisl joined #nim
20:35:38*j_rod_s quit (Quit: j_rod_s)
20:36:12*francisl quit (Ping timeout: 240 seconds)
20:38:04*j_rod_s joined #nim
20:38:54*j_rod_s quit (Client Quit)
20:44:24*yglukhov joined #nim
20:46:46*Quantem joined #nim
20:47:30*Quantem quit (Client Quit)
20:49:03FromGitter<tim-st> Not sure if I misunderstood the nullterminating symbol, but is that assumed: `import strutils; echo "abc".startsWith("\0xyz")` ?
20:49:11FromGitter<tim-st> returns true
20:54:53*MyMind quit (Read error: Connection reset by peer)
20:55:58*MyMind joined #nim
21:03:54dom96"\0xyz" is treated as ""
21:04:18FromGitter<krux02> really?
21:05:26FromGitter<krux02> dom96 but that is wrong behavior if you ask me
21:05:33FromGitter<tim-st> @ dom96 Than str.len implementation is wrong for "\0xyz"
21:06:02FromGitter<krux02> @tim-st no the str.len is ok, the startsWith implementation is wrong
21:06:06FromGitter<tim-st> I think \0 should rethought a bit. I could hack many procs in strutils with this.
21:06:39FromGitter<tim-st> I wondered about this because I wanted to use \0 break instead of str.len for my parser; but now I have troubles
21:07:25FromGitter<krux02> @tim-st if you make a pull request to fix startsWith, I will support it
21:07:35FromGitter<krux02> your example should return false
21:07:48FromGitter<tim-st> it's not only startsWith. There are atleast 15 only in strutils
21:07:58FromGitter<tim-st> that was just an example, to rethink this
21:08:08FromGitter<krux02> strings in Nim are length based. The 0 terminator is just for C interoperability
21:08:22*Trustable joined #nim
21:08:28FromGitter<tim-st> I read adding \0 to string in c is not allowed at all (maybe for safety with this scenario)
21:08:29FromGitter<krux02> fix them all
21:08:48FromGitter<tim-st> the current implementation has performance boost this way
21:08:54FromGitter<krux02> you can add \0 as much as you want in C, but you should know what you are doing
21:09:02FromGitter<tim-st> ok
21:10:01FromGitter<krux02> functions that take a `const char*` as argument or the equivalent `cstring` in Nim interpret the data until the first 0 byte.
21:10:06FromGitter<tim-st> So this means my parser shouldnt break on \0 because this is not necessarily the string end?
21:10:16FromGitter<krux02> yes
21:10:33FromGitter<tim-st> ok, thanks
21:10:38AraqI fixed that in strutils but never merged it back :-)
21:10:55FromGitter<krux02> ok, that is interesting.
21:11:09FromGitter<krux02> would be happy to see it.
21:11:54FromGitter<krux02> why didn't you merge it?
21:11:58FromGitter<krux02> Did you break code?
21:12:15Araqwas in some branch that I couldn't merge
21:12:22Araqin fact
21:12:51Araqit was in the "" is represented as 'nil' branch
21:14:13FromGitter<krux02> ah, yea I know
21:14:24FromGitter<krux02> I tried that, too
21:14:33FromGitter<krux02> it just has random crashes
21:15:16FromGitter<krux02> I can't figure out what causes them
21:15:25Araqme neither :)
21:15:28FromGitter<krux02> I think it is related to the GC.
21:16:01FromGitter<krux02> Maybe the GC things there is an object to clean but ther isn't
21:16:02Araqit's something subtle
21:16:18AraqI should probably give it another try
21:19:41FromGitter<krux02> yes, would be nice.
21:22:50FromGitter<tim-st> for my parser I needed `continuesWith` with a param `ignoreCase:bool, is that a common use case? could that be implemented using `when` ?
21:23:36FromGitter<krux02> how do you want to implement that with a when statement?
21:23:41FromGitter<krux02> when is compile time if
21:24:07FromGitter<krux02> you can make three functions
21:24:11FromGitter<tim-st> Yeah that was the question, maybe the compiler sees if the boolean is known at compile time
21:24:41*yglukhov quit (Read error: Connection reset by peer)
21:24:50FromGitter<tim-st> because otherwise this would probably slow down too much
21:25:10FromGitter<krux02> `continuesWith(...)`, `continuesWithInsenSitive(...)` and `continuesWith(..., casesensitive: bool)` and the last one has an if two the other two
21:25:19*yglukhov joined #nim
21:25:42FromGitter<tim-st> I've written the second one
21:26:32FromGitter<krux02> don't think too much about it.
21:26:48FromGitter<tim-st> ok^^
21:26:54*vivus joined #nim
21:27:03FromGitter<tim-st> just thought it would be cool in stdlib
21:27:05FromGitter<krux02> being case sensitive just because it is faster and easier to implement is not wrong
21:32:05*yglukhov quit (Read error: Connection reset by peer)
21:32:39*yglukhov joined #nim
21:42:19PMunchtim-st, you should give ignoreCase a default
21:42:28PMunchIn my opinion at least
21:42:54PMunchYou're writing a parser too by the way?
21:42:58*couven92 joined #nim
21:43:30FromGitter<tim-st> yes, that was the idea, to set it to false, and use when inside to not have overhead, wasnt sure if that works
21:44:12PMunchSure it will
21:44:20PMunchYou could make it a template as well
21:45:35FromGitter<tim-st> ok, thanks
21:46:11FromGitter<tim-st> yes, I'm nearly finished with my current parser and after that another one :\
21:46:25PMunchParser, or parser library?
21:48:19FromGitter<tim-st> the current one is a library that parses a document structure and create document objects from it
21:50:50PMunchCool, I'm also writing a parser library
21:51:35FromGitter<tim-st> also related to document articles?
21:53:42PMunchGeneral purpose: https://github.com/PMunch/combparser
21:54:11PMunchIn action: https://github.com/PMunch/protobuf-nim/blob/master/protobuf.nim#L107
21:55:45FromGitter<tim-st> That looks Interesting!
21:56:05PMunchIt's still a work in progress
21:56:09PMunchBut it works pretty well
21:56:16PMunchWorking on better error messages now :)
21:56:28FromGitter<krux02> PMunch I just had a quick look at your parser library. It seems pretty young, still
21:57:47PMunchYeah it is
21:58:00FromGitter<krux02> How much do you want to improve on it?
21:58:35PMunchWell, when I finish with the issue I opened in the repo I think I'll call it v1.0
21:58:35FromGitter<krux02> I remember the parser combinators that were part of the standard library in scala until version 2.11
21:58:55PMunchI might play around a bit more with AST parsing first though
21:59:00*yglukhov quit (Remote host closed the connection)
21:59:06FromGitter<krux02> one of the best features it had, was that not only did it parse an ast, it also mapped it directly into a suable structure
21:59:19PMunchI've tried to make it all generic, so if you write your own base parsers you can use it to parse anything
21:59:30FromGitter<krux02> PMunch: remember documentation is key when you want to make it popular
21:59:38FromGitter<krux02> Write an introduction
21:59:49PMunchYeah, if you look in the protobuf library you can see how the parser returns a protobuf tree structure
21:59:55PMunchIt's actually really neat
22:00:06PMunchAnd yes, I will write documentation :)
22:00:11FromGitter<krux02> is it fast?
22:00:19PMunchNo idea really :P
22:00:27PMunchHaven't benchmarked it at all
22:00:36FromGitter<krux02> ok
22:00:51PMunchBut I haven't been focusing on speed while writing it, so I wouldn't be surprised if it was slow :P
22:01:05FromGitter<krux02> I wrote a parser for obj files (well a part of the specification) and there it needs to be fast because the files can be quite big
22:01:26FromGitter<krux02> PMunch: do you allecate a lot of new strings?
22:01:32PMunchYes..
22:01:40PMunchThat is one thing I'm going to improve though
22:01:50FromGitter<krux02> well then it's probably slow
22:01:54FromGitter<krux02> ok
22:02:41PMunchThe problem there is that I want error messages, so I want to store where in the input it is. But since the input is generic I've currently resorted to just saving the input, basically keeping multiple copies of parts of the string
22:03:04PMunchWell, and every parser gets input, which is a slice of the whole
22:03:05FromGitter<krux02> the fastest tokenizer I've seen. Did not allocate strings for tokens at all. It just created the tokens in an std::vector and an identifier was a pointer into the original data and a length
22:03:15PMunchYeah
22:03:21FromGitter<krux02> a substring if you want to call it that
22:03:35PMunchI've considered using a similar system
22:05:05PMunchBut I need it to be generic
22:05:20PMunchSo I must rely on the user writing some kind of index procedure for their type..
22:05:23FromGitter<krux02> well I've not much experience with writing good error messages, but my parsers are quite simple
22:05:50FromGitter<krux02> if I would want to parse nested structures, I would do it with recursion
22:06:02FromGitter<tim-st> I have recursion too
22:06:13FromGitter<tim-st> I read that gcc inline very good also recursion
22:06:21*miran quit (Quit: Konversation terminated!)
22:06:23FromGitter<tim-st> like 8 depths or so
22:06:47FromGitter<krux02> well if the recursion is not inlined, then it is not inlined, that is not he bottleneck I think
22:07:36FromGitter<tim-st> do you have a project on github where you have a parser?
22:07:40FromGitter<krux02> I remembor how I did everything
22:07:47FromGitter<krux02> I had the entire input in memory
22:07:51FromGitter<tim-st> I'm not sure if I did my parser well^^
22:08:07FromGitter<krux02> then I had a position index, a line index and a column index
22:08:13FromGitter<krux02> the last two for the error messages
22:08:40FromGitter<tim-st> I have like 10 procs and in each one I have a while loop where I call the appropriate proc base on the char
22:08:51FromGitter<tim-st> and one main proc
22:09:10FromGitter<krux02> well I did not parse protobuf so I don't know how complex that is
22:09:19FromGitter<krux02> obj files are not complex
22:09:57FromGitter<krux02> and most of it I just don't parse, because the specification is from the 80, and that stuff isn't really used anymore
22:10:16FromGitter<tim-st> ^^
22:10:44FromGitter<krux02> there is some progress in computer graphics since the 80's
22:14:36PMunchWell protobuf is kinda like C-syntax
22:14:58PMunchThink C structs but with nesting and inline enums
22:15:21FromGitter<krux02> I know protobuf
22:15:30FromGitter<krux02> but when I used it. I had a generator
22:15:41FromGitter<krux02> protobuf generated source code
22:15:42PMunchYeah, that's how you normally do it
22:15:50PMunchAnd that is what this will do
22:15:52FromGitter<krux02> and what do you differently?
22:15:59FromGitter<krux02> did you implement the generator as a macro?
22:16:08PMunchIt will parse the protobuf file on compile-time and output the code to use it
22:16:11PMunchYeah, pretty much
22:17:18FromGitter<krux02> the only thing that I am worried is that the protobuf file is parsed at compile time on the nimvm (slow) every time I hit compile
22:18:40PMunchWell, the Nim compiler does incremental compilation
22:18:46PMunchSo that shouldn't be much of an issue
22:19:31FromGitter<krux02> do you know how the nim compiler cashes the result of the macro?
22:19:39PMunchNope
22:20:00FromGitter<krux02> I don't think it does cashe any macro results
22:20:04PMunchI assume it might just be file based
22:20:18PMunchSo if the file hasn't changed it doesn't do anything with it
22:20:24FromGitter<krux02> I don't think so
22:20:36PMunchSo if you include a file with just the parsing done in it I think it should be fine
22:20:55FromGitter<krux02> the generated C files are only recompiled, when the output of the nim compiler changed them
22:21:29FromGitter<krux02> so even if you regenerate the file every time, the generated C file did not change and is therefore reused.
22:21:47*couven92 quit (Ping timeout: 256 seconds)
22:22:52*solitudesf quit (Ping timeout: 240 seconds)
22:25:42FromGitter<krux02> PMunch I would measure it to be sure
22:26:03FromGitter<krux02> because when you have big or many protobuf files, this could become an issue.
22:29:07PMunchHmm, I guess
22:37:05*ak102 quit (Ping timeout: 256 seconds)
22:39:20*ak102 joined #nim
22:39:20*ak102 quit (Changing host)
22:39:20*ak102 joined #nim
22:47:05*yglukhov joined #nim
22:51:12*yglukhov quit (Ping timeout: 240 seconds)
22:52:08*nsf quit (Quit: WeeChat 2.0.1)
23:01:38*rockcavera quit (Remote host closed the connection)
23:12:53*natrys quit (Quit: natrys)
23:14:44*couven92 joined #nim
23:19:46FromGitter<krux02> Araq: what does `benign` mean in system?
23:20:41FromGitter<krux02> It is not documented and it is used a lot
23:21:29*Trustable quit (Remote host closed the connection)
23:25:09Araq {.pragma: benign, gcsafe, locks: 0.}
23:25:42FromGitter<krux02> ok, thank you
23:29:37FromGitter<krux02> printing is not easy
23:30:42FromGitter<krux02> system.wirte(f: File, r: BiggestFloat) uses "%g" format string wich looses a lot of precision.
23:40:00*yglukhov joined #nim
23:44:31*yglukhov quit (Ping timeout: 256 seconds)
23:47:31GitDisc<Lua> Is there a better way of pausing a program instead of
23:47:31GitDisc<Lua> echo("Press any key to shutdown the program")
23:47:32GitDisc<Lua> let close: string = stdin.readline()
23:47:37GitDisc<Lua> discard close
23:49:33FromGitter<zetashift> maybe sleep https://nim-lang.org/docs/os.html#sleep,int ?
23:52:27*icebattle quit (Ping timeout: 256 seconds)
23:52:41*icebattle joined #nim
23:57:36Araqkrux02: formatFloat?
23:59:27*endragor joined #nim