 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Folks,
as a few of you may already have noticed, I'm currently trying to
implement a mechanism to cache macros in memory, to speed up calls to
macros defined in other files.
While the current work-in-progress code appears to work ok on Windows,
/something/ seems to make it fail on Unix systems, in a manner that
puzzles me.
Since I can't do much Unix debugging myself, I'd be much obliged if
someone could pick up the glove to do some experiments with the code at
https://github.com/c-lipka/povray/tree/refactor/iostream, and give me a
hint or two where things may be going wrong. Otherwise I'll probably
have to abandon this attempt to speed up parsing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14/07/2016 16:57, clipka a écrit :
> Folks,
>
> as a few of you may already have noticed, I'm currently trying to
> implement a mechanism to cache macros in memory, to speed up calls to
> macros defined in other files.
>
> While the current work-in-progress code appears to work ok on Windows,
> /something/ seems to make it fail on Unix systems, in a manner that
> puzzles me.
>
> Since I can't do much Unix debugging myself, I'd be much obliged if
> someone could pick up the glove to do some experiments with the code at
> https://github.com/c-lipka/povray/tree/refactor/iostream, and give me a
> hint or two where things may be going wrong. Otherwise I'll probably
> have to abandon this attempt to speed up parsing.
>
Can you be a bit more explicit (or provide a reproducing situation) ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.07.2016 um 17:46 schrieb Le_Forgeron:
> Le 14/07/2016 16:57, clipka a écrit :
>> Folks,
>>
>> as a few of you may already have noticed, I'm currently trying to
>> implement a mechanism to cache macros in memory, to speed up calls to
>> macros defined in other files.
>>
>> While the current work-in-progress code appears to work ok on Windows,
>> /something/ seems to make it fail on Unix systems, in a manner that
>> puzzles me.
>>
>> Since I can't do much Unix debugging myself, I'd be much obliged if
>> someone could pick up the glove to do some experiments with the code at
>> https://github.com/c-lipka/povray/tree/refactor/iostream, and give me a
>> hint or two where things may be going wrong. Otherwise I'll probably
>> have to abandon this attempt to speed up parsing.
>>
>
> Can you be a bit more explicit (or provide a reproducing situation) ?
"make check" fails when trying to render the "biscuit.pov" scene,
claiming that in line 312 of "shapes.inc" there's an unexpected "max" --
which is so utterly nonsensical that I can make neither heads nor tails
of it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14/07/2016 18:33, clipka a écrit :
> Am 14.07.2016 um 17:46 schrieb Le_Forgeron:
>> Le 14/07/2016 16:57, clipka a écrit :
>>> Folks,
>>>
>>> as a few of you may already have noticed, I'm currently trying to
>>> implement a mechanism to cache macros in memory, to speed up calls to
>>> macros defined in other files.
>>>
>>> While the current work-in-progress code appears to work ok on Windows,
>>> /something/ seems to make it fail on Unix systems, in a manner that
>>> puzzles me.
>>>
>>> Since I can't do much Unix debugging myself, I'd be much obliged if
>>> someone could pick up the glove to do some experiments with the code at
>>> https://github.com/c-lipka/povray/tree/refactor/iostream, and give me a
>>> hint or two where things may be going wrong. Otherwise I'll probably
>>> have to abandon this attempt to speed up parsing.
>>>
>>
>> Can you be a bit more explicit (or provide a reproducing situation) ?
>
> "make check" fails when trying to render the "biscuit.pov" scene,
> claiming that in line 312 of "shapes.inc" there's an unexpected "max" --
> which is so utterly nonsensical that I can make neither heads nor tails
> of it.
>
Yes, reproduced.
using debugger to catch the original throw, I got that stack of calls:
(gdb) where
#0 0x00007ffff5dc08bd in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00000000005f72dc in pov::MessageFactory::ErrorAt
(this=this@entry=0x7fffe0004c10, ex=..., filename=filename@entry=0x7fffd801de80,
line=line@entry=312, column=column@entry=38, offset=offset@entry=11342,
format=0x68d086 "%s") at backend/control/messagefactory.cpp:472
#2 0x000000000057d4a7 in pov::Parser::Error (this=0x7fffe0004bb0, format=<optimized
out>) at parser/parser.cpp:10650
#3 0x00000000005845db in pov::Parser::Expectation_Error (s=0x6cdd0e "object",
this=0x7fffe0004bb0) at parser/parser.cpp:10569
#4 pov::Parser::Parse_Object (this=this@entry=0x7fffe0004bb0) at
parser/parser.cpp:6668
#5 0x00000000005876d1 in pov::Parser::Parse_CSG (this=this@entry=0x7fffe0004bb0,
CSG_Type=CSG_Type@entry=6) at parser/parser.cpp:2232
#6 0x0000000000584355 in pov::Parser::Parse_Object (this=this@entry=0x7fffe0004bb0)
at parser/parser.cpp:6625
#7 0x00000000005876d1 in pov::Parser::Parse_CSG (this=this@entry=0x7fffe0004bb0,
CSG_Type=CSG_Type@entry=8) at parser/parser.cpp:2232
#8 0x000000000058432d in pov::Parser::Parse_Object (this=this@entry=0x7fffe0004bb0)
at parser/parser.cpp:6615
#9 0x000000000058ef68 in pov::Parser::Parse_RValue (this=this@entry=0x7fffe0004bb0,
Previous=Previous@entry=173, NumberPtr=NumberPtr@entry=0x7fffd801fef0,
DataPtr=DataPtr@entry=0x7fffd801fee8, sym=sym@entry=0x7fffd801fed0,
ParFlag=ParFlag@entry=false, SemiFlag=true,
is_local=false, allow_redefine=true, allowUndefined=true, old_table_index=100) at
parser/parser.cpp:9287
#10 0x000000000058fc98 in pov::Parser::Parse_Declare (this=this@entry=0x7fffe0004bb0,
is_local=<optimized out>, after_hash=<optimized out>) at parser/parser.cpp:8779
#11 0x00000000005a0eca in pov::Parser::Parse_Directive
(this=this@entry=0x7fffe0004bb0, After_Hash=After_Hash@entry=1) at
parser/parser_tokenizer.cpp:2167
#12 0x000000000059c10d in pov::Parser::Get_Token (this=this@entry=0x7fffe0004bb0) at
parser/parser_tokenizer.cpp:451
#13 0x0000000000590a38 in pov::Parser::Parse_Frame (this=0x7fffe0004bb0) at
parser/parser.cpp:6816
#14 0x00000000005915a4 in pov::Parser::Run (this=0x7fffe0004bb0) at
parser/parser.cpp:210
#15 0x00000000005df87f in pov::Task::TaskThread (this=0x7fffe0004bb0, completion=...)
at backend/support/task.cpp:169
#16 0x00007ffff62ca5d5 in ?? () from
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
#17 0x00007ffff6ff96fa in start_thread (arg=0x7fffef114700) at pthread_create.c:333
#18 0x00007ffff5551b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
unwinding the calls, seems the parser encountered a '#' with either 'declare' or
'local', and we are parsing the right side of '='
It's an object, a merge containing a difference but the inner object failed to be
parsed. (at #4, Object = Parse_Object(); Object is 0x0)
Post a reply to this message
|
|
| |
| |
|
|
From: Yvo Smellenbergh
Subject: Re: Call for help with experimental development
Date: 14 Jul 2016 13:16:17
Message: <5787c8e0@news.povray.org>
|
|
|
| |
| |
|
|
On 2016-07-14 14:57:39 +0000, clipka said:
> Folks,
>
> as a few of you may already have noticed, I'm currently trying to
> implement a mechanism to cache macros in memory, to speed up calls to
> macros defined in other files.
>
> While the current work-in-progress code appears to work ok on Windows,
> /something/ seems to make it fail on Unix systems, in a manner that
> puzzles me.
>
> Since I can't do much Unix debugging myself, I'd be much obliged if
> someone could pick up the glove to do some experiments with the code at
> https://github.com/c-lipka/povray/tree/refactor/iostream, and give me a
> hint or two where things may be going wrong. Otherwise I'll probably
> have to abandon this attempt to speed up parsing.
Propably not of much use:
When I compile and run the code on OSX, all scenes render fine.
Compiled with my XCode project, not making use of the make utility.
Yvo
--
-------------------------------------------------------------------------------------------
POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14/07/2016 16:57, clipka a écrit :
> Folks,
>
> as a few of you may already have noticed, I'm currently trying to
> implement a mechanism to cache macros in memory, to speed up calls to
> macros defined in other files.
>
> While the current work-in-progress code appears to work ok on Windows,
> /something/ seems to make it fail on Unix systems, in a manner that
> puzzles me.
>
> Since I can't do much Unix debugging myself, I'd be much obliged if
> someone could pick up the glove to do some experiments with the code at
> https://github.com/c-lipka/povray/tree/refactor/iostream, and give me a
> hint or two where things may be going wrong. Otherwise I'll probably
> have to abandon this attempt to speed up parsing.
>
Looking at the output of Semaphore, the error location is bogus.
It is probably in shapes.inc, but at line 976, not 312.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.07.2016 um 19:43 schrieb Le_Forgeron:
> Looking at the output of Semaphore, the error location is bogus.
Oh really, is it? I wouldn't have noticed ;)
> It is probably in shapes.inc, but at line 976, not 312.
Now why exactly would you think that? I don't see a "max" in line 976
either.
Never mind, I've found the culprit. The code by which I'm copying the
macro code from the buffered text stream into memory was buggy for any
macro that was too large to fit entirely inside the buffer.
The problem did not manifest on Windows due to the larger buffer size
setting of 64k, as opposed to 0.5k on Unix. The Mac version also
presumably uses a larger buffer size.
The misplaced "max", btw, happened to be the second one in line 324,
which is exactly 512 characters after the start of the macro (presuming
Unix line endings).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Folks,
>
> as a few of you may already have noticed, I'm currently trying to
> implement a mechanism to cache macros in memory, to speed up calls to
> macros defined in other files.
>
> While the current work-in-progress code appears to work ok on Windows,
> /something/ seems to make it fail on Unix systems, in a manner that
> puzzles me.
>
> Since I can't do much Unix debugging myself, I'd be much obliged if
> someone could pick up the glove to do some experiments with the code at
> https://github.com/c-lipka/povray/tree/refactor/iostream, and give me a
> hint or two where things may be going wrong. Otherwise I'll probably
> have to abandon this attempt to speed up parsing.
Yesterday assembly from the source code did not work.
Today created a package on the file specification.
Just in case, I put the line
CXXFLAGS="-Wno-multichar -std=gnu++0x"
After that, from the source code program was created, too
make check - successfully
make install - successfully
run successfully
:)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
