This doesn’t seem to copy. (to /var/tmp/… on the local directory for the local server)
If I set an absolute path, prefixed with /Users/histed, I get a copy, with the full path prepended.
Full path, meaning: If I ask for
resource (‘…/…/…/Documents/MWorks/ExptImages/directory’) with x,y,z in ‘directory’
I’d expect
/var/tmp/…/MWorks/ExperimentCache/_mwel_name/tmp/directory/x (/y, /z etc),
not
/var/tmp/…/MWorks/ExperimentCache/_mwel_name/tmp/Documents/MWorks/ExptImages etc.
In other words, I’d think the last directory on a specified path should appear in the tmp directory, so we can later refer to images as ‘directory/x/00.png’ instead of the full path: ‘Documents/MWorks/ExptImages/directory/x’ etc.
That matters for us because we don’t want to pass the full path, because the username can change across computers.
What do you think about a change like this?
A second feature request:
Can you allow ~ expansion in these resource paths? Thus
resource(‘~/Documents/MWorks/etcetc’) then etcetc will be found and put in the tmp directory. Same rationale here: we don’t want to hardcode the user directory.
MWorks doesn’t handle ..'s in paths correctly. (This is a known issue.) I should probably add some code that looks for them and rejects them outright, but sometimes you can get away with using them, and I don’t want to break existing experiments that rely on that. (One exception: ..'s in paths to included files in MWEL are handled correctly.)
The safest approach is for all paths used in your MWEL file to be relative to the directory containing the MWEL file, with no ..'s. To use files located elsewhere in the filesystem, create symbolic links to them or to directories that contain them. In the example you cite, this would mean creating a symbolic link named directory that points to ../../../Documents/MWorks/ExptImages/directory. Then, your resource declaration would just be
resource ('directory')
and you could refer to images like directory/x/00.png as you want.
I’ve attached an example experiment that demonstrates this approach. It also lets you specify the image path you want in a variable, so that you can manually set the stimulus to use (e.g. via MWClient’s variables window) between runs. You asked about this when we chatted the other day.
I don’t think ~ expansion makes sense for MWorks. The expansion can potentially happen on two different machines (running MWClient and MWServer, respectively), and there’s no guarantee that the name of the current user is the same on both machines. This would be particularly unhelpful with MWorks for iPad, where the user’s home directory, if it exists at all, isn’t accessible to applications.
Again, a symbolic link to the desired resource directory, at or below the directory in which the MWEL file resides, is the best approach.
Thanks for this. I’m going to outline an argument for why changes could be useful for everyone, based on our experience.
Tilde expansion in resource statements: I see why tilde expansion wouldn’t work in MWorks strings generally. But in resource statements specifically, if I understand right, these paths are by definition on the client machine (and thus are sent to the server with a new path.)
Last-path-component on Server for resource statements: It is very awkward to have ‘Users/user/a/b/c/d/’ in a resource statement and then have to do ‘Users/user/a/b/c/d/imagedir/image.png’ in a variable, etc instead of ‘imagedir/image.png’. I can see why you want to match MWorks code/behavior in other areas which expands full paths in many places. How about an option on the resource statement ‘strip_parent_path’ which if true saves the above as ‘tmp/imagedir’ in the server working path rather than ‘tmp/Users/user/a/b/c/d/imagedir/image.png’? This has the additional advantage of handling relative paths correctly.
I really want to avoid symlinks - I had added Python code to our experiment to create them based on your prior example, but have decided it’s too fragile and adds too much complication (need a second variable which is updated with the symlink name, have to read and write multiple variable values because we use multiple stimuli, etc.) and I just removed it.
I think we are ok with the current MWorks behavior with no change. Right now I just enforce that people have to copy images into a subdir of the directory containing the experiment XML.
And for us variable docstrings (tooltips etc) are a higher priority than the above two things even if we needed them.
But I would still say the above would be required to allow images anywhere on the Client filesystem to be used. That’s what we’d expect given our multi-rig setup. Happy to discuss next time we see each other, or not.
No, the paths are used on both machines: on the client when the experiment is packaged and sent to the server, and on the server when the experiment is loaded.
I like this idea. I think I’d make it more general and let you specify an arbitrary “working path” for the resource on the server. The working path would be required to be relative to the directory containing the experiment source, with no ..'s, but otherwise it could be anything.
Also, if your experiment specifies a working path, then MWorks could safely expand ..'s and ~'s on the client side, since paths containing them would be mapped explicitly to subpaths of the server-side working directory. That would give you a lot of flexibility in locating the desired paths on the client while still keeping the server-side paths simple.