me.source* always empty with chuck add - chuck-users - lists.cs.princeton.edu

newer
problems with chubgraphs

me.source* always empty with chuck add

older
one sample block size vs demand...

Todd Willey

1 Sep 2012 1 Sep '12

10:42 p.m.

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; with: [chuck](via SndBuf): cannot stat file '/data/kick.wav'... After adding some debugging statements, it looks like me.sourceDir returns the empty string, as does me.sourcePath. If there is a more appropriate place to report/discuss these things, please let me know. -todd[1]

Reply

Sign in to reply online Use email software

Show replies by date

Kassen

2 Sep 2 Sep

2:14 p.m.

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.

Reply

Sign in to reply online Use email software

Todd Willey

4:38 p.m.

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

Reply

Sign in to reply online Use email software

Spencer Salazar

3 Sep 3 Sep

3:14 p.m.

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

Reply

Sign in to reply online Use email software

Todd Willey

3:30 p.m.

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

Reply

Sign in to reply online Use email software

4492

Age (days ago)

4493

Last active (days ago)

Download

4 comments

3 participants

tags

participants (3)

Kassen
Spencer Salazar
Todd Willey