Re: x.y.z numbering and releases
On Wed, Jan 18, 2006 at 09:45:54PM -0700, Martin Sebor wrote: > However, I believe that the issue can be just as effectively > dealt with by implementing the -rcN (or similar) suffix policy > that Bill mentioned in his first post, with the additional > (and IMO essential) advantage of preserving the well-established > meaning of the version number grounded in precisely defined > technical criteria. It's still just as precisely defined technically (go look at APR's versioning guidelines[1]). The real point of a release is whether we (as a PMC) 'bless' it by saying it passes all of the standard Apache release procedures. The real problem you have with rc sequences is that you end up having to vote twice for a release as you need to change the tarballs to go from an rc to a final release. It's almost never worth the hassle, IMHO. -- justin 1. http://apr.apache.org/versioning.html
Re: x.y.z numbering and releases
Martin Sebor wrote: Justin Erenkrantz wrote: --On January 18, 2006 5:30:04 PM -0700 Martin Sebor <[EMAIL PROTECTED]> wrote: I don't think of the name of a file mentioned in emails as a release, least of all when it refers to a transient file in someone's home directory. Similarly, I don't consider an SVN branch to be an actual release, even if its contents were identical to it. With this mindset I can only see one potential effect of skipping versions on users -- that of confusion. One of the problems in working in open-source projects is that everyone can see the release immediately. Therefore, we don't have the ability to 'take' a release back - once you tag it or announce it in any public forum, it's gone. By enforcing a 'cheap' version number policy, we remove any confusion: were they using the '1.2.3' release from Jan 10 or was that the '1.2.3' release from Jan 15? Instead, we make it crystal clear what the release was by only allowing that version to be used once. -- justin I understand the motivation behind the policy and fully support the goal of preventing the problem it is designed to address. However, I believe that the issue can be just as effectively dealt with by implementing the -rcN (or similar) suffix policy that Bill mentioned in his first post, with the additional (and IMO essential) advantage of preserving the well-established meaning of the version number grounded in precisely defined technical criteria. I agree with Martin -if- the SVN tag is also designated tags/1.2.3-rcN until it's voted in, and then copied or renamed to tags/1.2.3 upon release.
Re: x.y.z numbering and releases
Justin Erenkrantz wrote: --On January 18, 2006 5:30:04 PM -0700 Martin Sebor <[EMAIL PROTECTED]> wrote: I don't think of the name of a file mentioned in emails as a release, least of all when it refers to a transient file in someone's home directory. Similarly, I don't consider an SVN branch to be an actual release, even if its contents were identical to it. With this mindset I can only see one potential effect of skipping versions on users -- that of confusion. One of the problems in working in open-source projects is that everyone can see the release immediately. Therefore, we don't have the ability to 'take' a release back - once you tag it or announce it in any public forum, it's gone. By enforcing a 'cheap' version number policy, we remove any confusion: were they using the '1.2.3' release from Jan 10 or was that the '1.2.3' release from Jan 15? Instead, we make it crystal clear what the release was by only allowing that version to be used once. -- justin I understand the motivation behind the policy and fully support the goal of preventing the problem it is designed to address. However, I believe that the issue can be just as effectively dealt with by implementing the -rcN (or similar) suffix policy that Bill mentioned in his first post, with the additional (and IMO essential) advantage of preserving the well-established meaning of the version number grounded in precisely defined technical criteria. Martin
Re: x.y.z numbering and releases
--On January 18, 2006 5:30:04 PM -0700 Martin Sebor <[EMAIL PROTECTED]> wrote: I don't think of the name of a file mentioned in emails as a release, least of all when it refers to a transient file in someone's home directory. Similarly, I don't consider an SVN branch to be an actual release, even if its contents were identical to it. With this mindset I can only see one potential effect of skipping versions on users -- that of confusion. One of the problems in working in open-source projects is that everyone can see the release immediately. Therefore, we don't have the ability to 'take' a release back - once you tag it or announce it in any public forum, it's gone. By enforcing a 'cheap' version number policy, we remove any confusion: were they using the '1.2.3' release from Jan 10 or was that the '1.2.3' release from Jan 15? Instead, we make it crystal clear what the release was by only allowing that version to be used once. -- justin
[jira] Closed: (STDCXX-12) publish Class Reference and User Guide on the stdcxx site
[ http://issues.apache.org/jira/browse/STDCXX-12?page=all ] Martin Sebor closed STDCXX-12: -- Resolution: Fixed After some discussion we've finally figured out how to do this -- see: http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200601.mbox/[EMAIL PROTECTED] > publish Class Reference and User Guide on the stdcxx site > - > > Key: STDCXX-12 > URL: http://issues.apache.org/jira/browse/STDCXX-12 > Project: STDCXX > Type: Improvement > Components: Web > Versions: 4.1.2 > Environment: All > Reporter: Martin Sebor > Assignee: Martin Sebor > Priority: Critical > Fix For: 4.1.4 > > The stdcxx documentation in svn needs to be published in a browsable format > on the project Web site. Currently only the sources in svn are viewable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: x.y.z numbering and releases
William A. Rowe, Jr. wrote: [...] The candidate and number are pitched. We have a mantra, "version numbers are cheap". Thanks for the clarification. [...] There is typically no allowance in these rules for making version changes that are not determined by changes and differences between actual code releases. Yes, and in fact (unless something went HORRIBLY wrong) the never released version 1.2.3 enjoys versioning compatibility with 1.2.2 and 1.2.4 per the project's policy. It just simply never existed. True. The only snag here is that our existing policy deliberately prevents this from happening. [...] You can argue the converse; treating each and every release as equally stable doesn't help the user. Stating 'whoops, 1.2.3 just wasn't up to par, so we've released 1.2.4 following 1.2.2' gives the user one reassurance; the bad releases don't make it out the door. I don't think of the name of a file mentioned in emails as a release, least of all when it refers to a transient file in someone's home directory. Similarly, I don't consider an SVN branch to be an actual release, even if its contents were identical to it. With this mindset I can only see one potential effect of skipping versions on users -- that of confusion. That said, if sticking some suffix (such as -rcN) at the end of the "release candidate" tarball helps dispel even the slightest concern of mistaking a pre-release tarball for the real thing, I will gladly support doing so within the stdcxx release policy. As always, thanks for the feedback! Martin
Re: x.y.z numbering and releases
Martin Sebor wrote: William A. Rowe, Jr. wrote: In the httpd project, the RM (release manager) tags a build, with the final version number. If that tarball changes after it leaves their hands, and is in the hands of testers, it's never modified (much) . I'm not sure this means that the httpd version of the new tarball stays the same or not if the old tarball fails to get an approval. The candidate and number are pitched. We have a mantra, "version numbers are cheap". and 2) know what bugs people are pointing at. If there are several x.y.z packages all identically named, it's harder to know that the reporter is pointing at something that's already fixed, newly broken, or not working the entire cycle. I agree. My concern with changing the version number during a release is technical rather than procedural. There is typically no allowance in these rules for making version changes that are not determined by changes and differences between actual code releases. Yes, and in fact (unless something went HORRIBLY wrong) the never released version 1.2.3 enjoys versioning compatibility with 1.2.2 and 1.2.4 per the project's policy. It just simply never existed. The version number should also be an indicator of continuity (or its lack) between releases of the library. Users of the latest release of a library should be able to decide whether to upgrade to the new fully compatible release without having to wonder what they might have missed in the releases in between or whether a prior release might be sufficient or safer. You can argue the converse; treating each and every release as equally stable doesn't help the user. Stating 'whoops, 1.2.3 just wasn't up to par, so we've released 1.2.4 following 1.2.2' gives the user one reassurance; the bad releases don't make it out the door. Bill
Re: x.y.z numbering and releases
William A. Rowe, Jr. wrote: Martin Sebor wrote: Justin Erenkrantz wrote: In the future, you should not reuse the version - therefore, this should really be 4.1.4. Once, 4.1.3 is posted, it's 'gone' (regardless of whether it passes or not). Therefore, a vote should be with respect to a specific tarball. If that tarball changes (and a new version is pushed out), you need to get the minimum 3 +1s on that specific tarball. This is an interesting policy that I think deserves to be discussed further. Let me comment on it in a separate thread so as not to detract from the vote. Absolutely not ;-) Here's your thread for discussion of numbering, going forwards... In the httpd project, the RM (release manager) tags a build, with the final version number. If that tarball changes after it leaves their hands, and is in the hands of testers, it's never modified (much) . I'm not sure this means that the httpd version of the new tarball stays the same or not if the old tarball fails to get an approval. Some ASF projects roll a -pre1 or -rc1 tarball. It's clear to the user who downloads it that this is almost it, and is being voted on. If they don't get cleared, lets say three files change, then they roll -pre2 or -rc2. That seems like a reasonable policy to distinguish the tarballs. Let me write up something along these lines for stdcxx and post it for review. Now... in fairness Justin is right; you must vote on the actual tarball you will ship. You can't make an incremental change and consider the old votes still valid. Heck, maybe those voters even disagree with the suggested change, or how it was packaged? But please consider, the candidate must be clearly named. We have to be able to determine that Joe, Sandy and Pat all voted +1 on the -same tarball-. If we do that with -pre1/-pre2 or -rc1/-rc2, or as httpd does with x.y.z (ditched or adopted as appropriate), it doesn't so much matter. It really matters that we 1) know what people voted on, Understood. and 2) know what bugs people are pointing at. If there are several x.y.z packages all identically named, it's harder to know that the reporter is pointing at something that's already fixed, newly broken, or not working the entire cycle. I agree. My concern with changing the version number during a release is technical rather than procedural. A library version number must reflect both the backward and forward (source and binary) compatibility between any two releases of the library. The rules for assigning the major, minor, and micro (or patch, when permitted by the system linker) numbers are precisely specified and correspond to well-defined changes with an impact on the different types of compatibility (see the rules in effect for the Rogue Wave C++ Standard library below). There is typically no allowance in these rules for making version changes that are not determined by changes and differences between actual code releases. The version number should also be an indicator of continuity (or its lack) between releases of the library. Users of the latest release of a library should be able to decide whether to upgrade to the new fully compatible release without having to wonder what they might have missed in the releases in between or whether a prior release might be sufficient or safer. Martin The Rogue Wave C++ Standard Library versioning policy: The version identifier of a library is typically defined as the string .. with the following semantics: The major number starts at 1 and is incremented by one for each new release of the library that is source or binary incompatible with the previous release. Incrementing the major number resets both the minor and micro numbers to 0. The minor number starts at 0 and is incremented by one for each new release of the library that is forward but not backward compatible with the previous release. Incrementing the minor number resets the micro number to 0. The micro number starts at 0 and is incremented by one for each new release of the library that contains source code changes that are backward compatible with the previous release. A couple of useful references on library and symbol versioning: http://www.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/ http://sources.redhat.com/autobook/autobook/autobook_91.html
x.y.z numbering and releases
Martin Sebor wrote: Justin Erenkrantz wrote: In the future, you should not reuse the version - therefore, this should really be 4.1.4. Once, 4.1.3 is posted, it's 'gone' (regardless of whether it passes or not). Therefore, a vote should be with respect to a specific tarball. If that tarball changes (and a new version is pushed out), you need to get the minimum 3 +1s on that specific tarball. This is an interesting policy that I think deserves to be discussed further. Let me comment on it in a separate thread so as not to detract from the vote. Absolutely not ;-) Here's your thread for discussion of numbering, going forwards... In the httpd project, the RM (release manager) tags a build, with the final version number. If that tarball changes after it leaves their hands, and is in the hands of testers, it's never modified (much) . Some ASF projects roll a -pre1 or -rc1 tarball. It's clear to the user who downloads it that this is almost it, and is being voted on. If they don't get cleared, lets say three files change, then they roll -pre2 or -rc2. Now... in fairness Justin is right; you must vote on the actual tarball you will ship. You can't make an incremental change and consider the old votes still valid. Heck, maybe those voters even disagree with the suggested change, or how it was packaged? But please consider, the candidate must be clearly named. We have to be able to determine that Joe, Sandy and Pat all voted +1 on the -same tarball-. If we do that with -pre1/-pre2 or -rc1/-rc2, or as httpd does with x.y.z (ditched or adopted as appropriate), it doesn't so much matter. It really matters that we 1) know what people voted on, and 2) know what bugs people are pointing at. If there are several x.y.z packages all identically named, it's harder to know that the reporter is pointing at something that's already fixed, newly broken, or not working the entire cycle. Bill
Re: [VOTE] publish stdcxx 4.1.3, take 2
Justin Erenkrantz wrote: --On January 12, 2006 3:26:52 PM -0700 Martin Sebor <[EMAIL PROTECTED]> wrote: I created a new tarball incorporating these changes and replaced the old one with it. Here's the link again for convenience: http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.1.3.tar.gz The md5sum for this file is f1bc9bd5ef0966f994a9183e7353176d. Since these were the only changes I only smoke-tested this new tarball with gcc 3.2.3 on Linux and gcc 4.0.2 Solaris with successul results. I hereby cast my +1 vote to publish this tarball :) +1 with Solaris 10/Forte 11. The test cases say everything 'failed', but I'm not sure that it isn't really a false positive. It looks okay otherwise as far as I can tell. Assuming the failures came out of invoking make run they are bogus. We've changed the output of the ported tests but haven't changed the infrastructure to recognize the new ouptut. Running some of the tests manually should confirm this. I assume everyone else's votes are still good and that we just need a positive vote from you, Bill, or Ben before we can ask the Incubator PMC for permission to publish it. Nope. Typically, any changes to the code contained in a release invalidates all previous votes. Nice try. =) Okay, I'll collect new votes from the original voters and keep this rule in mind in the future. In the future, you should not reuse the version - therefore, this should really be 4.1.4. Once, 4.1.3 is posted, it's 'gone' (regardless of whether it passes or not). Therefore, a vote should be with respect to a specific tarball. If that tarball changes (and a new version is pushed out), you need to get the minimum 3 +1s on that specific tarball. This is an interesting policy that I think deserves to be discussed further. Let me comment on it in a separate thread so as not to detract from the vote. Thanks! Martin
Re: [VOTE] publish stdcxx 4.1.3, take 2 (was: Re: Mac OS X and stdcxx)
--On January 12, 2006 3:26:52 PM -0700 Martin Sebor <[EMAIL PROTECTED]> wrote: I created a new tarball incorporating these changes and replaced the old one with it. Here's the link again for convenience: http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.1.3.tar.gz The md5sum for this file is f1bc9bd5ef0966f994a9183e7353176d. Since these were the only changes I only smoke-tested this new tarball with gcc 3.2.3 on Linux and gcc 4.0.2 Solaris with successul results. I hereby cast my +1 vote to publish this tarball :) +1 with Solaris 10/Forte 11. The test cases say everything 'failed', but I'm not sure that it isn't really a false positive. It looks okay otherwise as far as I can tell. I assume everyone else's votes are still good and that we just need a positive vote from you, Bill, or Ben before we can ask the Incubator PMC for permission to publish it. Nope. Typically, any changes to the code contained in a release invalidates all previous votes. Nice try. =) In the future, you should not reuse the version - therefore, this should really be 4.1.4. Once, 4.1.3 is posted, it's 'gone' (regardless of whether it passes or not). Therefore, a vote should be with respect to a specific tarball. If that tarball changes (and a new version is pushed out), you need to get the minimum 3 +1s on that specific tarball. HTH. -- justin
Re: test for lig.alg.swap
Anton Pevtsov wrote:
Martin Sebor wrote:
[...]
Great idea! Thank you!
The attach contains the updated test version.
Okay, thanks.
I spotted a few more minor issues with the test and corrected
them before committing the final version:
http://svn.apache.org/viewcvs.cgi?rev=370230&view=rev
Attached is a diff between what you sent me and the final version.
You might want to look over the changes and keep them in mind for
future reference. Let me also note some of the more important ones
here:
--- your 25.swap.cppWed Jan 18 11:39:06 2006
+++ my 25.swap.cpp Wed Jan 18 12:06:10 2006
@@ -67,7 +68,7 @@
const std::size_t nseq = std::strlen (seq);
// construct a sequence of `nseq' elements to pass to swap
-T* const tseq = T::from_char (seq, nseq);
+T* const tseq = T::from_char (seq, nseq + 1);
We need to make sure the sequence is never empty since the
rw_assert() calls unconditionally dereference the pointers
even when (nseq == 0) holds.
int a_val, b_val;
bool success = true;
@@ -92,8 +93,8 @@
}
rw_assert (success, 0, line,
- "std::%s<%s%{?}, %s%{;}> ('%c', '%c'): got: ('%c', '%c') "
- "expected: ('%5$c', '%4$c') at step %zu",
+ "%s<%s%{?}, %s%{;}>(%#c, %#c): got: { %#c, %#c } "
+ "expected: { %5$#c, %4$#c } at step %zu",
Use the %#c specifier (note the pound sign -- it's our extension)
when formatting characters in diagnostic output to automatically
quote them and to format non-printable characters using standard
escape sequences (e.g., the linefeed character will be formatted
as '\n' including the quotes instead of inserting a newline into
the output.
fname, it1name, it_swap, it2name, a_val, b_val,
tseq->val_,
(tseq + i)->val_, i);
@@ -154,6 +155,10 @@
const ForwardIterator2 last2 =
make_iter (tseq2 + nseq, tseq2, tseq2 + nseq, it2);
+// silence bogus EDG eccp remark #550-D: variable was set
+// but never used
+_RWSTD_UNUSED (last2);
You might want to compile the tests using the EDG eccp I sent you
and silence these (bogus) warnings. The EDG compiler is the most
conforming C++ compiler and it might reveal problems that other
compilers don't.
@@ -162,17 +167,22 @@
std::size_t assigns_per_swap = T::n_total_op_assign_ -
last_n_op_assign;
-// exercise 25.2.3 - std::swap_ranges<> ()
last_n_op_assign = T::n_total_op_assign_;
+// exercise 25.2.3 - std::swap_ranges()
const ForwardIterator2 res = std::swap_ranges(first1, last1, first2);
+// silence bogus EDG eccp remark #550-D: variable was set
+// but never used
+_RWSTD_UNUSED (res);
+
// check the returned value, 25.2.2 p5
bool success = res.cur_ == last2.cur_;
rw_assert (success, 0, line,
- "std::swap_ranges<%s, %s> (\"%s\", \"%s\") returns: "
- "got: %p, expected: %p",
- it1name, it2name, seq1, seq2, res.cur_, last2.cur_);
+ "swap_ranges<%s, %s>(\"%s\", \"%s\") == first + %td, "
+ "got first + %td",
+ it1name, it2name, seq1, seq2, res.cur_ - tseq2,
+ last2.cur_ - tseq2);
Printing out offsets rather than pointers is more informative.
Martin
--- /nfs/b20/sebor/tmp/25.swap.cpp Wed Jan 18 11:39:06 2006
+++ /build/sebor/dev/stdlib/tests/algorithm/25_swap.cpp Wed Jan 18 12:06:10 2006
@@ -54,10 +54,11 @@
/**/
template
-void test_iter_swap (int line, const char* seq,
- ForwardIterator1 dummy1,
- ForwardIterator2 dummy2,
- const T*,
+void test_iter_swap (int line,
+ const char* seq,
+ ForwardIterator1 /* dummy */,
+ ForwardIterator2 /* dummy */,
+ const T* /* dummy */,
bool it_swap,
const char* it1name,
const char* it2name,
@@ -67,7 +68,7 @@
const std::size_t nseq = std::strlen (seq);
// construct a sequence of `nseq' elements to pass to swap
-T* const tseq = T::from_char (seq, nseq);
+T* const tseq = T::from_char (seq, nseq + 1);
int a_val, b_val;
bool success = true;
@@ -92,8 +93,8 @@
}
rw_assert (success, 0, line,
- "std::%s<%s%{?}, %s%{;}> ('%c', '%c'): got: ('%c', '%c') "
- "expected: ('%5$c', '%4$c') at step %zu",
+ "%s<%s%{?}, %s%{;}>(%#c, %#c): got: { %#c, %#c } "
+ "expected: { %5$#c, %4$#c } at step %zu",
fname, it1name, it_swap, it2name, a_val, b_val, tseq->val_,
(tseq + i)->val_, i);
@@ -135,7 +136,7 @@
const char* seq2,
ForwardIterator1 it1,
ForwardIterator2 it2,
- const T*,
+
[jira] Assigned: (STDCXX-12) publish Class Reference and User Guide on the stdcxx site
[ http://issues.apache.org/jira/browse/STDCXX-12?page=all ] Martin Sebor reassigned STDCXX-12: -- Assign To: Martin Sebor > publish Class Reference and User Guide on the stdcxx site > - > > Key: STDCXX-12 > URL: http://issues.apache.org/jira/browse/STDCXX-12 > Project: STDCXX > Type: Improvement > Components: Web > Versions: 4.1.2 > Environment: All > Reporter: Martin Sebor > Assignee: Martin Sebor > Priority: Critical > Fix For: 4.1.4 > > The stdcxx documentation in svn needs to be published in a browsable format > on the project Web site. Currently only the sources in svn are viewable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: question about serving pages from a database
Benjamin Gomez wrote: Ok, after looking into this. Apache serves these pages through a cgi script and an anonymous checkout procedure. The links need to look like this at least the initial link to the documentation: http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/stdcxx/trunk/doc/stdl ibref/index.html Note the viewcvs.cgi/*checkout*/ Cool beans! I committed a patch with your solution to the project Web page here: http://svn.apache.org/viewcvs.cgi?rev=370222&view=rev The live site should be updated within an hour. Thanks a lot for the research! Martin The internal documentation links work fine as they are relative links, so we just need to make the link to access the documentation like the one above and it should work from there. Ben -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 11:04 AM To: stdcxx-dev@incubator.apache.org Subject: Re: question about serving pages from a database Benjamin Gomez wrote: The headers are actually produced by whatever script or program is writing the pages to the browser. I see. Thanks for the tutorial! :) [...] Do we have access to the actual code that serves the pages out of the DB? I'm sure with some effort we could find it. Subversion comes with its own simple Web server called svnserve: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.svnser ve Here's the source: http://svn.collab.net/viewcvs/svn/trunk/subversion/svnserve/ But I suspect the interface we're using might be some Apache Subversion access module. I guess [EMAIL PROTECTED] would be the place to find out for sure. Martin
RE: question about serving pages from a database
Ok, after looking into this. Apache serves these pages through a cgi script and an anonymous checkout procedure. The links need to look like this at least the initial link to the documentation: http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/stdcxx/trunk/doc/stdl ibref/index.html Note the viewcvs.cgi/*checkout*/ The internal documentation links work fine as they are relative links, so we just need to make the link to access the documentation like the one above and it should work from there. Ben -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 11:04 AM To: stdcxx-dev@incubator.apache.org Subject: Re: question about serving pages from a database Benjamin Gomez wrote: > The headers are actually produced by whatever script or program is writing > the pages to the browser. I see. Thanks for the tutorial! :) [...] > Do we have access to the actual code that serves the pages out of the DB? I'm sure with some effort we could find it. Subversion comes with its own simple Web server called svnserve: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.svnser ve Here's the source: http://svn.collab.net/viewcvs/svn/trunk/subversion/svnserve/ But I suspect the interface we're using might be some Apache Subversion access module. I guess [EMAIL PROTECTED] would be the place to find out for sure. Martin
Re: question about serving pages from a database
Benjamin Gomez wrote: The headers are actually produced by whatever script or program is writing the pages to the browser. I see. Thanks for the tutorial! :) [...] Do we have access to the actual code that serves the pages out of the DB? I'm sure with some effort we could find it. Subversion comes with its own simple Web server called svnserve: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.svnserve Here's the source: http://svn.collab.net/viewcvs/svn/trunk/subversion/svnserve/ But I suspect the interface we're using might be some Apache Subversion access module. I guess [EMAIL PROTECTED] would be the place to find out for sure. Martin
RE: z/OS and z/TPF Development
A port was done for SourcePro Stdlib ed7 on z/OS 1.4 (tho, not fully certified - we just made sure the examples worked), and will be done for ed9 (possibly on z/OS 1.7 and again, not fully certified) - soon, I think. Nicole Willson Consulting Engineer Rogue Wave Software, Inc. A Division of Quovadx 303-545-3210 -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 17, 2006 7:39 PM To: stdcxx-dev@incubator.apache.org Cc: stdcxx-user@incubator.apache.org Subject: Re: z/OS and z/TPF Development Craig Chariton wrote: > Is anyone currently working on porting stdcxx for IBM TPF 4.1, z/OS and > z/TPF? I know IBM has ported STLPort for these platforms, and there is a > porting of the GNU C++ library for TPF 4.1 and z/TPF. However, porting > stdcxx may provide another option for users. If no one is currently working > on this, does anyone know of contacts who may be interested in such a > project? I'm not aware of any effort currently underway but it would certainly be an interesting exercise. In addition, we (Rogue Wave) might need to port the project there in the future so getting a head start now would come in handy. I'm not sure if we have access to a z/OS box at the moment (IIRC, John Hollis had a z/OS laptop at some point) so it might be useful to find out if IBM offers some sort of a "test drive" program similar to the one offered by HP: http://www.testdrive.hp.com/ Martin
RE: question about serving pages from a database
The headers are actually produced by whatever script or program is writing
the pages to the browser.
Usually it's something like the following depending on the language:
setContentType("text/html"); // If this line is missing, or is set to
//"text/plain" Then we get the results we're
// seeing now.
out.println("");
out.println("");
out.println("");
string title = "SessionExample";
out.println("" + title + "");
out.println("");
out.println("");
Do we have access to the actual code that serves the pages out of the DB?
Ben
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 18, 2006 10:03 AM
To: stdcxx-dev@incubator.apache.org
Subject: Re: question about serving pages from a database
Benjamin Gomez wrote:
> Hi Martin,
>
> The problem is that the headers being returned from the server include a
> content-type of text/plain instead of text/html. IE picks up the fact
that
> it is formatted as a web page and displays as a web page, but Mozilla
> formats it as it is supposed to.
Thanks. I assume the headers are part of the files themselves,
correct? I made a change to this page and added a meta tag with
the text/html content but still no dice. Do you see anything
wrong with what I did?
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/doc/index.html
Martin
RE: question about serving pages from a database
I'm not 100% sure but I'd say PHP (http://www.php.net/manual/en/) would be your best bet. It has a ton of interfaces: I'm sure Subversions support is out there somewhere. Brad. > -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 17, 2006 4:24 PM > To: [EMAIL PROTECTED] > Cc: stdcxx-dev@incubator.apache.org > Subject: question about serving pages from a database > > > Does anyone have any suggestion for how to get browsers to > render html files stored in a Subversion database? Here's > some more detail about the problem we're trying to solve: > >http://issues.apache.org/jira/browse/STDCXX-12 >http://issues.apache.org/jira/browse/STDCXX-122 > > Thanks > Martin >
Re: question about serving pages from a database
Benjamin Gomez wrote: Hi Martin, The problem is that the headers being returned from the server include a content-type of text/plain instead of text/html. IE picks up the fact that it is formatted as a web page and displays as a web page, but Mozilla formats it as it is supposed to. Thanks. I assume the headers are part of the files themselves, correct? I made a change to this page and added a meta tag with the text/html content but still no dice. Do you see anything wrong with what I did? http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/doc/index.html Martin
Re: Re: test for lig.alg.swap
Martin Sebor wrote:
Thanks! Your idea of reducing code duplication is neat. Unfortunately,
there is a problem with it that prevents us from taking advantage of
it in its current form: the library is designed to handle compilers that
do not provide support or fully implement member templates (the
configuration macro _RWSTD_NO_MEMBER_TEMPLATES). Thus the testsuite
cannot assume that member templates are supported.
[...]
in a new simple forwarding function called from the first overload of
test_swap() should do, don't you think?
Great idea! Thank you!
The attach contains the updated test version.
With best wishes,
Anton Pevtsov
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 18, 2006 05:00
To: stdcxx-dev@incubator.apache.org
Subject: Re: test for lig.alg.swap
Anton Pevtsov wrote:
The attached file contains my attempt to update lib.alg.swap tests and
port them to new test driver.
Thanks! Your idea of reducing code duplication is neat. Unfortunately,
there is a problem with it that prevents us from taking advantage of it
in its current form: the library is designed to handle compilers that do
not provide support or fully implement member templates (the
configuration macro _RWSTD_NO_MEMBER_TEMPLATES). Thus the testsuite
cannot assume that member templates are supported.
[...]
// classes used to exercise swap functions and to reduce code lines
struct TestIterSwap {
TestIterSwap (int dummy) : dummy_(dummy) {}
template
void test_swap (ForwardIterator1 it1, ForwardIterator2 it2, const
T* )
This is the problem. But I think we should be able to deal with it quite
easily. We don't need member templates to avoid code duplication
-- a simple
if (test_swap_ranges)
test_swap_ranges (it1, it2, (T*)0);
else
test_iter_swap (it1, it2, (T*)0, true);
in a new simple forwarding function called from the first overload of
test_swap() should do, don't you think?
Martin
/***
*
* swap.cpp - test exercising 25.2.2 [lib.alg.swap]
*
* $Id: //stdlib/dev/tests/stdlib/algorithm/swap.cpp#18 $
*
***
*
* Copyright (c) 1994-2005 Quovadx, Inc., acting through its Rogue Wave
* Software division. Licensed under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance with the
* License.Youmay obtain a copy ofthe Licenseat
* http://www.apache.org/licenses/LICENSE-2.0.Unless requiredby
* applicable law or agreed to in writing, software distributed under
* the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
* CONDITIONS OF ANY KIND, either express or implied. See the License
* for the specific language governing permissions and limitations under
* the License.
*
**/
#include // for swap, swap_ranges, iter_swap
#include // for strlen
#include
#include // for rw_test()
_RWSTD_NAMESPACE (std) {
// disable explicit instantiation for compilers (like MSVC)
// that can't handle it
#ifndef _RWSTD_NO_EXPLICIT_INSTANTIATION
template
void
swap (assign >&, assign >&);
template
FwdIter > >
swap_ranges (FwdIter > >,
FwdIter > >,
FwdIter > >);
template
void
iter_swap (FwdIter > >,
FwdIter > >);
#endif // _RWSTD_NO_EXPLICIT_INSTANTIATION
} // namespace std
/**/
template
void test_iter_swap (int line, const char* seq,
ForwardIterator1 dummy1,
ForwardIterator2 dummy2,
const T* , bool it_swap)
{
const char* const it1name =
it_swap ? type_name (dummy1, (T*)0) : "X";
const char* const it2name =
it_swap ? type_name (dummy2, (T*)0) : "X";
const char* const fname =
it_swap ? "iter_swap" : "swap";
// generate sequential values for each default constructed T
const std::size_t nseq = std::strlen (seq);
// construct a sequence of `nseq' elements to pass to swap
T* const tseq = T::from_char (seq, nseq);
int a_val, b_val;
bool success = true;
std::size_t i = 1;
for ( ; i < nseq; ++i) {
const ForwardIterator1 it1 =
make_iter (tseq, tseq, tseq + nseq, it1);
const ForwardIterator2 it2 =
make_iter (tseq + i, tseq, tseq + nseq, it2);
a_val = (*it1).val_;
b_val = (*it2).val_;
it_swap ? std::iter_swap (it1, it2) : std::swap(*it1, *it2);
// verify 25.2.2, p2, p7
success = a_val == (*it2).val_ && b_val == (*it1).val_;
if (!success)
break;
}
rw_assert (success, 0, line,
"std::%s<%s%{?}, %s%{;}> ('%c', '%c'):
RE: question about serving pages from a database
Hi Martin, The problem is that the headers being returned from the server include a content-type of text/plain instead of text/html. IE picks up the fact that it is formatted as a web page and displays as a web page, but Mozilla formats it as it is supposed to. Ben -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 17, 2006 4:24 PM To: [EMAIL PROTECTED] Cc: stdcxx-dev@incubator.apache.org Subject: question about serving pages from a database Does anyone have any suggestion for how to get browsers to render html files stored in a Subversion database? Here's some more detail about the problem we're trying to solve: http://issues.apache.org/jira/browse/STDCXX-12 http://issues.apache.org/jira/browse/STDCXX-122 Thanks Martin
