| 00:08:21 | * | def-pri-pub joined #nim |
| 00:15:52 | * | zachcarter quit (Quit: zachcarter) |
| 00:57:54 | * | vlad1777d quit (Quit: Leaving) |
| 01:20:03 | * | pie_ joined #nim |
| 01:23:50 | * | brson quit (Quit: leaving) |
| 01:24:13 | * | brson joined #nim |
| 01:25:55 | * | pie_ quit (Ping timeout: 260 seconds) |
| 01:30:19 | * | arnetheduck joined #nim |
| 01:38:09 | * | brson quit (Ping timeout: 260 seconds) |
| 02:01:31 | * | chemist69 quit (Ping timeout: 264 seconds) |
| 02:02:19 | * | adeohluwa quit (Quit: Connection closed for inactivity) |
| 02:13:17 | jsgrant_om | Is 'Frag' decently mature? Want to try to dip my toes with it, to learn a little Nim. |
| 02:14:02 | jsgrant_om | http://fragworks.io/ If not clear what I'm talking about. |
| 02:15:00 | ftsf | i think it's pretty recent, haven't tried it myself, but give it a go =) |
| 02:15:17 | * | chemist69 joined #nim |
| 02:15:57 | jsgrant_om | Game-loop looks pretty nice, albeit a little verbose; That said much of that might be my said inexperience with Nim. :^) |
| 02:16:45 | ftsf | trying to get a nimble task to build my example app =\ task example, "runs example app": exec "nim c -r examples/paintout" |
| 02:17:08 | ftsf | when i run `nimble example` it does nothing except print "example runs example app" =\ |
| 02:17:28 | jsgrant_om | Related to nimble, should that ship with standard Nim? Doesn't seem to be available in Fedora. |
| 02:17:49 | ftsf | i think it should, but distros may decide otherwise, is there a separate nimble package? |
| 02:18:08 | ftsf | (or at least be a dependent package) |
| 02:18:24 | jsgrant_om | ftsf: Only 'dnf search' result for nimble is "rubygem-prawm". |
| 02:18:38 | jsgrant_om | Is Nimble newer? |
| 02:18:39 | ftsf | =( |
| 02:18:55 | jsgrant_om | Maybe it just isn't in currently shipping version of Nim in Fedora. |
| 02:19:13 | ftsf | which version? |
| 02:20:30 | jsgrant_om | Oh farts... well that will do it. Fedora must not package Nim at all currently in main repo... must be mixing this box up with NixOS boxen. :^U |
| 02:20:46 | jsgrant_om | Just 'nim --help' and got a command not found... :^U |
| 02:21:14 | ftsf | ahh |
| 02:21:23 | jsgrant_om | Which I'm sure they don't have a nim2nix yet. |
| 02:21:28 | ftsf | well probably explains why there's no nimble =) |
| 02:21:55 | * | jsgrant_om will check copr, may have a go at making an rpmspec if there is none for it. |
| 02:22:51 | jsgrant_om | There's a nim-stable in copr, but last updated 10 months ago. |
| 02:23:36 | jsgrant_om | Almost makes me miss Arch/Aur. |
| 02:23:43 | ftsf | mmm arch <3 |
| 02:24:16 | jsgrant_om | Copr is nice, but too new & userbase is too little compartiviely me thinks. |
| 02:25:25 | jsgrant_om | Will eventually probably move full-time to NixOS... but somewhat commited to Fedora is my day-to-day box for the next-year at least. Somefactor of "good enough" till you run into one of these gotchas. |
| 02:25:36 | ftsf | https://nim-lang.org/0.11.3/nims.html A project.nims file can also be used as an alternative to a project.nimble file to specify the meta information... i'm guessing that's no longer true? |
| 02:26:20 | jsgrant_om | All thing said though, shocked with the typical user-spread of Fedora -- that no-one packaged it in the main repos though. |
| 02:26:33 | jsgrant_om | Double-though-combo. |
| 02:26:44 | ftsf | it could be you! |
| 02:28:12 | jsgrant_om | ftsf: Most I'd commit likely would be a copr spec, as-said not sure if going to be on Fedora for a year & you make a loose agreement to package to somefactor of maintain and/or pass on privs eventually. :^P |
| 02:28:50 | jsgrant_om | That being said, modern copr spec would be nice. Even "nim-devel" on copr right now is 6 months old & said last build failed. |
| 02:31:05 | ftsf | =( |
| 02:31:23 | ftsf | gonna try get my nim game in PAX indie showcase ^_^ |
| 02:31:33 | jsgrant_om | ftsf: Link? |
| 02:32:17 | ftsf | https://twitter.com/impbox/status/861756652311072768 pixel racing game |
| 02:33:22 | jsgrant_om | ftsf: ++ |
| 02:33:27 | pydsigner | Noice |
| 02:33:28 | jsgrant_om | Very cool. |
| 02:34:27 | * | jsgrant_om finds it hard to commit to making actual games; Mostly have made toys & lil sandboxes over the years; Want to start getting into gamejams next-year to force me to get a full project out. |
| 02:34:45 | ftsf | yeah game jams are great! just did ludum dare for the 2nd time using nim, lots of fun |
| 02:35:16 | ftsf | just make little stuff until you find something that's fun then keep working on it and release it |
| 02:36:41 | FromGitter | <Varriount> We need blog posts to submit to reddit and hacker news |
| 02:37:40 | ftsf | does anyone read those? =p |
| 02:37:56 | ftsf | jsgrant_om, https://ldjam.com/events/ludum-dare/38/smalltrek my last ludum dare game |
| 02:37:58 | jsgrant_om | ftsf: People only watch sassy con-talks. |
| 02:38:19 | FromGitter | <Varriount> ftsf: People on Reddit and Hacker News |
| 02:38:52 | jsgrant_om | Basically half of Bryan Lunduke's Resume. |
| 02:41:11 | FromGitter | <Varriount> If anyone needs VGM artists, there's a bunch on bandcamp |
| 02:41:24 | jsgrant_om | ftsf: Neat. |
| 02:42:42 | jsgrant_om | Pixel art is haaaard. Rather I probably just don't have the patience. |
| 02:42:48 | jsgrant_om | Voxel is pretty fun though. |
| 02:43:27 | ftsf | hmm i love doing pixel art, can work in a low res so it's very fast to make. haven't tried doing voxel stuff yet |
| 02:54:03 | FromGitter | <Varriount> ftsf: @zacharycarter might need your help then... he needs assets for an example game for frag |
| 02:55:46 | ftsf | looks like frag is going for a more high res style with the spline and stuff compared with nico which is mostly for pixel art type stuff |
| 02:57:14 | * | libman quit (Quit: Connection closed for inactivity) |
| 03:02:00 | * | Ieuan quit (Quit: ZNC - 1.6.0 - http://znc.in) |
| 03:18:01 | * | def-pri-pub quit (Quit: leaving) |
| 03:20:58 | jsgrant_om | Yeah, I'll shop around some more. More-lkely I'll settle on the Rustier side of things from the little I've looked about; But kinda peeking around the landscape & poking bushes atm. |
| 03:27:03 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 03:34:29 | * | ftsf_ joined #nim |
| 04:02:43 | * | chemist69 quit (Ping timeout: 255 seconds) |
| 04:06:02 | * | ftsf_ quit (Ping timeout: 240 seconds) |
| 04:07:17 | * | chemist69 joined #nim |
| 04:21:30 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 04:24:09 | * | zachcarter joined #nim |
| 04:44:54 | * | BennyElg quit (Remote host closed the connection) |
| 04:45:02 | * | dexterk_ quit (Ping timeout: 240 seconds) |
| 04:45:06 | * | dexterk__ joined #nim |
| 04:45:19 | * | Trioxin2 joined #nim |
| 04:48:07 | * | Trioxin quit (Ping timeout: 240 seconds) |
| 04:55:49 | * | Trioxin2 is now known as Trioxin |
| 04:59:10 | Trioxin | My fledgling software company is starting to do good. Once we're doing great, I'm going to donate to Nim project. |
| 04:59:39 | Trioxin | I think what Nim really needs is some marketing |
| 05:00:32 | Trioxin | actually, I can contribute that already. who to talk to? |
| 05:21:05 | * | ludocode quit (Ping timeout: 240 seconds) |
| 05:24:35 | * | zachcarter quit (Quit: zachcarter) |
| 05:31:39 | * | ludocode joined #nim |
| 05:49:54 | * | gokr joined #nim |
| 06:15:13 | * | rauss quit (Quit: WeeChat 1.7.1) |
| 06:23:17 | * | chemist69 quit (Ping timeout: 240 seconds) |
| 06:26:06 | * | chemist69 joined #nim |
| 06:29:49 | * | enthus1ast quit (Ping timeout: 260 seconds) |
| 06:30:26 | * | enthus1ast joined #nim |
| 06:34:15 | * | BennyElg joined #nim |
| 06:48:00 | * | nsf joined #nim |
| 06:53:08 | * | couven92 joined #nim |
| 07:03:09 | Araq | Trioxin: me. :D |
| 07:49:07 | gokr | An entertaining article by Robert Martin (known guy): http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html |
| 07:49:47 | Araq | hey, this guy is usually full of bullshit |
| 07:51:49 | FromGitter | <andreaferretti> @Araq I did not try nawabs yet, but will soon! |
| 07:51:58 | * | PMunch joined #nim |
| 07:56:22 | gokr | Well, I admit not being a C++ guy, so I haven't read much from him over the years. But that article was kinda fun and as much as I can tell (since I am 48) it's historically correct. |
| 07:58:02 | gokr | The only thing I disagree with was his claim that it was static typing of Java that made it "win" over Smalltalk. |
| 08:02:52 | FromGitter | <andreaferretti> not only that, it looks like an article written in 2006 |
| 08:03:08 | FromGitter | <andreaferretti> in the last decade, types are definitely coming back |
| 08:03:22 | FromGitter | <andreaferretti> scala, swift, go, rust... |
| 08:03:43 | FromGitter | <andreaferretti> I can barely think of recent popular untyped languages |
| 08:03:56 | FromGitter | <andreaferretti> maybe clojure |
| 08:06:04 | Araq | the idea that "100% test coverage" will make static typing irrelevant is ridiculous. how do you test for the absence of a race condition? |
| 08:06:27 | Araq | static typing proves things about your program. testing proves nothing. |
| 08:06:56 | FromGitter | <andreaferretti> I guess mostly everyone agrees these days |
| 08:07:05 | FromGitter | <andreaferretti> less so a few years ago |
| 08:07:07 | Araq | plus types are also about getting an efficient storage layout. |
| 08:07:56 | Araq | historically, dynamic typing never was as successful as static typing. |
| 08:08:20 | Araq | there wasn't a war going on. professionals used static typing and keep using it :P |
| 08:09:48 | gokr | You are narrow minded. |
| 08:09:50 | euantor | dom96: I've never seen that message before from Mailgun |
| 08:10:25 | Araq | gokr: no, just trying to be controversial ;-) |
| 08:11:18 | gokr | Araq: I agree with parts of what you are saying (various usefulness of static type systems) - but other parts are plain wrong. :) |
| 08:11:46 | euantor | Regarding the above testing discussion, I've also seen tests with bugs in several times, which helps nobody |
| 08:12:20 | gokr | "testing proves nothing" - in a mathematical sense perhaps, but in the real world it actually does help a LOT with good testing. That doesn't mean people can't go apeshit overboard on it though. |
| 08:12:21 | euantor | AN automatic type system is a much better helper (I haven't yet read the article shared above) |
| 08:13:25 | gokr | euantor: There are various things to say on that. Typing only catches a certain set of errors. But it can also cost a lot in "burden". |
| 08:13:59 | Araq | no, every bug can be formulated as a type violation (in some type system). |
| 08:14:24 | gokr | Araq: Further, "professionals used static typing" - well, let's just say that you are plain wrong and end it there. |
| 08:14:34 | euantor | dom96: Thanks for getting recaptcha live by the way, hopefully that will solve some of the complaints there have been regarding captchas |
| 08:14:35 | Araq | that was the controversial part ;-) |
| 08:14:44 | gokr | False part. |
| 08:15:41 | FromGitter | <andreaferretti> @Araq @dom96 looks like nawabs and choosenim do not work together |
| 08:15:58 | gokr | Since I can disprove your claim by simply finding a single professional (or hey, I can give you whole teams, whole companies) that actually, eh, yeah - believe it or not - did (and do) use dynamic typing successfully. Like me. |
| 08:16:11 | FromGitter | <andreaferretti> whenever I run nawabs, I get `Error: cannot open '/home/papillon/.nimble/lib/system.nim'` |
| 08:16:35 | FromGitter | <andreaferretti> I think nawabs expects the stdlib to be located in a precise position wrt the nim binary |
| 08:16:46 | FromGitter | <andreaferretti> which does not hold when using choosenim |
| 08:17:13 | Araq | gokr: could have said "real programmers" instead ;-) |
| 08:17:32 | Araq | didn't mean to offend you. |
| 08:17:54 | gokr | So you mean I wouldn't be offended by being a non real programmer? |
| 08:18:43 | Araq | yeah because http://www.smart-jokes.org/real-programmers.html |
| 08:19:30 | gokr | I know you are joking, but, not all might understand that. |
| 08:19:47 | Araq | I'm sorry. |
| 08:20:33 | gokr | either way, to be slightly more deep/constructive - the thing I find saddening is that here in Nim (which I love although I love Smalltalk too) we are battling the very low level pieces of software engineering. |
| 08:21:25 | Araq | andreaferretti: so choosenim breaks Nim ;-) |
| 08:22:01 | Araq | to bring up a different point: hardware stopped getting faster so things we take for granted are disputed again like GCs. |
| 08:22:54 | gokr | Saddening in the sense that... people aren't even aware of how far some other tooling have come. One may make fun of Smalltalk - but a lot of the stuff going on in that community is very interesting - mainly due to the fact that the IDE is reflective etc. |
| 08:23:25 | FromGitter | <andreaferretti> well, I though either you or @dom96 would be interested :-) |
| 08:24:26 | Araq | I'm not fixing my software to work with this .nimble/bin shit. |
| 08:25:02 | Araq | it didn't work with /usr/bin, it won't work with .nimble/bin, it's the wrong idea |
| 08:25:38 | Araq | either you have a system that uses relative addressing or you have a broken system. |
| 08:27:29 | Araq | gokr: the tooling is even better with static typing ;-) |
| 08:27:54 | gokr | Well, it's not that simple IMHO. |
| 08:28:14 | gokr | But when Nim's preferred IDE comes close to say Pharo - then come back to me. |
| 08:28:43 | gokr | (obviously I understand the value of added type information - but you don't seem to recognize the cost of it) |
| 08:29:35 | * | chemist69 quit (Ping timeout: 258 seconds) |
| 08:31:28 | Araq | which costs? writing down what's in my head anyway? |
| 08:32:13 | gokr | Don't pretend that you don't know what I mean. |
| 08:32:37 | * | chemist69 joined #nim |
| 08:33:03 | gokr | There is a reason why dynamically typed languages very often show huge productivity advantages. |
| 08:33:44 | Araq | never experienced this myself, sorry. |
| 08:34:14 | gokr | Eh, but have you really ever used a dynamically typed language then? |
| 08:34:49 | Araq | yeah, Lua, Python, JavaScript |
| 08:35:11 | gokr | (note my emphasis on "really") |
| 08:35:27 | Araq | productivity is the result of a good library ecosystem, dynamic typing doesn't help it. |
| 08:35:55 | gokr | Hehe, well, I give up. |
| 08:36:28 | PMunch | gokr, dynamic typing is definitely both a pro and a con |
| 08:37:12 | gokr | Of course it is. |
| 08:37:16 | PMunch | The benefit as you say is in the short term development time. Problem comes with larger projects were a bug could take forever to track down and even put critical systems at risk. |
| 08:38:04 | Araq | the short term development time has never been proven in any scientific sense and in theory there are lots of reasons against it and none in its favour |
| 08:38:14 | PMunch | The way I see it is declaring my types make the compiler able to check those thing for me before the product ever hits the customer |
| 08:38:31 | gokr | People keep claiming that, yeah, and I agree that it may be a problem (I have seen it quite a few times, for example in a huge Perl system which was ... abhorrant) - but I can also point at huge Smalltalk systems which haven't experienced it. |
| 08:38:57 | PMunch | Araq, for scripts it's definitely a notable difference when writing in dynamic languages |
| 08:39:03 | PMunch | At least that's what I feel. |
| 08:39:10 | Araq | I write my scripts in Nim ;-) |
| 08:39:11 | gokr | So people tend to think that "there are no big systems built with dynamic languages" - and that's just plain wrong too. |
| 08:39:26 | PMunch | Oh yeah, that's not what I'm saying |
| 08:39:38 | PMunch | You could definitely write large systems with a dynamic language |
| 08:39:46 | Araq | the argument is more like "all the big system better would have built with static types" ;-) |
| 08:39:54 | PMunch | But it's easier to ensure that it's correct in a statically typed language. |
| 08:39:57 | Araq | *been built |
| 08:39:57 | gokr | Araq: Nope. |
| 08:40:51 | gokr | Just read this: http://www.cincom.com/pdf/CS040819-1.pdf |
| 08:41:07 | * | yglukhov joined #nim |
| 08:41:20 | * | zachcarter joined #nim |
| 08:43:30 | * | yglukhov quit (Remote host closed the connection) |
| 08:43:54 | gokr | I just hope the Nim community can pick more good stuff from the dynamic side - not just a GC :) And actually realize that the world is not black & white. |
| 08:44:29 | Araq | that's a nice marketing brochure |
| 08:45:03 | Araq | it contains the beliefs of successful people, but no science. |
| 08:45:06 | gokr | I know, there is more material however and I have talked to several of those developers myself. |
| 08:45:23 | Araq | it's called "computer science", we should have some science. |
| 08:45:51 | gokr | The system is still very much alive IIRC, and was built by a team of about 30 if I remember correctly. And it generated/generates HUGE amount of money. |
| 08:46:30 | gokr | And key to the success was a) very fast dev time and b) very good complex modelling capabilities and meta development. |
| 08:47:15 | gokr | Araq: Smalltalk came out of PARC you know. |
| 08:47:38 | PMunch | I've also talked to developers who swears by a static type system for much the same reasons.. That doesn't prove anything! |
| 08:48:53 | gokr | What I mean is that I have talked to the developers working on that specific system. |
| 08:49:25 | Araq | https://courses.cs.washington.edu/courses/cse590n/10au/hanenberg-oopsla2010.pdf |
| 08:51:58 | gokr | So ok, they let people write a parser (very specific domain) and they concluded no difference. And I can of course point to the Capers Jones paper etc, that showed big differences. I would argue again, it's not black & white. Sometimes it doesn't matter, sometimes it matters a lot - and in both directions. |
| 08:52:04 | * | Arrrr joined #nim |
| 08:52:04 | * | Arrrr quit (Changing host) |
| 08:52:04 | * | Arrrr joined #nim |
| 08:52:12 | gokr | But to claim a single truth here is IMHO narrow minded. |
| 08:53:17 | gokr | But hey, I gotta get back to writing dynamically typed code for pay, so, ah, professionally I guess then. |
| 08:53:45 | * | yglukhov joined #nim |
| 08:56:31 | * | couven92 left #nim ("Leaving channel") |
| 08:56:38 | * | couven92 joined #nim |
| 08:56:54 | couven92 | f*** wrong CTRL+W :P |
| 08:57:21 | couven92 | turns out that also closes channels in Nim, not just tab panes in Edge :D |
| 08:57:35 | couven92 | (err... HexChat i mean) |
| 08:59:40 | FromGitter | <zacharycarter> fyi @ftsf the spine integration with frag is optional - frag is perfectly suited for pixel art style graphics as well |
| 09:00:01 | FromGitter | <zacharycarter> I just can't do any art besides 3d art |
| 09:02:28 | FromGitter | <andreaferretti> @dom96 it seems that for the same reason, choosenim also breaks nimble! |
| 09:02:52 | FromGitter | <andreaferretti> when I run nimble, it is not able to interpret my nimble files as nimscript |
| 09:03:06 | FromGitter | <andreaferretti> because `Error: cannot open '/home/papillon/.nimble/lib/system.nim'` |
| 09:07:40 | * | dddddd joined #nim |
| 09:11:59 | Araq | gokr: actually they conclude dynamic typing makes for faster development ;-) |
| 09:12:22 | Araq | but the paper is as flawed as everything else |
| 09:13:01 | * | aziz joined #nim |
| 09:18:27 | yglukhov | dom96: so I've thought a bit more about reproducibility and came to conclusion that vendoring-in-local-folder way is likely to solve most of my issues. Besides it looks like its much easier to implement, and can decouple nim from nimble completely. |
| 09:19:10 | yglukhov | so i guess i'll just delete my repo with better nimble doc, because nimble is already really close to that. |
| 09:21:29 | FromGitter | <andreaferretti> I think that the way nimble works now is actually fine |
| 09:22:11 | FromGitter | <andreaferretti> I just would like people to avoid mentioning `nimble install` so much |
| 09:22:30 | FromGitter | <andreaferretti> many other package managers have a shared lib folder |
| 09:22:52 | yglukhov | andreaferretti: but nimble can't guarantee reproducible builds |
| 09:23:23 | * | chemist69 quit (Quit: WeeChat 1.7.1) |
| 09:23:53 | FromGitter | <andreaferretti> it just needs to store the dependencies actually used in a lock file after resolution |
| 09:23:54 | PMunch | Hmm, I've got a "type EaseFunction = proc(t:float):float" and I want to define one such function. Is there a shorter way to write it than EaseFunction(proc(t:float):float = <body>)? |
| 09:24:07 | FromGitter | <andreaferretti> there is no need to put all deps in the local folder |
| 09:24:08 | * | chemist69 joined #nim |
| 09:24:30 | FromGitter | <andreaferretti> provided nimble is able to suggest the paths correctly to nim |
| 09:24:37 | FromGitter | <andreaferretti> which it currently does |
| 09:25:04 | couven92 | PMunch, `var f: EaseFunction = proc(f: float): float = 42.42` |
| 09:25:06 | yglukhov | andreaferretti: i see a couple of reasons why local folder is better |
| 09:25:44 | couven92 | the explicit type is probably not necessary as it can be inferred... |
| 09:26:16 | couven92 | you can probably assign any matching function to an `EaseFunction` variable if you want to |
| 09:26:23 | yglukhov | andreaferretti: if you're working with dependencies that do not maintain their version tags for some reasons, nimble will have to store the dependency of a specific VCS revision. |
| 09:26:24 | PMunch | couven92, that's just as long.. And I'm putting this in a table so I've got "const easingFunctions = {Bezier.easeInQuad: EaseFunction(proc(t:float):float = t*t)}.toTable |
| 09:27:34 | yglukhov | andreaferretti: this may lead to lots of same package but different revisions in global folder. because there will be no way to track "references" to them |
| 09:27:58 | FromGitter | <andreaferretti> that makes sense *but* I'd rather push people to actually *tag* their versions |
| 09:28:00 | couven92 | PMunch, `proc foo(f: float) = 42.42 * f` and then `const x = foo`, type's inferred |
| 09:28:17 | FromGitter | <andreaferretti> this is one of the culture problems I am mentioning |
| 09:28:25 | FromGitter | <andreaferretti> it takes a second to git tag |
| 09:28:30 | FromGitter | <andreaferretti> yet nobody does it |
| 09:29:23 | FromGitter | <andreaferretti> for instance, nimx has no tags :-) |
| 09:29:28 | zachcarter | I don’t tag builds |
| 09:29:40 | yglukhov | andreaferretti: i really can't see why forcing proper versioning is still considered a good opensource practice. |
| 09:29:53 | zachcarter | but then again I don’t maintian versions either atm |
| 09:29:53 | yglukhov | andreaferretti: closed source as well |
| 09:30:15 | FromGitter | <andreaferretti> @zachcarter this creates a problem for other people |
| 09:30:25 | FromGitter | <andreaferretti> why aren't you using tags? |
| 09:30:38 | zachcarter | a couple of reasons |
| 09:30:39 | PMunch | Well, problem is that tables doesn't have a regular constructor. So "const easeFunctions: Table[Bezier,EaseFunction] = {Bezier.easeInQuad: EaseFunction(proc(t:float):float = t*t)}.toTable" will actually create an array of tuples [(Bezier.easeInQuad, EaseFunction(proc(t:float):float = t*t))] and then convert that to a table. So type inference doesn't work.. |
| 09:30:40 | FromGitter | <andreaferretti> it seems you do this intentionally, so I am trying to understand |
| 09:30:54 | zachcarter | it’s not that I do it intentionally |
| 09:31:18 | gokr | Araq: Several Smalltalkers consulted in that paper (Ungar, Hirschfeld, Haupt), from Hasso Plattner. And I agree, the conclusion was... cloudy at best. Which just reinforces my point - its not black & white. |
| 09:31:42 | zachcarter | it’s A) I don’t know when the propper time to version something is really and being quite honest I’ve never worked at a software shop that has done a great job of release management so tagging isn’t something I do at work either |
| 09:31:55 | FromGitter | <andreaferretti> I bump version and tag every few commits |
| 09:32:06 | zachcarter | B) Most of my projects haven’t reached a point I’d even like to consider alpha yet |
| 09:32:10 | zachcarter | B ) |
| 09:32:23 | FromGitter | <andreaferretti> this is even a better reason to tag more often |
| 09:32:24 | zachcarter | so I figured I’d leave them at 0.1.0 until they reach maturity |
| 09:32:26 | zachcarter | then bump the verison |
| 09:32:30 | FromGitter | <andreaferretti> if the API is not stable yet |
| 09:32:43 | FromGitter | <andreaferretti> upgrading will break client code |
| 09:32:43 | zachcarter | interesting |
| 09:32:45 | yglukhov | andreaferretti: here's a use case. your proprietary project includes a lot of proprietary subprojects. every day you do a couple of commits to many of those subprojects, a lot of those commits are coupled with updating hypothetical "nimble.lock". |
| 09:33:12 | FromGitter | <andreaferretti> so clients need to refer to a tag that actually works for them and upgrade at their own pace |
| 09:33:15 | yglukhov | andreaferretti: adding tagging procedure to this flow adds a whole lot of work. |
| 09:33:35 | FromGitter | <andreaferretti> tagging is less necessary when everything is stable |
| 09:33:36 | yglukhov | andreaferretti: first, you have to recall the last tag |
| 09:33:46 | FromGitter | <andreaferretti> `git tag` |
| 09:33:51 | FromGitter | <andreaferretti> will show you :-) |
| 09:34:07 | FromGitter | <andreaferretti> or, you know, it's written in the nimble file |
| 09:34:20 | yglukhov | andreaferretti: its just error prone, because such flow requires more manual actions |
| 09:34:21 | FromGitter | <andreaferretti> it is literally changing a line a `git tag newtag` |
| 09:34:42 | FromGitter | <andreaferretti> I can hardly think less work |
| 09:34:58 | Araq | just say "this build is known to work" and that's what nawabs does for you |
| 09:37:00 | Araq | no need for tagging, no need to keep versions accurate in a .nimble file |
| 09:37:20 | Araq | deps are project specific |
| 09:37:24 | FromGitter | <andreaferretti> I am trying nawabs right now |
| 09:37:29 | * | Vladar joined #nim |
| 09:37:41 | FromGitter | <andreaferretti> I cannot figure out how to make it work |
| 09:38:02 | FromGitter | <andreaferretti> I see that `nawabs task taskname` should run a task in a nimble file |
| 09:38:10 | FromGitter | <andreaferretti> but apparently it does nothing |
| 09:39:58 | Araq | can you be more specific? |
| 09:40:06 | Araq | worked for me :-) |
| 09:41:41 | PMunch | "const easeFunctionsArr = {Bezier.linear: EaseFunction(proc(t:float):float = t)}.toTable" is so long winded... Is there really no better way? |
| 09:42:09 | FromGitter | <andreaferretti> I will try to produce an example |
| 09:42:57 | FromGitter | <andreaferretti> for instance clone this repo https://github.com/unicredit/csvtools |
| 09:43:04 | FromGitter | <andreaferretti> then `nawabs init` |
| 09:43:07 | FromGitter | <andreaferretti> `nawabs tests` |
| 09:43:13 | FromGitter | <andreaferretti> apparently, nothing happens |
| 09:43:13 | Araq | PMunch: use a template? |
| 09:43:17 | FromGitter | <andreaferretti> `nimble tests` |
| 09:43:22 | FromGitter | <andreaferretti> something happens :-) |
| 09:43:53 | Araq | nawabs task tests |
| 09:44:04 | FromGitter | <andreaferretti> sorry, `nawabs task test` |
| 09:44:10 | FromGitter | <andreaferretti> it is named differently |
| 09:44:15 | FromGitter | <andreaferretti> yet it does nothing |
| 09:44:23 | FromGitter | <andreaferretti> `nimble test` runs tests |
| 09:44:37 | FromGitter | <andreaferretti> the same seems to happen with every repository I have tried |
| 09:48:03 | PMunch | Hmm, a template would work, if I could figure out how to write it. I tried "template easeFunction(body:untyped):untyped = EaseFunction(proc(t:float):float = body)" but when I tried to call it with "t" it just complained t wasn't initialised.. |
| 09:48:50 | Araq | task tests, "some description here": |
| 09:48:50 | Araq | echo "run the tests here" |
| 09:49:02 | Araq | nawabs tests |
| 09:49:02 | Araq | Hint: used config file '/Users/andreasrumpf-mac/projects/nim/config/nim.cfg' [Conf] |
| 09:49:02 | Araq | run the tests here |
| 09:49:08 | Araq | ^^ works for me |
| 09:49:35 | FromGitter | <andreaferretti> for me, it just prints `Hint: used config file '/Users/andreasrumpf-mac/projects/nim/config/nim.cfg' [Conf]` |
| 09:49:41 | FromGitter | <andreaferretti> but then the tests are not run |
| 09:50:30 | Araq | what do you do in your tests? |
| 09:51:06 | Araq | also, why would it print for you '/Users/andreasrumpf-mac/...' ? :P |
| 09:51:56 | FromGitter | <andreaferretti> well, you get the idea :_D |
| 09:52:04 | Araq | ok |
| 09:52:29 | FromGitter | <andreaferretti> the tests are like this |
| 09:52:30 | FromGitter | <andreaferretti> https://github.com/unicredit/csvtools/blob/master/csvtools.nimble |
| 09:56:29 | * | aziz quit (Remote host closed the connection) |
| 09:57:08 | Araq | ok, can reproduce, thanks :-) |
| 09:57:17 | Araq | you use setCommand() |
| 09:59:44 | dom96 | euantor: I think they want a credit card number which I'm not eager to give. I don't want them charging me if somebody abuses the forum and ends up sending thousands of emails. |
| 10:00:30 | yglukhov | Araq, andreaferretti, i also think that setting version in nimble file is a pita. I've already fucked up a couple of jnim release because of that. |
| 10:01:10 | dom96 | yglukhov: That's fine, if you want vendoring we can give it to you. In the spirit of making Nimble modular, it should be a separate project though. This is how it's done in cargo (https://github.com/alexcrichton/cargo-vendor). |
| 10:02:01 | dom96 | andreaferretti: Interesting. I know why that Nimble error occurs, but choosenim should have warned you about it. (unless you're still using 0.1.0) |
| 10:02:26 | dom96 | So maybe you have created a set of circumstances where it didn't warn you? |
| 10:02:43 | dom96 | What's `nimble -v` and which Nim version have you selected with choosenim? |
| 10:05:11 | dom96 | The reason nawabs doesn't work is because it contains code copied from Nimble which is broken... |
| 10:05:47 | * | Tiberium joined #nim |
| 10:05:57 | dom96 | https://github.com/Araq/nawabs/blob/master/nimscriptsupport.nim#L110 |
| 10:06:02 | dom96 | The fix is easy: https://github.com/nim-lang/nimble/blob/master/src/nimblepkg/nimscriptsupport.nim#L191 |
| 10:06:40 | dom96 | (inb4OMG_ENV_VARS, that's just a fallback because I am tired of seeing people with this error, at least now they'll be able to set an env var to work around it) |
| 10:07:37 | FromGitter | <andreaferretti> @dom96 running devel, `nimble -v` outputs `nimble v0.8.6 compiled at 2017-05-11 10:03:43` |
| 10:08:18 | FromGitter | <andreaferretti> `choosenim -v` gives `choosenim v0.2.0 (2017-05-09 17:34:41) [linux/amd64]` |
| 10:08:55 | Araq | andreaferretti: when you do setCommand("c"), tell it to do 'nawabs c' which doesn't do anything :-) |
| 10:09:00 | dom96 | that's weird. Does `nimble install` work for that package? |
| 10:09:09 | FromGitter | <andreaferretti> @Araq I see |
| 10:09:13 | euantor | dom96: Weird. I use Mailgun myself and have never given them a credit card number. I wonder if it's a new policy for new setups? |
| 10:09:22 | dom96 | euantor: what do you use it for? |
| 10:09:31 | dom96 | euantor: do you send email using them? |
| 10:09:50 | FromGitter | <andreaferretti> @Araq is there a way to tell nawabs to compile with a given ste of flags defined in nimscript, like I am doing here? |
| 10:09:52 | Araq | I think we need to move away from setCommand to nimexec("c foo") |
| 10:09:54 | euantor | Also, did you follow the instructions to enable NoScript support for recaptcha? https://developers.google.com/recaptcha/docs/faq#does-recaptcha-support-users-that-dont-have-javascript-enabled |
| 10:10:11 | FromGitter | <andreaferretti> nimexec breaks building flags with functions etc |
| 10:10:15 | euantor | dom96: Yeah, I send email from a forum using their SMTP system. Have been for about a year and a half |
| 10:10:22 | FromGitter | <andreaferretti> much better to treat flags as actual values |
| 10:10:27 | FromGitter | <andreaferretti> not as an opaque string |
| 10:10:37 | Araq | andreaferretti: agreed, will think of a solution |
| 10:10:45 | FromGitter | <andreaferretti> thanks! |
| 10:10:54 | Araq | that said, I think it doesn't work correctly with nimble either |
| 10:11:25 | FromGitter | <andreaferretti> @dom96 no, `nimble install` fails with the same error |
| 10:11:45 | FromGitter | <andreaferretti> by the way, it happens with every single nimble file I have tried |
| 10:11:53 | Araq | dom96: it's not broken, NIM_LIB_PREFIX is not documented anywhere, you choose to introduce another can of worms |
| 10:11:55 | FromGitter | <andreaferretti> it is not specific of a particular file |
| 10:12:21 | dom96 | andreaferretti: Do you have a ~/.nimble/lib folder? |
| 10:12:58 | FromGitter | <andreaferretti> I do |
| 10:13:08 | dom96 | Where did it come from? |
| 10:14:31 | dom96 | Araq: It is documented in Nimble's readme |
| 10:14:52 | FromGitter | <andreaferretti> it contains libRMath.so |
| 10:15:05 | FromGitter | <andreaferretti> I am trying to figure out how it did end up there |
| 10:15:18 | FromGitter | <andreaferretti> I think some library tried to vendor a c dependency |
| 10:15:25 | FromGitter | <andreaferretti> by compiling it there |
| 10:15:47 | dom96 | hah |
| 10:15:53 | dom96 | Amazing. |
| 10:16:17 | dom96 | I need to make my check stricter I suppose. |
| 10:16:44 | FromGitter | <andreaferretti> well, I can delete the directory anyway |
| 10:16:50 | FromGitter | <andreaferretti> if this will help |
| 10:16:55 | FromGitter | <andreaferretti> I am not using the library |
| 10:17:02 | dom96 | It will, but who knows how many more will be affected by this. |
| 10:17:08 | dom96 | It would be good to figure out what creates this. |
| 10:17:21 | FromGitter | <andreaferretti> great, that worked! |
| 10:17:41 | FromGitter | <andreaferretti> I am mentioning this in the issue |
| 10:17:50 | dom96 | thanks |
| 10:17:55 | FromGitter | <andreaferretti> (I can close it or leave it open, as you prefer) |
| 10:18:31 | dom96 | Maybe I should just have choosenim detects this |
| 10:19:08 | dom96 | or release a new nimble that checks for lib/system.nim |
| 10:19:45 | dom96 | But then I worry about that file moving. |
| 10:20:25 | yglukhov | dom96: are you saying that its better to keep all dependencies global? |
| 10:22:20 | dom96 | I'm saying it's better to implement lock files. |
| 10:22:32 | dom96 | But I am willing to offer both options. |
| 10:23:35 | yglukhov | yglukhov: lockfiles i agree 100%, but where do you want to keep the dependency tree built from lockfile? |
| 10:24:35 | FromGitter | <andreaferretti> there is no need to materialize the tree |
| 10:24:43 | FromGitter | <andreaferretti> the actual dependencies can be global |
| 10:25:01 | FromGitter | <andreaferretti> and nimble can choose the relevant paths using the lock file |
| 10:25:11 | FromGitter | <andreaferretti> this way, deps will be shared |
| 10:25:47 | dom96 | yeah, that sounds right. |
| 10:25:50 | yglukhov | andreaferretti: in such case the non-tagging approach would likely litter the global folder |
| 10:26:17 | dom96 | Oh right, I also believe that versions should be tagged. |
| 10:26:51 | yglukhov | dom96: have you read about my use-case? |
| 10:27:29 | yglukhov | and the about my jnim pita? |
| 10:28:31 | yglukhov | and again, why create artificial limitations when the software can solve the underlying problem automagically |
| 10:28:42 | dom96 | I don't really understand the jnim pita, but yes, I understand the use case you described. |
| 10:29:25 | yglukhov | dom96: the jnim pita is that i've done a couple of releases on github without bumping the version in nimble file |
| 10:29:41 | dom96 | Because the more magical something is, the more prone it is to situations where you have no idea what the hell it is doing. |
| 10:29:44 | euantor | Oh yeah, I've done that too |
| 10:30:16 | dom96 | So your solution is to get rid of versions completely? |
| 10:30:21 | yglukhov | dom96: that statement is from some java world =)) |
| 10:30:43 | yglukhov | dom96: my solution is to make versioning/tagging completely optional. |
| 10:32:08 | yglukhov | dom96: version conflict resolving should be done automatically in favor of the constraint defined in the root package, or fail if the root package is not aware |
| 10:32:41 | yglukhov | thats it, in such way the root package will always be able to take control of the dependency tree, if it wants to |
| 10:33:27 | dom96 | okay, but that's just describing how lock files could operate. |
| 10:33:49 | yglukhov | yup |
| 10:33:57 | yglukhov | do you see any more issues? |
| 10:34:19 | dom96 | I think we all should read up on how other package managers solve this, especially cargo since it's revered as "the best". |
| 10:34:33 | yglukhov | yeah, done already |
| 10:34:37 | yglukhov | a couple of times |
| 10:35:00 | dom96 | Okay, I still haven't, so I don't really have a concrete answer as to how this should be solved. |
| 10:35:11 | dom96 | What did you learn from Cargo? |
| 10:35:20 | euantor | Yeah, from what I've used of Cargo it seems very solid and well designed |
| 10:36:57 | dom96 | I'm fairly sure that Cargo doesn't vendor packages by default. |
| 10:36:59 | yglukhov | dom96: it allows a cool way of specifying dependency origin/version. |
| 10:37:26 | yglukhov | dom96: the origin may be git and hg besides cargo registry |
| 10:37:52 | dom96 | Are you aware that Nimble offers the same thing? :) |
| 10:38:28 | yglukhov | dom96: version can be specific revision/tag, or branch, in which case lockfile will be updated accordingly with the tip of the branch. |
| 10:38:58 | yglukhov | dom96: yes, but revision spec in nimble is a bit flaky |
| 10:39:13 | dom96 | how so? |
| 10:40:12 | yglukhov | dom96: well, i guess the problem is that lockfiles are not implemented yet. otherwise, its pretty ok. |
| 10:40:19 | dom96 | ahh :) |
| 10:40:46 | dom96 | Right, but what about the issues we are arguing about here, how does cargo handle them? |
| 10:41:01 | yglukhov | dom96: cargo allows local overrides, but that i'm now solving by modifying nim.cfg |
| 10:41:18 | * | yaiyan joined #nim |
| 10:41:24 | yglukhov | cargo allows target specific dependencies. |
| 10:41:43 | dom96 | The first one is also on Nimble's roadmap |
| 10:42:10 | dom96 | but will have to be integrated with lock files anyway |
| 10:42:14 | yglukhov | cargo allows dev specific dependencies, which are checked out only for the "root" package. like some unittesting libs or smth |
| 10:42:30 | * | yaiyan is now known as Ieuan |
| 10:42:33 | euantor | Yeah, Cargo doesn't vendor packages which I'm well aware of, but they have good lock files :) They also allow you to have subpackages within one repository I believe |
| 10:42:33 | dom96 | not sure what you mean by "target specific", like OS specific? |
| 10:42:38 | yglukhov | dom96: overrides should bypass the lockfile i think |
| 10:42:52 | yglukhov | dom96: yep, os/arch |
| 10:43:10 | dom96 | Pretty sure we have those too |
| 10:43:32 | yglukhov | unfortunately, no, and it is not that easy to implement. |
| 10:43:37 | dom96 | dev specific deps are also on my roadmap (at least in my brain :)) |
| 10:43:57 | yglukhov | because target is not the one which you are sitting on, but the one, for which you are building |
| 10:43:59 | dom96 | no? Is it not just a case of: when defined(windows): requires "winlean" ? |
| 10:45:00 | yglukhov | cargo allows passing options "features" to dependency configs |
| 10:45:04 | dom96 | hrm, that's true, Nimble doesn't support cross-compilation yet. |
| 10:45:38 | dom96 | euantor: yeah, I like that too. I may relax Nimble's "one-nimble package per repo" policy |
| 10:46:16 | dom96 | But once again, Cargo doesn't vendor packages, and that is what we should be discussing. |
| 10:46:27 | dom96 | There are many features that Cargo implements which Nimble doesn't (yet) |
| 10:46:50 | dom96 | (Sorry, if Mozilla was paying me and a couple other people then maybe we would have those features) |
| 10:46:58 | yglukhov | dom96: maybe i should clarify what i mean by vendoring |
| 10:47:18 | dom96 | brb, need to walk the dog :) |
| 10:47:30 | euantor | dom96: btw, sorry if I caused you headaches by mentioning vendoring on the forum :P |
| 10:47:51 | euantor | Not sure if anybody else was talking about it before I mentioned it might be nice to have |
| 10:52:13 | yglukhov | euantor: does vendoring mean that the dependencies are all located in a local-to-proj subfolder? |
| 10:52:23 | euantor | yes |
| 10:52:42 | euantor | Such as COmposer for PHP or npm for node.js |
| 10:53:00 | yglukhov | yglukhov: do you know how cargo works? |
| 10:53:09 | euantor | Where you have project specific dependencies at project level, with the option to install packages globally (usually used for binaries) |
| 10:55:21 | euantor | Though Nimble's global directory structure solves the problem that vendoring solves elsewhere. In Composer and NPM and Go, all packages go into one folder regardless of version. For instance, both euantorano/sysrandom-1.0.0 and euantorano/sysrandom-1.0.1 end up in ./packages/euantorano/sysrandom, with the most recently installed one overwriting the existing |
| 10:55:21 | euantor | one. n Nimble, versions are appended to package names in the directory structure which helps |
| 10:59:27 | yglukhov | i cant find any info about where cargo stores packages |
| 11:01:25 | euantor | I'd guess it's in the $HOME/.cargo directory, but I don't have Rust installed on my machine here at work |
| 11:02:06 | euantor | http://doc.crates.io/environment-variables.html |
| 11:02:23 | * | Snircle joined #nim |
| 11:02:26 | euantor | Yeah, it's based upon a CARGO_HOME environment variable |
| 11:02:53 | Araq | dom96: that's in a nutshell the whole problem with your way of thinking. everything has to be like Rust ignoring the fact we don't have the resources to do what they do. and when I say "ok, we're not like Rust, we can get away with something much simpler (like nawabs)" it's considered heresy. |
| 11:04:51 | Araq | at the same time even Cargo wouldn't address my pain points. |
| 11:04:55 | * | Syneh_ quit () |
| 11:05:10 | * | Syneh_ joined #nim |
| 11:06:53 | dom96 | back |
| 11:07:24 | couven92 | what do we think about NuGet? you can specify one or more feed adresses from which you get you packages and they are stored together with the package name and version number in their directory names |
| 11:08:29 | PMunch | http://ix.io/to4 Any idea what this is? |
| 11:09:01 | couven92 | PMunch, it's a stack trace from the Nim compiler :P |
| 11:09:10 | PMunch | Yeah, no shit.. |
| 11:09:14 | euantor | I use NuGet at work and it's pretty nice |
| 11:09:59 | PMunch | Atom doesn't complain about anything, but when I compile the code it complains about an internal error. |
| 11:10:26 | dom96 | yglukhov: here is what ~/.cargo contains on my machine https://gist.github.com/dom96/5a046d3292eb936a56bba174d32607ab |
| 11:11:17 | dom96 | Indeed, packages are inside pkgName-ver directories. |
| 11:11:38 | dom96 | So we must be doing something right :) |
| 11:12:20 | * | Matthias247 joined #nim |
| 11:12:48 | dom96 | So about email, it seems that Google Apps might be the best option. |
| 11:12:55 | dom96 | Anyone have any better alternatives to mailgun? |
| 11:14:22 | euantor | https://aws.amazon.com/ses/ |
| 11:15:52 | PMunch | Apparently it's this bug: https://github.com/nim-lang/Nim/issues/5015 so changing my const to a let works fine.. |
| 11:15:54 | euantor | SES also allows receiving an email, and running a lambda function against it that could, for example, create a post/topic from an email |
| 11:17:05 | dom96 | I have similar reservations about Amazon's services as I do about Mailgun |
| 11:17:12 | dom96 | They are not really upfront about the cost. |
| 11:17:24 | euantor | yeah, you'd need to have rate limiting in place |
| 11:17:29 | dom96 | It's always "oh, if you exceed this many we will start charging" |
| 11:17:55 | euantor | I can't remember if Google Apps has a limit on emails/day or not |
| 11:18:59 | dom96 | looks like it's per user per month |
| 11:19:00 | dom96 | but ugh |
| 11:21:18 | dom96 | it seems that zoho is free |
| 11:21:46 | PMunch | Unfortunately an e-mail server is about the only thing we're not allowed to set up in our University server room. Otherwise I could've probably set something up for you there dom96 :( |
| 11:22:18 | dom96 | I'm wondering whether I should just set up postfix |
| 11:22:53 | euantor | If you're setting up a local one, make sure to do it properly with DKIM and SPF and everything |
| 11:23:08 | euantor | It's very easy to get a self hosted server blacklisted, and very difficult to reverse that |
| 11:27:06 | dom96 | Hrm, maybe i'll try this https://github.com/atech/postal/ |
| 11:27:16 | euantor | I've used this before: https://mailinabox.email/ |
| 11:27:49 | yglukhov | dom96: thats interesting. i wonder what cargo does about git-branch-originated packages |
| 11:28:03 | yglukhov | does it store them in the global dir as well? |
| 11:28:20 | dom96 | yglukhov: not sure |
| 11:29:57 | yglukhov | dom96: i don't really mind to store them in the global dir. deleting the dir from time to time and redownloading everything looks like although hacky but practical solution. |
| 11:31:19 | yglukhov | dom96: however i think it could be an external option to nimble about where to store the dependencies. either local or global. also it would be nice to set global dir in env var for build machines usecase, so that dependencies are stored in the build machine cache |
| 11:34:15 | * | adeohluwa joined #nim |
| 11:34:52 | dom96 | yglukhov: I'm happy with an env var, but you'll need to convince Araq too. |
| 11:41:10 | * | matkuki joined #nim |
| 11:46:05 | * | Tiberium quit (Remote host closed the connection) |
| 11:46:43 | * | Tiberium joined #nim |
| 11:58:43 | * | Tiberium quit (Remote host closed the connection) |
| 11:59:01 | * | Tiberium joined #nim |
| 11:59:02 | * | Tiberium_ joined #nim |
| 11:59:28 | * | user0 joined #nim |
| 12:03:39 | * | zachcarter quit (Quit: zachcarter) |
| 12:06:29 | * | vlad1777d joined #nim |
| 12:12:06 | FromGitter | <nortiero> Pardon me, I came here for another reason, but I see you are talking about nimble... one pain point (for me) is that tags may refer to completely different packages, with different contents: example: glfw 0.2.1 vs glfw 3.2.0. Am I wrong to think that this makes .nimble dependancies a bit flaky? |
| 12:13:43 | * | Tiberium_ quit (Quit: Leaving) |
| 12:14:17 | dom96 | hey nortiero, is that because there are two different packages with the same name? (glfw) |
| 12:15:05 | FromGitter | <nortiero> yes, package name is the same |
| 12:17:23 | * | Tiberium quit (Remote host closed the connection) |
| 12:17:40 | * | Tiberium joined #nim |
| 12:17:41 | * | Tiberium_ joined #nim |
| 12:17:48 | FromGitter | <nortiero> ok now I understand. It just happens that package name == tag name, and there are two packages with the same name, albeit different contents. |
| 12:18:24 | dom96 | no, unless 'tag' means something else to you |
| 12:18:28 | dom96 | the 'tag' is the version |
| 12:18:43 | dom96 | how can that be the same as the package name? |
| 12:19:33 | dom96 | But yes, this is a problem. |
| 12:19:38 | FromGitter | <nortiero> This is what I see: ⏎ nim-glfw: ⏎ url: https://github.com/EXetoC/nim-glfw/ (git) ⏎ tags: library, glfw, opengl, windowing, game [https://gitter.im/nim-lang/Nim?at=591456deac693c532ae172da] |
| 12:20:00 | * | Tiberium quit (Remote host closed the connection) |
| 12:20:00 | * | Tiberium_ quit (Remote host closed the connection) |
| 12:20:01 | * | rokups joined #nim |
| 12:20:04 | FromGitter | <nortiero> i was referring to tags as in "nimble search glfw" |
| 12:20:17 | * | 32NAAKZLC joined #nim |
| 12:20:17 | * | 18VAA5IDG joined #nim |
| 12:20:18 | * | Tiberium_ joined #nim |
| 12:20:24 | dom96 | I see. |
| 12:20:43 | dom96 | Why is that a problem? |
| 12:22:44 | FromGitter | <nortiero> No serious problem, I was under the impression that "install" took a tag instead of a package name, leading to ambiguities. That was not, just bad luck by my side, because there are two package with the same name. |
| 12:23:10 | * | 32NAAKZLC quit (Remote host closed the connection) |
| 12:23:10 | * | Tiberium_ quit (Remote host closed the connection) |
| 12:23:10 | * | 18VAA5IDG quit (Remote host closed the connection) |
| 12:24:05 | * | Tiberium joined #nim |
| 12:25:19 | * | Tiberium quit (Remote host closed the connection) |
| 12:25:37 | dom96 | Ahh, ok. |
| 12:25:46 | * | Tiberium joined #nim |
| 12:29:58 | * | Tiberium quit (Remote host closed the connection) |
| 12:30:19 | * | Tiberium joined #nim |
| 12:32:00 | FromGitter | <nortiero> Just another question -- I'm playing with nim features -- why this compiles and runs: ⏎ ⏎ template wat(): var typed = 12 ⏎ echo wat() [https://gitter.im/nim-lang/Nim?at=591459c32b926f8a67447d36] |
| 12:35:42 | * | chemist69 quit (Ping timeout: 264 seconds) |
| 12:37:29 | * | Trustable joined #nim |
| 12:39:00 | FromGitter | <nortiero> It has no consequences, just a syntax issue if I'm not mistaken. Unfortunately I have not enough experience to check under the bonnet |
| 12:40:12 | * | chemist69 joined #nim |
| 12:41:35 | * | Tiberium quit (Quit: Leaving) |
| 12:47:15 | * | Tiberium joined #nim |
| 12:49:27 | * | user0 quit (Quit: user0) |
| 12:54:42 | * | zachcarter joined #nim |
| 12:58:33 | * | Serenitor joined #nim |
| 12:58:54 | * | gokr quit (Ping timeout: 240 seconds) |
| 12:59:32 | Serenitor | type color = tuple[r, g, b, a: uint8] |
| 12:59:32 | Serenitor | var c: color = (255, 255, 255, 255) |
| 12:59:32 | Serenitor | # Error: type mismatch: got ((int, int, int, int)) |
| 12:59:32 | Serenitor | # but expected 'color = tuple[r: uint8, g: uint8, b: uint8, a: uint8] |
| 12:59:32 | Serenitor | is there a way for nim to derive the correct int types from the int literals? |
| 13:01:17 | euantor | yes, use `255'u8` |
| 13:01:40 | euantor | The `u8` means that the literal is a unit8, you can do `i8`, `i16`, etc. too |
| 13:02:03 | euantor | In an array context you only need to use the suffix for the first value, but I don't think that applies to a tuple |
| 13:03:32 | * | gokr joined #nim |
| 13:06:36 | Serenitor | ah, that's at least a bit shorter than |
| 13:06:36 | Serenitor | (255.uint8, 255.uint8, 255.uint8, 255.uint8).. |
| 13:06:36 | Serenitor | but there isn't something akin to color(255, 255, 255, 255) for tuples I guess? |
| 13:11:39 | Serenitor | anyways, thanks euantor |
| 13:16:26 | * | Arrrr quit (Quit: Leaving.) |
| 13:17:23 | PMunch | var c = color(255,255,255,255) |
| 13:18:07 | yglukhov | dom96: how do env vars relate to Araq? that would be solely nimble's feature, wouldnt it? |
| 13:18:53 | Araq | reproducible builds that depend on env vars cannot be taken seriously. |
| 13:19:10 | dom96 | yglukhov: nim needs to be aware of it too, unless you do not wish 'nim' to be aware of your packages at all. |
| 13:20:42 | PMunch | Serenitor, something like this works: http://ix.io/toA |
| 13:21:03 | gokr | dom96: I signed up for Sparkzone now recently when I set up a discourse installation. No idea how good it is, but it was recommended first by discourse. 10k free/month IIRC. |
| 13:22:19 | gokr | dom96: Sparkpost I mean. |
| 13:22:54 | dom96 | hrm, looks good, but I already set up postfix :) |
| 13:26:34 | dom96 | lol, SpamAssassin check: "ham" |
| 13:32:25 | * | Tiberium quit (Remote host closed the connection) |
| 13:33:41 | * | Tiberium joined #nim |
| 13:35:07 | dom96 | woop. Email works! |
| 13:35:27 | Araq | andreaferretti: fixed nawabs, but setCommand() is really a bad idea -.- |
| 13:35:51 | Araq | we should deprecate it and make a better nimexec() |
| 13:40:35 | * | adeohluwa quit (Quit: Connection closed for inactivity) |
| 13:42:12 | * | PMunch quit (Quit: leaving) |
| 13:43:38 | * | ftsf_ joined #nim |
| 13:48:35 | * | ftsf_ quit (Ping timeout: 240 seconds) |
| 13:51:11 | FromGitter | <andreaferretti> thank you! |
| 13:55:13 | FromGitter | <andreaferretti> now it works, although it does not handle the `--run` flag |
| 13:55:18 | FromGitter | <andreaferretti> I am not sure about other flags |
| 13:55:31 | FromGitter | <andreaferretti> and it still conflicts with choosenim :-P |
| 14:08:00 | * | pie_ joined #nim |
| 14:08:15 | Araq | --define: foo and see whether test.nim picks that up for nimble |
| 14:08:51 | Araq | --run setCommand("c") is a bad hack that never was supported IMO. |
| 14:10:04 | Araq | nimsuggest also conflicts with choosenim, *shrug* so don't use choosenim |
| 14:11:01 | * | rauss joined #nim |
| 14:11:04 | FromGitter | <Varriount> *or* improve choosenim |
| 14:13:36 | * | pie_ quit (Quit: Leaving) |
| 14:13:58 | * | pie_ joined #nim |
| 14:14:24 | dom96 | Suggestions on how to improve it are welcome |
| 14:14:33 | dom96 | Also I'm pretty sure nimsuggest works |
| 14:19:55 | * | BennyElg quit (Remote host closed the connection) |
| 14:20:09 | * | BennyElg joined #nim |
| 14:20:47 | * | BennyElg quit (Remote host closed the connection) |
| 14:21:14 | * | BennyElg joined #nim |
| 14:25:13 | * | BennyElg quit (Ping timeout: 240 seconds) |
| 14:28:47 | FromGitter | <andreaferretti> @dom96 I confirm it: nimsuggest does not work with choosenim |
| 14:28:52 | FromGitter | <andreaferretti> I just tried to check this |
| 14:29:22 | FromGitter | <andreaferretti> I can easily switch from manually installed nim to choosenim by adding a variable to the $PATH |
| 14:29:40 | FromGitter | <andreaferretti> and I tried to edit the same file in vscode and atom |
| 14:29:59 | FromGitter | <andreaferretti> when using manually installed nim, nimsuggest worked, but not with choosenim |
| 14:30:08 | * | matkuki quit (Quit: ChatZilla 0.9.93 [Firefox 52.1.1/20170504112025]) |
| 14:30:18 | dom96 | ahh, it's using the same code for finding the stdlib https://github.com/nim-lang/Nim/blob/devel/nimsuggest/nimsuggest.nim#L593 |
| 14:30:46 | FromGitter | <andreaferretti> a simple alternative would be for choosenim to just change the $PATH |
| 14:31:17 | FromGitter | <andreaferretti> uhm , on a second thought this would not work easily outside of a shell |
| 14:31:37 | FromGitter | <andreaferretti> nvm works this way |
| 14:31:51 | FromGitter | <andreaferretti> you just `nvm use someversion` and it alters ENV variables |
| 14:31:56 | FromGitter | <andreaferretti> and then you start working |
| 14:32:22 | dom96 | So I have to type that in at the start of every session? |
| 14:33:05 | FromGitter | <andreaferretti> yes |
| 14:33:19 | FromGitter | <andreaferretti> or put that in .bashrc or whatever |
| 14:33:25 | dom96 | I don't want to have to do that. |
| 14:33:42 | FromGitter | <andreaferretti> yeah, this would be a problem especially for nimsuggest |
| 14:34:07 | * | Trioxin2 joined #nim |
| 14:34:32 | FromGitter | <andreaferretti> if `findExe` follows symlinks |
| 14:34:43 | FromGitter | <andreaferretti> another solution would be to symlink instead of copy |
| 14:35:06 | FromGitter | <andreaferretti> I am not sure whether windows filesystem eventually got symlinks |
| 14:35:19 | dom96 | Symlinks is an option, but indeed Windows doesn't support them |
| 14:35:20 | FromGitter | <andreaferretti> but on Linux and OSX that would work |
| 14:35:50 | FromGitter | <andreaferretti> in fact, nim-vm used symlinks |
| 14:36:12 | demi- | i would strongly oppose a tool changing my PATH on me |
| 14:37:39 | * | Trioxin quit (Ping timeout: 272 seconds) |
| 14:38:32 | Araq | findExe does follow symlinks. |
| 14:39:19 | dom96 | I don't see the problem in fixing Nimsuggest and nawabs. |
| 14:40:08 | Araq | I don't see what's there to fix. choosenim introduced its own way of installing everything. |
| 14:40:16 | Araq | so fix it. |
| 14:40:52 | dom96 | I showed what needs to be fixed and how. |
| 14:43:16 | dom96 | Symlinks are not cross platform so I cannot use them. |
| 14:43:59 | * | chemist69 quit (Ping timeout: 272 seconds) |
| 14:44:47 | Araq | so what's the fix? use yet another env var? that choosenim cannot set anyway because it cannot set the path either? |
| 14:45:45 | dom96 | check if the prefix dir is correct, if not fallback to Nim's default prefix dir. |
| 14:46:02 | Araq | what's the default prefix dir? |
| 14:46:18 | dom96 | https://github.com/nim-lang/nimble/blob/master/src/nimblepkg/nimscriptsupport.nim#L191 |
| 14:46:37 | * | PMunch joined #nim |
| 14:48:25 | Araq | ok then. |
| 14:51:57 | dom96 | okay, great |
| 14:53:08 | dom96 | bbl |
| 14:56:24 | Araq | andreaferretti, please try again |
| 14:58:41 | * | rokups quit (Quit: Connection closed for inactivity) |
| 14:59:06 | * | jsgrant_om quit (Quit: Peace Peeps. o/ If you need me asap, message me at msg(at)jsgrant.io & I'll try to get back to you within 24 hours.) |
| 15:10:26 | * | chemist69 joined #nim |
| 15:13:19 | FromGitter | <andreaferretti> @Araq I just tried: nimsuggest works fine but nawabs still shows the same issue |
| 15:13:39 | Araq | well nawabs needs to be in nim/bin or something |
| 15:14:25 | Araq | dunno why choosenim cannot keep the ./bin/{nim, nimsuggest} ./lib layout intact |
| 15:14:50 | FromGitter | <andreaferretti> ah ok |
| 15:15:14 | FromGitter | <andreaferretti> well, if it is just for the lib I think it would be possible to copy that as well |
| 15:15:24 | * | rauss quit (Ping timeout: 240 seconds) |
| 15:15:46 | FromGitter | <andreaferretti> (if it was for me, I'd just go for symlinks, but I understand some people are interested in keeping windows support :-P) |
| 15:16:21 | Araq | I dunno if only 'lib' is affected, people usually demand 'koch web' to work |
| 15:16:25 | * | rauss joined #nim |
| 15:17:02 | Araq | Nim's way of doing things is beautiful, you can have as many versions of Nim as you want, everything uses relative paths |
| 15:17:46 | FromGitter | <andreaferretti> well, the only issue is a convenient way to actually have as many versions of Nim as you want |
| 15:18:42 | Araq | it's convenient, you change the PATH. |
| 15:19:08 | FromGitter | <andreaferretti> yeah, this is what I am doing so far |
| 15:19:38 | FromGitter | <andreaferretti> still, a little bit of automation would help |
| 15:19:41 | FromGitter | <andreaferretti> nowadays with `koch tools` it is just a small bash script with symlinks away... |
| 15:19:59 | FromGitter | <andreaferretti> it used to be more inconvenient before `koch tools` |
| 15:20:06 | * | rauss quit (Client Quit) |
| 15:20:24 | * | rauss joined #nim |
| 15:21:47 | Araq | on Windows finish.nim can modify the path for you ;-) |
| 15:22:32 | Araq | because it has an API for that. On UNIX you try to write a program that modifies .bashrc, lol |
| 15:28:12 | PMunch | Or put one symlink file in your path and then change that.. |
| 15:29:43 | PMunch | Or you could do it the busybox way, it bundles a lot of programs into one executable and then reads the 0th parameter to decide which one to run |
| 15:31:24 | dom96 | choosenim doesn't install nawabs |
| 15:31:39 | PMunch | So you create one symlink for each of your nim versions in a regular install directory (like /usr/bin, or /opt) which all link to one executable. Then this executable reads the 0th argument it is called with and runs that copy of Nim. To set a default it would have a tiny config file so that whenever it is called with just nim as it's 0th argument it reads that config and runs the correct version. |
| 15:31:43 | Araq | dom96: it changed the way Nim is installed |
| 15:32:30 | dom96 | it changed the way Nim is executed |
| 15:32:34 | dom96 | It's still installed the same way |
| 15:38:04 | * | pie_ quit (Quit: Leaving) |
| 15:40:00 | dom96 | But once again, I am open to suggestions on how to do it differently. |
| 15:40:40 | Araq | dom96: I already fixed it. |
| 15:40:49 | dom96 | nawabs still fails though |
| 15:41:59 | dom96 | but that's presumably because it's not inside bin/nim.exe |
| 15:42:07 | dom96 | s/inside/beside/ |
| 15:42:11 | Araq | yeah, can live with that |
| 15:42:23 | Tiberium | Araq, thanks for the fix with choosenim! this issue https://github.com/nim-lang/nimsuggest/issues/61 seems to be fixed |
| 15:42:42 | Tiberium | ah, no |
| 15:42:48 | Tiberium | ah, yes, it is fixed :) |
| 15:42:54 | Tiberium | maybe by another commit, but still |
| 15:43:09 | dom96 | okay, great |
| 15:48:58 | * | Arrrr joined #nim |
| 15:53:56 | * | couven92 quit (Quit: Client disconnecting) |
| 15:54:05 | * | Jesin quit (Quit: Leaving) |
| 15:58:56 | * | PMunch quit (Quit: leaving) |
| 16:02:11 | * | jsgrant_om joined #nim |
| 16:05:53 | * | Serenit0r joined #nim |
| 16:08:34 | * | Serenitor quit (Ping timeout: 255 seconds) |
| 16:13:04 | FromGitter | <andreaferretti> @Araq I tried writing a few lines of bash for my use case using symlinks |
| 16:13:14 | FromGitter | <andreaferretti> turns out, findExe follows symlinks |
| 16:13:20 | FromGitter | <andreaferretti> but does not resolve them |
| 16:13:47 | FromGitter | <andreaferretti> by which I mean - if it does find a nim binary following symlinks |
| 16:14:03 | FromGitter | <andreaferretti> it returns the unresolved path |
| 16:14:17 | FromGitter | <andreaferretti> so, going back and looking for lib does not work |
| 16:15:12 | FromGitter | <andreaferretti> anyway, here is my shell script in all its glory https://gist.github.com/andreaferretti/d40af6a276fb3275d97d0f9585d8197e :-P |
| 16:15:52 | FromGitter | <andreaferretti> it should allow to quickly swtich between versions, list versions and update devel |
| 16:16:07 | FromGitter | <andreaferretti> but, alas, it has the same problem of choosenim |
| 16:18:15 | FromGitter | <ephja> This generates an ICE depending on the order in which these definitions appear ⏎ ⏎ ```type ⏎ T[N] = proc(p: U[int]) ⏎ U[N] = object``` ⏎ ⏎ has this been reported? I recall seeing a bug report related to type ordering [https://gitter.im/nim-lang/Nim?at=59148eca631b8e4e61c6904e] |
| 16:24:44 | * | chrisheller quit (Remote host closed the connection) |
| 16:27:32 | * | arnetheduck quit (Ping timeout: 240 seconds) |
| 16:27:40 | FromGitter | <ephja> https://gist.github.com/ephja/2826c34408a092dd413a830b4e87ce4b |
| 16:31:21 | * | couven92 joined #nim |
| 16:37:04 | * | brson joined #nim |
| 16:48:37 | * | chemist69 quit (Ping timeout: 255 seconds) |
| 16:49:00 | * | chemist69 joined #nim |
| 17:16:15 | * | libman joined #nim |
| 17:16:50 | Araq | ephja, please report it anyway |
| 17:24:32 | FromGitter | <maiermic> I'm still trying to figure out what causes this (http://stackoverflow.com/questions/43855621/conflicting-types-when-compiling-nim-and-sdl2-image-with-emscripten) issue |
| 17:25:17 | FromGitter | <maiermic> I guess it is a bug of the sdl module |
| 17:27:44 | * | yglukhov quit (Remote host closed the connection) |
| 17:31:34 | libman | How long is my forum banishment? I am contractually obligated to bump my web frameworks thread about the new round at https://www.techempower.com/benchmarks/ ;-) |
| 17:32:59 | libman | Those who can, code. Those who can't, rant about coding - to keep the dream alive... |
| 17:41:39 | FromGitter | <Varriount> dom96 ^ |
| 17:50:47 | libman | No need to nag the gods directly. But an occasional discussion about that topic could inspire some ideas within the community: h2o<->nim bindings, for example... |
| 17:57:31 | * | nsf quit (Quit: WeeChat 1.7.1) |
| 18:01:18 | * | Jesin joined #nim |
| 18:03:33 | dom96 | Maybe a couple more days. |
| 18:03:59 | FromGitter | <Varriount> dom96: Aww, can't you be merciful? |
| 18:05:44 | FromGitter | <ephja> Araq: Yeah, I realized that they fail in different ways |
| 18:06:29 | * | SerenityStyle joined #nim |
| 18:09:21 | * | yglukhov joined #nim |
| 18:09:34 | * | Serenit0r quit (Ping timeout: 258 seconds) |
| 18:10:52 | FromGitter | <ephja> type ASTs can't yet be inspected reliably yet, right? |
| 18:11:06 | libman | No mercy. That would only encourage me. |
| 18:12:46 | FromGitter | <BontaVlad> :D |
| 18:14:15 | * | yglukhov quit (Ping timeout: 272 seconds) |
| 18:26:14 | * | yglukhov joined #nim |
| 18:28:41 | * | jsgrant_om quit (Quit: Peace Peeps. o/ If you need me asap, message me at msg(at)jsgrant.io & I'll try to get back to you within 24 hours.) |
| 18:29:25 | * | SerenityStyle quit (Ping timeout: 245 seconds) |
| 18:30:42 | * | jsgrant_om joined #nim |
| 18:34:20 | * | sz0 joined #nim |
| 18:36:30 | * | adeohluwa joined #nim |
| 18:37:30 | * | Ven joined #nim |
| 18:37:54 | * | Ven is now known as Guest80030 |
| 18:43:25 | couven92 | A C-function that takes a structure pointer as an argument should be a ptr type in the Nim proc, right? Because Nim wouldn't know how to trace the ref through the importc call? |
| 18:46:59 | * | Jesin quit (Quit: Leaving) |
| 18:49:03 | * | Jesin joined #nim |
| 18:49:04 | Araq | couven92: right |
| 18:51:53 | * | chemist69 quit (Ping timeout: 240 seconds) |
| 18:53:48 | * | vlad1777d quit (Quit: Leaving) |
| 18:54:59 | * | chemist69 joined #nim |
| 18:58:15 | zachcarter | can you use importcpp with a dynlib pragma? |
| 18:59:07 | zachcarter | not sure if that makes sense or not |
| 18:59:52 | Araq | no, you can't |
| 19:00:10 | couven92 | Araq, because of C++ name mangling? |
| 19:00:43 | couven92 | and because all DLL exports in C++ should use extern "C" to prevent that? |
| 19:00:59 | Araq | no, because it never was tested. |
| 19:01:03 | couven92 | Ah |
| 19:01:15 | zachcarter | I’m trying to do what’s being done here in D |
| 19:01:17 | zachcarter | https://github.com/olehlong/bgfx-extras-d/blob/master/source/bgfx_extras/nanovg.d#L664-L666 |
| 19:01:42 | zachcarter | that symbol’s defined in a shared library I built |
| 19:02:02 | zachcarter | in a cpp file |
| 19:02:18 | zachcarter | is there any way I can bind to it? |
| 19:02:33 | * | SerenityStyle joined #nim |
| 19:02:50 | couven92 | zachcarter, if it's properly externalized, shouldn't it be accessible by importc? |
| 19:03:06 | zachcarter | I figured it would be but when I try to use import c I get an error : |
| 19:04:50 | couven92 | zachcarter, have you marked the symbol as DLL exportable in your native library? i.e. does the compiler actually put the symbol in the export table? E.g. for C++ in Visual Studio this would be accomplished by __declspec(dllexport) |
| 19:04:54 | zachcarter | hrm interesting I mus thave done something because I’m getting very different errors now |
| 19:05:17 | zachcarter | I’ll have to check on that, I’m hoping so |
| 19:05:54 | zachcarter | https://github.com/bkaradzic/bgfx/blob/master/examples/common/nanovg/nanovg_bgfx.cpp#L1058 |
| 19:05:57 | zachcarter | it doesn’t look like it |
| 19:06:33 | couven92 | in the h file? |
| 19:07:47 | zachcarter | https://github.com/bkaradzic/bgfx/blob/master/examples/common/nanovg/nanovg_bgfx.h |
| 19:07:50 | zachcarter | doesn’t look like it either |
| 19:08:36 | couven92 | zachcarter, do you have a .def file or sth like it? |
| 19:09:15 | zachcarter | nope :/ not that I’m aware of |
| 19:09:31 | couven92 | you're using g++? |
| 19:09:54 | zachcarter | I’m on osx so clang |
| 19:12:31 | couven92 | ah, hmm... I actually just know how to do this in VCC (`__declspec(dllexport)`) and in g++ I think it's (`__attribute__((dllexport))`, so check how clang exports symbols |
| 19:14:07 | couven92 | otherwise, you could statically compile your library and use --passL:yourlib.a to nim, and use the appropiate header and importcpp pragmas |
| 19:16:00 | couven92 | Araq, how do pass a dynamically sized array pointer to an importc? Ideally I'd use sth. like `var x = newSeq[int](someNumber)` and then use `nativeFunc(addr(x), x.len)`... |
| 19:16:50 | zachcarter | thanks couven92 |
| 19:20:16 | * | Guest80030 quit (Ping timeout: 255 seconds) |
| 19:22:23 | * | Ven joined #nim |
| 19:22:47 | * | Ven is now known as Guest95275 |
| 19:26:55 | * | Guest95275 quit (Ping timeout: 245 seconds) |
| 19:27:14 | * | Arrrr quit (Quit: Leaving.) |
| 19:29:14 | * | Ven_ joined #nim |
| 19:31:12 | * | chrisheller joined #nim |
| 19:32:07 | * | Tiberium quit (Quit: Leaving) |
| 19:33:20 | FromGitter | <stisa> couven92 I think `seq`s are contiguos, so a pointer to the first element (`addr(x[0])`) should work? |
| 19:33:54 | * | Ven_ quit (Ping timeout: 240 seconds) |
| 19:35:00 | Araq | couven92: yeah what stisa says |
| 19:35:35 | couven92 | @stisa, hmm... still looks ugly, but I guess I could do: `proc asLPArray[T](s: seq[T]) = addr(s[0])` to make it prettier, right? |
| 19:35:44 | * | Ven_ joined #nim |
| 19:38:01 | * | Ven_ quit (Client Quit) |
| 19:39:56 | Araq | 1. you need to use unsafeAddr then |
| 19:40:08 | Araq | 2. don't make unsafe operations beautiful. |
| 19:40:31 | couven92 | Araq, okay... will do :P |
| 19:40:33 | Araq | cast and addr are deliberately ugly. |
| 19:41:55 | couven92 | I understand |
| 19:45:58 | * | BennyElg joined #nim |
| 19:48:26 | * | rb66 joined #nim |
| 19:50:30 | * | Serenitor joined #nim |
| 19:51:53 | * | SerenityStyle quit (Ping timeout: 240 seconds) |
| 19:56:33 | couven92 | Araq, I have some define constants in my C header... But since they all are the possible values for an integer function argument, I am tempted to do an `MyEnum {.size: sizeof(int32).} = enum`. But I got 'holes' in the range of possible values, so I should probably declare it as a `distinct int32` instead? |
| 20:01:03 | * | Ven_ joined #nim |
| 20:01:36 | Araq | yes |
| 20:02:50 | * | Ven_ quit (Client Quit) |
| 20:28:47 | * | zachcarter quit (Quit: zachcarter) |
| 20:42:50 | * | adeohluwa quit (Quit: Connection closed for inactivity) |
| 20:45:19 | * | gokr quit (Ping timeout: 255 seconds) |
| 20:48:15 | * | nsf joined #nim |
| 20:50:45 | * | Trustable quit (Remote host closed the connection) |
| 20:53:38 | * | Vladar quit (Ping timeout: 268 seconds) |
| 20:57:53 | * | chemist69 quit (Ping timeout: 240 seconds) |
| 20:58:11 | * | rauss quit (Quit: WeeChat 1.7.1) |
| 21:00:50 | * | chemist69 joined #nim |
| 21:03:38 | * | Ven joined #nim |
| 21:04:01 | * | Ven is now known as Guest14984 |
| 21:15:18 | bozaloshtsh | so jester seems to register its own handler for logger, how do I disable this? I want to use my own |
| 21:17:23 | FromGitter | <Varriount> @dom96 ^ |
| 21:18:14 | bozaloshtsh | https://github.com/dom96/jester/blob/master/jester.nim#L322 |
| 21:18:28 | bozaloshtsh | I was starting jester before registering my handler, that was the issue |
| 21:18:47 | dom96 | :) |
| 21:18:55 | dom96 | Glad you managed to find an answer on your own. |
| 21:26:51 | bozaloshtsh | are nim imports hoisted to the top? |
| 21:28:26 | bozaloshtsh | I've got jester routes in their own file and I'm importing that module after doing some other things |
| 21:28:31 | bozaloshtsh | but jester starts up before anyways |
| 21:28:41 | bozaloshtsh | @dom96 |
| 21:29:06 | dom96 | routes in a separate file are not supported by jester right now (sorry) |
| 21:29:23 | bozaloshtsh | aw |
| 21:29:39 | bozaloshtsh | I want to run an auxiliary http server, how would I go about doing that then? |
| 21:34:41 | dom96 | If you still want to use Jester you can probably do something like this: https://github.com/dom96/jester/blob/master/tests/example2.nim |
| 21:37:15 | bozaloshtsh | hmm |
| 21:37:35 | bozaloshtsh | why not make routes return that match it creates so jester.serve can be called any time? |
| 21:39:17 | dom96 | because at the time I didn't consider this possibility :) |
| 21:39:39 | bozaloshtsh | ah, that's fair |
| 21:39:57 | bozaloshtsh | well this works too, thanks |
| 21:42:16 | * | BennyElg quit (Read error: Connection reset by peer) |
| 21:42:29 | * | BennyElg joined #nim |
| 21:44:33 | * | Jesin quit (Quit: Leaving) |
| 21:49:30 | * | jsgrant_om quit (Quit: Peace Peeps. o/ If you need me asap, message me at msg(at)jsgrant.io & I'll try to get back to you within 24 hours.) |
| 21:51:14 | * | jsgrant_om joined #nim |
| 21:51:52 | * | Guest14984 quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:00:35 | * | pie_ joined #nim |
| 22:14:11 | * | zachcarter joined #nim |
| 22:15:16 | * | kunev quit (Ping timeout: 260 seconds) |
| 22:18:09 | * | kunev joined #nim |
| 22:21:38 | * | def-pri-pub joined #nim |
| 22:32:42 | * | kunev quit (Ping timeout: 240 seconds) |
| 22:34:12 | * | brson quit (Ping timeout: 240 seconds) |
| 22:51:49 | * | brson joined #nim |
| 23:05:07 | * | chemist69 quit (Ping timeout: 258 seconds) |
| 23:06:48 | * | nsf quit (Quit: WeeChat 1.7.1) |
| 23:08:15 | * | chemist69 joined #nim |
| 23:09:26 | * | couven92 quit (Quit: Client Disconnecting) |
| 23:29:00 | * | Matthias247 quit (Read error: Connection reset by peer) |