www.parrot.org/ | Parrot 1.4.0 "Mundo Cani" Released! | For 1.5: Remove Deprecated Features | Planet Parrot planet.parrotcode.org/
Set by moderator on 4 August 2009.
00:01 tetragon joined 00:02 whoppix joined 00:12 patspam joined 00:21 zak_ joined 00:45 Whiteknight joined 00:47 TiMBuS joined 00:48 satrac joined
Whiteknight I love running an svn up and having lots of files be updated! 00:50
it means things are changing!
cotto adds trailing null bytes to all files in svn 00:55
including the checked-in pbcs
Whiteknight whatever, that's fun to see too 00:56
Coke made a run through DEPRECATED.pod today, but most things are waiting for feedback. 01:09
01:10 eternaleye joined 01:27 ruoso left 01:34 kid51 joined 01:44 tetragon joined 01:57 Andy joined
dalek rrot: r40438 | allison++ | trunk/docs/project/debian_packaging_guide.pod:
[debian] Remove no-longer-used step from the Debian packaging guide.
 02:00
rrot: r40439 | allison++ | trunk/docs/project/ubuntu_packaging_guide.pod:
[ubuntu] Change to more common changelog entry.
02:04 Andy joined 02:06 petdance joined 02:08 petdance_ joined
treed bacek: Still here? 02:28
purl here is fine, wait until she looks at it
treed msg bacek Ah, thanks for the confirmation. I wonder why it stopped working: gist.github.com/163680 Your help is appreciated. 02:29
purl Message for bacek stored.
02:42 janus joined 02:43 theory joined 02:45 Andy joined 03:02 JimmyZ joined 03:26 dukeleto joined 03:42 wayland76 joined
dalek TT #905 created by allison++: [RFC] Deprecate Eval PMC 03:58
04:00 theory joined
bacek_at_work treed: ping 04:22
msg treed I'll fix parrot today-tomorrow so StringIterator.shift_pmc will work again. OTOH replacing ".local pmc item" with ".local string item" should work right now. And it's faster anyway. 04:24
purl Message for treed stored.
Coke if I clone a git repo that is a clone of an svn repo, what happens when I git svn dcommit? 04:25
chromatic I don't think it works. I could be wrong. 04:27
Coke I would think I'd have to 'git commit' and then have someone dcommit on the clone in the middle. 04:30
chromatic I agree. 04:31
Coke msg dukeleto you might want to clarify what's going to happen if someone clones your clone, in terms of dcommits.
purl Message for dukeleto stored.
dukeleto Coke: good point 04:38
Coke: i don't quite trust git-svn, so I have been using git to keep track of my work and then patching it onto a parrot svn repo. this is probably unfounded paranoia and I need to actually get my git-svn workflow working 04:39
chromatic If you thought Git's documentation was confusing... git-svn will abuse you. 04:41
dukeleto chromatic: indeed. the implementation will torment your
s/your/you/
Coke: if someone clones my clone, dcommiting will do nothing because my git repo knows nothing of the svn repo 04:46
05:09 tekky joined 05:39 Andy joined 05:41 TiMBuS joined 06:00 jhelwig joined 06:02 uniejo joined 06:12 he joined 06:17 uniejo joined
dukeleto woohoo, just fixed another bug in parrot_debugger. currently it gets a Bus error if you attempt to print string registers which have not come into existence yet 06:29
moritz dukeleto: maybe you should also post the relevant parts of your parrot/.git/config on the wiki 06:30
dukeleto: so that others know how to make git-svn work with it
dukeleto moritz: i am not quite sure that *I* know how to get git-svn to play nice, but I will try. currently I am using git to organize my work but I end up using "git diff --no-prefix" to generate a patch and just "patch" an up-to-date svn tree and commit directly with svn. but I am starting to feel comfortable with git-svn, so this will change 06:31
moritz dukeleto: I can do it, then 06:32
dukeleto moritz: that would be awesome
moritz: the thing that bothers me is that I would like to use git-svn with an svn branch and that seems to be very shaky ground 06:33
moritz dukeleto: I know that bacek++ does that successfully
dukeleto moritz: interesting. I would *really* like to know his workflow 06:34
moritz dukeleto: maybe we can convince him to share his experience on the wiki too
dukeleto moritz: as far as I can see, if I try to use git-svn on a repo that was not started with git-svn, nothing works. git-svn just hangs. other people tell me I am crazy and that it should work, but that is what I know right now. I have been meaning to right a test for git-svn, but I haven't gotten around to it... 06:35
moritz dukeleto: so it seems your parrot git-svn clone doesn't contain all the branches, right? 06:39
Tene++ made a clone that contains the branches, I could upload that to github 06:40
that would be even more awesome, I think
dukeleto moritz: git fetch will pull in all branches
moritz all the remote svn branches? 06:41
my clone is still running...
dukeleto moritz: my full git svn clone took over 3 days to finish
moritz I meant me cloning your git clone ;-) 06:42
dukeleto moritz: oh. yeah, it seems that I didn't push all the different branches to github, but I will attempt to fix that now. 06:43
moritz: just cloning my git repo should only be a few minutes
moritz right, finished
pushing all the branches would be great
dukeleto moritz: i will attempt to that. i think I may need to do it from the original physical repo that I used "git svn" on, which is on a different machine 06:44
moritz afaict there's no git command for pushing all branches, so you might need to iterate over .git/svn/origin/* or so 06:46
dukeleto moritz: interesting. i will attempt to do this when I have access to the machine tomorrow 06:47
moritz it seems that getting git-svn working on a cloned copy involves more than just adapting .git/config 06:52
Tene my parrot git-svn directory is 750M 07:02
that's with the compiled stuff too, though.
lemme realclean.
moritz Tene: there's one huge file in your .git/svn/ tree
Tene 666M after realclean. ;)
moritz Tene: it's 170M here (based on your tree) 07:03
Tene 514944\t.git/svn/vtable_morph_change@36392
07:03 wayland76 joined
Tene that one file is 503M 07:03
moritz it's not really worth shipping a 400M file with metadata that's only interesting in one particular branch
oh, 503 even ;-)
Tene What is it, I wonder? 07:04
moritz I don't know, but the repo seemed to work fine after removing it
pmichaud Good morning, #parrot 07:28
07:32 mokurai left
chromatic plausible.org/nasal/doc.html 07:48
dalek kudo: e5a63db | moritz++ | src/setting/Operators.pm:
infix:<eqv> for undefs
 07:53
nopaste "NotFound" at 213.97.96.43 pasted "Ugly fix for TT #218" (21 lines) at nopaste.snit.ch/17493 07:58
NotFound This patch shows the weakness of the PMCProxies 08:00
08:24 dukeleto joined 09:01 cognominal joined 09:17 MoC joined 09:37 kj joined 09:38 HG` joined 09:49 bacek joined 09:52 payload joined
bacek treed: ping 09:55
09:57 wayland76 joined
bacek treed: cardinal's string "failures" were fixed in parrot at r40132 and r40142 long time ago... You can just uncomment tests and they will pass. 09:57
10:08 mikehh joined 10:15 donaldh joined 10:35 tekky left 10:40 muixirt joined 10:43 Khisanth joined 10:45 JimmyZ joined 10:48 kid51 joined 11:21 donaldh joined 12:02 kj joined 12:05 kj left, kj joined 12:42 tetragon joined 12:50 ruoso joined 13:15 HG` joined 13:25 Khisanth joined 13:32 Khisanth joined 14:12 payload joined 14:38 whiteknight joined 14:45 Khisanth joined 14:48 Psyche^ joined 14:55 Andy joined
dalek cnum-dynpmcs: r140 | darbelo++ | trunk/src/pmc/decint.pmc:
Make DecInt's VTABLEs call SUPER and then round the result as appropiate.
 15:10
15:20 donaldh joined 15:25 jdv joined
dalek cnum-dynpmcs: r141 | darbelo++ | trunk/src/pmc/decnum.pmc:
Replace calls to decNumberRemainder() with calls to decNumberRemainderNear(),
 15:36
mikehh codetest FAIL, All others PASS (pre/post-config, smolder, nqp_test, fulltest) at r40439 - Ubuntu 9.04 amd64 15:43
DEPRECATED.pod fails t/codingstd/pod_syntax.t - PATCH in nopaste.snit.ch/17491 15:44
cotto somebody's just itching for a commit bit 15:45
mikehh++ 15:48
mikehh I am not sure about that :-} - let somebody else take the risks - anyway I submitted a CLA
dalek rrot: r40440 | cotto++ | trunk/DEPRECATED.pod:
[codingstd] fix POD errors in DEPRECATED.pod
 15:51
15:52 jan joined
dukeleto mikehh: congrats, it usually doesn't take long for them to approve you 15:52
15:53 mberends joined 15:56 davidfetter joined, hercynium joined 16:29 treed joined 16:37 whoppix joined
dalek kudo: 4665d75 | masak++ | src/setting/ (2 files):
[src/setting/Str.pm] a first shot at .encode

Parrot parts haven't been fully exposed yet.		 16:51
kudo: 7717c4a | masak++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
16:54 darbelo joined 16:59 treed joined 17:12 chromatic joined
dalek TT #906 created by allison++: [PIR] Assignment syntactic sugar restricted to destination parameters 17:13
17:15 iblechbot joined
dalek rrot: r40441 | allison++ | trunk/DEPRECATED.pod:
[cage] Link deprecated item to more relevant ticket.
 17:19
17:25 treed joined 17:29 mokurai joined
dalek rrot: r40442 | allison++ | trunk/src/library.c:
[cage] Remove 'runtime/parrot' from library and include path searches,

instead. Resolves TT #511.		 17:30
TT #511 closed by allison++: [CAGE] deprecate searching runtime/parrot for libraries and includes 17:38
cotto From C, what's the best way to get the full name of the namespace of a Sub PMC?
particle as a string? 17:43
you'll need to build it
cotto yay 17:47
particle do you need to worry about aliased namespaces? 17:48
that is, can you build towards the root from the sub, or must you build from the root towards the sub?
chromatic Use Parrot_Context_get_info(). 17:49
cotto chromatic, thanks. That does the trick. 17:53
chromatic I remembered using it when I wrote the proof of concept.
cotto which proof of concept? 17:57
chromatic The first time I did a profiling core. 17:58
cotto It's coming in very handy. 17:59
inner runloops make for all kinds of fun. 18:00
chromatic Exactly. 18:01
cotto Are inner runloops a common problem with interpreters or is Parrot just special? 18:06
chromatic Parrot's pretty special in that it calls in and out of C so much, but I can imagine similar fun in other VMs when calling back and forth into extensions. (Shared library callbacks, ugh.) 18:07
Infinoid In libfuse.so (and soviet russia), shared libraries callback into YOU. 18:11
18:16 Khisanth joined
cotto On a completely unrelated topic, is there any reason a PGO build isn't on the roadmap? 18:17
dalek TT #907 created by allison++: [CAGE] refactor Parrot_mmd_sort_candidates 18:20
tracwiki: v10 | moritz++ | git-svn-tutorial 18:21
tracwiki: mentioned a tar archive including all branches + svn meta data; git svn create-ignore
tracwiki: trac.parrot.org/parrot/wiki/git-sv...ction=diff
chromatic PGO?
allison developer.mozilla.org/en/Building_...timization
I'm assuming
cotto: because we only have so many tuits 18:22
cotto: but anyone is certainly welcome to try it
cotto PGO is profile-guided optimization 18:23
PGO is also developer.mozilla.org/en/Building_...timization
purl okay, cotto.
chromatic I tried it; didn't make a huge difference in some naive tests.
I think our Makefile trickeries hung it up a bit. 18:24
cotto Our build is special.
dalek rdinal: 9165470 | treed++ | t/string/ (2 files):
get_pmc_keyed on String is working again, remove todo/skip
 18:39
rdinal: 31c9263 | treed++ | (2 files):
Add String.each_char.
rdinal: 7f9db1a | treed++ | (3 files):
Implement String.empty? with tests.
rdinal: 34e0fdb | treed++ | (2 files):
Fix String.each to actually work as it should, also have it respect $/. Fixes #17.
cnum-dynpmcs: r142 | darbelo++ | trunk/ (3 files):
Move the version() METHOD from DecNum to DecNumContext. It looks like it should

Update our usage example to match.		 18:40
pmichaud allison: ping
allison pmichaud: pong 18:42
pmichaud ah. I was concerned about r40442 (removing runtime/parrot), but I misread the ticket. <latella>Never mind.</latella>
(I was thinking that runtime/parrot/library was removed from the path... but you just removed runtime/parrot) 18:43
allison pmichaud: ah, aye
pmichaud we missed you in lisbon. :-|
allison yeah, I'm bummed I didn't make it. Hopefully lots of Perl 6 stuff got done. :) 18:44
pmichaud It did.
lots of excitement about the rakudo announcement, and we have a really good plan for getting to next April 18:45
jnthn++ and I were reviewing the task list and we think it's very doable. But we're definitely going to want the calling convention refactors just as soon as Parrot can get them. :-)
allison excellent 18:48
yes, calling conventions are top on my list
pmichaud \\o/
allison I've got the extract from the old branch ready, will create the new branch this afternoon 18:49
pmichaud oooooh
I'm definitely looking forward to seeing it. :-)
allison the upside to being stuck in the US waiting for a visa is I have absolutely nothing to do for the next few weeks but sit in a hotel and work on parrot :)
cotto I love that upside! 18:50
pmichaud realizes that his PIR book should be waiting for him when he gets home. :-)
I'm eager to learn about PIR... I think I might be able to do some cool things with it. :-) 18:51
allison heh :)
history shows you're able to do some of the coolest things ever with it :) 18:52
pmichaud Well, I'm hoping that's just the prelude to even more stuff. :)
I'm also hoping that others are able to do cooler things with Parrot than I've done. 18:53
particle the pir book is surprisingly slim
much smaller than k&r
pmichaud wonders if B&N at the airport is carrying the book. :-P
allison particle: aye, it's a "Pocket Guide" 18:54
(but we can't use that term, since O'Reilly has printed so many)
cotto Is that a parrot in your pocket?
particle the firefox colors on the cover are an interesting choice
and the lack of a parrot logo 18:55
pmichaud okay, I should probably release this table in the restaurant for other paying customers
particle surely you could have gotten written permission :)
pmichaud back later (maybe) 18:56
particle stick the landing!
19:08 whoppix joined
whiteknight allison: ping 19:11
19:20 donaldh joined 19:26 mberends joined
dalek rrot: r40443 | NotFound++ | branches/auto_attrs/src (7 files):
set auto_attrs in several critical PMCs
 19:31
allison whiteknight: pong 19:47
whiteknight hey allison, did you get my email a few days back about the book?
allison particle: the "firefox colors" are a parrot wing
whiteknight a "pocket guide" is good, but something bigger would be better :)
allison particle: (a rather abstract one) actually, it's the background of the logo from parrotblog.org, repurposed
whiteknight: I did, but haven't had time to respond to it 19:48
particle ...knew it looked similar...
whiteknight that's fine, just wanted to make sure it wasn't lost in the ether
allison we don't need an expanded book on PIR
whiteknight also, if you need any help whatsoever in pcc_rewiring I'm at your service
allison and what most people are really going to want is not a guide to the internals of the VM, but how to write a language, or how to write libraries 19:49
particle i think the most important parrot document eventually will be how to install it
allison so, I have my eye on two more small guides "Parrot Developer's Guide: Compiler Tools" and "Parrot Developer's Guide: Modules" 19:50
particle hopefull that document is so short, nobody has to read it
allison particle: aye, but that's a few short lines at the beginning of each book "How to Get Parrot"
particle yes, i mean to say, our ultimate audience is folks who don't care that parrot is there, just that their hll works 19:51
allison particle: yup, agreed
whiteknight okay, new books is a good idea too. I'm fine with whatever so long as I have a plan to follow :)
allison whiteknight: pmichaud is going to work on the Compiler Tools book, but might be interested in help 19:52
whiteknight: some of the content for the Modules book could be pulled out of the remaining draft chapters.
whiteknight yeah, i've drafted a lot of stuff on it that idn't make it into the PIR book, so that's a start
right
so creating these in docs/pct and docs/modules?
allison docs/book/pct and docs/book/modules 19:53
whiteknight ah yes, that's what I meant
allison aye
a quick chapter shuffling out of draft could be a good start
whiteknight Okay, good. I'll see if I can hit that up tonight 19:54
19:55 joeri joined 20:06 ruoso joined 20:08 ruoso joined 20:09 tekky joined, tekky left 20:10 ruoso joined
dalek rrot: r40444 | allison++ | branches/pcc_arg_unify:
Creating branch for refactoring calling conventions, rewiring the internals of pcc dispatch to use a single argument passing strategy.
 20:33
cotto arg!
japhb allison: sorry I didn't respond to your email in the Parrot "standard libraries" thread, but I seem to have never received it. No matter, reading it in the archives now. 20:44
allison japhb: curious, still having trouble with your ISP filtering? 20:48
japhb allison: I thought I had that turned off, and I did get pmichaud's reply to your message just now (which is how I knew you'd sent one) 20:49
dalek rrot: r40445 | allison++ | branches/pcc_arg_unify (9 files):
[pcc] Merging in first round of changes from pcc_rewiring branch to
 20:50
japhb allison: I think I understand your objection to a single module repository -- would you instead support a single place to *find* modules? In other words, a repository of just module metadata, and including in Parrot the necessary tools to create and upload a metadata file when you are ready to "publish" your spiffy new module (wherever it happens to be hosted), and conversely for users to search against that metadata repo, select a metada 21:00
ta file, and call the appropriate tools to download the matching module source from sourceforge, github, etc., and configure/build/test/install?
darbelo japhb: Wouldn't that be just as easy to implement as an external tool? 21:03
japhb darbelo: what exactly do you mean by "external"? 21:04
particle japhb: you mean freshmeat.net?
japhb particle: No, I mean real metadata. Like META.json + MANIFEST + ... 21:05
And I'm thinking of something like masak's 'proto' tool on steroids.
particle i wonder how much of that could rely on rss feeds from various existing repositories 21:06
darbelo japhb: Not shipped with parrot, and not necessarily maintained by the same people.
japhb is trying to find "rough consensus" so that we can then produce "working code"
particle iwbni all the data were managed externally, and simply aggregated 21:07
japhb particle: Only if said RSS feeds were capable of including only "releases", and also could be taught to contain at least links to the proper metadata files.
iwbni?
purl iwbni is "it would be nice if"
japhb particle: that centralizes the task of writing aggregation tools, but does have the benefit of removing a step from the module author's "publish" workflow .... 21:09
particle correct
the site "discovers" the module, the author doesn't "publish"
japhb particle: well, remember, there'd be no per-release work for the module author other than 'make publish' 21:10
particle assuming they use make 21:11
and a special makefile template
japhb And we could even give them a reason to do it, by including the ability to squawk about the new release and have that fed directly to a "new modules" planet.
Hmmm, of course, that could happen in the discover mode too, I guess.
particle: I was using 'make publish' in the general sense of 'single simple command' rather than that exact syntax. Sorry for the confusion. 21:12
particle ah, ok
i'm thinking that module authors tag their distros as 'parrot' or similar, and the discovery engine picks out README, CHANGES, AUTHORS, etc 21:13
japhb darbelo: can you explain in more detail why you don't want the Parrot people involved in the module publishing game? I would think our deprecation cycle means that we may want to have some non-trivial input into that, if not outright control ... 21:14
particle: Would you agree with specifying the naming and format of those magic files?
21:16 Tene joined
japhb also a bit worried that discovery will become a difficult to scale operation, in the sense of pounding on github et al to the point they get a bit annoyed at us. I wonder if the various source repos have usable push APIs (I'm not talking RSS, I'm talking something that's efficient machine to machine, and pushed rather than polled) 21:17
Oh, and the other problem, is that discovery only works if the source is hosted in a public place.
Otherwise, the module author has to publish a tarball at least, and then they need some place to put it, and running discovery against every company ftp site won't work, so they need some way to notify the discovery engine to look for the new item. Which brings us back to 'make_publish' 21:19
darbelo japhb: I ussually think of parrot as a low-level, reusable component. I don't expect the parrot devs to care about the distribution of whatever modules run on their vm anymore than I expect the (extreme example) gcc devs to care about the distribution of the various open source projects written in C. 21:21
21:24 mikehh_ joined
japhb darbelo: Sure, I can see that ... but Parrot is somewhat special in that a large pillar of its motivation is to promote module sharing, between the HLLs (in the case of HLL-coded modules) and from Parrot to the HLLs (in the case of NCI libraries). In the C world, the closest equivalent I can think of are the desktop projects (GNOME, KDE, freedesktop.org), which all have some way of marking a project 'official', marking releases and bundle 21:32
s, and so on.
particle japhb: standard/recommended filenames/formats, yes 21:35
japhb: there will always be a darkpan, it can't be avoided
errands & 21:36
japhb particle: The darkpan is not what I meant
particle if the source isn't public, then what is it?
japhb particle: I was talking about businesses that do (for example) contribute modules to CPAN, but their VCS repos are behind the corporate firewall.
21:37 mberends joined
japhb particle: Thus, they already have to publish a snapshot externally somehow; we need to support that use case. 21:37
Open source != open source *control*, as several large companies are perfectly good (bad?) examples of. 21:38
darbelo japhb: I see that, but what I would expect the modules to have an independant release cycle. The release cycle for the nci wrapper of library FOO should follow the release cycle of library FOO, not that of parrot. 21:48
Tying both cycles together sounds like a recipe for pain. 21:49
japhb darbelo: Oh sure, I never meant that libraries would follow parrot's release cycle -- I meant that when we cross a deprecation boundary, we need to make it easy for our users to find the version of a module compatible with the version of parrot they have installed.
In other words, we should make it possible for a Parrot 2.0 and a Parrot 3.0 user to both have an easy time finding the proper module releases they can install. 21:50
And I think we may have to help with that; specifying metadata for compatibility and conflict resolution, for example. 21:51
I mean sure, a 3rd party sufficiently clued into Parrot's workings could indeed get all that right. But for *now* I suspect having us at least somewhat involved will ease the bootstrap. 21:52
And I also suspect that until one of us JFDIs, no one is going to magically come along and do it for us. :-) 21:53
darbelo I should probably make clear that I'm not against a centralized Parrot Module Repo. It's making it the One True Parrot Module Repo that makes me have second thoughts. 22:01
japhb darbelo: Just so I'm clear on where your dividing line is .... In the Perl world, does CPAN bother you? Or the fact that perl comes with cpan, which only knows about CPAN, and no other module repo? 22:08
(That's an honest question, I'm trying to find the line between "centralized" and "One True")
darbelo I'd have to say "that perl comes with cpan, which only knows about CPAN". 22:10
But CPAN has a mitigating factor, in my particular case, for perl modules available in the ports collection I don't have to care that cpan exists. 22:14
japhb BSD user? 22:15
darbelo Yup, OpenBSD. 22:16
japhb I'm in a similar place, because I run Debian -- lots and LOTS of CPAN is packaged. 22:17
Usually, I can find the perl package I want with apt, and if I can't, there's always CPAN search. At most two places to look -- but even so, I find myself somehow annoyed when I have to go the CPAN search. 22:18
22:20 Limbic_Region joined
japhb But at $work, where I have to use distros that don't package the world (as Debian tries to), I go nuts trying to find stuff across lots of different RPM repos. In fact, I often find it easier to badger Dag to package something for RPMforge than to go find it myself. 22:20
I'd be really happy if parrot didn't make people day-to-day unhappy like that.
Which is why, minimally, a central place to search seems key.
22:21 kid51 joined
japhb FPAN: "Federated Parrot Archive Network" ... where the "Federation" is the central metadata & search. 22:23
22:25 he left
japhb This idea is actually a win in terms of allowing the Parrot HLLs to see the Parrot NCI libraries right alongside the pure-HLL libraries from PEAR, Eggs, etc. 22:26
darbelo Hmm, but where do you draw the line for HLL-specific stuff. I would expect Rakudo to have it's own module repo, separate from whatever parrot provides. 22:28
Tene One statement I'd rather question from Allison's recent mail... "there's very little value in
creating a CPAN-like module repository"
CPAN is a CPAN-like module repository. Does that mean that there's very little value in CPAN?
japhb darbelo: I meant, if we federate just the metadata, then Rakudo users don't need to know or care whether they are pulling from a Parrot repo, or from a Perl 6 repo, or a Rakudo-specific repo, or directly from some github project ... 22:29
Tene japhb: you ever use cpanspec to package your own rpms from cpan? 22:33
japhb Tene: nope. Usually the stuff I need from CPAN has sufficiently finicky prereqs that a knowledgeable person figuring out library version interactions is helpful -- I'm not really an RPM guy, I can just cargo-cult a SPEC occasionally. 22:35
22:39 rg joined
kid51 cotto? 22:41
purl cotto is probably Christoph Otto <mailto:christoph@mksig.org>
japhb On #toolchain, it was pointed out that CPAN mirrors are often far more reliable than, say, github. So offering mirroring isn't such a bad idea after all .... 22:44
chromatic I (personally) don't want to be in the business of managing/administering such a thing. 22:46
22:48 tetragon joined
japhb chromatic: "such a thing"? mirrors or central meta data repo or both? 22:50
cotto kid51? 22:51
purl kid51 is now going to live dangerously.
chromatic Mirrors.
purl mirrors are like that
japhb chromatic: Ah OK. Well, I don't see mirrors as something we need to provide, merely that we should support the possibility that a VCS site might be mirrored by a third party, and let the market take it from there. 22:54
Does that make sense?
kid51 cotto: Just sent you mail re your new config step question. 22:55
cotto kid51, great. Thanks. 22:56
chromatic Sure, I much prefer that we allow this to happen rather than trying to do it ourselves up front. 22:57
22:58 cottoo joined, Casan joined
japhb As long as we make it possible, I think that's good enough for a start. 22:58
chromatic Exactly. 22:59
allison Tene: I wouldn't say CPAN has little value, but I would say that CPAN is part of why Perl is losing relevance in the wider world. People only go there if they already use Perl. 23:03
japhb OK, sounds like some consensus is forming in general. Now for the next level of detail: what tools and standards do we need to provide? I'd say at a minimum we need to standardize metadata format and semantics, and the names (and possibly formats) of any special files such as README, CHANGES, etc. And we (by which I mean the community, not the Parrot core team) need to provide a search server and a web and API interface to it. 23:04
I would *like* to support at least a CLI tool (like a smarter cpan shell) that makes search and download/build/install easier than the manual method. 23:05
23:13 hercynium joined
darbelo japhb: (CLI tool)++ 23:18
23:20 donaldh joined 23:24 jhelwig joined
dalek TT #908 created by allison++: [CAGE] Relocate xconf/ examples to examples/ directory 23:25
23:38 mberends joined
mikehh examples_tests FAIL, All Others PASS at r40445 (pre/post-config, smolder, nqp_test, fulltest) - Ubuntu 9.04 amd64 23:52
t/examples/pir.t - Failed test: 16 23:53
lokking at it now
looking 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!