00:06:25 | * | dddddd quit (Remote host closed the connection) |
00:32:27 | * | krux02 quit (Remote host closed the connection) |
00:53:06 | FromDiscord | <jos> wooo hooo!!!! |
00:53:07 | FromDiscord | <jos> https://github.com/simply-jos/darwintiler |
00:53:13 | FromDiscord | <jos> darwintiler now has a backend for MacOS AND x11!!!!!! |
00:53:15 | FromDiscord | <jos> WOOOOOOO!!!!!! |
00:53:18 | FromDiscord | <jos> coding rules!!!! |
00:53:23 | FromDiscord | <jos> ¢ |
00:53:54 | FromDiscord | <jos> thanks to whomever mentioned the where statement |
01:05:39 | nc-x[m] | Just want to post my opinion regarding https://forum.nim-lang.org/t/3888 - I can agree wrt moving tools out of the stdlib (But then testing whether the tool still compiles (with latest devel after any compiler changes were made) would be difficult (idk how they are tested right now, so I may be wrong)). But shrinking the stdlib would IMO be a horrible idea, even if they are made official packages. Having a batteries included |
01:05:40 | nc-x[m] | stdlib is good for popularity, not a small stdlib. A small stdlib will increase the bar to entry for hobbyists and people new to programming. Batteries included stdlib is good for quick implementation and prototyping because you don't waste time thinking about which lib to use. Whereas if more performance/features are desired a person can easily move to a nimble package as and when required. |
01:25:10 | * | leorize joined #nim |
01:47:22 | FromDiscord | <treeform> OMG is this true? "Order of evaluation of the operands of almost all C++ operators (including the order of evaluation of function arguments in a function-call expression and the order of evaluation of the subexpressions within any expression) is unspecified. The compiler can evaluate operands in any order, and may choose another order when the same expression is evaluated again." |
01:47:31 | FromDiscord | <treeform> https://en.cppreference.com/w/cpp/language/eval_order |
01:49:37 | FromDiscord | <treeform> so call to foo(bar(), baz()), baz() can run first, then bar()? |
01:51:23 | FromDiscord | <treeform> It feels like my whole world turns upside down |
01:53:05 | FromDiscord | <treeform> This might be a cool optimization but like have it always. |
01:58:37 | * | leorize quit (Quit: WeeChat 2.1) |
01:59:28 | FromDiscord | <treeform> can I propose that in nim we fix this? And provide like an {.optimize-operator-order.} pragma? |
01:59:30 | FromGitter | <kayabaNerve> Apparently :P |
01:59:54 | FromGitter | <kayabaNerve> Well, if it doesn't share data, you can run all three at once |
02:00:03 | FromGitter | <kayabaNerve> But that's threading which is the user's job. |
02:00:26 | FromGitter | <kayabaNerve> So shouldn't Nim just run left to right? Except for the fact the underlying C compiler can still f it over if it outputs code like this? |
02:00:42 | FromDiscord | <treeform> this is giving me issues: https://gist.github.com/treeform/6eec731f4c72b9f7e36ce7983f1f9d8c |
02:00:53 | FromDiscord | <treeform> the operands all depend on each other, I am reading from a stream. |
02:00:56 | FromGitter | <kayabaNerve> Instead of ⏎ int a = foo() ⏎ int b = bar() ⏎ int c = baz() ⏎ op(a, b, c) [https://gitter.im/nim-lang/Nim?at=5b17405882a4d36ea6d300b0] |
02:00:57 | FromDiscord | <treeform> They come out in random order. |
02:01:14 | FromGitter | <kayabaNerve> treeform: What if you use 4 var statements? |
02:01:24 | FromDiscord | <treeform> no the top thing works. |
02:01:26 | FromDiscord | <treeform> the bottom does not |
02:01:34 | FromDiscord | <treeform> I could not figure out why? |
02:01:35 | FromGitter | <kayabaNerve> Oh. I only saw the top half |
02:01:46 | FromGitter | <kayabaNerve> Yeah. As I said. The C compiler is doing the random thing. |
02:01:52 | FromGitter | <kayabaNerve> I think |
02:02:06 | FromDiscord | <treeform> C compilers actually does the right thing, its the C++ compiler that does not. |
02:02:08 | FromGitter | <kayabaNerve> Edit the compiled C to be explicit about the order |
02:02:19 | FromGitter | <kayabaNerve> So you're using nim cpp? |
02:02:24 | FromDiscord | <treeform> yeah |
02:02:30 | FromDiscord | <treeform> because I need to interface with cpp libs. |
02:03:03 | FromDiscord | <treeform> but both of them can do what ever they want |
02:03:06 | FromGitter | <kayabaNerve> Change the generated C++ from ⏎ ⏎ op(foo(), bar(), baz()) ⏎ ⏎ to ... [https://gitter.im/nim-lang/Nim?at=5b1740d993dc78791cb502aa] |
02:03:21 | FromGitter | <kayabaNerve> Unless we want to say there's already enough evidence |
02:03:49 | FromDiscord | <has1> hey |
02:03:53 | FromGitter | <kayabaNerve> Hi |
02:03:56 | FromDiscord | <treeform> hey |
02:04:06 | FromDiscord | <has1> how would i get the environment variables using nim? |
02:04:20 | FromDiscord | <treeform> I think there is a function in os module? |
02:04:21 | FromDiscord | <has1> I was looking at the Os module |
02:04:28 | FromDiscord | <has1> but i couldnt find anything |
02:05:29 | FromDiscord | <treeform> yeah me too strange |
02:06:16 | FromDiscord | <treeform> https://nim-lang.org/docs/ospaths.html#getEnv,string,string |
02:06:57 | FromDiscord | <has1> Ah yes, i just found it too |
02:07:02 | FromDiscord | <has1> i had to click one of those import links |
02:07:46 | FromDiscord | <has1> thanks, ill try this |
02:12:26 | * | thomasross quit (Quit: Leaving) |
02:13:33 | * | gangstacat quit (Ping timeout: 256 seconds) |
02:17:33 | * | gangstacat joined #nim |
02:29:50 | * | Kaynato quit (Ping timeout: 245 seconds) |
03:13:00 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
03:27:58 | FromGitter | <gogolxdong> How to make WorkProc of threadpool module return values? It has no return value: ⏎ `WorkerProc = proc (thread, args: pointer) {.nimcall, gcsafe.}` |
03:37:56 | FromGitter | <kayabaNerve> How would Nim do on this? https://www.crowdsupply.com/sutajio-kosagi/tomu/ |
03:38:35 | FromGitter | <kayabaNerve> I have 5 right here in front of me and am thinking |
03:38:52 | FromGitter | <kayabaNerve> I think I'll try to use dom96's nimkernel to get something going |
03:39:09 | FromGitter | <kayabaNerve> Not an OS or kernel of course. Just cross compiling, no stdlib |
03:53:13 | FromGitter | <honewatson> @nc-x[m] with unlimited resources I agree with you. However given the number of resources available some practical and pragmatic decisions should be made as to what should be included. As noted in the post such decisions could be driven by stats on actual usage in nim standard lib and nimble packages |
04:20:16 | * | Lord_Nightmare2 joined #nim |
04:21:50 | * | Lord_Nightmare quit (Ping timeout: 260 seconds) |
04:21:52 | * | Lord_Nightmare2 is now known as Lord_Nightmare |
04:56:50 | * | miran joined #nim |
05:11:47 | * | xkapastel quit (Quit: Connection closed for inactivity) |
05:20:46 | FromDiscord | <has1> Can i execute an application directly in memory, just with the bytes? |
05:21:00 | FromDiscord | <has1> How would i do that with nim? |
05:25:43 | FromGitter | <Varriount> has1: Could you elaborate? |
05:26:51 | FromDiscord | <has1> for example, in c# there is Assembly.Load to load an array of bytes into memory |
05:28:25 | * | Lord_Nightmare2 joined #nim |
05:28:36 | * | arecaceae quit (Read error: Connection reset by peer) |
05:29:00 | * | arecaceae joined #nim |
05:31:50 | * | xet7 joined #nim |
05:31:59 | * | Lord_Nightmare quit (Ping timeout: 256 seconds) |
05:31:59 | * | Lord_Nightmare2 is now known as Lord_Nightmare |
05:46:09 | * | nsf joined #nim |
05:50:28 | * | tiorock joined #nim |
05:50:28 | * | rockcavera quit (Killed (weber.freenode.net (Nickname regained by services))) |
05:50:28 | * | tiorock is now known as rockcavera |
05:50:28 | * | rockcavera quit (Changing host) |
05:50:28 | * | rockcavera joined #nim |
06:00:21 | FromGitter | <gogolxdong> @Varriount Can you help to check where goes wrong when issuing request to Price List service of AWS? |
06:08:28 | * | miran quit (Ping timeout: 240 seconds) |
06:12:57 | * | xkapastel joined #nim |
06:17:59 | nc-x[m] | @honewatson I don't understand how splitting up the stdlib will lead to more contributors. A person who has the skills to contribute to a code in a nimble package can as easily contribute to the same source code if it is in the nim repo. And discoverability is not the problem for getting contributors right now. In the official nim side, in the documentation you can find all the stdlib modules. So any interested person can easily |
06:17:59 | nc-x[m] | find some module he wants to contribute to. |
06:18:20 | nc-x[m] | *site |
06:20:22 | nc-x[m] | How many contributions do you think other official nim packages in nim-lang github are getting? Many of them are stagnant. Or getting developed by the official regulars only. |
06:21:09 | nc-x[m] | So if the burden of maintenance is on the same people I don't understand how splitting up the stdlib or reducing nim to nim core etc is going to help anything |
06:22:03 | nc-x[m] | I really don't find any logical thing in these arguments but they seem to pop up again and again in the forums |
06:23:43 | nc-x[m] | And for contributions, IMO people would be more interested in contributing directly to the nim repo, if only for the joy of contributing to something that they know people are surely gonna download. |
06:25:02 | nc-x[m] | Another point is that splitting up the stdlib into different packages will divert the attention of the core team from a single repo to multiple different repos. The code is the same, the bugs are the same, the people are the same. But now they need to follow different repositories. |
06:25:57 | * | xet7 quit (Ping timeout: 240 seconds) |
06:26:14 | nc-x[m] | > I really don't find any logical thing in these arguments but they seem to pop up again and again in the forums |
06:26:15 | nc-x[m] | This should have been the last comment but I posted it earlier :P |
06:26:45 | FromGitter | <survivorm> @zetashift Am i still needed? |
06:29:22 | nc-x[m] | Another example, regarding the proposed nim-lang/guiboost. There is nim-lang/ui. It is already separate repo. How many contributors do you think it has? https://github.com/nim-lang/ui/graphs/contributors |
06:34:12 | FromGitter | <alehander42> @dom96 gmail sends the nim forum reset pass mails to my spam, just wondering if this happens to other people |
06:38:06 | nc-x[m] | Also golang and python don't have a small stdlib. Their stdlib is very very vast. |
06:38:39 | * | xet7 joined #nim |
06:39:33 | FromGitter | <survivorm> @alehander42 I think the problem's common. Most people who're not newbies are quite used to this things happening |
06:41:19 | FromGitter | <survivorm> Alternative is rather hard - either maintain your own mail server "whiteness" or using a specialised server like MailGun or something similar, which have some drawbacks, even if your mailing is covered in their free limit |
06:43:09 | FromGitter | <survivorm> For example, they don't have 24/7 avail, from my experience, they have at least couple of hours/month downtime |
06:45:03 | FromGitter | <survivorm> And that's what i've seen myself - with rather seldom usage (not every day, though in some days i've used to send message packs 2-3-4 times a day, packs were about hundreds of thousands letters) |
06:47:35 | * | dddddd joined #nim |
06:53:04 | FromGitter | <alehander42> ah I see |
06:53:45 | FromGitter | <alehander42> well I yeah, I wondered why would it end up there at all(in the spam) as it doesnt seem to have usual characteristics |
06:56:13 | FromGitter | <survivorm> i think they are rather restrictive. If sender mail server is thrown to spam couple of times by gmail users (unresponsive enough to not sign off from the subscription, or by error), new mail from this server ir re-routed to spam automatically |
06:57:11 | FromGitter | <survivorm> Yeah, there are procedures to "clean up" your mail server from their blacklists, but i'm not sure how effective they are |
06:57:43 | FromGitter | <survivorm> and it's a fuss, anyway |
06:59:01 | FromGitter | <survivorm> and you need to know that you're in their black list in the first place |
07:13:14 | FromGitter | <honewatson> @nc-x[m] " I don't understand how splitting up the stdlib will lead to more contributors." --> It allows an under resourced core dev team to focus on a smaller core stdlib. The bar to entry can be stricter and higher to a smaller core stdlib/language repo compared to the other boost packages. I think there would be more people to contribute to domains they feel confident in such as games, web etc if these are |
07:13:14 | FromGitter | ... separated out. |
07:15:44 | nc-x[m] | Again, if people have the ability to contribute they can do so even now. And even if separated as other packages, if the core team is the one developing and maintaining it, then what is the use? |
07:18:10 | * | PMunch joined #nim |
07:18:49 | nc-x[m] | Also if the compiler depends on some stdlib package how are you gonna move it out? |
07:20:43 | nc-x[m] | Anyways it is for the core team to decide... |
07:23:55 | Araq | nc-x[m]: the compiler doesn't rely on Nimble packages :-) |
07:24:34 | nc-x[m] | Araq: stdlib, not nimble |
07:24:41 | nc-x[m] | It surely uses the stdlib |
07:24:41 | Araq | and fwiw I agree with you, maintaining lots of github repos is just a burden on top of everything else we need to do |
07:25:28 | Araq | but it depends, it's nice that packages can progress independently of Nim releases |
07:28:42 | Araq | nc-x[m]: if the compiler depends on it, it's not gonna be moved out :P |
07:29:16 | nc-x[m] | But right now if any compiler changes are made the stdlib has to also be fixed with it if it creates any issues. If you split the stdlib, those packages will be out of sync with devel. And those of us using devel surely won't be happy ;D |
07:31:03 | nc-x[m] | Also AFAIK much of the stdlib is pretty much stable and requires only occasional bugfixes. So moving them out so they progress independently is quite useless in that case. And if they remain in the stdlib and some major bug is found in one of the stdlib module, then thats what point releases are for. |
07:31:30 | * | Lord_Nightmare2 joined #nim |
07:31:33 | * | Lord_Nightmare quit (Ping timeout: 256 seconds) |
07:32:26 | * | Lord_Nightmare2 is now known as Lord_Nightmare |
07:34:51 | PMunch | Is honewatson known by something else here? |
07:35:46 | Araq | assuming that's true for the existing stdlib, it's not an argument for moving e.g. 'ui' to the stdlib |
07:36:19 | Araq | ideally I would commit ownership of 'ui' to somebody else ;-) |
07:39:28 | nc-x[m] | Araq: Yeah. Moving any module to stdlib would ideally require a proposal explaining its use case and maintenance burden and why it is better in the stdlib than a nimble package. |
07:39:29 | nc-x[m] | But splitting the stdlib requires even bigger proposal that explains (not in general terms as it is being done right now but) for **each module** why it should be removed from the stdlib. And as I already said, the current reasoning does not make sense to me. |
07:40:39 | nc-x[m] | PMunch: he uses gitter so just append an `@` before his name |
07:40:42 | nc-x[m] | *a |
07:46:06 | PMunch | Aaah, thanks. @honewatson thanks for the PR to the language server protocol :) |
07:49:28 | * | jjido joined #nim |
07:52:07 | * | floppydh joined #nim |
07:59:22 | * | crem quit (Ping timeout: 245 seconds) |
08:00:27 | * | yglukhov[i] quit (Read error: Connection reset by peer) |
08:00:59 | * | yglukhov[i] joined #nim |
08:01:23 | * | crem joined #nim |
08:02:43 | * | gmpreussner_ quit (Ping timeout: 256 seconds) |
08:04:10 | * | Vladar joined #nim |
08:04:31 | * | gmpreussner_ joined #nim |
08:08:45 | * | jjido quit (Ping timeout: 264 seconds) |
08:08:50 | * | yglukhov[i] quit (Read error: Connection reset by peer) |
08:09:26 | * | yglukhov[i] joined #nim |
08:16:11 | FromGitter | <dandevelo> Is there any way to make converters expand inline like templates instead of a proc being generated for the converter? |
08:21:16 | PMunch | Mark it as {.inline.}? |
08:21:48 | PMunch | Not sure if that works for converters, but it works for procs |
08:22:41 | FromGitter | <dandevelo> Thanks @PMunch , I did that but I still see a converter proc generated in the C code. |
08:24:29 | FromGitter | <dandevelo> This could be useful for simple scenarios like this one: https://forum.nim-lang.org/t/3042#19138 |
08:25:29 | FromGitter | <dandevelo> converter countryCapitalToString(c:country):string = capital[c] |
08:26:53 | PMunch | Yeah IIRC the inline thing is a hint to the C compiler |
08:27:24 | PMunch | So it will still show up in the C code, but get inlined when compiled further (if your compiler supports it and finds it useful) |
08:32:49 | FromGitter | <dandevelo> That's what I am also thinking. I guess I will just trust the compiler with this |
08:34:29 | PMunch | You could always check the output assembly :) |
08:39:47 | FromDiscord | <jos> www.godbolt.com |
08:40:07 | * | rauss quit (Ping timeout: 256 seconds) |
08:40:23 | FromDiscord | <jos> ^ online compiler that lets you view the disassembly in a nice way |
08:40:27 | FromDiscord | <jos> it RULES! |
08:43:10 | FromGitter | <dandevelo> @PMunch: true that :) |
08:49:34 | PMunch | jos, that's godbolt.org by the way |
08:50:16 | PMunch | And problem with that is you have to get it to load nimbase somehow |
08:53:21 | * | Yardanico quit (Ping timeout: 256 seconds) |
08:58:17 | PMunch | Hmm, looked at the assembly code for some trivial example |
08:58:57 | PMunch | With {.inline.} it does remove all mention of my converter. But both cases ended up with just inlining it :P |
08:59:05 | PMunch | I guess GCC was just too smart :P |
08:59:49 | FromGitter | <dandevelo> Also tried the same with VCC and it looks like it will inline it |
09:01:20 | PMunch | Just in case anyone else wants to have a peek: http://ix.io/1ctn/ |
09:10:05 | * | Yardanico joined #nim |
09:14:52 | nc-x[m] | Araq: https://nim-lang.org/docs/manual.html#overloading-resolution-automatic-self-insertions "{.this: self.} will become the default directive for the whole language eventually" Are there reasons why it is not the default atm? |
09:16:15 | Araq | it doesn't work well :-) |
09:16:28 | * | birdspider joined #nim |
09:17:23 | nc-x[m] | So would I be trying to shoot myself if I use {.this: self.} manually in my code? |
09:22:16 | Araq | not much shooting going on here but in generics it simply doesn't work. |
09:23:59 | nc-x[m] | Okay |
09:25:28 | * | noonien joined #nim |
09:26:02 | * | krux02 joined #nim |
09:28:10 | Araq | also I would like to remove this rewrite rule entirely... |
09:28:38 | Araq | not because it's bad but because Nim is better served with different rewrite rules and you can't have too many of these before a language explodes |
09:30:20 | * | krux02_ joined #nim |
09:30:29 | FromGitter | <survivorm> Good idea. Pragmas are already complicated enough, sadly |
09:30:32 | * | krux02_ quit (Client Quit) |
09:30:37 | * | krux02 quit (Quit: Leaving) |
09:30:53 | * | krux02 joined #nim |
09:31:08 | FromGitter | <survivorm> By the way, any movements on my pr? ⏎ https://github.com/nim-lang/Nim/pull/7806#issuecomment-394636152 |
09:31:28 | * | krux02 quit (Client Quit) |
09:31:42 | * | krux02 joined #nim |
09:31:51 | * | xkapastel quit (Quit: Connection closed for inactivity) |
09:37:46 | Araq | I already replied? |
09:41:14 | PMunch | Removing {.this: self.} :( |
09:41:37 | PMunch | It's so helpful for OO-esque code, comes in handy when making games |
09:43:35 | Araq | Python survives without it :P |
09:45:20 | PMunch | Isn't it you who say that copying a bad design isn't good design? |
09:46:26 | Araq | well "copying" a non-existing feature is not much of copy is it. |
09:47:05 | PMunch | Well you copy the design of omitting it |
09:47:16 | Araq | <insert your favorite argument against featurism here> |
09:51:49 | Araq | but *shrug* we can also make it work well instead. not sure how to do that though |
10:01:16 | Araq | I can also claim to "copy" the lack of this feature from Rust, Go, Oberon and Lisp |
10:01:37 | Araq | and ML |
10:01:51 | Araq | Ada. |
10:02:04 | * | leaf__ joined #nim |
10:02:27 | * | leaf__ is now known as Guest91693 |
10:03:00 | Guest91693 | hey, is there's a reason why the case statement breaks after every case by default unlike the the switch statement? |
10:04:23 | PMunch | I originally started loving Nim because it dared to be different. The way lot's of things seemed to break with tradition but always had a good reasoning behind it making you feel like the others were wrong about it. I can see why {.this: self.} might be hard to implement, and honestly it's not a deal-breaker, but I just hope Nim continues to challenge the norm in other areas and not just ending up as a mish-mash between all the other languages already out |
10:04:24 | PMunch | there. |
10:04:50 | PMunch | Guest91693, because most people tend to mess up their switch statements since they don't break by default |
10:05:07 | PMunch | And it's very rare that you actually want to fall through to the next case. |
10:05:09 | nc-x[m] | rust has self inside traits though |
10:06:18 | PMunch | Guest91693, what you can do if you do need it is use a range for your `of` statement and simply use a secondary check for things that shouldn't happen for all cases. |
10:06:19 | nc-x[m] | But i agree, if removing {.this.} makes nim simpler then so be it |
10:08:38 | Araq | well it's a typical Nim thing. Feature got implemented, works actually quite well but not with every language feature |
10:08:57 | Araq | and we're left in an uncomfortable position. |
10:09:28 | FromGitter | <survivorm> @Araq thanks for the reply, PR updated |
10:10:11 | Araq | where we have to spend more time to make it work really well but it usually also means updating the spec too to document the special cases |
10:10:25 | Araq | or where we have to remove it again. |
10:10:53 | Araq | and once it works really well we're left with a larger spec at least... |
10:10:54 | Guest91693 | breaking by default is fine but not allowing to keep checking other cases is kinda limiting, trying to implement a duff's device which relies on the ability of the switch statement to not break, I ended up either wrapping the case statement in a "while true" and add a control variable or use a series of "if" statements, both seems ugly |
10:11:27 | Araq | duff's device is a series of 'if' statements without 'elif' parts |
10:11:49 | Araq | it doesn't deserve syntax sugar. |
10:12:08 | Araq | nor does it require a 'while' loop afaict |
10:12:37 | FromGitter | <survivorm> @PMunch i think the point is not to make Nim a haystack |
10:13:13 | FromGitter | <survivorm> Too much features is not only hard to support, it's also hard to comprehand |
10:13:18 | PMunch | A haystack implies you have to look for the good bits as needles. I feel like Nim is more like a needlestack |
10:13:50 | Guest91693 | I thought I was doing it the wrong way but if that how it is then it's fine, thanks! |
10:13:50 | FromGitter | <mratsim> Favorite argument against featurism: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupéry |
10:13:55 | FromGitter | <survivorm> The problem is that the people are limited |
10:14:58 | FromGitter | <mratsim> I like this: self but I don’t like it when files start to get quite long. I indeed used it a lot for an emulator and my go playing bot. |
10:15:23 | FromGitter | <survivorm> and someone's needles are the other one's straw |
10:15:49 | PMunch | The problem with that quote is that it doesn't offer any insight as to what should and shouldn't be removed |
10:16:44 | PMunch | Sure, if Nim had a lot of cruft, life four different ways to say if, then I could agree. But this: self is a feature in it's own right, removing it is removing functionality which can't be achieved otherwise. |
10:18:16 | PMunch | Guest91693, why are you implementing Duff's device in Nim anyways? |
10:18:37 | FromGitter | <mratsim> I think it’s up to us to define the question. Something like “Does this contribute to Nim efficiency, expressiveness or elegance?” —> yes, no |
10:19:05 | Araq | PMunch: well in the longer run you will be able to write a macro that does the same... |
10:20:07 | FromGitter | <mratsim> `this: self`, and `using` contributes to elegance and readability but at the expense of debugging I would say so I’m not sure. |
10:20:38 | nc-x[m] | If the macro is in system.nim, then good enough. I prefer sane defaults than `importing` stuff for even simple things that should be the default. |
10:21:10 | PMunch | Araq, in the longer run? |
10:21:35 | FromGitter | <survivorm> I'll say no to [almost] any feature that makes debugging much harder. In the longer run, support is that counts |
10:21:48 | Araq | nc-x[m]: well no, once the rewrite rule can be done via a macro, it shouldn't be the default |
10:21:54 | PMunch | Are you referring to debugging for us or for the user? |
10:22:27 | PMunch | mratsim, do we have `using` in Nim? |
10:22:40 | FromGitter | <survivorm> @PMunch not sure i understand you |
10:22:43 | PMunch | Googling "Using Nim" didn't give any helpful results :P |
10:23:03 | Araq | PMunch: we have 'using' for parameter type "inference" |
10:23:12 | PMunch | survivorm, debugging for people using Nim, or people developing Nim |
10:23:14 | Araq | it used to be used for a .self like feature. |
10:23:39 | Araq | debugging is not clearly defined. debugging with GDB, echos, VS Code? |
10:24:40 | nc-x[m] | Araq: I mean would we need to import the macro before using it or would it be available for use directly |
10:24:48 | FromGitter | <survivorm> The debugging is the process of trying to find out what goes wrong (or even wider - of finding out HOW does the things go), so it's not important who's debugging. If feature is making it harder - i'll say no |
10:24:54 | * | Guest91693 quit (Quit: Page closed) |
10:25:04 | Araq | nc-x[m]: you would definitely need to import it. |
10:25:28 | nc-x[m] | :( |
10:26:09 | nc-x[m] | Features like these should be available by default instead of sugar.nim or anywhere else |
10:26:12 | FromGitter | <data-man> @PMunch: If I'm not mistaken, you also wanted memory-mapped streams. :) #7944 |
10:26:21 | Araq | that's my solution to the "useful rewrite rule" problem. I want all of them, but not all the time |
10:26:55 | Araq | so I have to be more explicit which ones apply in which scopes. |
10:27:28 | Araq | seems fair to me, for any particular feature you can argue "omg, needs to be the default" |
10:27:41 | Araq | but never for their combination. |
10:28:11 | FromGitter | <mratsim> @PMunch: https://github.com/status-im/nimbus/blob/040c09d5a99aa1e39e011247085830cc86d48b83/nimbus/logic/block_ops.nim#L15-L18 |
10:28:28 | FromGitter | <survivorm> That seems fair, if I undersatd correctly |
10:28:37 | nc-x[m] | Well, I am going to argue that giving people too many options would lead to crappy code and instead sane defaults would be the sanest choice |
10:28:42 | FromGitter | <mratsim> but `using` is better than this:self because if you don’t see a signature you know right away it’s ùsing` |
10:28:53 | FromGitter | <survivorm> That means different contexts of rule sets? |
10:29:28 | Araq | nc-x[m]: the default would be "too few options with more typing", a pretty safe bet :P |
10:29:35 | FromGitter | <mratsim> this: self however, you don’t know if value came from a global var, a local var, a this: self |
10:29:37 | FromGitter | <survivorm> Or may be even different domains |
10:30:21 | nc-x[m] | Well we can argue whole day :D |
10:31:13 | PMunch | Yeah I'd prefer using to this: self myself |
10:31:18 | FromGitter | <survivorm> If that's what you're suggesting, Araq, than it's good idea. Not only it must be simpler to implement, it also makes it easier to learn and comprehand |
10:32:40 | PMunch | Oh that's how it works mratsim. I thought it would be something like "using(someObject): |
10:33:02 | PMunch | And code put in that block would be like dropping things within a this: self proc |
10:34:33 | * | SenasOzys quit (Ping timeout: 264 seconds) |
10:35:53 | Araq | so ... in order to help the contributors, when you review something like this: https://github.com/nim-lang/Nim/pull/7550/files |
10:38:10 | Araq | you need to watch out for 'reject' tests. |
10:38:38 | Araq | it's most important that not suddenly some crap starts to compile that should have been rejected. |
10:39:13 | Araq | a language where everything has a valid interpretation is one that doesn't detect any errors. |
10:40:11 | FromGitter | <gogolxdong> @Varriount request to AWS Cost Explorer service and Price List service got unmatched signature . |
10:43:09 | krux02 | Araq: Just for curiosity, do you have an opinion on Microsoft owning github? |
10:44:13 | * | SenasOzys joined #nim |
10:44:24 | * | SenasOzys quit (Remote host closed the connection) |
10:45:01 | FromGitter | <mratsim> @Araq, isn’t that called a dynamic language ;) |
10:45:53 | Araq | krux02: seems bad, I'm not a fan of MS (even though I might look like one from time to time) |
10:46:27 | Araq | but even my personal opinion aside, seems objectively bad for github, people are migrating |
10:49:34 | krux02 | I thought the same. It is one company less in the pool of companies that make the internet. At least git, the foundation of github, makes migration of the project itself easy. |
10:50:16 | krux02 | when they pay so much money, they really want to market it, and get that money out at some point in time. |
10:50:34 | krux02 | Expect things to get pricier |
10:50:57 | krux02 | you just don't know yet how you pay Microsoft. |
10:51:22 | FromGitter | <mratsim> What changed after Microsoft acquisition of LinkedIn btw? |
10:52:53 | Araq | we don't know, nobody really used LinkedIn |
10:52:58 | Araq | XD |
10:55:31 | FromGitter | <mratsim> Ah, that’s why I got so many recruiter invites, when they find a dev on LinkedIn it’s like they found an unicorn :/ |
10:56:48 | krux02 | well what changed after the Microsoft acquision of Minecraft. I have to create and use a Microsoft account instead of my Minecraft account. You can expect the same to happen to Github, too. In the future it will become harder and harder to use the github account and you will be pushed to merge it with your microsoft account |
10:57:33 | krux02 | soon you can login to Mincraft with your github account :/ |
10:57:48 | PMunch | Also a lot larger focus on Windows and Xbox compatibility |
10:58:01 | PMunch | But I doubt Git for xbox will be released anytime soon :P |
10:58:37 | PMunch | How do you use git on Windows by the way? From cmd, or do you have to use cygwin or something like that? |
10:58:41 | krux02 | A yea, the name changed from "Minecraft" to "Mincraft Java Edition" to make it seem like it is not the core focus. |
10:58:55 | krux02 | and push people to use the other versions that are tied to microsoft platforms |
10:59:32 | krux02 | PMunch: On windows I think people use clients that don't exist on linux |
11:00:08 | krux02 | But it's just a guessing game, the cmd on windows is just horrible, I don't want to go there again |
11:00:17 | PMunch | Hmm, let's hope they don't rewrite git at least.. |
11:00:39 | krux02 | I think msys2 has git, and maybe the ubuntu subsystem for windows also has git. that might be an option |
11:01:11 | krux02 | so you can install git in three ways: msys2, cygwin, ubuntu subsystem |
11:01:28 | krux02 | great that you have so many options :/ |
11:01:43 | Araq | you really don't, only msys2 is sane :P |
11:02:23 | krux02 | I kind of like msys2, I use arch Linux, and msys2 makes me feel at home with pacman |
11:02:24 | floppydh | most sane* |
11:02:32 | krux02 | but never really used it |
11:02:42 | krux02 | I almost never use Windows anymore |
11:02:47 | floppydh | krux02: it has very few packages tho and it needs a lot of configuration to harmonize with the windows-env |
11:03:18 | floppydh | git-bash seems like a very good default, they use msys2 too, but for whatever reason decided to strip pacman |
11:03:23 | krux02 | well yea, Arch Linux here, |
11:05:03 | krux02 | that needs a lot of configuration |
11:05:55 | krux02 | especially when you want to use a printer |
11:06:15 | krux02 | (why is using a printer still such a nightmare) |
11:06:43 | Araq | my ubu cannot even do package management anymore |
11:06:50 | Araq | it keeps crashing |
11:09:06 | Araq | probably because I run it in a VM |
11:09:15 | Araq | but still... this used to work. |
11:11:09 | krux02 | well ubuntu is not very liked anymore. It constantly got in this state of too old packages so that I had to do dist upgrade. And then dist upgrade broke the entire system so that I had to clean install everything |
11:11:18 | krux02 | I am not going back anymore. |
11:11:56 | floppydh | ArchLinux is great once you've set it up and get comfortable with it |
11:12:25 | floppydh | What still kills me with Windows is how the lack of package-managing ripples throughout its software community |
11:12:48 | floppydh | Like my co-worker decided to not use boost for his project simply because installing it under Windows was something he tried and simply had given up |
11:13:07 | floppydh | Granted, it says a lot about him too, but still |
11:13:13 | Araq | that's exactly what I like about it, I can be ensured my games continue to run |
11:13:32 | floppydh | Well that's just a static vs dynamic linking thing no, that's not the issue/thing with package managers |
11:13:35 | Araq | because they are pretty much self-contained |
11:13:59 | Araq | package managers always use dynamic linking in practice. |
11:14:14 | floppydh | most of boost is header only and I install it with a single command? |
11:14:35 | floppydh | but true, most still is |
11:14:39 | krux02 | well the linux package manager isn't really made for closed source dynamic libraries. |
11:14:42 | Araq | who cares about boost? why should this be a Windows thing |
11:14:58 | Araq | 'c++nimble install boost' done. |
11:14:59 | floppydh | I just think that package managers != dynamic linking |
11:15:19 | Araq | oh c++ lacks 'c++nimble'? that's C++'s problem then. |
11:15:23 | floppydh | yeah |
11:15:30 | floppydh | they wont fix it tho |
11:15:42 | krux02 | c++ has more problems than the lack of modules |
11:15:57 | floppydh | I actually came to believe its its biggest issue |
11:16:18 | floppydh | But that's just because I'm not stuck on a single big cpp project that already has everything written in-house |
11:16:29 | krux02 | it was invented in a time without internet, and where computers were thought be be this boxes where users write their own programs on. |
11:17:03 | floppydh | but anyway, that's just for stuff like boost - The python installation on windows is also something I don't really get |
11:17:24 | floppydh | but there's thousands of issues with Windows that a package-manager with proper dependency tracking can do for you |
11:17:50 | krux02 | I don't really get python. I try to get rid of everthing on my desktop that uses it. |
11:18:04 | Araq | Python is fine on Windows, on my Mac I'm still stuck with Python 2.4.4 |
11:18:21 | Araq | with no idea how to remove it |
11:18:32 | floppydh | Araq: you can't, get brew |
11:18:34 | krux02 | Araq: not just python is old. gdb is old, opengl is old, (put in any open source softwar) is old |
11:18:43 | floppydh | brew fixes all those issues |
11:18:44 | floppydh | if Windows had brew, I wouldn't complain |
11:18:49 | Araq | tbh OS specific package managers are all way more fucked up than Windows is without a package manager. |
11:19:08 | krux02 | when java was still a thing: java is old on mac |
11:19:17 | floppydh | I tried to install py2 and py3 side-by-side but both installations (that polute C:/ for whatever reason) are named "python.exe" so I can't just add them to PATH - I don't even |
11:19:22 | Araq | the fact that Windows doesn't require >4 shitty scripting languages installed to boot up is a nice thing too |
11:19:53 | floppydh | package managers are not involved in the boot-up process :P |
11:19:54 | euantor | And if you need a package manager for Windows there are several. I like chocolatey personally |
11:19:56 | FromGitter | <Electrux> are we praising windows? cool :D |
11:20:08 | floppydh | brew is fine, it's not my style, but I accept it because most developers on macos rely on it |
11:20:18 | floppydh | I actually got most of what I wanted on brew and it worked |
11:20:26 | FromGitter | <Electrux> < loves 2 package managers - brew and pacmans |
11:20:34 | krux02 | Araq: ara you sure that windows doesn't use some shitty implementation of javascript for the GUI? |
11:20:48 | floppydh | chocolatey instead seems like something that tries to fix what can't be fixed |
11:20:49 | krux02 | I have no idea, but javascript for gui seems really popular these days |
11:20:53 | Araq | no, I'm not sure, but here is the thing: |
11:21:05 | Araq | I can safely ignore the shit they doing under the hood. |
11:21:18 | euantor | WIndows UWP apps can use JS + HTML |
11:21:27 | euantor | But Win32 stuff is still Win32 |
11:21:54 | Araq | whereas with Linux I need to learn it all or else it breaks and even then it breaks. |
11:22:07 | krux02 | but the shit they are doing under the hood is continuously piling up the huge istallation size of Windows |
11:22:17 | FromGitter | <Electrux> i dislike that web tech is used for desktop apps… it does look beautiful, but still… native applications feel wonderful while using |
11:23:16 | FromGitter | <Electrux> Krux02: doesn’t windows use (mostly) c# / dot net for UI? |
11:23:17 | FromGitter | <Electrux> :O |
11:24:29 | krux02 | Electrux: not quite: native fullscreen applications (not borderless window that looks fullscreen), on a CRT monitor (no lag), feel great |
11:25:22 | FromGitter | <Electrux> i dunno… they don’t feel that good to me… they do look so beautiful though :D |
11:25:25 | krux02 | but the time is over. Developing software is not anymore actually developing softwar, but reliably removing all the crap that other people put in the pipeline |
11:25:37 | FromGitter | <Electrux> lmao |
11:25:40 | FromGitter | <Electrux> amen to that xD |
11:25:51 | floppydh | I mostly add crap |
11:27:59 | FromGitter | <Electrux> lol |
11:30:13 | krux02 | when you run a game on a desktop computer, you basically render in a window buffer, this window buffer is then rendered on the screen buffer with streaching and interpolated pixels involved beacause reasons, the screen buffer is transmitter over HDMI to the buffer of the monitor. The monitor makes some "smart" post processing to make it look shit. And then eventually it will be rendered in some form in an undefined time on the the screen |
11:31:23 | krux02 | when you develop on NES, you write to memory that is regulary scanned and directly transmitted to the TV where the analogue signal directly without buffer controls the resulting image. |
11:31:50 | krux02 | so you just write to a dedicated area in memory and that stuff will be seen |
11:32:27 | krux02 | now you really have to find a way that your customers don't fuck up and by accident have some of the image worsening post processing steps active. |
11:34:27 | Araq | krux02: btw Apple just deprecated its OpenGL APIs ;-) |
11:34:37 | krux02 | yay |
11:35:17 | krux02 | well then I declare Apple as deprecated |
11:36:10 | krux02 | Araq: where is your source for that information though? |
11:39:24 | * | DarkArctic_ quit (Quit: Leaving) |
11:39:44 | * | DarkArctic joined #nim |
11:40:54 | * | camparis is now known as }{ultimo}{ |
11:45:36 | Araq | https://appleinsider.com/articles/18/06/04/opengl-opencl-deprecated-in-favor-of-metal-2-in-macos-1014-mojave |
11:45:49 | FromGitter | <mratsim> They deprecated OpenGL and OpenCL |
11:46:08 | FromGitter | <mratsim> aka, Adobe is in deep shit, Maya, Cinema4D too, Blender as well |
11:47:38 | FromGitter | <mratsim> CaptureOne and all cross-platform photo editing and video editing softwares. Maybe CAD too though CAD is not popular on MacOS |
11:48:30 | Yardanico | krux02 they officially deprecated it (they already have the notice on their developer website) |
11:48:39 | Yardanico | and yeah, they didn't say that on WWDC, they silently deprecated it :D |
11:49:16 | FromGitter | <mratsim> OpenGL has Metal but there is no OpenCL alternative by the way |
11:49:29 | Yardanico | they say you should use metal and metal shaders instead of OpenCL |
11:49:37 | Yardanico | and of course their ML tools (for machine learning) |
11:49:51 | FromGitter | <mratsim> their ML tool is a joke |
11:50:05 | FromGitter | <mratsim> you cannot train model with it. |
11:50:14 | krux02 | really Apple is too big, they should fall flat on their face with this tactics. |
11:50:49 | Yardanico | Too big to fail (TM) |
11:51:14 | krux02 | they should go back where they were in 1998 |
11:51:32 | FromGitter | <mratsim> AIG and Allianz and Kodak and Nokia and Yahoo and … managed to fail though |
11:53:00 | FromGitter | <mratsim> but basically they alienated their photo and movie partners and the visual creatives that are their top audience. |
11:53:26 | FromGitter | <mratsim> I can’t imagine the number of hours a studio like Pixar put in OpenCL |
11:54:52 | krux02 | don't forget OpenGL |
11:55:23 | krux02 | I can understand it OpenGL smells, it really has it's problems. But really go back to proprietary solutions? |
11:56:06 | FromGitter | <mratsim> OpenGL has a replacement though, so I think one way or another, there will be porting possible |
11:56:19 | FromGitter | <mratsim> through a translation layer for example |
11:56:36 | FromGitter | <mratsim> but OpenCL has nothing. |
11:57:11 | Yardanico | yeah, there's MoltenGL (but it's proprietary and supports only OpenGL ES 2.0) |
11:57:11 | krux02 | it's not like Apple has any different Hardware than other computers |
12:00:50 | Yardanico | will be launched in the next couple of months - http://v2.exercism.io/tracks/nim |
12:01:18 | Yardanico | (currently student/mentor count is broken it seems) |
12:02:39 | * | fvs joined #nim |
12:03:13 | FromDiscord | <ZarsBranchkin> hm, no Nim syntax highlighting on that site? I wonder what it uses for highlighting |
12:03:30 | Yardanico | it does highlight for me |
12:03:44 | FromDiscord | <ZarsBranchkin> https://v2.exercism.io/tracks/nim/exercises/bob/solutions/84b0966e4e0a43e3beb4cf0010e1b395 |
12:04:06 | FromGitter | <zetashift> not highlighted for me too on that solution |
12:04:14 | Yardanico | yeah |
12:04:18 | FromGitter | <zetashift> but the main example they show on the tracks ite is highlighted |
12:04:19 | Yardanico | maybe because it's still beta, I don't know :) |
12:20:16 | PMunch | If anyone is bored: https://github.com/PMunch/nimlsp/issues/2 |
12:22:13 | PMunch | Not highlighted for me either by the way, two errors in the log, both "Failed to load resource: net::ERR_BLOCKED_BY_CLIENT" for static.hotjar.com and google-analytics.com/analytics.js |
12:29:02 | PMunch | Or if you want a more interesting challenge: https://github.com/PMunch/nimlsp/issues/3 |
12:33:33 | Yardanico | ok, two exams are over, only physics left (on 20th) :) |
12:33:54 | PMunch | And @alehander42, from yesterdays question: I haven't looked at too many, only had a peek at the Python implementation. |
12:34:07 | PMunch | Yardanico, congrats, good feeling? |
12:35:58 | krux02 | I remember a website where the last post ever was, "Finally the exams are over, you can expect that updates are coming soon" |
12:36:14 | Yardanico | PMunch well, probably yeah, I mean that of course I didn't fail the exams, but the results directly influence the university I will go to. |
12:37:01 | Yardanico | because I'm aiming at free education :) |
12:37:23 | PMunch | Free education is best education :) |
12:37:50 | PMunch | Well, mine wasn't free per se. but €50 per semester isn't all that bad :P |
12:38:05 | Yardanico | from some website - " High EGE scores are important for access to the limited number of tuition-free seats at Russian universities." EGE is ЕГЭ - Unified State Exam |
12:38:06 | PMunch | Probably made that back in student discount on beer anyways |
12:38:35 | PMunch | Wait, why is the second E different? |
12:38:44 | Yardanico | it's not an E :) |
12:39:02 | Yardanico | https://en.wikipedia.org/wiki/E_(Cyrillic) |
12:40:22 | Yardanico | cyrillic alphabet has a bit more letters (33 vs 26) than latin |
12:41:11 | PMunch | Oh, I thought it was a literal translation of EGE |
12:41:17 | PMunch | That makes more sense |
12:41:37 | PMunch | Didn't know the cyrillic alphabet had that many characters, thought they were just different |
12:41:39 | Yardanico | btw, we have user with nickname "literal" in this channel :) |
12:41:49 | PMunch | We have 29 in Norwegian :) |
12:42:15 | PMunch | That's gotta be annoying |
12:42:18 | * | PMunch is now known as the |
12:42:23 | Yardanico | lol |
12:42:28 | * | the is now known as PMunch |
12:42:40 | Yardanico | PMunch you can type that fancy "æ" without any issues though :D |
12:42:57 | PMunch | Yup, æÆ |
12:43:02 | * | Electrux joined #nim |
12:43:06 | FromGitter | <alehander42> russian cyrillic is a bit bigger than usual |
12:43:13 | Yardanico | yeah, it is |
12:43:21 | FromGitter | <alehander42> bulgarian has 30 and serbian has 29 i think |
12:43:33 | PMunch | Plus åÅ and øØ |
12:43:37 | FromGitter | <alehander42> when I lived in denmark æ was bugging me so much :D |
12:43:51 | PMunch | Haha, why don't you like æ? |
12:44:13 | FromGitter | <alehander42> it's like two letters half-merged together, like a body with two heads |
12:44:16 | FromGitter | <alehander42> it's weird :D |
12:44:21 | PMunch | https://www.youtube.com/watch?v=f488uJAQgmw |
12:44:45 | FromGitter | <alehander42> the left guy looks like a very skinny young Joey |
12:45:23 | FromGitter | <alehander42> ABBA really changed these days .. |
12:58:05 | krux02 | æÆ, yay, compose key for the win |
12:58:14 | krux02 | œŒ |
12:58:40 | krux02 | sorry, when it is about typing symbols i just have to join the conversation |
12:59:54 | PMunch | Hmm, I found a shortcut for triggering an Emoji selector the other day, can't remember what it was though.. |
13:00:07 | PMunch | 😁 |
13:00:09 | PMunch | Found it |
13:00:13 | krux02 | cool |
13:00:23 | PMunch | Ctrl+Shift+E, logical enough |
13:00:25 | krux02 | emoji on IRC |
13:00:30 | PMunch | 👑 |
13:00:40 | krux02 | what os/input system? |
13:01:10 | PMunch | Linux, keyboard |
13:02:01 | krux02 | what keyboard layout? |
13:02:09 | krux02 | I have linux, too, but I don't have that |
13:02:14 | PMunch | Norwegian Dvorak |
13:02:16 | krux02 | (I use xfce, maybe it is related to that) |
13:02:25 | krux02 | ok, then I guess it is not the layout |
13:02:32 | PMunch | It was originally running OpenSuse KDE, but I installed i3 over it |
13:02:33 | krux02 | what desktop environment? |
13:02:48 | krux02 | hmm, I kind of don't think it is an i3 thing |
13:03:02 | PMunch | Haha, definitely not :P |
13:03:02 | krux02 | i3 is too minimal to implement an emoji selector |
13:03:40 | PMunch | https://forums.opensuse.org/showthread.php/528509-How-to-disable-CTRL-SHIFT-e-gnome-emoji-shortcut |
13:08:55 | PMunch | It seems like it's a Gnome thing |
13:09:00 | * | Vladar quit (Remote host closed the connection) |
13:09:19 | * | Vladar joined #nim |
13:11:14 | PMunch | wtf, the Norwegian flag is annotated as "bouvet island".. |
13:11:35 | PMunch | Bouvet Island is an uninhabited subantarctic high island and dependency of Norway located in the South Atlantic Ocean |
13:11:46 | PMunch | A part of Norway sure, but nothing anyone has heard about.. |
13:16:08 | * | nsf quit (Quit: WeeChat 2.1) |
13:17:47 | krux02 | :( I have a problem, I have mutual recursion on a generic proc |
13:18:37 | krux02 | and depending on whether I define overload A first it doesn't find overload B and vice versa |
13:18:43 | krux02 | there is no order to define the functions |
13:18:47 | krux02 | :( |
13:18:50 | krux02 | I am unhappy |
13:19:57 | krux02 | how do I forward declare a generic proc? |
13:20:01 | FromGitter | <mratsim> strange, mutual recursion works for me |
13:20:25 | FromGitter | <mratsim> https://github.com/status-im/nim-stint/blob/master/stint/private/uint_div.nim#L47-L49 |
13:21:10 | FromGitter | <mratsim> div2n1n calls divmod which calls div3n2n which calls div2n1n |
13:21:41 | krux02 | for me it doesn't |
13:21:55 | krux02 | but I am generating the call from a macro |
13:24:21 | * | clyybber joined #nim |
13:26:16 | * | SenasOzys joined #nim |
13:34:00 | krux02 | mratsim: http://ix.io/1cuw |
13:34:13 | krux02 | that is my mutually recursive function |
13:34:39 | krux02 | I try to forward declare it, but it just refuses to compile |
13:34:48 | krux02 | it constantly tells me "implementation expected" |
13:34:55 | krux02 | I copied the definition |
13:35:20 | krux02 | how do I do it anyway? where do I put the export* ? |
13:37:28 | FromGitter | <mratsim> (https://files.gitter.im/nim-lang/Nim/FEdQ/2018-06-06_15-37-16.png) |
13:37:40 | FromGitter | <mratsim> I copied your stuff as is and it works for me :? |
13:40:53 | krux02 | that module works that is not the problem |
13:40:57 | krux02 | but thank you for trying it |
13:41:21 | Araq | krux02: pragmas and the * export marker go the forward decl |
13:41:26 | Araq | *go to |
13:43:36 | krux02 | mratsim: for some reason when I use the function within the module I don't get the compilation problem, but when I call the function from outside it doesn't work |
13:44:24 | krux02 | Araq: I moved the export marker to the forward declaration and it doesn't work |
13:44:31 | krux02 | http://ix.io/1cuy |
13:48:01 | krux02 | When I call std140AlignedWrite from another module I get this error message: http://ix.io/1cuA |
13:49:07 | krux02 | and the error is from std140AlignedWrite array implementation |
13:49:54 | krux02 | the super weird thing is that I do exactly the same thing frome within the same file |
13:50:05 | nc-x[m] | Whats the plan with https://github.com/status-im/nim-asyncdispatch2 ? Is it going to make way into the stdlib? I see it has fixed some bugs which are in the stdlib asyncdispatch. |
13:50:06 | krux02 | I have that case covered |
13:50:39 | nc-x[m] | > nim-asyncdispatch2 - Asyncdispatch hard fork. |
13:50:40 | nc-x[m] | |
13:50:41 | nc-x[m] | And why is it a hard fork? |
13:51:01 | FromDiscord | <citycide> anybody run into Nimble not finding the stdlib on travis? ie. https://travis-ci.org/citycide/glob/jobs/388775329#L1343 |
13:51:31 | FromDiscord | <citycide> probably missing a path somewhere, may need to set that env var it talks about |
13:53:03 | FromGitter | <Varriount> nc-x[m]: Huh, I wasn't even aware that existed. |
13:53:12 | * | Vladar quit (Quit: Leaving) |
13:53:14 | Yardanico | @citycide can you try to add ".nimble/bin" to the path? |
13:56:15 | FromDiscord | <citycide> Yardanico: you mean `~/.nimble/bin` ? |
13:56:18 | Yardanico | yeah |
13:56:25 | FromDiscord | <citycide> will try |
13:57:39 | * | Vladar joined #nim |
13:59:01 | krux02 | I don't get it. I tested in isolation that my function works, but as soon as I use it in the macro context it doesn't compile anymore |
13:59:13 | krux02 | even though I tested with the exact same type that the macro generates |
14:00:27 | FromDiscord | <citycide> Yardanico: nope, same error. doesn't that just point it to library binaries anyway? |
14:00:43 | Yardanico | well, I don't know, travis always worked for me |
14:01:09 | Yardanico | ah, I forgot, I don't use travis in a project where I use "nimble install" |
14:04:24 | krux02 | yea weird error, adding an import works now |
14:04:27 | FromDiscord | <citycide> yea, I'll dig through a search on github and see what I can find |
14:04:28 | FromDiscord | <citycide> thanks |
14:04:40 | krux02 | the more I work with Nim modules the more wonky they feel |
14:05:07 | krux02 | but still better than no modules at all like C(++) |
14:05:23 | Araq | I don't have any problems with them |
14:05:55 | Araq | and I'm not sure your code can work with a forward decl as you're after compile-time evaluation for this feature |
14:06:03 | krux02 | sometimes I am a bit confused about symbol binding rules |
14:07:03 | krux02 | especially when I am generating code and the code is generated in a different module than the macro definition |
14:19:26 | * | rauss joined #nim |
14:37:13 | * | SenasOzys quit (Remote host closed the connection) |
14:37:31 | * | SenasOzys joined #nim |
14:39:03 | dom96 | This should really be modified to use choosenim now: https://github.com/nim-lang/Nim/wiki/TravisCI |
14:39:08 | dom96 | citycide: give choosenim a try |
14:39:30 | dom96 | https://github.com/nim-lang/nimforum/blob/master/.travis.yml#L35 |
14:39:48 | * | PMunch quit (Quit: Leaving) |
14:39:50 | dom96 | The desired Nim version can now be specified by setting that env var |
14:40:00 | dom96 | so you can set it to 0.18.0 for example |
14:40:23 | dom96 | or #devel |
14:42:22 | * | }{ultimo}{ quit (Ping timeout: 260 seconds) |
14:49:39 | * | }{ultimo}{ joined #nim |
14:49:40 | * | }{ultimo}{ quit (Changing host) |
14:49:40 | * | }{ultimo}{ joined #nim |
15:06:21 | * | SenasOzys quit (Ping timeout: 264 seconds) |
15:07:16 | yglukhov | dom96: Hey, are you going to simplify asyncmacro now? :) |
15:07:42 | Yardanico | yglukhov does it mean that we possibly will get better async stack traces? :) |
15:12:07 | * | birdspider quit (Quit: Leaving) |
15:24:33 | FromGitter | <mratsim> I would like Microsoft to add Bing Search to Github, currently github search is too much of a joke ... |
15:30:10 | yglukhov | Yardanico: i think async stack traces are not that good just because noone cared enough :). Surely simplifying asyncmacro will technically reduce the number of places where stack trace can be messed up, but we'll see. I'm planning to dive deeper into stacktraces after asyncmacro simplifications. |
15:36:01 | Araq | I remember dom96 live coding about it... |
15:36:17 | Araq | I remember fixing bugs related to it. we did care, but it's tough. |
15:36:46 | Araq | of course maybe with the recent PRs merged it might be easier now |
15:38:05 | * | SenasOzys joined #nim |
15:40:37 | Yardanico | AFAIK you shouldn't remove keys from a table if you're iterating over it? |
15:43:36 | Araq | yeah, you shouldn't |
15:53:53 | * | nsf joined #nim |
15:54:49 | * | Trustable joined #nim |
16:12:54 | dom96 | yglukhov: PRs welcome :) |
16:13:27 | dom96 | I think improvements to async stack traces require compiler bug fixes/macro API improvements |
16:21:49 | * | floppydh quit (Quit: WeeChat 2.1) |
16:25:21 | dom96 | This should make us feel a bit better about some of the issues we face in Nim https://news.ycombinator.com/item?id=17248095 :) |
16:27:02 | Yardanico | well, that'a a very rare case to happen |
16:27:29 | Yardanico | do you frequently use something like array[i++] += i + " "; ?:) |
16:33:48 | * | Notkea quit (Remote host closed the connection) |
16:36:21 | * | clyybber quit (Ping timeout: 264 seconds) |
16:37:17 | * | clyybber joined #nim |
16:37:18 | * | clyybber quit (Client Quit) |
16:37:44 | * | clyybber joined #nim |
16:37:45 | * | clyybber quit (Client Quit) |
16:38:06 | * | clyybber joined #nim |
16:38:30 | * | clyybber quit (Client Quit) |
16:40:07 | * | clyybber joined #nim |
16:41:01 | * | clyybber quit (Client Quit) |
16:41:33 | * | clyybber joined #nim |
16:42:16 | * | clyybber quit (Client Quit) |
16:46:56 | * | clyybber joined #nim |
16:46:57 | * | clyybber quit (Client Quit) |
16:48:13 | * | clyybber joined #nim |
16:48:13 | * | clyybber quit (Client Quit) |
16:49:12 | * | clyybber joined #nim |
16:49:13 | * | clyybber quit (Client Quit) |
16:49:52 | * | clyybber joined #nim |
16:49:52 | * | clyybber quit (Client Quit) |
16:50:55 | * | Notkea joined #nim |
16:51:10 | * | clyybber joined #nim |
16:51:16 | * | clyybber quit (Client Quit) |
16:51:57 | * | clyybber joined #nim |
16:51:57 | * | clyybber quit (Client Quit) |
16:54:05 | * | clyybber joined #nim |
16:54:05 | * | clyybber quit (Client Quit) |
16:54:20 | * | clyybber joined #nim |
16:54:20 | * | clyybber quit (Client Quit) |
16:56:55 | * | clyybber joined #nim |
16:56:55 | * | clyybber quit (Client Quit) |
16:58:23 | * | clyybber joined #nim |
16:58:24 | * | clyybber quit (Client Quit) |
17:00:30 | * | Trustable quit (Remote host closed the connection) |
17:03:07 | * | clyybber joined #nim |
17:03:07 | * | clyybber quit (Client Quit) |
17:07:46 | Yardanico | why is clyybber leaving and trying to join again? :D |
17:13:06 | * | clyybber joined #nim |
17:13:06 | * | clyybber quit (Client Quit) |
17:13:30 | * | sz0 joined #nim |
17:14:07 | * | clyybber joined #nim |
17:14:07 | * | clyybber quit (Client Quit) |
17:14:46 | * | xkapastel joined #nim |
17:16:19 | krux02 | hmm, what is the error "Error: not unused" supposed to mean? |
17:16:24 | krux02 | double negation? |
17:16:32 | krux02 | the problem is that I use a value? |
17:19:08 | * | clyybber joined #nim |
17:19:21 | * | clyybber quit (Client Quit) |
17:20:48 | * | clyybber joined #nim |
17:21:02 | * | clyybber quit (Client Quit) |
17:21:51 | * | clyybber joined #nim |
17:22:03 | * | clyybber quit (Client Quit) |
17:26:18 | * | clyybber joined #nim |
17:26:38 | * | clyybber quit (Client Quit) |
17:26:57 | * | clyybber joined #nim |
17:27:17 | * | clyybber quit (Client Quit) |
17:27:42 | * | clyybber joined #nim |
17:28:36 | * | clyybber quit (Client Quit) |
17:30:07 | * | clyybber joined #nim |
17:31:14 | * | clyybber quit (Client Quit) |
17:31:23 | * | clyybber joined #nim |
17:31:44 | * | clyybber quit (Client Quit) |
17:32:07 | * | clyybber joined #nim |
17:32:42 | * | clyybber quit (Client Quit) |
17:33:07 | * | clyybber joined #nim |
17:34:02 | * | clyybber quit (Client Quit) |
17:35:07 | * | clyybber joined #nim |
17:35:43 | * | clyybber quit (Client Quit) |
17:36:07 | * | clyybber joined #nim |
17:36:43 | * | clyybber quit (Client Quit) |
17:37:17 | * | clyybber joined #nim |
17:37:41 | * | clyybber quit (Client Quit) |
17:38:07 | * | clyybber joined #nim |
17:38:26 | * | clyybber quit (Client Quit) |
17:39:32 | * | clyybber joined #nim |
17:39:51 | * | clyybber quit (Client Quit) |
17:40:34 | * | clyybber joined #nim |
17:41:04 | * | clyybber quit (Client Quit) |
17:41:57 | * | clyybber joined #nim |
17:41:57 | * | clyybber quit (Client Quit) |
17:42:04 | * | clyybber joined #nim |
17:42:08 | * | clyybber quit (Client Quit) |
17:42:23 | * | clyybber joined #nim |
17:42:36 | * | clyybber quit (Client Quit) |
17:42:57 | * | clyybber joined #nim |
17:47:45 | * | clyybber quit (Ping timeout: 264 seconds) |
17:54:19 | * | noonien quit (Quit: Connection closed for inactivity) |
18:01:22 | * | btbytes joined #nim |
18:14:40 | krux02 | are here still a few people around? |
18:15:11 | FromGitter | <Vindaar> around right now at least |
18:16:03 | krux02 | cool |
18:16:36 | krux02 | I wonder if there is a way to create a generic type, that just looks like a normal generic, but the implementation is totally based on a macro |
18:17:58 | FromGitter | <Vindaar> when you say normal generic, what do you mean? |
18:18:49 | FromGitter | <Vindaar> or rather do you have a pseudo example? |
18:19:55 | krux02 | well I mean that a type looks to the outside world like this: MyType[int32] |
18:20:06 | ldlework | I'm guessing some macro that is parametric, that generates a type |
18:20:15 | krux02 | but internally the implementation, meaning all members of that type are generated by a macro |
18:20:31 | ldlework | krux02: my nim entity component system worked this way |
18:21:10 | krux02 | so I would like to replace the following `genMeshType(MyMesh, MyVertexType)` with `MyMesh[MyVertexType]" |
18:21:16 | ldlework | https://github.com/dustinlacewell/dadren/blob/master/examples/hatchet/main.nim#L33 |
18:21:20 | krux02 | I would like to hide that there is macro magic |
18:21:30 | ldlework | Entity, Position, Velocity and Icon are all normal user types |
18:21:39 | ldlework | aggregate is the macro, parametric on types |
18:21:52 | ldlework | and it generates a bunch of new types that use those user types in its implementation |
18:22:14 | ldlework | like a macro-based generic. but the code is crazy and was written a few years ago so probably isn't even valid Nim anymore |
18:22:58 | ldlework | magic.nim: https://github.com/dustinlacewell/dadren/blob/master/dadren/magic.nim |
18:23:28 | ldlework | I can't believe I did all that work and then just never looked at Nim again. |
18:24:08 | krux02 | well I would like to hide the "aggregate" macro, so that it is just "Entity[Position,Velocity,Icon]" |
18:24:28 | ldlework | What is Entity? |
18:24:54 | krux02 | well Entity should be a generic type, at least it should look generic |
18:25:12 | ldlework | that's what aggregate is, you're just looking at the wrong thing |
18:25:20 | ldlework | In your example, Entity is a macro no? |
18:25:21 | krux02 | but internally it is just generated by aggregate |
18:25:49 | ldlework | Aggregate[Position, Velocity, Icon], doesn't matter what it is called.. |
18:25:56 | krux02 | in my example "genMeshType" is the macro |
18:26:06 | ldlework | you have to invoke a macro |
18:26:16 | krux02 | ldlework, yes I know |
18:26:30 | krux02 | but I would like to let Nim decide where and when the macro is invoked |
18:26:42 | krux02 | a generic type is instanciated |
18:26:56 | krux02 | I would like the instanciation trigger the macro |
18:27:09 | ldlework | afaiu, for macros, you must literally (as in lexically) call them, and callsites are expanded during compile-time so they don't even exist anymore. |
18:27:34 | krux02 | well I know that |
18:27:46 | FromGitter | <Vindaar> < has way too little experience with macros for that :) |
18:28:06 | krux02 | I just want to spare the user of my library to actually call the macro |
18:28:19 | krux02 | the user should just think it is a generic type and everything works magically |
18:28:55 | krux02 | I am basically doing macros all day, so I think I am (almost) most experienced with macros |
18:29:15 | ldlework | krux02: an idea is a simple genertic type who's implementation is basically calling a macro to generate the rest of the class definition since methods and stuff in Nim arnt lexically attached to their class declarations this might work? |
18:29:36 | ldlework | But I doubt it |
18:30:21 | krux02 | so I don't know why I even ask, I know it doesn't work, but I still hope that there might be someone who tells me: "that is possible, simply put ..." |
18:30:38 | ldlework | like maybe the users uses Generic[ConcreteTypeA] and Generic[ConcreteTypeB] and when the compiler tries to generate Generic_ConcreteTypeA and Generic_ConcreteTypeB implementations, it expands the macro twice and you get two sets of methods. |
18:31:12 | ldlework | But the macro call would be inside the initializer |
18:31:35 | ldlework | and whether the macro call site can pass along the generic parameters to the macro implementation... fat chance I guess. |
18:31:59 | ldlework | Like lets say you made a generic type where the generic parameters were named A and B |
18:32:10 | ldlework | and in the initializer you called themacro(A, B) |
18:32:16 | ldlework | lol the macro will literally get A and B |
18:32:35 | ldlework | and not the concrete types that being passed as generic parameters to the generic class who's initializer is doing this |
18:34:15 | Araq | https://gist.github.com/Araq/bfcf12baa58ac2ab57641984f0b512c1 fwiw |
18:35:06 | krux02 | http://ix.io/1cvY |
18:35:13 | krux02 | basically this |
18:36:06 | ldlework | Araq: looks like your components get one functional continuation and that's it? |
18:37:22 | krux02 | my macro is invoked exactly two times that is what I want, for each type it is invoked once, but sadly I only get Sym "T" as argument, not Sym "int32" and Sym "float32". |
18:37:57 | ldlework | magic.nim will generate full classes which can have methods or whatever, and when you aggregate a component in that system, user code is able to call any method on the generated aggregates because they're fully generated types, etc |
18:38:02 | Araq | ldlework: not sure what that means, it's how I would do things |
18:38:10 | ldlework | but that is a nice little example |
18:38:23 | ldlework | Araq: looks like you pass a single "update" continuation during declareComponent |
18:38:46 | Araq | yeah you could it extend it to more update-like things |
18:38:50 | ldlework | So you create an entity with those components, and something else just calls the registered update continuation |
18:39:02 | Araq | but I don't know how useful that would be |
18:40:07 | ldlework | Yeah, imagine that Physics and Position components were just rich types of any complexity. And you hand wrote an Entity class that hadd Physics and Position as fields. And you had an instance of Entity. you could just do e.physics.literally_anything_this_class_declares |
18:40:27 | ldlework | Because everything ends up being a full type, as if you hand wrote the full non-generated implementation yourself |
18:40:36 | Araq | I don't imagine "any complexity", I avoid it. :-) |
18:40:54 | ldlework | I like general solutions. |
18:41:24 | FromGitter | <Vindaar> @krux02 in your ix.io paste up there. If you want "int32" or "float32" can't you just use getTypeInst[1] to get it? |
18:41:24 | Araq | I like simple solutions. |
18:41:44 | ldlework | Among the general solutions, I'll take the simplest, sure. |
18:41:50 | Araq | anyhow, Nim never got the BTree in its stdlib and this where my musings ended |
18:42:12 | Araq | interestingly, compiler/btrees is finally a thing in my branch... |
18:42:59 | Araq | ldlework: more complex than that has to be derived from concrete gaming code |
18:43:06 | Araq | and its problems. |
18:43:16 | Araq | IMHO anyway. |
18:43:48 | krux02 | Vindaar: I just figured that out |
18:43:59 | FromGitter | <Vindaar> :) |
18:44:02 | Araq | for example, it's also nice to be pointer-free than you can just write the bytes to disk |
18:44:22 | ldlework | Besides aggregation itself, my entity component system hid the aggregation implemention from the user entirely. |
18:44:37 | ldlework | So the complexity from the standpoint of game code was as simple or complex as your game code would be if you were not using my macro |
18:44:47 | ldlework | Because the result is natural types with a natural API |
18:45:05 | ldlework | Or whatever API your components have |
18:45:18 | ldlework | magic.nim doesn't place any constratints onthe types you aggregate. |
18:45:26 | ldlework | Write simple components with a single update, and get that |
18:45:41 | ldlework | Write components which have multiple methods and whatever and get that |
18:46:12 | ldlework | but magic.nim itself was complex as hell to be sure |
18:47:50 | krux02 | hmm I get invalid expression object ... |
18:48:26 | FromGitter | <Vindaar> @krux02 what's the result of that code supposed to be? |
18:48:29 | krux02 | http://ix.io/1cw3 |
18:49:16 | krux02 | Vindaar: for the moment I just want to generate the generic proc entirely with a macro |
18:51:20 | FromGitter | <Vindaar> so in that second paste the type you defined under dumpTree? |
18:51:24 | FromGitter | <Vindaar> or something like it? |
18:51:48 | krux02 | yes that thing under dump tree is the true final goal |
18:51:58 | FromGitter | <Vindaar> I see |
18:52:02 | krux02 | that should be generated from MyMesh[MyVertexType] |
18:54:44 | krux02 | Vindaar: and MyVertexType is tuple[position_os, normal_os: Vecf; texCoord: Vec2f] |
18:55:03 | krux02 | Araq: you have any idea how that might work? |
18:56:08 | * | nsf quit (Quit: WeeChat 2.1) |
18:58:05 | * | Electrux quit (Ping timeout: 240 seconds) |
19:02:02 | FromGitter | <Vindaar> So the issue is that your macro is expanded at `MyType[int32]`, which ends up putting `object...` right at that place. And `var t1: object...` doesn't make sense. Or something like that? |
19:04:20 | krux02 | well not really |
19:04:52 | krux02 | getType is acually called two times |
19:05:12 | krux02 | but I use three times the MyType[..] expression |
19:05:21 | krux02 | for each new type genType is called |
19:05:26 | krux02 | exactly what I want |
19:05:54 | krux02 | the problem is, as soon as I do anything different than trivially doing nothing, it fails |
19:06:01 | krux02 | I can't even emit a tuple type |
19:07:02 | FromGitter | <Vindaar> Hmm :/ |
19:07:40 | krux02 | http://ix.io/1cwd |
19:08:35 | FromGitter | <Vindaar> yeah, that works and just creates an int32, float32 and another float32 |
19:08:47 | krux02 | no it just creates one float32 |
19:08:51 | krux02 | look at the output |
19:08:55 | krux02 | there is only one float32 |
19:09:52 | * | Electrux joined #nim |
19:10:50 | FromGitter | <Vindaar> well, the type is only supposed to be created once, right? |
19:11:17 | krux02 | yes, and that is the case |
19:11:36 | krux02 | the problem is that when I actually create anything but a simple symbol, it fails |
19:11:38 | FromGitter | <Vindaar> yes, what I meant was it creates a variable of type int32, float32 and another float32 |
19:11:46 | FromGitter | <Vindaar> ah, yes |
19:13:57 | * | Electrux quit (Ping timeout: 240 seconds) |
19:19:52 | * | Electrux joined #nim |
19:24:18 | * | Electrux quit (Ping timeout: 255 seconds) |
19:29:52 | * | Electrux joined #nim |
19:34:32 | * | Electrux quit (Ping timeout: 276 seconds) |
19:40:10 | krux02 | Vindaar: I created a github issue |
19:40:34 | krux02 | I think it is just a matter of enabling something in the compiler nothing more, the infrastructure to do this is already there |
19:41:26 | * | clyybber joined #nim |
19:44:03 | FromGitter | <Vindaar> Ok, I see :) |
19:45:23 | FromGitter | <data-man> When discussing creating types, I always remember https://github.com/def-/nim-units (just the link. Can be useful for someone.) |
19:47:17 | * | miran joined #nim |
19:48:12 | * | jjido joined #nim |
19:50:52 | * | Electrux joined #nim |
19:54:49 | * | krux02 quit (Quit: Leaving) |
19:55:41 | * | Electrux quit (Ping timeout: 265 seconds) |
20:00:41 | FromGitter | <Vindaar> @krux02 reading again what you wrote: what do you gain by replacing the call to `genMeshType` with `MyMesh[T] = genMesh(T)`? The user still sees the macro calls, no? |
20:00:52 | * | Electrux joined #nim |
20:01:52 | FromGitter | <Vindaar> Do you have a link to your `genMeshType` macro? |
20:05:13 | * | Electrux quit (Ping timeout: 256 seconds) |
20:07:33 | * | clyybber quit (Ping timeout: 264 seconds) |
20:09:57 | * | jjido quit (Ping timeout: 264 seconds) |
20:21:20 | * | Vladar quit (Quit: Leaving) |
20:29:47 | * | Electrux joined #nim |
20:31:53 | * | elrood joined #nim |
20:34:21 | * | Electrux quit (Ping timeout: 265 seconds) |
20:36:34 | * | krux02 joined #nim |
20:39:51 | * | Electrux joined #nim |
20:44:30 | * | Electrux quit (Ping timeout: 265 seconds) |
20:56:27 | * | miran quit (Ping timeout: 245 seconds) |
20:59:52 | * | Electrux joined #nim |
21:04:19 | * | Electrux quit (Ping timeout: 265 seconds) |
21:16:48 | * | btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
22:24:58 | * | elrood quit (Quit: Leaving) |
22:56:55 | * | gangstacat quit (Ping timeout: 245 seconds) |
23:12:33 | * | riidom quit (Ping timeout: 248 seconds) |
23:40:15 | * | sz0 quit (Quit: Connection closed for inactivity) |