On Sun, 15 Sept 2024 at 17:34, Eric Covener wrote:
> On Sat, Sep 14, 2024 at 9:12 AM Ivan Zhakov wrote:
> >
> > Hi,
> >
> > While working on APR-Util 1.7.x CMake support I noticed some issues with
> CMake build in APR 1.7.5. I fixed it in r1920366 [1].
> >
&
On Wed, 18 Sept 2024 at 12:03, Graham Leggett via dev
wrote:
> On 15 Sep 2024, at 18:57, Ivan Zhakov wrote:
>
> > I would be happy to enable LDAP by default, but it doesn't work right
> now so I think it's better to disable it until it is fixed. I tried to fix
>
ppy to enable LDAP by default, but it doesn't work right now
so I think it's better to disable it until it is fixed. I tried to fix it,
but without success. I configured GitHub Actions job with LDAP enabled:
https://github.com/apache/apr-util/actions/runs/10871254641/job/30164847244
Do you have any ideas how to fix it?
--
Ivan Zhakov
Hi,
While working on APR-Util 1.7.x CMake support I noticed some issues with
CMake build in APR 1.7.5. I fixed it in r1920366 [1].
But to continue my APR-Util 1.7.x work I need this fix released.
Current CHANGES:
[[[
Changes for APR 1.7.6
*) CMake: Install include/apr_encode.h. [Ivan Zhakov
guration
> > + run: cmake --build ${{github.workspace}}/apu/build --config ${{
> matrix.build-type }}
> > +
> > +- name: Test
> > + working-directory: ${{github.workspace}}/apu/build
> > + # Execute tests defined by the CMake configuration.
> > + # See https://cmake.org/cmake/help/latest/manual/ctest.1.html
> for more detail
> > + run: ctest -C ${{ matrix.build-type }} --output-on-failure
> >
> >
>
> The action isn't working because the file should be located in the
> .github/workflows/NAME.yml directory, rather than in .github/NAME.yml.
>
>
> Yes, you are right. I have fixed the file name in r1920340.
And I reverted .github changes from trunk in r1920463.
Thanks!
--
Ivan Zhakov
.7.5 release which was done a week ago.
I hope I will be able to do this next week. So I suggest waiting with
apr-util v1.7 until CMake changes will be done.
--
Ivan Zhakov
On Thu, 22 Aug 2024 at 08:42, Ruediger Pluem wrote:
>
>
> On 8/21/24 9:30 AM, Ruediger Pluem wrote:
> >
> >
> > On 8/20/24 6:15 PM, Ivan Zhakov via dev wrote:
> >> On Tue, 20 Aug 2024 at 17:40, Ruediger Pluem <mailto:rpl...@apache.org>> wrote:
>
On Tue, 20 Aug 2024 at 18:11, Joe Orton wrote:
> On Tue, Aug 20, 2024 at 03:45:05PM +0200, Ivan Zhakov wrote:
> > On Tue, 20 Aug 2024 at 14:18, Ivan Zhakov wrote:
> > > I don't know what was the idea of having separate timeout value and
> > > non-blocking flag
tps://lists.apache.org/thread/9m0n8s3zxq0wznnq9nyxswoqdhx7167b
>
> I think Ivan's right about the test case being wrong in that thread.
> Committed the suggested testsock.c fix in r1920070.
>
> I am +1 on both r1920061 and r1920070 for APR 1.7.x (and 1.8.x) but
> would like to see that it hasn't affected the CI results first.
>
> +1.
--
Ivan Zhakov
On Tue, 20 Aug 2024 at 17:40, Ruediger Pluem wrote:
>
>
> On 8/20/24 3:45 PM, Ivan Zhakov wrote:
> > On Tue, 20 Aug 2024 at 14:18, Ivan Zhakov i...@apache.org>> wrote:
> >
> > On Tue, 20 Aug 2024 at 13:47, Ruediger Pluem <mailto:rpl...@apache.org>>
On Tue, 20 Aug 2024 at 14:18, Ivan Zhakov wrote:
> On Tue, 20 Aug 2024 at 13:47, Ruediger Pluem wrote:
>
>>
>>
>> On 8/20/24 1:32 PM, Ivan Zhakov wrote:
>> > On Fri, 9 Aug 2024 at 08:29, Ruediger Pluem > rpl...@apache.org>> wrote:
>> >
>>
On Tue, 20 Aug 2024 at 13:47, Ruediger Pluem wrote:
>
>
> On 8/20/24 1:32 PM, Ivan Zhakov wrote:
> > On Fri, 9 Aug 2024 at 08:29, Ruediger Pluem rpl...@apache.org>> wrote:
> >
> > Any APR windows guy on the below?
> >
> > On Windows apr_socke
course to fail:
> >>
> >> Index: network_io/win32/sockets.c
> >> ===
> >> --- network_io/win32/sockets.c (revision 1917061)
> >> +++ network_io/win32/sockets.c (working copy)
> &
On Wed, 14 Aug 2024 at 14:33, Eric Covener wrote:
> FYI I plan to RM APR 1.7.5 some time next week (around Aug 19)
> --
> Eric Covener
> cove...@gmail.com
Sounds good to me!
I have double checked my recent CMake related backports to APR 1.7.x branch.
--
Ivan Zhakov
On Wed, 17 Jul 2024 at 10:44, Daniel Sahlberg
wrote:
> Den lör 13 juli 2024 kl 18:21 skrev Ivan Zhakov :
>
>> The problem was that build.bat in the patch contained "%*" (with
>> quotes). In case of no parameters it was evaluated as "", so ant was
>> e
ks to mail-archives.apache.org), so the previous _docs.txt patch also
> contained those changes. Maybe this patch should be applied first, or a
> total rebuild of docs should be done after everything else.
>
> I have regenerated the site in r1919196.
Thanks!!
--
Ivan Zhakov
On Sat, 13 Jul 2024 at 17:40, Ivan Zhakov wrote:
> On Mon, 8 Jul 2024 at 21:03, Daniel Sahlberg
> wrote:
>
>> Hi,
>>
>> In a thread a while back, I asked about building on win32 and suggested
>> to improve the documentation[1].
>>
>> At first I wa
r some reason it doesn't update the website in my
environment. It seems to be running successfully, but doesn't change files
in docs/ directory:
[[[
Buildfile: build.xml
Overriding previous definition of reference to classpath
BUILD SUCCESSFUL
Total time: 0 seconds
]]]
I am using JDK 22.0.1.
Do you have any ideas?
--
Ivan Zhakov
On Tue, 11 Jun 2024 at 09:37, Ivan Zhakov wrote:
> On Mon, 10 Jun 2024 at 21:58, Daniel Sahlberg
> wrote:
>
>> Den mån 10 juni 2024 kl 10:55 skrev Jun Omae :
>>
>>> Hi,
>>>
>>> On Mon, Jun 10, 2024 at 5:32 AM Daniel Sahlberg
>>
>>
>
hat the bar to get started with APR is
> relatively high. Please don't take this as complaints - I'd be happy to
> help in any way I can to improve the documentation.
>
> It would be great! Patches welcome!
--
Ivan Zhakov
On Fri, 26 Apr 2024 at 14:56, Daniel Sahlberg
wrote:
> Den tors 25 apr. 2024 kl 18:20 skrev Ivan Zhakov :
>
>> Hi,
>>
>> I am currently working on CMake and vcpkg [1].
>>
>> One problem that I noticed is that APR 1.7.x (and APR-Util 1.6.x)
>> insta
, but maybe it's overkill?
[1] https://vcpkg.io/en/
--
Ivan Zhakov
On Mon, 22 Apr 2024 at 17:01, Joe Orton wrote:
> On Sat, Apr 20, 2024 at 12:38:20PM +0200, Ivan Zhakov wrote:
> > I would suggest separating APR in different libraries, while keeping them
> > in one project/source tree.
> >
> > Something like that:
> > - apr-
On Mon, 22 Apr 2024 at 14:41, Graham Leggett wrote:
> On 22 Apr 2024, at 12:52, Ivan Zhakov wrote:
>
> The question is, is it worth it for such a marginal change?
>> Have you looked in to the practicalities and verified no major stumbling
>> blocks,
>> bearing in
On Mon, 22 Apr 2024 at 11:03, Nick Kew wrote:
>
>
> > On 20 Apr 2024, at 11:38, Ivan Zhakov wrote:
> >
> > Hi,
> >
> > In APR 2.0 we merged APR-Util **project** to APR. Which is IMHO a good
> thing.
>
> Um, apr-util was a separate library, but no
xlate-2 (?)
- apr-crypto-2
- apr-xml-2
- apr-ldap-2
- apr-memcache-2
- apr-redis-2
I want to clarify that I don't propose going back to apr-util time when APR
was splitted to separate projects: this proposal is only about libraries on
the disk.
What do you think?
--
Ivan Zhakov
tall.vcxproj]
> D:\a\apr\apr\build\Debug\testall.exe : fatal error LNK1120: 1 unresolved
> externals [D:\a\apr\apr\build\testall.vcxproj]
>
> I fixed it in r1917104 <https://svn.apache.org/r1917104>.
PS: Maybe it makes sense to switch to using CMake for all platforms to
avoid such problems in future...
--
Ivan Zhakov
wise I will ask here for help.
>
> We had a regression in apr-1-config that is now fixed and we have some
> nice fixes / improvements for Windows.
> I know that people think of releasing 1.8., but another 1.7 release seems
> to be the lower hanging fruit.
>
>
> +1.
--
Ivan Zhakov
HREAD_SETNAME_NP], 1,
> > + [Define if pthread_setname_np is available])
> > +fi
> > +])dnl
> > +
>
> Thsi configure check does *not* fail for me on SLES 11 where
> pthread_[gs]ername_np is not available. In config.log I find
>
> warning: implicit declaration of function ‘pthread_setname_np’
>
> but configure procees with a "yes". The buidl then succeeds, but the
> library is not usable due to the unresolvable symbol.
>
> Best regards,
>
> Rainer
>
--
Ivan Zhakov
9 <https://svn.apache.org/viewvc?view=rev&rev=1906889>
implements apr_thread_name_set() and apr_thread_name_get() for Linux
and Windows.
--
Ivan Zhakov
32 8 */
>
> /* size: 40, cachelines: 1, members: 5 */
> /* sum members: 32, holes: 2, sum holes: 8 */
> /* last cacheline: 40 bytes */
> };
>
> Nice, but I'd like to note that this change breaks ABI and can be released
only in APR 2.0.
--
Ivan Zhakov
On Thu, 16 Jun 2022 at 21:06, Ivan Zhakov wrote:
> On Wed, 5 Jan 2022 at 21:37, Ivan Zhakov wrote:
>
>> On Mon, 13 Sept 2021 at 11:57, Johan Corveleyn wrote:
>> >
>> > On Tue, Sep 7, 2021 at 3:58 PM Johan Corveleyn
>> wrote:
>> > >
>>
On Tue, 12 Jul 2022 at 12:01, Ivan Zhakov wrote:
> I have implemented new apr_thread_name_get()/apr_thread_name_set() API in
> branch 'thread-name':
> https://svn.apache.org/repos/asf/apr/apr/branches/thread-name/
>
> Implementation is based on patch in issue 60587 [
On Fri, 20 Jan 2023 at 03:44, Eric Covener wrote:
> 1.7.1-rc1 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.1
> [X ] +1 looks great!
> [ ] -1 something is broken
>
> +1 (Windows)
--
Ivan Zhakov
I'm fine with both approaches.
Btw I've recently backported several fixes to 1.7.x branch:
[[[
*) Fix attempt to free invalid memory on exit when apr_app is used
on Windows. [Ivan Zhakov]
*) Fix double free on exit when apr_app is used on Windows. [Ivan Zhakov]
*) Fix a regression in apr_stat() for root path on Windows. [Ivan Zhakov]
]]]
And CMake/GitHub Actions stuff.
--
Ivan Zhakov
it should persist and
> work out the back-out as needed? Otherwise I ask the project
> member's permissions to work from a new 1.7.x-rebuild branch
> for the following week based on 1.7.0, and replace 1.7.x with
> the 1.7.x-rebuild branch one week later.
>
> I hope none of us are looking to land in this quicksand again,
>
> +1.
--
Ivan Zhakov
On Wed, 29 Jun 2022 at 01:28, Yann Ylavic wrote:
>
> On Tue, Jun 28, 2022 at 6:08 PM Ivan Zhakov wrote:
> >
> > On Tue, 28 Jun 2022 at 00:24, Yann Ylavic wrote:
> > >
> > > Hi Ivan,
> > >
> > > On Mon, Jun 27, 2022 at 8:19 PM Ivan Zhakov
ame_np and
pthread_getname_np(). It also supports Windows 10, version 1607 or later.
I think the branch is ready to be merged into the trunk.
Thoughts?
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60587
--
Ivan Zhakov
On Fri, 8 Jul 2022 at 19:15, Ivan Zhakov wrote:
>
> On Thu, 30 Jun 2022 at 20:14, Ivan Zhakov wrote:
> >
> > > > > I think that we could try an alternative approach for that part of
> > > > > the problem. The alternative approach would have the same
On Thu, 30 Jun 2022 at 20:14, Ivan Zhakov wrote:
>
> > > > I think that we could try an alternative approach for that part of the
> > > > problem. The alternative approach would have the same characteristics
> > > > as the approach that had been used for
can help with some logic à la apr_socket_sendv()?
>
[[[
Each buffer must be at least the size of a system memory page and *must be
aligned on a system memory page size boundary*. The system writes one
system memory page of data from each buffer.
]]]
[[[
The total number of bytes to be written. Each element of aSegmentArray
contains a one-page chunk of this total. Because the* file must be opened
with FILE_FLAG_NO_BUFFERING*, the number of bytes must be a multiple of the
sector size of the file system where the file is located.
]]]
--
Ivan Zhakov
On Fri, 24 Jun 2022 at 14:21, Yann Ylavic wrote:
>
> On Wed, Jun 22, 2022 at 2:26 PM Ivan Zhakov via dev
> wrote:
> >
> > Suggestions and improvements are welcome.
>
> I don't see any warning left in trunk and 1.8.x, possibly we'd have a
> Windows /We
allocate for the number of
captures in the regular expression (preg->re_nsub). An additional
improvement would be to cap the allocation size based on the passed-in
limit (nmatch). I'll try to handle that separately.
Thoughts?
--
Ivan Zhakov
Index: server/util_pcre.c
===
;
> > +}
> > +
> > +return pthread_setname_np(td, name);
>
> We probably need to check for HAVE_PTHREAD_SETNAME_NP since it's _np
> (non-portable).
Thanks for the suggestion!
I'm not so familiar with autoconf stuff (that's why I created branch):
can I just check for HAVE_PTHREAD_SETNAME_NP or do I need some
autoconf magic to set it?
--
Ivan Zhakov
On Tue, 28 Jun 2022 at 00:24, Yann Ylavic wrote:
>
> Hi Ivan,
>
> On Mon, Jun 27, 2022 at 8:19 PM Ivan Zhakov wrote:
> >
> > For the longer version, let me first outline a few problems with the
> > current apr_thread_current() API:
> >
> > 1) ap
s
when iovec count is more than WSABUF_ON_STACK, but this would break
implicit assumption that apr_socket_sendv() is atomic like writev [2].
PS: Do we have a test for such apr_socket_sendv() call?
[1] https://linux.die.net/man/2/send
[2] https://linux.die.net/man/2/writev
--
Ivan Zhakov
On Mon, 27 Jun 2022 at 21:40, Yann Ylavic wrote:
> On Mon, Jun 27, 2022 at 8:35 PM Ivan Zhakov wrote:
> >
> > On Mon, 27 Jun 2022 at 21:14, Yann Ylavic wrote:
> >>
> >> On Mon, Jun 27, 2022 at 8:08 PM Ivan Zhakov wrote:
> >> >
On Mon, 27 Jun 2022 at 21:14, Yann Ylavic wrote:
> On Mon, Jun 27, 2022 at 8:08 PM Ivan Zhakov wrote:
> >
> > On Mon, 27 Jun 2022 at 21:01, wrote:
> >>
> >> +#ifdef WIN32
> >> +typedef apr_status_t (__stdcall *encdec_fn)(char*, const char*,
>
try.
Thoughts?
--
Ivan Zhakov
; apr_size_t*);
> +#endif
>
> This uses assumptions about calling convention used on the Win32 platform.
I don't think it's a good thing. Do we really need an array of callbacks?
May just inline all these calls?
--
Ivan Zhakov
On Wed, 22 Jun 2022 at 19:26, Yann Ylavic wrote:
> On Wed, Jun 22, 2022 at 5:57 PM Ivan Zhakov wrote:
> >
> > On Wed, 22 Jun 2022 at 17:29, Yann Ylavic wrote:
> >
> >>
> >> PS: now the macos guys have some work
> >> (https://github.com/a
2 66.67%
]]]
Sometimes it works as expected:
https://github.com/apache/apr/actions/runs/2542369041
Anyone have any ideas why it may happen?
--
Ivan Zhakov
ndows runners.
Action runners status is available on GitHub:
https://github.com/apache/apr/actions
(any GitHub account is required to see logs)
Suggestions and improvements are welcome.
--
Ivan Zhakov
On Tue, 21 Jun 2022 at 19:56, Yann Ylavic wrote:
> On Tue, Jun 21, 2022 at 6:21 PM Ivan Zhakov wrote:
> >
> > On Tue, 21 Jun 2022 at 19:16, Yann Ylavic wrote:
> >>
> >> On Tue, Jun 21, 2022 at 5:58 PM Ivan Zhakov wrote:
> >> >
> >>
=======
testreslist 3 1 33.33%
]]]
Is this what are you looking for?
--
Ivan Zhakov
ses the below warnings
> at least currently:
>
> testfile.c:1243:13: error: ‘test_datasync_on_stream’ defined but not
> used [-Werror=unused-function]
> testfile.c:1222:13: error: ‘test_datasync_on_file’ defined but not
> used [-Werror=unused-function]
>
> Hi Yann,
No, this change is unintentional. Just incorrect conflict resolution.
Should be fixed in r1902145.
--
Ivan Zhakov
On Wed, 5 Jan 2022 at 21:37, Ivan Zhakov wrote:
> On Mon, 13 Sept 2021 at 11:57, Johan Corveleyn wrote:
> >
> > On Tue, Sep 7, 2021 at 3:58 PM Johan Corveleyn
> wrote:
> > >
> > > On Tue, Feb 23, 2021 at 9:59 AM Mariusz W wrote:
> > > >
racefully not support those calls,
> conditionally, when the function
> doesn't exist on an older version of the OS.
>
> I checked, it's building fine here, did you forget to mention your
> arguments to the cmake
> invocation so we can sort this out? Which MSVC and which W
tax error: identifier 'apr_winapi_pfn_if_indextoname'
C:\Ivan\SVN\apr\apr-1.8.x\include\arch\win32\apr_arch_misc.h(507): error
C2059: syntax error: ';'
C:\Ivan\SVN\apr\apr-1.8.x\include\arch\win32\apr_arch_misc.h(504): error
C2513: ' ': no variable declared before '='
C:\Ivan\SVN\apr\apr-1.8.x\include\arch\win32\apr_arch_misc.h(507): error
C2065: 'apr_winapi_pfn_if_indextoname': undeclared identifier
C:\Ivan\SVN\apr\apr-1.8.x\include\arch\win32\apr_arch_misc.h(507): warning
C4047: '=': 'int' differs in levels of indirection from 'int *(__cdecl
*)(NET_IFINDEX,PCHAR)'
C:\Ivan\SVN\apr\apr-1.8.x\include\arch\win32\apr_arch_misc.h(507): error
C2146: syntax error: missing ';' before identifier 'apr_load_dll_func'
C:\Ivan\SVN\apr\apr-1.8.x\include\arch\win32\apr_arch_misc.h(504): error
C2100: illegal indirection
C:\Ivan\SVN\apr\apr-1.8.x\include\arch\win32\apr_arch_misc.h(504): error
C2064: term does not evaluate to a function taking 0 arguments
C:\Ivan\SVN\apr\apr-1.8.x\include\arch\win32\apr_arch_misc.h(504): warning
C4033: 'apr_winapi_if_indextoname' must return a value
[6/239] Linking C executable gen_test_char.exe
ninja: build stopped: subcommand failed.
--
Ivan Zhakov
On Wed, 9 Feb 2022 at 13:47, Ivan Zhakov wrote:
> On Tue, 8 Feb 2022 at 21:58, Evgeny Kotkov
> wrote:
>
>> Ivan Zhakov writes:
>>
>> > This part is now in the following branch:
>> >
>> https://svn.ostyserver.net/svn/asf/apr/apr/branches/
On Tue, 8 Feb 2022 at 21:58, Evgeny Kotkov
wrote:
> Ivan Zhakov writes:
>
> > This part is now in the following branch:
> >
> https://svn.ostyserver.net/svn/asf/apr/apr/branches/win32-pollset-wakeup-no-file-socket-emulation
> >
> > What do you think?
> >
ib particpate and this causes specific problems for .dll loaded
> modules like our lib.
>
That's true.
But Microsoft finally fixed this in Universal CRT ( Visual Studio 2015). In
UCRT beginthreadex() is almost a wrapper around CreateThread(). So maybe it
makes sense to require VS 2015 for APR trunk and just use CreateThread?
--
Ivan Zhakov
On Thu, 20 Jan 2022 at 17:39, Ivan Zhakov wrote:
> On Fri, 14 Jan 2022 at 18:19, Ivan Zhakov wrote:
>
>> On Thu, 13 Jan 2022 at 23:37, Ruediger Pluem wrote:
>>
>>>
>>>
>>> On 1/13/22 7:04 PM, Ivan Zhakov wrote:
>>> > [[ sorry for de
On Fri, 14 Jan 2022 at 18:19, Ivan Zhakov wrote:
> On Thu, 13 Jan 2022 at 23:37, Ruediger Pluem wrote:
>
>>
>>
>> On 1/13/22 7:04 PM, Ivan Zhakov wrote:
>> > [[ sorry for delayed response ]]
>> >
>> > On Fri, 7 Jan 2022 at 17:33, Yann Ylavic
_ERROR) {
> -rv = apr_get_netos_error();
> -goto cleanup;
> -}
> +/* Got the right identifier, return. */
> break;
> }
> closesocket(*rd);
> @@ -438,6 +431,9 @@ apr_status_t apr_file_socket_pipe_create(apr_socke
> apr_os_sock_put(in, &rd, p);
> apr_os_sock_put(out, &wr, p);
>
> +/* read end of the pipe is non-blocking */
> +apr_socket_timeout_set(*in, 0);
> +
> apr_pool_cleanup_register(p, (void *)(*in), socket_pipe_cleanup,
>apr_pool_cleanup_null);
> apr_pool_cleanup_register(p, (void *)(*out), socket_pipe_cleanup,
> --
>
>
Makes sense to me. Committed in r1897245 .
Thanks!
--
Ivan Zhakov
On Thu, 13 Jan 2022 at 23:37, Ruediger Pluem wrote:
>
>
> On 1/13/22 7:04 PM, Ivan Zhakov wrote:
> > [[ sorry for delayed response ]]
> >
> > On Fri, 7 Jan 2022 at 17:33, Yann Ylavic wrote:
> >>
> >> Hi Ivan,
> >>
> >> On Fri, Jan
[[ sorry for delayed response ]]
On Fri, 7 Jan 2022 at 17:33, Yann Ylavic wrote:
>
> Hi Ivan,
>
> On Fri, Jan 7, 2022 at 2:50 PM Ivan Zhakov wrote:
> >
> > This change does not compile on Windows in APR 1.7.x:
> > [[[
> > file_io\win32\readwrite.c(3
of indirection from 'void *'
file_io\win32\readwrite.c(326): warning C4024: 'WSASend': different
types for formal and actual parameter 5
file_io\win32\readwrite.c(325): error C2198: 'WSASend': too few
arguments for call
]]]
I also have a high-level objection against backporting this change to
APR 1.7.x: IMHO APR 1.7.x is a stable branch and I think that only
regression fixes should be backported to the stable branch. r1896510
is a significant change and as far as I understand it's not a
regression fix. So I think it would be better to revert r1896510 and
release it as part of APR 2.0 (or 1.8.x).
--
Ivan Zhakov
/ sizeof(apr_wchar_t), fname)))
> return rv;
> -if (!(wanted & APR_FINFO_NAME)) {
> + if (!(wanted & (APR_FINFO_NAME | APR_FINFO_LINK))) {
> if (!GetFileAttributesExW(wfname, GetFileExInfoStandard,
>&FileInfo.i))
> return apr_get_os_error();
>
> ]]]
>
> And yes, if I revert that single hunk, the Subversion problem with
> subst'ed drives on Windows (or working copies on drive roots) is gone!
>
> Of course, I have no idea what other effects this has, but just
> confirming that taking another turn in the above conditional (like it
> was before) makes apr_stat return the same (AFAICS) as in 1.6.5, for
> substed drives or drive roots on Windows.
>
Hi,
The problem with apr_stat(APR_FINFO_LINK | APR_FINFO_MIN) should be
fixed by r1896717 [1] in trunk.
This fix also should resolve performance regression in apr_stat()
in most common cases.
I plan to backport this fix to APR 1.7.x at some point later.
Testing and review will be much appreciated! :)
[1] https://svn.apache.org/r1896717
--
Ivan Zhakov
On Thu, 2 Dec 2021 at 22:33, Mladen Turk wrote:
>
>
> On 02/12/2021 13:21, Ivan Zhakov wrote:
> > On Wed, 1 Dec 2021 at 21:26, Mladen Turk > <mailto:mt...@apache.org>> wrote:
> >
> >
> > So no uuidof used in recent Windows SDK.
> >
> &g
we have
> those in trunk/apr-2 (that will be hopefully released one day).
>
> IMHO, we should drop all that as well as windows stuff like
> APR_HAS_ANSI_FS and _WIN32_WCE (the latest one beeing my fault)
>
>
> +1.
--
Ivan Zhakov
fine IID_IXmlReader _IID_IXmlReader
#define IID_IXmlWriter _IID_IXmlWriter
#define IID_IXmlResolver _IID_IXmlResolver
]]
So no uuidof used in recent Windows SDK.
Btw Visual Studio 2008 support ended April 10, 2018 [1].
[1]
https://devblogs.microsoft.com/visualstudio/end-of-support-for-visual-studio-2008-in-one-year/
--
Ivan Zhakov
apr_size_t *outwords);
>
> /**
> + * @deprecated @see apr_conv_utf8_to_utf16
> + */
> +#define apr_conv_utf8_to_ucs2(in, inbytes, out, outwords)
> apr_conv_utf8_to_utf16(in, inbytes, out, outwords)
>
As far as I understand this doesn't fix ABI compatibility: applications
linked with older APR cannot be used with newer one.
--
Ivan Zhakov
On Mon, 18 May 2020 at 07:42, Jan Ehrhardt wrote:
> Ivan Zhakov in gmane.comp.apache.apr.devel (Thu, 14 May 2020 12:08:26
> +0300):
> >Do we really need to keep compatibility code for operating systems
> >that are not supported for years just for a few special companies?
>
iscussed a year ago. Thread: "Supported
Windows versions for APR 2.0 (was Re: [PATCH] Optimize
apr_file_info_get(APR_FINFO_SIZE) on Windows)" [1]
[1]
https://mail-archives.apache.org/mod_mbox/apr-dev/201905.mbox/%3ccabw-3ydoqhj7iqptuej0donv4jhrlgglytzpfkckvmz+ueg...@mail.gmail.com%3e
--
Ivan Zhakov
On Wed, 13 May 2020 at 22:31, Mladen Turk wrote:
> On 13/05/2020 21:04, Ivan Zhakov wrote:
> > On Wed, 13 May 2020 at 11:41, Mladen Turk mt...@apache.org>> wrote:
> >
> > 1. Remove all those .dsp, .dsw .mak files from APR trunk
> > None of them
'm willing to solve all that since it's mainly
> cleanup of the copy/paste code that is dragging on for 10+ years
>
> [1] https://svn.apache.org/r1613114
--
Ivan Zhakov
t Windows."*/
> >> +return *mem;
> >
> > Where are we[1] ensuring *mem is aligned on an 8 byte boundary?
>
> Since mem is apr_uint64_t, unless the caller is playing nasty casts we
> should be good, I think.
+1.
Also InterlockedCompareExchange64() as all oth
On Wed, 16 Oct 2019 at 03:15, Yann Ylavic wrote:
>
> Hi Ivan,
>
> On Tue, Oct 15, 2019 at 11:13 AM Ivan Zhakov wrote:
> >
> > On Tue, 15 Oct 2019 at 01:16, Yann Ylavic wrote:
> > >
> > > Then I don't know if we care enough about WIN32, but if s
On Tue, 15 Oct 2019 at 01:16, Yann Ylavic wrote:
>
> On Tue, Oct 8, 2019 at 1:10 PM wrote:
> >
> > Author: ivan
> > Date: Tue Oct 8 11:10:32 2019
> > New Revision: 1868129
> >
> > URL: http://svn.apache.org/viewvc?rev=1868129&view=rev
> > Log:
> > apr_atomic_read64(): Fix non-atomic read on 32-b
On Sat, 14 Sep 2019 at 16:44, Ivan Zhakov wrote:
> Hi!
>
> The apr_socket_sendfile() has Windows specific flag
> APR_SENDFILE_DISCONNECT_SOCKET. When this flag specified
> instructs Winsock to disconnect socket and prepare it for
> reuse after file send.
>
> There are se
ndows/win32/api/mswsock/nc-mswsock-lpfn_disconnectex
--
Ivan Zhakov
Index: CHANGES
===
--- CHANGES (revision 1866558)
+++ CHANGES (working copy)
@@ -224,6 +224,8 @@
*) apr_socket_listen: Allow larger listen backlog valu
On Wed, 28 Aug 2019 at 10:08, Joe Orton wrote:
>
> On Sat, Aug 24, 2019 at 05:39:17PM +0300, Ivan Zhakov wrote:
> > For what it's worth, I'm -1 on the changes done in r1862071 and
> > r1862435 for the reasons listed above.
> >
> > PS: No idea if I can ac
On Thu, 25 Jul 2019 at 15:58, Ivan Zhakov wrote:
>
> On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote:
> >
> > On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
> > >
> > > On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> > > > They also m
On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote:
>
> On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
> >
> > On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> > > They also make the existing old API unusable for many cases thus
> > > making a s
On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
>
> On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> > They also make the existing old API unusable for many cases thus
> > making a switch to the new API mandatory, even though it doesn't have
> > to be so
On Tue, 2 Jul 2019 at 13:18, Joe Orton wrote:
>
> On Tue, Jul 02, 2019 at 09:59:20AM +0200, Branko Čibej wrote:
> > On 02.07.2019 08:49, Joe Orton wrote:
> > > On Thu, Jun 27, 2019 at 05:01:56PM +0300, Ivan Zhakov wrote:
> > >> On Tue, 25 Jun 2019 at 17:21, wro
.
>
> * file_io/win32/dir.c, file_io/os2/dir.c: Likewise, but untested.
> * test/testdir.c (test_pread) [APR_POOL_DEBUG]: Add test case.
>
> I'm not sure it's best fix. Better solution would be allocate buffer for
dirname + MAX_FILE_NAME in apr_dir_t and reuse it on every iteration. Win32
already has such code.
--
Ivan Zhakov
avoid doing
UTF8->UCS conversions per every apr_dir_read(), and I have that on my TODO
list.
Speaking of this commit, my aim here was to fix accessing the uninitialized
memory, as I did in r1860747. And this turned out to be much simpler with
the ANSI code path removed.
--
Ivan Zhakov
On Tue, 28 May 2019 at 12:17, Ruediger Pluem wrote:
> On 2019/05/28 09:12:01, Ruediger Pluem wrote:
> > On 2019/05/27 17:17:53, Ivan Zhakov wrote:
> > > On Mon, 27 May 2019 at 20:13, wrote:
> > > >
> > > > Author: ivan
> > > > Date:
Doing so reduces the amount of dependencies required for building and
using APR, which I believe to be a good thing in this particular case.
And it also means that by default we would be relying on the native
component of the OS rather than on a 3rd-party library.
Please let me know if there would be any objections against this change.
--
Ivan Zhakov
On Wed, 15 May 2019 at 15:25, Ivan Zhakov wrote:
>
> On Tue, 20 Dec 2016 at 10:58, Ivan Zhakov wrote:
> >
> > On 19 December 2016 at 06:45, William A Rowe Jr wrote:
> > > On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov wrote:
> > >>
> > >&
7/Windows Server 2008 R2 is the minimum supported Windows
operating system for APR 2.0.
I've made necessary changes in CHANGES in r1859474.
--
Ivan Zhakov
On Tue, 20 Dec 2016 at 10:58, Ivan Zhakov wrote:
>
> On 19 December 2016 at 06:45, William A Rowe Jr wrote:
> > On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov wrote:
> >>
> >> On 17 December 2016 at 21:47, William A Rowe Jr
> >> wrote:
> >>
>
ee that it would harder to backport fixes to
stable branches. What about release apr 1.8 without ANSI logic?
--
Ivan Zhakov
poll problem.
>>
>> There's quite a bit more in trunk (some of it annoyingly
>> not labelled in commit messages). I've gone briefly through
>> that and see no obvious backports. Anyone else?
>
>
> There's a list of changes done by Ivan Zhakov start
angesets were meant to be refactorings that make the code
> clearer, without altering its behavior, I think that they should be reverted
> for now.
>
> (I will prepare an alternative patch with these simplifications that doesn't
> change the behavior of the code.)
>
>
> Sorry for that,
> Evgeny Kotkov
Reverted r1806592 and r1806603 in r1806701.
--
Ivan Zhakov
On 26 August 2013 at 20:13, Stefan Ruppert wrote:
> Am 26.08.2013 17:48, schrieb Ivan Zhakov:
>>
>> On Mon, Aug 26, 2013 at 7:41 PM, William A. Rowe Jr.
>> wrote:
>>>
>>> On Mon, 26 Aug 2013 18:58:21 +0400
>>> Ivan Zhakov wrote:
>>>
&g
o includes the
> tests.
>
> The log messages are included in the beginning of each patch file.
>
> 1-file-write-simplify-local-vars-v1.patch.txt
Committed in r1806592.
> 2-file-write-simplify-fileptr-inc-v1.patch.txt
Committed in r1806603.
> 3-file-write-invert-if-condition-v1.patch.txt
Committed in r1806604.
> 4-fix-locked-append-deadlock-v1.patch.txt
Committed in r1806608.
Thanks!
--
Ivan Zhakov
existing property.
>
> - Probably, implementing the first approach would result in a bit more
> complex code, as I think that it would require introducing an additional
> if-else code path.
>
> The log message is included in the beginning of the patch file.
>
Committed 3-reduce-syscalls-for-buffered-writes-v2.patch.txt patch in
r1806308. Thanks!
--
Ivan Zhakov
1 - 100 of 154 matches
Mail list logo
