I was going to whip off some frames from a project development directory 
and beta.3 tells me

File 'reeferMagnets.inc' line 169: Possible Parse Error: Cannot find file
  '../../ttCommon/ariali.ttf', even after trying to append file type 
extension.
File 'reeferMagnets.inc' line 169: Possible Parse Error: Cannot open 
font file.

alpha-8451792 renders this fine.

relevant code:
  36	#declare TtCommonDir="../../ttCommon/";
141	#declare ArialiFont=concat(TtCommonDir, "ariali.ttf");
165	text {
166		ttf ArialiFont
167		"Hi mom"
168		0.15,0
169		scale 3.6
170		translate <31*inches,36*inches,0>
171		pigment {Black}
172	}


I also see that "./subdir/include.inc" also fails.  I didn't notice this 
last night, because I had changed the prefix directory to "" instead of 
"./" .

This is weird, my farm has run 100 frames on beta.3 and my production 
code contains "../ttCommon/ariali.ttf" (one level back).

I thought I'd create a 3 file tar demonstrating this, except it doesn't 
fail.

This renders fine:
#declare dir="../../";
#include concat(dir, "include.inc")

So, I'm still confused. Schrödinger's bug: it's both broken and not broken.
-- 
dik

Post a reply to this message

On 02/19/2017 08:33 PM, dick balaska wrote:
> I was going to whip off some frames from a project development directory
> and beta.3 tells me
>
> File 'reeferMagnets.inc' line 169: Possible Parse Error: Cannot find file
>  '../../ttCommon/ariali.ttf', even after trying to append file type
> extension.
> File 'reeferMagnets.inc' line 169: Possible Parse Error: Cannot open
> font file.
>
> alpha-8451792 renders this fine.
>
> relevant code:
>  36    #declare TtCommonDir="../../ttCommon/";
> 141    #declare ArialiFont=concat(TtCommonDir, "ariali.ttf");
> 165    text {
> 166        ttf ArialiFont
> 167        "Hi mom"
> 168        0.15,0
> 169        scale 3.6
> 170        translate <31*inches,36*inches,0>
> 171        pigment {Black}
> 172    }
>
>
> I also see that "./subdir/include.inc" also fails.  I didn't notice this
> last night, because I had changed the prefix directory to "" instead of
> "./" .
>
> This is weird, my farm has run 100 frames on beta.3 and my production
> code contains "../ttCommon/ariali.ttf" (one level back).
>
> I thought I'd create a 3 file tar demonstrating this, except it doesn't
> fail.
>
> This renders fine:
> #declare dir="../../";
> #include concat(dir, "include.inc")
>
> So, I'm still confused. Schrödinger's bug: it's both broken and not broken.

Windows, linux or both OSs showing the hard "./subdir/include.inc" 
fails? Can you get to a small test case for this one?

Windows, linux or both OSs showing the flaky "../../ttCommon" behavior?

Thanks.
Bill P.

Post a reply to this message

Am 20.02.2017 um 02:33 schrieb dick balaska:

> File 'reeferMagnets.inc' line 169: Possible Parse Error: Cannot find file
>  '../../ttCommon/ariali.ttf', even after trying to append file type
> extension.
> File 'reeferMagnets.inc' line 169: Possible Parse Error: Cannot open
> font file.

I figured out where this comes from...


> I also see that "./subdir/include.inc" also fails.  I didn't notice this
> last night, because I had changed the prefix directory to "" instead of
> "./" .

... but this is puzzling me, because I know I've fixed it in commit
9cf8a79 (2017-02-16). Can you please double-check this one? Otherwise I
would have to wonder whether the beta.3 installer really contains what's
tagged as beta.3 on GitHub.


> This is weird, my farm has run 100 frames on beta.3 and my production
> code contains "../ttCommon/ariali.ttf" (one level back).

The problem only arises with relative paths that effectively go two
levels up (or more) from whatever is considered the base directory at
that point.


> I thought I'd create a 3 file tar demonstrating this, except it doesn't
> fail.
> 
> This renders fine:
> #declare dir="../../";
> #include concat(dir, "include.inc")

Let me guess: There also happens to be an "include.inc" in the current
directory?


Also, just for clarity: Am I right in assuming that this all happens
only on the Windows machine?


> So, I'm still confused. Schrödinger's bug: it's both broken and not broken.

We'll see whether it can be explained with a hidden variables theory.

Post a reply to this message

Am 2017-02-22 15:48, also sprach clipka:
> Am 20.02.2017 um 02:33 schrieb dick balaska:
>
>> File 'reeferMagnets.inc' line 169: Possible Parse Error: Cannot find file
>>  '../../ttCommon/ariali.ttf', even after trying to append file type
>> extension.
>> File 'reeferMagnets.inc' line 169: Possible Parse Error: Cannot open
>> font file.
>
> I figured out where this comes from...

Yay. For a minute I thought it was another manifestation of the stack 
woes, what with the broken/not broken behavior.

>
>
>> I also see that "./subdir/include.inc" also fails.  I didn't notice this
>> last night, because I had changed the prefix directory to "" instead of
>> "./" .
>
> ... but this is puzzling me, because I know I've fixed it in commit
> 9cf8a79 (2017-02-16). Can you please double-check this one? Otherwise I
> would have to wonder whether the beta.3 installer really contains what's
> tagged as beta.3 on GitHub.
>
povconsole64-9cf8a79.exe fails.
povconsole64-63e9b8ad.exe works. (The 2017-02-22 location of 
origin/release/v3.7.1)

Oh wait. I meant "../../" works. Re-reading before pressing send, I see 
you meant specifically "./" .  Let me re-check...

Yes, "./" works on 9cf8a79 on povconsole64.  I'm not sure what I was 
looking at the other day.  "./" also works inside of your built povwin 
beta.3 .
I could have sworn I saw it fail there.  I blame pebkac.

>
>> I thought I'd create a 3 file tar demonstrating this, except it doesn't
>> fail.
>>
>> This renders fine:
>> #declare dir="../../";
>> #include concat(dir, "include.inc")
>
> Let me guess: There also happens to be an "include.inc" in the current
> directory?

Nah, "3 files"  ttfail.ini, ttfail.pov, and ../../subdir/include.inc
(I thought maybe 'down 2 and up 1')
I also tried it with a .ttf .

I was shocked it worked. I thought I was going to have to do the "start 
with the whole project and prune away everything" thing again.

>
>
> Also, just for clarity: Am I right in assuming that this all happens
> only on the Windows machine?

"only" is a strong word.

My preferred geek workflow is to develop on Windows and deploy on Linux.
I can run eclipse (povclipse, c++) on Ubuntu, but under the cygwin/x 
server, it looks poopy. (kbreakout looks/plays great, though ;) )


I just tried it on Linux.  "./" and "../../" work on beta.3 .

-- 
dik

Post a reply to this message

Am 23.02.2017 um 05:43 schrieb dick balaska:

>>> I thought I'd create a 3 file tar demonstrating this, except it doesn't
>>> fail.
>>>
>>> This renders fine:
>>> #declare dir="../../";
>>> #include concat(dir, "include.inc")
>>
>> Let me guess: There also happens to be an "include.inc" in the current
>> directory?
> 
> Nah, "3 files"  ttfail.ini, ttfail.pov, and ../../subdir/include.inc
> (I thought maybe 'down 2 and up 1')
> I also tried it with a .ttf .
> 
> I was shocked it worked. I thought I was going to have to do the "start
> with the whole project and prune away everything" thing again.

That's seriously puzzling, unless the directory in which "include.inc"
resides also happens to be one of your include directories.

Because when processing the `#include` statement beta.3 will erroneously
collapse `../../include.inc` to `incldue.inc`, and unless POV-Ray
happens to find some `include.inc` in one of the paths it looks at (the
directory of the including scene, as well as all include directories) it
should complain that it doesn't find the file.

Post a reply to this message

Am 2017-02-23 07:43, also sprach clipka:
> Am 23.02.2017 um 05:43 schrieb dick balaska:

> That's seriously puzzling,

pebkac.
I'm sure of it. For all I know, I up-arrowed to a povray-alpha and it 
worked.


-- 
dik

Post a reply to this message