Re: [Numbers] Java version? (Was: Scope?)

[Eric Barnhill]

Okay. I will catch myself up on Lambdas and come back with a proposal for
this class at that time.

Eric

On Tue, Jan 31, 2017 at 3:05 AM, Gary Gregory 
wrote:

> +1 on Java 8.
>
> Gary
>
> On Mon, Jan 30, 2017 at 5:25 PM, Gilles 
> wrote:
>
> > [...] what JDK version do we target?
> >>
> >> I'd go for Java8, in the hope to revive interest in Commons from an
> >> audience that might be put off by the "no fun" of older and soon
> >> unsupported JVM.
> >>
> >
> >
> > Gilles
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
>  tl?ie=UTF8=1789=9325=1617290459&
> linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>
>  1617290459>
> JUnit in Action, Second Edition
>  tl?ie=UTF8=1789=9325=1935182021&
> linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
>  1935182021>
> Spring Batch in Action
>  tl?ie=UTF8=1789=9325=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>  1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [Numbers] Java version? (Was: Scope?)

[Gary Gregory]

+1 on Java 8.

Gary

On Mon, Jan 30, 2017 at 5:25 PM, Gilles 
wrote:

> [...] what JDK version do we target?
>>
>> I'd go for Java8, in the hope to revive interest in Commons from an
>> audience that might be put off by the "no fun" of older and soon
>> unsupported JVM.
>>
>
>
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[Numbers] Java version? (Was: Scope?)

[Gilles]

[...] what JDK version do we target?

I'd go for Java8, in the hope to revive interest in Commons from an
audience that might be put off by the "no fun" of older and soon
unsupported JVM.



Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Text] New feature: Parsing and formatting numbers (Was: Consider making the project "multimodule")

[Rob Tompkins]

> On Jan 30, 2017, at 7:47 PM, Gilles  wrote:
> 
>> On Mon, 30 Jan 2017 14:46:25 +0100, Gilles wrote:
>> Hi.
>> 
>> I think that it would be worth modularizing the [Text] component.
>> I only had quick glances, but it seems that some codes are more
>> generic than others (that e.g. focused on HTML entities).
>> 
>> The scope of [Text] could obviously encompass functionality for
>> which there isn't any code yet. An example is currently the subject
>> of a thread with subject:
>> [Numbers] Parsing and formatting classes
> 
> Would [Text] be welcoming utilities to handle I/O of fractions,
> complex numbers, matrices, and so on?
> 

I could see an argument for [text], [lang], or [numbers]. But it definitely 
feels somewhere in the middle of [text] and [numbers]. Either way I'd be happy 
to work on that. It seems interesting. 

-Rob

> Gilles
> 
>> 
>> [...]
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Text] New feature: Parsing and formatting numbers (Was: Consider making the project "multimodule")

[Gilles]

On Mon, 30 Jan 2017 14:46:25 +0100, Gilles wrote:

Hi.

I think that it would be worth modularizing the [Text] component.
I only had quick glances, but it seems that some codes are more
generic than others (that e.g. focused on HTML entities).

The scope of [Text] could obviously encompass functionality for
which there isn't any code yet. An example is currently the subject
of a thread with subject:
 [Numbers] Parsing and formatting classes


Would [Text] be welcoming utilities to handle I/O of fractions,
complex numbers, matrices, and so on?

Gilles



[...]



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Text] Consider making the project "multimodule"

[Emmanuel Bourg]

Le 30/01/2017 à 15:16, Rob Tompkins a écrit :

> I lean towards going with a single module out of simplicity

+1

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: JCS jcache examples specifically with spring caching

[Romain Manni-Bucau]

Not sure with spring but we have users in prod yes (we already got feedback
through tomee list / IRC /  privately)


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-01-30 18:09 GMT+01:00 Tim Cronin :

> is there anyone that has used the Jcache impl of JCS?
>
>
>
> On Wed, Jan 25, 2017 at 8:48 AM, Tim Cronin 
> wrote:
>
> > I'm trying to leverage Spring caching using jcs cache
> > the javadocs show only ctor for the JCSCachingManager.
> > https://commons.apache.org/proper/commons-jcs/commons-
> > jcs-jcache/apidocs/src-html/org/apache/commons/jcs/jcache/
> > JCSCachingManager.html#line.83
> >
> > but i pass in what seems more like default values
> >
> > public static void main(String[] args) throws Exception
> >   {
> >JCSCachingProvider provider = new JCSCachingProvider();
> >Properties props = new Properties();
> >
> >CacheManager cacheMgr = new JCSCachingManager(provider,
> >JCSCachingProvider.DEFAULT_URI,
> >Thread.currentThread().getContextClassLoader(),
> >props);
> >
> > //... do cache stuff...
> >
> >cacheMgr.close();
> >
> >   }
> >
> > I'm trying to fit this into an existing webapp that uses xml base
> > configuration
> > and having to set the defaults seems problematic, I'd have to wrap it to
> > get
> > proper current class load or use system which doesn't map to webapp
> loader
> >
> > Is there any reason for not having a default Ctor?
> >
> > 
> > 
> > 
> > 
> >  > factory-method="getSystemClassLoader" />
> > 
> >
> > 
> > 
> > 
> > 
> > 
> > 
> >
> >
>

Re: JCS jcache examples specifically with spring caching

[Tim Cronin]

is there anyone that has used the Jcache impl of JCS?



On Wed, Jan 25, 2017 at 8:48 AM, Tim Cronin  wrote:

> I'm trying to leverage Spring caching using jcs cache
> the javadocs show only ctor for the JCSCachingManager.
> https://commons.apache.org/proper/commons-jcs/commons-
> jcs-jcache/apidocs/src-html/org/apache/commons/jcs/jcache/
> JCSCachingManager.html#line.83
>
> but i pass in what seems more like default values
>
> public static void main(String[] args) throws Exception
>   {
>JCSCachingProvider provider = new JCSCachingProvider();
>Properties props = new Properties();
>
>CacheManager cacheMgr = new JCSCachingManager(provider,
>JCSCachingProvider.DEFAULT_URI,
>Thread.currentThread().getContextClassLoader(),
>props);
>
> //... do cache stuff...
>
>cacheMgr.close();
>
>   }
>
> I'm trying to fit this into an existing webapp that uses xml base
> configuration
> and having to set the defaults seems problematic, I'd have to wrap it to
> get
> proper current class load or use system which doesn't map to webapp loader
>
> Is there any reason for not having a default Ctor?
>
> 
> 
> 
> 
>  factory-method="getSystemClassLoader" />
> 
>
> 
> 
> 
> 
> 
> 
>
>

Re: [Text] Consider making the project "multimodule"

[Gary Gregory]

On Jan 30, 2017 6:16 AM, "Rob Tompkins"  wrote:


> On Jan 30, 2017, at 8:46 AM, Gilles  wrote:
>
> Hi.
>
> I think that it would be worth modularizing the [Text] component.
> I only had quick glances, but it seems that some codes are more
> generic than others (that e.g. focused on HTML entities).

I lean towards going with a single module out of simplicity, but I’m open
to the idea. I’m curious with what others have to say here.

-Rob

>
> The scope of [Text] could obviously encompass functionality for
> which there isn't any code yet. An example is currently the subject
> of a thread with subject:
> [Numbers] Parsing and formatting classes
>
> Hence, I think that it would make sense that [Text] is prepared
> to provide new utilities that handle domains not initially foreseen,
> while mitigating the risk of becoming a huge monolithic component.


Single module seems good for now.

Gary

>
>
> Thanks,
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Text] Consider making the project "multimodule"

[Rob Tompkins]

> On Jan 30, 2017, at 8:46 AM, Gilles  wrote:
> 
> Hi.
> 
> I think that it would be worth modularizing the [Text] component.
> I only had quick glances, but it seems that some codes are more
> generic than others (that e.g. focused on HTML entities).

I lean towards going with a single module out of simplicity, but I’m open to 
the idea. I’m curious with what others have to say here.

-Rob

> 
> The scope of [Text] could obviously encompass functionality for
> which there isn't any code yet. An example is currently the subject
> of a thread with subject:
> [Numbers] Parsing and formatting classes
> 
> Hence, I think that it would make sense that [Text] is prepared
> to provide new utilities that handle domains not initially foreseen,
> while mitigating the risk of becoming a huge monolithic component.
> 
> 
> Thanks,
> Gilles
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Commons Text 1.0-beta-1 based on RC4

[Rob Tompkins]

Hello all,

This is a [VOTE] for releasing Apache Commons Text 1.0-beta-1 (from RC4).

Tag name:
   commons-text-1.0-beta-1-RC4 (signature can be checked from git using 'git 
tag -v')

Tag URL:
   
https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=commit;h=65e4314fbd6c3a8f5c248d07a4ccffc1f0ea8bb9

Commit ID the tag points at:
   65e4314fbd6c3a8f5c248d07a4ccffc1f0ea8bb9

Site:
   http://home.apache.org/~chtompki/commons-text-1.0-beta-1-RC4

Distribution files (committed at revision 18041):
   https://dist.apache.org/repos/dist/dev/commons/text/

Distribution files hashes (SHA1):
   commons-text-1.0-beta-1-bin.tar.gz
   (SHA: dcedb6acc9e8dee75ef9ebefc3a03d20df1d84af)
   commons-text-1.0-beta-1-bin.zip
   (SHA1: b1fa8083bfdcec354a97c23468aa63082990febe)
   commons-text-1.0-beta-1-src.tar.gz
   (SHA1: 06e7bee6a1a710fb2a68472bbbd3209bdc66802c)
   commons-text-1.0-beta-1-src.zip
   (SHA1: 62f405f55689526ca87fd228ed4ae4a4cf4ad107)

These are the Maven artifacts and their hashes:
   commons-text-1.0-beta-1-javadoc.jar
   (SHA1: 771928f5f5439dbf75d857b4a8da83646ba854e8)
   commons-text-1.0-beta-1-sources.jar
   (SHA1: 104e0d8fe8791d7e6f0653fee406150e6f80ee0e)
   commons-text-1.0-beta-1-test-sources.jar
   (SHA1: 0e0b2ea171d8f82c4775b0e472c41b316052de8f)
   commons-text-1.0-beta-1-tests.jar
   (SHA1: 664d9d71be733cc8240a4164e6a3971fc9e95578)
   commons-text-1.0-beta-1.jar
   (SHA1: 6ef0390cf936f21e07ed47f34ba7eab0d918606b)
   commons-text-1.0-beta-1.pom
   (SHA1: 7b65ac70d36c5acf3bcad87ed2df9e7eba111726)

KEYS file to check signatures:
   http://www.apache.org/dist/commons/KEYS

Maven artifacts:
   https://repository.apache.org/content/repositories/orgapachecommons-1234

Please select one of the following options[1]:
  [ ] +1 Release it.
  [ ] +0 Go ahead; I don't care.
  [ ] -0 There are a few minor glitches: ...
  [ ] -1 No, do not release it because ...

This vote will be open at least 72 hours, i.e. until 
2017-02-02T15:00:00Z
(this is UTC time).


Cheers,
-Rob

[1] http://apache.org/foundation/voting.html
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: RDF commons testing

[Stian Soiland-Reyes]

On Mon, 30 Jan 2017 10:20:46 +, Stian Soiland-Reyes  
wrote:
> BTW - in your approach, would it work to run the tests out of the box 
> from an IDE like Eclipse? I think that is quite important so Commons RDF
> can be maintainable by many people in Apache Commons.

They did run out of the box in Eclipse thanks to the @TestRunner, and it
looks quite nice, separated out per interface contract tested:

https://raw.githubusercontent.com/stain/junit-contracts/patch-1/docs/junit-contracts.png


I was confused by your examples still using test class hierarchy like
"BarTest extends FooTest" which then turns out to be not needed at all.
Also I don't think there's generally a need to use the confusing
indirection of IProducer but rather give the instance to be tested
directly.

I was confused with @Contract.Inject being the annotation both for
the property to be set and the factory method to generate the
implementaton.


I added a suggestion to your README to show how junit-contracts can be
used with multiple interfaces and multiple implementations, using
java.util.Set as an example which I think many on this list will 
be familiar with.

https://github.com/stain/junit-contracts/tree/patch-1#motivation

I also think the ability to have different @Before is a strong
argument - so this could be relevant in multiple project with
several interface implementaton, but also for Commons RDF.


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers] Scope?

[Gilles]

On Mon, 30 Jan 2017 12:40:06 +0100, Eric Barnhill wrote:

I agree the solvers don't seem to be in the scope.


Let's agree to defer the decision. :-)


The MathArrays are a great idea but could use some rethinking.


Fine thne. Could you please start a new thread with some of the
things to rethink about?

First of all there are leftover references to classes like Field that 
have

disappeared with the larger math framework and these should go.


Agreed (no use-case have popped up IIRC).

Also, there are a lot of basic array-wise operations that might 
benefit
from inclusion. To pick an example at random, element-by-element 
cosine. In
fact I already have a whole library of these (very simple) methods 
for up

to 3 dimensions which I would be happy to contribute.

My understanding is that such operations can be accomplished 
elegantly with
lambdas now. But speaking only for myself, I tend to stick to "old 
school"

Java syntax and I know I find these methods very useful.


A very important issue here: what JDK version do we target?

I'd go for Java8, in the hope to revive interest in Commons from an
audience that might be put off by the "no fun" of older and soon
unsupported JVM.

If there was general agreement on inclusion of MathArrays, I am happy 
to

work on it.


Great.  But let's discuss first the above.


Gilles



Eric


On Mon, Jan 30, 2017 at 8:49 AM, Emmanuel Bourg  
wrote:



Hi,

Shouldn't [numbers] focus only on number structures (fractions, 
complex)
and the basic operations on them? I'm not sure the solvers fit in 
the

scope.

Emmanuel Bourg

Le 30/01/2017 à 02:17, Gilles a écrit :
> Hi.
>
> Anyone has a statement about it?
>
> Functionalities that are candidates to be moved from "Math"
> to "Numbers":
>  * FastMath
>  * CombinatoricsUtils [1]
>  * ContinuedFraction [1]
>  * special functions [1]
>  * solvers
>  * MathArrays [2]
>  * MathUtils [1]
>  * ...
>
> Thanks,
> Gilles
>
> [1] With redesigned API (e.g. to allow usage as Java8 functional
> interface).
> [2] Partly (e.g. "linearCombination").
>
>



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Text] Consider making the project "multimodule"

[Gilles]

Hi.

I think that it would be worth modularizing the [Text] component.
I only had quick glances, but it seems that some codes are more
generic than others (that e.g. focused on HTML entities).

The scope of [Text] could obviously encompass functionality for
which there isn't any code yet. An example is currently the subject
of a thread with subject:
 [Numbers] Parsing and formatting classes

Hence, I think that it would make sense that [Text] is prepared
to provide new utilities that handle domains not initially foreseen,
while mitigating the risk of becoming a huge monolithic component.


Thanks,
Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers] Scope?

[Gilles]

On Mon, 30 Jan 2017 12:30:20 +0100, Emmanuel Bourg wrote:

Le 30/01/2017 à 12:08, Gilles a écrit :

Ideally, it should be another light-weight component (because 
solvers

are used in so many areas).

This thread is about if (and how) we can try and stretch the scope a
little, so as to group several basic utilities in a single 
component.


I'd prefer creating [math] sub modules than independent components.


Either you or I have misunderstood the consensus that CM cannot
provide (what I'd call) "partial" releases (I had proposed that
currently unsupported code[1] will not be released anymore).

The consequence is that the date of the next release of CM was
likely to be: never.

The consequence of which is that valuable _and_ supported code
must be moved to other components (that would also become a
good opportunity to get rid of obsolete stuff, and redesign
without backwards compatibility burdens) in order to be useful
to a larger audience.


Otherwise what will be left in [math] once you are done slicing it?


Good question.
Development can be viewed from the [Math] component POV (removing
stuff) or from each of the new components' view (what's in scope?).

The former POV leads to project death.[2]

The latter is being worked on, and in the end, the goal is that
CM will loose nothing[3]: it will depend on other components where
the "removed" functionality has been transferred.

A big component like Commons Math is a nightmare to manage; as
we've seen, it simply did not work (reasons, according to me, have
been already amply exposed on this ML).
Small components are more agile.

The proposed roadmap increases the chances to attract enough
contributors so that eventually the huge task of supporting
the whole of CM can be considered again.
In the meantime, more focused components can attract contributors
who will not have to wait years to see their work released
officially.

This IMO is actually more community-building stuff than clinging
onto an old component, full of good code[4] but an empty shell,
community-wise.


Gilles



Emmanuel Bourg



[1] Unsupported = nobody knows the code enough to timely follow up
on reports about it.
[2] Visible symptom is: nobody works on reports piling up in JIRA.
[3] Of course, there will backwards incompatible changes, but that
fact was agreed on several years ago, when the then current
development branch was aimed at releasing the next major version.
[4] But also containing outdated things to be revamped or thrown away.


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers] Scope?

[Eric Barnhill]

On Mon, Jan 30, 2017 at 12:51 PM, sebb  wrote:

>
> > Also, there are a lot of basic array-wise operations that might benefit
> > from inclusion. To pick an example at random, element-by-element cosine.
> In
> > fact I already have a whole library of these (very simple) methods for up
> > to 3 dimensions which I would be happy to contribute.
>
> If every mathematical operation has its own function that quickly gets
> very unwieldy to test and maintain.
>

With C++ complex numbers (a library I have looked at quite a bit) there are
three categories of operators: complex operations, transcendental overloads
and operator overloads. Keeping with that model for arrays does not add up
to so many functions. The new class would be around half those, and half
the functions already in the current class (e.g. shuffle, range, norm) some
of which are already operator overloads.

Re: [Numbers] Scope?

[sebb]

On 30 January 2017 at 11:40, Eric Barnhill  wrote:
> I agree the solvers don't seem to be in the scope.
>
> The MathArrays are a great idea but could use some rethinking.
>
> First of all there are leftover references to classes like Field that have
> disappeared with the larger math framework and these should go.
>
> Also, there are a lot of basic array-wise operations that might benefit
> from inclusion. To pick an example at random, element-by-element cosine. In
> fact I already have a whole library of these (very simple) methods for up
> to 3 dimensions which I would be happy to contribute.

If every mathematical operation has its own function that quickly gets
very unwieldy to test and maintain.

> My understanding is that such operations can be accomplished elegantly with
> lambdas now. But speaking only for myself, I tend to stick to "old school"
> Java syntax and I know I find these methods very useful.

Or surely one can use a Visitor strategy if lambdas are too modern?

> If there was general agreement on inclusion of MathArrays, I am happy to
> work on it.
>
> Eric
>
>
> On Mon, Jan 30, 2017 at 8:49 AM, Emmanuel Bourg  wrote:
>
>> Hi,
>>
>> Shouldn't [numbers] focus only on number structures (fractions, complex)
>> and the basic operations on them? I'm not sure the solvers fit in the
>> scope.
>>
>> Emmanuel Bourg
>>
>> Le 30/01/2017 à 02:17, Gilles a écrit :
>> > Hi.
>> >
>> > Anyone has a statement about it?
>> >
>> > Functionalities that are candidates to be moved from "Math"
>> > to "Numbers":
>> >  * FastMath
>> >  * CombinatoricsUtils [1]
>> >  * ContinuedFraction [1]
>> >  * special functions [1]
>> >  * solvers
>> >  * MathArrays [2]
>> >  * MathUtils [1]
>> >  * ...
>> >
>> > Thanks,
>> > Gilles
>> >
>> > [1] With redesigned API (e.g. to allow usage as Java8 functional
>> > interface).
>> > [2] Partly (e.g. "linearCombination").
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers] Scope?

[Eric Barnhill]

I agree the solvers don't seem to be in the scope.

The MathArrays are a great idea but could use some rethinking.

First of all there are leftover references to classes like Field that have
disappeared with the larger math framework and these should go.

Also, there are a lot of basic array-wise operations that might benefit
from inclusion. To pick an example at random, element-by-element cosine. In
fact I already have a whole library of these (very simple) methods for up
to 3 dimensions which I would be happy to contribute.

My understanding is that such operations can be accomplished elegantly with
lambdas now. But speaking only for myself, I tend to stick to "old school"
Java syntax and I know I find these methods very useful.

If there was general agreement on inclusion of MathArrays, I am happy to
work on it.

Eric


On Mon, Jan 30, 2017 at 8:49 AM, Emmanuel Bourg  wrote:

> Hi,
>
> Shouldn't [numbers] focus only on number structures (fractions, complex)
> and the basic operations on them? I'm not sure the solvers fit in the
> scope.
>
> Emmanuel Bourg
>
> Le 30/01/2017 à 02:17, Gilles a écrit :
> > Hi.
> >
> > Anyone has a statement about it?
> >
> > Functionalities that are candidates to be moved from "Math"
> > to "Numbers":
> >  * FastMath
> >  * CombinatoricsUtils [1]
> >  * ContinuedFraction [1]
> >  * special functions [1]
> >  * solvers
> >  * MathArrays [2]
> >  * MathUtils [1]
> >  * ...
> >
> > Thanks,
> > Gilles
> >
> > [1] With redesigned API (e.g. to allow usage as Java8 functional
> > interface).
> > [2] Partly (e.g. "linearCombination").
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Numbers] Scope?

[Emmanuel Bourg]

Le 30/01/2017 à 12:08, Gilles a écrit :

> Ideally, it should be another light-weight component (because solvers
> are used in so many areas).
> 
> This thread is about if (and how) we can try and stretch the scope a
> little, so as to group several basic utilities in a single component.

I'd prefer creating [math] sub modules than independent components.
Otherwise what will be left in [math] once you are done slicing it?

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers] Scope?

[Gilles]

On Mon, 30 Jan 2017 08:49:49 +0100, Emmanuel Bourg wrote:

Hi,

Shouldn't [numbers] focus only on number structures (fractions, 
complex)

and the basic operations on them?


Strictly speaking, yes; but I'm trying to fit more in it than just
the obvious, so as to not require many new components (although I'd
prefer that way).


I'm not sure the solvers fit in the scope.


I'm also not sure.

Ideally, it should be another light-weight component (because solvers
are used in so many areas).

This thread is about if (and how) we can try and stretch the scope a
little, so as to group several basic utilities in a single component.

Gilles



Emmanuel Bourg

Le 30/01/2017 à 02:17, Gilles a écrit :

Hi.

Anyone has a statement about it?

Functionalities that are candidates to be moved from "Math"
to "Numbers":
 * FastMath
 * CombinatoricsUtils [1]
 * ContinuedFraction [1]
 * special functions [1]
 * solvers
 * MathArrays [2]
 * MathUtils [1]
 * ...

Thanks,
Gilles

[1] With redesigned API (e.g. to allow usage as Java8 functional
interface).
[2] Partly (e.g. "linearCombination").





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers] Scope?

[Gilles]

Hi.

On Mon, 30 Jan 2017 08:10:27 +0100, Benedikt Ritter wrote:

Hello Gilles,

Am 30.01.2017 um 02:17 schrieb Gilles 
:


Hi.

Anyone has a statement about it?

Functionalities that are candidates to be moved from "Math"
to "Numbers":
* FastMath


I just thought, maybe FastMath would fit into Commons Lang. WDYT?


Could be, but I'd consider it only if Lang would become "multimodule".

An interesting feature would be to be able to replace, at runtime,
in some portion of code, all calls to "Math" with calls to "FastMath"
(or any other class that implement the set of functions provided by
the JDK's "Math" class).
Is this feasible?


[...]

(Sorry for OT posting :-))


That's quite on-topic.
We should advance on a global roadmap for handling the future of
"Commons Math".

"FastMath" functions are at least as accurate as "Math". But the
"Fast" claim is not verified in some cases (hence a name change
might be in order).

The functions of "FastMath" are building blocks for other "low-level"
functionality; hence it should be made available either "standalone",
or in a light-weight component (hence the "Numbers" proposal), or in
a module of its own.




* CombinatoricsUtils [1]
* ContinuedFraction [1]
* special functions [1]
* solvers
* MathArrays [2]
* MathUtils [1]
* ...

Thanks,
Gilles

[1] With redesigned API (e.g. to allow usage as Java8 functional
   interface).
[2] Partly (e.g. "linearCombination").





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: RDF commons testing

[Sergio Fernández]

Thanks for the suggestion, Claude!

I agree with Stian, do a PR with how the test suite would change, so then
we are discussing about more concrete things.

On Mon, Jan 30, 2017 at 11:20 AM, Stian Soiland-Reyes 
wrote:

> On Mon, 30 Jan 2017 09:08:27 +1100, Peter Ansell 
> wrote:
> > Hi Claude,
> > Abstract test classes are working well for Commons RDF so far. Others
> > may benefit from your solution, so feel free to suggest the approach
> > to others who may be interested in exploring it.
>
> I would not dismiss Claude's suggestion out of hand. Apache Commons is
> for anyone who wants to participate! :-)
>
> Claude  - if you would like to have a go in a branch at what Commons RDF
> tests look like using contract testing, then feel free!
>
> >> https://www.linkedin.com/pulse/contract-testing-why-
> abstract-tests-enough-claude-warren-jr
>
> I liked this blog article which explains the problem. We in a way
> already have this problem twice in Commons RDF tests because we have the
> Triple/Quad duality (TripleLike) and Graph/Dataset duality (GraphLike)
> as well as the multiple implementations of the commons-rdf-api
> interfaces.
>
> So you will notice some of those tests have considerable duplication
> with subtle differences, e.g. along the lines of:
>
>
> graph.add(triple);
> assertTrue(graph.contains(triple)
> assertTrue(graph.contains(triple.getSubject(),
> triple.getPredicate(), triple.getObject());
>
> vs
>
> dataset.add(quad);
> assertTrue(dataset.contains(quad));
> assertTrue(dataset.contains(quad.getGraphName(),
>   quad.getSubject(), quad.getPredicate(), quad.getObject());
>
> This could in theory be harmonized so that there's a single abstract
> test class with an abstract method to make the triple/quad - and then
> extensions for Triple and Quad that adds the last decomposition
> assertion.
>
> But as we already use abstract classes to run the tests per RDF
> implementation, and so I thought it would get messy to try to reorganize
> it.
>
>
> Another thing is that now the tests are munged together
> into mainly AbstractRDFTest (which must create an RDF factory instance,
> that then can create the other things) - otherwise you will have to
> make many SomethingImplTest in each module (and easily forget to
> specialize one of the tests in one of the modules)
>
> With your approach, would you still have to make a such specialization,
> or is that automatic?
>
>
> BTW - in your approach, would it work to run the tests out of the box
> from an IDE like Eclipse? I think that is quite important so Commons RDF
> can be maintainable by many people in Apache Commons.
>
>
>
>
> --
> Stian Soiland-Reyes
> University of Manchester
> http://www.esciencelab.org.uk/
> http://orcid.org/-0001-9842-9718
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co

Re: RDF commons testing

[Stian Soiland-Reyes]

On Mon, 30 Jan 2017 09:08:27 +1100, Peter Ansell  wrote:
> Hi Claude,
> Abstract test classes are working well for Commons RDF so far. Others
> may benefit from your solution, so feel free to suggest the approach
> to others who may be interested in exploring it.

I would not dismiss Claude's suggestion out of hand. Apache Commons is
for anyone who wants to participate! :-)

Claude  - if you would like to have a go in a branch at what Commons RDF
tests look like using contract testing, then feel free!

>> https://www.linkedin.com/pulse/contract-testing-why-abstract-tests-enough-claude-warren-jr

I liked this blog article which explains the problem. We in a way
already have this problem twice in Commons RDF tests because we have the
Triple/Quad duality (TripleLike) and Graph/Dataset duality (GraphLike)
as well as the multiple implementations of the commons-rdf-api
interfaces.

So you will notice some of those tests have considerable duplication
with subtle differences, e.g. along the lines of:


graph.add(triple);
assertTrue(graph.contains(triple)
assertTrue(graph.contains(triple.getSubject(),
triple.getPredicate(), triple.getObject());

vs

dataset.add(quad);
assertTrue(dataset.contains(quad));
assertTrue(dataset.contains(quad.getGraphName(),
  quad.getSubject(), quad.getPredicate(), quad.getObject());

This could in theory be harmonized so that there's a single abstract
test class with an abstract method to make the triple/quad - and then
extensions for Triple and Quad that adds the last decomposition
assertion.

But as we already use abstract classes to run the tests per RDF
implementation, and so I thought it would get messy to try to reorganize
it.


Another thing is that now the tests are munged together
into mainly AbstractRDFTest (which must create an RDF factory instance,
that then can create the other things) - otherwise you will have to
make many SomethingImplTest in each module (and easily forget to
specialize one of the tests in one of the modules)

With your approach, would you still have to make a such specialization,
or is that automatic?


BTW - in your approach, would it work to run the tests out of the box 
from an IDE like Eclipse? I think that is quite important so Commons RDF
can be maintainable by many people in Apache Commons.




-- 
Stian Soiland-Reyes
University of Manchester
http://www.esciencelab.org.uk/
http://orcid.org/-0001-9842-9718


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org