- Boost - lists.preview.boost.org

Re: [boost] Proposal: Monotonic Containers: Performance test
by Christian Schladetsch 11 Jun '09

11 Jun '09

void test_speed() { typedef monotonic::map<int, monotonic::list<int> > map_with_list; monotonic::inline_storage<1000000> storage; map_with_list m(storage); size_t count = 10000; boost::timer timer; for (size_t i = 0; i < count; ++i) { int random = rand(); map_with_list::iterator iter = m.find(random); if (iter == m.end()) m.insert(make_pair(random, monotonic::list<int>(storage))); else iter->second.push_back(i); } double elapsed = timer.elapsed(); cout << "monotonic: " << elapsed << endl; // do the same thing, with std::containers { typedef std::map<int, std::list<int> > map_with_list; map_with_list m; for (size_t i = 0; i < count; ++i) { int random = rand(); map_with_list::iterator iter = m.find(random); if (iter == m.end()) m[random] = std::list<int>(); else iter->second.push_back(i); } double elapsed = timer.elapsed(); cout << "std: " << elapsed << endl; } } monotonic: 0.005 std: 0.09

4 5

bug-sprint #2114, 2 comments
by Alexander Arhipenko 11 Jun '09

11 Jun '09

I have 2 major comment on the updated patch. Consider following snippet from gcc.hpp: #if __GNUC__ >= 4 && !defined(__MINGW32__) && !defined(__CYGWIN__) # define BOOST_SYMBOL_EXPORT __attribute__((visibility("default"))) # define BOOST_SYMBOL_HIDE __attribute__((visibility("hidden"))) # define BOOST_SYMBOL_IMPORT BOOST_SYMBOL_EXPORT ...And assume following scenario: Someone is writing shared library (let's name it foo) with 'visilibility=hidden' option. Library foo is using e.g. boost_filesystem. In this case, all the symbols marked with BOOST_FILESYSTEM_DECL will be exported from foo library. This could easily break foo library's ABI (in case of migration to the newest boost version etc.), so BOOST_SYMBOL_IMPORT should be defined for gcc as empty macro: # define BOOST_SYMBOL_IMPORT. The second comment: BOOST_EXCEPTION_EXPORT/IMPORT are intended for re-exporting exceptions from shared library. So, they should be defined for gcc as: # define BOOST_EXCEPTION_EXPORT BOOST_SYMBOL_EXPORT # define BOOST_EXCEPTION_IMPORT BOOST_SYMBOL_EXPORT and not as: # define BOOST_EXCEPTION_EXPORT BOOST_SYMBOL_EXPORT # define BOOST_EXCEPTION_IMPORT BOOST_SYMBOL_IMPORT Note: for the current patch version this part works as expected, since BOOST_SYMBOL_EXPORT == BOOST_SYMBOL_IMPORT for gcc. See also this thread (search for exception): http://lists.boost.org/Archives/boost/2008/12/146068.php Regards

4 8

[candidate bloom_filter] Default Sequence
by JOAQUIN M. LOPEZ MUÑOZ 11 Jun '09

11 Jun '09

Currently, the default Sequence template arg is class Sequence = fusion::vector< detail::default_hash<0>, detail::default_hash<1>, detail::default_hash<2> > which implies the default K is 3. I propose to generalize this a bit so that we have something like template<typename K> default_hash_sequence...; such that default_hash_sequence<K> is the fusion sequence default_hash<0>,...,default_hash<K-1> (I don't know Fusion but I'm sure this can be done) and then put class Sequence = default_hash_sequence<3> So, a user can easily set bloom_filter<foo,default_hash_sequence<K> > with a K other than 3. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Proposal: Monotonic Containers
by joaquin＠tid.es 10 Jun '09

10 Jun '09

Stewart, Robert escribió: > joaquin(a)tid.es wrote: > On Tuesday, June 09, 2009 9:34 AM > >> Stewart, Robert escribió: >> >>> There's a problem with using an allocator for the node based >>> containers: they use the allocator to allocate the elements >>> but not the nodes. That implies free store (de)allocations >>> for the nodes which is contrary to the intended purpose of >>> this proposal. >>> >> Umm, I beg to differ. If we have a node-based container >> >> xxx<T,...,custom_allocator<T> > >> >> and node<T> is the internal node type, the container is required >> to do the allocation using an allocator of type >> >> custom_allocator<T>::rebind<node<T> >::other. >> >> The container is not allowed to do any kind of allocation using >> other means than the custom_allocator<X> family of allocators. >> > > If custom_allocator<node<T> > is not specialized to do the same as > custom_allocator<T>, or to use the same memory pool, then it > doesn't fit the proposal. Point conceded, but how would you do otherwise? Specifying a custom allocator is your only way to affect the container's allocation behavior. Seems like you're implying that the container wrapping approach is in some way more powerful than directly specifying the custom allocator, which is not. Your only chance to solve the problem you mention is to make custom_allocator<node_type<T> > use the same memory pool. There's a way to do this. If you construct the container with custom_allocator<T> a; xxx<T,...,custom_allocator<T> > x(a); then xxx will use an object of type custom_allocator<node<T> > for its allocation needs, which perforce will be an object differnt to the allocator a you've passed; but the container is required to construct this internal allocator as a copy of a: // inside xxx implementation custom_allocator<node<T> > internal_a(a); So you can use this knowledge to pass info around, for instance on the memory pool to be used. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

10 26

first review submission of timer_queue.zip
by JohnQ 10 Jun '09

10 Jun '09

Hi, Thanks for pointing me to the submission requirements page... I just uploaded timer_queue.zip to boost vault for first review. Haven't got everything shipshape yet but I'm hoping I've satisfied enough of the requirements so I can start getting some feedback on functionality. If not, let me know so I can rework and resubmit. In essence, timer_queue is a library for creating timers that fire at some arbitrary time in the future and hand you back a void* that you provided when you created the timer. Timers can be deleted before they fire by providing an id (can be non-unique) when you create a timer that can be used to delete particular sets of timers later on. Thanks to any who take the time to review this and help me make it better. John Q.

2 1

[mpl]iter_fold_if Forward Backward rationale?
by Larry Evans 10 Jun '09

10 Jun '09

Why is there both a ForwardOp and BackwardOp template argument to iter_fold_if? https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp#L… I would have thought that only 1 was needed. Since iter_fold_if is not documented here: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/refmanual_toc.h… I assume it's not meant to be used by the user, but is only an implementation detail; however, it, or a variation, might be useful to implement the and_seq mentioned here: http://article.gmane.org/gmane.comp.lib.boost.devel/186204 As shown in that post, the template, while_if_then was used, and it does not require anything like both a ForwardOp and BackwardOp, it just requires the If and Then unary metafunctions. One problem I encountered with while_if_then was moving to the end of the sequence, at which time the Then metafunction couldn't be called; hence, I had to make it lazy to avoid dereferencing the end iterator. Is that somehow related to the need for BackwardOp in iter_fold_if. IOW, because iter_fold_if might reach the end iterator, it has to backup? I'm really asking because in the variadic template version of mpl, I wondering if iter_fold_if could be replaced with something like while_if_then (which may be renamed fold_if to be more consistent with other names with similar function). Any insight about the rationale for the iter_fold_if would probably save me considerable time in deciding whether it can be replaced with the proposed fold_if. -regards, Larry

3 28

[filesytem][1.39.0] basic_path::clear mia?
by Jeff Flinn 10 Jun '09

10 Jun '09

http://www.boost.org/doc/libs/1_39_0/libs/filesystem/doc/reference.html#bas… lists void clear(); as an available modifier on basic_path. Neither I nor MSVC8 seem to be able to find it. Am I doing something wrong? Thanks, Jeff

1 0

Re: [boost] Proposal: Monotonic Containers
by Artyom 10 Jun '09

10 Jun '09

> The space has already been created before the allocator is > requested to > provide for new storage. > > Otherwise, we could never use a vector<char> on a > machine that requires > 16-byte alignment. > This is not correct. Allocators allocate memory as single chunk. So, if you use vector<char> that has size of 10 characters, it would allocate a single chunk of at least 10 bytes, and it's beginning would be aligned to 8 or 16. So if you for example, allocate 3 charrecters that start at 0x100 to 0x102, and then you would try to allocate single integer you need to return pointer with value 0x104, 0x108 or 0x110-- aligned to 4, 8 or 16 according to architecture requirements, if you would return 0x103 it may cause illegal operation on some architectures like ARM, hundreds cycles cost on architectures like IA64 and fault in execution of atomic operations like in shared_ptr. You **must** return aligned pointers from allocators. Artyom

3 4

Re: [boost] [multi_array] Negative strides
by pete＠pcbartlett.com 10 Jun '09

10 Jun '09

>John Reid <j.reid(a)mail.cryst.bbk.ac.uk> wrote:John Reid wrote: >> Either the library was designed with negative strides in mind and it is >> just the assertions that are stopping me using them or they were never >> part of the original spec and are not safe to use. In either case I >> can't find them mentioned in the documentation. Could the owner of the >> library clear this up? >Do libraries have owners? Posts on boost.multi_array don't seem to >provoke many responses. Nearly all libraries have owners (see e.g. http://gitorious.org/boost/svn/blobs/master/libs/maintainers.txt ). There is considerable variation in how closely each owner is monitoring this list. Pete

1 0

Re: [boost] [Christian S] Spirit and ANTLR - Request for example
by Christophe Henry 10 Jun '09

10 Jun '09

> brought an idea to boost and had it shot down [...] I quite agree with Luke's explanation and while Christian's behaviour is not perfect, I'd like to point out that bringing a new idea to boost for the first time is a stressful experience, as I myself remember full well. And having his idea immediately shot down is even less nice (as I also remember full well). It seems to happen quite sometimes that people coming with new ideas are met with (unconsciously) not so friendly behaviour. Perhaps we should think about the way new people are met if we don't want to end as a closed (and thus condemned) community... And in the same time, maybe Christian could take a short break and we could all try to restart on a better basis. I therefore offer to close this thread for now as it clearly brings nothing but spam in our mailboxes. If Christian comes up later with interesting examples, we would all profit from them. Regards, Christophe

2 1

Re: [boost] Proposal: Monotonic Containers
by Artyom 10 Jun '09

10 Jun '09

Hi, Several notes: 1st... This code does not compile with gcc-4.3 (mingw) a) Fix: map.h/set.h --> - set(Predicate P, Allocator const &A) - : Set(P, A) + set(Predicate Pr, Allocator const &A) + : Set(Pr, A) because it shadows template parameter P. b) Fix in ./boost/monotonic/storage_base.h Add #include <boost/cstdint.hpp> 2nd... Never use: #pragma once not portable 3rd... Your allocator is not correct you do not align the pointers as required by most of architectures. You need to provide 8-16 bytes alignment... According to system 4th... Why don't you use boost::pool? It is debugged and tested instead of writing new implementation? 5th... Implement ALL constructors of each container. For example I can call. std::string str="Foo"; std::vector<int> v(str.begin(),str.end()); this is not supported 6th... This is bad idea to derive from std containers. They to do not provide virtual destructors. This may be very error prone. This is just short glance. Artyom --- On Tue, 6/9/09, Christian Schladetsch <christian.schladetsch(a)gmail.com> wrote: > From: Christian Schladetsch <christian.schladetsch(a)gmail.com> > Subject: Re: [boost] Proposal: Monotonic Containers > To: boost(a)lists.boost.org > Date: Tuesday, June 9, 2009, 3:06 PM > Hello, > > That is not what I asked for. I wanted online docs and > code. We are very > >> busy people, and anything that takes extra time is > likely to mean we don't > >> bother. > > > > > OK well on second thought, what? > > I am also busy. > > I gave you a link to code and documentation in the one > archive. > http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Monoto… > > Click on the link, get the code and the documentation. > Sorry that you have > to click into the archive twice, but boost doesn't have a > better way of > doing it ATM that I am aware of. > > Chrstian. > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 2

Re: [boost] identifying a string type
by Steven Ross 10 Jun '09

10 Jun '09

Is there a boolean argument that can be used to identify whether a data type is some form of string that has a [] operator that returns an integer data type (preferably 2 or less bytes in size)? I now am using enable_if so that strings and floats are identified and the proper specialized call is made for them when spread_sort is called by the user. It would be nice to automatically identify strings too inside enable_if, so that the user can just call "spread_sort" and the correct specialized and optimized sorting call will be made depending on the data type for integers, floats, and strings, and std::sort will be called for unsupported data types.

5 7

Proposal: Extended Allocators (was Montonic Containers)
by Christopher Jefferson 10 Jun '09

10 Jun '09

It is my belief (but I'm happy to shown wrong) that the idea of 'Monotonic Containers' to provide a new allocator for vector to support a small block of memory is fundamentally not going to work, due to 2 limitations of allocators: 1) There is no support for in-line expansion (effectively, realloc which doesn't move if it can't realloc) 2) There is no support for an allocator to say "No, you can't have X memory, but I could give you Y", so it's hard to "exactly fill" a limited memory buffer. I have been working around this by implementing new special containers, which know about the size of a fixed buffer and therefore can make use of the space. I now think I'm probably going about this the wrong way, a much better way would be to implement: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html , or a variant thereof. The big problem with doing this "within boost" is that it would pull in a basically complete implementation of std::allocator and the containers into boost. In an ideal world, such a small and in my opinion useful extension would have been added to C++0x, but it's far too late for that now. tl;dr : Seeing as we are having a "what would boost accept" couple of days, would adding an (extended) implementation of a substantial part of the standard library be acceptable, or would I be better off trying to get this picked up by one of the existing standard libraries to pick this up (my worry being they may not want, quite sensibly, want to accept code which is not standardised). Chris

3 2

boost::directx?
by Christian Schladetsch 09 Jun '09

09 Jun '09

Hello, Is there a possibility of making submissions that use meta-C++ to assist with writing DirectX-based code? Obviously, DirectX is Microsoft-specific (but not necessarily platform specific!). So my question comes down to "is there a space in boost for MS-specific systems"? Perhaps in boost::microsoft or boost::directx or boost::microsoft::directx. I have a number of systems that are generally useful, and would like to support the use of boost in game development. It is hard enough to get gamedevs to use STL, let alone boost. But for example, creating vertex declarations is a royal PITA and can be assisted with some deft use of boost::mpl. Plus, we are already using boost::shared_ptr<> to make com_ptr<>, but it could be made more obvious and a lot of people don't know how to use it. There are two ways of looking at it. First, boost is about C++ and not about supporting specific API's. Fair enough - but then there are many boost libraries that use system-specific idioms such as threads and lock-free containers. It could be argued that boost doesn't want to tie itself to a proprietary API which itself will be versioned and modified externally to boost, but the same is already true in a lot of what boost does. Another way of looking at it is that boost is here to be used by real people solving real problems. In this case, it seems that there is room within a new namespace for domain-specific boost libraries. I realise this is a can of worms. What do you think? Should boost be more egalitarian and increase its possible audiance, or is introducing a dependancy on a 3rd party proprietary API an anathema to boost? Regards, Christian. ----- http://www.linkedin.com/in/christianschladetsch

13 40

[Christian S] Spirit and ANTLR - Request for example
by John Phillips 09 Jun '09

09 Jun '09

Christian, Inside the directx thread you asserted that there are things that ANTLR can do and Spirit can't. This met with some resistance, but I would like to take a different approach. Please post a working code example, along with rationale for why you want to do it, that shows something ANTLR can do, but Spirit can't. The goal is to move this out of the land of unsupported allegations, and into specific examples that can promote specific responses. My experience of Joel and Hartmut suggests that if you have any such real examples, they will use them as a basis for improving Spirit, a process which benefits everyone. If you display examples, and Hartmut and Joel (or anyone else) respond by providing working examples of how Spirit does that, too, then better information is propagated on the list, and again everyone benefits. In general, this is a better way to critique by comparison. Provide actual working code for the comparison, and there is far less room for misinterpretation of intent or conclusions. John

14 27

Borland tests
by Robert Ramey 09 Jun '09

09 Jun '09

The serialization library fails to build on the latest borland compiler with the error message quoted below. This suggests to me that some changes might be in order for config/borland and/or perhaps iterator_facade.hpp Robert Ramey "C:/BuildAgent/work/e5a72339587b6bb4/cb2009_3/bin/bcc32" -j5 -g255 -q -c -P -Ve -Vx -a8 -b- -v -Od -IC:\BuildAgent\work\e5a72339587b6bb4\spirit -tWC -tWR -tWC -tWD -WM- -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -I".." -I"C:/BuildAgent/work/e5a72339587b6bb4/cb2009_3/include/" -o"C:\BuildAgent\work\e5a72339587b6bb4\results\boost\bin.v2\libs\serialization\build\borland-6.1.3\debug\basic_text_wiprimitive.obj" "..\libs\serialization\src\basic_text_wiprimitive.cpp" ..\libs\serialization\src\basic_text_wiprimitive.cpp: Unknown compiler version - please run the configure tests and report the results Error E2061 ..\boost/iterator/iterator_facade.hpp 484: Friends must be functions or classes Error E2139 ..\boost/iterator/iterator_facade.hpp 484: Declaration missing ; Error E2061 ..\boost/iterator/iterator_facade.hpp 485: Friends must be functions or classes Error E2139 ..\boost/iterator/iterator_facade.hpp 485: Declaration missing ; Error E2061 ..\boost/iterator/iterator_facade.hpp 487: Friends must be functions or classes Error E2228 ..\boost/iterator/iterator_facade.hpp 487: Too many error or warning messages *** 6 errors in Compile ***

3 4

Re: [boost] Proposal: Monotonic Containers
by joaquin＠tid.es 09 Jun '09

09 Jun '09

Stewart, Robert escribió: > Andrew Sutton wrote: > On Tuesday, June 09, 2009 9:07 AM > >>> People will expect that a monotonic::foo<..> is like a >>> foo<..>, and they will accept that it requires a storage >>> argument. But they will find it harder to accept that it >>> requires retooling from a type-argument level of the >>> allocator. >>> >> Why incur the overhead of expectation, when foo<T, >> monotonic::allocator<T>> gives you exactly what you want? >> > > There's a problem with using an allocator for the node based containers: they > use the allocator to allocate the elements but not the nodes. That implies > free store (de)allocations for the nodes which is contrary to the intended > purpose of this proposal. > Umm, I beg to differ. If we have a node-based container xxx<T,...,custom_allocator<T> > and node<T> is the internal node type, the container is required to do the allocation using an allocator of type custom_allocator<T>::rebind<node<T> >::other. The container is not allowed to do any kind of allocation using other means than the custom_allocator<X> family of allocators. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

[program options] why is ->multitoken() not default for vector arguments?
by Thorsten Ottosen 09 Jun '09

09 Jun '09

Hi, I have code like bpo::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("file", bpo::value<std::string>(), ".sug file with graph description") ("new_edge", bpo::value<std::vector<unsigned>>()->multitoken(), "two numbers denoting the new edge"); I had to add the ->multitoken to make a command like ./clique_tester.exe --new_edge 1 2 --file bug1.sug ^^^^^^^^ work. This seems wierd. Why would I want a vector of values, yet only parse one of the trailing argument? Thanks -Thorsten

2 5

[ublas] Fwd: Undelivered Mail Returned to Sender
by Maik Beckmann 09 Jun '09

09 Jun '09

Something seems to be wrong with the ublas mailing list setup. This isn't the first time I get a "Undelivered Mail" response. Posting to boost@ and boost- users@ works fine. -- Maik

2 1

gcc visibility support
by Vladimir Prus 09 Jun '09

09 Jun '09

Over in issue 2114 (https://svn.boost.org/trac/boost/ticket/2114) Jürgen has provided a patch to add gcc visiblity support to all separately compiled libraries. gcc visibility is a mechanism similar to dllexport on Windows, with the same benefits. I have tried to apply it, and rebuild program_options. The the size of release shared library went from 272K down to 224K. The number of relocations went from 972 to 872. Both changes seem to be good. It seems to be unlikely to get the authors of every compiled library to look at the patch, so it looks like an alternative approach is necessary. Does anybody have any objections to this approach? If not, I'll check this in somewhere before Jule 15 deadline, and will take care of checking regression results afterwards. - Volodya

5 6

[website] adding Google analytics reports to boost.org
by joaquin＠tid.es 09 Jun '09

09 Jun '09

After reading about Volodya's insertion of a GA tracker for Boost.Build docs, I wonder whether it'd make sense to add one of these to the boost.org website itself. Some of the data we could gather, like for instance the geographical distribution of visitors, can be very illuminating. There are two problems at first sight with this: * Whose the reports' associated Google account should be? * How to make the data public? This is not technically trivial, but maybe some volunteer would like to do the job of extracting the data via the Google Analytics Data Export API: http://www.techcrunch.com/2009/05/22/make-your-google-analytics-data-public/ Thank you, Joaquín M López Muñoz Telefónica, Inevstigación y Desarrollo

6 6

ublas
by boost＠cyberfiber.org 09 Jun '09

09 Jun '09

hoped you could include this in the upcoming release best regards, michael

2 4

Re: [boost] boost::directx?
by Artyom 08 Jun '09

08 Jun '09

Hi, DirectX can't be relevant because it is not cross platform API. I may think of OpenGL but not DX. > Make this some kind of boost::graphics, target both dx > and ogl or w/e in a > seamless fashion, then you have something worthy. Artyom

12 32

boost/checked_delete.hpp
by mbiddeg＠mtn.co.ug 08 Jun '09

08 Jun '09

Hi Guys. I need serious help here, though this is child's play for you all. >From boost/checked_delete.hpp (attached), template<class T> inline void checked_delete(T * x) { // intentionally complex - simplification causes regressions typedef char type_must_be_complete[ sizeof(T)? 1: -1 ]; (void) sizeof(type_must_be_complete); delete x; } template<class T> inline void checked_array_delete(T * x) { typedef char type_must_be_complete[ sizeof(T)? 1: -1 ]; (void) sizeof(type_must_be_complete); delete [] x; } * What's the result of applying sizeof to an incomplete type? * Why is sizeof called twice? * Why is the result of sizeof cast to void? What exactly does that line do? * Is it an empty statement if the sizeof is legal? * Why not apply x = 0; at the end? This code is not too clear to me & the boost documentation is not either. Please assist. Please do not direct me to the C++ standard text. Then again, smart pointers are simple to understand & use, but their implementations are all rather difficult to understand (maybe except scoped_ptr). Which brings me to one more question, why wasn't Andrei's technique of Smart_Ptr (Loki) chosen over the boost implementation technique (a class per smart pointer) for C++ 0x? His allows for an innumerable number of extension through policies. I ask this purely to understand why, not as a rejoinder. Awaiting your feedback. Thank you. Nice day. ______________________________________________________________________ Kizza George Mbidde Interconnect Billing Systems Analyst IT cell: +256 77 221 2982 email: mbiddeg(a)mtn.co.ug [cid:image001.gif@01C9E853.125FFD20]

3 3

Bug Sprint Final Report
by Marshall Clow 08 Jun '09

08 Jun '09

The boost bug sprint started Friday, May 29th, and ended Sunday June 7th. Thank you to everyone who participated! Just because the bug sprint is over, that doesn't mean you can't fix bugs! ;-) Here's a day by day status: Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. 6:00 AM PDT 6/4: 739 open tickets. 8:00 AM PDT 6/5: 730 open tickets. 7:00 AM PDT 6/6: 719 open tickets. 7:00 AM PDT 6/7: 706 open tickets. 7:00 AM PDT 6/8: 710 open tickets (oops!) Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. 6/3: 4 new tickets, 19 modifications, 2 tickets closed. 6/4: 3 new tickets, 42 modifications, 24 tickets closed. 6/5: 3 new tickets, 35 modifications, 8 tickets closed. 6/6: 4 new tickets, 61 modifications, 29 tickets closed. 6/7: 1 new ticket, 20 modifications, 4 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

3 2