[GitHub] commons-lang pull request: fix JsonToStringStyle
GitHub user jacktan1991 opened a pull request: https://github.com/apache/commons-lang/pull/66 fix JsonToStringStyle except number types and boolean type , all other types in java (char, String, Date etc.) should be `appendAsString`. + add method `appendDetail(StringBuffer buffer, String fieldName, char value)` to `JsonToStringStyle` + modify `appendDetail(StringBuffer buffer, String fieldName, Object value)` You can merge this pull request into a Git repository by running: $ git pull https://github.com/jacktan1991/commons-lang branch-3.4-fix-json-style Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/66.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #66 commit fc5fbc70f76e2e028435d145ea8d91dd10fe5daa Author: Jack <792626...@qq.com> Date: 2015-04-20T08:22:28Z add testChar and testDate Cases into JsonToStringStyleTest commit ed0fea128ad83d6c07367eea7bf2e24116fa5723 Author: Jack <792626...@qq.com> Date: 2015-04-20T08:34:59Z fix the JsonToStringStyle:except number types and boolean type , all other types in java (char, String, Date etc.) should be 'appendAsString' commit d2195f07a714b3e332d7c8feaf787858cc937023 Author: Jack Date: 2015-04-20T08:48:42Z Merge pull request #1 from jackiewhu/branch-3.4-fix-json-style Branch 3.4 fix json style --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-lang pull request: fix JsonToStringStyle
Github user jacktan1991 closed the pull request at: https://github.com/apache/commons-lang/pull/66 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-lang pull request: fix JsonToStringStyle
GitHub user jacktan1991 opened a pull request: https://github.com/apache/commons-lang/pull/67 fix JsonToStringStyle except number types and boolean type , all other types in java (char, String, Date etc.) should be `appendAsString`. add method `appendDetail(StringBuffer buffer, String fieldName, char value)` to `JsonToStringStyle` modify `appendDetail(StringBuffer buffer, String fieldName, Object value)` You can merge this pull request into a Git repository by running: $ git pull https://github.com/jacktan1991/commons-lang branch-3.4-fix-json-style Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/67.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #67 commit fc5fbc70f76e2e028435d145ea8d91dd10fe5daa Author: Jack <792626...@qq.com> Date: 2015-04-20T08:22:28Z add testChar and testDate Cases into JsonToStringStyleTest commit ed0fea128ad83d6c07367eea7bf2e24116fa5723 Author: Jack <792626...@qq.com> Date: 2015-04-20T08:34:59Z fix the JsonToStringStyle:except number types and boolean type , all other types in java (char, String, Date etc.) should be 'appendAsString' --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1658276 - in /commons/proper/csv/trunk: pom.xml src/test/java/org/apache/commons/csv/CSVBenchmark.java
Hello again,
I've had some time to look ad the JMH Benchmarks. What I see is, that the
build now issues a warning:
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for org.apache.commons:commons-csv:jar:1.1.1-SNAPSHOT
[WARNING] 'profiles.profile[benchmark].dependencies.dependency.systemPath'
for org.skife.kasparov:csv:jar should not point at files within the project
directory, ${basedir}/csv-1.0.jar will be unresolvable by dependent
projects @ line 432, column 23
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
Furthermore I can no longer run tests from within Intellij, because it can
not construct the class path for the JMH Benchmark class correctly. One
work around for this would be to create an additional source folder
"benchmark" and put the CSVBenchmark there.
WDYT?
Benedikt
2015-02-16 15:43 GMT+01:00 Ralph Goers :
> JMH is a tool used during the build. The source code for the product does
> not depend on it. See http://www.apache.org/legal/resolved.html#prohibited
> .
>
> Ralph
>
>
> > On Feb 15, 2015, at 2:23 AM, Benedikt Ritter wrote:
> >
> > 2015-02-09 2:40 GMT+01:00 sebb :
> >
> >> On 8 February 2015 at 23:47, wrote:
> >>> Author: ebourg
> >>> Date: Sun Feb 8 23:47:27 2015
> >>> New Revision: 1658276
> >>>
> >>> URL: http://svn.apache.org/r1658276
> >>> Log:
> >>> Added a JMH benchmark to compare the most commons CSV parsers
> >>
> >> -1
> >>
> >> This has broken the Continuum build.
> >>
> >> Also the JMH website says:
> >>
> >> "The recommended way to run a JMH benchmark is to use Maven to setup a
> >> standalone project that depends on the jar files of your application.
> >> This approach is preferred to ensure that the benchmarks are correctly
> >> initialized and produce reliable results. It is possible to run
> >> benchmarks from within an existing project, and even from within an
> >> IDE, however setup is more complex and the results are less reliable."
> >>
> >> Further, it's not clear to me what the JMH license is.
> >> It rather looks like GPL.
> >>
> >
> > +1 for this change in general. It's far superior to the manual benchmark
> we
> > had before.
> >
> > Regarding the problems mentioned by sebb:
> >
> > - Is the continuum build fixed already?
> > - if we add further functionality, we will eventually end up with a multi
> > module build that has modules like: core, beans, annotations, benchmarks.
> > For now we should follow KISS and simply add it to the project until
> > unresolvable problems show up.
> > - regarding the license issue: since log4j seems to use it, I think we
> are
> > on the save side. Maybe someone from the log4j team can comment (ping at
> > bodewig, ggregory)
> >
> >
> >>
> >>> Added:
> >>>
> >>
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVBenchmark.java
> >> (with props)
> >>> Modified:
> >>>commons/proper/csv/trunk/pom.xml
> >>>
> >>> Modified: commons/proper/csv/trunk/pom.xml
> >>> URL:
> >>
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/pom.xml?rev=1658276&r1=1658275&r2=1658276&view=diff
> >>>
> >>
> ==
> >>> --- commons/proper/csv/trunk/pom.xml (original)
> >>> +++ commons/proper/csv/trunk/pom.xml Sun Feb 8 23:47:27 2015
> >>> @@ -73,6 +73,12 @@ CSV files of various types.
> >>> The Apache Software Foundation
> >>>
> >>>
> >>> + Emmanuel Bourg
> >>> + ebourg
> >>> + ebo...@apache.org
> >>> + Apache
> >>> +
> >>> +
> >>> Gary Gregory
> >>> ggregory
> >>> ggreg...@apache.org
> >>> @@ -357,6 +363,112 @@ CSV files of various types.
> >>>
> >>>
> >>>
> >>> +
> >>> +
> >>> +
> >>> +
> >>> +
> >>> +
> >>> +
> >>> +
> >>> + benchmark
> >>> +
> >>> +
> >>> +
> >>> + org.openjdk.jmh
> >>> + jmh-core
> >>> + 1.5.2
> >>> + test
> >>> +
> >>> +
> >>> +
> >>> + org.openjdk.jmh
> >>> + jmh-generator-annprocess
> >>> + 1.5.2
> >>> + test
> >>> +
> >>> +
> >>> +
> >>> + genjava
> >>> + gj-csv
> >>> + 1.0
> >>> + test
> >>> +
> >>> +
> >>> +
> >>> +net.sourceforge.javacsv
> >>> +javacsv
> >>> +2.0
> >>> + test
> >>> +
> >>> +
> >>> +
> >>> + com.opencsv
> >>> + opencsv
> >>> + 3.1
> >>> + test
> >>> +
> >>> +
> >>> +
> >>> + net.sf.supercsv
> >>> + super-csv
> >>> + 2.2.1
> >>> +
> >>> +
> >>> +
> >>> +
Re: [COMMONSRDF] GroupID for incubation releases
On Thu, Apr 16, 2015 at 7:41 AM, Sergio Fernández wrote: > Hi, > > On Wed, Apr 15, 2015 at 12:30 PM, Reto Gmür wrote: > > > On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández > > wrote: > > > > > On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell > > > wrote: > > > > > > > > BlankNodes cannot be compared across different SPARQL queries. That > is > > > > a well known RDF issue, not just with SPARQL, and is not going to be > > > > solved by anything except bulk execution of a single query to get all > > > > of the BlankNodes back in a single query. > > > > > > > > > I think that's something where we all can agree, isn't it? > > > > > > > No, there is no need to get all of the blank-nodes (of the graph) back. > > It's enough to get the context (aka minimum self contained graph, aka > > symmetric concise bounded description), this is what impl.sparql in > > clerezza commons RDF does. That's why if we have to assign a string > > identifier to it this would have to be a strong digest of this context > > graph and an indicator of the position of the node within it. > > > I could understand that need, but i still think is a very concrete use > case. Therefore I'd prefer to keep the api contracts as they were, keeping > such concrete aspect up to each implementation. > > Is that something what we could agree on? > Not sure what the agreement would be. The API are being redefined. For example apparently there has been a "decision" somewhere (maybe on Github?) that BlankNode identity should no longer be scoped but depend exclusively on their ID. I've just presented two usecases where a BlankNode ID is problematic, as the BlankNode ID is not part of the RDF spec I suggest not to have it in the API, but as there seem to exist strong opinion to keep the BlankNode ID I've created COMMONSRDF-13 inviting to show some concrete code that benefits from having such an ID exposed, of course this would also allow me to show if this usecases can be rewritten without the exposed IDs. Cheers, Reto > > Thanks. > > Cheers, > > -- > Sergio Fernández > Partner Technology Manager > Redlink GmbH > m: +43 6602747925 > e: sergio.fernan...@redlink.co > w: http://redlink.co >
Re: svn commit: r1674710 - /commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java
Hello Gary,
I get the same errors, but none of them are related to missing close
tags.
I dont think that it is correct that javadoc8 cares about
xhtml, it checks for html. Thats why it disallows self closed tags.
But I guess it doesnt matter much we have so many javadoc styles anyway.
Gruss
Bernd
Am
Sun, 19 Apr 2015 20:53:20 -0700 schrieb Gary Gregory
:
> Javadoc 8 does not allow for XHTML tags to not be closed (in the
> default mode).
>
> When I run 'mvn clean site', I get, more of these errors and others:
>
> 9 errors
> 6 warnings
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 07:16 min
> [INFO] Finished at: 2015-04-19T20:33:23-07:00
> [INFO] Final Memory: 57M/386M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project commons-io: Error during page generation: Error rendering
> Maven report:
> [ERROR] Exit code: 1 -
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\CopyUtils.java:309:
> warning: no @param for encoding
> [ERROR] public static void copy(
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\CopyUtils.java:358:
> warning: no @param for encoding
> [ERROR] public static void copy(
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\FileCleaner.java:140:
> error: reference not found
> [ERROR] * {@link
> javax.servlet.ServletContextListener#contextDestroyed(javax.servlet.ServletContextEvent)}.
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\FileCleaner.java:33:
> error: reference not found
> [ERROR] * {@link
> javax.servlet.ServletContextListener#contextDestroyed(javax.servlet.ServletContextEvent)}
> or similar.
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\FileCleaningTracker.java:186:
> error: reference not found
> [ERROR] * {@link
> javax.servlet.ServletContextListener#contextDestroyed(javax.servlet.ServletContextEvent)}.
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\FileCleaningTracker.java:40:
> error: reference not found
> [ERROR] * {@link
> javax.servlet.ServletContextListener#contextDestroyed} or similar.
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\IOUtils.java:3069:
> warning: no @return
> [ERROR] public static byte[] readFully(final InputStream input, final
> int length) throws IOException {
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\BoundedReader.java:66:
> warning: no description for @throws
> [ERROR] * @throws IOException
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\BoundedReader.java:76:
> warning: no description for @throws
> [ERROR] * @throws IOException
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\BoundedReader.java:130:
> warning: no description for @throws
> [ERROR] * @throws IOException
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\BoundedReader.java:28:
> error: self-closing element not allowed
> [ERROR] *
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\UnixLineEndingInputStream.java:60:
> error: incorrect use of inline tag
> [ERROR] * @inheritDoc
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\UnixLineEndingInputStream.java:102:
> error: incorrect use of inline tag
> [ERROR] * @inheritDoc
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\WindowsLineEndingInputStream.java:62:
> error: incorrect use of inline tag
> [ERROR] * @inheritDoc
> [ERROR] ^
> [ERROR]
> C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\WindowsLineEndingInputStream.java:115:
> error: incorrect use of inline tag
> [ERROR] * @inheritDoc
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: "C:\Program
> Files\Java\jdk1.8.0_45\jre\..\bin\javadoc.exe" @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\vcs\svn\apache\commons\trunks-proper\io\target\site\apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please r
Re: svn commit: r1658276 - in /commons/proper/csv/trunk: pom.xml src/test/java/org/apache/commons/csv/CSVBenchmark.java
Hm... In Log4j, we have a separate Maven module for benchmarks, but we
already have a lot of modules in Log4j... I'm sure we do not want another
module for [cvs].
We have a source folder for tests already, a third one might require a lot
more configuration in the POM, I'm not sure. Isn't there a way to solve
this with the current project structure?
Gary
On Mon, Apr 20, 2015 at 5:27 AM, Benedikt Ritter wrote:
> Hello again,
>
> I've had some time to look ad the JMH Benchmarks. What I see is, that the
> build now issues a warning:
>
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.apache.commons:commons-csv:jar:1.1.1-SNAPSHOT
> [WARNING] 'profiles.profile[benchmark].dependencies.dependency.systemPath'
> for org.skife.kasparov:csv:jar should not point at files within the project
> directory, ${basedir}/csv-1.0.jar will be unresolvable by dependent
> projects @ line 432, column 23
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
>
> Furthermore I can no longer run tests from within Intellij, because it can
> not construct the class path for the JMH Benchmark class correctly. One
> work around for this would be to create an additional source folder
> "benchmark" and put the CSVBenchmark there.
>
> WDYT?
>
> Benedikt
>
> 2015-02-16 15:43 GMT+01:00 Ralph Goers :
>
> > JMH is a tool used during the build. The source code for the product does
> > not depend on it. See
> http://www.apache.org/legal/resolved.html#prohibited
> > .
> >
> > Ralph
> >
> >
> > > On Feb 15, 2015, at 2:23 AM, Benedikt Ritter
> wrote:
> > >
> > > 2015-02-09 2:40 GMT+01:00 sebb :
> > >
> > >> On 8 February 2015 at 23:47, wrote:
> > >>> Author: ebourg
> > >>> Date: Sun Feb 8 23:47:27 2015
> > >>> New Revision: 1658276
> > >>>
> > >>> URL: http://svn.apache.org/r1658276
> > >>> Log:
> > >>> Added a JMH benchmark to compare the most commons CSV parsers
> > >>
> > >> -1
> > >>
> > >> This has broken the Continuum build.
> > >>
> > >> Also the JMH website says:
> > >>
> > >> "The recommended way to run a JMH benchmark is to use Maven to setup a
> > >> standalone project that depends on the jar files of your application.
> > >> This approach is preferred to ensure that the benchmarks are correctly
> > >> initialized and produce reliable results. It is possible to run
> > >> benchmarks from within an existing project, and even from within an
> > >> IDE, however setup is more complex and the results are less reliable."
> > >>
> > >> Further, it's not clear to me what the JMH license is.
> > >> It rather looks like GPL.
> > >>
> > >
> > > +1 for this change in general. It's far superior to the manual
> benchmark
> > we
> > > had before.
> > >
> > > Regarding the problems mentioned by sebb:
> > >
> > > - Is the continuum build fixed already?
> > > - if we add further functionality, we will eventually end up with a
> multi
> > > module build that has modules like: core, beans, annotations,
> benchmarks.
> > > For now we should follow KISS and simply add it to the project until
> > > unresolvable problems show up.
> > > - regarding the license issue: since log4j seems to use it, I think we
> > are
> > > on the save side. Maybe someone from the log4j team can comment (ping
> at
> > > bodewig, ggregory)
> > >
> > >
> > >>
> > >>> Added:
> > >>>
> > >>
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVBenchmark.java
> > >> (with props)
> > >>> Modified:
> > >>>commons/proper/csv/trunk/pom.xml
> > >>>
> > >>> Modified: commons/proper/csv/trunk/pom.xml
> > >>> URL:
> > >>
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/pom.xml?rev=1658276&r1=1658275&r2=1658276&view=diff
> > >>>
> > >>
> >
> ==
> > >>> --- commons/proper/csv/trunk/pom.xml (original)
> > >>> +++ commons/proper/csv/trunk/pom.xml Sun Feb 8 23:47:27 2015
> > >>> @@ -73,6 +73,12 @@ CSV files of various types.
> > >>> The Apache Software Foundation
> > >>>
> > >>>
> > >>> + Emmanuel Bourg
> > >>> + ebourg
> > >>> + ebo...@apache.org
> > >>> + Apache
> > >>> +
> > >>> +
> > >>> Gary Gregory
> > >>> ggregory
> > >>> ggreg...@apache.org
> > >>> @@ -357,6 +363,112 @@ CSV files of various types.
> > >>>
> > >>>
> > >>>
> > >>> +
> > >>> +
> > >>> +
> > >>> +
> > >>> +
> > >>> +
> > >>> +
> > >>> +
> > >>> + benchmark
> > >>> +
> > >>> +
> > >>> +
> > >>> + org.openjdk.jmh
> > >>> + jmh-core
> > >>> + 1.5.2
> > >>> + test
> > >>> +
> > >>> +
> > >>> +
> > >>> +
Re: svn commit: r1658276 - in /commons/proper/csv/trunk: pom.xml src/test/java/org/apache/commons/csv/CSVBenchmark.java
Hello,
2015-04-20 17:08 GMT+02:00 Gary Gregory :
> Hm... In Log4j, we have a separate Maven module for benchmarks, but we
> already have a lot of modules in Log4j... I'm sure we do not want another
> module for [cvs].
>
I've started work on a Csv2BeanMapper, which could be a separate module...
>
> We have a source folder for tests already, a third one might require a lot
> more configuration in the POM, I'm not sure. Isn't there a way to solve
> this with the current project structure?
>
There are more issues IMHO. One has to manually download one of the
benchmark dependencies, because it is not available at maven central. I was
able to get my IDE to compile again, but we should integrate the download
into the build. And we should resolve the warnings which show up at the
start of the build.
B.
>
> Gary
>
> On Mon, Apr 20, 2015 at 5:27 AM, Benedikt Ritter
> wrote:
>
> > Hello again,
> >
> > I've had some time to look ad the JMH Benchmarks. What I see is, that the
> > build now issues a warning:
> >
> > [WARNING]
> > [WARNING] Some problems were encountered while building the effective
> model
> > for org.apache.commons:commons-csv:jar:1.1.1-SNAPSHOT
> > [WARNING]
> 'profiles.profile[benchmark].dependencies.dependency.systemPath'
> > for org.skife.kasparov:csv:jar should not point at files within the
> project
> > directory, ${basedir}/csv-1.0.jar will be unresolvable by dependent
> > projects @ line 432, column 23
> > [WARNING]
> > [WARNING] It is highly recommended to fix these problems because they
> > threaten the stability of your build.
> > [WARNING]
> > [WARNING] For this reason, future Maven versions might no longer support
> > building such malformed projects.
> > [WARNING]
> >
> > Furthermore I can no longer run tests from within Intellij, because it
> can
> > not construct the class path for the JMH Benchmark class correctly. One
> > work around for this would be to create an additional source folder
> > "benchmark" and put the CSVBenchmark there.
> >
> > WDYT?
> >
> > Benedikt
> >
> > 2015-02-16 15:43 GMT+01:00 Ralph Goers :
> >
> > > JMH is a tool used during the build. The source code for the product
> does
> > > not depend on it. See
> > http://www.apache.org/legal/resolved.html#prohibited
> > > .
> > >
> > > Ralph
> > >
> > >
> > > > On Feb 15, 2015, at 2:23 AM, Benedikt Ritter
> > wrote:
> > > >
> > > > 2015-02-09 2:40 GMT+01:00 sebb :
> > > >
> > > >> On 8 February 2015 at 23:47, wrote:
> > > >>> Author: ebourg
> > > >>> Date: Sun Feb 8 23:47:27 2015
> > > >>> New Revision: 1658276
> > > >>>
> > > >>> URL: http://svn.apache.org/r1658276
> > > >>> Log:
> > > >>> Added a JMH benchmark to compare the most commons CSV parsers
> > > >>
> > > >> -1
> > > >>
> > > >> This has broken the Continuum build.
> > > >>
> > > >> Also the JMH website says:
> > > >>
> > > >> "The recommended way to run a JMH benchmark is to use Maven to
> setup a
> > > >> standalone project that depends on the jar files of your
> application.
> > > >> This approach is preferred to ensure that the benchmarks are
> correctly
> > > >> initialized and produce reliable results. It is possible to run
> > > >> benchmarks from within an existing project, and even from within an
> > > >> IDE, however setup is more complex and the results are less
> reliable."
> > > >>
> > > >> Further, it's not clear to me what the JMH license is.
> > > >> It rather looks like GPL.
> > > >>
> > > >
> > > > +1 for this change in general. It's far superior to the manual
> > benchmark
> > > we
> > > > had before.
> > > >
> > > > Regarding the problems mentioned by sebb:
> > > >
> > > > - Is the continuum build fixed already?
> > > > - if we add further functionality, we will eventually end up with a
> > multi
> > > > module build that has modules like: core, beans, annotations,
> > benchmarks.
> > > > For now we should follow KISS and simply add it to the project until
> > > > unresolvable problems show up.
> > > > - regarding the license issue: since log4j seems to use it, I think
> we
> > > are
> > > > on the save side. Maybe someone from the log4j team can comment (ping
> > at
> > > > bodewig, ggregory)
> > > >
> > > >
> > > >>
> > > >>> Added:
> > > >>>
> > > >>
> > >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVBenchmark.java
> > > >> (with props)
> > > >>> Modified:
> > > >>>commons/proper/csv/trunk/pom.xml
> > > >>>
> > > >>> Modified: commons/proper/csv/trunk/pom.xml
> > > >>> URL:
> > > >>
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/pom.xml?rev=1658276&r1=1658275&r2=1658276&view=diff
> > > >>>
> > > >>
> > >
> >
> ==
> > > >>> --- commons/proper/csv/trunk/pom.xml (original)
> > > >>> +++ commons/proper/csv/trunk/pom.xml Sun Feb 8 23:47:27 2015
> > > >>> @@ -73,6 +73,12 @@ CSV files of various types.
> > > >>> The Apache Software Foundation
> >
Re: [COMMONSRDF] GroupID for incubation releases
Hi Peter,
I wrote some code to better answer the second part of your email.
> > Besides the SPARQL usecase, here's a simple usecase for wrapping data as
> > RDF:
> >
> > interface Person {
> >String getFirstName();
> >String getLastName();
> >String getDiary()
> > }
> >
> > interface DataBase() {
> > Interator list();
> > Interator filterByLastName(String);
> > Interator filterByFirstName(String);
> > }
> >
> > No the task is to expose this dynamically as RDF (i.e. without
> duplicating
> > the data).
> >
> > Wrapping this with clerezza one would wrap the Person instance in a
> > blanknode, the identity of the BlankNode would depend on the identity of
> > the Person instance. Doing the same with the incubating commons rdf
> > proposal would require keeping a Bidirectional Weak Hashmap of from
> > Blanknode identifiers to Person objects. I don't think many programmers
> > would like to do the latter, so I don't think it is currently a suitable
> > API for exposing arbitrary data using the RDF datamodel.
>
> If there is no single or aggregate primary key for a person, then it
> will not work reliably with any database,
> RDF/Graph/Document/NoSQL/Relational/etc. It works internally in
> Clerezza, in-memory, with the added BlankNode object wrapper, and
> could be mapped using BlankNode.internalIdentifier. It isn't helpful
> to use arguments about not liking a method to imply it is impossible.
>
I did not say that it is impossible, I just say that it takes additional
code and uses additional memory (memory usage can be minimized by using a
bidirectional weak hashmap).
Here I've implemented the simple usecase using Clerezza:
https://github.com/retog/rdfwrapper-example. The actual wrapper class is
here:
https://github.com/retog/rdfwrapper-example/blob/master/clerezza-based-wrapper/src/main/java/org/example/clerezza/based/wrapper/PersonDataBaseGraph.java
.
I think an API should be evaluated by the elegance and efficiency it allows
to implement different usecases. Even if you think that the example is
badly chosen and in reality persons would always come with identifiers I
invite you to implement the same functionality with your API proposal,
after all we should be able to wrap even a crappy API that does not expose
the primary key of the underlying database. Note that the Clerezza Commons
RDF based implementation works with constant memory even if the backend
exposes billions of persons.
I think comparing code and it's properties it's the best way to compare
APIs, so I hope you - or someone else - will accept the invitation.
Cheers,
Reto
Re: [math] threading redux
On 4/19/15 6:08 AM, Gilles wrote: > Hello. > > On Sat, 18 Apr 2015 22:25:20 -0400, James Carman wrote: >> I think I got sidetracked when typing that email. I was trying >> to say that >> we need an abstraction layer above raw threads in order to allow for >> different types of parallelism. The Future abstraction is there >> in order >> to support remote execution where side effects aren't good enough. > > I don't know what > "remote execution where side effects aren't good enough" > means. > > I'll describe my example of "prototype" (see quoted message below[1]) > and what *I* mean when I suggest that (some of) the CM code should > allow > to take advantage of multi-threading. > > I committed the first set of classes in "o.a.c.m.ml.neuralnet".[2] > Here is the idea of "parallelism" that drove the design of those > classes: The training of an artificial neural network (ANN) is > performed > by almost[3] independent updates of each of ANN's cells. You > _cannot_[4] > however chop the network into independent parts to be sent for remote > processing: each update must be visible ASAP by all the training > tasks.[5] There are lots of ways to allow distributed processes to share common data. Spark has a very nice construct called a Resilient Distributed Dataset (RDD) designed for exactly this purpose. > > "Future" instances do not appear in the "main" code, but the idea > was, > indeed, to be able to use that JDK abstraction: see the unit test[6] > testTravellerSalesmanSquareTourParallelSolver() > defined in class > org.apache.commons.math4.ml.neuralnet.sofm.KohonenTrainingTaskTest > in the "test" part of the repository. This is a good concrete example. The question is, is there a way that we could set up, say KohonenTrainingTask to not just directly implement Runnable and enable it to be executed by something other than an in-process, thread-spawning Executor. You're right that however we did set it up, we would have to allow each task to access the shared net. > >> As for a concrete example, you can try Phil's idea of the genetic >> algorithm >> stuff I suppose. > > I hope that with the above I made myself clear that I was not asking > for a pointer to code that could be parallelized[7], but rather that > people make it explicit what _they_ mean by parallelism[8]. What > I mean > is multithread safe code that can take advantage of the multiple core > machines through the readily available classes in the JDK: namely the > "Executor" framework which you also mentioned. That is one way to achieve parallelism. The Executor is one way to manage concurrently executing threads in a single process. There are other ways to do this. My challenge is to find a way to make it possible for users to plug in alternatives. > Of course, I do not preclude other approaches (I don't know them, as > mentioned previously) that may (or may not) be more appropriate > for the > example I gave or to other algorithms; but I truly believe that this > discussion should be more precise, unless we deepen the > misunderstanding > of what we think we are talking about. Agreed. Above example is also a good one to look at. > > > Regards, > Gilles > > [1] As a side note: Shall we agree that top-posting is bad? ;-) Yes! > [2] With the purpose to implement a version of a specific > algorithm (SOFM) so > that the data structures might not be generally useful for any > kind of > artificial neural network. > [3] The update should of course be thread-safe: two parallel tasks > might try > to update the same cell at the same time. Right, this is partly a function of what data structure and protocols you use to protect the shared data. > [4] At least, it's instinctively obvious that for a SOFM network > of "relatively > small", you'd _loose_ performance through I/O. Yes, just like it does not make sense to do spreadsheet math on hadoop clusters. The (perhaps impossible) idea is to set things up so that thread location and management is pluggable. Phil > [5] In later phases of the training, "regions" will have formed in > the ANN, so > that at that point, it might be possible to continue the > updates of those > regions on different computation nodes (with the necessary > synchronization > of the region's boundaries). > [6] It's more of an example usage that could probably go to the > "user guide". > [7] The GA perfectly lend itself to the same kind of "readiness to > parallelism" > code which I implemented for the SOFM. > [8] As applied concretely to a specific algorithm in CM. > >> On Saturday, April 18, 2015, Gilles >> wrote: >> >>> On Fri, 17 Apr 2015 16:53:56 -0500, James Carman wrote: >>> Do you have any pointers to code for this ForkJoin mechanism? I'm curious to see it. The key thing you will need in order to support parallelization in a generic way >>> >>> What do you mean by "generic way"? >>> >>> I'm afraid that we may be trying to compare apples an
