00:12 sena_kun joined 00:14 Altai-man_ left 02:12 Altai-man_ joined 02:14 sena_kun left 02:15 MasterDuke left 04:13 sena_kun joined 04:14 Altai-man_ left 05:07 vrurg left 05:08 vrurg joined 05:15 Kaiepi left 05:32 Kaiepi joined 06:12 Altai-man_ joined 06:14 sena_kun left 06:44 patrickb joined 06:54 domidumont joined
Geth problem-solving: antoniogamiz++ created pull request #216:
Add first draft of URL specification, refs #93		 07:27
07:27 leont joined 08:02 ccamel joined 08:03 camelCaser left 08:13 sena_kun joined 08:14 Altai-man_ left 08:29 MasterDuke joined 09:13 MasterDuke left 10:12 Altai-man_ joined 10:14 sena_kun left 10:17 MasterDuke joined 12:18 brrt joined
nine With regards to the new ecosystem proposal: at its heart CPAN is just a mirror system - and one that works really well. What sucks about it is the prolonged registration process including manual review. That's just out of date, isn't it? 12:37
Well is it? In Raku it's super easy to pick up where someone else left and publish a new version of a dist under a different auth. That also makes it super easy to hijack an ecosystem. Just publish a higher version of a common module under your auth and everyone will install it as we're too lazy to state what exact version we want. 12:38
Right now the manual registration is really the only measure we have against this. The only reason this has not become a problem so far is our relative obscurity. 12:39
If we want to stick with CPAN we could also completely side step PAUSE if we want. In the same move we could work around the :auth and :ver issue (as far as they even exist - CPAN stores files in author's directories and tar balls are versioned). 12:42
We could simply provide our own upload service that puts all Raku module in a single CPAN user's directory. The file names we us don't have to be fit for human consumption (yes that's me suggesting SHAs again).
I don't think anything prevents us from storing the eco system index on CPAN as well. CPAN does have a rule that files must not be changed once uploaded. But we can simply version this file (and delete older versions) so you'd just have to do 2 web request instead of 1 (first get the file list, then load the newest index file) 12:44
brrt ... well, stupid question is, how do other folks do it? 12:47
I know go just has everybody publish under their 'own' url (most of which are probably github's, really)
lizmat nine: I think the ecosystem hijackability is mostly caused by laziness of the ecosystem users 12:49
old habits die hard
nine Not even I do this correctly
lizmat but really, you shouldn't say "use Discogs::API", but really "use Discogs::API:ver<0.0.1>:auth<cpan:ELIZABETH>"
I know, and for development, that's fine 12:50
but production code *should* really specify what they need
this will also ensure that production code is not prone to module update induced failures
which is what makes maintaining Perl installations such a pain 12:51
brrt ok, so the first question that you're going to be asked is going to be, 'why isn't that in a version_lock YAML file?' 12:52
lizmat perhaps we need a pragma that would enforce full specification of dependencies
'use fully-specified-dependencies-only'
then test your application with -Mfully-specified-dependencies-only and see where it breaks 12:53
leont Anyone enabling that pragma probably already declares full versions
lizmat true, but it could be a test before putting into production: add -Mfully-specified-dependencies-only and see if it can run the tests 12:54
if people don't have tests, well, then they're flying blind anyway
brrt hmm, it's a good idea 12:55
user-centric thinking, I'd go so far as to say we should have a `raku --publish` option 12:56
and we'd start by doing just that check
leont Yeah, a release test may be a good idea
brrt: I'm always scared with more YAML dependencies, because that probably means my YAMLish module :-p 12:57
lizmat what does this have to do with YAML ?
brrt YAML 'version lock' files is how most other language tooling does it? 12:58
leont lizmat: just a detail he mentioned
brrt JSON is also possible
leont JSON is terrible for human beings. YAML, much like Raku, puts all the pain at the implementor
nine A simple text file with one dependency per line would be totally fine 13:02
Anyway the format is beside the point. It's about declare exact dependencies in your code vs. some meta data (like... META6.json!) 13:03
The reason why others use a meta data file is because they auto generate it 13:04
The reason why I'm reluctant to put an :auth on my use statements is that this completely destroys the feature that my user can swap in a different implementation (e.g. because a maintainer went AWOL or someone needs an internal patch) 13:05
lizmat nine: not true, if we implement supersede 13:07
design.raku.org/S22.html#supersedes 13:08
also: design.raku.org/S22.html#emulates 13:10
13:13 sena_kun joined 13:14 Altai-man_ left 13:20 domidumont left
jdv79 in addition to what i said in my comment on the proposal - exactly what is motivating this? 14:15
i don't see droves of people in #raku or elsewhere lamenting the existing stuff
ugexe if we wait for droves of people to lament we wouldnt even be using cpan 14:41
[Coke] I think it's reasonable to address these issues *before* we get a complaining userbase. 14:43
brrt on the other hand, raku community has a ... history of pre-overengineering, mabye? 14:47
*maybe
ugexe its just a difficult problem space given the raku spec. i think people think e.g."just make a simple file system mirror" yet how is that supposed to deal with all the filesystem stuff CUR does like case sensitivity or unicode? 14:49
live by sha1 die by sha1 14:50
14:50 brrt left 14:51 brrt joined
[Tux] Rakudo version 2020.07-48-g17f7f156a - MoarVM version 2020.07-12-g0a06f80c7
csv-ip5xs0.859 - 0.890
csv-ip5xs-207.930 - 8.931
csv-parser23.874 - 27.901
csv-test-xs-200.388 - 0.396
test7.836 - 8.495
test-t1.882 - 2.025
test-t --race0.839 - 0.890
test-t-2032.621 - 34.027
test-t-20 --race8.746 - 9.010
 15:15
[Coke] ugexe: how goes?
I only ever talk to you when I have a bug, figured I'd just say hi. :) 15:16
15:25 lichtkind joined
patrickb how would I go about hunting a 'Cannot invoke this object (REPR: Null; VMNull)' during the rakudo build? 15:25
the line before reads 'Compiling gen/moar/stage1/QAST.moarvm'
it's in nqp, not rakudo 15:26
MasterDuke patrickb: run it in gdb and break on MVM_exception_throw_adhoc? 15:30
patrickb will give it a try. That's a first for me...
OK. It's interpreting src/vm/moar/stage0/nqp.moarvm and tries to do an `invoke_v`. Assumingly with null arguments. 15:57
That seems like a dead end, because I didn't change stage0 at all. 15:58
16:12 Altai-man_ joined 16:14 sena_kun left
ugexe [Coke]: trying to tie up $work loose ends before I have to use this expiring pto 16:45
17:12 domidumont joined 17:24 toddr left 17:27 brrt left 17:38 patrickb left 17:43 domidumont left 17:55 lucasb joined 18:13 sena_kun joined 18:14 Altai-man_ left
[Coke] mmm, definitely take advantage of PTO. 18:23
19:39 brrt joined 19:45 toddr joined 20:12 Altai-man_ joined 20:14 sena_kun left 20:39 brrt left 21:22 lichtkind left 22:12 sena_kun joined 22:14 Altai-man_ left 22:33 leont left 22:38 Kaiepi left 22:41 Kaiepi joined
Geth rakudo: 1b5f6b98f4 | (Vadim Belman)++ | src/core.c/Attribute.pm6
Don't use higher-level `declares_method` method

It makes Attribute incompatible with Metamodel and other NQP classes via a mixin.
  `can` is to be avoided too because KnowHOW doesn't have it.		 23:24
rakudo: 9e51d01b93 | (Vadim Belman)++ | src/core.c/Exception.pm6
Fix exception code for KnowHOW compatibility

In a rare case the exception can be thrown for a KnowHOW type object or instance. The problem is that method `methods` of KnowHOW returns not a list of code objects but the method table itself in a hash form.
rakudo: d8f0507de6 | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #3834 from vrurg/roast_657_attr_fix

Partial fix of mixing in a role with attributes into a NQP class

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!