Since Richard is in favor and Nathaniel hasn't said anything, I went
ahead and landed the PCRE branch. It's my hope that this has no
visible effects at all, beyond not needing boost.regex anymore; let me
know if there are problems. I updated the Debian dependencies; it
does not appear that the
On Wed, Oct 10, 2007 at 12:06:28AM -0700, Zack Weinberg wrote:
Since Richard is in favor and Nathaniel hasn't said anything, I went
ahead and landed the PCRE branch.
Yay!
My impression is that, while external Boost libraries are now not
needed, to get the header-only libraries that we still
On Wed, Oct 10, 2007 at 05:13:48PM +1000, Daniel Carosone wrote:
So, I'm assuming we should now be able to get away with a dep on just
boost-headers, which will save a chunk of space and time. Thankyou.
Well, time at least, if space not so much after all...
[EMAIL PROTECTED]
On 10/10/07, Daniel Carosone [EMAIL PROTECTED] wrote:
My impression is that, while external Boost libraries are now not
needed, to get the header-only libraries that we still use, people
building from source will still have to go through the trouble of
building the whole of Boost.
Zack Weinberg schrieb:
$ bcp --list --scan --boost=/usr/include *.cc *.hh | grep '^boost/' | wc -l
1271
Individual Boost headers (I checked format.hpp and shared_ptr.hpp)
seem to expand to about 300 sub-headers a pop, with not much overlap.
Are there still objections against including those
In message [EMAIL PROTECTED] on Wed, 10 Oct 2007 09:17:03 +0200, Thomas
Keller [EMAIL PROTECTED] said:
me Zack Weinberg schrieb:
me $ bcp --list --scan --boost=/usr/include *.cc *.hh | grep '^boost/' | wc
-l
me 1271
me
me Individual Boost headers (I checked format.hpp and shared_ptr.hpp)
In message [EMAIL PROTECTED] on Wed, 10 Oct 2007 00:06:28 -0700, Zack
Weinberg [EMAIL PROTECTED] said:
zackw Since Richard is in favor and Nathaniel hasn't said anything, I went
zackw ahead and landed the PCRE branch. It's my hope that this has no
zackw visible effects at all, beyond not
A make check on h:n.v.m currently results in one failed test:
syntax_errors_in_.mtn-ignore. The reasons is because the test performs
a mtn ls unknown command and checks the stderr output. Unfortunately,
it doesn't seem to be deterministic in what order the files are checked
against the Lua
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 10, 2007, at 9:19 AM, Daniel Carosone wrote:
On Wed, Oct 10, 2007 at 05:13:48PM +1000, Daniel Carosone wrote:
So, I'm assuming we should now be able to get away with a dep on just
boost-headers, which will save a chunk of space and time.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 10, 2007, at 9:17 AM, Thomas Keller wrote:
Zack Weinberg schrieb:
$ bcp --list --scan --boost=/usr/include *.cc *.hh | grep
'^boost/' | wc -l
1271
Individual Boost headers (I checked format.hpp and shared_ptr.hpp)
seem to expand to about
On 10/10/07, Julio M. Merino Vidal [EMAIL PROTECTED] wrote:
1) The trouble of users with external boost libary versions goes away
There will most likely be no trouble, I think. If monotone uses no
binary libraries from Boost (as is the case now), the user will only
need to have an unpacked
On 10/10/07, Ralf S. Engelschall [EMAIL PROTECTED] wrote:
A make check on h:n.v.m currently results in one failed test:
syntax_errors_in_.mtn-ignore. The reasons is because the test performs
a mtn ls unknown command and checks the stderr output. Unfortunately,
it doesn't seem to be
On Sat, Oct 06, 2007, Ralf S. Engelschall wrote:
This afternoon I finally got really nerved having to type
$ mtn diff -r `mtn automate parent rev` -r rev
or the rather ugly, unhandy and partly unrecognizeable
$ mtn log --diffs --no-graph --brief --from rev --to rev
just to get
On 10/10/07, Richard Levitte [EMAIL PROTECTED] wrote:
I just hit a whoopsie that I hadn't noticed before; it seems the
syntax checking test doesn't quite work because the first line in
stderr doesn't necessarely match the first line in stderr-ref.
This should be fixed as of rev
On 10/10/07, Ralf S. Engelschall [EMAIL PROTECTED] wrote:
I propose to simply
skip the first line of stderr during output comparisons:
That's the right fix in principle but I think there is a more elegant
way to implement it. Stay tuned...
Yes, that's what I expected.
Feel free to
Indexes speed up read operations but slow down writes. Which do we do
more of? I'd optimize for the case that would benefit most. I
suspect we do a fair amount of both. In this case, maybe adding
indexes for mostly-read tables would be the way to go.
-Ben
On 10/10/07, Ralf S. Engelschall
Some Monotone operations really operate slower than what one would
expect in the first spot. Hence, I've today looked at the run-time of
a simple mtn update in a workspace which *is already* at h:n.v.m.
This no-operation command internally performs a dozend times the
following SQL queries:
On 10/10/07, Ben Walton [EMAIL PROTECTED] wrote:
Indexes speed up read operations but slow down writes. Which do we do
more of? I'd optimize for the case that would benefit most. I
suspect we do a fair amount of both. In this case, maybe adding
indexes for mostly-read tables would be the
Ralph wrote:
CREATE INDEX revision_certs__id_name_value ON
revision_certs (id, name, value);
CREATE INDEX public_keys__id ON
public_keys (id);
This dropped down the total execution time of the mentioned mtn update
command by over 80%!
Ben wrote:
Indexes
Chad Walstrom [EMAIL PROTECTED] writes:
[...]
Would there be a way to tell sqlite to ignore indices for given
operations, such as pulls?
That strikes me as a low-level question that should be ignored (at
least unless it causes some measurable problem).
One would hope that SQLite will only
Hi folks!
Is there a general interest of doing another summit next year - maybe
again in January/February?
We should have more than enough topics for it, a lot of things still nag
my personal feeling about monotone (automate interface, selectors,
policy *cough* branches, partial pull, ...) and I
On Wed, Oct 10, 2007 at 05:08:11PM +0200, Julio M. Merino Vidal wrote:
Well, time at least, if space not so much after all...
Well, space... you'd save all the space of boost libraries, _including_
boost-headers (which is the biggest package according to the numbers you
showed). The binary
Thomas Keller wrote:
Is there a general interest of doing another summit next year - maybe
again in January/February?
You know I couldn't attend to the last / first one this year, but I'd
really like to make it this time. But since I'm even more broken than
last year all I could afford is
23 matches
Mail list logo
