Mailing-List: contact dev-help@systemml.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@systemml.incubator.apache.org
From: dusenberrymw@gmail.com
Content-Type: multipart/alternative;
	boundary=Apple-Mail-969B85F1-D6D7-40A8-ACAB-D9149574C954
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 13 Feb 2017 10:56:14 -0800
Subject: Re: Namespace handling w/ imports
Message-Id: <AFF9BFBD-FDFB-4BD4-8491-2CB3F5D77F51@gmail.com>
References: <39b71f78-2562-27c0-109b-1ab558d31b69@gmail.com> <OFAAD36C3F.9491317C-ON002580C6.0019EF94-882580C6.00226237@notes.na.collabserv.com>
In-Reply-To: <OFAAD36C3F.9491317C-ON002580C6.0019EF94-882580C6.00226237@notes.na.collabserv.com>
To: dev@systemml.incubator.apache.org
archived-at: Mon, 13 Feb 2017 18:56:27 -0000

--Apple-Mail-969B85F1-D6D7-40A8-ACAB-D9149574C954
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Thanks, Matthias for bringing this up.  As Glenn pointed out, the full file p=
ath as the namespace is needed so that we can effectively build libraries/pa=
ckages for SystemML, rather than just single-file scripts.  If you truncate t=
he namespace down to just the name of the specific file, then you prevent th=
e ability to build a library in which the same file name is used in multiple=
 folders.

Another note with the example presented.  Assuming that you are running the `=
mnist_lenet-train.dml` script, the `train` and `predict` functions are defin=
ed in `mnist_lenet.dml`, which is imported, so those functions would not be i=
n the default namespace.

-Mike

--

Mike Dusenberry
GitHub: github.com/dusenberrymw
LinkedIn: linkedin.com/in/mikedusenberry

Sent from my iPhone.


> On Feb 12, 2017, at 10:15 PM, Glenn Weidner <gweidner@us.ibm.com> wrote:
>=20
> Use of source filenames instead of default namespace helped address variou=
s issues and tasks under https://issues.apache.org/jira/browse/SYSTEMML-590 t=
hat were encountered when creating the SystemML-NN script library. Unit test=
s were also added to cover different import scenarios. As I recall, function=
 name conflicts could potentially occur between independent source files whe=
n global default namespace used. It also helped simplify calling dml-bodied f=
unctions when a file was imported by another.
>=20
> Thanks,
> Glenn
>=20
>=20
> Matthias Boehm ---02/12/2017 12:30:35 AM---While debugging our mnist_lenet=
 script, I encountered an issue with our namespace handling with imp
>=20
> From: Matthias Boehm <mboehm7@googlemail.com>
> To: dev@systemml.incubator.apache.org
> Date: 02/12/2017 12:30 AM
> Subject: Namespace handling w/ imports
>=20
>=20
>=20
>=20
> While debugging our mnist_lenet script, I encountered an issue with our=20=

> namespace handling with imports. Here is the related function call graph=20=

> (after inlining):
>=20
> ----FUNCTION CALL GRAPH
> ------MAIN PROGRAM
> --------.\mnist_lenet.dml::train
> ----------.\nn/layers/dropout.dml::forward
> ----------.\mnist_lenet.dml::predict
>=20
> but it should read as follows
>=20
> ----FUNCTION CALL GRAPH
> ------MAIN PROGRAM
> --------.defaultNS::train
> ----------dropout::forward
> ----------.defaultNS::predict
>=20
> The namespace handling was changed a while ago. So my question is: was=20
> there a necessity to encode the filenames in the namespace or is this=20
> just a bug?
>=20
>=20
> Regards,
> Matthias
>=20
>=20
>=20
>=20

--Apple-Mail-969B85F1-D6D7-40A8-ACAB-D9149574C954--