| 00:12:24 | * | Hideki_ quit (Remote host closed the connection) |
| 00:13:12 | * | Hideki_ joined #nim |
| 00:15:06 | * | luis__ joined #nim |
| 00:17:17 | * | Hideki_ quit (Ping timeout: 240 seconds) |
| 00:43:24 | * | luis__ quit (Ping timeout: 252 seconds) |
| 00:48:28 | rayman22201 | @yumaikas, congrats! your article is #2 on HN right now :-D |
| 00:51:04 | * | Hideki_ joined #nim |
| 01:00:42 | FromGitter | <zacharycarter> anyone know how `outdir` works with nimterop and `getHeader` ? |
| 01:01:07 | FromGitter | <zacharycarter> I keep getting an error about missing build files even though I'm using the -d:xxxGit and -d:xxxStatic flags |
| 01:01:50 | * | Hideki_ quit (Ping timeout: 265 seconds) |
| 01:03:59 | FromGitter | <zacharycarter> ah never mind I figured out the issue |
| 01:08:16 | FromGitter | <zacharycarter> meh - I can't get passed this error: No build files found in |
| 01:08:21 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 01:19:31 | shashlick | Sup |
| 01:19:52 | shashlick | What's your code look like |
| 01:20:13 | shashlick | @zacharycarter ^^ |
| 01:22:26 | FromGitter | <zacharycarter> shashlick - I just added a comment to this issue: https://github.com/nimterop/nimterop/issues/57 |
| 01:22:40 | FromGitter | <zacharycarter> I think it's still a problem with enums that reference other values defined in the same enum |
| 01:23:49 | * | kevin joined #nim |
| 01:24:13 | * | kevin is now known as Guest73162 |
| 01:24:30 | FromGitter | <zacharycarter> I stopped using getHeader because of the `No build files found in` error |
| 01:24:44 | shashlick | What did you pass to getHeader |
| 01:24:49 | shashlick | I'll look into that issue |
| 01:24:57 | FromGitter | <zacharycarter> but before the code looked like: |
| 01:25:29 | FromDiscord | <slymilano> >Is Nim stable? I have vague memories that some parts of its runtime had some deep issues that weren't yet resolved, like maybe around concurrency? I see the language is at 1.0 now, does it have a stable, solid, dependable implementation and runtime? |
| 01:25:35 | FromDiscord | <slymilano> https://news.ycombinator.com/item?id=21393675 |
| 01:25:44 | FromDiscord | <slymilano> Really curious to hear what you guys say |
| 01:25:46 | FromGitter | <zacharycarter> https://gist.github.com/zacharycarter/4927871683a3bdd8284eb8a5b7785c99 |
| 01:26:02 | FromGitter | <zacharycarter> and I would run with: `nim c -d:sokol_gfxGit -d:sokol_gfxStatic .\sokol_gfx.nim` |
| 01:26:53 | FromGitter | <zacharycarter> slymilano: that's a pretty vague description of `deep issues` |
| 01:27:22 | shashlick | Let me try |
| 01:27:40 | shashlick | Your code set Defines is missing the L |
| 01:27:45 | FromDiscord | <slymilano> Yeah I figured it's vague |
| 01:27:55 | FromGitter | <zacharycarter> and I think the fact that the language is now 1.0 is an assertion from the author / contributors to the language that it is the things you asked about |
| 01:28:23 | FromGitter | <zacharycarter> err yeah sorry |
| 01:28:28 | FromGitter | <zacharycarter> that setDefines shouldn't be there |
| 01:29:00 | FromDiscord | <slymilano> oh i didn't ask the question, just saw it https://news.ycombinator.com/item?id=21392803 |
| 01:29:04 | FromGitter | <zacharycarter> since I'm setting the defines in `nim c` command |
| 01:29:57 | shashlick | I've not tested with _ |
| 01:30:08 | shashlick | Will need to see how the macros hold up |
| 01:30:23 | FromGitter | <zacharycarter> ah okay |
| 01:31:02 | shashlick | Linux? |
| 01:31:06 | FromGitter | <zacharycarter> Windows |
| 01:32:20 | FromGitter | <zacharycarter> slymilano: I guess the simple answer is yes - but there are all sorts of caveats and I think the question is flawed in the first place |
| 01:33:39 | FromGitter | <zacharycarter> You can achieve concurrency and parallelism in Nim |
| 01:34:50 | FromGitter | <zacharycarter> I'm guessing the author of - `I have vague memories that some parts of its runtime had some deep issues that weren't yet resolved, like maybe around concurrency` - is referring to the fact that the default GC imposes thread local heaps which can make sharing memory between threads tricky |
| 01:35:28 | FromGitter | <zacharycarter> but I don't think that has anything to do with a stable / solid / dependable implementation and runtime |
| 01:35:53 | FromGitter | <zacharycarter> also what person A might deem fitting the above criteria, person B might not |
| 01:37:12 | FromGitter | <zacharycarter> but as I mentioned previously, I think the fact that the language has crossed the v 1.0 threshold means the authors are asserting those things |
| 01:37:20 | FromGitter | <zacharycarter> ymmv |
| 02:26:00 | shashlick | @zacharycarter - sokol doesn't have any cmake, configure or makefiles |
| 02:26:04 | shashlick | there's nothing to build |
| 02:26:32 | shashlick | you really just need cImport |
| 02:44:09 | * | Guest73162 quit (Quit: Leaving) |
| 02:44:24 | * | Guest73162 joined #nim |
| 02:50:49 | * | seni quit (Quit: Leaving) |
| 02:51:39 | * | Guest73162 quit (Quit: Leaving) |
| 02:54:48 | * | Guest6403 joined #nim |
| 03:10:32 | * | FreshcollegeGirl joined #nim |
| 03:19:16 | * | rockcavera quit (Remote host closed the connection) |
| 03:19:26 | * | tamago324 joined #nim |
| 03:21:34 | * | tamago324 quit (Remote host closed the connection) |
| 03:22:56 | leorize | more nim on HN and the first thing people complain is still style-insensitivity :p |
| 03:24:25 | * | tamago324 joined #nim |
| 03:55:48 | FromGitter | <zacharycarter> shashlick: ah okay, I thought you could just download and prepare the header with getHeader but I guess not |
| 03:56:00 | FromGitter | <zacharycarter> it's always the first complaint |
| 04:07:03 | * | Guest6403 quit (Quit: leaving) |
| 04:07:49 | * | kevin joined #nim |
| 04:07:51 | shashlick | that's what gitPull does pretty much |
| 04:07:56 | * | kevin is now known as Guest94183 |
| 04:08:10 | yumaikas | o/ |
| 04:11:33 | yumaikas | Do we have some way to leave messages in here? |
| 04:11:39 | yumaikas | !leavemessage |
| 04:11:43 | yumaikas | hrm.... |
| 04:11:47 | yumaikas | !bot |
| 04:11:59 | disruptek | shashlick: https://github.com/disruptek/nimph |
| 04:24:57 | * | Guest94183 quit (Ping timeout: 240 seconds) |
| 04:38:26 | * | dddddd quit (Ping timeout: 240 seconds) |
| 04:46:18 | * | nsf joined #nim |
| 04:54:31 | leorize | yumaikas: leave message? |
| 04:56:08 | yumaikas | leorize: Like, a bot where you can ask it to let someone know something next time they are active. It's a feature of some IRC channels I've been in elsewhere |
| 04:56:26 | leorize | we don't have that :P |
| 04:56:48 | disruptek | i usually just send them a virus. |
| 04:56:54 | disruptek | perks 'em right up. |
| 04:57:17 | yumaikas | leorize: You think it would be a bad thing to keep up and running here? |
| 04:57:34 | leorize | I think it's fine |
| 04:57:41 | leorize | although you can just point ppl to logs :P |
| 04:58:32 | * | chemist69_ joined #nim |
| 04:58:56 | * | Hideki_ joined #nim |
| 05:00:37 | yumaikas | You can, I suppose I might. Just wanted to chat with dom96 some is all |
| 05:00:54 | leorize | oh, dom96 has a bouncer here |
| 05:01:02 | leorize | just ping him |
| 05:01:34 | * | chemist69 quit (Ping timeout: 265 seconds) |
| 05:02:11 | yumaikas | @dom96? |
| 05:02:15 | yumaikas | or just his nick? |
| 05:02:31 | * | yumaikas has weechat in a VPS watching here |
| 05:02:37 | FromDiscord | <Rika> doesnt matter really does it |
| 05:02:45 | leorize | it's irc, just the nick is fine |
| 05:03:01 | yumaikas | Fair enough. IDK what he's got set to highlight |
| 05:03:14 | * | Hideki_ quit (Ping timeout: 240 seconds) |
| 05:03:27 | disruptek | what is OCB Amazon Neptune and why did it cost me $1000 last month? 🙁 |
| 05:03:42 | FromDiscord | <Rika> rip |
| 05:13:24 | disruptek | very odd. it's like, in addition to the normal ~$300 rate i usually pay, but i've never gotten this line item before. |
| 05:15:22 | yumaikas | Rika, leorize: Y'all running anything publicly written in Jester, with source available? |
| 05:16:19 | FromDiscord | <Rika> nope, im pretty new to the language, and im still stuck converting a medium sized python lib to pure nim |
| 05:16:55 | yumaikas | Ok. Looking for examples to list in a promotional docs-site I'm working on atm |
| 05:17:58 | FromDiscord | <Rika> what intuitions do you all have regards ref object vs object, because i cant decide if this one type should be heap or stack allocated xd |
| 05:18:08 | disruptek | ref. |
| 05:18:38 | yumaikas | Rika: I'd need more context |
| 05:18:54 | yumaikas | If it's going to be mutated from procs a lot, I'd say go with ref object |
| 05:19:14 | FromDiscord | <Rika> hmm the fields are mutated |
| 05:19:33 | FromDiscord | <Rika> i'll make it a ref i think |
| 05:19:50 | FromDiscord | <Rika> i can only recall fields being passed into procs and being mutated |
| 05:19:52 | yumaikas | Also, if you're coming from pthong, I think that ref object is probably going to be closer to what you might expect |
| 05:20:03 | FromDiscord | <Rika> pthong. |
| 05:20:32 | yumaikas | derp |
| 05:20:35 | yumaikas | *python |
| 05:20:37 | FromDiscord | <Rika> wonder how much impact a ref object has on performance though, if any at all |
| 05:20:48 | yumaikas | Depends on your use case |
| 05:21:03 | yumaikas | Worst comes to worst, measure it both ways |
| 05:21:21 | FromDiscord | <Rika> i'll be instantiating 10s of thousands of these and storing it in memory |
| 05:21:55 | yumaikas | That sounds like something to profile then. What is the context for this? |
| 05:21:59 | FromDiscord | <Rika> rather, not storing it in memory but destroying them again then reinstantiating when necessary (its not my lib...) |
| 05:22:44 | yumaikas | (To be clear, I don't have an answer for how this should be done) |
| 05:22:44 | FromDiscord | <Rika> here's the lib im moving https://github.com/llllllllll/slider |
| 05:24:00 | FromDiscord | <Rika> the `Beatmap` class in `beatmap.py` is what i'm moving (i kinda fixed the "christ almighty thats a lot of fields" issue) |
| 05:25:35 | yumaikas | Ok. Well, I'm not an expert in this. I think I'd start without making it a ref, and then pass refs where they are needed |
| 05:25:54 | yumaikas | but, like I said, I'd measure it if performance is a sticking point |
| 05:26:26 | FromDiscord | <Rika> hmm |
| 05:26:32 | yumaikas | The nim *should* be faster than the python, at least for stuff that isn't accelerated by C libraries under the hod |
| 05:26:33 | FromDiscord | <Rika> well ill just figure it out i guess ;; |
| 05:26:54 | FromDiscord | <Rika> this class is pure python so it should be okay |
| 05:27:46 | FromDiscord | <Rika> it takes a few seconds parsing a thousand of the files (converting to the class) so it should be fine right ;; |
| 05:30:40 | yumaikas | When it comes to performance, it all depends on if you can afford to do less |
| 05:31:59 | FromDiscord | <Rika> do keyword-only arguments exist in nim? |
| 05:33:11 | yumaikas | Not as such, I don't think |
| 05:33:27 | FromDiscord | <Rika> https://github.com/nim-lang/Nim/issues/9036 darn |
| 05:33:31 | yumaikas | I know that htmlgen uses macros to get halfway there |
| 05:34:33 | * | jwm224 joined #nim |
| 05:34:52 | FromDiscord | <Rika> eeeeeeee i dont think im that desperate to get there |
| 05:35:50 | yumaikas | Now, if you're ok with them also being positional, I think you have args be specified with keywords, so long as you provide a default value? |
| 05:35:52 | * | kevin joined #nim |
| 05:35:56 | yumaikas | I could remember wrong |
| 05:36:14 | * | kevin is now known as Guest96537 |
| 05:38:22 | FromDiscord | <Rika> ill just trust whoever would use this weird ass library to pass it keyworded |
| 05:41:18 | yumaikas | Rika: Have your examples pass it keyworded, that should make it a *lot* more likely that other people do |
| 05:42:00 | FromDiscord | <Rika> oh no i havent put docu on this lib yet 😰 |
| 05:42:30 | FromDiscord | <Rika> aaaaaaa ill do it when i finish (also damn i need to put this in git with proper commits too oh no) |
| 05:43:07 | * | Guest96537 quit (Quit: leaving) |
| 05:43:44 | * | kevin_ joined #nim |
| 05:49:32 | * | theelous3_ quit (Read error: Connection reset by peer) |
| 05:52:02 | yumaikas | dom96: I have a start on a docs repo up at https://github.com/yumaikas/jester-docs, and apparently we had met improperly before: https://news.ycombinator.com/item?id=18139797 |
| 05:57:16 | * | sagax quit (Ping timeout: 252 seconds) |
| 06:02:50 | * | FreshcollegeGirl quit (Ping timeout: 240 seconds) |
| 06:06:31 | * | theelous3 joined #nim |
| 06:11:06 | FromDiscord | <Rika> ooh thats cool |
| 06:14:40 | * | LargeEpsilon joined #nim |
| 06:34:42 | * | narimiran joined #nim |
| 06:39:25 | Araq | what's an "improper meeting"? |
| 06:41:20 | FromDiscord | <Rika> unaware meeting? |
| 06:45:04 | narimiran | nim bingo, there is a new nim thread on HN, can you guess the top-voted comment? |
| 06:45:35 | * | solitudesf joined #nim |
| 06:49:36 | Araq | some bullshit about something that never comes up in practice |
| 06:51:24 | narimiran | i wrItE mY cODe liKE tHiS |
| 06:58:54 | FromGitter | <SolitudeSF> and the comment right below it gives wrong examples of style insensitivity. the classic. |
| 06:59:20 | Araq | yes and in Java you can write it like this: |
| 06:59:23 | Araq | \u0069\u0020\u0077\u0072\u0049\u0074\u0045\u0020\u006D\u0059\u0020\u0063\u004F\u0044\u0065\u0020\u006C\u0069\u004B\u0045\u0020\u0074\u0048\u0069\u0053 |
| 06:59:48 | Araq | because Java allows for Unicode inputs in non-string-literals |
| 07:00:00 | * | gmpreussner_ quit (Quit: kthxbye) |
| 07:00:47 | Araq | there are good reasons for not using Java, this is not one of these. |
| 07:02:35 | Araq | now back to my precious command line where I have to type 'gcc' even though the program is called GCC |
| 07:03:16 | Araq | and back to browsing where every url starts with 'https' even though I'm pretty sure it should be HTTPS |
| 07:04:52 | * | gmpreussner joined #nim |
| 07:15:20 | FromDiscord | <Rika> but my grep |
| 07:15:21 | FromDiscord | <Rika> :V |
| 07:21:08 | GordonBGood | Araq: and a link to an interview with you that was actually quite informative for a short interview (SoftwareSource), but all of his interviews aren't dated on the website, so can't tell how relevent they are |
| 07:22:00 | GordonBGood | Sorry, (SourceSort) |
| 07:22:50 | GordonBGood | I assumed the interview came after the buzz about version 1.0, but I don't think it says anywhere |
| 07:25:57 | GordonBGood | Araq: I went back and closely looked at your araq-refcounting branch; there are a couple of things I notices; would you like me to file comments in issues there or chat about them first here? |
| 07:26:09 | GordonBGood | There are just a couple of observations... |
| 07:26:59 | Araq | GordonBGood: the interview is about 2 weeks old |
| 07:27:16 | GordonBGood | Thank you on the interview |
| 07:27:38 | Araq | and yeah ask here |
| 07:27:52 | GordonBGood | Okay, here goes: |
| 07:27:54 | Araq | the branch is WIP btw, I'm finishing the refcount implementation |
| 07:28:23 | Araq | the idea is that --gc:destructors is the new mode |
| 07:28:31 | GordonBGood | I assume you intented that the --gc:destructors and --gc:hooks seem to do about the same thing? |
| 07:28:47 | Araq | no |
| 07:28:55 | Araq | --gc:destructors == refcounting |
| 07:29:01 | GordonBGood | The mode is --gc:destructors, but it has a --gc:hooks option? |
| 07:29:02 | Araq | --gc:hooks == araqsgc |
| 07:29:38 | GordonBGood | Yes, currently --gc:hooks is araqsgc, but it opens the door to others in the future? |
| 07:30:10 | Araq | well it's hooks |
| 07:30:32 | Araq | you can write your own GC via it but it needs more hooks for this to work out |
| 07:30:36 | GordonBGood | Okay, I'll reread it again in the view that destructors is the mode, hooks is an available option on top of destructors |
| 07:31:29 | GordonBGood | Yes, we discussed the "more hooks" required; let it ride for now as it likely isn't that important |
| 07:31:32 | Araq | I think --gc:hooks is a deadend, as I said, too many proc vars would be involved to the point we're better off with a swappable mmdisp.nim implementation or something |
| 07:32:32 | GordonBGood | Hmm, that's interesting that you are starting to see --gc:hooks that way |
| 07:32:53 | Araq | '=' and '=destroy' and '=sink' are static constructs, more efficient than runtime hooks and we need to stick to one thing and make it work really well |
| 07:33:30 | Araq | enough experimentation, it's time to decide on a design and to stick with it |
| 07:33:47 | GordonBGood | My other observation is that destructors and or hooks have optSeqDestructors in the option set but as currently written they also need to declare nimSeqsV2 just as newruntime does? |
| 07:34:17 | GordonBGood | I'm with you there, there is already too much legacy code to worry about |
| 07:34:59 | GordonBGood | destructors/hooks can't work without nimSeqsV2 as they have already shed the cruft |
| 07:37:01 | GordonBGood | Just as newruntime has also shed the cruft and forces that destructors and nimSeqsV2 must be used |
| 07:40:46 | Araq | nimSeqsV2 is optSeqDestructors, I don't understand the question |
| 07:41:05 | Araq | other options also imply optSeqDestructors |
| 07:41:33 | * | filcuc joined #nim |
| 07:42:37 | GordonBGood | The comment is: you turn on optSeqDestructors, which tells the compiler what to do, but I think you also need to declare the symbol "nimSeqsV2" in order to make the when statements work? |
| 07:43:31 | GordonBGood | As currently written... |
| 07:43:43 | Araq | ah. good point, yes |
| 07:44:39 | GordonBGood | So, at least for now, we need to add the declarations of "nimSeqsV2" at the same time we turn on "optSeqDestructors", right? |
| 07:45:33 | Araq | right |
| 07:46:04 | GordonBGood | Finally, maybe you can help me shortcut some investigations on the "using seqsv2 everywhere" project, which is now my top priority: |
| 07:46:55 | GordonBGood | I've got the whole project mapped out and half finished, but I have some conflicts between using the new and old seqs (not at the same time, of course) |
| 07:47:33 | GordonBGood | I never liked the old seqs/strings, so up to now just used them as they seems to work and never really looked at the structure |
| 07:48:43 | GordonBGood | Now it seems I have never really understood how they were mapped into memory; I assume that there was an outer object that contained a ptr/ref just like the new ones, but it seems I was mistaken |
| 07:50:03 | GordonBGood | I'm now starting to come to the realization that the new seqsv2 do work like that, but the old ones were a stack location pointing to the whole GenericSeq object on the heap, right? |
| 07:50:26 | * | jjido joined #nim |
| 07:51:09 | Araq | right |
| 07:51:31 | Araq | old seq/string: a single pointer |
| 07:51:45 | Araq | new seq/string: a (len, pointer) pair |
| 07:52:00 | GordonBGood | I've just had a "whoops" moment when I realized that I was trying to pass the new seqsv2 outer object (containing the len) when the routines were expecting the old seq pointer |
| 07:52:45 | GordonBGood | So that seems to mean that in order to give the old code proc's what they expect, I'm going to have to pass them a pointer to the outer object, right? |
| 07:53:04 | GordonBGood | So a pointer to an object that then contains a pointer? |
| 07:53:42 | GordonBGood | I can do it, but it seems redundant somehow... |
| 07:54:15 | Araq | it's mind boggling for me too ;-) |
| 07:54:31 | Araq | it helps to look at how tyTuple is handled |
| 07:55:19 | GordonBGood | Well, I guess the most important thing is get it working first, and then look at tuning if possible later :) |
| 07:56:35 | GordonBGood | I really want to get this into devel so everybody can test it against their libraries, and hopefully so we can soon make it the default and get rid of the old version |
| 07:56:51 | GordonBGood | stake through the heart so it never comes back |
| 07:58:11 | GordonBGood | It seems to me that in addition to the reasons that you no longer find the old seqs acceptible as you stated a couple of days ago... |
| 07:59:15 | GordonBGood | They are also the reason the GC was/is so difficult to support, why a multi-threaded GC seemed so difficult, and therefore why a smoothly working multi-threading async is in the state it is |
| 07:59:38 | * | luis__ joined #nim |
| 07:59:57 | Araq | hardly, you can't blame seqs for MM being hard |
| 08:00:01 | GordonBGood | But that's just my (strongly held) opionion ;-) |
| 08:01:31 | GordonBGood | It seems to me that the whole deepCopy mess came about because of the difficulty of crossing seq's/string's/closure to different threads |
| 08:02:01 | Araq | no, it's a problem of threadlocal heaps |
| 08:02:27 | GordonBGood | It wasn't actually the seq's/string's/ref's I suppose, but the lack of destroy/move semantics, but now seq's (and I think closures) embrace that |
| 08:03:21 | * | gmpreussner_ joined #nim |
| 08:03:51 | GordonBGood | Yes, I understand that it was the problem of theadlocal heaps, but without the complexities of supporting seqs with cruft, it seems to me that something like a shared heap GC would have been much easier and likely done by now |
| 08:03:55 | * | krux02 joined #nim |
| 08:04:27 | * | gmpreussner quit (Ping timeout: 240 seconds) |
| 08:05:30 | GordonBGood | In order to make seqsv2 work with all the old MM, I'm having to make at least some minor changes in every GC implementation and adaptation, as they were all "hard coded" to GenericSeq |
| 08:06:01 | GordonBGood | Anyway, "water under the bridge", we are well on the way do doing it right now, I think |
| 08:06:44 | * | ng0 joined #nim |
| 08:07:40 | GordonBGood | With seqsv2, and if we didn't have to support the old seqs/strings/closures, each of the GC files would be simpler |
| 08:08:23 | GordonBGood | Araq: let me get back to work and not take up more of your time; thanks for the help |
| 08:12:41 | Zevv | Interesting: I have a workload thats 100% faster on 'nim c' then it is on 'nim cpp' |
| 08:19:20 | * | Vladar joined #nim |
| 08:28:09 | Zevv | Twice the cache misses on .cpp, hmmm |
| 08:31:49 | * | floppydh joined #nim |
| 08:40:11 | Araq | Zevv: my guess would be that c++'s name mangling on top of Nim's name mangling produces long internal identifiers |
| 08:40:18 | Araq | slowing everything down quite a bit |
| 08:40:25 | Zevv | at *run time* ? |
| 08:42:11 | * | tklohna_ joined #nim |
| 08:42:19 | Araq | oh I thought you were talking about the compile times |
| 08:43:06 | Zevv | nope :) |
| 08:43:35 | Araq | https://github.com/nim-lang/Nim/pull/12550 is 'outplace' a word? |
| 08:43:56 | Araq | the opposite of an inplace operation is 'outplace'. right? |
| 08:44:04 | Zevv | if you want it to be |
| 08:44:21 | Zevv | "in place" is two words, actually |
| 08:44:37 | Araq | sorted(x) == outplace(sort(x)) ? |
| 08:44:49 | Araq | any English natives around? |
| 08:45:34 | FromDiscord | <Chiqqum_Ngbata> "outplace" isn't a word or commonly used neologism |
| 08:45:44 | Araq | sorted(x) == sort(x).ed() |
| 08:46:09 | Araq | shuffle(x).ed, nah too silly |
| 08:46:17 | FromDiscord | <Chiqqum_Ngbata> Wikipedia tells me... "An algorithm which is not in-place is sometimes called not-in-place or out-of-place. " |
| 08:47:37 | Araq | copyof(sort(x)) |
| 08:47:50 | FromDiscord | <Chiqqum_Ngbata> copy makes the most sense to me |
| 08:48:14 | * | letto_ joined #nim |
| 08:48:26 | Araq | copied(sort(x)) |
| 08:50:04 | FromDiscord | <Chiqqum_Ngbata> Perfect IMO |
| 08:50:15 | Araq | I like 'outplace' better, at least it's not misleading, you have to read its docs, 'copied(sort(x))' could mean it's copied afterwards |
| 08:52:19 | FromDiscord | <Chiqqum_Ngbata> No chance of defaulting sorting to making a copy & making the in-place sortInPlace or sort(thing, inplace=true) ? |
| 08:52:27 | Araq | hmm or maybe even returnInner(sort(copy x)) |
| 08:53:55 | Araq | Chiqqum_Ngbata: Nim values efficiency too much for that, we mostly use inplace algorithms where they have clear performance benefits |
| 08:54:33 | * | fanta1 joined #nim |
| 08:54:44 | FromDiscord | <Chiqqum_Ngbata> Right, fair enough |
| 08:55:19 | Zevv | and in real life a thing like sorting is often perfectly fine in most of the cases |
| 09:00:28 | * | Hideki_ joined #nim |
| 09:04:02 | * | tamago324 quit (Remote host closed the connection) |
| 09:05:10 | * | Hideki_ quit (Ping timeout: 268 seconds) |
| 09:08:41 | * | vesper joined #nim |
| 09:09:06 | PMunch | Once you've got your types mapped working against C in Nim really "just works" :) |
| 09:09:29 | * | vesper11 quit (Ping timeout: 268 seconds) |
| 09:09:33 | PMunch | Although with a bit more casting and pointers than in normal Nim code |
| 09:10:00 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 09:26:31 | FromDiscord | <kodkuce> dous using C wrapedd libs give you any slowdown vs same lib in Nim? |
| 09:26:58 | FromDiscord | <kodkuce> *same lib 100% same writed in Nim |
| 09:27:36 | PMunch | Well, it depends on how they are implemented |
| 09:27:56 | PMunch | Nim obviously doesn't have the ability to opitimise anything in a C wrapped library |
| 09:28:40 | PMunch | But it will all be optimised by the C compiler off course, so it's only for some pretty edge-cases you would get a speedup I think |
| 09:28:55 | PMunch | But it all depends on what the wrapper is doing |
| 09:29:11 | PMunch | Some wrappers will convert types back and forth, which might be slow if you do it a lot |
| 09:30:57 | * | tklohna_ quit (Ping timeout: 250 seconds) |
| 09:41:43 | FromDiscord | <kodkuce> got it, ty 🙂 |
| 09:44:33 | * | letto_ quit (Quit: Konversation terminated!) |
| 09:46:12 | * | letto joined #nim |
| 09:53:46 | superbia | is there a list of modules that work/don't work with JS |
| 09:54:08 | dom96 | yumaikas, epic, thanks! |
| 09:54:50 | dom96 | oh cool, we're on HN front page |
| 09:59:22 | FromDiscord | <mratsim> @kodkuce, no slowdown, Nim compiles to C with the same C calling convention so there is no extra wrapper overhead |
| 09:59:35 | PMunch | By the way yumaikas, you can use the Freenode MemoServ to send messages to offline users: https://github.com/atheme/atheme/wiki/MemoServ%3ASEND |
| 10:00:27 | * | luis__ quit (Quit: luis__) |
| 10:00:53 | PMunch | dom96, I keep seeing articles on Nim by people I've never heard of, which is a really good sign :) |
| 10:01:24 | dom96 | superbia, don't think so. Just try to import them, if they don't work you'll know ;) |
| 10:01:39 | dom96 | PMunch, yep :) |
| 10:02:48 | PMunch | superbia, most pure Nim modules should work |
| 10:03:23 | superbia | I mean, is there a reason why a nice list of working modules or not working modules doesn't exist? |
| 10:04:18 | PMunch | Probably no-one has been arsed to write one :P |
| 10:04:42 | PMunch | But no, there is no reason why it couldn't exist |
| 10:10:15 | Araq | superbia: the stdlib mentions *if* a module works with JS |
| 10:10:37 | Araq | usually it's safe to assume that it doesn't work |
| 10:11:57 | FromDiscord | <mratsim> I thought it was the other way around |
| 10:24:44 | * | abm joined #nim |
| 10:31:30 | Zevv | what is apart from expections and refs/pointers the biggest difference between C and CPP codegen? |
| 10:33:49 | Araq | C++ codegen enables 'importcpp' |
| 10:35:34 | Zevv | hmm that does not seem relevant for what I'm looking at here. It must be something with the refs vs pointers, but can't get my fingers behind it yet. |
| 10:42:09 | * | pigmej quit (Remote host closed the connection) |
| 10:42:11 | * | Balu[m]1 quit (Remote host closed the connection) |
| 10:42:14 | * | Manny8888 quit (Remote host closed the connection) |
| 10:42:19 | * | Connor[m] quit (Remote host closed the connection) |
| 10:42:19 | * | MrAxilus quit (Read error: Connection reset by peer) |
| 10:42:19 | * | d-nice2[m] quit (Remote host closed the connection) |
| 10:42:20 | * | nergal[m] quit (Read error: Connection reset by peer) |
| 10:42:20 | * | planetis[m] quit (Read error: Connection reset by peer) |
| 10:42:22 | * | LEdoian[m] quit (Read error: Connection reset by peer) |
| 10:42:24 | * | spymasterd[m] quit (Read error: Connection reset by peer) |
| 10:42:25 | * | meff[m] quit (Write error: Connection reset by peer) |
| 10:42:26 | * | BitPuffin quit (Remote host closed the connection) |
| 10:42:27 | * | Miguelngel[m] quit (Remote host closed the connection) |
| 10:42:27 | * | skrylar[m] quit (Remote host closed the connection) |
| 10:42:27 | * | salotz[m] quit (Remote host closed the connection) |
| 10:42:29 | * | GitterIntegratio quit (Read error: Connection reset by peer) |
| 10:42:30 | * | zielmicha[m]1 quit (Remote host closed the connection) |
| 10:42:31 | * | lasso[m] quit (Remote host closed the connection) |
| 10:42:32 | * | testgovno[m] quit (Remote host closed the connection) |
| 10:42:32 | * | Demos[m] quit (Remote host closed the connection) |
| 10:42:34 | * | M948e5[m] quit (Read error: Connection reset by peer) |
| 10:42:34 | * | lqdev[m] quit (Read error: Connection reset by peer) |
| 10:42:35 | * | narimiran[m] quit (Remote host closed the connection) |
| 10:42:37 | * | xomachine[m] quit (Read error: Connection reset by peer) |
| 10:42:38 | * | muxueqz[m] quit (Remote host closed the connection) |
| 10:42:38 | * | yglukhov[m] quit (Read error: Connection reset by peer) |
| 10:42:39 | * | isaac[m]1 quit (Remote host closed the connection) |
| 10:42:40 | * | Asbrn[m] quit (Remote host closed the connection) |
| 10:42:41 | * | k0mpjut0r quit (Write error: Connection reset by peer) |
| 10:42:41 | * | nc-x[m] quit (Remote host closed the connection) |
| 10:42:41 | * | TheManiac[m] quit (Remote host closed the connection) |
| 10:42:42 | * | macsek1911[m] quit (Remote host closed the connection) |
| 10:42:42 | * | leorize[m] quit (Remote host closed the connection) |
| 10:42:42 | * | swisscowbell[m] quit (Remote host closed the connection) |
| 10:50:43 | FromDiscord | <treeform> C++ backend uses c++ exceptions, while c does a different thing. |
| 10:51:20 | Zevv | yeah, but there are no exceptions happening, and I just threw out all raises as well. |
| 10:51:55 | Zevv | At the ASM level things are also not that different, but still I get 1.7 instructions per cycle on C and only 1.0 on C++ |
| 10:52:09 | Zevv | pipeline stalls |
| 10:53:41 | * | kevin_ quit (Quit: leaving) |
| 11:00:08 | * | clyybber joined #nim |
| 11:05:01 | * | testgovno[m] joined #nim |
| 11:20:50 | * | Vladar quit (Ping timeout: 240 seconds) |
| 11:21:17 | * | Vladar joined #nim |
| 11:27:38 | * | LargeEpsilon quit (Ping timeout: 252 seconds) |
| 11:28:55 | * | Connor[m] joined #nim |
| 11:28:55 | * | swisscowbell[m] joined #nim |
| 11:28:55 | * | k0mpjut0r joined #nim |
| 11:28:55 | * | planetis[m] joined #nim |
| 11:28:55 | * | leorize[m] joined #nim |
| 11:28:56 | * | d-nice2[m] joined #nim |
| 11:28:56 | * | GitterIntegratio joined #nim |
| 11:28:56 | * | M948e5[m] joined #nim |
| 11:28:56 | * | MrAxilus joined #nim |
| 11:28:56 | * | BitPuffin joined #nim |
| 11:28:56 | * | isaac[m] joined #nim |
| 11:28:56 | * | nergal[m] joined #nim |
| 11:28:57 | * | Manny8888 joined #nim |
| 11:28:57 | * | Demos[m] joined #nim |
| 11:28:57 | * | lqdev[m] joined #nim |
| 11:28:57 | * | pigmej joined #nim |
| 11:28:57 | * | LEdoian[m] joined #nim |
| 11:29:02 | * | salotz[m] joined #nim |
| 11:29:02 | * | skrylar[m] joined #nim |
| 11:29:03 | * | spymasterd[m] joined #nim |
| 11:29:03 | * | muxueqz[m] joined #nim |
| 11:29:03 | * | lasso[m] joined #nim |
| 11:29:03 | * | Miguelngel[m] joined #nim |
| 11:29:03 | * | narimiran[m] joined #nim |
| 11:29:03 | * | Asbrn[m] joined #nim |
| 11:29:03 | * | nc-x[m] joined #nim |
| 11:29:03 | * | xomachine[m] joined #nim |
| 11:29:04 | * | meff[m] joined #nim |
| 11:29:04 | * | TheManiac[m] joined #nim |
| 11:29:04 | * | yglukhov[m] joined #nim |
| 11:29:04 | * | Balu[m] joined #nim |
| 11:29:04 | * | macsek1911[m] joined #nim |
| 11:29:05 | * | zielmicha[m]1 joined #nim |
| 11:41:30 | FromGitter | <zacharycarter> I think I have working sokol_gfx bindings now, so yay! |
| 11:47:57 | * | solitudesf quit (Ping timeout: 246 seconds) |
| 11:49:26 | * | rockcavera joined #nim |
| 11:52:07 | * | solitudesf joined #nim |
| 11:53:18 | FromGitter | <zacharycarter> excited to start writing some networking code this evening |
| 12:07:39 | * | LargeEpsilon joined #nim |
| 12:09:42 | shashlick | @zacharycarter I think getHeader should work for your use case too, will expand it |
| 12:09:49 | shashlick | Any other hiccups |
| 12:10:05 | FromDiscord | <mratsim> does the new nimble now eats hint and warning on nimble test @dom96? |
| 12:28:08 | * | lritter joined #nim |
| 12:28:58 | * | clyybber quit (Quit: WeeChat 2.6) |
| 12:29:07 | * | clyybber joined #nim |
| 12:31:56 | clyybber | Araq: Seems like the `Obj(v: 1)` to `var tmp = Obj(); tmp.v = 1; tmp` conversion is causing many problems. |
| 12:32:20 | clyybber | It also doesn't seem that well of an idea in hindsight, maybe this should be better done in the backend as it is now. |
| 12:32:51 | Araq | which problems? |
| 12:33:16 | clyybber | The test failure, one moment |
| 12:33:18 | FromGitter | <alehander42> clyybber everything that one does in the backend needs to be done in each backend, isnt it |
| 12:33:44 | FromGitter | <alehander42> is there something like a pre-backend pass which does stuff like that independent on the actual target |
| 12:34:02 | * | theelous3 quit (Ping timeout: 276 seconds) |
| 12:34:32 | clyybber | alehander42: Yes there is, and thats exactly where I'm doing it currently. |
| 12:35:03 | clyybber | Araq: Here: https://dev.azure.com/nim-lang/Nim/_build/results?buildId=430 |
| 12:35:49 | clyybber | I'm not sure the cause of it though. But introducing a temporary for every object constructor seems a bit overkill (doing it before the code backend and injectdestructors that is) |
| 12:36:44 | clyybber | Araq: And I could do the transformation from `Obj(v: 1)` to `Obj(v: 1, somefieldwithadefaultvalue: 2)` in theory. |
| 12:36:59 | clyybber | Its just that I need to rely on the object-variant-discriminator to be constant. |
| 12:37:16 | clyybber | Which it is required to be currently by the spec |
| 12:37:54 | clyybber | So I wanted your opinion on wether theres plans to remove that const restriction or if its here to stay (meaning I can rely on it) |
| 12:39:12 | Araq | you can rely on it in the sense that the value will always be required to be precise enough so that we can detect the object case branch at compiletime |
| 12:39:24 | clyybber | Yeah, thats enough |
| 12:39:39 | Araq | it can be a variable of a 'range' type if that's precise enough |
| 12:40:05 | clyybber | Yeah, just need to know which case its gonna end up in. So I can insert the appropriate default values. |
| 12:40:18 | clyybber | *case branch |
| 12:41:38 | Araq | from `Obj(v: 1)` to `Obj(v: 1, somefieldwithadefaultvalue: 2)` is even better in theory because it doesn't lose information |
| 12:41:58 | Araq | we still know it's a complete object construction |
| 12:42:02 | Araq | I like it. |
| 12:42:15 | * | dddddd joined #nim |
| 12:42:20 | clyybber | Yeah, and thats better for the js backend |
| 12:42:29 | clyybber | Because js has constructors right? |
| 12:42:51 | Araq | it helps every backend not to lose information |
| 12:43:14 | Araq | the backend can always lower on its own, but extracting the highlevel information that existed is harder |
| 12:44:48 | clyybber | Yeah |
| 12:45:01 | * | Vladar quit (Quit: Leaving) |
| 12:45:16 | * | Kaivo joined #nim |
| 12:45:56 | * | Hideki_ joined #nim |
| 12:47:03 | clyybber | woow, I found something rare in the compiler code |
| 12:47:17 | clyybber | command syntax like this `someproc arg1, arg2, arg3` |
| 12:51:01 | clyybber | Araq: Should I allow this: |
| 12:51:12 | clyybber | type o = object |
| 12:51:17 | clyybber | case b: bool = true |
| 12:51:30 | clyybber | of false: f: int |
| 12:51:36 | clyybber | of true: t: int |
| 12:51:54 | clyybber | discard o(t: 1) |
| 12:51:58 | clyybber | ? |
| 12:54:56 | FromGitter | <zacharycarter> shashlick: I think the enum thing is the only thing that's really blocking me atm, I ended up using nimgen to generate the bindings instead of nimterop |
| 12:55:06 | FromGitter | <zacharycarter> and then I manually tweaked the output from nimgen |
| 12:55:10 | Araq | yeah, it's required for a better Option[T] type |
| 12:55:14 | FromGitter | <zacharycarter> since I was in a rush |
| 12:57:07 | clyybber | Araq: Ok. I have to do some of the transformation in sem then. |
| 12:57:46 | Araq | beware about the effects for the macro system then |
| 12:58:14 | clyybber | Araq: Yeah, I don't want to affect that. Maybe I'll store it somewhere secret for use in transf |
| 12:58:41 | clyybber | Or I just transform twice. One time only for checks. |
| 12:58:45 | Araq | https://www.deviantart.com/a-discworld-guild/art/Death-Builds-a-Swing-Set-37768200 this is how to not design software systems. |
| 12:59:15 | Araq | clyybber: unfortunately this hidden AST state is worse |
| 12:59:29 | Araq | see nfDefault node flags |
| 13:00:00 | Araq | nfDefaultParam, nfDefaultRefsParam, nfExecuteOnReload ... |
| 13:00:15 | Araq | bad design. |
| 13:00:36 | shashlick | @zacharycarter why nimgen? Anything specific |
| 13:00:38 | clyybber | Lol that pic. |
| 13:00:56 | clyybber | Araq: So what should I do? Just take the bad design and go with it? |
| 13:01:03 | clyybber | Whats bad about it anyways? |
| 13:01:35 | Araq | Nim's macro system works better with less magic so do the transformation in sem and document the breaking change |
| 13:01:51 | Araq | (but then previously we had no default values so it doesn't break anything, does it...) |
| 13:02:25 | shashlick | I'm planning on porting some nimgen stuff into nimterop |
| 13:02:25 | clyybber | Araq: Should I also do the reset and default(T) transformations in sem? |
| 13:03:19 | Araq | so .. --gc:destructors. it's a thing now |
| 13:03:36 | Araq | simple tests work |
| 13:03:58 | FromGitter | <zacharycarter> shashlick: I had to do a lot of search and replace work and I was just more familiar with nimgen's API. I'll give nimterop a shot again soon |
| 13:04:02 | Araq | looking for sensible milestones |
| 13:04:16 | clyybber | Araq: And --gc:hooks is an extension of --gc:destructors, is that right? |
| 13:04:35 | Araq | yeah but don't use it :P |
| 13:04:41 | Araq | the hooks are incomplete |
| 13:04:51 | clyybber | ok |
| 13:05:31 | Araq | time to write a threading API that doesn't suck I guess |
| 13:05:41 | clyybber | Araq: I think it may be a good idea to do the object constructor to object contructor transformation in sem and result, default(T), and reset in transf.nim, wdyt? |
| 13:05:43 | FromDiscord | <mratsim> just how many --gc: are there now? |
| 13:05:58 | clyybber | Araq: yes please |
| 13:06:15 | clyybber | mratsim: Not enough :D |
| 13:06:57 | Araq | mratsim: there is only --gc:destructors, everything else is moribund. Until we switch to something else, next Monday. |
| 13:07:46 | Araq | clyybber: hmmm, I still like 'result' in the backend |
| 13:08:10 | Araq | don't care about default(T) and reset |
| 13:08:18 | clyybber | Araq: I don't want to make it go away, just insert a `result = Obj(defaultthings)` at the start of a proc. |
| 13:08:40 | clyybber | Oh |
| 13:09:00 | Araq | don't insert this, use the DFA to see where it's required |
| 13:09:02 | clyybber | It just occured to me that I have to insert an object constructor for every variable thats not initalized. |
| 13:09:09 | shashlick | @zacharycarter cool I'll port those into nimterop |
| 13:09:13 | Araq | yup |
| 13:09:18 | clyybber | Araq: Ok. Won't the backend optimize it away anyways? |
| 13:09:24 | clyybber | If its not used I mean. |
| 13:10:26 | Araq | the C backend does that but still |
| 13:10:52 | clyybber | ok |
| 13:12:05 | FromDiscord | <mratsim> so what about the threading API, will it differ from Threadpool API? |
| 13:15:54 | Araq | mratsim: we should join forces on your picasso thing |
| 13:17:12 | shashlick | Nimble nawabs nimby nimph |
| 13:17:16 | clyybber | Yeah |
| 13:17:23 | clyybber | I wanted to say, those should join too. |
| 13:17:25 | shashlick | Wish we could bring all this together |
| 13:17:40 | Araq | nawabs died with 'nimble develop' |
| 13:17:48 | clyybber | shashlick: Thougg, I meant nawabs, nimby and nimph |
| 13:18:10 | clyybber | nimble is a bit different, as its old an has to retain compatibility. |
| 13:18:47 | Araq | just today I discussed Nimble with dom96, want to change $nimbledir |
| 13:18:55 | shashlick | Ya but nimble isn't just some random tool, it's the official package manager |
| 13:19:11 | clyybber | shashlick: Exactly. Thats why experiments should be done elsewhere. |
| 13:19:15 | clyybber | Until its ready. |
| 13:19:29 | shashlick | If that's what they are, sure |
| 13:19:55 | shashlick | But ideas need to come back into nimble eventually |
| 13:20:04 | Araq | anyhow one idea we developed was that the existence of $cwd/deps means Nimble uses that instead of $nimblePath |
| 13:20:20 | clyybber | where $cwd is the project dir? |
| 13:20:22 | clyybber | Yeah pls |
| 13:20:23 | Araq | yes |
| 13:20:40 | Araq | other current working dir or "project dir" |
| 13:20:44 | shashlick | What of Nim's knowledge of nimble |
| 13:20:58 | Araq | most likely project dir |
| 13:21:36 | FromDiscord | <mratsim> I don't mind joining forces |
| 13:22:10 | FromDiscord | <mratsim> the PoC is there, the original author (another Andreas) is also available if needed (and he is german 😉 ) |
| 13:22:21 | Araq | oh no |
| 13:22:34 | Araq | I cannot get along with other Germans |
| 13:22:54 | clyybber | haha, thats why krux is in your team right? |
| 13:23:39 | FromDiscord | <mratsim> well he is focused on releasing a cleanup C version, he is not a Nim dev (yet) |
| 13:24:48 | FromDiscord | <mratsim> basically my proof of concept and tests are living in e04 folder: https://github.com/mratsim/weave/blob/master/e04_channel_based_work_stealing/tests/fib.nim |
| 13:25:18 | FromDiscord | <mratsim> and now we need a proper generic, nim-ified code which I should get back to: https://github.com/mratsim/weave/tree/master/picasso |
| 13:29:44 | Araq | now we need proper =hooks :-) |
| 13:32:07 | Araq | shashlick: there is an RFC covering that, does it have any known flaws? |
| 13:32:41 | shashlick | I've not thought much about it |
| 13:33:38 | Araq | what's your opinion on $cwd/deps? |
| 13:36:59 | shashlick | i like it but `rm -rf deps` won't do what you expect |
| 13:39:35 | Araq | 'rm -rf' never does what I expect |
| 13:41:11 | shashlick | so basically this is for https://github.com/nim-lang/nimble/issues/131 |
| 13:43:32 | Araq | yeah |
| 13:47:08 | shashlick | seems like an easy fix - if dir exists, set nimbleDir |
| 13:49:01 | Araq | exactly |
| 13:49:17 | * | Hideki_ quit (Ping timeout: 240 seconds) |
| 13:49:22 | Araq | and Nim needs to understand this too or else we remove --nimbleDir |
| 13:49:40 | * | Vladar joined #nim |
| 13:50:50 | shashlick | my concern with RFCs in general is that they don't refine into clear requirements and design |
| 13:51:19 | shashlick | there's several nimble changes that are interrelated and needs a bigger design discussion to nail down the exact functionality |
| 13:51:29 | shashlick | and we don't seem to get there with github issues |
| 13:52:31 | shashlick | so $cwd/deps depends on https://github.com/nim-lang/nimble/issues/654 |
| 13:54:43 | Araq | well the RFCs are better than nothing |
| 13:55:38 | * | superbia quit (Ping timeout: 240 seconds) |
| 13:56:42 | Araq | #654 is wrong because Nimble should create/touch the .nim.cfg file so that nimsuggest and other tools understand the setup |
| 13:57:27 | Araq | 'nimble getPaths' cannot work nor do I want nim to call into Nimble, wrong direction |
| 13:57:46 | Araq | esp since nimble already calls nim |
| 13:58:59 | Araq | oh it's mentioned in the discussion |
| 14:01:53 | Araq | and apparently the discussion died because I didn't reply |
| 14:03:41 | disruptek | why would you remove nimbleDir now? |
| 14:05:32 | Araq | because it means we have to sync the two implementations |
| 14:06:06 | Araq | and ideally we like to see Nimble change it, I personally think $nimbledir is terrible |
| 14:06:35 | disruptek | oh, for some reason i read that as nimblePath. you wouldn't change the compiler, right? |
| 14:07:00 | Araq | I'm vague, nimbledir is the same as nimblePath for me |
| 14:07:51 | disruptek | okay, well, yeah, it's pretty vague. prefer we not remove anything until we have a concrete plan on how it could work. |
| 14:08:23 | disruptek | without nimblePath, i have to rethink how i do all package management. |
| 14:08:33 | disruptek | and it kills nimph to boot. |
| 14:08:48 | Araq | wait what? why would it? |
| 14:09:07 | * | EvilKhaosKat joined #nim |
| 14:09:24 | Araq | anyhow, I wrote enough RFCs on Nimble's issue tracker |
| 14:09:37 | disruptek | the point of nimph is to create a virtual env style "this is your world now" and then be able to freeze it like an upside-down icicle. |
| 14:10:23 | Araq | I feel like we should create a "Nimble-experiments" branch, hack something together and iterate |
| 14:11:17 | Araq | there is no need to change the Nim compiler for experiments, you can pass --noNimblePath to it |
| 14:11:28 | disruptek | i /want/ nimblePath. |
| 14:11:29 | Araq | in fact, that's what Nimble already does |
| 14:11:41 | disruptek | everything falls apart if it goes away. |
| 14:11:58 | disruptek | i mean, the whole idea of nimph is that it stands on nimble's shoulders. |
| 14:12:03 | shashlick | nimblePath will be retained, this $cwd is just another way of setting it |
| 14:12:09 | shashlick | configuration by convention |
| 14:12:11 | * | GordonBGood quit (Ping timeout: 276 seconds) |
| 14:12:15 | disruptek | sure, i could write something to replace it, but i'm trying to integrate here. |
| 14:12:42 | Araq | I want project specific dependencies |
| 14:12:47 | shashlick | @disruptek, i'm yet to read your readme but i'd rather see your work improve nimble |
| 14:12:56 | disruptek | well, maybe we're talking about the same thing, then. |
| 14:13:10 | disruptek | nimph puts all your project's dependencies in the project's directory. |
| 14:13:20 | disruptek | then it nimblePath on the compiler so you can find them. |
| 14:13:25 | Araq | that's fine with me, that's what I'm aiming for too |
| 14:14:06 | shashlick | @Araq - for the near term, we can add $cwd support to nimble and nim and deal with #654 separately |
| 14:14:27 | disruptek | is there a different compiler option for "where to find !stdlib modules"? |
| 14:14:44 | disruptek | other than --path, i mean? |
| 14:14:55 | shashlick | if $cwd/deps exists or new flag in .nimble file says local deps, use that method |
| 14:14:55 | Araq | what's wrong with --path? |
| 14:15:14 | disruptek | the problem with --path is /only/ that most people don't use it. |
| 14:15:20 | Araq | here is what I often do: create a nim.cfg file |
| 14:15:23 | Araq | it contains |
| 14:15:30 | Araq | --noNimblePath |
| 14:15:30 | disruptek | i'm trying to build something that works with everyone else's flow. |
| 14:15:39 | Araq | --path:x --path:y etc |
| 14:15:50 | disruptek | yes, that's how i started with nim because i was frustrated with nimble. |
| 14:15:56 | Araq | and then I have complete control and can ignore Nimble ;-) |
| 14:16:10 | disruptek | but i decided that was too anti-social of me and it didn't make sense if i wanted to share code. |
| 14:16:11 | shashlick | @Araq - why does the global package dir not work for you? |
| 14:16:16 | shashlick | how has it broken for you in the past |
| 14:16:39 | Araq | it accumulates cruft by design |
| 14:16:42 | disruptek | you can't control it and it's a mess. i don't want to have to build with nimble. |
| 14:17:16 | disruptek | i can't control individual project dependencies as soon as they /lexically/ clash, eg. npeg-#head. |
| 14:17:26 | disruptek | ridiculous. |
| 14:17:39 | Araq | for example, I had broken builds because nim picks up chronos-2.2.8 instead of chronos-1.2.2 |
| 14:17:56 | disruptek | yes, and the supposed solution to that is to build with nimble. |
| 14:18:10 | disruptek | i don't want to have to use a tool because that tool broke my compiler environment. |
| 14:18:25 | Araq | but that doesn't work, nimble uses my nim.exe but i'm developing the compiler so it should use my nim_temp.exe |
| 14:18:41 | Araq | and yeah, there is always a workaround |
| 14:18:57 | Araq | but the workarounds suck moreso than avoiding Nimble. |
| 14:20:04 | Araq | plus I still fundamentally disagree with having multiple package-$version dirs, it's pretending we live in times where version control has yet to be invented. |
| 14:20:35 | Araq | but I have written down all these things in Nimble's issue tracker already. |
| 14:21:11 | shashlick | I'm sure package local deps is useful |
| 14:21:26 | shashlick | Just wanted to know how global has bitten you specifically |
| 14:21:38 | disruptek | i just enumerated some examples. |
| 14:21:38 | Araq | well do you know now? |
| 14:22:01 | shashlick | @disruptek Nim is aware of nimble, you don't need to build only with nimble |
| 14:22:06 | shashlick | I've never used nimble c |
| 14:22:12 | disruptek | no, that's incorrect. |
| 14:22:14 | Araq | :O |
| 14:23:22 | shashlick | Why do you think https://github.com/nim-lang/nimble/issues/654 exists |
| 14:23:42 | disruptek | do i need to read it? |
| 14:23:59 | shashlick | More eyes |
| 14:24:09 | Araq | disruptek, I think you know about it already |
| 14:24:10 | disruptek | it causes the compiler to use the latest versions, which are not necessarily the versions i want it to use. |
| 14:24:19 | Araq | ^ exactly. |
| 14:24:26 | shashlick | Anyway, I'm all for improving nimble, I'm happy to contribute too |
| 14:24:38 | Araq | I know :-) |
| 14:24:44 | shashlick | But there needs to be a clear path forward that folks can agree upon |
| 14:24:57 | Araq | which is why I'm spending my time on this here |
| 14:25:24 | disruptek | i want to be able to hack on a library in order to fix its interop with my code, and then push those changes to that library. i don't want that hackery to break every other package i have that uses that library while it's in this state of flux. |
| 14:26:02 | shashlick | My biggest hurdle is getting @dom96's attention, though that's gotten a bit better |
| 14:26:07 | shashlick | Time difference doesn't help |
| 14:26:10 | disruptek | ie. i'm working on lib1 inside app1 and i don't want app2 which depends upon lib1 to break. |
| 14:26:14 | Araq | agreed. the fact that Nimble throws away the .git dir hinders collaboration IMO. |
| 14:27:35 | Araq | (it also throws away examples and documentation... yada yada yada) |
| 14:27:45 | disruptek | you end up having to `nimble develop` everything, and also constantly prune shit outta .nimble/pkgs and then maybe you don't want your develop copy so you wanna delete it and ... it's insane. |
| 14:28:51 | Araq | plus as treeform found out, 'nimble develop' doesn't work when you have 2 instances of the package you work on because you have project specific deps. |
| 14:29:15 | disruptek | well of course not. but that's solved with nimph and his tool. wasn't a big deal. |
| 14:32:27 | disruptek | one thing that's nice about what we have now is that i can do `cd oldapp; nim c --nimblePath=../newapp/.nimble oldapp.nim; nimble test` to confirm that an old app builds against a new app's packages. i don't want to lose that, either. |
| 14:33:14 | federico3 | https://lobste.rs/s/9o7mpj/nim_scripting_ease_compiled_language |
| 14:33:22 | Araq | so for me the global $nimbledir is the single cause of the trouble, it lead to --nimblePath, --noNimblePath, 'nimble develop'. |
| 14:34:23 | shashlick | One thing about package local deps is how it will impact CI caching |
| 14:35:01 | shashlick | Also, for deps folder to exist it will need to be checked into source control |
| 14:35:24 | shashlick | Or we introduce a new nimble flag in the file |
| 14:35:31 | Araq | you can check in deps/empty.txt |
| 14:35:40 | Araq | I've used this workaround in the past |
| 14:37:25 | FromGitter | <nixfreakz_twitter> where does the exe get stored again when cross compiling ? |
| 14:37:38 | shashlick | It also brings up the question of whether this is a user or project preference |
| 14:38:20 | shashlick | Then if you install a package globally that had local deps how does that work |
| 14:38:38 | Araq | deps are not local or global |
| 14:38:53 | Araq | deps are deps but in the end they are stored somewhere |
| 14:39:03 | disruptek | someone write that down. |
| 14:39:19 | Araq | currently that's $nimbledir, we like a project specific location. |
| 14:39:57 | FromGitter | <alehander42> Araq but the problem with package-$version is |
| 14:40:02 | FromGitter | <alehander42> that you might use lib A and lib B |
| 14:40:05 | Araq | disruptek, but I did, it's in the issue tracker... :-/ |
| 14:40:08 | FromGitter | <alehander42> which depend on different versions of C |
| 14:40:13 | FromGitter | <alehander42> i am not sure how version control |
| 14:40:14 | FromGitter | <alehander42> helprs |
| 14:40:22 | disruptek | it was just comically quotable. 😁 |
| 14:40:22 | FromGitter | <alehander42> or maybe i am misunderstanding |
| 14:40:24 | clyybber | We should just use git submodules. |
| 14:40:28 | clyybber | Thats what I do. |
| 14:40:35 | clyybber | Everyone handles their deps themselves. |
| 14:40:41 | clyybber | Boom every problem solved. |
| 14:40:51 | FromGitter | <alehander42> and we should use assembler |
| 14:40:58 | FromGitter | <alehander42> everybody handles his own compilation |
| 14:41:24 | clyybber | Not a fair comparision |
| 14:41:31 | FromGitter | <alehander42> well it is |
| 14:41:36 | clyybber | Nope |
| 14:41:38 | Araq | alehander42: yes I know. it doesn't come as often as people bring it up and in the meantime while Nimble solves this very problem I don't want to use it. |
| 14:41:50 | FromGitter | <alehander42> "let everyone do it yourself" is not always the best we can do |
| 14:41:56 | disruptek | a better retort is to suggest that you git submodule the stdlib used in your app, too. |
| 14:42:00 | shashlick | My point is that nimble install in a project dir should install in its deps dir if it exists |
| 14:42:02 | FromGitter | <alehander42> but otherwise i see the simpleness point :P |
| 14:42:33 | disruptek | shashlick: that's how it works now. |
| 14:42:33 | FromGitter | <alehander42> Araq it doesnt because we have few packages probably |
| 14:42:37 | shashlick | But that deps dir should have no effect when that project is now a dependency itself |
| 14:42:41 | clyybber | alehander42: Of course a fancy nim specific wrapper around git submodules would be cool |
| 14:43:00 | FromGitter | <alehander42> in the future i imagine it coming more, as the probability of a well known nimble package to be used by many other deps |
| 14:43:03 | FromGitter | <alehander42> comes bigger |
| 14:43:06 | clyybber | alehander42: But the fact is that simple fs hierarchy + submodules solve all package problems. |
| 14:43:18 | FromGitter | <alehander42> well, this is just simplistic |
| 14:43:21 | FromGitter | <alehander42> at the very least |
| 14:43:27 | FromGitter | <alehander42> i might want to use a different vcs |
| 14:43:27 | clyybber | It just works |
| 14:43:28 | FromGitter | <alehander42> than git |
| 14:43:39 | clyybber | Fair enough mercurial has submodules too. |
| 14:43:49 | FromGitter | <alehander42> i might not want to use a vcs |
| 14:43:52 | clyybber | Well |
| 14:44:02 | clyybber | then I don't care about you :p |
| 14:44:11 | FromGitter | <alehander42> but the fact is |
| 14:44:22 | clyybber | Use a vcs or bust. |
| 14:44:29 | disruptek | the reason not to use submodules is that i don't need to maintain my own version control history to get value from /your/ version control history. |
| 14:44:34 | FromGitter | <alehander42> yea |
| 14:44:39 | FromGitter | <alehander42> i just feel its incorrect |
| 14:44:46 | FromGitter | <alehander42> but i think disruptek knows why |
| 14:44:56 | Araq | you can keep the package-$version scheme and yet put it into a local directory |
| 14:44:56 | clyybber | disruptek: Small wrapper to update your submodules. |
| 14:45:11 | Araq | it's orthogonal. |
| 14:45:12 | clyybber | I'm not arguing we should use submodules as is. |
| 14:45:13 | FromGitter | <alehander42> Araq but what is the problem with supporting package/version |
| 14:45:22 | clyybber | I'm arguing we should build a pkg manager that is just a small wrapper for submodules. |
| 14:45:27 | FromGitter | <alehander42> its a technical problem, i want my tools to solve it |
| 14:45:36 | FromGitter | <alehander42> and let me just use it |
| 14:45:49 | clyybber | And thats what I'm planning to build. |
| 14:45:54 | disruptek | clyybber: i would say that when nimph is built, it would make sense to be able to turn an existing dep into a submodule with a single command. |
| 14:46:04 | FromGitter | <alehander42> clyybber your idea is cool, but i think it applies to "just build a lang-independent package manager which works like that" |
| 14:46:14 | Araq | alehander42: it isn't a problem, it's a personal preference of mine not to do it this way |
| 14:46:15 | FromGitter | <alehander42> because if you do that, i see no reason to limit it to a language |
| 14:46:20 | clyybber | alehander42: Sure. |
| 14:46:27 | * | nixfreak28 joined #nim |
| 14:46:57 | clyybber | alehander42: Well, not quite. I would want that wrapper to generate a .cfg similar to nimby to include the submodules paths. |
| 14:47:04 | Araq | because then if I do "update dependency X" X's directory name doesn't change. |
| 14:48:02 | disruptek | yes, but a `mv` is atomic pretty low on i/o. |
| 14:48:36 | Araq | come on, I might navigate to the directory, my brain is happier with stable names |
| 14:48:37 | FromGitter | <mratsim> why isn’t nimbledir with package + version hash / commit hash enough? |
| 14:48:44 | Araq | it's not about the machine, it's about myself. |
| 14:48:48 | disruptek | i mean, i agree in principle. in practice, nimph won't care what it's named. it will rename it. |
| 14:48:58 | FromGitter | <mratsim> that also saves on disk space |
| 14:49:18 | disruptek | it /is/ enough. |
| 14:49:35 | Araq | I don't care about disk space. if it becomes scare, I delete some porn. |
| 14:50:15 | Araq | *scarce |
| 14:53:34 | * | floppydh quit (Quit: WeeChat 2.6) |
| 14:53:43 | disruptek | i wanna gonna use github stars instead of package age to determine seniority, but i was worried about Araq's porn collection. |
| 14:53:53 | disruptek | ^ was gonna, that is. |
| 14:53:56 | Araq | but let me make this clear: if nimble detects $cwd/deps and uses it automatically it would be a huge improvement, I think |
| 14:54:12 | Araq | you can keep the project-$version stuff as it is |
| 14:54:36 | federico3 | disruptek: github stars are really meaningless |
| 14:54:39 | disruptek | actually it should detect $cwd/**/.nimble |
| 14:54:52 | * | evilkhaoskat_ joined #nim |
| 14:54:54 | Araq | and I'm willing to patch the compiler to do the same |
| 14:55:01 | disruptek | where ** may include any .. |
| 14:55:22 | Araq | until we sort out/change the nim/nimble integration |
| 14:55:29 | disruptek | if you do that, i'm not sure nimph needs to do any package management at all. |
| 14:55:31 | FromGitter | <mratsim> When I run out of space next, I guess I’m gonna have to delete my 25k+ pics of whale flukes (https://github.com/mratsim/humpback-whale-identification) |
| 14:56:00 | disruptek | kinky bastard. |
| 14:56:59 | federico3 | space on might be cheap but very often disk usage is a proxy for complexity and bloat |
| 14:57:17 | * | EvilKhaosKat quit (Ping timeout: 240 seconds) |
| 14:57:53 | disruptek | what's good about stars is that they already exist and people are using them to vote. |
| 14:58:05 | Araq | use a deduplicating file system. yes, yes, I know. that too has "issues". still an order of magnitude better than faking this feature via symlinks. |
| 14:59:32 | Araq | or via "sharing" stuff in some crazy global fashion (/usr/bin anyone?) |
| 15:01:57 | FromGitter | <alehander42> hm, what should i do next for notnil |
| 15:04:53 | * | PMunch quit (Quit: Leaving) |
| 15:06:15 | Araq | alehander42: what's the status? |
| 15:08:38 | FromGitter | <alehander42> well i didnt have much time last several weeks |
| 15:09:22 | FromGitter | <alehander42> so its basically on "it seems the early ast-based pr + some new fixes/changes seems to work fine for most of the spec" |
| 15:11:02 | FromGitter | <alehander42> i guess mostly it needs some more tests and mostly the initialization thing: https://github.com/alehander42/RFCs/blob/master/RFCs/nilcheck.rst#initialization-of-non-nilable-pointers |
| 15:12:53 | * | solitudesf quit (Remote host closed the connection) |
| 15:18:20 | Araq | ok, will think about it |
| 15:21:29 | shashlick | @Araq I'll take care of it, presuming @dom96 is in sync |
| 15:23:05 | shashlick | Do you agree with a nimble field as well so that folks don't need to check in an empty directory |
| 15:23:42 | shashlick | But then Nim won't know about it cause it doesn't parse nimble files |
| 15:24:51 | shashlick | Although only nimble installs dependencies so the deps folder will exist already once Nim commands are run |
| 15:25:18 | * | superbia joined #nim |
| 15:27:51 | Araq | dom96 is ok with it |
| 15:28:17 | Araq | nimble field is ok too for me but as you noticed nim wouldn't understand it |
| 15:28:52 | Araq | we can use a longer name like 'nimbledeps' and then it can always be enabled IMO |
| 15:29:21 | shashlick | Shouldn't matter like I said cause it only matters when you need to install deps and folder doesn't exist |
| 15:29:37 | shashlick | Can't be always on else it will never allow global deps |
| 15:30:16 | Araq | why does it need to allow "global deps"? |
| 15:30:34 | shashlick | That's how stuff works today |
| 15:30:48 | shashlick | The past is always with us |
| 15:31:15 | Araq | but I opt-in for the new behaviour, I create a 'nimbledeps' dir |
| 15:31:28 | Araq | it means I'm aware of the consequences |
| 15:31:31 | shashlick | Yes that I agree |
| 15:31:54 | shashlick | I'm talking about making a configuration option as well, not just convention |
| 15:32:20 | shashlick | So if the dir doesn't exist, it will get created since project owner wants local deps |
| 15:32:39 | * | evilkhaoskat_ quit (Quit: Leaving) |
| 15:32:44 | * | solitudesf joined #nim |
| 15:32:53 | shashlick | Since nimble is configured with a nimble file, that's the best place to put it |
| 15:33:43 | Araq | hmm ok |
| 15:34:13 | Araq | nim doesn't have to know about this then, nimble creates the nimbledeps or it doesn't |
| 15:34:20 | dom96 | I think you should let Araq implement it at first at least |
| 15:34:37 | Araq | in either case nimbledeps will be picked up by Nim |
| 15:34:42 | Araq | if it exists |
| 15:35:35 | Araq | ??? |
| 15:35:43 | shashlick | Yes that is correct |
| 15:35:57 | shashlick | If dir exists, use it |
| 15:37:03 | Araq | dom96, why? |
| 15:37:46 | disruptek | for one thing, you won't be able to complain that the tail is wagging the dog. 😜 |
| 15:38:24 | dom96 | Araq, you know your use cases well, so it makes sense for you to implement and resolve any problems that come up |
| 15:40:27 | disruptek | will the compiler iterate over all parents to find dep dirs? just stop at the first one? or be blind to anything unspecified? |
| 15:41:12 | Araq | disruptek, it surely won't do what Nimble does in order to confuse everybody |
| 15:41:39 | disruptek | y'know, there are two opposite interpretations of that sentence. |
| 15:41:49 | Araq | kidding aside, I'll copy the logic from Nimble |
| 15:42:03 | Araq | yay code duplication |
| 15:42:59 | clyybber | "just use a deduplicating file system" |
| 15:43:03 | clyybber | jk :p |
| 15:45:55 | shashlick | @Araq @dom96 I can do the nim portion as well, have to learn that part anyway |
| 15:46:50 | Araq | shashlick, I appreciate it very much, thanks |
| 15:47:10 | dom96 | Wait, the Nim portion? |
| 15:58:40 | Araq | dom96, Nim needs to understand $pwd/nimbledeps too because 'nim c' already understands --nimblePath |
| 15:59:05 | * | superbia1 joined #nim |
| 16:01:53 | * | superbia1 quit (Client Quit) |
| 16:02:02 | * | superbia quit (Ping timeout: 240 seconds) |
| 16:03:57 | dom96 | lol |
| 16:04:13 | * | jjido joined #nim |
| 16:04:47 | dom96 | --nimblePath exists to make using Nimble packages without having to create a nimble package easy |
| 16:05:58 | dom96 | Are you planning to put packages into $pwd/deps (and btw I much prefer `deps` than `nimbledeps`) manually without Nimble? |
| 16:06:19 | * | jjido quit (Client Quit) |
| 16:06:33 | dom96 | I'm assuming you're not, in which case you'll already have a Nimble package and will be able to use `nimble` instead of `nim`. |
| 16:06:37 | clyybber | pls make it nimbledeps |
| 16:06:54 | clyybber | THen I know where it came from |
| 16:07:39 | disruptek | .something; i don't need to see it. |
| 16:07:48 | Araq | dom96, that's true but there is no reason 'nim c' suddenly breaks just because we also went with #654 in some half-baken way |
| 16:08:54 | Araq | we can work on #654 afterwards once you made your peace with the idea that Nimble manages a nim.cfg file :P |
| 16:09:05 | Pistos | Hm, impressive quantity here: http://rosettacode.org/wiki/Category:Nim |
| 16:09:12 | clyybber | disruptek: Yeah, it should definitely be .nimbledeps |
| 16:09:51 | Araq | don't you dare and put a dot in front of it! |
| 16:09:58 | dom96 | haha |
| 16:10:02 | Araq | don't hide important things! |
| 16:10:47 | disruptek | if i can't take it for granted, then what's the point? |
| 16:11:50 | dom96 | Araq, implement this in Nimble first. You can probably get away with using `--nimblePath:./deps` in your nim.cfg |
| 16:12:00 | dom96 | to make `nim c` work |
| 16:12:15 | dom96 | But as I've said to you, I want us to see how well this works first |
| 16:12:17 | disruptek | i couldn't make it work last time i tried. |
| 16:12:38 | dom96 | adding yet another Nimble-specific logic to Nim is a bad move |
| 16:13:16 | shashlick | That's just for the near term so that it can be decoupled from 654 |
| 16:13:35 | Araq | dom96, I'm afraid it cannot work this way, but we'll see |
| 16:13:51 | dom96 | shashlick, what do you mean by "decoupled from 654"? |
| 16:14:07 | shashlick | 654 is to remove nimble code from Nim |
| 16:14:17 | shashlick | That doesn't have clear line of sight yet |
| 16:14:25 | disruptek | my issue coulda been due to https://github.com/nim-lang/Nim/issues/12367 i guess. |
| 16:14:36 | shashlick | So for now Nim can continue to know about nimble |
| 16:14:42 | shashlick | We can solve that separately |
| 16:14:44 | dom96 | shashlick, so the solution is to add more Nimble-related stuff to Nim? |
| 16:14:54 | shashlick | I had made some suggestions on that one |
| 16:15:14 | shashlick | I'm fine solving both together but it will slow it down since we don't yet have consensus |
| 16:15:55 | dom96 | All that you need to do is implement a `freeze` command in Nimble and support for this new `deps` directory *in Nimble* |
| 16:16:01 | dom96 | Nim doesn't need to know about it at all |
| 16:16:31 | shashlick | How will Nim know to use this deps dir |
| 16:18:32 | dom96 | That's something to work out later |
| 16:18:45 | dom96 | we can test out this feature without Nim knowing about it |
| 16:22:11 | * | narimiran quit (Ping timeout: 276 seconds) |
| 16:23:41 | nixfreak28 | where does nim store the exe nim c -d:mingw-w64 control1.nim ? |
| 16:23:46 | shashlick | So it will work only with nimble c and not Nim c? |
| 16:24:21 | dom96 | yes |
| 16:31:18 | shashlick | Ok will cross that bridge when we reach it |
| 16:32:22 | shashlick | I'll post a comment with design details and we can proceed on implementation after that |
| 16:32:56 | shashlick | Will track here - https://github.com/nim-lang/nimble/issues/131 |
| 16:41:12 | disruptek | the compiler needs to be modified because it currently finds packages outside nimblePath. |
| 16:41:31 | disruptek | this cannot be solved properly until that is fixed. |
| 16:41:45 | shashlick | @dom96 is suggesting to resolve that as part of 654 |
| 16:41:51 | nixfreak28 | only compiles to Mach-0 not exec " nim c -d:mingw-w64 control1.nim |
| 16:42:15 | shashlick | I'm not fully convinced but let's see if that gets some clarity |
| 16:45:33 | * | tklohna joined #nim |
| 16:48:26 | disruptek | if i'm reading #654 right, it says that the compiler will know so little about where to look for and find packages, that the only way to build something that imports from a package directory will be to pass each and every path you want to import. |
| 16:49:27 | disruptek | ie. package directories as a concept need not even exist. |
| 16:50:45 | * | tklohna quit (Ping timeout: 268 seconds) |
| 16:56:25 | * | tklohna joined #nim |
| 16:57:16 | Araq | and how can we try out the feature if 'nim c' is my muscle memory and doesn't support it? that's crazy talk |
| 16:57:21 | disruptek | in case it wasn't clear, i will restate that nimblePath can only be set via config.nims, and as it is additive, it cannot be used with today's compiler anyway. |
| 16:58:20 | Araq | not to mention that we don't have consensus on #654 either, you cannot simply go ahead and do it. |
| 16:59:13 | disruptek | wow, #131 dates to may of 2015. |
| 17:00:17 | Araq | and how can I test it with nimsuggest integration? I can't, this half-assed thing doesn't work |
| 17:00:30 | Araq | it needs the compiler patch. |
| 17:00:43 | disruptek | i guess i will just do it in nimph. i can solve all these problems and paper over the apparent power struggle. |
| 17:00:47 | FromDiscord | <kodkuce> nim can wrap C++ libs too right? |
| 17:00:58 | disruptek | yep. |
| 17:04:24 | dom96 | okay. I add the compiler patch. But do try to implement this with a simple nim.cfg change if possible |
| 17:04:31 | dom96 | (and if that fails it might be a good idea to fix it) |
| 17:04:42 | dom96 | s/I add/add/ lol |
| 17:05:12 | disruptek | what nim.cfg works? |
| 17:06:28 | disruptek | i mean, what nim.cfg would you like to see in an ideal world, assuming the compiler knew how to read it? |
| 17:08:20 | * | LargeEpsilon quit (Ping timeout: 276 seconds) |
| 17:10:03 | * | Jesin quit (Quit: Leaving) |
| 17:11:38 | disruptek | expect ima hafta write an expect dsl for nim. |
| 17:19:14 | disruptek | anyone remember the old kibbutz tool? not finding it in ddg, but it was just a sentimental thought... |
| 17:21:52 | * | Jesin joined #nim |
| 17:22:03 | * | lritter quit (Ping timeout: 240 seconds) |
| 17:36:00 | shashlick | We will get there |
| 17:36:13 | shashlick | Takes time to build consensus |
| 17:38:27 | * | elrood joined #nim |
| 17:38:42 | * | elrood left #nim (#nim) |
| 17:41:00 | disruptek | but shashlick |
| 17:41:05 | disruptek | THINK OF THE CHILDREN |
| 17:41:12 | disruptek | CHILDREN ARE DYING |
| 17:41:27 | shashlick | We are the world, we are the children |
| 17:45:50 | * | Jesin quit (Quit: Leaving) |
| 17:52:26 | * | Jesin joined #nim |
| 17:52:50 | shashlick | I need a quality come back on that @disruptek |
| 18:00:17 | * | clyybber quit (Quit: WeeChat 2.6) |
| 18:00:56 | * | fanta1 quit (Quit: fanta1) |
| 18:03:35 | * | tklohna quit (Ping timeout: 276 seconds) |
| 18:05:00 | stefantalpalaru | Don't worry, this is a high-quality comeback. Michael Jackson was thinking about children all the time. |
| 18:05:28 | * | NimBot joined #nim |
| 18:10:21 | * | tklohna joined #nim |
| 18:20:49 | disruptek | nimble, n: somehow, the opposite of agile. |
| 18:22:11 | nixfreak28 | If I need to compile a dll file into the nim program in order to run it on windows is that possible ? or does the user on windows need that dll file? |
| 18:22:23 | * | skrylar[m] has somehow managed to barely use nimble all this time |
| 18:22:37 | disruptek | it's not dll if it's not a "dynamically loaded library." |
| 18:23:21 | nixfreak28 | wine64 window.exe could not load: SDL2.dll |
| 18:23:30 | skrylar[m] | unless you use one of those weird file bundlers that you can sometimes get from drm platforms |
| 18:23:55 | nixfreak28 | so I can't bundle the dll file in ? |
| 18:24:21 | skrylar[m] | no but you can statically link SDL2 these days |
| 18:24:56 | nixfreak28 | so I need to know the path on the windows box to do that correct? |
| 18:24:57 | * | LargeEpsilon joined #nim |
| 18:25:20 | skrylar[m] | no? |
| 18:25:29 | skrylar[m] | are you cross compiling or something |
| 18:25:33 | nixfreak28 | yes |
| 18:25:39 | disruptek | shashlick: if you don't think that was quality, you have a hole in your soul. |
| 18:25:40 | nixfreak28 | from osx/linux to windows |
| 18:25:51 | skrylar[m] | well windows doesn't embed the path to a library like linux does |
| 18:29:12 | nixfreak28 | So your saying I won't be able to give the user on windows an exe file unless they install SDL2? |
| 18:37:43 | shashlick | It just needs to be in the path |
| 18:37:59 | shashlick | Or statically link like @lqdev is |
| 18:43:35 | * | Tyresc joined #nim |
| 18:45:09 | nixfreak28 | right but the use has to have SDL2 installed on there machine correct ? |
| 18:45:21 | nixfreak28 | use == user |
| 18:46:10 | shashlick | Or you can ship binary with your exe or statically link into your exe |
| 18:47:52 | * | Jesin quit (Quit: Leaving) |
| 18:48:11 | nixfreak28 | I need to read about statically linked , thanks |
| 18:50:20 | stefantalpalaru | skrylar[m]: Linux binaries don't hardcode library paths by default. You need to fuck them up on purpose to set an "rpath": https://en.wikipedia.org/wiki/Rpath |
| 18:52:11 | * | Jesin joined #nim |
| 19:06:26 | * | Tyresc quit (Ping timeout: 265 seconds) |
| 19:08:28 | * | Kameleon joined #nim |
| 19:13:11 | * | narimiran joined #nim |
| 19:16:59 | * | GordonBGood joined #nim |
| 19:18:43 | FromGitter | <nixfreakz_twitter> So like this nim c -d:mingw --cpu:amd64 --dynlibOverride:sdl2 --passL:/usr/local/opt/sdl2/lib/libSDL2.dylib --threads:on window.nim |
| 19:18:58 | FromGitter | <nixfreakz_twitter> nm invalid file |
| 19:18:59 | FromGitter | <nixfreakz_twitter> hmm |
| 19:31:52 | nixfreak28 | Here we go nim c -d:mingw --cpu:amd64 --passC="/usr/local/opt/sdl2/lib/libSDL2-2.0.0.dylib" --threads:on window.nim |
| 19:33:53 | * | filcuc quit (Ping timeout: 264 seconds) |
| 19:42:12 | * | LargeEpsilon quit (Ping timeout: 246 seconds) |
| 19:57:40 | * | Kameleon quit (Quit: Leaving) |
| 20:03:43 | shashlick | How do you expect an osx dylib shared lib to work on windows |
| 20:09:46 | * | rosma[m] joined #nim |
| 20:20:18 | * | rosma[m] left #nim ("User left") |
| 20:22:01 | krux02 | On Linux you can simply assume SDL2 to be installed, it doesn't need to be shipped. |
| 20:22:25 | krux02 | so many things depend on SDL2 that you can see it as a core thing these days. |
| 20:22:41 | * | LargeEpsilon joined #nim |
| 20:23:05 | skrylar[m] | you probably shouldn't |
| 20:23:21 | skrylar[m] | unless you plan on shipping source, or being part of a core repo, it's a good idea to ship anything that isn't on a default like, debian install as part of an appimage |
| 20:24:56 | skrylar[m] | mostly because even IF what you use is safely there NOW, it might not be tomorrow, and if the app can't be recompiled it becomes a humongous pain in everyone's ass to work around |
| 20:27:23 | * | krux02 quit (Remote host closed the connection) |
| 20:28:06 | * | krux02 joined #nim |
| 20:32:18 | skrylar[m] | can't speak about snapcraft, but flatpak will also deal with this for you |
| 20:39:27 | * | lqdev[m] uploaded an image: image.png (48KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/VcmgVOSdhDgbsgVxFtCeOPSh > |
| 20:39:35 | lqdev[m] | got some progress on my high level Wren wrapper |
| 20:39:49 | skrylar[m] | 👌 |
| 20:39:50 | lqdev[m] | finally starting to wrap my head around macros with `untyped` and `typed` params |
| 20:40:13 | nixfreak28 | I really don't know anything about cross compiling extra libs using nim thats why I'm asking you guys |
| 20:42:03 | rayman22201 | on Windows, you just put the dll you want in the same directory as your exe file. |
| 20:42:25 | rayman22201 | but note, a dylib will not work on Windows. That's the Mac specific format for shared libraries |
| 20:42:28 | skrylar[m] | @lqdev the brain melt happens when you have macros producing macros |
| 20:43:04 | skrylar[m] | <rayman22201 "but note, a dylib will not work "> thats true but also pedantry ^_^ |
| 20:43:40 | * | nsf quit (Quit: WeeChat 2.6) |
| 20:43:43 | skrylar[m] | oh wait |
| 20:43:45 | rayman22201 | how is that pedantry? if you look at his previous comment, he was trying to compile a windows binary using a dylib file |
| 20:43:56 | skrylar[m] | yeah ey'd need to link to the dll in the cross compiler, i see what you meant |
| 20:44:03 | rayman22201 | >.> |
| 20:44:58 | skrylar[m] | i'm not sure that cross compiling is worth it in the first place, but eh. |
| 20:47:03 | skrylar[m] | something i like doing is putting a gulp pragma in to call pkg-config |
| 20:47:29 | skrylar[m] | since you will want both cflags and ldflags, and those vary |
| 20:47:51 | skrylar[m] | (i'm not sure if this breaks crossing with nim though) |
| 20:48:10 | * | tklohna quit (Ping timeout: 268 seconds) |
| 20:50:14 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 20:50:15 | * | GordonBGood quit (Read error: Connection reset by peer) |
| 20:53:43 | * | GordonBGood joined #nim |
| 20:58:10 | * | LargeEpsilon quit (Ping timeout: 252 seconds) |
| 21:00:20 | lqdev[m] | skrylar: fortunately, I don't do that and I never will (hopefully) |
| 21:00:28 | lqdev[m] | I just prefer generating calls to macros instead |
| 21:04:01 | * | abm quit (Quit: Leaving) |
| 21:17:06 | disruptek | tell me something good, humans. |
| 21:18:27 | * | narimiran quit (Remote host closed the connection) |
| 21:19:01 | * | eys joined #nim |
| 21:20:42 | disruptek | c-blake released cligen-0.9.41 with a couple fixes for me, then after i bumped my stuff to that tag, he removed it. not a trace. semver ftw. now i'm on nimble/pkgs/cligen-#337c447118879ad875d40969619fc64a02b94312. |
| 21:20:43 | FromDiscord | <exelotl> I'm seeing hatsune miku in january |
| 21:21:03 | disruptek | wtf is that? |
| 21:21:35 | FromGitter | <zetashift> A vocaloid: https://en.wikipedia.org/wiki/Vocaloid |
| 21:22:20 | FromGitter | <zetashift> Not my kind of music, but it's weirdly endearing |
| 21:22:51 | disruptek | interesting. |
| 21:23:29 | FromGitter | <zetashift> Also anyone know if there is an issue/RFC about how Nim/Araq is moving forward with concepts? |
| 21:24:02 | * | jjido joined #nim |
| 21:24:34 | disruptek | there is, but i can't remember if it's in rfcs or issues. |
| 21:26:58 | FromGitter | <zetashift> Oh gotem: https://github.com/nim-lang/RFCs/issues/168 |
| 21:27:36 | disruptek | that's the one. |
| 21:45:02 | * | tklohna joined #nim |
| 21:52:32 | dom96 | I'm actually pleasantly impressed that we have this in our docs: https://nim-lang.github.io/Nim/nimc.html#cross-compilation-for-ios |
| 21:55:40 | dom96 | lol, the xcode I have is too old for Nim |
| 21:58:20 | FromDiscord | <kodkuce> Mac sux anyway |
| 21:58:27 | FromDiscord | <kodkuce> iphone too |
| 21:59:22 | dom96 | Yeah, of course. Don't worry, once I find myself with a decade of free time I will start to use Arch Linux again |
| 22:00:16 | skrylar[m] | its a nice desktop environment |
| 22:00:32 | skrylar[m] | i still based my gui stuff on Be instead of NeXT tho |
| 22:00:44 | skrylar[m] | although i guess since both are based on message passing its not that different |
| 22:03:03 | dom96 | hrm, it seems that --os:ios should possibly imply `macosx` rather than just `posix` |
| 22:04:58 | * | skrylar[m] idly wonders how sr.ht builds actually run |
| 22:05:16 | skrylar[m] | azure and travis are VMs if i recall |
| 22:05:50 | euantor | sr.ht builds are VMs inside QEMU running inside Docker |
| 22:06:02 | skrylar[m] | bizzare |
| 22:06:11 | euantor | So Host -> Docker -> QEMU -> Build |
| 22:06:41 | euantor | Reasoning is that there have been KVM escape issues in the past and docker adds an extra level of sand boxing |
| 22:06:42 | skrylar[m] | i used to use a small jenkins to do canary builds against nim's git |
| 22:06:51 | skrylar[m] | tho laminar is nice for even smaller stuff |
| 22:08:08 | skrylar[m] | yeh. those external CIs are still bothersome IMO |
| 22:08:24 | skrylar[m] | downloading a nim compiler and source checkout every build? egh |
| 22:12:17 | * | eys quit (Quit: eys) |
| 22:14:31 | * | nixfreak28 quit (Ping timeout: 260 seconds) |
| 22:15:08 | skrylar[m] | @dom96 are the gtk bindings old because nobody has bothered to update them |
| 22:15:39 | dom96 | why else would they be old? |
| 22:16:05 | skrylar[m] | politics, intentional deprecation, ... |
| 22:17:15 | skrylar[m] | did gdk3 already, half done with glib |
| 22:17:29 | dom96 | AFAIK salewski has gtk3 bindings |
| 22:18:11 | skrylar[m] | i saw ey was doing something with the introspector |
| 22:22:31 | * | tklohna quit (Ping timeout: 268 seconds) |
| 22:40:11 | FromGitter | <brentp> @mratsim . I just prototyped some code that uses Arraymancer to do dimensionalty-reduction with PCA on genomic data, then trains a simple neural net on labelled samples to do ancestry prediction on incoming samples. |
| 22:47:29 | * | Vladar quit (Quit: Leaving) |
| 22:51:58 | * | LargeEpsilon joined #nim |
| 22:54:50 | dom96 | Nothing like downloading each dependency separately for iOS. This is why I hate dependencies with a passion. |
| 22:57:05 | Araq | lol. it only needs a better package manager. |
| 22:58:41 | * | LargeEpsilon quit (Ping timeout: 276 seconds) |
| 23:08:12 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 23:10:25 | dom96 | yay, a dependency that doesn't respect the `ssl` define |
| 23:10:34 | dom96 | but instead quits my app with "SSL support is required." |
| 23:13:06 | dom96 | https://github.com/CORDEA/oauth/blob/develop/src/oauth2.nim#L295-L297 |
| 23:13:08 | * | dom96 sighs |
| 23:14:42 | * | qwertfisch is now known as zombiefisch |
| 23:17:46 | * | solitudesf quit (Ping timeout: 265 seconds) |
| 23:19:31 | dom96 | yay, a Nim stack trace. Finally! https://i.imgur.com/8H8Eqoj.png |
| 23:26:14 | Calinou | doesn't OAuth imply SSL support? |
| 23:26:18 | Calinou | using it without SSL sounds risky |
| 23:27:47 | dom96 | of course, but when I'm trying to get my large application, which uses oauth for something that's non-critical, running on iOS quitting my application at runtime is a big PITA |
| 23:28:03 | dom96 | it should throw a compiletime error |
| 23:30:53 | dom96 | oooh, lldb goes into SDL's source code. That's nice |
| 23:37:52 | dom96 | now the question is, how do I load a font on iOS |
| 23:38:58 | dom96 | Guess I'll need to implement resource bundling |
| 23:47:11 | * | Sembei joined #nim |
| 23:47:30 | * | Sembei quit (Client Quit) |
| 23:53:02 | shashlick | Just use nimdeps |
