Re: BCEL: Can't load Object.class using LDC

[Romain Manni-Bucau]

Hi,

Maybe a bit ot of topic but did you check with asm (using classreader for
ex) if it is readable for it? Javap in verbose mode is hard to read humanly
(and not verbosel does not mean much) so an issue can still be hidden.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 3 févr. 2022 à 01:42, Stefan Reich
 a écrit :

> I'm mainly curious how it's possible that everything looks completely
> normal in javap (checked a dozen times), but the class verifier complains
> anyway? Something has to be different. Is there a way to dig deeper into a
> class file?
>
> Greetings
>
> On Wed, 2 Feb 2022 at 23:14, Stefan Reich <
> stefan.reich.maker.of@googlemail.com> wrote:
>
> > Hmm, no change with latest version.
> >
> > I did "git clone https://github.com/apache/commons-bcel.git"; and "mvn
> > package".
> >
> > stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ javac -cp
> > bcel-6.6.0-SNAPSHOT.jar MakeBadClassFile.java
> > stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ java -cp
> > bcel-6.6.0-SNAPSHOT.jar:. MakeBadClassFile
> > Now please try: java BadClassFile
> > stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ java BadClassFile
> > Error: Unable to initialize main class BadClassFile
> > Caused by: java.lang.VerifyError: (class: BadClassFile, method: main
> > signature: ([Ljava/lang/String;)V) Illegal type in constant pool
> > stefan@lenovo-ThinkPad-X220:~/dev/classreftest$
> >
> > On Wed, 2 Feb 2022 at 22:59, Gary Gregory 
> wrote:
> >
> >> You should try the latest from git master.
> >>
> >> Gary
> >>
> >> On Wed, Feb 2, 2022, 15:41 Stefan Reich
> >>  wrote:
> >>
> >> > Hi again,
> >> >
> >> > actual problem this time...
> >> >
> >> > I think I am doing everything right... Decompilation in javap -v looks
> >> > just like it should. But I get a VerifyError... I'm using JDK 17. Full
> >> > program attached. Please advice, thank you :)
> >> >
> >> > # javac -cp bcel-6.5.0.jar MakeBadClassFile.java
> >> > # java -cp bcel-6.5.0.jar:. MakeBadClassFile
> >> > # java BadClassFile
> >> > Error: Unable to initialize main class BadClassFile
> >> > Caused by: java.lang.VerifyError: (class: BadClassFile, method: main
> >> > signature: ([Ljava/lang/String;)V) Illegal type in constant pool
> >> >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> >
>

Re: BCEL: Can't load Object.class using LDC

[Stefan Reich]

I'm mainly curious how it's possible that everything looks completely
normal in javap (checked a dozen times), but the class verifier complains
anyway? Something has to be different. Is there a way to dig deeper into a
class file?

Greetings

On Wed, 2 Feb 2022 at 23:14, Stefan Reich <
stefan.reich.maker.of@googlemail.com> wrote:

> Hmm, no change with latest version.
>
> I did "git clone https://github.com/apache/commons-bcel.git"; and "mvn
> package".
>
> stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ javac -cp
> bcel-6.6.0-SNAPSHOT.jar MakeBadClassFile.java
> stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ java -cp
> bcel-6.6.0-SNAPSHOT.jar:. MakeBadClassFile
> Now please try: java BadClassFile
> stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ java BadClassFile
> Error: Unable to initialize main class BadClassFile
> Caused by: java.lang.VerifyError: (class: BadClassFile, method: main
> signature: ([Ljava/lang/String;)V) Illegal type in constant pool
> stefan@lenovo-ThinkPad-X220:~/dev/classreftest$
>
> On Wed, 2 Feb 2022 at 22:59, Gary Gregory  wrote:
>
>> You should try the latest from git master.
>>
>> Gary
>>
>> On Wed, Feb 2, 2022, 15:41 Stefan Reich
>>  wrote:
>>
>> > Hi again,
>> >
>> > actual problem this time...
>> >
>> > I think I am doing everything right... Decompilation in javap -v looks
>> > just like it should. But I get a VerifyError... I'm using JDK 17. Full
>> > program attached. Please advice, thank you :)
>> >
>> > # javac -cp bcel-6.5.0.jar MakeBadClassFile.java
>> > # java -cp bcel-6.5.0.jar:. MakeBadClassFile
>> > # java BadClassFile
>> > Error: Unable to initialize main class BadClassFile
>> > Caused by: java.lang.VerifyError: (class: BadClassFile, method: main
>> > signature: ([Ljava/lang/String;)V) Illegal type in constant pool
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>

Re: BCEL: Can't load Object.class using LDC

[Stefan Reich]

Hmm, no change with latest version.

I did "git clone https://github.com/apache/commons-bcel.git"; and "mvn
package".

stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ javac -cp
bcel-6.6.0-SNAPSHOT.jar MakeBadClassFile.java
stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ java -cp
bcel-6.6.0-SNAPSHOT.jar:. MakeBadClassFile
Now please try: java BadClassFile
stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ java BadClassFile
Error: Unable to initialize main class BadClassFile
Caused by: java.lang.VerifyError: (class: BadClassFile, method: main
signature: ([Ljava/lang/String;)V) Illegal type in constant pool
stefan@lenovo-ThinkPad-X220:~/dev/classreftest$

On Wed, 2 Feb 2022 at 22:59, Gary Gregory  wrote:

> You should try the latest from git master.
>
> Gary
>
> On Wed, Feb 2, 2022, 15:41 Stefan Reich
>  wrote:
>
> > Hi again,
> >
> > actual problem this time...
> >
> > I think I am doing everything right... Decompilation in javap -v looks
> > just like it should. But I get a VerifyError... I'm using JDK 17. Full
> > program attached. Please advice, thank you :)
> >
> > # javac -cp bcel-6.5.0.jar MakeBadClassFile.java
> > # java -cp bcel-6.5.0.jar:. MakeBadClassFile
> > # java BadClassFile
> > Error: Unable to initialize main class BadClassFile
> > Caused by: java.lang.VerifyError: (class: BadClassFile, method: main
> > signature: ([Ljava/lang/String;)V) Illegal type in constant pool
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: BCEL: Can't load Object.class using LDC

[Gary Gregory]

You should try the latest from git master.

Gary

On Wed, Feb 2, 2022, 15:41 Stefan Reich
 wrote:

> Hi again,
>
> actual problem this time...
>
> I think I am doing everything right... Decompilation in javap -v looks
> just like it should. But I get a VerifyError... I'm using JDK 17. Full
> program attached. Please advice, thank you :)
>
> # javac -cp bcel-6.5.0.jar MakeBadClassFile.java
> # java -cp bcel-6.5.0.jar:. MakeBadClassFile
> # java BadClassFile
> Error: Unable to initialize main class BadClassFile
> Caused by: java.lang.VerifyError: (class: BadClassFile, method: main
> signature: ([Ljava/lang/String;)V) Illegal type in constant pool
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org

Re: Optimizing ConstantPoolGen

[Stefan Reich]

Thank you

On Wed, 2 Feb 2022 at 20:24, Gary Gregory  wrote:

> I would guess not. PRs (with tests) are welcome in GitHub.
>
> Gary
>
> On Wed, Feb 2, 2022, 12:02 Stefan Reich
>  wrote:
>
> > Hi folks,
> >
> > I'm getting into compiling my own little scripting language into Java
> byte
> > code. Short experimentation with both Javassist and BCEL led me to use
> > BCEL.
> >
> > Just a quick question: Has anyone looked into optimizing constant lookups
> > in ConstantPoolGen (e.g. addInteger)? Right now, they are just scanned
> > linearly every time.
> >
> > Many greetings,
> > Stefan
> >
> > --
> > == Gaz.AI ==
> >
>

Re: Optimizing ConstantPoolGen

[Gary Gregory]

I would guess not. PRs (with tests) are welcome in GitHub.

Gary

On Wed, Feb 2, 2022, 12:02 Stefan Reich
 wrote:

> Hi folks,
>
> I'm getting into compiling my own little scripting language into Java byte
> code. Short experimentation with both Javassist and BCEL led me to use
> BCEL.
>
> Just a quick question: Has anyone looked into optimizing constant lookups
> in ConstantPoolGen (e.g. addInteger)? Right now, they are just scanned
> linearly every time.
>
> Many greetings,
> Stefan
>
> --
> == Gaz.AI ==
>

Optimizing ConstantPoolGen

[Stefan Reich]

Hi folks,

I'm getting into compiling my own little scripting language into Java byte
code. Short experimentation with both Javassist and BCEL led me to use BCEL.

Just a quick question: Has anyone looked into optimizing constant lookups
in ConstantPoolGen (e.g. addInteger)? Right now, they are just scanned
linearly every time.

Many greetings,
Stefan

-- 
== Gaz.AI ==

Re: [All] GSoC 2022

[Gilles Sadowski]

Hello.

Le mer. 2 févr. 2022 à 10:47, Alex Herbert  a écrit :
>
> On Mon, 31 Jan 2022 at 15:06, Gilles Sadowski  wrote:
> >
> > Hello.
> >
> > Le jeu. 27 janv. 2022 à 18:09, Alex Herbert  a 
> > écrit :
> > >
> > > I would be willing to go through GSOC again.
> >
> > Thanks; I know that back in 2020, it had been a disproportionate
> > amount of work...
> >
> > > I think that the
> > > statistics component could again serve as a project. There are some
> > > packages in Math that could be moved to make use of the updated
> > > distributions (e.g. math.stat.inference)
> >
> > That would be great, although I seem to notice that there
> > might be some dependency issues...
> >
> > > or perhaps a reworking of the
> > > math.stat.descriptive package to support using them with streams.
> >
> > +1
> >
> > > In the last iteration (GSOC 2020) we failed to get enough of a picture
> > > of the competence of candidates in the 'bonding phase' before places
> > > were formally allocated. I think we should require that a candidate
> > > can:
> > >
> > > - Open a PR on GitHub to add a feature in the topic area. It should be
> > > of non-trivial complexity and delivered to a quality ready to merge.
> >
> > Do you think that the above "stream support" could be that task?
>
> Yes. A simple class to compute a summary statistic such as:
>
> public interface Statistic {
> void add(R x);
> }
> public interface DoubleStatistic extends Statistic,
> DoubleConsumer, DoubleSupplier {
> // Composite interface
> }
>
> public Mean implements DoubleStatistic {
>   static Mean create();
>   // Overrides
>   public void accept(double x);
>   public void add(Mean m);
>   public double getAsDouble();
> }
>
> Used as:
>
> DoubleStream s;
> double u = s.collect(Mean::create, Mean::accept, Mean::add).getAsDouble();

To simplify the above, would we also provide
---CUT---
public Mean ... {
  // ...
  public static double collect(DoubleStream s) {
return s.collect(Mean::create, Mean::accept, Mean::add).getAsDouble();
  }
}
---CUT---

>
> The implementation(s) can be updated and expanded later using
> different underlying algorithms (simple sum, extended precision sum,
> rolling mean) by passing a choice to the create method.
>
> The project will involve how to move from this simple statistic to
> supporting IntStream, LongStream, DoubleStream as appropriate and
> allow combining statistics efficiently to obtain a customised summary
> statistic, perhaps by enum.
>
> This is for the StorelessUnivariateStatistic in Commons Math. A more
> detailed examination of the existing functionality would be required
> and use cases generated for each to understand how these can be
> supported in streams.

This study could be indeed started in the "bonding" period and will
fairly clearly indicate the candidate's potential.

> >
> > > - Show knowledge of the topic area beyond this single feature,
> > > demonstrating ability to continue to significantly contribute through
> > > a 3 month period in the subject area.
> >
> > That seems more fuzzy to define and assess (?).
>
> I agree; choosing candidates is a fuzzy area. This was meant to
> summarise my understanding of how we chose candidates last time. It is
> based on their proposal submitted to GSOC but also impressions from
> the bonding period.

As you noted in your post-GSoc 2020 suggestions, the issue
stemmed from not having a concrete way to evaluate the bonding
period.
This should be solved (for "[Statistics]") with your proposal above.

I'd be glad to get help with defining concrete tasks for the ideas
below. :-)

> >
> > Some ideas (for "Commons Math"):
> > 1. Redesign and modularization of the "ml" package
> >   -> main goal: enable multi-thread usage
> > 2. Abstracting the linear algebra utilities
> >   -> main goal: allow (runtime?) switch to alternative implementations
> > 3. Redesign and modularization of the "random" package
> >   -> main goal: general support of low-discrepancy sequences
> > 4. Refactoring and modularization of the "special" package
> >  -> main goal: ensure accuracy and performance and better API,
> >  add other functions (?).
> >
> > > Without this set of skills there will be little progress in the formal
> > > code period.
> >
> > :-}
> >
> > Shall we open a "GSoC 2022" report in each concerned JIRA project?
>
> Yes. I think we just create some tickets and tag them with the
> appropriate tag (GSOC 2022 ?). There should be some left over from
> last time to repurpose or use as templates for new ones.

Actually, I was thinking of creating one global "GSoC 2022" issue
in each component, that would list all the topics and a complete
description of their respective goal, and then sub-tasks (or linked
issues) for more specific discussions (once the topic is taken on
by at least one candidate).
I mean that we should separate the JIRA "new feature" report from
the report that tracks GSoC activity.  That way, we will be to close
the GSoC ticket when the time comes, and re

Re: [MATH][GA] Build Failure for PR #204

[Gilles Sadowski]

Hi.

Le mer. 2 févr. 2022 à 09:29, Avijit Basak  a écrit :
>
> Hi All
>
> Please see my comments below.
>
> [...]
>
>
> And there was this old issue that the "" should contain
> the name of the top-level package, i.e. "math4", not "math".
> -- There was a review comment for PR#197 to remove 4 from artifactid.
> "aherbert  on Sep 25, 2021
> 
>
> Remove the 4 from math4. The version is specified separately from the
> artifact ID."

Indeed, it seems that there are discrepant expectations or a
misunderstanding about how to compose the "".
In "Commons Math", it contains "math4" as (IIUC) a unique
identifier of the top-level package (that is updated with every
major version).  Because of that latter convention, it is true that
the "4" is redundant with the (major) version number.
However, it could also be construed that the redundancy may
be useful for stressing that artefacts with different major versions
can be used together (without "JAR hell").
That view of having the "packageId" as part of the artifact's name
is used in some other components (e.g. "[Lang]"[1]) but not all
(e.g. "[IO]"[2])...

>
> I've updated the feature branch with those changes. Please rebase.
>
> I've not yet looked at the code, but a question arose from looking at
> the dependencies: What is "jfreechart" used for in the "examples"?
> -- jfreechart is used to do a graphical plot of the optimization process.
>
> I've just updated the "k-means" example, removing the GUI along
> the way.  In general, I think that the example applications should
> follow the KISS principle (which here translates to:  Only write to the
> console or to files).  Since we don't intend to write full-fledged
> applications, building/testing should be as smooth as possible: GUIs
> entail unnecessary hassle for someone working from a remote
> (text) terminal.
> -- I shall remove that and the corresponding part of the code.

Thanks.
Please note that I don't suggest that you remove the tracking of
the optimization process (it is useful to have a trace in order to
check that evolution proceeds as expected), instead of displaying
a GUI, you can save snapshots (either in text form or, if the
check is more easily done graphically, by using the "[Imaging]"
component[3]).

Regards,
Gilles

> [...]
>

[1] 
https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=blob;f=pom.xml;h=4f12fdf537fd56a69d1b94567e22de99761ec775;hb=HEAD#l28
[2] 
https://gitbox.apache.org/repos/asf?p=commons-io.git;a=blob;f=pom.xml;h=8f61ca0177a056a80dda656dbb70a9774adac548;hb=HEAD#l26
[3] See e.g. the "kmeans/image" module.

>
> Thanks & Regards
> --Avijit Basak
>
> On Tue, 1 Feb 2022 at 05:24, Gilles Sadowski  wrote:
>
> > Hello.
> >
> > Le lun. 31 janv. 2022 à 06:27, Avijit Basak  a
> > écrit :
> > >
> > > Hi All
> > >
> > > Please find my comments below.
> > >
> > > >There is no attachment (I think that the ML manager strips those).
> > > >Please copy/paste the relevant part of the console log (or provide
> > > >a link to it).
> > > --The build was done locally with a fresh clone of the feature branch.
> >
> > Strange that the "pom.xml" in PR #204 still refers to version 1.0 of
> > Commons Numbers, instead of version 1.1-SNAPSHOT.
> > This creates many "NoClassDefFound" errors that were fixed with
> > commit 7e2213f2e5a536ad49d549d21f9eed9e71db5638 in branch
> > "feature__MATH-1563__genetic_algorithm" branch 6 days ago.
> >
> > Anyways, after fetching your PR and rebasing on that branch, the
> > build is successful.
> >
> > Nevertheless, I had to fix/consolidate many POM files that contained
> > a slew of duplicate declarations (the "dependency management" is
> > done at the highest possible level, to ensure version consistency).
> > Also, please use the same formatting rules as in existing files (in
> > POM files, the indentation is 2 spaces).
> >
> > And there was this old issue that the "" should contain
> > the name of the top-level package, i.e. "math4", not "math".
> >
> > I've updated the feature branch with those changes. Please rebase.
> >
> > I've not yet looked at the code, but a question arose from looking at
> > the dependencies: What is "jfreechart" used for in the "examples"?
> > I've just updated the "k-means" example, removing the GUI along
> > the way.  In general, I think that the example applications should
> > follow the KISS principle (which here translates to:  Only write to the
> > console or to files).  Since we don't intend to write full-fledged
> > applications, building/testing should be as smooth as possible: GUIs
> > entail unnecessary hassle for someone working from a remote
> > (text) terminal.
> >
> > > Please find the log below. Kindly let me know once the build is
> > successful.
> > > The command was "*mvn clean verify apache-rat:check checkstyle:check
> > > pmd:check spotbugs:check javadoc:javadoc*".
> >
> > As Alex noted, you should ensure that th

Re: [VOTE][CANCELLED] Release Apache Commons Daemon 1.2.5 based on RC1

[Gary Gregory]

1.3.0, not 1.30 ;-)

Gary

On Wed, Feb 2, 2022, 02:29 Mark Thomas  wrote:

> This vote has been cancelled as the consensus is that the next version
> needs to be 1.30 rather than 1.2.5.
>
> Mark
>
>
> On 27/01/2022 22:29, Mark Thomas wrote:
> > We have fixed a few bugs and added some enhancements since Apache
> > Commons Daemon 1.2.4 was released, so I would like to release Apache
> > Commons Daemon 1.2.5.
> >
> > Apache Commons Daemon 1.2.5 RC1 is available for review here:
> >  https://dist.apache.org/repos/dist/dev/commons/daemon/1.2.5-RC1
> > (svn revision 52304)
> >
> > The Git tag commons-daemon-1.2.5-RC1 commit for this RC is
> > 6cbcf2368bc91eceae80455613e089a635bfc98b
> >
> > which you can browse here:
> >
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=6cbcf2368bc91eceae80455613e089a635bfc98b
> >
> >
> > You may checkout this tag using:
> >  git clone https://gitbox.apache.org/repos/asf/commons-daemon.git
> > --branch commons-daemon-1.2.5-RC1 commons-daemon-1.2.5-RC1
> >
> > Maven artifacts are here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1578/commons-daemon/commons-daemon/1.2.5/
> >
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> >
> commons-daemon-1.2.5.jar=742cda24782493bc76f8276810a582deaeb622e48f3334bbd0d9e8e08efbfe367ea48a804eb51874a1823e8523fb318ab1f9f6958e71bc37e4b10dc5d01e652c
>
> >
> >
> commons-daemon-1.2.5-bin.tar.gz=1d41efa490ca201132767c08c8b54207714701851c42195916d3e9d0b1731a69a5bcb41f877e2d35079aafecff9c47cb828637399794339307e0ab66e4bc5589
>
> >
> >
> commons-daemon-1.2.5-native-src.tar.gz=6f3968f6cdc96cf784c92547123896c32110c932dc293a3b0fc3a093490b0699c3053f8c3137e39eea3d6c20d7332f98b90dc29a3e2737356d3cde1b4b4e0e2e
>
> >
> >
> commons-daemon-1.2.5-native-src.zip=20ebd8d897dc51828c71162ecd0337158b91b51fc10ba3f65964a68b0c61466b50b42c44f6aee84db7c621a0d420514e533b50d9deebb4a6b50ddb837e765f8f
>
> >
> >
> commons-daemon-1.2.5-src.zip=1079969d99c2047f8b8216ca820e731c1dc62ca52d1919bf1deb6b04f32b0dc3ea1ef871a251e03558de665fe3633c29fb13ead642936a51ea1d31431d76be8b
>
> >
> >
> commons-daemon-1.2.5-src.tar.gz=937042d811b9dc6aaefffdf523d8ee52193342120fb39fc50c7607931f712d6ba9ebae6e2409bf089689fea9064f9107f62627ffeca98335750e2431c828a328
>
> >
> >
> commons-daemon-1.2.5-bin.zip=1760fa09086611acecd65655fcf1e2f20527af3663b3115f3365283dde700871ae467a7834fb77dac1ac2b9aedd90ac4dfff7812dca0f9f668afe93ab4c14b54
>
> >
> >
> commons-daemon-1.2.5-bin-windows.zip=b860595c1c104c07678fc25e7efe242b29e4dcc9f12cd564a563adcbaa4503317f8437ccb8ed79b318fbea43a43df20d89ac9b0e83a8cd6fd981722fd5da37f4
>
> >
> >
> >
> > KEYS:
> >https://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner than 72 hours from now.
> >
> >[ ] +1 Release these artifacts
> >[ ] +0 OK, but...
> >[ ] -0 OK, but really should fix...
> >[ ] -1 I oppose this release because...
> >
> > Thank you,
> >
> > Mark
> >
> > -
> > 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: [All] GSoC 2022

[Alex Herbert]

On Mon, 31 Jan 2022 at 15:06, Gilles Sadowski  wrote:
>
> Hello.
>
> Le jeu. 27 janv. 2022 à 18:09, Alex Herbert  a 
> écrit :
> >
> > I would be willing to go through GSOC again.
>
> Thanks; I know that back in 2020, it had been a disproportionate
> amount of work...
>
> > I think that the
> > statistics component could again serve as a project. There are some
> > packages in Math that could be moved to make use of the updated
> > distributions (e.g. math.stat.inference)
>
> That would be great, although I seem to notice that there
> might be some dependency issues...
>
> > or perhaps a reworking of the
> > math.stat.descriptive package to support using them with streams.
>
> +1
>
> > In the last iteration (GSOC 2020) we failed to get enough of a picture
> > of the competence of candidates in the 'bonding phase' before places
> > were formally allocated. I think we should require that a candidate
> > can:
> >
> > - Open a PR on GitHub to add a feature in the topic area. It should be
> > of non-trivial complexity and delivered to a quality ready to merge.
>
> Do you think that the above "stream support" could be that task?

Yes. A simple class to compute a summary statistic such as:

public interface Statistic {
void add(R x);
}
public interface DoubleStatistic extends Statistic,
DoubleConsumer, DoubleSupplier {
// Composite interface
}

public Mean implements DoubleStatistic {
  static Mean create();
  // Overrides
  public void accept(double x);
  public void add(Mean m);
  public double getAsDouble();
}

Used as:

DoubleStream s;
double u = s.collect(Mean::create, Mean::accept, Mean::add).getAsDouble();

The implementation(s) can be updated and expanded later using
different underlying algorithms (simple sum, extended precision sum,
rolling mean) by passing a choice to the create method.

The project will involve how to move from this simple statistic to
supporting IntStream, LongStream, DoubleStream as appropriate and
allow combining statistics efficiently to obtain a customised summary
statistic, perhaps by enum.

This is for the StorelessUnivariateStatistic in Commons Math. A more
detailed examination of the existing functionality would be required
and use cases generated for each to understand how these can be
supported in streams.

>
> > - Show knowledge of the topic area beyond this single feature,
> > demonstrating ability to continue to significantly contribute through
> > a 3 month period in the subject area.
>
> That seems more fuzzy to define and assess (?).

I agree; choosing candidates is a fuzzy area. This was meant to
summarise my understanding of how we chose candidates last time. It is
based on their proposal submitted to GSOC but also impressions from
the bonding period.

>
> Some ideas (for "Commons Math"):
> 1. Redesign and modularization of the "ml" package
>   -> main goal: enable multi-thread usage
> 2. Abstracting the linear algebra utilities
>   -> main goal: allow (runtime?) switch to alternative implementations
> 3. Redesign and modularization of the "random" package
>   -> main goal: general support of low-discrepancy sequences
> 4. Refactoring and modularization of the "special" package
>  -> main goal: ensure accuracy and performance and better API,
>  add other functions (?).
>
> > Without this set of skills there will be little progress in the formal
> > code period.
>
> :-}
>
> Shall we open a "GSoC 2022" report in each concerned JIRA project?

Yes. I think we just create some tickets and tag them with the
appropriate tag (GSOC 2022 ?). There should be some left over from
last time to repurpose or use as templates for new ones.

Alex

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

Re: [MATH][GA] Build Failure for PR #204

[Avijit Basak]

Hi All

Please see my comments below.

>Strange that the "pom.xml" in PR #204 still refers to version 1.0 of
>Commons Numbers, instead of version 1.1-SNAPSHOT.
>This creates many "NoClassDefFound" errors that were fixed with
>commit 7e2213f2e5a536ad49d549d21f9eed9e71db5638 in branch
>"feature__MATH-1563__genetic_algorithm" branch 6 days ago.
-- I could not work further on PR#204. As there was an issue with the
local build, I did not try to merge any further changes.

Anyways, after fetching your PR and rebasing on that branch, the
build is successful.
--Thanks for the confirmation.

Nevertheless, I had to fix/consolidate many POM files that contained
a slew of duplicate declarations (the "dependency management" is
done at the highest possible level, to ensure version consistency).
Also, please use the same formatting rules as in existing files (in
POM files, the indentation is 2 spaces).
-- I have missed these two points.

And there was this old issue that the "" should contain
the name of the top-level package, i.e. "math4", not "math".
-- There was a review comment for PR#197 to remove 4 from artifactid.
"aherbert  on Sep 25, 2021


Remove the 4 from math4. The version is specified separately from the
artifact ID."

I've updated the feature branch with those changes. Please rebase.

I've not yet looked at the code, but a question arose from looking at
the dependencies: What is "jfreechart" used for in the "examples"?
-- jfreechart is used to do a graphical plot of the optimization process.

I've just updated the "k-means" example, removing the GUI along
the way.  In general, I think that the example applications should
follow the KISS principle (which here translates to:  Only write to the
console or to files).  Since we don't intend to write full-fledged
applications, building/testing should be as smooth as possible: GUIs
entail unnecessary hassle for someone working from a remote
(text) terminal.
-- I shall remove that and the corresponding part of the code.

> Please find the log below. Kindly let me know once the build is
successful.
> The command was "*mvn clean verify apache-rat:check checkstyle:check
> pmd:check spotbugs:check javadoc:javadoc*".

>As Alex noted, you should ensure that the build is successful with
>the supported version of the JDK (i.e. Java 8 currently).
>[If you encounter problems with a later version, it's always nice to
>file a JIRA report, but fixing such issues is probably low priority.]
--I have updated my JDK to version 8. The build is successful now. Thanks.


Thanks & Regards
--Avijit Basak

On Tue, 1 Feb 2022 at 05:24, Gilles Sadowski  wrote:

> Hello.
>
> Le lun. 31 janv. 2022 à 06:27, Avijit Basak  a
> écrit :
> >
> > Hi All
> >
> > Please find my comments below.
> >
> > >There is no attachment (I think that the ML manager strips those).
> > >Please copy/paste the relevant part of the console log (or provide
> > >a link to it).
> > --The build was done locally with a fresh clone of the feature branch.
>
> Strange that the "pom.xml" in PR #204 still refers to version 1.0 of
> Commons Numbers, instead of version 1.1-SNAPSHOT.
> This creates many "NoClassDefFound" errors that were fixed with
> commit 7e2213f2e5a536ad49d549d21f9eed9e71db5638 in branch
> "feature__MATH-1563__genetic_algorithm" branch 6 days ago.
>
> Anyways, after fetching your PR and rebasing on that branch, the
> build is successful.
>
> Nevertheless, I had to fix/consolidate many POM files that contained
> a slew of duplicate declarations (the "dependency management" is
> done at the highest possible level, to ensure version consistency).
> Also, please use the same formatting rules as in existing files (in
> POM files, the indentation is 2 spaces).
>
> And there was this old issue that the "" should contain
> the name of the top-level package, i.e. "math4", not "math".
>
> I've updated the feature branch with those changes. Please rebase.
>
> I've not yet looked at the code, but a question arose from looking at
> the dependencies: What is "jfreechart" used for in the "examples"?
> I've just updated the "k-means" example, removing the GUI along
> the way.  In general, I think that the example applications should
> follow the KISS principle (which here translates to:  Only write to the
> console or to files).  Since we don't intend to write full-fledged
> applications, building/testing should be as smooth as possible: GUIs
> entail unnecessary hassle for someone working from a remote
> (text) terminal.
>
> > Please find the log below. Kindly let me know once the build is
> successful.
> > The command was "*mvn clean verify apache-rat:check checkstyle:check
> > pmd:check spotbugs:check javadoc:javadoc*".
>
> As Alex noted, you should ensure that the build is successful with
> the supported version of the JDK (i.e. Java 8 currently).
> [If you encounter problems with a later version, it's alwa