> I don't truly understand how base works and fits together, and my feeling is
> few people do, or someone would have figured out the solution to weird bugs
> like https://trac.macports.org/ticket/37093 by now.
I assure you the logging code is not that hard to understand compared
with some other
On Nov 20, 2014, at 5:47 AM, Clemens Lang wrote:
>>> That's on 10.6, where I have indeed seen clang-3.4 consume huge amounts of
>>> memory on a single file, AFAIK that compiler wasn't being used. However, if
>>> port upgrade outdated uses a single tclsh process for the whole procedure,
>>> and
>
Hi,
>> OK. BTW, isn't SQLite a protocol that doesn't really scale well? I'm far
>> from an
>> expert on this kind of subject, but I recently followed advice on the
>> kdepim-user ML to migrate my akonadi db to mysql (mariadb, as is the default
>> for port:akonadi), and performance has become way
On Nov 20, 2014, at 4:30 AM, René J.V. Bertin wrote:
> On Thursday November 20 2014 11:11:05 Clemens Lang wrote:
>
>>> What is the point of all those scans, if I may ask?
>>
>> We're not the ones doing them, SQLite is. We don't really care how SQLite
>> does
>> things, as long as it's fast.
>
Hi,
- On 20 Nov, 2014, at 09:53, René J.V. Bertin rjvber...@gmail.com wrote:
> Are you saying that for each file, you first look up the port again and again,
> which is probably an operation of a certain cost too?
No, we're not doing that manually. We're just sending a database query with tw
On Nov 20, 2014, at 2:53 AM, René J.V. Bertin wrote:
> On Thursday November 20 2014 09:24:56 Clemens Lang wrote:
>
>> The slowness occurs because a database query uses an index to select all
>> files
>> installed by the port currently being processed and then continues to scan
>> over
>> this
Hi,
- On 20 Nov, 2014, at 03:14, Merton Campbell Crockett
m.c.crock...@roadrunner.com wrote:
> It would seem to me that if there were a general problem with changes to the
> database software, I should have seen delays when the 15 outdated software
> packages were processed before processing
On Nov 19, 2014, at 9:14 PM, Merton Campbell Crockett
wrote:
> It would seem to me that if there were a general problem with changes to the
> database software, I should have seen delays when the 15 outdated software
> packages were processed before processing the boost package.
Even an expon
https://trac.macports.org/ticket/45645
It's already documented in the ticket tracker.
On Nov 19, 2014, at 9:14 PM, Merton Campbell Crockett wrote:
> Jeremy:
>
> Your assertion that the problem is related to a new version of the database
> software included in the Yosemite software distribution
Jeremy:
Your assertion that the problem is related to a new version of the database
software included in the Yosemite software distribution bothers me.
It would seem to me that if there were a general problem with changes to the
database software, I should have seen delays when the 15 outdated
Yosemite introduced a new version of the database software that MacPorts uses,
making MacPorts horrifically slow presently.
Please let the process complete next time.
A (not yet released) version of MacPorts will address the database changes from
Yosemite.
On Nov 19, 2014, at 17:37, Merton Cam
I was performing an update of outdated software and ran into this problem when
updating Wireshark.
---> Computing dependencies for boost
---> Fetching archive for boost
---> Attempting to fetch
boost-1.56.0_2+no_single+no_static+python27.darwin_14.x86_64.tbz2 from
http://packages.macports.or
12 matches
Mail list logo
