Is there a way to allow an std::cout within my opcode to print in the
terminal? I am trying to debug an opcode I just made that causes a seg
fault

I guess a better question might be, what is the best way to debug a
new opcode? Or at least, the best way to get info in the about what is
causing the seg fault

Pete

On Tue, Jan 26, 2016 at 1:04 PM, Peter Burgess
 wrote:
> Is there a way to allow an std::cout within my opcode to print in the
> terminal? I am trying to debug an opcode I just made that causes a seg
> fault
>

The best way to debug is to think -- that is what I always told my 
students.

An help is to use printf (I write C) and the macros __LINE__ and __FILE__

Ni reason not to use this crutch to inticate where to look.

In bad cases gdb is useful, especially to locate crash sites

At least that is what I do.

==John ff

On Tue, 26 Jan 2016, Peter Burgess wrote:

> I guess a better question might be, what is the best way to debug a
> new opcode? Or at least, the best way to get info in the about what is
> causing the seg fault
>
> Pete
>
> On Tue, Jan 26, 2016 at 1:04 PM, Peter Burgess
>  wrote:
>> Is there a way to allow an std::cout within my opcode to print in the
>> terminal? I am trying to debug an opcode I just made that causes a seg
>> fault
>>
>> Pete

I was trying to setup gbd to help me, but it needs me to setup a host
application as it's a .so file. I tried fiddling with this, but not
sure how exactly to get that to work... I've set csound as the host
executable, and a filepath to the relevant .csd as an arguement, but
that's not working out.

if you do stick some printf instances in the opcode source, how do you
get that to print to the terminal when you run a csd that uses the
opcode?

I suppose it's worth mentioning that I'm just using my opcode as a
pluggin rather than building it into csound, but I would have thought
that printf and cout functions should work just the same either way

Pete

On Tue, Jan 26, 2016 at 1:49 PM, jpff  wrote:
> The best way to debug is to think -- that is what I always told my students.
>
> An help is to use printf (I write C) and the macros __LINE__ and __FILE__
>
> Ni reason not to use this crutch to inticate where to look.
>
> In bad cases gdb is useful, especially to locate crash sites
>
> At least that is what I do.
>
> ==John ff
>
>
> On Tue, 26 Jan 2016, Peter Burgess wrote:
>
>> I guess a better question might be, what is the best way to debug a
>> new opcode? Or at least, the best way to get info in the about what is
>> causing the seg fault
>>
>> Pete
>>
>> On Tue, Jan 26, 2016 at 1:04 PM, Peter Burgess
>>  wrote:
>>>
>>> Is there a way to allow an std::cout within my opcode to print in the
>>> terminal? I am trying to debug an opcode I just made that causes a seg
>>> fault
>>>
>>> Pete
>>
>>

Or should it print my printf and cout messages anyway? I have couts at
the beginning and end of my init function, as well as in various
places in my perform function, so if it should be outputting these
message, then my error must happen immediately...

could this header file cause a segfault:

typedef struct
{
    OPDS h;                                    // required header
    MYFLT *out;                                // output args
    MYFLT *in;                                 // input args
    MYFLT *prevIn;                           // Table that holds
previous input samples
    int *sumTable;                          // Table that holds number
of samples to sum per motion

} sumTableStruct;

On Tue, Jan 26, 2016 at 1:56 PM, Peter Burgess
 wrote:
> I was trying to setup gbd to help me, but it needs me to setup a host
> application as it's a .so file. I tried fiddling with this, but not
> sure how exactly to get that to work... I've set csound as the host
> executable, and a filepath to the relevant .csd as an arguement, but
> that's not working out.
>
> if you do stick some printf instances in the opcode source, how do you
> get that to print to the terminal when you run a csd that uses the
> opcode?
>
> I suppose it's worth mentioning that I'm just using my opcode as a
> pluggin rather than building it into csound, but I would have thought
> that printf and cout functions should work just the same either way
>
> Pete
>
> On Tue, Jan 26, 2016 at 1:49 PM, jpff  wrote:
>> The best way to debug is to think -- that is what I always told my students.
>>
>> An help is to use printf (I write C) and the macros __LINE__ and __FILE__
>>
>> Ni reason not to use this crutch to inticate where to look.
>>
>> In bad cases gdb is useful, especially to locate crash sites
>>
>> At least that is what I do.
>>
>> ==John ff
>>
>>
>> On Tue, 26 Jan 2016, Peter Burgess wrote:
>>
>>> I guess a better question might be, what is the best way to debug a
>>> new opcode? Or at least, the best way to get info in the about what is
>>> causing the seg fault
>>>
>>> Pete
>>>
>>> On Tue, Jan 26, 2016 at 1:04 PM, Peter Burgess
>>>  wrote:
>>>>
>>>> Is there a way to allow an std::cout within my opcode to print in the
>>>> terminal? I am trying to debug an opcode I just made that causes a seg
>>>> fault
>>>>
>>>> Pete
>>>
>>>

ah! ok, cheers :D

On Tue, Jan 26, 2016 at 2:24 PM, Rory Walsh  wrote:
> Use csound->Message(), it appears in tons of opcode source, you can see
> there how it's used.
>
> On 26 January 2016 at 13:56, Peter Burgess 
> wrote:
>>
>> I was trying to setup gbd to help me, but it needs me to setup a host
>> application as it's a .so file. I tried fiddling with this, but not
>> sure how exactly to get that to work... I've set csound as the host
>> executable, and a filepath to the relevant .csd as an arguement, but
>> that's not working out.
>>
>> if you do stick some printf instances in the opcode source, how do you
>> get that to print to the terminal when you run a csd that uses the
>> opcode?
>>
>> I suppose it's worth mentioning that I'm just using my opcode as a
>> pluggin rather than building it into csound, but I would have thought
>> that printf and cout functions should work just the same either way
>>
>> Pete
>>
>> On Tue, Jan 26, 2016 at 1:49 PM, jpff  wrote:
>> > The best way to debug is to think -- that is what I always told my
>> > students.
>> >
>> > An help is to use printf (I write C) and the macros __LINE__ and
>> > __FILE__
>> >
>> > Ni reason not to use this crutch to inticate where to look.
>> >
>> > In bad cases gdb is useful, especially to locate crash sites
>> >
>> > At least that is what I do.
>> >
>> > ==John ff
>> >
>> >
>> > On Tue, 26 Jan 2016, Peter Burgess wrote:
>> >
>> >> I guess a better question might be, what is the best way to debug a
>> >> new opcode? Or at least, the best way to get info in the about what is
>> >> causing the seg fault
>> >>
>> >> Pete
>> >>
>> >> On Tue, Jan 26, 2016 at 1:04 PM, Peter Burgess
>> >>  wrote:
>> >>>
>> >>> Is there a way to allow an std::cout within my opcode to print in the
>> >>> terminal? I am trying to debug an opcode I just made that causes a seg
>> >>> fault
>> >>>
>> >>> Pete
>> >>
>> >>
>> >
>

Naive tought; you did have a \n at the endof your message?  If not 
bufferig will hurt  Or write to stderr


On Tue, 26 Jan 2016, Peter Burgess wrote:

> Or should it print my printf and cout messages anyway? I have couts at
> the beginning and end of my init function, as well as in various
> places in my perform function, so if it should be outputting these
> message, then my error must happen immediately...
>
> could this header file cause a segfault:
>
> typedef struct
> {
>    OPDS h;                                    // required header
>    MYFLT *out;                                // output args
>    MYFLT *in;                                 // input args
>    MYFLT *prevIn;                           // Table that holds
> previous input samples
>    int *sumTable;                          // Table that holds number
> of samples to sum per motion
>
> } sumTableStruct;
>
> On Tue, Jan 26, 2016 at 1:56 PM, Peter Burgess
>  wrote:
>> I was trying to setup gbd to help me, but it needs me to setup a host
>> application as it's a .so file. I tried fiddling with this, but not
>> sure how exactly to get that to work... I've set csound as the host
>> executable, and a filepath to the relevant .csd as an arguement, but
>> that's not working out.
>>
>> if you do stick some printf instances in the opcode source, how do you
>> get that to print to the terminal when you run a csd that uses the
>> opcode?
>>
>> I suppose it's worth mentioning that I'm just using my opcode as a
>> pluggin rather than building it into csound, but I would have thought
>> that printf and cout functions should work just the same either way
>>
>> Pete
>>
>> On Tue, Jan 26, 2016 at 1:49 PM, jpff  wrote:
>>> The best way to debug is to think -- that is what I always told my students.
>>>
>>> An help is to use printf (I write C) and the macros __LINE__ and __FILE__
>>>
>>> Ni reason not to use this crutch to inticate where to look.
>>>
>>> In bad cases gdb is useful, especially to locate crash sites
>>>
>>> At least that is what I do.
>>>
>>> ==John ff
>>>
>>>
>>> On Tue, 26 Jan 2016, Peter Burgess wrote:
>>>
>>>> I guess a better question might be, what is the best way to debug a
>>>> new opcode? Or at least, the best way to get info in the about what is
>>>> causing the seg fault
>>>>
>>>> Pete
>>>>
>>>> On Tue, Jan 26, 2016 at 1:04 PM, Peter Burgess
>>>>  wrote:
>>>>>
>>>>> Is there a way to allow an std::cout within my opcode to print in the
>>>>> terminal? I am trying to debug an opcode I just made that causes a seg
>>>>> fault
>>>>>
>>>>> Pete
>>>>
>>>>
>>>

Jpff's advice is solid gold. The debugger should be a last resort.

If you are the author of the code, before you debug it, rewrite it to make it clearer and easier to read and understand. Don't abbreviate. Don't use comments. Write the code so it explains itself.

Regards,
Mike

I understand what my code says (though whether that makes it correct
or not is another matter :D ) but my opcode appears to seg fault on
the call to the init function. I thought I posted my sources to the
dev-board, but it turns out I only sent it to john, lol

Johns last message says as follows:

Running the C++ under gdb I see

Breakpoint 1, sumTable_init (csound=0x9fe000009fe0, p=0x1)
    at /home/jpff/Sourceforge/csound/New/csound6/Opcodes/myOpcode.cpp:7
7       {


(gdb) list
2       #include "myOpcode.h"
3       #include 
4
5       // At note initialisation
6       int sumTable_init (CSOUND *csound, sumTableStruct *p)
7       {
8
9           csound->Message(csound, Str("Start Init\n"));
10          std::cout << "Start Init" << std::endl;
11

(gdb) s
9           csound->Message(csound, Str("Start Init\n"));
(gdb) print p
$2 = (sumTableStruct *) 0x808318
(gdb) print *p
$3 = {h = {nxti = 0x0, nxtp = 0x808368,
    iopadr = 0x7fffe51d5b75 ,
    opadr = 0x7fffe51d5cbe ,
    optext = 0x7aef70, insdshead = 0x8035b0}, out = 0x803aa0, in = 0x803778,
  prevIn = 0x0, sumTable = 0x0}
(gdb)

so asI said -- but it is coffee time


... His last message prior suggested I need to allocate the memory for
my arrays in the init function, so I'm guessing that's what this is
showing

On Tue, Jan 26, 2016 at 3:43 PM, Michael Gogins
 wrote:
> Jpff's advice is solid gold. The debugger should be a last resort.
>
> If you are the author of the code, before you debug it, rewrite it to make
> it clearer and easier to read and understand. Don't abbreviate. Don't use
> comments. Write the code so it explains itself.
>
> Regards,
> Mike
>
> On Jan 26, 2016 8:49 AM, "jpff"  wrote:
>>
>> The best way to debug is to think -- that is what I always told my
>> students.
>>
>> An help is to use printf (I write C) and the macros __LINE__ and __FILE__
>>
>> Ni reason not to use this crutch to inticate where to look.
>>
>> In bad cases gdb is useful, especially to locate crash sites
>>
>> At least that is what I do.
>>
>> ==John ff
>>
>> On Tue, 26 Jan 2016, Peter Burgess wrote:
>>
>>> I guess a better question might be, what is the best way to debug a
>>> new opcode? Or at least, the best way to get info in the about what is
>>> causing the seg fault
>>>
>>> Pete
>>>
>>> On Tue, Jan 26, 2016 at 1:04 PM, Peter Burgess
>>>  wrote:
>>>>
>>>> Is there a way to allow an std::cout within my opcode to print in the
>>>> terminal? I am trying to debug an opcode I just made that causes a seg
>>>> fault
>>>>
>>>> Pete
>>>
>>>
>

Hmm, I've tried allocating the arrays stored in the struct first like so:

// At note initialisation
int sumTable_init (CSOUND *csound, sumTableStruct *p)
{

    csound->Message(csound, Str("Start Init\n"));
    std::cout << "Start Init" << std::endl;

    uint32_t nsmps = CS_KSMPS;                            // array
size from orchestra (could be = csound->ksmps)

    p->prevIn = new MYFLT[nsmps];
    p->sumTable = new MYFLT[4];

    // Init prevIn with 0's
    MYFLT *prevIn = p->prevIn;
    for(unsigned int i = 0; i < nsmps; i++) {
        prevIn[i] = 0;
    }

    // Init sumTable with {4, 3, 2, 1}
    MYFLT *sumTable = p->sumTable;
    for(int i = 0; i < 4; i++) {
        sumTable[i] = 4 - i;
    }

    csound->Message(csound, Str("Init OK\n"));
    std::cout << "Init OK" << std::endl;

    return OK;
}

It doesn't seem to sooth the segfault. I think I might start cutting
bits out until it works so I can see where the problem lies.

On Tue, Jan 26, 2016 at 3:53 PM, Peter Burgess
 wrote:
> I understand what my code says (though whether that makes it correct
> or not is another matter :D ) but my opcode appears to seg fault on
> the call to the init function. I thought I posted my sources to the
> dev-board, but it turns out I only sent it to john, lol
>
> Johns last message says as follows:
>
> Running the C++ under gdb I see
>
> Breakpoint 1, sumTable_init (csound=0x9fe000009fe0, p=0x1)
>     at /home/jpff/Sourceforge/csound/New/csound6/Opcodes/myOpcode.cpp:7
> 7       {
>
>
> (gdb) list
> 2       #include "myOpcode.h"
> 3       #include 
> 4
> 5       // At note initialisation
> 6       int sumTable_init (CSOUND *csound, sumTableStruct *p)
> 7       {
> 8
> 9           csound->Message(csound, Str("Start Init\n"));
> 10          std::cout << "Start Init" << std::endl;
> 11
>
> (gdb) s
> 9           csound->Message(csound, Str("Start Init\n"));
> (gdb) print p
> $2 = (sumTableStruct *) 0x808318
> (gdb) print *p
> $3 = {h = {nxti = 0x0, nxtp = 0x808368,
>     iopadr = 0x7fffe51d5b75 ,
>     opadr = 0x7fffe51d5cbe ,
>     optext = 0x7aef70, insdshead = 0x8035b0}, out = 0x803aa0, in = 0x803778,
>   prevIn = 0x0, sumTable = 0x0}
> (gdb)
>
> so asI said -- but it is coffee time
>
>
> ... His last message prior suggested I need to allocate the memory for
> my arrays in the init function, so I'm guessing that's what this is
> showing
>
> On Tue, Jan 26, 2016 at 3:43 PM, Michael Gogins
>  wrote:
>> Jpff's advice is solid gold. The debugger should be a last resort.
>>
>> If you are the author of the code, before you debug it, rewrite it to make
>> it clearer and easier to read and understand. Don't abbreviate. Don't use
>> comments. Write the code so it explains itself.
>>
>> Regards,
>> Mike
>>
>> On Jan 26, 2016 8:49 AM, "jpff"  wrote:
>>>
>>> The best way to debug is to think -- that is what I always told my
>>> students.
>>>
>>> An help is to use printf (I write C) and the macros __LINE__ and __FILE__
>>>
>>> Ni reason not to use this crutch to inticate where to look.
>>>
>>> In bad cases gdb is useful, especially to locate crash sites
>>>
>>> At least that is what I do.
>>>
>>> ==John ff
>>>
>>> On Tue, 26 Jan 2016, Peter Burgess wrote:
>>>
>>>> I guess a better question might be, what is the best way to debug a
>>>> new opcode? Or at least, the best way to get info in the about what is
>>>> causing the seg fault
>>>>
>>>> Pete
>>>>
>>>> On Tue, Jan 26, 2016 at 1:04 PM, Peter Burgess
>>>>  wrote:
>>>>>
>>>>> Is there a way to allow an std::cout within my opcode to print in the
>>>>> terminal? I am trying to debug an opcode I just made that causes a seg
>>>>> fault
>>>>>
>>>>> Pete
>>>>
>>>>

Yeah? I've tried the last changes you suggested, but it's still
segfaulting in the same spot. How does it sound? :D lol

I'll scour your changes again just incase

On Tue, Jan 26, 2016 at 4:20 PM, jpff  wrote: