00:01:21 | disruptek | bump 1.7.0 sniffs your tags to see if you use `v` and adds it for you if necessary. |
00:02:09 | disruptek | if it isn't sure, it gives you a chance to interrupt before assuming a sane, no-vee, usage. |
00:06:22 | FromGitter | <Willyboar> shashlick thanks i will check it because it is a custom proc |
00:15:33 | shashlick | how'd you get from 1.3.4 to 1.7.0 |
00:27:38 | FromDiscord | <Rika> That's some intense minor version bumping |
00:29:18 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
00:30:28 | shashlick | amazing - i compiled an old nim tool I wrote 2 years ago with spawn & async with latest nim and it just works |
00:34:09 | * | luis_ quit (Quit: luis_) |
00:34:31 | * | luis_ joined #nim |
00:48:25 | disruptek | i had to write another tool just to up the bump speed of bump. |
00:49:05 | disruptek | the way this works is, when you add functionality, you bump the minor. |
00:49:50 | disruptek | 1.6.0 lets you commit at the same time you bump, in case it's just a minor change and you don't need multiple commits. |
00:50:28 | disruptek | 1.5.0 moved some params around. it shoulda been 2.0, honestly. |
00:50:52 | disruptek | 1.4.0 adds the --v that lets you force a `v` prefix on your tags, if you're a lunatic like shashlick. |
00:51:51 | disruptek | now let's talk about STEVE GULLY. i only got two contributions to his re-election campaign. what's with you people? |
00:52:03 | disruptek | don't you want to see NIM IN CONGRESS? |
00:52:15 | * | krux02_ quit (Remote host closed the connection) |
00:54:00 | * | seni quit (Quit: Leaving) |
00:57:11 | shashlick | i'd have added all that and made a 1.4.0 |
00:58:45 | * | NimBot joined #nim |
00:59:16 | disruptek | don't lie, you have many people using nimterop and you won't even cut a 1.0.0. |
01:06:24 | * | hpyc9 quit (Quit: ZNC 1.7.3 - https://znc.in) |
01:06:25 | * | blackbeard420 quit (Quit: ZNC 1.7.3 - https://znc.in) |
01:28:00 | * | blackbeard420 joined #nim |
01:28:36 | * | hpyc9 joined #nim |
01:59:13 | * | theelous3_ joined #nim |
02:00:31 | * | theelous3 quit (Ping timeout: 250 seconds) |
02:24:03 | shashlick | 😄 |
02:26:19 | disruptek | dude. |
02:26:33 | disruptek | there's nothing juvenile about nimterop. 😉 |
02:34:14 | * | luis_ quit (Quit: luis_) |
03:07:51 | * | dddddd quit (Remote host closed the connection) |
03:13:59 | FromDiscord | <Chiqqum_Ngbata> npm has that version bump feature btw https://docs.npmjs.com/cli/version.html |
03:14:24 | FromDiscord | <Chiqqum_Ngbata> Wonder if there's any other conveniences they've found https://docs.npmjs.com/cli-documentation/cli |
03:14:58 | disruptek | looks like nah. |
03:16:00 | disruptek | doctor is something that most tools should have. |
03:19:23 | * | chemist69 quit (Ping timeout: 276 seconds) |
03:20:48 | * | chemist69 joined #nim |
03:28:59 | shashlick | @disruptek what's a good reason to release small individual features quickly? I know it is a nimble update away unlike larger pieces of software but still don't get it. |
03:29:28 | disruptek | the same reason you separate features out into different commits. |
03:30:01 | leorize | lol I managed to break the forum's RST renderer |
03:30:27 | shashlick | Ya but that's no reason to tag it as a release |
03:30:45 | disruptek | why not? |
03:30:53 | shashlick | Unless you don't plan any other updates |
03:31:07 | shashlick | I understand patches to fix stuff |
03:31:42 | shashlick | But why release 10 features when they can be clustered into one release |
03:31:56 | disruptek | because of a little thing called "change control". |
03:32:28 | disruptek | i wanna be able to roll to the point at which a feature doesn't exist, exists, and is merely the /last/ feature added. |
03:32:35 | disruptek | that lets me isolate problems. |
03:32:51 | disruptek | without that, you're just guessing. |
03:32:59 | disruptek | guessing costs money. |
03:33:20 | disruptek | tagging is free, now that bump exists. 🤣 |
03:33:36 | shashlick | That's what commits give me as the developer |
03:33:42 | shashlick | But why would a user care |
03:34:09 | disruptek | because users don't `git bisect`. they wanna say, "it worked fine before 1.6.0" |
03:34:46 | disruptek | i expect that users only use releases. it's not always true, but it gives us common truth to talk about. |
03:35:20 | shashlick | But if you release that often, all you'll get is it worked in 1.6.0 but doesn't in 1.20.0 |
03:35:28 | shashlick | They aren't going to try every release |
03:35:40 | disruptek | that's fine. |
03:35:40 | shashlick | Which is the same as commits |
03:35:53 | disruptek | well, it's not. clearly. |
03:36:25 | disruptek | for one thing, i can more easily mate my software to yours if you give me lotsa releases to test against. |
03:38:07 | disruptek | if you need another reason, it isolates testing to points at which the software is not terribly broken. ie. it doesn't have partially-implemented features. |
03:38:39 | shashlick | Well in nimterop case, features take time to get right |
03:38:40 | disruptek | it gives me an easier way to identify commits at which i may want to initiate a new branch. |
03:38:55 | shashlick | So I have to work in a branch |
03:39:02 | shashlick | Cause it takes time |
03:39:15 | disruptek | and i can more easily compare to points in time or feature additions and removals without having to look up git hashes. |
03:40:01 | disruptek | tell me how you want it to work. it's fine to tell me it's useless to you, too. |
03:40:59 | shashlick | Well the way I work, I only push to head when it is fully tested and works |
03:41:19 | shashlick | I isolate instability from users |
03:41:39 | disruptek | what about bug fixes? |
03:41:50 | shashlick | So for me the releases reflect my level of confidence |
03:42:34 | disruptek | i mean, we don't disagree here, right? |
03:42:38 | shashlick | Bug fixes as well depends how big it ends up |
03:42:51 | shashlick | Cause I have a large test matrix and it takes time |
03:43:01 | disruptek | i'm willing to play pretty fast and loose with bump. there's almost no one using it, as far as i know. |
03:43:08 | shashlick | Win lin osx x 0.19.6 - devel |
03:43:22 | disruptek | you have >100 people starring nimterop and i know it's used pretty heavily. |
03:43:27 | shashlick | I understand but I'm trying to see if there's something I can learn here |
03:44:14 | disruptek | if it were me, i would branch nimterop for almost anything, whatfer test matrix reasons. |
03:45:26 | disruptek | i'd cut a new patch release when the matrix says the bug is fixed. |
03:45:53 | disruptek | and then i'd pull that into my longer-term new development branches where i build stuff that takes time. |
03:48:36 | disruptek | nim is pretty lazy about squashing merges, but that's one way to reduce gratuitous commits if it bugs you. i personally find it more useful to have the extra detail. |
03:49:28 | shashlick | I think that's pretty much what I'm doing |
03:49:38 | shashlick | It took 3 months to get getHeader done |
03:49:50 | disruptek | back when i used to work for other people, i'd have paid $2k/year to use nimterop without batting an eye. i think it's nuts to call it 0.3.0. there's way too much product there. |
03:52:14 | shashlick | Thanks I appreciate that |
03:52:51 | shashlick | I do think I need to make smaller changes though |
03:52:58 | disruptek | i agree. |
03:53:18 | disruptek | i think it will make feedback much more meaningful. |
03:54:12 | shashlick | Larger diffs are intimidating, even my own :P |
03:55:07 | disruptek | of course. i don't remember the order of stuff, either. i have so very many components to my startup software. it's kinda nuts. |
03:55:30 | disruptek | looking at a tags page makes that much more tolerable. |
03:56:01 | disruptek | it will save golden a collosal amount of time in its bisection, too. |
04:03:00 | shashlick | So do you squash often? |
04:03:48 | disruptek | the only time i squash is if i write 1k loc and then throw it out or go a very different way and i simply don't want to confuse myself later. but it's pretty rare. |
04:04:30 | disruptek | i don't feel the hard part of coding is putting text on the screen, and by the same token, i don't have any problem deleting stuff. |
04:06:35 | disruptek | looking at bump, i've added 779 lines and remove 249. it's 368 lines long. for what really should be an awk script. 🤪 |
04:10:55 | * | rockcavera quit (Remote host closed the connection) |
04:35:31 | * | leorize quit (Remote host closed the connection) |
04:36:07 | * | leorize joined #nim |
04:49:56 | * | nsf joined #nim |
05:03:46 | * | narimiran joined #nim |
05:28:45 | * | mipri joined #nim |
05:54:31 | * | clyybber joined #nim |
05:57:09 | FromGitter | <mratsim> @Araq agree on stamp-it, looks very interesting, I should have more time to play with Picasso now. Once the scheduler is done, some lock-free data structure would be nice |
06:05:29 | FromGitter | <mratsim> Especially the guard/concurrent ptr interface they propose to abstract memory réclamation scheme |
06:13:23 | * | mipri left #nim (#nim) |
06:14:59 | * | solitudesf joined #nim |
06:20:31 | * | PMunch joined #nim |
06:26:58 | * | solitudesf quit (Remote host closed the connection) |
06:27:36 | * | solitudesf joined #nim |
06:28:58 | FromDiscord | <arnetheduck> shashlick, did you ever figure out a way to create wrappers that don't depend on nimterop (ie inlining all necesserary code in the wrapper itself)? |
06:30:56 | leorize | you can generate the wrapper from nimterop |
06:32:06 | leorize | the idea of nimterop is that you can seamlessly use a C header |
06:39:16 | FromDiscord | <arnetheduck> leorize, the feature I'm after is to create a standalone wrapper that works without requiring the user of the wrapper to have nimterop and its dependencies installed - this is generally a safer option as it protects the wrapper from being broken by upgrades to nimterop - it also simplifies the dependency graph and the build (see https://github.com/arnetheduck/nim-sqlite3-abi/blob/master/update.sh) |
06:49:31 | leorize | bundle your own copy of nimterop/types and you're done |
06:50:20 | leorize | or you can use nimgen, which works pretty well also |
06:55:01 | * | theelous3_ quit (Ping timeout: 268 seconds) |
06:55:40 | clyybber | This is the one feature that would get me to use nimterop. |
06:56:11 | clyybber | So far c2nim + scriptfoo is enough for me. |
06:56:22 | clyybber | But with wrapping alsa it gets a bit hardcore |
06:56:25 | clyybber | bbl |
06:56:26 | * | clyybber quit (Quit: WeeChat 2.6) |
07:00:00 | * | gmpreussner_ quit (Quit: kthxbye) |
07:05:02 | * | gmpreussner joined #nim |
07:08:18 | * | krux02 joined #nim |
07:09:26 | FromDiscord | <Chiqqum_Ngbata> Same |
07:12:48 | FromDiscord | <arnetheduck> leorize, I know I can bundle nimterop, but that's more complicated than having the feature in nimterop itself - the wrapper becomes more difficult to use and build. I'm already using `c2nim` and some manual hacking which is fine, but I generally would prefer nimterop if it was dep-free. since creating the wrapper happens once while it's used many times over, it seems better to optimize wrappers for ease of use (for this same reason, it' |
07:20:16 | leorize | the biggest problem is that nimterop-generated wrapper is machine-dependant |
07:20:46 | leorize | since it runs the preprocessor of that machine on the header |
07:21:43 | leorize | so if a header is used for both *nix and windows, a wrapper generated by nimterop will only work on the os/architecture it was generated from |
07:23:02 | leorize | whenever #ifdefs are involved, c2nim is always the better option |
07:24:16 | leorize | (for generic wrapper) |
07:26:13 | * | SyrupThinker joined #nim |
07:26:37 | * | floppydh joined #nim |
07:27:39 | FromDiscord | <arnetheduck> that |
07:27:43 | FromDiscord | <arnetheduck> that's a good point |
07:28:18 | FromDiscord | <arnetheduck> the preprocessor stuff is optional afair - but the comment stands regardless |
07:29:26 | FromDiscord | <arnetheduck> I guess that's a good argument for running nimterop at compile time (or make nimterop translate the machine-dependent stuff more accurately) |
07:33:03 | leorize | iirc, nimterop was built on the idea of seamless C interop like in Zig (ie. you can just cImport()) and you get all the functions |
07:33:13 | leorize | which is probably why it was made this way |
07:33:41 | leorize | the model doesn't map really well to Nim though :P |
07:36:23 | * | couven92 joined #nim |
07:49:11 | Araq | I've complained about this model before too fwiw |
07:49:26 | Araq | it's incredibly fragile by construction |
07:49:59 | Araq | plus I don't want cImport "bullshit.h", I know enough about C not to want that |
07:50:30 | Araq | if I want it, I know where to find .emit: "#include ..." |
08:00:08 | FromDiscord | <kodkuce> that article form 2017 read faster 😛 |
08:02:54 | * | gmpreussner quit (Ping timeout: 265 seconds) |
08:03:27 | * | gmpreussner joined #nim |
08:12:12 | FromDiscord | <arnetheduck> btw, krux02 removed several float magics which is a bit unfortunate because they were hooked to llvm/CPU intrinsics - now codegen is worse for those cases (ie float to int converstion and a few others) - Araq, is there an easy way to match a function signature in the compiler ast? ie I want to match `X(a, b: SomeType)` by function+module name and arguent types so I can pick out what used to be magic.. going just by name is fragile |
08:14:45 | Araq | there is no good way. for min/max checking something like x.typ.skipTypes(abstractInst).kind in {tyInt..tyInt64} works but you know this |
08:15:18 | Araq | we could really have some pattern matching helpers in the compiler |
08:16:12 | krux02 | @arnetheduck: you mean the procs `toFloat` and `toInt`? |
08:16:39 | Araq | however, toFloat/toInt never were widely used, better detect it for nkConv or whatever it's called internally |
08:16:57 | krux02 | I think those magits don't really help you to begin with, since most type conversations are written with conversation call `float(x)` ant `int(y)`. |
08:17:16 | krux02 | they are nkConv nodes in the ast if that helps |
08:28:01 | FromDiscord | <arnetheduck> yeah, there was a bunch of them, `mToFloat`, `mMinF64`, `mAbsF64` etc - a lot of these exist as `c` math functions in `math.h` with well-established meanings and `llvm` has intrinsics for them |
08:30:01 | FromDiscord | <arnetheduck> for nkconv I'm already using these intrinsics - but I saw for example that `min`/`max` was rewritten as pure nim which will be slower unless by chance the compiler pattern-matches the generated code |
08:31:03 | FromDiscord | <arnetheduck> Araq, yeah, I'm using that kind of matching but it quickly gets hairy |
08:32:31 | FromGitter | <mratsim> min and max are especially an issue |
08:33:26 | FromGitter | <mratsim> 7x perf gap by generating naive code VS intrinsics: https://github.com/nim-lang/Nim/issues/9514 |
08:33:29 | FromDiscord | <arnetheduck> on that topic, the new usage of `int128` is pretty unwieldy - in general there exist ways to do the correct arithmetic, overflow checking etc without that kludge - and no less error prone (as the `mod` bug showed, you still need to think about what you do) |
08:34:50 | Araq | ok, but in the worst case it allows us to add native int128 support, that can't be a bad thing |
08:35:15 | FromDiscord | <arnetheduck> on the topic of inlining, we've seen that due to how nim generates very verbose code coupled with gcc's heurestic for inlining which apparently is based on number of `;`, inlining often does not happen in practise |
08:35:45 | FromDiscord | <arnetheduck> well, will you add an `int256` to implement it? |
08:36:29 | FromDiscord | <arnetheduck> fwiw, we have all that stuff in `stint` - ideally for nlvm would be if all ints were generic on the bit size - I believe you have that planned somewhere? |
08:36:54 | FromDiscord | <arnetheduck> that would require a full bignim lib in the compiler however |
08:37:41 | FromGitter | <mratsim> Are you asking me or Araq? |
08:37:46 | Araq | yeah, it's planned, however |
08:38:51 | Araq | it's as you say, maybe we should use a bigint implementation |
08:39:19 | Araq | and then we need to be careful that the vm emulates the cpu |
08:42:52 | FromDiscord | <arnetheduck> is Nim (regularly) tested on any bigendian platform btw? saw that `int128` will be laid out as mixed-endian in that case which is fun |
08:45:43 | Araq | no, it isn't. work on that started via testing on the BSDs, I think |
08:49:00 | * | mipri joined #nim |
08:54:13 | * | Vladar joined #nim |
08:57:53 | mipri | how serious is the Z3 stuff in the roadmap? do you have a syntax in mind for associating static constraints with variables? |
08:58:14 | krux02 | arnetheduck: well, I removed those magics to simplify the code and CI didn't complain about that. |
08:59:05 | * | ng0 joined #nim |
08:59:15 | * | alexander92 joined #nim |
09:00:05 | mipri | a good hello-world example would be for C argc/argv handling, where a function takes an int that's the length of the other parameter, and you can only look at argv[i] when that's definitely OK (like in the branch of an if that tests i against argc) |
09:00:49 | Araq | mipri, I'm serious about it, but have no clues about the required syntax |
09:01:10 | Araq | I see it as un-important, it needs to be "skippable" Nim code |
09:01:32 | Araq | the Nim compiler ignores it, the NimProof tool looks at it |
09:02:05 | FromGitter | <alehander42> i am interested |
09:02:14 | FromGitter | <alehander42> in some examples how |
09:02:17 | FromGitter | <alehander42> z3 would be used |
09:02:26 | FromGitter | <alehander42> e.g. cool things that would be provable |
09:02:34 | mipri | makes sense. That gives you the extra work only when you want it. |
09:02:57 | mipri | or when the users of a library want it. |
09:03:52 | Araq | and indeed, I will start with proving array indexes correct |
09:04:09 | Araq | it's a nice real world example that I happen to understand well |
09:04:24 | mipri | I think that's the direction ATS has moved as well. Even though you can technically compile ATS without the checks, Hongwei wants something more approachable to be the default. (and I mention ATS because its syntax is also very scary over all :) tho the basic refinement-type stuff isn't too bad) |
09:05:05 | mipri | cool, I'll look forward to that |
09:05:06 | FromGitter | <alehander42> and how would be called: with a --z3 switch ? |
09:05:26 | FromGitter | <alehander42> is there a language that uses it like that |
09:05:30 | mipri | or 'nim prof' analogously to 'nim ch eck' |
09:06:29 | mipri | ATS can use Z3, but uses a less powerful constraint solver by default, and it does the argc/argv thing I described above. deech comes around here some times, and has a video about it: https://www.youtube.com/watch?v=zt0OQb1DBko |
09:06:35 | Araq | most likely it will be a separate executable because of the dependency |
09:07:44 | Araq | mipri, we have our own thing too, see https://github.com/nim-lang/Nim/pull/10965 |
09:08:32 | Araq | but it's limited and Z3 is a trusted piece of technology |
09:08:53 | Araq | sometimes NIH is wrong even for Nim. |
09:15:28 | FromDiscord | <mratsim> LLVM uses ISL and polyhedral representation for array bound checking |
09:16:36 | Araq | when does it do that? is it enabled by default? |
09:27:36 | FromDiscord | <mratsim> when you use LLVM Polly |
09:28:57 | FromDiscord | <mratsim> they use ISL (wrapper here: https://github.com/mratsim/nim-isl) to analyze read after write, write after read, write after write, read after read and bounds validity |
09:29:42 | FromDiscord | <mratsim> it needs affine constraint though, it would work with for loops but I don't think it would work for while loop for example |
09:30:17 | Araq | afaik it also doesn't support separation logic and Z3 has some support for it |
09:30:20 | FromDiscord | <mratsim> or quasi affine (modulo constraint / skipping every 2 iteration) is fine |
09:30:53 | FromDiscord | <mratsim> if you want to play with it, there is a playground here: http://playground.pollylabs.org/ |
09:31:05 | FromDiscord | <mratsim> switch the examples to dependence analysis |
09:31:38 | FromDiscord | <mratsim> ah no sorry memory access |
09:33:32 | FromDiscord | <mratsim> I tried to port it to Nim but it's too messy, too much memory management in-between functions |
09:35:31 | Araq | sorry but I'm busy with other things and Z3 is a wise choice, we need separation logic for free/dispose |
09:35:44 | FromDiscord | <mratsim> no worries |
09:35:50 | FromDiscord | <mratsim> I also gave up on that because no time |
09:37:08 | alexander92 | however |
09:37:22 | alexander92 | do we use annotations etc, e.g. how can i pass the constraint info to my functions |
09:38:22 | Araq | {.precondition, postcondition.} pragmas would be in the proc header |
09:38:35 | Araq | not inside the proc body |
09:38:41 | Araq | if that's what you mean |
09:42:37 | FromGitter | <alehander42> yeah |
09:42:40 | FromGitter | <alehander42> but what i mean is e.g. |
09:43:14 | FromGitter | <alehander42> it would infer local expressions constraints |
09:43:15 | FromGitter | <alehander42> as well, right |
09:43:48 | FromGitter | <alehander42> but i guess i wouldn't be able to somehow use generic conditions or overload based on conditions |
09:44:55 | Araq | no overloading on conditions in my Nim |
09:45:39 | Araq | it's a bad idea IMO. if you want to specialize, a 'when' inside your proc is cleaner |
09:45:43 | FromGitter | <alehander42> well, one can always add it as a "macro" |
09:45:45 | FromGitter | <alehander42> maybe |
09:45:56 | FromGitter | <alehander42> in some limited sense |
09:46:03 | FromGitter | <alehander42> yeah, not very important |
09:46:07 | * | lritter joined #nim |
09:46:11 | FromGitter | <alehander42> just trying to imagine how it fits with the other stuff |
09:46:20 | FromGitter | <alehander42> and more like, can types "carry" conditions |
09:46:42 | FromGitter | <alehander42> e.g. i encode in my type that its name should be >2 etc |
09:47:24 | FromGitter | <alehander42> one way it can work is by just annotating all functions that take that type with the same condition i guess |
09:48:55 | mipri | that's how other languages do it, but I've wondered why type-based defaults weren't used. Probably there's a conflict of purpsoe there: you want the defaults for tersity, but you want the checks in the first place for correctness. |
09:49:14 | * | dddddd joined #nim |
09:49:52 | Araq | yup, conflicting goals here. |
09:50:26 | FromDiscord | <mratsim> I think I missed the pre/post condition boat. Is that a compile-time thing (similar to concept?) or a runtime thing (similar to design by contract / Eiffel)? |
09:51:10 | Araq | compile-time thing. it's about proving things correct |
09:51:43 | Araq | it's not about more sugar for 'assert'. Eiffel is pretty foolish in this regard IMHO. |
09:52:36 | FromDiscord | <mratsim> seems like Ada spark would love to have this |
09:53:21 | Araq | I think they are working on this |
09:54:28 | Araq | I stole Ada Spark's business plan, put my name on it and sold it as "Nim's roadmap" :P |
09:54:35 | Araq | (just kidding) |
09:54:49 | mipri | my impression with SPARK is that it has runtime checks but tries to prove that it doesn't need them a lot of the time, as an optimization. But that's a very different experience. Instead of an error, you get a runtime check and silently slower code that then might surprise you with a runtime failure. |
09:56:06 | Araq | that's Ada, not Spark, Spark proves stuff correct |
09:56:29 | mipri | ah, OK. I've only used pre/post conditions in Ada. |
09:59:00 | FromDiscord | <mratsim> I really think you should steal that slide: https://image.slidesharecdn.com/osis18iotadaandspark-defenseindepthforsafemicro-controllerprogramming-180529131452/95/osis18iot-ada-and-spark-defense-in-depth-for-safe-microcontroller-programming-by-fabien-chouteau-yannick-moy-adacore-6-638.jpg?cb=1527599798 |
10:01:05 | FromDiscord | <mratsim> i.e. this: https://forum.nim-lang.org/t/4704#29405 |
10:02:36 | Araq | we are all good at loving the non-existing |
10:04:02 | Araq | I talked about "big idea, new tool for Nim", you beat me with "bigger idea, let's have The Nim Pyramid" |
10:15:34 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
10:16:33 | * | enthus1ast joined #nim |
10:16:37 | * | dv^_^ quit (Ping timeout: 240 seconds) |
10:17:44 | enthus1ast | is it supported to load generic functions from dll? like this: proc foo*[T](known: Known, boundObj: T) {.cdecl, exportc, dynlib.} = |
10:18:17 | * | FromGitter quit (Remote host closed the connection) |
10:18:36 | * | FromGitter joined #nim |
10:18:38 | * | dv^_^ joined #nim |
10:18:38 | Araq | certainly not |
10:19:55 | enthus1ast | mhh what i thought, the T is not known when compiled |
10:56:21 | FromDiscord | <mratsim> History has proven that pyriamid schemes can capture and captivate the public and TV audiences |
10:57:21 | Araq | pyramids have usually been used to bury someone |
10:58:03 | * | alexander92 quit (Ping timeout: 240 seconds) |
11:00:22 | Zevv | talking about overengineering - a hole in the ground would do just as fine |
11:00:39 | Araq | lol |
11:01:55 | * | alexander92 joined #nim |
11:02:14 | Zevv | Hmm, I guess nim stdlib would not appreciate a PR for forth-like rot[seq[T]]() and swap[seq[T]]() ? |
11:05:48 | Araq | ah that's was what I wanted to do today |
11:08:17 | Araq | write my stdlib RFC |
11:08:32 | Araq | swap and rot for seqs? add to sequtils? |
11:08:33 | Zevv | I *just* wanted to ask "what" |
11:08:38 | Zevv | yeah and dup and over and drop :) |
11:08:49 | Zevv | nah, I'll make a forth nimble, nevermind |
11:09:00 | Zevv | I guess it will not fit your stdlib RFC |
11:09:12 | Araq | it's an open question :-) |
11:09:23 | Araq | but please name more_sequtils, not forth |
11:09:46 | Araq | or something that people can understand, I wasn't aware "forth" is about operations on Nim's seqs :P |
11:10:56 | Zevv | sure :) |
11:15:58 | * | LargeEpsilon joined #nim |
11:24:30 | shashlick | @arnetheduck - I am tracking https://github.com/nimterop/nimterop/issues/12 5 and have some ideas for it but it hasn't been a priority |
11:24:56 | shashlick | Sorry https://github.com/nimterop/nimterop/issues/125 |
11:26:02 | shashlick | @leorize is right about the preprocessor, I delegate to tools where I can - tree-sitter for parsing as well |
11:26:41 | shashlick | I've debated with @Araq before about it but I'm still not convinced that this approach has any detriment |
11:28:13 | shashlick | I see no value in retaining and checking in wrapped content since nimterop can pin to upstream versions |
11:29:28 | shashlick | I understand if there is a concern of breaking changes in nimterop, but I have a huge test matrix for it |
11:31:19 | shashlick | I do see value in options though so you can still use toast standalone, turn off the preprocessor, use c2nim within nimterop and I'll get around to #125 as well |
11:35:15 | shashlick | If there are particular important wrappers that folks want tested with nimterop updates, I'll be happy to include them |
11:36:22 | shashlick | Right now I have nimarchive and nimgit2 which I test before releases, apart from a few within nimterop test itself |
11:36:43 | * | nc-x joined #nim |
11:37:51 | * | nc-x left #nim (#nim) |
11:43:26 | Araq | shashlick, I know we disagree on it. |
11:44:10 | Araq | it's still a bit sad that nobody took clang's parser and replaced c2nim's parser with it |
11:50:59 | narimiran | ** Nim 1.0.2 is out ** |
11:53:54 | shashlick | dpp uses clang but I think clang is too large to expect users to install when they have gcc already |
11:54:30 | shashlick | If Nim moved to clang full time and it was always present it would be different |
11:54:42 | shashlick | But again that's not the c2nim approach admittedly |
12:06:06 | * | Kaivo quit (Ping timeout: 252 seconds) |
12:10:20 | * | rockcavera joined #nim |
12:10:56 | PMunch | narimiran, when will the changelog article be up? |
12:11:25 | narimiran | when i write the changelog. soon (TM) |
12:11:33 | PMunch | Haha, okay |
12:11:50 | narimiran | but it (probably) won't be a separate article, but you'll have a link to changelog |
12:15:11 | leorize | you can't call it a release without a proper changelog :p |
12:15:37 | narimiran | leorize: i can. i just did :P |
12:18:00 | * | Kaivo joined #nim |
12:18:06 | FromDiscord | <mratsim> it's not a releasebut a putsch then |
12:18:35 | leorize | Zevv: how did you test the json parser? |
12:18:56 | Zevv | who what where |
12:19:09 | leorize | for performance testing against npeg? |
12:19:22 | Zevv | parsejson, next() until you hit the end |
12:21:03 | Zevv | https://github.com/zevv/npeg/blob/master/tests/performance.nim#L95 |
12:23:15 | leorize | I noticed that you imported packedjson and never tested it :p |
12:23:24 | * | Hideki_ joined #nim |
12:23:37 | Zevv | nah I had a local version once that stripped the actual object creation - but in the end that's just parsejson |
12:24:39 | leorize | you mean packedjson doesn't cause much overhead from building the tree? |
12:25:12 | Zevv | packedjson does not build a tree like the normal json iirc |
12:25:20 | Zevv | it fakes until you go look inside, something like that |
12:25:26 | Zevv | I think |
12:25:59 | * | NimBot joined #nim |
12:27:50 | leorize | is memfiles broken on linux? |
12:27:54 | Zevv | no? |
12:28:11 | leorize | using a memfile stream with parsejson got me syntax error |
12:28:19 | leorize | but none when I switch to the normal stream |
12:28:46 | Zevv | maybe memfile *streams* are broken, but I use memfiles regularly without issues |
12:31:05 | dom96 | narimiran why wouldn't you write an article? :/ |
12:32:24 | Araq | it was a joke gone bad |
12:32:36 | Araq | I told him "yeah, this github diff is good enough" |
12:32:59 | shashlick | @Zevv is npeg faster than regex? And faster than stdlib peg? |
12:32:59 | Araq | and he didn't notice I was kidding |
12:34:06 | Zevv | shashlick: good questions. I need more test cases. |
12:34:54 | Zevv | shashlick: I only compared to parsejson and lqdev's top down Rod parser |
12:38:28 | narimiran | here y'all go, hand-picked, organic v1.0.2 changelog: https://github.com/nim-lang/Nim/blob/devel/changelogs/changelog_1_0_2.md |
12:40:13 | shashlick | Awesome work! |
12:40:19 | * | javasox joined #nim |
12:43:48 | narimiran | and yours too, shashlick! |
12:44:14 | narimiran | (btw, my travis problem seems to be magically solved today) |
12:45:12 | FromDiscord | <Rika> is it impossible to reference a higher directory when importing? |
12:45:34 | FromDiscord | <mratsim> ../ |
12:48:24 | * | theelous3 joined #nim |
12:48:35 | FromDiscord | <Rika> let me try it again |
12:49:08 | narimiran | wow, one full hour since the release and nobody reported any embarrassing bug/omission? is this the real life, is this just fantasy? |
12:49:49 | PMunch | narimiran, maybe no-one was able to update, everyones computer is on fire! |
12:49:53 | Zevv | Everbody is still busy reading the changelog |
12:50:07 | narimiran | PMunch: still win in my book |
12:50:14 | FromDiscord | <Rika> @mratsim doesnt work |
12:50:44 | narimiran | Zevv: ...and nobody pointed out that one missing `]` in the changelog either |
12:50:49 | * | stefantalpalaru joined #nim |
12:51:39 | FromDiscord | <Rika> literally unreadable |
12:52:37 | lqdev[m] | @Rika are you sure the path is correct? I use ../ all the time and it works |
12:52:46 | lqdev[m] | what error are you getting? |
12:53:12 | FromDiscord | <Rika> hmm wait |
12:53:43 | FromDiscord | <Rika> okay so i cant use the [m1, m2] syntax with it |
12:54:24 | FromDiscord | <mratsim> ah yes, the mysteries of bracket |
12:54:33 | FromDiscord | <mratsim> but if you use ../../ I think it works |
12:54:47 | FromDiscord | <mratsim> (i.e. double parent) |
12:55:10 | FromDiscord | <mratsim> there are some weirds bugs around import ./ ../ and bracket syntax |
12:56:52 | Araq | not really, it's just the same Nim syntax as everywhere else |
12:56:57 | FromDiscord | <Rika> wtf double parent does work |
12:57:03 | Araq | there is no special casing for it |
12:57:13 | FromDiscord | <Rika> why does ../[] not work though? |
12:57:33 | Araq | because you need ../.. ? |
12:57:50 | Araq | you still need to do the counting yourself |
13:03:00 | shashlick | Ok what's next |
13:05:44 | * | skelett quit (Quit: WeeChat 2.5) |
13:06:04 | Araq | add 'bump' to Nimble |
13:06:10 | * | skelett joined #nim |
13:06:11 | * | skelett quit (Client Quit) |
13:06:46 | * | skelett joined #nim |
13:07:35 | * | javasox quit (Ping timeout: 260 seconds) |
13:08:22 | Araq | and make 'nimble search' use the github search too |
13:08:36 | FromDiscord | <ZeeQyu> Ooh, that'd be nice |
13:09:07 | FromDiscord | <Rika> hey nice bump on nimble |
13:12:24 | FromDiscord | <arnetheduck> re large precision integers, we just merged a massive test suite for both compile and runtime, coutesy of @jangko: https://github.com/status-im/nim-stint/pull/91 - might beof interest |
13:12:42 | FromDiscord | <Shield> why's "garbage-collected" was removed from the main website but not github? and why remove it at all if the gc is still winning the async war? |
13:18:01 | disruptek | it misleads potential customers. |
13:20:22 | Araq | Shield: we need to remove it from github too :P |
13:21:06 | * | skelett quit (Quit: WeeChat 2.5) |
13:21:26 | * | skelett joined #nim |
13:21:52 | shashlick | @disruptek you good merging bump into nimble? |
13:22:44 | * | Kaivo quit (Quit: WeeChat 2.6) |
13:22:56 | * | Kaivo joined #nim |
13:23:34 | disruptek | if i can just import it, sure. i don't fancy maintaining two instances of a 400-line sed. |
13:24:28 | shashlick | I'm good with that but you will have to impress @dom96 if not already |
13:24:55 | disruptek | impressing dom96 has never been my strong suit. |
13:25:17 | * | theelous3 quit (Ping timeout: 240 seconds) |
13:27:41 | shashlick | I think it is easier to impress Araq |
13:31:28 | shashlick | Thinking of working on choosenim but that is also the same boat |
13:33:03 | disruptek | apparently, he likes NIH tools so trivial that their very existence is questionable. |
13:34:50 | Araq | "he"? me? |
13:35:21 | disruptek | oh shoot, the dragon wakes. |
13:35:41 | * | Hideki_ quit (Remote host closed the connection) |
13:35:48 | Araq | well I'm away, please offend me when I'm online |
13:35:52 | disruptek | shashlick: choosenim was always too magical for me. if that could be improved, maybe we'd get less bug reports. |
13:35:57 | Araq | so that I can defend myself |
13:36:02 | Araq | bye |
13:36:05 | disruptek | lol |
13:36:20 | disruptek | he didn't give us much of a time window in which to offend him. |
13:36:28 | * | Hideki_ joined #nim |
13:36:28 | FromGitter | <alehander42> smart |
13:40:18 | * | Hideki_ quit (Remote host closed the connection) |
13:40:32 | * | Hideki_ joined #nim |
13:47:40 | shashlick | I like that Araq's indignation is based on actual research and practical experience |
13:48:34 | shashlick | not armchair theories |
13:53:19 | * | Hideki_ quit (Remote host closed the connection) |
13:54:05 | * | Hideki_ joined #nim |
13:58:38 | * | Hideki_ quit (Ping timeout: 265 seconds) |
14:13:49 | stefantalpalaru | If we're keeping it real, reference counting is a form of garbage collection. |
14:15:32 | * | theelous3 joined #nim |
14:19:03 | FromDiscord | <Rika> isnt there also an argument that borrow checking is a form of garbage collection too or smth |
14:20:59 | FromDiscord | <mratsim> memory management yes, but garbage collection usually implies runtime cost |
14:25:12 | stefantalpalaru | Can you do compile-time garbage collection in the form of borrow checking without runtime garbage collection in the form of reference counting? Rust cannot. |
14:25:23 | * | PMunch quit (Remote host closed the connection) |
14:27:04 | FromDiscord | <Rika> rust cant? |
14:28:19 | stefantalpalaru | "In order to enable multiple ownership, Rust has a type called Rc<T>. Its name is an abbreviation for reference counting." - https://doc.rust-lang.org/1.22.0/book/second-edition/ch15-04-rc.html |
14:29:00 | dom96 | Araq has grown soft over the years :P |
14:29:03 | dom96 | Everything I ask for in reviews is stuff I've learned from him ;) |
14:29:31 | shashlick | While you are here |
14:29:37 | disruptek | maybe he has learned something in that time. |
14:29:47 | shashlick | I'm planning on replacing untar with nimarchive in choosenim |
14:29:57 | stefantalpalaru | "A thread-safe reference-counting pointer. 'Arc' stands for 'Atomically Reference Counted'." - https://doc.rust-lang.org/std/sync/struct.Arc.html |
14:30:00 | * | fanta1 joined #nim |
14:30:02 | shashlick | Are you onboard with that |
14:30:28 | dom96 | that depends, will we need to ship more DLLs with choosenim? |
14:30:46 | shashlick | Will enable zip, gz, xz and 7z extraction natively cross platform |
14:31:03 | shashlick | Can be statically linked |
14:32:00 | shashlick | It is a wrapper for libarchive and includes zlib, lzma and bzlib |
14:32:14 | FromDiscord | <Rika> stefantalpalaru, i dont understand this portion of your statement, "compile-time garbage collection in the form of borrow checking", doesnt Rust do that already? |
14:32:25 | FromDiscord | <Rika> anyway, this is getting OT |
14:32:48 | FromDiscord | <mratsim> talking about borrow checking or garbage collection is not OT |
14:33:27 | * | Hideki_ joined #nim |
14:33:28 | dom96 | shashlick: how easily can it be statically linked? |
14:33:51 | stefantalpalaru | Read the whole phrase, Rika. I'm saying not even Rust can avoid the runtime overhead of garbage collection. |
14:34:06 | dom96 | tbh I guess it doesn't really matter, we ship the SSL DLLs anyway |
14:34:17 | dom96 | another few can't hurt, can they? |
14:34:19 | shashlick | https://github.com/genotrance/nimarchive/blob/master/tests/tnimarchive_extract.nim |
14:34:28 | shashlick | You just import nimarchive and use extract |
14:34:33 | shashlick | Everything else is abstracted |
14:34:39 | shashlick | Uses nimterop |
14:35:02 | dom96 | That tells me nothing about how easy it is to statically link |
14:35:13 | FromDiscord | <Rika> @mratsim i meant OT because we're discussing rust |
14:35:14 | disruptek | the user doesn't care how hard it was to link. |
14:35:43 | shashlick | There's nothing else to do |
14:35:49 | shashlick | In choosenim |
14:36:05 | shashlick | See the CI if needed |
14:36:08 | FromDiscord | <Rika> anyway i understand the statement now |
14:37:09 | dom96 | shashlick: Okay, if the CI can handle it then I'll likely be happy. I'm still curious what statically linking this looks like on Windows though, i.e. what commands do you need to pass to Nim to do it? |
14:37:59 | dom96 | disruptek: every additional dependency increases the possibility of problems. |
14:38:34 | shashlick | Everything is built into nimterop |
14:38:44 | disruptek | you know what's a problem? not being able to open an archive. |
14:38:53 | shashlick | https://github.com/genotrance/nimarchive/blob/master/nimarchive/archive.nim |
14:39:25 | shashlick | Nimterop will download, build and link the lib |
14:40:21 | shashlick | The nimarchive ci is testing cross platform including windows |
14:40:27 | shashlick | See the nimble file |
14:41:04 | dom96 | Libraries downloading other libraries, what could go wrong? :) |
14:41:28 | disruptek | next you'll want code to create other code. |
14:41:34 | disruptek | SHASHLICK |
14:41:40 | disruptek | you madlad. |
14:41:42 | disruptek | get in lane. |
14:43:03 | shashlick | I don't setup crazy CI matrices for fun, let's just say |
14:43:23 | disruptek | liar. |
14:51:14 | * | alexander92 quit (Ping timeout: 240 seconds) |
14:51:38 | * | Hideki_ quit (Ping timeout: 240 seconds) |
14:55:10 | dom96 | shashlick btw what's so magical about choosenim? |
14:56:04 | shashlick | ? |
14:57:24 | dom96 | oh, sorry, @disruptek |
14:57:42 | disruptek | i dunno, that's kinda the nature of magic. |
14:57:53 | dom96 | lol okay |
14:58:01 | disruptek | what i know is that i couldn't figure out why it wouldn't work for me. |
14:58:25 | disruptek | also, i can't figure out why it doesn't work for other people who show up here and can't seem to achieve a reproducable compiler with it. |
14:58:43 | disruptek | but again, to me, it's magic. i'm not smart enough. |
14:59:04 | dom96 | any errors? |
14:59:14 | disruptek | those would be helpful, yes. |
15:00:16 | dom96 | Hrm, okay. So no errors, no evidence of what actually wasn't working, just statements that it's "too magical". |
15:00:22 | dom96 | Starting to wonder if you're just spreading FUD :P |
15:00:46 | shashlick | There are some known issues |
15:00:53 | disruptek | my opinion is worthless here for myriad reasons; chief among them is the fact that i don't use choosenim. |
15:01:03 | shashlick | But I think it works very well for me |
15:02:39 | disruptek | when i tried to use it, it was very inconsiderate of my environment and not transparent about what it was doing or why. |
15:03:05 | * | ng0 joined #nim |
15:03:17 | disruptek | repairing things was a manual process and i had no introspection into the inherent assumptions, so i had to guess as to what to do. |
15:03:37 | disruptek | maybe it just needs a `doctor` mode, or maybe i need to hire another child just to manage my choosenim install. |
15:04:22 | * | fanta1 quit (Quit: fanta1) |
15:05:10 | * | alexander92 joined #nim |
15:06:05 | disruptek | tbh, because i don't use it, my only surface with the software is the people that come here with bizarre misbehavior which is fixed by "blow away choosenim and reinstall" or "abandon choosenim and build nim from source". so, there's that. |
15:08:25 | disruptek | i actually think `nim doc` is a bigger problem, but i think i should wait until araq is online in case there's an opportunity there to offend him. |
15:13:28 | alexander92 | thats a good thing, if restart works fine |
15:14:10 | disruptek | yes, we've managed to port docker-like-sysadmin to software. |
15:14:11 | * | Trustable joined #nim |
15:14:33 | disruptek | next nimble submodule: ctrl-alt-del |
15:15:02 | FromDiscord | <kodkuce> winXP |
15:22:09 | FromDiscord | <kodkuce> how can i see C generated code when i compile helloworld.nim |
15:22:41 | shashlick | look in nimcache |
15:22:41 | stefantalpalaru | --verbosity:2 |
15:23:09 | * | theelous3 quit (Ping timeout: 268 seconds) |
15:23:32 | stefantalpalaru | or --listCmd |
15:25:22 | FromDiscord | <kodkuce> verbosuty and list cmd dident show anything, where is nimchache |
15:26:03 | FromDiscord | <kodkuce> fopund it |
15:29:46 | FromDiscord | <kodkuce> a lot of files for just 1 line hello world i was even using -gc:none hoping it will remove gc part |
15:32:05 | * | brainproxy joined #nim |
15:33:38 | * | alexander92 quit (Ping timeout: 268 seconds) |
15:38:03 | * | tklohna_ quit (Ping timeout: 240 seconds) |
15:42:43 | * | clyybber joined #nim |
15:53:42 | disruptek | Zevv: why not see how much of the nre api you can replicate in your npeg code blocks? it could be that the bits that don't fit perfectly are outweighed by the consistency of interface. |
16:00:09 | * | narimiran quit (Ping timeout: 268 seconds) |
16:08:11 | * | fanta1 joined #nim |
16:08:20 | * | LargeEpsilon quit (Ping timeout: 276 seconds) |
16:20:27 | FromDiscord | <Clyybber> @arnetheduck Btw, how do you handle object constructors in nlvm? |
16:21:06 | dom96 | narimiran[m]: Araq: so was it a joke or are we really not getting a release article? |
16:21:53 | FromDiscord | <Clyybber> Because I'm about to introduce a transformation like `Obj(v: 1)` -> `var tmp = Obj(); tmp.v = 1; tmp` |
16:25:17 | FromGitter | <Willyboar> I have a silly newbie question ⏎ Why this takes all prints all the files ⏎ ⏎ ```code paste, see link``` ⏎ ... [https://gitter.im/nim-lang/Nim?at=5db07eed14d55a37856158f5] |
16:26:02 | disruptek | actually, it gives only the first. |
16:26:36 | federico3 | no forum post for 1.0.2 ? |
16:27:05 | disruptek | `return` is the crash operator. it crashes the compiler at top-level and crashes your procedure anywhere else. |
16:28:00 | federico3 | also, there is no version and changelog on https://nim-lang.org/install_unix.html and https://nim-lang.org/install.html |
16:28:03 | FromGitter | <Willyboar> Well is there a way to return all the files? |
16:28:18 | disruptek | accumulate them into a sequence and return that? |
16:29:22 | FromGitter | <Willyboar> Can i have a small ex? :P |
16:30:44 | disruptek | !eval var s = seq[string]; for n in walkDir("."): if s.len > 1: return s else: s.add n; echo s |
16:30:45 | NimBot | Compile failed: /usercode/in.nim(1, 45) Error: complex statement requires indentation |
16:30:51 | disruptek | hmmph. |
16:30:54 | disruptek | !eval var s = seq[string]; for n in walkDir("."): if s.len > 1: return s else: s.add n |
16:30:56 | NimBot | Compile failed: /usercode/in.nim(1, 45) Error: complex statement requires indentation |
16:31:17 | disruptek | you get the idea. |
16:31:41 | disruptek | maybe nimbot should learn what \x0a means. |
16:32:59 | dom96 | PRs welcome :) |
16:33:24 | disruptek | i can't teach that kid anything; he's younger than me. |
16:35:47 | disruptek | !eval var s = seq[string]; { for n in walkDir("."): { { if s.len > 1: return s else: s.add n } }; echo s |
16:35:49 | NimBot | Compile failed: /usercode/in.nim(1, 99) Error: expected: '}', but got: '[EOF]' |
16:36:09 | disruptek | !eval var s = seq[string]; { for n in walkDir("."): { if s.len > 1: return s else: s.add n } }; echo s |
16:36:11 | NimBot | Compile failed: /usercode/in.nim(1, 12) Error: 'typedesc' metatype is not valid here; typed '=' instead of ':'? |
16:36:32 | disruptek | !eval var s: seq[string]; { for n in walkDir("."): { if s.len > 1: return s else: s.add n } }; echo s |
16:36:33 | NimBot | Compile failed: /usercode/in.nim(1, 32) Error: undeclared identifier: 'walkDir' |
16:36:43 | disruptek | !eval import os; var s: seq[string]; { for n in walkDir("."): { if s.len > 1: return s else: s.add n } }; echo s |
16:36:45 | NimBot | Compile failed: /usercode/in.nim(1, 73) Error: 'return' not allowed here |
16:37:05 | disruptek | !eval import os; var s: seq[string]; { for n in walkDir("."): { if s.len > 1: echo "return " & $s else: s.add n } }; echo s |
16:37:08 | NimBot | Compile failed: /usercode/in.nim(1, 100) Error: type mismatch: got <seq[string], tuple[kind: PathComponent, path: string]> |
16:37:11 | disruptek | i'm the bob ross of nimbot. |
16:37:18 | disruptek | !eval import os; var s: seq[string]; { for c, n in walkDir("."): { if s.len > 1: echo "return " & $s else: s.add n } }; echo s |
16:37:21 | NimBot | Compile failed: /usercode/in.nim(1, 62) Error: expression 'if ( |
16:37:29 | disruptek | pretty little curly braces. |
16:38:12 | leorize | !eval import os; var s: seq[string]; for c, n in walkDir("."): (if s.len > 1: echo "return " & $s else: s.add n); echo s |
16:38:16 | NimBot | @["./nimble"]↵@["./nimble", "./nim"] |
16:38:34 | disruptek | hooray! |
16:39:19 | disruptek | it takes a child. |
16:39:26 | disruptek | or, a village, as you prefer. |
16:41:16 | * | theelous3 joined #nim |
16:49:02 | Zevv | disruptek: makes sense, but that API is also not very structured. And my problem with mimicing is that you can't just get there all the way, but people do get expectations and will complain if youre not a drop in replacement |
16:49:22 | disruptek | let me talk to those people; i'll straighten them out. |
16:51:09 | disruptek | maybe you should patch nre and then npeg will fit into stdlib more nicely. |
16:51:40 | Zevv | I wouldnt want it to |
16:51:55 | Zevv | its miiiiiineeeee |
16:52:09 | Zevv | and then Id have to sit on my hands before I type, all the time |
16:52:50 | disruptek | just wear mittens at the keyboard; that's what i do. |
16:54:37 | clyybber | arnetheduck: I'll also make the result variable transform to a normal variable btw. |
16:55:51 | Zevv | I have these fingerless mittens, thats a nice tradeoff |
17:03:21 | shashlick | @dom96 - https://github.com/nim-lang/nimble/commit/c834faf60e1dbdd8ae46456e1fb2dc2db05e4e91#diff-8f5588fb3c673d679a2ed04e79cdc74eR370 broke choosenim |
17:03:33 | shashlick | initOptions() is now private and inaccessible from choosenim |
17:04:58 | * | floppydh quit (Quit: WeeChat 2.6) |
17:05:09 | * | fanta1 quit (Quit: fanta1) |
17:07:32 | dom96 | shashlick fun, easy fix in any case. Also, we need a comment in that function to make sure none of us makes it private by mistake :) |
17:09:07 | shashlick | okay will push a PR for nimble |
17:09:44 | shashlick | though we might need choosenim to refer to nimble head else it won't pull the changes until the next version |
17:10:28 | * | tklohna_ joined #nim |
17:10:44 | dom96 | Never HEAD |
17:11:09 | dom96 | We can pin it to your commit |
17:11:20 | shashlick | okay |
17:12:06 | FromDiscord | <arnetheduck> clybbber, that depends - `nlvm` does constant inits more aggressively, so for those your suggested transform would be a pessimization - for dynamic init, it does that transformation already essentially |
17:13:32 | clyybber | arnetheduck: I think/hope that llvm will optimize those away in the constant init case, wdyt? |
17:14:06 | FromDiscord | <arnetheduck> well, if it's able to trace it, it's more work for the optimizer which slows down the compile |
17:14:11 | shashlick | @dom96 - did you change NimbleError any? |
17:14:20 | shashlick | choosenim doesn't expect it in version.nim |
17:14:27 | dom96 | shashlick even if I did I wouldn't remember |
17:14:33 | FromDiscord | <arnetheduck> I also don't think that it's able to lift constant constructors in all cases |
17:15:01 | * | ng0_ joined #nim |
17:15:45 | * | Trustable quit (Remote host closed the connection) |
17:16:53 | FromDiscord | <arnetheduck> re result, it's already kind of a variable, no? I've never been fond of it , neither the implementation (which is pretty messy due to how the compiler uses `TLoc` passed into the node processing function, and you never know what that tloc is/comes from) nor the feature itself, it's pretty useless with the other return types (and for the few corner cases, one can just make an explicit var) |
17:17:24 | * | ng0 quit (Ping timeout: 260 seconds) |
17:18:49 | FromDiscord | <arnetheduck> nim has better codegen for large result variables (except for the bugs where it calls genericreset 2-3 times), the ones that are transformed into a parameter - I don't do the rvo dance.. potentially that would be an interesting transform to have, but then again, perhaps not - `llvm` has special features to deal with large object returns so if that transform is done by default, it will again be a pessimization |
17:19:33 | FromDiscord | <arnetheduck> @Clyybber ^ |
17:20:48 | FromDiscord | <arnetheduck> a meaningful change that we've run into lots of times is `genericReset` - if you could get rid of that, it would be a big win (it should probably be replaced by explicit, type-specific functions that can be inlined) |
17:21:46 | FromDiscord | <arnetheduck> at least, that's what I'm going to do for `nlvm` if I ever have time - and having the same structure in the C code would make it more maintainable |
17:22:49 | FromDiscord | <arnetheduck> re optimizations, the way `llvm` works is that you add the optimization passes that make sense for your language - if you can generate "good" code out of the box, that's obviously faster/better |
17:29:10 | FromGitter | <Willyboar> @disruptek can't make it work |
17:32:45 | * | elrood joined #nim |
17:34:14 | clyybber | arnetheduck: I had that planned. |
17:35:18 | clyybber | generic reset I mean |
17:40:25 | leorize | what exactly does genericReset do? I heard from people who optimize Nim code that it's performance hell |
17:40:46 | leorize | but I'm not quite sure what it is and when will it be used |
17:52:19 | jken | Can someone explain this error to me? Position* = ref object of Component |
17:52:19 | jken | x*, y*, z*: float |
17:52:19 | jken | Dimensions* = ref object of Component |
17:52:20 | jken | width*, height*, depth*: float |
17:52:20 | jken | ControlledCamera* = ref object of Component |
17:52:21 | jken | Controllable* = ref object of Component |
17:52:22 | jken | RenderBlock* = ref object of Component |
17:52:24 | jken | oops.. sorry. |
17:52:36 | jken | expression 'init(app)' has no type (or is ambiguous) |
17:52:46 | jken | clipboard is borked on my system |
17:53:01 | Yardanico | You're trying to do something like "let a = init(app)" but init(app) doesn't return anything |
17:53:04 | Yardanico | (probably) |
17:53:20 | disruptek | more likely it's the last line in a statement list that must return a value. |
17:53:25 | jken | I am not assigning the return |
17:53:36 | jken | and the proc does not specify a return type |
17:53:53 | Yardanico | can you post the source code of the proc and the way you call it in ix.io or other paste service? |
17:54:03 | Yardanico | (it'll be probably a bit too large to fit in IRC :P) |
17:54:46 | jken | This is the proc |
17:54:46 | jken | https://paste.debian.net/plain/1109375 |
17:54:59 | jken | I import the module it is in (platform) |
17:55:07 | jken | and then call platform.init(app) |
17:55:10 | jken | where app is an Application |
17:55:43 | Yardanico | why platform.init(app) though? |
17:56:00 | leorize | to avoid collision persumably |
17:56:19 | jken | I am trying to refactor so that platform, and some other modules I have, can be added as modular layers in my Application |
17:56:28 | jken | so I have other modules with the same procs/signaturs |
17:56:45 | leorize | so what's the content of the line in the error message? |
17:57:10 | jken | Its this proc: |
17:57:10 | jken | proc init(app: Application): |
17:57:11 | jken | platform.init(app) |
17:57:26 | leorize | after proc declaration it's `=` |
17:57:28 | leorize | not `:` |
17:57:36 | jken | ah derp |
17:57:40 | jken | my bad |
17:58:19 | jken | Thank you. |
17:59:15 | leorize | the first time I got that I was confused as well :p |
17:59:27 | leorize | guess we need some context-aware error messages |
18:02:03 | * | nsf quit (Quit: WeeChat 2.6) |
18:09:03 | FromDiscord | <arnetheduck> leorize, it will reset an instance to its default state, meaning all zeroes/nils - it walks object graphs using RTTI which is really inefficient because no inlining can happen etc |
18:09:17 | FromDiscord | <arnetheduck> it's also called redundantly due to bugs, compounding the issue |
18:10:02 | Araq | it was mitigated in version 1, and will be gone in version 1.1 |
18:10:07 | Araq | I think. |
18:10:42 | Araq | the new seqs and strings don't work with it anyway, time to kill it |
18:15:35 | * | PMunch joined #nim |
18:20:29 | * | icyphox_ joined #nim |
18:20:56 | FromDiscord | <kodkuce> i want magic new runtime or something so i can say to rust people they gey and nim better |
18:31:13 | * | icyphox_ quit (Quit: icy's znc) |
18:32:50 | lqdev[m] | @kodkuce that's a pretty radical idea, lol |
18:40:26 | * | tklohna_ quit (Ping timeout: 276 seconds) |
18:49:00 | * | Hideki_ joined #nim |
18:54:03 | * | Hideki_ quit (Ping timeout: 268 seconds) |
18:57:28 | FromGitter | <xmonader> ```code paste, see link``` ⏎ ⏎ any idea how to fix that? removing .closure. also doesn't work [https://gitter.im/nim-lang/Nim?at=5db0a298a03ae1584ff79f38] |
18:58:16 | FromGitter | <xmonader> ```code paste, see link``` ⏎ ⏎ that's what i'm trying to do [https://gitter.im/nim-lang/Nim?at=5db0a2c814d55a3785626c33] |
18:59:21 | * | leorize quit (Remote host closed the connection) |
18:59:49 | * | leorize joined #nim |
19:05:21 | * | tklohna_ joined #nim |
19:10:20 | * | tklohna_ quit (Ping timeout: 276 seconds) |
19:21:00 | * | elrood quit (Quit: Leaving) |
19:41:46 | * | kkkk joined #nim |
19:42:12 | * | PMunch_ joined #nim |
19:42:27 | * | kkkk quit (Remote host closed the connection) |
19:45:42 | * | lritter quit (Ping timeout: 246 seconds) |
19:46:18 | * | narimiran joined #nim |
19:47:18 | FromDiscord | <mratsim> (fixed) |
19:48:22 | * | PMunch quit (Remote host closed the connection) |
19:48:44 | * | PMunch_ is now known as PMunch |
19:51:53 | * | ng0_ is now known as ng0 |
19:52:40 | FromDiscord | <ZeeQyu> xmonader: Couldn't reproduce, I added dummy declarations to let it compile, but I'm guessing there's more going on in your code. Hope my experiments help you in some way. |
19:52:40 | FromDiscord | <ZeeQyu> Which nim version are you on, btw? I did v.0.0 |
19:52:47 | FromDiscord | <ZeeQyu> v1.0.0 and it worked |
19:53:05 | FromDiscord | <ZeeQyu> https://play.nim-lang.org/#ix=1ZDf |
19:58:34 | * | nsf joined #nim |
20:03:01 | * | lmariscal quit (Quit: I'm Out!) |
20:04:57 | * | clyybber quit (Quit: WeeChat 2.6) |
20:05:22 | * | lmariscal joined #nim |
20:06:29 | FromDiscord | <krab4t> notifications in discord doesnt work without @ 🙂 |
20:06:47 | FromGitter | <xmonader> Yup @mratsim gave me lots of help. I think it may differ with the complete code @ZeeQyu ⏎ https://github.com/xmonader/nim-servy/pull/1 |
20:08:25 | FromDiscord | <ZeeQyu> @krab4t Oh, believe me, I know. However, I don't know how mentions in gitter work, so at that point, it's just easier to let people read chat when they feel like reading chat. |
20:09:52 | FromGitter | <xmonader> question why the unpacking here works ⏎ ⏎ ``` let parentName, dirName, ext = splitFile(thepath) ⏎ ``` [https://gitter.im/nim-lang/Nim?at=5db0b390ef84ab37868534d6] |
20:10:30 | FromDiscord | <ZeeQyu> Thanks for showing that pull request. I might've learned something. Not sure though |
20:11:39 | * | narimiran quit (Ping timeout: 240 seconds) |
20:25:15 | * | alexander92 joined #nim |
20:30:30 | * | nsf quit (Quit: WeeChat 2.6) |
20:30:53 | * | PMunch quit (Remote host closed the connection) |
20:33:51 | stefantalpalaru | Why was this repo archived? https://github.com/nim-lang/csources |
20:35:43 | FromDiscord | <ZeeQyu> A decision was made to freeze the csources to 20.2, as everything after 1.0.0 is intended to have a backwards compatability guarantee. So using those csources you should be able to reach any recent release using koch's iteration compilation |
20:36:50 | FromDiscord | <ZeeQyu> I'm guessing the archival was a way to formalize that decision |
20:36:55 | stefantalpalaru | OK |
20:41:53 | Araq | exactly |
20:42:06 | FromDiscord | <ZeeQyu> Trying to find where I read it. Was some weird place like the install notes of something, in a part of a list of steps to take when releasing a new compiler version |
20:42:19 | FromDiscord | <ZeeQyu> But I guess confirmation from Araq is an easier source |
20:44:54 | stefantalpalaru | I was worried you're dropping the csources Git repo. That's what usually happens with abandoned GitHub repos - they get archived as a sign that people shouldn't bother reporting bugs. |
20:45:37 | disruptek | well, they shouldn't. |
20:46:21 | FromDiscord | <ZeeQyu> Perhaps a readme update to the csources repo is in order then, with the same content as my answer above. If that's possible after it's been archived, don't know how permanent that action is. |
20:46:45 | Araq | you can un-archive it |
20:47:11 | * | brainproxy quit (Ping timeout: 276 seconds) |
20:47:16 | FromDiscord | <ZeeQyu> Nice |
20:48:42 | Araq | it was brought up that it might eventually become too hard to have a Nim compiler that can build from csources 0.20.2 |
20:49:21 | Araq | if that happens (and we hope it's 5 years away) we will introduce nim-lang/csources2 |
20:50:08 | FromDiscord | <ZeeQyu> Why prefer that over just updating csources? |
20:51:12 | Araq | because this way all the scripts that use 'git clone csources' continue to work |
20:51:20 | FromDiscord | <ZeeQyu> Fair |
20:53:35 | FromDiscord | <ZeeQyu> But if those scripts want to use nim 1.40.0, then they all have to be updated. What would change in the compiler that would make those original scripts not work? |
20:56:56 | rayman22201 | ideally all the scripts would be pinned to a git hash, but I think it's too late to change all those scripts now. Too many copies out in the wild. |
20:58:04 | * | brainproxy joined #nim |
20:58:20 | stefantalpalaru | That's what I do, I target a specific commit: https://github.com/status-im/nimbus-build-system/blob/master/scripts/build_nim.sh |
20:58:56 | rayman22201 | yeah. That's the smart thing to do. |
21:00:15 | Araq | ZeeQyu: new Nim versions can usually not compile old system.nim files, Nim gets more and more picky |
21:02:56 | * | brainproxy quit (Ping timeout: 268 seconds) |
21:03:17 | shashlick | all nim releases come with csources included |
21:05:31 | stefantalpalaru | Only the tarballs, IIRC. |
21:05:44 | Araq | shashlick: yeah but our own CIs don't use that either |
21:06:23 | Araq | unfortunately. plus our "build from source" instructions always told to do it via "git clone csources" |
21:07:01 | Araq | so instead of fixing every script and our docs, we made it work as documented. *shrug* |
21:09:30 | shashlick | makes sense |
21:10:57 | FromDiscord | <ZeeQyu> Araq: So if you were to try to run something you wrote a while ago with a newly compiled compiler, based on updated csources, then we can't compile a legacy compiler with that compiler. Is that what you're saying? |
21:10:58 | FromDiscord | <ZeeQyu> |
21:10:58 | FromDiscord | <ZeeQyu> But in that case, if we have old csources to compile an old compiler, then koch to a new compiler, we can't use the new compiler to go back to the old one. Which means, every time we change compiler version backwards, we need to compile from csources. |
21:10:58 | FromDiscord | <ZeeQyu> In that case, shouldn't we have a hard break to a new major version at each time we can't compile from the old csources anymore? Or is that what you mean? |
21:13:27 | lqdev[m] | shashlick: I'm getting an incomplete struct error in nimterop because a header I'm importing doesn't contain the struct's implementation, how can I fix this? |
21:13:31 | Araq | if I update csources to Nim v2 they cannot compile Nim v1 anymore. you would need to checkout a different version from csources and I've been told that nobody will be able to figure it out and hell will freeze over and we'll all die |
21:13:38 | * | solitudesf quit (Ping timeout: 265 seconds) |
21:13:56 | FromDiscord | <ZeeQyu> But isn't that still the case with a csources2? |
21:14:07 | lqdev[m] | https://termbin.com/86ot this is my wrapper |
21:14:19 | FromDiscord | <ZeeQyu> Just that they need to pick another repo instead of checking out another commit |
21:14:56 | Araq | but that's opt-in, csources can still compile v1 |
21:15:00 | shashlick | @lqdev - trying |
21:15:02 | Araq | that's the difference. |
21:15:14 | Araq | it's not really all that hard to understand, is it? |
21:15:53 | * | alexander92 quit (Quit: WeeChat 2.4) |
21:15:59 | FromDiscord | <ZeeQyu> I'm guessing the detail I was missing was that csources2 is bound to nim 2.x. Given that, it makes way more sense |
21:16:13 | shashlick | hmm - wfm |
21:18:02 | shashlick | @Araq - you have been tagging csources so it is possible to build older versions by using corresponding csources |
21:18:24 | Araq | yes, I do know that |
21:18:47 | Araq | but the scripts do not checkout versions, they all use "latest" |
21:19:25 | shashlick | which scripts - i know choosenim does this but it's a fallback if you have to build from github sources |
21:19:52 | Araq | build_all.sh: |
21:19:54 | Araq | [ -d csources ] || echo_run git clone --depth 1 https://github.com/nim-lang/csources.git |
21:20:33 | shashlick | well if someone wants to build 0.18.0, it will still fail since csources master today cannot build it |
21:20:47 | Araq | yes, so it's correct since 1.0 |
21:20:49 | Araq | :P |
21:22:19 | shashlick | 😄 |
21:22:24 | shashlick | @dom96 - easy one - https://github.com/nim-lang/nimble/pull/732 |
21:24:46 | Araq | it's also all silly nonsense, by the same logic every C++ project should have gcc -std=c11 in its build instructions because when I checkout the git repo in 2040 C++2040 will be so different so that it doesn't work without this switch. Or something like that. |
21:25:38 | FromDiscord | <ZeeQyu> Oh god, I hope we've replaced c++ by 2040. |
21:25:53 | FromDiscord | <ZeeQyu> We probably won't, but that won't stop me from hoping |
21:26:51 | Araq | and you cannot add this switch to your build, because somebody checks our the version from 2019 where this switch is still missing |
21:26:58 | Araq | *out |
21:27:33 | FromDiscord | <ZeeQyu> Crap, you're right. Backwards compatibility is horrible. |
21:27:53 | shashlick | why not fix the build scripts instead - is it cause 1.0 has to be perfect |
21:28:30 | Araq | shashlick: I regard this solution particularly elegant, I don't have to fix the builds, nor do I have to update csources for a release |
21:28:42 | Araq | a release now takes less time than before |
21:29:30 | stefantalpalaru | Of course you need to explicitly pass the corresponding flag to the compiler if you target a specific standard version. C and C++ developers are not as crazy as you think, with their backwards compatibility requirements. |
21:30:53 | * | brainproxy joined #nim |
21:31:26 | shashlick | well but now you are restricted to only use the features in the csourses version for the nim compiler going forward |
21:31:37 | Araq | I'm not. |
21:33:23 | Araq | in the worst case, I create csources2 and move on. And distros can still build v1 |
21:33:30 | disruptek | you guys are talkin' like your programs aren't compiled from C89. |
21:33:46 | disruptek | seems like a non-issue to me. |
21:34:11 | FromDiscord | <ZeeQyu> It's fine, we've hidden all the C89. The user doesn't have to see it. |
21:34:37 | disruptek | i haven't seen one complaint about not being able to submit a PR against csources. |
22:14:29 | * | Vladar quit (Quit: Leaving) |
22:14:36 | FromDiscord | <krab4t> so i just should use ` Option[bool] ` that makes code full of ` some(true|false) ` 👺 |
22:15:02 | disruptek | is your project public yet? |
22:15:25 | FromDiscord | <krab4t> no, its 400 lines of code in one file |
22:15:57 | FromDiscord | <krab4t> how you make VS Code run nimble build over nim -c |
22:16:14 | disruptek | i dunno; i don't use vs code and i try not to use nimble. |
22:16:43 | FromDiscord | <krab4t> so what you use then |
22:16:53 | FromDiscord | <kodkuce> neovim |
22:16:57 | FromDiscord | <kodkuce> i think xD |
22:17:03 | disruptek | yeah. |
22:17:28 | disruptek | y'know, PoE was released 6 years ago on this date. |
22:17:42 | disruptek | you'd be in good company if you wanted to get it out there. |
22:18:12 | FromDiscord | <krab4t> Joined: Mar 27, 2012 |
22:18:21 | disruptek | what does `nimble build` do? |
22:18:46 | FromDiscord | <krab4t> build entire project with multiple files i think |
22:21:07 | FromGitter | <Willyboar> One step left for my static blog gen |
22:22:04 | dom96 | Thanks shashlick |
22:22:08 | dom96 | (for the Nimble PR) |
22:22:10 | FromDiscord | <krab4t> disruptek, i don't want to be in "their" company wtf, its just small tool for myself |
22:22:34 | disruptek | just make a type with three values; Truthy, Falsey, and Neither. then return that instead of your bool Option. |
22:23:23 | FromGitter | <Willyboar> I ll make a break for some hot chocolate and "mpougatsa" and i will ask for some help |
22:23:24 | FromGitter | <Willyboar> :) |
22:23:30 | dom96 | we have csources2 now? |
22:23:42 | dom96 | what's next? Nimble2? |
22:24:14 | disruptek | i started a nimble rewrite in perl6. |
22:24:25 | disruptek | it's not as bad as it sounds. |
22:24:33 | dom96 | disruptek, you're the hero we don't deserve |
22:24:38 | disruptek | lol |
22:24:50 | dom96 | Araq, Why. Is. There. No. Nim. 1.0.2. Release. Article. |
22:25:06 | disruptek | dom96 got his period today. |
22:25:10 | disruptek | several of 'em, in fact. |
22:27:13 | mipri | https://irclogs.nim-lang.org/23-10-2019.html#12:10:56 about that |
22:27:27 | dom96 | Oh nice. FWIW I don't condone such language in this channel |
22:27:42 | mipri | so this: https://github.com/nim-lang/Nim/blob/devel/changelogs/changelog_1_0_2.md |
22:30:56 | dom96 | mipri, yeah, I saw that. See https://irclogs.nim-lang.org/23-10-2019.html#12:31:05 |
22:32:34 | dom96 | Fine, since nobody is going to do it, I'll write it myself. |
22:40:09 | * | brainproxy quit (Ping timeout: 265 seconds) |
22:40:26 | * | Hideki_ joined #nim |
22:48:07 | disruptek | /home/adavidoff/git/gully/gully.nim(268, 11) Hint: quit() called [QuitCalled] |
22:48:13 | disruptek | but whyyyyyy |
22:48:50 | FromGitter | <Willyboar> Can i have a little help please? ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5db0d8d13d669b28a0c579ca] |
22:49:36 | disruptek | again? |
22:49:44 | disruptek | because `return` is the crash operator. |
22:49:59 | FromGitter | <Willyboar> :) i didnt make it |
22:50:04 | disruptek | it crashes the compiler at top-level, and it crashes your procedure should it occur therein. |
22:51:21 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
22:53:21 | mipri | in with return? You mean if `echo d` is replaced with `return d`? obviously once it returns, the rest of the loop doesn't happen. |
22:53:31 | mipri | try `result &= d` |
22:54:32 | dom96 | narimiran[m], Araq: I hope you will forgive me for this: https://nim-lang.org/blog/2019/10/23/version-102-released.html |
22:55:33 | FromGitter | <Willyboar> @mipri it seems is working |
22:55:48 | FromGitter | <Willyboar> you are the best thank you |
22:56:01 | FromGitter | <Willyboar> @disruptek thanks you too |
22:56:45 | disruptek | oh no, you're not blaming _me_ for that code. |
22:57:10 | * | Hideki_ quit (Remote host closed the connection) |
22:57:55 | * | Hideki_ joined #nim |
22:59:13 | * | Hideki_ quit (Remote host closed the connection) |
22:59:27 | * | Hideki_ joined #nim |
22:59:40 | rayman22201 | I think it looks good @dom96 👍 |
22:59:50 | dom96 | rayman22201, thx <3 |
23:00:09 | rayman22201 | someone has to do the marketing around here :-P |
23:00:44 | * | Hideki_ quit (Remote host closed the connection) |
23:01:20 | * | Hideki_ joined #nim |
23:02:31 | disruptek | none of my nim 1.0.1 code is working since updating to 1.0.2. 🤔 |
23:03:16 | disruptek | /home/adavidoff/git/gully/gully.nim(327, 28) Error: string literal must be of some string type |
23:03:27 | disruptek | result.add Footer, "]#", "footer", |
23:03:46 | disruptek | i'm chock-a-block with string literals here, people. |
23:04:53 | * | brainproxy joined #nim |
23:06:16 | * | Hideki_ quit (Ping timeout: 268 seconds) |
23:10:36 | * | brainproxy quit (Ping timeout: 265 seconds) |
23:18:04 | FromDiscord | <Kiori Sün> Hi there, I'm looking into Nim for JS deving, I would need it to be able to import js modules(ideally), and do code splitting in some term. |
23:18:04 | FromDiscord | <Kiori Sün> Currently i use typescript+parcel. It doesn't seem Nim has the required features for my non SPA use case. Also I've read somewhere in the forums that the js code Nim outputs isn't optimizable by the JIT, but it was an old post somewhere. |
23:18:04 | FromDiscord | <Kiori Sün> Does anyone has a good experience with Nim in JS-Land? |
23:19:21 | * | krux02_ joined #nim |
23:22:51 | * | krux02 quit (Ping timeout: 240 seconds) |
23:23:14 | stefantalpalaru | Why would any JS code not be JIT-able? I don't think that's a thing. |
23:27:22 | mipri | https://v8.dev/blog/elements-kinds#avoid-reading-beyond-the-length-of-the-array f.e. |
23:27:29 | FromDiscord | <Kiori Sün> Depending on how it's written the vm might not be able to identify hot code paths, etc |
23:28:00 | FromDiscord | <Kiori Sün> i don't remember the specifics of the post, I'm just passing on what i read. and i don't know about the quality of the output code |
23:29:07 | FromDiscord | <Kiori Sün> one of my main concerns that i seem to find no info on is code-splitting with nim. Seems impossible. I'm not sure about the using JS modules situation. |
23:34:46 | * | Hideki_ joined #nim |
23:38:59 | * | brainproxy joined #nim |
23:49:14 | * | Hideki_ quit (Ping timeout: 240 seconds) |
23:57:17 | rayman22201 | It's not impossible, but it's not "well supported" either. code splitting is a lot like dlls. (the JS world re-inventing the wheel yet again...) |
23:58:40 | rayman22201 | You have to compile each module that you want to "split" separately, and then use something like this to stich it back together when needed: https://github.com/filamentgroup/loadJS |