Re: [chuck-users] me.source* always empty with chuck add

I didn't consider remote machines, but now that I am it might make more sense to keep the relative path. That would avoid the difference between /Users and /home between OSX and linux, for example. That makes it so I can just untar or rsync a pack of assets, and as long as I work from the root of that asset pack, and the remote chuck instance is also running in the root, we'll be in sync. On Mon, Sep 3, 2012 at 3:14 PM, Spencer Salazar wrote:

Hey Todd,

Thanks for catching this. Its not totally clear what me.sourceDir/Path() should do in the case of a remote VM -- if the 'chuck --loop' instance was on a completely different machine then basically none of this would work.

Probably what makes sense for most sensible use cases is to supply the full absolute path.

spencer

On Sun, Sep 2, 2012 at 1:38 PM, Todd Willey wrote:

...

When I put some EM_error3 debugging in chuck_vm.cpp in the MSG_ADD condition, it looks like msg->code->name is equivilent to the argument passed (like "examples/otf_01.ck"), but msg->code->filename is always empty. Debugging shred_sourceDir in chuck_lang.cpp, it seems like shred->code->filename is also empty, leading to the empty sourceDir result.

The following fix seems to work, but I'm not sure this is the right way to do it? It still requires the looper and the adder to be in the same relative path. A better fix might be to send the full pathname.

Index: chuck_otf.cpp =================================================================== --- chuck_otf.cpp (revision 195) +++ chuck_otf.cpp (working copy) @@ -193,6 +193,7 @@ code = compiler->output(); // name it code->name += string(msg->buffer); + code->filename = code->name;

// set the flags for the command cmd->type = msg->type;

On Sun, Sep 2, 2012 at 2:14 PM, Kassen wrote:

...

On Sat, Sep 01, 2012 at 10:42:20PM -0400, Todd Willey wrote:

...

The examples/otf_01.ck file recommends running `chuck --loop` in one terminal, and `chuck + otf_01.ck` in another. The looping vm bombs out at:

me.sourceDir() + "/data/kick.wav" => buf.read;

Weird! It sound like the OS and perhaps even type of shell might matter here. Also, just to be use; was the dirt containing otf*.ck your current dir when this happened?

Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

---

chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users