I created a page on the wiki to document our wish-list of further 
enhancements to the POV SDL.

http://wiki.povray.org/content/Knowledgebase:Language_Feature_Requests

I added a few items I'd like to see.


-- 
http://isometricland.com

Post a reply to this message

On 04.06.10 21:50, SharkD wrote:
> I created a page on the wiki to document our wish-list of further
> enhancements to the POV SDL.
>
> http://wiki.povray.org/content/Knowledgebase:Language_Feature_Requests
>
> I added a few items I'd like to see.

I don't think such a list belong into the wiki at all.

	Thorsten

Post a reply to this message

On 6/4/2010 4:09 PM, Thorsten Froehlich wrote:
> On 04.06.10 21:50, SharkD wrote:
>> I created a page on the wiki to document our wish-list of further
>> enhancements to the POV SDL.
>>
>> http://wiki.povray.org/content/Knowledgebase:Language_Feature_Requests
>>
>> I added a few items I'd like to see.
>
> I don't think such a list belong into the wiki at all.
>
> Thorsten


Why not? Is information on development not a good choice? Would you 
prefer it tucked away somewhere where no-one can see it?

-- 
http://isometricland.com

Post a reply to this message

On 06/04/2010 05:09 PM, Thorsten Froehlich wrote:
> On 04.06.10 21:50, SharkD wrote:
>> I created a page on the wiki to document our wish-list of further
>> enhancements to the POV SDL.
>>
>> http://wiki.povray.org/content/Knowledgebase:Language_Feature_Requests
>>
>> I added a few items I'd like to see.
> 
> I don't think such a list belong into the wiki at all.

concur ... moved it into User:SharkD ... besides some of what you
requested is already implemented

Post a reply to this message

On 04.06.10 22:18, SharkD wrote:
> On 6/4/2010 4:09 PM, Thorsten Froehlich wrote:
>> On 04.06.10 21:50, SharkD wrote:
>>> I created a page on the wiki to document our wish-list of further
>>> enhancements to the POV SDL.
>>>
>>> http://wiki.povray.org/content/Knowledgebase:Language_Feature_Requests
>>>
>>> I added a few items I'd like to see.
>>
>> I don't think such a list belong into the wiki at all.
>
> Why not? Is information on development not a good choice?

It is not information on development. It is a wish list of things someone or 
some group of users feels might be useful in the future without actually 
having used it. It is no information on development that either will or may 
occur.

	Thorsten

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> I created a page on the wiki to document our wish-list of further
> enhancements to the POV SDL.
>
> http://wiki.povray.org/content/Knowledgebase:Language_Feature_Requests
>
> I added a few items I'd like to see.
>
>
> --
> http://isometricland.com

It's like a section: Features POV SDL has not compared to other SDL.
So I'd say it's right to be in the wiki. Like a comparison to other products.

Of course, the wiki should not become overcrowded!1

Greetings
DH

Post a reply to this message

Am 05.06.2010 12:23, schrieb DH0909:
> SharkD<mik### [at] gmailcom>  wrote:
>> I created a page on the wiki to document our wish-list of further
>> enhancements to the POV SDL.
...
>
> It's like a section: Features POV SDL has not compared to other SDL.
> So I'd say it's right to be in the wiki. Like a comparison to other products.

The proper place for a "feature wishlist" is the bugtracking and 
feature-request system on <http://bugs.povray.org>, as that's /the/ 
primary place where the developers will look for them. It's no good to 
have wishlists scattered about however-many places.

BTW, the bugtracker also provides a means for users to vote on bugs or 
features they deem particularly important to address.

Post a reply to this message

On 6/5/2010 10:00 AM, clipka wrote:

> The proper place for a "feature wishlist" is the bugtracking and
> feature-request system on <http://bugs.povray.org>, as that's /the/
> primary place where the developers will look for them.

The list is not for developers. It's for other users.


-- 
http://isometricland.com

Post a reply to this message

On 06/05/2010 03:46 PM, SharkD wrote:
> On 6/5/2010 10:00 AM, clipka wrote:
> 
>> The proper place for a "feature wishlist" is the bugtracking and
>> feature-request system on <http://bugs.povray.org>, as that's /the/
>> primary place where the developers will look for them.
> 
> The list is not for developers. It's for other users.
> 
> 

Sounds like the right place to me ... if I had a feature request that I
cared about I'd want the developers to know about it. If discussion and
list building is what your aim is, how about
povray.pov4.discussion.general ... are we getting any closer ;-)

Post a reply to this message

On 6/4/2010 4:47 PM, Jim Holsenback wrote:
> concur ... moved it into User:SharkD ... besides some of what you
> requested is already implemented

Which ones were implemented?



-- 
http://isometricland.com

Post a reply to this message

On 6/5/2010 3:00 PM, Jim Holsenback wrote:
> ...If discussion and
> list building is what your aim is, how about
> povray.pov4.discussion.general ... are we getting any closer ;-)

Where they will get buried once again... There needs to be a place where 
the /result/ of the discussion can be recorded. A log or some such. One 
where other information like bug reports aren't mixed in.


-- 
http://isometricland.com

Post a reply to this message

On 06/05/2010 11:41 PM, SharkD wrote:
> On 6/4/2010 4:47 PM, Jim Holsenback wrote:
>> concur ... moved it into User:SharkD ... besides some of what you
>> requested is already implemented
> 
> Which ones were implemented?
> 
> 
> 
Hmmmm ... I thought I was fairly clear with the posting I left in your
user space on the Wiki. You haven't been test driving the beta's have
you? Off the top of my head ... there is now a #for loop, and #break now
allows you to bail out of loops. The former was a new addition, and the
later was the result of a bug that I found by accident (a typo). As for
the various unary/binary operators, I noted that some not all that you
mentioned have been around for quite a while now. I'd be the first to
admit that some portions of the documentation can be rather dry reading,
but if you do some digging there is some useful information to be found ;-)

Post a reply to this message

On 06/05/2010 11:43 PM, SharkD wrote:
> On 6/5/2010 3:00 PM, Jim Holsenback wrote:
>> ...If discussion and
>> list building is what your aim is, how about
>> povray.pov4.discussion.general ... are we getting any closer ;-)
> 
> Where they will get buried once again... There needs to be a place where
> the /result/ of the discussion can be recorded. A log or some such. One
> where other information like bug reports aren't mixed in.
> 
> 

clipka pointed out the attributes of the bugtracker so I won't go over
that again. I really don't think that the KB namespace on the Wiki is a
sound choice, and the link to your post in the Questions and Tips table
of contents wasn't that prudent of a choice either. That leaves your
user space ... list away if you must, but I think the bugtracker is the
best choice :-)

Post a reply to this message

Am 06.06.2010 04:43, schrieb SharkD:
> On 6/5/2010 3:00 PM, Jim Holsenback wrote:
>> ...If discussion and
>> list building is what your aim is, how about
>> povray.pov4.discussion.general ... are we getting any closer ;-)
>
> Where they will get buried once again... There needs to be a place where
> the /result/ of the discussion can be recorded. A log or some such. One
> where other information like bug reports aren't mixed in.

Any feature request that does not wind up in the bugtracker /will/ get 
buried.

And the problem with /discussions/ about feature requests is that they 
tend to have /no/ clear-cut result whatsoever, as they tend do be free 
brainstorming sessions - unless there's someone with the necessary will 
and authority (e.g. because he has started the discussion in the first 
place) "driving" the discussion to a proper conclusion (ideally by 
summarizing the discussion and result in a proper place... like, say, 
the bugtracker ;-))

(Yes, the feature request description is a good place to summarize 
earlier discussions.)

Post a reply to this message

Again, I think it would be good to have a formal means of discussing and 
tracking feature requests for non-devs, since bugtracker seems to be 
"for devs only."

My reasoning is that feature requests are hidden once they are closed on 
bugtracker, so there's no obvious way to view them. There's also no way 
to discuss them further since discussions are closed once the request is 
locked.

This is definitely not a method that is amenable to users.

-- 
http://isometricland.com

Post a reply to this message

Am 20.06.2010 10:10, schrieb SharkD:
> Again, I think it would be good to have a formal means of discussing and
> tracking feature requests for non-devs, since bugtracker seems to be
> "for devs only."
>
> My reasoning is that feature requests are hidden once they are closed on
> bugtracker, so there's no obvious way to view them. There's also no way
> to discuss them further since discussions are closed once the request is
> locked.
>
> This is definitely not a method that is amenable to users.

Yes, I do agree that this practical attempt at what sounded good in 
theory did show some serious caveats of that process.

I don't think the way things were handled was the right way to handle 
them, but extrapolating from this experience, my idea of the process may 
be less universal than I had imagined; and similar outcomes may have to 
be expected in future, too.

My apologies for the inconvenience.

Post a reply to this message

On 6/20/2010 9:51 AM, clipka wrote:
> Am 20.06.2010 10:10, schrieb SharkD:
>> Again, I think it would be good to have a formal means of discussing and
>> tracking feature requests for non-devs, since bugtracker seems to be
>> "for devs only."
>>
>> My reasoning is that feature requests are hidden once they are closed on
>> bugtracker, so there's no obvious way to view them. There's also no way
>> to discuss them further since discussions are closed once the request is
>> locked.
>>
>> This is definitely not a method that is amenable to users.
>
> Yes, I do agree that this practical attempt at what sounded good in
> theory did show some serious caveats of that process.
>
> I don't think the way things were handled was the right way to handle
> them, but extrapolating from this experience, my idea of the process may
> be less universal than I had imagined; and similar outcomes may have to
> be expected in future, too.
>
> My apologies for the inconvenience.
Just going to drop a comment here. For POVRay, a "democratic" vote on 
feature thing may sort of work. Linden Labs uses the same system for 
their bug/feature tracker, and its gotten to be so much of a horrible 
swamp that even finding "if" something has been suggested, so you can 
vote, or comment, never mind do so before something gets closed,or 
relocated, or incorrectly marked as fixed (this happens a bit too often 
in some cases, sometimes due to a "we think we had a fix pending, only 
it didn't work, but no one bothered to reopen the issue, when it 
failed", or just lost in the mire. My opinion of such systems is, as a 
result... rather jaded. lol Not sure, reading the posts on the subject, 
over the last 24 hours, is impressing me with it here either. Seems like 
we are seeing the same sort of issues, "I think my suggestion still 
needs time to be commented on, but someone closed it.", sort of thing. 
Don't make the same mistakes Linden has.

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

clipka wrote:

> Yes, I do agree that this practical attempt at what sounded good in 
> theory did show some serious caveats of that process.

I think the basic idea is reasonable so if there are problems
with the process the way to go may be to simply tweak the process.
Here are my 2 cents on that:

1. The POV-Ray community is strong in the forum so I think
    that would be the best place for discussing (not tracking)
    new feature suggestions.

2. The bug tracker could be officially extended to also track
    feature requests (although you can currently add them, this
    is not described or commented on anywhere). A sensible rule
    for opening a new feature request would then be that it must
    be discussed in the newsgroups first, to weed out crackpot
    ideas and to refine ideas by feedback from what users
    actually need.

3. After discussion, the request should only be entered if a member of
    the POV-Ray team deems the request reasonable (note that a request
    should not be deemed unreasonable at this point just because it would
    be too much effort to implement right now).

4. This process only works if each feature request in the newsgroups
    actually gets read by member of the POV team, so it might be useful
    to add a new group povray.feature-requests or similar.

5. The feature request entry should link back to the newsgroup thread
    discussing the feature request, and a link to the new task should be
    posted on the thread as a notification.

6. Once a feature request is added it must remain visible whatever
    state it is set to. I have no experience with Flyspray but I'd
    expect there to be some configuration/solution for this.

Post a reply to this message

On 6/20/2010 4:38 PM, Patrick Elliott wrote:
> Just going to drop a comment here. For POVRay, a "democratic" vote on
> feature thing may sort of work. Linden Labs uses the same system for
> their bug/feature tracker, and its gotten to be so much of a horrible
> swamp that even finding "if" something has been suggested, so you can
> vote, or comment, never mind do so before something gets closed,or
> relocated, or incorrectly marked as fixed (this happens a bit too often
> in some cases, sometimes due to a "we think we had a fix pending, only
> it didn't work, but no one bothered to reopen the issue, when it
> failed", or just lost in the mire. My opinion of such systems is, as a
> result... rather jaded. lol Not sure, reading the posts on the subject,
> over the last 24 hours, is impressing me with it here either. Seems like
> we are seeing the same sort of issues, "I think my suggestion still
> needs time to be commented on, but someone closed it.", sort of thing.
> Don't make the same mistakes Linden has.
>

I would just like to clarify that I'm not advocating a "democratic" way 
of choosing which features should and should not be implemented, or 
which are that most critical. I just want a way to track and discuss 
ideas that isn't subject to being "blocked" or "locked" on some dev's whim.


-- 
http://isometricland.com

Post a reply to this message

On 21.06.10 01:04, Christian Froeschlin wrote:
> 3. After discussion, the request should only be entered if a member of
> the POV-Ray team deems the request reasonable (note that a request
> should not be deemed unreasonable at this point just because it would
> be too much effort to implement right now).

That was my understanding of what clipka has previously suggested in this 
thread already:

 >> And the problem with /discussions/ about feature requests is that they
 >> tend to have /no/ clear-cut result whatsoever, as they tend do be free
 >> brainstorming sessions - unless there's someone with the necessary will
 >> and authority (e.g. because he has started the discussion in the first
 >> place) "driving" the discussion to a proper conclusion (ideally by
 >> summarizing the discussion and result in a proper place... like, say,
 >> the bugtracker ;-))
 >>
 >> (Yes, the feature request description is a good place to summarize
 >> earlier discussions.)

	Thorsten

Post a reply to this message

On 06/21/2010 10:38 AM, SharkD wrote:
> I just want a way to track and discuss
> ideas that isn't subject to being "blocked" or "locked" on some dev's whim.

I'm going to jump in here for a moment ... starting something is not my
intention, but these kind of statements can sometimes escalate things,
when it's not necessary. To be clear "whim" is just an unfair
characterization. At last count (I'm unsure) there were only a handful
of people working on issue's (getting 3.7 release ready), so there is
only a finite number of things that can be done, given personal demands
on everyones time. Now PLEASE don't take this wrong, but some of the
things that you've put forth ... well face it, you haven't done your
homework ;-) ... other things have been spot on valid. Good solid and
well thought out ideas about how things should work or be is what we all
want ... right?

Jim

Post a reply to this message

On 6/20/2010 7:04 PM, Christian Froeschlin wrote:
> 4. This process only works if each feature request in the newsgroups
> actually gets read by member of the POV team, so it might be useful
> to add a new group povray.feature-requests or similar.

That would at least narrow down the places where non-dev-requested 
features occur to a single location.


-- 
http://isometricland.com

Post a reply to this message

On 6/20/2010 7:04 PM, Christian Froeschlin wrote:
> 5. The feature request entry should link back to the newsgroup thread
> discussing the feature request, and a link to the new task should be
> posted on the thread as a notification.

...but then things end up scattered around multiple locations again.

-- 
http://isometricland.com

Post a reply to this message

I can cite Vega Strike as a project that HAPPILY stores feature requests 
in a wiki because of the sheer volume of feature requests and to serve 
as a place to direct people who raise duplicate issues.

See:
http://vegastrike.sourceforge.net/forums/viewtopic.php?f=6&t=6280

And:
http://vegastrike.sourceforge.net/wiki/FAQ:Feature_Requests

-- 
http://isometricland.com

Post a reply to this message

On 06/21/2010 02:18 PM, SharkD wrote:
> I can cite Vega Strike as a project that HAPPILY stores feature requests
> in a wiki because of the sheer volume of feature requests and to serve
> as a place to direct people who raise duplicate issues.
> 
> See:
> http://vegastrike.sourceforge.net/forums/viewtopic.php?f=6&t=6280
> 
> And:
> http://vegastrike.sourceforge.net/wiki/FAQ:Feature_Requests
> 
no one ever tired to stop you ... just where you were putting the list,
and the links to your list.

knock yer self out:
http://wiki.povray.org/content/Knowledgebase:POV-Ray_Feature_Requests
and:
http://wiki.povray.org/content/Knowledgebase_Talk:POV-Ray_Feature_Requests

Post a reply to this message

On 6/21/2010 6:38 AM, SharkD wrote:
> I would just like to clarify that I'm not advocating a "democratic" way
> of choosing which features should and should not be implemented, or
> which are that most critical. I just want a way to track and discuss
> ideas that isn't subject to being "blocked" or "locked" on some dev's whim.
>
Not talking about you specifically. There was just a mention, some place 
up the threads, about how you can "vote" an item. This becomes a mess at 
some point. There are dozens of issues with design, missing functions, 
etc. in Second Life, and its scripting system, which don't get looked at 
because its become the habit of the staff there to sort through the 
morass of postings by looking at the number of people that voted "for" 
the item in question. So, you can have an important issue that doesn't 
get solved for a year, because no one knew to vote on it, and some 
trivial widget, which seems popular, get fixed in 3 days. The only good 
thing here is, I doubt the POVRay bug tracker is ever going to get as 
big as the one Linden has. ;)

The only thing I agree with you on, since you definitely have made some 
errors here, is that *maybe* the original poster should have the option 
of re-opening a subject, as long as they post additional details, which 
make what they are proposing clearer, or something. It is possible for 
someone to have a good idea, but not an immediately clear concept of how 
to describe it, then just not have time to add that (or forget to) 
before someone nukes the item. That is a legit issue, imho.

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

On 21.06.10 20:33, Patrick Elliott wrote:
> The only thing I agree with you on, since you definitely have made some
> errors here, is that *maybe* the original poster should have the option
> of re-opening a subject, as long as they post additional details, which
> make what they are proposing clearer, or something.

Fact is the OP had made 26 feature requests, almost 1/5th of all reports in 
the bug reporter, and of those only 8 remain closed. Of those eight, six 
were closed by me.

	Thorsten

Post a reply to this message

On 21/06/2010 09:04, Christian Froeschlin wrote:
> 6. Once a feature request is added it must remain visible whatever
>     state it is set to. I have no experience with Flyspray but I'd
>     expect there to be some configuration/solution for this.

There isn't a knob in the config for this. I'd have to dig into the code to
find out how the default search options are set.

(If anyone who is familiar with PHP wants to grab a copy of the flyspray
source and find out please feel free:)

-- Chris

Post a reply to this message

On 22/06/2010 04:33, Patrick Elliott wrote:
 I agree with you on, since you definitely have made some
> errors here, is that *maybe* the original poster should have the option 
> of re-opening a subject, as long as they post additional details, which 
> make what they are proposing clearer, or something. It is possible for 

There is an option to allow comments on closed bug reports, which I've now
enabled. This doesn't re-open it, but at least it allows for feedback.

-- Chris

Post a reply to this message

Chris Cason wrote:

> (If anyone who is familiar with PHP wants to grab a copy of the flyspray
> source and find out please feel free:)

I'm not familiar with PHP, but if the entry page of the
web site (and also the homelink/tasklist which is currently 
http://bugs.povray.org/proj0?do=index) could be changed to

http://bugs.povray.org/index.php?&status[0]=&order=status&order2=severity

it should show all entries with closed ones at the end of the list.

Post a reply to this message

On 6/21/2010 3:27 PM, Chris Cason wrote:
> There is an option to allow comments on closed bug reports, which I've now
> enabled. This doesn't re-open it, but at least it allows for feedback.
>
> -- Chris

Thank you! That should be satisfactory. (Though making them visible by 
default might not be bad either.)

-- 
http://isometricland.com

Post a reply to this message