Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
I happen to agree that the commit messages suck, but the right thing to do is have a look at the script and suggest a patch on the infrastructure mailing list. I would do it myself, but have a paper to write first. I also think that placement of the Log text after the long list of files is obviously broken, and the commit template does not include prefixes for Submitted by: Reviewed by: Obtained from: which are really really important. I don't think that this discussion belongs on every mailing list that uses subversion -- move it to infrastructure. Roy
Re: msdev chokes on .dsp and .dsw in unix text file format
At 05:34 PM 11/19/2004, Garrett Rooney wrote: Kris Carlgren wrote: Hi. I know Im new, and I wanted to check out the APR-1.0.0 release. With the release, APR is receiving a lot of attention at the moment, so I thought Id post my only problem and solution. Everything compiled fine under cygwin and redhat linux, but choked in msdev. The .dsp and .dsw files are in Unix text file format, and msdev doesnt give a clear error message. It simply says project not found. Of course, the solution was to run lineends.pl on the tree and everything worked fine. I propose adding lineends.pl to the Build on Win32 page, or try to keep the .dsp and .dsw files in DOS format. Actually now that APR is in Subversion we can just set svn:eol-style on the files in question and never have this problem again. ONLY if svn:eol-style crlf in conjunction with an svn diff produces an identical result on linux and win32. Even then it creates a binary diff (mixing line ending codes). This is -not- elegant. Search for my previous rants on the subject. Kris, are you using a win32 port of svn? Or are you trying to use a non-win32 port such as cygwin? Those are two different operating systems. I love the idea of noting build/lineends.pl in the building on win32 page!!! I'm shocked it wasn't there and appologize for the oversite. Bill
Re: [NOTICE] CVS to SVN migration complete
At 06:52 PM 11/19/2004, Justin Erenkrantz wrote: --On Saturday, November 20, 2004 1:49 AM +0100 André Malo [EMAIL PROTECTED] wrote: Just a question: Maybe I'm missing the info - is the httpd trunk supposed to work with the apr 1.0.x branch or just the apr trunk? We're going to have to decide which APR branch/release httpd 2.1/2.2 should work with - and, we'll have to decide soon. Whichever we pick, we need to stick 2.2 to a *released* version of APR. At this point, without a compelling argument, I'd vote for 1.0.x. -- justin I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. That is the right answer, branch APR 1.x, fix on svn trunk (2.0.0) and commit the right code in httpd-2.2 such that an allocation of memory is consistently size_t and an allocation of disk is consistently off_t, and none of which has anything to do with int or long. Bill
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
--On Friday, November 19, 2004 6:22 PM -0800 Roy T. Fielding [EMAIL PROTECTED] wrote: I happen to agree that the commit messages suck, but the right thing to do is have a look at the script and suggest a patch on the infrastructure mailing list. I would do it myself, but have a paper http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/mailer/ See mailer.py. the long list of files is obviously broken, and the commit template does not include prefixes for Submitted by: Reviewed by: Obtained from: which are really really important. We'd probably need to do work on enhancements for this. -- justin
Re: msdev chokes on .dsp and .dsw in unix text file format
William A. Rowe, Jr. wrote: ONLY if svn:eol-style crlf in conjunction with an svn diff produces an identical result on linux and win32. Even then it creates a binary diff (mixing line ending codes). This is -not- elegant. Search for my previous rants on the subject. I'm not sure exactly what the behavior is, but I will note that nobody has seemed to have a problem with using svn:eol-style on these kind of files in the Subversion tree. If there is a problem with the way it currently works I'm sure the Subversion dev list would like to hear about it. If there have been discussions about such things in the past that were ignored then a reminder of the issues involved would probably help get them dealt with. Another possibility, FWIW, is to port the gen-make.py code from Subversion that generates VS6 and VS.NET build files automatically, rather than keeping manually generated ones in the tree. -garrett
Re: msdev chokes on .dsp and .dsw in unix text file format
At 09:14 PM 11/19/2004, Garrett Rooney wrote: William A. Rowe, Jr. wrote: ONLY if svn:eol-style crlf in conjunction with an svn diff produces an identical result on linux and win32. Even then it creates a binary diff (mixing line ending codes). This is -not- elegant. Search for my previous rants on the subject. I'm not sure exactly what the behavior is, but I will note that nobody has seemed to have a problem with using svn:eol-style on these kind of files in the Subversion tree. If there is a problem with the way it currently works I'm sure the Subversion dev list would like to hear about it. If there have been discussions about such things in the past that were ignored then a reminder of the issues involved would probably help get them dealt with. Simple. Let me suggest a patch containing libapr.dsp apr.dsp build/config.m4 that effects some change to the build, for private build purposes. Now, imagine trying to svn co such a patch, and have it apply, on both win32 and unix without missing a beat. When all TEXT files are native eol-style, this just works. When checked out on win32 native, the patch and to-be-patched files all have matching line ends. When checked out unix native, the patch and to-be-patched files all have matching line ends. It only becomes a NIGHTMARE when folks believe that a unix utility should be used for checkouts to win32. Not only do the .dsp, .dsw, makefiles and .vcproj/.sln files all fail, but there are much more subtle errors in the compilation of code, such that later debugging information doesn't line up with actual lines of code. It's very exasperating and a total waste of time to decipher segfaults that result in such code. I've always maintained that to build win32, one uses win32 files. To build unix (including cygwin) one uses unix files. And to check out from a repository, one uses the native svn to the target. I love the spirit, concept, and even occasionally the implementation of cygwin. But it drives me mad to have folks expect cygwin and native win32 results correspond with one another. They are most certainly two different platforms. Another possibility, FWIW, is to port the gen-make.py code from Subversion that generates VS6 and VS.NET build files automatically, rather than keeping manually generated ones in the tree. This, of course, is a marvelous idea. Bill
Re: msdev chokes on .dsp and .dsw in unix text file format
William A. Rowe, Jr. wrote: Simple. Let me suggest a patch containing libapr.dsp apr.dsp build/config.m4 that effects some change to the build, for private build purposes. Now, imagine trying to svn co such a patch, and have it apply, on both win32 and unix without missing a beat. When all TEXT files are native eol-style, this just works. When checked out on win32 native, the patch and to-be-patched files all have matching line ends. When checked out unix native, the patch and to-be-patched files all have matching line ends. It only becomes a NIGHTMARE when folks believe that a unix utility should be used for checkouts to win32. Not only do the .dsp, .dsw, makefiles and .vcproj/.sln files all fail, but there are much more subtle errors in the compilation of code, such that later debugging information doesn't line up with actual lines of code. It's very exasperating and a total waste of time to decipher segfaults that result in such code. I've always maintained that to build win32, one uses win32 files. To build unix (including cygwin) one uses unix files. And to check out from a repository, one uses the native svn to the target. I love the spirit, concept, and even occasionally the implementation of cygwin. But it drives me mad to have folks expect cygwin and native win32 results correspond with one another. They are most certainly two different platforms. So are you saying that if we force svn:eol-style to CRLF on the .dsp files that the resulting patches won't work. When I try it here (a unix box) I get a diff that includes \rs at the end of the lines for changes in a CRLF file. Isn't that what it should be? Patch seems to deal with it just fine BTW, even if there are some CRLF and some NL files. I admit, I haven't tried this on win32 (either normal or cygwin), since I don't have access to such a machine at the moment, but I have no reason to believe it will work differently there. Another possibility, FWIW, is to port the gen-make.py code from Subversion that generates VS6 and VS.NET build files automatically, rather than keeping manually generated ones in the tree. This, of course, is a marvelous idea. Unfortunately it requires someone with more Win32-fu than me to do it. -garrett
Re: msdev chokes on .dsp and .dsw in unix text file format
At 09:35 PM 11/19/2004, Garrett Rooney wrote: William A. Rowe, Jr. wrote: Simple. Let me suggest a patch containing libapr.dsp apr.dsp build/config.m4 that effects some change to the build, for private build purposes. Now, imagine trying to svn co such a patch, and have it apply, on both win32 and unix without missing a beat. When all TEXT files are native eol-style, this just works. When checked out on win32 native, the patch and to-be-patched files all have matching line ends. When checked out unix native, the patch and to-be-patched files all have matching line ends. It only becomes a NIGHTMARE when folks believe that a unix utility should be used for checkouts to win32. Not only do the .dsp, .dsw, makefiles and .vcproj/.sln files all fail, but there are much more subtle errors in the compilation of code, such that later debugging information doesn't line up with actual lines of code. It's very exasperating and a total waste of time to decipher segfaults that result in such code. I've always maintained that to build win32, one uses win32 files. To build unix (including cygwin) one uses unix files. And to check out from a repository, one uses the native svn to the target. I love the spirit, concept, and even occasionally the implementation of cygwin. But it drives me mad to have folks expect cygwin and native win32 results correspond with one another. They are most certainly two different platforms. So are you saying that if we force svn:eol-style to CRLF on the .dsp files that the resulting patches won't work. When I try it here (a unix box) I get a diff that includes \rs at the end of the lines for changes in a CRLF file. Isn't that what it should be? If you apply that patch using native patch on win32, we have duplicate \r's and that does fail. Patch seems to deal with it just fine BTW, even if there are some CRLF and some NL files. Modern versions of patch learned to (mostly) ignore \r's - but when you have oddballs (I'm fighting hp/ux and aix at home, this evening) patch is dirt stupid. I admit, I haven't tried this on win32 (either normal or cygwin), since I don't have access to such a machine at the moment, but I have no reason to believe it will work differently there. Trust - it does. Please consider that the patch itself is pushed and extracted from svn just as the original sources, so \r-ness is very consistent. Another possibility, FWIW, is to port the gen-make.py code from Subversion that generates VS6 and VS.NET build files automatically, rather than keeping manually generated ones in the tree. This, of course, is a marvelous idea. Unfortunately it requires someone with more Win32-fu than me to do it. 2c US - I'll invest some effort with you. ITMT the suggestion of using either native Win32 svn or converting with build/lineends.pl is the way to go tonight. Bill
2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
--On Friday, November 19, 2004 8:01 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. That is the right answer, branch APR 1.x, fix on svn trunk (2.0.0) and commit the right code in httpd-2.2 such that an allocation of memory is consistently size_t and an allocation of disk is consistently off_t, and none of which has anything to do with int or long. I don't believe that Allen would be able to complete his changes in a reasonable timeframe. I'm tired of holding things up for a 'major' rewrite that'll come any day now (TM). Sorry. I'd be willing to give him a week or two to make the changes everywhere he needs to, but even then it'd be hard for all of us to review such a major change. I'm in favor of releasing httpd 2.1 as 2.2 almost as-is with some relatively minor things thrown in (say the config re-org changes and the group hooks). However, trying to fix the 64-bit issues in a 2.2 (and with an APR 2.0) at this late state would make it really hard for our module writers to adopt 2.2 in a timely manner. So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 11:03 PM 11/19/2004, Justin Erenkrantz wrote: --On Friday, November 19, 2004 8:01 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. I don't believe that Allen would be able to complete his changes in a reasonable timeframe. So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- I guess the ball is to Allen, then, but I'd also be happy to quickly whack at it. The concept is Simple(tm) and would be far less painful than actually fighting through all the ( cast )s of his later patches. Bill
Re: APR 1.0.1 and 0.9.5 posted for review
+1 for APR-0.9.5 and APR-Util-0.9.5 Tested on NetBSD-2.0RC2 and FreeBSD 5.2.1-p11 -Paul Justin Erenkrantz wrote: Can we please get some feedback on the following releases: http://www.apache.org/~jerenkrantz/0.9.5/ (The directory actually contains 0.9.5 and 1.0.1.) If we get 3 +1s, then I'll copy it over to dist. -- justin
Re: [PATCH] update last (I think) reference to CVS in the docs
On Fri, 19 Nov 2004, Garrett Rooney wrote: We're using SVN now, might as well say so in README.dev ;-) Got it, thanks.
Re: Email archive busted?
On Fri, 19 Nov 2004, Garrett Rooney wrote: In an attempt to see what happened in the last day or so while my email was accidentally being routed to /dev/null (never mess with your email settings right before getting on a plane, it's just asking for trouble) I checked out the eyebrowse archives for dev@apr.apache.org and [EMAIL PROTECTED] and it seems that neither are working. The most recent mail in the archives for both lists are from november 2003. Yeah we noticed that during the hackathon but forgot to fix it. I'll prod infrastructure. Thanks, Cliff
Re: APR 1.0.1 and 0.9.5 posted for review
--On Friday, November 19, 2004 11:14 PM -0700 Paul Querna [EMAIL PROTECTED] wrote: +1 for APR-0.9.5 and APR-Util-0.9.5 Tested on NetBSD-2.0RC2 and FreeBSD 5.2.1-p11 Thanks. By my count, that is now 3 +1s for 0.9.5 and 1.0.1 (which includes my own +1), so I've gone and placed them in /dist and updated apr.apache.org. If someone feels like it, they could draft an email announcement. I've done enough damage already. =) -- justin
Re: svn commit: r105905 - in apr/apr/trunk: . include include/arch/unix poll/unix
On Sat, Nov 20, 2004 at 12:28:20AM -, Paul Querna wrote: Author: pquerna Date: Fri Nov 19 16:28:19 2004 New Revision: 105905 Added: apr/apr/trunk/include/arch/unix/apr_arch_poll_private.h (contents, props changed) apr/apr/trunk/poll/unix/epoll.c (contents, props changed) apr/apr/trunk/poll/unix/kqueue.c (contents, props changed) apr/apr/trunk/poll/unix/select.c (contents, props changed) This should probably have been done with: svn cp poll.c epoll.c svn cp poll.c kqueue.c ... but never mind. Thanks for following this through and sorry I didn't get round tuit! :) joe
[EMAIL PROTECTED]: failure notice]
Hello, I tried to subscribe the [EMAIL PROTECTED] mailing list, but get the following response: - Forwarded message from [EMAIL PROTECTED] - Envelope-to: [EMAIL PROTECTED] Delivery-date: Sat, 20 Nov 2004 12:52:55 +0100 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. [...] - End forwarded message - I think the correct address is [EMAIL PROTECTED], as the link on http://apr.apache.org/mailing-lists.html suggests? Either the link and the mailling list server or the paragraph describing [EMAIL PROTECTED] is/are wrong. Should I try subscribing the cvs list, if I want to receive the svn logs? Bye Uwe -- Uwe Zeisberger exit vi, lesson II: : w q ! CR NB: write the current file signature.asc Description: Digital signature
Re: [EMAIL PROTECTED]: failure notice]
* Uwe Zeisberger [EMAIL PROTECTED] wrote: I tried to subscribe the [EMAIL PROTECTED] mailing list, but get the following response: Try [EMAIL PROTECTED] ;-) nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote: I don't believe that Allen would be able to complete his changes in a reasonable timeframe. I'm tired of holding things up for a 'major' rewrite that'll come any day now (TM). Sorry. I'd be willing to give him a week or two to make the changes everywhere he needs to, but even then it'd be hard for all of us to review such a major change. I'm in favor of releasing httpd 2.1 as 2.2 almost as-is with some relatively minor things thrown in (say the config re-org changes and the group hooks). However, trying to fix the 64-bit issues in a 2.2 (and with an APR 2.0) at this late state would make it really hard for our module writers to adopt 2.2 in a timely manner. So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin +1. Of course, I am assuming that his 64bit fixes will likely break binary compatibility. For module writers it's not a big deal, but for commercial 3rd party modules it might be. Simply because they would need to produce yet another version of their modules for httpd. Recall how long it took for some 1.3 modules to be ported to 2.0? With 2.2 they will now need to port to 2.2, which obviously is trivially easier than going from 1.3-2.0. But there will be delay. If we then produce another 2.x which isn't binary compatible, then it's another process and the module list will start looking quite crowded: 1.3 2.0 2.2 (non-64) 2.x (64) That's a lot of modules for companies to worry about. No, I don't have the answer but we should be prepared for the uptake of 2.2 to be less than we hope or imagine. This kind of brings up an idea that's been sloshing around between that handful of neurons in my noggin: Some sort of API seed program within httpd/apr where we put a little more effort in getting the latest API versions out there. We've been operating on a pull me scenario, and it's worked, but it's been hardly optimal. Maybe some sort of push mechanism would be useful. Even if it's just a blurb on the site that Apache 2.2 will be released soon, here is the new API (which is frozen), if you plan to have your Apache modules ready for 2.2 when released, please grab this tarball and test. In many, many ways the success of httpd depends on the availability of its modules.
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 08:23 AM 11/20/2004, Jim Jagielski wrote: On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote: So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin +1. Of course, I am assuming that his 64bit fixes will likely break binary compatibility. It does - that's the rub. And, for 2.2, this was always the plan. For module writers it's not a big deal, but for commercial 3rd party modules it might be. Simply because they would need to produce yet another version of their modules for httpd. They will. Implicit in the '2.0 isn't a moving target' comes the correlary '2.1-dev is a moving target, and once we get it right, it will be 2.2 and quit shifting the API beneath you.' Recall how long it took for some 1.3 modules to be ported to 2.0? With 2.2 they will now need to port to 2.2, which obviously is trivially easier than going from 1.3-2.0. Yes - though there will be api changes as well. We obviously need to move beyond APR 0.9 - either to 1.x or (if we have to fix the API) to 2.x. But there will be delay. If we then produce another 2.x which isn't binary compatible, then it's another process and the module list will start looking quite crowded [...] That's a lot of modules for companies to worry about. We might, or it might be too drastic (event mpm's which allow requests to jump threads.) If they are too radical for 2.4 or 2.6 expectations, then 3.0 comes along. I'd hope no faster than 6-18 mos per minor bump because you are right - it creates a burden for module authors. No, I don't have the answer but we should be prepared for the uptake of 2.2 to be less than we hope or imagine. Of course. This is true of most projects, Major bump is quite slow (initially), minor is a noticeable delay, and subver should be quick if we keep it painless. This kind of brings up an idea that's been sloshing around between that handful of neurons in my noggin: Some sort of API seed program within httpd/apr where we put a little more effort in getting the latest API versions out there. We've been operating on a pull me scenario, and it's worked, but it's been hardly optimal. Maybe some sort of push mechanism would be useful. Even if it's just a blurb on the site that Apache 2.2 will be released soon, here is the new API (which is frozen), if you plan to have your Apache modules ready for 2.2 when released, please grab this tarball and test. I'm 100% with you - we should loudly scream The alpha is here! Tell module authors this is it - if we can make your life easier, now is the moment we will break ABI in order to do so! Of course, snooze you lose, if there is something you needed, it will just wait until 2.3-dev for us to begin work after the feature/api freeze 2.2. Bill
Branches, please vote...
We have apr/apr/branches/ 1.0.x/ - this is great APR_0_9_BRANCH - this should be 0.9.x? APR/ unlabeled/ - these are duds - delete them? apr/apr-util/branches/ 1.0.x/ - again, dandy APU_0_9_BRANCH - this should be 0.9.x? apr/apr-iconv/branches/ 1.0.x/ - again, dandy API_0_9_BRANCH - this should be 0.9.x? API_1_0_BRANCH ICONV - these are dead - rm them? Opinions on my '?'s above?
Re: Branches, please vote...
--On Saturday, November 20, 2004 12:18 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: We have apr/apr/branches/ 1.0.x/ - this is great APR_0_9_BRANCH - this should be 0.9.x? +1. APR/ unlabeled/ - these are duds - delete them? +1. apr/apr-util/branches/ 1.0.x/ - again, dandy APU_0_9_BRANCH - this should be 0.9.x? +1. apr/apr-iconv/branches/ 1.0.x/ - again, dandy API_0_9_BRANCH - this should be 0.9.x? +1. API_1_0_BRANCH ICONV - these are dead - rm them? +1. Opinions on my '?'s above? Looks good. -- justin
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 08:23 AM 11/20/2004, Jim Jagielski wrote: This kind of brings up an idea that's been sloshing around between that handful of neurons in my noggin: Some sort of API seed program within httpd/apr where we put a little more effort in getting the latest API versions out there. The other alternative is a 'fixed' subset of the httpd API that we simply don't touch. At least so it's APR compat if not ABI compat. That also means leaving httpd n.x releases on apr m.x releases. But mod_isapi already builds on all platforms if you are looking for a stable plug-in api ;-) Bill
[PATCH] first cut at auto-generating dsp files
So I got a little motivated, and started playing around with auto
generating windows dsp files just like we currently auto generate parts
of the make based build system. This doesn't actually work yet, for a
few reasons I'll get into in a sec, but I'm going to leave for the
weekend soon and I don't know when I'll get back to this so I figured
I'd throw the diff out there and let anyone who cares pick it up.
The patch takes a similar approach to the Subversion dsp generator code,
there's an EZT template for the dsp files (build/dsp.ezt), and we
generate a list of public headers, private headers, and source files,
pass them (along with a few other parameters) into the template, and
write out a dsp file.
There are a few problems, and a few things that are just a bit different
from the existing apr.dsp file.
First, EZT doesn't have a good way to have nested groups, so it's not
easy to generate subgroups for each directory of files, instead all the
source files have gone into one big group. I don't think this is a big
enough problem to care about, but if one of the windows people could
confirm this I'd appreciate it.
Second, unlike the more unixish platforms the windows build doesn't
always totally override all the files from the unix subdirectories, so
we're going to need some mechanism to specify which unix files get
included and which don't. This is just busted at the moment, so there's
no way you'll be able to use this stuff to build a working version of APR.
Third, we need some logic to handle the difference between the static
libs (apr.dsp) and the dynamic libs (libapr.dsp), currently this hasn't
been written at all, and we're just hardcoded to do the static libs and
to write out to apr.dsp-new so you can compare with the original.
Lastly, I lack any way to test this at all, so it's quite likely that
even the parts I think are working just don't. If someone could test
this I would appreciate it.
I welcome any feedback you might have.
-garrett
Index: build/ezt.py
===
--- build/ezt.py(revision 0)
+++ build/ezt.py(revision 0)
@@ -0,0 +1,585 @@
+#!/usr/bin/env python
+ezt.py -- easy templating
+
+ezt templates are very similar to standard HTML files. But additionally
+they contain directives sprinkled in between. With these directives
+it is possible to generate the dynamic content from the ezt templates.
+
+These directives are enclosed in square brackets. If you are a
+C-programmer, you might be familar with the #ifdef directives of the
+C preprocessor 'cpp'. ezt provides a similar concept for HTML. Additionally
+EZT has a 'for' directive, which allows to iterate (repeat) certain
+subsections of the template according to sequence of data items
+provided by the application.
+
+The HTML rendering is performed by the method generate() of the Template
+class. Building template instances can either be done using external
+EZT files (convention: use the suffix .ezt for such files):
+
+ template = Template(../templates/log.ezt)
+
+or by calling the parse() method of a template instance directly with
+a EZT template string:
+
+ template = Template()
+ template.parse('''htmlhead
+... title[title_string]/title/head
+... bodyh1[title_string]/h1
+...[for a_sequence] p[a_sequence]/p
+...[end] hr
+...The [person] is [if-any state]in[else]out[end].
+... /body
+... /html
+... ''')
+
+The application should build a dictionary 'data' and pass it together
+with the output fileobject to the templates generate method:
+
+ data = {'title_string' : A Dummy Page,
+... 'a_sequence' : ['list item 1', 'list item 2', 'another
element'],
+... 'person': doctor,
+... 'state' : None }
+ import sys
+ template.generate(sys.stdout, data)
+htmlhead
+titleA Dummy Page/title/head
+bodyh1A Dummy Page/h1
+ plist item 1/p
+ plist item 2/p
+ panother element/p
+ hr
+The doctor is out.
+/body
+/html
+
+Template syntax error reporting should be improved. Currently it is
+very sparse (template line numbers would be nice):
+
+ Template().parse([if-any where] foo [else] bar [end unexpected args])
+Traceback (innermost last):
+ File stdin, line 1, in ?
+ File ezt.py, line 220, in parse
+self.program = self._parse(text)
+ File ezt.py, line 275, in _parse
+raise ArgCountSyntaxError(str(args[1:]))
+ArgCountSyntaxError: ['unexpected', 'args']
+ Template().parse([if unmatched_end]foo[end])
+Traceback (innermost last):
+ File stdin, line 1, in ?
+ File ezt.py, line 206, in parse
+self.program = self._parse(text)
+ File ezt.py, line 266, in _parse
+raise UnmatchedEndError()
+UnmatchedEndError
+
+
+Directives
+==
+
+ Several directives allow the use of dotted qualified names refering to objects
+ or
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 12:37 PM 11/20/2004, William A. Rowe, Jr. wrote: The other alternative is a 'fixed' subset of the httpd API that we simply don't touch. At least so it's APR compat if not ABI compat. s/APR compat/API compat/
Re: Branches, please vote...
+1 on all changes. William A. Rowe, Jr. wrote: We have apr/apr/branches/ 1.0.x/ - this is great APR_0_9_BRANCH - this should be 0.9.x? APR/ unlabeled/ - these are duds - delete them? apr/apr-util/branches/ 1.0.x/ - again, dandy APU_0_9_BRANCH - this should be 0.9.x? apr/apr-iconv/branches/ 1.0.x/ - again, dandy API_0_9_BRANCH - this should be 0.9.x? API_1_0_BRANCH ICONV - these are dead - rm them? Opinions on my '?'s above?
Eliminate .rc files?
http://svn.apache.org/viewcvs.cgi/httpd/mod_aspdotnet/trunk/Apache.Web/Apache.Web.Version.h?rev=105923view=markup is how I coded the version header for mod_aspdotnet, so that the .rc file... http://svn.apache.org/viewcvs.cgi/httpd/mod_aspdotnet/trunk/Apache.Web/Apache.Web.rc?rev=105923view=log never needs to be autogenerated. The differences between apr and mod_aspdotnet? Our apr_version.h file includes apr.h, and only because we declare some fn's in there. Does anyone object to flipping those version function declarations into apr.h (they are immutable) and including apr_version.h within apr.h? It's already protected from double-inclusion. The only possible breakage is including apr_version.h without ever including apr.h - a scenario I think is most unlikely. It seems like this could fall under the 1.1 bump. Comments? Bill
Re: Branches, please vote...
On Sat, 20 Nov 2004, Justin Erenkrantz wrote: Opinions on my '?'s above? Looks good. -- justin Likewise +1 to all. --Cliff
[SVN] Branches for apr[-util|-iconv] 0.9.x moved
apr/apr/branches/ APR_0_9_BRANCH - 0.9.x apr/apr-util/branches/ APU_0_9_BRANCH - 0.9.x apr/apr-iconv/branches/ API_0_9_BRANCH - 0.9.x All changed... you need to... cd into your local checkout directories, and switch them. cd /path-to-local/apr-0.9/ svn switch https://svn.apache.org/repos/asf/apr/apr/branches/0.9.x cd /path-to-local/apr-util-0.9/ svn switch https://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x cd /path-to-local/apr-iconv-0.9/ svn switch https://svn.apache.org/repos/asf/apr/apr-iconv/branches/0.9.x and you will jump right up with us. apr/apr/branches/ APR/ unlabeled/ - these are duds - delete them? apr/apr-iconv/branches/ API_1_0_BRANCH ICONV - these are dead - rm them? All gone. Bill
