<< 19-08-2019 >>
00:34:55*rockcavera joined #nim
00:34:58*laaron quit (Remote host closed the connection)
00:41:30*laaron joined #nim
00:46:36*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
00:48:32FromDiscord_<Shield> apparently opengl can use other threads to load textures using wglShareLists since windows 2000
00:48:34FromDiscord_<Shield> amazing
00:50:02*laaron joined #nim
00:57:49*laaron quit (Remote host closed the connection)
01:04:58*laaron joined #nim
01:10:10*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
01:11:08*laaron joined #nim
01:13:30*laaron quit (Remote host closed the connection)
01:15:38*laaron joined #nim
01:20:06*laaron quit (Client Quit)
01:21:45*laaron joined #nim
01:51:02*ng0_ joined #nim
01:53:36*ng0 quit (Ping timeout: 260 seconds)
02:16:54*lritter joined #nim
02:44:04*lritter quit (Ping timeout: 244 seconds)
02:44:59*lritter joined #nim
02:46:31*dddddd quit (Remote host closed the connection)
02:46:31*noonien quit (Quit: Connection closed for inactivity)
03:48:43*fjellfras joined #nim
03:48:59*fjellfras quit (Max SendQ exceeded)
03:49:19*fjellfras joined #nim
03:53:11*chemist69 quit (Ping timeout: 252 seconds)
03:55:03*chemist69 joined #nim
04:24:46*nsf joined #nim
04:53:37*endragor joined #nim
04:57:43*terps joined #nim
05:08:12*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
05:08:24*laaron- joined #nim
05:17:02*narimiran joined #nim
05:19:42*laaron- quit (Remote host closed the connection)
05:20:03*laaron joined #nim
05:26:35FromGitter<awr1> there's an equivalent on X too
05:44:51*salewski joined #nim
05:46:22*solitudesf joined #nim
05:46:29salewskinarimiran, link on Nim's homepage https://stackoverflow.com/questions/tagged/nim is outdated, tag is nim-lang now.
05:49:31*absolutejam quit (Ping timeout: 268 seconds)
05:50:37*salewski quit (Quit: WeeChat 2.5)
05:53:03*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
05:54:25*laaron joined #nim
06:21:26*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
06:22:00*laaron joined #nim
06:22:46narimiransalewski: fixed
06:34:06*PMunch joined #nim
06:55:15*terps quit (Ping timeout: 264 seconds)
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:52*gmpreussner joined #nim
07:37:24*krux02 joined #nim
08:05:02*terps joined #nim
08:11:32*lkw quit (Quit: ZNC 1.7.3 - https://znc.in)
08:13:20*lkw joined #nim
08:23:03*stefanos82 joined #nim
08:27:16*ng0_ is now known as ng0
08:33:43*lkw quit (Quit: ZNC 1.7.3 - https://znc.in)
08:35:00*lkw joined #nim
08:41:14*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
08:41:53*laaron joined #nim
09:11:27*terps quit (Ping timeout: 252 seconds)
09:18:33*floppydh joined #nim
09:21:51*MarderIII joined #nim
09:51:55*LargeEpsilon joined #nim
09:51:58*shomodj joined #nim
09:54:53*shomodj_ joined #nim
09:58:58*shomodj quit (Ping timeout: 272 seconds)
09:59:36*MarderIII quit (Ping timeout: 272 seconds)
10:11:17*terps joined #nim
10:13:28*lkw quit (Quit: ZNC 1.7.3 - https://znc.in)
10:18:40FromGitter<zah> `x: type` and more importantly `x: type Foo` is used in hundreds of places in our codebases at this point. It's working out fine for us, what's so terrible about it?
10:24:24*lkw joined #nim
10:30:48*ZORR0W joined #nim
10:34:15*dddddd joined #nim
10:34:29*MarderIII joined #nim
10:44:17*stefanos82 quit (Quit: Quitting for now...)
10:48:31*abm joined #nim
10:58:16*skelett quit (Quit: WeeChat 2.4)
10:58:45*skelett joined #nim
10:59:46*LargeEpsilon quit (Ping timeout: 272 seconds)
11:01:07*skelett quit (Client Quit)
11:01:43*nc-x joined #nim
11:01:49*fjellfras quit (Quit: Leaving)
11:01:54nc-xnarimiran: you there?
11:02:03*skelett joined #nim
11:02:04narimirannc-x: yeah
11:02:23nc-xCan you please cancel all builds except the top one here - https://travis-ci.org/nim-lang/nightlies/pull_requests
11:02:30*skelett quit (Client Quit)
11:03:05nc-xI don't why travis does not autocancel builds after a force push. Also I closed the old PR, yet it is still queued.
11:03:10narimirannc-x: done, and thanks for notifying me about it
11:03:14nc-x*I don't understand
11:03:20nc-xthank you
11:03:40*skelett joined #nim
11:04:00*nc-x quit (Remote host closed the connection)
11:04:10narimiranyeah, travis has some problems with auto-cancel. i guess that once it starts (it is not pending anymore), it doesn't cancel it. unfortunately.
11:15:40*vlad1777d joined #nim
11:22:32*LargeEpsilon joined #nim
11:24:13*PMunch quit (Ping timeout: 245 seconds)
11:24:22*nc-x joined #nim
11:24:36nc-xnarimiran: looks like autocancellation is not enabled for nightlies repo https://docs.travis-ci.com/user/customizing-the-build/#building-only-the-latest-commit
11:25:04*nc-x quit (Remote host closed the connection)
11:25:29narimiranit is enabled
11:27:24narimiran...but once the tests are running (no more pending/queued), it must be manually cancelled. i think auto-cancellation works only for jobs that are in queue (not running yet)
11:27:39*nc-x joined #nim
11:27:47nc-xbut it works fine on the nim repo IIRC
11:28:01narimiranit doesn't. trust me, i know :)
11:28:32narimiran(i'm the one who manually cancels stuff, if i notice there is a pile-up)
11:28:35*vlad1777d quit (Ping timeout: 248 seconds)
11:30:31*PMunch joined #nim
11:32:29krux02zah: `x: type` is bad because it is just another way to represent `x: typedesc[T]` or `x: typedesc[Foo]`. I don't like the idea of alternative syntaxes for the same thing.
11:33:32krux02I am currently implementing a warning into the compiler to normalize the usage of typedesc arguments in procedure arguments.
11:35:15*clyybber joined #nim
11:36:52clyybberWell the plan was to deprecate typedesc not type
11:37:10clyybberThen one issue cropped up, and changed the plan
11:37:16clyybbereven though the issue has been fixed
11:38:28*tiorock joined #nim
11:38:28*tiorock quit (Changing host)
11:38:28*tiorock joined #nim
11:38:28*rockcavera quit (Killed (orwell.freenode.net (Nickname regained by services)))
11:38:28*tiorock is now known as rockcavera
11:39:05FromGitter<zah> you'll then have to add the same warning for `ref[T]`, `static T` and `ptr[T]`. It's so much better when the user have to remember the unique style of writing every built-in type
11:41:27FromGitter<zah> oh, and we better forget about creating abstractions where the choice of such a modifier is provided as a paramter
11:42:31*terps quit (Ping timeout: 252 seconds)
11:52:36*MarderIII quit (Ping timeout: 248 seconds)
11:53:32*terps joined #nim
11:53:34*nc-x15 joined #nim
11:54:02nc-x15narimiran: yeah you are right https://github.com/travis-ci/travis-ci/issues/8712
11:55:25krux02clyybber: I disliked the plan to convert from typedesc to type everywhere from the beginning.
11:56:08krux02typedesc is structurally ugly, and we have to fix the structural ugliness first before we try to make it look pretty.
11:56:50clyybberSure, fix its structure/design, but why intentionally make it look ugly?
11:57:13clyybberI don't think the way to solve things is to steer users away from doing it/
11:57:26clyybberIt's a social workaround
11:58:01*Kaivo joined #nim
12:02:07krux02clyybber, typedesc is ugly.
12:02:31krux02I don't want to make the ugliest part of Nim look pretty.
12:03:04clyybberkrux02: You mean the implementation is ugly or the design of typedesc?
12:03:13krux02both
12:03:44krux02I really don't like the part that typedesc sneaks generic parameters to your function.
12:05:05clyybberThat can be changed, and AFAICT you have a PR up that does exactly that, right?
12:05:40FromGitter<zah> The notion that typedesc should be avoided on some "bad semantics" ground is really outrageous for me. We've used typedesc in beatiful ways in a number of our libraries. Typedesc is often used to create symbols that act as holders of associated values and other types. We've used such symbols to describe serialization formats, network protocols and bunch of other things to create really nice APIs
12:07:07FromGitter<zah> If you can't appreaciate typedesc, you are entitled to this, but why make things worse for others that appreaciate it?
12:07:43clyybberI have to agree with zah there, I don't see a reason to cripple and deprecate type/typedesc
12:07:46disruptekzah: you don't understand, krux02 is trying to save you from yourself. 😜
12:08:19FromGitter<zah> not sure if you are attempting humor here or being serious :)
12:08:33disruptekbehind all humor is a kernel of truth.
12:10:09krux02zah: The goal is to make typedesc conprehensible for people who didn't design it.
12:10:23krux02and of course easy to use.
12:10:48FromGitter<zah> so, by requiring the people to write `typedesc[T]`, you've solved that?
12:11:27krux02well, requirering people to type that at least ensure people understand the generic origin of typedesc.
12:11:35clyybberTBF you solve the bind once vs bind many part of typedesc that way
12:12:21clyybberThough I would argue that its fine to have typedesc's implicit generic parameter be bind once, and when you want bind many you will go the explicit route
12:12:29FromGitter<alehander42> i think people can be teached that using 'type X / typedesc X' makes a function generic: there are 10-s of way less obvious things in most languages, so this isn't such a dealbreaker
12:12:42krux02it is not obvious at all, and to be fail even a very surprising behavior, that ``typeof(int)`` and ``typeof(float)`` are expression of different types
12:12:54FromGitter<zah> Nim has implicit type classes. People have to learn about them at some point
12:13:02krux02people think that those expressions are just of type ``typedesc``, or ``type`` if you want to call it that way.
12:13:24clyybberDo type classes introduce an implicit generic parameter?
12:13:36krux02yes they do
12:13:52clyybberCool
12:14:40clyybberThen I say document that typedesc behaves like a typeclass. Problem solved?
12:14:48FromGitter<zah> it's already documented
12:14:57krux02the bad part about typedesc is how well it hides that it adds generic parameters that you are not aware of.
12:15:07disrupteki think i'd rather the language used the more explicit syntax; the user can always hide that with their own definitions if they want.
12:15:25krux02clyybber: typedesc is not like a typeclass, it is special, because it has "bind many" behavior.
12:15:42FromGitter<zah> > In many contexts, Nim allows you to treat the names of types as regular values. These values exists only during the compilation phase, but since all values must have a type, typedesc is considered their special type. ⏎ ⏎ typedesc acts like a generic type. For instance, the type of the symbol int is typedesc[int]. Just like with regular generic types, when the generic param is ommited, typedesc denotes the type class
12:15:42FromGitter... of all types. As a syntactic convenience, you can also use typedesc as a modifier. ⏎ ⏎ Procs featuring typedesc params are considered implicitly generic. They will be instantiated for each unique combination of supplied types and within the body of the proc, the name of each param will refer to the bound concrete typ ... [https://gitter.im/nim-lang/Nim?at=5d5a92eebfd2887f531b3808]
12:16:36clyybberkrux02: Are other typclasses not bind many?
12:16:43FromGitter<zah> well, now the manual is wrong, because someone did some stupid find and replace without looking at the final result. This particular sentence is not true: "typedesc as a modifier."
12:16:44livcdwhoa i just swapped oldwinapi with winim in a lib and it magically works
12:16:52krux02clyybber: nope
12:16:57krux02only typedesc is bind many.
12:17:14FromGitter<zah> not true. `auto` is bind many as well
12:17:15krux02This bind many feature is a very harmful feature of Nim.
12:17:39FromGitter<zah> and you can introduce your own bind many types in type sections ⏎ `type AnyTuple = distinct tuple`
12:18:17krux02zah: yea, we have to forbid that one.
12:18:22krux02first deprecation only
12:18:33krux02eventually forbidding and then removal in the compiler.
12:18:45krux02Bind many is a harmful feature.
12:18:47krux02Hard to teach
12:18:51krux02hard to understand
12:18:56krux02not valuable.
12:18:58FromGitter<zah> then make sure `auto` is not bind many as well. you are just fighting pointless battles imo
12:19:22clyybberYeah, either go all the way, or don't go at all
12:19:25*nc-x15 quit (Remote host closed the connection)
12:20:47krux02zah: Now that you mention auto, I think I should actually put a warning in the compiler to use explicit generics for `auto` parameters as well.
12:20:48clyybberkrux02: Bind many isn't that hard to understand IMO. Just document that every typedesc parameter introduces one generic param each
12:23:06FromGitter<zah> well, since you are executing on Araq's will here, make sure to ask him what he thinks about `auto`. He was the one that made it bind many. There used to be a separate type called `any` for this.
12:23:16krux02zah: I don't want to destroy important code at all. I also won't break what we have currently. It will all start out as a warning message. If you find problems examples that really become harder to understand with explicit generic parameters, or examples where you really don't know how to rewrite the code so that it doesn't have an implicit generic parameter, please report it. The overall goal is to make the language
12:23:16krux02cleaner.
12:24:02clyybberBut why not make bind many default?
12:24:07FromGitter<zah> so, your goal is to remove implicit generic parameters from the language? wow
12:24:09krux02I already said it, I consider "bind many" typeclasses as a harmful feature. They don't solve a problem. And every feature that a language has that programmers need to be aware of devalues the language.
12:24:22krux02zah: I did not say that
12:24:41clyybberkrux02: But how are they harmful? As opposed to bind once?
12:25:06krux02I said it earlier. I would have preferred if Nim never got implicit generic parameters. But I won't remove them as I think it is too late to get rid of them.
12:25:21clyybberBut you cripple them to death
12:25:40clyybberHow is bind once a good default for any typeclass?
12:26:03krux02But I want to get rid of all implicit generic parameters for things that are tagged as bind many. Then when no "bind many" typeclass actually uses it's bind-many feature, I think it is time to disable bind many behavior.
12:26:38krux02"bind many" is the harful thing that I want to destroy.
12:26:54FromGitter<zah> As I said, I don't think Araq will agree to make `auto` bind once
12:27:02clyybberYeah, but why? It really is not as hard to understand as you make it seem to be
12:27:51clyybberkrux02: Why not make it so that if you want bind once behaviour you should use explicit generic parameters.
12:28:39disruptekhmm, that's not crazy.
12:29:39clyybberIt also has the bonus that it is not that cumbersome to use explicit generic parameters for bind once, since you only want one.
12:29:49krux02clyyber: how many generic parameters does this function have: ``proc high*[I, T](x: array[I, T]): I {.magic: "High", noSideEffect.}``
12:30:23clyybberkrux02: Does it matter?
12:30:32krux02yes it does.
12:31:07*PMunch quit (Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number)
12:31:13FromGitter<zah> I've considered "bind many" as the default when I started, but it seemed that a lot of code that is "arithmetic" is the mathematic sense wants multiple parameters of the same type and frequently uses a result matching the type of the inputs
12:31:44*PMunch joined #nim
12:32:07FromGitter<zah> So, "bind once" seemed like the better default, because adding a modifier to your type class is not that hard
12:32:47krux02whatever the default is, there should not be both "bind once" and "bind many" in the same language.
12:33:05FromGitter<zah> well, that's your opinion. better run it though Araq
12:33:12clyybberzah: But making "bind once" using explicit generic parameters is a lot more smaller and simpler than doing the same for "bind many"
12:34:16krux02zah: don't worry, everything I do is checked with Araq.
12:34:33krux02Generally he is on my side. He also things that something about typedesc has to be done.
12:34:55clyybber"bind once" as a default also only seems sane if you look at `x, y: someTypeClass` but gets very unintuitive when you have `x: someTypeClass, aBool: bool, y: someTypeClass`
12:35:51clyybberkrux02: I agree that "bind once" and "bind many" behaviour in the same language is not good. But I'd argue that "bind many" is the better default.
12:36:36krux02clyybber: but "bind many" is the one we could pretty easily get rid of.
12:37:06krux02it would only affect typedecs and auto as far as I can tell.
12:37:20krux02And auto can be treated as totally special anyway.
12:37:58clyybberkrux02: I think "bind once" isn't so hard to get rid of as you think
12:38:01krux02in my opinion auto is not really a type.
12:38:01FromGitter<alehander42> guys, should async traceback always include the "normal" traceback
12:38:06FromGitter<alehander42> or do i need a flag for that
12:38:31clyybberOptionally you could make `x, y: type` "bind once" and `x: type, y: type` "bind many"
12:38:50clyybberkrux02: WDYT about that?
12:38:59clyybberzah: Wdyt?
12:39:13FromGitter<zah> The problem is how do you treat the result type
12:39:19krux02clyybber: nope you can't
12:39:25clyybberWhy?
12:39:30FromGitter<alehander42> hm, probably i need stacktrace:on, solved
12:39:59FromGitter<zah> proc `cross(a, b: Vector): Vector`
12:40:42FromGitter<alehander42> can't we require explicitness for "bind many" typedesc-s and leave "bind once" implicit
12:40:55clyybberzah: When we make "bind once" the default for `a, b: Vector` it wont be ambiguous?
12:41:14*adeohluwa joined #nim
12:41:27FromGitter<zah> the current rules say that both `a` and `b` and the result will have the same type
12:41:36*laaron quit (Remote host closed the connection)
12:41:50krux02clyybber: we cannot change the default. Too late for that.
12:43:14FromGitter<zah> So, why do we need a special type such as `auto`? How is `auto` so different from `object`?
12:43:15*Guest62213 joined #nim
12:43:31krux02zah: auto isn't a type
12:43:41krux02object is a typeclass
12:43:45clyybberzah: Change the rule to say that the result type will be the first "bind once" type of the same typeclass.
12:44:09krux02auto is merely a marker to explicity state the absence of an explicit type declaration.
12:44:20FromGitter<zah> so, when does something becomes a type class? why is `auto` not a type class?
12:45:45*terps quit (Ping timeout: 250 seconds)
12:45:50clyybberkrux02: With a deprecation period, I think it wouldn't be so hard? Its also a very simple change to adapt to.
12:46:59clyybberkrux02: But `object | tuple | int` is a type class. So I'd argue that auto is the typeclass that contains all typeclasses.
12:47:21krux02clyybber: well, I will begin to deprecated the usage of parameterless typedesc arguments for precedures as this will help a lot of people with their raised issues in Nim.
12:47:32*abm quit (Ping timeout: 245 seconds)
12:48:21FromGitter<zah> you are going to deprecate `proc foo(T: typedesc)`?
12:49:11krux02in ``proc foo[T](t: typedesc[T])`` it is better to use `T` to reference to the type than `t`, because with `t` the compiler needs to strip away the `typedesc`-ness. This is done in 100s of places in the compiler, but it is not guaranteed to work all the time. `T` just works better.
12:49:20krux02zah: yes
12:49:38krux02not template or macro though.
12:49:53krux02in templates and macros the typedesc parameters are used differently.
12:49:53clyybberSo yet another inconsistency?
12:50:13clyybberWell, inconsistency is a bit too much, but you know what I mean
12:50:16*laaron joined #nim
12:50:36krux02I would call it a constraint, or guide.
12:51:15krux02in templates and macros a typeexpression as an argument does make a lot of sense.
12:51:21FromGitter<alehander42> even if this is so, why cant the compiler just convert such signatures to foo<parameter> (<implvar>: typedesc[<parameter>])
12:51:34krux02this type expression can then be expanded in places where it makes sense.
12:52:01krux02I hope that at some point I could bring the typechecker to not lift those typeexpressions into `typedesc` nodes.
12:52:28FromGitter<zah> oh, my, it's getting worse by the minute
12:53:10FromGitter<zah> the problem of the compiler is exactly that a lot of places remain where type expressions are not lifted to the correct typedesc type
12:53:23*adeohluwa quit (Ping timeout: 248 seconds)
12:53:51FromGitter<zah> When I started working on the compiler, it relied a lot on a AST node called `nkType`, where `n.typ` was denoting something like `tyInt`
12:54:11*Guest62213 quit (Quit: Leaving)
12:55:15FromGitter<zah> This was a really broken design for a lot of the code in `typerel` that must handle generic instantiations and typedesc parameters and you strive to get back to such a world
12:56:12FromGitter<zah> I can file some issues to show you just how broken this line of thinking is
12:57:18krux02I can show you some issues that I already raised that can show you how broken the `typedesc` hell is.
12:58:38clyybberkrux02: Before 1.0 its the last chance to change the default. And I think we should get it right.
12:58:42disruptekissue fight!
12:58:58*laaron quit (Remote host closed the connection)
13:00:58*laaron joined #nim
13:01:24krux02zah: https://github.com/nim-lang/Nim/issues/10749
13:07:07*LargeEpsilon quit (Ping timeout: 245 seconds)
13:08:48*LargeEpsilon joined #nim
13:09:11krux02zah: I don't see how a typedesc node and a node of `nkType` is different.
13:11:15FromGitter<zah> for your issue, the user could indeed benefit from helpers that skip things like typedesc nodes or generic `TyGenericInst`, but that's certainly doable ⏎ ⏎ When you rely on things like `nkType`, you cannot discriminate between the value `10` and the type `int`. In typerel, they both arrive as `tyInt`.
13:12:46FromGitter<zah> The difficulty of the situation is greatly increased when the type is produced by a template or a macro. E.g. `ElemType(SomeSeq)`
13:13:57*abm joined #nim
13:14:18FromGitter<zah> ... because you don't have a `nkType` then. You have a `nkCall`
13:16:32krux02I agree that integer literal types are a bit ugly, but they affect other parts of the language.
13:17:56clyybberkrux02, zah: Re: Changing the default bind: I think most procs that rely on "bind once" as the default also have signatures like `x: typeclass` or `x, y: typeclass`, for which "bind once" can stay as a default IMO
13:18:10*MarderIII joined #nim
13:18:25*nc-x quit (Remote host closed the connection)
13:18:54*Kaivo quit (Quit: WeeChat 2.5)
13:19:08FromGitter<zah> You are missing my entire point. `nkType` is a non-workable when any exprsesion in the language can produce a type. We have `nkCalls, nkDots` and bunch of other stuff that must produce `tyTypeDesc` values. I can only hope that the test suite will prevent you from crippling the language, but you'll still lose time trying, so I better warn you now
13:23:53krux02The problem of typedesc that I currently have is the compiler often just doesn't care if something is ``typedesc[int]`` or ``int``. There is just this skipTypes applied so that the two are effectively the same.
13:25:34FromGitter<zah> Yes, but this is only because it was really hard to fix all the `nkType` stuff from the start. I've made great progress towards supporting arbitrary higher-order types correctly (by skipping just one level of typedesc everywhere). We can get there with more work
13:26:36krux02But then you have to document the rules for it.
13:26:40FromGitter<zah> `nkType` is not the only culprit actually. The other broken type is `tyGenericParam` when it appears as a generic type parameter.
13:26:57krux02When is typedesc supposed to be skipped and when is it supposed to be kept?
13:27:30FromGitter<zah> `tyGenericParam` has two different meanings in the compiler. When it's a proc parameter, it acts like `auto`. When it appears as a generic type parameter, it should act as `tyTypeDesc[auto]`
13:28:04FromGitter<zah> This refactoring has proved very hard to execute in the past, but I've made some progress towards it as well
13:28:30krux02What I am working on is to reduce the usage of ``typedesc`` where possible. So instead of fixing all the parts that are still broken, I deprecate the branches of the compiler that are both broken but also expendable.
13:28:48FromGitter<zah> If a fully correctly implemented language, you would always skip just one level of typedesc. And every location that accepts a type will enfore that it was given a typedesc
13:28:51krux02with "broken" I mean "people raised issues"
13:29:14*rockcavera quit (Ping timeout: 272 seconds)
13:29:33FromGitter<zah> Right now a variable declaration such as `var x: T` for example doesn't require the expression supplied as a type to be a typedesc value
13:29:37krux02Well that is something to work for.
13:29:47FromGitter<zah> This is legacy from the `nkType` thinking
13:29:55krux02I had a different idea in mind.
13:30:53krux02use typedesc only for overload resolution in ``proc foo(t: typedesc[int])`` or ``proc bar[T](t: typedesc[T])`` and get rid of all other usages of typedesc.
13:31:05krux02and see how far that one can get me.
13:31:20krux02in my expericen, in proces the `t` argument is never used for anything.
13:32:03krux02s/in proces/in the given procs/
13:36:44*shomodj joined #nim
13:40:26*shomodj_ quit (Ping timeout: 258 seconds)
13:42:53clyybberkrux02: Btw, is Araq not here to chime in on the discussion?
13:43:04krux02nope
13:43:13FromGitter<zah> I don't know what to say. I'll just say that undoing the work of others because you don't care enough to understand it is not the best way to improve Nim. We've already lost LemonBoy for similar reasons
13:43:40clyybberoh, you know why LemonBoy left?
13:43:45FromGitter<zah> But I'll talk to Araq regarding all of this, maybe we'll figure something out
13:47:36clyybberzah: Wdyt about making "x, y: typeclass" bind once and then binding the return type to the only fitting "bind once" typeclass and erroring with an ambiguity error otherwise?
13:48:48*stefanos82 joined #nim
13:50:47FromGitter<zah> seems like a bit too many special rules to me. I definetely agree that `foo(x: SomeT, y: bool, z: SomeT)` is a bit unintuitive, but perhaps not enough to warrant a special rule
13:52:34clyybberzah: But "bind many" and "bind once" behaviour depending on the typeclass is more confusing IMO
13:52:44*adeohluwa joined #nim
13:53:28clyybberThough I agree, I'd have as few as possible special rules.
13:55:14FromGitter<zah> well, the thinking there is that if it's legal for `auto`, why not make it legal for user defined types? You can improve the understandability of the code though following naming conventions. (e.g. the names of bind many type classes can start with `Any*`)
13:55:37disruptekor Auto.
13:56:20clyybberzah: Yeah, I understand your reasoning. But I think that attaching "bind many" vs "bind once" to the type is not a good idea as it only ever comes up in signatures, so I think it should be part of the signatures.
13:57:14clyybberI think with `x, y: typeclass` for "bind once" and otherwise having "bind many" as a default we would have sane defaults
13:58:26disrupteki don't think the semantics should change just because you grouped the arguments; sometimes the argument order is motivated by other concerns, and i personally enumerate each argument and type.
13:59:27FromGitter<alehander42> clybber, but what about x: Vector, y: int, z: Vector and a hypothetical bind-once Vector
13:59:44shashlickquestion - i'm building a static liblzma.a and adding it to passL but symbols it includes are still not resolved
13:59:57shashlicki checked with strings and the symbol is present in the .a file
14:00:06shashlickany suggestions?
14:00:11clyybberdisruptek, alehander42: In those cases you are going to have to use an explicit generic parameter
14:00:30clyybberwhich isn't so bad, since when you want "bind once" its only going to be 1 generic param anyways
14:01:24disruptekyou said `x, y: typeclass` for "bind once".
14:01:33FromGitter<alehander42> honestly i think bind-many has to be explicit and bind-once implicit (so still a(b: Vector) works )
14:02:22clyybberdisruptek: Yeah, but you are always free to use `x, y: typeclass[T]` instead
14:02:43clyybberdisruptek: Its just syntactic sugar, so that procs like `+` dont get ugly
14:03:23*MarderIII quit (Ping timeout: 245 seconds)
14:03:47*adeohluwa quit (Ping timeout: 248 seconds)
14:03:49disrupteki dunno, i'm not seeing the elegance to these rules.
14:04:29clyybberYeah, I'm not fully convinced myself, just proposing to get feedback
14:04:34disruptekshashlick: do you have any working static lib examples?
14:04:51disruptekclyybber: you're fighting the good fight, my man.
14:05:20*PMunch quit (Remote host closed the connection)
14:05:27clyybberThank you disruptek
14:05:33shashlick@disruptek /?
14:05:52shashlicklibz and libarchive get linked properly, not liblzma
14:06:12disruptekah, hmm. and otherwise built the same?
14:06:58disruptekdid you pass -llzma and not -lzma?
14:16:25*adeohluwa joined #nim
14:20:40FromGitter<alehander42> btw proc setPosition*(s: Stream, pos: int)
14:20:44FromGitter<alehander42> shouldnt we have int64
14:20:44FromGitter<alehander42> here
14:21:27FromGitter<alehander42> i can have a 5gb file/string easily these days
14:21:49*i7sDream joined #nim
14:22:25FromGitter<alehander42> maybe this should be overloaded for 32/64bits but i dont know what is the int type for that
14:23:18clyybberint is int32 on 32bit architectures and int64 on 64 bit
14:23:20FromGitter<alehander42> .. which is `int` , so maybe thats fine
14:23:23clyybberSo it is fine as it is
14:23:56FromGitter<alehander42> the issue was that i need to `.int` int64 values which i pass
14:24:14clyybberHuh
14:24:41FromGitter<zah> A 32-bit process can still read a portion of a large file
14:25:04*adeohluwa quit (Remote host closed the connection)
14:25:51shashlick@disruptek - well, i built liblzma.a so i just passed it as is
14:26:01shashlickisn't -llzma for shared so?
14:26:47FromGitter<alehander42> @zah is right, i forgot about that, so yeah, i'll open a pr later
14:30:01*endragor quit (Remote host closed the connection)
14:30:25disruptekshashlick: are you saying -llzma works and static lib doesn't?
14:31:29disruptekbecause my thinking is, rule out static lib issue (which you have) and then rule out symbol issue (which so link could do).
14:33:29shashlickwell, -llzma is using the system lzma
14:33:40shashlicki've built my own static copy from source and want to use that
14:33:57disruptekokay, but does the so version work?
14:34:06shashlickyes
14:34:41disruptekdo you have a static version in the system?
14:34:56shashlickthat's what i've compiled from scratch
14:35:23shashlickcheckout https://github.com/kobolabs/liblzma
14:35:56disruptekare you on linux?
14:36:03shashlick./configure --disable-xz --disable-xzdec --disable-lzmadec --disable-lzmainfo --disable-shared
14:36:04shashlickyes
14:36:24disruptekwhen i say, "on the system", i mean as part of your distro.
14:37:25disrupteki'm asking because i don't actually have one, myself, but you might. if so, you could test linking to it to see if it's an issue with your static build.
14:37:44disruptekyou could also test building a shared version from source and linking against that.
14:38:00shashlickya i have a static one as well, a sec
14:38:10*lritter quit (Quit: Leaving)
14:38:36disruptekif that works, then it looks like an issue with your from-source build.
14:40:40shashlickyep that worked and now stuff from libz.a which i built from scratch is not working
14:42:16*clyybber quit (Quit: WeeChat 2.5)
14:42:17disruptekit's almost like the toolchains are different.
14:42:45*MarderIII joined #nim
14:44:03shashlicknow i am trying to use the system libz.a and again the system liblzma.a symbols are a problem
14:45:03shashlickso libarchive.a depends on liblzma.a and libz.a
14:45:07disruptekthe venn diagram suggests it's a toolchain issue in the lzma.a build. did you test building your own lzma.so and linking that?
14:45:29shashlickdo you need to link those libs as part of libarchive compile time?
14:45:40shashlickor is it only during link time for .a files
14:45:47disruptekonly link.
14:46:06shashlickya so libarchive doesn't complain during build
14:46:33disruptekdo you see your lzma symbols in libarchive.a?
14:47:21disruptekyou can use `nm` instead of `strings` for a better result.
14:49:57shashlickyep they are with a U
14:50:00shashlickprefix
14:51:27disruptekso it doesn't seem like libarchive.a is getting linked with liblzma.a.
14:52:19shashlicki'm creating a test binary that uses libarchive and that's where i'm doing the passL
14:53:26disruptekso that works with the system lzma.a but not your local one. nm them both and see how the symbols differ?
14:54:03*terps joined #nim
14:54:04shashlickwell even system lzma.a doesn't work
14:54:35disruptekyou said "yep that worked and now stuff from libz.a which i built from scratch is not working
14:54:46disruptekthat wasn't a test of the system lzma?
14:54:57shashlickand then when i added the system libz.a as well, it complained about liblzma.a again
14:55:41disruptekwow. 🤪
14:56:21disruptekdoes this link with z.a and lzma.a? int main() {return 0;}
15:08:50*nsf quit (Quit: WeeChat 2.5)
15:10:08*MarderIII quit (Ping timeout: 258 seconds)
15:17:41*Kaivo joined #nim
15:17:51*ZORR0W quit (Ping timeout: 250 seconds)
15:18:29shashlickomg it was just the order in which files are linked
15:18:47shashlickliblzmaa libz.a libarchive.a doesn't work
15:19:01shashlicklibarchive.a liblzmaa libz.a works
15:19:03shashlickridiculous
15:19:13disruptekhow the heck did you figure that out?
15:19:37*endragor joined #nim
15:21:07shashlickdumb luck
15:21:38shashlickwhat sense does that make - don't you usually have to link to stuff before referring to it
15:21:51shashlickmeanwhile, does osx support configure scripts
15:22:09*floppydh quit (Quit: WeeChat 2.5)
15:22:22disruptekit does seem like surprising behavior.
15:23:11disrupteki guess when we link, we do tend to refer to stuff first: .c .c .c .a or .o .o .o .so
15:24:06shashlicklibarchive depends on stuff in the .a after it
15:24:08shashlickso i don't get it
15:24:27shashlickanyway, yet another random piece of info i'll forget in some months and then struggle with again
15:24:40disruptekisn't it great?
15:24:49shashlickor someone will ask and i won't remember how i solved it
15:25:06disrupteki had just cleared a space on my whiteboard to try to figure your problem out, too. 😁
15:27:55shashlickwell, at least now i have a working libarchive wrapper on linux
15:28:02shashlickmy old method was crashing
15:28:48disrupteki'm tired of surfing the tech wave.
15:29:04disrupteki am literally too old for this shit.
15:29:36disrupteki saved my first programs on audio tape 35 years ago.
15:30:03shashlicki cannot compete with that
15:30:19disruptekwho the hell would want to.
15:30:30*nc-x joined #nim
15:30:35shashlick😄
15:31:06disruptekwhat's sad is, i'll tell anyone who'll listen that we're still in the dark ages.
15:31:15shashlicksomehow i can extract bz2 files without including bzip2
15:31:22shashlicki'll agree with that
15:31:36shashlicki still struggle to explain to hw guys why sw is so buggy
15:32:17disruptekhw guys have a different mindset. one i wish more sw guys shared.
15:32:41disruptekbut, then we'd have way less software. on the other hand, it'd probably be bulletproof.
15:33:33nc-xshashlick: Windows build passes. https://github.com/nim-lang/nightlies/pull/29 is ready to merge.
15:34:05nc-xAlso i think the arm builds need to be commented out in the build matrix. They are taking too much travis time.
15:34:39nc-xThey can be reenabled later when they are fixed.
15:34:56*LargeEpsilon_ joined #nim
15:35:03disruptekfixed how?
15:35:11shashlickneed to build sqlite for arm
15:35:15shashlicknow that IC needs it for build
15:35:19shashlickthanks @nc-x
15:38:34nc-xhttps://www.sqlite.org/download.html The precompiled binaries for android might be usable
15:38:46*nc-x quit (Remote host closed the connection)
15:39:03*LargeEpsilon quit (Ping timeout: 268 seconds)
15:39:13*LargeEpsilon_ quit (Ping timeout: 245 seconds)
15:46:43*narimiran quit (Ping timeout: 245 seconds)
15:48:13*rockcavera joined #nim
16:06:36*snooptek quit (Remote host closed the connection)
16:07:14*snooptek joined #nim
16:16:46shashlicknow that nim requires sqlite, do we need to provide it in all our arm nightly builds?
16:23:17*terps quit (Ping timeout: 250 seconds)
16:26:26FromGitter<awr1> hasn't nim required sqlite for a long time
16:26:34FromGitter<awr1> i thought the compiler used it internally
16:26:46shashlickwell, i need to statically link it anyway in arm so it will be built in
16:26:58shashlickcause all arm builds are static so that pcre, glibc, etc. is available
16:27:48FromGitter<awr1> what do you use for arm development?
16:27:57FromGitter<awr1> or are you just cross compiling
16:28:16shashlickcross compiling with dockcross
16:28:29shashlickhttps://github.com/nim-lang/nightlies/blob/master/dx.sh
16:37:57*i7sDream quit (Ping timeout: 245 seconds)
16:38:25*endragor quit (Remote host closed the connection)
16:40:21*i7sDream joined #nim
16:42:42*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:50:13*terps joined #nim
16:50:43*MarderIII joined #nim
16:51:46*i7sDream quit (Ping timeout: 246 seconds)
16:58:45FromGitter<Varriount> Does the compiler use SQLite? For what?
16:59:24shashlickincremental compilation
17:07:17*wildtrees joined #nim
17:09:31*wildtrees quit (Max SendQ exceeded)
17:19:38*clyybber joined #nim
17:21:39*terps quit (Ping timeout: 264 seconds)
17:33:13*narimiran joined #nim
18:10:03*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
18:10:41*Jjp137 quit (Read error: Connection reset by peer)
18:11:57*Jjp137 joined #nim
18:13:37*laaron joined #nim
18:23:57*joki1337 joined #nim
18:31:54*nsf joined #nim
18:39:48*ZORR0W joined #nim
18:45:20*joki1337 quit ()
18:47:12ZevvWhat is the proper way to check if I can do a copyMem? when defined(js) and not defined(vm)? Or is there some common thing to check for?
18:49:18FromGitter<Varriount> Zevv: `when declared(copyMem)`?
18:50:18Zevv"rror: limited VM support for 'addr'
18:53:22Zevvwell, it's only about one percent faster, nevermind :)
19:12:17*ZORR0W quit (Ping timeout: 250 seconds)
19:13:56*MarderIII quit (Ping timeout: 258 seconds)
19:14:28clyybberZevv: What are you working on?
19:16:26Zevvsome npeg optimizations
19:17:54*ZORR0W joined #nim
19:17:54*jmiven left #nim ("WeeChat 2.4")
19:19:14*MarderIII joined #nim
19:21:07jxyHow do you pass extra parameters to tasks defined in nimble file?
19:21:51jxyparamStr used to work, but now extra arguments do not show at all
19:23:03Zevvbtw clyybber, the question came up a few days ago: is there any estimate how "finished" the newruntime is at this time? Are there still big unknowns, or is the end in sight?
19:24:02jxysaw the regression issue: https://github.com/nim-lang/nimble/issues/633#issuecomment-513071570
19:24:39clyybberZevv: The core is pretty much finished.
19:25:31Zevvsweet!
19:25:49clyybberI'm currently reworking the code a bit, but it wont change functionality
19:27:01Zevvso, I'll give json another try, maybe you can help me out with the last bits then
19:27:08clyybberSure
19:34:05Zevvok, what I basically do is change all JsonNode into owneds.
19:34:18ZevvThe first thing I run into is "Error: '=' is not available for type <owned JsonNode>; requires a copy because it's not the last read of 'b';"
19:34:38Zevvwhat is the typical problem here?
19:42:07*rheoli joined #nim
19:45:15*rheoli quit (Client Quit)
19:48:12clyybberZevv: The problem is that owned refs cannot be copied.
19:48:26clyybberSo the compiler needs to be able to turn them into moves
19:48:42Zevvor I need to do an explicit deepCopy?
19:49:11clyybberZevv: Depends, probably not. Do you have the code uploaded somewhere?
19:49:28ZevvNot yet, just hacking away a bit for now to see what happens
19:49:59ZevvI got my own stuff running with newruntime a month a go or so, but it broke again. I have some json dependencies, but it seems that there are some more things that need fixing
19:50:13Zevvso I whenned out the json code for now, one thing at a time :)
19:50:16clyybberBtw, I think Araq said once that for the JSon module it isn't reasonable/possible to use owned refs
19:50:28clyybberSo you can just use regular refs instead
19:50:42Zevvwhy is that? in the end it is just a tree, right?
19:51:05disrupteki think the problem is `to`.
19:51:08clyybberYeah, I don't know, maybe he didn't even say that
19:51:37clyybberZevv: But what happens when you just use regular refs?
19:52:57Zevvcurrently doing some json stuff gives "cannot return an owned pointer as an unowned pointer; use 'owned(JsonNode)' as the return type
19:53:12Zevvjson.nim:191
19:53:49clyybberOk, with an unedited json.nim?
19:54:44Zevvyes
19:55:14Zevvoh and right, now I remember: my own project gives C gen issues with redeclerations :/
19:55:18Zevvso two problems here :)
19:55:44clyybberAh ok. Well C gen issues are most likely bugs
19:55:54Zevvof course
19:56:35clyybberZevv: Can you add an unowned to json:171
19:56:42FromGitter<iffy> the wrapSocket docs (https://nim-lang.org/docs/net.html#wrapSocket%2CSslContext%2CSocket) say "Disclaimer: This code is not well tested, may be very unsafe and prone to security vulnerabilities."
19:56:49clyybberso that it says `= unowned ref JsonNodeObj`
19:56:58FromGitter<iffy> What needs to happen for there to be some confidence that `wrapSocket` is secure?
19:57:02*MarderIII quit (Remote host closed the connection)
19:57:11Zevvaah, "unowned". What is the exact semantic difference between "unowned" and nothing at all?
19:57:30*MarderIII joined #nim
19:57:33clyybberIt confuses me too rn, I thought unowned would be the default
19:58:05Zevvmy compiler does not yet know what unowned means :)
19:58:16clyybberOooh, which version are you on?
19:58:19FromGitter<alehander42> it's still young
19:58:28clyybberFor newruntime stuff I suggest using #devel
19:59:07Zevvpretty recent devel, but I'm booting todays version now
19:59:22FromGitter<iffy> rather, is there a way to confidently host an SSL service with Nim right now?
20:00:45*nsf quit (Quit: WeeChat 2.5)
20:04:35Zevv/home/ico/external/Nim/lib/pure/json.nim(171, 15) Error: undeclared identifier: 'unowned'
20:05:10clyybberHuh. Ok then unowned should indeed be the default.
20:06:48clyybberAh
20:07:10clyybberI know, Zevv can you try adding an unown before the object constructors?
20:07:26clyybberApparently object constructors return an onwed ref by default.
20:10:09*shomodj joined #nim
20:11:56Zevvah unonwn :)
20:13:02*MarderIII quit (Quit: Leaving)
20:15:20Zevvlike a charm
20:18:24clyybberNice
20:19:11clyybberZevv: Do you have a reproducable test case for your C gen issue?
20:19:13FromGitter<iffy> It looks like net wrapSocket uses OpenSSL underneath. What, then, are the security concerns that warrant the disclaimer?
20:20:10clyybberiffy: I think those are there because it hasn't been formally verified by a security researcher, whatever that means
20:20:12FromGitter<iffy> I'm motivated (though perhaps not completely qualified) to do the work to remove that disclaimer
20:20:36Zevvclyybber: I'll try to make a minimal exampel for the codegen issue. I have a template generating a proc using templates, and it seems that closures are redefined somehow
20:23:32clyybberZevv: Can you reproduce it on #devel? Araq has implemented support for clousers about a month ago I think
20:23:56Zevvyes I can reproduce, running todays nim
20:24:23Zevvbut I have a hard time reducing
20:25:23Zevvit is a symbol that does not get mangled inside a template it seems
20:32:00*narimiran quit (Remote host closed the connection)
20:33:15clyybberHmm, when your code is open source, I don't think it will be a problem cloning a git repo to reproduce.
20:33:23clyybberWell, Imma be off and get some sleep
20:33:27clyybberGood night
20:33:29*clyybber quit (Quit: WeeChat 2.5)
20:33:34Zevvgood night.
20:34:24ZevvFor tomorrow: my problem seems to be caused by the fact that all variables on the stack frame moved from nested blocks to the top level of the C function with newruntime, and now some names clash.
20:42:29*solitudesf quit (Ping timeout: 258 seconds)
20:56:18*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:00:36*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
21:00:55*laaron joined #nim
21:01:01*stefanos82 quit (Quit: Quitting for now...)
21:01:33*shomodj joined #nim
21:01:43*actuallybatman joined #nim
21:05:52*shomodj quit (Ping timeout: 245 seconds)
21:07:17*shomodj joined #nim
21:15:20*abm quit (Quit: Leaving)
21:16:28*laaron- joined #nim
21:16:56*NimBot joined #nim
21:31:07*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:49:57*LargeEpsilon_ joined #nim
21:54:12*LargeEpsilon_ quit (Ping timeout: 248 seconds)
22:39:11*cyraxjoe joined #nim
22:50:02*shashlick quit (Remote host closed the connection)
23:07:06*krux02_ joined #nim
23:10:16*krux02 quit (Ping timeout: 264 seconds)
23:13:19FromDiscord_<exelotl> hey, is newruntime usable on the latest stable release, or is it recommended to use the devel branch?
23:25:42*krux02_ quit (Remote host closed the connection)
23:27:35*aq60 joined #nim
23:27:45rayman22201devel
23:31:32aq60hi
23:31:43aq60how to reset object to zero?
23:32:10aq60or lets say, array[64, char]
23:34:50rayman22201https://nim-lang.github.io/Nim/algorithm.html#fill%2CopenArray%5BT%5D%2CT
23:35:30rayman22201That's the safe way.
23:43:40aq60tnx!
23:43:59rayman22201np