| 00:00:11 | dom96 | I think that's an important question to answer |
| 00:00:50 | FromGitter | <Willyboar> I personally likes the current system and insist that a tool like virtualenv would be a solution |
| 00:01:01 | * | zyklon quit (Ping timeout: 268 seconds) |
| 00:01:10 | dom96 | Willyboar: virtualenv? Why would we need virtualenv? |
| 00:01:22 | FromGitter | <Willyboar> not as a default |
| 00:01:50 | dom96 | we don't need virtualenv |
| 00:02:06 | dom96 | we can have multiple versions of the same library installed |
| 00:02:16 | * | zyklon joined #nim |
| 00:03:08 | * | jjido joined #nim |
| 00:03:15 | dom96 | But I also personally like the current system. The only advantage that these local deps will bring is that it will be slightly easier to modify the dependencies if you want to fix something |
| 00:04:00 | dom96 | And if that's the only problem we are solving then I am having doubts that we should solve that problem in this way. |
| 00:07:16 | shashlick | This is really a question of isolation |
| 00:07:29 | shashlick | Nothing from other projects should impact this project |
| 00:09:17 | FromGitter | <Willyboar> What languages use a similar system? Python and ruby they don't. I think node use it. |
| 00:09:46 | rayman22201 | node is the only language that uses a subcommand for this |
| 00:09:49 | rayman22201 | that I know of |
| 00:10:10 | FromGitter | <Willyboar> is this nodemodules folder? |
| 00:10:17 | rayman22201 | yeah |
| 00:10:32 | dom96 | shashlick, I know, but there is something to be concerned about and that is complexity of Nimble. This feature will touch a lot of code and I'm sure it won't end here, we'll need to adjust the way the packages are put into this deps folder and we'll get more and more special cases just for this which will make Nimble's code base really complex. |
| 00:10:35 | rayman22201 | You have a global `nodemodules` but can pass `--local` |
| 00:11:09 | rayman22201 | I don't have a preference, just giving an example for context |
| 00:12:14 | FromGitter | <Willyboar> but i think a freeze command it would be nice |
| 00:12:46 | shashlick | I have some more thoughts on this and I'll update the doc for tomorrow |
| 00:12:52 | dom96 | Anyway, 'night |
| 00:13:02 | shashlick | Gn |
| 00:13:05 | FromGitter | <Willyboar> goodnight dom |
| 00:13:11 | rayman22201 | gn |
| 00:15:25 | FromGitter | <Willyboar> anybody who can help with this issue? |
| 00:15:27 | FromGitter | <Willyboar> https://github.com/thebigbaron/pine/issues/4 |
| 00:22:02 | * | oculux quit (Quit: blah) |
| 00:25:30 | * | Vladar quit (Remote host closed the connection) |
| 00:26:09 | * | oculux joined #nim |
| 00:35:11 | Araq | there is no complexity here, you have a deps/ dir, Nimble uses it. the end. |
| 00:37:09 | * | ftsf joined #nim |
| 00:39:34 | rayman22201 | If you are still awake, I have a problem. I want to pass 'out' params for "closureRef" and "closureIterRef" into the async procs. But I have no clue what the type of a "closureRef" is, or a "closureIterRef" for that matter.... :/ |
| 00:45:36 | * | krux02_ joined #nim |
| 00:48:39 | * | krux02 quit (Ping timeout: 264 seconds) |
| 00:50:30 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 01:13:57 | FromGitter | <Varriount> If you don't know what they are, why do you need to pass parameters for them? |
| 01:14:37 | rayman22201 | Macros |
| 01:15:40 | rayman22201 | Also. Bad question. You often need types that are derived. That's why auto exists |
| 01:17:20 | * | kevin_ joined #nim |
| 01:19:21 | disruptek | shashlick: you up? |
| 01:28:20 | disruptek | offered my comments here: https://gist.github.com/genotrance/ee2ce321a56c95df2d4bb7ce4bd6b5ab#gistcomment-3072295 |
| 01:28:37 | * | kevin_ quit (Quit: leaving) |
| 01:48:26 | shashlick | hey |
| 01:48:41 | disruptek | just posted another long comment. |
| 01:48:51 | disruptek | brb |
| 01:50:10 | shashlick | no problem, thanks for taking the time |
| 01:51:46 | disruptek | aside from my comments, i think the two open issues are `develop` and what to do about binaries like toast. |
| 01:52:32 | shashlick | toast already works cause it is relative to cimport.nim |
| 01:52:39 | shashlick | which is part of the same pacakge |
| 01:52:50 | disruptek | ah, sneaky. |
| 01:53:01 | disruptek | did you bump libarchive with bump? |
| 01:53:02 | shashlick | the problem is if you refer to a binary from another package |
| 01:53:11 | shashlick | i only use bump nowadays |
| 01:53:18 | disruptek | any gotchas? |
| 01:53:21 | shashlick | who has time |
| 01:53:25 | shashlick | naah, works great |
| 01:53:54 | disruptek | i just put in a projectVersion*() that you can use to get a version for embedding in cligen's --version. |
| 01:53:55 | shashlick | did you see the chat earlier on the gist? |
| 01:54:08 | shashlick | i am thinking of localdeps to be an extension of nimble develop |
| 01:57:08 | FromDiscord | <Karl Marx> Hey can someone help me a bit |
| 01:57:08 | * | snooptek quit (Remote host closed the connection) |
| 01:57:25 | FromDiscord | <Karl Marx> I want to collect, terminal arguments and parse them into an string |
| 01:57:57 | FromDiscord | <Karl Marx> But I get this error |
| 01:57:57 | FromDiscord | <Karl Marx> https://cdn.discordapp.com/attachments/371759389889003532/640006650299940895/Screen_Shot_2019-11-01_at_7.57.43_PM.png |
| 01:58:02 | FromDiscord | <Karl Marx> How to convert a Tained String into a normal string? |
| 01:58:27 | shashlick | $ |
| 01:58:42 | FromDiscord | <Karl Marx> Where do I put the $? |
| 01:58:57 | FromDiscord | <Karl Marx> Since I read about it in the docs, but I didnt really understand it |
| 01:59:30 | shashlick | collector is a sequence of tainted strings |
| 01:59:41 | shashlick | you don't pass it to newString |
| 02:00:08 | FromDiscord | <Karl Marx> Ohhh I get it now |
| 02:00:10 | shashlick | if you want, you can use collector.join(" ") to create a string out of the sequence separated by spaces |
| 02:01:21 | FromDiscord | <Karl Marx> Since its the terminal args, how would I parse lets say, the first argument the user does like: "command [argument]" so how do I grab the [argument] part and parse it to an string? I know how to do this in rust, but I have no idea how to do this on Nim |
| 02:01:56 | shashlick | collector[0] = command |
| 02:02:09 | shashlick | collector[1 .. ^1] = arguments in a sequence |
| 02:02:39 | shashlick | so you could `collector[1 .. ^1].join(" ")` |
| 02:03:50 | * | snooptek joined #nim |
| 02:05:01 | disruptek | shashlick: sorry, wedged my ws. |
| 02:05:03 | FromDiscord | <Karl Marx> It works! Thank u |
| 02:05:04 | FromDiscord | <Karl Marx> https://cdn.discordapp.com/attachments/371759389889003532/640008438864281621/Screen_Shot_2019-11-01_at_8.04.25_PM.png |
| 02:05:27 | disruptek | local deps work for me as `nimble develop`. |
| 02:05:55 | shashlick | what's a good place to store such a spec |
| 02:06:11 | shashlick | gist sucks for editing and highlighting what changed |
| 02:06:40 | disruptek | i woulda said gist. 😀 |
| 02:06:52 | disruptek | i just wrote an ix paster. |
| 02:07:09 | shashlick | ix is a one line curl command |
| 02:07:16 | disruptek | mostly so i can have a bot send me repro's that link to the playground. |
| 02:07:24 | disruptek | curl is for pussies. |
| 02:08:55 | disruptek | what do i do about my crap code problem? |
| 02:09:52 | shashlick | each top level project should have its own deps |
| 02:09:59 | * | kevin_ joined #nim |
| 02:10:27 | shashlick | if we pull in the exact deps of deps, you can have incompatible versions together |
| 02:10:38 | shashlick | if you see how lockfiles work, they do the same thing |
| 02:10:56 | shashlick | each project has its own lockfile that isn't impacted by those of its dependencies' lockfiles |
| 02:11:50 | disruptek | yeah, but i'm talking about dogshit i wanna break out. i guess i just do it manually. |
| 02:12:38 | shashlick | that's just an answer for the first line |
| 02:12:43 | shashlick | let me understand the rest |
| 02:19:08 | shashlick | why wouldn't you put the not-yet-ready code in a subdir and refer to them with relative paths? |
| 02:19:55 | lmariscal | is ephja here? |
| 02:20:00 | disruptek | only because i want them to be modules so i can do normal git operations on them. |
| 02:20:29 | shashlick | then they are independently in git anyway |
| 02:20:47 | disruptek | yeah, i'm not sure how it works. it's an issue i have with the problem of distributions. |
| 02:21:23 | shashlick | i guess you need to put them into nimble then |
| 02:22:50 | * | ng0_ joined #nim |
| 02:24:09 | shashlick | you could do git submodules if you don't want them in nimble |
| 02:24:18 | disruptek | yep. |
| 02:24:39 | disruptek | i have to see how it feels once i start on nimph. |
| 02:24:40 | shashlick | or we can have a `requires "https://github.com/abc/def"` |
| 02:24:54 | shashlick | not sure if nimble already supports that |
| 02:24:59 | disruptek | that's what i use now. |
| 02:25:12 | disruptek | it's only the "distributions" use-case that i'm thinking about. |
| 02:25:32 | * | ng0 quit (Ping timeout: 260 seconds) |
| 02:25:35 | disruptek | if you wanna distribute some closed software with local deps, is there any way to do it? |
| 02:25:49 | disruptek | this isn't such a strange request. |
| 02:26:54 | kevin_ | 👑️ |
| 02:27:07 | disruptek | oh shoot |
| 02:27:11 | disruptek | 👑 |
| 02:27:23 | disruptek | i see your crown and raise you a crown. |
| 02:28:12 | kevin_ | I still learn how to use 👑️ |
| 02:28:33 | kevin_ | 😋️ |
| 02:28:55 | FromGitter | <Willyboar> shashlick that was one thing i hate to golang |
| 02:29:19 | FromGitter | <kaushalmodi> shasklick: nimterop 0.3.3 also works great. Many thanks! |
| 02:29:34 | shashlick | excellent, thanks for checking |
| 02:31:25 | FromGitter | <Willyboar> you have google from behind build a package hosting |
| 02:31:58 | shashlick | @disruptek - for closed source, you need binary distribution right |
| 02:32:34 | disruptek | i mean internal stuff that you might want to put in your dist. |
| 02:33:36 | shashlick | right you don't want to check it into the project and it's in a separate repo |
| 02:34:02 | disruptek | yeah. |
| 02:34:47 | disruptek | i have a lot of this stuff and putting it in a dist makes a lot of sense for reproducibility. |
| 02:35:37 | disruptek | my dists will be immutable. |
| 02:35:53 | shashlick | i don't see how nimble can help there |
| 02:36:07 | shashlick | we cannot rely on git cause nimble supports hg either |
| 02:37:00 | disruptek | i think it's fine for me, just not sure about anyone else. |
| 02:37:19 | shashlick | how would you solve the thing i said about lock files |
| 02:37:34 | shashlick | how do you decide to retain the deps vs ignoring them |
| 02:37:40 | disruptek | everything i do will be local deps. |
| 02:38:27 | * | exelotl quit (Ping timeout: 264 seconds) |
| 02:41:22 | shashlick | so this is only an issue if the project with local deps is actually a library |
| 02:42:51 | disruptek | is it? |
| 02:43:05 | shashlick | why else would you install it into ~/.nimble |
| 02:43:20 | disruptek | i mean, i have this problem now. |
| 02:44:08 | shashlick | right but if we do implement local deps as described in the gist |
| 02:44:16 | shashlick | it would solve your problem no |
| 02:44:32 | disruptek | i can't `develop` bump because it produces a binary, so i edit the file. then if i wanna install it alongside my other nimble binaries, i edit the file and `nimble install`. then i edit the file again so i can develop it. and now i've got 17 versions of bump in my ~/.nimble. |
| 02:45:00 | disruptek | if we do local deps, i won't ever use global deps. |
| 02:45:07 | disruptek | so, yeah, all my problems are solved. |
| 02:45:32 | disruptek | except for editing my $PATH 😀 |
| 02:46:01 | disruptek | i actually just symlink from my ~/bin directly to my devel bump, but don't let Araq hear me say that. |
| 02:46:53 | shashlick | ya it would be nice if nimble supported binaries for `nimble develop` |
| 02:47:27 | disruptek | anyway, i'm hopeful we can get the compiler patched and move forward on this. it'll help a lot of people, i think. |
| 02:48:24 | shashlick | we might not need compiler changes |
| 02:48:53 | shashlick | cause local deps will need some nimble action which can create and maintain a nim.cfg file for you |
| 02:49:01 | disruptek | we do because it looks in ~/.nimble no matter what. |
| 02:49:14 | * | krux02_ quit (Remote host closed the connection) |
| 02:49:24 | shashlick | we can add --noNimblePath to the cfg |
| 02:49:38 | disruptek | that's not enough. 🙁 |
| 02:50:00 | shashlick | why not |
| 02:50:16 | disruptek | 'cause it still looks. try it. i could be wrong, but i don't think so. |
| 02:50:28 | * | GordonBGood joined #nim |
| 02:53:29 | shashlick | that's what nimble does when you do nimble c |
| 02:54:00 | shashlick | should work |
| 02:54:12 | disruptek | lemme me try it again. |
| 02:54:20 | shashlick | --noNimblePath |
| 02:56:14 | disruptek | if you specify a path and it doesn't exist, it loads from ~/.nimble. |
| 02:57:27 | shashlick | why are you specifying anything |
| 02:57:32 | shashlick | presume you are running nim and not nimble |
| 02:57:39 | disruptek | i /am/ running nim. |
| 02:58:22 | disruptek | i specified a directory that didn't exist -- it loaded .nimble. i specified a directory that exists and is empty -- it loaded .nimble. i specify --noNimblePath, it doesn't look anywhere. okay, at least that works. |
| 02:58:52 | disruptek | but the other two don't work unless i'm willing to manually add everything to my nim.cfg/config.nims, which frankly, i'm willing to do to get proper behavior. |
| 03:00:11 | shashlick | So that's the current behavior - use noNimblePath plus explicit --path for each dep |
| 03:00:23 | shashlick | Local deps will automate that |
| 03:01:00 | disruptek | you're just gonna have to accept that some people don't want to have to run `nimble build` in order to build their software. |
| 03:01:03 | disruptek | i'm one of those people. |
| 03:01:07 | disruptek | araq is one of those people. |
| 03:01:41 | shashlick | I understand - nimble commands will work sure, but maintaining a Nim.cfg will make Nim work too |
| 03:01:59 | shashlick | Anyway you will use nimble to install and maintain deps |
| 03:02:12 | shashlick | So it can maintain the cfg and nim doesn't have to change |
| 03:02:15 | disruptek | if we could give nim a --nimblePath in nim.cfg or on the command-line and it does the right thing -- ie. not looking anywhere else, that would be an improvement. |
| 03:02:21 | disruptek | but that's not the current behavior. |
| 03:02:25 | disruptek | so, nim does need to change. |
| 03:03:03 | disruptek | but don't take my word for it -- try it yourself. |
| 03:05:18 | * | lritter quit (Ping timeout: 245 seconds) |
| 03:10:58 | shashlick | --nimblePath appends, so that's not what we want |
| 03:11:20 | shashlick | --noNimblePath + paths is all we have now |
| 03:11:29 | shashlick | i don't want to mix that into this local deps requirement tho |
| 03:13:30 | shashlick | i think i've kind of addressed all your concerns in your second comment |
| 03:14:00 | shashlick | as far as explicit behavior, it is explicit cause you need to either create a deps folder or set a .nimble flag |
| 03:14:22 | shashlick | and it only applies when it is checked out and the main project |
| 03:14:47 | disruptek | yeah, but `mkdir` isn't all that explicit. it's easy to overlook when wondering why something isn't behavior the way you expect. |
| 03:15:03 | disruptek | you look in your local config, nothin'. you look in your global config, nothin'. wtf, nim? |
| 03:15:17 | shashlick | people are used to node_modules folders littered around |
| 03:15:29 | shashlick | it will take time but it is obvious |
| 03:16:10 | shashlick | debatable sure, but those who want local deps will know about it |
| 03:16:13 | disruptek | you don't create node_modules. |
| 03:16:18 | disruptek | npm is local by default. |
| 03:16:28 | shashlick | perhaps we can add a line to nimble output stating local mode or something |
| 03:16:36 | disruptek | that would work. |
| 03:16:51 | shashlick | so every time it runs, it makes it clear where deps are being loaded from |
| 03:17:27 | disruptek | or where they are installed to. |
| 03:17:34 | shashlick | adding a flag is not an issue, but then we need to design which commands or sub-commands it applies to and what not |
| 03:17:57 | shashlick | bunch of code to just set nimbleDir |
| 03:18:29 | disruptek | sometimes a bad design is expensive to change. |
| 03:18:45 | disruptek | but not as expensive as living with it. |
| 03:19:17 | shashlick | do you agree that local deps are only relevant as the main project but not for libraries? |
| 03:20:55 | disruptek | you mean are deps recursive? |
| 03:21:00 | disruptek | recursively local? |
| 03:21:12 | disruptek | nim doesn't support that yet, afaik. |
| 03:22:30 | shashlick | no suppose i make a project with local deps, do all my dev and checkin |
| 03:23:01 | shashlick | if someone nimble installs that project into ~/.nimble, those deps won't come down with it |
| 03:23:44 | shashlick | cause now it lives with the rest of the gang of deps in ~/.nimble |
| 03:23:52 | disruptek | i think if i can dev locally, then you can have global install. |
| 03:24:05 | disruptek | i would get araq's opinion on that. |
| 03:24:25 | shashlick | also, if they want to create a project with local deps that depends on that project which has local deps |
| 03:25:04 | shashlick | their project's dep tree will supersede |
| 03:25:38 | shashlick | if every dep locks its dependencies, you will get multiple versions of the same deps |
| 03:25:47 | shashlick | i read this is how lock files work |
| 03:26:30 | disruptek | if i'm devel'ing project A and it depends upon C1 and B and project B is also local and depends on C2, then i don't mind `nimble build` installing C2 in my A deps folder. |
| 03:28:12 | disruptek | B would have to {.path.} a specific version, i guess. i think the tooling is behind on this use-case. |
| 03:28:36 | shashlick | that will happen anyway, but note that a C2 checked into B won't be pulled as is, nimble will pull C2 from upstream |
| 03:28:45 | shashlick | https://snyk.io/blog/making-sense-of-package-lock-files-in-the-npm-ecosystem/ - see the last para on libraries |
| 03:29:26 | disruptek | you should watch hickey's talk on package management if you haven't. |
| 03:32:49 | disruptek | https://www.youtube.com/watch?v=oyLBGkS5ICk |
| 03:34:39 | disruptek | if i already have B devel-linked in, is nimble going to try to reinstall it? |
| 03:36:44 | shashlick | linked in how/where |
| 03:36:59 | disruptek | say B is already `nimble develop`ed. |
| 03:38:11 | disruptek | another reason to bump versions more often. 😊 |
| 03:39:19 | shashlick | how do you see `nimble develop` linking a project into the local deps dir of another project |
| 03:39:46 | disruptek | fair question. |
| 03:40:19 | disruptek | what does `nimble develop` actually do if i'm using local deps? |
| 03:41:05 | disruptek | i've never actually seen hickey speak in real time. |
| 03:41:23 | disruptek | afaik he speaks at 1.75x speed because i can't bear to watch him any slower. |
| 03:46:39 | shashlick | ehe |
| 03:46:46 | shashlick | i'm still fleshing out the nimble develop behavior |
| 03:46:56 | shashlick | but that's for the project in question |
| 03:47:17 | shashlick | i've not gotten far enough for nimble developing a project in a project with local deps |
| 03:47:41 | shashlick | its just a link really but you usually run nimble develop in that project's dir and ~/.nimble is implicit |
| 03:48:02 | disruptek | ah, yeah, a lot of my stuff relies on other of my stuff. most of it. |
| 03:48:13 | shashlick | local deps are only relevant in that project's dir, how do you run the develop command on some other dir then |
| 03:48:37 | shashlick | unless it is `nimble develop path/to/dir` |
| 03:48:44 | disruptek | could be a symlink. i dunno. i can do that with nimph if i have to. |
| 03:48:52 | disruptek | i'm just trying to understand what `nimble develop` even means. |
| 03:48:55 | shashlick | but not sure it is supported yet |
| 03:49:26 | shashlick | nimble develop makes a link file in ~/.nimble/pkgs so nim knows where to really look |
| 03:49:34 | shashlick | rest is the same |
| 03:49:34 | disruptek | right, i know that much. |
| 03:49:47 | disruptek | okay, so we can decide exactly what it does in this use-case. |
| 03:49:52 | disruptek | it's wide open. |
| 03:51:25 | disruptek | so if you're in a local-deps `develop` project and you run `develop`, you pass it a path or it's a user error. |
| 03:51:37 | disruptek | seems pretty easy. |
| 03:52:00 | disruptek | it could be a different name to make it less confusing. |
| 03:53:09 | shashlick | unless it is the other way around - run `nimble develop --nimbleDir:local-dep-dir` |
| 03:53:21 | shashlick | wonder if that works today |
| 03:54:13 | disruptek | that should work, though does it matter that you have the subcommand before the option? |
| 03:56:37 | shashlick | whichever way it works |
| 03:57:06 | shashlick | help says nimble COMMAND [opts] |
| 03:57:37 | disruptek | huh. okay. |
| 03:58:01 | shashlick | made some updates to the gist |
| 04:05:54 | shashlick | wondering what `nimble develop` should even do |
| 04:07:10 | disruptek | it installs `localDependencies = true` in your `project.nimble` and then runs `nimble install`. |
| 04:08:38 | shashlick | why would nimble develop force local deps |
| 04:09:28 | disruptek | i guess that's true. |
| 04:10:00 | shashlick | but if it came with predefined local deps, it should install deps there ya |
| 04:10:32 | disruptek | i think this is more complex than it needs to be but it'll be a hard sell to just put it all under a separate subcommand. |
| 04:12:19 | shashlick | the code changes aren't very large |
| 04:12:27 | shashlick | but i want the behavior to be clear |
| 04:13:01 | disruptek | i'm just talking about the user. |
| 04:13:21 | disruptek | develop did one thing, i don't think it should suddenly do a very different thing. |
| 04:13:38 | shashlick | do you think `nimble develop pkgwlocaldeps` should setup the project in ~/.nimble as well as with local deps? |
| 04:13:39 | disruptek | context changing with the behavior staying the same... that's fine. |
| 04:14:13 | disruptek | no, if you wanna set it up globally you can use --global. |
| 04:14:30 | disruptek | there could be a --local too. |
| 04:14:50 | disruptek | it doesn't hurt the user to give them more explicit ways to tell us what they want. |
| 04:14:56 | shashlick | i think --global needs to be reserved for cross-user global, that's a different issue |
| 04:15:02 | disruptek | it gives us more opportunities to verify that we're doing the right thing. |
| 04:15:15 | disruptek | okay, well, w/e. |
| 04:15:20 | shashlick | but that also complicates the user experience |
| 04:15:42 | disruptek | you don't need to use --v with bump anymore, but i bet you still do. |
| 04:16:54 | shashlick | nope, not used it |
| 04:17:02 | shashlick | bump's smart |
| 04:17:10 | disruptek | hmmph. |
| 04:17:47 | disruptek | did it ever fail gracefully for you? |
| 04:19:09 | disruptek | i guess what i'm getting at is that when the user provides more input, you can use it to provide better output. |
| 04:19:24 | disruptek | i know it's a balancing act. just sayin'. |
| 04:22:37 | shashlick | ya i'm not too opinionated, i like driving for clarity and good arguments |
| 04:33:35 | * | kevin_ quit (Ping timeout: 276 seconds) |
| 04:33:57 | shashlick | another update around `nimble develop` but i'm not thrilled about it |
| 04:34:15 | shashlick | for folks when you wake up - https://gist.github.com/genotrance/ee2ce321a56c95df2d4bb7ce4bd6b5ab |
| 04:47:40 | * | kungtotte quit (Quit: WeeChat 2.6) |
| 04:57:26 | * | chemist69 quit (Ping timeout: 246 seconds) |
| 04:58:47 | * | kungtotte joined #nim |
| 04:59:35 | * | chemist69 joined #nim |
| 05:18:40 | * | leorize quit (Ping timeout: 260 seconds) |
| 05:22:02 | * | leorize joined #nim |
| 05:53:01 | * | kevin joined #nim |
| 05:53:25 | * | kevin is now known as Guest19657 |
| 06:14:10 | * | dddddd quit (Remote host closed the connection) |
| 06:35:11 | * | solitudesf joined #nim |
| 06:41:37 | * | narimiran joined #nim |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:03:55 | * | zyklon quit (Remote host closed the connection) |
| 07:04:59 | GordonBGood | Araq: posted an issue against the "closures memory leak" issue, in spite of your PR - https://github.com/nim-lang/Nim/issues/12577 |
| 07:05:02 | * | gmpreussner joined #nim |
| 07:05:18 | GordonBGood | I think it's a valid issue as per my tests |
| 07:11:13 | * | theelous3_ joined #nim |
| 07:11:58 | * | nsf joined #nim |
| 07:12:39 | * | theelous3 quit (Ping timeout: 264 seconds) |
| 07:13:25 | * | uvegbot joined #nim |
| 07:15:37 | * | codeasone joined #nim |
| 07:19:27 | Araq | GordonBGood: I'm aware my patch must be done unconditionally |
| 07:24:27 | * | ndl joined #nim |
| 07:24:39 | GordonBGood | Araq: ah, good, I filed the issue just as we last agreed, but in testing I also see something wierd in "Alternative 2", a seq field doesn't get destroyed in spite of the destructor being called |
| 07:24:52 | GordonBGood | those are version 2 seq's |
| 07:25:03 | FromDiscord | <ndl> hi |
| 07:25:05 | ndl | hi |
| 07:25:33 | ndl | (: |
| 07:25:58 | Araq | GordonBGood: are you at a point where you can fix bugs like these now? :P |
| 07:27:14 | Araq | # tst.`=destroy` # this one on --gc:destructors produces dangling references exist FATAL error! |
| 07:27:16 | GordonBGood | Araq, I'm not sure - I understand them when I read them and I understand your fixes, but I guess I won't know if I can fix them myself unless I try :) |
| 07:27:48 | Araq | well d'oh, don't call =destroy yourself, the compiler does it for you |
| 07:27:49 | GordonBGood | Yeah, that one was new and a surprise |
| 07:28:11 | Araq | we don't 'nil' out refs in the generated destructor |
| 07:28:39 | Araq | just let the compiler do its job, don't nanny it |
| 07:28:53 | GordonBGood | That was left over from what you suggested; in fact wrapping the whole thing in a try:/finally shouldn't be necessary as the compiler effectively does that |
| 07:29:20 | * | solitudesf quit (Ping timeout: 268 seconds) |
| 07:31:55 | GordonBGood | Anyway, given that your patch will be applied unconditionally and back-ported, I just have to look into why the seq fields (Alternative 2) aren't deallocating their memory |
| 07:32:03 | GordonBGood | That seems easy to trace |
| 07:38:39 | GordonBGood | seq's version 2 have their own custom =destroy's so nothing should be generated by calling them, right? |
| 07:48:07 | GordonBGood | Have to go - jungle day - back in a few hours |
| 07:48:35 | Araq | bye |
| 07:52:26 | * | GordonBGood quit (Ping timeout: 240 seconds) |
| 07:57:07 | * | ndl quit (Quit: leaving) |
| 08:03:30 | * | gmpreussner_ joined #nim |
| 08:04:18 | * | gmpreussner quit (Ping timeout: 265 seconds) |
| 08:08:03 | * | jjido joined #nim |
| 08:45:46 | * | eterps left #nim (#nim) |
| 08:49:41 | * | Vladar joined #nim |
| 09:00:04 | * | Trustable joined #nim |
| 09:04:20 | FromGitter | <zacharycarter> cool - my little sokol example works with the destructors gc |
| 09:23:11 | FromDiscord | <Lantos> using what I've learned from you guys 🙂 |
| 09:23:11 | FromDiscord | <Lantos> https://cdn.discordapp.com/attachments/371759389889003532/640118691475750919/data.png |
| 09:24:44 | FromDiscord | <Lantos> any guesses to what this is? |
| 09:29:14 | FromGitter | <zacharycarter> Bitcoin moving average? |
| 09:31:39 | FromDiscord | <Lantos> yep! |
| 09:37:36 | FromDiscord | <Lantos> I seem to be bottle necked by nimitry. Will try the gnuplot wrapper |
| 09:38:25 | FromDiscord | <Lantos> or nimx to render it |
| 09:39:41 | FromDiscord | <Lantos> or nimx |
| 09:42:50 | * | GordonBGood joined #nim |
| 09:55:06 | GordonBGood | I'm back - got rained out |
| 09:55:25 | * | NimBot joined #nim |
| 10:06:13 | * | krux02 joined #nim |
| 10:12:34 | FromDiscord | <Chiqqum_Ngbata> Last time I had to plot something I generated CSV and threw it at R |
| 10:13:28 | * | Guest19657 quit (Remote host closed the connection) |
| 10:29:08 | * | ng0_ quit (Quit: Alexa, when is the end of world?) |
| 10:35:49 | * | filcuc joined #nim |
| 10:37:42 | GordonBGood | Araq: I've found the problem with destroying seq's with "--gc:destructors": you have now defined "nimV2" as part of "--gc:destructors"; and "nimV2" is set to disable seqsv2 "hooks" |
| 10:38:18 | GordonBGood | I'm confused, as you used to use "nimV2" it meant "--newruntime", so this seems ambiguous |
| 10:45:23 | * | letto quit (Read error: Connection reset by peer) |
| 10:45:45 | * | letto joined #nim |
| 10:56:18 | * | ng0 joined #nim |
| 10:57:09 | GordonBGood | I take it that "nimV2" no longer means "newruntime" but now mean either "gcDestructors" or "gcHooks" or "newruntime", with "nimOwnedEnabled" now meaning B/D |
| 10:58:25 | GordonBGood | I still don't see why "--newruntime" also mean "gcHooks", but never mind, that doesn't affect me for now... |
| 10:59:04 | * | filcuc quit (Quit: Konversation terminated!) |
| 11:15:49 | FromDiscord | <krab4t> why Haxe extension for VSCode looks way better than nim? 🙂 |
| 11:16:35 | * | Vladar quit (Quit: Leaving) |
| 11:19:39 | FromDiscord | <krab4t> https://i.imgur.com/zSiaoUY.png WTF |
| 11:20:28 | * | skellock joined #nim |
| 11:25:21 | FromDiscord | <Rika> what're you WTFing about |
| 11:31:08 | dom96 | Araq, please answer the questions: https://irclogs.nim-lang.org/01-11-2019.html#23:56:43 |
| 11:35:35 | dom96 | or answer it here: https://gist.github.com/genotrance/ee2ce321a56c95df2d4bb7ce4bd6b5ab#gistcomment-3072452 |
| 11:36:01 | * | solitudesf joined #nim |
| 11:39:27 | * | clyybber joined #nim |
| 11:40:05 | clyybber | disruptek, Araq: Should I provide a pragma for object fields to enforce explicit initalization? |
| 11:52:01 | * | krux02 quit (Remote host closed the connection) |
| 11:55:00 | lqdev[m] | @krab4t because the author of the Nim extension didn't pay attention to details |
| 11:55:06 | lqdev[m] | I bet it works better too |
| 11:55:11 | lqdev[m] | (the haxe ext) |
| 12:00:08 | FromGitter | <rishavs> Have a question on Vladar's nimgame2 |
| 12:00:39 | FromGitter | <rishavs> Just ran the platformer demo with 0.6.1. I can feel some microfreezes every 15-20 secs. Are these GC pauses? |
| 12:03:30 | clyybber | rishavs: Try with --gc:boehm and maybe some other gc's and if it disappears its probably the GC |
| 12:03:44 | FromDiscord | <Rika> or if it changes pattern |
| 12:03:49 | clyybber | yeah |
| 12:03:54 | FromDiscord | <Rika> try one of the stop the world GCs nim has |
| 12:04:16 | FromDiscord | <Rika> is go's GC stop the world? maybe try that, see if the freezes lengthen |
| 12:05:34 | FromDiscord | <Lantos> @Chiqqum_Ngbata did you do this because you couldn't find a quick grapher? |
| 12:05:43 | clyybber | I think go's GC isn't stop the world |
| 12:05:58 | clyybber | And for gc:go you require some dll I think |
| 12:06:09 | clyybber | which you get from the go distribution package |
| 12:06:11 | FromDiscord | <Chiqqum_Ngbata> R is just seductively easy to work with |
| 12:06:33 | FromDiscord | <Lantos> lol never heard a language talked about in that way |
| 12:06:46 | FromDiscord | <Rika> seductively easy... |
| 12:06:57 | FromDiscord | <Chiqqum_Ngbata> Think I tried other things and had a moment of clarity "I don't want to program plots!" |
| 12:07:45 | zedeus | https://github.com/Vindaar/ggplotnim |
| 12:09:09 | FromDiscord | <Rika> OOH |
| 12:09:16 | FromDiscord | <Rika> ***shiny*** |
| 12:11:06 | lqdev[m] | @Rike go and boehm are stop the world and afaik you dont need any extra dlls |
| 12:11:26 | FromDiscord | <Rika> i knew it 😛 |
| 12:12:04 | lqdev[m] | iirc the details are pointed out in the gc manual |
| 12:13:25 | FromGitter | <rishavs> I tried the perf flags `--multimethods:on -d:release --opt:speed` and dont seem to be getting any microfreezes anymore in the demo |
| 12:13:35 | lqdev[m] | indeed https://nim-lang.org/docs/gc.html#garbage-collector-options |
| 12:13:36 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 12:14:05 | lqdev[m] | by "Go lang-like" I understand that it's an in-house implementation |
| 12:14:15 | clyybber | rishavs: --multimethods:on is not a flag that enables more performance |
| 12:14:53 | FromGitter | <rishavs> oh. I found them in the nimgame2 github readme |
| 12:15:16 | FromGitter | <rishavs> bt in general for gamedev, which gc would be the best to go with among these? https://nim-lang.org/docs/gc.html#garbage-collector-options |
| 12:15:44 | FromGitter | <rishavs> I am assuming anything with "stop the world" is something i should stay away from? |
| 12:16:01 | FromDiscord | <Rika> yes |
| 12:16:17 | FromDiscord | <Rika> if its a game you avoid stop the world |
| 12:16:54 | clyybber | rishavs: That means nimgame2 needs multimethods, so I'd leave it enabled.. |
| 12:21:22 | FromDiscord | <Rika> destructors when 😛 |
| 12:22:31 | FromGitter | <zacharycarter> @rishavs - you should go with Nim's default GC, regions GC, no GC or the new destructor based GC |
| 12:23:09 | FromGitter | <zacharycarter> boehm mark and sweep and golang's GC are all considered stop the world GCs |
| 12:27:25 | lqdev[m] | rishavs: the default gc works really well for games, I used it already in memrecall and planet overgamma |
| 12:33:28 | * | ponyrider quit (Quit: WeeChat 2.6) |
| 12:33:49 | * | ponyrider joined #nim |
| 12:36:19 | * | clyybber quit (Quit: WeeChat 2.6) |
| 12:45:59 | * | uu91 joined #nim |
| 13:01:37 | * | GordonBGood quit (Ping timeout: 240 seconds) |
| 13:02:02 | * | uvegbot quit (Quit: Konversation terminated!) |
| 13:07:41 | FromGitter | <kaushalmodi> @Vindaar Does the dependencies section of ggplotnim need to get updated? https://github.com/Vindaar/ggplotnim/blob/master/README.org#dependencies |
| 13:08:48 | FromGitter | <kaushalmodi> I'd like to try it out but am looking for small examples that basically take in XY data series and plot that (like the examples of nimetry package). |
| 13:09:02 | * | Kaivo quit (Quit: WeeChat 2.6) |
| 13:09:46 | FromGitter | <kaushalmodi> My use case is that I would have the XY data and then I'd need to save the plot of those to files (I tried plotly but that pops up a browser window each time, and then that window stays open). |
| 13:10:53 | FromGitter | <kaushalmodi> In my use case, I would literally be generating hundreds of such graphs in a batch. Then based on the simulation status, I would look at the respective plot file to see what went wrong. |
| 13:15:00 | * | natrys joined #nim |
| 13:31:42 | FromDiscord | <Chiqqum_Ngbata> From nim documentation "$projectDir/nim.cfg" |
| 13:31:45 | FromDiscord | <Chiqqum_Ngbata> What is a projectDir? CWD? |
| 13:33:23 | FromDiscord | <mratsim> projectdir is your git directory |
| 13:33:34 | FromDiscord | <mratsim> the base directory of your project |
| 13:33:41 | disruptek | and the directory holding a something.nimble file. |
| 13:34:25 | FromGitter | <kaushalmodi> mratsim: It's not the git directory. I had to cook up something to get that |
| 13:34:32 | FromDiscord | <Chiqqum_Ngbata> Thanks |
| 13:34:54 | FromDiscord | <Chiqqum_Ngbata> Oh, uh.. what is it then? |
| 13:35:55 | FromDiscord | <mratsim> Multithreading runtimes are a pain to design :/. You need to think of data structures where people run N threads for days and they should leave no gorbage even if sometimes you have 1 billion tasks and sometimes only 2 ... |
| 13:38:09 | FromGitter | <kaushalmodi> Chiqqum_Ngbata: https://github.com/nim-lang/Nim/issues/9467 <-- related issue |
| 13:39:20 | * | dddddd joined #nim |
| 13:39:58 | FromGitter | <kaushalmodi> The default behavior of `projectDir` in nims is misleading. So I don't use that any more. |
| 13:40:30 | FromGitter | <kaushalmodi> I define the `getGitRoot()` proc defined in that issue in my global config.nims |
| 13:40:36 | * | lritter joined #nim |
| 13:41:54 | disruptek | i think it might have been fixed recently. |
| 13:43:26 | FromGitter | <kaushalmodi> hmm.. I wouldn't know as I stopped using `projectDir`. But I will try out the dummy example in that issue when I get to my development machine |
| 13:45:41 | disruptek | it'll be helpful if you can find a bug with it; i'm starting to rely on it more and more. |
| 13:51:59 | FromDiscord | <Chiqqum_Ngbata> Yeah. I always hesitate to use things like this when I run into arbitrary terminology. # impatient |
| 13:56:08 | * | exelotl joined #nim |
| 13:58:59 | * | bacterio joined #nim |
| 14:03:30 | * | bacterio quit (Quit: bacterio) |
| 14:07:56 | * | bacterio joined #nim |
| 14:07:56 | * | bacterio quit (Changing host) |
| 14:07:56 | * | bacterio joined #nim |
| 14:29:34 | disruptek | https://nim-lang.org/docs/macros.html#getProjectPath -- this is returning a `src` subdirectory in a project, not the project path. |
| 14:31:16 | FromGitter | <kaushalmodi> disruptek: Heh.. coincidentally I recently documented that |
| 14:32:54 | FromGitter | <kaushalmodi> As I updated in issue 9467, we are missing something like `getGitRoot` because procs are those, I believe, would be more useful in config.nims |
| 14:33:14 | disruptek | i think my solution is also to roll my own. |
| 14:34:12 | FromGitter | <kaushalmodi> what's your "roll your own"? |
| 14:34:20 | FromDiscord | <Rika> make your own proc |
| 14:34:27 | FromGitter | <kaushalmodi> yes.. |
| 14:34:41 | FromGitter | <kaushalmodi> I meant what's his "roll your own" proc defn? |
| 14:37:13 | disruptek | start with getProjectPath and climb until i find a .nimble. |
| 14:37:20 | disruptek | i just wish i had globbing at compile-time. |
| 14:37:34 | shashlick | You do |
| 14:37:38 | FromGitter | <kaushalmodi> I do the same.. but climb up till .git |
| 14:38:10 | disruptek | i do? |
| 14:38:16 | FromGitter | <kaushalmodi> may be we need a `getRootDir` proc in nims that accepts a string |
| 14:38:34 | FromGitter | <kaushalmodi> `getRootDir(".git")` , `getRootDir(".nimble")` |
| 14:39:02 | disruptek | it should be an enum; in theory, ExtSep could be != "." for... reasons. |
| 14:39:05 | shashlick | https://github.com/nimterop/nimterop/blob/master/nimterop/cimport.nim#L47 |
| 14:39:15 | shashlick | Poor man's walk dir |
| 14:39:42 | shashlick | https://github.com/nimterop/nimterop/blob/master/nimterop/build.nim#L677 also works though |
| 14:40:10 | * | nsf quit (Quit: WeeChat 2.6) |
| 14:40:12 | disruptek | yeah, i already walkdir in here. i'm just lazy. |
| 14:41:44 | shashlick | Any more comments on the local deps proposal? |
| 14:41:52 | shashlick | @arnetheduck @mratsim |
| 14:42:51 | disruptek | isn't `nimble build` the same as `nimble install` in localdeps? |
| 14:43:22 | shashlick | Yep |
| 14:43:34 | disruptek | install without options should probably install somewhere. |
| 14:43:54 | shashlick | Gets confusing |
| 14:44:03 | shashlick | Even develop has that issue |
| 14:44:10 | disruptek | there's no way to install otherwise. |
| 14:44:18 | shashlick | Which is why I'm documenting to get some consensus |
| 14:44:48 | shashlick | Do you want to try and answer @dom96 question |
| 14:45:42 | disruptek | asked and answered. i mean, we have issues going back years on this thing. |
| 14:50:31 | shashlick | Ya but people understand lock files a bit better now |
| 14:51:23 | disruptek | honestly, the people that don't understand these problems are people that don't write software. |
| 14:54:31 | shashlick | You're being too generous |
| 14:54:52 | * | uvegbot joined #nim |
| 14:55:03 | shashlick | Plus knowing a lot about everything too much to ask too |
| 14:55:14 | shashlick | I won't claim to know anything about package management |
| 14:55:40 | disruptek | i'm drawing a red circle on my calendar around "November 2nd, 2019". it isn't often i'm called "too generous." 🤣 |
| 14:56:18 | disruptek | you're just proving my point, though. |
| 14:56:31 | disruptek | if you write anything of any complexity, you run into these problems. |
| 14:56:53 | FromDiscord | <Rika> disruptek so you're in favor of lockfiles right> |
| 14:57:03 | disruptek | yep. and/or localdeps. |
| 14:57:46 | disruptek | the fact is, there's information we find useful about testing our assumptions when developing software. that information should be shared, versioned, stored on disk. |
| 14:58:24 | FromDiscord | <Rika> what are the arguments against lockfiles though? |
| 14:58:34 | disruptek | it could be the deps themselves, it could be lockfiles, it could be package.json or package-lock.json or fubar.nimble or config.nims or nim.cfg or pretty much anything. |
| 14:59:58 | disruptek | there's really no good reason not to record this stuff, control it, and measure it when attempting to help the user accomplish their goals. |
| 15:00:09 | shashlick | I think local deps is a development requirement |
| 15:00:23 | shashlick | Whereas lock files is a distribution requirement |
| 15:00:29 | * | theelous3_ quit (Ping timeout: 246 seconds) |
| 15:00:30 | shashlick | Cannot mix the two |
| 15:00:43 | disruptek | that's not true at all. |
| 15:00:54 | shashlick | Ok please explain |
| 15:01:01 | FromDiscord | <Rika> hmmm? |
| 15:01:24 | shashlick | Note that npm has both as separate features |
| 15:01:28 | FromDiscord | <Rika> local deps is generally used for development (package version isolation between projects) |
| 15:01:54 | disruptek | you use lockfiles in development all the time; you want to update a library and make sure your code works. you update the lib, you get some test errors, you modify your code, it works. now you version those lockfiles. now you can roll back to the previous version of deps and verify that your code still works -- because you have the old lockfiles. |
| 15:02:10 | FromDiscord | <Rika> lock files are used to ensure anyone who installs a certain version of a repo with a lockfile will have the same versions as the dev who first made and used the lockfile |
| 15:02:18 | FromDiscord | <Rika> no no no |
| 15:02:35 | FromDiscord | <Rika> lockfiles arent necessarily only for distribution, its just that usually they are |
| 15:04:21 | shashlick | Lock files are the next logical step after providing per project isolation |
| 15:04:34 | shashlick | But figuring out both for this requirement will get us nowhere |
| 15:04:59 | shashlick | We just want to implement --save or whatever npm offers |
| 15:11:53 | * | ftsf quit (Ping timeout: 276 seconds) |
| 15:12:13 | * | clyybber joined #nim |
| 15:12:18 | * | jjido joined #nim |
| 15:17:51 | skellock | systemctl poweroff |
| 15:18:05 | disruptek | 😦 |
| 15:18:13 | skellock | woah... i almost brought down the internet. sorry. |
| 15:18:24 | disruptek | close one. |
| 15:18:40 | skellock | i'm an untrained professional |
| 15:22:09 | disruptek | clyybber: not sure what you mean wrt pragmas; i would think we'd need a pragma to /not/ set defaults before we need one for defaults; or aren't you defaulting NeedsInit? |
| 15:25:10 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:26:01 | * | sagax quit (Ping timeout: 268 seconds) |
| 15:32:10 | * | NicQ joined #nim |
| 15:39:50 | clyybber | disruptek: Yeah thats basically what I meant |
| 15:39:55 | clyybber | its equitvalent |
| 15:41:38 | * | skellock quit (Ping timeout: 240 seconds) |
| 15:41:41 | disruptek | yeah, i don't see how defaults matter for non-NeedsInit; that should be safe. but NeedsInit probably needs to let the user choose how/where to alloc. |
| 15:42:16 | disruptek | let them override it, i mean. |
| 15:44:33 | clyybber | ok |
| 15:44:35 | clyybber | Hmm |
| 15:44:52 | clyybber | the way the compiler handles/allows discriminator values rn is really broken |
| 15:45:15 | clyybber | It is not clear wether I am supposed to be able to use an int as a discriminator |
| 15:45:31 | clyybber | And I'm not sure what is intended anymore |
| 15:46:22 | * | nsf joined #nim |
| 15:46:36 | disruptek | seems like a fair question. |
| 15:46:45 | clyybber | Because Araqs fix for https://github.com/nim-lang/Nim/issues/12379 doesn't acutally fix it for me, and their is some checking for the discriminators size in semobjconstr too |
| 15:47:18 | disruptek | probably if you want int-like behavior you should use a range[int]. |
| 15:47:38 | disruptek | that would seem to be a suitable subset. |
| 15:48:00 | disruptek | but maybe there's some reason you can't have the discriminator field be a range? |
| 15:48:03 | clyybber | range[int16] I think |
| 15:48:23 | disruptek | i mean, as a developer, maybe you are somehow limited with your discriminator type. |
| 15:48:29 | clyybber | disruptek: Araqs fix tries to disallow using types that have low(T) != 0 |
| 15:48:33 | clyybber | as a discriminator |
| 15:48:45 | disruptek | wow, that seems like a mistake. |
| 15:49:19 | clyybber | Yeah I don't like it either. |
| 15:49:29 | clyybber | And will remove it |
| 15:49:35 | disruptek | lol |
| 15:50:25 | clyybber | disruptek: Can you check my snippet in the issue? Just to make sure its really not fixed. |
| 15:50:37 | disruptek | do you have a link? |
| 15:51:04 | clyybber | https://github.com/nim-lang/Nim/issues/12379 |
| 15:52:03 | disruptek | SEGV |
| 15:54:00 | disruptek | https://play.nim-lang.org/#ix=20C3 |
| 15:54:15 | clyybber | disruptek: Are you on devel? |
| 15:54:41 | disruptek | yeah. |
| 15:54:55 | clyybber | Ok, thanks |
| 15:55:19 | disruptek | interesting that it works in playground. what does it say for you? |
| 15:55:29 | clyybber | It doesn't work in playground for me |
| 15:55:35 | clyybber | errors in int128 |
| 15:55:50 | disruptek | that's better than a SEGV though. |
| 15:55:50 | clyybber | and with int32 as the discriminator it infinite loops |
| 15:55:59 | disruptek | fun. |
| 15:56:07 | disruptek | that'll be useful this winter. |
| 15:56:08 | clyybber | #FUN# |
| 15:56:16 | clyybber | disruptek: Haha |
| 15:57:01 | disruptek | i just did a `build_all.sh` and it's still SEGV for me. |
| 15:57:20 | disruptek | on HEAD. |
| 15:58:24 | clyybber | hmm |
| 15:59:01 | clyybber | weird. sadly the manual/spec isn't very specific on what is supposed to be supported as a discriminator |
| 16:01:22 | disruptek | i just wonder if narrowing the spec is going to get in the way of some use-case. |
| 16:01:39 | clyybber | yeah |
| 16:02:57 | clyybber | and interestingly my snippet works when you remove the field assignment at the end |
| 16:07:31 | disruptek | that's even worse. |
| 16:08:46 | disruptek | wait, that /should/ work if you remove the assignment. |
| 16:09:46 | clyybber | umm |
| 16:09:48 | clyybber | yeah |
| 16:10:23 | clyybber | but you can also change it to a valid assignment |
| 16:10:27 | clyybber | and it will still crash |
| 16:12:41 | clyybber | seems like the compiler tries to prove something |
| 16:12:47 | clyybber | and fails miserably |
| 16:13:29 | clyybber | oh |
| 16:13:38 | clyybber | it just tries to compute alignment or size |
| 16:13:40 | clyybber | and fails |
| 16:13:42 | clyybber | ha |
| 16:14:55 | * | theelous3 joined #nim |
| 16:15:45 | clyybber | ping Araq, krux02 |
| 16:15:46 | disruptek | but that means we support 128bit ints for discriminator. |
| 16:16:23 | clyybber | haha, I don't think so. The generated runtime checks for field assignments |
| 16:16:45 | clyybber | only work for int16 or less |
| 16:16:54 | clyybber | I think |
| 16:17:10 | disruptek | works for int64. |
| 16:17:32 | disruptek | on playground, at least. |
| 16:18:10 | clyybber | huh, try with one branch having high(int64) |
| 16:18:43 | clyybber | anyways I think that could also just mean that the checks fail to detect invalid assigns |
| 16:19:26 | disruptek | need to add some tests to the compiler for this stuff. |
| 16:20:41 | * | jjido joined #nim |
| 16:21:08 | clyybber | @mratsim: Huh do booleans not work as discriminators for you? |
| 16:21:15 | clyybber | disruptek: Yeah definitely |
| 16:21:31 | FromDiscord | <mratsim> in your issue you said to only allow enums |
| 16:21:37 | clyybber | bool is an enum |
| 16:21:47 | FromDiscord | <mratsim> ah so you mean ordinal? |
| 16:21:50 | clyybber | but yeah I was wrong anyway in that PR |
| 16:22:05 | clyybber | mratsim: We should allow as much as possible :P |
| 16:22:21 | FromDiscord | <yewpad> good evening guys. hope you're having an awesome day so far |
| 16:22:36 | FromDiscord | <mratsim> hello yewpad |
| 16:22:37 | clyybber | But I'm not sure wether types with a length >= 32 are supposed to be supported |
| 16:22:45 | clyybber | yewpad: Good dat |
| 16:22:49 | clyybber | day |
| 16:23:24 | FromDiscord | <mratsim> you probably mean sizeof(T) > 2 bytes (i.e. bigger than int16) |
| 16:23:29 | clyybber | yeah |
| 16:23:43 | FromDiscord | <mratsim> no they are not supported in case statement anyway |
| 16:23:46 | FromDiscord | <yewpad> I'm planing on writing a huge server orchestration software for Minecraft servers in Nim. Any tips, anything to watch out for? |
| 16:24:08 | clyybber | mratsim: Interesting, so basically the checks were completely bogus till now. |
| 16:25:27 | clyybber | Hmm, maybe there is more to it. |
| 16:28:16 | clyybber | Ha |
| 16:29:05 | clyybber | It's not supposed to be supported |
| 16:29:14 | clyybber | I'm pretty sure |
| 16:30:43 | disruptek | yewpad: hard to answer questions that lack specificity. |
| 16:30:47 | clyybber | ah |
| 16:30:50 | clyybber | it is supported |
| 16:35:44 | clyybber | but only for constant discriminators. |
| 16:36:05 | clyybber | or not? |
| 16:36:15 | clyybber | wth, I can't tell anymore |
| 16:36:53 | disruptek | start with adding some tests of stuff you think should work. see when they start failing. |
| 16:37:03 | FromDiscord | <mratsim> @yewpad iirc def- uses Nim to manage teeworld servers but I may be wrong |
| 16:37:06 | disruptek | we have no idea what the spec is anymore. |
| 16:37:22 | disruptek | need to see what people are using in any event. |
| 16:37:48 | def- | well, we do have some scripts in Nim, but also others in Python |
| 16:37:55 | FromDiscord | <mratsim> See: https://hookrace.net/blog/what-is-hookrace/ |
| 16:38:07 | FromDiscord | <mratsim> oh, the master is there :p |
| 16:38:08 | clyybber | disruptek: The thing that tops it that it is not supported for ranges even when when the branch can be determined at compile time |
| 16:38:23 | def- | @mratsim You pinged me :D |
| 16:40:21 | FromDiscord | <mratsim> that doesn't mean you are always on 😉 |
| 16:41:42 | FromDiscord | <mratsim> Well I'm not that attached to case objects with bool @Clyybber, I wanted to use them for lazy creation of stuff (cryptographic object for Status and lazy channel creation for Picasso) |
| 16:41:56 | clyybber | They should definitely work |
| 16:42:00 | FromDiscord | <mratsim> but it's not really an issue to create an enum with 2 state |
| 16:42:13 | clyybber | mratsim: bool IS an enum with 2 states |
| 16:42:22 | clyybber | and it works |
| 16:42:43 | FromDiscord | <mratsim> bool is a type, and enum is another ;). Whoever told you otherwise is a javascript or Php developer |
| 16:42:49 | clyybber | mratsim: My problem with the current compiler is what happens for size(T) > 2 |
| 16:43:12 | FromDiscord | <mratsim> I think it's safe to throw a compile-time error on that |
| 16:43:23 | FromDiscord | <mratsim> at the enum definition level |
| 16:43:32 | FromDiscord | <mratsim> because you can't do a case statement on those anyway |
| 16:43:41 | clyybber | mratsim: https://github.com/nim-lang/Nim/blob/devel/lib/system.nim#L43 |
| 16:43:56 | FromDiscord | <mratsim> I'm not to sure how the compiler special cases case branches with range of ints though |
| 16:44:07 | clyybber | mratsim: I am, and its bogus |
| 16:44:21 | FromDiscord | <mratsim> oh, you right it's an enum, magic |
| 16:44:38 | FromDiscord | <mratsim> I never knew :p |
| 16:44:55 | clyybber | These are my concerns rn: |
| 16:44:58 | clyybber | only supported for compile time discriminator values |
| 16:45:01 | clyybber | ? BUT why the fuck not for ranges that are specific enough to specify the branch at compile time |
| 16:45:03 | clyybber | ? Why the fuck does this mess up sizealign? |
| 16:45:05 | clyybber | ? Why the fuck does araqs fix disallow low(T) != 0 |
| 16:45:07 | clyybber | sorry for the language |
| 16:45:35 | FromDiscord | <mratsim> I think you should probably take a walk 😉 |
| 16:45:38 | clyybber | they are all conerns for discriminator types with size > 2 bytes |
| 16:46:27 | FromDiscord | <mratsim> anyway, it's good to see more people working on the low-level internal and magic of the Nim compiler |
| 16:47:01 | clyybber | Not good for the people though :p |
| 17:02:03 | * | adeohluwa joined #nim |
| 17:06:51 | Zevv | voodoo, black magic, witchwork, wizardry and sorcery |
| 17:07:10 | disruptek | now you're talkin' my language. |
| 17:07:58 | clyybber | blaka smoko |
| 17:08:27 | Zevv | shamans and necromancers |
| 17:13:50 | lqdev[m] | shashlick: any progress on `nim check` performance problems with nimterop? |
| 17:22:53 | shashlick | not yet @lqdev |
| 17:23:04 | shashlick | do you still see it with devel? |
| 17:23:56 | shashlick | replied to some of the comments on https://gist.github.com/genotrance/ee2ce321a56c95df2d4bb7ce4bd6b5ab |
| 17:24:14 | shashlick | @disruptek - i didn't reply to your second comment since we discussed it and I made relevant updates to the gist |
| 17:24:25 | * | adeohluwa quit (Ping timeout: 268 seconds) |
| 17:24:30 | * | clyybber quit (Quit: WeeChat 2.6) |
| 17:24:43 | shashlick | but please everyone review the gist and provide your insights |
| 17:25:13 | disruptek | this needs to reach a wider audience than irc. |
| 17:26:28 | * | clyybber joined #nim |
| 17:27:28 | clyybber | crash playground.. |
| 17:28:13 | clyybber | https://play.nim-lang.org/#ix=20Cz |
| 17:28:30 | clyybber | disruptek: its getting fun |
| 17:28:57 | disruptek | oh c'mon |
| 17:29:20 | FromDiscord | <Rika> `--nimbleDir:xxx overrides all the following behaviors` instead of this maybe something simpler like `--no-local` or something, then the current behavior would be used |
| 17:29:54 | FromDiscord | <Rika> (unless nimbleDir isnt currently provided by default, in which case ignore this) |
| 17:30:26 | clyybber | disruptek: and its gcc that infi-loops |
| 17:30:35 | disruptek | wow, gcc bugs. |
| 17:30:41 | disruptek | yeah. |
| 17:31:23 | * | clyybber quit (Quit: WeeChat 2.6) |
| 17:31:51 | disruptek | c=2 fails the same. |
| 17:32:00 | * | clyybber joined #nim |
| 17:32:06 | disruptek | c=2 fails the same. |
| 17:32:07 | clyybber | Hahahaha, it hung up my pc |
| 17:33:31 | clyybber | or at least made it really s l o w |
| 17:34:25 | disruptek | i only have one known wedge on my machine, but it's a bad one. |
| 17:34:49 | clyybber | damn, I can borrow you some fried eggs if you want? |
| 17:34:56 | disruptek | sometimes if i ctrl-d exit out of a terminal too quickly, it hangs my compositor. the only reasonable fix is to ssh in and reboot. |
| 17:35:22 | clyybber | haha, wayland? |
| 17:35:25 | disruptek | yeah. |
| 17:35:32 | clyybber | have you reported it? |
| 17:35:39 | disruptek | to whom? |
| 17:35:46 | clyybber | wlroots? |
| 17:35:54 | clyybber | you use sway right? |
| 17:36:12 | disruptek | i can't narrow it down. could be sway, could be wayland, could be mesa conceivably. |
| 17:36:39 | clyybber | disruptek: rely on it, build your scripts around it, make a ruckus when its fixed |
| 17:36:46 | disruptek | lol |
| 17:37:03 | disruptek | the best way to change behavior of software is to rely upon its consistency. |
| 17:37:04 | clyybber | adapt your workflow kids |
| 17:37:19 | shashlick | @Rika - nimbleDir is existing behavior |
| 17:37:21 | clyybber | disruptek: that is a sentence worth archiving |
| 17:37:48 | FromDiscord | <Rika> hmm so it's best to just use existing behavior |
| 17:37:49 | FromDiscord | <Rika> okay |
| 17:37:54 | shashlick | @disruptek I've posted on the github issue, I'll make a forum post as well |
| 17:38:44 | * | sagax joined #nim |
| 17:39:50 | * | natrys quit (Ping timeout: 268 seconds) |
| 17:40:58 | * | natrys joined #nim |
| 17:45:54 | * | NicQ quit (Read error: Connection reset by peer) |
| 17:46:27 | * | NicQ joined #nim |
| 17:47:04 | * | clyybber quit (Quit: WeeChat 2.6) |
| 17:50:56 | * | NicQ quit (Ping timeout: 268 seconds) |
| 17:54:50 | * | sedfox quit (Ping timeout: 240 seconds) |
| 17:55:25 | FromDiscord | <arnetheduck> shashlick, local deps issue? (haven't been following chat for a few days) |
| 17:55:45 | shashlick | Yes @arnetheduck |
| 17:55:52 | shashlick | Please see the gist |
| 17:57:18 | * | nif_ quit (Quit: ...) |
| 17:57:28 | * | nif joined #nim |
| 17:57:57 | FromDiscord | <arnetheduck> oh, well, in general I think it's a travesty that nimble ever looks outside of the local project folder (and nim std lib) without explicitly being told to do so. I'd switch it to local and deal with the fallout (either by printing a warning or whatever) - in theory it should be an almost pain-free upgrade, you just run nimble build or whatever and it sets up the deps locally and you're done |
| 17:58:22 | lqdev[m] | shashlick: the performance issue persists, nim check still takes ~4s to complete |
| 17:59:21 | FromDiscord | <arnetheduck> if I have two side-by-side checkouts, there should be absolutely no leakage of information between them |
| 17:59:41 | disruptek | arnetheduck: i share your position, but we seem to be in the minority. |
| 18:03:22 | FromDiscord | <arnetheduck> well, I can't put it any more gently than that either - I mean, the world learned that globals of most kinds are a bad idea - in your code, in your software repo, etc etc - inevitably it fails whenever you create your second checkout or need two things side by side.. guiding users towards this shitty developer experience by defaulting to global is just bad - it's like encouraging users to use globals in code without educating them on th |
| 18:05:16 | shashlick | We are getting there |
| 18:05:32 | shashlick | See my last comment about a --user flag to break out |
| 18:05:51 | shashlick | I'm yet to incorporate it into the proposal |
| 18:08:52 | shashlick | Any feedback on behaviors |
| 18:12:02 | FromDiscord | <arnetheduck> yeah, --user to break out is fine, or --global to install to /usr/whatever.. lock files btw are a way to deal with all this, if they're properly implemented.. there are a few other things as well, I want to be able to locally override a dep to a development version I have checked out somewhere (`nimble develop` or whatever it's called) etc.. there's a whole bunch of features that follow, but this is a fundamental issue - you can only so |
| 18:13:02 | disruptek | i have no idea what `isRootDir` does. anyone? |
| 18:15:28 | disruptek | mr. duck, add some newlines. irc folks are only getting half your comments. |
| 18:15:31 | FromDiscord | <arnetheduck> generally, I also have a gut feeling lock files solve most of the issues that your gist and deps thing aims to solve, except mainaining a local copy inside deps (ie vendoring).. generally that's not what I want |
| 18:16:05 | FromDiscord | <arnetheduck> ie generally, I don't want source files from other projects to be checked into my own repo |
| 18:16:23 | disruptek | that's my shitty-code example. |
| 18:16:33 | FromDiscord | <arnetheduck> there are use cases for that, but that can be an addon to lock files |
| 18:17:19 | disruptek | sometimes you have to deal with orphaned code that way, too. |
| 18:25:46 | FromDiscord | <arnetheduck> yeah, but most of the time I don't - ie imagine a dep on boost in c++ - I don't want a copy of that stuff in my repo |
| 18:28:52 | disruptek | that's a case where you'll manually point to it with a --path: statement. |
| 18:29:43 | FromDiscord | <arnetheduck> well, no - I'll have a lock file checked in, so that it can be resolved deterministically - if I need vendoring, I'll run a proxy or potentially have special magic commands that work off the lock files to take a local copy |
| 18:30:33 | disruptek | how fun for you. |
| 18:30:54 | FromDiscord | <Rika> sounds like the "DONT PUSH NODE_MODULES" thing again |
| 18:31:08 | FromDiscord | <Rika> basically: just dont push the deps folder i guess? |
| 18:31:43 | FromDiscord | <arnetheduck> rika, how will you know what's in my deps folder if I hand you some code? the point is to ensure that if I can build the project, so can you |
| 18:31:58 | FromDiscord | <Rika> isnt that the point of the lockfile |
| 18:32:17 | FromDiscord | <Rika> wait, lemme guess: the proposal doesnt indicate a lockfile |
| 18:33:12 | FromDiscord | <arnetheduck> yeah, but once you have a lock file, it doesn't matter where the deps live - they can even be in a (global) cache - semantically, the deps behave as if they were in a deps folder |
| 18:33:49 | FromDiscord | <Rika> hmm good points |
| 18:33:58 | FromDiscord | <Rika> i just want a lock file tbh ;; |
| 18:34:04 | FromDiscord | <Rika> i dont mind either global or local |
| 18:34:39 | FromDiscord | <arnetheduck> there's a few other things as well: I want to have multiple projects per git repo, and be able to specify deps in a relative way (so the commit is atomic across libraries) |
| 18:34:49 | FromDiscord | <arnetheduck> deps folder makes that awkward |
| 18:36:34 | FromDiscord | <arnetheduck> I want to codevelop two things that live in separate repos: I have them checked out side-by-side and want to (locally) say/override: use my checked-out version - also tricky with deps (a symlink in deps perhaps, but...) |
| 18:38:36 | FromDiscord | <arnetheduck> vendoring is more of a distribution thing: the behind-the-firewall use case, or "I want a local copy of the deps in case they get pulled" - doesn't necessarily mean that a local copy in my own git repo is the smoothest option (that's git's responsibility, to copy repos of code, no need for nimble to implement it poorly also) |
| 18:44:37 | * | sedfox joined #nim |
| 18:49:38 | * | natrys quit (Ping timeout: 276 seconds) |
| 18:54:30 | federico3 | https://circleci.com/gh/FedericoCeratto/nim-package-directory/128 is anyone running into this error with circleci? |
| 18:55:17 | * | sedfox quit (Ping timeout: 240 seconds) |
| 19:02:32 | * | sedfox joined #nim |
| 19:08:24 | * | sedfox quit (Ping timeout: 265 seconds) |
| 19:20:23 | * | GordonBGood joined #nim |
| 19:20:31 | * | sedfox joined #nim |
| 19:33:06 | * | Skaruts joined #nim |
| 19:35:40 | Skaruts | hey guys, I noticed an issue with physics (and seen some other people noticing too), but I don't know if this is a bug or if it's just people doing something wrong |
| 19:36:07 | Skaruts | hmm, does IRC support posting images? |
| 19:37:17 | * | thomasross quit (Quit: Leaving) |
| 19:37:28 | lqdev[m] | Skaruts: no, you have to use a hosting service like imgur |
| 19:37:37 | * | thomasross joined #nim |
| 19:37:53 | Skaruts | ok then 1 sec... I have a gif of the problem |
| 19:39:56 | Skaruts | https://i.imgur.com/R9saNLX.mp4 |
| 19:40:32 | Skaruts | in the gif I'm walking against a StaticBody, and instead of just stopping, I get this jittering |
| 19:41:11 | Skaruts | that doesn't happen everywhere, just on some places, but I couldn't perceive a pattern |
| 19:42:01 | Skaruts | I implemeted several FPS controllers from following several tutorials, and this happens with all of them |
| 19:42:32 | GordonBGood | To all: I'm new here and Araq has me looking at a couple of newish things like seqsv2 and reference counting that require more knowledge of "compiler magic"... |
| 19:42:49 | Skaruts | OH |
| 19:42:53 | Skaruts | wait a minute |
| 19:43:05 | GordonBGood | I don't know who's who: Other than Araq, who actually works on the compiler magic? |
| 19:43:06 | Skaruts | I'M ON THE WRONG IRC |
| 19:43:14 | Skaruts | lol sorry guys |
| 19:43:19 | Skaruts | facepalm |
| 19:43:27 | solitudesf | happens to the best of us |
| 19:43:54 | Skaruts | best way to tell when you seriously need some sleep... |
| 19:44:17 | Skaruts | well, see ya, then, sorry lol |
| 19:44:28 | * | Skaruts left #nim (#nim) |
| 19:45:56 | GordonBGood | Given that it's the weekend, it may not be the bast day to find ppl on here? |
| 19:53:08 | disruptek | GordonBGood: clyybber and krux02 get their hands dirty in the compiler. |
| 19:55:49 | GordonBGood | disruptek: thanks, I have gathered that krux02 is the VM specialist but maybe also the rest of the "magic"? |
| 19:56:19 | disruptek | the thing about magic is that it is opaque to all but the practitioner, so i really have no idea. |
| 19:56:41 | GordonBGood | I've chatted with clyybber, but not about "work", will have to extend the relationship, I think |
| 19:57:10 | GordonBGood | (vent), yes, the new "spagetti code" is conditional compilation, I'm afraid |
| 19:59:32 | GordonBGood | Just re-read the compiler internal's document: "the Nim compiler itself; note that this code has been translated from a bootstrapping version written in Pascal, so the code is not a poster child of good Nim code" |
| 20:00:39 | * | Sembei joined #nim |
| 20:01:16 | GordonBGood | One can read it and understand it by some skipping to and fro, but to actually change or debug something is intense |
| 20:03:25 | * | codeasone left #nim (#nim) |
| 20:11:34 | * | Sembei quit (Quit: WeeChat 2.6) |
| 20:13:23 | GordonBGood | disruptek: do you never sleep? You seem to be here no matter what time of day or night I check in |
| 20:13:42 | disruptek | i'm a loser. it is known. |
| 20:14:21 | GordonBGood | Welll, I assumed you were "different"; not necessarily a bad thing |
| 20:14:57 | disruptek | "touched", you mean? |
| 20:15:43 | GordonBGood | Nah, don't want to jump to any conclusions: I see you are quite helpful through |
| 20:16:00 | GordonBGood | Can answer quite a few Nim question |
| 20:16:22 | GordonBGood | Do you have a specific developement area? |
| 20:16:27 | disruptek | i don't know much, but i like guessing. |
| 20:16:58 | GordonBGood | You seem to make quite accurate guesses |
| 20:17:13 | disruptek | https://github.com/disruptek -- a pretty good birds-eye view. |
| 20:19:08 | GordonBGood | Thanks, been in Nim for a while, I see |
| 20:19:43 | disruptek | yeah, i think about 6 months or so. |
| 20:19:52 | GordonBGood | I've jumped languages quite a bit, now trying to settle in Nim dev for the long haul |
| 20:20:07 | disruptek | it's pretty tough to beat. what other paradigms do you code in? |
| 20:20:54 | disruptek | kaushalmodi: pushed a new bump that has a recursive project .nimble finder you can use to get the repo path; works at compile-time. |
| 20:21:15 | GordonBGood | For the last several years, mostly FP - F#/Fable, Haskell, Elm, with many other stops, investigations along the way |
| 20:21:34 | disruptek | nice. i wanna learn clojure next. |
| 20:22:36 | disruptek | i see us running nim in lvm and having lisp in the same vm would be amazing. |
| 20:22:43 | disruptek | er, jvm |
| 20:22:59 | GordonBGood | Have helped with a GraphicsSVG repo for Elm, several web pages/SPA using Elm and Fable, got involved with Eta which is a port of Haskell to run on JVM |
| 20:23:15 | disruptek | neat, i don't know eta. |
| 20:24:14 | disruptek | looks pretty cool. |
| 20:24:50 | GordonBGood | Really nice guy (couple actually) run the show, and I would really like them to succeed, but kind of dropped out of their dev team because it is going to be a hard sell to go anywhere; only FP nerds will choose Haskell-like programming |
| 20:25:05 | GordonBGood | Found the repo? |
| 20:25:29 | GordonBGood | The chief there really knows his JVM and Java! |
| 20:25:32 | disruptek | that's why i'm out on haskell. i think it's just too big a hill to climb for library support. |
| 20:26:27 | disruptek | i think it's a sexy language, just going to be slow going. |
| 20:26:52 | GordonBGood | I've actually chatted with SPJ of GHC and he invited me to contribute, but "compiler magic" was just a bit beyond me at the time - so now I'm trying to get my head around Nim "compiler magic" |
| 20:27:32 | GordonBGood | Haskell/Eta is very satisfying to get something working |
| 20:27:50 | GordonBGood | It's pretty hard to write really ugly code in Haskell |
| 20:28:02 | disruptek | right, that's what i like about it. |
| 20:28:12 | disruptek | i'm a very aesthetic-oriented programmer. |
| 20:28:59 | GordonBGood | It's what I despair a bit about Nim: while the external syntax is a thing of beauty, it seems the internal implementation is not so much |
| 20:29:55 | disruptek | i sometimes think i'd like to /heavily/ comment nim and/or the stdlib, but i don't know if it'd go over very well. |
| 20:29:58 | GordonBGood | Yeah, me too - if the final code doesn't look beautiful to me, I'm never really satisfied, even if it works |
| 20:30:56 | GordonBGood | Ah, Araq seems to be more mellow these days - I think that'w why he invited me here: a fresh look at things |
| 20:31:54 | disruptek | yeah, i think he's pretty relaxed, all things considered. |
| 20:32:03 | disruptek | must be all the running. |
| 20:32:10 | GordonBGood | Elm language is a beautiful simple language that can be used to teach programming to 12-year-olds (using the mentioned graphics package), but I think perhaps overly restrictive for general use |
| 20:32:46 | disruptek | this was a good article: https://elm-lang.org/news/the-syntax-cliff |
| 20:33:18 | GordonBGood | the owner, Evan, doesn't accapt anyone touching "his" compiler code, which means that new releases take years |
| 20:34:00 | GordonBGood | Yes, he's opinionated, but I agree with most of his opinions |
| 20:34:41 | disruptek | it's nice when those line up. 😆 |
| 20:35:29 | GordonBGood | There was also a recent article I'm to lazy to look up about the Norwegian transport company that converted their whole website of 83,000 lines of Elm code and are very satisfied; that is even more real world |
| 20:35:52 | disruptek | yikes. |
| 20:36:00 | disruptek | that seems like a huge amount of elm. |
| 20:36:48 | GordonBGood | The only two criticisms by that company were lack of type classes and function overloading, but they ended up kind of justifying even those |
| 20:37:44 | GordonBGood | IIRC, now up to 15 programmers, something like two or three years; they started gradually with just a small part and as things worked out went with the whole thing |
| 20:37:46 | disruptek | "NoRedInk switched to Elm about two years ago, and 250k+ lines later, they still have not had to scramble to fix a confusing runtime exception in production." |
| 20:38:55 | GordonBGood | Well, unlike what they say, it IS possible to have runtime exceptions in Elm, but they are likely right that they are likely not "confusing" as in not difficult to find |
| 20:39:13 | GordonBGood | The Elm compiler is written in Haskell |
| 20:39:55 | disruptek | i just... don't know how to justify that quantity of such a language. |
| 20:40:31 | disruptek | if i'm gonna write something big, i want something pretty muscular. |
| 20:41:28 | GordonBGood | Well, JS output can be pretty muscular these days, JS engines can produce code that is about the same speed as any VM |
| 20:42:07 | GordonBGood | And WPA's and SPA's are getting to be the rage when they can be used: trivial installation without a "store" |
| 20:44:10 | GordonBGood | My main quibble with Elm and why I would likely choose Fable/F# for such an application is that immutable is strictly enforced even more than Haskell, where one can wrap mutation in monads and drop to primitive ops where necessary |
| 20:44:16 | disruptek | trying to decide if i would write something big in nim right now. |
| 20:45:24 | disruptek | probably not. |
| 20:45:46 | GordonBGood | If one wants mutation for graphics or math power, one has to communicate with JS, and Evan/Elm strictly controls that; to the point that a memoizing lazy list is impossible to use |
| 20:46:35 | disruptek | which kinda defeats a lot of the appeal of such a platform. |
| 20:47:25 | GordonBGood | I wouldn't be afraid to write something fairly big in Nim other than if it needed multi-threading except that, in spite of version 1.0; I don't know how it is going to stay "stable" with all the proposals and fixes that are actaully required |
| 20:48:54 | GordonBGood | If you are talking about Elm; yes, I would choose F#/Elm for something big, but I guess the needs of the Norway company didn't extend beyond what Elm supports |
| 20:49:20 | disruptek | i haven't written enough, but i don't think the story on larger apps is all that clear. |
| 20:50:04 | disruptek | there are some fairly large holes, too. |
| 20:50:18 | * | GordonBGood quit (Read error: Connection reset by peer) |
| 20:51:33 | * | GordonBGood joined #nim |
| 20:51:58 | GordonBGood | Nah, me either, I get bored with one-man large apps and won't join something big at tis stage |
| 20:53:12 | GordonBGood | Joining a group such as this is likely a good space for my "talents" or lack of them |
| 20:54:21 | GordonBGood | I sometimes feel a bit out classed by you younger CS types, but I somehow seem to manage to get up to speed - the fun is in the challenge |
| 20:54:45 | FromGitter | <alehander42> age is good |
| 20:54:59 | disruptek | nim has good bones. there's a lot to contribute, even if it's just to test stuff. it sometimes feels like there are so few people using this thing that misbehavior goes undetected for too long. |
| 20:55:35 | GordonBGood | Yes, I can really contribute in more extensive tests if nothing else |
| 20:55:54 | GordonBGood | alehandler: well, hello, OAP |
| 20:56:10 | FromGitter | <alehander42> i am slightly interested in fuzzing lately |
| 20:56:19 | disruptek | i'm a mechanic; never went to school for cs. |
| 20:56:24 | FromGitter | <alehander42> but i've heard people say nim gets enough actual bugs currently |
| 20:56:38 | GordonBGood | fuzzing? ah fizzbuzz |
| 20:56:38 | disruptek | that's the case for almost anything you might want to fuzz. |
| 20:56:50 | FromGitter | <alehander42> hello gordon |
| 20:57:08 | FromGitter | <alehander42> well, no, like randomly generated tests property tests etc |
| 20:57:18 | FromGitter | <alehander42> i am also without finished cs ed |
| 20:57:57 | disruptek | they asked you not to come back, huh? |
| 20:58:27 | FromGitter | <alehander42> well, i just dropped out |
| 20:58:33 | FromGitter | <alehander42> without realizing i am dropping out |
| 20:58:39 | FromGitter | <alehander42> i found out years later |
| 20:58:46 | GordonBGood | I grew up in the age of main frames, which when I actually got access to one I found exhilerating, but didn't want to join the big orgs that a CS degree seemed to require at that tiime |
| 20:58:50 | FromGitter | <alehander42> that my "next year" thing is not likely |
| 20:59:06 | disruptek | ahh. |
| 20:59:32 | FromGitter | <alehander42> ive watched a video about some kid which got a mainframe |
| 20:59:38 | FromGitter | <alehander42> in his basement |
| 20:59:40 | FromGitter | <alehander42> fun stuff |
| 21:00:02 | GordonBGood | So I'm an electrical engineer, but became a "systems engineer" mixing cross disciplines including programming |
| 21:00:13 | FromGitter | <alehander42> i like the simplicity of the "older" computing: the "we can just write a new os in a month and see what happens" thing |
| 21:01:00 | GordonBGood | My carreer has spanned the life and death of DEC and the "beginning" of the Intell 4004, if you know what that was |
| 21:01:13 | FromGitter | <alehander42> electrical engineers are cool: you're one of those people that can play with a circuit board |
| 21:01:19 | GordonBGood | ^career |
| 21:01:38 | FromGitter | <alehander42> i would be impressed if you had a carrier |
| 21:01:46 | FromGitter | <alehander42> i dont |
| 21:01:54 | GordonBGood | Yeah, we used to design circuit boards and pump out a prototype in a couple of days |
| 21:02:55 | disruptek | what did you think of tracey kidder's book? |
| 21:04:42 | * | luis__ joined #nim |
| 21:06:37 | GordonBGood | The Soul of a New Machine? That was happening while I was still in uni, mostly. My career has revolved entirely around what we used to call microprocessors, now just all CPU's and SOC's |
| 21:07:57 | GordonBGood | Actually was happening just after I was in uni when mini computer manugacturers through they still had a significant "niche" |
| 21:07:57 | disruptek | yeah, just curious how it struck you since you were a little less removed from that era. |
| 21:08:14 | GordonBGood | I was allready working along the lines of what we have now |
| 21:08:28 | disruptek | i see. |
| 21:09:23 | disruptek | that hardware isn't uncommon on ebay but it's pretty hard to get it working if you don't have parts reserves and experience and even, in some cases, licenses. |
| 21:10:54 | GordonBGood | That whole minicomputer culture described in the book was real, but I've never workied within the confines of a large organization as described because "nicro" allowed smaller groups to compete |
| 21:11:26 | disruptek | right; makes sense. |
| 21:12:11 | disruptek | it's been such an amazing growth story. hard to really convey to younger folks what a shift it has been. |
| 21:13:00 | GordonBGood | I once had an employee who bought an old IBM line printer that was being sold for scrap for the novelty that it contained a one farad capacitor |
| 21:13:14 | GordonBGood | Yeah, what a shift |
| 21:13:41 | GordonBGood | In uni, the research dept thought they were leading edge using DEC minis |
| 21:14:26 | GordonBGood | The line printer could only be moved with a crane, something like a half ton to a ton |
| 21:14:27 | disruptek | doesn't matter what it is, it's immediately obsolete. |
| 21:15:22 | GordonBGood | He asked if he though I could get it working with his original IBM PC - I replied that if the think still worked, of course I could build an interface, but what would be the point? |
| 21:15:55 | * | luis__ quit (Quit: luis__) |
| 21:16:01 | GordonBGood | The same would apply to getting ebay DEC's working - what's the point other than for a museum? |
| 21:16:10 | disruptek | i'm sure it had some simple serial interface, but yeah. |
| 21:16:17 | disruptek | even the museums don't want this stuff. |
| 21:16:29 | disruptek | you go to bletchley park and it's just rooms full of junk. |
| 21:16:52 | disruptek | i'm not including colossus in that statement, but you know... |
| 21:17:03 | GordonBGood | And who other than OAP's like me would even know what it once was |
| 21:17:09 | disruptek | same with the computer museum in CA. |
| 21:17:11 | * | luis__ joined #nim |
| 21:17:28 | * | Trustable quit (Remote host closed the connection) |
| 21:17:42 | disruptek | a friend wanted to donate a hardware turing computer. i couldn't give it away. |
| 21:17:49 | * | narimiran quit (Remote host closed the connection) |
| 21:18:17 | disruptek | mechanical, i mean. |
| 21:18:35 | disruptek | i think it's at the ford museum now. |
| 21:18:53 | GordonBGood | I think the line printer interface was parallel, serial was pretty slow in those days |
| 21:19:35 | disruptek | https://www.thehenryford.org/collections-and-research/digital-collections/artifact/449880 |
| 21:19:47 | GordonBGood | Something one of a kind might appeal to some |
| 21:20:02 | disruptek | i doubt it was parallel. |
| 21:21:48 | disruptek | i mean, look at that thing. |
| 21:21:55 | GordonBGood | Yeah, I looked at the spec's but it was too long ago to remember |
| 21:23:19 | GordonBGood | Yeah, look at it, but at least it doesn't weigh a ton and take a whole room to store |
| 21:24:07 | disruptek | i saw eniac at upenn when i was a kid; ridiculous. |
| 21:24:35 | GordonBGood | Rediculous to us now; not to them at the time |
| 21:24:46 | disruptek | i guess it's open to the public now, but it was a big deal to get to see it then. |
| 21:24:57 | * | jjido quit (Quit: Textual IRC Client: www.textualapp.com) |
| 21:25:15 | GordonBGood | Not still operable, surely? |
| 21:26:08 | disruptek | no, but i guess it mattered to some political nutjob at penn. |
| 21:26:34 | GordonBGood | Ah... |
| 21:27:13 | disruptek | a friend worked with eckert, so was able to gimme a tour. |
| 21:27:28 | GordonBGood | Neat... |
| 21:27:44 | disruptek | yeah, this is the guy that invented mercury memory. |
| 21:28:30 | GordonBGood | I've forgetten about mercury memory if I ever knew it... |
| 21:28:42 | disruptek | you didn't miss anything. |
| 21:29:01 | disruptek | https://en.wikipedia.org/wiki/Delay_line_memory |
| 21:31:52 | GordonBGood | My first knowledge of volatile memory was TTL memory boards for DEC at somethhing like $10,000 for four kilobytes and the Intel 4004 "kit" which came with a 32 word memory chip worth probably something like $10 |
| 21:33:30 | disruptek | yeah, i remember that stuff. someone'd have a plastic tube of chips and it was like seeing a bag of cocaine. |
| 21:33:35 | GordonBGood | Wow, who would have though they could even make such a thing work reliably enough |
| 21:33:45 | disruptek | i know, it's nuts. |
| 21:34:45 | disruptek | i mean, your memory ran faster or slower depending on ambient temperature ffs. |
| 21:35:09 | GordonBGood | Anyway, it's nice chatting for a change, but it is delaying getting to looking into the --gc:destructors bug to do with seq memory leaks |
| 21:35:34 | disruptek | i don't want to hold you from that important work. 😄 |
| 21:35:55 | GordonBGood | So I should really get back to that, but on the other hand, maybe not - it's my bd |
| 21:36:47 | disruptek | ah, then you must enjoy yourself. go fix some bugs. 😁 |
| 21:36:58 | GordonBGood | I'm driven to see what a Nim with an alternate MM system to GC will work like |
| 21:38:51 | GordonBGood | GC, as in Boehm, works ok, but everybody turns to GC, as a potential systems language, I'd like to see Nim have something else, at least as a solid option |
| 21:39:06 | GordonBGood | That isn't manual MM |
| 21:39:30 | disruptek | it's definitely a killer app. |
| 21:39:47 | GordonBGood | Yeah, I hope so |
| 21:40:23 | GordonBGood | Anyway, bye for now, thanks for the tips on who's sho and the chat |
| 21:40:34 | disruptek | sure thing, have a good one. |
| 21:43:18 | * | nsf quit (Quit: WeeChat 2.6) |
| 21:44:50 | * | GordonBGood quit (Ping timeout: 240 seconds) |
| 21:47:57 | * | skellock joined #nim |
| 21:49:39 | shashlick | @arnetheduck sorry was away |
| 21:50:02 | shashlick | Why are you linking local deps with vendoring? That's not the goal |
| 21:50:09 | shashlick | The goal is isolation during dev |
| 21:50:32 | shashlick | And to get to a good lock file you need to get the deps in a working condition |
| 21:50:42 | shashlick | Local deps give you isolation |
| 21:51:00 | shashlick | Then you can create your lock file and then your users can install it however |
| 21:51:09 | shashlick | This is step 1 |
| 21:51:54 | shashlick | If someone wants to check in their deps folder, that's their choice but it has nothing to do with distribution as noted in the gist |
| 21:58:09 | * | skellock quit (Quit: WeeChat 2.6) |
| 22:07:04 | * | luis__ quit (Remote host closed the connection) |
| 22:16:58 | federico3 | can i run startProcess without capturing the stdout? |
| 22:17:15 | disruptek | yep. |
| 22:17:37 | disruptek | you can send it to parent streams or just hope you don't have too much output, i guess. |
| 22:19:16 | federico3 | poParentStream |
| 22:19:20 | disruptek | yeah. |
| 22:19:27 | federico3 | the doc is the opposite of intuitive :D |
| 22:19:46 | disruptek | it's not brilliant, no. 😆 |
| 22:20:12 | disruptek | also remember to catch the exit signal fd if you're doing that. |
| 22:20:17 | federico3 | I feel like we need a flowchart |
| 22:20:48 | Zevv | I feel like the execprocess and friends could do with some major rework. I started some of that some time ago but abanoned because |
| 22:20:54 | federico3 | yes |
| 22:21:15 | Zevv | even the compiler itself suffers from its flaws |
| 22:21:48 | Zevv | sorry, "flaws" is too negative, just from "the way it is implemented now" |
| 22:22:28 | disruptek | maybe i'll fork it for when i impl nim-expect. 😛 |
| 22:22:43 | Zevv | I know how to do a lot of this stuff properly on linux/posixy, but the windows parts elude me |
| 22:22:52 | disruptek | you're nominated. |
| 22:23:00 | Zevv | i need a friend |
| 22:23:05 | FromGitter | <alehander42> i almost started my mini os kernel toy |
| 22:23:14 | Zevv | to help me with the windows implementation |
| 22:23:28 | Zevv | no, you should almost *finish* it instead :) |
| 22:23:30 | FromGitter | <alehander42> i am at the point where i am trying to get var context = Context() to not crash |
| 22:23:35 | disruptek | i'm not friends with anyone who runs windows. |
| 22:23:44 | Zevv | same here. true story. |
| 22:23:56 | FromGitter | <alehander42> so can i get `-d:useMalloc` only with --newruntime ? |
| 22:24:30 | FromGitter | <alehander42> i love water |
| 22:24:37 | FromGitter | <alehander42> ah thats what thirst does |
| 22:24:43 | skrylar[m] | @eacyy it gets vomited as a bunch of separate chat lines via the irc bot |
| 22:24:55 | Zevv | I'm not sure. i needed something similar a few months ago but i didnt know about :usemalloc, so I added an os to the nim compiler with very basic mallocs |
| 22:25:03 | Zevv | probably not the way t ogo, but it worked for me |
| 22:26:02 | Zevv | that did work out quite well in the end with newruntime though |
| 22:31:01 | Araq | Zevv, we tried to fix osproc's bugs but they are nasty. I happen to like the API but surely it could be improved. |
| 22:31:32 | Zevv | a good api is though here |
| 22:31:45 | Zevv | as everywhere |
| 22:31:50 | FromGitter | <alehander42> hm, so malloc + free should be enough for newruntime -d:useMalloc bare metal |
| 22:31:58 | FromGitter | <alehander42> right |
| 22:33:18 | Zevv | alehander42: my problem was that nim does its own management of memory chuks as a workaround for inefficient malloc implementations, so it always starts with allocing in pretty large chunks. not sure if that logic is above or below :usemalloc |
| 22:33:55 | Zevv | something is always allocing 512kb, iirc |
| 22:34:51 | disruptek | story of my life. |
| 22:35:13 | FromGitter | <alehander42> yeah but it seems newrutime -d:usemalloc just calls malloc in nimNewObj |
| 22:35:21 | FromGitter | <alehander42> otherwise i also saw the thing you describe |
| 22:35:33 | Zevv | so, i missed something obvious there :) |
| 22:36:02 | Araq | there is now also --gc:destructors -d:useMalloc so that you can use all of Nim, no 'owned' annotation. but it's WIP |
| 22:36:55 | Zevv | so its ready enough to try? sweet will do that! |
| 22:37:34 | Zevv | the community (or at least 1 member) is pretty confused about availble memory management models and their state these days :) |
| 22:37:48 | Araq | I know, it's being sorted out |
| 22:38:12 | Zevv | which is actually pretty cool, as it shows the language is so flexible that all these experiments just fit in the languge implementation |
| 22:38:40 | Araq | the plan is that in the end 2 options remain: --gc:destructors and --gc:boehm, one for latency and embedded or really big heaps, the other for throughput |
| 22:39:30 | Araq | but support a custom destructors and a shared heap. |
| 22:39:37 | Zevv | so newruntime was valuable as a learning experiment but will die? |
| 22:40:14 | Araq | I might use the 'owned' annotation for further optimizations |
| 22:41:09 | Zevv | I never managed to ownedize some of my code, ran around in circles but couldnt get the compiler happy. just as with the json lib. I guess its intrinsincially hard with some models |
| 22:41:38 | Araq | and rayman22201's research projecct is whether 'async' can work with --newruntime |
| 22:41:52 | Zevv | yeah, he never asked for that :) |
| 22:42:11 | Zevv | he just kind of ran into it I believe |
| 22:42:29 | Araq | well we discussed it |
| 22:42:53 | Zevv | ah ok didnt know that, good job rayman22201! |
| 22:43:14 | FromGitter | <alehander42> araq hm i can try it |
| 22:43:21 | Araq | json.nim should be easy to port to 'owned' once you annotated the collection libraries too |
| 22:43:23 | FromGitter | <alehander42> what does --gc:destructors do |
| 22:43:40 | FromGitter | <alehander42> hm, this worded until now, my next error is for var a = "ls" |
| 22:43:47 | FromGitter | <alehander42> error: dereferencing pointer to incomplete type 'AllocatorObj' {aka 'struct AllocatorObj'} ⏎ (*dest).p->allocator->dealloc((*dest).p->allocator, (*dest).p, (*dest).p->cap + 1 + sizeof(NI) + sizeof(void*)); } |
| 22:43:51 | FromGitter | <alehander42> cool |
| 22:44:37 | Zevv | cmon thats soooo obvious, its there in the error message |
| 22:45:04 | Araq | alehander42: no idea where this bug comes from, but can't be hard to fix |
| 22:45:11 | Zevv | ha |
| 22:45:40 | Araq | --gc:destructor throws away the GCs and replaces it with good old refcounting |
| 22:46:05 | Zevv | that is soo 80's |
| 22:46:12 | Araq | kinda sad I know. we can optimize the overhead to acceptable levels though |
| 22:47:14 | Zevv | if its effective and it works, so what. things were tried, a lot was learned on the way. |
| 22:48:02 | Araq | oh I'm also using about 90% of the implementation |
| 22:48:44 | Araq | so very little effort was "wasted" indeed. |
| 22:49:20 | FromDiscord | <yewpad> Any Linux users here? |
| 22:49:25 | Zevv | some |
| 22:49:44 | FromGitter | <alehander42> hm, it seems AllocatorObj is defined in stdlib_allocators.nim.c. |
| 22:49:56 | FromGitter | <alehander42> and i am probably not compiling them correctly together with stdlib_system |
| 22:50:13 | FromDiscord | <yewpad> I need some recommendations. Lightweight, should look somewhat modern, focus on efficiency, I don't care about security. |
| 22:50:24 | Zevv | lightweight *what*? |
| 22:50:35 | FromDiscord | <yewpad> lightweight linux distro |
| 22:51:14 | * | solitudesf quit (Ping timeout: 246 seconds) |
| 22:51:37 | Zevv | oh dunno, I don't care too much for distros, too lazy. I always pick debian, its lightweight and looks somewhat modern. it also focusess on efficience, but not sure if that is what you are looking for of course |
| 22:51:59 | FromDiscord | <yewpad> I had some bad experiences with Debian's mirrors |
| 22:52:07 | Araq | https://distrowatch.com/ --> "Mx Linux" |
| 22:52:21 | Zevv | there you go |
| 22:52:26 | FromDiscord | <yewpad> Debian's gnome based, isn't it? |
| 22:52:43 | Zevv | no, it is agnostic |
| 22:54:02 | FromDiscord | <yewpad> Mx Linux ain't gonna do it for me |
| 22:56:18 | stefantalpalaru | Y'er a newbie, Harry! Use Mint Linux or Ubuntu. |
| 22:56:35 | FromDiscord | <yewpad> I'll go with Pop Os |
| 22:56:45 | skrylar[m] | SuSE here |
| 22:57:03 | FromGitter | <alehander42> hm, Araq i get system needs nimRawDispose |
| 22:57:08 | FromGitter | <alehander42> with --gc:destructors |
| 22:59:45 | Araq | you need nim devel |
| 23:00:12 | FromGitter | <alehander42> i use it |
| 23:00:31 | FromGitter | <alehander42> with ⏎ --os:standalone ⏎ --noMain ⏎ --deadCodeElim:off ⏎ --cpu:i386 ... [https://gitter.im/nim-lang/Nim?at=5dbe0a8fa85791488f895bba] |
| 23:02:00 | Araq | wtf? |
| 23:02:05 | Araq | --deadCodeElim:off? |
| 23:02:13 | Araq | --os:standalone? |
| 23:03:03 | Araq | 'standalone' is not yet supported I guess |
| 23:03:17 | Zevv | back to the newruntime for you |
| 23:05:25 | FromDiscord | <mratsim> @yewpad, the big question with Linux is how much time do you want to spend or how much you wantto learn the internals of system administration |
| 23:05:59 | FromDiscord | <yewpad> I don't really care about the internals. I'm a software developer, I just want it to work and do its job |
| 23:06:25 | FromGitter | <alehander42> hm, probably dont need the deadCode one |
| 23:06:32 | FromDiscord | <mratsim> I use Debian to manage my home server (run a virtualization host + containers) and arch for my work machine and all the containers on that server |
| 23:06:36 | FromGitter | <alehander42> well --os:standalone because i was trying it on bare metal |
| 23:06:39 | Zevv | just pick a debian flavour, ubuntu, xubuntu, whatever |
| 23:06:40 | FromGitter | <alehander42> kinda |
| 23:06:44 | Calinou | maybe Fedora? |
| 23:06:52 | FromDiscord | <yewpad> PopOs is Ubuntu flavoured |
| 23:06:57 | FromDiscord | <mratsim> yeah agree, pick an Ubuntu or Fedora then |
| 23:06:59 | Calinou | it offers recent packages, but is still quite stable, I'd say it's a good choice for developers |
| 23:07:00 | FromGitter | <alehander42> it kinda runs now with standalone and newruntime |
| 23:07:12 | FromGitter | <alehander42> with some patches to the c files |
| 23:07:16 | FromDiscord | <mratsim> though Fedora I seem to always get into SELinux issues for some reasons |
| 23:07:18 | FromGitter | <alehander42> very simple patches |
| 23:08:00 | FromDiscord | <mratsim> @Araq: for your threading API, don't forget a barrier API, there is no barriers right now in Nim so I had to implement my own. |
| 23:08:28 | FromDiscord | <mratsim> If you know your way around windows barrier that would be helpful as well |
| 23:09:21 | FromDiscord | <mratsim> nothing fany, I only need init, wait and destroy: https://github.com/mratsim/weave/blob/master/picasso/primitives/barriers.nim#L32-L50 |
| 23:09:21 | FromGitter | <Willyboar> I use elementary OS to my second computer and i like it a lot. |
| 23:09:51 | * | exelotl quit (Ping timeout: 250 seconds) |
| 23:26:20 | Araq | mratsim: barrier == threadpool's sync? |
| 23:33:38 | FromDiscord | <mratsim> I'm think that won't work for me, there is no shared memory besides channels so you can't access a worker.ready variable |
| 23:33:45 | FromDiscord | <mratsim> I think* |
| 23:36:48 | FromDiscord | <mratsim> I'm guessing I just need that: https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-entersynchronizationbarrier |
| 23:39:32 | * | exelotl joined #nim |
| 23:47:20 | Araq | a barrier is just a condition variable on the condition counter == N |
| 23:47:49 | Araq | if not, it's because I'm tired and working on something else :P |
