dataPath() not working when app is not run from appdir (linux) #2195

Closed
charlesgoyard opened this Issue Nov 1, 2013 · 3 comments

Comments

Projects
None yet
2 participants
@charlesgoyard

On Linux with java 1.7 :
When exporting the following code:

println("datapath: " + dataPath("somedata"));

and running:

#correct
cd /home/charles/w/processing/sketchbook/datapathbug/application.linux32
./ datapathbug
datapath: /home/charles/w/processing/sketchbook/datapathbug/application.linux32/data/somedata
# wrong
cd /
/home/charles/w/processing/sketchbook/datapathbug/application.linux32/datapathbug
datapath: /data/somedata

I could get a bit closer by doing:

import java.net.URL;
URL urlpath = datapathbug.class.getProtectionDomain().getCodeSource().getLocation();
   File filepath = new File(urlpath.getPath());

but it returns the application.linux32/lib/databug.jar path. Splitting this string sounds like an ugly hack.

This can be related to issue #2181, but I'm not sure.

A quick fix is to add

cd $APPDIR

in the shell script generated when exporting while things get sorted out.

Thanks,
Charles

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 12, 2014

Member

How are you using dataPath() that this is necessary? It's not a documented feature, and createInput() (or createReader() and others) should cover most of what you need.

Member

benfry commented May 12, 2014

How are you using dataPath() that this is necessary? It's not a documented feature, and createInput() (or createReader() and others) should cover most of what you need.

@charlesgoyard

This comment has been minimized.

Show comment
Hide comment
@charlesgoyard

charlesgoyard May 13, 2014

Hi Ben,
thanks for watching at this issue.
dataPath() is sometimes necessary with third party libraries:

  • controlP5 for saving settings,
  • openNI for accessing .skel files (UserSaveCalib example),
  • Here's a snippet that builds a list of matching files in a directory:
void build_pathlist() {
    pathlist = new ArrayList<File>();
    File dir = new File(dataPath(""));
    for (File f: dir.listFiles()) {
        if (f.getName().endsWith(".tsv") ||
            f.getName().endsWith(".txt")) {
            pathlist.add(f);
        }
    }
    Collections.sort(pathlist);
}
  • it's also necessary to have a working version anyway, since createInputRaw() relies on it.

Maybe controlP5 and openNI should use datapath() internally by default, I don't know.
What I find is:

  • the method exists;
  • in some cases it's not working;
  • fixing this in Java is not that easy, but fixing it from the shell is.

Are you asking because dataPath() will go away ?

Thanks for the good work on P5 !
Charles

Hi Ben,
thanks for watching at this issue.
dataPath() is sometimes necessary with third party libraries:

  • controlP5 for saving settings,
  • openNI for accessing .skel files (UserSaveCalib example),
  • Here's a snippet that builds a list of matching files in a directory:
void build_pathlist() {
    pathlist = new ArrayList<File>();
    File dir = new File(dataPath(""));
    for (File f: dir.listFiles()) {
        if (f.getName().endsWith(".tsv") ||
            f.getName().endsWith(".txt")) {
            pathlist.add(f);
        }
    }
    Collections.sort(pathlist);
}
  • it's also necessary to have a working version anyway, since createInputRaw() relies on it.

Maybe controlP5 and openNI should use datapath() internally by default, I don't know.
What I find is:

  • the method exists;
  • in some cases it's not working;
  • fixing this in Java is not that easy, but fixing it from the shell is.

Are you asking because dataPath() will go away ?

Thanks for the good work on P5 !
Charles

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 12, 2015

Member

Fixed for 3.0 beta 4.

However, none of those are good reasons to use the data path. It's not documented and it behaves differently than most people expect. Libraries should use createInput() (with a specific path that makes sense for the library's use) and createOutput() if they need to read/write files. Maybe it needs to be removed so that there's no confusion.

If a specific path is needed, sketchPath() is a better option. But keep in mind that a sketch may be bundled inside a .app file on OS X, so creating files nearby mean a folder just hanging out inside /Applications, or wherever the .app is located.

Member

benfry commented Aug 12, 2015

Fixed for 3.0 beta 4.

However, none of those are good reasons to use the data path. It's not documented and it behaves differently than most people expect. Libraries should use createInput() (with a specific path that makes sense for the library's use) and createOutput() if they need to read/write files. Maybe it needs to be removed so that there's no confusion.

If a specific path is needed, sketchPath() is a better option. But keep in mind that a sketch may be bundled inside a .app file on OS X, so creating files nearby mean a folder just hanging out inside /Applications, or wherever the .app is located.

@benfry benfry closed this Aug 12, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment