<< 27-02-2018 >>
00:04:17FromGitter<zacharycarter> @mratsim you asked me a while ago if I used Nim in my hackathon project... I didn't :( I am so new to machine learning, I would have no idea how to utilize anything other than a library pre-built for ML :P
00:04:35FromGitter<zacharycarter> Plus I was trying to do all of this on a macbook pro, so I used https://github.com/apple/turicreate
00:04:50FromGitter<zacharycarter> which actually worked really well for my purposes - although I didn't win... so maybe not.
00:08:24*francisl quit (Ping timeout: 260 seconds)
00:21:09*koranza quit (Remote host closed the connection)
00:25:05*smt quit (Ping timeout: 248 seconds)
00:26:39*Jesin joined #nim
00:57:07*BitPuffin quit (Remote host closed the connection)
03:27:17*endragor joined #nim
03:28:51*vlad1777d_ quit (Ping timeout: 252 seconds)
03:37:12*dddddd quit (Remote host closed the connection)
03:46:27*endragor quit (Remote host closed the connection)
03:49:26*xkapastel quit (Quit: Connection closed for inactivity)
03:50:12*endragor joined #nim
04:00:03*NimBot joined #nim
04:02:59*d10n-work quit (Quit: Connection closed for inactivity)
04:07:27*SenasOzys quit (Ping timeout: 240 seconds)
04:26:47*endragor quit (Remote host closed the connection)
04:28:01*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
04:30:16*endragor joined #nim
04:56:42*r3d9u11 joined #nim
05:21:46FromGitter<k0pernicus> Maybe it can be interesting for Nimble to create a « smart » README.markdown file (if no one already exists in the root directory), no? ⏎ A sort of template to explain how to build/install the lib/binary, a short description, the license, etc… ⏎ Just an « easy-way-to-push » for Github/Gitlab users
05:54:58*endragor quit (Remote host closed the connection)
06:08:39*nsf joined #nim
06:20:15*r3d9u11 quit (Remote host closed the connection)
06:32:20*endragor joined #nim
06:51:57*donotturnoff joined #nim
06:52:08*donotturnoff quit (Remote host closed the connection)
06:55:06FromGitter<survivorm> About Nimble, how about dedicating some server for continuous builds of nimble packages against stable/devel/head each time as any (nim dev/stable/head or package itself) changes? And letting nimble know last build statuses?
06:55:45FromGitter<survivorm> @Yardanico
06:57:02FromGitter<survivorm> That may help with the version check process, also may lead to "builds with <version>" tags at package
06:58:01FromGitter<survivorm> Will immensely help in putting nim projects into production, making things more clear from all points of view
06:59:24FromGitter<survivorm> (Imagine - you may see that some codebase works with nim <versions ....> not because developer said it is, but because it was also tested automatically
06:59:57FromGitter<survivorm> And the second tag may be of cause - tests pass
07:00:51FromGitter<survivorm> like <versions ...> build passes, tests passes, <versions ...> build passes
07:07:06GitDisc<treeform> survivorm, i actually wanted to try some thing like this but first thing I run into is missing dlls.
07:07:30GitDisc<treeform> i wish library writers would include the dlls they used.
07:08:55GitDisc<treeform> on mac and linux the .so files are easier to come by through brew and apt-get but on windows it appears much harder
07:09:18GitDisc<treeform> but even on mac and linux the libraries don't tell were the .so files should come from.
07:09:25GitDisc<treeform> or which versions they work with
07:09:38GitDisc<treeform> for me that appears to be the biggest bottle neck in reproducing builds
07:10:29GitDisc<treeform> i should they would just include them for mac, linux, windows 32 and windows 64
07:11:16GitDisc<treeform> i wish they would just include them for mac, linux, windows 32 and windows 64
07:17:33*el_tejon joined #nim
07:28:16FromGitter<mratsim> @zacharycarter I didn't know about Turi create, it's nice!
07:28:30*PMunch joined #nim
07:29:46FromGitter<survivorm> @treeform I think it's another chicken-egg, but much simpler
07:30:53FromGitter<mratsim> @treeform I would say every project should have an "installation" section in the readme. Also Travis/Appveyor config help to see what is needed. For package manager on Windows there is nuget and chocolate, not sure how many libraries are in there though.
07:31:09FromGitter<survivorm> If the continuous build system exist and people know of it, AND it produce accurate error messages to maintainer, people will try their packages agains it
07:31:45FromGitter<survivorm> And, eventually, they'll fix dependancies
07:32:28GitDisc<treeform> nuge .net only (does not work for nim) and chocolate is ok, but its not brew or apt-get which are a lot better.
07:32:34FromGitter<survivorm> not everyone, mind you. But we're talking of developing projects, not abandoned
07:32:58GitDisc<treeform> nuget .net only (does not work for nim) and chocolate is ok, but its not brew or apt-get which are a lot better.
07:33:08GitDisc<treeform> nuget is .net only (does not work for nim) and chocolate is ok, but its not brew or apt-get which are a lot better.
07:33:35FromGitter<mratsim> @survivorm auto testing should be done by the author
07:33:50FromGitter<survivorm> And, of cause, more platforms to build against is better, but its costly
07:34:03GitDisc<treeform> computers are cheap, dev time is pricy
07:34:49FromGitter<survivorm> @mratsim Tests should be written by devs, yes. But autobuild system should include tests, why should it not?
07:35:31GitDisc<treeform> I agree with survivorm, I even wanted to build some thing like this.
07:35:35FromGitter<mratsim> But reporting the result to a central location might be good
07:35:46FromGitter<survivorm> @treeform Computers are Cheaper, yes. But dedicated servers, working full-time - i'm not sure
07:35:47GitDisc<treeform> I think many devs use mac or linux but forget about windows
07:35:54GitDisc<treeform> and everyone forgets about win32
07:36:03FromGitter<survivorm> Yeah
07:36:36FromGitter<survivorm> And that autobuild system may become great businnes opportunity for nim
07:36:57GitDisc<treeform> i doubt about businnes opportunity...
07:37:00FromGitter<survivorm> If ecosystem is PREDICTABLE, risks are mush smaller
07:37:27GitDisc<treeform> Who builds and maintains this thing: https://nimble.directory/
07:37:30FromGitter<survivorm> But, of cause, it's not the only barrier
07:38:06GitDisc<treeform> https://github.com/FedericoCeratto/nim-package-directory
07:38:15GitDisc<treeform> it looks like he does a ton of stuff already
07:38:24GitDisc<treeform> Build and serve pkg docs
07:39:10FromGitter<survivorm> So, the continuous builds will be great addition
07:39:42FromGitter<survivorm> But, as with every good idea, someone need to make it work
07:39:58FromGitter<survivorm> even if as a prototype
07:40:14FromGitter<survivorm> then it may become community-driven
07:55:53*rokups joined #nim
08:02:30*Arrrr joined #nim
08:10:43*el_tejon quit (Quit: el_tejon)
08:13:59Araqnimble tries to play nice with OS package managers
08:14:10Araqso ideally a nimble package should say
08:14:24Araq"to finish the installation, run 'sudo apt-get foobar'"
08:14:50Araqwe spent quite some effort in distros.nim to support this
08:14:57Araqpeople need to use the feature
08:24:25livcdpackage managers :(
08:24:48FromGitter<survivorm> First of all, i think people need to KNOW of it :) No offence. People are lazy, so if they're not reminded of something they tend to forget it
08:26:07FromGitter<survivorm> So if autobuid brakes because of something maintainers didn't supply and it's written in bright red in the last build's log details, people will surely remember :)
08:31:03*yglukhov joined #nim
08:31:17livcdpackagae managers often break if you do not use them regularly
08:32:07livcdyou have not done brew update && upgrade in a week ? Phuck you now you need to do this and this and this and wait for this other shit to compile for 50 minutes.
08:32:42FromGitter<survivorm> You're overrating this
08:33:28FromGitter<survivorm> E.g. in arch I don't upgrade for a month sometimes. And nothing bad happens
08:33:49FromGitter<survivorm> But, surely, problem exists
08:34:15FromGitter<survivorm> in particular, with cross-dependencies
08:34:48livcdI do not know about arch. Happens to me all the time with apt and brew
08:35:32FromGitter<survivorm> That's why i've gone from ubuntu
08:36:24FromGitter<survivorm> unstability in everyday tasks are a pain in the ass which you can tolerate only so far
08:36:55AraqI still don't believe in versioning :-)
08:37:29FromGitter<survivorm> But the point of my talk is not 'build everythere', it's more 'predictability'
08:37:33Araqit's just some number, to update, update and hope you have enough tests
08:37:45Araqif you don't, don't update :-)
08:37:59Araqbugfixes can break things too.
08:38:00livcdI prefer working instead of latest and greatest
08:38:34FromGitter<survivorm> So that you would know that in the environment 'A-...B' project is supposed to work
08:38:34livcdPeople like latest because it often fixed the issues they had. But it's like a bandaid to a bigger problem
08:39:06Araqsurvivorm: I've argued about this before, it's an intractable problem
08:39:41Araqlibrary A works with B versions 1..4, B works with C versions 1..4, C with D versions 1..4
08:39:58livcdeww
08:40:08Araqlibrary A needs to test a configuration space with 4*4*4 instances
08:40:36Araqintractable, so instead you pin your dependencies
08:40:58FromGitter<survivorm> Of cause, 100% sure is a myth. But if you're at least 90% sure, that A works with B, C, D(version numbers), then that'll work
08:41:17Araqprobabilities multiply too
08:41:23FromGitter<survivorm> @Araq that's what virtual environments are made for
08:41:38Araq90% ^ n is not a good chance of having something that works
08:42:01FromGitter<survivorm> Of cause you're not to put all the dependencies at one place
08:42:13FromGitter<survivorm> and of cause they'll conflict
08:42:31FromGitter<survivorm> @Araq I mean 90% net
08:42:35Araqyou can't argue against math :P
08:42:40FromGitter<survivorm> Not for each member
08:43:08Araqin Nim's case, most regressions are due to bugfixes.
08:43:22FromGitter<survivorm> Or every little thing in the world would brake, by your logic
08:43:39AraqMurphy's law :P
08:44:12FromGitter<survivorm> Murphy's law is only a special case :)
08:44:28FromGitter<survivorm> Worst case scenario
08:44:54FromGitter<survivorm> It happens, yes, but not as often as it's advertised
08:45:13Araqwell in practice I have a ~50% chance my brew command works
08:45:21FromGitter<survivorm> It's just more rememberable :D
08:45:35FromGitter<survivorm> Poor soul :)
08:45:52FromGitter<survivorm> I rarely see my pacman command fails :P
08:46:24FromGitter<survivorm> That's more about quality of testing
08:47:04FromGitter<survivorm> But that's not the point
08:47:04Araqyou need to test a combinatorial explosion
08:47:13Araqthat is the point.
08:47:37Araqyou will never get "quality" into this, IMO
08:47:49Araqonly "good enough" ;-)
08:48:51FromGitter<survivorm> IIRC, Joel Spolsky said about little barriers for people. Barrier may seem small, but if you remove it, you may be surprised about how many new people will come through
08:49:22FromGitter<survivorm> And if you'll remove as many as you can, well...
08:49:51FromGitter<survivorm> that's the maths you like, @Araq
08:50:21FromGitter<survivorm> each barrier cuts a percent of otherwise interested people
08:51:30Araqyes, but a package manager that fails can be a bigger barrier than a configure script that I can hack into a working state
08:52:04Araqand there is little than I dislike more than configure scripts :-)
08:52:37FromGitter<survivorm> And why should it fail?
08:52:57FromGitter<survivorm> 'Cause of version conflict?
08:53:05Araqfor example.
08:53:26Araqor a download fails.
08:53:48Araqor the package manager puts stuff into the wrong wrong directory
08:53:52FromGitter<survivorm> And just what can you do about failing download?
08:54:23FromGitter<survivorm> Version conflicts lead to virtual environments
08:54:28Araqor the package manager has a misguided notion of a "transaction" and rolls back useful work
08:55:04FromGitter<survivorm> I live with python's virtual env's for years. And almost no problems seen
08:56:05FromGitter<survivorm> Why our discussion drifted to PM's? I was talking on continuous build system
08:56:08FromGitter<survivorm> ?
08:56:45Araqwere you? sorry
08:57:20FromGitter<survivorm> And, just btw, wrong paths are easily fixed by virtualenvs too
08:57:38livcdpackage managers fail all the time
08:57:46livcd(c) statistics pulled out of my ass
08:58:18FromGitter<survivorm> I was talking about idea of testing every nimble package then nim/or package is changed
08:58:43FromGitter<survivorm> And displaying test results somethere centralized
08:58:49FromGitter<survivorm> That's all
09:00:17FromGitter<mratsim> I hate Python’s virtualenv … I have to maintain one for Datascience on Python3, one on Python2 because university still didn’t get rid of it, one for blockchain … spare me already … reproducible builds? tough luck ….
09:01:40livcdbrew is like the least likely to break and it still breaks if I do not use it frequently. At least it displays what it wants from you. Unless it does not and then you spend time with shit
09:04:24FromGitter<survivorm> @mratsim Any other idea? To maintain or not several versions is developer's choice, it's more about the ability to know if something fails
09:04:49FromGitter<survivorm> It would fail anyway! Just being concealed
09:06:03FromGitter<survivorm> Would you think it's better to invest time and money into some project relying on some software and eventually find out that your dependencies do not build?
09:06:32FromGitter<survivorm> Better be aware of it earlier
09:12:32*Arrrr quit (Ping timeout: 276 seconds)
09:13:17Araq"it would fail anyway"
09:13:31Araqas a programmer I can fix broken compilations
09:13:39Araqbut I don't want to deal with
09:13:57Araq"dep A requires B version 1.0, dep C requires B version 2.0"
09:14:32Araqthere are different "failure modes"
09:15:00Araqand the package manager is usually the least helpful at the topmost layer
09:15:26FromGitter<andreaferretti> @survivorm I agree that having a CI server continuosly build and test nimble packages would be tremendously useful
09:15:38FromGitter<andreaferretti> I tried to suggest this idea for a while
09:15:52*Arrrr joined #nim
09:15:52*Arrrr quit (Changing host)
09:15:52*Arrrr joined #nim
09:15:53FromGitter<andreaferretti> but in the end nothing come out of it
09:16:01AraqI like the idea too. somebody needs to *do* it though.
09:16:21FromGitter<mratsim> Would Digital Ocean sponsorship covers that?
09:16:28FromGitter<mratsim> cover*
09:16:41FromGitter<andreaferretti> the simplest way would be to open the CI servers to (a limited vetted set of) external developers
09:16:50Araqwe can deploy any service we want to, I think
09:16:54FromGitter<andreaferretti> and create a template for a nimble project
09:16:58Araqnot sure if we have CPU limitations
09:17:25FromGitter<andreaferretti> then developers could create jobs to test their own packages
09:17:33FromGitter<andreaferretti> this is open to abuse
09:17:57FromGitter<andreaferretti> but I think it could be tried with at least a few people
09:20:27*Vladar joined #nim
09:24:52*SenasOzys joined #nim
09:27:36FromGitter<survivorm> @andreaferretti i think it's great idea. But my idea was something other than that - automatically detect changes and re-build and re-test every affected nimble package on it
09:27:56FromGitter<survivorm> After a while - add platform-specific builds
09:28:28FromGitter<survivorm> I bet more than 50% packages will be "yellow" status at best
09:29:17*dddddd joined #nim
09:29:31FromGitter<survivorm> meaning red - not builds or all tests fail, yellow - some tests fail and green - all clean
09:30:25FromGitter<survivorm> Nim's virtue is that that operations may be done relatively fast
09:31:32FromGitter<survivorm> I don't know any other language which have a possibility to cover it's full ecosystem with automatical CI. Even if theoretically
09:32:44FromGitter<survivorm> And then, we may add "with predictable ecosystem" to Nim's slogan :)
09:33:24Araqit's very predictable already.
09:33:49AraqI always have to patch what I need to use.
09:33:55Araq:-)
09:34:36Araqmy favourite are "assumes Unix environment" packages
09:34:42FromGitter<survivorm> You sound like a friend of mine
09:36:31FromGitter<survivorm> He was used to say - What do you not like about my program? It's almost working, you only need to fix a small thing there <he dives into program and fixes a single (or 2-3-5) line of code. Program works>
09:37:34FromGitter<survivorm> He was genuinely surprised, why so much people where eager to hang him on the nearest tree :D
09:38:15*yglukhov quit (Remote host closed the connection)
09:38:26FromGitter<andreaferretti> I confess I never tried my packages on windows :-)
09:38:47FromGitter<andreaferretti> on the other hand, some of them requires unix-specific libs
09:39:21FromGitter<andreaferretti> while others only use platform specific features via the nim stdlib, so in theory they should work on windows
09:39:26FromGitter<andreaferretti> at least, I hope so :-P
09:40:30FromGitter<andreaferretti> I settled for a bash script that I run daily after updating nim that tells me if any test fails
09:41:13livcdWhy not nimscript?!
09:41:14FromGitter<survivorm> That's the point of CI, exactly :)
09:41:50FromGitter<andreaferretti> @livcd no particular reason, it was just a few lines of bash, I didn't overthink it
09:42:40livcdWhenever I see bash I puke a little in my mouth
09:43:11FromGitter<andreaferretti> yeah I agree
09:43:22FromGitter<andreaferretti> but it's just a loop that calls nimble test
09:43:39FromGitter<survivorm> @andreaferretti But the problem stands, @Araq is right. Somebody need to write a CI environment to make it work
09:44:11FromGitter<andreaferretti> there is a CI environment to test nim itself
09:44:15*arecacea1 quit (Remote host closed the connection)
09:44:23FromGitter<andreaferretti> I was suggesting to use that
09:44:37*arecacea1 joined #nim
09:44:47*yglukhov joined #nim
09:44:56FromGitter<survivorm> does it support virtualenvs?
09:45:36FromGitter<survivorm> Because if not than it would benefit noone with dependencies
09:45:58FromGitter<andreaferretti> well, nim dependencies are alreay isolated by nimble
09:46:10FromGitter<andreaferretti> for native dependencies, yeah there is a problem
09:46:32FromGitter<andreaferretti> but there are mantained docker images, those could be autogenerated and used
09:47:13FromGitter<survivorm> abot 700 docker-containers? I think it'll be an overkill
09:47:43FromGitter<survivorm> And each will need to be re-tested at each nim update
09:47:48*smt joined #nim
09:48:02Araqall we need is a github hook that triggers a rebuild of github.com/nim-lovers.git
09:48:18FromGitter<survivorm> and docker itself brings it's own 'perks'
09:48:38Araqand nim-lovers is just a github repo that is registered at appveyor and travis
09:49:18Araqand sends me an email when stuff breaks
09:49:39FromGitter<survivorm> @Araq you'll drown
09:49:44FromGitter<survivorm> in letters
09:49:48Araqhuh?
09:50:01Araqno, only selected packages are tested
09:50:12FromGitter<survivorm> Ah, i see
09:50:20Araqpeople can create PRs to nim-lovers
09:50:24federico3andreaferretti: this is what nimble.directory has been doing - given the limited hardware it's testing pkg install and "nim doc" but not running tests
09:50:26Araqif they want to add their packages for testing
09:50:40FromGitter<survivorm> but still, i think letters should come to project's maintainers
09:50:56Araqwell the point is to detect compiler regressions
09:51:11Araqso the Nim core devs should take action
09:51:40FromGitter<survivorm> No, no, i think we have a misunderstanding there, @Araq
09:51:52Araqwe can do that already with nim-lang but the tests run for too long already
09:53:02federico3I also did pkg installs against Nim devel on ci.nim-lang.org but there was no interest in it
09:53:08FromGitter<survivorm> My point is that the projects shoud have the 'builds for ver ...' and 'tests pass for ver... ' badges, access to the last build's logs
09:53:54FromGitter<survivorm> @FedericoCeratto I think it's problem of marketting, most of all
09:54:09FromGitter<survivorm> If you have it already, it's great
09:54:11FromGitter<andreaferretti> @federico3 I have been saying this lots of time
09:54:19FromGitter<andreaferretti> doing nimble install is not useful at all
09:54:34federico3survivorm: https://nimble.directory/pkg/jester the badges on the right side do that
09:54:34FromGitter<survivorm> We just need it's proper display
09:54:43FromGitter<andreaferretti> for instance, for all of my 12 or so packages
09:54:53Araqfederico3, I had interest but the problems I looked at were 90% nimble configuration problems
09:54:57FromGitter<andreaferretti> nimble install will just clone the repo and copy files
09:55:09federico3andreaferretti: "nim doc" is being run as well. I'd be more than happy to run tests if hardware was available
09:55:18FromGitter<andreaferretti> all failures I saw were just git failing due to network issues
09:55:32Araq"nim doc" doesn't really compile stuff
09:55:40Araqah yeah, that too, andreaferretti
09:55:54FromGitter<andreaferretti> we need a way to actually run tests
09:56:24FromGitter<andreaferretti> I don't really want to sound negative but without doing that it's all wasted effort
09:57:34FromGitter<survivorm> @federico3 it's great. It just needs tests, and a list of "works against version"
09:57:47federico3I'm aware "nim doc" is not running tests. (Yet I saw install and builds failing and helped me so far)
09:58:08FromGitter<survivorm> And be a little more visible, in a way of UI
09:58:37federico3survivorm: I did experiments with running tests for many pkg against both Nim devel and released on CircleCI. One host is just too slow
09:58:46FromGitter<survivorm> I've not stumbled upon it untill i've looked for them in special
09:59:08federico3I accept PRs and buildbots
09:59:35FromGitter<survivorm> @federico3 That may be the problem @Araq may probably help with
10:00:05FromGitter<survivorm> (one host problem, i mean)
10:00:13Araqactually dom96 is our infrastructure man
10:00:40federico3I pinged dom96 few times in the past - the build infrastucture is not being resurrected so far
10:00:46FromGitter<survivorm> Than that's him ^)
10:01:00Araqthat said, unless it sends me an email, it doesn't exist
10:01:00*yglukhov quit (Remote host closed the connection)
10:01:25FromGitter<survivorm> An email on what, exactly?
10:01:46FromGitter<survivorm> In what case?
10:02:16federico3rebuilding all/many pkgs on every commit against Nim and spotting regressions
10:02:30FromGitter<survivorm> I think if something didn't build before, and not builds with the new nim, it shouldn't ne the case
10:03:26FromGitter<survivorm> But yes, if something did build and now it's not - that MAY be it
10:04:27AraqI've argued for this before but this "diff" technology is out of reach, so we start with all-green projects and keep them green
10:04:38FromGitter<survivorm> And the aggregation still stands, or @Araq will drown, as i've said before. If he'll get a 200 letters each time something goes wrong...
10:05:10federico3Araq: out of reach?
10:05:25FromGitter<survivorm> @Araq just why? It's not so hard?
10:06:08Araqdunno, people in #nim couldn't imagine it back then
10:06:18FromGitter<survivorm> Just keep a package -> version -> nim version -> build state in some external store fo CI
10:06:36FromGitter<survivorm> And a little logic on it
10:07:20FromGitter<survivorm> It not so much data, even for 700 packages :)
10:07:27Araqanyway, I won't drown in emails, I will get a single one that says "now packages X, Y fail"
10:07:53FromGitter<survivorm> As i've said - aggregation
10:08:08Araqthat's what travis and appveyor do out of the box
10:09:36federico3survivorm: I already have this simple logic implemented actually
10:10:18FromGitter<survivorm> That means we think similarly on some topics :)
10:10:57FromGitter<survivorm> And that's great, of cause
10:11:18FromGitter<survivorm> The thing remaining is mailing?
10:11:41federico3the big blocker is hardware...
10:12:03FromGitter<survivorm> let's ping @dom96
10:12:19FromGitter<survivorm> May be he have a say in that
10:12:35Araqwhat would it take to run a builder?
10:12:49FromGitter<survivorm> If many people will vouch for it, it's more likely to happen
10:12:50*jaco60 joined #nim
10:13:40federico3Araq: in terms of CPU power?
10:13:48Araqno, required software
10:14:55federico3not much really
10:16:20AraqPython based buildbot?
10:16:46Araqwhy did we abandon nimbuild :-/ was my favourite
10:17:27federico3both nimble.directory and nim-ci have code to update and build Nim and install and tests pkgs
10:18:13federico3something to trigger remote builds and report outputs would be quite simple
10:25:53*Pisuke quit (Ping timeout: 240 seconds)
10:25:55*Sembei joined #nim
10:46:09*floppydh joined #nim
11:06:57FromGitter<alehander42> I think that's unfeasible for *all* nimble libs
11:07:18FromGitter<alehander42> but it might be feasible for e.g. top <N> nimble libs on a small set of platforms
11:07:38FromGitter<alehander42> (I don't know if there are any stats in nimble on downloads etc, that would be useful)
11:17:15dom96The problem is that most nimble packages don't have tests
11:17:35FromGitter<andreaferretti> is that true?
11:17:39dom96I suppose compiling all .nim files is good enough though
11:18:08FromGitter<andreaferretti> most libs i have seen have some kind of test
11:18:20FromGitter<andreaferretti> even if it's just some asserts behind when isMainModule
11:18:37dom96They don't have "proper" tests
11:18:42dom96ones that work via 'nimble test'
11:18:46FromGitter<andreaferretti> The problem is that *how* to test depends from library to library
11:18:50federico3it's still a lot of material to test
11:19:19FromGitter<andreaferretti> hence I think it makes sense to *not* do this automatically
11:19:28FromGitter<andreaferretti> require authors to submit a package for CI
11:19:31dom96Doing it once a day or even once a week shouldn't be a problem
11:19:33FromGitter<andreaferretti> whereby they specify
11:19:38FromGitter<andreaferretti> 1) how to run tests
11:19:48FromGitter<andreaferretti> 1) who to mail when something goes wrong
11:20:02dom96we already have a standardised way to run tests
11:20:07dom96packages just need to fall in line :P
11:20:09federico3andreaferretti: this *was* using CircleCI to do that: https://github.com/FedericoCeratto/nim-ci
11:20:53federico3dom96: the standardised way does not define what kind of tests can be run. "nimble test" could run integration tests
11:22:59FromGitter<andreaferretti> @federico3 I don't understand what do you mean
11:23:18FromGitter<andreaferretti> Do you mean that that project was requiring package authors to register?
11:28:16federico3no, it was doing automated builds against Devel but on CircleCi
11:29:10dom96federico3: yeah, I should probably clarify that in the readme
11:29:23federico3but a free CI env is way too limiting for this use case
11:29:36Yardanicofederico3, we can use multiple CIs at the same time :D
11:29:56YardanicoE.g. travis, circleci, semaphoreci (latter is faster than others btw) :P
11:31:57federico3Yardanico: maintaining that is very time consuming and you cannot safely run tests for 3rd partiy library - hence nimble.directory runs on dedicated hw
11:32:07Yardanicowell I know that :(
11:33:23federico3dom96: any hope to resurrect the buildbots? Testing against multiple OSes would be a nice added benefit
11:35:09*natrys joined #nim
11:37:22dom96which build bots?
11:37:35*vlad1777d_ joined #nim
11:37:39dom96brb
11:41:28Yardanicodom96, nim buildbots? :)
11:52:30dom96again, which ones
11:52:39dom96We had many different implementations
11:52:49Araqnimbuild
11:53:33*tongir quit (Ping timeout: 240 seconds)
11:53:38dom96I was considering reviving Nimbuild as a commercial project
11:54:04Araqcommercial? why? what's its selling point?
11:56:42Araqnimbuild still compiles btw
11:56:51Araqwell I had to make 3 changes to builder.nim
11:57:08Araqbut then it compiles with tons of deprecation warnings :-)
11:58:05*vlad1777d_ quit (Ping timeout: 240 seconds)
12:00:04dom96I have some ideas :P
12:00:39dom96if there is no selling point then why don't you use the python buildbot? :P
12:01:12Araqbecause I'm egocentric
12:02:25federico3dom96: any other build system would do as long as we have some hw (possibly with different OSes) to run tests.
12:02:48*Snircle joined #nim
12:03:42dom96we've got the GCC build farm at our disposal, but I don't think we can abuse it for this
12:05:45Yardanicodom96, wow, I didn't know about this D:
12:05:50Yardanico:D how did that happen?
12:06:48dom96You can just request access
12:06:58dom96and they give it to FOSS projects
12:07:42Yardanicowait, so it can be used like a usual CI service?
12:08:22dom96you get ssh access to the machines
12:08:56*SenasOzys quit (Ping timeout: 268 seconds)
12:12:32federico3I also have access to the Debian build fleet with few more architectures but it's not meant for our use case
12:16:51*yglukhov joined #nim
12:18:32federico3dom96: is the hardware from nimbuild still around?
12:18:45dom96it was the gcc farm
12:19:04*SenasOzys joined #nim
12:20:05federico3anyone volunteering some hw? andreaferretti , survivorm ? Or perhaps D.O. can provide some?
12:33:11*yglukhov quit (Remote host closed the connection)
12:37:52dom96Do we have the software necessary to make use of the hardware?
12:41:26*athenot joined #nim
12:44:15FromGitter<andreaferretti> I don't think I will be able to provide hardware
12:44:57FromGitter<andreaferretti> but I think hardware is not the problem
12:45:38FromGitter<andreaferretti> the problem is an actual application that lets user register, provide contact information, list dependencies, list which os/archs are supported, and tell how to run tests
12:46:00*endragor quit (Remote host closed the connection)
12:46:12FromGitter<andreaferretti> the idea of doing all of this in automated way is severely limited
12:46:28*endragor joined #nim
12:47:46Yardanicoando also it'll be better to let some trusted users add any nim libraries into this buildfarm
12:49:14Araqandreaferretti: that's just a pullrequest
12:49:22Araqto some repo we need to setup
12:49:37Araqconfiguration can be done via NimScript, JSON, .travis hacking
12:49:45Araqit doesn't matter
12:49:57dom96What is important is presentation
12:50:04dom96Travis is slow
12:50:20dom96and I don't want to click/scroll through tens of pages to find whether some package succeeded
12:50:37FromGitter<andreaferretti> it is not just a pull request
12:50:48FromGitter<andreaferretti> does the current CI application even have a DB?
12:51:03Araqyou're overthinking this
12:51:25FromGitter<andreaferretti> maybe
12:51:28*fvs joined #nim
12:52:19federico3dom96: yes, both the nimble directory and the previous nim-ci can orchestrate that and collect output & so on
12:54:39Araqwell first we need to decide what to test. do we test for Nim regressions or the quality of a Nimble package?
12:55:45Araqthese are not the same things. :-)
12:55:54federico3once the test for a pkg are being run we can both give feedback to pkg users/devs and also use *some* flagged packages as a Nim regression test
12:57:32dom96IMO Nim's travis should just test some nimble packages
12:57:41dom96as it currently does
12:58:12dom96Having a diff of all packages that broke between versions would be useful
12:58:44FromGitter<andreaferretti> does it?
12:59:06FromGitter<andreaferretti> I just checked nim travis file and it only does nimble install of some packages
12:59:07federico3that's what nim-ci was doing using CircleCi because that CI service serves build artifacts
12:59:19FromGitter<andreaferretti> (veey few of them)
12:59:37federico3but it's too restrictive and fiddly
13:00:14Araqdom96, travis is too slow already though
13:00:30federico3instead with dedicated hw we could even test against different OS in a consistent manner
13:01:08dom96Araq: Anyway, when are we releasing?
13:01:20Araqmost packages are hardly portable, you can't test against different OSes in a consistent manner in any meaningful way, IMHO
13:01:30FromGitter<andreaferretti> many are
13:01:56FromGitter<andreaferretti> possibly the majority
13:02:08Araqmy view is probably biased as I don't look at computational stuff, only IO/network related things
13:02:14federico3Araq: I'm not saying all packages must work on all OSes
13:02:39FromGitter<andreaferretti> even IO related things may be portable if they build on the stdlib
13:02:40federico3only the ones that are flagged as reliable on a given OS could trigger a regression alert
13:02:41Araqdom96, all bugs have been fixed, I think
13:02:51dom96https://travis-ci.org/nim-lang/Nim/jobs/345946710#L4061 *sigh*
13:03:11dom96I guess you can take a risk and merge https://github.com/nim-lang/Nim/pull/7229
13:03:21dom96There are still PRs we have to merge before release
13:03:40Araqdom96, that one is too risky
13:03:53Araqcan't merge that for the release
13:04:14YardanicoPASS: ttables2.nim C (714.23207784 secs) is that ok?
13:04:25Yardanicottables2 took 714 seconds on travis ci to pass
13:04:29dom96lol, that sounds like a problem
13:04:49Yardanicoor PASS: tfrexp1.nim JS (249.62910891 secs)
13:05:13dom96see, a CI system should be able to pick those things out
13:05:24dom96travis is so stupid it makes me want to write my own innovative solution
13:05:25YardanicoPASS: tdeepcopy.nim C (463.38030910 secs)
13:05:44Yardanicomaybe travis build bots were overloaded?
13:06:38dom96possible
13:16:13*athenot_ joined #nim
13:16:17*athenot quit (Ping timeout: 276 seconds)
13:16:45AraqPASS: tdeepcopy.nim C (7.93710828 secs)
13:16:57AraqPASS: ttables2.nim C (11.71816730 secs)
13:17:01Araqon my machine
13:17:06Araqso yeah, these are slow tests
13:17:12Araqbut don't take minutes
13:19:37*Vladar quit (Remote host closed the connection)
13:19:59*yglukhov joined #nim
13:20:06*sz0 joined #nim
13:24:39*floppydh quit (Ping timeout: 260 seconds)
13:32:29*endragor quit (Remote host closed the connection)
13:32:56*endragor joined #nim
13:34:29FromGitter<alehander42> yeah, I've always secretly wanted to rewrite travis, but these days honestly building periodically some docker images and executing simpler command on top of them seems simpler to me
13:35:15*floppydh joined #nim
13:39:26*endragor quit (Remote host closed the connection)
13:39:56*endragor joined #nim
13:47:17Araqmratsim: https://github.com/nim-lang/Nim/pull/7265 will this help arraymancer? you might be able to not use any 'when's at all
13:49:06*Arrrr quit (Ping timeout: 256 seconds)
13:54:31FromGitter<Varriount> Araq: Why is `BackwardsIndex` its own type?
13:56:16FromGitter<mratsim> @Araq yes, I reviewed it on IRC yesterday ;)
13:56:57FromGitter<mratsim> @Varriount I think the distinct type is imported so that the compiler throws an error to authors that didn’t adapt
13:57:02FromGitter<mratsim> important*
13:59:27Araqso ... what are your conclusions?
14:08:07FromGitter<krux02> Araq: I am writing a doc string for "writeFloatToBuffer", because I think it needs one.
14:09:01FromGitter<krux02> should I use lines like this: `## :param buf: description` ?
14:11:39dom96no
14:12:07dom96You should write a nicely formatted rst list:
14:12:14dom96## The parameters are:
14:12:15dom96##
14:12:22dom96## * ``buf`` - description
14:12:31dom96For now at least, until we get a proper format for this
14:12:31Araqyou shouldn't write a doc comment for this proc ;-)
14:12:40Araqit's not exported, I hope.
14:13:07Araq ## returns the number of written bytes.
14:13:24Araqsomething like that maybe since the return value is the only thing that is ambiguous
14:15:31FromGitter<krux02> I don't export it, and when it is exported I hope it get's a better name. But I would like to write a comment on it, because I think it is important enough to be commented.
14:15:50Araqso write about the non-obvious parts
14:16:07AraqI don't need comments that translate Nim's syntax into English.
14:16:36Araqand :param: is a bad idea because inevitably it leads to
14:16:45Araq:param foo: the Foo.
14:17:38dom96"The writeFloatToBuffer proc"
14:17:41dom96:P
14:17:45FromGitter<survivorm> @Araq that is often made for auto doc generation
14:18:23FromGitter<survivorm> And explanation is there only if param's meaning isn't obvious
14:18:45AraqI've seen enough Java documentation to disagree.
14:26:34FromGitter<krux02> Araq: There is a line to check for characters: `elif buf[i] in {'a'..'z', 'A'..'Z', '.'}: hasDot = true`, when is that true?
14:27:15FromGitter<krux02> ah, I got it, it is for exponential format
14:29:31*floppydh quit (Quit: WeeChat 2.0.1)
14:36:19*natrys quit (Quit: natrys)
14:37:09FromGitter<survivorm> @Araq what about python docs? The style is the same, but the docs are usually much better
14:38:16AraqI don't like them too much, the docs are usually verbose and missing the point
14:38:48FromGitter<zetashift> I nominate hexdocs! https://hexdocs.pm/elixir/Kernel.html
14:39:02Araqhttps://pyformat.info/ only exists because of Python's weak docs
14:39:14Araqok, that is only about string formatting, but still.
14:40:21Araqthe most important thing are examples.
14:40:45Araqexamples are not one way of learning things. they are the only way.
14:41:06Araqand :param: by definition cannot be about examples.
14:41:22dom96well organised examples are good
14:41:45dom96ironically the strformat module exposes a hell of a lot of lines as "examples"
14:42:14dom96I should just fix it myself of course
14:43:13Araqdon't you dare touch my work of art.
14:43:23*floppydh joined #nim
14:45:53livcdNow I realized...how should I update nim to 0.17.3 ? :-|
14:46:26FromGitter<mratsim> @Araq I like @krux02 PR, it’s much cleaner. I think containers with a length should be a concept too. (Iterable? Unless we may have infinite iterable)
14:46:31FromGitter<survivorm> @Araq plain examples are usually not enough. One of the best docs in my book is http://docs.sqlalchemy.org
14:47:09FromGitter<survivorm> It contains a lot of examples, yes, but also much theory behind them
14:47:19FromGitter<survivorm> EXPLANATIONS
14:47:59FromGitter<survivorm> And API reference is always good too, in some cases invaluable. And there you need params explanation
14:48:06FromGitter<mratsim> @survivorm it really depends on your public, see: https://www.divio.com/en/blog/documentation/
14:49:27FromGitter<mratsim> 4 axes: tutorials / how-to / Explanation / Reference. All with a different audience in mind
14:49:30FromGitter<survivorm> Yeah, @mratsim it's right. So, examples are only one of many
14:49:48FromGitter<mratsim> yes examples only covers the how-to
14:49:55FromGitter<survivorm> they drift to how-to, althought limited
14:50:20FromGitter<survivorm> because how-t's should cover *scenarios*
14:50:37FromGitter<mratsim> indeed
14:50:39FromGitter<survivorm> Which is rare for examples
14:51:09*endragor quit (Remote host closed the connection)
14:53:07*endragor_ joined #nim
14:54:35Araqsurvivorm: when I look at http://docs.sqlalchemy.org/en/latest/core/tutorial.html I only read the example code...
14:55:09*athenot joined #nim
14:55:23FromGitter<survivorm> @Araq http://docs.sqlalchemy.org/en/latest/core/sqlelement.html
14:55:33FromGitter<survivorm> then look here, for example
14:55:37Araqand when I read some wall of text I often translate it in my head into more concrete examples
14:55:52FromGitter<andreaferretti> that is just your personal approach
14:56:01FromGitter<survivorm> That's your own mind work
14:56:10FromGitter<survivorm> not everyone do the same
14:56:10FromGitter<andreaferretti> there are many people who actually like to read text and explanation
14:56:18FromGitter<survivorm> +1
14:56:27*athenot_ quit (Ping timeout: 245 seconds)
14:57:49*endragor_ quit (Ping timeout: 252 seconds)
14:59:09*gsingh93 quit (Quit: ZNC - http://znc.in)
15:00:56Araqwhatever, I stand by my words and Python's parameter descriptions are for the lack of static typing
15:01:55Araqyou might as well argue to annotate the list of possible exceptions in prosa
15:02:13Araqmanually.
15:03:24*yglukhov quit (Remote host closed the connection)
15:05:10FromGitter<andreaferretti> there are various things in documentation
15:05:12Araqremove the examples from SQLAlchemy's docs and see how worse it becomes. Remove the prosa instead and it makes little to no difference.
15:05:15*endragor joined #nim
15:06:19FromGitter<andreaferretti> in that particular case you may be right
15:06:25FromGitter<andreaferretti> now try the same exercise here https://github.com/unicredit/cello
15:06:54FromGitter<andreaferretti> I don't think the examples even make sense without the links to the literature
15:07:05FromGitter<andreaferretti> different libraries have different requirements
15:08:32*r3d9u11 joined #nim
15:08:46*endragor quit (Remote host closed the connection)
15:10:06*endragor joined #nim
15:11:29*MJCaley joined #nim
15:11:39Araq"For bit sequences, rank(i) counts the number of 1 bits in the first i places. "
15:11:49Araqlet x = { 13..27, 35..80 }
15:11:49Araqecho x.rank(16) # 3
15:12:02Araqcan't say I understand it :-)
15:12:35Araqmaybe you need more examples :P (or an easier to follow visualization)
15:12:59FromGitter<andreaferretti> yeah, not saying it is very well written
15:13:13FromGitter<andreaferretti> just that the code without explanation will not make much sense
15:13:53Araqone problem here is that a set in math does not have an order
15:14:03Araqyou talk about the first 'i places'
15:14:09Araqand then about sets
15:14:14FromGitter<andreaferretti> an integer set is just a bit sequence
15:14:29AraqI know, I implemented them.
15:14:30FromGitter<andreaferretti> in this case 000000000000011111111....
15:14:45FromGitter<andreaferretti> to the left of position 16 there are 3 ones
15:15:03Araqyeah, bitstrings here would make it much more obvious
15:15:08FromGitter<andreaferretti> that's all that there's to it
15:15:37Araqyes but without the bit strings I'm essentially in the mode "ok, whatever, it's probably true"
15:16:19FromGitter<andreaferretti> I will update the docs to actually show the bitstrings
15:16:36FromGitter<andreaferretti> Anyway the point was that without the prose the code itself does not make much sense
15:16:48FromGitter<andreaferretti> Especially the data structures that come later
15:17:04Araqlet x = "ABRACADABRA"
15:17:04Araqecho x.rank('A', 8) # 4
15:17:18Araq^ that one is much easier to follow
15:17:37Araqbut you could instead write
15:17:50Araqlet x = "ABRACADA|BRA"
15:17:52FromGitter<andreaferretti> thank you for the feedback, I will try to improve the docs
15:20:07Araqlet x = "ABRACADA|BRA"
15:20:07Araq# ^ 8th position
15:20:07Araqassert x.rank('A', 8) == 4 # 4 instances of 'A'
15:20:34Araqsee? only an example required to explain 'rank' :P
15:20:53Araqbut hey, keep the prosa, it's fine.
15:25:24*yglukhov joined #nim
15:28:30*floppydh_ joined #nim
15:28:41*floppydh quit (Quit: WeeChat 2.0.1)
15:37:57*r3d9u11 quit (Remote host closed the connection)
15:41:10FromGitter<alehander42> I agree that examples are a bit more important ( I hate when there is a huge list of methods/api with no examples: examples can showcase *recommended* usage & pitfalls succintly.) Still explanations are also good to have for non-obvious srtuff
15:42:54*PMunch quit (Quit: Leaving)
15:44:24FromGitter<mratsim> I absolutely hate reading doxygen docs for that matter
15:46:17FromGitter<alehander42> of course ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ works :D I've created macros for nothing [https://gitter.im/nim-lang/Nim?at=5a957d49758c233504c83d52]
15:48:45*yglukhov quit (Remote host closed the connection)
16:08:45*endragor quit (Remote host closed the connection)
16:10:10*floppydh_ quit (Quit: WeeChat 2.0.1)
16:12:17FromGitter<krux02> I absolutely hat reading doxygen docs for various reasons. Most importantly the generated document is very hard do navigate.
16:16:55*yglukhov joined #nim
16:17:54*Trustable joined #nim
16:22:42*SenasOzys quit (Ping timeout: 245 seconds)
16:30:18*SenasOzys joined #nim
16:35:48FromGitter<Bennyelg> I vote for examples! without them I am nothing :) i hate to read too much docs without getting the point. easy to me understand an example and than see some doc
16:38:05GitDisc<treeform> Hey dom96, some thing is wrong with nimble or this package, not sure which?
16:38:06GitDisc<treeform> https://gist.github.com/treeform/3c3f36b9662cd926a7990c9115c41a75
16:38:27GitDisc<treeform> https://github.com/watzon/github-api-nim
16:38:44GitDisc<treeform> it says client.nim should be moved, but its already in the right dir?
16:39:04dom96https://github.com/watzon/github-api-nim/blob/master/github_api.nimble#L8
16:39:08dom96Not with that 'srcDir'
16:39:48GitDisc<treeform> I still don't get it.
16:40:06GitDisc<treeform> so he should just remove that so that src dir is the pkg root?
16:40:09dom96yes
16:40:33dom96Nimble installs everything in the 'srcDir'
16:40:45dom96and by default that's wherever the .nimble file is
16:41:15GitDisc<treeform> but you can move it inside
16:41:19GitDisc<treeform> did not know thanks!
16:41:20GitDisc<treeform> it was confusing me
16:41:44GitDisc<treeform> i am downloading all nimble packages and checking them for errors.
16:41:51GitDisc<treeform> it looks like good 50% of them have errors
16:41:55dom96oh cool
16:42:08GitDisc<treeform> i want to open PRs with the authors to fix them
16:42:16dom96brilliant
16:42:30GitDisc<treeform> but I need to know how 😦
16:42:45dom96The ideal structure is a 'src' directory
16:42:55dom96and then 'srcDir = "src"'
16:43:11GitDisc<treeform> but then can you have multiple files there?
16:43:23dom96Then you need a 'pkgName' directory
16:43:26dom96inside that
16:43:35GitDisc<treeform> hmm no one is doing that
16:43:53GitDisc<treeform> well sorry, i have not seen that yet
16:43:57GitDisc<treeform> some people are probalby are
16:44:08dom96it's not a requirement
16:44:20dom96it just adds some nice separation
16:47:37dom96Here is a new package that almost gets it right: https://github.com/emekoi/suffer/tree/master/src/private
16:47:45dom96this directory should also be in a 'suffer' dir
16:47:52dom96even though it only contains .c files
16:48:00GitDisc<treeform> why private?
16:48:03dom96That's something that I should get Nimble to verify too
16:48:15dom96'private' by contention means "package-local"
16:48:26dom96*convention
16:48:36GitDisc<treeform> i mean its odd that you have to skip it: `skipDirs = @["docs", "private", "example"]`
16:49:08dom96oh, I didn't realise it was skipped
16:49:26GitDisc<treeform> dom96 what are your thoughts on including dlls in the nim packages too?
16:49:43GitDisc<treeform> its seems to hard to reproduce builds that wrap c libs?
16:50:08GitDisc<treeform> mainly because package managers on windows are not good.
16:50:26dom96I think chocolatey should be used
16:50:39GitDisc<treeform> but it does not have stuff
16:50:49dom96so add the DLL to chocolatey :P
16:50:55GitDisc<treeform> like cairo.dll for example spend a long time looking for it
16:51:25GitDisc<treeform> i also chocolatey is trying to be more like an app installer rather then dll finder...
16:51:27dom96I don't want Nimble to care about DLLs
16:51:39dom96But I do plan to offer ways to extend Nimble to add such functionality
16:52:09dom96maybe it's time someone wrote a DLL package manager for Windows
16:52:17GitDisc<treeform> if dlls are not included its hard to be reproducible builds, less so with .so files but it still happens.
16:52:26FromGitter<krux02> I once wrote a wrapper, where I just instructed the compiler to compile the C files, too.
16:52:32GitDisc<treeform> if dlls are not included its hard to have reproducible builds, less so with .so files but it still happens.
16:53:06GitDisc<treeform> krux02, what if you are using mingw but the C files require VC++ of a specific version?
16:53:09FromGitter<krux02> it worked quite fine, but it only works for small projects you want to wrap, because you basically have to express the entire build of the C library with compile commands.
16:53:29FromGitter<krux02> then the C files will fail to compile
16:53:56FromGitter<krux02> but I don't concider C files that require VC++ of a specific version as a C file
16:54:35FromGitter<krux02> it's only a C file when it is compiliant with the standard.
16:55:19GitDisc<treeform> dom96, i have opend a PR with that pkg: https://github.com/watzon/github-api-nim/pull/1
16:55:39GitDisc<treeform> I hope they fix it. I will try to go through everypackage
16:55:50GitDisc<treeform> what about like "nake" and "bable" files?
16:55:58dom96babel -> nimble
16:56:00dom96Just rename it
16:56:25dom96You can keep the old ini-style nimble files too
16:56:28dom96it's not that important
16:56:30GitDisc<treeform> i though it slightly different format?
16:56:57dom96yeah, there are two formats, but that's not a babel/nimble distinction
16:57:05dom96the new nimble name was adopted much before that
17:00:15GitDisc<ethanpmorgan> Book arrived. Time to sit down and have a good read
17:01:05GitDisc<treeform> dom96, another thing I see, people have tests, but then don't define nimble test task... so nimble test does not work.
17:01:27dom96'test' is defined by Nimble if it doesn't exist
17:02:45*douglascorrea joined #nim
17:04:21GitDisc<treeform> i guess I would like to run the test, but they don't define how?
17:05:57GitDisc<treeform> what should I tell this guy to fix his: https://github.com/Krognol/discordnim
17:06:07GitDisc<treeform> should I tell him to rename src to discrodnim
17:06:18GitDisc<treeform> or tell him to move everything to src?
17:06:28dom96srcDir = "src"
17:06:35GitDisc<treeform> but then move all the files?
17:06:37dom96and move all files into `discordnim` dir
17:06:50dom96except the main file 'discord.nim' could be called 'discordnim.nim'
17:06:58dom96(discordnim is a bad name)
17:07:11dom96oh, he already has a discordnim.nim
17:07:13GitDisc<treeform> for a lib?
17:07:19dom96and his nimble file is named 'discord'...
17:07:48dom96and he copied websockets into his repo
17:07:48GitDisc<treeform> yeah tons of issues
17:08:06GitDisc<treeform> which kind of sux
17:08:25GitDisc<treeform> hmm
17:09:20*yglukhov quit (Remote host closed the connection)
17:10:51GitDisc<treeform> i wish nims package structure was simpler so less people would get it wrong... hmm
17:11:22GitDisc<treeform> is this because package structure hasswitched?
17:11:26GitDisc<treeform> is this because package structure has switched?
17:11:53dom96no, it's because I added a warning to enforce it
17:11:56dom96because nobody reads docs
17:12:41GitDisc<treeform> thats true!
17:12:56Araqyeah that package structure...
17:13:15Araqwe can't get it right :-(
17:13:42GitDisc<treeform> finally a package that defines everything correctly and has tests!
17:13:48GitDisc<treeform> oh wait its 'nimble'
17:15:50GitDisc<treeform> is the default download method "git" or I should not assume that?
17:16:51GitDisc<treeform> never mind it looks like everything has a method defined
17:22:21dom96I think we did do some small adjustments so you may find some of my own packages giving warnings :P
17:27:22dom96Ideas on how we can alleviate this as always are welcome
17:28:28FromGitter<krux02> Araq: do you have any idea why why this could fail my commit changes: `let lst = lc[$x | (x <- 'a'..'z'), string].asList`?
17:28:43FromGitter<krux02> well I analyze it now
17:29:10*Jesin quit (Quit: Leaving)
17:29:48GitDisc<treeform> dom96, my idea was have win, linux and mac, constantly download update and checking all pacakges
17:29:56GitDisc<treeform> and annoying people with errors, test fails and warnings.
17:30:40dom96sure, we should do that
17:30:50GitDisc<treeform> well I am just doing that right now
17:34:21*r3d9u11 joined #nim
17:34:53*Jesin joined #nim
17:35:53dom96yeah, but you're doing it manually, right?
17:36:06dom96Some software that does it automatically would be nice
17:37:39GitDisc<treeform> yeah I have to figure out what to do first. Then do this more automatically.
17:37:43FromGitter<krux02> well I see, for some reason the overloading rules decide to use the `[]` template from system that has an untyped first parameter, even though the list comprehension should match here
17:37:43GitDisc<treeform>
17:37:43GitDisc<treeform> https://cdn.discordapp.com/attachments/371759389889003532/418099393137475594/unknown.png
17:37:56GitDisc<treeform> every nimble pacakge
17:38:26federico3treeform: you mean trying to install a nimble package and show if it fails?
17:38:42FromGitter<krux02> this list comprehension feature in macros really looks a lot like: "I want to be python and I will abuse anything I can to make it look like python"
17:38:46GitDisc<treeform> no i am sure the install works?
17:39:00GitDisc<treeform> i am downloading every package and running its tests
17:39:21Yardanicotreeform: I did the same yesterday
17:39:26YardanicoBut I cloned git repos with --depth 1 :)
17:39:33Araqkrux02: can you use 'typed' for your [] instead?
17:39:33GitDisc<treeform> but most packages have no tests (or have tests but not a rule for them in nimble) or just broken
17:39:47GitDisc<treeform> Yardanico, oh good idea
17:39:51FromGitter<krux02> well yes I think I can
17:40:17federico3treeform: if you have hardware to run tests on windows, nimble directory is doing part of it e.g. https://nimble.directory/pkg/jester
17:41:11GitDisc<treeform> hg does not seem to have --depth 1 equivalent
17:41:30*xkapastel joined #nim
17:41:46Yardanicoyeah, I didn't find any useful one
17:41:53GitDisc<treeform> federico3, are you linking to jester spastically?
17:42:03federico3what?
17:42:04FromGitter<krux02> Araq: that change does not do anything
17:42:17FromGitter<krux02> it is still undeclared identifier
17:42:36Araqnot sure how 'lc' work but it's a gross hack :-)
17:43:03Araqessentially one overload with untyped forces untyped for every other overload
17:43:04FromGitter<krux02> but I don't understand quite why this is the case. The parser knows already the type of the first argument and with that type alone it should be clear that the macro from future should be called
17:43:14GitDisc<treeform> federico3, nimble directory is great. I would be logical for it to run tests to. I am not sure what pkg jester has todo with it?
17:43:28FromGitter<krux02> Araq: well I do understand how it works, and I can easily change it, but not without changing the syntax
17:43:36GitDisc<treeform> federico3: `Jester: The sinatra-like web framework for Nim. Jester provides a DSL for quickly creating web applications in Nim.`
17:43:57FromGitter<krux02> instead of lc[ x | ..., ...], I could simply change it to lc(x | ... , ...)
17:44:23federico3treeform: I know what jester is. Being a popular package, it works well as an example. Please don't insult other people.
17:44:55dom96krux02: the plan is to have for expressions and get rid of this list comprehension macro
17:45:30FromGitter<krux02> that sounds neat. But still this test wants list comprehension to work.
17:45:31Araqdom96: yes but 'lc' needs a deprecation path
17:45:33*yglukhov joined #nim
17:45:37Araqwe can't just change it to ()
17:46:36dom96arghhh
17:46:44dom96latest Nim breaks a package that choosenim depends on
17:47:05Araqso fix the package?
17:47:07FromGitter<krux02> that is shooting in your foot
17:47:09FromGitter<krux02> isn't it
17:47:31FromGitter<krux02> yes I agree, fix the package.
17:47:39FromGitter<krux02> it has to be done anyway.
17:47:39dom96ooh, fixed already
17:48:11dom96awesome
17:49:06dom96now how do I test choosenim update self without releasing a new version of choosenim
17:53:01FromGitter<krux02> you release a new version of choosenim and call it pre-alpha
17:53:29dom96orrr I hack choosenim to make it think its outdated ;)
17:53:42dom96won't be 100% tested but at least partially
17:53:53Araqthat's what I do often too :-)
17:54:04Araqworks well, don't be concerned
17:54:10FromGitter<krux02> well in the entire codebase listcomprehension is only used by the test
17:54:23dom96I predict that it might fail because of choosenim's proxyexe's though
17:54:30dom96which I can't test easily
17:54:51Araqthese proxyexes keep me awake at night
17:56:25dom96:P
17:56:30*donotturnoff joined #nim
17:57:25*yglukhov quit (Remote host closed the connection)
18:05:03FromGitter<krux02> Araq: the Nim compiler wants to typecheck all arguments for `[]`, but fails at that. Even though there is an overload that does not nedd any typechecking.
18:06:10*MJCaley quit (Quit: MJCaley)
18:08:12Araqpretty sure that's documented behaviour
18:09:10dom96yay, choosenim's travis failing on mac because of openssl
18:09:26dom96Did I mention how much I hate dependencies?
18:11:07FromGitter<krux02> Araq: well I tried a lot, all I can come up with is the solution to change the syntax of list comprehension to braces instead of brackets.
18:11:36*birdspider joined #nim
18:11:37FromGitter<krux02> `let lst = lc($x | (x <- 'a'..'z'), string).asList` works fine
18:12:26FromGitter<krux02> maybe I have another idea, but it's a step backwards
18:12:31Araqhow come my solution works with lc?
18:14:10FromGitter<krux02> you use untyped templates for `[]`
18:14:28FromGitter<krux02> and then you check in the template with `is`
18:14:46FromGitter<krux02> but that is not extendable
18:15:17FromGitter<krux02> I have the `[]` with a secord arument fixed as Backwards index
18:19:28Araqah yeah
18:20:17Araqmaybe make your solution opt-in?
18:20:35Araqor rather have some -d:nimIneedLc for compatibility?
18:21:02Araqyour solution is pretty nice and 'lc' is pretty bad :-)
18:22:55YardanicoOn list of nim projects on github sorted by stars - at least two of these packages on the first page are broken :)
18:23:31YardanicoAporia (but I guess it's ok), and nimes (NES emulator)
18:23:49Araqbroken because ...?
18:24:09YardanicoAraq, well, I mean it needs some fixing with current devel
18:24:33Yardaniconimes is broken because range type rules have changed
18:24:45Yardanico(it uses stuff like "case val mod 3 of:"
18:26:42Araqok, that can be fixed by template modMask(x, n): untyped = range[0..n-1](x mod n)
18:27:03Araqwhich is how this feature should have been done in the first place :-)
18:28:40livcdhttps://www.reddit.com/r/golang/comments/80l18y/how_many_of_you_tried_d_why_did_you_abandon_it/?st=je5zjd4d&sh=5379822b <- i guess most of the things people comment about also apply to Nim :)
18:28:47livcd(sorry offtopic)
18:29:38FromGitter<krux02> I just looked for all usages of the identifier `lc` in nim files. sadly I can't include the `[` character in my serach. I get 170 results. Half of that is just an identifier lc used randomly, the other half is actually list compresenios. In other words. List comprehension is used 60 time all over the world.
18:29:59YardanicoI want to check if nimkernel still works with latest devel :P
18:30:06Yardanico(downloading i686 toolchain)
18:31:17FromGitter<zetashift> @livecd half of em are complaints about D's history and the other half about better tooling
18:31:27FromGitter<zetashift> Nim can learn from both and apply it
18:31:54*birdspider quit (Quit: Leaving)
18:33:02FromGitter<krux02> yes Nim can learn from the mistakes of D
18:33:10FromGitter<krux02> but nim is not D
18:33:14FromGitter<krux02> I think nim is better than D
18:33:28Yardanicook, apparently nimkernel still compiles & works (although it's not a big codebase)
18:33:35Yardanicowhich is cool :)
18:33:36dom96really?
18:33:38dom96it works for you?
18:33:38Yardanicodom96, yes
18:33:41FromGitter<krux02> without testing D, but nim has typed ast based macros
18:33:45Yardanicodom96, why not?
18:33:46FromGitter<krux02> power feature.
18:33:49FromGitter<zetashift> @Yardanico wow I didn't expect that to compile
18:33:55dom96I haven't tested it since I wrote it :P
18:34:05Yardanicodom96, but I used i686-elf-gcc compiler instead of i586-elf-gcc, not much difference though
18:34:19FromGitter<zetashift> nimkernel is one of the first things I explored while reading on nim :O
18:34:31Yardanicoapparently there's no deprecation warnings compiling nimkernel :D
18:34:44dom96livcd: "No job security"
18:34:56dom96So basically "No Google behind it"
18:35:12Araqso .. for loop expressions are pretty tough to implement
18:35:33Araqthe parser change looks easy enough but the rewrite rule is not obvious how to design
18:35:53Araqa for loop yielding type T gets the type ForLoopExpr[T]
18:36:08Araqand then in theory you can match this type in a macro and perform the rewrite on your own
18:37:03Araqexcept we can't easily rewrite @[for i in 0..3: i] becuase the array [] constructor is builtin
18:37:38dom96I'm really tempted to ask "How many of you tried Nim. Why did you abandon it?" :)
18:37:57Araqyou are never depressed enough, are you?
18:38:05Araq:P
18:38:40Araqmaybe it I use a toSeq macro
18:38:48AraqtoSeq(for i in 0..4: i)
18:39:50Yardanicolook at this beauty - https://i.imgur.com/9WR4MzW.png
18:40:02dom96:D
18:40:21dom96Now rewrite Linux in Nim :P
18:40:33federico3Yardanico: what is it?
18:40:38Yardanicofederico3, nimkernel?
18:41:22FromGitter<alehander42> the index out of bounds does it for me
18:41:35Araqnimkernel is an exokernel
18:41:44Yardanicoalehander42: it's just for testing exception handling :P
18:42:10FromGitter<alehander42> :D it's still beautiful
18:42:23dom96It's a work of art
18:42:35dom96Bids start at £1,000,000
18:43:38Yardanicowith nim v2 it'll be actually a lot easier to write kernel in nim :)
18:43:45Yardanicobecause no GC
18:44:00Yardanicowell, I think you can port some GC to this nimkernel too
18:44:53*salewski joined #nim
18:44:56FromGitter<zetashift> Haven't people made OS's in GC-d langs for years? OTOH OCaml has a pretty known unikernel
18:45:08Yardanicodom96, there's also mero which is based on your nimkernel: https://github.com/samanthadoran/Mero
18:45:13Yardanicoit's actually cool (but it requires some fixing)
18:45:21Yardanicoand it has memory allocation!
18:45:26dom96:o
18:46:05dom96I remember when I was making nimkernel and wondering how to handle memory with the GC
18:46:10dom96and Araq said I should just use the GC :P
18:47:12AraqI still think you can make Nim's GC run in kernel space
18:47:34Araqyou have a heap and a stack, you can have a GC
18:48:19FromGitter<krux02> I don't think you want a GC in kernel space, but yea, who knows.
18:48:21Yardanico:D https://github.com/samanthadoran/Mero/blob/master/source/keyboard.nim#L74
18:48:31FromGitter<krux02> I am no expert in kernel programming
18:48:40FromGitter<krux02> but the screenshot reminded me of my program
18:50:15Araqthat's just C being dump. memset() is a CPU feature, not an OS feature
18:50:37Araqif you can't use string.h in your kernel, get a string.h that works
18:50:57*Trustable quit (Remote host closed the connection)
18:52:06Araqsome header files are more equal than others
18:55:00dom96bah, zahary added a lot of nimble packages without a PR
18:55:54ehmrya nim unikernel would be cool, but these days it should be unikernels or microkernels. hopefully linux isn't going to happen again
18:56:59salewskiDoes someone have an idea about https://github.com/StefanSalewski/gintro/issues/24
18:57:12salewskimay it just be missing ssl for nimgrab?
18:57:21FromGitter<zetashift> I compiled with d:ssl tho
18:57:27FromGitter<zetashift> :D
18:58:00salewskiFor linux nimgrab was working fine when compiled with ssl.
18:58:04FromGitter<zetashift> Should I try it with this: http://gnuwin32.sourceforge.net/packages/wget.htm ?
18:58:52salewskiYes, would be good. But we have to find out why nimgrab fails, araq said it should work once.
18:59:32FromGitter<krux02> I don't use nimgrep, normal grep just works fine
19:00:01Araqzetashift: update your Putty client
19:00:23Araqkrux02 nimgrep does much more than grep though
19:00:26salewskinimgrab -- not related to nimgrep!
19:00:45Araqthat too.
19:01:05FromGitter<krux02> I thought it was a typo
19:01:28Araqyou know the saying, "nimgrab her by the Putty"
19:01:33FromGitter<krux02> is nimgrep just forwarding to grep but with a regexp change?
19:02:07FromGitter<krux02> well I have to go
19:03:27Araqin short: no.
19:06:14Araqzetashift: does it work?
19:09:52FromGitter<zetashift> Haha I posted in the wrong gitter
19:10:09salewskizetashift: But even when it installs, there may be problems. Some people have trouble getting GTK3 working on Windows at all.
19:10:38FromGitter<zetashift> I asked "@Araq, how do I even update the Putty client? Google says w10 ships with OpenSSH"
19:11:20Araqwell hmmm
19:11:33Araqthat solved it for me yesterday
19:11:44Araqtry our new OpenSSL DLLs
19:13:23shashlickdom96: in case you didn't find this yet - https://nim-lang.org/docs/rdstdin.html
19:13:25shashlicklooks like irclogs is down
19:13:54FromGitter<zetashift> @Araq, I did a clean install yesterday; So I should have the latest DLL's(which I downloaded from the site)
19:14:26Araqyou don't because 0.18 is not yet out which will ship with these
19:14:30Araqjust a sec
19:15:32dom96shashlick: works for me
19:16:04dom96I hope we remove this rdstdin thing
19:16:20dom96why even have a separate module for this..
19:16:31shashlickya, just saw your stream and was wanting to chime in :)
19:16:49Araqrdstdin is what the compiler uses
19:17:09shashlickwatching: https://www.youtube.com/watch?v=Oiw23yfqQy8
19:17:30Araqdo we really want the linenoise dependency whenevery somebody uses terminal.nim?
19:17:49Araqterminal is for TUIs, rdstdin is for line histories
19:17:53dom96we don't, but we also don't want these tiny modules that "the compiler uses"
19:18:42Araqyou mean the stuff that doesn't break? :P
19:19:06ehmryI was using readlinewrap before I relalized there was rdstdin, now I just use rdstdin so that stuff like terminal echo works
19:21:46ehmryrlwrap gives you line history with no compile dependencies
19:21:48*ludocode left #nim (#nim)
19:22:55Araqand Windows gives every terminal program a history out of the box :P
19:23:12AraqWindows -- king of the command line.
19:25:22livcdyeah but i had to reboot to unfuck the %PATH% when updating Nim
19:25:32livcdcons and pros
19:27:04Araqget "Rapid Environment Editor" or restart your console
19:27:13Araqthere is no need whatsoever to do a full reboot
19:27:22Araqmaybe if you're on Win95
19:27:38livcdI did. Something running still held the old configuration.
19:28:05dom96That would be no different on other OSs
19:29:01FromGitter<zetashift> @Araq how can I get my hands on those updates DLL's. I am running on latest devel though ;D
19:29:34*watzon joined #nim
19:30:32watzonDoes anyone know if a package exists for adding colors to strings for use with the logging module? Asking for a friend.
19:30:34livcdIdk other OSs fuser or lsof usually work unlike this one.
19:31:21FromGitter<zetashift> @watzon you mean: https://nim-lang.org/docs/terminal.html ?
19:31:34GitDisc<treeform> after analyzing all pkgs here are some stats:
19:31:36GitDisc<treeform> ```good 383
19:31:36GitDisc<treeform> invalidStrucutre 208
19:31:37GitDisc<treeform> invalidNakefile 1
19:31:37GitDisc<treeform> invalidNimbleName 6
19:31:37GitDisc<treeform> invalidName 8
19:31:38GitDisc<treeform> missingNimble 2
19:31:38GitDisc<treeform> missingReadme 1
19:31:39GitDisc<treeform> hasNameInNimble 2```
19:31:57FromGitter<zetashift> that's decent
19:32:02AraqhasNameInNimble?
19:32:08Araqwhat does that mean?
19:32:12GitDisc<treeform> name = "foo" is not valid any more
19:32:21GitDisc<treeform> you can't have a name directive in nimble
19:33:33watzon@zetashift can that be used in conjunction with the logging module? I haven't used Nim for a bit so I'm not much help to the guy that needs to know.
19:34:43GitDisc<treeform> Araq: see https://gist.github.com/treeform/3f692bbc6932af0c6a994c70ed8aeeff
19:35:05GitDisc<treeform> this line needs to be removed: https://github.com/baabelfish/mangle/blob/master/mangle.nimble#L2
19:35:09dom96hey watzon. I think your friend will need to implement their own `Logger`, similar to the `FileLogger`.
19:35:24dom96or rather, the ConsoleLogger I was meaning to say :)
19:35:38FromGitter<zetashift> @watzon I thought you had a ConsoleLogger and could just manipulate that with terminal ;P
19:35:47watzonIt seems like it will change all of the colors for the terminal at the same time. I think he was hoping for one that you can use to colorize strings individually
19:36:13watzonAhh I gotcha
19:36:32FromGitter<SitiSchu> For clarification: I'd like to do something like this: http://i.sitischu.com/21f0d
19:36:47FromGitter<SitiSchu> (I'm the guy @watzon is talking about ^^)
19:37:44dom96yeah, just take a look at how the ConsoleLogger is implemented in the logging module and then implement your own ColoredConsoleLogger :)
19:38:04dom96You should be able to mostly copy and paste its implementation
19:38:24FromGitter<SitiSchu> ok I guess I'll do that, thanks a lot :)
19:42:00*fvs left #nim ("ERC (IRC client for Emacs 25.3.1)")
19:47:20*natrys joined #nim
19:47:43planetis[m]Hello!, how can I make this code work in nim https://gist.github.com/konqoro/4f802a496d961789f5c570ca59a21581 ?
19:49:21planetis[m]it errors fact.nim(24, 15) Error: ambiguous call; both fact.factorial(n: int64 or uint64)[declared in fact.nim(16, 5)] and fact.factorial(n: int8 or uint8)[declared in fact.nim(22, 8)] match for: (int literal(20))
19:49:42*yglukhov joined #nim
19:50:04planetis[m]its from julia stdlib btw
19:51:00*xkapastel quit (Quit: Connection closed for inactivity)
19:51:38Araqfactorial for int8?
19:51:40Yardanicoplanetis[m], well 20 is ambiguous
19:51:47Araqwhat's the point?
19:52:32planetis[m]ok i will remove that one
19:53:38planetis[m]still the same
19:53:59Araqzetashift: http://nim-lang.org/download/dlls3.zip
19:53:59planetis[m]but why its ambiguous?
19:55:30Araqbecause 'int' is not in your list
19:55:40Araqand 20 is of type 'int'
19:56:05Araqint is not an alias, it's a type of its own
19:57:20planetis[m]ok got it
20:00:09planetis[m]calculating 13! at compile time won't work anyway in 32bit right?
20:02:46Yardanicoplanetis[m], why wont?
20:02:49Yardanicoah
20:04:35planetis[m]it overflows an int32
20:05:31Yardanicoplanetis[m], and what about int64 ?
20:05:45planetis[m]ok I remade it
20:06:34planetis[m]the limit is 20!
20:06:36planetis[m]for 64
20:08:22Yardanicoplanetis[m], what about uint64 ?
20:08:35Yardanicoyou don't need negative numbers for factorial, right? :)
20:08:57planetis[m]I think I like it better than the julia version
20:09:02planetis[m]nim is cool
20:09:08*MJCaley joined #nim
20:09:26planetis[m]you are tough to satisfy :p
20:09:27planetis[m]idk
20:12:31*yglukhov quit (Remote host closed the connection)
20:13:27*r3d9u11 quit (Remote host closed the connection)
20:15:28dom96Damn, looks like I've been hit by the classic error of my program thinking that v0.8.10 is actually 0.8.1 D:
20:17:37FromGitter<zacharycarter> Can anyone explain to me why - https://play.nim-lang.org/?gist=6b02354bb8e850eff9eea2d0b405dbde - doesn't work / how to implement it correctly?
20:18:59*salewski quit (Quit: WeeChat 1.9.1)
20:20:29Araqw.kind == PlayerKind.Warrior is not known at compile-time
20:21:26FromGitter<zacharycarter> ahhh okay - I didn't realize evaluations inside concepts had to be compile-time ready - but that's totally logical
20:21:33FromGitter<zacharycarter> hrm - I guess it might be tougher to do this than I expected
20:21:59Araqdunno, concepts are mostly sugar
20:22:23AraqI can always write the code without a concept since Nim checks the types at instantiation time
20:22:50FromGitter<zacharycarter> yeah - I guess I might be able to achieve this with a macro or something?
20:23:44FromGitter<zacharycarter> not really sure how to do type refinement based on a runtime value
20:23:51FromGitter<zacharycarter> I guess you can't
20:24:53Araqit's a type system, it only deals with compiletime :-)
20:24:59FromGitter<zacharycarter> yeah heh
20:37:11YardanicoI still feel this proc has a pretty long name :) https://github.com/nim-lang/Nim/commit/a897371797154844f96906e72fa013b8205d0393
20:37:21Yardanicobut you don't use it a lot, so that's fine
20:42:19FromGitter<SitiSchu> use an editor with autocomplete I guess ^^
20:44:33YardanicoI do :P
20:53:10*xkapastel joined #nim
20:54:56*rokups quit (Quit: Connection closed for inactivity)
20:56:27federico3dom96: does Nimble strictly requires a README.md file?
20:57:02dom96no
20:57:23federico3any README* ?
20:57:34dom96no, why would it?
20:57:57federico3just checking - it was claimed on https://github.com/FedericoCeratto/nim-syslog/issues/7
20:59:00dom96hrm, linux binary for newest choosenim seems suspiciously small
20:59:25dom96treeform: "nimble requires projects to have README.md. Would you please convert README.adoc to README.md?"
20:59:31dom96That's wrong
21:00:07federico3dom96: https://github.com/nim-lang/nimble#project-structure make it looks so
21:00:48dom96Why would Nimble require an .md file?
21:02:12federico3are you asking me?
21:03:44dom96I just don't see a reason for spelling out that '.adoc' or '.rst' or whatever other format you want is fine too
21:04:28federico3dom96: if you are asking me: there's a README.md listed in the project structure that makes it look like it's required
21:04:52dom96The text above it has the word "recommended" :(
21:05:30dom96Choosenim 0.3.2 is officially here https://github.com/dom96/choosenim/blob/master/changelog.markdown#032---27022018
21:06:33*Jesin quit (Quit: Leaving)
21:07:06Yardanicodom96, btw, just curious - how much unique IDs (people) you have in analytics?
21:07:16Yardanicowho accepted sending anonymous data
21:07:36dom96don't know the count
21:07:53dom96Not even sure how to check it
21:10:53*do_not_turn_off joined #nim
21:11:57*donotturnoff quit (Ping timeout: 240 seconds)
21:14:43dom96To give you a sort of ball park, the peak number of "users" (no idea how analytics even defines them) on the same day was 27 on January 9, 2018.
21:15:57Araqoh my I broke the tests again
21:16:26Araqand I cannot open appveyor's results anymore as that freezes my browser
21:16:32dom96I think the "users" are basically the unique IDs though
21:16:45Araqso I have to look at travis' log
21:18:43*vivus joined #nim
21:19:44dom96The OS split is: 66% Linux, 12.7% Mac and 20% Windows
21:20:06dom96Impressed that Windows is more popular than Mac
21:20:22FromGitter<Bennyelg> :| interesting.
21:20:37*do_not_turn_off quit (Ping timeout: 252 seconds)
21:21:02Araqso many Linux users, interesting
21:21:24FromGitter<Bennyelg> Windows is deprecated since fedora 3
21:21:27FromGitter<Bennyelg> :)
21:21:36dom96Araq: Most are probably just travis CI
21:22:09Araqtravis CI visits our website?
21:22:21*yglukhov joined #nim
21:22:36dom96this is choosenim
21:30:52GitDisc<treeform> dom96, "Why would Nimble require an .md file?" https://gist.github.com/treeform/2c5b6b3fa302ccf2da5d3005d2bea1ba
21:31:02GitDisc<treeform> I think its what that error message is trying todo? Am I wrong?
21:31:52dom96https://github.com/FedericoCeratto/nim-syslog/blob/master/syslog.nimble#L16
21:32:27dom96good that 'check' catches that
21:32:30dom96I didn't test it
21:33:13GitDisc<treeform> requiring README.md file is not a bad idea ...
21:33:30GitDisc<treeform> but I see the person says they have the file, then they have a different file/
21:33:38GitDisc<treeform> I will change my PR
21:36:16GitDisc<treeform> I hope I made the PR more clear: https://github.com/FedericoCeratto/nim-syslog/issues/7
21:36:38dom96That's not a PR :)
21:36:48GitDisc<treeform> sorry issue
21:37:01GitDisc<treeform> repo has too many errors, I don't want to rewrite it just yet.
21:38:56GitDisc<treeform> dom96, what should I do about packages that have `-` and `.` in the name?
21:39:11dom96ask the maintainer to rename
21:39:19GitDisc<treeform> ok
21:39:49GitDisc<treeform> was it a valid name before?
21:39:54GitDisc<treeform> how did they get added?
21:40:11dom96it was
21:49:08GitDisc<treeform> What are the rules for taking over unmaintained pkgs like? https://github.com/barcharcraz/nim-assimp
21:49:23GitDisc<treeform> 3 PRs, last commit 3 years ago...
21:51:21GitDisc<treeform> dom96, what are your thoughts about naming like `nimfoo` and `foonim` should that be discouraged?
21:54:15*rauss quit (Quit: WeeChat 2.0.1)
21:54:37*rauss joined #nim
21:56:37dom96I discourage it
21:56:40dom96but not enough to ask for a rename
21:58:57*rauss quit (Ping timeout: 245 seconds)
21:59:08*sz0 quit (Quit: Connection closed for inactivity)
22:00:17*rauss joined #nim
22:09:28*natrys quit (Quit: natrys)
22:09:53*nsf quit (Quit: WeeChat 2.0.1)
22:10:25jaco60Hello... Don't know if it's the place for newbie questions but, just in case... How to specify a width spec in format strings ? I've understood Nim uses the old Python 3.x format thing to interpolate values in strings but how can i do the same as {:.2}, for example ?
22:19:03dom96jaco60: fmt"{1.2:.2f}" might work
22:19:50dom96where <1.2> can be your variable
22:20:01dom96(the `fmt` macro is defined in strformat)
22:23:11jaco60dom96 : strformat is in the devel branch ?
22:23:32dom96yep
22:23:36jaco60argh
22:23:57jaco60nvm... i'll use printf...
22:24:09dom96Just grab devel
22:24:19*MJCaley quit (Quit: MJCaley)
22:24:31dom96Nim moves fast so you'd want to use that for now anyway
22:25:35jaco60@dom96 is there a documentation about new features introduced by devel ? (something like a "What's new?" ?)
22:26:16dom96https://github.com/nim-lang/Nim/blob/devel/changelog.md
22:26:32jaco60Cool, thanks
22:28:17FromGitter<zetashift> @Araq @salewski that didn't fix the error
22:29:13ZevvHi. I'm building a simple regular expression / pattern matching lib based on Lua patterns
22:29:33ZevvI'm looking for a way to return a variable number of captures
22:29:53ZevvWhy are these two considered the same?
22:29:54Zevvproc match(src: string, pat: string): (string, string)
22:29:56Zevvproc match(src: string, pat: string): (string, string, string)
22:30:11Araqbecause overloading doesn't look at the return types
22:30:20ZevvOk, that makes sense
22:32:01ZevvAre there any idiomatic solutions to this?
22:32:21ZevvFor easy unpacking I'd like to return a tuple, but the number of elements depends on the captures made by the pattern matching
22:45:29Araqwrite a macro
22:48:29*Jesin joined #nim
22:59:03*jaco60 quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:16:02*yglukhov quit (Remote host closed the connection)
23:31:41*yglukhov joined #nim
23:33:45*vlad1777d_ joined #nim
23:36:17*yglukhov quit (Ping timeout: 256 seconds)
23:54:57*SitiSchu joined #nim