<< 03-10-2019 >>
00:04:05shashlickHow do you know it is not
00:04:26disruptekmy benchmark
00:11:56disruptekwhat's crazy is, the release and danger defines are, uh, defined. but the code runs as if it's debug. i guess it doesn't toggle the checks?
00:57:12FromGitter<dawkot> Is `typedesc` different than `type`? I've been able to make the compiler stop complaining by using `type` everywhere instead of the other one
00:57:43disruptekuse `typedesc` for a type description. where are you using `type`?
01:01:15*owl_000 joined #nim
01:41:45FromGitter<nepeckman> When the JSON docs say "Sets in object variants are not supported" does it mean HashSets aren't supported? Or does it mean the set of fields unique to each variant?
01:44:49leorizethat means it doesn't support Nim's set[T]
01:44:56disruptekto() pukes on most stuff.
01:45:52FromGitter<nepeckman> Gotcha that's what I thought. Having an issue where object variant branches aren't getting set when marshalling from JSON
01:46:04FromGitter<nepeckman> Wanted to know if it was intended or a bug
01:46:43disruptekthere's some noise about rewriting to() but it's not done yet.
01:47:14disruptekdoesn't help that variants got a little tighter a few months ago, too.
01:49:31FromGitter<nepeckman> Ah I see. Thanks for the info!
01:56:05rayman22201weird question, does anybody have a version of Windows older than windows 10?
01:57:03rayman22201tests\async\tasyncclosestall.nim is suddenly failing for me on Windows 10 (even on a fresh devel)... I'm wondering if the windows socket behavior has changed.
01:57:39*ng0_ joined #nim
01:58:52disruptekwhat does the ci say?
01:59:16rayman22201I'm running the test locally
01:59:36*ng0 quit (Ping timeout: 260 seconds)
01:59:45disrupteki mean, doesn't ci run on a windows platform?
01:59:46FromGitter<timotheecour> @rayman22201 u pinged me
02:00:19rayman22201@disruptek, yeah, but it might be an older Windows version (probably is.)
02:00:34rayman22201@timotheecour. I have questions for you on github :-)
02:01:13FromGitter<timotheecour> ya i saw that, happy to chat might be more efficient (eg 1 1 chat , did u see my msg)
02:02:27rayman22201sorry I didn't see any pms
02:02:44rayman22201oh, you are on gitter that's why. I'm on irc
02:03:02rayman22201I will go on gitter. hold on
02:05:27rayman22201hrmm. not sure if it's just my machine. I guess I will push to the CI and see
02:21:59*actuallybatman quit (Ping timeout: 276 seconds)
02:41:20disruptekMaximum number of descriptors is exhausted!
02:54:39*dddddd quit (Remote host closed the connection)
02:58:30*owl_000 quit (Ping timeout: 265 seconds)
03:12:02*lritter quit (Ping timeout: 240 seconds)
03:13:04*lritter joined #nim
03:14:57*sealmove joined #nim
03:18:09*rockcavera quit (Remote host closed the connection)
03:27:33*thomasross_ joined #nim
03:27:33*thomasross is now known as Guest73787
03:27:33*Guest73787 quit (Killed (card.freenode.net (Nickname regained by services)))
03:27:33*thomasross_ is now known as thomasross
03:49:53*chemist69 quit (Ping timeout: 245 seconds)
03:52:01*chemist69 joined #nim
03:57:18*nixfreak joined #nim
03:58:09nixfreakSince I can cross compile to windows now , I was wondering if nim has a gui library for creating apps that will compile and run on windows also?
04:07:16*nixfreak quit (Quit: WeeChat 2.5)
04:10:28*nixfreak joined #nim
04:17:11*shashlick quit (Remote host closed the connection)
04:17:33*shashlick joined #nim
04:25:57*thomasross quit (Ping timeout: 240 seconds)
04:30:28*thomasross joined #nim
04:44:17nixfreakjust learning this language, but when I run the example for the tut1 for the if statement I get an error if.nim(8, 21) Error: attempting to call routine: 'name'
04:44:20nixfreak found 'name' of kind 'let'
04:44:45nixfreakis that not supposed to compile , is it only an example ?
04:46:08*LargeEpsilon joined #nim
04:46:27nixfreaknm I was missing a comma
04:51:31FromGitter<Varriount> Anyone know what the backport notation does in GitHub?
04:52:12*nsf joined #nim
04:53:03rayman22201It's just used to help remind the core team what needs to be backported to the 1.0 branch
05:06:51FromDiscord<Rika> i feel like arraymancer is overkill for me as i only need `Vec2`s
05:06:56FromDiscord<Rika> is it?
05:16:50nixfreakgetting module can't import itself? http://dpaste.com/1FRB0NE
05:18:11nixfreakdoes strutils have parseInt
05:22:39*narimiran joined #nim
05:24:51sealmovehttps://nim-lang.org/docs/strutils.html#parseInt%2Cstring
05:25:38nixfreakso the tut is wrong ?
05:26:35sealmovehaven't used `from X import Y`
05:27:01sealmovew8
05:28:06sealmoveohhh
05:28:11sealmovethe problem is your file name
05:28:22sealmoveyou named it strutils.nim, so compiler gets confused
05:28:38sealmovethe error message is quite clear "can't import itself"
05:28:46nixfreakoh interesting
05:29:02nixfreakok thanks
05:29:43sealmovenp
05:30:54*owl_000 joined #nim
05:48:50*LargeEpsilon quit (Ping timeout: 240 seconds)
05:51:51*navinmistry joined #nim
05:52:08AraqVarriount: it means the fix will be backported to produce 1.0.2
05:52:24*thomasross_ joined #nim
05:52:25*thomasross is now known as Guest44331
05:52:25*thomasross_ is now known as thomasross
05:52:44*Guest44331 quit (Read error: Connection reset by peer)
06:00:55skrylar[m]the threading issue is something i have a pin on wrt. that bmessage stuff
06:01:22skrylar[m]have been waiting to finish other things before deciding how to implement those parts
06:03:05*lritter quit (Ping timeout: 246 seconds)
06:06:50*LargeEpsilon joined #nim
06:08:35*LargeEpsilon_ joined #nim
06:09:11*owl_000 quit (Remote host closed the connection)
06:12:07*LargeEpsilon quit (Ping timeout: 245 seconds)
06:14:28*solitudesf- joined #nim
06:26:02*skoude joined #nim
06:40:15*navinmistry quit (Remote host closed the connection)
06:43:47*thomasross quit (Ping timeout: 245 seconds)
06:51:02*thomasross joined #nim
06:52:52*solitudesf- quit (Quit: Leaving)
06:53:09*solitudesf joined #nim
06:56:41FromDiscord<mratsim> @Rika, yes if you want vectors/matrix for graphics, look into nim-glm or opengl-sandbox
06:57:07FromDiscord<Rika> Okay
06:57:09FromDiscord<mratsim> Arraymancer is focused on numerical/scientific computing
06:57:13FromDiscord<Rika> Thanks
06:57:53FromDiscord<Rika> Oh that's perfect
06:57:55*PMunch joined #nim
07:00:00*gmpreussner quit (Quit: kthxbye)
07:02:09*navinmistry joined #nim
07:02:22FromDiscord<mratsim> btw @krux02, is it normal to see a "This content is not available" with rotating thingies in onpengl-sandbox readme? https://github.com/krux02/opengl-sandbox#examples
07:04:56*gmpreussner joined #nim
07:05:08*navinmistry quit (Remote host closed the connection)
07:05:30*navinmistry joined #nim
07:06:21*navinmis_ joined #nim
07:09:37*navinmistry quit (Ping timeout: 245 seconds)
07:11:43*navinmis_ quit (Remote host closed the connection)
07:12:56*navinmistry joined #nim
07:13:38*navinmis_ joined #nim
07:13:52*Vladar joined #nim
07:15:13*navinmis_ quit (Remote host closed the connection)
07:16:14*navinmis_ joined #nim
07:17:27*navinmistry quit (Ping timeout: 264 seconds)
07:20:31*navinmis_ quit (Remote host closed the connection)
07:25:18*thomasross_ joined #nim
07:25:18*thomasross is now known as Guest66011
07:25:18*thomasross_ is now known as thomasross
07:26:17*Guest66011 quit (Ping timeout: 240 seconds)
07:31:23*skoude quit (Ping timeout: 276 seconds)
07:31:25*floppydh joined #nim
07:35:57*navinmistry joined #nim
07:40:27*navinmistry quit (Ping timeout: 245 seconds)
07:48:31leorizerayman22201: that tests fail all the time in azure pipelines
07:49:24leorizeI've tested against both windows 10 1607 and 1809 on azure
07:49:31leorizenever managed to reproduce it locally though
07:51:17*skoude joined #nim
07:51:50*navinmistry joined #nim
07:57:27*thomz joined #nim
07:59:01*thomz quit (Client Quit)
07:59:17*thomz joined #nim
07:59:27*navinmistry quit (Remote host closed the connection)
08:07:21*skoude quit (Ping timeout: 265 seconds)
08:10:22*asymptotically joined #nim
08:11:01*BigEpsilon joined #nim
08:15:03*LargeEpsilon_ quit (Ping timeout: 264 seconds)
08:16:29*fanta1 joined #nim
08:20:55*skoude joined #nim
08:25:16*skoude quit (Ping timeout: 240 seconds)
08:26:37sealmoveeh I can't solve this...
08:33:04*fanta1 quit (Quit: fanta1)
08:38:01FromDiscord<Rika> what's wrong?
08:39:44*skoude joined #nim
08:41:24*Ven`` joined #nim
08:43:18*BigEpsilon quit (Quit: Leaving)
08:43:34*LargeEpsilon joined #nim
08:43:41*Ven`` quit (Client Quit)
08:44:12*skoude quit (Ping timeout: 245 seconds)
08:44:54*navinmistry joined #nim
08:49:40*fanta1 joined #nim
08:49:59*navinmistry quit (Remote host closed the connection)
08:51:06*navinmistry joined #nim
08:51:55*clyybber joined #nim
08:57:08*skoude joined #nim
09:07:51*asymptotically quit (Remote host closed the connection)
09:08:12*asymptotically joined #nim
09:09:35sealmoveRika: I get segfault when closing stream
09:09:41sealmoveworks fine if I don't close it
09:12:44PMunchHmm, that sounds familiar sealmove
09:14:07FromGitter<alehander42> you need to debug that
09:14:16FromGitter<alehander42> compile with debug symbols and see where exactly is it segfaulting
09:15:17*thomasross quit (Ping timeout: 240 seconds)
09:16:04sealmovemanaged to reduce it to this: https://play.nim-lang.org/#ix=1XqO
09:17:56sealmoveit segfaults at lib/pure/streams.nim(1127) fsReadData
09:18:19*thomz quit (Quit: Going offline, see ya! (www.adiirc.com))
09:18:54sealmoveI think it freaks out because it's a closure
09:19:02FromGitter<alehander42> well
09:19:05FromGitter<alehander42> you close the stream
09:19:08FromGitter<alehander42> before you use it
09:19:16*LargeEpsilon_ joined #nim
09:19:20sealmoveoh hmm...
09:19:47sealmoveseems right xD I feel stupid
09:19:48FromGitter<alehander42> we do need a better way to ensure closing indeed
09:20:05FromGitter<alehander42> no, its easy to make a mistake like that: i also didnt see it for long time
09:20:12sealmoveyeah, in my case I don't know where to put `close(stream)`
09:20:23clyybberStill it should crash on the last line, not on close
09:20:27clyybberAFAICT
09:20:51FromGitter<alehander42> hm, probably indeed
09:20:52*thomasross joined #nim
09:20:57clyybberAnd this: https://play.nim-lang.org/#ix=1XqR shouldn't crash at all
09:21:30FromGitter<alehander42> but i am not sure: basically you need to close whenever x() can't be accessed anymore which means after y is not accessible
09:21:39FromGitter<alehander42> so it does seem like a destructor/finalizer thing
09:21:51*shomodj joined #nim
09:22:32*LargeEpsilon quit (Ping timeout: 245 seconds)
09:22:54sealmoveI need a destructor indeed
09:23:10sealmoveWas considering it a few days ago, but thought I could avoid it
09:23:22sealmoveBut now with these closures... there is no avoiding it
09:23:23clyybberThis example https://play.nim-lang.org/#ix=1XqT doesn't access it afterwards though.
09:23:26clyybberAnd it still crashes
09:24:01*BigEpsilon joined #nim
09:24:11sealmoveclyybber: it doesn't crash for me
09:24:31*fanta1 quit (Max SendQ exceeded)
09:25:00clyybberUh, so maybe its a nim playground thing
09:25:08sealmoveI mean, you need a file
09:25:10clyybberBecause this: https://play.nim-lang.org/#ix=1XqU crashes in playground
09:25:29clyybbersealmove: Yeah, but it should raise some IO error when there isn't one right? Not segfault
09:25:52*skoude quit (Ping timeout: 245 seconds)
09:26:13clyybberCrashes on my PC too.
09:26:31FromGitter<alehander42> we should use openFileStream
09:26:37FromGitter<alehander42> that's what written in the docs
09:26:44FromGitter<alehander42> otherwise the other one reurns nil
09:26:53FromGitter<alehander42> one thing that the compiler would catch with the new nil handling
09:26:55FromGitter<alehander42> :P
09:27:18clyybberOh, well. Good to know :D
09:27:28clyybberAnd so the mystery was solved..
09:27:32*LargeEpsilon_ quit (Ping timeout: 245 seconds)
09:27:44sealmoveI still don't get it
09:28:06*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:28:14FromGitter<alehander42> of course, if we annotate close to take not nil
09:28:18*navinmistry quit ()
09:28:23clyybbersealmove: stream is nil, so close causes a segfault
09:28:27FromGitter<alehander42> newFileStream returns nil
09:28:29FromGitter<alehander42> on error
09:28:34FromGitter<alehander42> use openFileStream
09:28:43FromGitter<alehander42> if you want to directly get an exc
09:28:59FromGitter<alehander42> which reminds me .. we still need `not nil` Araq ?
09:29:04FromGitter<alehander42> i mean, the keyword
09:29:30sealmoveso basically clyybber it crashes on your PC because you link a file that can't be opened, because it works fine on mine.
09:29:38clyybberYeah
09:29:38FromGitter<alehander42> because, if i get from third party code a ref type defined as nilable, i still want to be able to say `a(b: Stream not nil)`
09:29:39*thomz joined #nim
09:29:56FromGitter<alehander42> maybe `!Stream`
09:30:12clyybberalehander42: I thought the plan was to make not nil the default?
09:30:20FromGitter<alehander42> yes, but thats the point
09:30:23FromGitter<alehander42> you can still define
09:30:48FromGitter<alehander42> type A = nil InternalObject
09:30:51sealmoveso how do I make a destructor?
09:31:14FromGitter<alehander42> and the user code might need to turn A again into not nil in a param
09:31:19clyybberalehander42: I see.
09:31:33clyybbersealmove: overload `=destroy`
09:31:42sealmovethx
09:31:42FromDiscord<djazz> Nim in Action book finally arrived! Manning shipped with FedEx and it was a hassle to get it (had to sit outside apartment at 7 °C for over an hour, because the previous attempts to deliver failed)
09:31:49FromGitter<alehander42> like in this case: close(stream: Stream not nil) ?
09:32:03FromDiscord<djazz> https://cdn.discordapp.com/attachments/309979210997301249/629243889898749980/DSC_1372.JPG
09:32:41clyybberalehander42: So what is the rule then? No ref in Stream must be nil?
09:33:05FromGitter<alehander42> no, i mean
09:33:31FromGitter<alehander42> if Stream is defined as nilable in the type section
09:33:35*shomodj joined #nim
09:33:50clyybberalehander42: Ah nevermind, yeah.
09:33:56FromGitter<alehander42> close should still get a not nil version
09:34:14FromGitter<alehander42> which would require somebody somehow to have done .isNil check somewhere
09:34:48clyybberalehander42: I think an explicit 'not nil' annotation should stay and overwrite 'nil ref'
09:35:16clyybberalehander42: close should not have a 'nil ref' version
09:35:21FromGitter<alehander42> on the other hand, close itself could of course get a nilable and the compiler will tell you to add if not s.isNil inside
09:35:35FromGitter<alehander42> but i think one shouldn't call close succesfully on nil stream
09:35:38*skoude joined #nim
09:35:54FromGitter<alehander42> yes indee
09:36:15FromGitter<alehander42> so we just need both, with implicit not nil as default
09:36:32clyybberYeah.
09:36:43FromGitter<alehander42> and i would hope the syntax is similar
09:36:43clyybberNow the syntax is the question that remains
09:36:56clyybberWhen not nil is to stay, I would vote for nil ref
09:37:08FromGitter<alehander42> e.g. `nil A` and `notnil A` or `may A` and `notnil A` or `?A` `!A`
09:37:09sealmoveif I overload `=destroy`... am I overriding stuff? I mean if you have a complex type, proc `=destroy(x: MyType)` = close(x.stream) is correct?
09:37:30FromGitter<alehander42> i agree `!` might be confusing ?
09:38:11livcdnixfreak: wNim
09:38:57clyybbersealmove: You still need to free x, I think.
09:40:02*skoude quit (Ping timeout: 245 seconds)
09:40:35clyybberalehande42: Or `may ref` and `must ref`. Though that doesn't read so nice with non ref.
09:41:15clyybberI think `nil A` and `notnil A` is the best option.
09:43:44sealmovewhere is free() declareD?
09:46:17clyybbersealmove: I don't know. But wouldn't it be a better approach to just pass a stream to myProc2
09:47:43sealmoveI am making an API and I don't want to expose the underlying stream to the end-user
09:48:10sealmovehe will use a proc, with a filepath argument, and get back an object
09:48:16*ng0_ is now known as ng0
09:49:19sealmoveanyway I think GC takes care of free()...
09:49:30sealmoveeven when you overload `=destroy`
09:54:47*skoude joined #nim
09:55:30*fanta1 joined #nim
10:01:21*thomz quit (Quit: Going offline, see ya! (www.adiirc.com))
10:06:55*Hideki_ joined #nim
10:11:58*LargeEpsilon_ joined #nim
10:15:34*LargeEpsilon joined #nim
10:15:50*BigEpsilon quit (Ping timeout: 276 seconds)
10:18:57*LargeEpsilon_ quit (Ping timeout: 268 seconds)
10:19:32FromDiscord<Kiloneie> @djazz nice setup
10:23:01*couven92 joined #nim
10:23:46*ng0 quit (Quit: Alexa, when is the end of world?)
10:27:20*abm joined #nim
10:27:36*skoude quit (Ping timeout: 240 seconds)
10:32:29*skoude joined #nim
10:34:37*shomodj quit (Remote host closed the connection)
10:34:50*shomodj joined #nim
10:34:56FromDiscord<Kiloneie> Can someone explain to me why aS won't work, or why the compiler/VS Code thinks it's a keyword ?...
10:34:56FromDiscord<Kiloneie> https://cdn.discordapp.com/attachments/371759389889003532/629265117854433280/what.png
10:35:14narimiranbecause `aS` == `as` in nim
10:35:25FromDiscord<Kiloneie> oh...
10:35:34FromDiscord<Kiloneie> and it's not case sensitive
10:35:38FromDiscord<Kiloneie> welp D:
10:36:14FromDiscord<djazz> @Kiloneie thats in my bookshelf heh
10:36:39FromDiscord<juan_carlos> Try to use descriptive variable names if possible. :)
10:37:05FromDiscord<Kiloneie> yeh... sometimes i forget
10:37:11*skoude quit (Ping timeout: 265 seconds)
10:37:15FromDiscord<Kiloneie> last video was more of a ... mehh....
10:37:34FromDiscord<Kiloneie> Was trying something new and kinda messed up
10:37:57FromDiscord<Kiloneie> @djazz i don't even have a book shelf D:
10:38:39FromDiscord<djazz> Aww. I have two bookcases in my reading corner :3
10:39:33FromDiscord<Kiloneie> I don't read O,O... books...
10:39:40FromDiscord<Kiloneie> i am wired to my computer xD
10:40:00FromDiscord<djazz>
10:40:00FromDiscord<djazz> https://cdn.discordapp.com/attachments/371759389889003532/629266387885621248/DSC_1082.JPG
10:40:17FromDiscord<djazz> I do love ebooks too
10:40:33FromDiscord<Kiloneie> Nice
10:41:16FromDiscord<Rika> does nim in action have an ebook equiv.
10:42:31narimiranNiA has an ebook version IIRC
10:42:52FromDiscord<Kiloneie> in PDF, kindle format, and the website which is the most functional one
10:43:04FromDiscord<Kiloneie> still haven't full read it
10:43:20*skoude joined #nim
10:43:38FromDiscord<Kiloneie> got to chapter 5 and a half, then went to metaprogramming xD, jumping all over.
10:45:57*thomasross quit (Ping timeout: 240 seconds)
10:47:40*thomasross joined #nim
10:48:10FromDiscord<Rika> nice
10:48:11*thomz joined #nim
10:54:13clyybbersealmove: Might make sense then to store the stream inside the object?
10:55:42sealmoveclyybber: yeah, this is the solution I came up with
10:55:49FromDiscord<djazz> The epub of NiA is converted from the kindle format. It's lacking a bit
10:55:54sealmovewhich is typical in other languages too
10:56:06FromDiscord<djazz> But its drm free so i can fix it myself (add monospaced fonts etc)
10:56:47*LargeEpsilon quit (Ping timeout: 276 seconds)
10:58:26*fanta1 quit (Quit: fanta1)
11:00:48FromDiscord<Kiloneie> best experience is from the website, so you can experiment with the code as well.
11:01:45FromDiscord<djazz> Yea
11:13:50*skoude quit (Ping timeout: 268 seconds)
11:13:57FromGitter<alehander42> clybber i like `?A` still
11:14:11FromGitter<alehander42> but i am not sure how those discussions are resolved i admit
11:14:39FromGitter<alehander42> i guess one of the "core team decides" / "some kind natural agreement between all" / "community votin"
11:16:33FromDiscord<juan_carlos> Agile Coin Flip :P
11:22:28*ng0 joined #nim
11:22:49*dddddd joined #nim
11:25:23clyybberalehander42: We argue till everybody thinks the same :p
11:26:13*skoude joined #nim
11:26:24clyybberalehander42: IMO '?' or '!' feel out of place in type sections. So far we never used punctuation operators in Nim.
11:26:34clyybbers/ in Nim/ in typesections in Nim
11:27:12FromGitter<alehander42> but i expect most of their usage
11:27:16FromGitter<alehander42> to be not in type sections
11:27:22FromGitter<alehander42> but in functions
11:27:39clyybberYeah, but its such a tiny char, it may be easy to oversee
11:27:58clyybber* overlook
11:28:10FromGitter<alehander42> well, you can say this for all other chars
11:28:24FromGitter<alehander42> :D
11:28:33FromGitter<alehander42> i think its much bigger than `:`
11:28:43FromGitter<alehander42> or `*`
11:28:55*LargeEpsilon joined #nim
11:29:24clyybberHmm, well yeah. That argument falls flat. Lets try another one: It feels more inline with other ref modifiers such as owned
11:29:29clyybberOr var
11:29:32clyybberOr static
11:29:50FromGitter<alehander42> probably
11:30:07clyybberSo in a sense it feels more Nim-like
11:30:08FromGitter<alehander42> i agree there is argument that it's more nim/python-like
11:30:35FromGitter<alehander42> but on the other hand custom operators are also nim-like
11:31:11clyybberotoh no operator currently operatoes on types afaik
11:31:31clyybbers/toes/tes
11:31:38clyybberno toes here
11:31:42FromGitter<alehander42> if you put `/` in front
11:31:49FromGitter<alehander42> it will autofix it in gitter and iirc discord
11:32:02FromGitter<alehander42> /s/toes/tes
11:32:09FromGitter<alehander42> /s/tes/te
11:32:12FromGitter<alehander42> hm
11:32:12FromDiscord<Rika> autofix?
11:32:17FromGitter<alehander42> i forgot how it works
11:32:23clyybberDiscord does it without preceeding /
11:32:28FromGitter<alehander42> no its on th eend
11:32:33FromGitter<alehander42> s/end/eend
11:32:41FromDiscord<Rika> what
11:32:41FromGitter<alehander42> yep
11:32:46clyybbers/it/itt/
11:32:48FromGitter<alehander42> `s/typ/typo/`
11:32:55clyybberlol
11:32:56FromGitter<alehander42> would replace typ with typo
11:32:59FromGitter<alehander42> in your previous message
11:33:10clyybberYeah, doesn't work from irc tho
11:33:18FromGitter<alehander42> probably
11:33:21clyybberBecause the bot appends From IRC
11:33:23FromDiscord<Rika> and discord is bridging gitter via irc
11:33:24FromGitter<alehander42> yep
11:33:29FromGitter<alehander42> no i think because
11:33:33FromGitter<alehander42> it appends <clyybber>
11:33:34*skoude quit (Ping timeout: 268 seconds)
11:33:44clyybberalehander42: Ah, yeah ur right
11:34:19FromGitter<alehander42> but i thought about a bot that generates similar text diffs from discord ui edits
11:34:53*thomz quit (Quit: Going offline, see ya! (www.adiirc.com))
11:39:16ZevvCan someone explain in one or two sentenes what the typical procedure is to add magic to the compiler? I'd like to see if I can add some time function to allow for compile time profiling, do I really need to at a TOpcode?
11:39:16clyybberThat would be cool indeed
11:39:59clyybberIf it should work at compile time yes afaik
11:40:44Zevvok, then I'll figure it out, thanks
11:40:55*fanta1 joined #nim
11:41:04*rockcavera joined #nim
11:41:48FromGitter<alehander42> i'd immitate optEcho
11:41:53FromGitter<alehander42> opcEcho *
11:42:03Zevvyeah or slurp or gorge
11:42:19Zevvbut trying to follow writeFile now, that seems to be different
11:43:13*skoude joined #nim
11:46:42FromGitter<alehander42> i cant understand how it works in vm
11:49:33Zevvhaha same here
11:49:39Zevvbut today is the day I will finally go there
11:51:10*thomasross quit (Read error: Connection reset by peer)
11:51:24*thomasross joined #nim
11:54:10FromGitter<alehander42> btw can nim vm + vm experimetnal ffi be used for repl
11:54:32FromGitter<alehander42> iirc the old `nim secret` wasnt liked because of no support for code depending on ffi?
11:54:46FromGitter<alehander42> and the lack of normal repl niceties
11:56:15Zevvwell that was easy
11:56:43*fanta1 quit (Quit: fanta1)
11:59:28*solitudesf quit (Ping timeout: 268 seconds)
12:12:09PMunchHmm, channels in Nim, what safeties do they offer? Can you have multiple senders? Multiple receivers?
12:13:44*Kaivo joined #nim
12:20:47ZevvNoooooo! I missed PR #12345 by 1 :(
12:21:07Zevvdamn you clyybber!
12:21:23PMunchOuch, what is the next milestone?
12:21:29PMunch#13000 I guess
12:21:49narimiran#12421 ?
12:22:10PMunchOh right, yeah that's a cool one
12:22:24narimiran#12358
12:22:50narimiran(fibonacci)
12:23:01PMunchOf course..
12:23:16PMunchCouple of primes in there as well
12:23:22PMunchAlthough those are not that obvious
12:23:26FromGitter<alehander42> ix.io/1XrE/md
12:24:06FromGitter<alehander42> i'd imagine something like that
12:24:08*LargeEpsilon quit (Ping timeout: 268 seconds)
12:25:27FromDiscord<mratsim> @alehander42, the bridge that we use for Gitter<->Discord for Status channels allow editing and discord code-pasting ==> Gitter
12:26:27*skoude quit (Ping timeout: 264 seconds)
12:26:38FromGitter<alehander42> yes, this is pretty good
12:27:05FromGitter<alehander42> the code-pasting is uploaded to a link?
12:27:07FromGitter<alehander42> but with your bridge edited message are also reposted
12:27:17FromGitter<alehander42> which is the thing i'd fix if i write a bridge
12:27:21FromGitter<alehander42> or tweak one
12:28:16*daddoo joined #nim
12:28:16*daddoo quit (Changing host)
12:28:16*daddoo joined #nim
12:29:29PMunchHow do you really fix that though?
12:29:42PMunchAt least with IRC it's not really possible to do in a good way I think..
12:31:39FromGitter<alehander42> i think you just
12:31:45FromGitter<alehander42> generate a "diff"
12:31:49FromGitter<alehander42> e.g. you changed the word
12:32:11FromGitter<alehander42> "help me with this code" ⏎ to ⏎ "help me with this code here"
12:32:20FromGitter<alehander42> we dont repost the whole paragraph
12:32:31FromGitter<alehander42> just post "this code here*"
12:32:33*thomz joined #nim
12:32:40FromGitter<alehander42> or "this code => this code here*"
12:33:14clyybberZevv: lol, didn't even notice it :p
12:35:17FromGitter<alehander42> btw PMunch, can i also get on the devroom mailing list
12:35:21FromGitter<alehander42> or is it only for organizers
12:36:40PMunchIt is for organisers, but I think the term is applied loosely :P
12:37:44PMunchalehander42, and yeah I guess something like that would be possible, but you have some weird edge cases where they change two things for example
12:42:05FromGitter<alehander42> PMunch, i wonder if i should try for a small talk, but with only 1-2-3 nim talks, we need only the top stuff
12:42:26FromGitter<alehander42> so i thought about helping with org, but with the minimalistic room staff, there are enough people
12:42:34FromGitter<alehander42> so i'll be just a visitor in this case :P
12:42:43FromGitter<alehander42> yeah, i guess in some cases thats true
12:42:51FromGitter<alehander42> but most edits are small maybe
12:43:25PMunchYou still need to not fail drastically when those cases kick in though :P
12:44:48PMunchI talked to the minimalistic guys today, apparently they want to stick with many 15-20 minutes talks (which I agree is a good idea) and not do any formal split between the topics (might be good or bad, depending on what they find interesting).
12:45:02PMunchSo potentially we could have lots of Nim talks :)
12:50:43*actuallybatman joined #nim
12:52:03FromGitter<alehander42> i have an idea to demonstrate my small lang building dsl idea as a talk
12:52:49FromGitter<alehander42> but probably people will show me 3 different ways this already works in the racket ide
12:53:35FromGitter<alehander42> i'd love to hear a talk about generic programming in Nim
12:54:38*skoude joined #nim
12:55:02ZevvMan we're not sharing a room with these Lua dorks and the like, right
12:56:21FromGitter<alehander42> they did have their own devroom several times
12:56:23FromGitter<alehander42> so maybe not?
12:57:26Zevvhehe
12:57:58PMunchLua dorks?
12:58:18PMunchWe're sharing with what was the "Minimalistic languages" devroom from last year
12:58:44PMunchThey haven't had a room before that
12:59:02FromDiscord<mratsim> @alehander: you can just show npeg 😛
12:59:03*skoude quit (Ping timeout: 245 seconds)
12:59:22FromDiscord<mratsim> on a brainfuck compiler
13:00:29*clyybber quit (Quit: WeeChat 2.6)
13:00:43FromDiscord<mratsim> Generic programming, what kind? Arraymancer is generic only (and that's an issue because if you don't instantiate the proc, you're not sure they compile, *hint @narimiran testament tests*).
13:01:00narimiran:P
13:08:37FromGitter<alehander42> mratsim but npeg is zevv's
13:08:44FromGitter<alehander42> he can show it
13:08:59FromGitter<alehander42> zevv, show it
13:09:16FromGitter<alehander42> mratsim there are much more interesting examples than brainfuck imo :P
13:09:34*fanta1 joined #nim
13:10:49FromGitter<alehander42> i think people over think "language tut = parser" which is like 5% of it
13:10:58Zevvshow what
13:11:13FromGitter<alehander42> but i also think "machine learning = some matrices" so i am worse at this
13:11:26FromGitter<alehander42> zevv, show npeg
13:12:15FromGitter<alehander42> mratsim i thought it would be renamed , well all kinds of interesting generic libs, e.g. nim science libs or some of the status stream/serialization libs etc
13:12:20Zevvmwah
13:13:16PMunchHmm, so an iterator can't be sent over a channel, even if it's sent and read from the same thread..
13:19:00FromGitter<alehander42> what is verbosePass
13:19:40FromGitter<alehander42> hm, it seems it just prints verbosity info
13:19:41FromGitter<alehander42> ok
13:21:25FromDiscord<mratsim> what would be renamed?
13:21:51FromDiscord<mratsim> Arraymancer? Yes it's still planned. I can't say "when Nim 1.0 is released" anymore though :p
13:22:34FromGitter<alehander42> awesome
13:22:43Mister_Magister!eval
13:22:50FromGitter<alehander42> yeah, araq delivered, now you
13:22:56Mister_Magisterhow was this working again
13:23:02FromGitter<alehander42> !eval 2
13:23:04NimBotCompile failed: /usercode/in.nim(1, 1) Error: expression '2' is of type 'int literal(2)' and has to be discarded
13:23:16Mister_Magister!eval something
13:23:18NimBotCompile failed: /usercode/in.nim(1, 1) Error: undeclared identifier: 'something'
13:23:27Mister_Magisteroh
13:23:31narimiran!eval echo "sth"
13:23:32FromGitter<alehander42> 2 + !eval 2
13:23:34NimBotsth
13:23:39FromGitter<alehander42> hm, interesting
13:23:54Mister_Magister!eval echo "help" == "help"
13:23:57NimBottrue
13:24:04Mister_Magisterso i can compare like that
13:24:14FromGitter<alehander42> !eval quit(1)
13:24:16NimBot<no output>
13:24:19FromGitter<alehander42> sorry
13:24:23narimiran!eval echo "sth"
13:24:26NimBotsth
13:24:29PMunchalehander42 -_-
13:24:30narimirangood
13:24:42FromGitter<alehander42> well, it just exits the example program
13:24:49FromGitter<alehander42> i wondered if it would tell me about quit code
13:25:45PMunchWell no, it returns stdout if there is any, otherwise stderr
13:26:03FromGitter<alehander42> but i admit i wondered if it can crash it sorry
13:26:09FromGitter<alehander42> makes sense
13:26:26PMunchHaha, it has already been put through its paces poor thing
13:26:52PMunchSeems fairly stable, at least as long as Docker isn't filling up the disk..
13:27:14*nif quit (Quit: ...)
13:27:17FromDiscord<Rika> is `nil` nim's noop? it doesnt feel like it is but its the only thing i can find in docs
13:27:23*nif joined #nim
13:27:47FromDiscord<mratsim> it's a null pointer
13:27:47FromGitter<alehander42> btw
13:27:57FromGitter<alehander42> what causes that PMunch? i have problems with my docker CI
13:27:58FromDiscord<mratsim> the compiler might optimize it away
13:28:14narimiranmaybe `discard` is what you want
13:28:14FromGitter<alehander42> it just goes `out of space` with like 1.9 gb on a mapped volume
13:28:22FromDiscord<Rika> my question is more of "what is nim's no op" then
13:28:24PMunchalehander42, not sure really, some artifacts left over when it's building the container..
13:28:26FromGitter<alehander42> i guess its storage options, but it still seems very low
13:28:39PMunchI just manually log on whenever it hangs and clear out the folder
13:28:45FromGitter<alehander42> do you know how to show docker's active limits
13:28:48FromGitter<alehander42> hm, yeah
13:29:03lqdev[m]@Rika noop is `discard`, a noop proc is `proc noop() = discard`
13:29:24FromDiscord<Rika> okay thanks
13:29:29FromGitter<alehander42> `nil` was acting as `discard` in the past sometimes
13:29:31FromGitter<alehander42> iirc
13:29:38FromGitter<alehander42> but `discard` is correct
13:30:01FromDiscord<Rika> nim-lang/irc still has docs using `nil` as a noop
13:30:33lqdev[m]link?
13:30:55FromDiscord<Rika> https://github.com/nim-lang/irc/blob/master/src/irc.nim#L13-L25
13:31:13FromDiscord<Rika> also uses booleans in capital `True`
13:31:20PMunchMan bash history expansion is so nice :)
13:31:30PMunchFor example: !?docker run?0- 5aa221a973d0
13:31:31narimirannow there's your chance for an easy hacktoberfest PR ;)
13:31:48FromGitter<alehander42> fish
13:31:51FromGitter<alehander42> is also nice
13:31:56FromGitter<alehander42> i just see it inline
13:32:04*daddoo left #nim ("Leaving")
13:32:07FromGitter<alehander42> without any ? !
13:32:17lqdev[m]^ this
13:32:19PMunchThat expands to the last run command that matches "docker run" and takes the entire command except for the last word, then places 5aa221a973d0 at the end of the command
13:32:21lqdev[m]fish is awesome
13:32:30lqdev[m]I use it daily
13:32:32PMunchSo for me that expands to docker run -p 80:80 -p 5000:5000 5aa221a973d0
13:32:41narimiran+1 satisfied fish user here
13:32:52PMunchI use zsh
13:32:53FromGitter<alehander42> this is the sea and we are the fishes
13:33:04FromGitter<alehander42> but this completion sounds ok also
13:33:38narimiranbtw, while we're offtopicing (?), @alehander42, did you manage to set up ocaml?
13:34:39FromGitter<alehander42> yes, it is great, but i will play with it tomorrow
13:34:47FromGitter<alehander42> as i have stuff to do today
13:35:00FromGitter<alehander42> which this chat demonstrates
13:35:07PMunchYou can probably use history expansion in fish as well
13:35:52narimiranfuzzy history search with ctrl+r
13:36:06narimiran(but i think this won't work without fzf)
13:45:28*Kaivo quit (Quit: WeeChat 2.6)
13:49:08*Kaivo joined #nim
13:54:39*LargeEpsilon joined #nim
13:56:03disruptekif you know of a good nim benchmark, please offer. looking for more stuff to add to examples for golden.
13:56:45*asymptotically quit (Quit: Leaving)
13:56:55FromGitter<alehander42> what is golden
13:59:43*actuallybatman quit (Ping timeout: 268 seconds)
14:07:56Zevvsilence
14:08:32FromDiscord<juan_carlos> Enjoy the silence...
14:09:57*dom96 shouts
14:10:13shashlick@dom96 - if you should here, you need to review my PRs 😄
14:10:19shashlickshout
14:10:54narimiranlet it all out
14:10:59dom96hehe, I wish I could
14:11:17narimiranshashlick: tears for fears :)
14:12:02disruptekgolden is a simple benchmark that will help find regressions -- https://github.com/disruptek/golden
14:12:34narimiranshashlick: ...and there i thought you were only into trance :)
14:13:14*couven92 quit (Ping timeout: 265 seconds)
14:14:14shashlickit's been a long time
14:16:51sealmovedamn, I can't make it work... I want to transform `x.f` to `x.f()`
14:17:42sealmovethe experimental overloading of `.` doesn't seem to work
14:19:01FromGitter<alehander42> no
14:19:13FromGitter<alehander42> there is .()
14:19:15FromGitter<alehander42> as well
14:19:17FromGitter<alehander42> look at jsffi
14:19:19sealmoveoh..
14:19:22FromGitter<alehander42> it overloads . .() and .=
14:19:43sealmovemissed that! thanks!
14:19:52FromGitter<alehander42> np
14:21:35*ljoonal quit (Quit: ljoonal.xyz)
14:21:39sealmovebut I want to match `.` not `.()`...
14:21:42livcdmratsim: where can I start learning how to do md5 with simd with Nim ? :X
14:22:59FromDiscord<juan_carlos> . is .() on Nim
14:23:56sealmoveI tried for example: template `.`(x: InstanceStdArray; field: untyped): untyped = (x.field)()
14:24:26sealmovebut it doesn't match it
14:24:36sealmoveeven tried with macro using newCall()
14:25:38sealmovebasically I want to simulate lazy reading of a field, so instead of real field I have a proc field which is a closure
14:25:44FromDiscord<juan_carlos> I think you have to pass an --experimental compile flag.
14:25:53sealmoveoh, let me try
14:27:25sealmoveno, it doesn't work, I think it's covered by the {.experimental: "dotOperators".} pragma anyway
14:27:57FromGitter<alehander42> so you want to simulate python's @property ?
14:28:20*ljoonal joined #nim
14:29:21sealmovealeh, I am not familiar with this feature (though I did see it somewhere)
14:30:04sealmoveshould be what I am looking for yes
14:30:26FromGitter<alehander42> if we read https://nim-lang.org/docs/manual.html#overloading-resolution
14:30:31FromGitter<alehander42> carefully, which i never do
14:30:38FromGitter<alehander42> it seems untyped matches last
14:30:46FromGitter<alehander42> so if field already exists
14:30:58FromGitter<alehander42> probably overloading `.` and calling it for field
14:31:02FromGitter<alehander42> wouldnt override it
14:31:33FromGitter<alehander42> the way i expect @property to work in nim is by using e.g. internalField or something
14:31:54FromGitter<alehander42> and public field and `field=`
14:31:59FromGitter<alehander42> accessors
14:32:46FromGitter<alehander42> but i am not really sure what the template example needs because
14:32:52FromGitter<alehander42> if field is a proc with no args
14:32:57FromGitter<alehander42> you already can do `a.field`
14:32:58sealmoveyes it has no args..
14:33:00FromGitter<alehander42> and call it
14:33:10sealmoveyes but
14:33:13FromGitter<alehander42> thats how high and len
14:33:16FromGitter<alehander42> yea
14:33:19sealmoveif for example you want to be able to call len on it
14:33:26sealmovethen you len sees a proc
14:33:31FromGitter<alehander42> no?
14:33:49FromGitter<alehander42> a.len.int works right
14:34:04sealmovebut a is not a proc
14:34:09FromGitter<alehander42> so i guess it calls it in this case as well
14:34:10FromGitter<alehander42> but len is
14:34:20FromGitter<alehander42> usually
14:34:50sealmovealeh, I get: Error: type mismatch: got <proc (): seq[seq[byte]]{.closure.}>
14:34:57sealmoveexpression: len(r.entries)
14:35:17sealmovewhere r is some object and entries is a proc field
14:36:51*fanta1 quit (Quit: fanta1)
14:37:20*PMunch quit (Remote host closed the connection)
14:39:13sealmoveI think this deserves a minimized example, hold on
14:39:54FromGitter<alehander42> hm sorry
14:40:29*fanta1 joined #nim
14:41:23Araqlen(r.entries())
14:41:30Araqyou need to *call* the proc
14:41:47FromGitter<alehander42> sorry i was wrong
14:41:48sealmovehttps://play.nim-lang.org/#ix=1Xsq
14:41:53FromGitter<alehander42> you dont need to call it if its actually
14:42:01FromGitter<alehander42> a proc overload of your type
14:42:04FromGitter<alehander42> but if its a field, you do
14:42:06sealmoveAraq: I know, I am trying to make a template or something that does it for me
14:44:36sealmovehttps://play.nim-lang.org/#ix=1Xsr
14:45:43FromGitter<alehander42> you need to use internalField and do macro `.` `.=` imo: this would solve it
14:46:19sealmovealready have internalField in my code (not in posted example though), so I'll give it a try ;)
14:47:15*shomodj_ joined #nim
14:49:57*shomodj quit (Ping timeout: 240 seconds)
14:51:13livcdoh no we need nim syntax highlighting in bat
14:52:57FromDiscord<Rika> do i have to make a for loop to create a table from two arrays of equal length
14:54:25disruptekthere's a zip.
14:56:40FromDiscord<Rika> i forgot
14:56:53FromDiscord<Rika> you know i keep on forgetting zip map reduce and stuff like those exist
14:59:59*Hideki_ quit (Remote host closed the connection)
15:02:41sealmovealehander42 any idea? https://play.nim-lang.org/#ix=1XsA I don't know how to use internalField + `.=`
15:03:01*couven92 joined #nim
15:04:06FromGitter<alehander42> so now
15:04:31FromGitter<alehander42> just use b: untyped
15:04:34FromGitter<alehander42> dont give it a type
15:04:50FromGitter<alehander42> and construct `internal b`
15:05:07*Hideki_ joined #nim
15:06:16sealmovei don't think it matches: https://play.nim-lang.org/#ix=1XsC
15:06:25FromGitter<alehander42> http://ix.io/1XsE
15:06:26*Hideki_ quit (Remote host closed the connection)
15:06:30FromGitter<alehander42> no my idea is different
15:06:41FromGitter<alehander42> you *have to* not have a `field` in your type
15:07:05*Hideki_ joined #nim
15:07:12FromGitter<alehander42> if i am getting it correctly
15:07:20sealmoveohh
15:07:25FromGitter<alehander42> i dont think you can override field with a template
15:07:59FromGitter<alehander42> so for the MyType .. maybe you can write custom `init`
15:08:02FromGitter<alehander42> for a constructor
15:08:12FromGitter<alehander42> but it depends on your usevase
15:08:16FromGitter<alehander42> usecase
15:09:45sealmoveso basically, the proc() logic goes inside the template, clever
15:10:42FromGitter<alehander42> well, it depends
15:11:03FromGitter<alehander42> i mean, why do you need to replace the field getter func
15:11:17*Hideki_ quit (Ping timeout: 245 seconds)
15:11:55sealmovebecause I have both normal and "lazy" fields, and I want to hide it from the end-user
15:12:25*solitudesf joined #nim
15:14:18FromGitter<alehander42> but does the lazy logic
15:14:23FromGitter<alehander42> needs to be replaced on runtime
15:14:45FromGitter<alehander42> otherwise you can hardcode it in template field =
15:14:50FromGitter<alehander42> template otherField =
15:15:51FromDiscord<kodkuce> i got flue 😦
15:16:29sealmovethe logic? no, it should be fixed
15:18:03Araqkodkuce: get well soon!
15:20:50*floppydh quit (Quit: WeeChat 2.6)
15:21:08sealmovealehander42: it works!! :) <3 https://play.nim-lang.org/#ix=1XsT
15:22:17AraqZevv: could not load: libz3.so :-(
15:23:10Zevvhmm let me see if I can figure out how to make that portable
15:24:49Zevv"(libz3.so|z3.dll)", something like that?
15:25:09Araqnah I'm on OSX
15:25:30Araqtrying 'brew install z3' but I should build from source already
15:25:59Zevvdunno about that. I have mac nor winbox, so I cannot help you out here :(
15:27:03*LargeEpsilon quit (Ping timeout: 264 seconds)
15:27:54Mister_Magisteris there multithreading in nim?
15:28:03Mister_Magisteri want to run webserver in separate thread
15:28:09disruptekMister_Magister: yes.
15:28:23*shomodj_ quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:28:31disruptekmaybe the bug isn't that we're not cleaning up a fd; maybe it's that we're creating an extra one.
15:28:55sealmovealehander42: Thanks so much! I thought it was impossible, and it's quite important for my API.
15:29:24Zevvhow do I handle different ABI versions in FFI? I have a windows libz3.dll that does not have a specific function
15:30:19disruptekas far as i'm concerned, no file that ends in .dll has a function.
15:30:25Zevvpff and my test cases segfault, this nimble needs some love it seems
15:31:28FromDiscord<Rika> is it possible to convert iterators to arrays/seqs like in python? i cant seem to figure out how
15:31:39disruptekimport sequtils; toSeq()
15:32:10FromDiscord<Rika> okay that was quick thanks
15:37:20*couven92 quit (Ping timeout: 265 seconds)
15:37:31*LargeEpsilon joined #nim
15:38:40*fanta1 quit (Quit: fanta1)
15:40:16FromDiscord<Rika> are there any docs about `mixin` and what it is?
15:41:07leorizeit's in the manual
15:41:42FromDiscord<Rika> okay
15:51:12*LargeEpsilon quit (Remote host closed the connection)
15:51:41*LargeEpsilon joined #nim
15:55:42FromGitter<awr1> good morning
15:55:46*skoude joined #nim
15:56:01FromGitter<awr1> or afternoon if your timezone requires it
15:57:55*asymptotically joined #nim
15:58:30disruptekit's about to.
15:59:56*skoude quit (Ping timeout: 240 seconds)
16:07:28FromDiscord<Rika> it's evening/night over here
16:12:51FromGitter<alehander42> Sealmove thanks
16:12:57FromGitter<alehander42> What are you writing
16:13:08FromGitter<alehander42> Here it's late evening
16:13:37sealmoveI am writing the Nim backend for Kaitai Struct: https://kaitai.io/
16:14:14sealmoveEveryone in this IRC should know it by now xD I always end up talking about it
16:16:31FromGitter<alehander42> Yeaa i forgot
16:16:35FromGitter<alehander42> Sorry
16:16:54FromGitter<alehander42> Are you a seal which moves
16:16:58*thomasross quit (Ping timeout: 245 seconds)
16:17:00FromGitter<alehander42> My more important qu
16:17:57sealmoveactually sealmove is: https://en.wikipedia.org/wiki/Adjournment_(games)
16:23:42*thomasross joined #nim
16:25:08*teimosso joined #nim
16:26:23sealmovealehander42: but nice joke ;P
16:43:36narimiranbig news here:
16:43:56narimiranthanks to leorize, we now have Azure Pipelines CI!
16:44:20disrupteksweet, and how fast is it?
16:44:46narimiran"ok, but why another CI service?" AP allows for 10 parallel jobs, and it is noticeably faster than travis (4 parallel jobs) and especially appveyor (1 "parallel" job)
16:45:11*fanta1 joined #nim
16:45:26narimiranthis roughly means that what used to take 3 hours will now* take less than an hour
16:45:49narimiran*now = after the trial period where we use all three CIs is over, and AP takes over as our main (only?) CI
16:47:16*zuibaf joined #nim
16:48:49*zuibaf quit (Client Quit)
17:13:31*LargeEpsilon quit (Ping timeout: 265 seconds)
17:13:56sealmovegreat! :>
17:17:27*LargeEpsilon joined #nim
17:23:31FromGitter<nickdex> So I just got to know (from intellisense) len proc doesn't support Set type?! any reason for that?
17:29:02FromGitter<nickdex> and source code has some *magic* in it lol
17:32:29narimiran`len` should be an alias for `card`
17:34:12Araqthat's shipping in 1.0, nickdex.
17:36:20disruptekcan i put in a `len` for linked lists?
17:36:30Zevvstop that
17:37:40Zevvoh that was not for disruptek, wrong window :)
17:37:45FromDiscord<Rika> len is already aliased is it not
17:37:59disruptekit is for sets.
17:38:16FromDiscord<Rika> oh no i was referring to nickdex
17:38:16*LargeEpsilon quit (Ping timeout: 240 seconds)
17:40:41FromGitter<zetashift> TIL about card huh, maybe I should try for a PR on nim-by-example for Sets and LinkedList
17:42:20Araqdon't use 'card', 'len' has won
17:52:10*rockcavera quit (Remote host closed the connection)
17:52:30*fanta1 quit (Quit: fanta1)
17:53:03Zevvaraq, please dont make that argument against cpuTime().
17:53:18Araqwell I did
17:53:25AraqI can remove my reply
17:53:34Araqbut it's what I think :P
17:53:59Zevvpeople do stupid stuff.
17:54:08Araqcan't we expose the VM's instruction counter instead?
17:54:25Araqthat's deterministic and still useful for benchmarking
17:54:38disrupteki would love that.
17:54:43Zevvnope. That will not find a lot of copies when indexing tables with large values
17:55:19Zevvbad phrasing, sorry - that will not find large memcpys
17:55:31Araqyeah but we fixed those :P
17:55:59ZevvI had to count dots on my terminal for that
17:56:43Araqwe can also enable it via --define:benchmarkVM
17:56:53Araqand then the default Nim doesn't include it
17:57:09Zevvyour argument is really the PRNG?
17:57:28AraqI'm not making this up
17:57:39Araqpeople love compile-time random number generators
17:57:44disrupteklol
17:57:58Zevvok, I will build you one compile time random number generator a day and post it in the issue until you merge it
17:58:34disruptekwhether it's deterministic only matters if you're going to run the code only once.
17:58:58Araqdeterministic builds are totally useful
17:59:15*nif quit (Quit: ...)
17:59:20disruptekyes, but if i want to benchmark compilation of non-deterministic code, that should be my right.
17:59:25*nif joined #nim
18:00:14Zevvdisruptek: c'mon, we'll just fork nim and leave those guys behind!
18:00:35Araqnot everybody understands the joke, beware
18:00:44Araqanyway, make it optional
18:00:44Zevvhehe
18:00:54rayman22201I have a friend that works on slot machines. Deterministic builds are actually required by state law. 😝
18:01:24Zevvyeah, but we had this discussion. There is slurp and gorge already
18:01:34disruptekand %random%
18:01:52Araq"other crap exists" is a poor argument
18:02:08Araqwe must not make it *even easier* to do
18:02:23disruptekbut pandora's box is already open. this is nim...
18:02:34Araqso make it opt-in, that's all I'm asking for
18:02:52Araqyou add --benchmarkVM:on to your build and you have the feature
18:03:48disruptekis there anything in particular that should be benchmarked for regression in the compiler?
18:03:56disruptekor just megatest? or just everything?
18:04:07Araqthe bootstrap process itself?
18:04:09Araqbbl
18:04:40rayman22201Personally I think the more the better. (Within reason)
18:05:42FromGitter<nickdex> So len for sets (and linked list?) is shipping with nim 1.0, correct?
18:05:57disruptekdoesn't exist for linked lists. exists for sets.
18:06:13disrupteki would like to add it for linked lists.
18:06:16*disruptek shrugs.
18:06:43disruptekit's like 3 lines of code to impl.
18:06:45FromGitter<nickdex> Ok cool, and what was all the .magic. thing in system.nim? Comments just say its some compiler magic
18:06:55disruptekthat's exactly what it is.
18:07:28FromGitter<nickdex> haha
18:07:57disrupteksometimes a little magic is required.
18:08:44FromGitter<nickdex> hmm, thats explains why nim is such a cool and fast language :)
18:15:43*teimosso quit (Quit: teimosso)
18:18:51FromGitter<alehander42> Builtin codr
18:21:31*sealmove quit (Quit: WeeChat 2.6)
18:51:11FromDiscord<Lunar> Just curious, when Nim compiles into JavaScript, does it compile into *efficient* JavaScript?
18:51:24FromDiscord<Lunar> Or is there stuff in it that can be refined?
18:53:24FromGitter<zetashift> It does some neat stuff but since the C backend is the most mature, I suspect that more things could be done to make it as `efficient` as for example Bucklescript.
18:55:31FromGitter<zetashift> But the Nim forum is made using the JS compilation target and the forum loads really fast for me, especially compared to other offerings
19:00:24dom96The resulting JS can definitely be optimised further, biggest problem is when you use Nim's `string` type (which needs to be converted between Nim's and JS' string)
19:02:21*skoude joined #nim
19:06:28shashlick@dom96 - what's the best place to PM
19:06:44dom96shashlick, here
19:06:47dom96I mean, IRC
19:06:50*skoude quit (Ping timeout: 240 seconds)
19:06:59shashlickokay when's the best time to finish these PRs?
19:07:05shashlicktakes a full day turnaround
19:08:03dom96I only ever get a chance to look at them in the evening
19:08:18*NimBot joined #nim
19:08:52*lritter joined #nim
19:08:54shashlickokay restarting nimble CI, it will pull latest for issue280xxx and should pass now
19:09:00dom96I restarted it
19:09:02shashlickjust review the most recent code changes
19:09:20shashlickokay thanks
19:09:37*sschwarzer joined #nim
19:09:38shashlickcan we close on https://github.com/dom96/choosenim/pull/135 as well
19:09:41sschwarzerHi :)
19:11:30dom96shashlick, I left another comment on the Nimble PR
19:12:06FromGitter<dawkot> Am I the only one who thinks this shouldn't be allowed? ⏎ ⏎ ```for it in foo.fields: ⏎ if it is int: ⏎ discard``` [https://gitter.im/nim-lang/Nim?at=5d9648069735874673ee3147]
19:12:16FromGitter<dawkot> I ofter forget that I should use `when` in place of `if`
19:12:25FromGitter<dawkot> and the errors get very cryptic
19:12:56shashlick@dom96 - it fails to remove the test file sometimes when the process hasn't quite released the lock on the binary
19:13:03shashlickbreaks CI
19:14:15dom96bah, that's a dirty workaround. I'll merge this, but please create an issue to fix this and comment with a link to it as a reply to my comment
19:15:04shashlickwill do - what's a better way to deal with this
19:15:19FromDiscord<Kiloneie> Here is another video !
19:15:19FromDiscord<Kiloneie> Link: https://youtu.be/AtLz9Q_pcNM
19:15:23shashlickwe could just add a .5 sec delay before doing this
19:15:37shashlickinstead of a retry but still might not be enough depending on the system
19:16:41dom96shashlick, you need to at the very least the check the OS error code
19:17:10dom96it might also be fair enough to just ignore the error and write out a warning that the file could not be deleted for now
19:17:48shashlickokay will just try/except and post a message
19:17:50dom96Now that I use phabricator at work every day I really miss it...
19:18:59shashlickhow can i try to import a module and fail gracefully
19:19:04shashlickif it isn't installed
19:20:15FromGitter<zetashift> @sschwarzer hello
19:21:10shashlick@dom96 - `display("Error:", "Failed to delete " & binFileName, Error, MediumPriority)` /?
19:21:20dom96warning
19:21:27dom96errors are reserved for a hard failure
19:21:45sschwarzerzetashift: I think at the moment there's nothing I can contribute to the conversation. :)
19:21:46shashlickdeal
19:21:55dom96shashlick, also, include the error message
19:23:29shashlick`display("Warning:", "Failed to delete " & binFileName & ": " & getCurrentExceptionMsg(), Warning, MediumPriority)`
19:24:44lqdev[m]gaah why do you use `getCurrentException` and `getCurrentExceptionMsg`
19:25:04lqdev[m]you're in an `except` block anyway, why not just do `except IOError as err`?
19:25:29dom96^^
19:26:11shashlickjust staying consistent with the rest of the code
19:27:08disruptekshashlick: you're in trouble now.
19:27:46shashlickalmost always
19:28:12shashlicksince there's no one way to code in nim
19:29:01dom96shashlick, https://travis-ci.org/dom96/choosenim/builds/593203344
19:29:18dom96dunno what's going on but your PR broke the CI
19:31:04shashlickwth - https://travis-ci.org/dom96/choosenim/builds/588218043
19:32:03dom96ran 11 days ago
19:32:10shashlicklet me just say I hate CIs
19:33:13FromDiscord<mratsim> @miran, I think this should be in the learn resources: https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html
19:33:24shashlick@dom96 - yes and there were no changes in choosenim in that time
19:33:34narimiran(i'm not highlighted if you don't use narimiran)
19:33:48narimiranyeah, i'll add it tomorrow
19:34:06Mister_Magistershashlick: y u have CI
19:34:10Mister_Magisteri need reason to hate it
19:34:12shashlick@dom96 - `display("Warning:", "Failed to delete " & binFileName & ": " & exc.msg, Warning, MediumPriority)`
19:34:37dom96shashlick, yes, I know. I guess something must have changed though, maybe the Nimble version?
19:34:38shashlickit makes sure my crap works, but getting things working with 30-45 minute turnarounds in a black box is excruciating
19:34:56shashlicki'll look into it
19:35:15Mister_Magisterheh
19:35:28shashlick@dom96 - are you good with that nimble.nim code change?
19:35:45dom96mratsim: huh, I'm surprised but the discount code on that page still works
19:35:51dom96shashlick, yes
19:39:38shashlickmeanwhile, how can i check if a module can be imported? `when compiles(import xyz)` doesn't work
19:44:36dom96I don't think you can
19:45:35shashlick@dom96 - pushed a fix for the retry - https://github.com/nim-lang/nimble/pull/714
19:47:46shashlickhere's a shabby workaround for the compiles question - `when gorge("nimble path nimterop").contains(".nimble"):`
19:48:19FromDiscord<mratsim> I thought when compiles was the root of all Nim evil, but when gorge puts it to shame
19:49:05shashlicki'm always running into edge cases - i want to use a nimterop module in the nimble file of a project that depends on nimterop
19:49:43sschwarzermratsim: What's `gorge` anyway? What's it for?
19:49:53dom96I've discovered that doing serialization/deserialization the `JSON.to` way is wrong
19:50:13shashlickso you cannot even nimble install since nimterop isn't present and cannot be imported, but install is the one that installs nimterop too
19:50:22shashlickso when gorge is the only way to check before i import
19:50:30dom96sschwarzer, it's a compile-time readFile
19:51:49sschwarzerdom96: Thanks
19:52:17*actuallybatman joined #nim
19:53:54*sschwarzer quit (Quit: leaving)
20:01:44shashlick@dom96 - choosenim looks like gzip issue
20:02:06*clyybber joined #nim
20:02:21dom96We really need lock files
20:02:59shashlickthere's an old gzip since ~/.nimble/pkgs is cached
20:03:10shashlickclearing cache and restarting build will fix the issue
20:03:24shashlicki don't have permissions tho
20:03:40Zevvhm I got tons of CI failures on #12346, is that me or azure?
20:03:41*nsf quit (Quit: WeeChat 2.5)
20:04:28rayman22201moving the AsyncEvent PR discussion on topic... I hate to throw away code, but I might try re-implementing VirtualAsyncEvent in terms of old AsyncEvent. (I think I tried this before and ran into problems, but I don't remember the details now.)
20:04:44rayman22201It make the PR easier to accept
20:05:05rayman22201I still don't like that it will allow the API's to diverge. It also means re-doing the FlowVar PR
20:05:35dom96well actually
20:05:42dom96I don't think you can change the semantics of AsyncEvent now
20:05:50dom96since you'll break backwards compat
20:05:54dom96so you need to do it this way
20:06:18rayman22201My PR has the same semantics though
20:06:40rayman22201unless you are telling me someone is relying on "out of FD's"
20:07:04dom96hrm
20:07:19dom96that's a good point
20:07:24rayman22201I was very careful to match semantics
20:07:39rayman22201since I knew this was such a big impl change
20:07:51dom96this does feel hard and I wonder how other languages handle it
20:08:01dom96technically any new procedure can break code
20:08:18dom96since you can have code which says: `when declared(fooBar): {.error ..}`
20:08:29disruptekwhy can't it break anything? 1.0 is out. time to look forward.
20:09:00dom96because then what is the point of 1.0?
20:09:14rayman22201LTS
20:09:18disruptekthe point of 1.0 is to stop people saying we can't break anything.
20:09:45FromGitter<alehander42> i think we should drop `int`
20:09:48FromGitter<alehander42> in 1.0.2
20:09:57dom96disruptek, huh?
20:10:25dom96we indeed cannot break anything now in 1.x releases
20:10:51disrupteklet me get this straight... we couldn't break anything before 1.0 and now we can't break anything post-1.0.
20:10:58disruptekwhen exactly should innovation occur?
20:11:12FromGitter<alehander42> its a post-breakage world disruptek
20:11:22dom96We could break anything before 1.0
20:11:29dom96What makes you think we couldn't?
20:11:40FromDiscord<Kiloneie> are we gonna move quicker than C++ ?
20:12:24disruptekwell, i'm not going to argue with that.
20:12:30disruptektoo ridiculous a question.
20:12:43FromGitter<alehander42> that golden readme
20:12:49FromGitter<alehander42> i cant understand it
20:12:49dom96we can break stuff, but it's worth the effort to keep things backwards compatible so that those who are betting on Nim 1.0 can get new features without having to rewrite their code every release.
20:12:49disruptekleorize: ah, you fixed newline post proc() -- thanks.
20:13:14disruptekyou make it sound like nim has a new release more often than once every 15 years or so.
20:13:29dom96and when I say "we can break stuff", I mean "we can but it has to go into a new major release"
20:13:31disruptekalehander42: just run it, it's pretty simple.
20:14:22disruptekdom96: it's cool if you don't ever want to improve anything; i just think you should be honest about it.
20:15:23dom96You can improve things without breaking compatibility
20:15:43FromGitter<alehander42> disruptek, we might add a theorem assistant, why improve if we can go in the proving business
20:15:53FromGitter<alehander42> sorry, bad puns today, cya
20:16:29rayman22201this is getting in the weeds. I was careful to maintain compatibility, but I still see the advantage of just making it an additive change, especially if that is what it takes to get the PR approved.
20:16:50dom96I'm not being ridiculous here am I?
20:16:52clyybberdom96: AFAIK the point of releasing 1.0 was to allow for faster development
20:17:08clyybberWhich also means breaking, but not breaking 1.0.x
20:17:12dom96The sole point of any 1.0 release is t have a stable release that everyone can get behind
20:17:18dom96*to
20:18:21clyybberNon breaking bugfixes are backported to 1.0
20:18:41dom96A 1.1 is still a release that doesn't break anything
20:18:47dom96but one which includes new features
20:19:50clyybberHmm, I don't think that we are doing that kind of dev rn.
20:20:08clyybberI made a change which broke beakwards compatibility and it will be in 1.1
20:20:10clyybberAFAICT
20:20:25dom96what change?
20:20:25clyybberBut it's in the changelog so its no big deal
20:20:41FromGitter<alehander42> hm, i think we need to preserve backward compat
20:20:43FromGitter<alehander42> if possible
20:20:50FromGitter<alehander42> but this has to be defined precisely
20:20:59clyybberdom96: https://github.com/nim-lang/Nim/pull/12268 this one, credit goes to LemonBoy
20:21:32dom96what makes you think this will go into 1.1?
20:21:55dom96Quoting the Nim release article:
20:21:56dom96> New features (which do not break backwards compatibility) will continue in steadily advancing 1.x branches.
20:21:57clyybberbecause devel is 1.1 ?
20:22:01dom96https://nim-lang.org/blog/2019/09/23/version-100-released.html
20:22:15clyybberHmm, ok. I don't see a 1.1 branch though
20:22:33dom96alehander42: This is all defined explicitly ^
20:22:36clyybberonly version-1.0 and devel
20:23:18dom96Doesn't this break all expectations that you have?
20:23:28dom96I don't believe other languages do breaking changes in 1.x versions
20:23:40clyybberdom96: This confirms it: https://github.com/nim-lang/Nim/blob/devel/changelog.md
20:23:52shashlickit's just semvar guys
20:24:01clyybberdom96: I believe many do. How would languages advance otherwise?
20:24:03shashlickMINOR version when you add functionality in a backwards compatible manner, and
20:24:17shashlickPATCH version when you make backwards compatible bug fixes.
20:24:20dom96clyybber, which do? Rust at the very least definitely doesn't
20:24:27dom96Swift release a major version too for breaking changes
20:24:27shashlickMAJOR version when you make incompatible API changes,
20:24:34dom96and yes, indeed, this is literally semver
20:24:56dom96well, I'm going to change it, because this is the promise we agreed to
20:25:00clyybberHmmm, well I think the current development model is much better for Nim
20:25:15FromGitter<alehander42> clyybber its not just about the development model
20:25:27dom96narimiran: are you there?
20:25:38FromGitter<alehander42> i kinda agree with you clyybber
20:25:39disruptekwhat's the big deal, just start a 2.0 branch.
20:25:45rayman22201so we already broke semver? that didn't take long lol
20:26:06FromGitter<alehander42> but on the other hand, breaking existing code is indeed promised not to happen
20:26:20FromGitter<alehander42> the problem is indeed that in nim it might be much easier to break existing code
20:26:38dom96yes, what disruptek said
20:27:05shashlickwhat's the rush with breaking changes already?
20:27:06FromGitter<alehander42> but maybe having major versions more often isnt so bad
20:27:17disrupteki never feel bad about releasing a new major.
20:27:20*rockcavera joined #nim
20:27:22dom96yes, whether to have major versions rapidly or not is another discussion to be had
20:27:37dom96but breaking backwards compatibility in 1.1 cannot happen
20:27:40shashlick@dom96- can you restart the choosenim build after clearing cache?
20:27:41clyybberIts not like these changes are very major..
20:27:44disruptekyou can always do something where odd majors are stable and evens are devel.
20:27:44FromGitter<alehander42> i dont think nim should wait another 10 years for 2.0
20:27:58FromGitter<alehander42> the python model isnt necesarily optimal: look at 2/3
20:28:16shashlickno one is going to take a project seriously if there's no offer of stability
20:28:27*nif quit (Quit: ...)
20:28:30dom96clyybber, it doesn't matter how small it is
20:28:33FromDiscord<Kiloneie> there was a huge backlash regarding python 2 to 3
20:28:37*nif joined #nim
20:28:41dom96this is a promise we made to the community
20:29:03narimirandom96: i am now
20:29:04shashlickthat was still a major version change
20:29:06FromGitter<alehander42> however dom96 there is another moment
20:29:18FromGitter<alehander42> e.g. this change: procThatTakesInt32(SOMECONST int(maybe 64))
20:29:20dom96narimiran: https://github.com/nim-lang/Nim/commit/4ab9b6146b02bd707e8918aeab14ecbd5569a0b7
20:29:22dom96I've made this change
20:29:24FromGitter<alehander42> can this be an attack surface
20:29:36dom96narimiran: 1.1 *cannot* get breaking changes
20:29:59FromGitter<alehander42> it seems to me, that one can imagine somehow that accepting such code would be insecure in some scenario
20:30:09FromGitter<alehander42> and "In certain serious cases, for example if a security vulnerability is discovered in the standard library, we reserve the right to break code which uses it."
20:30:21FromGitter<alehander42> this should be defined more precisely
20:30:32clyybberIt does make a difference. Theres breaking changes where I go through my code base and replace some string with another string, and then theres changes which require me to redesign my whole program architecture.
20:30:44dom96serious cases warrant evidence to show that this is a security issue that is exploited IMO
20:30:57FromGitter<alehander42> clyybber, have to admit this isnt the point tho: your code should work with no changes
20:31:12dom96yep ^
20:31:36clyybberalehander42: Yeah, thats where I'm disagreeing. If you expect your code to work without changes stay on the 1.0.x branch, you get bugfixes.
20:32:05clyybberNew features are in some sense always a breaking change, as dom96 showed above.
20:32:07FromGitter<alehander42> well, thats a different version scheme
20:32:20rayman22201@clyybber, but that's not what was promised in the release, and that's not how semver works.
20:32:26clyybberI know.
20:32:34clyybberBut its what would be better and is currently done
20:32:51FromGitter<alehander42> but i dont think it matters too much
20:33:03FromGitter<alehander42> as we can just have major versions more often
20:33:04dom96clyybber, why would that be better?
20:33:06FromGitter<alehander42> than until now
20:33:19dom96This is just semantics. Why not follow semver *and* what we promised in our most popular article yet?
20:33:56rayman22201better or not doesn't matter. We already made that promise, with a very popular release. You can't make a promise like that and then change your mind a week later.
20:34:06FromGitter<alehander42> but on the other hand, what do the other languages do when they find bugs in their existing api-s: ok, they keep them compatible until a + 1.0
20:34:06rayman22201Not if you want Nim to succeed anyway.
20:34:11FromGitter<alehander42> but where do they put the fixes
20:34:38*LargeEpsilon joined #nim
20:34:46FromGitter<alehander42> i think a workaround is the nim flag way: we can have a flag like "-d:withFixes"
20:34:54dom96alehander42: they deprecate the API and offer a replacement
20:34:54clyybberIMO we should differentiate between degrees of breaking changes.
20:34:56FromGitter<alehander42> which explicitly changes some things
20:35:04narimirani've just read what y'all have been writing. and it is just the same old same old
20:35:07FromGitter<alehander42> and keep the default working like that
20:35:11disruptekthe problem is libraries.
20:35:19narimirani feel like every week we repeat the same story, over and over again
20:35:29narimiranand i'm getting sick of it
20:35:37FromGitter<alehander42> thats your job nari
20:35:38FromGitter<alehander42> come on
20:35:42disruptekjust cut a major for a major breaking change.
20:36:13clyybberFine, so just shift the current model one digit to the left.
20:36:24FromGitter<alehander42> clyybber, but we cant : the point is one should be able to update it with no changes, its not about "it would take me 2 minutes"
20:36:28disrupteki'd rather submit PRs to projects to bring them up to a new major than not break their stuff.
20:36:47FromGitter<alehander42> thats why i think having a flag to enable those fixes or more often majors sounds ok
20:37:05clyybberalehander42: But why do people even update when they don't want anything to change?
20:37:11*Ven`` joined #nim
20:37:25dom96narimiran: we discussed this in PM and you said I should discuss it with Araq
20:37:26dom96I did
20:37:29narimiranjust before y'all get all riled up (probably too late for that....): whichever "conclusion" you reach today, just know that in two days it will be changed again
20:37:38FromGitter<alehander42> new features
20:37:45clyybberalehander42: More often majors is better than a flag IMO, because flags make the compiler code really messy
20:37:46dom96No, it won't be changed agan
20:37:52dom96This is documented in our release article
20:37:55clyybbernarimiran: Nice
20:38:06narimirandom96: "No, it won't be changed agan" where did i hear that one before?
20:38:09clyybbernarimiran: To what will it be changed?
20:38:13FromDiscord<Kiloneie> People like new cool stuff, if the benefits outweigh the negatives, people would opt for changes that would break their code.
20:38:23clyybberExactly.
20:38:31rayman22201this stuff matters for companies more than individuals. You are not taking that into account.
20:38:31dom96It won't be changed because I won't let it.
20:38:33FromGitter<alehander42> narimiran, we just want clear rules on what is breaking change and what not
20:38:35shashlickpeople != organizations
20:38:39FromGitter<alehander42> why the sarcastic tone
20:38:47*LargeEpsilon quit (Ping timeout: 245 seconds)
20:38:48narimiran...and there i was, thinking of writing a RFC about future releases. what a silly idea
20:38:59shashlickprofessional orgs won't accept a project that cannot offer stability for a year
20:39:20dom96Yes, even Status is still on 0.19.0 or something
20:39:28rayman22201More major versions is a good idea imo. "move the current development one digit to the left" if you prefer @clyybber
20:39:31FromGitter<alehander42> there can be stuff like "editions" or switches, or version pragmas
20:39:38FromGitter<alehander42> there are possible decisions
20:39:48FromGitter<alehander42> but they have to be specified
20:39:51dom96yes, of course there can be. That's compatible with our promise.
20:40:03FromGitter<alehander42> yes, so such RFC-s would be welcome
20:40:05dom96As long as the default behaviour remains backwards compatible, everything is fine
20:40:10shashlickbut you still need to maintain older releases
20:40:15shashlickn, n-1 for now
20:40:18clyybberalehander42: I'd rather release major more often. Switches make the compiler really messy
20:40:21FromDiscord<Kiloneie> What is the time factor between major releases supposed to be ?
20:40:51FromGitter<alehander42> clyybber agreed, but even if you release, you need to keep supporting the previous version api for some time
20:40:54narimiranshashlick: i'm up for it. but what i'm getting tired of is changing story and promises every few days, depending on the weather outside
20:41:06shashlickwhat's the change?
20:41:24rayman22201but you HAVE to preserve the compatibility guarantees for organizations. There are people who's entire job is to make sure that all code in a dependency tree for an organization remains compatible. I have seen EXTREMLY OLD linux kernels, and GCC versions used in large organizations for exactly this reason. It's the same reason lock files are so important. This all ties together.
20:41:30shashlickuntil 1.0, we had n = devel and n-1 = 0.20.x which were being maintained
20:41:31narimiran"we should do this". ok. "no wait, that is better"
20:41:48clyybberalehander42: Why do we have to provide backwards compatibility with major versions???
20:41:56narimiran"oh wait, scratch that"
20:42:05dom96narimiran: what are we changing?
20:42:06narimiran"no no, let's try this, after all"
20:42:08FromGitter<alehander42> so you're complaining that 10 people might have different ideas while brainstorming something
20:42:15narimirandom96: hopefully nothing ;)
20:42:17FromGitter<alehander42> that's a bit rich
20:42:26shashlickpost 1.0, we have n = devel, n-1 = 1.0 but when 1.0.x and 1.1.x can only be both maintained if we add an n-2
20:42:45dom96All I'm doing is clearing up misconception, by emphasising what we wrote in our release notes for 1.0
20:42:52narimiranalehander42 i'm complaining about changing already discussed and agreed upon stuff
20:43:08narimirani have no problem with discussing something new, discussion is good
20:43:17FromGitter<alehander42> but we're trying to understand what precisely is agreed upon
20:43:24FromGitter<alehander42> maybe you need to add some context
20:43:25clyybbernarimiran: Well clearly there has been some miscommunication?
20:43:30*krux02 joined #nim
20:43:37clyybberSince you promise the one thing but do the other..
20:44:03narimiranbut when i'm the one making promises, and then later on i'm the one who needs to communicate "oh, btw, i might have lied to you the last time", it does feel shitty
20:44:07FromGitter<alehander42> clyybber i mean in the codebase, you need to keep code for some things, as you need to still support older versions for some time, not with compat
20:44:40FromGitter<alehander42> but what are you talking about nari?
20:44:50rayman22201That's exactly it ^^ We are not clear on the promise. The release blog said a very specific thing, and it looks like that promise is now being broken.
20:45:00narimiran^
20:45:02FromGitter<alehander42> it just seems you have a certain situation in mind, and at least i have no idea what you are referrig to
20:45:28clyybberalehander42: Hmm, yeah. Thats why I think that semver doesn't make much sense. It would make more sense to have MAJOR be for fundemental changes, MINOR for backwards compatibility breaking changes, and PATCH for non backwards compatibility breaking changes.
20:45:57FromGitter<alehander42> you might be right, its a complicated problem
20:46:09FromDiscord<mratsim> We always had the minor for backward compatibility changes
20:46:17FromDiscord<mratsim> breaking*
20:46:29FromDiscord<mratsim> and a flag for old version compatibility
20:46:30FromGitter<alehander42> well, this is about a dream version scheme
20:46:33FromDiscord<mratsim> like nimOldRightShift
20:46:41shashlick@clyybber - when you want to make breaking changes, create a 1.x branch from which all 1.x.x stuff flows and do your 2.x stuff in devel
20:47:00FromDiscord<mratsim> and Araq said that all backward incompatible changes will have a similar flag as much as possible
20:47:19clyybbershashlick: Sure, its just semantics. Currently we do breaking changes in 1.1 and all non breaking stuff goes in 1.0.x
20:47:28shashlickyou're building a product here that has consumers, it is useless moving super fast
20:48:07clyybbermratsim: I think Araq scratched that idea, though I may misremember
20:48:11FromGitter<alehander42> but dom96 , narimiran e.g. what i mean by "define more precisely" is stuff like this: ⏎ ⏎ 1) is new warnings for the same code breaking ⏎ 2) is adding a new procedure breaking ⏎ 3) or a new overload [https://gitter.im/nim-lang/Nim?at=5d965e8a97d0f02487c73b2c]
20:48:18rayman22201That's fine. But this "New features (which do not break backwards compatibility)" from the blog is now a lie
20:48:29disruptekif nim doesn't move fast, i don't think it has a chance.
20:48:31dom96rayman22201, no no no
20:48:44clyybberdisruptek: Yeah
20:48:46FromGitter<alehander42> you cant just say "it doesnt break existing code", when its not obvious what breaks it
20:48:52rayman22201oops, not full post, "New features (which do not break backwards compatibility) will continue in steadily advancing 1.x branches."
20:49:15rayman22201the parentheses part should not have been there
20:49:46FromGitter<alehander42> because usually it seems to me adding new functions seems fine .. but on the other hand it *can* break nim code
20:50:08narimiraneverything can break something ;)
20:50:21FromGitter<alehander42> well, in this case where is the definition :)
20:50:24dom96alehander42: I agree, and I did want to specify this more clearly but there wasn't enough time really
20:50:24narimiranhttps://xkcd.com/1172/
20:50:56narimiran(how many of you knew what's at that link even before clicking it? :))
20:51:06FromDiscord<Kiloneie> Not me
20:51:07*clyybber raises hand
20:51:08FromDiscord<mratsim> how many people are able to validate others on the forum @dom96 @miran, it feels like I have to do like 5 per day
20:51:14FromGitter<alehander42> i've seen it :O
20:51:38dom96narimiran: Please be explicit about this. I have no idea what your thoughts are on this issue and why you came to those thoughts. Is it something that you discussed with Araq?
20:51:43FromGitter<alehander42> the problem i see is that because nim has powerful metaprogramming
20:52:16dom96mratsim: yglukhov can as well IIRC, but yeah, we could use more mods. I don't visit the forum much during the day, only in the evenings.
20:52:20FromGitter<alehander42> i cant understand, how can we add any new feature without possibly breaking the code of somebody
20:52:31disruptekeither most stdlib moves outside stdlib or we're going to keep having these discussions as we try to improve stdlib. i just don't see any other way around that.
20:52:36disrupteks/most/more/
20:52:37FromDiscord<mratsim> I think 1.0 was too rushed if we can't break the standard library in 1.x, there is a lot of cruft in there
20:52:37narimirandom96: i'm about to go to bed, so i don't want to go into any more detail right now, i'm too tired. (i shouldn't have even start commenting about this if i were smart)
20:52:50FromDiscord<Kiloneie> Imma just say that, stability is necessary, but changes must also not come at the pace of C++ or even worse Python, the later really only doing minor changes. Python is gonna stay the same for long years. C++ evolves, but not quickly enough.
20:52:58clyybbermratsim: Yeah, I agree.
20:53:16dom96mratsim: there is a reason we had plenty of stdlib cleanup efforts...
20:53:35FromGitter<alehander42> narimiran, sorry for my tone
20:53:43clyybberEssentially we don't need semver if every new feature is potentially breaking.
20:53:48FromGitter<alehander42> disruptek sounds very reasonable
20:53:52dom96mratsim: and also why some stdlib modules are marked "unstable", they can be broken
20:54:00clyybberWe just need two numbers X.X where the first is breaking and the second is not.
20:54:27dom96clyybber, if every new feature is potentially breaking then every bug fix is also
20:54:39FromDiscord<mratsim> we can use 3 X.X.X with the first one being "you need to relearn the language"
20:54:40narimiranalehander42 don't worry, my irc client doesn't transmit the tone ;) no need to apologize :)
20:54:41FromGitter<alehander42> indeed
20:54:43rayman22201I really don't have a preference. My point was just that we made a particular guarantee in a very public guarantee, so we are now stuck with it
20:54:59rayman22201in a "very public way" *
20:55:00dom96indeed
20:55:18FromDiscord<mratsim> we can make a public announcement saying that this was too strong a guarantee and explain exactly what is entailed
20:55:22clyybberYeah
20:55:25disruptekwhat promise was made wrt bug fixes?
20:55:37FromGitter<alehander42> i imagine a Araq screaming in the eu parlament "no breaking compat"
20:55:41disruptekbecause the code won't suddenly stop working just because most of the improvement is in 2.0...
20:55:47rayman22201https://nim-lang.org/blog/2019/09/23/version-100-released.html
20:55:57rayman22201I'm totally cool "shifting to left" so to speak
20:56:08dom96rayman22201, what do you mean?
20:56:12disruptekAraq wants his batteries-included stdlib but when it comes to breakage, that's "user code" as far as he's concerned.
20:56:25FromGitter<alehander42> mratsim we just need to define precisely what changes are "breaking"
20:56:33rayman22201what @clyybber said earlier. Changing the development model so that we rlease more major versions.
20:56:38clyybberThough we should consider wether it makes more sense to differentiate between certain degrees of breaking.
20:56:45FromDiscord<mratsim> no, we need to define what areas are under the stability guarantees
20:57:06FromGitter<alehander42> i kinda agree with disruptek: a more minimal stdlib with more stable core interfaces makes sense to me
20:57:09dom96rayman22201, that's fine by me too
20:57:47FromDiscord<Kiloneie> I do like that everyone here wants this language to be the best, each with it's ideas.
20:58:01rayman22201the problem with PR, is that "first impressions count". We made the big "first impression", any other announcements we make that contradict that will look bad and hurt Nim in the eyes of the larger world. That's how PR works.
20:58:26disruptekmaybe this is just a matter of perspective.
20:58:29dom96yeah, well, to be honest I don't think a clarifying blog post would be that bad
20:58:37dom96But I also don't think that these rules should be changed
20:58:44dom96we should instead clarify them even more strictly
20:58:48disruptekmaybe the solution is to carefully patch 1.0 and forward-port the bugfixes to 2.0.
20:58:52dom96and explicitly spell out that the stdlib is included
20:59:25rockcaveraAn error is happening in the Nim compiler as I try to recompile a file. Description, my settings and example to reproduce the error: https://pastebin.com/EAb7bhMx
20:59:46disruptekrockcavera: make sure you are using a nightly.
21:00:21clyybberrockcavera: Can you translate the error?
21:00:27*narimiran quit (Ping timeout: 245 seconds)
21:00:47rockcaveraclyybber yes
21:01:04rockcaveradisruptek i'm use nim 1.0, not is nightly
21:01:20FromGitter<alehander42> dom96 well how would we clarify the rules
21:01:22disruptekrockcavera: that version has the bug you found but later nightly releases do not.
21:01:22rockcaveraI will test with nightly
21:01:34FromGitter<alehander42> e.g. when an addition to an api isn't breakage
21:01:42disruptekthink about it. we fix bugs in 1.0 and port those fixes to 2.0.
21:01:45disruptekeveryone gets what they want.
21:01:48shashlickare you guys really saying that you cannot fix bugs without breaking function signatures?
21:01:58FromGitter<alehander42> we can say "if you depend on when declared(stuff)": we dont promise not to break that
21:02:06dom96alehander42: I would rule out things like warnings and edge cases like "I had a when declared() in my code and it broke"
21:02:08disruptekname collisions are a thing, too. as is dependence upon broken behavior.
21:02:13FromGitter<alehander42> exactly
21:02:39dom96yeah, that's kind of a Nim problem I think
21:02:40rockcaveraclyybber A sintaxe do nome do arquivo, do nome do diretório ou do rótulo do volume está incorreta. = The syntax of the file name, directory name, or volume label is incorrect.
21:02:52FromGitter<alehander42> hm, this means the nil checking with warnings + switch can kinda get in 1.1
21:02:57*Vladar quit (Remote host closed the connection)
21:03:12dom96alehander42: of course.
21:03:13clyybberrockcavera: Check your file name then.
21:03:27FromGitter<alehander42> @dom96 but another problem i see is: we can add a new function
21:03:27disruptekclyybber: are you on windows?
21:03:31clyybbernope
21:03:46FromGitter<alehander42> and the user to not have when declared, but have the same name with the same signature
21:03:57FromGitter<alehander42> and have a error due to a clash
21:04:14disrupteki think rockcavera is suffering from https://github.com/nim-lang/Nim/issues/12249
21:04:18FromGitter<alehander42> but this seems like a problem other langs should also have
21:04:23rockcaveradisruptek Truth. The bug is in stable 1.0. At nightly it works normally
21:04:27dom96alehander42: yep, like I said, that's a Nim problem sadly.
21:04:34disruptekrockcavera: great 😀
21:04:34clyybberdisruptek: Looks like your right.
21:04:59rockcaveradisruptek and clyybber thanks for help
21:05:00rockcavera;)
21:05:06dom96alehander42: i am interested how other langs handle this. Of course, not many allow no namespaces...
21:05:07disruptekhave fun.
21:05:13clyybbernp :) (even tho I wasn't of much help)
21:05:25FromDiscord<juan_carlos> I have Chrome 75 Stable, still crashes everyday tho... 🤷‍♀️
21:05:28dom96Maybe there is a reason that doing something that not many other languages do is a bad idea *cough*
21:05:43rayman22201I think a few lisps are the only languages that share this problem...
21:05:52rockcaveraclyybber important that was requested and tried to help
21:06:10clyybber:)
21:06:48clyybberdom96: So should we just skip 1.1 now?
21:07:08clyybberOr do you want to make a 1.1 branch and revert all the backwards compat breaking changes?
21:07:13dom96clyybber, IMO we shouldn't, but that's yet another fight to be had :)
21:07:33dom96yes, that's what I would like
21:07:59rayman22201current 1.1 should probably become 2.0, and a new 1.1 created....
21:08:09dom96devel != 1.1
21:08:13dom96please stop calling it that
21:08:27rayman22201fair enough
21:08:44rayman22201current devel should become 2.0, and a 1.1 created :-)
21:09:21clyybberdom96: Good that we had this discussion now, because so far you only need to revert https://github.com/nim-lang/Nim/pull/12268
21:09:23FromGitter<alehander42> this seems reasonable
21:10:03dom96I'm sure we'll rehash this discussion once Araq awakens
21:10:34clyybberHehe
21:12:27rayman22201indeed
21:15:35clyybberdom96: Btw is there a way to allow for PR authors to add labels to their own PRs?
21:15:44dom96not that I know of
21:16:06FromGitter<alehander42> dom96 i have to admit that
21:16:14*Ven`` quit (Ping timeout: 276 seconds)
21:16:19clyybberHmm, ok. If there were I'd have proposed adding breaking, feature and bugfix labels.
21:16:22FromGitter<alehander42> e.g. following https://github.com/rust-lang/rust/blob/master/RELEASES.md
21:17:02FromGitter<alehander42> there are some changes with led to "no longer works"
21:17:25*ng0 quit (Quit: Alexa, when is the end of world?)
21:17:40FromGitter<alehander42> also changing "unsound" signature
21:17:52FromGitter<alehander42> but not sure what scheme and definition do they follow
21:18:14disruptekwell, those are also new minors every 6-8 weeks.
21:18:28disruptekthat means you don't have a long time for people to develop lots of code that will break.
21:18:43disruptekthis is the problem with the proposals we have at present.
21:18:58disruptekthe language will move too slowly, which will force it to move more slowly.
21:19:04FromGitter<alehander42> but also very rare
21:19:14clyybberThats why I'm saying that it would make sense to have frequent small breaking changes.
21:19:27clyybberAnd have an extra version digit for that.
21:19:49disrupteki just think we port fixes forward, not backward.
21:20:04clyybberdisruptek: Whats the difference?
21:20:34disruptekthe difference is that the 1.0 ONLY gets fixes, which meets the guarantee offered.
21:20:58dom96interesting
21:21:02disruptekand we don't have to worry about any of the new work breaking anyone; they can use 1.0 if they want stability.
21:21:20clyybberdisruptek: Ok, that is what I'd like too.
21:21:34dom96So Rust seems to allow breaking changes, so long as the breakage is minor
21:21:38FromGitter<alehander42> and they did have the same new function problem https://www.reddit.com/r/rust/comments/9hf2qy/the_future_of_rusts_backwards_compatibility/e6cd9p6/
21:21:41clyybberHave MINOR for small breaking changes MAJOR for big ones and PATCH for non breaking
21:21:52FromGitter<alehander42> a good discussion https://www.reddit.com/r/rust/comments/9hf2qy/the_future_of_rusts_backwards_compatibility/
21:21:55dom96They also seem to use "crater" to check how many packages the change breaks which is pretty cool
21:22:10FromGitter<alehander42> nim already kinda does that with important packages
21:22:20disruptekmajor can just represent a branch that will forward-port fixes, so when 2.0 goes out, it deprecates 1.0 and becomes the new bugfix branch.
21:22:53FromGitter<alehander42> but the main point stays: we need good rules
21:22:59clyybberdom96, alehander42: I also sent out PRs to the packages in important_packages that failed with my PR.
21:23:06FromGitter<alehander42> "small" breaking changes means nothing
21:23:13FromGitter<alehander42> without a definition of "small change"
21:23:28disrupteki think we can do better than rust here, if we want to.
21:23:31dom96indeed
21:23:37clyybberalehander42: Definition is "small breaking change". Meaning it can be easily fixed with a regex or something.
21:23:54clyybberWe could also introduce a regex to run on your code with every "small breaking change"
21:23:58FromGitter<alehander42> and how would i fix with regex your typing change ..
21:23:59disruptekhonestly, i don't want even that.
21:24:14disrupteki hate picking up code i wrote years ago and having to fuck with it.
21:24:34clyybberalehander42: Simple, remove the explicit ".int" from all consts
21:24:43dom96based on that reddit post it seems that Rust is also suffering from under-specification of these guarantees
21:24:46disrupteklike i want to try to figure out what was "fixed" in the compiler 5 years ago that now breaks my 5-year-old code. and patch it.
21:24:49disruptekno thanks.
21:25:07clyybberdisruptek: If its code you don't want to fuck with, dont use that code?
21:25:32clyybberI mean thats the definition of maintenance right? Changing your code?
21:25:36disruptekthat puts the work of keeping my code working on me, despite the fact that it's you that's doing the development.
21:25:41clyybberSo that it keeps working
21:25:57disruptekno point in a stability guarantee, then.
21:25:58federico3disruptek: or... you write down which version of the compiler is supported and use that one
21:26:11clyybberdisruptek: Well. If you want that stability guarantee go stay on 1.0.x
21:26:18disruptekyeah, that's what i'm talking about.
21:26:22clyybberAh cool
21:27:00dom96if there is no point in a stability guarantee then what's the point in a 1.0 release?
21:27:06disrupteki don't want to run some regexp on my 1.0 code to keep it working.
21:27:16disrupteki guess i wasn't that clear earlier.
21:28:02disrupteki have to do this all the time with node and it's a disaster. i do it less frequently with python and it's still a pita.
21:29:07clyybberMaybe we should ditch semver and do X.X
21:29:11dom96So I think the conclusion we can all agree to at least is: we need to define what we consider a "serious" breaking change in Nim.
21:29:12federico3??
21:29:35dom96It could be as easy as: it's "serious" if it breaks more than 1% of Nimble packages
21:29:49FromGitter<sheerluck> if Scala 3 is not resembling Scala 2, and who remembers what Scala 1 was like, so Nim 2 can differ from Nim 1. Like Python 4 is different from Python3
21:30:40clyybberdom96: We can't test all nimble packages though
21:30:49*asymptotically quit (Quit: Leaving)
21:31:00clyybberAnd then theres also the problem that many nimble packages are broken rn
21:31:02dom96clyybber, why not?
21:31:20federico3dom96: it's also VERY serious if it breaks backward compatibility in a way that prevents code from being compatible with the previous and the new version of the compiler at the same time
21:31:24clyybberdom96: It would take forever. Making development a PITA
21:31:47federico3dom96: e.g. what happened with py2/3
21:32:06dom96clyybber, I really don't think it would take long. We might need to invest some actual money into a build machine, but we can do that.
21:32:37clyybberdom96: How do we test those packages though?
21:33:01clyybberMany are unmantained wrappers.
21:33:17clyybberWhich are broken with new releases of the thing they are wrapping
21:33:22clyybberWhich is out of our control
21:33:29clyybberMany are broken rn.
21:33:39disruptekand might not even be buildable by us.
21:33:41dom96The tool can certainly keep track of what's broken right now
21:33:47dom96and ignore those packages
21:34:14federico3dom96: yep, like the package directory
21:34:14dom96These problems are obviously solvable. Otherwise Crater wouldn't be a thing.
21:34:18shashlickthis is basically what 1.0 means - cannot be a mom and pop shop anymore where we do things for our convenience
21:34:30dom96federico3, precisely
21:34:36disruptektechnically, we could figure out what a package depends upon. i've been planning on building this for a pentest app i have in mind.
21:34:49shashlickit is a total pain building customer facing stuff - lots of totally boring and hopeless work to keep things stable
21:35:11dom96I wonder what crater runs, whether it just compiles code or tries to run tests too
21:35:24shashlicki've spent several soulless hours fighting with travis and appveyor
21:35:27clyybberWould be kind of useless if it didn't run tests too.
21:35:44shashlicka mature project isn't just about working on cool features and moving fast
21:36:00dom96"it does this by building large number of crates, running their test suites and comparing the results between two versions of the Rust compiler."
21:36:07dom96yeah, it runs the tests https://github.com/rust-lang/crater
21:36:50disruptekthis is how golden is going to work, but it'll support stages too, so you can bench sections of code and not just the complete runtime.
21:36:52dom96Written by a mozilla contractor. Ahh... how I wish this was possible for Nim...
21:36:55clyybbershashlick: And you want Nim to be a mature project which just stops evolving?
21:36:59shashlicke.g. nimterop is tested on 0.19.6, 0.20.2, 1.0.0 and devel, on win/lin/osx, on travis and appveyor
21:37:07shashlickis that what i said?
21:37:18shashlickevolving with stability is hard work
21:37:18clyybberSorry, maybe I misunderstood
21:37:44FromGitter<sheerluck> working on cool features and moving fast is more fun though
21:37:54shashlickhave to be disciplined
21:38:12clyybbershashlick: Well, it is just slowing down development. Simple as that.
21:38:24shashlickyou bet, it is how real life is
21:38:45clyybbershashlick: But it would make more sense for everyone to evolve fast.
21:39:01clyybberSo maybe we should make Nim evolve fast and continuous
21:39:18clyybberThat way we will also attract people who want their stuff to evolve fast
21:39:31shashlickwhat's the purpose of such an evolution?
21:39:39shashlickyou will only have hobbyists using nim
21:39:46shashlickno one with real $$$ will ever pick it up
21:39:48clyybberAnd scientists
21:40:01shashlickanyone who doesn't mind throwing their code away, yes
21:40:14clyybbershashlick: Well, its not like we are gonna replace Java by standing still
21:40:29clyybberWe aren't gonna replace those big stable behemoths.
21:40:39shashlicki don't know what you mean by that
21:40:48*thomz quit (Quit: Going offline, see ya! (www.adiirc.com))
21:40:50shashlickare you really saying that you cannot write backwards compatible code?
21:41:08clyybberNo I am not. I am saying that we should not do it forever.
21:41:27disruptekthe problem isn't writing backwards-compat code. it's writing forwards-compat code.
21:41:43clyybberdisruptek: I still dont get the difference :P
21:41:46*solitudesf quit (Ping timeout: 265 seconds)
21:42:00disruptekit's easy to look behind you and act accordingly.
21:42:12shashlickif you were running a professional company that was considering Nim, how often would you afford picking up new breaking changes?
21:42:28disruptekwe don't have to guess; status hasn't yet adopted 0.20.
21:42:39disruptekare they not big enough a nim shop?
21:42:49shashlicksay you wrote 100k lines of code, how often do you want to run a full regression and fix all broken code
21:42:58Cadeywell
21:43:00Cadeylet's be honest
21:43:07disruptekmaybe once every 3 years.
21:43:10Cadeybreaking changes don't have to be completely breaking
21:43:15clyybberExactly
21:43:21Cadeywhat if there was a `nim fix` to fix the worst of it?
21:43:26clyybberDo small breaking changes and release more often
21:43:29Cadeylike `go fix` or `2to3`
21:43:32federico3disruptek: I don't get what your point is.
21:43:44clyybberCadey: Yeah, that was my original idea with the regex thing
21:43:47disruptekstatus cannot afford to run 0.20 let alone 1.0.
21:43:50shashlickyou are acting as if any code change is a breaking change
21:43:57clyybberdisruptek: I wonder why
21:43:57shashlickwhat sense does that make
21:44:11shashlickbecause you cannot waste dev time porting
21:44:15shashlickthere's no $ in that
21:44:23shashlickzero features
21:44:27disruptekno string conversion in porting, no.
21:44:33clyybberlol
21:44:44Cadeyi think go has a good model for this tbh
21:44:47clyybbershashlick: So don't port and stay on some old branch.
21:45:02Cadeythey make code written against go 1.x work on go 1.(x+n)
21:45:05shashlickand get zero bug fixes cause the dev team is too busy building cool features
21:45:21shashlickand then basically don't use nim at all cause you don't ever get any stability
21:45:24clyybberWell.
21:45:36disruptekmaybe we just let the user specify which version they want and then we can toggle how we behave with it in our "fixed" code.
21:45:46shashlickStatus would be fine with 0.19.x if we released 0.19.8 and 0.19.10
21:45:48disruptekthat way we can keep you working forever.
21:45:58shashlickbut we are barely even wanting to support n-1
21:46:03disruptekand then we just flush that out whenever we cut a major.
21:46:03clyybbershashlick: But nim-lang would not be fine.
21:46:14shashlickn = devel here which isn't even a release
21:46:59shashlick@disruptek - araq contemplated that but it is even harder than just backporting
21:47:00disruptekthink about it. we just `when` out the problem and then we can support anything.
21:47:12disruptekit's not as hard as this semver problem.
21:47:17shashlickit is more code complexity whereas backporting is a process complexity
21:47:30clyybberAnd the compiler code will get more and more messy and no one will ever see through it ever again
21:47:35shashlicknot everyone can handle compiler code complexity, backporting is routine
21:47:59disruptekthen i'm back to saying we need 2.0 and forward-port from 1.0 to 2.0.
21:48:14clyybberI still dont get forward porting
21:48:16shashlickhowever porting is achieved is fine with me, forward, back sure
21:48:17disrupteki don't see an alternative that lets nim grow and without growth, nim is dead.
21:48:43shashlickmy point is that stability has just as much value, if not more, as growth does
21:48:44disruptekforward porting means you only put bug fixes into 1.0 and you stop worrying about breaking devel.
21:49:14shashlickyou need a dedicated team that maintains 1.0.x as well as picks real features that could go into 1.1
21:49:14clyybberdisruptek: Ah, ok
21:49:18disruptekthe code is stable -- just don't change it and it's likely to keep working for quite awhile.
21:49:22shashlickwhile some cool cats work on devel
21:49:30shashlickbut don't assume all of it is just free
21:50:00disruptekwell, status is probably the most motivated to stabilize 1.0 and patch it with fixes.
21:50:08shashlickthis really makes no sense really, how many of you write new original code 100% of the time
21:50:09disruptekand maybe dom96 is a memory of that cohort as well.
21:50:25clyybbershashlick: So what are you saying?
21:50:30disrupteks/memory/member/
21:50:40clyybberThat we should value stability over evolution?
21:50:42shashlick@disruptek - you know the hell i went through just to upgrade feud from 0.19.6 to 0.20.0
21:50:49shashlickpaltry 5k project
21:50:59shashlicklife is a balance, both matter
21:51:14disruptekyes, i've already had breakage in my code and i've barely written anything.
21:51:22Cadeyevolution should break as little as possible
21:51:38shashlicknote that evolution != revolution either
21:51:46clyybberWell it is
21:52:00clyybberevolution in the literal sense is based on discarding broken ideas
21:52:23clyybbers/broken ideas/suboptimal designs
21:52:28shashlickthat's what revolution is
21:52:33shashlickevolution builds on what exists
21:52:42shashlickit doesn't just throw out the past
21:53:25clyybbershashlick: Exactly. A series of small breaking changes
21:53:42clyybberWhich is IMO what nims development model should be.
21:53:45clyybberBreak often but small
21:54:01clyybberAnd with a `nim fix` that shouldn't be so bad for companies either
21:55:14disruptekbasically, the browser model where you support the last N versions and you cut a new one several times per year.
21:55:21disruptekis that what you're proposing?
21:55:23clyybberAlso at some you have to decide, do you want to target hobbyists or companies. If you target hobbyists you can move fast and stay popular. When you target companies you move slow but get money
21:55:32clyybberdisruptek: Yeah
21:55:49disruptekthat would give us a rubber-band that we could put packages in.
21:55:54clyybberMainly so that we dont get people staying on old versions forever
21:56:05disruptekthen they only come to our attention if they don't work with the N-most recent version.
21:56:48clyybberdisruptek: We give them `nim fix`
21:56:54clyybberAnd integrate that into nimble.
21:57:04clyybberAssuming such a `nim fix` is feasable.
21:57:12disruptekyeah, i'm not sure how that works.
21:57:24disrupteki think it's easier to `when` support the last N versions.
21:57:24clyybberdisruptek: Maybe we should also have different subrepos on nimble
21:57:45clyybberdisruptek: You mean in the compiler? Believe me for some things it just isn't possible
21:57:53disrupteknot the compiler, just the stdlib.
21:58:02disruptekthe issue, imo, is the stdlib.
21:58:16clyybberdisruptek: Like a subrepo for up-to-date maintained packages and another subrepo for older packages.
21:58:33clyybberOr we attach the subrepos to the language versions
21:58:57disruptekjust flag packages that pass tests according to which version they work with.
21:59:35FromDiscord<mratsim> agree with disruptek
21:59:51FromDiscord<mratsim> Also we are planning to move to 1.02 or 1.0.4
22:00:07clyybbermratsim: What was preventing you till now?
22:00:17*shomodj joined #nim
22:00:17clyybberWas it compiler or stdlib changes?
22:00:24FromDiscord<mratsim> staying on 0.19 was to decouple development workflow from nim's
22:00:32clyybberUgh
22:00:35FromDiscord<mratsim> compiler breakage
22:01:00FromDiscord<mratsim> https://github.com/status-im/nimbus/issues/399
22:01:37dom96mratsim: easy for you to say that stdlib breakage doesn't matter when Status uses practically none of it :P
22:02:54clyybbermratsim: Maybe status should contribute more to the compiler
22:03:13FromDiscord<mratsim> that's because we would like to change key stuff in the standard lib but we can't wait for those changes
22:03:36clyybberSo that you don't accumulate workarounds upon workarounds but instead the core issue gets fixed and everybodys happy :)
22:03:38FromDiscord<mratsim> Well, we sponsor 2~3 compiler devs
22:03:53FromDiscord<mratsim> we do, static changes in 0.19 were for that
22:04:10clyybberAh, right. zah is also at status?
22:04:14FromDiscord<mratsim> yes
22:04:28clyybberCool. He started contributing a bit more recently
22:05:13FromDiscord<mratsim> it's not that easy to fix core issues
22:05:19FromDiscord<mratsim> see the generic sandwich
22:05:38FromGitter<zetashift> generic sandwich? :O
22:06:10FromDiscord<mratsim> https://github.com/nim-lang/Nim/issues/11225
22:06:21clyybberBeat me to it :p
22:09:30clyybberWell, it has been a nice discussion with y'all :) Good night!
22:09:32*clyybber quit (Quit: WeeChat 2.6)
22:16:11FromDiscord<mratsim> 'night
22:20:08*LargeEpsilon joined #nim
22:20:40FromGitter<zetashift> wow what a read
22:24:46*LargeEpsilon quit (Ping timeout: 268 seconds)
22:43:12*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:54:37*actuallybatman quit (Ping timeout: 240 seconds)
22:59:49*shomodj joined #nim
23:01:01*krux02 quit (Remote host closed the connection)
23:10:27*traviss quit (Ping timeout: 245 seconds)
23:13:05*traviss joined #nim
23:14:59*actuallybatman joined #nim
23:27:02FromDiscord<treeform> disruptek, I just updated to openSSL 1.1.1 on Ubuntu and now my jwt signing code eats up all memory and crashes. Is that what you had happen to you?
23:29:30FromDiscord<treeform> I hate openSSL so much.
23:33:09disruptekwell, no, but i use gentoo.
23:33:32disruptektreeform: i don't think your upgrade was successful.
23:39:30FromDiscord<treeform> disruptek, I am debugging it now.
23:40:00FromDiscord<treeform> its in the "PEM_read_bio_PrivateKey" what ever it does
23:41:17*thomasross quit (Ping timeout: 240 seconds)
23:43:08*Kaivo quit (Ping timeout: 276 seconds)
23:43:20FromDiscord<treeform> for some reason it allocates 24bytes over and over till death.
23:43:55disruptekwhich 1.1.1?
23:44:01FromDiscord<treeform> yeah
23:44:24disruptekbut which version? i'm on 1.1.1c
23:44:57FromDiscord<treeform> `OpenSSL 1.1.0g 2 Nov 2017 (Library: OpenSSL 1.1.1 11 Sep 2018)`
23:45:30FromDiscord<treeform> I guess i on 1.1.0g that pretends to be 1.1.1?
23:46:06disruptekvice-versa, i think.
23:47:13disruptekyou were on 1.0.2 before?
23:47:24FromDiscord<treeform> disruptek, on mac I was
23:47:37FromDiscord<treeform> on my server i was always on `OpenSSL 1.1.0g`
23:47:41FromDiscord<treeform> which now on a new server crashes
23:48:32*thomasross joined #nim
23:50:16FromDiscord<treeform> tried with `-d:nimNoAllocForSSL` no luck same thing
23:50:44FromDiscord<treeform> disruptek, you can't write that non openSSL singing code fast enough!
23:51:14disruptekhmm, i haven't looked at it. but i guess i will look. the only spec you have is the existing code, right?
23:52:17FromDiscord<treeform> yes, I am sure google has a spec
23:52:35*traviss quit (Quit: Leaving)
23:52:42FromDiscord<treeform> https://cloud.google.com/iot/docs/how-tos/credentials/jwts
23:53:37FromDiscord<treeform> hmm google seems to use openSSL as well https://github.com/GoogleCloudPlatform/cpp-docs-samples/blob/master/iot/mqtt-ciotc/mqtt_ciotc.c#L26
23:53:53*traviss joined #nim
23:54:35FromDiscord<treeform> hmm https://stackoverflow.com/questions/51330491/jwt-without-openssl
23:54:43disruptekthis looks pretty easy, let's just make sure one of these is in nim-crypto.
23:57:43*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)