[jira] Commented: (MATH-246) Simplex Method Implementation
[
https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689389#action_12689389
]
Luc Maisonobe commented on MATH-246:
Another issue that bothers me.
There is a constructor for a linear constraint with vectors for both left hand
side and right hand side that subtracts both and put 0 as the scalar on the
right hand side.
This seems odd to me.
If for example we call it with lhs = { 2, 3 }, rhs = { 1, 1 }, r = EQ this
means we set up the constraint
(2 - 1) x + (3 - 1)y = 0 or x + 2y = 0. Users may think it would be equivalent
to the two constraints 2x=1 and 3y=1 which is not the case. For inequality
constraints, this looks even more strange.
If there is a use for this in a specific context, I suggest the subtraction be
done at user code level before calling the constructor rather than providing
support in the linear constraint class for this.
I suggest to drop this constructor, except if you can provide me some hints I
will pour in the javadoc to help users.
> Simplex Method Implementation
> -
>
> Key: MATH-246
> URL: https://issues.apache.org/jira/browse/MATH-246
> Project: Commons Math
> Issue Type: New Feature
>Reporter: Benjamin McCann
>Assignee: Luc Maisonobe
> Fix For: 2.0
>
> Attachments: newfiles.zip
>
>
> I've created an implementation of the Simplex algorithm for optimizing
> systems of constrained linear equations that I'd like to contribute.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (NET-267) Support HTTP Proxying
Support HTTP Proxying - Key: NET-267 URL: https://issues.apache.org/jira/browse/NET-267 Project: Commons Net Issue Type: New Feature Affects Versions: 2.0 Reporter: Rory Winston Priority: Minor In response to a recent email on the user list: add support for FTP proxying over HTTP (not SOCKS). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COMPRESS-28) CPIO reports unexpected EOF
[
https://issues.apache.org/jira/browse/COMPRESS-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Grobmeier resolved COMPRESS-28.
-
Resolution: Fixed
> CPIO reports unexpected EOF
> ---
>
> Key: COMPRESS-28
> URL: https://issues.apache.org/jira/browse/COMPRESS-28
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Christian Grobmeier
> Fix For: 1.0
>
> Attachments: patch-improvedcpiodocs.txt,
> patch_cpiotestcases_closing.txt
>
>
> When unpacking an CPIO archive (made with the compress classes or even made
> with OSX cpio comandline tool) an EOF exception is thrown.
> Here is the testcode:
> final File input = getFile("cmdcreated.cpio");
> final InputStream in = new FileInputStream(input);
> CpioArchiveInputStream cin = new CpioArchiveInputStream(in);
> CpioArchiveEntry entry = null;
> while ((entry = (CpioArchiveEntry) cin.getNextCPIOEntry()) != null) {
> File target = new File(dir, entry.getName());
> final OutputStream out = new FileOutputStream(target);
> IOUtils.copy(in, out);
> out.close();
> }
> cin.close();
> Stacktrace is here:
> java.io.EOFException
> at
> org.apache.commons.compress.archivers.cpio.CpioArchiveInputStream.readFully(CpioArchiveInputStream.java:293)
> at
> org.apache.commons.compress.archivers.cpio.CpioArchiveInputStream.getNextCPIOEntry(CpioArchiveInputStream.java:168)
> at
> org.apache.commons.compress.archivers.cpio.CpioArchiveInputStreamTest.testCpioUnpack(CpioArchiveInputStreamTest.java:26)
> ...
> This happens with the first read access to the archive. It occured while my
> try to improve the testcases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COMPRESS-53) Remove src/main/resources
Remove src/main/resources - Key: COMPRESS-53 URL: https://issues.apache.org/jira/browse/COMPRESS-53 Project: Commons Compress Issue Type: Improvement Reporter: Jukka Zitting Priority: Minor The src/main/resources directory currently contains a copy of the bla.zip file from src/test/resources. The test file most likely should not be included in the resulting commons-compress jar file. In fact it doesn't since the commons-parent:11 parent POM overrides the default resources settings, but it's still confusing to have the test file under src/main. I would simply remove the entire src/main/resources directory as we're not using it for anything and the current Maven settings won't use the directory in any case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COMPRESS-54) Add 7zip or RAR archive support
Add 7zip or RAR archive support --- Key: COMPRESS-54 URL: https://issues.apache.org/jira/browse/COMPRESS-54 Project: Commons Compress Issue Type: New Feature Environment: N/A Reporter: Tim Pinet Priority: Minor Has anyone looked into adding support for 7zip and RAR file types? Using the j7zip and junrar libraries I was able to get a rough protoype working with commons-compress but only with extract support for RAR (due to licencing issues). Also, my prototype performance is poor so I definately need to improve it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SANDBOX-307) UUID URN version 5 generation
UUID URN version 5 generation
-
Key: SANDBOX-307
URL: https://issues.apache.org/jira/browse/SANDBOX-307
Project: Commons Sandbox
Issue Type: Bug
Components: Id
Affects Versions: Nightly Builds
Environment: Linux Ubuntu 8.10
JDK 1.6.10
Reporter: Davide Ling
The following test fail with the message:
org.junit.ComparisonFailure:
expected:<...:uuid:be6a1b75-9a58-[5]4a8-972e-791dfdd8815...> but
was:<...:uuid:be6a1b75-9a58-[3]4a8-972e-791dfdd8815...>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at
org.davideling.provauuid.ProvaUUIDTest.testUUID(ProvaUUIDTest.java:25)
public class UUIDVersion5Test {
// Linux generated URN using the uuid command:
// dav...@mydebian:~$ uuid -v 5
6ba7b811-9dad-11d1-80b4-00c04fd430c8 http://davideling.org/miaApp/2
// dav...@mydebian:~$ be6a1b75-9a58-54a8-972e-791dfdd8815b
private static final String LINUX_GENERATED_URN =
"urn:uuid:be6a1b75-9a58-54a8-972e-791dfdd8815b";
// URL UUID namespace
private static final UUID NAMESPACE = new
UUID("6ba7b811-9dad-11d1-80b4-00c04fd430c8");
// Name
private static final String NAME = "http://davideling.org/miaApp/2";;
@Test
public void testUUID() throws Exception {
UUID uuid = UUID.nameUUIDFromString(NAME, NAMESPACE,
UUID.SHA1_ENCODING);
assertEquals(LINUX_GENERATED_URN, uuid.toUrn() );
}
}
When using the SHA1 algorithm with UUID.nameUUIDFromString the version field
have to be 5 (?) as the
Linux uuid generated URN?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-54) Add 7zip or RAR archive support
[ https://issues.apache.org/jira/browse/COMPRESS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689465#action_12689465 ] Torsten Curdt commented on COMPRESS-54: --- I've only gathered libraries for implementing this. For RAR I found sources for o rarlib (GPL) o unrar (sort of free but cpp) For 7zip I found o p7zip (LGPL + restriction, written in C) o j7zip (LGPL) And there are other algorithms (and libraries) to implement as well: ARJ, CAB, ... But I fear some of those implementations need to be hosted somewhere else (due to the licensing). I'd suggest to create a github project for it. > Add 7zip or RAR archive support > --- > > Key: COMPRESS-54 > URL: https://issues.apache.org/jira/browse/COMPRESS-54 > Project: Commons Compress > Issue Type: New Feature > Environment: N/A >Reporter: Tim Pinet >Priority: Minor > Original Estimate: 30h > Remaining Estimate: 30h > > Has anyone looked into adding support for 7zip and RAR file types? Using the > j7zip and junrar libraries I was able to get a rough protoype working with > commons-compress but only with extract support for RAR (due to licencing > issues). Also, my prototype performance is poor so I definately need to > improve it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SANDBOX-307) UUID URN version 5 generation
[
https://issues.apache.org/jira/browse/SANDBOX-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Ling updated SANDBOX-307:
Description:
The following test fail with the message:
org.junit.ComparisonFailure:
expected:<...:uuid:be6a1b75-9a58-[5]4a8-972e-791dfdd8815...> but
was:<...:uuid:be6a1b75-9a58-[3]4a8-972e-791dfdd8815...>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at
org.davideling.provauuid.ProvaUUIDTest.testUUID(ProvaUUIDTest.java:25)
public class UUIDVersion5Test {
// Linux generated URN using the uuid command:
// dav...@mydebian:~$ uuid -v 5 6ba7b811-9dad-11d1-80b4-00c04fd430c8
http://davideling.org/miaApp/2
// dav...@mydebian:~$ be6a1b75-9a58-54a8-972e-791dfdd8815b
private static final String LINUX_GENERATED_URN =
"urn:uuid:be6a1b75-9a58-54a8-972e-791dfdd8815b";
// URL UUID namespace
private static final UUID NAMESPACE = new
UUID("6ba7b811-9dad-11d1-80b4-00c04fd430c8");
// Name
private static final String NAME = "http://davideling.org/miaApp/2";;
@Test
public void testUUID() throws Exception {
UUID uuid = UUID.nameUUIDFromString(NAME, NAMESPACE,
UUID.SHA1_ENCODING);
assertEquals(LINUX_GENERATED_URN, uuid.toUrn() );
}
}
When using the SHA1 algorithm with UUID.nameUUIDFromString the version field
have to be 5 (?) as the
Linux uuid generated URN?
was:
The following test fail with the message:
org.junit.ComparisonFailure:
expected:<...:uuid:be6a1b75-9a58-[5]4a8-972e-791dfdd8815...> but
was:<...:uuid:be6a1b75-9a58-[3]4a8-972e-791dfdd8815...>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at
org.davideling.provauuid.ProvaUUIDTest.testUUID(ProvaUUIDTest.java:25)
public class UUIDVersion5Test {
// Linux generated URN using the uuid command:
// dav...@mydebian:~$ uuid -v 5
6ba7b811-9dad-11d1-80b4-00c04fd430c8 http://davideling.org/miaApp/2
// dav...@mydebian:~$ be6a1b75-9a58-54a8-972e-791dfdd8815b
private static final String LINUX_GENERATED_URN =
"urn:uuid:be6a1b75-9a58-54a8-972e-791dfdd8815b";
// URL UUID namespace
private static final UUID NAMESPACE = new
UUID("6ba7b811-9dad-11d1-80b4-00c04fd430c8");
// Name
private static final String NAME = "http://davideling.org/miaApp/2";;
@Test
public void testUUID() throws Exception {
UUID uuid = UUID.nameUUIDFromString(NAME, NAMESPACE,
UUID.SHA1_ENCODING);
assertEquals(LINUX_GENERATED_URN, uuid.toUrn() );
}
}
When using the SHA1 algorithm with UUID.nameUUIDFromString the version field
have to be 5 (?) as the
Linux uuid generated URN?
> UUID URN version 5 generation
> -
>
> Key: SANDBOX-307
> URL: https://issues.apache.org/jira/browse/SANDBOX-307
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Id
>Affects Versions: Nightly Builds
> Environment: Linux Ubuntu 8.10
> JDK 1.6.10
>Reporter: Davide Ling
>
> The following test fail with the message:
> org.junit.ComparisonFailure:
> expected:<...:uuid:be6a1b75-9a58-[5]4a8-972e-791dfdd8815...> but
> was:<...:uuid:be6a1b75-9a58-[3]4a8-972e-791dfdd8815...>
> at org.junit.Assert.assertEquals(Assert.java:123)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at
> org.davideling.provauuid.ProvaUUIDTest.testUUID(ProvaUUIDTest.java:25)
> public class UUIDVersion5Test {
> // Linux generated URN using the uuid command:
> // dav...@mydebian:~$ uuid -v 5 6ba7b811-9dad-11d1-80b4-00c04fd430c8
> http://davideling.org/miaApp/2
> // dav...@mydebian:~$ be6a1b75-9a58-54a8-972e-791dfdd8815b
> private static final String LINUX_GENERATED_URN =
> "urn:uuid:be6a1b75-9a58-54a8-972e-791dfdd8815b";
>
> // URL UUID namespace
> private static final UUID NAMESPACE = new
> UUID("6ba7b811-9dad-11d1-80b4-00c04fd430c8");
>
> // Name
> private static final String NAME = "http://davideling.org/miaApp/2";;
>
> @Test
> public void testUUID() throws Exception {
>
> UUID uuid = UUID.nameUUIDFromString(NAME, NAMESPACE,
> UUID.SHA1_ENCODING);
> assertEquals(LINUX_GENERATED_URN, uuid.toUrn() );
> }
>
> }
> When using the SHA1 algorithm with UUID.nameUUIDFromString the version field
> have to be 5 (?) as the
> Linux uuid generated URN?
--
This message is automatically generated by JIRA.
-
You can reply to this
[jira] Created: (COMPRESS-55) CpioArchiveEntry ignores invalid modes
CpioArchiveEntry ignores invalid modes
--
Key: COMPRESS-55
URL: https://issues.apache.org/jira/browse/COMPRESS-55
Project: Commons Compress
Issue Type: Bug
Reporter: Sebb
CpioArchiveEntry has the following code:
{code}
default:
// FIXME: testCpioUnarchive fails if I change the line to
// actually throw the excpetion
new IllegalArgumentException("Unknown mode (full mode: " + mode
+ ", masked mode: " + (mode & S_IFMT));
}
{code}
As the comment says, rejecting invalid modes causes test failures.
These appear to be caused by the code
{bq}this.cpioEntry.setMode(0);
in the method CpioArchiveOutputStream.finish()
Is a mode of 0 allowed? If so, then setMode needs to allow it, otherwise the
method call needs to change to something else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-53) Remove src/main/resources
[ https://issues.apache.org/jira/browse/COMPRESS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689470#action_12689470 ] Sebb commented on COMPRESS-53: -- CpioArchiveInputStream.readNewEntry() can also set the mode to 0 in CpioArchiveInputStreamTest.testCpioUnarchive(). > Remove src/main/resources > - > > Key: COMPRESS-53 > URL: https://issues.apache.org/jira/browse/COMPRESS-53 > Project: Commons Compress > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > > The src/main/resources directory currently contains a copy of the bla.zip > file from src/test/resources. The test file most likely should not be > included in the resulting commons-compress jar file. In fact it doesn't since > the commons-parent:11 parent POM overrides the default resources settings, > but it's still confusing to have the test file under src/main. > I would simply remove the entire src/main/resources directory as we're not > using it for anything and the current Maven settings won't use the directory > in any case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMPRESS-53) Remove src/main/resources
[ https://issues.apache.org/jira/browse/COMPRESS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated COMPRESS-53: - Comment: was deleted (was: CpioArchiveInputStream.readNewEntry() can also set the mode to 0 in CpioArchiveInputStreamTest.testCpioUnarchive().) > Remove src/main/resources > - > > Key: COMPRESS-53 > URL: https://issues.apache.org/jira/browse/COMPRESS-53 > Project: Commons Compress > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > > The src/main/resources directory currently contains a copy of the bla.zip > file from src/test/resources. The test file most likely should not be > included in the resulting commons-compress jar file. In fact it doesn't since > the commons-parent:11 parent POM overrides the default resources settings, > but it's still confusing to have the test file under src/main. > I would simply remove the entire src/main/resources directory as we're not > using it for anything and the current Maven settings won't use the directory > in any case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-55) CpioArchiveEntry ignores invalid modes
[
https://issues.apache.org/jira/browse/COMPRESS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689471#action_12689471
]
Sebb commented on COMPRESS-55:
--
CpioArchiveInputStream.readNewEntry() can also set the mode to 0 when tested
by CpioArchiveInputStreamTest.testCpioUnarchive().
> CpioArchiveEntry ignores invalid modes
> --
>
> Key: COMPRESS-55
> URL: https://issues.apache.org/jira/browse/COMPRESS-55
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Sebb
>
> CpioArchiveEntry has the following code:
> {code}
> default:
> // FIXME: testCpioUnarchive fails if I change the line to
> // actually throw the excpetion
> new IllegalArgumentException("Unknown mode (full mode: " + mode
> + ", masked mode: " + (mode & S_IFMT));
> }
> {code}
> As the comment says, rejecting invalid modes causes test failures.
> These appear to be caused by the code
> {bq}this.cpioEntry.setMode(0);
> in the method CpioArchiveOutputStream.finish()
> Is a mode of 0 allowed? If so, then setMode needs to allow it, otherwise the
> method call needs to change to something else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-55) CpioArchiveEntry ignores invalid modes
[
https://issues.apache.org/jira/browse/COMPRESS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689474#action_12689474
]
Sebb commented on COMPRESS-55:
--
Just tried a test with mode 0 allowed.
One test fails:
Unknown mode (full mode: 4294967295, masked mode: 61440
at
org.apache.commons.compress.archivers.cpio.CpioArchiveEntry.setMode(CpioArchiveEntry.java:605)
at
org.apache.commons.compress.archivers.cpio.CpioArchiveInputStream.readNewEntry(CpioArchiveInputStream.java:324)
at
org.apache.commons.compress.archivers.cpio.CpioArchiveInputStream.getNextCPIOEntry(CpioArchiveInputStream.java:182)
at
org.apache.commons.compress.archivers.cpio.CpioArchiveInputStream.getNextEntry(CpioArchiveInputStream.java:421)
at
org.apache.commons.compress.archivers.CpioTestCase.testCpioUnarchive(CpioTestCase.java:82)
4294967295 = 0x
61440 = 0xF000
I think this may be due to problems with EOF handling, because I don't think
the test file has that data in it.
> CpioArchiveEntry ignores invalid modes
> --
>
> Key: COMPRESS-55
> URL: https://issues.apache.org/jira/browse/COMPRESS-55
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Sebb
>
> CpioArchiveEntry has the following code:
> {code}
> default:
> // FIXME: testCpioUnarchive fails if I change the line to
> // actually throw the excpetion
> new IllegalArgumentException("Unknown mode (full mode: " + mode
> + ", masked mode: " + (mode & S_IFMT));
> }
> {code}
> As the comment says, rejecting invalid modes causes test failures.
> These appear to be caused by the code
> {bq}this.cpioEntry.setMode(0);
> in the method CpioArchiveOutputStream.finish()
> Is a mode of 0 allowed? If so, then setMode needs to allow it, otherwise the
> method call needs to change to something else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COMPRESS-56) Add InputStream byte counting to debug invalid input formats
Add InputStream byte counting to debug invalid input formats Key: COMPRESS-56 URL: https://issues.apache.org/jira/browse/COMPRESS-56 Project: Commons Compress Issue Type: Improvement Reporter: Sebb If an input file has an invalid format - or the code thinks it has - at present it's really difficult to find out what the problem is. If the file input methods counted bytes, then this information could be included in Exceptions or log output etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-207) Implementation of GeneticAlgorithm.nextGeneration() is wrong
[ https://issues.apache.org/jira/browse/MATH-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689486#action_12689486 ] David Stefka commented on MATH-207: --- Hi again, I have finished work on better representation of permutations in GA, so I am sending the implementation in a .zip file. The code includes: * new implementation of RandomKey -- chromosome representing permutations; the old PermutationChromosome implementation has been removed * some minor improvements (chromosome's representation is held in an unmodifiable list instead of an array, better implementation of generic issues, renaming of several classes, etc.) * GeneticAlgorithm has a static Random instance, which is used for all random numbers in the implementation. This is useful for debugging, because if the Random is initialized to a particular seed, the behavior can be reproduced. If a similar mechanism is already somewhere in the * the code should be java 1.5 compatible * all the files should include the Apache license headers I have also filled and signed the CLA and sent it to secret...@apache.org > Implementation of GeneticAlgorithm.nextGeneration() is wrong > > > Key: MATH-207 > URL: https://issues.apache.org/jira/browse/MATH-207 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.0 >Reporter: David Stefka >Assignee: Phil Steitz > Fix For: 2.0 > > Attachments: geneticalgorithm.patch, genetics_impl.zip, patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > The implementation of GeneticAlgorithm.nextGeneration() is wrong, since the > only way how a Chromosome can get into the new generation is by mutation. > Enclosed, I am sending a patch for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-207) Implementation of GeneticAlgorithm.nextGeneration() is wrong
[ https://issues.apache.org/jira/browse/MATH-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Stefka updated MATH-207: -- Attachment: geneticAlgorithms.zip New implementation of basic GA algorithms > Implementation of GeneticAlgorithm.nextGeneration() is wrong > > > Key: MATH-207 > URL: https://issues.apache.org/jira/browse/MATH-207 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.0 >Reporter: David Stefka >Assignee: Phil Steitz > Fix For: 2.0 > > Attachments: geneticalgorithm.patch, geneticAlgorithms.zip, > genetics_impl.zip, patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > The implementation of GeneticAlgorithm.nextGeneration() is wrong, since the > only way how a Chromosome can get into the new generation is by mutation. > Enclosed, I am sending a patch for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-201) CountingInputStream is partially synchronized
CountingInputStream is partially synchronized - Key: IO-201 URL: https://issues.apache.org/jira/browse/IO-201 Project: Commons IO Issue Type: Bug Components: Filters Affects Versions: 1.4 Reporter: Sebb CountingInputStream is only partially synchronized. The count is not synchronized when it is updated in read operations, so is not guaranteed to be published correctly The synchronization could be removed without loss of functionality. Not sure it makes sense to share a stream between threads anyway, as the underlying stream is unlikely to be thread-safe. If only one thread reads the stream, then the count field could be made volatile. This would allow other threads to read the count safely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-201) CountingInputStream/CountingOutputStream only partially synchronized
[ https://issues.apache.org/jira/browse/IO-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-201: Summary: CountingInputStream/CountingOutputStream only partially synchronized (was: CountingInputStream is partially synchronized) > CountingInputStream/CountingOutputStream only partially synchronized > > > Key: IO-201 > URL: https://issues.apache.org/jira/browse/IO-201 > Project: Commons IO > Issue Type: Bug > Components: Filters >Affects Versions: 1.4 >Reporter: Sebb > > CountingInputStream is only partially synchronized. > The count is not synchronized when it is updated in read operations, so is > not guaranteed to be published correctly > The synchronization could be removed without loss of functionality. > Not sure it makes sense to share a stream between threads anyway, as the > underlying stream is unlikely to be thread-safe. > If only one thread reads the stream, then the count field could be made > volatile. > This would allow other threads to read the count safely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-201) CountingInputStream is partially synchronized
[ https://issues.apache.org/jira/browse/IO-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689490#action_12689490 ] Sebb commented on IO-201: - Same applies to CountingOutputStream > CountingInputStream is partially synchronized > - > > Key: IO-201 > URL: https://issues.apache.org/jira/browse/IO-201 > Project: Commons IO > Issue Type: Bug > Components: Filters >Affects Versions: 1.4 >Reporter: Sebb > > CountingInputStream is only partially synchronized. > The count is not synchronized when it is updated in read operations, so is > not guaranteed to be published correctly > The synchronization could be removed without loss of functionality. > Not sure it makes sense to share a stream between threads anyway, as the > underlying stream is unlikely to be thread-safe. > If only one thread reads the stream, then the count field could be made > volatile. > This would allow other threads to read the count safely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-55) CpioArchiveEntry ignores invalid modes
[
https://issues.apache.org/jira/browse/COMPRESS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689501#action_12689501
]
Sebb commented on COMPRESS-55:
--
Further investigation shows that the test file *does* have in it.
The file (bla.cpio) is a temporary archive created by the test case.
It looks like the problem may be that the CpioArchiveEntry class initialises
the mode to -1.
I can get the test cases to pass by:
1) Allowing setMode(0)
2) defaulting mode to 0 rather than -1.
But I'm not sure that this is the correct approach - does 0 make sense as a
mode?
Perhaps only for the trailer, in which case using a default of 0, and
disallowing setMode(0) would make more sense.
[The finish() method would not need to call setMode(0) if the default was 0]
Also, I suspect the "mtime" field should be initialised to 0 rather than -1.
> CpioArchiveEntry ignores invalid modes
> --
>
> Key: COMPRESS-55
> URL: https://issues.apache.org/jira/browse/COMPRESS-55
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Sebb
>
> CpioArchiveEntry has the following code:
> {code}
> default:
> // FIXME: testCpioUnarchive fails if I change the line to
> // actually throw the excpetion
> new IllegalArgumentException("Unknown mode (full mode: " + mode
> + ", masked mode: " + (mode & S_IFMT));
> }
> {code}
> As the comment says, rejecting invalid modes causes test failures.
> These appear to be caused by the code
> {bq}this.cpioEntry.setMode(0);
> in the method CpioArchiveOutputStream.finish()
> Is a mode of 0 allowed? If so, then setMode needs to allow it, otherwise the
> method call needs to change to something else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COMPRESS-55) CpioArchiveEntry ignores invalid modes
[
https://issues.apache.org/jira/browse/COMPRESS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689501#action_12689501
]
Sebb edited comment on COMPRESS-55 at 3/26/09 8:00 AM:
---
Further investigation shows that the test file *does* have in it.
The file (bla.cpio) is a temporary archive created by the test case.
It looks like the problem may be that the CpioArchiveEntry class initialises
the mode to -1.
I can get the test cases to pass by:
1) Allowing setMode(0)
2) defaulting mode to 0 rather than -1.
But I'm not sure that this is the correct approach - does 0 make sense as a
mode?
Perhaps only for the trailer, in which case using a default of 0 would make
more sense.
The finish() method would not need to call setMode(0) if the default were 0.
However, when reading a trailer the mode will be read as 0.
I suppose it might be worth throwing an Exception if the mode is zero but the
record is not the trailer record.
Also, I suspect the "mtime" field should be initialised to 0 rather than -1.
was (Author: s...@apache.org):
Further investigation shows that the test file *does* have in it.
The file (bla.cpio) is a temporary archive created by the test case.
It looks like the problem may be that the CpioArchiveEntry class initialises
the mode to -1.
I can get the test cases to pass by:
1) Allowing setMode(0)
2) defaulting mode to 0 rather than -1.
But I'm not sure that this is the correct approach - does 0 make sense as a
mode?
Perhaps only for the trailer, in which case using a default of 0, and
disallowing setMode(0) would make more sense.
[The finish() method would not need to call setMode(0) if the default was 0]
Also, I suspect the "mtime" field should be initialised to 0 rather than -1.
> CpioArchiveEntry ignores invalid modes
> --
>
> Key: COMPRESS-55
> URL: https://issues.apache.org/jira/browse/COMPRESS-55
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Sebb
>
> CpioArchiveEntry has the following code:
> {code}
> default:
> // FIXME: testCpioUnarchive fails if I change the line to
> // actually throw the excpetion
> new IllegalArgumentException("Unknown mode (full mode: " + mode
> + ", masked mode: " + (mode & S_IFMT));
> }
> {code}
> As the comment says, rejecting invalid modes causes test failures.
> These appear to be caused by the code
> {bq}this.cpioEntry.setMode(0);
> in the method CpioArchiveOutputStream.finish()
> Is a mode of 0 allowed? If so, then setMode needs to allow it, otherwise the
> method call needs to change to something else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COMPRESS-53) Remove src/main/resources
[ https://issues.apache.org/jira/browse/COMPRESS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMPRESS-53. -- Resolution: Fixed Tests work without this, so removed as suggested commit -m "COMPRESS-53 Remove src/main/resources" Committed revision 758683. > Remove src/main/resources > - > > Key: COMPRESS-53 > URL: https://issues.apache.org/jira/browse/COMPRESS-53 > Project: Commons Compress > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > > The src/main/resources directory currently contains a copy of the bla.zip > file from src/test/resources. The test file most likely should not be > included in the resulting commons-compress jar file. In fact it doesn't since > the commons-parent:11 parent POM overrides the default resources settings, > but it's still confusing to have the test file under src/main. > I would simply remove the entire src/main/resources directory as we're not > using it for anything and the current Maven settings won't use the directory > in any case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-246) Simplex Method Implementation
[ https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689539#action_12689539 ] Ben McCann commented on MATH-246: - That constructor was made so that constraints such as x + 2y <= 3x + 4y could be expressed instead of just scalars on the right hand side (x + 2y <= 9). The user doesn't have to care about the implementation details which cause one side to be subtracted from the other, but only needs to know how to express their constraint. I actually would propose a different change to the constructor, which would be to change it to: public LinearEquation(RealVector leftHandSide, double lhsConstantTerm, Relationship relationship, RealVector rightHandSide, double rhsConstantTerm) That would make it more flexible and allow for constraints such as x + 2y + 7 <= 3x + 4y + 6 which I originally overlooked. You're correct that the user could do this him/herself, but it seems a common use case (one I will be using frequently to say the least), so I thought it wise to provide the extra convenience. And perhaps adding some JavaDocs would clear up any potential confusion that I had not envisioned: /** * @param leftHandSide The coefficients of the linear expression on the left hand side of the constraint * @param lhsConstantTerm The constant term of the linear expression on the left hand side of the constraint * @param relationship The type of (in)equality used in the constraint * @param rightHandSide The coefficients of the linear expression on the right hand side of the constraint * @param rhsConstantTerm The constant term of the linear expression on the right hand side of the constraint */ > Simplex Method Implementation > - > > Key: MATH-246 > URL: https://issues.apache.org/jira/browse/MATH-246 > Project: Commons Math > Issue Type: New Feature >Reporter: Benjamin McCann >Assignee: Luc Maisonobe > Fix For: 2.0 > > Attachments: newfiles.zip > > > I've created an implementation of the Simplex algorithm for optimizing > systems of constrained linear equations that I'd like to contribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-246) Simplex Method Implementation
[ https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689550#action_12689550 ] Luc Maisonobe commented on MATH-246: This is fine, thanks. I'll check it in with the appropriate explanation. > Simplex Method Implementation > - > > Key: MATH-246 > URL: https://issues.apache.org/jira/browse/MATH-246 > Project: Commons Math > Issue Type: New Feature >Reporter: Benjamin McCann >Assignee: Luc Maisonobe > Fix For: 2.0 > > Attachments: newfiles.zip > > > I've created an implementation of the Simplex algorithm for optimizing > systems of constrained linear equations that I'd like to contribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-54) Add 7zip or RAR archive support
[ https://issues.apache.org/jira/browse/COMPRESS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689547#action_12689547 ] Christian Grobmeier commented on COMPRESS-54: - The 7zip SDK is in the public domain - i guess its compatible with asl, is it? http://www.7-zip.org/sdk.html The java impl is not a stream, but it feels like it is possible to take those classes and write streaming classes. > Add 7zip or RAR archive support > --- > > Key: COMPRESS-54 > URL: https://issues.apache.org/jira/browse/COMPRESS-54 > Project: Commons Compress > Issue Type: New Feature > Environment: N/A >Reporter: Tim Pinet >Priority: Minor > Original Estimate: 30h > Remaining Estimate: 30h > > Has anyone looked into adding support for 7zip and RAR file types? Using the > j7zip and junrar libraries I was able to get a rough protoype working with > commons-compress but only with extract support for RAR (due to licencing > issues). Also, my prototype performance is poor so I definately need to > improve it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-55) CpioArchiveEntry ignores invalid modes
[
https://issues.apache.org/jira/browse/COMPRESS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689551#action_12689551
]
Christian Grobmeier commented on COMPRESS-55:
-
Here is the original dcos for the mode:
The mode specifies both the regular permissions and the file type. It
consists of several bit fields as follows:
017 This masks the file type bits.
014 File type value for sockets.
012 File type value for symbolic links. For symbolic links,
the link body is stored as file data.
010 File type value for regular files.
006 File type value for block special devices.
004 File type value for directories.
002 File type value for character special devices.
001 File type value for named pipes or FIFOs.
0004000 SUID bit.
0002000 SGID bit.
0001000 Sticky bit. On some systems, this modifies the behavior
of executables and/or directories.
777 The lower 9 bits specify read/write/execute permissions
for world, group, and user following standard POSIX con-
ventions.
This tells me, that 0 is not correct since it is not described in the above.
But I am unsure about this. If defaulting, I would do something for regular
files and 777 or something like that
> CpioArchiveEntry ignores invalid modes
> --
>
> Key: COMPRESS-55
> URL: https://issues.apache.org/jira/browse/COMPRESS-55
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Sebb
>
> CpioArchiveEntry has the following code:
> {code}
> default:
> // FIXME: testCpioUnarchive fails if I change the line to
> // actually throw the excpetion
> new IllegalArgumentException("Unknown mode (full mode: " + mode
> + ", masked mode: " + (mode & S_IFMT));
> }
> {code}
> As the comment says, rejecting invalid modes causes test failures.
> These appear to be caused by the code
> {bq}this.cpioEntry.setMode(0);
> in the method CpioArchiveOutputStream.finish()
> Is a mode of 0 allowed? If so, then setMode needs to allow it, otherwise the
> method call needs to change to something else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMPRESS-47) Make ZiparchiveInputStream support as much of the zip package as possible
[ https://issues.apache.org/jira/browse/COMPRESS-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-47: --- Fix Version/s: (was: 1.1) 1.0 > Make ZiparchiveInputStream support as much of the zip package as possible > - > > Key: COMPRESS-47 > URL: https://issues.apache.org/jira/browse/COMPRESS-47 > Project: Commons Compress > Issue Type: Improvement >Reporter: Stefan Bodewig > Fix For: 1.0 > > > Copying something I sent to the dev list: > > Generally speaking the InputStream metaphor doesn't work for ZIP > > archives. > > A ZIP archive contains what is called "central directory" at the end > > of the archive. This is the only authoritative source telling you > > what is inside that archive. > > Before the central directory there are the actualy contents (among > > other things). For each entry you get a local file header describing > > the entry (duplicating information from the central directory) and the > > actual contents. The central directory contains a pointer to the > > local file data. > > java.util.ZipInputStream reads the stream in sequence and creates > > ZipEntries as it finds local file information. > > ZipFile (our, not the one in java.util.zip - I don't know what the > > later does) reads the archve from the back and parses the central > > directory to see what is inside the archive. > > It is not uncommon for archiver to "update" existing archives by > > adding new local file data at the end and rewrite the central > > directory without removing the old local file data. In such a case > > java.util.ZipInputStream will find entries that shouldn't be there or > > worse old data for updated entries. > Having said that, the only alternative for people who really only have a > stream and > not a file is java.util.ZipInputStream and we cn at least do better than that. > We need a ZipArchiveInputStream that shares the broken "if there is local > file data > there is a ZipArchiveEntry" logic with ZipInputStream but uses the data > parsing > code of ZipFile to provide all the benefits of encoding support, access to > external > attributes and parsed extra fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-55) CpioArchiveEntry ignores invalid modes
[
https://issues.apache.org/jira/browse/COMPRESS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689605#action_12689605
]
Sebb commented on COMPRESS-55:
--
I've just created some test files on the people host (7.1-STABLE FreeBSD).
In the case of the 'bin' 'newc' and 'crc' formats, the TRAILER record has a
link count of 1, namesize 10, and all the other fields are 0.
So I think the defaults in the CpioArchiveEntry should also be set to 0.
> CpioArchiveEntry ignores invalid modes
> --
>
> Key: COMPRESS-55
> URL: https://issues.apache.org/jira/browse/COMPRESS-55
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Sebb
>
> CpioArchiveEntry has the following code:
> {code}
> default:
> // FIXME: testCpioUnarchive fails if I change the line to
> // actually throw the excpetion
> new IllegalArgumentException("Unknown mode (full mode: " + mode
> + ", masked mode: " + (mode & S_IFMT));
> }
> {code}
> As the comment says, rejecting invalid modes causes test failures.
> These appear to be caused by the code
> {bq}this.cpioEntry.setMode(0);
> in the method CpioArchiveOutputStream.finish()
> Is a mode of 0 allowed? If so, then setMode needs to allow it, otherwise the
> method call needs to change to something else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-55) CpioArchiveEntry ignores invalid modes
[
https://issues.apache.org/jira/browse/COMPRESS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689636#action_12689636
]
Sebb commented on COMPRESS-55:
--
I've changed the default header values to zero:
URL: http://svn.apache.org/viewvc?rev=758837&view=rev
Log:
The default value for fileFormat must be chosen so checkNewFormat() and
checkOldFormat() both fail; -1 is not suitable.
Initialise other fields to zero as that is what the trailer needs.
Update Javadoc
The output stream no longer needs to set the mode:
URL: http://svn.apache.org/viewvc?rev=758838&view=rev
Log:
Mode defaults to zero, so no need to set it.
> CpioArchiveEntry ignores invalid modes
> --
>
> Key: COMPRESS-55
> URL: https://issues.apache.org/jira/browse/COMPRESS-55
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Sebb
>
> CpioArchiveEntry has the following code:
> {code}
> default:
> // FIXME: testCpioUnarchive fails if I change the line to
> // actually throw the excpetion
> new IllegalArgumentException("Unknown mode (full mode: " + mode
> + ", masked mode: " + (mode & S_IFMT));
> }
> {code}
> As the comment says, rejecting invalid modes causes test failures.
> These appear to be caused by the code
> {bq}this.cpioEntry.setMode(0);
> in the method CpioArchiveOutputStream.finish()
> Is a mode of 0 allowed? If so, then setMode needs to allow it, otherwise the
> method call needs to change to something else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-55) CpioArchiveEntry ignores invalid modes
[
https://issues.apache.org/jira/browse/COMPRESS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689647#action_12689647
]
Sebb commented on COMPRESS-55:
--
Fixed for Input as well:
URL: http://svn.apache.org/viewvc?rev=758846&view=rev
Log:
COMPRESS-55 Don't attempt to set mode zero. Print error if mode 0 found not in
trailer.
Just need to decide if the stacktrace should become a thrown Exception.
> CpioArchiveEntry ignores invalid modes
> --
>
> Key: COMPRESS-55
> URL: https://issues.apache.org/jira/browse/COMPRESS-55
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Sebb
>
> CpioArchiveEntry has the following code:
> {code}
> default:
> // FIXME: testCpioUnarchive fails if I change the line to
> // actually throw the excpetion
> new IllegalArgumentException("Unknown mode (full mode: " + mode
> + ", masked mode: " + (mode & S_IFMT));
> }
> {code}
> As the comment says, rejecting invalid modes causes test failures.
> These appear to be caused by the code
> {bq}this.cpioEntry.setMode(0);
> in the method CpioArchiveOutputStream.finish()
> Is a mode of 0 allowed? If so, then setMode needs to allow it, otherwise the
> method call needs to change to something else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COMPRESS-57) CpioArchiveEntry.fileFormat and headerSize should be immutable fields, only set on construction
CpioArchiveEntry.fileFormat and headerSize should be immutable fields, only set on construction --- Key: COMPRESS-57 URL: https://issues.apache.org/jira/browse/COMPRESS-57 Project: Commons Compress Issue Type: Improvement Reporter: Sebb CpioArchiveEntry.fileFormat and headerSize should be immutable fields, only set on construction. It does not make sense to change these values once set. Removing the protected set method would simplify other code. Probably also makes sense to add isFormatNew() / isFormatOld() methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (BEANUTILS-343) With ArrayConverter, need example on how to convert any array to string!
With ArrayConverter, need example on how to convert any array to string! Key: BEANUTILS-343 URL: https://issues.apache.org/jira/browse/BEANUTILS-343 Project: Commons BeanUtils Issue Type: Wish Components: ConvertUtils & Converters Affects Versions: 1.8.0-BETA Environment: Windows XP Reporter: Colbert Philippe org.apache.commons.beanutils.converters.ArrayConverter The JavaDoc of class ArrayConverter gives a fine example on how to parse a string to read an array instance. The same documentation also says that the other direction is possible, that is from array object into string form. However, I can't figure out how to do that (from array object into string form). Can somebody give me a code example (similar to the one given with class ArrayConvert) on how to covert a array object into string form? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-246) Simplex Method Implementation
[ https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689736#action_12689736 ] Luc Maisonobe commented on MATH-246: The contribution has been checked in subversion repository as of r758920. I'm not sure I have done it right, in fact I suspect either I blew something or did not understand the meaning of the output value of the solver. I thought it returned both the optimal point (x1, x2 ..., xn) and the value of the objective function at this point. While adapting signatures and organization to be consistent with the rest of the optimization framework, I had the value of the objective function computed directly by the new method LinearObjectiveFunction.getValue(). The SimplexSolverTest.testLargeModel failed when checking this value. Before all my changes it returned 7518, after my changes it returns 13366. However, the values of all variables are good and if I compute the value in the old code as in the new code, I also get 13366. So I don't understand what this 7518 meant. One puzzling fact is that for some toy problem with two variables and two inequality constraints, both computation methods (the old one and the new one) gave identical results. Could you check this and explain what I blew ? > Simplex Method Implementation > - > > Key: MATH-246 > URL: https://issues.apache.org/jira/browse/MATH-246 > Project: Commons Math > Issue Type: New Feature >Reporter: Benjamin McCann >Assignee: Luc Maisonobe > Fix For: 2.0 > > Attachments: newfiles.zip > > > I've created an implementation of the Simplex algorithm for optimizing > systems of constrained linear equations that I'd like to contribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-343) With ArrayConverter, need example on how to convert any array to string!
[ https://issues.apache.org/jira/browse/BEANUTILS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689784#action_12689784 ] Niall Pemberton commented on BEANUTILS-343: --- See http://tinyurl.com/cv2w7q but please ask questions on the mailing list : http://commons.apache.org/beanutils/mail-lists.html > With ArrayConverter, need example on how to convert any array to string! > > > Key: BEANUTILS-343 > URL: https://issues.apache.org/jira/browse/BEANUTILS-343 > Project: Commons BeanUtils > Issue Type: Wish > Components: ConvertUtils & Converters >Affects Versions: 1.8.0-BETA > Environment: Windows XP >Reporter: Colbert Philippe > > org.apache.commons.beanutils.converters.ArrayConverter > The JavaDoc of class ArrayConverter gives a fine example on how to parse a > string to read an array instance. The same documentation also says that the > other direction is possible, that is from array object into string form. > However, I can't figure out how to do that (from array object into string > form). > Can somebody give me a code example (similar to the one given with class > ArrayConvert) on how to covert a array object into string form? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-246) Simplex Method Implementation
[ https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin McCann updated MATH-246: - Attachment: SimplexSolverTest.patch SimplexTableau.patch Hi Luc, What you did was fine. It exposed a bug, which I've attached a patch for. In the large test, there were multiple variables that could have taken a given value. For example, when we solved the problem let's say it turned out that one of two cases could be true: x2 = 0 and x3 = 49 x2 = 49 and x3 = 0 In this ambiguous case, I was setting x2 and x3 to 49. The patch makes it so that we just choose the first variable when settings its value from the solution. > Simplex Method Implementation > - > > Key: MATH-246 > URL: https://issues.apache.org/jira/browse/MATH-246 > Project: Commons Math > Issue Type: New Feature >Reporter: Benjamin McCann >Assignee: Luc Maisonobe > Fix For: 2.0 > > Attachments: newfiles.zip, SimplexSolverTest.patch, > SimplexTableau.patch > > > I've created an implementation of the Simplex algorithm for optimizing > systems of constrained linear equations that I'd like to contribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
