We discovered this morning (almost by accident) that the gcc setting
GCC_OBJC_CALL_CXX_CDTORS has been enabled for us since our switch to
4.2 last summer. This means that destructors on C++ objects will be
called when the objective-c object containing it goes away (this
wasn't the case with past
There is one caveat here that I found after running into some issues
with the unit tests. When you convert members from pointers to scoped
pointers, even if you keep the destruction ordering consistent (by
re-ordering the members in the @interface decl), the objects are
destructed much later than
Interesting fix ;)
On our side, Evan wrote a little apache mod rewrite script that makes a
directory case insensitive.
It's now live on build.chromium.org.
Do you think you can verify that the problem is really fixed by trying again
without your fix?
Thanks,
Nicolas
On Thu, Apr 9, 2009 at
Avi/Adam, you got nominated on IRC as relevant people for this.
In http://codereview.chromium.org/66013 I'm changing the way some of the
RenderWidgetHost[View] functions work slightly. I need to coordinate to get
Mac and Linux changes to accommodate this in (I can't land my patch as-is
because of
Hi Nicolas
I confirmed your fix works, I can now get Chrome symbols without my
workaround.
Maybe Mozilla / Firefox can do the same on their server?
Does your change make the filename case insensitive as well?
I think all your files are lowercase, but in case they do mix case,
the same problem
glib and x aren't thread-safe. To work around this our intention is to
only call into them from the UI thread. Unfortunately we currently
don't follow through on this.
To query the clipboard the renderer sends a sync IPC call to the
browser. The browser handles this call on the IO thread (in
On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade est...@chromium.org wrote:
a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
the calls thread safe, but it does so by locking a process-wide mutex,
which will block our UI thread's main loop.
I personally think this is OK.
On Fri, Apr 10, 2009 at 12:28 PM, Peter Kasting pkast...@google.com wrote:
Please let me know if you understand this patch enough to make appropriate
changes, and how to coordinate landing various bits so I don't break anyone.
PK
I patched this in and started fixing things and ended up
On Fri, Apr 10, 2009 at 12:40 PM, ptr727 pieter.vilj...@gmail.com wrote:
Hi Nicolas
I confirmed your fix works, I can now get Chrome symbols without my
workaround.
Maybe Mozilla / Firefox can do the same on their server?
Does your change make the filename case insensitive as well?
I
On Fri, Apr 10, 2009 at 1:07 PM, Adam Langley a...@chromium.org wrote:
X sends an expose message to us
We ask for a BackingStore
We don't have one, so we start a timed wait on the renderer to send us a
paint
We get the paint, so we create the backing store and copy the bitmap to it.
With
On Fri, Apr 10, 2009 at 1:03 PM, Brett Wilson bre...@chromium.org wrote:
On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade est...@chromium.org wrote:
a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
the calls thread safe, but it does so by locking a process-wide mutex,
On Thu, Apr 9, 2009 at 6:49 PM, Ojan Vafai o...@google.com wrote:
At a quick glance, this looks great. I didn't look over every bug, but the
ones I did look at look good.
Yep. You'll want some sort of default description for the ones that have
none.
200+ bugs is certainly too many, but
Option (b) is better, as far as I can tell. On windows, those
messages have their own HWND anyway.
Adam
On Fri, Apr 10, 2009 at 1:15 PM, Ricardo Vargas rvar...@chromium.org wrote:
I opened bug 7379 a while ago to implement option b on the windows side.
On Fri, Apr 10, 2009 at 1:03 PM,
(Ack...resending)
Ok, I have the CL ready, if anyone with Java readability would be willing to
do a review, please let me know.
more inline...
On Fri, Apr 10, 2009 at 2:07 PM, Pam Greene p...@chromium.org wrote:
On Thu, Apr 9, 2009 at 6:49 PM, Ojan Vafai o...@google.com wrote:
At a quick
The issue tracker at code.google.com/p/chromium may be inaccessible or slow
to respond for the next few hours.
Engineers are working on the issue now, so just be patient. It's a good
chance to ignore bugs for a while :)
--Mark
--~--~-~--~~~---~--~~
Chromium
And it's back already, faster than I expected. Pardon the spam.
On Fri, Apr 10, 2009 at 18:31, Mark Larson (Google) m...@chromium.orgwrote:
The issue tracker at code.google.com/p/chromium may be inaccessible or
slow to respond for the next few hours.
Engineers are working on the issue now, so
I have had this constant trouble with getting chromium source. the
tarball continually gets disconnected every fw mb(tried on 2 different
isp's) and the svn gets svn: REPORT of '/svn/!svn/vcc/default': 200 OK
(http://src.chromium.org) after downloading for a while. Here is a
message from someone
I've seen this problem too while doing a big checkout, and i'm investigating
the issue, but the reason is not clear to me yet.
Are you using gclient to get the code?
Nicolas
On Tue, Apr 7, 2009 at 5:11 PM, GREENie ofsevens...@gmail.com wrote:
I have had this constant trouble with getting
18 matches
Mail list logo
