[Bug 63067] Ant build fails with Oracle JDK 11.0.1 @ Windows 10 x64 (problem with poifs?)
https://bz.apache.org/bugzilla/show_bug.cgi?id=63067 Dominik Stadler changed: What|Removed |Added OS||All -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[Bug 62904] Simple Excel Array Formula Fails in POI
https://bz.apache.org/bugzilla/show_bug.cgi?id=62904 --- Comment #4 from gallon.fi...@gmail.com --- @Yegor could you please look into this issue https://bz.apache.org/bugzilla/show_bug.cgi?id=63054 ? The topic seems very close, and the divine vision of the code may still be fresh in your cache. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[Bug 63068] New: Unifying Cell.setCellFormula behavior
https://bz.apache.org/bugzilla/show_bug.cgi?id=63068
Bug ID: 63068
Summary: Unifying Cell.setCellFormula behavior
Product: POI
Version: 4.0.x-dev
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: SS Common
Assignee: dev@poi.apache.org
Reporter: gallon.fi...@gmail.com
CC: gallon.fi...@gmail.com
Target Milestone: ---
Motivation: in a simple testcase:
Cell cell = getInstance();
cell.setCellErrorValue(FormulaError.NUM.getCode()); // some non-trivial value
cell.setCellFormula("\"foo\"");
System.out.println(cell.getCellType());
System.out.println(cell.getCachedFormulaResultType());
all HSSF, XSSF, SXSSF return cellType == FORMULA, but the
getCachedFormulaResultType() returns:
HSSF: NUMERIC (value == 0)
XSSF: ERROR (value == NULL (code == 0))
SXSSF: NUMERIC (value == 0)
In Excel, when a formula is set, it is immediately evaluated, even if
calculation mode is set to manual. We won't mimic this behavior (although it's
theoretically possible but is costly an may have subtle side effects). Because
we don't evaluate the formula right away, we don't know the result type (which
is in general volatile for a fixed formula). So the old value may be seen as a
(stale) "cached" value, just like between calls to the evaluator.
So the choice is to set the value to a default value for the previous value
type or simply preserve the value. My take is to preserve the value, it's least
invasive and doesn't involve implicit value changes.
So, the proposed change:
* state this strategy in Cell's javadoc
* ensure this behavior by tests
* implement
Special case: if there already was a formula set, the behavior remains the
same.
Special case: when setting a formula on a blank cell, it's value type is
converted to numeric with value 0.
Special case: if the formula cannot be set for some reason (part of an array
group or parsing error), the value shall be preserved, as well as the previous
formula.
Special case: when a cell becomes a part of an array formula group, the value
shall be preserved.
Note: I am referring to a non-null valid formula. Setting formula to null
(effectively, removing a formula) logic may is different.
Did I miss something?
Comments are very welcome.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org
[Bug 63067] New: Ant build fails with Oracle JDK 11.0.1 @ Windows 10 x64 (problem with poifs?)
https://bz.apache.org/bugzilla/show_bug.cgi?id=63067 Bug ID: 63067 Summary: Ant build fails with Oracle JDK 11.0.1 @ Windows 10 x64 (problem with poifs?) Product: POI Version: 4.0.x-dev Hardware: PC Status: NEW Severity: normal Priority: P2 Component: POIFS Assignee: dev@poi.apache.org Reporter: gallon.fi...@gmail.com Target Milestone: --- Testsuite: org.apache.poi.hpsf.basic.TestWrite Tests run: 10, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 0.119 sec - Standard Error - Your default character set is windows-1251. However, this testcase must be run in an environment with a default character set supporting at least 8-bit-characters. You can achieve this by setting the LANG environment variable to a proper value, e.g. "de_DE". This testcase is skipped for the default codepage. - --- Testcase: writeEmptyPropertySet took 0.001 sec Testcase: writeTwoSections took 0.001 sec Testcase: unicodeWrite8Bit took 0 sec Testcase: inPlaceNPOIFSWrite took 0.101 sec Caused an ERROR build\tmp\poifiles\Test-HPSF16257071657768182756ole2 (The requested operation cannot be performed on a file with a user-mapped section open) java.io.FileNotFoundException: build\tmp\poifiles\Test-HPSF16257071657768182756ole2 (The requested operation cannot be performed on a file with a user-mapped section open) at java.base/java.io.FileOutputStream.open0(Native Method) at java.base/java.io.FileOutputStream.open(FileOutputStream.java:298) at java.base/java.io.FileOutputStream.(FileOutputStream.java:237) at java.base/java.io.FileOutputStream.(FileOutputStream.java:187) at org.apache.poi.hpsf.basic.TestWrite.inPlaceNPOIFSWrite(TestWrite.java:565) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) === TestHSSFWorkbook: Testcase: testRewriteFileBug58480 took 0.004 sec FAILED null junit.framework.AssertionFailedError at org.apache.poi.hssf.usermodel.TestHSSFWorkbook.testRewriteFileBug58480(TestHSSFWorkbook.java:1129) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) == Testsuite: org.apache.poi.poifs.nio.TestDataSource Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Testcase: testFileWritable took 0.002 sec FAILED Could not delete file build\tmp\poifiles\TestDataSource16374135609496438093.test junit.framework.AssertionFailedError: Could not delete file build\tmp\poifiles\TestDataSource16374135609496438093.test at org.apache.poi.poifs.nio.TestDataSource.testFileWritable(TestDataSource.java:80) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) = I build with IntelliJ Idea, project jdk set to jdk11. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[GitHub] poi pull request #140: Add .travis.yml
GitHub user krichter722 opened a pull request: https://github.com/apache/poi/pull/140 Add .travis.yml This should be useful since it allows to track build issues, like https://travis-ci.org/krichter722/poi/builds/476455505 You can merge this pull request into a Git repository by running: $ git pull https://github.com/krichter722/poi travis Alternatively you can review and apply these changes as the patch at: https://github.com/apache/poi/pull/140.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #140 commit 15eb9ce2b9684949fbaddcadcb53354628adaf95 Author: Karl-Philipp Richter Date: 2019-01-07T16:43:39Z Add .travis.yml --- - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[Bug 63046] Switch to SLF4J for logging
https://bz.apache.org/bugzilla/show_bug.cgi?id=63046 --- Comment #2 from PJ Fanning --- https://logging.apache.org/log4j/2.x/ Says: Avoid lock-in Applications coded to the Log4j 2 API always have the option to use any SLF4J-compliant library as their logger implementation with the log4j-to-slf4j adapter. My preference would still be for slf4j-api. And users who want log4j2 can use https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-slf4j-impl/2.11.1 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[Bug 63046] Switch to SLF4J for logging
https://bz.apache.org/bugzilla/show_bug.cgi?id=63046 --- Comment #1 from Axel Howind --- Why not use log4j2 instead which now offers the same functionality that SLF4J does (seperation of API and backend), seems to perform better and has more functionality? What's more, it's an Apache project. There's an interesting discussion on stackoverflow in the comments to [this](https://stackoverflow.com/questions/41498021/is-it-worth-to-use-slf4j-with-log4j2) question, where one of the log4j2 devs and Ceki (the one behind SLF4J) are involved. Oh, and of course the answer by itself is also worth a read. After trying both, I would say: if your project already uses SLF4J, stick with it. If not, use Log4j2. What's more: SLF4J on Android is dead for more than 4 years now. I don't know how easy it is running POI on Android (I just googled and found at least two projects that do it), but it would be definitely easier if the used logging framework supports the platform. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[Bug 62904] Simple Excel Array Formula Fails in POI
https://bz.apache.org/bugzilla/show_bug.cgi?id=62904
Yegor Kozlov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Yegor Kozlov ---
I checked in the fix in r1850646. The fix *improves* support for evaluation of
array formulas, but full coverage is a long way ahead.
What is included in the fix:
1. support for array arguments in the IF function.
In a array context IF is rarely used by its own, it is usually nested in
another function like {=MIN(IF(logical_test, values))} as in your example.
Tests with MIN and MAX all pass. For SUM I have at least one failing test, but
it can be related to another issue.
2. Support for array arguments in logical IS*** functions and unary operators.
This makes it possible to evaluate formulas like {=SUM( --ISERROR(E6:E11)) }.
Previously IS*** and unary operators evaluated to a scalar and the result was
wrong.
Please open a new ticket or re-open this one if you find more issues with
evaluation of array formulas.
Regards,
Yegor
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org
