Re: [VOTE] Release 3.0 RC4 as 3.0 FINAL
+1 On Thursday 10 May 2007 3:29:31 pm Nick Burch wrote: Hi All Since no-one has raised any objections in the last week, I guess we all think we're ready to release 3.0 RC4 as 3.0 FINAL. Voting will close in one week: [ ] +1 I support the release [ ] +0 I don't care [ ] -1 I'm opposed to the release because... I'm +1 With any luck, this will be our last release as Apache Jakarta POI, and the next one will be Apache POI (no Jakarta). I guess we might want to do a 3.0.1 as Apache POI shortly after the TLP move, but we can decide that at the time :) Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: [VOTE] Move POI to TLP
+1 On Friday 04 May 2007 2:47:44 pm Nick Burch wrote: Hi All After lots of discussion within POI, and Jakarta in general, we think POI is ready to graduate to its own TLP. Thanks to the magic of ApacheCon, lots of people have been on-hand to help finalise the proposal for this, which is attached below. So, now is the time to vote on the proposal: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. Cheers Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Is Glen Stampoultzis still a POI developer?
Yeah, Glen is one of the oldest commiters on POI. I imagine, real life would be taking more of his time these days... I'd wait for him to reply a day or two, otherwise, if we have testcases, we should be confident to commit... that's the point of testcases, no? Regards - Avik On Tuesday 27 Mar 2007 7:38:19 pm Yegor Kozlov wrote: He doesn't seem to be posting in poi-user and poi-dev for quite a long time. He is the author of org.apache.poi.hssf.record.DrawingGroupRecord and I think I found a bug in it. Before applying the fix I would like to make sure it is correct and won't break anything. The bug is in DrawingGroupRecord.writeData. If the record is over max record size then continue record is not written right after the first portion. Instead it writes two chunks with sid=DrawingGroupRecord.sid and continue records only after it. In other words, DrawingGroupRecord serializes data as follows: [DrawingGroupRecord] [DrawingGroupRecord] [continued]... while it should be [DrawingGroupRecord] [continued] [continued] ... I found it when fixing Bug 28744 and have a test case which fails with Glen's code and works fine with my fix. Regards, Yegor - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Build/release stuff WAS Re: What Are Current POI Release Plans?
Most important issue was the file headers. Been fixed. Key signing needs to be arranged. Everything else (IMO) was a wishlist and/or general QA issue, not unexpected in an alpha release. Regards - Avik On Thursday 11 January 2007 08:58, Andrew C. Oliver wrote: Umm...okay so there will be a POI release when we release it. The rest is not part of a topic that I'm interested in discussing anymore. Build issues that I'm aware of: 1. Someone needs to anoint themselves release manager for 3.x.x XXx 2. Someone needs to get a valid key recognized by Apache. Given that I mainly only do patches anymore to fulfill customer requests and they have a long bake time and tend to be out of range for long periods of time, I'd like the first two not to be me. Lastly: can someone please figure out if we have any other REAL issues and list them here? Some seemed to be preference issues of Jakarta members. I do not plan to assist in satiating those. #2 is a serious issue, we should be signing releases. I will help with any serious legal or technical issues as the integrity of POI is important to me / our business. thanks, Andy David Fisher wrote: First let's talk about what is necessary to get the build to generate artifacts that comply. Yes - is it close now, or not? That is all I meant by roadmap BTW - Didn't I say I didn't want to get into that awful Jakarta General discussion. (I understand completely your Ackerly issue - having licensed a Microsoft Excel Developers SDK 12 years ago.) Yegor wouldn't be volunteering if I hadn't assigned him to work with POI 2 years ago, and that is no lie. I stay on the sidelines and offer advice. Generating Excel and PPT is important to us. (As is PDF, but that isn't in POI's roadmap. I generated PDF from C++ for Acrobat 1.0 in the early 90's. If Bill Gates is really jealous of PDF then he should have published the office file formats in 1992. He missed it, just like he missed the internet. I have it on good authority that just like Ballmer won't let his kids have an iPod, Bill won't look at a PDF.) I didn't intend this to be a venom thread, but you should know that if you tap it all of us have some. If we didn't have some Microsoft issues we wouldn't be eating the POI. Again, when and how will there be a POI release? Peace, Dave On Jan 10, 2007, at 4:02 PM, Andrew C. Oliver wrote: Roadmaps are lies in a volunteer open source project. Draw your own and just move it when it isn't met or put resources on the table to get them met. First let's talk about what is necessary to get the build to generate artifacts that comply. -Andy David Fisher wrote: Hi- OK. There was an attempt at a POI 3.alpha3 release last month, and Jakarta got into a big snit because it wasn't done right, etc. Then there has been a whole lot of effort to get everything updated to the current Jakarta standards. (This is the short version and I don't care about all the details as there is a long, long thread on Jakarta General about it.) Where is POI now? Is it almost time to vote for an actual release? IMHO the next release might as well be a final or RC one and not alpha or beta Could someone (Nick?) please provide a roadmap? I know that Yegor wants to do some HSLF refactoring to contribute some of the style improvements that he has already completed for me. He doesn't have every feature covered yet and this shouldn't necessarily block anything. Best Regards, Dave Fisher - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ --No PST Files Ever Again Buni Meldware Communication Suite Email, Calendaring, ease of configuration/administration http://buni.org - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
[VOTE][RESULT] Yegor as commiter
The vote has passed Vote Thread: http://mail-archives.apache.org/mod_mbox/jakarta-poi-dev/200612.mbox/[EMAIL PROTECTED] Eight +1 votes, zero -1 votes Four PMC Votes, Three committer votes Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Forrest and POI docs
Our documentation is currently being generated using apache forrest (http://forrest.apache.org/) I think it works pretty well (using our own definition of 'well' of course :) The trouble is, it apparently works only on forrest 0.5.1, since the support for something called 'antproxy.xml' has been removed (cant find when, from the changelogs) My inclination is to NOT move the build to the latest and greatest version of forrest. Having looked, I doubt it will be a trivial task, given that the learning curve in forrest is a difficult one... among other things I dont understand, apparently forrest now bundles its own version of ant (why on earth?) Further, forrest is not 1.0 yet, and the possibility of further incompatible changes is pretty high... we've already done a couple of rounds of refactoring of our documentation build process. I would therefore suggest that POI continue to build the documentation using forrest 0.5.1. Its just and extra click to download. We need to highlight this better in our own documentation of course. Therefore, if you have strong feelings about supporting the latest forrest version, now is the time to shout, and indeed, jump in and rewrite the build! Thoughts? Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Fixing the source headers
Thanks for this Henri. Comments inline. On Saturday 23 December 2006 02:38, Henri Yandell wrote: Turned out to be a pretty simple regexp change; so that's done for many of the files. I had to run dos2unix on a few to fix them, hopefully that wasn't a problem. Nope, wasnt. There are a few ASL 1.1 files in src/java/org/apache/poi/hssf/record/formula/ . Is that intended? Must have gotten missed when we updated the license. Nothing in POI is imported solely on the license, everything's under a CLA, AFAIK. Should be fine to update. Same for src/resources/devtools/poi.jin if anyone is using that. I'll update that. Tho dont think anyone uses it anymore. Hen On 12/19/06, Henri Yandell [EMAIL PROTECTED] wrote: Started to do this today and had to take a step back - the POI header style isn't catered for by the script. So I'll have to do some scripting etc. Board meeting tomorrow - so I'll hit this again in a few days (or next Tuesday at the latest). Hen On 12/19/06, Avik Sengupta [EMAIL PROTECTED] wrote: The commit message has come thru, [EMAIL PROTECTED] should now be allowed. Thanks again! Quoting Henri Yandell [EMAIL PROTECTED]: I made a fix to the DOAP file to test that (had to add svnadmins as rw to poi as the 'new' Jakarta perms meant that svnadmins couldn't write to the dir :) ). Hen On 12/17/06, Avik Sengupta [EMAIL PROTECTED] wrote: It wouldn't, as far as I'm concerned. Not sure if you apache address is allowed on the list, please ping me when you commit, in case I miss the moderation mail among all the spam. Thanks for the offer, much appreciated. Regards - Avik Quoting Henri Yandell [EMAIL PROTECTED]: Would it be a problem if I went through and modified the source headers and NOTICE as per: http://www.apache.org/legal/src-headers.html ? Hen --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ This message was sent using IMP, the Internet Messaging Program. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ This message was sent using IMP, the Internet Messaging Program. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Fixing the source headers
The commit message has come thru, [EMAIL PROTECTED] should now be allowed. Thanks again! Quoting Henri Yandell [EMAIL PROTECTED]: I made a fix to the DOAP file to test that (had to add svnadmins as rw to poi as the 'new' Jakarta perms meant that svnadmins couldn't write to the dir :) ). Hen On 12/17/06, Avik Sengupta [EMAIL PROTECTED] wrote: It wouldn't, as far as I'm concerned. Not sure if you apache address is allowed on the list, please ping me when you commit, in case I miss the moderation mail among all the spam. Thanks for the offer, much appreciated. Regards - Avik Quoting Henri Yandell [EMAIL PROTECTED]: Would it be a problem if I went through and modified the source headers and NOTICE as per: http://www.apache.org/legal/src-headers.html ? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ This message was sent using IMP, the Internet Messaging Program. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ This message was sent using IMP, the Internet Messaging Program. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Fixing the source headers
It wouldn't, as far as I'm concerned. Not sure if you apache address is allowed on the list, please ping me when you commit, in case I miss the moderation mail among all the spam. Thanks for the offer, much appreciated. Regards - Avik Quoting Henri Yandell [EMAIL PROTECTED]: Would it be a problem if I went through and modified the source headers and NOTICE as per: http://www.apache.org/legal/src-headers.html ? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ This message was sent using IMP, the Internet Messaging Program. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: [VOTE] Another alpha release?
+1a Quoting Amol Deshmukh [EMAIL PROTECTED]: +1a ~ amol --- Nick Burch [EMAIL PROTECTED] wrote: Hi All It's now about 6 months since our last alpha release, 3.0-alpha2. There's been quite a bit of new functionality added to HSLF, and bug fixes to HSSF and HWPF. So, I think a new release is probably in order. Asking around, it seems that people are planning some new features early in the new year, and a bit refactoring too (mainly in HSLF). Based on that, I think we should probably make this release another alpha one, then give serious thought to doing a beta release in Feb / March, when the new features are in. However, I wouldn't object to calling this one a beta, if people think that'd be better. So, could people vote, and include any thoughts they might have too? The options are: +1a - release as alpha +1b - release as beta 0 - I don't have a strong opinion either way -1 - I don't think we should do a release now I'm voting [+1a]. Voting will last for 1 week. (As with all Apache release votes, the votes of everyone are taken account of, but only PMC members have binding votes) Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ This message was sent using IMP, the Internet Messaging Program. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: build of poi in gump
There were, at one point, two poi builds in gump. I believe one was called poi, and another poi3. this was a result of certain experimental code we were toying with. Currently, there is only one active branch of POI, the svn trunk. Apologies for not fixing this ourselves, thanks for your help Regards - Avik Quoting Antoine Levy-Lambert [EMAIL PROTECTED]: Uhhm, I am going to go for it and configure the build of poi in gump to be done from the trunk. Let's see what happens next. Regards, Antoine Antoine Levy-Lambert wrote: Hi, I am an Ant committer ... and also a Jakarta committer. My main interest outside of Ant is in Slide right now. This leads me to look at the build of Slide in Gump. I have seen that Slide depends upon Poi. Poi does not build in Gump these days. It seems to be configured to build out of poi/branches/REL_2_BRANCH and not out of trunk. I am going to change this in the gump metadata, unless someone thinks there is a valid reason for that ? Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ This message was sent using IMP, the Internet Messaging Program. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: poi.apache.org commentary
Well my opinion is, 'cant we just get on with it, forget all these organisational stuff' ... but I suppose that's quite naive. I dont think there's any question that committers should have votes on new releases and new committers. In the jakarta scheme of things, that probably does mean that we'll need to be more proactive in getting POI committers on the PMC. We've been quite lazy on that front.. I hope to make certain amends soon. Given the direction of Jakarta, there's a resonable argument in moving to a TLP. I think that's a shame, though practically I'm quite agnostic to the idea. Regards - Avik Quoting Nick Burch [EMAIL PROTECTED]: On Thu, 13 Jul 2006, Nick Burch wrote: On Sun, 2 Jul 2006, Nick Burch wrote: What does everyone else think? Anyone? I think the main thing is: do we think committers should be allowed to vote on new releases and new committers? At the moment, committers aren't also PMC members, so we don't have that. If we think we should have, we need to move to our own TLP, and make all committers automatically PMC members. Does no-one have any opinions on this? Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ This message was sent using IMP, the Internet Messaging Program. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: GC and HSSF
Use the concurrent GC. On Wednesday 07 June 2006 13:14, Koller Krisztian wrote: Hi We are using the POI-HSSF to generate ms excel files. It works fine if the excel sheet contains only a few rows. In our production environment the excel files have more then 5000 rows. (20-30 columns / row) Some times during the generation of the excel sheet the jvm executes the garbage collector. Unfortunately the garbage collector runs more then two minutes long. Something - maybe the POI objects in the memory? - blocks the gc (and the whole application)... (without the poi objects the gc runs very fast (only a few millisec)) Any idea please? Regards, Krisztian - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: GC and HSSF
Concurrent GC is not about multiple processors. It will just spread the cost of the GC accros the total time of your program. Regards - Avik On Wednesday 07 June 2006 13:34, Koller Krisztian wrote: Thanks. But we have only one CPU. On 6/7/06, Avik Sengupta [EMAIL PROTECTED] wrote: Use the concurrent GC. On Wednesday 07 June 2006 13:14, Koller Krisztian wrote: Hi We are using the POI-HSSF to generate ms excel files. It works fine if the excel sheet contains only a few rows. In our production environment the excel files have more then 5000 rows. (20-30 columns / row) Some times during the generation of the excel sheet the jvm executes the garbage collector. Unfortunately the garbage collector runs more then two minutes long. Something - maybe the POI objects in the memory? - blocks the gc (and the whole application)... (without the poi objects the gc runs very fast (only a few millisec)) Any idea please? Regards, Krisztian - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: VOTE Sean Sullivan committer
On Thu, 13 Apr 2006, Andrew Oliver wrote: I propose Sean to be a committer with all rights therein but for his commit rights to automatically expire if he does not use them within 3 months or if he ever becomes bound by such an agreement. +1 Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Top level project status
I like status quo, but given the the 'core' as you call it is pretty active, the status may not be quo any longer... at which point, I think we must, again, regretably, ask for top level status. Regards - Avik Quoting Andrew C. Oliver [EMAIL PROTECTED]: http://wiki.apache.org/jakarta/OneCommunityProposals There is a pretty active core (primarily out of the commons crowd) that want to remake Jarkarta in Commons's image (my perception). Pretty radical but they go as far as even combining mail lists. I don't think that would be healthy for us at all. Regretfully I think we should discuss the merits of promotion to top level project status. I plan to -1 any such radical measures. If you're not on general@jakarta.apache.org list, then you may be like Wha? What is he talking about. I sugest you join and potentially ask for a recap. Thoughts? -Andy PS. I may be very latent ATM as I'm writing this from Milan, Italy (I live in Durham, NC) - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Development of poi-ruby contribution
Well, I did the poi-ruby module initially as a proof of concept, but havent been sure if its useful to anybody :) .. I'd be delighted to see it developed further. I dont believe you need to wrap the poifs modules. The good thing about poi, from the wrapping point of view, is that its got a clear encapsulation of its public api. So you need only start wrapping from HSSFWorkbook onwards. To start with read support, you essentially need to wrap the HSSFWorkbook constructor that takes an InputStream. For write support, there is the translation of a ruby IO object to a java OutputStream. Similary, you need to transform a ruby IO object to a java InputStream beyond that, you need to wrap more methods of HSSFWorkbook, and then the child objects of workbook, ie HSSFRow, HSSFCell, HSSFFormat etc.. some which are already done.. but more methods might be needed. Hope that helps. Shout if you need anything else. Regards - Avik Quoting Tim Taylor [EMAIL PROTECTED]: I have used POI for quite a while, but have recently started working in Ruby. I was very interested to see the poi-ruby extension, but after trying it out, it appears that this library can only create Excel files, not read them. It also appears that there has been no activity on this extension in 10 months since the initial commit. After reading the brief description of this extension available at http://jakarta.apache.org/poi/poi-ruby.html I noticed that providing the ability to READ excel files was listed as one of the TODOs. This item was also marked as being easy. As I have a need for this capability, I would like to go ahead and implement this functionality. However, before I started, I was hoping to get some thoughts on exactly what would need to be wrapped to provide this capability. Based on my initial and very brief review, it appears that many of the classes under the org.apache.poi.poifs package would need to be wrapped as well as more of the org.apache.poi.hssf.usermodel package and the org.apache.poi.hssf.eventusermodel package. Any suggestions or guidance would be appreciated before I get started. - Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: cvs-svn migration complete
Thank you, Henri, for doing all the hard work. Has the CVS been locked for further edits? Regards - Avik Quoting Henri Yandell [EMAIL PROTECTED]: http://svn.apache.org/repos/asf/jakarta/poi svn co https://svn.apache.org/repos/asf/jakarta/poi/trunk jakarta-poi Same list of committers as in cvs obviously. Commit emails goto [EMAIL PROTECTED] as before. Let me know if you have any problems, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: 500K patch file for rich text
Jason, When you put this in, can you ping the dev list, since its likely that the commit mail will be eaten up due to size... Regards - Avik Jason Height wrote: All, How do we want to handle this patch for the rich text support. The patch is quite large because it includes the pull method patch attached to bug 31906. I dont believe that this mailing list will allow me to send an email with a file that is arround the 500K mark, so this makes reviewing the diff difficult. I could just apply it and if there are any major problems then it can be backed out. Thoughts? Should this be done before or after a formal 3.0 release. I would have thought that 3.0 should contain something major maybe this is it. Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Embedding Pdf document inside Excel
On Tue, 2005-07-19 at 13:54 +0200, Malte Finsterwalder wrote: Hello, .. I would like to know whether it's possible to write an Excel document with an embedded pdf document using POI. Nope, not that I know of. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: src jar
Good idea, IMO. If so, one per binary jar, or one huge one? He who does, decides :) - avik On Wed, 2005-07-13 at 13:38 +0100, Nick Burch wrote: Hi All Unless I'm being muppet at reading ant build files, it seems we don't currently have a way to produce a source jar file for poi. It might be nice if we could spit one out, so I could include it with my cvs binary builds (for people not running java 1.5). Does it make sense to add one as an ant task? If so, one per binary jar, or one huge one? Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: [EMAIL PROTECTED]: Project jakarta-poi-3 (in module jakarta-poi-3) failed
There should be an xml file in the gump cvs that defines the project. Nick, you should have access, by default. I think we should delete the jakarta-poi project (it points to a branch that has been discontinued) . The jakarta-poi-3 project is the only significant one at the moment. Regards - Avik On Fri, 2005-07-08 at 11:03 +0100, Nick Burch wrote: On Fri, 8 Jul 2005, Gump [HEAD] :-( wrote: Project jakarta-poi-3 has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 15 runs. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - jakarta-poi-3 : POI Does anyone know if we control what gump looks for as its output? From reading the gump site, it seems some projects control it, and the rest have their config in the gump cvs tree itself Assuming no-one does know, I'll email the gump team and ask them to change from a hard coded -2.1- to pulling the version out of ant (these errors are because the jar files have stopped being poi-2.1-date, and are now poi-3.0-alpha1-date) As for the other gump errors, about the 2.5.1 failing to compile, I'm stumped as to what's up (my auto cvs checkout+build stuff is working fine). Anyone got any ideas? Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: [Bug 35527] - ArrayIndexOutOfBoundsException when reading xls file
Thanks Amol, this was a long standing bug.
Does you fix handle writing out as well? Sorry, too lazy to read the
code! :)
On Fri, 2005-07-08 at 16:59 +0200, [EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35527.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35527
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2005-07-08 16:59 ---
*** I thought i had resolved this issue as fixed ***
*** couple of days back, but my fix comments dont ***
*** appear, so I'm adding these comments again***
Further investigation revealed that the byte array
was falling short 2 bytes when the sid of the SubRecord
indicated an EndSubRecord.
Hence,
I made a slight modification in the change I proposed
earlier in the file I committed. Here is the changed part:
code
while (pos - offset = size-2) // atleast one short must be present
{
short subRecordSid = LittleEndian.getShort(data, pos);
short subRecordSize = -1; // set default to 0
if (pos-offset = size-4) { // see if size info is present, else default to
-1
subRecordSize = LittleEndian.getShort(data, pos + 2);
}
/code
Now, when the byte array falls short two bytes when dealing with
EndSubRecord, the length is implicitly set to 0 since the change
in ObjRecord now sets the length to default value of -1 if the
short value for the SubRecord size is not found.
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List:http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Build on the weekend
I remember the large amount of absolutely fantastic effort you put in originally to clean up our build process to use forrest rather than centipede (ugh!).. But if moving to forrest 0.7 isn't absolutely necessary, do you want to put in all this effort yourself, and get all of us to download 30MB again? What do we loose staying at an ancient forrest version? Of course, if you think its worth it, i have no issues at all. Regards - Avik On Mon, 2005-06-27 at 12:04 +1000, Glen Stampoultzis wrote: I promised a build on the weekend but got side tracked into upgrading to forrest 0.7 so it will be delayed until I get those issues sorted out. I noticed that there's very little in terms of changes listed for this release so I'd appreciate if people could post the stuff they've been working on (don't modify the status.xml file, just post the changes to the list). If you want to promote the stuff you've been working on this is your final chance. Also, please hold off doing any big stability reducing changes until we get this out. Regards, Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: [VOTE] Development Release
+1 On Sun, 2005-06-19 at 22:48 +1000, Glen Stampoultzis wrote: snip I'm proposing to call this release 3.0-alpha1. Please indicate whether you're +1, 0 or -1. Regards, Glen Stampoultzis - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
RE: FormulaRecord getValue setVal ue enhancement
Quoting Amol Deshmukh [EMAIL PROTECTED]:
--- [EMAIL PROTECTED] wrote:
This will break existing code. Very Bad Thing! Also,
with my Alan Cooper fanboy
hat on, I think recommending to /prefer/ calling
setCellType() is in itself a Bad Thing.
It wouldnt break existing code since existing code
would be throwing CastClassException anyway :) But I
get your point and am glad we had this discussion.
I would say, add a method called
setCellFormulaResult() overloaded for
string/num etc.
Yeah, probably a better option! Although maybe, I can
do something like:
Create inner nested class Formula which has the
overloaded setCellFormulaResult(..) methods ( a
constructor that takes in the formula string)... and
add setCellValue(HSSFCell.Formula f) to HSSFCell. This
will keep the HSSFCell api clean since it will just
add two methods (getFormulaValue/setCellValue(Formula
f) - and I can make the javadocs very clear about
how/when to use these method :)
I am sure we can fix the class cast exception on
calling setCellFormula
followed
setCellValue independently.
True. I should have thought of that! :) So now in
setCellValue(..) methods we can change:
if ((cellType != CELL_TYPE_STRING )
(cellType != CELL_TYPE_FORMULA))
{
setCellType(CELL_TYPE_STRING, false);
}
--TO--
if ((cellType != CELL_TYPE_STRING ))
{
setCellType(CELL_TYPE_STRING, false);
}
[Since we will have a setCellValue(Formula f) that
will take care of the formula with initial value]
Regards,
~ amol
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List:http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List:http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
RE: FormulaRecord getValue setVal ue enhancement
Can you put in the changes to the record and the aggregate ? I think your mail
brings out an important point... Of how to provide high level access to
formulas. Something i've put some thought to recently... But its the subject of
another mail, and much debate.
Sorry he you received an empty mail earlier.Quoting Amol Deshmukh [EMAIL
PROTECTED]:
--- [EMAIL PROTECTED] wrote:
This will break existing code. Very Bad Thing! Also,
with my Alan Cooper fanboy
hat on, I think recommending to /prefer/ calling
setCellType() is in itself a Bad Thing.
It wouldnt break existing code since existing code
would be throwing CastClassException anyway :) But I
get your point and am glad we had this discussion.
I would say, add a method called
setCellFormulaResult() overloaded for
string/num etc.
Yeah, probably a better option! Although maybe, I can
do something like:
Create inner nested class Formula which has the
overloaded setCellFormulaResult(..) methods ( a
constructor that takes in the formula string)... and
add setCellValue(HSSFCell.Formula f) to HSSFCell. This
will keep the HSSFCell api clean since it will just
add two methods (getFormulaValue/setCellValue(Formula
f) - and I can make the javadocs very clear about
how/when to use these method :)
I am sure we can fix the class cast exception on
calling setCellFormula
followed
setCellValue independently.
True. I should have thought of that! :) So now in
setCellValue(..) methods we can change:
if ((cellType != CELL_TYPE_STRING )
(cellType != CELL_TYPE_FORMULA))
{
setCellType(CELL_TYPE_STRING, false);
}
--TO--
if ((cellType != CELL_TYPE_STRING ))
{
setCellType(CELL_TYPE_STRING, false);
}
[Since we will have a setCellValue(Formula f) that
will take care of the formula with initial value]
Regards,
~ amol
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List:http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List:http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
RE: FormulaRecord getValue setVal ue enhancement
Sounds good! AFAIK, getValue for numbers and strings should already work in HSSFCell, no? there is, of course, no implementation for setting. getValueType -- is there enuf logic to know this for sure? Also, if you are doing this, you may as well update the HSSFCell methods ... pretty please! :) On Thu, 2005-06-09 at 17:17 -0400, Amol Deshmukh wrote: Ok.. thanks for the info! I didnt realise that FormulaRecordAggregate stored the string value of the formula evaluation. I dont think the PATCH for 35290 will have any adverse effects on the StringRecord. But looks like there needs to be a setValue(..) in the FormulaRecordAggregate that will set the correct value in a StringRecord if the calculated value is String. So here's what I've done locally in addition to the changes in current PATCH: In FormulaRecordAggregate.java 1. add setValue(..) overloaded for double, String , errorCode, blank value types 2. add getNumberValue(), getBooleanValue() , getErrorCodeValue() 3. add getValueType() I plan on doing testing with actual excel files as well to ensure deserializing and serializing both work fine after the change. If that seems fine to you, I will update the PATCH file for 35290. Regards, ~ amol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 09, 2005 2:19 PM To: Amol Deshmukh Subject: Re: FormulaRecord getValue setVal ue enhancement String formula results are stored as a String record that follows a formula record. POI handles them together as FormulaRecordAggregate. Can you ensure your patch does not mess this up? Thanks. Quoting Amol Deshmukh [EMAIL PROTECTED]: I started of trying to implement fix for 35288 but=20 realised that FormulaRecord assumes and stores only double value as the result of the formula. I checked OO documentation=20 (pg 163 of http://sc.openoffice.org/excelfileformat.pdf)=20 and it has description of how excel stores different value types for a formula result. So the patch attempts to do just that... ... but I assumed that for string formulas, the value is not stored since the value bytes are fixed length (8 bytes) so cannot hold a String of arbitrary length. Now, FormulaRecord can accept and serialize=20 values for formula of types other than double, this will enable a fix for 35288 (since instead of casting to specific Record, we hace option=20 of casting to FormulaRecord too since now it can accept different data types in the setvalue) (hope I made some sense :) ~ amol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 09, 2005 1:39 PM To: poi-dev@jakarta.apache.org Subject: Re: DO NOT REPLY [Bug 35290] - FormulaRecord=20 getValue setValue enhancement =20 =20 Amol, =20 Can you please talk us thru this patch.. I am not clear what=20 it does. In particular, I am not sure how this interacts with=20 StringRecord. Also does this help with your other bug (35288) =20 Thanks for the patch. =20 Regards - Avik =20 =20 Quoting [EMAIL PROTECTED]: =20 DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG=B7 RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=3D35290. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND=B7 INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=3D35290 --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 18:37 --- Created an attachment (id=3D15355) --=20 (http://issues.apache.org/bugzilla/attachment.cgi?id=3D15355act ion=3Dview) [PATCH] Enhancements to FormulaRecord for reading=20 calculated value of formula Prior to this Patch, FormulaRecord ignored non numeric values=20 (treated them as UNKNOWN). This patch modifies FormulaRecord so that it correctly=20 identifies the type of the value and stores it. Testcases have been=20 included in patch. Results were verified by running BiffView (since=20 FormulaRecord.toString() has also been modified accordingly). -- Configure bugmail:=20 http://issues.apache.org/bugzilla/userprefs.cgi?tab=3Demail --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:
RE: FormulaRecord getValue setVal ue enhancement
= More power to the user!! :) This will break existing code. Very Bad Thing! Also, with my Alan Cooper fanboy hat on, I think recommending to /prefer/ calling setCellType() is in itself a Bad Thing. I would say, add a method called setCellFormulaResult() overloaded for string/num etc. Remember, in many situations, people just depend on excel to recalc formula's, and this will enable existing code to work as-is for them. For users for whom this does not work, we provide additional powers. I am sure we can fix the class cast exception on calling setCellFormula followed setCellValue independently. Thoughts?? Regards - Avik Quoting Amol Deshmukh [EMAIL PROTECTED]: ** WARNING: LONG MAIL ** Now the only thing that keeps me from updating the patch as i discussed earlier is this: Normally, users do not need to use HSSFCell.setCellType since setvalue takes care of that... unless the original record is/was a FormulaAggregateRecord. In which case my patch will simply set the value as result of formula, but if the user meant to actually overwrite the cell contents (which was a formula string) with the new value in the setCellValue (s)he will have to explicitly call HSSFCell.setCellType to force the underlying record to change from FormulaRecordAggregate to LabelSSTRecord/NumerRecord/BoolErrRecord etc. Code to illustrate how things will function after the patch: 1 HSSFCell cell = row.getCell(idx); //get existing cell 2 3 cell.setCellValue(test); // set a string value If cell contained a formula, then after line 3, the formula's result value will be set to the string, the cell contents will STILL BE A FORMULA. To force the contents to change from formula to string: 1 HSSFCell cell = row.getCell(idx); // get existing cell 2 cell.setCellType(HSSFCell.CELL_TYPE_STRING); // IMP!! 3 cell.setCellValue(test); // set a string value Line 2 is now required to force the underlying record to change from FormulaRecordAggregate to LabelSSTRecord. This code will result in the cell containing String, not formula. This changes the semantics of the API slightly, since now it may be recommended to /prefer/ calling setCellType(..) explicitly in the user code. Changing the semantics is a BadThing, but the advantage is that: a. setCellFormula(..) followed by setCellValue(..) will NOT throw ClassCastException :) b. setCellFormula(..) followed by setCellValue(..) will allow user to set the default value for the formula evaluation. Whereas, setCellType(..) followed by setCellValue(..) will overwrite the formula in the cell with the string/number/bool value specified = More power to the user!! :) Regards, ~ amol -Original Message- From: Avik Sengupta [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 10:32 AM To: poi-dev@jakarta.apache.org Subject: RE: FormulaRecord getValue setVal ue enhancement Sounds good! AFAIK, getValue for numbers and strings should already work in HSSFCell, no? there is, of course, no implementation for setting. getValueType -- is there enuf logic to know this for sure? Also, if you are doing this, you may as well update the HSSFCell methods ... pretty please! :) On Thu, 2005-06-09 at 17:17 -0400, Amol Deshmukh wrote: Ok.. thanks for the info! I didnt realise that FormulaRecordAggregate stored the string value of the formula evaluation. I dont think the PATCH for 35290 will have any adverse effects on the StringRecord. But looks like there needs to be a setValue(..) in the FormulaRecordAggregate that will set the correct value in a StringRecord if the calculated value is String. So here's what I've done locally in addition to the changes in current PATCH: In FormulaRecordAggregate.java 1. add setValue(..) overloaded for double, String , errorCode, blank value types 2. add getNumberValue(), getBooleanValue() , getErrorCodeValue() 3. add getValueType() I plan on doing testing with actual excel files as well to ensure deserializing and serializing both work fine after the change. If that seems fine to you, I will update the PATCH file for 35290. Regards, ~ amol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 09, 2005 2:19 PM To: Amol Deshmukh Subject: Re: FormulaRecord getValue setVal ue enhancement String formula results are stored as a String record that follows a formula record. POI handles them together as FormulaRecordAggregate. Can you ensure your patch does not mess this up? Thanks. Quoting Amol Deshmukh [EMAIL PROTECTED]: I started of trying to implement fix for 35288 but=20 realised that FormulaRecord assumes and stores only double value as the result of the formula. I checked OO documentation=20 (pg 163 of http://sc.openoffice.org/excelfileformat.pdf)=20 and it has description of how excel stores different value types for a formula result. So the patch attempts to do just
Re: DO NOT REPLY [Bug 35290] - FormulaRecord getValue setValue enhancement
Amol, Can you please talk us thru this patch.. I am not clear what it does. In particular, I am not sure how this interacts with StringRecord. Also does this help with your other bug (35288) Thanks for the patch. Regards - Avik Quoting [EMAIL PROTECTED]: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35290. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35290 --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 18:37 --- Created an attachment (id=15355) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15355action=view) [PATCH] Enhancements to FormulaRecord for reading calculated value of formula Prior to this Patch, FormulaRecord ignored non numeric values (treated them as UNKNOWN). This patch modifies FormulaRecord so that it correctly identifies the type of the value and stores it. Testcases have been included in patch. Results were verified by running BiffView (since FormulaRecord.toString() has also been modified accordingly). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
RE: [PATCH] FormulaEvaluator functions added
Ok, I'll put it in. Dont assign bugs to yourself, leave it assigned to be the lists, else we cant figure when you put in new comments :) On Fri, 2005-06-03 at 05:30 -0700, Amol Deshmukh wrote: --- Additional Comments From [EMAIL PROTECTED] 2005-06-01 19:52 --- Some testcases failed! snipped/ Not sure, but these seem to be places where you have =NA() as the expected value. Can you pls investigate, thanks! Avik, I presume you opened the test xls in OpenOffice. The =NA() values are actually Error values (#VALUE! etc.), since those tests check if the evaluator can return error values when that is the expectation. However, OpenOffice seems to evaluate some of the formulas that return error in excel. I have fixed problems in the core eval classes that was causing the automated tests to fail and updated the patch - so the new patch file should be good to go :) Regards, ~ amol - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
[VOTE] Nick and Amol as committers
Nick Burch has been working on the Powerpoint support for POI for a while now. His code has been recently committed to the repository, and I'm sure there is more on the way. Amol Deshmukh has added significant new functionality to POI in formula evaluation, and has offered many other bugfixes and comments over the past few months. I believe it is time that they checked in their own pathes now :) Please provide your votes for Nick Burch as jakarta-poi committer [ ] Amol Deshmukh as jakarta-poi committer [ ] To start, here's my +1 to both. Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Powerpoint support
(cc'd to poi-user, apologies if you therefore recieve it twice) The initial powerpoint support is now in POI's CVS, in the scratchpad area. Tests and introductory documentation included. (Glen, could you pls regenerate the site?) A round of applause to Nick Burch for getting us there. Long way to go for full support, so I'm sure the POI team, and Nick in particular, will appreciate all the help, if only for tests and bug reports. Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: [PATCH] - enhanced the HSSFCellStyle constants list
Committed, thanks. In the future, could you please attach patches to our bug tracker http://issues.apache.org/bugzilla/ Things in emails tend to fall thru the cracks. Also, anything without unit tests is less likely to be evaluated or committed... our experience shows that code without unit tests tend to bit-rot fairly quickly. Regards - Avik On Fri, 2005-05-20 at 22:02 +0200, Andreas Engel wrote: Hello out there, i'm not sure this hits the right place. if thats the case please give an advice where to post instead. while using the poi library for some time now i had to play around with excel cell styles, mainly the bgcolor attributes. so i realized that there are two constants missing: the lesser and least dotted styles. i added them to class HSSFCellStyle. someone should check the wording of the constant names. please take this as a kind of test for further commitments to this project. any advice to meet common commitment rules is appreciated. and last but not least ... the patch file: thanks for your outstanding work andreas engel, germany mail AT a-engel.de - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Is there a schedule for the next release?
I don't think that having only writing functionality (or the fact that creating a new drawing removes old one's) are necessarily a problem. AFAICS, the issues are a) some files failing to read, and b) some files being corrupted on re-write, both of which are obvious regressions from some of our previous releases. However, with all the new functionality in, a couple of dev releases on the way would certainly help. On Thu, 2005-05-19 at 21:49 -0700, [EMAIL PROTECTED] wrote: Well what makes sense is to have a toggle switch for now. Basically yes see the drawing stuff and no don't see the drawing stuff. Or someone finish the drawing stuff so that it read/writes properly. The drawing stuff was a SuperLink Software customer and the deal was to make it possible to write images not necessarily read them. Generally we write estimates to feature complete, but this one was an exception. It was probably a mistake to have the image stuff on by default since it does not properly read them. -Andy Avik Sengupta wrote: Personally I would like to see some more time before we cut a release, since there is, after some months of low activity, some nice momentum in our development. Further, I would like to ensure all file corruption issues in 2.5.1 are solved before we do a new release. Having said that, our release planning (and release numbering) have been somewhat inconsistent historically :), so the above is certainly likely to change! On Wed, 2005-05-18 at 00:28 +0200, Mikael Sitruk wrote: Hi I would like to know when the next release will be released? The 2.5.1 is 8 months old already Mikael.S -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
data format
Dumb question: How does one get the data format of an existing cell (ie, excel file read in by POI) as a string (ie, as '#0.00') TIA - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Unicode in Header/Footer
I believe this was fixed.. can someone please confirm? http://issues.apache.org/bugzilla/show_bug.cgi?id=22873 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
FormulaEvaluator comitted
You'd have seen the directory add messages slowly trickling in, but the main diff mail was probably eaten coz it was too big. In any case, its in scratchpad now. So please test aggressively! Amol, once again, thanks and great work. I have a few ideas on this, more in another mail. Regards - Avik -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Is there a schedule for the next release?
Personally I would like to see some more time before we cut a release, since there is, after some months of low activity, some nice momentum in our development. Further, I would like to ensure all file corruption issues in 2.5.1 are solved before we do a new release. Having said that, our release planning (and release numbering) have been somewhat inconsistent historically :), so the above is certainly likely to change! On Wed, 2005-05-18 at 00:28 +0200, Mikael Sitruk wrote: Hi I would like to know when the next release will be released? The 2.5.1 is 8 months old already Mikael.S -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
RE: FormulaEvaluator Partial Implementation
But what happens when one assert fails - wouldnt the AssertionError cause the cells that follow to never be tested. (BTW, I'm a JUnit novice, so I may be wrong - in which case we can even continue this discussion off the list to avoid some embarassment to me ;) No, you are correct, but my point is when you are doing regression tests, it doesn't matter. The idea is that our regression tests pass 100% for all code in CVS, so if one test fails, you fix that, and then if another fails, you fix that... Obviously, if you are doing test-first, it doesnt work very well, but in that case, you'll be writing different tests in any case. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Formula Eval docs
I have checked in the documentation for Formula Eval, both user guide, and contributor/development guide. They should be on the site when its next rebuild.. Glen, can you please do the honours? Its slightly backward to check in docs, before code, but the code is coming along nicely, and I thought the docs would help code review etc. Amol, once the are on the site, pls check them for correctness. Also, if you make further changes/enhancements to the docs, could you pls send them in as diffs against the xdocs... its a simple format. Regards - Avik -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: org.apache.poi.util.StringUtil
On Fri, 2005-05-13 at 16:35 +0100, Nick Burch wrote: Hi All It has been suggested (in Bugzilla) that my PowerPoint code's util.TextMunger class is largely a duplicate of util.StringUtil. Since i did the suggesting, I suppose it behoves me to reply :). But let me say that I haven't looked very closely at what you require, it just looked similar. However, I'm really struggling to figure out exactly what that class does. Comments like write compressed unicode don't really explain much... Could someone perhaps tell me if there are any methods to do the following? * Take little endian unicode bytes, and return a string public static String getFromUnicodeLE( final byte[] string, final int offset, final int len) The javadoc is completely off! Also, I am not sure if the method that takes only the byte array is correct... I think we mostly use the above method. * Take a string, and return little endian unicode bytes public static void putUnicodeLE( final String input, final byte[] output, final int offset) the output is not returned, but put into the byte array. * Take a string, and return the closest approximation in US-ASCII bytes ?? What's closest? taking only the low bytes? I dont think there's anything that does that (there were, but they were bugfixed out :) * Take a string, try to convert it US-ASCII bytes, and either return the bytes or indicate (exception, null return etc) that it couldn't be done? public static boolean isUnicodeString(final String value) does the checking, and returns true of false. public static void putCompressedUnicode( final String input, final byte[] output, final int offset) converts to a US-ASCII byte array, or throws an java.lang.InternalError I'll happily do a patch the javadocs for the methods I end up using, once I know what they do! Thanks! the term Compressed/Uncompressed unicode is an unfortunate Excel'ism that's got into our code. Hope that helps. I'm pretty sure the above is correct, but... Shout if you need anything else. Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
RE: Writing unit tests for the powerpoint code
On Thu, 2005-05-12 at 09:05 -0400, Michael Zalewski wrote: Those are good tests. But think smaller. I was composing a mail with the same sentiments, but Michael says it better! Its difficult (impossible?) to do a full functional test automated. However, testing smaller pieces is well worth the effort. In HSSF, I do the 'opening in excel' part manually, but that's a very small part of the HSSF testsuite, and they are usually important only while you are initially developing the funtionality. In the long term, to prevent regressions, smaller unit tests are much more valuable. If the file doesnt open properly, there is usually an underlying cause that can be tested independently. When you have a regression, smaller tests will obviously provide better diagnostics. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
RE: FormulaEvaluator Partial Implementation
On Thu, 2005-05-12 at 08:54 -0400, Amol Deshmukh wrote: TWIC: I've started writing automated tests and I can see how they are immensely helpful :) See, told you so! ha ha..! :) snip I have written the user api docs and contributors guide which in itself was a GoodThing, since that made me revisit the user api and change it to make it (slightly) more usable. Great! have you written them as xdocs? If you want, post them to bugzilla, and I'm happy to convert them to xdocs. You can then maintain them in that format later. So once I'm done with my TODO list I will submit a patch along with the user and dev docs. Will probably take me another weekend though, so expect (if u care that is :) the next patch around Monday. I'm sure many people do. Hopefully with a couple of more rounds of testing, IMHO, it should be in good shape to be worthy of getting into scratchpad (?) I certainly think so. Might be useful to put your wip in bugzilla, if it isnt too much of a pain, I can pitch in if I have some time. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: FormulaEvaluator Partial Implementation
Some comments inline.
On Thu, 2005-05-12 at 12:30 -0700, Amol Deshmukh wrote:
--- Additional Comments From [EMAIL PROTECTED]
2005-05-12
20:38 ---
Another thought, on the tests... Why do you need
separate
test methods/classes
for each eval if you are directly reading it from
the excel
snip/
That way,
one method (with asserts in a loop) will test all
functions/operators.
...because otherwise I wouldnt know which test failed
if even one test failed :)
No, you would... you'll get the formula from excel, and each formula
would be a separate assert, and in the assert comment, you put the
formula. so:
while (get all cells) {
...
assertEquals(c.getCellFormula(), expectedValueCell, actualValue)
}
Also this way we get more control over which tests we
want to carry out simply by specifying the required
classes in a testsuite like AllTests.java.
Well, if you are doing test first development that helps, but really,
for regression testing, doesnt matter much, so long as you can see what
is failing.
And while implementing other functions, if someone wants to do
test-first, its better to write a lower level test without reading from
an excel file, but doing everything in POI.
Effortwise it is not a big deal since I generated all
the classes using code generation (you didnt expect me
to /write/ all the test classes did you? :)
No i didnt :) but I am thinking less code to maintain! A year later,
a new contributor will forget about generation, and copy paste...
If there are suggestions to improve after you see the
test framework and the test cases, I'll be glad to
make
necessary changes...
Thanks and Regards,
~ amol
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List:http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List:http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: FormulaEvaluator Partial Implementation
On Tue, 2005-05-10 at 20:38 -0700, [EMAIL PROTECTED] wrote: -1 on committing any patches without unit tests anymore. It destabilizes code too much. Even to scratchpad because then the code never moves out of scratchpad. We learned this lesson already. It doesn't matter how good or bad or how much we want it...no unit tests + doco...it stays as patches in bugzilla. While I agree with your general sentiments, I think that not getting things into CVS detracts from getting more contributors, particularly for this formula stuff, where unit tests are going to be easy to write, but we need lots and lots of it, and one person is certainly not going to finish all cases. That's why I think we have scratchpad, so that people can start looking at incomplete stuff. If required, we should have criteria for removing stuff from scratchpad, if they remain unmaintained for too long. Also we should NEVER release jars of stuff from scratchpad, only CVS. If scratchpad and main have the same criteria, then why have scp? would you rather that HWPF not have been added to CVS, as opposed to being where it is now? (sorry, too many rhetorical q's :) Amol, irrespective of this disucussion, you should start writing some tests for your code :) Regards - Avik [EMAIL PROTECTED] wrote: [Moving to the list, since bugzilla is bad for conversation] Comments inline. As a result, you may have to apply the patch to /src/scratchpad/src instead of the root folder That's ok. For the initial bit, can you just zip/tgz the directory. Provide patches after the initial additions have been comitted. I am waiting to commit till the dummy method javadocs are removed (maybe an awk script might be quick?) 1. Ptg and Eval: Delegating or extending? snip But I guess extending from Ptg could also work... Just to clarify, by extend, i meant have a separate class that interits from the Ptgs.. ie, `class AddEval extends AddPtg` .. but as I said, just a suggestion, you'll know best. 2. Functions in one class or one class per function? snip Yeah, sure. 3. Testing... Unit testing would be a big effort. Almost as big as writing individual functions, a distributed effort would be great! Certainly, probably bigger. So once again, this is a call for everybody interested in this functionality to write unit tests for it. Its easy! 4. My eclipse... snip Please try and remove the extraneous comments, i dont want to put that in CVS. I'll commit it as soon as that's done, I'm happy with everything else. 5. Under contruction: The work on core eval classes is not yet complete. I think there is need for a BlankEval class to handle empty cells - which are currently being handled as StringEval(). Yeah, sure, thats understood, and no issues. But your 'empty cell' comment made me think, the function implementations should probably follow Excel semantics.. for eg, in the average function, empty cells do not add to the number of elements (ie, the denominator). Also, these semantics might be different for different versions of excel. How do we handle that. A final thoguht on error handling. Your error handling is modelled after OO.o. In excel however, errors are a more limited set.. #REF, #VALUE, etc. Do we need to think about how to handle/map those. Maybe it doesnt matter? Once again, to everybody out there, this is a big and important piece of work that can certainly do with more evaluation/comments/unit tests. Thanks! Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: FormulaEvaluator Partial Implementation
Quoting Amol Deshmukh [EMAIL PROTECTED]: But... * Unit tests: do you mean *all* unit tests, some unit tests that test basic flows or unit tests with complete code coverage? not all, some tests, testing the basic functionality. Also I guess that means that I'm on my own till the code moves into CVS? Again, fine by me, but if there are any ideas to enable distributed development w/o putting it into CVS, they are welcome. * Docos... I assume javadocs. Correct me if you meant otherwise... javadocs for the primary methods. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: FormulaEvaluator Partial Implementation
Quoting [EMAIL PROTECTED]: Quoting Amol Deshmukh [EMAIL PROTECTED]: * Docos... I assume javadocs. Correct me if you meant otherwise... javadocs for the primary methods. And a basic how-to .. how to use the api. Even if only a few lines. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Formula Evaluation
tho I'm personally happy to see POI just as a file format reader... well, as you'd have noticed, its often requested. So yeah, I'd be interested in seeing this. My concerns would be first that this have adequate documentation and unit tests. I think that is paramount in functionality of this nature (and shouldnt be difficult to test, either) Also, I wonder what kind of API would be appropriate for this functionality. One, since it is impossible to implement ALL excel functions immediately, the code should degrade gracefully, while at the same time provide enuf feedback to the called. Also, I would therefore like that adding new implementations of functions should be easy. I would also prefer if the math implementation could be pluggable.. if someone were to want to integrate with pre-built math libraries in the future. But in any case, lets see what you have. I am happy to have this added so long as there are sufficient tests and docs. Quoting Amol Deshmukh [EMAIL PROTECTED]: I wanted to know if any work has been done for providing formula evaluation functionality in POI. (I realise that POI is basically a file-format translator, but such a utility could be useful when reading from files.) If there has been no work done so far wrt formula evaluation and it is deemed a useful feature, I would like to contribute my solution for this. I have a partially implemented solution (based on FormulaParser and *Ptg classes) that works for most common formulas with limited function support (although thats only because I havent had the time to implement all std excel functions, not a limitation of the approach per se). What is the best way to submit this code for evaluation (no pun intended :)? Regards, ~ amol Notes: Brief description of approach: 1. added function: abstract Ptg evaluate(Ptg[] operands) to OperationPtg and implemented it in every concrete operation class. 2. Used FormulaParser to get RPN tokens from FormulaString and using simple stack operations called evaluate on an operation token. 3. Functions are implemented as individual classes each having a Ptg evaluate(Ptg[] operands) method. 4. All above operations are driven by FormulaEvaluator which also performs evaluation of AreaPtg and ReferencePtg before invoking operations or functions. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: DO NOT REPLY [Bug 34761] - No API call available to set the top row for a sheet
Hey, cool, thanks Amol. I'll put this in, in a day or two. On Thu, 2005-05-05 at 16:31 +0200, [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34761. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34761 --- Additional Comments From [EMAIL PROTECTED] 2005-05-05 16:31 --- Created an attachment (id=14942) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14942action=view) Patch for 34761 The attachment is a patch that adds methods to expose the WindowTwo.toprow element of a sheet to the user thru the usermodel api call xxx.usermodel.HSSFSheet.getTopRow() and setTopRow(). To enable this, getTopRow and setTopRow were also added to xxx.model.Sheet class. An elementary test case is provided and the results of the api call were verified manually. However more automated tests would be required to really test this patch well! -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
bug 31906?
Any thoughts on http://issues.apache.org/bugzilla/show_bug.cgi?id=31906 (Pull method for continue records) Looks good to me, but I'm not sure i've thought of all consequences. Can someone profile it for memory/speed? Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Detect unicode
We currently have two methods to detect unicode characters. Which is
better? Primarily on performance. I want to consolidated. There might be
other such code scattered!
public static boolean hasMultibyte(String value){
if( value == null )return false;
for(int i = 0 ; i value.length() ; i++ ){
char c = value.charAt(i);
if(c 0xFF )return true;
}
return false;
}
public static boolean isUnicodeFormat(final String format) {
try {
return !format.equals( new String(format.getBytes (ISO-8859-1),
ISO-8859-1));
} catch (UnsupportedEncodingException e) {
return true;
}
}
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List:http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: o.a.pi.poifs.filesystem.TestEmptyDocument fails on HEAD
Instead someone should fix the bugs. Well, yes, that is ideal.. but if that doesnt happen, then you are left with the possibility that regressions get into the codebase when people cant answer Do all tests that are SUPPOSED TO PASS, continue to pass after my fix? And we've seen that happen to POI in the last year that we've had breakage in HEAD.. it really affects development velocity when you cant answer the above question confidently! I've tried to find a middle path in the current build.xml that i just checked in . Regards - Avik On Wed, 2005-04-20 at 22:36 +0200, Rainer Klute wrote: Am Mittwoch, den 20.04.2005, 23:17 +0530 schrieb [EMAIL PROTECTED]: Ok, thanks. That makes sense. Do you have a bug he for this? I'll update the code with that. In any event i think we should not run known failing tests by default, it can hide other breakage. I've been thinking of a way to keep them separately in cvs; for now i'll disable them.Quoting Rainer Klute [EMAIL PROTECTED]: Its bug 11744. However, I think we should never leave out any testcases! Omitting failing testcases contradicts the whole sense of testing. Instead someone should fix the bugs. Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 Inhibit software patents: http://www.nosoftwarepatents.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Branches
Branches are merged, everything on HEAD. On Fri, 2005-04-22 at 09:48 -0500, Laubach Shawn Contr 327 CSSG/GFSL wrote: I've got a little change to headers and footers in HSSF and I've lost track of the different branches I need to make the changes in. Could someone get me that information? Shawn -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
State of HEAD (again)
running ant test on CVS Head version of POI now shows all tests PASSED. Please ensure that any fix does not introduce a regression in the future. Therefore, as you might have seen from CVS/Bugzilla mails, I have started to check in some patches. I'll review more bugs in the coming weeks. After that, I really want to get on with the Powerpoint stuff. Regards - Avik PS: One open issue is with test15556, which opens the file attached to bug 15556. While the old issue is still fixed, there is currently an error due to OBJ record. I've disabled the test for now. Since this is not a regression, and I have added a bug to record this issue (34575) I consider this an acceptable course of action. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Getting a PIC
Have you seen the drawing code in HSSF? Maybe its similar/same? On Wed, 2005-04-20 at 03:02 +, Robert Paris wrote: I'm working on the part of Word that stores pictures and I've run into a problem. I'm able to grab the PIC structure (from the SPRM sprmCPicLocation). However, once I've gone through that, I have a chunk of data that I believe is an Office Shape Format. Unfortunately, I am unable to find the definition for this structure anywhere. Does anyone know where it is? The documentation for Word 97 says that all pictures inserted with Word 97 are in the new Office shape format (documented elsewhere). Without that documentation, I have no way to read this data! Anyone? - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
RE: State of the Head
Just to let you know, I've finally managed to fix this... properly. CVS is down, so i'll probably check this in tomorrow. Added some extra tests as well. Regards - Avik On Tue, 2005-04-19 at 23:36 +0530, [EMAIL PROTECTED] wrote: I also cant reconcile this behaviour with the fact that the code HSSFWorkbook wb = new HSSFWorkbook(); HSSFSheets = wb.createSheet(Sheet1); in earlier versions of POI produced a book with only ONE sheet called 'Sheet1'. I think even if we are checking for duplicate names, the above code should work as before! Quoting [EMAIL PROTECTED]: hey, thanks. I saw that , but what I cant reconcile the fact that everything worked fine before the check for duplicate names was there, (ie, you could create a new wb, and then create a sheet called 'Sheet1' in it) while the bug report claims that creating a sheet with a duplicate name sometimes crashes excel. I could just redo all tests so that we create sheets with other names, but I dont know if that is a good idea! Regards - Avik Quoting Amol Deshmukh [EMAIL PROTECTED]: Avik, Following is the stack trace of calls when creating a new HSSFWorkbook(): at org.apache.poi.hssf.model.Workbook.createBoundSheet(Workbook.java:1664) at org.apache.poi.hssf.model.Workbook.createWorkbook(Workbook.java:300) at org.apache.poi.hssf.usermodel.HSSFWorkbook.init(HSSFWorkbook.java:120) at org.apache.poi.hssf.usermodel.TestFormulas.binomialOperator(TestFormulas.jav a:456) at org.apache.poi.hssf.usermodel.TestFormulas.testPowerIntegers(TestFormulas.ja va:115) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at org.apache.poi.hssf.usermodel.TestFormulas.main(TestFormulas.java:1090) If you see the top of the stack trace above, file org.apache.poi.hssf.model.Workbook.java creates sheet by name 'Sheet1' by default. This may explain why a subsequent wb.createSheet(Sheet1) would fail. HTH, ~ amol -Original Message- From: Avik Sengupta [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 9:53 AM To: poi-dev@jakarta.apache.org Subject: Re: State of the Head The following commit: http://cvs.apache.org/viewcvs.cgi/jakarta-poi/src/java/org/apa che/poi/hssf/usermodel/HSSFWorkbook.java?r1=1.36r2=1.37 for bug 30951 seemed to have been done without running all tests, probably coz there were other tests failing at that time :( .. which is why I have been apprehensive of accepting any patch till previous errors have been removed. This commit throws an exception if, while creating a sheet, a sheet exits in the workbook with the same name. Which is fine, however, there seems to be some issue with naming even the first sheet you create as 'Sheet1', where the following code fails. HSSFWorkbook wb = new HSSFWorkbook(); HSSFSheets = wb.createSheet(Sheet1); ie, POI seems to think that a sheet named 'Sheet1' exists even in a new workbook! Still investigating. Regards - Avik On Tue, 2005-04-12 at 17:07 +0530, Avik Sengupta wrote: HEAD on our CVS is currently broken (tests dont pass). Thats the reason why I haven't been merging patches/bugfixes for a while... including the powerpoint work by Nick (who just added some write support today.. cool!)..I plan to play around with Nick's powerpoint code, but feel blocked by the fact that head is not all OK.. So this mail is to say that any help on this highly appreciated :).I'm planning to put some work on this in the next couple of weeks. Regards - Avik -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
o.a.pi.poifs.filesystem.TestEmptyDocument fails on HEAD
with the following error. Ideas?? Can someone confirm this with latest CVS HEAD? (ant -Dtestcase=org.apache.poi.poifs.filesystem.TestEmptyDocument single-test) [junit] Testcase: testSingleEmptyDocument took 0.113 sec [junit] Caused an ERROR [junit] Cannot remove block[ 0 ]; out of range [junit] java.io.IOException: Cannot remove block[ 0 ]; out of range [junit] at org.apache.poi.poifs.storage.BlockListImpl.remove(BlockListImpl.java:103) [junit] at org.apache.poi.poifs.storage.BlockAllocationTableReader.fetchBlocks(BlockAllocationTableReader.java:190) [junit] at org.apache.poi.poifs.storage.BlockListImpl.fetchBlocks(BlockListImpl.java:128) [junit] at org.apache.poi.poifs.filesystem.POIFSFileSystem.processProperties(POIFSFileSystem.java:403) [junit] at org.apache.poi.poifs.filesystem.POIFSFileSystem.init(POIFSFileSystem.java:102) [junit] at org.apache.poi.poifs.filesystem.TestEmptyDocument.testSingleEmptyDocument(TestEmptyDocument.java:94) -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: o.a.pi.poifs.filesystem.TestEmptyDocument fails on HEAD
Ok, thanks. That makes sense. Do you have a bug he for this? I'll update the code with that. In any event i think we should not run known failing tests by default, it can hide other breakage. I've been thinking of a way to keep them separately in cvs; for now i'll disable them.Quoting Rainer Klute [EMAIL PROTECTED]: Avik, this testcase never ran successfully. I added it once because someone sent an error report and complained that reading an empty document does not work. The testcase verifies that by creating an empty document and trying to read it back in. I fiddeled around with POIFS a little bit but due to lack of time and lack of knowledge about POIFS I couldn't find a solution. However, I believe that this is an error and someone who knows POIFS better than me should try to solve that issue. Am Mittwoch, den 20.04.2005, 18:02 +0530 schrieb Avik Sengupta: with the following error. Ideas?? Can someone confirm this with latest CVS HEAD? (ant -Dtestcase=org.apache.poi.poifs.filesystem.TestEmptyDocument single-test) [junit] Testcase: testSingleEmptyDocument took 0.113 sec [junit] Caused an ERROR [junit] Cannot remove block[ 0 ]; out of range [junit] java.io.IOException: Cannot remove block[ 0 ]; out of range [junit] at org.apache.poi.poifs.storage.BlockListImpl.remove(BlockListImpl.java:103) [junit] at org.apache.poi.poifs.storage.BlockAllocationTableReader.fetchBlocks(BlockAllocationTableReader.java:190) [junit] at org.apache.poi.poifs.storage.BlockListImpl.fetchBlocks(BlockListImpl.java:128) [junit] at org.apache.poi.poifs.filesystem.POIFSFileSystem.processProperties(POIFSFileSystem.java:403) [junit] at org.apache.poi.poifs.filesystem.POIFSFileSystem.init(POIFSFileSystem.java:102) [junit] at org.apache.poi.poifs.filesystem.TestEmptyDocument.testSingleEmptyDocument(TestEmptyDocument.java:94) Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 Inhibit software patents: http://www.nosoftwarepatents.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: o.a.pi.poifs.filesystem.TestEmptyDocument fails on HEAD
Ok, thanks. That makes sense. Do you have a bug he for this? I'll update the code with that. In any event i think we should not run known failing tests by default, it can hide other breakage. I've been thinking of a way to keep them separately in cvs; for now i'll disable them.Quoting Rainer Klute [EMAIL PROTECTED]: Avik, this testcase never ran successfully. I added it once because someone sent an error report and complained that reading an empty document does not work. The testcase verifies that by creating an empty document and trying to read it back in. I fiddeled around with POIFS a little bit but due to lack of time and lack of knowledge about POIFS I couldn't find a solution. However, I believe that this is an error and someone who knows POIFS better than me should try to solve that issue. Am Mittwoch, den 20.04.2005, 18:02 +0530 schrieb Avik Sengupta: with the following error. Ideas?? Can someone confirm this with latest CVS HEAD? (ant -Dtestcase=org.apache.poi.poifs.filesystem.TestEmptyDocument single-test) [junit] Testcase: testSingleEmptyDocument took 0.113 sec [junit] Caused an ERROR [junit] Cannot remove block[ 0 ]; out of range [junit] java.io.IOException: Cannot remove block[ 0 ]; out of range [junit] at org.apache.poi.poifs.storage.BlockListImpl.remove(BlockListImpl.java:103) [junit] at org.apache.poi.poifs.storage.BlockAllocationTableReader.fetchBlocks(BlockAllocationTableReader.java:190) [junit] at org.apache.poi.poifs.storage.BlockListImpl.fetchBlocks(BlockListImpl.java:128) [junit] at org.apache.poi.poifs.filesystem.POIFSFileSystem.processProperties(POIFSFileSystem.java:403) [junit] at org.apache.poi.poifs.filesystem.POIFSFileSystem.init(POIFSFileSystem.java:102) [junit] at org.apache.poi.poifs.filesystem.TestEmptyDocument.testSingleEmptyDocument(TestEmptyDocument.java:94) Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 Inhibit software patents: http://www.nosoftwarepatents.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: o.a.pi.poifs.filesystem.TestEmptyDocument fails on HEAD
Ok, thanks. That makes sense. Do you have a bug he for this? I'll update the code with that. In any event i think we should not run known failing tests by default, it can hide other breakage. I've been thinking of a way to keep them separately in cvs; for now i'll disable them.Quoting Rainer Klute [EMAIL PROTECTED]: Avik, this testcase never ran successfully. I added it once because someone sent an error report and complained that reading an empty document does not work. The testcase verifies that by creating an empty document and trying to read it back in. I fiddeled around with POIFS a little bit but due to lack of time and lack of knowledge about POIFS I couldn't find a solution. However, I believe that this is an error and someone who knows POIFS better than me should try to solve that issue. Am Mittwoch, den 20.04.2005, 18:02 +0530 schrieb Avik Sengupta: with the following error. Ideas?? Can someone confirm this with latest CVS HEAD? (ant -Dtestcase=org.apache.poi.poifs.filesystem.TestEmptyDocument single-test) [junit] Testcase: testSingleEmptyDocument took 0.113 sec [junit] Caused an ERROR [junit] Cannot remove block[ 0 ]; out of range [junit] java.io.IOException: Cannot remove block[ 0 ]; out of range [junit] at org.apache.poi.poifs.storage.BlockListImpl.remove(BlockListImpl.java:103) [junit] at org.apache.poi.poifs.storage.BlockAllocationTableReader.fetchBlocks(BlockAllocationTableReader.java:190) [junit] at org.apache.poi.poifs.storage.BlockListImpl.fetchBlocks(BlockListImpl.java:128) [junit] at org.apache.poi.poifs.filesystem.POIFSFileSystem.processProperties(POIFSFileSystem.java:403) [junit] at org.apache.poi.poifs.filesystem.POIFSFileSystem.init(POIFSFileSystem.java:102) [junit] at org.apache.poi.poifs.filesystem.TestEmptyDocument.testSingleEmptyDocument(TestEmptyDocument.java:94) Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 Inhibit software patents: http://www.nosoftwarepatents.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: State of the Head
One of the tests that fail on HEAD currently is test15556 in o.a.p.hssf.usermodel.TestBugs This test just opens a file that is attached to bug 15556 in bugzilla. However, the error is not the same as in that bug (an SSTDeserialize issue that has since been fixed)... currently it fails in creating an ObjRecord (the file has many diagrams) [junit] Caused by: java.lang.ArrayIndexOutOfBoundsException: 33 [junit] at org.apache.poi.util.LittleEndian.getNumber(LittleEndian.java:491) [junit] at org.apache.poi.util.LittleEndian.getShort(LittleEndian.java:52) [junit] at org.apache.poi.hssf.record.ObjRecord.fillFields(ObjRecord.java:98) [junit] at org.apache.poi.hssf.record.Record.fillFields(Record.java:90) [junit] at org.apache.poi.hssf.record.Record.init(Record.java:55) [junit] at org.apache.poi.hssf.record.ObjRecord.init(ObjRecord.java:61) Glen, anything you can think of? Regards - Avik On Tue, 2005-04-12 at 17:07 +0530, Avik Sengupta wrote: HEAD on our CVS is currently broken (tests dont pass). Thats the reason why I haven't been merging patches/bugfixes for a while... including the powerpoint work by Nick (who just added some write support today.. cool!)..I plan to play around with Nick's powerpoint code, but feel blocked by the fact that head is not all OK.. So this mail is to say that any help on this highly appreciated :).I'm planning to put some work on this in the next couple of weeks. Regards - Avik -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: State of the Head
The following commit: http://cvs.apache.org/viewcvs.cgi/jakarta-poi/src/java/org/apache/poi/hssf/usermodel/HSSFWorkbook.java?r1=1.36r2=1.37 for bug 30951 seemed to have been done without running all tests, probably coz there were other tests failing at that time :( .. which is why I have been apprehensive of accepting any patch till previous errors have been removed. This commit throws an exception if, while creating a sheet, a sheet exits in the workbook with the same name. Which is fine, however, there seems to be some issue with naming even the first sheet you create as 'Sheet1', where the following code fails. HSSFWorkbook wb = new HSSFWorkbook(); HSSFSheets = wb.createSheet(Sheet1); ie, POI seems to think that a sheet named 'Sheet1' exists even in a new workbook! Still investigating. Regards - Avik On Tue, 2005-04-12 at 17:07 +0530, Avik Sengupta wrote: HEAD on our CVS is currently broken (tests dont pass). Thats the reason why I haven't been merging patches/bugfixes for a while... including the powerpoint work by Nick (who just added some write support today.. cool!)..I plan to play around with Nick's powerpoint code, but feel blocked by the fact that head is not all OK.. So this mail is to say that any help on this highly appreciated :).I'm planning to put some work on this in the next couple of weeks. Regards - Avik -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
RE: State of the Head
hey, thanks. I saw that , but what I cant reconcile the fact that everything worked fine before the check for duplicate names was there, (ie, you could create a new wb, and then create a sheet called 'Sheet1' in it) while the bug report claims that creating a sheet with a duplicate name sometimes crashes excel. I could just redo all tests so that we create sheets with other names, but I dont know if that is a good idea! Regards - Avik Quoting Amol Deshmukh [EMAIL PROTECTED]: Avik, Following is the stack trace of calls when creating a new HSSFWorkbook(): at org.apache.poi.hssf.model.Workbook.createBoundSheet(Workbook.java:1664) at org.apache.poi.hssf.model.Workbook.createWorkbook(Workbook.java:300) at org.apache.poi.hssf.usermodel.HSSFWorkbook.init(HSSFWorkbook.java:120) at org.apache.poi.hssf.usermodel.TestFormulas.binomialOperator(TestFormulas.jav a:456) at org.apache.poi.hssf.usermodel.TestFormulas.testPowerIntegers(TestFormulas.ja va:115) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at org.apache.poi.hssf.usermodel.TestFormulas.main(TestFormulas.java:1090) If you see the top of the stack trace above, file org.apache.poi.hssf.model.Workbook.java creates sheet by name 'Sheet1' by default. This may explain why a subsequent wb.createSheet(Sheet1) would fail. HTH, ~ amol -Original Message- From: Avik Sengupta [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 9:53 AM To: poi-dev@jakarta.apache.org Subject: Re: State of the Head The following commit: http://cvs.apache.org/viewcvs.cgi/jakarta-poi/src/java/org/apa che/poi/hssf/usermodel/HSSFWorkbook.java?r1=1.36r2=1.37 for bug 30951 seemed to have been done without running all tests, probably coz there were other tests failing at that time :( .. which is why I have been apprehensive of accepting any patch till previous errors have been removed. This commit throws an exception if, while creating a sheet, a sheet exits in the workbook with the same name. Which is fine, however, there seems to be some issue with naming even the first sheet you create as 'Sheet1', where the following code fails. HSSFWorkbook wb = new HSSFWorkbook(); HSSFSheets = wb.createSheet(Sheet1); ie, POI seems to think that a sheet named 'Sheet1' exists even in a new workbook! Still investigating. Regards - Avik On Tue, 2005-04-12 at 17:07 +0530, Avik Sengupta wrote: HEAD on our CVS is currently broken (tests dont pass). Thats the reason why I haven't been merging patches/bugfixes for a while... including the powerpoint work by Nick (who just added some write support today.. cool!)..I plan to play around with Nick's powerpoint code, but feel blocked by the fact that head is not all OK.. So this mail is to say that any help on this highly appreciated :).I'm planning to put some work on this in the next couple of weeks. Regards - Avik -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
RE: State of the Head
I also cant reconcile this behaviour with the fact that the code HSSFWorkbook wb = new HSSFWorkbook(); HSSFSheets = wb.createSheet(Sheet1); in earlier versions of POI produced a book with only ONE sheet called 'Sheet1'. I think even if we are checking for duplicate names, the above code should work as before! Quoting [EMAIL PROTECTED]: hey, thanks. I saw that , but what I cant reconcile the fact that everything worked fine before the check for duplicate names was there, (ie, you could create a new wb, and then create a sheet called 'Sheet1' in it) while the bug report claims that creating a sheet with a duplicate name sometimes crashes excel. I could just redo all tests so that we create sheets with other names, but I dont know if that is a good idea! Regards - Avik Quoting Amol Deshmukh [EMAIL PROTECTED]: Avik, Following is the stack trace of calls when creating a new HSSFWorkbook(): at org.apache.poi.hssf.model.Workbook.createBoundSheet(Workbook.java:1664) at org.apache.poi.hssf.model.Workbook.createWorkbook(Workbook.java:300) at org.apache.poi.hssf.usermodel.HSSFWorkbook.init(HSSFWorkbook.java:120) at org.apache.poi.hssf.usermodel.TestFormulas.binomialOperator(TestFormulas.jav a:456) at org.apache.poi.hssf.usermodel.TestFormulas.testPowerIntegers(TestFormulas.ja va:115) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at org.apache.poi.hssf.usermodel.TestFormulas.main(TestFormulas.java:1090) If you see the top of the stack trace above, file org.apache.poi.hssf.model.Workbook.java creates sheet by name 'Sheet1' by default. This may explain why a subsequent wb.createSheet(Sheet1) would fail. HTH, ~ amol -Original Message- From: Avik Sengupta [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 9:53 AM To: poi-dev@jakarta.apache.org Subject: Re: State of the Head The following commit: http://cvs.apache.org/viewcvs.cgi/jakarta-poi/src/java/org/apa che/poi/hssf/usermodel/HSSFWorkbook.java?r1=1.36r2=1.37 for bug 30951 seemed to have been done without running all tests, probably coz there were other tests failing at that time :( .. which is why I have been apprehensive of accepting any patch till previous errors have been removed. This commit throws an exception if, while creating a sheet, a sheet exits in the workbook with the same name. Which is fine, however, there seems to be some issue with naming even the first sheet you create as 'Sheet1', where the following code fails. HSSFWorkbook wb = new HSSFWorkbook(); HSSFSheets = wb.createSheet(Sheet1); ie, POI seems to think that a sheet named 'Sheet1' exists even in a new workbook! Still investigating. Regards - Avik On Tue, 2005-04-12 at 17:07 +0530, Avik Sengupta wrote: HEAD on our CVS is currently broken (tests dont pass). Thats the reason why I haven't been merging patches/bugfixes for a while... including the powerpoint work by Nick (who just added some write support today.. cool!)..I plan to play around with Nick's powerpoint code, but feel blocked by the fact that head is not all OK.. So this mail is to say that any help on this highly appreciated :).I'm planning to put some work on this in the next couple of weeks. Regards - Avik -- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: There it goes again...
I've tried to unsubscribe this address, dont know if it succeeded. If not, i'll ask infrastructure. Quoting Kais Dukes [EMAIL PROTECTED]: Does this mean we have to put up with this autoresponder for another 10 days :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 18 March 2005 17:03 To: POI Developers List Subject: Opal Andrews/STLS/FRS is out of the office. I will be out of the office starting 03/18/2005 and will not return until 03/28/2005. If you need immediate assistance, please contact Ted Governal at 44-8664. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Adding Hyperlink support to POI-HSSF...? (3)
Hey, this looks cool... But should HyperlinkRecord be a CellValueRecordInterface? When you read in the file, what record do you get at the cell.. an SSTRecord? Maybe the HLINK is only indirectly linked to the cell? You'll probably just have to pore over BiffViewer output to understand the semantics of this.. that's the only way, as Andy suggested earlier. As far as implementing serialize, check our the other records... dont look at SST, which is probably most complicated.. look at NumberRecord for simple, Formula record for intermediate .. Getsize... well, you will just have to count :) .. ie, add up the sizes of the individual elements... and if you mess up the count, subsequent records will not be read.. dont you just love the format :) !! Again, check formularecord for a useful example. HTH - Avik Quoting Mark Hissink Muller [EMAIL PROTECTED]: I'm not sure the attachment worked; find the draft here: http://www.hissinkmuller.nl/poi/HyperlinkRecord.java Thanks, - Mark On Sun, 20 Feb 2005 21:14:34 +0100, Mark Hissink Muller [EMAIL PROTECTED] wrote: POI-dev members, Thanks again for your support on my attempt to add an Excel Hyperlinked cell to HSSF. Things are going fairly well. With help of Avik's document, I've been able to read the label and the actual URL into a new HyperlinkRecord, which works fine. When testing the HyperlinkRecord-class fully integrated, and trying to read the hyperlink from the modified HSSFCell, I have some problems. Instead of finding my new HSSFCell.CELL_TYPE_HYPERLINK (with record HyperlinkRecord), I find a LabelSSTRecord, which, as I understand it, is a basic kind of text-record. Zooming in on: public static Workbook createWorkbook(List recs) I see that 161 Record(s) from the InputStream [1] are input but that after 81 records the processing breaks because an EOFRecord is found. Commenting the break, I learn that my HyperlinkRecord is number 101 in the List. I am puzzled; why is the EOF found before all the records are property processed? Another thing which I could use a suggestion is the implementation of: public int serialize( int offset, byte[] data ) // and public int getRecordSize() For your convenience, I've added my current (draft) version of the HyperlinkRecord as an attachment to this mail. Any thoughts are highly appreciated. Cheers, - Mark [1] - I have a simple example where I try to read an Hyperlink+Label from cell A1. Apart from this, the workbook is empty (new Excel-file) - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: cvs commit: jakarta-poi/src/contrib/poi-ruby - New directory
On Sat, 2005-02-19 at 01:12 -0500, Andrew Oliver wrote: hummm...probably should have gone under src/ruby Make sense... I'll move it... only a few files yet..sorry for the CVS spam. I hope there are many more. However, this does prove something. you're sick avik...sick ;-) :) - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Adding Hyperlink support to POI-HSSF...? (2)
Does this help? HLINK Hyperlink BIFF2 BIFF3 BIFF4S BIFF4W BIFF5 BIFF7 BIFF8 BIFF8X 01B8H 01B8H In Excel, every cell may contain a hyperlink. The HLINK record refers to one cell address or a cell range where all cells contain the same hyperlink. Every hyperlink can contain a text mark and a description that is shown in the sheet instead of the real link. Text marks are appended behind a link, separated by the hash sign (#). Examples for text marks: www.example.org#table1 or C: \example.xls#Sheet1!A1. Inside of this record strings are stored in several formats. Sometimes occurs the character count, otherwise the character array size (in 16 bit character arrays the character count is half of the array size). Furthermore some strings are zero-terminated, others not. They are stored either as 16 bit character arrays or as 8 bit character arrays, independent of the characters. Common Record Contents Each HLINK record starts with the same data items and continues with special data related to the current type of hyperlink. It starts with a cell range. Each cell of this range will contain the same hyperlink. Record HLINK, BIFF8: Offset Size Contents 0 2 Index to first row 2 2 Index to last row 4 2 Index to first column 6 2 Index to last column 8 16 GUID of StdLink: D0H C9H EAH 79H F9H BAH CEH 11H 8CH 82H 00H AAH 00H 4BH A9H 0BH (79EAC9D0-BAF9-11CE-8C82-00AA004BA90B) 24 4 Unknown value: 0002H 28 4 Option flags (see below) [32] 4 (optional, see option flags) Character count of description text, including trailing zero word (dl) [36] 2dl (optional, see option flags) Character array of description text, no Unicode string header, always 16 bit characters, zero-terminated [var.] 4 (optional, see option flags) Character count of target frame, including trailing zero word (fl) [var.] 2fl (optional, see option flags) Character array of target frame, no Unicode string header, always 16 bit characters, zero-terminated Special data (5.36.2 and following) [var.] 4 (optional, see option flags) Character count of the text mark, including trailing zero word (tl) [var.] 2tl (optional, see option flags) Character array of the text mark without # sign, no Unicode string header, always 16 bit characters, zero-terminated The special data parts in the following are described with relative offsets (starting again by zero). The real offset inside of the record data (without header) is either 32 (without description) or 36+2dl (with description). * Option flags The option flags specify the following content of the record. Bit Mask Contents 0 0001H 0 = No link extant 1 = File link or URL 1 0002H 0 = Relative file path 1 = Absolute path or URL 2 and 4 0014H 0 = No description 1 (both bits) = Description 3 0008H 0 = No text mark 1 = Text mark 7 0080H 0 = No target frame 1 = Target frame 8 0100H 0 = File link or URL 1 = UNC path (incl. server name) Hyperlink to a URL (Uniform Resource Locator) These data fields occur for links which are not local files or files in the local network (for instance HTTP and FTP links and e-mail addresses). The lower 9 bits of the option flags field must be 0.x00x.xx112 (x means optional, depending on hyperlink content). The GUID could be used to distinguish a URL from a file link. Offset Size Contents 0 16 GUID of URL Moniker: E0H C9H EAH 79H F9H BAH CEH 11H 8CH 82H 00H AAH 00H 4BH A9H 0BH (79EAC9E0-BAF9-11CE-8C82-00AA004BA90B) 16 4 Size of character array of the URL, including trailing zero word (us). There are us/2-1 characters in the following string. 20 us Character array of the URL, no Unicode string header, always 16 bit characters, zero-terminated Hyperlink to a Local File These data fields are for links to files on local drives. The path of the file can be complete with drive letter (absolute) or relative to the location of the workbook. The lower 9 bits of the option flags field must be 0.x00x.xxx12. The GUID could be used to distinguish a URL from a file link. Offset Size Contents 0 16 GUID of File Moniker: 03H 03H 00H 00H 00H 00H 00H 00H C0H 00H 00H 00H 00H 00H 00H 46H (0303---C000-0046) 16 2 Directory up-level count. Each leading ..\ in the file link is
Re: Adding Hyperlink support to POI-HSSF...? (2)
On Sat, 2005-02-19 at 16:20 +0530, Avik Sengupta wrote: Does this help? Sorry if you saw this with messed up formatting... This is documented in the OpenOffice fileformat documentation, I dont have the link at hand, you can find it on the POI website. - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Ruby bindings for POI
In case you were watching the commit logs, you'd have noticed that I have just checked in an initial attempt at Ruby bindings for POI. This allows the use of the POI from everyone's favourite language :). The wrapping is done by compiling POI with GCJ, and generating the Ruby wrapper with SWIG. The inspiration for this project is PyLucene, so thanks to the OSAF folks. While I think this is the best place for this code, and so I have checked this into the POI jakarta repository, I am open to suggestions stating that this should go into RubyForge etc... Docs are at http://jakarta.apache.org/poi/poi-ruby.html This is still in its initial stages (so you'd need to compile from source..) ... but there's enuf of the feature set to be useful. Further enhancements to follow! Thoughts/feedback/brickbats? Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
[Attn:Jason] Re: JUnit test fails and other problem
Jason, Do you remember what is the current status on http://issues.apache.org/bugzilla/show_bug.cgi?id=22742 I seem to remember there was some problem with this patch in our conversion from the 2.0 branch to head. Any clues? This is apparently causing this tests to fail. Amol, thanks for the report. And please bring on any patches! Quoting Amol Deshmukh [EMAIL PROTECTED]: Hi, (I.) I'm having some problems running the JUnit tests for the POI source code. StackTrace is at the end of this message. Apparently this is something that I have noticed over the last week or so. I was able to get all the tests running prior to that. The exception is thrown from a call at: org.apache.poi.hssf.usermodel.TestBugs.test15556(TestBugs.java:259) I'm running Windows XP. (II.) Also, I wanted to know how to send a PATCH for the JUnit tests. Atleast one class does not seem to close FileIn/OutputStreams at all places (org.apache.poi.hssf.usermodel.TestBugs). I have fixed the 'problem' locally, but I dont know whether this should be submitted as a PATCH since it is change to 'testing' code. Regards, ~ amol Addendum: Stack trace for (I.) from JUnit via ant task test: [junit] java.lang.reflect.InvocationTargetException [junit] at sun.reflect.GeneratedConstructorAccessor41.newInstance(Unknown Source) [junit] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) [junit] at java.lang.reflect.Constructor.newInstance(Unknown Source) [junit] at org.apache.poi.hssf.record.RecordFactory.createRecord(RecordFactory.java:224 ) [junit] at org.apache.poi.hssf.record.RecordFactory.createRecords(RecordFactory.java:16 0) [junit] at org.apache.poi.hssf.usermodel.HSSFWorkbook.init(HSSFWorkbook.java:164) [junit] at org.apache.poi.hssf.usermodel.HSSFWorkbook.init(HSSFWorkbook.java:211) [junit] at org.apache.poi.hssf.usermodel.HSSFWorkbook.init(HSSFWorkbook.java:192) [junit] at org.apache.poi.hssf.usermodel.TestBugs.test15556(TestBugs.java:259) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) [junit] at java.lang.reflect.Method.invoke(Unknown Source) [junit] at junit.framework.TestCase.runTest(TestCase.java:154) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRu nner.java:289) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask .java:1061) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.jav a:676) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitT ask.java:1413) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.jav a:633) [junit] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) [junit] at org.apache.tools.ant.Task.perform(Task.java:364) [junit] at org.apache.tools.ant.Target.execute(Target.java:341) [junit] at org.apache.tools.ant.Target.performTasks(Target.java:369) [junit] at org.apache.tools.ant.Project.executeTarget(Project.java:1214) [junit] at org.apache.tools.ant.Project.executeTargets(Project.java:1062) [junit] at org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunn er.java:377) [junit] at org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRun ner.java:135) [junit] Caused by: java.lang.ArrayIndexOutOfBoundsException: 33 [junit] at org.apache.poi.util.LittleEndian.getNumber(LittleEndian.java:491) [junit] at org.apache.poi.util.LittleEndian.getShort(LittleEndian.java:52) [junit] at org.apache.poi.hssf.record.ObjRecord.fillFields(ObjRecord.java:98) [junit] at org.apache.poi.hssf.record.Record.fillFields(Record.java:90) [junit] at org.apache.poi.hssf.record.Record.init(Record.java:55) [junit] at org.apache.poi.hssf.record.ObjRecord.init(ObjRecord.java:61) [junit] ... 34 more [junit] Test - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta POI Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List:
Re: Subversion migration
Consider it a +0.5. Willing to help but not wanting it to take too much effort. Also I don't want anyone else put out by the move to agreement from the other committers is important to me. My thought exactly. I'm leaning towards lets do it, but don't want to particularly push it.. certainly not over any objections. Personally I'm looking forward to the ability selectively to merge atomic commits. I'm not sure if SVN improves much in terms of merges... much of that is future plans, but I could be wrong. AFAIC, the major advantages are firewalls, and atomic commits. In terms of data corruption, I'm pretty relaxed that the risk is low, but that's only an opinion. On Mon, 2005-01-03 at 22:47 +1100, Glen Stampoultzis wrote: [EMAIL PROTECTED] wrote: Because this is a core piece of infrastructure that could drastically affect this project, we need to proceed with due caution. Is CVS being discontinued? If so, at what point? Glen, is that a +1 (commitment of effort)? Consider it a +0.5. Willing to help but not wanting it to take too much effort. Also I don't want anyone else put out by the move to agreement from the other committers is important to me. Is anyone on POI familiar enough with Subversion to branch, tag and merge? Not yet. Learning subversion is something I'm going to have to do as part of my day job anyway since we are switching over there also. Does IntelliJ support subversion? There's a plugin for the current version. Apparently it's workable but not as seemless as the current CVS support. The upcoming version of Idea is going to have full support for subversion and they're opening up the source to the CVS and subversion code which is a nice bonus. What advantage will the POI project gain by switching given that our directory structure is relatively stable? Personally I'm looking forward to the ability selectively to merge atomic commits. Tracking merges with tags using CVS is a PITA. Playing nicely with firewalls is also handy when I'm in companies with restricted access to the internet. As I said though, commitment from all of you is important to me. Regards, Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HDF should be HWPF in bugzilla
Hi folks... back from a no replying to emails short break :) No, I don't have bugzilla admin... and as was pointed out on the infra list, bugzilla only has global Editcomponents admins. Apparently Andy has those privs. FWIW, the only project level privs, AFAIK, are to allow users to access bugs in a project, but thats irrelevant in an open bugzilla. Its crappy in a way, but WTH, I quite like bugzilla :) In terms of Apache installation, I think there are enough objectors for jira that bugzilla will be around for a while... it was one of the earliest apps to move to ajax from nagoya (there's a redirect, so people didn't notice). Although I personally would suggest we move... its easy, in the sense that accounts are moved as well. I have shell access at nagoya, and have created a dump of the items. http://www.apache.org/~avik/poinews.tar.gz Do you think it makes sense to maintain the news site. I will try and get is ported to ajax if it makes sense. On Sun, 2005-01-02 at 11:06 +1100, Glen Stampoultzis wrote: [EMAIL PROTECTED] wrote: I added it. I remember that someone else had permission (was it you Glen?). I think maybe Avik. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HSSFRichTextString use
1.Is this how Excel normally stores rich text in a xls file? It seems like a weird way to do this. Rich text is as weird as you can imagine. 2.Does it support the \img tag which would provide a way to include images. Whats the \img tag? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Asking again: unicode not working
You should probably try cellOn.setEncoding(HSSFCell.ENCODING_UTF_16 ); compressed unicode, AFAIK is an MS term that does not mean what it says :( On Wed, 2004-12-08 at 13:58 -0700, David Thielen wrote: -Original Message- From: David Thielen [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 11:02 AM To: 'POI Users List' Subject: Asking again: unicode not working Hi; I create my spreadsheet using: wb = new HSSFWorkbook(); sheet = wb.createSheet(); wb.setSheetName(0, process.getTitle(), HSSFWorkbook.ENCODING_UTF_16); For each cell I do: cellOn = rowOn.createCell(cellOnInd); cellOn.setEncoding( HSSFCell.ENCODING_COMPRESSED_UNICODE ); But when I do a: // code not shown set font to Arial Unicode MS cellOn.setCellValue(); // if you use a text mail client this is Euro, TM, and 2 russian characters I get: // if you use a text mail client, then is 3 PC graphics chars and a And the cell is set to use Arial Unicode MS. Any ideas? Thanks - dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mailing List Admin
I've done this, tell me if its still a problem.. havent seen a confirmation from ezmlm myself. On Mon, 2004-09-27 at 21:15, Danny Mui wrote: Who's got enough karma to remove [EMAIL PROTECTED] from the user's mailing list? It's been bothering us for a few weeks now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge questions
Yeah, that's what I thought, but the SringRecord is in hssf.record.. That's why I'm confused! On Mon, 2004-09-13 at 04:12, Glen Stampoultzis wrote: The hssf package was copied. The util package was manually merged. At 04:33 PM 13/09/2004, you wrote: Tyring to solve the testfailure in TestBugs, I am a bit confused by the merge. Was the merge done by simply copying the files from branch to head? If it was, then something is wrong with StringRecord. The last version on branch was 1.5.2.3, the latest on head, after merge is 1.9, and there is a difference between the two. In fact, there are more differences in the two than between 1.5.2.3 and 1.8! help? Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Glen Stampoultzis [EMAIL PROTECTED] http://members.iinet.net.au/~gstamp/glen/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge questions
Oh, ok makes sense. thanks. seems one patch from Toshiaki (18846) was applied to head and not branch. Meanwhile, I had fixed a bug 25695 in branch, but apparently (according to the commit comment) the fix did not work in HEAD. So looks like I'll have to fix the bug again...(my memory being what it is :) buts that shouldnt be very difficult... there's a very good testcase.. so thats cool. Thanks for the explanation Regards - Avik On Monday 13 Sep 2004 6:02 am, Glen Stampoultzis wrote: Well the only difference between the branch and head for StringRecord is that I had to update the call to StringUtil.putUncompressedUnicode() and change it to StringUtil.putUnicodeLE(); Was that the wrong change to make? -- Glen At 10:34 PM 13/09/2004, you wrote: Yeah, that's what I thought, but the SringRecord is in hssf.record.. That's why I'm confused! On Mon, 2004-09-13 at 04:12, Glen Stampoultzis wrote: The hssf package was copied. The util package was manually merged. At 04:33 PM 13/09/2004, you wrote: Tyring to solve the testfailure in TestBugs, I am a bit confused by the merge. Was the merge done by simply copying the files from branch to head? If it was, then something is wrong with StringRecord. The last version on branch was 1.5.2.3, the latest on head, after merge is 1.9, and there is a difference between the two. In fact, there are more differences in the two than between 1.5.2.3 and 1.8! help? Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Glen Stampoultzis [EMAIL PROTECTED] http://members.iinet.net.au/~gstamp/glen/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Glen Stampoultzis [EMAIL PROTECTED] http://members.iinet.net.au/~gstamp/glen/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Merge questions
Tyring to solve the testfailure in TestBugs, I am a bit confused by the merge. Was the merge done by simply copying the files from branch to head? If it was, then something is wrong with StringRecord. The last version on branch was 1.5.2.3, the latest on head, after merge is 1.9, and there is a difference between the two. In fact, there are more differences in the two than between 1.5.2.3 and 1.8! help? Regards - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
hpsf.basic.TestWrite failures
The testVariantTypes test in org.apache.poi.hpsf.basic.TestWrite fail if the local environment is set to UTF8, but passes if env is ISO-8859-1. In particular, the failures start at : check(Variant.VT_LPSTR, \u00e4, codepage); Any ideas? - Avik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where can I get PowerPoint code to test it?
Since its a largish piece of work (and might become the foundation of a much larger piece of work), and some of it done for his employer, I was waiting for a contributor agreement before committing it. So for now, please get it off the list archives. Sorry. Havent heard from Koundinya in a while. Will ping. Regards - Avik On Wed, 2004-08-25 at 08:00, Glen Stampoultzis wrote: Koundinya sent something to the list a while back. Search the archives (for his name). Avik was going to commit it to CVS but I don't think he got around to it. Avik? Regards, Glen At 03:21 AM 25/08/2004, you wrote: I am interested in testing the PPT extraction/creation code (even putting together some JUnit tests for it), but I can't find the code in the CVS HEAD branch. (I've got an excellent chance to test it because we are translating a 200+ slide presentation into 15 different languages.) Am I blind? Is it hidden? Or is it not in CVS yet? Thanks. -- Nathan Christiansen Software Engineer Tahitian Noni International http://www.tahitiannoni.com Glen Stampoultzis [EMAIL PROTECTED] http://members.iinet.net.au/~gstamp/glen/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDK 1.3 support
Even tho most committers, I believe, run 1.4 as their regular JVM's these days, we've always tried to ensure that POI runs properly in a jdk 1.3 environment. Any 1.4'isms therefore are usually the result of overlooking, rather than policy. Personally, I've tried to occasionally compile and test in a 1.3 environment, to ensure we stay 1.3 clean. However, this is getting increasingly difficult to do, particularly for people running Linux for various reasons [1]. However, I suppose keeping 1.3 compatibility is important for many of our users. So this mail is really to say that if running poi in JDK1.3 is important to you then: 1. Please say so 2. Someone please volunteer to compile and test latest CVS once in a while to ensure we stay 1.3 clean. Regards - Avik [1] Sun JDK 1.3 do not run well in recent Linux distributions,incl Fedora. See http://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=110610 for an explanation. Gump no longer does 1.3 runs. Many libraries that one downloads these days are NOT compiled with 1.3 bytecode compatibility, therefore throwing invalid class errors when run with jdk 1.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )
Interesting analysis, for sure. However, I'm not sure its as easy as it sounds. Essentially, the way in which the underlying records are being stored has changed (from create at startup to create and/or spoof on demand) Which is quite cool, but breaks many higher level functionality that depend on a different set of assumptions. Also, that has created a cognitive gap that not many have been able to cross, whereby its been difficult to fix the broken functionality. So its not a case of CVS merge.. essentially, some functionality needs to be re-written to the new way... - avik On Thu, 2004-08-05 at 03:33, [EMAIL PROTECTED] wrote: Greetings! One of you said Chime in, so I am. (No I haven't contributed before...) I thought that before I suggested option 1,2,3, or 4, I would try to see what was really at issue, which led to a little analyzing: (If I understand what is in CVS now, the branch you are referring to is the one tagged REL_2_BRANCH, and head is HEAD - which also seems to be MAIN, and jakarta-poi.) A quick compare of these shows: 5 .java files in REL_2_BRANCH not in HEAD. 119 .java files in HEAD not in REL_2_. 300 .java files that have differences, BUT... it looks like most of those 300 (90%+ ?), the only difference is in blank lines around the copyright notice or changes in comments, which leaves less than 30 java files where functionality has to be reconciled. If this is right, option #1 now seems less ominous than it did. I know I am assuming that I'm even looking at the right branch, which hasn't been obvious. I'm also only counting differences in the .java files. Am I way off base here? If my impression is even close to realistic, I'd be glad to help with merging changes from REL_2 into HEAD. Regards, Chris Wakefield Avik Sengupta [EMAIL PROTECTED] 08/05/04 10:40 AM Please respond to POI Developers List To: POI Developers List [EMAIL PROTECTED] cc: Subject: Plans etc (was Re: [VOTE] POI 2.5.1 release ) Glen, Thanks for setting the agenda. I agree that no. 4. isnt really an option. Option 1 is getting more and more difficult each day. Till about the 2.5 delivery, most changes were getting backported. But I think some recent fixes havent been. And I think it is infeasible to expect outside contributors to provide patches for both branches, which leaves committers with double the work to do. Thus, I think unless we are sure of getting HEAD in a fixable state very soon (which doesnt seem very likely at the moment), this will only get worse. Which I think essentially leaves us with a mix of options 2 and 3. I say this with some sadness, since the trunk contains some good stuff, and I have been thinking about this for a while. I think we are currently in a state of paralysis, and really need to getmoving... all the good stuff cant help us if we get stuck. Technically, the performance changes affect POIFS as well, AFAIK. Therefore, it would be better to copy HPFS and HWPF to branch, and copy the resulting back to HEAD.. but thats just an implementation detail. So my suggestion is take option 2 immediately, and work towards 3 after that. And finally, agree 100% on the rules of thumb.. On Wed, 2004-08-04 at 16:46, Glen Stampoultzis wrote: At 04:40 PM 4/08/2004, you wrote: On Wed, 2004-08-04 at 07:31, Glen Stampoultzis wrote: I've collected a bunch of changes together and created a maintenance release. Glen, first of all thank you for your changes and your effort to create a maintenance release! This does not include any changes being made in the head. I don't mind another maintenance release, but I'd also like to see a release with the new features that are in the head. For example, the HPSF capability to write properties is not in any release but only in the head for months if not for a year or so. HPSF's codepage handling is also in the head only for months. I suspect that many users don't know that these features exist because they just download a release and don't bother to checkout the CVS' head. Yes. I would also like a release of head. The main problem we face with this is that HSSF is very broken in the trunk. The performance work that was initially done was not complete. I did a bit of work earlier to try to fix some of the issues but there is still more that needs to be done and no one is particularly motivated to fix it as it's fairly hard to know where to start. Meanwhile it gets harder and harder to backport fixes to head as the branch gets further out of line. As I see it we have the following options: 1. Continue working on the trunk and backport any changes that haven't gone into the trunk yet. 2. Copy HSSF from the branch to trunk and overwrite the performance/memory changes. 3. Copy HSSF from the branch to trunk and come up
Plans etc (was Re: [VOTE] POI 2.5.1 release )
Glen, Thanks for setting the agenda. I agree that no. 4. isnt really an option. Option 1 is getting more and more difficult each day. Till about the 2.5 delivery, most changes were getting backported. But I think some recent fixes havent been. And I think it is infeasible to expect outside contributors to provide patches for both branches, which leaves committers with double the work to do. Thus, I think unless we are sure of getting HEAD in a fixable state very soon (which doesnt seem very likely at the moment), this will only get worse. Which I think essentially leaves us with a mix of options 2 and 3. I say this with some sadness, since the trunk contains some good stuff, and I have been thinking about this for a while. I think we are currently in a state of paralysis, and really need to getmoving... all the good stuff cant help us if we get stuck. Technically, the performance changes affect POIFS as well, AFAIK. Therefore, it would be better to copy HPFS and HWPF to branch, and copy the resulting back to HEAD.. but thats just an implementation detail. So my suggestion is take option 2 immediately, and work towards 3 after that. And finally, agree 100% on the rules of thumb.. On Wed, 2004-08-04 at 16:46, Glen Stampoultzis wrote: At 04:40 PM 4/08/2004, you wrote: On Wed, 2004-08-04 at 07:31, Glen Stampoultzis wrote: I've collected a bunch of changes together and created a maintenance release. Glen, first of all thank you for your changes and your effort to create a maintenance release! This does not include any changes being made in the head. I don't mind another maintenance release, but I'd also like to see a release with the new features that are in the head. For example, the HPSF capability to write properties is not in any release but only in the head for months if not for a year or so. HPSF's codepage handling is also in the head only for months. I suspect that many users don't know that these features exist because they just download a release and don't bother to checkout the CVS' head. Yes. I would also like a release of head. The main problem we face with this is that HSSF is very broken in the trunk. The performance work that was initially done was not complete. I did a bit of work earlier to try to fix some of the issues but there is still more that needs to be done and no one is particularly motivated to fix it as it's fairly hard to know where to start. Meanwhile it gets harder and harder to backport fixes to head as the branch gets further out of line. As I see it we have the following options: 1. Continue working on the trunk and backport any changes that haven't gone into the trunk yet. 2. Copy HSSF from the branch to trunk and overwrite the performance/memory changes. 3. Copy HSSF from the branch to trunk and come up with some more incremental ways to reduce memory. 4. Pretend nothing is wrong and go about the way we've been going. I don't like any of these options much. (1) involves a lot of work and will probably take a while to stabilize but preserves what has been done so far. (2) is easy and gets us back to a sane state but means all those memory improvements are now lost to us. (3) would be good but involves finding quick wins. There may be none to be found. I've been doing a little work in the background experimenting with less obtrusive ways to conserve memory but it's too early to tell if they'll be effective. (4) really doesn't isn't an option. We need to do something or the project is in trouble. So consider this an open discussion (non-committers welcome to chime in) about each option. If you're willing to help out in getting things back on track then let us know what you might be able to contribute. Here are some rules of thumb I'd like us to apply in the future: 1. No long lived branches. Branches are for minor patches to releases. Experimenting in branches is okay but don't expect it to form part of a release until it is solid. 2. No checking in of broken code. 3. Incremental changes are best. Regards, Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I am ready to contribute my efforts to POI
We also do care for high quality documentation. I think this is very important. Yes of course. thanks Rainer! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Powerpoint Tools for POI?
Ralph, We're (from having been burnt before), quite vary of dead code. Therefore, its good to hear you chime in with offer to help. And I certainly do hope Sudhakar is interested in further developing this functionality. However, first we need to ensure that the author wants the code in POI in the first place. Regards - Avik On Mon, 2004-08-02 at 21:05, Ralph Scheuer wrote: (To whom it may concern) Hello everybody, in the course of the last months, I have searched for a free Java framework that can process PowerPoint files. Some days ago, I finally found something here: http://cvs.apache.org/viewcvs.cgi/jakarta-slide/src/share/org/apache/ slide/extractor/ Apparently, one would not expect such things in Slide but rather in POI. Slide's extractors were contributed by Ryan Rhodes. I have tested these at first and this weekend I finally discovered Sudhakar Chavali's classes. This was cross-posted to the Slide User mailing list and the POI User mailing list. Sudhakar's classes are even better than those by Ryan Rhodes as they even take care of the document structure. I have just integrated this code into a production framework and fixed an issue where non-ASCII characters (in my case German umlauts) were not displayed correctly. All in all, this seems to be some really good work that might be able to help a lot of people. Avik Sengupta has already asked Sudhakar if he wants his work to become part of POI. While I do not want to impact his own decision of whether he wants to keep maintaining this code or not, I just wanted to inform you that there is some really good code available to deal with PowerPoint files and that this might also be a starting point for integrating even more PowerPoint functionality into POI. I just wondered why this code is in Slide and not in POI and whether there has already been conversation across the different groups. IMHO POI would be a good place for this functionality (the text extraction part is certainly also interesting for the Lucene guys). Once Sudhakar's code is in the right hands, I will certainly contribute any fixes we have for this code. If there is anything else I can do to help with this issue, let me know, but keep in mind that I have not been involved in any Jakarta project until now, so I may have to learn a lot. Kind regards, Ralph Scheuer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unicode support question
Cool. The setting of Unicode text in a cell is pretty well tested over the years. So I was surprised. Thanks for clarifying. Regards - Avik On Wed, 2004-07-21 at 03:32, Mikael Sitruk wrote: Well it seems that the problem was related to the program I used to insert non latin one character in the database. I've changed the client to one that really support Unicode and I've got the appropriate result in POI. I have also made the test without the database e.g. directly creating Unicode string and sending to POI everything was fine. Regards, Mikael.S -Original Message- From: Mikael Sitruk [mailto:[EMAIL PROTECTED] Sent: 20 July, 2004 00:53 To: [EMAIL PROTECTED] Subject: Unicode support question Hi I've been using POI for a while, but recently I've tried to check the support for Unicode. I'm not really sure that the problem that I encounter is related to POI itself, but I would like to share with you the fact, hoping that you might help I've an oracle database which NLS_LANG is set to ATL32UTF8. I've inserted Hebrew character in the database and I able to see them with an db editor like TOAD. I fetcht the data using JDBC, with oracle Thin driver, and send the data to two kind of output: 1.CSV file using UTF8 encoding 2.POI using the createCell and setEncoding(ENCODING_UTF_16). When I open the CSV file in an editor that support UTF 8, I see correctly the Hebrew characters, on the other hand when opening the Excel file created by POI I see garbage characters. Do you know what might be the problem??? P.S: The program runs on win2000, with jdk1.4.x, and I create the output file by cloning a template created MS excel. Thanks, for input. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POI in .NET
] Running org.apache.poi.poifs.storage.TestDocumentBlock
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 7.084
sec
[junit] Running org.apache.poi.poifs.storage.TestHeaderBlockReader
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.204
sec
[junit] Running org.apache.poi.poifs.storage.TestHeaderBlockWriter
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.317
sec
[junit] Running org.apache.poi.poifs.storage.TestPropertyBlock
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.298
sec
[junit] Running org.apache.poi.poifs.storage.TestRawDataBlock
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.175
sec
[junit] Running org.apache.poi.poifs.storage.TestRawDataBlockList
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.306
sec
[junit] Running
org.apache.poi.poifs.storage.TestSmallBlockTableReader
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.795
sec
[junit] Running
org.apache.poi.poifs.storage.TestSmallBlockTableWriter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.638
sec
[junit] Running org.apache.poi.poifs.storage.TestSmallDocumentBlock
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 9.562
sec
[junit] Running
org.apache.poi.poifs.storage.TestSmallDocumentBlockList
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.099
sec
[junit] Running org.apache.poi.util.TestBinaryTree
[junit] Tests run: 20, Failures: 7, Errors: 6, Time elapsed: 3.555
sec
[junit] TEST org.apache.poi.util.TestBinaryTree FAILED
[junit] Running org.apache.poi.util.TestBitField
[junit] Tests run: 15, Failures: 0, Errors: 0, Time elapsed: 0.074
sec
[junit] Running org.apache.poi.util.TestByteField
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.118
sec
[junit] Running org.apache.poi.util.TestHexDump
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 0.199
sec
[junit] TEST org.apache.poi.util.TestHexDump FAILED
[junit] Running org.apache.poi.util.TestIntList
[junit] Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 0.169
sec
[junit] TEST org.apache.poi.util.TestIntList FAILED
[junit] Running org.apache.poi.util.TestIntegerField
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.128
sec
[junit] Running org.apache.poi.util.TestLittleEndian
[junit] Tests run: 15, Failures: 0, Errors: 0, Time elapsed: 0.11
sec
[junit] Running org.apache.poi.util.TestLongField
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.827
sec
[junit] Running org.apache.poi.util.TestPOILogFactory
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.146
sec
[junit] Running org.apache.poi.util.TestPOILogger
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.153
sec
[junit] Running org.apache.poi.util.TestShortField
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.119
sec
[junit] Running org.apache.poi.util.TestShortList
[junit] Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 0.195
sec
[junit] TEST org.apache.poi.util.TestShortList FAILED
[junit] Running org.apache.poi.util.TestStringUtil
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.173
sec
On Thu, 2004-07-08 at 19:19, Avik Sengupta wrote:
Have you yearned to use the wonders of POI in you .NET applications?
Well, then yearn no more. POI compiled into a .NET dll is available at
http://www.apache.org/~avik/dist/poi-2.5.1-dev-20040708.dll
The following C# code uses poi to create a new excel file.. it compiles
and runs successfully .. tested in mono, should be fine in windows as
well. Of course, no warranties, it may eat your homework :)
Done with IKVM. You need to download the IKVM runtime to run this.
Thoughts?
--
//Main.cs -- reference POI dll and IKVM.GNU.Classpath.dll
using System;
using org.apache.poi.hssf.usermodel;
using ikvm.lang;
class MainClass
{
public static void Main(string[] args)
{
Console.WriteLine(Hello World!);
HSSFWorkbook wb = new HSSFWorkbook();
HSSFSheet s= wb.createSheet(Sheet1);
HSSFRow r= s.createRow(0);
HSSFCell c = r.createCell(1);
c.setCellValue(1);
java.io.FileOutputStream fs = new
java.io.FileOutputStream(dotnet.xls);
wb.write(fs);
fs.close();
}
}
---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting lots of /tmp/*.xls on Brutus
Yeah it did. We usually try to keep 1.2 compatibility .. but I dont know how important it is any more.. needs discussion on the dev list, I suppose. Regards - Avik On Mon, 2004-07-12 at 21:01, Adam R. B. Jack wrote: Did my suggestion of : http://java.sun.com/j2se/1.3/docs/api/java/io/File.html#createTempFile(java.lang.String,%20java.lang.String,%20java.io.File) Make it to this list? If you could pass a third parameter of './tmp' or './test/tmp' or something, then Gump would automatically clean up. Also, wouldn't this be a nicer place for human users to look? regards, Adam - Original Message - From: Rainer Klute [EMAIL PROTECTED] To: POI Developers List [EMAIL PROTECTED] Sent: Sunday, July 11, 2004 10:22 PM Subject: Re: Getting lots of /tmp/*.xls on Brutus Am So, den 11.07.2004 schrieb [EMAIL PROTECTED] um 8:23: It is deliberately this way. You need to delete the unit tests after running the test target. They are left there because how the heck could yo= u test if the files where valid otherwise? You could compare the generated files with files that are known to be correct and contain the expected result. Such a scenario could be set up as follows: 1. Run the test with a switch do not compare. 2. Manually load the generated file into the target application (Word, Excel etc.) and ensure that it is correct. 3. Move the generated file to a directory with should be files. 4. Future test runs use the file to compare with the files they generate themselves and remove the latter if the comparison yielded equality. (HPSF does it similarly.) Maybe we should add a delete /tmp/*.xls to the gump target? I doubt that any gump instances have other uses for xls files in the temp directory This could be done, too. Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting lots of /tmp/*.xls on Brutus
As Rainer confirmed, these are indeed POI tests. tests are indeed a separate target from compile in the build scripts, so even if you compile regularly, you should be fine. (Also I must say that all tests on my 1.8GHz pentium4 take about 1min 10sec to run .. POI is quite fast :). Its just that our gump descriptor specifies the test target to be run. We don't, in general, delete the files created, because some tests require opening up the file in excel to see if it displays correctly. So usually this is not a problem for interactive use, but I can see why gump would have a problem. One solution is to specify a separate ant target for gump that deletes all files created. In any case, the files are created in the system temp directory, using the java File.createTempFile method call. I dont know if that is something that can be controlled by setting environment variables. I'll see what I can do. Regards - Avik On Thu, 2004-07-08 at 23:53, Adam R. B. Jack wrote: My local (work) Gump that builds a really small subset of the Gump stack (and then my code) started dying w/ lack of disk space. We found that we were getting a full /tmp, and then I saw that Brutus has a similar issue. [EMAIL PROTECTED]:~$ wc /tmp/*.xls -bash: /usr/bin/wc: Argument list too long [EMAIL PROTECTED]:~$ cat /tmp/*.xls | wc -bash: /bin/cat: Argument list too long 0 0 0 i.e. lots of files! Basically, I have to assume that these are from POI (please correct me if I am wrong) and one (or both) of the two POI runs. http://brutus.apache.org:8080/gump/jakarta-poi/index.html http://brutus.apache.org:8080/gump/jakarta-poi-3/index.html Could you look at this problem, and help us out? Could you see if the POI test runs could use a ./tmp (or similar) directory, 'cos Gump cleans that out each run. [I don't know if this uses some Java function that you have limited control over, but I thought I'd ask.] Also, would it be possible to separate the POI tests from the POI compile? I use POI at work (love it, thanks!) and we try to compile our stack of code regularly. Anything that creates this much data must be resource intensive :) -- so if we could have separate poi and poi-test, we'd be able to save local resources. No biggee though. Thanks in advance. regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move HWPF out of scratchpad
+1 On Thu, 2004-03-25 at 17:58, Ryan Ackley wrote: Lets make it official - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving HWPF out of scratchpad
Lets go with the traditional thing Label things beta1, beta2 etc for development releases and full version numbers for final versions. Increase the major revision number for big changes. Ryan, you'll have to take a call on where you want to make a release from, HEAD or 2.0BRANCH. Currently all the HWPF code lives in HEAD. however, HSSF on HEAD does not pass even the existing unit tests. Do you want to make a copy of the HWPF code in Branch to make a release? Your call. I'll help the best I can. If we release from branch, lets call it 2.6beta1. If we release from head, call it 3.0beta1. Right? Regards - Avik On Thu, 2004-03-25 at 16:18, Glen Stampoultzis wrote: At 04:51 PM 25/03/2004, you wrote: I am very keen to see HWPF move out of scratchpad, it seems to have a lot of momentum recently. I was about to write a mail on this, Ryan beat me to it. So lets do that ASAP, i think. We should also do a dev release with this in, but I am -1 to calling it a 2.6. And I certainly disagree to adding HWPF to a bugfix release of 2.5.1. I dont think our long-suffering users would appreciate that :) Alternatives? Guys, I really think we really have to get our version numbering sane. We seem to have introduced a few regressions in 2.5, tho we called it a prod release. So I am all for doing a release, but calling it dev/beta whatever. What do you think? Absolutely. I think we all agree that the current way of doing things is silly. I'm really not bothered exactly what scheme we choose as long as it's sane. I figured for the 3.0 stuff we could decide on something sensible then document it as a standard. Options: Linux style: Odd minor numbers for development versions. Even numbers for production versions. Major numbers when big changes happen. Traditional: Label things beta1, beta2 etc for development releases and full version numbers for final versions. Increase the major revision number for big changes. Other: ??? I think I prefer traditional style but as I said I'm not really bothered. Regards, Glen Stampoultzis [EMAIL PROTECTED] http://members.iinet.net.au/~gstamp/glen/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving HWPF out of scratchpad
I am very keen to see HWPF move out of scratchpad, it seems to have a lot of momentum recently. I was about to write a mail on this, Ryan beat me to it. So lets do that ASAP, i think. We should also do a dev release with this in, but I am -1 to calling it a 2.6. And I certainly disagree to adding HWPF to a bugfix release of 2.5.1. I dont think our long-suffering users would appreciate that :) Guys, I really think we really have to get our version numbering sane. We seem to have introduced a few regressions in 2.5, tho we called it a prod release. So I am all for doing a release, but calling it dev/beta whatever. What do you think? On Thu, 2004-03-25 at 00:30, Ryan Ackley wrote: To all committers, I would like to get feel out everyones thoughts on moving HWPF out of scratchpad. More specifically, what requirements do you want me to meet before you would be willing to vote for this to happen? Avik and I are writing an article for JDJ and it will contain material on HWPF. For this article to have the maximum benefit, I feel that HWPF should be as easily accessible as possible. How about a 2.6 release containing HWPF? thoughts? -Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Received a patch file
Ryan, I hope you've got this issue solved... if not, send me the patch and I can apply it for you.. On Fri, 2004-03-05 at 08:17, Height, Jason wrote: Ryan, Well I use cygwin which provides the unix patch, cvs etc utilites for windows to do the work. But there may be easier ways (I don't know) However here is a rough instruction: Start a cygwin bash shell cd jakarta-poi-root patch -p0 mypatchfile.diff This assumes that the diff was performed beneath the Jakarta poi root directory, it may be one level up or several levels down in the source tree, you should be able to have a look at the diff file to work it out. The -p parameter means ignore this many levels of directory structure in the patch file. In our case when the directories match it is zero. If you are lucky the patch was applied without any rejects!! Then use cvs to upload the new code which I assume you already know how to do Let me know if you come to grief. Jason -Original Message- From: Ryan Ackley [mailto:[EMAIL PROTECTED] Sent: Friday, 5 March 2004 1:01 PM To: POI Developers List Subject: Received a patch file Err...now what do I do? How do I apply a patch to cvs? FYI, I use Windows. -Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail (including attachments) is confidential information of Australian Submarine Corporation Pty Limited (ASC). It may also be legally privileged. Unauthorised use and disclosure is prohibited. ASC is not taken to have waived confidentiality or privilege if this e-mail was sent to you in error. If you have received it in error, please notify the sender promptly. While ASC takes steps to identify and eliminate viruses, it cannot confirm that this e-mail is free from them. You should scan this e-mail for viruses before it is used. The statements in this e-mail are those of the sender only, unless specifically stated to be those of ASC by someone with authority to do so. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Warning about your e-mail account.
Folks, I have no clue how this message got into the list... I certainly didn't moderate it in.. and I cant believe '[EMAIL PROTECTED]' (duh!) is a member of the list. I'll ask the infrastructure people if we can stop this. Apparently the new Beagle worm is smart enough to send messages tuned to the recipient's email address!! Regards - Avik On Wed, 2004-03-03 at 21:18, [EMAIL PROTECTED] wrote: Dear user of e-mail server Apache.org, We warn you about some attacks on your e-mail account. Your computer may contain viruses, in order to keep your computer and e-mail account safe, please, follow the instructions. For details see the attached file. Sincerely, The Apache.org team http://www.apache.org __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New development build
+1 to do a dev and prod release... Our version numbers are pretty messed up, I would prefer a 2.1.x dev and a 2.2 release .. but please do what you prefer. I'd like to do a new development build followed soon after by a production build. Following our current quirky version standards this would be 2.1 for the development version and 3.0 for the production version. Alternatively we could go 2.5 for the production version. I really don't care. Please give your -1, -0, +0, +1's. BTW, we should probably look at upgrading to the new 2.0 license for this release. This will be forced upon us if we release after the end of Feb anyway. Anyone got a conversion script? Glen Stampoultzis [EMAIL PROTECTED] http://members.iinet.net.au/~gstamp/glen/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test Failure
single-test: [junit] Testsuite: org.apache.poi.hssf.usermodel.TestEscherGraphics [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.66 sec [junit] Testcase: testGetFont took 0.538 sec [junit] FAILED [junit] expected:...Arial... but was:...dialog... [junit] junit.framework.ComparisonFailure: expected:...Arial... but was:...dialog... [junit] at junit.framework.Assert.assertEquals(Assert.java:81) [junit] at junit.framework.Assert.assertEquals(Assert.java:87) [junit] at org.apache.poi.hssf.usermodel.TestEscherGraphics.testGetFont(TestEscherGraphics.java:30) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commits branches and features oh my
We need to start moving on 3.0 again. The testcases were initially failing in hpsf (testcase issues) which I have fixed. The next block was the shared formula stuff that does not work in 3.0. Jason has put a patch in bugzilla to fix that (very different from 2.0) .. while I looked at it yet, I am not too concerned since its a reasonably well defined/encapsulated issue, with a patch. The testcases then stop working on the hssf.usermodel.TestBugs tests, which are primarily higher level/functional sort of tests, meaning that they are catching things which aren't being caught in our unit tests. Which in turn means that they require significantly more debugging effort. Anyways, that was just by way of a status check. Andy, what would be useful if you could do a couple of paragraphs of architecture documentation about how records are now stored and manipulated into higher level objects? Another thing that struck me while I was debugging was that there were only a few tests for ValueRecordAggregate, given the amount of functionality in that class.. we need to write more tests for that.. i'll try and do some. Regards - Avik On Tue, 2004-02-10 at 04:46, Andrew C. Oliver wrote: Don't forget to add this to 3.0! We need to start moving on 3.0 again. I need everyone's help to make the HSSF stuff work. There was too much stuff I didn't work on for me to be able to do it myself. Lets also get the discussion on TNEF and POIFS2 rolling again. SuperLink also has a significant new feature to add in the coming days: Escher images. I'd like to propose that we do a 2.5. . . . Oh I know I know we said never again, but this feature is far too mature for 3.0 and far to sweeping for a 2.01 release in my opinion. I'd like to hear what others think. Based on this you can now draw company logos on the reports and more. Alternatively, we could make the HEAD 4.0 and do the drawing stuff as 3.0 Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GUMP
I would of thought the 3rd line would be a dead give away: It would be if my brains were functioning right I would have imagined that the branch setting would be on the cvs element rather than module element. Even after receiving your mail, it took me a while to find it ..:) Thanks. I'll run with it. One installation of python Gump has started sending nags... they are going to the moderation queue as the from address is not subscribed, but I havent been letting them thru since its not taking care of the branch. This needs to be taken to the gump lists. Regards - Avik On Mon, 2004-02-02 at 18:30, Glen Stampoultzis wrote: At 10:18 PM 2/02/2004, you wrote: Anybody know how GUMP knows about branches? I could not see any difference in the jakarta-poi and jakarata-poi3, so am confused. How were they set up initially. I would of thought the 3rd line would be a dead give away: module name=jakarta-poi tag=REL_2_BRANCH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
