[jira] [Updated] (SANSELAN-64) Sanselan 0.97 can't read TIFF file without tag "Samples Per Pixel"
[
https://issues.apache.org/jira/browse/SANSELAN-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
VVD updated SANSELAN-64:
Summary: Sanselan 0.97 can't read TIFF file without tag "Samples Per Pixel"
(was: Sanselat 0.97 can't read TIFF file without tag "Samples Per Pixel")
> Sanselan 0.97 can't read TIFF file without tag "Samples Per Pixel"
> --
>
> Key: SANSELAN-64
> URL: https://issues.apache.org/jira/browse/SANSELAN-64
> Project: Commons Sanselan
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 0.97
> Environment: Any
>Reporter: VVD
> Fix For: 1.0
>
>
> {code:title=Test.java|borderStyle=solid}
> package test;
> import ...;
> public class Test {
> public static void main (String[] args) {
> File fin = new File("/file.tif");
> File fout = new File("/file.png");
> try {
> Map params = new Hashtable();
> BufferedImage image = Sanselan.getBufferedImage(fin);
> Sanselan.writeImage(image, fout,
> ImageFormat.IMAGE_FORMAT_PNG, new Hashtable());
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> {code}
> org.apache.sanselan.ImageReadException: Missing expected field: 277 (0x115:
> Samples Per Pixel):
> at
> org.apache.sanselan.formats.tiff.TiffDirectory.findField(TiffDirectory.java:186)
> at
> org.apache.sanselan.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:463)
> at
> org.apache.sanselan.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:163)
> at
> org.apache.sanselan.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:441)
> at org.apache.sanselan.Sanselan.getBufferedImage(Sanselan.java:1264)
> at org.apache.sanselan.Sanselan.getBufferedImage(Sanselan.java:1231)
> at test.Test.main(Test.java:24)
> 24 is line: "BufferedImage image = Sanselan.getBufferedImage(fin);"
> I look at sources and see that TIFF_TAG_SAMPLES_PER_PIXEL is mandatory tag:
> "int samplesPerPixel = directory.findField(TIFF_TAG_SAMPLES_PER_PIXEL,
> *true*).getIntValue();"
> Why?
> ImageMagick simple show warning and convert it correctly:
> Unknown field with tag 32309 (0x7e35) encountered. `TIFFReadDirectory' @
> warning/tiff.c/TIFFWarnings/761.
> Unknown field with tag 32950 (0x80b6) encountered. `TIFFReadDirectory' @
> warning/tiff.c/TIFFWarnings/761.
> KDE applications (gwenview, okular, kolourpaint) show warning and open too:
> TIFFReadDirectory: Warning, Unknown field with tag 32309 (0x7e35) encountered.
> TIFFReadDirectory: Warning, Unknown field with tag 32950 (0x80b6) encountered.
> Do I need to check not released versions (from sources)?
> Also TIFF compression 4 isn't supported, but I saw Issue that Sanselat 1.0 is
> support it, but 1.0 isn't released yet.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-768) org.apache.commons.math3.analysis.solvers.LaguerreSolver.ComplexSolver is private
[ https://issues.apache.org/jira/browse/MATH-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-768: Priority: Minor (was: Major) Fix Version/s: 3.1 Issue Type: Wish (was: Bug) As I've explained on the "user" ML, the removal was intentional. It would be helpful if you would open a discussion on the "dev" ML, that would lead to adopting a design for the complex solvers (such as what should be the API, how to name the interface and classes, in which those should belong, ...) > org.apache.commons.math3.analysis.solvers.LaguerreSolver.ComplexSolver is > private > - > > Key: MATH-768 > URL: https://issues.apache.org/jira/browse/MATH-768 > Project: Commons Math > Issue Type: Wish >Affects Versions: 3.0 >Reporter: Lance Finney >Priority: Minor > Fix For: 3.1 > > > We used LaguerreSolver.solveAll() in version 2.1, but we never upgraded to > 2.2. As such, we didn't notice that it was deprecated in that release. > Now that 3.0 is out, we want to upgrade, but that method has been completely > removed. > Interestingly, the logic is still there in the library in an inner class: > org.apache.commons.math3.analysis.solvers.LaguerreSolver.ComplexSolver. > Unfortunately for us, though, ComplexSolver is now private. So, for us as > users, we've lost access to a useful algorithm that is still in the library. > Please re-enable access to this useful algorithm that proves complex roots of > polynomial formulae. The simplest approach might be to make > LaguerreSolver.ComplexSolver public, but perhaps another approach would be > considered better design. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-53) Allow to always enclose printed values into quotes
Allow to always enclose printed values into quotes -- Key: CSV-53 URL: https://issues.apache.org/jira/browse/CSV-53 Project: Commons CSV Issue Type: Improvement Components: Printer Reporter: Emmanuel Bourg Fix For: 1.x The printer encloses the values into quotes only if it contains a special character like a field separator or a line separator. However some applications expect the values to always be enclosed into quotes. It's necassary to be able to control how the quotes are added, either always or as needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-52) Keep track of record numbers
Keep track of record numbers Key: CSV-52 URL: https://issues.apache.org/jira/browse/CSV-52 Project: Commons CSV Issue Type: Improvement Components: Parser Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.x The parser is able to return the current line number of the file, it should also be able to return the record number. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-51) Support unicode line separators
Support unicode line separators --- Key: CSV-51 URL: https://issues.apache.org/jira/browse/CSV-51 Project: Commons CSV Issue Type: Improvement Components: Parser Reporter: Emmanuel Bourg Assignee: Emmanuel Bourg Priority: Minor Fix For: 1.x CSVParser doesn't recognizes the Unicode characters U+2028 (LINE SEPARATOR), U+2029 (PARAGRAPH SEPARATOR) and U+0085 (NEXT LINE) as line separators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226902#comment-13226902
]
Simone Tripodi commented on SANDBOX-404:
great, thanks a lot!!!
instead of enjoying vacations, can you please apply the same change on the
branch? It would simplify the future merge, if accepted.
TIA, all the best!
-Simo
PS I was obviously joking ;)
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_FromMonoidToAddition.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226898#comment-13226898 ] Emmanuel Bourg commented on CSV-43: --- It's less efficient than a direct instantiation, but that doesn't make the API inefficient. The critical part is the parsing, concerns about the efficiency should be focused on this part of the code. I don't want to make the API more complex with an additional CSVFormatBuilder class or extra steps to define a format. This is quite similar to the design of the Guava API for example, such as the Joiner/Splitter classes. > CSVFormat fluent API is rather inefficient > -- > > Key: CSV-43 > URL: https://issues.apache.org/jira/browse/CSV-43 > Project: Commons CSV > Issue Type: Improvement >Reporter: Sebb > > The implementation of the CSVFormat fluent API is rather inefficient, as each > method invocation clones the original class instance. > Now that the fields are volatile, it would be possible to do away with the > clone() calls entirely. > This would mean that the format could be updated later. > If such usage is not desirable, then perhaps consider adding some kind of > "freeze" method to prevent further changes. > Or perhaps the parse() and format() methods could perform the freeze (e.g. > set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226892#comment-13226892
]
Claudio Squarcella commented on SANDBOX-404:
Hi Simone,
you were convincing :)
I just reverted that change and only committed the solution for the issue you
discovered ([see
r1299232|http://svn.apache.org/viewvc?view=revision&revision=1299232]).
Claudio
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_FromMonoidToAddition.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226888#comment-13226888 ] Sebb commented on CSV-43: - Yes, a builder would also work, and would allow the class to be truly immutable. However it would mean bigger changes to the API. A simpler fix would be to add a flag to reject further changes. Not immutable, but thread-safe since code uses volatile. Either fix would be fine by me. > CSVFormat fluent API is rather inefficient > -- > > Key: CSV-43 > URL: https://issues.apache.org/jira/browse/CSV-43 > Project: Commons CSV > Issue Type: Improvement >Reporter: Sebb > > The implementation of the CSVFormat fluent API is rather inefficient, as each > method invocation clones the original class instance. > Now that the fields are volatile, it would be possible to do away with the > clone() calls entirely. > This would mean that the format could be updated later. > If such usage is not desirable, then perhaps consider adding some kind of > "freeze" method to prevent further changes. > Or perhaps the parse() and format() methods could perform the freeze (e.g. > set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226880#comment-13226880 ] Oliver Heger commented on CSV-43: - Wouldn't this be a good candidate for the builder pattern (Bloch, Effective Java, item 2)? The nested Builder class implements the fluent interface and eventually creates an immutable instance of CSVFormat. Maybe, as an extension, the Builder could be seeded with an existing CSVFormat instance if a new instance is to be derived from an existing one. > CSVFormat fluent API is rather inefficient > -- > > Key: CSV-43 > URL: https://issues.apache.org/jira/browse/CSV-43 > Project: Commons CSV > Issue Type: Improvement >Reporter: Sebb > > The implementation of the CSVFormat fluent API is rather inefficient, as each > method invocation clones the original class instance. > Now that the fields are volatile, it would be possible to do away with the > clone() calls entirely. > This would mean that the format could be updated later. > If such usage is not desirable, then perhaps consider adding some kind of > "freeze" method to prevent further changes. > Or perhaps the parse() and format() methods could perform the freeze (e.g. > set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226862#comment-13226862 ] Sebb commented on CSV-43: - Yes, every fluent method creates a new instance. That seems very wasteful. > CSVFormat fluent API is rather inefficient > -- > > Key: CSV-43 > URL: https://issues.apache.org/jira/browse/CSV-43 > Project: Commons CSV > Issue Type: Improvement >Reporter: Sebb > > The implementation of the CSVFormat fluent API is rather inefficient, as each > method invocation clones the original class instance. > Now that the fields are volatile, it would be possible to do away with the > clone() calls entirely. > This would mean that the format could be updated later. > If such usage is not desirable, then perhaps consider adding some kind of > "freeze" method to prevent further changes. > Or perhaps the parse() and format() methods could perform the freeze (e.g. > set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226859#comment-13226859
]
Simone Tripodi commented on SANDBOX-404:
{quote}
Now, secondary issue: while looking for a solution I also noticed that
{{SpanningTree}} did not have a generic type for the type of weight operations
(i.e. the variable in {{MutableSpanningTree}} had explicit type {{Monoid}}).
So as a first attempt to fix the error I added {{WO}} as a generic type in
{{SpanningTree}} and modified all the classes using it.
{quote}
It is not an issue, it is not broken in my branch (at least).
Why should it matter which type of Monoid the spanning trees are using, at APIs
level? They don't add any value to execute algorithms.
If you can take a look at the experimental branch, I simplified a lot also the
chain builders signatures, getting rid of useless generic types.
For what I've experienced, the only types that really matter are Vertices
{{V}}, Edges {{E}} and Weights {{W}} (and {{Graph}} and its specializations)
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_FromMonoidToAddition.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226848#comment-13226848 ] Emmanuel Bourg commented on CSV-43: --- What is the efficiency issue you are concerned with? Is it the creation of 5 instances to define a format? > CSVFormat fluent API is rather inefficient > -- > > Key: CSV-43 > URL: https://issues.apache.org/jira/browse/CSV-43 > Project: Commons CSV > Issue Type: Improvement >Reporter: Sebb > > The implementation of the CSVFormat fluent API is rather inefficient, as each > method invocation clones the original class instance. > Now that the fields are volatile, it would be possible to do away with the > clone() calls entirely. > This would mean that the format could be updated later. > If such usage is not desirable, then perhaps consider adding some kind of > "freeze" method to prevent further changes. > Or perhaps the parse() and format() methods could perform the freeze (e.g. > set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMMONSSITE-67) Add instructions for migrating Sandbox component to Proper
[ https://issues.apache.org/jira/browse/COMMONSSITE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226847#comment-13226847 ] Sebb commented on COMMONSSITE-67: - More updates to POM: Change commons.jira.componentid - pid can be found using JIRA createIssue Change URLs Remove "Sandbox" from if necessary Update Gump: URL: http://svn.apache.org/viewvc?rev=1299111&view=rev Log: CSV moved to proper Modified: gump/metadata/project/commons-proper.xml gump/metadata/project/commons-sandbox.xml Update Continuum: - fix SVN URL > Add instructions for migrating Sandbox component to Proper > -- > > Key: COMMONSSITE-67 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-67 > Project: Commons All > Issue Type: Improvement >Reporter: Sebb > > Need proper documentation on migrating a Sandbox component. > Here's a summary of what I did for CSV recently. > Remove external link from trunks-sandbox > svn rename -m"CSV => proper" \ > https://svn.apache.org/repos/asf/commons/sandbox/csv/trunk \ > https://svn.apache.org/repos/asf/commons/proper/csv/trunk > Add external link to trunks-proper > Login to minotaur > Rename the site directory /www/commons.apache.org/sandbox/csv => > /www/commons.apache.org/csv > Edit /www/commons.apache.org/sandbox/.htaccess to add redirect > Create /www/commons.apache.org/csv/download_csv.cgi from an existing cgi file > (copy & rename) > Update commons-site: > - remove CSV entry from src/site/xdoc/sandbox/index.xml > - add CSV entry to src/site/site.xml, src/site/xdoc/index.xml, > src/site/xdoc/components.xml, src/site/xdoc/downloads/index.xml > - regenerate and deploy > Update CSV pom: > Change parent to normal commons-parent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMMONSSITE-68) new-sandbox-component.html file not linked from anywhere
new-sandbox-component.html file not linked from anywhere Key: COMMONSSITE-68 URL: https://issues.apache.org/jira/browse/COMMONSSITE-68 Project: Commons All Issue Type: Bug Reporter: Sebb There's a useful new-sandbox-component.html file about creating a new sandbox component, but it is not linked from anywhere. Perhaps belongs under http://commons.apache.org/sandbox/index.html ? Or under "General Information" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMMONSSITE-67) Add instructions for migrating Sandbox component to Proper
Add instructions for migrating Sandbox component to Proper -- Key: COMMONSSITE-67 URL: https://issues.apache.org/jira/browse/COMMONSSITE-67 Project: Commons All Issue Type: Improvement Reporter: Sebb Need proper documentation on migrating a Sandbox component. Here's a summary of what I did for CSV recently. Remove external link from trunks-sandbox svn rename -m"CSV => proper" \ https://svn.apache.org/repos/asf/commons/sandbox/csv/trunk \ https://svn.apache.org/repos/asf/commons/proper/csv/trunk Add external link to trunks-proper Login to minotaur Rename the site directory /www/commons.apache.org/sandbox/csv => /www/commons.apache.org/csv Edit /www/commons.apache.org/sandbox/.htaccess to add redirect Create /www/commons.apache.org/csv/download_csv.cgi from an existing cgi file (copy & rename) Update commons-site: - remove CSV entry from src/site/xdoc/sandbox/index.xml - add CSV entry to src/site/site.xml, src/site/xdoc/index.xml, src/site/xdoc/components.xml, src/site/xdoc/downloads/index.xml - regenerate and deploy Update CSV pom: Change parent to normal commons-parent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226818#comment-13226818
]
Claudio Squarcella commented on SANDBOX-404:
Hi,
I found it. All the above errors were caused by the tests using null weight
operations, while the compiler expects an explicit type. So as a workaround I
just added casts to existing types: see the example below.
Before:
{code}
findShortestPath( graph ).from( a ).to( b ).applyingDijkstra( null );
{code}
After:
{code}
findShortestPath( graph ).from( a ).to( b ).applyingDijkstra(
(DoubleWeightBaseOperations) null );
{code}
Now, secondary issue: while looking for a solution I also noticed that
{{SpanningTree}} did not have a generic type for the type of weight operations
(i.e. the variable in {{MutableSpanningTree}} had explicit type {{Monoid}}).
So as a first attempt to fix the error I added {{WO}} as a generic type in
{{SpanningTree}} and modified all the classes using it.
Is it ok if I commit both changes together? (and since we're here, I can also
do the same for {{InMemoryWeightedPath}} that still uses {{Monoid}}).
Claudio
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_FromMonoidToAddition.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226809#comment-13226809
]
Claudio Squarcella commented on SANDBOX-404:
Hi Simone,
thanks for the notice. Working on it now!
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_FromMonoidToAddition.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
