headers
Philippe Vaucher | 1 Nov 01:02
Picon

Re: Boost Timer Update

>
> I haven't tried it but according to various links, GetSystemTime() only
> gives
> ~10ms or ~15ms precision

Thank you for the links!

Some results looks bizarre tho, like timeGetTime() at the same level than
GetTickCount() seems quite weird to me.
The graphs also seems to indicate QPC has one of the largest call overhead,
would it be a concern ?

Anyway, this makes me wonder what is the rational behind using
GetSystemTimeAsFileTime() to implement date_time::microsec_clock ? Does
anyone know (or could an author entlighten us) ?

This also raise another question, if we chose to implement microsec_timer
with QPC, what will we name the timer implemented with
posix_time::microsec_clock (which is just a typedef for
date_time::microsec_clock) ?

Philippe
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 8 comments |
headers
Eric Niebler | 1 Nov 01:01
Picon
Favicon

Re: [proto] interface changes


David Greene wrote:
> Eric Niebler wrote:
>> To all those currently using the proto expression template toolkit at 
>> boost/xpressive/proto (all 2 of you, you know who you are), this is a 
>> heads up that the code has been rewritten, and the interfaces changed 
>> considerably. The changes have been committed to HEAD.
> 
> First I've heard of this.  Are there docs anywhere?

Heh. You snipped the part where I said, "Now that I have an interface I 
can live with, I'm more inclined to write docs, and I will."

So the answer is no, there are no docs yet. It's on my To-Do list, but 
you might find /libs/xpressive/test/ext_/toy_spirit.cpp interesting. 
It's a prototype for Spirit-2 using proto. I just added it to HEAD early 
this morning. There's also xpressive itself, which is a much more 
elaborate client of proto.

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Jason Hise | 1 Nov 01:28
Picon

Re: [proposal] Sequence container with O(log n) random access _and_ O(log n) insertion/removal (wherever)

On 10/31/06, Martin Knoblauch Revuelta <mkrevuelta <at> gmail.com> wrote:
> On 10/31/06, Jason Hise <0xchaos <at> gmail.com> wrote:
> >
> > I don't entirely understand the benifit of your 'non-proportional
> > sequence view'.  What use cases can you think of where this would be
> > beneficial to client code?
>
> The best example I've thought of is a text editor [...]
> For the next version I have designed an interface that allows having
> more than one NPSV width, and indexing separately by each one of them.

Wouldn't it make more sense to have a container of containers if you
want to do this?  Or am I misunderstanding something?

>
> >  Right now it seems like it adds
> > unjustified bloat to the library.
>
> The empty_number class, used as default value for the template
> parameter W, contains no data, so it should be optimized away by any
> compiler.

I was referring more to lines of code and elegance of implementation.

> By the way, somebody asked me if I could implement splice methods. I
> am doing it, but I'm calling them move, since splice is a specific
> name referring how this is done with lists, and remarking that it
> takes O(1) time, which will be false here. What do you think?

I think that the member function should still be called splice for the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Garland | 1 Nov 02:03

Re: Boost Timer Update

Philippe Vaucher wrote:
>> I haven't tried it but according to various links, GetSystemTime() only
>> gives
>> ~10ms or ~15ms precision
> 
> 
> Thank you for the links!
> 
> Some results looks bizarre tho, like timeGetTime() at the same level than
> GetTickCount() seems quite weird to me.
> The graphs also seems to indicate QPC has one of the largest call overhead,
> would it be a concern ?
> 
> Anyway, this makes me wonder what is the rational behind using
> GetSystemTimeAsFileTime() to implement date_time::microsec_clock ? Does
> anyone know (or could an author entlighten us) ?

Sorry to be so quiet...it's not that I'm not interested, just too busy to 
really contribute. Anyway, the reason for GetSystemTimeAsFileTime is that it 
works.  And it doesn't suffer from the rollover issue and the stability issues 
that the QPC stuff does in the face of multi-threading.  So it just works and 
it gives enough precision for 90% of the applications.

> This also raise another question, if we chose to implement microsec_timer
> with QPC, what will we name the timer implemented with
> posix_time::microsec_clock (which is just a typedef for
> date_time::microsec_clock) ?

I'll be happy to replace the current microsec_clock implementation as long as 
you can deal with rollover and multi-threading.  Oh, and you can't add any
(Continue reading)

Permalink | Reply | 7 comments |
headers
Lubomir Bourdev | 1 Nov 02:47
Picon
Favicon

Re: GIL Review


Stefan Heinzmann wrote:
> 
> Maybe it's just me but I find extending GIL to support 
> something like the v210 Quicktime format quite challenging (I 
> don't want to imply that this is GIL's fault). This is a 
> 10-bit YUV 4:2:2 format which stores 6 pixels in 16 bytes. It 
> appears to me as if trying to support it would touch on a lot 
> of concepts and corners of GIL, as it would require a new 
> pixel storage format, color space, component subsampling, and 
> maybe more.
> 
> I believe it would help understanding if you could try to 
> give at least a road map of what needs doing to support this 
> properly (a fully coded example would probably require quite 
> some effort).
> 

Stefan,

This is an excellent example for a very complicated image format.
Here is a link that I found that describes it:

http://developer.apple.com/quicktime/icefloe/dispatch019.html#v210

Basically, each 16 bytes contain 6 packed Y'CbCr pixels, each channel of
which is 10-bits long. Some of the channels are shared between different
pixels.

Here is a rough plan of how I would approach modeling this in GIL:
(Continue reading)

Permalink | Reply | 3 comments |
headers
SourceForge.net | 1 Nov 03:54
Picon
Favicon

[Boost-bugs] [ boost-Bugs-1588359 ] "Bug" in comment

Bugs item #1588359, was opened at 2006-10-31 18:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1588359&group_id=7586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexis Wilke (alexis_wilke)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Bug" in comment

Initial Comment:
This is very low priority!

Hey guys,

In this file:

  http://boost.org/boost/integer.hpp

there is the following comment which says '9=unsigned
long' and the code says '9=unsigned char'. Should
someone get rid of that comment or fix it?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Edward Lam | 1 Nov 04:09
Picon
Favicon

Re: Boost Timer Update

Jeff Garland wrote:
> I'll be happy to replace the current microsec_clock implementation as long as 
> you can deal with rollover and multi-threading.

I guess it depends on what you're using the timer for. I really don't mind 
either way as long as the behaviour is well-documented. When I'm using a 
"microsecond timer", it is because I want to measure short intervals, not long 
ones. But perhaps there should be clearer ways of specifying the 
precision/accuracy/resolution trade-offs desired?

Philippe Vaucher wrote:
> This also raise another question, if we chose to implement microsec_timer
> with QPC, what will we name the timer implemented with
> posix_time::microsec_clock (which is just a typedef for
> date_time::microsec_clock) ?

On second thought, apparently Java calls their QPC implementation is called 
"nano" instead. Perhaps we could use that terminology as well?

On the QPC implementation, someone here 
(http://channel9.msdn.com/ShowPost.aspx?PostID=156175) suggested that it's might 
be good enough to call SetThreadAffinityMask() to cpu 0 and then set it back to 
the old value when done. I have no idea what type of overhead it imposes though.

For more robust QPC implementations, the following two links have some more 
ideas. As Jeff suggests here, this is not new but this is the first time I've 
really looked seriously at the issue as QPC always worked well enough for my 
profiling purposes.

http://msdn.microsoft.com/msdnmag/issues/04/03/HighResolutionTimer/
(Continue reading)

Permalink | Reply | 5 comments |
headers
Matt Gruenke | 1 Nov 04:34

Re: GIL Review

Joel de Guzman wrote:

>Lubomir Bourdev wrote:
>  
>
>>I guess our documentation was not very clear... 
>>The only aspects that GIL color spaces combine are the ordering and the
>>name of the channels. Maybe using Fernando's suggestion things will be
>>clearer - instead of color spaces, think of them as "pixel formats".
>>    
>>
>
>Ouch. But "color space" is a known terminology. Search wikipedia
>and you'll get: http://en.wikipedia.org/wiki/Color_space. Now
>try "pixel format" and you'll get nothing. Do we really want
>to reinvent terminology?
>  
>

I think inventing new terminology is better than overloading or 
hijacking existing terminology.  Furthermore, I believe good names 
accurately describe the concepts to which they refer.  Finally, as a 
user, seeing an unfamiliar term will either prompt me to investigate it 
- or at least to treat it as an unknown, and therefore with appropriate 
caution.

In contrast, misleading terminology gives the false sense of 
understanding and leads to misuse and unpleasant surprises.

Regarding your supporting point, if I'm using a Boost library, the place
(Continue reading)

Permalink | Reply | 21 comments |
headers
Joel de Guzman | 1 Nov 05:44
Picon
Favicon

Re: GIL Review

Matt Gruenke wrote:
> Joel de Guzman wrote:
> 
>> Lubomir Bourdev wrote:
>>  
>>
>>> I guess our documentation was not very clear... 
>>> The only aspects that GIL color spaces combine are the ordering and the
>>> name of the channels. Maybe using Fernando's suggestion things will be
>>> clearer - instead of color spaces, think of them as "pixel formats".
>>>    
>>>
>> Ouch. But "color space" is a known terminology. Search wikipedia
>> and you'll get: http://en.wikipedia.org/wiki/Color_space. Now
>> try "pixel format" and you'll get nothing. Do we really want
>> to reinvent terminology?
>>  
>>
> 
> I think inventing new terminology is better than overloading or 
> hijacking existing terminology.  Furthermore, I believe good names 
> accurately describe the concepts to which they refer.  Finally, as a 
> user, seeing an unfamiliar term will either prompt me to investigate it 
> - or at least to treat it as an unknown, and therefore with appropriate 
> caution.

I see no overloading or hijacking.

> In contrast, misleading terminology gives the false sense of 
> understanding and leads to misuse and unpleasant surprises.
(Continue reading)

Permalink | Reply | 20 comments |
headers
Joel de Guzman | 1 Nov 05:50
Picon
Favicon

Re: GIL Review

Joel de Guzman wrote:
> Matt Gruenke wrote:

>> Regarding your supporting point, if I'm using a Boost library, the place 
>> I'd look for usage information is the library's docs - not Wikipedia.  
>> Of course, if questions about the problem domain (or common solution 
>> practices) arise, when reading the library docs, I would obviously turn 
>> to other resources.  So long as the library makes precise use of 
>> standard terminology, and carefully documents non-standard terminology 
>> when standard terminology is non-existent or cannot be used precisely, I 
>> see no problem.
> 
> That's not my point. Take a look at all the existing libraries
> that use concepts. Pick one; Vigra seems popular. Note:
> http://tinyurl.com/y3mgfn I see no "pixel format" there.
> Pick another one: http://tinyurl.com/18r. See the term
> "color space" again?

Oops. I wonder why tinyurl didn't pick that one.
Try http://tinyurl.com/yye9tq. And see the term "color space".

Regards,
--

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 0 comments |

Gmane