Re: Strategy for Harmony to work with Visual Studio 2005?
On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I think the key reason is that this is non-standard stuff from microsoft's for-fee toolchain, and people in OSS try to avoid having a dependency on that. I wouldn't mind supporting this at some point a) once it becomes a standard and b) has broad acceptance, but I'm guessing that's going to take years. People who have used the free version of MSFT tools seem to just set the flag as you note. Honestly that seems like the best approach to me. Otherwise, you'll get tons of warnings from code that's intended to be portable across C compilers, which can't possibly be expected to switch to the microsoft-only APIs. Switching to the microsoft-only APIs inside of specialized parts of the tree that are only used on windows is one thing, but even then I'd advise against it since it ties you too closely to their toolchain. -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]Using APR for Harmony's native link to the OS
On 7/4/06, Marina Goldburt [EMAIL PROTECTED] wrote: Hi, To support the idea mentioned in the letter http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED], I've tried to implement the file I/O part of the Harmony portlib using APR. The JIRA issue with the patch is http://issues.apache.org/jira/browse/HARMONY-751. The main difficulty to implement I/O function using APR was the lack of modularity in the classlib native code (the other (not portlib) modules relies on the portlib functions returning OS I/O handles (but APR uses its own handles)). Please, review the patch and comment if the efforts to move OS/platform specific code to APR make sense and can be useful. For what it's worth, speaking as an APR developer, I really don't think this makes sense the way APR currently works. In this patch you're basically taking the approach of allocating a new pool whenever you need to call into an APR function. This is inefficient in the normal case (things like where you're doing it to call stat, then destroying the pool afterwards), since you end up allocating 8k worth of data to create the pool, only to free it immediately afterwards. It's worse in other cases, like in hyfile_open where you create a new pool to hold the file, but then proceed to leak it, returning from the function without stashing the pool anywhere, so you can't ever destroy it, it'll stick around until apr_terminate is called (probably via atexit, although I haven't looked at the entire patch so I don't know when it's actually being called). Until a version of APR exists that doesn't require the use of memory pools, this approach is simply not reasonable to take. If you want to work on making it possible to use APR without pools, please feel free to join us over on [EMAIL PROTECTED] and discuss the issue, I think it's an interesting task, and I'd love to talk about it. But until then, making use of APR in a garbage collected environment like a Java class library is simply not going to make sense for anything other than highly specialized situations where the pool overhead is acceptable (see the Tomcat JNI based APR connector for example). -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]Using APR for Harmony's native link to the OS
On 7/4/06, Mladen Turk [EMAIL PROTECTED] wrote: Garrett Rooney wrote: Until a version of APR exists that doesn't require the use of memory pools, this approach is simply not reasonable to take. I pretty much agree with you. The entire tomcat-native that makes a low level network abstraction is very much slowed down by the fact that we need to create the pool for every object either socket or file. The entire problem would disappear if there would be a simple apr_free. Unfortunately, it's not really as simple as that. The underlying APR allocators are optimized for quick allocation (a comparison and a pointer increment in the common case for non-threaded apps, that plus a mutex lock (hopefully noncontested) in threaded, IIRC) at the cost of not providing any of the infrastructure that would allow free to work. Adding that sort of support would be very nontrivial. Personally, I think a more practical approach is a separate set of functions that create APR objects without pools, with pool based wrappers built on top of them for use in systems that are built with pools in mind. Don't get me wrong, I love pools in many situations, but there are a huge number of applications that can't use APR today because it basically requires you to buy into the pool based approach to resource management, which just doesn't fit all programs. Anyway, now we're way off topic for this list ;-) -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [svn] PROPFIND errors on SVN repository-- please advise
On 6/29/06, bootjvm [EMAIL PROTECTED] wrote: All, Has anyone seen this SVN error before? Please advise: % svn _something_ ... svn: PROPFIND request failed on '/repos/asf/incubator/harmony/some/file' svn: PROPFIND of '/repos/asf/incubator/harmony/some/file' could not connect to server (https://svn.apache.org) % So I tried a simple checkout of the top-level README file: % svn checkout https://svn.apache.org/repos/asf/incubator/harmony/README README svn: PROPFIND of '/repos/asf/incubator/harmony/README' could not connect to server (https://svn.apache.org) % followed by non-secure HTTP route, % svn checkout http://svn.apache.org/repos/asf/incubator/harmony/README README svn: PROPFIND request failed on '/repos/asf/incubator/harmony/README' svn: PROPFIND of '/repos/asf/incubator/harmony/README': 302 found (https://svn.apache.org) % You can't check out a file, it's a dumb error, but that's what that means... This happened to me last night, so I decided to wait until this morning for the error to clear, but it persists. Any hints? I have never had any trouble accessing SVN before... Well, I hate to say it, but have you tried any of the usual kind of tests when you can't connect to an http server? Can you browse it in a browser? Can you ping the machine? Can you telnet in via port 80? Those errors about not being able to connect to the server sound like connectivity problems to me... -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn.apache.org checkin problem?
On 6/18/06, Mark Hindess [EMAIL PROTECTED] wrote: I've spent a hour or so doing integration work on the new awt/ accessibility/swing contribution but when I try to check it in I get: Transmitting file data ..svn: Commit failed (details follow): svn: PUT of '/repos/asf/!svn/wrk/e4d2e767-8216-0410-9287-d51fae1415dd/incubator/harmony/enhanced/classlib/trunk/modules/accessibility/make/common/build.xml': 500 Internal Server Error (https://svn.apache.org) Anyone any idea what might cause this? (I've tried several times over the last few hours and always get the same error on the same file.) It's making me nervous not having this big change checked in. What's your source ip address? I'm seeing a number of errors from 195.212.29.163 which could be you: [Sun Jun 18 10:17:06 2006] [error] [client 195.212.29.163] Could not get next bucket brigade [500, #0] Not that it's an especially useful error message, but hey, it's a place to start... -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] building...
On 6/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Thanks - I figured that out. It's an interesting difference from makefiles, as they tend to be more explicit and local - I can go into a directory and look at the makefile for the params used for building stuff local to that directory. Yeah, when I was trying to disect the vm build when it was first released I had similar problems. I wanted to run some of the build commands by hand to see a particular error without running the whole build, but it was very difficult to tell what the final string of arguments were, and once I had them it was difficult to tell what I would have to change to alter them. The other major problem was that when build problems occurred, compiles didn't stop. So if one file blows up because of an issue, the set of warnings in it immediately scroll off the screen and are replaced by hundreds more. On make based systems I'm used to it would stop after the first file, which is much more approachable when debugging. -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] More SVN restructuring thoughts... (was Re: Ant build | IOException)
On 6/8/06, Oliver Deakin [EMAIL PROTECTED] wrote: Would /classlib and /drlvm be checked out in your local workspace as peers to /trunk or would they be checked out under /trunk/classlib etc. and linked to the right bit of SVN from there? i.e. if you wanted to make local changes to classlib, say, and be able to incorporate them into your global build under /trunk, but also generate patches against the code in svn under /classlib/trunk for submission, where would the code you are making changes to be checked out to in the above diagram? (my knowledge of svn switch is somewhat slim...) The basic idea is that you initially check out a copy of trunk that has a few empty directories in it. Then, svn switch says hey, this directory in my working copy that used to point to $HARMONY/trunk/classpath (which is empty) should now point to $HARMONY/classpath/trunk. It'll then essentially check out the contents of $HARMONY/classpath/trunk into your working copy's classpath directory. At that point you can do things like run an update or a diff at the top level of your working copy and it'll nicely recurse into the switched subdirectories. If you make changes in those subdirectories there and commit them they'll be committed to the $HARMONY/classpath/trunk directory in the repository (or wherever you had that subdirectory switched to). Does that make sense? -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant build | IOException
On 6/7/06, Thorbjørn Ravn Andersen [EMAIL PROTECTED] wrote: svn checkout https://svn.apache.org/repos/asf/incubator/harmony ant -f harmony/enhanced/classlib/trunk/make/depends.xml download Please don't check out the root of the harmony tree. It's incredibly wasteful, that's far more content than you need, and it'll only get worse as more tags and branches are created. If you want to check out the trunk of the classlib, check out the trunk of the classlib: svn checkout https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk classlib -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross plaform issues
Garrett Rooney wrote: access to scalable IO facilities (IOCP, epoll, kqueue, etc...) See the apr_pool API, which uses epoll, kqueue, etc on the backend if available. Now that my message finally makes it through the ASF mail system, I notice that typo... That should be apr_poll, not apr_pool ;-) -garrett
Re: Cross plaform issues
Rodrigo Kumpera wrote: A quick look at APR reveal that it doesn´t provide all OS abstraction that a JVM needs. There are no functions to mark pages as executable, This is probably not there, but could be added to APR if people were interested and willing to write the code. access to scalable IO facilities (IOCP, epoll, kqueue, etc...) See the apr_pool API, which uses epoll, kqueue, etc on the backend if available. or workarounds for small diferences on syscalls or libC implementation. Uhh, that's what most of APR is... Not that I'm saying APR should definately be used, but in the interests of accuracy... -garrett
