I don't think that a firing squad will materialize over this change,
but if one does, I'll quell them for you.
LGTM in principle (but I haven't seen the actual change).
Mark
Craig Schlenter wrote:
> On Wed, Jan 13, 2010 at 9:00 PM, Peter Kasting wrote:
>> On Wed, Jan 13, 2010 at 10:53 AM, Craig
Dan Kegel wrote:
> On Wed, Jan 13, 2010 at 9:12 AM, Stephen White
> wrote:
>> 2) Most of the supposed performance advantage of strict aliasing rules is
>> probably taken care of by memory disambiguation in modern (ie., Core2 and
>> later) CPUs.
>
> I kind of doubt that. Disallowing aliasing let
Viet-Trung Luu wrote:
>> 2. Temporarily move /bin/ps to /bin/ps.real, and at /bin/ps put a
>> small script that writes the full argument list and maybe other
>> debuggery to a log file somewhere, and then invokes /bin/ps.real. For
>> example:
[...]
>
> Done. And I now see that it looks like my fau
Debugging tips:
1. What's the parent pid of your zombies? Is it a browser process or
something else?
2. Temporarily move /bin/ps to /bin/ps.real, and at /bin/ps put a
small script that writes the full argument list and maybe other
debuggery to a log file somewhere, and then invokes /bin/ps.real.
Thomas Van Lenten wrote:
> Where are the profile dirs going on disk? Time machine doesn't have to be
> on, we can add things to this file incase it is turned on.
(and again. the multiple-address interface for mailing lists kind of sucks.)
--
Chromium Developers mailing list: chromium-dev@googl
(another drek message to avoid having people respond to the wrong addresses)
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Nirnimesh wrote:
> +chromium-dev. This is mac only.
> Trung, Mark: I did see ps zombies, but they were from my long-standing
> chrome, not from chromebot. I'm on 10.5.8.
I haven't seen this myself, but I have seen it reported in the wild.
http://crbug.com/28547#c29, for example.
Mark
--
Chromiu
Igor Gatis wrote:
> Great, just wrote a rule for that. I placed it on the final target of my
> project. What would be nice is to define such rule on the protobuf library
> gyp and export it. It seems this file does that. But when I try doing the
> same, I get the following error:
[...]
> File
>
Igor Gatis wrote:
> Really? At least, it does not seem to be the case for make generator.
> There are no rules for handling .proto files in make generator. That's
> actually what I've been trying to do in the last couple of days.
GYP rules are something that you have to write yourself, there aren'
Igor Gatis wrote:
> Is there a wishlist? I'd like to vote for support for both configure
> step and .proto files.
GYP rules should be able to support .proto files.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http:/
Finnur Thorarinsson wrote:
> You can use the channel changer, as PhistucK points out, to switch and then
> use the About box to update, but you can only move forward in time (stable
> -> beta -> dev).
I'm pretty sure the changer is deprecated. The supported way to hop
between channels is to run t
ther some numbers.
>> Best regards,
>> Jeremy
>> On Mon, Dec 14, 2009 at 6:46 PM, Mark Mentovai wrote:
>>>
>>> Jeremy Moskovich wrote:
>>> > Yep, Avi's right - we don't really have that option here. ATSUI is
>>> > deprecate
Jeremy Moskovich wrote:
> Yep, Avi's right - we don't really have that option here. ATSUI is
> deprecated in 10.6 - we're seeing crashes and incorrect rendering.
> If there are perf issues we can file radars against Core Text.
We should at least know what this change does to us perf-wise. If
we'
pink wrote:
> 2009/12/14 Jeremy Moskovich :
>> There should be no perf regression this time since we'll continue to use
>> ATSUI on 10.5 and only switch to Core Text on 10.6.2 [like Safari].
>> This should also have the effect of fixing [or modifying the stack traces]
>> we've been seeing for ATSUI
Igor Gatis wrote:
> You mean they were manually pre-created, right?
Yes
> I used a custom action with success and I believe that sounds better for
> module updates purposes.
We used to do things like that in the pre-GYP days. When we moved our
builds over to GYP, we decided that it wasn't anywh
There are cases where you'll want to flout the linter, but this isn't
one of them. Scott and Peter have both posted viable workarounds that
don't hamper readability (and in fact improve it relative to the
snippet Jonathan is asking about.) Personally, I prefer Scott's, but
Peter's is good too.
D
Igor Gatis wrote:
> BTW, do you guys know of lists or wiki I could get more information
> regarding GYP tool?
We have gyp-develo...@googlegroups.com. There's also some
documentation in various states of completeness at
http://gyp.googlecode.com/.
Mark
--
Chromium Developers mailing list: chrom
> On Wed, Dec 9, 2009 at 3:28 PM, Igor Gatis wrote:
>> Is there documentation somewhere regarding gclient? I'd like to know more
>> about how hooks and other gclient features work.
>>
>>
>> On Tue, Dec 8, 2009 at 6:27 PM, Mark Mentovai wrote:
>>>
&g
gclient sync --force
Gary Thomas wrote:
> Indeed, this is in thread:
> http://groups.google.com/group/chromium-dev/browse_thread/thread/0053084fdb3f7742
>
> However, there is no solution there. I have a brand new download/
> checkout and I ran
> 'gclient sync' immediately thereafter. The thread
Igor Gatis wrote:
> When I change a .gyp, do I need to call gyp or the build process does that
> for me? If it does, how does it detect the .gyp file has been modified?
When you change it yourself, in your own working copy, you run
"gclient runhooks" to get new files generated.
When a .gyp change
Bradley Nelson wrote:
> Even if those files are largely a duplicate of those in base?
If it gets to that point, we can maintain the sources list, or the
shared sources list, in a variable. Then we could do explicit
additions to the targets that need it, or explicit excludes if that
winds up easie
Bradley Nelson wrote:
> You mean as 'base' currently is, or duplicating the file lists?
I mean I have no problem with base_nacl_win64 existing as a target,
and with adding files that are needed in that target to that target.
Mark
--
Chromium Developers mailing list: chromium-dev@googlegroups.co
I think that the stripped-down NaCl-specific 64-bit targets are the
right thing to have happened to base, at least for now.
Mark
Brad Nelson wrote:
> I had talked about this with mmentovai and some others. Concern was raised
> about the complexity this would introduce into gyp. I do have a gut fe
Is this thought to be http://crbug.com/29240, or are there other
problems with the signal handler? The change to fix that is out at
http://codereview.chromium.org/460094.
Mark
Evan Stade wrote:
> On Mon, Dec 7, 2009 at 1:41 PM, Paweł Hajdan Jr.
> wrote:
>>
>> On Mon, Dec 7, 2009 at 22:34, Glenn
This script runs on
third_party/WebKit/WebKitLibraries/libWebKitSystemInterfaceLeopard.a,
but that file hasn't changed in the past couple of days, so I don't
see why this would be happening.
The script that's driving the failed step is at
third_party/WebKit/WebCore/WebCore.gyp/mac/adjust_visibilit
a try.
Eric Seidel wrote:
> I'm anti trailing whitespace. I think they're only agnostic about it
> because XCode can't zap it for them. I think better would be to get this
> kind of functionality pushed into XCode. You might ask Mark Mentovai to
> work his connections as h
nikuli...@gmail.com wrote:
> LibICU is almost ubiquitous in non microsoft OS distributions, usually
> more upstream and ahead of upstream with bugs subsequent to every ICU
> release. Also it takes a lot of time to compile.
>
> Is there any point of having it bundled?
Our version of ICU is patched
James Robinson wrote:
> What's the benefit of omitting the virtual destructor?
The benefit is that the destructor stays out of the vtable, which will
potentially reduce the vtable size and save a layer of indirection. I
don't consider either of these advantages compelling. I agree that
it's over
rahulsin...@gmail.com wrote:
> I was trying to compile chromium today on Linux and I got this error.
> This error occurred because of -Werror CFLAG set in the Makefile. I
> remedied by writing a one-liner to delete all occurrences of -Werror
> from CFLAGS in all Makefiles.
I happen to find this wa
Bradley Nelson wrote:
> If we move the gypi's to subdirectories, paths in them will still be
> relative to src/chrome, which might be confusing.
> I would prefer if gypi's didn't have this behavior, and plan to fix it:
> http://code.google.com/p/gyp/issues/detail?id=116
That bug only refers to the
Peter Kasting wrote:
> On Fri, Nov 13, 2009 at 12:44 PM, Stuart Morgan
> wrote:
>>
>> If we end up actually having four at a time that seems likely to be
>> worse than two: either four people are doing nothing but sheriffing,
>> which there is probably not enough work for, or all four people are
>
Ojan Vafai wrote:
> I don't think this is what sheriffs are supposed to do, although there is
> clearly not consensus here. The goal of the sheriff is to keep the tree open
> as long as possible without carpeting over regressions. The sheriff should
> suffer through minor flakiness without closing
(m...@chromium.org, please - that's the address that I can post to
mailing lists from.)
There was a chromium-dev thread on this on Friday.
http://groups.google.com/group/chromium-dev/browse_thread/thread/932a19ed777b9bb4
Between your two choices, I have a slight preference for option 1.
Option
omplained about but there could be others.
> What is the best way for use to check this other than eyeballing.
> We will push a new nacl version into chrome later this week and I
> want to make sure it is "clean".
>
> Robert
>
> On Thu, Nov 5, 2009 at 8:38 PM, Mark M
We've got the "gypd" (d = debug) sorta-generator format as an option,
alongside xcode, msvs, make, etc. It dumps the dicts it receives as
.gypd files next to your .gyp files, so you can see what would be fed
to a generator. You might need to feed it some -D because it's not
tied to an OS by defa
Paweł Hajdan Jr. wrote:
> scons: ***
> [/home/ph/chromium/src/sconsbuild/Debug/obj/yasm/genmacro/source/patched-yasm/tools/genmacro/genmacro.o]
> Source
> `/home/ph/chromium/src/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.c'
> not found, needed by target
> `/home/ph/chromium/s
Oops.
http://codereview.chromium.org/353002
Nico Weber wrote:
> Hi,
>
> when building after syncing, I now get
>
>
> /Users/thakis/src/chrome-git/src/chrome/../xcodebuild/chrome.build/Debug/chrome.build/Script-649B47660F26D59AE4D7EEA0.sh:
> line 2: BUILT_PRODUCTS_DIR: command not found
>
> e
I'm sure that there are better examples than the below. Presumably if
you want something defined in both Debug and Release, you want it
globally, and you'd be better off specifying it outside of the
configuration altogether.
Brad, we can still inherit from non-abstract configurations, right?
Thi
Jens Alfke wrote:
> How much would that increase memory use? (says the guy on the Memory task
> force...) I.e. what's the RPRVT of a warmed-up renderer process?
Does it matter? At least for the startup case, that's a renderer we
know we'll need anyway.
You could use this argument to shoot down
Jens Alfke wrote:
> Unfortunately, it's nearly impossible to continue a forked process on OS X
> if it uses any higher-level (above POSIX) APIs. The main problem is that
> Mach ports can't be replicated across the fork, so if any ports were already
> open, they'll all be bogus in the new process.
Darin Fisher wrote:
> I suspect this is at least one of the bigger issues.
> I also suspect that process creation is a problem on Windows. We should
> probably look into having a spare child process on Windows to minimize new
> tab jank. Maybe there is a bug on this already?
This shouldn't be r
Nico Weber wrote:
> Is SL a supported platform for building?
Certainly.
> If so, should we have an SL buildbot?
Yes, but Tom and I have other priorities right now. We should have
10.6 bots running next month.
Mark
--~--~-~--~~~---~--~~
Chromium Developers mail
thakis r29990 (http://codereview.chromium.org/336001)
-[NSString stringWithCString:] is deprecated as of Mac OS X 10.4. The
replacement is -[NSString stringWithCString:encoding:].
We also have base::SysUTF8ToNSString from base/sys_string_conversions.h.
Mark
Paweł Hajdan Jr. wrote:
> I get thi
Evan Stade wrote:
> There's a checkbox in the external protocol dialog with the text
> "Remember my choice for all links of this type." (On windows and
> linux, this is not actually implemented, but there are bugs out to fix
> that) The options are then "Cancel" and "Launch Application". The
> con
Evan Martin wrote:
> On Mon, Oct 19, 2009 at 7:43 AM, Mark Mentovai wrote:
>> If you had tried a debug build, you would have seen output like this:
>>
>> [mmdd/hhmmss:FATAL:/chrome/trunk/src/base/mac_util.mm(80)] Check
>> failed: bundle. failed to load the bundle
Mikhail Naganov wrote:
> Also answering on Mark's question.
>
> $ pwd
> /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS
[...]
> $ ./Chromium
> <<< this way, it fails >>>
OK, I know what's happening here. Having a dot after MacOS in the
path to the executable is what bre
How are you launching it from the Terminal? Can you tell me the exact
invocation? $PATH and working directory too?
Can you log the value of path after PathService::Get(base::FILE_EXE,
&path) in chrome::GetVersionedDirectory(),
chrome/common/chrome_paths_mac.mm:72?
Mark
Mikhail Naganov wrote:
I've been sheriffing for Munjal for the past hour, when I found the
tree in a bad state.
I'm happy to keep helping, but it'd be great if some other folks would
step up too.
Mark
Munjal wrote:
> I am the only scheduled sheriff today and there is no co-sheriff. I was out
> for 5 minutes to grab l
Today on the waterfall, I see:
Sheriffs: munjal
>From past experience, one sheriff really isn't enough. Munjal should
be able to take a lunch break.
Also, I think that this will be his first stint as sheriff. It would
probably help him out if he had a co-sheriff who had done it at least
once
Albert J. Wong wrote:
> What is @loader_path relative off of?
@loader_path is the directory that contains whatever is being loaded.
While loading the main executable, @loader_path is equivalent to
@executable_path.
If your three dylibs refer to one another and are always in the same
directory,
framework as a bundle from mac_util::MainAppBundle()
since r28262.
If you put the dylibs in the framework and they depend on one another,
you may need to switch them to refer to each other using @loader_path
instead of @executable_path.
Mark
scherkus wrote:
> On Wed, Oct 7, 2009 at 12:17 PM, Ma
Which processes need to load these libraries?
Are these libraries loaded at launch time or by dlopen?
Mark
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://grou
If anyone want to work on this, we've left some breadcrumbs behind by
declaring libraries that could be built as either static or shared as
a GYP variable named library_type. It expands to static_library by
default, but the intention was to make it easy to switch to a shared
library build by flip
gclient may have gotten confused in a previous run. Try "gclient sync
--force" and let us know if you still have a problem with that.
Mark
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options,
Nick Carter wrote:
> I've been assuming that a 'dependencies' entry between two targets implies
> the serialization of their build order, and a missed opportunity for build
> parallelization.
That's not true. If a static library depends on another static
library (the common case among our target
Nick Carter wrote:
> The pollution obscures the actual dependency structure.
One man's pollution is another's...?
Seriously, we do this because the typical pattern is to say "anyone
that depends on this library needs to use these include directories or
have these macros defined." With 120 or so
Yes, I was poking this a little bit last week, and a little bit the
week before. It seems that under Valgrind, tests involving the
pasteboard, and maybe a couple of other things too, will always fail.
In some cases, the test failures result in certain things not being
cleaned up, which in turn re
John Abd-El-Malek wrote:
> I've seen this before last week as well.
OK, then there might be something else going on. When it happened in
the past, what did svn status show?
I've never seen this, by the way. (Any time I make changes to V8, I
don't do it in a Chromium working copy.)
> Can this
This happened after a GYP change that Brad made recently (last week, I think).
We need to add to v8's svn:ignore.
John Abd-El-Malek wrote:
> Every time v8 team updates which branch is the one that's used in Chrome,
> gclient sync fails on Windows. The error is below.
> running 'svn upd
Adam Langley wrote:
> * x87 doubles are 80-bits in registers and 64-bits in memory.
Depending on the state of the x87 floating point control word.
Can bracket significant test-impacting floating point operations with
fldcw or do something else in that code to force spills to memory?
I'm aware o
Dan Kegel wrote:
> It's so our tests pass, I think.
We don't have tests for nothing.
If a test exposes a case where something requires 53/64-bit IEEE
double precision as opposed to 64/80-bit double extended, and we're
changing our configuration "to make tests pass" but then releasing in
another
Is there a reason we gate this on branding? The comment doesn't speak
to that at all.
Evan Martin wrote:
> The code doesn't lie:
>
> 'conditions': [
> ['branding=="Chromium"', {
> 'cflags': [
> '-march=pentium4',
> '-msse2',
Drew Wilson wrote:
> I'm trying to do a gcl try on my mac, but getting this error:
> svn checkout --depth empty svn://svn.chromium.org/chrome-try/try
> /var/folders/zz/zzzivhrRnAmviuee++2D3++-1lE/-Tmp-/tmpMRXSrL --username
> atwil...@google.com
> Ouput:
> svn: invalid option: --depth
> Type 'svn h
I wrote:
> Well, I have it on for third party code on the Mac.
I'm wrong.
Hmm...
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromi
Craig Schlenter wrote:
> Currently we remove -Wall in third party code though.
Oh.
Well, I have it on for third party code on the Mac. I like it that
way, and I recommend it. Maybe more Linux developers don't like it,
and that's why it's off on that platform. Or maybe it's just an
accident of
Jeremy Orlow wrote:
> Unless we can get people upstream to compile with -Wall -Werror, that'll be
> an uphill battle (every time we want to roll to a new version). It'd be
> nice if we could, though.
This is exactly the rationale for building code that's not our own
with -Wall but not -Werror.
Eric Seidel wrote:
> WebCore builds with -Werror upstream, so I'm slightly surprised that
> Chromium builds it w/ -Werror disabled. However it's possible we
> build with different errors turned on.
The last time I looked at this, our WebCore build throws warnings on
four files on the Mac with GC
Avi Drissman wrote:
> Screw #2: The actual scrollbar is drawn just a wee bit shorter. Cocoa sizes
> scrollbar thumbs with a proportion value ([0..1]) while HITheme uses a
> "viewsize" value related to the physical size of the scrollbar. The precise
> formula Cocoa uses to turn the view size into i
On behalf of the Mac folks, you're quite welcome!
Mark
Adam Barth wrote:
> Thanks for making Mac Chrome launch ridiculously fast. I really enjoy
> that, on my laptop, the main window is painted before the dock icon
> has even crested its first bounce.
--~--~-~--~~~-
Evan Martin wrote:
> The one that's easy to break is incognito: open one normal window, one
> incognito, try refreshing the NTP on both. Check that this actually
> works on trunk before you assume any breakage was introduced by you.
Yeah, I noticed while I was working on it that the system seems
Evan Martin wrote:
> This cache is in-memory only, right? That is, it's generated during startup?
> (In the past I've talked about caches but I'm worried that the NTP
> positioning will jump around due to stale caches, since the site
> ranking is based on day granularity. Though that could be co
Amanda Walker wrote:
> Great writeup. There's definitely too much going on in the UI thread. Even
> after the page paints, I'm seeing multi-second pauses while additional stuff
> comes in, where the browser process is unresponsive (example: iGoogle with a
> bunch of gadgets). It's not clear to
I spent a chunk of last week looking at the new tab page performance
on startup on the Mac. I found that the renderer was waiting on data
from the browser process for what seemed like far too long. The key
to this problem is that resource requests for the new tab page are
funneled through the br
Andrew Scherkus wrote:
> Any opposition to globally declaring an operator<< ostream overload for
> TimeDelta in base/time.h?
> According to style guide it needs to be fully justified, but it'd be nice to
> use DCHECK_xx/EXEPCT_xx/ASSERT_xx with TimeDeltas.
I think this is fine.
Mark
--~--~-
Ben Laurie wrote:
> The observation is that many places that are currently:
> #if defined(OS_LINUX)
> are going to become:
> #if defined(OS_LINUX) || defined(OS_FREEBSD)
> and this is ugly.
I think that these would generally be proper as defined(OS_POSIX) &&
!defined(OS_MACOSX). If people think
This should be fixed at our r23546.
Mark
I wrote:
> I've tracked this down to WebKit r47270, which we picked up in our
> merge at r23446. It looks like there's a fix for our specific case
> upstream at r47333, but I believe that function still contains bugs.
> I'm going to talk to Simon, the au
I've tracked this down to WebKit r47270, which we picked up in our
merge at r23446. It looks like there's a fix for our specific case
upstream at r47333, but I believe that function still contains bugs.
I'm going to talk to Simon, the author of the relevant WebKit patches,
about that.
I can own
John Abd-El-Malek wrote:
> Intentional but I have a TODO in the Chromium branch of Rietveld to update
> this. I just synced ~60 changes from trunk to our branch, and now we get a
> close button to the left of each issue. Since everyone with a @chromium
> account could edit an issue, I thought it
n179...@gmail.com wrote:
> Does Chromium use boost library? In the source tree, i see there is a
> 'boost' directory under 'third-party'.
> It appears to be an incomplete version of boost 1.36. I said
> incomplete since a lot of directories of boost are missing?
>
> Does anyone know why is that?
I don't think so. It looks like VS doesn't rebuild files when the
compiler invocation to build them would change. Michael added a new
macro definition on the command line.
If that's the case, this would be a VS problem (I'd call it a bug),
and I'm not sure how easy it would be to work around in
Dimitri Glazkov wrote:
> The culprit here was the change to the CodeGeneratorV8.pm. It looks
> like we should somehow trigger clobber of of rule_binding.py when that
> happens.
We already do. In the .idl rule in webkit.gyp, we have:
'inputs': [
'../third_party/WebKit/WebC
I just checked in r22506, which alters the structure of the
application on disk on the Mac slightly. The entire program has moved
into a dylib (framework) that lives within the app bundle, and the
main executable is now a tiny stub that doesn't do anything but jump
to the entry point in the dylib
Evan Martin wrote:
> When we load a plugin any symbols we export come before its symbols.
This doesn't happen on the Mac unless you go out of your way to
arrange for it to happen.
Even so, we do use -fvisiblility=hidden for all Mac builds, because I
like for these things to be well-trimmed anywa
pjwaffle wrote:
> Why don't we use CMake for chromium's build system? It would ease the
> pain on for example xcode or kdevelop users.
Because we have GYP, which eases the pain on Xcode, Visual Studio,
SCons, and make users. We developed GYP specifically to meet
Chromium's needs. We did conside
Dan Kegel wrote:
> No. Generating files is the point of gyp. Nothing says they have to
> be in the source tree.
Out of all of the proposals out there, the only ones that make any
sense to my software-developin' mind are the ones that keep the build
files in the source tree. I find it much easi
Michael Moss wrote:
> I agree. I thought we wanted to avoid that kind of bloat, which is why
> I went the helper script route instead of pestering for loops. If we
> add too many features, pretty soon we'll just have scons-NG (not that
> there's anything wrong with that, but I don't understand tha
I don't think I've seen it. Is it gonna work on the Mac?
Evan Martin wrote:
> On Fri, Jul 17, 2009 at 7:38 PM, Mark Mentovai wrote:
>> Dan, variants aren't implemented for non-scons builds yet. There's a
>> plan in place, but it'll happen after loops
(Third try to send this to the list, and then I'm giving up. They
keep bouncing.)
Dan, variants aren't implemented for non-scons builds yet. There's a
plan in place, but it'll happen after loops are added (which should be
next week).
Mark
Dan Kegel wrote:
> Hi Mark,
> I'm interested in cleani
Ben Goodger (Google) wrote:
> Specifically, there were reasons why GYP was created instead of just
> using CMake. Mark Mentovai should comment.
I'm not on webkit-dev, but I was on the cc list for that thread. I'm
unwinding from the weekend now, but I'll subscribe and
Since yesterday, all of the Mac builds in BigHouse (including main
Buildbot builds and tryserver builds) have been supported by an extra
set of distccd servers running on nearby Linux systems. The only
impact should be that builds should be faster now, since there are
more CPUs available to do Ma
You probably want 'actions' - these run at compile time. You can
find examples of these all over our tree.
Mark
Mike Mammarella wrote:
>
> Hi all,
>
> I'm trying to add a file which needs to be processed autoconf-style at
> "compile" time. It's a script with things like @@FOO@@ that are values
I can help you out this afternoon if necessary.
Dimitri Glazkov wrote:
> I agree -- if weren't such a Python n00b I'd already have a patch. I
> am looking through it now
>
> :DG<
>
> On Mon, Jul 6, 2009 at 8:19 AM, Mark Mentovai wrote:
>> = needs to be
= needs to be quoted if it occurs in the first word passed to the
shell (or, if the first word was a variable assignment, the second
word, and so on). EncodePOSIXShellArgument doesn't know or care
whether it's working with the first word or a subsequent one.
I'm pretty much convinced that whatev
Sometimes, it's hard to work on a product and actually use it at the
same time. The rapid stop/start cycles aren't exactly conducive to
keeping long-lived activities like your e-mail open. "I work on
Chromium, but I surf in Camino, or Safari, or Firefox." Does that
sound familiar? I've worked
I see the problem here, I'll fix it.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~
Avi Drissman wrote:
> OK, this fixes just about everything important.
>
> Known issues:
> - Expose funkiness with 10.5. Since that's fixed in 10.6, that's unlikely to
> get attention.
Avi and I found that the Exposé funkiness, present on his Leopard
machine and my Leopard laptop last week, is all
If you've got a file that begins its life as something on-disk, and
you just need to carry the path to it around, then that's fine, it
should live its life as a FilePath.
If you've got to create a file using some name where the name is some
constant in code, use FilePath with ASCII constants. Ap
Amanda Walker wrote:
> Yeah. And I have to say, the tab-modal file sheet is very, very cool.
> It would be a shame to lose that capability.
I agree, I think it'd be worth seeing how polished we can get things
with Avi's POC. It's a cool behavior that has the exact "feel" that
sheet users would
I think that this is really cool. Really cool. I asked Avi where
this was headed, and he said that if it's headed into GTM then this
app will drive development for polish and feedback is welcome. Here
are the rough edges I found while playing around with this:
When a native sheet is born, the
Yeah, that'd be awesome.
Ben Goodger wrote:
> I remember Nicholas saying he thought it'd be possible to fabricate a
> non-modal sheet like thing.
>
> -Ben
>
> On Tue, May 5, 2009 at 3:25 PM, Mark Mentovai wrote:
>> The sheet approach or the sheet-look app
1 - 100 of 138 matches
Mail list logo
