Thanks.
Oh, btw, the output from testmem:
APR Memory Test
===
Standard Memory
Creating the memory areaOK
Creating 10 lumps of memory, each 1024 bytesOK
Writing to the lumps of memory..OK
Check wha
Ok, I can take a hint :-)
Actually, this is very convenient, because I have other pending
deadlines. I'm looking forward to discussion when enough people
have looked at the code.
Good weekend everyone,
Sander
> What Ryan said.
>
> :-)
>
>
> On Thu, May 10, 2001 at 03:47:06PM -0700, [EMAIL PROTEC
What Ryan said.
:-)
On Thu, May 10, 2001 at 03:47:06PM -0700, [EMAIL PROTECTED] wrote:
> On Thu, 10 May 2001, David Reid wrote:
>
> > You know, I did post a suggestion and got zero response from anyone else on
> > the list (other than Luke). This *is* the APR development list isn't it?
> > For
On Thu, 10 May 2001, David Reid wrote:
> You know, I did post a suggestion and got zero response from anyone else on
> the list (other than Luke). This *is* the APR development list isn't it?
> For talking about APR code?
The memory code has been changing every few hours for the last three days.
You know, I did post a suggestion and got zero response from anyone else on
the list (other than Luke). This *is* the APR development list isn't it?
For talking about APR code?
> > BTW ... although I'm buried, it's looking really good from here!
> > Please please please,
> > agree on the 'shorten
The "correct" place is to add the directory memory to the list in
apr_modules in configure.in, then run
./buildconf;./configure;make
As for testmem, just do make testmem in the test directory. It'll be added
once we know the code works.
david
- Original Message -
From: "Sander Striker"
> > BTW ... although I'm buried, it's looking really good from here!
> > Please please please,
> > agree on the 'shortened names/filenames' and I will be very happy.
>
> I already did, so did Luke and Elrond. Actually I explicitly asked
> for it when handing the code over. The long names were just
Please ignore the last posted patch, it had a flaw.
This one is the correct one.
> Hi,
>
> I guessed these would be needed anyway, so I did a simple
> implementation of associating a type with cleanup functions.
>
> Now you can run all registered cleanup functions of a
> certain type in one call
Hi,
I guessed these would be needed anyway, so I did a simple
implementation of associating a type with cleanup functions.
Now you can run all registered cleanup functions of a
certain type in one call. Guess this comes in handy when
trying to implement pools in terms of a memory system.
One sma
> dreid 01/05/09 10:46:24
>
> Modified:test Makefile.in
> Added: test testmem.c
> Log:
> Add a test file for the new memory code. Pretty simple, but at least it
> tests that the code works and allows development to continue.
> Not included
> in the normal build.
Committed, thanks! (skipped the first patch, this is the second one)
Cheers,
-g
On Thu, May 10, 2001 at 10:10:17AM -0700, Bill Tutt wrote:
> Let's try this instead. :)
>
> Bill
>
> Index: apr_errno.h
> ===
> RCS file: /home/cvspub
Ok, trying to shed some light on this, because I'm afraid people
are going to get confused.
>>> the idea of providing an independent apr_memsys_join() with
>>> totally separate memory, totally separate semantics, that can
>>> cope with totally alien apr_memsys instances, thereby
>>> guaranteeing y
Attached diff should solve the problem.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 10 May 2001 12:45
> To: [EMAIL PROTECTED]
> Subject: cvs commit: apr/test testmem.c
>
>
> dreid 01/05/10 03:45:04
>
> Modified:test testmem.c
> Log
Forwarding this back to the list, somehow we dropped the
list by accident.
Sander
-Original Message-
From: Sander Striker [mailto:[EMAIL PROTECTED]
Sent: 10 May 2001 12:48
To: William A. Rowe, Jr.
Subject: RE: Memory code...
> > David Reid wrote...
> >
> > [...]
> > >> When you find the
On Sat, Apr 28, 2001 at 08:51:52AM -0700, [EMAIL PROTECTED] wrote:
>
> The ONLY way to print to stderr, stdout, stdin through APR is to call
> apr_open_std*. This is because APR doesn't use stdio on Windows. We use
> native I/O. That means that APR on Windows doesn't have any idea what you
> me
On Thu, May 10, 2001 at 07:31:08AM -0500, William A. Rowe, Jr. wrote:
> From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]>
> Sent: Thursday, May 10, 2001 5:58 AM
>
>
> > the idea of providing an independent apr_memsys_join() with
> > totally separate memory, totally separate semantics, tha
From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]>
Sent: Thursday, May 10, 2001 5:58 AM
> the idea of providing an independent apr_memsys_join() with
> totally separate memory, totally separate semantics, that can
> cope with totally alien apr_memsys instances, thereby
> guaranteeing you de
On Thu, May 10, 2001 at 05:33:23AM -, [EMAIL PROTECTED] wrote:
> wrowe 01/05/09 22:33:23
>
> Modified:.aprutil.dsp libaprutil.dsp
> Log:
> I _swear_ this was building at one time, yet I see nothing changed,
> and no attic. Have folks mucked directly in cvs again,
On Thu, May 10, 2001 at 11:54:20AM +0100, David Reid wrote:
> Why memsys??? I'm sorry I just don't follow the logic. The code deals with
> memory doesn't it?
semantics time:
apr_memory is a noun. to me, it implies ownership of the memory by apr.
apr_memory_system (or memsys): implies manageme
Hmm, replies inline.
> > Not our call is it? We're a library, so if the user wants to abort on a
> > call of APR_EINVAL then that's their business. We're simply telling
them
> > they passed in an invalid handle. Chances are they'll ignore it.
> >
> > Roy's recent email about asserts in librarie
Why memsys??? I'm sorry I just don't follow the logic. The code deals with
memory doesn't it?
> On Thu, May 10, 2001 at 01:54:51AM +0100, David Reid wrote:
> > Does anyone have any objections to simply calling this stuff
> > apr_memory_blah?
> >
> > That'll give us
> >
> > apr_memory_malloc
> > a
> > You will need the same kind of thing for stackable memory systems
> > -- there
> > needs to be a way for a developer to ensure that data allocated within a
> > data structure is as long-lived as the data structure itself.
>
> Could you expand on this? Ie, give a small example (I probably have
I'll look into it and see what the problem is.
Sander
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 10 May 2001 12:45
> To: [EMAIL PROTECTED]
> Subject: cvs commit: apr/test testmem.c
>
>
> dreid 01/05/10 03:45:04
>
> Modified:test testm
On Thu, May 10, 2001 at 01:54:51AM +0100, David Reid wrote:
> Does anyone have any objections to simply calling this stuff
> apr_memory_blah?
>
> That'll give us
>
> apr_memory_malloc
> apr_memory_realloc
> apr_memory_free
> apr_memory_is_tracking
> apr_memory_create
> apr_memory_reset
> apr_memo
On Wed, May 09, 2001 at 06:48:42PM -0700, dean gaudet wrote:
>
>
> On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:
>
> > my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a
> > problem???
>
> nope -- the ap_pool_join() is a promise by the caller that they won't
> destroy
Hi again,
>> [.. apr_memory_system_free() ..]
>> if (mem == NULL)
>> return APR_EINVAL; /* Hmm, is this an error??? */
>>
>> Yes, this is an error, but not something you would want to fail
>> on (otherwise I would have used an assert). Maybe you could do
>> somekind of warning at debug
Hello.
> > As some of you will have noticed I've just added a first pass at
> > the memory
> > code from the Samba folks. It's just a first pass but does build
cleanly,
> > when included in the build. I've not yet added it to the apr_modules
line
> > in configure.in as until we know it's buildin
APRUTIL LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2001/04/12 15:30:47 $]
Release:
2.0a9 : released December 12, 2000
RELEASE SHOWSTOPPERS:
* Need apu_compat.h to track the latest renames
[Will voulenteers - is on it]
* add m
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2001/04/27 20:01:34 $]
Release:
2.0a9 : released December 12, 2000
2.0a8 : released November 20, 2000
2.0a7 : released October 8, 2000
2.0a6 : released August 18, 2000
2
On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:
> my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a
> problem???
nope -- the ap_pool_join() is a promise by the caller that they won't
destroy pool B prior to destroying pool A. well, if you think of this in
terms of 1.3,
Does anyone have any objections to simply calling this stuff
apr_memory_blah?
That'll give us
apr_memory_malloc
apr_memory_realloc
apr_memory_free
apr_memory_is_tracking
apr_memory_create
apr_memory_reset
apr_memory_destroy
apr_standard_memory_create
apr_tracking_memory_create
etc...
all using a
31 matches
Mail list logo
