systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deron Eriksson <>
Subject Re: Project folder structure
Date Tue, 09 Feb 2016 23:31:45 GMT
With regards to DML and PyDML, the test scripts are in src/test/scripts, so
something similar in main (src/main/scripts) may have some good points to
it. I've used Maven for a long time so personally I'm biased towards
Maven's "convention over configuration" paradigm. However, at the same time
it is nice to have the DML/PyDML scripts available at the root.

I'm a bit confused by the dev folder at the root of the project. If it only
contains a single script (dev/release/, maybe dev needs to
be deleted and the script needs to move elsewhere (the root of the project
itself or into another directory, but it doesn't seem like it would be a
good fit in the scripts directory with the DML). Is there some place under
src/ for Would it fall under src/main/resources?
Somewhere else?

Perhaps we need some terminology to distinguish between DML/PyDML 'scripts'
and other 'scripts' such as


On Tue, Feb 9, 2016 at 1:21 PM, Luciano Resende <>

> On Tue, Feb 9, 2016 at 12:43 PM, Matthias Boehm <> wrote:
> > -1
> >
> > I don't see a compelling argument for this unnecessary change to a more
> > complex project structure just to follow Spark which is not directly
> > comparable - both in project size and content. For example, our
> algorithms
> > are at the same time a library of algorithms as well as samples for how
> to
> > write new algorithms. From my perspective, our major goal should be
> > "simplicity via minimality" not "simplicity via common structure" because
> > the latter would always require us to stay in sync.
> >
> > Regards,
> > Matthias
> >
> >
> I just don't see why it would make sense to add "notebooks" and "bash
> release scripts" all inside scripts which to me is currently filled with ML
> Algorithms in different stages or for different purposes.
> I am not keen on "simplicity via minimality" neither "simplicity via common
> structure"... I am keen on what makes sense I (and thus drive adoption) for
> someone that is first trying to look trough SystemML code, particularly
> folks that are already used to some best practices or with some other
> projects on the same area.
> --
> Luciano Resende

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message