Helló http://lists.boost.org/MailArchives/boost/ http://lists.boost.org/MailArchives/boost/msg77147.php Érdemes bele-bele nézni a listába. üdv gsd On Wed, 29 Dec 2004 boost-request@lists.boost.org wrote:
Send Boost mailing list submissions to boost@lists.boost.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request@lists.boost.org
You can reach the person managing the list at boost-owner@lists.boost.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..."
The boost archives may be found at: http://lists.boost.org/MailArchives/boost/
Today's Topics:
1. [mpl] value2type generalization of int_ needed (Larry Evans) 2. Re: [mpl] value2type generalization of int_ needed (Daniel Wallin) 3. Re: [mpl] value2type generalization of int_ needed (Larry Evans) 4. Re: [date_time] catalog.xml in CVS (Vladimir Prus) 5. Re: [mpl] value2type generalization of int_ needed (Larry Evans) 6. Re: Re: thoughts on a GUI component library (Dave Harris) 7. Re: smart_ptr and handles (Dirk Gregorius) 8. Re: addressof with Metrowerks and Boost Function/Signal (Douglas Gregor) 9. Re: Re: smart_ptr and handles (Jonathan Wakely) 10. Re: [date_time] catalog.xml in CVS (Jeff Garland) 11. Re: Re: Namespaces vs. directory placement (Peter Dimov) 12. Re: [date_time] catalog.xml in CVS (Vladimir Prus) 13. Re: Re: smart_ptr and handles (Peter Dimov) 14. Re: smart_ptr and handles (Dirk Gregorius) 15. Re: Re: [date_time] catalog.xml in CVS (Jeff Garland) 16. Re: Re: smart_ptr and handles (Jonathan Wakely) 17. Re: Re: Serialization and async messaging (Caleb Epstein) 18. Re: Re: smart_ptr and handles (Peter Dimov) 19. Re: Re: thoughts on a GUI component library (Marcelo E. Magallon) 20. Re: Re: [date_time] catalog.xml in CVS (Vladimir Prus) 21. Re: Re: [date_time] catalog.xml in CVS (Bart)
----------------------------------------------------------------------
Message: 1 Date: Wed, 29 Dec 2004 06:07:19 -0700 From: Larry Evans <cppljevans@cox-internet.com> Subject: [boost] [mpl] value2type generalization of int_ needed To: boost@lists.boost.org Message-ID: <cqu6mg$l97$1@sea.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
mpl has int_ which wraps an int value, but I've needed something similar for other types, in particular, for enumerated types. I'm suggesting something like:
//template to create a type from a value of some type. template < typename ValueType //type of value to be "typified"
struct value2type { typedef ValueType value_type ; template < value_type ValueInstance //value to be typified. > struct instance //the type created from ValueInstance {}; };
The name is modelled after In2Type in Alexandrescu's _Modern C++ Design_ which is also where the "typified" comes from.
Could this template, or something like it be added to mpl?
------------------------------
Message: 2 Date: Wed, 29 Dec 2004 13:33:55 +0100 From: Daniel Wallin <dalwan01@student.umu.se> Subject: [boost] Re: [mpl] value2type generalization of int_ needed To: boost@lists.boost.org Message-ID: <cqu87i$ojv$1@sea.gmane.org> Content-Type: text/plain; charset=ISO-8859-1
Larry Evans wrote:
mpl has int_ which wraps an int value, but I've needed something similar for other types, in particular, for enumerated types. I'm suggesting something like: [snip]
Could this template, or something like it be added to mpl?
What's wrong with mpl::integral_c<> ?
-- Daniel Wallin
------------------------------
Message: 3 Date: Wed, 29 Dec 2004 06:46:23 -0700 From: Larry Evans <cppljevans@cox-internet.com> Subject: [boost] Re: [mpl] value2type generalization of int_ needed To: boost@lists.boost.org Message-ID: <cqu8vn$qfh$1@sea.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12/29/2004 05:33 AM, Daniel Wallin wrote: [snip]
What's wrong with mpl::integral_c<> ? OOPS. I missed that. Thanks.
------------------------------
Message: 4 Date: Wed, 29 Dec 2004 16:00:12 +0300 From: Vladimir Prus <ghost@cs.msu.su> Subject: Re: [boost] [date_time] catalog.xml in CVS To: boost@lists.boost.org Message-ID: <200412291600.13740.ghost@cs.msu.su> Content-Type: text/plain; charset="iso-8859-1"
On Wednesday 29 December 2004 13:04, Vladimir Prus wrote:
Hi, the date_time, specifically the libs/date_time/xmldoc directory, includes the catalog.xml file:
And date_time_autodoc.boostbook/ and other *.boostbook files should not be in CVS, too.
- Volodya
------------------------------
Message: 5 Date: Wed, 29 Dec 2004 07:08:25 -0700 From: Larry Evans <cppljevans@cox-internet.com> Subject: [boost] Re: [mpl] value2type generalization of int_ needed To: boost@lists.boost.org Message-ID: <cqua92$tds$1@sea.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12/29/2004 06:46 AM, Larry Evans wrote:
On 12/29/2004 05:33 AM, Daniel Wallin wrote: [snip]
What's wrong with mpl::integral_c<> ?
OOPS. I missed that. Thanks.
I started to use it; however, in the particular application I have (located at http://boost-sandbox.sourceforge.net/vault/index.php? in placeholders_test.cpp), the T must be separate from the value. In other words instead of:
template<class T, T N> struct integral_c,
I need the N to be separate in order to use it as the a_index template argument to typemap_valued_placeholdered<,>::at<a_index>.
Can you see any other way?
TIA.
------------------------------
Message: 6 Date: Wed, 29 Dec 2004 13:40 +0000 (GMT) From: brangdon@cix.compulink.co.uk (Dave Harris) Subject: Re: [boost] Re: thoughts on a GUI component library To: boost@lists.boost.org Message-ID: <memo.192880@cix.compulink.co.uk>
In-Reply-To: <20041223171108.GB6938@maribor.izzy.net> alan-boost@engrm.com (Alan Gutierrez) wrote (abridged):
That's okay for simple things, but for any serious printing work you need to know you're talking to a printer. For example, you may need to embed postscript in your output stream.
I'd like to look at how OS X is able to make a PDF of everything.
I can think of two ways. First, the PDF can reflect what would be printed if the printer did not support postscript (which not all printers do). Second, PDF can itself contain embedded postscript.
-- Dave Harris, Nottingham, UK
------------------------------
Message: 7 Date: Wed, 29 Dec 2004 14:51:27 +0100 From: Dirk Gregorius <dirk@dirkgregorius.de> Subject: [boost] Re: smart_ptr and handles To: boost@lists.boost.org Message-ID: <41D2B65F.40506@dirkgregorius.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Thanks for your help and sorry for not looking carefully at the documentation:
I tried the following for a Windows device context:
The creation function is: HDC GetDC( HWND) The deletion function is: int ReleaseDC( HWND, HDC );
// Code like in the documentation... typedef shared_ptr<void> handle; handle make_dc( HWND hWnd ) { // The release function takes two arguments, so I tried an adapter functor...unfortunately it does not work handle( GetDC( hWnd ), bind1( ReleaseDC, hWnd ) ); }
My problem is to bind the window handle to the custom delete function. My compilter spits aout a lot of error messages here. Can I use boost::bind here or boost::function?
BTW: How does shared_ptr call the custom delete function? For a COM object it should call in the D'tor:
raw_ptr->Release();
While in my case it should call ( what is the usual way in the C++ standard IIRC ):
Release( raw_ptr );
Does the shard_ptr interface figures this out in some clever way and manage this internally?
Regards,
-Dirk
------------------------------
Message: 8 Date: Wed, 29 Dec 2004 09:01:44 -0500 From: Douglas Gregor <dgregor@cs.indiana.edu> Subject: Re: [boost] addressof with Metrowerks and Boost Function/Signal To: boost@lists.boost.org Message-ID: <2C25580F-59A2-11D9-AA59-000D932B7224@cs.indiana.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed
On Dec 26, 2004, at 11:15 AM, Reece Dunn wrote:
I am getting ambiguity errors on Metrowerks 9.2 when using Boost.Function and Boost.Signal. These errors can be corrected with the following patches:
Thanks! The patches are in CVS now.
Doug
------------------------------
Message: 9 Date: Wed, 29 Dec 2004 14:20:11 +0000 From: Jonathan Wakely <cow@compsoc.man.ac.uk> Subject: Re: [boost] Re: smart_ptr and handles To: boost@lists.boost.org Message-ID: <20041229142011.GA67252@compsoc.man.ac.uk> Content-Type: text/plain; charset=us-ascii
On Wed, Dec 29, 2004 at 02:51:27PM +0100, Dirk Gregorius wrote:
Thanks for your help and sorry for not looking carefully at the documentation:
I tried the following for a Windows device context:
The creation function is: HDC GetDC( HWND) The deletion function is: int ReleaseDC( HWND, HDC );
// Code like in the documentation... typedef shared_ptr<void> handle; handle make_dc( HWND hWnd ) { // The release function takes two arguments, so I tried an adapter functor...unfortunately it does not work handle( GetDC( hWnd ), bind1( ReleaseDC, hWnd ) ); }
Should that be bind, not bind1 ?
It's not hard to write your own deleter if you can't do it with a binder:
struct DCReleaser { DCReleaser(HWND hwnd) : hwnd(hwnd) {} void operator()(void* p) { ReleaseDC( hwnd, (HDC)p ); } HWND hwnd; };
handle make_dc( HWND hWnd ) { return handle( GetDC( hWnd ), DCReleaser(hWnd) ); }
but ...
My problem is to bind the window handle to the custom delete function. My compilter spits aout a lot of error messages here. Can I use boost::bind here or boost::function?
I think bind(ReleaseDC, hWnd, _1) should work.
BTW: How does shared_ptr call the custom delete function? For a COM object it should call in the D'tor:
raw_ptr->Release();
While in my case it should call ( what is the usual way in the C++ standard IIRC ):
Release( raw_ptr );
Does the shard_ptr interface figures this out in some clever way and manage this internally?
The custom deleter's function operator is called with the managed pointer as its argument, e.g. for a deleter d and pointer p: d(p)
jon
-- "Ye have locked yerselves up in cages of fear; and behold, do ye now complain that ye lack freedom." - Lord Omar Khayyam Ravenhurst "Epistle to the Paranoids," HBT
------------------------------
Message: 10 Date: Wed, 29 Dec 2004 07:21:42 -0700 From: "Jeff Garland" <jeff@crystalclearsoftware.com> Subject: Re: [boost] [date_time] catalog.xml in CVS To: boost@lists.boost.org Message-ID: <20041229142142.M12777@crystalclearsoftware.com> Content-Type: text/plain; charset=iso-8859-1
On Wed, 29 Dec 2004 16:00:12 +0300, Vladimir Prus wrote
On Wednesday 29 December 2004 13:04, Vladimir Prus wrote:
Hi, the date_time, specifically the libs/date_time/xmldoc directory, includes the catalog.xml file:
This is an internally used file, so it shouldn't cause errors - but perhaps an error has crept in? Are you seeing a problem when you try and generate the overall boost results? I noted before that for the 1.32 pdf date-time was excluded and no one explained why/how that happened since the html was clearly generated :-(
And date_time_autodoc.boostbook/ and other *.boostbook files should not be in CVS, too.
Yes, well, since we haven't been sucessful in getting all of the doxygen to boost-book bridge to work well for date-time we have to slightly modify the generated files for our purpose. So that's why those are there.
Jeff
------------------------------
Message: 11 Date: Wed, 29 Dec 2004 16:33:05 +0200 From: "Peter Dimov" <pdimov@mmltd.net> Subject: Re: [boost] Re: Namespaces vs. directory placement To: <boost@lists.boost.org> Message-ID: <003b01c4edb3$501ec820$6401a8c0@pdimov2> Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original
Jonathan Turkanis wrote:
The occurence of boost::io::put in the above example has to be qualified, since otherwise it will refer to the member function being defined.
What I have to say has nothing to do with namespaces or directory placement, but...
Given that in the documentation you speak of user-defined overloads of boost::io::read et al, it might be worthwhile to point out that two-phase lookup will not see these user overloads. If you want to have an overload customization point in a template, you have to use an unqualified call. And choose the identifiers wisely. :-)
------------------------------
Message: 12 Date: Wed, 29 Dec 2004 17:32:44 +0300 From: Vladimir Prus <ghost@cs.msu.su> Subject: [boost] Re: [date_time] catalog.xml in CVS To: boost@lists.boost.org Message-ID: <cquf6c$9ce$1@sea.gmane.org> Content-Type: text/plain; charset=us-ascii
Jeff Garland wrote:
On Wed, 29 Dec 2004 16:00:12 +0300, Vladimir Prus wrote
On Wednesday 29 December 2004 13:04, Vladimir Prus wrote:
Hi, the date_time, specifically the libs/date_time/xmldoc directory, includes the catalog.xml file:
This is an internally used file, so it shouldn't cause errors - but perhaps an error has crept in? Are you seeing a problem when you try and generate the overall boost results?
No, I see a problem when trying to build date_time docs.
I noted before that for the 1.32 pdf date-time was excluded and no one explained why/how that happened since the html was clearly generated :-(
I recall it was some kind of fop -> pdf convert bug, but I'm not sure.
And date_time_autodoc.boostbook/ and other *.boostbook files should not be in CVS, too.
Yes, well, since we haven't been sucessful in getting all of the doxygen to boost-book bridge to work well for date-time we have to slightly modify the generated files for our purpose. So that's why those are there.
You mean that each time after modifying headers, you have to manually tweak the generated files?
- Volodya
------------------------------
Message: 13 Date: Wed, 29 Dec 2004 16:44:22 +0200 From: "Peter Dimov" <pdimov@mmltd.net> Subject: Re: [boost] Re: smart_ptr and handles To: <boost@lists.boost.org> Message-ID: <007201c4edb4$e4173980$6401a8c0@pdimov2> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Jonathan Wakely wrote:
struct DCReleaser { DCReleaser(HWND hwnd) : hwnd(hwnd) {} void operator()(void* p) { ReleaseDC( hwnd, (HDC)p ); } HWND hwnd; };
handle make_dc( HWND hWnd ) { return handle( GetDC( hWnd ), DCReleaser(hWnd) ); }
Yep. Note also that shared_ptr will call the deleter with an HDC, not a void*, so the cast in operator() is not necessary:
void operator()(HDC p) const { ReleaseDC( hwnd, p ); }
I think bind(ReleaseDC, hWnd, _1) should work.
That's what I'd use, too. :-)
------------------------------
Message: 14 Date: Wed, 29 Dec 2004 15:51:21 +0100 From: Dirk Gregorius <dirk@dirkgregorius.de> Subject: [boost] Re: smart_ptr and handles To: boost@lists.boost.org Message-ID: <41D2C469.7030907@dirkgregorius.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Thanks - the custom functor works, but I don't understand why using boost::bind or std::bind1 fails:
Does anybody know why the compiler complains about this?
typedef shared_ptr<void> handle; handle make_dc( HWND hWnd ) { handle spHandle( GetDC( hWnd ), bind( &ReleaseDC, hWnd, _1 ) ); return handle; }
The compiler has problems with the return_value. I will attach the compiler output to the end of the mail. It is in german but you should get the idea anyway.
c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost 1.32\include\boost\bind.hpp(62) : error C2039: 'result_type': Ist kein Element von 'operator``global namespace''' c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost 1.32\include\boost\bind.hpp(62) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'type' c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost 1.32\include\boost\bind.hpp(62) : error C2955: 'boost::_bi::type': für die Verwendung einer Vorlagenklasse ist eine Vorlagen-Argumentliste erforderlich c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost 1.32\include\boost\bind.hpp(111): Siehe Deklaration von 'boost::_bi::type'
------------------------------
Message: 15 Date: Wed, 29 Dec 2004 07:58:38 -0700 From: "Jeff Garland" <jeff@crystalclearsoftware.com> Subject: Re: [boost] Re: [date_time] catalog.xml in CVS To: boost@lists.boost.org Message-ID: <20041229145838.M39611@crystalclearsoftware.com> Content-Type: text/plain; charset=iso-8859-1
On Wed, 29 Dec 2004 17:32:44 +0300, Vladimir Prus wrote
Jeff Garland wrote:
On Wed, 29 Dec 2004 16:00:12 +0300, Vladimir Prus wrote
On Wednesday 29 December 2004 13:04, Vladimir Prus wrote:
Hi, the date_time, specifically the libs/date_time/xmldoc directory, includes the catalog.xml file:
This is an internally used file, so it shouldn't cause errors - but perhaps an error has crept in? Are you seeing a problem when you try and generate the overall boost results?
No, I see a problem when trying to build date_time docs.
Maybe you can be more explicit about what you are doing and the errors you are seeing. BTW, we haven't been able to build docs for quite awhile now and our requests for help have gone unanswered on the boost-doc list. We weren't sure what magic was applied to do the 1.32 release.
I noted before that for the 1.32 pdf date-time was excluded and no one explained why/how that happened since the html was clearly generated :-(
I recall it was some kind of fop -> pdf convert bug, but I'm not sure.
Ok.
And date_time_autodoc.boostbook/ and other *.boostbook files should not be in CVS, too.
Yes, well, since we haven't been sucessful in getting all of the doxygen to boost-book bridge to work well for date-time we have to slightly modify the generated files for our purpose. So that's why those are there.
You mean that each time after modifying headers, you have to manually tweak the generated files?
That's correct -- although I think we actually use a script to do it. Sorry to say I've been hands-off of this for awhile so I don't know the details. Hopefully Bart will post later and describe the details.
Jeff
------------------------------
Message: 16 Date: Wed, 29 Dec 2004 15:06:41 +0000 From: Jonathan Wakely <cow@compsoc.man.ac.uk> Subject: Re: [boost] Re: smart_ptr and handles To: boost@lists.boost.org Message-ID: <20041229150641.GA70310@compsoc.man.ac.uk> Content-Type: text/plain; charset=us-ascii
On Wed, Dec 29, 2004 at 04:44:22PM +0200, Peter Dimov wrote:
Jonathan Wakely wrote:
struct DCReleaser { DCReleaser(HWND hwnd) : hwnd(hwnd) {} void operator()(void* p) { ReleaseDC( hwnd, (HDC)p ); } HWND hwnd; };
handle make_dc( HWND hWnd ) { return handle( GetDC( hWnd ), DCReleaser(hWnd) ); }
Yep. Note also that shared_ptr will call the deleter with an HDC, not a void*, so the cast in operator() is not necessary:
void operator()(HDC p) const { ReleaseDC( hwnd, p ); }
Yes, of course it will. Silly me. Thanks, Peter.
I think bind(ReleaseDC, hWnd, _1) should work.
That's what I'd use, too. :-)
Finally, Dirk, if you don't want to use shared_ptr<void> (and casts) everywhere you can include boost/type_traits.hpp and use remove_pointer:
typedef shared_ptr<remove_pointer<HDC>::type> dc_handle; typedef shared_ptr<remove_pointer<HWND>::type> wnd_handle;
jon
-- "It is unbecoming for young men to utter maxims." - Aristotle
------------------------------
Message: 17 Date: Wed, 29 Dec 2004 10:10:17 -0500 From: Caleb Epstein <caleb.epstein@gmail.com> Subject: Re: [boost] Re: Serialization and async messaging To: boost@lists.boost.org Message-ID: <989aceac04122907105ca21332@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII
On Wed, 29 Dec 2004 00:27:23 -0500, Jody Hagins <jody-boost-011304@atdesk.com> wrote:
I think Scott is saying that operator>> is insufficient because it can not do a partial read of what is there... it wants to snarf all 4K.
I think at least one person here is mixing pickles and milk, as my old Latin teacher used to say.
Firstly, the serialization library doesn't use operator>> or operator<< at all. If you're using these operators on some sort of socket iostream and you don't want blocking to occur, thats your first mistake.
When reading/writing data with sockets, its up to you to use an appropriate protocol that can detect "message" boundaries so you know when you have a complete block of data to work with. See for example the BEEP protocol (http://beepcore.org/) for a nice specification and implementation.
Don't tightly couple this communications layer to the application layer. The two layers should just pass "complete" blocks of data (e.g. serialized objects) between each other. -- Caleb Epstein caleb dot epstein at gmail dot com
------------------------------
Message: 18 Date: Wed, 29 Dec 2004 17:21:48 +0200 From: "Peter Dimov" <pdimov@mmltd.net> Subject: Re: [boost] Re: smart_ptr and handles To: <boost@lists.boost.org> Message-ID: <000b01c4edba$204131e0$6401a8c0@pdimov2> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Dirk Gregorius wrote:
Thanks - the custom functor works, but I don't understand why using boost::bind or std::bind1 fails:
Does anybody know why the compiler complains about this?
typedef shared_ptr<void> handle; handle make_dc( HWND hWnd ) { handle spHandle( GetDC( hWnd ), bind( &ReleaseDC, hWnd, _1 ) ); return handle; }
The problem is that ReleaseDC uses the __stdcall calling convention:
http://boost.org/libs/bind/bind.html#Q_win32_api
#define BOOST_BIND_ENABLE_STDCALL to turn on __stdcall support (and change "return handle" to "return spHandle").
------------------------------
Message: 19 Date: Wed, 29 Dec 2004 09:08:21 -0600 From: "Marcelo E. Magallon" <mmagallo@debian.org> Subject: Re: [boost] Re: thoughts on a GUI component library To: boost@lists.boost.org Message-ID: <20041229150821.GA7250@jacinta.casa> Content-Type: text/plain; charset=us-ascii
On Tue, Dec 28, 2004 at 05:28:15PM -0500, Alan Gutierrez wrote:
That's easy: you start with a vector description of *everything* and plug a rasterizer where needed. This vector description in Quartz is called DPS: Display PostScript.
This gives you the gimmicks you see on MacOS X, for example window minimization and maximization effects. You just need to start with a rectangle, and subdivide the edges, and apply some transformation to them. Then you can use algebraic grid generation to compute the inner grid. And now you only need to apply the grid transformation to the elements of the window.
So where can I learn about algebraic grid generation?
I'm not at the office now, I'll write this down and mail you a couple of references next week. I think they could be useful for getting you started if you have interest in the topic. It's nothing more than just careful interpolation.
I understand what you are saying architecure wise. Do you really feel that it is easy? Could it be cross-platform? I'm of a mind that you start with rendering soultions, rather than widgets.
It's conceptually easy.
The basic idea is that you need some sort of abstraction to display hardware, nothing new there. If you orient this abstraction towards raster devices like the screen, you basically tie both of your hands behind your back when it comes to dealing with significantly different devices like a printer or a text-based UI.
If you start with vector graphics, rendering to the screen is easy, it's "just" rasterization (ok, it's full of pesky details, but that's a different thing). Rendering to a printer is either transforming your vector description to the printer's vector description (PostScript, ...) or rasterizing at a given resolution.
There's still nothing new there.
You could implement OS X's gimmicks on top of X11 or GDI, with some amount of pain involved. The problem is neither is particularly good at working with affine transformations or texture application or alpha blending or shading. Here's where Quartz shines. This is also what Cairo Graphics is trying to be.
Could this be cross platform? It depends on what you mean by that.
Would something like this work across platforms? Sure, why not?
Would something like this work across platforms if you want to use the native widgets? Probably not.
And yes, I tend to think about the rendering part of the problem because that's what I do and that's what interests me. It's also one of the spots that hinders portability: don't take it too far, think of something as simple as fonts. I would also like to see a nice event loop system (because that's one wheel I've reinvented many times already and I don't feel I've gotten it right yet), so if you start discussing that (from the Boost POV) I will pay closer attention :-)
I my opinion GTK+ has got the whole UI thing right (or "as right as it can get"). They have clear boundaries between different parts of the system: rendering (with GDK as an abstraction on top of X11 and others), widgets (GTK+ itself), accessibility (ATK), text handling and rendering (Pango), themability. Where GTK+ sucks at is extensibility: it's a pain to write new widgets. The whole signaling business in GTK+ is also awkward to say the least. GTKmm is an improvement over GTK+, but there are some corners which still feel somewhat "wrong" (perhaps because GTK+ is "still underneath")
On the other hand I think Qt got and still gets the whole thing wrong. (That and the fact that they reinvented wheels that didn't need reinventing in the first place).
I'm getting way off-topic...
Marcelo
------------------------------
Message: 20 Date: Wed, 29 Dec 2004 18:27:52 +0300 From: Vladimir Prus <ghost@cs.msu.su> Subject: [boost] Re: Re: [date_time] catalog.xml in CVS To: boost@lists.boost.org Message-ID: <cquido$hhj$1@sea.gmane.org> Content-Type: text/plain; charset=us-ascii
Jeff Garland wrote:
On Wed, 29 Dec 2004 17:32:44 +0300, Vladimir Prus wrote
Jeff Garland wrote:
On Wed, 29 Dec 2004 16:00:12 +0300, Vladimir Prus wrote
On Wednesday 29 December 2004 13:04, Vladimir Prus wrote:
Hi, the date_time, specifically the libs/date_time/xmldoc directory, includes the catalog.xml file:
This is an internally used file, so it shouldn't cause errors - but perhaps an error has crept in? Are you seeing a problem when you try and generate the overall boost results?
No, I see a problem when trying to build date_time docs.
Maybe you can be more explicit about what you are doing and the errors you are seeing.
Sure. 1. I have up-to-date CVS tree. 2. I run "bjam --v2" in libs/date_time/xmldocs and get:
xslt-xsltproc bin/gcc/debug/date_time.docbook ../../../tools/boostbook/dtd/boostbook.dtd:412: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" %DocBook; ^ Entity: line 1: (many screens of similar errors omitted). 3. I remove catalog.xml and run bjam again. Everything works.
BTW, we haven't been able to build docs for quite awhile now
I know it was broken for about a week (because I broke it), but it should be working now.
and our requests for help have gone unanswered on the boost-doc list. We weren't sure what magic was applied to do the 1.32 release.
I'm not sure what problems you refer too, sorry.
And date_time_autodoc.boostbook/ and other *.boostbook files should not be in CVS, too.
Yes, well, since we haven't been sucessful in getting all of the doxygen to boost-book bridge to work well for date-time we have to slightly modify the generated files for our purpose. So that's why those are there.
You mean that each time after modifying headers, you have to manually tweak the generated files?
That's correct -- although I think we actually use a script to do it. Sorry to say I've been hands-off of this for awhile so I don't know the details. Hopefully Bart will post later and describe the details.
Ok.
- Volodya
------------------------------
Message: 21 Date: Wed, 29 Dec 2004 08:59:15 -0700 From: Bart <bartmann_nsd@yahoo.com> Subject: [boost] Re: Re: [date_time] catalog.xml in CVS To: boost@lists.boost.org Message-ID: <pan.2004.12.29.15.59.12.221317@yahoo.com> Content-Type: text/plain; charset=ISO-8859-1
On Wed, 29 Dec 2004 07:58:38 -0700, Jeff Garland wrote:
On Wed, 29 Dec 2004 17:32:44 +0300, Vladimir Prus wrote
Jeff Garland wrote:
On Wed, 29 Dec 2004 16:00:12 +0300, Vladimir Prus wrote
On Wednesday 29 December 2004 13:04, Vladimir Prus wrote:
Hi, the date_time, specifically the libs/date_time/xmldoc directory, includes the catalog.xml file:
This is an internally used file, so it shouldn't cause errors - but perhaps an error has crept in? Are you seeing a problem when you try and generate the overall boost results?
No, I see a problem when trying to build date_time docs.
Maybe you can be more explicit about what you are doing and the errors you are seeing. BTW, we haven't been able to build docs for quite awhile now and our requests for help have gone unanswered on the boost-doc list. We weren't sure what magic was applied to do the 1.32 release.
I noted before that for the 1.32 pdf date-time was excluded and no one explained why/how that happened since the html was clearly generated :-(
I recall it was some kind of fop -> pdf convert bug, but I'm not sure.
Ok.
And date_time_autodoc.boostbook/ and other *.boostbook files should not be in CVS, too.
Yes, well, since we haven't been sucessful in getting all of the doxygen to boost-book bridge to work well for date-time we have to slightly modify the generated files for our purpose. So that's why those are there.
You mean that each time after modifying headers, you have to manually tweak the generated files?
That's correct -- although I think we actually use a script to do it. Sorry to say I've been hands-off of this for awhile so I don't know the details. Hopefully Bart will post later and describe the details.
Jeff
We wanted the doxygen created reference to have three sections: date_time, gregorian, & posix_time with a fourth to be added later (local_time). Boostbook generated a boostbook file for each section, however, all three boostbook files had the same section and title tags. Our script rewrites those tags and adds a copyright notice.
It's a bit of extra work but we have a nicely nested set of reference docs as a result.
Building the docs from anywhere other than boost_root/libs/date_time/xmldoc will not produce the boostbook files but simply uses them.
Bart
------------------------------
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
End of Boost Digest, Vol 956, Issue 2 *************************************