<< 28-07-2017 >>
00:04:55*jinshil joined #nim
00:13:15*def-pri-pub quit (Quit: leaving)
00:30:39*yingjun_ joined #nim
00:34:50*yingjun_ quit (Ping timeout: 240 seconds)
00:56:45*mahtob joined #nim
01:14:39*sz0 quit (Quit: Connection closed for inactivity)
01:32:55*chemist69 quit (Ping timeout: 255 seconds)
01:36:15*Serenitor joined #nim
01:38:57*ftsf quit (Ping timeout: 268 seconds)
01:39:56Serenitorwould you guys say it makes sense to log this here as an issue? https://forum.nim-lang.org/t/3070
01:40:07SerenitorI can't find any docs or threads on nimrtl + missing stacktrace so I've got no idea if that behavior is to be expected..
01:46:43*chemist69 joined #nim
01:47:32*def-pri-pub joined #nim
01:49:47*yingjun_ joined #nim
02:03:19*yingjun_ quit (Remote host closed the connection)
02:03:30*yingjun_ joined #nim
02:14:43*yingjun_ quit (Remote host closed the connection)
02:16:27*endragor joined #nim
02:17:41*pilne joined #nim
02:17:46*def-pri-pub quit (Quit: Lost terminal)
02:20:17*yingjun_ joined #nim
02:23:57*mahtob quit (Ping timeout: 260 seconds)
02:30:45*yingjun_ quit (Remote host closed the connection)
02:35:52*yingjun_ joined #nim
03:17:19*krux02 quit (Remote host closed the connection)
03:22:37*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:45:24*rauss joined #nim
03:57:20*dankrad quit (Ping timeout: 240 seconds)
03:59:30*dankrad joined #nim
04:01:01*Serenitor quit (Quit: Leaving)
04:13:13*yingjun_ quit (Remote host closed the connection)
04:13:22*yingjun_ joined #nim
04:14:46*yingjun_ quit (Remote host closed the connection)
04:35:15*mahtob joined #nim
04:41:57FromGitter<Varriount> Serenitor: Well, stack traces are tricky
04:42:30FromGitter<Varriount> Especially across DLL boundaries, as they would have to communicate in order to tell which stack traces to use.
04:58:38*mahtob quit (Remote host closed the connection)
05:00:52*dankrad quit (Ping timeout: 260 seconds)
05:02:41*dankrad joined #nim
05:15:10*yingjun_ joined #nim
05:19:31*yingjun_ quit (Ping timeout: 246 seconds)
05:22:01*yingjun_ joined #nim
05:29:47*rauss quit (Quit: WeeChat 1.9)
05:47:39*vivus quit (Quit: Leaving)
06:05:50*pilne quit (Quit: Quitting!)
06:17:13*andrzejku joined #nim
06:20:08*planhths joined #nim
06:23:10*nsf joined #nim
06:34:12*andrzejku quit (Ping timeout: 260 seconds)
06:44:44*andrzejku joined #nim
06:46:59*yglukhov joined #nim
06:49:32*ShalokShalom quit (Remote host closed the connection)
06:50:35*user0 quit (Ping timeout: 240 seconds)
06:51:19*yglukhov quit (Ping timeout: 240 seconds)
06:54:44*user0 joined #nim
06:58:34*Matthias247 joined #nim
06:59:11*Vladar joined #nim
07:01:17*big_num joined #nim
07:01:24*big_num left #nim (#nim)
07:09:17*djellemah joined #nim
07:30:31*yingjun_ quit (Remote host closed the connection)
07:30:40*yingjun_ joined #nim
07:30:45*ftsf joined #nim
07:30:45*ftsf quit (Read error: Connection reset by peer)
07:32:10*yingjun_ quit (Remote host closed the connection)
07:34:19*yingjun_ joined #nim
07:36:43*yglukhov joined #nim
07:40:21*ftsf joined #nim
07:44:54*andrzejku quit (Quit: Textual IRC Client: www.textualapp.com)
07:45:58*ShalokShalom joined #nim
07:48:13*yglukhov quit ()
07:58:22*Andris_zbx joined #nim
07:58:38*yglukhov joined #nim
08:18:49*v17d joined #nim
08:34:14*djellemah_ joined #nim
08:36:05*enthus1a1t- quit (Ping timeout: 240 seconds)
08:37:19*djellemah quit (Ping timeout: 240 seconds)
08:51:47*yingjun_ quit (Remote host closed the connection)
08:51:57*yingjun_ joined #nim
08:52:54*yingjun_ quit (Remote host closed the connection)
08:55:48*yingjun_ joined #nim
08:56:10*dom96|w joined #nim
08:56:13*yingjun_ quit (Remote host closed the connection)
08:58:27*yingjun_ joined #nim
09:02:57*jinshil quit (Quit: Good-bye!)
09:05:10*dom96|w quit (Read error: Connection reset by peer)
09:09:47*dom96|w joined #nim
09:11:55*yingjun_ quit (Remote host closed the connection)
09:12:55*yingjun_ joined #nim
09:12:56*yingjun_ quit (Remote host closed the connection)
09:13:25*yingjun_ joined #nim
09:23:19*planhths quit (Ping timeout: 240 seconds)
09:26:17*planhths joined #nim
09:35:38*Tiberium joined #nim
09:38:19*v17d quit (Ping timeout: 240 seconds)
09:50:46*v17d joined #nim
09:56:31*yingjun_ quit (Remote host closed the connection)
09:57:28FromGitter<AlexKotik> Is there a way to generate random number in NimScript during compile-time and pass it to the compiled program? It seems randomize() is not available for NimScript.
10:00:43*v17d quit (Remote host closed the connection)
10:04:42*yingjun_ joined #nim
10:06:51*dom96|w quit (Quit: My Mac has gone to sleep. ZZZzzz…)
10:13:27FromGitter<TiberiumN> you can take a seed from somewhere else
10:13:43FromGitter<TiberiumN> e.g. you can call randomize(123123) ⏎ ⏎ but instead of 123123 use some source of seed
10:15:46*krux02 joined #nim
10:27:37FromGitter<AlexKotik> I think I just use `hash(CompileDate & CompileTime)` as a seed. What is the best way to pass these random integers to compiled program? Basically I need to define a constant with some name and integer value, so the compiler could see it. Can I do it with switch("d", <something>)?
10:28:10federico3Nim 0.17 just entered Debian stretch-backports
10:50:30*v17d joined #nim
11:04:52*yingjun_ quit (Remote host closed the connection)
11:09:08*yingjun joined #nim
11:14:47*xet7 quit (Read error: Connection timed out)
11:15:18*xet7 joined #nim
11:31:18*krux02 quit (Remote host closed the connection)
11:36:21*Tiberium quit (Remote host closed the connection)
11:40:28*yingjun quit (Remote host closed the connection)
11:41:06*yingjun joined #nim
11:46:10*xet7 quit (Read error: Connection timed out)
11:46:47*xet7 joined #nim
11:46:48*xet7 quit (Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number)
11:47:17*xet7 joined #nim
11:47:17*xet7 quit (Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number)
11:47:43*xet7 joined #nim
11:47:43*xet7 quit (Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number)
11:48:13*xet7 joined #nim
11:48:13*xet7 quit (Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number)
11:48:34*yingjun quit (Remote host closed the connection)
11:48:42*xet7 joined #nim
11:48:42*xet7 quit (Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number)
11:48:44*yingjun joined #nim
11:48:48*yingjun quit (Remote host closed the connection)
11:59:13*planhths quit (Ping timeout: 276 seconds)
12:02:46*yingjun joined #nim
12:03:41*yingjun quit (Remote host closed the connection)
12:03:52*Snircle joined #nim
12:04:07*yingjun joined #nim
12:04:32yukenwell, I got the full nim suite setup on my windoge machine. guess i'll start development later today once I finish muh DOTA
12:09:33cremIs it possible to finish DOTA?
12:13:51FromGitter<TiberiumN> Lol
12:31:39*SunDwarf joined #nim
12:35:44*yingjun quit (Remote host closed the connection)
12:36:34*arnetheduck joined #nim
12:36:57*yingjun joined #nim
12:37:31*krux02 joined #nim
12:37:44FromGitter<krux02> yes it is possible. Just quit the game, and it finished.
12:37:53FromGitter<krux02> or don't start
12:38:12FromGitter<krux02> best tactic to not loose Tetris is to not play the game
12:39:39*yingjun quit (Remote host closed the connection)
12:39:44*dddddd joined #nim
12:39:48*yingjun joined #nim
12:39:54*yingjun quit (Remote host closed the connection)
12:41:25*Serenitor joined #nim
12:47:27*v17d quit (Ping timeout: 240 seconds)
13:00:45*v17d joined #nim
13:06:35*dom96|w joined #nim
13:10:19*yingjun joined #nim
13:13:22nivdom96: marketing idea: do a weekly/bi-monthly newsletter of new developments, submitted packages/libraries, media content. i'd subscribe immediately
13:13:47dom96|wniv: do it :P
13:13:51cremhourly!
13:14:16nivdom96: i might consider it if you ever fix try/await
13:14:36federico3niv: do it and it will be published on https://planet.nim-lang.org/
13:14:49*yingjun quit (Ping timeout: 240 seconds)
13:14:50FromGitter<krux02> I like the to read the factorio friday facts, some news on the development every friday
13:15:04nivyep, that's what gave me the idea actually
13:15:36dom96|wniv: If anything I will remove the edge cases that fail.
13:15:53dom96|wThere is no easy fix for try await, unless 'yield' is supported in a try stmt.
13:16:54nivyeah, it's yield that doesn't work for me :( so i can't even wait for the future manually
13:17:28dom96|wthat definitely shouldn't be a problem
13:17:38dom96|woh but you need to use an if stmt
13:17:40niv"cannot yield in a non-inlined iterator"
13:17:41dom96|winstead of a try
13:18:00dom96|wif myFut.failed: # handle error
13:18:06*rauss joined #nim
13:19:03nivmm that didn't work last time i tried.
13:19:14nivi had to yield to get the future to complete, and that errored
13:23:45*sz0 joined #nim
13:31:10*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
13:33:44dom96|wniv yielding won't read the future and so shouldn't fail
13:34:49FromGitter<TiberiumN> niv: maybe you've put yield in except statement?
14:25:27*dankrad quit (Ping timeout: 240 seconds)
14:34:39*dom96|w quit (Quit: My Mac has gone to sleep. ZZZzzz…)
14:41:01*acidx_ is now known as acidx
14:41:30*acidx is now known as Guest52923
14:47:33*Guest52923 is now known as acidx
14:51:10FromGitter<TiberiumN> what would happen if I have a "var bot = VkBot()", VkBot is a "ref object", and I want to use it from another variable? ⏎ ⏎ Would "var myBot = bot" copy object or copy the reference?
14:55:19*Arrrr joined #nim
14:55:19*Arrrr quit (Changing host)
14:55:19*Arrrr joined #nim
14:59:56*salewski joined #nim
15:00:49*v17d quit (Ping timeout: 240 seconds)
15:01:18salewskiTiberionM, "var myBot = bot" copies the reference of course.
15:01:26FromGitter<TiberiumN> ok, thanks
15:02:12salewskiBut strings and seq behave differently -- they have copy semantic,
15:02:34salewskiso while they are pointers, assignment copied the content.
15:07:09*salewski quit (Quit: WeeChat 1.4)
15:12:38*yingjun joined #nim
15:16:57*yingjun quit (Ping timeout: 240 seconds)
15:24:15*Andris_zbx quit (Remote host closed the connection)
15:24:19*dankrad joined #nim
15:28:49*dom96|w joined #nim
15:30:58*user0 quit (Ping timeout: 246 seconds)
15:38:29*Matthias247 quit (Read error: Connection reset by peer)
15:39:39FromGitter<zacharycarter> I'm thinking about writing a flux implementation in Nim for my demo next week
15:40:04FromGitter<krux02> a flux implementation?
15:40:26FromGitter<zacharycarter> it's a front-end architecture for state management that all the js fanboys love
15:40:31FromGitter<zacharycarter> but I think it'd help win my argument
15:40:33FromGitter<zacharycarter> if I could write one in an hour
15:41:17FromGitter<krux02> well you can train writing one :P
15:41:23FromGitter<zacharycarter> yup
15:42:16FromGitter<krux02> code becomes better when it has less clutter and when you train to do something fast you automatically leave out all the unnecessary clutter and keep focus on the important
15:50:03*nhywyll joined #nim
16:03:02yukenzacharycarter, time for me to get started with Nim.
16:03:06*yuken scratches his head
16:03:12yukeni have no clue what i'm doing
16:03:24FromGitter<krux02> well, programming
16:03:36FromGitter<krux02> just do it a lot and you will become better at it
16:03:45yukenoh no, I know the basics of programming
16:03:49yukenno clue how to start with Nim specifically.
16:03:56FromGitter<krux02> well just do it
16:04:02FromGitter<krux02> get yourself a goal
16:04:03dom96|wyuken: buy Nim in Action ;)
16:04:11yuken> books
16:04:14dom96|wj/k. Read the tutorial.
16:04:22FromGitter<krux02> dom96 is the book in print already?
16:04:22dom96|wAsk questions here.
16:04:36FromGitter<krux02> yea pretty active here
16:04:37dom96|wkrux02: It's being printed as we speak :)
16:04:39FromGitter<krux02> great support
16:04:43FromGitter<krux02> cool
16:04:49yukenHm.
16:04:49FromGitter<TiberiumN> yeah I've learned a lot here
16:04:51dom96|wAlso, I got some new Nim stickers.
16:04:55FromGitter<TiberiumN> and I was being annoying
16:04:55FromGitter<TiberiumN> wow!
16:05:02dom96|wI'll be creating a marketplace on sticker mule so you guys can buy some as well
16:05:04*v17d joined #nim
16:05:05FromGitter<krux02> a log time ago someone who bought the book promised me to forward the book to me
16:05:18FromGitter<krux02> I wonder if that actually will happen
16:06:04FromGitter<TiberiumN> by secret: there would be an email address of the person, tho bought the book (on all pages)
16:06:26FromGitter<TiberiumN> but yeah, since we're all developers, one can easily change that
16:07:54FromGitter<TiberiumN> one a little bit sad thing: no HTTPS support in asynchttpserver or jester :( ⏎ now I have WSL( bash on windows), and I'm running NGINX here, which acts like a proxy and redirects to http://localhost:5000, which is my app, launched from window
16:07:58FromGitter<TiberiumN> windows
16:10:51FromGitter<TiberiumN> but overall the main reason why I choose Nim was indentation and python-like syntax (in many places)
16:11:11FromGitter<TiberiumN> I didn't knew about the macros stuff at all :)
16:11:31FromGitter<TiberiumN> and never used them in another languages
16:12:17FromGitter<krux02> well I don't know about any other useful language that has macros
16:12:25FromGitter<krux02> I only know about emacs lisp
16:12:59*dom96|w quit (Quit: My Mac has gone to sleep. ZZZzzz…)
16:13:01FromGitter<krux02> and that language is only to develop emacs
16:13:15FromGitter<krux02> and emacs is only good to develop emacs lisp
16:13:28FromGitter<TiberiumN> Honestly lisp looks like something very hard to understand for me
16:13:31FromGitter<krux02> therefore both emacs lisp and emacs are very important products
16:13:36FromGitter<krux02> well it's not
16:13:42FromGitter<krux02> the syntax is trivial
16:13:49FromGitter<krux02> and then it just like any other language
16:14:20FromGitter<krux02> istead of this:
16:14:49FromGitter<krux02> if <cond>: <a> else: <b>
16:14:52FromGitter<krux02> it is this:
16:15:12FromGitter<krux02> (if <cond> <a> <b>)
16:15:44FromGitter<krux02> but yea some things particular in emacs lisp are very wonky
16:15:59FromGitter<krux02> for example the dynamic stack
16:16:01*yglukhov quit (Remote host closed the connection)
16:17:10FromGitter<krux02> called function see local variables from the context of calling functions.
16:18:19yukenIn my previous language, I could've done this: https://gist.github.com/YukenK/032ddf8918d9861307b7b5ff461b2407
16:18:25FromGitter<krux02> not good for static code analysis, but it allows to override the value of global variables locally for the duration of a funtion call
16:18:26yukenHow would I do something similar with Nim o-o?
16:18:48FromGitter<krux02> I don't know what that means
16:20:14FromGitter<krux02> in nim the functions you can call on a type are not declared in the block of the type
16:20:19yukenkrux02, I can define procs under an object type, and then the proc will have access to all of the variables on that type.
16:20:21FromGitter<krux02> a lot of freedom
16:20:32FromGitter<krux02> ah
16:20:39yukenSorry if that's a bit of a poor explanation :p
16:20:44FromGitter<krux02> well there is a this pragma for that
16:21:08FromGitter<krux02> but before you do that, try to get used to not use it for a while and see if you like it
16:21:36yukenWell, I don't understand how I'd modify an object then :p.
16:22:31FromGitter<krux02> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=597b64c7a7b406262d3be60f]
16:23:05yukenSo I'd just be passing through the object as an argument to procs?
16:23:15FromGitter<krux02> yes
16:23:23yukenMakes sense, you can do that in the language I used before.
16:23:49*yglukhov joined #nim
16:23:53FromGitter<krux02> you can do that in any language, but nim has static dispatch and allow to call it like a "method"
16:24:27*Trustable joined #nim
16:25:18yukenhttps://gist.github.com/YukenK/2a316ee968e71bf50b5729c62ce76837 is what I wrote then, for my first... thing.
16:25:48FromGitter<krux02> well remove the "ref"
16:26:11FromGitter<krux02> just "mob = object"
16:26:31FromGitter<krux02> using ref types is a waste most of the time
16:27:08FromGitter<krux02> even non ref types are passed by reference to functions for performance reasons, so don't worry about too much copy
16:27:40nhywyllkrux02: elisp has lexical binding for 5+ years now, fwiw
16:28:37*yglukhov quit (Ping timeout: 260 seconds)
16:30:25yukenNow, my previous language was synchronous, and allowed for sleeping. So I could do this, to loop this proc forever, looping it once every second: https://gist.github.com/YukenK/e44b2e841b9d2fd977117c3d12993590
16:30:30yukenI assume this is a bit different in Nim?
16:31:43FromGitter<krux02> not really, you can still do the same I guess
16:31:51FromGitter<krux02> I just don't know the << operator
16:32:00FromGitter<krux02> or what it means to you
16:32:27yukenJust output, basically. A << B causes B to be outputted to everything in A.
16:32:40yukenMy previous language was meant for easy networking & multiplayer, it was designed around games.
16:37:40*dom96|w joined #nim
16:39:56FromGitter<krux02> what language was that?
16:40:00yukenBYOND.
16:40:07FromGitter<krux02> never heared of it
16:40:12yukenhttp://www.byond.com
16:40:26FromGitter<krux02> I like nim because it provides me the low level contral that c++ does plus macros and stuff
16:41:10FromGitter<krux02> so it's not one of those scripting/toy languages it can actually output fast code
16:41:19FromGitter<krux02> and memory efficient code
16:42:00yukenoddly enough
16:42:09yukenBYOND uses proc like Nim, which I didn't expect.
16:43:12*dom96|w quit (Quit: My Mac has gone to sleep. ZZZzzz…)
16:43:17*endragor quit (Remote host closed the connection)
16:44:52*endragor joined #nim
16:45:06FromGitter<krux02> well if you want to, you can also define yourself the ``<<`` operator
16:45:25*dom96|w joined #nim
16:49:09yukenHm, I've come across a bug and figured out why. I'm trying to call two procs, but the first one starts a loop, so the code seems to pause at that loop and not start the 2nd one. Any ideas? https://gist.github.com/YukenK/13b350e83ea07f6d7861c97f55f92506
16:49:46*endragor quit (Ping timeout: 276 seconds)
16:52:29*arnetheduck quit (Read error: Connection reset by peer)
16:56:11*nsf quit (Quit: WeeChat 1.9)
17:00:17dom96|wyuken: Both procs start an infinite loop. The `worldLoop` never exits.
17:00:35dom96|wSo your program is stuck in the `worldLoop` proc forever
17:01:03yukendom96|w, I know that, same issue with BYOND, which is fixed by spawn (not the same as spawn in Nim, not multithreadded).
17:01:11yukenNot sure what I should change to do it here.
17:01:12dom96|wNot sure what you're trying to do so can't advise more.
17:01:38dom96|wIf you want to run `worldLoop` in a new thread then you spawn a new thread.
17:01:47dom96|wwith `spawn`
17:02:34yukendom96|w, I'd like them to be able to both run at the same time, essentially, without stopping the other or causing any issues.
17:03:41dom96|wyou probably want `createThread` instead.
17:06:55yukenI'm reading the docs on that and have quite literally zero clue how that works, never touched multithreading
17:10:35*dom96|w quit (Quit: My Mac has gone to sleep. ZZZzzz…)
17:14:25*yingjun joined #nim
17:19:08*yingjun quit (Ping timeout: 260 seconds)
17:20:51*sakalli joined #nim
17:21:02FromGitter<TiberiumN> Maybe byond uses async?
17:22:34*v17d is now known as vlad1777d
17:26:22*sakalli quit (Quit: leaving)
17:27:19*sakalli joined #nim
17:28:54*yglukhov joined #nim
17:29:36subsetparkSo I'd like to get vim omnicomplete from nim working
17:29:57subsetparkDo you think it makes sense to try to fix up baabelfish's fork of zah's vim plugin, or start a new small one that only does omnicomplete?
17:29:58FromGitter<krux02> yea completion would be nice
17:30:13FromGitter<krux02> I have emacs, and from time to time it have completion but it is unusably slow
17:30:20FromGitter<krux02> so I deactivate it always
17:30:30FromGitter<krux02> at least flycheck works often
17:30:37FromGitter<krux02> not reliably though
17:30:40FromGitter<krux02> too many crashes
17:32:34subsetparkso... no opinion, then?
17:35:06*Snircle joined #nim
17:36:40FromGitter<timmyjose> Hello, folks. Just trying out Nim after a long while... hopefully it will be interesting! Wanted to drop by and say "Hi!"
17:37:01FromGitter<krux02> well hi, then
17:37:32FromGitter<timmyjose> :-)
17:37:40FromGitter<krux02> I am sure Nim is "iteresting", I have little doubt you will be disappointed if that is your only concern
17:40:08FromGitter<timmyjose> Yeah, had worked through Part I of the official tutorials a while back, and liked its intuitive nature... but then didn't progress onto higher concepts. Hoping to work through it, do a few projects, and then maybe have a better assessment for myself! It does look very clean though.
17:40:58FromGitter<timmyjose> Any advice for a beginner? :-)
17:56:58ehmrytimmyjose: avoid the low-level details at first and look at how the standard library presents high-level interfaces
17:57:51ehmryif you start casting pointers and try to do C stuff right away its not going to be fun
18:03:18FromGitter<krux02> ehmry: well that depends, if you know how to do C stuff it won't be fun to do the stuff with "high-level" interfaces
18:04:09ehmrythat is if you do C stuff but don't realize what a waste of time it can be
18:07:22FromGitter<timmyjose> @ehmry Thanks for the tips!
18:07:58FromGitter<krux02> ehmry well I think it's the opposite but yea
18:08:11FromGitter<krux02> in nim I feel productive doing cool stuff
18:08:20FromGitter<krux02> with cool I mean control over memory
18:08:40FromGitter<krux02> C has the problem that it is not very good at abstractions
18:09:00FromGitter<krux02> c++ has the problem of being horrible in a lot of ways
18:09:08FromGitter<krux02> and Nim combines the best of borth worlds
18:09:11FromGitter<timmyjose> Just curious about the metaprogramming in Nim... I am used to Lisp-style macros... any similarities?
18:09:19FromGitter<krux02> so I program Nim like I used to program C++
18:09:34Xetimmyjose: it's basically lisp macros
18:09:35FromGitter<krux02> well I don't lisp style macros too well
18:09:46FromGitter<timmyjose> @Xe yeah? Wow.... that's sweet! :D
18:09:54FromGitter<krux02> well I think it's better than lisp macros
18:10:03FromGitter<timmyjose> @krux02 Hahaha!
18:10:03FromGitter<krux02> because Nim as a type system
18:10:10Xekrux02: tl;dr it's the same basic idea tho
18:10:28FromGitter<krux02> yes the same idea, but in a language that has static type information
18:10:37FromGitter<krux02> I think that's in important improvement
18:10:43FromGitter<timmyjose> For prototyping, dynamic languages can be very handy! Though I do prefer static langs for production systems... hence Lisp->Haskell over some time now
18:10:49FromGitter<timmyjose> (for me that is)
18:10:52FromGitter<krux02> nodes are not just ast nodes, they can have a type
18:11:06dom96Nim is very good for prototyping too, the static typing doesn't hold you back a lot of the time.
18:11:45FromGitter<krux02> well in emacs I see the benefits of a dynamic language
18:11:53FromGitter<timmyjose> @dom96 Interesting! It does indeed look like I will have a lot of fun over the next couple of weeks. Thanks for all the suggestions and feedback, guys!
18:12:14FromGitter<krux02> but reall I do like type checkers
18:12:32FromGitter<krux02> told you
18:12:43FromGitter<krux02> when it is about being interesting, Nim is a great language
18:12:44FromGitter<timmyjose> Static Types + Full Type Inference is pretty awesome! And yeah, you did, @krux02 ;-)
18:13:01FromGitter<krux02> well Nim does not have Full type inference
18:13:11FromGitter<krux02> I've seen languages with better type inference
18:13:17FromGitter<krux02> but it is pretty good
18:13:47FromGitter<krux02> Haskell for example
18:13:53FromGitter<timmyjose> Yup... I was talking about Haskell too!
18:14:12FromGitter<timmyjose> Yeah, even without full type inference, anything beats Java-level verbosity! :D
18:14:21FromGitter<timmyjose> Hell, even C++11 is much better now
18:14:26FromGitter<krux02> There is no language without type inference is some way left, except Java
18:14:33FromGitter<timmyjose> Hahaha!
18:15:14FromGitter<krux02> c++ has a lot of great language design features
18:15:24FromGitter<krux02> but sadly c++ is fundamentally flawed
18:15:36FromGitter<krux02> I seriously hate programming in that language
18:15:42FromGitter<timmyjose> LOL!
18:15:53FromGitter<krux02> well no that is not true I do too much like a lot of c++ stuff
18:16:10*big_num joined #nim
18:16:15FromGitter<krux02> it is complicated
18:16:27*big_num left #nim (#nim)
18:16:28FromGitter<timmyjose> What about Rust (mentioning which appears to be fast becoming a bit of a meme in itself). I like it well enough, but its metaprogramming is quite primitive
18:16:38FromGitter<krux02> but sometimes it is just painful, and then it is really painful
18:16:54FromGitter<krux02> well yea I tried rust for a day
18:17:03FromGitter<krux02> I wanted to do a metaprogramming project
18:17:10FromGitter<krux02> and then I tried to do it in rust macros
18:17:14FromGitter<timmyjose> Ah ha!
18:17:18FromGitter<krux02> then I stopped using rust
18:17:24FromGitter<timmyjose> Hahahaha... :D
18:17:26FromGitter<timmyjose> Man...
18:17:30FromGitter<timmyjose> That is rough!
18:17:50FromGitter<krux02> Rust is also super verbose
18:18:09FromGitter<krux02> it has too much visual noise if you ask me
18:18:13Xeit has more tokens than a chuck-e-cheese
18:18:15Xe:D
18:18:15FromGitter<timmyjose> Agreed... anything more than basic programs, and you get Java-looking code with all the traits
18:18:19FromGitter<timmyjose> Yup...
18:18:20FromGitter<krux02> sorry verbose is the wrong word
18:18:28FromGitter<krux02> it uses too many operators
18:18:38FromGitter<krux02> too much move semantic operators
18:18:58FromGitter<timmyjose> In fact, it used to be even worse before... now things have stabilised, but I agree, it's not very easy to read Rust code written by someone else
18:19:10FromGitter<krux02> all this move semantics stuff is nice and all, but I think it should happen nicely in the background and it should not be in your face all the time
18:19:44FromGitter<krux02> well Nim code is not easy to read either
18:19:50FromGitter<timmyjose> yeah... that definitely takes some time to get used to. I mean, I like it, but sometimes a lot of things happen in the background, and you have pretty much no idea why your damned code is not working!
18:19:53FromGitter<krux02> especially when people abuse the nim syntax
18:20:02FromGitter<krux02> what does this mean: ```nim
18:20:04FromGitter<timmyjose> normal Nim code or when using macros?
18:20:35FromGitter<krux02> ```foo bar baz, buff```
18:20:43FromGitter<krux02> normal nim code
18:21:21Araqfoo bar(baz), buff
18:21:24FromGitter<krux02> macros can obfuscate the code arbitrarily, but they can also be used to clean up a lot of mess
18:21:27FromGitter<timmyjose> That's interesting... has there been some community movement to get some sort of coding guidelines/style in place?
18:21:50FromGitter<timmyjose> Like some idomatic style?
18:21:54FromGitter<timmyjose> idiomatic*
18:21:58AraqNim is easy to read. you need to know that the command syntax in an expression context can only take a single argument
18:21:59FromGitter<krux02> Araq: you don't count, I would guess you came up with that parsing rule
18:22:19Araqthe parsing rule is simple, it's just that you don't know it. at all.
18:23:05dom96IMO it's taking it too far.
18:23:09Araqalso the parsing rule came from extensive discussions and experiments
18:23:13FromGitter<krux02> well I can obfuscate my code if I want to a lot. But that is possible everwhere, I also have a lot of freedom to write it nicely
18:23:13dom96foo bar # fine
18:23:21AraqI haven't pulled it out of my ass.
18:23:26FromGitter<timmyjose> LOL
18:24:42FromGitter<krux02> well my coding rule, command syntax only top level or at the last argument
18:26:40FromGitter<timmyjose> Right guys. I've got to go now, but it's been an interesting discussion right off the bat! Nice to meet you all, hope to have some real solid questions as I delve into Nim deeply. Cheers!
18:27:18dom96timmyjose: feel free to ping me if you need any help! :)
18:35:02FromGitter<TiberiumN> @krux02 I also use something like "int someJson["number"].num"
18:35:07FromGitter<TiberiumN> because BiggestInt is not int
18:35:33FromGitter<TiberiumN> ah it is int64
18:36:06*nsf joined #nim
18:38:35*arnetheduck joined #nim
18:39:20*notbarton joined #nim
18:39:27*notbarton quit (Remote host closed the connection)
18:39:41*tanguy joined #nim
18:41:23*tanguy quit (Remote host closed the connection)
18:45:14dom96oh look, a Rust in Action book.
18:45:33FromGitter<TiberiumN> lol :)
18:45:45dom96It describes Rust as the following: "Rust is a new systems programming language that gives you the low-level power of C with the elegance and ease of languages like Ruby and Python."
18:45:46FromGitter<TiberiumN> well it has simpler chapter names
18:45:51FromGitter<TiberiumN> WAT
18:45:52dom96Doesn't that sound familiar?
18:45:52FromGitter<TiberiumN> ????
18:46:00dom96It seems completely wrong for Rust, no?
18:46:16FromGitter<TiberiumN> yeah I think so
18:47:01FromGitter<TiberiumN> "High-level, expressive feel. Rust programs are able to feel ergonomic and yet ⏎ achieve bare metal performance"
18:47:15FromGitter<TiberiumN> it throws you into Rust immediatly
18:51:06FromGitter<TiberiumN> dom96: why it's cheaper by 5 dollars? because it's not complete yet?
18:51:11*yglukhov quit (Remote host closed the connection)
18:51:18FromGitter<TiberiumN> (2 out of 15 chapters)
18:52:23*Nimbecile joined #nim
18:53:24FromGitter<krux02> well there is nothing that beats the flexibility of the Nim procs
18:53:38dom96TiberiumN: shorter planned page count probably
18:54:00FromGitter<krux02> I fell so relieved after I got rid of thinking object oriented
18:54:33FromGitter<krux02> it feels like a life long I tried to push the rectangle in the star shaped hole
18:54:47FromGitter<TiberiumN> well, it turned out for me that I don't even need OOP 0_0 (because I almost never use inheritance in python lol)
18:54:54FromGitter<TiberiumN> *used
18:55:06FromGitter<krux02> I don't use inheritance at all
18:55:08FromGitter<krux02> anymore
18:55:18FromGitter<krux02> I don't think it enables me anything
18:55:44FromGitter<krux02> it just makes me busy thinking about object hierachies
19:00:30*kunev quit (Ping timeout: 268 seconds)
19:00:58*kunev joined #nim
19:02:47NimbecileI hope it's ok to ask this question here...not sure if it's particular to nim or a general programming thing...in example code I see statements like "discard &IID_IDispatch"...what does the "&" mean? I thought it was the string concatenate operator? Only other thing in docs that I saw that used that symbol was a lookahead operator (don't know what that is)
19:03:52FromGitter<krux02> well I don't know what it does, Nim allows to define operators so it is propably defined in your context
19:04:02FromGitter<TiberiumN> where did you find this code?
19:04:04FromGitter<TiberiumN> can you give a link?
19:04:11Araqyup, the new winapi wrappers use '&'
19:04:22FromGitter<krux02> and that is a good example why operators should not be decared arbitrarily
19:04:39FromGitter<krux02> it just mecomes readable like APL
19:04:46Nimbecileyes, it was in the winim module
19:04:49FromGitter<krux02> (executable line noise)
19:04:58Araqand APL is unreadable because you never learned it?
19:08:20AraqI don't like winapi's usage of '&' either fwiw, but "there is bad code out there" is never an argument against language features
19:08:55FromGitter<krux02> no it's not against the language feature
19:08:59AraqI know code that nests 'if' statements 20 levels deep. I never ever read "let's kill if statements, they are bad"
19:09:00FromGitter<krux02> it's against the way it is used
19:09:33FromGitter<krux02> I like operator overloading, but I think it should be done with caution
19:09:56Araqagreed. but!
19:10:32FromGitter<krux02> I already said it, I would really like to see ¬∨∧ as an alias for "not" "or" "and"
19:10:42Araq' "discard &IID_IDispatch"...what does the "&" mean?' is a biased question.
19:10:57FromGitter<krux02> no idea
19:11:24Araqnot only the '&' is mysterious, the IID_IDispatch is also troublesome and why is it discarded?
19:13:26Araq ¬∨∧ are hard to memoize :P
19:13:55Araqyou could use '+' for 'or' and '*' for 'and' perhaps
19:14:44subsetparkkrux02, you're gonna love this new language i've got, it's called Haskell
19:15:02Araqbut the partial evaluation properties warrant keywords.
19:15:14*yglukhov joined #nim
19:15:23Araq'and' is much more like 'if' than an "ordinary" operator
19:15:30Araqsame for 'or'
19:15:43FromGitter<krux02> well ¬∨∧ are the operators that are taught in math for logical oparations
19:15:48FromGitter<krux02> it school
19:16:00AraqI know, but math often uses bad notation.
19:16:09Araqor logic for that matter.
19:16:16FromGitter<krux02> they are hard to type on most keyboards, but they are the offical symbol for logical operations
19:16:58NimbecileI looked in the imported modules for the definition of "&" in this context...is that correct approach?
19:17:12Araqlogical operations do not have sideeffects, programming languages have, so 'a and b and c' is not the same as 'a and c and b'
19:17:16FromGitter<krux02> No overloading '+' and '*' does not work, because it has already a meaning for ints
19:17:29Araqbut not for bools :P
19:17:31FromGitter<krux02> and the logic operators are defined to be bitwise operators on integer types
19:17:34Araqit would work.
19:17:53AraqI would like to kill the bitwise ops ;-)
19:18:06FromGitter<krux02> well I do like them
19:18:24AraqIMHO it should use 'band', 'bor' and 'bnot'
19:18:50FromGitter<krux02> no don't introduce yet another operator symbol to the language
19:18:57*nhywyll quit (Ping timeout: 260 seconds)
19:18:58Araqit's not operators
19:19:06FromGitter<krux02> it's functions?
19:19:06Araqit would be ordinary functions.
19:19:17FromGitter<krux02> I don't like it.
19:19:21*yglukhov quit (Remote host closed the connection)
19:19:22Araqlol.
19:19:41FromGitter<krux02> what is the problem with the overload of and or not?
19:19:54*yglukhov joined #nim
19:20:05Araqwell anyway, I rest my case. bool 'and' is brilliant as it's closer to 'if' than to ∧
19:20:50Araq(and easy to use/read too)
19:21:09FromGitter<krux02> I definitively prefer 'and' over '&&'
19:21:11*yglukhov quit (Remote host closed the connection)
19:21:21FromGitter<krux02> && and || appear so random
19:21:34*yglukhov joined #nim
19:21:49FromGitter<krux02> it feels like there is desperate need to use some ascii oparators when the real operators are not available
19:23:48Araqdunno, I don't see "desparate" needs. I see language designers optimize for having few keywords in the language so that the language appears superficially easy. heck it's even used as an idiotic measure of "language complexity"
19:25:23yukenI have zero clue how spawn & threading in general works with Nim o-o.
19:28:25FromGitter<zacharycarter> man react and redux and this whole way of building applications needs to die
19:28:39FromGitter<zacharycarter> an ugly painful death
19:28:50*xet7 joined #nim
19:29:34yuken... Hold on
19:29:39yukenis Nim synchronous?
19:32:54FromGitter<TiberiumN> Ehm, what do you mean?
19:33:07FromGitter<TiberiumN> Like all languages, yes by default
19:33:15*nhywyll joined #nim
19:33:21FromGitter<TiberiumN> You can use threads and async thought
19:33:35FromGitter<TiberiumN> *or
19:34:48FromGitter<krux02> it does make a lot of sense to be synchronous by default
19:35:43FromGitter<TiberiumN> Maybe "like almost all languages"
19:35:49dom96zacharycarter: what's wrong with React?
19:38:00FromGitter<krux02> yuken: for what do you need threading? I am programmer for a while now, and there is no need for threading at all
19:38:30subsetparkwell, thats a bit of an overstatement...
19:38:48yukenprobably terrible but https://gist.github.com/YukenK/13b350e83ea07f6d7861c97f55f92506 is what I'm trying to do right now.
19:39:18FromGitter<TiberiumN> Why you can't use one global loop?
19:39:19dom96Araq: Thought you were going to add a warning/error when 'not' is used without parens?
19:39:21FromGitter<krux02> well I have an idea for you
19:39:29FromGitter<TiberiumN> And call other procs from here
19:39:29dom96I dislike bnot/band etc.
19:39:40yukenTiberiumN, I can't exactly pause that global loop, while having other parts of it active, can I?
19:40:05dom96It's also a big breaking change, I'm certain that people have used a variable named 'band' somewhere.
19:40:13Araqdom96: given up on that, it's hard to do in the compiler and a bad inconsistency
19:40:25dom96and it's not immediately obvious that 'band' should be read as 'b_and'
19:40:37Araqdom96: no, it's system.band, your code can continue to use it
19:40:51FromGitter<zacharycarter> dom96: react isn't opinionated enough and putting together a react app is like rocket sciencew
19:41:43FromGitter<zacharycarter> also my company is mandating its use and we have this library of components that we're supposed to reuse and apparently none of them work
19:41:56FromGitter<TiberiumN> https://github.com/search?utf8=✓&q=language%3Anim+band&type=Code
19:42:01FromGitter<TiberiumN> Not much of this
19:42:13dom96zacharycarter: my view is probably skewed since I started using React at Facebook :)
19:42:47dom96Araq: oh okay.
19:43:19dom96Well, think some more about this.
19:43:29dom96It will deprecate/break a lot of code regardless.
19:43:51FromGitter<krux02> well you can use threads, but I discourage to do it
19:44:20dom96yuken: You likely don't need threads.
19:44:30dom96You just need to rethink your program
19:44:51yukenIf you can figure out how I'd pause, sure.
19:44:56XeYAGNI: thread edition
19:45:03dom96You can for example check when a second has passed in your playerLoop proc.
19:45:13dom96instead of creating another while loop and sleeping in it
19:45:25yukenw
19:45:31FromGitter<krux02> yuken: threads will bring you all kinds of problems with locking stuff. what you can do though, is do it all single threaded and then abuse iterators as resumable functions
19:45:47*arnetheduck quit (Ping timeout: 260 seconds)
19:45:48FromGitter<krux02> would be an adventure to do so
19:45:54yukenThat's how BYOND actually handles threads, since it isn't a multithreaded engine.
19:46:05dom96First time I've heard of BYOND
19:46:13FromGitter<krux02> and I would probably just do a sigle loop that updates both the world and the player
19:46:21*cspar__ quit (Read error: Connection reset by peer)
19:46:35yukenHow would I pause one part while continuing the other, though?
19:46:38FromGitter<krux02> well I know wesnoth
19:46:46FromGitter<krux02> abuse iterators
19:46:54*Nimbecile left #nim (#nim)
19:47:01yukenI've never used iterators, ;p.
19:47:10*tankfeeder left #nim (#nim)
19:47:28*cspar__ joined #nim
19:47:48krux02well an iterator is basically a function you can implement that has a yield statement
19:48:05dom96yuken: BYOND seems like something that is incredibly specialised (for games)
19:48:11yukenIt is, dom96.
19:48:17krux02whenever you call yield, the function is frozen in it's state, and the calling function can do stuff with the yielded object
19:48:40dom96Unfortunately applying the same style of programming to Nim probably won't work.
19:48:58krux02so you can have two closure iterators as an object
19:49:10dom96I wouldn't complicate this stuff with 'yield'
19:49:24dom96Having two procedures running concurrently is far more complex than one.
19:49:36dom96Creating a game doesn't require concurrency.
19:49:38krux02dom96: you haven't done it yet, but I thought about it , it is pretty amazing what you can do with it
19:49:55krux02it.s not super nice in the syntax, but very flexible in it's use case
19:50:06dom96krux02: huh? what haven't I done yet?
19:50:34krux02abusing iterators, or did you?
19:50:34yukenI'd like to have a variable called "time", which will update once every 100ms by +1. Don't care how I have to do it really.
19:50:59krux02every 100ms by 1, why?
19:51:11dom96krux02: async await abuses iterators
19:51:32dom96it is precisely what you should use instead of messing with iterators yourself.
19:51:54FromGitter<TiberiumN> also
19:52:21krux02yuken: using iterators might just confuse you, so maybe that is not what you should do
19:52:24dom96yuken: That's simple (you can do that with one loop and a sleep). You surely have more requirements though.
19:52:29FromGitter<TiberiumN> Why you can't use async with threads of another thread will not access async features?
19:52:34krux02I just had a funny idea that I want to try out one day
19:52:34FromGitter<TiberiumN> In Nim
19:52:38yukenkrux02, measuring time in 1/10th seconds for various things I'd like to do
19:52:39krux02don't you you should do it that wa
19:52:40krux02y
19:52:42yukenI can write up a quick example if you'd like.
19:53:08dom96krux02: wat?
19:53:29*derlafff quit (Remote host closed the connection)
19:53:32dom96TiberiumN: Your sentence broke a bit there, but I think I can guess what you mean.
19:53:52krux02dom96: I think the idea to abuse iterators very interesting and they can do more things than just async stuff
19:54:04dom96TiberiumN: async await + threads is tough. Mainly because memory cannot be shared between threads easily.
19:54:20FromGitter<TiberiumN> Well how to use utilize multiple cores with async?
19:54:41*derlafff joined #nim
19:54:48dom96SO_REUSE_PORT + multiple processes :P
19:55:11dom96That's one solution, but in general this isn't a solved problem (yet) for Nim.
19:55:12yukenkrux02, one example of using a time variable like that is setting the next time a player is allowed to use a skill. I can write up a quick example of that if you'd like, to see how I use it.
19:55:21krux02for example I could implement my own visual debugger in nim with a macro that transforme a procedure to an iterator, each breakpoint into a yield, and debugging doesn't stop the interactive program, but only that single function
19:55:53dom96yuken: BYOND likely offers this for you, but in Nim you'll need to implement it yourself: an event system.
19:56:14dom96It's basically a single while loop that handles everything for you.
19:56:26yukendom96, BYOND doesn't do that for you, no.
19:56:44krux02yuken: http://ix.io/yIX
19:56:50krux02that is what I use to measure time
19:57:09Araqerr, krux02, I looked at your gist
19:57:23krux02what gist?
19:57:27Araqit's specially created to break the reorder pass
19:57:34dom96You should look up how to implement an event loop or something like it in Python to get an idea how it's done.
19:57:40krux02ah, yes of course
19:57:55krux02that was my goal
19:58:09krux02I can hide it a bit better that it is specially created to break the preorder pass
19:58:37krux02but it shows that generally a preorder pass is not generally safe
19:59:28krux02yuken: that thing I sent you uses the sdl2 timer.
19:59:58krux02the advantage is, that a timer object is tiny you can create as many as you want and no matter if they are running or not they don't consume processing time
20:01:26krux02so each player, even each skill can have it's own timer object
20:02:31yukenkrux02, right now in BYOND, I handle skills timers by having an array which is just an associative list, and each skill has a cooldownID. I set the value in that array to be equal to world.time (how long the world has been running) plus the cooldown time on the skill
20:02:37yukenand they can't use it if world.time is below that value
20:03:46krux02well then you can do that
20:03:56yukenhttps://gist.github.com/YukenK/1f13e194b933bed1ec76194be4206c5d
20:04:01krux02let worldtimer = newStopWatch(true)
20:04:31krux02each frame: let time = worldtimer.time
20:05:39krux02echo skill: let canUse = skill.cooldown < time:
20:07:30*mahtob joined #nim
20:07:45krux02for skill in user.skills: if skill.cooldown < time: canUse = true
20:08:02krux02you don't need assoc array
20:08:35yukenwell in that case
20:08:48yukenI used an associative array because all skills were shared between players, noit new objects for each player.
20:11:15FromGitter<TiberiumN> You can have s
20:11:53FromGitter<TiberiumN> You can have array of skills on each player object
20:11:54FromGitter<TiberiumN> Ah
20:12:02FromGitter<TiberiumN> You did it exactly like that
20:13:20FromGitter<krux02> I think it's easier if each player his this seq[tuple[skillId: int; cooldown: float64]]
20:14:37FromGitter<krux02> and then there is a global value let skills: array[SkillKind, Skill] = [...]
20:16:47*yingjun joined #nim
20:17:14yukenwell so far, a lot of new stuff that I barely understand, but it's coming along nicely.
20:17:27yukenNim's syntax seems really similar to BYOND, but there are still a ton of differences so far.
20:21:22*yingjun quit (Ping timeout: 260 seconds)
20:21:55*Jesin quit (Quit: Leaving)
20:22:03dom96You might be interested in taking a look at how other games are developed in Nim.
20:23:02dom96https://github.com/ftsf/ld38-smalltrek/blob/master/src/main.nim
20:23:12dom96As an example (this won LD38 IIRC)
20:24:52*rauss quit (Quit: WeeChat 1.9)
20:25:30dom96And here is my Snake game https://github.com/dom96/snake
20:26:17dom96It's much simpler, but runs in the browser so it might be a bit difficult to understand some of it (due to the web crap ;))
20:26:59*nsf quit (Quit: WeeChat 1.9)
20:27:56*user0 joined #nim
20:31:39FromGitter<cabhishek> Hi everyone! A noob generics question ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ Why can't I do ``` v.locationstring ()``` ? [https://gitter.im/nim-lang/Nim?at=597b9f2b4bcd78af56f4b7bf]
20:32:35FromGitter<zacharycarter> dom96: I'm not sure if you already read or not but I'm doing a presentation on Nim next week at my workplace
20:32:48FromGitter<zacharycarter> I was thinking about writing an implementation of flux in Nim
20:32:53dom96zacharycarter: oohh, nope, haven't read it. Nice!
20:33:07dom96If you want I can take a look at your slides
20:33:42FromGitter<krux02> @cabhishek well that is a good question, it just doesn't work
20:33:42FromGitter<zacharycarter> that would be wonderful, as soon as I have them ready I will toss them your way
20:34:00FromGitter<krux02> I think it is parser related, and there is a workaround
20:35:55Araqit's actually logic related. x.y[z] can only mean (x.y)[z] (Nim's interpretation) or x.(y[z])
20:35:56FromGitter<krux02> http://ix.io/yL6
20:38:43FromGitter<cabhishek> @krux02 Ah I see! Thanks for the link
20:39:21AraqI don't really understand why so many people have trouble with this. it's not even Nim specific, C uses the very same parsing rule in this case.
20:39:44Araqor JavaScript. or Java. or ...
20:39:58*Vladar quit (Remote host closed the connection)
20:40:39*Arrrr quit (Read error: Connection reset by peer)
20:40:51FromGitter<krux02> well a method in c++ with a generic argument can be call v.foobar<T>();
20:41:10FromGitter<krux02> and that is what people are used to
20:41:15Araqyeah but that uses angle brackets
20:41:31FromGitter<krux02> it's not about the brackets
20:41:37Araqit is.
20:41:53AraqI voted for different brackets but people declined.
20:42:20FromGitter<krux02> I like these brackets
20:42:31FromGitter<krux02> but I think they are a bit overloaded too much
20:42:38Araqthey are ambiguous and suck
20:42:41FromGitter<krux02> arrays, indexing and generics all use []
20:42:55Araqarrays and indexing is fine, generics should have used something else
20:43:09Araqnot <> because these suck too, but something like [. .]
20:43:18FromGitter<krux02> what do you think of
20:43:20FromGitter<krux02> ‹›
20:43:35AraqUnicode, meh.
20:43:39FromGitter<krux02> ⟨⟩
20:43:54Araq[. .] can be rendered differently by your font
20:44:10FromGitter<krux02> ⊂⊃≪≫
20:44:22FromGitter<TiberiumN> Lol
20:44:26FromGitter<TiberiumN> I like
20:44:40FromGitter<TiberiumN> I like ⊂⊃ actually
20:44:55FromGitter<TiberiumN> Ah, no
20:45:05FromGitter<krux02> ≤⊂≥⊃≫≪∩≫⊂⊶⊃≤∪≥⌊⋃⌋⊆⊷⊇⌈⋂⌉⊆⊷⊇
20:46:03FromGitter<krux02> well [. .] is fine, but then I would like it for arrays
20:46:23FromGitter<krux02> [.1, 2,3,4,5.]
20:46:32FromGitter<krux02> arrays are rare
20:46:42FromGitter<krux02> or [[ for arrays ]]
20:47:19FromGitter<krux02> scala uses () for indexing
20:47:19Araqit's not about array construction, it's about array indexing which is everywhere in my code
20:47:56Araq() for indexing, meh. creates the ambiguities elsewhere
20:48:11FromGitter<krux02> so if it should be changed, then with a tool that understands the language and fixes all occurences of []
20:49:42FromGitter<krux02> I like that <> is not for generics those are comparison operators
20:49:55FromGitter<krux02> I think we are stuck with what we have
20:50:02FromGitter<krux02> and it's not bad
20:52:42euantorvb uses () for indexing and it's awful
20:53:52AraqI also came up with x.foo(:T)(z)
20:53:52Araqnew type of brackets: (: )
20:53:53Araqonly required for the case where x.y[z] gets the array indexing precedence, the rest of the generic use cases can continue to use []
20:53:53Araqit's growing on my since ':' is obviously about types
20:53:53Araq*on me
20:54:58FromGitter<krux02> well I don't like the idea to introduce (:)
20:55:22FromGitter<krux02> if would confuse people who see it first time a lot
20:55:41FromGitter<krux02> it's too many variations of doing the same thing
20:56:13FromGitter<krux02> eather change to a superior notation and make the old deprecated, or stick with the old one
20:57:05FromGitter<krux02> that is one of the reasons why I don't like c++ as a language at all
20:57:33FromGitter<krux02> it never get's rid of stuff, only introduces now syntax that solve things, but nobody knows about
20:57:46FromGitter<krux02> and new people are instictively lead to use the wrong tools
20:59:06*yglukhov quit (Remote host closed the connection)
20:59:07dom96Araq: You may as well just go with (.)(.) :P
20:59:07AraqI'm sick and tired of the "it would confuse people" argument. what doesn't confuse people?
20:59:47Araqyes, learning something new can be confusing. it can also enable you to do new things.
20:59:54dom96I like (:)
20:59:56FromGitter<krux02> ( . Y . ) please
20:59:58dom96in fact, I love it.
21:00:08dom96krux02: your ASCII game is far better than mine
21:00:19FromGitter<cabhishek> if its documented then "it would confuse people" is not harmful
21:00:28FromGitter<krux02> I don't like gaps in between
21:00:32dom96Araq: You've got my approval on (: ) for the cases where disambiguation is required.
21:00:46FromGitter<krux02> ( o | o )
21:01:10dom96Although it is a fair thing to be worried about. Having two different ways to do things increases the amount of things people have to learn.
21:01:52FromGitter<krux02> really I don't like it, Nim has already too many different node kinds and weird things in the languge
21:01:57FromGitter<krux02> less is more
21:02:17FromGitter<krux02> don't clutter the language with things it doesn't need
21:02:33Araqthat's a general argument, but in this concrete case there are no other options.
21:02:50Araq[] is a gotcha. we need to use something else.
21:03:07Araqsomething else used consistently everywhere requires a deprecation path
21:03:14FromGitter<cyberlis> if i want return value from thread (not threadpool) i have to use channels? or there is another way?
21:03:22Araqand is more verbose.
21:03:22FromGitter<krux02> what about :[ ] ?
21:03:36*Matthias247 joined #nim
21:03:46FromGitter<krux02> or ![ ]
21:03:57ehmryi don't think a comparision to C++ is fair, i find the confusing syntax to be constructors, lambdas, and templates, with Nim does better on all those
21:04:05AraqI want you to write const foo: array[.30, int.] = [0, 1, ...] a couple of times
21:04:31Araqyou will *curse* your very own desire for "consistency" soon enough
21:04:40FromGitter<krux02> const foo: array[.30,int.] = [0,1,...]
21:04:49dom96Yay. Not long now until Nim in Action is printed!
21:05:08FromGitter<TiberiumN> @cyberlis afaik yes
21:05:14FromGitter<krux02> (| banana clip |)
21:05:17Araq<operator> [] has the obvious downsides.
21:05:45Araqthe others are the same as [. .] or (: )
21:05:59Araqit doesn't really matter which one you pick, it's
21:06:11FromGitter<krux02> well it does matter
21:06:12Araqa) a massive change if applied consistently everywhere
21:06:13dom96cyberlis: you can also write into a shared global variable (but that's not memory safe)
21:06:20Araqb) longer than []
21:06:48FromGitter<krux02> I would like the indexing operator to be changed, not generics
21:06:49FromGitter<cyberlis> thank you
21:07:00*BitPuffin|osx joined #nim
21:07:30Araqand to what? () is ambiguous and makes me barf
21:07:48Araqand then let's see, a) and b) apply too.
21:07:56FromGitter<krux02> getElementAtIndex
21:08:08FromGitter<krux02> (that is ObjectiveC)
21:09:00Araqthat's funny but not helpful.
21:09:04FromGitter<krux02> I would really like to have something that is symetric
21:09:12FromGitter<krux02> I am thinking
21:09:48FromGitter<krux02> or at lest something that seems symetric
21:10:49dom96actually, can we do [:T, Y]?
21:11:30FromGitter<TiberiumN> Y?
21:11:46FromGitter<krux02> well I think () is not too bad. when x.foo(i) cannot be resolved, it just tries to resolve x.foo.apply(i)
21:11:54dom96TiberiumN: just a random type name
21:12:05dom96what? () is for proc calls
21:12:15dom96It seems even more ambiguous to me
21:12:26FromGitter<krux02> no new parsing rule, just a new rule for overloading
21:13:12FromGitter<krux02> well () is actually quite nice, when you have some experience with scala
21:13:24FromGitter<krux02> scala is a very nice language
21:14:23FromGitter<krux02> the language is desigend, so that ``proc(int): T`` and ``seq[T]`` have the same interface
21:15:06Araqdom96: [:T, Y] will work, yes
21:15:11Araq*would work
21:16:07FromGitter<krux02> so whenever you need to pass a proc somewhere, a seq does have the same interface and can be passed directory, without constructing a wrapping function object for it
21:16:55*Trustable quit (Remote host closed the connection)
21:17:05*nhywyll quit (Quit: nhywyll)
21:17:07dom96Araq: So maybe we could offer that for disambiguation?
21:17:19dom96Over time we could even start encouraging people to use that syntax from the get-go
21:17:29dom96and then deprecate [T]
21:17:36FromGitter<krux02> myseq.map(mypermutation) simply works
21:18:33Araqdom96: proc foo[:T](a: seq[:tuple[:a, b: int; z: T]])
21:19:44dom96oh :\
21:19:55dom96yeah, that sucks
21:20:27dom96Good to support both then
21:20:45Araqkrux02: I find that totally confusing... :P
21:21:03krux02well it isn't
21:21:38krux02I worked some years in scala, and that is one of the things I would port instantly in my programming language if I would write my own
21:21:49dom96So I'm considering creating some sort of marketing campaign for my book (by offering some books for free)
21:22:21dom96You know, the usual: RT and follow @nim_lang and you will have a chance to win 1 out of 10 books!
21:22:25dom96Thoughts?
21:22:40Araqdom96: [: ] sucks though for font patches
21:22:54ehmrydom96: I plan on lending my out whenever I can
21:22:55krux02dom96: it is hard to sell a book about a programming language when they are not interested in that language, so get people interested and then show them the solution to their need for information: your book
21:22:59dom96Araq: Nobody cares about font patches
21:23:29Araqdom96: != is already rendered differently for many people
21:23:40dom96Who?
21:23:53Araqeverybody who installed that new programming font, forgot its name
21:23:58krux02dom96: would it make you excited if you could win a book about Forth?
21:24:13dom96krux02: of course
21:24:15dom96It's a free book!
21:24:41krux02well yea
21:24:50dom96Yeah :P
21:25:26krux02or if you can win a book about tax returns?
21:26:23krux02I am sorry, but I think your book is boring to most people, but if you can show them that your book contains something special, then people will be interested
21:26:56*sakalli quit (Ping timeout: 260 seconds)
21:27:18dom96Come on, most developers are interested in new languages
21:27:28krux02well not really
21:27:30dom96enough to warrant wanting a free book
21:27:38krux02most developers are interested in their own language
21:27:45dom96okay fine, enough developers are interested in new languages
21:28:10krux02and developers that only know one language and are heavily invested in that language demonize every other programming language
21:29:07dom96I don't really think that's a valid reason not to do this.
21:29:27krux02wasn't there once a feature in nem that allowed me to specify replacement patterns?
21:29:44krux02dom96: true
21:30:14krux02I am not an export in selling, but make a presentation somewhere
21:30:20krux02talk about the programming language
21:30:29krux02tell people what you can do with it
21:30:36krux02and then show them your book at the end
21:30:55dom96I do these things
21:31:12dom96All. The. Time.
21:31:16krux02ask zachery nicely if he will link your book in his presentation (maybe he will do it)
21:31:22krux02ok
21:31:26krux02then I am out of information
21:32:01dom96Also, the first chapter of Nim in Action is named "Why Nim?"
21:32:03krux02then do your "win a free book" challenge
21:32:43krux02well I have a chapter on why c++ is broken and we need to search for a new language
21:34:47*rauss joined #nim
21:39:46FromGitter<TiberiumN> dom96: what tweet i need to RT ? :)
21:40:53dom96TiberiumN: heh, no tweet yet. It'll definitely be tweeted by @nim_lang, and i'll try to remind you but I'll likely forget.
21:41:04FromGitter<TiberiumN> Ok :)
21:44:38*nsf joined #nim
21:47:16dom96wow, this is awesome https://github.com/simply-jos/darwintiler
21:47:58FromGitter<TiberiumN> Yeah, saw this on Reddit
21:56:43FromGitter<cyberlis> dom96, i've read you book. i didn't find anything about `var`keyword in function params. i thought it is important
21:57:11FromGitter<cyberlis> or i missed
21:58:12dom96It's definitely mentioned in chapter 6
21:58:29dom96But to be fair I didn't focus on it too much.
21:58:31FromGitter<cyberlis> will look right now
22:04:14FromGitter<cyberlis> but in general this book is good enough. it gave me enough know
22:04:23dom96that's good :)
22:04:34dom96'var' in general isn't too difficult to grasp I hope
22:08:27*Matthias247 quit (Read error: Connection reset by peer)
22:18:19*yingjun joined #nim
22:20:16*nsf quit (Quit: WeeChat 1.9)
22:22:42*yingjun quit (Ping timeout: 260 seconds)
22:37:06*cyberlis joined #nim
22:42:24*cyberlis quit (Quit: Leaving)
22:54:05*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
22:57:45FromGitter<zacharycarter> dom96: do you think something like redux lends itself well to karax?
22:58:56FromGitter<zacharycarter> it looks like right now when something like a entry is added in the todo app, the dom is just directly manipulated
22:59:36Araqit's not. there is a shadow DOM, it's diff'ed, a patch set is computed, the real DOM is patched
23:00:43FromGitter<zacharycarter> gotcha
23:00:54FromGitter<zacharycarter> Araq: what do you think for complex application state management?
23:01:34FromGitter<zacharycarter> I know you threw up at the flux video I linked you but when I make this presentation next week the question will come up
23:02:43AraqI have no idea what it means
23:03:11Araqyou have state, you render it to a DOM, the state changes, it gets re-rendered
23:03:13FromGitter<zacharycarter> okay so flux and all of its implementations are basically just trying to solve the problem of what to do with application state
23:03:29FromGitter<zacharycarter> right but if all of these components have their own state
23:03:47FromGitter<zacharycarter> it can become messy quickly
23:04:05Araqthen you have completely misunderstood the point of a DOM diff'ing design.
23:04:19Araqyou don't have stateful components.
23:04:27Araqyou avoid them.
23:04:35Araqlike the fucking plague.
23:04:58FromGitter<zacharycarter> okay can you say then what karax is analogous to
23:05:02FromGitter<zacharycarter> what other framework
23:05:06AraqElm.
23:05:11FromGitter<zacharycarter> thank you
23:05:57Araqbtw Karax supports stateful components ;-)
23:06:21Araqand it took 4 iterations to get a design that works for complex stuff, ymmv
23:06:37FromGitter<zacharycarter> well then it may warrant something like flux
23:06:43FromGitter<zacharycarter> when those are used
23:07:05FromGitter<zacharycarter> but I'll stick with talking about dom diffing once I understand it more
23:07:39Araqmaybe, but I still think stateful components rape the whole DOM diff idea, which is about re-inventing the immediate mode UI.
23:07:57Araqwhere *all* of your state is not in the UI.
23:08:17FromGitter<zacharycarter> yeah they do go against that concept I agree
23:09:06*pilne joined #nim
23:09:18FromGitter<zacharycarter> but if you're going to support stateful components you might as well support a flux implementation too since it seems that it's the JS community's preferred way of dealing with the state
23:10:00FromGitter<zacharycarter> I'm honestly extremely glad to now understand that karax ditches all that state management in favor of what you're doing
23:10:28FromGitter<zacharycarter> because christ almighty building a react app with redux and all the other shit that goes along with it, like webpack, etc... is an effing nightmare
23:10:45dom96zacharycarter: no idea what redux is :\
23:11:05FromGitter<zacharycarter> dom96: http://redux.js.org/
23:11:44FromGitter<zacharycarter> it's the popular state container / management / whatever library that has emerged in the react ecosystem
23:12:52dom96But react itself has a concept of state. Is that not enough?
23:13:54FromGitter<zacharycarter> for a lot of people apparently not
23:14:15Araqthe problem is that 'react' is not 'reactive' (oh the irony)
23:14:28krux02what is 'reactive'?
23:15:40FromGitter<zacharycarter> http://www.reactivemanifesto.org/
23:16:06FromGitter<zacharycarter> but I mean
23:16:18dom96"Data is measured in Petabytes."
23:16:47dom96Yeah... for 99.9% (probably even more .9) of developers this is not the case.
23:17:04Araqno, not that one
23:17:14Araqhttps://en.wikipedia.org/wiki/Incremental_computing that one.
23:17:21FromGitter<TiberiumN> Because
23:17:42FromGitter<TiberiumN> Sorry, mobile gitter sucks a lot
23:18:20dom96huh, I'm pretty sure React does that.
23:18:20Araqinstead of detecting that item X was inserted into the list, the full list is rendered into a virtual DOM (O(n) instead of O(1)) and that then produces an O(1) real DOM update. (simplified to make a point)
23:18:53Araqit's an incomplete solution to the problem.
23:19:24dom96btw React tutorial has a nice step-by-step implementation of tic-tac-toe. It'd be awesome to see how that is implemented in karax.
23:19:53krux02<insert smart comment here>
23:20:41dom96But yeah, I'm fairly sure that React computes which elements have changed and only performs an update on those elements.
23:20:58dom96otherwise performance would be incredibly bad, no?
23:21:35dom96So far from what I've used of React I ran into one gotcha.
23:21:44Araqdom96: no, it works as I wrote it works and so does karax because you need to start from reactive/incremental data structures to do better than that
23:21:49dom96Apart from that everything worked nicely.
23:22:03krux02I am surprised again and again on how slow some software is
23:22:30dom96Araq: huh? I'm confused. So both Karax and React work the same way? But they are not "reactive"?
23:22:41Araqyes, that is correct.
23:23:05dom96okay, and do you plan to fix that in karax?
23:25:03Araqyeah but not sure how
23:26:19AraqI don't see it as a big problem, but I can imagine it's one reason why people use "flux"
23:28:04FromGitter<zacharycarter> Araq: I've never done server side rendering before in a web app but I imagine it'd be possible with Nim
23:28:13FromGitter<zacharycarter> I imagine it's another question that will be asked
23:29:45Araqwe're developing a native version of karax
23:30:08Araqbut it's still in the design phase
23:30:27FromGitter<zacharycarter> hrm I think that's different from what I'm talking about
23:31:57FromGitter<zacharycarter> I don't think Elm handles this
23:32:18FromGitter<brimbur> Hi, is nimsuggest working for anyone in nim 17.0?
23:32:19dom96Interesting. The developer of Factor wishes he didn't create its UI in OpenGL but used WebKit instead (https://twitter.com/slava_pestov/status/891075788413345792).
23:32:31FromGitter<zacharycarter> https://medium.com/walmartlabs/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8
23:32:47FromGitter<TiberiumN> @brimbur why it shouldn't?
23:32:54dom96Araq: Shouldn't you establish Karax first?
23:33:25dom96It would be nice to get at least 1% of the traction of React before committing to another project (a native version of karax).
23:34:30FromGitter<zacharycarter> dom96: maybe there is already need for it?
23:36:00FromGitter<zacharycarter> dom96: do you guys think you could update the link to frag on the main page to zengine?
23:36:12dom96zacharycarter: PR nim-lang/website
23:36:13FromGitter<zacharycarter> or just replace it with a link to someone else's library
23:36:24FromGitter<zacharycarter> will do thanks
23:36:24*dankrad_ joined #nim
23:37:23*dankrad quit (Ping timeout: 268 seconds)
23:37:42Araqdom96: that's not for me to decide.
23:40:38FromGitter<brimbur> It broke my editor after 15.something so I have been using an the old version of nimsuggest.exe that works, but the old one does not work with 17 anymore, so before I start debugging my own code I would like to know if anyone has used nimsuggest with v17 or if it is a known issue.
23:41:18krux02well my nimsuggest fails all the time
23:41:36FromGitter<TiberiumN> You need to use the same versions of nimsuggest and compiler
23:41:58FromGitter<brimbur> Well the old one worked up until 17.0
23:42:23FromGitter<TiberiumN> And I don't have that issue on devel with vscode-nim plugin (both on Linux and Windows)
23:42:28*itseris quit (Quit: Konversation terminated!)
23:43:06FromGitter<brimbur> But is it supposed to work? or is it a known problem?
23:43:13dom96brimbur: what editor are you using?
23:43:26FromGitter<brimbur> my own custom
23:43:43FromGitter<TiberiumN> pH
23:43:44FromGitter<TiberiumN> Oh
23:44:02dom96hrm. Well, what do you mean that Nimsuggest doesn't work?
23:44:09dom96It can't answer simple queries after 0.17.0?
23:44:16dom96gives errors? or what?
23:44:54FromGitter<brimbur> it just crashes I have not inestigated at all, just want to check if it is a known problem before I do :)
23:45:13FromGitter<brimbur> investigated
23:45:27dom96I don't really use it to be honest :)
23:45:31dom96Any ideas Araq ?
23:45:33Araqzacharycarter: oh that thing ... seems easy to provide for karax too, right?#
23:45:44Araqdom96: works for me
23:46:05FromGitter<TiberiumN> Hmm, I use nimsuggest all the time, and it crashed for me only once (taking up all the RAM)
23:46:19FromGitter<TiberiumN> I mean it doesn't do that usually
23:46:51FromGitter<brimbur> ok, thanks, so it should work then
23:46:56FromGitter<TiberiumN> And it's very useful - much like an IDE
23:48:20FromGitter<TiberiumN> Maybe you can debug what does your editor send to nimsuggest
23:49:29FromGitter<brimbur> I think it cant connect since 15 or something, has the connection method changed in the last years?
23:50:11Araqit did change, yeah, in particular 0.17.0 introduce multi threading
23:50:18Araq*introduced
23:50:52Araqbut report it properly please, have to sleep here now
23:50:57Araqgood night
23:51:07Xesleep well Araq
23:51:34FromGitter<brimbur> Any readme or comments or docs anywhere what changed?
23:53:29FromGitter<brimbur> It feels wrong to bug report if it is not a bug, but just an undocumented change
23:53:43FromGitter<TiberiumN> Well, I don't know since I've joined Nim when it was 0.16 already
23:53:44Xean undocumented change is a bug
23:56:55*Jesin joined #nim
23:58:01*vlad1777d quit (Remote host closed the connection)