Re: negated operators and disjunctions (was: Recommended Perl 6 best practices?)
# from Carl Mäsak
# on Sunday 14 September 2008 07:18:
die Unrecognized directive: TMPL_$directive
if $directive ne 'VAR' | 'LOOP' | 'IF';
One is tempted to assume that this means the same as
$directive ne 'VAR' || $directive ne 'LOOP' || $directive ne 'IF',
but it doesn't.
Actually, it does mean exactly that.
But you're not really tempted to read it as:
if this isn't var or else this isn't loop or else this isn't if
(in denial?). Instead, one is tempted to read it as:
if this is not: 'var', 'loop', or 'if'
, by which you really mean:
if this is not 'var' and this is not 'loop' and this is not 'if'
or:
if not this is any of: 'var', 'loop', or 'if'
which is:
unless this is any of: 'var', 'loop', or 'if'
or:
if this is not all of: 'var', 'loop', and 'if'
But perhaps the thing to remember is to not mix negated operators with
disjunctions? The 'dis' being a form of negative and all.
I found this in E06:
if %person{title} ne $known_title { ... }
Well... I guess E06 is unmaintained, but currently has the best
explanation of junctions I can find, so I offer the attached patch in
the hope that the logic error does not propagate.
--Eric
--
But you can never get 3n from n, ever, and if you think you can, please
email me the stock ticker of your company so I can short it.
--Joel Spolsky
---
http://scratchcomputing.com
---
Index: exe/E06.pod
===
--- exe/E06.pod (revision 14582)
+++ exe/E06.pod (working copy)
@@ -857,6 +857,15 @@
print Unknown title: %person{title}.;
}
+[Update: that was a logic error: the negated operator carries through
+the disjunction and is always false.
+
+unless %persontitle eq $known_title {
+say Unknown title: %persontitle.;
+}
+
+Hash key quoting has also changed.]
+
or even CCode references:
my ideal := \tall \dark \handsome;
Re: Iterator semantics
Hi Larry,
# from Larry Wall
# on Thursday 11 September 2008 12:13:
So when you put something into a list context, some of the values
will be considered easy, and some will be considered hard.
The basic question is whether we treat those the same or differently
from a referential point of view. ...
The easy ones are the values that have already been calculated,
presumably...
Suppose we have
my @a = 1..10; # assume easy
my @b = =$socket; # assume hard
for @a,@b {...}
If the for list sees @b as hard and just copies @b's iterator into its
own list for lazy evaluation, then it's going to end up iterating the
socket without loading @b. Contrariwise if @b is eagerly evaluated it
might clobber the other iterator in the for list. So those iterators
must be kept unified. It's not enough to copy out the iterators
from the array; access to the hard elements of the array must still
be modulated by the array container. A snapshot of the array
container will not do in this case.
If a lazy list is an array with an iterator welded onto the end, then:
1 .. 10 is just: 1, 2, 3, weld_here iter(4, thru = 10)
1 .. * is just: 1, 2, 3, weld_here iter(4)
And because an iterator doesn't go backwards, the array has to remember
the previous values to allow me to maintain the just an array
abstraction, so after I asked for @a[3], the internal state is like:
1 .. * becomes: 1, 2, 3, 4, weld_here iter(5)
As a first shot at that definition, I'll submit:
1 .. $n # easy
1 .. * # hard
On the other hand, I can argue that if the first expression is easy,
then the first $n elements of 1..* should also be considered easy, and
it's not hard till you try to get to the *. :)
It could also be that I'm confusing things here, of course, and that
1..* is something easy and immutable that nevertheless cannot be
calculated eagerly.
But you can take a copy of the @a = 1 .. * however you like as long
as just an array holds such that @a[41] is always the same regardless
of whether you (internally) have to kick the welded-on iter 27 times to
get that element or have already passed it. So in this case you could
(internally) end up with two copies each holding their own iter() in
different states while still giving the same result at the just an
array level. But this is just an optimization on the general case you
stated of must be modulated by the array container and it is an
optimization which is only possible for predictable iters.
So, perhaps the case is:
1 .. $n # bounded and predictable
1 .. * # unbounded and predictable
=$handle # bounded and unpredictable
=$socket # unbounded and unpredictable
By unpredictable, I'm meaning simply that the value of a given element
cannot be calculated independently by replicating a (pure) function
f($i). Perhaps a filehandle isn't a thorough example of that though?
What about:
my @a = 1..*;
my @b = =$socket;
for @a,@b {...; @a = something(); ...}
or:
my @a = 1..*;
my @b = =$socket;
my @c = (@a, @b);
for @c {...; @a = something(); ...}
In the first case, changing @a changes the for() iterator but in the
second, the for() will still be nibbling on 1..*, right? So the
welded-on-iter is basically by-reference until I do something under
the just an array paradigm which breaks the weld?
@a = 1..*;
@a[-1] = 9; # @a = (9) now ?
That's just my thoughts from what I understand and sorry if introducing
welding into the analogy causes bits of molten metal to go flying
around ;-)
--Eric
--
You can't win. You can't break even. You can't quit.
--Ginsberg's Restatement of the Three Laws of Thermodynamics
---
http://scratchcomputing.com
---
Re: [perl #57320] touch /tmp/t make test = fails t/perl/Parrot_IO.t ?
# from Will Coleda # on Monday 28 July 2008 07:31: I presume Eric noticed this as he was working on his patch to enable a parallel make test; Now that his patch is applied, fixing these tests should have a higher priority; If two tests that are trying to create/use the same directory run at the same time, one of them is likely to fail. Well, that is all true. But it really has little to do with parallel testing, it is simply a faulty assumption. Today I'm working on something else and still haven't shutdown my machine since then, so I still have a file /tmp/t, so the tests still fail. I *could* delete that file, but what if that just happens to be my favorite empty file of all time? But if I look at it deeper, the Parrot::IO code only exists for ./tools/docs/write_docs.pl? Oh, and a bunch of the codingstd tests? --Eric
Re: unified languages-test
# from Will Coleda # on Monday 18 August 2008 12:11: as far as i'm aware, with planet.parrotcode, the administrator picks the feeds that are aggregated. ~jerry Yes, I assumed you wanted server side aggregation. What you're suggesting here sounds just like subscribe to as many feeds as you want in your reader, which I can already do. What else am I missing? Perhaps http://$url/testfeed?tclrakudo=spectest_regressionparrot=branches/gsoc_nci/testj Or something like that, where the any news? question from the client is answered as the union of any news? in relation to all of the requested targets. Which would reduce the number of requests to the server. But of course a newsreader with nested folders could cobble it all together on the client side. --Eric -- Turns out the optimal technique is to put it in reverse and gun it. --Steven Squyres (on challenges in interplanetary robot navigation) --- http://scratchcomputing.com ---
Re: enterprise parrot
# from jerry gay # on Tuesday 05 August 2008 14:13: On Tue, Aug 5, 2008 at 1:47 PM, Geoffrey Broadwell wrote: Which reminds me: chromatic, what was your reasoning for major releases being every three months, instead of four or six? I agree we don't want to go much beyond six months for our major releases, but with at least two major distros that aim for decent freshness (Ubuntu and Fedora) using six month release cycles, I'm curious what we gain with a shorter cycle than that. please start a new thread as this has moved off-topic. Indeed. There's quite a bit of ground left to be covered before anyone needs to worry about how much the support contracts are going to cost. I imagine that release cycles and deprecation of parrot features isn't going to mean nearly as much churn to RHEL or Ubuntu LTS, or Debian stable users as it would with e.g. Perl 5 -- because they will typically be interfacing with the HLL, which provides a bit of buffer. --Eric -- A counterintuitive sansevieria trifasciata was once literalized guiltily. --Product of Artificial Intelligence --- http://scratchcomputing.com ---
Re: [perl #57358] Enable parallel testing
# from Moritz Lenz # on Monday 28 July 2008 09:52: That's not -just- with the patch, though, is it? I presume you've set TEST_JOBS to be something other than '1' ... I've set it to 2, and obeserve the errors below. With serial testing I get a PASS (r29828). Yes. TEST_JOBS=1 doesn't change anything. It looks like most of the tests in t/steps might potentially conflict. To smoke out the resource conflicts in the test suite, one would have to run $n jobs -- but that will forkbomb your system. Another check is to run each against each other with `prove -j 2 $test_n $test_i` Tests need to be written defensively for arbitrary parallelization to be possible. If that's too much coding, the non-optimal serial within a directory scheme (or other forms of work division) would have to be used. --Eric -- Politics is not a bad profession. If you succeed there are many rewards, if you disgrace yourself you can always write a book. --Ronald Reagan --- http://scratchcomputing.com ---
Re: [perl #57358] Enable parallel testing
# from Moritz Lenz # on Monday 28 July 2008 13:02: With enough RAM everything is fair game ;-) I ran it with $n == 20, and identified this list of files: Yes. My reading of Parrot::Configure suggests that there's no tempdir involved, which would need to be done per-process. The alternative is to try to grok whatever Andy Armstrong was doing (has done?) with the TAP::Parser::Scheduler and schedule 't/steps' as a serial chunk. Other alternatives could be made to exist via a simple matter of coding. --Eric -- Consumers want choice, consumers want openness. --Rob Glaser --- http://scratchcomputing.com ---
Re: This week on parrot?
# from Andy Lester # on Monday 05 May 2008: This presupposes that the summaries are a good thing: anyone have any feedback on this point? Just wondering who the audience would be. Lurkers (potential contributors.) Posting it on use.perl.org (and/or various other feed sources) would reach more of us. --Eric -- Time flies like an arrow, but fruit flies like a banana. --Groucho Marx --- http://scratchcomputing.com ---
Re: This week on parrot?
# from Andy Lester # on Monday 05 May 2008: But do those lurkers actually exist? I exist (or at least, I operate under the assumption that I exist.) that the people who would be interested in a summary are already on the list. Indeed I am on the list. But, I usually don't read anything with brackets in the subject line, which is most of the list traffic. A lot of what is happening is the sort of stream that doesn't give your foot back if you dip your toe in the water, so I tend to use what little time I currently have for parrot watching from the streambank. I guess what I'd really like to see would be something aimed higher than the p5p summaries are. It'd be something that could be interesting to a wider range of readers, not just the people who care about the nitty gritty of PGE/PIR/whatever. This fabulous technology brings is this much closer to Rakudo being reality. This gets us closer is somewhat assumed in that working away from the goal would be rather silly. But, yes it is good to be explicit about what is progressing and how quickly -- though maybe that's another channel. I think something with a similar level of detail to the p5p summaries would be useful for those who want to contribute, but are looking for a good entry-point. A mid-level summary of who is doing what would make it more approachable. --Eric -- Hot dogs: just another condiment. --Heart-attack Man --- http://scratchcomputing.com ---
Re: Google Summer of Code 2008 Call for Proposals
# from Will Coleda # on Thursday 20 March 2008 12:22: We also have a presence on #parrot and #soc-help on irc.perl.org, as well as #perl6 on freenode. See http://www.perlfoundation.org/perl5/index.cgi?gsoc2008_projects for some project ideas if you're a student Hi all, The traffic regarding parrot seems a bit light. In past years of involvement, the bulk of accepted proposals were parrot or Perl 6 related. I think we would like to see at least 10 applications here this year. So, a few questions for parrot people: Are there enough exciting and accessible potential projects within and around parrot? Are we making them clear enough on the wiki? Should we have some more info about how the student should get started coming up with a parrot-related invent your own project proposal? More links to parrot info? Are there some students starting to appear in #parrot and I'm just not noticing it? Did your local perl mongers list get my call for proposals mail? http://use.perl.org/~Eric+Wilhelm/journal/35953 Do *you* know any students who would be good candidates? Am I just being impatient? I'm curious whether there is a lack of interest or a failure to adequately promote the opportunity. (Or possibly procrastination, but students who appear before the 31st seem likely to make for a more successful, drama-free summer.) I think the most successful students are going to come from one-on-one connections, so I would ask everyone to please try to contact at least one student by Monday. Thanks, Eric
summer of parrot - ideas and mentors wanted
# from chromatic # on Saturday 01 March 2008 17:19: Will Coleda and Dave Rolsky are currently performing similar features for Parrot; either of them might be a good first choice. If neither can do it, I will. Excellent, thanks. Parrot seems to be nicely supplied with soc managers now! Jerry Gay had already volunteered to do this on irc, so I will let you all sort it out. Please feel free to join us in #soc on irc.perl.org. Should parrot have its own pages for ideas and mentors? Perhaps add a link to your own ideas page, but go ahead and start adding yourselves mentors here? http://www.perlfoundation.org/perl5/index.cgi?gsoc2008_mentors http://www.perlfoundation.org/perl5/index.cgi?gsoc2008_projects If you hate wikis as much as I do, please visit this handy form and I will batch the wiki edits on your behalf. http://scratchcomputing.com/loveperlhatewiki.html Thanks, Eric -- But you can never get 3n from n, ever, and if you think you can, please email me the stock ticker of your company so I can short it. --Joel Spolsky --- http://scratchcomputing.com ---
Re: summer of code mentor applications starting (and ending) next week
# from Nicholas Clark # on Friday 29 February 2008 06:58: There is no such thing as a p5p admin*. No, it would need to be somebody on behalf of TPF, as google needs somewhere to send the mentorship check. Alternatively, a company or individual attached to a sufficiently large perl-based project could submit their application separately (at least Catalyst, mod_perl, and RT come to mind.) But for hacking The only requirement is that you be an entity with which google (a US organization) can legally do business (and of course: that you represent a vibrant open source project.) I'm told that the TPF website is out-of-date. Richard? We need to start building a list of mentors, but they need someone at TPF to contact. http://code.google.com/soc/2008/ The organization should choose a single administrator to submit its application via the GSoC web app between March 3-12, 2008. --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management --- http://scratchcomputing.com ---
Re: [perl #38262] [CAGE] get external Perl5 modules out of the parrot repo
# from James Keenan via RT # on Wednesday 27 February 2008 09:40: The output of Test::Builder changed at 0.64_01, which falls in between the 0.60 we had in the distro and the 0.72 which most (but not all) of our developers are likely to be using now. ... Two possible solutions: Either eliminate those 6 tests entirely, or rewrite the tests to make the regexes which need to be matched tolerant of the differences between Test::Builder 0.60 and 0.72 in this regard. Are you depending on having Test::Harness 3? If so, the TAP::Harness and/or TAP::Parser API should make parsing TAP less fragile than hand-rolled regexps. --Eric
Re: the future of testing
# from Rafael Garcia-Suarez # on Wednesday 09 January 2008 05:36: Allison Randal wrote in perl.perl6.internals : In the Python test suite, there's a single global location to declare a list of test files that are expected to be skipped on a particular platform. This has a much cleaner feel than our own motley collection of skip and todo markers in various test files. To me, python code generally tends to *feel* cleaner, but on deeper inspection, usually is limited by failed assumptions. I suspect that you've fallen prey to this same seduction in your perusal of their test suite. There may still be something in it -- I'm just adding salt :-D A global skip/todo config would be nice in that it also provides more metadata about the tests, so e.g. running a targetted cross-section of tests becomes easier. That assumes that tests are skipped per file, which is not always the case (sometimes you want to skip only one test, sometimes even to work around an OS bug that appears only in one specific version). But reorganizing platform-dependent tests might be a good idea. Agreed. Skipping a subtest is very common. Organization would benefit from them being separated, but duplicated setup code would ensue. If tests were broken into methods within the file, you could have the global config and keep the granularity. The what is a platform? issue could also make the categorization messy (when you start involving compiler combinations or what-not.) Perhaps something more declarative can be done by providing standard is_foo() functions to reduce the complexity (and/or increase the readability) of the SKIP/TODO conditionals. So, (syntax aside) given foo.t with methods bar, baz, bort, and bob: t/foo.t is_osx(version: 10.0): skip_all: reason: ... is_osx: skip: bar baz bort is_solaris: todo: baz reason: baz needs love is_win32(with = compiler: msvc): todo: bort --Eric -- software: a hypothetical exercise which happens to compile. --- http://scratchcomputing.com ---
Re: [perl #45601] [unified_testing] Plans and notes for the unified testing branch
# from Bernhard Schmalhofer via RT # on Tuesday 27 November 2007 16:22: after the release of Test::Harness 3.03 I'm wondering about the status of the 'unified_testing' branch. Test::Harness::Straps doesn't exist in the new Test::Harness, so trunk would need to catchup with that issue regardless (e.g. calling Test::Harness::runtests() will no longer pickup on your custom straps package.) I wonder whether any major obstacles have surfaced and whether it makes sense to merge the changes in 'unified_testing' with 'trunk' again. As far as the harness is concerned, yes. Using the TAP::Harness API is preferable. If the parrot-land changes aren't 100% (e.g. unifying the way in which tests expect to be called), the old harness will still need to deal with the fact that the Test::Harness internals have changed and Straps is no longer available through that API. --Eric
Re: [perl #45601] [unified_testing] Plans and notes for the unified testing branch
# from James Keenan via RT # on Friday 21 September 2007 13:44: On Thu Sep 20 13:03:31 2007, [EMAIL PROTECTED] wrote: http://perlsix.org/svn/parrot/view/branches/unified_testing/BRANCH_TODO ... 5) Add processing of the output of Configure --test. When I began working on writing tests for the Perl 5 components of Parrot last November, we made the decision to not incorporate all the tests I was writing under the 'make test' target. This is perfectly fine. ... some take a long time to run ...some of the tests were only meaningful if run post-configuration, pre-build... Those are fine reasons to exclude tests from a given target. So I'm unclear as to what the 'unification' you're talking about would mean for these test suites. Can you clarify? I think unification is primarily needed in the sense of unifying how the results are reported. Do not be alarmed -- the fact that TAP::Parser has a parser (and an aggregator) as separate objects from the harness means there is more than one way to do it.[1] Also, unification in the sense that the shebang line for the tests tell the harness ~how to execute the test, not where to find the parrot and etc. It is intended that the test shebangs will function against an installed parrot and/or hll. And, also unification might involve specifying/organizing the tests (e.g. which are developer, which are exhaustive, etc) as e.g. a YAML file rather than capturing `$some_t_harness --files`.[2] If this can be completely expressed in data and/or directory layout, the amount of support code required to select a set of tests to run is reduced or eliminated. The details are in the details, err... footnotes. [1] For example, a smoke server might be logging the TAP results from `./Configure.pl --test`, then doing some post-processing and reporting on those results in conjunction with the rest of the TAP tree. The time at which those tests are run need not be dictated by the single harness, but it would be nice to unify the config/declaration of which tests are which and why -- possibly allowing a smoker to run them outside of the context of ./Configure so long as the state of the universe required by these tests is known. [2] This is not strictly necessary, but from my adventures in reading a few $some_t_harness files, the list of files does not usually require computation, and yet can be difficult to deduce from a quick read vs a data file. Perhaps some environment variables or etc. become involved and the list of tests actually does require computation. At the least, the unified harness will not require each t/harness to execute Test::Harness::runtests(@tests)[3] and so the code is reduced simply to the task of returning a manifest of files to be run. Perhaps t/manifest, (which (yes) might still need to be executed) but does not actually run the tests.[4] But maybe a nice directory layout would do? [3] unification actually conflicts with each t/harness calling runtests() in that the options (such as archiving the TAP) would need to be communicated in a rather roundabout way. [4] Whatever best serves the goal of being able to reliably report on the results of all of the tests run, how long they (each and all) took, and (hopefully cleanly) selects which to run (or not run) when. --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --- http://scratchcomputing.com ---
Re: Test::Harness 2.99_02 vs. Parrot
# from Andy Armstrong # on Monday 10 September 2007 11:13 am: On 10 Sep 2007, at 19:12, Andy Armstrong wrote: What are the steps a parrot-n00b would take to be able to reproduce your results? svn co https://svn.perl.org/parrot/trunk parrot perl Configure.pl make make test If your Test::Harness is 2.99_+, you'll see lots of places where the -I switch angers the '#!./parrot'. I tend to think this is an abuse of Test::Harness and therefore parrot should bundle Test-Harness-2.64 in their distro (at least, until they get away from it.) Sounds like Eric's got it under control :) More or less (but there's only one of me.) From prove's point of view, the parrot test suite is a wreck in terms of how it defines which tests are to be run. Some are blacklisted, activated by options, etc. This logic is also (potentially) distributed to every $(find -name harness) file in the tree. So, this is only a *start* because it currently has no way to know which test files to run. http://scratchcomputing.com/tmp/runtests --Eric -- As an old bass player friend of mine used to say: throw money, don't clap. --Tony Parisi --- http://scratchcomputing.com ---
Re: [perl #45153] better TAP::Harness support
# from Parrot via RT # on Tuesday 04 September 2007 01:30 am: With TAP::Parser, the attached patch and Parrot/TAP/Harness.pm in the current directory[1], the tests can be run as: runtests --harness Parrot::TAP::Harness $(perl t/harness --files) The runtests code has been refactored into App::Prove, which allows parrot to make their own ./runtests such as the attached. This gets rid of the need for --harness argument, and also allows for additional argument flag customizations. ./runtests $(perl t/harness --files) Get TAP::Harness from the svn. Note: this distro also contains a lib/Test/Harness.pm and bin/prove -- neither of those are needed for this, and they *might* even cause trouble with the existing parrot test framework. http://svn.hexten.net/tapx/trunk Additionally, there is now parallel testing support with TAP::Harness::Parallel. http://scratchcomputing.com/svn/TAP-Harness-Parallel/trunk This works like: ./runtests --jobs 9 $(perl t/harness --files) And appears to yield a 30-40% decrease in wait time (assuming that tests do not have resource conflicts (shared tempfiles, etc.)) A cursory examination implies that some parrot tests do indeed have such conflicts, but you have to crank -j up to 25 to find them (which is borderline forkbombing.) t/pmc/io.t t/pmc/os.t t/dynoplibs/myops.t t/src/extend.t --Eric -- Like a lot of people, I was mathematically abused as a child. --Paul Graham --- http://scratchcomputing.com --- runtests Description: Perl program
Re: TAP::Harness
# from Gabor Szabo # on Saturday 01 September 2007 01:35 am: Regarding Parrot, I think there was some discussion of moving it to use TAP::Harness and to use Smolder to collect the TAP based results. Indeed. We determined that the main task is refactoring all of the t/harness files. It looks like each one of them is building-up a list of tests in code (either with array declarations, globs, etc -- and affected by various environment vars and/or switches.) Other than sorting-out all of that, it's a simple matter of subclassing TAP::Harness and overriding a few methods such as _get_parser_args(). At least, I think that will do it. --Eric -- Left to themselves, things tend to go from bad to worse. --Murphy's Corollary --- http://scratchcomputing.com ---
Re: [perl #44213] docs/faq.pod - fix Lfoo|http://... pod abuse
# from Will Coleda via RT # on Friday 03 August 2007 01:40 pm: Seems like a pretty straightforward patch, but isn't the L syntax used currently proper? The L doesn't support named http:// links. from perlpod: ' Lscheme:... Links to an absolute URL. For example, Lhttp://www.perl.org/. But note that there is no corresponding Ltext|scheme:... syntax, for various reasons. ' Is there a particular pod reader we're trying to make happy? I'm assuming the website uses combust, so mostly whatever combust uses. The 68K emulator and April Fool's Joke links here are broken because of it: http://www.parrotcode.org/faq/ Also, pod2html (Pod::HTML) and Pod::Simple::HTML. Thanks, Eric -- It is impossible to make anything foolproof because fools are so ingenious. --Murphy's Second Corollary --- http://scratchcomputing.com ---
Re: t/codingstd/perlcritic.t needs to be optional
# from Andy Lester # on Wednesday 27 June 2007 10:09 pm: Modified since when? Create a .critictest file when it succeeds and use that timestamp? # from chromatic # on Wednesday 27 June 2007 11:10 pm: What if we have the Perl::Critic checks as Subversion commit hooks? Could email p6i with the results, too. That's what we do at work, and it's annoying, but it's there and it's pretty in-your-face. If it doesn't hose svk push, where the first of several commits fails due to standards violations, I wouldn't mind trying it as an experiment. I would guess a post-commit hook run in the background would be the way to do it. Besides the timeout issue, complex code preventing a checkin may be a bad thing because one would need to track-down a server admin if the gatekeeper script had a bug. If the tests run quickly enough locally, that will encourage clean checkins, with the post-commit informing the list of any dirty ones. --Eric -- You can't win. You can't break even. You can't quit. --Ginsberg's Restatement of the Three Laws of Thermodynamics --- http://scratchcomputing.com ---
Re: [perl #43081] [p6] Get p6 tests from pugs.
# from Paul Cochrane # on Thursday 31 May 2007 01:42 pm: It is possible to get anonymous svn access to the pugs source, but svn won't allow you to check out source from a different repository into another repository's path Maybe I'm missing something, but what I've done in similar situations basically amounts to: svn propset svn:ignore foo . svn co http://example.com/repository foo Later: svn up foo rsync foo/ standard/location/ That is, the files are all copied (or symlinked) from a single foreign checkout directory into their standard homes within the native repository tree. IME, the up vs co logic is best stuck in a bootstrapping script ala: http://svn.dotreader.com/svn/dotreader/trunk/util/dev_fetch_books Do avoid svn:externals though. --Eric -- hobgoblin n 1: (folklore) a small grotesque supernatural creature that makes trouble for human beings --- http://scratchcomputing.com ---
