[jira] [Commented] (MATH-811) Improve event detection by selecting g function slope
[ https://issues.apache.org/jira/browse/MATH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468379#comment-13468379 ] Yannick TANGUY commented on MATH-811: - Your idea seems interesting, but I think it depends on how users already handle event detection. If most of them won't use the slope selection, maybe an extended interface is better, or an abstract class (like in OREKIT events package), so that these users don't have to implement this method. But if there are enough users who can be interested in the new features, I think it must be implemented in EventHandler interface, and users will have to adapt their code. In the second hypothesis, I understand it will have to wait for 4.0. Anyway, what's really important for us is to have this feature now (and it's ok, our version of Commons Math implement it), to identify precisely the differences between our version and the official version (snapshot or a released version) and then, to know approximatively when this feature could be integrated (Commons Math roadmap). By now, this discussion has enabled to improve the implementation, clarify the use of event detection : that's a good point ! And when you'll have time to look further into it, we can discuss again to find a more elegant solution (if any) and integrate it. Improve event detection by selecting g function slope - Key: MATH-811 URL: https://issues.apache.org/jira/browse/MATH-811 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Yannick TANGUY Attachments: JIRA-811_slope_selection.patch, JIRA-811_slope_selection_V2.patch, JIRA-811_slope_selection_V3.patch, JIRA-811_slope_selection_V3_with_spaces.patch, JIRA-811_slope_selection_with_spaces.patch We would like to select g function slope in CommonsMath event detection feature. This would improve event detection for the final user (the possibility to ignore some events, and less computation time) and also correct a bug found while using OREKIT (see https://www.orekit.org/forge/issues/104) in our applications. The modification consists in adding a method (getSlopeSelection() : int) in EventHandler, and modifying one conditionnal in the method evaluateStep (class EventState). We can provide modified code and unitary tests for this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirko Raner updated CODEC-158:
--
Attachment: CODEC-158.patch
Attached are the modifications I had in mind to address this. Please let me
know if you have any questions or improvements.
There is already a class called BinaryCodec in package
org.apache.commons.codec.binary. The new BinaryCodec interface in
org.apache.commons.codec may be confused with this existing class. In the
patch, the naming is consistent (i.e. StringEncoder+StringDecoder-StringCodec
and BinaryEncoder+BinaryDecoder-BinaryCodec) and the two types are
distinguishable by their package. If you feel this could be a problem, please
make a suggestion as to how this can be resolved.
Thanks!
Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
and decoder
---
Key: CODEC-158
URL: https://issues.apache.org/jira/browse/CODEC-158
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.7
Reporter: Mirko Raner
Priority: Minor
Attachments: CODEC-158.patch
Original Estimate: 1h
Remaining Estimate: 1h
Currently, there are no common interfaces that extend both the encoder and
the decoder interfaces. This makes it hard to deal with a codec as a single
entity and requires separate treatment of encoder and decoder parts.
For example, let's say you want to develop a storage abstraction that uses an
encoding. Right now, you would need to write
class Storage
{
@Inject Encoder encoder;
@Inject Decoder decoder;
//...
}
In practice, encoder and decoder need to match, and most likely both encoder
and decoder would be bound to the same implementation, like Base64 or
URLCodec. Because of the lack of a common superinterface they need to be
specified separately. There are some classes like BaseNCodec that can be used
to unify some of the encoders and decoders, but they are too specific and
restrictive.
Ideally, I would like to write:
class Storage
{
@Inject Codec codec;
//...
}
Assuming that combined encoder/decoder classes like Base64 would implement
that Codec interface, this could be directly bound to a combined
encoder/decoder implementation.
It would be nice if these interfaces were added and the existing codec
classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
modified to implement these new interfaces.
I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468459#comment-13468459
]
Sebb commented on CODEC-158:
Thanks!
Does not seem to affect binary compatibility (according to Clirr).
However, it is very awkward having an interface and implementation of the
interface with the same class name, so I think the BinaryCodec interface needs
to be renamed.
Otherwise one has to do something like:
BinaryCodec bc = new org.apache.commons.codec.binary.BinaryCodec();
or
org.apache.commons.codec.BinaryCodec bc = new BinaryCodec();
or even
org.apache.commons.codec.BinaryCodec bc = new
org.apache.commons.codec.binary.BinaryCodec();
These are ugly and tricky to read.
Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
and decoder
---
Key: CODEC-158
URL: https://issues.apache.org/jira/browse/CODEC-158
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.7
Reporter: Mirko Raner
Priority: Minor
Attachments: CODEC-158.patch
Original Estimate: 1h
Remaining Estimate: 1h
Currently, there are no common interfaces that extend both the encoder and
the decoder interfaces. This makes it hard to deal with a codec as a single
entity and requires separate treatment of encoder and decoder parts.
For example, let's say you want to develop a storage abstraction that uses an
encoding. Right now, you would need to write
class Storage
{
@Inject Encoder encoder;
@Inject Decoder decoder;
//...
}
In practice, encoder and decoder need to match, and most likely both encoder
and decoder would be bound to the same implementation, like Base64 or
URLCodec. Because of the lack of a common superinterface they need to be
specified separately. There are some classes like BaseNCodec that can be used
to unify some of the encoders and decoders, but they are too specific and
restrictive.
Ideally, I would like to write:
class Storage
{
@Inject Codec codec;
//...
}
Assuming that combined encoder/decoder classes like Base64 would implement
that Codec interface, this could be directly bound to a combined
encoder/decoder implementation.
It would be nice if these interfaces were added and the existing codec
classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
modified to implement these new interfaces.
I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-393) DBCP to support database connection failover
Campbell created DBCP-393: - Summary: DBCP to support database connection failover Key: DBCP-393 URL: https://issues.apache.org/jira/browse/DBCP-393 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.4 Reporter: Campbell Priority: Critical Hello. Would it be possible for the DriverManagerConnectionFactory to accept a list or alternative database connection URL. With a possible maxRetry parameter, the suggestion is this improvement would allow for automatic fail over to a secondary database when a connection exception occurs. Let me know if this is a good candidate or if you have made thought of this already as it is standard behaviour in other managed datasources. Many thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EMAIL-120) attach(DataSource xx) doesn't close inputstream
mike bell created EMAIL-120: --- Summary: attach(DataSource xx) doesn't close inputstream Key: EMAIL-120 URL: https://issues.apache.org/jira/browse/EMAIL-120 Project: Commons Email Issue Type: Bug Affects Versions: 1.2 Environment: Windows 7, 64 bit Reporter: mike bell Basically I have code like shown below. message.attach(reports[1].getDatasource(), Report + new SimpleDateFormat(mmdd).format(new java.util.Date()) + . + selectedAttachment, selectedAttachment.toUpperCase() + version of report); Where the DataSource in question is a simple JAF FileDataSource. What I found [when I found files were not being cleaned up by my cleaner) 1. I can delete the backing file before calling this method 2. I cannot delete the backing file after calling this method. 3. Workaround uses the URL version of attachment. DataSource ds=reports[1].getDatasource(); FileDataSource fds=(FileDataSource) ds; URL url=fds.getFile().toURI().toURL(); /** * MJB: We don't use the DataSource directly (as we should) because of a bug in Commons Email * where it usually doesn't close the inputstream */ message.attach(url,Report + new SimpleDateFormat(mmdd).format(new java.util.Date()) + . + selectedAttachment, selectedAttachment.toUpperCase() + version of report); 4. I therefore assume the inputstream has been opened and never closed. 5. Same test after calling send() provides same results -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-437) [FTP] Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
[
https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Zhu updated VFS-437:
---
Attachment: (was: FtpFileObject_patch)
[FTP] Program crashes when StackOverFlow Exception happens from pulling a
softlinked directory that link to the directory that has the same name one
level above
-
Key: VFS-437
URL: https://issues.apache.org/jira/browse/VFS-437
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Environment: java version 1.7.0_02
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version
4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
Reporter: Jason
Priority: Blocker
Fix For: 2.1
With the setting below, StackOverFlow exceptions occur and server crashes
set the builder.setUserDirlsRoot (opt, true)
Attept to pull with:
ftp://root:password@ip:/Vol1
Vol directory has the following info
lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 - /Vol1
When it tries to look for the parent of the Vol1, it goes back to the same
Vol1, which causes a infinite loop that eventually creates stackoverflow
exception.
The problem is inside the doGetType() method in FtpFileObject
@Override
protected FileType doGetType()
throws Exception
{
// VFS-210
synchronized (getFileSystem())
{
if (this.fileInfo == null)
{
getInfo(false);
}
if (this.fileInfo == UNKNOWN)
{
return FileType.IMAGINARY;
}
else if (this.fileInfo.isDirectory())
{
return FileType.FOLDER;
}
else if (this.fileInfo.isFile())
{
return FileType.FILE;
}
else if (this.fileInfo.isSymbolicLink())
{
return getLinkDestination().getType();
}
}
throw new FileSystemException(vfs.provider.ftp/get-type.error,
getName());
}
It will keep hitting the else if (this.fileinfo.isSymbolicLink()) condition
and the fileinfo displayed is always the Vol1 under root directory.
Exception is shown below
java.lang.StackOverflowError
at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
[jira] [Updated] (VFS-437) [FTP] Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
[
https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Zhu updated VFS-437:
---
Attachment: (was: FtpFileObject_svndiff.htm)
[FTP] Program crashes when StackOverFlow Exception happens from pulling a
softlinked directory that link to the directory that has the same name one
level above
-
Key: VFS-437
URL: https://issues.apache.org/jira/browse/VFS-437
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Environment: java version 1.7.0_02
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version
4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
Reporter: Jason
Priority: Blocker
Fix For: 2.1
With the setting below, StackOverFlow exceptions occur and server crashes
set the builder.setUserDirlsRoot (opt, true)
Attept to pull with:
ftp://root:password@ip:/Vol1
Vol directory has the following info
lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 - /Vol1
When it tries to look for the parent of the Vol1, it goes back to the same
Vol1, which causes a infinite loop that eventually creates stackoverflow
exception.
The problem is inside the doGetType() method in FtpFileObject
@Override
protected FileType doGetType()
throws Exception
{
// VFS-210
synchronized (getFileSystem())
{
if (this.fileInfo == null)
{
getInfo(false);
}
if (this.fileInfo == UNKNOWN)
{
return FileType.IMAGINARY;
}
else if (this.fileInfo.isDirectory())
{
return FileType.FOLDER;
}
else if (this.fileInfo.isFile())
{
return FileType.FILE;
}
else if (this.fileInfo.isSymbolicLink())
{
return getLinkDestination().getType();
}
}
throw new FileSystemException(vfs.provider.ftp/get-type.error,
getName());
}
It will keep hitting the else if (this.fileinfo.isSymbolicLink()) condition
and the fileinfo displayed is always the Vol1 under root directory.
Exception is shown below
java.lang.StackOverflowError
at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
[jira] [Updated] (VFS-437) [FTP] Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
[
https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Tran updated VFS-437:
-
Attachment: VFS-437.diff
Proposed solution ( from Dennis )
[FTP] Program crashes when StackOverFlow Exception happens from pulling a
softlinked directory that link to the directory that has the same name one
level above
-
Key: VFS-437
URL: https://issues.apache.org/jira/browse/VFS-437
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Environment: java version 1.7.0_02
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version
4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
Reporter: Jason
Priority: Blocker
Fix For: 2.1
Attachments: VFS-437.diff
With the setting below, StackOverFlow exceptions occur and server crashes
set the builder.setUserDirlsRoot (opt, true)
Attept to pull with:
ftp://root:password@ip:/Vol1
Vol directory has the following info
lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 - /Vol1
When it tries to look for the parent of the Vol1, it goes back to the same
Vol1, which causes a infinite loop that eventually creates stackoverflow
exception.
The problem is inside the doGetType() method in FtpFileObject
@Override
protected FileType doGetType()
throws Exception
{
// VFS-210
synchronized (getFileSystem())
{
if (this.fileInfo == null)
{
getInfo(false);
}
if (this.fileInfo == UNKNOWN)
{
return FileType.IMAGINARY;
}
else if (this.fileInfo.isDirectory())
{
return FileType.FOLDER;
}
else if (this.fileInfo.isFile())
{
return FileType.FILE;
}
else if (this.fileInfo.isSymbolicLink())
{
return getLinkDestination().getType();
}
}
throw new FileSystemException(vfs.provider.ftp/get-type.error,
getName());
}
It will keep hitting the else if (this.fileinfo.isSymbolicLink()) condition
and the fileinfo displayed is always the Vol1 under root directory.
Exception is shown below
java.lang.StackOverflowError
at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
[jira] [Updated] (LANG-778) Add methods uuidToByteArray and byteArrayToUuid
[ https://issues.apache.org/jira/browse/LANG-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated LANG-778: Fix Version/s: 3.2 Summary: Add methods uuidToByteArray and byteArrayToUuid (was: Add ByteArrayUtils) Add methods uuidToByteArray and byteArrayToUuid --- Key: LANG-778 URL: https://issues.apache.org/jira/browse/LANG-778 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Joerg Schaible Assignee: Joerg Schaible Priority: Minor Fix For: 3.2 Attachments: LANG-778.diff Original Estimate: 8h Remaining Estimate: 8h ByteArrayUtils will currently contain only conversion methods between several types and an array of bytes. The functionality is similar to DataInput and DataOutput, but without the indirection of IO streams. As special type the utility class supports also conversion between UUID and byte array (memory layout as described in RFC 4122). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468711#comment-13468711 ] Gilles commented on MATH-867: - Thanks. The improved Javadoc is in revision 1393641. CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound. --- Key: MATH-867 URL: https://issues.apache.org/jira/browse/MATH-867 Project: Commons Math Issue Type: Bug Reporter: Frank Hess Fix For: 3.1 Attachments: MATH867_patch, Math867Test.java When fitting with bounds, the CMAESOptimizer fits finely near the lower bound and coarsely near the upper bound. This is because it internally maps the fitted parameter range into the interval [0,1]. The unit of least precision (ulp) between floating point numbers is much smaller near zero than near one. Thus, fits have much better resolution near the lower bound (which is mapped to zero) than the upper bound (which is mapped to one). I will attach a example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-801) Util for conversion between primitive types
[ https://issues.apache.org/jira/browse/LANG-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved LANG-801. - Resolution: Fixed Added with minor adjustment to naming conventions. Util for conversion between primitive types --- Key: LANG-801 URL: https://issues.apache.org/jira/browse/LANG-801 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Sebastien Riou Assignee: Joerg Schaible Priority: Minor Attachments: patch_Conversion.txt A utility class to convert data from one primitive type to another, in the most commonly used fashions (big endian/little endian byte order, lsb first or msb first). It also deals with arrays of primitive types and String containing hexadecimal numbers. Such conversions are needed when dealing with embedded software or hardware modeling/design. I attach a initial version which deals with the default encoding, the one which seems the most natural on the JVM: little endian byte ordering, and, within a byte, lsb first. I plan to implement the other encoding I need: - big endian, lsb first - big endian, msb first So far I implemented about half of the methods needed to cover the default encoding: - methods to convert a large data type into an array of a smaller data type (longToBytes for example) - methods to convert an array of a small data type into a larger data type (bytesToLong for example) The remaining half consist of the methods to convert from an array of a data type into an array of another data type (bytesToLongs, LongsToBytes) Once this is available for different encodings, the most useful part can be done: the bridge methods to convert from one encoding to another -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-778) Add methods uuidToByteArray and byteArrayToUuid
[ https://issues.apache.org/jira/browse/LANG-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved LANG-778. - Resolution: Fixed Added as methods to class Conversion that contains already all the conversions between bytes and longs. Add methods uuidToByteArray and byteArrayToUuid --- Key: LANG-778 URL: https://issues.apache.org/jira/browse/LANG-778 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Joerg Schaible Assignee: Joerg Schaible Priority: Minor Fix For: 3.2 Attachments: LANG-778.diff Original Estimate: 8h Remaining Estimate: 8h ByteArrayUtils will currently contain only conversion methods between several types and an array of bytes. The functionality is similar to DataInput and DataOutput, but without the indirection of IO streams. As special type the utility class supports also conversion between UUID and byte array (memory layout as described in RFC 4122). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
