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

[Todd Willey]

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
<spencer at ccrma.stanford.edu> 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 <xtoddx at gmail.com> 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 <signal.automatique at gmail.com> 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 at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users