<< 26-07-2018 >>
00:30:58*Jesin joined #nim
00:32:14*Jesin quit (Client Quit)
00:33:39*abm quit (Quit: Leaving)
00:48:08*Jesin joined #nim
00:51:36FromGitter<Varriount> @Altarrel: You'll either need to put this at the beginning of the header file, or use Nimgen to preprocess the header file. ⏎ ⏎ ```#def DISCORD_DYNAMIC_LIB ⏎ #def int64_t int64 ⏎ #def int32_t int32 ⏎ #def int8_t int8``` [https://gitter.im/nim-lang/Nim?at=5b591b181be9bb57bcc3bd3c]
00:59:35*xet7 quit (Quit: Leaving)
01:00:45*rayman226 joined #nim
01:01:02*rayman22201 quit (Read error: Connection reset by peer)
01:01:22*rayman22201 joined #nim
01:04:57*rayman226 quit (Ping timeout: 240 seconds)
01:15:32*rayman288 joined #nim
01:15:50*mwbrown quit (Ping timeout: 256 seconds)
01:17:44*rayman22201 quit (Ping timeout: 244 seconds)
01:20:44*mwbrown joined #nim
01:21:13*stefanos82 quit (Quit: Quitting for now...)
01:21:37*rayman22201 joined #nim
01:23:45*rayman288 quit (Ping timeout: 248 seconds)
01:28:16*rayman22201 quit (Quit: -a- IRC for Android 2.1.40)
01:45:06*Jesin quit (Quit: Leaving)
01:50:24*ftsf joined #nim
01:53:21FromGitter<gogolxdong> How to parse from ast like ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b592991a31e386158b1610c]
01:58:31FromGitter<gogolxdong> and build NimNode from it.
02:07:54FromGitter<gogolxdong> What's the difference between `object of RootObj` and `ref object of RootObj`?
02:08:12*DarkArctic_ joined #nim
02:09:35FromGitter<Quelklef> One is a reference :P
02:09:41FromGitter<Quelklef> Look up reference types vs object types
02:11:13*DarkArctic quit (Ping timeout: 248 seconds)
02:13:23*DarkArctic__ joined #nim
02:16:20*DarkArctic_ quit (Ping timeout: 256 seconds)
02:18:32*gmpreussner joined #nim
02:20:03*DarkArctic_ joined #nim
02:24:16*DarkArctic__ quit (Ping timeout: 256 seconds)
02:30:04*DarkArctic__ joined #nim
02:32:06*dddddd quit (Remote host closed the connection)
02:33:41*DarkArctic_ quit (Ping timeout: 244 seconds)
02:33:45*DarkArctic joined #nim
02:36:47*DarkArctic__ quit (Ping timeout: 244 seconds)
02:38:49*DarkArctic_ joined #nim
02:39:19*DarkArctic quit (Read error: Connection reset by peer)
02:40:08*DarkArctic__ joined #nim
02:44:06*DarkArctic_ quit (Ping timeout: 256 seconds)
03:03:24*DarkArctic_ joined #nim
03:06:05*DarkArctic joined #nim
03:06:57*DarkArctic__ quit (Ping timeout: 264 seconds)
03:07:59*DarkArctic_ quit (Ping timeout: 260 seconds)
03:10:20*DarkArctic_ joined #nim
03:13:33*DarkArctic quit (Ping timeout: 264 seconds)
03:16:43*DarkArctic joined #nim
03:20:09*DarkArctic_ quit (Ping timeout: 264 seconds)
03:25:14*icebattle joined #nim
03:30:05FromGitter<gogolxdong> Since objects are value types in Nim, composition is as efficient as inheritance.
03:30:55FromGitter<gogolxdong> new an object will return its ref right?
03:31:01FromGitter<Quelklef> no
03:31:10FromGitter<Quelklef> pretty sure new is `proc newT (x: ref T): void`
03:31:43FromGitter<Quelklef> not quite, apparently its `proc newT (x: var ref T): void`
03:34:53*endragor joined #nim
03:34:55FromGitter<gogolxdong> ```code paste, see link``` ⏎ ⏎ ref 0x7f94f6d7f048 --> [name = 0x7f94f6d80058"sheldon"] [https://gitter.im/nim-lang/Nim?at=5b59415edb4bcb16e879aaf5]
03:35:35*icebattle quit (Ping timeout: 240 seconds)
03:35:40FromGitter<Quelklef> ?
03:37:48*icebattle joined #nim
03:51:29*icebattle quit (Read error: Connection reset by peer)
03:55:36*icebattle joined #nim
04:01:48FromGitter<gogolxdong> Why does it say? ⏎ `Error: invalid expression: wsdl` of ⏎ nodes.add newNimNode(nnkTypeDef).add(newIdentNode("wsdl"), newEmptyNode())
04:14:46*icebattle quit (Ping timeout: 256 seconds)
04:18:04*rayman22201 joined #nim
04:34:48*Shivelight joined #nim
04:36:47*nsf joined #nim
04:40:23FromGitter<Quelklef> You're gonna need to give us more info than that
04:40:28FromGitter<Quelklef> like the source code
05:13:12*DarkArctic_ joined #nim
05:16:40*DarkArctic quit (Ping timeout: 256 seconds)
05:25:34*DarkArctic__ joined #nim
05:28:33*DarkArctic_ quit (Ping timeout: 264 seconds)
06:02:13FromGitter<gogolxdong> Why does the following ⏎ ⏎ ```in expression '[("b", 3), ("c", 5)]."toTable"': identifier expected, but found '"toTable"'``` [https://gitter.im/nim-lang/Nim?at=5b5963e5ee7b230b4469fee1]
06:02:58FromGitter<gogolxdong> according to the astspec.txt , it should be `{a: 3, b: 5}`
06:04:31FromGitter<gogolxdong> and ⏎ ⏎ ```undeclared identifier: 'b'``` [https://gitter.im/nim-lang/Nim?at=5b59646fe5fc191d959e3c5a]
06:44:29*Shivelight quit (Quit: Connection closed for inactivity)
06:56:56*xylef joined #nim
07:08:40*NamPNQ joined #nim
07:16:54*leorize quit (Ping timeout: 260 seconds)
07:31:42*yglukhov[i] joined #nim
07:37:31*Shivelight joined #nim
07:39:18*ng0 joined #nim
07:51:23*floppydh joined #nim
07:52:36*yglukhov_ joined #nim
07:56:28*yglukhov[i] quit (Ping timeout: 256 seconds)
07:57:28FromGitter<andreaferretti> is there a way to configure which backend to use when running `nim c` from inside a nim.cfg file?
07:57:37FromGitter<andreaferretti> something like `--backend: cpp`
07:57:49FromGitter<andreaferretti> I skimmed the compiler options but could not find it
07:57:55FromGitter<mratsim> you should use nim cpp?
07:58:01FromGitter<andreaferretti> yeah I know
07:58:23FromGitter<andreaferretti> the point is that I am trying to automate checking for the status of nim issues
07:58:32FromGitter<mratsim> i.e. the “way” to go is do do: ⏎ ⏎ when not defined(cpp): ⏎ {.error: “Use CPP backend”.} [https://gitter.im/nim-lang/Nim?at=5b597f275301255724c76ce2]
07:58:35FromGitter<mratsim> ah
07:58:37FromGitter<andreaferretti> and I have already many variants
07:58:52FromGitter<andreaferretti> I wouldn't like to treat issues that involve cpp differently
07:59:06FromGitter<andreaferretti> just add issuexxx.nim.cfg file if possible
08:00:24FromGitter<andreaferretti> (I have variants like: this thing should compile, this thing should not, this one should output this result and so on - I'd rather not duplicate them for cpp)
08:00:58FromGitter<andreaferretti> I will use some bash hack with the file name instead
08:12:54*gmpreussner quit (Ping timeout: 256 seconds)
08:13:28*gmpreussner joined #nim
08:20:55*xylef quit (Quit: WeeChat 2.2)
08:24:59FromGitter<gogolxdong> What's the form of `nnkFormalParams`?
08:36:30*arecacea1 quit (Read error: Connection reset by peer)
08:36:51*arecacea1 joined #nim
08:37:00FromGitter<mratsim> you should use `dumpASTGen`on a proc to check
08:38:03FromGitter<mratsim> ```dumpASTGen: ⏎ myAwesomeProc(x, y: int): int {.myPragma.} = result = 1``` [https://gitter.im/nim-lang/Nim?at=5b59886bc0fa8016e73a502c]
08:38:22FromGitter<mratsim> maybe add a dose of generics as well
08:41:38FromGitter<gogolxdong> reverse engineering , this is helpful, I found there is a elaborate sample of proc in astspec.txt .
08:46:46*literal quit (Ping timeout: 256 seconds)
08:47:30*literal joined #nim
08:49:12*Ven`` joined #nim
08:50:36*leorize joined #nim
08:51:39FromGitter<gogolxdong> How to put params ? It's varargs, seq[NimNode] cannot convert to varargs[NimNode]
08:53:47*xet7 joined #nim
08:54:13*dddddd joined #nim
08:55:09*ng0 quit (Quit: Alexa, when is the end of world?)
08:56:03*krux02 joined #nim
09:21:53*xylef joined #nim
09:57:55*Vladar joined #nim
10:03:22*clyybber joined #nim
10:11:56*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:24:29*Shivelight quit (Quit: Connection closed for inactivity)
10:30:33*ng0 joined #nim
10:31:33FromGitter<mratsim> @gogolxdong use nnkarglistj.newTree
10:45:53*yglukhov_ quit (Ping timeout: 248 seconds)
10:46:27*yglukhov[i] joined #nim
10:48:05*ng0 quit (Quit: Alexa, when is the end of world?)
11:07:38*xylef quit (Quit: WeeChat 2.2)
11:09:55FromGitter<Varriount> @dom96 When you said that you're "largely happy with this [exceptions] proposal, did you mean the original proposal by Araq, or the systems suggested in the comments?
11:10:26dom96The latter
11:10:56dom96but it really depends what else will be on the menu for Nim 2.0
11:17:47*ng0 joined #nim
11:18:20krux02dom96: this is what I think when you talk about Nim 2.0: https://www.bueromarkt-ag.de/bilder/bonbons_nimm2_orange_und_zitrone,p-270162_2,s-700.jpg
11:31:35*NamPNQ quit (Remote host closed the connection)
11:46:27*yglukhov[i] quit (Ping timeout: 240 seconds)
11:48:07*yglukhov[i] joined #nim
11:55:30*yglukhov[i] quit (Ping timeout: 260 seconds)
12:03:00*yglukhov[i] joined #nim
12:07:13*stefanos82 joined #nim
12:27:50*nsf quit (Quit: WeeChat 2.1)
12:29:00*noonien joined #nim
12:29:46*yglukhov[i] quit (Read error: Connection reset by peer)
12:30:23*yglukhov[i] joined #nim
12:45:21*stefanos82 quit (Quit: Quitting for now...)
12:48:30*stefanos82 joined #nim
12:51:18*endragor quit (Remote host closed the connection)
13:05:52*endragor joined #nim
13:07:08*ng0 quit (Quit: Alexa, when is the end of world?)
13:07:38*clyybber quit (Ping timeout: 244 seconds)
13:09:28*ng0 joined #nim
13:10:13*endragor quit (Ping timeout: 244 seconds)
13:10:26*ng0 quit (Client Quit)
13:16:37*Ven`` joined #nim
13:21:42*ng0 joined #nim
13:22:36*krux02 quit (Quit: Leaving)
13:23:55livcddom96: windows defender detects choosenim as a virus
13:23:58livcdor is this known ?
13:24:05*Ven`` quit (Ping timeout: 268 seconds)
13:25:25FromGitter<ephja> I knew it couldn't be trusted!
13:25:29*BitPuffin joined #nim
13:26:22livcdmaybe it's just a setting in my organization
13:31:35FromGitter<Quelklef> hahaha
13:31:56FromGitter<Quelklef> I knew dom was a secret evil villain all this time
13:32:29dom96darn, my evil has been discovered. I would have gotten away with it too, if it wasn't for you meddling kids!
13:32:29FromGitter<Quelklef> He's don a Ken Thompson hack and inserted a virus into the choosenim's bootstrapping process!
13:32:32*dom96 shakes fist
13:33:07FromGitter<ephja> book advertisement botnet
13:34:00livcdwell actually
13:34:20livcdi was just trying to build Chapter7 from Nim in Action
13:34:40livcdand it refused because i am on 0.18.0
13:35:29*yglukhov[i] quit (Read error: Connection reset by peer)
13:36:06*yglukhov[i] joined #nim
13:38:10*Ven`` joined #nim
13:38:53*ng0 quit (Quit: Alexa, when is the end of world?)
13:39:58FromDiscord<Hel> so i have both 32bit and 64bit version of mingw on my pc
13:40:09FromDiscord<Hel> how do i make nim switch between them when compiling?
13:41:15FromGitter<Bennyelg> how do I run my "fixed" forked version to see if my build is pass ?
13:41:32livcdwhat does switch between them mean or what do you want to achieve ?
13:41:53FromDiscord<Hel> i want nim to be able to compile to both 32 and 64 bit
13:45:16*d10n-work joined #nim
13:52:08FromDiscord<Hel> nvm
13:57:56*cryptocat1094 joined #nim
14:05:19*fvs joined #nim
14:23:28zacharycarter[m]change the nim compiler executable
14:23:39zacharycarter[m]and the target arch
14:23:48zacharycarter[m]which is the cpu flag I think
14:35:33*Sembei joined #nim
14:37:06*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:37:33*Pisuke quit (Ping timeout: 264 seconds)
14:40:48*yglukhov_ joined #nim
14:40:49FromDiscord<Hel> yeah i forgot nim.cfg existed and that it has a purpose
14:41:30Calinouhttps://github.com/Calinou/clr/releases
14:41:38Calinouyay for making Travis CI and GitLab CI work together :P
14:41:41Calinouthere's macOS builds now
14:42:42*yglukhov[i] quit (Ping timeout: 244 seconds)
14:51:58FromGitter<gogolxdong> What does Error: cannot generate code for: mSlice mean?
14:52:26FromGitter<Quelklef> @gogolxdong please give us the source code
14:53:03*Ven`` joined #nim
14:53:24FromGitter<mratsim> mSlice is toopenArray i think
14:54:37FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b59e0ade5fc191d959fc5bf]
14:55:21FromGitter<gogolxdong> the last line ,error raised from packedjson.
14:55:45Araquse Nim devel to compile packedjson
14:56:12*DarkArctic__ quit (Quit: Leaving)
14:56:42*DarkArctic joined #nim
14:57:50*Trustable joined #nim
14:59:15FromGitter<gogolxdong> It's latest.
14:59:27FromGitter<gogolxdong> both Nim and packedjson.
15:00:07*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:00:51Araqcan you extract a small test case for packedjson then?
15:04:57FromGitter<gogolxdong> tested ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b59e3191be9bb57bcc5f072]
15:06:06FromGitter<gogolxdong> it works but the above doesn't.
15:10:25*icebattle joined #nim
15:17:13FromGitter<gogolxdong> don't know where trigger this error ,but it's from macro body.
15:17:40FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b59e614c0fa8016e73b97e1]
15:17:42*gangstacat quit (Quit: Ĝis!)
15:19:31FromGitter<gogolxdong> seems packedjson doesn't work in macro
15:21:10FromGitter<gogolxdong> BTW, stdlib.json works
15:21:30*rayman22201 quit (Quit: -a- IRC for Android 2.1.40)
15:21:34FromGitter<gogolxdong> should I use json instead?
15:47:48*ftsf quit (Ping timeout: 244 seconds)
15:53:48ehmrym
15:53:50ehmryc
15:53:59ehmrywoops
16:01:05FromGitter<gogolxdong> my debug shows it follows the path of `[]` -> rawGet -> extractLen -> x[pos]
16:05:27FromGitter<kayabaNerve> The recent Exceptions RFC is irrelevant if your program can never error. RFC to make Nim never Error by making the only valid Nim program an empty file.
16:05:42FromGitter<kayabaNerve> 🤔
16:06:49FromGitter<Quelklef> Seconded
16:07:03*yglukhov_ quit (Read error: Connection reset by peer)
16:07:38*yglukhov[i] joined #nim
16:07:56FromGitter<Quelklef> RFC to make exception-handling Go-style so that no exception "actually" ever occurs
16:09:13*icebattle quit (Ping timeout: 256 seconds)
16:16:41*icebattle joined #nim
16:30:13FromGitter<kayabaNerve> How to destroy the Nim language: give @Quelklef full repo ownership and tell him to do whatever he thinks is best. 🤔
16:30:35FromGitter<kayabaNerve> Nah. We're open source. We don't have to listen to a centralized authority like that :D
16:30:41FromGitter<Quelklef> ;))
16:31:01FromGitter<Quelklef> I wouldn't do anything to it 'cause I have no fuckin clue how the compiler works
16:31:41FromGitter<Quelklef> I could poke around the parser I suppose but
16:31:59FromGitter<Quelklef> once it gets to static analysis and compilation, I'm out
16:32:00dom96Replace all keywords with emojis :D
16:32:06FromGitter<Quelklef> OH GO
16:32:08FromGitter<Quelklef> D
16:32:20FromGitter<Quelklef> Like this? https://www.emojicode.org/
16:32:23FromGitter<kayabaNerve> Someone else already did that
16:32:23FromGitter<kayabaNerve> ^^
16:32:45dom96Damn it, it's almost impossible to have an original thought in this world nowadays
16:32:48FromGitter<Quelklef> darn my browser doesn't have support for those emojis :(
16:32:54FromGitter<Quelklef> I feel that
16:33:03FromGitter<Quelklef> I've had several "original ideas" that I found out Nim implements, lol
16:33:13FromGitter<kayabaNerve> dom96 other people have already said that exact same thing
16:33:35FromGitter<kayabaNerve> Something something asking Ara_q to implement converters
16:34:15FromGitter<kayabaNerve> That day I learned they were already there
16:40:56FromGitter<rayman22201> lmao.
16:43:06FromGitter<rayman22201> Serious question / thought about the RFC. @dom96, you brought up a good point, which is that I just assumed this RFC was for post 1.0. But that might have just been me doing the "making assumptions makes an ass out of you and me". Should it be part of the RFC or a Tag or something to make it clear what version an RFC is targeting?
16:45:44leorizegithub have something called milestone
16:46:04leorizeI think everything that's targeting v1 is tagged with v1 milestone
16:46:05FromGitter<rayman22201> Yes, milestones are used in Nim. you can see them
16:46:55FromGitter<rayman22201> The reason I assumed the RFC was not for 1.0 was because the 1.0 milestone did not have that RFC listed.
16:47:45FromGitter<rayman22201> @dom96 made several comments that he thinks @Araq wanted the new exceptions for 1.0 though.
16:47:52FromGitter<rayman22201> which contradicts the milestone
16:48:20FromGitter<rayman22201> and it doesn't make sense to put a newly proposed RFC into a milestone anyway
16:48:27dom96I think it's safe to assume that any RFC you see is meant for "right now"
16:48:34dom96Unless it explicitly mentions v2.0
16:48:55dom96if you add it to the milestone then it's as if the RFC was accepted
16:50:56FromGitter<rayman22201> when you say meant for "right now", you mean meant for discussing right now, or implementing right now?
16:52:15*literal quit (Ping timeout: 265 seconds)
16:53:08dom96Implementing right now
16:53:20*literal joined #nim
16:53:27dom96In fact, it's rather pointless to discuss 2.0 currently
16:53:35dom96It's too far in the future
16:53:57FromGitter<rayman22201> hrmmm....
16:55:09*yglukhov_ joined #nim
16:56:26FromGitter<rayman22201> Doesn't "implement right now" defeat the purpose of the milestones?
16:57:04FromGitter<rayman22201> I see your issue with the whole thing now
16:58:03*yglukhov[i] quit (Ping timeout: 265 seconds)
16:58:27FromGitter<rayman22201> the real issue for me is that, even with the milestones, I am not clear on what the goals for 1.0 are. There are seveal RFCs in github right now that are not part of the 1.0 milestone. Are those unofficially blocking 1.0?
17:01:47FromGitter<rayman22201> A good RFC should be able to be proposed for implementation past the current milestone. It may be pointless to talk about 2.0 right now, but it's useful to talk about features > 1.0, we should always have goals for the future.
17:08:03FromGitter<rayman22201> Maybe I'm asking for a more clear roadmap. A common practice is to have a feature freeze, and focus only on bug fixes and stability for a period leading up to a release. Is that something that the you guys have discussed?
17:08:06*krux02 joined #nim
17:09:23FromGitter<Quelklef> IIRC Araq has expressed a similar sentiment
17:09:27FromGitter<Quelklef> let me see if I can find the post
17:10:32*krux02_ joined #nim
17:11:13FromGitter<rayman22201> I just feel bad because I was "fanning the flames" on this RFC, because I think it's cool. But I never meant to derail core development over it. I want 1.0 as much as the next Nim programmer lol
17:11:16*nsf joined #nim
17:12:38FromGitter<rayman22201> not that I think I'm actually "derailing" anything. I realize I don't have that kind of power :-P
17:13:27FromGitter<Quelklef> I can't find the post
17:13:37*ng0 joined #nim
17:13:38FromGitter<Quelklef> but I remember Araq saying somewhere that he does want to focus on stability until 1.0
17:13:44FromGitter<Quelklef> And try not to introduce new features
17:14:52FromGitter<rayman22201> It's Ironic that he introduced this RFC then lol.
17:15:53FromGitter<rayman22201> I remember seeing Araq say something similar at one point as well. That is another reason I assumed it was an after 1.0 proposal though.
17:16:58FromGitter<rayman22201> If there is a feature freeze for 1.0 in effect, it should really be more clearly visible somewhere...
17:17:11Araqthe v1 plan is in github
17:17:28Araqand RFCs like "different exceptions" are not part of it
17:17:40FromGitter<rayman22201> that's what I thought!?!
17:17:43Araqthe v1 plan is probably overly ambitious though
17:17:57Araqok, so ... what's the question?
17:18:40FromGitter<rayman22201> @dom96 has been very vocal in the RFC about reminding people that "this is not for 1.0". Which makes me and other people think that it was proposed for 1.0
17:18:57Araq"in the RFC"? which one?
17:19:02FromGitter<rayman22201> the exceptions RFC
17:19:17FromGitter<rayman22201> #8363
17:19:18Araqyeah, not for 1.0
17:19:26Araqshould have been more clear, sorry
17:19:30dom96what?
17:19:50dom96Pretty sure you even told me this was for 1.0
17:19:56Araqwell ... it started with something I want to do for v1
17:20:17Araqand then it developed into something that can't be done for v1
17:20:19dom96Yes, so the RFC was for 1.0
17:20:23dom96But you changed your mind about it
17:20:27dom96So it's no longer for 1.0
17:20:37FromGitter<rayman22201> lol! #BDFL powers activate
17:20:38Araqtbh I'm not sure.
17:21:11dom96lol
17:21:14dom96Please be more explicit
17:21:16FromGitter<Quelklef> we'll find out when 1.0 comes out whether it's in 1.0 or not
17:21:17dom96What are you unsure about?
17:21:32Araqif I initially thought it would be for v1
17:23:00*dorelix quit (Quit: Leaving)
17:23:10dom96IMO all RFCs that don't explicitly say "This is for v2.0" are effectively a proposal for 1.0
17:23:21dom96Discussing 2.0 proposals is a bit of a waste of time at this point
17:23:26AraqIMO it's different
17:23:44Araqall RFCs that are not in the v1 plan, are not for v1 but for v2, unless (and that's a big unless)
17:24:01stefanos82well, you could excuse yourself by clarifying to v1.x than to v1 that indirect points to v1.0, whereas .x could be any version number you want
17:24:14Araqit's not implemented by the core team anyway
17:24:25dom96No, RFCs are suggested by our community
17:24:31dom96It's up to them whether they are suggesting it for 1.0 or not
17:24:50Araqdepends on if the community is working on them or not
17:25:04FromGitter<rayman22201> @dom96, I have to agree with @Araq. That shouldn't be the community decision. They get to propose the RFC, the core team gets to decide when it gets merged!
17:25:14AraqI regard these as orthogonal to v1
17:25:34FromGitter<Quelklef> I'm in this boat as well. RFCs are about the features which shouldn't (IMO) be tied to any specific version
17:26:03Araqwell we have a v1 plan, I'm working on *only* that (even though I'm on holidays right now)
17:26:10dom96But ... this is exactly why we are having trouble here.
17:26:10FromGitter<rayman22201> I know of no software project that works that way. It would be chaos if the community decided what feature goes into a certain version. You would never get anything shipped!
17:26:10FromGitter<Quelklef> Unless there's a known change coming up which will be incompatible with the RFC and it needs to be merged before then, or something like that
17:26:35dom96RFCs are proposed now
17:26:38Araqwell ok, it also depends on whether the RFC will break stuff or not.
17:26:44dom96The people proposing them assume that they will be implemented now
17:27:01dom96**Especially** if these features break backwards compatibility
17:27:07dom96Which the exceptions RFC did do
17:27:31Araqlet me mark that RFC with "postponed"
17:27:34dom96This isn't about "This RFC goes into exactly version 1.0.0"
17:27:58dom96It's about "This RFC is for the 0.x.x releases" or "pre-1.0"
17:28:10dom96It makes a big difference to RFCs which it is
17:28:31Araqwell the exception RFC was written by me
17:28:36dom96Of course, it makes no sense for an RFC to say "This is to be implemented in version 0.18.2" (which might not even exist).
17:28:39Araqand I got too many downvotes
17:28:50FromGitter<rayman22201> lol
17:28:57Araqso, if something like that makes it into Nim
17:29:09Araqit will need an updated RFC.
17:29:20Araqfirst. I can close it too if you want to.
17:29:40Araqbut that's a special RFC, ninja'ed by myself.
17:29:53Araqwhat about RFCs in general?
17:30:19Araqthey can't be for v1.
17:30:37FromGitter<rayman22201> It was a good idea though! A good idea that breaks backwards compatibility / needs to be implemented in the future, still needs an avenue to be discussed.
17:31:10FromGitter<rayman22201> The C++ committee has proposals for C++ 24... Talking about RFCs for the far future is not that weird
17:31:58FromGitter<rayman22201> It just needs to be made explicit approximately where that RFC is in the roadmap.
17:32:04FromGitter<rayman22201> which is subject to change of course
17:33:07Araqthe "let's have better init RFC" is backwards compatible and so if somebody works on it and pushes it through, it will be in v1. if not, then it won't. seems fair to me.
17:33:43Araqan RFC which would break too much code has little chance to be accepted to begin with.
17:35:05FromGitter<rayman22201> fair enough
17:36:10*icebattle quit (Ping timeout: 256 seconds)
17:38:32*gangstacat joined #nim
17:39:00FromGitter<Quelklef> Wait, what versioning system does Nim use? I had assumed semantic versioning, but I'm getting the sense that that's perhaps not correct
17:39:13FromGitter<Quelklef> 1) 0-compatible features will be merged before 2.0, right?
17:40:31*rockcavera quit (Remote host closed the connection)
17:42:15Araqwe are trying semantic versioning.
17:42:30FromGitter<Quelklef> Cool
17:52:16*endragor joined #nim
17:55:32FromGitter<mratsim> should we create a tag backward-incompatible to further classify RFCs?
17:57:00*endragor quit (Ping timeout: 256 seconds)
17:57:37*krux02_ quit (Remote host closed the connection)
17:58:07*dorelix joined #nim
17:59:02Araqcan't hurt
18:00:00stefanos82for some reason I had the impression Nim's metaprogramming was supposed to allow language's extension based on a user's needs
18:00:22FromGitter<Quelklef> ... that sounds about right. What's up?
18:02:17FromGitter<Quelklef> Also, is there any convention on what `{}` and `{}=` are? They're accessors, but how do they differ from `[]` and `[]=`? If there is none, I'd like to suggest that they be "lax" versions of corresponding `[]` and `[]=`. Where `string[string.len]` throws an error, `string{string.len}` returns '\0', etc.
18:03:36dom96that is exactly what the convention is :)
18:03:51FromGitter<Quelklef> Oh, awesome!
18:04:32FromGitter<kayabaNerve> What if I do {len+1}
18:04:35FromGitter<kayabaNerve> Null or error?
18:04:55FromGitter<Quelklef> null still, I suppose
18:05:16subsetparkdom96: new error running a nimble task from CI: `Error: undeclared identifier: 'version'`. Any ideas where to start looking?
18:07:56FromGitter<kayabaNerve> @Quelklef Or error :P I guess null though
18:08:06FromGitter<Quelklef> Nah, I think null is good, especially in this case
18:08:11FromGitter<kayabaNerve> It could also cause random data
18:08:23FromGitter<kayabaNerve> I'm not asking what it should; I'm asking what it does
18:08:24FromGitter<Quelklef> Since a valid `string[x]` call will NEVER return '\0', since '\0' is the string terminator
18:08:31FromGitter<Quelklef> Oh. It's not defined right now my man
18:08:39FromGitter<mratsim> @stefanos82, lots of the recent RFCs are not just extension but syntax or semantic changes
18:08:53dom96subsetpark: show me more of the output
18:08:55dom96that's really weird
18:08:58FromGitter<kayabaNerve> Oh. Yep. Just realized that
18:09:12stefanos82@mratsim: semantic, like how something it's implemented behind the scenes?
18:09:13FromGitter<kayabaNerve> @mratsim Yeah. I added one to normalize the paths in Nim handled pragmas.
18:09:24FromGitter<kayabaNerve> It'll change how every path in the header pragma works
18:09:42subsetparkdom96: https://ghostbin.com/paste/3bjjp
18:10:00FromGitter<mratsim> @stefanos82: this is an example of semantic change: https://github.com/nim-lang/Nim/issues/8208
18:10:04subsetparki replaced the nimble task invocation with the commands that those tasks execute, and they work fine
18:10:13subsetparkand the tasks work fine from my local
18:10:27subsetparkas did they, i'm pretty sure, on that particular commit that choosenim is pegged at...
18:10:40dom96can you reproduce this?
18:10:56FromGitter<kayabaNerve> I support null btw @Quelklef
18:11:41subsetparkhmm... nope, i reran the same build and it worked fine
18:12:14FromGitter<kayabaNerve> MAGIC
18:12:17stefanos82@mratsim: this example shows something that shouldn't have been allowed in the first place I'm afraid. It can lead to unnecessary confusion to those who come to Nim for the first time or want to learn more about Nim metaprogramming
18:12:43FromGitter<Quelklef> Yeah. It'd also be really nice to have a `{}` on slices that doesn't complain about being out of range, just makes the result string smaller. Means result.len != slice.b - slice.a, but also means that you can idiomatically do `s{0 ..< 100}` to take 100 or less from the string
18:12:47FromGitter<Quelklef> I think I'll make a PR
18:13:31FromGitter<mratsim> I’d like {} to be an alias to `toopenArray` actually
18:14:01FromGitter<Quelklef> example?
18:14:03*vivus joined #nim
18:15:21FromGitter<Quelklef> Oh it's not in the docs cause its in devel innit
18:15:22FromGitter<mratsim> if you slice+assign a seq `b[10..20] = a[0..10]`, you create a new seq, then copy the data.
18:15:57FromGitter<mratsim> if you want to avoid the extra allocation you have to do `b[10..20] = a.toOpenArray(0, 10)` currently
18:17:17FromGitter<Quelklef> Ah
18:17:33FromGitter<Quelklef> I mean you could have `a{x .. y}` be lax slicing and `a{x, y}` be toOpenArray
18:17:37FromGitter<Quelklef> it'd be a little weird though
18:17:54FromGitter<mratsim> yeah it will be tricky
18:18:19FromGitter<mratsim> well if {} is lready used for lax slicing on string, it can stay so.
18:18:28FromGitter<Quelklef> it isn't, not yet, I don't think
18:18:31FromGitter<mratsim> I wasn’t even aware that existed
18:18:36FromGitter<Quelklef> Not in stable, anyway
18:19:26FromGitter<mratsim> toOpenArray can even be `a[.10..20.]`, though it’s super strange and unsearchable too.
18:19:51FromGitter<Quelklef> Oh, is `[. .]` an operator? I thought it was unused but reserved syntax
18:20:04FromGitter<mratsim> no it’s not.
18:20:12FromGitter<Quelklef> No it's not what
18:20:16FromGitter<Quelklef> Not an operator, or no unused?
18:20:57FromGitter<mratsim> I’m not even sure the parser maps it to any symbol
18:20:57FromGitter<Quelklef> not*
18:21:07FromGitter<Quelklef> yeah thats what I thought
18:21:51FromGitter<Quelklef> close enough, anyway
18:22:40FromGitter<Quelklef> I think `{}` being toOpenArray would be weird because if it were then it should be implemented generically, not just for strings
18:22:50*Ven`` joined #nim
18:22:58FromGitter<Quelklef> But having a generic `{}` would be weird because that's what `.toOpenArray` is for
18:23:39FromGitter<Quelklef> Dunno, perhaps a `` `{}`T (x: T, a, b: int) = x.toOpenArray(a, b)`` wouldn't be too bad
18:27:13stefanos82what is {}T supposed to do?
18:27:25FromGitter<Quelklef> It just means I'm defining {} to be generic
18:27:42stefanos82that looks confusing
18:27:47FromGitter<Quelklef> /shrug
18:28:00FromGitter<Quelklef> identifier, generic params, formal params, `=`, body
18:28:05FromGitter<Quelklef> just like any other proc
18:28:16stefanos82Nim should retain its simplicity
18:28:23stefanos82no need to add unnecessary complexities
18:28:28stefanos82we have C++ already doing that for us
18:28:35FromGitter<Quelklef> Um
18:28:54FromGitter<Quelklef> What part of ``proc `{}`T (x: T, a, b: int) = x.toOpenArray(a, b)`` is unnecessarily complex?
18:29:29stefanos82any part that adds an extra layer of complexity in the language
18:29:58FromGitter<Quelklef> Generics are indispensable IMO
18:31:27FromGitter<Quelklef> Unless you want to get rid of user-defined operators, generics, `x.f(a, b)` call syntax, `a, b: T` type annotations, or expressions as proc bodies, I don't know what you'd remove
18:31:54FromGitter<Quelklef> And personally the first 3 things there are some of my favorite parts of the language and are quite elegant and not that complex
18:32:01stefanos82I agree with the indispensable comment, but I'm sure there is a way to implement them without adding syntax complexities.
18:32:04FromGitter<Quelklef> (Well, generics is complex)
18:32:12FromGitter<Quelklef> Not Nim's generics
18:32:22FromGitter<Quelklef> You may want to do something like Haskell does
18:32:43FromGitter<Quelklef> Where types have to start with an upper case letter, and then all identifiers in a type that are lowercase are assumed to be type parameters
18:33:01FromGitter<Quelklef> So it'd instead be `proc `{}`(x: a, a, b: int) = x.toOpenArray(a, b)`
18:33:29FromGitter<Quelklef> However, the reason Haskell is able to do that is because its type parameters are local to the expression. Nim's are not, take a look at:
18:33:56FromGitter<Quelklef> ```proc f[T](x: T) = ⏎ when T == int: ⏎ echo("biinegigenge") ⏎ echo(x)``` [https://gitter.im/nim-lang/Nim?at=5b5a1414d2f0934551d36d61]
18:34:20FromGitter<Quelklef> Then consider:
18:34:35FromGitter<Quelklef> Sorry, let me undo the previous line
18:34:42FromGitter<Quelklef> "line" as in "message"
18:34:58FromGitter<Quelklef> Now, consider if we had these Haskell-like type type annotations with nicer syntax
18:35:05FromGitter<Quelklef> That example comes cleaner:
18:35:23FromGitter<Quelklef> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b5a146b07be4357bdf0a63c]
18:35:29FromGitter<Quelklef> However, it breaks other things. Consider this:
18:35:58FromGitter<Quelklef> ```proc outer(x: a) = ⏎ proc inner(x: a) = ⏎ echo(x) ⏎ inner()``` [https://gitter.im/nim-lang/Nim?at=5b5a148de5fc191d95a07cfe]
18:36:09FromGitter<Quelklef> Sorry, bad example. Let me try again:
18:36:32stefanos82how about writing down your thoughts and clear things up first and then provide an actual example?
18:36:37FromGitter<Quelklef> ```proc outer(x: a) = ⏎ proc inner(y: a) = ⏎ echo(x) ⏎ inner(4)``` [https://gitter.im/nim-lang/Nim?at=5b5a14b53396495b333dcc67]
18:36:41FromGitter<Quelklef> ^ this one works
18:37:00FromGitter<Quelklef> does the `a` in `y: a` refer to the same `a` in `x: a`? It's unclear
18:37:49FromGitter<Quelklef> If it does, then `outer` will only compile when `a` is `int`, because then `inner` will be of type `int`, and `4` is `int`
18:37:58FromGitter<Quelklef> But if, say, `a` is string, it'll yell at you
18:38:10FromGitter<Quelklef> But the more important part is the ambiguity
18:38:43FromGitter<Quelklef> Of course, this can be solved, but it *must* be solved with another kind of annotation
18:39:03FromGitter<Quelklef> No matter, you need to make type scope clear *somehow*. And I think that the way that was chosen is just fine
18:39:48stefanos82did you read this? https://github.com/nim-lang/Nim/issues/7449
18:40:51FromGitter<Quelklef> No, but I don't see how it's directly relevant
18:41:18*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:41:24stefanos82it relates to nested proc example of yours
18:41:47FromGitter<Quelklef> Sure, it's similar
18:52:03*nsf quit (Quit: WeeChat 2.1)
18:52:34FromGitter<kayabaNerve> @Quelklef Because you're not a real Nim dev if you can't cite every PR, issue, and Git Patch file by memory
18:52:51FromGitter<kayabaNerve> That's how it's directly relevant
18:53:12FromGitter<Quelklef> ?
18:53:23FromGitter<Quelklef> I mean, I don't see how it's relevant to my argument
18:53:34FromGitter<Quelklef> It's new information, and it's similar, but it doesn't change anything
18:53:42FromGitter<Quelklef> unless I'm not understanding something ...?
18:53:47FromGitter<kayabaNerve> Your argument is irrelevant; you should become a real Nim dev and that means memorizing #7449.
18:53:53FromGitter<Quelklef> boi
18:53:55FromGitter<kayabaNerve> No, Im just effing around.
18:54:03FromGitter<Quelklef> yeah i got that after the second message :P
19:03:18*yglukhov[i] joined #nim
19:03:18*yglukhov_ quit (Read error: Connection reset by peer)
19:05:36FromGitter<mratsim> I’ll give you a tip, the more you clog the bug tracker with your issues, the easier it is to remember what is there
19:05:43FromGitter<mratsim> proof: https://github.com/nim-lang/Nim/issues/8448
19:06:10*CcxWrk quit (Quit: ZNC 1.7.1 - https://znc.in)
19:07:10*CcxWrk joined #nim
19:07:49FromGitter<Quelklef> Speaking of which, there are 56 pages of bugs
19:08:21FromGitter<Quelklef> when I saw that I was really compelled to just go through them, oldest to newest, test them on the latest devel branch, and close them if they're fixed by now
19:09:46FromGitter<Quelklef> but I can't close things, so the best I could do is post a "this is
19:09:56*CcxWrk quit (Excess Flood)
19:09:56FromGitter<Quelklef> fixed" comment, which I'm not sure if would be helpful or annoying
19:10:34FromGitter<Quelklef> For instance, https://github.com/nim-lang/Nim/issues/6185 is fixed
19:11:00FromGitter<rayman22201> The github issue tracker could use a good cleaning... It probably needs a person with admin privileges though...
19:11:29*yglukhov[i] quit (Ping timeout: 248 seconds)
19:11:35FromGitter<Quelklef> Yeah
19:12:12*yglukhov[i] joined #nim
19:15:02dom96hmmm, should Option.get return a `var T`?
19:15:14FromGitter<Quelklef> Option.mget?
19:17:05Araqyeah, mget it
19:20:04*icebattle joined #nim
19:20:06dom96there is no `mget` for option
19:20:57*yglukhov[i] quit (Ping timeout: 240 seconds)
19:21:33*ldlework pulls open his coat.
19:21:40ldleworkI heard you're lookin for some Monads?
19:21:47FromGitter<Quelklef> oh no
19:22:29ldlework(the shady pawn-dealer coat-opening, not the naked-flasher kind)
19:22:31ldleworklol
19:22:35FromGitter<Quelklef> oh no
19:22:57*yglukhov[i] joined #nim
19:23:29*Trustable quit (Remote host closed the connection)
19:33:52*stefanos82 quit (Quit: Quitting for now...)
19:34:45*Vladar quit (Quit: Leaving)
19:37:44*yglukhov_ joined #nim
19:41:27*yglukhov[i] quit (Ping timeout: 240 seconds)
19:44:57*icebattle quit (Ping timeout: 244 seconds)
19:47:58*vivus quit (Quit: Leaving)
19:49:09*krux02 quit (Ping timeout: 265 seconds)
19:58:31*rockcavera joined #nim
20:01:07*krux02 joined #nim
20:01:50*icebattle joined #nim
20:04:32*d10n-work quit (Quit: Connection closed for inactivity)
20:10:31FromGitter<Varriount> @Quelklef I'll probably go through them today.
20:10:42FromGitter<Varriount> I've gotten into the habit of checking all recently updated issues.
20:11:12FromGitter<Quelklef> I mean, the recently updated ones aren't the point
20:11:20FromGitter<Quelklef> That sounds like a good habit though
20:11:38FromGitter<Varriount> I mean, if you commented on those issues, they will be marked as updated.
20:12:07FromGitter<Quelklef> Ah
20:12:08FromGitter<Quelklef> hm
20:12:26*geocar joined #nim
20:12:29FromGitter<Quelklef> I'd do it, but I'd want official permission before I pull shenanigans of this size
20:13:01FromGitter<Quelklef> @Araq @dom96 OK for me to bump (many) (very old) now-resolved issues so they can be closed?
20:14:03FromGitter<Varriount> Or you could give us a list.
20:14:14FromGitter<Quelklef> y'know
20:14:23FromGitter<Quelklef> some day I hope to be as smart as you are, Varriount
20:30:08FromGitter<Quelklef> What is the showstopper label?
20:34:05*Ven`` joined #nim
20:41:47*icebattle quit (Ping timeout: 244 seconds)
20:47:29*Ven`` quit (Ping timeout: 248 seconds)
20:48:56*yglukhov_ quit (Read error: Connection reset by peer)
20:49:31*yglukhov[i] joined #nim
20:53:02*cryptocat1094 quit (Quit: WeeChat 2.2)
20:54:07*noonien quit (Quit: Connection closed for inactivity)
21:30:25*Jesin joined #nim
21:51:19*yglukhov_ joined #nim
21:52:18*yglukhov[i] quit (Ping timeout: 256 seconds)
21:54:19*NimBot joined #nim
21:55:48*yglukhov_ quit (Read error: Connection reset by peer)
21:56:24*yglukhov[i] joined #nim
22:07:04*icebattle joined #nim
22:32:35FromGitter<gogolxdong> [] -> rawGet -> extractSlice-> x[pos]
22:47:06*yglukhov[i] quit (Read error: Connection reset by peer)
22:47:43*yglukhov[i] joined #nim
22:51:04FromGitter<gogolxdong> sorry ,it's `[]=` -> add -> newJstring -> newBody -> storeAtom -> buf: var seq[byte]
22:51:20FromGitter<Quelklef> ??
22:53:05*icebattle quit (Ping timeout: 240 seconds)
22:57:05*yglukhov[i] quit (Ping timeout: 240 seconds)
23:03:43*yglukhov[i] joined #nim
23:03:46FromGitter<gogolxdong> packedjson issue.
23:03:59*yglukhov[i] quit (Remote host closed the connection)
23:08:28FromGitter<gogolxdong> ```code paste, see link``` ⏎ ⏎ doesn't [https://gitter.im/nim-lang/Nim?at=5b5a546ca31e386158b4ded0]
23:11:29*CcxWrk joined #nim
23:16:25*xet7 quit (Quit: Leaving)
23:20:18FromGitter<Varriount> Don't use typed and untyped in procedures. Those are meant for use in templates and macros only.
23:20:47FromGitter<Quelklef> he didn't
23:25:40*icebattle joined #nim
23:39:32zacharycarter[m]yglukhov: are you around by any chance? or anyone else that has used / knows jsbind?
23:43:59zacharycarter[m]I'm curious how you would bind an event handler and then later remove it with the whole jsRef / Unref thing
23:44:09zacharycarter[m]my event handlers are attaching fine - but not being removed