sjn | tonyo: can the resolution speed somehow be made "ok" with a index format that is in a text (human-editable) format? Having an easy-to understand format can make a _huge_ difference when it comes to making it easy for new people to contribute and/or troubleshoot... | 00:01 | |
(this is especially true if there's an ambition to make the raku.land locally deployable (e.g. for managing business-internal packages)) | 00:03 | ||
00:46
Nemokosch joined
|
|||
Nemokosch | Hi, something else: I think the version selection on the page of a dist is broken | 00:47 | |
raku.land/zef:lizmat/DirHandle take this dist for example | 00:48 | ||
0.0.8 is preselected. Open it, select 0.0.7. It will appear as selected but 0.0.8 will still be disabled from selection and it will still have the "selected" attribute in the HTML... | |||
and you will never be able to make it show | |||
in fact, you don't even have to select the previous version, it's enough to open the drop-down and hover the previous one for a brief moment | 00:50 | ||
00:53
Nemokosch left
00:54
Nemokosch joined
|
|||
Nemokosch | uh, wait... is this the actual UX? :D | 00:54 | |
if one clicks "Go", the selection changes... can't be coincidental, right? 😅 | 00:55 | ||
Then what can I say, I find it unintuitive. Why would you require an extra button only the update the selection of a dropdown. | 00:56 | ||
I thought it would trigger the download. But there is a separate link for the download, and that link doesn't even change for some modules, regardless the version (maybe CPAN being the common theme) | 00:58 | ||
00:58
Nemokosch left
|
|||
jjatria | I seem to remember there was a reason we had to go with the compromise of requiring an additional "Go" click, but we'd welcome anyone coming up with a better solution. I cannot find that reason if it ever existed, though... | 11:41 | |
What modules are you thinking of? I can see the download link update appropriately in the CPAN version of HTTP::Tiny, for example: raku.land/cpan:JJATRIA/HTTP::Tiny | 11:42 | ||
JRaspass | The alternative would be to require javascript, atm it's just a simple form, nothing complicated | 13:58 | |
tonyo | sjn: it can be converted to human readable format using the module | 17:19 | |
zef eco is also capable of being a private repository for organizations | 17:20 | ||
and then be indexed by private instances of RL without any modification or special handling in RL aside from an API key being provided to the endpoint | |||
if you know of an org that would like a private auth please let me know and i will work with them on configuring it/setting it up | 17:22 | ||
sjn is a little frustrated about the increased use of opaque file formats for keeping track of information that doesn't _need_ to be it... :-| | 17:39 | ||
lizmat | sjn zef performance is to a great extent affected by the JSON file format used currently, so there is a need | 17:46 | |
sjn | what bottlenecks has profiling revealed? | 17:54 | |
tonyo | the time to search and resolve is directly tied to the size of the JSON blob zef receives | 17:55 | |
sjn | sure, as expected. though that's not what I asked about :) | ||
tonyo | so it's slow right now, 3500 modules, every time that number doubles so does the parsing. the bottleneck is json parsing | 17:56 | |
lizmat | tonyo: you're aware of raku.land/zef:lizmat/JSON::Fast::Hyper ? | ||
tonyo | i am but it effectively needs to use whatever is in core to avoid problems with what zef thinks vs what rakudo internals | 17:57 | |
sjn | to me "it's slow" is still a good enough reason to take another hard look at what's taking time in the language to see if it can be sped up somehow :) | 17:58 | |
tonyo | so if we can put that in core then it may bide us some time until the format is needed | ||
sjn: there's been a lot of eyes on the json parser, it's currently written in nqp | |||
sjn: converting the index to a human readable format is trivial in this case, i'm not sure what the resistance is about but am open to more discussion of it | 18:25 | ||
lizmat | tonyo: fwiw, there's no resistance from me as long as there's an API for it | 18:29 | |
tonyo | thank you lizmat | 18:30 | |
JRaspass | likewise | 21:44 | |
21:47
Nemokosch joined
|
|||
Nemokosch | I also think the demand to move away from the "current API" (ie. a huge monolithic JSON file exposed) is very much justified | 21:48 | |
I suppose it's a main reason why a `zef search` or any sort of module resolution is so slow | 21:50 | ||
and whenever I want to quickly check if a dist got uploaded indeed, it's not the most convenient API to work with anyway | 21:51 | ||
for the wrong archives - honestly, when I saw it, I didn't assume it was a very specific thing. Now, I don't see anything similar. I guess it cannot be such a big thing, then. | 21:56 | ||
(It was already after the realization that one has to press the "Go" button, as much as I can recall) | 21:57 | ||
21:57
Nemokosch left
|