You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Ryan Phillips <ry...@trolocsis.com> on 2009/01/09 07:18:02 UTC
SCons Updates...
Hi All,
I've been adding bits and pieces to the scons build system for /trunk.
* Add APRConfigureBase and APRConfigure classes
The idea is to use APRConfigure and the base class to support cross
compiles... For a cross compile a user can simply subclass
APRConfigureBase and return the necessary results they need.
Most compiled or executed applications ran at configure time will
eventually be pulled into the class.
* A few bug fixes for SIZE_T formats in apr.h
* Added mmap and friends to function checking
* Check for semaphores
* Check for F_SETLK and flock
Are the new classes heading in the right direction?
Regards,
Ryan
Re: SCons Updates... 2
Posted by Steve Comstock <st...@trainersfriend.com>.
Dan Poirier wrote:
> Greg Stein <gs...@gmail.com> writes:
>
>> Understood. But if you're writing new code (for APR 2.x), then why
>> wouldn't you develop the codebase in Unicode? "Link with old
>> libraries" might be an answer, though I'd say "it is outside the scope
>> of APR to interact with that old library".
>>
>> Frankly, it would be nice if the APR 2.x API was pure Unicode charset,
>> encoded as UTF-8 across the board.
>>
>> I'm not disputing that EBCDIC is still in use (as you eminently point
>> out). Just that I fail to see it has a strict, useful requirement for
>> APR 2.x.
>
> Frankly, internal Unicode would be great. Just so input and output
> still support EBCDIC, since people still do use it. (Maybe even just
> input - does anyone actually serve web pages in EBCDIC?)
Well, I was just going to lurk, but I believe the answer
to this question is No. The z/OS servers convert EBCDIC
strings to UTF-8 by default. I don't think many (any?)
browsers support EBCDIC.
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Check out the Trainer's Friend Store to purchase z/OS <==
==> application developer toolkits. Sample code in four <==
==> programming languages, JCL to Assemble or compile, <==
==> bind and test. <==
==> http://www.trainersfriend.com/TTFStore/index.html <==
Re: SCons Updates... 2
Posted by Dan Poirier <po...@pobox.com>.
Greg Stein <gs...@gmail.com> writes:
> Understood. But if you're writing new code (for APR 2.x), then why
> wouldn't you develop the codebase in Unicode? "Link with old
> libraries" might be an answer, though I'd say "it is outside the scope
> of APR to interact with that old library".
>
> Frankly, it would be nice if the APR 2.x API was pure Unicode charset,
> encoded as UTF-8 across the board.
>
> I'm not disputing that EBCDIC is still in use (as you eminently point
> out). Just that I fail to see it has a strict, useful requirement for
> APR 2.x.
Frankly, internal Unicode would be great. Just so input and output
still support EBCDIC, since people still do use it. (Maybe even just
input - does anyone actually serve web pages in EBCDIC?)
--
Dan Poirier <po...@pobox.com>
Re: SCons Updates... 2
Posted by Greg Stein <gs...@gmail.com>.
Understood. But if you're writing new code (for APR 2.x), then why
wouldn't you develop the codebase in Unicode? "Link with old
libraries" might be an answer, though I'd say "it is outside the scope
of APR to interact with that old library".
Frankly, it would be nice if the APR 2.x API was pure Unicode charset,
encoded as UTF-8 across the board.
I'm not disputing that EBCDIC is still in use (as you eminently point
out). Just that I fail to see it has a strict, useful requirement for
APR 2.x.
Cheers,
-g
On Fri, Jan 23, 2009 at 14:58, Steve Comstock <st...@trainersfriend.com> wrote:
>...
> Greg,
>
> I'm just a lurker here, and I am also a mainframe bigot.
>
> I'd like to point out a few things about IBM mainframes
> and in particular z/OS, then I'll go back to lurking.
>
> Of course you know modern mainframes have hardware
> instructions that process data in ASCII and Unicode
> (UTF-8, UTF-16, and UTF-32), IEEE binary floating
> point, IEEE decimal floating point, and other
> instructions that can easily convert data between
> little endian and big endian for portability, and
> more.
>
> You're aware that mainframes can run Linux, either
> natively or under z/VM.
>
> I'm sure you acknowledge that z/OS still processes
> a huge percent of corporate, customer, and government
> data in the largest organizations.
>
> Did you know you can run UNIX under z/OS? That z/OS
> comes with a free HTTPD server? That IBM recently
> made available a port of Apache to run under z/OS,
> as a no-charge product? Of course, Java, C, and C++
> are available under z/OS. But even more mundane
> languages such as Assembler, COBOL, and PL/I on
> z/OS support Unicode, XML, and the ability to
> create, say, CGIs. While accessing DB2, a fully
> relational database that also supports Unicode,
> XML, and LOB data objects natively.
>
> At the same time, code that was written 35 years
> ago continues to run with no recompile or relink.
> Now that's code reuse!
>
> I find all that pretty impressive. Here's a link to a
> paper on this:
>
> http://www.trainersfriend.com/Papers/Future_of_Mainframe.pdf
>
> or for a list of several papers I've written that are
> mainframe centric:
>
> http://www.trainersfriend.com/General_content/Book_site.htm
>
>
> But, of course, we're not here to start any relgious wars.
> I'll just go back to lurking now.
>
>
>
> Kind regards,
>
> -Steve Comstock
> The Trainer's Friend, Inc.
>
> 303-393-8716
> http://www.trainersfriend.com
>
> z/OS Application development made easier
> * Our classes include
> + How things work
> + Programming examples with realistic applications
> + Starter / skeleton code
> + Complete working programs
> + Useful utilities and subroutines
> + Tips and techniques
>
> ==> Check out the Trainer's Friend Store to purchase z/OS <==
> ==> application developer toolkits. Sample code in four <==
> ==> programming languages, JCL to Assemble or compile, <==
> ==> bind and test. <==
> ==> http://www.trainersfriend.com/TTFStore/index.html <==
>
Re: SCons Updates... 2
Posted by Steve Comstock <st...@trainersfriend.com>.
Greg Stein wrote:
> On Fri, Jan 23, 2009 at 13:24, Jeff Trawick <tr...@gmail.com> wrote:
>> On Fri, Jan 23, 2009 at 5:31 AM, Greg Stein <gs...@gmail.com> wrote:
>>> Check for ebcdic? Are we *really* going to continue support for that?
>>> Seriously, folks.
>> What is the better criteria?
>> * offends sensibility of at least one APR contributor
>> * actively used by and depended on by multiple APR contributors (and may be
>> a partial sponsor of the warm, dry environment necessary for APR hacking,
>> though that's probably a difficult determination to make for certain)
>
> If it is still being used, then... well, geez. *shudder*
>
> And in response to your question, "duh. not like I have any super-vote
> here. just opening a discussion."
>
> Cheers,
> -g
Greg,
I'm just a lurker here, and I am also a mainframe bigot.
I'd like to point out a few things about IBM mainframes
and in particular z/OS, then I'll go back to lurking.
Of course you know modern mainframes have hardware
instructions that process data in ASCII and Unicode
(UTF-8, UTF-16, and UTF-32), IEEE binary floating
point, IEEE decimal floating point, and other
instructions that can easily convert data between
little endian and big endian for portability, and
more.
You're aware that mainframes can run Linux, either
natively or under z/VM.
I'm sure you acknowledge that z/OS still processes
a huge percent of corporate, customer, and government
data in the largest organizations.
Did you know you can run UNIX under z/OS? That z/OS
comes with a free HTTPD server? That IBM recently
made available a port of Apache to run under z/OS,
as a no-charge product? Of course, Java, C, and C++
are available under z/OS. But even more mundane
languages such as Assembler, COBOL, and PL/I on
z/OS support Unicode, XML, and the ability to
create, say, CGIs. While accessing DB2, a fully
relational database that also supports Unicode,
XML, and LOB data objects natively.
At the same time, code that was written 35 years
ago continues to run with no recompile or relink.
Now that's code reuse!
I find all that pretty impressive. Here's a link to a
paper on this:
http://www.trainersfriend.com/Papers/Future_of_Mainframe.pdf
or for a list of several papers I've written that are
mainframe centric:
http://www.trainersfriend.com/General_content/Book_site.htm
But, of course, we're not here to start any relgious wars.
I'll just go back to lurking now.
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Check out the Trainer's Friend Store to purchase z/OS <==
==> application developer toolkits. Sample code in four <==
==> programming languages, JCL to Assemble or compile, <==
==> bind and test. <==
==> http://www.trainersfriend.com/TTFStore/index.html <==
Re: SCons Updates... 2
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jan 23, 2009 at 14:41, Jeff Trawick <tr...@gmail.com> wrote:
> On Fri, Jan 23, 2009 at 7:40 AM, Greg Stein <gs...@gmail.com> wrote:
>>
>> On Fri, Jan 23, 2009 at 13:24, Jeff Trawick <tr...@gmail.com> wrote:
>> > On Fri, Jan 23, 2009 at 5:31 AM, Greg Stein <gs...@gmail.com> wrote:
>> >>
>> >> Check for ebcdic? Are we *really* going to continue support for that?
>> >> Seriously, folks.
>> >
>> > What is the better criteria?
>> > * offends sensibility of at least one APR contributor
>> > * actively used by and depended on by multiple APR contributors (and may
>> > be
>> > a partial sponsor of the warm, dry environment necessary for APR
>> > hacking,
>> > though that's probably a difficult determination to make for certain)
>>
>> If it is still being used, then... well, geez. *shudder*
>>
>> And in response to your question, "duh. not like I have any super-vote
>> here. just opening a discussion."
>
> Here's a better opening to such a discussion ;)
>
> "Hey guys, here are some platforms/nuances/whatever currently in APR that I
> think we might be able to drop in 2.0. Which are still being
> used/maintained?" ;)
hehehehe.....
Re: SCons Updates... 2
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jan 23, 2009 at 7:40 AM, Greg Stein <gs...@gmail.com> wrote:
> On Fri, Jan 23, 2009 at 13:24, Jeff Trawick <tr...@gmail.com> wrote:
> > On Fri, Jan 23, 2009 at 5:31 AM, Greg Stein <gs...@gmail.com> wrote:
> >>
> >> Check for ebcdic? Are we *really* going to continue support for that?
> >> Seriously, folks.
> >
> > What is the better criteria?
> > * offends sensibility of at least one APR contributor
> > * actively used by and depended on by multiple APR contributors (and may
> be
> > a partial sponsor of the warm, dry environment necessary for APR hacking,
> > though that's probably a difficult determination to make for certain)
>
> If it is still being used, then... well, geez. *shudder*
>
> And in response to your question, "duh. not like I have any super-vote
> here. just opening a discussion."
Here's a better opening to such a discussion ;)
"Hey guys, here are some platforms/nuances/whatever currently in APR that I
think we might be able to drop in 2.0. Which are still being
used/maintained?" ;)
Re: SCons Updates... 2
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jan 23, 2009 at 13:24, Jeff Trawick <tr...@gmail.com> wrote:
> On Fri, Jan 23, 2009 at 5:31 AM, Greg Stein <gs...@gmail.com> wrote:
>>
>> Check for ebcdic? Are we *really* going to continue support for that?
>> Seriously, folks.
>
> What is the better criteria?
> * offends sensibility of at least one APR contributor
> * actively used by and depended on by multiple APR contributors (and may be
> a partial sponsor of the warm, dry environment necessary for APR hacking,
> though that's probably a difficult determination to make for certain)
If it is still being used, then... well, geez. *shudder*
And in response to your question, "duh. not like I have any super-vote
here. just opening a discussion."
Cheers,
-g
Re: SCons Updates... 2
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jan 23, 2009 at 5:31 AM, Greg Stein <gs...@gmail.com> wrote:
> Check for ebcdic? Are we *really* going to continue support for that?
> Seriously, folks.
What is the better criteria?
* offends sensibility of at least one APR contributor
* actively used by and depended on by multiple APR contributors (and may be
a partial sponsor of the warm, dry environment necessary for APR hacking,
though that's probably a difficult determination to make for certain)
Re: SCons Updates... 2
Posted by Greg Stein <gs...@gmail.com>.
Check for ebcdic? Are we *really* going to continue support for that?
Seriously, folks.
On Sun, Jan 11, 2009 at 08:04, Ryan Phillips <ry...@trolocsis.com> wrote:
> More updates...
>
> * Add detection of IPv6
> * Fix return code checking of TryRun's... Scons expects 1 as success (meh)
> * Add ebcdic, nonblock inherited check, tcp_nodelay, union semun,
> TCP_CORK/TCP_NOPUSH, getrlimit/setrlimit, in_addr, sockaddr_storage,
> rlimit struct, ... and more
> * Add sctp check
> * Add accept filter check
>
> -Ryan
>
Re: SCons Updates... 2
Posted by Ryan Phillips <ry...@trolocsis.com>.
More updates...
* Add detection of IPv6
* Fix return code checking of TryRun's... Scons expects 1 as success (meh)
* Add ebcdic, nonblock inherited check, tcp_nodelay, union semun,
TCP_CORK/TCP_NOPUSH, getrlimit/setrlimit, in_addr, sockaddr_storage,
rlimit struct, ... and more
* Add sctp check
* Add accept filter check
-Ryan
Re: SCons Updates...
Posted by Paul Querna <ch...@force-elite.com>.
Ryan Phillips wrote:
> Hi All,
>
> I've been adding bits and pieces to the scons build system for /trunk.
>
> * Add APRConfigureBase and APRConfigure classes
>
> The idea is to use APRConfigure and the base class to support cross
> compiles... For a cross compile a user can simply subclass
> APRConfigureBase and return the necessary results they need.
>
> Most compiled or executed applications ran at configure time will
> eventually be pulled into the class.
>
> * A few bug fixes for SIZE_T formats in apr.h
>
> * Added mmap and friends to function checking
>
> * Check for semaphores
>
> * Check for F_SETLK and flock
>
> Are the new classes heading in the right direction?
Yes, this is great, thank you!
Making the APRConfigureBase and allowing people to override when
cross-compiling will actually make cross compiling pretty easy too.
Nice Idea.
Committed in r733102.
-Paul