Re: [Libevent-users] Libevent 2.0.1-alpha is released
On Mon, Jun 01, 2009 at 05:47:42PM +0100, James Mansion wrote: [...] > Actually nonpersist_readd fails sometimes too - it hits one of the > exit(1)s. Shouldn't > the test just fail? Well, it should _pass_, actually. ;) But yeah, in the new "tinytest" system, a test should call tt_fail() rather than exit(). The nonpersist_readd() test calls exit() because it's a legacy test: it was written before we switched from the ad-hoc unit test system to the current test system. If somebody wants to convert all the old legacy tests to use the tt_* macros, that would be a fine thing. (One of the reasons that tinytest runs each test case in a subprocess is so that old tests can fail by calling exit() or assert() without bringing the entire testing process to a halt.) -- Nick Mathewson ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
On Mon, Jun 01, 2009 at 05:38:58PM +0100, James Mansion wrote: > Nick Mathewson wrote: > >Good morning, evening, night, or afternoon! > > > >The first alpha release in the long-promised Libevent 2.0 series > >is finally out. You can download Libevent 2.0.1-alpha from > > http://monkey.org/~provos/libevent-2.0.1-alpha.tar.gz > > > > > I have a number of patches designed to make the build on Win32 smoother. > I have the regress application building, although it does not run reliably. > > The biggest changes are in the rpcgen program - most of the others are > minor. > > Where should I send the patches? Try the sourceforge patch tracker at https://sourceforge.net/tracker/?group_id=50884&atid=461324 > I have a waf script that automates building the whole lot including > doing the config > stage if anyone is interested. Its not finalised (and I have yet to > make it work on > UNIX) but it may help dev without fiddling with msdev projects all the time. > Neat stuff. > The result fails the same way as the msdev build when a debug build is used, > and fails in other ways when an optimised build is done. > > What is the expectation for regress.exe --no-fork on Windows? The expectation for regress.exe on windows is that it pass with no errors. (FWIW, the --no-fork option is only for debugging and internal use; using it with more than one test at a time is likely not to work.) > At the moment > it fails in test_edgetriggered because the 'fd' passed to write isn't > appropriate. Weirdly, it works on mingw, which is why I hadn't noticed it. [I guess this is what happens from not having a working MSVC build.] But yeah, that should be a send, not a write. I've just fixed that in the repository. > I can't help feeling that the attempt to use raw UNIX-style APIs and fd > abstraction > on Windows is likely to be fraught - its easy enough to create an > abstraction that > works OK, but doing so using the raw UNIX abstractions seems to me likely to > end up fighting the differences between sockets, file handles, and fd as > emulated by > C runtime on Windows. > > It may be possible to bully it to work eventually, but its going to be > very messy. > > Is it really so unpalatable to break the API with the major version change? Heh. Unless somebody volunteers to rewrite all of *my* currently-working code that was written to use the existing APIs, I will sure find it unpalatable to break them. I suspect that other people who have written applications with the current Libevent will feel the same way. If there's something that really sucks in a current interface, the right approach is probably to add a _new_ API that can do the right thing, while we deprecate the old API but keep it working. That's what we did with event_set() in 2.0.1. yrs, -- Nick ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
James Mansion wrote: What is the expectation for regress.exe --no-fork on Windows? At the moment it fails in test_edgetriggered because the 'fd' passed to write isn't appropriate. Actually nonpersist_readd fails sometimes too - it hits one of the exit(1)s. Shouldn't the test just fail? James ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
Nick Mathewson wrote: Good morning, evening, night, or afternoon! The first alpha release in the long-promised Libevent 2.0 series is finally out. You can download Libevent 2.0.1-alpha from http://monkey.org/~provos/libevent-2.0.1-alpha.tar.gz I have a number of patches designed to make the build on Win32 smoother. I have the regress application building, although it does not run reliably. The biggest changes are in the rpcgen program - most of the others are minor. Where should I send the patches? I have a waf script that automates building the whole lot including doing the config stage if anyone is interested. Its not finalised (and I have yet to make it work on UNIX) but it may help dev without fiddling with msdev projects all the time. The result fails the same way as the msdev build when a debug build is used, and fails in other ways when an optimised build is done. What is the expectation for regress.exe --no-fork on Windows? At the moment it fails in test_edgetriggered because the 'fd' passed to write isn't appropriate. I can't help feeling that the attempt to use raw UNIX-style APIs and fd abstraction on Windows is likely to be fraught - its easy enough to create an abstraction that works OK, but doing so using the raw UNIX abstractions seems to me likely to end up fighting the differences between sockets, file handles, and fd as emulated by C runtime on Windows. It may be possible to bully it to work eventually, but its going to be very messy. Is it really so unpalatable to break the API with the major version change? James ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
Nick Mathewson wrote: Replacing timeval is probably a non-starter. It would be nice to remote the header dependency on Windows, but in order to remove struct timeval from all Libevent interfaces, we'd have to break backward API compatibility with all existing Libevent applications, which would probably not make us any friends. OK well I've been playing with replacing the production of the event-config.h file with waf, and I think the problem lies in inconsistent use of Windows headers. That type really needs to come from winsock2.h, and ideally ws2tcpip.h should be used to pull in the windows headers needed - there are some places where we just get windows.h and that just uses winsock.h which will cause trouble. Never mind. Yeah; I may have acted too dismissively to cmake initially. I think it would be a mistake to _replace_ our autotools stuff with cmake in a 2.0.x timeframe, but if cmake is the best way to produce project files that make VS people happy, I'd be fine using cmake for that. I'm actually happier with waf at the moment, but I realise that cmake has reasonable traction at the moment with some big projects using it. James ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
Nick Mathewson wrote: [...] > Yeah; I may have acted too dismissively to cmake initially. I think > it would be a mistake to _replace_ our autotools stuff with cmake in a > 2.0.x timeframe, but if cmake is the best way to produce project files > that make VS people happy, I'd be fine using cmake for that. > > [...] >> If you are more comfortable with make, why not just use nmake? Its not >> as if this is a >> very complex project structure. > > Sure, nmake would be fine too. I'd love to include a good nmake file > if anybody writes one. For my work on MySQL Proxy (which uses libevent, sure) I use both: * autotools for all the unixes * cmake for windows It is sometimes a pain as they are not always in sync, but both systems have their unique features and are important, like autotools "make distcheck" feature which does everything to verify that a build is good. I usually use cmake for the development phase (it is faster to build with cmake) and use automake and friends for the packaging and distribution. cheers, Jan -- jan: "Gee, Brain^WEric, what'd you wanna do tonight?" eric: Same thing we do everynight: Take over the HelloWorld! ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
On Fri, May 22, 2009 at 08:29:01PM +0100, James Mansion wrote: > Nick Mathewson wrote: > >"A private type"? What kind of thing do you mean here? > > > The struct just has a couple of integer fields and won't vary by > platform, so > having a libevent struct that can be converted is probably easy enough. > > All we really need is something that represents a time with a big enough > range and a decent resolution - I don't think a 'struct timeval' really > needs > to be in the interface. Replacing timeval is probably a non-starter. It would be nice to remote the header dependency on Windows, but in order to remove struct timeval from all Libevent interfaces, we'd have to break backward API compatibility with all existing Libevent applications, which would probably not make us any friends. > >OTHER QUESTIONS: > > > >Q1: > > > >It sounds like you're winding up with project files that are better > >than the ones we have. Is that so? Should we ship yours instead? > > > > > All I did was open in VS2008 Express and let it convert them. Well, and > a couple of tweaks to the include paths etc. I got the impression that > there > was some surgery going on for the directory structures etc. > >(I'd try to reproduce your changes, but I always screw up Visual > >Studio stuff whenever I touch it, and wind up making changes only to > >the debug build, or adding absolute paths by mistake, or stuff like > >that.) > > > Well, I do too. I tend to use the IDE for debugging and development > only. Its why I'd > suggest looking at cmake or something else. Yeah; I may have acted too dismissively to cmake initially. I think it would be a mistake to _replace_ our autotools stuff with cmake in a 2.0.x timeframe, but if cmake is the best way to produce project files that make VS people happy, I'd be fine using cmake for that. [...] > If you are more comfortable with make, why not just use nmake? Its not > as if this is a > very complex project structure. Sure, nmake would be fine too. I'd love to include a good nmake file if anybody writes one. -- Nick ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
Nick Mathewson wrote: "A private type"? What kind of thing do you mean here? The struct just has a couple of integer fields and won't vary by platform, so having a libevent struct that can be converted is probably easy enough. All we really need is something that represents a time with a big enough range and a decent resolution - I don't think a 'struct timeval' really needs to be in the interface. OTHER QUESTIONS: Q1: It sounds like you're winding up with project files that are better than the ones we have. Is that so? Should we ship yours instead? All I did was open in VS2008 Express and let it convert them. Well, and a couple of tweaks to the include paths etc. I got the impression that there was some surgery going on for the directory structures etc. (I'd try to reproduce your changes, but I always screw up Visual Studio stuff whenever I touch it, and wind up making changes only to the debug build, or adding absolute paths by mistake, or stuff like that.) Well, I do too. I tend to use the IDE for debugging and development only. Its why I'd suggest looking at cmake or something else. Q2: Were you able to compile regress.exe in test? That's the one with the I didn't try. Q3: There are a bunch of other new files in Libevent 2.0 that may not be in the old project files. On win32, the libevent_core library should contain: OK. I'll try to find the time to have another look, but its not easy right now. If you are more comfortable with make, why not just use nmake? Its not as if this is a very complex project structure. James ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
On Fri, May 22, 2009 at 07:44:36PM +0100, James Mansion wrote: > Nick Mathewson wrote: [...] > >So reading that message again, I guess I wasn't as explicit as I > >should have been. Short version: "yes, I think the next release will > >build okay with visual C. But somebody besides me test out the code > >in the subversion repository to make sure there aren't any surprises." > > > >yrs, > > > > (Using: Visual Studio Express and Windows 7 SDK Beta, Vista Home Premium > 32 bit) > > As of r1298. Thanks! I've fixed some of the stuff below, I hope. See comments at the bottom for some more stuff we should do that I will probably need help with. > - > > Build fails on ssize_t in args to evbuffer_reserve_space. > > If I search for ssize_t then I can see: > > #define _EVENT_ssize_t > use of ssize_t > use of SSIZE_T > use of ev_ssize_t > > I added: > > #define ssize_t _EVENT_ssize_t > > #define ev_ssize_t _EVENT_ssize_t I've changed the code to use ev_ssize_t thoughout, which should be defined in include/event2/util.h. [...] > time-test.c does not compile because event2\event_struct.h > uses struct timeval.h and WinSock.h has not been included. > > I added: > > #ifdef WIN32 > #include > #include > #include > #endif > > to time-test.c, but the reality is that any file including > event_struct.h will need to do this. I suggest using a > private type that is equivalent of including WinSock2.h > into a base libevent header. This isn't likely to increase > the dependencies of a Windows application that uses libevent. "A private type"? What kind of thing do you mean here? > - > > signal-test.c and time-test.c use the C99 __func__. > > I added: > > #define __func__ __FUNCTION__ > > in a Win32-specific block - I'm lazy, its compiler-specific > really. Fixed in svn. > - > > Execution fails: > > C:\src\libevent\WIN32-Prj>time_test\debug\time_test > [err] evsig_init: socketpair: Successful WSAStartup not yet performed > [WSANOTINITIALISED ] > > C:\src\libevent\WIN32-Prj>signal_test\debug\signal_test.exe > [err] evsig_init: socketpair: Successful WSAStartup not yet performed > [WSANOTINITIALISED ] Fixed these two too. > event_test fails the same way though I don't get an error > message when running from the command line (I do under the debugger, > which is odd). It looks like event_test is just plain broken on Windows. Whoever wrote it seems to have been under the impression that CreateFile would give you something you can pass to select(), which isn't so. (Yeah, we totally need new example code. If anybody wants to write some, that would be wonderful.) OTHER QUESTIONS: Q1: It sounds like you're winding up with project files that are better than the ones we have. Is that so? Should we ship yours instead? (I'd try to reproduce your changes, but I always screw up Visual Studio stuff whenever I touch it, and wind up making changes only to the debug build, or adding absolute paths by mistake, or stuff like that.) Q2: Were you able to compile regress.exe in test? That's the one with the actual serious regression tests that let us know whether Libevent is working. I don't know if there's a project for it. Its sources on win32 should be: regress.c regress.gen.c regress.gen.h regress.h regress_buffer.c regress_bufferevent.c regress_dns.c regress_et.c regress_http.c regress_iocp.c regress_main.c regress_minheap.c [NOT INCLUDED ON WIN32: regress_pthread.c] regress_rpc.c regress_util.c [NOT INCLUDED ON WIN32: regress_zlib.c] tinytest.c tinytest.h tinytest_macros.h Q3: There are a bunch of other new files in Libevent 2.0 that may not be in the old project files. On win32, the libevent_core library should contain: WIN32-Code/win32.c buffer.c buffer_iocp.c bufferevent.c bufferevent_async.c bufferevent_filter.c bufferevent_pair.c bufferevent_sock.c event.c event_iocp.c evmap.c evthread_win32.c evutil.c listener.c log.c strlcpy.c and the libevent_extra library should contain: event_tagging.c http.c evdns.c evrpc.c (The libevent library is for backward compatibility, and should contain all of the above.) If any of these sources are missing from the appropriate project files, they should be added in. yrs, -- Nick ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
Nick Mathewson wrote: On Tue, May 19, 2009 at 06:03:18PM -0400, Nick Mathewson wrote: [...] With respect to building it with Visual C, please see my message to this very list from last Thursday: http://monkeymail.org/archives/libevent-users/2009-May/001650.html So reading that message again, I guess I wasn't as explicit as I should have been. Short version: "yes, I think the next release will build okay with visual C. But somebody besides me test out the code in the subversion repository to make sure there aren't any surprises." yrs, (Using: Visual Studio Express and Windows 7 SDK Beta, Vista Home Premium 32 bit) As of r1298. - Build fails on ssize_t in args to evbuffer_reserve_space. If I search for ssize_t then I can see: #define _EVENT_ssize_t use of ssize_t use of SSIZE_T use of ev_ssize_t I added: #define ssize_t _EVENT_ssize_t #define ev_ssize_t _EVENT_ssize_t and compilation of the library completed, but that's hardly a sane solution. Note that SSIZE_T is defined (at least in the beta of the SDK for Windows 7) in BaseTsd.h, and that file is probably a good source for definitions that fake a lake of inttypes. - I had to add ..\..\include to the header search paths for the test projects, otherwise teh include of from evutil.h will fail. - I had to add Ws2_32.lib to the link dependencies for all the tests. - libevent fails to find definitions for a lot of functions named evmap_*. I added map.c to the file list for libevent. - time-test.c does not compile because event2\event_struct.h uses struct timeval.h and WinSock.h has not been included. I added: #ifdef WIN32 #include #include #include #endif to time-test.c, but the reality is that any file including event_struct.h will need to do this. I suggest using a private type that is equivalent of including WinSock2.h into a base libevent header. This isn't likely to increase the dependencies of a Windows application that uses libevent. - signal-test.c and time-test.c use the C99 __func__. I added: #define __func__ __FUNCTION__ in a Win32-specific block - I'm lazy, its compiler-specific really. - Execution fails: C:\src\libevent\WIN32-Prj>time_test\debug\time_test [err] evsig_init: socketpair: Successful WSAStartup not yet performed [WSANOTINITIALISED ] C:\src\libevent\WIN32-Prj>signal_test\debug\signal_test.exe [err] evsig_init: socketpair: Successful WSAStartup not yet performed [WSANOTINITIALISED ] event_test fails the same way though I don't get an error message when running from the command line (I do under the debugger, which is odd). ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
James Mansion wrote: I'll try to find an opportunity to grab from svn this evening. I've taken trunk - there's a tag for 2.01 but not branch for 2.0, right? ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
Nick Mathewson wrote: So reading that message again, I guess I wasn't as explicit as I should have been. Short version: "yes, I think the next release will build okay with visual C. But somebody besides me test out the code in the subversion repository to make sure there aren't any surprises." Ah. Well, I noticed that thread referenced 1.4.x so I thought I'd try the 2.x snap, since the completion port support makes this the first libevent of real interest to me. I'll try to find an opportunity to grab from svn this evening. James ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
On Tue, May 19, 2009 at 06:03:18PM -0400, Nick Mathewson wrote: [...] > With respect to building it with Visual C, please see my message to > this very list from last Thursday: > > http://monkeymail.org/archives/libevent-users/2009-May/001650.html So reading that message again, I guess I wasn't as explicit as I should have been. Short version: "yes, I think the next release will build okay with visual C. But somebody besides me test out the code in the subversion repository to make sure there aren't any surprises." yrs, -- Nick ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
On Tue, May 19, 2009 at 10:46:03PM +0100, James Mansion wrote: > Nick Mathewson wrote: > >Good morning, evening, night, or afternoon! > > > >The first alpha release in the long-promised Libevent 2.0 series > >is finally out. You can download Libevent 2.0.1-alpha from > > http://monkey.org/~provos/libevent-2.0.1-alpha.tar.gz > > > Is there any ambition that this can be built on Win32 at the moment? Yes. With MinGW, it has built all along. With respect to building it with Visual C, please see my message to this very list from last Thursday: http://monkeymail.org/archives/libevent-users/2009-May/001650.html You may want to read the rest of the thread too, for context. There should be a 2.0.2-alpha sometime in the next week or two that should build better for you. If anybody wants to try it out before then to make sure it builds for you, you can as always check it out from svn with "svn checkout https://levent.svn.sourceforge.net/svnroot/levent/trunk/libevent libevent" hth, -- Nick ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
Nick Mathewson wrote: Good morning, evening, night, or afternoon! The first alpha release in the long-promised Libevent 2.0 series is finally out. You can download Libevent 2.0.1-alpha from http://monkey.org/~provos/libevent-2.0.1-alpha.tar.gz Is there any ambition that this can be built on Win32 at the moment? I tried, thinking I'd then build a script for waf, but it seems completely broken - shows signs that the sources have been rearranged since the vstudio project was made, and more worryingly the provided config file is called event_config.h and defines symbols with names like _EVENT_*, while in Win32-Code there is a file called config.h which does not have the _EVENT_ prefix. James ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
On Fri, Apr 24, 2009 at 10:32:46AM -0700, Dan Kegel wrote: > On Sat, Apr 18, 2009 at 11:24 AM, Nick Mathewson wrote: > > Libevent 2.0 is intended to be backward compatible with the Libevent > > 1.4 APIs[*]. ?Any program that worked with Libevent 1.4 should still > > work with Libevent 2.0, unless we screwed up. ?Please test your > > programs when you have a chance, so that if we _did_ screw up, we can > > notice soon. > > > > [*] Unless you were messing around with the internals of internal > > structures. > > Say, wouldn't this be a good time to remove the deprecated event_gotsig > and event_sigcb interface? Valgrind just complained about a > thread race there on me, so I'm going to remove them from my > local copy... Good catch; done. -- Nick ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
On Sat, Apr 18, 2009 at 11:24 AM, Nick Mathewson wrote: > Libevent 2.0 is intended to be backward compatible with the Libevent > 1.4 APIs[*]. Any program that worked with Libevent 1.4 should still > work with Libevent 2.0, unless we screwed up. Please test your > programs when you have a chance, so that if we _did_ screw up, we can > notice soon. > > [*] Unless you were messing around with the internals of internal > structures. Say, wouldn't this be a good time to remove the deprecated event_gotsig and event_sigcb interface? Valgrind just complained about a thread race there on me, so I'm going to remove them from my local copy... ___ Libevent-users mailing list [email protected] http://monkeymail.org/mailman/listinfo/libevent-users
