|
Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec Set by moderator on 3 May 2016. |
|||
|
01:48
ilbot3 joined
|
|||
| moderator | Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec | ||
|
05:32
domidumont joined
05:37
domidumont joined
05:58
TimToady joined
06:02
domidumont joined
06:04
domidumont joined
06:31
lizmat joined
07:06
domidumont joined
08:16
lizmat joined
08:18
domidumont joined
09:54
domidumont joined
12:58
sufrostico joined
|
|||
| [Coke] | still getting panda failures trying to install things at $dayjob. | 13:12 | |
| also, panda doesn't like it if you cancel out of something and end up with an empty projects.json file. | |||
| gist.github.com/coke/547e2d778f34e...ae547eaae3 | 13:13 | ||
| Is there a way to tell panda to not use git:// ? | 13:15 | ||
| (we shouldn't be encouraging people to use the git:// protocol, I think. Our default should be ssh or http(s)) | |||
| (ditto for rakudobrew) | |||
| ah, same thing. just not listed in the --help. | 13:16 | ||
| yay | 13:17 | ||
| stmuk | I think rakudobrew is a developer tool and can use git but panda should use http(s) to be useable behind broken corporate firewalls | 13:18 | |
| jdv79 | [Coke]: how many years has that been true? :) | 13:37 | |
| [Coke] | jdv79: what in particular? | ||
| jdv79 | having trouble installing sruff at work | 13:39 | |
| MadcapJake | nine_: any thoughts on how I should go forward? I'll continue my current route if you think it's alright or I can backtrack a bit and go the full directory-based route (wherein I will need some guidance as to naming and how to get that name when needing) | 13:42 | |
| [Coke] | Since well before Christmas. | ||
| nine_ | MadcapJake: I still think in the long term the directory-base approach is better. But I'm fine with a first implementation that's easier and which later on gets adapted. | 14:13 | |
| MadcapJake: though I don't think the directory thing is much more complicated. Remember: if all you need to store is a name, you can just as well use empty files and work with the dir() results | 14:14 | ||
| MadcapJake | nine_: but how would you implement fuzzy version/auth matching if we sha1'd the filename? | 14:19 | |
|
14:25
perlpilot_ joined
14:27
perlpilot joined
14:44
perlpilot_ joined
|
|||
| ugexe | you store the CUR::DepSpec and sha1 together, then fuzzy match on the DepSpec | 15:39 | |
| MadcapJake | ugexe: where? Inside the file? | 15:40 | |
| ugexe | you need a manifest somewhere | ||
| MadcapJake | but then I could just stick with the single-file per short-id | 15:41 | |
| ugexe | for each short-id file, if thats how you are doing it, would act as such a manifest | ||
| jdv79 | is there a doc explaining the current state of things? i've been away for a while. | 15:42 | |
| ugexe | each line (or each 3 lines, whatever) represent a single DepSpec | ||
| MadcapJake | ugexe: yeah that's what I'm currently doing but nine_ is in the directory per short-id camp and I'm just not seeing the whole picture for that design | 15:43 | |
| ugexe | so maybe each line in short-id has something like '0.0.1\\0github:foo\\01.2\\0<sha1 or entire path>' | ||
| if you want a directory per short-id you probably treat it like ipfs and use like sha1(short-id) ~ '/' sha1(dep-spec without short-id) | 15:45 | ||
| ah but that removes the fuzzy search... i see | |||
| MadcapJake | right | ||
| that's where my confusion lies | 15:46 | ||
| ugexe | he has been talking about doing something with DepSpec and EVAL, so i suspect he has a plan | ||
| jdv79: i'm not sure much has changed besides nine's commits which are probably mostly transparent to the end user. precomp to ~/.perl6 is supposed to better i think | 15:47 | ||
| i guess for fuzzyness it would have to recurse through those directories to find the first DepSpec (which will have to be stored *somewhere*) that matches | 15:49 | ||
| but if you are using fuzzy stuff like that in your code (use XXX:ver(* > 1.0)) instead of a concrete version then the associated slowdown would be acceptable | 15:50 | ||
| while still letting concrete versions be discovered without hitting the file system a bunch of times | 15:51 | ||
| jdv79 | ugexe: cool | 15:53 | |
| nine_ | MadcapJake: what exactly do you want to fuzzy match? | ||
| ugexe | nine_: is there a way to better invalidate precomps in lib/.precomp and/or ~/.perl6 when using something with `version: '*'`? I'm getting bitten by old precomp code more and more, and im not sure if its related to installs or from running via FileSystem (perl6 -Ilib bin/xxx) | 15:54 | |
| nine_ | ugexe: MadcapJake++ is working on registering custom repo implementations, i.e. the 'gx' -> CompUnit::Repository::Gx lookup. So there is not much user input in the first place besides the short-id | ||
| ugexe | by fuzzy match i think he means `find module Foo::Bar where version > 1.2` | 15:56 | |
| nine_ | ugexe: are you sure it's outdated precomp files and not outdated distributions? | ||
| ugexe | nine_: yes, positive | ||
| MadcapJake | I want to allow people to do `use CompUnit::Repository::GX:ver<1.2.*> and it will translate into gx#ver<1.2.*>#/path/to/gx/repos which will get fuzzy-matched by CURI against any repo that implements the `gx` short-id | ||
| nine_ | Because outdated precomp files usually lead to all kinds of "funny" error messages, not just old versions being used. | ||
| ugexe | Its definately precomp. It happens with zef for instance, which has 0 dependencies | 15:57 | |
| but it does dynamically load plugins, which might complicate the process | 15:58 | ||
| nine_ | ugexe: what kind of errors do you see? | ||
| ugexe | nine_: no errors. i changed a single line and reran it, but it continues to show the old output until I delete the precomp directories | 15:59 | |
| nine_ | ugexe: on what file system? | ||
| ugexe | ext4 i believe | 16:00 | |
| nine_ | Is this something that started this week or has it been there longer? | 16:01 | |
| ugexe | i can't really say, i suspect its been around longer but I did not pay it much attention. fwiw i *have* gotten the error messages you've mentioned before, but thats not the case for this | 16:02 | |
| my gut tells me its related to this type of stuff tho: (try require ::($ = $module)) | 16:03 | ||
| where $module ends up loaded the old precomp | 16:04 | ||
| the old precomp of something *it* uses that is | |||
| i really just need to know what i should be looking for in RAKUDO_MODULE_DEBUG so next time I can put some more details together | 16:06 | ||
| the reason i suspect the try require bit is because something like this used to happen with Net::HTTP regarding dynamically loading IO::Socket::SSL (although I cant say for certain it really is the same) | 16:09 | ||
| a description of one such encounter is documented in the last comment here: github.com/ugexe/zef/issues/86 | 16:14 | ||
|
17:26
domidumont joined
17:54
hankache joined
18:34
perlpilot joined
19:25
Kassandry joined
23:15
sufrostico joined
|
|||