Steph Fox wrote:
> Rob's download page is at http://ctindustries.net/libxml/ if anyone
> needs to update their libxml copy locally.
Another thing: make sure you update your libxml def file to CVS HEAD;
otherwise the xsl build will break.
--
Edward Z. YangGnuPG: 0x869C48D
Edward Z. Yang wrote:
Steph Fox wrote:
Rob's download page is at http://ctindustries.net/libxml/ if anyone
needs to update their libxml copy locally.
Just a quick note: the new files don't seem to work properly with 5.2.5
unless you update ext/libxml/config.w32 to the branch version;
a
Steph Fox wrote:
> Rob's download page is at http://ctindustries.net/libxml/ if anyone
> needs to update their libxml copy locally.
Just a quick note: the new files don't seem to work properly with 5.2.5
unless you update ext/libxml/config.w32 to the branch version;
apparently the wrong lib is use
The win32 snapshot builds have been done since Jan 20/21, so maybe
there is more than 1 library to fix
No, the errors that caused the original failure were fixed within a day or
two. Also the snaps libxml is up to date, it's just the zip.zip one that
isn't. Machine probably needs a kick.
Rob
On 02/02/2008, Gregory Beaver <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm getting unresolved external symbol xmlXPathCompiledEvalToBoolean
> with the latest zip.zip, any plans to update libxml2 to .31 soon in zip.zip?
>
> Greg
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsu
Hi all,
I'm getting unresolved external symbol xmlXPathCompiledEvalToBoolean
with the latest zip.zip, any plans to update libxml2 to .31 soon in zip.zip?
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
And lo, the snapshot was "A Good Thing".
On 18/04/07, Richard Quadling <[EMAIL PROTECTED]> wrote:
This looks like it will be available in snaps.php.net in about 40 minutes.
Looking forward to it!
On 17/04/07, Rob Richards <[EMAIL PROTECTED]> wrote:
> Unless anyone sees a way to do this without
This looks like it will be available in snaps.php.net in about 40 minutes.
Looking forward to it!
On 17/04/07, Rob Richards <[EMAIL PROTECTED]> wrote:
Unless anyone sees a way to do this without adding the lock, I'd like to
commit this patch.
It adds a php_flock call only for windows. In doing
Unless anyone sees a way to do this without adding the lock, I'd like to
commit this patch.
It adds a php_flock call only for windows. In doing so I got rid of the
win32/flock files and now compile with flock_compat from main.
Rob
Richard Quadling wrote:
The testing I'm using is to launch m
The testing I'm using is to launch multiple copies of the same PHP
script simultaneously using php.exe (CLI mode). This could easily be
multiple FastCGI scripts or multiple ISAPI threads.
On 16/04/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Richard Quadling wrote:
> So isn't locking the
Richard Quadling wrote:
> So isn't locking the solution for Windows?
If this is single writer process, even with multithreads - a mutex
is most efficient, otherwise with concurrent writer processes, file
locking makes the most sense.
Bill
--
PHP Internals - PHP Runtime Development Mailing List
So isn't locking the solution for Windows?
On 16/04/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
On Windows, there is no such thing as a true open-write-for-append.
Unlike Unix, write for append mode is not atomic, internally it is a
seek + write. Mix that with multiple writers, and you
On Windows, there is no such thing as a true open-write-for-append.
Unlike Unix, write for append mode is not atomic, internally it is a
seek + write. Mix that with multiple writers, and you have an inherent
race condition built it.
Richard Quadling wrote:
> That's good news. Has a patch been s
That's good news. Has a patch been submitted? Even if it is initially
only a win32 compiler directive wrapping the lock?
On 14/04/07, Rob Richards <[EMAIL PROTECTED]> wrote:
I can sometimes reproduce the missing entries though never get data
corruption anymore.
This might now be a Windows only i
I can sometimes reproduce the missing entries though never get data
corruption anymore.
This might now be a Windows only issue with how it is caching writes. I
did a little debugging and no errors occurred.
The file was opened successfully every time, the data was written
(correct number of byte
So why are there missing entries?
I can even get the corruption back again if I use a shorter line (100
rather than 5000).
On 13/04/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
The new implementation does not use any locks, instead it uses direct
io, where locks are not necessary for append
The new implementation does not use any locks, instead it uses direct
io, where locks are not necessary for append operations.
On 13-Apr-07, at 6:33 AM, Richard Quadling wrote:
On 05/04/07, Rob Richards <[EMAIL PROTECTED]> wrote:
No difference using sprintf()/fwrite() instead of fprintf().
On 05/04/07, Rob Richards <[EMAIL PROTECTED]> wrote:
No difference using sprintf()/fwrite() instead of fprintf().
I did come across a similar issue from apache:
http://mail-archives.apache.org/mod_mbox/httpd-dev/199503.mbox/[EMAIL PROTECTED]
Changing to use VCWD_OPEN_MODE, write() and close() s
No difference using sprintf()/fwrite() instead of fprintf().
I did come across a similar issue from apache:
http://mail-archives.apache.org/mod_mbox/httpd-dev/199503.mbox/[EMAIL PROTECTED]
Changing to use VCWD_OPEN_MODE, write() and close() seems to work.
Rob
Rasmus Lerdorf wrote:
That still
That still doesn't make sense to me. Could you try doing an sprintf()
followed by an fwrite() then? Is fprintf() perhaps doing something
stupid internally? I'd really like to avoid a lock here.
-Rasmus
Rob Richards wrote:
> I can confirm that it does fail with the single fprintf call without t
I can confirm that it does fail with the single fprintf call without the
lock on Win32.
Using flock() does fix the problem in my tests.
I was able to fix win build using flock() instead of php_flock() and
defining HAVE_FLOCK in win32/flock.h
Rob
Richard Quadling wrote:
This test is with the
This test is with the multiline fprintf and no lock.
Adding the php_flock() has stalled the build process for Win32 (I
can't build on Win32 as I don't know how!).
On 05/04/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
Yes, but again, is this test with the single fprintf call? That's the
real
Is it possible that at the lowest layer within the C library that 4K
blocking is performed?
On 05/04/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
Ilia Alshanetsky wrote:
> Rasmus,
>
> Sorry for the delay in the reply. According to my tests on linux using
> the sample script provided by the orig
Yes, but again, is this test with the single fprintf call? That's the
real fix for this problem, not the lock.
-Rasmus
Richard Quadling wrote:
> Using PHP 5.2.2-dev (cli) (built: Mar 23 2007 07:02:57) I can
> replicate the problem on Windows.
>
> Using this single line command at the CMD prompt
Ilia Alshanetsky wrote:
> Rasmus,
>
> Sorry for the delay in the reply. According to my tests on linux using
> the sample script provided by the original bug reporter having no lock
> causes a problem when the error message is >4k in length. In this case
> multiple buffers are used and corruption
Using ProcMon on WinXP, you can see that the different processes
interleave the writes but in blocks of 4096 bytes. The remaining 929
bytes will sometimes be written after another processes 4096/929
bytes.
Locking IS required here.
On 05/04/07, Richard Quadling <[EMAIL PROTECTED]> wrote:
Using
Using PHP 5.2.2-dev (cli) (built: Mar 23 2007 07:02:57) I can
replicate the problem on Windows.
Using this single line command at the CMD prompt:
for %x in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do
start php -r
"ini_set('error_log','/tmp/test.log');for($i=0;$i<100;$i++)error_log(
Rasmus,
Sorry for the delay in the reply. According to my tests on linux
using the sample script provided by the original bug reporter having
no lock causes a problem when the error message is >4k in length. In
this case multiple buffers are used and corruption can happen (it did
on a dua
http://rquadling.php1h.com/main.c.diff.txt for HEAD. I don't know how
to patch a specific version.
On 05/04/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
Matt Wilmas wrote:
> Hi,
>
> Maybe just a Windows problem if it wasn't noticed yet, but I was compiling
> the latest 5.2 snapshot and got:
>
Matt Wilmas wrote:
> Hi,
>
> Maybe just a Windows problem if it wasn't noticed yet, but I was compiling
> the latest 5.2 snapshot and got:
>
> main.obj : error LNK2019: unresolved external symbol _php_flock referenced
> in function _php_log_err
> Release_TS\php5ts.dll : fatal error LNK1120: 1 unr
Hi,
Maybe just a Windows problem if it wasn't noticed yet, but I was compiling
the latest 5.2 snapshot and got:
main.obj : error LNK2019: unresolved external symbol _php_flock referenced
in function _php_log_err
Release_TS\php5ts.dll : fatal error LNK1120: 1 unresolved externals
Caused by this r
31 matches
Mail list logo
