<< 20-01-2018 >>
00:08:26*devdri joined #nim
00:09:02*devdri quit (Client Quit)
00:11:03*devdri joined #nim
00:33:08GitDisc<Lite5h4dow> are there any god GUI modules for Nim?
00:33:15GitDisc<Lite5h4dow> goor*
00:33:21GitDisc<Lite5h4dow> good**
00:37:34*user0 joined #nim
00:37:52Calinounope
00:38:00CalinouQt is hell to bind, so nobody bothers binding Qt
00:38:04Calinouonly Go has a semi-working Qt binding…
00:38:13GitDisc<Lite5h4dow> o.o
00:38:14Calinouand since Qt is the only relevant GUI framework outside of Electron… :|
00:38:38GitDisc<Lite5h4dow> Rip
00:38:46GitDisc<Lite5h4dow> is electron any easier?
00:40:31GitDisc<Lite5h4dow> i know Atom is build with it
00:40:55GitDisc<Lite5h4dow> built*
00:42:10user0Hi guys, Where am I doing generic instantiation wrong?
00:42:19user0https://play.nim-lang.org/?gist=229af510a01901fdb876f2b46270ee66
00:42:55GitDisc<Lite5h4dow> thats beyond mt
00:43:06GitDisc<Lite5h4dow> idk why your using [T] everywhere
00:46:19user0For generic types?
00:46:25GitDisc<Lite5h4dow> ah ok
00:51:04*yglukhov joined #nim
00:55:26*yglukhov quit (Ping timeout: 256 seconds)
01:00:27*MJCaley joined #nim
01:12:29*yglukhov joined #nim
01:13:54*couven92 quit (Read error: Connection reset by peer)
01:14:38*Amrykid quit (Ping timeout: 276 seconds)
01:16:47*yglukhov quit (Ping timeout: 248 seconds)
01:29:57*arnetheduck joined #nim
01:38:50*devdri quit ()
01:45:49*vivus quit (Quit: Leaving)
01:58:28*endragor joined #nim
02:03:27*endragor quit (Ping timeout: 268 seconds)
02:03:38*sz0_ joined #nim
02:04:03*sz0_ is now known as sz0
02:17:49*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
02:43:11*MJCaley quit (Quit: MJCaley)
02:44:51*Amrykid joined #nim
02:55:33*vlad1777d quit (Ping timeout: 264 seconds)
02:59:17*chemist69 quit (Ping timeout: 256 seconds)
02:59:48*craigger quit (Quit: bye)
03:06:20*marenz_ quit (Ping timeout: 256 seconds)
03:07:36*Amrykid quit (Quit: Leaving)
03:13:11*chemist69 joined #nim
03:20:03*yglukhov joined #nim
03:24:27*yglukhov quit (Ping timeout: 240 seconds)
03:24:31*craigger joined #nim
04:05:49*endragor joined #nim
04:06:22*arthurz joined #nim
04:06:26*endragor quit (Remote host closed the connection)
04:06:54*endragor joined #nim
04:17:55FromGitter<Quelklef> Found a possible bug: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a62c2f2e0141226506a0e06]
04:18:04FromGitter<Quelklef> Is this an issue or does `auto` not work how I think it does?
04:24:32FromGitter<Quelklef> I should not that `echo meth(c)` indeed prints "no compiler ... type"
04:32:40arthurz@Quelklef then `auto` inferred string as the datatype. Which works as expected
04:33:08FromGitter<Quelklef> Sure, but shouldn't it complain about a baseless method?
04:33:21FromGitter<Quelklef> iirc if it were `method meth(c: Child): string`, it would yell at me
04:33:57arthurzIMO base plays no role here
04:35:24FromGitter<Quelklef> ... Shouldn't it? Baseless methods aren't allowed. This is a baseless method.
04:37:59arthurzSince `Child` belongs to `Parent` it is not (IIRC)
04:38:39*endragor quit (Remote host closed the connection)
04:38:48FromGitter<Quelklef> But it is, since it's a different method.
04:39:14FromGitter<Quelklef> Well, I don't think procs/methods with the same signature but different return types are allowed anyway
04:39:29FromGitter<Quelklef> so really *that* should be noticed by the compiler
04:40:24FromGitter<Quelklef> But the error it gives when `meth(Child)` has an explicit signature is a baseless error, which is sufficient...
04:40:55*endragor joined #nim
04:43:26arthurzIn the manual about the Multi-Methods `method eval(e: Expression): int {.base.} =
04:43:27arthurz # override this base method
04:43:27arthurz quit "to override!"
04:43:27arthurzmethod eval(e: Literal): int = return e.x`
04:43:42arthurzthe method is named the same
04:45:22FromGitter<Quelklef> Right, and shares the same return type
04:54:28*dddddd quit (Remote host closed the connection)
05:06:26*arthurz quit (Ping timeout: 255 seconds)
05:06:42*arthurz joined #nim
05:15:03*user0 quit (Quit: user0)
05:17:21*arthurz quit (Quit: Leaving)
05:29:57*tefter joined #nim
05:42:49*yglukhov joined #nim
05:47:45*yglukhov quit (Ping timeout: 263 seconds)
06:22:47*sz0 quit (Quit: Connection closed for inactivity)
06:28:50*endragor quit (Remote host closed the connection)
06:29:18*endragor joined #nim
06:29:18*endragor quit (Remote host closed the connection)
06:31:09*endragor joined #nim
06:51:45*yglukhov joined #nim
06:55:57*yglukhov quit (Ping timeout: 240 seconds)
06:57:17*nsf joined #nim
07:16:42*sz0 joined #nim
07:17:13*vlad1777d joined #nim
07:25:22*azur_kind joined #nim
07:27:00*azur_kind quit (Client Quit)
07:58:40*miran joined #nim
08:00:24*yglukhov joined #nim
08:04:49*yglukhov quit (Ping timeout: 268 seconds)
09:04:29*gmpreussner quit (Ping timeout: 255 seconds)
09:05:22*gmpreussner joined #nim
09:10:46*Yardanico joined #nim
09:14:58*xkapastel quit (Quit: Connection closed for inactivity)
09:33:33*Trustable joined #nim
09:39:43*yglukhov joined #nim
09:43:57*yglukhov quit (Ping timeout: 240 seconds)
09:44:31*endragor quit (Remote host closed the connection)
09:44:34*devdri joined #nim
09:45:01*endragor joined #nim
09:55:42*endragor quit (Remote host closed the connection)
09:56:16*endragor joined #nim
10:18:48FromGitter<alehander42> @Araq, do you have any idea what might be causing me great trouble with using EventHandlers while updating to newer karax ? a lot of top level & anon proc-s with (ev: Event, v: VNode) signature just don't match the type anymore and I can't even find a pattern (some of them can be casted to it, some not)
10:20:46FromGitter<alehander42> on the other hand a lot of the proc-s with the same signature just work, it's puzzling
10:25:23FromGitter<alehander42> also why is it using its own version of stdlib dom, shouldn't stdlib dom be just updated with the new stuff?
10:25:47*user0 joined #nim
10:27:58Araqmaybe
10:28:15Araqthere was a recent bugfix that might cause these regressions
10:28:29Araqany example to reproduce will do
10:32:59FromGitter<alehander42> sorry, obviously I've introduced some procs which take dom.Event instead of kdom.Event accidentally
10:33:59FromGitter<alehander42> still not sure why kdom should be a fork of stdlib dom, some fields seem to be missing(maybe they're outdated dom model?) etc
10:35:32AraqI preferred to make some breaking changes without deprecation path
10:35:52Araqand wanted to be more lax about the type hierarchy
10:36:00Araq(Element vs Node, wtf)
10:36:32AraqI didn't do that but it seemed a good idea to have kdom
10:42:19FromGitter<alehander42> sounds fair, still I guess if there are no bigger differences, it might be useful to upstream them
10:46:28*yglukhov joined #nim
10:46:33AraqPRs are welcome
11:00:21*devdri quit ()
11:08:11*miran_ joined #nim
11:10:58*endragor quit (Remote host closed the connection)
11:11:24*miran quit (Ping timeout: 256 seconds)
11:11:26*endragor joined #nim
11:13:07*miran_ is now known as miran
11:30:50*Vladar joined #nim
11:33:52*Snircle joined #nim
11:33:55*yglukhov quit (Remote host closed the connection)
11:34:28*yglukhov joined #nim
11:38:57*yglukhov quit (Ping timeout: 240 seconds)
11:43:20*couven92 joined #nim
11:44:30*solitudesf joined #nim
11:46:29FromGitter<Bennyelg> Do we have something like goFMT to align file?
11:54:36dom96nimpretty
11:54:52dom96although I don't think it's ready
11:58:12federico3Bennyelg https://github.com/FedericoCeratto/nimfmt
11:58:39federico3but it's in alpha stage
12:06:36*dddddd joined #nim
12:13:09user0Hi, I have a stack allocated object. How can I pass a reference to the object? https://play.nim-lang.org/?gist=3390085458a7adb5eac72f2a20109429
12:15:14*yglukhov joined #nim
12:16:35*endragor quit (Remote host closed the connection)
12:17:14FromGitter<Varriount> user0 You
12:17:16*endragor joined #nim
12:17:19*endragor quit (Remote host closed the connection)
12:18:01FromGitter<Varriount> user0: Why do you need to pass a reference?
12:21:03user0It should yield a better performance than copying the object. Furthermore, passing by reference lets me mutate the object. As for the example, `abeObj` is passed as an object to `$`() However I want to pass its reference to the overloaded `$`()
12:21:16dom96'var PersonObj'
12:21:18*endragor joined #nim
12:21:38dom96note, AFAIK the compiler already performs this as an optimisation when it makes sense
12:25:49user0dom96: Thanks. But if I define `&`() this way: `proc `$`(person: var PersonObj): string =`, $abeObj still chooses `proc `$`(person: PersonObj): string =`. It makes sense that abeObj picks the latter `$`() but is there a way to forcefully pass by its ref?
12:26:55dom96Ah well, on line 17 you're defining it as an immutable variable
12:27:16dom96so you can change that 'let' to 'var'
12:27:59FromGitter<ZarsBranchkin> Hah, stumbled upon this thread and decided to see, if I can match the performance via Nim https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/
12:28:27user0Nice, thanks. What magic just happened: :D
12:28:35FromGitter<ZarsBranchkin> Real happy that I did indeed manage to get same throughput as the yes written in native C
12:30:08FromGitter<alehander42> also, @Araq is there an idiomatic way to somehow mark a view as "ready/cached" for a certain redraw?
12:30:44FromGitter<alehander42> so e.g. influence how does it redraw a list of n elements and make it actually redraw just m of those n
12:31:31dom96ZarsBranchkin: nice! You should write about it to spread the news :)
12:32:09FromGitter<ZarsBranchkin> Here is how it looks: https://gist.github.com/ZarsBranchkin/aa9387d11c42d4cdd439191ecbb30499
12:32:17FromGitter<ZarsBranchkin> Not even that ugly, hah
12:37:27dom96heh, that's pretty short
12:37:46dom96seriously though, if you want to write a guest post on nim-lang.org I'd be happy to publish it
12:39:06FromGitter<ZarsBranchkin> Hm, alright, will see!
12:41:14FromGitter<alehander42> btw I use locally a `hasKey()` with `JsAssoc` and also a concept that matches common usages of Table and JsAssoc. would that be useful for stdlib or it doesn't sound idiomatic
12:41:20dom96great, let me know if you do decide to write something :)
12:44:15miranspeaking of writing.... i hope to have basic nim tutorial (for people with no experience with other languages) ready for v0.18 (Araq said this might happen before FOSDEM)
12:46:33dom96awesome
12:46:49dom96but you don't have to sync up the release of that with v0.18
12:47:05dom96in fact it will give more exposure to release it at a different time
12:47:40miranindeed
12:48:42miranbut this is something that keeps me motivated to do it reasonably quickly, and not to stretch it for couple of months ;)
13:04:38*marenz_ joined #nim
13:20:36*user0 quit (Quit: user0)
13:20:50*user0 joined #nim
13:24:55*natrys joined #nim
13:30:03FromGitter<mratsim> Oh I stumbled upon that: https://hastysite.h3rald.com/
13:30:17FromGitter<mratsim> Nim static website generator
13:35:07*user0 quit (Quit: user0)
13:35:21*user0 joined #nim
13:36:33*devdri joined #nim
13:45:41*devdri quit ()
13:53:41FromGitter<survivorm> concept is little foreign to me. What exactly does it do? directory structure and syntactic sugar for adding new"pages"?
13:55:50*Trustable quit (Remote host closed the connection)
13:56:55*Trustable joined #nim
13:57:22*devdri joined #nim
13:59:21*stevenfx joined #nim
14:04:35*MJCaley joined #nim
14:08:31*marenz_ quit (Ping timeout: 248 seconds)
14:08:50*vlad1777d quit (Ping timeout: 260 seconds)
14:15:14*MJCaley quit (Quit: MJCaley)
14:18:41*endragor quit (Remote host closed the connection)
14:19:13*endragor joined #nim
14:30:39*stevenfx quit (Quit: Leaving)
14:36:08*nsf quit (Quit: WeeChat 2.0.1)
14:39:51*devdri quit ()
14:43:23*azur_kind joined #nim
14:51:05*devdri joined #nim
14:54:44*devdri quit (Client Quit)
15:40:47*vlad1777d joined #nim
15:42:54*PMunch joined #nim
15:46:49dom96alehander42: hah, I was about to reply to your comment with a Nim suggestion: https://news.ycombinator.com/item?id=16193159
15:47:14dom96then I noticed you posted that :)
15:52:32*Boomerang joined #nim
16:13:14*MJCaley joined #nim
16:21:08*BitPuffin joined #nim
16:25:39*miran quit (Quit: Konversation terminated!)
16:28:15*miran joined #nim
16:47:56FromGitter<Bennyelg> hey, anyway I can make an overload functions? ⏎ e.g ⏎ x.create().modify().apply() ?
16:48:09FromGitter<Bennyelg> like returning self or this
16:50:12FromGitter<Quelklef> oh, hey, I actually have a good idea for that
16:50:23FromGitter<Quelklef> try something like this (I have no idea if it'll work):
16:50:26miranit should be doable
16:50:48FromGitter<Quelklef> ```template `^^`(value, proc: untyped): untyped = ⏎ value.proc() ⏎ value``` [https://gitter.im/nim-lang/Nim?at=5a6373685ade18be399eef84]
16:50:49FromGitter<ZarsBranchkin> Just create a proc that takes object as first argument and return the same object: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a6373695ade18be399eef87]
16:51:07FromGitter<Quelklef> @ZarsBranchkin that will work, but it means you can't return anything else, such as a success value.
16:51:22FromGitter<Quelklef> Which will get real hairy if you have some procs which return `this` and some which return other things
16:51:45FromGitter<Quelklef> But @miran if that `^^` thing works then you could do `x^^create()^^modify()^^apply()`.
16:52:08FromGitter<Bennyelg> interesting.
16:52:34FromGitter<Quelklef> I put thought into this problem like 6 months ago I'm so glad my idea can actually be used lol
16:52:50miranapply will work on the thing that modify returns, which will work on the thing that create returns
16:53:01FromGitter<ZarsBranchkin> True, also, might be neat to replace `^^`with `->`
16:53:07FromGitter<Bennyelg> yea
16:53:10FromGitter<Quelklef> Right, ^^ is super ugly
16:53:12FromGitter<Bennyelg> I'll check for this one night
16:53:14FromGitter<Bennyelg> now*
16:53:15miranthe easiest way is the thing that zarsbranchkin mentioned
16:53:24FromGitter<Quelklef> I think -> is kinda ugly, too, though, takes a lot of keystrokes
16:53:47FromGitter<Quelklef> wb `::`
16:53:54FromGitter<Quelklef> I think that's a valid operator name?
16:54:11FromGitter<ZarsBranchkin> Ah, hah, that's also a thing.. Hm, probably, it's not really used anywhere else, is it
16:54:33FromGitter<Quelklef> Unless this is actually Haskell and not Nim : P
16:54:45FromGitter<Bennyelg> I tried to put the template you gave me
16:55:14FromGitter<Quelklef> I'm assuming it didn't work?
16:55:28FromGitter<Bennyelg> no I just overcome the underscore
16:55:30FromGitter<ZarsBranchkin> ah, it doesn't work, the `::` as operator
16:55:31FromGitter<Bennyelg> which wasn't valid
16:55:35FromGitter<Bennyelg> let see in a minute
16:55:44FromGitter<Quelklef> @ZarsBranchkin shoot
16:55:57miranhttps://play.nim-lang.org/?gist=1be7ede9cd4bff651e398096cf9f6f1a
16:56:00FromGitter<Quelklef> @Bennyelg ok, cool. The code I put in the chat was 100% untested, lol
16:56:12mirani don't see why chaining with dot will not do the trick
16:56:18FromGitter<Quelklef> beacuase
16:56:24FromGitter<Quelklef> that only works on functions that map type T to T
16:56:40FromGitter<Quelklef> It's a special case which requires no extra work
16:56:45FromGitter<ZarsBranchkin> Wait, your code might need `discard value._proc()`, considering that you do expect that it might return something
16:56:50FromGitter<Quelklef> you're right
17:00:05miranquelklef - creating a proc which will do the chaining for procs which modify input "in place" is too ugly?
17:00:47FromGitter<Quelklef> Your solution is ugly because it means we need to keep track of which procs return `this` and which procs return, say, a success value
17:00:49miranquick n dirty: https://play.nim-lang.org/?gist=ef65956d8179a6fdf60db6250ad5b7bf
17:01:01FromGitter<Quelklef> That example only works because the procs map int -> int
17:01:11FromGitter<Quelklef> If we had, say, a mutable `Person` type,
17:01:23FromGitter<Bennyelg> working
17:01:29FromGitter<Quelklef> I may want to do `person->setName("miran")->sayHello()`
17:01:29FromGitter<Bennyelg> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a6375e9ce68c3bc74e0df33]
17:01:35FromGitter<Quelklef> fuck! nice work!
17:01:39FromGitter<Bennyelg> sample
17:01:42FromGitter<Quelklef> I'm so excited about this oh my god
17:01:46FromGitter<Bennyelg> ``````
17:01:53FromGitter<Bennyelg> Cheers
17:01:56*natrys quit (Quit: natrys)
17:01:58FromGitter<Quelklef> will it work for procs with arguments, though?
17:02:03FromGitter<ZarsBranchkin> Yeah, the bonus of custom operator is that you don't have to worry which objects support this behavior, and which don't
17:02:07FromGitter<Quelklef> ^
17:02:22FromGitter<Bennyelg> it should work @Quelklef
17:02:30FromGitter<Quelklef> Unfortunately not working for `point->moveUp(10)`
17:02:37FromGitter<Quelklef> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a63762cae53c159031196eb]
17:02:53FromGitter<ZarsBranchkin> Hm, but you're not passing the arguments to it, or am I missing something
17:03:01FromGitter<Quelklef> Yeah, we need to account for that
17:03:06FromGitter<ZarsBranchkin> Shouldn't you get the rest of the arguments as varargs and pass them to procx() call?
17:03:11FromGitter<Quelklef> I was trying to do it by having procx be untyped, but that didn't work
17:03:13FromGitter<Bennyelg> I'll try to do something
17:03:16FromGitter<ZarsBranchkin> Haven't really messed much with varargs
17:03:27FromGitter<Bennyelg> yea
17:03:28FromGitter<ZarsBranchkin> ah, make sense, him
17:03:31FromGitter<Bennyelg> I am checking varags
17:03:32FromGitter<Quelklef> Well, that wouldn't work because passing > 2 args to operators means you can't do it as infix
17:04:11FromGitter<ZarsBranchkin> i think you need the procx as untyped here, not the value. Well maybe both
17:04:34FromGitter<Quelklef> I'm not sure if its binding like `(point->moveRight)(10)` or
17:04:45FromGitter<Quelklef> `(point)->(moveRight(10))`
17:05:05FromGitter<Quelklef> because if it's the former, some kind of python-esque varargs could work like you're saying
17:05:10FromGitter<Quelklef> but if it's the latter, I think we're busted
17:05:10FromGitter<ZarsBranchkin> well the template asks for proc, so I'd guess the 1. one
17:05:22FromGitter<Quelklef> so we need to partially apply the proc
17:06:02FromGitter<Quelklef> Is there any way to expand varargs?
17:06:14FromGitter<Quelklef> like the `f(*[1, 2, 3])` splat operator in py
17:06:28Araqmacros.unpackVarargs
17:06:29Araqiirc
17:06:43FromGitter<Quelklef> nice, thanks
17:07:41FromGitter<Quelklef> Doesn't look like it, unless that's devel only
17:09:29FromGitter<Bennyelg> Not working for when passing arguments :|
17:10:05FromGitter<Quelklef> Looks like we'd need to pass into the land of (shudder) macros
17:10:14FromGitter<Quelklef> I'm not strong enough, I leave it to you brave soldiers
17:10:35FromGitter<Bennyelg> heheh
17:10:55*Boomerang quit (Quit: WeeChat 1.9.1)
17:12:10Araquse devel
17:13:17FromGitter<Quelklef> devel is scary :-(
17:13:19FromGitter<Quelklef> i will try
17:15:11*nsf joined #nim
17:20:45*MJCaley quit (Quit: MJCaley)
17:21:40FromGitter<mratsim> devel is home
17:22:43mirandevel introduced some bugs affecting me, so i'm staying with the stable for now....
17:29:57*MJCaley joined #nim
17:30:16FromGitter<alehander42> @dom96 ah right, I have to be a bit more lighthearted with go folks :D ⏎ @mratsim I haven't used non-devel from a long time :D
17:32:37FromGitter<Quelklef> You can't discard typeless statements?
17:32:40FromGitter<Quelklef> But why
17:34:10*endragor quit (Remote host closed the connection)
17:34:36*endragor joined #nim
17:36:06*endragor_ joined #nim
17:38:57*endragor quit (Ping timeout: 240 seconds)
17:39:12dom968KG of t-shirts just arrived :D
17:40:32*natrys joined #nim
17:41:14*endragor_ quit (Ping timeout: 276 seconds)
17:51:18Yardanicowow
17:51:43Yardanicomiran, did you report them all? :)
17:57:23miranYardanico: of course
18:26:36*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
18:30:26miranmore nim-spotting on HN: https://news.ycombinator.com/item?id=16192071
18:30:44*MJCaley quit (Quit: MJCaley)
18:33:17*craigger quit (Quit: bye)
18:34:14*devdri joined #nim
18:38:43*devdri quit (Client Quit)
18:49:13*MJCaley joined #nim
18:53:11*Trustable quit (Remote host closed the connection)
18:53:35*craigger joined #nim
18:53:58*craigger quit (Client Quit)
18:54:05*azur_kind quit (Ping timeout: 260 seconds)
18:55:19*Snircle joined #nim
18:58:33*craigger joined #nim
19:05:00*sz0 quit (Quit: Connection closed for inactivity)
19:07:55dom96I don't understand people who think something is a toy if it compiles to C
19:08:50*darithorn joined #nim
19:09:13dom96All this Rust webassembly talk makes me really think we need to invest in creating a Nim webassembly backend
19:09:26*craigger quit (Quit: bye)
19:09:38dom96The ability to compile to JS and WebAssembly would be brilliant
19:11:38PMunchYeah WebAssembly could position Nim to take a large share of that emerging market
19:12:28*darithorn quit (Client Quit)
19:21:21*craigger joined #nim
19:34:54*Ven`` joined #nim
19:37:19*miran quit (Quit: Konversation terminated!)
19:41:29*vivus joined #nim
19:42:59FromGitter<alehander42> I think js's support is also under-marketed, honestly with several more improvements Nim would seem better than typescript (for me) in most aspects
19:45:03PMunchYeah the benefit of being able to use a single language for both front-end and back-end and have good performance for the back-end is really enticing
19:47:33dom96I tried to market it by creating that snake game
19:47:50dom96perhaps that's the wrong way to market this feature
19:47:56*MJCaley quit (Quit: MJCaley)
19:47:56dom96because it didn't make much of an impact
19:48:38dom96Perhaps what we need is some good frameworks that bridge the gap between JS and the C backend
19:51:16*MJCaley joined #nim
19:52:09FromGitter<alehander42> yeah, it has potential for frameworks that can reuse logic on the backend and frontend (*isomorphic* if you wish)
19:53:10FromGitter<alehander42> another good thing is that you can readily reuse a big part of the js ecosystem thanks to the existing typescript definitions
19:53:37*vlad1777d quit (Quit: Leaving)
19:54:23FromGitter<alehander42> I even talked with the dts2nim girl about her tool, something like that and something like `definitely-nim` mirror of `definitily-typed` might give more exposure to the js backend
19:55:35*vlad1777d joined #nim
19:56:02dom96oh, I must have missed this tool
19:56:05dom96that's awesome
19:57:28FromGitter<alehander42> yeah, it's very cool
19:58:47*yglukhov quit (Remote host closed the connection)
20:00:00FromGitter<alehander42> I thought about forking it, but she said she doesn't work currently on nim code, and also these days it's easier to serialize ts ast, so it can be also rewritten in nim
20:00:28FromGitter<alehander42> the only more serious problem is that ts has only the concept of 'number'
20:01:23*MJCaley quit (Quit: MJCaley)
20:01:30FromGitter<alehander42> but most smaller libs honestly have types corresponding either 90% to int-s or 90% to float-s in reality, so a cli switch can be good enough
20:02:11FromGitter<alehander42> or also the py2nim approach with runtime calling functions with `number` args
20:07:52FromGitter<zetashift> @miran WalterBright made some interesting remarks in that thread about compiling to C and how he decided not to go that way
20:08:17FromGitter<zetashift> which is weird cause now they have that -betterC anyway
20:13:33*yglukhov joined #nim
20:17:59*yglukhov quit (Ping timeout: 256 seconds)
20:31:34vivusDoes Nim have the capacity to support backend adoption? Seems like a lot of stuff has to be "re-invented" for basic CRUD backends
20:31:54*MJCaley joined #nim
20:33:23PMunchvivus, what do you mean?
20:33:42PMunchWhy would CRUD be hard to do in Nim?
20:34:01vivusNim doesn't have a Django/Rails type of framework, which almost every other language does. Even Go/Rust do.
20:34:07PMunchI made a simple CRUD server with a mySQL backend using Jester
20:34:44vivusPMunch: A lot of stuff has to be rewritten for it. There aren't things like out-of-the-box auth, etc.
20:35:13PMunchNot really rewritten.. Just made in a library
20:35:17PMunchOr added to Jester
20:35:25dom96yeah, I don't understand why there aren't more web frameworks being written for Nim
20:35:38*thomasross joined #nim
20:36:18vivusI'd love to use Nim for web backends but resources are constrained and we cant expect araq and dom to do unpaid support for every small issue, thus it is easier to just stick to Flask/Django for now
20:37:03*darithorn joined #nim
20:37:09*darithorn quit (Client Quit)
20:40:28dom96Well sure, it requires some time commitment, but once you get going others will be able to take advantage of your work
20:40:30*yglukhov joined #nim
20:41:32dom96If years ago I said "oh well, it's just easier to stick to Python." then Nim would be dead.
20:42:25*MJCaley quit (Quit: MJCaley)
20:48:11*Vladar quit (Quit: Leaving)
20:51:20*couven92 quit (Ping timeout: 260 seconds)
20:51:22vivusWe need maybe a community push to build a web framework. the folks at Crystal are building a Rails-like one
20:55:03*devdri joined #nim
20:55:08dom96I suppose the allure of such a framework is that includes everything
20:55:11dom96*that it
20:55:33PMunchYeah there's definitely a bit of work involved in making a good web framework
20:55:53PMunchBut I think Nim would be a good fit for the task with metaprogramming and C/JS backends
20:55:59dom96I've only used Django so I can't really say much about Rails
20:56:08PMunchPersonally I don't like it
20:56:15PMunchToo much "magic"
20:56:32dom96I'm wondering whether it makes sense to write a more heavy-weight web framework
20:56:38dom96or if I should just continue improving Jester
20:56:54PMunchWe spent a couple days trying to figure out how to change a particularly stubborn pre-defined route before just giving up..
20:57:09PMunchWell Jester is pretty good already
20:57:20dom96hrm, I remember strangely little about my time with Django
20:57:43dom96But what I do remember is that it offered a lot of nice components with regards to auth and db access
20:58:01dom96Perhaps it's "just" a case of replicating those for Jester
20:58:12PMunchYeah, that's the one thing Jester/Nim kinda misses..
20:58:16dom96I do like the idea of a pluggable core rather than a behemoth
20:58:23PMunchYeah, same here
20:58:37dom96Jester is missing "middleware" for that
20:58:40dom96I guess
20:58:43PMunchYeah
20:58:56PMunchThe site I did didn't really have or need auth :P
20:59:06dom96With 500+ stars it'd be a shame to give up on jester
20:59:19dom96and I do need a web framework with auth and good DB support
20:59:31FromGitter<Bennyelg> Question: Why I can iterate over CsvParser if I am pass it throw to a proc?
20:59:32dom96so looks like I'll be working on this soon (TM)
21:00:15FromGitter<alehander42> I don't think that necessarily the creators of the languages should work on every framework or library, just in this case dom96 already has written one, so it makes sense
21:00:19FromGitter<alehander42> @vivus ^
21:00:27*BitPuffin quit (Remote host closed the connection)
21:00:41FromGitter<alehander42> otherwise that's one of the goals of that needed-libraries initiative, giving ideas to people that want to contribute
21:00:52dom96I dunno, maybe the fact that Jester already exists puts off a lot of people from creating another web framework
21:01:01PMunchYeah isn't there a GitHub page for that?
21:01:25FromGitter<alehander42> there are a lot of good devs that would like to create a lib or framework if they know it would be unique in some aspect, so adding to a young language ecosystem is a good opportunity for them
21:01:54PMunchYeah I love to make small libraries and things
21:02:05PMunchCurrently looking at implementing Protobuf
21:02:19PMunchAnd not just wrapping the C version, but writing it in Nim
21:04:36*Jesin joined #nim
21:05:13dom96that would be awesome
21:05:23dom96you could make some nice macros
21:05:32dom96that parse protobuf and output Nim code :D
21:05:58*couven92 joined #nim
21:05:59vivusalehander42 my suggestion was that dom and araq shouldn't work on it and others in the community should. they already do so much for Nim and we would rather have their expertise focused on the compiler/core
21:06:18FromGitter<Bennyelg> how I can do something like this: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a63af4aba39a53f1a3e93ae]
21:08:50FromGitter<Bennyelg> I can't pass a open file to a function?
21:09:19PMunchUhm, yes you can?
21:09:35FromGitter<Bennyelg> so why for example x.take(5) not working
21:09:38FromGitter<Bennyelg> i get an error
21:09:49FromGitter<Bennyelg> I know the num is not considered yet
21:09:54FromGitter<Bennyelg> but simple print not working
21:09:57FromGitter<alehander42> @vivus I agree completely only about the community part
21:10:40*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:11:42PMunchWhat error do you get?
21:12:18FromGitter<Bennyelg> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a63b0b2290a1f4561b3c19a]
21:12:30FromGitter<Bennyelg> type mismatch: got (CsvParser)
21:12:58PMunchYeah
21:13:11dom96"for a 'var' type a variable needs to be passed, but 'file' is immutable"
21:13:16PMunchYour function takes a CsvParser but readRow expects a var CsvParser
21:13:49FromGitter<Bennyelg> I tried var CsvParser in my function
21:14:07dom96And what happened?
21:14:22dom96The compiler needs to suggest changes in this error messages I think
21:14:23FromGitter<Bennyelg> csvql2.nim(42, 11) Error: ')' expected
21:14:25FromGitter<Bennyelg> :D
21:14:36dom96so you must have messed up the syntax somehow
21:14:43dom96file: var CsvParser
21:14:54FromGitter<Bennyelg> thanks
21:15:03vivusbut we've discussed the web framework thing lots of times here before. chicken/egg problem :P
21:15:06FromGitter<Bennyelg> freaking idiot (me)
21:15:12PMunchHaha :P
21:15:14FromGitter<Bennyelg> i did var f: Csvparser
21:15:37FromGitter<Bennyelg> when I am doing var so it's new copy of the csvParser ?
21:15:47dom96no, it's a reference
21:15:48FromGitter<Bennyelg> on proc
21:15:56FromGitter<Bennyelg> oh so its the same
21:16:06PMunchYup
21:16:12FromGitter<Bennyelg> thanks
21:16:15PMunchvar means that it can change the original instance
21:16:27FromGitter<Bennyelg> yea
21:18:27*nsf quit (Quit: WeeChat 2.0.1)
21:18:47FromGitter<tim-st> @dom96 is it possible to store nim objects or tuples as value in redis using your lib? or only string -> string
21:19:24dom96you can serialise the objects
21:19:32dom96using the marshal module
21:19:53dom96or if it's a relatively simple object just use json
21:20:06FromGitter<tim-st> Thanks, is there an example somewhere or a proc existing for this?
21:20:30*miran joined #nim
21:20:40dom96for json: https://nim-lang.org/docs/json.html#unmarshalling-json-into-a-type
21:20:46FromGitter<Bennyelg> @tim-st probably something like pickle
21:20:48dom96and the section just below it as well
21:21:01dom96https://nim-lang.org/docs/marshal.html
21:21:06dom96marshal module has some examples too
21:21:35FromGitter<tim-st> ok, so the idea is to serialize to string and use string -> string?
21:21:45FromGitter<tim-st> I read about`Hashes` type in redis
21:21:52FromGitter<tim-st> thought this one could work
21:23:18FromGitter<tim-st> https://redis.io/topics/data-types
21:23:39FromGitter<tim-st> I never used redis so maybe I'm completely wrong about this type
21:23:54dom96redis is just a key-value store
21:24:07dom96so you can store an object inside some arbitrary key
21:25:00dom96what do you want to store?
21:25:12FromGitter<tim-st> Ok, thanks for your answer. So the common way is really to serialize to string and deserialize? and on update get, deserialize, change, serialize, update?
21:25:38FromGitter<tim-st> just some string -> tuple[string, int, ...] -> ~10 items
21:25:55dom96it depends what you're doing
21:26:59dom96redis' data types are pretty simple
21:27:48dom96I've used it a long time ago though
21:27:55FromGitter<tim-st> If I use deserialize+serialize it's still quicker than mongodb?
21:27:58dom96You should go through its docs to see how to do things
21:28:07FromGitter<tim-st> ok, thanks
21:28:08dom96that I do not know
21:32:04*yglukhov quit (Remote host closed the connection)
21:49:39FromGitter<Quelklef> ```while index < sequence.len: ⏎ let item = sequence[index]``` ⏎ ⏎ Should never fail, right...? [https://gitter.im/nim-lang/Nim?at=5a63b973ae53c1590312c078]
21:49:51FromGitter<Quelklef> Assuming positive index
21:51:02FromGitter<tim-st> if you inc index correctly and len is builtin, yes
21:51:38FromGitter<Quelklef> Something in my code is very, very wrong
21:51:53FromGitter<Quelklef> By the looks of it, `sequence[1]` where `sequence.len == 42` is failing
21:51:57FromGitter<Quelklef> Lord help me
21:52:35*couven92 quit (Ping timeout: 260 seconds)
21:53:15FromGitter<ZarsBranchkin> What kind of error does it even raise? Tough to believe that it would be an index error
21:53:50FromGitter<Quelklef> It is. Turns out, it's cause of wild templating
21:54:03FromGitter<Quelklef> For some reason, the printed stack trace led me to the wrong proc/method
21:54:25*miran quit (Quit: Konversation terminated!)
21:54:34FromGitter<tim-st> I also had this a few times, the stack trace is not so good like in Python unfortunately
21:55:05FromGitter<Quelklef> Still pretty good if you ask me :-)
21:55:20FromGitter<Quelklef> Just seems to not follow methods
21:55:24FromGitter<tim-st> Yes, it's good enough
21:55:46dom96Quelklef: can you reproduce it?
21:55:55dom96If the stack trace is wrong please report it
21:56:25FromGitter<Quelklef> I don't think it's actually wrong, it just points to the base method instead of the called method
21:56:47FromGitter<Quelklef> If that's an issue, I can probably reproduce
21:56:57FromGitter<tim-st> I remember for me it often points to system.nim, which is correct, but not the upper call
21:58:47FromGitter<tim-st> I never had problems with the Python stack trace, but I'm not sure if it's possible for a non interpreted language to have such a detailled step by step stack trace
22:01:02FromGitter<tim-st> Btw. I read the default compiler should be replaced. Which downsides appear regarding performance and compile time, if I use the new one?
22:01:21FromGitter<ZarsBranchkin> Heh, especially with this much meta-programming going on. I started noticing bit wilder stack traces when I was experimenting with macros
22:01:32FromGitter<Quelklef> @tim-st Are you talking to switching to devel?
22:02:00FromGitter<Quelklef> @ZarsBranchkin Yeah, I'm thinking a lot of it has to do with my copious usage of returning anonymous procs
22:02:24FromGitter<tim-st> No, I remember I read here some days ago, that in a new stable release a new default compiler should appear because of better try except handling
22:02:40FromGitter<tim-st> Maybe I got it wrong?
22:03:03FromGitter<Quelklef> Dunno, I never heard anything about that
22:05:35FromGitter<Quelklef> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a63bd2e5a9ebe4f75b22d37]
22:05:40*Demos[m] quit (*.net *.split)
22:05:40*odc quit (*.net *.split)
22:05:41*notdekka[m] quit (*.net *.split)
22:05:41*hiway quit (*.net *.split)
22:05:42*d10n quit (*.net *.split)
22:05:46*d10n_ joined #nim
22:05:53FromGitter<Quelklef> ^ typical stack trace for a project im working on :'[
22:06:30FromGitter<ZarsBranchkin> Oh wow, alright, haven't run into these kinds of traces yet
22:06:36*odc joined #nim
22:07:02FromGitter<Quelklef> Lol
22:07:19FromGitter<Quelklef> I, er, rely on mutual recursion a bit much
22:07:41*notdekka[m] joined #nim
22:07:41*hiway joined #nim
22:09:06dom96oh, you're using methods?
22:09:09dom96I would report it
22:09:19dom96if you create a small test case, then even better
22:09:37*Demos[m] joined #nim
22:09:38FromGitter<Quelklef> can do
22:19:38*natrys quit (Ping timeout: 255 seconds)
22:26:15PMunchHuh, Nim doesn't have arithmetic bit shifts?
22:28:51FromGitter<ZarsBranchkin> PMunch: https://nim-lang.org/docs/system.html#shl,int,SomeInteger
22:29:19*solitudesf quit (Ping timeout: 248 seconds)
22:29:42PMunchZarsBranchkin, yeah but those are bitwise bit-shifts
22:29:54PMunchAccording to the manual: "Bit shifting operators always treat their arguments as unsigned. For arithmetic bit shifts ordinary multiplication or division can be used."
22:30:05PMunchWhat I need are arithmetic bit shifts.
22:31:02PMunchAnd I'm bit-shifting 63 to the right. Which means multiplying by a rather large number, either putting it in code, or importing the maths module to use powers..
23:00:53*shashlick quit (Ping timeout: 246 seconds)
23:01:12*hiway quit (Ping timeout: 246 seconds)
23:01:33*ehmry quit (Ping timeout: 246 seconds)
23:01:35*macsek1911[m] quit (Ping timeout: 246 seconds)
23:01:35*byteflame quit (Ping timeout: 246 seconds)
23:02:49*Yardanico quit (Remote host closed the connection)
23:02:58*ehmry joined #nim
23:03:29*byteflame joined #nim
23:04:18*hiway joined #nim
23:04:59*shashlick joined #nim
23:05:47*macsek1911[m] joined #nim
23:32:39*yglukhov joined #nim
23:36:54*yglukhov quit (Ping timeout: 246 seconds)
23:37:10*andi___ joined #nim
23:41:31*Gertm quit (Ping timeout: 240 seconds)
23:41:42*Gertm joined #nim
23:44:58*UxerUospr joined #nim
23:50:58*skelett joined #nim
23:52:19*andi___ quit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
23:58:41*arecaceae quit (Remote host closed the connection)
23:58:59*arecaceae joined #nim