Re: svn commits via email missing?
On Sun, Oct 05, 2008 at 10:43:45AM -0500, Patrick R. Michaud wrote: We seem to have lost the svn-commit mail updates, I haven't seen a svn-commit message since r31606 on October 3 (parrot is currently at r31676). Any chance we get could this back? For me it's much easier to review commits and patches arriving by email than to have to go manually look them up via svn. Robert sorted it out. This was an artifact of the perl.org svn upgrade. Missing mails have been regenerated. FWIW, '[EMAIL PROTECTED]' is probably the right contact point if there is a next time. -j Pm --
Re: [svn ci] added support for decorators to pmc methods
On Aug 7, 2007, at 1:26 PM, jerry gay wrote:
as of r20545, you can now decorate pmc methods to give the compiler a
hand in warning you about bad code, just like we've been doing
throughout parrot core (a.k.a. seatbelts.) for a list of decorators,
see include/parrot/compiler.h. for more info, see
docs/dev/seatbelts.pod
for example, in r20546, Null PMC's get_pointer method now looks
like this:
PARROT_CAN_RETURN_NULL
void* get_pointer() {
return PMCNULL;
}
Thanks so much for doing this.
What about being able to do NOTNULL() and NULLOK() on args to the
PMC? For the decorators to really make sense, we need both halves of
the equation.
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn ci] added support for decorators to pmc methods
On Tuesday 07 August 2007 11:29:03 Andy Lester wrote: What about being able to do NOTNULL() and NULLOK() on args to the PMC? For the decorators to really make sense, we need both halves of the equation. Are there any cases where they *can* be NULL? I wonder if slapping NOTNULL() on them by default would break anything. (I can't think of anything that's not already a bug.) -- c
Re: [svn ci] added support for decorators to pmc methods
On Aug 7, 2007, at 1:38 PM, chromatic wrote: Are there any cases where they *can* be NULL? I wonder if slapping NOTNULL() on them by default would break anything. (I can't think of anything that's not already a bug.) But can't some PMC methods take additional args, besides the default ones that already exists? That's what I'm thinking of. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: svn r18461 indentation problem?
Mark, It's highly likely that I was wrong to indent your example. I've noticed that particle has done some more work on the pod and he's moved it back :-) Anyway, your work is now in. Good stuff! Thanks for the help! Paul On 08/05/07, Mark Glines [EMAIL PROTECTED] wrote: Hi Paul! I noticed you reindented the example when checking in the PDD07 change. Sorry to disagree with you, but this seems wrong to me. Elsewhere in PDD07, it says: neither PARROT_IN_CORE nor the outermost _GUARD #ifdefs cause the level of indenting to increase. So I think the indentation was right. I'm in #parrot, if you'd like to discuss this. And thanks for looking at my patch! Mark
Re: [svn ci] NCI methods now name-mangled
On Apr 5, 2007, at 5:45 PM, Leopold Toetsch wrote: Am Donnerstag, 5. April 2007 00:39 schrieb Jonathan Worthington: Don't really need a policy to tell me that breaking stuff for languages folks sucks. :-) I try hard to avoid it, but unfortunately stuff slips through the net occasionally. In this case, I wasn't even aware that you could use SELF.meth(...) to call non-vtable methods, and it's done nowhere in core PMCs or I'd have noticed it. This could be also read as a notice to language maintainers: If you are using some features of parrot, then please, please submit a core test for it, if such a test doesn't exist yet. This will help Parrot and You in the future ... Thanks. leo Not only to language maintainers, but anyone using parrot where a feature isn't tested. And it also technically falls on whoever implemented said feature in parrot, for not adding a test. What if we had a repository, ala pugs with it's open commits, solely for people to commit tests. It could help improve bug discovery and test coverage, as well as ambiguity about features in parrot. Then developers could just update it and run it seperately(and check it to make sure nothing malicious gets through which is always a potential of course).
Ease of Committing Tests (was Re: [svn ci] NCI methods now name-mangled)
On Friday 06 April 2007 00:58, Joshua Isom wrote: What if we had a repository, ala pugs with it's open commits, solely for people to commit tests. It could help improve bug discovery and test coverage, as well as ambiguity about features in parrot. Then developers could just update it and run it seperately(and check it to make sure nothing malicious gets through which is always a potential of course). Is that a big convenience over mailing patches to the list or nopasting them for IRC such that people who won't do either of those will happily commit them? Are the specifications good and complete enough that tests can be unambiguously correct? Who will merge these tests into the standard tree? Just looking for more information, -- c
Re: Ease of Committing Tests (was Re: [svn ci] NCI methods now name-mangled)
On Apr 6, 2007, at 11:48 AM, chromatic wrote: On Friday 06 April 2007 00:58, Joshua Isom wrote: What if we had a repository, ala pugs with it's open commits, solely for people to commit tests. It could help improve bug discovery and test coverage, as well as ambiguity about features in parrot. Then developers could just update it and run it seperately(and check it to make sure nothing malicious gets through which is always a potential of course). Is that a big convenience over mailing patches to the list or nopasting them for IRC such that people who won't do either of those will happily commit them? It would add a convenience if we had a web form that just listed what testing method, the input, and the output for example. If it's promoted on the main page or somewhere on the site, then someone wouldn't have the join the list(which they may not want to do for some reason), or they may not have an irc client. I never really used an irc client before I started joining #parrot. I was working with parrot a couple months before I ever joined. Are the specifications good and complete enough that tests can be unambiguously correct? Reading over a pdd isn't the same as writing code based on that pdd. Something the ambiguoity isn't intentional and was just missed. Plus if they're random user tests, we should consider that it might not be accurate. Who will merge these tests into the standard tree? Who merges patches sent to the list into the standard tree? In my experience, it's almost anyone. Just looking for more information, -- c
Re: [svn ci] PMC documentation guidelines draft
jerry gay wrote: i've recently committed (r17998) a draft of PMC documentation guidelines, for your review. This document is meant to formalize, clarify, and extend the current de facto style for documentation of core PMCs. you'll find the document at docs/pmc/documentation.pod. highlights: ~ brings many things which are currently c-style comments into pod, which makes the information more accessible ~ groups related items together, making for easier reading ~ provides better descriptions of functions and methods, making the PMC user's life easier ~ adds stability classification to PMCs your comments, questions, patches, and commits are most welcome. As mentioned on #parrot, it misses how to use the thing. Perl Best Practices has a nice template, from which some sections could be stolen: * version: always useful, as things *will* change in the future * usage: to indicate how people should (and should not) use the pmc * author: so people know who to blame for the pmc (or praise!) ~jerry kjs
Re: [svn ci] PMC documentation guidelines draft
On Apr 5, 2007, at 10:45 AM, Klaas-Jan Stol wrote: jerry gay wrote: i've recently committed (r17998) a draft of PMC documentation guidelines, for your review. This document is meant to formalize, clarify, and extend the current de facto style for documentation of core PMCs. you'll find the document at docs/pmc/documentation.pod. highlights: ~ brings many things which are currently c-style comments into pod, which makes the information more accessible ~ groups related items together, making for easier reading ~ provides better descriptions of functions and methods, making the PMC user's life easier ~ adds stability classification to PMCs your comments, questions, patches, and commits are most welcome. As mentioned on #parrot, it misses how to use the thing. Perl Best Practices has a nice template, from which some sections could be stolen: * version: always useful, as things *will* change in the future Which version? The parrot version, or the revision, etc? Although it won't end up in any pod, the last revision is stored at the top of the fine, line three. * usage: to indicate how people should (and should not) use the pmc Often people have to abuse something before you know to tell them not to use it that way. Do you have specific examples? * author: so people know who to blame for the pmc (or praise!) ~jerry kjs
Re: [svn ci] PMC documentation guidelines draft
Joshua Isom wrote: On Apr 5, 2007, at 10:45 AM, Klaas-Jan Stol wrote: jerry gay wrote: i've recently committed (r17998) a draft of PMC documentation guidelines, for your review. This document is meant to formalize, clarify, and extend the current de facto style for documentation of core PMCs. you'll find the document at docs/pmc/documentation.pod. highlights: ~ brings many things which are currently c-style comments into pod, which makes the information more accessible ~ groups related items together, making for easier reading ~ provides better descriptions of functions and methods, making the PMC user's life easier ~ adds stability classification to PMCs your comments, questions, patches, and commits are most welcome. As mentioned on #parrot, it misses how to use the thing. Perl Best Practices has a nice template, from which some sections could be stolen: * version: always useful, as things *will* change in the future Which version? The parrot version, or the revision, etc? Although it won't end up in any pod, the last revision is stored at the top of the fine, line three. The version of the PMC; PMCs will be updated (as implementations will change over time). It's just the same as PDDs: they have a version, why not give other 'documents' a version. * usage: to indicate how people should (and should not) use the pmc Often people have to abuse something before you know to tell them not to use it that way. Do you have specific examples? well, this is kinda obvious, isn't it? Just as the synopsis for a perl module, which tells you how to use the module (for instance, how to use recdescent parse module), this usage tells you how to use the pmc. In many cases it's very simple (Integer, etc.), but others (Exporter) are not self-evident. IMHO, it's good to tell the user what the expected/typical use is. * author: so people know who to blame for the pmc (or praise!) ~jerry kjs kjs
Re: [svn ci] NCI methods now name-mangled
Am Donnerstag, 5. April 2007 00:39 schrieb Jonathan Worthington: Don't really need a policy to tell me that breaking stuff for languages folks sucks. :-) I try hard to avoid it, but unfortunately stuff slips through the net occasionally. In this case, I wasn't even aware that you could use SELF.meth(...) to call non-vtable methods, and it's done nowhere in core PMCs or I'd have noticed it. This could be also read as a notice to language maintainers: If you are using some features of parrot, then please, please submit a core test for it, if such a test doesn't exist yet. This will help Parrot and You in the future ... Thanks. leo
Re: [svn ci] NCI methods now name-mangled
At 01:33 04/04/2007 +0100, Jonathan Worthington wrote:
Hi,
I was working on starting to move class functionality into v-table
methods, as discussed on list recently. However, I hit an interesting
issue - you cannot have a METHOD or PCCMETHOD with the same name as a
vtable method. We need to be able to do that to implement the interface
specified in PDD15, though.
As of r17967, instead of turning any non-vtable method to:
Parrot_CLASSNAME_METHODNAME
Which could conflict with the vtable method, pmc2c now generates:
Parrot_CLASSNAME_nci_METHODNAME
I had to fix a couple of bits of code that directly called such methods,
but some of them had this is evil and needs fixing comments above them
anyway. (Since calling a method directly like this ignores inheritance,
it's generally the wrong thing to do.) The Complex PMC was the only PMC
that needed changing to get Parrot building again after the change.
Therefore I expect the impact of this change will be small.
Anyway, hope this is agreeable, and please do report any issues.
This new behavior breaks the build of Lua PMC.
in languages/lua/pmc/luastring.pmc
#line 295
PMC* add (PMC* value, PMC* dest) {
MMD_LuaNumber: {
PMC* n = SELF.tonumber();
if (n-vtable-base_type == dynpmc_LuaNumber) {
in languages/lua/pmc/pmc_luastring.h (generated correct)
#line 109
PARROT_DYNEXT_EXPORT extern PMC* Parrot_LuaString_nci_tonumber(Interp *, PMC*);
in languages/lua/pmc/luastring.c (generated NOT CORRECT)
#line 172 luastring.c
PMC*
Parrot_LuaString_add_LuaNumber(Interp *interp, PMC* pmc, PMC* value, PMC* dest)
{
PMC* n = Parrot_LuaString_tonumber(interp, pmc);// need
_nci_ !!!
if (n-vtable-base_type == dynpmc_LuaNumber) {
Regards.
François.
Thanks,
Jonathan
Re: [svn ci] NCI methods now name-mangled
François PERRAD wrote: Anyway, hope this is agreeable, and please do report any issues. This new behavior breaks the build of Lua PMC. For me too, even after a 'make realclean' on Parrot. In the interests of our developing policy on a stable trunk: Jonathan, fix the problem for Lua or revert the change before continuing with further development. Thanks! Allison
Re: [svn ci] NCI methods now name-mangled
Jonathan Worthington wrote: Hi, I was working on starting to move class functionality into v-table methods, as discussed on list recently. However, I hit an interesting issue - you cannot have a METHOD or PCCMETHOD with the same name as a vtable method. We need to be able to do that to implement the interface specified in PDD15, though. As of r17967, instead of turning any non-vtable method to: Parrot_CLASSNAME_METHODNAME Which could conflict with the vtable method, pmc2c now generates: Parrot_CLASSNAME_nci_METHODNAME This is a leftover from the old days when the way to override a vtable method was to define a method with an '__' name, so they never conflicted. I expect this assumption will need to be rooted out in several other places as well, so its worth a thorough review for the PMC PDD. This is a good enough fix in the meantime. (After Lua is working.) Allison
Re: [svn ci] NCI methods now name-mangled
François PERRAD wrote: This new behavior breaks the build of Lua PMC. Argh, sorry. :-( Thanks for the detailed bug report - I know where the problem is, and am working on a fix. Jonathan
Re: [svn ci] NCI methods now name-mangled
Allison Randal wrote: For me too, even after a 'make realclean' on Parrot. In the interests of our developing policy on a stable trunk: Jonathan, fix the problem for Lua or revert the change before continuing with further development. Don't really need a policy to tell me that breaking stuff for languages folks sucks. :-) I try hard to avoid it, but unfortunately stuff slips through the net occasionally. In this case, I wasn't even aware that you could use SELF.meth(...) to call non-vtable methods, and it's done nowhere in core PMCs or I'd have noticed it. Anyway, fixed in r17982. May need a realclean - I had to do one anyway to run the buildtools tests. Thanks, Jonathan
Re: [svn ci] NCI methods now name-mangled
Allison Randal wrote: This is a leftover from the old days when the way to override a vtable method was to define a method with an '__' name, so they never conflicted. Not really - this was a conflict in the names of the methods at a C level. The '__' prefix was a PIR-level thing. In PIR we may have moved away from using name mangling to prevent the conflict, but in C that's probably all we've got at our disposal. Note that name of method at a C level and name of the method for method lookups do not have to be at all related. I expect this assumption will need to be rooted out in several other places as well, so its worth a thorough review for the PMC PDD. Sure, I'm sure there's more than one way to deal with this issue, but for now this works and unblocks stuff. Thanks, Jonathan
Re: [svn ci] NCI methods now name-mangled
Jonathan Worthington wrote: Anyway, fixed in r17982. May need a realclean - I had to do one anyway to run the buildtools tests. Awesome. Works for me even without realclean. Thanks! Allison
Re: SVN tips in wranglers.pod
On 11/7/06, Paul Cochrane [EMAIL PROTECTED] wrote: Thanks Bernhard! Added to the list. Paul When the commit is associated with a ticket in RT, I usually copypaste the ticket header. e.g. #39197: [CAGE] lib/Parrot/Test.pm ignores core dumps failures!CU, Bernhard paul~ i took the liberty of beefing up the examples in your patch, adding some more info, and committing it. you'll find it in r15225. ~jerry
Re: SVN tips in wranglers.pod
Paul Cochrane schrieb: In the attached patch, I've added a section on SVN usage tips for the doc/dev/wranglers.pod documentation, mostly distilled from wisdom on #parrot. Is there anything else people think should be added before I commit the patch? Or any changes to the pod itself? When the commit is associated with a ticket in RT, I usually copypaste the ticket header. e.g. #39197: [CAGE] lib/Parrot/Test.pm ignores core dumps failures!CU, Bernhard
Re: SVN tips in wranglers.pod
Thanks Bernhard! Added to the list. Paul When the commit is associated with a ticket in RT, I usually copypaste the ticket header. e.g. #39197: [CAGE] lib/Parrot/Test.pm ignores core dumps failures!CU, Bernhard
Re: SVN::Web
Nik Clayton wrote: Hi Adam, Adam Kennedy wrote: Phase N is my company, and http://svn.phase-n.com/svn/cpan is the collaborative subversion repository for my code, that now includes PPI, which you've expressed a desire to have bugs fixed in I believe a number of times. I see you're using Insurrection. I was wondering if you'd looked at SVN::Web before using Insurrection, and if so, if there are any features missing from SVN::Web that you'd use. SVN::Web can be found at http://jc.ngo.org.uk/svnweb/jc/browse/nik/CPAN/SVN-Web/trunk/ and, of course, on CPAN. Hmm... well I can only see the front-end part there, where to be honest I don't actually need, and came for free with Insurrection. What I'm using it for is the administration side. - Admin of multiple repositories - Email-based accounts - Disabled, Read-Only, Read-Write or Admin on a per-repository basis (that's all I need anyway) - Automated password $stuff. That is, password auto-creation, emailing account details on creation or request, password update ability. - Automatic creation of additional repositories As for the rest, like disk quotas and such, I don't particularly need that either. My big need is very easy account management. Something that minimizes the number of seconds I have to look at a web svn tool. Because the whole point of the exercise for me is to make it so easy to have people fix bugs, I can do the whole account/review/release cycle in less than 1 minute or so, so I can have bugs fixed in modules without distracted from what I'm working on. Adam K
Re: SVN::Web
Nik Clayton wrote: Hi Adam, [...] Mea culpa -- that was supposed to be an e-mail. N
Re: SVN::Web
Nik Clayton wrote: Nik Clayton wrote: Hi Adam, [...] Mea culpa -- that was supposed to be an e-mail. N That's totally fine. :) I used Insurrection because it was there... and I didn't know of anything else that worked. And once you get past the fact that it's impossible to install, it does the admin stuff quite well. (except it's missing an I forgot my password feature) In short, I don't want to _see_ the repository, I want to _run_ the repository. What's SVN::Web like for that? Adam K
Re: SVN::Web
Hi Nik, * Nik Clayton [EMAIL PROTECTED] [2006-05-12 15:40]: Mea culpa -- that was supposed to be an e-mail. well, that’s what it was, too. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: svn links for the Architecture section on the website?
Given the recent explosion of svn commits in the synopses, and the fact that the versions of the synopses on the dev.perl.org/perl6 site are lagging a bit, would it make sense to add a link to the svn site to the Synopses page? I'd rather not. The ones on the dev site shouldn't have been more than 24 hours out of date. I've updated the cron job so they should now update every 6 hours. -R
Re: svn performance
On Sat, 4 Mar 2006, Leopold Toetsch wrote: On Feb 28, 2006, at 19:27, Andy Dougherty wrote: Executive summary -- svn co on Solaris 8 is still *slow*! Ill stick to fetching snapshots with wget. Dumb question? Why 'svn co' instead of incrementally updating with 'svn up'? It's not a dumb question. I only occasionally have a chance to work on Parrot. For a variety of reasons, including disk space limitations, I find it inconvenient to keep an svn copy locally. -- Andy Dougherty [EMAIL PROTECTED]
Re: svn performance
On Feb 28, 2006, at 19:27, Andy Dougherty wrote: Executive summary -- svn co on Solaris 8 is still *slow*! Ill stick to fetching snapshots with wget. Dumb question? Why 'svn co' instead of incrementally updating with 'svn up'? leo
Re: svn performance
On Fri, Feb 17, 2006 Andy Dougherty wrote: [svn co on Solaris 8 is painfully *slow*] $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz real0m16.84s user0m0.09s sys 0m0.20s $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk real 2:01:50.3 user 1:02.0 sys44.9 It's something specific to svn. No, I don't know what. $ svn --version svn, version 1.1.3 (r12730) compiled Mar 31 2005, 13:19:13 Thanks to everyone for suggestions. Here's a summary of what I found: jerry gay: can't hurt to upgrade... It didn't hurt (too much), but, alas, it didn't help either. Matt Fowles: Do you, perchance, sit behind an http proxy server? Try: time svn co https://svn.perl.org/parrot/trunk parrot-trunk Me: svn: Unrecognized URL scheme 'https://svn.perl.org/parrot/trunk' I don't know why. I have OpenSSL installed in /usr/local where svn should have found it when building. Bob Rogers: I had the same problem just last week. To fix it, I upgraded to Subversion 1.3.0 from the tarball, and discovered that you don't get HTTPS support unless you explicitly specify the --with-ssl option to configure, which I hadn't realized when I installed 1.1.3. Alas that didn't work. Even presetting CCFLAGS, CPPFLAGS, and every other sort of flags I could find documented, and passing all the --with-xxx options specifying the full path locations to OpenSSL, the build process would find it using the C compiler, but then trample on the CPPFLAGS and fail to find them with the preprocessor, and then conclude that I didn't have OpenSSL installed (even though it had just successfully correctly identified my OpenSSL version in the previous step!) Much painful hand editing of configure scripts and makefiles later, it turns out that the http: vs. https: stuff doesn't make any significant difference. Oh well. Running svn under truss didn't help either -- no particular type of syscall stood out as being slow. Executive summary -- svn co on Solaris 8 is still *slow*! Ill stick to fetching snapshots with wget. -- Andy Dougherty [EMAIL PROTECTED]
Re: svn performance
On Fri, Feb 17, 2006 at 08:38:26AM -0800, Robert Spier wrote: snapshots or releases. And, since a checkout takes about an hour (last time I checked) I tend to be too lazy to fetch one just to make a patch. Only if you're checking out to a Commodore 64. Or possibly hand-transcribing the bits. [EMAIL PROTECTED] /tmp$ time svn co http://svn.perl.org/parrot/trunk parrot-trunk /dev/null real1m4.827s user0m4.108s sys 0m2.852s From a random starbucks to my laptop: real1m11.923s user0m6.068s sys 0m4.432s
Re: svn performance
All~ On 2/17/06, jesse [EMAIL PROTECTED] wrote: On Fri, Feb 17, 2006 at 08:38:26AM -0800, Robert Spier wrote: snapshots or releases. And, since a checkout takes about an hour (last time I checked) I tend to be too lazy to fetch one just to make a patch. Only if you're checking out to a Commodore 64. Or possibly hand-transcribing the bits. I could check it out over iridium dial up... Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: svn performance
On Fri, 17 Feb 2006, Matt Fowles wrote: All~ On 2/17/06, jesse [EMAIL PROTECTED] wrote: On Fri, Feb 17, 2006 at 08:38:26AM -0800, Robert Spier wrote: snapshots or releases. And, since a checkout takes about an hour (last time I checked) I tend to be too lazy to fetch one just to make a patch. Only if you're checking out to a Commodore 64. Or possibly hand-transcribing the bits. I could check it out over iridium dial up... Sigh. I wish it were that simple, or that funny. $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz real0m16.84s user0m0.09s sys 0m0.20s $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk real 2:01:50.3 user 1:02.0 sys44.9 It's something specific to svn. No, I don't know what. -- Andy Dougherty [EMAIL PROTECTED]
Re: svn performance
Sigh. I wish it were that simple, or that funny. $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz real0m16.84s user0m0.09s sys 0m0.20s $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk real 2:01:50.3 user 1:02.0 sys44.9 It's something specific to svn. No, I don't know what. What version of subversion are you using? -R
Re: svn performance
Andy~ On 2/17/06, Andy Dougherty [EMAIL PROTECTED] wrote: On Fri, 17 Feb 2006, Matt Fowles wrote: All~ On 2/17/06, jesse [EMAIL PROTECTED] wrote: On Fri, Feb 17, 2006 at 08:38:26AM -0800, Robert Spier wrote: snapshots or releases. And, since a checkout takes about an hour (last time I checked) I tend to be too lazy to fetch one just to make a patch. Only if you're checking out to a Commodore 64. Or possibly hand-transcribing the bits. I could check it out over iridium dial up... Sigh. I wish it were that simple, or that funny. $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz real0m16.84s user0m0.09s sys 0m0.20s $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk real 2:01:50.3 user 1:02.0 sys44.9 It's something specific to svn. No, I don't know what. $ svn --version svn, version 1.1.4 (r13838) compiled May 13 2005, 06:29:47 How bout you? Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: svn performance
On Fri, 17 Feb 2006, Matt Fowles wrote: On 2/17/06, Andy Dougherty [EMAIL PROTECTED] wrote: Sigh. I wish it were that simple, or that funny. $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz real0m16.84s user0m0.09s sys 0m0.20s $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk real 2:01:50.3 user 1:02.0 sys44.9 It's something specific to svn. No, I don't know what. $ svn --version svn, version 1.1.4 (r13838) compiled May 13 2005, 06:29:47 $ svn --version svn, version 1.1.3 (r12730) compiled Mar 31 2005, 13:19:13 -- Andy Dougherty [EMAIL PROTECTED]
Re: svn performance
On Fri, 17 Feb 2006, Matt Fowles wrote: On 2/17/06, Andy Dougherty [EMAIL PROTECTED] wrote: $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz real0m16.84s $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk real 2:01:50.3 It's something specific to svn. No, I don't know what. Do you, perchance, sit behind an http proxy server? Try: time svn co https://svn.perl.org/parrot/trunk parrot-trunk
Re: svn performance
On 2/17/06, Matt Fowles [EMAIL PROTECTED] wrote: $ svn --version svn, version 1.1.4 (r13838) compiled May 13 2005, 06:29:47 How bout you? can't hurt to upgrade... svn --version svn, version 1.3.0 (r17949) compiled Jan 15 2006, 23:18:48 ~jerry
Re: svn performance
On Fri, 17 Feb 2006, jesse wrote: On Fri, 17 Feb 2006, Matt Fowles wrote: On 2/17/06, Andy Dougherty [EMAIL PROTECTED] wrote: $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz real0m16.84s $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk real 2:01:50.3 It's something specific to svn. No, I don't know what. Do you, perchance, sit behind an http proxy server? Not that I know of (though I'm not sure how I'd know), and no other mode of communication is similarly affected (i.e. cvs, rsync, etc., all work fine). Try: time svn co https://svn.perl.org/parrot/trunk parrot-trunk svn: Unrecognized URL scheme 'https://svn.perl.org/parrot/trunk' I don't know why. I have OpenSSL installed where svn should have found it when building. If I can find the free time, perhaps I'll try upgrading, though I have no reason to think it'll solve the problem. I don't use svn for anything else, and wget works just fine for fetching the snapshots, so this hasn't been a priority for me. -- Andy Dougherty [EMAIL PROTECTED]
Re: svn performance
From: Andy Dougherty [EMAIL PROTECTED] Date: Fri, 17 Feb 2006 17:23:55 -0500 (EST) On Fri, 17 Feb 2006, jesse wrote: Try: time svn co https://svn.perl.org/parrot/trunk parrot-trunk svn: Unrecognized URL scheme 'https://svn.perl.org/parrot/trunk' I don't know why. I have OpenSSL installed where svn should have found it when building. I had the same problem just last week. To fix it, I upgraded to Subversion 1.3.0 from the tarball, and discovered that you don't get HTTPS support unless you explicitly specify the --with-ssl option to configure, which I hadn't realized when I installed 1.1.3. I don't understand why this is necessary; HTTP and HTTPS support both use Neon, and so I would assume that Neon is doing all the TLS stuff itself. I guess SVN is supplying it with certs, so it needs OpenSSL, but you'd think it could check to see if Neon was built to use OpenSSL, and take it from there. Or even just probe for OpenSSL directly. Oh, well . . . -- Bob Rogers http://rgrjr.dyndns.org/
Re: svn performance
On Fri, Feb 17, 2006 at 05:23:55PM -0500, Andy Dougherty wrote: On Fri, 17 Feb 2006, jesse wrote: Do you, perchance, sit behind an http proxy server? Not that I know of (though I'm not sure how I'd know), and no other mode of communication is similarly affected (i.e. cvs, rsync, etc., all work fine). Perhaps your behind a transparent http proxy. If that's the case I would expect TLS to resolve the issue. -J -- pgp0ONuNQ90HG.pgp Description: PGP signature
Re: svn access (was: [perl #38576] [PATCH] Make DETAIL_MEMORY_DEBUG work. )
On Wed, 15 Feb 2006, Leopold Toetsch via RT wrote: Andy, I've already asked once: don't you have svn access? If no (and if you want it) please mail me your auth.perl.org account data, to get you svn priv bits. I do have priv bits, and have on rare occasion used them, but I don't usually have an svn repository available -- I usually work with the snapshots or releases. And, since a checkout takes about an hour (last time I checked) I tend to be too lazy to fetch one just to make a patch. Still, I'll take your message to heart, and when feasible (and appropriate!) just try to check stuff in directly. -- Andy Dougherty [EMAIL PROTECTED]
Re: [svn ci] Better gdb support (r11581)
Leopold Toetsch wrote: A debug session snippet: I've changed the syntax now to the more conforming convenience var syntax for registers: (gdb) pp $I1 I1=3 $x0 ... $x9 are predefined for x in S,I,N (no PMCs yet) This is the same as printing HW registers: (gdb) p $eax $1 = 135154512 And: (gdb) pp N28 # general syntax leo
Re: [svn ci] Changes to dynoplibs build process
On 1/10/06, Jonathan Worthington [EMAIL PROTECTED] wrote: Jonathan Worthington [EMAIL PROTECTED] wrote: Note that dynamic op libs do not *work* on Win32 yet They do now - I'm using them with my .NET to PIR translator and they work nicely. I would really like some feedback from MinGW and cygwin folks on how dynoplibs build and work for them Works straight off on cygwin. :-) Gives the answers you wanted. How much info did you want about the way it builds? [I suspect that this isn't the answer that your asking for, but it seems to run ops2c.pl for each runcore on the dynops, and then builds .o from each one, and then finally just builds DLLs from them (i.e. 2x4 DLLs)] cygwin seems to be able to use both .def files or just export all the symbols from a DLL, the latter being what is done here. Nick
Re: [svn ci] Changes to dynoplibs build process
Nick Glencross [EMAIL PROTECTED] wrote: On 1/10/06, Jonathan Worthington [EMAIL PROTECTED] wrote: I would really like some feedback from MinGW and cygwin folks on how dynoplibs build and work for them Works straight off on cygwin. :-) Gives the answers you wanted. That's great, thanks. How much info did you want about the way it builds? I badly phrased my question - I guess I shoulda written if rather than how. That's what happens when I write emails at 2AM. ;-) [I suspect that this isn't the answer that your asking for, but it seems to run ops2c.pl for each runcore on the dynops, and then builds .o from each one, and then finally just builds DLLs from them (i.e. 2x4 DLLs)] That's what I'd expect, yep. cygwin seems to be able to use both .def files or just export all the symbols from a DLL, the latter being what is done here. Good. I want to do away with the .def files for all platforms we can - it's a pain as the main one keeps getting out of sync with the code. Knowing cygwin can handle exporting by decorating the code helps towards that. And I'd guess it points to MinGW handling it too as both use gcc. Thanks for testing, Jonathan
Re: [svn ci] Changes to dynoplibs build process
Jonathan Worthington [EMAIL PROTECTED] wrote: Note that dynamic op libs do not *work* on Win32 yet They do now - I'm using them with my .NET to PIR translator and they work nicely. I would really like some feedback from MinGW and cygwin folks on how dynoplibs build and work for them, as I've taken the mark the code approach rather than the DEF file approach. To test, build a (clean) Parrot and then:- cd src\dynoplibs make ..\..\parrot dan.pasm ..\..\parrot test.pasm First of those should print 11, second a load of stuff ending with 42, if it works. Thanks, Jonathan
Re: Svn Commit list...
... seems to be dead for about a day now, though I know commits are going through. Fixed. BCCing webmaster at perl dot org, where this will hopefully open a ticket. THANK YOU. This meant the message got seen much earlier than it otherwise would, and because of the BCC, no collateral damage. -R
Re: [svn ci] Perl 5 tests for PGE::P5Regexp (update)
On 11/21/05, jerry gay [EMAIL PROTECTED] wrote: i've checked in a subset of Perl 5.9.2's regexp tests for PGE to chew on. for now, i modified the stolen harness to emit PIR. the harness is currently very ugly... that won't be for long, however, as i'll refactor it soon. it's been refactored, and is much less ugly now. the refactoring has allowed me to expand on the ability to parse perl match result vars like '$', '$-[4]', '$1', etc. and that has allowed me to include even more of the 960 perl 5 tests, in fact, 800 of them. the final 160 are skipped by the harness because there are too many of them which cause parrot to crash, so i'll wait until the bugs are fixed before enabling those tests. of the 800 tests the harness cares about, i decided to skip 290 tests; those which are designed to produce errors, expose perl bugs, those with syntax PGE doesn't understand (e.g. trailing modifiers,) and those which cause parrot to devour system resources just as vonnegut's Ice-Nine enveloped the earth. failing tests (there are approximately 155 of them) are currently marked todo, to prevent noise in parrot's test harness from PGE::P5Regexp, which is far from complete. i'm much happier seeing unexpected success messages rather than expected failures during development, so this should be the norm in the test suite. subtracting the skipped and todo tests from the total leaves about 360 passing tests from perl 5's test suite. thanks to patrick's work on PGE and P5Regexp, we now have a perl 5 regular expression parser capable of handling things like 'a:[b]:' =~ /([[:]+)/ nice work, patrick. ~jerry
Re: [svn ci] Debug segment updates
Jonathan Worthington [EMAIL PROTECTED] wrote: What's left? Making this work for when you .include files in PIR. Which means monkeying with the lexer and IMCC. shudder I've done it and it's available to play with. I'll admit now that, despite having covered quite a bit of the IMCC codebase while working out the best way to do this, I'm still no expert on how it works so this may not be perfect. Anyway, an example of the kinda thing that now works:- $ cat crash1.pir # Example .sub main :main _test() .end .include crash2.pir .sub _test2 _does_not_exist() .end $ cat crash2.pir .sub _test _test2() .end $ parrot crash1.pir Name '_does_not_exist' not found current instr.: '_test2' pc 24 (crash1.pir:9) called from Sub '_test' pc 17 (crash2.pir:2) called from Sub 'main' pc 7 (crash1.pir:3) Note how the correct files are named in the backtrace now; before it would always say crash1.pir no matter what file it was in. Also fixed some warnings, plus a bug that pre-dated my debug seg work that meant sometimes a file didn't get a debug segment added to it.. Happy debugging, Jonathan
Re: [svn ci] (r8717) Win32 Dynclasses
Woot! None of the tests are currently failing on OS X, though there are several TODOs hey. Many (All??) of the failing tests are TODOs: perhaps the test harness isn't happy about TODOs on win32, for some reason. Do TODO tests report as passed in the core suite? If so, it's probably something with lib/Parrot/Test/Tcl.pm ... Thanks for your work on this, Jonathan! On Jul 28, 2005, at 4:11 PM, Jonathan Worthington wrote: Hi, Dynclasses now work on Win32 when building Parrot with the MS Visual Studio compiler. That means that all t\dynclass\*.t passes. :-) I've also (after ci'ing a fix to config/gen/makefiles/tcl.in) managed to build Partcl on Win32 and run the tests. Here's what I'm seeing. Failed Test Status Wstat Total Fail Failed List of Failed -- t\cmd_expr.t 433 6.98% 41-43 t\cmd_linsert.t51 20.00% 2 t\cmd_proc.t 41 25.00% 4 t\cmd_source.t 21 50.00% 1 t\cmd_string.t374 10.81% 16, 33-35 t\cmd_time.t 11 100.00% 1 t\tcl_backslash.t 162 12.50% 12, 14 t\tcl_command_subst.t 101 10.00% 10 t\tcl_misc.t 121 8.33% 12 t\tcl_pir_compiler.t 31 33.33% 3 Failed 10/39 test scripts, 74.36% okay. 16/266 subtests failed, 93.98% okay. Any problems, let me know. Take care, Jonathan
Re: SVN revision (was: [perl #xxxxxx] Badly balanced at classes/pmc2c2.pl)
On Monday 11 April 2005 17:54, Leopold Toetsch wrote: BTW: a nice to have: include SVN revision of local copy in bug report. I'll implement it. jens
Re: svn
William Coleda wrote: I'd like to work on a patch to move all the perl* pmcs into dynclasses, which would involve quite a bit of file moving, Hi, I'm currently working on moving the implementation of the PerlHash PMC into a Hash PMC. The plan is to let PerlHash be an extension of Hash. Currently there are still some problems with regard to dumping and freezing. When these problems are resolved, I'll try to switch the Parrot core to using the Hash PMC internally. I'll try to provide a patch this weekend or next week. CU, Bernhard -- ** Dipl.-Physiker Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
Re: svn
On Wed, Dec 08, 2004 at 06:21:18PM -0700, Phil Frost wrote: On Wed, Dec 08, 2004 at 07:19:07PM -0500, William Coleda wrote: Is there a plan at any point to move to an svn repository from cvs? I'd like to work on a patch to move all the perl* pmcs into dynclasses, which would involve quite a bit of file moving, and I'll happily wait for svn if we're going that way, since it'll be smoother. If you are planning on switching revision control systems, I suggest something other than svn. There are a number of other systems available to the free software developer which offer serious advantages which might not be aparent to those who have not experienced them. Among them are arch, darcs, and monotone. Arch is out. Its Win32 support is crap. http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20Support monotone is out. Its too unstable. They just made an incompatible change requiring *lossy* migration. http://www.venge.net/monotone/README.changesets This leaves just Darcs. I would eshew Darcs for a large, Open project for these reasons. * Its immature. What happens if we hit a bug and wedge the repository or worse, corrupt it? What happens if they introduce an incompatible change as monotone did? * We don't have any Darcs experts to solve the hard problems. * The darcs manual proudly proclaims Darcs is refreshingly different from CVS. Because of the different models used by cvs and darcs, it is difficult to provide a complete equivalence between cvs and darcs. Parrot has a lot of CVS users. They do not want refreshingly different. However, this does not mean distributed version control is out. There is an option. SVK. Its distributed version control WITHOUT everybody having to learn and run SVK. SVK is a *client* of a Subversion (or CVS or Perforce) repository. This means Parrot can switch to Subversion and those that want to play with distributed version control can do so without everybody else having to drink their brand of Kool-Aid. For reference, here's the gauntlet I'd make any new revision control system for Parrot run through. 1) Are they easily available on all the platforms Parrot is? Various Unixen, OS X, Windows. Is there any hope for a VMS port? 2) Can the command set and workflow be made similar to CVS? You're going to have enough trouble convincing people to leave the warm, familiar, comforting, if slightly demented, embrace of CVS that they have known for years. Its best if the new system works as much like CVS as possible. 3) Do we need distributed version control? Can this be gotten without having to drink their brand of Kool-Aid, such as by individuals using SVK over a Subversion repository? 4) Are these systems mature enough that they're not going to fall apart under a large repository? Or that we don't have to worry about hitting a bug which corrupts the repository or gets it into an inconsistent state? Or that they'll introduce an incompatible change? 5) Do we have any experts with these new version control systems? Someone who knows how to solve the hairy problems. 6) Can we convert the existing CVS repository to it without losing revision histories? 7) Can we supply a read-only CVS mirror of the repository? 8) What's the documentation like? Is there a well-written, comprehensive tutorial? Can I get going in under an hour? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Home of da bomb
Re: svn
On Wed, Dec 08, 2004 at 07:19:07PM -0500, William Coleda wrote: Is there a plan at any point to move to an svn repository from cvs? I'd like to work on a patch to move all the perl* pmcs into dynclasses, which would involve quite a bit of file moving, and I'll happily wait for svn if we're going that way, since it'll be smoother. If you are planning on switching revision control systems, I suggest something other than svn. There are a number of other systems available to the free software developer which offer serious advantages which might not be aparent to those who have not experienced them. Among them are arch, darcs, and monotone. I have used arch extensively, and I found it to be a powerfull tool but with a somewhat poorly designed interface. I have now been using darcs for several weeks and found it to be extremely well designed, but I've not used it long enough to endorse it fully. Monotone I have not used but it offers many of the same advantages.
Re: svn
Michael G Schwern [EMAIL PROTECTED] wrote: 1) Are they easily available on all the platforms Parrot is? Various Unixen, OS X, Windows. Is there any hope for a VMS port? Can we add are there GUIs for Windows, OS X, and other platforms with wimpy users? ;^) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: svn
On Thu, Dec 09, 2004 at 04:35:26PM -0800, Brent 'Dax' Royal-Gordon wrote: Michael G Schwern [EMAIL PROTECTED] wrote: 1) Are they easily available on all the platforms Parrot is? Various Unixen, OS X, Windows. Is there any hope for a VMS port? Can we add are there GUIs for Windows, OS X, and other platforms with wimpy users? ;^) A) Wimpy users don't hack Parrot and a lack of a GUI for the VC is not going to be what stops them. B) If there's not a GUI now there's nothing stopping someone from writing a GUI tomorrow. So no, I would not consider a GUI to be important. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ 7. It is always something -- RFC 1925
Re: svn
On Thu, 9 Dec 2004, Michael G Schwern wrote: On Thu, Dec 09, 2004 at 04:35:26PM -0800, Brent 'Dax' Royal-Gordon wrote: Michael G Schwern [EMAIL PROTECTED] wrote: 1) Are they easily available on all the platforms Parrot is? Various Unixen, OS X, Windows. Is there any hope for a VMS port? Can we add are there GUIs for Windows, OS X, and other platforms with wimpy users? ;^) A) Wimpy users don't hack Parrot and a lack of a GUI for the VC is not going to be what stops them. B) If there's not a GUI now there's nothing stopping someone from writing a GUI tomorrow. So no, I would not consider a GUI to be important. I chuckled as I read this. I love the term wimpy users. Also, if I may, there are various GUIs for svn. One of them is even written in java so theoretically it should run everywhere. http://jsvn.alternatecomputing.com/ I haven't used that one. The one I used was written for Unix using Qt. I forgot what it was called.. but this jsvn seems pretty cool. My two cents. -Calin
Re: svn
Will~ On Wed, 08 Dec 2004 19:19:07 -0500, William Coleda [EMAIL PROTECTED] wrote: Is there a plan at any point to move to an svn repository from cvs? I'd like to work on a patch to move all the perl* pmcs into dynclasses, which would involve quite a bit of file moving, and I'll happily wait for svn if we're going that way, since it'll be smoother. While I personally like the idea, I think it is unlikely given how much slower svn is on sizable repositories. Of course I have not tried it recently, so maybe that has changed... All that being said, I am in absolutely no position of authority about this... Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: svn
While I personally like the idea, I think it is unlikely given how much slower svn is on sizable repositories. Of course I have not tried it recently, so maybe that has changed... All that being said, I am in absolutely no position of authority about this... This is, and always has been, (since 1.0 at least), a myth. We have always been at war with Apache has moved most of their projects to SVN. It's probably ready. -R
Re: svn
On Wed, Dec 08, 2004 at 10:16:21PM -0500, Matt Fowles wrote: While I personally like the idea, I think it is unlikely given how much slower svn is on sizable repositories. Of course I have not tried it recently, so maybe that has changed... If you wish to try out a recent Subversion on some sizable source there's a mirror of the maint and bleadperl Perforce repositories here. http://svn.clkao.org/svnweb/perl You can pull them out using svn://svn.clkao.org/perl Subversion has improved a lot. I'm using it now. If you do try it I recommend going straight to 1.1.1 and using fsfs based repositories. Keep in mind that SVN is slower on checkouts than CVS. However diff is a purely local operation. And if you're using something like SVK network traffic isn't much of an issue after all after the initial mirror. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Now we come to that part of the email you've all been waiting for--the end.
