-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
i'd like to embed source-code (C-like GLSL-shaders) into Pd-patches, and thought that the new [text] family of objects might be able to do that.
my first source-file looks like:
<snap> int main(void) { return 0; } </snap>
i read it with [read -c snap.c( when check the contents of [text define -k foo], it looks like:
snap:1 int main (void); {; } pdtk_textwindow_append .x83210e8 {return 0; } pdtk_textwindow_append .x83210e8 {; } pdtk_textwindow_append .x83210e8 {}; </snap:1>
reading it without the "-c" flag [read snap.c(, i get: snap:2 int main (void) { return 0; } pdtk_textwindow_append .x83210e8 {} </snap:2>
now checking the .pd file itself is better, the content is basically:
#A set int main (void) { return 0 ; };
now a more realistic example would be something like:
<interpol> // Cyrille Henry 2008 #extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect texture_mass; uniform float init;
void main (void) { vec2 coord = gl_TexCoord[0].st/2.; vec4 pos = texture2DRect(texture_mass, coord);
gl_FragColor = pos;
}
</interpol>
as you can see, some lines are terminated with semicolons, others are not. unfortunately, Pd swallows all semicolons, the exact nature of the eating depending on the presense of the "-c" flag.
what's worse, it's utterly impossible to restore the original file. loading without "-c" i get:
<write> // Cyrille Henry 2008 #extension GL_ARB_texture_rectangle : enable uniform sampler2DRect texture_mass; uniform float init; void main (void) { vec2 coord = gl_TexCoord[0].st/2.; vec4 pos = texture2DRect(texture_mass, coord); gl_FragColor = pos; } </write>
AND
<write -c> // Cyrille Henry 2008 #extension GL_ARB_texture_rectangle : enable uniform sampler2DRect texture_mass uniform float init void main (void) { vec2 coord = gl_TexCoord[0].st/2. vec4 pos = texture2DRect(texture_mass, coord) gl_FragColor = pos } </write -c>
loading with the "-c" flag i get:
<write> // Cyrille Henry 2008; #extension GL_ARB_texture_rectangle : enable; ; uniform sampler2DRect texture_mass; ; uniform float init; ; ; void main (void); {; vec2 coord = gl_TexCoord[0].st/2.; ; vec4 pos = texture2DRect(texture_mass, coord); ; ; gl_FragColor = pos; ; }; </write>
AND
<write -c> // Cyrille Henry 2008 #extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect texture_mass
uniform float init
void main (void) { vec2 coord = gl_TexCoord[0].st/2.
vec4 pos = texture2DRect(texture_mass, coord)
gl_FragColor = pos
} </write -c>
should it be possible to read/store/write source-code like text with [text], in a way that preserves semicolons, (and colons) and line-breaks (and empty lines)?
i'm wondering whether these are bugs or design limitations of [text].
ghmsd IOhannes
On 09/16/2013 01:44 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
i'd like to embed source-code (C-like GLSL-shaders) into Pd-patches, and thought that the new [text] family of objects might be able to do that.
my first source-file looks like:
<snap> int main(void) { return 0; } </snap>
i read it with [read -c snap.c( when check the contents of [text define -k foo], it looks like:
snap:1 int main (void); {; } pdtk_textwindow_append .x83210e8 {return 0; } pdtk_textwindow_append .x83210e8 {; } pdtk_textwindow_append .x83210e8 {}; </snap:1>
reading it without the "-c" flag [read snap.c(, i get: snap:2 int main (void) { return 0; } pdtk_textwindow_append .x83210e8 {} </snap:2>
now checking the .pd file itself is better, the content is basically:
#A set int main (void) { return 0 ; };
now a more realistic example would be something like:
<interpol> // Cyrille Henry 2008 #extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect texture_mass; uniform float init;
void main (void) { vec2 coord = gl_TexCoord[0].st/2.; vec4 pos = texture2DRect(texture_mass, coord);
gl_FragColor = pos; }
</interpol>
as you can see, some lines are terminated with semicolons, others are not. unfortunately, Pd swallows all semicolons, the exact nature of the eating depending on the presense of the "-c" flag.
what's worse, it's utterly impossible to restore the original file. loading without "-c" i get:
<write> // Cyrille Henry 2008 #extension GL_ARB_texture_rectangle : enable uniform sampler2DRect texture_mass; uniform float init; void main (void) { vec2 coord = gl_TexCoord[0].st/2.; vec4 pos = texture2DRect(texture_mass, coord); gl_FragColor = pos; } </write>
AND
<write -c> // Cyrille Henry 2008 #extension GL_ARB_texture_rectangle : enable uniform sampler2DRect texture_mass uniform float init void main (void) { vec2 coord = gl_TexCoord[0].st/2. vec4 pos = texture2DRect(texture_mass, coord) gl_FragColor = pos } </write -c>
loading with the "-c" flag i get:
<write> // Cyrille Henry 2008; #extension GL_ARB_texture_rectangle : enable; ; uniform sampler2DRect texture_mass; ; uniform float init; ; ; void main (void); {; vec2 coord = gl_TexCoord[0].st/2.; ; vec4 pos = texture2DRect(texture_mass, coord); ; ; gl_FragColor = pos; ; }; </write>
AND
<write -c> // Cyrille Henry 2008 #extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect texture_mass
uniform float init
void main (void) { vec2 coord = gl_TexCoord[0].st/2.
vec4 pos = texture2DRect(texture_mass, coord)
gl_FragColor = pos
} </write -c>
should it be possible to read/store/write source-code like text with [text], in a way that preserves semicolons, (and colons) and line-breaks (and empty lines)?
i'm wondering whether these are bugs or design limitations of [text].
I believe it's a design limitation-- [text] works with arrays of atoms, and there isn't an atom designed to simply load and save an arbitrary string without regard to the content. A quick fix would be a flag to load a file where each line is an a_symbol, but then maybe you run into problems with MAXPDSTRING. (And probably you fill up the symbol table more quickly if you want to parse those symbols further.)
After working with the narrow case of interpreting arbitrary user input to the search plugin as a tcl string[1], I'd advise against trying to build in changes to [text] that make c code compatible with it, because a) there are many other programming languages and important use cases which will have their own problems and b) trying to implement a general-purpose parser on top of a domain-specific parser is like trying to keep a bowling ball balanced on top of another bowling ball. (I say domain-specific because [text] is designed to parse FUDI messages, not arbitrary text files.)
Best, Jonathan
[1] And now that I'm not doing that any longer, it greatly simplifies the interface.
ghmsd IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlI3Q20ACgkQkX2Xpv6ydvRrkACgtFVPNN3ELWOi1vNDL6Xy1OQD CYYAn2vDufGuWEXUbp2KvHvPoGdSvE2g =iz26 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list