<< 18-01-2018 >>
00:00:08*dddddd joined #nim
00:02:53*SenasOzys_ quit (Ping timeout: 276 seconds)
00:03:35FromGitter<matrixbot> `ratherAnonymous` Hello Nimblers (I just came up with this term.) I'm pretty new to Nim and I seriously don't get why someone would ever want to declare a value with "let" instead of "const".
00:03:47FromGitter<matrixbot> `ratherAnonymous` could someone clear things up for me?
00:03:50FromGitter<Quelklef> const is only compile-time values
00:04:48FromGitter<Quelklef> ```proc test(a: int): int = ⏎ const b = a + 1 ⏎ return b``` [https://gitter.im/nim-lang/Nim?at=5a5fe4a01dcb91f177635cd1]
00:04:52FromGitter<matrixbot> `ratherAnonymous` but if the value of let can't change, that doesn't make a difference, right?
00:05:07FromGitter<Quelklef> Doesn't work because `b` cannot be found at compile-time, so `let` or `var` must be used instead
00:06:05FromGitter<tim-st> @matrixbot I learnt that `let` and `var` are internally the same, let is only checked at compile time to not be changed or redeclared
00:06:44FromGitter<tim-st> well there are differences when passing them
00:07:54*cspar_ joined #nim
00:09:14FromGitter<matrixbot> `ratherAnonymous` so basically: use const whenever possible, but if it can't be done during compilation just use let.
00:09:39FromGitter<Quelklef> I suppose.
00:09:46FromGitter<Quelklef> And if let doesn't work, you must need var
00:09:57FromGitter<Quelklef> Except if it's a parameter, that'll get you in trouble
00:09:59FromGitter<tim-st> Make it const if possible, but not for bigger data
00:10:57*cspar__ quit (Ping timeout: 240 seconds)
00:11:04FromGitter<tim-st> and you cant use let when you pass by referencing, also if you not changing the object
00:11:29FromGitter<tim-st> At least that's what I learnt for now
00:14:49FromGitter<matrixbot> `ratherAnonymous` thanks, that helped
00:20:27*kunev quit (Ping timeout: 240 seconds)
00:21:16*kunev joined #nim
00:42:21*gokr quit (Ping timeout: 256 seconds)
00:45:22*MJCaley joined #nim
00:57:55*Sentreen quit (Ping timeout: 260 seconds)
01:10:28*Sentreen joined #nim
01:49:57*vlad1777d quit (Ping timeout: 240 seconds)
01:55:20*dyce[m] quit (*.net *.split)
01:55:22*zielmicha_ quit (*.net *.split)
01:55:22*mal`` quit (*.net *.split)
01:55:24*jonafato quit (*.net *.split)
01:55:25*euantor quit (*.net *.split)
01:55:57*jonafato joined #nim
01:56:13*zielmicha_ joined #nim
01:56:16*euantor joined #nim
01:56:34*mal`` joined #nim
01:57:55*dyce[m] joined #nim
01:58:52*MJCaley quit (Quit: MJCaley)
02:17:02yunfani saw nim dont has a backend of any assembly lang, why? if its for saving time, why not choose llvm?
02:27:53*allan0 quit (Ping timeout: 265 seconds)
02:35:39*allan0 joined #nim
02:45:28FromGitter<Quelklef> Nim -> C -> asm
02:45:30FromGitter<Quelklef> ?
02:45:49yunfani mean why not directly translated to llvm ir?
02:45:54yunfannim -> llvm ir
02:46:08FromGitter<Quelklef> dunno
02:46:11FromGitter<Quelklef> probably a lot harder than C
02:49:37yunfanalso do you have any prebuilt binary for android?
02:50:43*endragor joined #nim
02:50:59*endragor quit (Remote host closed the connection)
02:51:27*endragor joined #nim
02:51:50*MJCaley joined #nim
02:57:10FromGitter<data-man> @yunfan: See https://github.com/arnetheduck/nlvm
03:01:45*chemist69 quit (Ping timeout: 256 seconds)
03:02:08*MJCaley quit (Quit: MJCaley)
03:05:51yunfanthanks
03:09:20FromGitter<putao88> How to implement the routing function of karax with NIM
03:09:39FromGitter<putao88> Have anyone ever used it
03:13:09*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:15:09*chemist69 joined #nim
03:30:06*ehmry quit (*.net *.split)
03:30:08*planetis[m] quit (*.net *.split)
03:30:15*vegax87 quit (*.net *.split)
03:30:17*Sargun quit (*.net *.split)
03:30:32*Sargun joined #nim
03:30:59*vegax87 joined #nim
03:32:30*planetis[m] joined #nim
03:33:01*ehmry joined #nim
03:39:05*tyler569 quit (Ping timeout: 240 seconds)
03:46:44*fvs joined #nim
03:52:09FromGitter<honewatson> @putao88 you mean with history api?
03:57:19*marenz__ quit (Ping timeout: 248 seconds)
04:20:14*dddddd quit (Remote host closed the connection)
04:29:34*Yardanico[Phone] joined #nim
04:29:47FromGitter<putao88> yes
04:46:26yunfan@data-man nlvm compiled stuck at some stage, and it has been passed hours, so i stop that make
04:49:50*Yardanico[Phone] quit (Quit: Quit)
05:02:32*fvs left #nim ("ERC (IRC client for Emacs 25.3.1)")
05:02:38*pleiosaur quit (Remote host closed the connection)
05:31:37*Trioxin joined #nim
05:32:36Trioxinwhat's the best way to implement an HTTP server in Nim? I have a need to code a very high-performance API. The doc for asynchttpserver says it shouldn't be used in production.
05:34:38Trioxinwould asyncnet be good for implenting a websocket server?
05:36:30FromGitter<gogolxdong> There is a websocket library implemented by asyncnet ` https://github.com/niv/websocket.nim`
05:38:02yunfani think websocket is the best choice before http2 become popular
05:38:13*derlafff quit (Remote host closed the connection)
05:38:37*derlafff joined #nim
05:39:59Trioxinyunfan, what I mean is which Nim library should I use? My API needs to have 2 parts. One is a websocket server and the other is a typical HTTP API
05:40:07Trioxinlibraries*
05:40:55TrioxinThe reason I want to use Nim is because it needs to handle a massive amount of traffic
05:40:55yunfanTrioxin: isnt that websocket need a http entry for upgrade?
05:41:16yunfanwhat i mean is to upgrade all your http gate to websocket
05:41:34yunfani am also a backend developer too, i could understand your needs
05:41:38*chemist69 quit (Ping timeout: 276 seconds)
05:42:15Trioxinyunfan, you think Nim can handle this well vs something like Node?
05:43:53*chemist69 joined #nim
05:44:23yunfanTrioxin: yes, i am quit sure after yesterday i'd test that
06:01:47*wurui joined #nim
06:25:44*nsf joined #nim
06:30:18*xkapastel quit (Quit: Connection closed for inactivity)
06:51:11*endragor quit (Remote host closed the connection)
07:10:57*couven92 joined #nim
07:11:40*endragor joined #nim
07:12:41*tec joined #nim
07:12:48*sz0 joined #nim
07:16:33*endragor quit (Ping timeout: 256 seconds)
07:26:53*endragor joined #nim
07:31:54*Trioxin quit (Ping timeout: 265 seconds)
07:39:11*gokr joined #nim
07:55:44yunfanjust test a recursive fibonacci 35, and found nim is better than go in binary size and running speed
07:55:53yunfanvery glad of this, thank you team
07:57:19*SenasOzys_ joined #nim
07:59:44miranyunfan: how big are the differences? give us some numbers :)
08:02:03yunfanmiran: well its a recursive implement of fibonacci, and i use 35 for testing, since the result is not out of the native big int. and i'd use nim 0.17.2 go-18 cpython2.7 a pypy2.7 for test
08:03:49yunfanthe time costs were 0.02s, 0.05s 1.8s 0.3s
08:04:24yunfanmiran: for nim , i use `nim c -d:release ` , while for go, i use `go build -o fib.2 -ldflags '-s -w'`
08:04:46yunfanalso the size difference is much bigger in 10 times
08:04:58yunfannim version only have 81k, while go version has 1001k
08:05:14FromGitter<survivorm> Not really illustrating
08:05:17yunfanmy testing platform is a ubuntu 1710 x86_64
08:06:02yunfananyway, i am very satisfied of such result
08:06:15FromGitter<survivorm> tests should run more, the 0.02s is too little, such times are much more affected by fluctuation
08:06:23*Vladar joined #nim
08:07:18Araqthe binary sizes are illustrating though since Golang by design cannot perform effective dead code elimination. but don't quote me on that, maybe I've overlooked some trick they could in theory pull off.
08:07:34FromGitter<survivorm> More proper is to run it, for example, 1000 times (and print it to file or do smth similar to not be cleared by compiler;s optimizations)
08:07:37yunfanwell i had run that binary serveral times
08:07:51yunfan0.02s is just a average result, also for go's 0.5
08:08:28FromGitter<survivorm> I mean 1000 cycles inside one run
08:08:59yunfanyou were right, maybe we need to design a benchmarks to show this
08:09:11yunfanand i think memory usage need to be measured too
08:09:35FromGitter<survivorm> and several runs, of course. And then write as proper experiment data, like 1.05 +- 0.01
08:09:39FromGitter<survivorm> :)
08:10:32Araqfib is a pretty bad benchmark anyway
08:11:03FromGitter<survivorm> I'm physicist by education, so i'm a little obsessed in that way :)
08:11:21Araqcompilers can detect it and optimize it into its closed form
08:11:23yunfanwell that's out of my ability currently :D
08:12:44FromGitter<gogolxdong> Is there a defer close of DbConn?
08:13:04Araqgogolxdong: if you write it
08:13:31FromGitter<survivorm> I think the things to be measured are - disk i/o, memory i/o, memory usage, time-consuming calculations, integer and fp respectively.
08:13:57FromGitter<gogolxdong> haha ,what 's it now ,try and except close?
08:14:08FromGitter<survivorm> Gui performance is a little hard to measure (to compare), i think
08:14:25Araqtry: ... finally: close(dbHandle)
08:15:25miranwhen people start talking about (nim and) benchmarks, this is posted: https://github.com/kostya/benchmarks
08:16:09FromGitter<survivorm> Yeah, but the fact is - i don't thing many people understand WHAT is done there
08:17:02FromGitter<survivorm> And i'm not quite sure about the code quality
08:17:15FromGitter<survivorm> of all language versions
08:18:26mirancan we improve nim code for those examples?
08:18:41FromGitter<survivorm> By PR-s, i think
08:19:21FromGitter<survivorm> but the question is - are they illustrative? Just what is done in 'em?
08:19:51FromGitter<survivorm> Aren't they too domain-specific
08:20:02miranbut can they be improved? i just skimmed through them....
08:20:24FromGitter<survivorm> Question not to me
08:22:31FromGitter<gogolxdong> what if a break from except, does finally work?
08:23:32FromGitter<survivorm> That's meaning of finaly, i suppose :)
08:23:54FromGitter<survivorm> Or do you mean marked break?
08:24:07FromGitter<survivorm> to the block mark i mean
08:24:51FromGitter<survivorm> @miran the only interesting test (for me) is JSON
08:26:23FromGitter<gogolxdong> like ``` ⏎ ⏎ `````` [https://gitter.im/nim-lang/Nim?at=5a605a2f517037a212bf5573]
08:26:24Araqgood thing we never optimized JSON :P
08:26:30FromGitter<survivorm> Applicational. The other one may be simple http server performance, like jester's test
08:26:34FromGitter<gogolxdong> like
08:26:45FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a605a45ba39a53f1a2d4935]
08:27:36FromGitter<survivorm> Why break from except?
08:28:14Araqsurvivorm: "stop after N attempts" idiom?
08:28:15FromGitter<gogolxdong> what if.
08:29:18FromGitter<survivorm> i'd better use a var-based while and just set it false in except
08:29:34Araqgogolxdong: the section in a 'finally' is guaranteed to run unless you call 'quit'
08:29:36miransurvivorm: and JSON is a benchmark where nim is as slow as python....
08:29:57FromGitter<gogolxdong> clear
08:30:03Araqwell as slow as Python's C implementation iirc
08:30:19Araqbut we're doing bad in this benchmark for sure
08:32:02FromGitter<survivorm> And nim's json is missing concrete structures parse implementation, i think (like parse([typedef]))-> list of <typedef> objects
08:33:01*floppydh joined #nim
08:33:04FromGitter<survivorm> Anyways, tests shoud either postulate just what is being tested or be real-life examples
08:33:36FromGitter<survivorm> And of such, i see only json test in this benchmark :(
08:39:05miranhowever these tests might be, it is what people look and how they compare the speed of languages
08:39:17miran*however bad
08:40:01FromGitter<survivorm> Yeah, and that's what makes me especially unhappy
08:40:28FromGitter<survivorm> They ARE bad, so people get mislead, misguided
08:42:14FromGitter<survivorm> My thoughts at reading this tests: interesting, but don't know, interesting, but don't know, ..., oh, json. Performance.... python is great, nim might been better, interesting, but don't know, interesting, but don't know...
08:43:01FromGitter<survivorm> Even Java is much better in this test :(
08:43:43*yglukhov joined #nim
08:44:06yunfansurvivorm that testing has some problem, for eg, the json test, python got the high marks only because ujson is a pure c extension
08:44:32FromGitter<survivorm> I know that
08:45:21yunfanso i wonder if there're other similar problem in those tests which i dont know about
08:45:24FromGitter<survivorm> but that doesn't solves the problem. What shoud I think about language performance, based on this test?
08:46:26miransurvivorm: what about these benchmarks: https://benchmarksgame.alioth.debian.org/u64q/task-descriptions.html - any good?
08:47:11FromGitter<survivorm> So, i'm backing to my previous thoughts: tests should either be simple, just operation-based, or real-life based
08:47:25FromGitter<survivorm> @miran - no better
08:47:47miran"We ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result."
08:47:48FromGitter<survivorm> do you know at least 60% of that tests
08:47:52FromGitter<survivorm> ?
08:48:15FromGitter<survivorm> Ah, benchgame is biassed
08:48:33FromGitter<survivorm> there's a lot of talks on the net about it
08:48:37yunfanmiran: if they ask the same algorigthm, then which is the standard? you know some language has special ways, like forth :D
08:49:31*Vladar quit (Quit: Leaving)
08:49:52FromGitter<survivorm> He is even not including some languages/implementations based on his left leg thumb's thoughts
08:56:30mirani might try to implement n-body benchmark in nim, we'll see if i manage to find the time to do it....
08:56:52FromGitter<survivorm> Even json test is not so illustrative: better are something like parsing large json, outputting json of internal data structures, and something like json->yaml and yaml->json for large files for illustrating converting formats
08:57:02miraneven if it is a bad benchmark, just to have an idea how fast/slow is nim for that kind of problems
08:57:30FromGitter<survivorm> And that illustrates exactly what?
08:58:17*Arrrr joined #nim
08:58:49FromGitter<survivorm> I mean, there are such problems common? They might be, maybe i just don't know
08:58:55miranspeed for numerics?
08:59:26FromGitter<survivorm> Of which ones? Fp, int, +, *, ^?
08:59:26*SenasOzys_ quit (Read error: Connection reset by peer)
08:59:43FromGitter<survivorm> logarifmic, trigonometric?
09:00:05mirani usually don't have numerical code which does only one operator, but a bunch of them together
09:00:34FromGitter<survivorm> And so, make a more real-life example
09:00:49FromGitter<survivorm> or do simple synthetic
09:00:57FromGitter<survivorm> it's either-or
09:01:33mirani might later do some simple DAE solver
09:01:55miranbut first i need to do it in python. well, i should be doing it right now.... :)
09:02:04FromGitter<survivorm> :)
09:02:18FromGitter<survivorm> That's more realistic, yeah
09:02:46FromGitter<survivorm> made something similar myself, years ago... in matlab :)
09:05:02FromGitter<survivorm> Forgot methods just after finishing the solution, just remember using sparce-matrixes
09:05:21mirani'm trying to convert my colleagues from matlab to python
09:05:27miranone down, two to go
09:05:33FromGitter<survivorm> :)
09:06:07FromGitter<survivorm> Good luck with that :) In my opinion, both are great
09:06:18Araqbenchmarks that test library implementations need to say so.
09:06:22FromGitter<survivorm> in their own domain
09:06:51Araqlibraries are important, usually moreso than languages, but if you try to benchmark languages, you should do that.
09:07:03Araqand in this sense json is meaningless.
09:07:07miranmatlab is especially great in "we don't have a licence for that, we can only use some outdated version, what now?"
09:07:44FromGitter<survivorm> @Araq, yeah, they should. But did you ever seen good lang bencmarks? Even statisfying ones?
09:08:58FromGitter<survivorm> @miran then i've been student, we've never bothered by such thing as "license"
09:09:29FromGitter<survivorm> Russia's quite more simple about that :D
09:11:07mirani'm in croatia, it is (almost) the same here ;)
09:12:28Araqsurvivorm: the scientific computing benchmarks are usually good, but limited to floating point / matrix performance. but if that's your domain, they have relevant results
09:13:03*PMunch joined #nim
09:15:51FromGitter<data-man> @Araq: Why a threadvars in other modules are correct?
09:16:16Araqdata-man: sorry, but you don't understand thread vars.
09:16:44Araqvar x {.threadvar.}: int = 8 # compiler complains, no clue why, so you rewrite that as
09:16:53Araqvar x {.threadvar.}: int
09:16:56Araqx = 8
09:17:10Araqbut that's wrong.
09:17:29Araqthe compiler tries to tell you it's the wrong idea.
09:17:53Araqthat 'x' is 8 only for the main thread then.
09:18:14Araqevery other thread has its own version of 'x' and it's 0 because that's the default initializer
09:21:13*sendell joined #nim
09:22:07*sz0 quit (Quit: Connection closed for inactivity)
09:23:24FromGitter<survivorm> So, basically, with threadvars, you must operate them only AFTER split?
09:23:54FromGitter<survivorm> Because they are initialised in that moment
09:25:11Araqevery thread needs to initialize its own version of it, usually that is done in every proc that needs it via a guard like
09:25:21Araqif v == nil: v = newThing()
09:26:14Araqin data-man's case he can can get away with plain old global variables of type 'bool' but that has other downsides
09:27:09*Vladar joined #nim
09:27:21FromGitter<survivorm> Global vars usually are frowned at :)
09:27:25Araq(note that this lazy initialization guard does NOT need to be protected with a lock because it's not shared memory)
09:28:19Araqglobals are more convenient than they are harmful.
09:28:55FromGitter<survivorm> I think it's more the case of not overusing them
09:29:49FromGitter<survivorm> And usually you may exclude globals by not much design complexity tradeoff
09:30:05AraqI beg to differ.
09:30:56Araqglobals will be with us as long as implicit function parameter passing through large subsystems remains a dream
09:32:08Araqf(a, b) # new dependency introduced, make that f(a, b, c) ? in thousands of lines of code? breaking all existing clients of the API?
09:32:54FromGitter<survivorm> Hm. I don't think it's a good example
09:33:33Araqit's the example that comes up in the Nim compiler. all the time.
09:34:49FromGitter<survivorm> thats more like poorly desined API, in most cases. USUALLY you either may predict theese deps or they are not obligatory. So may be well defaulted
09:35:58FromGitter<survivorm> But no offence meant
09:36:27FromGitter<survivorm> I do not now the context
09:36:31FromGitter<gogolxdong> MariaDB 10.2.12 was installed and grant all privileges to root@% as well localhost , but connecting to localhost keeps `SIGSEGV: Illegal storage access. (Attempt to read from nil?)`
09:37:09FromGitter<gogolxdong> can be connected from remote
09:37:25FromGitter<survivorm> Looks like something is not being initialised
09:37:41FromGitter<survivorm> but don't know why
09:37:59FromGitter<gogolxdong> ```import db_mysql ⏎ var db = open("localhost:3306", "root", "cncare", "cmp")``` [https://gitter.im/nim-lang/Nim?at=5a606af75ade18be398ecc20]
09:38:32FromGitter<gogolxdong> just two lines.
09:40:28FromGitter<gogolxdong> I tried python connector, it also worked. ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a606b8c5a9ebe4f75a079fd]
09:40:56yunfanbtw, is there any list like `awesome nim` stuff?
09:41:12yunfani want to make some socket based server
09:41:16livcdyes there is
09:41:19Araqgogolxdong: try without the port like the Python version?
09:41:33livcdhttps://github.com/VPashkov/awesome-nim
09:41:51FromGitter<gogolxdong> the same
09:42:06yunfanthanks livcd
09:43:35Araqdoes mariadb ship with a lib*.so that looks like "libmysqlclient.so.(15|16|17|18|19|20)" ?
09:45:04FromGitter<gogolxdong> I installed MariaDB-server MariaDB-client
09:45:37*wurui quit (Remote host closed the connection)
09:46:04FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a606cdb6117191e617e260b]
09:46:05Araqsurvivorm: withotu globals you cannot even add stdout.write statements for debugging
09:48:24Araqgogolxdong: look for libmysql* in /usr/lib
09:48:45FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a606d7dae53c1590301953e]
09:51:42Araqedit mysql.nim
09:51:59Araqlib = "libmysqlclient.so.(15|16|17|18|19|20)"
09:52:03Araqmake that line
09:52:43Araqlib = "libmysqlclient.so.(|20|19|18|17|16|15)"
09:52:49Araqand try again
09:58:12FromGitter<data-man> @Araq: Maybe you will make the right changes? I'm tired. :(
09:58:59Araqok, np.
09:59:19*arnetheduck joined #nim
10:04:57FromGitter<data-man> Thanks!
10:07:59dom96Trioxin: Feel free to use asynchttpserver, but put it behind nginx.
10:09:15*zahary_ joined #nim
10:13:45FromGitter<gogolxdong> yeah,what's the trick?
10:14:21FromGitter<gogolxdong> reverse order
10:16:32Araqgogolxdong: prefer later versions over early library versions.
10:16:38Araqdid that work?
10:17:54FromGitter<gogolxdong> yes
10:20:05*chemist69 quit (Ping timeout: 255 seconds)
10:20:28*chemist69 joined #nim
10:20:45Araqok, pushing this fix then
10:33:13*Yardanico joined #nim
11:05:04*Yardanico quit (Quit: Leaving)
11:09:54*gokr quit (Quit: Leaving.)
11:15:35*Arrrr quit (Ping timeout: 240 seconds)
11:15:47FromGitter<gogolxdong> Did you push?
11:16:06FromGitter<gogolxdong> It seems right.
11:33:05*tec left #nim ("Leaving")
11:35:59*Yardanico joined #nim
11:38:59FromGitter<alehander42> what the fuck, when did strformat.% disappear ?
11:41:51Yardanicorecently
11:41:51Yardanico:)
11:42:49PMunchWhat? Why?
11:43:04Yardanicoalehander42 PMunch : https://github.com/nim-lang/Nim/commit/9a60eae631e9f778d3920f3a66de0e726e687eef
11:43:10Yardanicohttps://github.com/nim-lang/Nim/issues/7078
11:47:02PMunchAh, it just switched name :P
11:47:50FromGitter<alehander42> I don't understand what's wrong with @dom96 ops module proposal
11:48:04*Sentreen quit (Ping timeout: 265 seconds)
11:51:31FromGitter<alehander42> honestly I'll just patch my local nim and wait until the final solution about that :D
11:51:52PMunchProblem is that it still collides with the json module
11:52:10PMunchSo if you want to use json then you can't use string formatting with this procedure
11:52:57*sz0 joined #nim
11:55:00FromGitter<alehander42> honestly, I'd just hide json.`%`(string) and add an alias for it, if one really needs to create a JString somewhere in his user code
11:57:11FromGitter<survivorm> honestly, why not add `as` construct to import like in python? like `from json import % as toJson`?
11:57:15PMunchYeah, but it's a bad thing that the standard library collides with itself..
11:57:34FromGitter<alehander42> or, I would move the json.%(string) to its own module and if one really needs explicitly this version of it, he can import it
11:58:28FromGitter<survivorm> @alehander42 dom96 will object that it collides with The Book (tm) :)
11:59:24FromGitter<survivorm> Honestly, should The Book be renamed as Codex? :)
11:59:32FromGitter<alehander42> @dom96 should just make a time machine, go back and change json dsl to use ~ or something, just to make us feel good :D
12:00:04*sendell quit (Remote host closed the connection)
12:00:25*Sentreen joined #nim
12:01:15FromGitter<survivorm> personally, i'd bind The book to nim version, not v1, as it is still not out, but, say, 0.17.3, and write minor changes in later versions in errata
12:02:00*Arrrr joined #nim
12:02:00*Arrrr quit (Changing host)
12:02:00*Arrrr joined #nim
12:02:15FromGitter<survivorm> I think this decision is sane
12:07:12FromGitter<survivorm> as the situation, as it's now reminds me of Tale of the Troika by Strugatskie and The Book is seems stamped by big round stamp...
12:08:49FromGitter<alehander42> overally I don't really agree that it's stdlib's problem: it's very possible to have <name>(<type>) stuff in several different modules that makes sense, the language provides the user with a tool to choose priority, it's still "playing nicely"
12:10:14FromGitter<survivorm> Yeah, i agree
12:12:31AraqI prefer & because it's constructing a concatenation
12:12:50FromGitter<alehander42> I think c programmers will be very confused in the beginning
12:12:53AraqI also want to have % which would construct a format string with dollars for i18n purposes
12:12:55FromGitter<alehander42> by unary `&`
12:13:11Araqso eventually I want to have both unary & and unary %
12:13:19Araqbecause both are required.
12:14:03Araq%"{a} contains {b} elements"
12:14:07Araqbecomes
12:14:22Araqi18n"$1 contains $2 elements" % [a, b]
12:14:29FromGitter<survivorm> And that makes sense. How about `as` in import?
12:14:37Araqbut we still lack the i18n proc :P
12:14:52FromGitter<alehander42> ok, the i18n thing sounds cool, but than this means the name clash wasn't actually the problem
12:15:36FromGitter<alehander42> I know well that we'll use a planet emoji for i18n
12:15:39Araqit was a problem for yglukhov, and I respect his opinion.
12:15:43FromGitter<alehander42> and this is all smoke and mirrors
12:16:39FromGitter<alehander42> :D & still makes some sense, haven't thought about concat
12:16:39Araqmaybe we can make unary % part of the i18n module... and then the story can repeat
12:17:02Araqbut for now I consider strformat stable.
12:17:04FromGitter<alehander42> that's what I am saying, people will say the same about i18n %
12:17:33Araqalehander42: by then we hopefully have a better and much faster json module (see that benchmark problem)
12:17:53Araqa json.nim module without the % constructors ;-)
12:17:53FromGitter<survivorm> Ah, about short names and clashes
12:18:28Araqpersonally I agree though, use json.`%` vs strformat.`%` ffs
12:18:45Araqthe language does offer a sweet mechanism for disambiguation.
12:19:01Araqmultiple mechanisms in fact, import x except `%`
12:19:15*xet7 quit (Ping timeout: 260 seconds)
12:19:56*dddddd joined #nim
12:21:19FromGitter<survivorm> Maybe a little crazy idea, but may be it would be viable to make a namespacing import mechanism, like `import json mark functions`, there functions is treated as a list of names with name functions. Another way to avoid ambiguosity
12:22:16Araqanother minor argument: the existing '%' uses the dollar syntax, strformat.`%` used {curlies}, not really consistent
12:22:33FromGitter<survivorm> And then the standard import may work as `import X mark all` if all is defined
12:23:00*xet7 joined #nim
12:23:08FromGitter<survivorm> personally, i'd prefer curlies
12:23:33FromGitter<survivorm> the syntax seems more clear and more powerful
12:23:57miranwait what?! strformat story is not over yet?
12:24:28Araqmiran: for me it is. unary '%' will be a different proposal
12:24:32FromGitter<alehander42> yeah but `concat &` also doesn't have the formatting capabilities of `&`{}
12:24:48FromGitter<alehander42> so they're both equally "associative" naming
12:24:51miranAraq: just to check - `fmt` still works?
12:25:01miranjust as when it was %
12:25:16Araqmiran: 'fmt' works and now also unary '&'
12:25:55miranok, i think i'll just use `fmt`, because this seems to be something that doesn't/won't change, unlike the symbol(s)
12:26:54AraqI will fight hard for keeping unary '&'
12:27:40miranAraq: let us all rather fight hard about some other, more important, things ;)
12:28:07FromGitter<alehander42> when is v0.18 supposed to be released :?
12:29:23AraqI won't say "before FOSDEM", but it is what I'm thinking.
12:30:27mirangreat news Araq!
12:30:56miranand now for the hard question - what version comes after v0.18? :)
12:31:29Araqv1 RC 1.
12:31:45Araq"a planet emoji for i18n" -- what does that mean?
12:32:14miranwooohooo
12:33:32*marenz__ joined #nim
12:33:32FromGitter<alehander42> before FOSDEM would be excellent
12:34:06FromGitter<alehander42> ah, just noticing that an emoji *obviously* would be a great dsl symbol
12:34:31FromGitter<alehander42> also, I think the promille sign can still be used instead of percent ;)
12:34:53FromGitter<alehander42> (not serious)
12:35:14Araqdon't wooohooo me yet, wooohooo me when it's out please.
12:36:02Araqalehander42: zahary said i18n is a more interesting problem because it also affects HTML styles like <b><i>
12:36:31miranAraq: no, when it is out it will be much more ooos there :)
12:36:35Araqso for karax it should be based on verbatim strings
12:36:42Araq*should not
12:41:43FromGitter<alehander42> @Araq hm, interesting, I haven't thought about this case
12:42:19FromGitter<alehander42> there can be some cases when you're supposed to bold / italic words only for some localizations ?
12:42:31Araqaccording to him, yes
12:42:49Araqthe translated text also can affect the layout in other ways
12:43:26Araqplus it's not clear whether people want to switch languages at compiletime or runtime
12:43:51Araqruntime is slower but less tedious to deploy
12:44:19Yardanicofirefox uses both btw
12:44:32YardanicoYou can download firefox in your language (precompiled), or install your language as an addon
12:52:22*Sembei quit (Read error: Connection reset by peer)
13:02:47*Snircle joined #nim
13:10:07dom96lol
13:33:37*leorize joined #nim
13:55:45*Arrrr quit (Ping timeout: 248 seconds)
13:59:06PMunchThe streams module, will it read/write with different endianness depending on platform?
14:03:31yglukhovPMunch: no, it doesn't care
14:03:33FromGitter<GULPF> yes, I think there is an issue for that
14:03:40FromGitter<GULPF> reall?
14:03:45FromGitter<GULPF> u
14:04:18yglukhovi mean streams.readInt will return different values depending on platform endianness
14:04:37FromGitter<GULPF> ok, then we agree
14:04:39PMunchyglukhov, well that's a pain..
14:04:56PMunchEspecially since there isn't a way to specify endianness..
14:05:02FromGitter<GULPF> https://github.com/nim-lang/Nim/issues/4322
14:05:53euantorWould be nice to pass a second parameter to the proces for the endian IMO
14:06:22yglukhovit should be trivial to add LE+BE variants to appropriate read/write procs in streams.nim
14:06:39yglukhoveuantor: thats a runtime cost
14:07:25yglukhovimo its better to just add LE/BE variants, and deprecate the procs with unspecified endianness
14:07:29FromGitter<RedBeard0531> Not if it is a compile-time constant to an inlined function
14:07:31Yardanicoyou can use struct.nim
14:07:39Yardanico(it's a module in nimble)
14:07:55PMunchyglukhov, not if it's implemented with a static parameter and a compile time check :)
14:07:57Yardanicoit's a python-like struct module, but it's of course slower than streams
14:09:09yglukhovok, true. still, why would you want to write stream.read(myVal, true) all the time instead of stream.readBE(myVal). or stream.readInt32(true) instead of stream.readInt32BE()
14:09:36yglukhovwith true/false you have to always remember what they mean =)
14:10:18FromGitter<RedBeard0531> Default params would make it not be painful (and I'd assume it would be an enum big/little/native(?) rather than true false)
14:10:50PMunchMake it an enum :)
14:10:59PMunchstream.read(myVal, BigEndian)
14:11:00yglukhovits just BE vs LE. there is no Native
14:11:07FromGitter<RedBeard0531> Personally I'd default to little, since big endian is effectively dead, but I'm sure that is controversial
14:11:24yglukhovreads always return native. writes always take native.
14:11:49PMunchBig endian is used for most network traffic
14:11:53PMunchSo not exactly dead
14:12:12yglukhovPMunch, you'd be surprised =)
14:12:19FromGitter<RedBeard0531> Only at the lowest levels. Most new protocols use little endian
14:12:24yglukhove.g. capnproto is always LE
14:12:31yglukhovbecause its real world now.
14:13:21FromGitter<RedBeard0531> big is useful for 1) old protocols (unfortunately including tcp/ip) and 2) when you need a memcmp-able format for numeric data
14:13:39FromGitter<RedBeard0531> but almost everything else seems to use little endian these days
14:14:04FromGitter<RedBeard0531> "network endian" just backed the wrong horse :(
14:14:40euantoryglukhov: I was thinking more `stream.readInt(myVal, eBig)` where there is an `Ednians` enum of `eBig and eSmall`
14:16:34yglukhoveuantor: ok, readInt could be readInt(i: var int, endianness: static[Endianness]). But why would you want that?
14:16:52yglukhovExcept maybe for some formats that can have various endianness..
14:16:59yglukhovso then its a runtime cost anyway...
14:17:25euantorHaving 10 procs rather than 20 procs seems like a good reason to me
14:17:44euantorMakes maintenance easier and documentation easier to read
14:18:31yglukhovi've never thought from that perspective.
14:18:56yglukhovmaintanance of such procs feels like find and replace to me =)
14:19:05*natrys joined #nim
14:19:19*nsf quit (Quit: WeeChat 2.0.1)
14:19:25FromGitter<RedBeard0531> It also makes it easier to forward from callers. eg you could build a `proc writeT (to: var stream, v: T, endian =eLittle)` and only write one rather than have both BE and LE versions
14:20:15*sendell joined #nim
14:20:41FromGitter<RedBeard0531> please don't call the enum value small-endian...
14:21:21yglukhovwell ok. i don't really mind enum arg that much. indeed there might be use-cases for it.
14:21:25yglukhoveven in runtime
14:21:52yglukhovstill i think the readInt should be overloaded by static vs non-static arg.
14:22:01yglukhovbecause static is likely to be used a heck more
14:22:18PMunchYeah I'd be fine with only static
14:22:23FromGitter<RedBeard0531> If they are {.inline.} compilers are really good at const-propagation, so it shouldn't matter
14:23:07PMunchIf you need runtime you could do something like if myEndian == little: s.readInt(little) else: s.readInt(big)
14:23:21FromGitter<RedBeard0531> I'd want to see -d:release disassembly before buying an argument to use static for perf reasons
14:23:43PMunchHmm, this is strange. If I run my program with a regular echo I get two different numbers. If I add .toHex they are the same..
14:24:28yglukhovhrmm.. toHex bug?
14:25:15PMunchLooks like it
14:27:22PMunchOh no wait, my bad :P
14:27:27PMunchThey were just really similar
14:28:18yglukhovok. so whos gonna be the lieutenant for streams endianness awareness? ;)
14:29:30PMunchI can create an issue for it at least :)
14:29:44yglukhovthere's already an issue, no? =)
14:30:18PMunchhttps://github.com/nim-lang/Nim/issues/4322 this one?
14:30:30PMunchI was thinking a more RFC oriented one
14:30:36yglukhovyup
14:30:43PMunchWith what we have discussed here now
14:31:27yglukhov+ i would vote for deprecation of careless procs.
14:31:35yglukhovwhat do you guys think?
14:32:38euantoran RFC issue sounds like a good idea to me
14:32:39yglukhovanother option would be add the Endianness = Little by default. so no deprecation would be needed
14:32:42miranmake a RFC
14:33:01euantorMaybe a good idea to include some details of how it works elsewhere (D, Rust, etc.)
14:34:12dom96So I've got a challenge for you guys. Araq has the idea of putting a Nim Game of Life implementation on the back of our FOSDEM flyer, can anyone create a small enough implementation so it fits on a small leaflet? :)
14:34:35Araqit also needs to be reasonably readable
14:34:44zahary_Araq, alehander42, to clarify what I meant about i18n:
14:34:44zahary_Sometimes you have to translate sentences involving markup -- "The <a href="Whale">Whale</a> is the largest living mammal" -- and this markup can be produced by your Karax-like DSL.
14:34:49Araqwe don't want some cryptic shit nobody can read
14:34:53Araq;-)
14:34:54zahary_ It's much better if the translator sees the whole sentence, but in a form that preserves the markup somehow - e.g. "The {Whale} is the largest living mammal"
14:35:15dom96Also, bonus points if you can somehow initialise the board with a single glider, or the text "nim" or something
14:35:30zahary_Then if the same markers are included in the translated text, this can be used to put back the words in the correct places in the DSL form
14:35:37PMunchHmm, I do have game of life programmed in Nim already
14:35:47zahary_I've successfully implemented such a system for the Jade templating langauge
14:35:56PMunchBut it's a bit bigger than the back of a flyer (although it supports all kinds of crazy things)
14:37:13miranre: game of life - this might can be a nice example to follow: http://nbviewer.jupyter.org/url/norvig.com/ipython/Life.ipynb
14:37:42PMunchOr this: https://github.com/PMunch/drawille-nim/blob/master/examples/gameoflife.nim
14:37:46PMunchWhich is already in Nim
14:37:46yglukhovhere's what google found: https://github.com/arthurtw/nim-examples
14:37:59PMunchJust need to strip away all the extra features like PNG loading and such
14:39:41miranAraq: "we don't want some cryptic shit" ...and please don't use any iterators, we don't want to embarrass ourselves :D
14:39:59Araqhuh? iterators are super clean
14:40:36Araqyou don't have to use .closure, explicit creation and looping via finished()
14:40:43dom96Here is what I quickly came up with by modifying the Rosetta Code sample: https://gist.github.com/dom96/785c7d046e1035af4a65f04c0a0e82fd
14:42:54mirandom96: can't `newSeqWith` be used?
14:43:11miraninstead of lines 8-11
14:44:10dom96yeah, lots of room for improvement
14:44:57miranok, so we take that as a template and improve it?
14:45:59dom96sure, if you want. or start from scratch :)
14:46:17miranok, when is the deadline? :)
14:46:19FromGitter<RedBeard0531> If h and w are const, why not just `var univ, utmp: array[h, array[w, bool]]` ?
14:47:34FromGitter<alehander42> @zahary_ so it's basically a recursive i18n function which replaces text subnodes with their text translation?
14:51:15zahary_yes, it performs a recursive traversal in the case of Jade, but it could also be integrated in the Karax in other ways - the top node populates a stack of "translations pieces" and the subnodes pop out items from it
14:51:19yglukhovzahary_: how does your impl look like in jade?
14:51:27yglukhovi mean the usage of it
14:51:48zahary_You mark a text to be translated by putting a !T prefix
14:51:51dom96miran: No idea. Whenever somebody comes up with a small enough sample, or we decide against this idea entirely :P
14:51:53PMunchI think this is the shortest I can get my game of life example: http://ix.io/EjC/
14:51:59PMunchWith actually having something on screen
14:52:24zahary_!T The #[a(href = 'Whale') Whale] is ...
14:52:25mirandom96: ok, i'll see what i can do
14:52:56yglukhovPMunch: i really think its quicker to start a pr instead rfc discussion =)
14:53:01zahary_Or like this
14:53:01zahary_span
14:53:01zahary_ | !T The
14:53:01zahary_ a(href="Whale") Whale
14:53:01zahary_ | is the largest
14:53:35PMunchyglukhov, but then I have to write the code. Which I don't have time for right now :(
14:53:41dom96PMunch: Nice. Keep going :)
14:53:41miranPMunch: add some spaces please :)
14:53:53PMunchI was trying to keep it compact miran :P
14:53:56dom96also, I don't think this will work on Windows, right?
14:54:14PMunchWhy wouldn't it?
14:54:20zahary_I guess the relevant point to your previous discussion is that a similar mechanim is applied to string interpolations in the code
14:54:22PMunchDoesn't the Windows terminal support utf-8?
14:54:48dom96stdout.write "\e[A\e[K"?
14:54:53PMunchOr are you talking about the terminal clear characters
14:54:54PMunchAh
14:54:56miranPMunch: even with the spaces, it will be as (horizontally) compact as line 15
14:55:24PMunchHmm, yeah I'm not sure how to clear the terminal on Windows..
14:55:29PMunchmiran, oh horizontally
14:55:34PMunchI thought you meant vertically
14:56:28miranjust horizontally for now ;)
14:56:58FromGitter<alehander42> @zahary_ interesting, that sounds reasonable, I thought that some translations can somehow produce additional tags
14:58:01zahary_well, you can in theory if you put tags directly in the translated text, but this was not the point - the point was about preserving the context of the entire sentence when markup or interpolations are present
14:58:12zahary_and sometimes the markup will move around
14:58:13PMunchHmm dom96 your version isn't quite correct is it?
14:58:24FromGitter<alehander42> @PMunch maybe a more functional impl can be more minimal, intuitively it seems to me as a good problem for that style
14:58:27PMunchIt updates pieces of the board before it's all checked
14:58:36miranis it "against the rules" to have a border in game of life? rows 0 and ^1, and cols 0 and ^1
14:58:45PMunchNah
14:58:50zahary_I can't quote a proper example, but in some languages "Please click {here}" becomes "Here {click} please"
14:58:53PMunchalehander42, that might be possible
14:59:35miranPMunch: nah as in it is not against the rules, or as in let's not do that?
14:59:37yglukhovzahary_: cool. how do you extract the keys for the translator out of such template?
15:00:57zahary_we use GetText, so the source text (and the ID of the translation) is this "Please click {here}" form. The translator is supposed to provide a translation having the same number of "slots"
15:01:34dom96PMunch: hrm, maybe. Like I said, I just copied it from Rosetta Code.
15:01:41dom96I think I will create an implementation from scratch
15:01:53PMunchOh wait
15:01:59PMunchIt has univ and utmp
15:02:10PMunchI read those as the same variable :P
15:02:33FromGitter<alehander42> @zahary_ makes sense, how does this apply for right-to-left languages? it seems to me that the order of the slots is important
15:03:22zahary_haven't got a change to work in a hebrew project yet, but woudn't it just reverse the order?
15:04:15*leorize quit (Quit: WeeChat 2.0.1)
15:05:06*acidx quit (Quit: Lost terminal)
15:07:11FromGitter<mratsim> @euantor @pmunch @yglukhov is the RFC created? I use readInt32BE but I'm fine with a static enum, I don't want to pay for dynamic when I don't need it: https://github.com/mratsim/Arraymancer/blob/b061aefd27fb4f8c4a8f4155a388bf9dd5d743c7/src/datasets/mnist.nim#L55
15:10:08PMunchOkay dom96, got it slightly smaller: http://ix.io/EjF/
15:10:52PMunchmratsim, yes: https://github.com/nim-lang/Nim/issues/7105
15:11:04Araqfor x in 0 .. <width * 2: # bug.
15:11:26Araqat least it looks like a bug
15:11:27FromGitter<alehander42> @zahary_ probably. maybe I just can't imagine how you also specify the order in the translation (e.g. except something like "<div>Please</div><a>click</a><span>here</span>" => "{Please} {click} {here}" => "{1: MyClick} {0: MyPlease} {2: MyHere}")
15:12:04PMunchAraq, how so?
15:12:16FromGitter<krux02> dom96: I implemented the new iterator syntax from that issue, if you remember. What do you think about it: http://ix.io/EjG/Nim
15:12:41miranPMunch: `0 ..< 2` is the correct way to do it
15:13:40dom96krux02: nice but I would prefer if this was changed in Nim. Also, calling the iterator to get an instance of it is still odd.
15:14:30FromGitter<mratsim> @miran @araq I thought unary < raised an error now?
15:14:47*acidx joined #nim
15:14:52*gokr joined #nim
15:14:53FromGitter<krux02> dom96: I can only do macro programming changing anything in the Nim sourcecode sadly gives me a headache
15:14:54*bli joined #nim
15:14:56*acidx quit (Client Quit)
15:15:10FromGitter<krux02> doing it in macros allows me to prototype it fast
15:15:12*Guest18787 joined #nim
15:15:37*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
15:15:41PMunchAraq, better: http://ix.io/EjI/ ? Cleaned the code up a bit as well
15:16:04FromGitter<krux02> and what do you mean is odd with the instance?
15:16:20FromGitter<krux02> do you mean ``let x = fibo(0,1)`` is odd?
15:16:24*Snircle joined #nim
15:16:24dom96yes
15:16:30dom96I would prefer an explicit newIterator function
15:16:38FromGitter<krux02> well exactly that was proposed in the discussion
15:17:04*Guest18787 is now known as acidx
15:17:19FromGitter<krux02> well there is still ``instanceIterator(fibo, 0, 1)`` on normal closures
15:17:29*bli quit (Client Quit)
15:19:21FromGitter<krux02> http://ix.io/EjJ/Nim
15:19:30FromGitter<krux02> I added as example 4
15:19:54miranfor those wondering what krux02 and dom96 are talking about: https://github.com/nim-lang/Nim/issues/7047
15:22:50*endragor quit (Remote host closed the connection)
15:24:11PMunchdom96, http://ix.io/EjS/ this should work cross platform by using the terminal library
15:24:20PMunchBut it flickers something horrible on my screen..
15:24:47dom96bbl lecture time
15:24:54*endragor joined #nim
15:29:37FromGitter<andreaferretti> @krux02 great work!
15:29:45*endragor quit (Ping timeout: 264 seconds)
15:30:11FromGitter<andreaferretti> if iterators in nim do not change (altering them now would break a lot of things) this would be a great addition to the `future` module
15:30:55FromGitter<krux02> it seems like you are collecting my macros I write when I am in the mood to do it
15:31:01FromGitter<krux02> :P
15:31:48FromGitter<krux02> and to be honest I don't think altering the closure syntax for iterators would break a lot of things. They are so horrible to use that there are almost no use cases for them.
15:34:32FromGitter<RedBeard0531> Not that I love the current syntax/semantics, but does the current form guarantee that inside the iterator the arguments have whatever value was last passed in? If so, that means these are bi-directional coroutines since in-effect yield can return a value. That opens up some interesting use cases that aren't covered by fixing the arguments at the time of the first call.
15:35:14FromGitter<RedBeard0531> I don't really think that should be the only or even the default way to use them, but just an interesting thing to consider
15:39:48FromGitter<krux02> of course I think you can abuse iterators and change the argument after each call, but honestly I think the biggest effect it will have is to confuse the reader of the code.
15:40:49FromGitter<mratsim> Aka "with great power comes great abuse opportunity".
15:42:36FromGitter<RedBeard0531> Perhaps it would be best to just steal python's syntax and use next() for simple iteration and send(...) for sending data into the iterator: https://docs.python.org/2.7/reference/expressions.html?highlight=yield#generator-iterator-methods
15:44:19Yardanicowhat will happen with performance?
15:47:21FromGitter<krux02> @RedBeard0531 not sure about the `send` from python, but the next is what I basically implemented.
15:47:33FromGitter<krux02> the yield in nim does not have a value
15:47:58FromGitter<krux02> and the question is, what type would yield have if it supports a sand
15:48:48FromGitter<RedBeard0531> It could be specified in the iterator signature somehow
15:50:06AraqNim's iterators are not nearly as bad as portrayed here
15:50:17FromGitter<krux02> when I think about it. the send is the same functionality as the arguments to the iterator call like it is today
15:50:23FromGitter<RedBeard0531> But IMO the bigger problem I've run into with closure iterators is that they don't support yielding from inside a try block. This means they also don't work correctly with defer and destructors. And unlike the poor calling syntax, this can't be papered over by the async macro.
15:50:38FromGitter<krux02> I don't say nim's iterators are bad. I just don't like the syntax
15:50:50FromGitter<krux02> and it is hard to interleave iterators
15:50:50FromGitter<RedBeard0531> Is there any hope of getting exception to work correctly with closure iterators in time for 1.0?
15:51:04Araqno.
15:51:21FromGitter<RedBeard0531> Damn :(
15:51:23FromGitter<andreaferretti> the main issue for me is that it is difficult to iterate only partially
15:51:26AraqI can dream of some way for making it work with the setjmp based implementation
15:51:44FromGitter<andreaferretti> do some iterations, then when you feel like it do some more iterations
15:51:51Araqbut the setjmp impl is exactly what will disappear in the nearer future
15:51:55FromGitter<andreaferretti> with `next` it is easy
15:52:04FromGitter<andreaferretti> without it, not so much
15:52:11Araqthat is also not about syntax.
15:52:22Araqto next a closure iterator, just call it
15:52:25FromGitter<krux02> well mostly it is about syntax
15:52:36Araqoh my that was so hard to explain...
15:52:37FromGitter<krux02> I did not add any functionality with my macro
15:52:50FromGitter<krux02> but I made the usage of iterators simpler (I think)
15:52:53FromGitter<andreaferretti> yeah, but if the iterator has arguments, suddenly you have to call it again with the same arguments
15:53:09Araqactually you can vary the arguments
15:53:17PMunchI think this is the best I can do: http://ix.io/Ekn/ It's cross platform and fairly compact while not being completely unreadable. Plus it shows some variety of Nim functionality
15:53:23FromGitter<andreaferretti> which is precisely what makes it confusing
15:53:25FromGitter<krux02> not just the arguments, but you also have to check with a different function if the value you got is actually a valid value
15:53:31FromGitter<krux02> that is not very intuitive
15:53:35FromGitter<andreaferretti> I want to materialize something once and for all
15:53:40FromGitter<andreaferretti> which I can then step over
15:53:59FromGitter<RedBeard0531> @Araq, you could always just only support compilers that implement the C++ coroutines TS, then the problem just goes away :evil_grin:
15:54:12Araqyup.
15:54:14Araqbbl.
15:54:36FromGitter<andreaferretti> also, it is entirely not clear to me what happens when you change arguments
15:55:01FromGitter<andreaferretti> I am in the middle of iterating over something that depends on some initial value x
15:55:09FromGitter<andreaferretti> now I suddenly pass y
15:55:15FromGitter<andreaferretti> what does this even mean?
15:55:24FromGitter<krux02> @andreaferretti it continues the function where it left of, just then from that point on the arguments are different
15:55:34FromGitter<andreaferretti> I see
15:55:44FromGitter<krux02> it's not hard (for me) to understand. But it is somthing I do not want. Because it's confusing
15:56:14FromGitter<andreaferretti> I find it quite confusing, especially if the argument is not used anymore
15:56:32FromGitter<andreaferretti> it makes sense, but it is weird
15:59:13FromGitter<krux02> And the thing that is bugging me: let's say there is a library that defires two iterators (by default inline) of undefined length (very long), `foo` and `bar`, and your job is it to write an iterator `foobar` that interleaves the values from `foo` and `bar` in a single iterator.
16:00:41FromGitter<krux02> impossible
16:00:47*MJCaley joined #nim
16:04:32FromGitter<RedBeard0531> I think that is isomorphic to implementing the zip iterator
16:06:05*miran_ joined #nim
16:07:32*endragor joined #nim
16:09:27*nsf joined #nim
16:10:19*gokr quit (Quit: Leaving.)
16:11:14miran_ah, it seems i missed the iterator discussion - i agree with what andreaferetti and krux02 have said
16:12:02miran_passing (different) arguments to already started iterator just feels wrong and it is confusing
16:20:08FromGitter<krux02> @RedBeard0531 if you want to try, here is a challenge: http://ix.io/Ekp
16:22:56GitDisc<awr> when compiling with `--cpu:arm` is the resulting binary aarch32 or aarch64?
16:26:54FromGitter<RedBeard0531> @krux02 Last time I thought about it, I came to the conclusion that implementing the zip iterator wasn't possible... at least for me
16:27:42*Trustable joined #nim
16:29:34FromGitter<RedBeard0531> And I think I know how to implement either API given the other, so I think we can term this class of problem ZI-Complete (short for Zip Iterator) :)
16:30:42FromGitter<krux02> I implemented the zip iterator :P http://ix.io/Ekt
16:31:13FromGitter<krux02> it works it just becomes slower and slower
16:32:29FromGitter<krux02> I reastart the iterator foo and bar for each element. Basically making a constant time problem linear
16:32:36*xkapastel joined #nim
16:33:06FromGitter<krux02> and therfore it is zip implemented in O(n²) time
16:33:29PMunchHmm, can you populate an array or seq with an iterator in Nim?
16:33:36FromGitter<krux02> yes
16:33:42FromGitter<krux02> toSeq(...)
16:33:47PMunchOooh
16:34:03PMunchHmm, didn't work..
16:34:20FromGitter<krux02> well the toSeq needs to be outside of the iterator
16:34:29PMunchYeah obviously
16:34:29FromGitter<krux02> toSeq(mystuff.items())
16:34:42FromGitter<krux02> I don't like it a lot
16:34:44PMunchAha, figured it out
16:35:37yglukhovAraq: mind merging please? https://github.com/nim-lang/Nim/pull/7103
16:35:53*federico3 is now known as federico2
16:36:03yglukhovdom96: *
16:37:07*federico2 quit (Quit: WeeChat 1.9)
16:37:39*federico3 joined #nim
16:41:19GitDisc<awr> yeah i noticed the method syntax doesn't work with toSeq()
16:41:20GitDisc<awr> too
16:42:10GitDisc<awr> it's a little annoying
16:43:54*Serenitor joined #nim
16:45:35PMunchCan you unpack a tuple in a for loop?
16:46:07GitDisc<awr> what do you mean
16:46:48PMunchI made a sequence of tuples with the list comprehension from the future module
16:47:17PMunchAnd now I want to loop through all the fields and not have to do pos.x pos.y
16:47:36GitDisc<awr> the only time it seemed that tuple unpacking didn't work is when the variable was `const`
16:47:46GitDisc<awr> i think your tuple unpacking should work
16:47:50FromGitter<RedBeard0531> @krux02 neat, but I don't consider that *solving* the problem any more than a solution calling `toSeq` would be ;)
16:49:08FromGitter<skilchen> @krux02 are you looking for something like that?
16:49:09FromGitter<RedBeard0531> An O(N^N) solution to TSP doesn't solve the NP-Complete class
16:49:09FromGitter<skilchen> https://play.nim-lang.org/?gist=f71e5f9c2305354adf689bd438a26d72
16:49:14GitDisc<awr> a cool thing i noticed about tuple unpacking is, if, for instance, you have a setter set up (i.e. a proc `x=`(a: Position): void)
16:49:20GitDisc<awr> the unpacking will call the setter
16:50:42FromGitter<RedBeard0531> I think the point is to do the whole thing with just inline iterators, no closure iterators nor O(N) temporary storage.
16:51:02*Serenitor quit (Quit: Leaving)
16:51:49*Serenitor joined #nim
16:53:41*Serenitor quit (Client Quit)
16:54:08*Serenitor joined #nim
16:57:21PMunchI tried for i, j in <list of tuples>: and it gave me i as the index and j as the tuple..
16:57:37*Serenitor quit (Client Quit)
16:57:44miran_try: for (i, j) in tuples
16:57:53PMunch Error: identifier expected, but found '('
16:57:58*Serenitor joined #nim
16:58:19FromGitter<RedBeard0531> for i, j in [...].items():
16:58:47PMunchAh, that worked
16:59:37FromGitter<RedBeard0531> it will implicitly call pairs() rather than items() when you have two vars in the for
16:59:45GitDisc<awr> for _, (x, y) in mpairs(blahblah):
17:00:02FromGitter<RedBeard0531> well that's just silly :)
17:00:10GitDisc<awr> lol
17:00:40FromGitter<RedBeard0531> iirc there is also an mitems if that is what you want
17:01:23PMunchAny way to shorten this line: for x, y in lc[ (x,y) | (x <- 0..<width, y <- 0..<height), tuple[x, y:int] ].items():
17:01:36PMunchThat .items on the end is bothering me..
17:01:48GitDisc<awr> every time i've used pairs/mpairs i mix up the order of the index and the element
17:02:03miran_PMunch: well, you can put it in front ;)
17:02:22PMunchThat doesn't really solve anything :P
17:02:31GitDisc<awr> for _, (x, y) in blahblah:?
17:02:34PMunchMakes it look a little better maybe..
17:03:06PMunchawr: Error: identifier expected, but found '('
17:03:33FromGitter<RedBeard0531> for x in 0..<width: for y in x..height: use(x,y)
17:03:34*MJCaley quit (Quit: MJCaley)
17:03:57FromGitter<RedBeard0531> no reason to make a list first when you just want nested for loops
17:04:10PMunchhttps://play.nim-lang.org/?gist=fce0a16123b57a9db27b6e74d4c0e9c2
17:04:12FromGitter<RedBeard0531> should be much faster too
17:05:05PMunchRedBeard0531, yeah I thought about that.. But I kinda wanted to show off that kind of style in Nim as well
17:06:08*gokr joined #nim
17:06:10PMunchHuh RedBeard0531, that doesn't even work
17:06:12PMunchNot on a single line
17:06:17FromGitter<RedBeard0531> Showing off *bad* style is probably a *bad* idea ;)
17:06:26FromGitter<RedBeard0531> https://play.nim-lang.org/?gist=30d5aca1c7a94c9c052e87073081fe3f
17:06:43PMunchWell for this purpose it's not the best fit, but the style of doing list comprehension is still good
17:06:50FromGitter<RedBeard0531> Yeah, a for statement must start on is own line
17:07:25PMunchRedBeard0531, yeah that's what I had originally. But I wanted to shave of a line and show of some list comprehension at the same time :)
17:07:59FromGitter<RedBeard0531> @PMunch, I think that is only true when you need a seq as the output. If you just want to iterate, I think using (inline) iterators is a better idea
17:08:33FromGitter<RedBeard0531> You can't say you saved a line if is is so long that it wraps :)
17:09:21FromGitter<RedBeard0531> Maybe the trick is to implement an ic (iterator comprehension) macro!
17:09:57GitDisc<awr> i think if you really wanted the tuple unpacking you should do what redbeard said initailly and do for x, y in items(blahblah)
17:10:19PMunchThat's why I tried to make it shorter :)
17:12:45PMunchGot the game of life example down to 22 lines, but I feel that there's room for improvement
17:13:05miran_PMunch: show us the code
17:13:28PMunch21 lines now
17:13:33FromGitter<alehander42> can't we have mutiple flyers with various small examples? it would be very hard to demonstrate nim with one example (and this way people can *collect* them :D )
17:13:42dom96awr: pretty sure it's 32 bit arm
17:13:42PMunchhttp://ix.io/EkB/
17:14:05PMunchalehander42, that would actually be really cool
17:14:35PMunchBut probably more expensive to get printed
17:14:49dom96yep, and would take more time to get right :)
17:15:06dom96but do please suggest examples that you feel are print-worthy
17:15:14dom96I'm sure we can integrate them in other places
17:15:16FromGitter<alehander42> I am thinking more like 3-4 examples, not a unique one for each flyer
17:15:37dom96that won't fit on the size of flyer I have in mind
17:15:55FromGitter<alehander42> no, I mean 3-4 kinds of flyers
17:16:15miran_"for x in 0 .. <width:" - isn't the new way of doing this `0 ..< width`?
17:16:41dom96"not a unique one for each flyer" sounds like you're trying to say the opposite
17:16:45federico3Nim's collectible flyers will be worth millions
17:17:28FromGitter<alehander42> :D sorry, I meant, not a different snippet for each different flyer, but e.g. 50 flyers #1 50 flyers #2 etc
17:17:32*endragor quit (Remote host closed the connection)
17:17:56PMunchHaha, alehander42 100 different flyers would indeed be hard to do :P
17:18:06*endragor joined #nim
17:18:09dom96alehander42: ahh, well that's a given
17:18:15PMunchHow many flyers are you planning on making dom96?
17:18:29dom96Dunno, maybe around 500
17:18:34FromGitter<alehander42> you can have some kind of dsl(demonstrating typesafe metaprogramming), game of life, something that demonstrates interop, etc
17:18:36dom96They're not that expensive
17:18:43miran_PMunch: what about "playable area" (x and y) that goes from 1 to width-1? so you don't have that long line 17?
17:18:47GitDisc<awr> how could you compile for aarch64
17:19:10dom96awr: arm64? Check the compiler/platforms (or something like that) sources
17:19:12PMunchmiran_, not quite sure what you mean
17:19:27*yglukhov quit (Remote host closed the connection)
17:19:35miran_ok, let me just modify your code, give me a bit
17:19:51GitDisc<awr> Ah thank you dom96
17:20:01GitDisc<awr> i didn't see on the consts defined by compiler page
17:20:17miran_ah, i cannot just c/p it, it takes also line numbers :(
17:20:43PMunchalehander42, a DSL in such a small snippet might be hard. But I agree that a metaprogramming example would be awesome
17:21:15FromGitter<alehander42> yeah, or even a demonstration of an existing dsl might be cool too
17:21:36PMunchAnd interop would require them to have the thing you're interoping with installed or downloaded if they want to try it
17:21:44PMunchBut that would be cool as well :)
17:21:49dom96alehander42: problem with those ideas is that they are very abstract
17:22:39*endragor quit (Ping timeout: 248 seconds)
17:22:44miran_PMunch: https://gist.github.com/anonymous/b1400bbe5c82459b6984c0f1dd7cd30c
17:23:01miran_see lines 12, 13, and 17
17:23:45miran_but you need to make sure that the border (first and last row and column) are always off
17:23:58miran_always = at the start
17:25:33PMunchhttp://ix.io/EkC/
17:25:40PMunchYeah, that does indeed make the code a bit cleaner
17:25:50FromGitter<alehander42> well I don't think anyone will type the examples by hand, the point is to demonstrate cool/unique aspects of the language, and the current game of life example doesn't contain any of them (type system, metaprogramming, interop, etc)
17:25:53PMunchBut now the simulation doesn't wrap
17:26:11PMunchBut I guess that's a decent tradeof for an example
17:26:28FromGitter<alehander42> it would look very similar in many other languages
17:26:50dom96IMO we should include a command below the code like:
17:27:03PMunchI guess you could do a [...]<code>[...] approach and have a "see full example at: <url>"
17:27:20dom96curl https://bit.ly/bqhasu > life.nim && nim c -r life.nim
17:27:27PMunchIt would be nice to host the snippets somewhere anyways, for those who don't want to type them down
17:27:55PMunchYeah, that's another way to do it. Shows both the link and the command to actually run it
17:28:08PMunchDownside with my game of life example is that it requires drawille
17:28:46FromGitter<alehander42> that's the thing I worry about, if I am e.g. a visitor and I get this flyer, I wouldn't really see how this is different than most other languages I use
17:28:54PMunchSo it would be "wget nim-lang.org/life.nim && nimble install drawille && nim c -r life.nim"
17:29:38dom96ugh, ix.io code can't be copied without the line numbers
17:29:53PMunchYes it can, just remove the trailing / in the url
17:30:03PMunchThen it shows the paste without line-numbers
17:30:07FromGitter<mratsim> Just show NimES :P
17:30:20*sendell quit (Remote host closed the connection)
17:30:26dom96ahh, nice
17:30:33dom96Using drawille definitely has its advantages
17:30:34miran_PMunch: nice hack, will save some retyping in the future
17:30:49Araqwell the problem lends to some nice array DSL
17:31:03shodan45dom96: apparently I'm getting your book for my birthday! woohoo!
17:31:17FromGitter<mratsim> Array DSL, did someone call me? :P
17:31:23Araqand if we include the command to install&run using a library is not a problem
17:31:27dom96shodan45: ooh, awesome :D
17:31:37Araqmratsim: I guess... :-)
17:31:50dom96Araq: Yeah, but we shouldn't cheat too much :P
17:32:07Araqimport gameoflife
17:32:14PMunchrun()
17:32:21Araqyup, 2 lines
17:32:24dom96# Nim. It's that easy.
17:32:39FromGitter<mratsim> Get away you sales guy
17:32:44AraqGolang gets away with it :P
17:32:53dom96lol?
17:32:55dom96where?
17:33:09Araq"write a HTTP server in 3 lines"
17:33:14PMunchI'm still concerned about size though. When I was playing around with the flyer with dom96 I realized how little text you could actually fit on it :P
17:33:16Araqdom96: don't recall where I saw it
17:33:36dom96yeah, maybe we should check how much space we actually realistically have
17:33:48Araqbut all the Go examples are like that because Go is mega unexpressive
17:33:50dom96if all else fails though I can always get a larger flyer printed
17:34:32dom96yeah, so we should do better
17:34:40dom96showing off nimble with one package would be nice too
17:34:51dom96an additional risk too though
17:35:01dom96and also, does drawille support windows? :)
17:35:19PMunchDunno, I don't have a Windows machine so I can't really test it..
17:35:40PMunchBut if the Windows terminal supports UTF-8 I don't see why it shouldn't work..
17:35:55PMunchThe colour stuff is probably not gonna work though
17:35:59dom96are you using the terminal module in drawille?
17:36:12PMunchNo
17:36:40PMunchI didn't realise it had colours until today..
17:37:53dom96are you using any other escapes to draw at specific coordinates?
17:38:07Araqmratsim: so ... how can we use your DSL for GoL?
17:38:17PMunchdom96, nope
17:38:26FromGitter<mratsim> dunno, have to read GoL code
17:38:30PMunchDrawille just has a $ proc for it's canvas which returns a string
17:38:50dom96oh, cool
17:38:52PMunchSo you do "stdout.write(canvas)" to "draw" the screen
17:39:07dom96but then that really fills up the terminal buffer lol
17:39:32PMunchWell that's why you want to clear your terminal between each draw
17:39:57dom96yeah, you can use eraseScreen for that
17:40:01dom96but that's another line :)
17:40:19PMunchYup, but it was super flickery on my machine though
17:40:26PMunchDidn't appear to clear it properly
17:40:44PMunchI've used to print some control character for that in my drawille example
17:41:00PMunchWhich didn't flicker but relied on knowing the height of the screen
17:41:03dom96you probably need to stdout.setScreenPos(0, 0)
17:41:19PMunchHmm, that's even another line :P
17:41:43dom96IMO drawille should do this :P
17:42:03PMunchWell I wanted to make it more portable
17:42:21PMunchIf you wanted to implement a UI over telnet for example
17:42:26*gokr quit (Quit: Leaving.)
17:42:32PMunchOr some other random task
17:43:37dom96that's something the terminal module should support I guess
17:44:32PMunchOh well, I'm off now. Probably be back on in not too long
17:47:27*PMunch quit (Quit: Leaving)
17:51:49*natrys quit (Quit: natrys)
17:52:17GitDisc<awr> @ pmunch if you're using your game of life example to show off nim
17:52:25GitDisc<awr> you could use gorge() to install drawille maybe
17:55:02GitDisc<awr> i'm dumb
17:55:25GitDisc<awr> wouldn't work, because drawille needs to be imported
17:58:27*floppydh quit (Quit: WeeChat 2.0.1)
18:03:13*devdri joined #nim
18:06:37*UxerUospr joined #nim
18:09:18*Arrrr joined #nim
18:21:54*yglukhov joined #nim
18:22:29*nsf quit (Quit: WeeChat 2.0.1)
18:26:35*yglukhov quit (Ping timeout: 268 seconds)
18:30:35*yglukhov joined #nim
18:32:11*miran_ quit (Remote host closed the connection)
18:32:32*sz0 quit (Quit: Connection closed for inactivity)
18:33:14dom96turns out eraseScreen doesn't really erase it...
18:33:44*devdri quit ()
18:35:39*Jesin joined #nim
18:47:38*Trustable quit (Remote host closed the connection)
18:48:04*devdri joined #nim
18:50:13*federico3 quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
18:50:40*federico3 joined #nim
18:50:56*federico3 quit (Client Quit)
18:51:09*federico3 joined #nim
18:53:32*federico2 joined #nim
19:00:22*fredrik92 joined #nim
19:01:29*federico2 quit (Quit: WeeChat 1.9)
19:16:04*federico2 joined #nim
19:16:05*federico2 quit (Client Quit)
19:16:12*yglukhov quit (Remote host closed the connection)
19:25:01*Jesin quit (Quit: Leaving)
19:25:37*Serenitor quit (Quit: Leaving)
19:30:36*gokr joined #nim
19:31:42*Jesin joined #nim
19:47:23*xet7 quit (Ping timeout: 256 seconds)
19:56:51*Ven` joined #nim
20:00:26*xet7 joined #nim
20:03:27*yglukhov joined #nim
20:05:10*yglukhov quit (Read error: Connection reset by peer)
20:05:48*yglukhov joined #nim
20:12:20*Ven` quit (Read error: Connection reset by peer)
20:12:54*Ven` joined #nim
20:18:12*Arrrr quit (Ping timeout: 268 seconds)
20:22:51*Serenitor joined #nim
20:37:56*gokr quit (Ping timeout: 268 seconds)
20:49:42*Yardanico quit (Read error: Connection reset by peer)
21:13:41*UxerUospr quit (Quit: Lost terminal)
21:14:17*Ven` quit (Ping timeout: 256 seconds)
21:15:54*Ven` joined #nim
21:18:47*Vladar quit (Quit: Leaving)
21:20:05*Amrykid joined #nim
21:20:11*yglukhov quit (Remote host closed the connection)
21:24:07*yglukhov joined #nim
21:24:10*yglukhov quit (Remote host closed the connection)
21:30:52*gokr joined #nim
21:51:57*devdri quit ()
21:52:51*yglukhov joined #nim
21:57:17*yglukhov quit (Remote host closed the connection)
21:59:43*nsf joined #nim
22:19:17*nsf quit (Quit: WeeChat 2.0.1)
22:23:28*vlad1777d joined #nim
22:30:06*devdri joined #nim
22:40:43*yglukhov joined #nim
22:53:03*fvs joined #nim
23:05:41*NimBot joined #nim
23:22:55*Sentreen quit (Quit: WeeChat 1.6)
23:24:44*Sentreen joined #nim
23:43:02*Amrykid quit (Ping timeout: 255 seconds)
23:43:16*Ven` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:45:11*MJCaley joined #nim
23:46:45*Serenitor quit (Quit: Leaving)
23:57:01*fvs left #nim ("ERC (IRC client for Emacs 25.3.1)")