Hello all,
I am currently trying to rework the SQL stuff I have, to break them down into their component objects (ie, each external in its own file, as opposed to a library). Well, I am able to get the code such that everything compiles and produces the *.pd_darwin files that I need.
But, when I load them, Pd complains that it can't find specific functions that are in other externals. The real trouble here is that there are two externals that call functions in the other externals, so no matter what order I load them in, it will tell me that it can't find the function from the other external. Kind of a "circular" problem.
Is there anyway to get these things to compile this stuff so that Pd will load everything properly?
Do you need any additional info to answer the question?
Thanks,
Mike
- you could put both of these functions into one file - you could make a third "lib" file for shared functions.
For now, you'll probably be best off by linking everything into one binary. The grand plan is to support loading a "lib" file as part of the libdir format, which would work for you.
.hc
On Mar 23, 2009, at 4:42 PM, Mike McGonagle wrote:
Hello all,
I am currently trying to rework the SQL stuff I have, to break them down into their component objects (ie, each external in its own file, as opposed to a library). Well, I am able to get the code such that everything compiles and produces the *.pd_darwin files that I need.
But, when I load them, Pd complains that it can't find specific functions that are in other externals. The real trouble here is that there are two externals that call functions in the other externals, so no matter what order I load them in, it will tell me that it can't find the function from the other external. Kind of a "circular" problem.
Is there anyway to get these things to compile this stuff so that Pd will load everything properly?
Do you need any additional info to answer the question?
Thanks,
Mike
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Thanks, Hans, I guess I misunderstood you when you said that the externals should be in a separate file, I took it to mean that they should have their own 'external binary', rather than their own source files.
I changed the makefile so that everything now compiles into a single external library. BUT, now when I try to run any of the database stuff I already know that works with the older version, I am getting
consistency check failed: atom_string
for ever atom that gets returned from the database object. I tried to look into the Pd source, but it isn't very obvious what is possibly causing this.
Is there some documentation on a "consistency check" error?
Mike
On Mon, Mar 23, 2009 at 4:10 PM, Hans-Christoph Steiner hans@eds.org wrote:
- you could put both of these functions into one file
- you could make a third "lib" file for shared functions.
For now, you'll probably be best off by linking everything into one binary. The grand plan is to support loading a "lib" file as part of the libdir format, which would work for you.
.hc
On Mar 23, 2009, at 4:42 PM, Mike McGonagle wrote:
Hello all,
I am currently trying to rework the SQL stuff I have, to break them down into their component objects (ie, each external in its own file, as opposed to a library). Well, I am able to get the code such that everything compiles and produces the *.pd_darwin files that I need.
But, when I load them, Pd complains that it can't find specific functions that are in other externals. The real trouble here is that there are two externals that call functions in the other externals, so no matter what order I load them in, it will tell me that it can't find the function from the other external. Kind of a "circular" problem.
Is there anyway to get these things to compile this stuff so that Pd will load everything properly?
Do you need any additional info to answer the question?
Thanks,
Mike
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
I think you understood correctly. Ideally, externals would be one source file per objectclass, and one binary per objectclass. It sounds like your code is a bit more complicated, things like Gem and PDP have shared code like your project seems to. The objectclasses are all in their own source file, but we don't yet have a good way to load the shared code before loading individual files. I hope to work that out soon.
.hc
On Mar 23, 2009, at 6:27 PM, Mike McGonagle wrote:
Thanks, Hans, I guess I misunderstood you when you said that the externals should be in a separate file, I took it to mean that they should have their own 'external binary', rather than their own source files.
I changed the makefile so that everything now compiles into a single external library. BUT, now when I try to run any of the database stuff I already know that works with the older version, I am getting
consistency check failed: atom_string
for ever atom that gets returned from the database object. I tried to look into the Pd source, but it isn't very obvious what is possibly causing this.
Is there some documentation on a "consistency check" error?
Mike
On Mon, Mar 23, 2009 at 4:10 PM, Hans-Christoph Steiner hans@eds.org wrote:
- you could put both of these functions into one file
- you could make a third "lib" file for shared functions.
For now, you'll probably be best off by linking everything into one binary. The grand plan is to support loading a "lib" file as part of the libdir format, which would work for you.
.hc
On Mar 23, 2009, at 4:42 PM, Mike McGonagle wrote:
Hello all,
I am currently trying to rework the SQL stuff I have, to break them down into their component objects (ie, each external in its own file, as opposed to a library). Well, I am able to get the code such that everything compiles and produces the *.pd_darwin files that I need.
But, when I load them, Pd complains that it can't find specific functions that are in other externals. The real trouble here is that there are two externals that call functions in the other externals, so no matter what order I load them in, it will tell me that it can't find the function from the other external. Kind of a "circular" problem.
Is there anyway to get these things to compile this stuff so that Pd will load everything properly?
Do you need any additional info to answer the question?
Thanks,
Mike
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
--
George Burns - "Don't stay in bed, unless you can make money in bed."
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs
Any suggestions about the "consistency check" issue? The only reference I see to them in the Pd source is in the 's_print.c' file, but that is just the function that gets called to report the error.
Mike
On Mon, Mar 23, 2009 at 5:30 PM, Hans-Christoph Steiner hans@eds.org wrote:
I think you understood correctly. Ideally, externals would be one source file per objectclass, and one binary per objectclass. It sounds like your code is a bit more complicated, things like Gem and PDP have shared code like your project seems to. The objectclasses are all in their own source file, but we don't yet have a good way to load the shared code before loading individual files. I hope to work that out soon.
.hc
On Mar 23, 2009, at 6:27 PM, Mike McGonagle wrote:
Thanks, Hans, I guess I misunderstood you when you said that the externals should be in a separate file, I took it to mean that they should have their own 'external binary', rather than their own source files.
I changed the makefile so that everything now compiles into a single external library. BUT, now when I try to run any of the database stuff I already know that works with the older version, I am getting
consistency check failed: atom_string
for ever atom that gets returned from the database object. I tried to look into the Pd source, but it isn't very obvious what is possibly causing this.
Is there some documentation on a "consistency check" error?
Mike
On Mon, Mar 23, 2009 at 4:10 PM, Hans-Christoph Steiner hans@eds.org wrote:
- you could put both of these functions into one file
- you could make a third "lib" file for shared functions.
For now, you'll probably be best off by linking everything into one binary. The grand plan is to support loading a "lib" file as part of the libdir format, which would work for you.
.hc
On Mar 23, 2009, at 4:42 PM, Mike McGonagle wrote:
Hello all,
I am currently trying to rework the SQL stuff I have, to break them down into their component objects (ie, each external in its own file, as opposed to a library). Well, I am able to get the code such that everything compiles and produces the *.pd_darwin files that I need.
But, when I load them, Pd complains that it can't find specific functions that are in other externals. The real trouble here is that there are two externals that call functions in the other externals, so no matter what order I load them in, it will tell me that it can't find the function from the other external. Kind of a "circular" problem.
Is there anyway to get these things to compile this stuff so that Pd will load everything properly?
Do you need any additional info to answer the question?
Thanks,
Mike
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
--
George Burns - "Don't stay in bed, unless you can make money in bed."
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs
On Mon, 23 Mar 2009, Mike McGonagle wrote:
Any suggestions about the "consistency check" issue? The only reference I see to them in the Pd source is in the 's_print.c' file, but that is just the function that gets called to report the error.
It could be any function that calls the bug() function. Here are three ways of finding causes:
1. #define bug(A,B...) bug("%s:%d:"A,__FILE__,__LINE__,B) and recompile Pd. This will cause every call to bug() to also report the file and line number where it was called from. You do it in <m_pd.h> but you need to #undef it where it is defined so that the function can be defined without a parse error.
2. Use a debugger. In gdb, type "break bug" before you type "run". This will make the programme pause at every call to bug(). Then use "where" to get a backtrace.
3. Edit the bug() definition so that it posts a stacktrace as well. This is OS-specific. In Linux, use the backtrace() and backtrace_symbols() functions from <execinfo.h>.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Well, I was searching through the sources, and I think I might have figured out what MAY be happening. It seems that the full error is
consistency check failed: atom_string
And from looking at 'atom_string' (in 'm_atom.c'), it would appear that it can no longer determine the type of the atoms that are being returned from the database. Maybe something I did in splitting these files apart caused some weirdness.
Is it safe to assume that the name of the function that produces this error is the string just after the colon? In this case, "atom_string"?
Thank,
Mike
On Mon, Mar 23, 2009 at 6:08 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 23 Mar 2009, Mike McGonagle wrote:
Any suggestions about the "consistency check" issue? The only reference I see to them in the Pd source is in the 's_print.c' file, but that is just the function that gets called to report the error.
It could be any function that calls the bug() function. Here are three ways of finding causes:
- #define bug(A,B...) bug("%s:%d:"A,__FILE__,__LINE__,B) and recompile Pd.
This will cause every call to bug() to also report the file and line number where it was called from. You do it in <m_pd.h> but you need to #undef it where it is defined so that the function can be defined without a parse error.
- Use a debugger. In gdb, type "break bug" before you type "run". This will
make the programme pause at every call to bug(). Then use "where" to get a backtrace.
- Edit the bug() definition so that it posts a stacktrace as well. This is
OS-specific. In Linux, use the backtrace() and backtrace_symbols() functions from <execinfo.h>.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Mon, 23 Mar 2009, Mike McGonagle wrote:
Well, I was searching through the sources, and I think I might have figured out what MAY be happening. It seems that the full error is consistency check failed: atom_string
ah sorry, you mentioned it in another email, but I saw it too late.
Is it safe to assume that the name of the function that produces this error is the string just after the colon? In this case, "atom_string"?
Fairly so, but that string is explicitly written at every use of bug(), so it's not typo-proof (think about copy-paste...). For example, if it says "consistency check failed: canvas_undo", you don't know because canvas_redo misreports itself as canvas_undo. This is why I love macros.
However, in this case, there's only one bug("atom_string"), so you know which one it is.
Check whether you might be printing any uninitialised atoms... including memory that has been cleared with zeroes, as this is invalid in Pd. Also, setting an .a_w.w_ field does not in itself set the .a_type field, and I suppose that it's a common possible mistake to forget this.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Mon, Mar 23, 2009 at 7:13 PM, Mathieu Bouchard matju@artengine.ca wrote:
Check whether you might be printing any uninitialised atoms...
Bingo, Mathieu. I found that I had an atom that I was using as a constant value, and I forgot to put in the code to initialize its value.
Thank.
Mike
-
Hans-Christoph Steiner -
Mathieu Bouchard -
Mike McGonagle