systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Namespace handling w/ imports
Date Mon, 13 Feb 2017 18:56:14 GMT
Thanks, Matthias for bringing this up.  As Glenn pointed out, the full file path as the namespace
is needed so that we can effectively build libraries/packages for SystemML, rather than just
single-file scripts.  If you truncate the namespace down to just the name of the specific
file, then you prevent the 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 defined in `mnist_lenet.dml`, which is imported,
so those functions would not be in the default namespace.



Mike Dusenberry

Sent from my iPhone.

> On Feb 12, 2017, at 10:15 PM, Glenn Weidner <> wrote:
> Use of source filenames instead of default namespace helped address various issues and
tasks under that were encountered when
creating the SystemML-NN script library. Unit tests were also added to cover different import
scenarios. As I recall, function name conflicts could potentially occur between independent
source files when global default namespace used. It also helped simplify calling dml-bodied
functions when a file was imported by another.
> Thanks,
> Glenn
> 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
> From: Matthias Boehm <>
> To:
> Date: 02/12/2017 12:30 AM
> Subject: Namespace handling w/ imports
> While debugging our mnist_lenet script, I encountered an issue with our 
> namespace handling with imports. Here is the related function call graph 
> (after inlining):
> --------.\mnist_lenet.dml::train
> ----------.\nn/layers/dropout.dml::forward
> ----------.\mnist_lenet.dml::predict
> but it should read as follows
> --------.defaultNS::train
> ----------dropout::forward
> ----------.defaultNS::predict
> The namespace handling was changed a while ago. So my question is: was 
> there a necessity to encode the filenames in the namespace or is this 
> just a bug?
> Regards,
> Matthias

  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message