 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
mmm, povray.bugreports seems to be locked. o well.
2.2.1.2 Comments (block comments).
up to v3.6. (don't know about 3.7beta).
Probably already know, and trivial, but still ... not seeing any mention of
it in (online) doc's.
Povray's-Editor syntax highlighting is a little off when it comes to
following the syntax rules for nested block comments. (its highliting them
in default c-style)
Also (very trivial), think the example is not really showing the difference
to not nested block-comment style.
---(org)
/* This is a comment
// This too
/* This also */
*/
---
---(mine)
/* This is a comment
// This too
/* This also */
and this one is also a comment
*/
---
Come to think of it, this probebly make the SciTe-Pov-Lexer the only true
compliant Povray-syntax-highlighter in the world. :-)
(damn C-junkies ;-) )
anyway, a trivial mail from a trivial individual.
cheers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MvGulik wrote:
> mmm, povray.bugreports seems to be locked. o well.
>
> 2.2.1.2 Comments (block comments).
>
> up to v3.6. (don't know about 3.7beta).
This is the wrong group for this message. Please read
Newsgroups: povray.announce.frequently-asked-questions
Subject: bug reporting
Date: Wed, 10 Jul 2002 20:32:49 -0700
From: Alan Kong <ako### [at] povrayWWW SPAMCOMorg>
Message-ID: <fpupiu02i1198jbb38i3o06hv6is1a3uar@4ax.com>
Xref: news.povray.org povray.announce.frequently-asked-questions:50
Thorsten, POV-Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rigghht.
Sorry for trespassing in the programmers geek club o honourable master.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MvGulik <.......@dds.nl> wrote:
> Rigghht.
> Sorry for trespassing in the programmers geek club o honourable master.
Do you think that's the attitude that will give you serious answers
to your questions?
You are an invited guest in this news servers. You behave as the owners
want you to behave. It's that simple. (And it's not like the usage policy
of this server would be unreasonable in any way.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"MvGulik" <.......@dds.nl> wrote in message news:442261cf@news.povray.org...
> mmm, povray.bugreports seems to be locked. o well.
>
> 2.2.1.2 Comments (block comments).
>
> up to v3.6. (don't know about 3.7beta).
>
> Probably already know, and trivial, but still ... not seeing any mention of
> it in (online) doc's.
>
> Povray's-Editor syntax highlighting is a little off when it comes to
> following the syntax rules for nested block comments. (its highliting them
> in default c-style)
>
> Also (very trivial), think the example is not really showing the difference
> to not nested block-comment style.
>
> ---(org)
> /* This is a comment
> // This too
> /* This also */
> */
> ---
> ---(mine)
> /* This is a comment
> // This too
> /* This also */
> and this one is also a comment
> */
> ---
>
> Come to think of it, this probebly make the SciTe-Pov-Lexer the only true
> compliant Povray-syntax-highlighter in the world. :-)
> (damn C-junkies ;-) )
>
> anyway, a trivial mail from a trivial individual.
> cheers
I can confirm this bug exists in 3.7.0.beta.11c as well.
A minimal test case is:
/*
/* correctly highlighted */
incorrectly highlighted
*/
Lance.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch <-> wrote:
> I can confirm this bug exists in 3.7.0.beta.11c as well.
It's not so much a bug (ie. a programming error) than a limitation
of the editor. Limitations are not bugs.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:44250ffe@news.povray.org...
> Lance Birch <-> wrote:
> > I can confirm this bug exists in 3.7.0.beta.11c as well.
>
> It's not so much a bug (ie. a programming error) than a limitation
> of the editor. Limitations are not bugs.
I suppose, but the behaviour surely isn't intended: comments should be
highlighted as comments, only in certain situations they aren't correctly
highlighted. From the end users' perspective it's a "bug" - it's not doing
what's expected.
It'd be like saying that the trace-and-no_image bug was a limitation rather than
a bug (in both cases something that's expected to happen doesn't happen).
In any case, it's a minor issue.
Meanwhile I'm still trying to reliably replicate a "60-second-freeze" bug that
happens with 3.7.0.beta.11c and prior versions as well (has anyone else
experienced this?). It happened again today... it's a combination of tip of the
day being displayed and the splash screen, but I can't reproduce it reliably; it
only ever happens when tip of the day has been displayed and clicked past, and
then the splash image displayed and clicked past, at which point the interface
stops responding for 60 seconds (with no CPU usage), and then unfreezes and is
fine again.
I've experienced "uncategorized parse error" a few times too, though again I
haven't been able to reliably replicate the circumstances that create it (and I
think it might be to do with something that's not in the build on the website
anyway).
Lance.
thezone - thezone.firewave.com.au
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch <-> wrote:
> I suppose, but the behaviour surely isn't intended: comments should be
> highlighted as comments, only in certain situations they aren't correctly
> highlighted. From the end users' perspective it's a "bug" - it's not doing
> what's expected.
> It'd be like saying that the trace-and-no_image bug was a limitation rather than
> a bug (in both cases something that's expected to happen doesn't happen).
It all comes down to the definition of "bug".
There are basically three ways a program may work in a way it shouldn't:
1: A behaviour has been clearly specified when designing the program and
the programmer had the intention to code it correctly, but made a mistake
which slipped during testing and thus the program doesn't work correctly
and against the specification. This is clearly a programming error, ie. a
bug.
2: Something more or less obvious is not specifically stated as a
requirement for the program, either because of a human overlook or
just because nobody thought about it, and thus it gets never implemented.
Usually it's something that, when the programmer is told about, he goes
"doh, I didn't about that one". In a way one could classify this as a
programming mistake, ie. a bug. It just happened at a bit higher level.
Problems with some POV-Ray features such as related to trace and no_image
fall into this category.
3: Something was specified differently than what the future use of
the feature requires. The programmer codes exactly and flawlessly as
specified, and the program works as specified. Only in a future unexpected
scenario it turns out that the specification was lacking.
This is the case with the winpov editor and nested comments: The original
coder never thought that it could be used for a language supporting C-style
comments which can be (legally) nested and thus never bothered to even add
support for that. You have to remember that the editor was a completely
separate and independent program from POV-Ray, and that they were joined
at some point. The original coder of the editor couldn't have predicted
that his editor will be used for POV-Ray SDL in the future.
It's thus not a bug, it's just a limitation, a flawed design. That, of
course, doesn't mean that it wouldn't be a great thing if support for
nested comments would be added to the editor. However, it would be wrong
to call it "a bug".
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch wrote:
>>>I can confirm this bug exists in 3.7.0.beta.11c as well.
>>
>> It's not so much a bug (ie. a programming error) than a limitation
>>of the editor. Limitations are not bugs.
>
> I suppose, but the behaviour surely isn't intended
It most certainly is intended. IIRC I vaguely remember it actually being
documented somewhere (older release notes maybe?) or having been discussed
before. It is just that nested comments cannot be colored correctly for
computational complexity reasons. It is not a bug, and anyway the way it was
"reported" and where it was "reported" were simply unacceptable.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> It is just that nested comments cannot be colored correctly for
> computational complexity reasons.
If nested comments can be *parsed* correctly (as povray does), they
certainly can be colored correctly.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>>It is just that nested comments cannot be colored correctly for
>>computational complexity reasons.
>
> If nested comments can be *parsed* correctly (as povray does), they
> certainly can be colored correctly.
Carefully re-read my sentence ;-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:4425c372$1@news.povray.org...
> Warp wrote:
> >>It is just that nested comments cannot be colored correctly for
> >>computational complexity reasons.
> >
> > If nested comments can be *parsed* correctly (as povray does), they
> > certainly can be colored correctly.
>
> Carefully re-read my sentence ;-)
Heh... yes but it can't be that computationally intenstive because there are
other editors that handle nested comments (e.g. "ED", emacs, etc).
However, it's probably a lot of work to implement for very little gain. On the
other hand issues like artifacts with +b2 are more important to resolve (btw the
render time difference that it makes can be significant - 30% faster in many
cases, which is fantastic).
Lance.
thezone - thezone.firewave.com.au
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch <-> wrote:
> However, it's probably a lot of work to implement for very little gain.
I don't understand why. Parsing them is quite trivial, so coloring them
correctly should be too. Just increase a counter when /* is encountered
and decrease it when */ is encountered, When the counter gets back to 0,
that's the end of the comment.
Of course there may be ambiguous cases like this:
/*
#debug "Comments end with the */ symbol\n"
*/
However, I don't think it would be so difficult to make the syntax-coloring
algorithm to interpret that like the parser does (and in fact, if it does so,
it helps the user to immediately spot a potential problem with comments
if there exists one, as might be the case here).
In fact, I just checked and the above causes a syntax error in POV-Ray
because it doesn't "parse" strings inside comments. Thus coloring that
becomes quite simple, as I described above (ie. with a simple counter).
And as I said, the user would immediately spot the problem while editing
the text because the syntax coloring clearly shows that the comment is
ending somewhere he didn't expect.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:442638df@news.povray.org...
> Lance Birch <-> wrote:
> > However, it's probably a lot of work to implement for very little gain.
>
> I don't understand why.
I don't have any idea how the editor currently does its syntax highlighting, so
I don't know what's involved in implementing this - I assume it mustn't be as
easy as I thought it would be if it hasn't been done already.
Obviously I agree with what you're saying though because I'd like to see it
"fixed"/implemented.
As I mentioned, there are other editors that seem to be able to do it without
any problems, but I'm also willing to accept that it's a low priority in the
scheme of things.
Lance.
thezone - thezone.firewave.com.au
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch <-> wrote:
> I don't have any idea how the editor currently does its syntax highlighting, so
> I don't know what's involved in implementing this - I assume it mustn't be as
> easy as I thought it would be if it hasn't been done already.
The explanation may be as simple as:
The editor code has been made by someone else, and trying to figure out
from someone else's code exactly where the comment-coloring code is and
how it works and how it should be modified is too much trouble taking into
account the enormous amount of more important other work yet to be done.
Trying to figure out someone else's code is often a rather appalling
prospect. I know this from personal experience. :)
For example, I once, many years ago, tried to compile mplayer for
Sparc/Solaris. At that time the support for that platform was not very good,
but after some tweaking I got it compiled and running. The only problem
was that the program made a check that the target architecture byte
endianess was not supported (ultrasparc is a high-endian processor, unlike
intels, which are low-endian) and refused to continue.
Well, I located the check (it was easy to find by just searching the
error message and then the place where it was being used) and removed it.
Presto, the video started showing. The only problem was that the red and
blue channels were swapped.
In the end, the solution was rather simple: It was enough to swap the
indexing values in two lines of code in one file (I used #ifdefs for better
compatibility). However, it took me over an hour to actually locate those
two lines. mplayer is such an enormously complex program that it was
really hard to try to figure out its inner workings.
Locating and understanding the syntax-coloring code in the winpov
editor is probably not this hard, but given that there are more urgent
issues at hand, it's probably a quite low-priority task.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I don't understand why. Parsing them is quite trivial, so coloring them
> correctly should be too. Just increase a counter when /* is encountered
> and decrease it when */ is encountered,
The way (most) editors do it is by just looking at what is visible when
printing a line, i.e. you can determine most commenting coloring based on
what is on screen. This just leaves the case of the first line visible on
screen, and for that you just have to search up until the first comment
opening or closing and can then decide what to do. With recursive comments,
you always need to parse the whole file when a comment is changed. For small
files nobody will notice, but for i.e. a 20 MB file even today you would
probably notice some lag when editing. And of course, five years ago that
was just plain impossible to do efficiently for a plain text editor (it is
different if you have an editor that support styles or a specifically built
comment-tracking). The trouble is that this again makes a generic syntax
highlighting engine a lot more complex to implement and even more complex to
set up.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> The way (most) editors do it is by just looking at what is visible when
> printing a line, i.e. you can determine most commenting coloring based on
> what is on screen. This just leaves the case of the first line visible on
> screen, and for that you just have to search up until the first comment
> opening or closing and can then decide what to do. With recursive comments,
> you always need to parse the whole file when a comment is changed. For small
> files nobody will notice, but for i.e. a 20 MB file even today you would
> probably notice some lag when editing. And of course, five years ago that
> was just plain impossible to do efficiently for a plain text editor (it is
> different if you have an editor that support styles or a specifically built
> comment-tracking). The trouble is that this again makes a generic syntax
> highlighting engine a lot more complex to implement and even more complex to
> set up.
I do understand that syntax-coloring block comments in general can be
inefficient due to exactly what you mention: It can't be done in a
line-by-line basis but the beginning and the end of the comment has
to be searched in order for the editor to know what to color. However,
the current editor does that, and nobody has complained about its speed,
so I suppose it does it at a reasonable one.
Is adding support for nested comments really that much heavier than
supporting single comments? I can't fathom the possible reason for that,
unless the current block-comment coloring has some kind of optimization
which relies on not having nested comments, such as marking the beginning
and end lines of a comment block and re-scanning the file only if one of
these two lines is modified or if in the current line the end-of-comment
symbol is written (trivially detectable by the program, obviously).
Now that I think about it, that might actually be quite reasonable.
I don't know how editors do perform block-comment coloring, but such
an optimization as I mentioned above could very well be a common
technique, and one which gets more complex with nested comments.
OTOH, I can't really think of why nested comments would make it any
more inefficient. Granted, it would require a bit more of coding and
actually supporting nested marks for beginning/ending lines, but I don't
think that's computationally expensive at all (ie. not more expensive
than single block comment coloring).
Anyways, I do understand why it is not being done. It's a rather
low-priority issue and there are much more important things to do.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Is adding support for nested comments really that much heavier than
> supporting single comments?
Yes, just try to think about the algorithm: It would always have to search
the whole file in both directions to determine where it is inside nested
comments, while the non-nested version can abort as soon as it finds the
first closing of a comment to know it isn't inside a comment, and the first
opening to know that it is inside an opening (all based on searching from
the first visible line to the beginning of the file). Alternatively it would
have to somehow keep track of comments at least on a line-by-line basis
(comment count would do, I think, but I haven't verified that). It basically
gets messy, and even then it would only for as long as there is one type of
multi-line comments (I don't know of any language that has more off-hand,
but I certainly can imagine one). Basically, the algorithm for non-nested is
simple and fast, but the nested case is either messy and probably fast or
simple and slow. And that is why I said coloring cannot be done due to
computational complexity. Of course it is possible, but with much added
complexity.
Thorsten
PS: In the Mac version I "solved" the problem in a different way. The editor
simply colors the comment-characters and single-line comments only. That way
it is really fast, even on the oldest Macs it can run on. Coloring exists
since POV-Ray 3.1 on Macs, and that could run on systems with just a MC
68020 - meaning with less than five MIPS average performance available...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
