dear list, Miller,
how about general c++ wrappers for making writing externals more clear and simple? Gem (or gemPlus?) seems to have this approach, I wonder if others have thought of it. Are there efficiency issues?
juha
Hello,
ok, so I compiled the 0.34-3 version a few days before 34-4 came around. The problem applies to both. (previous version I was using was 0.34-0)
when starting pd it says: reading startup file: /home/mis/.pdrc
then (when run in verbose mode) it reports every line in my .pdrc (even the commented lines) as such:
[snip] tried /usr/lib/pd/externs/zexy and failed open: No such file or directory No such file or directory tried /home/mis/downloads/pd/new/pd-0.34-4/bin/-lib and failed tried ../extra/-lib and failed tried ../extra/-lib and failed open: No such file or directory [snip]
my .pdrc is in the format: -lib <path> and -path <path>:,path> etc...
ideas?
./MiS
you have to change your .pdrc especially every path segment formerly sepretetd by : now goes like
-path /path/to/one -path /path/to/two
also i think it not understand # comment anymore ..
|ok, so I compiled the 0.34-3 version a few days before 34-4 came around. |The problem applies to both. (previous version I was using was 0.34-0) | |when starting pd it says: |reading startup file: /home/mis/.pdrc | |then (when run in verbose mode) |it reports every line in my .pdrc (even the commented lines) as such: | |[snip] |tried /usr/lib/pd/externs/zexy and failed |open: No such file or directory |No such file or directory |tried /home/mis/downloads/pd/new/pd-0.34-4/bin/-lib and failed |tried ../extra/-lib and failed |tried ../extra/-lib and failed |open: No such file or directory |[snip] | | |my .pdrc is in the format: |-lib <path> |and |-path <path>:,path> etc...
-- × d V . o r g
I get exactly the same result after having changed my .pdrc.
Guess it must be me/setup. The funny thing is it still is working with my 0.34-0 version. Could it be something related to compilation settings? The compilation went fine, without any problems but i have noticed lately that possibly I have some some problems with the linker. Having trouble compiling just about anything these days.
OS: RH7.0
./MiS
On 11/26/01 4:40 PM, _-¯-_ @ jdl@xdv.org wrote:
you have to change your .pdrc especially every path segment formerly sepretetd by : now goes like
-path /path/to/one -path /path/to/two
also i think it not understand # comment anymore ..
Hmm, well, I tried something like:
-path /path/a:/path/b
in pd-0.34.3 and... no trouble that I could find. On the other hand, comments in .pdrc do no longer work.
cheers Miller
On Mon, Nov 26, 2001 at 07:53:39PM -0500, Michal Seta wrote:
I get exactly the same result after having changed my .pdrc.
Guess it must be me/setup. The funny thing is it still is working with my 0.34-0 version. Could it be something related to compilation settings? The compilation went fine, without any problems but i have noticed lately that possibly I have some some problems with the linker. Having trouble compiling just about anything these days.
OS: RH7.0
./MiS
On 11/26/01 4:40 PM, _-¯-_ @ jdl@xdv.org wrote:
you have to change your .pdrc especially every path segment formerly sepretetd by : now goes like
-path /path/to/one -path /path/to/two
also i think it not understand # comment anymore ..
Ok, so I'm completely lost here. I seem to be the only one with the prob so I guess it's not pd. It's me and I'm not surprised.
I recompiled and checked for any errors/warnings and found nothing. But still can't load -path and -lib entries from .pdrc with the recent versions. Actually, here it is what it does:
1st it lists my -path and -lib entries (as if it was finding them) then: tried /path/a and failed (and so on for each -path then tried /path-to-lib/-lib and failed and so on for each -lib (note that it puts "-lib" at the end of the path)
then open: No such file or directory tried /path/a; stat failed or directory and so on for each path and then for libs.
and again, 34-0 works, no prob.
I'll be upgrading my OS to debian within the next few days so I guess it doesn't matter anymore. Hopefully it will work then.
Thanks anyways.
./MiS
On 11/26/01 9:10 PM, Miller Puckette @ mpuckett@man104-1.ucsd.edu wrote:
Hmm, well, I tried something like:
-path /path/a:/path/b
in pd-0.34.3 and... no trouble that I could find. On the other hand, comments in .pdrc do no longer work.
cheers Miller
Michal Seta hat gesagt: // Michal Seta wrote:
Ok, so I'm completely lost here. I seem to be the only one with the prob so I guess it's not pd. It's me and I'm not surprised.
Could you attach your .pdrc for further inspection?
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
Hi,
Thanks to CK my problem is solved. Thanks a lot.
Now, back to work
./MiS
hi Micha/l, hi Miller,
.pdrc parsing was recently (over)simplified. If there is a line
- not starting with '-', or 2. not having exactly expected number
of tokens (in the scanf("%s") sense), then all remaining part of .pdrc is taken as a list of filenames to load.
Miller, could you please look at my .pdrc post from Mon, 01 Oct 2001?
Krzysztof
Michal Seta wrote:
Ok, so I'm completely lost here.
Sure enough, it's all there...
I think it's wrong to handle .pdrc files as additional arguments, and only rewrote the code to prevent setuid abuses that were possible with an older (also buggy) version... so anything done to the current setup is temporary anyway.
But as Krzysztof notes, any parse error in the .pdrc file has bizzare and bad results. So I'll have to choose whether to patch it up again or to figure out how to do it right (with A=B style declarations and a site file and correct handling of whether to override or add to paths... )
cheers Miller
On Tue, Nov 27, 2001 at 09:57:31AM +0100, Krzysztof Czaja wrote:
hi Micha/l, hi Miller,
.pdrc parsing was recently (over)simplified. If there is a line
- not starting with '-', or 2. not having exactly expected number
of tokens (in the scanf("%s") sense), then all remaining part of .pdrc is taken as a list of filenames to load.
Miller, could you please look at my .pdrc post from Mon, 01 Oct 2001?
Krzysztof
Michal Seta wrote:
Ok, so I'm completely lost here.
On Mon, 26 Nov 2001, [iso-8859-1] Juha Vehvil�inen wrote:
dear list, Miller,
how about general c++ wrappers for making writing externals more clear and simple? Gem (or gemPlus?) seems to have this approach, I wonder if others have thought of it. Are there efficiency issues?
Well, efficiency in a sense that a wrapper will wrap, meaning one level of function calls more, beside the fact that virtual functions in C++ are slower than their "C" counterparts.
But thats not really an issue. The main issue is just who is interested enough in having a C++ interface to write such a wrapper, or extracts the existing code from Gem (giving proper credit !), bundles it up, documents it, maintains it ...
Guenter
Juha Vehviläinen wrote:
dear list, Miller,
how about general c++ wrappers for making writing externals more clear and simple? Gem (or gemPlus?) seems to have this approach, I wonder if others have thought of it. Are there efficiency issues?
juha
I've often thought of this, but never spent enough time to conjure up a good framework. I think it would be tricky to do this, while interfacing to the C-language PD.
For the first time today, I took a quick look at the Gem approach, but I'd have to look at it in a lot more detail to see whether it would work in general. I think that Mark had said once during a similar discussion on this list, that his classes where pretty much specific to the needs of Gem.
On my first reading of the Gem approach, I have to say that the macro approach used seems pretty ugly - it seems you have to define a macro for every combination of creation arguments that the object could have. But again, I haven't looked at it in detail. Also, I don't beleive that Gem deals at all with DSP processes.
Again, I don't know if I could do any better. I think a good C++ framework at the very least would have to employ some tricky template magic.
Certainly, if you have any ideas about how to implement such a thing, I'm sure that people on this list would be very interested and maybe we could come up with something.
You mention a concern about efficiency issues. I am quite sure that this would not be a concern. No, I think the biggest problem is how to interface a set of class heirarchies to the PD code.
Again, I have thought several times about this, and my mind got a little overwhelmed.
Larry
-
_-¯-_ -
Frank Barknecht -
guenter geiger -
Juha Vehviläinen -
Krzysztof Czaja -
Larry Troxler -
Michal Seta -
Miller Puckette