 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Preset INI file is 'D:\WWW\JESUSNJIM\RAYTRACE\JOHN3_16-17.INI'.
Preset source file is 'D:\WWW\JESUSNJIM\RAYTRACE\JOHN3_16-17.INI'.
Rendering with 12 threads.
-
Parser Options
Input file: John3_16-17.pov
Remove bounds........On
Split unions.........Off
Library paths:
C:\Users\Jim-Michaels\Documents\POV-Ray\v3.7\include
C:\Windows\Fonts
Animation Options
Initial Frame: 1 Final Frame: 9104
Frame Step: 1
Initial Clock: 4.500 Final Clock: -11.000
Cyclic Animation.....Off Field render.........Off Odd lines/frames.....Off
Image Output Options
Image resolution.....720 by 405 (rows 1 to 405, columns 1 to 720).
Output file..........John3_16-170001.png, 24 bpp PNG
Dithering............Off
Graphic display......On (gamma: 2.2)
Mosaic preview.......Off
Continued trace......Off
Information Output Options
All Streams to console..........On
Debug Stream to console.........On
Fatal Stream to console.........On
Render Stream to console........On
Statistics Stream to console....On
Warning Stream to console.......On
-
"John3_16-17.pov" line 136: Parse Error: String too long.
Render failed
-
CPU time used: kernel 0.06 seconds, user 0.00 seconds, total 0.06 seconds.
Elapsed time 0.39 seconds.
----------------------------------------------------------------------------
the string has 263 chars. why is this even a problem? if this is written in c++,
use std::string in <string>. please fix.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jmichae3" <jmi### [at] yahoo com> wrote:
> Preset INI file is 'D:\WWW\JESUSNJIM\RAYTRACE\JOHN3_16-17.INI'.
> Preset source file is 'D:\WWW\JESUSNJIM\RAYTRACE\JOHN3_16-17.INI'.
> Rendering with 12 threads.
> -
> Parser Options
> Input file: John3_16-17.pov
> Remove bounds........On
> Split unions.........Off
> Library paths:
> C:\Users\Jim-Michaels\Documents\POV-Ray\v3.7\include
> C:\Windows\Fonts
> Animation Options
> Initial Frame: 1 Final Frame: 9104
> Frame Step: 1
> Initial Clock: 4.500 Final Clock: -11.000
> Cyclic Animation.....Off Field render.........Off Odd lines/frames.....Off
> Image Output Options
> Image resolution.....720 by 405 (rows 1 to 405, columns 1 to 720).
> Output file..........John3_16-170001.png, 24 bpp PNG
> Dithering............Off
> Graphic display......On (gamma: 2.2)
> Mosaic preview.......Off
> Continued trace......Off
> Information Output Options
> All Streams to console..........On
> Debug Stream to console.........On
> Fatal Stream to console.........On
> Render Stream to console........On
> Statistics Stream to console....On
> Warning Stream to console.......On
> -
> "John3_16-17.pov" line 136: Parse Error: String too long.
>
> Render failed
> -
> CPU time used: kernel 0.06 seconds, user 0.00 seconds, total 0.06 seconds.
> Elapsed time 0.39 seconds.
> ----------------------------------------------------------------------------
>
>
> the string has 263 chars. why is this even a problem? if this is written in c++,
> use std::string in <string>. please fix.
in source/backend/parser/parse.h line 54,
const int MAX_STRING_LEN_FAST = 256;
// this needs to be usable as bit mask, so keep it MAX_STRING_LEN_FAST - 1
const int MAX_STRING_LEN_MASK = (MAX_STRING_LEN_FAST - 1);
is way too small. it should be 65536. I also see another set of strings in the
windows
config that looks a mite small. windows/pvtext.cpp
char str [2048] ;
several of those.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 28/12/2014 20:47, jmichae3 a écrit :
> "jmichae3" <jmi### [at] yahoocom> wrote:
>> Preset INI file is 'D:\WWW\JESUSNJIM\RAYTRACE\JOHN3_16-17.INI'.
>> Preset source file is 'D:\WWW\JESUSNJIM\RAYTRACE\JOHN3_16-17.INI'.
>> Rendering with 12 threads.
>> -
>> Parser Options
>> Input file: John3_16-17.pov
>> Remove bounds........On
>> Split unions.........Off
>> Library paths:
>> C:\Users\Jim-Michaels\Documents\POV-Ray\v3.7\include
>> C:\Windows\Fonts
>> Animation Options
>> Initial Frame: 1 Final Frame: 9104
>> Frame Step: 1
>> Initial Clock: 4.500 Final Clock: -11.000
>> Cyclic Animation.....Off Field render.........Off Odd lines/frames.....Off
>> Image Output Options
>> Image resolution.....720 by 405 (rows 1 to 405, columns 1 to 720).
>> Output file..........John3_16-170001.png, 24 bpp PNG
>> Dithering............Off
>> Graphic display......On (gamma: 2.2)
>> Mosaic preview.......Off
>> Continued trace......Off
>> Information Output Options
>> All Streams to console..........On
>> Debug Stream to console.........On
>> Fatal Stream to console.........On
>> Render Stream to console........On
>> Statistics Stream to console....On
>> Warning Stream to console.......On
>> -
>> "John3_16-17.pov" line 136: Parse Error: String too long.
>>
>> Render failed
>> -
>> CPU time used: kernel 0.06 seconds, user 0.00 seconds, total 0.06 seconds.
>> Elapsed time 0.39 seconds.
>> ----------------------------------------------------------------------------
>>
>>
>> the string has 263 chars. why is this even a problem? if this is written in c++,
>> use std::string in <string>. please fix.
>
> in source/backend/parser/parse.h line 54,
> const int MAX_STRING_LEN_FAST = 256;
> // this needs to be usable as bit mask, so keep it MAX_STRING_LEN_FAST - 1
> const int MAX_STRING_LEN_MASK = (MAX_STRING_LEN_FAST - 1);
>
> is way too small. it should be 65536. I also see another set of strings in the
> windows
I have another patch for that (already in a branch, circa 2014-05-18 ),
because replacing a hard limit with another one is just a bad idea.
Btw, there is, in current main branch, an array sized by
MAX_STRING_LEN_FAST, so this increase to 65536 is not a good idea at
all. And limiting fast string to 256 is really what is intended (fast
string is used for token, you do not want to type a 10235 charaters long
identifier anyway). It's just the slower string that must be unbounded.
(as long as your C++ memory allows it)
https://github.com/LeForgeron/povray/commits/master
> config that looks a mite small. windows/pvtext.cpp
> char str [2048] ;
>
I have no clue nor concern about windows port. Somebody else might.
> several of those.
>
>
>
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] freefr> wrote:
> Btw, there is, in current main branch, an array sized by
> MAX_STRING_LEN_FAST, so this increase to 65536 is not a good idea at
> all. And limiting fast string to 256 is really what is intended (fast
> string is used for token, you do not want to type a 10235 charaters long
> identifier anyway). It's just the slower string that must be unbounded.
> (as long as your C++ memory allows it)
If MAX_STRING_LEN_FAST is used for an array, then it's indeed not a
very good idea to set it to 65536 because it would mean that even
single-character strings would start consuming that much RAM.
Using std::string for all strings is probably a very viable option.
Most std::string implementations nowadays use short string optimization
(although there are probably a few exceptions), so they are very
efficient for short strings, and probably what MAX_STRING_LEN_FAST
is already doing.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> > Btw, there is, in current main branch, an array sized by
> > MAX_STRING_LEN_FAST, so this increase to 65536 is not a good idea at
> > all. And limiting fast string to 256 is really what is intended (fast
> > string is used for token, you do not want to type a 10235 charaters long
> > identifier anyway). It's just the slower string that must be unbounded.
> > (as long as your C++ memory allows it)
>
> If MAX_STRING_LEN_FAST is used for an array, then it's indeed not a
> very good idea to set it to 65536 because it would mean that even
> single-character strings would start consuming that much RAM.
> Using std::string for all strings is probably a very viable option.
The place where it is used is the core part of the tokenizer. Using a
dynamically allocated string would significantly increase overhead in the most
called place as the short string optimization won't work (it is frequently not
more than 10/14 chars). Now consider the average POV token length, and you
notice
you get at least one additional memory allocation per token parsed.
The only limit is that this can't parse character strings over 256 chars long.
However, as you can concat strings to any length in POV, this is neither a bug
now something that needs to be fixed. To the contrary...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <nomail@nomail> wrote:
> The place where it is used is the core part of the tokenizer. Using a
> dynamically allocated string would significantly increase overhead in the most
> called place as the short string optimization won't work (it is frequently not
> more than 10/14 chars). Now consider the average POV token length, and you
> notice
> you get at least one additional memory allocation per token parsed.
Does the part that parses tokens really need to use the exact same string
class as the part that parses and handles strings?
> However, as you can concat strings to any length in POV, this is neither a bug
> now something that needs to be fixed. To the contrary...
Using concat to get longer string literals is a kludge.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Thorsten Froehlich <nomail@nomail> wrote:
> > The place where it is used is the core part of the tokenizer. Using a
> > dynamically allocated string would significantly increase overhead in the most
> > called place as the short string optimization won't work (it is frequently not
> > more than 10/14 chars). Now consider the average POV token length, and you
> > notice
> > you get at least one additional memory allocation per token parsed.
>
> Does the part that parses tokens really need to use the exact same string
> class as the part that parses and handles strings?
No, and actually, checking the code, this part of the tokenizer uses the unbound
string parsing. Which leaves the question how the original poster could get this
error message. The problem most likely is an identifier longer than 255
characters ... which is, well, really pointless to have.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 30/12/2014 01:01, Thorsten Froehlich a écrit :
> Warp <war### [at] tagpovrayorg> wrote:
>> Thorsten Froehlich <nomail@nomail> wrote:
>>> The place where it is used is the core part of the tokenizer. Using a
>>> dynamically allocated string would significantly increase overhead in the most
>>> called place as the short string optimization won't work (it is frequently not
>>> more than 10/14 chars). Now consider the average POV token length, and you
>>> notice
>>> you get at least one additional memory allocation per token parsed.
>>
>> Does the part that parses tokens really need to use the exact same string
>> class as the part that parses and handles strings?
>
> No, and actually, checking the code, this part of the tokenizer uses the unbound
> string parsing. Which leaves the question how the original poster could get this
> error message. The problem most likely is an identifier longer than 255
> characters ... which is, well, really pointless to have.
>
>
Sorry dear, but a string literal (e.g. "Povray is a nice program" in a
#declare or #local) longer than 255 would lead to a parse error with the
original parser.
Hence my patch in my master branch of hgpovray (made in May 2014).
I mean:
#declare MyString = "Povray is a nice program";
Now extends the string... and see povray fails to parse it when the
limit is reached.
--
Just because nobody complains does not mean all parachutes are perfect.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <lef### [at] freefr> wrote:
> Sorry dear, but a string literal (e.g. "Povray is a nice program" in a
> #declare or #local) longer than 255 would lead to a parse error with the
> original parser.
>
> Hence my patch in my master branch of hgpovray (made in May 2014).
>
> I mean:
>
> #declare MyString = "Povray is a nice program";
>
> Now extends the string... and see povray fails to parse it when the
> limit is reached.
Hmm, then I probably fixed this in my local branch in Perforce some time ago
when I changed the code there to use UTF8 throughout ... the fix certainly is to
change the parsing code for string literals and not tweak the buffer size.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 30/12/2014 16:54, Thorsten Froehlich a écrit :
> Le_Forgeron <lef### [at] freefr> wrote:
>> Sorry dear, but a string literal (e.g. "Povray is a nice program" in a
>> #declare or #local) longer than 255 would lead to a parse error with the
>> original parser.
>>
>> Hence my patch in my master branch of hgpovray (made in May 2014).
>>
>> I mean:
>>
>> #declare MyString = "Povray is a nice program";
>>
>> Now extends the string... and see povray fails to parse it when the
>> limit is reached.
>
> Hmm, then I probably fixed this in my local branch in Perforce some time ago
> when I changed the code there to use UTF8 throughout ... the fix certainly is to
> change the parsing code for string literals and not tweak the buffer size.
>
>
So does my own fix. I agree that the buffer size should not be tweaked.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
