Re: jira messages redirected to commits mailing list (was: [jira] Updated: (HARMONY-188) ...)
Sweet, many thanks. Craig On Mar 7, 2006, at 9:14 AM, Leo Simons wrote: Taking care of this now... I will note that this makes it even more important for committers and active contributors to subscribe to the commits mailing list - a lot of important information is in those jira messages. I will also note that it *also* makes it even more important that Jira is not used for discussion - that really needs to happen here on the mailing list where everyone can track it. The ASF has had some bad experience in the past with too much communication going via the issue tracker; this isn't so much a guideline as it is a pretty hard requirement. - Leo On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: Mark Hindess wrote: Geir, There are quite a lot of JIRA messages these days, perhaps it is time to split the JIRA traffic to a separate list with a reply-to set to harmony-dev. Or perhaps just have them sent to the commit list? Yes, please... +1e6 -Archie
Re: jira messages redirected to commits mailing list
One of the cooler Jira features is the mailing list integration. You can subscribe it to the mailing list, after which it will automatically scan email subjects for issue identifiers (i.e. HARMONY- ) and add the email content as a comment to the referenced issue, including attachments. That might make it easier to maintain discussion on the list and have it propagated into JIRA rather than the other way around, if that's the way people want to go. http://www.atlassian.com/software/jira/docs/latest/ issue_creation_email.html Craig On Mar 7, 2006, at 10:48 AM, Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Is there some way to teach JIRA not to send so much mail? Stop using it as a chat room. :) So what is the right way to use JIRA? - people open an issue, - maybe comment with a test case - maybe attach a patch or two - I may comment on the issue, with comments that are relevant to that specific issue - when I work on it I assign it to me, and say progress started - when I'm done I resolve it - when the reporter has verified it they comment to say so - I close it as verified What steps should I stop doing? Every state change produces mail to the world - even though it is likely only of interest to the reporter, assignee, and watchers. i.e. any way to solve the problem rather than move it ;-) Every change should be visible to everyone for maximum transparency, or so I believe. It would be a pain in the rear if one had to explicitly sign up for each jira one was interested in. Some people say every JIRA state change / comment is too much 'spam' -- you want to see them all ... That said, once the VM activity gets really honking, we'll probably need a second stream for those... Not sure why the VM is special here. Regards, Tim Leo Simons wrote: Taking care of this now... I will note that this makes it even more important for committers and active contributors to subscribe to the commits mailing list - a lot of important information is in those jira messages. I will also note that it *also* makes it even more important that Jira is not used for discussion - that really needs to happen here on the mailing list where everyone can track it. The ASF has had some bad experience in the past with too much communication going via the issue tracker; this isn't so much a guideline as it is a pretty hard requirement. - Leo On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: Mark Hindess wrote: Geir, There are quite a lot of JIRA messages these days, perhaps it is time to split the JIRA traffic to a separate list with a reply-to set to harmony-dev. Or perhaps just have them sent to the commit list? Yes, please... +1e6 -Archie -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Subversion problems?
I am on a Mac as well, and IIRC when setting up SVN originally I found the binary available from Fink did not support SSL. The binary available from Metassian does, however, and it seems to work pretty well: http://metissian.com/projects/macosx/subversion/ Craig On Jan 17, 2006, at 9:40 AM, [EMAIL PROTECTED] wrote: Ok guys thanks for the responses. Geir, George, your right I think, definitely looks like something my end now! I was using https://svn.apache.org/repos/asf/incubator/harmony as the url for my working copy, and the problems I am having are using the svn command line client (v1.2.3, r15833) on Mac OS X. Since you guys said you weren't having problems, I tried checking out the classlib from a dedicated server I've got running FC3 and svn command line client v1.3.0 (r17949), and it seems to be working fine! Leo, comments inline (apologies for any bad formatting, using webmail): On Tue, Jan 17, 2006 at 05:00:56PM -, [EMAIL PROTECTED] wrote: Hi guys, I've just tried updating my Harmony tree from Subversion, but I'm getting this error: svn: SSL is not supported This means your svn client was compiled without SSL support (or the webdav lib that svn uses, neon, was compiled without SSL support).
Re: half-baked idea? j2me
Seems like the difference is that once the little bootstrap piece is done you wouldn't need to recompile it every time... heck, you might not ever have to if you could just download a little binary for your platform. Craig On Nov 4, 2005, at 4:21 AM, Geir Magnusson Jr. wrote: On Nov 4, 2005, at 3:20 AM, Robin Garner wrote: Geir Magnusson Jr. wrote: On Nov 1, 2005, at 9:05 PM, Robin Garner wrote: Actually my colleagues at ANU and I were remarking last week that all the recent discussion on the Harmony list (configure scripts, packed structs etc etc) were close to being proof that Java was the easier way to go. C'mon... you still have to deal with that with a Java based VM because you still need the bootstrap stuff... geir Yes, but only in a tiny percentage of the code, only for a handful of API calls, and none of it performance critical. And all of it requiring configure scripts? :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: half-baked idea? j2me
Some of us are still hoping for a mostly Java based implementation. While I am apparently too tainted to contribute much, it will make it a lot more fun to play around with. Craig On Nov 1, 2005, at 6:05 PM, Robin Garner wrote: Rodrigo Kumpera wrote: On 11/1/05, Robin Garner [EMAIL PROTECTED] wrote: On 11/1/05, Robin Garner [EMAIL PROTECTED] wrote: Rodrigo Kumpera wrote: AFAIK IKVM, sablevm and jamvm all run on portable devices. Developing a j2me jvm is not as easier as it seens, first, the footprint and execution performance must be really optimized, so expect a LOT of assembly coding. Back to the language wars again :) This does not necessarily follow. Try googling for the 'squawk' VM - they had a poster at OOPSLA last week. This is a java-in-java virtual machine targetted at embedded devices. The core VM runs in 80KB of memory. Device drivers are all written in Java. Robin, With a java-in-java VM even if you don't write directly in assembly you still need to generate machine code with java anyway, and that will look a lot like asm (JikesRVM baseline JITer for example). With C, for example, you can get away using just an interpreter. My mistake, obviously. When you said performance must be really optimized, so expect a LOT of assembly coding, I assumed you were saying that large chunks of the VM would need to be written in assembler in order to get adequate performance. So what _was_ the point you were making ? cheers I was just trying to say that a decent j2me VM is not as simple as David suggested. Not that C or Java would be more suited to implement it. As a matter of fact, I think that java-in-java VMs can be as good as C/C++ based JVMs or better. But one thing is hard to deny, a simple JVM, like bootJVM, is a lot easier to write in C than in java (not using an AOT compiler). And that was my point, C/C++ sounds to be the easy path to start with. Actually my colleagues at ANU and I were remarking last week that all the recent discussion on the Harmony list (configure scripts, packed structs etc etc) were close to being proof that Java was the easier way to go. Another data point (FWIW) - joeq, excluding the compiler and the class library interface comes in at ~39,000 lines of code. bootJVM is already over 50,000. I know that KLOC is a pretty bogus measure of complexity, but it certainly says _something_. And Joeq is a fully functioning VM. cheers
Re: [arch] VM Interface
One potential use is for companies (and individuals) to work around particular performance limitations and bugs in the Sun VM while keeping the libraries they know inside and out. I imagine that could become common if Harmony ends up being as modular as we all hope. I am curious as to how much of the standard libraries would be rendered non-functional without the VM specific classes from Sun, however. Craig Blake On Jun 5, 2005, at 5:32 PM, Peter Donald wrote: Hi, It seems like there is a little bit of heat being generated by this topic due to confusion. While Geir has not actually stated this anywhere I assume that the reason that he is advocating for a VM interface that is independent of GNU Classpath is because he has plans to interoperate with other class libraries. I assume that if the Harmony JVM gets half as good as is hoped there will be companys who want to adopt the JVM but continue to use Suns class library so that differences in libraries don't hurt their customers. Consider IBM - There are a few people here (both active and lurkers) that are IBMers. They have publicly showed support for an open source JVM on numerous occasions and I am sure they would benefit considerably (as would Harmony) if this project was to get to that stage. However I suspect that it is likely that they want to stick with a derivative of Suns rt.jar for the moment. The reason being that their customers do not want to be exposed to differences between rt.jar and GNU Classpath. Given that IBM has already re-written large chunks of the JVM I suspect that over time they may move piecemeal to an OSS class library - at a pace at which they can verify it matches Suns behaviour. Another possibility would be the people from Brazil who are starting their own JVM and I would not be surprised if at some point someone wants to reimplement the class library using with a ASL/MIT or other license with fewer restrictions. I could be wrong but I guess the idea is to keep the options open and encourage collaboration with both big buisness and other OSS projects. --- Cheers, Peter Donald ** | You can't wake a person who is pretending | | to be asleep. -Navajo Proverb. | **
Re: [Harmony Wiki] Update of People by NicolasCannasse
Heh, well, depends on the particular one I suppose. :-) I don't know that it's important to be notified of each new interested party. I imagine we will get many thousands of them (ok, maybe not, but we can hope anyways). Maybe having separate messages for edits is overkill. Is there some way to have it post summaries or a digest at reasonable intervals instead? Craig On May 24, 2005, at 9:38 AM, Matt Benson wrote: --- Craig Blake [EMAIL PROTECTED] wrote: Yeah, please. Not sure if these are really valuable anyways. What, People? :) -Matt Thanks, Craig On May 24, 2005, at 8:33 AM, dan sinclair wrote: Can these either be turned off or sent to another list? They seem to generate a lot of email that isn't related to the topic at hand. Thanks, dan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Threading
I was discussing this recently and the view was put that really this level of scalability was probably not worth the various sacrifices associated with the approach (our load balancing leaves something to be desired, for example). So as far as I know, most VMs these days just rely on posix style threads. Of course in that case your scalability will largely depend on your underlying kernel threads implementation. Whether or not it's worth it depends on your needs. The lack of a highly scalable threading model in the current popular VMs is the reason why we have to use alternative architectures (like SEDA) to make truly scalable servers. Some of us would find it very valuable. ;-) It seems apparent that directly mapping to the underlying thread system results in a VM that doesn't scale very well on any of the common architectures including both MS and Linux, perhaps a different approach would be better? Craig --Steve
Re: Threading
Seems to me that you might want to be open to either using the platform's threading when a platform has good scalability, and punt and do it in VM when the platform doesn't offer it. If it can be done then I am all for it. Once the Harmony VM becomes modular it is something that can probably be investigated further, anyways. Craig geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Threading
Just out of curiosity, can anyone familiar with the various OSS VM implementations being discussed share their insights regarding the respective threading capabilities? I have heard of some commercial specialty VMs handling upwards of 30,000 concurrent threads easily and it would be wonderful to be able to have that sort of scalability (or more!) available in the Harmony effort. Thanks, Craig
