POV-Ray : Newsgroups : povray.general : Problem with Parse_String and #ifndef Server Time
16 Nov 2024 19:19:26 EST (-0500)
  Problem with Parse_String and #ifndef (Message 1 to 10 of 15)  
Goto Latest 10 Messages Next 5 Messages >>>
From: Florian Brucker
Subject: Problem with Parse_String and #ifndef
Date: 10 Sep 2003 12:21:10
Message: <3f5f4f76$1@news.povray.org>
Hey Guys!

I want to check if a certain pigment is already defined and otherwise 
define it. Normally that would be no problem, #ifndef does the job.

Unfortunately, I create my pigments dynamically within the SDL code. 
Every pigment gets a number. The pigment's name would be

	Parse_String(concat("Pigment",str(Number,0,0)))

but this does not work with #indef. The following code reports: "Parse 
Error: Expexted ')', '(' found instead". The error occurs right after 
"Parse_String" in the code:

<code>
#include "strings.inc"

#local Number = 34;
#local PigmentName = concat("Pigment",str(Number,0,0));

#ifndef(Parse_String(PigmentName))
	#debug "no pigment defined, yet\n"
#end
</code>

I understand this from the parser's point of view - normaly, opening 
brackets inside #ifndef() do not make sense, as identifiers aren't 
allowed to contain brackets. In the case of Parse_String(), however, 
it makes sense.

I see no reason to rewrite the parser because of this, but I'd like to 
know if there is another possibility to check if an identifier from 
which I got only the name as a string is already declared.

BTW, declaring such an identifier is possible: while

<code>
#declare Parse_String(PigmentName) = pigment { rgb<1,0,0> }
</code>

gives an error,

<code>
Parse_String(concat("#declare ",PigmentName)) = pigment { rgb<1,0,0> }
</code>

works perfectly.

Thanks in advance,
Florian
-- 
//=================[web: http://www.torfbold.com]==================\\
#local a=-5;#while(a<5)sphere{<sin(a*pi)*5a*10pow(a,5)*.01>sin(a*a*a*
.1)+1pigment{rgb 9*z}}#local a=a+.01;#end camera{look_at-y*10location
<8,-3,-8>*10}// [www.povray.org]     [www.imp.org]     [www.irtc.org]


Post a reply to this message

From: Tim Nikias v2 0
Subject: Re: Problem with Parse_String and #ifndef
Date: 10 Sep 2003 12:29:44
Message: <3f5f5178$1@news.povray.org>
How about this:
write your own Parse_String which always outputs to
"somefile.ext".
Then do:
#ifndef (#include"somefile.ext")

I'm not quiet sure if that'll work though.

As for the last part of your post:
#declare Parse_String... = ...
processes down to
#declare #include "blabla" = ...

So, I'd expect it to complain. Hm, which might
be a reason for #ifndef to complain for the above:
#ifndef (#include"...") ?

You've got to experiment. Perhaps writing the entire
#ifndef () ... #debug ".." #end
to disc and #including that.

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de

"Florian Brucker" <tor### [at] torfboldcom> schrieb im Newsbeitrag
news:3f5f4f76$1@news.povray.org...
> Hey Guys!
>
> I want to check if a certain pigment is already defined and otherwise
> define it. Normally that would be no problem, #ifndef does the job.
>
> Unfortunately, I create my pigments dynamically within the SDL code.
> Every pigment gets a number. The pigment's name would be
>
> Parse_String(concat("Pigment",str(Number,0,0)))
>
> but this does not work with #indef. The following code reports: "Parse
> Error: Expexted ')', '(' found instead". The error occurs right after
> "Parse_String" in the code:
>
> <code>
> #include "strings.inc"
>
> #local Number = 34;
> #local PigmentName = concat("Pigment",str(Number,0,0));
>
> #ifndef(Parse_String(PigmentName))
> #debug "no pigment defined, yet\n"
> #end
> </code>
>
> I understand this from the parser's point of view - normaly, opening
> brackets inside #ifndef() do not make sense, as identifiers aren't
> allowed to contain brackets. In the case of Parse_String(), however,
> it makes sense.
>
> I see no reason to rewrite the parser because of this, but I'd like to
> know if there is another possibility to check if an identifier from
> which I got only the name as a string is already declared.
>
> BTW, declaring such an identifier is possible: while
>
> <code>
> #declare Parse_String(PigmentName) = pigment { rgb<1,0,0> }
> </code>
>
> gives an error,
>
> <code>
> Parse_String(concat("#declare ",PigmentName)) = pigment { rgb<1,0,0> }
> </code>
>
> works perfectly.
>
> Thanks in advance,
> Florian
> -- 
> //=================[web: http://www.torfbold.com]==================\\
> #local a=-5;#while(a<5)sphere{<sin(a*pi)*5a*10pow(a,5)*.01>sin(a*a*a*
> .1)+1pigment{rgb 9*z}}#local a=a+.01;#end camera{look_at-y*10location
> <8,-3,-8>*10}// [www.povray.org]     [www.imp.org]     [www.irtc.org]
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 01.09.2003


Post a reply to this message

From: ABX
Subject: Re: Problem with Parse_String and #ifndef
Date: 10 Sep 2003 12:34:19
Message: <c5kulvsca8m0ppns155dbjjp8d4rocqsp1@4ax.com>
On Wed, 10 Sep 2003 18:22:47 +0200, Florian Brucker <tor### [at] torfboldcom> wrote:
> <code>
> #include "strings.inc"
>
> #local Number = 34;
> #local PigmentName = concat("Pigment",str(Number,0,0));
>
> #ifndef(Parse_String(PigmentName))
> 	#debug "no pigment defined, yet\n"
> #end
> </code>

Try this:

#include "strings.inc"
#local Number = 34;
#local PigmentName = concat("Pigment",str(Number,0,0));
#local PigmentTest = concat("(defined(",PigmentName,")?yes:no)");
#if(!Parse_String(PigmentTest))
	#debug "no pigment defined, yet\n"
#end

ABX


Post a reply to this message

From: Florian Brucker
Subject: Re: Problem with Parse_String and #ifndef
Date: 10 Sep 2003 12:44:36
Message: <3f5f54f4$1@news.povray.org>
Hi Tim!

> You've got to experiment. Perhaps writing the entire
> #ifndef () ... #debug ".." #end
> to disc and #including that.
That did the job!

if anyone is interested, here's the code:

<code>
#include "strings.inc"

#declare TestIdent = 1;

#macro IFDEF2(Name)                                                   	
	#declare TEMPDEF__ = 0;

	Parse_String(concat(
		"#ifdef(",Name,")
			#declare TEMPDEF__=1;
		#end"
	))		
	
	(TEMPDEF__)
#end

#if (IFDEF2("TestIdent"))
	#debug "defined\n"
#else
	#debug "nope\n"
#end
</code>

result: defined

Thanks Tim!

Greetings,
Florian
-- 
//=================[web: http://www.torfbold.com]==================\\
#local a=-5;#while(a<5)sphere{<sin(a*pi)*5a*10pow(a,5)*.01>sin(a*a*a*
.1)+1pigment{rgb 9*z}}#local a=a+.01;#end camera{look_at-y*10location
<8,-3,-8>*10}// [www.povray.org]     [www.imp.org]     [www.irtc.org]


Post a reply to this message

From: Florian Brucker
Subject: Re: Problem with Parse_String and #ifndef
Date: 10 Sep 2003 12:51:17
Message: <3f5f5685$1@news.povray.org>
Hey ABX

> #include "strings.inc"
> #local Number = 34;
> #local PigmentName = concat("Pigment",str(Number,0,0));
> #local PigmentTest = concat("(defined(",PigmentName,")?yes:no)");
> #if(!Parse_String(PigmentTest))
> 	#debug "no pigment defined, yet\n"
> #end

Wow, that's a nice idea!

You know, two answers to my post in 10 minutes. And both helped me 
solve my problem. That's what I call a great community :)

Thanks,
Florian
-- 
//=================[web: http://www.torfbold.com]==================\\
#local a=-5;#while(a<5)sphere{<sin(a*pi)*5a*10pow(a,5)*.01>sin(a*a*a*
.1)+1pigment{rgb 9*z}}#local a=a+.01;#end camera{look_at-y*10location
<8,-3,-8>*10}// [www.povray.org]     [www.imp.org]     [www.irtc.org]


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Problem with Parse_String and #ifndef
Date: 10 Sep 2003 13:18:16
Message: <3f5f5cd8$1@news.povray.org>
In article <3f5f4f76$1@news.povray.org> , Florian Brucker 
<tor### [at] torfboldcom>  wrote:

> I understand this from the parser's point of view - normaly, opening
> brackets inside #ifndef() do not make sense, as identifiers aren't
> allowed to contain brackets. In the case of Parse_String(), however,
> it makes sense.

This isn't the parsers problem, it is your scene.  You simply do not
generate a valid scene with what you do.  This should be clear from the
specification of #ifndef (taking only a single identifier).

However, this isn't all.  There is a second misconception.  What you expect
is #macros to behave like macros, not functions.  However, if you read the
chapter in the documentation which explains the difference between the
POV-Ray #macro and what most people commonly expect from macros (and how
macros return something), you will notice that what you do cannot work as
expected.

Even worse, there is a third roadblock in your code, which is that a #macro
name can also be checked with an #ifndef.  And actually this is what the
parser catches first and reports an error for.  nevertheless, the first two
problems would persist even if this would be accepted by the parser.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Warp
Subject: Re: Problem with Parse_String and #ifndef
Date: 10 Sep 2003 13:45:26
Message: <3f5f6336@news.povray.org>
It would be nice if the string parsing was an internal command which
could be used anywhere.
  I suppose #parse would be a good name. This way you could do things like:

#declare #parse(concat(name1, name2)) = 5;

  That is, the parser would take the string given as parameter to #parse
and parse its contents as if it was just plain text appearing at that place
in the file. This would certainly be handy for many things.

  (OTOH it accentuates the importance of I/O restrictions because it would
allow making extremely obfuscated SDL code.)

  I think one important feature of this #parse command that differentiates
it from other commands is that it should be possible to appear *anywhere*
in the code. Even though this is not strictly indispensable, it would
certainly make it more useful.
  That is for example this:

#de#parse("cl")are ab#parse("cde")fg = 5;

would be effectively the same thing as:

#declare abcdefg = 5;

  I don't know if this behaviour would be easy to implement in the current
parser, but just an idea...

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Problem with Parse_String and #ifndef
Date: 10 Sep 2003 13:50:46
Message: <3f5f6476@news.povray.org>
In article <3f5f6336@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   That is for example this:
>
> #de#parse("cl")are ab#parse("cde")fg = 5;
>
> would be effectively the same thing as:
>
> #declare abcdefg = 5;
>
>   I don't know if this behaviour would be easy to implement in the current
> parser, but just an idea...

Aren't *you* the one who usually argues for well structured code? ;-) ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Warp
Subject: Re: Problem with Parse_String and #ifndef
Date: 10 Sep 2003 16:01:12
Message: <3f5f8308@news.povray.org>
Thorsten Froehlich <tho### [at] trfde> wrote:
> Aren't *you* the one who usually argues for well structured code? ;-) ;-)

  In C++ yes, but the POV-Ray SDL is a hacker language. :P

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -


Post a reply to this message

From: Jim Charter
Subject: Re: Problem with Parse_String and #ifndef
Date: 10 Sep 2003 16:33:11
Message: <3f5f8a87$1@news.povray.org>
Warp wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
> 
>>Aren't *you* the one who usually argues for well structured code? ;-) ;-)
> 
> 
>   In C++ yes, but the POV-Ray SDL is a hacker language. :P
> 
Do you mean a language for 'hacks', or a language for 'hackers'?


Post a reply to this message

Goto Latest 10 Messages Next 5 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.