Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-05-02

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
05:53 domidumont joined #perl6-toolchain
05:58 domidumont joined #perl6-toolchain
06:06 domidumont joined #perl6-toolchain
06:36 domidumont joined #perl6-toolchain
06:49 MadcapJake Ok didn't get as far as I'd hoped.  Here's my (not yet working) progress: https://github.com/MadcapJake/rakudo/commit/669a9cd91054b27be97bb5fe12e9f3bcde94c535
08:00 domidumont joined #perl6-toolchain
08:31 jdv79 joined #perl6-toolchain
08:36 domidumont joined #perl6-toolchain
10:37 JimmyZ joined #perl6-toolchain
11:09 domidumont joined #perl6-toolchain
12:06 domidumont joined #perl6-toolchain
13:09 sufrostico joined #perl6-toolchain
13:36 sufrostico joined #perl6-toolchain
14:01 domidumont1 joined #perl6-toolchain
15:15 [Coke]_ joined #perl6-toolchain
15:19 Brock joined #perl6-toolchain
15:20 hoelzro_ joined #perl6-toolchain
15:20 sufrosti1o joined #perl6-toolchain
15:24 JimmyZ joined #perl6-toolchain
16:11 MadcapJake nine_: I'm not sure I understand what you mean by the second option "before removing the file, check if any other module would provide the same short-id"
16:12 nine_ MadcapJake: right now, you just remove the file, even if there would be other modules (or versions of your module) that provide an implementation.
16:13 nine_ MadcapJake: my suggestion is to check if there are other modules that do that and if there are just not delete the file yet
16:16 MadcapJake ahh yeah I see, I like that option but I'd need to check the short/ for another module with that short-name, right?
16:18 nine_ Considering the packaging issues, I'd actually prefer option 1
16:22 MadcapJake alriiiight ;)
16:27 [Coke]_ https://finanalyst.github.io/ModuleCitation/
16:27 [Coke]_ (list of modules that refer to other modules)
16:30 MadcapJake that's epic!
16:59 MadcapJake interesting how you can see JSON::Fast being used in favor of JSON::Tiny
17:08 tadzik joined #perl6-toolchain
17:36 domidumont joined #perl6-toolchain
17:45 [Coke] tadzik: I have one outstanding PR for rakudobrew, and two open issues - the biggest issue is that you added a second 'moar-bleed' backend, but there's no way to distinguish it from 'moar' for the user, so it's kind of confusing.
17:45 [Coke] Not sure if the right answer on that is to expose it as moar-blead more directly, or remove it.
17:50 Kassandry joined #perl6-toolchain
17:53 [Coke] looks like it was added 2 weeks ago: https://github.com/tadzik/rakudobrew/commit/309424c0
17:58 tadzik ouch
17:58 tadzik I added it at tux's request
17:58 tadzik yeah, name should be changed
17:59 tadzik that should do it
18:00 [Coke] thanks, closed the ticket.
18:02 [Coke] I opened about 3 more, though. :)
18:03 [Coke] I did do https://github.com/tadzik/rakudobrew/pull/90 if you want, though.
18:05 tadzik Merg'd, thanks :)
18:06 [Coke] #93 is because git protocol of git resolves to:
18:06 [Coke] git ls-remote --tags git://github.com/rakudo/rakudo.git
18:06 [Coke] but that should be:
18:06 [Coke] git ls-remote --tags git@github.com/rakudo/rakudo.git
18:06 [Coke] er:
18:06 [Coke] git ls-remote --tags git@github.com:rakudo/rakudo.git
18:07 [Coke] the latter is smart enough to use my ssh over https bridge. the first is trying to lookup github.com directly in DNS which isn't going to work here.
18:08 [Coke] I can fix that so if protocol is git, it uses @..: instead of ://.../ if you like. (and leaves it as is for anything non-git)
18:09 [Coke] (commented on #93)
18:09 tadzik ah
18:10 tadzik does git@github.com allow it to work with people who don't have a github account and ssh key though?
18:10 tadzik maybe https:// would be safer
18:11 [Coke] if they want https, they can ask for it already.
18:12 [Coke] with the undocumented GIT_PROTOCOL
18:12 [Coke] (which needs documenting, one sec, ticket coming. :)
18:21 cognominal joined #perl6-toolchain
18:27 [Coke] tadzik: pretty sure it works if your project is public.
18:28 [Coke] (we have issues with private repos using github enterprise, but I would be surprised if they happened on public repos @github.com) - it's easy to test though, you can move your key out of the way.
18:36 MadcapJake nine_: I've set up the repository short-id subdir idea, but I can't decide which one will be chosen, traverse and pick the latest ver/api?
18:42 nine_ MadcapJake: that's....a good question. I thought we could let .need decide that but in this case there could even be different short-names
18:43 MadcapJake right, need needs a decision on the DepSpec and for that we'll need to make a decision on which file within that given short-id's dir we should use
18:44 MadcapJake (currently I'm just doing the same as short/, each file's name is the dist.id and the contents is a line-separated ver/auth/api)
18:45 nine_ Much complexity just to have short ids instead of full class names :/
18:47 perlpilot .oO( torturing developers on behalf of users ... )
18:49 MadcapJake I'm more worried about a performance hit than complexity
18:50 MadcapJake nine_: I think we have to remember that repositories won't be in the magnitude of modules so perhaps traversing (or even moving back to a single file model) would be better performance-wise?
18:53 MadcapJake If we returned to a single file model, on installation we could sort by version/api which would reduce the need for parsing to just the first line (then we'd need to allow users to specify an older version/api somehow)
18:56 nine_ That still dosn't answer the question: if both Foo and Bar implement a "baz" repository, which one do you load?
18:57 MadcapJake oh yeah :\
19:00 MadcapJake nine_: a new pragma e.g., `use repo :gx(CompUnit::Repository::GX);`
19:03 nine_ Or we just refuse to install Bar
19:06 MadcapJake that was my other thought but seems kind of limited. What if johnny wrote a repo for github with short-id 'gh' and linda wrote a "global home" repository with the same short-id, do we just tell johnny or linda to change? :)
19:11 MadcapJake Progress: https://github.com/MadcapJake/rakudo/commit/4f1ef9c052d44855b26d65304152c2840c42779c
19:13 nine_ Essentially that was the idea. It's like the scheme part of URIs.
19:53 MadcapJake so if we only allow one repo to a given short-id, I could revert back to single-files in the repositories directory, right?
20:22 pnu__ joined #perl6-toolchain
20:22 MadcapJake_ joined #perl6-toolchain
20:22 nine_ one module but different versions
20:27 MadcapJake_ what would be the point of supporting multiple versions of a repo though?
20:50 MadcapJake nine_: Let's say you install a new CUR, wouldn't you want it to replace the old CUR? What situation would you want to utilize a previous CUR version's api?
21:07 nine_ When you uninstall this CUR, wouldn't you want to utilize the older, still installed version?
21:07 nine_ Maybe that's the reason for uninstalling in the first place: the new version doesn't work right.
21:11 MadcapJake ok i can see that
21:13 perlpilot what does it mean to "version a CUR"?
21:16 MadcapJake well a CUR in that light would be just like any other module
21:16 MadcapJake this work I'm doing is wrt custom CURs
21:20 perlpilot just reading the last few lines here, I get the impression that you could use versioned CUR to implement a set of poor-man's local::lib sandboxes
21:21 MadcapJake not familiar with local::lib, could you elaborate?
21:21 mst http://p3rl.org/local::lib
21:22 MadcapJake doesn't perl 6 already have -Ilib and `use lib 'lib'` for this kind of purpose?
21:22 mst basically "about eight years ago, mst got bored of explaining how to get perl to install to and load from an extra directory tree on #perl and managed to boil it down to 4 env vars ... then wrote a module to generate them"
21:22 mst ...
21:22 mst no, those are equivalent to the perl5 -Ilib and 'use lib'
21:22 MadcapJake oh :P
21:22 mst shockingly enough
21:23 MadcapJake how are they different?
21:25 mst huh? -Ilib and 'use lib' affect @INC or equivalent
21:26 mst local::lib affects @INC, and $PATH, and the behaviour of module installation
21:26 mst did you read the docs for local::lib when I linked them? :(
21:26 MadcapJake mst: yep :) skipped the bootstrapping part though :P
21:26 mst that's ok
21:27 mst everybody does, then they complain they don't have local::lib installed already so clearly this is useless
21:27 MadcapJake I'm not a perl 5 programmer so this is a little hard for me to discern
21:27 mst ok, so, basically, PERL_MB_OPT and PERL_MM_OPT are specifying "which CUR to *install* into"
21:27 mst whereas @INC is "which CUR to *load* things from"
21:28 mst then the $PATH thing is because I don't have shim scripts and wanted something that was actually simple and debuggable by sysadmins
21:29 MadcapJake ok this is awesome, yes this is exactly what my custom CUR work would allow
21:29 perlpilot excellent
21:32 MadcapJake right now perl 6 has two CURs: filesystem (CURFS) and installation (CURI). CURFS doesn't have the means to install or uninstall and is how -Ilib and use lib work (seems like this is the same as Perl 5).  Whereas CURI uses a special filesystem database but allows installs and uninstalls (though you really can pick a location for this via RAKUDO_PREFIX)
21:33 MadcapJake (there are three other CURs actually, AbsPath, Perl5, and NQP)
21:35 MadcapJake anyways, I am working on a CUR for GX which is a language-agnostic package manager that utilizes the P2P IPFS protocol.
21:47 mst yeah, personally, I would like to have a read-only ::Installation and then a subclass that does the installs
21:47 mst and RAKUDO_PREFIX for CURLI is basically equivalent to the local::lib INSTALL_BASE bits
21:50 Kassandry joined #perl6-toolchain
21:54 mst MadcapJake: does that make local::lib make a bit more sense?
22:16 sufrostico joined #perl6-toolchain
23:08 lizmat joined #perl6-toolchain
23:33 lizmat_ joined #perl6-toolchain

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary