Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #perl6-toolchain
01:48 Topic for #perl6-toolchain is now Fire is step THREE! | https://github.com/perl6/toolchain-bikeshed | Channel logs: http://irclog.perlgeek.de/perl6-toolchain/today | useful prior art: https://metacpan.org/pod/CPAN::Meta::Spec
05:32 domidumont joined #perl6-toolchain
05:37 domidumont joined #perl6-toolchain
05:58 TimToady joined #perl6-toolchain
06:02 domidumont joined #perl6-toolchain
06:04 domidumont joined #perl6-toolchain
06:31 lizmat joined #perl6-toolchain
07:06 domidumont joined #perl6-toolchain
08:16 lizmat joined #perl6-toolchain
08:18 domidumont joined #perl6-toolchain
09:54 domidumont joined #perl6-toolchain
12:58 sufrostico joined #perl6-toolchain
13:12 [Coke] still getting panda failures trying to install things at $dayjob.
13:12 [Coke] also, panda doesn't like it if you cancel out of something and end up with an empty projects.json file.
13:13 [Coke] https://gist.github.com/coke/547e2d778f34e1f20d1376ae547eaae3
13:15 [Coke] Is there a way to tell panda to not use git:// ?
13:15 [Coke] (we shouldn't be encouraging people to use the git:// protocol, I think. Our default should be ssh or http(s))
13:15 [Coke] (ditto for rakudobrew)
13:16 [Coke] ah, same thing. just not listed in the --help.
13:17 [Coke] yay
13:18 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:37 jdv79 [Coke]: how many years has that been true? :)
13:37 [Coke] jdv79: what in particular?
13:39 jdv79 having trouble installing sruff at work
13:42 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.
14:13 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:14 nine_ 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:19 MadcapJake nine_: but how would you implement fuzzy version/auth matching if we sha1'd the filename?
14:25 perlpilot_ joined #perl6-toolchain
14:27 perlpilot joined #perl6-toolchain
14:44 perlpilot_ joined #perl6-toolchain
15:39 ugexe you store the CUR::DepSpec and sha1 together, then fuzzy match on the DepSpec
15:40 MadcapJake ugexe: where? Inside the file?
15:40 ugexe you need a manifest somewhere
15:41 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
15:42 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
15:43 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>'
15:45 ugexe 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 ugexe ah but that removes the fuzzy search... i see
15:45 MadcapJake right
15:46 MadcapJake 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
15:47 ugexe 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:49 ugexe 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:50 ugexe 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:51 ugexe while still letting concrete versions be discovered without hitting the file system a bunch of times
15:53 jdv79 ugexe: cool
15:53 nine_ MadcapJake: what exactly do you want to fuzzy match?
15:54 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
15:56 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?
15:56 ugexe nine_: yes, positive
15:56 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
15:56 nine_ Because outdated precomp files usually lead to all kinds of "funny" error messages, not just old versions being used.
15:57 ugexe Its definately precomp. It happens with zef for instance, which has 0 dependencies
15:58 ugexe but it does dynamically load plugins, which might complicate the process
15:58 nine_ ugexe: what kind of errors do you see?
15:59 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?
16:00 ugexe ext4 i believe
16:01 nine_ Is this something that started this week or has it been there longer?
16:02 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:03 ugexe my gut tells me its related to this type of stuff tho: (try require ::($ = $module))
16:04 ugexe where $module ends up loaded the old precomp
16:04 ugexe the old precomp of something *it* uses that is
16:06 ugexe 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:09 ugexe 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:14 ugexe a description of one such encounter is documented in the last comment here: https://github.com/ugexe/zef/issues/86
17:26 domidumont joined #perl6-toolchain
17:54 hankache joined #perl6-toolchain
18:34 perlpilot joined #perl6-toolchain
19:25 Kassandry joined #perl6-toolchain
23:15 sufrostico joined #perl6-toolchain

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