Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2014-01-10

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:48 klapperl joined #metacpan
04:32 preflex_ joined #metacpan
04:55 ralesk_ joined #metacpan
06:24 [Sno] joined #metacpan
06:47 ether_ joined #metacpan
07:51 dpetrov_ joined #metacpan
10:02 b_jonas joined #metacpan
10:04 b_jonas hi. in the page https://metacpan.org/release/RJBS/perl-5.18.0 , the select box lists entries like "5.018001 DEV (RJBS on 2013-08-04)". could you change this to display the full version number, such as "perl-5.18.1-RC2 DEV (RJBS on 2013-08-04)" please?
10:04 dipsy [ perl-5.18.0 - The Perl 5 language interpreter - metacpan.org - Perl programming language ]
10:41 dolmen joined #metacpan
11:06 bowtie_ joined #metacpan
13:41 thaljef joined #metacpan
13:48 jayallen joined #metacpan
13:54 oalders b_jonas: could you add that to the wish list? https://github.com/CPAN-API/cpan-api/wiki/Wishlist
13:54 dipsy [ Wishlist · CPAN-API/cpan-api Wiki · GitHub ]
14:01 b_jonas oalders: let me try. I'll create a github account.
14:01 oalders :)
14:02 BinGOs I noticed that yesterday and WTF'd
14:02 b_jonas BinGOs: I think it's changed at least twice
14:02 b_jonas but I can't prove that
14:03 BinGOs I was letting them sort out their SSL cert woes before adding more pain.
14:05 thaljef *wishes the metacpan site would indicate if a module is in the Perl core*
14:06 thaljef *also wishes all core modules had a common namespace prefix.  but that's another story*
14:06 jayallen_ joined #metacpan
14:08 b_jonas ah, I found a similar report: https://github.com/CPAN-API/metacpan-web/issues/950
14:08 dipsy [ "Go to version" drop-down shows incorrect version number · Issue #950 · CPAN-API/metacpan-web · GitHub ]
14:08 b_jonas that was before the two changes
14:08 oalders i think there was an issue for core modules. if that's not on the wish list, it should be added
14:08 b_jonas hmm no, that's different
14:12 b_jonas done
14:14 oalders b_jonas++
14:14 BinGOs core in which perl would be one issue
14:16 BinGOs "This module became a core module at version <bleh> in perl <blah> and left core at perl <bloh>"
17:27 [Sno] joined #metacpan
17:40 ether thaljef: the in-core status is a bit tricky, because it's not a simple boolean. modules can enter and leave core in different perl versions, and sometimes more than once
17:40 ether e.g. Time::Piece, the groundhog module
17:40 ether thaljef: what would you use such an in-core status for?
17:42 thaljef ether: when shopping around for modules that do X, I would probably give preference to one that is in core (for example).
17:42 b_jonas good idea, but first let's remove Net::Ftp from core
17:43 ether a module's in-core status doesn't really say anything about its feature set, or even its level of maintenance
17:43 ether and I hate to say, its quality
17:44 ether e.g. one thing Path::Tiny does well is remove unnecessary calls to File::Spec
17:44 thaljef I understand.  But it says something about its availability in the target environment.  As you can imagine, I think about dependencies a lot.
17:44 ether so I'd always use Path::Tiny ahead of File::Temp, File::Spec, File::Copy etc directly
17:45 ether I'd be interested in seeing a report for all dists: "number of degrees away from core"
17:46 ether i.e. how many layers of dependencies do you have before all trails end with a core module
17:46 ether Path::Tiny is degree 1, as it checks in its build process that all deps are in core
17:46 thaljef what would that tell you?
17:46 thaljef (just asking)
17:47 ether well you just said you were concerned about availability, and dependencies in general...
17:48 ether maybe I can convince neilb to be interested in such a report ;)
17:49 trs reporting if a module is core or not would be pretty easy given Module::CoreList
17:49 ether trs: given what version of perl, though?
17:49 ether MCL needs that as an input, or you just get a range of versions that it was in core in.
17:49 thaljef Oh, now I see.  I was only thinking of degree 0 and degree > 0.  But yes, that would be an interesting metric.
17:50 trs ether: I think it'd be simplest just to show the range of versions
17:50 trs rather than require the user to pick a perl version
17:51 ether *nod*
17:53 thaljef AFAIK, only recently have modules been removed from core.  So for the first pass, I'd be happy with just "In core since..."
18:12 ether there have been removals in the past too
18:34 chansen ether: when did Time::Piece leave core? I was under the impression that it has been in core since 5.10
18:37 ether it was in core before that as well, in the 5.6 era, and then left
18:38 chansen ahh
18:40 BinGOs Time::Piece got added during v5.7.* and removed during v5.7.* again
18:40 BinGOs before being finally included in v5.10.0
18:59 trs thaljef: Module::CoreList has a removed_from method, so finding when it was removed should be easy
19:01 trs thaljef: it's things like correctly representing Time::Piece that might be difficult
19:02 trs but as a first pass simply saying "Module X was in core perl from version 5.a.b (to 5.c.d)?"
19:02 trs should be straightforward
19:02 thaljef That would certainly make me smile.
19:03 thaljef Maybe I'll finally try hacking on MetaCPAN for this.
19:03 trs bonus points if the logic which summarizes the version range makes sure it's continuous :)
19:03 trs thaljef: you should! it's fun :)
19:03 * BinGOs sighs.
19:03 BinGOs I said this 5 hours ago
19:04 trs BinGOs: yeah, I know.
19:05 BinGOs I'm just slightly grumpy, because I am trying to extract the 'demonstration' batteries out of something to put in ones that work
19:06 trs heh
19:07 BinGOs and possibly I am suffering from CPAN upload withdrawal
19:09 trs I feel sorry for Robrt and Ask...
19:09 * ether nodnods
19:10 trs it's never good when "several" drives fail at once
19:11 chansen I started out grumpy this morning. I started my hacking session trying to convince my C compiler that "my int foo" is a valid C expression, then a client wants me to hack a date/time parser in c without a clear specification of which dates/times that should be supported. SIGH!!
19:15 ether I'm trying to talk to Product people who don't understand how sql works
19:16 ether you can't make things have a 1:1 relationship if they are 1:N! using smaller words doesn't mean I can make it work for you.
19:30 chansen Yeah, trying to convince non-technical persons of technical matters can be a challenge :/
19:33 * chansen took a few single malts after work, life seems better now ;)
19:35 b_jonas chansen: spawn a perl, load Date::Manip, parse dates with that?
19:35 b_jonas left #metacpan
19:35 dpetrov_ joined #metacpan
19:36 chansen How am I supposed to respond when he left the channel?
19:37 ranguard thaljef: https://github.com/CPAN-API/metacpan-developer will help get you started :)
19:37 dipsy [ CPAN-API/metacpan-developer · GitHub ]
19:38 b_jonas joined #metacpan
19:40 chansen b_jonas: the single reason is performance
19:41 b_jonas does it have to be very fast? if you use a persistent perl to parse all dates that come up, is that fast enough? I know Date::Manip isn't very fast.
19:42 trs DPaaS - Date Parsing as a Service
19:43 b_jonas it could be either in a separate process or linked together, whichever you prefer
19:43 chansen b_jonas:  and less ambiguity, after my persuasion (big requirement from my side)
19:47 chansen here is the full story, I have developed a ISO 8601 compliant parser in c (which accepts all ISO 8601 formats) with an optional lenient mode, and it's fast, much faster than strptime (assuming you know the exact ISO 8601 format), and know the client wants a faster generic parser for non ISO formats
20:44 dpetrov_ joined #metacpan
22:26 bowtie_ joined #metacpan
22:50 nbezzala joined #metacpan

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary